From f50ae72ec3417cae55dd4e085991c01af9fdc5f1 Mon Sep 17 00:00:00 2001 From: Martin Nagy Date: Wed, 11 Feb 2009 20:37:59 +0100 Subject: Initial commit --- doc/Makefile.in | 29 + doc/arm/Bv9ARM-book.xml | 14205 +++++++++++++++++++ doc/arm/Bv9ARM.ch01.html | 562 + doc/arm/Bv9ARM.ch02.html | 158 + doc/arm/Bv9ARM.ch03.html | 818 ++ doc/arm/Bv9ARM.ch04.html | 1036 ++ doc/arm/Bv9ARM.ch05.html | 143 + doc/arm/Bv9ARM.ch06.html | 8784 ++++++++++++ doc/arm/Bv9ARM.ch07.html | 254 + doc/arm/Bv9ARM.ch08.html | 139 + doc/arm/Bv9ARM.ch09.html | 630 + doc/arm/Bv9ARM.ch10.html | 111 + doc/arm/Bv9ARM.html | 276 + doc/arm/Bv9ARM.pdf | 14133 ++++++++++++++++++ doc/arm/Makefile.in | 67 + doc/arm/README-SGML | 329 + doc/arm/isc-logo.eps | 12253 ++++++++++++++++ doc/arm/isc-logo.pdf | Bin 0 -> 21981 bytes doc/arm/latex-fixup.pl | 49 + doc/arm/man.dig.html | 673 + doc/arm/man.dnssec-dsfromkey.html | 170 + doc/arm/man.dnssec-keyfromlabel.html | 210 + doc/arm/man.dnssec-keygen.html | 270 + doc/arm/man.dnssec-signzone.html | 340 + doc/arm/man.host.html | 249 + doc/arm/man.named-checkconf.html | 134 + doc/arm/man.named-checkzone.html | 300 + doc/arm/man.named.html | 322 + doc/arm/man.nsupdate.html | 568 + doc/arm/man.rndc-confgen.html | 222 + doc/arm/man.rndc.conf.html | 255 + doc/arm/man.rndc.html | 203 + doc/doxygen/Doxyfile.in | 1269 ++ doc/doxygen/Makefile.in | 38 + doc/doxygen/doxygen-input-filter.in | 60 + doc/doxygen/isc-footer.html | 28 + doc/doxygen/isc-header.html | 26 + doc/doxygen/mainpage | 85 + 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 + doc/draft/draft-ietf-dnsext-2929bis-01.txt | 928 ++ doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt | 992 ++ doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt | 1397 ++ ...t-ietf-dnsext-dnssec-2535typecode-change-06.txt | 442 + .../draft-ietf-dnsext-dnssec-bis-updates-01.txt | 616 + .../draft-ietf-dnsext-dnssec-experiments-03.txt | 840 ++ .../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-06.txt | 504 + doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt | 839 ++ doc/draft/draft-ietf-dnsext-ds-sha256-05.txt | 504 + doc/draft/draft-ietf-dnsext-ecc-key-07.txt | 928 ++ .../draft-ietf-dnsext-forgery-resilience-02.txt | 17 + doc/draft/draft-ietf-dnsext-interop3597-02.txt | 334 + ...draft-ietf-dnsext-keyrr-key-signing-flag-12.txt | 560 + doc/draft/draft-ietf-dnsext-mdns-46.txt | 1801 +++ doc/draft/draft-ietf-dnsext-nsid-01.txt | 840 ++ doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt | 464 + doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt | 580 + .../draft-ietf-dnsext-rfc2671bis-edns0-01.txt | 480 + .../draft-ietf-dnsext-rfc2672bis-dname-13.txt | 952 ++ ...-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-05.txt | 729 + doc/draft/draft-ietf-dnsext-tsig-sha-06.txt | 522 + doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt | 1063 ++ doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt | 1232 ++ .../draft-ietf-dnsop-default-local-zones-05.txt | 672 + doc/draft/draft-ietf-dnsop-inaddr-required-07.txt | 396 + .../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-01.txt | 1008 ++ 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 + doc/draft/draft-kato-dnsop-local-zones-00.txt | 295 + .../draft-park-ipv6-extensions-dns-pnp-00.txt | 1830 +++ doc/draft/update | 46 + doc/misc/Makefile.in | 48 + doc/misc/dnssec | 84 + doc/misc/format-options.pl | 49 + doc/misc/ipv6 | 113 + doc/misc/migration | 267 + doc/misc/migration-4to9 | 57 + doc/misc/options | 537 + doc/misc/rfc-compliance | 62 + doc/misc/roadmap | 47 + doc/misc/sdb | 169 + doc/misc/sort-options.pl | 50 + doc/rfc/fetch | 6 + doc/rfc/index | 119 + doc/rfc/rfc1032.txt | 781 + doc/rfc/rfc1033.txt | 1229 ++ doc/rfc/rfc1034.txt | 3077 ++++ doc/rfc/rfc1035.txt | 3077 ++++ doc/rfc/rfc1101.txt | 787 + doc/rfc/rfc1122.txt | 6844 +++++++++ doc/rfc/rfc1123.txt | 5782 ++++++++ doc/rfc/rfc1183.txt | 619 + doc/rfc/rfc1348.txt | 227 + doc/rfc/rfc1535.txt | 283 + doc/rfc/rfc1536.txt | 675 + doc/rfc/rfc1537.txt | 507 + doc/rfc/rfc1591.txt | 395 + doc/rfc/rfc1611.txt | 1683 +++ doc/rfc/rfc1612.txt | 1795 +++ doc/rfc/rfc1706.txt | 563 + doc/rfc/rfc1712.txt | 395 + doc/rfc/rfc1750.txt | 1683 +++ doc/rfc/rfc1876.txt | 1011 ++ doc/rfc/rfc1886.txt | 268 + doc/rfc/rfc1982.txt | 394 + doc/rfc/rfc1995.txt | 451 + doc/rfc/rfc1996.txt | 395 + doc/rfc/rfc2052.txt | 563 + doc/rfc/rfc2104.txt | 620 + doc/rfc/rfc2119.txt | 171 + doc/rfc/rfc2133.txt | 1795 +++ doc/rfc/rfc2136.txt | 1460 ++ doc/rfc/rfc2137.txt | 619 + doc/rfc/rfc2163.txt | 1459 ++ doc/rfc/rfc2168.txt | 1123 ++ doc/rfc/rfc2181.txt | 842 ++ doc/rfc/rfc2230.txt | 619 + doc/rfc/rfc2308.txt | 1067 ++ doc/rfc/rfc2317.txt | 563 + doc/rfc/rfc2373.txt | 1459 ++ doc/rfc/rfc2374.txt | 675 + doc/rfc/rfc2375.txt | 451 + doc/rfc/rfc2418.txt | 1459 ++ doc/rfc/rfc2535.txt | 2635 ++++ doc/rfc/rfc2536.txt | 339 + doc/rfc/rfc2537.txt | 339 + doc/rfc/rfc2538.txt | 563 + doc/rfc/rfc2539.txt | 395 + doc/rfc/rfc2540.txt | 339 + doc/rfc/rfc2541.txt | 395 + doc/rfc/rfc2553.txt | 2299 +++ doc/rfc/rfc2671.txt | 395 + doc/rfc/rfc2672.txt | 507 + doc/rfc/rfc2673.txt | 395 + doc/rfc/rfc2782.txt | 675 + doc/rfc/rfc2825.txt | 395 + doc/rfc/rfc2826.txt | 339 + doc/rfc/rfc2845.txt | 843 ++ doc/rfc/rfc2874.txt | 1123 ++ doc/rfc/rfc2915.txt | 1011 ++ doc/rfc/rfc2929.txt | 675 + doc/rfc/rfc2930.txt | 899 ++ doc/rfc/rfc2931.txt | 563 + doc/rfc/rfc3007.txt | 507 + doc/rfc/rfc3008.txt | 395 + doc/rfc/rfc3071.txt | 563 + doc/rfc/rfc3090.txt | 619 + doc/rfc/rfc3110.txt | 395 + doc/rfc/rfc3123.txt | 451 + doc/rfc/rfc3152.txt | 227 + doc/rfc/rfc3197.txt | 283 + doc/rfc/rfc3225.txt | 339 + doc/rfc/rfc3226.txt | 339 + doc/rfc/rfc3258.txt | 619 + doc/rfc/rfc3363.txt | 339 + doc/rfc/rfc3364.txt | 619 + doc/rfc/rfc3425.txt | 283 + doc/rfc/rfc3445.txt | 563 + doc/rfc/rfc3467.txt | 1739 +++ doc/rfc/rfc3490.txt | 1235 ++ doc/rfc/rfc3491.txt | 395 + doc/rfc/rfc3492.txt | 1963 +++ doc/rfc/rfc3493.txt | 2187 +++ doc/rfc/rfc3513.txt | 1459 ++ doc/rfc/rfc3596.txt | 451 + doc/rfc/rfc3597.txt | 451 + doc/rfc/rfc3645.txt | 1459 ++ doc/rfc/rfc3655.txt | 451 + doc/rfc/rfc3658.txt | 1067 ++ doc/rfc/rfc3757.txt | 451 + doc/rfc/rfc3833.txt | 899 ++ doc/rfc/rfc3845.txt | 395 + doc/rfc/rfc3901.txt | 283 + doc/rfc/rfc4025.txt | 675 + doc/rfc/rfc4033.txt | 1179 ++ doc/rfc/rfc4034.txt | 1627 +++ doc/rfc/rfc4035.txt | 2971 ++++ doc/rfc/rfc4074.txt | 339 + doc/rfc/rfc4159.txt | 171 + doc/rfc/rfc4193.txt | 899 ++ doc/rfc/rfc4255.txt | 507 + doc/rfc/rfc4343.txt | 563 + doc/rfc/rfc4367.txt | 955 ++ doc/rfc/rfc4398.txt | 955 ++ doc/rfc/rfc4408.txt | 2691 ++++ doc/rfc/rfc4431.txt | 227 + doc/rfc/rfc4470.txt | 451 + doc/rfc/rfc4634.txt | 6051 ++++++++ doc/rfc/rfc4641.txt | 1963 +++ doc/rfc/rfc4648.txt | 1011 ++ doc/rfc/rfc4701.txt | 675 + doc/rfc/rfc5155.txt | 2915 ++++ doc/rfc/rfc952.txt | 340 + doc/xsl/Makefile.in | 28 + doc/xsl/copyright.xsl | 75 + doc/xsl/isc-docbook-chunk.xsl.in | 65 + doc/xsl/isc-docbook-html.xsl.in | 58 + doc/xsl/isc-docbook-latex-mappings.xml | 37 + doc/xsl/isc-docbook-latex.xsl.in | 166 + doc/xsl/isc-docbook-text.xsl | 50 + doc/xsl/isc-manpage.xsl.in | 145 + doc/xsl/pre-latex.xsl | 55 + 218 files changed, 213544 insertions(+) create mode 100644 doc/Makefile.in create mode 100644 doc/arm/Bv9ARM-book.xml create mode 100644 doc/arm/Bv9ARM.ch01.html create mode 100644 doc/arm/Bv9ARM.ch02.html create mode 100644 doc/arm/Bv9ARM.ch03.html create mode 100644 doc/arm/Bv9ARM.ch04.html create mode 100644 doc/arm/Bv9ARM.ch05.html create mode 100644 doc/arm/Bv9ARM.ch06.html create mode 100644 doc/arm/Bv9ARM.ch07.html create mode 100644 doc/arm/Bv9ARM.ch08.html create mode 100644 doc/arm/Bv9ARM.ch09.html create mode 100644 doc/arm/Bv9ARM.ch10.html create mode 100644 doc/arm/Bv9ARM.html create mode 100755 doc/arm/Bv9ARM.pdf create mode 100644 doc/arm/Makefile.in create mode 100644 doc/arm/README-SGML create mode 100644 doc/arm/isc-logo.eps create mode 100644 doc/arm/isc-logo.pdf create mode 100644 doc/arm/latex-fixup.pl create mode 100644 doc/arm/man.dig.html create mode 100644 doc/arm/man.dnssec-dsfromkey.html create mode 100644 doc/arm/man.dnssec-keyfromlabel.html create mode 100644 doc/arm/man.dnssec-keygen.html create mode 100644 doc/arm/man.dnssec-signzone.html create mode 100644 doc/arm/man.host.html create mode 100644 doc/arm/man.named-checkconf.html create mode 100644 doc/arm/man.named-checkzone.html create mode 100644 doc/arm/man.named.html create mode 100644 doc/arm/man.nsupdate.html create mode 100644 doc/arm/man.rndc-confgen.html create mode 100644 doc/arm/man.rndc.conf.html create mode 100644 doc/arm/man.rndc.html create mode 100644 doc/doxygen/Doxyfile.in create mode 100644 doc/doxygen/Makefile.in create mode 100644 doc/doxygen/doxygen-input-filter.in create mode 100644 doc/doxygen/isc-footer.html create mode 100644 doc/doxygen/isc-header.html create mode 100644 doc/doxygen/mainpage create mode 100644 doc/draft/draft-baba-dnsext-acl-reqts-01.txt create mode 100644 doc/draft/draft-daigle-napstr-04.txt create mode 100644 doc/draft/draft-danisch-dns-rr-smtp-03.txt create mode 100644 doc/draft/draft-dnsext-opcode-discover-02.txt create mode 100644 doc/draft/draft-durand-dnsop-dynreverse-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-2929bis-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt create mode 100644 doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-rsasha256-06.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-ds-sha256-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-ecc-key-07.txt create mode 100644 doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-interop3597-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt create mode 100644 doc/draft/draft-ietf-dnsext-mdns-46.txt create mode 100644 doc/draft/draft-ietf-dnsext-nsid-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2672bis-dname-13.txt create mode 100644 doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-tsig-sha-06.txt create mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt create mode 100644 doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt create mode 100644 doc/draft/draft-ietf-dnsop-default-local-zones-05.txt create mode 100644 doc/draft/draft-ietf-dnsop-inaddr-required-07.txt create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt create mode 100644 doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt create mode 100644 doc/draft/draft-ietf-dnsop-name-server-management-reqs-01.txt create mode 100644 doc/draft/draft-ietf-dnsop-respsize-06.txt create mode 100644 doc/draft/draft-ietf-dnsop-serverid-06.txt create mode 100644 doc/draft/draft-ietf-enum-e164-gstn-np-05.txt create mode 100644 doc/draft/draft-ietf-ipv6-node-requirements-08.txt create mode 100644 doc/draft/draft-ietf-secsh-dns-05.txt create mode 100644 doc/draft/draft-ihren-dnsext-threshold-validation-00.txt create mode 100644 doc/draft/draft-kato-dnsop-local-zones-00.txt create mode 100644 doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt create mode 100644 doc/draft/update create mode 100644 doc/misc/Makefile.in create mode 100644 doc/misc/dnssec create mode 100644 doc/misc/format-options.pl create mode 100644 doc/misc/ipv6 create mode 100644 doc/misc/migration create mode 100644 doc/misc/migration-4to9 create mode 100644 doc/misc/options create mode 100644 doc/misc/rfc-compliance create mode 100644 doc/misc/roadmap create mode 100644 doc/misc/sdb create mode 100644 doc/misc/sort-options.pl create mode 100755 doc/rfc/fetch create mode 100644 doc/rfc/index create mode 100644 doc/rfc/rfc1032.txt create mode 100644 doc/rfc/rfc1033.txt create mode 100644 doc/rfc/rfc1034.txt create mode 100644 doc/rfc/rfc1035.txt create mode 100644 doc/rfc/rfc1101.txt create mode 100644 doc/rfc/rfc1122.txt create mode 100644 doc/rfc/rfc1123.txt create mode 100644 doc/rfc/rfc1183.txt create mode 100644 doc/rfc/rfc1348.txt create mode 100644 doc/rfc/rfc1535.txt create mode 100644 doc/rfc/rfc1536.txt create mode 100644 doc/rfc/rfc1537.txt create mode 100644 doc/rfc/rfc1591.txt create mode 100644 doc/rfc/rfc1611.txt create mode 100644 doc/rfc/rfc1612.txt create mode 100644 doc/rfc/rfc1706.txt create mode 100644 doc/rfc/rfc1712.txt create mode 100644 doc/rfc/rfc1750.txt create mode 100644 doc/rfc/rfc1876.txt create mode 100644 doc/rfc/rfc1886.txt create mode 100644 doc/rfc/rfc1982.txt create mode 100644 doc/rfc/rfc1995.txt create mode 100644 doc/rfc/rfc1996.txt create mode 100644 doc/rfc/rfc2052.txt create mode 100644 doc/rfc/rfc2104.txt create mode 100644 doc/rfc/rfc2119.txt create mode 100644 doc/rfc/rfc2133.txt create mode 100644 doc/rfc/rfc2136.txt create mode 100644 doc/rfc/rfc2137.txt create mode 100644 doc/rfc/rfc2163.txt create mode 100644 doc/rfc/rfc2168.txt create mode 100644 doc/rfc/rfc2181.txt create mode 100644 doc/rfc/rfc2230.txt create mode 100644 doc/rfc/rfc2308.txt create mode 100644 doc/rfc/rfc2317.txt create mode 100644 doc/rfc/rfc2373.txt create mode 100644 doc/rfc/rfc2374.txt create mode 100644 doc/rfc/rfc2375.txt create mode 100644 doc/rfc/rfc2418.txt create mode 100644 doc/rfc/rfc2535.txt create mode 100644 doc/rfc/rfc2536.txt create mode 100644 doc/rfc/rfc2537.txt create mode 100644 doc/rfc/rfc2538.txt create mode 100644 doc/rfc/rfc2539.txt create mode 100644 doc/rfc/rfc2540.txt create mode 100644 doc/rfc/rfc2541.txt create mode 100644 doc/rfc/rfc2553.txt create mode 100644 doc/rfc/rfc2671.txt create mode 100644 doc/rfc/rfc2672.txt create mode 100644 doc/rfc/rfc2673.txt create mode 100644 doc/rfc/rfc2782.txt create mode 100644 doc/rfc/rfc2825.txt create mode 100644 doc/rfc/rfc2826.txt create mode 100644 doc/rfc/rfc2845.txt create mode 100644 doc/rfc/rfc2874.txt create mode 100644 doc/rfc/rfc2915.txt create mode 100644 doc/rfc/rfc2929.txt create mode 100644 doc/rfc/rfc2930.txt create mode 100644 doc/rfc/rfc2931.txt create mode 100644 doc/rfc/rfc3007.txt create mode 100644 doc/rfc/rfc3008.txt create mode 100644 doc/rfc/rfc3071.txt create mode 100644 doc/rfc/rfc3090.txt create mode 100644 doc/rfc/rfc3110.txt create mode 100644 doc/rfc/rfc3123.txt create mode 100644 doc/rfc/rfc3152.txt create mode 100644 doc/rfc/rfc3197.txt create mode 100644 doc/rfc/rfc3225.txt create mode 100644 doc/rfc/rfc3226.txt create mode 100644 doc/rfc/rfc3258.txt create mode 100644 doc/rfc/rfc3363.txt create mode 100644 doc/rfc/rfc3364.txt create mode 100644 doc/rfc/rfc3425.txt create mode 100644 doc/rfc/rfc3445.txt create mode 100644 doc/rfc/rfc3467.txt create mode 100644 doc/rfc/rfc3490.txt create mode 100644 doc/rfc/rfc3491.txt create mode 100644 doc/rfc/rfc3492.txt create mode 100644 doc/rfc/rfc3493.txt create mode 100644 doc/rfc/rfc3513.txt create mode 100644 doc/rfc/rfc3596.txt create mode 100644 doc/rfc/rfc3597.txt create mode 100644 doc/rfc/rfc3645.txt create mode 100644 doc/rfc/rfc3655.txt create mode 100644 doc/rfc/rfc3658.txt create mode 100644 doc/rfc/rfc3757.txt create mode 100644 doc/rfc/rfc3833.txt create mode 100644 doc/rfc/rfc3845.txt create mode 100644 doc/rfc/rfc3901.txt create mode 100644 doc/rfc/rfc4025.txt create mode 100644 doc/rfc/rfc4033.txt create mode 100644 doc/rfc/rfc4034.txt create mode 100644 doc/rfc/rfc4035.txt create mode 100644 doc/rfc/rfc4074.txt create mode 100644 doc/rfc/rfc4159.txt create mode 100644 doc/rfc/rfc4193.txt create mode 100644 doc/rfc/rfc4255.txt create mode 100644 doc/rfc/rfc4343.txt create mode 100644 doc/rfc/rfc4367.txt create mode 100644 doc/rfc/rfc4398.txt create mode 100644 doc/rfc/rfc4408.txt create mode 100644 doc/rfc/rfc4431.txt create mode 100644 doc/rfc/rfc4470.txt create mode 100644 doc/rfc/rfc4634.txt create mode 100644 doc/rfc/rfc4641.txt create mode 100644 doc/rfc/rfc4648.txt create mode 100644 doc/rfc/rfc4701.txt create mode 100644 doc/rfc/rfc5155.txt create mode 100644 doc/rfc/rfc952.txt create mode 100644 doc/xsl/Makefile.in create mode 100644 doc/xsl/copyright.xsl create mode 100644 doc/xsl/isc-docbook-chunk.xsl.in create mode 100644 doc/xsl/isc-docbook-html.xsl.in create mode 100644 doc/xsl/isc-docbook-latex-mappings.xml create mode 100644 doc/xsl/isc-docbook-latex.xsl.in create mode 100644 doc/xsl/isc-docbook-text.xsl create mode 100644 doc/xsl/isc-manpage.xsl.in create mode 100644 doc/xsl/pre-latex.xsl (limited to 'doc') diff --git a/doc/Makefile.in b/doc/Makefile.in new file mode 100644 index 0000000..14d35bc --- /dev/null +++ b/doc/Makefile.in @@ -0,0 +1,29 @@ +# Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2000, 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.11 2007/06/19 23:47:13 tbox Exp $ + +# This Makefile is a placeholder. It exists merely to make +# sure that its directory gets created in the object directory +# tree when doing a build using separate object directories. + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +SUBDIRS = arm misc xsl doxygen +TARGETS = + +@BIND9_MAKE_RULES@ diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml new file mode 100644 index 0000000..8c17589 --- /dev/null +++ b/doc/arm/Bv9ARM-book.xml @@ -0,0 +1,14205 @@ +]> + + + + + BIND 9 Administrator Reference Manual + + + + 2004 + 2005 + 2006 + 2007 + 2008 + Internet Systems Consortium, Inc. ("ISC") + + + 2000 + 2001 + 2002 + 2003 + Internet Software Consortium. + + + + + Introduction + + The Internet Domain Name System (DNS) + consists of the syntax + to specify the names of entities in the Internet in a hierarchical + manner, the rules used for delegating authority over names, and the + system implementation that actually maps names to Internet + addresses. DNS data is maintained in a + group of distributed + hierarchical databases. + + + + Scope of Document + + + The Berkeley Internet Name Domain + (BIND) implements a + domain name server for a number of operating systems. This + document provides basic information about the installation and + care of the Internet Systems Consortium (ISC) + BIND version 9 software package for + system administrators. + + + + This version of the manual corresponds to BIND version 9.6. + + + + + Organization of This Document + + In this document, Section 1 introduces + the basic DNS and BIND concepts. Section 2 + describes resource requirements for running BIND in various + environments. Information in Section 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 + concepts that the system administrator may need for implementing + certain options. Section 5 + describes the BIND 9 lightweight + resolver. The contents of Section 6 are + organized as in a reference manual to aid in the ongoing + maintenance of the software. Section 7 addresses + security considerations, and + Section 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 + historic information related to BIND + and the Domain Name + System. + + + + Conventions Used in This Document + + + In this document, we use the following general typographic + conventions: + + + + + + + + + + + To describe: + + + + + We use the style: + + + + + + + a pathname, filename, URL, hostname, + mailing list name, or new term or concept + + + + + Fixed width + + + + + + + literal user + input + + + + + Fixed Width Bold + + + + + + + program output + + + + + Fixed Width + + + + + + + + + The following conventions are used in descriptions of the + BIND configuration file: + + + + + + + + To describe: + + + + + We use the style: + + + + + + + keywords + + + + + Fixed Width + + + + + + + variables + + + + + Fixed Width + + + + + + + Optional input + + + + + Text is enclosed in square brackets + + + + + + + + + + The Domain Name System (<acronym>DNS</acronym>) + + The purpose of this document is to explain the installation + and upkeep of the BIND (Berkeley Internet + Name Domain) software package, and we + begin by reviewing the fundamentals of the Domain Name System + (DNS) as they relate to BIND. + + + + DNS Fundamentals + + + The Domain Name System (DNS) is a hierarchical, distributed + database. It stores information for mapping Internet host names to + IP + addresses and vice versa, mail routing information, and other data + used by Internet applications. + + + + Clients look up information in the DNS by calling a + resolver library, which sends queries to one or + more name servers and interprets the responses. + The BIND 9 software distribution + contains a + name server, named, and a resolver + library, liblwres. The older + libbind resolver library is also available + from ISC as a separate download. + + + + 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, + called a domain, is given a label. The domain + name of the + node is the concatenation of all the labels on the path from the + node to the root node. This is represented + in written form as a string of labels listed from right to left and + separated by dots. A label need only be unique within its parent + domain. + + + + For example, a domain name for a host at the + company Example, Inc. could be + ourhost.example.com, + where com is the + top level domain to which + ourhost.example.com belongs, + example is + a subdomain of com, and + ourhost is the + name of the host. + + + + For administrative purposes, the name space is partitioned into + areas called zones, each starting at a node and + extending down to the leaf nodes or to nodes where other zones + start. + The data for each zone is stored in a name server, which answers queries about the zone using the + DNS protocol. + + + + The data associated with each domain name is stored in the + form of resource records (RRs). + Some of the supported resource record types are described in + . + + + + For more detailed information about the design of the DNS and + the DNS protocol, please refer to the standards documents listed in + . + + + + + Zones + + To properly operate a name server, it is important to understand + the difference between a zone + and a domain. + + + + As stated previously, a zone is a point of delegation in + the DNS tree. A zone consists of + those contiguous parts of the domain + tree for which a name server has complete information and over which + it has authority. It contains all domain names from a certain point + downward in the domain tree except those which are delegated to + other zones. A delegation point is marked by one or more + NS records in the + parent zone, which should be matched by equivalent NS records at + the root of the delegated zone. + + + + For instance, consider the example.com + domain which includes names + such as host.aaa.example.com and + host.bbb.example.com even though + the example.com zone includes + only delegations for the aaa.example.com and + bbb.example.com zones. A zone can + map + exactly to a single domain, but could also include only part of a + domain, the rest of which could be delegated to other + name servers. Every name in the DNS + tree is a + domain, even if it is + terminal, that is, has no + subdomains. Every subdomain is a domain and + every domain except the root is also a subdomain. The terminology is + not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 + to + gain a complete understanding of this difficult and subtle + topic. + + + + Though BIND is called a "domain name + server", + it deals primarily in terms of zones. The master and slave + declarations in the named.conf file + specify + zones, not domains. When you ask some other site if it is willing to + be a slave server for your domain, you are + actually asking for slave service for some collection of zones. + + + + + Authoritative Name Servers + + + Each zone is served by at least + one authoritative name server, + which contains the complete data for the zone. + To make the DNS tolerant of server and network failures, + most zones have two or more authoritative servers, on + different networks. + + + + Responses from authoritative servers have the "authoritative + answer" (AA) bit set in the response packets. This makes them + easy to identify when debugging DNS configurations using tools like + dig (). + + + + The Primary Master + + + The authoritative server where the master copy of the zone + data is maintained is called the + primary master server, or simply the + primary. Typically it loads the zone + contents from some local file edited by humans or perhaps + generated mechanically from some other local file which is + edited by humans. This file is called the + zone file or + master file. + + + + In some cases, however, the master file may not be edited + by humans at all, but may instead be the result of + dynamic update operations. + + + + + Slave Servers + + The other authoritative servers, the slave + servers (also known as secondary servers) + load + the zone contents from another server using a replication process + known as a zone transfer. Typically the data + are + transferred directly from the primary master, but it is also + possible + to transfer it from another slave. In other words, a slave server + may itself act as a master to a subordinate slave server. + + + + + Stealth Servers + + + Usually all of the zone's authoritative servers are listed in + NS records in the parent zone. These NS records constitute + a delegation of the zone from the parent. + The authoritative servers are also listed in the zone file itself, + at the top level or apex + of the zone. You can list servers in the zone's top-level NS + records that are not in the parent's NS delegation, but you cannot + list servers in the parent's delegation that are not present at + the zone's top level. + + + + A stealth server is a server that is + authoritative for a zone but is not listed in that zone's NS + records. Stealth servers can be used for keeping a local copy of + a + zone to speed up access to the zone's records or to make sure that + the + zone is available even if all the "official" servers for the zone + are + inaccessible. + + + + A configuration where the primary master server itself is a + stealth server is often referred to as a "hidden primary" + configuration. One use for this configuration is when the primary + master + is behind a firewall and therefore unable to communicate directly + with the outside world. + + + + + + + + Caching Name Servers + + + + + The resolver libraries provided by most operating systems are + stub resolvers, meaning that they are not + capable of + performing the full DNS resolution process by themselves by talking + directly to the authoritative servers. Instead, they rely on a + local + name server to perform the resolution on their behalf. Such a + server + is called a recursive name server; it performs + recursive lookups for local clients. + + + + To improve performance, recursive servers cache the results of + the lookups they perform. Since the processes of recursion and + caching are intimately connected, the terms + recursive server and + caching server are often used synonymously. + + + + The length of time for which a record may be retained in + the cache of a caching name server is controlled by the + Time To Live (TTL) field associated with each resource record. + + + + Forwarding + + + Even a caching name server does not necessarily perform + the complete recursive lookup itself. Instead, it can + forward some or all of the queries + that it cannot satisfy from its cache to another caching name + server, + commonly referred to as a forwarder. + + + + There may be one or more forwarders, + and they are queried in turn until the list is exhausted or an + answer + is found. Forwarders are typically used when you do not + wish all the servers at a given site to interact directly with the + rest of + the Internet servers. A typical scenario would involve a number + of internal DNS servers and an + Internet firewall. Servers unable + to pass packets through the firewall would forward to the server + that can do it, and that server would query the Internet DNS servers + on the internal server's behalf. + + + + + + + Name Servers in Multiple Roles + + + The BIND name server can + simultaneously act as + a master for some zones, a slave for other zones, and as a caching + (recursive) server for a set of local clients. + + + + However, since the functions of authoritative name service + and caching/recursive name service are logically separate, it is + often advantageous to run them on separate server machines. + + A server that only provides authoritative name service + (an authoritative-only server) can run with + recursion disabled, improving reliability and security. + + A server that is not authoritative for any zones and only provides + recursive service to local + clients (a caching-only server) + does not need to be reachable from the Internet at large and can + be placed inside a firewall. + + + + + + + + + <acronym>BIND</acronym> Resource Requirements + + + Hardware requirements + + + DNS hardware requirements have + traditionally been quite modest. + For many installations, servers that have been pensioned off from + active duty have performed admirably as DNS servers. + + + The DNSSEC features of BIND 9 + may prove to be quite + CPU intensive however, so organizations that make heavy use of these + features may wish to consider larger systems for these applications. + BIND 9 is fully multithreaded, allowing + full utilization of + multiprocessor systems for installations that need it. + + + + CPU Requirements + + CPU requirements for BIND 9 range from + i486-class machines + for serving of static zones without caching, to enterprise-class + machines if you intend to process many dynamic updates and DNSSEC + signed zones, serving many thousands of queries per second. + + + + + 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 + option can be used to limit the amount of memory used by the cache, + at the expense of reducing cache hit rates and causing more DNS + traffic. + Additionally, if additional section caching + () is enabled, + the max-acache-size option can be used to + limit the amount + of memory used by the mechanism. + It is still good practice to have enough memory to load + all zone and cache data into memory — unfortunately, the best + way + to determine this for a given installation is to watch the name server + in operation. After a few weeks the server process should reach + a relatively stable size where entries are expiring from the cache as + fast as they are being inserted. + + + + + + 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 + any second-level internal name servers query a main name server, which + has enough memory to build a large cache. This approach minimizes + the bandwidth used by external name lookups. The second alternative + is to set up second-level internal name servers to make queries + independently. + In this configuration, none of the individual machines needs to + have as much memory or CPU power as in the first alternative, but + this has the disadvantage of making many more external queries, + as none of the name servers share their cached data. + + + + + Supported Operating Systems + + ISC BIND 9 compiles and runs on a large + number + of Unix-like operating systems and on NT-derived versions of + Microsoft Windows such as Windows 2000 and Windows XP. For an + up-to-date + list of supported systems, see the README file in the top level + directory + of the BIND 9 source distribution. + + + + + + Name Server Configuration + + In this section we provide some suggested configurations along + with guidelines for their use. We suggest reasonable values for + certain option settings. + + + + Sample Configurations + + 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 + queries + from outside clients are refused using the allow-query + option. Alternatively, the same effect could be achieved using + suitable + firewall rules. + + + +// Two corporate subnets we wish to allow queries from. +acl corpnets { 192.168.4.0/24; 192.168.7.0/24; }; +options { + directory "/etc/namedb"; // Working directory + allow-query { corpnets; }; +}; +// Provide a reverse mapping for the loopback address 127.0.0.1 +zone "0.0.127.in-addr.arpa" { + type master; + file "localhost.rev"; + notify no; +}; + + + + + + An Authoritative-only Name Server + + This sample configuration is for an authoritative-only server + that is the master server for "example.com" + and a slave for the subdomain "eng.example.com". + + + +options { + directory "/etc/namedb"; // Working directory + allow-query-cache { none; }; // Do not allow access to cache + allow-query { any; }; // This is the default + recursion no; // Do not provide recursive service +}; + +// Provide a reverse mapping for the loopback address 127.0.0.1 +zone "0.0.127.in-addr.arpa" { + type master; + file "localhost.rev"; + notify no; +}; +// We are the master server for example.com +zone "example.com" { + type master; + file "example.com.db"; + // IP addresses of slave servers allowed to transfer example.com + allow-transfer { + 192.168.4.14; + 192.168.5.53; + }; +}; +// We are a slave server for eng.example.com +zone "eng.example.com" { + type slave; + file "eng.example.com.bk"; + // IP address of eng.example.com master server + masters { 192.168.4.12; }; +}; + + + + + + + Load Balancing + + + + A primitive form of load balancing can be achieved in + the DNS by using multiple records + (such as multiple A records) for one name. + + + + For example, if you have three WWW servers with network addresses + of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the + following means that clients will connect to each machine one third + of the time: + + + + + + + + + + + + + + Name + + + + + TTL + + + + + CLASS + + + + + TYPE + + + + + Resource Record (RR) Data + + + + + + + www + + + + + 600 + + + + + IN + + + + + A + + + + + 10.0.0.1 + + + + + + + + + + 600 + + + + + IN + + + + + A + + + + + 10.0.0.2 + + + + + + + + + + 600 + + + + + IN + + + + + A + + + + + 10.0.0.3 + + + + + + + + When a resolver queries for these records, BIND will rotate + them and respond to the query with the records in a different + order. In the example above, clients will randomly receive + records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients + will use the first record returned and discard the rest. + + + For more detail on ordering responses, check the + rrset-order substatement in the + options statement, see + . + + + + + + Name Server Operations + + + Tools for Use With the Name Server Daemon + + This section describes several indispensable diagnostic, + administrative and monitoring tools available to the system + administrator for controlling and debugging the name server + daemon. + + + Diagnostic Tools + + The dig, host, and + nslookup programs are all command + line tools + for manually querying name servers. They differ in style and + output format. + + + + + dig + + + The domain information groper (dig) + is the most versatile and complete of these lookup tools. + It has two modes: simple interactive + mode for a single query, and batch mode which executes a + query for + each in a list of several query lines. All query options are + accessible + from the command line. + + + dig + @server + domain + query-type + query-class + +query-option + -dig-option + %comment + + + The usual simple use of dig will take the form + + + dig @server domain query-type query-class + + + For more information and a list of available commands and + options, see the dig man + page. + + + + + + host + + + The host utility emphasizes + simplicity + and ease of use. By default, it converts + between host names and Internet addresses, but its + functionality + can be extended with the use of options. + + + host + -aCdlnrsTwv + -c class + -N ndots + -t type + -W timeout + -R retries + -m flag + -4 + -6 + hostname + server + + + For more information and a list of available commands and + options, see the host man + page. + + + + + + nslookup + + nslookup + has two modes: interactive and + non-interactive. Interactive mode allows the user to + query name servers for information about various + hosts and domains or to print a list of hosts in a + domain. Non-interactive mode is used to print just + the name and requested information for a host or + domain. + + + nslookup + -option + + host-to-find + - server + + + + Interactive mode is entered when no arguments are given (the + default name server will be used) or when the first argument + is a + hyphen (`-') and the second argument is the host name or + Internet address + of a name server. + + + Non-interactive mode is used when the name or Internet + address + of the host to be looked up is given as the first argument. + The + optional second argument specifies the host name or address + of a name server. + + + Due to its arcane user interface and frequently inconsistent + behavior, we do not recommend the use of nslookup. + Use dig instead. + + + + + + + + + Administrative Tools + + Administrative tools play an integral part in the management + of a server. + + + + + named-checkconf + + + The named-checkconf program + checks the syntax of a named.conf file. + + + named-checkconf + -jvz + -t directory + filename + + + + + + named-checkzone + + + The named-checkzone program + checks a master file for + syntax and consistency. + + + named-checkzone + -djqvD + -c class + -o output + -t directory + -w directory + -k (ignore|warn|fail) + -n (ignore|warn|fail) + -W (ignore|warn) + zone + filename + + + + + named-compilezone + + + Similar to named-checkzone, but + it always dumps the zone content to a specified file + (typically in a different format). + + + + + + rndc + + + The remote name daemon control + (rndc) program allows the + system + administrator to control the operation of a name server. + Since BIND 9.2, rndc + supports all the commands of the BIND 8 ndc + utility except ndc start and + ndc restart, which were also + not supported in ndc's + channel mode. + If you run rndc without any + options + it will display a usage message as follows: + + + rndc + -c config + -s server + -p port + -y key + command + command + + The command + is one of the following: + + + + + + reload + + + Reload configuration file and zones. + + + + + + reload zone + class + view + + + Reload the given zone. + + + + + + refresh zone + class + view + + + Schedule zone maintenance for the given zone. + + + + + + retransfer zone + + class + view + + + Retransfer the given zone from the master. + + + + + + + freeze + zone + class + view + + + Suspend updates to a dynamic zone. If no zone is + specified, + then all zones are suspended. This allows manual + edits to be made to a zone normally updated by dynamic + update. It + also causes changes in the journal file to be synced + into the master + and the journal file to be removed. All dynamic + update attempts will + be refused while the zone is frozen. + + + + + + thaw + zone + class + view + + + Enable updates to a frozen dynamic zone. If no zone + is + specified, then all frozen zones are enabled. This + causes + the server to reload the zone from disk, and + re-enables dynamic updates + after the load has completed. After a zone is thawed, + dynamic updates + will no longer be refused. + + + + + + notify zone + class + view + + + Resend NOTIFY messages for the zone. + + + + + + reconfig + + + Reload the configuration file and load new zones, + but do not reload existing zone files even if they + have changed. + This is faster than a full reload when there + is a large number of zones because it avoids the need + to examine the + modification times of the zones files. + + + + + + stats + + + Write server statistics to the statistics file. + + + + + + querylog + + + Toggle query logging. Query logging can also be enabled + by explicitly directing the queries + category to a + channel in the + logging section of + named.conf or by specifying + querylog yes; in the + options section of + named.conf. + + + + + + dumpdb + -all|-cache|-zone + view ... + + + Dump the server's caches (default) and/or zones to + the + dump file for the specified views. If no view is + specified, all + views are dumped. + + + + + + stop -p + + + Stop the server, making sure any recent changes + made through dynamic update or IXFR are first saved to + the master files of the updated zones. + If -p is specified named's process id is returned. + This allows an external process to determine when named + had completed stopping. + + + + + + halt -p + + + Stop the server immediately. Recent changes + made through dynamic update or IXFR are not saved to + the master files, but will be rolled forward from the + journal files when the server is restarted. + If -p is specified named's process id is returned. + This allows an external process to determine when named + had completed halting. + + + + + + trace + + + Increment the servers debugging level by one. + + + + + + trace level + + + Sets the server's debugging level to an explicit + value. + + + + + + notrace + + + Sets the server's debugging level to 0. + + + + + + flush + + + Flushes the server's cache. + + + + + + flushname name + + + Flushes the given name from the server's cache. + + + + + + status + + + Display status of the server. + Note that the number of zones includes the internal bind/CH zone + and the default ./IN + hint zone if there is not an + explicit root zone configured. + + + + + + recursing + + + Dump the list of queries named is currently recursing + on. + + + + + + validation + on|off + view ... + + + + Enable or disable DNSSEC validation. + Note dnssec-enable also needs to be + set to yes to be effective. + It defaults to enabled. + + + + + + + + A configuration file is required, since all + communication with the server is authenticated with + digital signatures that rely on a shared secret, and + there is no way to provide that secret other than with a + configuration file. The default location for the + rndc configuration file is + /etc/rndc.conf, but an + alternate + location can be specified with the + option. If the configuration file is not found, + rndc will also look in + /etc/rndc.key (or whatever + sysconfdir was defined when + the BIND build was + configured). + The rndc.key file is + generated by + running rndc-confgen -a as + described in + . + + + + The format of the configuration file is similar to + that of named.conf, but + limited to + only four statements, the options, + key, server and + include + statements. These statements are what associate the + secret keys to the servers with which they are meant to + be shared. The order of statements is not + significant. + + + + The options statement has + three clauses: + default-server, default-key, + and default-port. + default-server takes a + host name or address argument and represents the server + that will + be contacted if no + option is provided on the command line. + default-key takes + the name of a key as its argument, as defined by a key statement. + default-port specifies the + port to which + rndc should connect if no + port is given on the command line or in a + server statement. + + + + The key statement defines a + key to be used + by rndc when authenticating + with + named. Its syntax is + identical to the + 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; + thus, + a string like "rndc_key" is a valid + name. + The key statement has two + clauses: + algorithm and secret. + While the configuration parser will accept any string as the + argument + to algorithm, currently only the string "hmac-md5" + has any meaning. The secret is a base-64 encoded string + as specified in RFC 3548. + + + + The server statement + associates a key + defined using the key + statement with a server. + The keyword server is followed by a + host name or address. The server statement + has two clauses: key and port. + The key clause specifies the + name of the key + to be used when communicating with this server, and the + port clause can be used to + specify the port rndc should + connect + to on the server. + + + + A sample minimal configuration file is as follows: + + + +key rndc_key { + algorithm "hmac-md5"; + secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; +}; +options { + default-server 127.0.0.1; + default-key rndc_key; +}; + + + + This file, if installed as /etc/rndc.conf, + would allow the command: + + + + $ rndc reload + + + + to connect to 127.0.0.1 port 953 and cause the name server + to reload, if a name server on the local machine were + running with + following controls statements: + + + +controls { + inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; +}; + + + + and it had an identical key statement for + rndc_key. + + + + Running the rndc-confgen + program will + conveniently create a rndc.conf + file for you, and also display the + corresponding controls + statement that you need to + add to named.conf. + Alternatively, + you can run rndc-confgen -a + to set up + a rndc.key file and not + modify + named.conf at all. + + + + + + + + + + + Signals + + Certain UNIX signals cause the name server to take specific + actions, as described in the following table. These signals can + be sent using the kill command. + + + + + + + + + SIGHUP + + + + Causes the server to read named.conf and + reload the database. + + + + + + SIGTERM + + + + Causes the server to clean up and exit. + + + + + + SIGINT + + + + Causes the server to clean up and exit. + + + + + + + + + + + + Advanced DNS Features + + + + Notify + + DNS NOTIFY is a mechanism that allows master + servers to notify their slave servers of changes to a zone's data. In + response to a NOTIFY from a master server, the + slave will check to see that its version of the zone is the + current version and, if not, initiate a zone transfer. + + + + For more information about DNS + NOTIFY, see the description of the + notify option in and + the description of the zone option also-notify in + . The NOTIFY + protocol is specified in RFC 1996. + + + + 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 + zones that it loads. + + + + + + Dynamic Update + + + Dynamic Update is a method for adding, replacing or deleting + records in a master server by sending it a special form of DNS + messages. The format and meaning of these messages is specified + in RFC 2136. + + + + Dynamic update is enabled by including an + allow-update or update-policy + clause in the zone statement. The + tkey-gssapi-credential and + tkey-domain clauses in the + options statement enable the + server to negotiate keys that can be matched against those + in update-policy or + allow-update. + + + + Updating of secure zones (zones using DNSSEC) follows RFC + 3007: RRSIG, NSEC and NSEC3 records affected by updates are + automatically regenerated by the server using an online + zone key. Update authorization is based on transaction + signatures and an explicit server policy. + + + + The journal file + + + All changes made to a zone using dynamic update are stored + in the zone's journal file. This file is automatically created + by the server when the first dynamic update takes place. + The name of the journal file is formed by appending the extension + .jnl to the name of the + corresponding zone + file unless specifically overridden. The journal file is in a + binary format and should not be edited manually. + + + + The server will also occasionally write ("dump") + the complete contents of the updated zone to its zone file. + This is not done immediately after + each dynamic update, because that would be too slow when a large + zone is updated frequently. Instead, the dump is delayed by + up to 15 minutes, allowing additional updates to take place. + + + + When a server is restarted after a shutdown or crash, it will replay + the journal file to incorporate into the zone any updates that + took + place after the last zone dump. + + + + Changes that result from incoming incremental zone transfers are + also + journalled in a similar way. + + + + The zone files of dynamic zones cannot normally be edited by + hand because they are not guaranteed to contain the most recent + dynamic changes — those are only in the journal file. + The only way to ensure that the zone file of a dynamic zone + is up to date is to run rndc stop. + + + + If you have to make changes to a dynamic zone + manually, the following procedure will work: Disable dynamic updates + to the zone using + rndc freeze zone. + This will also remove the zone's .jnl file + and update the master file. Edit the zone file. Run + rndc thaw zone + to reload the changed zone and re-enable dynamic updates. + + + + + + + + Incremental Zone Transfers (IXFR) + + + The incremental zone transfer (IXFR) protocol is a way for + slave servers to transfer only changed data, instead of having to + transfer the entire zone. The IXFR protocol is specified in RFC + 1995. See . + + + + When acting as a master, BIND 9 + supports IXFR for those zones + where the necessary change history information is available. These + include master zones maintained by dynamic update and slave zones + whose data was obtained by IXFR. For manually maintained master + zones, and for slave zones obtained by performing a full zone + transfer (AXFR), IXFR is supported only if the option + ixfr-from-differences is set + to yes. + + + + When acting as a slave, BIND 9 will + attempt to use IXFR unless + it is explicitly disabled. For more information about disabling + IXFR, see the description of the request-ixfr clause + of the server statement. + + + + + Split DNS + + Setting up different views, or visibility, of the DNS space to + internal and external resolvers is usually referred to as a + Split DNS setup. There are several + reasons an organization would want to set up its DNS this way. + + + One common reason for setting up a DNS system this way is + to hide "internal" DNS information from "external" clients on the + Internet. There is some debate as to whether or not this is actually + useful. + Internal DNS information leaks out in many ways (via email headers, + for example) and most savvy "attackers" can find the information + they need using other means. + However, since listing addresses of internal servers that + external clients cannot possibly reach can result in + connection delays and other annoyances, an organization may + choose to use a Split DNS to present a consistent view of itself + to the outside world. + + + Another common reason for setting up a Split DNS system is + to allow internal networks that are behind filters or in RFC 1918 + space (reserved IP space, as documented in RFC 1918) to resolve DNS + on the Internet. Split DNS can also be used to allow mail from outside + back in to the internal network. + + + Example split DNS setup + + Let's say a company named Example, Inc. + (example.com) + has several corporate sites that have an internal network with + reserved + Internet Protocol (IP) space and an external demilitarized zone (DMZ), + or "outside" section of a network, that is available to the public. + + + Example, Inc. wants its internal clients + to be able to resolve external hostnames and to exchange mail with + people on the outside. The company also wants its internal resolvers + to have access to certain internal-only zones that are not available + at all outside of the internal network. + + + In order to accomplish this, the company will set up two sets + of name servers. One set will be on the inside network (in the + reserved + IP space) and the other set will be on bastion hosts, which are + "proxy" + hosts that can talk to both sides of its network, in the DMZ. + + + The internal servers will be configured to forward all queries, + except queries for site1.internal, site2.internal, site1.example.com, + and site2.example.com, to the servers + in the + DMZ. These internal servers will have complete sets of information + for site1.example.com, site2.example.com, site1.internal, + and site2.internal. + + + To protect the site1.internal and site2.internal domains, + the internal name servers must be configured to disallow all queries + to these domains from any external hosts, including the bastion + hosts. + + + The external servers, which are on the bastion hosts, will + be configured to serve the "public" version of the site1 and site2.example.com zones. + This could include things such as the host records for public servers + (www.example.com and ftp.example.com), + and mail exchange (MX) records (a.mx.example.com and b.mx.example.com). + + + In addition, the public site1 and site2.example.com zones + should have special MX records that contain wildcard (`*') records + pointing to the bastion hosts. This is needed because external mail + servers do not have any other way of looking up how to deliver mail + to those internal hosts. With the wildcard records, the mail will + be delivered to the bastion host, which can then forward it on to + internal hosts. + + + Here's an example of a wildcard MX record: + + * IN MX 10 external1.example.com. + + Now that they accept mail on behalf of anything in the internal + network, the bastion hosts will need to know how to deliver mail + to internal hosts. In order for this to work properly, the resolvers + on + the bastion hosts will need to be configured to point to the internal + name servers for DNS resolution. + + + Queries for internal hostnames will be answered by the internal + servers, and queries for external hostnames will be forwarded back + out to the DNS servers on the bastion hosts. + + + In order for all this to work properly, internal clients will + need to be configured to query only the internal + name servers for DNS queries. This could also be enforced via + selective + filtering on the network. + + + If everything has been set properly, Example, Inc.'s + internal clients will now be able to: + + + + + Look up any hostnames in the site1 + and + site2.example.com zones. + + + + + Look up any hostnames in the site1.internal and + site2.internal domains. + + + + Look up any hostnames on the Internet. + + + Exchange mail with both internal and external people. + + + + Hosts on the Internet will be able to: + + + + + Look up any hostnames in the site1 + and + site2.example.com zones. + + + + + Exchange mail with anyone in the site1 and + site2.example.com zones. + + + + + + Here is an example configuration for the setup we just + described above. Note that this is only configuration information; + for information on how to configure your zone files, see . + + + + Internal DNS server config: + + + + +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { bastion-ips-go-here; }; + +options { + ... + ... + forward only; + forwarders { // forward to external servers + bastion-ips-go-here; + }; + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { internals; externals; }; // restrict query access + allow-recursion { internals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample master zone + type master; + file "m/site1.example.com"; + forwarders { }; // do normal iterative + // resolution (do not forward) + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site2.example.com" { // sample slave zone + type slave; + file "s/site2.example.com"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals; externals; }; + allow-transfer { internals; }; +}; + +zone "site1.internal" { + type master; + file "m/site1.internal"; + forwarders { }; + allow-query { internals; }; + allow-transfer { internals; } +}; + +zone "site2.internal" { + type slave; + file "s/site2.internal"; + masters { 172.16.72.3; }; + forwarders { }; + allow-query { internals }; + allow-transfer { internals; } +}; + + + + External (bastion host) DNS server config: + + + +acl internals { 172.16.72.0/24; 192.168.1.0/24; }; + +acl externals { bastion-ips-go-here; }; + +options { + ... + ... + allow-transfer { none; }; // sample allow-transfer (no one) + allow-query { any; }; // default query access + allow-query-cache { internals; externals; }; // restrict cache access + allow-recursion { internals; externals; }; // restrict recursion + ... + ... +}; + +zone "site1.example.com" { // sample slave zone + type master; + file "m/site1.foo.com"; + allow-transfer { internals; externals; }; +}; + +zone "site2.example.com" { + type slave; + file "s/site2.foo.com"; + masters { another_bastion_host_maybe; }; + allow-transfer { internals; externals; } +}; + + + + In the resolv.conf (or equivalent) on + the bastion host(s): + + + +search ... +nameserver 172.16.72.2 +nameserver 172.16.72.3 +nameserver 172.16.72.4 + + + + + + TSIG + + This is a short guide to setting up Transaction SIGnatures + (TSIG) based transaction security in BIND. It describes changes + to the configuration file as well as what changes are required for + different features, including the process of creating transaction + keys and using transaction signatures with BIND. + + + BIND primarily supports TSIG for server + to server communication. + This includes zone transfer, notify, and recursive query messages. + Resolvers based on newer versions of BIND 8 have limited support + for TSIG. + + + + TSIG can also be useful for dynamic update. A primary + server for a dynamic zone should control access to the dynamic + update service, but IP-based access control is insufficient. + The cryptographic access control provided by TSIG + is far superior. The nsupdate + program supports TSIG via the and + command line options or inline by use + of the key. + + + + 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 + be the same on both hosts. + + + 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 + are easier to read. Note that the maximum key length is 512 bits; + keys longer than that will be digested with MD5 to produce a + 128-bit key. + + + dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2. + + + The key is in the file Khost1-host2.+157+00000.private. + Nothing directly uses this file, but the base-64 encoded string + following "Key:" + can be extracted from the file and used as a shared secret: + + Key: La/E5CjG9O+os1jq0a2jdA== + + The string "La/E5CjG9O+os1jq0a2jdA==" can + be used as the shared secret. + + + + 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 + the length is a multiple of 4 and only valid characters are used), + so the shared secret can be manually generated. + + + Also, a known string can be run through mmencode or + a similar program to generate base-64 encoded data. + + + + + 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. + + + + Informing the Servers of the Key's Existence + + Imagine host1 and host 2 + are + both servers. The following is added to each server's named.conf file: + + + +key host1-host2. { + algorithm hmac-md5; + secret "La/E5CjG9O+os1jq0a2jdA=="; +}; + + + + 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 + file that is included by + named.conf. + + + At this point, the key is recognized. This means that if the + server receives a message signed by this key, it can verify the + signature. If the signature is successfully verified, the + response is signed by the same key. + + + + + 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 + for host1, if the IP address of host2 is + 10.1.2.3: + + + +server 10.1.2.3 { + keys { host1-host2. ;}; +}; + + + + Multiple keys may be present, but only the first is used. + This directive does not contain any secrets, so it may be in a + world-readable + file. + + + If host1 sends a message that is a request + to that address, the message will be signed with the specified key. host1 will + expect any responses to signed messages to be signed with the same + key. + + + A similar statement must be present in host2's + configuration file (with host1's address) for host2 to + sign request messages to host1. + + + + TSIG Key Based Access Control + + BIND allows IP addresses and ranges + to be specified in ACL + definitions and + allow-{ query | transfer | update } + directives. + This has been extended to allow TSIG keys also. The above key would + be denoted key host1-host2. + + + An example of an allow-update directive would be: + + + +allow-update { key host1-host2. ;}; + + + + This allows dynamic updates to succeed only if the request + was signed by a key named "host1-host2.". + + + + You may want to read about the more powerful + update-policy statement in + . + + + + + Errors + + + The processing of TSIG signed messages can result in + several errors. If a signed message is sent to a non-TSIG aware + server, a FORMERR (format error) will be returned, since the server will not + understand the record. This is a result of misconfiguration, + since the server must be explicitly configured to send a TSIG + signed message to a specific server. + + + + If a TSIG aware server receives a message signed by an + unknown key, the response will be unsigned with the TSIG + extended error code set to BADKEY. If a TSIG aware server + receives a message with a signature that does not validate, the + response will be unsigned with the TSIG extended error code set + to BADSIG. If a TSIG aware server receives a message with a time + outside of the allowed range, the response will be signed with + the TSIG extended error code set to BADTIME, and the time values + will be adjusted so that the response can be successfully + verified. In any of these cases, the message's rcode (response code) is set to + NOTAUTH (not authenticated). + + + + + + TKEY + + TKEY + is a mechanism for automatically generating a shared secret + between two hosts. There are several "modes" of + TKEY that specify how the key is generated + or assigned. BIND 9 implements only one of + these modes, the Diffie-Hellman key exchange. Both hosts are + required to have a Diffie-Hellman KEY record (although this + record is not required to be present in a zone). The + TKEY process must use signed messages, + signed either by TSIG or SIG(0). The result of + TKEY is a shared secret that can be used to + sign messages with TSIG. TKEY can also be + used to delete shared secrets that it had previously + generated. + + + + The TKEY process is initiated by a + client + or server by sending a signed TKEY + query + (including any appropriate KEYs) to a TKEY-aware server. The + server response, if it indicates success, will contain a + TKEY record and any appropriate keys. + After + this exchange, both participants have enough information to + determine the shared secret; the exact process depends on the + TKEY mode. When using the + Diffie-Hellman + TKEY mode, Diffie-Hellman keys are + exchanged, + and the shared secret is derived by both participants. + + + + + SIG(0) + + + BIND 9 partially supports DNSSEC SIG(0) + transaction signatures as specified in RFC 2535 and RFC2931. + SIG(0) + uses public/private keys to authenticate messages. Access control + is performed in the same manner as TSIG keys; privileges can be + granted or denied based on the key name. + + + + When a SIG(0) signed message is received, it will only be + verified if the key is known and trusted by the server; the server + will not attempt to locate and/or validate the key. + + + + SIG(0) signing of multiple-message TCP streams is not + supported. + + + + The only tool shipped with BIND 9 that + generates SIG(0) signed messages is nsupdate. + + + + + DNSSEC + + + Cryptographic authentication of DNS information is possible + through the DNS Security (DNSSEC-bis) extensions, + defined in RFC 4033, RFC 4034, and RFC 4035. + This section describes the creation and use of DNSSEC signed zones. + + + + In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. BIND + 9 ships + with several tools + that are used in this process, which are explained in more detail + below. In all cases, the option prints a + full list of parameters. Note that the DNSSEC tools require the + keyset files to be in the working directory or the + directory specified by the option, and + that the tools shipped with BIND 9.2.x and earlier are not compatible + with the current ones. + + + + There must also be communication with the administrators of + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presence + or absence of a DS record at the + delegation + point. + + + + For other servers to trust data in this zone, they must + either be statically configured with this zone's zone key or the + zone key of another zone above this one in the DNS tree. + + + + Generating Keys + + + The dnssec-keygen program is used to + generate keys. + + + + A secure zone must contain one or more zone keys. The + zone keys will sign all other records in the zone, as well as + the zone keys of any secure delegated zones. Zone keys must + have the same name as the zone, a name type of + ZONE, and must be usable for + authentication. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + the only one is RSASHA1. + + + + The following command will generate a 768-bit RSASHA1 key for + the child.example zone: + + + + dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example. + + + + Two output files will be produced: + Kchild.example.+005+12345.key and + Kchild.example.+005+12345.private + (where + 12345 is an example of a key tag). The key filenames contain + the key name (child.example.), + algorithm (3 + is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in + this case). + The private key (in the .private + file) is + used to generate signatures, and the public key (in the + .key file) is used for signature + verification. + + + + To generate another key with the same properties (but with + a different key tag), repeat the above command. + + + + The dnssec-keyfromlabel program is used + to get a key pair from a crypto hardware and build the key + files. Its usage is similar to dnssec-keygen. + + + + The public keys should be inserted into the zone file by + including the .key files using + $INCLUDE statements. + + + + + Signing the Zone + + + The dnssec-signzone program is used + to sign a zone. + + + + Any keyset files corresponding to + secure subzones should be present. The zone signer will + generate NSEC, NSEC3 + and RRSIG records for the zone, as + well as DS for the child zones if + '-g' is specified. If '-g' + is not specified, then DS RRsets for the secure child + zones need to be added manually. + + + + The following command signs the zone, assuming it is in a + file called zone.child.example. By + default, all zone keys which have an available private key are + used to generate signatures. + + + + dnssec-signzone -o child.example zone.child.example + + + + One output file is produced: + zone.child.example.signed. This + file + should be referenced by named.conf + as the + input file for the zone. + + + dnssec-signzone + will also produce a keyset and dsset files and optionally a + dlvset file. These are used to provide the parent zone + administrators with the DNSKEYs (or their + corresponding DS records) that are the + secure entry point to the zone. + + + + + + Configuring Servers + + + To enable named to respond appropriately + to DNS requests from DNSSEC aware clients, + dnssec-enable must be set to yes. + + + + To enable named to validate answers from + other servers both dnssec-enable and + dnssec-validation must be set and some + trusted-keys must be configured + into named.conf. + + + + trusted-keys are copies of DNSKEY RRs + for zones that are used to form the first link in the + cryptographic chain of trust. All keys listed in + trusted-keys (and corresponding zones) + are deemed to exist and only the listed keys will be used + to validated the DNSKEY RRset that they are from. + + + + trusted-keys are described in more detail + later in this document. + + + + Unlike BIND 8, BIND + 9 does not verify signatures on load, so zone keys for + authoritative zones do not need to be specified in the + configuration file. + + + + After DNSSEC gets established, a typical DNSSEC configuration + will look something like the following. It has a one or + more public keys for the root. This allows answers from + outside the organization to be validated. It will also + have several keys for parts of the namespace the organization + controls. These are here to ensure that named is immune + to compromises in the DNSSEC components of the security + of parent zones. + + + +trusted-keys { + + /* Root Key */ +"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/ + E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3 + zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz + MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M + /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M + iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI + Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3"; + +/* Key for our organization's forward zone */ +example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe + 3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb + OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC + lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt + 8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b + iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn + SCThlHf3xiYleDbt/o1OTQ09A0="; + +/* Key for our reverse zone. */ +2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA + VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0 + tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0 + yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ + 4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06 + zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL + 7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD + 52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib"; +}; + +options { + ... + dnssec-enable yes; + dnssec-validation yes; +}; + + + + None of the keys listed in this example are valid. In particular, + the root key is not valid. + + + + + + + IPv6 Support in <acronym>BIND</acronym> 9 + + + BIND 9 fully supports all currently + defined forms of IPv6 + name to address and address to name lookups. It will also use + IPv6 addresses to make queries when running on an IPv6 capable + system. + + + + For forward lookups, BIND 9 supports + only AAAA records. RFC 3363 deprecated the use of A6 records, + and client-side support for A6 records was accordingly removed + from BIND 9. + However, authoritative BIND 9 name servers still + load zone files containing A6 records correctly, answer queries + for A6 records, and accept zone transfer for a zone containing A6 + records. + + + + For IPv6 reverse lookups, BIND 9 supports + the traditional "nibble" format used in the + ip6.arpa domain, as well as the older, deprecated + ip6.int domain. + Older versions of BIND 9 + supported the "binary label" (also known as "bitstring") format, + but support of binary labels has been completely removed per + RFC 3363. + Many applications in BIND 9 do not understand + the binary label format at all any more, and will return an + error if given. + In particular, an authoritative BIND 9 + name server will not load a zone file containing binary labels. + + + + For an overview of the format and structure of IPv6 addresses, + see . + + + + 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 + IPv6 address in a single record. For example, + + + +$ORIGIN example.com. +host 3600 IN AAAA 2001:db8::1 + + + + Use of IPv4-in-IPv6 mapped addresses is not recommended. + If a host has an IPv4 address, use an A record, not + a AAAA, with ::ffff:192.168.42.1 as + the address. + + + + 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 + ip6.arpa. is appended to the + resulting name. + For example, the following would provide reverse name lookup for + a host with address + 2001:db8::1. + + + +$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. +1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR host.example.com. + + + + + + + + The <acronym>BIND</acronym> 9 Lightweight Resolver + + The Lightweight Resolver Library + + Traditionally applications have been linked with a stub resolver + library that sends recursive DNS queries to a local caching name + server. + + + IPv6 once introduced new complexity into the resolution process, + such as following A6 chains and DNAME records, and simultaneous + lookup of IPv4 and IPv6 addresses. Though most of the complexity was + then removed, these are hard or impossible + to implement in a traditional stub resolver. + + + BIND 9 therefore can also provide resolution + services to local clients + using a combination of a lightweight resolver library and a resolver + daemon process running on the local host. These communicate using + a simple UDP-based protocol, the "lightweight resolver protocol" + that is distinct from and simpler than the full DNS protocol. + + + + Running a Resolver Daemon + + + To use the lightweight resolver interface, the system must + run the resolver daemon lwresd or a + local + name server configured with a lwres + statement. + + + + By default, applications using the lightweight resolver library will + make + UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. + The + address can be overridden by lwserver + lines in + /etc/resolv.conf. + + + + The daemon currently only looks in the DNS, but in the future + it may use other sources such as /etc/hosts, + NIS, etc. + + + + The lwresd daemon is essentially a + caching-only name server that responds to requests using the + lightweight + resolver protocol rather than the DNS protocol. Because it needs + to run on each host, it is designed to require no or minimal + configuration. + Unless configured otherwise, it uses the name servers listed on + nameserver lines in /etc/resolv.conf + as forwarders, but is also capable of doing the resolution + autonomously if + none are specified. + + + The lwresd daemon may also be + configured with a + named.conf style configuration file, + in + /etc/lwresd.conf by default. A name + server may also + be configured to act as a lightweight resolver daemon using the + lwres statement in named.conf. + + + + + + + <acronym>BIND</acronym> 9 Configuration Reference + + + BIND 9 configuration is broadly similar + to BIND 8; however, there are a few new + areas + of configuration, such as views. BIND + 8 configuration files should work with few alterations in BIND + 9, although more complex configurations should be reviewed to check + if they can be more efficiently implemented using the new features + found in BIND 9. + + + + BIND 4 configuration files can be + converted to the new format + using the shell script + contrib/named-bootconf/named-bootconf.sh. + + + Configuration File Elements + + Following is a list of elements used throughout the BIND configuration + file documentation: + + + + + + + + + + acl_name + + + + + The name of an address_match_list as + defined by the acl statement. + + + + + + + address_match_list + + + + + A list of one or more + ip_addr, + ip_prefix, key_id, + or acl_name elements, see + . + + + + + + + masters_list + + + + + A named list of one or more ip_addr + with optional key_id and/or + ip_port. + A masters_list may include other + masters_lists. + + + + + + + domain_name + + + + + A quoted string which will be used as + a DNS name, for example "my.test.domain". + + + + + + + dotted_decimal + + + + + One to four integers valued 0 through + 255 separated by dots (`.'), such as 123, + 45.67 or 89.123.45.67. + + + + + + + ip4_addr + + + + + An IPv4 address with exactly four elements + in dotted_decimal notation. + + + + + + + ip6_addr + + + + + An IPv6 address, such as 2001:db8::1234. + IPv6 scoped addresses that have ambiguity on their + scope zones must be disambiguated by an appropriate + zone ID with the percent character (`%') as + delimiter. It is strongly recommended to use + string zone names rather than numeric identifiers, + in order to be robust against system configuration + changes. However, since there is no standard + mapping for such names and identifier values, + currently only interface names as link identifiers + are supported, assuming one-to-one mapping between + interfaces and links. For example, a link-local + address fe80::1 on the link + attached to the interface ne0 + can be specified as fe80::1%ne0. + Note that on most systems link-local addresses + always have the ambiguity, and need to be + disambiguated. + + + + + + + ip_addr + + + + + An ip4_addr or ip6_addr. + + + + + + + ip_port + + + + + An IP port number. + The number is limited to 0 + through 65535, with values + below 1024 typically restricted to use by processes running + as root. + In some cases, an asterisk (`*') character can be used as a + placeholder to + select a random high-numbered port. + + + + + + + ip_prefix + + + + + An IP network specified as an ip_addr, + followed by a slash (`/') and then the number of bits in the + netmask. + Trailing zeros in a ip_addr + may omitted. + For example, 127/8 is the + network 127.0.0.0 with + netmask 255.0.0.0 and 1.2.3.0/28 is + network 1.2.3.0 with netmask 255.255.255.240. + + + When specifying a prefix involving a IPv6 scoped address + the scope may be omitted. In that case the prefix will + match packets from any scope. + + + + + + + key_id + + + + + A domain_name representing + the name of a shared key, to be used for transaction + security. + + + + + + + key_list + + + + + A list of one or more + key_ids, + separated by semicolons and ending with a semicolon. + + + + + + + number + + + + + A non-negative 32-bit integer + (i.e., a number between 0 and 4294967295, inclusive). + Its acceptable value might further + be limited by the context in which it is used. + + + + + + + path_name + + + + + A quoted string which will be used as + a pathname, such as zones/master/my.test.domain. + + + + + + + port_list + + + + + A list of an ip_port or a port + range. + A port range is specified in the form of + range followed by + two ip_ports, + port_low and + port_high, which represents + port numbers from port_low through + port_high, inclusive. + port_low must not be larger than + port_high. + For example, + range 1024 65535 represents + ports from 1024 through 65535. + In either case an asterisk (`*') character is not + allowed as a valid ip_port. + + + + + + + size_spec + + + + + A number, the word unlimited, + or the word default. + + + An unlimited size_spec requests unlimited + use, or the maximum available amount. A default size_spec uses + the limit that was in force when the server was started. + + + A number can optionally be + followed by a scaling factor: + K or k + for kilobytes, + M or m + for megabytes, and + G or g for gigabytes, + which scale by 1024, 1024*1024, and 1024*1024*1024 + respectively. + + + The value must be representable as a 64-bit unsigned integer + (0 to 18446744073709551615, inclusive). + Using unlimited is the best + way + to safely set a really large number. + + + + + + + yes_or_no + + + + + Either yes or no. + The words true and false are + also accepted, as are the numbers 1 + and 0. + + + + + + + dialup_option + + + + + One of yes, + no, notify, + notify-passive, refresh or + passive. + When used in a zone, notify-passive, + refresh, and passive + are restricted to slave and stub zones. + + + + + + + + Address Match Lists + + Syntax + +address_match_list = address_match_list_element ; + address_match_list_element; ... +address_match_list_element = ! (ip_address /length | + key key_id | acl_name | { address_match_list } ) + + + + + Definition and Usage + + Address match lists are primarily used to determine access + control for various server operations. They are also used in + the listen-on and sortlist + statements. The elements which constitute an address match + list can be any of the following: + + + + an IP address (IPv4 or IPv6) + + + an IP prefix (in `/' notation) + + + + a key ID, as defined by the key + statement + + + + the name of an address match list defined with + the acl statement + + + + a nested address match list enclosed in braces + + + + + Elements can be negated with a leading exclamation mark (`!'), + and the match list names "any", "none", "localhost", and + "localnets" are predefined. More information on those names + can be found in the description of the acl statement. + + + + The addition of the key clause made the name of this syntactic + element something of a misnomer, since security keys can be used + to validate access without regard to a host or network address. + Nonetheless, the term "address match list" is still used + throughout the documentation. + + + + When a given IP address or prefix is compared to an address + match list, the comparison takes place in approximately O(1) + time. However, key comparisons require that the list of keys + be traversed until a matching key is found, and therefore may + be somewhat slower. + + + + The interpretation of a match depends on whether the list is being + used for access control, defining listen-on ports, or in a + sortlist, and whether the element was negated. + + + + When used as an access control list, a non-negated match + allows access and a negated match denies access. If + there is no match, access is denied. The clauses + allow-notify, + allow-recursion, + allow-recursion-on, + allow-query, + allow-query-on, + allow-query-cache, + allow-query-cache-on, + allow-transfer, + allow-update, + allow-update-forwarding, and + blackhole all use address match + lists. Similarly, the listen-on option will cause the + server to refuse queries on any of the machine's + addresses which do not match the list. + + + + Order of insertion is significant. If more than one element + in an ACL is found to match a given IP address or prefix, + preference will be given to the one that came + first in the ACL definition. + Because of this first-match behavior, an element that + defines a subset of another element in the list should + come before the broader element, regardless of whether + either is negated. For example, in + 1.2.3/24; ! 1.2.3.13; + the 1.2.3.13 element is completely useless because the + algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 + element. Using ! 1.2.3.13; 1.2.3/24 fixes + that problem by having 1.2.3.13 blocked by the negation, but + all other 1.2.3.* hosts fall through. + + + + + + Comment Syntax + + + The BIND 9 comment syntax allows for + comments to appear + anywhere that whitespace may appear in a BIND configuration + file. To appeal to programmers of all kinds, they can be written + in the C, C++, or shell/perl style. + + + + Syntax + + + /* This is a BIND comment as in C */ + // This is a BIND comment as in C++ + # This is a BIND comment as in common UNIX shells and perl + + + + Definition and Usage + + Comments may appear anywhere that whitespace may appear in + a BIND configuration file. + + + C-style comments start with the two characters /* (slash, + star) and end with */ (star, slash). Because they are completely + delimited with these characters, they can be used to comment only + a portion of a line or to span multiple lines. + + + C-style comments cannot be nested. For example, the following + is not valid because the entire comment ends with the first */: + + + +/* This is the start of a comment. + This is still part of the comment. +/* This is an incorrect attempt at nesting a comment. */ + This is no longer in any comment. */ + + + + + + C++-style comments start with the two characters // (slash, + slash) and continue to the end of the physical line. They cannot + be continued across multiple physical lines; to have one logical + comment span multiple lines, each line must use the // pair. + + + For example: + + + +// This is the start of a comment. The next line +// is a new comment, even though it is logically +// part of the previous comment. + + + + + Shell-style (or perl-style, if you prefer) comments start + with the character # (number sign) + and continue to the end of the + physical line, as in C++ comments. + + + For example: + + + + +# This is the start of a comment. The next line +# is a new comment, even though it is logically +# part of the previous comment. + + + + + + + You cannot use the semicolon (`;') character + to start a comment such as you would in a zone file. The + semicolon indicates the end of a configuration + statement. + + + + + + + + Configuration File Grammar + + + A BIND 9 configuration consists of + statements and comments. + Statements end with a semicolon. Statements and comments are the + only elements that can appear without enclosing braces. Many + statements contain a block of sub-statements, which are also + terminated with a semicolon. + + + + The following statements are supported: + + + + + + + + + + acl + + + + defines a named IP address + matching list, for access control and other uses. + + + + + + controls + + + + declares control channels to be used + by the rndc utility. + + + + + + include + + + + includes a file. + + + + + + key + + + + specifies key information for use in + authentication and authorization using TSIG. + + + + + + logging + + + + specifies what the server logs, and where + the log messages are sent. + + + + + + lwres + + + + configures named to + also act as a light-weight resolver daemon (lwresd). + + + + + + masters + + + + defines a named masters list for + inclusion in stub and slave zone masters clauses. + + + + + + options + + + + controls global server configuration + options and sets defaults for other statements. + + + + + + statistics-channels + + + + declares communication channels to get access to + named statistics. + + + + + + server + + + + sets certain configuration options on + a per-server basis. + + + + + + trusted-keys + + + + defines trusted DNSSEC keys. + + + + + + view + + + + defines a view. + + + + + + zone + + + + defines a zone. + + + + + + + + + The logging and + options statements may only occur once + per + configuration. + + + + <command>acl</command> Statement Grammar + +acl acl-name { + address_match_list +}; + + + + + <command>acl</command> Statement Definition and + Usage + + + The acl statement assigns a symbolic + name to an address match list. It gets its name from a primary + use of address match lists: Access Control Lists (ACLs). + + + + Note that an address match list's name must be defined + with acl before it can be used + elsewhere; no forward references are allowed. + + + + The following ACLs are built-in: + + + + + + + + + + any + + + + Matches all hosts. + + + + + + none + + + + Matches no hosts. + + + + + + localhost + + + + Matches the IPv4 and IPv6 addresses of all network + interfaces on the system. + + + + + + localnets + + + + Matches any host on an IPv4 or IPv6 network + for which the system has an interface. + Some systems do not provide a way to determine the prefix + lengths of + local IPv6 addresses. + In such a case, localnets + only matches the local + IPv6 addresses, just like localhost. + + + + + + + + + + <command>controls</command> Statement Grammar + +controls { + [ inet ( ip_addr | * ) [ port ip_port ] allow { address_match_list } + keys { key_list }; ] + [ inet ...; ] + [ unix path perm number owner number group number keys { key_list }; ] + [ unix ...; ] +}; + + + + + + <command>controls</command> Statement Definition and + Usage + + + The controls statement declares control + channels to be used by system administrators to control the + operation of the name server. These control channels are + used by the rndc utility to send + commands to and retrieve non-DNS results from a name server. + + + + An inet control channel is a TCP socket + listening at the specified ip_port on the + specified ip_addr, which can be an IPv4 or IPv6 + address. An ip_addr of * (asterisk) is + interpreted as the IPv4 wildcard address; connections will be + accepted on any of the system's IPv4 addresses. + To listen on the IPv6 wildcard address, + use an ip_addr of ::. + If you will only use rndc on the local host, + using the loopback address (127.0.0.1 + or ::1) is recommended for maximum security. + + + + If no port is specified, port 953 is used. The asterisk + "*" cannot be used for ip_port. + + + + The ability to issue commands over the control channel is + restricted by the allow and + keys clauses. + Connections to the control channel are permitted based on the + address_match_list. This is for simple + IP address based filtering only; any key_id + elements of the address_match_list + are ignored. + + + + A unix control channel is a UNIX domain + socket listening at the specified path in the file system. + Access to the socket is specified by the perm, + owner and group clauses. + Note on some platforms (SunOS and Solaris) the permissions + (perm) are applied to the parent directory + as the permissions on the socket itself are ignored. + + + + The primary authorization mechanism of the command + channel is the key_list, which + contains a list of key_ids. + Each key_id in the key_list + is authorized to execute commands over the control channel. + See in ) + for information about configuring keys in rndc. + + + + If no controls statement is present, + named will set up a default + control channel listening on the loopback address 127.0.0.1 + and its IPv6 counterpart ::1. + In this case, and also when the controls statement + is present but does not have a keys clause, + named will attempt to load the command channel key + from the file rndc.key in + /etc (or whatever sysconfdir + was specified as when BIND was built). + To create a rndc.key file, run + rndc-confgen -a. + + + + The rndc.key feature was created to + ease the transition of systems from BIND 8, + which did not have digital signatures on its command channel + messages and thus did not have a keys clause. + + It makes it possible to use an existing BIND 8 + configuration file in BIND 9 unchanged, + and still have rndc work the same way + ndc worked in BIND 8, simply by executing the + command rndc-confgen -a after BIND 9 is + installed. + + + + Since the rndc.key feature + is only intended to allow the backward-compatible usage of + BIND 8 configuration files, this + feature does not + have a high degree of configurability. You cannot easily change + the key name or the size of the secret, so you should make a + rndc.conf with your own key if you + wish to change + those things. The rndc.key file + also has its + permissions set such that only the owner of the file (the user that + named is running as) can access it. + If you + desire greater flexibility in allowing other users to access + rndc commands, then you need to create + a + rndc.conf file and make it group + readable by a group + that contains the users who should have access. + + + + To disable the command channel, use an empty + controls statement: + controls { };. + + + + + <command>include</command> Statement Grammar + include filename; + + + <command>include</command> Statement Definition and + Usage + + + The include statement inserts the + specified file at the point where the include + statement is encountered. The include + statement facilitates the administration of configuration + files + by permitting the reading or writing of some things but not + others. For example, the statement could include private keys + that are readable only by the name server. + + + + + <command>key</command> Statement Grammar + +key key_id { + algorithm string; + secret string; +}; + + + + + + <command>key</command> Statement Definition and Usage + + + The key statement defines a shared + secret key for use with TSIG (see ) + or the command channel + (see ). + + + + The key statement can occur at the + top level + of the configuration file or inside a view + statement. Keys defined in top-level key + statements can be used in all views. Keys intended for use in + a controls statement + (see ) + must be defined at the top level. + + + + The key_id, also known as the + key name, is a domain name uniquely identifying the key. It can + be used in a server + statement to cause requests sent to that + server to be signed with this key, or in address match lists to + verify that incoming requests have been signed with a key + matching this name, algorithm, and secret. + + + + The algorithm_id is a string + that specifies a security/authentication algorithm. Named + supports hmac-md5, + hmac-sha1, hmac-sha224, + hmac-sha256, hmac-sha384 + and hmac-sha512 TSIG authentication. + Truncated hashes are supported by appending the minimum + number of required bits preceded by a dash, e.g. + hmac-sha1-80. The + secret_string is the secret + to be used by the algorithm, and is treated as a base-64 + encoded string. + + + + + <command>logging</command> Statement Grammar + +logging { + [ channel channel_name { + ( file path_name + [ versions ( number | unlimited ) ] + [ size size spec ] + | syslog syslog_facility + | stderr + | null ); + [ severity ( | | | | + | [ level ] | ); ] + [ print-category or ; ] + [ print-severity or ; ] + [ print-time or ; ] + }; ] + [ category category_name { + channel_name ; [ channel_name ; ... ] + }; ] + ... +}; + + + + + + <command>logging</command> Statement Definition and + Usage + + + The logging statement configures a + wide + variety of logging options for the name server. Its channel phrase + associates output methods, format options and severity levels with + a name that can then be used with the category phrase + to select how various classes of messages are logged. + + + Only one logging statement is used to + define + as many channels and categories as are wanted. If there is no logging statement, + the logging configuration will be: + + +logging { + category default { default_syslog; default_debug; }; + category unmatched { null; }; +}; + + + + In BIND 9, the logging configuration + is only established when + the entire configuration file has been parsed. In BIND 8, it was + established as soon as the logging + statement + was parsed. When the server is starting up, all logging messages + regarding syntax errors in the configuration file go to the default + channels, or to standard error if the "" option + was specified. + + + + The <command>channel</command> Phrase + + + All log output goes to one or more channels; + you can make as many of them as you want. + + + + Every channel definition must include a destination clause that + says whether messages selected for the channel go to a file, to a + particular syslog facility, to the standard error stream, or are + discarded. It can optionally also limit the message severity level + that will be accepted by the channel (the default is + info), and whether to include a + named-generated time stamp, the + category name + and/or severity level (the default is not to include any). + + + + The null destination clause + causes all messages sent to the channel to be discarded; + in that case, other options for the channel are meaningless. + + + + The file destination clause directs + the channel + to a disk file. It can include limitations + both on how large the file is allowed to become, and how many + versions + of the file will be saved each time the file is opened. + + + + If you use the versions log file + option, then + named will retain that many backup + versions of the file by + renaming them when opening. For example, if you choose to keep + three old versions + of the file lamers.log, then just + before it is opened + lamers.log.1 is renamed to + lamers.log.2, lamers.log.0 is renamed + to lamers.log.1, and lamers.log is + renamed to lamers.log.0. + You can say versions unlimited to + not limit + the number of versions. + If a size option is associated with + the log file, + then renaming is only done when the file being opened exceeds the + indicated size. No backup versions are kept by default; any + existing + log file is simply appended. + + + + The size option for files is used + to limit log + growth. If the file ever exceeds the size, then named will + stop writing to the file unless it has a versions option + associated with it. If backup versions are kept, the files are + rolled as + described above and a new one begun. If there is no + versions option, no more data will + be written to the log + until some out-of-band mechanism removes or truncates the log to + less than the + maximum size. The default behavior is not to limit the size of + the + file. + + + + Example usage of the size and + versions options: + + +channel an_example_channel { + file "example.log" versions 3 size 20m; + print-time yes; + print-category yes; +}; + + + + The syslog destination clause + directs the + channel to the system log. Its argument is a + syslog facility as described in the syslog man + page. Known facilities are kern, user, + mail, daemon, auth, + syslog, lpr, news, + uucp, cron, authpriv, + ftp, local0, local1, + local2, local3, local4, + local5, local6 and + local7, however not all facilities + are supported on + all operating systems. + How syslog will handle messages + sent to + this facility is described in the syslog.conf man + page. If you have a system which uses a very old version of syslog that + only uses two arguments to the openlog() function, + then this clause is silently ignored. + + + The severity clause works like syslog's + "priorities", except that they can also be used if you are writing + straight to a file rather than using syslog. + Messages which are not at least of the severity level given will + not be selected for the channel; messages of higher severity + levels + will be accepted. + + + If you are using syslog, then the syslog.conf priorities + will also determine what eventually passes through. For example, + defining a channel facility and severity as daemon and debug but + only logging daemon.warning via syslog.conf will + cause messages of severity info and + notice to + be dropped. If the situation were reversed, with named writing + messages of only warning or higher, + then syslogd would + print all messages it received from the channel. + + + + The stderr destination clause + directs the + channel to the server's standard error stream. This is intended + for + use when the server is running as a foreground process, for + example + when debugging a configuration. + + + + The server can supply extensive debugging information when + it is in debugging mode. If the server's global debug level is + greater + than zero, then debugging mode will be active. The global debug + level is set either by starting the named server + with the flag followed by a positive integer, + or by running rndc trace. + The global debug level + can be set to zero, and debugging mode turned off, by running rndc +notrace. All debugging messages in the server have a debug + level, and higher debug levels give more detailed output. Channels + that specify a specific debug severity, for example: + + +channel specific_debug_level { + file "foo"; + severity debug 3; +}; + + + + will get debugging output of level 3 or less any time the + server is in debugging mode, regardless of the global debugging + level. Channels with dynamic + severity use the + server's global debug level to determine what messages to print. + + + If print-time has been turned on, + then + the date and time will be logged. print-time may + be specified for a syslog channel, + but is usually + pointless since syslog also prints + the date and + time. If print-category is + requested, then the + category of the message will be logged as well. Finally, if print-severity is + on, then the severity level of the message will be logged. The print- options may + be used in any combination, and will always be printed in the + following + order: time, category, severity. Here is an example where all + three print- options + are on: + + + + 28-Feb-2000 15:05:32.863 general: notice: running + + + + There are four predefined channels that are used for + named's default logging as follows. + How they are + used is described in . + + +channel default_syslog { + syslog daemon; // send to syslog's daemon + // facility + severity info; // only send priority info + // and higher +}; + +channel default_debug { + file "named.run"; // write to named.run in + // the working directory + // Note: stderr is used instead + // of "named.run" + // if the server is started + // with the '-f' option. + severity dynamic; // log at the server's + // current debug level +}; + +channel default_stderr { + stderr; // writes to stderr + severity info; // only send priority info + // and higher +}; + +channel null { + null; // toss anything sent to + // this channel +}; + + + + The default_debug channel has the + special + property that it only produces output when the server's debug + level is + nonzero. It normally writes to a file called named.run + in the server's working directory. + + + + For security reasons, when the "" + command line option is used, the named.run file + is created only after named has + changed to the + new UID, and any debug output generated while named is + starting up and still running as root is discarded. If you need + to capture this output, you must run the server with the "" + option and redirect standard error to a file. + + + + Once a channel is defined, it cannot be redefined. Thus you + cannot alter the built-in channels directly, but you can modify + the default logging by pointing categories at channels you have + defined. + + + + + The <command>category</command> Phrase + + + There are many categories, so you can send the logs you want + to see wherever you want, without seeing logs you don't want. If + you don't specify a list of channels for a category, then log + messages + in that category will be sent to the default category + instead. If you don't specify a default category, the following + "default default" is used: + + +category default { default_syslog; default_debug; }; + + + + As an example, let's say you want to log security events to + a file, but you also want keep the default logging behavior. You'd + specify the following: + + +channel my_security_channel { + file "my_security_file"; + severity info; +}; +category security { + my_security_channel; + default_syslog; + default_debug; +}; + + + To discard all messages in a category, specify the null channel: + + +category xfer-out { null; }; +category notify { null; }; + + + + Following are the available categories and brief descriptions + of the types of log information they contain. More + categories may be added in future BIND releases. + + + + + + + + + default + + + + The default category defines the logging + options for those categories where no specific + configuration has been + defined. + + + + + + general + + + + The catch-all. Many things still aren't + classified into categories, and they all end up here. + + + + + + database + + + + Messages relating to the databases used + internally by the name server to store zone and cache + data. + + + + + + security + + + + Approval and denial of requests. + + + + + + config + + + + Configuration file parsing and processing. + + + + + + resolver + + + + DNS resolution, such as the recursive + lookups performed on behalf of clients by a caching name + server. + + + + + + xfer-in + + + + Zone transfers the server is receiving. + + + + + + xfer-out + + + + Zone transfers the server is sending. + + + + + + notify + + + + The NOTIFY protocol. + + + + + + client + + + + Processing of client requests. + + + + + + unmatched + + + + 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 + default it is sent to + the null channel. + + + + + + network + + + + Network operations. + + + + + + update + + + + Dynamic updates. + + + + + + update-security + + + + Approval and denial of update requests. + + + + + + queries + + + + Specify where queries should be logged to. + + + At startup, specifying the category queries will also + enable query logging unless querylog option has been + specified. + + + + The query log entry reports the client's IP + address and port number, and the query name, + class and type. It also reports whether the + Recursion Desired flag was set (+ if set, - + if not set), if the query was signed (S), + EDNS was in use (E), if DO (DNSSEC Ok) was + set (D), or if CD (Checking Disabled) was set + (C). + + + + client 127.0.0.1#62536: query: www.example.com IN AAAA +SE + + + client ::1#62537: query: www.example.net IN AAAA -SE + + + + + + dispatch + + + + Dispatching of incoming packets to the + server modules where they are to be processed. + + + + + + dnssec + + + + DNSSEC and TSIG protocol processing. + + + + + + lame-servers + + + + Lame servers. These are misconfigurations + in remote servers, discovered by BIND 9 when trying to + query + those servers during resolution. + + + + + + delegation-only + + + + 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. + + + + + + edns-disabled + + + + Log queries that have been forced to use plain + DNS due to timeouts. This is often due to + the remote servers not being RFC 1034 compliant + (not always returning FORMERR or similar to + EDNS queries and other extensions to the DNS + when they are not understood). In other words, this is + targeted at servers that fail to respond to + DNS queries that they don't understand. + + + Note: the log message can also be due to + packet loss. Before reporting servers for + non-RFC 1034 compliance they should be re-tested + to determine the nature of the non-compliance. + This testing should prevent or reduce the + number of false-positive reports. + + + Note: eventually named will have to stop + treating such timeouts as due to RFC 1034 non + compliance and start treating it as plain + packet loss. Falsely classifying packet + loss as due to RFC 1034 non compliance impacts + on DNSSEC validation which requires EDNS for + the DNSSEC records to be returned. + + + + + + + + + + + <command>lwres</command> Statement Grammar + + + This is the grammar of the lwres + statement in the named.conf file: + + +lwres { + listen-on { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + view view_name; + search { domain_name ; domain_name ; ... }; + ndots number; +}; + + + + + <command>lwres</command> Statement Definition and Usage + + + The lwres statement configures the + name + server to also act as a lightweight resolver server. (See + .) There may be multiple + lwres statements configuring + lightweight resolver servers with different properties. + + + + The listen-on statement specifies a + list of + addresses (and ports) that this instance of a lightweight resolver + daemon + should accept requests on. If no port is specified, port 921 is + used. + If this statement is omitted, requests will be accepted on + 127.0.0.1, + port 921. + + + + The view statement binds this + instance of a + lightweight resolver daemon to a view in the DNS namespace, so that + the + response will be constructed in the same manner as a normal DNS + query + matching this view. If this statement is omitted, the default view + is + used, and if there is no default view, an error is triggered. + + + + The search statement is equivalent to + the + search statement in + /etc/resolv.conf. It provides a + list of domains + which are appended to relative names in queries. + + + + The ndots statement is equivalent to + the + ndots statement in + /etc/resolv.conf. It indicates the + minimum + number of dots in a relative domain name that should result in an + exact match lookup before search path elements are appended. + + + + <command>masters</command> Statement Grammar + + +masters name port ip_port { ( masters_list | ip_addr port ip_port key key ) ; ... }; + + + + + + <command>masters</command> Statement Definition and + Usage + masters + lists allow for a common set of masters to be easily used by + multiple stub and slave zones. + + + + + <command>options</command> Statement Grammar + + + This is the grammar of the options + statement in the named.conf file: + + +options { + version version_string; + hostname hostname_string; + server-id server_id_string; + directory path_name; + key-directory path_name; + named-xfer path_name; + tkey-gssapi-credential principal; + tkey-domain domainname; + tkey-dhkey key_name key_tag; + cache-file path_name; + dump-file path_name; + memstatistics yes_or_no; + memstatistics-file path_name; + pid-file path_name; + recursing-file path_name; + statistics-file path_name; + zone-statistics yes_or_no; + auth-nxdomain yes_or_no; + deallocate-on-exit yes_or_no; + dialup dialup_option; + fake-iquery yes_or_no; + fetch-glue yes_or_no; + flush-zones-on-shutdown yes_or_no; + has-old-clients yes_or_no; + host-statistics yes_or_no; + host-statistics-max number; + minimal-responses yes_or_no; + multiple-cnames yes_or_no; + notify yes_or_no | explicit | master-only; + recursion yes_or_no; + 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; + dnssec-must-be-secure domain yes_or_no; + dnssec-accept-expired yes_or_no; + forward ( only | first ); + forwarders { ip_addr port ip_port ; ... }; + dual-stack-servers port ip_port { + ( domain_name port ip_port | + ip_addr port ip_port ) ; + ... }; + check-names ( master | slave | response ) + ( warn | fail | ignore ); + check-mx ( warn | fail | ignore ); + check-wildcard yes_or_no; + check-integrity yes_or_no; + check-mx-cname ( warn | fail | ignore ); + check-srv-cname ( warn | fail | ignore ); + check-sibling yes_or_no; + allow-notify { address_match_list }; + allow-query { address_match_list }; + allow-query-on { address_match_list }; + allow-query-cache { address_match_list }; + allow-query-cache-on { address_match_list }; + allow-transfer { address_match_list }; + allow-recursion { address_match_list }; + allow-recursion-on { address_match_list }; + allow-update { address_match_list }; + allow-update-forwarding { address_match_list }; + update-check-ksk yes_or_no; + try-tcp-refresh yes_or_no; + allow-v6-synthesis { address_match_list }; + blackhole { address_match_list }; + use-v4-udp-ports { port_list }; + avoid-v4-udp-ports { port_list }; + use-v6-udp-ports { port_list }; + avoid-v6-udp-ports { port_list }; + listen-on port ip_port { address_match_list }; + listen-on-v6 port ip_port { address_match_list }; + query-source ( ( ip4_addr | * ) + port ( ip_port | * ) | + address ( ip4_addr | * ) + port ( ip_port | * ) ) ; + query-source-v6 ( ( ip6_addr | * ) + port ( ip_port | * ) | + address ( ip6_addr | * ) + port ( ip_port | * ) ) ; + use-queryport-pool yes_or_no; + queryport-pool-ports number; + queryport-pool-interval number; + max-transfer-time-in number; + max-transfer-time-out number; + max-transfer-idle-in number; + max-transfer-idle-out number; + tcp-clients number; + reserved-sockets number; + recursive-clients number; + serial-query-rate number; + serial-queries number; + tcp-listen-queue number; + transfer-format ( one-answer | many-answers ); + transfers-in number; + transfers-out number; + transfers-per-ns number; + transfer-source (ip4_addr | *) port ip_port ; + transfer-source-v6 (ip6_addr | *) port ip_port ; + alt-transfer-source (ip4_addr | *) port ip_port ; + alt-transfer-source-v6 (ip6_addr | *) port ip_port ; + use-alt-transfer-source yes_or_no; + notify-delay seconds ; + notify-source (ip4_addr | *) port ip_port ; + notify-source-v6 (ip6_addr | *) port ip_port ; + notify-to-soa yes_or_no ; + also-notify { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + max-ixfr-log-size number; + max-journal-size size_spec; + coresize size_spec ; + datasize size_spec ; + files size_spec ; + stacksize size_spec ; + cleaning-interval number; + heartbeat-interval number; + interface-interval number; + statistics-interval number; + topology { address_match_list }; + sortlist { address_match_list }; + rrset-order { order_spec ; order_spec ; ... }; + lame-ttl number; + max-ncache-ttl number; + max-cache-ttl number; + sig-validity-interval number ; + sig-signing-nodes number ; + sig-signing-signatures number ; + sig-signing-type number ; + min-roots number; + use-ixfr yes_or_no ; + provide-ixfr yes_or_no; + request-ixfr yes_or_no; + treat-cr-as-space yes_or_no ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + port ip_port; + additional-from-auth yes_or_no ; + additional-from-cache yes_or_no ; + random-device path_name ; + max-cache-size size_spec ; + match-mapped-addresses yes_or_no; + preferred-glue ( A | AAAA | NONE ); + edns-udp-size number; + max-udp-size number; + root-delegation-only exclude { namelist } ; + querylog yes_or_no ; + disable-algorithms domain { algorithm; algorithm; }; + acache-enable yes_or_no ; + acache-cleaning-interval number; + max-acache-size size_spec ; + clients-per-query number ; + max-clients-per-query number ; + masterfile-format (text|raw) ; + empty-server name ; + empty-contact name ; + empty-zones-enable yes_or_no ; + disable-empty-zone zone_name ; + zero-no-soa-ttl yes_or_no ; + zero-no-soa-ttl-cache yes_or_no ; +}; + + + + + + <command>options</command> Statement Definition and + Usage + + + The options statement sets up global + options + to be used by BIND. This statement + may appear only + once in a configuration file. If there is no options + statement, an options block with each option set to its default will + be used. + + + + + + directory + + + The working directory of the server. + Any non-absolute pathnames in the configuration file will be + taken + as relative to this directory. The default location for most + server + output files (e.g. named.run) + is this directory. + If a directory is not specified, the working directory + defaults to `.', the directory from + which the server + was started. The directory specified should be an absolute + path. + + + + + + key-directory + + + When performing dynamic update of secure zones, the + directory where the public and private key files should be + found, + if different than the current working directory. The + directory specified + must be an absolute path. + + + + + + named-xfer + + + This option is obsolete. It + was used in BIND 8 to specify + the pathname to the named-xfer + program. In BIND 9, no separate + named-xfer program is needed; + its functionality is built into the name server. + + + + + + tkey-gssapi-credential + + + The security credential with which the server should + authenticate keys requested by the GSS-TSIG protocol. + Currently only Kerberos 5 authentication is available + and the credential is a Kerberos principal which + the server can acquire through the default system + key file, normally /etc/krb5.keytab. + Normally this principal is of the form + "dns/server.domain". + To use GSS-TSIG, tkey-domain + must also be set. + + + + + + tkey-domain + + + The domain appended to the names of all shared keys + generated with TKEY. When a + client requests a TKEY exchange, + it may or may not specify the desired name for the + key. If present, the name of the shared key will + will be client specified part + + tkey-domain. Otherwise, the + name of the shared key will be random hex + digits + tkey-domain. + In most cases, the domainname + should be the server's domain name, or an otherwise + non-existent subdomain like + "_tkey.domainname". If you are + using GSS-TSIG, this variable must be defined. + + + + + + tkey-dhkey + + + The Diffie-Hellman key used by the server + to generate shared keys with clients using the Diffie-Hellman + mode + of TKEY. The server must be + able to load the + public and private keys from files in the working directory. + In + most cases, the keyname should be the server's host name. + + + + + + cache-file + + + This is for testing only. Do not use. + + + + + + dump-file + + + The pathname of the file the server dumps + the database to when instructed to do so with + rndc dumpdb. + If not specified, the default is named_dump.db. + + + + + + memstatistics-file + + + The pathname of the file the server writes memory + usage statistics to on exit. If not specified, + the default is named.memstats. + + + + + + pid-file + + + The pathname of the file the server writes its process ID + in. If not specified, the default is + /var/run/named/named.pid. + 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 + existing one will be removed. Note that none + is a keyword, not a filename, and therefore is not enclosed + in + double quotes. + + + + + + recursing-file + + + The pathname of the file the server dumps + the queries that are currently recursing when instructed + to do so with rndc recursing. + If not specified, the default is named.recursing. + + + + + + statistics-file + + + The pathname of the file the server appends statistics + to when instructed to do so using rndc stats. + If not specified, the default is named.stats in the + server's current directory. The format of the file is + described + in . + + + + + + port + + + The UDP/TCP port number the server uses for + receiving and sending DNS protocol traffic. + The default is 53. This option is mainly intended for server + testing; + a server using a port other than 53 will not be able to + communicate with + the global DNS. + + + + + + random-device + + + The source of entropy to be used by the server. Entropy is + primarily needed + for DNSSEC operations, such as TKEY transactions and dynamic + update of signed + zones. This options specifies the device (or file) from which + to read + entropy. If this is a file, operations requiring entropy will + fail when the + file has been exhausted. If not specified, the default value + is + /dev/random + (or equivalent) when present, and none otherwise. The + random-device option takes + effect during + the initial configuration load at server startup time and + is ignored on subsequent reloads. + + + + + + preferred-glue + + + If specified, the listed type (A or AAAA) will be emitted + before other glue + in the additional section of a query response. + The default is not to prefer any type (NONE). + + + + + + root-delegation-only + + + 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"). + + + +options { + root-delegation-only exclude { "de"; "lv"; "us"; "museum"; }; +}; + + + + + + + disable-algorithms + + + Disable the specified DNSSEC algorithms at and below the + specified name. + Multiple disable-algorithms + statements are allowed. + Only the most specific will be applied. + + + + + + dnssec-lookaside + + + When set, dnssec-lookaside + provides the + validator with an alternate method to validate DNSKEY records + at the + top of a zone. When a DNSKEY is at or below a domain + specified by the + deepest dnssec-lookaside, and + the normal dnssec validation + has left the key untrusted, the trust-anchor will be append to + the key + name and a DLV record will be looked up to see if it can + validate the + key. If the DLV record validates a DNSKEY (similarly to the + way a DS + record does) the DNSKEY RRset is deemed to be trusted. + + + + + + dnssec-must-be-secure + + + Specify hierarchies which must be or may not be secure (signed and + validated). + If yes, then named will only accept + answers if they + are secure. + If no, then normal dnssec validation + applies + allowing for insecure answers to be accepted. + The specified domain must be under a trusted-key or + dnssec-lookaside must be + active. + + + + + + + + Boolean Options + + + + + auth-nxdomain + + + If yes, then the AA bit + is always set on NXDOMAIN responses, even if the server is + not actually + authoritative. The default is no; + this is + a change from BIND 8. If you + are using very old DNS software, you + may need to set it to yes. + + + + + + deallocate-on-exit + + + This option was used in BIND + 8 to enable checking + for memory leaks on exit. BIND 9 ignores the option and always performs + the checks. + + + + + + memstatistics + + + Write memory statistics to the file specified by + memstatistics-file at exit. + The default is no unless + '-m record' is specified on the command line in + which case it is yes. + + + + + + dialup + + + If yes, then the + server treats all zones as if they are doing zone transfers + across + a dial-on-demand dialup link, which can be brought up by + traffic + originating from this server. This has different effects + according + to zone type and concentrates the zone maintenance so that + it all + happens in a short interval, once every heartbeat-interval and + hopefully during the one call. It also suppresses some of + the normal + zone maintenance traffic. The default is no. + + + The dialup option + may also be specified in the view and + zone statements, + in which case it overrides the global dialup + option. + + + If the zone is a master zone, then the server will send out a + NOTIFY + request to all the slaves (default). This should trigger the + zone serial + number check in the slave (providing it supports NOTIFY) + allowing the slave + to verify the zone while the connection is active. + The set of servers to which NOTIFY is sent can be controlled + by + notify and also-notify. + + + If the + zone is a slave or stub zone, then the server will suppress + the regular + "zone up to date" (refresh) queries and only perform them + when the + heartbeat-interval expires in + addition to sending + NOTIFY requests. + + + Finer control can be achieved by using + notify which only sends NOTIFY + messages, + notify-passive which sends NOTIFY + messages and + suppresses the normal refresh queries, refresh + which suppresses normal refresh processing and sends refresh + queries + when the heartbeat-interval + expires, and + passive which just disables normal + refresh + processing. + + + + + + + + + + + + + dialup mode + + + + + normal refresh + + + + + heart-beat refresh + + + + + heart-beat notify + + + + + + no (default) + + + + yes + + + + + no + + + + + no + + + + + + yes + + + + no + + + + + yes + + + + + yes + + + + + + notify + + + + yes + + + + + no + + + + + yes + + + + + + refresh + + + + no + + + + + yes + + + + + no + + + + + + passive + + + + no + + + + + no + + + + + no + + + + + + notify-passive + + + + no + + + + + no + + + + + yes + + + + + + + + + Note that normal NOTIFY processing is not affected by + dialup. + + + + + + + fake-iquery + + + In BIND 8, this option + enabled simulating the obsolete DNS query type + IQUERY. BIND 9 never does + IQUERY simulation. + + + + + + fetch-glue + + + This option is obsolete. + In BIND 8, fetch-glue yes + caused the server to attempt to fetch glue resource records + it + didn't have when constructing the additional + data section of a response. This is now considered a bad + idea + and BIND 9 never does it. + + + + + + flush-zones-on-shutdown + + + When the nameserver exits due receiving SIGTERM, + flush or do not flush any pending zone writes. The default + is + flush-zones-on-shutdown no. + + + + + + has-old-clients + + + This option was incorrectly implemented + in BIND 8, and is ignored by BIND 9. + To achieve the intended effect + of + has-old-clients yes, specify + the two separate options auth-nxdomain yes + and rfc2308-type1 no instead. + + + + + + host-statistics + + + In BIND 8, this enables keeping of + statistics for every host that the name server interacts + with. + Not implemented in BIND 9. + + + + + + maintain-ixfr-base + + + This option is obsolete. + It was used in BIND 8 to + determine whether a transaction log was + kept for Incremental Zone Transfer. BIND 9 maintains a transaction + log whenever possible. If you need to disable outgoing + incremental zone + transfers, use provide-ixfr no. + + + + + + minimal-responses + + + If yes, then when generating + responses the server will only add records to the authority + and additional data sections when they are required (e.g. + delegations, negative responses). This may improve the + performance of the server. + The default is no. + + + + + + multiple-cnames + + + This option was used in BIND 8 to allow + a domain name to have multiple CNAME records in violation of + the DNS standards. BIND 9.2 onwards + always strictly enforces the CNAME rules both in master + files and dynamic updates. + + + + + + notify + + + If yes (the default), + DNS NOTIFY messages are sent when a zone the server is + authoritative for + changes, see . The messages are + sent to the + servers listed in the zone's NS records (except the master + server identified + in the SOA MNAME field), and to any servers listed in the + also-notify option. + + + If master-only, notifies are only + sent + for master zones. + If explicit, notifies are sent only + to + servers explicitly listed using also-notify. + If no, no notifies are sent. + + + The notify option may also be + specified in the zone + statement, + in which case it overrides the options notify statement. + It would only be necessary to turn off this option if it + caused slaves + to crash. + + + + + + notify-to-soa + + + If yes do not check the nameservers + in the NS RRset against the SOA MNAME. Normally a NOTIFY + message is not sent to the SOA MNAME (SOA ORIGIN) as it is + supposed to contain the name of the ultimate master. + Sometimes, however, a slave is listed as the SOA MNAME in + hidden master configurations and in that case you would + want the ultimate master to still send NOTIFY messages to + all the nameservers listed in the NS RRset. + + + + + + recursion + + + If yes, and a + DNS query requests recursion, then the server will attempt + to do + all the work required to answer the query. If recursion is + off + and the server does not already know the answer, it will + return a + referral response. The default is + yes. + Note that setting recursion no does not prevent + clients from getting data from the server's cache; it only + prevents new data from being cached as an effect of client + queries. + Caching may still occur as an effect the server's internal + operation, such as NOTIFY address lookups. + See also fetch-glue above. + + + + + + rfc2308-type1 + + + Setting this to yes will + cause the server to send NS records along with the SOA + record for negative + answers. The default is no. + + + + Not yet implemented in BIND + 9. + + + + + + + use-id-pool + + + This option is obsolete. + BIND 9 always allocates query + IDs from a pool. + + + + + + zone-statistics + + + If yes, the server will collect + statistical data on all zones (unless specifically turned + off + on a per-zone basis by specifying zone-statistics no + in the zone statement). + These statistics may be accessed + using rndc stats, which will + dump them to the file listed + in the statistics-file. See + also . + + + + + + use-ixfr + + + This option is obsolete. + If you need to disable IXFR to a particular server or + servers, see + the information on the provide-ixfr option + in . + See also + . + + + + + + provide-ixfr + + + See the description of + provide-ixfr in + . + + + + + + request-ixfr + + + See the description of + request-ixfr in + . + + + + + + treat-cr-as-space + + + This option was used in BIND + 8 to make + the server treat carriage return ("\r") characters the same way + as a space or tab character, + to facilitate loading of zone files on a UNIX system that + were generated + on an NT or DOS machine. In BIND 9, both UNIX "\n" + and NT/DOS "\r\n" newlines + are always accepted, + and the option is ignored. + + + + + + additional-from-auth + additional-from-cache + + + + These options control the behavior of an authoritative + server when + answering queries which have additional data, or when + following CNAME + and DNAME chains. + + + + When both of these options are set to yes + (the default) and a + query is being answered from authoritative data (a zone + configured into the server), the additional data section of + the + reply will be filled in using data from other authoritative + zones + and from the cache. In some situations this is undesirable, + such + as when there is concern over the correctness of the cache, + or + in servers where slave zones may be added and modified by + untrusted third parties. Also, avoiding + the search for this additional data will speed up server + operations + at the possible expense of additional queries to resolve + what would + otherwise be provided in the additional section. + + + + For example, if a query asks for an MX record for host foo.example.com, + and the record found is "MX 10 mail.example.net", normally the address + records (A and AAAA) for mail.example.net will be provided as well, + if known, even though they are not in the example.com zone. + Setting these options to no + disables this behavior and makes + the server only search for additional data in the zone it + answers from. + + + + These options are intended for use in authoritative-only + servers, or in authoritative-only views. Attempts to set + them to no without also + specifying + recursion no will cause the + server to + ignore the options and log a warning message. + + + + Specifying additional-from-cache no actually + disables the use of the cache not only for additional data + lookups + but also when looking up the answer. This is usually the + desired + behavior in an authoritative-only server where the + correctness of + the cached data is an issue. + + + + When a name server is non-recursively queried for a name + that is not + below the apex of any served zone, it normally answers with + an + "upwards referral" to the root servers or the servers of + some other + known parent of the query name. Since the data in an + upwards referral + comes from the cache, the server will not be able to provide + upwards + referrals when additional-from-cache no + has been specified. Instead, it will respond to such + queries + with REFUSED. This should not cause any problems since + upwards referrals are not required for the resolution + process. + + + + + + + match-mapped-addresses + + + If yes, then an + IPv4-mapped IPv6 address will match any address match + list entries that match the corresponding IPv4 address. + Enabling this option is sometimes useful on IPv6-enabled + Linux + systems, to work around a kernel quirk that causes IPv4 + TCP connections such as zone transfers to be accepted + on an IPv6 socket using mapped addresses, causing + address match lists designed for IPv4 to fail to match. + The use of this option for any other purpose is discouraged. + + + + + + ixfr-from-differences + + + When yes and the server loads a new version of a master + zone from its zone file or receives a new version of a slave + file by a non-incremental zone transfer, it will compare + the new version to the previous one and calculate a set + of differences. The differences are then logged in the + zone's journal file such that the changes can be transmitted + to downstream slaves as an incremental zone transfer. + + + By allowing incremental zone transfers to be used for + non-dynamic zones, this option saves bandwidth at the + expense of increased CPU and memory consumption at the + master. + In particular, if the new version of a zone is completely + different from the previous one, the set of differences + will be of a size comparable to the combined size of the + old and new zone version, and the server will need to + temporarily allocate memory to hold this complete + difference set. + + ixfr-from-differences + also accepts master and + slave at the view and options + levels which causes + 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 + not log + 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. + The default is yes. + + + + + + dnssec-validation + + + Enable DNSSEC validation in named. + Note dnssec-enable also needs to be + set to yes to be effective. + The default is yes. + + + + + + dnssec-accept-expired + + + Accept expired signatures when verifying DNSSEC signatures. + The default is no. + Setting this option to "yes" leaves named vulnerable to replay attacks. + + + + + + querylog + + + Specify whether query logging should be started when named + starts. + If querylog is not specified, + then the query logging + is determined by the presence of the logging category queries. + + + + + + check-names + + + This option is used to restrict the character set and syntax + of + certain domain names in master files and/or DNS responses + received + from the network. The default varies according to usage + area. For + master zones the default is fail. + For slave zones the default + is warn. + For answers received from the network (response) + the default is ignore. + + + The rules for legal hostnames and mail domains are derived + from RFC 952 and RFC 821 as modified by RFC 1123. + + check-names + applies to the owner names of A, AAAA and MX records. + It also applies to the domain names in the RDATA of NS, SOA + and MX records. + It also applies to the RDATA of PTR records where the owner + name indicated that it is a reverse lookup of a hostname + (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT). + + + + + + check-mx + + + Check whether the MX record appears to refer to a IP address. + The default is to warn. Other possible + values are fail and + ignore. + + + + + + check-wildcard + + + This option is used to check for non-terminal wildcards. + The use of non-terminal wildcards is almost always as a + result of a failure + to understand the wildcard matching algorithm (RFC 1034). + This option + affects master zones. The default (yes) is to check + for non-terminal wildcards and issue a warning. + + + + + + check-integrity + + + Perform post load zone integrity checks on master + zones. This checks that MX and SRV records refer + to address (A or AAAA) records and that glue + address records exist for delegated zones. For + MX and SRV records only in-zone hostnames are + checked (for out-of-zone hostnames use + named-checkzone). + For NS records only names below top of zone are + checked (for out-of-zone names and glue consistency + checks use named-checkzone). + The default is yes. + + + + + + check-mx-cname + + + If check-integrity is set then + fail, warn or ignore MX records that refer + to CNAMES. The default is to warn. + + + + + + check-srv-cname + + + If check-integrity is set then + fail, warn or ignore SRV records that refer + to CNAMES. The default is to warn. + + + + + + check-sibling + + + When performing integrity checks, also check that + sibling glue exists. The default is yes. + + + + + + zero-no-soa-ttl + + + When returning authoritative negative responses to + SOA queries set the TTL of the SOA record returned in + the authority section to zero. + The default is yes. + + + + + + zero-no-soa-ttl-cache + + + When caching a negative response to a SOA query + set the TTL to zero. + The default is no. + + + + + + update-check-ksk + + + When regenerating the RRSIGs following a UPDATE + request to a secure zone, check the KSK flag on + the DNSKEY RR to determine if this key should be + used to generate the RRSIG. This flag is ignored + if there are not DNSKEY RRs both with and without + a KSK. + The default is yes. + + + + + + try-tcp-refresh + + + Try to refresh the zone using TCP if UDP queries fail. + For BIND 8 compatibility, the default is + yes. + + + + + + + + + + Forwarding + + The forwarding facility can be used to create a large site-wide + cache on a few servers, reducing traffic over links to external + name servers. It can also be used to allow queries by servers that + do not have direct access to the Internet, but wish to look up + exterior + names anyway. Forwarding occurs only on those queries for which + the server is not authoritative and does not have the answer in + its cache. + + + + + forward + + + This option is only meaningful if the + forwarders list is not empty. A value of first, + the default, causes the server to query the forwarders + first — and + if that doesn't answer the question, the server will then + look for + the answer itself. If only is + specified, the + server will only query the forwarders. + + + + + + forwarders + + + Specifies the IP addresses to be used + for forwarding. The default is the empty list (no + forwarding). + + + + + + + + Forwarding can also be configured on a per-domain basis, allowing + for the global forwarding options to be overridden in a variety + of ways. You can set particular domains to use different + forwarders, + or have a different forward only/first behavior, + or not forward at all, see . + + + + + Dual-stack Servers + + Dual-stack servers are used as servers of last resort to work + around + problems in reachability due the lack of support for either IPv4 + or IPv6 + on the host machine. + + + + + dual-stack-servers + + + Specifies host names or addresses of machines with access to + both IPv4 and IPv6 transports. If a hostname is used, the + server must be able + to resolve the name using only the transport it has. If the + machine is dual + stacked, then the dual-stack-servers have no effect unless + access to a transport has been disabled on the command line + (e.g. named -4). + + + + + + + + Access Control + + + Access to the server can be restricted based on the IP address + of the requesting system. See for + details on how to specify IP address lists. + + + + + + allow-notify + + + Specifies which hosts are allowed to + notify this server, a slave, of zone changes in addition + to the zone masters. + allow-notify may also be + specified in the + zone statement, in which case + it overrides the + options allow-notify + statement. It is only meaningful + for a slave zone. If not specified, the default is to + process notify messages + only from a zone's master. + + + + + + allow-query + + + Specifies which hosts are allowed to ask ordinary + DNS questions. allow-query may + also be specified in the zone + statement, in which case it overrides the + options allow-query statement. + If not specified, the default is to allow queries + from all hosts. + + + + allow-query-cache is now + used to specify access to the cache. + + + + + + + allow-query-on + + + Specifies which local addresses can accept ordinary + DNS questions. This makes it possible, for instance, + to allow queries on internal-facing interfaces but + disallow them on external-facing ones, without + necessarily knowing the internal network's addresses. + + + allow-query-on may + also be specified in the zone + statement, in which case it overrides the + options allow-query-on statement. + + + If not specified, the default is to allow queries + on all addresses. + + + + allow-query-cache is + used to specify access to the cache. + + + + + + + allow-query-cache + + + Specifies which hosts are allowed to get answers + 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; + localhost;) is used. + + + + + + allow-query-cache-on + + + Specifies which local addresses can give answers + from the cache. If not specified, the default is + to allow cache queries on any address, + localnets and + localhost. + + + + + + allow-recursion + + + Specifies which hosts are allowed to make recursive + queries through this server. If + allow-recursion is not set + then allow-query-cache is + used if set, otherwise allow-query + is used if set, otherwise the default + (localnets; + localhost;) is used. + + + + + + allow-recursion-on + + + Specifies which local addresses can accept recursive + queries. If not specified, the default is to allow + recursive queries on all addresses. + + + + + + allow-update + + + Specifies which hosts are allowed to + submit Dynamic DNS updates for master zones. The default is + to deny + updates from all hosts. Note that allowing updates based + on the requestor's IP address is insecure; see + for details. + + + + + + allow-update-forwarding + + + Specifies which hosts are allowed to + submit Dynamic DNS updates to slave zones to be forwarded to + the + master. The default is { none; }, + which + means that no update forwarding will be performed. To + enable + update forwarding, specify + allow-update-forwarding { any; };. + Specifying values other than { none; } or + { any; } is usually + counterproductive, since + the responsibility for update access control should rest + with the + master server, not the slaves. + + + Note that enabling the update forwarding feature on a slave + server + may expose master servers relying on insecure IP address + based + access control to attacks; see + for more details. + + + + + + allow-v6-synthesis + + + This option was introduced for the smooth transition from + AAAA + to A6 and from "nibble labels" to binary labels. + However, since both A6 and binary labels were then + deprecated, + this option was also deprecated. + It is now ignored with some warning messages. + + + + + + allow-transfer + + + Specifies which hosts are allowed to + receive zone transfers from the server. allow-transfer may + also be specified in the zone + statement, in which + case it overrides the options allow-transfer statement. + If not specified, the default is to allow transfers to all + hosts. + + + + + + blackhole + + + Specifies a list of addresses that the + server will not accept queries from or use to resolve a + query. Queries + from these addresses will not be responded to. The default + is none. + + + + + + + + + + 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. + The server will listen on all interfaces allowed by the address + match list. If a port is not specified, port 53 will be used. + + + Multiple listen-on statements are + allowed. + For example, + + +listen-on { 5.6.7.8; }; +listen-on port 1234 { !1.2.3.4; 1.2/16; }; + + + + will enable the name server on port 53 for the IP address + 5.6.7.8, and on port 1234 of an address on the machine in net + 1.2 that is not 1.2.3.4. + + + + If no listen-on is specified, the + server will listen on port 53 on all IPv4 interfaces. + + + + The listen-on-v6 option is used to + specify the interfaces and the ports on which the server will + listen + for incoming queries sent using IPv6. + + + + When { any; } is + specified + as the address_match_list for the + listen-on-v6 option, + the server does not bind a separate socket to each IPv6 interface + address as it does for IPv4 if the operating system has enough API + support for IPv6 (specifically if it conforms to RFC 3493 and RFC + 3542). + Instead, it listens on the IPv6 wildcard address. + If the system only has incomplete API support for IPv6, however, + the behavior is the same as that for IPv4. + + + + A list of particular IPv6 addresses can also be specified, in + which case + the server listens on a separate socket for each specified + address, + regardless of whether the desired API is supported by the system. + + + + Multiple listen-on-v6 options can + be used. + For example, + + +listen-on-v6 { any; }; +listen-on-v6 port 1234 { !2001:db8::/32; any; }; + + + + will enable the name server on port 53 for any IPv6 addresses + (with a single wildcard socket), + and on port 1234 of IPv6 addresses that is not in the prefix + 2001:db8::/32 (with separate sockets for each matched address.) + + + + To make the server not listen on any IPv6 address, use + + +listen-on-v6 { none; }; + + + + If no listen-on-v6 option is + specified, the server will not listen on any IPv6 address + unless -6 is specified when named is + invoked. If -6 is specified then + named will listen on port 53 on all IPv6 interfaces by default. + + + + + Query Address + + If the server doesn't know the answer to a question, it will + query other name servers. query-source specifies + the address and port used for such queries. For queries sent over + IPv6, there is a separate query-source-v6 option. + If address is * (asterisk) or is omitted, + a wildcard IP address (INADDR_ANY) + will be used. + + + + If port is * or is omitted, + a random port number from a pre-configured + range is picked up and will be used for each query. + The port range(s) is that specified in + the use-v4-udp-ports (for IPv4) + and use-v6-udp-ports (for IPv6) + options, excluding the ranges specified in + the avoid-v4-udp-ports + and avoid-v6-udp-ports options, respectively. + + + + The defaults of the query-source and + query-source-v6 options + are: + + +query-source address * port *; +query-source-v6 address * port *; + + + + If use-v4-udp-ports or + use-v6-udp-ports is unspecified, + named will check if the operating + system provides a programming interface to retrieve the + system's default range for ephemeral ports. + If such an interface is available, + named will use the corresponding system + default range; otherwise, it will use its own defaults: + + +use-v4-udp-ports { range 1024 65535; }; +use-v6-udp-ports { range 1024 65535; }; + + + + Note: make sure the ranges be sufficiently large for + security. A desirable size depends on various parameters, + but we generally recommend it contain at least 16384 ports + (14 bits of entropy). + Note also that the system's default range when used may be + too small for this purpose, and that the range may even be + changed while named is running; the new + range will automatically be applied when named + is reloaded. + It is encouraged to + configure use-v4-udp-ports and + use-v6-udp-ports explicitly so that the + ranges are sufficiently large and are reasonably + independent from the ranges used by other applications. + + + + Note: the operational configuration + where named runs may prohibit the use + of some ports. For example, UNIX systems will not allow + named running without a root privilege + to use ports less than 1024. + If such ports are included in the specified (or detected) + set of query ports, the corresponding query attempts will + fail, resulting in resolution failures or delay. + It is therefore important to configure the set of ports + that can be safely used in the expected operational environment. + + + + The defaults of the avoid-v4-udp-ports and + avoid-v6-udp-ports options + are: + + +avoid-v4-udp-ports {}; +avoid-v6-udp-ports {}; + + + + Note: BIND 9.5.0 introduced + the use-queryport-pool + option to support a pool of such random ports, but this + option is now obsolete because reusing the same ports in + the pool may not be sufficiently secure. + For the same reason, it is generally strongly discouraged to + specify a particular port for the + query-source or + query-source-v6 options; + it implicitly disables the use of randomized port numbers. + + + + + use-queryport-pool + + + This option is obsolete. + + + + + + queryport-pool-ports + + + This option is obsolete. + + + + + + queryport-pool-updateinterval + + + This option is obsolete. + + + + + + + + The address specified in the query-source option + is used for both UDP and TCP queries, but the port applies only + to UDP queries. TCP queries always use a random + unprivileged port. + + + + + Solaris 2.5.1 and earlier does not support setting the source + address for TCP sockets. + + + + + See also transfer-source and + notify-source. + + + + + + Zone Transfers + + BIND has mechanisms in place to + facilitate zone transfers + and set limits on the amount of load that transfers place on the + system. The following options apply to zone transfers. + + + + + + also-notify + + + Defines a global list of IP addresses of name servers + that are also sent NOTIFY messages whenever a fresh copy of + the + zone is loaded, in addition to the servers listed in the + zone's NS records. + This helps to ensure that copies of the zones will + quickly converge on stealth servers. If an also-notify list + is given in a zone statement, + it will override + the options also-notify + statement. When a zone notify + statement + is set to no, the IP + addresses in the global also-notify list will + not be sent NOTIFY messages for that zone. The default is + the empty + list (no global notification list). + + + + + + max-transfer-time-in + + + Inbound zone transfers running longer than + this many minutes will be terminated. The default is 120 + minutes + (2 hours). The maximum value is 28 days (40320 minutes). + + + + + + max-transfer-idle-in + + + Inbound zone transfers making no progress + in this many minutes will be terminated. The default is 60 + minutes + (1 hour). The maximum value is 28 days (40320 minutes). + + + + + + max-transfer-time-out + + + Outbound zone transfers running longer than + this many minutes will be terminated. The default is 120 + minutes + (2 hours). The maximum value is 28 days (40320 minutes). + + + + + + max-transfer-idle-out + + + Outbound zone transfers making no progress + in this many minutes will be terminated. The default is 60 + minutes (1 + hour). The maximum value is 28 days (40320 minutes). + + + + + + serial-query-rate + + + Slave servers will periodically query master servers + to find out if zone serial numbers have changed. Each such + query uses + a minute amount of the slave server's network bandwidth. To + limit the + amount of bandwidth used, BIND 9 limits the rate at which + queries are + sent. The value of the serial-query-rate option, + an integer, is the maximum number of queries sent per + second. + The default is 20. + + + + + + serial-queries + + + In BIND 8, the serial-queries + option + set the maximum number of concurrent serial number queries + allowed to be outstanding at any given time. + BIND 9 does not limit the number of outstanding + serial queries and ignores the serial-queries option. + Instead, it limits the rate at which the queries are sent + as defined using the serial-query-rate option. + + + + + + transfer-format + + + + Zone transfers can be sent using two different formats, + one-answer and + many-answers. + The transfer-format option is used + on the master server to determine which format it sends. + one-answer uses one DNS message per + resource record transferred. + many-answers packs as many resource + records as possible into a message. + many-answers is more efficient, but is + only supported by relatively new slave servers, + such as BIND 9, BIND + 8.x and BIND 4.9.5 onwards. + The many-answers format is also supported by + recent Microsoft Windows nameservers. + The default is many-answers. + transfer-format may be overridden on a + per-server basis by using the server + statement. + + + + + + + transfers-in + + + The maximum number of inbound zone transfers + that can be running concurrently. The default value is 10. + Increasing transfers-in may + speed up the convergence + of slave zones, but it also may increase the load on the + local system. + + + + + + transfers-out + + + The maximum number of outbound zone transfers + that can be running concurrently. Zone transfer requests in + excess + of the limit will be refused. The default value is 10. + + + + + + transfers-per-ns + + + The maximum number of inbound zone transfers + that can be concurrently transferring from a given remote + name server. + The default value is 2. + Increasing transfers-per-ns + may + speed up the convergence of slave zones, but it also may + increase + the load on the remote name server. transfers-per-ns may + be overridden on a per-server basis by using the transfers phrase + of the server statement. + + + + + + transfer-source + + transfer-source + determines which local address will be bound to IPv4 + TCP connections used to fetch zones transferred + inbound by the server. It also determines the + source IPv4 address, and optionally the UDP port, + used for the refresh queries and forwarded dynamic + updates. If not set, it defaults to a system + controlled value which will usually be the address + of the interface "closest to" the remote end. This + address must appear in the remote end's + allow-transfer option for the + zone being transferred, if one is specified. This + statement sets the + transfer-source for all zones, + but can be overridden on a per-view or per-zone + basis by including a + transfer-source statement within + the view or + zone block in the configuration + file. + + + + Solaris 2.5.1 and earlier does not support setting the + source address for TCP sockets. + + + + + + + transfer-source-v6 + + + The same as transfer-source, + except zone transfers are performed using IPv6. + + + + + + alt-transfer-source + + + An alternate transfer source if the one listed in + transfer-source fails and + use-alt-transfer-source is + set. + + + If you do not wish the alternate transfer source + 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 + query. + + + + + + alt-transfer-source-v6 + + + An alternate transfer source if the one listed in + transfer-source-v6 fails and + use-alt-transfer-source is + set. + + + + + + use-alt-transfer-source + + + Use the alternate transfer sources or not. If views are + specified this defaults to no + otherwise it defaults to + yes (for BIND 8 + compatibility). + + + + + + notify-source + + notify-source + determines which local source address, and + optionally UDP port, will be used to send NOTIFY + messages. This address must appear in the slave + server's masters zone clause or + in an allow-notify clause. This + statement sets the notify-source + for all zones, but can be overridden on a per-zone or + per-view basis by including a + notify-source statement within + the zone or + view block in the configuration + file. + + + + Solaris 2.5.1 and earlier does not support setting the + source address for TCP sockets. + + + + + + + notify-source-v6 + + + Like notify-source, + but applies to notify messages sent to IPv6 addresses. + + + + + + + + + + UDP Port Lists + + use-v4-udp-ports, + avoid-v4-udp-ports, + use-v6-udp-ports, and + avoid-v6-udp-ports + specify a list of IPv4 and IPv6 UDP ports that will be + used or not used as source ports for UDP messages. + See about how the + available ports are determined. + For example, with the following configuration + + + +use-v6-udp-ports { range 32768 65535; }; +avoid-v6-udp-ports { 40000; range 50000 60000; }; + + + + UDP ports of IPv6 messages sent + from named will be in one + of the following ranges: 32768 to 39999, 40001 to 49999, + and 60001 to 65535. + + + + avoid-v4-udp-ports and + avoid-v6-udp-ports can be used + to prevent named from choosing as its random source port a + port that is blocked by your firewall or a port that is + used by other applications; + if a query went out with a source port blocked by a + firewall, the + answer would not get by the firewall and the name server would + have to query again. + Note: the desired range can also be represented only with + use-v4-udp-ports and + use-v6-udp-ports, and the + avoid- options are redundant in that + sense; they are provided for backward compatibility and + to possibly simplify the port specification. + + + + + Operating System Resource Limits + + + The server's usage of many system resources can be limited. + Scaled values are allowed when specifying resource limits. For + example, 1G can be used instead of + 1073741824 to specify a limit of + one + gigabyte. unlimited requests + unlimited use, or the + maximum available amount. default + uses the limit + that was in force when the server was started. See the description + of size_spec in . + + + + The following options set operating system resource limits for + the name server process. Some operating systems don't support + some or + any of the limits. On such systems, a warning will be issued if + the + unsupported limit is used. + + + + + + coresize + + + The maximum size of a core dump. The default + is default. + + + + + + datasize + + + The maximum amount of data memory the server + may use. The default is default. + This is a hard limit on server memory usage. + If the server attempts to allocate memory in excess of this + limit, the allocation will fail, which may in turn leave + the server unable to perform DNS service. Therefore, + this option is rarely useful as a way of limiting the + amount of memory used by the server, but it can be used + to raise an operating system data size limit that is + too small by default. If you wish to limit the amount + of memory used by the server, use the + max-cache-size and + recursive-clients + options instead. + + + + + + files + + + The maximum number of files the server + may have open concurrently. The default is unlimited. + + + + + + stacksize + + + The maximum amount of stack memory the server + may use. The default is default. + + + + + + + + + + Server Resource Limits + + + The following options set limits on the server's + resource consumption that are enforced internally by the + server rather than the operating system. + + + + + + max-ixfr-log-size + + + This option is obsolete; it is accepted + and ignored for BIND 8 compatibility. The option + max-journal-size performs a + similar function in BIND 9. + + + + + + max-journal-size + + + Sets a maximum size for each journal file + (see ). When the journal file + approaches + the specified size, some of the oldest transactions in the + journal + will be automatically removed. The default is + unlimited. + This may also be set on a per-zone basis. + + + + + + host-statistics-max + + + In BIND 8, specifies the maximum number of host statistics + entries to be kept. + Not implemented in BIND 9. + + + + + + recursive-clients + + + The maximum number of simultaneous recursive lookups + the server will perform on behalf of clients. The default + is + 1000. Because each recursing + client uses a fair + bit of memory, on the order of 20 kilobytes, the value of + the + recursive-clients option may + have to be decreased + on hosts with limited memory. + + + + + + tcp-clients + + + The maximum number of simultaneous client TCP + connections that the server will accept. + The default is 100. + + + + + + reserved-sockets + + + 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 + to provide room for outgoing TCP queries and incoming zone + transfers. The default is 512. + The minimum value is 128 and the + maximum value is 128 less than + maxsockets (-S). This option may be removed in the future. + + + This option has little effect on Windows. + + + + + + max-cache-size + + + The maximum amount of memory to use for the + server's cache, in bytes. + When the amount of data in the cache + reaches this limit, the server will cause records to expire + prematurely based on an LRU based strategy so that + the limit is not exceeded. + A value of 0 is special, meaning that + records are purged from the cache only when their + TTLs expire. + Another special keyword unlimited + means the maximum value of 32-bit unsigned integers + (0xffffffff), which may not have the same effect as + 0 on machines that support more than 32 bits of + memory space. + Any positive values less than 2MB will be ignored reset + to 2MB. + In a server with multiple views, the limit applies + separately to the cache of each view. + The default is 0. + + + + + + tcp-listen-queue + + + The listen queue depth. The default and minimum is 3. + If the kernel supports the accept filter "dataready" this + also controls how + many TCP connections that will be queued in kernel space + waiting for + some data before being passed to accept. Values less than 3 + will be + silently raised. + + + + + + + + + + Periodic Task Intervals + + + + + cleaning-interval + + + This interval is effectively obsolete. Previously, + the server would remove expired resource records + from the cache every cleaning-interval minutes. + BIND 9 now manages cache + memory in a more sophisticated manner and does not + rely on the periodic cleaning any more. + Specifying this option therefore has no effect on + the server's behavior. + + + + + + heartbeat-interval + + + The server will perform zone maintenance tasks + for all zones marked as dialup whenever this + interval expires. The default is 60 minutes. Reasonable + values are up + to 1 day (1440 minutes). The maximum value is 28 days + (40320 minutes). + If set to 0, no zone maintenance for these zones will occur. + + + + + + interface-interval + + + The server will scan the network interface list + every interface-interval + minutes. The default + is 60 minutes. The maximum value is 28 days (40320 minutes). + If set to 0, interface scanning will only occur when + the configuration file is loaded. After the scan, the + server will + begin listening for queries on any newly discovered + interfaces (provided they are allowed by the + listen-on configuration), and + will + stop listening on interfaces that have gone away. + + + + + + statistics-interval + + + Name server statistics will be logged + every statistics-interval + minutes. The default is + 60. The maximum value is 28 days (40320 minutes). + If set to 0, no statistics will be logged. + + + Not yet implemented in + BIND 9. + + + + + + + + + + + Topology + + + All other things being equal, when the server chooses a name + server + to query from a list of name servers, it prefers the one that is + topologically closest to itself. The topology statement + takes an address_match_list and + interprets it + in a special way. Each top-level list element is assigned a + distance. + Non-negated elements get a distance based on their position in the + list, where the closer the match is to the start of the list, the + shorter the distance is between it and the server. A negated match + will be assigned the maximum distance from the server. If there + is no match, the address will get a distance which is further than + any non-negated list element, and closer than any negated element. + For example, + + +topology { + 10/8; + !1.2.3/24; + { 1.2/16; 3/8; }; +}; + + + will prefer servers on network 10 the most, followed by hosts + on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the + exception of hosts on network 1.2.3 (netmask 255.255.255.0), which + is preferred least of all. + + + The default topology is + + + topology { localhost; localnets; }; + + + + + The topology option + is not implemented in BIND 9. + + + + + + + The <command>sortlist</command> Statement + + + The response to a DNS query may consist of multiple resource + records (RRs) forming a resource records set (RRset). + The name server will normally return the + RRs within the RRset in an indeterminate order + (but see the rrset-order + statement in ). + The client resolver code should rearrange the RRs as appropriate, + that is, using any addresses on the local net in preference to + other addresses. + However, not all resolvers can do this or are correctly + configured. + When a client is using a local server, the sorting can be performed + in the server, based on the client's address. This only requires + configuring the name servers, not all the clients. + + + + The sortlist statement (see below) + takes + an address_match_list and + interprets it even + more specifically than the topology + statement + does (). + Each top level statement in the sortlist must + itself be an explicit address_match_list with + one or two elements. The first element (which may be an IP + address, + an IP prefix, an ACL name or a nested address_match_list) + of each top level list is checked against the source address of + the query until a match is found. + + + Once the source address of the query has been matched, if + the top level statement contains only one element, the actual + primitive + element that matched the source address is used to select the + address + in the response to move to the beginning of the response. If the + statement is a list of two elements, then the second element is + treated the same as the address_match_list in + a topology statement. Each top + level element + is assigned a distance and the address in the response with the + minimum + distance is moved to the beginning of the response. + + + In the following example, any queries received from any of + the addresses of the host itself will get responses preferring + addresses + on any of the locally connected networks. Next most preferred are + addresses + on the 192.168.1/24 network, and after that either the + 192.168.2/24 + or + 192.168.3/24 network with no preference shown between these two + networks. Queries received from a host on the 192.168.1/24 network + will prefer other addresses on that network to the 192.168.2/24 + and + 192.168.3/24 networks. Queries received from a host on the + 192.168.4/24 + or the 192.168.5/24 network will only prefer other addresses on + their directly connected networks. + + +sortlist { + { localhost; // IF the local host + { localnets; // THEN first fit on the + 192.168.1/24; // following nets + { 192.168.2/24; 192.168.3/24; }; }; }; + { 192.168.1/24; // IF on class C 192.168.1 + { 192.168.1/24; // THEN use .1, or .2 or .3 + { 192.168.2/24; 192.168.3/24; }; }; }; + { 192.168.2/24; // IF on class C 192.168.2 + { 192.168.2/24; // THEN use .2, or .1 or .3 + { 192.168.1/24; 192.168.3/24; }; }; }; + { 192.168.3/24; // IF on class C 192.168.3 + { 192.168.3/24; // THEN use .3, or .1 or .2 + { 192.168.1/24; 192.168.2/24; }; }; }; + { { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net + }; +}; + + + The following example will give reasonable behavior for the + local host and hosts on directly connected networks. It is similar + to the behavior of the address sort in BIND 4.9.x. Responses sent + to queries from the local host will favor any of the directly + connected + networks. Responses sent to queries from any other hosts on a + directly + connected network will prefer addresses on that same network. + Responses + to other queries will not be sorted. + + +sortlist { + { localhost; localnets; }; + { localnets; }; +}; + + + + + RRset Ordering + + When multiple records are returned in an answer it may be + useful to configure the order of the records placed into the + response. + The rrset-order statement permits + configuration + of the ordering of the records in a multiple record response. + See also the sortlist statement, + . + + + + An order_spec is defined as + follows: + + + class class_name + type type_name + name "domain_name" + order ordering + + + If no class is specified, the default is ANY. + If no type is specified, the default is ANY. + If no name is specified, the default is "*" (asterisk). + + + The legal values for ordering are: + + + + + + + + + fixed + + + + Records are returned in the order they + are defined in the zone file. + + + + + + random + + + + Records are returned in some random order. + + + + + + cyclic + + + + Records are returned in a cyclic round-robin order. + + + If BIND is configured with the + "--enable-fixed-rrset" option at compile time, then + the initial ordering of the RRset will match the + one specified in the zone file. + + + + + + + + For example: + + +rrset-order { + class IN type A name "host.example.com" order random; + order cyclic; +}; + + + + will cause any responses for type A records in class IN that + have "host.example.com" as a + suffix, to always be returned + in random order. All other records are returned in cyclic order. + + + If multiple rrset-order statements + appear, + they are not combined — the last one applies. + + + + + In this release of BIND 9, the + rrset-order statement does not support + "fixed" ordering by default. Fixed ordering can be enabled + at compile time by specifying "--enable-fixed-rrset" on + the "configure" command line. + + + + + + Tuning + + + + + lame-ttl + + + Sets the number of seconds to cache a + lame server indication. 0 disables caching. (This is + NOT recommended.) + The default is 600 (10 minutes) and the + maximum value is + 1800 (30 minutes). + + + + + + + max-ncache-ttl + + + To reduce network traffic and increase performance, + the server stores negative answers. max-ncache-ttl is + used to set a maximum retention time for these answers in + the server + in seconds. The default + max-ncache-ttl is 10800 seconds (3 hours). + max-ncache-ttl cannot exceed + 7 days and will + be silently truncated to 7 days if set to a greater value. + + + + + + max-cache-ttl + + + Sets the maximum time for which the server will + cache ordinary (positive) answers. The default is + one week (7 days). + A value of zero may cause all queries to return + SERVFAIL, because of lost caches of intermediate + RRsets (such as NS and glue AAAA/A records) in the + resolution process. + + + + + + min-roots + + + The minimum number of root servers that + is required for a request for the root servers to be + accepted. The default + is 2. + + + + Not implemented in BIND 9. + + + + + + + sig-validity-interval + + + Specifies the number of days into the future when + DNSSEC signatures automatically generated as a + result of dynamic updates () will expire. There + is a optional second field which specifies how + long before expiry that the signatures will be + regenerated. If not specified the signatures will + be regenerated at 1/4 of base interval. The second + field is specified in days if the base interval is + greater than 7 days otherwise it is specified in hours. + The default base interval is 30 days + giving a re-signing interval of 7 1/2 days. The maximum + values are 10 years (3660 days). + + + The signature inception time is unconditionally + set to one hour before the current time to allow + for a limited amount of clock skew. + + + The sig-validity-interval + should be, at least, several multiples of the SOA + expire interval to allow for reasonable interaction + between the various timer and expiry dates. + + + + + + sig-signing-nodes + + + Specify the maximum number of nodes to be + examined in each quantum when signing a zone with + a new DNSKEY. The default is + 100. + + + + + + sig-signing-signatures + + + Specify a threshold number of signatures that + will terminate processing a quantum when signing + a zone with a new DNSKEY. The default is + 10. + + + + + + sig-signing-type + + + Specify a private RDATA type to be used when generating + key signing records. The default is + 65535. + + + It is expected that this parameter may be removed + in a future version once there is a standard type. + + + + + + min-refresh-time + max-refresh-time + min-retry-time + max-retry-time + + + These options control the server's behavior on refreshing a + zone + (querying for SOA changes) or retrying failed transfers. + Usually the SOA values for the zone are used, but these + values + are set by the master, giving slave server administrators + little + control over their contents. + + + These options allow the administrator to set a minimum and + maximum + refresh and retry time either per-zone, per-view, or + globally. + These options are valid for slave and stub zones, + and clamp the SOA refresh and retry times to the specified + values. + + + + + + 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. + + + + + + max-udp-size + + + Sets the maximum EDNS UDP message size named will + send in bytes. Valid values are 512 to 4096 (values outside + this range will be silently adjusted). The default + value is 4096. The usual reason for setting + max-udp-size to a non-default value is to get UDP + answers to pass through broken firewalls that + block fragmented packets and/or block UDP packets + that are greater than 512 bytes. + This is independent of the advertised receive + buffer (edns-udp-size). + + + + + + masterfile-format + + Specifies + the file format of zone files (see + ). + The default value is text, which is the + standard textual representation. Files in other formats + than text are typically expected + to be generated by the named-compilezone tool. + Note that when a zone file in a different format than + text is loaded, named + may omit some of the checks which would be performed for a + file in the text format. In particular, + check-names checks do not apply + for the raw format. This means + a zone file in the raw format + must be generated with the same check level as that + specified in the named configuration + file. This statement sets the + masterfile-format for all zones, + but can be overridden on a per-zone or per-view basis + by including a masterfile-format + statement within the zone or + view block in the configuration + file. + + + + + + clients-per-query + max-clients-per-query + + These set the + initial value (minimum) and maximum number of recursive + simultaneous clients for any given query + (<qname,qtype,qclass>) that the server will accept + before dropping additional clients. named will attempt to + self tune this value and changes will be logged. The + default values are 10 and 100. + + + This value should reflect how many queries come in for + a given name in the time it takes to resolve that name. + If the number of queries exceed this value, named will + assume that it is dealing with a non-responsive zone + and will drop additional queries. If it gets a response + after dropping queries, it will raise the estimate. The + estimate will then be lowered in 20 minutes if it has + remained unchanged. + + + If clients-per-query is set to zero, + then there is no limit on the number of clients per query + and no queries will be dropped. + + + If max-clients-per-query is set to zero, + then there is no upper bound other than imposed by + recursive-clients. + + + + + + notify-delay + + + The delay, in seconds, between sending sets of notify + messages for a zone. The default is zero. + + + + + + + + + Built-in server information zones + + + The server provides some helpful diagnostic information + through a number of built-in zones under the + pseudo-top-level-domain bind in the + CHAOS class. These zones are part + of a + built-in view (see ) of + class + CHAOS which is separate from the + default view of + class IN; therefore, any global + server options + such as allow-query do not apply + the these zones. + If you feel the need to disable these zones, use the options + below, or hide the built-in CHAOS + view by + defining an explicit view of class CHAOS + that matches all clients. + + + + + + version + + + The version the server should report + via a query of the name version.bind + with type TXT, class CHAOS. + The default is the real version number of this server. + Specifying version none + disables processing of the queries. + + + + + + hostname + + + The hostname the server should report via a query of + the name hostname.bind + with type TXT, class CHAOS. + This defaults to the hostname of the machine hosting the + name server as + found by the gethostname() function. The primary purpose of such queries + is to + identify which of a group of anycast servers is actually + answering your queries. Specifying hostname none; + disables processing of the queries. + + + + + + server-id + + + The ID the server should report when receiving a Name + Server Identifier (NSID) query, or a query of the name + ID.SERVER with type + TXT, class CHAOS. + The primary purpose of such queries is to + 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 + use the hostname as found by the gethostname() function. + The default server-id is none. + + + + + + + + + + Built-in Empty Zones + + Named has some built-in empty zones (SOA and NS records only). + These are for zones that should normally be answered locally + and which queries should not be sent to the Internet's root + servers. The official servers which cover these namespaces + return NXDOMAIN responses to these queries. In particular, + these cover the reverse namespace for addresses from RFC 1918 and + RFC 3330. They also include the reverse namespace for IPv6 local + address (locally assigned), IPv6 link local addresses, the IPv6 + loopback address and the IPv6 unknown address. + + + 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 create a empty zone in that case. + + + The current list of empty zones is: + + + 0.IN-ADDR.ARPA + 127.IN-ADDR.ARPA + 254.169.IN-ADDR.ARPA + 2.0.192.IN-ADDR.ARPA + 255.255.255.255.IN-ADDR.ARPA + 0.0.0.0.0.0.0.0.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 + D.F.IP6.ARPA + 8.E.F.IP6.ARPA + 9.E.F.IP6.ARPA + A.E.F.IP6.ARPA + B.E.F.IP6.ARPA + + + + Empty zones are settable at the view level and only apply to + views of class IN. Disabled empty zones are only inherited + from options if there are no disabled empty zones specified + at the view level. To override the options list of disabled + zones, you can disable the root zone at the view level, for example: + + disable-empty-zone "."; + + + + If you are using the address ranges covered here, you should + already have reverse zones covering the addresses you use. + In practice this appears to not be the case with many queries + being made to the infrastructure servers for names in these + spaces. So many in fact that sacrificial servers were needed + to be deployed to channel the query load away from the + infrastructure servers. + + + The real parent servers for these zones should disable all + empty zone under the parent zone they serve. For the real + root servers, this is all built in empty zones. This will + enable them to return referrals to deeper in the tree. + + + + empty-server + + + Specify what server name will appear in the returned + SOA record for empty zones. If none is specified, then + the zone's name will be used. + + + + + + empty-contact + + + Specify what contact name will appear in the returned + SOA record for empty zones. If none is specified, then + "." will be used. + + + + + + empty-zones-enable + + + Enable or disable all empty zones. By default they + are enabled. + + + + + + disable-empty-zone + + + Disable individual empty zones. By default none are + disabled. This option can be specified multiple times. + + + + + + + + Additional Section Caching + + + The additional section cache, also called acache, + is an internal cache to improve the response performance of BIND 9. + When additional section caching is enabled, BIND 9 will + cache an internal short-cut to the additional section content for + each answer RR. + Note that acache is an internal caching + mechanism of BIND 9, and is not related to the DNS caching + server function. + + + + Additional section caching does not change the + response content (except the RRsets ordering of the additional + section, see below), but can improve the response performance + significantly. + It is particularly effective when BIND 9 acts as an authoritative + server for a zone that has many delegations with many glue RRs. + + + + In order to obtain the maximum performance improvement + from additional section caching, setting + additional-from-cache + to no is recommended, since the current + implementation of acache + does not short-cut of additional section information from the + DNS cache data. + + + + One obvious disadvantage of acache is + that it requires much more + memory for the internal cached data. + Thus, if the response performance does not matter and memory + consumption is much more critical, the + acache mechanism can be + disabled by setting acache-enable to + no. + It is also possible to specify the upper limit of memory + consumption + for acache by using max-acache-size. + + + + Additional section caching also has a minor effect on the + RRset ordering in the additional section. + Without acache, + cyclic order is effective for the additional + section as well as the answer and authority sections. + However, additional section caching fixes the ordering when it + first caches an RRset for the additional section, and the same + ordering will be kept in succeeding responses, regardless of the + setting of rrset-order. + The effect of this should be minor, however, since an + RRset in the additional section + typically only contains a small number of RRs (and in many cases + it only contains a single RR), in which case the + ordering does not matter much. + + + + The following is a summary of options related to + acache. + + + + + + acache-enable + + + If yes, additional section caching is + enabled. The default value is no. + + + + + + acache-cleaning-interval + + + The server will remove stale cache entries, based on an LRU + based + algorithm, every acache-cleaning-interval minutes. + The default is 60 minutes. + If set to 0, no periodic cleaning will occur. + + + + + + max-acache-size + + + The maximum amount of memory in bytes to use for the server's acache. + When the amount of data in the acache reaches this limit, + the server + will clean more aggressively so that the limit is not + exceeded. + In a server with multiple views, the limit applies + separately to the + acache of each view. + The default is 16M. + + + + + + + + + + + + <command>statistics-channels</command> Statement Grammar + +statistics-channels { + [ inet ( ip_addr | * ) [ port ip_port ] [allow { address_match_list } ]; ] + [ inet ...; ] +}; + + + + + <command>statistics-channels</command> Statement Definition and + Usage + + + The statistics-channels statement + declares communication channels to be used by system + administrators to get access to statistics information of + the name server. + + + + This statement intends to be flexible to support multiple + communication protocols in the future, but currently only + HTTP access is supported. + It requires that BIND 9 be compiled with libxml2; + the statistics-channels statement is + still accepted even if it is built without the library, + but any HTTP access will fail with an error. + + + + An inet control channel is a TCP socket + listening at the specified ip_port on the + specified ip_addr, which can be an IPv4 or IPv6 + address. An ip_addr of * (asterisk) is + interpreted as the IPv4 wildcard address; connections will be + accepted on any of the system's IPv4 addresses. + To listen on the IPv6 wildcard address, + use an ip_addr of ::. + + + + If no port is specified, port 80 is used for HTTP channels. + The asterisk "*" cannot be used for + ip_port. + + + + The attempt of opening a statistics channel is + restricted by the optional allow clause. + Connections to the statistics channel are permitted based on the + address_match_list. + If no allow clause is present, + named accepts connection + attempts from any address; since the statistics may + contain sensitive internal information, it is highly + recommended to restrict the source of connection requests + appropriately. + + + + If no statistics-channels statement is present, + named will not open any communication channels. + + + + + + <command>server</command> Statement Grammar + +server ip_addr[/prefixlen] { + bogus yes_or_no ; + provide-ixfr yes_or_no ; + request-ixfr yes_or_no ; + edns yes_or_no ; + edns-udp-size number ; + max-udp-size number ; + transfers number ; + transfer-format ( one-answer | many-answers ) ; ] + keys { string ; string ; ... } ; + transfer-source (ip4_addr | *) port ip_port ; + transfer-source-v6 (ip6_addr | *) port ip_port ; + notify-source (ip4_addr | *) port ip_port ; + notify-source-v6 (ip6_addr | *) port ip_port ; + query-source address ( ip_addr | * ) port ( ip_port | * ) ; + query-source-v6 address ( ip_addr | * ) port ( ip_port | * ) ; + use-queryport-pool yes_or_no; + queryport-pool-ports number; + queryport-pool-interval number; +}; + + + + + + <command>server</command> Statement Definition and + Usage + + + The server statement defines + characteristics + to be associated with a remote name server. If a prefix length is + specified, then a range of servers is covered. Only the most + specific + server clause applies regardless of the order in + named.conf. + + + + The server statement can occur at + the top level of the + configuration file or inside a view + statement. + If a view statement contains + one or more server statements, only + those + apply to the view and any top-level ones are ignored. + If a view contains no server + statements, + any top-level server statements are + used as + defaults. + + + + If you discover that a remote server is giving out bad data, + marking it as bogus will prevent further queries to it. The + default + value of bogus is no. + + + The provide-ixfr clause determines + whether + the local server, acting as master, will respond with an + incremental + zone transfer when the given remote server, a slave, requests it. + If set to yes, incremental transfer + will be provided + whenever possible. If set to no, + all transfers + to the remote server will be non-incremental. If not set, the + value + of the provide-ixfr option in the + view or + global options block is used as a default. + + + + The request-ixfr clause determines + whether + the local server, acting as a slave, will request incremental zone + transfers from the given remote server, a master. If not set, the + value of the request-ixfr option in + the view or + global options block is used as a default. + + + + IXFR requests to servers that do not support IXFR will + automatically + fall back to AXFR. Therefore, there is no need to manually list + which servers support IXFR and which ones do not; the global + default + of yes should always work. + The purpose of the provide-ixfr and + request-ixfr clauses is + to make it possible to disable the use of IXFR even when both + master + and slave claim to support it, for example if one of the servers + is buggy and crashes or corrupts data when IXFR is used. + + + + The edns clause determines whether + the local server will attempt to use EDNS when communicating + with the remote server. The default is yes. + + + + The edns-udp-size option sets the EDNS UDP size + that is advertised by named when querying the remote server. + Valid values are 512 to 4096 bytes (values outside this range will be + silently adjusted). This option is useful when you wish to + advertises a different value to this server than the value you + advertise globally, for example, when there is a firewall at the + remote site that is blocking large replies. + + + + The max-udp-size option sets the + maximum EDNS UDP message size named will send. Valid + values are 512 to 4096 bytes (values outside this range will + be silently adjusted). This option is useful when you + know that there is a firewall that is blocking large + replies from named. + + + + The server supports two zone transfer methods. The first, one-answer, + uses one DNS message per resource record transferred. many-answers packs + as many resource records as possible into a message. many-answers is + more efficient, but is only known to be understood by BIND 9, BIND + 8.x, and patched versions of BIND + 4.9.5. You can specify which method + to use for a server with the transfer-format option. + If transfer-format is not + specified, the transfer-format + specified + by the options statement will be + used. + + + transfers + is used to limit the number of concurrent inbound zone + transfers from the specified server. If no + transfers clause is specified, the + limit is set according to the + transfers-per-ns option. + + + + The keys clause identifies a + key_id defined by the key statement, + to be used for transaction security (TSIG, ) + when talking to the remote server. + When a request is sent to the remote server, a request signature + will be generated using the key specified here and appended to the + message. A request originating from the remote server is not + required + to be signed by this key. + + + + Although the grammar of the keys + clause + allows for multiple keys, only a single key per server is + currently + supported. + + + + The transfer-source and + transfer-source-v6 clauses specify + the IPv4 and IPv6 source + address to be used for zone transfer with the remote server, + respectively. + For an IPv4 remote server, only transfer-source can + be specified. + Similarly, for an IPv6 remote server, only + transfer-source-v6 can be + specified. + For more details, see the description of + transfer-source and + transfer-source-v6 in + . + + + + The notify-source and + notify-source-v6 clauses specify the + IPv4 and IPv6 source address to be used for notify + messages sent to remote servers, respectively. For an + IPv4 remote server, only notify-source + can be specified. Similarly, for an IPv6 remote server, + only notify-source-v6 can be specified. + + + + The query-source and + query-source-v6 clauses specify the + IPv4 and IPv6 source address to be used for queries + sent to remote servers, respectively. For an IPv4 + remote server, only query-source can + be specified. Similarly, for an IPv6 remote server, + only query-source-v6 can be specified. + + + + + + <command>trusted-keys</command> Statement Grammar + +trusted-keys { + string number number number string ; + string number number number string ; ... +}; + + + + + <command>trusted-keys</command> Statement Definition + and Usage + + The trusted-keys statement defines + DNSSEC security roots. DNSSEC is described in . A security root is defined when the + public key for a non-authoritative zone is known, but + cannot be securely obtained through DNS, either because + it is the DNS root zone or because its parent zone is + unsigned. Once a key has been configured as a trusted + key, it is treated as if it had been validated and + proven secure. The resolver attempts DNSSEC validation + on all DNS data in subdomains of a security root. + + + All keys (and corresponding zones) listed in + trusted-keys are deemed to exist regardless + of what parent zones say. Similarly for all keys listed in + trusted-keys only those keys are + used to validate the DNSKEY RRset. The parent's DS RRset + will not be used. + + + The trusted-keys statement can contain + multiple key entries, each consisting of the key's + domain name, flags, protocol, algorithm, and the Base-64 + representation of the key data. + Spaces, tabs, newlines and carriage returns are ignored + in the key data, so the configuration may be split up into + multiple lines. + + + + + <command>view</command> Statement Grammar + +view view_name + class { + match-clients { address_match_list }; + match-destinations { address_match_list }; + match-recursive-only yes_or_no ; + view_option; ... + zone_statement; ... +}; + + + + + <command>view</command> Statement Definition and Usage + + + The view statement is a powerful + feature + of BIND 9 that lets a name server + answer a DNS query differently + depending on who is asking. It is particularly useful for + implementing + split DNS setups without having to run multiple servers. + + + + Each view statement defines a view + of the + DNS namespace that will be seen by a subset of clients. A client + matches + a view if its source IP address matches the + address_match_list of the view's + match-clients clause and its + destination IP address matches + the address_match_list of the + view's + match-destinations clause. If not + specified, both + match-clients and match-destinations + default to matching all addresses. In addition to checking IP + addresses + match-clients and match-destinations + can also take keys which provide an + mechanism for the + client to select the view. A view can also be specified + as match-recursive-only, which + means that only recursive + requests from matching clients will match that view. + The order of the view statements is + significant — + a client request will be resolved in the context of the first + view that it matches. + + + + Zones defined within a view + statement will + only be accessible to clients that match the view. + By defining a zone of the same name in multiple views, different + zone data can be given to different clients, for example, + "internal" + and "external" clients in a split DNS setup. + + + + Many of the options given in the options statement + can also be used within a view + statement, and then + apply only when resolving queries with that view. When no + view-specific + value is given, the value in the options statement + is used as a default. Also, zone options can have default values + specified + in the view statement; these + view-specific defaults + take precedence over those in the options statement. + + + + Views are class specific. If no class is given, class IN + is assumed. Note that all non-IN views must contain a hint zone, + since only the IN class has compiled-in default hints. + + + + If there are no view statements in + the config + file, a default view that matches any client is automatically + created + in class IN. Any zone statements + specified on + the top level of the configuration file are considered to be part + of + this default view, and the options + statement will + apply to the default view. If any explicit view + statements are present, all zone + statements must + occur inside view statements. + + + + Here is an example of a typical split DNS setup implemented + using view statements: + + +view "internal" { + // This should match our internal networks. + match-clients { 10.0.0.0/8; }; + + // Provide recursive service to internal clients only. + recursion yes; + + // Provide a complete view of the example.com zone + // including addresses of internal hosts. + zone "example.com" { + type master; + file "example-internal.db"; + }; +}; + +view "external" { + // Match all clients not matched by the previous view. + match-clients { any; }; + + // Refuse recursive service to external clients. + recursion no; + + // Provide a restricted view of the example.com zone + // containing only publicly accessible hosts. + zone "example.com" { + type master; + file "example-external.db"; + }; +}; + + + + + <command>zone</command> + Statement Grammar + +zone zone_name class { + type master; + allow-query { address_match_list }; + allow-query-on { address_match_list }; + allow-transfer { address_match_list }; + allow-update { address_match_list }; + update-policy { update_policy_rule ... }; + also-notify { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + check-names (warn|fail|ignore) ; + check-mx (warn|fail|ignore) ; + check-wildcard yes_or_no; + check-integrity yes_or_no ; + dialup dialup_option ; + 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 ; + max-transfer-idle-out number ; + max-transfer-time-out number ; + notify yes_or_no | explicit | master-only ; + notify-delay seconds ; + notify-to-soa yes_or_no; + pubkey number number number string ; + notify-source (ip4_addr | *) port ip_port ; + notify-source-v6 (ip6_addr | *) port ip_port ; + zone-statistics yes_or_no ; + sig-validity-interval number ; + sig-signing-nodes number ; + sig-signing-signatures number ; + sig-signing-type number ; + database string ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + key-directory path_name; + zero-no-soa-ttl yes_or_no ; +}; + +zone zone_name class { + type slave; + allow-notify { address_match_list }; + allow-query { address_match_list }; + allow-query-on { address_match_list }; + allow-transfer { address_match_list }; + allow-update-forwarding { address_match_list }; + update-check-ksk yes_or_no; + try-tcp-refresh yes_or_no; + also-notify { ip_addr port ip_port ; ip_addr port ip_port ; ... }; + check-names (warn|fail|ignore) ; + dialup dialup_option ; + 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 ) ; ... }; + max-ixfr-log-size number ; + max-transfer-idle-in number ; + max-transfer-idle-out number ; + max-transfer-time-in number ; + max-transfer-time-out number ; + notify yes_or_no | explicit | master-only ; + notify-delay seconds ; + notify-to-soa yes_or_no; + pubkey number number number string ; + transfer-source (ip4_addr | *) port ip_port ; + transfer-source-v6 (ip6_addr | *) port ip_port ; + alt-transfer-source (ip4_addr | *) port ip_port ; + alt-transfer-source-v6 (ip6_addr | *) port ip_port ; + use-alt-transfer-source yes_or_no; + notify-source (ip4_addr | *) port ip_port ; + notify-source-v6 (ip6_addr | *) port ip_port ; + zone-statistics yes_or_no ; + database string ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + multi-master yes_or_no ; + zero-no-soa-ttl yes_or_no ; +}; + +zone zone_name class { + type hint; + file string ; + delegation-only yes_or_no ; + check-names (warn|fail|ignore) ; // Not Implemented. +}; + +zone zone_name class { + type stub; + allow-query { address_match_list }; + allow-query-on { address_match_list }; + check-names (warn|fail|ignore) ; + dialup dialup_option ; + delegation-only yes_or_no ; + file string ; + masterfile-format (text|raw) ; + forward (only|first) ; + forwarders { ip_addr port ip_port ; ... }; + masters port ip_port { ( masters_list | ip_addr port ip_port key key ) ; ... }; + max-transfer-idle-in number ; + max-transfer-time-in number ; + pubkey number number number string ; + transfer-source (ip4_addr | *) port ip_port ; + transfer-source-v6 (ip6_addr | *) port ip_port ; + alt-transfer-source (ip4_addr | *) port ip_port ; + alt-transfer-source-v6 (ip6_addr | *) port ip_port ; + use-alt-transfer-source yes_or_no; + zone-statistics yes_or_no ; + database string ; + min-refresh-time number ; + max-refresh-time number ; + min-retry-time number ; + max-retry-time number ; + multi-master yes_or_no ; +}; + +zone zone_name class { + type forward; + forward (only|first) ; + forwarders { ip_addr port ip_port ; ... }; + delegation-only yes_or_no ; +}; + +zone zone_name class { + type delegation-only; +}; + + + + + + <command>zone</command> Statement Definition and Usage + + Zone Types + + + + + + + + + + + master + + + + + The server has a master copy of the data + for the zone and will be able to provide authoritative + answers for + it. + + + + + + + slave + + + + + A slave zone is a replica of a master + zone. The masters list + specifies one or more IP addresses + of master servers that the slave contacts to update + its copy of the zone. + Masters list elements can also be names of other + masters lists. + By default, transfers are made from port 53 on the + servers; this can + be changed for all servers by specifying a port number + before the + list of IP addresses, or on a per-server basis after + the IP address. + Authentication to the master can also be done with + per-server TSIG keys. + If a file is specified, then the + replica will be written to this file whenever the zone + is changed, + and reloaded from this file on a server restart. Use + of a file is + recommended, since it often speeds server startup and + eliminates + a needless waste of bandwidth. Note that for large + numbers (in the + tens or hundreds of thousands) of zones per server, it + is best to + use a two-level naming scheme for zone filenames. For + example, + a slave server for the zone example.com might place + the zone contents into a file called + 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 + a single directory.) + + + + + + + stub + + + + + A stub zone is similar to a slave zone, + except that it replicates only the NS records of a + master zone instead + of the entire zone. Stub zones are not a standard part + of the DNS; + they are a feature specific to the BIND implementation. + + + + Stub zones can be used to eliminate the need for glue + NS record + in a parent zone at the expense of maintaining a stub + zone entry and + a set of name server addresses in named.conf. + This usage is not recommended for new configurations, + and BIND 9 + supports it only in a limited way. + In BIND 4/8, zone + transfers of a parent zone + included the NS records from stub children of that + zone. This meant + that, in some cases, users could get away with + configuring child stubs + only in the master server for the parent zone. BIND + 9 never mixes together zone data from different zones + in this + way. Therefore, if a BIND 9 master serving a parent + zone has child stub zones configured, all the slave + servers for the + parent zone also need to have the same child stub + zones + configured. + + + + Stub zones can also be used as a way of forcing the + resolution + of a given domain to use a particular set of + authoritative servers. + For example, the caching name servers on a private + network using + RFC1918 addressing may be configured with stub zones + for + 10.in-addr.arpa + to use a set of internal name servers as the + authoritative + servers for that domain. + + + + + + + forward + + + + + A "forward zone" is a way to configure + forwarding on a per-domain basis. A zone statement + of type forward can + contain a forward + and/or forwarders + statement, + which will apply to queries within the domain given by + the zone + name. If no forwarders + statement is present or + an empty list for forwarders is given, then no + forwarding will be done for the domain, canceling the + effects of + any forwarders in the options statement. Thus + if you want to use this type of zone to change the + behavior of the + global forward option + (that is, "forward first" + to, then "forward only", or vice versa, but want to + use the same + servers as set globally) you need to re-specify the + global forwarders. + + + + + + + hint + + + + + The initial set of root name servers is + specified using a "hint zone". When the server starts + up, it uses + the root hints to find a root name server and get the + most recent + list of root name servers. If no hint zone is + specified for class + IN, the server uses a compiled-in default set of root + servers hints. + Classes other than IN have no built-in defaults hints. + + + + + + + delegation-only + + + + + 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. + + + + + + + + + + Class + + The zone's name may optionally be followed by a class. If + a class is not specified, class IN (for Internet), + is assumed. This is correct for the vast majority of cases. + + + The hesiod class is + named for an information service from MIT's Project Athena. It + is + used to share information about various systems databases, such + as users, groups, printers and so on. The keyword + HS is + a synonym for hesiod. + + + Another MIT development is Chaosnet, a LAN protocol created + in the mid-1970s. Zone data for it can be specified with the CHAOS class. + + + + + Zone Options + + + + + allow-notify + + + See the description of + allow-notify in . + + + + + + allow-query + + + See the description of + allow-query in . + + + + + + allow-query-on + + + See the description of + allow-query-on in . + + + + + + allow-transfer + + + See the description of allow-transfer + in . + + + + + + allow-update + + + See the description of allow-update + in . + + + + + + update-policy + + + Specifies a "Simple Secure Update" policy. See + . + + + + + + allow-update-forwarding + + + See the description of allow-update-forwarding + in . + + + + + + also-notify + + + Only meaningful if notify + is + active for this zone. The set of machines that will + receive a + DNS NOTIFY message + for this zone is made up of all the listed name servers + (other than + the primary master) for the zone plus any IP addresses + specified + with also-notify. A port + may be specified + with each also-notify + address to send the notify + messages to a port other than the default of 53. + also-notify is not + meaningful for stub zones. + The default is the empty list. + + + + + + check-names + + + This option is used to restrict the character set and + syntax of + certain domain names in master files and/or DNS responses + received from the + network. The default varies according to zone type. For master zones the default is fail. For slave + zones the default is warn. + + + + + + check-mx + + + See the description of + check-mx in . + + + + + + check-wildcard + + + See the description of + check-wildcard in . + + + + + + check-integrity + + + See the description of + check-integrity in . + + + + + + check-sibling + + + See the description of + check-sibling in . + + + + + + zero-no-soa-ttl + + + See the description of + zero-no-soa-ttl in . + + + + + + update-check-ksk + + + See the description of + update-check-ksk in . + + + + + + try-tcp-refresh + + + See the description of + try-tcp-refresh in . + + + + + + database + + + Specify the type of database to be used for storing the + zone data. The string following the database keyword + is interpreted as a list of whitespace-delimited words. + The first word + identifies the database type, and any subsequent words are + passed + as arguments to the database to be interpreted in a way + specific + to the database type. + + + The default is "rbt", BIND 9's + native in-memory + red-black-tree database. This database does not take + arguments. + + + Other values are possible if additional database drivers + have been linked into the server. Some sample drivers are + included + with the distribution but none are linked in by default. + + + + + + dialup + + + See the description of + dialup in . + + + + + + 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. + + + + + + forward + + + Only meaningful if the zone has a forwarders + list. The only value causes + the lookup to fail + after trying the forwarders and getting no answer, while first would + allow a normal lookup to be tried. + + + + + + forwarders + + + Used to override the list of global forwarders. + If it is not specified in a zone of type forward, + no forwarding is done for the zone and the global options are + not used. + + + + + + ixfr-base + + + Was used in BIND 8 to + specify the name + of the transaction log (journal) file for dynamic update + and IXFR. + BIND 9 ignores the option + and constructs the name of the journal + file by appending ".jnl" + to the name of the + zone file. + + + + + + ixfr-tmp-file + + + Was an undocumented option in BIND 8. + Ignored in BIND 9. + + + + + + journal + + + Allow the default journal's filename to be overridden. + The default is the zone's filename with ".jnl" appended. + This is applicable to master and slave zones. + + + + + + max-journal-size + + + See the description of + max-journal-size in . + + + + + + max-transfer-time-in + + + See the description of + max-transfer-time-in in . + + + + + + max-transfer-idle-in + + + See the description of + max-transfer-idle-in in . + + + + + + max-transfer-time-out + + + See the description of + max-transfer-time-out in . + + + + + + max-transfer-idle-out + + + See the description of + max-transfer-idle-out in . + + + + + + notify + + + See the description of + notify in . + + + + + + notify-delay + + + See the description of + notify-delay in . + + + + + + notify-to-soa + + + See the description of + notify-to-soa in + . + + + + + + pubkey + + + In BIND 8, this option was + intended for specifying + a public zone key for verification of signatures in DNSSEC + signed + zones when they are loaded from disk. BIND 9 does not verify signatures + on load and ignores the option. + + + + + + zone-statistics + + + If yes, the server will keep + statistical + information for this zone, which can be dumped to the + statistics-file defined in + the server options. + + + + + + sig-validity-interval + + + See the description of + sig-validity-interval in . + + + + + + sig-signing-nodes + + + See the description of + sig-signing-nodes in . + + + + + + sig-signing-signatures + + + See the description of + sig-signing-signatures in . + + + + + + sig-signing-type + + + See the description of + sig-signing-type in . + + + + + + transfer-source + + + See the description of + transfer-source in . + + + + + + transfer-source-v6 + + + See the description of + transfer-source-v6 in . + + + + + + alt-transfer-source + + + See the description of + alt-transfer-source in . + + + + + + alt-transfer-source-v6 + + + See the description of + alt-transfer-source-v6 in . + + + + + + use-alt-transfer-source + + + See the description of + use-alt-transfer-source in . + + + + + + + notify-source + + + See the description of + notify-source in . + + + + + + notify-source-v6 + + + See the description of + notify-source-v6 in . + + + + + + min-refresh-time + max-refresh-time + min-retry-time + max-retry-time + + + See the description in . + + + + + + ixfr-from-differences + + + 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.) + + + + + + key-directory + + + See the description of + key-directory in . + + + + + + multi-master + + + See the description of multi-master in + . + + + + + + masterfile-format + + + See the description of masterfile-format + in . + + + + + + + + + Dynamic Update Policies + BIND 9 supports two alternative + methods of granting clients the right to perform + dynamic updates to a zone, configured by the + allow-update and + update-policy option, respectively. + + + The allow-update clause works the + same way as in previous versions of BIND. + It grants given clients the permission to update any + record of any name in the zone. + + + The update-policy clause is new + in BIND 9 and allows more fine-grained + control over what updates are allowed. A set of rules + is specified, where each rule either grants or denies + permissions for one or more names to be updated by + one or more identities. If the dynamic update request + message is signed (that is, it includes either a TSIG + or SIG(0) record), the identity of the signer can be + determined. + + + Rules are specified in the update-policy + zone option, and are only meaningful for master zones. + When the update-policy statement + is present, it is a configuration error for the + allow-update statement to be + present. The update-policy statement + only examines the signer of a message; the source + address is not relevant. + + + + This is how a rule definition looks: + + + +( grant | deny ) identity nametype name types + + + + Each rule grants or denies privileges. Once a message has + successfully matched a rule, the operation is immediately + granted + or denied and no further rules are examined. A rule is matched + when the signer matches the identity field, the name matches the + name field in accordance with the nametype field, and the type + matches + the types specified in the type field. + + + No signer is required for tcp-self + or 6to4-self however the standard + reverse mapping / prefix conversion must match the identity + field. + + + The identity field specifies a name or a wildcard + name. Normally, this is the name of the TSIG or + SIG(0) key used to sign the update request. When a + TKEY exchange has been used to create a shared secret, + the identity of the shared secret is the same as the + identity of the key used to authenticate the TKEY + exchange. TKEY is also the negotiation method used + by GSS-TSIG, which establishes an identity that is + the Kerberos principal of the client, such as + "user@host.domain". When the + identity field specifies + a wildcard name, it is subject to DNS wildcard + expansion, so the rule will apply to multiple identities. + The identity field must + contain a fully-qualified domain name. + + + + The nametype field has 12 + values: + name, subdomain, + wildcard, self, + selfsub, selfwild, + krb5-self, ms-self, + krb5-subdomain, + ms-subdomain, + tcp-self and 6to4-self. + + + + + + + + + + name + + + + Exact-match semantics. This rule matches + when the name being updated is identical + to the contents of the + name field. + + + + + + + subdomain + + + + This rule matches when the name being updated + is a subdomain of, or identical to, the + contents of the name + field. + + + + + + + wildcard + + + + The name field + is subject to DNS wildcard expansion, and + this rule matches when the name being updated + name is a valid expansion of the wildcard. + + + + + + + self + + + + + This rule matches when the name being updated + matches the contents of the + identity field. + The name field + is ignored, but should be the same as the + identity field. + The self nametype is + most useful when allowing using one key per + name to update, where the key has the same + name as the name to be updated. The + identity would + be specified as * (an asterisk) in + this case. + + + + + + + selfsub + + + + This rule is similar to self + except that subdomains of self + can also be updated. + + + + + + + selfwild + + + + This rule is similar to self + except that only subdomains of + self can be updated. + + + + + + + tcp-self + + + + Allow updates that have been sent via TCP and + for which the standard mapping from the initiating + IP address into the IN-ADDR.ARPA and IP6.ARPA + namespaces match the name to be updated. + + + It is theoretically possible to spoof these TCP + sessions. + + + + + + + 6to4-self + + + + Allow the 6to4 prefix to be update by any TCP + conection from the 6to4 network or from the + corresponding IPv4 address. This is intended + to allow NS or DNAME RRsets to be added to the + reverse tree. + + + It is theoretically possible to spoof these TCP + sessions. + + + + + + + + + In all cases, the name + field must + specify a fully-qualified domain name. + + + + If no types are explicitly specified, this rule matches + all types except RRSIG, NS, SOA, NSEC and NSEC3. Types + may be specified by name, including "ANY" (ANY matches + all types except NSEC and NSEC3, which can never be + updated). Note that when an attempt is made to delete + all records associated with a name, the rules are + checked for each existing record type. + + + + + + Zone File + + Types of Resource Records and When to Use Them + + This section, largely borrowed from RFC 1034, describes the + concept of a Resource Record (RR) and explains when each is used. + Since the publication of RFC 1034, several new RRs have been + identified + and implemented in the DNS. These are also included. + + + Resource Records + + + A domain name identifies a node. Each node has a set of + resource information, which may be empty. The set of resource + information associated with a particular name is composed of + separate RRs. The order of RRs in a set is not significant and + need not be preserved by name servers, resolvers, or other + parts of the DNS. However, sorting of multiple RRs is + permitted for optimization purposes, for example, to specify + that a particular nearby server be tried first. See and . + + + + The components of a Resource Record are: + + + + + + + + + + owner name + + + + + The domain name where the RR is found. + + + + + + + type + + + + + An encoded 16-bit value that specifies + the type of the resource record. + + + + + + + TTL + + + + + The time-to-live of the RR. This field + is a 32-bit integer in units of seconds, and is + primarily used by + resolvers when they cache RRs. The TTL describes how + long a RR can + be cached before it should be discarded. + + + + + + + class + + + + + An encoded 16-bit value that identifies + a protocol family or instance of a protocol. + + + + + + + RDATA + + + + + The resource data. The format of the + data is type (and sometimes class) specific. + + + + + + + + The following are types of valid RRs: + + + + + + + + + + A + + + + + A host address. In the IN class, this is a + 32-bit IP address. Described in RFC 1035. + + + + + + + AAAA + + + + + IPv6 address. Described in RFC 1886. + + + + + + + A6 + + + + + IPv6 address. This can be a partial + address (a suffix) and an indirection to the name + where the rest of the + address (the prefix) can be found. Experimental. + Described in RFC 2874. + + + + + + + AFSDB + + + + + Location of AFS database servers. + Experimental. Described in RFC 1183. + + + + + + + APL + + + + + Address prefix list. Experimental. + Described in RFC 3123. + + + + + + + CERT + + + + + Holds a digital certificate. + Described in RFC 2538. + + + + + + + CNAME + + + + + Identifies the canonical name of an alias. + Described in RFC 1035. + + + + + + + DHCID + + + + + Is used for identifying which DHCP client is + associated with this name. Described in RFC 4701. + + + + + + + DNAME + + + + + Replaces the domain name specified with + another name to be looked up, effectively aliasing an + entire + subtree of the domain name space rather than a single + record + as in the case of the CNAME RR. + Described in RFC 2672. + + + + + + + DNSKEY + + + + + Stores a public key associated with a signed + DNS zone. Described in RFC 4034. + + + + + + + DS + + + + + Stores the hash of a public key associated with a + signed DNS zone. Described in RFC 4034. + + + + + + + GPOS + + + + + Specifies the global position. Superseded by LOC. + + + + + + + HINFO + + + + + Identifies the CPU and OS used by a host. + Described in RFC 1035. + + + + + + + IPSECKEY + + + + + Provides a method for storing IPsec keying material in + DNS. Described in RFC 4025. + + + + + + + ISDN + + + + + Representation of ISDN addresses. + Experimental. Described in RFC 1183. + + + + + + + KEY + + + + + Stores a public key associated with a + DNS name. Used in original DNSSEC; replaced + by DNSKEY in DNSSECbis, but still used with + SIG(0). Described in RFCs 2535 and 2931. + + + + + + + KX + + + + + Identifies a key exchanger for this + DNS name. Described in RFC 2230. + + + + + + + LOC + + + + + For storing GPS info. Described in RFC 1876. + Experimental. + + + + + + + MX + + + + + Identifies a mail exchange for the domain with + a 16-bit preference value (lower is better) + followed by the host name of the mail exchange. + Described in RFC 974, RFC 1035. + + + + + + + NAPTR + + + + + Name authority pointer. Described in RFC 2915. + + + + + + + NSAP + + + + + A network service access point. + Described in RFC 1706. + + + + + + + NS + + + + + The authoritative name server for the + domain. Described in RFC 1035. + + + + + + + NSEC + + + + + Used in DNSSECbis to securely indicate that + RRs with an owner name in a certain name interval do + not exist in + a zone and indicate what RR types are present for an + existing name. + Described in RFC 4034. + + + + + + + NSEC3 + + + + + Used in DNSSECbis to securely indicate that + RRs with an owner name in a certain name + interval do not exist in a zone and indicate + what RR types are present for an existing + name. NSEC3 differs from NSEC in that it + prevents zone enumeration but is more + computationally expensive on both the server + and the client than NSEC. Described in RFC + 5155. + + + + + + + NSEC3PARAM + + + + + Used in DNSSECbis to tell the authoritative + server which NSEC3 chains are available to use. + Described in RFC 5155. + + + + + + + NXT + + + + + Used in DNSSEC to securely indicate that + RRs with an owner name in a certain name interval do + not exist in + a zone and indicate what RR types are present for an + existing name. + Used in original DNSSEC; replaced by NSEC in + DNSSECbis. + Described in RFC 2535. + + + + + + + PTR + + + + + A pointer to another part of the domain + name space. Described in RFC 1035. + + + + + + + PX + + + + + Provides mappings between RFC 822 and X.400 + addresses. Described in RFC 2163. + + + + + + + RP + + + + + Information on persons responsible + for the domain. Experimental. Described in RFC 1183. + + + + + + + RRSIG + + + + + Contains DNSSECbis signature data. Described + in RFC 4034. + + + + + + + RT + + + + + Route-through binding for hosts that + do not have their own direct wide area network + addresses. + Experimental. Described in RFC 1183. + + + + + + + SIG + + + + + Contains DNSSEC signature data. Used in + original DNSSEC; replaced by RRSIG in + DNSSECbis, but still used for SIG(0). + Described in RFCs 2535 and 2931. + + + + + + + SOA + + + + + Identifies the start of a zone of authority. + Described in RFC 1035. + + + + + + + SPF + + + + + Contains the Sender Policy Framework information + for a given email domain. Described in RFC 4408. + + + + + + + SRV + + + + + Information about well known network + services (replaces WKS). Described in RFC 2782. + + + + + + + SSHFP + + + + + Provides a way to securely publish a secure shell key's + fingerprint. Described in RFC 4255. + + + + + + + TXT + + + + + Text records. Described in RFC 1035. + + + + + + + WKS + + + + + Information about which well known + network services, such as SMTP, that a domain + supports. Historical. + + + + + + + X25 + + + + + Representation of X.25 network addresses. + Experimental. Described in RFC 1183. + + + + + + + + The following classes of resource records + are currently valid in the DNS: + + + + + + + + + + IN + + + + + The Internet. + + + + + + + + CH + + + + + Chaosnet, a LAN protocol created at MIT in the + mid-1970s. + Rarely used for its historical purpose, but reused for + BIND's + built-in server information zones, e.g., + version.bind. + + + + + + + + HS + + + + + Hesiod, an information service + developed by MIT's Project Athena. It is used to share + information + about various systems databases, such as users, + groups, printers + and so on. + + + + + + + + + + The owner name is often implicit, rather than forming an + integral + part of the RR. For example, many name servers internally form + tree + or hash structures for the name space, and chain RRs off nodes. + The remaining RR parts are the fixed header (type, class, TTL) + which is consistent for all RRs, and a variable part (RDATA) + that + fits the needs of the resource being described. + + + The meaning of the TTL field is a time limit on how long an + RR can be kept in a cache. This limit does not apply to + authoritative + data in zones; it is also timed out, but by the refreshing + policies + for the zone. The TTL is assigned by the administrator for the + zone where the data originates. While short TTLs can be used to + minimize caching, and a zero TTL prohibits caching, the + realities + of Internet performance suggest that these times should be on + the + order of days for the typical host. If a change can be + anticipated, + the TTL can be reduced prior to the change to minimize + inconsistency + during the change, and then increased back to its former value + following + the change. + + + The data in the RDATA section of RRs is carried as a combination + of binary strings and domain names. The domain names are + frequently + used as "pointers" to other data in the DNS. + + + + Textual expression of RRs + + RRs are represented in binary form in the packets of the DNS + protocol, and are usually represented in highly encoded form + when + stored in a name server or resolver. In the examples provided + in + RFC 1034, a style similar to that used in master files was + employed + in order to show the contents of RRs. In this format, most RRs + are shown on a single line, although continuation lines are + possible + using parentheses. + + + The start of the line gives the owner of the RR. If a line + begins with a blank, then the owner is assumed to be the same as + that of the previous RR. Blank lines are often included for + readability. + + + Following the owner, we list the TTL, type, and class of the + RR. Class and type use the mnemonics defined above, and TTL is + an integer before the type field. In order to avoid ambiguity + in + parsing, type and class mnemonics are disjoint, TTLs are + integers, + and the type mnemonic is always last. The IN class and TTL + values + are often omitted from examples in the interests of clarity. + + + The resource data or RDATA section of the RR are given using + knowledge of the typical representation for the data. + + + For example, we might show the RRs carried in a message as: + + + + + + + + + + ISI.EDU. + + + + + MX + + + + + 10 VENERA.ISI.EDU. + + + + + + + + + + MX + + + + + 10 VAXA.ISI.EDU + + + + + + + VENERA.ISI.EDU + + + + + A + + + + + 128.9.0.32 + + + + + + + + + + A + + + + + 10.1.0.52 + + + + + + + VAXA.ISI.EDU + + + + + A + + + + + 10.2.0.27 + + + + + + + + + + A + + + + + 128.9.0.33 + + + + + + + + The MX RRs have an RDATA section which consists of a 16-bit + number followed by a domain name. The address RRs use a + standard + IP address format to contain a 32-bit internet address. + + + The above example shows six RRs, with two RRs at each of three + domain names. + + + Similarly we might see: + + + + + + + + + + XX.LCS.MIT.EDU. + + + + + IN A + + + + + 10.0.0.44 + + + + + + + + CH A + + + + + MIT.EDU. 2420 + + + + + + + + This example shows two addresses for + XX.LCS.MIT.EDU, each of a different class. + + + + + + Discussion of MX Records + + + As described above, domain servers store information as a + series of resource records, each of which contains a particular + piece of information about a given domain name (which is usually, + but not always, a host). The simplest way to think of a RR is as + a typed pair of data, a domain name matched with a relevant datum, + and stored with some additional type information to help systems + determine when the RR is relevant. + + + + MX records are used to control delivery of email. The data + specified in the record is a priority and a domain name. The + priority + controls the order in which email delivery is attempted, with the + lowest number first. If two priorities are the same, a server is + chosen randomly. If no servers at a given priority are responding, + the mail transport agent will fall back to the next largest + priority. + Priority numbers do not have any absolute meaning — they are + relevant + only respective to other MX records for that domain name. The + domain + name given is the machine to which the mail will be delivered. + It must have an associated address record + (A or AAAA) — CNAME is not sufficient. + + + For a given domain, if there is both a CNAME record and an + MX record, the MX record is in error, and will be ignored. + Instead, + the mail will be delivered to the server specified in the MX + record + pointed to by the CNAME. + + + For example: + + + + + + + + + + + + + example.com. + + + + + IN + + + + + MX + + + + + 10 + + + + + mail.example.com. + + + + + + + + + + IN + + + + + MX + + + + + 10 + + + + + mail2.example.com. + + + + + + + + + + IN + + + + + MX + + + + + 20 + + + + + mail.backup.org. + + + + + + + mail.example.com. + + + + + IN + + + + + A + + + + + 10.0.0.1 + + + + + + + + + + mail2.example.com. + + + + + IN + + + + + A + + + + + 10.0.0.2 + + + + + + + + + + Mail delivery will be attempted to mail.example.com and + mail2.example.com (in + any order), and if neither of those succeed, delivery to mail.backup.org will + be attempted. + + + + Setting TTLs + + The time-to-live of the RR field is a 32-bit integer represented + in units of seconds, and is primarily used by resolvers when they + cache RRs. The TTL describes how long a RR can be cached before it + should be discarded. The following three types of TTL are + currently + used in a zone file. + + + + + + + + + + SOA + + + + + The last field in the SOA is the negative + caching TTL. This controls how long other servers will + cache no-such-domain + (NXDOMAIN) responses from you. + + + The maximum time for + negative caching is 3 hours (3h). + + + + + + + $TTL + + + + + The $TTL directive at the top of the + zone file (before the SOA) gives a default TTL for every + RR without + a specific TTL set. + + + + + + + RR TTLs + + + + + Each RR can have a TTL as the second + field in the RR, which will control how long other + servers can cache + the it. + + + + + + + + All of these TTLs default to units of seconds, though units + can be explicitly specified, for example, 1h30m. + + + + 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 + and PTR records. Entries in the in-addr.arpa domain are made in + least-to-most significant order, read left to right. This is the + opposite order to the way IP addresses are usually written. Thus, + a machine with an IP address of 10.1.2.3 would have a + corresponding + in-addr.arpa name of + 3.2.1.10.in-addr.arpa. This name should have a PTR resource record + whose data field is the name of the machine or, optionally, + multiple + PTR records if the machine has more than one name. For example, + in the example.com domain: + + + + + + + + + + $ORIGIN + + + + + 2.1.10.in-addr.arpa + + + + + + + 3 + + + + + IN PTR foo.example.com. + + + + + + + + + The $ORIGIN lines in the examples + are for providing context to the examples only — they do not + necessarily + appear in the actual usage. They are only used here to indicate + that the example is relative to the listed origin. + + + + + Other Zone File Directives + + The Master File Format was initially defined in RFC 1035 and + has subsequently been extended. While the Master File Format + itself + is class independent all records in a Master File must be of the + same + class. + + + Master File Directives include $ORIGIN, $INCLUDE, + and $TTL. + + + The <command>$ORIGIN</command> Directive + + Syntax: $ORIGIN + domain-name + comment + + $ORIGIN + sets the domain name that will be appended to any + unqualified records. When a zone is first read in there + is an implicit $ORIGIN + <zone-name>. + The current $ORIGIN is appended to + the domain specified in the $ORIGIN + argument if it is not absolute. + + + +$ORIGIN example.com. +WWW CNAME MAIN-SERVER + + + + is equivalent to + + + +WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM. + + + + + The <command>$INCLUDE</command> Directive + + Syntax: $INCLUDE + filename + +origin + comment + + + Read and process the file filename as + if it were included into the file at this point. If origin is + specified the file is processed with $ORIGIN set + to that value, otherwise the current $ORIGIN is + used. + + + The origin and the current domain name + revert to the values they had prior to the $INCLUDE once + the file has been read. + + + + RFC 1035 specifies that the current origin should be restored + after + an $INCLUDE, but it is silent + on whether the current + domain name should also be restored. BIND 9 restores both of + them. + This could be construed as a deviation from RFC 1035, a + feature, or both. + + + + + The <command>$TTL</command> Directive + + Syntax: $TTL + default-ttl + +comment + + + Set the default Time To Live (TTL) for subsequent records + with undefined TTLs. Valid TTLs are of the range 0-2147483647 + seconds. + + $TTL + is defined in RFC 2308. + + + + + <acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive + + Syntax: $GENERATE + range + lhs + ttl + class + type + rhs + comment + + $GENERATE + is used to create a series of resource records that only + differ from each other by an + iterator. $GENERATE can be used to + easily generate the sets of records required to support + sub /24 reverse delegations described in RFC 2317: + Classless IN-ADDR.ARPA delegation. + + +$ORIGIN 0.0.192.IN-ADDR.ARPA. +$GENERATE 1-2 0 NS SERVER$.EXAMPLE. +$GENERATE 1-127 $ CNAME $.0 + + + is equivalent to + + +0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE. +0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE. +1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA. +2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA. +... +127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA. + + + + + + + + + + range + + + + This can be one of two forms: start-stop + or start-stop/step. If the first form is used, then step + is set to + 1. All of start, stop and step must be positive. + + + + + + lhs + + + This + describes the owner name of the resource records + to be created. Any single $ + (dollar sign) + symbols within the lhs side + are replaced by the iterator value. + + To get a $ in the output, you need to escape the + $ using a backslash + \, + e.g. \$. The + $ may optionally be followed + by modifiers which change the offset from the + iterator, field width and base. + + Modifiers are introduced by a + { (left brace) immediately following the + $ as + ${offset[,width[,base]]}. + For example, ${-20,3,d} + subtracts 20 from the current value, prints the + result as a decimal in a zero-padded field of + width 3. + + Available output forms are decimal + (d), octal + (o) and hexadecimal + (x or X + for uppercase). The default modifier is + ${0,0,d}. If the + lhs is not absolute, the + current $ORIGIN is appended + to the name. + + + For compatibility with earlier versions, $$ is still + recognized as indicating a literal $ in the output. + + + + + + ttl + + + + Specifies the time-to-live of the generated records. If + not specified this will be inherited using the + normal ttl inheritance rules. + + class + and ttl can be + entered in either order. + + + + + + class + + + + Specifies the class of the generated records. + This must match the zone class if it is + specified. + + class + and ttl can be + entered in either order. + + + + + + type + + + + At present the only supported types are + PTR, CNAME, DNAME, A, AAAA and NS. + + + + + + rhs + + + + rhs is a domain name. It is processed + similarly to lhs. + + + + + + + + The $GENERATE directive is a BIND extension + and not part of the standard zone file format. + + + BIND 8 does not support the optional TTL and CLASS fields. + + + + + Additional File Formats + + In addition to the standard textual format, BIND 9 + supports the ability to read or dump to zone files in + other formats. The raw format is + currently available as an additional format. It is a + binary format representing BIND 9's internal data + structure directly, thereby remarkably improving the + loading time. + + + For a primary server, a zone file in the + raw format is expected to be + generated from a textual zone file by the + named-compilezone command. For a + secondary server or for a dynamic zone, it is automatically + generated (if this format is specified by the + masterfile-format option) when + named dumps the zone contents after + zone transfer or when applying prior updates. + + + If a zone file in a binary format needs manual modification, + it first must be converted to a textual form by the + named-compilezone command. All + necessary modification should go to the text file, which + should then be converted to the binary form by the + named-compilezone command again. + + + Although the raw format uses the + network byte order and avoids architecture-dependent + data alignment so that it is as much portable as + possible, it is primarily expected to be used inside + the same single system. In order to export a zone + file in the raw format or make a + portable backup of the file, it is recommended to + convert the file to the standard textual representation. + + + + + + BIND9 Statistics + + BIND 9 maintains lots of statistics + information and provides several interfaces for users to + get access to the statistics. + The available statistics include all statistics counters + that were available in BIND 8 and + are meaningful in BIND 9, + and other information that is considered useful. + + + + The statistics information is categorized into the following + sections. + + + + + + + + + + + Incoming Requests + + + + The number of incoming DNS requests for each OPCODE. + + + + + + + Incoming Queries + + + + The number of incoming queries for each RR type. + + + + + + + Outgoing Queries + + + + The number of outgoing queries for each RR + type sent from the internal resolver. + Maintained per view. + + + + + + + Name Server Statistics + + + + Statistics counters about incoming request processing. + + + + + + + Zone Maintenance Statistics + + + + Statistics counters regarding zone maintenance + operations such as zone transfers. + + + + + + + Resolver Statistics + + + + Statistics counters about name resolution + performed in the internal resolver. + Maintained per view. + + + + + + + Cache DB RRsets + + + + The number of RRsets per RR type (positive + or negative) and nonexistent names stored in the + cache database. + Maintained per view. + + + + + + + + + + A subset of Name Server Statistics is collected and shown + per zone for which the server has the authority when + zone-statistics is set to + yes. + These statistics counters are shown with their zone and view + names. + In some cases the view names are omitted for the default view. + + + + There are currently two user interfaces to get access to the + statistics. + One is in the plain text format dumped to the file specified + by the statistics-file configuration option. + The other is remotely accessible via a statistics channel + when the statistics-channels statement + is specified in the configuration file + (see .) + + + + The Statistics File + + The text format statistics dump begins with a line, like: + + + +++ Statistics Dump +++ (973798949) + + + The number in parentheses is a standard + Unix-style timestamp, measured as seconds since January 1, 1970. + + Following + that line is a set of statistics information, which is categorized + as described above. + Each section begins with a line, like: + + + + ++ Name Server Statistics ++ + + + + Each section consists of lines, each containing the statistics + counter value followed by its textual description. + See below for available counters. + For brevity, counters that have a value of 0 are not shown + in the statistics file. + + + + The statistics dump ends with the line where the + number is identical to the number in the beginning line; for example: + + + --- Statistics Dump --- (973798949) + + + + + Statistics Counters + + The following tables summarize statistics counters that + BIND 9 provides. + For each row of the tables, the leftmost column is the + abbreviated symbol name of that counter. + These symbols are shown in the statistics information + accessed via an HTTP statistics channel. + The rightmost column gives the description of the counter, + which is also shown in the statistics file + (but, in this document, possibly with slight modification + for better readability). + Additional notes may also be provided in this column. + When a middle column exists between these two columns, + it gives the corresponding counter name of the + BIND 8 statistics, if applicable. + + + + Name Server Statistics Counters + + + + + + + + + + + Symbol + + + + + BIND8 Symbol + + + + + Description + + + + + + + Requestv4 + + + RQ + + + + IPv4 requests received. + Note: this also counts non query requests. + + + + + + Requestv6 + + + RQ + + + + IPv6 requests received. + Note: this also counts non query requests. + + + + + + ReqEdns0 + + + + + + + Requests with EDNS(0) received. + + + + + + ReqBadEDNSVer + + + + + + + Requests with unsupported EDNS version received. + + + + + + ReqTSIG + + + + + + + Requests with TSIG received. + + + + + + ReqSIG0 + + + + + + + Requests with SIG(0) received. + + + + + + ReqBadSIG + + + + + + + Requests with invalid (TSIG or SIG(0)) signature. + + + + + + ReqTCP + + + RTCP + + + + TCP requests received. + + + + + + AuthQryRej + + + RUQ + + + + Authoritative (non recursive) queries rejected. + + + + + + RecQryRej + + + RURQ + + + + Recursive queries rejected. + + + + + + XfrRej + + + RUXFR + + + + Zone transfer requests rejected. + + + + + + UpdateRej + + + RUUpd + + + + Dynamic update requests rejected. + + + + + + Response + + + SAns + + + + Responses sent. + + + + + + RespTruncated + + + + + + + Truncated responses sent. + + + + + + RespEDNS0 + + + + + + + Responses with EDNS(0) sent. + + + + + + RespTSIG + + + + + + + Responses with TSIG sent. + + + + + + RespSIG0 + + + + + + + Responses with SIG(0) sent. + + + + + + QrySuccess + + + + + + + Queries resulted in a successful answer. + This means the query which returns a NOERROR response + with at least one answer RR. + This corresponds to the + success counter + of previous versions of + BIND 9. + + + + + + QryAuthAns + + + + + + + Queries resulted in authoritative answer. + + + + + + QryNoauthAns + + + SNaAns + + + + Queries resulted in non authoritative answer. + + + + + + QryReferral + + + + + + + Queries resulted in referral answer. + This corresponds to the + referral counter + of previous versions of + BIND 9. + + + + + + QryNxrrset + + + + + + + Queries resulted in NOERROR responses with no data. + This corresponds to the + nxrrset counter + of previous versions of + BIND 9. + + + + + + QrySERVFAIL + + + SFail + + + + Queries resulted in SERVFAIL. + + + + + + QryFORMERR + + + SFErr + + + + Queries resulted in FORMERR. + + + + + + QryNXDOMAIN + + + SNXD + + + + Queries resulted in NXDOMAIN. + This corresponds to the + nxdomain counter + of previous versions of + BIND 9. + + + + + + QryRecursion + + + RFwdQ + + + + Queries which caused the server + to perform recursion in order to find the final answer. + This corresponds to the + recursion counter + of previous versions of + BIND 9. + + + + + + QryDuplicate + + + RDupQ + + + + Queries which the server attempted to + recurse but discovered an existing query with the same + IP address, port, query ID, name, type and class + already being processed. + This corresponds to the + duplicate counter + of previous versions of + BIND 9. + + + + + + QryDropped + + + + + + + Queries for which the server + discovered an excessive number of existing + recursive queries for the same name, type and + class and were subsequently dropped. + This corresponds to the + dropped counter + of previous versions of + BIND 9. + + + + + + QryFailure + + + + + + + Other query failures. + This corresponds to the + failure counter + of previous versions of + BIND 9. + + + + + + XfrReqDone + + + + + + + Requested zone transfers completed. + + + + + + UpdateReqFwd + + + + + + + Update requests forwarded. + + + + + + UpdateRespFwd + + + + + + + Update responses forwarded. + + + + + + UpdateFwdFail + + + + + + + Dynamic update forward failed. + + + + + + UpdateDone + + + + + + + Dynamic updates completed. + + + + + + UpdateFail + + + + + + + Dynamic updates failed. + + + + + + UpdateBadPrereq + + + + + + + Dynamic updates rejected due to prerequisite failure. + + + + + + + + + + Zone Maintenance Statistics Counters + + + + + + + + + + Symbol + + + + + Description + + + + + + + NotifyOutv4 + + + + IPv4 notifies sent. + + + + + + NotifyOutv6 + + + + IPv6 notifies sent. + + + + + + NotifyInv4 + + + + IPv4 notifies received. + + + + + + NotifyInv6 + + + + IPv6 notifies received. + + + + + + NotifyRej + + + + Incoming notifies rejected. + + + + + + SOAOutv4 + + + + IPv4 SOA queries sent. + + + + + + SOAOutv6 + + + + IPv6 SOA queries sent. + + + + + + AXFRReqv4 + + + + IPv4 AXFR requested. + + + + + + AXFRReqv6 + + + + IPv6 AXFR requested. + + + + + + IXFRReqv4 + + + + IPv4 IXFR requested. + + + + + + IXFRReqv6 + + + + IPv6 IXFR requested. + + + + + + XfrSuccess + + + + Zone transfer requests succeeded. + + + + + + XfrFail + + + + Zone transfer requests failed. + + + + + + + + + + Resolver Statistics Counters + + + + + + + + + + + Symbol + + + + + BIND8 Symbol + + + + + Description + + + + + + + + Queryv4 + + + SFwdQ + + + + IPv4 queries sent. + + + + + + Queryv6 + + + SFwdQ + + + + IPv6 queries sent. + + + + + + Responsev4 + + + RR + + + + IPv4 responses received. + + + + + + Responsev6 + + + RR + + + + IPv6 responses received. + + + + + + NXDOMAIN + + + RNXD + + + + NXDOMAIN received. + + + + + + SERVFAIL + + + RFail + + + + SERVFAIL received. + + + + + + FORMERR + + + RFErr + + + + FORMERR received. + + + + + + OtherError + + + RErr + + + + Other errors received. + + + + + + EDNS0Fail + + + + + + + EDNS(0) query failures. + + + + + + Mismatch + + + RDupR + + + + Mismatch responses received. + + + + + + Truncated + + + + + + + Truncated responses received. + + + + + + Lame + + + RLame + + + + Lame delegations received. + + + + + + Retry + + + SDupQ + + + + Query retries performed. + + + + + + GlueFetchv4 + + + SSysQ + + + + IPv4 NS address fetches invoked. + + + + + + GlueFetchv6 + + + SSysQ + + + + IPv6 NS address fetches invoked. + + + + + + GlueFetchv4Fail + + + + + + + IPv4 NS address fetch failed. + + + + + + GlueFetchv6Fail + + + + + + + IPv6 NS address fetch failed. + + + + + + ValAttempt + + + + + + + DNSSEC validation attempted. + + + + + + ValOk + + + + + + + DNSSEC validation succeeded. + + + + + + ValNegOk + + + + + + + DNSSEC validation on negative information succeeded. + + + + + + ValFail + + + + + + + DNSSEC validation failed. + + + + + + + + + + + + Compatibility with <emphasis>BIND</emphasis> 8 Counters + + Most statistics counters that were available + in BIND 8 are also supported in + BIND 9 as shown in the above tables. + Here are notes about other counters that do not appear + in these tables. + + + + + RFwdR,SFwdR + + + These counters are not supported + because BIND 9 does not adopt + the notion of forwarding + as BIND 8 did. + + + + + + RAXFR + + + This counter is accessible in the Incoming Queries section. + + + + + + RIQ + + + This counter is accessible in the Incoming Requests section. + + + + + + ROpts + + + This counter is not supported + because BIND 9 does not care + about IP options in the first place. + + + + + + SErr + + + This counter could be implemented, but is not yet + supported. + + + + + + + + + + + + <acronym>BIND</acronym> 9 Security Considerations + + Access Control Lists + + Access Control Lists (ACLs), are address match lists that + you can set up and nickname for future use in allow-notify, + allow-query, allow-query-on, + allow-recursion, allow-recursion-on, + blackhole, allow-transfer, + etc. + + + Using ACLs allows you to have finer control over who can access + your name server, without cluttering up your config files with huge + lists of IP addresses. + + + It is a good idea to use ACLs, and to + control access to your server. Limiting access to your server by + outside parties can help prevent spoofing and denial of service (DoS) attacks against + your server. + + + Here is an example of how to properly apply ACLs: + + + +// Set up an ACL named "bogusnets" that will block RFC1918 space +// and some reserved space, which is commonly used in spoofing attacks. +acl bogusnets { + 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; + 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; +}; + +// Set up an ACL called our-nets. Replace this with the real IP numbers. +acl our-nets { x.x.x.x/24; x.x.x.x/21; }; +options { + ... + ... + allow-query { our-nets; }; + allow-recursion { our-nets; }; + ... + blackhole { bogusnets; }; + ... +}; + +zone "example.com" { + type master; + file "m/example.com"; + allow-query { any; }; +}; + + + + This allows recursive queries of the server from the outside + unless recursion has been previously disabled. + + + For more information on how to use ACLs to protect your server, + see the AUSCERT advisory at: + + + ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos + + + + <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. + + + Another useful feature in the UNIX version of BIND is the + ability to run the daemon as an unprivileged user ( user ). + We suggest running as an unprivileged user when using the chroot feature. + + + Here is an example command line to load BIND in a chroot sandbox, + /var/named, and to run named setuid to + user 202: + + + /usr/local/bin/named -u 202 -t /var/named + + + + The <command>chroot</command> Environment + + + In order for a chroot environment + to + work properly in a particular directory + (for example, /var/named), + you will need to set up an environment that includes everything + BIND needs to run. + From BIND's point of view, /var/named is + the root of the filesystem. You will need to adjust the values of + options like + like directory and pid-file to account + for this. + + + Unlike with earlier versions of BIND, you typically will + not need to compile named + statically nor install shared libraries under the new root. + However, depending on your operating system, you may need + to set up things like + /dev/zero, + /dev/random, + /dev/log, and + /etc/localtime. + + + + + Using the <command>setuid</command> Function + + + Prior to running the named daemon, + use + the touch utility (to change file + access and + modification times) or the chown + utility (to + set the user id and/or group id) on files + to which you want BIND + to write. + + + Note that if the named daemon is running as an + unprivileged user, it will not be able to bind to new restricted + ports if the server is reloaded. + + + + + + Dynamic Update Security + + + Access to the dynamic + update facility should be strictly limited. In earlier versions of + BIND, the only way to do this was + based on the IP + address of the host requesting the update, by listing an IP address + or + network prefix in the allow-update + zone option. + This method is insecure since the source address of the update UDP + packet + is easily forged. Also note that if the IP addresses allowed by the + allow-update option include the + address of a slave + server which performs forwarding of dynamic updates, the master can + be + trivially attacked by sending the update to the slave, which will + forward it to the master with its own source IP address causing the + master to approve it without question. + + + + For these reasons, we strongly recommend that updates be + cryptographically authenticated by means of transaction signatures + (TSIG). That is, the allow-update + option should + list only TSIG key names, not IP addresses or network + prefixes. Alternatively, the new update-policy + option can be used. + + + + Some sites choose to keep all dynamically-updated DNS data + in a subdomain and delegate that subdomain to a separate zone. This + way, the top-level zone containing critical data such as the IP + addresses + of public web and mail servers need not allow dynamic update at + all. + + + + + + + Troubleshooting + + Common Problems + + 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 + up logging files beforehand. The log files provide a + source of hints and information that can be used to figure out + what went wrong and how to fix the problem. + + + + + + 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 + represents a date, usually of the form YYYYMMDDRR. + Occasionally they will make a mistake and set them to a + "date in the future" then try to correct them by setting + them to the "current date". This causes problems because + serial numbers are used to indicate that a zone has been + updated. If the serial number on the slave server is + lower than the serial number on the master, the slave + server will attempt to update its copy of the zone. + + + + Setting the serial number to a lower number on the master + server than the slave server means that the slave will not perform + updates to its copy of the zone. + + + + The solution to this is to add 2147483647 (2^31-1) to the + number, reload the zone and make sure all slaves have updated to + the new zone serial number, then reset the number to what you want + it to be, and reload the zone again. + + + + + Where Can I Get Help? + + + The Internet Systems Consortium + (ISC) offers a wide range + of support and service agreements for BIND and DHCP servers. Four + levels of premium support are available and each level includes + support for all ISC programs, + significant discounts on products + and training, and a recognized priority on bug fixes and + non-funded feature requests. In addition, ISC offers a standard + support agreement package which includes services ranging from bug + fix announcements to remote support. It also includes training in + BIND and DHCP. + + + + To discuss arrangements for support, contact + info@isc.org or visit the + ISC web page at + http://www.isc.org/services/support/ + to read more. + + + + + Appendices + + Acknowledgments + + A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym> + + + Although the "official" beginning of the Domain Name + System occurred in 1984 with the publication of RFC 920, the + core of the new system was described in 1983 in RFCs 882 and + 883. From 1984 to 1987, the ARPAnet (the precursor to today's + Internet) became a testbed of experimentation for developing the + new naming/addressing scheme in a rapidly expanding, + operational network environment. New RFCs were written and + published in 1987 that modified the original documents to + incorporate improvements based on the working model. RFC 1034, + "Domain Names-Concepts and Facilities", and RFC 1035, "Domain + Names-Implementation and Specification" were published and + became the standards upon which all DNS implementations are + built. + + + + The first working domain name server, called "Jeeves", was + written in 1983-84 by Paul Mockapetris for operation on DEC + Tops-20 + machines located at the University of Southern California's + Information + Sciences Institute (USC-ISI) and SRI International's Network + Information + Center (SRI-NIC). A DNS server for + Unix machines, the Berkeley Internet + Name Domain (BIND) package, was + written soon after by a group of + graduate students at the University of California at Berkeley + under + a grant from the US Defense Advanced Research Projects + Administration + (DARPA). + + + Versions of BIND through + 4.8.3 were maintained by the Computer + Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark + Painter, David Riggle and Songnian Zhou made up the initial BIND + project team. After that, additional work on the software package + was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment + Corporation + employee on loan to the CSRG, worked on BIND for 2 years, from 1985 + to 1987. Many other people also contributed to BIND development + during that time: Doug Kingston, Craig Partridge, Smoot + Carl-Mitchell, + Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently + handled by Mike Karels and Øivind Kure. + + + BIND versions 4.9 and 4.9.1 were + released by Digital Equipment + Corporation (now Compaq Computer Corporation). Paul Vixie, then + a DEC employee, became BIND's + primary caretaker. He was assisted + by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan + Beecher, Andrew + Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat + Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe + Wolfhugel, and others. + + + In 1994, BIND version 4.9.2 was sponsored by + Vixie Enterprises. Paul + Vixie became BIND's principal + architect/programmer. + + + BIND versions from 4.9.3 onward + have been developed and maintained + by the Internet Systems Consortium and its predecessor, + the Internet Software Consortium, with support being provided + by ISC's sponsors. + + + As co-architects/programmers, Bob Halley and + Paul Vixie released the first production-ready version of + BIND version 8 in May 1997. + + + BIND version 9 was released in September 2000 and is a + major rewrite of nearly all aspects of the underlying + 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 development work is made + possible today by the sponsorship + of several corporations, and by the tireless work efforts of + numerous individuals. + + + + + General <acronym>DNS</acronym> Reference Information + + IPv6 addresses (AAAA) + + IPv6 addresses are 128-bit identifiers for interfaces and + sets of interfaces which were introduced in the DNS to facilitate + scalable Internet routing. There are three types of addresses: Unicast, + an identifier for a single interface; + Anycast, + an identifier for a set of interfaces; and Multicast, + an identifier for a set of interfaces. Here we describe the global + Unicast address scheme. For more information, see RFC 3587, + "Global Unicast Address Format." + + + IPv6 unicast addresses consist of a + global routing prefix, a + subnet identifier, and an + interface identifier. + + + The global routing prefix is provided by the + upstream provider or ISP, and (roughly) corresponds to the + IPv4 network section + of the address range. + + The subnet identifier is for local subnetting, much the + same as subnetting an + IPv4 /16 network into /24 subnets. + + The interface identifier is the address of an individual + interface on a given network; in IPv6, addresses belong to + interfaces rather than to machines. + + + The subnetting capability of IPv6 is much more flexible than + that of IPv4: subnetting can be carried out on bit boundaries, + in much the same way as Classless InterDomain Routing + (CIDR), and the DNS PTR representation ("nibble" format) + makes setting up reverse zones easier. + + + The Interface Identifier must be unique on the local link, + and is usually generated automatically by the IPv6 + implementation, although it is usually possible to + override the default setting if necessary. A typical IPv6 + address might look like: + 2001:db8:201:9:a00:20ff:fe81:2b32 + + + IPv6 address specifications often contain long strings + of zeros, so the architects have included a shorthand for + specifying + them. The double colon (`::') indicates the longest possible + string + of zeros that can fit, and can be used only once in an address. + + + + + Bibliography (and Suggested Reading) + + Request for Comments (RFCs) + + Specification documents for the Internet protocol suite, including + the DNS, are published as part of + the Request for Comments (RFCs) + series of technical notes. The standards themselves are defined + by the Internet Engineering Task Force (IETF) and the Internet + Engineering Steering Group (IESG). RFCs can be obtained online via FTP at: + + + + ftp://www.isi.edu/in-notes/RFCxxxx.txt + + + + (where xxxx is + the number of the RFC). RFCs are also available via the Web at: + + + http://www.ietf.org/rfc/. + + + + + Standards + + RFC974 + + Partridge + C. + + Mail Routing and the Domain System + January 1986 + + + RFC1034 + + Mockapetris + P.V. + + Domain Names — Concepts and Facilities + November 1987 + + + RFC1035 + + Mockapetris + P. V. + Domain Names — Implementation and + Specification + November 1987 + + + + + Proposed Standards + + + RFC2181 + + Elz + R., R. Bush + + Clarifications to the <acronym>DNS</acronym> + Specification + July 1997 + + + RFC2308 + + Andrews + M. + + Negative Caching of <acronym>DNS</acronym> + Queries + March 1998 + + + RFC1995 + + Ohta + M. + + Incremental Zone Transfer in <acronym>DNS</acronym> + August 1996 + + + RFC1996 + + Vixie + P. + + A Mechanism for Prompt Notification of Zone Changes + August 1996 + + + RFC2136 + + + Vixie + P. + + + S. + Thomson + + + Y. + Rekhter + + + J. + Bound + + + Dynamic Updates in the Domain Name System + April 1997 + + + RFC2671 + + + P. + Vixie + + + Extension Mechanisms for DNS (EDNS0) + August 1997 + + + RFC2672 + + + M. + Crawford + + + Non-Terminal DNS Name Redirection + August 1999 + + + RFC2845 + + + Vixie + P. + + + O. + Gudmundsson + + + D. + Eastlake + 3rd + + + B. + Wellington + + + Secret Key Transaction Authentication for <acronym>DNS</acronym> (TSIG) + May 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 + + + RFC3007 + + + B. + Wellington + + + Secure Domain Name System (DNS) Dynamic Update + November 2000 + + + RFC3645 + + + S. + Kwan + + + P. + Garg + + + J. + Gilroy + + + L. + Esibov + + + J. + Westhead + + + R. + Hall + + + Generic Security Service Algorithm for Secret + Key Transaction Authentication for DNS + (GSS-TSIG) + October 2003 + + + + <acronym>DNS</acronym> Security Proposed Standards + + RFC3225 + + + D. + Conrad + + + Indicating Resolver Support of DNSSEC + December 2001 + + + RFC3833 + + + D. + Atkins + + + R. + Austein + + + Threat Analysis of the Domain Name System (DNS) + August 2004 + + + RFC4033 + + + R. + Arends + + + R. + Austein + + + M. + Larson + + + D. + Massey + + + S. + Rose + + + DNS Security Introduction and Requirements + March 2005 + + + RFC4034 + + + R. + Arends + + + R. + Austein + + + M. + Larson + + + D. + Massey + + + S. + Rose + + + Resource Records for the DNS Security Extensions + March 2005 + + + RFC4035 + + + R. + Arends + + + R. + Austein + + + M. + Larson + + + D. + Massey + + + S. + Rose + + + Protocol Modifications for the DNS + Security Extensions + March 2005 + + + + Other Important RFCs About <acronym>DNS</acronym> + Implementation + + RFC1535 + + Gavron + E. + + A Security Problem and Proposed Correction With Widely + Deployed <acronym>DNS</acronym> Software. + October 1993 + + + RFC1536 + + + Kumar + A. + + + J. + Postel + + + C. + Neuman + + + P. + Danzig + + + S. + Miller + + + Common <acronym>DNS</acronym> Implementation + Errors and Suggested Fixes + October 1993 + + + RFC1982 + + + Elz + R. + + + R. + Bush + + + Serial Number Arithmetic + August 1996 + + + RFC4074 + + + Morishita + Y. + + + T. + Jinmei + + + Common Misbehaviour Against <acronym>DNS</acronym> + Queries for IPv6 Addresses + May 2005 + + + + Resource Record Types + + RFC1183 + + + Everhart + C.F. + + + L. A. + Mamakos + + + R. + Ullmann + + + P. + Mockapetris + + + New <acronym>DNS</acronym> RR Definitions + October 1990 + + + RFC1706 + + + Manning + B. + + + R. + Colella + + + <acronym>DNS</acronym> NSAP Resource Records + October 1994 + + + RFC2168 + + + Daniel + R. + + + M. + Mealling + + + Resolution of Uniform Resource Identifiers using + the Domain Name System + June 1997 + + + RFC1876 + + + Davis + C. + + + P. + Vixie + + + T. + Goodwin + + + I. + Dickinson + + + A Means for Expressing Location Information in the + Domain + Name System + January 1996 + + + RFC2052 + + + Gulbrandsen + A. + + + P. + Vixie + + + A <acronym>DNS</acronym> RR for Specifying the + Location of + Services. + October 1996 + + + RFC2163 + + Allocchio + A. + + Using the Internet <acronym>DNS</acronym> to + Distribute MIXER + Conformant Global Address Mapping + January 1998 + + + RFC2230 + + Atkinson + R. + + Key Exchange Delegation Record for the <acronym>DNS</acronym> + October 1997 + + + RFC2536 + + Eastlake + D. + 3rd + + DSA KEYs and SIGs in the Domain Name System (DNS) + March 1999 + + + RFC2537 + + Eastlake + D. + 3rd + + RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) + March 1999 + + + RFC2538 + + + Eastlake + D. + 3rd + + + Gudmundsson + O. + + + Storing Certificates in the Domain Name System (DNS) + March 1999 + + + RFC2539 + + + Eastlake + D. + 3rd + + + Storage of Diffie-Hellman Keys in the Domain Name System (DNS) + March 1999 + + + RFC2540 + + + Eastlake + D. + 3rd + + + Detached Domain Name System (DNS) Information + March 1999 + + + RFC2782 + + Gulbrandsen + A. + + + Vixie + P. + + + Esibov + L. + + A DNS RR for specifying the location of services (DNS SRV) + February 2000 + + + RFC2915 + + Mealling + M. + + + Daniel + R. + + The Naming Authority Pointer (NAPTR) DNS Resource Record + September 2000 + + + RFC3110 + + Eastlake + D. + 3rd + + RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) + May 2001 + + + RFC3123 + + Koch + P. + + A DNS RR Type for Lists of Address Prefixes (APL RR) + June 2001 + + + RFC3596 + + + Thomson + S. + + + C. + Huitema + + + V. + Ksinant + + + M. + Souissi + + + <acronym>DNS</acronym> Extensions to support IP + version 6 + October 2003 + + + RFC3597 + + Gustafsson + A. + + Handling of Unknown DNS Resource Record (RR) Types + September 2003 + + + + <acronym>DNS</acronym> and the Internet + + RFC1101 + + Mockapetris + P. V. + + <acronym>DNS</acronym> Encoding of Network Names + and Other Types + April 1989 + + + RFC1123 + + Braden + R. + + Requirements for Internet Hosts - Application and + Support + October 1989 + + + RFC1591 + + Postel + J. + + Domain Name System Structure and Delegation + March 1994 + + + RFC2317 + + + Eidnes + H. + + + G. + de Groot + + + P. + Vixie + + + Classless IN-ADDR.ARPA Delegation + March 1998 + + + RFC2826 + + + Internet Architecture Board + + + IAB Technical Comment on the Unique DNS Root + May 2000 + + + RFC2929 + + + Eastlake + D. + 3rd + + + Brunner-Williams + E. + + + Manning + B. + + + Domain Name System (DNS) IANA Considerations + September 2000 + + + + <acronym>DNS</acronym> Operations + + RFC1033 + + Lottor + M. + + Domain administrators operations guide. + November 1987 + + + RFC1537 + + Beertema + P. + + Common <acronym>DNS</acronym> Data File + Configuration Errors + October 1993 + + + RFC1912 + + Barr + D. + + Common <acronym>DNS</acronym> Operational and + Configuration Errors + February 1996 + + + RFC2010 + + + Manning + B. + + + P. + Vixie + + + Operational Criteria for Root Name Servers. + October 1996 + + + RFC2219 + + + Hamilton + M. + + + R. + Wright + + + Use of <acronym>DNS</acronym> Aliases for + Network Services. + October 1997 + + + + Internationalized Domain Names + + RFC2825 + + + IAB + + + Daigle + R. + + + A Tangled Web: Issues of I18N, Domain Names, + and the Other Internet protocols + May 2000 + + + RFC3490 + + + Faltstrom + P. + + + Hoffman + P. + + + Costello + A. + + + Internationalizing Domain Names in Applications (IDNA) + March 2003 + + + RFC3491 + + + Hoffman + P. + + + Blanchet + M. + + + Nameprep: A Stringprep Profile for Internationalized Domain Names + March 2003 + + + RFC3492 + + + Costello + A. + + + Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in + Applications (IDNA) + March 2003 + + + + Other <acronym>DNS</acronym>-related RFCs + + + Note: the following list of RFCs, although + DNS-related, are not + concerned with implementing software. + + + + RFC1464 + + Rosenbaum + R. + + Using the Domain Name System To Store Arbitrary String + Attributes + May 1993 + + + RFC1713 + + Romao + A. + + Tools for <acronym>DNS</acronym> Debugging + November 1994 + + + RFC1794 + + Brisco + T. + + <acronym>DNS</acronym> Support for Load + Balancing + April 1995 + + + RFC2240 + + Vaughan + O. + + A Legal Basis for Domain Name Allocation + November 1997 + + + RFC2345 + + + Klensin + J. + + + T. + Wolf + + + G. + Oglesby + + + Domain Names and Company Name Retrieval + May 1998 + + + RFC2352 + + Vaughan + O. + + A Convention For Using Legal Names as Domain Names + May 1998 + + + RFC3071 + + + Klensin + J. + + + Reflections on the DNS, RFC 1591, and Categories of Domains + February 2001 + + + RFC3258 + + + Hardie + T. + + + Distributing Authoritative Name Servers via + Shared Unicast Addresses + April 2002 + + + RFC3901 + + + Durand + A. + + + J. + Ihren + + + DNS IPv6 Transport Operational Guidelines + September 2004 + + + + Obsolete and Unimplemented Experimental RFC + + RFC1712 + + + Farrell + C. + + + M. + Schulze + + + S. + Pleitner + + + D. + Baldoni + + + <acronym>DNS</acronym> Encoding of Geographical + Location + November 1994 + + + RFC2673 + + + Crawford + M. + + + Binary Labels in the Domain Name System + August 1999 + + + RFC2874 + + + Crawford + M. + + + Huitema + C. + + + DNS Extensions to Support IPv6 Address Aggregation + and Renumbering + July 2000 + + + + Obsoleted DNS Security RFCs + + + Most of these have been consolidated into RFC4033, + RFC4034 and RFC4035 which collectively describe DNSSECbis. + + + + RFC2065 + + + Eastlake + 3rd + D. + + + C. + Kaufman + + + Domain Name System Security Extensions + January 1997 + + + RFC2137 + + Eastlake + 3rd + D. + + Secure Domain Name System Dynamic Update + April 1997 + + + RFC2535 + + + Eastlake + 3rd + D. + + + Domain Name System Security Extensions + March 1999 + + + RFC3008 + + + Wellington + B. + + + Domain Name System Security (DNSSEC) + Signing Authority + November 2000 + + + RFC3090 + + + Lewis + E. + + + DNS Security Extension Clarification on Zone Status + March 2001 + + + RFC3445 + + + Massey + D. + + + Rose + S. + + + Limiting the Scope of the KEY Resource Record (RR) + December 2002 + + + RFC3655 + + + Wellington + B. + + + Gudmundsson + O. + + + Redefinition of DNS Authenticated Data (AD) bit + November 2003 + + + RFC3658 + + + Gudmundsson + O. + + + Delegation Signer (DS) Resource Record (RR) + December 2003 + + + RFC3755 + + + Weiler + S. + + + Legacy Resolver Compatibility for Delegation Signer (DS) + May 2004 + + + RFC3757 + + + Kolkman + O. + + + Schlyter + J. + + + Lewis + E. + + + Domain Name System KEY (DNSKEY) Resource Record + (RR) Secure Entry Point (SEP) Flag + April 2004 + + + RFC3845 + + + Schlyter + J. + + + DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format + August 2004 + + + + + + Internet Drafts + + Internet Drafts (IDs) are rough-draft working documents of + the Internet Engineering Task Force. They are, in essence, RFCs + in the preliminary stages of development. Implementors are + cautioned not + to regard IDs as archival, and they should not be quoted or cited + in any formal documents unless accompanied by the disclaimer that + they are "works in progress." IDs have a lifespan of six months + after which they are deleted unless updated by their authors. + + + + Other Documents About <acronym>BIND</acronym> + + + + + + Albitz + Paul + + + Cricket + Liu + + + <acronym>DNS</acronym> and <acronym>BIND</acronym> + + 1998 + Sebastopol, CA: O'Reilly and Associates + + + + + + + + + Manual pages + + + + + + + + + + + + + + + + + + + diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html new file mode 100644 index 0000000..0377123 --- /dev/null +++ b/doc/arm/Bv9ARM.ch01.html @@ -0,0 +1,562 @@ + + + + + +Chapter 1. Introduction + + + + + + + +
+ + + + + + + +
Chapter 1. Introduction
+Prev   Next +
+
+
+
+

+Chapter 1. Introduction

+
+

Table of Contents

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

+ The Internet Domain Name System (DNS) + consists of the syntax + to specify the names of entities in the Internet in a hierarchical + manner, the rules used for delegating authority over names, and the + system implementation that actually maps names to Internet + addresses. DNS data is maintained in a + group of distributed + hierarchical databases. +

+
+

+Scope of Document

+

+ The Berkeley Internet Name Domain + (BIND) implements a + domain name server for a number of operating systems. This + document provides basic information about the installation and + care of the Internet Systems Consortium (ISC) + BIND version 9 software package for + system administrators. +

+

+ This version of the manual corresponds to BIND version 9.6. +

+
+
+

+Organization of This Document

+

+ In this document, Section 1 introduces + the basic DNS and BIND concepts. Section 2 + describes resource requirements for running BIND in various + environments. Information in Section 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 + concepts that the system administrator may need for implementing + certain options. Section 5 + describes the BIND 9 lightweight + resolver. The contents of Section 6 are + organized as in a reference manual to aid in the ongoing + maintenance of the software. Section 7 addresses + security considerations, and + Section 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 + historic information related to BIND + and the Domain Name + System. +

+
+
+

+Conventions Used in This Document

+

+ In this document, we use the following general typographic + conventions: +

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

+ To describe: +

+ 		+

+ We use the style: +

+
+

+ a pathname, filename, URL, hostname, + mailing list name, or new term or concept +

+ 		+

+ Fixed width +

+
+

+ literal user + input +

+ 		+

+ Fixed Width Bold +

+
+

+ program output +

+ 		+

+ Fixed Width +

+
+

+ The following conventions are used in descriptions of the + BIND configuration file:

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

+ To describe: +

+ 		+

+ We use the style: +

+
+

+ keywords +

+ 		+

+ Fixed Width +

+
+

+ variables +

+ 		+

+ Fixed Width +

+
+

+ Optional input +

+ 		+

+ [Text is enclosed in square brackets] +

+
+

+

+
+
+

+The Domain Name System (DNS)

+

+ The purpose of this document is to explain the installation + and upkeep of the BIND (Berkeley Internet + Name Domain) software package, and we + begin by reviewing the fundamentals of the Domain Name System + (DNS) as they relate to BIND. +

+
+

+DNS Fundamentals

+

+ The Domain Name System (DNS) is a hierarchical, distributed + database. It stores information for mapping Internet host names to + IP + addresses and vice versa, mail routing information, and other data + used by Internet applications. +

+

+ Clients look up information in the DNS by calling a + resolver library, which sends queries to one or + more name servers and interprets the responses. + The BIND 9 software distribution + contains a + name server, named, and a resolver + library, liblwres. The older + libbind resolver library is also available + from ISC as a separate download. +

+
+
+

+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, + called a domain, is given a label. The domain + name of the + node is the concatenation of all the labels on the path from the + node to the root node. This is represented + in written form as a string of labels listed from right to left and + separated by dots. A label need only be unique within its parent + domain. +

+

+ For example, a domain name for a host at the + company Example, Inc. could be + ourhost.example.com, + where com is the + top level domain to which + ourhost.example.com belongs, + example is + a subdomain of com, and + ourhost is the + name of the host. +

+

+ For administrative purposes, the name space is partitioned into + areas called zones, each starting at a node and + extending down to the leaf nodes or to nodes where other zones + start. + The data for each zone is stored in a name server, which answers queries about the zone using the + DNS protocol. +

+

+ The data associated with each domain name is stored in the + form of resource records (RRs). + Some of the supported resource record types are described in + the section called “Types of Resource Records and When to Use Them”. +

+

+ For more detailed information about the design of the DNS and + the DNS protocol, please refer to the standards documents listed in + the section called “Request for Comments (RFCs)”. +

+
+
+

+Zones

+

+ To properly operate a name server, it is important to understand + the difference between a zone + and a domain. +

+

+ As stated previously, a zone is a point of delegation in + the DNS tree. A zone consists of + those contiguous parts of the domain + tree for which a name server has complete information and over which + it has authority. It contains all domain names from a certain point + downward in the domain tree except those which are delegated to + other zones. A delegation point is marked by one or more + NS records in the + parent zone, which should be matched by equivalent NS records at + the root of the delegated zone. +

+

+ For instance, consider the example.com + domain which includes names + such as host.aaa.example.com and + host.bbb.example.com even though + the example.com zone includes + only delegations for the aaa.example.com and + bbb.example.com zones. A zone can + map + exactly to a single domain, but could also include only part of a + domain, the rest of which could be delegated to other + name servers. Every name in the DNS + tree is a + domain, even if it is + terminal, that is, has no + subdomains. Every subdomain is a domain and + every domain except the root is also a subdomain. The terminology is + not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 + to + gain a complete understanding of this difficult and subtle + topic. +

+

+ Though BIND is called a "domain name + server", + it deals primarily in terms of zones. The master and slave + declarations in the named.conf file + specify + zones, not domains. When you ask some other site if it is willing to + be a slave server for your domain, you are + actually asking for slave service for some collection of zones. +

+
+
+

+Authoritative Name Servers

+

+ Each zone is served by at least + one authoritative name server, + which contains the complete data for the zone. + To make the DNS tolerant of server and network failures, + most zones have two or more authoritative servers, on + different networks. +

+

+ Responses from authoritative servers have the "authoritative + answer" (AA) bit set in the response packets. This makes them + easy to identify when debugging DNS configurations using tools like + dig (the section called “Diagnostic Tools”). +

+
+

+The Primary Master

+

+ The authoritative server where the master copy of the zone + data is maintained is called the + primary master server, or simply the + primary. Typically it loads the zone + contents from some local file edited by humans or perhaps + generated mechanically from some other local file which is + edited by humans. This file is called the + zone file or + master file. +

+

+ In some cases, however, the master file may not be edited + by humans at all, but may instead be the result of + dynamic update operations. +

+
+
+

+Slave Servers

+

+ The other authoritative servers, the slave + servers (also known as secondary servers) + load + the zone contents from another server using a replication process + known as a zone transfer. Typically the data + are + transferred directly from the primary master, but it is also + possible + to transfer it from another slave. In other words, a slave server + may itself act as a master to a subordinate slave server. +

+
+
+

+Stealth Servers

+

+ Usually all of the zone's authoritative servers are listed in + NS records in the parent zone. These NS records constitute + a delegation of the zone from the parent. + The authoritative servers are also listed in the zone file itself, + at the top level or apex + of the zone. You can list servers in the zone's top-level NS + records that are not in the parent's NS delegation, but you cannot + list servers in the parent's delegation that are not present at + the zone's top level. +

+

+ A stealth server is a server that is + authoritative for a zone but is not listed in that zone's NS + records. Stealth servers can be used for keeping a local copy of + a + zone to speed up access to the zone's records or to make sure that + the + zone is available even if all the "official" servers for the zone + are + inaccessible. +

+

+ A configuration where the primary master server itself is a + stealth server is often referred to as a "hidden primary" + configuration. One use for this configuration is when the primary + master + is behind a firewall and therefore unable to communicate directly + with the outside world. +

+
+
+
+

+Caching Name Servers

+

+ The resolver libraries provided by most operating systems are + stub resolvers, meaning that they are not + capable of + performing the full DNS resolution process by themselves by talking + directly to the authoritative servers. Instead, they rely on a + local + name server to perform the resolution on their behalf. Such a + server + is called a recursive name server; it performs + recursive lookups for local clients. +

+

+ To improve performance, recursive servers cache the results of + the lookups they perform. Since the processes of recursion and + caching are intimately connected, the terms + recursive server and + caching server are often used synonymously. +

+

+ The length of time for which a record may be retained in + the cache of a caching name server is controlled by the + Time To Live (TTL) field associated with each resource record. +

+
+

+Forwarding

+

+ Even a caching name server does not necessarily perform + the complete recursive lookup itself. Instead, it can + forward some or all of the queries + that it cannot satisfy from its cache to another caching name + server, + commonly referred to as a forwarder. +

+

+ There may be one or more forwarders, + and they are queried in turn until the list is exhausted or an + answer + is found. Forwarders are typically used when you do not + wish all the servers at a given site to interact directly with the + rest of + the Internet servers. A typical scenario would involve a number + of internal DNS servers and an + Internet firewall. Servers unable + to pass packets through the firewall would forward to the server + that can do it, and that server would query the Internet DNS servers + on the internal server's behalf. +

+
+
+
+

+Name Servers in Multiple Roles

+

+ The BIND name server can + simultaneously act as + a master for some zones, a slave for other zones, and as a caching + (recursive) server for a set of local clients. +

+

+ However, since the functions of authoritative name service + and caching/recursive name service are logically separate, it is + often advantageous to run them on separate server machines. + + A server that only provides authoritative name service + (an authoritative-only server) can run with + recursion disabled, improving reliability and security. + + A server that is not authoritative for any zones and only provides + recursive service to local + clients (a caching-only server) + does not need to be reachable from the Internet at large and can + be placed inside a firewall. +

+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
BIND 9 Administrator Reference Manual Home Chapter 2. BIND Resource Requirements
+
+ + diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html new file mode 100644 index 0000000..efe0eb8 --- /dev/null +++ b/doc/arm/Bv9ARM.ch02.html @@ -0,0 +1,158 @@ + + + + + +Chapter 2. BIND Resource Requirements + + + + + + + +
+ + + + + + + +
Chapter 2. BIND Resource Requirements
+Prev   Next +
+
+
+
+

+Chapter 2. BIND Resource Requirements

+
+

Table of Contents

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

+Hardware requirements

+

+ DNS hardware requirements have + traditionally been quite modest. + For many installations, servers that have been pensioned off from + active duty have performed admirably as DNS servers. +

+

+ The DNSSEC features of BIND 9 + may prove to be quite + CPU intensive however, so organizations that make heavy use of these + features may wish to consider larger systems for these applications. + BIND 9 is fully multithreaded, allowing + full utilization of + multiprocessor systems for installations that need it. +

+
+
+

+CPU Requirements

+

+ CPU requirements for BIND 9 range from + i486-class machines + for serving of static zones without caching, to enterprise-class + machines if you intend to process many dynamic updates and DNSSEC + signed zones, serving many thousands of queries per second. +

+
+
+

+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 + option can be used to limit the amount of memory used by the cache, + at the expense of reducing cache hit rates and causing more DNS + traffic. + Additionally, if additional section caching + (the section called “Additional Section Caching”) is enabled, + the max-acache-size option can be used to + limit the amount + of memory used by the mechanism. + It is still good practice to have enough memory to load + all zone and cache data into memory — unfortunately, the best + way + to determine this for a given installation is to watch the name server + in operation. After a few weeks the server process should reach + a relatively stable size where entries are expiring from the cache as + fast as they are being inserted. +

+
+
+

+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 + any second-level internal name servers query a main name server, which + has enough memory to build a large cache. This approach minimizes + the bandwidth used by external name lookups. The second alternative + is to set up second-level internal name servers to make queries + independently. + In this configuration, none of the individual machines needs to + have as much memory or CPU power as in the first alternative, but + this has the disadvantage of making many more external queries, + as none of the name servers share their cached data. +

+
+
+

+Supported Operating Systems

+

+ ISC BIND 9 compiles and runs on a large + number + of Unix-like operating systems and on NT-derived versions of + Microsoft Windows such as Windows 2000 and Windows XP. For an + up-to-date + list of supported systems, see the README file in the top level + directory + of the BIND 9 source distribution. +

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 1. Introduction Home Chapter 3. Name Server Configuration
+
+ + diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html new file mode 100644 index 0000000..d548ddf --- /dev/null +++ b/doc/arm/Bv9ARM.ch03.html @@ -0,0 +1,818 @@ + + + + + +Chapter 3. Name Server Configuration + + + + + + + +
+ + + + + + + +
Chapter 3. Name Server Configuration
+Prev   Next +
+
+
+
+

+Chapter 3. Name Server Configuration

+
+

Table of Contents

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

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

+
+

+Sample Configurations

+
+

+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 + queries + from outside clients are refused using the allow-query + option. Alternatively, the same effect could be achieved using + suitable + firewall rules. +

+
+// Two corporate subnets we wish to allow queries from.
+acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
+options {
+     directory "/etc/namedb";           // Working directory
+     allow-query { corpnets; };
+};
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+
+
+
+

+An Authoritative-only Name Server

+

+ This sample configuration is for an authoritative-only server + that is the master server for "example.com" + and a slave for the subdomain "eng.example.com". +

+
+options {
+     directory "/etc/namedb";           // Working directory
+     allow-query-cache { none; };       // Do not allow access to cache
+     allow-query { any; };              // This is the default
+     recursion no;                      // Do not provide recursive service
+};
+
+// Provide a reverse mapping for the loopback address 127.0.0.1
+zone "0.0.127.in-addr.arpa" {
+     type master;
+     file "localhost.rev";
+     notify no;
+};
+// We are the master server for example.com
+zone "example.com" {
+     type master;
+     file "example.com.db";
+     // IP addresses of slave servers allowed to transfer example.com
+     allow-transfer {
+          192.168.4.14;
+          192.168.5.53;
+     };
+};
+// We are a slave server for eng.example.com
+zone "eng.example.com" {
+     type slave;
+     file "eng.example.com.bk";
+     // IP address of eng.example.com master server
+     masters { 192.168.4.12; };
+};
+
+
+
+
+

+Load Balancing

+

+ A primitive form of load balancing can be achieved in + the DNS by using multiple records + (such as multiple A records) for one name. +

+

+ For example, if you have three WWW servers with network addresses + of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the + following means that clients will connect to each machine one third + of the time: +

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

+ Name +

+ 		+

+ TTL +

+ 		+

+ CLASS +

+ 		+

+ TYPE +

+ 		+

+ Resource Record (RR) Data +

+
+

+ www +

+ 		+

+ 600 +

+ 		+

+ IN +

+ 		+

+ A +

+ 		+

+ 10.0.0.1 +

+
+

+ 		+

+ 600 +

+ 		+

+ IN +

+ 		+

+ A +

+ 		+

+ 10.0.0.2 +

+
+

+ 		+

+ 600 +

+ 		+

+ IN +

+ 		+

+ A +

+ 		+

+ 10.0.0.3 +

+
+

+ When a resolver queries for these records, BIND will rotate + them and respond to the query with the records in a different + order. In the example above, clients will randomly receive + records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients + will use the first record returned and discard the rest. +

+

+ For more detail on ordering responses, check the + rrset-order substatement in the + options statement, see + RRset Ordering. +

+
+
+

+Name Server Operations

+
+

+Tools for Use With the Name Server Daemon

+

+ This section describes several indispensable diagnostic, + administrative and monitoring tools available to the system + administrator for controlling and debugging the name server + daemon. +

+
+

+Diagnostic Tools

+

+ The dig, host, and + nslookup programs are all command + line tools + for manually querying name servers. They differ in style and + output format. +

+
+
dig
+
+

+ The domain information groper (dig) + is the most versatile and complete of these lookup tools. + It has two modes: simple interactive + mode for a single query, and batch mode which executes a + query for + each in a list of several query lines. All query options are + accessible + from the command line. +

+

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

+

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

+

+ dig @server domain query-type query-class +

+

+ For more information and a list of available commands and + options, see the dig man + page. +

+
+
host
+
+

+ The host utility emphasizes + simplicity + and ease of use. By default, it converts + between host names and Internet addresses, but its + functionality + can be extended with the use of options. +

+

host [-aCdlnrsTwv] [-c class] [-N ndots] [-t type] [-W timeout] [-R retries] [-m flag] [-4] [-6] hostname [server]

+

+ For more information and a list of available commands and + options, see the host man + page. +

+
+
nslookup
+
+

nslookup + has two modes: interactive and + non-interactive. Interactive mode allows the user to + query name servers for information about various + hosts and domains or to print a list of hosts in a + domain. Non-interactive mode is used to print just + the name and requested information for a host or + domain. +

+

nslookup [-option...] [[host-to-find] | [- [server]]]

+

+ Interactive mode is entered when no arguments are given (the + default name server will be used) or when the first argument + is a + hyphen (`-') and the second argument is the host name or + Internet address + of a name server. +

+

+ Non-interactive mode is used when the name or Internet + address + of the host to be looked up is given as the first argument. + The + optional second argument specifies the host name or address + of a name server. +

+

+ Due to its arcane user interface and frequently inconsistent + behavior, we do not recommend the use of nslookup. + Use dig instead. +

+
+
+
+
+

+Administrative Tools

+

+ Administrative tools play an integral part in the management + of a server. +

+
+
+named-checkconf +
+
+

+ The named-checkconf program + checks the syntax of a named.conf file. +

+

named-checkconf [-jvz] [-t directory] [filename]

+
+
+named-checkzone +
+
+

+ The named-checkzone program + checks a master file for + syntax and consistency. +

+

named-checkzone [-djqvD] [-c class] [-o output] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] [-W (ignore|warn)] zone [filename]

+
+
+named-compilezone +
+

+ Similar to named-checkzone, but + it always dumps the zone content to a specified file + (typically in a different format). +

+
+rndc +
+
+

+ The remote name daemon control + (rndc) program allows the + system + administrator to control the operation of a name server. + Since BIND 9.2, rndc + supports all the commands of the BIND 8 ndc + utility except ndc start and + ndc restart, which were also + not supported in ndc's + channel mode. + If you run rndc without any + options + it will display a usage message as follows: +

+

rndc [-c config] [-s server] [-p port] [-y key] command [command...]

+

The command + is one of the following: +

+
+
reload
+

+ Reload configuration file and zones. +

+
reload zone + [class + [view]]
+

+ Reload the given zone. +

+
refresh zone + [class + [view]]
+

+ Schedule zone maintenance for the given zone. +

+
retransfer zone + + [class + [view]]
+

+ Retransfer the given zone from the master. +

+
freeze + [zone + [class + [view]]]
+

+ Suspend updates to a dynamic zone. If no zone is + specified, + then all zones are suspended. This allows manual + edits to be made to a zone normally updated by dynamic + update. It + also causes changes in the journal file to be synced + into the master + and the journal file to be removed. All dynamic + update attempts will + be refused while the zone is frozen. +

+
thaw + [zone + [class + [view]]]
+

+ Enable updates to a frozen dynamic zone. If no zone + is + specified, then all frozen zones are enabled. This + causes + the server to reload the zone from disk, and + re-enables dynamic updates + after the load has completed. After a zone is thawed, + dynamic updates + will no longer be refused. +

+
notify zone + [class + [view]]
+

+ Resend NOTIFY messages for the zone. +

+
reconfig
+

+ Reload the configuration file and load new zones, + but do not reload existing zone files even if they + have changed. + This is faster than a full reload when there + is a large number of zones because it avoids the need + to examine the + modification times of the zones files. +

+
stats
+

+ Write server statistics to the statistics file. +

+
querylog
+

+ Toggle query logging. Query logging can also be enabled + by explicitly directing the queries + category to a + channel in the + logging section of + named.conf or by specifying + querylog yes; in the + options section of + named.conf. +

+
dumpdb + [-all|-cache|-zone] + [view ...]
+

+ Dump the server's caches (default) and/or zones to + the + dump file for the specified views. If no view is + specified, all + views are dumped. +

+
stop [-p]
+

+ Stop the server, making sure any recent changes + made through dynamic update or IXFR are first saved to + the master files of the updated zones. + If -p is specified named's process id is returned. + This allows an external process to determine when named + had completed stopping. +

+
halt [-p]
+

+ Stop the server immediately. Recent changes + made through dynamic update or IXFR are not saved to + the master files, but will be rolled forward from the + journal files when the server is restarted. + If -p is specified named's process id is returned. + This allows an external process to determine when named + had completed halting. +

+
trace
+

+ Increment the servers debugging level by one. +

+
trace level
+

+ Sets the server's debugging level to an explicit + value. +

+
notrace
+

+ Sets the server's debugging level to 0. +

+
flush
+

+ Flushes the server's cache. +

+
flushname name
+

+ Flushes the given name from the server's cache. +

+
status
+

+ Display status of the server. + Note that the number of zones includes the internal bind/CH zone + and the default ./IN + hint zone if there is not an + explicit root zone configured. +

+
recursing
+

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

+
validation + [on|off] + [view ...] +
+

+ Enable or disable DNSSEC validation. + Note dnssec-enable also needs to be + set to yes to be effective. + It defaults to enabled. +

+
+

+ A configuration file is required, since all + communication with the server is authenticated with + digital signatures that rely on a shared secret, and + there is no way to provide that secret other than with a + configuration file. The default location for the + rndc configuration file is + /etc/rndc.conf, but an + alternate + location can be specified with the -c + option. If the configuration file is not found, + rndc will also look in + /etc/rndc.key (or whatever + sysconfdir was defined when + the BIND build was + configured). + The rndc.key file is + generated by + running rndc-confgen -a as + described in + the section called “controls Statement Definition and + Usage”. +

+

+ The format of the configuration file is similar to + that of named.conf, but + limited to + only four statements, the options, + key, server and + include + statements. These statements are what associate the + secret keys to the servers with which they are meant to + be shared. The order of statements is not + significant. +

+

+ The options statement has + three clauses: + default-server, default-key, + and default-port. + default-server takes a + host name or address argument and represents the server + that will + be contacted if no -s + option is provided on the command line. + default-key takes + the name of a key as its argument, as defined by a key statement. + default-port specifies the + port to which + rndc should connect if no + port is given on the command line or in a + server statement. +

+

+ The key statement defines a + key to be used + by rndc when authenticating + with + named. Its syntax is + identical to the + 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; + thus, + a string like "rndc_key" is a valid + name. + The key statement has two + clauses: + algorithm and secret. + While the configuration parser will accept any string as the + argument + to algorithm, currently only the string "hmac-md5" + has any meaning. The secret is a base-64 encoded string + as specified in RFC 3548. +

+

+ The server statement + associates a key + defined using the key + statement with a server. + The keyword server is followed by a + host name or address. The server statement + has two clauses: key and port. + The key clause specifies the + name of the key + to be used when communicating with this server, and the + port clause can be used to + specify the port rndc should + connect + to on the server. +

+

+ A sample minimal configuration file is as follows: +

+
+key rndc_key {
+     algorithm "hmac-md5";
+     secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
+};
+options {
+     default-server 127.0.0.1;
+     default-key    rndc_key;
+};
+
+

+ This file, if installed as /etc/rndc.conf, + would allow the command: +

+

+ $ rndc reload +

+

+ to connect to 127.0.0.1 port 953 and cause the name server + to reload, if a name server on the local machine were + running with + following controls statements: +

+
+controls {
+        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
+};
+
+

+ and it had an identical key statement for + rndc_key. +

+

+ Running the rndc-confgen + program will + conveniently create a rndc.conf + file for you, and also display the + corresponding controls + statement that you need to + add to named.conf. + Alternatively, + you can run rndc-confgen -a + to set up + a rndc.key file and not + modify + named.conf at all. +

+
+
+
+
+
+

+Signals

+

+ Certain UNIX signals cause the name server to take specific + actions, as described in the following table. These signals can + be sent using the kill command. +

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

SIGHUP

+ 		+

+ Causes the server to read named.conf and + reload the database. +

+
+

SIGTERM

+ 		+

+ Causes the server to clean up and exit. +

+
+

SIGINT

+ 		+

+ Causes the server to clean up and exit. +

+
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 2. BIND Resource Requirements Home Chapter 4. Advanced DNS Features
+
+ + diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html new file mode 100644 index 0000000..4aba208 --- /dev/null +++ b/doc/arm/Bv9ARM.ch04.html @@ -0,0 +1,1036 @@ + + + + + +Chapter 4. Advanced DNS Features + + + + + + + +
+ + + + + + + +
Chapter 4. Advanced DNS Features
+Prev   Next +
+
+
+
+

+Chapter 4. Advanced DNS Features

+
+

Table of Contents

+
+
Notify
+
Dynamic Update
+
The journal file
+
Incremental Zone Transfers (IXFR)
+
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
+
+
TKEY
+
SIG(0)
+
DNSSEC
+
+
Generating Keys
+
Signing the Zone
+
Configuring Servers
+
+
IPv6 Support in BIND 9
+
+
Address Lookups Using AAAA Records
+
Address to Name Lookups Using Nibble Format
+
+
+
+
+

+Notify

+

+ DNS NOTIFY is a mechanism that allows master + servers to notify their slave servers of changes to a zone's data. In + response to a NOTIFY from a master server, the + slave will check to see that its version of the zone is the + current version and, if not, initiate a zone transfer. +

+

+ For more information about DNS + NOTIFY, see the description of the + notify option in the section called “Boolean Options” and + the description of the zone option also-notify in + the section called “Zone Transfers”. The NOTIFY + protocol is specified in RFC 1996. +

+
+

Note

+ 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 + zones that it loads. +
+
+
+

+Dynamic Update

+

+ Dynamic Update is a method for adding, replacing or deleting + records in a master server by sending it a special form of DNS + messages. The format and meaning of these messages is specified + in RFC 2136. +

+

+ Dynamic update is enabled by including an + allow-update or update-policy + clause in the zone statement. The + tkey-gssapi-credential and + tkey-domain clauses in the + options statement enable the + server to negotiate keys that can be matched against those + in update-policy or + allow-update. +

+

+ Updating of secure zones (zones using DNSSEC) follows RFC + 3007: RRSIG, NSEC and NSEC3 records affected by updates are + automatically regenerated by the server using an online + zone key. Update authorization is based on transaction + signatures and an explicit server policy. +

+
+

+The journal file

+

+ All changes made to a zone using dynamic update are stored + in the zone's journal file. This file is automatically created + by the server when the first dynamic update takes place. + The name of the journal file is formed by appending the extension + .jnl to the name of the + corresponding zone + file unless specifically overridden. The journal file is in a + binary format and should not be edited manually. +

+

+ The server will also occasionally write ("dump") + the complete contents of the updated zone to its zone file. + This is not done immediately after + each dynamic update, because that would be too slow when a large + zone is updated frequently. Instead, the dump is delayed by + up to 15 minutes, allowing additional updates to take place. +

+

+ When a server is restarted after a shutdown or crash, it will replay + the journal file to incorporate into the zone any updates that + took + place after the last zone dump. +

+

+ Changes that result from incoming incremental zone transfers are + also + journalled in a similar way. +

+

+ The zone files of dynamic zones cannot normally be edited by + hand because they are not guaranteed to contain the most recent + dynamic changes — those are only in the journal file. + The only way to ensure that the zone file of a dynamic zone + is up to date is to run rndc stop. +

+

+ If you have to make changes to a dynamic zone + manually, the following procedure will work: Disable dynamic updates + to the zone using + rndc freeze zone. + This will also remove the zone's .jnl file + and update the master file. Edit the zone file. Run + rndc thaw zone + to reload the changed zone and re-enable dynamic updates. +

+
+
+
+

+Incremental Zone Transfers (IXFR)

+

+ The incremental zone transfer (IXFR) protocol is a way for + slave servers to transfer only changed data, instead of having to + transfer the entire zone. The IXFR protocol is specified in RFC + 1995. See Proposed Standards. +

+

+ When acting as a master, BIND 9 + supports IXFR for those zones + where the necessary change history information is available. These + include master zones maintained by dynamic update and slave zones + whose data was obtained by IXFR. For manually maintained master + zones, and for slave zones obtained by performing a full zone + transfer (AXFR), IXFR is supported only if the option + ixfr-from-differences is set + to yes. +

+

+ When acting as a slave, BIND 9 will + attempt to use IXFR unless + it is explicitly disabled. For more information about disabling + IXFR, see the description of the request-ixfr clause + of the server statement. +

+
+
+

+Split DNS

+

+ Setting up different views, or visibility, of the DNS space to + internal and external resolvers is usually referred to as a + Split DNS setup. There are several + reasons an organization would want to set up its DNS this way. +

+

+ One common reason for setting up a DNS system this way is + to hide "internal" DNS information from "external" clients on the + Internet. There is some debate as to whether or not this is actually + useful. + Internal DNS information leaks out in many ways (via email headers, + for example) and most savvy "attackers" can find the information + they need using other means. + However, since listing addresses of internal servers that + external clients cannot possibly reach can result in + connection delays and other annoyances, an organization may + choose to use a Split DNS to present a consistent view of itself + to the outside world. +

+

+ Another common reason for setting up a Split DNS system is + to allow internal networks that are behind filters or in RFC 1918 + space (reserved IP space, as documented in RFC 1918) to resolve DNS + on the Internet. Split DNS can also be used to allow mail from outside + back in to the internal network. +

+
+

+Example split DNS setup

+

+ Let's say a company named Example, Inc. + (example.com) + has several corporate sites that have an internal network with + reserved + Internet Protocol (IP) space and an external demilitarized zone (DMZ), + or "outside" section of a network, that is available to the public. +

+

+ Example, Inc. wants its internal clients + to be able to resolve external hostnames and to exchange mail with + people on the outside. The company also wants its internal resolvers + to have access to certain internal-only zones that are not available + at all outside of the internal network. +

+

+ In order to accomplish this, the company will set up two sets + of name servers. One set will be on the inside network (in the + reserved + IP space) and the other set will be on bastion hosts, which are + "proxy" + hosts that can talk to both sides of its network, in the DMZ. +

+

+ The internal servers will be configured to forward all queries, + except queries for site1.internal, site2.internal, site1.example.com, + and site2.example.com, to the servers + in the + DMZ. These internal servers will have complete sets of information + for site1.example.com, site2.example.com, site1.internal, + and site2.internal. +

+

+ To protect the site1.internal and site2.internal domains, + the internal name servers must be configured to disallow all queries + to these domains from any external hosts, including the bastion + hosts. +

+

+ The external servers, which are on the bastion hosts, will + be configured to serve the "public" version of the site1 and site2.example.com zones. + This could include things such as the host records for public servers + (www.example.com and ftp.example.com), + and mail exchange (MX) records (a.mx.example.com and b.mx.example.com). +

+

+ In addition, the public site1 and site2.example.com zones + should have special MX records that contain wildcard (`*') records + pointing to the bastion hosts. This is needed because external mail + servers do not have any other way of looking up how to deliver mail + to those internal hosts. With the wildcard records, the mail will + be delivered to the bastion host, which can then forward it on to + internal hosts. +

+

+ Here's an example of a wildcard MX record: +

+
*   IN MX 10 external1.example.com.
+

+ Now that they accept mail on behalf of anything in the internal + network, the bastion hosts will need to know how to deliver mail + to internal hosts. In order for this to work properly, the resolvers + on + the bastion hosts will need to be configured to point to the internal + name servers for DNS resolution. +

+

+ Queries for internal hostnames will be answered by the internal + servers, and queries for external hostnames will be forwarded back + out to the DNS servers on the bastion hosts. +

+

+ In order for all this to work properly, internal clients will + need to be configured to query only the internal + name servers for DNS queries. This could also be enforced via + selective + filtering on the network. +

+

+ If everything has been set properly, Example, Inc.'s + internal clients will now be able to: +

+
    +
  • + Look up any hostnames in the site1 + and + site2.example.com zones. +
    • +
  • + Look up any hostnames in the site1.internal and + site2.internal domains. +
    • +
  • Look up any hostnames on the Internet.
    • +
  • Exchange mail with both internal and external people.
    • +
+

+ Hosts on the Internet will be able to: +

+
    +
  • + Look up any hostnames in the site1 + and + site2.example.com zones. +
    • +
  • + Exchange mail with anyone in the site1 and + site2.example.com zones. +
    • +
+

+ Here is an example configuration for the setup we just + described above. Note that this is only configuration information; + for information on how to configure your zone files, see the section called “Sample Configurations”. +

+

+ Internal DNS server config: +

+
+
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { bastion-ips-go-here; };
+
+options {
+    ...
+    ...
+    forward only;
+    forwarders {                                // forward to external servers
+        bastion-ips-go-here;
+    };
+    allow-transfer { none; };                   // sample allow-transfer (no one)
+    allow-query { internals; externals; };      // restrict query access
+    allow-recursion { internals; };             // restrict recursion
+    ...
+    ...
+};
+
+zone "site1.example.com" {                      // sample master zone
+  type master;
+  file "m/site1.example.com";
+  forwarders { };                               // do normal iterative
+                                                // resolution (do not forward)
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site2.example.com" {                      // sample slave zone
+  type slave;
+  file "s/site2.example.com";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals; externals; };
+  allow-transfer { internals; };
+};
+
+zone "site1.internal" {
+  type master;
+  file "m/site1.internal";
+  forwarders { };
+  allow-query { internals; };
+  allow-transfer { internals; }
+};
+
+zone "site2.internal" {
+  type slave;
+  file "s/site2.internal";
+  masters { 172.16.72.3; };
+  forwarders { };
+  allow-query { internals };
+  allow-transfer { internals; }
+};
+
+

+ External (bastion host) DNS server config: +

+
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
+acl externals { bastion-ips-go-here; };
+
+options {
+  ...
+  ...
+  allow-transfer { none; };                     // sample allow-transfer (no one)
+  allow-query { any; };                         // default query access
+  allow-query-cache { internals; externals; };  // restrict cache access
+  allow-recursion { internals; externals; };    // restrict recursion
+  ...
+  ...
+};
+
+zone "site1.example.com" {                      // sample slave zone
+  type master;
+  file "m/site1.foo.com";
+  allow-transfer { internals; externals; };
+};
+
+zone "site2.example.com" {
+  type slave;
+  file "s/site2.foo.com";
+  masters { another_bastion_host_maybe; };
+  allow-transfer { internals; externals; }
+};
+
+

+ In the resolv.conf (or equivalent) on + the bastion host(s): +

+
+search ...
+nameserver 172.16.72.2
+nameserver 172.16.72.3
+nameserver 172.16.72.4
+
+
+
+
+

+TSIG

+

+ This is a short guide to setting up Transaction SIGnatures + (TSIG) based transaction security in BIND. It describes changes + to the configuration file as well as what changes are required for + different features, including the process of creating transaction + keys and using transaction signatures with BIND. +

+

+ BIND primarily supports TSIG for server + to server communication. + This includes zone transfer, notify, and recursive query messages. + Resolvers based on newer versions of BIND 8 have limited support + for TSIG. +

+

+ TSIG can also be useful for dynamic update. A primary + server for a dynamic zone should control access to the dynamic + update service, but IP-based access control is insufficient. + The cryptographic access control provided by TSIG + is far superior. The nsupdate + program supports TSIG via the -k and + -y command line options or inline by use + of the key. +

+
+

+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 + be the same on both hosts. +

+
+

+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 + are easier to read. Note that the maximum key length is 512 bits; + keys longer than that will be digested with MD5 to produce a + 128-bit key. +

+

+ dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2. +

+

+ The key is in the file Khost1-host2.+157+00000.private. + Nothing directly uses this file, but the base-64 encoded string + following "Key:" + can be extracted from the file and used as a shared secret: +

+
Key: La/E5CjG9O+os1jq0a2jdA==
+

+ The string "La/E5CjG9O+os1jq0a2jdA==" can + be used as the shared secret. +

+
+
+

+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 + the length is a multiple of 4 and only valid characters are used), + so the shared secret can be manually generated. +

+

+ Also, a known string can be run through mmencode or + a similar program to generate base-64 encoded data. +

+
+
+
+

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

+
+
+

+Informing the Servers of the Key's Existence

+

+ Imagine host1 and host 2 + are + both servers. The following is added to each server's named.conf file: +

+
+key host1-host2. {
+  algorithm hmac-md5;
+  secret "La/E5CjG9O+os1jq0a2jdA==";
+};
+
+

+ 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 + file that is included by + named.conf. +

+

+ At this point, the key is recognized. This means that if the + server receives a message signed by this key, it can verify the + signature. If the signature is successfully verified, the + response is signed by the same key. +

+
+
+

+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 + for host1, if the IP address of host2 is + 10.1.2.3: +

+
+server 10.1.2.3 {
+  keys { host1-host2. ;};
+};
+
+

+ Multiple keys may be present, but only the first is used. + This directive does not contain any secrets, so it may be in a + world-readable + file. +

+

+ If host1 sends a message that is a request + to that address, the message will be signed with the specified key. host1 will + expect any responses to signed messages to be signed with the same + key. +

+

+ A similar statement must be present in host2's + configuration file (with host1's address) for host2 to + sign request messages to host1. +

+
+
+

+TSIG Key Based Access Control

+

+ BIND allows IP addresses and ranges + to be specified in ACL + definitions and + allow-{ query | transfer | update } + directives. + This has been extended to allow TSIG keys also. The above key would + be denoted key host1-host2. +

+

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

+
+allow-update { key host1-host2. ;};
+
+

+ This allows dynamic updates to succeed only if the request + was signed by a key named "host1-host2.". +

+

+ You may want to read about the more powerful + update-policy statement in + the section called “Dynamic Update Policies”. +

+
+
+

+Errors

+

+ The processing of TSIG signed messages can result in + several errors. If a signed message is sent to a non-TSIG aware + server, a FORMERR (format error) will be returned, since the server will not + understand the record. This is a result of misconfiguration, + since the server must be explicitly configured to send a TSIG + signed message to a specific server. +

+

+ If a TSIG aware server receives a message signed by an + unknown key, the response will be unsigned with the TSIG + extended error code set to BADKEY. If a TSIG aware server + receives a message with a signature that does not validate, the + response will be unsigned with the TSIG extended error code set + to BADSIG. If a TSIG aware server receives a message with a time + outside of the allowed range, the response will be signed with + the TSIG extended error code set to BADTIME, and the time values + will be adjusted so that the response can be successfully + verified. In any of these cases, the message's rcode (response code) is set to + NOTAUTH (not authenticated). +

+
+
+
+

+TKEY

+

TKEY + is a mechanism for automatically generating a shared secret + between two hosts. There are several "modes" of + TKEY that specify how the key is generated + or assigned. BIND 9 implements only one of + these modes, the Diffie-Hellman key exchange. Both hosts are + required to have a Diffie-Hellman KEY record (although this + record is not required to be present in a zone). The + TKEY process must use signed messages, + signed either by TSIG or SIG(0). The result of + TKEY is a shared secret that can be used to + sign messages with TSIG. TKEY can also be + used to delete shared secrets that it had previously + generated. +

+

+ The TKEY process is initiated by a + client + or server by sending a signed TKEY + query + (including any appropriate KEYs) to a TKEY-aware server. The + server response, if it indicates success, will contain a + TKEY record and any appropriate keys. + After + this exchange, both participants have enough information to + determine the shared secret; the exact process depends on the + TKEY mode. When using the + Diffie-Hellman + TKEY mode, Diffie-Hellman keys are + exchanged, + and the shared secret is derived by both participants. +

+
+
+

+SIG(0)

+

+ BIND 9 partially supports DNSSEC SIG(0) + transaction signatures as specified in RFC 2535 and RFC2931. + SIG(0) + uses public/private keys to authenticate messages. Access control + is performed in the same manner as TSIG keys; privileges can be + granted or denied based on the key name. +

+

+ When a SIG(0) signed message is received, it will only be + verified if the key is known and trusted by the server; the server + will not attempt to locate and/or validate the key. +

+

+ SIG(0) signing of multiple-message TCP streams is not + supported. +

+

+ The only tool shipped with BIND 9 that + generates SIG(0) signed messages is nsupdate. +

+
+
+

+DNSSEC

+

+ Cryptographic authentication of DNS information is possible + through the DNS Security (DNSSEC-bis) extensions, + defined in RFC 4033, RFC 4034, and RFC 4035. + This section describes the creation and use of DNSSEC signed zones. +

+

+ In order to set up a DNSSEC secure zone, there are a series + of steps which must be followed. BIND + 9 ships + with several tools + that are used in this process, which are explained in more detail + below. In all cases, the -h option prints a + full list of parameters. Note that the DNSSEC tools require the + keyset files to be in the working directory or the + directory specified by the -d option, and + that the tools shipped with BIND 9.2.x and earlier are not compatible + with the current ones. +

+

+ There must also be communication with the administrators of + the parent and/or child zone to transmit keys. A zone's security + status must be indicated by the parent zone for a DNSSEC capable + resolver to trust its data. This is done through the presence + or absence of a DS record at the + delegation + point. +

+

+ For other servers to trust data in this zone, they must + either be statically configured with this zone's zone key or the + zone key of another zone above this one in the DNS tree. +

+
+

+Generating Keys

+

+ The dnssec-keygen program is used to + generate keys. +

+

+ A secure zone must contain one or more zone keys. The + zone keys will sign all other records in the zone, as well as + the zone keys of any secure delegated zones. Zone keys must + have the same name as the zone, a name type of + ZONE, and must be usable for + authentication. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + the only one is RSASHA1. +

+

+ The following command will generate a 768-bit RSASHA1 key for + the child.example zone: +

+

+ dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example. +

+

+ Two output files will be produced: + Kchild.example.+005+12345.key and + Kchild.example.+005+12345.private + (where + 12345 is an example of a key tag). The key filenames contain + the key name (child.example.), + algorithm (3 + is DSA, 1 is RSAMD5, 5 is RSASHA1, etc.), and the key tag (12345 in + this case). + The private key (in the .private + file) is + used to generate signatures, and the public key (in the + .key file) is used for signature + verification. +

+

+ To generate another key with the same properties (but with + a different key tag), repeat the above command. +

+

+ The dnssec-keyfromlabel program is used + to get a key pair from a crypto hardware and build the key + files. Its usage is similar to dnssec-keygen. +

+

+ The public keys should be inserted into the zone file by + including the .key files using + $INCLUDE statements. +

+
+
+

+Signing the Zone

+

+ The dnssec-signzone program is used + to sign a zone. +

+

+ Any keyset files corresponding to + secure subzones should be present. The zone signer will + generate NSEC, NSEC3 + and RRSIG records for the zone, as + well as DS for the child zones if + '-g' is specified. If '-g' + is not specified, then DS RRsets for the secure child + zones need to be added manually. +

+

+ The following command signs the zone, assuming it is in a + file called zone.child.example. By + default, all zone keys which have an available private key are + used to generate signatures. +

+

+ dnssec-signzone -o child.example zone.child.example +

+

+ One output file is produced: + zone.child.example.signed. This + file + should be referenced by named.conf + as the + input file for the zone. +

+

dnssec-signzone + will also produce a keyset and dsset files and optionally a + dlvset file. These are used to provide the parent zone + administrators with the DNSKEYs (or their + corresponding DS records) that are the + secure entry point to the zone. +

+
+
+

+Configuring Servers

+

+ To enable named to respond appropriately + to DNS requests from DNSSEC aware clients, + dnssec-enable must be set to yes. +

+

+ To enable named to validate answers from + other servers both dnssec-enable and + dnssec-validation must be set and some + trusted-keys must be configured + into named.conf. +

+

+ trusted-keys are copies of DNSKEY RRs + for zones that are used to form the first link in the + cryptographic chain of trust. All keys listed in + trusted-keys (and corresponding zones) + are deemed to exist and only the listed keys will be used + to validated the DNSKEY RRset that they are from. +

+

+ trusted-keys are described in more detail + later in this document. +

+

+ Unlike BIND 8, BIND + 9 does not verify signatures on load, so zone keys for + authoritative zones do not need to be specified in the + configuration file. +

+

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

+
+trusted-keys {
+
+        /* Root Key */
+"." 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwSJxrGkxJWoZu6I7PzJu/
+             E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3
+             zy2Xy4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYghf+6fElrmLkdaz
+             MQ2OCnACR817DF4BBa7UR/beDHyp5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M
+             /lUUVRbkeg1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq66gKodQj+M
+             iA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ97S+LKUTpQcq27R7AT3/V5hRQxScI
+             Nqwcz4jYqZD2fQdgxbcDTClU0CRBdiieyLMNzXG3";
+
+/* Key for our organization's forward zone */
+example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe
+                      3Y9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbb
+                      OTcM8pwXlj0EiX3oDFVmjHO444gLkBO UKUf/mC7HvfwYH/Be22GnC
+                      lrinKJp1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt
+                      8lgnyTUHs1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/b
+                      iuvF4qJCyduieHukuY3H4XMAcR+xia2 nIUPvm/oyWR8BW/hWdzOvn
+                      SCThlHf3xiYleDbt/o1OTQ09A0=";
+
+/* Key for our reverse zone. */
+2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwcxOdNax071L18QqZnQQQA
+                                VVr+iLhGTnNGp3HoWQLUIzKrJVZ3zggy3WwNT6kZo6c0
+                                tszYqbtvchmgQC8CzKojM/W16i6MG/ea fGU3siaOdS0
+                                yOI6BgPsw+YZdzlYMaIJGf4M4dyoKIhzdZyQ2bYQrjyQ
+                                4LB0lC7aOnsMyYKHHYeRv PxjIQXmdqgOJGq+vsevG06
+                                zW+1xgYJh9rCIfnm1GX/KMgxLPG2vXTD/RnLX+D3T3UL
+                                7HJYHJhAZD5L59VvjSPsZJHeDCUyWYrvPZesZDIRvhDD
+                                52SKvbheeTJUm6EhkzytNN2SN96QRk8j/iI8ib";
+};
+
+options {
+        ...
+        dnssec-enable yes;
+        dnssec-validation yes;
+};
+
+
+

Note

+ None of the keys listed in this example are valid. In particular, + the root key is not valid. +
+
+
+
+

+IPv6 Support in BIND 9

+

+ BIND 9 fully supports all currently + defined forms of IPv6 + name to address and address to name lookups. It will also use + IPv6 addresses to make queries when running on an IPv6 capable + system. +

+

+ For forward lookups, BIND 9 supports + only AAAA records. RFC 3363 deprecated the use of A6 records, + and client-side support for A6 records was accordingly removed + from BIND 9. + However, authoritative BIND 9 name servers still + load zone files containing A6 records correctly, answer queries + for A6 records, and accept zone transfer for a zone containing A6 + records. +

+

+ For IPv6 reverse lookups, BIND 9 supports + the traditional "nibble" format used in the + ip6.arpa domain, as well as the older, deprecated + ip6.int domain. + Older versions of BIND 9 + supported the "binary label" (also known as "bitstring") format, + but support of binary labels has been completely removed per + RFC 3363. + Many applications in BIND 9 do not understand + the binary label format at all any more, and will return an + error if given. + In particular, an authoritative BIND 9 + name server will not load a zone file containing binary labels. +

+

+ For an overview of the format and structure of IPv6 addresses, + see the section called “IPv6 addresses (AAAA)”. +

+
+

+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 + IPv6 address in a single record. For example, +

+
+$ORIGIN example.com.
+host            3600    IN      AAAA    2001:db8::1
+
+

+ Use of IPv4-in-IPv6 mapped addresses is not recommended. + If a host has an IPv4 address, use an A record, not + a AAAA, with ::ffff:192.168.42.1 as + the address. +

+
+
+

+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 + ip6.arpa. is appended to the + resulting name. + For example, the following would provide reverse name lookup for + a host with address + 2001:db8::1. +

+
+$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
+1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.
+
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 3. Name Server Configuration Home Chapter 5. The BIND 9 Lightweight Resolver
+
+ + diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html new file mode 100644 index 0000000..29ff97c --- /dev/null +++ b/doc/arm/Bv9ARM.ch05.html @@ -0,0 +1,143 @@ + + + + + +Chapter 5. The BIND 9 Lightweight Resolver + + + + + + + +
+ + + + + + + +
Chapter 5. The BIND 9 Lightweight Resolver
+Prev   Next +
+
+
+
+

+Chapter 5. The BIND 9 Lightweight Resolver

+
+

Table of Contents

+
+
The Lightweight Resolver Library
+
Running a Resolver Daemon
+
+
+
+

+The Lightweight Resolver Library

+

+ Traditionally applications have been linked with a stub resolver + library that sends recursive DNS queries to a local caching name + server. +

+

+ IPv6 once introduced new complexity into the resolution process, + such as following A6 chains and DNAME records, and simultaneous + lookup of IPv4 and IPv6 addresses. Though most of the complexity was + then removed, these are hard or impossible + to implement in a traditional stub resolver. +

+

+ BIND 9 therefore can also provide resolution + services to local clients + using a combination of a lightweight resolver library and a resolver + daemon process running on the local host. These communicate using + a simple UDP-based protocol, the "lightweight resolver protocol" + that is distinct from and simpler than the full DNS protocol. +

+
+
+

+Running a Resolver Daemon

+

+ To use the lightweight resolver interface, the system must + run the resolver daemon lwresd or a + local + name server configured with a lwres + statement. +

+

+ By default, applications using the lightweight resolver library will + make + UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. + The + address can be overridden by lwserver + lines in + /etc/resolv.conf. +

+

+ The daemon currently only looks in the DNS, but in the future + it may use other sources such as /etc/hosts, + NIS, etc. +

+

+ The lwresd daemon is essentially a + caching-only name server that responds to requests using the + lightweight + resolver protocol rather than the DNS protocol. Because it needs + to run on each host, it is designed to require no or minimal + configuration. + Unless configured otherwise, it uses the name servers listed on + nameserver lines in /etc/resolv.conf + as forwarders, but is also capable of doing the resolution + autonomously if + none are specified. +

+

+ The lwresd daemon may also be + configured with a + named.conf style configuration file, + in + /etc/lwresd.conf by default. A name + server may also + be configured to act as a lightweight resolver daemon using the + lwres statement in named.conf. +

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 4. Advanced DNS Features Home Chapter 6. BIND 9 Configuration Reference
+
+ + diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html new file mode 100644 index 0000000..1f39b96 --- /dev/null +++ b/doc/arm/Bv9ARM.ch06.html @@ -0,0 +1,8784 @@ + + + + + +Chapter 6. BIND 9 Configuration Reference + + + + + + + +
+ + + + + + + +
Chapter 6. BIND 9 Configuration Reference
+Prev   Next +
+
+
+
+

+Chapter 6. BIND 9 Configuration Reference

+
+

Table of Contents

+
+
Configuration File Elements
+
+
Address Match Lists
+
Comment Syntax
+
+
Configuration File Grammar
+
+
acl Statement Grammar
+
acl Statement Definition and + Usage
+
controls Statement Grammar
+
controls Statement Definition and + Usage
+
include Statement Grammar
+
include Statement Definition and + Usage
+
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 + Usage
+
options Statement Grammar
+
options Statement Definition and + Usage
+
statistics-channels Statement Grammar
+
statistics-channels Statement Definition and + Usage
+
server Statement Grammar
+
server Statement Definition and + Usage
+
trusted-keys Statement Grammar
+
trusted-keys Statement Definition + and Usage
+
view Statement Grammar
+
view Statement Definition and Usage
+
zone + Statement Grammar
+
zone Statement Definition and Usage
+
+
Zone File
+
+
Types of Resource Records and When to Use Them
+
Discussion of MX Records
+
Setting TTLs
+
Inverse Mapping in IPv4
+
Other Zone File Directives
+
BIND Master File Extension: the $GENERATE Directive
+
Additional File Formats
+
+
BIND9 Statistics
+
Statistics Counters
+
+
+

+ BIND 9 configuration is broadly similar + to BIND 8; however, there are a few new + areas + of configuration, such as views. BIND + 8 configuration files should work with few alterations in BIND + 9, although more complex configurations should be reviewed to check + if they can be more efficiently implemented using the new features + found in BIND 9. +

+

+ BIND 4 configuration files can be + converted to the new format + using the shell script + contrib/named-bootconf/named-bootconf.sh. +

+
+

+Configuration File Elements

+

+ Following is a list of elements used throughout the BIND configuration + file documentation: +

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

+ acl_name +

+ 		+

+ The name of an address_match_list as + defined by the acl statement. +

+
+

+ address_match_list +

+ 		+

+ A list of one or more + ip_addr, + ip_prefix, key_id, + or acl_name elements, see + the section called “Address Match Lists”. +

+
+

+ masters_list +

+ 		+

+ A named list of one or more ip_addr + with optional key_id and/or + ip_port. + A masters_list may include other + masters_lists. +

+
+

+ domain_name +

+ 		+

+ A quoted string which will be used as + a DNS name, for example "my.test.domain". +

+
+

+ dotted_decimal +

+ 		+

+ One to four integers valued 0 through + 255 separated by dots (`.'), such as 123, + 45.67 or 89.123.45.67. +

+
+

+ ip4_addr +

+ 		+

+ An IPv4 address with exactly four elements + in dotted_decimal notation. +

+
+

+ ip6_addr +

+ 		+

+ An IPv6 address, such as 2001:db8::1234. + IPv6 scoped addresses that have ambiguity on their + scope zones must be disambiguated by an appropriate + zone ID with the percent character (`%') as + delimiter. It is strongly recommended to use + string zone names rather than numeric identifiers, + in order to be robust against system configuration + changes. However, since there is no standard + mapping for such names and identifier values, + currently only interface names as link identifiers + are supported, assuming one-to-one mapping between + interfaces and links. For example, a link-local + address fe80::1 on the link + attached to the interface ne0 + can be specified as fe80::1%ne0. + Note that on most systems link-local addresses + always have the ambiguity, and need to be + disambiguated. +

+
+

+ ip_addr +

+ 		+

+ An ip4_addr or ip6_addr. +

+
+

+ ip_port +

+ 		+

+ An IP port number. + The number is limited to 0 + through 65535, with values + below 1024 typically restricted to use by processes running + as root. + In some cases, an asterisk (`*') character can be used as a + placeholder to + select a random high-numbered port. +

+
+

+ ip_prefix +

+ 		+

+ An IP network specified as an ip_addr, + followed by a slash (`/') and then the number of bits in the + netmask. + Trailing zeros in a ip_addr + may omitted. + For example, 127/8 is the + network 127.0.0.0 with + netmask 255.0.0.0 and 1.2.3.0/28 is + network 1.2.3.0 with netmask 255.255.255.240. +

+

+ When specifying a prefix involving a IPv6 scoped address + the scope may be omitted. In that case the prefix will + match packets from any scope. +

+
+

+ key_id +

+ 		+

+ A domain_name representing + the name of a shared key, to be used for transaction + security. +

+
+

+ key_list +

+ 		+

+ A list of one or more + key_ids, + separated by semicolons and ending with a semicolon. +

+
+

+ number +

+ 		+

+ A non-negative 32-bit integer + (i.e., a number between 0 and 4294967295, inclusive). + Its acceptable value might further + be limited by the context in which it is used. +

+
+

+ path_name +

+ 		+

+ A quoted string which will be used as + a pathname, such as zones/master/my.test.domain. +

+
+

+ port_list +

+ 		+

+ A list of an ip_port or a port + range. + A port range is specified in the form of + range followed by + two ip_ports, + port_low and + port_high, which represents + port numbers from port_low through + port_high, inclusive. + port_low must not be larger than + port_high. + For example, + range 1024 65535 represents + ports from 1024 through 65535. + In either case an asterisk (`*') character is not + allowed as a valid ip_port. +

+
+

+ size_spec +

+ 		+

+ A number, the word unlimited, + or the word default. +

+

+ An unlimited size_spec requests unlimited + use, or the maximum available amount. A default size_spec uses + the limit that was in force when the server was started. +

+

+ A number can optionally be + followed by a scaling factor: + K or k + for kilobytes, + M or m + for megabytes, and + G or g for gigabytes, + which scale by 1024, 1024*1024, and 1024*1024*1024 + respectively. +

+

+ The value must be representable as a 64-bit unsigned integer + (0 to 18446744073709551615, inclusive). + Using unlimited is the best + way + to safely set a really large number. +

+
+

+ yes_or_no +

+ 		+

+ Either yes or no. + The words true and false are + also accepted, as are the numbers 1 + and 0. +

+
+

+ dialup_option +

+ 		+

+ One of yes, + no, notify, + notify-passive, refresh or + passive. + When used in a zone, notify-passive, + refresh, and passive + are restricted to slave and stub zones. +

+
+
+

+Address Match Lists

+
+

+Syntax

+
address_match_list = address_match_list_element ;
+  [ address_match_list_element; ... ]
+address_match_list_element = [ ! ] (ip_address [/length] |
+   key key_id | acl_name | { address_match_list } )
+
+
+
+

+Definition and Usage

+

+ Address match lists are primarily used to determine access + control for various server operations. They are also used in + the listen-on and sortlist + statements. The elements which constitute an address match + list can be any of the following: +

+
    +
  • an IP address (IPv4 or IPv6)
    • +
  • an IP prefix (in `/' notation)
    • +
  • + a key ID, as defined by the key + statement +
    • +
  • the name of an address match list defined with + the acl statement +
    • +
  • a nested address match list enclosed in braces
    • +
+

+ Elements can be negated with a leading exclamation mark (`!'), + and the match list names "any", "none", "localhost", and + "localnets" are predefined. More information on those names + can be found in the description of the acl statement. +

+

+ The addition of the key clause made the name of this syntactic + element something of a misnomer, since security keys can be used + to validate access without regard to a host or network address. + Nonetheless, the term "address match list" is still used + throughout the documentation. +

+

+ When a given IP address or prefix is compared to an address + match list, the comparison takes place in approximately O(1) + time. However, key comparisons require that the list of keys + be traversed until a matching key is found, and therefore may + be somewhat slower. +

+

+ The interpretation of a match depends on whether the list is being + used for access control, defining listen-on ports, or in a + sortlist, and whether the element was negated. +

+

+ When used as an access control list, a non-negated match + allows access and a negated match denies access. If + there is no match, access is denied. The clauses + allow-notify, + allow-recursion, + allow-recursion-on, + allow-query, + allow-query-on, + allow-query-cache, + allow-query-cache-on, + allow-transfer, + allow-update, + allow-update-forwarding, and + blackhole all use address match + lists. Similarly, the listen-on option will cause the + server to refuse queries on any of the machine's + addresses which do not match the list. +

+

+ Order of insertion is significant. If more than one element + in an ACL is found to match a given IP address or prefix, + preference will be given to the one that came + first in the ACL definition. + Because of this first-match behavior, an element that + defines a subset of another element in the list should + come before the broader element, regardless of whether + either is negated. For example, in + 1.2.3/24; ! 1.2.3.13; + the 1.2.3.13 element is completely useless because the + algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 + element. Using ! 1.2.3.13; 1.2.3/24 fixes + that problem by having 1.2.3.13 blocked by the negation, but + all other 1.2.3.* hosts fall through. +

+
+
+
+

+Comment Syntax

+

+ The BIND 9 comment syntax allows for + comments to appear + anywhere that whitespace may appear in a BIND configuration + file. To appeal to programmers of all kinds, they can be written + in the C, C++, or shell/perl style. +

+
+

+Syntax

+

+

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

+

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

+

+
# This is a BIND comment as in common UNIX shells and perl
+

+

+
+
+

+Definition and Usage

+

+ Comments may appear anywhere that whitespace may appear in + a BIND configuration file. +

+

+ C-style comments start with the two characters /* (slash, + star) and end with */ (star, slash). Because they are completely + delimited with these characters, they can be used to comment only + a portion of a line or to span multiple lines. +

+

+ C-style comments cannot be nested. For example, the following + is not valid because the entire comment ends with the first */: +

+

+ +

+
/* This is the start of a comment.
+   This is still part of the comment.
+/* This is an incorrect attempt at nesting a comment. */
+   This is no longer in any comment. */
+
+

+ +

+

+ C++-style comments start with the two characters // (slash, + slash) and continue to the end of the physical line. They cannot + be continued across multiple physical lines; to have one logical + comment span multiple lines, each line must use the // pair. +

+

+ For example: +

+

+ +

+
// This is the start of a comment.  The next line
+// is a new comment, even though it is logically
+// part of the previous comment.
+
+

+ +

+

+ Shell-style (or perl-style, if you prefer) comments start + with the character # (number sign) + and continue to the end of the + physical line, as in C++ comments. +

+

+ For example: +

+

+ +

+
# This is the start of a comment.  The next line
+# is a new comment, even though it is logically
+# part of the previous comment.
+
+

+ +

+
+

Warning

+

+ You cannot use the semicolon (`;') character + to start a comment such as you would in a zone file. The + semicolon indicates the end of a configuration + statement. +

+
+
+
+
+
+

+Configuration File Grammar

+

+ A BIND 9 configuration consists of + statements and comments. + Statements end with a semicolon. Statements and comments are the + only elements that can appear without enclosing braces. Many + statements contain a block of sub-statements, which are also + terminated with a semicolon. +

+

+ The following statements are supported: +

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

acl

+ 		+

+ defines a named IP address + matching list, for access control and other uses. +

+
+

controls

+ 		+

+ declares control channels to be used + by the rndc utility. +

+
+

include

+ 		+

+ includes a file. +

+
+

key

+ 		+

+ specifies key information for use in + authentication and authorization using TSIG. +

+
+

logging

+ 		+

+ specifies what the server logs, and where + the log messages are sent. +

+
+

lwres

+ 		+

+ configures named to + also act as a light-weight resolver daemon (lwresd). +

+
+

masters

+ 		+

+ defines a named masters list for + inclusion in stub and slave zone masters clauses. +

+
+

options

+ 		+

+ controls global server configuration + options and sets defaults for other statements. +

+
+

statistics-channels

+ 		+

+ declares communication channels to get access to + named statistics. +

+
+

server

+ 		+

+ sets certain configuration options on + a per-server basis. +

+
+

trusted-keys

+ 		+

+ defines trusted DNSSEC keys. +

+
+

view

+ 		+

+ defines a view. +

+
+

zone

+ 		+

+ defines a zone. +

+
+

+ The logging and + options statements may only occur once + per + configuration. +

+
+

+acl Statement Grammar

+
acl acl-name {
+    address_match_list
+};
+
+
+
+

+acl Statement Definition and + Usage

+

+ The acl statement assigns a symbolic + name to an address match list. It gets its name from a primary + use of address match lists: Access Control Lists (ACLs). +

+

+ Note that an address match list's name must be defined + with acl before it can be used + elsewhere; no forward references are allowed. +

+

+ The following ACLs are built-in: +

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

any

+ 		+

+ Matches all hosts. +

+
+

none

+ 		+

+ Matches no hosts. +

+
+

localhost

+ 		+

+ Matches the IPv4 and IPv6 addresses of all network + interfaces on the system. +

+
+

localnets

+ 		+

+ Matches any host on an IPv4 or IPv6 network + for which the system has an interface. + Some systems do not provide a way to determine the prefix + lengths of + local IPv6 addresses. + In such a case, localnets + only matches the local + IPv6 addresses, just like localhost. +

+
+
+
+

+controls Statement Grammar

+
controls {
+   [ inet ( ip_addr | * ) [ port ip_port ] allow {  address_match_list  }
+                keys { key_list }; ]
+   [ inet ...; ]
+   [ unix path perm number owner number group number keys { key_list }; ]
+   [ unix ...; ]
+};
+
+
+
+

+controls Statement Definition and + Usage

+

+ The controls statement declares control + channels to be used by system administrators to control the + operation of the name server. These control channels are + used by the rndc utility to send + commands to and retrieve non-DNS results from a name server. +

+

+ An inet control channel is a TCP socket + listening at the specified ip_port on the + specified ip_addr, which can be an IPv4 or IPv6 + address. An ip_addr of * (asterisk) is + interpreted as the IPv4 wildcard address; connections will be + accepted on any of the system's IPv4 addresses. + To listen on the IPv6 wildcard address, + use an ip_addr of ::. + If you will only use rndc on the local host, + using the loopback address (127.0.0.1 + or ::1) is recommended for maximum security. +

+

+ If no port is specified, port 953 is used. The asterisk + "*" cannot be used for ip_port. +

+

+ The ability to issue commands over the control channel is + restricted by the allow and + keys clauses. + Connections to the control channel are permitted based on the + address_match_list. This is for simple + IP address based filtering only; any key_id + elements of the address_match_list + are ignored. +

+

+ A unix control channel is a UNIX domain + socket listening at the specified path in the file system. + Access to the socket is specified by the perm, + owner and group clauses. + Note on some platforms (SunOS and Solaris) the permissions + (perm) are applied to the parent directory + as the permissions on the socket itself are ignored. +

+

+ The primary authorization mechanism of the command + channel is the key_list, which + contains a list of key_ids. + Each key_id in the key_list + is authorized to execute commands over the control channel. + See Remote Name Daemon Control application in the section called “Administrative Tools”) + for information about configuring keys in rndc. +

+

+ If no controls statement is present, + named will set up a default + control channel listening on the loopback address 127.0.0.1 + and its IPv6 counterpart ::1. + In this case, and also when the controls statement + is present but does not have a keys clause, + named will attempt to load the command channel key + from the file rndc.key in + /etc (or whatever sysconfdir + was specified as when BIND was built). + To create a rndc.key file, run + rndc-confgen -a. +

+

+ The rndc.key feature was created to + ease the transition of systems from BIND 8, + which did not have digital signatures on its command channel + messages and thus did not have a keys clause. + + It makes it possible to use an existing BIND 8 + configuration file in BIND 9 unchanged, + and still have rndc work the same way + ndc worked in BIND 8, simply by executing the + command rndc-confgen -a after BIND 9 is + installed. +

+

+ Since the rndc.key feature + is only intended to allow the backward-compatible usage of + BIND 8 configuration files, this + feature does not + have a high degree of configurability. You cannot easily change + the key name or the size of the secret, so you should make a + rndc.conf with your own key if you + wish to change + those things. The rndc.key file + also has its + permissions set such that only the owner of the file (the user that + named is running as) can access it. + If you + desire greater flexibility in allowing other users to access + rndc commands, then you need to create + a + rndc.conf file and make it group + readable by a group + that contains the users who should have access. +

+

+ To disable the command channel, use an empty + controls statement: + controls { };. +

+
+
+

+include Statement Grammar

+
include filename;
+
+
+

+include Statement Definition and + Usage

+

+ The include statement inserts the + specified file at the point where the include + statement is encountered. The include + statement facilitates the administration of configuration + files + by permitting the reading or writing of some things but not + others. For example, the statement could include private keys + that are readable only by the name server. +

+
+
+

+key Statement Grammar

+
key key_id {
+    algorithm string;
+    secret string;
+};
+
+
+
+

+key Statement Definition and Usage

+

+ The key statement defines a shared + secret key for use with TSIG (see the section called “TSIG”) + or the command channel + (see the section called “controls Statement Definition and + Usage”). +

+

+ The key statement can occur at the + top level + of the configuration file or inside a view + statement. Keys defined in top-level key + statements can be used in all views. Keys intended for use in + a controls statement + (see the section called “controls Statement Definition and + Usage”) + must be defined at the top level. +

+

+ The key_id, also known as the + key name, is a domain name uniquely identifying the key. It can + be used in a server + statement to cause requests sent to that + server to be signed with this key, or in address match lists to + verify that incoming requests have been signed with a key + matching this name, algorithm, and secret. +

+

+ The algorithm_id is a string + that specifies a security/authentication algorithm. Named + supports hmac-md5, + hmac-sha1, hmac-sha224, + hmac-sha256, hmac-sha384 + and hmac-sha512 TSIG authentication. + Truncated hashes are supported by appending the minimum + number of required bits preceded by a dash, e.g. + hmac-sha1-80. The + secret_string is the secret + to be used by the algorithm, and is treated as a base-64 + encoded string. +

+
+
+

+logging Statement Grammar

+
logging {
+   [ channel channel_name {
+     ( file path_name
+         [ versions ( number | unlimited ) ]
+         [ size size spec ]
+       | syslog syslog_facility
+       | stderr
+       | null );
+     [ severity (critical | error | warning | notice |
+                 info | debug [ level ] | dynamic ); ]
+     [ print-category yes or no; ]
+     [ print-severity yes or no; ]
+     [ print-time yes or no; ]
+   }; ]
+   [ category category_name {
+     channel_name ; [ channel_name ; ... ]
+   }; ]
+   ...
+};
+
+
+
+

+logging Statement Definition and + Usage

+

+ The logging statement configures a + wide + variety of logging options for the name server. Its channel phrase + associates output methods, format options and severity levels with + a name that can then be used with the category phrase + to select how various classes of messages are logged. +

+

+ Only one logging statement is used to + define + as many channels and categories as are wanted. If there is no logging statement, + the logging configuration will be: +

+
logging {
+     category default { default_syslog; default_debug; };
+     category unmatched { null; };
+};
+
+

+ In BIND 9, the logging configuration + is only established when + the entire configuration file has been parsed. In BIND 8, it was + established as soon as the logging + statement + was parsed. When the server is starting up, all logging messages + regarding syntax errors in the configuration file go to the default + channels, or to standard error if the "-g" option + was specified. +

+
+

+The channel Phrase

+

+ All log output goes to one or more channels; + you can make as many of them as you want. +

+

+ Every channel definition must include a destination clause that + says whether messages selected for the channel go to a file, to a + particular syslog facility, to the standard error stream, or are + discarded. It can optionally also limit the message severity level + that will be accepted by the channel (the default is + info), and whether to include a + named-generated time stamp, the + category name + and/or severity level (the default is not to include any). +

+

+ The null destination clause + causes all messages sent to the channel to be discarded; + in that case, other options for the channel are meaningless. +

+

+ The file destination clause directs + the channel + to a disk file. It can include limitations + both on how large the file is allowed to become, and how many + versions + of the file will be saved each time the file is opened. +

+

+ If you use the versions log file + option, then + named will retain that many backup + versions of the file by + renaming them when opening. For example, if you choose to keep + three old versions + of the file lamers.log, then just + before it is opened + lamers.log.1 is renamed to + lamers.log.2, lamers.log.0 is renamed + to lamers.log.1, and lamers.log is + renamed to lamers.log.0. + You can say versions unlimited to + not limit + the number of versions. + If a size option is associated with + the log file, + then renaming is only done when the file being opened exceeds the + indicated size. No backup versions are kept by default; any + existing + log file is simply appended. +

+

+ The size option for files is used + to limit log + growth. If the file ever exceeds the size, then named will + stop writing to the file unless it has a versions option + associated with it. If backup versions are kept, the files are + rolled as + described above and a new one begun. If there is no + versions option, no more data will + be written to the log + until some out-of-band mechanism removes or truncates the log to + less than the + maximum size. The default behavior is not to limit the size of + the + file. +

+

+ Example usage of the size and + versions options: +

+
channel an_example_channel {
+    file "example.log" versions 3 size 20m;
+    print-time yes;
+    print-category yes;
+};
+
+

+ The syslog destination clause + directs the + channel to the system log. Its argument is a + syslog facility as described in the syslog man + page. Known facilities are kern, user, + mail, daemon, auth, + syslog, lpr, news, + uucp, cron, authpriv, + ftp, local0, local1, + local2, local3, local4, + local5, local6 and + local7, however not all facilities + are supported on + all operating systems. + How syslog will handle messages + sent to + this facility is described in the syslog.conf man + page. If you have a system which uses a very old version of syslog that + only uses two arguments to the openlog() function, + then this clause is silently ignored. +

+

+ The severity clause works like syslog's + "priorities", except that they can also be used if you are writing + straight to a file rather than using syslog. + Messages which are not at least of the severity level given will + not be selected for the channel; messages of higher severity + levels + will be accepted. +

+

+ If you are using syslog, then the syslog.conf priorities + will also determine what eventually passes through. For example, + defining a channel facility and severity as daemon and debug but + only logging daemon.warning via syslog.conf will + cause messages of severity info and + notice to + be dropped. If the situation were reversed, with named writing + messages of only warning or higher, + then syslogd would + print all messages it received from the channel. +

+

+ The stderr destination clause + directs the + channel to the server's standard error stream. This is intended + for + use when the server is running as a foreground process, for + example + when debugging a configuration. +

+

+ The server can supply extensive debugging information when + it is in debugging mode. If the server's global debug level is + greater + than zero, then debugging mode will be active. The global debug + level is set either by starting the named server + with the -d flag followed by a positive integer, + or by running rndc trace. + The global debug level + can be set to zero, and debugging mode turned off, by running rndc +notrace. All debugging messages in the server have a debug + level, and higher debug levels give more detailed output. Channels + that specify a specific debug severity, for example: +

+
channel specific_debug_level {
+    file "foo";
+    severity debug 3;
+};
+
+

+ will get debugging output of level 3 or less any time the + server is in debugging mode, regardless of the global debugging + level. Channels with dynamic + severity use the + server's global debug level to determine what messages to print. +

+

+ If print-time has been turned on, + then + the date and time will be logged. print-time may + be specified for a syslog channel, + but is usually + pointless since syslog also prints + the date and + time. If print-category is + requested, then the + category of the message will be logged as well. Finally, if print-severity is + on, then the severity level of the message will be logged. The print- options may + be used in any combination, and will always be printed in the + following + order: time, category, severity. Here is an example where all + three print- options + are on: +

+

+ 28-Feb-2000 15:05:32.863 general: notice: running +

+

+ There are four predefined channels that are used for + named's default logging as follows. + How they are + used is described in the section called “The category Phrase”. +

+
channel default_syslog {
+    syslog daemon;                      // send to syslog's daemon
+                                        // facility
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel default_debug {
+    file "named.run";                   // write to named.run in
+                                        // the working directory
+                                        // Note: stderr is used instead
+                                        // of "named.run"
+                                        // if the server is started
+                                        // with the '-f' option.
+    severity dynamic;                   // log at the server's
+                                        // current debug level
+};
+
+channel default_stderr {
+    stderr;                             // writes to stderr
+    severity info;                      // only send priority info
+                                        // and higher
+};
+
+channel null {
+   null;                                // toss anything sent to
+                                        // this channel
+};
+
+

+ The default_debug channel has the + special + property that it only produces output when the server's debug + level is + nonzero. It normally writes to a file called named.run + in the server's working directory. +

+

+ For security reasons, when the "-u" + command line option is used, the named.run file + is created only after named has + changed to the + new UID, and any debug output generated while named is + starting up and still running as root is discarded. If you need + to capture this output, you must run the server with the "-g" + option and redirect standard error to a file. +

+

+ Once a channel is defined, it cannot be redefined. Thus you + cannot alter the built-in channels directly, but you can modify + the default logging by pointing categories at channels you have + defined. +

+
+
+

+The category Phrase

+

+ There are many categories, so you can send the logs you want + to see wherever you want, without seeing logs you don't want. If + you don't specify a list of channels for a category, then log + messages + in that category will be sent to the default category + instead. If you don't specify a default category, the following + "default default" is used: +

+
category default { default_syslog; default_debug; };
+
+

+ As an example, let's say you want to log security events to + a file, but you also want keep the default logging behavior. You'd + specify the following: +

+
channel my_security_channel {
+    file "my_security_file";
+    severity info;
+};
+category security {
+    my_security_channel;
+    default_syslog;
+    default_debug;
+};
+

+ To discard all messages in a category, specify the null channel: +

+
category xfer-out { null; };
+category notify { null; };
+
+

+ Following are the available categories and brief descriptions + of the types of log information they contain. More + categories may be added in future BIND releases. +

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

default

+ 		+

+ The default category defines the logging + options for those categories where no specific + configuration has been + defined. +

+
+

general

+ 		+

+ The catch-all. Many things still aren't + classified into categories, and they all end up here. +

+
+

database

+ 		+

+ Messages relating to the databases used + internally by the name server to store zone and cache + data. +

+
+

security

+ 		+

+ Approval and denial of requests. +

+
+

config

+ 		+

+ Configuration file parsing and processing. +

+
+

resolver

+ 		+

+ DNS resolution, such as the recursive + lookups performed on behalf of clients by a caching name + server. +

+
+

xfer-in

+ 		+

+ Zone transfers the server is receiving. +

+
+

xfer-out

+ 		+

+ Zone transfers the server is sending. +

+
+

notify

+ 		+

+ The NOTIFY protocol. +

+
+

client

+ 		+

+ Processing of client requests. +

+
+

unmatched

+ 		+

+ 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 + default it is sent to + the null channel. +

+
+

network

+ 		+

+ Network operations. +

+
+

update

+ 		+

+ Dynamic updates. +

+
+

update-security

+ 		+

+ Approval and denial of update requests. +

+
+

queries

+ 		+

+ Specify where queries should be logged to. +

+

+ At startup, specifying the category queries will also + enable query logging unless querylog option has been + specified. +

+ +

+ The query log entry reports the client's IP + address and port number, and the query name, + class and type. It also reports whether the + Recursion Desired flag was set (+ if set, - + if not set), if the query was signed (S), + EDNS was in use (E), if DO (DNSSEC Ok) was + set (D), or if CD (Checking Disabled) was set + (C). +

+ +

+ client 127.0.0.1#62536: query: www.example.com IN AAAA +SE +

+

+ client ::1#62537: query: www.example.net IN AAAA -SE +

+
+

dispatch

+ 		+

+ Dispatching of incoming packets to the + server modules where they are to be processed. +

+
+

dnssec

+ 		+

+ DNSSEC and TSIG protocol processing. +

+
+

lame-servers

+ 		+

+ Lame servers. These are misconfigurations + in remote servers, discovered by BIND 9 when trying to + query + those servers during resolution. +

+
+

delegation-only

+ 		+

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

+
+

edns-disabled

+ 		+

+ Log queries that have been forced to use plain + DNS due to timeouts. This is often due to + the remote servers not being RFC 1034 compliant + (not always returning FORMERR or similar to + EDNS queries and other extensions to the DNS + when they are not understood). In other words, this is + targeted at servers that fail to respond to + DNS queries that they don't understand. +

+

+ Note: the log message can also be due to + packet loss. Before reporting servers for + non-RFC 1034 compliance they should be re-tested + to determine the nature of the non-compliance. + This testing should prevent or reduce the + number of false-positive reports. +

+

+ Note: eventually named will have to stop + treating such timeouts as due to RFC 1034 non + compliance and start treating it as plain + packet loss. Falsely classifying packet + loss as due to RFC 1034 non compliance impacts + on DNSSEC validation which requires EDNS for + the DNSSEC records to be returned. +

+
+
+
+
+

+lwres Statement Grammar

+

+ This is the grammar of the lwres + statement in the named.conf file: +

+
lwres {
+    [ listen-on { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ view view_name; ]
+    [ search { domain_name ; [ domain_name ; ... ] }; ]
+    [ ndots number; ]
+};
+
+
+
+

+lwres Statement Definition and Usage

+

+ The lwres statement configures the + name + server to also act as a lightweight resolver server. (See + the section called “Running a Resolver Daemon”.) There may be multiple + lwres statements configuring + lightweight resolver servers with different properties. +

+

+ The listen-on statement specifies a + list of + addresses (and ports) that this instance of a lightweight resolver + daemon + should accept requests on. If no port is specified, port 921 is + used. + If this statement is omitted, requests will be accepted on + 127.0.0.1, + port 921. +

+

+ The view statement binds this + instance of a + lightweight resolver daemon to a view in the DNS namespace, so that + the + response will be constructed in the same manner as a normal DNS + query + matching this view. If this statement is omitted, the default view + is + used, and if there is no default view, an error is triggered. +

+

+ The search statement is equivalent to + the + search statement in + /etc/resolv.conf. It provides a + list of domains + which are appended to relative names in queries. +

+

+ The ndots statement is equivalent to + the + ndots statement in + /etc/resolv.conf. It indicates the + minimum + number of dots in a relative domain name that should result in an + exact match lookup before search path elements are appended. +

+
+
+

+masters Statement Grammar

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

+masters Statement Definition and + Usage

+

masters + lists allow for a common set of masters to be easily used by + multiple stub and slave zones. +

+
+
+

+options Statement Grammar

+

+ This is the grammar of the options + statement in the named.conf file: +

+
options {
+    [ version version_string; ]
+    [ hostname hostname_string; ]
+    [ server-id server_id_string; ]
+    [ directory path_name; ]
+    [ key-directory path_name; ]
+    [ named-xfer path_name; ]
+    [ tkey-gssapi-credential principal; ]
+    [ tkey-domain domainname; ]
+    [ tkey-dhkey key_name key_tag; ]
+    [ cache-file path_name; ]
+    [ dump-file path_name; ]
+    [ memstatistics yes_or_no; ]
+    [ memstatistics-file path_name; ]
+    [ pid-file path_name; ]
+    [ recursing-file path_name; ]
+    [ statistics-file path_name; ]
+    [ zone-statistics yes_or_no; ]
+    [ auth-nxdomain yes_or_no; ]
+    [ deallocate-on-exit yes_or_no; ]
+    [ dialup dialup_option; ]
+    [ fake-iquery yes_or_no; ]
+    [ fetch-glue yes_or_no; ]
+    [ flush-zones-on-shutdown yes_or_no; ]
+    [ has-old-clients yes_or_no; ]
+    [ host-statistics yes_or_no; ]
+    [ host-statistics-max number; ]
+    [ minimal-responses yes_or_no; ]
+    [ multiple-cnames yes_or_no; ]
+    [ notify yes_or_no | explicit | master-only; ]
+    [ recursion yes_or_no; ]
+    [ 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; ]
+    [ dnssec-must-be-secure domain yes_or_no; ]
+    [ dnssec-accept-expired yes_or_no; ]
+    [ forward ( only | first ); ]
+    [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
+    [ dual-stack-servers [port ip_port] {
+        ( domain_name [port ip_port] |
+          ip_addr [port ip_port] ) ; 
+        ... }; ]
+    [ check-names ( master | slave | response )
+        ( warn | fail | ignore ); ]
+    [ check-mx ( warn | fail | ignore ); ]
+    [ check-wildcard yes_or_no; ]
+    [ check-integrity yes_or_no; ]
+    [ check-mx-cname ( warn | fail | ignore ); ]
+    [ check-srv-cname ( warn | fail | ignore ); ]
+    [ check-sibling yes_or_no; ]
+    [ allow-notify { address_match_list }; ]
+    [ allow-query { address_match_list }; ]
+    [ allow-query-on { address_match_list }; ]
+    [ allow-query-cache { address_match_list }; ]
+    [ allow-query-cache-on { address_match_list }; ]
+    [ allow-transfer { address_match_list }; ]
+    [ allow-recursion { address_match_list }; ]
+    [ allow-recursion-on { address_match_list }; ]
+    [ allow-update { address_match_list }; ]
+    [ allow-update-forwarding { address_match_list }; ]
+    [ update-check-ksk yes_or_no; ]
+    [ try-tcp-refresh yes_or_no; ]
+    [ allow-v6-synthesis { address_match_list }; ]
+    [ blackhole { address_match_list }; ]
+    [ use-v4-udp-ports { port_list }; ]
+    [ avoid-v4-udp-ports { port_list }; ]
+    [ use-v6-udp-ports { port_list }; ]
+    [ avoid-v6-udp-ports { port_list }; ]
+    [ listen-on [ port ip_port ] { address_match_list }; ]
+    [ listen-on-v6 [ port ip_port ] { address_match_list }; ]
+    [ query-source ( ( ip4_addr | * )
+        [ port ( ip_port | * ) ] |
+        [ address ( ip4_addr | * ) ]
+        [ port ( ip_port | * ) ] ) ; ]
+    [ query-source-v6 ( ( ip6_addr | * )
+        [ port ( ip_port | * ) ] | 
+        [ address ( ip6_addr | * ) ] 
+        [ port ( ip_port | * ) ] ) ; ]
+    [ use-queryport-pool yes_or_no; ]
+    [ queryport-pool-ports number; ]
+    [ queryport-pool-interval number; ]
+    [ max-transfer-time-in number; ]
+    [ max-transfer-time-out number; ]
+    [ max-transfer-idle-in number; ]
+    [ max-transfer-idle-out number; ]
+    [ tcp-clients number; ]
+    [ reserved-sockets number; ]
+    [ recursive-clients number; ]
+    [ serial-query-rate number; ]
+    [ serial-queries number; ]
+    [ tcp-listen-queue number; ]
+    [ transfer-format ( one-answer | many-answers ); ]
+    [ transfers-in  number; ]
+    [ transfers-out number; ]
+    [ transfers-per-ns number; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ use-alt-transfer-source yes_or_no; ]
+    [ notify-delay seconds ; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ notify-to-soa yes_or_no ; ]
+    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ max-ixfr-log-size number; ]
+    [ max-journal-size size_spec; ]
+    [ coresize size_spec ; ]
+    [ datasize size_spec ; ]
+    [ files size_spec ; ]
+    [ stacksize size_spec ; ]
+    [ cleaning-interval number; ]
+    [ heartbeat-interval number; ]
+    [ interface-interval number; ]
+    [ statistics-interval number; ]
+    [ topology { address_match_list }];
+    [ sortlist { address_match_list }];
+    [ rrset-order { order_spec ; [ order_spec ; ... ] ] };
+    [ lame-ttl number; ]
+    [ max-ncache-ttl number; ]
+    [ max-cache-ttl number; ]
+    [ sig-validity-interval number ; ]
+    [ sig-signing-nodes number ; ]
+    [ sig-signing-signatures number ; ]
+    [ sig-signing-type number ; ]
+    [ min-roots number; ]
+    [ use-ixfr yes_or_no ; ]
+    [ provide-ixfr yes_or_no; ]
+    [ request-ixfr yes_or_no; ]
+    [ treat-cr-as-space yes_or_no ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ port ip_port; ]
+    [ additional-from-auth yes_or_no ; ]
+    [ additional-from-cache yes_or_no ; ]
+    [ random-device path_name ; ]
+    [ max-cache-size size_spec ; ]
+    [ match-mapped-addresses yes_or_no; ]
+    [ preferred-glue ( A | AAAA | NONE ); ]
+    [ edns-udp-size number; ]
+    [ max-udp-size number; ]
+    [ root-delegation-only [ exclude { namelist } ] ; ]
+    [ querylog yes_or_no ; ]
+    [ disable-algorithms domain { algorithm; [ algorithm; ] }; ]
+    [ acache-enable yes_or_no ; ]
+    [ acache-cleaning-interval number; ]
+    [ max-acache-size size_spec ; ]
+    [ clients-per-query number ; ]
+    [ max-clients-per-query number ; ]
+    [ masterfile-format (text|raw) ; ]
+    [ empty-server name ; ]
+    [ empty-contact name ; ]
+    [ empty-zones-enable yes_or_no ; ]
+    [ disable-empty-zone zone_name ; ]
+    [ zero-no-soa-ttl yes_or_no ; ]
+    [ zero-no-soa-ttl-cache yes_or_no ; ]
+};
+
+
+
+

+options Statement Definition and + Usage

+

+ The options statement sets up global + options + to be used by BIND. This statement + may appear only + once in a configuration file. If there is no options + statement, an options block with each option set to its default will + be used. +

+
+
directory
+

+ The working directory of the server. + Any non-absolute pathnames in the configuration file will be + taken + as relative to this directory. The default location for most + server + output files (e.g. named.run) + is this directory. + If a directory is not specified, the working directory + defaults to `.', the directory from + which the server + was started. The directory specified should be an absolute + path. +

+
key-directory
+

+ When performing dynamic update of secure zones, the + directory where the public and private key files should be + found, + if different than the current working directory. The + directory specified + must be an absolute path. +

+
named-xfer
+

+ This option is obsolete. It + was used in BIND 8 to specify + the pathname to the named-xfer + program. In BIND 9, no separate + named-xfer program is needed; + its functionality is built into the name server. +

+
tkey-gssapi-credential
+

+ The security credential with which the server should + authenticate keys requested by the GSS-TSIG protocol. + Currently only Kerberos 5 authentication is available + and the credential is a Kerberos principal which + the server can acquire through the default system + key file, normally /etc/krb5.keytab. + Normally this principal is of the form + "dns/server.domain". + To use GSS-TSIG, tkey-domain + must also be set. +

+
tkey-domain
+

+ The domain appended to the names of all shared keys + generated with TKEY. When a + client requests a TKEY exchange, + it may or may not specify the desired name for the + key. If present, the name of the shared key will + will be client specified part + + tkey-domain. Otherwise, the + name of the shared key will be random hex + digits + tkey-domain. + In most cases, the domainname + should be the server's domain name, or an otherwise + non-existent subdomain like + "_tkey.domainname". If you are + using GSS-TSIG, this variable must be defined. +

+
tkey-dhkey
+

+ The Diffie-Hellman key used by the server + to generate shared keys with clients using the Diffie-Hellman + mode + of TKEY. The server must be + able to load the + public and private keys from files in the working directory. + In + most cases, the keyname should be the server's host name. +

+
cache-file
+

+ This is for testing only. Do not use. +

+
dump-file
+

+ The pathname of the file the server dumps + the database to when instructed to do so with + rndc dumpdb. + If not specified, the default is named_dump.db. +

+
memstatistics-file
+

+ The pathname of the file the server writes memory + usage statistics to on exit. If not specified, + the default is named.memstats. +

+
pid-file
+

+ The pathname of the file the server writes its process ID + in. If not specified, the default is + /var/run/named/named.pid. + 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 + existing one will be removed. Note that none + is a keyword, not a filename, and therefore is not enclosed + in + double quotes. +

+
recursing-file
+

+ The pathname of the file the server dumps + the queries that are currently recursing when instructed + to do so with rndc recursing. + If not specified, the default is named.recursing. +

+
statistics-file
+

+ The pathname of the file the server appends statistics + to when instructed to do so using rndc stats. + If not specified, the default is named.stats in the + server's current directory. The format of the file is + described + in the section called “The Statistics File”. +

+
port
+

+ The UDP/TCP port number the server uses for + receiving and sending DNS protocol traffic. + The default is 53. This option is mainly intended for server + testing; + a server using a port other than 53 will not be able to + communicate with + the global DNS. +

+
random-device
+

+ The source of entropy to be used by the server. Entropy is + primarily needed + for DNSSEC operations, such as TKEY transactions and dynamic + update of signed + zones. This options specifies the device (or file) from which + to read + entropy. If this is a file, operations requiring entropy will + fail when the + file has been exhausted. If not specified, the default value + is + /dev/random + (or equivalent) when present, and none otherwise. The + random-device option takes + effect during + the initial configuration load at server startup time and + is ignored on subsequent reloads. +

+
preferred-glue
+

+ If specified, the listed type (A or AAAA) will be emitted + before other glue + in the additional section of a query response. + The default is not to prefer any type (NONE). +

+
root-delegation-only
+
+

+ 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"). +

+
+options {
+        root-delegation-only exclude { "de"; "lv"; "us"; "museum"; };
+};
+
+
+
disable-algorithms
+

+ Disable the specified DNSSEC algorithms at and below the + specified name. + Multiple disable-algorithms + statements are allowed. + Only the most specific will be applied. +

+
dnssec-lookaside
+

+ When set, dnssec-lookaside + provides the + validator with an alternate method to validate DNSKEY records + at the + top of a zone. When a DNSKEY is at or below a domain + specified by the + deepest dnssec-lookaside, and + the normal dnssec validation + has left the key untrusted, the trust-anchor will be append to + the key + name and a DLV record will be looked up to see if it can + validate the + key. If the DLV record validates a DNSKEY (similarly to the + way a DS + record does) the DNSKEY RRset is deemed to be trusted. +

+
dnssec-must-be-secure
+

+ Specify hierarchies which must be or may not be secure (signed and + validated). + If yes, then named will only accept + answers if they + are secure. + If no, then normal dnssec validation + applies + allowing for insecure answers to be accepted. + The specified domain must be under a trusted-key or + dnssec-lookaside must be + active. +

+
+
+

+Boolean Options

+
+
auth-nxdomain
+

+ If yes, then the AA bit + is always set on NXDOMAIN responses, even if the server is + not actually + authoritative. The default is no; + this is + a change from BIND 8. If you + are using very old DNS software, you + may need to set it to yes. +

+
deallocate-on-exit
+

+ This option was used in BIND + 8 to enable checking + for memory leaks on exit. BIND 9 ignores the option and always performs + the checks. +

+
memstatistics
+

+ Write memory statistics to the file specified by + memstatistics-file at exit. + The default is no unless + '-m record' is specified on the command line in + which case it is yes. +

+
dialup
+
+

+ If yes, then the + server treats all zones as if they are doing zone transfers + across + a dial-on-demand dialup link, which can be brought up by + traffic + originating from this server. This has different effects + according + to zone type and concentrates the zone maintenance so that + it all + happens in a short interval, once every heartbeat-interval and + hopefully during the one call. It also suppresses some of + the normal + zone maintenance traffic. The default is no. +

+

+ The dialup option + may also be specified in the view and + zone statements, + in which case it overrides the global dialup + option. +

+

+ If the zone is a master zone, then the server will send out a + NOTIFY + request to all the slaves (default). This should trigger the + zone serial + number check in the slave (providing it supports NOTIFY) + allowing the slave + to verify the zone while the connection is active. + The set of servers to which NOTIFY is sent can be controlled + by + notify and also-notify. +

+

+ If the + zone is a slave or stub zone, then the server will suppress + the regular + "zone up to date" (refresh) queries and only perform them + when the + heartbeat-interval expires in + addition to sending + NOTIFY requests. +

+

+ Finer control can be achieved by using + notify which only sends NOTIFY + messages, + notify-passive which sends NOTIFY + messages and + suppresses the normal refresh queries, refresh + which suppresses normal refresh processing and sends refresh + queries + when the heartbeat-interval + expires, and + passive which just disables normal + refresh + processing. +

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

+ dialup mode +

+ 		+

+ normal refresh +

+ 		+

+ heart-beat refresh +

+ 		+

+ heart-beat notify +

+
+

no (default)

+ 		+

+ yes +

+ 		+

+ no +

+ 		+

+ no +

+
+

yes

+ 		+

+ no +

+ 		+

+ yes +

+ 		+

+ yes +

+
+

notify

+ 		+

+ yes +

+ 		+

+ no +

+ 		+

+ yes +

+
+

refresh

+ 		+

+ no +

+ 		+

+ yes +

+ 		+

+ no +

+
+

passive

+ 		+

+ no +

+ 		+

+ no +

+ 		+

+ no +

+
+

notify-passive

+ 		+

+ no +

+ 		+

+ no +

+ 		+

+ yes +

+
+

+ Note that normal NOTIFY processing is not affected by + dialup. +

+
+
fake-iquery
+

+ In BIND 8, this option + enabled simulating the obsolete DNS query type + IQUERY. BIND 9 never does + IQUERY simulation. +

+
fetch-glue
+

+ This option is obsolete. + In BIND 8, fetch-glue yes + caused the server to attempt to fetch glue resource records + it + didn't have when constructing the additional + data section of a response. This is now considered a bad + idea + and BIND 9 never does it. +

+
flush-zones-on-shutdown
+

+ When the nameserver exits due receiving SIGTERM, + flush or do not flush any pending zone writes. The default + is + flush-zones-on-shutdown no. +

+
has-old-clients
+

+ This option was incorrectly implemented + in BIND 8, and is ignored by BIND 9. + To achieve the intended effect + of + has-old-clients yes, specify + the two separate options auth-nxdomain yes + and rfc2308-type1 no instead. +

+
host-statistics
+

+ In BIND 8, this enables keeping of + statistics for every host that the name server interacts + with. + Not implemented in BIND 9. +

+
maintain-ixfr-base
+

+ This option is obsolete. + It was used in BIND 8 to + determine whether a transaction log was + kept for Incremental Zone Transfer. BIND 9 maintains a transaction + log whenever possible. If you need to disable outgoing + incremental zone + transfers, use provide-ixfr no. +

+
minimal-responses
+

+ If yes, then when generating + responses the server will only add records to the authority + and additional data sections when they are required (e.g. + delegations, negative responses). This may improve the + performance of the server. + The default is no. +

+
multiple-cnames
+

+ This option was used in BIND 8 to allow + a domain name to have multiple CNAME records in violation of + the DNS standards. BIND 9.2 onwards + always strictly enforces the CNAME rules both in master + files and dynamic updates. +

+
notify
+
+

+ If yes (the default), + DNS NOTIFY messages are sent when a zone the server is + authoritative for + changes, see the section called “Notify”. The messages are + sent to the + servers listed in the zone's NS records (except the master + server identified + in the SOA MNAME field), and to any servers listed in the + also-notify option. +

+

+ If master-only, notifies are only + sent + for master zones. + If explicit, notifies are sent only + to + servers explicitly listed using also-notify. + If no, no notifies are sent. +

+

+ The notify option may also be + specified in the zone + statement, + in which case it overrides the options notify statement. + It would only be necessary to turn off this option if it + caused slaves + to crash. +

+
+
notify-to-soa
+

+ If yes do not check the nameservers + in the NS RRset against the SOA MNAME. Normally a NOTIFY + message is not sent to the SOA MNAME (SOA ORIGIN) as it is + supposed to contain the name of the ultimate master. + Sometimes, however, a slave is listed as the SOA MNAME in + hidden master configurations and in that case you would + want the ultimate master to still send NOTIFY messages to + all the nameservers listed in the NS RRset. +

+
recursion
+

+ If yes, and a + DNS query requests recursion, then the server will attempt + to do + all the work required to answer the query. If recursion is + off + and the server does not already know the answer, it will + return a + referral response. The default is + yes. + Note that setting recursion no does not prevent + clients from getting data from the server's cache; it only + prevents new data from being cached as an effect of client + queries. + Caching may still occur as an effect the server's internal + operation, such as NOTIFY address lookups. + See also fetch-glue above. +

+
rfc2308-type1
+
+

+ Setting this to yes will + cause the server to send NS records along with the SOA + record for negative + answers. The default is no. +

+
+

Note

+

+ Not yet implemented in BIND + 9. +

+
+
+
use-id-pool
+

+ This option is obsolete. + BIND 9 always allocates query + IDs from a pool. +

+
zone-statistics
+

+ If yes, the server will collect + statistical data on all zones (unless specifically turned + off + on a per-zone basis by specifying zone-statistics no + in the zone statement). + These statistics may be accessed + using rndc stats, which will + dump them to the file listed + in the statistics-file. See + also the section called “The Statistics File”. +

+
use-ixfr
+

+ This option is obsolete. + If you need to disable IXFR to a particular server or + servers, see + the information on the provide-ixfr option + in the section called “server Statement Definition and + Usage”. + See also + the section called “Incremental Zone Transfers (IXFR)”. +

+
provide-ixfr
+

+ See the description of + provide-ixfr in + the section called “server Statement Definition and + Usage”. +

+
request-ixfr
+

+ See the description of + request-ixfr in + the section called “server Statement Definition and + Usage”. +

+
treat-cr-as-space
+

+ This option was used in BIND + 8 to make + the server treat carriage return ("\r") characters the same way + as a space or tab character, + to facilitate loading of zone files on a UNIX system that + were generated + on an NT or DOS machine. In BIND 9, both UNIX "\n" + and NT/DOS "\r\n" newlines + are always accepted, + and the option is ignored. +

+
+additional-from-auth, additional-from-cache +
+
+

+ These options control the behavior of an authoritative + server when + answering queries which have additional data, or when + following CNAME + and DNAME chains. +

+

+ When both of these options are set to yes + (the default) and a + query is being answered from authoritative data (a zone + configured into the server), the additional data section of + the + reply will be filled in using data from other authoritative + zones + and from the cache. In some situations this is undesirable, + such + as when there is concern over the correctness of the cache, + or + in servers where slave zones may be added and modified by + untrusted third parties. Also, avoiding + the search for this additional data will speed up server + operations + at the possible expense of additional queries to resolve + what would + otherwise be provided in the additional section. +

+

+ For example, if a query asks for an MX record for host foo.example.com, + and the record found is "MX 10 mail.example.net", normally the address + records (A and AAAA) for mail.example.net will be provided as well, + if known, even though they are not in the example.com zone. + Setting these options to no + disables this behavior and makes + the server only search for additional data in the zone it + answers from. +

+

+ These options are intended for use in authoritative-only + servers, or in authoritative-only views. Attempts to set + them to no without also + specifying + recursion no will cause the + server to + ignore the options and log a warning message. +

+

+ Specifying additional-from-cache no actually + disables the use of the cache not only for additional data + lookups + but also when looking up the answer. This is usually the + desired + behavior in an authoritative-only server where the + correctness of + the cached data is an issue. +

+

+ When a name server is non-recursively queried for a name + that is not + below the apex of any served zone, it normally answers with + an + "upwards referral" to the root servers or the servers of + some other + known parent of the query name. Since the data in an + upwards referral + comes from the cache, the server will not be able to provide + upwards + referrals when additional-from-cache no + has been specified. Instead, it will respond to such + queries + with REFUSED. This should not cause any problems since + upwards referrals are not required for the resolution + process. +

+
+
match-mapped-addresses
+

+ If yes, then an + IPv4-mapped IPv6 address will match any address match + list entries that match the corresponding IPv4 address. + Enabling this option is sometimes useful on IPv6-enabled + Linux + systems, to work around a kernel quirk that causes IPv4 + TCP connections such as zone transfers to be accepted + on an IPv6 socket using mapped addresses, causing + address match lists designed for IPv4 to fail to match. + The use of this option for any other purpose is discouraged. +

+
ixfr-from-differences
+
+

+ When yes and the server loads a new version of a master + zone from its zone file or receives a new version of a slave + file by a non-incremental zone transfer, it will compare + the new version to the previous one and calculate a set + of differences. The differences are then logged in the + zone's journal file such that the changes can be transmitted + to downstream slaves as an incremental zone transfer. +

+

+ By allowing incremental zone transfers to be used for + non-dynamic zones, this option saves bandwidth at the + expense of increased CPU and memory consumption at the + master. + In particular, if the new version of a zone is completely + different from the previous one, the set of differences + will be of a size comparable to the combined size of the + old and new zone version, and the server will need to + temporarily allocate memory to hold this complete + difference set. +

+

ixfr-from-differences + also accepts master and + slave at the view and options + levels which causes + 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 + not log + 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. + The default is yes. +

+
dnssec-validation
+

+ Enable DNSSEC validation in named. + Note dnssec-enable also needs to be + set to yes to be effective. + The default is yes. +

+
dnssec-accept-expired
+

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

+
querylog
+

+ Specify whether query logging should be started when named + starts. + If querylog is not specified, + then the query logging + is determined by the presence of the logging category queries. +

+
check-names
+
+

+ This option is used to restrict the character set and syntax + of + certain domain names in master files and/or DNS responses + received + from the network. The default varies according to usage + area. For + master zones the default is fail. + For slave zones the default + is warn. + For answers received from the network (response) + the default is ignore. +

+

+ The rules for legal hostnames and mail domains are derived + from RFC 952 and RFC 821 as modified by RFC 1123. +

+

check-names + applies to the owner names of A, AAAA and MX records. + It also applies to the domain names in the RDATA of NS, SOA + and MX records. + It also applies to the RDATA of PTR records where the owner + name indicated that it is a reverse lookup of a hostname + (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT). +

+
+
check-mx
+

+ Check whether the MX record appears to refer to a IP address. + The default is to warn. Other possible + values are fail and + ignore. +

+
check-wildcard
+

+ This option is used to check for non-terminal wildcards. + The use of non-terminal wildcards is almost always as a + result of a failure + to understand the wildcard matching algorithm (RFC 1034). + This option + affects master zones. The default (yes) is to check + for non-terminal wildcards and issue a warning. +

+
check-integrity
+

+ Perform post load zone integrity checks on master + zones. This checks that MX and SRV records refer + to address (A or AAAA) records and that glue + address records exist for delegated zones. For + MX and SRV records only in-zone hostnames are + checked (for out-of-zone hostnames use + named-checkzone). + For NS records only names below top of zone are + checked (for out-of-zone names and glue consistency + checks use named-checkzone). + The default is yes. +

+
check-mx-cname
+

+ If check-integrity is set then + fail, warn or ignore MX records that refer + to CNAMES. The default is to warn. +

+
check-srv-cname
+

+ If check-integrity is set then + fail, warn or ignore SRV records that refer + to CNAMES. The default is to warn. +

+
check-sibling
+

+ When performing integrity checks, also check that + sibling glue exists. The default is yes. +

+
zero-no-soa-ttl
+

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

+
zero-no-soa-ttl-cache
+

+ When caching a negative response to a SOA query + set the TTL to zero. + The default is no. +

+
update-check-ksk
+

+ When regenerating the RRSIGs following a UPDATE + request to a secure zone, check the KSK flag on + the DNSKEY RR to determine if this key should be + used to generate the RRSIG. This flag is ignored + if there are not DNSKEY RRs both with and without + a KSK. + The default is yes. +

+
try-tcp-refresh
+

+ Try to refresh the zone using TCP if UDP queries fail. + For BIND 8 compatibility, the default is + yes. +

+
+
+
+

+Forwarding

+

+ The forwarding facility can be used to create a large site-wide + cache on a few servers, reducing traffic over links to external + name servers. It can also be used to allow queries by servers that + do not have direct access to the Internet, but wish to look up + exterior + names anyway. Forwarding occurs only on those queries for which + the server is not authoritative and does not have the answer in + its cache. +

+
+
forward
+

+ This option is only meaningful if the + forwarders list is not empty. A value of first, + the default, causes the server to query the forwarders + first — and + if that doesn't answer the question, the server will then + look for + the answer itself. If only is + specified, the + server will only query the forwarders. +

+
forwarders
+

+ Specifies the IP addresses to be used + for forwarding. The default is the empty list (no + forwarding). +

+
+

+ Forwarding can also be configured on a per-domain basis, allowing + for the global forwarding options to be overridden in a variety + of ways. You can set particular domains to use different + forwarders, + or have a different forward only/first behavior, + or not forward at all, see the section called “zone + Statement Grammar”. +

+
+
+

+Dual-stack Servers

+

+ Dual-stack servers are used as servers of last resort to work + around + problems in reachability due the lack of support for either IPv4 + or IPv6 + on the host machine. +

+
+
dual-stack-servers
+

+ Specifies host names or addresses of machines with access to + both IPv4 and IPv6 transports. If a hostname is used, the + server must be able + to resolve the name using only the transport it has. If the + machine is dual + stacked, then the dual-stack-servers have no effect unless + access to a transport has been disabled on the command line + (e.g. named -4). +

+
+
+
+

+Access Control

+

+ Access to the server can be restricted based on the IP address + of the requesting system. See the section called “Address Match Lists” for + details on how to specify IP address lists. +

+
+
allow-notify
+

+ Specifies which hosts are allowed to + notify this server, a slave, of zone changes in addition + to the zone masters. + allow-notify may also be + specified in the + zone statement, in which case + it overrides the + options allow-notify + statement. It is only meaningful + for a slave zone. If not specified, the default is to + process notify messages + only from a zone's master. +

+
allow-query
+
+

+ Specifies which hosts are allowed to ask ordinary + DNS questions. allow-query may + also be specified in the zone + statement, in which case it overrides the + options allow-query statement. + If not specified, the default is to allow queries + from all hosts. +

+
+

Note

+

+ allow-query-cache is now + used to specify access to the cache. +

+
+
+
allow-query-on
+
+

+ Specifies which local addresses can accept ordinary + DNS questions. This makes it possible, for instance, + to allow queries on internal-facing interfaces but + disallow them on external-facing ones, without + necessarily knowing the internal network's addresses. +

+

+ allow-query-on may + also be specified in the zone + statement, in which case it overrides the + options allow-query-on statement. +

+

+ If not specified, the default is to allow queries + on all addresses. +

+
+

Note

+

+ allow-query-cache is + used to specify access to the cache. +

+
+
+
allow-query-cache
+

+ Specifies which hosts are allowed to get answers + 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; + localhost;) is used. +

+
allow-query-cache-on
+

+ Specifies which local addresses can give answers + from the cache. If not specified, the default is + to allow cache queries on any address, + localnets and + localhost. +

+
allow-recursion
+

+ Specifies which hosts are allowed to make recursive + queries through this server. If + allow-recursion is not set + then allow-query-cache is + used if set, otherwise allow-query + is used if set, otherwise the default + (localnets; + localhost;) is used. +

+
allow-recursion-on
+

+ Specifies which local addresses can accept recursive + queries. If not specified, the default is to allow + recursive queries on all addresses. +

+
allow-update
+

+ Specifies which hosts are allowed to + submit Dynamic DNS updates for master zones. The default is + to deny + updates from all hosts. Note that allowing updates based + on the requestor's IP address is insecure; see + the section called “Dynamic Update Security” for details. +

+
allow-update-forwarding
+
+

+ Specifies which hosts are allowed to + submit Dynamic DNS updates to slave zones to be forwarded to + the + master. The default is { none; }, + which + means that no update forwarding will be performed. To + enable + update forwarding, specify + allow-update-forwarding { any; };. + Specifying values other than { none; } or + { any; } is usually + counterproductive, since + the responsibility for update access control should rest + with the + master server, not the slaves. +

+

+ Note that enabling the update forwarding feature on a slave + server + may expose master servers relying on insecure IP address + based + access control to attacks; see the section called “Dynamic Update Security” + for more details. +

+
+
allow-v6-synthesis
+

+ This option was introduced for the smooth transition from + AAAA + to A6 and from "nibble labels" to binary labels. + However, since both A6 and binary labels were then + deprecated, + this option was also deprecated. + It is now ignored with some warning messages. +

+
allow-transfer
+

+ Specifies which hosts are allowed to + receive zone transfers from the server. allow-transfer may + also be specified in the zone + statement, in which + case it overrides the options allow-transfer statement. + If not specified, the default is to allow transfers to all + hosts. +

+
blackhole
+

+ Specifies a list of addresses that the + server will not accept queries from or use to resolve a + query. Queries + from these addresses will not be responded to. The default + is none. +

+
+
+
+

+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. + The server will listen on all interfaces allowed by the address + match list. If a port is not specified, port 53 will be used. +

+

+ Multiple listen-on statements are + allowed. + For example, +

+
listen-on { 5.6.7.8; };
+listen-on port 1234 { !1.2.3.4; 1.2/16; };
+
+

+ will enable the name server on port 53 for the IP address + 5.6.7.8, and on port 1234 of an address on the machine in net + 1.2 that is not 1.2.3.4. +

+

+ If no listen-on is specified, the + server will listen on port 53 on all IPv4 interfaces. +

+

+ The listen-on-v6 option is used to + specify the interfaces and the ports on which the server will + listen + for incoming queries sent using IPv6. +

+

+ When

+
{ any; }
+

is + specified + as the address_match_list for the + listen-on-v6 option, + the server does not bind a separate socket to each IPv6 interface + address as it does for IPv4 if the operating system has enough API + support for IPv6 (specifically if it conforms to RFC 3493 and RFC + 3542). + Instead, it listens on the IPv6 wildcard address. + If the system only has incomplete API support for IPv6, however, + the behavior is the same as that for IPv4. +

+

+ A list of particular IPv6 addresses can also be specified, in + which case + the server listens on a separate socket for each specified + address, + regardless of whether the desired API is supported by the system. +

+

+ Multiple listen-on-v6 options can + be used. + For example, +

+
listen-on-v6 { any; };
+listen-on-v6 port 1234 { !2001:db8::/32; any; };
+
+

+ will enable the name server on port 53 for any IPv6 addresses + (with a single wildcard socket), + and on port 1234 of IPv6 addresses that is not in the prefix + 2001:db8::/32 (with separate sockets for each matched address.) +

+

+ To make the server not listen on any IPv6 address, use +

+
listen-on-v6 { none; };
+
+

+ If no listen-on-v6 option is + specified, the server will not listen on any IPv6 address + unless -6 is specified when named is + invoked. If -6 is specified then + named will listen on port 53 on all IPv6 interfaces by default. +

+
+
+

+Query Address

+

+ If the server doesn't know the answer to a question, it will + query other name servers. query-source specifies + the address and port used for such queries. For queries sent over + IPv6, there is a separate query-source-v6 option. + If address is * (asterisk) or is omitted, + a wildcard IP address (INADDR_ANY) + will be used. +

+

+ If port is * or is omitted, + a random port number from a pre-configured + range is picked up and will be used for each query. + The port range(s) is that specified in + the use-v4-udp-ports (for IPv4) + and use-v6-udp-ports (for IPv6) + options, excluding the ranges specified in + the avoid-v4-udp-ports + and avoid-v6-udp-ports options, respectively. +

+

+ The defaults of the query-source and + query-source-v6 options + are: +

+
query-source address * port *;
+query-source-v6 address * port *;
+
+

+ If use-v4-udp-ports or + use-v6-udp-ports is unspecified, + named will check if the operating + system provides a programming interface to retrieve the + system's default range for ephemeral ports. + If such an interface is available, + named will use the corresponding system + default range; otherwise, it will use its own defaults: +

+
use-v4-udp-ports { range 1024 65535; };
+use-v6-udp-ports { range 1024 65535; };
+
+

+ Note: make sure the ranges be sufficiently large for + security. A desirable size depends on various parameters, + but we generally recommend it contain at least 16384 ports + (14 bits of entropy). + Note also that the system's default range when used may be + too small for this purpose, and that the range may even be + changed while named is running; the new + range will automatically be applied when named + is reloaded. + It is encouraged to + configure use-v4-udp-ports and + use-v6-udp-ports explicitly so that the + ranges are sufficiently large and are reasonably + independent from the ranges used by other applications. +

+

+ Note: the operational configuration + where named runs may prohibit the use + of some ports. For example, UNIX systems will not allow + named running without a root privilege + to use ports less than 1024. + If such ports are included in the specified (or detected) + set of query ports, the corresponding query attempts will + fail, resulting in resolution failures or delay. + It is therefore important to configure the set of ports + that can be safely used in the expected operational environment. +

+

+ The defaults of the avoid-v4-udp-ports and + avoid-v6-udp-ports options + are: +

+
avoid-v4-udp-ports {};
+avoid-v6-udp-ports {};
+
+

+ Note: BIND 9.5.0 introduced + the use-queryport-pool + option to support a pool of such random ports, but this + option is now obsolete because reusing the same ports in + the pool may not be sufficiently secure. + For the same reason, it is generally strongly discouraged to + specify a particular port for the + query-source or + query-source-v6 options; + it implicitly disables the use of randomized port numbers. +

+
+
use-queryport-pool
+

+ This option is obsolete. +

+
queryport-pool-ports
+

+ This option is obsolete. +

+
queryport-pool-updateinterval
+

+ This option is obsolete. +

+
+
+

Note

+

+ The address specified in the query-source option + is used for both UDP and TCP queries, but the port applies only + to UDP queries. TCP queries always use a random + unprivileged port. +

+
+
+

Note

+

+ Solaris 2.5.1 and earlier does not support setting the source + address for TCP sockets. +

+
+
+

Note

+

+ See also transfer-source and + notify-source. +

+
+
+
+

+Zone Transfers

+

+ BIND has mechanisms in place to + facilitate zone transfers + and set limits on the amount of load that transfers place on the + system. The following options apply to zone transfers. +

+
+
also-notify
+

+ Defines a global list of IP addresses of name servers + that are also sent NOTIFY messages whenever a fresh copy of + the + zone is loaded, in addition to the servers listed in the + zone's NS records. + This helps to ensure that copies of the zones will + quickly converge on stealth servers. If an also-notify list + is given in a zone statement, + it will override + the options also-notify + statement. When a zone notify + statement + is set to no, the IP + addresses in the global also-notify list will + not be sent NOTIFY messages for that zone. The default is + the empty + list (no global notification list). +

+
max-transfer-time-in
+

+ Inbound zone transfers running longer than + this many minutes will be terminated. The default is 120 + minutes + (2 hours). The maximum value is 28 days (40320 minutes). +

+
max-transfer-idle-in
+

+ Inbound zone transfers making no progress + in this many minutes will be terminated. The default is 60 + minutes + (1 hour). The maximum value is 28 days (40320 minutes). +

+
max-transfer-time-out
+

+ Outbound zone transfers running longer than + this many minutes will be terminated. The default is 120 + minutes + (2 hours). The maximum value is 28 days (40320 minutes). +

+
max-transfer-idle-out
+

+ Outbound zone transfers making no progress + in this many minutes will be terminated. The default is 60 + minutes (1 + hour). The maximum value is 28 days (40320 minutes). +

+
serial-query-rate
+

+ Slave servers will periodically query master servers + to find out if zone serial numbers have changed. Each such + query uses + a minute amount of the slave server's network bandwidth. To + limit the + amount of bandwidth used, BIND 9 limits the rate at which + queries are + sent. The value of the serial-query-rate option, + an integer, is the maximum number of queries sent per + second. + The default is 20. +

+
serial-queries
+

+ In BIND 8, the serial-queries + option + set the maximum number of concurrent serial number queries + allowed to be outstanding at any given time. + BIND 9 does not limit the number of outstanding + serial queries and ignores the serial-queries option. + Instead, it limits the rate at which the queries are sent + as defined using the serial-query-rate option. +

+
transfer-format
+

+ Zone transfers can be sent using two different formats, + one-answer and + many-answers. + The transfer-format option is used + on the master server to determine which format it sends. + one-answer uses one DNS message per + resource record transferred. + many-answers packs as many resource + records as possible into a message. + many-answers is more efficient, but is + only supported by relatively new slave servers, + such as BIND 9, BIND + 8.x and BIND 4.9.5 onwards. + The many-answers format is also supported by + recent Microsoft Windows nameservers. + The default is many-answers. + transfer-format may be overridden on a + per-server basis by using the server + statement. +

+
transfers-in
+

+ The maximum number of inbound zone transfers + that can be running concurrently. The default value is 10. + Increasing transfers-in may + speed up the convergence + of slave zones, but it also may increase the load on the + local system. +

+
transfers-out
+

+ The maximum number of outbound zone transfers + that can be running concurrently. Zone transfer requests in + excess + of the limit will be refused. The default value is 10. +

+
transfers-per-ns
+

+ The maximum number of inbound zone transfers + that can be concurrently transferring from a given remote + name server. + The default value is 2. + Increasing transfers-per-ns + may + speed up the convergence of slave zones, but it also may + increase + the load on the remote name server. transfers-per-ns may + be overridden on a per-server basis by using the transfers phrase + of the server statement. +

+
transfer-source
+
+

transfer-source + determines which local address will be bound to IPv4 + TCP connections used to fetch zones transferred + inbound by the server. It also determines the + source IPv4 address, and optionally the UDP port, + used for the refresh queries and forwarded dynamic + updates. If not set, it defaults to a system + controlled value which will usually be the address + of the interface "closest to" the remote end. This + address must appear in the remote end's + allow-transfer option for the + zone being transferred, if one is specified. This + statement sets the + transfer-source for all zones, + but can be overridden on a per-view or per-zone + basis by including a + transfer-source statement within + the view or + zone block in the configuration + file. +

+
+

Note

+

+ Solaris 2.5.1 and earlier does not support setting the + source address for TCP sockets. +

+
+
+
transfer-source-v6
+

+ The same as transfer-source, + except zone transfers are performed using IPv6. +

+
alt-transfer-source
+
+

+ An alternate transfer source if the one listed in + transfer-source fails and + use-alt-transfer-source is + set. +

+
+

Note

+ If you do not wish the alternate transfer source + 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 + query. +
+
+
alt-transfer-source-v6
+

+ An alternate transfer source if the one listed in + transfer-source-v6 fails and + use-alt-transfer-source is + set. +

+
use-alt-transfer-source
+

+ Use the alternate transfer sources or not. If views are + specified this defaults to no + otherwise it defaults to + yes (for BIND 8 + compatibility). +

+
notify-source
+
+

notify-source + determines which local source address, and + optionally UDP port, will be used to send NOTIFY + messages. This address must appear in the slave + server's masters zone clause or + in an allow-notify clause. This + statement sets the notify-source + for all zones, but can be overridden on a per-zone or + per-view basis by including a + notify-source statement within + the zone or + view block in the configuration + file. +

+
+

Note

+

+ Solaris 2.5.1 and earlier does not support setting the + source address for TCP sockets. +

+
+
+
notify-source-v6
+

+ Like notify-source, + but applies to notify messages sent to IPv6 addresses. +

+
+
+
+

+UDP Port Lists

+

+ use-v4-udp-ports, + avoid-v4-udp-ports, + use-v6-udp-ports, and + avoid-v6-udp-ports + specify a list of IPv4 and IPv6 UDP ports that will be + used or not used as source ports for UDP messages. + See the section called “Query Address” about how the + available ports are determined. + For example, with the following configuration +

+
+use-v6-udp-ports { range 32768 65535; };
+avoid-v6-udp-ports { 40000; range 50000 60000; };
+
+

+ UDP ports of IPv6 messages sent + from named will be in one + of the following ranges: 32768 to 39999, 40001 to 49999, + and 60001 to 65535. +

+

+ avoid-v4-udp-ports and + avoid-v6-udp-ports can be used + to prevent named from choosing as its random source port a + port that is blocked by your firewall or a port that is + used by other applications; + if a query went out with a source port blocked by a + firewall, the + answer would not get by the firewall and the name server would + have to query again. + Note: the desired range can also be represented only with + use-v4-udp-ports and + use-v6-udp-ports, and the + avoid- options are redundant in that + sense; they are provided for backward compatibility and + to possibly simplify the port specification. +

+
+
+

+Operating System Resource Limits

+

+ The server's usage of many system resources can be limited. + Scaled values are allowed when specifying resource limits. For + example, 1G can be used instead of + 1073741824 to specify a limit of + one + gigabyte. unlimited requests + unlimited use, or the + maximum available amount. default + uses the limit + that was in force when the server was started. See the description + of size_spec in the section called “Configuration File Elements”. +

+

+ The following options set operating system resource limits for + the name server process. Some operating systems don't support + some or + any of the limits. On such systems, a warning will be issued if + the + unsupported limit is used. +

+
+
coresize
+

+ The maximum size of a core dump. The default + is default. +

+
datasize
+

+ The maximum amount of data memory the server + may use. The default is default. + This is a hard limit on server memory usage. + If the server attempts to allocate memory in excess of this + limit, the allocation will fail, which may in turn leave + the server unable to perform DNS service. Therefore, + this option is rarely useful as a way of limiting the + amount of memory used by the server, but it can be used + to raise an operating system data size limit that is + too small by default. If you wish to limit the amount + of memory used by the server, use the + max-cache-size and + recursive-clients + options instead. +

+
files
+

+ The maximum number of files the server + may have open concurrently. The default is unlimited. +

+
stacksize
+

+ The maximum amount of stack memory the server + may use. The default is default. +

+
+
+
+

+Server Resource Limits

+

+ The following options set limits on the server's + resource consumption that are enforced internally by the + server rather than the operating system. +

+
+
max-ixfr-log-size
+

+ This option is obsolete; it is accepted + and ignored for BIND 8 compatibility. The option + max-journal-size performs a + similar function in BIND 9. +

+
max-journal-size
+

+ Sets a maximum size for each journal file + (see the section called “The journal file”). When the journal file + approaches + the specified size, some of the oldest transactions in the + journal + will be automatically removed. The default is + unlimited. + This may also be set on a per-zone basis. +

+
host-statistics-max
+

+ In BIND 8, specifies the maximum number of host statistics + entries to be kept. + Not implemented in BIND 9. +

+
recursive-clients
+

+ The maximum number of simultaneous recursive lookups + the server will perform on behalf of clients. The default + is + 1000. Because each recursing + client uses a fair + bit of memory, on the order of 20 kilobytes, the value of + the + recursive-clients option may + have to be decreased + on hosts with limited memory. +

+
tcp-clients
+

+ The maximum number of simultaneous client TCP + connections that the server will accept. + The default is 100. +

+
reserved-sockets
+
+

+ 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 + to provide room for outgoing TCP queries and incoming zone + transfers. The default is 512. + The minimum value is 128 and the + maximum value is 128 less than + maxsockets (-S). This option may be removed in the future. +

+

+ This option has little effect on Windows. +

+
+
max-cache-size
+

+ The maximum amount of memory to use for the + server's cache, in bytes. + When the amount of data in the cache + reaches this limit, the server will cause records to expire + prematurely based on an LRU based strategy so that + the limit is not exceeded. + A value of 0 is special, meaning that + records are purged from the cache only when their + TTLs expire. + Another special keyword unlimited + means the maximum value of 32-bit unsigned integers + (0xffffffff), which may not have the same effect as + 0 on machines that support more than 32 bits of + memory space. + Any positive values less than 2MB will be ignored reset + to 2MB. + In a server with multiple views, the limit applies + separately to the cache of each view. + The default is 0. +

+
tcp-listen-queue
+

+ The listen queue depth. The default and minimum is 3. + If the kernel supports the accept filter "dataready" this + also controls how + many TCP connections that will be queued in kernel space + waiting for + some data before being passed to accept. Values less than 3 + will be + silently raised. +

+
+
+
+

+Periodic Task Intervals

+
+
cleaning-interval
+

+ This interval is effectively obsolete. Previously, + the server would remove expired resource records + from the cache every cleaning-interval minutes. + BIND 9 now manages cache + memory in a more sophisticated manner and does not + rely on the periodic cleaning any more. + Specifying this option therefore has no effect on + the server's behavior. +

+
heartbeat-interval
+

+ The server will perform zone maintenance tasks + for all zones marked as dialup whenever this + interval expires. The default is 60 minutes. Reasonable + values are up + to 1 day (1440 minutes). The maximum value is 28 days + (40320 minutes). + If set to 0, no zone maintenance for these zones will occur. +

+
interface-interval
+

+ The server will scan the network interface list + every interface-interval + minutes. The default + is 60 minutes. The maximum value is 28 days (40320 minutes). + If set to 0, interface scanning will only occur when + the configuration file is loaded. After the scan, the + server will + begin listening for queries on any newly discovered + interfaces (provided they are allowed by the + listen-on configuration), and + will + stop listening on interfaces that have gone away. +

+
statistics-interval
+
+

+ Name server statistics will be logged + every statistics-interval + minutes. The default is + 60. The maximum value is 28 days (40320 minutes). + If set to 0, no statistics will be logged. +

+
+

Note

+

+ Not yet implemented in + BIND 9. +

+
+
+
+
+
+

+Topology

+

+ All other things being equal, when the server chooses a name + server + to query from a list of name servers, it prefers the one that is + topologically closest to itself. The topology statement + takes an address_match_list and + interprets it + in a special way. Each top-level list element is assigned a + distance. + Non-negated elements get a distance based on their position in the + list, where the closer the match is to the start of the list, the + shorter the distance is between it and the server. A negated match + will be assigned the maximum distance from the server. If there + is no match, the address will get a distance which is further than + any non-negated list element, and closer than any negated element. + For example, +

+
topology {
+    10/8;
+    !1.2.3/24;
+    { 1.2/16; 3/8; };
+};
+

+ will prefer servers on network 10 the most, followed by hosts + on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the + exception of hosts on network 1.2.3 (netmask 255.255.255.0), which + is preferred least of all. +

+

+ The default topology is +

+
    topology { localhost; localnets; };
+
+
+

Note

+

+ The topology option + is not implemented in BIND 9. +

+
+
+
+

+The sortlist Statement

+

+ The response to a DNS query may consist of multiple resource + records (RRs) forming a resource records set (RRset). + The name server will normally return the + RRs within the RRset in an indeterminate order + (but see the rrset-order + statement in the section called “RRset Ordering”). + The client resolver code should rearrange the RRs as appropriate, + that is, using any addresses on the local net in preference to + other addresses. + However, not all resolvers can do this or are correctly + configured. + When a client is using a local server, the sorting can be performed + in the server, based on the client's address. This only requires + configuring the name servers, not all the clients. +

+

+ The sortlist statement (see below) + takes + an address_match_list and + interprets it even + more specifically than the topology + statement + does (the section called “Topology”). + Each top level statement in the sortlist must + itself be an explicit address_match_list with + one or two elements. The first element (which may be an IP + address, + an IP prefix, an ACL name or a nested address_match_list) + of each top level list is checked against the source address of + the query until a match is found. +

+

+ Once the source address of the query has been matched, if + the top level statement contains only one element, the actual + primitive + element that matched the source address is used to select the + address + in the response to move to the beginning of the response. If the + statement is a list of two elements, then the second element is + treated the same as the address_match_list in + a topology statement. Each top + level element + is assigned a distance and the address in the response with the + minimum + distance is moved to the beginning of the response. +

+

+ In the following example, any queries received from any of + the addresses of the host itself will get responses preferring + addresses + on any of the locally connected networks. Next most preferred are + addresses + on the 192.168.1/24 network, and after that either the + 192.168.2/24 + or + 192.168.3/24 network with no preference shown between these two + networks. Queries received from a host on the 192.168.1/24 network + will prefer other addresses on that network to the 192.168.2/24 + and + 192.168.3/24 networks. Queries received from a host on the + 192.168.4/24 + or the 192.168.5/24 network will only prefer other addresses on + their directly connected networks. +

+
sortlist {
+    { localhost;                                   // IF   the local host
+        { localnets;                               // THEN first fit on the
+            192.168.1/24;                          //   following nets
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.1/24;                                // IF   on class C 192.168.1
+        { 192.168.1/24;                            // THEN use .1, or .2 or .3
+            { 192.168.2/24; 192.168.3/24; }; }; };
+    { 192.168.2/24;                                // IF   on class C 192.168.2
+        { 192.168.2/24;                            // THEN use .2, or .1 or .3
+            { 192.168.1/24; 192.168.3/24; }; }; };
+    { 192.168.3/24;                                // IF   on class C 192.168.3
+        { 192.168.3/24;                            // THEN use .3, or .1 or .2
+            { 192.168.1/24; 192.168.2/24; }; }; };
+    { { 192.168.4/24; 192.168.5/24; };             // if .4 or .5, prefer that net
+    };
+};
+

+ The following example will give reasonable behavior for the + local host and hosts on directly connected networks. It is similar + to the behavior of the address sort in BIND 4.9.x. Responses sent + to queries from the local host will favor any of the directly + connected + networks. Responses sent to queries from any other hosts on a + directly + connected network will prefer addresses on that same network. + Responses + to other queries will not be sorted. +

+
sortlist {
+           { localhost; localnets; };
+           { localnets; };
+};
+
+
+
+

+RRset Ordering

+

+ When multiple records are returned in an answer it may be + useful to configure the order of the records placed into the + response. + The rrset-order statement permits + configuration + of the ordering of the records in a multiple record response. + See also the sortlist statement, + the section called “The sortlist Statement”. +

+

+ An order_spec is defined as + follows: +

+

+ [class class_name] + [type type_name] + [name "domain_name"] + order ordering +

+

+ If no class is specified, the default is ANY. + If no type is specified, the default is ANY. + If no name is specified, the default is "*" (asterisk). +

+

+ The legal values for ordering are: +

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

fixed

+ 		+

+ Records are returned in the order they + are defined in the zone file. +

+
+

random

+ 		+

+ Records are returned in some random order. +

+
+

cyclic

+ 		+

+ Records are returned in a cyclic round-robin order. +

+

+ If BIND is configured with the + "--enable-fixed-rrset" option at compile time, then + the initial ordering of the RRset will match the + one specified in the zone file. +

+
+

+ For example: +

+
rrset-order {
+   class IN type A name "host.example.com" order random;
+   order cyclic;
+};
+
+

+ will cause any responses for type A records in class IN that + have "host.example.com" as a + suffix, to always be returned + in random order. All other records are returned in cyclic order. +

+

+ If multiple rrset-order statements + appear, + they are not combined — the last one applies. +

+
+

Note

+

+ In this release of BIND 9, the + rrset-order statement does not support + "fixed" ordering by default. Fixed ordering can be enabled + at compile time by specifying "--enable-fixed-rrset" on + the "configure" command line. +

+
+
+
+

+Tuning

+
+
lame-ttl
+

+ Sets the number of seconds to cache a + lame server indication. 0 disables caching. (This is + NOT recommended.) + The default is 600 (10 minutes) and the + maximum value is + 1800 (30 minutes). +

+
max-ncache-ttl
+

+ To reduce network traffic and increase performance, + the server stores negative answers. max-ncache-ttl is + used to set a maximum retention time for these answers in + the server + in seconds. The default + max-ncache-ttl is 10800 seconds (3 hours). + max-ncache-ttl cannot exceed + 7 days and will + be silently truncated to 7 days if set to a greater value. +

+
max-cache-ttl
+

+ Sets the maximum time for which the server will + cache ordinary (positive) answers. The default is + one week (7 days). + A value of zero may cause all queries to return + SERVFAIL, because of lost caches of intermediate + RRsets (such as NS and glue AAAA/A records) in the + resolution process. +

+
min-roots
+
+

+ The minimum number of root servers that + is required for a request for the root servers to be + accepted. The default + is 2. +

+
+

Note

+

+ Not implemented in BIND 9. +

+
+
+
sig-validity-interval
+
+

+ Specifies the number of days into the future when + DNSSEC signatures automatically generated as a + result of dynamic updates (the section called “Dynamic Update”) will expire. There + is a optional second field which specifies how + long before expiry that the signatures will be + regenerated. If not specified the signatures will + be regenerated at 1/4 of base interval. The second + field is specified in days if the base interval is + greater than 7 days otherwise it is specified in hours. + The default base interval is 30 days + giving a re-signing interval of 7 1/2 days. The maximum + values are 10 years (3660 days). +

+

+ The signature inception time is unconditionally + set to one hour before the current time to allow + for a limited amount of clock skew. +

+

+ The sig-validity-interval + should be, at least, several multiples of the SOA + expire interval to allow for reasonable interaction + between the various timer and expiry dates. +

+
+
sig-signing-nodes
+

+ Specify the maximum number of nodes to be + examined in each quantum when signing a zone with + a new DNSKEY. The default is + 100. +

+
sig-signing-signatures
+

+ Specify a threshold number of signatures that + will terminate processing a quantum when signing + a zone with a new DNSKEY. The default is + 10. +

+
sig-signing-type
+
+

+ Specify a private RDATA type to be used when generating + key signing records. The default is + 65535. +

+

+ It is expected that this parameter may be removed + in a future version once there is a standard type. +

+
+
+min-refresh-time, max-refresh-time, min-retry-time, max-retry-time +
+
+

+ These options control the server's behavior on refreshing a + zone + (querying for SOA changes) or retrying failed transfers. + Usually the SOA values for the zone are used, but these + values + are set by the master, giving slave server administrators + little + control over their contents. +

+

+ These options allow the administrator to set a minimum and + maximum + refresh and retry time either per-zone, per-view, or + globally. + These options are valid for slave and stub zones, + and clamp the SOA refresh and retry times to the specified + values. +

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

+
max-udp-size
+

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

+
masterfile-format
+

Specifies + the file format of zone files (see + the section called “Additional File Formats”). + The default value is text, which is the + standard textual representation. Files in other formats + than text are typically expected + to be generated by the named-compilezone tool. + Note that when a zone file in a different format than + text is loaded, named + may omit some of the checks which would be performed for a + file in the text format. In particular, + check-names checks do not apply + for the raw format. This means + a zone file in the raw format + must be generated with the same check level as that + specified in the named configuration + file. This statement sets the + masterfile-format for all zones, + but can be overridden on a per-zone or per-view basis + by including a masterfile-format + statement within the zone or + view block in the configuration + file. +

+
+clients-per-query, max-clients-per-query +
+
+

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

+

+ This value should reflect how many queries come in for + a given name in the time it takes to resolve that name. + If the number of queries exceed this value, named will + assume that it is dealing with a non-responsive zone + and will drop additional queries. If it gets a response + after dropping queries, it will raise the estimate. The + estimate will then be lowered in 20 minutes if it has + remained unchanged. +

+

+ If clients-per-query is set to zero, + then there is no limit on the number of clients per query + and no queries will be dropped. +

+

+ If max-clients-per-query is set to zero, + then there is no upper bound other than imposed by + recursive-clients. +

+
+
notify-delay
+

+ The delay, in seconds, between sending sets of notify + messages for a zone. The default is zero. +

+
+
+
+

+Built-in server information zones

+

+ The server provides some helpful diagnostic information + through a number of built-in zones under the + pseudo-top-level-domain bind in the + CHAOS class. These zones are part + of a + built-in view (see the section called “view Statement Grammar”) of + class + CHAOS which is separate from the + default view of + class IN; therefore, any global + server options + such as allow-query do not apply + the these zones. + If you feel the need to disable these zones, use the options + below, or hide the built-in CHAOS + view by + defining an explicit view of class CHAOS + that matches all clients. +

+
+
version
+

+ The version the server should report + via a query of the name version.bind + with type TXT, class CHAOS. + The default is the real version number of this server. + Specifying version none + disables processing of the queries. +

+
hostname
+

+ The hostname the server should report via a query of + the name hostname.bind + with type TXT, class CHAOS. + This defaults to the hostname of the machine hosting the + name server as + found by the gethostname() function. The primary purpose of such queries + is to + identify which of a group of anycast servers is actually + answering your queries. Specifying hostname none; + disables processing of the queries. +

+
server-id
+

+ The ID the server should report when receiving a Name + Server Identifier (NSID) query, or a query of the name + ID.SERVER with type + TXT, class CHAOS. + The primary purpose of such queries is to + 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 + use the hostname as found by the gethostname() function. + The default server-id is none. +

+
+
+
+

+Built-in Empty Zones

+

+ Named has some built-in empty zones (SOA and NS records only). + These are for zones that should normally be answered locally + and which queries should not be sent to the Internet's root + servers. The official servers which cover these namespaces + return NXDOMAIN responses to these queries. In particular, + these cover the reverse namespace for addresses from RFC 1918 and + RFC 3330. They also include the reverse namespace for IPv6 local + address (locally assigned), IPv6 link local addresses, the IPv6 + loopback address and the IPv6 unknown address. +

+

+ 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 create a empty zone in that case. +

+

+ The current list of empty zones is: +

+
    +
  • 0.IN-ADDR.ARPA
    • +
  • 127.IN-ADDR.ARPA
    • +
  • 254.169.IN-ADDR.ARPA
    • +
  • 2.0.192.IN-ADDR.ARPA
    • +
  • 255.255.255.255.IN-ADDR.ARPA
    • +
  • 0.0.0.0.0.0.0.0.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
    • +
  • D.F.IP6.ARPA
    • +
  • 8.E.F.IP6.ARPA
    • +
  • 9.E.F.IP6.ARPA
    • +
  • A.E.F.IP6.ARPA
    • +
  • B.E.F.IP6.ARPA
    • +
+

+

+

+ Empty zones are settable at the view level and only apply to + views of class IN. Disabled empty zones are only inherited + from options if there are no disabled empty zones specified + at the view level. To override the options list of disabled + zones, you can disable the root zone at the view level, for example: +

+
+            disable-empty-zone ".";
+
+

+

+

+ If you are using the address ranges covered here, you should + already have reverse zones covering the addresses you use. + In practice this appears to not be the case with many queries + being made to the infrastructure servers for names in these + spaces. So many in fact that sacrificial servers were needed + to be deployed to channel the query load away from the + infrastructure servers. +

+
+

Note

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

+ Specify what server name will appear in the returned + SOA record for empty zones. If none is specified, then + the zone's name will be used. +

+
empty-contact
+

+ Specify what contact name will appear in the returned + SOA record for empty zones. If none is specified, then + "." will be used. +

+
empty-zones-enable
+

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

+
disable-empty-zone
+

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

+
+
+
+

+Additional Section Caching

+

+ The additional section cache, also called acache, + is an internal cache to improve the response performance of BIND 9. + When additional section caching is enabled, BIND 9 will + cache an internal short-cut to the additional section content for + each answer RR. + Note that acache is an internal caching + mechanism of BIND 9, and is not related to the DNS caching + server function. +

+

+ Additional section caching does not change the + response content (except the RRsets ordering of the additional + section, see below), but can improve the response performance + significantly. + It is particularly effective when BIND 9 acts as an authoritative + server for a zone that has many delegations with many glue RRs. +

+

+ In order to obtain the maximum performance improvement + from additional section caching, setting + additional-from-cache + to no is recommended, since the current + implementation of acache + does not short-cut of additional section information from the + DNS cache data. +

+

+ One obvious disadvantage of acache is + that it requires much more + memory for the internal cached data. + Thus, if the response performance does not matter and memory + consumption is much more critical, the + acache mechanism can be + disabled by setting acache-enable to + no. + It is also possible to specify the upper limit of memory + consumption + for acache by using max-acache-size. +

+

+ Additional section caching also has a minor effect on the + RRset ordering in the additional section. + Without acache, + cyclic order is effective for the additional + section as well as the answer and authority sections. + However, additional section caching fixes the ordering when it + first caches an RRset for the additional section, and the same + ordering will be kept in succeeding responses, regardless of the + setting of rrset-order. + The effect of this should be minor, however, since an + RRset in the additional section + typically only contains a small number of RRs (and in many cases + it only contains a single RR), in which case the + ordering does not matter much. +

+

+ The following is a summary of options related to + acache. +

+
+
acache-enable
+

+ If yes, additional section caching is + enabled. The default value is no. +

+
acache-cleaning-interval
+

+ The server will remove stale cache entries, based on an LRU + based + algorithm, every acache-cleaning-interval minutes. + The default is 60 minutes. + If set to 0, no periodic cleaning will occur. +

+
max-acache-size
+

+ The maximum amount of memory in bytes to use for the server's acache. + When the amount of data in the acache reaches this limit, + the server + will clean more aggressively so that the limit is not + exceeded. + In a server with multiple views, the limit applies + separately to the + acache of each view. + The default is 16M. +

+
+
+
+
+

+statistics-channels Statement Grammar

+
statistics-channels {
+   [ inet ( ip_addr | * ) [ port ip_port ] [allow {  address_match_list  } ]; ]
+   [ inet ...; ]
+};
+
+
+
+

+statistics-channels Statement Definition and + Usage

+

+ The statistics-channels statement + declares communication channels to be used by system + administrators to get access to statistics information of + the name server. +

+

+ This statement intends to be flexible to support multiple + communication protocols in the future, but currently only + HTTP access is supported. + It requires that BIND 9 be compiled with libxml2; + the statistics-channels statement is + still accepted even if it is built without the library, + but any HTTP access will fail with an error. +

+

+ An inet control channel is a TCP socket + listening at the specified ip_port on the + specified ip_addr, which can be an IPv4 or IPv6 + address. An ip_addr of * (asterisk) is + interpreted as the IPv4 wildcard address; connections will be + accepted on any of the system's IPv4 addresses. + To listen on the IPv6 wildcard address, + use an ip_addr of ::. +

+

+ If no port is specified, port 80 is used for HTTP channels. + The asterisk "*" cannot be used for + ip_port. +

+

+ The attempt of opening a statistics channel is + restricted by the optional allow clause. + Connections to the statistics channel are permitted based on the + address_match_list. + If no allow clause is present, + named accepts connection + attempts from any address; since the statistics may + contain sensitive internal information, it is highly + recommended to restrict the source of connection requests + appropriately. +

+

+ If no statistics-channels statement is present, + named will not open any communication channels. +

+
+
+

+server Statement Grammar

+
server ip_addr[/prefixlen] {
+    [ bogus yes_or_no ; ]
+    [ provide-ixfr yes_or_no ; ]
+    [ request-ixfr yes_or_no ; ]
+    [ edns yes_or_no ; ]
+    [ edns-udp-size number ; ]
+    [ max-udp-size number ; ]
+    [ transfers number ; ]
+    [ transfer-format ( one-answer | many-answers ) ; ]]
+    [ keys { string ; [ string ; [...]] } ; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
+    [ query-source-v6 [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
+    [ use-queryport-pool yes_or_no; ]
+    [ queryport-pool-ports number; ]
+    [ queryport-pool-interval number; ]
+};
+
+
+
+

+server Statement Definition and + Usage

+

+ The server statement defines + characteristics + to be associated with a remote name server. If a prefix length is + specified, then a range of servers is covered. Only the most + specific + server clause applies regardless of the order in + named.conf. +

+

+ The server statement can occur at + the top level of the + configuration file or inside a view + statement. + If a view statement contains + one or more server statements, only + those + apply to the view and any top-level ones are ignored. + If a view contains no server + statements, + any top-level server statements are + used as + defaults. +

+

+ If you discover that a remote server is giving out bad data, + marking it as bogus will prevent further queries to it. The + default + value of bogus is no. +

+

+ The provide-ixfr clause determines + whether + the local server, acting as master, will respond with an + incremental + zone transfer when the given remote server, a slave, requests it. + If set to yes, incremental transfer + will be provided + whenever possible. If set to no, + all transfers + to the remote server will be non-incremental. If not set, the + value + of the provide-ixfr option in the + view or + global options block is used as a default. +

+

+ The request-ixfr clause determines + whether + the local server, acting as a slave, will request incremental zone + transfers from the given remote server, a master. If not set, the + value of the request-ixfr option in + the view or + global options block is used as a default. +

+

+ IXFR requests to servers that do not support IXFR will + automatically + fall back to AXFR. Therefore, there is no need to manually list + which servers support IXFR and which ones do not; the global + default + of yes should always work. + The purpose of the provide-ixfr and + request-ixfr clauses is + to make it possible to disable the use of IXFR even when both + master + and slave claim to support it, for example if one of the servers + is buggy and crashes or corrupts data when IXFR is used. +

+

+ The edns clause determines whether + the local server will attempt to use EDNS when communicating + with the remote server. The default is yes. +

+

+ The edns-udp-size option sets the EDNS UDP size + that is advertised by named when querying the remote server. + Valid values are 512 to 4096 bytes (values outside this range will be + silently adjusted). This option is useful when you wish to + advertises a different value to this server than the value you + advertise globally, for example, when there is a firewall at the + remote site that is blocking large replies. +

+

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

+

+ The server supports two zone transfer methods. The first, one-answer, + uses one DNS message per resource record transferred. many-answers packs + as many resource records as possible into a message. many-answers is + more efficient, but is only known to be understood by BIND 9, BIND + 8.x, and patched versions of BIND + 4.9.5. You can specify which method + to use for a server with the transfer-format option. + If transfer-format is not + specified, the transfer-format + specified + by the options statement will be + used. +

+

transfers + is used to limit the number of concurrent inbound zone + transfers from the specified server. If no + transfers clause is specified, the + limit is set according to the + transfers-per-ns option. +

+

+ The keys clause identifies a + key_id defined by the key statement, + to be used for transaction security (TSIG, the section called “TSIG”) + when talking to the remote server. + When a request is sent to the remote server, a request signature + will be generated using the key specified here and appended to the + message. A request originating from the remote server is not + required + to be signed by this key. +

+

+ Although the grammar of the keys + clause + allows for multiple keys, only a single key per server is + currently + supported. +

+

+ The transfer-source and + transfer-source-v6 clauses specify + the IPv4 and IPv6 source + address to be used for zone transfer with the remote server, + respectively. + For an IPv4 remote server, only transfer-source can + be specified. + Similarly, for an IPv6 remote server, only + transfer-source-v6 can be + specified. + For more details, see the description of + transfer-source and + transfer-source-v6 in + the section called “Zone Transfers”. +

+

+ The notify-source and + notify-source-v6 clauses specify the + IPv4 and IPv6 source address to be used for notify + messages sent to remote servers, respectively. For an + IPv4 remote server, only notify-source + can be specified. Similarly, for an IPv6 remote server, + only notify-source-v6 can be specified. +

+

+ The query-source and + query-source-v6 clauses specify the + IPv4 and IPv6 source address to be used for queries + sent to remote servers, respectively. For an IPv4 + remote server, only query-source can + be specified. Similarly, for an IPv6 remote server, + only query-source-v6 can be specified. +

+
+
+

+trusted-keys Statement Grammar

+
trusted-keys {
+    string number number number string ;
+    [ string number number number string ; [...]]
+};
+
+
+
+

+trusted-keys Statement Definition + and Usage

+

+ The trusted-keys statement defines + DNSSEC security roots. DNSSEC is described in the section called “DNSSEC”. A security root is defined when the + public key for a non-authoritative zone is known, but + cannot be securely obtained through DNS, either because + it is the DNS root zone or because its parent zone is + unsigned. Once a key has been configured as a trusted + key, it is treated as if it had been validated and + proven secure. The resolver attempts DNSSEC validation + on all DNS data in subdomains of a security root. +

+

+ All keys (and corresponding zones) listed in + trusted-keys are deemed to exist regardless + of what parent zones say. Similarly for all keys listed in + trusted-keys only those keys are + used to validate the DNSKEY RRset. The parent's DS RRset + will not be used. +

+

+ The trusted-keys statement can contain + multiple key entries, each consisting of the key's + domain name, flags, protocol, algorithm, and the Base-64 + representation of the key data. + Spaces, tabs, newlines and carriage returns are ignored + in the key data, so the configuration may be split up into + multiple lines. +

+
+
+

+view Statement Grammar

+
view view_name
+      [class] {
+      match-clients { address_match_list };
+      match-destinations { address_match_list };
+      match-recursive-only yes_or_no ;
+      [ view_option; ...]
+      [ zone_statement; ...]
+};
+
+
+
+

+view Statement Definition and Usage

+

+ The view statement is a powerful + feature + of BIND 9 that lets a name server + answer a DNS query differently + depending on who is asking. It is particularly useful for + implementing + split DNS setups without having to run multiple servers. +

+

+ Each view statement defines a view + of the + DNS namespace that will be seen by a subset of clients. A client + matches + a view if its source IP address matches the + address_match_list of the view's + match-clients clause and its + destination IP address matches + the address_match_list of the + view's + match-destinations clause. If not + specified, both + match-clients and match-destinations + default to matching all addresses. In addition to checking IP + addresses + match-clients and match-destinations + can also take keys which provide an + mechanism for the + client to select the view. A view can also be specified + as match-recursive-only, which + means that only recursive + requests from matching clients will match that view. + The order of the view statements is + significant — + a client request will be resolved in the context of the first + view that it matches. +

+

+ Zones defined within a view + statement will + only be accessible to clients that match the view. + By defining a zone of the same name in multiple views, different + zone data can be given to different clients, for example, + "internal" + and "external" clients in a split DNS setup. +

+

+ Many of the options given in the options statement + can also be used within a view + statement, and then + apply only when resolving queries with that view. When no + view-specific + value is given, the value in the options statement + is used as a default. Also, zone options can have default values + specified + in the view statement; these + view-specific defaults + take precedence over those in the options statement. +

+

+ Views are class specific. If no class is given, class IN + is assumed. Note that all non-IN views must contain a hint zone, + since only the IN class has compiled-in default hints. +

+

+ If there are no view statements in + the config + file, a default view that matches any client is automatically + created + in class IN. Any zone statements + specified on + the top level of the configuration file are considered to be part + of + this default view, and the options + statement will + apply to the default view. If any explicit view + statements are present, all zone + statements must + occur inside view statements. +

+

+ Here is an example of a typical split DNS setup implemented + using view statements: +

+
view "internal" {
+      // This should match our internal networks.
+      match-clients { 10.0.0.0/8; };
+
+      // Provide recursive service to internal clients only.
+      recursion yes;
+
+      // Provide a complete view of the example.com zone
+      // including addresses of internal hosts.
+      zone "example.com" {
+            type master;
+            file "example-internal.db";
+      };
+};
+
+view "external" {
+      // Match all clients not matched by the previous view.
+      match-clients { any; };
+
+      // Refuse recursive service to external clients.
+      recursion no;
+
+      // Provide a restricted view of the example.com zone
+      // containing only publicly accessible hosts.
+      zone "example.com" {
+           type master;
+           file "example-external.db";
+      };
+};
+
+
+
+

+zone + Statement Grammar

+
zone zone_name [class] {
+    type master;
+    [ allow-query { address_match_list }; ]
+    [ allow-query-on { address_match_list }; ]
+    [ allow-transfer { address_match_list }; ]
+    [ allow-update { address_match_list }; ]
+    [ update-policy { update_policy_rule [...] }; ]
+    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ check-names (warn|fail|ignore) ; ]
+    [ check-mx (warn|fail|ignore) ; ]
+    [ check-wildcard yes_or_no; ]
+    [ check-integrity yes_or_no ; ]
+    [ dialup dialup_option ; ]
+    [ 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 ; ]
+    [ max-transfer-idle-out number ; ]
+    [ max-transfer-time-out number ; ]
+    [ notify yes_or_no | explicit | master-only ; ]
+    [ notify-delay seconds ; ]
+    [ notify-to-soa yes_or_no; ]
+    [ pubkey number number number string ; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ zone-statistics yes_or_no ; ]
+    [ sig-validity-interval number ; ]
+    [ sig-signing-nodes number ; ]
+    [ sig-signing-signatures number ; ]
+    [ sig-signing-type number ; ]
+    [ database string ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ key-directory path_name; ]
+    [ zero-no-soa-ttl yes_or_no ; ]
+};
+
+zone zone_name [class] {
+    type slave;
+    [ allow-notify { address_match_list }; ]
+    [ allow-query { address_match_list }; ]
+    [ allow-query-on { address_match_list }; ]
+    [ allow-transfer { address_match_list }; ]
+    [ allow-update-forwarding { address_match_list }; ]
+    [ update-check-ksk yes_or_no; ]
+    [ try-tcp-refresh yes_or_no; ]
+    [ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]
+    [ check-names (warn|fail|ignore) ; ]
+    [ dialup dialup_option ; ]
+    [ 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] ) ; [...] }; ]
+    [ max-ixfr-log-size number ; ]
+    [ max-transfer-idle-in number ; ]
+    [ max-transfer-idle-out number ; ]
+    [ max-transfer-time-in number ; ]
+    [ max-transfer-time-out number ; ]
+    [ notify yes_or_no | explicit | master-only ; ]
+    [ notify-delay seconds ; ]
+    [ notify-to-soa yes_or_no; ]
+    [ pubkey number number number string ; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ use-alt-transfer-source yes_or_no; ]
+    [ notify-source (ip4_addr | *) [port ip_port] ; ]
+    [ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ zone-statistics yes_or_no ; ]
+    [ database string ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ multi-master yes_or_no ; ]
+    [ zero-no-soa-ttl yes_or_no ; ]
+};
+
+zone zone_name [class] {
+    type hint;
+    file string ;
+    [ delegation-only yes_or_no ; ]
+    [ check-names (warn|fail|ignore) ; // Not Implemented. ]
+};
+
+zone zone_name [class] {
+    type stub;
+    [ allow-query { address_match_list }; ]
+    [ allow-query-on { address_match_list }; ]
+    [ check-names (warn|fail|ignore) ; ]
+    [ dialup dialup_option ; ]
+    [ delegation-only yes_or_no ; ]
+    [ file string ; ]
+    [ masterfile-format (text|raw) ; ]
+    [ forward (only|first) ; ]
+    [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
+    [ masters [port ip_port] { ( masters_list | ip_addr [port ip_port] [key key] ) ; [...] }; ]
+    [ max-transfer-idle-in number ; ]
+    [ max-transfer-time-in number ; ]
+    [ pubkey number number number string ; ]
+    [ transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
+    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
+    [ use-alt-transfer-source yes_or_no; ]
+    [ zone-statistics yes_or_no ; ]
+    [ database string ; ]
+    [ min-refresh-time number ; ]
+    [ max-refresh-time number ; ]
+    [ min-retry-time number ; ]
+    [ max-retry-time number ; ]
+    [ multi-master yes_or_no ; ]
+};
+
+zone zone_name [class] {
+    type forward;
+    [ forward (only|first) ; ]
+    [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
+    [ delegation-only yes_or_no ; ]
+};
+
+zone zone_name [class] {
+    type delegation-only;
+};
+
+
+
+
+

+zone Statement Definition and Usage

+
+

+Zone Types

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

+ master +

+ 		+

+ The server has a master copy of the data + for the zone and will be able to provide authoritative + answers for + it. +

+
+

+ slave +

+ 		+

+ A slave zone is a replica of a master + zone. The masters list + specifies one or more IP addresses + of master servers that the slave contacts to update + its copy of the zone. + Masters list elements can also be names of other + masters lists. + By default, transfers are made from port 53 on the + servers; this can + be changed for all servers by specifying a port number + before the + list of IP addresses, or on a per-server basis after + the IP address. + Authentication to the master can also be done with + per-server TSIG keys. + If a file is specified, then the + replica will be written to this file whenever the zone + is changed, + and reloaded from this file on a server restart. Use + of a file is + recommended, since it often speeds server startup and + eliminates + a needless waste of bandwidth. Note that for large + numbers (in the + tens or hundreds of thousands) of zones per server, it + is best to + use a two-level naming scheme for zone filenames. For + example, + a slave server for the zone example.com might place + the zone contents into a file called + 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 + a single directory.) +

+
+

+ stub +

+ 		+

+ A stub zone is similar to a slave zone, + except that it replicates only the NS records of a + master zone instead + of the entire zone. Stub zones are not a standard part + of the DNS; + they are a feature specific to the BIND implementation. +

+ +

+ Stub zones can be used to eliminate the need for glue + NS record + in a parent zone at the expense of maintaining a stub + zone entry and + a set of name server addresses in named.conf. + This usage is not recommended for new configurations, + and BIND 9 + supports it only in a limited way. + In BIND 4/8, zone + transfers of a parent zone + included the NS records from stub children of that + zone. This meant + that, in some cases, users could get away with + configuring child stubs + only in the master server for the parent zone. BIND + 9 never mixes together zone data from different zones + in this + way. Therefore, if a BIND 9 master serving a parent + zone has child stub zones configured, all the slave + servers for the + parent zone also need to have the same child stub + zones + configured. +

+ +

+ Stub zones can also be used as a way of forcing the + resolution + of a given domain to use a particular set of + authoritative servers. + For example, the caching name servers on a private + network using + RFC1918 addressing may be configured with stub zones + for + 10.in-addr.arpa + to use a set of internal name servers as the + authoritative + servers for that domain. +

+
+

+ forward +

+ 		+

+ A "forward zone" is a way to configure + forwarding on a per-domain basis. A zone statement + of type forward can + contain a forward + and/or forwarders + statement, + which will apply to queries within the domain given by + the zone + name. If no forwarders + statement is present or + an empty list for forwarders is given, then no + forwarding will be done for the domain, canceling the + effects of + any forwarders in the options statement. Thus + if you want to use this type of zone to change the + behavior of the + global forward option + (that is, "forward first" + to, then "forward only", or vice versa, but want to + use the same + servers as set globally) you need to re-specify the + global forwarders. +

+
+

+ hint +

+ 		+

+ The initial set of root name servers is + specified using a "hint zone". When the server starts + up, it uses + the root hints to find a root name server and get the + most recent + list of root name servers. If no hint zone is + specified for class + IN, the server uses a compiled-in default set of root + servers hints. + Classes other than IN have no built-in defaults hints. +

+
+

+ delegation-only +

+ 		+

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

+
+
+
+

+Class

+

+ The zone's name may optionally be followed by a class. If + a class is not specified, class IN (for Internet), + is assumed. This is correct for the vast majority of cases. +

+

+ The hesiod class is + named for an information service from MIT's Project Athena. It + is + used to share information about various systems databases, such + as users, groups, printers and so on. The keyword + HS is + a synonym for hesiod. +

+

+ Another MIT development is Chaosnet, a LAN protocol created + in the mid-1970s. Zone data for it can be specified with the CHAOS class. +

+
+
+

+Zone Options

+
+
allow-notify
+

+ See the description of + allow-notify in the section called “Access Control”. +

+
allow-query
+

+ See the description of + allow-query in the section called “Access Control”. +

+
allow-query-on
+

+ See the description of + allow-query-on in the section called “Access Control”. +

+
allow-transfer
+

+ See the description of allow-transfer + in the section called “Access Control”. +

+
allow-update
+

+ See the description of allow-update + in the section called “Access Control”. +

+
update-policy
+

+ Specifies a "Simple Secure Update" policy. See + the section called “Dynamic Update Policies”. +

+
allow-update-forwarding
+

+ See the description of allow-update-forwarding + in the section called “Access Control”. +

+
also-notify
+

+ Only meaningful if notify + is + active for this zone. The set of machines that will + receive a + DNS NOTIFY message + for this zone is made up of all the listed name servers + (other than + the primary master) for the zone plus any IP addresses + specified + with also-notify. A port + may be specified + with each also-notify + address to send the notify + messages to a port other than the default of 53. + also-notify is not + meaningful for stub zones. + The default is the empty list. +

+
check-names
+

+ This option is used to restrict the character set and + syntax of + certain domain names in master files and/or DNS responses + received from the + network. The default varies according to zone type. For master zones the default is fail. For slave + zones the default is warn. +

+
check-mx
+

+ See the description of + check-mx in the section called “Boolean Options”. +

+
check-wildcard
+

+ See the description of + check-wildcard in the section called “Boolean Options”. +

+
check-integrity
+

+ See the description of + check-integrity in the section called “Boolean Options”. +

+
check-sibling
+

+ See the description of + check-sibling in the section called “Boolean Options”. +

+
zero-no-soa-ttl
+

+ See the description of + zero-no-soa-ttl in the section called “Boolean Options”. +

+
update-check-ksk
+

+ See the description of + update-check-ksk in the section called “Boolean Options”. +

+
try-tcp-refresh
+

+ See the description of + try-tcp-refresh in the section called “Boolean Options”. +

+
database
+
+

+ Specify the type of database to be used for storing the + zone data. The string following the database keyword + is interpreted as a list of whitespace-delimited words. + The first word + identifies the database type, and any subsequent words are + passed + as arguments to the database to be interpreted in a way + specific + to the database type. +

+

+ The default is "rbt", BIND 9's + native in-memory + red-black-tree database. This database does not take + arguments. +

+

+ Other values are possible if additional database drivers + have been linked into the server. Some sample drivers are + included + with the distribution but none are linked in by default. +

+
+
dialup
+

+ See the description of + 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. +

+
forward
+

+ Only meaningful if the zone has a forwarders + list. The only value causes + the lookup to fail + after trying the forwarders and getting no answer, while first would + allow a normal lookup to be tried. +

+
forwarders
+

+ Used to override the list of global forwarders. + If it is not specified in a zone of type forward, + no forwarding is done for the zone and the global options are + not used. +

+
ixfr-base
+

+ Was used in BIND 8 to + specify the name + of the transaction log (journal) file for dynamic update + and IXFR. + BIND 9 ignores the option + and constructs the name of the journal + file by appending ".jnl" + to the name of the + zone file. +

+
ixfr-tmp-file
+

+ Was an undocumented option in BIND 8. + Ignored in BIND 9. +

+
journal
+

+ Allow the default journal's filename to be overridden. + The default is the zone's filename with ".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 + max-transfer-time-in in the section called “Zone Transfers”. +

+
max-transfer-idle-in
+

+ See the description of + max-transfer-idle-in in the section called “Zone Transfers”. +

+
max-transfer-time-out
+

+ See the description of + max-transfer-time-out in the section called “Zone Transfers”. +

+
max-transfer-idle-out
+

+ See the description of + max-transfer-idle-out in the section called “Zone Transfers”. +

+
notify
+

+ See the description of + notify in the section called “Boolean Options”. +

+
notify-delay
+

+ See the description of + notify-delay in the section called “Tuning”. +

+
notify-to-soa
+

+ See the description of + notify-to-soa in + the section called “Boolean Options”. +

+
pubkey
+

+ In BIND 8, this option was + intended for specifying + a public zone key for verification of signatures in DNSSEC + signed + zones when they are loaded from disk. BIND 9 does not verify signatures + on load and ignores the option. +

+
zone-statistics
+

+ If yes, the server will keep + statistical + information for this zone, which can be dumped to the + statistics-file defined in + the server options. +

+
sig-validity-interval
+

+ See the description of + sig-validity-interval in the section called “Tuning”. +

+
sig-signing-nodes
+

+ See the description of + sig-signing-nodes in the section called “Tuning”. +

+
sig-signing-signatures
+

+ See the description of + sig-signing-signatures in the section called “Tuning”. +

+
sig-signing-type
+

+ See the description of + sig-signing-type in the section called “Tuning”. +

+
transfer-source
+

+ See the description of + transfer-source in the section called “Zone Transfers”. +

+
transfer-source-v6
+

+ See the description of + transfer-source-v6 in the section called “Zone Transfers”. +

+
alt-transfer-source
+

+ See the description of + alt-transfer-source in the section called “Zone Transfers”. +

+
alt-transfer-source-v6
+

+ See the description of + alt-transfer-source-v6 in the section called “Zone Transfers”. +

+
use-alt-transfer-source
+

+ See the description of + use-alt-transfer-source in the section called “Zone Transfers”. +

+
notify-source
+

+ See the description of + notify-source in the section called “Zone Transfers”. +

+
notify-source-v6
+

+ See the description of + notify-source-v6 in the section called “Zone Transfers”. +

+
+min-refresh-time, max-refresh-time, min-retry-time, max-retry-time +
+

+ See the description in the section called “Tuning”. +

+
ixfr-from-differences
+

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

+ See the description of + key-directory in the section called “options Statement Definition and + Usage”. +

+
multi-master
+

+ See the description of multi-master in + the section called “Boolean Options”. +

+
masterfile-format
+

+ See the description of masterfile-format + in the section called “Tuning”. +

+
+
+
+

+Dynamic Update Policies

+

BIND 9 supports two alternative + methods of granting clients the right to perform + dynamic updates to a zone, configured by the + allow-update and + update-policy option, respectively. +

+

+ The allow-update clause works the + same way as in previous versions of BIND. + It grants given clients the permission to update any + record of any name in the zone. +

+

+ The update-policy clause is new + in BIND 9 and allows more fine-grained + control over what updates are allowed. A set of rules + is specified, where each rule either grants or denies + permissions for one or more names to be updated by + one or more identities. If the dynamic update request + message is signed (that is, it includes either a TSIG + or SIG(0) record), the identity of the signer can be + determined. +

+

+ Rules are specified in the update-policy + zone option, and are only meaningful for master zones. + When the update-policy statement + is present, it is a configuration error for the + allow-update statement to be + present. The update-policy statement + only examines the signer of a message; the source + address is not relevant. +

+

+ This is how a rule definition looks: +

+
+( grant | deny ) identity nametype name [ types ]
+
+

+ Each rule grants or denies privileges. Once a message has + successfully matched a rule, the operation is immediately + granted + or denied and no further rules are examined. A rule is matched + when the signer matches the identity field, the name matches the + name field in accordance with the nametype field, and the type + matches + the types specified in the type field. +

+

+ No signer is required for tcp-self + or 6to4-self however the standard + reverse mapping / prefix conversion must match the identity + field. +

+

+ The identity field specifies a name or a wildcard + name. Normally, this is the name of the TSIG or + SIG(0) key used to sign the update request. When a + TKEY exchange has been used to create a shared secret, + the identity of the shared secret is the same as the + identity of the key used to authenticate the TKEY + exchange. TKEY is also the negotiation method used + by GSS-TSIG, which establishes an identity that is + the Kerberos principal of the client, such as + "user@host.domain". When the + identity field specifies + a wildcard name, it is subject to DNS wildcard + expansion, so the rule will apply to multiple identities. + The identity field must + contain a fully-qualified domain name. +

+

+ The nametype field has 12 + values: + name, subdomain, + wildcard, self, + selfsub, selfwild, + krb5-self, ms-self, + krb5-subdomain, + ms-subdomain, + tcp-self and 6to4-self. +

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

+ name +

+ 		+

+ Exact-match semantics. This rule matches + when the name being updated is identical + to the contents of the + name field. +

+
+

+ subdomain +

+ 		+

+ This rule matches when the name being updated + is a subdomain of, or identical to, the + contents of the name + field. +

+
+

+ wildcard +

+ 		+

+ The name field + is subject to DNS wildcard expansion, and + this rule matches when the name being updated + name is a valid expansion of the wildcard. +

+
+

+ self +

+ 		+

+ This rule matches when the name being updated + matches the contents of the + identity field. + The name field + is ignored, but should be the same as the + identity field. + The self nametype is + most useful when allowing using one key per + name to update, where the key has the same + name as the name to be updated. The + identity would + be specified as * (an asterisk) in + this case. +

+
+

+ selfsub +

+ 		+

+ This rule is similar to self + except that subdomains of self + can also be updated. +

+
+

+ selfwild +

+ 		+

+ This rule is similar to self + except that only subdomains of + self can be updated. +

+
+

+ tcp-self +

+ 		+

+ Allow updates that have been sent via TCP and + for which the standard mapping from the initiating + IP address into the IN-ADDR.ARPA and IP6.ARPA + namespaces match the name to be updated. +

+
+

Note

+ It is theoretically possible to spoof these TCP + sessions. +
+
+

+ 6to4-self +

+ 		+

+ Allow the 6to4 prefix to be update by any TCP + conection from the 6to4 network or from the + corresponding IPv4 address. This is intended + to allow NS or DNAME RRsets to be added to the + reverse tree. +

+
+

Note

+ It is theoretically possible to spoof these TCP + sessions. +
+
+

+ In all cases, the name + field must + specify a fully-qualified domain name. +

+

+ If no types are explicitly specified, this rule matches + all types except RRSIG, NS, SOA, NSEC and NSEC3. Types + may be specified by name, including "ANY" (ANY matches + all types except NSEC and NSEC3, which can never be + updated). Note that when an attempt is made to delete + all records associated with a name, the rules are + checked for each existing record type. +

+
+
+
+
+

+Zone File

+
+

+Types of Resource Records and When to Use Them

+

+ This section, largely borrowed from RFC 1034, describes the + concept of a Resource Record (RR) and explains when each is used. + Since the publication of RFC 1034, several new RRs have been + identified + and implemented in the DNS. These are also included. +

+
+

+Resource Records

+

+ A domain name identifies a node. Each node has a set of + resource information, which may be empty. The set of resource + information associated with a particular name is composed of + separate RRs. The order of RRs in a set is not significant and + need not be preserved by name servers, resolvers, or other + parts of the DNS. However, sorting of multiple RRs is + permitted for optimization purposes, for example, to specify + that a particular nearby server be tried first. See the section called “The sortlist Statement” and the section called “RRset Ordering”. +

+

+ The components of a Resource Record are: +

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

+ owner name +

+ 		+

+ The domain name where the RR is found. +

+
+

+ type +

+ 		+

+ An encoded 16-bit value that specifies + the type of the resource record. +

+
+

+ TTL +

+ 		+

+ The time-to-live of the RR. This field + is a 32-bit integer in units of seconds, and is + primarily used by + resolvers when they cache RRs. The TTL describes how + long a RR can + be cached before it should be discarded. +

+
+

+ class +

+ 		+

+ An encoded 16-bit value that identifies + a protocol family or instance of a protocol. +

+
+

+ RDATA +

+ 		+

+ The resource data. The format of the + data is type (and sometimes class) specific. +

+
+

+ The following are types of valid RRs: +

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

+ A +

+ 		+

+ A host address. In the IN class, this is a + 32-bit IP address. Described in RFC 1035. +

+
+

+ AAAA +

+ 		+

+ IPv6 address. Described in RFC 1886. +

+
+

+ A6 +

+ 		+

+ IPv6 address. This can be a partial + address (a suffix) and an indirection to the name + where the rest of the + address (the prefix) can be found. Experimental. + Described in RFC 2874. +

+
+

+ AFSDB +

+ 		+

+ Location of AFS database servers. + Experimental. Described in RFC 1183. +

+
+

+ APL +

+ 		+

+ Address prefix list. Experimental. + Described in RFC 3123. +

+
+

+ CERT +

+ 		+

+ Holds a digital certificate. + Described in RFC 2538. +

+
+

+ CNAME +

+ 		+

+ Identifies the canonical name of an alias. + Described in RFC 1035. +

+
+

+ DHCID +

+ 		+

+ Is used for identifying which DHCP client is + associated with this name. Described in RFC 4701. +

+
+

+ DNAME +

+ 		+

+ Replaces the domain name specified with + another name to be looked up, effectively aliasing an + entire + subtree of the domain name space rather than a single + record + as in the case of the CNAME RR. + Described in RFC 2672. +

+
+

+ DNSKEY +

+ 		+

+ Stores a public key associated with a signed + DNS zone. Described in RFC 4034. +

+
+

+ DS +

+ 		+

+ Stores the hash of a public key associated with a + signed DNS zone. Described in RFC 4034. +

+
+

+ GPOS +

+ 		+

+ Specifies the global position. Superseded by LOC. +

+
+

+ HINFO +

+ 		+

+ Identifies the CPU and OS used by a host. + Described in RFC 1035. +

+
+

+ IPSECKEY +

+ 		+

+ Provides a method for storing IPsec keying material in + DNS. Described in RFC 4025. +

+
+

+ ISDN +

+ 		+

+ Representation of ISDN addresses. + Experimental. Described in RFC 1183. +

+
+

+ KEY +

+ 		+

+ Stores a public key associated with a + DNS name. Used in original DNSSEC; replaced + by DNSKEY in DNSSECbis, but still used with + SIG(0). Described in RFCs 2535 and 2931. +

+
+

+ KX +

+ 		+

+ Identifies a key exchanger for this + DNS name. Described in RFC 2230. +

+
+

+ LOC +

+ 		+

+ For storing GPS info. Described in RFC 1876. + Experimental. +

+
+

+ MX +

+ 		+

+ Identifies a mail exchange for the domain with + a 16-bit preference value (lower is better) + followed by the host name of the mail exchange. + Described in RFC 974, RFC 1035. +

+
+

+ NAPTR +

+ 		+

+ Name authority pointer. Described in RFC 2915. +

+
+

+ NSAP +

+ 		+

+ A network service access point. + Described in RFC 1706. +

+
+

+ NS +

+ 		+

+ The authoritative name server for the + domain. Described in RFC 1035. +

+
+

+ NSEC +

+ 		+

+ Used in DNSSECbis to securely indicate that + RRs with an owner name in a certain name interval do + not exist in + a zone and indicate what RR types are present for an + existing name. + Described in RFC 4034. +

+
+

+ NSEC3 +

+ 		+

+ Used in DNSSECbis to securely indicate that + RRs with an owner name in a certain name + interval do not exist in a zone and indicate + what RR types are present for an existing + name. NSEC3 differs from NSEC in that it + prevents zone enumeration but is more + computationally expensive on both the server + and the client than NSEC. Described in RFC + 5155. +

+
+

+ NSEC3PARAM +

+ 		+

+ Used in DNSSECbis to tell the authoritative + server which NSEC3 chains are available to use. + Described in RFC 5155. +

+
+

+ NXT +

+ 		+

+ Used in DNSSEC to securely indicate that + RRs with an owner name in a certain name interval do + not exist in + a zone and indicate what RR types are present for an + existing name. + Used in original DNSSEC; replaced by NSEC in + DNSSECbis. + Described in RFC 2535. +

+
+

+ PTR +

+ 		+

+ A pointer to another part of the domain + name space. Described in RFC 1035. +

+
+

+ PX +

+ 		+

+ Provides mappings between RFC 822 and X.400 + addresses. Described in RFC 2163. +

+
+

+ RP +

+ 		+

+ Information on persons responsible + for the domain. Experimental. Described in RFC 1183. +

+
+

+ RRSIG +

+ 		+

+ Contains DNSSECbis signature data. Described + in RFC 4034. +

+
+

+ RT +

+ 		+

+ Route-through binding for hosts that + do not have their own direct wide area network + addresses. + Experimental. Described in RFC 1183. +

+
+

+ SIG +

+ 		+

+ Contains DNSSEC signature data. Used in + original DNSSEC; replaced by RRSIG in + DNSSECbis, but still used for SIG(0). + Described in RFCs 2535 and 2931. +

+
+

+ SOA +

+ 		+

+ Identifies the start of a zone of authority. + Described in RFC 1035. +

+
+

+ SPF +

+ 		+

+ Contains the Sender Policy Framework information + for a given email domain. Described in RFC 4408. +

+
+

+ SRV +

+ 		+

+ Information about well known network + services (replaces WKS). Described in RFC 2782. +

+
+

+ SSHFP +

+ 		+

+ Provides a way to securely publish a secure shell key's + fingerprint. Described in RFC 4255. +

+
+

+ TXT +

+ 		+

+ Text records. Described in RFC 1035. +

+
+

+ WKS +

+ 		+

+ Information about which well known + network services, such as SMTP, that a domain + supports. Historical. +

+
+

+ X25 +

+ 		+

+ Representation of X.25 network addresses. + Experimental. Described in RFC 1183. +

+
+

+ The following classes of resource records + are currently valid in the DNS: +

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

+ IN +

+ 		+

+ The Internet. +

+
+

+ CH +

+ 		+

+ Chaosnet, a LAN protocol created at MIT in the + mid-1970s. + Rarely used for its historical purpose, but reused for + BIND's + built-in server information zones, e.g., + version.bind. +

+
+

+ HS +

+ 		+

+ Hesiod, an information service + developed by MIT's Project Athena. It is used to share + information + about various systems databases, such as users, + groups, printers + and so on. +

+
+

+ The owner name is often implicit, rather than forming an + integral + part of the RR. For example, many name servers internally form + tree + or hash structures for the name space, and chain RRs off nodes. + The remaining RR parts are the fixed header (type, class, TTL) + which is consistent for all RRs, and a variable part (RDATA) + that + fits the needs of the resource being described. +

+

+ The meaning of the TTL field is a time limit on how long an + RR can be kept in a cache. This limit does not apply to + authoritative + data in zones; it is also timed out, but by the refreshing + policies + for the zone. The TTL is assigned by the administrator for the + zone where the data originates. While short TTLs can be used to + minimize caching, and a zero TTL prohibits caching, the + realities + of Internet performance suggest that these times should be on + the + order of days for the typical host. If a change can be + anticipated, + the TTL can be reduced prior to the change to minimize + inconsistency + during the change, and then increased back to its former value + following + the change. +

+

+ The data in the RDATA section of RRs is carried as a combination + of binary strings and domain names. The domain names are + frequently + used as "pointers" to other data in the DNS. +

+
+
+

+Textual expression of RRs

+

+ RRs are represented in binary form in the packets of the DNS + protocol, and are usually represented in highly encoded form + when + stored in a name server or resolver. In the examples provided + in + RFC 1034, a style similar to that used in master files was + employed + in order to show the contents of RRs. In this format, most RRs + are shown on a single line, although continuation lines are + possible + using parentheses. +

+

+ The start of the line gives the owner of the RR. If a line + begins with a blank, then the owner is assumed to be the same as + that of the previous RR. Blank lines are often included for + readability. +

+

+ Following the owner, we list the TTL, type, and class of the + RR. Class and type use the mnemonics defined above, and TTL is + an integer before the type field. In order to avoid ambiguity + in + parsing, type and class mnemonics are disjoint, TTLs are + integers, + and the type mnemonic is always last. The IN class and TTL + values + are often omitted from examples in the interests of clarity. +

+

+ The resource data or RDATA section of the RR are given using + knowledge of the typical representation for the data. +

+

+ For example, we might show the RRs carried in a message as: +

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

+ ISI.EDU. +

+ 		+

+ MX +

+ 		+

+ 10 VENERA.ISI.EDU. +

+
+

+ 		+

+ MX +

+ 		+

+ 10 VAXA.ISI.EDU +

+
+

+ VENERA.ISI.EDU +

+ 		+

+ A +

+ 		+

+ 128.9.0.32 +

+
+

+ 		+

+ A +

+ 		+

+ 10.1.0.52 +

+
+

+ VAXA.ISI.EDU +

+ 		+

+ A +

+ 		+

+ 10.2.0.27 +

+
+

+ 		+

+ A +

+ 		+

+ 128.9.0.33 +

+
+

+ The MX RRs have an RDATA section which consists of a 16-bit + number followed by a domain name. The address RRs use a + standard + IP address format to contain a 32-bit internet address. +

+

+ The above example shows six RRs, with two RRs at each of three + domain names. +

+

+ Similarly we might see: +

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

+ XX.LCS.MIT.EDU. +

+ 		+

+ IN A +

+ 		+

+ 10.0.0.44 +

+
  +

+ CH A +

+ 		+

+ MIT.EDU. 2420 +

+
+

+ This example shows two addresses for + XX.LCS.MIT.EDU, each of a different class. +

+
+
+
+

+Discussion of MX Records

+

+ As described above, domain servers store information as a + series of resource records, each of which contains a particular + piece of information about a given domain name (which is usually, + but not always, a host). The simplest way to think of a RR is as + a typed pair of data, a domain name matched with a relevant datum, + and stored with some additional type information to help systems + determine when the RR is relevant. +

+

+ MX records are used to control delivery of email. The data + specified in the record is a priority and a domain name. The + priority + controls the order in which email delivery is attempted, with the + lowest number first. If two priorities are the same, a server is + chosen randomly. If no servers at a given priority are responding, + the mail transport agent will fall back to the next largest + priority. + Priority numbers do not have any absolute meaning — they are + relevant + only respective to other MX records for that domain name. The + domain + name given is the machine to which the mail will be delivered. + It must have an associated address record + (A or AAAA) — CNAME is not sufficient. +

+

+ For a given domain, if there is both a CNAME record and an + MX record, the MX record is in error, and will be ignored. + Instead, + the mail will be delivered to the server specified in the MX + record + pointed to by the CNAME. +

+

+ For example: +

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

+ example.com. +

+ 		+

+ IN +

+ 		+

+ MX +

+ 		+

+ 10 +

+ 		+

+ mail.example.com. +

+
+

+ 		+

+ IN +

+ 		+

+ MX +

+ 		+

+ 10 +

+ 		+

+ mail2.example.com. +

+
+

+ 		+

+ IN +

+ 		+

+ MX +

+ 		+

+ 20 +

+ 		+

+ mail.backup.org. +

+
+

+ mail.example.com. +

+ 		+

+ IN +

+ 		+

+ A +

+ 		+

+ 10.0.0.1 +

+ 		+

+
+

+ mail2.example.com. +

+ 		+

+ IN +

+ 		+

+ A +

+ 		+

+ 10.0.0.2 +

+ 		+

+
+

+ Mail delivery will be attempted to mail.example.com and + mail2.example.com (in + any order), and if neither of those succeed, delivery to mail.backup.org will + be attempted. +

+
+
+

+Setting TTLs

+

+ The time-to-live of the RR field is a 32-bit integer represented + in units of seconds, and is primarily used by resolvers when they + cache RRs. The TTL describes how long a RR can be cached before it + should be discarded. The following three types of TTL are + currently + used in a zone file. +

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

+ SOA +

+ 		+

+ The last field in the SOA is the negative + caching TTL. This controls how long other servers will + cache no-such-domain + (NXDOMAIN) responses from you. +

+

+ The maximum time for + negative caching is 3 hours (3h). +

+
+

+ $TTL +

+ 		+

+ The $TTL directive at the top of the + zone file (before the SOA) gives a default TTL for every + RR without + a specific TTL set. +

+
+

+ RR TTLs +

+ 		+

+ Each RR can have a TTL as the second + field in the RR, which will control how long other + servers can cache + the it. +

+
+

+ All of these TTLs default to units of seconds, though units + can be explicitly specified, for example, 1h30m. +

+
+
+

+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 + and PTR records. Entries in the in-addr.arpa domain are made in + least-to-most significant order, read left to right. This is the + opposite order to the way IP addresses are usually written. Thus, + a machine with an IP address of 10.1.2.3 would have a + corresponding + in-addr.arpa name of + 3.2.1.10.in-addr.arpa. This name should have a PTR resource record + whose data field is the name of the machine or, optionally, + multiple + PTR records if the machine has more than one name. For example, + in the [example.com] domain: +

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

+ $ORIGIN +

+ 		+

+ 2.1.10.in-addr.arpa +

+
+

+ 3 +

+ 		+

+ IN PTR foo.example.com. +

+
+
+

Note

+

+ The $ORIGIN lines in the examples + are for providing context to the examples only — they do not + necessarily + appear in the actual usage. They are only used here to indicate + that the example is relative to the listed origin. +

+
+
+
+

+Other Zone File Directives

+

+ The Master File Format was initially defined in RFC 1035 and + has subsequently been extended. While the Master File Format + itself + is class independent all records in a Master File must be of the + same + class. +

+

+ Master File Directives include $ORIGIN, $INCLUDE, + and $TTL. +

+
+

+The $ORIGIN Directive

+

+ Syntax: $ORIGIN + domain-name + [comment] +

+

$ORIGIN + sets the domain name that will be appended to any + unqualified records. When a zone is first read in there + is an implicit $ORIGIN + <zone-name>. + The current $ORIGIN is appended to + the domain specified in the $ORIGIN + argument if it is not absolute. +

+
+$ORIGIN example.com.
+WWW     CNAME   MAIN-SERVER
+
+

+ is equivalent to +

+
+WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
+
+
+
+

+The $INCLUDE Directive

+

+ Syntax: $INCLUDE + filename + [ +origin ] + [ comment ] +

+

+ Read and process the file filename as + if it were included into the file at this point. If origin is + specified the file is processed with $ORIGIN set + to that value, otherwise the current $ORIGIN is + used. +

+

+ The origin and the current domain name + revert to the values they had prior to the $INCLUDE once + the file has been read. +

+
+

Note

+

+ RFC 1035 specifies that the current origin should be restored + after + an $INCLUDE, but it is silent + on whether the current + domain name should also be restored. BIND 9 restores both of + them. + This could be construed as a deviation from RFC 1035, a + feature, or both. +

+
+
+
+

+The $TTL Directive

+

+ Syntax: $TTL + default-ttl + [ +comment ] +

+

+ Set the default Time To Live (TTL) for subsequent records + with undefined TTLs. Valid TTLs are of the range 0-2147483647 + seconds. +

+

$TTL + is defined in RFC 2308. +

+
+
+
+

+BIND Master File Extension: the $GENERATE Directive

+

+ Syntax: $GENERATE + range + lhs + [ttl] + [class] + type + rhs + [comment] +

+

$GENERATE + is used to create a series of resource records that only + differ from each other by an + iterator. $GENERATE can be used to + easily generate the sets of records required to support + sub /24 reverse delegations described in RFC 2317: + Classless IN-ADDR.ARPA delegation. +

+
$ORIGIN 0.0.192.IN-ADDR.ARPA.
+$GENERATE 1-2 0 NS SERVER$.EXAMPLE.
+$GENERATE 1-127 $ CNAME $.0
+

+ is equivalent to +

+
0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.
+0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
+1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
+2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
+...
+127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
+
+
++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

range

+ 		+

+ This can be one of two forms: start-stop + or start-stop/step. If the first form is used, then step + is set to + 1. All of start, stop and step must be positive. +

+
+

lhs

+ 		+

This + describes the owner name of the resource records + to be created. Any single $ + (dollar sign) + symbols within the lhs side + are replaced by the iterator value. + + To get a $ in the output, you need to escape the + $ using a backslash + \, + e.g. \$. The + $ may optionally be followed + by modifiers which change the offset from the + iterator, field width and base. + + Modifiers are introduced by a + { (left brace) immediately following the + $ as + ${offset[,width[,base]]}. + For example, ${-20,3,d} + subtracts 20 from the current value, prints the + result as a decimal in a zero-padded field of + width 3. + + Available output forms are decimal + (d), octal + (o) and hexadecimal + (x or X + for uppercase). The default modifier is + ${0,0,d}. If the + lhs is not absolute, the + current $ORIGIN is appended + to the name. +

+

+ For compatibility with earlier versions, $$ is still + recognized as indicating a literal $ in the output. +

+
+

ttl

+ 		+

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

+

class + and ttl can be + entered in either order. +

+
+

class

+ 		+

+ Specifies the class of the generated records. + This must match the zone class if it is + specified. +

+

class + and ttl can be + entered in either order. +

+
+

type

+ 		+

+ At present the only supported types are + PTR, CNAME, DNAME, A, AAAA and NS. +

+
+

rhs

+ 		+

+ rhs is a domain name. It is processed + similarly to lhs. +

+
+

+ The $GENERATE directive is a BIND extension + and not part of the standard zone file format. +

+

+ BIND 8 does not support the optional TTL and CLASS fields. +

+
+
+

+Additional File Formats

+

+ In addition to the standard textual format, BIND 9 + supports the ability to read or dump to zone files in + other formats. The raw format is + currently available as an additional format. It is a + binary format representing BIND 9's internal data + structure directly, thereby remarkably improving the + loading time. +

+

+ For a primary server, a zone file in the + raw format is expected to be + generated from a textual zone file by the + named-compilezone command. For a + secondary server or for a dynamic zone, it is automatically + generated (if this format is specified by the + masterfile-format option) when + named dumps the zone contents after + zone transfer or when applying prior updates. +

+

+ If a zone file in a binary format needs manual modification, + it first must be converted to a textual form by the + named-compilezone command. All + necessary modification should go to the text file, which + should then be converted to the binary form by the + named-compilezone command again. +

+

+ Although the raw format uses the + network byte order and avoids architecture-dependent + data alignment so that it is as much portable as + possible, it is primarily expected to be used inside + the same single system. In order to export a zone + file in the raw format or make a + portable backup of the file, it is recommended to + convert the file to the standard textual representation. +

+
+
+
+

+BIND9 Statistics

+

+ BIND 9 maintains lots of statistics + information and provides several interfaces for users to + get access to the statistics. + The available statistics include all statistics counters + that were available in BIND 8 and + are meaningful in BIND 9, + and other information that is considered useful. +

+

+ The statistics information is categorized into the following + sections. +

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

Incoming Requests

+ 		+

+ The number of incoming DNS requests for each OPCODE. +

+
+

Incoming Queries

+ 		+

+ The number of incoming queries for each RR type. +

+
+

Outgoing Queries

+ 		+

+ The number of outgoing queries for each RR + type sent from the internal resolver. + Maintained per view. +

+
+

Name Server Statistics

+ 		+

+ Statistics counters about incoming request processing. +

+
+

Zone Maintenance Statistics

+ 		+

+ Statistics counters regarding zone maintenance + operations such as zone transfers. +

+
+

Resolver Statistics

+ 		+

+ Statistics counters about name resolution + performed in the internal resolver. + Maintained per view. +

+
+

Cache DB RRsets

+ 		+

+ The number of RRsets per RR type (positive + or negative) and nonexistent names stored in the + cache database. + Maintained per view. +

+
+

+ A subset of Name Server Statistics is collected and shown + per zone for which the server has the authority when + zone-statistics is set to + yes. + These statistics counters are shown with their zone and view + names. + In some cases the view names are omitted for the default view. +

+

+ There are currently two user interfaces to get access to the + statistics. + One is in the plain text format dumped to the file specified + by the statistics-file configuration option. + The other is remotely accessible via a statistics channel + when the statistics-channels statement + is specified in the configuration file + (see the section called “statistics-channels Statement Grammar”.) +

+
+

+The Statistics File

+

+ The text format statistics dump begins with a line, like: +

+

+ +++ Statistics Dump +++ (973798949) +

+

+ The number in parentheses is a standard + Unix-style timestamp, measured as seconds since January 1, 1970. + + Following + that line is a set of statistics information, which is categorized + as described above. + Each section begins with a line, like: +

+

+ ++ Name Server Statistics ++ +

+

+ Each section consists of lines, each containing the statistics + counter value followed by its textual description. + See below for available counters. + For brevity, counters that have a value of 0 are not shown + in the statistics file. +

+

+ The statistics dump ends with the line where the + number is identical to the number in the beginning line; for example: +

+

+ --- Statistics Dump --- (973798949) +

+
+
+

+Statistics Counters

+

+ The following tables summarize statistics counters that + BIND 9 provides. + For each row of the tables, the leftmost column is the + abbreviated symbol name of that counter. + These symbols are shown in the statistics information + accessed via an HTTP statistics channel. + The rightmost column gives the description of the counter, + which is also shown in the statistics file + (but, in this document, possibly with slight modification + for better readability). + Additional notes may also be provided in this column. + When a middle column exists between these two columns, + it gives the corresponding counter name of the + BIND 8 statistics, if applicable. +

+
+

+Name Server Statistics Counters

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

+ Symbol +

+ 		+

+ BIND8 Symbol +

+ 		+

+ Description +

+
+

Requestv4

+ 		+

RQ

+ 		+

+ IPv4 requests received. + Note: this also counts non query requests. +

+
+

Requestv6

+ 		+

RQ

+ 		+

+ IPv6 requests received. + Note: this also counts non query requests. +

+
+

ReqEdns0

+ 		+

+ 		+

+ Requests with EDNS(0) received. +

+
+

ReqBadEDNSVer

+ 		+

+ 		+

+ Requests with unsupported EDNS version received. +

+
+

ReqTSIG

+ 		+

+ 		+

+ Requests with TSIG received. +

+
+

ReqSIG0

+ 		+

+ 		+

+ Requests with SIG(0) received. +

+
+

ReqBadSIG

+ 		+

+ 		+

+ Requests with invalid (TSIG or SIG(0)) signature. +

+
+

ReqTCP

+ 		+

RTCP

+ 		+

+ TCP requests received. +

+
+

AuthQryRej

+ 		+

RUQ

+ 		+

+ Authoritative (non recursive) queries rejected. +

+
+

RecQryRej

+ 		+

RURQ

+ 		+

+ Recursive queries rejected. +

+
+

XfrRej

+ 		+

RUXFR

+ 		+

+ Zone transfer requests rejected. +

+
+

UpdateRej

+ 		+

RUUpd

+ 		+

+ Dynamic update requests rejected. +

+
+

Response

+ 		+

SAns

+ 		+

+ Responses sent. +

+
+

RespTruncated

+ 		+

+ 		+

+ Truncated responses sent. +

+
+

RespEDNS0

+ 		+

+ 		+

+ Responses with EDNS(0) sent. +

+
+

RespTSIG

+ 		+

+ 		+

+ Responses with TSIG sent. +

+
+

RespSIG0

+ 		+

+ 		+

+ Responses with SIG(0) sent. +

+
+

QrySuccess

+ 		+

+ 		+

+ Queries resulted in a successful answer. + This means the query which returns a NOERROR response + with at least one answer RR. + This corresponds to the + success counter + of previous versions of + BIND 9. +

+
+

QryAuthAns

+ 		+

+ 		+

+ Queries resulted in authoritative answer. +

+
+

QryNoauthAns

+ 		+

SNaAns

+ 		+

+ Queries resulted in non authoritative answer. +

+
+

QryReferral

+ 		+

+ 		+

+ Queries resulted in referral answer. + This corresponds to the + referral counter + of previous versions of + BIND 9. +

+
+

QryNxrrset

+ 		+

+ 		+

+ Queries resulted in NOERROR responses with no data. + This corresponds to the + nxrrset counter + of previous versions of + BIND 9. +

+
+

QrySERVFAIL

+ 		+

SFail

+ 		+

+ Queries resulted in SERVFAIL. +

+
+

QryFORMERR

+ 		+

SFErr

+ 		+

+ Queries resulted in FORMERR. +

+
+

QryNXDOMAIN

+ 		+

SNXD

+ 		+

+ Queries resulted in NXDOMAIN. + This corresponds to the + nxdomain counter + of previous versions of + BIND 9. +

+
+

QryRecursion

+ 		+

RFwdQ

+ 		+

+ Queries which caused the server + to perform recursion in order to find the final answer. + This corresponds to the + recursion counter + of previous versions of + BIND 9. +

+
+

QryDuplicate

+ 		+

RDupQ

+ 		+

+ Queries which the server attempted to + recurse but discovered an existing query with the same + IP address, port, query ID, name, type and class + already being processed. + This corresponds to the + duplicate counter + of previous versions of + BIND 9. +

+
+

QryDropped

+ 		+

+ 		+

+ Queries for which the server + discovered an excessive number of existing + recursive queries for the same name, type and + class and were subsequently dropped. + This corresponds to the + dropped counter + of previous versions of + BIND 9. +

+
+

QryFailure

+ 		+

+ 		+

+ Other query failures. + This corresponds to the + failure counter + of previous versions of + BIND 9. +

+
+

XfrReqDone

+ 		+

+ 		+

+ Requested zone transfers completed. +

+
+

UpdateReqFwd

+ 		+

+ 		+

+ Update requests forwarded. +

+
+

UpdateRespFwd

+ 		+

+ 		+

+ Update responses forwarded. +

+
+

UpdateFwdFail

+ 		+

+ 		+

+ Dynamic update forward failed. +

+
+

UpdateDone

+ 		+

+ 		+

+ Dynamic updates completed. +

+
+

UpdateFail

+ 		+

+ 		+

+ Dynamic updates failed. +

+
+

UpdateBadPrereq

+ 		+

+ 		+

+ Dynamic updates rejected due to prerequisite failure. +

+
+
+
+

+Zone Maintenance Statistics Counters

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

+ Symbol +

+ 		+

+ Description +

+
+

NotifyOutv4

+ 		+

+ IPv4 notifies sent. +

+
+

NotifyOutv6

+ 		+

+ IPv6 notifies sent. +

+
+

NotifyInv4

+ 		+

+ IPv4 notifies received. +

+
+

NotifyInv6

+ 		+

+ IPv6 notifies received. +

+
+

NotifyRej

+ 		+

+ Incoming notifies rejected. +

+
+

SOAOutv4

+ 		+

+ IPv4 SOA queries sent. +

+
+

SOAOutv6

+ 		+

+ IPv6 SOA queries sent. +

+
+

AXFRReqv4

+ 		+

+ IPv4 AXFR requested. +

+
+

AXFRReqv6

+ 		+

+ IPv6 AXFR requested. +

+
+

IXFRReqv4

+ 		+

+ IPv4 IXFR requested. +

+
+

IXFRReqv6

+ 		+

+ IPv6 IXFR requested. +

+
+

XfrSuccess

+ 		+

+ Zone transfer requests succeeded. +

+
+

XfrFail

+ 		+

+ Zone transfer requests failed. +

+
+
+
+

+Resolver Statistics Counters

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

+ Symbol +

+ 		+

+ BIND8 Symbol +

+ 		+

+ Description +

+
+

Queryv4

+ 		+

SFwdQ

+ 		+

+ IPv4 queries sent. +

+
+

Queryv6

+ 		+

SFwdQ

+ 		+

+ IPv6 queries sent. +

+
+

Responsev4

+ 		+

RR

+ 		+

+ IPv4 responses received. +

+
+

Responsev6

+ 		+

RR

+ 		+

+ IPv6 responses received. +

+
+

NXDOMAIN

+ 		+

RNXD

+ 		+

+ NXDOMAIN received. +

+
+

SERVFAIL

+ 		+

RFail

+ 		+

+ SERVFAIL received. +

+
+

FORMERR

+ 		+

RFErr

+ 		+

+ FORMERR received. +

+
+

OtherError

+ 		+

RErr

+ 		+

+ Other errors received. +

+
+

EDNS0Fail

+ 		+

+ 		+

+ EDNS(0) query failures. +

+
+

Mismatch

+ 		+

RDupR

+ 		+

+ Mismatch responses received. +

+
+

Truncated

+ 		+

+ 		+

+ Truncated responses received. +

+
+

Lame

+ 		+

RLame

+ 		+

+ Lame delegations received. +

+
+

Retry

+ 		+

SDupQ

+ 		+

+ Query retries performed. +

+
+

GlueFetchv4

+ 		+

SSysQ

+ 		+

+ IPv4 NS address fetches invoked. +

+
+

GlueFetchv6

+ 		+

SSysQ

+ 		+

+ IPv6 NS address fetches invoked. +

+
+

GlueFetchv4Fail

+ 		+

+ 		+

+ IPv4 NS address fetch failed. +

+
+

GlueFetchv6Fail

+ 		+

+ 		+

+ IPv6 NS address fetch failed. +

+
+

ValAttempt

+ 		+

+ 		+

+ DNSSEC validation attempted. +

+
+

ValOk

+ 		+

+ 		+

+ DNSSEC validation succeeded. +

+
+

ValNegOk

+ 		+

+ 		+

+ DNSSEC validation on negative information succeeded. +

+
+

ValFail

+ 		+

+ 		+

+ DNSSEC validation failed. +

+
+
+
+

+Compatibility with BIND 8 Counters

+

+ Most statistics counters that were available + in BIND 8 are also supported in + BIND 9 as shown in the above tables. + Here are notes about other counters that do not appear + in these tables. +

+
+
RFwdR,SFwdR
+

+ These counters are not supported + because BIND 9 does not adopt + the notion of forwarding + as BIND 8 did. +

+
RAXFR
+

+ This counter is accessible in the Incoming Queries section. +

+
RIQ
+

+ This counter is accessible in the Incoming Requests section. +

+
ROpts
+

+ This counter is not supported + because BIND 9 does not care + about IP options in the first place. +

+
SErr
+

+ This counter could be implemented, but is not yet + supported. +

+
+
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 5. The BIND 9 Lightweight Resolver Home Chapter 7. BIND 9 Security Considerations
+
+ + diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html new file mode 100644 index 0000000..c973734 --- /dev/null +++ b/doc/arm/Bv9ARM.ch07.html @@ -0,0 +1,254 @@ + + + + + +Chapter 7. BIND 9 Security Considerations + + + + + + + +
+ + + + + + + +
Chapter 7. BIND 9 Security Considerations
+Prev   Next +
+
+
+
+

+Chapter 7. BIND 9 Security Considerations

+
+

Table of Contents

+
+
Access Control Lists
+
Chroot and Setuid
+
+
The chroot Environment
+
Using the setuid Function
+
+
Dynamic Update Security
+
+
+
+

+Access Control Lists

+

+ Access Control Lists (ACLs), are address match lists that + you can set up and nickname for future use in allow-notify, + allow-query, allow-query-on, + allow-recursion, allow-recursion-on, + blackhole, allow-transfer, + etc. +

+

+ Using ACLs allows you to have finer control over who can access + your name server, without cluttering up your config files with huge + lists of IP addresses. +

+

+ It is a good idea to use ACLs, and to + control access to your server. Limiting access to your server by + outside parties can help prevent spoofing and denial of service (DoS) attacks against + your server. +

+

+ Here is an example of how to properly apply ACLs: +

+
+// Set up an ACL named "bogusnets" that will block RFC1918 space
+// and some reserved space, which is commonly used in spoofing attacks.
+acl bogusnets {
+        0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3;
+        10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
+};
+
+// Set up an ACL called our-nets. Replace this with the real IP numbers.
+acl our-nets { x.x.x.x/24; x.x.x.x/21; };
+options {
+  ...
+  ...
+  allow-query { our-nets; };
+  allow-recursion { our-nets; };
+  ...
+  blackhole { bogusnets; };
+  ...
+};
+
+zone "example.com" {
+  type master;
+  file "m/example.com";
+  allow-query { any; };
+};
+
+

+ This allows recursive queries of the server from the outside + unless recursion has been previously disabled. +

+

+ For more information on how to use ACLs to protect your server, + see the AUSCERT advisory at: +

+

+ ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos +

+
+
+

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

+

+ Another useful feature in the UNIX version of BIND is the + ability to run the daemon as an unprivileged user ( -u user ). + We suggest running as an unprivileged user when using the chroot feature. +

+

+ Here is an example command line to load BIND in a chroot sandbox, + /var/named, and to run named setuid to + user 202: +

+

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

+
+

+The chroot Environment

+

+ In order for a chroot environment + to + work properly in a particular directory + (for example, /var/named), + you will need to set up an environment that includes everything + BIND needs to run. + From BIND's point of view, /var/named is + the root of the filesystem. You will need to adjust the values of + options like + like directory and pid-file to account + for this. +

+

+ Unlike with earlier versions of BIND, you typically will + not need to compile named + statically nor install shared libraries under the new root. + However, depending on your operating system, you may need + to set up things like + /dev/zero, + /dev/random, + /dev/log, and + /etc/localtime. +

+
+
+

+Using the setuid Function

+

+ Prior to running the named daemon, + use + the touch utility (to change file + access and + modification times) or the chown + utility (to + set the user id and/or group id) on files + to which you want BIND + to write. +

+
+

Note

+ Note that if the named daemon is running as an + unprivileged user, it will not be able to bind to new restricted + ports if the server is reloaded. +
+
+
+
+

+Dynamic Update Security

+

+ Access to the dynamic + update facility should be strictly limited. In earlier versions of + BIND, the only way to do this was + based on the IP + address of the host requesting the update, by listing an IP address + or + network prefix in the allow-update + zone option. + This method is insecure since the source address of the update UDP + packet + is easily forged. Also note that if the IP addresses allowed by the + allow-update option include the + address of a slave + server which performs forwarding of dynamic updates, the master can + be + trivially attacked by sending the update to the slave, which will + forward it to the master with its own source IP address causing the + master to approve it without question. +

+

+ For these reasons, we strongly recommend that updates be + cryptographically authenticated by means of transaction signatures + (TSIG). That is, the allow-update + option should + list only TSIG key names, not IP addresses or network + prefixes. Alternatively, the new update-policy + option can be used. +

+

+ Some sites choose to keep all dynamically-updated DNS data + in a subdomain and delegate that subdomain to a separate zone. This + way, the top-level zone containing critical data such as the IP + addresses + of public web and mail servers need not allow dynamic update at + all. +

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 6. BIND 9 Configuration Reference Home Chapter 8. Troubleshooting
+
+ + diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html new file mode 100644 index 0000000..d25df0b --- /dev/null +++ b/doc/arm/Bv9ARM.ch08.html @@ -0,0 +1,139 @@ + + + + + +Chapter 8. Troubleshooting + + + + + + + +
+ + + + + + + +
Chapter 8. Troubleshooting
+Prev   Next +
+
+
+
+

+Chapter 8. Troubleshooting

+
+

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?

+

+ The best solution to solving installation and + configuration issues is to take preventative measures by setting + up logging files beforehand. The log files provide a + source of hints and information that can be used to figure out + what went wrong and how to fix the problem. +

+
+
+
+

+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 + represents a date, usually of the form YYYYMMDDRR. + Occasionally they will make a mistake and set them to a + "date in the future" then try to correct them by setting + them to the "current date". This causes problems because + serial numbers are used to indicate that a zone has been + updated. If the serial number on the slave server is + lower than the serial number on the master, the slave + server will attempt to update its copy of the zone. +

+

+ Setting the serial number to a lower number on the master + server than the slave server means that the slave will not perform + updates to its copy of the zone. +

+

+ The solution to this is to add 2147483647 (2^31-1) to the + number, reload the zone and make sure all slaves have updated to + the new zone serial number, then reset the number to what you want + it to be, and reload the zone again. +

+
+
+

+Where Can I Get Help?

+

+ The Internet Systems Consortium + (ISC) offers a wide range + of support and service agreements for BIND and DHCP servers. Four + levels of premium support are available and each level includes + support for all ISC programs, + significant discounts on products + and training, and a recognized priority on bug fixes and + non-funded feature requests. In addition, ISC offers a standard + support agreement package which includes services ranging from bug + fix announcements to remote support. It also includes training in + BIND and DHCP. +

+

+ To discuss arrangements for support, contact + info@isc.org or visit the + ISC web page at + http://www.isc.org/services/support/ + to read more. +

+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 7. BIND 9 Security Considerations Home Appendix A. Appendices
+
+ + diff --git a/doc/arm/Bv9ARM.ch09.html b/doc/arm/Bv9ARM.ch09.html new file mode 100644 index 0000000..f16f4c6 --- /dev/null +++ b/doc/arm/Bv9ARM.ch09.html @@ -0,0 +1,630 @@ + + + + + +Appendix A. Appendices + + + + + + + +
+ + + + + + + +
Appendix A. Appendices
+Prev   Next +
+
+
+
+

+Appendix A. Appendices

+
+

Table of Contents

+
+
Acknowledgments
+
A Brief History of the DNS and BIND
+
General DNS Reference Information
+
IPv6 addresses (AAAA)
+
Bibliography (and Suggested Reading)
+
+
Request for Comments (RFCs)
+
Internet Drafts
+
Other Documents About BIND
+
+
+
+
+

+Acknowledgments

+
+

+A Brief History of the DNS and BIND +

+

+ Although the "official" beginning of the Domain Name + System occurred in 1984 with the publication of RFC 920, the + core of the new system was described in 1983 in RFCs 882 and + 883. From 1984 to 1987, the ARPAnet (the precursor to today's + Internet) became a testbed of experimentation for developing the + new naming/addressing scheme in a rapidly expanding, + operational network environment. New RFCs were written and + published in 1987 that modified the original documents to + incorporate improvements based on the working model. RFC 1034, + "Domain Names-Concepts and Facilities", and RFC 1035, "Domain + Names-Implementation and Specification" were published and + became the standards upon which all DNS implementations are + built. +

+

+ The first working domain name server, called "Jeeves", was + written in 1983-84 by Paul Mockapetris for operation on DEC + Tops-20 + machines located at the University of Southern California's + Information + Sciences Institute (USC-ISI) and SRI International's Network + Information + Center (SRI-NIC). A DNS server for + Unix machines, the Berkeley Internet + Name Domain (BIND) package, was + written soon after by a group of + graduate students at the University of California at Berkeley + under + a grant from the US Defense Advanced Research Projects + Administration + (DARPA). +

+

+ Versions of BIND through + 4.8.3 were maintained by the Computer + Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark + Painter, David Riggle and Songnian Zhou made up the initial BIND + project team. After that, additional work on the software package + was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment + Corporation + employee on loan to the CSRG, worked on BIND for 2 years, from 1985 + to 1987. Many other people also contributed to BIND development + during that time: Doug Kingston, Craig Partridge, Smoot + Carl-Mitchell, + Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently + handled by Mike Karels and Øivind Kure. +

+

+ BIND versions 4.9 and 4.9.1 were + released by Digital Equipment + Corporation (now Compaq Computer Corporation). Paul Vixie, then + a DEC employee, became BIND's + primary caretaker. He was assisted + by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan + Beecher, Andrew + Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat + Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe + Wolfhugel, and others. +

+

+ In 1994, BIND version 4.9.2 was sponsored by + Vixie Enterprises. Paul + Vixie became BIND's principal + architect/programmer. +

+

+ BIND versions from 4.9.3 onward + have been developed and maintained + by the Internet Systems Consortium and its predecessor, + the Internet Software Consortium, with support being provided + by ISC's sponsors. +

+

+ As co-architects/programmers, Bob Halley and + Paul Vixie released the first production-ready version of + BIND version 8 in May 1997. +

+

+ BIND version 9 was released in September 2000 and is a + major rewrite of nearly all aspects of the underlying + 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 development work is made + possible today by the sponsorship + of several corporations, and by the tireless work efforts of + numerous individuals. +

+
+
+
+

+General DNS Reference Information

+
+

+IPv6 addresses (AAAA)

+

+ IPv6 addresses are 128-bit identifiers for interfaces and + sets of interfaces which were introduced in the DNS to facilitate + scalable Internet routing. There are three types of addresses: Unicast, + an identifier for a single interface; + Anycast, + an identifier for a set of interfaces; and Multicast, + an identifier for a set of interfaces. Here we describe the global + Unicast address scheme. For more information, see RFC 3587, + "Global Unicast Address Format." +

+

+ IPv6 unicast addresses consist of a + global routing prefix, a + subnet identifier, and an + interface identifier. +

+

+ The global routing prefix is provided by the + upstream provider or ISP, and (roughly) corresponds to the + IPv4 network section + of the address range. + + The subnet identifier is for local subnetting, much the + same as subnetting an + IPv4 /16 network into /24 subnets. + + The interface identifier is the address of an individual + interface on a given network; in IPv6, addresses belong to + interfaces rather than to machines. +

+

+ The subnetting capability of IPv6 is much more flexible than + that of IPv4: subnetting can be carried out on bit boundaries, + in much the same way as Classless InterDomain Routing + (CIDR), and the DNS PTR representation ("nibble" format) + makes setting up reverse zones easier. +

+

+ The Interface Identifier must be unique on the local link, + and is usually generated automatically by the IPv6 + implementation, although it is usually possible to + override the default setting if necessary. A typical IPv6 + address might look like: + 2001:db8:201:9:a00:20ff:fe81:2b32 +

+

+ IPv6 address specifications often contain long strings + of zeros, so the architects have included a shorthand for + specifying + them. The double colon (`::') indicates the longest possible + string + of zeros that can fit, and can be used only once in an address. +

+
+
+
+

+Bibliography (and Suggested Reading)

+
+

+Request for Comments (RFCs)

+

+ Specification documents for the Internet protocol suite, including + the DNS, are published as part of + the Request for Comments (RFCs) + series of technical notes. The standards themselves are defined + by the Internet Engineering Task Force (IETF) and the Internet + Engineering Steering Group (IESG). RFCs can be obtained online via FTP at: +

+

+ + ftp://www.isi.edu/in-notes/RFCxxxx.txt + +

+

+ (where xxxx is + the number of the RFC). RFCs are also available via the Web at: +

+

+ http://www.ietf.org/rfc/. +

+
+

+Bibliography

+
+

Standards

+
+

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

+
+
+

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

+
+
+

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

+
+
+
+

+Proposed Standards

+
+

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

+
+
+

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

+
+
+

[RFC1995] M. Ohta. Incremental Zone Transfer in DNS. 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.

+
+
+

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

+
+
+

[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.

+
+
+

[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.

+
+
+

[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 + Key Transaction Authentication for DNS + (GSS-TSIG). October 2003.

+
+
+
+

+DNS Security Proposed Standards

+
+

[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.

+
+
+

[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduction and Requirements. 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 + Security Extensions. March 2005.

+
+
+
+

Other Important RFCs About DNS + Implementation

+
+

[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 + Errors and Suggested Fixes. October 1993.

+
+
+

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

+
+
+

[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.

+
+
+

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

+
+
+

[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 + Domain + Name System. January 1996.

+
+
+

[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 + Distribute MIXER + Conformant Global Address Mapping. January 1998.

+
+
+

[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.

+
+
+

[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.

+
+
+

[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.

+
+
+

[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.

+
+
+

[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.

+
+
+

[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.

+
+
+
+

+DNS and the Internet

+
+

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

+
+
+

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

+
+
+

[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.

+
+
+

[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.

+
+
+
+

+DNS Operations

+
+

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

+
+
+

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

+
+
+

[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.

+
+
+

[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, + and the Other Internet protocols. May 2000.

+
+
+

[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.

+
+
+

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

+
+
+
+

Other DNS-related RFCs

+
+

Note

+

+ Note: the following list of RFCs, although + DNS-related, are not + concerned with implementing software. +

+
+
+

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

+
+
+

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

+
+
+

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

+
+
+

[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.

+
+
+

[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.

+
+
+

[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.

+
+
+
+

Obsolete and Unimplemented Experimental RFC

+
+

[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.

+
+
+

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

+
+
+
+

Obsoleted DNS Security RFCs

+
+

Note

+

+ Most of these have been consolidated into RFC4033, + RFC4034 and RFC4035 which collectively describe DNSSECbis. +

+
+
+

[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.

+
+
+

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

+
+
+

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

+
+
+

[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.

+
+
+

[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.

+
+
+

[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 + (RR) Secure Entry Point (SEP) Flag. April 2004.

+
+
+

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

+
+
+
+
+
+

+Internet Drafts

+

+ Internet Drafts (IDs) are rough-draft working documents of + the Internet Engineering Task Force. They are, in essence, RFCs + in the preliminary stages of development. Implementors are + cautioned not + to regard IDs as archival, and they should not be quoted or cited + in any formal documents unless accompanied by the disclaimer that + they are "works in progress." IDs have a lifespan of six months + after which they are deleted unless updated by their authors. +

+
+
+

+Other Documents About BIND +

+

+
+

+Bibliography

+
+

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

+
+
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Chapter 8. Troubleshooting Home Manual pages
+
+ + diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html new file mode 100644 index 0000000..3fa321a --- /dev/null +++ b/doc/arm/Bv9ARM.ch10.html @@ -0,0 +1,111 @@ + + + + + +Manual pages + + + + + + + +
+ + + + + + + +
Manual pages
+Prev   Next +
+
+
+
+
+

+Manual pages

+
+
+
+

Table of Contents

+
+
+dig — DNS lookup utility +
+
+host — DNS lookup utility +
+
+dnssec-dsfromkey — DNSSEC DS RR generation tool +
+
+dnssec-keyfromlabel — DNSSEC key generation tool +
+
+dnssec-keygen — DNSSEC key generation tool +
+
+dnssec-signzone — DNSSEC zone signing tool +
+
+named-checkconf — named configuration file syntax checking tool +
+
+named-checkzone — zone file validity checking or converting tool +
+
+named — Internet domain name server +
+
+nsupdate — Dynamic DNS update utility +
+
+rndc — name server control utility +
+
+rndc.conf — rndc configuration file +
+
+rndc-confgen — rndc key generation tool +
+
+
+
+
+
+ + + + + + + + + + + +
+Prev   Next +
Appendix A. Appendices Home dig
+
+ + diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html new file mode 100644 index 0000000..79ebc74 --- /dev/null +++ b/doc/arm/Bv9ARM.html @@ -0,0 +1,276 @@ + + + + + +BIND 9 Administrator Reference Manual + + + + + +
+ + + + + + + +
BIND 9 Administrator Reference Manual
   Next +
+
+
+
+
+
+

+BIND 9 Administrator Reference Manual

+

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

+

Copyright © 2000-2003 Internet Software Consortium.

+
+
+
+
+

Table of Contents

+
+
1. Introduction
+
+
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
+
+
+
2. BIND Resource Requirements
+
+
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
+
+
Load Balancing
+
Name Server Operations
+
+
Tools for Use With the Name Server Daemon
+
Signals
+
+
+
4. Advanced DNS Features
+
+
Notify
+
Dynamic Update
+
The journal file
+
Incremental Zone Transfers (IXFR)
+
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
+
+
TKEY
+
SIG(0)
+
DNSSEC
+
+
Generating Keys
+
Signing the Zone
+
Configuring Servers
+
+
IPv6 Support in BIND 9
+
+
Address Lookups Using AAAA Records
+
Address to Name Lookups Using Nibble Format
+
+
+
5. The BIND 9 Lightweight Resolver
+
+
The Lightweight Resolver Library
+
Running a Resolver Daemon
+
+
6. BIND 9 Configuration Reference
+
+
Configuration File Elements
+
+
Address Match Lists
+
Comment Syntax
+
+
Configuration File Grammar
+
+
acl Statement Grammar
+
acl Statement Definition and + Usage
+
controls Statement Grammar
+
controls Statement Definition and + Usage
+
include Statement Grammar
+
include Statement Definition and + Usage
+
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 + Usage
+
options Statement Grammar
+
options Statement Definition and + Usage
+
statistics-channels Statement Grammar
+
statistics-channels Statement Definition and + Usage
+
server Statement Grammar
+
server Statement Definition and + Usage
+
trusted-keys Statement Grammar
+
trusted-keys Statement Definition + and Usage
+
view Statement Grammar
+
view Statement Definition and Usage
+
zone + Statement Grammar
+
zone Statement Definition and Usage
+
+
Zone File
+
+
Types of Resource Records and When to Use Them
+
Discussion of MX Records
+
Setting TTLs
+
Inverse Mapping in IPv4
+
Other Zone File Directives
+
BIND Master File Extension: the $GENERATE Directive
+
Additional File Formats
+
+
BIND9 Statistics
+
Statistics Counters
+
+
7. BIND 9 Security Considerations
+
+
Access Control Lists
+
Chroot and Setuid
+
+
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?
+
+
A. Appendices
+
+
Acknowledgments
+
A Brief History of the DNS and BIND
+
General DNS Reference Information
+
IPv6 addresses (AAAA)
+
Bibliography (and Suggested Reading)
+
+
Request for Comments (RFCs)
+
Internet Drafts
+
Other Documents About BIND
+
+
+
I. Manual pages
+
+
+dig — DNS lookup utility +
+
+host — DNS lookup utility +
+
+dnssec-dsfromkey — DNSSEC DS RR generation tool +
+
+dnssec-keyfromlabel — DNSSEC key generation tool +
+
+dnssec-keygen — DNSSEC key generation tool +
+
+dnssec-signzone — DNSSEC zone signing tool +
+
+named-checkconf — named configuration file syntax checking tool +
+
+named-checkzone — zone file validity checking or converting tool +
+
+named — Internet domain name server +
+
+nsupdate — Dynamic DNS update utility +
+
+rndc — name server control utility +
+
+rndc.conf — rndc configuration file +
+
+rndc-confgen — rndc key generation tool +
+
+
+
+
+
+
+ + + + + + + + + + + +
   Next +
   Chapter 1. Introduction
+
+ + diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf new file mode 100755 index 0000000..b56a05d --- /dev/null +++ b/doc/arm/Bv9ARM.pdf @@ -0,0 +1,14133 @@ +%PDF-1.4 +5 0 obj +<< /S /GoTo /D (chapter.1) >> +endobj +8 0 obj +(1 Introduction) +endobj +9 0 obj +<< /S /GoTo /D (section.1.1) >> +endobj +12 0 obj +(1.1 Scope of Document) +endobj +13 0 obj +<< /S /GoTo /D (section.1.2) >> +endobj +16 0 obj +(1.2 Organization of This Document) +endobj +17 0 obj +<< /S /GoTo /D (section.1.3) >> +endobj +20 0 obj +(1.3 Conventions Used in This Document) +endobj +21 0 obj +<< /S /GoTo /D (section.1.4) >> +endobj +24 0 obj +(1.4 The Domain Name System \(DNS\)) +endobj +25 0 obj +<< /S /GoTo /D (subsection.1.4.1) >> +endobj +28 0 obj +(1.4.1 DNS Fundamentals) +endobj +29 0 obj +<< /S /GoTo /D (subsection.1.4.2) >> +endobj +32 0 obj +(1.4.2 Domains and Domain Names) +endobj +33 0 obj +<< /S /GoTo /D (subsection.1.4.3) >> +endobj +36 0 obj +(1.4.3 Zones) +endobj +37 0 obj +<< /S /GoTo /D (subsection.1.4.4) >> +endobj +40 0 obj +(1.4.4 Authoritative Name Servers) +endobj +41 0 obj +<< /S /GoTo /D (subsubsection.1.4.4.1) >> +endobj +44 0 obj +(1.4.4.1 The Primary Master) +endobj +45 0 obj +<< /S /GoTo /D (subsubsection.1.4.4.2) >> +endobj +48 0 obj +(1.4.4.2 Slave Servers) +endobj +49 0 obj +<< /S /GoTo /D (subsubsection.1.4.4.3) >> +endobj +52 0 obj +(1.4.4.3 Stealth Servers) +endobj +53 0 obj +<< /S /GoTo /D (subsection.1.4.5) >> +endobj +56 0 obj +(1.4.5 Caching Name Servers) +endobj +57 0 obj +<< /S /GoTo /D (subsubsection.1.4.5.1) >> +endobj +60 0 obj +(1.4.5.1 Forwarding) +endobj +61 0 obj +<< /S /GoTo /D (subsection.1.4.6) >> +endobj +64 0 obj +(1.4.6 Name Servers in Multiple Roles) +endobj +65 0 obj +<< /S /GoTo /D (chapter.2) >> +endobj +68 0 obj +(2 BIND Resource Requirements) +endobj +69 0 obj +<< /S /GoTo /D (section.2.1) >> +endobj +72 0 obj +(2.1 Hardware requirements) +endobj +73 0 obj +<< /S /GoTo /D (section.2.2) >> +endobj +76 0 obj +(2.2 CPU Requirements) +endobj +77 0 obj +<< /S /GoTo /D (section.2.3) >> +endobj +80 0 obj +(2.3 Memory Requirements) +endobj +81 0 obj +<< /S /GoTo /D (section.2.4) >> +endobj +84 0 obj +(2.4 Name Server Intensive Environment Issues) +endobj +85 0 obj +<< /S /GoTo /D (section.2.5) >> +endobj +88 0 obj +(2.5 Supported Operating Systems) +endobj +89 0 obj +<< /S /GoTo /D (chapter.3) >> +endobj +92 0 obj +(3 Name Server Configuration) +endobj +93 0 obj +<< /S /GoTo /D (section.3.1) >> +endobj +96 0 obj +(3.1 Sample Configurations) +endobj +97 0 obj +<< /S /GoTo /D (subsection.3.1.1) >> +endobj +100 0 obj +(3.1.1 A Caching-only Name Server) +endobj +101 0 obj +<< /S /GoTo /D (subsection.3.1.2) >> +endobj +104 0 obj +(3.1.2 An Authoritative-only Name Server) +endobj +105 0 obj +<< /S /GoTo /D (section.3.2) >> +endobj +108 0 obj +(3.2 Load Balancing) +endobj +109 0 obj +<< /S /GoTo /D (section.3.3) >> +endobj +112 0 obj +(3.3 Name Server Operations) +endobj +113 0 obj +<< /S /GoTo /D (subsection.3.3.1) >> +endobj +116 0 obj +(3.3.1 Tools for Use With the Name Server Daemon) +endobj +117 0 obj +<< /S /GoTo /D (subsubsection.3.3.1.1) >> +endobj +120 0 obj +(3.3.1.1 Diagnostic Tools) +endobj +121 0 obj +<< /S /GoTo /D (subsubsection.3.3.1.2) >> +endobj +124 0 obj +(3.3.1.2 Administrative Tools) +endobj +125 0 obj +<< /S /GoTo /D (subsection.3.3.2) >> +endobj +128 0 obj +(3.3.2 Signals) +endobj +129 0 obj +<< /S /GoTo /D (chapter.4) >> +endobj +132 0 obj +(4 Advanced DNS Features) +endobj +133 0 obj +<< /S /GoTo /D (section.4.1) >> +endobj +136 0 obj +(4.1 Notify) +endobj +137 0 obj +<< /S /GoTo /D (section.4.2) >> +endobj +140 0 obj +(4.2 Dynamic Update) +endobj +141 0 obj +<< /S /GoTo /D (subsection.4.2.1) >> +endobj +144 0 obj +(4.2.1 The journal file) +endobj +145 0 obj +<< /S /GoTo /D (section.4.3) >> +endobj +148 0 obj +(4.3 Incremental Zone Transfers \(IXFR\)) +endobj +149 0 obj +<< /S /GoTo /D (section.4.4) >> +endobj +152 0 obj +(4.4 Split DNS) +endobj +153 0 obj +<< /S /GoTo /D (subsection.4.4.1) >> +endobj +156 0 obj +(4.4.1 Example split DNS setup) +endobj +157 0 obj +<< /S /GoTo /D (section.4.5) >> +endobj +160 0 obj +(4.5 TSIG) +endobj +161 0 obj +<< /S /GoTo /D (subsection.4.5.1) >> +endobj +164 0 obj +(4.5.1 Generate Shared Keys for Each Pair of Hosts) +endobj +165 0 obj +<< /S /GoTo /D (subsubsection.4.5.1.1) >> +endobj +168 0 obj +(4.5.1.1 Automatic Generation) +endobj +169 0 obj +<< /S /GoTo /D (subsubsection.4.5.1.2) >> +endobj +172 0 obj +(4.5.1.2 Manual Generation) +endobj +173 0 obj +<< /S /GoTo /D (subsection.4.5.2) >> +endobj +176 0 obj +(4.5.2 Copying the Shared Secret to Both Machines) +endobj +177 0 obj +<< /S /GoTo /D (subsection.4.5.3) >> +endobj +180 0 obj +(4.5.3 Informing the Servers of the Key's Existence) +endobj +181 0 obj +<< /S /GoTo /D (subsection.4.5.4) >> +endobj +184 0 obj +(4.5.4 Instructing the Server to Use the Key) +endobj +185 0 obj +<< /S /GoTo /D (subsection.4.5.5) >> +endobj +188 0 obj +(4.5.5 TSIG Key Based Access Control) +endobj +189 0 obj +<< /S /GoTo /D (subsection.4.5.6) >> +endobj +192 0 obj +(4.5.6 Errors) +endobj +193 0 obj +<< /S /GoTo /D (section.4.6) >> +endobj +196 0 obj +(4.6 TKEY) +endobj +197 0 obj +<< /S /GoTo /D (section.4.7) >> +endobj +200 0 obj +(4.7 SIG\(0\)) +endobj +201 0 obj +<< /S /GoTo /D (section.4.8) >> +endobj +204 0 obj +(4.8 DNSSEC) +endobj +205 0 obj +<< /S /GoTo /D (subsection.4.8.1) >> +endobj +208 0 obj +(4.8.1 Generating Keys) +endobj +209 0 obj +<< /S /GoTo /D (subsection.4.8.2) >> +endobj +212 0 obj +(4.8.2 Signing the Zone) +endobj +213 0 obj +<< /S /GoTo /D (subsection.4.8.3) >> +endobj +216 0 obj +(4.8.3 Configuring Servers) +endobj +217 0 obj +<< /S /GoTo /D (section.4.9) >> +endobj +220 0 obj +(4.9 IPv6 Support in BIND 9) +endobj +221 0 obj +<< /S /GoTo /D (subsection.4.9.1) >> +endobj +224 0 obj +(4.9.1 Address Lookups Using AAAA Records) +endobj +225 0 obj +<< /S /GoTo /D (subsection.4.9.2) >> +endobj +228 0 obj +(4.9.2 Address to Name Lookups Using Nibble Format) +endobj +229 0 obj +<< /S /GoTo /D (chapter.5) >> +endobj +232 0 obj +(5 The BIND 9 Lightweight Resolver) +endobj +233 0 obj +<< /S /GoTo /D (section.5.1) >> +endobj +236 0 obj +(5.1 The Lightweight Resolver Library) +endobj +237 0 obj +<< /S /GoTo /D (section.5.2) >> +endobj +240 0 obj +(5.2 Running a Resolver Daemon) +endobj +241 0 obj +<< /S /GoTo /D (chapter.6) >> +endobj +244 0 obj +(6 BIND 9 Configuration Reference) +endobj +245 0 obj +<< /S /GoTo /D (section.6.1) >> +endobj +248 0 obj +(6.1 Configuration File Elements) +endobj +249 0 obj +<< /S /GoTo /D (subsection.6.1.1) >> +endobj +252 0 obj +(6.1.1 Address Match Lists) +endobj +253 0 obj +<< /S /GoTo /D (subsubsection.6.1.1.1) >> +endobj +256 0 obj +(6.1.1.1 Syntax) +endobj +257 0 obj +<< /S /GoTo /D (subsubsection.6.1.1.2) >> +endobj +260 0 obj +(6.1.1.2 Definition and Usage) +endobj +261 0 obj +<< /S /GoTo /D (subsection.6.1.2) >> +endobj +264 0 obj +(6.1.2 Comment Syntax) +endobj +265 0 obj +<< /S /GoTo /D (subsubsection.6.1.2.1) >> +endobj +268 0 obj +(6.1.2.1 Syntax) +endobj +269 0 obj +<< /S /GoTo /D (subsubsection.6.1.2.2) >> +endobj +272 0 obj +(6.1.2.2 Definition and Usage) +endobj +273 0 obj +<< /S /GoTo /D (section.6.2) >> +endobj +276 0 obj +(6.2 Configuration File Grammar) +endobj +277 0 obj +<< /S /GoTo /D (subsection.6.2.1) >> +endobj +280 0 obj +(6.2.1 acl Statement Grammar) +endobj +281 0 obj +<< /S /GoTo /D (subsection.6.2.2) >> +endobj +284 0 obj +(6.2.2 acl Statement Definition and Usage) +endobj +285 0 obj +<< /S /GoTo /D (subsection.6.2.3) >> +endobj +288 0 obj +(6.2.3 controls Statement Grammar) +endobj +289 0 obj +<< /S /GoTo /D (subsection.6.2.4) >> +endobj +292 0 obj +(6.2.4 controls Statement Definition and Usage) +endobj +293 0 obj +<< /S /GoTo /D (subsection.6.2.5) >> +endobj +296 0 obj +(6.2.5 include Statement Grammar) +endobj +297 0 obj +<< /S /GoTo /D (subsection.6.2.6) >> +endobj +300 0 obj +(6.2.6 include Statement Definition and Usage) +endobj +301 0 obj +<< /S /GoTo /D (subsection.6.2.7) >> +endobj +304 0 obj +(6.2.7 key Statement Grammar) +endobj +305 0 obj +<< /S /GoTo /D (subsection.6.2.8) >> +endobj +308 0 obj +(6.2.8 key Statement Definition and Usage) +endobj +309 0 obj +<< /S /GoTo /D (subsection.6.2.9) >> +endobj +312 0 obj +(6.2.9 logging Statement Grammar) +endobj +313 0 obj +<< /S /GoTo /D (subsection.6.2.10) >> +endobj +316 0 obj +(6.2.10 logging Statement Definition and Usage) +endobj +317 0 obj +<< /S /GoTo /D (subsubsection.6.2.10.1) >> +endobj +320 0 obj +(6.2.10.1 The channel Phrase) +endobj +321 0 obj +<< /S /GoTo /D (subsubsection.6.2.10.2) >> +endobj +324 0 obj +(6.2.10.2 The category Phrase) +endobj +325 0 obj +<< /S /GoTo /D (subsection.6.2.11) >> +endobj +328 0 obj +(6.2.11 lwres Statement Grammar) +endobj +329 0 obj +<< /S /GoTo /D (subsection.6.2.12) >> +endobj +332 0 obj +(6.2.12 lwres Statement Definition and Usage) +endobj +333 0 obj +<< /S /GoTo /D (subsection.6.2.13) >> +endobj +336 0 obj +(6.2.13 masters Statement Grammar) +endobj +337 0 obj +<< /S /GoTo /D (subsection.6.2.14) >> +endobj +340 0 obj +(6.2.14 masters Statement Definition and Usage) +endobj +341 0 obj +<< /S /GoTo /D (subsection.6.2.15) >> +endobj +344 0 obj +(6.2.15 options Statement Grammar) +endobj +345 0 obj +<< /S /GoTo /D (subsection.6.2.16) >> +endobj +348 0 obj +(6.2.16 options Statement Definition and Usage) +endobj +349 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.1) >> +endobj +352 0 obj +(6.2.16.1 Boolean Options) +endobj +353 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.2) >> +endobj +356 0 obj +(6.2.16.2 Forwarding) +endobj +357 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.3) >> +endobj +360 0 obj +(6.2.16.3 Dual-stack Servers) +endobj +361 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.4) >> +endobj +364 0 obj +(6.2.16.4 Access Control) +endobj +365 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.5) >> +endobj +368 0 obj +(6.2.16.5 Interfaces) +endobj +369 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.6) >> +endobj +372 0 obj +(6.2.16.6 Query Address) +endobj +373 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.7) >> +endobj +376 0 obj +(6.2.16.7 Zone Transfers) +endobj +377 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.8) >> +endobj +380 0 obj +(6.2.16.8 UDP Port Lists) +endobj +381 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.9) >> +endobj +384 0 obj +(6.2.16.9 Operating System Resource Limits) +endobj +385 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.10) >> +endobj +388 0 obj +(6.2.16.10 Server Resource Limits) +endobj +389 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.11) >> +endobj +392 0 obj +(6.2.16.11 Periodic Task Intervals) +endobj +393 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.12) >> +endobj +396 0 obj +(6.2.16.12 Topology) +endobj +397 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.13) >> +endobj +400 0 obj +(6.2.16.13 The sortlist Statement) +endobj +401 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.14) >> +endobj +404 0 obj +(6.2.16.14 RRset Ordering) +endobj +405 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.15) >> +endobj +408 0 obj +(6.2.16.15 Tuning) +endobj +409 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.16) >> +endobj +412 0 obj +(6.2.16.16 Built-in server information zones) +endobj +413 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.17) >> +endobj +416 0 obj +(6.2.16.17 Built-in Empty Zones) +endobj +417 0 obj +<< /S /GoTo /D (subsubsection.6.2.16.18) >> +endobj +420 0 obj +(6.2.16.18 Additional Section Caching) +endobj +421 0 obj +<< /S /GoTo /D (subsection.6.2.17) >> +endobj +424 0 obj +(6.2.17 statistics-channels Statement Grammar) +endobj +425 0 obj +<< /S /GoTo /D (subsection.6.2.18) >> +endobj +428 0 obj +(6.2.18 statistics-channels Statement Definition and Usage) +endobj +429 0 obj +<< /S /GoTo /D (subsection.6.2.19) >> +endobj +432 0 obj +(6.2.19 server Statement Grammar) +endobj +433 0 obj +<< /S /GoTo /D (subsection.6.2.20) >> +endobj +436 0 obj +(6.2.20 server Statement Definition and Usage) +endobj +437 0 obj +<< /S /GoTo /D (subsection.6.2.21) >> +endobj +440 0 obj +(6.2.21 trusted-keys Statement Grammar) +endobj +441 0 obj +<< /S /GoTo /D (subsection.6.2.22) >> +endobj +444 0 obj +(6.2.22 trusted-keys Statement Definition and Usage) +endobj +445 0 obj +<< /S /GoTo /D (subsection.6.2.23) >> +endobj +448 0 obj +(6.2.23 view Statement Grammar) +endobj +449 0 obj +<< /S /GoTo /D (subsection.6.2.24) >> +endobj +452 0 obj +(6.2.24 view Statement Definition and Usage) +endobj +453 0 obj +<< /S /GoTo /D (subsection.6.2.25) >> +endobj +456 0 obj +(6.2.25 zone Statement Grammar) +endobj +457 0 obj +<< /S /GoTo /D (subsection.6.2.26) >> +endobj +460 0 obj +(6.2.26 zone Statement Definition and Usage) +endobj +461 0 obj +<< /S /GoTo /D (subsubsection.6.2.26.1) >> +endobj +464 0 obj +(6.2.26.1 Zone Types) +endobj +465 0 obj +<< /S /GoTo /D (subsubsection.6.2.26.2) >> +endobj +468 0 obj +(6.2.26.2 Class) +endobj +469 0 obj +<< /S /GoTo /D (subsubsection.6.2.26.3) >> +endobj +472 0 obj +(6.2.26.3 Zone Options) +endobj +473 0 obj +<< /S /GoTo /D (subsubsection.6.2.26.4) >> +endobj +476 0 obj +(6.2.26.4 Dynamic Update Policies) +endobj +477 0 obj +<< /S /GoTo /D (section.6.3) >> +endobj +480 0 obj +(6.3 Zone File) +endobj +481 0 obj +<< /S /GoTo /D (subsection.6.3.1) >> +endobj +484 0 obj +(6.3.1 Types of Resource Records and When to Use Them) +endobj +485 0 obj +<< /S /GoTo /D (subsubsection.6.3.1.1) >> +endobj +488 0 obj +(6.3.1.1 Resource Records) +endobj +489 0 obj +<< /S /GoTo /D (subsubsection.6.3.1.2) >> +endobj +492 0 obj +(6.3.1.2 Textual expression of RRs) +endobj +493 0 obj +<< /S /GoTo /D (subsection.6.3.2) >> +endobj +496 0 obj +(6.3.2 Discussion of MX Records) +endobj +497 0 obj +<< /S /GoTo /D (subsection.6.3.3) >> +endobj +500 0 obj +(6.3.3 Setting TTLs) +endobj +501 0 obj +<< /S /GoTo /D (subsection.6.3.4) >> +endobj +504 0 obj +(6.3.4 Inverse Mapping in IPv4) +endobj +505 0 obj +<< /S /GoTo /D (subsection.6.3.5) >> +endobj +508 0 obj +(6.3.5 Other Zone File Directives) +endobj +509 0 obj +<< /S /GoTo /D (subsubsection.6.3.5.1) >> +endobj +512 0 obj +(6.3.5.1 The \044ORIGIN Directive) +endobj +513 0 obj +<< /S /GoTo /D (subsubsection.6.3.5.2) >> +endobj +516 0 obj +(6.3.5.2 The \044INCLUDE Directive) +endobj +517 0 obj +<< /S /GoTo /D (subsubsection.6.3.5.3) >> +endobj +520 0 obj +(6.3.5.3 The \044TTL Directive) +endobj +521 0 obj +<< /S /GoTo /D (subsection.6.3.6) >> +endobj +524 0 obj +(6.3.6 BIND Master File Extension: the \044GENERATE Directive) +endobj +525 0 obj +<< /S /GoTo /D (subsection.6.3.7) >> +endobj +528 0 obj +(6.3.7 Additional File Formats) +endobj +529 0 obj +<< /S /GoTo /D (section.6.4) >> +endobj +532 0 obj +(6.4 BIND9 Statistics) +endobj +533 0 obj +<< /S /GoTo /D (subsubsection.6.4.0.1) >> +endobj +536 0 obj +(6.4.0.1 The Statistics File) +endobj +537 0 obj +<< /S /GoTo /D (subsection.6.4.1) >> +endobj +540 0 obj +(6.4.1 Statistics Counters) +endobj +541 0 obj +<< /S /GoTo /D (subsubsection.6.4.1.1) >> +endobj +544 0 obj +(6.4.1.1 Name Server Statistics Counters) +endobj +545 0 obj +<< /S /GoTo /D (subsubsection.6.4.1.2) >> +endobj +548 0 obj +(6.4.1.2 Zone Maintenance Statistics Counters) +endobj +549 0 obj +<< /S /GoTo /D (subsubsection.6.4.1.3) >> +endobj +552 0 obj +(6.4.1.3 Resolver Statistics Counters) +endobj +553 0 obj +<< /S /GoTo /D (subsubsection.6.4.1.4) >> +endobj +556 0 obj +(6.4.1.4 Compatibility with BIND 8 Counters) +endobj +557 0 obj +<< /S /GoTo /D (chapter.7) >> +endobj +560 0 obj +(7 BIND 9 Security Considerations) +endobj +561 0 obj +<< /S /GoTo /D (section.7.1) >> +endobj +564 0 obj +(7.1 Access Control Lists) +endobj +565 0 obj +<< /S /GoTo /D (section.7.2) >> +endobj +568 0 obj +(7.2 Chroot and Setuid) +endobj +569 0 obj +<< /S /GoTo /D (subsection.7.2.1) >> +endobj +572 0 obj +(7.2.1 The chroot Environment) +endobj +573 0 obj +<< /S /GoTo /D (subsection.7.2.2) >> +endobj +576 0 obj +(7.2.2 Using the setuid Function) +endobj +577 0 obj +<< /S /GoTo /D (section.7.3) >> +endobj +580 0 obj +(7.3 Dynamic Update Security) +endobj +581 0 obj +<< /S /GoTo /D (chapter.8) >> +endobj +584 0 obj +(8 Troubleshooting) +endobj +585 0 obj +<< /S /GoTo /D (section.8.1) >> +endobj +588 0 obj +(8.1 Common Problems) +endobj +589 0 obj +<< /S /GoTo /D (subsection.8.1.1) >> +endobj +592 0 obj +(8.1.1 It's not working; how can I figure out what's wrong?) +endobj +593 0 obj +<< /S /GoTo /D (section.8.2) >> +endobj +596 0 obj +(8.2 Incrementing and Changing the Serial Number) +endobj +597 0 obj +<< /S /GoTo /D (section.8.3) >> +endobj +600 0 obj +(8.3 Where Can I Get Help?) +endobj +601 0 obj +<< /S /GoTo /D (appendix.A) >> +endobj +604 0 obj +(A Appendices) +endobj +605 0 obj +<< /S /GoTo /D (section.A.1) >> +endobj +608 0 obj +(A.1 Acknowledgments) +endobj +609 0 obj +<< /S /GoTo /D (subsection.A.1.1) >> +endobj +612 0 obj +(A.1.1 A Brief History of the DNS and BIND) +endobj +613 0 obj +<< /S /GoTo /D (section.A.2) >> +endobj +616 0 obj +(A.2 General DNS Reference Information) +endobj +617 0 obj +<< /S /GoTo /D (subsection.A.2.1) >> +endobj +620 0 obj +(A.2.1 IPv6 addresses \(AAAA\)) +endobj +621 0 obj +<< /S /GoTo /D (section.A.3) >> +endobj +624 0 obj +(A.3 Bibliography \(and Suggested Reading\)) +endobj +625 0 obj +<< /S /GoTo /D (subsection.A.3.1) >> +endobj +628 0 obj +(A.3.1 Request for Comments \(RFCs\)) +endobj +629 0 obj +<< /S /GoTo /D (subsection.A.3.2) >> +endobj +632 0 obj +(A.3.2 Internet Drafts) +endobj +633 0 obj +<< /S /GoTo /D (subsection.A.3.3) >> +endobj +636 0 obj +(A.3.3 Other Documents About BIND) +endobj +637 0 obj +<< /S /GoTo /D (appendix.B) >> +endobj +640 0 obj +(B Manual pages) +endobj +641 0 obj +<< /S /GoTo /D (section.B.1) >> +endobj +644 0 obj +(B.1 dig) +endobj +645 0 obj +<< /S /GoTo /D (section.B.2) >> +endobj +648 0 obj +(B.2 host) +endobj +649 0 obj +<< /S /GoTo /D (section.B.3) >> +endobj +652 0 obj +(B.3 dnssec-dsfromkey) +endobj +653 0 obj +<< /S /GoTo /D (section.B.4) >> +endobj +656 0 obj +(B.4 dnssec-keyfromlabel) +endobj +657 0 obj +<< /S /GoTo /D (section.B.5) >> +endobj +660 0 obj +(B.5 dnssec-keygen) +endobj +661 0 obj +<< /S /GoTo /D (section.B.6) >> +endobj +664 0 obj +(B.6 dnssec-signzone) +endobj +665 0 obj +<< /S /GoTo /D (section.B.7) >> +endobj +668 0 obj +(B.7 named-checkconf) +endobj +669 0 obj +<< /S /GoTo /D (section.B.8) >> +endobj +672 0 obj +(B.8 named-checkzone) +endobj +673 0 obj +<< /S /GoTo /D (section.B.9) >> +endobj +676 0 obj +(B.9 named) +endobj +677 0 obj +<< /S /GoTo /D (section.B.10) >> +endobj +680 0 obj +(B.10 nsupdate) +endobj +681 0 obj +<< /S /GoTo /D (section.B.11) >> +endobj +684 0 obj +(B.11 rndc) +endobj +685 0 obj +<< /S /GoTo /D (section.B.12) >> +endobj +688 0 obj +(B.12 rndc.conf) +endobj +689 0 obj +<< /S /GoTo /D (section.B.13) >> +endobj +692 0 obj +(B.13 rndc-confgen) +endobj +693 0 obj +<< /S /GoTo /D [694 0 R /FitH ] >> +endobj +697 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 +694 0 obj << +/Type /Page +/Contents 697 0 R +/Resources 696 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 703 0 R +>> endobj +695 0 obj << +/Type /XObject +/Subtype /Form +/FormType 1 +/PTEX.FileName (./isc-logo.pdf) +/PTEX.PageNumber 1 +/PTEX.InfoDict 704 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 705 0 R +/R9 706 0 R +/R11 707 0 R +/R13 708 0 R +>>/ExtGState << +/R17 709 0 R +/R8 710 0 R +>>/Font << /R19 711 0 R >> +>> +/Length 712 0 R +/Filter /FlateDecode +>> +stream +xœu˜;“d9…ýû+®Ùe´R©— lG`XËkz#†10gwÙ~6ßÉ[53}+ˆ}tI%åóäÉT½ßs*{Ö?·¿××í'¿ûŸ?lï·¼Ÿ#5Û_7}÷n³æ3õùæóýÌ»íwû7\^ûõÃVö×oøÿ_·ÒvþmÕSéœmqöÚ¾æh)ŸÏŽ™,ײ—Zjj•ÅVÊ•ëµÍÔÆn¹§±†Ö5͵[+i6}Ÿk’¨Í–§ºØ±ÖRöÝVIƒ e´Ä¶yKfZWTp¾ÜÏç9ùÀ–ÆŒõÒý>R_­êÂJsJƒ¥.ŸËÊiôÝ×\ +û”_g'®Û_6´§ÖØËÍ“[8føƒ”œKj“È4­¹¯5Ã#6ÆJ²4·œª+ÚøاkÇä~¤ž19wR7ñm¦U%s˜,ÃT| +Û2Æ‚ŒjUçq¥K"ηbøR<™¬¨™ãŸ¹×²RU| Ñ$ÞÕZ*Š–ŒCõu«|ˆhL$,I˜–¼`¥Y|ÃNżŠLó’#pÕ‹BÖŽj9-- 9@‘ €DÌ©….¶áJ{N]Á©¥Z*zÃ3…?´T®²$À“%ÁXF°Zê%.ä’@ŽO­—€!$t\'<Ž¶*W +èj˵ãB;Žþ"%«ê;¥+ßÚ)Éú¾Œ¤IJ5yÝGN>³ʧ*=5Dt'ŸtˇÀùiQ{ + ˜‚ÚIq%˜3vH­wÁKAįr‹þq n[Uz¯!*â)ôàKG°€ÝgG-dL#¹X0¹Â“@ñ´×£^ëµ½æHÕÊ_7S41Ã,ëÀO%ê*\ç/1v¢\¨Î¡¨êG´P:‘Sœ¸1ÀÞ£q‹uc¤,¯J¶”e— '‚; F/É&N(AWÖšNfãÀŠq‚ì’htËØ“ªØOàÙ‰GÎ4óHD'ª:SÙ#Oœ™äD4Ltæª3—=Ý™pÂSè¬F$_)^"åÛ•.ªd­Ôd´ÁJŒÓ¤¨,à}‹F:IòP<Á:‚é¡û½¶H­JŒŒÀvÎ9±”8G +%S}8\Ž»Ä{!•pŸj yî8NíÖL-»Ä¼1_yk¦“ˆÔøèus‘#¸W™˜ÁAŹ{0º¤Œ4±à8pª0ŠÚž]#H ªiÓºhS”28Ú*7»Å'¤«ÎwMpíD¦9d=‹rêÀ Öd ðlÎmF1Û\ÓjÍ J$¾›ƒlHO†¯,x!Fàqê*i!ߪ ‰ ž£‘\·î"o6,âM(¨$‡^êP^Å>˜³ ÔV¬ˆ¦#Z†ª¼§?Áj¹“LÃ¥R»š¨¦VÅo€Ž –eõT¥ Ø€ùU¢ÙÜ* „2ÊNvÊ@ÈËY#E?°+êEn£±¦h“ÊFØläƒbY3Âc0CEW'ñÖÆ4€»Öm"ŒÙ©˜94A¬#—ª Áõ¢ÙëN)ÅZþÅÖ…µˆ‘ç#µxì‡Ð:Å ÑqYŠ¢ŽÞ\U¢ÜÆÕ²hb \´ÑP£’šð¢>Ô9Ž¨Ñ¸ˆùUm!‰§¢Zh!ú‹~(Ât~¿ÙA,«×>*"œD0QEuÑ|Îóî`‰ö™%„U™&2WjDó5EŠ)€®äò.º‡Õ…]Ó8¡º ú5Q«­"Y;¨¢©j%R]»nG¿'ŠAU‚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 +704 0 obj +<< +/Producer (AFPL Ghostscript 8.51) +/CreationDate (D:20050606145621) +/ModDate (D:20050606145621) +/Title (Alternate-ISC-logo-v2.ai) +/Creator (Adobe Illustrator\(R\) 11) +/Author (Douglas E. Appelt) +>> +endobj +705 0 obj +[/Separation/PANTONE#201805#20C/DeviceCMYK 713 0 R] +endobj +706 0 obj +[/Separation/PANTONE#207506#20C/DeviceCMYK 714 0 R] +endobj +707 0 obj +[/Separation/PANTONE#20301#20C/DeviceCMYK 715 0 R] +endobj +708 0 obj +[/Separation/PANTONE#20871#20C/DeviceCMYK 716 0 R] +endobj +709 0 obj +<< +/Type /ExtGState +/SA true +>> +endobj +710 0 obj +<< +/Type /ExtGState +/OPM 1 +>> +endobj +711 0 obj +<< +/BaseFont /NVXWCK#2BTrajanPro-Bold +/FontDescriptor 717 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 718 0 R +/Subtype /Type1 +>> +endobj +712 0 obj +2362 +endobj +713 0 obj +<< +/Filter /FlateDecode +/FunctionType 4 +/Domain [ 0 1] +/Range [ 0 1 0 1 0 1 0 1] +/Length 39 +>> +stream +xœ«N)-P0PÈ-ÍQH­HÎPsõ, QE¸zFÆ`^-=1°endstream +endobj +714 0 obj +<< +/Filter /FlateDecode +/FunctionType 4 +/Domain [ 0 1] +/Range [ 0 1 0 1 0 1 0 1] +/Length 36 +>> +stream +xœ«N)-P0PÈ-ÍQH­HÎPsõ LÑE ‘D Êk8/«endstream +endobj +715 0 obj +<< +/Filter /FlateDecode +/FunctionType 4 +/Domain [ 0 1] +/Range [ 0 1 0 1 0 1 0 1] +/Length 40 +>> +stream +xœ«N)-P0TÈ-ÍQH­HÎPq ôLLÑD\=C 0¯=D³endstream +endobj +716 0 obj +<< +/Filter /FlateDecode +/FunctionType 4 +/Domain [ 0 1] +/Range [ 0 1 0 1 0 1 0 1] +/Length 50 +>> +stream +xœ«N)-P0Ð365³TÈ-ÍQH­HÎP€Š™X ‹™›#Ä ô -,ŒÀüZ&‹ˆendstream +endobj +717 0 obj +<< +/Type /FontDescriptor +/FontName /NVXWCK#2BTrajanPro-Bold +/FontBBox [ -45 -17 923 767] +/Flags 4 +/Ascent 767 +/CapHeight 767 +/Descent -17 +/ItalicAngle 0 +/StemV 138 +/MissingWidth 500 +/CharSet (/Msmall/C/Ysmall/Nsmall/Osmall/Esmall/Rsmall/S/Ssmall/I/Tsmall/Ismall/Usmall) +/FontFile3 719 0 R +>> +endobj +718 0 obj +<< +/Type /Encoding +/BaseEncoding /WinAnsiEncoding +/Differences [ 127/Nsmall/Tsmall/Esmall/Rsmall/Ysmall/Ssmall/Msmall/Osmall/Ismall/Usmall] +>> +endobj +719 0 obj +<< +/Filter /FlateDecode +/Subtype /Type1C +/Length 2657 +>> +stream +xœ}VkpUž!!i0dHÈ:=«°î"ŠÏ*QpYWÊD@p• ‘$$ç$!a2ïžé×éîéǼ’ÌäÍC Ãû)Á]^º+–B-®k)ZˆËµîÄf‹½´J«¬ýÓÕ÷ÜÛçÜïœï|§Í¦Ì1&³Ùþdš…Ãhëôõa3NO?œ™iv¤è›…$}ت?‰´±èË,Ý®³"cqC;‘µjô=©ãuVú¨ÕxÓUîÈçðÈœCæè×éÎþŒt§Óz>Tww$Õ°,'£ÛãŸBœÐ85HqL+kc6zjœ-kŠ_ô?„>M/DãQàZçÕ çɽ»Oö| +_ÀźŠþúD…PE¸EJ‹ˆZ»`»øâ€8(ÅA…‘}Bµ´>R&+åáE ÿf­YPxïÃôñð Ìܤg~ý(qe.Ê®Fw‘›¾ä<8ò§ý“?ßúzñÛW»§Z>CšÓjùè¼9üÆûzÞƒa¸ºú=}•Úî¼ÇN7Â~â}CØ,ÎÂÖêö–îz¹ +„W +©š¤õ\ o…„ TZ +ˆõjIt!†CΞ«y|×ÓhÌ£¤åËýk?^Ø^ /ç/õùmþ ÉF'™nH P¬ÏÅÛøVf1,ƒ&‰î–ÏZ†ö‡ rÓ/±©‘Ò”=†&eàÇn+Ì„¹t [r63Î˹€ð2,TÙ¹NK½°N³çàpÎÝ1MReZò¹šDÑMV‡ƒ)v33—àþ˜ hlßµäf9.jBˆ¨"j +%zÈ2(bPÏIe†§VŠ Q +'x6FöÐQ§X)®‡ZÐg¹ßÏÆwÌk6'¾¿+ãóËV¦–ªl`Ý\‚@h†¡T.Bn·¤$tÀnv§á0¡‰Z8¦(J\¤Kò*x¯Mˆ‰ío¡Oò¤¬­EGíjk´áïú”îÒ¶ú¨3Qµ®Ýè…ô$¼èF¦ÔÀùi.?Ä1,0@ËL7?È¡Û™ Q <$Q>· :È:ꥎ=‘îÉcSþH( ‚A·î»Ñ˜§ûÒ5ÞÞP8ùØNqnLOÙTúÛ¤Qh|~üÖ +n¨`×rŽ`ëF†â|¼?C3A•‹“pJê>8Åž0`ÅUI Ó²ßÛ"à$Ö‡©®ŸÛƒÐF¼› [¸M‰m;Ðd´jëöÎ^MëŒ$”Žpç] +rHô“Nxkz¨k `(¨ñG¶³a|oð1®@‹§Þ®/ô5»úôlôJë¦`œ‰‚ +ªVŶ°  +-R¶5ðöU…¢Ëðå q¡Âª±v:#“TsOÕ¶U(G_¬xâm#¹#—ÙTpÃȤd{ód4åÌMóqŸé¦ižÏ4Õ2€3¿Ú*e%]_Nÿj6a©úâ!4æ®/Eñ@;ªªu’Ñô€pPmïSóc’ +.9,«”à%WÃ:Î-°R,6îâ ðAZbbñn d7¥¹„‘¹yL–'®C9‹O–¤~º]ÏC¾˜«Ý›ða2…¼N’º!ðóÙÆÆP¾—m5jA…šÒø8¹SLÃ4ÚÞ­…&bö‡ýn§ »H§âëâÎa„ïº÷§ßßg>ˆ¦¤+ÐÔŒô,·5£»Ð}hZ¡ÛÐDÝ¡wÍЋôú½ßè Q„ܱߪ?~²¡¨eý«ø­Ûk‘¹é ô¡•)eúÇ~Ô|À•Tqî¦c1[Ö5ÕÒæï¬Õ2ÇóàYf-ë 1‹Ë_|åç=>–fH| +&–ê„n>ÚÝ)D 6Á?Äx:ÆŸ+0Ô®GNªÃÐIDøX?ÀÙBþMþF9ßB]‚æû…÷a+æ›,„Ã=×9®Ã6ÀÆ<²SôOŒÈ*šWq»˜´ÉCbȄ̆¬"¡  +x¸ \3§gA34–ITž-‹R8õ-ǵÛö2ªWuÉ~Á!"(0Š*FÂ͢ùĨ¸SˆˆoÊQPˆ0¦šåiFäݸVN^_!Ô‚–bž "-Qy$ÑÎsªm ¥Ä¡@·âJ=Ŧ¿íÝëL ÍDËQÆTË?GúÓlRÎ$F*4’ƒð6–š\`Œª Ñ“Œôöd]˜é`û™ü9¸DijeI Û.q +ȼLçÇ<;— *X³«¥×ÛGâ_Y1ETïƒ4ˆÒ-U…_>´üØ¢æ}õï÷v¼ §ádù#¹rÛŸå¥@ÔÁ\5l…hð<8Ús·’?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 +698 0 obj << +/D [694 0 R /XYZ 85.0394 794.5015 null] +>> endobj +699 0 obj << +/D [694 0 R /XYZ 85.0394 769.5949 null] +>> endobj +696 0 obj << +/Font << /F21 702 0 R >> +/XObject << /Im1 695 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +722 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 +723 0 obj << +/D [721 0 R /XYZ 56.6929 794.5015 null] +>> endobj +720 0 obj << +/Font << /F23 726 0 R /F14 729 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +732 0 obj << +/Length 2891 +/Filter /FlateDecode +>> +stream +xÚíMsÛȆïþ¼E:p2ߎ²,{•½.K®|m( +–˜•U~}Àô )ÚB¼k¯E–¢$6ºÝž™%fÜý³Ô0®2=K2Í f¶X½à³k÷»7/„6Š­”û&òÛ¹Q)3©Lfs|‘——/þøZŠ™Ô,I1»ü4ø2’I©²ÙåÕ?ŽN«²)Êf}üÏË?uˬ´íûùln%Ó©J»wŠã¹àœ—M]]mͲ*[«g—!£³\è™M3–h.ÚPú_Ö׳þŇ­ØýûçØbBÙ½nQ²ëÞ§_HØ®S…œfîeêÒn“„Y-|X—Ã.Õ]q<—îeõ©ÿúªZlV.›Çs“fGÌ}qùz–_tö%ÿ¿Qj Ó;²}Žd¸+äîõ?CO$ Š"Òy Èšö.¶ž"é)ú©>éÑu^.ÿ›wwÔP—7Ëõc´´Jö˜QR ›“IA†)X-‚”H)¤ó@Šïµô=)Ê“âFê{€cÄ#ñq]\õ¯–å8.ÊØg È(½Éd CŠ ¬AF$ Š Òy C;t"<Ú“qyS€ê«Xx—¯üO/ÖM±ê_ÿìÞÿêÝ…ûâ¦1iÓ}žl ™“AA†(X¬t”H(¤s!%K³Ä9—“:…šEwU‹tùpâ÷$¼Þ”Wy;Dä·í˜‘ª½«Bžˆ dr2&ÈÂ+E` ƒÂ„t>`"& · ˜t#‰ŸLòò*>¾¸ß+«Ÿ%£8@Æ&〠)°"‘0(HçÜ-Tåqø{Uvbsù¬W5ß`tŒOÆ R8aE œ"aP8‘ÎN&“,3:”+]ÁÒât²inªzÙ¸Ï}±S®õ}QwsR²uIÈÚT$°!Ä–*Ù(±0$hçÂh–$I63)g©1C]ÒW& +W±ïëå*¯úoÞæ®x­]Δܫ!$j2È¢ AP ƒ¢€t>P`S–˜Ä" +¤§àâ6¿<™îÏLñ9. u“¹@†X‚‹H¤ó c™5™B\(à¢)òÛææ–g‡"dm2ÈB«B  ƒB‚t>ÔZ3cÅPC_Cœæ‹›ey=Z=¨Tì]±ùX™2+¹’øDBÀnŽ #„ì\¿‰#‰ƒB„ô>ŒJ2måPS˜PS¼®êÿäÝûUÇŠþN0_aB ÚAö&³ )6¶Ô!؈ÄA±Az†É™²z¨4¬>bë ´“þvsÛ,ïný[>T·íò7Sö™®=‚X®É0 C +†-9"qP0ìxLJÇpî­³„%ÊMh­séO³_ž¿{åE.ÖÕ¦^€äÅ¿7˺XÁÙx4]ኟ9åi‘Sîëvi£i—#Ò³ë5v¸ ]ž¬Rý .Ã1÷~üôã¨OOÿºMQ÷¢OÓ?Cßk¾ + ãGyiKnSñSî,Hîä; Rw"&Eé=l»¨Œ3-¸tBûщç¦ß¼WåíC|×åÝf{EDÈÙT"°!AÄ–&±8"hïIÊ”û.F'~Çm«'€Ãhõlú™ƒ8žÉâ#CJ|œ~JüH”ø¤w˜H\éΤ𜨰1ðç*÷¥ØËü6/])–Jsè-úR˜ ß“aB†LXO¡ÇaŠÄAÁDz0Í„0P•(r™çkü®2ÑÏç‘œßh‚ÌNÆRØ`å(l"qPØÞ‡ HKÆE%‰ +%Éåq&ªêÖŸ}ªêðxEÿâ/ÇÆ-¡÷ ¹)Æ&¦®E6/VíS<*ßÙ ù™¬>2¤ÔÇù§ÔÄA©OzgÄJºŠLê‡3âWËüº¬ÖÍrá¢x0iº‡}%A1ÈÙd"!EÖD˜q""qPDÞ"DÂRÉ3Dô \­–årÝÔ¨?Qñ»8åú*@Š&€ )°‘8(HïÄÀ K¤ …DX‘\,¯Ë¼¿ýÅ¡ý•P‚dOF R(a1Åx£{, +¥ï±D™*ÆÓ¬ŸÚ´ßH<¹ºwkØl»*òfSã=ábOÝBÄÄâVb¼_ŽÈÌ®×X±.βLôC¼[ˆïªfùÉ­ïݺGÏ“|ëeacê=ˆ ‰{pKlŠ°Hi¤÷@šIÝ°®¥}$J{Ò{Ø\‰[Aq#íÃqËɦ©Vy8mñ0ôŸ|g÷åƇôLRâãôSâGâ Ä'½â[·xæ ÒVÞæåÖAXø$5û5ðû M–°£ÔGù—ã­‘ (í)×Øo8ãÐuØjg*§ÕÝChµGèÇþ‹Â/˜}YÚT¾?¨‚Ó÷·]ã`Û•o•úÎF|ÈÍdÕ‘!%;Î=¥{$JxÒû ¼JXæ*É <|tÔyéæñUD{üØ-Ìæá·® +øƒÿÝÙ/ËuS”탙‰0ß™æ•Éš#CJsœuJóH”æ¤÷AsiX +M…­æ:h¾nêãô¨ýèá·oðÐkƒh—#öùlk…lMfR,`5("qP,Þ„b‰Ðø˜Ž~]í»=Ãמ,Åzž%húg°º +ÁîGÓäm2ƒÅREŽ7XD‚ ˆ \@pÁ,tûµDÀ'/œÕ½ÊýØø@Á_™'Hûd !E–•B*Åéö®ÒŒ‘@aaëêdz¿µÍ:ê°uõÕ¶HA‰©”!;2¬3ÁX$1Ò5–$LCK¢[ÎÂéÌù›ödŽ÷ÇršgľڀŠL% Ù¤a½ Ò"AP‡…r=|Ê?SRxÐRèWywqqvê:ûñÌ7ƒÊ'*SƒVZâï<Ž`¨ðwæ2ciìÈÛÕ÷ Ε[~©‘&Å3çë™SÿÀóøóp%ðö?ž­®Bendstream +endobj +731 0 obj << +/Type /Page +/Contents 732 0 R +/Resources 730 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 703 0 R +/Annots [ 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 745 0 R 746 0 R 747 0 R 748 0 R 749 0 R 750 0 R 751 0 R 752 0 R 753 0 R 754 0 R 755 0 R 756 0 R 757 0 R 758 0 R 759 0 R 760 0 R 761 0 R 762 0 R 763 0 R 764 0 R 765 0 R 766 0 R 767 0 R 768 0 R 769 0 R 770 0 R 771 0 R 772 0 R 773 0 R 774 0 R 775 0 R 776 0 R 777 0 R 778 0 R 779 0 R 780 0 R 781 0 R 782 0 R 783 0 R 784 0 R ] +>> endobj +735 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 +736 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 +737 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 +738 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 +739 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 +740 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 +741 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 +742 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 +743 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 +744 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 +745 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 +746 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 +747 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 +748 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 +749 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 +750 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 +751 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 +752 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 +753 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 +754 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 +755 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 +756 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 +757 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 +758 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 +759 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 +760 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 +761 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 +762 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 +763 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 +764 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 +765 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 +766 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 +767 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 +768 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 +769 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 +770 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 +771 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 +772 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 +773 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 +774 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 +775 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 +776 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 +777 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 +778 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 +779 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 +780 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 112.5583 539.579 121.5146] +/Subtype /Link +/A << /S /GoTo /D (subsection.4.5.5) >> +>> endobj +781 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 +782 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 +783 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 +784 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 +733 0 obj << +/D [731 0 R /XYZ 85.0394 794.5015 null] +>> endobj +734 0 obj << +/D [731 0 R /XYZ 85.0394 711.9273 null] +>> endobj +730 0 obj << +/Font << /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +787 0 obj << +/Length 3167 +/Filter /FlateDecode +>> +stream +xÚí[wÛ6Çßý)ôh?‹ûå1מvw“4q_¶ÛVfJ¢W’›Í~úEZàÈØ­ÓØ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õï‹©pê´´zPb*KA†(©Prq  àÞ(–m ð”—u[‡VóT…ªÕUè{«ëvuþ[˜éUö˜¥b€!ÆTAˆq2q`  Þûº¢ %Zy<®²/Û™F¿ŠÚÊšÓ¨¢ÒYŒ +0ÄPra¨dâÀPA½§áBY¢™3 –S]ù_A ©,b @©0P2q`  Þ(ReSsãA9Õ•}B–Š†P!ÇÈÄ1€zý­mÑ¡°ðûõ·ß­«å²jWŒ8µ·wp -Æb¸@Å0\2q`¸ ÞÃ4„s¢¸ •¥­+ÞýÁˆµTzíQÕlÑ3‚áŒÛþ˜Ûj[§iL¤Ëp{êc΋y†OPS¡ÆyÊÄñ„z<ùÃ¥'þ8.eÖ±§7 õ©-¦&ÙaÐá0föƒÀÁ\÷ÄHg‰Ô±âDDfÖ¬¶ëf±Ép#¡LðòîICcèÄ—² x"ôäâ@ðÁ½~¬Ÿûr—*˜|0~î1…Vü1à2ÊIÈe1'Àãj%Æ·5æâÀ8A½NŒl7`GLÔALæ«ÙâöªÎQ¢‰qìÐdÇ2~Tóäábx’ÆÐCg?ŒÌuGûš¤ušÓè‡"çðøòµ¯çÿÁ›5b*‹†#P*1¾%6F ê=`¢(tRæ &¿Õ_rS__‚œ!ìiÕ7漘'`ˆñ5ÅxÊÄñ„z< KM£Ž}œ8Š>½N*¤¶˜šd‡A„ØÙCsˆážÃ2î 2‹æúºÝI–)TÆyNZÏQò¨vÆ£ 1v „<™80zPï&ýáN§¥@úPüÜc¢óçì²úÃîËbN€!Æ ÔJŒïïÎÅq‚zW™$å„Sã)íõHÛo[Þ‡FSßUË0ë}ªV«:·êç9©”î{÷i]m< ZðãšÕ„ôà 1x |<™80xPïá<,´Sí +àñÉu³ÎÍt$%Úš;ðHjªBÅô– xòI: +O.Ü{_¡„±„I *Ôá«U‹Ïë:·ÐÇ}}Š°ŒMo¸ÒG|Ý3¦»%`ˆ¡å”ã[ðrq`(¡ÞJZ{z8(aüAP:<Ó‘Ì=¡Ñ'¤µ`ˆ!eÃÉÄ!ƒzÈ(I¨eý•{ÌýUÌe1'Àãj…q’‰ãõ8í„vW‡/U57­Ô›üëÏvðR;®©MÈq1?Àãjˆñ“‰ãõøa†8«AÒÅÏ}.XÉG]B.‹9†'P+9¾q"Æ ê=µâT§$¨H:¬ã,!IÅC ãÛ{rq` ÞFM‡ã;Ñ››fÑ\û†ÁszÀIžÃbB€!FÈ@#„L!¨÷DˆfD9,¢'äÛ7~æ¸ðsÆÜ•.I(gnÿJ—°ê8nŽÉ-Fbè ÄŽc. Ô{BG:¢$ÖÙ¡óþý¦î;Š·Ý…Ž:¼äât›UÊ\1Àãb Ìøâe.Œ Ô{âB¢†}S±æÐóÛþYËúhŒSKŸÎbV’† + !e? Ìuâ„+"ÍEw <¿/¶Óðš“ èWæ«»×ÄÿiVíZ¸1îQY(Öb²<¾&™‹“õž4f‚Hy§19_-o¶_Ò;³Ú«ßÐÔÃö !IÅC ã›brq` Þ”Éô€Ûðìêj·Õ©Z„kݳô¹~QÍ>í +…Óú iÝg£Xêd‡) s=¾Ðœ ÓsÝŽ+Á=H‡oÖßø†À7óÙfÚßÀ–Û.çû\©ì¡'ƒøIÉ##ÆØI,eØ!l $ß • au^MeˆP ök°q;ñÝŸˆÂèûªúd¿®*Ùao«‚R o¸Û{Wæ:<õ_ÁAKpøNú~ΗYV ¾„èƒ7Òsó”‰ñw²ìò\þF–`†¾%ih·±Ü`øß)w^òìkHüŒ8¥øÿÿÂàô^cÙÞXfGödqK‰kßÅ%ü°"úû1‘ZvÈÿ 9†Sendstream +endobj +786 0 obj << +/Type /Page +/Contents 787 0 R +/Resources 785 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 703 0 R +/Annots [ 792 0 R 793 0 R 794 0 R 795 0 R 796 0 R 797 0 R 798 0 R 799 0 R 800 0 R 801 0 R 802 0 R 803 0 R 804 0 R 805 0 R 806 0 R 807 0 R 808 0 R 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 ] +>> endobj +792 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 +793 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 +794 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 +795 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 +796 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 +797 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 +798 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 +799 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 +800 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 +801 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 +802 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 +803 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 +804 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 +805 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 +806 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 +807 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 +808 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 545.4324 511.2325 554.5382] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.1.2.2) >> +>> endobj +809 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 +810 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 +811 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 +812 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 +813 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 +814 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 +815 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 +816 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 +817 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 +818 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 +819 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 +820 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 +821 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 +822 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 377.0886 511.2325 386.0947] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.11) >> +>> endobj +823 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 365.0569 511.2325 374.063] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.12) >> +>> endobj +824 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 353.0252 511.2325 362.0313] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.13) >> +>> endobj +825 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 340.9936 511.2325 349.9997] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.14) >> +>> endobj +826 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 328.9619 511.2325 337.968] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.15) >> +>> endobj +827 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 316.8305 511.2325 325.9363] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.16) >> +>> endobj +828 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 304.8985 511.2325 313.9046] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.1) >> +>> endobj +829 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 292.7672 511.2325 301.7235] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.2) >> +>> endobj +830 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 280.7355 511.2325 289.6918] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.3) >> +>> endobj +831 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 268.7038 511.2325 277.6601] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.4) >> +>> endobj +832 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 256.6722 511.2325 265.7779] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.5) >> +>> endobj +833 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 244.6405 511.2325 253.7462] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.6) >> +>> endobj +834 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 232.6088 511.2325 241.5651] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.7) >> +>> endobj +835 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 220.5771 511.2325 229.5334] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.8) >> +>> endobj +836 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 208.5455 511.2325 217.5017] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.9) >> +>> endobj +837 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 196.5138 511.2325 205.4701] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.10) >> +>> endobj +838 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 184.4821 511.2325 193.4384] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.11) >> +>> endobj +839 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 172.4504 511.2325 181.4067] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.12) >> +>> endobj +840 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 160.4187 511.2325 169.5245] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.13) >> +>> endobj +841 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 148.3871 511.2325 157.3433] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.14) >> +>> endobj +842 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 136.3554 511.2325 145.3117] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.15) >> +>> endobj +843 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 124.3237 511.2325 133.4295] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.16) >> +>> endobj +844 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 +845 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [499.2773 100.2604 511.2325 109.2166] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.16.18) >> +>> endobj +846 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 (subsection.6.2.17) >> +>> endobj +847 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.18) >> +>> endobj +848 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.19) >> +>> endobj +788 0 obj << +/D [786 0 R /XYZ 56.6929 794.5015 null] +>> endobj +785 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +851 0 obj << +/Length 3445 +/Filter /FlateDecode +>> +stream +xÚí[SGÇßùzHÕ½}¿ì>laÀ){1©lm’YƒÊH"º@¼Ÿ~{4ÓÝG¨ç@oÖáW +æÌ9:ÿßœ¾Îˆõ¨ÿÇzV*œì'‰¢Lõã-Ú;óï½Ùbí1»á ]xÔ«Ó­¿¾¦çˆÓ\÷N?ƒsYB­e½ÓáÏÛûïOO?îüzúÃÖái<)t̨¨ÏøÛÖÏ¿ÒÞÐûÿa‹á¬ê]û_(aÎñÞxK*A”"üåbëãÖ?ã Á»+ÓÜQÂe¹É|.À'aœëŒN9¢…¯þ(špÂiýAüá .±–Jï£>l^Í®ªY{<«ðqk­ÛÃ>.ú‹j\M;»\ÑíƒêJùd´M'Í_ú“aóâÇyÿ¬ÚÙµŽn“]Eïå‡t®Èà†ÜŠ[¢9e)£úÌÎzÍ‹¨X°Û…†›Šmž¥˜Ýˆ#‹ãõžx‘†(Eyâ…ÝÊËb¶œ/ªáî—êëáøc¨ÜFLÈi11À#fM3×ML&ŒÔ{"F("µÄðoJÌíu†+ñÈJJHa1 ÀdM"L ¨÷DXÍ âV@®FÕu .ý2ê–R¢„x0¥äÿY_îSHw1LÀƒiMN¦LL¨÷cDP `’ߦ۫Œvúñ±Ó MHk14ÀƒfM6šL4¨÷vηJ …R·2óŸé¤Ê3C3· kŸrå¹…¥íR”€BÔÒ°N2A ¡®FÖ&Eú›Pt{å1Š=æªMj1,Ñ c% fD7*`¤ ~™’ÄãzÚ(B•‘P!Ìq¼„ÿ®‰X‰yºã‡Ã_/«¹Ï|à–{("!…Å`C (G& Ô{DsâüˆÂ@ö/ús„ ü1!ñÍ9¹ —Ðb\€!† ÌÈn\2q`¸ Þ.ŠúHXˆ‹¸YOÞ_Ö-F)#Q·¹b.€!ÆTƨn.2q`\ ÞÞÀ2¶Æ…l¸8ø:éGƒ¶ßp9ô]Œæõ‡éÅh0ª[©Ô“•=$¦Xv`ˆÉoL·ì™80ÙQï¾ê¬=ÿ+1ÜwÕ}!`t­¼]øWJ¹Gß‚<èŽk¡˜1`ˆ1e6ÝCæ\c¨÷4Öa’hi"duÿ•qºÖm­Y›~n~žTóér¶Ãìö  +LWÎo c~:¯Ú‘Íb6¡S|^ýLj‡7I3R¬70Äô†ÇôÎÄézOM åDiô^).n—Ö +ö,{!aÅ8C (†C& Ô{ÄA9J¤àÀ[|àÛÕï‹eÿ¢¡¡úýrC5ŸÇ)‹XNVcýT˜§R + !BÁš–wR‹¡÷e,‘”% +xÛŒæƒeFîwÿÊy¯òß÷ÌzÌa1!À#j„’‰#õžÑ æT$D´„|¬‹Ñä¬mÕOß®8/ýËr~B†‹ù†?PAÛ=–‹ãõžøñ &ñ#[~Ž&WÕ,ô +ßõ//#L£¶æ}¸òs+^†"1‹ÅŒCŒ¨ÆH&ŒÔ{bDrÂü±‘Õ2ò~q^Ín~W )£¦[2XŒ®êáŠì9·C!‹ÅŒCŒ¨’íž!ÍÅ1‚zOýUA 50‡/~H™Y§Óþx&ÃÜwïOŽÞg–ê¤ñeŒóö¸5¤vvbOuÏZLh1.Àà +†á’‰Ãõžpa†8ÇÀ…—àrt¼ÿöǃÃÜÖ5E¨]¼pñôêJHe1(ÀJ…’‰õž@¡Š8ê (¢ßóÍ­ÿkb¥ë€ÄÜÏ´üýu^BŠ‹†@PB  L@¨÷Øy‘N<é¶óòêèø ônç‹ÐI½—ÃßÕ¤aÿÍ÷\Ý^dqcF{PUØÄöÝ›ÃãÓ½z†æ4W´ ” +™OÿIãô.bªJA€†kRØ\¸÷‚eÄH•@0-{Ãáj¯O˜NK¼žÎÆý…ï¹j£_91ÅxC (ÕÝxdâÀð@½‡5=©ÑZ„m­²]Ó«‹„k`¨w‰æ‹Ñ Þ/Ä_–ïþ0N!ãÅ8C '¨(†S& 'Ô{ì·He¼‹<º6Ú *gùsœf‹ +Æb8@Al÷Ž\¨÷ÔøHE|# a1÷&ûÓåÄ÷EêU=êžyýè$¥Íe1(Éã(…a²F æ:Õ !ˆd&AKÆqjFskh¶~$x$·Zá6Å +';LafLáÍ 0…1×IaΈÔ8í‘&PßõG^ÆI2¨nÓÙ—–‡>?r±˜ÀS¦Ôvß­›‹Óõž¥ŽpÅ¡ ìÚ¸¸Ãµj5Bµ9ä£Xm`ˆ© ó©‰SõÕÎf¨jËVíýéøÒ+üit1Z|m$¾-Λ)áÖúÆ·4Ü\»š†ÈÌP"â *ö&3Z<´ÎA1e¥@@Cˆ5Il÷.\›ÞYæ1ÂH¢™m–þëéº6¯ŽÕ`9‹TìO'óÑ°šõ›Íây §öÜ-_À`3âÍóÖ!»îÛ·àé°isØáäªYN˜Nš{Y…ϧ vr2_Ì0ĸ‚Êb\eâÀ¸B½'®êÛM\…ý¡?Îãv­üº•Ñþ ŒÅNu•5J «©¯—“AsW´4Ï¡±í„*¤½*`ˆAeÅ ÊÄA…zÍ+“„S˜ +w7uÞÏ–º·Fé—)Ë<0!§ÅÀC ¨L& ˜ ï¹QwŒhÕ>ƶ£ ÓÆØölºütQÍÏ}ûU×£®ôÄ3Üu° ÁÎZd®{ÁžIǦ×ÜõÃ#Ê´OZ±q°³?ÃnýM;íS3®óR¾ŒmŠ/©˜æÒK +"—ÔšŒ;™80†Pï±a纞$â¡Ø_våâ œûçýÉÙZ/,Â.–ãåøS=ù,´{Ýø6IÅÚG3Lú$¦üF˜ðˆß¨»Dðö(6ö³~ª·Ô§‹tÿÆeü¦j/Úï«‹KJùÒ\Ü  íb„€!TÃ(Ò†÷lŒÓzb³¤¹ç 7çÛ{——Õd8TÝsÌÑìÎÝ.`€u»`8®{…žËÁ†×ìåD½w'ÚÔ ¦1> ƒ/“éõE5<« i½ÚÆÝKg«üê É-¾z€!võ@ñ0b2q`ä Þcg‹9M4kïàÜkz[®¾„šJûj6ªÚÛk¿ÍÓÙ×õ{ncó{püñF;ݬiÊž +1Y¥(@C…51rq (àÞCaVÅ] 7EäM5©f¡_E>©>·-uܨq4ù¼Ú1¼š"Óîy­9Å܃ 10 6®{é?ê=ÕÉ”í˜{Í ~]#Ž>\éö¢ÃS³Y~ñº=ÿŸÿÉêE{ó²ë7汘`ˆQuÂ(ÉÄQ‚zåCS"´ +ˆ¦|¼}ºMÏfýË󯉋ØF|\žUõÃØCYéýÈ®AFpþLŠGÈ\1ÀÃ*ƒa‘‰ÃõžŠ‡ô#{ÛÞk¹×<Ë©.'ÕoK/}#¼o:ÂVˆqÛY ¬œ¼ÞŸ7@XÁŸG3¦¬`ˆ%Á€ÈÄzO@M| Þ¶&õþ®IâÌúŸk œã/ÃŒA´°&eõ®Ì´v»Ð0ÇÌÍóת1ڽ̒ ƒuŸ á’0ÖÞG¹×<ꥆ<…á`:X‚Ú±÷)Îñ6#ÅžzùR…\£ 1 ( +™@06Üçæ{eDiÓÌY¾ª[±ý®?‰»ìŸå¦}BìÁú¶iŸ˜`›ö¹yÞ&'ÝO)çÃr±á6×粎H«ÚT¬Vᶇ£³'U6Ám\-AŽÒëØ!—#,ê;pf ‘T´˜ñ³óiÝySæ…³?³VŽRÌ’BšQäûß6BÀ¾(qŸ+¬ˆà¡’‰¶’Mæój°;œnfÇ_*?ˆöûMAß Ms):É AHÈEžF~3„ tâ—QîrG¬µ¹ÆÒÿψSͽíì»/Ó7tÖ\²]ß)&¨ó‘SÙ«¿yL4׈B6Ó®‘ÿî£A{endstream +endobj +850 0 obj << +/Type /Page +/Contents 851 0 R +/Resources 849 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 703 0 R +/Annots [ 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 866 0 R 867 0 R 868 0 R 869 0 R 870 0 R 871 0 R 872 0 R 873 0 R 874 0 R 875 0 R 876 0 R 877 0 R 878 0 R 879 0 R 880 0 R 881 0 R 882 0 R 886 0 R 887 0 R 888 0 R 889 0 R 890 0 R 891 0 R 892 0 R 893 0 R 894 0 R 895 0 R 896 0 R 897 0 R 898 0 R 899 0 R 900 0 R 901 0 R 902 0 R 903 0 R 904 0 R 905 0 R 906 0 R 907 0 R 908 0 R 909 0 R 910 0 R ] +>> endobj +853 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.20) >> +>> endobj +854 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 746.3946 539.579 755.3509] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.21) >> +>> endobj +855 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 734.3125 539.579 743.2688] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.22) >> +>> endobj +856 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 722.2305 539.579 731.1868] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.23) >> +>> endobj +857 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 710.1484 539.579 719.1047] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.24) >> +>> endobj +858 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 698.1661 539.579 707.1721] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.25) >> +>> endobj +859 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 685.9843 539.579 694.9406] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.2.26) >> +>> endobj +860 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 673.9023 539.579 682.8586] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.26.1) >> +>> endobj +861 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 661.9199 539.579 670.926] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.26.2) >> +>> endobj +862 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 649.7382 539.579 658.6945] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.26.3) >> +>> endobj +863 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 637.7558 539.579 646.6124] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.2.26.4) >> +>> endobj +864 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 625.5741 539.579 634.5304] +/Subtype /Link +/A << /S /GoTo /D (section.6.3) >> +>> endobj +865 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 613.4921 539.579 622.4483] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.3.1) >> +>> endobj +866 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 601.41 539.579 610.3663] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.3.1.1) >> +>> endobj +867 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 589.328 539.579 598.2842] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.3.1.2) >> +>> endobj +868 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 577.2459 539.579 586.2022] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.3.2) >> +>> endobj +869 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 565.1639 539.579 574.1201] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.3.3) >> +>> endobj +870 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 553.0818 539.579 562.0381] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.3.4) >> +>> endobj +871 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 540.9998 539.579 550.1055] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.3.5) >> +>> endobj +872 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 528.9177 539.579 538.0235] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.3.5.1) >> +>> endobj +873 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 516.8357 539.579 525.9414] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.3.5.2) >> +>> endobj +874 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 504.7536 539.579 513.8594] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.3.5.3) >> +>> endobj +875 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 492.6716 539.579 501.6279] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.3.6) >> +>> endobj +876 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 480.5895 539.579 489.5458] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.3.7) >> +>> endobj +877 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 468.5075 539.579 477.4638] +/Subtype /Link +/A << /S /GoTo /D (section.6.4) >> +>> endobj +878 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 456.4254 539.579 465.3817] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.4.0.1) >> +>> endobj +879 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 444.3434 539.579 453.2997] +/Subtype /Link +/A << /S /GoTo /D (subsection.6.4.1) >> +>> endobj +880 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 432.2613 539.579 441.2176] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.4.1.1) >> +>> endobj +881 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 420.1793 539.579 429.1356] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.4.1.2) >> +>> endobj +882 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 408.0972 539.579 417.0535] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.4.1.3) >> +>> endobj +886 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 396.0152 539.579 404.9715] +/Subtype /Link +/A << /S /GoTo /D (subsubsection.6.4.1.4) >> +>> endobj +887 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 373.4431 539.579 382.2997] +/Subtype /Link +/A << /S /GoTo /D (chapter.7) >> +>> endobj +888 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 361.3809 539.579 370.4867] +/Subtype /Link +/A << /S /GoTo /D (section.7.1) >> +>> endobj +889 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 349.2989 539.579 358.2551] +/Subtype /Link +/A << /S /GoTo /D (section.7.2) >> +>> endobj +890 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 337.2168 539.579 346.1731] +/Subtype /Link +/A << /S /GoTo /D (subsection.7.2.1) >> +>> endobj +891 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 325.1348 539.579 334.091] +/Subtype /Link +/A << /S /GoTo /D (subsection.7.2.2) >> +>> endobj +892 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 313.0527 539.579 322.009] +/Subtype /Link +/A << /S /GoTo /D (section.7.3) >> +>> endobj +893 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 290.4806 539.579 299.2128] +/Subtype /Link +/A << /S /GoTo /D (chapter.8) >> +>> endobj +894 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 278.4184 539.579 287.3747] +/Subtype /Link +/A << /S /GoTo /D (section.8.1) >> +>> endobj +895 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 266.3364 539.579 275.2927] +/Subtype /Link +/A << /S /GoTo /D (subsection.8.1.1) >> +>> endobj +896 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 254.2544 539.579 263.2106] +/Subtype /Link +/A << /S /GoTo /D (section.8.2) >> +>> endobj +897 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 242.1723 539.579 251.1286] +/Subtype /Link +/A << /S /GoTo /D (section.8.3) >> +>> endobj +898 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 219.6002 539.579 228.3323] +/Subtype /Link +/A << /S /GoTo /D (appendix.A) >> +>> endobj +899 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 207.538 539.579 216.4943] +/Subtype /Link +/A << /S /GoTo /D (section.A.1) >> +>> endobj +900 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 195.456 539.579 204.4123] +/Subtype /Link +/A << /S /GoTo /D (subsection.A.1.1) >> +>> endobj +901 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 183.3739 539.579 192.3302] +/Subtype /Link +/A << /S /GoTo /D (section.A.2) >> +>> endobj +902 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 171.2919 539.579 180.2482] +/Subtype /Link +/A << /S /GoTo /D (subsection.A.2.1) >> +>> endobj +903 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 159.2098 539.579 168.1661] +/Subtype /Link +/A << /S /GoTo /D (section.A.3) >> +>> endobj +904 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [527.6238 147.1278 539.579 156.0841] +/Subtype /Link +/A << /S /GoTo /D (subsection.A.3.1) >> +>> endobj +905 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [522.6425 135.0457 539.579 144.1515] +/Subtype /Link +/A << /S /GoTo /D (subsection.A.3.2) >> +>> endobj +906 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [522.6425 122.9637 539.579 132.0694] +/Subtype /Link +/A << /S /GoTo /D (subsection.A.3.3) >> +>> endobj +907 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [522.6425 100.3916 539.579 109.2482] +/Subtype /Link +/A << /S /GoTo /D (appendix.B) >> +>> endobj +908 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [522.6425 88.3294 539.579 97.4352] +/Subtype /Link +/A << /S /GoTo /D (section.B.1) >> +>> endobj +909 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [522.6425 76.2474 539.579 85.3531] +/Subtype /Link +/A << /S /GoTo /D (section.B.2) >> +>> endobj +910 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [522.6425 64.1653 539.579 73.2711] +/Subtype /Link +/A << /S /GoTo /D (section.B.3) >> +>> endobj +852 0 obj << +/D [850 0 R /XYZ 85.0394 794.5015 null] +>> endobj +849 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +913 0 obj << +/Length 762 +/Filter /FlateDecode +>> +stream +xÚíÙKOÜ0à{~…»‡L=~Ï• +*q jÉ q »a[Á†–mUµ¿¾NˆƒaWá!$X¡aã±ÇžO–qÿƒL0$ˆYR 9j¶Xœ­ü½ömÊШŒ[íUÅ»iaXuÎ”Ö t×™î²jy2{ÿñ¨Ú?ªŽç§Õa±_ ½Æ##—m—?Š“SΖ>ƒ$§Ùoÿ$l](-A+)Ã7—Åqñiè0ºÛ…&g‚„4"1!£©X#ON“¿ð·Ú™ìš—$i¶l6›zQ^ÔίçèfWë˳/õå¼tœf0/5ç¯å—¢'˜Ñ½Ê+òNÈ/ê°º[¥º^±›‹ÏQñ†¸2Ü.Þvÿmõq‹`ÐJ$g';ü`GY0ÖboGß·³ª¿¾J¿21/§)¬÷dMQ`NS\OD9®)‘HNSvøA“Ô`R¯ÉÜÑ´ù¶jþ^5uëIî =RXêÉ¢À¤¸”ˆzR"‘¤ìð$!ÁãzHöRs¶®—åâk½¸X\5çóÒh±ô`Aa' Šs‚â"ºqA‰Dr‚²Ã‚Á!š^ÛÔoEz·=\PXãÉ‚¢Àœ ¸†ˆ4.(‘HNPvø ÈÓFõ‚(äÑô–ŽDÏGë?†Lf„Ý©1 +1*,•HFX~øA˜³@Ãr¿¨-±Í¯ï˳Ÿ~wÒVíx='¯P€É¼¢À¯¸À(Ô8¯D"9^Ùá^V)žíü£eÇëºY.üº·¾½€·P‘ÉÞ¢Àœ·¸â(Æ\©DrÞ²ÃÞŒ"žþ°ÛMß(ŒÚ +„ª¢mÔR„î(ßµ¼Ó«Áö”gû–;£Oê0Tj²Ã(0ç0–€büà–J$ç0;üàP àR‡‡G”·û^ÙbëÞiI”»=îiQ…eŸŒ* +Ì¡ŠËŠrüEi*‘-TËøÒ Ã…M½‹÷ÒÿæÿöÊ‚tN¤§+²’˜ÔÐöÕNÖŒNµoeþwã¹endstream +endobj +912 0 obj << +/Type /Page +/Contents 913 0 R +/Resources 911 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 703 0 R +/Annots [ 915 0 R 916 0 R 917 0 R 918 0 R 919 0 R 920 0 R 921 0 R 922 0 R 926 0 R 927 0 R ] +>> endobj +915 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 758.5763 511.2325 767.5824] +/Subtype /Link +/A << /S /GoTo /D (section.B.4) >> +>> endobj +916 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 746.5215 511.2325 755.6272] +/Subtype /Link +/A << /S /GoTo /D (section.B.5) >> +>> endobj +917 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 734.5663 511.2325 743.672] +/Subtype /Link +/A << /S /GoTo /D (section.B.6) >> +>> endobj +918 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 722.6111 511.2325 731.7169] +/Subtype /Link +/A << /S /GoTo /D (section.B.7) >> +>> endobj +919 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 710.656 511.2325 719.7617] +/Subtype /Link +/A << /S /GoTo /D (section.B.8) >> +>> endobj +920 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 698.8005 511.2325 707.8065] +/Subtype /Link +/A << /S /GoTo /D (section.B.9) >> +>> endobj +921 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 686.8453 511.2325 695.8514] +/Subtype /Link +/A << /S /GoTo /D (section.B.10) >> +>> endobj +922 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 674.7905 511.2325 683.8962] +/Subtype /Link +/A << /S /GoTo /D (section.B.11) >> +>> endobj +926 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 662.8353 511.2325 671.941] +/Subtype /Link +/A << /S /GoTo /D (section.B.12) >> +>> endobj +927 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [494.296 650.8801 511.2325 659.9859] +/Subtype /Link +/A << /S /GoTo /D (section.B.13) >> +>> endobj +914 0 obj << +/D [912 0 R /XYZ 56.6929 794.5015 null] +>> endobj +911 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +930 0 obj << +/Length 2197 +/Filter /FlateDecode +>> +stream +xÚÝYÝã¶÷_áG-pfù)‘y¼»¦¸ ¸¢Ý òæA+qmádÉÑÇnœ¿¾C)˶|wé-РX`M†äpæ7¿ÚlMá­µ"T¹ÎŒ$Š2µ.ö+ºÞ»¿­XБJ%…€‡…·%4QšgëÍ|‘·«¿|ÏÙšS’¦\­ž¦½ÒL#¤Y?”?'ïvùa°Ý݆+š°»_~Ài’d:cn…-É Õ~‡fèÚr,†ªm‚ºXbRžFí 悹Nûagaiºi¶kì€OïÛ}^58þ˜ïƒÎý±ìÇÿ¦Š¾ÿxÌ ²¤h›¾ê‡_·Oø9Äõûc3ä¿ad[TOÇ Íö»XÅ6C5T(Í’êŽ% Ý$8£;cÄ(Å£Âa§‰;ˆà,ÉñqWÙ.ïî˜NŠ]Uä5J÷yÓ€›3™¼Ðh{ÓÝéd¬Ýæn‘±·%ÊŸÚ¥­í6ªfö‡]ÛU˜yDIûlƒ®?\Ø!oÂJa+Nò>;ó'ªö‡ÚîÁ¹ë†ƒ¡Ã.wáÊT’Ø×õåûüÐã(ºT¼ÏA4‹³›X–Þ¶ïmOÀ-ˆ*ª–ù£ZÕÇ•+° jœ ܳ‡ˆ[·~­v< ¢·›@ÒUãàQKñpR·ùcî­Š˜g’™ò€bI Obž!£”&÷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¦ûüüÌ)Húu‰ÀC"ü£ÛæMõû‘“M'“¿>3>8 +¥ŽrÜ\AÕ„ 78Y˜ÙdÍHÊ%¬áƒh±ùùla+°_¥™ê@0ˆF(ažsý®7 °t2ÏRN†, +ôœA)*ìaˆÔqf§†dJfKÖñ›Öñ  RyEÃBÛé kÑFdœ(&ø9˜Q÷×±ÂÁÄ S¬4MƒÙ Ï 0Bš1ÉsÞUíæÙæk¿d¹äÄjž°8ùÚ‚§D +}å7A,û+£c”ú…%%”Æ8yÿiU ¢¿^OI¢ LQ¦=úP +F”Qò܇‡àðYÔ

ÑÚШ€<øÈÌ; 3š0ןW±9ùºtKD8h¬o ՟⻩Üb’Âvƒ/µî¡=¸Ó/3B +½´HÙ5#¤‰ºÁFˆ%FH#U¥362(¨«ínx±î  ªˆàF.ÑDßÖÏغҥ¡5ɸm *Þ¹ À.ë2ø°¤òŠƒÝ„t)ø0dY$ƒS™Ì®“ Dyغ ++úF…ÓŸ°3±|;•>cÊCºÍ–âùÚfÛbJù©Pì&ÀD1"”¿³Œir܈rLLÊÂZô2﮽d2¢…WN‚©Ù’“àǦ 9kÃ~¶¡ï?¢þBTBoë‘ç +hÇqÕR®°„ë%KôMK¢á³´ýP>ÇG¸²ìÚÖçâMÎiªÏñ¶³õÁqØÚ_‘ĶV&myœ³žŒ|ÖB‚¸ +ä8'&éˆÉK{ h ,$_ÆœQ“SÛ”•«ü ‰—¦áöŒª/»ÀKÒ;2b²îhOcãJx=Ã%úú8­3sîY»ûƹE%ýèöqï?‹Ÿ"\Lèx¬ëªÝvùaw\ª~‚}‚’oa`a讀ì|‹ã ̬;ºlô]:‰©âˆX ý+OD0ˆ·7öw—L†p.õy2aÃýu¦&ôåÏŽvÛ&t•?öñfW5ßÖqbçž:Nÿø:köE¯ w šlmãÁ‡JÇF¯7®ŸÌÿÎYµúëÃôÕI¡UÔॠM¡¡+ö«_W?ÿB×劮XQ"ŒVëx „Ã×û•0¤JGI½º_ýó¿œí˜5 7-ÀyÖ +Ãêó¥6ñLæÒ‰j6}ugA˜°Œ„«‡‘á¶ã[§pS‰•ïÊm‚+zz=ßâÛ¬ž–ü‚ÙÚFérúÌìŸî8MnÂ¥Žõõ!”ëS¥^ñ’ÃÕƒBÖoÂÜÿœ8ð„øœ)θ 'DnŒ8}·)áäÚL‰l“»VXÂ=|عoBÝJ÷zÊk; xòã¿þþ5wm?Ì4×êXÝ.¾9¨H1ºAß_€Ã¿±/¶ÛŸ¿ +}ëmDÏNùmŽ›!úÒsàž%DÏ<÷}õ›ãØè÷¥*‡Ým𾚽"ðÆ@¿"RC¤Té—ÀË¡‚Gˆ §²¬ÒÅšw?ƒŸÙF¯Æˆ—ÆCU_ÂÏÜø€~òò÷m]Þ†Ò«™þ %¸SPÃÌ—D)´:°Åé[ ×–D6‡Ïh¶ÅkaèÒê4·ú +B·€ójæþYpÃÝ]KÝ‚ˆŒËùÏ~W?ÿqOÁ@¨0_k½øaüéo#q¿$.¢G@ +Nå:(¹(dWn¿6žVŠ»ýñG¬endstream +endobj +929 0 obj << +/Type /Page +/Contents 930 0 R +/Resources 928 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 941 0 R +>> endobj +931 0 obj << +/D [929 0 R /XYZ 85.0394 794.5015 null] +>> endobj +6 0 obj << +/D [929 0 R /XYZ 85.0394 769.5949 null] +>> endobj +932 0 obj << +/D [929 0 R /XYZ 85.0394 582.8476 null] +>> endobj +10 0 obj << +/D [929 0 R /XYZ 85.0394 512.9824 null] +>> endobj +933 0 obj << +/D [929 0 R /XYZ 85.0394 474.7837 null] +>> endobj +14 0 obj << +/D [929 0 R /XYZ 85.0394 399.5462 null] +>> endobj +934 0 obj << +/D [929 0 R /XYZ 85.0394 363.8828 null] +>> endobj +18 0 obj << +/D [929 0 R /XYZ 85.0394 223.0066 null] +>> endobj +935 0 obj << +/D [929 0 R /XYZ 85.0394 190.9009 null] +>> endobj +936 0 obj << +/D [929 0 R /XYZ 85.0394 170.4169 null] +>> endobj +937 0 obj << +/D [929 0 R /XYZ 85.0394 158.4617 null] +>> endobj +928 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +944 0 obj << +/Length 3187 +/Filter /FlateDecode +>> +stream +xÚÍÛrã¶õÝ_¡Gyf…àBðÒ7g/3oºv'Ó&y EÈæ,E2"e­÷ë{ÎEJtvÛ¦ÓŒÀ¹ß`µð§6q¦³E’EÂJeëí…\<ÀÚ_/ìÐj õíÝÅ7ïL²ÈDëxq·• +™¦jqWü¼T"—p‚\Þ}÷ör¥­\¾yÿÃÕõ o®~àÙÛÜÞ½ýÆ¿H+ßÜÜÂG]®”Š¹|ýÝÕwo?кâ#¯oî>¼ó÷×w×ïo.½ûþâíÝ€õ˜2% ¢üÛÅÏ¿ÊE~!…ÉR»8À)T–éÅö"²FØȘ0S]Ü^üm8p´ê·ÎrJI¡M¬gX¥Í«l&bKȪ»GGämšªjeý@?×Mýäê¾lêŽ&òÝ¥J— ¼ï\A£²¦oáºõ®lGš }ûp÷×7o†Ã‘R?ìw9nü—ºr9eiœŠXIÀ:ŠDøOu&™œðô?Ûð P +‘Yû;Ð> gñ0옵 +4­£…UÑQµ³‘¼’Hdi²HL º$c×¥RjÙŒy~<[©T³üéRË‘ˆNøßõÏ3ü²Dd*Ã{\þ;êlñÂ0-…µpö¬†Ži°¾ÈFžcÝó¡ñº[tHû7ï"5Ú¢uB7Jý®ü„šK¹ü©,úÇ—¹EˆdrvIIp˜¿Ë.¥á4Iþà)ß•ù}åþP^°øóò*ÎÀ?F©ý}^Iôµ–ÂÌ{ïîò*xÂv߃%ÆFÚåÏw—™^ºO=¯±OtõºjÎ|g÷Û~â]ïwùú£ë»__äè×?Š£Çóÿp¯Zf"M€å+T2cÌ8Ô…<¤"J „¼äg X¥¦*&‚x8Šy1œ*3ৠ' z;D¿7Í6â¸É·<{ûÜõn{žxÓ˜¨D OfI6Šª©Y¶û]ÛtüÃGDøö^R½,šõ~ a–æiÖúºOmEXùM|JYw}^U!rÂL^tܾýè\{zïãð #$å[·ûè*÷L3×uïvµë‘²q¤CZ˜YÌL¢IgvÙ5›þpÔ\€hAqó÷êredÂxÁô—ï݃'‡Ïtí~*§°DÃ`³¯‹Ù“WA{¢Æ ƒÜ`ì@fú’)­é†(ùL#ÂøâgsL_‹^ æD²‡-c“ɧbý‚«hó»1)óêc…‰GÊGGâb¤³90;%½ +Á7§õÇÒíH@ëÇrW¯p"aÙõ8ì{Èûü>露Ƃ:ô4Ýõ9]GÇ•õ¦Ùmƒæü¤•mÞ®æxß’T1m*¿Ôò±ézš¯°Ž†žÓú#åEÁ×w„T +OåÚÔ“Ûu¹'LeE³~c³ï‡ûG¸{`s<«áïhˆŒ |Š;c÷¬&#zPÚ¶ûôW ÛR¡UB>çuU‚ô½²ÙeÕ4i´oé;嬟 /go6¨XÎ¥Z>Ó$ZqÆnAä^¯&)¤FïžÆGlæfSÏf´Ðˆ.F1pUBÚ=û„óÝw%z¤Û:WLÍo{·+½€„¬,µf¼½†Àw˪4ƒ%JCè,³SN×^å¿l‡RžAü{ +^0ö5žy ›–îCž›ÀH0Z”Y­bmÉäp‘œ$Ž2¾zâãpf0/+œr¦Cå‹rúìcÆþ2‰€Á}Œˆg&fƒ›‹9 I‘eà&ˆÞWc›°™7z›N¥ìg¦¢<ÇJU‘@™y”|uع9~›²¥4 €îÂØEÁÞªbP¬ñùVŠ$Õ#ź/ëYò€I¤ç´uB‡ÿA9P]u ÍäO`þ˜¼ÒÏ ù€-ýº¾}Íðž.T:)¤ÖéTérNÉ\›ï†P4‡ºjòâkÝ¿îß;ðP@×Å|®ñu’öNF%GÏ\Ð +ž‡ß>€zwÈ&Q`9EvØžìÜd–Æf,‚‚QEðúTc%b;­Ì{‚? `AØ>äuù9\Ÿ3bLQOàŒ~¾^sÑæý›'­¡/ͯXˆ6Ra"86O>$ç˜ í8U*¶e «OœÝ7œÑ…>G2[¾Í½—ƒ¥º)Ü éTÀ0SÞûhŠ—ÌðÕèL òì cϹ ;M;²p8<$†€sÈùèêî*FÕÄ3ÅSâ(6SͲÔJ³sÒŠé‚¢K $Ô¿u¼~Bœ«C˜‚5ÚèTÕ pa +‘ëøžúd½ÍûGšÙ© + FD|Lá¥sÎF +œb’©±×hš~†· +*‹$ΠϧP EPŠ|J¦ »£4=⬠+¾$r,)B€š¾‡]Ù÷Ž`D§QÎûsú`üðQÆžð­¯p +N1({z¦ °Ûð 9<Ÿÿô |‹¦G ‡joy5—«yÈ-Õ.Ô¨M]qÂsKu ŸÆ‡jveeÏŽ®e˯ûà=Qñf³¢wÞ.!÷)߶•7&r 89h,ŒYc¡ªØ„= Å©$NôA*ëfÛæõœ›Ó”¨&æøvrýu½s¹F"ÒØ׸nöUA×Ü»™f‰É„N’pA³ß!ž‚é€Ùœ‚*#l©ÁúI;­ÒÄD;˜³ªi£³> ˜ÎÞC™Gƒ®²”Xå9¨WK3•{B­Àa‡lŽRÂs”g°ùwé·ÂFYØêØÔÝ«9î¢7•B>uæÄȈT¥Ù •9áÞíï~Üfšˆ$ŠN²P0Ðê”ÐÑ ÜˆÁ>Æ „WÇ$`F^ð*M¦¼š£áL2¢fÒà­‡ÆÅYïÝ3ŸÈÌ@->¬œ¢Ádò$@â71:,ëS6/‡ûpÔAáÏCŸoÄÞ ô% +ï}æ#x<<%ä É¡s&fF‰Ð& ÕËg8k.ÑZ(’bDÒùîqëŸEàÝ=Yæ1˜JbO²oŠ›€å=I^ótÏ÷@áA¤'­30pP”Ä`ñµ^óÍ÷®?8,Ðh.ÐE2†,_›QÎ1—r(ÈS5é;¾p /.¡JØÇái [¨åÃ~5gë@ +½þ`J9ÿdÑÆÇVþ¢Ì!ûȨÀÌBÖ?e‘úñcΗ`ùX¹žŸš¦-zXæç-@fØ:\a½ã¶Gî7žÛù¨ß•=Éȧv)½»@2wl(kz+0h´zx6éqŸSS> u»žQ¶àðI¼þ˜CÍ-í‚f¡œoMoqÓâ›äÚµ|Éï…2VDÓWÜãÒ|ññþkÿ=êø_bP*˜4Õ/øÃ[Df@ +ž!þêóy©òendstream +endobj +943 0 obj << +/Type /Page +/Contents 944 0 R +/Resources 942 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 941 0 R +/Annots [ 951 0 R 952 0 R ] +>> endobj +951 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [272.8897 207.1951 329.1084 219.2548] +/Subtype /Link +/A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >> +>> endobj +952 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [190.6691 179.6723 249.6573 189.0819] +/Subtype /Link +/A << /S /GoTo /D (rfcs) >> +>> endobj +945 0 obj << +/D [943 0 R /XYZ 56.6929 794.5015 null] +>> endobj +946 0 obj << +/D [943 0 R /XYZ 56.6929 756.8229 null] +>> endobj +947 0 obj << +/D [943 0 R /XYZ 56.6929 744.8677 null] +>> endobj +22 0 obj << +/D [943 0 R /XYZ 56.6929 651.295 null] +>> endobj +948 0 obj << +/D [943 0 R /XYZ 56.6929 612.4036 null] +>> endobj +26 0 obj << +/D [943 0 R /XYZ 56.6929 555.4285 null] +>> endobj +949 0 obj << +/D [943 0 R /XYZ 56.6929 530.6703 null] +>> endobj +30 0 obj << +/D [943 0 R /XYZ 56.6929 416.0112 null] +>> endobj +950 0 obj << +/D [943 0 R /XYZ 56.6929 391.253 null] +>> endobj +34 0 obj << +/D [943 0 R /XYZ 56.6929 164.815 null] +>> endobj +953 0 obj << +/D [943 0 R /XYZ 56.6929 137.4068 null] +>> endobj +942 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +958 0 obj << +/Length 3415 +/Filter /FlateDecode +>> +stream +xÚ¥ZKsã6¾ûWè¹jÍàAäÑÉÌlf«ÆÉŽ•ÚJ%9Pm±L‰ŠHÙq~ýv£ %Á3›ÚÒ` øÉYa2¡Ë|æÊ<3BšÙj{%fÐ÷Ï+Écn ›é¨ïWß~ÐnVf¥Uv¶x˜ÌUd¢(äl±þuþý·?-Þ¾¾QFÌev}c¬˜¼[|þñÝÏß/>þxw}#¥uØ—sïâ‡÷4üÝŸn?ÞQûîöSï¹_¼ÿDíß„ïîîá!¯_üëêý"r=Ý™Yþãê×ßÅl üוÈtY˜Ù ¼ˆL–¥šm¯r£3“k(íÕýÕ¿ã„“^ÿiJRF™)”KˆJ锨L™Y ](ª—M³Ú\ßh+çÕáZó_Ä|]·õc5Ôkê:zvæ>Ј¿º]݃ôl®ç·'5ÝŽFï»f7PWÓi[žÂ¤ËWžtÇ‹vÔ1+ ^8ïr² íŠL:[ÂÖ‘ý»{ú‚ƯºÃº§Nvž—™2Îñ7 s[Á±³›\¹,×¹Vd¥1ÊÛ³$ ÔBƒöŸÐ#.ó“‘㇄ýÙ'À¡9Y{ÉßLa\2ŒËÆ¡‰fG­¾><ׇ~Ž‰¼‡/(Ã(a="…`ï<¨AÏ@¼2±ŸUÏ¥.3a­=EŠ„…–hGAÙüYäÁœ•^jˆK^®¾TY—óC}Ø6»ªM,¦s8YaO6•q±žI›Šw¶ëËY› Œ²?.ioIÿä2zõ5SÇOÙDÄVÊÓò2ÖΫ¯¶#â"i·¦FÍsBsì·`«z?Ž‡£í8»W鸎y¶5ðºß“t»¶{äi + ¢â¥ 486Có\\ž(ÙÓ *'Ø`||$Ý㤣@òkw$)\µ&òçß÷Ô‚(L{Cʱ™ÑK„{ OÙåÑ‹E pàg`6Ž;ð’è:×€4Î"ÈÆÇ8@Yƒ67¿ ¡VÇvHÙ ÆÇåвº}³Júí{ -Äü»wï¨Eë÷®ÚÖ[¸ Òoà<Ãã;[9´ÈʱÅ"µ7ìX×pºÔ܈ÓS¸O‚gÚÓ2´é1Ì1„ÞðÛª<¼ ?çÇJûïÛêÙU­WmuÞH ÇëÙ7ã~]l/¸³5x‡ÝCÊ/ª¬ˆ&ˆçÑò¢ý¾^5¯´žß„WAê‰D¶VÜ›+çÿÙÔ;¢³ÆYMžˆÒw[ž5À*.Ð ]Jpä./‹3{Ej,®º§÷—¦mIµ0HèˆèÑÞ+z  +&‘|ø D`ñ‚ZÈà߆Zm,oyˆY, þóÊ÷Ê]ý³>a&2k<³ÍŠ9ç†ÄGU噕¹:÷¨ Ý+J*¦Á/«ñ/gQ¸¨k¹€\ÇŽ)˜½ ˜·G»ÍP1ì`NÞ SCG׿Øó0aÄí­¯\øþ¥—üüÜ 4­gf9{n©k_­ž’¢ª„K£KpdΟÙ-Á^™Ö’ÏÝ@€ ÔB[ ¯ë%8~Bè𪃠Pb„óÇãè8`ô±#‡®k™Ú6Ou„‰IÐ%óL6æ¨ÍcÊšŠL‚IFbÄyÉÇ@îX`Y%‡x¯”Ç­¶ÜyxœQãó´ZÆßL?¸¬Ö\΋Ü׫.ZhH¿ÎT5b¤Ît&³‹ò”Ô*ƒH¿˜å&Ç…\²žGÝL‡]rx9ËHf qƒÍ”Ï,5$«üKDg`”ðyê?ù„+'Ÿ(œø*.SüáÜpN@»_6uôa—Ãh¯ºý+uûHǹ0ÌЃ¤£àûУ"¸z0¡Ç'ºÄþ»ˆš¶gp}ŠûNwû–XÀ—i‡ÄƒvîrŸÇ”TdS¤{ þ+Ágš§Rg…• –ÎÓ%•ÙX¨À€ kXêâY +p‘æPj¶]åK]¼´ç‡3õBypÀ&؈\û`‹æ€¹‰";$×ë†ê`Ð^²¥±YžËòÔ\6Çmå F“Pà¹'ÕØT{îx¬wࣸ²¦çÛzµ©vqW@™°oÌÎH± 6§ÐŒœB;V)|ÀgdÞh.jf3£ðÔkzÇyO6¦¡RxyÀIZ›Ÿ–|ÛO–8h“ÉÜÍê’A¦1aÎ`R_œ5—™‘ÚDýá#+y…9u›ߤ b†|Uõ@³é^ꉮ+ÉÊ%ÍÈ|eåé¯D¤´TR¬ík á(ƃ¢ÆÍ€Bæå±2t:)VY}N:8òÄžõ ±{HKWå±½~…x°Y‘x{€£”xÁ}˜²Œ‡¶¯Ùe&AÚ¹¬È O@Z1HßS@ÿ·Bf‚f­ÎDx;ÆW:Kg¥•™yHÿ(½H€ 8@ˆEO@C^ôâ\›6žvÝËŽõTÑH +“©Ò3:­Ó8˜k8¾óšlùø¿óå ¥BÐ=&óرk„Óâ¼nÍ€¨µ Žöu“ S=qsz †€\…nß| €ÅtMô=M¸ª{^!ȧï×¢Q%à)Ì €àà¢úþ!éœ œ‹Íåè,Œ-Ï……(œ‹,²2^ +”r¬¾*{êÃÂ4Òçাc¡Z¯; ·]u‹ο0b0–9›7Œ÷13;w|rQ 'èú¾Yzlq\QF‡¤A_ )â)b—×i|H£>î’àœ‹˜¿„›#ÎJ*NUF+ •¿šâ ªúºåL²xnô'sLÑÛof2ýqÉë6;„7Öé¥`F¤ðE|Èl‡ÍßD˜ŸûPˆ0b26o† ¨£ßô<ê €Ì$Íòý1J4˜DôTE‡_Ÿ‚§OFŒ»¼ÂE6ÅÉ}b`¯OµFxìë8gâ¼// •ó—vC3ÎÔR&Z¸Ì¨> endobj +961 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 +962 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 +959 0 obj << +/D [957 0 R /XYZ 85.0394 794.5015 null] +>> endobj +38 0 obj << +/D [957 0 R /XYZ 85.0394 570.5252 null] +>> endobj +960 0 obj << +/D [957 0 R /XYZ 85.0394 541.3751 null] +>> endobj +42 0 obj << +/D [957 0 R /XYZ 85.0394 434.1868 null] +>> endobj +963 0 obj << +/D [957 0 R /XYZ 85.0394 406.5769 null] +>> endobj +46 0 obj << +/D [957 0 R /XYZ 85.0394 301.1559 null] +>> endobj +964 0 obj << +/D [957 0 R /XYZ 85.0394 276.6843 null] +>> endobj +50 0 obj << +/D [957 0 R /XYZ 85.0394 200.1512 null] +>> endobj +965 0 obj << +/D [957 0 R /XYZ 85.0394 175.6796 null] +>> endobj +956 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +969 0 obj << +/Length 2458 +/Filter /FlateDecode +>> +stream +xڥ˒ã¶ñ>_¡[4Ušø¬œÖÞuv\ÞÙdG9¤¼>@$4b-²Ž¢|}ºÑ ’’8Ž«R:h4~7$V!üÄ*N‚$—ù*Í£ E¼*š»põk»Œóà‘æX?lî¾ÿI¥«<È™¬6»­,³L¬6å¯kDÁ=P×›îd®ßþôîñ‰ÆOï>1ôù_Ï›Ÿhü5ŒÃ÷OÏð÷B$i¸þñ㻿o>|¡uÁ$Ÿ6_>¿ÿç›ÇÏO÷¿m~¾û°¹žßL„ +Yþýî×ßÂU üù. TžÅ«LÂ@ä¹\5wQ¬‚8RÊCê»ç»Œg«n뢤DH•ÈQIµ$ª8K(ªwp9®‹®ý†òe8j[u-O{s¼ÙÚÐÔîyp8V>žiÒèÞš÷æøêÇ•íM½ãqO_ÍhÖèÚîö0^·³†y væHƒ’Yé˜ Û <á¯RFûª,a3(¤z ò8–îªÌ6"z]_ô«âhý¹5´<ô<ØuÈ_ƒ‡·[ H‹1Ê!$2M"è(²Ùž­ÙWmI0M <€n}Òu½t#ívÄN5,¨nÔ€‡Vok;‘Ũé¦ڪЖÊŠ¶¶>äT9åÄ^å0èÛW%ONݱ.d,L¬FŽvÈŸŠ!ÂdôÃœ) Á—t7|aÔ Ózvêï™ØÜ\–Œ‚<‘£µq¬d[DßÕd6©«íQ+ÓÓôà0ºWà·$ÈöLߦë-ºƒAÍ9~`ÚŸA#Û¯5‹Ð±¤òK2Í‘I ¼!K½¶·<-Ý%ŽƒHJÁû¾ƒM¹Z7F·#v¯­fWº„IÛYgJ© #ui +…>°®Á€º}á’` 2™#XôåFñh0^a˜ š%Y˜žÍ~{ 5àÞ¯æ®ëoãiW†…ËÝz°ûîX=\7q úyE¼4¦ q/ÖǤñØb)Q’™ð"Ký-Üy°Íݾšë®Ð5AZ2@Žñ Ž¿t”÷fN{&¡ñw£Š‰€'ëzÇ|>Å~ÑsÉúÇÃc~è àì†ýZ/a&ƒ,ÉÛ‹x8ö(¬[ËSy*ú„ÝŽ~G'ÿ•¶ôå{÷ §‚O‰Tùâ±nsÝu߆Òõ§xq¿“‚©Ã'mà•ëÊ´¶ØÀÃ(ˆ²2›Hƒ\É”üÿ>—kÐJ²uÕx7È=ãº- ˜dÊkqWÏ¡Æí( 1Üî™ ++x¨mO+èG¸`=ª¿£ßw¾8tž@Ü~®€iãb&ýÊyÊÉe£pη³-X¢(…Žgò.„ŽÁ&Uk!¿X2üÈ¥óüÎ8‰Û0,@ÞYT¯öÂT½¡]8-õV¹I@©äµ‹¼.OÈXxœ‹k¼I´ygWŽ3Ïo¾NÀT×{ŸéÏmמ›nèAŠƒ`TÁÜœ¨˜I×µi_¨II @„É«d­08í«‚±4}XH”pK‚5úL¶fŽduÕF©ZúZÏ["î¢óÇ&AÁ„]FSÅ”rÅ”¡Â-•  6·=_¥ôÍ}¯«fœ‘{áø—ѧ±&Þl~¡š˜¡4µN}ߘ]y]7]ðÈÍÁ +3‡zÙM¥ÄEö‡<'Ĭ¢‡Â‚k‰ŸºãIK”Íÿ¬>¼’‰$s“™Taâb2 Åéºìœ[âzgy`Ð[¡Ê ")™å˜°P¬®µ±<»‰’ GS‰Œ™BæSF[ÐÆg¥@|º]ªJ°óI£)¾¢l–RHE„cñÒáÍ‘*š8~±È$†=åÃ~ •W8¡JG3¶œœpÜCÖîwgšìÈ$"èbÝÓ؇_¤×ññ@ËX&ÉJ‰S’K ‰„&—…k²ðwS‰Ûµ¾š]è få°îßδ"Ê¡ru)ÙÅhiVæc„ãD&²,ˆ”>òd>òø¦À\ÈÀÁ–]ë1é1º9>qáü’f»LRŠPdˆLNÏ7‘#ÃŽ< }Ôt(é µÂZÙá÷ô5ÿÞë¡·žŒgO·KÕ›nû“SfD• *}× m‰]tš³ ûkÞÄ2ßùPa)t¦5Šï¸@ÝÂÎÝ@ ²#Ya„‘¨ßÓuzcÎgei¦/Õ«'ÞWv1w;sM$¦\h! +K³ËZ! U¢|õ },ä-T\Èiù)¶†—™M¬)¢Ût‡KBaŒÂ´˜ŸS7`\&Ö^±¡‰&&Ú¡Ù’å^_ˆ¼=¢ µŽ¸Š©/@ð$.˜Á²n 0ãf—«{/Qc‡çöùŽ±Éñ¡ÚÖ=¯tñÍX>Ëî)z /{0„öG1Y C*5÷Hò|ÅjAÀùеa0ÂXë–KƯ,†•p=†”Fä9‰ñléÜî|uÚ$1Sû52Ñ”*?õVù8ijÞC@üû 3ß‚ü¹=á¬zÛ”SsÀÖ'¨‹«ƒNøÒÕæOwíi¸þáñé=|ë5ë~ÒÅÀªƒtk¨€ƒ6¼Ý ]´Né!)½=Á˜*5$ÐyúÿPŠrla±Ö¯æj§›íb5% îÖfÏX.]äü©pšwzc 4vÖ׳Ü]Õ°»“™2_$¡OæÖ#ç’_åpÚÐØ°ö4uîëÜzû.—H38Bn«‚'äô°…ïúýuoõÖV1J¹–cݽŒñ=Ãm}„R/"$•§Ž4÷•>‚tùª[«_Ð@âIŠý[†a{ÓШk/O \¯\iܽŒ‹µyîbm^`8O_Š­j˜=:9M®<uH&)!Íf¹² E ¤òïFÜÙ Ív¤Yžú*Ï]‚ÍŽb7KFY!ëö4¹é>a±¬z Ù\˜"T‘2»Œ·SCNE˜"¿ÄTz[Õ•=L A05h1„u”»œdkM9C€/¥x$ue¿r~EÇðyΟ¯Ž&áèBg Ú½.ßóh¦·\Q&ɧw%±»Üéu©®Œ¡™ÐÙ^ôÃo)Ó$TK +…3¸U£©UPk\‘;cpËÜÓ…à8~*”©DGÊR³)=„ò6MÄU$ä¨U“—¿pf¥ÉÖ\:âç¥Z¾þ®Úé=YO½å¼zxã¿H_ø‡ÈÂ?!á˜èþïÿ]¦¿Ÿ¢4PY&—ÿRÁá("Ì”K©á çþš[Öÿ xK:óendstream +endobj +968 0 obj << +/Type /Page +/Contents 969 0 R +/Resources 967 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 941 0 R +>> endobj +970 0 obj << +/D [968 0 R /XYZ 56.6929 794.5015 null] +>> endobj +54 0 obj << +/D [968 0 R /XYZ 56.6929 717.7272 null] +>> endobj +971 0 obj << +/D [968 0 R /XYZ 56.6929 690.4227 null] +>> endobj +58 0 obj << +/D [968 0 R /XYZ 56.6929 550.0786 null] +>> endobj +972 0 obj << +/D [968 0 R /XYZ 56.6929 525.2967 null] +>> endobj +62 0 obj << +/D [968 0 R /XYZ 56.6929 393.0502 null] +>> endobj +973 0 obj << +/D [968 0 R /XYZ 56.6929 363.1913 null] +>> endobj +967 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +976 0 obj << +/Length 2095 +/Filter /FlateDecode +>> +stream +xÚ•XÉ’Û6½û+täTîË1Þ§*®T<9Å9`DHD …%Ë_ŸntƒË írJ6@£ÑëƒÂ]¿pW¤~—É./? Âtwh_»Ìýò*ä5IûiÇ0ؘݧqá§E”ïöK!¯^ýô> +wQàgY”îŽÓYYžûYš»‡êoïM-ÎFwû( ¼èßh[âçEⶎÈý ËK»áõ‡oiõŸR÷ãpnôï¨ÙÊÎèIL˜øq’E,&CèØÈïöaÞ¯b¨®b`)ÃK)ñ®ôË,ÊXHøišÆVÊÛŸ`[yµîÂÂCAøEaYì-BïBOÓd-.’6›ATʨ¾Ms#Ö£”Q°Û°¸¶¯¤6þÝ>Nrï}?ЂVt¼IuÚ€¢ô=òROËá">ÒÔÂà¥ðaè—iÙk°*p}>¨³ì4È‘ û#^áHƒ£½OßÒHŒrû«Ñ܈šežåpì‡ÖIU«ñØð:¡éK¦‚5ö'EK? +JòÚC 2ã ÆÕŸÞ½!ú(…Éš8 ¬ýR¨ UÒ§7"Îtƒ ‹3=}yÌFGòÍ¡:ƒ&q[êþ*AÏ»<ñÀÔq˜{š…ôVöItê+¹‚Ïø†ñ[ñd •yµ—‘£f^¤¯©!r¤ã®¯Œ{3$®J×¼¥§ïTP¥Xæ5¡'7Ö7mdk¥¤Þ±ÜqÓYâ|nÔn‚±S +fhWü(½¾YhovçåvlŒ25©,*Yݳ÷›¦¿ªîÄqˆjØ|SüÍ‚Ø{©uÏ•cqÀ]#Xg±¬,ÕI’Êøߨ ´8͸dD\2lL|£ælV‹„Jn Ë`«.hš±š#A&Fªä=¢;I^4¥ŽTRdûC#4‹hÅ¡V|.ÓÊhMË4`šÑ_ûiÓ\Õ†+ït¿åab\rc8JK§ rgM¢ ÷Ô‘¸·~$Â&TE´´ð¬“a«ì¯nhQYdçJÉk„“âªÒZ¨xm¯v¿•|“UllÑY6HúQƒX½¾G9(©§²æ +dXõcsý.Û~¸ý¿ Šç•‰×:%<ä7IE”èÚ–Ø’ª2yÑT +hZvýxªY/ý‘áÝN6“dy 8xp]Óc~{î0¨”~‚’$¡½„3×|Ó$ý$ÈR¸2Æ/{ë³ý4±òÕc¯ÕW¹aµ¤ôó,ÎXT¦JP¶Ø¶ÖVDÙ6ßFµÊ0«æU¢íÇŽ™¶¿À×¹`-åñöl«U +^AÁ³"rÍçžü‚ÍVN²éÎ|Õ•©^Tãb6+'gäÐqQgä œÀ#Ùu£¦MÀmû¥”Ä”ˆC¬¿Ðé,õÀû¹Z@“0 ±ÙEÐól6ü˜æI4$mVn:ôsxµWï&ì˜:,F9Ü2, +DŽ49œvDü¹„šný~¹ æÒû/å¢õ>ÉÃP©_¬MËZç¹—ù3?,žk&ä2@‘(Å£À9[pxZµ_.{©ãKi¨X)$5”uai `‰fAþ2sò5ÜrNñÝìÈS?/ÃüYvà©6;ðX[$€Aq[€ÃÙ$Õ„|ÎdÚbß©@åœÖôQ‚уrmýG aCˆ¨Vj@Pºµp7ñ>Z`­óBC¬SßWÄ<ˆEíƒeõôöTá€;i‡œWbé"Žp±°Å©M)Gy%â*哦tð–RW8WièÈME“Œ"­º³lââ/²Ão,Õ`ú0Ù@ç×’Kà†Ï Ïm~~ÐÁ*µf¸ºzQè¦Á‹ÇÍQh³æÀêÛÆr’.“ƒ‘?,Ñevÿ'€þ0¿]pø®»¨¡ïì{”æµå€ûèŒó‚"¨röZ^¬žH9¢Â !\: +Ÿ¤IhsÜ]W‰y-èÚ3·Øé„™„ƾt‡éQ…ë-šÇyzÚñÈ¢°äø[î%•SŸ¬cPwMß92¨6ŠÐ9ÎQ °ÄÂ~ûFbÌ‘œÎ*Î#²­.ø„XbI"èÓ +Õ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 +982 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 +983 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 +977 0 obj << +/D [975 0 R /XYZ 85.0394 794.5015 null] +>> endobj +66 0 obj << +/D [975 0 R /XYZ 85.0394 769.5949 null] +>> endobj +978 0 obj << +/D [975 0 R /XYZ 85.0394 574.3444 null] +>> endobj +70 0 obj << +/D [975 0 R /XYZ 85.0394 574.3444 null] +>> endobj +979 0 obj << +/D [975 0 R /XYZ 85.0394 540.5052 null] +>> endobj +74 0 obj << +/D [975 0 R /XYZ 85.0394 447.7637 null] +>> endobj +980 0 obj << +/D [975 0 R /XYZ 85.0394 410.3389 null] +>> endobj +78 0 obj << +/D [975 0 R /XYZ 85.0394 348.7624 null] +>> endobj +981 0 obj << +/D [975 0 R /XYZ 85.0394 311.223 null] +>> endobj +82 0 obj << +/D [975 0 R /XYZ 85.0394 189.9853 null] +>> endobj +984 0 obj << +/D [975 0 R /XYZ 85.0394 156.0037 null] +>> endobj +974 0 obj << +/Font << /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +988 0 obj << +/Length 605 +/Filter /FlateDecode +>> +stream +xÚ¥TËr›0ÝóZŠ™¢êŒ´Ìƒ¤îŒÇài;iŽQ¦QIó÷HÄ$qW†A÷utî‘.`óÀgh&©‘ Ç„ƒÝÞÃàÁÄ.=âr‚1)˜f¦Þç ‰äŒÎ@z?Á A@šÝ@Š8ò †ÉfµºZû,‚i|î”cxµŠ×'~Ât¾¼´®äG’ƋĘ <ûr²Jãµ Qt:_ºúuœ\mÖgñh]oæëx/ÓÄ¿M¿zqúÚôO‚YßÀoïæƒÌ´ûÕÈIÁÁ³10"RR°÷BÎ=…—xׯ€“èPzT7‚e3zD8J  Mpª—ˆŠˆŽÊùÁØhÒU•®[•9Õ*UoÛ¼|pŠ½4­Ú7}Ç—Mƒ€ +4‹$çÉ™‘•2' £JëØé}•ª±Ö¶Ìì¢öìJçÕ¥-ÙZ³ØÖ>ðAY³ìöwªv™÷ö»)ó?A‘ÿR¶Ph÷ÑÆÑ~»¥Ý…ÁeêsƒLÕù“éÛôÖwC’œ[yžTÝäºgGE8ìIƒ‹|7ðÒ¾omè[”—™~nlNÓímhë<ïRBHì640; +ó}å*!²á ]ÖÑUA«ƒlÛ*kyÓÚ Ë54<ªàmgvd¦gíTúä,¥ì¢}Tã?9_¸ûÿcZ8^¾Klue…zR…]fù •Úµº~±®Û´î0lÒqÐÝPµS#HÓÖù]ךÃ@ÿ;ÆQ?+G†Ä¼îPÿ{$ÿ©0BLz˜¶éTÐH PGª—œÐÌÇÙýHý/š@endstream +endobj +987 0 obj << +/Type /Page +/Contents 988 0 R +/Resources 986 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 941 0 R +>> endobj +989 0 obj << +/D [987 0 R /XYZ 56.6929 794.5015 null] +>> endobj +86 0 obj << +/D [987 0 R /XYZ 56.6929 769.5949 null] +>> endobj +990 0 obj << +/D [987 0 R /XYZ 56.6929 744.7247 null] +>> endobj +986 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +993 0 obj << +/Length 1222 +/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' 0|‹Cš R&®}› ô ½=+·-n;N;)LùÍæìÏíxp+íµl)Ýrn¬Ù4ƒ:¢[ظbñª»ø»xøË=pIÎ +ÄP²!ìåö0¿>üô²J×­Ù¦‘ %*Š¼¼•«ÛZ  ÿVòy#tµ1ÃQïžs*ô^ mÌ梸”Û®®³ +©Þ†/F¶œWˆåçÁ¿líÝc° £?;7ÌÁÚ¹¶Ý:øëN©~Ç«Þ@]bôÕÂê ?¼”ÙŸJz ÏVd[}ćž?±àú­Ÿ#„WÕ°˜eÓvÁK§*ÞÔ¨¤÷ü²“Tºm|¡¥úrMøžÒ`^g¾'ïý‹çuÒ5ÀÔ™Ùþ—´oÉ—–è-ËÃè>²<8Á³2pÁ¢1‚3•ƒŒ>píNƒ?Û{³p…T™ý| „-KR”x+:BØ#†Ë›‚WÀè%Á9*))¼ëÍžô\Ç=Ïuü$îþ\¨tÚÕê8ÿMøLÌ:›$4 1Ë= +q/ÇV”ðç^Ƕġà2…¿@¡žKñÿ‹ubóÆ7Ü#ar/¼o°+ߨ £ØœWÕL ìõ…Áýñqùvå»`W¾Ý@˜UxÎ$U‹†O^re˜†ÑŽJûÓÌ©¿¦L¯ +/9ƒ¶‹Ôïè˜PTâ„ý'tüôívþÊ ß.4EæKhé;(ˆÄ÷txšd¨ e ™¼0½÷6R=ºû*Š™Üendstream +endobj +992 0 obj << +/Type /Page +/Contents 993 0 R +/Resources 991 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 999 0 R +>> endobj +994 0 obj << +/D [992 0 R /XYZ 85.0394 794.5015 null] +>> endobj +90 0 obj << +/D [992 0 R /XYZ 85.0394 769.5949 null] +>> endobj +995 0 obj << +/D [992 0 R /XYZ 85.0394 575.896 null] +>> endobj +94 0 obj << +/D [992 0 R /XYZ 85.0394 529.2011 null] +>> endobj +996 0 obj << +/D [992 0 R /XYZ 85.0394 492.9468 null] +>> endobj +98 0 obj << +/D [992 0 R /XYZ 85.0394 492.9468 null] +>> endobj +997 0 obj << +/D [992 0 R /XYZ 85.0394 466.0581 null] +>> endobj +102 0 obj << +/D [992 0 R /XYZ 85.0394 237.1121 null] +>> endobj +998 0 obj << +/D [992 0 R /XYZ 85.0394 206.4074 null] +>> endobj +991 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1002 0 obj << +/Length 1860 +/Filter /FlateDecode +>> +stream +xÚÍËrÛ6ð®¯àøDÍD0^$ÁæäÄvêL⸲RO'Í"!‹>’²êvúï]g¢Ð§¾3[ôh „… Î,ùâ2ÄÐ(`÷òäãÙxB=ì^ŸMÇžçþ ƒžº:›žŒîÎ.>]^'¹ûöÇ“«Y‹ñ4·Ÿ.Ï/Þ}ÞÒ½Í:)ú’Ì”ßG_¾b'ß0b¡ðœ L0"aH|Ä=†<ÎX»’®G?u{»úè æF”ùt@uœ ©Î ‘Ï(Óªû½,äxâcìa,Ð¥Å$J’ +EÕ*:2{(A"!x"BPèyThîW–@Õ¬^kT¼‹´H³ö–¬Œ£lYÖ ªäÝѶy΢lÒŽÁ/Jƒ2¼üÏÁÛŽÍÙ{gTY Yî°jàZVw-¼(- ‹òU&Q\æCö´ÖÃ|yeõˆ£d>¬­VÚ‹++-¼¬kY›i¹°bfÑìKl÷£,+72± +*íXEE½O)Ãð«)Lv<¢RD|ÀCø @-‚‡<öŒÇžeÇ-#: ¤}³(nÑÚè›Æ.öß1ÍÈ }ëØ¥æߎõ‡= Ùµ}ÑùÉ}ƒU·âé¡÷ÊôµY:ð^¤÷^Çç”8„#Æ!œAÈ‚‹<Š( m˜§ã Á@êC%&$¿‰²¨ˆÓâÖg½€§©@~šPw2ž0ṫ*ÍÓ&Uﬦ𶹔&Ô˜iâ +šwÄõ4Ž +»nÏFñ2•wÒb§vWGœª<£ñï͸®;Zù:kÒUf1«1®ŒK=&µYü{¸^ÇK{W=¨úŽŒRƉö¨b6´+@Û¨Š(—¨# Ñ@>ר‚µÎÿ +f!uÓ…Zåî}9&îÚÀKí3 +·Yš«¥Ù¸¹¹1ë]ÀQ“MÚ,Í~!›MY}3ËÊ(õaºÔ~¹0[De&ÈM–;¥ö\‘l»Ì^ Æ(P"æÀHcýÖ0>T¼Â2J(Ò+í“¢TÁμ"Ls AÏ€Í2²´ã,•Ec—7i–Ùå²(dlqT U£ŒÚ«reL…½¦lf™Ö -ÛŠŸ)›4—?ì×$¤ýS‡ù1*‚ç%Ê!ÄnQòÏNµ|ôâØAÌ9 ´,ØJ·KjÒÊ4a0£í­‚ªrRV‰iŽö=#ÏÌâÖëy­\!7&Wèg>x•€öSnO—«&fna> +n9ê®ÐB©ªWúQEBŽ| ÌNuë`:ôkn‹}8ÔXÅÇtªëmý÷­¯ý=^¤8æñ Ç̃€×á<ÊÃ>%Åê+'Йú>êçòE@Û߈¶¿4E¢þhh!V²ŠúO@º¬bºMæ1áwÿ$‰%7BܲÌê½>ìsëD7c¸¦1êÿ0§‘ÌÁ¬‡^˜yö·èl™ê.$ ˆßf’È:®Ò¹ïXÀŽ2³—à‰+YÔÑ\÷¦ +=n ˆi¬¢> endobj +1007 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 +1003 0 obj << +/D [1001 0 R /XYZ 56.6929 794.5015 null] +>> endobj +106 0 obj << +/D [1001 0 R /XYZ 56.6929 480.2651 null] +>> endobj +1004 0 obj << +/D [1001 0 R /XYZ 56.6929 441.7923 null] +>> endobj +1005 0 obj << +/D [1001 0 R /XYZ 56.6929 373.7178 null] +>> endobj +1006 0 obj << +/D [1001 0 R /XYZ 56.6929 361.7627 null] +>> endobj +110 0 obj << +/D [1001 0 R /XYZ 56.6929 167.4388 null] +>> endobj +1008 0 obj << +/D [1001 0 R /XYZ 56.6929 126.8733 null] +>> endobj +114 0 obj << +/D [1001 0 R /XYZ 56.6929 126.8733 null] +>> endobj +1009 0 obj << +/D [1001 0 R /XYZ 56.6929 98.4089 null] +>> endobj +1000 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1013 0 obj << +/Length 2705 +/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™„$"ÕêY2u0œLrT¦@\,Q`eŸ¾GWK»®&R¢UšzWÃè‰d=d¡·õdŸG€‚Qy¿ÆPq +$ÑR O#@)ɳLyg=Iû°7#Xœ³,ÕQ(üÊ1Ù ®{˜‹mÑ4# *%Y*äô/#¨\ÜV.]T4ñØŒ‘Lôô7K„t¿ïŸ’ËÊ-×ӌƕò§‹ò[ß2U{qË>Äkˆ9‘”C‚Ò‚Cñõ˜7ÀSÍ1D‹qÙô㊳T;¸/Côh‹ßÍ ؼ3’Xhw„úÞ›42 ,Ä%´¬Î¼cîƒþ:Í]ÝbýœØ­&CiqW”Û"Æ=àšaéó»~;*9U„çOËÏgØŒH!ƒÛODÜCøš¬jR0Õªš.ÕtU©ºUj—© y’*užk¤a+Qز¸Çwº g’Ÿ¯ 9¸3ñð…GÙºÊ4›Ýj†òšÍ¿š—œÕ—‹Hâ+^ I×ù,9ƒ€p +›Ai:ÿÁ/ͪ8n[»ùJ WufÝ6øÖ­iï©ðÑ‹"X¶e±¯^$ôLŠòkPÑÀÞØ"¥2Þ8‹åͺiL0ºÛPú–­·ÎÕ±ZX³,ü§[ó vtë-Ô|iMµ4ËàÖífàÌ'1À›údbO)'TÁN>#‰v1¦{¤º˜ØeÊ….é92u1¦{¤Š¦‰á=)^.·Õ¡¹¹¿ ?YŒå~¯eÈnS9çÐDSHòöbùP-ëv/6¥°½8‘øû™+âýë2^¹3ÐÇ=!ÉyÈ÷#·5Q9—ýÄ}0í¡4ÍÓ±wÅ]m‹õØçCÐË4âÉ8RcZ¯±¶ãšæ‘B,è+´o+ûeÏA3>÷ÿ5¹NgF{Zv•<³GMò|víRMg×H5<³éeX®¡ŸÍøyΑêk‰•iØÂIÞ§çEZçá¼ÈvÙ ÏöÓvúi‘fýÚ>Ä̓AUWIç©MÚ§³.=6ÊîÍí¶¾¼6~²ÐÓ¤Ê œz|'RfKDÈê®›…™?s‚‘whàqŽ=u–=Ú,ÕPKA¤êÖÈI['«2!÷[_M Žþ_ä“xvè:ŸÇ³„ÑTå½äÐ÷l£„‘3Jø5–ÄYÕî7®2Î)D \Á³§õÑ6¼MwÉC­¾Â¡=ÆDû…‰/ÅqâY‡3gÏ [W¹8w%îÒaŽ.škQÅÊØ2¦ü€fÝéÐsç½0Ý<ì"E‘ÿ“üÙ›Zçl]ðÆ@ÿ°¼„佂ÎQtÕiFBL§‘dfü h4¨0“sÜ®#ÐI<< §Ÿ0²Û_ŒGv„ +µ#÷‚+ÏÌ.¹cWø}ìzì¬'¬#[õBcå–jü½õO¬ ÖÖ•,¿r4êÓ’À°Á_T3 ·Ü>íl‹ëµ?Pgè£îLfq3où§{³(-²²ó» +#¿UÃ¥ìœôý©e0fÆOØGG÷ãÑê‹aº°¿®™´”úGGà32’ØMZ ÿ&ƒÃ`3GÕÚK!¤M4Ý×Û•[³)îÊÚIdÒ¹žß{¤¥—¡ª=-â9ØÅðEàð{»]ëÈ•™&™Œ%â¹J&•…>ËœlÌø5œÚo8Ó¢¡5Å’Œ€%L䶵U6‰%™ìÜor¿ùb¹++På¡ÀSï8±;{?\ëÙZx[<„B<ø­YÇk…}qhû×ñÌêiH£ÞÂOƒÊÀÇjm&3BµºPkw©¦kíHa™,6fñ;Xâê¤äV)š,?/@¤‘ ¿ß”@$æ}&µ˜ŠɈ˜lÍIÆs~z›ë[)ûj3Ø—æ¡j‹/Ã=9­œõÉxýì„!r(N¸Ri¼ ¤|;}éco{5eâ9Tcºª‹T«:Ơϱ¥Òsdê`LWu‘jl‡}q÷ÛÝ׳§/L1F­cœ9˜E[ãÍáð˜@ÅSö­—/«rk&ÀŠ5§ª{`0æ¼SuÞui¦×Ó ´õµ®Ì©ÛÂFI¦Ï±Ž4'¼ûº€,Âï2?ç°úÔaƒ€C‡•°qâI[„0Ú´áb+Þ¯œús<-‰ v·ÓÓ7°)œ=ë®3"œ¹}Eši7ô›-Rbÿ5h„!—kÏþ¤ÇÌSZóq#T¡çYÊ +ÏÒ¡äñ_•NEÿ…6_0endstream +endobj +1012 0 obj << +/Type /Page +/Contents 1013 0 R +/Resources 1011 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 999 0 R +>> endobj +1014 0 obj << +/D [1012 0 R /XYZ 85.0394 794.5015 null] +>> endobj +118 0 obj << +/D [1012 0 R /XYZ 85.0394 769.5949 null] +>> endobj +966 0 obj << +/D [1012 0 R /XYZ 85.0394 749.3395 null] +>> endobj +122 0 obj << +/D [1012 0 R /XYZ 85.0394 221.8894 null] +>> endobj +1018 0 obj << +/D [1012 0 R /XYZ 85.0394 197.4323 null] +>> endobj +1011 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1021 0 obj << +/Length 3394 +/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,‘±Ž²¹º¹úÁ ¼ÕŸ†,KJ¤Œåb)b’Bÿ!.–L$Ú! +ôf)‡†ÌH"¸ðÆÙÀø)#2ËäÂs¡ñë|[ËÕC¹úð©©ËëeBiônYüòëã7ïÝÓ +-õåK)Ò˜‚yCPÊj“·­auÉ3’¦*³\^^'$Œ^:Í¡Ûº€Ä1›—Ø]”XTûrÕ5ûc@¨ŒIÂ%;ú +³„sÊÔbÉɤä¿Wú‡‹*ÿL%­îëf_VXcFÒX8©¿„q¢[†§|_¤pA2tõÏ”²Î« hÅæ¦:=dý'äÔŸ +: +O‰¢iÃú,cÆ ';tÕ¦êp}-Ê«r×:H ¶"È×üm—ï»@W°ÿdIìvfVЈEòäT侜 +¡~&=Ÿ¡;Ðè顺fÑêÁ|üd‘À<国H‰¨n:«°™!M¯ê燔B5&Ò2óûÕ­¿zÈëºÜáÛ¦(Á¹xý«µñYŒù’D&cÐ;6\ûë4:„T +"¿T^ð7MáÔ~ªº‡æ`1¯-€6;\­ESûö©Bo4€Úî6ùq²‡6¿·ˆ¼-Ûþ!oÚêåý— ÔBr€VL%”³ô¤#CS$véˆçÂáÿ¨QIbÖ˜Àrùý* EÌgHžËOÛ™Dr‡ÑE–²±5‡SïÝÿ¾z,ë~’gç8Î(¼° +†\ósì¹Ì¯! yMò(=7É“´yvzþ˳C’,žµ¦çššód–4„J#{Þ@&[Ü +þäo›W˜{æ:†·9àïõˆuy¦Ä_pñÇe|œº]»=x4 ¤øÒ—AÿîcÏ8¬Î³õ\S‹ŽÝ ”aldÒ·½IÏN¶õ “HnOx·9d¢6œó A‰<¾à®3>á¸t¡k_–Ÿ\±üO‰˜HA ËÎÕsM­:ö ˆš!)äc³ÞÚ]‰Û»qtØyW¶æë +”¥ð§8Öù¶Z™ K™pLØ4©núW¦UYAº µ´¥AbqZŠ0Õ.ÌS3Þ¦k0Ò¤þ<52[Kói+<´Fù²ÀÊ‹!bÔq^ +)¼¶>äVRYT%›º‰ŒîJój›åð)È¥¾l­ËeXbñÐqjjl‡†½;â/C£AÎmíφ µM Õí ³I¾±µÊ­6?¶!A¾7LWóh‹4ú¥9ìë|c\¨†œugÛ#½Õ +€¿±\¶4DÇó`×÷’sóqW‡âƒ>ñÁ‡‡ÐÖöÎ;ûì*lzb°ççû™÷"|0Ö0ßæ]Wnwzn¸Ï³9=‘¹ûXµžªMp­z8sÑ¿…µOe=‹_°0ˆL“ô<~ ¹æñËsµò§yô#Ê +dÿWÀËŨg-ÚG²“†#Ù‘M_ÔùvÂ$í±‹'™ñH æ江wCî½^Z,I¢± ß×MÿÊP*+±ÌA™HIœÒ“SÉj€eÊc™rX¦ÆºÀ³Ç65Ä6¬ÑãØ4²·;dK=Fà¶D¬\ÁÂÃh„ÙPÈìðL ·yø ¨ÚÏBЦ¡’i+riTChâl°/C¿ÀC¾Ö`"† ͨƒ­‡Ü +À3¢MÙé¡J.£çî3®·ø±[ +ðVV4.&md#¦,C8à¦XÒoŒjxzšáwÓÒÚ¸è®tF7³XÁñKßbæjN?÷®3sï¸LîÓ×3G!˜Ö˜Ó ={®i×㚈IŒw†F}ûÊ€HÜ©e¨ÑoÿÐ6‘4úkpÝÐè†`(2w^šDEc¹KA<—«¶«êû^Æ°×ÖžPp󘡪4ÉL–Eby–â8Ž†ò?–†fb+­2qØŠß´æýÚÅA@¨© 57„õðcZ—ä‚“8ñ§4Ã’ÕÈò‚AúêÏŸžœ¾ §‡ÿÌn8@ÎÍãÆì úD¨õa{gL±’iŽ‰“k¶|Œ‚n{ÑЦ÷Žñ‰FþØTE{âùuYºú…Èò# © §ú|°)ô~·Ô »jë:œÔXÊØ©œ__”¼$j C®3ëËqéÚ~—wí´ÜÊ`/Wò|·žkÚïxq±\ xÔñO˜7ï«ÎÚÂoÙØÐãWíØêÞp§ Æz³ÆËbT° ÓkÞxž Çðë¡Ü7Í<8í¹§I×apõ}{ñ¨¹¿×™SFlÂê2ÀŒG?L^˜V¸‘j. é,‰ù`ËíÇåÇݦZUÝæhèEe誳"S—G@Á)4qo»ª´wB`Å”÷þîÚhô8?Üo™ýåÐY6"óÇ`öD59Àׯë›!öZJÆa©tg¿€L`ãOÂZ4Jc@:=p‹ ïÚÜè¢N`¥9Ñz[©8+þzÌúØk5ìEq’òÔ}ª=ÄFëBé}îd»@WÖ êX¶ >bþ|ÛÝ©™µ\œ%þ6¥=>Ë„`fb9˜AËɘǟc9™AÔ#‘çáÏÐTr¡†?ä:ŽK_É£¯éáó ˜Ú:¥éÆäï‡ûCèsqšú궛½EAÀ0î_ýó%^×gÃ3Áö¾íÌ›bçÂе2WO‚¯ÑEèú…Žÿ†œ¾FŠT{–¬ãYíƒÀ°Ü™wÚó°[çy`3÷FÀ/,ƒ½A·*Ûvî_ `Fñÿ³Mýuˆ?üoýcགྷ4;ªSX3!V)4?K¦W/)¬þ„Tÿ7ˆ²endstream +endobj +1020 0 obj << +/Type /Page +/Contents 1021 0 R +/Resources 1019 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 999 0 R +>> endobj +1022 0 obj << +/D [1020 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1019 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F53 1017 0 R /F14 729 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1028 0 obj << +/Length 3881 +/Filter /FlateDecode +>> +stream +xÚ­ÙrÛ8òÝ_á·•«"' î>erÌxª63›xª™<Ð$eqC‘‘ŠÇ[ûñÛx ’\5[©q4ÐFßù5ƒüÚèˆÉT]'©Š4ãú:ß]±ë˜ûþŠ;˜µZO¡¾»»zýA&×i”Æ"¾¾ÛLö23†_ß¿¬Þþðæç»÷ŸnÖB³•ŒnÖ:f«oþúžF>Ô֫xˆ·?}üpûýß?½¹IÔêîö§7ë„¥ +V^^ûÓÏïÇuŸo¾Üýxõþn8Åô¤œI<ÂoW¿|a×øÇ+ÉÔèë'è°ˆ§©¸Þ])-#­¤ô#õÕç«¿ NfíÒç´4‘6" °NÈ ë¸ä‘‰¥¹NtÅæwUq³–±YU}÷7ܬÊþ°oʸÇzu·õ“Y]·O¾Ýзü½/÷MVc/]=Úõm^v¬oé[”¶«š’ºOÛÒ­o²]éhØfí’·»ÇÈ`8åšó(ÕZXŠ»¾}|¬š‡hÉ}ÎV%× #“0d×µž‚Yv)3eƒ¶ŠÇÍ÷6«{` +c«_Ö_Žˆe”(%/à¡Ž ˜ßWl¢DèŸáô ŠB®úm‰ ±êÊý·rOƒÕ¸Ye}Y?ßpÎWp…’ñÕ§2/›ž@òmÖ<”7|ÕQ—¥ß‘nïð°¥ân§Ê Íá±€}i¢uènÿõᓽ#¸6.næW•‘4 \¯š¶§F—}³7M+\ÑYp`—u=žÛ¿2&ê²{=ÉW÷·ü©ªkjÝ»EDu]û]7íþ‰P´ý† v©Göïöà$wÄæpx:à™Ò5 ËË#¼2Œ”é¼êï\E•Š þÍß69ÝÏŽtY¹uÌ#¹é;Íõ +2(²šG‰IùÌêóœ£:Ž’„©9êÿGÙ¾éÇù6;Ã7…ÄoêC·=©èçñŠ~„7¬è3ÄqùÆåY¾='R"†Fj.±fv†5j` šé€2ƒ cR§ÌhF` +V BÐ z¨cçÓàHtveÖ¸íý¦÷ýÈ¡¥å© ²¥Ga Í qÁ” FqÉ2Î’sŒ1m$1B   ÞžNc}Y*“HÈá–â0Ï‘«­5®éðØV–ÔÍëìЕݟƒ&=¡:K‚(\Ÿ”Ä=;/Ñàüøb¿^ +2ûj Hy2úl[[j€–«5rAœR.ñkl÷áànGlZ |tðN¹¯¼aŠå ùBÀ(dغwp`˜û,'¿][tBêÚ€e_ûÓÍTyÝVSffò‹¡\䩧‰NA3¡}«lJè +oœ{ŸZJ,Dõ`ÜÅË$ ì+3bq=Zyœz(kW ¢Ì º_­iÁ¾;@Õ»µÓkrI…Q6q¼('Ú•‰ž†Øµ±V‚o©ÉŽËÁcœð*i$UrdBÌRà¸4/Ô›$ÒBzÜcNãNA,ƒ†]NC-}É$î +IÅ!v!‡©ðnÛCí8ÂÚ@F+ª‰v¢ +š* xW½Èäq“ÚݤÞïC¹IÞ4H³çàön Ÿ åPEàÛãøn–}~[è-!:V¡¨î„‡/‰ä·*àŒÄ°£nF’sh«t–¾à2lr P`Ô€¨ +m^p·)÷èž÷ùXáò©‘CçHˆ’ˆ‰A'¨:äsšÒkó¨tuÛ»ÃvÏ`ö~÷¹2R-R Œ€Ñ\Dæ±ÚýˆDŸ*|%¸Á¹+Á¿Åd¼‹­!4cÐŒ¿‹ÒÅõ›>¹Ð$P:伕ˆùy +x¤âA¿üA7-þàÊFÛšl’$ãç°Ž„½ò‰­ŽRÃÞÀGc¬vëë„«‹ÀHF[¥fÑî2«UE{»¢—ÿaPº²/ŠõT×jÝ8®CVÛÝ˶‚LÖ²(ßâÍý…êYýö`)=]¿'aƒÅuõµ Er¿ +¡B5p<º\ÈúòMXëÀB&«Lü’è ØÕ˜ðÏóÖÃŽëé–Gy©€{;c’(•C´gÏ:+eÔõ¦è’\Õ)l•R´Â­KX%@@A+姖FÎ…«°U¬‡žÕí¬Æ.€T%¿ ©æÉœIê!ÉÃÔ¤ 9FG`8ÅhZÿÜV¾¸æÇ…Õi²¿3‘ +çâÕc¶ïl¼¦b¥A+Ëóò±wí晃Ø*M!…òI’Š—1£ryÎxæ ¨äè @(·žíçjË/ÑŒí.Ë×»B‡ïÈ!sp¢gÅåe¯q/k˜¾Ùßu RçQ&™ãÄ¿gî-$ëÊu¬üóFÞþoàw¡ŠíÄÕúðÖýÖW+ãœ4wL¼ÈE|Ç3—bM© +!Ù˜Owd©2&? ýi4 ã÷þ(Ù 'e‘ ¯}'TŽ–j¦ÈåÞ#-³g~ÈËü#»à®°^€ª”¾0» È⡺l=—àSÏ%¨r‰_ô\‚¹„ (²Ç–­#Șpá±› qÌ` #yAhg’1p¸v@fåÖ®aãlqò§“fÔ0u¾ +´VÀØ$ ÄÄá;çéĬņŸàl<Æñ')†íè°pp«l7ôhh›øÚ$4Ü5%®l9N¹ÐÔŽ´4pïÖPhŠ#®Ÿ¨é{"ꃤ÷D»¥«ÛÀáÐÆq €¯?ÿdi hÔ`/„]’¥é‚ãûÑäýÖ…Ú“÷Y˲Íó"]™`š‡âà Œ¾øþ6ç(Ë¢Ç#—eM8J•¦:âO¤Žðï pøïäñÿÙÂø×èááRºd1é°# +Í“%åÃß7“þ?(†endstream +endobj +1027 0 obj << +/Type /Page +/Contents 1028 0 R +/Resources 1026 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 999 0 R +/Annots [ 1030 0 R ] +>> endobj +1030 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [120.1376 318.9001 176.3563 328.1154] +/Subtype /Link +/A << /S /GoTo /D (controls_statement_definition_and_usage) >> +>> endobj +1029 0 obj << +/D [1027 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1026 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F55 1025 0 R /F21 702 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1034 0 obj << +/Length 1676 +/Filter /FlateDecode +>> +stream +xÚÝXmoÛ6þî_!û`ÃQ$×Oi¦îдKœlmW Š¤ØBõâYr³`èßQ$eÙ–Û  ¶að‰Òñîx÷ÜsgÃx¾†K»~ýæôâx"‚ñlúúürâ ¬‚ñÉ‹ã73'ñu'¯ÏŸOÏ®6z&f/G§³îý“Ìô~½ÿ€½ür„S’{w°Àˆ(E½bp†xÀ˜{’.G?u +{oÛ­ƒ‘#QÒÐQÖ $ˆ+Å=Á +¼Ò¡;6'«£b™§æ¾Èʬˆr³ˆ«òWŒé|½Šš¬*ÍCýÄIgµ¹Föz[åyuWÿ Csô< =°çS…¤”­åéýÄ1¯Ê$þ­[ý©7zVÎ')ÎM–£|^­²fQÁ'‹"Šý"áOž¶[°“¦­tÆ«´±¢1»¸¿¡¼œž]¯oØu<+nØtþöòYóöç`þ¶¼ÆÓ3²xwv5W¨ûéÙé<¡J¿ûѪ÷·]2F>ï˜6ŽVKªúðyÌæ$½Öyã×éêSº2Ò„ +„áGÏäv´Á¢A/vƒ>’ž;Xp©ª•™-\Mj¿·¹½µ×²n¢ýÅÜÕv?,h×gá¹'ˆë”ZÔuJýº2;šè£{»LãL06ë(nç»ïœ| gu¼ÊnÌ]¹Ü±¶Õ"µú› ºì­‹òN;s'òYu©µùÿÔ¡¢HH!=%so£t9={qõf7FD…œy}ÏÉN倗ÛI Ñ•±å扆½3NoP;²ý,â`€ ñ dàg3»î¸’DPQî¡-€ù†õˆdŠ!róŸú_E0}L3`ՀЯ ˜{ÂÈã<;½xuÂ=•á=7‡!Ü÷óÁŽóÔ1e×HÓ?²æ0Æí¤ÿoŒAŸPRð¯`ŒRÄE@Ʀç³Ãëi|4ˆíy9 ±¾›ÿÄí¤ÿˆH8$„‘ fE±ýrï[%üSEBaðšÂ,Äà'Mì}µý€ºù® íIy€r€d`>b¦¤ui4¹÷y×}iµR=×ÿ„­gÚendstream +endobj +1033 0 obj << +/Type /Page +/Contents 1034 0 R +/Resources 1032 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 999 0 R +>> endobj +1035 0 obj << +/D [1033 0 R /XYZ 56.6929 794.5015 null] +>> endobj +126 0 obj << +/D [1033 0 R /XYZ 56.6929 424.8255 null] +>> endobj +1036 0 obj << +/D [1033 0 R /XYZ 56.6929 397.5211 null] +>> endobj +1037 0 obj << +/D [1033 0 R /XYZ 56.6929 368.0037 null] +>> endobj +1038 0 obj << +/D [1033 0 R /XYZ 56.6929 356.0485 null] +>> endobj +1032 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1042 0 obj << +/Length 2335 +/Filter /FlateDecode +>> +stream +xÚ¥XKsÛF¾ëWð¶`•9™7€ä”õ#åœZK{ØJr „´#ÿúížžÁƒ„äT¥T%6æÑÓÓϯGl8ü‰MfW¹Þ¤¹f† ³)7|ós?݈°FÅŒV +>VfwFeÌd2ÝìæLþ}wóÝ;)6’3k¥ÙÜídzlš2#­ÜÜ•¿&¯Ýq¨NÛ4<ÑÛßï~¦mš¥Y*p‡#R&r؉~,?»¶¨JÚñæÃ-ï*7œOU?rš)‡xÖ0asã9h&¶;Á9O>tC½ +[Ô&g¹•6ìPœ¥:³~‡?E)›|øåîý»ÿ]÷ø›&Ž>UñèÚº?Ðçðè†0ß4Ý—>,r½¿,Ò}uú\ÂÄÐÑâ–$ +,ª:®mÜçêj[št{Ä£ª ^/†W‚åƾ¿vmõ/X(•IJ78k¹IÞ·4tÚŠ,©úc×ö 7üu£f'5 i™i‡ ï kujÁ¬ViX¶÷‡t‡È×ÿDÍ MWܦ:y…j"ÌüR7 QÅcU|Z +ÛWQzo¤ê!ܵWwá¾ @TÒNؤ×](‹ÎïB­…VÇßqª8ŸHií@øpmù*lÜÓ/X8Ž´õP»!ðq—' '×ö{ÒM™ƒW Š„wzO“CGÐWÝî»ÓÁ ^p÷Ýy yÅŒî,uú-3*8œK–½"–^ÕHx QV}qª“ÞKÊ5'‚H"žÞ>“jt¢nÆ¿nqùÍÛ»)e¥‚A(‘ &ŒÍ1%ÑäéaCÄÇY×ïæ(‡-ùŠ/Êr[“0–IH5b.DÓäü„’éË‚Ä\ªmÎ$å¡àlà:ÚçM±Éh Ck,—Ó:*uÅFpL¦µÊwMßíž5x“ÍUt“kã@ƃ£&¢ð/g\¿›o¸ÖÉ5ß…qðªÁ8é•HV‹…@W¦ k¾%Ä'ÁçØ,¹[u¨tPõßH¡©æ6,;R +º¢kèf>/ ûcUÔ¿q.¡Bú̦ ô¥ +Ù"³Õ!?}|÷š¨¯–]ªeô2ÒàV¸òŸ7¿þÎ7%èççÎTž™ÍøàX¡åæp£…dyntinnoþ3r„–)fHXçEû8ð +dܱdµ‹Òí”æp3µ°ÈxÙý&Çü’A̘’šböÃLÇÆj4gÿ²ÝY‘ÜÁ™¼½Ô ðÔDS¡ ÷Qºùs#×y®hÑŒöwtà¾{›7Üh3»Td¼›sö—,3Oš)ã©2È5†l„Ng¾–ä9VË­„‚´•‹Î|Ý +Èmø*\K+1 iè¾Z°Ë2 aI™ã´rB¼}UPIëUéiÜã’'Ú[Vû­‚bwn†°²¯Ú2 6{ÁȆ"ÆVód +Ž…6 0i“‹`¸CÕ÷. !øó|¥„ +?HZ_;µÔL-¸ªè·é\é/l„Hn1¶öOuû°"¯äY¹¼(cžOP"ha×µ 2|úaå¹b:S&0ðø†"X¥ŸŒZFpá΢¥)›Ho#ø…sžˆBý®ˆ+Ip+ò1Ｄތå\E”7*¹þ‘N¾ÕQzU‡ß™>/ëuWT à<”ÿYvÀü:ú9TÃcç}'{o$œ+KðYD% *W ûù¸®¬šjGiaAز Çøº1;.šè€Ú=}ÿD"€‡Š¤-‰'|ƒ'¬ô$úúÒåú@ KT·¿hõb|cYÜ—Õq‹FÜCS柱‚ÖWKfKt?¯¢«_ÔK)”]E壥À’s°” +ǪÖÝ7È?PQ~²-š3é ‡Ý<Á4ö(„A_¹;?ç@V±Ô¤0€×7ËDãš8íŽ]Sk°ÎZèÚÓ늆òJ‹ÊQQ^Ÿb!˜ÌØ\x°yÍ\bȨ˜Áû%¡ì§e‘ùÒeÐný5uX¥Gçy~¼}ÿÓ+šÿ[iå»0¤ˆ¼Làk™ws{h‘¼ÅrJHP·‚ö{tãµ`ƇŸ +ÐçÍÓôCÕV'wʼnü.·S:jùµ4¥ná%…Qð¹-ø7B0­g¥Ï ²[»¸Ù©þÞ?æIýÞõÑ/ã”cqÅ´¶¯Z|H¤g°‹Z]½úë>Y·¯tpVx|‰œZ¬êÐIK_"åø9–±?ºó©ekPó >À@p‚?úÇ03{ ”ÕÊŠ†)¢-•Z;¾2™Ñ0XNÀdª\~Óh~ØÐᵩ¤IªŒ6>ˆÙé…ÏîbÃ]°jË®Kf‰ÃYC[5îÜñ„J +%8 ܇ ’F¨É:@y¬Ú‹i<üä|±ô=êw¸O^«@"vÂk`?s!'ʧƒù“ÂM˜¨/b’’/ÂpzÞñXEÃáé&Oª¶ßlôòU:ÛÔÆšÊþh× +¾àæZÅZÖÍÀ +@ׂ!z6šMAb™^‹'ÙâkR>3,OΈÀZøŠlIO°›ó:Ù…Á;°Þ©.¡b_½µ8YÄ{Äl^Þ×­;=½ûÇîÜ”ã+í²¬Ue=ÄìqpíÙË=ÆùÚ£‰2L#¤Y{Kš:‰iÑÊ[‡â™nd… +ù³/‹+'þ¹ö|endstream +endobj +1041 0 obj << +/Type /Page +/Contents 1042 0 R +/Resources 1040 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1056 0 R +/Annots [ 1046 0 R 1047 0 R ] +>> endobj +1039 0 obj << +/Type /XObject +/Subtype /Form +/FormType 1 +/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf) +/PTEX.PageNumber 1 +/PTEX.InfoDict 1057 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 1058 0 R +>>>> +/Length 1059 0 R +/Filter /FlateDecode +>> +stream +xœeU9²,GôûeË@@Q ‡!é¡%bd(dèúʤ—÷ÿ(žÑ¯ +’$¡T¬)ÿ®ïë¯ãïãÇ_¢ýþÏaíÏc‹®½Ú¿G—=ûÌöÓ1ÄF¬lÖ]töö×ãqu‰Ý¦‹÷5š”<8Ç—ý:\;âúãñ‰üéÆ&ÞЇ h—õ:ÀÀX=&02²oÒCó eD3PMtð1CrZûbœ7³}t€mA£d«·íä'ÐWŠ!è®»½KO(°ƒÔ¤‡tÙKb•^¦Ìì »å*’ÎÕBêFåmY¸™`Uõ´™Õ -¿nÜž í½³`*TûÞ£jg“¾=Ås–A½R?Ô =}³Ú§l +¤Ï’ÃigÙ¥—ÇáC6uéíÛ&”\Ê GTœ„Méêö–KòlÜ’Fyu|?é%åiÈ¥K”êNÊq{vˆ*êèJE¢]8hÍò¤p0R±ˆ$Á(+Á nÖN¬ +qª„Ñ«ò^ÿï>‹«>÷— .13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7ÙaÆ´Ëdô 6(WðÚºK +г2"ïE9~  +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¥Ç™åë—Φ@±¯iW H +þ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 +1057 0 obj +<< +/Producer (AFPL Ghostscript 6.50) +>> +endobj +1058 0 obj +<< +/Type /ExtGState +/Name /R4 +/TR /Identity +/OPM 1 +/SM 0.02 +/SA true +>> +endobj +1059 0 obj +1049 +endobj +1046 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [470.3398 477.3512 539.579 489.4108] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1047 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [316.7164 465.396 385.3363 477.4557] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1043 0 obj << +/D [1041 0 R /XYZ 85.0394 794.5015 null] +>> endobj +130 0 obj << +/D [1041 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1044 0 obj << +/D [1041 0 R /XYZ 85.0394 580.0302 null] +>> endobj +134 0 obj << +/D [1041 0 R /XYZ 85.0394 580.0302 null] +>> endobj +1045 0 obj << +/D [1041 0 R /XYZ 85.0394 539.9341 null] +>> endobj +138 0 obj << +/D [1041 0 R /XYZ 85.0394 315.9171 null] +>> endobj +1054 0 obj << +/D [1041 0 R /XYZ 85.0394 282.0038 null] +>> endobj +142 0 obj << +/D [1041 0 R /XYZ 85.0394 146.7217 null] +>> endobj +1055 0 obj << +/D [1041 0 R /XYZ 85.0394 117.3479 null] +>> endobj +1040 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F41 925 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1064 0 obj << +/Length 3348 +/Filter /FlateDecode +>> +stream +xÚ¥Z[w£F~÷¯Ð[ð9#4Mþ93öÆ9‰3k{/'—‡6 ‹ …k4¿~«ºªHÌæaè{W×å«‹®ø W2ñ“,ÊV*‹}„r•ï®‚Õ+Ìýý*ä5k·h=]õÝóÕ·wB­2?K¢dõ¼™œ•úAš†«çâW/ö… 'ÞýÃûÇÛŸnž¯UìÝüx½ŽdàýòóÃ-µžožînŸ¨û[ ƒûÿÜ=Â7¼^ GÞûïo>>ß>Ò|̧Þ|ø×u†ÞÍÃûÛ4õáϸ»½Á»žÿùxûtýûóW·Ï㣦/úóê×߃Uïÿá*ðE–ÊÕ:fY´Ú]ÅRø2ÂÔWOWÿœÌÚ­‹Œ ?I´ÀÉH,qRf~"` +9ù¼-áY‰òLÙ½•µU]SKצ¥V›çÚTm£ëúÈ«ºªçÍÈ×ߢ(.†Ý¿Ä_œéÝùy»Û×e?öš¾lzÃgoÎûB÷eA/mc‡S¯gZ*·ÑN €ë0ô3)#ûªß‚ ªKf,$<±ÂåYä¹oÓöÔ(èhœÚíÊ¢‚Kíë²ÐÓ›Þ²æJoyý±Ñ»*§ùô(ˆ¼—2׃áÃú­æ íPtà‹›l[j˜º=ðªmÙPK/½¦ÖÝu˜z¯x@”9~@˾¾'vAgc—À_x ª±O4Þ7¦/uG"ffG©‡B›ŸW”µ>ºó^ŽîúZ!À7”ôÝUÍЗƞ*@aàUUóJsº(ªÞ*Íü]dÅD¶!³²ÇâW*©µ¯u2tSÌ•”ößįH¿à“œ”†èÒ#6˜^wÌšd”©Û(=³ú¢=ðimGëòN›­}PºFsl0KuGšaFJïvèð©¶C*H;ˆe@Z“·Ý¾ít_ºšJì! ,bY7ts¤Æœk¤i–í§ ßx?Ø®ä±ZÞr:U`‘Óï·ºy½¼Œy;ÔÜ'kwÔÃgîH¨GËw –;³«ûN7fSv|©º#ŸÐZÌÚÚJÒÊ+ècª]…Vb;í´~ö h‚wRŒD,)CÊäÔÒy­¡ñ\7„0Ü´ÝŽáPFdß0 +0B +‡cG.º‘'`d›'Ï O0ú:hàN_ÒqõhKµeH–°˜3åíZ+æÌékܧþĈGà @·¢á~Û˜%Ò Ó6„Ê»¸ð¤ýxÒÀqÆ<Ÿí>XãÉØ4` lÌÀ-Ex·9¹ÉZcÌV†Þã²  ˆL%s°ÇéÂbåË4P!†Ä£Ð —ÜdÄœ®[]œLú_œSO¸;n\—ͨšëHÅ~áWTtâkýñÑ!ˆ-n Ú`Ì™‚p›S’ëuçA˜•w3g÷Ë<ÏÖÖæo–“\ò!@xðÓ$'þ+]r«éqi8ºUŸç=8ÂÝ·yË{-äÁNM]BhhlZ>ÄÔŒ?Ç[¼Ð&8»’±Z'ÑÀbà§~· §ÈÉ0ž âq!Š“é5Ò_0 \¨NNTZV ÖFÊù|é! ¨uö|ØOˆá¾Ì+Tzrº ‡Ò{¼{O¦I{râ=•åy +'9™¬â,ò#&ÉMv¯+j²)ôS€§³J€KÍÿg™çg ñJ`Ùyg RSúiŽœ L§e8j R6êÀ.ÕýqÑ|׎™ +%8LVì ” *Œ +& âN‰°Mó|®8Ø‹iK…mØš79K(H~ꊊéØiA-j’~+¬üâ–Œv(9•8ÎV¼Ó´;)Ê +##¸bV¶XÝom|‚—ñ×–¬p5qfz*xŽ°ØžØ_ +AîO†–H6ÉDžÅS0P—ú“¡¦cZDß-“b ËЯ¿Uš:%„$|ÃÒ 0UÄ„Ìň¸â³Æ_*ø'" “ÇÃmI [F¿½¿&p^:ÿ'³€d†UCÜHµ*{œtUhÌ_H3GZßØÚŽQÄ6[æ?ÌïJˆ`PªByß·´V §Êƒ-9ßQCÀJÀ.]ŒVæ<¤gXÇ‘Š öao’õÅ®$ÃN©7ê¢í¸j)l€°˜’BálÑþ°B §ã\YNcʾpAÛ@8ÎF}ûßBÑ#,&Æ,¨’qÔP¡‹V !¨ër) SÔÈ·-…ÅŠÓ\øn@ÓÇ!/4Ù¦Ok÷üª½º=¾Æ€@J4Õž†Ð{1Mú"–õf~àÅÏ,¯¡7„7ŒmW‹¨xÓ°ê` :"£HæÈs„Œ"™ £„Œ.¢NƇ 6V»@Ý⎺.j¶äCßþ:DCÕ‚`V -cÝ«FgÃ/å¶jŠ¯þÞדߠRÅ8hSwD§0 SÆ:vô*²øàä +^0d~œ,Ĉ5ˆF(,Ú|ÀÈ­]¼ÇýÆ|BÎI„@„qHð°ž7o¬*žQ¶A4ûÍä…õa0îWWÍvb6C«—~ÙiÔ àÙüw—ñ×:WŽŸˆSNœ“ѽÆFxBùi˜ +ú!G‡·½\@_x¥ [¾5&~(Š7,ûol +©mø¯(¡Ÿ¡AAÉM@rgJ'Ï¢«PÅ*s5M¦ õ@¬ðù T$±/ãx¬ÖÊ`¡ð+|*س«ñsröçÇI_I!Oç…DòV»·¹à ;“_q‘©¨´ž9k¢Vó2‹T…Kd'çiÏ(L5Ú&uU¿¥ÖÜdpÄ©)AìÇy‰M‘#¾ÿÈ5H% b“ Ü6è;q* +ó§ñº«¾¸Ë8‹W‰=öÃO¿PÚ¾þ-ÿ.ˆî˜ÕšÃ0«QΩ\þzÄwþ맋@Ç‚ÎWlb?@~Hš²ôO"BúøŸ •¶`´—ÿûHNÿf+_¤i´\²‹TêÇ)ÂD!ߢà‚r÷Ÿ&—¤ÿbÈendstream +endobj +1063 0 obj << +/Type /Page +/Contents 1064 0 R +/Resources 1062 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1056 0 R +/Annots [ 1067 0 R 1068 0 R ] +>> endobj +1067 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [464.1993 488.466 511.2325 500.5257] +/Subtype /Link +/A << /S /GoTo /D (proposed_standards) >> +>> endobj +1068 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 477.5271 105.4 488.5705] +/Subtype /Link +/A << /S /GoTo /D (proposed_standards) >> +>> endobj +1065 0 obj << +/D [1063 0 R /XYZ 56.6929 794.5015 null] +>> endobj +146 0 obj << +/D [1063 0 R /XYZ 56.6929 556.0057 null] +>> endobj +1066 0 obj << +/D [1063 0 R /XYZ 56.6929 521.4772 null] +>> endobj +150 0 obj << +/D [1063 0 R /XYZ 56.6929 361.9951 null] +>> endobj +1069 0 obj << +/D [1063 0 R /XYZ 56.6929 325.2573 null] +>> endobj +154 0 obj << +/D [1063 0 R /XYZ 56.6929 133.2872 null] +>> endobj +1070 0 obj << +/D [1063 0 R /XYZ 56.6929 104.8892 null] +>> endobj +1062 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F55 1025 0 R /F41 925 0 R /F48 940 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1074 0 obj << +/Length 3001 +/Filter /FlateDecode +>> +stream +xÚå]sÛÆñ]¿‚o¡2æå>CòäÆJãLâ&±Úfšd¦ ›¨)€! Ñj§ÿ½»·wÀI©™>u<2îc±··ß» ˜qø'fÖ0®2=K3Í f¶º»â³÷°÷Ç+áahCýáö곯T:ËX–Èdvû.Âe·VÌn×?Ï¿üúå÷·7?^/¤ásÍ®&áó—¯þr-„˜¿|óåÍ+Úzõæ- ¾ºyyêù퟼aµ±ð^xóí÷ß¾¾íßøõö›«›ÛŽÒø6‚+$ó·«Ÿå³5\ê›+ÎTfÍìÎD–ÉÙÝ•6Š­TXÙ^½½ú¡CíºW§¸c”eÆÊtŠ=Ù{LÆ%•cÏÍÇün·-^\/”¶ó×ÕŠá>û +¶û7Á’T8_9äUÛ¼Ìæ% 켬Úb_å[Z^mË¢ƒikz. Í—Ûb¸³¿v^4õöÁƒcl›ºi«ü®ðøòj¿ŽÐ«M^½÷Hïòr‹W˜-Õ !XfŒ$âËv€I:ßõÎQ㺢g» ÷mS® z’ÈùmX^Õw»¼z¤I¾mjŽÀ°ì=G`]qïZÿò&ðØóÕªhÜ®ívWžÍËÊ݈¯NXÔÕö‘TòŸu…lÂa»É[åt8Mª:¬>£Hn–·[xøÉ»€Ô/ô·sH‹öPï?°ŽJËd­£ò5²V +GźØÔ{áÁ2Üxº-›_ß” *£4^°Ös^8”H!.7EKK÷;ÿîÁ#…†–p\Aý oíQ Ym³ùŸªb„Ìã‡ÑÒoÕþHϤ<Ÿlǘ¤Ùün8HÎmã`à‰XØëïi§Ùå«Þ4ujŽûÝ«5Œö©ÅM¢—–ª¢eÞ´eíGB¶J ʺ)WF§0ùEJ½s õÇGœ /KÞÔ!+Ø*¯üR¾ýàG5=—5šŽIÍP›Ê€Ê³íEЭ‘²½úîo“ªEfi¶3/aœØ NX^zàU]ý¹|O—_ÓªÓGx¾«÷bËšäáýßî‹}Y8å´N±k;ò ZDL™©$ .´)ÛB°ŽìckKl"=ø‹ Œ mãÝ~¬ˆYþ>Ì)©PJ Š ,q¥àài…Í:œ ’#— ?Ëc>È'a!Gqi™ŽhpÐq5(ÚMz Ç"™‚8ähR "‹=Î:´8!]Âùl9ïU´Eo=,ê8¡…¸ËÉqaZ?Àb™6ù=\?ÆŠÙ€’“¼öÜ€œÀhžüÄy)Ë Üž=.³#Åy†"Rø™VÍ”0ç*î¯*…f‰„]Èu&çhú<™{ç׫–¼Ã“@2˜$铯™°Tu¹Óôý …yòõÆÀu OE1“‡˜™Ä.f!ü%‘s„ÉÝ}㯺,<—Lʬæ ÌãØeJŸás]6à$ëÍ(€Aç;XåèCCs¯á4yG¼¿ó80Øã O¥O]S +î·ÚÞ¯Ëê½ÇïbЇ½ð™Ð1J5màŽË†»Hé’Ö)qâx¶Iw(N•Eñ ÑGÚ.•u绸|¿Ü–+”݉N¤#.¸ZqByÁý +Û9S§¼¦$K2¡/él’rñ,G–Wð¯¸\Ó0Åd}H¶þÜo×tq®²ö0Í=%0bž7ýeÝ2Ÿ–ˆ¿+Ÿvú7½óE]g•;t|ÄfR¤ÎPp‚©Ü”+€P)y°ÄÃápž•d—ø*LÜì»vw§9$*Àcþè,Dûˆw‘õ•’TÂ]껟|Æ©øÇNß\ÃR(LÃUØÝGïgµïkŒjåù;$`™Z‹K|ô*¸Ä/0Û°DwJŒ×dAö +Ž“v¢N‘ Rëu‰ÆŒ¬:3äA7&ãP¢?Á¦ãVʳw”œñä¹&!WÆ&E×h6dHHº¯0quW¬Jrv|þÝO´x$w\tÙ=…¨£²ê($¸ºÔ©¸¹õªËšÑ=£ÚüýÓO‚ré)åÒó] aŠ|8¼C1B_®#_»Þ—C´2Á]`𘪢X»¸„¯«üÞEˆ"lSÐyOÔ8kW»ÈP*KÏ?Q`‚A¨Å`xÈÚ+kÔ|[×èR°ˆµ©Ãáâ# Z}]lˇ€ÃÓm·p_h\kËž"™ÿõÚ˜yI– +õ’Šc"DŒdñbTnbBÂëê8¿¨i@Têuï÷b3TyúBá9¨7… +/ª}µX ϶N‡ø¯=™Ÿ4!µ¤§·¨a)šwŽÙ‘àsȳÏ'ŒŽGûåškŸ:šÀfØ,ÕÊ£ys½H8aƧàô š:Èû§ºq‹€tpÝ7¨`J_—Ó¨x¤v–v~•Ä‹#—±8ƒÙäÛw~Í?AÓ]È¥YYuÃB—6Á¬¯ß•Iz >-‚‰ïàÐgEîÅbRC]>ijù‡ÊÝŠgd?]ãˆÛÞ~pÑß©ÛÎùo—.´MÈÑc[gØÂÔ ë@ qQKG¾DØûíµ˜?º²Ë¼uß­·úB‰gÇ$r8GÓŒÍÏñiØXñ +<‘šGPÎÁž0ÓQ ÏU®QÓ%>d•£öxw½{¤yÒò~è2«<;pcVÅM]Ü },åûXèj›Cähpç‘ž]²7ÄØçî2 í3XîËŸÿ¹Õ(,xbSz(œô…‘Ç +|_æ«]ûôß;N]W—¼hs²½*!DÚŒSº¨0¾‰Wk7ªéé;•0Ú]», …JXÌQ¹;Í–RÅlØ®·ïPS„ ¡wlÂŽ5´ƒ2N<ää+ á`ÊvE±kqOä?³‰ +I!ñNDÅ/e¤ó=mEû$…÷ +Ĩ ìSgyT©¸¦y32ËÛ>xßUP‡2Çm‹U[>xHäÍÈõÄ&œí®ûøUÀ ‚Ãv +“7 `©gŒN¡wbAÎÇü&ePÁ†¬¶ÿL„N|&‚šÒŒ†¸;ô3½ú ¥G=û/mýù©ÏlJ~59ÿÑ0†r_Å (ˆÊZá¢jA¤ãC1×Ξ?µƒ:>v”¹ÃX'Ãc¿…Ì‘.Mi# 'øËQ|¢$Q†™„«Ëe¾J­yBÙ¥ŸY“¼Ñ Ì?%Až2®­½ ÁêŒÔe ž;5’àøØi ÆÇþ/%x¡'(ÒÄ>£‚~J›PfÃ6ãIAJkYzIŽÐi1 ‹R¨ËŒ:wjÄ©ñ±Ó¬Š½éJ£Â1|öë?ãåg†Ç™Æ&÷Q>´ì2ž$£²®ÏOòÿTÆö¤ "•†*Î\ø%J uFF게ÎÉh|ì´Œâcÿÿ‚ +ä•Pn»ÎK0‚:#ÁuY‚çN$8>vZ‚ñ±—­ $ZWÅ“¤h$ƒÜ.}’“gÇ“ÿRŠkáÄŒgÙtÒ ©Ù—jêä¤:êäÀ¤+3°–ñß[qú4´SlýµÎ`xðKÿpÂp´.šÕ¾\Ò3à¨eý€¿‚Rdþ¦n‹€*oÃ(žþÇ81E“¥eG£|$þbT† ¾ÇNo2æP`Žê,Z|¬ï÷ýOƒ¢Š£m¿¦(Æ*­AV+;øyXRð¤Íýû ~Œ”»ƒ_Ä/+÷1^dÄ[¬†Â­GÔ$œ ‰9²¯t‰‚1®è±²ØŒMÆõužFµûñ'š‚Zâï)HèùjK; šþË·S€MüÏ?“ú ¿˜á¢e"^ü÷A§B3p€>Õ!zßRX”»fñ¾^lŠ}q¦¢{‡àŽ¸Ÿ9è_1v:¿7 ½8!2øóÖð»$Ùût E«µrZøŠ'ÌÊ, D!éòHݺ_S“þCHá endstream +endobj +1073 0 obj << +/Type /Page +/Contents 1074 0 R +/Resources 1072 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1056 0 R +/Annots [ 1076 0 R ] +>> endobj +1076 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [417.8476 181.7231 466.5943 193.7827] +/Subtype /Link +/A << /S /GoTo /D (sample_configuration) >> +>> endobj +1075 0 obj << +/D [1073 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1072 0 obj << +/Font << /F37 791 0 R /F39 885 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1079 0 obj << +/Length 853 +/Filter /FlateDecode +>> +stream +xÚÕWMsÚ0½ûWxr‚ƒ…¾üÕœhBÚf:™4¸½$9¸F$Ì›X& íô¿W²°‘ƒ€PÒÎt˜Y^½]½}+VȆâƒl×^ˆCÛ)p!rídjAûN¼û`¡¥S9ºÕûÈêßAèaÏŽÆV` ;]w(  +`gxùùSÔu° ;§îƒê“ýËhp¥ækÓþé·.B¨Ó¿8œjKäàlÐïú´}½ »·Ñ¹5ˆšHõÝ Hd˜Öõ-´GbSç$ \ûI<@€ÂÛS‹º¸”z&µ†Ö—P{[-5²ƒ ÀÄÃz(Òè ð €òÝx“Š€Ü„@r¡ëâjzœOq1ê:„)ì¹ÊHòéÑJjoÈÔTH¦ÎP…%}Ôn[þËŬµÆ,óI |4í­tlÚ¶¡4…zFGy-ÃbZׄpQÄåäQŽ}*j8ÛAiÊÓyÙdV*r…Y¶ê°‘§cÆ<@¦Eo¬9ƒîª°Œ9z•Fð¾áiüÈö“Hµd—Bxo=#=Jpmy äñM6P‹w¨kãð_f³Ié›—rãaÏ:>€é½ÿ£ÖŒÄ"#±Ô\.¯!R›xŨÿoä䟥¤w&z®U;&\ÑÕQÑÂJ›AÓÉ&SžâËÆGMÜ缬Žïv3ªº'5NòìB|÷N9kõ~/œÅIjda-°‡érƒ¢³“@ú¤Yl |s¤´àN +ùLšó'ÀŽäÏ[Bì½eK¸]—q¶Ð]»PïØ8ž§Ûš?Óe„¸@Þ WØðxðEeuG£> A€›;HKôØ È2(ÉÆk‘×7šõЫendstream +endobj +1078 0 obj << +/Type /Page +/Contents 1079 0 R +/Resources 1077 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1056 0 R +>> endobj +1080 0 obj << +/D [1078 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1077 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1083 0 obj << +/Length 1946 +/Filter /FlateDecode +>> +stream +xÚ¥ÙrÛÈñ_ÁòYeŒ0ƒ{ý¤µd[›¬ãXL^Ö[®!0$Q‹ƒÆ!™IåßÓ=Ý Ú7¥*ÍLOOß(—.üÉe×Küe”ø"pe°LË…»ÜÃÝÛ…dg@rÆX?nWo¼h™ˆ$Tár³ÑŠ…Çr¹É~Y½~wýasûqí¨À]ùbí¡»º¾ùçZJ¹º~ÿúö†®nÞßÓæÍíõ:òW›|¼EˆT ¾ øåæþîíú×ÍO‹ÛÍY¾±ÒõP¸/‹_~u—¨òÓÂ^ËG8¸B&‰Z– ?ðDà{Þ)÷‹¿Ÿ ŽníÓ9›^,‚XE3FñåÈ(I(’Ä–QˆÐSž5Š.ŠúÑùÒ›æä¤:=˜µºîêß´äUgšJí+:›¯Óó`• +6WWhLÛ5yÚÑiDP§©i[´íH)’ P# “öM›×ÕwóWþ³ü/Dgø +!¦`9Ÿ“GÀß(O$èb„þ«®XÍmÞ)ÌW] #Òº|qVHzcKµƒ÷…~à­%…,®öÝéÈx¥nÁ¯æÛåÝåɳ«k+Ë«9É]£«vgšïµÿÈVêOØJÍÚê0€µÙéß^ßÕŸLÙN×UÝLóy w?ŸuÛ}.õik¦šÏÆòŸ3åZòê äì%µ'…ù¡Å¹«¨hØ„<É}5?Gˆ YR`‘j7C8Œ…ò}ɸŸÜÀ­¢m¾ôùƒ.LÕT¬ñµ6ÐnH¡Å?Ìæ@U‚º7èYž­ÑMz »|“¦d’J—¦5ÍÃ`e)!CÿÕœŸG÷¾ºÏ“Ké Ï»"5â˜\E²Ýu/=bÆu®ð•"üÍ!‡èSa¸VMK{¨›·Ájßç™!hWó­éº¼ÚÓ¡?ÒºYC“ÂøÓ){€ E¥»¾YËxe˜zÅcO pœÉ˜ÅS +-VÒ¼;±˜ ýñîý í]7gÇÌ´i“o‘§'ƒUzÐÕ~8 vÅÀ±·uõÉuÕ¾o41F B +FÐüòÑÅÈAw3,4iLÚCÓ&#èc7Y¾C8¦-^WLog.†{9Yy•}F~§ÁÑ>ªm×£DÙÑš5Ý]ÞL¬ €ß̉é*£Mß>Þæû©{ö˜wÚ‘“É!eXÉñP¢dÍKÝäʼnŽm`Föf"^æ-¯UÛÛÇ‚’æß`Š0ð&!@ætìê}£e^òÖ>ÉîP¥3‚lO´’ÿpgeðØé†Õë¦ÉkîVœÈŠ3t˜Qû–žðbü  öÔ²‘¾m-~ b•DŒÈRRå™#§öT´‡\Óf~|@6IbÅdßf8Ë@Dž8cZÎŒ!®}ÿLæ4CÆÑ>gâ'ƒ7Ö“s1,òŠ«l}ì83ñÀcJ^]Ð T?Í´ w³††QD(é,!â9MCºQÈ8â2 ò‚ +ÌKÔÂKàÔUÃd $ÏoMeé(ÎýA7†Õû˹üï•nuÊåüƒÎ›©&ï`Æjç§ ’Æ1:C‰õ¾î¹³S©:nJý5/ûò̃6ðEµ·n憥 R±Ày‡ßˆ*Q$ÔLC-ÈKúüE¦»a´NE\–Ã,Ô ç2,’ðq=c³>å—š–‹c9Èq@ãèôãiP§™¬j¡â8ðâ…>®Më¡Ô©SfC·üé¥b0ú»¿ÝoøÁ(÷žû%Î þ|6ó»™{®×ÿ÷¯t—Ÿ%ýút¬Î?ÀMòËsCjÎ,ÚCyO%?ÿœ÷­èÿ¢ „êendstream +endobj +1082 0 obj << +/Type /Page +/Contents 1083 0 R +/Resources 1081 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1056 0 R +>> endobj +1084 0 obj << +/D [1082 0 R /XYZ 85.0394 794.5015 null] +>> endobj +158 0 obj << +/D [1082 0 R /XYZ 85.0394 427.2881 null] +>> endobj +1085 0 obj << +/D [1082 0 R /XYZ 85.0394 390.6298 null] +>> endobj +162 0 obj << +/D [1082 0 R /XYZ 85.0394 229.0656 null] +>> endobj +1086 0 obj << +/D [1082 0 R /XYZ 85.0394 200.0179 null] +>> endobj +166 0 obj << +/D [1082 0 R /XYZ 85.0394 151.3455 null] +>> endobj +1087 0 obj << +/D [1082 0 R /XYZ 85.0394 127.291 null] +>> endobj +1081 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1090 0 obj << +/Length 2296 +/Filter /FlateDecode +>> +stream +xÚ¥YK“Û6¾Ï¯PåbªlÁx|Ä•Ãx¿Kÿõ¼iÙç/4㟗×?üàQ›טYùûf>cWÉ O„µØ7ìÉBABH‹¦~l/gßó#fÇ¡ÅRIbÈÛÑD„p4v‡#|¸'ÉLåÝCuûb<.äÑ0ýì”{·öüà3•º‰ÁEø –‚;`»lF¯O\_(ãÉI™¡‰ì=K€7EÝé“Ý>0ŒHiNÆÎáëºøSƒ¤0`#Hf!§Uæ®,Ŭj%Õ6 æ`s31³Kµm¶¶3ŠuVŠuž EWRª›ý _œë¥!ÖKª[«¶Mþ„zƒ¬3¨¨0ê¯éêkLHÂD„¡ýb¯öey8n£œŸ/õ‘—Áùíu{ºŠQSµçD×û´Ú?µL +C9¹‡h?ƒÆÃxÿ¥Í£òE¶‡ M”˜-¶²£ÓÁ­G Îóî!Ïkìt 6^˜Ùú EoCð kŸÄE•jWû¶Ãõçf´kJ³ÃÃÆ.F¤®±¢à×–UPLÍ6^<›Í»Åéã`²Hü¯8l+„¯ÒaDÄ,½Té0"ãÄr™¯8-Ħb&ˆ%Ûã8Žï×XübeMǨºYá­0DÈH$e:„fëUØé_©0˜MžÖ2©O^ýí/ø“‹†÷Çkkœš-y Qš47C[cÕObUÚë/2—Zh¡7`ºòý®5ãÚpð5Á*ÒÈËÀy +mÀ·lr3£n:ä‚€ë2ý Ô¬6Ûký€ ®Í0˜;gñ²{‚gQS£åäPzïÄS_t¥$‰¸\À‹Û‚ìºÔJ#È(8‰bÅ橆3좰_öyk,¥³y0£—ÚJáÑMƒ=Š²ÄÖÜ ;hÓ£ú[R»ÍG ž 'T~†â‰Ü=_>íªcÄÔÏ• @g"ý2¬pG¤¦Vó}N£øà…NÁn ”ƒûø4ÕïýzÆ\µÝ“„êtPCaÚa1áx_–ýtCBQû.x1ÔªQxñœ ÏÜí»VÎ[ïÍk &ºC[·%ÕÚ{6f°±ü¶“ÛîÛ‹Gõ°…D?@DR¦ìò12·ö¥¶÷º6^á‚H)£a\3ǞĦ$ߤ69÷£ Ü3Ô/-žŸX¨„ÿûã/XaLD’pÿo5꧊P½Š¡”àø2>ÜþòóXôÿL?øñendstream +endobj +1089 0 obj << +/Type /Page +/Contents 1090 0 R +/Resources 1088 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1056 0 R +>> endobj +1091 0 obj << +/D [1089 0 R /XYZ 56.6929 794.5015 null] +>> endobj +170 0 obj << +/D [1089 0 R /XYZ 56.6929 691.7741 null] +>> endobj +1092 0 obj << +/D [1089 0 R /XYZ 56.6929 668.7722 null] +>> endobj +174 0 obj << +/D [1089 0 R /XYZ 56.6929 579.8329 null] +>> endobj +1093 0 obj << +/D [1089 0 R /XYZ 56.6929 549.1878 null] +>> endobj +178 0 obj << +/D [1089 0 R /XYZ 56.6929 502.9124 null] +>> endobj +1094 0 obj << +/D [1089 0 R /XYZ 56.6929 474.9173 null] +>> endobj +182 0 obj << +/D [1089 0 R /XYZ 56.6929 277.7919 null] +>> endobj +1095 0 obj << +/D [1089 0 R /XYZ 56.6929 249.7968 null] +>> endobj +1088 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1098 0 obj << +/Length 3185 +/Filter /FlateDecode +>> +stream +xÚ¥Ùrã6òÝ_¡·•«" ;O'™“¬GÙ­T&´[ÌH¤"Röx·öß·/ð2=NÕ–«L 4¾!½P𧩠”É¢E’EUÚ.6û3µ¸ƒ±oδÌYùI«á¬×볯ߚd‘YÆ‹õíW¨4Õ‹uñÛòòÛ‹Ÿ×W×ç«Ðªeœ¯l¬–oþy®µ^^¼¿¼zÃCoÞàÆÛ«‹ó$Z®¹¾BˆÊ`^IJrýýկ翯¿;»Zwô Ï •Aâþ<ûíwµ(à(ß©Àd©]<@G:ËÂÅþ,²&°‘1²;ûpöá`”–ÎñÄš4°i˜Ì0%Ô ­ƒÌÚpÄ›± qVö|¥•‚#}x÷ ý{÷È×yã +n^l6®i¸}YWí±Þáùa3`½Z¬Â(È"ú×ïÞ#[S½Ìw»ú—§áòÝÏ+Šã¹N—€×5ª +nóêÎÉü¶fØãosp›ò£R!ÑÊŠ..àFáp¸*Û²® bfzõ€^é@Ù$‘^¢rÅóàý¼0 ’Dg2ívS$i$ãžÜñqK˜$ô›ý1ƒn#‘áXÐܺã ¸òPgÑð¬"«€b›-VÀÔÓ¡È[7‡$6‰áÝÌÅ&A¬;ÒŠ’ïmÓ–÷®0Ö,×ÛYÛå6§Fæ*n¹Ï­« +º/˜@ +Pb7ƒDøøÉ=6~¸© 9háÖ ì¦¾w¼äI)ÀêÓ®ð;òX᪺uÅ,gtd:ñŒaëðÉKü¶nZ½Âÿa0/ß: 2—ˆË.*^å>çûÃÎq§¾åo.ƒ,TÂz‚ŒøÇ hÞ¸¿óΑžhV¤i’ $Õ#A}ÿÃ: 6F'!È«ÿ¾zFeˆå=ÝÒ.«|_n¸Ã»ÊÝ%|›o,êj'ü,…íVÊ' iZ9y.˜šò®òndyΟîz€ +?åcFs¡FwÊñÂ}Z4™ <QÒ,’T1Žâñ}ÿzž…ËúÄìóG‚ª3ƒ™ ¥ ³§v†}Ís¸w¨Üñö´›9Oˆb¡Y¿:Ô»ró8sž ˆñzÚ´0yï$M. ÀtÓðݗͦ®0"¹;sT$ܨžpë ·Âaá©T72ê>@óË–Ì+ô{¼´w!Èj«*Š—¹Ç¡éí%c`ÐÄw‘—x‚þšƒ-™Ë„ТüéÄÕøaiÁ¡´à€?3¶…å#‹ÁêÄÒ +!Ûè+h^ÅßSõ©ª*^…ž#|ฉRf3Âå® +J–Bè<"Ùf†ce»…YF JhÈñŒD;ïÄš»›ºp<­q­ ¨ùûúâ ¦HoÀâ |s^á·Ð#B·ã ´'4ŠWë¡Ó N"òöÔí¡b8(*ªQɲ¨ 3ÀH¡tŸïJtMÈçPüÂ'|†%Âg»HÇg‚ +a´¡ ‘chÀY•Œ8 ƒÂY•ggÔ™øYä3` ¸C,ŽbbRäQl YõŠ‰í ‹ûÕ=‹¡#'‰,Âʽ A@Д…ïÜò—Ï‹Ó1ò¢CÂ"Ê„­qöÔL…3Õ1Y+Ïd­˜Éº®x”Óþžt'Y*²àCCWX¬½ðj6ø¦®ßýxõ÷ȲŽvÃC dåD|ó„ΉyàkñANÀAÕ’@("„ífOx€vžÐð¸(Dmˆ³È|¸PI$)Ï)Kòê‘dÃiG×ã…t-x¢úíåâÿÖ ¨!f͈!ú½ ¹–Y+Žc5»Ihùþ§5ÚÛ‹_ÖßJ Øد¡>EU[n@ Ä6u"ÉâPÂÁKæ#ßø¢Æ$Åè& â$ãšÁ`–™$·6ò)2»Æˆöl¶yU6{†ÞÖG†½5ø —ïÆî\åÐKR¼„SÄ¡oó3À˜„>>h8Ý„Áö¡f(þ” *QÙ0DÄ+¦‹£(ö÷' $æ{¸¢†ò˜“¡lÌdðQ ”öéÇ3¼2*Ъ+ˆ4Fò¯·ÜÙbnl”2€p â.|…WÄ$èÈ ò†´ý\SÌ\K!æd‚óUL ^""©Üðx‹UŠÕ,•;¼>À<â +©}èM¶Z¾ÄØKʵúÖív{ÒFœâ>£LÜ9ObF‰Þx²úK¸OËNˆ;µ¬Êïeïœó$๔/G{¢¥¤]ù®ÝÖ§;¤Î  .± wæ–ÐåÀ—•ÒÌÑÃD·áh¿1 ƒÃ2Šñ Å?øù7\ k49»õÖÍe¿~EY—>¯ªVi_‡$)¼“„@©â:%°ÖŽÂ'.Úš>¢„øÜ»á6ãľ‹RËÙª;£‘<*Ì&‘õ3šBÊž@²÷âÙ#•Ø‘™’ô$›™tbd2¯©Ðbç‚O?.GßÌ31(‰EŠç9&EòÉØZSlòô|X–(Ž^<^¬Sÿ›¾ÕÔ¾º$Eœ®²ë=KávÎW¨FŒ 7äáË>Ì ôTòÝúr‡ò}YŸ_ê •”Wth‚8½å ó2ª ´6~Ñ¢&ÊFs"m,LúbM˜ &v)uˆ9@†îfW’öa›l)|»°ÏO'XU¬í5dJ~ê¢Ô_¢ßŒ +È„uÒÄÝIv'¬‰6 lOˆô'™ ú´4ô¸/½‹î"ƒ‘¾b¿Ó×W˜™~¦ûœo$Ú~Â~Én|ÀE¤v^)S¬Û¿æX? ãòõÉò_['ÑÀI +cýaÒ±ãIׯª‰ÏñNý)yQhTŒ—ÈKmjäÁ-Fà[Ÿ‰ÿ8aÛG&öRPÎ~©GáôáQàYpb)h ÈHî¬&{@’*âCbÚp̆¡¨}1Þ—$ð}î3eÍAà/A¤¶D‚´Óƹ´9õ±•bâ›÷>\]òÈh¥×­Ü׃qñ°à (èeÇF~0Pʢ뷗 ­± b½Œ…™ÑÁ\v9¦ÇdÝaíÃéfWn¾#pÏÖ`rí™”jà;L´âÝ9ˆx/Å!4j¬k;”~/wDí§ûÎø“6Ù +Î&ßÏ&ü Ù"tíM6t¯%Í+ï‹Ëûrçº(£ |p÷ÐvÏ6G Te÷Ó?ûÒ}÷ˆ1z–™­Š¢®@‚¥ŸH‚±}¤£}íÑHuÕDÃb U|1ÄnyŠTva’ä/FJ¥és{AwË_¦ÞDBý`#)µ•P÷–.}±?öXæÊfä_MøÔÕt­¯ÌÓº¤½mÝþ0Éówõ¦{/j¾öwã m3WÁuÙ[˜0]ÞÚØð,÷_—®F%àõåϲ¦•g­}3®QtࣼÉcéÚÓÚ¿¶u½ógy8xAëca19Ðʦq§)…ˆù3NŠÚ=á3©“I‚0Õ>N«šácùøQ) ”íòŒà¹Ÿào7fž¯T÷îôÿD¤ÿML”&MŸyƒŒ1HÃ,ñD!á¡RÞý–ä)éÿ±I9´endstream +endobj +1097 0 obj << +/Type /Page +/Contents 1098 0 R +/Resources 1096 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1105 0 R +/Annots [ 1101 0 R ] +>> endobj +1101 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [418.3461 611.3335 487.0181 623.3932] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_policies) >> +>> endobj +1099 0 obj << +/D [1097 0 R /XYZ 85.0394 794.5015 null] +>> endobj +186 0 obj << +/D [1097 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1100 0 obj << +/D [1097 0 R /XYZ 85.0394 749.4437 null] +>> endobj +190 0 obj << +/D [1097 0 R /XYZ 85.0394 597.4103 null] +>> endobj +1102 0 obj << +/D [1097 0 R /XYZ 85.0394 573.0707 null] +>> endobj +194 0 obj << +/D [1097 0 R /XYZ 85.0394 410.9267 null] +>> endobj +1103 0 obj << +/D [1097 0 R /XYZ 85.0394 378.8211 null] +>> endobj +198 0 obj << +/D [1097 0 R /XYZ 85.0394 204.765 null] +>> endobj +1104 0 obj << +/D [1097 0 R /XYZ 85.0394 171.4256 null] +>> endobj +1096 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F14 729 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1109 0 obj << +/Length 3252 +/Filter /FlateDecode +>> +stream +xÚ­M—ã¶í>¿Â‡¾·ž×µBŠ¢H¥§ÉÎl²I»ig&=äã [ôX/¶äXòîN~}¤%[“M_û|‚$€ø -g~r¦ó$/ÒbfŠ,ÑBêÙjw%fOÐ÷õ•dšE Z ©¾z¼úâ­2³")ò4Ÿ=®sÙDX+gÕOó,±É5Ì æ·ïîÞ\/d¡µš¿ùææŸw÷׋T "’›Û_K)ç7ïßÜÝRŒ"àíÝ͵Éæ?Üß=\ÿòøíÕÝcäp¸ )²÷ÛÕO¿ˆY›ùöJ$ª°zö"‘E‘ÎvW™V‰Î” +˜íÕÃտ℃^?tR*R$©ÊÓ ±¤r&³DeÐ9”‹.`R­ƒ\@BD¹À–` ÈSÌi‘H© ?âÍáyß·O‡r¿©W “"Ÿ—Ç~ãš¾^•}Ý6„k×øÕ,8@Ôͺ=ìuGß}Ûuõrë¨Õ_Ëùæp-í¼=>m·áÎ8Ùƒ[uÿL­Ÿ…ĸ*Œ«"O”²v€ŒÓKX÷r“ hkdR˜P"Ñl‘inªíl!e“ú~÷©wM;é^*ŸWîg!ÒÆUØLa¯ô½û5Ï„RLʸqãʦ ð¬Q 0µ—ÌÒ¹‹(*×­õÒuÔ$ÑÊ Ï•'Ê8û±cPîN„]É€ÈÌ»ú‰vðïmãº$Ž°`nžþ]ƒ ‚ªýŠ•;`SÏû–Ðë qÜ¢¤fX†h@ž_êÃ¥@&*¸¡aOyjÄ™:w¨qÿž‰5ãz·gÔG0Ð awÇ®'ä’ç[·ÛmûÑU ä̘ùWïÞßA1 )¼ÛÔqÖºßæ?¸C¹Å†]·[¦è7%/6b¤_mÝš‡ìÉâW®ëxû‘y3žÅ}Úo˺¡©ò8Õ®U®/kflé`Ÿ×E:÷;µ¬5˜u»2‚UÙ9oÕyámÊ•LŽJ–%i®ŠŽÊb3qšÀëè"SLÒîÙs ­›¾#¸¤Ïúœxh[£–Ò<#ïäå¡Ü¹Þ:< ZÏß·½£.’2AŒŠŒHÒ‚$™ßŽu®ýêž½¥"Œ‡xë::úÚ&6SzlÞ¸SKf”²*¡í§CÄÇöðkÝ<¶â%W}{x¦þöp6à‚Æλ½[ÕÈ‹×2Ð,ŸOƒ.’Z ½ÐA#Õ”Ft’J›Ž4‚––r¸ +Ûí¹`ÕȽ«H6JˆÄäÆŒ…CG]'„Š$M>H~W¶5º ZFÓö¬ÚÝ\…hŸ¦&Å!Éñ@Csá¦Ò‚BÖãÉ•¤:gg‚5•Û®%Ü’û`Ýݱ9E2 +K‡8„ãª]Ý€±JPZGÞd‡DûrÈžwò_´^fSo+"C—Ç#™˜¶évu?åˆÐZñ g¥`ðËüøW>”*r§3p…eäÞ3`ýNS7nÓ;yD?šc­³ÏëPÏÚïP%µã±Ԫܗ˼®Ý~p<¶8ásúõ³Rļöþ€ªìK<öR„ˆ½¡“ņ1L†²g\³bLŒn9D®9u¶L‘d¹µ!‡x˜övY¦ ŸfŠÖ>]H)G%¨ ¨` ŽÏ¡,ç«~¸Âë)£,q„„tÏù¹ + s'uàNr@â晀‘ÀdN¾×ÏÛ1Ïœ˜¥ +ЦüàÎè 7"¨‰Ð$—¯§¼.zo«ÂP€úç=CTœYen“BÄjêÇïßßM#TŠ*-‚/|MÓQà·1 +´ä•Ž‡ â +ÒêI wòVéíÙª¨ßÝÎ5•ã8)ˆ• Ó/ƨ’ì¼@ÿjÏ2¼ÕY}k¡€Ú>µV7;jBå–Ç:´’DøŸÓ4ÛÁ^KÊäå|ëÝ~ë€Ñiµ $Xð:‚ßÝ=¾ýƒìf(YÛnrÂxÙ¿¸yøæF¾”UBÑo¡Dc¦Æ‡íÂY”ô1¹…zº-væ¥×CW~_•ðVSŸ%îS‰òš0/ë¯IBa:þ’'µª…²àA…ÑÃ:v£‹üÌ¢¤oäÜ#—ô…½1‚©½Å{hÄe2íäG¢¾.@”¡UyJ¿?ú +b½á;HÖùâ¾ìË«ãÊU_NOæ") cq|7æë¯Bè¿ÊTe:AmLä-&OŒAö¨ô‰H@µ—¿´WÚ€Ó± žV‡šïZÎBƒžd~ºve?XŸ…Ux£V>ÞS;X‰Gúò%5½ù!ЗOx™“ â,Ùü©èIèyö¼°·Òû­FŽG{%ª2;¸Š›¹Ld:måSöcU’Û<ÜFa¦fFžK7\MÑ”fÈPo^F‚:,ù?n5Ï£/úðp§ëWÉpM_f†¥ä,=ƒÒe±@le–# ²Ç +<ß"/X=ƒ¸/çÁb<9¹Àât4‡|Á›Hk“‰Œ÷–§E"R}’0Z¿õ#N;Zšs&\¯¥ïÀ B‹âÇwk’r=Mû Û9.·K(»WÀb®ó‹²Ž¼dÜã‹3צC­ÿÂÉNó$rjs“ aôÑ£ý +J b±ß„щÖù…“ƒxƒŒJÉƒÝ°í –Ëj÷ ˆâ|PìùöîÐû>ìEÑ,-ûó JBTõG­Ý p®È¾À'%áVhïJžŽ¹°±pÄÂÅT|ÅùbPÌç3•Û‹|~}hwÛré¶*,À¥fÒNfõ†N.~Y‰Æ…Â÷É_fPÒ‡·o  ¯­i¶ÝˆŽò‚7TûWO—3&6Ë#Ý^¤fR,oÎ œ#—óïúhƒå“›eWïêmyˆ¥Ê„8AâF«ôÏÖG9°aã‰a.­NŒXN¬‡)Tèu›öˆGì’)ëêpŸ +RËâV²³´¡†AˆdÀßÀÕöXÑ…¡}É­©T%Jhõ™Co’¼°ùèÔw´Ê±Ã.%™!ƒû_Þ½ó÷n§ÒzÈÀ!Õ0âìo|ZÛýÙj9åjùèömSÕའÉï/òìmX?.}µÉ½Á–Û²ƒû²‹®\ò€.¶bÁ/CÂrÊ*b\ôE—Û]`¢š¥ÙØzÞO¿7¦xý%T,!/§[°*¸FœEMÉ.MŒ•˜Û‚Í‹Õûû‡w_¿4‘È'¯÷üíj … ·§"Þ® .± ›€ÊnŠ™ R’"M?sÓh3æUÃùåõ23ж^O,‡oÅ2>ѼZ<½šÎ#¬P!ªy#ƒç 4uëÔ + UˆÄuV¼¼Ô)e ç/> –|}Ä[¾¸»¿‡CÔMT4ÃðF‹Ó üIT¸ ;?ðËPñVUè‚èô7 øpiKìOD“"VØØŒ66ð8uRÈ(L0”lÙuÇ]‰¥¶â§s$ôuJAï¡þœ .ºj2˜dàJU>¨¡“Ï•ÝPK'ºÈO1ta  øŠ#~Õ Ä9ÖsåÖåqÛ³ºÊp0ºÈe©ó['‚|ËÅežÿ~(!ˆA§Ò`xË0zDúÜMç8kO&.βºóhB×íÄe¡þ”LGOéßã¬ÎV¸@8¨aÔ8~?{%ÚÕFªµ›ðËþ”sÁ4µÈOJÆÃN//çì„èð’q$Ϙ}¯\èžôv&ÉŒ® hΨY*“Ìæêì]ºmÖŸsewvèëÆ “ ++â~Ú;Ä(>õw¥üÎÄŸoDÌvþç¿úœþÝ’QÖ¦§ñŒ“< ÂI˜)Üvš_pþtÉú‡B¬ðendstream +endobj +1108 0 obj << +/Type /Page +/Contents 1109 0 R +/Resources 1107 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1105 0 R +>> endobj +1110 0 obj << +/D [1108 0 R /XYZ 56.6929 794.5015 null] +>> endobj +202 0 obj << +/D [1108 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1111 0 obj << +/D [1108 0 R /XYZ 56.6929 748.4014 null] +>> endobj +206 0 obj << +/D [1108 0 R /XYZ 56.6929 549.4516 null] +>> endobj +1112 0 obj << +/D [1108 0 R /XYZ 56.6929 521.7105 null] +>> endobj +210 0 obj << +/D [1108 0 R /XYZ 56.6929 231.5025 null] +>> endobj +1113 0 obj << +/D [1108 0 R /XYZ 56.6929 201.1114 null] +>> endobj +1107 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1116 0 obj << +/Length 2902 +/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Ä)+qM Oð•Ä±2J&.H(àC(ºé»'‘ž„QL©W7q( 0òèsex^æ3Qüô[ë¸ožg)‡û7V`èëFt3#Œ¨nñ1 L7°K6¬Èȼï7/Ù +8?r*‰ÆO3F[ƒ|c=¡HBEb  +ÏP~ÂŽÒ†À‡(¬Î„c”Òá1t1¨„=ü² £Ìdº‚×b›Rò + d%šÏ8!ÊK–e+0À!aŸ# 3·¢‹•á‹äpÈnaŒå¨o +WÁJp©¨o=«ØüÁ'AÅd@ºOCë‹d9ãJ2¡ŽÂ\E?f1wŒ\=±Hœ#>ÊÏe¨Xx:[qÓ™]猸Š~ýtz5<Áÿ\b +r!ŸÇa–ÿO–?Úôe…"Ÿ]îŸãÌÛÂÝ_<šZ1ñ#HŒ¢ ºô8”Áÿ\dž—þpž‘d<Ž…^tÏ5°øEu%¾Z$Ié@L +QÐE”gáBæ·ˆP¢ÇrþIäDd³ÄæÉ…Ë[™HFŠ¸Ê$fú£"Xê 2¨ÈÚ´°â™Ð/ƒš¤tI„Yæ.Ý%» 2£pEÁøqS£HDŒÙÆ(ÙÃÒ%1’À‹Nf„]ÙÆ +#¡¾•±2%f| ŽÆÈ>ÛÛó0÷h‘B@‘)G÷&  €ÙÑ9Z´éx6‹é`‡ë3æ•+›#“Œžd’–Dxq¬f‹ý|IÆ„Œâ„òynp Ónð…ψÒcÚ‘~t\ƒ–çÜœ§Ð0¯å@ìÀÏ$zÃý1ÁÂJ´t4OP"#ÏŰѱ”À PI”eùO† *!PTz J$üÇNF¦ –´á×Ïâ†^LËòsÝH±AOëæ’Xļ¹è0@¥•à±¨2s|Ѷh)ZNa,g QvÒyˆnê¾Ç——óKËQ ¥‘„EÆ™õ§æ™×§²gÿjd£L¿F6ÞÄ´b#r·ŸÙIŸ~øÌ”ènf¿‡,Œž™ÇÍ`2Cãì£fÃ!Hö}ÒU <÷€K°RïŽðI¬åŸñS)f`E¡3$‡B4„ BÅÙÝ¥tŸUõ$+1cP>/ÔÍL,9"=¶abæ[4Grôsâ„‘› r{ɸ²4ÆT3¤SX¼“=dV`}‡¢ø-Ãʼnüä"B>+%­ôd2?×–tÍÚŽú€ú¾X±-z6 jDnìXÈÁ™Cã TÒ£kè}\þ£h2 |4òÂð@G¸w Ÿ“ôÄêN4¢q¸’y^xELT]’œbÅÑc:Ðéƒú"ú|ˆBTãŽg¤<²Ê ¯y}3*ùþh@3'$5—Ñ­ÀÍwÂzåãü0@d|ž¦°ç$&w€'©T[Ü{Ž®Á!¥n­g[i])ŠRB…Ú.²«“  ܤ ÏsøÕ¼¿Ý[U^˜÷ÏFÇ®š°·vÃä$Šv?4§û÷R‰nµ¶°¤³¢,ïê¡sònM綞N9öûT‘æ¦§Æ‰“fRM…Õ…à̦·¹Ñ-³ztºw~¿>mšÜnjÚ·­ÑTžÆ6fuÓu­t0ÝWmøí—âk +uïß rÚ$äH…Ãðœ¢ÏzõS\p¡+®I_ò/U¯Tðw6øWƒ!Ã(=£`Ýtÿˆz¯_¥"dR»¶j5ý63îÆv¶Ó¿´6u1l5Wï;ŠBë¨ûh 6zmæOœÖfCÕ0+~¹»ÁµâîìÖù$]6Õ{{£™­öh™¾÷6÷sÌzÚ1¹ÚûöÕÑæ@äΖïõµí¶,8ƪ1”ו·g[î +†Íï ßóV–¶7œ×°Ã¯†5cö~suŽštµÉů†ér&×—UgiÞÇ— ÌÄyCu¼ÎÞܵg5·I5cuÊ*5öŸy¼:íÿðîý¸ûæÁMÏPÈÝ $ð—ʾ„îZœ$<›É1øë2ÇtGµfs6©1£–úGq>sþT»öX;Ö'=¸ íûո͑~c%0òô´ ¦Óiª«†#ß¡¶XDïîÀi«Á¨}„p9hÝ{?ê-6ðnÛ)\^GªxØ„¢Á–9<‰ïëÓ6¹ŽoOrãÞ÷Ãꈮ8lW-=ô­ÁØÕÇæœ-ss:îŠu{_ß×óî­‡z·×ÞñCÞLÃ~×¹››tÊm×ÓhŸNË”àuÖkHú8ˆ‡éºß鬭مî<¹í»Ó•ožìq¯}z¿ s\›KÖòÜìuÏQ¢Fwø #ݾ &mî²R›ÕY0X½7¡ +µA™R§·îôœÚ¦) eqÙÏ'ñ¦×±š -]®£ËdcÅ›fwvqšÍ²ýnÞ¿lËR{š/¶œÃ=MF#n>RÄéì ï«nWv·EØ—zóß¿ä’i2Ð?è'ûò£Ðãj†aþÛ?&…:„eÿo°E2ýíS>ÿ@BêAYæ>ÿ(yú¬ˆ¿œ£s~®É é«æÅß.?ªþÛúÞendstream +endobj +1115 0 obj << +/Type /Page +/Contents 1116 0 R +/Resources 1114 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1105 0 R +>> endobj +1117 0 obj << +/D [1115 0 R /XYZ 85.0394 794.5015 null] +>> endobj +214 0 obj << +/D [1115 0 R /XYZ 85.0394 717.5894 null] +>> endobj +1118 0 obj << +/D [1115 0 R /XYZ 85.0394 690.1986 null] +>> endobj +1114 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1121 0 obj << +/Length 2380 +/Filter /FlateDecode +>> +stream +xÚ¥YKsã6¾ûWð°ªÊBð"H:'gÆ“8•õxmMöÉ¡1w(RCRÖz«ö¿o7¤(šv¶jì*£4~|hÐ"àð+‚È0“Ê4ˆSÍ".¢`½=ãÁ˜ûùLxžeÏ´sý´:û჊ƒ”¥Fš`µÉJO¬ò?BÍR¶ <¼¾ýÝ,–2âáý§ÛÛw ‡+¸¾¡ö§ë›÷D¥‹¥†«ðÝ/—·««;Õ^ÔåûßBˆðòæÝ•_ðþ枈W—‹X‡«OwW÷‹?W¿ž]­†“ŒO+¸Âc|;ûãOäpè_Ï8Sièp&ÒTÛ3)i¥ú‘òìþìƒÀѬ[:k=Á™TFΘO‹‘ù‡Y¡LG)3J*g¿¼j[»^Ú*{(íbi8Ÿmû#ž ă‘XErÌú”•EžuE]MØ—:f‰äñéªÿþøš•àÓ èøÿ˜IH–¦‘ž7(ƒPÍåë²hYžìWœŠ:£K´Jk‚ņƒm#™Š… Lœ2A âaoð¬Ž3e‘£9»³HIÐÜq|£ ŒK#ë©e@&e1!Ò·¾‚q¦Š˜F´;ëÑnà‡ë­ Þ×p¢`t¨^ðr,Ù +âæ"XÀûƒ'…ˆS:S]A`È8 ë ¶IØ=ú¯ ÉC‹ž[š*‹¶³9ÍUÏ^´4bŠ‡ÿζ»ÒÒTÖxIO …XJGáuE㻬Y,5»b½/†<Ÿ(ÑÔuGC#u¼^« +8fz´éÄÚ€S“4 ÆAð}q…¥ë˜Ëßõ§¡ª5ð ¡*¡™ÒFŽ3ŠcÎX÷À È9çSœûÝ®n:ê8÷M@óÝ}È€Ie N<3a±Ùì˽ÁMØ’ô–&²²$b½oš…HB[uć¹ý̹¬\ ¡ŒºÙ¶$Ã… yª²­%ª«½ä<'­_”UùìÌqÉQHY×_÷»–ÍÅ˵·Ì¡pº••mMÔ¾µþ®¬9ÚͶ4ÔyîmöÕ³ÛÛ¦è§Ö½Y$ᾪŠê õk?žUÓ]ÖÙŽ ;í3¤ßö¨|ÌR%§ü‡2IJ…Ö° OæMsb²‚„ì¬}v®1;±(Bí•[·ÛÐâcC‡¬;#zÞsrä9 ðõÚî|žù#`Þ4°ÝÆm=Ú™§|'§ƒþ¥éÓiž' .gŸ[¦_††¶45J£'»r§GƒÓ0 ÚçLYI3Ÿ¥ÔUñi‹1!ÈeÍCä4ê@EÚoÉ=n‰jq¬QÖ`_gçÓµ¯TAç~­µÓŠ[Eƒ‰L<Ê=ži²ùâŸ7w£WïÀ¿/èßicà›ÊE ÜÃuVô5Õ%“L¼xðÖ~Å¿x{\¡ÅKi¨óØ'ÆïJw²8uG„G‡ÏÂ×ë—`Qª`AùßèF¢Î§öxóQiÔÞ{pÏ×î X z¬¨‹zç2DH5^4¹Di̽°ðE >צ®Ëlp/¶#ÙxáIÎJuÅ…‹2Oí«²øjO„èéUCªš7äµ;».0l;—GC¤CÑXŒÃy6ŒOŸG¾AË÷Uø© +ˆ¬‚“ÎÒøœrò‰’²$¡4ýÛÇ»ëŸñÓ~eñ«€=›;ÂcÝB†ÆXðÃVšÓ‡/ìöá€cÀ".ò‡äâB¼¨‚üÂÊG)í[)òß²¨–dœÙÂMN@zòäÁ¡¢¥…„t0Ð[g»µpMäî“› +¯7^5t\ç.<7SQK„S£Ýš£ˆ^GfˆŠ×/†qˆ€[èò::-vÞ¿÷ºÇo aàÍ>Ô)ø¹) ‰I˜ö 2±/.âF'~QÖN°vt¦yxJ2ŲÇ3àƒœÃ‡þÅyCO‡7ãƤþ#'!þ_BÆ?݃UqzD:QØÙï¨ÍüäIòà@á'*¿'ÒC}¤àùáì1»«¸«Î÷³>_±Ó$ÏDŠ÷ÜI5á¿ö.ª¸vv÷ŠÌ=ô!ļ"xß½t½†rZ¸¯p㺛Í,‚HHDÏØë ƒ±Oº ‹pt8³?ð¾ì¼Eµ«# StìÙ 9µØ¦.Ëú0øâPïK¿fý„¯b*r¹f1“"÷ôÕƒ©1Ľæ_a”²C¾¼@Í™JxèØ[çm`2‹#Õ'›‡o2耵_EQÎNöÀrh…ëIvâÉ)Ä +Æßú…ìK` ¡5¯£ïíê=ÀÉHlŠåsÇ!¹õ|ÑÁ8øî/¿ ê˜)¬’f«xÝaõ¢z¥œ³’š÷ÿ‡x©úÿC|upendstream +endobj +1120 0 obj << +/Type /Page +/Contents 1121 0 R +/Resources 1119 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1105 0 R +/Annots [ 1124 0 R ] +>> endobj +1124 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 +1122 0 obj << +/D [1120 0 R /XYZ 56.6929 794.5015 null] +>> endobj +218 0 obj << +/D [1120 0 R /XYZ 56.6929 594.1106 null] +>> endobj +1123 0 obj << +/D [1120 0 R /XYZ 56.6929 562.6395 null] +>> endobj +222 0 obj << +/D [1120 0 R /XYZ 56.6929 370.2937 null] +>> endobj +1125 0 obj << +/D [1120 0 R /XYZ 56.6929 341.714 null] +>> endobj +226 0 obj << +/D [1120 0 R /XYZ 56.6929 214.6004 null] +>> endobj +1126 0 obj << +/D [1120 0 R /XYZ 56.6929 186.0207 null] +>> endobj +1119 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F62 1050 0 R /F21 702 0 R /F39 885 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1130 0 obj << +/Length 1913 +/Filter /FlateDecode +>> +stream +xÚX_Û8ï§È£h\KòßÇöfoÑÅ]±èÎ>]ïA±•‰P[ÊFöäæÛ)JNœqºE€˜¦(Š"©)³M?¶©‹4M¾©š<-2VlÚá]¶y†±_ß± “"-r!àeet[ˆ:-j^m¶×J>=½ûðOÎ6ýFÓò´ª+†Ó2X¢H«&«ý„§ƒ"áOŸ¿<ÕÐã_úù0žþã«r¶åQ+ËS‘—þûØ/¯£_­v¸Üσá*qz˜úQe'Gzk¿OGµ{âWr¢æ‰ä(Ï꺰C§\ +veÒÖNϬ—ê¼g¸rÞÊ.ÎèŒÈ¢h¡Á¾¨îý<æBh%ÒËÞ:z³á˜èáhÓ»>HÅôÑhÇ L8[Ú,²j¼œ—D>Õ/…T¿—T„ ¬ñØ€0š&îm´Ù­4DÈÞY¢Bž¼è.ÈÜ&ò0§5¤RP¦†³à÷öÆ'çSʯ†í°ÓF^b ®Æû+ìY‰Óò¸ó†_Ž;oDHàJz+ÞI©!úê`Dñ:™Œ¡£ Q’â™ÞR-ÅãT!pº Û&ƒè¦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:ç ½"åEžéjl?œ|BèE éɸXú +q¿–D"mX• ‘¹ÈjmËúÿ@CH®2#¶¦È²&RØš8"u£´÷Dí¦ñŽÌ~§¹G@ 8È°€¿¦¯Ðžt–æøúê¾QCJºoæ°Ù²(î Ç<Ž,üˆ5kõ46i]WMPº/Ÿÿ¨Î ‚oœ»p7ª2ö·¸ÅÓº*#¼Åð`' C½žu¼?\: jº·3äŠÅ.…îÙ|˜ëãц›À¥Yé›Îe<¨õÞd[°4ÏËòÇ-Jµ¨{È‘!ètE1‘RDPż´î¡bnó‚%ŸT+)wð0Ò£Tç‚KÏXx¸¿_OIŸN@a&`ËêY‡ +:åô³¡&Ä«»Û†ý5é˜âB€û}Ye¡ødÉ °]B楖x¬†Í@”üizT(þ¶Úxe訳vTn3o-òÁa^¨ª1ü8Háã=ô6³¶µ{Ó‘¡š»hW”P·Šj‰v¢æwЮ„Z[Š´»ƒhM 5ƒ© º¡s?‡+ì +ïp,'èñ+)jä‘jåQúk ©ï¯‘ÙYºÝÕ¡Eâ¦Á§âÛð´â·I-§Ñ;ÀÍÍ$b®»Ö¬Ý‰ÜQµ㩺›{JýÐà4;,ÿ‰f`¨º ‡W$‚7€Úù«1[Ë/¥nÆÏX «Eš Q S£»»·ž;šWïP{“øÄDN)ój=u”ö¬ÊùßC;»òÕ]Û Ñ_;Œ`ÝÄF +q…7ÉGb†N0bèKNôJ… $ȳÈBÏ"g¥O Øêåýµ G’^—=Ys{}ñJE½Ó6l`‘“TÈ‹«Ã}%­JüŠÆ‹ŸêIÙmS:_Óß Р*çóýÃì(š´ªŠúºWy÷ËÓü-1~!EŠß×¾6F‘íE†>5.NF¸áb¼¹]mþpùv¹ÿÐÆ}endstream +endobj +1129 0 obj << +/Type /Page +/Contents 1130 0 R +/Resources 1128 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1105 0 R +>> endobj +1131 0 obj << +/D [1129 0 R /XYZ 85.0394 794.5015 null] +>> endobj +230 0 obj << +/D [1129 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1132 0 obj << +/D [1129 0 R /XYZ 85.0394 576.7004 null] +>> endobj +234 0 obj << +/D [1129 0 R /XYZ 85.0394 576.7004 null] +>> endobj +1133 0 obj << +/D [1129 0 R /XYZ 85.0394 544.8207 null] +>> endobj +238 0 obj << +/D [1129 0 R /XYZ 85.0394 403.9445 null] +>> endobj +1134 0 obj << +/D [1129 0 R /XYZ 85.0394 368.2811 null] +>> endobj +1128 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1137 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +endobj +1136 0 obj << +/Type /Page +/Contents 1137 0 R +/Resources 1135 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1105 0 R +>> endobj +1138 0 obj << +/D [1136 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1135 0 obj << +/ProcSet [ /PDF ] +>> endobj +1141 0 obj << +/Length 3113 +/Filter /FlateDecode +>> +stream +xÚÍË’ã¶ñ>_¡K*šªŒ7ÍiýØd}p{o¶«Â‘8#ÖJ¤,R;ž|}ºÑEI´É(U.Fw£ŸÄ„ÃOLœa\y=)¼f† 3™¯ïøä ¾ýõNDm3Z)ø“ù:3Ê1ãd1™‘|ýñî«÷RL$gÖJ3ùø8¬e ǼÒ~òqñóô›e¹é«íýL>µ÷¿~üž¦iV¸Bà4KVx?üð-A{j¾i›_8—O»mÙ×mCƒ?VÕ¶jæUĨ&žy+mDhªÂÈ1BeBhæïÅ´¡ñº£öa{/Ü´-«èêu½*·ô§o±5#´î/Ðj1]¶ÏÕg`µÐÓ7øÅMûepUXü¡æ±z&| u¨2RÓ>æ¨nÞ ãȪÌ›Èj·›/Ú™i˜ íçºzîØýL ›(†Q‡Í%èÓ:$cøŒßVUDÔ-ÛÝjAýçvû)öê~IÀÄ®¼‚í$Æ™uCí~yâñAëSÄ°n£x2ŒÍÛõfUý€–K—±bO @´mÐ4ýeÝ2ã8- +Waƒš)m%ÂÌ ™æLZEBµL€ap~ƽ¯Wq/¿£ÍïòI:pH^”ïÛÕª}Žòâäv -©YÕ]O½`ùÐV sø·ëª¨ý’XP»ëÓXu¬,óݤÔ_´ó.>¿Eúï¾û8øoAè…žh!™å^¢óÿíîç_ùd±âû;Δwfò 8ÖwZzVðB¥‘ÕÝOwÿüg%:PˆŠyÁÕy +h\±›f¢š%žfÊÁ¾x燈v œ0“)¥ÌDsͤæEؾr¾:–‘‚9«üð „$™wÎå™ gc”!:à€D´‰œ 8À‚¢|D]QÜxè¡Ê)ºØdlµÌ9íâìr±ØV]w, +e5¨.·’DBxEÊLØcA€š/OHô³ÚÝ’Æ„ñ +‘šC^¢@È º[”ÔsŸÄÝÑ-*4Ý}þ}x¡ C»ONm´cÐU.¹½¨¸GË€ p¬N¥à‚ÛaÇâ3@˜„œo26ž×Ù#Z¾â Þÿ‡‰[L5½bâÊÁŠ«Kº-4ä©…V{àW›yÂ8£Ì©a¬‡dfµ[À¦K +ÞŽÈ„ñ‘N2© +{Häí¶–Y@ªùîjcöÐ…¶©bgKí8K<^ôW:žr‰zsbøàÁ¬7Ü¿ãѨÂ@üçâTÍr†4ZG6Þd8uÌí³™S>5eÞp{;>ŒWøÔH;Ö€|n¶Õcý{†Se È ñè,§*|‚ý˜Unß@qz;VÆk¬z˜¯Å‘稹¸ýjbsf¡Þk·v1—F[Ó‡Î8“rHˆwª@3·:F¾šñãlŒò”qYj‹fžÀ.¤+ô`‘)‘}CygWU'j +&1èI Û§ u~M ð§4)Ú1^¤ç§j¾Ïˆ!чTÿX½`Œ(Ä=''$Ô*N± ÕH>ÀŽB×­l2¹/G™fœ °PÛx ±éJ€5  +2Æ­®¯¶Â+Þ0¸/…Ö=gb”Œ»Á!hgAó1S:Æ/ ‰4¶¿BgK —â—PaÙó~]yÅ8™ßH@¾‹RÞ@"jÕX@ç"X™JÖNgC÷ šY¹Êðl3ÎúóÞp%º¶·âyÀw‘gÃj­óœuíà:<ÓÎeÏe³ø*ëà•cZ€EŸÛbé=D<n]k¦¡¦x½[Ogc”™mæPÞq m ¡»ÝöWSv¶ÅÈ»ÃV)Ï;cù +h4:‰[q=`¼Âµ®•úë3ö¼pÃåÀ Ô^VØiÝÌW»E…ŠiÎ|3‘]8~½ÑXQÎDzLe=HF}Ü7Pƒˆq6F™‰î*ÓÂíNòÈlATq®ðãcµ| …ˆ×EãJQß²R×À…,®2È…Ñ&ð¼h×eÝœD2åYám±‡}u,Kgc”¹h&!e0GTž;â–q<3â™ÔvúÛî^€‡SFøÛõ[:ªÔfú¼¬Ã ?×álù1ŒÄƒI/4]q@óí?Ñ8’ñ†Æ1b§ú½\ÏrGþ›t<ù‹”:cPÒ5رdŒ/¬¯ºží÷ãˆW°>ëlŠMˆó‚ºŽá{°!H€K}E]%L°Z‹¨®=nì9u`o§®c”ÔõÊj^¯ËÕuý{È®Àëâ%…¨V»-ÔM_=¡g ãŸËÕ.$ið…Ç)ûÓs‚‘ÆЗ®Ú”Û²'xØ +”]—»Íùb¿؟¡©°¡k8<Óï2§r<¬3Ék +©rŒjæµò‡•ñÀƒÐx¼sÐÅmJ7RF"OMÐѦPî<ÃSâsøŒuV×þX7ÿÀU¡ðòZå" PRïƒê>{ú?ÞîôŒòÂéÿ‰g’ó£ÓÿwP÷˜~øÇg»af¸„ìâ%ñÐåè©çá²3| K ÝýýTø[ç{ÞU0%„HË¡r»Tø~iÖ“0ÎÆ(3Yƒ|ŸC61€]öC,‚j¤¬¶iéîì‚=Œ4íVö0ÜW~9ÎaÊ9‹\`É|í>LBÍì¤2Ñ"ìy‹H€7´ˆÊK1&ñË-BC‰a±gÆö®]»äÚ÷œkG2=Ð1JÎÅÛŃ{û–Ò¹Sp(: +'öuð8Z¿›· CHU™îá|éAæshQ‰P¼××ãÞÍcoY~®°ç¦åú¡~ÚÕý }À£/­ê-uÊüo<»ÓŽþ­w]D÷På¢à¢î;N-xœZ¼L¤v³¡»ÙÖ%¾4©h<,z¾¥™äut¼× +Ÿ6ô’fŽ&û@d !{A¹I1ùO!&Ó¦¤Ø.ªU½®{z¥ƒòæ|ú¡§ou„Œ7Ù<­^h„d;o×àçÄ^x‘!²`H¤òf®“8ÄQL;„KÅ0 ›ÕÐh³[WÛzNÃõØ­ñÂ2Ð@¥}x ‚€tŽ4ËîExoåâ[%hCŠ-ñõ¶ÿ—O,ÓP¶(E×Ç/ƒÒ›"Ÿ*zMä¦kŸ³yûè ”BaÖøH j+>~ …ëŽÚ¦¥¶ëËfAŸ4²!rNC€ &fFar¼°^äˆ C&d)ät¾ÛEñ÷°ëØ ôA¹},õãÅ:‚]Õͧ ëd·bؽøâixGäA4» ¯T ¤†£GévkªµTfÖ·³ 9=?>TýsU5Y–ÙaI’Lè µaó@yÞ‡òˇ ŽÏ–ÞDÆö³U;/WÅ(-8õyrxk\òy•ãàï²ge ò€`T/U2uUØ$V*û¾œ/C"Žíà~‡2žØZ¨U:¬i*ž žÎ×ãã£2RòñwHÂþE +²>Ÿ2˜ÄáÎG9ü)¿²ÁrÔ™½ã7àã~€ª;'è¼UðB4²nÃÑ2–'ÁN;ú3Þ*ü?ÚªŠª•YZêð€rõ\¾ÄE^í…ºbYS¦iM5> endobj +1147 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 +1142 0 obj << +/D [1140 0 R /XYZ 85.0394 794.5015 null] +>> endobj +242 0 obj << +/D [1140 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1143 0 obj << +/D [1140 0 R /XYZ 85.0394 576.7004 null] +>> endobj +246 0 obj << +/D [1140 0 R /XYZ 85.0394 479.565 null] +>> endobj +1144 0 obj << +/D [1140 0 R /XYZ 85.0394 441.8891 null] +>> endobj +1145 0 obj << +/D [1140 0 R /XYZ 85.0394 424.9629 null] +>> endobj +1146 0 obj << +/D [1140 0 R /XYZ 85.0394 413.0077 null] +>> endobj +1139 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1152 0 obj << +/Length 4061 +/Filter /FlateDecode +>> +stream +xÚÍ[[sãƱ~ׯ`žB¹ÌÙ¹_’ÊÃÆÑúlŽ½Nl¥òà¸| +’PK2®V©üøtÏ9$利:¥ÚÅp0hÌôôåëž›Pøc¥‰vÜMŒ“DQ¦&óåÜý¯/X3KƒfÃQ¼¾xóN˜‰#Ns=¹¾в„ZË&×·?N5aä(ÐéWß}x÷þë¿}ÿöÒÈéõûï>\θ¢Ów +­«o®¾½úpýü¢ÂM¿úŸ·¹¾ú>ÜÓ‘ÈßøSèqár€ê÷W﮾¿úðÕÕåO×¾¸ºÎ‹.˜Q+ùåâÇŸèäÖýç J„³jò?(aÎñÉòB*A”"õ,.~¸øk&8¸ë-1PJF4Wb2³šp£Õá׆WPxml*GŒQvç­3m‰f÷„ZÂùvK$l‰‘ÄY31@D .üŽ4»<±†(áÜvØ ˜Â°µe–ÌÁÙâþì%ŠïNï±]÷8Á7ï c;–qh¯ÀQoW(%vúþ/x5ƒ§Fo†au|hµYÞÔëq¡ˆÕJÅa jÜééõC] ÈAl¬B}‰´'3&1œCƒ§÷TŸš‡23ýT-6uÚ7õ¢}¦2Êeè쟛yµX<‡ŸþMuׯ›y˜‹ÓîÍ%›vuhßÄñajóºëà58#:žÊú\­šÕýåLP=­:¼ªð¢¶í£ÒÀf­Âí®]ÖaÀ¼Š_B›ÓiµJ÷õºé>†ÿ Šþß¿… ·çÕº‚y¯ãOxl4£`vnðÊL7.[~N +ȇŸ‹j^?´‹[OH൫õ¼]W«ÛvÚÍýÃ,î;rñ¶Ä”F²«eÒP0â¾ÕØ×Ù :!ÀÒNfN-™ø$Ӈ̊fœ( öý˜]ÑΫ´xXX£ÔÄR±ãà’æí¿U^@Kš_J(þ•14…MŽ8ºL•¤@[s°µ,í0Wê8íD…·ÀG@ÿóD '‚Ð7¼Ä"ÉA!Í2„yÎ$ì7c%:À x 9~oi_Üð¥‰=ô8{H×€=ùŸ,½A¸al†VÁ X|f¼ß÷j09˜Ù»g'ðw…qHö÷s¸Ñ¬>µ‹OãqL÷'žèæí£G8xUÁŸ.t$ñÛ±þ!yP lÜÄŽ­‚ð ööUZˆgR_lìLzžšÅ"ÑïçqX5ÿ8+!™ºïžÜ#µ ¿ªÕshøéC?þ:h°EÁÈ_A2yChCYh!Ž£ * g‘-ëçÝ5;ĘQÛq¯5½‰àlH±7À¸¡1ͯ¹-B àƒËÆÛf Dž,ÀΪYí9P*Ðs¾•fŠ'–Ê Lk5^ëªZÖe£Q]2BA ¢6tõªZkDThx:Ð’ÞÅcO.`þˆ¶ýoÜ|ÆBn\ˆ] û&º¢ «uˆ¼"¡_ÃFÀ¾ƒX¢iWQ—êùfÝôøaJëë`W§Ä9uJKbôq•R.•ö”JåqgS©!ÅÃ*5šß¢éú—( PûÊ’jÚ®êر×e„ª …¸ÓT$/W`Œœ¿rçãL¦x‚5a¸Ô1oÊæ&ŠX…³•!„º°]FØŽÝËfÞ.ÚUú# %Œðà#mªW·ÑëÒl¨’ERGTh+œçÒ ”Äy9ÉôÄA â¿9s<·¦”†7HyÃ…4FÕ?ìYiˆ2ð8|µ•ŽgCŠûóc”i!Íð`ÌÊì@´þ²iƒ!‚6æ#}Q›´íØÐ2¶|N®1§-Ÿ}Ák¸ oðí(ÔÎL»M¢Qu¿›ÿнYúìã›å3éë®'[üµ»ÍPëÍ0®)Ëá`‡Ïeé@—gÌöI +´1Œ?&‡`2`¸Õ£4}IóÀ³Éáâ9Íð\Ø•C°N-(’KØSLèaðK³C-d€ÏJŸoý‘Þ‰åsg‰’@¤¸Aû?L"eb +ùÕ†‹Ƴñ=D•3Æ™L¢ù. wC³é"J S;¡ô0]*© ‰:¸†D4‹/C nG›Å 5ù'¼·‰AáɹúÌäSz%úÿʧ¶°£Æn™;¸£ DpË'ÒJ¢µx}†6Sœ IîïªD ÃÌöÅÇ65äèí/B<@\\éý“Š=)¬B©u2œjùëå8Qœ I$Ó«ÞÔ¤a^‘Û§ÒšA2dÎÓåôÛ˜%Rš³´VÁ@Ã8p÷lkÍO¬U€RŒóñZñxé䃓J$')ß®11šTG¤˜”•ƒpjÇð,'˜ +ŒhÄ:ÂHÌ Xa€‘šàùr‰âlH²”“09Í·o>*4RÑdÀ‡g®…T?Å}Lxà…þålkÎO¬YhX³Ñn¼æ£Â38¾QÞGÄO +KeøQ½‘†Ê©>ßÒ3ÅK—€FÀ–È—l7¦yÁc›£·Ü ·—´¢ Ä–RŠé"$š|Ø%Cj·x²ÇÀ˜Ë ÚzáÀMg^Ê3ÅÙdI8ð…# {±eÁ3ˆ.ýÉ.|ò3rÍF¡µÛõÌhìNË1ÏC1‚¦46”N +€®¥ ê[åY›Û„8þ +/ÀÖ¨”;üai†iÌÙûY†·©\{BXî\Jå; è 0{G… þmaþôaªsAÄ<™„J­Ø.R7·§c”âèCüMÀƇÙÖW›ÝDq6$Y0»Bƒû˜‡(âd´4ŒCÎuZù+Eõ¯¡™9/qcGÃ%ŠèÃD$Üü³>.¥ç —…K£VI¸äCÚÉHŸ&qžBNõ¶`0#Úåài³JÙ ýw‚Ñ6ÎRÎIû¼ + %GäQê»j³(‰%X*+såÙF+#Ç–ámÑ kT>ÕÞ®Ð/î¸ÜV\N„uàìøC¢8’,ø.A±ÀaåaGöœ["Üü²©;*ai;+Ý€¡dW¿MØ™Ïö™à„+³sÖ»¬>7ËýÀ~ªšEÈ/úŸËv³Âš1£\ùŒLÂìì¯÷.%¶cù¥\> ¶Ö«ÁJ¢8’,€)›‚áËÃŽ±lŠ“YAR­dŽžqÄÁ¬~/’nT±õTuãDê]ЖyRžxÖ>Ч®^ª×;w}µîcžu7[ÜGžÏb×Gb]D–°y³Öí#žÅ…BEüªøÜ ¢÷½ñ®ÏÛi7¯!qˆ#Á·ëßlÈö'Y²ÿ-ÂE­ˆÔ|GVÛu)3!7™Nˆ +Ô±41æ(¬œ~líÍs_w%L „ËüÌ·ˆfÐõ‚‰-_<±e}_ʼnçwƒˆzLjs•ë_¿>à ï_<Ãû&—ÂÂ4ÛÙ¦íô…ÈÁ±È‡R‡¦¸"Xô¹o~‘‹P…–Æ|‘ÿ+)@§ Íx€³ï7¬%öåªéìš! +Ô1‡ž=ÌÏ\rEm¨H…'´ŒÇDеYuÍý*K +“@ÄŠçB”‡bW°ÖÌJ©”ÔCq]šù#!¦öŽ„`Üôo]¬ Û˳ÄKú%¾]˨ޖ9…Õ“]|Ìßlšnê.ÛµtlÔFUÝÕ‹T +S÷£sÈÀÈX÷Œ–2w»(æ0 ½WbÇÿfù †¹ŽÊG<Ê5]CNÎ¥tÖŸÇí¬HñðYÿh~Áp § ´…Ì8×ü2ÅôIh°`£ ®ÚX¦€œ”H>æ*„“ûPPt3ÉÀŽØE—U.a–ðš+,š'D9³nlà𘺾ñBB0™Ôì Ò¡{Gè}r‰/+Ì6YçÜOyÑ@D(“S*ŒTzé“ñPµÿÿVJp …ô¡”]2@ÒŸfyÈÞ€ÜKf€û éÙ8òÕ +žèͶKê-‰?˜^À¡E×°NžÄô;,)ÒJ”¯0¬•;ªå ëÉ3½&„–˺/ÐñÐè›»ç“_A½Îì±ê%”ÔTÚêÏk]ß­ëËAt•Û…e›(Cµ|LÌœÜnè?cX/J•–±È[Mì©ÂëJka5ó\Sî€[²Ä%ØùØê ŸÆkú2|¼uÀ(ƒovY m‰S»f?PÛûŠŒºüQ[·¨>Õ¡Ëãiß×onBË—Z1ycr®ÒíÇ™'¿ö„g 5;_{þgOå,- k€±3Á1kΆ_‰î}-ÊÅüuò<ÎÛ.β¶>¸eR°øý$~pË@œ)¥Ó···ëXîN§ßÆbsh~Ó`.g¿¸ŸâˉTmIeb?U…—þì‹Û•˜™ùC¸ìßþ¹^ÔKˆvÂýß{ŸV9’üOQø}@ Ÿb +jLŒ˜æxqºñ¿IýÅã=þ\%öúoõ꾈CþuèÃcUJ‡w7žæU¿ú£äí'ÛÒagÐ;ð-JZœòEð½™3[BóÂÔÿ Æ+h:endstream +endobj +1151 0 obj << +/Type /Page +/Contents 1152 0 R +/Resources 1150 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1148 0 R +>> endobj +1153 0 obj << +/D [1151 0 R /XYZ 56.6929 794.5015 null] +>> endobj +250 0 obj << +/D [1151 0 R /XYZ 56.6929 165.9801 null] +>> endobj +1149 0 obj << +/D [1151 0 R /XYZ 56.6929 136.242 null] +>> endobj +254 0 obj << +/D [1151 0 R /XYZ 56.6929 136.242 null] +>> endobj +1154 0 obj << +/D [1151 0 R /XYZ 56.6929 106.2766 null] +>> endobj +1150 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1157 0 obj << +/Length 3064 +/Filter /FlateDecode +>> +stream +xÚ­]sÛ6òÝ¿B{ˆÜX4A€y}J]§u§ur‰3w3M'¥%Øâ˜"U’²ãéÝ¿]ì"%Z¾´7z¸Xì.‹ý$&!üÄ$ƒPfj¢3Ä¡ˆ'óÕQ8¹…±ïãÌÒ¬õíÕÑék©'Y%Q2¹ºéÑJƒ0MÅäjñËôì‡Wo¯ÎßÏ¢8œ&Áñ,NÂé·—ß$£æìÍåë‹ï?¼{u¬ÕôêâÍ%ß¿>w~yvŸ@æ ¦ðÄ„×?Sïü§óŸÏ/¯ÞÿzõãÑù•_LÁ"”¸’ß~ù5œ,`Ý?…ÌÒxòa ²,š¬ŽT,ƒXIé åÑû£x‚½Q;uL±Lƒ8ôˆ•èiP„QéHLtœ‰Œ¤Uáy<ž%aˆOÅ‚úÿ¦&Ÿ—Ÿª|eÀ?xl±hLÛ~ZåÝ|ù©,ÚŽàÿ¡æc ÔÎéë¨/ÃLè “(«u‡:²2 æEÏDS¿3Ã0ªŠ®¨+Rw^-¨ó¡Ío “•=²á†AC±²ô^lÇ"‚|0OË©’º(©…FÓœ¾nŠUÞå#}nZ³ ^WS»0iVEexò|îÉÏ몳´ê’7uC{ Yo˜_kš{ÃõÚ49®°›“:›^-a#`e¸!‚,ŽI7=!iÙÖÔÛ‹)‹M‹ŠÚniFtž¦`Y ˜¥‡ë7Õ T»¯F%ƒ0‹5c¢Ö÷©‰,ˆµŒÓÖMg÷~Ÿ˜TA$SG¬íòάLÕÑzc\/ mJ‚Ó×ò ¨Õ¶+ºMçϫ̇»ñî¢îfN Uêt(üšÉ€æ9›Ôµq¦õHú†ÚnÉ#7uYÖEuû÷§Ny¢b8P:9ìÖúXöP +ÕÓRÝTöh¡¼C¡w™Âª`’Ò‡¹z¬}¶ƒÍ!ôU2dëtsñ–u3Ptluxñö^±Æ‡~Ÿ¸ã>ª¦HZÆé3jêaP“Ãz^M‡¸öÔ´Ëv\M}¶»jZ“’Ði}Þê©`¬ßN_P§ª;{ઠ+ø©LfϨª‡u@UëyUâÚSÕ.ÛqUõÙæ´tc¬Ê¾;aÓb‹Z¯7ì߯·‡pÄõ€ïQJ8ßsGsWŽ |X*wÝÎS3<1°9¨ñ>ÖÓ÷XÏjü ×­Æ÷ØŽj|ÀÖ»/ŠÛ}ÏæìvïX»èÝ­§ÜÙ™‡¢[Ú›(RAªUìbǼÛ›8ˆD”þÏ{£!qu`ozXöÆa=¿7‡¸ööf—íøÞôÙòi¨ DàÅ—ì…©æeݺ9γ\79¤ ÷@ûY˜$ƒH :}çÛÈ*%‡>èØÐ'#ã6'AÈû ½œšÒä ~ôa>ÏË|•sF&1ä6w4„¾î·¯^ Wó-ÎÖ`ˆlQnÓ/)Ý¢ ‡Úµ`=ˆ±±4´…Tue4H‹øxÁ@YÏórY·OT3—™Ø"T¦kñƒÀ>ÂöÜÞÔ!5Ñ ÙÏõ Õ Ùœ[;Îrm¬™¯»VÍع汛zãd*üL3–ê-L;oŠõ6ïÝËIðXÙŽ?;'d7ž"åVq‚æåÓè„ÉÅŽ\âür2…ÝÝ´ \å ³ƒç|‰#‘ÀPÑR¯}¬º|ÞsšÃÙÕ+˜ÖŠz“sB]m Y6,¤Ó¶¨æ£ªiÍ|Ó'ç ·Mýµf£îåíÊçí÷yY,rJ"Õ mG›¯7}Жߒ}ìÈ©AS£—Þƒm=Ôö$ iw–15·in*¦—`ĠǘŽÚ±ßZ,.8{ÀÓðŒ_ ƒ¶Þ uQ”lï*º%•%›[^hߘõ|ƒ{eM{ÇŽÈüsiP½)išÛÖvï€6ÂÁ°°êI£ÝÌF +Ƙ׫5ÅA¬®SÎòLj: ¤äDÐbø(ÙyD±hkžßåw†g®Kp”Ì¿Û„|M’ÖŸ¡ì Ö€2Ó7èÛ„Í×ìwW¬ ÞDÑô‡úÁÜ{Ó•2£³$£°'HKÓh¿o +ïUÖ2ï\A䱇I‘#äÚMkr`k÷?7ì:uó±ccuÆ篗†9›±®éd§ÆyHÐïɇ•î» +ûµéãi$m©Ú ™†M£s~†ìª±¾ÃF¸ýFȬMµh îЖƊj£ÏJPÑäÚX ˆmŽ çØ+ã1š„‘K‚Àˆv·¥4ÕP ·'ÃÚÈÅêÜéŒÊå]ûµ hÏ—ŠK™9lª™,8WçbNµcNÿz`Ë xá¼—†(<Ûf +è¶'’X!;òž¬rëŠ='æ/LU?6¦c$Š®T@ñ€áCe[¥OgÌUMß–þ õ½P=<ËC½ 3)CŽ€íXf«D&PÐpf‹kžA1WÜŒ•q%Šv·'#ô SÓq< Ö`tk‹Ñ;-ˆ#ÉŸ$H:ëNƒT©h¨ÛQ~€=y€_‰~šøý¾1ͨ6â@×/§5~?¥Ã Jãì9zz„Þ<Ÿ/ÇnSÄq"þŒˆ–丠Y +5p–}UðíU{¶½O/QHÓäËèÑÖ+( ´ñ0âmÖ6%¹µA¬ÄaN¡H£'¢6§ú7 ö–{v…7sZyÊ3ÉžbäÈ%A:‹¾†è}·¬Ë1iUô}^ŒÅ6 ¤Î ‰Rù Â•HËþï‹UQæ ~!„“b +cú+S¨µ" *P;gÉ¥íP¼Pc:g»ýÜ F(ºáð„¥ŒE%{!§qqœdÅ #¶¶PðŠ-Ħˆ!Ö”+¶~C½c’ª I¼»CQšÑ«x‘RFîÌŽó’‘ö²è½¼Àþ¨$ž~k؆­h7NB„a˜í–2Ÿ2–dæO›‚•/óû¢ö3'$8´ÝY©Ü¢¥ôPL3§¦Ý\·†q­¹á˜2e‚»ÔŠÊQ5Ôáô AET.¨)û¨Ý_÷s`í.40§¤¤)_¸çæŠiXÓ°–,}Ái.ž>ÝÃ÷Âõ¹<²u%çxÖ8_×õs¾Z—Ærɸ–ÙqRË KCçÀEò4Rß`ù£¦_A „üfÄVfžÂ@´tù¹ôµMQeÜÄ +¨4TGá7Øë@`:[ªyy[C}¿\Ñ'{Pyç„8ÖÿÁ¬²®ï6kÒKÛž\Ö±Šhß¡‰ZÉ»–+Êlú¡Ý°áóid™¿áüŠ°·ª„¸n $/:H3©z‡õ³õÎB³ÑG`,\‡^ƒD4doÄ¡ÅÓcë8è÷—šB|¬çw6¹î¡³b5Yç÷>¦‚4ÕÙŽ»»Ü]!ÔÛr„¸}MxâŠGÜ»e¼â<}û:+Ô ;÷ÚëÞzÏêÕ¶ÄyWIŸŸÞå§Cå^úáÀd|äÉÁGKäèÇU*÷³ŒÝö/{^˜œ1ÀäzÕ†vþ {R;Ó®éjÁ¾1?îP{÷ ‘¿N´zs| +£ÛMãîX“ÔšH‰2Ó«ã ð Jši¥†– ç¶ÉaMMK@ëopBÉØw”Ñ'ô¼Ú-íu Ó% ÛÒÚ8Ša`ÁâIàì„Û—/OÈ/ÕÍØ!k—¦,Oצñw–¸œý“…ö n¼ý3@6¾M(ñ´MœZ ø1s&­$YÛ×vÀi¿7peÃþWÁµ95´-ØóædGvEíNAˆ0#> endobj +1158 0 obj << +/D [1156 0 R /XYZ 85.0394 794.5015 null] +>> endobj +258 0 obj << +/D [1156 0 R /XYZ 85.0394 731.767 null] +>> endobj +1159 0 obj << +/D [1156 0 R /XYZ 85.0394 703.7216 null] +>> endobj +262 0 obj << +/D [1156 0 R /XYZ 85.0394 229.6467 null] +>> endobj +1160 0 obj << +/D [1156 0 R /XYZ 85.0394 201.8883 null] +>> endobj +266 0 obj << +/D [1156 0 R /XYZ 85.0394 144.1965 null] +>> endobj +1161 0 obj << +/D [1156 0 R /XYZ 85.0394 118.9605 null] +>> endobj +1155 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R /F14 729 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1165 0 obj << +/Length 2262 +/Filter /FlateDecode +>> +stream +xÚ½koÜ6ò»…€~¸ÝÔ+“"õ`ûÉqlŸ‹KÚs¶8Ú'k¯P­´•´qÝ_3R¢lÙIϹ€ÅÇp8ï— þx'a¢"¤J†1ãqPìŽXp {—GܬÐʇz½>:¹i B•DI°þàáÊB–e'ÀX…‰ˆ„ F ÆØâþ™±¨.û²©‰Õ¼ÞÐàÇ.¿ÕÈ/`V¬"*É¥ÁwÖìvºî;:´Ëï-šý^ç­Cy·Õí’g M+ý6ïit·-{ÝíóB?ƒ t´ÑgÔZÑÔHÿí¡ÍGp¥Ò!’ŽÄò4T"ʈØU×ßWp•v” !]Ÿ·=mÜ•ý–û­…íïZ)¶y›½n;Ú8yEë?³˜uUÞma:Xãe„Š`šþ¯NhÅ`€Shy "D,h®q¶x­‹üÐé3ª8&¿JAp‚¥‹Ü 'Àã¾Ò½®ìæFWå$¾¡©¥‚%x¾sg‘Œ˜_òÅ€¾ÈkÜXp Èbë›áR,MšÚÝÓgß´¤+³ûÁíMxŠ OUY[«h¬!à øƒ±ÊÞª¾ÜWOt4ŸN5M4 ŽÕMO;7ЀB$N,.Ìõ°ªÏQœÇ8‹É8pùCSUÍ]YßÒ´´x¤óªÜ8ü¤A0 ZÊÁ=Fúædd]tGÞ¤GËo;ëY¯N¾!ï•|ê½¾Cœ˜;âP¥i;a*¹õ+³ánö6Ö[ä/Øá¾æzXÂ!ê¿9},Cáœå>FØõeUÑpÿãpÛçÀÔDX_‚;443¯‹¦muaÉÉû^ïöľh5Æ žb]0fq’Íc©ôÖ‰ú•€hŸ )§¬=&´nè[5õ-[K´câ~†šˆ È#韠æA*XEQr™A&ŠT˜e©"_ûúëÁÛ¤ò½ fÖHph-FdÁ8À8kyqç''ôõã¬AçB$M){™KÁ§êƒCÛ<¸G;84«ÉÎ~{ß­æ<¯,ò +ãab¢ Fd‘L\„EEplB#®Y"64Í ãäM×Ñ|Œ]8˧wtßÂ8‘Wam›´°MmUs;žã.LLˆœq·™€yLcÛqÕ…WN(jùÑƨ$F-MҚ͸.tÛØùlL¢PxÑV_iV<28´sÍßíÃÜŒ~ݵƒã»ƒwÌÇ4Óuíˆj·[{¶Ÿâ°ê øÌ…Ïĸ}«?–Í¡{ì¼3E™çï·ºª|D·qšØëÖîY*­Ü7 AÉèƒnGÏú”–á;¡ eA…J¿ša&¨i )¯» iææò¶¶T Õªïï3 ,OÁ‚µ«uMðwFgtþ`$ï¦%)Ä:WŠ’|f«?å™Ì_ëÜ¿õ/ó¯^às}˜ˆY˜BAùYB¥b9߈¡Y¦ŠÉ§qÑ9¸ìИ¢Þ( Kê©_C&D¡Hy‘†Îtþå9Hœ€Å‰S°òSM´¸6ÿ¡_MøâjG‹Ë‡¢‚KX +È#%€h‘!-Áo Å¥ÈæG¡˜…“«Þ4Àbàqé¯|̆KhUG;‡n Ò@KÆk"mìQì¯`´°Ès{ŸKœæ€iÐìvô½_F†¶¹Ã‹šC…>–&*`ã–Óô%m®†õ¥¸„ÅCÊÉ/qÇãO—õ<ÚbÚí5`º&X°×Œ]°aÛvWÔ„öz¶˜™u"™¨0ÊTX3ý–>«L|Ïx™_N)–\ù\†B&‘ÿúEä‚8qÏGöåãlîéà¢t…Ñe›ïvyûDªÍÂ$UÂy_nfß$`¤èóøi"¸Ø•I¢b²|š\rMìkáp9e%dºxÿN;8›‚ñ¨Åè Ê?ù¤!˜œ»\OR}<¾'àĦøضõ8Ò•ö íËb1-:"p/90FJ›ƒ@{.ª¦£¾ön fІW¦oMË‚ËžtfèǼŸ?xº©šâ×ibï7«Ññðöä*ÞÜÊ«ÎU +ºÝ•unÞK¦=·½ÊôLÚ_»rÂ!ˆÙTáoï{|"Ñ›oúg–† R—жIÆ?Ç—„_â «‰/ýo§¼Ì Øî¹óQ|p'8³e Tª ã©lþ!ò‰Èx·€ö9å”2ò¢šñNÎ2èHS›7ô¼i"i¢L¼„Qç;Ó’ÁÊÕ´”o6¤ƒÎ‚îò¾Ø…ávN‹aJ*[‹¬(:5ï=õvÕœ‘oªM¿ÕíÐOu#p +IZòÀ—ÇË$ŒºŒy’Ž}>Jwâ)¥1(SR™|Biʉ„îÚ6U÷š+*ëÝðÖ;Ș¶P&誛> ÞèA¾Vè7÷cqO×údrÅ°qÅT[oŠâ iQ‰pÄú²*ûû%ç|ñŒ=ñ¼LàÿGª8„*ŸW¡RL ´„˜}ØèOêÏÂu“hé½ÌÏJÌ#æK ì‹Gªjo¦øóCà˜Q#÷«¾ÿ¤´º½.J”ŽXÂÌ!ôæ5œÝPB0Š?¸C2‰mEá›À¡ .†‚ƽ‡ÙÍf5W¶å^tè†,µ~uù´®<9¼L°|+ ,ˆªÐ@$s?y±ÀQüâØÆúQ‚{fYä÷bžÃ§Y(3@"À&•zB>j;Ý/qÊ#ý¿ÚÕ.endstream +endobj +1164 0 obj << +/Type /Page +/Contents 1165 0 R +/Resources 1163 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1148 0 R +>> endobj +1162 0 obj << +/Type /XObject +/Subtype /Form +/FormType 1 +/PTEX.FileName (/usr/local/share/db2latex/xsl/figures/warning.pdf) +/PTEX.PageNumber 1 +/Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000] +/BBox [0.00000000 0.00000000 31.00000000 31.00000000] +/Resources << +/ProcSet [ /PDF ] +>> +/Length 557 +/Filter [/FlateDecode] +>> +stream +xÚm”In1 EOPw¨u€$ÅIg0²Êľÿ6¤¤êV5 oʯÅésÀóή¯ƒÖ×O²Î Ž¢‘ÿ¨#h8Çùø:„5?ùÆ [ÄIÚL’~”F Ø PÈùYÌÀ¹dˆÐzZ8å±Ýƒ²ÙËò‘–Œ€f¾Å(ÌÀE#@x˜oL Û¹[ƒ±ñðù +ä +6\>RgÈbÏWÖ¹j[†› +WŒÏ¢®{6;»²þFÃÇñ÷ø]š¨)Õ/Ô¬Mu;pk;Ì©Ëdh<åE–ñ¬AÏw³ð¬±±Nê¦ó¡Ä½t•‹ùD„™Â²]°Ä(‡;„ ·åŽ°Š­r²ÂÙÄLûˆ T¥Í¡誋ŠŽt’¹w_ =Î]ˆ‹=¦uSä÷—ä"ï±yl±‡µÃ-ËkHsŠöreOÚ³êvg›<7ºt,‡Ýe—;ãÒèЭ/I…B÷&ê(ýê³ö󻉨YÙ¹Ç,çkRÔšÚ'^ m" ^˜h±ÎW9AVªy­Â©/fýÆ"•œãûFy-Sng \Çdª¼˜©Æ¥†Í}B©•µŒÎ$âw1.¶&Øíþ²C¶O–ÃVç X×9g¹E{îÇ< •ãóP)!ÍZÜÅŸLÞª~ÑÔ'¯UâXLµüc“ÅXsЖõÚ¯½˜Ó’~òBL–§èªÆ¹O¦ºNZ_[Èü.øšŠû*]3QôçÇñ!Ö-žendstream +endobj +1166 0 obj << +/D [1164 0 R /XYZ 56.6929 794.5015 null] +>> endobj +270 0 obj << +/D [1164 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1167 0 obj << +/D [1164 0 R /XYZ 56.6929 749.9737 null] +>> endobj +274 0 obj << +/D [1164 0 R /XYZ 56.6929 246.2071 null] +>> endobj +1168 0 obj << +/D [1164 0 R /XYZ 56.6929 214.3631 null] +>> endobj +1169 0 obj << +/D [1164 0 R /XYZ 56.6929 155.5938 null] +>> endobj +1170 0 obj << +/D [1164 0 R /XYZ 56.6929 143.6386 null] +>> endobj +1163 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F62 1050 0 R >> +/XObject << /Im3 1162 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1173 0 obj << +/Length 2334 +/Filter /FlateDecode +>> +stream +xÚÍZÝsÛ6÷_¡·“;%Š/â£}r'çNâö÷)Ídh‰–x¡HŸHEuïú¿ß P”MYv­Îdü@`,»‹ÝýAf# +ldRB…•#m%I)KG“ÅÍ`ìÍ s’8)éÏúñêè»×B,±Š«ÑÕM—!Ô6ºš~Ÿþóä—«³Ëㄧt¬Èq’*:þñüâR,~N¾x}þæ×Ë“c-ÇWç?_ ùòìõÙåÙÅéÙqÂLÊ`=v,x}þö [o.OÞ½;¹<þxõÓÑÙUw–þyî ÿ9ú𑎦p쟎(Ö¤£5t(aÖòÑâH¦‚¤RˆH)Þý«cØõK‡ô'¹ œ[1JRJ$c»wÅ(ìš°Ò:9·7MK‰H…3‰”„Zº1 g=“0Έæ6éÔ%¸ð6)ëÙ¬¨fN70_ôçSC˜Ôn7±¹Í'Åo”ò¼­ +=^ϳ[í¾f³IC¤´ûµRÀÈR ×îøpEŠI“LæYUåå“® xz ÜPå(0Õb±ªŠI0”'Ev¾ç"³ûÎòÙd’7~P»Áð)¡œ‹=ñ?éæmçßî\˜µ§¯C™5Êðt–qÅn³ +E¤•û¬*)Ô²T…êÃߢýe^ºòe›!¡=¼xîÎtÏu1ÃÏ-VNIw{v5ÅcÊßœêeŠú{uÏG³/“)jå©Ä"d¹‚œ0M>çwÏKgNkÍدÇþ«‹÷ïÏN±í>¢Ðž¨‡Õ(;¨F07Çöh”)Â4ÅÜò¥È×ÏÖdpM¿Öòñ#ŠëIô5»"¥üloR¦’pJT_§üEŹµ(­'Í¡”¶¦û®[cðÚBºmU„YF¤VG¸&To#äHYPE · uª}÷ì"<5ˆQš¦`£½Â¯æù@Âc–€:¼°ú +MDÀàJ A^"í`ÑîÚ ‚°¡LÇtÐÕB±¸½‹á¾Œ­Éd‹¨j’oÂÿPâ d]j¾q.Í ÂàÒ€ )˽˜°ã„Qê@[‰üÞGÂSÉ2[,²×dÿ¼ÔÕÄJ†!Ø3PÈ)q•öþë‹Â˜Ã·ê…l:|Ö|ZdídþÉ£üîMÆkõçC$xŽJMw ¾ç@¯ðæ›,‹-4~uï »wÒÝ®ÄLt%·û@å+aï›Þ=Šjšb擽ôË}š»Åu]ì¡V]Ë•v~Z¾ J¬ ýz5ö:Å1§XàŠšñyØj†5´ŠØØð¾A¤°ØävY€ÜaZJ@Ü3Ül›µ¾ jÝ’É»6Ê”R/Só=Åèø$T¥þ©oTðÖMÜ@þ“Ó·M×=Ô8$8^ñ‹º…#êñ/QB(¯ GÙÆ aܘæŒjpÔŪ <®%Æì)’×E;ª¡µ„ÖúŽ ÀieŒ×¹CIø æ6*ÂÆ“(=J œâ§H"?ïÏ~pÐÙŽ«:Ü Ϊ™yÄÖ ‚·ãÚ›ÀKÌEÝ‹œë”e½Î§ƒú¾š‡I7µ›å"§ï:# °º^e›Õ÷÷c’h­ùHÀ-O|xpHª´~n:Z¡-"¡ÀÇ’ÅŠn¸ˆ`©#ÁBŒænÀk¬õ¤1 ½sÜ­ f^7ƒ°ÚÁ.ˆÿ}a^ZC¢Œÿ-:£nµµûtF!U•"Z.¼QZU?Mg=a¥³>EDq èÎXµGg*2*X|ìŸd¥;þ3§Ex§×||þˉ$L¢HR´‰¹q¡Ï 0 ÝUÞ®ëågìU›/o²‰ó ªíG%,Úyš;€m‹Ý¦ëëä¥Ï ÑtPpNŸ]âŠÝ¦,«”Ùçî\9ÈË6–«ò¶yºå˜•>°@CxŸG’+ƒpGЦ~d‰_4©ëÌåÈ7q|=/\.u¼e -3ô"8w? p&°xa|cv‚‹ïk_ŠÀ dÒà´iĪn±q‹•Âð–bVdøYû*- †uÓ¶YU¾Û£¸ L}¦ÿ)e^“Y;o°ï}ØÑ°|Z[>ï«.6>¯p¬Yùò‡£”@˜dMþíà3œ& +ŠÉ–ì6uÒÍÝ®Á:ð°è¼îÞDÙ¡dß.ØrÿKÐþí« ,Ù>•½Ü¡SnD_ÖERHp*F\ÚÞmxÙ Û\ÚçàÜÃÌÅÜ”§ ‘ jµ'â\f”å[ï=ô¯†àì%ï0È¿ûã›ÿs‘Ôy©–›_<—  ‹uà–×}ÀpÅZlù_évûÉ»—ïüY0A` ‰–÷ú& !ÓÞ€«úquØå¶^¶ïMçc¡®"'ŒS:7qàO,›£mÅÿ Ù¸ÂZ×Tvõ,´&šµG+„­etpþª*~'Íh` ¶ªÕâ:ê¬×Ulöɳe½º}H~Ö‰îEÉ¢Ý;ÊÐ?Sˆ”¸ÿ€ø×:Ú[9>õ-6ÿ…VÆðá—¡îf¡Ü™Dú  CRÃõ€èÿÚÄ6endstream +endobj +1172 0 obj << +/Type /Page +/Contents 1173 0 R +/Resources 1171 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1148 0 R +>> endobj +1174 0 obj << +/D [1172 0 R /XYZ 85.0394 794.5015 null] +>> endobj +278 0 obj << +/D [1172 0 R /XYZ 85.0394 537.224 null] +>> endobj +1175 0 obj << +/D [1172 0 R /XYZ 85.0394 512.8844 null] +>> endobj +282 0 obj << +/D [1172 0 R /XYZ 85.0394 444.1158 null] +>> endobj +1176 0 obj << +/D [1172 0 R /XYZ 85.0394 414.002 null] +>> endobj +1177 0 obj << +/D [1172 0 R /XYZ 85.0394 336.6639 null] +>> endobj +1178 0 obj << +/D [1172 0 R /XYZ 85.0394 324.7088 null] +>> endobj +286 0 obj << +/D [1172 0 R /XYZ 85.0394 175.0326 null] +>> endobj +1179 0 obj << +/D [1172 0 R /XYZ 85.0394 144.8676 null] +>> endobj +1171 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1182 0 obj << +/Length 4254 +/Filter /FlateDecode +>> +stream +xÚ­[Ýsã¶÷_¡·ê:C|ÀÝÓõ¾êLsIv’<ÐmqN"]‘ŠãÎôï.I ²œ¹? `±ØßîÂl–Û©"+,·3me¦r¦fËíE>»ƒ¾ÌY„A‹ñ¨¿]_|÷^è™ÍlÁ‹Ùõíh.“åÆ°Ùõê—y‘ñìÌÏßüøñýÕ‡Ÿ?½~¡åüúêÇ/\åó÷WÿxGo>½þá‡×Ÿ^,˜Qlþæﯺ~÷‰º +?Çß®>¾¥K“~z÷þݧwß¼{ñÛõ÷ï®ã^Æûe¹Àüçâ—ßòÙ +¶ýýEž kÔì>òŒYËgÛ ©D¦¤¡esñùâŸqÂQ¯ûi’,ϸ(x‚’¥¨lV.ÿ÷ +÷ðÝ{ÎfŒeV)ŽCs˜ÕdZæ&rYãò<Ÿ/ۦߵ›Ž8ñ¹/ûj[5=}¾­~ÍsÞÔ}Ý6ÔR6+zù¹+ï*¿–QK‰<Ë Ø.u½®"Aà ÛWZÃ`I8žM+€ï4®ˆ…¯ªå¦Ü½`f^õBû½`C»¡!ËuÙ4ÕÆw÷-µÞTôÜwÕŠzn©¥{ì`j+WÛº©»~Wöí®£þ0Ãt!œš¶9[y’§g‹È} ¼½¯`âa¡çí->û‘khÊmEM]µû½Ú¡tf¸Gþu¾o²(þlØv{VPm ßpka±ãƒ9ÈB.=ƒwÍj™8.2&´ñƒö}½©ûGšBt7~½e»Ý‚x¢ ß±Ep› ÉÌ”/Q˜ˆô~WW¿WÔÒ´ÍâíÇÏãîn¿é½˜Þ¶^&ýOˆ‹ð6æ".2ÉY&½Š¼nŒ`*3@°ßcÝT}‚ ^ ãc±çÁ£´á‡™×5–ôyýæ'úîÚå—ª§÷ ˆWÕÔÍ)}3É4t÷Õ²F „ÃL(‘,À:¨@òý¡ñÒfynĬà*“ÆÏ1_vhLÚx-⌋ñ”Î2M¥JÁ![͆•‘Âûv—b*œLnƒ)p*ò|hø­aâ$ ¤»­At¿ âŒgX •ÎXQè) ÊÕjw‚‚ù]\ÂÆ…˜?¬ëåš”GB¿Êåò,Kä•1Îœq’濯~ú]RK»‹-½9œ2u``$W'´ÌãZžd,çè ‡í1phBʯflœq1žò˜± ™aàã°§+2›ËÀY°»nÈÄ‹K ‘ƒ³eàÍö×ÄT&3 +ìúhÔ¯¹ÊKPà]Ý}wFvz¼¯è¹÷†ÍcdGOoÎÊÌêÍjI6|åÏs8«W$œiQA`Á5ÕÝ‹ós +§rnI’§ƒ–r¹¬î{òvÊ)ö–Í£o¸¥§# _Èþ¥£qD¤›g ©B* À¨–Ï[ê'ƒF¿¢UF“’z‡½z=ñ Ã2  ‚qôgð’#þH›i”>)­L˜ŒÂT‡ãÿZa .Æ3Ë*“ Œ€5ÃÂOɪÌrV¨3²ªAgý—/S.ʳ‘† Ž+²[bÞc»Ѳ6H4µÍæ‘ÞÅǬµ:Bó³A*£F6'$!‡Õ6í²ôË­Û®GêßÁÈöþ¦\~ñg=ˆ—…§RBÔóD&˜41Ë•f,A=àhP@¨ß¥o +%#ãSÓ€nZÁ‚ðÀHÝA Â#ÀJ•>·ÎDÃ˶ü£Þî·¿,÷;ÄXŒ1a A2—ÅÉà¹X¢§ó°“EGîóòpŒUb:A#ÂN–;ØNØÊ8úú•s™`ø+@ü`Ɉª“FTeVëb6åftsƒ?kZOÚM5P40*! _F³ÓÈ™å@˜ÂCUøzf\Œ§L@ ïŒóaå' çÂì ´™ ¨ˆŸøu0¦åGáhj{o~ë®Ûûþ†;p˜†®ã€I£ôêfzÁæþ·^œ/£¹yl{"¨Þ£F•›Mû²/( ÆÉ@±ÈópÀ_ªÇ.m9u!ƒªCP¸wÞ‰°`vÅ"NLÆ›±ËäJP£¸·DÐ0÷ØÁ= b-èàn[÷äãáó¦ôBË Íâìé Xƒ:Èpêh켡›Hpa3=Sœƒ ‚˜ù«%8̸O™`®!¾ˆÃÌmÙ,ªFwR|C"ÃŒgˆ”9ÿØyB$”šÉ „Ö¾QÀ!^¯k/ôäÁ&‹yWoï7þ¯~ +Z™£›f'‹7`e´\h}7hD]˜§Èå¾ +Ù”Çú– +šB„¾A¨‹"~³­Œúzôf\Œ§L¡ožÒ²aegxWi$bÀÅø]T—¹ñìi½ãJ+FgÏ-;£F!pÿf<ˆ3žá sìiÅÐy¦ €‚oGd˜ñ‘¢#vcLä)ŀЫˆÐsdÜÜ5-}¯‚_g¯%ì$§’cД<㾩ÿHÙnžiÁŠtJES*…O©hJ©èùϯþE«v[Ö µù=ͯ>¿¢CrAO’ nÄ}Ù¯©+LçǤÆáw.é¦Ázh&˜»]»¿O;|«clý4øh=ÿØöž;Îi:.m}Ëý¦ìÁ(o;bâýÏûæÇÏÔë)Âè, +Ü$:þÜnJ°³p¢ðâüv×y C q Ç°;•›?Ãëa¹A›ðãþ~S»f>w:d@úh¬Ë¾CǪö1CßîýݹM8öGDiƒ÷ºïªÍ-±‹“ÑÓÊ©l@£¼°óû]½-ðQîûu»«ÿ3Þv¾­P‘ënKYaJ€‡,ŸË§;´ê?¢ÎÇÓ?44‘t¡_ÂU€7öR‚nr°G_oÃŒ‹ñ” lÕ0mqس¡ †j€Õ)sÿ`â<3Jz¸¹Ü[ÈLXLò ]”`ø +c˜I€Û«˜¯æQ˜p1žñ˜Eü†oqÔI0á‚ß`¨œÍfþ®${”} Ííi™ÀìÅôÍ7Ûoœñ̆ÑlÛ¼°ÏØ1¡d ˜ 9å ¸É${B €dEû 7f<³aøÜhðˆ“ ŸR ¸OÅLG[æÄ™MdAKÏêj¹wN>FU'ø¢p7ð ^ô²À_•ñ¢ô¹ªNÕ~en2‡†¤¾ÝÝŒ^>¥ªÞãñÄ‘(ÚÆQ¸Õ_>U[òšÏ?RK‹ùÛšj}3¡:+Y:ûÛQ| TfJLh?ª3ÇQgH†#ÉášëæhUÀíŠqö\ŽÅñçÖ?š×ùuŠß‰;"¢ãœ•gøG¡ãx¶‘§×!n„£©D+å@^yÓî{ê9D”w·÷ñ ô†¬Æ >àG&§.¹NVh\æËžÉËæ™Ôâ ­Ä0гÇyD¦0˜0.,@LÓç ²7¶×½àK#åcï +G%fi±ëåK6J36¿jhHï2Ø·,»ê’ðsœ³Üt-{X»RŒ‘§À“²+”yÖ- !£/_ÃÀM„ØÇ¢šærŠ6F籓œßìý˪­\<‡bç›Ö¥+ÿÃ[™yŽaÏ$F*P‘’4eXÉ>+h !y=pàÞSíGÑ(W¾eí·1àZübYé¼´ûÕè*—Ã=ѳÄêA©Ã¡‰E¦Ü°‘9È<8ô?9’`E²Ø!L`àwUŸ´,Å8/‹¿¤¤ã÷*UEQ( QÞ ˆ‘»Å çxþ‚ÃîU¸öèü JÆK:]XµjèÍßù¶Ðy³¯7=ÚéŒ.ë„Š%ö-I>Kò¾y¼ ÝT›.ôAÒïi.Ch""{ðÔ.CÈÌ÷íf,k°†ˆ('_ îpcÀëù¢LU¥1m'ôÔÄ3ÄÕyq\9Hœ5 –µŸ#7Ŭ¾†íc¤ˆÕëÒ—½~ú’7e?,4uÕ¤ø /»²éÂÝ2c),„vJ¯ø Gú]þtáÍ\úRæk.N‚Ñ«Ú/K6ZœMqlш@åF­ê»º§ê$, oÜÚØ\ûj¦ñ¶:׃NcëP4-üò.ü0Žé×{ßä¨Ã&G¾ÅsÓ…Rž/äv0ãÎâ!¬pÕÓäÛò ‘…ûðæZƒ«›}`®Û®«o\žKx¨-4Uß±Á]1ˆ½ÁM’“„n(Ðnè1€œ‚„h0 öó„_jwAö rôŽª•ÂúbÐË9ã CÉUÜÀn¿Ëñ7ÚÝ¿Õ`x~eLš]ï”K·2•²w‘6 g^t-×Åxi§#Ò;àéÙ!½tcýKÔæ2‚0Šâ¾ I9$QŽM ÎðªÌŸ²-€ŸŒíò¶wAÕˆL §æ]¿†ðWä=CY¹n1l6G9$‚ñu³¬(‘Ú'-”„8TIþ, e†+K …³;Ì”óxá¹:T‰w«·ô¤je$ÈDÀ÷àï«ã¶÷ ÖNIpÔÞ]„¥¹oéI Â_jf/ˆUVd“BGn}¬,Ö+ Þ~³óˆÛ§†<ŠÁâ P” <ô¬ë»µ]ÝÑ+êqWرÂúº2Ý<â‹ù¿»Üû‘¡J/ÐÊwµNAI»;¿lÐ¥ü8ñ„Ag¼¨©è‚š +ð^:ˆó}×í¤K⥛Êé&6iÝjÁëv¿YQ#ZGO vblâ9µ ,];wŽ;éýË4ϬB¬…/{ç|ÚÐÒ·‘’MN–ª ©£U#X ìèWXÅïøÄÚ<¸£ç&®˜( æ™åÑm>î‹@7T Ÿù–(Céï8ÿ‡Tó¡²qï†ùÛ8"œºmëê!.çwù3ì[€+ W9pLí¯ 83ä‰óöî·Œ›÷—•™D=Ñ2J™@bÂUaÀšó7ºdÄ÷!»vI—ƒzÛ°ˆ¿P¦çMEé9ןk¤'µüÔZžPC=ÜÀŠR‹7~e¯òËÔB o]6>=E«ò&üÖ¹Ô@ø%€9‘½ñ,®f]ú[J£¤¼ +—ØèÒÒη=¬ýͬÁ4åÁ>cùßQÊ-ÆF­êÎS<^e-ñƒ`èe$ \/ 'ƪ)ÔÂ1‹¤Šg¤vº0Á/Sâ…Y Â&çdòäœþBÀ]2î‡Cáè_¥¤5“˜ŽA‡ÿ³ŠgÚ +Lò$UÄ„Qþaˆlö«*ù0v%p;Óü»KœQÕm½©Ðø¼:•ZÆJ…©¤d‰ÿê9e¦5& ø‰,«6„ "…»Ååá“ŽIÿ?hPU‡endstream +endobj +1181 0 obj << +/Type /Page +/Contents 1182 0 R +/Resources 1180 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1148 0 R +/Annots [ 1184 0 R 1185 0 R ] +>> endobj +1184 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 404.4849 256.3816 416.5446] +/Subtype /Link +/A << /S /GoTo /D (rndc) >> +>> endobj +1185 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [268.5158 404.4849 332.4306 416.5446] +/Subtype /Link +/A << /S /GoTo /D (admin_tools) >> +>> endobj +1183 0 obj << +/D [1181 0 R /XYZ 56.6929 794.5015 null] +>> endobj +290 0 obj << +/D [1181 0 R /XYZ 56.6929 724.3071 null] +>> endobj +1031 0 obj << +/D [1181 0 R /XYZ 56.6929 689.0661 null] +>> endobj +294 0 obj << +/D [1181 0 R /XYZ 56.6929 117.0915 null] +>> endobj +1186 0 obj << +/D [1181 0 R /XYZ 56.6929 87.6248 null] +>> endobj +1180 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F14 729 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1190 0 obj << +/Length 2372 +/Filter /FlateDecode +>> +stream +xÚµËrã6òî¯ÐQ® +<,Ÿ&ÛëìÆÙxœÓdjŠ&a‹>‘²W»É¿§)R¤,ﺶt`h4ºýB‹-(üØBKBE.TI™\¤å]<ÁÚõó8A‡ ±¾»?ûöJ¨ELâˆG‹ûÇ-M¨ÖlqŸ}^~üÛ‡Þ_Þ\ÒeDÎÑåw7·ßãLŒŸ?Ý^Ý\ÿr÷á\…Ëû›ŸnqúîòêòîòöãåyÀ´d°Ÿ{ +G6\Ýüã¡ë»?þøáîüËýg—÷½,CyVßÏ>¡‹ ÄþáŒk¹x%,Žù¢< ¥ 2¢›)Î>ýܬº­sú“B©¹šQ g ÆH,%iPÆ$\8 Z¡#P¥t™Wi±Í Šø©MZSšªÅá÷æWJy•·y]áLReüÒ$Oƪƒ£ X&Bp¼«ûU‡ÄH,&”Ó-NÇÁ”˜ˆH†^3`NHØÖ˜MÛà ]šµIs˵±ŒŠhiáÂ/&íöºÎ;r/+³9gzip[;Ë85‰ÀïãÜ3mª´ÞV­?7#–Î"!#\3½úk|M‘R¼…E˜ŒÔ ;Z-“4/r;gùÒ‘W¬$Y™WyÓno°X?âZZWVµOÛá"*»AŒ‡~×fSæm›WOäQî$ëWê ª@‚öt,:  )½lr¤!(r!(\w]œiW°ØàìöÅɪnq¦†C7 xz¨Ôò +Îq³æ_I¹.Ì70âùrD÷ú±Dà’Š Wzg±óëMþ ˆ8øÍìÎÙ²éxIüÞÄÛ”‹Žo´“>y(¼÷ÕU±CèÁQUTIé!0úg°ˆQ¤7ˆ¿Ã!`{àØ{OWÞÓ-‹s^~½IÊ2Ù µwfG BJ_ó áÿ8Ù¸ ± ~£KŠ§.mU"&Ø\ÑÅœ.“nL;E è"öŸG$•…½äú„äÿ¯øÆ)x?½»ÙÓ§„G*1! æ/3dÌz’&øiVÞœ2?­¹±ßåÄ´À£3p¶A஡ûO7×ýJ%mŒ9Ìg!U$âÀ¤ä Î0v 7O dž0 žÒµ‚2)jßr™l”òt<âf’{¬SÈq;æÐ4$“j*A4„”SÝáà 3®4¡ûF‡– ZmH~êÐÖ).&ÔöaÒ²PnŸA|UÒ%,Ÿ=“ö ~AÀ¡ –8åÇ¢‚<´?ØèHœÃ3(Š\ˆt¾åÆI¬µž…=Å`HÒ)kÌÔa UGæjñl΋¼›¢ßX“fàM WËߪú¥B0ið‹ +´k®„á‘«ÝNŽï‹Œ+Y]&¹ßïëE€¶UþûÖ¸ÂF¦ª6ÜaÉÍ£ñŒ±¥sM¾¼iq]€‡Žžum¬ÒÁããèóš£Â% +I»²È²3^J e|îédãFˆ4éC–@ cÓ=› :ävÆŸŠ³õ0jÁ¾ü©œX0áÞÜ©NENýX,ŒB\–!/Ç/“6]ùà¢G6“cK‘#Ëðr¬h½Þàvü2 <;êÒ¿’ô¡À°¾Jž ®=Sá\/ À^í*I;Ö€c±§ìEÕª·²Xí«ønìË¡™‹QÒ/Ÿtk[(+ѹõþ½pèܸ(NH™-!ùû}Û †g\;„Æjpðq׆ÊG²þ%j„=VÝöƒO„ñVCp1ת€G£ëV48×m0PºäíîÛd  +›ú +ÄíÔ® +UÕòî*óû¶ëum›"Ó·\‡àV”omU&iPfrF"xLiNU¬¦$%Q²¯%x¡°RRkqŠ”> Åy8C,²¸ýÃéÍ|q%&ÿ[bBÏrY3êËRï'ä€*”ô$ãGéu‘Ð?ÜÉ6èJÈ B´Š†C°µqSˆð ¬`³ta£Y¹f}£Â-x3B<á»Ó×k(Ò0ZÀ´Oîbi›Då¶D¤j[>¸ ®¢–û÷ÏWG6wñ Ö×8Œã +ÉÔ`Yû®Hì¼Ê3`߶nÀî y"3ÊŽ¡>f‚Zh éŒ¶#Jtµ¡íAn>µ"ÈcQŸ¡°wq²‹H³p•Ë{CVG0Rœ†,a[‚1Óûƒ1‹º4[+©å lYÍâÍÆlÔap µ¿ ¿îëüÁÝø­t˜6°“Õžp1wh«}¿Åm EßkûRÒ/$¾àLD!l5ëQÆ·6Åbß*ê§'oÑÿKc óxGcßc +êUÛž +û1ú†Á`𠶿ïài')"=æ…G_'í +wíÃùs¡¶h $48ÚÓê<ÖÂàg[y™»;𸠡/s©ßÓoò› 9n¸3˜•ËŸÚìPåþê{Ó»¹ÈÐíj3³ÙÌñõG'_Qìå¸òÁæ1¶ kw{E¥¶÷œ&ÅHIpj=VÛK²©zCèN¯a§é¦ìÙ>ÐŒdÉ«Çz´-3[OÈså;¨Ëê®?O‡"5>>n$è<¦ lF_õâîŒ7N¶ª¾8}÷Hi¬¸7SbSJmÞ¹Ã)*óõçxËÝNy"6ýÈ£Ë:ºNy'÷–nÇ6èÏý?)à™*fÛ§´—ñÝÿ]îÿØ…òQhÍç ‚FP\ƪcÊr.Ô!çýŸœSÖÿkɉáendstream +endobj +1189 0 obj << +/Type /Page +/Contents 1190 0 R +/Resources 1188 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1199 0 R +/Annots [ 1195 0 R 1196 0 R 1197 0 R ] +>> endobj +1195 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [406.6264 524.1437 456.8481 536.2033] +/Subtype /Link +/A << /S /GoTo /D (tsig) >> +>> endobj +1196 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [140.5805 512.856 196.7992 524.2481] +/Subtype /Link +/A << /S /GoTo /D (controls_statement_definition_and_usage) >> +>> endobj +1197 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [103.6195 470.0794 159.8382 482.1391] +/Subtype /Link +/A << /S /GoTo /D (controls_statement_definition_and_usage) >> +>> endobj +1191 0 obj << +/D [1189 0 R /XYZ 85.0394 794.5015 null] +>> endobj +298 0 obj << +/D [1189 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1192 0 obj << +/D [1189 0 R /XYZ 85.0394 749.3189 null] +>> endobj +302 0 obj << +/D [1189 0 R /XYZ 85.0394 679.8163 null] +>> endobj +1193 0 obj << +/D [1189 0 R /XYZ 85.0394 652.1211 null] +>> endobj +306 0 obj << +/D [1189 0 R /XYZ 85.0394 573.4726 null] +>> endobj +1194 0 obj << +/D [1189 0 R /XYZ 85.0394 542.9681 null] +>> endobj +310 0 obj << +/D [1189 0 R /XYZ 85.0394 335.1831 null] +>> endobj +1198 0 obj << +/D [1189 0 R /XYZ 85.0394 307.4879 null] +>> endobj +1188 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1202 0 obj << +/Length 3489 +/Filter /FlateDecode +>> +stream +xÚ­Z_“㶠ßO±“'ïÌYÿJê=]’½tÓæ’^6Óé$™ŒlË»êYÒÖ’ooÛéw/@€”ä¥ïÜöÆ"A +@ø²¸Lá'.Ml!‹Ë¬Ð‰I…¹\7éåŒ}{!xÎÒOZNg}u{ñåk•]Ia¥½¼ÝNxåIšçâòvóËÂ&2¹éâëÞ¼¾ùöç·¯®2½¸½ùáÍÕRštñúæÏ×Ôúöí«ï¿õöj)r#_ÿñÕ·×oiÈ2¯nÞ|C”‚'˜¾½~}ýöúÍ××W¿Ý~wq}t™ê+R…Šüãâ—ßÒË ¨ýÝEš¨"7—ÐIQò²¹ÐF%F+å)»‹Ÿ.þNFÝ«Qû‰4‘Êʈ¥¸")Œ‘3 š"±Jª`A‘‚UÒ4]캻»º½#-Ê¡jªv î7Õ¯i*Ûz¨»–(e»¡ÆÏ}yW¡-`E5Ù²ô†“ãò°Ôí½Ÿ$&“dš¤*30çx ž3S9hYž×Â)•-Ö]‹ÒÝöW"_T=RóEIƒõ¦¢Öûr_WÃuº-Í +J;âê×SgÛí©1ÜW4·-fÕWû÷Õý'“‹›¡h§ÀÖ*‹½¾/Û¶ÚEÔ[j‘%&ËÕå2l¼ðp¿/{XR*°wßwëôî±/Ýax8 4ÖTÃ}·é_`O£àMÉ#A#|…¶ ¨}Ò×h +ìí ·ã)õ•…y>“ÚØX¬ËÖ“*n­*:ôÕUD eè´>ÖŽ¯qïÄŒU$©QÞT è]·ŠØJ§‰Í½Iƒ…mGϾÚUköÛûùÝ¡§ÎzÖ¬¸ƒž€Ï¦êÑ“™Z’/Q¤Ú$N+8gI¦Aµ~¢€¹å󆧥Ðó1l†z}Ø•{êSÞ¢ö¶\×;ÄŽBˆÅÑëtvð…ùiƒå¦§ÍM ‡)fáFôMݯ™‹‹}áÍ@ Ñ!"¹’ŽD2na;v= +‡H¿nêˆ$'ÐØÎD¢âœP±ŸN°7÷8h+~©\¯«‡ÁA2_=-0îPMMFNÀ‘ºÂÆ<)„)øDÔí¶‹Åš<ÉEbMjÄ ro­³$SFÌ]ÃÁ?%²Ñß°ã-<ƒ'c§Œ!7a’\ûœ†•Á&v’Ó¤(” !²j+õ¯<Ô ¯nÒ¸äb<G´ƒ=®¹PœvóeÇòŽ[…=Þ*lzÓ×6ÉUnç QŸãCÛ ó7žiWë>¡a“àpc¼ˆ—µkìÔïb³ˆ•¤H2ëóÈ<^vŒšä@å +Ð]’Fâ$F˜ü]¡PÐ^"…<­˜Æ1¤vDtþ ýÙƒ «dê6q(/@¡‹€Îy y˜€£ŽæXq‚á¶! GóÓ¬Èjª²<±µÎ7´L-l¼ßaˆè!Òؘ­Uf‚­U†!¡ÖCOƒä˜8Ë‹ŽÓ܉É\ÄĘñ ¬,) VîÕ²¥Ññ€ÕE¤Ò_9aÕa‰Œó¼dX¿:[H4Zê¹­wd@À¬`#CÃc)l;‡'øM÷èâÎì蹪Ö]ã’€Õ\•Šfhpf…·ž·z.ÏžZc¤ãNϾ|ï®Êõ=¿ë¢”'ÅŽFw%›˜{`mªtA‰^;цêâ:·6Ñ©òŽÔ‹\7ˆÄZ;)Þ‰k€«ÖáùÈ4]ˆ<_¯Ôh•üTàԉΔdI\\r(”6þ"Gh‹°µ*×ï4>nŽtÛÑnx<'€vÉ4; +’˜ÈT&ya—~&[a‹Ë7há¶Àtú,[¼vQÈÕïc€©ÀF*í4Ö÷]G§Nòq’‹wUõàסµyB·ÛPc¢’·A*l¨Y˜áöôøè4À(Áý|¾ ¦H²,@QÜXñM—’ùâïùakUm»P®B¿fº+´àIþ«"`§m–†+ úçò@P™÷AÏ<ìK¬@ºÈJŠ†,²ŽŒ­I‰ ösf (Ôœ™Ïð.Ø~~^q¡4æçš 8…ÒâH¡ô´BPNÈ3-7×̤\œ{Îê!‹b§Ÿv¨s#>³ô駤Gü )åoW¸ýÖ¤¼ ¨#bµ£‚°S€óÎ}Ì!ËZ—‡¢ñ*$­ <² ° © ýqðЬ\m—'àéDà$Ý09 +0sÈèi.AëÆò9¤}kÂé e5ð¬=Lò×å’oŸG\d¹Ø-ÆRˆoÍÒĤG †o¹= +ˆÒ†–/º°µáúØpˆD ;&9^UÌÅúHáÈÕ‡uUmú£ëvS¯Y!˜„–Á{Y™-Þt4ÃglO3ÚqÁ®wP¾ðÕ(WÑ _ìË÷%ê~׬á¦`ÔgDÓ} qŸ_+@³Mu‰àóã´víø¶rJcòš4M;ð•Õ‹HÍa“ ¿é|*’ŠBûIGde2uÖ!‡86wº>úÁMdvAç35C…Ÿ±Êöw. ~ŸÑùKœJ +ü“Ål7·5Ú'}Á¯"´ú‚HcÀÀž¢í¶dÚ¼Œ~?Ú×í°¤jç=U}ô#Í›ª s—QqÏùw2Eš<\{ðõl$a@Z)ĉ+&9¹b’ók$0L’Óë#Ép2 +kî²Úc¯0¹¿C8_Pø;v! ¹(Éï3S|µŒ@x"BÉ_– IJ,Ç÷xc$†âÖ•Æ'Ëý н.ô' &O¾ÐjJæù‹ÛÔ.þÔvLå›p÷ûåôÈ|»4N* wվߦÇÕ×üÎ"‘"ü™vn»é‚£j3y.—¦¬wñ  ƒ¸'™xÿÛ”¨c9\"ós…)ùO s¶J'7Wæ 8Qv.ŸÝCÔ¾*ù¨BK%@¤3‹bñÂBV¤É$Bhï·‡Ãú!ÆE&6×ù§¸xаÞG7 <§æ\Qp¯ ä½ízÈCŸËi;<œ²s*Îe²ëÖå.VBKpA›ÊÿŠøßù˜)ù™äQŸ‰þLz™Ï$ñÁo²á¾ê$Ñ6ÜÝ:VÙ"-¥Ux·]ñ¿$bÿÝT&Á?\Fþi™†¯úÿ÷ÿ:Ç?½ê,Qy.Ç¿lÎäÏòDçÀ„…B-TþLrÿÐç¢ÿ¬@Ùendstream +endobj +1201 0 obj << +/Type /Page +/Contents 1202 0 R +/Resources 1200 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1199 0 R +>> endobj +1203 0 obj << +/D [1201 0 R /XYZ 56.6929 794.5015 null] +>> endobj +314 0 obj << +/D [1201 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1204 0 obj << +/D [1201 0 R /XYZ 56.6929 749.2381 null] +>> endobj +318 0 obj << +/D [1201 0 R /XYZ 56.6929 540.3599 null] +>> endobj +1205 0 obj << +/D [1201 0 R /XYZ 56.6929 517.4049 null] +>> endobj +1200 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1208 0 obj << +/Length 3336 +/Filter /FlateDecode +>> +stream +xÚ¥ZYoãF~÷¯0ò22`1}‘lÎ%A@K”DD"’²â]ä¿oUW5/·í Ã`_ì®ó«ª¦ä¥€?yiãHèÌ\¦™‰b!ãËÕáB\naîë Ék–~Ñr¼ê«»‹/?êô2‹²D%—w›Ñ^6ÖÊË»õO‹ß¼ÿçÝÍíÕRÅb‘DWË8‹¯>}þdôøðÃ矾þ÷íû«Ô,î>ýð™†oo>ÞÜÞ|þpsµ”6–ð¾âžyáã§ïn¨õõíûï¿{õËÝ·7w=/c~¥ÐÈÈï?ý".×Àö·"Ò™/ÏБÌ2uy¸0±Žb£µÙ_üxñ¯~ÃѬ{5$¿XÛ(¶* Péã,J4L¡«ºŽ2¹È÷{jlòU¹/»²hy¢¹’vQP§=uÓkêÖÕäe±¨E“weµååmWZ*ð°ø¦>£À€,9"K¥qC˜A‚à•}½åucòµŒ+ü²sééÝåÕzÏ䊶ͷžò¶¨˜¹®æç®lqëË¥i¤Ò¬NÊ(‹cåveÞQÉzQâ>±Y¬‹vÕ”÷Ži®èÙíŠ;RÆ‘Lc=a'ZÕÕ&Àh7U2嵇œw> 3­ÄâÓ†hx¬O4·Ë +Êi€dLíó®\íhöÔ:1À ¯{(šGšª÷ë~¨-k>´Þ¸YÊÄF6K§bzIG*U†ùévyGîRWûGjy²Ä¢;×Ô Ûž .?ÇSψ8‘Ò©7°¹ +ÈùYÄþe€,ž-¯’Í©ZuÀöuFå[%Ÿ¿Úç@(µýX[î@ÏG¹­jrŒuD2ã D¥tæ» sA:ö6R€"Ðê×–’× TÅ‹sÝüÆæ¹/ ‘ÚÈ€q½æVÊF©íMðMKÛÿ¬”96eÝ8 ÀÞ5M¬ŠcGm¯_ƒ2|¤±Ù0Xç¾­ièžIÚ×4Wnh„ÚŒ0YÃC«-IU&&ÊR«gØ5y¹Ýáé*#k'º‹Ÿ…P`ÀhW4¼lçhƒÖ©åýçj16’6MÿžÌÐS…^|?`á=Éê™âoq”Ÿû"o¹Yoh Z½è ƒW>{jnˇ‚yq@H¢J 0ë!MŽ,öží¹-öÅŠz›º\lÄTûwÔ!*úñ†ž;~Ñøýz"¡çˆäՌѣ³óZw1u„:#3² +lô‚ÃÎé +=¬6°t èþ÷´ölÉÞ„±,Â&ƒ§¾Œæq¤Ó>B îCû“4_Î5 ð¶.º¢9”óxv…-bÕ ¬>Rÿ˜·œ4 ^mLäG&3ÉmÃV¥˜K–M‰ÎyS Ë'Ù0¤Œ'ö¡Ìƒ+Š•6͘ „ˆÞZÉxfV´P#ßÄ ôME“)¾ÉrD¿iYmêŸÈÈêÞäê†)¸ðS®Šj¦l^&ÓHè=“¿&ƒ=ûªmeÚÚ)‚}rŒÅ„PØhKpÎ%.Ø='´HÔÆ̦XƒÅkèËnâòàLÆžÑ*?ëÒfm½"88¹“Ç +ˆY1Y^(14Qo¨Ï[(I©Ä+É91ìÊ –í¸Ê¹žùZjzrÉÆBl!þDIjfð¹>í94€U;räÓpPò4É|U@Tòa…t{Ç– ü?Ÿ)ÅYÏN·.š&d³Y$J{¨hAIl"ðú(sÊë’ÉuÉfÒS— ˆJA³a¶-šŒy 7üfÛwP”ZÓ"¤oøŽÎʘ$h LR:™-úgÕÕš,”I›P3€¢mÕ‚xh?SÎ +CDžU=yØv{òæÊ.NA=Žç-?é±á vË‘a_;Rº¾¦²®§€CÉœ +‡ÍÛáz²a¨Ùžš|Ùk|äبŸgM+8f +h Ì’kP—†Ã`ñH¯-xý˜è"À5o°œ)Æ)® ¨`¦¬;€½×ëÂU¯Š*1WCΈ#ƒ˜ðÇe_ßçhN6áèÍ´Ïã`”•,¶l&i0õ¹*Lý‡Ð­všˆ}µK&2O¥4q.!Ur —yÁt%σc ƒä ³A +“ÂtQ9k‹Ž µ()¿ÖŽz¤1ðŠ†1zÏUÉ +J8¼Ž½€Ò}™Dòî!ÝÚïo&)¡€û,dÚët%<úƒ¡êœIÞÔû}}F(³•ÓãXCøq‡=ô^öv@fdäsä† +[A£ÍPáo4ÕzÅÔäÁàjL”€EŒŠ°fá­^³ˆx¬ÙØöšE´Ë)9·¤Ô1ôMRe—â±åÁ2¶<|ñÔT#!DCå5!åý#¾( +ˆü‘1ƒ½¡¢Ö‘HŬ„´ãÑÀrЬDcT¼xO.‘MÇŽCšµ„Öþµ#\ÍüÝ‹µ„pvð®Îœ“Z–Ì÷uR`-¸%ð²(GÎc(b&,C½—{dëSwCh^Q¿7Q5'¥\\ÏjDFÿ·‡›!xJáI(W¿ºs~eÄ™ÿ:^•†M¹ÌžÌ65Ï4´zFF#yõH®<ÜÚq£G8¾vÂ14È'ÇKçt7©Ïx·œ‡ 'Ñ…Þ“ ë³ºGmÍds˜r|€]¥`ƒ]áÌ3©´""õ`´~@/W!ÐÒ‘”z~ï嶦²ÆšÂYÆ…sÑÚ뇽àa´«Yõx”š×z£‚ÛÝPôn2Mlýý£KŸ»¬x*† PJË¡þ¯º¥Ór@6²i_ î\bf$@±‹îF Pjð–ÑhüÏYan 9µtpÎñŒÛ˜žP l¹Üš«0îL_ ý êùãø¼x@ÔÙ$žÕ¡R9 TŠÿÂ7mŸ 0è\sX;u®(ÓNÁÀøB5ðG¾‚smY­ÂWÍ’æ%û«„ø»Ï”ÄØÒ‘\I¤^g±0„‚v!\‡-KeY_àvV°Ï¶nB÷ÆI¥I_úÆ$À˜ÂßOP4¹’S{¶4@¢:Å›]>ÍõÜM`Óì@ô^Ê—¿ð$㶳ö ÷=¢Œ†Œó#”k¨u°ˆ ÉAYÙ_)^¸?{K¥Ɉ¯®ûê©bÑ°8¼D €¥Tc¨‚ž‡h:è—rXÙË;F uÏ#Þ—&Kž)yb"­ú»1âñ™šWô `}Ä2§e"òÇé±t÷Ž-O¤C«´Ã=Ë× hôÚ}É{©³UHoY¹mæûsþØÒ¨S4Œ9r ^ê²)í­f)µ¦Ü‹2ew Ú¼¥«!tT Tʽ¹y“ÐvšœDtßóM1\¯Ç¤axºÜÎêU$|7Z›¸K@méEP5_:‰_Õ È/SÙ\3ÃǮ ¥RËXã}¶™e—‹û%DZA9ŽŒßŠø-6Ñ4²-ª¢É÷ K|‚¯å|¯™¤ÝúùÔín$¥DNðÆàÔÐð‘?~Ñe²Ó7Œ®†$4Q> n¢ýw hq\xbÿPf"{­6DDì+Hº’Á¤`“Ÿö€ÎF¶†4´þP4Aü& U—û&í†ù¼•Óp˜Š”_¶ûOYÃ×ÁÉ7bw0ûi€L±^SæR¹Fê>ÒÓd³½¤Æíè«~¿~9~áéWý§û"?+û%Ü龜Ԝ$Í‘ÒNHzòó‚~Õ+„<ÝŠ¯€ËHJ”y¡f`=þÊ÷µja¼Œ®êßÝk4ü/¿ä*¤@ÃfwnĽ„–3¼FGàÝ@6«Èý>ý·þ3Yªu ÞB=¡†>OLéâ/F£×BÔ¨ 5¹™KM.{04èö5‰Ð> endobj +1210 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [173.6261 273.4719 242.2981 282.8815] +/Subtype /Link +/A << /S /GoTo /D (the_category_phrase) >> +>> endobj +1209 0 obj << +/D [1207 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1206 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1214 0 obj << +/Length 2391 +/Filter /FlateDecode +>> +stream +xÚµ]sÛ6òÝ¿BÓ—H3B€ ^žÒÔιsIZŸûpÓv2´IœR¤Ž¤âª7ýïÝÅ.ø!ÓŽï27z °X,ö{œð“3‹8Ué,I#¡©g«ýE0ÛÂÚ» É8K´b}{{ñê*Lf©HcÏn7ZFÆÈÙíúçy,”X…`þö㇫ëw?ݼY$Ñüöúã‡ÅRé`~uýK½»yóþý››ÅR-çoÿþæ‡ÛËZŠ™Æ·×¾#HJŸGˆÞ\^]Þ\~x{¹øõöû‹ËÛN–¡¼2Q_üük0[ƒØß_"LžÝÃ$2MÕléPè( =¤¸øçÅÁÁªÛ:©?ÆjB‘œR`”ˆ8IH«]V–¶X,ã ˜¯í&;í§¦]Ûº&ØPÆ™ +E*ƒh¶”R¤Z+·—Ð^ƒF“0_½¢÷uÞÚ†ÆmE_¦ˆ¤O„hìg N„——› + †j@°* ^nl¹¦Ñ¡Î«ñ6âSjPc8æÓÓÉüæ]¾ÝYâf©ÂMu&ÚŸ¯=¯$yøPYå±(†*’‰HCeÆt åI‡ò´UÓxŽNí./·tm§6'’B&A<ÖXGf—3Ï×zu¥ÂG x©0&IÎíÎ2ÒÐmT "…=äÜï%¸`G³X¢«ä9Ž¯DjŒ™vû¥'¸Rt.=âMÊP„”Þ¡“wÇ털¡: ¥3f˜Äó]Öà ¥Z‚4»Ê3^>Ô iæÕÁÖèqiwYK;ò– ä¥ìõqe^;¶‡#ãßïléiø³l A°XB’yÑ 1í-¯‚¹T@Ø4D/ÀoY•X:òY(ƒùuëWê}V {8óñ‰cŒOüfôù%Tai¼‚vMjåXœ†õXf{»õ±œÐ8¤eLʘyɇîøˆ±ÜÄ\Uÿæ'ë܉cWmUŸRʹ í„A,¢$Aõ¸¨#»_U@K¥Ð])9àŒhdMU6/¸•M€kÄ + ~Q*šUF¡0©”,Áò8!¤·¡8BŽäªÚï]ÊÁI‘—î$ ^ÔæïLßcc׎7í8šàC§"cý<'*õÛYtpÚŠ5ÒÚ5³„®KŠM”PR%lÓRºÇi¾«ìÐÉØDJ.‘¾P³&èIìM;äÉ9£ ÿ¯8¾ÏÛÝT=ï‚û‘ˆ‚’¦LêSÂrûÜ€Š]äèÀ;CÀÑÝg +Î,- °Æ‚íª¶~"ñùì +ié“‹ql|,WÀ¸%ûú0 +- æAJ%G3„¯·âñ%̹ßf¢Šð‘i‘UF›ãyV´v!ç5Í8}Íc^´K—`q±ÖR¯›‚’è˱ÝÈI::ÖÖõ¾Zç›ÓYîöU£j»í²ö£ª¼l;è +r -›¯<oð:<|—}îêô0†g-)×송ã + /ºÝÙÑáÌØ»:kì#ýP$ÒHF¾òÁ¦ú‰™ï]Bp/Ø< +õ¼©hÁÉ‚¸N‘¡öATúškÄè¯2lqÔV´ÔXƾ÷¹0|°‹ÀЄøžî¶-Yü‚ŽVžSç*Uù¢%Òs.™R¦UFKz4n“œs †˜pÞ0‘j3ŠvÈ Õ鿳9'ŽSPIHÀ&¡ímÓd[Ë<çå”s[¦ÌÀä¡JA%˜xŽÑ‡j¶â´ v²ý•‘†@‡àó:¡EêsÖðp¬6­Í0À58j¡d98—µ‰°N›ÏÖ¨*2žoP„‘PõÙígSEußÅ!¦ÓQìò¤O³¾ŸÄ¦äo<w]½¬ƒ+¤¿¯•§Œùz t5œaϹ¤¼ÁpQ…1¦T<·¿gûCa. Í²í‹†šìD˜¬èØ€Èäš|Ë!w#‚!¼Ê–ÉxÔŒ¦T(ø4—3GGdEÃøþ°xþ›µ>ÖE=€^tîÁãTj!ÂEŸ¸§ÿ×"UP½_pYëão˜œ;›?i?óðR»?}òªø4Z˜| œ²ÁöÊ!}3ÜŽào^O‰8uåç«ëÄ+߯§ÙØëzó}áÉbB¾IÏ]v‚ƒ3þ’½zD·ÎªþÖÓ5{\* ¾é 2 Æi9jaÎSäwLôðR‹$ìosøªñ]èÚÂñ½yʳ@þDHlìa#[ý¾±õËÓ0Eð;IŸÎ 2¦íë) +O§‘«AV ¢¾¶ã„¡Ÿ³¼Èî +h¸2êbõ¡0¸؆†kÛ¬êÜõªŒUmF„¡?ìÙ•9`<Àu[]ÚuâÓ«²ÍòRL)è}Õ‰0Ñmí³“Ï(ì4ëµ]ýhs\ôð5” Ü¡m#¼ý)4`A +•R hôs n‰$HÎ^=ÿ·]žì¡VÇú h_´xèwœ¿?y¡` m¢ÇÞŸð +™Ìd‰ÀÈ/ti$ùHsÍi&}ÉŒÂA/ÄKÔû64miKÜ „VÞÕp‚½Õd_T5¸7–#×Àù}ßåF1†]êÀÓW¼­*q¶=ÖìšÄËüÔ]ÂÚrªyºM¤I¸}üu6Cï€ÖÑôo¶Ï'éw<êF‰8 “§Ý 5Ò©v: Gˆâyn S—ZV»%äz ®œ¿w7 é©ÀÖ ù ‡œ³\óèYÓ8“ad#î_UG|9e©þæ2ºTsÊÖë׎¾¡±Û> endobj +1215 0 obj << +/D [1213 0 R /XYZ 56.6929 794.5015 null] +>> endobj +322 0 obj << +/D [1213 0 R /XYZ 56.6929 496.5566 null] +>> endobj +1211 0 obj << +/D [1213 0 R /XYZ 56.6929 471.7746 null] +>> endobj +1216 0 obj << +/D [1213 0 R /XYZ 56.6929 154.8032 null] +>> endobj +1217 0 obj << +/D [1213 0 R /XYZ 56.6929 142.848 null] +>> endobj +1212 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1220 0 obj << +/Length 3046 +/Filter /FlateDecode +>> +stream +xÚÍZÝsÛ6÷_¡™{¨<­pø 2o®-çÜIìœí›¹»¶ŒYœP¤*RvÜ¿þv± D9´X_œ™ØX‹¯Åb÷· ‰‡1Š5ã*‰F6‰˜æBfË#>ºƒ¶·G"ðLZ¦I—ëçÛ£¿Ÿ+;JXb¤ÝÎ;cŌDZÝf¿ŽOÿqòávz}<‘š ;žhÃÇ?_\žQMBÅéÕåùÅÛ]ŸÛh|{quIÕ×Óóéõôòtz<±Ð_†žép~ñnJÔÛë“÷ïO®¿ýåhz»ÝKw¿‚+ÜÈG¿þÎGlû—#ÎTëÑ|p&’DŽ–G‘VLGJµ5ÅÑÍÑ?·vZ}×>ùE\0!µMTÌ"­ã秥)8LH!X¢õÓY'BYÉâ™hÃ8Û3‘¢s&"R,VJ¬N˜QRùC©Ýl³Î›G”tP «# ³ ãÉjµ>ñ¸ºO ’kZfDd®ÌÛÊjN¥çul\ÝÔì©è#½5FŽº+þ:)¨(f +T ä^S°QÄxÂõ`#ËŒµ¤í³ªüsy7(ØÓÀ¸Y§M^•$>¬)Ñ«t]çåÝ¡‡Ó˜¹ˆ¸³ö×±T,9xe¾²íñ¼ˆ%pÆ\‰XÁ¶¤H¼äÖ®®Š{·ñÙå Ø +®‚VB¯ Šú'4 v\of lŽÆiMlÍÂQñà ©ó{GmEU}Ú¬jj_9Ï1ÁÀ\A÷HæÕzéÂaµÇúÑ-Òb¾SfEîʦ á˜C[:[l¾L—A#j·Æmƒ½;pî~Ý!}Û«Åc&åàÍ‚qb!Œìçyz^žü«2ȬY§e =ƒ ýwdéé¼î¯™Ëï_­ÝÚ¿cãeð•&‰Dl’„ÅÚDû"®6Í7’qíÊì t»ë~]ñŠWo1%¢!§kbË.Èé–U“χ]îm+¿Ë«Û‹óÿìÙý¦šUÅáuVõ=릕Lédèú«Y™àX½½Þ‡=ÿØgr_Tº }-y ³öE°íñ¼<…d:VƒÊhÀÒ'œ¼è¦\¦Íl®jH¤ïA–éƒ , ·;mŠ¼cʨò!­©nS¦ÀxΊê2׸õ2/ÛêE fEZ×û.Tú ñ¼TœŒ+°*áèR©âa‘£ÏÆ:…Ž0´à°¾¬¨Âo5€v·'X^3aw÷¹{è”L(“&ˆ9¬ŒÇ'4>\öDr¬É>(üV¥c·Y.Óõ#}x eZÔR0Å݇ +PÛT¡\¸¾%kXNF‘¾ Ò2«¬nÙÒÆÝU0¿· ÇÜ.r’ùDX°ü±Uû²ßö™(¥üš•ŠÀÔ ÕÔþa®kRúl¡+Vù󂺺ÉÜÚÀ\JGç`Cææé¦CæaÀ¼Wêí•õ"Òωî‰ +[/7EÑ'ÁZŽÙ"-KwÈ–v.Õ×]ÔokK9gFƃ¶”GLŠ ¡¥kªõ§Á›øÈŠêõ¡Ê!{ÙYÌwìtƒPj@f:‘Lê$ØËUWc8æx³˜ÏHdÔ瀼º ùŽÁŽ¶†YEi:†Ixwä5ùV‰†p/ðåÝM¼š¬eÊÊè%c¶]ž•vĦ"=„ܵUD G°ùuîêA)᪚ 1¨—Û÷âg;áôEµ)²6|¥r민1f}Öúlu„n¢I×Íff?Ša0šÕ2lõ‰­·éqy –­¹~~ƒ + ¿2ð=ä`øýØÞÏ7 (NAĶç¦]€*Ò&8ú±{O _¸Oð±) W×} g+#wø={V'f#øªUH÷ÀØ D-ÒÆ aW¶^™³$Vñ'ˆDë²^±SÈùU‰kñ8жŽŽ{U­›0qÓv$HñC¨¾ø@ L³,äNBÞÉž¤ŽNÜXp¼ËnëòC·[üTH„5*c<„ |„=îËãÊn1FŒ/š¾},%ô“A(·Çˆþƒ¶ Ä5euüÀ癫sê™QÈX¥wa„4 U»ÞÉãšÿFs´J°àü ©d<¡ +jÐúm9 Ÿ\m3­šÛó3íôØ%¿+ýúŒösÞl0ã)æ¸z„ðp++©ÜÔ(ý(ò#LÞaNåٕ؃ÞLOéûê2Sßí¨(‘wg4ühÔ‰žµiNÍOnöi¢å5ÞÆŒæòÆ)Ýf šN/d`tÇ¢îm|2Sê ãEåð/þf¤Væ D’“¹{|Ó+¼‡æ>§ËUáجZÒ(—TžÀQ?ÞLû6ÙúÍšÔšT~1iéšç&Ф½®ë8¾Ò}Ó¤¯‚GJAÖÀdb-‰'Ëë†tÃ,0’j)Iˆʼ„³ µb¼JgŸœ·ÐDÁ— ׈mæ +èe•m +W÷*ʾ…îmw¯ºÚw£~0罧ٕÒwœÉUV1ðñCXZY¸„Æ–ÎJØúì¯äï½Úƒ·7o¿L‰½ìq¤»æׂ‚J³Ø¼è´ÚÏ‹(#¢! ¨Œfá[J>€Gú£ÁwþiAé$(|ÎVY„uhØj2~,óz¶ÿlå=6'/ ļ¬(Pú2”÷“ (”oô¬ºw[÷«Aù(éy©„ +¸i%Q€eü%ötE%yÍž Ú,ªz/|J1Iëzö‡(Mç4¾î„¿­Òph3¼2ôj‚qu…»óç9©Êb8V;Ûò#*Tcß©M2l|WÝÕÔ²‹)¬ +©C¤é½#Ê#_Oa–Nbæ¡rW}:tùﳫ÷'þµßŽ #˜öÉÁ¶‡ésKøMᢥ‡5óÅF}ÛŸá!Ã"zéQ¢´üƒ´mr KÏF,ŠxÊäåÞcxªpªðVR7›Dý¹}cÉdºsT´sö¯¥¢€™xÑmgU46Lk3¤¡2QLŜ̚—1ÉH¶k>ôᦣ~Ü´êÇu«~PÔ¨=õCîŠx=pÆŠU‘æ×?,#‘mz yüdÜäKWm0)¶\SîÕ7P ®jÞøù¡ +‡òuÛΤÓ{FÕ3t,Yâ‹ýèB !Ïù)€ "¤ Öªfæ©×;K žøH‹‡ô±&šfn6ë2ŒfÆçWד¾-¿Ÿ^ãO|$%¥Œ lYæ ²Té7•SìZ¨&ïŽCÌuî3Ȧö>æ++BT „XYÞº +j{$jçÅàÃo97erlª*£¨bbÀì\„δ’>ÐGŠ’¡“A£?MWÛ²¡éî\Ca˜Ÿ†ÊÝÑ™¸ÕG¨ž§yºVT;¶ª¼`LüŒ5$i>ÍÝ„÷iV•?„Ê°myo.áí æm‚YU*äXÒ[}ÌÒ’ +Ñúš¼6+Z| ¢$’ w;`]³>éþìÂEDeOT'®'L¢Žò¾¶óKªµAÕ¡ºUõYÿE%ùØN¾ ¢rÔm‹ &«é mÀò–wß´°GH£à5ප˷!]i·oOçÇEïVˆfœhk& ÌpŠØËÈÐu÷nßuˆ°älót»- +Þ$diö2ªs8E7YUuÞø_½ì°‘ϪÒ•ØZÌ&-Ыj©Û×A$)'§ó‘áÅ:$–pýVÔÖÐdi^í¾@þ÷:˜ôhÍ*}µi2 &Xn(I€Ú€ù&XŒéª ÒŸ×òiÌðàØ]žG9¨vCdûú|„'[mODÐö‰U||ŽR.Ìõ9¯|þØkQéà£Ý½AG"* %m¿m(iÛ@„mãqã% ¨coçÀ•/{g‡I½€cI=c± Ç î>-ò¬E€ð^f‘­ÍƇÄZ$~ æý(k«›Ý¨/ü"§µ¸ýñôÎK +§; ãëpÌí~ð9ô Rìc¹}ò Òÿ¯×v!Z²Hà +8³’~óñô‡§|4ñÿÕŸ¹î~YÀeq¾íeã¹a±L,K‹Î6OE«˜éXîØ:‹ÿ®æ¹÷endstream +endobj +1219 0 obj << +/Type /Page +/Contents 1220 0 R +/Resources 1218 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1199 0 R +>> endobj +1221 0 obj << +/D [1219 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1218 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1224 0 obj << +/Length 1962 +/Filter /FlateDecode +>> +stream +xÚÍ]sÛ6òÝ¿BôL…üÀõ)Mœœ;W·g»OnÆC‹°Å)?T’²›»Þ¿],@‘•(i:ž1‹Å.°_Ø…ø"„?¾ˆbk¡‰V, +y´XUgáâ æÞŸqG³ôDË1Õw·g¯ÞÉd¡™ŽE¼¸}ñJY˜¦|q›ß1ì8„Á›¯Þ]¾ÿùúõy¢‚Û˯Η" +ƒw—ÿº èýõë~x}}¾äiă7ÿ|ýÓíÅ5MÅŽÇw—Wo £és„éõÅ»‹ë‹«7çn¿?»¸Î2>/%ä·³»á"‡c2©Óhñƒq­Å¢:S‘d‘’Òcʳ›³ G³véœþ„ä,‰äb)KAü˜è8I™J¥mGšÅRÈAÛ‚/8g:ŠÄDÝB±˜GÑ nÎA…aåKk:RÈMŸõ¦2uïTÝfU•µ¨`+GF aŠiÅ•åw».ÿí׆€'ÇÚÇÝ,1å#¦œÃ™"wdJû:”-&ÓÄuÓõž5H&ž}U&g«¦~œ‘ &âØ“þ†¢4ÿ˜á¸)g<£ñ„i)’ÑΗ1(÷¿¸h!$ÓèGËÁ0@uGeÑõ¦^6µ_`?Åæ>Ëó–w›¦í<>Ðè[7ÿkc8ôÿ¾õCÜp8»Õç¼ì {Ôàü*>^Õ™¬]­'§Ë›*+jË`î Ǧ¿fÏuÞôÎõ¶z0ídÍrÖ2À×{ç(’€¿Š™N¸ÞÅøl ½5è=uÑóͬΠø¹ËžÌ)Á5,š¥‰âŸ‹È±à–‡Á"À÷qoOÛöœ§î±6r õKlŸMë¦úfeç¡•ã—9}ÊâiÝ¿üO'¦)³1$eÌÜBB¤Eá1ûùXiÁ”–‹( +Y ›i®}Zp=JŽž|9¦§Ü8VÎWÔÑY-É5”ŒX†|êdG®U1±¿ÏX¦‹H¢Þ“Ù4ïi–#¢Ã½ísBÑ ´I[hŽ>AÚ¤­TÙG,BÕ¶ì‹M9ë8aÊ%Ôç<'f©ˆÕ¾çt$gç:EýD"'æFš©¹Cæîˆþ¥èׄ΋G$}tG÷´úç1$z'Ó¤²±DÍÆ´}a:6D¾M¿é'F€‘!tÝ©‡¤{xr%Y"g"FFA·1«nƒEÆÖÕì7bl"¶çïˆ6²¾mcé0!wdOœë×™cÐÛ«qE Òë•Ùcì%Žƒ æIšsÝŽ ôÔq‡¸ã<È3S¡#Ü­›m™œ­Vfƒ yèþ¶5g›¢&¸|$DÝЗ®„ +GºSTþ †z<¢Ñ‚“O¼íà"žrvZ@N# €™›¦©Š¾·¢0¯NwŽ˜—¢, zpe Ô¸LìS3‡ÚÜ„qlj6m IÁ¿À× 9+;²·æL€)Üÿ\“ÊࡨóŽ@RB;‡À‘­¥à›Ñ§,Îy0ò ÄM#1Þð–q3a@—;Éñ’¨·W7à•Ðùô¨ XãûÑ™­ êN¦^Â:4º¶°NnpûÚ4ugˆ Û/iðàÈ Ét}{žÛYÊ…çêˆ:{K!TeumωqÙ.£OÝ´Uæ¸Óa Ò~ôKûÕÚf2áCp¦¢°ÒÂÞU!w¾ª_US_•Gï¼SJWãtn3HÓDCÚGȯ¨°±£©b°sƒÈ!ýQ<ª=ΠX·q·ƒ¬¦ÓR.mÁ3‡îÛâéÉIË÷B ùtp¥÷¦ð0 + çJ©™(P)5ÊÆrñœ•Þz®ÒÇÚàÇ’ÿ9ÑõLµ½Ôp3¼2ýêUkƒëX¡#+î€×ÈP—=íÝÝcÏEnÜ)3úÐ]‚PóH‘&c`”ˆ½|NE²OpëKl›Ù¼gØÁfcêܧ9«·!A–Y_<;:ØÓ +Ããð†ýŒÉ÷µ&ÕݳݛN5Ÿkߔ룩ÁO>ap¨ø$Éâˆä#öN£ïWYjZkñSW^¬@hçÎD2$Í—U%vó¶<Ûº¨¶0S±ëaN¨$u8ˆAÛ!&£áÔÎDŠNC³®¾W>E#4ÃêŽ Ìùu™b~§ÊP6¶lš_·B?˜ÇÆyãLfÁÀÄI︛¬w)}­yÔ¡Ù‘ jö +Ç]‡&]‡VePñµ'¼sL<9‚è8¶&¶ÚÓ£½¶kw±ò#È1¸§ GÌ_Ò»ßýj>À‡9Ÿ6ÑÐ&ïäYu‚šNleùñVÖsŸIÆPëïJ&T·~Y6/¢3Ž>«¦ªüN:ÓOŸ˜&ñ‰ÏW&ëŠò#ÁxϺY‡š'âÜoöNÛ•™Oœÿij—#÷µ¼ôGr>™î”9e7TåßñíÍïlÆP!ÿúç7¥ÿÚ÷7²H'ñô~{Ú6¥…€sƒ{(=¡"<á}kÝtý.øÑ'׋éûvÅË"ï‹ütyÑšUß´.7`"=õqòÈòË–O_×ЈËß±u?¾vîebŸÃgHÂ!ˆþô«ûî' …oÆé‘w ÷–.ý¦ð|êàm'â!ƒî@Ìlýÿ÷Ür»endstream +endobj +1223 0 obj << +/Type /Page +/Contents 1224 0 R +/Resources 1222 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1199 0 R +/Annots [ 1228 0 R 1229 0 R ] +>> endobj +1228 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [491.4967 546.2465 511.2325 558.3062] +/Subtype /Link +/A << /S /GoTo /D (lwresd) >> +>> endobj +1229 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 534.2914 89.457 546.351] +/Subtype /Link +/A << /S /GoTo /D (lwresd) >> +>> endobj +1225 0 obj << +/D [1223 0 R /XYZ 56.6929 794.5015 null] +>> endobj +326 0 obj << +/D [1223 0 R /XYZ 56.6929 744.5408 null] +>> endobj +1226 0 obj << +/D [1223 0 R /XYZ 56.6929 717.3918 null] +>> endobj +330 0 obj << +/D [1223 0 R /XYZ 56.6929 594.9189 null] +>> endobj +1227 0 obj << +/D [1223 0 R /XYZ 56.6929 564.805 null] +>> endobj +334 0 obj << +/D [1223 0 R /XYZ 56.6929 340.8686 null] +>> endobj +1230 0 obj << +/D [1223 0 R /XYZ 56.6929 316.529 null] +>> endobj +338 0 obj << +/D [1223 0 R /XYZ 56.6929 259.8095 null] +>> endobj +1231 0 obj << +/D [1223 0 R /XYZ 56.6929 229.6957 null] +>> endobj +342 0 obj << +/D [1223 0 R /XYZ 56.6929 197.042 null] +>> endobj +1232 0 obj << +/D [1223 0 R /XYZ 56.6929 169.8331 null] +>> endobj +1222 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1235 0 obj << +/Length 1102 +/Filter /FlateDecode +>> +stream +xÚ½XKs£8¾ûWpŒbyjN™¬“ÍÔNf×ë9eS.„QYHŒ${ÿ}…» Ù§»— çÈ#§+¹-Õ/ÀÛ˜ƒG(ÐéöïUcÎRá8FÑ°Ú¦-Ïê¦\³Û ŸÒ°ûT* +¢ð‘ ÈÑRý A9h×JÂØ +¡æù\¿> endobj +1236 0 obj << +/D [1234 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1233 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1240 0 obj << +/Length 1162 +/Filter /FlateDecode +>> +stream +xÚ½X]sâ6}çWø:#U–mMž²)I³ÓͶ,ûDƱEâÆX¬-ÈÒîþ÷ +l° Ø&Éð€-ù{t¯t%l ýó Å 7lnB†03¼Yºï¦ƒ³oÀö#Püêðóë5µ ¹E,c8-`996†þ¨kA{u¯>ß]ßÞ|\öl³;¼ý|ׄ¡îõíýôéfpùéÓå °Ãp÷ê÷Ë?‡ýAÚeenï~K[xú÷è Ýôï®ú½ñðc§?ÜùRô#ºvä[g4F†¯ÝþØAr‡ÏúAÌ91f“QÈLJ·-açKç¯`¡wcZ©FP‹Thâ‚€‚ÒP6ãТ„nõ€…P× Cù –HV‘zI¤íÿeݾ‹$™Ì\å=N QiûÏ‹ô¼B³CÎ)B߇®÷ô(Cñjˆ‹D€¥ þÌe¬ÊT×-§ñpÉù¥ üsZ¯‡—1´^Ïçõ×"2J_G9PúÌ'ùËøÕ¦n7¬væ}Gþ¶ñ +$r{Y$þÚ +ææd=Júöcƒ‡m)±™†…¶IÍ ê/iW6N¡CcáMÀ– ©MÌJýs‹ƒ<ÏÆÆ:ÿmÆéØ쥱Y>vQ· #œVÇV*j-%¨ MÇ4›³Ii˜š”[•4Ú Rg2Š‚ä G©á—Bg·ÕÑcjÆmH,Dh–2r¤úíÅz×è±NEOƒ©;=Eï#HÝè9Ø 6´&£o¦í+‘Ld<‰dÝÅkg_Ü¢Åì^Ä5ü=ˆ R"^ºái”‘™û¨Ø’©ˆ +fB !ª¡3%ŒÀÏ¥±¨E£„¡¼9ðÂ@DgC猖_øzUñžDsR6÷q,EýáKözðÀ Ó°±«DCúû@$-TËê °MÍ·“6•±.ö³^FèžÅníɦ;Zeíùb…k¸º.Ù„&m¨&mbkg;×¾FMl§Ò~ÅS£Â).‹ rÛ¶ªWÅÑAÑ6®\íd{JÙ¼z« h$kmÃ+r5Ûrå`ƪ4‡\OJK†ØFÖIKlˆM‡¼¸G¾(o“2’*˜®€/Bwµ]ª<ùI¥êÄÉj¥M^àW +ÆÎK›Bjr~ÌϺI“gà[ä7Ç8Ä>FTIÍÕÝ›ÏÚs↉)Ré<¨Y实b;ja!,€?kÁ÷i Bù’à_Ñ¢0ùGÏk¤7ØÜ|ý4Iæ«!—'uyqhyLîßUî9öÓ ÜµŒË¥…r½§sF÷BáFAôжÄ}n¬î…«”<ؘM]O´e %Pº> +¼¤-‚’s©ÃoUïöd|ql>tRäß6…*W­q"±¿­Í2´MËá$Žöî§fž¡GnŸ\}ÚP*lqÚˆ<×{¬i|Î'm«î)ƒë‹ßŠ_´;¬ž}¿œ_¾›z/s²»:&´puLlGÝ5HFjíŸi0ß^DRÿv2°endstream +endobj +1239 0 obj << +/Type /Page +/Contents 1240 0 R +/Resources 1238 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1237 0 R +>> endobj +1241 0 obj << +/D [1239 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1238 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1244 0 obj << +/Length 1750 +/Filter /FlateDecode +>> +stream +xÚ­XÝs›F×_¡·Ê3ÞÇÇôÉMíÔÆiuúfÜœ$&(v”6ÿ{wÙƒŒSYi<–»½ýüíÞ">gðÇç¡°™yó òlÁ¸˜Ç»›o`ïÕŒ«c²†\ß/gß^ºÁ<²#ßñçËõ@Vh³0äóeònñòÇó_–7g–#Ø·Ï,á³Å÷W×?ÐJD—o®/¯^ývs~x‹åÕ›kZ¾¹¸¼¸¹¸~yqfñPp8ï O¸¼úù‚¨W7ç¯_Ÿßœ½_þ4»Xö¾ ýåÌEGþš½{Ïæ ¸ýÓŒÙnŠù=¼0›G‘3ßÍ<áÚÂsÝn%›½ýÚ ì¶G§â'ÜСLÐãƒrÚ‘ó@D¶ï:nÁwg–ÏØ¢N7ÖÌÒ$Õ{+͵ªà¶òf·RÑßÑã=:Ú-ÎíHçPüÏÓ|cåE¢ê¯–‚O©›êxQü)Qz_ª“ìÙ¥¹U…™pŦVVúqmíU}[T·yq´ñeUܥɤŒ#´Wê¯FÕúÄÓºRR[qeÉÚªK«Shƒ§ÖÀ­¥Ó݉ÿ!­%ºÚ?KlÇsEŒ¬(‹J•–·ørÄ™@i¦E.3k];K6z{j>eÅ2Þ>'¹cŒÉ<‰ºK;„”RoosÙEçÈä¶V@¥~R]Ý~R·u©âg¤FÇ[k'ËR%8 X©»¦ñà—€3UU d“5Æš?˜`DÓãóÿF ×o®/ú#üm*Ék«IÊë_j/ÀxüÑqÞ ›AÖ2µ‘ˆ«È³=ítv}Œ³&1bÿ6Ò!©YZô~î´›fèFÕ>+6§7Ik¹Ê”%³MQ¥z»3ÉÊ4YÚ³|7rêpÙØþù˜ +$€ªM8µZŒ8S²½¦®Ú#ó.O*˜‘5q–ª\×V©*«ÍÍÉùdInÕŽu +)^”óCíiõQÿSÉ{,ª£-S»Æ™"Üñ¬®DÇã"×2ÖÇçÏ*rU%l:à?H¤u¤ž×i?©ª€¹Ìª iiZ‰bŽ½B,ǵ#œŒG¦AõÁæ·—Ÿ÷ËkT Ó¯ãù¢eÂéœû0ª3V”سjÆßj©ÕàG¯?¨?sòö†£¸¡ˆø­–et¹ƒÑT9í ´ª–[Õ4˜Ÿa|Ž"˜‘§³à±0ׇéÚ†¯纋Zá‰TSÒs“+¬¤Ü‚]àÓ[¬”9P«„¨Õžžø¡c¹Ü¦æØÂ4Ìx+ÊÊèi{=Q±¢Ìfóqf°©º¾¿øP +ÛMSIŠ.îáJ¦À_D‹«5-ê-TŠ¢q¸  ˜¬ÚañÿŽl$ #ûdG²Lºú ¢ÂUVĈ¼OqbB`¥5â%RCÛx\Hum@Ë|;Q8®„D­e“ÐݧYFT›.ÑNþ‰ýè‘ÙLÀ·+"ðœpúƒØ0YC®ö{n¶îc³çjJ+ëúïfp¿¬ºçšÐ=Ìw™¾?VŽuc¹ŽXÜÕ¸ÝèLj‘-”/вvµXÓSwgL—†nüÜŸç†5‡éD®ê"k´áÅ»&Ùñ¥CYq +‹„S“Q±cþì”C×£’s=(AùAå´$kz’/ȽS´Òºeȶ +‘zp=朷^EÜÄ9:ø "@ig)lÁÝGÄ®¨5Q݆ÌE£ËƬ“Su÷"˜²76•Îèãÿ ‹cð»jò‰*ƒ¦D¡kªŒî[ÒÒ6˜ s©I'ÝÐi»2È)¾‘°¼ÐDàÜ’¢7*zvBFÙÄ­M“²` +2г¦…¶sïŸp}׆û¨k"öTÚA×ç¿yAˆñàærñ#Èâ<~h–ë9‹u»Rìˆá~›¶MHsÈ$ö `ÛZ¥±uX"\&ðaÈŒ¼mÑd m®Ì¹¶+Â^_@£–ÓÓ­Šq›‡¾øV5àúB«ê¸Pëµ·žnWdÁaÞ—Õ÷\úGíJ@»b<ðû¶-n|0t¼I-‹E‹d’Æ´Ù”‰lÐm׆ZÅM¿qšÃêÔ(½œ=J,Ý®EÓ³–Í*ëôá´Bc˜¢ð WUzGæ8†ˆ‡6à„0€•á\MŽ…åzÑ"]_ز6&áÄ€¬zÛbÆéÌœó |øD¯ó‚î>ˆ8&8‚2Þž»¦ÖãûTvÃ\àÛ4t Ü\aão§Èaý ùÕ?Ñ>ü~í¶†Î4]œ!œ(èŒB¯=qhyÿ[îcÓÿÖ½ endstream +endobj +1243 0 obj << +/Type /Page +/Contents 1244 0 R +/Resources 1242 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1237 0 R +>> endobj +1245 0 obj << +/D [1243 0 R /XYZ 85.0394 794.5015 null] +>> endobj +346 0 obj << +/D [1243 0 R /XYZ 85.0394 285.8176 null] +>> endobj +1246 0 obj << +/D [1243 0 R /XYZ 85.0394 252.9894 null] +>> endobj +1242 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1249 0 obj << +/Length 3961 +/Filter /FlateDecode +>> +stream +xÚ½[_“Û8ŽïOÑo箋٤(ŠdíÓlÒ“ÍþÉÌ%ÞººÚÝÙVw«bKŽ%%éûô$Mɲ{î¦ê*•˜¢ ’·þˆ[U°ÂföVÛœ).ÔífÃoŸàÝûái–h™Rýqusÿ³Ô·–Ù"+nWÉX†qcÄíjûEÁ2v#ðÅÛ_>þüáýß?ýt§óÅêÃ/⋟?üõZï?ýô·¿ýôén)Œ‹·úé×ÕÃ'zUø1þøáã;ê±ôsaÐO??|zøøöáî_«?ß<¬â\Òù +.q"_oþñ/~»…iÿù†3iºýœ k³ÛýM®$S¹”¡gwóùæ?â€É[÷éœþre˜Êòâv)sf€ÿ¼–ÓB‘V–2“QË™˜Ór B-7å¾Ú.u]y¨—›#̺éërwæ +Tlsu]ŽH5#Hº¢È˜ÔÊŒ%Y¡5 +‹êØ G§a|Ú¸5Š‚¹¾ïuÿì[ÏõÆ7ûÓ÷NÔ~n‡Ý–Úå$0ÊÍÈõÀÜ;j“¯CÕõàKnÑ gZ2,áô×]Xb–Á7ï?^®>xOÝÞ úvÓîÀ´3ko‡# Þô;ÿqÛPË,þR×}ÓÑ;E?‰¬)¸ö$å·²Þ•ë— l¶#™ìTe8>¶=2[P üäv*¼8ëfSPáHàÕŒoˆ ô5cç¦lü€›¯CM쉪¦q‡§é÷Ûê±Èi`^@ñ{z«Bÿä<ÛUoè¡iûrŠsN§†=™Ü}Õoî¿׊ÁH}¹žTÅŠ\@…•*2½ø8,¥*@N‡ÌÐJt¡»} „ˆ›J-á{êúg–å^N“Ú½1,×¹ôl·Mw?3›L2+x´Ì¶í¾p?Ÿ‰ÖLsл٘ÅêÎf‹–$ƒA6-bZbˆM:Øð›pÍ +”ØêÐâ¢,gÏÂôöCç·Üu-µÖñú‹Pƒ1£§®B]Juê"ÕŒð#|qðüæ‘j†ûß„eÚ¨ ûÙ‰Yx\»<î`ÃÖEp僯 +±C„‰Žšdqô¹£Žî¹ô®NÏ„gØzªš +Ãå–¾p€y¾¸2 ¶¼ð+¶úËÃÍ,k¦™ÈÌÉWpüÿtò3–…†¨Æž¸ÙÕ€Aˆ°EŠ°s}9‘H –+n_È2® 퉪›ç²yr8ÁÁ==¿}ùBöHìbGÓz’˜ ák> +À¥®ŽZuô.P#Í#Uœˆ«„ öbñᑺ)TÌþ éGpÉ­ž(ȃaà-\dü¯ÒEÆg‚Gh|¯wžqyw`Eþa]Í€ŠÐS… «¦àÜk¡ÆáñÒ¬~Fç¬Àš€ÿ>ðÍØ߆BJ&è+¹]ü>~¯»Ê+Lêœi›ec¨ò)kP&¯Î+dqz5ò + p +ä0lÍëðKò,xÃk»'¥ ßÝA£ÈŽ¯ë.¡º¢»@å`|Ø.¨NpÁ”È_a©f¸•W°w´FìW!JwöŠóTÉKè’‰RÈ°!¬ip*Ýä»m uuÙù'Ú0„üŠŠhÕM×ïÌbØP ’m[Ï"|4_š@*ËŒ-&y˱Ùn¼g‚TÛõ|ö’©"K’Ë$>F£pI¯ÄíÔgGûu7—("¬«Ó Çé*CJ ôBÜæÒ2H¼íïN?âˆËtHg#餀arkOœƒA²Y…å‚™\Š¨°K®ì…Î_ÙL©®¸J rûÕ¾ëËr¿zÓ]òˆÈâ«RDª1F>S–ÞŽäð!‹'>ƒO®3Á> >“tŠ$ÌA9Ö½ /ІÉaäpí¡+Ÿüw§ ûqZϬ¡_H…{0ÝœSI‰]hº.¨a(U6vŒßgÏ\‚¯ÙÔœ™_•¹RÇ@šd»`0²(pGà•¸”R]6˜Håvíëí31–ÿÈë¬Ñ ëQïΠŠ1ëÕü‰ áª>¨œp59e9ªŽ6âmzŽãw7Uç;>¼ Ç:Xê̾p8æÆ­»,ø‰]\wÊt¾îhþÒØàú÷d_y†–œV@}pš{gô/ƒ…˜«„¥†‚&OËûB{ï‚*6Y=÷ì¢;üúÜZ.w.lz:ãiú粧Ö÷²ñ-ç:–¢ÿ¾«Ÿšr×%¯5?eÈQ¼QNè‚UÓ¸¬Bj¶t6:œYÚ,>Ó®’ÎdÌJ2X…xÀ”LÖ Û6³7|$òXÖæÅ}Bë ‚ ÄYt”ôø«³hœeXêÀÒ÷$bøh­Ã •OÃÒr´èh¥}媜̧ޮñB»]®`÷5TME ¿/e}š¿”DïÛoX>BøR‹mïß¹59fT9˵ (sAq™Jwœ)Y§üä’ydí|ƒg>üŸ(H'~— pŽ¤Ã×ê|»Ž¦òئõuHPcvQ5›]Köœ”Ûvˆö×Ð]ÄÎÌ&5ϯcgJu;#•³s<[úñR šqà~U‚H5#ÂxÓ”g´Ë@P TháÉZ…±¸#NíJ…€¦’ƒ'’ÓÑû¯C#ë*¾p¨­dWD-6“ƒ9èòÅiˆº\NK¸Èiÿn„“D×Þ6,·O5ýï…DWp(Ÿó"8ÿ)ÃK5¿?¨ôhõÿ%Ée×d‚¸ZÒ¼–àýËÅ+%WJuÅ´•K^M"qG}]„H5#Ãx·È@½ÅÅXJxž&ðä ›{ÅŽˆÆÐŽ1AÊòp€€ÖùIºè¾hé×\@>-¸¢­ÿuW~Ûhn«œ:Ÿá=Ê‚„˜Kóœ)³G ’Š²Vüˆüzœ¨8à¯èÕ)Q)ä[Ì ñ8C½$OIÖ!p¸ƒ¶"(L6Zð]‚^¢¹mœÖ*Þè( >H;Ö—Þ§ÚljǠì0¶U·9Öë$PLL6Ë$(ÂP†Hj¹+hèåñé–ŸãôËôƒsã=åÿ\mümw—,gPˆžIdÔײItæD‘ê59ÎF»Š +H + +u;RªËØ©\žÖÒ¡WÊTÆâÕ¥«LÑ Ó6r–[ÀëSfñ÷w¿Þ¯ÞþJNhA’?ìסˆà&ÁƒaG¤nk »¼ÝVõ7Je¹¿BŸ6ÛØûîãgú4½²ây˸_¼Á|ÍäÑðøa1) ’X¢ã *ȃ±òÈâ>žŽ·ÞN÷¦ô;v/ñâ”?Ç7~·/Ù9ÇSqÚùûÝ +Ï âQ‡oIŸøÎ9Q'¤Ms|?†`ܧ°i0 ;¶§C’è7í~?4þZQŒôcïÚµëÒ ª¿láÂê•› ÑûöD§£Ìå¶úVoÎÃb–3]hq•w$:g>Nø,Ó`/#]íàŒmãŸÛGúÜ%#<ø;_¨Yü]{Bª ]ÏËüe/*Ï2èx˜Vû+^‡c½/õÎwÓ?jûs}·4ŸÞú|Ï@^f&ßðÄÌØ» +(¼%9FG¿î”ĵÀ‘š®t˜ÚÑ)¨÷E@~<ÀC |[g;ئL»"¶òÄÿ ÅO‡Ž¨l¸DŠ”?° ‡ø˹«^.æ"•AP`Èu–m,wð!BZ=‚žãqŠ{ò·Àð#—\@á ÙàSº>j*¿…Eìk/Hø-ƒþ¢—”> endobj +1251 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [222.5592 220.8351 286.2499 230.2447] +/Subtype /Link +/A << /S /GoTo /D (statsfile) >> +>> endobj +1250 0 obj << +/D [1248 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1247 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F39 885 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1255 0 obj << +/Length 3390 +/Filter /FlateDecode +>> +stream +xÚ¥]s£Fòݿ•—ÈU a`€¡ò䬽9'YûÎÖ^.•äK#‹ZŠ@v|W÷߯¿„äMÝn•fšéžþî©óþ«sûA”éó4Ó~¨ø|¶: Ο`íû3%0žòúPßMϾù¥ç™Ÿ%ar>]ôö2~`Œ:ŸÎ¼ÿÛåߧ×÷^“Ä¿ðâ$˜|ws{Å3?ÞßÝ~¸ùþÓýåEª'Ó›»[ž¾¿þp}}ûþúÂS&Vð}(;ùàÃÍO×<úþþòãÇËû‹ß§?œ]O»³ôÏ«‚òÇÙ¯¿çs8öge&>—ÀWYž¯Îtù±Ž"7Sž=œý£Û°·JŸŽñOÇÆCœ{‘öM{Œr9ðƒ¸æ¥qæ'Qu\Õ—ry½± »Ùع÷Tníþ¡UøY ÌyçüÔQǾ1‘Rp³¾›pÒ¬í¬ø-B;3™š´K‹KѤ,šÖά}][ýÄÁ%Ôžº„0­xö¥(Kž”ìªh»í¾Sf"‹5à“}ˆ4YT‚ÖÑ’Ïç…‡|BéøY”"”ŸÅqHÇi‹ºÊKV¥ÆÎð•_ê?s~ü±µ›W2ͺ® Z©`2%t°6·‹|[¶üR4ü¬j™hk~®y‹Ñ8*ÙZ¸#äÖíÝí5²Ç?PnÑ T%¾6ÙZ¶:¡d„,ÙÔuëÍmiŸrd‡WWå릥 éijN’ÐÒ0Ð3–gj@Äô" &Û #2 z*½šT¢3»²UËó(,„Û§š& ÙdúÓUÃàÈܶ^ótiŸm)Ÿ×«¼¨VIœÈ«9A/¬Iiä'*ÚÓ¤ו¿íÒIV´iÝW4ûç¬ÜÎEÒh-$a`š§2?ŒBfÁmÝ +HS¯dÄg ;[èkØŽ‚—¸àÊúO¢°¿…¡¾ºÆ¿ïd†?]dáäŸ{“Ÿð¯;Í|·ðñÓÃõ§8êtô›º¯\pžHùÊ:³¨O‚`ò:°N}é£êGulãèñÕÜ~õ­ Ëçn¸mºájÛØíʽþ÷[qc¨yqÌÒb“ ‹N›Z긭uPˆr^4ùci½¼|ª7 6«æÐÔߥ'Ip@#$ L-ý|ú†+¦D›hñœIÔwð¼ruûðpýž{äÒZÞÊ“4mY¿¼µc•¯ÈƒBÄÿ^Ó9ê⎺²Y—–UlÀSðJgȆãÌÜã1~ ø“¦Í[r$cf•—p;›¹ël©uî~U7bxÝÙfΔbìn³õº,p³c*¦#?Sɶ:¡`D,©k^Yן󦘦 I['ÑIôÐ!þv%Fi2 àç¥E_”¯í»jpúqÔ‰p„Þ}~‚Yg ¹æg€mè›™<çe1Ï[Ê6àU¼2Œr¡(/[»©rr³I6YÙvYÏe“ºÛC´SôÍÆ©%§½ˆ>‚íãÇë_pœHŽ0ãH5oŸD (8Å/„à†P: ˆÙ×[ëc)ö6Æ“â¼_ï+Žl< ;=C{D%×Îlu1Å®mÓŽˆ.Iü@œ¿Xt*ÉäŒ2:ŸÑÇXÕ›ÅJ˜ä]y,åèp˼á…Ò.Zž’=ô䳕sl«vsa&[ÌI#±Lµöƒ²ùaN(ð^^Í–ÌÓT š¹+¬]¯-å$ÉhF3èãÞç rÅñ–ç† +s %òÖÊêvÝG€y P!ÊTˆVÌ@ÝrfÍfÚ•RÒ?Eé>Nw:ûÕI·osDmSJEšbU”ù†r4ܾÞ3—\VÜ÷Çù4¯-çl#ÚܹjG•›÷à‹†9:(ùÊ·iºóÜ;ý9ê¼uN0Ž“Þ»uÜ}wP=£Z¡:>ZÆÛÍ¡‡hžé0=MF5BÇÀg°îÑñ€Nc&¦“ea7(g0lxòeYÌ–ŠÕ|ŽÊb²ç9Ù>qÄ9*ŽòÙÌ®[WÍ‹Ý4ü‚V‰O؉@“]ªÓ»ãû\M’ÆX…²ª#^pŒxq¬8vŽÇ=ÇJü AtDCÁ Úu¦97*ª'|‹& r“0 åSO踀pdç0ùè‰]”b¥ZqpƒT»cV/sÛl«¹ò‘8µï6d̺ºCÆØúêXçÉ:•o’Xÿ¥”%ÒX>óè熳¶x¶þ*Èì¤ì¬6J}¤, +laî â  ªù®®KëjÍ;)´Ž¸ªHC© Þ¨dz@Ç•"ÝضK¯úSÄtЗÒ~šÀùOá»R™Ÿj¨)ûØGà¢ø¯™z*±–(0.MØÏW! Ô©K?//Çö5~œ(òèq—®•ÝdL‘Õ’ÝþëêîãåÍm?Üq¯©í³K ]¤—¨‰)öæÙn:l’ã(?LM:´eö¿&CÕÛ‚-¿ÊˆK§ I%©¤Cú[°¾ëo#ö¸®À§&N¾ÜK}ë¸M±¸gÎÙ2¯ž,£\p¶¿âi/ÃÈ¡‰t'³Ék½•=v-à b89,ÜèÛyÌŸ ôN{Ñ£.ç]Þàš0‹öE¶“þcÁ:0—Ê°²ûIÄ.ÓØ5G¸† wÓU¥§ÔÕÌÑ\òY?UúJ²uÜÄ;(rtþ b¯WWžý³h«I(ÝÃ8;MC5BÄð¼ÔÔ‡TL—.g㎒ÔÛT +Ä +dì$PÈÒîÂ0jwÍC[IçVgK;ûÌ +oÑH¶vUsëWA‘vÈ+×Ë+Zj(FÄ ¾ƒÁ?ôúÀÈ4M‡üŒ—Bà­Ŭ°=,”jG½;±sÆL1Hþ9 ÛS°øø:âþÃÀø)yàÉv# PigºÔ-dB\jA¡:uDíœ,&TcNÖ‹¢ÈÃ0jظ³Õ¾Ö±Ë·UiQ ¯½UÿFÃU_+£![zš¿Ó¿zµêôµ,*;´?W dÞØ¡7=„Â{ø‚÷QíWYæëмQ™õ¡ŽkÅÍƼ„|_íÝ™Ÿuo5‚x(3P61«lpôåñc˜ +ºâ yA—EÐ$ëFNýÑ€Z¢¼à®;p®á)LGðÝ•8ýèàí +9W÷±Àn >XH•„ÙøÆmÍÓÈkŒ9sKŠF>6JüX§{ Bñ¢8FMüŒ)“ +â,vCh@µCœLãöiÙò‚ûaø"Ý]üR¤§¢³§ú`vy }A! +GÂJpS`ä ‰^¸DÍ+Ül^ÐöxˆÌªÚ±n˜ +"RT9‰½20EÅ<™»4C÷‰NÍ'篫àØH‡FIÛmø&ñ-ÄF剦v°Ôk„Q!OR,©&{R©Øò±žL)&™8A4¨>ßñkMqd]‚vPz; ;³_Ú|Ó>‚zzn§1çù&ÖÎ6ÄS…“e½¶‹-§¾ð:ßn$ø»ëc"H38'…yÈ1…vÀ¥ˆ1øÒl×r« Š˼3™wºw‘±»ÌsWÌ#íúž0¡ä²' îGõò­è‘&Bùx+ûf‚®ú¾"4^EtíÙ»¥œŽI‘àUn°ç*÷ðD¡ot抴.ÿÉŒdÔèJb1LQ± Ͻ8m8Ј!%6P7w•àsa_F( c_&îéÈè¡LÔåè$ ‘ ‘O‚ôàzéËÉÑê‚"/AÒò³~f_ 7!„)àïrúa#7}z*ëÇÎú¤C&­S~<¢Ä å!ÒWÊ* +‡Ò§ö°‘„ +âC`D~ÎÄÔÀ…Ç*oZ*Mø¡Uæªíþ]k\‹gù.>WÝv¾½›Þ|ø…Çl‚lm#0äÖí³CSæÏb©{þ [bFÜcôtž;CÿµÅò0JЋ§'¢69à@¸P,-Фq\mW”rvÞŽ|eÿk¢Œ‡HÊ=}ÂÙA‚×_:z +f‹ü¼Æ]fvåM§2‚¬_²÷¹Õ«³ÜÎ꺒©—VUÿ×3.yt­¡êjbçYäM¿@Þ€½,Ò |¥ÒoA8Ǭ†Í5 ³˜º,];šÚ«LùQÚ¥UÝ"F¬$ðU’¼é+¢8uU:1ïè~ *ÖÇ3Y×n‹}üýÙH>t•ÿûgn»ßêÔŒ ÇÓ(H „ÏRG®Ó}ÊãÈø± ÓÒÿ‚+Iendstream +endobj +1254 0 obj << +/Type /Page +/Contents 1255 0 R +/Resources 1253 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1237 0 R +>> endobj +1256 0 obj << +/D [1254 0 R /XYZ 85.0394 794.5015 null] +>> endobj +350 0 obj << +/D [1254 0 R /XYZ 85.0394 396.2024 null] +>> endobj +1060 0 obj << +/D [1254 0 R /XYZ 85.0394 369.4308 null] +>> endobj +1253 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1259 0 obj << +/Length 3376 +/Filter /FlateDecode +>> +stream +xÚÍ]sÛ6òÝ¿Bo•gB” ><¦©“sçâ\wnz½>Ðeñ*‘ªHÙñýúÛÅ)Rt.—™ËxÏš¨(H¶ñkz—$Y+¿"ÿ´+<µtNáÏË–Ë¢)ªpzE¿u^.‹òÁ1%V£.$}æo>Ü]¿ý•´˜vÞë¦f­¤RfE’:ä·E‰·&;_Teãð«ÈJîáN„ˆçÙb]äùÒ>Óï¡ö}ÿVš›4Ëê©Ädcµœ&¥Å¡EœôþœÿïówwïBßö}fÛ<¨*NäŸ@uø¼¦§å!'À+Y^<:-Á•¯ßÝ]ݾEžOšªüfËÊ‚A®‹å´Ýj–¤æ¤yš•Ï>húF«{ðmi€žöE“×hâ<Eò£¾Þm•j7]3”·&;y-§Šm;}Ô± +ܳðB¸®OK3­f]¬ójÖb¹F\\l–ÑbSäe3Høx"@ ¸œ& Å¡ Çl‚¹<ä©=ȪEª[çŒðSæ Ъ¼”פƵ–q|»Ûä[ ÚµµqÀ¯$›FC·Œý[‡ö|(«ÖUˆTQK¼·Ö‚ªhcæw—ô’O¦,æ‚Ÿ(õÖÍO`[³\澕š·9=ƒãÑ4Ž”m†6r3'ú¥ 8}z<Ñ¢¯ S™8™×»|5zŸäæ© +ß]¶Ï?L—2j;¬<(ovhÖQùiYm³bÌ@98‹í‰ÝŽ“ÄL&"°ÖöwûÇ[ˆ¥i0Ìýj‘ˆØD˜Hñ1aa¦.'MQ‚øUèßòlyÞ"cY£á/XdkÂ"–»÷ªn¢º ­nŠÅÐ"Ñ©`'d’€k„‚¾E‚å‚{ë“à2 Å;ÑÑ%ÁŠ‡$ J|}€ü#ÏwÞçrŠêðÛáÁ!­Ü›I\úHi/€Èl¿òoV\,†ã· +9Àî…A¶ ‹›L zçéÉ{‘¢Y{Wꤞ¿på 8{Û‰VLj=}Û]¬ó·Ýb!¥h+ üGÅ'j\G÷Y=Le Ž3}ŽkHä†}»UÖœP’+yÌ‘¦1q¬`FrZÃTÛ6„E"áóë†Ö;7Ž€ÏtqK¿u;”Xt†Kláq çì·En‰I'¨Äž2úiöYYƒ@lhIÝTþí*‡ª(':á(‘”ÕeÒ‘Fp].( ~¸¤ÿA¹ƒŒ1ÄsVíð³ú¼Çœ/}¡QÝÅšPã€ÕÏÙ=ÖHȨŒ™>6 ÛK¬°À‰yÿØÑxªÔNŒ„3Å•é¼ì§^Žný +:8ìʘ”tF¨ÎW[º÷u̴ΧjÈ+"¿ìh€Ò „è#×0i›O´”(G®áEsû‡·]—УþˆK9݉úºšH˜dü”(ºéKÑÎÖÃ×Jiš€Á^>ë–ÚP¤@:Wwâ"Nù«Š)ßÆéfÝNá½Ôô°Ú͵G£ð¬µ˜x©ßùݪÄbà¤(‡JÞJqâÏ\þ´p‰¸2tekü»‹[·eS ;p$ ª"zK?~xMÀ{çyèl–A±1%)ýzÇ<üº¾áñ¸šZæONfÅ'-êlSWÑÙO ÐßH>‚£èÃÎ}§,ÃkQ•xöâ æÏý†ùø·Ä æL …ˆ„/;D +É—fèsýÇÎCÒÿù§3†endstream +endobj +1258 0 obj << +/Type /Page +/Contents 1259 0 R +/Resources 1257 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1237 0 R +/Annots [ 1263 0 R ] +>> endobj +1263 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [154.2681 85.4256 203.5396 97.4853] +/Subtype /Link +/A << /S /GoTo /D (notify) >> +>> endobj +1260 0 obj << +/D [1258 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1261 0 obj << +/D [1258 0 R /XYZ 56.6929 679.1143 null] +>> endobj +1262 0 obj << +/D [1258 0 R /XYZ 56.6929 667.1591 null] +>> endobj +1257 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F48 940 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1266 0 obj << +/Length 3662 +/Filter /FlateDecode +>> +stream +xÚ­ksÛ6ò»…¾=2x’àܧ4qrî\œ;ÇéMÛ4EÙœP¢"RQ}¿þv±Å—¤ôÚñŒ‚Ë}a±/ˆ/üñ…Ñ“©Z$©Š4ãz‘¯¯Øâ Þ}¸â&ô@aꇇ«×ïe²H£4ñâaÕÃe"f _<, ÞþãÍ¿nî¯C¡YGסŽYðÃíÝ;ZIixûéîý퇟îß\'*x¸ýtGË÷7ïoîoîÞÞ\‡Ühß ‡áÄïoÿyC³÷o>~|sýÛÃW7,}y9“(È׫_~c‹%ˆýã‹djôâ,âi*ë+¥e¤•”~¥ºú|õïaï­ýtNZšH‘Ì(PÈž9ƒ¹Š‰N£XÂ+Tàí +exý^™d™$‰;B¬³¦-va½©^t€4ÖQ¢¥r°¯®C)Ó`S·å¯Œ‰¢g!‚lwÍMPà,"»Ü›–ÖVõŽ–ˆ-þ·Þ nˆPólrÔ²ažxñû¶*ó²áR%‘,ù\zÞDÇ/ÚQ/BÉT ¨žó(ÕZX¬M±ûVì²Ï ~ŠÏU r-i¾oÊÍ“c’÷Å‘ t™hÇeV5uˆ<®æô®ÒHhå%-IÎNhIE‰ê 7õ 2ƒÕƒl¤jÂçNMø€jŠH+‚ÅQÂ(%d¬,ª‡çbFPÁ¢XpÕqtBDÉŒy®êm[Ö3ÁJ^h‚:¢ÙcAc³-rbw‰ :(Ý7í,+ìW$ÜëMn†¡#-¥ç¤i³¶Xƒà (%EGáð\æÏ4ͳÆñS¶4Ö`»rimí$7¡P2b*Y‰Žê7éiuÅ ìó˜E0 %âඥõ¾ZÒ”ÌZcUg1yÑ4Ùî…Ûš^·ûÝÆ}²Â_¹×Ï¥ãÈï —îméæÙ¾±vïš*ûV4rk4Äô@Ú|—5ÏÑij²ˆipúq2òD$q@aŠ!Ÿ‰$ÔÑ Ã¶›:Sç°/\3sž|5CpÜ”‰8ú³‡×€zRox/ ½ã¡;׶ÄMc¥¡Iþ\ä_pšZ›£—Ùº8z+X@ Ʊƒ¸ûLãý}S´ôuö”•›¦~þô†&ïÞ|¼‰Ü×õnU.@1D!†›œ$øÖ»O·ïÿCó5ßSAÖ¶`$9ºX!„$»„â&ÄL,4ý•iÖ­º¿ýp{Kœž3‡¼l‡Äšýv[“¹"þšèå5PæAf•„ôéè‚ÂCï7­ý€R@ÆxLìH Ê$ØWm¹†IË.ÄAb^›éàs½. hÐñB\z®Å7‚p+}iM-Ë€º*5ZàÑJv$;ÝÀÄë¿Ýðs¹\›¡,¢ò*1(>ºÓ§ý.ó^(B›%½¶È´ˆ¬¥Wäûpí¥ÞÓ’w;°vÈì>&Þ†’z`¹OÛn@4mYU´và09Û™cŸ,ÉÅ«Öű̢À…g¼†ç`¥­`}h{&0kÄ3qÒ?éT‚¹Ëø¼êCöO +µ+òý®AG;öM²tgIwP3´¾I +Èm؈ø‰,QŸõM(¥R˜^ÞÅ„³TX³NyðÎjž¿î |`J9,4mCP´âtà0ÁÞlžv). £Od5H©…p¸miÙ,.ÝH†/<’C½ûBÎKcVž˜¡}yæJš 4LZ&A¼æ`9À5ò“ʉÆ9ÇC/R›ÐÚ±=Ûðêná”Æäe')Ì—µµvxí?|PêlùBo¾lêÈ+Ǫs4\”<]›Ó£0Ž[—ÀsÖ_^A†“ ›-8Œ"¢Íz m‚e±ÊàÌÓCÙÌ&öI$uòLËÒyZGÄù#ΣhÛù„Ûp<ŽÒ¡ØõvA˜ùDYC„Ôõ—ý¶qÙç¢ðÁ§©gËHŽŒðiûªhóçð©ÚÏ!4*îí={„‚âtb"2Ê\ +B=¨3AÈCÙ3²Ê…d&l_¶Ÿ&É +?‘œ'ßAÍÐœop½Rèö‡C²ÄU vVÏ8‘êÞ˜éK¹sjR¯~òsˆÐ–-žJAÆéíÈ´#e#8Æ£óçµ— }šUµgúP¶ÏÄ åh6ü–üqÄU’O™í—ئxÓýæ­Ìúso|>s9:\Ìkf®N¡vï +3MÑ9Üñî»î’ÉÐéwô¾¤±­<3ßû‚ã—ð(f±>‹¾c€ËMýCT¡ç.”&Žt"Ò¾ÑušE!u •,”RðAJ'ÿ®§+NÝ´HËîä~ºc<ÀÜLTH¥Ðf¡‹ wÄ_~TšJ‚êÍ­´G-Ø…×·k±xWƒL‹¾XsØGmåŠÅ`ADÃ$2Ú‘XµKÅ_® +÷P®·•í£ßµUa–Nv_¥Ø‹å¢¯ß?·eÒÊ”ÉExì}þ9ƒ‚Ä+—pÀµðsîÈÇ PL0ÎzÇ +õ >#,—ᶮ«‰ ÈÐÊtÑG;õjJû äÁbä¨#g¼ëÈÐy§µÇ¦®Šv.²€Ò”ŽÍ°—8i¢gÕ!{iºZªÎ¡ds>q‡éí;·ÖË!ðP5'£–„íÑüRk§uf_<”ïê…؃ò®Ì›iÜJ#ÁŒ8Ï@5ÃÁ0naS:ÕCNP1ò;²Ü~ãšùê>Õ½bGwÅŽ‚Š½ª( B/¶Ív`Áey)&…4ºúGSÃp`ÿd¿©(­A4¾­šÛÆŽ]Ã2ÀúÄåj³à@'Žæ {²½[,h€œ ¿mÇÕ®Üþüþ~ø:£a›íÀˆ÷U¶#„àxàJx´7žæx—ÄñÚÑ¡õ]f0E8šÜB¹Ya“ýhju¯]9ã`Ï’ÔŸ°í®þV.6>\@Шxtïæz¢£ý…XU–Àr-‘É…ƒÕÁ‡ý¦f=Å;s¸¸1CÂ/ƒD·~boè\½ôhRÙ˜HcH4có½Zéà/14Á;ÑŠŠä$7Wèøy•x  Lpw7p®™Vê‚»éAq7j΂‡©68)åyêÔ ùá]"G'ߧßí~{¬±›|WöÎJ½š9‡P%1¡Ìÿs§gÌüÄ;ç¬ÌÃ_yŠ÷{Ï^Œo¯fŸ‡ºÄÆÛY[ãP.&Xµµ>Ôi[ë ¨/l¯!NØš‰¸†€t–z5C~hk2âŠÉÿ5¦6bljJ–ž65† —ÊyÎÔ<ü‰§x¿ÛÔâˆ'â¶wP—ؘ`;oj~žo Å#ÐCs@H®ÝYæTeMØl³¼˜8(­â³NâãvC¿€¥ƒ½Ä Ûº8§GÚ\;µ­\xÓfîÇ’lsÆýèÞ­²¼¬ÊÖÝ–C•UgKw;“Ð ,RM3* i»™È + ?ÝÝþìØ}Rm=wåánÑRt?û‚§§bƒw&d ®“Ë™ïh´¢ÁøîÓgš¬íÝšàÖ{Šƒô5vÉq渄٩ýç&Ssiÿå`ðÓ©ˆ™Dôöß‹³ôò¼v"èSl$ò¡®†½ÈÅnN´Bõ×ÊaÍV HÚ´ýÎjSªr3û«¾A«/Ï‹-ìô+Å°…£¹fcù´©ÝåøI/jÒHH.Ï{ÑÐi/êìÅØrY"?Y®võ:Ìöíó«î®nðÊ^fN +ƒq“‰³ìu@Sþ†EŒ€úkŸAß +JÕñw}Òví6äk¼ƒJÝE?¾y,ž³o¥­Sû«;f7‚€õ]^QÉh€®¶þòûTü= ö‡Jpwed]¾ÀNn‰6AP¶„ÓgûË#ûA§EzƒýD,^ci{; VuUÕ‡û[úÑ]Î9œwîgJ°]àËMú‰µÔþ.zf{Xw¡ó§~}ümºJ"iÌ™4ƈ4ñL¡$*sÞýN{ÊúÿR]òendstream +endobj +1265 0 obj << +/Type /Page +/Contents 1266 0 R +/Resources 1264 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1273 0 R +/Annots [ 1268 0 R 1269 0 R 1270 0 R 1271 0 R 1272 0 R ] +>> endobj +1268 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [108.9497 292.4924 172.6404 301.7078] +/Subtype /Link +/A << /S /GoTo /D (statsfile) >> +>> endobj +1269 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [293.8042 246.568 355.0043 258.6276] +/Subtype /Link +/A << /S /GoTo /D (server_statement_definition_and_usage) >> +>> endobj +1270 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [395.8905 246.568 444.6373 258.6276] +/Subtype /Link +/A << /S /GoTo /D (incremental_zone_transfers) >> +>> endobj +1271 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [309.3157 215.2488 370.5157 227.3084] +/Subtype /Link +/A << /S /GoTo /D (server_statement_definition_and_usage) >> +>> endobj +1272 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [305.9683 183.9296 367.1684 195.9892] +/Subtype /Link +/A << /S /GoTo /D (server_statement_definition_and_usage) >> +>> endobj +1267 0 obj << +/D [1265 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1264 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F21 702 0 R /F62 1050 0 R /F39 885 0 R /F14 729 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1277 0 obj << +/Length 3827 +/Filter /FlateDecode +>> +stream +xÚ¥]sÛ6òÝ¿Âo'ÏT,ðóÑIž;mšsœéÍ´} %Èâ…"U‘´âþúÛ/€¤D;—9ûAÀb,û ªËþÕeœI®óË4‚8Tñåjw^>ÂØJp–i9Æzsñý;“^æAžèäò~3Z+ Â,S—÷ëßI ƒ+X!\¼ýõý»Û?Ý]_¥Ñâþö×÷WK‡‹w·?ßpëÇ»ë_~¹¾»Zª,V‹·ÿ¼þpsÇC‰¬ñæöý Éùç…EïnÞÝÜݼ{sõçýO7÷þ,ãóªÐàAþºøýÏðr Çþé" LžÅ—Gè„Ês}¹»ˆbÄ‘1R]|¼ø—_p4JSgù§Â@›DÏ0P›3Äy_¦q$†¿mm}µ4J/šnË­fÿÝÖ¶›jÑ컲©[†‡+•-,wZÛ vƒÜøþ]”öT)Ò"­¸Û³miB˜VAhò\pþãvæE×vSôU0%{×ki0aõöðÌRÈ{°eýè°Û£ejeÚ†zÍNÆû%Òs¹T¹ +t +¿*ÈãX!ݶ9”]Ñ•O@ŒŽòźè +¤±`àßMm¸jê?ÂP?ö~C/k` Ó¡ÔÚÓ=à™¾;)Öë]T< ;Òœ0/<¼ã¾zfø±¬dKç §'C2«Š(Ì‘BüÍ}K|Cì À_vÒ@ÑOù“3+Z­eññüLðªXm-h]Ç‹Ûšam³“ѶìúBŽ§•­ÐÚNÏÃV ¯×¶-ÅCe£&4‹¶_mq\1Í4‹# :Bè ,À8ÀKk¼¾•=NóÄç4Žd?ð´UÇ”Ué&xMÁƒ ,QÊ¢|ï=BÅ̵UALM¦&ÙbW<3ìAÆ@\èÇp€íšu‰÷k¥ÿðÌ}Ý®ð’;7\% +d…}qèJÛÂ¥˜$Y\WmƒÒ v¯xjÊ5‹Fâ®0A‰d;@Œ†þŽ;s¹»LO…;SNÈ`Dä`íÞyì÷üË\ãáfo^0pÉŽ™(@Ø7m[‚0Ø~ÙÛº•!ºª324YÒÎÊ•Ó\¾¨¶©žDߎ[Ú[M_­E+Q°Žek½êÑïž5à©ä»HYÕ§j/Ê8štD`Õ‘¤w(Tà(àlÅnOò®CЋ B3´Š8(V›Eû¹åÖ†§¢¬0à—ó¯ˆuã¤q6nŸmÓvbØÕØf¤YžŠÑÞ4M +Ðös#ŸÓIL&øB6I-îB¬À}ÏiAÂ{‡'ú¿÷€oŒOìšÖÑ ­Qg*’ñÐI.TÈ¿»¢¬<éµífHW†ØAªgØÀ†eVJ±_!µÜqÎzjx¢œ¹—hИQ4!4HFgkìÝØè[?Ž¿Ñ$z¸aYòáqH¼$úИ}(By¢™†~–Y<•öØsèºëìnßáuÌ&]'¶`kw~è\(T©1¯K… ²Ô˜c‰/«àFeý]•›g‘×™] é¬éÁ®úCËá,2»iœ)\üTqyU³qK¾v€y)1 |¬¯‚ÌQ¤ ™—¦Së1¨O,æ +Uó(ñ†Å¡æH:;0Å£ób_cF”™J\:0ˆürshvK +°0ÌÕ/\†J•(g‹„’Æz¬±‘ÓBh0Ç"-õhd²['Hµ[Žõ2½9fÕäŒ"‰ƒ<ͦ\d}5 r®ùÜïQ…bˆÑP\Êâ‚-Wq19¡0Eä)qú‹é)ÅÄä ¦”ÁP)«÷­p~"EÌ>3B"¼Õ¢Éµ[N§æ´4Š‘†0{ìœÇÑ.£™`!ãד,(æ#±º~ÛÛYkÅy-9ö–Â`:•Ó"Òšù‘`‚1æƼ`DVG…ƒÄxky’0øì/‰…‚hH`°ÍvÚ8sb"E‘ +J[°E܇ßQìÅ€)ÅÑ”b‘á87ªFé Ë¡ýªU5/YÕ¥Ÿ?¹½-ƒq‡ u3B~ŽPL% æ÷skŒ %Gæk.ýh÷ {•LÒ®Ü%ñq9šÌ춌pwóîÓÇ›†³å£‰[—•e¢‡q.ŽqΘÕÏ“L îa'v¦eÂæ„÷CRèyOfilðdc‡øW?˜[ŠµšÃ‰ÉóYf?Tz„¤Êà¬Ø¨‚T©ä2RäB‘~¡8ÈHË1×ÕLqÕcqjÑ­¶Ë]±ßÛõs ‚å1 +ãf“ůÓá±f™¸ï4 $‚SJn7sµE*{¾ZY„X 7z”tšŒr r­œ›8]Ü~xŠäœ<€„‡&©DƒãŒÙ#X(B´â):#qD9k–åSá«Êí@¨ÐرŒ›P‹?A°ÛšlQÂQ)Š”†ƒÇc0ˆ ,²%Ñâ¦ûâ19WAÌfa ËvÌæº+wŽÐœM_ÍY<Ô”öN–7!ÈÏeÝáfû `×R=)aõè±9|æë gùÔçŸÏöPÛŠÛ¨>‚-¾Z¤Ò­' âÖýÛ2ÜÔ5WRÚÙ"›˜Å)-üºôö8€3ÝHb¤Å")©éÀ„ÕÊî¹=VV%Q‰éÁym³úL‰@]y5Æ;eQ£IÃUYâPÌçäÉ]ÎÂÉG’’,µÜÄèî±&q†çaIê$Zäcp¨(+®ø9-ˆŒõ={ÑT8h°'N!d/â3ÞˆGOûþ°oÜ:ó…\ˆÏWM€¬aý¢¹3: L˜™×ÍÝëesç±póò ûxöˆërƒ >àÜêÅ:ÓȼNŽÇš¡gb§â4ã8™ô›w廧sôÄúkO*Qî2R~3‰S1 `¦|HÀª)(œˆ©zˆÚ¹aßm,7? í +ÐiY‚õGQÀËN&1‚IEZÏò[—Tï"W½‹bbã?Zþ› WÐqw‚m±ÃQì,û°B´Xm‹úÑÊ«B6xõérve×9 +ÈPÃïR‰¶cú‹ìƒ"ÑòÄ¢]þD$¦µ³±HÌ&Ÿo0 DY¬ õcC½óU½ é‘ µÒmø÷A†Á¯¹Å‘#*HïúòŸrÅ#ôV„>Äø73T(1ÐØn…0ûDi9Ç…c¹¦Ô14 BŒ‹<Ìð¢bBÎ]èVzûᓬP dgw ¥lÐÇÜö;ç7Î÷‰œuá²F”äôHˆôJ…‚ïR¥X~IëЃ’ÖaÃkv¸ä ¹t¥ýõj)2Pò·¯lÇ¥€Ø zÓžâÈè‘3ÖþS5¦=)ƒŸ q!ÒÓcæÕÈÜÌh %¹,óðõoË)['Î/qÄåWBCŽeÍÉ0qXQሕàH0w¼ÞÁ½m“|Ïcú݆"Q>s&-.Oò¯çv·oÅ¡tµ&T®Ù?.6²x§l÷4'Ê@Õ'¾T©,ñÚÕ±º`&‰>Qó¯ 'N9ÏH°½WæÒpžJ4ÙÎlÇA¬ãÄ?õRœ/lL`ò$¹û™3D :u©»Ç™¸! t蟃Èç©{ÝN©Ê>yàOG…aèTöÉVÒ>nK~ƒO]œ~NÔŸužœ„ßÌØ4ÈR¹Ûwï¯CR2κ –»z²ÂGC/ó[¹N܆î‘nÊndI}ÝñøqÁ=õµ€=¦/TŒTJ¡)4*\ÜvÓbhÃì‘S‹ȇ3/FÑ*ÑR*}=Šc½E{,bìZ.ÖM‚f³¼º»ÇšÙ~4ƒ.mÒéþRËã«@‰–/&”X[hÈç ÐznzÆÙÊ7ŠÏ°¯\ÎÒNžâ8GM|Êè Ýð¸w’Ú1ȵ‘[|̉Ôi245Nô­>X¯¶`¬éC<Ÿ/€¥Ñ¡2ßVÑYJÅÔ5ïã>Êp•¬Ì=÷¤¹ã^æªWU}ËÂMèwüÉF(‚|@t‰¶ùÓX˜h=yqV$2S$8ñ_^8RѨ÷Ç#ç¶E+êrïêk¢^yf*J~Ôe¯>ö 1Œò¢~%ÑF}%I!½¬]‰D¢QZIåL»@²Tå¯îí‘Î7ŸêVd±Ñ“Ýoj‰!²lñÃûoÞbë´{pÍP@º Þt¼øT» ÎD³|þ{AßÆJý’›Ž$’—ÜŒ_²H㲜k;H׆û¥Ð¹nŠ·¼|‚32i|Z&r§±ácÜùÉŠ¢ Ê’o©V/}\j⿹ÝÐKçÿýáéðUn”&Ë^(×BDç‚E„($<Ï•B¾P='ý¿L+•endstream +endobj +1276 0 obj << +/Type /Page +/Contents 1277 0 R +/Resources 1275 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1273 0 R +>> endobj +1278 0 obj << +/D [1276 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1275 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F41 925 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1281 0 obj << +/Length 3465 +/Filter /FlateDecode +>> +stream +xÚÅZÝsÛ6÷_áGy&B € ÁG×qrnÇ'»÷1m‰²5–IHÙqÿúÛÅ.(P‚äæÚ™‹g"p±Ä.€ß~§ üÉSkD¢‹ô4/RaiN§O'Éé=ô}<‘Ì3öLãëû»“ï>èü´E¦²Ó»y0–‰µòônöËèâoç7w—“³±2É(gc“%£ï¯®ß¥ Ÿ‹Ï×®>þ<9?ËÓÑÝÕçk"O.?\N.¯/.ÏÆÒ ï+áÀ ®~º¤ÖÇÉù§O瓳ßî~8¹¼ëçÎW&'òŸ“_~KNg0íN¡ kN_à!²(ÔéÓIj´0©Öž²<¹=ù{?`Ðë^­_j¬0*ÍNÇ:6ƒ1¢«œˆÄÀªsSˆL+ݯ²’±Uö\¸Ê³ºm«éø¹\.fe·hêÝyËÌ•åÅi8øž +=WDè óD¨´ÐC%.ëò˲:ƒIÊÑûëÛÛË jZ¹çÿÖåS5Ãý´ztÝtê¼3Y•$"Ë + êÓ¬H±‡ze¹0yV0w¹l–TU³–š“¾°¢mÕõnÀÔŽµ‚­3°2RÆ(7îkÕFd«D¤J§,Å Q þVó3iGójÚ-ž+˜³–Éèî;gÕ¼Ü,;zX´=¤*À¤üàqd. +P—yÄò^¹Ì„Íù®#ô\Áæ”ÓiµêÆÕ×Õb]ÍöphS‘)£«ÑsEôLÙü’,*rî4€5ÖräÔÀ¥U€ŒÚÅ}]v¢µÄôòPÕÔû\­ó×E}O=Š¡=|a Ém!öö[ˆÑ-ç PN2%Òµnb;É`ó;éÐr[uS AÒ=€ ×jVdXŽÊ ûU©0‚?DXVåsÅ/8«£æófYWk2Úð}šãjY¾ÒsÙuåô±=©,Ggj#*`: (Ï„óþϦZ¿.›û=©L$‰IŠí™öåVZ'¢°Y>|»ª¦€˜{š"6º‡jšT":(vOÛíC³YΨí,xÛ®\wÕ¬¥¦–_~| 9I:±£«yÄýi ë"¥GB¸";I5„ˆ0ÄèÀšŽE­ª39šŽñMpjÅ4ÍvÜÚâ×$QÕìGXU÷-jøÙ# úÙ“Çb7ÖUë§Eíáõåug€OUO™ÒÌwXOË®ºo@fde RYÝ»[TmõŠZ‹Ühõ–WÌ´âô¸Ž€Øs¡ÄéC5}ã®·{@†MËlñ†ðž+"}åÔŠ,OvÄß9G¡Ó¢wšw i›Ö¹E6}¤ðuëÅ´ãçâ kúP®Ëi‡¶€ôÅÀûð†üÊ$™G7/@ÜäÌö{S;'Ÿ{{ʃ¸„T—†¨µÊÉcÌËÅ2‘ŒH iƒˆcÇUW`pEî=Q»„ÈË– $+}¦öWhþR®ë˜ L*ß×Ü )ëö¥Z· ¾ r½³Žpë†àA·´ÏÀu1x8'&‰¨,•‚tÒO{Í0ùsWNx·£ÉiÑœq <¤ÙzHÈ^šut' +¡u‘‡òÍÁ½&¸V@啳3Aᙂ5±£3C•éÑÜ­&—Õ}¹$ÚCÓvlßØãÒŸ_ŽDž€‡`£àðå´Øð,6ðM>\¹0Šß¬™‘»ôÈ*ÉByð§f¶Ǭ’Þ0XÑ0Ѐ°«EdY¿&Qÿ¾[(xë ’ÕjI¾ŠVçqsÍÎÍKí¼мgDêœ~ÏßQ×9ü# +9] }ú©ì‘0±È¬]uÄÅÕ¾¸UC³©SÃm½Wy°RÞm«¢wÛØ$’eTaòž +rüïœH.ÄÃïõí;b¾ýÌ=´uÐÀ àïþR“¹ 8v7×òp²™øGt¸¹› q C÷rW*LÙzPÂ#  Þ&lâJPkQϘ­à„$îiÙq‡ÿåQKú¡‘¡Úhy€eÓàõ¦DOèXXít(¼¦'ÇyUÏ8C[pJwu=>ÿ~"Î'7g…rØrä›l—äL›»®®ïÐÌ¡RH+%„‰ã9TÈu8‡ê¹¶6öôu¿°B¹:.¹çŠˆÖMs› e_ l\”F{GLÖ‡¿C €Z•ë–ßhBÆy?“Kú¹ºáÇÙŒ3W!ÈÂèÐõkN¾u|1Ì’ ”7I¡¾5D‚´Ïnª‹\h›î” «¦m}éø\.7¾ÂôÎ<±!H­y#×È¡$S>n¡“ˆÄQZ&×ÿCl‹Wg0Áü Ün™ŽÀ–™¶¨}Y,gÓr½bR‘§¹9*¼gÚ—>ÌÎ +H›­ˆ§Ì_ét{DmOÛ¸ô}F‚ð;e¬C“bºÆ²SYçB;PxF½ÖIÊØäqIèüØû\ˆ¦ ·Uv¬~l`W p…ñë !¶!‚-Aù—òµåGÏB?l7d"ðìTñÝ©ƒÝ¦wíŠ-~75dP”»°¤¼‰C#œ1QžÊnú@uªS ªÔE÷ðDÐEcqÅ2Ñ)ùP<öÕY‚Ç8XMQe\È‘¶¯ ÓeËýõ¶NdŸJçP"ªã§ˆ©(Rm‡‰'†zVÔ‡[h:¬`ßÎ^C×+>µT"“ÆC0-ºKeÛ û”’~ÐkÁR´^(#D.SsÜ|C®ÃöÛsm xQwÕ=ìîë¾Can¤9®@ÏÑ`hÃOÒíP…›j «ëp• Çuˆ–-”3¢!¨µÕÓ±8å[êrÆ¿DØïA„ûÆ®8¶oIŸÄÕ…8Åe>vÝNÎŒýƒ·™VMÛ” +ÏEƒÈ§5¤Tù†šA´#VDð95©Â—.ó%<âQ”k¯;¶î—›ê€ŒèÕ×E˯®5$XÙttš½kÒ½5ÂQ]i3Z1›óŠÁ¯˜£îç›ÀÑÔËWê^ÔcÞV ‡…Ø;.ès»årNèÁ›{ùͦ7ó~˜<&’ÿnÚX°†8œHéã°;·;‰nÔ}ÏaaÄD™Àst)¯J"GxD£’ÈÞa'Ï?Q}‘àWšeóBÔ®Y1ãœ<9hm%‘Á¢$*X|1X‡ÜŠBêRÇK÷ÇZØ ¹#I¨× U=åz±·hZÇT@®bþÜB¾ýÁhx€$Ejå7xúƒîUR$hßGÝkÈuؽö\aV?žúÂeøÁ26M³ãò{®ˆƒ¹âq±2ÅPƒè™{!ŒJüñU$쌌 mr¼ƒý¹¯ŠÊŒ$L;Þ‘A¸<œì”íÕe°½eöYÜS°c¶°”°Åf _\Ÿº¼å£ 9¡5vçTë ”ü‡ ¤´È³>/ÿƒµÄ!PAÐÐ*}#幎€Êsm7¬]?E•9®@ÏÑ ‚*;Táª4”•ß‚*ØH¢*³Œª¬ð¨’GU®=ª€Hçqvˆ*xm„ sZ™õÐê» Z(±!ò´ŒÜÍßÿßÐJŒ0øÊqh\G å¹hAÍ‹‰ÿÞ·œ KÛì¸øž+"˜ ‚Wüy¨À?ù#b6ZQZÈßóAî—r^о£>>6ƒ–OÙÓÞ…ÑÏÇ‘9ÎÙ¥AþÛ$í(P·; +ÌѸCÙ«ÕEäÁÀ™óÆN†\‡w²çr)[µnÆu3n›rÜuËýÄÌ¿vU çŠh0ÜKp¹–Cx/¥ÏB» 9»j¹é°¦,ñ¾’ðûÂ}ÿ$w?s!ÉÙ(Þp¬@ð_E•œ²=ð€ww?…ýÇ à”ÛQ¨\ËíÃ+8  ¾Øý|ì§Ä‰S‹wavo.üNg®Í·'< +VW™¿&å‘f[èô à\G€ç¹"ÀOËéÃ~ŒÂãGq\ž+¢ÇðŠL + O.‡Šü$ä"¨‚³Y¸¤m‘†O!Òˆ w {˜Ýá é|AimØpÛmŽÂo{ Yí5Òý^;ⵌTÊa½@!2Ùoí¡k5ÐÒoí¾-„ÒRßü€éðÞ{&Wc­fPARÞ?~lcô¬ÌŽ‹ï™öåï^ÏË‹|¨{å?³ÜWx÷‡¯io§Ð=™Ü^}l‰8o–P€ñAWáNd€úó b¹ „ÝwçšÍy˦¸®r{9Ò‡§¿ª¥C_Ã_uÌèÇÛ)yþ5ItyODç> +³åz}ûã忉q2áΆ~ûë)Ô½˜ûw]j­Çꕺúë<@üÂ#ÓU ÅøE +/`µ£‚[>+³ý‰¬ÙÎAg#OÛ&k3î˜SG|ˆ‚Çm±‹ÜLˆ“ ù¥é¨õ² VÆ5-“ "f*Ñ`‘µø@7¸ûàtŒ˜§€Z[ý)ÏëÏߌÀ»´ì'ý­¸?}ew{Ÿ9ÅVÅ­H'P8áí +V +7rWs£­0VåÕÿ ƒ^'endstream +endobj +1280 0 obj << +/Type /Page +/Contents 1281 0 R +/Resources 1279 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1273 0 R +>> endobj +1282 0 obj << +/D [1280 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1279 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1285 0 obj << +/Length 3124 +/Filter /FlateDecode +>> +stream +xÚ¥ZKsã6¾ûWèªj„‚äq2ãÉ:µ™ÌzœÃV’MQ6k(Ò);Ú_¿ÝèÅ—ì­ÍL• 6@£Ñ¯AÉUÿå*²Â¦*]Å©Q(£U¾¿ +WÐ÷ã•džgÚ ¹~¸»úþ“ŽW©H­²«»Ý`®D„I"WwÛß+”Xà aðá—ÏŸn~üõöý:6ÁÝÍ/Ÿ×…Á§›^SëÇÛ÷?ÿüþv½‘I$ƒÿxÿåîú–º,ÏñÃÍçDIéqaÒÛëO׷ן?\¯ÿ¸ûéêú®ßËp¿2Ô¸‘?¯~û#\maÛ?]…B§I´z—PÈ4U«ý•‰´ˆŒÖžR]}½úW?á × ]ÒŸ‰)cA“J$¡ZV²±”À 2¦g%+¹¤dÏ…Jî§M—?mÅîP´ÓMK%EšÄj5œz&@ϵ H •…vbÇ"Ü­Ó08œÖ g×5ø„÷µLÉ=@.ê|,¨ñŸ¦.ˆïØ–õï>|¡F¹£¾_?2áÏcq(‹–^vYYMX©‚OÍhd8&!BÞ쟲®¼/«²;­¥”Á;舭t„'#´Ö°õ(Rn'Ûb—«Ž ©l‘qrF #­µ!ÿ©ð<#-‘0X˜e“h¡l š×J(cÎþ"áxA†¸¹—ì°EõÌ×W…ËHCGàÚ`ç¡Ò·¤×0…å¤Ç‘g5‘ïyȱ-¶Dqg‡,tjYÇuW4ñSÛ²+6/嶠Þ<˽ ¯±LÅ (ÏÅ¡Å“)[Èö˜³ p6‡l‡ÄßÃPåî”Âñù40XMTeý­¥¦“Z§AñWWê¬"jí jñªFâ4¸éˆJj€FVµ µîy+¦ìÏS5/Ô<›"Ž8/ÁòÓQ鼨¨#^%«O/9 +*Ê(6¿%W“çÇhêêD“Âq/œU÷Ø´yR¯3|ÙáêØxy,óGjº½aƒÙûŸ{:ía#;Âœ‡²¿~fþ¬ÞRcÛSv§ìñôYݾôÓ×üìx 3`1Ë›mh!~Gæõ>äºÀ{.Ôyìvºn +BEÑëëz¦…u‡Á’² +m2^÷î¬S4O]é\6•AO£ÓʾÈj0€Ý±¢œSË09ä@«Ê¶OH>„bÿÔõ†ë(xOôç¬:òŒÍŽ"ž*O[)À9ªîʬ0‹*IÒs‹ô‡>æ‡O w-F}`VÖ€€ÿ£IXÞ#6z»´”áð‰V}šðMu4Œf(,½(S‹L×R¶£I2fBc®¿ë<ÛìpX»ÅC{·Mˆ+‰ÎR'¢CUºkjQ|À^rJ꤆[v-¦ƒ—ÕN 2Np³t>JF"V½ê-œ±±š™œ‹£ OE^¢žŠ-žBªßÚ™'¶ð@ÌÓY|wÒÊ(ab£Æ'=>ž‹¾º £7°Ú€é²§{¦££]LAøe‚¿¶pÏ4_y>`¿&g.ýµ×/*Ü;¯W»ùB„l»e¨Öö< ±ÜôNi[d-©œ  ´m‹àÀ3šâ80Z™â€£Q´ÀÖïaÖ¼.®3oø@cëñy‡‘Rø³im#c‘Bªr¬Ótq“06`Ëm»šõõpd”BÔÆóÓã© ·Í>+¹ë>kKD8J3lèW#­)ïcÐx¨š{Ä+Ü;“sË£š¥,ëäµÚ!£C¹Ý:׆(æÄzFç °S7ô5;"BÂGT„¨ùßk »G¢“Z€±-:¢=9™F »(anß|y6c{Šõ2Ê€Þy®=ÈVÖ—‘±ND¡òõt9亜/{.‡ËúcÜ´ç£%N +©õë"x¦ÆU»þŒeeNm"Ö ^¾z¢+¨à9É¢ÈåìºX‹<àŽ…úûRÏpý%]C½™›Útº3syÎ*I“LÊ® 74 í6µÖ6:N\1õ/Êϵ1:*:‚eéq=ôyä…ýû£Û5P]‘ ” L™(Nê8íý¢zöÌë×ÃuJðWNÂКY¹oÑ”ü|Ìps&ŒÝæÂpQy53KO4$léÀYƒÌ°GÂʯ?±J°~‰âÄ°lÓ\Aè“~×  Ö?ô,8‘å¼—c]áù»2IÍ$²…8÷l8Íðë@?®âe¶û¢¨}âlñ¤¶¼0œÞñ¡©»CS½– ´›£diÏx +„¾¸€6¡è½çN¶çîPæÛ#ÐÝQS’.:Oæ ´AiêpúÌɹ  Îa=åÔvÅá˜õ×9v0 ¡C¤J#!±†};ôü›á€yØ›Ï;Æ ¥óè +¥­ɳþ™ë )|üWx1 +.à!qÑeeÕŽmøoä†>áŠÈÝÉg6v”Ña8#o»Ë• ¡õ©lÀt9“y&çÁXl<¢xÓ&µÊ^]ºgš¯=®ý!•­=.ý”ì¯Ý”r¹€©=$Bº“—j.áÉâ;†ÎÝ!•=ˆ¡2^$G[Aäc’³å/ý±ÀNýà¢ÊIáQ•Îè(Bµ«Ô$ºT“øÌ þŽ­=à3_ÓOŽ$MDÚßKLÏb¢B +-µ/"öÙ‰fçKâ„ó<WDpxŽe›Ë !®…Æø‰Ü ·#‘0‘‰™ R „(vÜ5–êWàÄfñˆõ2NeŽA±¥ÕãåÇQèlÀ&ú(„nÖG! Ÿ£PB ÓÛoDhü]Iæ.a¡ëãç¯Ôå/Gƒæ!e{L7ÑË4-A% ­Få£yÔ +i(åØì‚€cÅ$¸PÏå‘(˜Ë¤o„*Yˆ* ûù½vcC‚Gcõ0\–E&¡ˆ•ÑÓH€#^×æyø7¬0-Â(™ÜãÝì&÷+ÿ¯ãò‡ºùG§±oºkd.rç` ‘"ÂoÛ³ub¢ÿå—ha’$Ë¿LKa5—ç¢q!ÌÅM?b<ÕÆK·Tëdz‚1ÅBÅ`æRBõ1 þ<8¯È"Öƒ“E¤!ÑÒyý‚Öƒ;ø«‚Ù/(‹‰Ô¬âH„Š~Ë°ús%!±¥©&žAÛíô¬Gøþf¯VØÏj¸%žw3˜ØmÉŽ| …Õ`’à'!þ¤ÂûïZBAíì …à´É³| oØN–âo6Ôð”ª5MB/|ÑÍ¥->ÏÐ i_Q È:ã„¿‚Ã\3«26¦ð+\nÏ4œ±MCð¥óPþžž¯Î}c!„½™ýí_Ðœ^dbpµäÂ7 P¬0XEjÀGšêºH]¬H˜k ú‡Z+Üendstream +endobj +1284 0 obj << +/Type /Page +/Contents 1285 0 R +/Resources 1283 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1273 0 R +/Annots [ 1288 0 R 1291 0 R ] +>> endobj +1288 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [339.2005 483.6075 400.4005 495.5077] +/Subtype /Link +/A << /S /GoTo /D (zone_statement_grammar) >> +>> endobj +1291 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [455.0966 291.3684 511.2325 303.428] +/Subtype /Link +/A << /S /GoTo /D (address_match_lists) >> +>> endobj +1286 0 obj << +/D [1284 0 R /XYZ 56.6929 794.5015 null] +>> endobj +354 0 obj << +/D [1284 0 R /XYZ 56.6929 712.783 null] +>> endobj +1287 0 obj << +/D [1284 0 R /XYZ 56.6929 687.8416 null] +>> endobj +358 0 obj << +/D [1284 0 R /XYZ 56.6929 470.2923 null] +>> endobj +1289 0 obj << +/D [1284 0 R /XYZ 56.6929 447.8217 null] +>> endobj +362 0 obj << +/D [1284 0 R /XYZ 56.6929 335.2388 null] +>> endobj +1290 0 obj << +/D [1284 0 R /XYZ 56.6929 312.9276 null] +>> endobj +1283 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F63 1053 0 R /F62 1050 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1295 0 obj << +/Length 3121 +/Filter /FlateDecode +>> +stream +xÚµZKsã6¾ûWè¹jÈà ²ršd<‰SOÖñž’h‰¶X#‘Ž(ãÝÚÿ¾Ýh"(JždjÇU#°Ñ~|xðƒ?>+tÎd©f¶T¹f\Ï› 6{„ºï/¸çÉS6äúöîâë÷ÒÎʼ4ÂÌî}9+ +>»[þ:ÿ?ß]Ý^fB³¹É/3mØüÛë›wD)éç»7ﯿÿ×íÛK«æw×nˆ|{õþêöê滫ˌšC{á{8Ñàýõ?®¨ôýíÛŸ~z{{ùûÝWwq.Ãùr&q"\üú;›-aÚ?^°\–…ž=ÃËyYŠÙæBi™k%e ¬/~¹øgìpPëšNéOé"×B™Y¦A¶,§µÌr¦Ak™• SÁMÔ²àSZ\¨åj½îž³?öõö%ëÚñ¤¹Ö¹Z̆=¹&¸©2cR ~yªÍoŒ‰º‡ÅüyÕ,VT\w‹jE;¯–Ëí%/æußÆEÕR¡Z,꧕;ǵlÚjûB”w7¿P0Ë~×tm¦rÌïVïiS} 6¾Ÿ§®ÏP zÚ0XÎóRÃ4Qê¾¹_×o °¢3“ +Ú¶ý®j¾ë\’Ž©ˆŠnp(ü}»ß¦½äó]½m«uöP-šö1ЄÀ¿ßQaÙôƒ>w«z“vXÿé{s`©äa´õ®­û7T|nv«À¶†AûjÛ¬_ˆð±ížc+ +NÀÖ­k´{êé3Y°%Ù#ÊUæ–³S–82+rÅ-4CîM…’qÍúŽJ÷5ýöÑ –DhÐL¸tr‹ÁÏ´ÜwüoÐÉÄàBæVxXä]½©ÛªNpß¿Š† ÅEÕ{iœ=Áo÷©Þn›¥33øµX~2µ²+&B{v*•&ºä£ñLà-ÞÚWr‹É¹dâór  %¥ÏM)ÄEqÆGûu9 +tf's"·pû3ÅÕßO.âï%iKVŸ÷Ö!×io\&6•ZòJ£Šó2D® !äh‡+1<%R¤.+bj8R RG©k]jquþ ‰cw6¸+¢>À˜MÑ9 +V§;\0lÐgà³cÆæô¹Ùd$É—î„£9H+¿{=c®3æ¸æ°ZV»ã ‚¡åùÑ#×Äðé¾öDR‰tüÆ8BÆ÷±©1v»»‘É­ûýýƽ@ùÝK[mš1Ði Pi’àR7U¿«}‚z?î‚9@z…#R€z0SúÐä;—µƒ @9 äè±Á€ìf‰”P¾év5Qw«jÃQÐ=BÕ}EÁÐÐI “aå; …¹Pœ*¤£¯|«ëŸ§N v˜yÓöhϮ·½¾>²Á!1Y¥g:ÕÒ¸3ªÜ>ú£‡ÛÕDþlØàØjŽûuVS/𠌤±¹<’Æ°¼…M¤9²ÜÈõš °!“=g(YË#»ªYŸö]¯°ôÎúîë´ïF®±ïf Îsµ]¢¡Œ•ÁSSœ$rMH’(ƒéœ‹á´ŽÝØÈèÆP n ŃãGtcø ß‘7†òÁñù1>5h¶®>y-A¾BðÔ_gãrù&ZÐé1|“âÜ‚ªˆE¨ C L'¹uÑÁÕ ò‚D—q0²â@a°Ãe\$ÿ… Z[ô&,þw +ûÀ–¾,vxCÝ¢@5짼°)€Øz±}4wµt=â1Üšq¡S×Ó§ £ 7.8©‚””§z =m°d’•ó»ËRÌ;â©Ûê~íùâÐÊ =¿!æpœ7¡§öOZÈN7•yÞd^µ°a šýæ¤jeÜ.e`#d¿/t#ÙüSµÞÓ•ÇþôiUµ¢s ÐÆ +û×–Øâa`–i¢_‘£Fݦ7Õ+(/X åÞ÷{Ðç },º=^ãî:@÷u€`¨#ŠZŽâgàÊîªË ûçS××HÓ=0÷S£ÑÖ/ƒ¿ã4NÀcJ„+°.¬”tí`¹†ðw·«ûÓà@–%¸k¡Ý9“tZ~DþlØà8÷û9à@`-9xë°óã›øÀõŠ JA-“2•!‚ƒM7TùkPA¬¯œÑ ¹NC…Èuˆ¦ŸLÖ¿´`¾=eªt×Çr¡ÊWdˆ\B¤»> Ét*…¿·Ú_tRù¹rDƒ·Ë1&Ñ&_{EBÁ_óèy¿é: ¸…4Ø„®L±õü-üó|§úÅ#·´íü@èB²ãoB¨¶¹§MÖÕ}½î‘JßԷ߇‘seQΔsˆN¢8Rà¼÷s1^6d›êÊÏu4)kè Çñ/ë'¿û„ äÏHÙøp4 ú¸ø  +7øtµî uØ—=0FÛß6lz›ÇÖ›ùòð¶ÀGƒnS‡Q¶mŒJ|mðxfÃË$²Â¼rþ1ä:ã ëà Îpêíñ–·Ì…(Θ&†O7¼îU¦ã'HY P=RVÂ2Ò#RÆ´7üõëS»s$¸‡ Äâgçû:x…«\y®áAåÄ•˜Ö¹Á\C8&ŠtG?‰m T:ŽÓ!W™¼äe07(9˜ ¿éKYÒK Yž|É!aÏ/‘O¿ä(-çSo9#ÄGHexË¡˜T&o9NKƒw'˜Ò·~ªõÁv’[nÿŠúJØ¿è ¯ü?<ÞЈƒ +þÌâÄ‹9<ß‘“÷×,¾øâ×t‡§†ÊÒÍ4D`öø¥ B¡õ$вÈu!ì„èÿ¤â/ +endstream +endobj +1294 0 obj << +/Type /Page +/Contents 1295 0 R +/Resources 1293 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1273 0 R +/Annots [ 1297 0 R 1298 0 R ] +>> endobj +1297 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [213.0783 309.0057 261.825 319.7901] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_security) >> +>> endobj +1298 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [398.1622 184.6228 446.9089 196.6825] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_security) >> +>> endobj +1296 0 obj << +/D [1294 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1293 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F63 1053 0 R /F62 1050 0 R /F48 940 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1302 0 obj << +/Length 2626 +/Filter /FlateDecode +>> +stream +xÚ­]sÛ6òÝ¿B÷tòMˆà“É“›Ø=w7q}ssÓö–èHc‰tDÙ®çæþûíbIQŽ3éøAàb±X,öV jâR‘º˜d…N*7™­ää3Ìýx¤' HI뇫£×g&›¢Hu:¹ºéÐÊ…Ìs5¹šÿ6M…Ç@ANßýrqvþã¿.OŽ3;½:ÿåâ8ÑNNÏÎ>¥Ñ—'>œ\'*wjúîŸ'¯N/i*e?œ_¼'HA?ˆ^žž^ž^¼;=þãꧣӫx–îy•4x/G¿ý!'s8öOGR˜"w“GøB…ž¬¬3ÂYcduôëѧH°3ë—ŽÉϺ\8mÓIb¬Èaÿq)+‘)H™+Dj´‰RÖjLÊ ¥|½*g·‹fU Ï«¤NÁÖ]¢{[G¬‘½Mgo%Sa 7Øü×»j¶ü]J]µÇ‰ÑzZÒÏjÙniÔÜðÄ|¾9Vù´jÛ€»]”Û0ªhÐV›‡jCãÇåjE£ºa¼r6«îxüå¾Ú,©O»YóžLá¾õdÍtÛ€9hVU`„6I4ÜM‘Z†…sÚŸ 7x:VJMA’ÓOaGT³ÝŽøÀ½p88(‚è$8ò'ÁÁ5c3ê]SÏ«9Ójx¿«#Í«›ò~Å+—-òüúÌæÛ1&6“Ü)²^7uEX½;ÔF¨ù„$£«a‰ÉÁjó õµ­V&Z²J…û”RNÏëmµ¹)gU;²‰qf §)-¥CjºÜ-‚o}=§‰»f³miH³Û°,hŽYŽ~qû Qð£s-€¶.ŸìÅ €6ê+o~ß.ëÏaójD"V¡œS,4TìªNšzääIÄíéQs·]6õ˜´M*réò¶F¤¹eÄmyëõÞ(ýÒ%Ú‹‘^¢¯`èI™1Imº (“Ÿ¹f¨º ¶CGbø°\å“4ÍÁôí‹\§EžçãŽ3‰“.Iïtzü Î)“éngds]ng‹=&ÒÒýuLŠ_cÒ9!-ÜzIï¿n‚ h Ù^Rt&(;ŽH1ø¢kºâ&½ë/&tª]_çzÆæD`œH|ç·¼[š§0*^bBZäY0Ûm¹­ÖU½ "ô¤ÅÇ>Ãp‚àêÏr \¼1¤$‡TM™ùÖv’ÜæéljTd"K_ÿ{Oܹ¿ÁJ’Ž”6¶Gío +|³–ÉÁ×k•öhïûgéFjHOù …ªêòz…È «ër͠舊|!Œo þVrÓ0J¤pþ‘fúJ†KH¨ YÁá`”6a˜L ¤¬ФÅ6øò¡X×ål±¬ù–—5kmÅš ² †QÒl–ö¨šû¨›E3Í ûÍzØ·¨h½ñbzFœŽ›ú†™2,;ÿø`ƒx‚ ¡Ã&©Y†¥@WůFƒ&`ÈÔî6yHGŒY­2™"°`Yú¦ðŽ ˜È!Ä‹ãæ‰^Vö½ž :1r ËG‡ßÇÅòXM½»ëÒŠR…U,UÛ‘*@QÕ½`2Ðä,˃ª)öÀ³fM¹óK7ulÁí1@ðé@«HÂÿ^Tc¡{€ÅÞ ¬Ÿ‚í›~W_½xe6HŠd>-y"fD½3Èî¤-žÏTÆ É$Ixþîp)&]’ûáXe…ÈÀìv>˜3h%…VFýuLFŠ_ap„–ªè3y(gp¢ÈÒ&’‡íÞN?§„€hz±éAVœõLÝ‹JÙP;‚!€bÌ›ŠUƒ"€®1µŠ–Ü•ˆ¯\\¥…°«Û®+n›Ù­w¼&g«7^z3„Z¢MÓgßãÖU“M—L‹Y„ ŠˆY&vÃ.˜\sW£d„ðÙ>¸Ö4^”L§ª›ûÏÌ×ÉÇsƼ¿óÞ´dTç‚ ¤ñ!r9ý]:­lÎö‰0WJh)Õ›ùuþæÍk£ßŽïð’jÂH« #¹@ UŠ: +P¯–#Ö‚é)B¼æ!¸ ÛÌ m &ÑÍ>.· F ¦X‘ž_£Y¯çè8ÑÄN âjD Ä£*‹OÖk4Bˆ7 xC$ò,8¹dˆ¡PÓ¯ÎÜÑb´¯?iªw3Ú—D[öst*ÞÇ ¡d¾8òÙP5‹^]׎b³£«ãBO›Ð*¸­ž)Hbá4Vø[ Éï!?‚Mܯ¦¿ ;¡ß ¿>ŒYu°„ˤ{¹HµÎ÷ªEŽÌî•t64=m§éiU§ø YÚ]ChWÆ(–¥²´j+ÁÔ}½âT}˜4* ² y`2vHlÓÂÙnYŠŒvâ€Oö¬JkúVó¸ þ•ñÀw$µ§ eýÐÜz'é\Ž70ROêT˜<–?…Ud·lFÚ½8…›n÷91±Õf:­6Í­¶ÐˆÀ‘wKðÛ0F–±Wò‡Ù• ø áÉË;­þž±qc¬7,G;ð)wà?ù· +»ìùN<ê¶ vj:vŠ}bL›ë¿oiâ¶n¸¡áî ÷–éjÛ– “9ŸkšØŠ`d—4òʱ òÑŽvÈ +ŒŽ6ç)%ms¿™½o$½ŸËô©R®mLêú‚3äýaÀ—8Ô|@E#´÷>û‚I®ëAwS—Q€G„ÝÛbûr±7À8Ÿ5äõCïq–“°x—£íkÈÞsËfÜ%…>…ì=Kø+µ:k…ÌÍ~? ‹OO¹êx†}JP‘[çãc¬a=p†‘­;Ü,Û[‚ „4”Óïw=)DÝõr»%×IâÂÉ~€G4ß~L‡­Bà.cN^¦PÙGGw~qòþýå°qçÚ€à³Lè,UßÝ7ˆ“Åý`›[¡ÁïÆ}}rñŸ±¦Ë·éN¤Š´“@ ºUÏ4ãÇžÐøî=òž,'A'¿ûy}÷¿6Cï¯Ç¦u–ƒþf +ãìçؘ1©aýÿˆdM3endstream +endobj +1301 0 obj << +/Type /Page +/Contents 1302 0 R +/Resources 1300 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1273 0 R +>> endobj +1303 0 obj << +/D [1301 0 R /XYZ 56.6929 794.5015 null] +>> endobj +366 0 obj << +/D [1301 0 R /XYZ 56.6929 725.2846 null] +>> endobj +1304 0 obj << +/D [1301 0 R /XYZ 56.6929 700.2184 null] +>> endobj +370 0 obj << +/D [1301 0 R /XYZ 56.6929 148.5316 null] +>> endobj +1305 0 obj << +/D [1301 0 R /XYZ 56.6929 118.3446 null] +>> endobj +1300 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1308 0 obj << +/Length 2999 +/Filter /FlateDecode +>> +stream +xÚ­ZÝsÛ¸÷_¡·Òˆ‡Olžr‰“úæ.ISg¦3w÷@I”͉D2"e'íôï.vA‘2e;I'3!´X,‹ýø°œ ø'gÎÆBgf–f&¶BÚÙr{&f×Ð÷æL2Ï<0͇\?_ýôZ§³,Ε̮ÖY.ÎÉÙÕê÷èåß_¼¿ºøp>WVDI|>·‰ˆ~¾|ûŠ(}^¾{ûúòÍÇ/ÎS]]¾{Kä¯/>\¼}yq>—ÎJ¯X‰¯/½ Ö›/~ûíŇó?¯~9»¸ê×2\¯òùì÷?ÅlËþåLÄ:svv?D,³LͶgÆêØ­esöϳô½~è”ý¬v±u*0 ÒS´YœhèB^®q À)œÐo\Ò‘£©wó ¥)§™fž²"E,²$c–¿NÈHaQ©d†z¦ÍÊ‚oÕÛ²ëŠÕ³ó¹–2Ê©s—W«zK ͹ŒP7ÿ£ÚoKXïÎ¥‹l<±˜/ëê!Ôõž~¯ˆ ä^ãù›rù‰º]´oXVÅ„»r³!Ò¢À…ÍæÆÅ™¶Él.eœY«üšöm°¦å¥Q‘/oˆôy_쾞KXxlttuÃ*4¼¬”ôúCXÑÂr¨`u7yG”¶)–%®*ÌVV¥˜Ø•ÚX»Ä°áAÉù­™ïWÍ'n'6ʉØhvõY‡íº|k‚n©7Ðý ð¼Ôêá|ɜͦDì²c³=  +ØY(cUÑJ¢* ©¢•Šê¦+ëªEÿÑYT|Ynö«²º¦N4Œã ÜqdFìD3î 3ZKg‚ƒç·u¹zÌ™€Ð2ÁòÓÖ‹ˆ$KÇb{{ATeJÛ`0ù¸Á ʤR!Êz«`£Àuwåm± ÞH3ñ¸¹Ìbi!ãprQ¹*Öù~Óµô«^ÓwÚPÎÄ©•!νÛÏÛz¿[ê&W„{Ð@ ¶©™všJ3rh26雓þFƒÌp’¹22Ö‰²cŒ´Ÿ'd¬V»¢õ–ŸIS)H‹sX…]ê3ß,ø÷ #dÖ™ÊbçÒlb”³4M†ƒžÓîÈTÇ/P“–¸¯žÑ±IÏcNigÒÎœÐδ;2?ØOÆÊ(-¡,ºì¡Êc¥“ß”˜ÀI%dÂ[T¬dš“ÏÓeúlël´¯éáÙT’K†IµÊ·ÅjB¸Ö±ÓIðo.# ~yS,?a3‰Ê5‘|ŽÂFÝ»¼ó¹ ûÛ¯mWl©‹ªZÍÉŒ Hà89Ü–+Ÿá´ÅZ¨µ £®wùvK)úʪ+ ¢îÖ9z6Rºš¾$Ý®„îâ6tÞpë=Û¿ð$œx,äWF¿(UC£hnŠ-Ôk(ì¢øÝððË kx=Û=ÖJ¯xåW(Æ*³¾ +€šßª˜oór“/6ÅÔ6e¡ibߦT93Þ&˜܇æ Íʲޅ,ZWT`°¿ß$`é ‚¾à<ÇÝK£¤ìîʶÀtìDT2ÏÄ|%¹*¬ÂQ “-QßUã¼<•ÒÄ8•Ý /Ÿ/þCDØ”Po©•X«ísjÿ÷ùxGätx}‡Ì£­ã´ñ¶î _nH¢mþ ýJ¤à(´ø˱k +w(îÐ^0­Ý¯‘ãxYUEÏÓ7T ®Y"y*òËý®ì@Í™èuAXaHìÐÕ˜¹üwúš¢ZñÜuEßÛ|WÖ{&6ù|ʧ!& ðj_¡Œ{ô 0wè¬ lPm$Óº—õv[xl +%¤Ûå ¡sSä-÷ËD;CMÞ+d@D%™¼(‰šQ‡^0åŽæ+"­—’ø=ái6mM-N'<„G†4†IÒó F + q ßÝKKÜ÷¯Ô¹`Q]]¡Ýæ>r€FU"öyHÍ~×ÔlJ3–—=ŽF9A·6/Ý” Ì­H!+AÚ+¼¦o[o™ œ¢×˜X|É· #lh%ŽpüÇ·—ÿÂWœ#[úÁ¨ZUÝQâ¹¾›Ä¼ÖÞØY%’t´öŠ ŒŸ¯»©÷a&ú!ÂôÍ®¼…<ç} 2*Æ(’ ´`?—hnð â[àòµø +"=âó FÄG8‚Úʱ³³@­ìÁµäWáéžr…åc» !eöÆ9º5@¸ÚÁñ·X…›€EG]¸§H ›Oòà‚ÑùðhXÞÁ>6ŒáŽ +í«€[ŸÑ•˃’Hâ ·dÁ]õfOFrJl‰ð˪Øäð¢(Ó¢8fìB aÅ<€¨r‹KÍ+æöù¾Çùw¸R¶ξf²ãñ¢¹èBzXæ ]œXÚ|]„dtH,eu” ¥ú}ã|3̾»º-É[+€FÝdâù?Üf<éÖÇAS«o¸Óè/}ž,õé×NCÂ;¾Ö˜X!÷c˜¯Né7d?…àÝ(ÝgýM½È"8øÇ1î4cÌÕ~IÈäÔVà}†„Ä *û˜C@­z3}'\ŸïÉléYÂ)&³fúR2ýÄèì´,'@7ȱ¨Ãc=ÔQg…¤Ïû¾Ê¦x‘(^*üƒÜf€%ôHl+sr{0BFWð¿Š.Ž 2ͤLc©éu}öy&ca2ÿ-Fm¿Ôƒ <á§Ë­š½ªaA³Áš‚àùP²_T¢F‡ª4©4œ,úÇÐ~xhz|â0þ„Bß¾Ô$£HÓÊG– j EDuá\JÆ%i¬tÿš¼ÌOÇz~FÊú\ (À 8žSëã«÷ÄÉ°]]ÂÎ=®ãW/ßã ÝÝ©@uÏ3z”X ’þ°xx¹0XN@: ¢ÓeSK}uå‹•£w¤x]p<}B’¼¹CÆù•'Àb7…]ñBÝŸ¢ü­ˆGn)ž|–IGÚ‘ûÜ‹S“¥q¢q}$¤?[Åÿbb~økŽ|k±ÄMÑGìÿÊ!/à³±s'*Š†üèT–δQǖíÿ …¹ªÿ˜5@_endstream +endobj +1307 0 obj << +/Type /Page +/Contents 1308 0 R +/Resources 1306 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1310 0 R +>> endobj +1309 0 obj << +/D [1307 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1306 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F62 1050 0 R /F63 1053 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1313 0 obj << +/Length 2984 +/Filter /FlateDecode +>> +stream +xÚÝZÝÛ6ß¿Âo•šå‡(‘i²ÉmqÝäwm´¶¼"KKÎvû×ß ‡”%[ò¦— ¬Fä3äü惔Ōߘé„%VÚYjc¦¹Ð³ÕîŠÏî¡ïÍ•ð<‹À´èsý¸¼úáµJg–ÙD&³å¦7—aÜ1[®‰&ÙfàÑË··¯oÞüóý‹yGË›··ó…ÔÒ辬ﲒšÊ¢i‰r†„Þ›wžã\˜’#O=‹‰ªl—ÕäûÏ„"é Oci¤Á°åš¼ò ·o—7¯ÿMô$d÷¹spˆ6ÒÆ:Ö·y•v™ªR\ÄðWoK­«úá‰(‚¤xåî9•Ð…hÍ×ßc¢7Þ‰\)P ¤èü¨7Ëq­ð‚û–¯‰#ŒÈûÎKºý0æ ¤úªvÏ5àr+ÈJ[ÔOZmóòÁ“ÎðÌ«æ¶UZáw{`åEî¹qínÔÖ³¡.¾ï±(K¢>ŠÕGç/nx…[ 3ßç~’ŠÆ³²ÝR£_¾Wõf3¶¬¬òQ­ïBõòlj?œ€<Í$Ry^¦„Dí¶6ó¾øœW¾É?³‰%ÒcVsÖ?—%áDb“¥Œ’;Àç÷8-Ô¢-Iô{‚jXý¾Xçô†û;¶TG±ØúI +½¸r™ßp{ª #§PæÕF½â_[·Vn‚J™ÐÊö7ÁñNo>TÝ<‰OU QLE ‰¶‘i$3R«®V‘ *° ò8 U¹àã4 >N·Ö¯ccV€+îVò ä Yà k9˜=8‹Û0o…Ú +¶t€ù»³h¯€ +Á é.¸ù ¶™.kYê4Ñ­óMv(=CÑœ$Ç|÷ÐúTçÕêW®yå_ˆïHãº1¬2Šlað‹élÈ¢1~&ö¸.dÃÀ…{µË~_„dŒæ]´Å._ÕYjÔP³›Ëzxž5pTëD¨¡7ÕT0îh‡ìT¿*2 +‚´‰UEçGè.ëêžNŸˆÂ¬ +[cX]õD#wEuhsßLHBê.ÈÉ÷»bA Jè*Ò!¦*ð½õ¡BHîD4H"·P©7díát`‹bwØÑËç¬<äÙ¥ñb³§Þ¬1W'/"IAYœè©{®€¤>×4’:®Q$ërIqÊ ÔP—5é¸FT¢I²Ô +3Ôåˆ&Ñ¡I Ñ$ I@£§âóÁé^߇XG­®ž²D‡,¡qÓ¡¨÷à‚w.áÁ%NÀ% ÇIù¿‚+™Â–8bëÿ-‘2-éBî´z\ ¸¦ƒT}hÏ£œÒ…—Ué¸Ft`+cqDj_™·‡Öƒ «ŸÅ±*í¦àµªð½øhå¸]´"*ÔR„)Guæí<‚éÊ2͹Ö!™h%ñ:ÄÒmÝ4¤ú\Ó긦£Õ(¤ XŽí3ªt\#º ÕaJñeŽR<@Jq>ˆW\ãÐ.^Ás$^Á@¯xÀuñŠ¶æˆ!ßãã'x¹Q~K<À–BF,˜ä¯³$œd?sÍÐ纰Àåªõ|_dåâÓ!ß?-öxás +,…ûyYÏ3"*•0« ¢(ð¡Ì>ãŽ)y<'KÕ…h~ëu±ÊJwð„>§-uuÁ +š{ã%~áéî1ÖÄ€~ã‹ 5ø°H²‹Ì ¬»;Ï›   qpµ%ðVíÞ!,–It­¶ÔÞ”ò@g 2zé}“¿“†®T°Jwœ®ì$Ò*ç‹4Ž¾ó³UyûXï?ÒË]V­‹u»eÃ6…Üå܉8!ừ:$µm@;-°@3/¬/@¤á3ðØÞ”ÍÉœV4»÷¸ÅÆ•Ÿwˆî!¥»ª€—Ædá0e¼¿7¹ØÈ‚S—O°e´áŒ:†ú¸¦)€Tä¸j!"—9Þ$´9fJ°„ïq>ÏýÕ²ƒ¸"Ž ìqí\„“ w˜M«ºZ3:Á.iex·§˜Ñúä@9Ö$Ÿ *xÄ‘)¦ÆîsM•Žëd{ ºžDaXòŒtÏ3"|Q¤bI e ýÍ#m§4‘Aó(5ŒDÃá<œOè~"4‰™Œãx HW Ì-Góãåg0?t8óCwuØäíÝ4>ÑŸß”ägqÈͧ”9ÂH)ˆ$xÛíî¡ÇÝFÂÓeMxB lZphJÑÈÝRe^ ü]öa‹_ôS¾)@¿¥‡ÿŒ +}FvPœØ­—Výõf,$ 4"¯÷p\ ǃÎ}UûRâkFîs ˜Öv×J_bZÁe20­?7ÞiRÜ“tÉ7wáz t9 w1†;ˆutK[8Y¥'žÛ]Ñ—‹Ÿ&ºP8¸%ÊšPÅÐýš^M÷cb7RÃ4lÉŸ‹iœš“ ™'Æ2‰éýb4é1M“ÀÔÿøãJ½M½ße絯Ô0N©‹tLç* ‹Îüh××¾Ä «û¥.¾®0 qçûÉJHys¸A5k¨;`~5+­ªù~,k©”‡¼z,@G˜`äB2ójqúIöÄ#˜áîË(.ª'?ߨ;hH2;øe(sðŽtˆßå8à` ãN¡ Cž"N0˜³èªOh©+?¨%ôxï1ÇbP§]™äjz®sw$­<;¹¥ãöú ÿ[®éÃßé¹@£˜žMüÖpƒ(×Ãð6i/(‡%þ´‰¦¡ÚP¹eaè¥^Ý~ L­®4ÀVkú¸ã¾âv­á [O}ë±5Ið=Ð?þBdX‹îîû![}ôº»ÏÍ Ñã&~Ò¥4ÃßX8)ï~¦ñÕ?÷:~†S¦Œ‘ãî.!&Æ&ñJártrá8ƒDŽ¨þ_r›Äÿendstream +endobj +1312 0 obj << +/Type /Page +/Contents 1313 0 R +/Resources 1311 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1310 0 R +>> endobj +1314 0 obj << +/D [1312 0 R /XYZ 56.6929 794.5015 null] +>> endobj +374 0 obj << +/D [1312 0 R /XYZ 56.6929 573.6377 null] +>> endobj +1061 0 obj << +/D [1312 0 R /XYZ 56.6929 551.8981 null] +>> endobj +1311 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F21 702 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1317 0 obj << +/Length 3275 +/Filter /FlateDecode +>> +stream +xÚÅ]sÛ6òÝ¿Bo'ÏD,¾?ÓÄé¹sMs©;7sm(‰²9•HU¤ìº¿¾»X€"%JN&¹¹ñŒ¹Àb±ßŸ0øã§3&½šX¯2͸ž,6Wlrcß]ñˆ3KH³>Ö·wWß¼“vâ3o„™Ü­zk¹Œ9Ç'wË_¦oþùúÃÝÍÇë™Ðlj²ë™6lúííû·ÔãéóæÇ÷ïn¿ûùãëk«¦w·?¾§î7ïn>Þ¼ss=ãNs˜/â +g&¼»ý× Aß}|ýï?^ÿv÷ýÕÍ]w–þy9“x?®~ùM–pìï¯X&½Ó“'h°Œ{/&›+¥e¦•”©g}õÓÕ¿»{£aêÿ´t™vÂŽ0PÈ9X™‰Õ>3†»kî¦ESï°(àxÜÆÞE¾Ë†:óøÝÖMSÎ×µ¬Ú:ŽÓgS4M~_dÈ €÷)ð"ƒ›ƒÓ„½7yõ<Ë«æ©Ø5»O¯{æÒGä2î¾!¢âîÅ +¿2&eQµ¯ WÈé|ßFâ⤺Z?Ôì·Ûz×KÜp2†eÎk1™qžy î5dÉYdÃ:oËÇÌO«â‰›uþXD°Ø=Â`w)l±x ~äÎ!Äptê1—ý‘«%‡1•ùLSg]=åñ6@F•óÓ»‡b„ÅÒûÌiåû,¦£v#ƒ£žg¿ô fZÇ…Võn“#W™ ®Â7_7xõLö¸øbCíÊE誛z»þs­5Èв~jh©*"~ÂA…Wá wY¬òýú@ÄÈéá:­|ñôü¥ÓÛŒYfãBc¬3m=í–Zát³È«ÓE-ÏT7e“?“-™ô­áÌ»r¹,ªØŽßœ>Û¸:1'NÍ›pÆÕöMYÝØŽJˆ&“:QWaØ#cÒõ7mÞ¸ÈìÄ䱌i°ÆÆËL)æÆM|Dšõ±ÈBñßaõYÛÌÊêxs×d·—wï°F¶H%ÀÊáöAúP­7ùŸåf¿¡FµßÌñ®Wô-«y½J ¿ê*ÎëèÍT#„yEÀ 0ª¶H…ê©¢“ +á@P!泯BˆzF…Hs€XkŽ\ÿæá“I-Zâ}Ñ´Mú. â‰÷¿:¾ÿrS¶>•ëõÐàÓš«}S,3òòwiÞÁÕA#jpØtLƒ%‰Ìsñ9*|F +µ7™R\–Â>Öy)ì°†R˜üXÕœ£6™uÞ\¦¢Ã!cpbÃ3k™ÒAæì ŒØHÂ( è +wÈÙÁœcƒd¡ž,†æEEQ±k1Odo0& °8ŽLV(!}žBøÜCZHËn궠6†ME µðñȾ/Tþ TþŒP ¥ ”âÉ/ˆ1›ykMÏ+HöI^¸åO¼ÂP,Ž'NÎÙAä„G Þ!*3ßm¢Ûà3@ãÉgp1â3`4ø ì"z~ðÂFŸeKxä°‡üt ½CoK½"¡wPÓ¿D K ¤ô.ñ”‡lxÊOe"¸XÝ‹‘t'(úpr~b¿9 ‡Ÿa*…Ÿ|&´~b×™ðSAN#<€‚ÁëåæöaGÌEÚV´Ûø3 ©£Uz¨Q_-ÒÕV·Æ¼`#{XldÂ:I"0%_§&R€-S/Ña½@×6óLÇÒ\³ÎE®-‹¶ØmJPÐL0O%&Á¦Hòi¾\ÆzCB#Ÿ(£ÑÄo´¹€ê +hR><*‚îÞ| Ô¸*mY“ ãEƒ3É8Rÿ&d¤ÚÑZð]m  À âq4Ùä@\œr°ÿÚÇìÊ%Çî†VVJ‡[H¡£òd0·_mv< lÓcЫp0vœ­zÌ´Þâáóuð*ÐŽkÛéÏo?Pæ㯨/±Áb?À7)‰»>P'„9»’È6‡=arªA¤õ–Ï`²Êï·KPÌÚ¥€C­¥ªÛáI’6R±Æ« +1còN µÂ…‰`}ðCÁ3Ápù-yÇõ:}É›˜DA/€öÍ>2KÅ {%$‰…®b·ÊqίB¨Åºnfc÷Q"r¨á¸vÌ> Æxq÷ì)à HB¤Í>­™o·E¾£Þ²Šû<ĵ†kK\û£•n2ÍMòÃÀœúiÖiþH1ÎfŠ‰d‹Iüh”©è‚eæ!—:rNR‚¾3«Ø˜T¥€LöHùP*¤™–+B¤¸KÆ¢t€Ï_”X𣠙©È´0–l7M‹ã~B2È…+á\2{‚u¡6él“)p †X‘Ý!à Éá„Žù?7ä¡cà±Çsj&üXR v„FbÑF’gFð™ DYï—ä¡; +•iñ¹áF»Ï$t(w–=•íCY]*R)›Y͛ÉOw +›¨­wcgˆ­NÄþŒ®Ã¬OìÖïïKçÀô èÝïw9)vbϺ8 R¹]1™Iãͧ<HÞ6Üøck2cÅ…µhƒµ"˜f —š%ê@…ÁÛ~Õ]òO•HëIOï{LÔâŒðºaHœþñzføôþ‹éÍ g`Q Žo"•ÉÓ!›ü1AR>Ä{l‡Ã˜:¾¹ÝˆÉÛŽ4éŸ*­<ë/ÎjØ|àˆŽYRÌŸê5šUêdCú©ÈtÆ ¤ê<EÄY—! +†že]D|ôu z8dD ;±§h[Ò=hµÆ^R*Ú,>Y{h¬®!ʉ†õÈ·Pd1ŒX\ 6ýÿ¡¥¢N„Py ™DÛ½kþ2Á4 br2;…äñS5Ⱦ§xˆÐ7ÏclZ!™¶©aé;Ì'±±ƒôŸRh`êlDҗ犾R|™žýŸ# +ÎA¼µ•—R‡uÁ)E,2ÄþýMNýRD!eà—FdViA¿$,ëû%lö^¯ 5¨8YNÙµM‰e1Ͷ¬óKû%æ2λ ø<Ž¨w*S\‰¡o +„û&0M‡ß_ ¶’Z(0ÊNXuü^{6J8&ŒëjÊ—|SŠZ¬Í„5/D6=¤ó2”NíÏåØïÝÀu_¢¤C:%e CDM93 åçð¢í’}p~ LÎõ…Éùž054\Ç°háÉISñF0qoâ’]” ý½"¶TÃq®_Äþz¬¾úb™0úJU={*Ö$E5œo®)½¥¶ƒ·Ö( +£;rÈá­ð©Ôð\Œ=W@ÀÂù•iË­ý_$ºTHØl󶜗ë²}Tžû)¡ÔþþoäÎY„|ñÏ ¿ÁT6ÛzæIÜ.(d‘‘(<§¶Ç”w¿G<%ýo +~_õendstream +endobj +1316 0 obj << +/Type /Page +/Contents 1317 0 R +/Resources 1315 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1310 0 R +>> endobj +1318 0 obj << +/D [1316 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1315 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F62 1050 0 R /F63 1053 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1321 0 obj << +/Length 3347 +/Filter /FlateDecode +>> +stream +xÚ¥ZÝsÛF÷_¡·Ò3»ß\^žÒÄɹÓ:9Ç}¸éõ–(›ITEʪ{sÿû ,EJ´L’s?@‹Åþ,%'þˉu©ËU>Ér“Z!íd¶:“;˜ûp&™f‰¦}ªŸnÎ~|¯³IžæN¹ÉÍ¢Ç˧Â{9¹™ÿž¸T¥çÀA$o?^½¿üðÛõ›óÌ$7—¯Î§ÊŠäýå/Ôúpýæ×_ß\ŸO¥·2yûÏ7Ÿn.®iÊ1Ÿ.¯ÞÑHN'˜^_¼¿¸¾¸z{qþÇÍÏg7ÝZúë•BãBþ<ûý1™Ã²>©Î½ì¡#R™çj²:3V§ÖhG–gŸÏþÕ1ì͆WÇìg¬O­2,©S-­·²L3)(32•ÞÉÎÊJŽY9R¡•×u[-§M½ÛÎÊã5K™¥÷ùžHD/H—J¦yžéÄÃ[º÷–ƒe[‡²z^¶åvU­Ëæ|ª…Iö÷Õì›6YÖ³bI£Èì\ú†©b>ý²i^Á´ŠõœHëM[Õëb¹|¤þoï>Ñ;›zÛ2ñ¾Z2ãÛ !¬Xè4³:ǵ§¹µ*(·kJäê|ÒÖôlÊ ÇeÉÕÇ›Ë÷ÿ¦ÑèQÜ• 8¦s:¹¹¯šèéÉ”»¦å©Í¦,¶Ô®Öij½/Y̲xˆÍrûP¸ô ›³¿ Úå©TÊ°=WEmFì®Ñï´bº¿ë5/݈,uƺáÒgËV*h0é–žAM­ÁÖ#z€ÆÏ{°½Ÿ’+Œèbó4Ë´eb’NµŒÆqM[´åª\·Ü-[ž@3* Á Eî"Ó¯pCg¼gêE\c<h à\¼dÇ:Ìhé4Cš{a¢ÑÈõÁ›¦*óI ;¶­æórÍýðÌ’‚º›28Å4ìl‡3U¹§Wn‹í“·ô¬Ö³ån^­ï¨[ŒØBe€hÖ¸¯·…ÈE¤îÙùï«ö¾âŒ[¬‘¥Ê€ç \(ºØ‘0eR‘åQ¬|d+eê.Œ1ÊÇ©,n÷- ÅÂû ,<ÃiÂƬ^ÿGu·Ûˆ 4ˆ#Kpº#|ô2µyn'ÎAÃå_´1Î0 +0ÖOò¢÷ðâf|cÈjµ›ZoRŸ»ìÌzÒÙ~1ñ°™WððTkŸ]õŒh‘ÁÒ"µº€_pá¯JN¢¥wi‘râ„I•09Šžü9Cgr°S êµÃZ6?^®Ôä] +šôÅŒ§}ÎaQN ¢ œXmôP&•™È‚ÊŸë%¢¨´ anž¨Ô¦’š Q2Ͳ*·42¯K¦‡ÃAf·ÙàA4à:F$žÁ=OçZ°Cã®÷ÏÂÍÛOtššzv®Dòÿ  R'>hK•Ïý¤¿Ëßç8<ÂåãL©É÷¹õTå©÷DL8ˆFiÿ| {cžÏc:ªÔš>¸“TF‹ÔJôYŸ¦2L4¢@L¤¶©×V5ø¥ú2†wöd˜Ò~%¸‚m•ŽÔ¯}BDÁ¤à” #VMOŽ›¡s ê5Ë=ÚËO`buH60Ái  ¦¬†íЗ뺬Ž”‡"„ „ ù}‚„‰Z¿TMÛD·VöŠ_…°=}0ÓÝ|3Åôj,íÈ2È âòOÕUœyIñPWó—x‚3#Í×ò ZºoÒrª4ÁÇÈîCüòæHßç¹{HwzñuSÎh{µ )<–æ…JÛ¤^Ðì«á\ÃYH³¹!JÀ6¥|t•óÎÁéší}ÑR‹’^¤ i +ŒPz‹­À3`!’¦ +fÔOÁ‘¢'c_ïè%ÄZèäsyR‡£1„l¦õ=hn{Çãº_5EòiþôŸp !¢œqØÍØÙOÀÄB$³«¾>#hÆDÏkÑÌdpT´"-ŠÛ:žùûz”¡Eµ,n—ܶÅ:ÒÔ銥9VB½,3å_Åj³,]0e;’°¨1#§¤q$% +>kún' ÓiÆÏDk‘ü—Ûb}WRS«Ìyj:kµ}Míÿ½‹Š#‡§ÏÖ‰×'",³ˆ‰8ÚŠn:¤bPuÖJ†‡CtŽpä¹8N‹ã‹°õj,c…¸ !;BÒºX•ó±Ì`¬™ŠËP'%„ + ú¡0è+GÉêpØGfiþI‹•ÑöHêU˜×9ü{E8¢À{Á%³á ‘å0¤z‰ü/ÀŒ%SÑ…  4¸Í Ú©oÀt¨¦‡^`ê3}#ôöØbý6UB +qNÅpdCîwýTƒ23Ûʼn'·ê)!biÒ¹M3»¯ë†Î!H è +£U8ï0:'ò +r•m؈ 1µ0–ß`ð‡V¨!áʤ°dÃ% >"ÇÐBL õïC!ŒcbŒ'îù³ÜÙš=Ö58.ó™Î,ÀMóšß[ôÏ“?wåöqˆTWï鈎¡7Ž!‡ +z ®ˆ€€ôÄ™nÍ¡óØ{Ë-øU?ÓG¢u³´÷õn9§—¨b€±»²ísu‡7 IÜæª4DoÂûÙÝùh«:¹0|O—B–7<Éb®¸+ª5^@I“\Õm ˜`¥b`~^6iÄÜQ±Ž6ŠeSù-OÑ+|( +ãëõzÉ’ÃVŒƒÀð.íEPÑw‡ë‰ì „˾#³ ·<´5õC5/ç1ÔsRp[̾ì‰Ã<†ýÕNàmµ¬ÚÇ#€¨¾©›¦º]òtSA^Ñ#]:±éjƒÍ¢»ÓÑ~"ŒÔ9×7%&!13ùüØ´åŠoîËXkS²ªF·ø¨(¹¹çüvxuÊ)oqdz!цDvU¬™>Š†6;|*ü>hÄz‰JQ>†‰î¬XÆÄù¡Xîâk‡,;Á‰*Oö÷%sä² 1Çú ä:UÒ>/5ÒœJí»qî.ÜPêMijćÄéï²C5Ê´b6¸ÒÙ­6 7\$”æ<½œQJâÕ¼{1,¦»|~z;$¤Fºö£Gõ̆Dª YÑOìH†aæYÁ‘hDðÑždÆÊ¡`2f.{› +´ÔÛ’‹ "“–«Ë)l·ñýîø^<ë2½…[ÊQ&T¬— ccô_‚¤¥„Ùœƒ©¦ªyb‰¿Ühù•>ïŠe—ÍÂG³ O'£jÆ3¨Že›È¢.Š ð•»x· ­$VÚÇŸ’à(oœc  ßm¹µ,CU#ûÃ2@çiHPÓ"ÆŠ:ï®>Þªf”yž|ÿ»§/û%§R˜&ê\Ъ1sT£vÛrÝ*mRïÅQÛéps„c=öÓ„Há8@ðÇË7œO@Ÿ4n‹˜“€[ØÚGj>ØLP^ñúª…édK1¨\‚2+©É—DšÍ ÔÛ¢jx2Ò¢¹íEsÏ+´bûÉ­ë’[GÓݺfú]j¡>4LJ0s‡þþÄOÄ´Mñw]#(%ºïîßýó±Ãoë ìÐÞ«q¼S$I˜°R¸Ö?ùAãTõÿ5µùÍendstream +endobj +1320 0 obj << +/Type /Page +/Contents 1321 0 R +/Resources 1319 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1310 0 R +/Annots [ 1324 0 R 1326 0 R ] +>> endobj +1324 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [442.7768 483.7823 511.2325 495.8419] +/Subtype /Link +/A << /S /GoTo /D (query_address) >> +>> endobj +1326 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [361.118 212.4953 409.8647 224.5549] +/Subtype /Link +/A << /S /GoTo /D (configuration_file_elements) >> +>> endobj +1322 0 obj << +/D [1320 0 R /XYZ 56.6929 794.5015 null] +>> endobj +378 0 obj << +/D [1320 0 R /XYZ 56.6929 540.8756 null] +>> endobj +1323 0 obj << +/D [1320 0 R /XYZ 56.6929 517.8101 null] +>> endobj +382 0 obj << +/D [1320 0 R /XYZ 56.6929 293.4989 null] +>> endobj +1325 0 obj << +/D [1320 0 R /XYZ 56.6929 267.9627 null] +>> endobj +1319 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F62 1050 0 R /F41 925 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1329 0 obj << +/Length 3260 +/Filter /FlateDecode +>> +stream +xÚ¥]sÛ6òÝ¿BoGÏT<|$8÷”䜞;iÚsÜëC¯Ù¼P¤*RqÜ_ß]ì‚"eJnç&ãp±X ì÷Rr!àŸ\X '‹,Ob#¤Y”Û+±x€¹o¯$Ó,ÑrLõöþêïïu¶Èã¯òÛÕ/¿ŠÅŽýÝ•ˆunÍâ "–y®Û«ÄèØ$ZL}õéêߣYÿêÜýmccU6sJ.P +€“t‘™·8‘È£§ª{DÈF}K˜ºÚV=£áŠm{hÙn·uÛvÿL¸CçÖ„]=Ÿ¼Ú¹ý·Ç ý2CÚ# \$°+Gì*8L¦s<&2º-¾.Ë¢|tË®ú=ЗÁj™3yѬgÖ”n ÑL³wåaßU_ÜIKmul¥Ñ‹¥”qnŒòTe]¹¦ïfvÔ*ÖÆ&¼Z»ë«¶éH?ª¦ë]±Ž_(ˆˆ…Ýͤ‰³DËyƒ`¢å˜Šä)ç "P!ÿBÕ®;Ý”1¶‰Í.ox¿s]{Ø—ÌíT›9!K•ÇɎרUmÚºnŸªæ‡öè8p®s=5-J áú°B¸Gp¦ãÉ ºtýàá’iÁ^ºÃÖïV)x‚^¢M\³iùÅ5MWMïöMQƒù1¸tô“bêg…»/½Ò/š=k +þÍgð–Û³Ve2 ð9—­jLuÞªªSª¯êeÝ>,g-,•q¶p™j†‰…¥iœ¡ŠM¹¬PŒ¹fe@XEnÕµµëÝ?®—IšD”ÇÓEYº]ï…†£fÍÓ É3Ì x=@ùÒXB”ívâXUuÕþ4ÏyO‘•BdLÕTòÌëK‹Ò2ÖB#÷ÿÀ\@“ÎÆnˆ'²=z”xÝr(-XGÀê‚UjshJº' +¶ôå}çuIÙX*™¾¢K#ª º¨ÎòT¡’Ë T3,œª¤+vÊÃ'ç=Fâ/ ƒÃÆçÊC¤ 8H¨bÖi@:ÀFtîÅqt–Bì´éä84¹Xp7:Ø@ÿÊÁ^®Kcq#G :æS~ÀÅÇ&‡ôïâõT¯pñr5Ê­ŒÄÁŠèçGÇÜO>sƒ”V*§‰É§ÆSìvÞ:[ÌiQÕ³ Ðí\Yá>›FÈÓf«£®Ý2•ºã×Úzíºž‘û¢éŠ2䤀ñf2&8ÆÁSU3´âéâз[p ¥ÏOyy—mûÅ­ÿz—"‹iò?|é!„óVUw’Hu×´BRHPš‰3ã}þïmÔ«¢«º³^#g W¢/{1Õy¯1PáaÛ®_BÖÔW\t·ƒ}é8rPA­.31PÍp1qV¦PNظÅëImð iYÔ¶L4±#ÒŽÉ`:ÊóS® á‰g£Ùãiòö}E fTnrÅë~†`†2Nuô±íÉ„R`Ú ó[PµÝÕn ky#ù‹q ÃÖØE¸,ÑÕ‰ªiQ9*'ò„ò;SPË_da šáa Jy>eb.c—G!3v˜®û¢qí¡#*²j>Õmûù°ë&Iœœä{ì=È´0x eàmÉTçS÷±rElXIì€_å;ù'Bó1ìØí¼;ÔÝæÒ°“ÀŒ}Æ“(çØ—< ÄÚè­+ êEÀâ݃ÏSîhÞè*hrST{B¬ª~|*j!L¬¼·ÃÅÈë,igRjÁÁ3±Æ[Ö’>¢• ñçªnWϽë`U­Mx/‹¾õ!,±!Ô|“EZ ^X¤/:"ç»Y¹šÊ']ÚÊ;bÜ‹ÊvD¡q#fÅãµ+é^ ß(ò‡â«PÒ¨T›éU é‚Žõ¬*Æ…&e­g¬]§"6Ö¾’õ©Î[û@å%UîÎÚ¹†ߨìòæÕÌîÓÊ<ƒíOv'ûÈÓ‘™Ã`0s€½ÂóÄÌ3è2À÷ï~ddÛ4nÈAµ"A~¯Q£löQ³(3ìÐN­ý/¤©‚#&#SžÑB uµVÙk  |šçæÁ¨.>P‘¥ø{X/»¶üìf¤r‚{1—9¨fX˜zyƒÁÚNyðW +9Ô ñD’Ärx„!+,÷Õ®o÷!¸YàO@¯ù’§P$ûßаë×U‹°É"×—à2­H9ùò[;·fmŸ+GK®ªöþ&ÖúÔǹ¦=½Ü}¢ÑÆÆ"3r²=õ[;î‚¿`á„Ï€{Õ8ï3–ÄÒ×)¸Yº¯€9í¾Ê³°L{É#Îgf E)XWèäG}H°³Ë“®@hª§Šë(­‹¾ Èë<¹S´-œVq3!•@äU¦|ºä=¡9¾:„q€9Œû),9奨XS‘ûº«BóÇ;Öÿ"hó|Ç`EiŸ$õL"ê ›èÃÝO 4 Ÿ}Ñ»‡gš â> 9‰ ‡ |ª„Y²L-¹¯%Ä(jQ¨$zCdÁ½ 'zŠé¾ò-j¼7ïŠ]õlÜ÷ÓùòÊyl²'pOC{þÁç¿€¢ös»%jV2D‹`Ûø<@O¬Fž®ÚÓ÷÷x«£T|›JGoà|gù@ôÒg÷üÄ|²sµÓã^lÎd˜„`‚×ÔQo™N’Ë‘ù6T&9UGˆÒj¹ +=íCÓU u¬¥ónÏ ¢k_ÉË]þÝ7æ,*ƒ«|‹ÓóñL 5¡­xŸè(/6´öèŠ-Cc'‹ctÄøôð•Å²»|įŽëÂR¿Ñv»vσm;(‡ JÒŠž+úd©^÷oW…Kí ÂN½ éÙ3»¶«úŠª1M— Ê„ƒ!BPUIo†8Pß¿%à ùG·€*ß’“o +°bH${^ª%4¬æ¶!LAÃàuEõb±6©vuà²rOTÑŠÁ[žk°w}ÔšR+ßïÛè2êðá±=ùðæ¨Â?@¸ñ5èÇkÍLÿgƒ©2Ö‰yåsÕ˜ê|8¨B±Iùíʃ›ë,ÉLä—9¨fX8í,I¨ TsN´ &n–ÚßÕ®ôAÏi‡ ôØ `H45_+"5¿{»™ÝÖ¾q5ÁlC½:DT“ÄJ¤zjÎT˜¢Áð/z¯8R*ÁØÊ‘sýŒš¢Ø‰õ”‚Ú¸'W]óÜcûDÀ¶hž ò?S+iZ²`.(Ú"äÍÊZº¿5áªfNáÃé•”dö>E…!H@_âÔA*Øj3øœY¹á½]ÑQÄØ > endobj +1332 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [375.4723 524.316 432.5882 536.3756] +/Subtype /Link +/A << /S /GoTo /D (journal) >> +>> endobj +1330 0 obj << +/D [1328 0 R /XYZ 85.0394 794.5015 null] +>> endobj +386 0 obj << +/D [1328 0 R /XYZ 85.0394 661.0164 null] +>> endobj +1331 0 obj << +/D [1328 0 R /XYZ 85.0394 635.6995 null] +>> endobj +1327 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1335 0 obj << +/Length 2714 +/Filter /FlateDecode +>> +stream +xÚ­]sÛ6òÝ¿B÷tÔLÄà‹_“'7uzî\œ«{jûKÄ E*"eÇ×¹ÿ~»X€%JéLn2Åb±Xì·ø„Á?>IÒ8-D1É +'Œ'“Åö†MÖ°öÓ w834 ±~˜ß¼ý ³I©H'óU@+YžóÉ|ù[”Æ"ž½ÿøðáþ§?ÞN3Íï?>Lg"aчûÞÑè§ÇÛ_~¹}œÎxžðèý?n?Íïi)u4~¸ø‘ }.}¼ûp÷x÷ðþnúÇüç›»y—ð¾œI¼È—›ßþ`“%\ûçË"O&/0a1/ +1ÙÞ¨DƉ’ÒCª›_oþÕ VíÖQùq ™Š +>&À¤ˆS)d/@žÆœƒ\cÑ'³/›e¹ ‹Î§œóH·Ÿiz_wfÿ¬«öìÞ<Î8O'™à1—B]à“f!Ö6=²¹¨Œ®Ëz=+ §p Oy~…k„ðÀes%ù‰ù¦l§3™‹¨ç‚fjVSžG+³èÊgS½°yj›ÊtSвŒ¥Ñ§=¢™ç²9´€…~3)žDÝÆЦ¨›=_šCµ¤!mÜ6ÏÍ|Ý•[¢<@Äj ˆ˜ó¸HaÙ&Œ¶9ØÁ÷&…ƒ.û]¶\ÙY³¥±ƒ…^ø¡¾^ñ°“WãY ¥ +óÅ÷:rÎc¦RîvlËúЙd”ÊÌY"XЧn^h°Õµ^›6dÌ^]€Þˆ‚û«“{Ø‚°ö¯„[ÂÔ4ÔŽ]ÞÞ,ÚfïÛ• Ý™eVmŸ–uí€Ë†Nϧ.”¥}q7õ@|y´ëmÊòìDãɾ™‰íuØð Ý™E¹zµ»Ð;«‰8jv]‰ÔU1o´Ã­úõÔÑ8î§W?pzw{ŸÌFƒÆîÑÆ—Ì?MT,ò,½nþ!Öeóï±ðþ£÷Ý“ÑÝû‡¨ 3y‡k„‰ý+3ž§C.æ(Åò^>ŠeÑKYU…gÁo üŸ¦vÈ[<׺^ZêÀŸ¶´†eaÚÁ}-Á¶zÿ5Áº±9)³XBXp´,uuØÚ pâ,É‹¡R½lLmÈÍd¹S)™¡søÑÇXÛ,.-ÍJªŽ&~wÊhØ3ìy4ºmjýT¹­@þ`Íƺ·BØ vúr/õë˜]üÎ Ü)GŠ,ñGÇè 3bÕ.é¯åö°ÅIJ‡Üš€DNs8ÇA´bR\ F÷+BlMG(È2xsÞÙšÀIp%T…ÁmÈ[Ymp†Ø:Stú€CÒ4k°‹Åáº%&y+%²ë–b]¶Ä y´Ê±Ò sÅ!¤Yr‡k„‰¡%Br£ò|Ƚ+xMo‰"=Ê  ]Ó¨óˆµé^šýgÂì/Ak¸}]ŠnB2¬Eæ,m\çá'ùYt“2·ìÛ %3Èë’l¨Ô½Yñ"µ +Š_4+ü ‰B,Øë7/2¯ßávÔoü’~ã(ÐÓo¤ú+V¿q€úä­~ƒ²µ$® ÜmhQn÷:yá#¥(¼[ :#Ñ“Á`ÑÔ¿3&Ö‡½v1¶ ¤rÖxá[5zi–À¶yt»êÌþ„òLKƘ×<¼çíɬKwj…©gcn‡¢·LÈbqðå1Þ:4©( ÅvÔæ¥rÃeÙ.šgã³6 ëÕ©¥9>ÍŽ2±çrIX +9w4Ž'UÕ¼xJO£#;yŽ¶”8tnÇB†Ç\üäIP[ÞK²éÑÐKµ]³£Ôg/>ßïMnOw>eyvþoMÎOxÑ”,_vz,Óo;½ëŠÓóXxí¶ƒëbjØ^­?Ò¼ø=Ö§õGš±6ô=H@ì¸gç>!Á•'‡]5ëµÕ–_Îß‹*LáýÕ…dð©LÎ|œÊ¥ËØ1K ‡HDvâñ|2›2tœyÿ΂¸ ·QuÜ·áëâvÂq ã6жqÛ&¹NÙ:—³7Ã49ìP³Ÿ$Ø3}±$E‘LTªb OþWÚho,‡87Úÿ“ñ8eir™íc@Ë ýŽ!©™ç²BC=Z„*Ø¿ +—< õ ”&u&Ù]~¥b&Š"ðúVåÝyàéÏÆq§ë‘s0)Ç,žöë%¥K3…ý³$SÃp¹7m;â,YÎp ÉdñWÔ[ÄÅUå¶g!ÅsåÎáæÙñTÀt·Øœv&IûÿÁžâ78äB²€ñ€I«™çɳ8“Â7Ó¨Y%3J±œ2v­ƒu~ ¿©í†Á´Å“­úar̵fIÆ£; ‚±  K³ +’ˆŠö’à‚©¼æ iw”nÛr]ÇŒ;RàK`êtͲ4–¶%ZÕCSÏj³v­8Á=y¤ >zNÁšæž$Ÿtë·ÙT\Ø´¿Üh×´%Õ¸`…P²OA¹*³´5IŸi æQ8åþHÊc‡e;VY땹Ûäå}G0t2rkyÏEÊüM³·µÍ€Jpuéº0S¿îŘšPJwŠÓŠàçm':‰n ~½,ú›Üå– ¥1g¼·è ²8„†o5è8‡;†Œ›Ã¬Íaߤp÷¥œ ç–WœòĨ—K×ÁrØî°ä‰ZÂ2P¤‘˽lJ”C˜~®{Šc®|©}1ôêSÉ@}%äš°¤Ð§å“×­KCbŽ„Ëk?øî‘ùª1uyC^Bña4æx|Ňa–B(ÿÓ^2¤º\³·ù»1™üC> ß +õnLåÿ$€ó–§ïh"‘’ý÷ëÜH‹çɱ/-„[š» L}8[nðØ‚ gôuýmkqØX5¾¦F ¬©ñ»„«A,vd± +Õ-ýt[D’ÄøX‹ŒÕ¥²JF™R \¶ÛÐ2± óua|û0щ Ø3ª¨KEe•4² ˆžM˪/ïñt§û°§t´2‚:Ñ€Êh¯ð«» ¹9þƼf_óõý/*μŠ:»;Wê£þÔNUÛ~ªR+Ï»`÷o9öƒ®Lbüv¤¦g}ÍôÝ?ö WY )¼o@åC…-=S6-gçM÷«ð9ëÿ‹aèendstream +endobj +1334 0 obj << +/Type /Page +/Contents 1335 0 R +/Resources 1333 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1310 0 R +>> endobj +1336 0 obj << +/D [1334 0 R /XYZ 56.6929 794.5015 null] +>> endobj +390 0 obj << +/D [1334 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1337 0 obj << +/D [1334 0 R /XYZ 56.6929 751.9325 null] +>> endobj +394 0 obj << +/D [1334 0 R /XYZ 56.6929 369.5823 null] +>> endobj +1338 0 obj << +/D [1334 0 R /XYZ 56.6929 344.1885 null] +>> endobj +1333 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F62 1050 0 R /F41 925 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1341 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«±Ä^¾1rüI0δß3!’¿ì1‰¢ñ=@ú6Ð÷4$>培À /š»ˆº8ЋG¢D_ãÔ4Ïâcà,ÃSléy(ªà%ÎT‰‹G~„…:þ*p曑~w÷ì(~Š…Ÿ}œS|~Üú"LùbÉ)çøqÒ:•Ï°þorc\endstream +endobj +1340 0 obj << +/Type /Page +/Contents 1341 0 R +/Resources 1339 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1346 0 R +/Annots [ 1344 0 R 1345 0 R ] +>> endobj +1344 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [242.0197 602.0286 315.2448 614.0883] +/Subtype /Link +/A << /S /GoTo /D (rrset_ordering) >> +>> endobj +1345 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 +1342 0 obj << +/D [1340 0 R /XYZ 85.0394 794.5015 null] +>> endobj +398 0 obj << +/D [1340 0 R /XYZ 85.0394 673.0194 null] +>> endobj +1343 0 obj << +/D [1340 0 R /XYZ 85.0394 649.1998 null] +>> endobj +1339 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F21 702 0 R /F41 925 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1349 0 obj << +/Length 2450 +/Filter /FlateDecode +>> +stream +xÚÅÛrÛÆõ]_ñØ ×{Çnò¤8’«L"·4;Žãˆ„,N@‚&À(Š§ÿÞ³7`q¡$Wét<–‹³gÏý’`øG!‘ÔT'™æH`"’Õö 'ŸàÝÛ3âaæhC}¿<{}ɲD#-©L–·.…°R$Y®?¤Q4 8}óîúòêí?糌§Ë«w׳98½¼úé­Þ.Îþù|1›%Húæ¯ç[^,Ü+éq|uýƒÛÑîqéââòbqqýæböqùãÙŲå%æ—`fù|öá#NÖÀög1­Dr?0"ZÓd{ÆC‚3vʳ÷goFoíÑIùŒ(“tB€”M Ph$¼2¬š»â\)–ÞUuS›%M«ÛÊÝc½9̈J‹US>8€UµÛÁÏbívEs_~u?î7eé öîØm¸!_¯ÝN]µÛr7Ñ´¹Ë·SçÛ¢‡”ñJE½¯víÁ¦2Â Ì AZÚc”ôùX6~xš`µ«·¸)ܳ®À2Ø^_r ÌàÎfTYÜ°ÜÔp\bœ~±×K2Áx ÂåQV«¼4Bý.ú <Õþ÷¿¿›âàË£ÀóÁ…îŒ{ êPÏ£­§‰À€p±¨ /‰w‡5ˆj÷É#a}$”#Í ·HþyW}I‘ne³Ù—F†R¦Þ<*û\×$w»1Ds<ì¬ÍÀëÍνÉ=Æ|Wß[Ý™w{·ÍÜÆGs¬‹ÛcéöÀìlñŒé§c|Ø{ëir˜eZÝúÃw'HŸPɾÌW–j΀j{-çly“¶Æ ¶ÊÀV—ðn¬Â¢B*ÀoРye„?!y‘ÈÀ[lÝäM±-v»r_¶ë¬@HÇÞl¬?„åž-•­Œ¢í¹È”( Z¤¨Îú&n•¦“»Gd ð«'Þë„Dpú¾ððyYWnÕLËMe¹²~8ãS:”Ù7Ã0ͨDàÕ"Î +¦LÀt/Ÿ·XD¶…ŸÇÆvŒ×Ðñ¥Ó‹M5Î Ùˆ& ¡FiÖ£ië[¨§(a3” §RÆÁµä!¼eöåùnJôaÀå%ÚÚjL8Ü$•Ê¡(Ÿç$= +Ä)5òæá<ÆèX쑆1’Y&º‹­Ò÷ÅjÂ0(E‹àMŸÖ…q‘ŒúíÛª,«ûú[qA§‹~.ø°*óºv‰ÞEA%AüE-T,0Bʘ‘˜ä¦’a/–X‹q£´"ëG@5" `†ÈI¸"cHÌ='h>4ûb‚mˆlDÒ`'¨Çµ9b%ÿD®Ƨ¸€Æ_ÀuÜçZÀ’‡xþj]móÍnäؘ I˜øóo1>Á8ÃI ì5ŹFàuºÏy—='¸§ˆ?bÃta¢=²ŠŠãͤ&4d橼¯Ø­ÍŒ¤~iüyc¼´X;Êgvs`]Üæwü‘z2z)ðÆ,(èüú_Ó¡AjØ@#Nyâ4X4´/Ú»ìË“´é˜6u‚¶Œ!NÛ¤ömòqÚ¬qF¼!a2Ed¿Œé“Ò­„ž\ó#DÇ_(åS„c†Í#ê/dsàŒ²hB,p^7`&õ¯°&>™èÅ0Ëúæ± ´•Å§Ü×î¿åå±hƒôa‚8¥ƒ`OÛ$¤ÀL·å•/U¿-¬?PA€Ã ‰gø.ã +ePw÷½÷¿;1u¸LDw.¿ '†q305çYœH°D þÍ5…ì"2Á|~‡|9(4&ÖÒœ@½f€ã¨àdØ Àk[Oò`‘—ínÿa„¨ŸÀáÐ Nÿ¨vÅTEoN•ª›‹ qåN,˜— Û¨’”êî>Êpâ´þ@è”iò„þ +**œ[ò¤©¯ÔŸˆÅÞó­þnûºÚwÑ ‹d<}Dê;/Q'užï8û +”áÄi©C¯âOH]H¤2¨mø°*7«ÿ™Ô}æo逫ãn=w«›;ÖÅÐ9®|_è§a¦éµNL‡¶o‰ï7ÍÝ “41þËb—ß”ÅÜG¹íx}>0-é>ô«4Í›>)®š_UÛýƶ• ¼Ú”ÛÂä.fÛïß··RÈË»M³±¹‚áa¿ ¯m¿ÇkçC°¹Í›ÕÝ”XÚdibŠ3ö.¡öõÑ‚þÑÂ>q"£z™¡v¶ßÍ ÿ)‹HXÖ>gß%qC;jli¦Àm5Å CÒm1™(îûÚËÊÏüŠßóí¾ty|<Ì£P…B| _¢y^èñzš÷•©ººvOÛáØÕ¹{¸"̬^™‘ò” °àWn?ºËÅÆÉñ_åÜÙÏý„‘þÜo0²ƒnLgÚÁxË–2]åǺ3·‡xúÕ Vef +7B³<šÕùÉ)ŸlÇx^Hfi„d0ù™.ìÜå¿yT]QÙÓ…ƒe$nCN°©èŸ ŠLÚ'"wúxk¨µÈDŽŒ„É1šB˜Ð¬¯€¼¼Ïêþˆøtä}$ËÙ×y;Gƒé±Ÿéã?É­‘ó.ÇÓ¹q½Ì!©uì“IÉ´N×û}‘[Rºæâa‚·vþj…¤fƒà Õ ".\RnŠúîB¡Ñä”>ïà &[ ~²à6qˆM@¶ ¾ rû}‹P‰²,êÖÐÖô °. H€¸8u)Úxâ:0$ ¦ÿ¢I—𗦣R€g`âD0„t÷può9!s­™ŠÖ–×NvãõÕ–&?TÀQ1ÏcÌ–)Ic/Ufà÷g/´ãé +Œ™3ƒ7……YŠ²ÈMp2?Lž6OW˜•“â\wãaÙ›ïpcòR·F<ƒ#ÎgwËa‚£Œ´u4^7÷­«Âf­Õ,êã~o£é.ÜŽ­qLX™AýP¬C`3s)À “˜¦ ‘:½1ä=¸5tàéÂMè€færã1;€‰ó+÷éDû¯#:5å–ÁY†C.þꨎ‚Íf[Œ °ÅÌíƒï–G STйæï½Â.Sî£<+üêŠÇ¢ƒ¶BÝÂÑݸJ‚R‚*­’؃^æ”Æû…£ùŠ*éñˆÑ÷s–i5Ý 0ÍŽ¢÷qNøsËRô¸óÚ˜ +u Ú Æ¦>àäÉV󹟟;ž¸™():]”ùâ¢,KtDyøN=&ý?o>¤Uendstream +endobj +1348 0 obj << +/Type /Page +/Contents 1349 0 R +/Resources 1347 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1346 0 R +/Annots [ 1351 0 R ] +>> endobj +1351 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [325.3322 596.1482 398.9856 608.2078] +/Subtype /Link +/A << /S /GoTo /D (the_sortlist_statement) >> +>> endobj +1350 0 obj << +/D [1348 0 R /XYZ 56.6929 794.5015 null] +>> endobj +402 0 obj << +/D [1348 0 R /XYZ 56.6929 666.7383 null] +>> endobj +1010 0 obj << +/D [1348 0 R /XYZ 56.6929 639.147 null] +>> endobj +1352 0 obj << +/D [1348 0 R /XYZ 56.6929 513.4583 null] +>> endobj +1353 0 obj << +/D [1348 0 R /XYZ 56.6929 501.5031 null] +>> endobj +406 0 obj << +/D [1348 0 R /XYZ 56.6929 101.3093 null] +>> endobj +1354 0 obj << +/D [1348 0 R /XYZ 56.6929 74.6262 null] +>> endobj +1347 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R /F62 1050 0 R /F63 1053 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1357 0 obj << +/Length 3401 +/Filter /FlateDecode +>> +stream +xÚ½]sã6î=¿Âoç̬´â—$>¦»Ù^zmö.Ioæ¦íƒb3‰fm)+Éɦ¿¾êÖ“v:sɃH$@Ðb‘À¿Xä&N”Õ‹ÌêØ$Â,VÛ“dqcߟƉR4Æúîæäý'•-llS™.nîFkåq’çbq³þeùáŸgÿ¾9¿:¤I–i|™4Y~wqù‘ –>>_~ºøþ竳ÓL/o.>_øêüÓùÕùå‡óÓHäFÀ|É+™ðéâÇsj}uöÓOgW§¿Ýüpr~Óïe¼_‘(ÜÈד_~KkØö'I¬lnÏÐIba­\lO´Q±ÑJÈæäúä?ý‚£Q?uN~Ú䱑:]DJÇy +kÌJ9‰R‹2cãTIÕKYŠ9),”ò¦Øº¨ë6ûÛ2‰µNÕb¼æåk†´‘ÒÄZfé”öµëZ¹–ËîÁaC-«ÝöÖ5¬ïèÛºU]­[Bèj®ŠÍ‘Ë‚Fp'aBó)«u¹*º²®àüU’/‚¯Ë¶¸Ý8^W+«S±¼g¬_“Ü<”Ì|A<{âT9´…Ô ÜÌåçFo<Ò‰‰½[c¤ÇmNE¾„]m·®Z»u ÔÐÉòÆo +´píîŠÝ¦£N ¯Çô¨„Í{úi’ÌÐÇó‘*àà®DBknËj×¹–H# ¨ÖÔèÛâ[¹Ým©óTlvî5v²,–VI&%òy~ÒX'bÄŽ:d'>0=ÖïL¤±•&{ÃFX¯AÀBF`£Qå5jÖ€%-­}~5ÃÀÄ ˆ@5åàæԂƒ(¤aíXïV(n©—•ëžëæ vMq‡ã¿&‰\Ñ8Œ•ÕŠæ­#È£kîêf[T+÷!–†z#Ú®¦‰-UîLæ‰1‹ª}vMÏØ@¤a3©QSõ>çž Ò‡æn4×Y0¶dÞÚ”ïl c ~xõ¶G͇z× †·o/2¶‰–ó`à«¢ªêŽ¨¸o+çÏÚË«xanP…½€E‚‚(Ôs¹Ù›¸eÔ–8øÍ {¬æ4_ÎVÓ7coÊ”ÀwÝñ®›bô¹g ê¼.¿wÔ%¥noY^wIc¬ã.©Ç +’>î‘4\*Z毓ï±fèO=ŒJ-¦ ðålÒp¤ãûÀ[0Ù4žÊÕÃdÎÈÍà8cÚßÞÐ$ϳ.«¢y!ªæcÝ–] ¦÷ä •Ž(R2÷fçuF×Y¾§2Ãý™kò0ð­+$š›å³s_„Ä2j¢’DZ¨åAý‡ÓïhöïÎó\t[¼PcUìZÆ,üFõëÎ5¥còÏ`ϵk*ê_C” ¢úï' IÏ.~|Gso­ˆ›L¦.9Q*_nê¶Ã–%‰¶¥Q n ´xëÖ%h3\]µþX±;owx`ˆ[0ôòš¾þRÁ{¿}Áßû3j‡†£¢I^ÀK½Ùy?=Ù Õ#IsåÚö¨™\Å©öu;c·³ËÛYYEM]wíalc%Àz^%ÝcÍÐV{Áš´ZL‰óÍ‘#Á²ì:Jü’ˆÈ—Z6ª–†º‡¢£–WsDþuWr$A£l¦9yº˵ݯPÍ÷¨Ö„rËF(5øš}#,V+÷>9þSÁm>–W’ƹÉ,_$ræª1±Í £ „Å `Bâd”MÌŸÉ×TîÓÏ|>_K0²‹'q|-š—ÀZܤûKE;ˆŸ€¤z¬5½A ÂÄ©„{Þ@à¬Ò„Äz9’†IA©¼Àb£úãói” +*£T.ÏD‹*8Ã…†Ë]ÊÔ'•‹¯ 'ÚZEX£¶ßí x±•‹5ìi1ÞVX9/í÷Íñ[ÌäÀÆ‘S»ôŠ–o7R#ºÍPÑ—³hÙƒ×6ƒÌRѱHÿÞ)©–´ëGCŠþ÷t(wƒh.Y¦^ @†Zƹ"u;îÍz,â•÷\Xåºì^"ïþ¡wpþ™‰³<—‹1CÏ°fø˜x6`7K!Èœ0rýèV%æ(þîËB@eƒw ÷nYx® Æ ¼ØÁMé}õŸ\E(/¯¯Ï?v^±¥ñb×Õ[Hd"rQYçR™©‹ZÁU÷·N—÷®r ‡Ð-ZþÒ‡W&·¥™wø®_ªb[®¨³{\Ã</Ø}Ù+ +Ÿ€JiÜ€¸P¨4Øܳy]N¡ÇÆOáp]ŠáVœ;pp“‚àxÇ‹hBõ«q’/ˆÿ å¾=òÝäË-o†þˆa¼œŠ¾~Ä]<™Ò¾u LÑ ÆgêõnƒñK"BPŠÍv¬”x¨Ÿ©±©«{jݺ»:°‚}Ïê µé¦¥﫧è÷I‹Ñ—†{ýÂ3UË‹;õ)Rà/š ÷ˆiÜ ´§ ò”¼éÉ&oÈ#òŽÅ{M 5â,_=ÀVp 1Þ&’®oO˜NÀ/3È'0 ƒ ÃÀlàÌÞPV_6zÃLø¡àŨǦiš÷/EEC}†ÅkXµy.û»éRf‰"}}^Œ + +±øMðFC踜Ù؈g›Ïçï:‹¥Èr¾¯Õ\ö.tl¥!ïÖ»/ŸJTWl£…ØŒO8Bm쇦Lxwߌ&ˆ÷’ú¸,ê£Q¼G€ yt|þÔ‹ÞH¡ã ‰°Ô‹+š–Ë#2ÊfSåõ•†4M†L¼¯5x¹åqfS5Š‡¥œšÊ +cI.õȾÔ#¹|$1ÿ­,ÉUxŸ>T$—”$§€ÐÀÓ¥ÖØä=jàbµk^uûDÃr@ }H(9Íè×6å¶ì«ŶÞUþÖ\XmêÕ®M|qÏXÜ“‘ìetX¦A÷oT¨» ö4Ì*LüC Ý‚H6ëÖcš’›@ÀÆmÇ°ÖAà ¶` å#UÒû„%ÔpýùŒ ƒÓ§>ñ,¬R +’©W(!$DfY6)'*É2T;áÄo7¡8ËáÞó%£Òýj¯¶ýT4e½ã¢žk³WŽŸ”.õ£¹)Ä£«¨7j@c¬ãÑ\Ž‘M:ªêµ;ÌQSÈ +r•¾ÎB5ÃÃÄß@¬Rm§LøHî!BP&Æ.BŒB:hûóâ—&Õº…³æéîÄL•7@ðן¤/ä뮨º°<|€€Âà`.±¹Ý»'½ïŠy¿“µCë¹ì&C•{¦‘ÿ:ÿß©ìÍCþÂŒ„4ÕŠ¾Þ)f«°"‹­’Ù±LµW#•ÆBgê 5a½¢Fk_‚cÑ¥<Á­g¯óÑcÍ02Ù³±Ì§| š„ +üœñÀ±ËC½áWŒ^› íµ ñûѽŸê}´8°D˜k@¯|¹Ë? •%R0j«Rj¯ö^èºðìÅÊçKÎárý*X¦ ^Õfõ‹ù~C¿x{­“7^ÏÆXÇõ«ÇÚׯîåѾŸYÈ…“ôuz¬&»Mu,29eaP-«)&Òpøåit®>Ò{¿¯°ȳJ-tPÖÐãôù! +Z|úÐâ虣+½üâ˜Ú(æÒûeQ ¬´*ÕFcQäX¡ú˜hØ(øððÎkŒ2s/«XYè fü^Ú£m¦Ä\o:ÈÉë`V¾0‹¦Ø:ŠµE¨xCà L„moë'Z„ChAGŸI +ÃXF¤ûY`Q~åA7Æ"êý"mw3E LOð¸º+²ÊÞ¨±^Q÷€ÕWŒÝ¸Ð‡‡wýcù,ØcwÍË!ndåøÃÞóÕ-ôX3{˜dåÒ¥åt7ô, +ÇÙuK¡;ršøá! èîË€%¢±Bߺ‡â©ô!šRKÊ*¼ÖÞoO£èe>ìH=È|Ýa¨Ð¼0–æˆð(š„Æ +ò½ûþç H¨êúɘåÆ+&´»¦¨Ú;~DJÌòçIb¹†O”×ĹXž¨[;JŠ,ófCÙ ¼h&ëÝÊ;¬„CŽ½ëž§÷Öœ$Z”Ãôö¥ŸD-Ääp&p$¼îÚe»)ž¯„å׳%|hA:]Ý´!céºTOÔÂg-O!`fÊfÀ‚\©=–ÛùºBªƒh3dP§ÊÂÖ#vx¬¦¯†Ç¡~ÿrâa¾*ОbgOõöP{}!x0È}ù¸Ò{'ÿk¡GrSž3Z´Ö=詤Ô̓ )¥–ËûM}ë“RŽð'F,\°v†³‡ŽÏâ¨Izp°ˆë³üÉS·»%2Õ2ykÙÛÇc¿hS&ÆŸ¡Í8™¤-þö¯Ý†Ÿê ²‘\ñVøî#m˜ò7žÚçr“Øä2›aýß9oendstream +endobj +1356 0 obj << +/Type /Page +/Contents 1357 0 R +/Resources 1355 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1346 0 R +/Annots [ 1359 0 R ] +>> endobj +1359 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [318.204 427.0782 366.911 439.1379] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update) >> +>> endobj +1358 0 obj << +/D [1356 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1355 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F62 1050 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1362 0 obj << +/Length 3826 +/Filter /FlateDecode +>> +stream +xÚ¥ZQÛ8~Ÿ_‘Ç 0ñZ’mÙ¸ÃÝît·‡Ûv¯=°»žXI|uì4¶gšýõGŠ”b;Î ‡jJ¢%Š"?‘ŒÅ"„b'A’Él¡³(ˆC/Öû›p±…±oó¬ÓjÈõýÃÍwï”^dA–Èdñ°Ì•ašŠÅCñÛ2 dp 3„Ë·?¼{ÿ㯟ÞÜêhùðþã‡Û•ŒÃå»÷ÿ¸'êÇOo~þùͧەHc±|ûÓ›_î?ÑPÂs|ÿþÃÔ“ÑãʤŸîßݺÿðöþö‡¿ßÜ?ø½ ÷+B…ùzóÛᢀmÿý& T–Æ‹gh„È2¹ØßD± +âH)×SÝ|¾ù§Ÿp0j_ÕŸ©9£@© +LEgY¼Ðq$ +†PÝÎО>|CÄñV¤K³¡G»£Î¼.†£ÝñDͮܛ–ɆŸnÆö`Öåïa( ¿û”W½iƒ ¥‰@ ‘,´LÇÙ•MÓjÈE{sFâ¸p¦¨ÛU_Vmù§™®.d¤Zd//ï¹fÖêXÈ8Hc%Ç|6U’vÊI–yñdŽ]Ù’nôòþ‡Ÿiä×~¡®Ç~ƒÊÞ˜#µ­ô–¥¬™ãÔ¡>WJ…ËÝfr™WeA,¤kbËéШ It^z…YBÔïaò{ ¤Å*Š` àƒ+!‚,ŽÉãš¾kË'“¸×Éò˜×[î|.«Š¨GîiËÊÔ]u"Ö¼øOßv¦€å +ªåƒU Œf“÷UG¯YYˆtË °Ówú¶ÏyAÚhÞ65µ7Í‘%0]WÖ[»¯ÐmHÎXÇJ&¬šGͺ©WgÁ’Ä –°`þ•d¹5ÌCLj“Ôí³9NØyÛÒp·³B7ývGCÔþbjj£ѾžóªòoåÝÜf«fý…¼msÌ·{P»ó¾C¾þÂvhýù;« ï°íM˜íbôÚÙ’Â喵ݙ£ç«‰b# …^ñø$A("ñ²Ç¹®{¼çB5ìóo×^¤àµ/®î¹f–;¼ +ÂL%ãõÉáU‘Ã#"•û~O òv¤¬Æí¸iÛ|ËÌdŠHÕùIò+;ljîC$À§C-ä phäÑ"ˆ²hl2ƒ3Uîà"FåÑ!¢ƒ9²@·‚Ø ŒÜ3è Ù©óìoÀèü úÝ2¤°ïŒ\ÎÀÁB(Ç°m‚ ,ØÆÈhlUOïm#`¾znSTX)'^2Ìøg]˜X8ÈLÍfYŒ/O”¬MùÄ ã«3´¶‹M°Cê"!À˜p>N˜øzAΘ™Œö +°Åk¥B¿lC®ëÀæ¹ØÀaŽxø•Yïéᛊ©uô²žkFŠ¾E\Æ©‹ñÙ‡vh i‚9 H4¢Y>KãâóϦq¶®‡­¹Àj°¦t G{¡ÁãvAħÁ®<ÿ+»ºœ—P{Ý•ˆ(Q¨@_È“B¨ Q·žë5).f;XIDhˆÂxÔÁ£’eKf tËvÚ™oÝŒ-õ•a†BLw|=È$Q2ÆÑç]¹†ÐDEÂz(>é´#ÀÏ„À à!XÎâ.6È/œJ€?ç¨_ÜÜKïJ:}œ·¦g‰$Ûii(“*™JËä•ê@ f9ãŠz:”kÏ5Í·iA¡ç¥2ƒX<…Rš/GÓµí­©Í1çaè>1ÛÎÌ€ŽP*ˆx‰d/øÕºÙ@Ö;.·ÅˆuìöÙ4‚gª–šÎК£ÁªÏ;9B_NärØáœ{Ë1SQzÄD Õ]BìœBÒec]8Ç–Z];›8 +²,Ô¯ (Z©”™,þÃŒU“¦¸›Q] +²«¡æffýjt¦óDÓ6û’5Ô6{Ã}· ÖÊzgÖ_X6|«Ó¦¯nÅ’ÿ‘ß>˜#jÂYFVi" 0ËlìG¨h03`×ö ØŸfTèaè«*Tè²áà`l‚¤—ïyöCw庯ÀøAÊ9½fQ Îˆau°Bí¶s— „¹±Ê†¼-­S4´«ºé¨#?l¨GîLƒó[R±”Î'ŽùóÜVÃ@)=·SCïjØŠÊ&öº7|q̉é|:üyMyµº&d¹}e¯ Åa<’’&ÝC¬K‹?òrCØ€æsÙ툵ló=SVÑDVæÉTĘ·N`·Ê°èBÆh-$žýdyê +D!dÆYòºŸE"ö–ÐÔ¸ì¶?æt‰âô¤\{J©‹ô ®Îì)¾Ã&ešWÅ©ûô8q%º¬v…a20Z!·) híÒØ=K²ÎYðGÃöB˜NnÄ¢ÏcYg•^ÚݪÔÚ<„¡+¶1d8ŽGžJóL#yk•ƒöÖ€®²^W}AY‰tæ|b Ig"ÿ7…„°ƒÐ×𔶶Wò6æa@„‘cCºrcÉ(µ· Æé©BÌ“ÄÎå­JfçI¤¿ù•Š²žä—ögã~²¿+az·”Æ’è‹aúëz˜î¹¬3T%¨¶]¹ÿÚ›ãéŽdÂ4sv|*¥TY¥‰xYLÏ5#çX“Q%vŒ…³µl‚^ˆDÌ* ±ÌXv%åÐñ9×Ml°¾‡Á}¿Ç`•Æ©B £¾Ðºß?-J8q=Áf{«Ìåpý±¥,ºZ˜§‚Ó4}K=k¸„IuÔ&·"¯ODláíšHRª%ÏùŸù˜t¬…3¯¿Î t”:ùŠPx÷Gø]aî~9i +x›ø åo¯ÍÉ!Ä-å4`ŽO†ÁÃVS” '‹ .žÔqÖks°ÅG¼aP3\ÖvAÕƒÃ`zò¢(ÑOìñ&ÂY,Bu”¸ª2r_é1hÁ…L¬ T¢º¾æÕ¸”œ $øvÍ®wX!jçJ6®`òB,¸ÝšÂ— +¸wP +•îI}R„“ß.D~Yð)$;•Wœ »@¶;ˆù +¢iVIuíšg"ödz@¡½•Víy"‹Tð$["§‡³TAê3“ Qú!^¹Ë¿×‚—¯mª§ÙJ˜‹¨šÈ•¶÷W¹ãƒ]ÕvRÅE ¶æÛÚ¸XÅÕû¸¼xwž¾˜ÖþÀKú½/º8¥ì†õ<¬÷åç Šèö›Ö‘°Ç[>4µÃ‹dy¾péÈ¡‹Å€.çÔ?2åÏÎF* éF±ÊáÝ-(ŠÎNy…ãênÅ •Áapâl0ȳßÍm×€€•%ÂËgÅN{8ØgZ0¸±±Ä§ä Ãþé¥Í±ñÈÃUóÌé]A6ï†R@½ïlR ¸Ã`ÓÊg§ØçeÍ1æ´ðZ“‹³ÎºI@Jß]½/u œ!Ñ5†&ÚPÇŸ4McmÔÞnµ·üaéÛMPó{UI #–ºë‘¯D³¾²ötܨ»„Ðê¯`q<Í‚8I'0>p¹p½q]¨W\W¯€ÐO%‰_@¦å¿0 +¤òA>ê(’)) ´³†Èž#-YÏ–ç¬glº9jûž^ö«,ìzlzÔ’\ +¢÷óšXËý¡±E_Ë|š‹R…ˆ¡eÓƒLG“"³Á`Î4 —ÈBð‚&2¤†î‘Àßí +ƒpù}_VÝÊe>þ²¥V>¹°äŒ!GB-¤ÎÎzUéy2•Š%ÕD›§²°p‹£6`@jgªÃ¦¯ˆ±(ómÝʯip$vŒ~?Æ7rêw…]¶øžâÏ"nsØ"ù-¸Gé¡ +WØ¡5}Ѭºæ°²õ‡UÑà 0W&Q2HbíÐü±¬‹ùª¬ÔÂEÉV$¥¯•#àzð…Ÿ·?½ùøyfBˆ‰³ÔGÕ68ÇB3 ç88¿Û2æÕ¾Œ»ËQVU”Ëcs 1hQÞŽÃW~¯pŽ-€ˆ´zíç +ÿåÓÿÒ_/fýX!Ef­XªKÔˆT:g5˜ë).g¤/ ƒõuxò¢Ñ)*,Ö§É+Ç\©ð…@W‚…i)DÇ”ËF=†.5^ïx´-5ÚÞª ÓXí›»ÛEÊÔ¹[^A”wõ:‡•UèymÁ6K¹` „+ØfîC¥ÌÞÞ-“Ö{À©"flˆ }§¦'bclQ2KÝ«zYSº€]¼RQ¶ùc5šÙWÌ…Ò“:›+Ñ©$]öÖ…#÷A^I ++x¶ß=Xvª¸aÿÎ~¡0zÏ»ôÌùÃ'“¾5X×zX¹¢™O´h©¢¬í}ˆýyMOóíP•kOC˽æ@Ï5³„´9tšM‚šPˆÌAëùã¸5Ö;Ÿ)»ÀÒ'þWâÁW¨—ÃÓõhÇ1Y¥Çšzºh†Õó—×d–Ë%'?˜EJ«Ñ’N¤~mÛè\¯÷?¤]î4ÿ†Ù;~»Ì‰à‡ ðuÊÑÎ`N›×_ÞRCœ¦”ƒB–'¸rSjü¦Óÿ¢À©1®r:˜+¿‘)Æ>üûaÀTñ‹¿ýÊó5:ç(^ñò5,×A"ý•ŒQ]&9âü›vFŸÏà³s£üMIE-dØð‘ ÐÖu2WrBŠÏQG¸ †tÜ~«°9ñ×ÓK)„02Õ“£àuæKÛG»¨x V mì^ß­!ÖåªÆÌg,¾èp%ŠPhų^.Ü)ýß_ŸƒH*M¯ä ø©L”Â$,”£KÐàO‘/Eÿ/²Wendstream +endobj +1361 0 obj << +/Type /Page +/Contents 1362 0 R +/Resources 1360 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1346 0 R +/Annots [ 1364 0 R 1369 0 R ] +>> endobj +1364 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [324.9335 578.0115 381.8296 590.0711] +/Subtype /Link +/A << /S /GoTo /D (zonefile_format) >> +>> endobj +1369 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 152.6674 116.59 164.7271] +/Subtype /Link +/A << /S /GoTo /D (view_statement_grammar) >> +>> endobj +1363 0 obj << +/D [1361 0 R /XYZ 56.6929 794.5015 null] +>> endobj +410 0 obj << +/D [1361 0 R /XYZ 56.6929 226.773 null] +>> endobj +1368 0 obj << +/D [1361 0 R /XYZ 56.6929 199.6254 null] +>> endobj +1360 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F11 1367 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1374 0 obj << +/Length 2801 +/Filter /FlateDecode +>> +stream +xÚ½ZÝoã6Ï_aôå Vù!ê£÷”Ý$=]ï^’;×íƒbËkaɵ䤾¿þf8¤D)²œEC`h4ÎÌoHÉQøŒÁŸÅÊg2 fQøŠq5[=]°Ùhûé‚™¹š»Rï.~¸•Ñ,ñ“P„³‡£+öYóÙÃú7ïý?®>=ÜÜ]Î…b^è_ÎUȼw‹å5qz¼ÿ¸¼]üô¯»«Ë(ð—ľ»¹½¹»Y¾¿¹œóXqè/Œ†n¿ÜõÓÝÕ‡Ww—¿?ü|qóÐbqñr&È¿ýÎfk€ýóóe«Ù ¼0Ÿ'‰˜=]Jú*ÒrŠ‹û‹¶ +VÝu,~Š}%‚p6W`5Œ‚ñ(3Ÿ)ˆÚ< +@— xeÁÇ¢l¥0ÊÛªnÊô)Âå"ñ%—3Wå+ÃVhÄ°t sø" –¶< ;ô[cÙu¶Îö†ÞV‡btäí/yìe»jßPÛsža²ý‘Èj3Ði‘þp¸‘1÷ƒ(L•ÿ1/×$ÞÃñ–¡‘}É›­1rÜݽ¨Ïeú0!Jœû‰R‚Ðÿú0¢™)•Qýý%ôUÞªHëzD±d~"`"2»Z>Þh”‘Š82R>©|Øæ5R¡·Î6é¡hjâ7•yb¼°¹dc8få=¥«m^:²yùe b{wã‰ÜT‚™ûAØÈмØT‡‡:ˆ¼GÇ 6ãŒ/Yc]ú̃'‰Í¡\5yU"@–˜¹vûü)ÕÓ_û]UgÔCÏ `Ö‡Õ–88qò¬&vnžlÌ×YÙä£ée›Û^ ¡°þðâ\?¾èÉZvôªmÂ3-«´nè…â‚æXLfQbÕÒ¢8Zùú|Ãàâë±:ì‰2.j‘„Þý.[‹(72]`n‰X¨Á'=eUf™=‘ô#Ì,Ôg×éc‘™±“‰ôYÀÂ>ð!^euMþBFÕ°áIÃDëö0ÇšD†Ü!ãÓÙΕ:íZ)ôÎÌAðpž¯_§<å ‹ió­Ôˆý~Òc¾‰ê;@3Ž¼Å5=ËhÓÒ6ÝŃtãÔËJ·e•åÏi`¥ôXÒÀuïh]è)ü™1a9¸†–÷‹k³Ž€CÉ“sŽÙG$‘Wí­f=è@a†ê¹É¸<áz¨yb†'2.¦PÅíd\\û÷7wÿ¾¹™‚Jùaª^ºEÅ'Òm›jÙ|÷¶,‹êNeYá$[– »,‹*(¬KBÈm“¶P¸¸IBȱIˆ¢ÂÆ$a?AêÜÍekxv© ßLjBRçkx¦ôp’Q¯Õ&#|i“‘Vlž]2"ù6á+%#¤ºd„g’Ñ [ö—%d–ètF +`õ³WI÷æäi”‰YgHt^FJL{)8L¦vïqÒ&Ñ1G˜·"i§mQP—Uz¨3“@c ‰!äýX >\ú‚ÑÞ#¸wÐ{–° '{C{Z×îœ@êšÚã;'vrwNfô4'ƒ±Dq?âq2—ׄðÀçck ‘±]b8ð#Z„€4Äí +9hàS"‚ÈÂrÄŠâÉŸÃ ,‚õÅà»C^4ó¼¤èæi׉ü®G,3\‡~D4>K©¤·ÅÀKxu¥9Àzlµã[FÚQä¿Z»æbüï?^?-²å==MV¯ôsm TeqÄ!ƒA +…¤ÚLIž^6˜­ÖšmÚ/iW9­”ÕþÉœ6àñ˜Ñ“ºV¿&NQ­¬˜"Ï‘kCIè¡çÐtY5}å5ä,¢ô,OÌ‘‹²ÉöeÖüÍè¡Um˜ …YN_8]{€(Eª‡>¸Õ­òVžÒ9gÉ õø«ŠvH‰±ÒqEJ½KW™é@qhû’Ú—¿^üpµXÒµÖ»ª¬©ƒ$XÐÑÑ٥ɀI»tßä«ùظ +^¸¦â^‹VU¤Z§#7 È Äh-| iv ?]¯Ãä-°6ä'z»»}O]`oŠM=Ú]›ò¤„íaŽF¬¨+êš—«â°ÎÆ`‘ÇR <–¼ç1´“ÇÀ_|z‰¥§ 1Ô† «›¢(Á—2[ãÒÁÊ°ÕĽ"/¿NéÌjÓŸÛ÷¢ÚÍÇ&ÞcºúJé¤ï2tÝc°ÑÔ¡üZV/å«ž~kïIÜË@B$f_A*mÌ6èžÝ8Èá°’žô _󑥇ÎUÔA§C`aÞ02ù®ÄÈþÌë¦&š†…ÑmEèÛJþl:â Ðì´‰M;Ë7ªý %®õSÛØ$qdÚ‹Ä:ƒcÚ>ÅíÊl`n\M0€¢lÄÊ€hLÄSzd]Ö7ˆ•‰žÔöNël0î)%{²Pš.E^7ýKÏÀ–™ yýã©S–x̃邚+¥/@:;*±tt¡×Ÿl‚Ã;  SM[m¥^›í¬ÐAØ7ËüÅr~u}}ç_Ý}ºL„wu +¹·ãXÊiä®Ôiä­ÔYä“V;ä¯ÌŽ"ï™åpyx3v¸©Xñ3Ø© ìVê<ö)«ö¡Ùqì®Y¡ –ÉÛñã-9“3ø© üVê<þ)«þ¡Ùqü®YácÑW¼¹/Žã3ø© üVê<þ)«þ¡Ùqü®Y¡°LÒýÞ}Ðgá™88Rq°Rçã0eÕ‰ÃÐìx\³Ìÿk‹Oáù˜1éËDœÙ1\©‰˜Y©ó1›²êÄlhvÅ!õ”–¦ÊÝÖ©/}…Ñë̵ NaÊËÍ>­›ýeìVÍ¡°ˆ;õ[x1µLS1$Rp"Þ•I¡Ïî’{XÄÅõIï¾">yìvÚ@tl÷ÔPuºÚçNyèÄKæúWfÙZO ÔQ3[ÆÚÕÑ®Jq!nӲ̊‘Oå¦|TT©é’¾¤†çä4·×©0BS[??u™€£Åx1~f¤þòÿ>9u¬È—q,Æ÷< {],’È:¥¿ç¨¡çJƾŠE4âúÿx``endstream +endobj +1373 0 obj << +/Type /Page +/Contents 1374 0 R +/Resources 1372 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1346 0 R +>> endobj +1375 0 obj << +/D [1373 0 R /XYZ 85.0394 794.5015 null] +>> endobj +414 0 obj << +/D [1373 0 R /XYZ 85.0394 592.2428 null] +>> endobj +1376 0 obj << +/D [1373 0 R /XYZ 85.0394 565.4551 null] +>> endobj +1372 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1379 0 obj << +/Length 3229 +/Filter /FlateDecode +>> +stream +xÚ¥ZÝsÛ6÷_¡·£f"Ÿ$ñ˜6NëNëÜ9îô¡í-Qç$R);Î_ ì‚%ZI®“™\,‹Ýß~²˜qø'f&e©•v–YÍ f¶Ü]ñÙ#Ìýx%ˆg˜1×÷÷Wß½WÙÌ2›Êtv¿ŽdåŒç¹˜Ý¯þHR&Ù$ð䇷ïo~üíîí<ÓÉý͇ÛùBž¼¿ùåG?Þ½ýõ×·wó…ÈH~øéí¿ï¯ïp*%ßßܾCŠÅÇ+Bï®ß_ß]ßþp=ÿëþç«ëû~/ñ~Wn#_ýñŸ­`Û?_q¦lnfÏð™°VÎvWÚ(f´R²½úxõŸ^`4ë?²_ϳÐ9“d|ͲB2kž^–Ï9ÍôYøY4 _ŒE îMSÉ2Ž î•j&³ÆHç_˜U™Hg™RŒ;¸÷ÖØ3ZfR-ŸàÌ( Š{ŽóE*’{ø_&gî‘<“Ù,ÍsfEîžý=ŒkkòDc¿ÓÁžðÝÍNÎÞ5°ŸY´¥ w ö;JeXÀ)0e³Œg,7wt¿)CYžÊbëF6Ù‡²îÚ–‡ùBñäi.MRZ¤®ç@jÈÞmÊ–d|ž “4uIlí¦9nWȵªÚâa.y²%Þb»ÅA¹Ûw/Ⱦljc½*8„5œ-zò½¦y›gþXìçÆ»pŒ`*SÉû~#9.âd +shšnJ„¼)ËỪE&|f´7 ø«- ©j|†-ë`2¯Õh“‚…&€˜hö]ÕÔ8^5J|ÀÖi‘q&3cÇźn‹WûŠ®Ú9 ±é­ïj©å)xIAîÑÙpúJ&r8ÔpΓ·«Uå4*ZËePÎ2ÅrSÕQG„C$A +Ôù¡EUÚ$E$Ni ŽÄ¹É%ˆ+!'¨Ôõ–mƒ,K€5lí|"‡$#jÛ ÿù„. +V–åÄFò½½B5®RÕ]y µHœè$U»½w`óD[éúµÝ7uKSІ­1‹.ÐqRhÆ9ô-#ÏíŠzYbÛܬ]^í‹@±6O~ÇäsÎvŒ{o©7ŸûbIÞð3Ž³Å!…òìV£ðê»vÄ‚dfñËmšC·X»©&×·¡2£JƒØ×R摲0éŠ6þðâ[7(Ad.êö¹$êÝÃÁmÓ•a‘¢›€Dƒ1_‚„k ácÏ)LºE›M³ÂÔ®\nŠºjwÔ Á9ÌrטÆ~õÎ4£³?Uº¢^‹aÝPFm‹.D±7gÜ+½»ýˆƒA!WM©Ctãõ±öÎ p\Ô9V8Uf£È‹¡£ÀË«ÆþÙkççaÓ%Ž÷™=ŽÈ€z¿º÷?¹áå§e¹ïN>½»kËŽ¡v£<  îóWŽŒ#\©>‡8+‡²Éå¶y „ŸÈ’‡c‡˜VÕIH»´µ: iGÁ ·.ÂkŸyAb·}™ !ü©”›ä†Öò~n8ævÕò¸-À7ºOÇaö‹]ÞáŸ,šÃ +#8Á¬ÎáLÙ7eîÒ "¸žqDJ¿<9Jø©ÍQè+Ì¥T²ÁÇQB{'ðøê>"Oº¡o Eà> endobj +1380 0 obj << +/D [1378 0 R /XYZ 56.6929 794.5015 null] +>> endobj +418 0 obj << +/D [1378 0 R /XYZ 56.6929 489.6987 null] +>> endobj +985 0 obj << +/D [1378 0 R /XYZ 56.6929 463.7183 null] +>> endobj +1377 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F21 702 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1383 0 obj << +/Length 2832 +/Filter /FlateDecode +>> +stream +xÚµ]sÛ6òÝ¿Bo'ß„(>I }JS'uçšæRwî!õdh +²9•H•¤œøîúßoø!ѱ]÷Fø^ì.ö›b +?¶ÐŠPaä"3’(ÊԢ؞ÐÅ5¬½9aaO7%ã]ß^œ|õZd CLÊÓÅÅzKª5[\¬>,_}ÿòÝÅÙûÓ„+ºLÉi¢Rºüöüíw8c°yõÓÛ×ço~yÿò4“Ë‹óŸÞâôû³×gïÏÞ¾:;M˜V ÎóឯÏÿq†½7ï_þøãË÷§—?œœ]ô´ŒéeT8B~?ùpI+ û‡J„Ñjñ ”0cøb{"• J +g6'?Ÿü³8ZõGçø'•&ŠËt‘(N4MÙ<—)¡ +¸–d’‘Ô(Ùs™³9.Ç]ŽËÛüs’yqc“¶ü·=¤š4Sl1}„@¿k1€¥0MP¸¸±§‰ ÂáRn÷[äÛz_uد×aƒÝÖÍöË +Û«»Î¶Øíjl÷m¸®›°¯hmskaÞþoáRÒ!S³ü×­†#À ༠ŒQaƈQ +…3bÇ•ôعv•w9ön®õ׺Þýæ”é¥uã6î*CoSnËî…ë«álDÙõ?•› öŠÍÃ-À2\u}ö-oíæ.©ã]y7àæ裑0î ó(¸l‰XñeU‡ û¹°veWÀ+Áäò¼Âé›Oxv78»Ýoºr·±8º-í§öî ²ñ•ùn·)‘/à.oò.ÐÀýóºùþàÀUîa†ÇfÔjwó©áK;E™só+»ÎEÅä«×r¬6 +Î8Àv Yú#nšJvFŒà:ì!aèODfí´,GJA™…"ŒKDÑY&–™¢”.Û.ïʶ+‹6)nòª²›1ûìÖVÑ7M¾ÝæÍ ¶À.‰‘™ðÐg¦pÓ<»ílÊ´¸£¬l‡½_©¢an÷1_­üA00c ÏƒdR(âïa ŽÃÓá–]Ýt=ìap6å›Mý)bœ0­C„ûã6 .,üŽ~Axõe\ 5â !禬Aµÿ㛹—žË  ‘Ëê'¾èwöWJyUve]áL^­°óK›_Û™ëŸz0£¹‘`’i‘ÁœÃæ°N9>ŒƒÂ›¯pßÕδw-Üý|µ-+@²É“ðT­ôÁ vu8‰v.¯màe^ ÓÅò ê8‡m>°­8Ö….«|zÁ²Ï ½‘qÒ‘êÀxo)Y:f•–Ug«UXóˆ°Ì3Áá¹…ý\^mìx`ìw¨n0²ž0:`´›Úù—¨»º¨7m¼5ô„Àë}·Çs–—Ã;ì;\)p>™šNu@Ç÷‡Æ]x‰«Þ +û‰5¶˜|:×裟wÂ>DÒÃP²N€R-—.Y©q-žÂ[F@Q +‚­3ÉÐèšhÖ}¢ìü±¸¦†è,»ß²¢O‘µdššŠgKk1ƒ<–VO@͆›¿,­ +žøiå2‹[¾þzÎKFŽ<—[¢ŒSWx"É*„ž!œÃüÊÁü¾8Ü£ét/ˮ竮Ü;ôb¤r˜ÕFÂѯœËªdn2¥&(©¼WI1Y–.F» †]Ušw6Ù¯vøñÍOUûíUdí#nwðž kòª]Û¦}ìi6w:Árêჺ² lødûoéê.Ì·ý6½ôK8ÿfïúï¾qæÈ…P#î_!„\ýãÉ|Jœ•+ì@i¹“Ç_E2CÏÔql=MEŽ>‡\Îàç>iCڣؗ_ñL\z8 š£j2ÂS¯ ‡pƨª?‡*§‚p‘™Y–‚å+×wc(¤|¢¹ûªžÇÐL!Í#°|˜ÃÛü?^r'®?KDÁ”5Sn†…ú>ü5CìÊ2÷òi_ó.ïù¨7¹l˜¬™óˆòÉ—My"\ñ0UröñÆ<éßîélÆýécNúâ;̾êsØ¢ž|Ù”-.…•F³Y¶@xָ˓]íªíöÓ?=Ÿ¸ÞćŒAÌý“÷÷—™?”ÐþýŸý/›á/H ˆÖ|þŸ)‚¦DC"‘òASvT˜€dV9í;Fý˜°Mendstream +endobj +1382 0 obj << +/Type /Page +/Contents 1383 0 R +/Resources 1381 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1388 0 R +>> endobj +1384 0 obj << +/D [1382 0 R /XYZ 85.0394 794.5015 null] +>> endobj +422 0 obj << +/D [1382 0 R /XYZ 85.0394 690.4757 null] +>> endobj +1385 0 obj << +/D [1382 0 R /XYZ 85.0394 663.4801 null] +>> endobj +426 0 obj << +/D [1382 0 R /XYZ 85.0394 582.7428 null] +>> endobj +1386 0 obj << +/D [1382 0 R /XYZ 85.0394 552.623 null] +>> endobj +430 0 obj << +/D [1382 0 R /XYZ 85.0394 310.6261 null] +>> endobj +1387 0 obj << +/D [1382 0 R /XYZ 85.0394 286.2805 null] +>> endobj +1381 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1391 0 obj << +/Length 3884 +/Filter /FlateDecode +>> +stream +xÚ¥Ërã6òî¯ðQ®1x$P9M2ž¬S›IvÆÙG%9P%s‡"‘²G©Úßntƒ/ÓcOR:hF£ß ¼ð“—&‰§ÜeêâÈi.×û q¹ƒ±ï.$ÏY†IËá¬on/¾z«ÓK¹D%—·Û. kååíæ—E©è +0ˆÅ·?¾{{óÝÏï__¥ñâöæÇwWKeÄâíÍ߯©õÝû×?üðúýÕRZ#ßþíõO·×ïi(aßܼ{CGO }ýöúýõ»o¯¯~»ýþâú¶;Ëð¼Rh<Èï¿ü&.7pìï/D¤5—БtN]î/b£#k åŇ‹t£~é,ÿ¤ˆ”NÔ c9` Q"Uj\”h¥=¹Z&B,~?åÇó¡>¶ËC]—Ë¢jóã}VÒ`uÚ¯òã×Ôù Ï|¹T:rRÄ—K)#gŒòÈþ÷5~õVÉ˼"—±‹L*’îÊ”€k€­mò#qõC›µù>¯Zê¾ÉBUE[ÔA²jCŸ›l—óVzpBØI%‘ˆeìwº½Ë;zúIÒF‰Z„ŸÃ<Æ¥€I)ÜOÐ&äbC´å u×wÙ1[ËŠ¦-Ö lkú_åôŸ5M½.͆úE{Ç#ôw¼’v‘ïëÖ/P‹*ÛóR&dU9½¸ÙŽVh)Òô‰Ö–ù•\T;ØÁßVl#mœ ·EºS ¡°òukóÍ+„˜E{—#˵òÀ”cVírjÖ[^åijhZ@µ®‘N¤e”j/~¬Ê3Rjìë¦ì¼&44 ª2;5¼";Ê"ç=ÿ.óÿ›2o˜ Ï*Æ"I»‚ÌÔ4?[QÑ4”Í¥)_9²­ëj;# Bij,OˆËRê(5 +ÙŒ2&“ÏI¡C…ŽŸ“BzŸÊ)LõbUÔ¨×ëÓ‘šѹAbÚú@2¿ÏKž¿MLu…×°;3V7"¤ä 5£/ª¦Ø0ælæXZšHí˜àû"˜Ó­8²óºC¡Ä¤Ždû ôKm]dE%ùémRÇÌ3)¹Íà8س‹ºÊ ì +€=ÉËìÕÅ"²©yÉÝ©X>Ú¾A%3¶ôš{µwuÃÛ£¤hM –`K§¤Yd-4Î<©>,é‚I‰¬tcU¨½½Ò„„Ïæ5´ØUu¯³q*ü øi4á¾[‚[c§gΨê9þ¤)˜NpVÏó'qVÍñG˔Ά›ŒÎ6ÝKÆ‘²±ú³{Íð¬Î†Á qSƒ]ó)ÇìÜäÛìT¶MÔ™¯ôÆzÆfq®OÔØ GßkïPOuœx`hû±,!¶Ñ¸âÿ®¸/ªµë¯_eÞ k3ä\âûìø±›Y´ôŸ1–U½;qó¡(Kj±¹÷Úh·§#ÈÝq΢b¨@ÆÌ( )˜S¯½Rxkç!Ìê@(q +vx;«R62 ×|?Dãì-Ê$ ³Šfxm©ƒiéÄSD&‚–ž˜n@©_bº•ˆâ¸ïñ¾“¸,>mçÏÀÁv N íÜ&oÑW.öé%€îrÏußñz¯S»(ë5Fbë¸êØ QÝ4 ú†ùû¬i“d¸g˜B×Ü`ÛmˆßÔÇ!AEÌH]$‰£k/ª5 )‰§G$‹?¼ÝÄV !B³õ´ ƒ©~Ç@zl$ìÐJKG†àevŸ#H ^²×Ò&$rqš²¹B4-ï9g•4„¿iÓ9Ÿ“/0&.îœï<=8™0°©Rnì‡z& ¯$¶«TQR3//žŒÊïÊCÝ4ŪÌ#ºÈvÓþ`ˆgö`J§ô‹øå2Ðg%‡솻õ(:PãÀÔÓs¼ŸRó!!l­«%çöKúú9AÂKT’ÎjSXÝRt:!+Íš§·óÁUj"#{¡Š‚»2:ès}à°U¿ Q@.Ørœÿ»²^¡6x˜_ÚPgjû‘Ñ0È{Ξ4X27IŸ26ªÙÈ‚Îú—'ƒÊØêà厤.OÛD®—‰.ܶŠ,›%eeo–py!ƒYBØH•ëÍÎ󧲔Jà\Vje]«†êM«fµ®5ÎŒ¹F6H¥ÉXŽÍbKÚ¶çA’f ÂÆ‚m&ç`ša^oQQ3mš™°´ú•í«!`,H+ŒÖÛž†Ë«Îi=m61¤°l¾!愘Èé'¡F +ŽuE/Ãëd:A†ÑÁ3ˆ¢#/¥/—Ö›¿ÅJ‹Ž'fÔ€¬ Œ òɘã#Þð0qçX§ Ñ1‹À²S[ï!é¤Ô3^lÉÔAk•ù ö} ("jÞÞqòºå€Ø§Ã^ýûd`QêëÐî¿]T¹g@h ǪS ¼yAÙ/zûb}GÍÁáíð„®;¡ã Æë(¤ÇÖ&l_·_C+憺ëÕv•áê¹P,Ö±8g>ë(—ݬ/š»úT"•„fåCvn¨ýP?¢æ$ LJ;œŽJ{G +’¸§Ì¹UQ¬µy±9S‚DäÚ¬¡4q§DÏk\êÜÈNò¹ +þ÷7íïþ@ÖGÝþ”ìÑ»y=@– :“Ž£H2šjÃíA£³Êäò:™‡VN†ÌjŽ·pÖªöU%€±Ñòm’hxëK3á$Åž7«y´“<èäåb[3–üS¶ÇÐ1ÐX0Ed€­îHäkœªJ/僲:ívçI}o}Ìš»b+µ®Ç+»8ZÀŒ‡Z||h1s&kb”ž©ËØX[œoªæ‰ÂBÜÉcÔûúRï:1‰í#zi9hˆèÖ%zÐæ8sßòÓCËËjúçMÒÅõ›wxÅÙËûý©£ç/ùr*£ÇBÆUGLÝ‚CyA#ÆÕƧsºÙôK&i$”Œ¿ ̘*Oî‹2°¤«Šá%-O›Ã²)þ˜« +I.±nâ1!@¯÷d¹8‰ æ-´~~óy´Äi»%é±l¬j *|u&¸/ˆïÈr‘Ò5ÞÒŸÜZ°nÉXUF)’tã;1ø畃ð¤,64–¾šF*‚’¹P AVç–ÄÔ-~F QÔ§–ê|8ØÞ æ20YVM ±(!TC7ç‰Øü÷ög˜e46’o–ê¢¿í²¾=•c”«)ÀÓ¢¹£A¬XôÑ<#ðl0c˜ʣð {´óÇš1q$$qWÎ$͘ºŽœa„¼‘Ž¿"Ø66oVËüÕÔ–õaÇÈ ±ÍÃê, ?PtƒCísª]„GXCCŒÁEíÐ+IŠv#D¾ +ÿeÆ4MgÍÛgŸ>«¦`®t—tB!uPS©ƒEçö©ØŸöØQ=Ô¬³8ž7þˆÖ“C+¨¥Ô±Åì¥ò•O7Ñ*´Š´4Ž´5íTM)Eª¦¿ü€T !¬jªuª†ƒ$/.äÐVñS@zUCèXÕ–ZHV.>$Š_ià?(Ž³¸ô‘$“ž~¬ê‡©È|¹dþyqceés9èÑÓÌSrÖµ¯Qè>¬ñ&r‹‡šÀ\¼²zX¼ÂÀ \v½9_¦Áù!Ø« hÆ¥¢aÞï>ÌV¢ŠLªL_Š‰¥¯ €Eb;²Ø ¥:.Ë‚™Õ‘L¥œóM}òµ<ãٚÁ&ºSwÅÿV&ÒÂt +\ù`sn=?ÖÅèg5´µÏa»==VtÄ|žÄÉâaÅŠ¸éqƒæŽ°”_åÌXªŸ? +Äë}Ù'TÝ“ô$‰Øñ—(#ZïòK¬ËãdZ¤Â+@P‘*zêc.™AÿTm€Ž¶®7 ?œ¿Gˆcü=ÄFŸFa3L?díú.”˜ø#ÙÀ蛲{,/b´Žÿ„[—Eä>qñâ?h +½¿…ÿÒˆ ÿb»=S‡Q_sö:CmïNÓ¯BÃ{:ldŒ$è&âàê³}ª8v×Ä*ÜE§©Àû%à…D.=íVÀ¼-DSo}qu&ùÅš˜ø²ÍR Û½2úB8ªW`ð<~]×*~â Öa´þvlD$øXTŠ'öK5hvÜíì›Ki×ñðˆŠ[x×Äqé$|b°Ê'IØ„ˆ‰õî xéˆÁnje‡:™v娔.@Êbï“ï4„Aiø€…æQ-ÓÉj}:öa!ŠjUŸ¼6A'Ô帮8òEÃMFüÇeã<ŠÞU)1㣌„sþ)L—ê¾x†=žØi5wàp'Ÿy ÃÄÀ³áìœÙ:˜äÎY‡G¿yÁRõõ’ŽæåÅyVÊÒ8R±çhQx}•‘pþõõÙ8l- +üú˜ŸŸÈÞHÔ4{!ûØ€(‚Ì}„`u÷´Â&Ó¯À”€{u  RËT½ä;09kíüW`ËãrˆÒâ59?˜p›$ýÎ^Y6sI¸ŠlMღ Û›Žø©z¸«Í„S& ´MÌš@~bòû0ãùÍZä+pk|GðY@Œ9è+~ŠÐžùÅÀNMQ0¾¾ýpóÝ«é­@š_¦¹È&HCÇÝ%5Þ>ª ³—ƒéÄïá)§8‘€y Ú¦àQÍ”©“(M3$äÑ7}ݤÏïÿs@Òî¡ô,Ú¬äOð9«æ +mÓqµÁ&cË•B6ÿ/F”zÞ­à÷Ío\´´j?¿ ¾=· >¸P–WšN‹!¸§q“= VvUÖžºr‡éJh†E þwy•é«;ìžbƒ é<,B &„# +€>ÏÁž´|ãp€œ1LjñD#”®H—‰N¯ç«ñ“—/t»¢ÊÚÎÎŽ“žçêu#óMÏ%¦7/8Ê[ðUWØUaluûdÈ,\Ìf\¯KˆüN;âbÁDbcwÌö{Hê|}nsr„Ø$ÏXm ùè¹±B’Y?4ÔöæûSÙ‡’§ NLµ4~éUÂ}îÓF™L¥ú+eþb»àj€Lâ(}ô…Õ  (™‹œ{rø3÷­°6ø¸1gD÷í_þŽ¸ÿÈ:†xÎZ5oOTjñY¢ü÷ºöåáƒãǤÿC_ý¢endstream +endobj +1390 0 obj << +/Type /Page +/Contents 1391 0 R +/Resources 1389 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1388 0 R +/Annots [ 1393 0 R ] +>> endobj +1393 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [87.6538 116.0624 137.7628 128.122] +/Subtype /Link +/A << /S /GoTo /D (tsig) >> +>> endobj +1392 0 obj << +/D [1390 0 R /XYZ 56.6929 794.5015 null] +>> endobj +434 0 obj << +/D [1390 0 R /XYZ 56.6929 718.7806 null] +>> endobj +1274 0 obj << +/D [1390 0 R /XYZ 56.6929 687.5668 null] +>> endobj +1389 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1396 0 obj << +/Length 2509 +/Filter /FlateDecode +>> +stream +xÚÅY_s㸠ϧð[™µJ‘")Í>ew“m®wÙk’{èäv2²ÍØšµ%Ÿ$ÇM;÷Ý ¤þØò:¹›NÇ")@à@G ~á(–I4ÒIHÊÑl}ÆF x÷ù,t4O4éR}¸?ûë•Ð£$HW£û§¯8`qŽîçã»øùþòö|Â%«à|"¸¾ùD+ =>~¹¹ºþüË폎Æ÷×_nhùöòêòöòæãåù$Œeû¹ãpdÃÕõ—4ú|{ñÓO·ç_ï8»¼otéê2Šüvöð•æ ög,I,G;˜° L>ZŸER2¯¬ÎîÎþÑ0ì¼µ[‡ì'EȘër1d@™JÀ+4àýÒ @vHÃ$9çÀiê2Í«'Sž‡ñxRÛræ÷tÙk‘'±Û“æóa¾" Õq¾“g5À:k*íYÏVé¶2\D$ÇÕÆ̲§œ¨q ÊØÕ럟#ZB9ü’r[à$,ÿ»È Žd«š]ßeõÒ­/ -щë¢v*S>9¸Û;X€wN$P¯ÎžÍêå< Ã1¸g¤ÅøŠ” q#}q¥Ï7:ä[äÀëðfx‡’±zÓ•Oš]={ÌP,Îái/éWƸ™(ßeël•–N-‹ìˆô´_û;ƒ•®Z–cW-Ü{D-.#‹Ë7{œíñ +}®Ht=^$*ù‹€ÐL8Ä­³ÖÜÔi¶ªÞ”TÆЀ¼sSÍÊlSgEN ÅÓP, @ ™·©–ÑÉ •Zü å¡ð¬³|#Ƥk.­TŒ(E/Ëň·Xkè'Ý ‡°vÈϿøñöC`U DR +ØÞé_ªS‚pCAç 181bH”úú†þò¢€;~¥ŠÃašŸÆ]q¾L­Å$;âJ¸ê(âÊW"®!&ôjÄ,’}¨!U€Pq ìÒ…f•ÉkEÄVzb)Clêä(Þ +xGÑ ¬,ÀV§íQ¦˜`ï1¼Õ2à Æk/Y¨{‹GÖ&À‹ˆØ¼LŒì¡TÈPÈuaºhq÷£žrªºÊ!0A]þ¦ù6“¡î.ðT…â ♉¿&ž8€žb™~Ûšòûá”0¦¾NÀPFI2Àð¨vZ4¹µ‰&¡YMB%®:ÐÌçsÍ(šðÝŠÝÒ‰&KÒ&˦ SGЩ_b+¹ª_„²šdV2¡]á²å'úIçm y¼`‘Ên±‹P^A8f˜©/Xäñ‚.*Œ”<}«Rõ:6uy:âQ Yœôéÿ@ñWË×{˜„{UákãÇ׸r ¬)…´ðJtäƒy“‡Ð1åI¹­j3Ÿ|3/q½«ÓÚ¬ g±'*Óõ:-‰ÔU‡ +¡½‰”+)ºœðþ½H› 4=ç¬ê2ËD–o×S¬©¿7îÒ¿·lYŸáÃ!ÝÛùÚÇC_¿’íÉNôûû!cƒ<¬8̲Fæ¯5ò'ƒ×˜gmqCù¿`öðÆú'jŽ¨m±zbr„’cUËÜ µÆX½Z m†é§›»»Ë4®Ìl[fõ ÍlpE]aWÃÂeVyfX +Om5€Ë‡U%Â@ÅÐ)GPã$úTUéé'Ý CÅÜ>ß~U ÂDA¼/d`™(é sد;¢ð¢jëâñ…·ç¤Å/Î’ý>Ìú#olšYóÂÓßšW°ñnirzAu 6Ûé*›Ñ¼¡Û¨Á ¥G^ä“t[/ 8/Eô§ej‡‘±?ï[^ìrÛ±Éñt넴ʽ`S·ÕzŠOÂÇ6ˆ)²Š)´PVn(@ZRo»XÒ¸Ò;h½m"ÚÏ0óÒ$ÃäJ+ñ0Í^´&ÙëíaT ³s|6)Éìó'mó*[ä¾’ÙC§/¹Më×øpFÇù2­hejð–piVäx gª¹ÛèèRšÖåy<¶áLsdè²—ÐÎ’®wÕÄ+­ûì€à‰ü†e:÷òœ‡c)?§«lÞÙœ;¢ YóÙäCZ·×íí½ï…]UQ¬0oÞÕ€6›ÚÁc0vg·m³GÈÕª!vvZ§4ÊMµÎ‹5øTÕ´Ü´×'î&˜d‹\í Ú”²Û…= *‡á0ú•IF0 “YQúR©Èç6§à2úI„!MWÝŽ õ[ºýFq +±c N|}í\”¸Ï €·;ɶJð4ÿ‚ãiH¤ Ú2_QËëÖ@ðÜ-SGÙñ|J‰\2Ñ{ùÜêIÝ^•¶]K:Å•}K ƒßç¬Aaà +£Æ:0¶ŽŽÆãW'Žc_ÎÛ’Ì5·Eeönmߧª¦ƒõþßk-¨üýòŸ¾TPP+¨¤o—ÛÛÊÔûÞßšô/Þß[rî2ïߣºåtÒ£E“2y½ÕB¥Š‘¸ +TÄQˆÔ´ºÞ®êl³24sé$Aõ°íÀ¼’¤³e³·‚‹v!’8—K|r²¬]€–‚—–ótmÞ‘­ñ£æ{ý`¦H¶o‰¤G¦º˜+·”®˜Ê–k;ŠqŸ$`ð!…Ü«"šÐm\Tƒ6ƒðÊÜÛIxΥŠl@ø»M:3^ž:úanv«Ì†‹àÊ÷¢û©p––e†•_/ëmé¬õWD»E^4¹¢ Í·Gº‘þ e±GÔæÚ®Ó—ý¦c•9ÜnüqµãÕq˜Y-ƒ#ÅòAG"\±üœ™ÝŸëDˆƒr¼Ñq¬‰… b%÷Üæ÷ªúÚíXöÒØ:­gËÉl•$MgcØ£t>ZŠÇ•EW\ÿýýЕ¨}Á÷­…ÿ³®P%&° +J³ áÒ¿˜ê±(óât·dÍSØOÒ®ùÁÞgHv·aþ±…ý=“A¿¾]ŠNyÀÿ°Mâ<ñ}¶=þã +Ê2Jªñ™ÒcSìLù´µ®ÇOPwA1µmcÖ%Z ôÿj*úW!%uý§ÿnÿ1t â˜7‚© æPô9¡lô$-«ÿ÷øPôÿLÎ8Èendstream +endobj +1395 0 obj << +/Type /Page +/Contents 1396 0 R +/Resources 1394 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1388 0 R +/Annots [ 1398 0 R 1401 0 R ] +>> endobj +1398 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [399.2874 719.9611 467.9594 732.0207] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1401 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [461.1985 450.514 510.2452 462.5737] +/Subtype /Link +/A << /S /GoTo /D (DNSSEC) >> +>> endobj +1397 0 obj << +/D [1395 0 R /XYZ 85.0394 794.5015 null] +>> endobj +438 0 obj << +/D [1395 0 R /XYZ 85.0394 615.421 null] +>> endobj +1399 0 obj << +/D [1395 0 R /XYZ 85.0394 585.8633 null] +>> endobj +442 0 obj << +/D [1395 0 R /XYZ 85.0394 502.9736 null] +>> endobj +1400 0 obj << +/D [1395 0 R /XYZ 85.0394 470.6064 null] +>> endobj +446 0 obj << +/D [1395 0 R /XYZ 85.0394 298.1533 null] +>> endobj +1371 0 obj << +/D [1395 0 R /XYZ 85.0394 271.5604 null] +>> endobj +450 0 obj << +/D [1395 0 R /XYZ 85.0394 137.8852 null] +>> endobj +1402 0 obj << +/D [1395 0 R /XYZ 85.0394 105.518 null] +>> endobj +1394 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1405 0 obj << +/Length 2683 +/Filter /FlateDecode +>> +stream +xÚ­ZYsÛÈ~ׯ`ù%P• Ï…+~’½²W[±ÖÑ*IUv÷‡Ê$À%@ÉJjÿ{º§{pP EÇ*— =zúøúˆr&àŸœEqg*›%™ #!£Y±>³O°öþDòž¹ß4îzs}òêNfY˜Å*ž]/¼ÒP¤©œ]/~ âP…§ÀAo¾|wñþWg§‰ ®/~¾<«Hï.þvNÔû«³ήNç2dðödz×çW´37—?ÐLFL¯Îß__¾=?ýýú§“óëN—¡¾RhTä“_³¨ýÓ‰u–F³{ˆPf™š­OL¤ÃÈhígV'¿œü½c8Xu¯NÚOŠPéXMPé)FYkXBžçÅ-j{å`¯2p^„G঻ÒÞó¦!C…ÊÈ”75mÞÚµ­ÚÓ¹–*XØß„P•mp(ƒœf'GÕKZho-Müpù ÍTùÚ6›¼àùö6g–÷åjE[nx­±¶"êæatN³»il;>©X• ]¾6Yœ¡B3 Á1€OÊ0‹"åT¡àë4 Öy[Ü¢8Èñ‘‚§2@EpP.i­lySSﶧ2 P_|ä— 7o›†Þ±F;8›‘¢$”J¶1²À×÷`§Áµ°SΓ„qÄÀSa–¦é4ìæÇù¥ÃÔH> XR&îF)^dL³0Ñ2~F=ǧdÌT˜(aÆB®Ê¦ÂtÂŽˆí]/{ç8ñû—f"`ÀI,|,8 ÌaJ…Q”¥Sk&$Ð::ö«|×8´§A^-ˆpPCba›¶¬ò¶¬+š@¬¹­C¬áD‡5ÀšFÝɱ…BÅÉ,јUfÏ€5æ8²œÂ$~ÅýÉ_[Š‰P=£žãSBf24ÙXÄCPKB‘dr5ïG„Z,Â8ÕñP#¤@2…7@®ÌR3ÂÖÃ( .P&­ƒªn‰h6¶(1¯ÛÅK˜‰LpS·SõCj B¦r$äaÌÇP.ã,ñÈœO”$pL9>¡Z†¯€Ûa™ïV¬I[ÓÓñ)«Od@ˆ»Ð(­Æ±šcÙQ`ATY¬#ZÇÁEÕ­•‡8Böø„˜+>#{7r•`ŸÏ”ªP~“ú‡#­§C£…úªõdEßb½_Q]"ʽ¢«†•kóÏv⨹ÎÙ^#+~¶S§€ªqd<üîoKˆfðƒ 6ÎDõ]¹À€ˆu€àÂÚ·yU6k.ë-­SäÀŒ/ßH;?ÃbcW¶ðs~£ëF2€+cè Ïh+÷(ÈÈI:#uà"·L9rîµ$Yk‹Ý¶)ïì¼®VSè…œúŠᦒØÛG%ÌW ‘Ô"©DŽ•›#€ñé?vàv~qI6^3G Ž•Ç›[¢Ö«Û48ÖÅ ‹:ò÷À¸ZDÁµ+¡: +jwæÂny¸¤gW“F„^?…Õ'úPš$ÙoCâ[ò³)?UÎaàÔ–¦~S*Aʸ¾&º¾è±h‚MÔniêÕ‚ÀVõÊ8ÆE]µöKÛ©ê¬ ]¨…Ø‹zn(䶫£âfÖ]æ?lX%Þd `[ò“;db’ÆR:¤ŠX‘(ÿ®]ß=S×Æ£‚BƒÚ[§¤@£M¤¡ÀZ>)¢Œcóøâ€lÙÎpƒYPÔ¹#‹rfy³²´Ã¥YaXÆ«,t‡UaÀK™Ú6“Ð×±žFPÔ!Ýb®‚œD¦Ü”žïUæâ€'\pˆï-ùéÁ«¤._\Ž·ÁÂnmÌ÷²nùt_äb¾¸Ãª¹ý®z½s JÍH>œd!ïpŽEHr*oÊÞ?”ØŽ¸¸ô¹›t@.9E½Þ”+»˜{öðåÚÉìíÌá§?ÛYúóÞü°¦¸kð±8"3“Mõ‹À—Dõ &ÀjèÚO4B’‹œ"«©¡Vþ 'qÈy®ÿЇ/Qe’}·‰§úÅ][Ã>2Óon{i¹ S€èî2#±e&½pêâ2$â¬z˜lÕLÀËå  cÁÝ2KÓ c!çQÖÁã늜õQoheeïìŠæ°$6ÉÎÄ»-ÊÂU²4ÑçywS. ßR'aíÝÛ]w˜ +*±ðÜäÛ–(ú®‡(v†O‡ÈLú +õ’¾ÓR±Le ™(È@ÙQµCdÙÄ÷räÍm/P¾äâuð@ÌS‡µT +dQ1ûÚ¦¢l'ï¦.øY–|O à@Df—Øßm—¢&ì5®ú üJ8˜“¦¦` >&¿J‰ÐD™ü– T¢¯Pp ^Þ†…âG;´@éÍÂi[ct9êkÛ‡ FûM.óE.(‹å6z×ð½cÿ^÷fè­þ?=ÿ:ñm´Ö¡HÍžÚ”ìb@Þ ßì¿ ñ±t·Ë(#ìÕ+Úrí‚©æ¶Þ­Dó Iü;Š#> endobj +1406 0 obj << +/D [1404 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1403 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1409 0 obj << +/Length 1124 +/Filter /FlateDecode +>> +stream +xÚÍXÛnã6}÷Wè1)@®¨»§lê¤Yt³­×}rƒ‘(‡nKÒqœzÿ½”(Ù’/Éq…aHâåðÌpf8C¤éò‡4φºé[šë[ÐÖ‘­É@×f²ïf€ª1 š£>Ž®MWó¡ïŽ6ŽXÔ=iãprvõÛåãáè¶~æÀs`;úÙÇÛ»_U‹¯W_î®ooþ]ž»ÖÙøöËj ¯‡£áÝÕð ÏFr¾Q!˜p}ûûP½ÝŒ.?¾ß? †ãµ,My‘n‚|Lîu-”bèÐô=[[È"ß7´d`Ù&´-Ó¬[âÁ×ÁŸkÀFo9uŸþlÓƒ¶g¸{h !èÛ¶ÑÒ íCÇ4ÌRƒ…І-5 ëúÙk–%àWIH**yNÌ +y?\[¨±-ºLº®«6D!8Ö4ÅIõ9 bÌù½úø·Ò ú…–Àš£˼š‘`.»(‡êõ µÊDÀqœ-À·9aËWµ‡!#œO,‚ÇiL¹Píß/Ôó¾iÀYzbXÁpÊ#ÂÞ»Gó<”»u2® +äYLƒ¶bUÏTõLÙ<®7BxßG<i&hÔ†§ù´à]aæëöâ£Z¡Z`rÄI³f×YÅÁ# ž@aÈ\5ü­Ûú³ta¯è,Í‘m¨µÒÄWˆÉËIá4ÌBÕ¶$|š±išu¦‚ÌË-€Î4BŠãyÞ|Ÿf¹ µu@ˆhmO\0šÎ~4±%ŠÅteLšüF³‚¼ˆË^ý'›³Ç]¹m./ š8}­’oSž“ ƒ4R„Åz# ²4^®"ʸè%E…Co9Ùÿè7­åéKÄÀæÇmi9;bYBɈIÒ ö¿7l{—„HrÐǶ¶öSz†üƒ-y:9Ú¶Œ$Îf ÓHçÉC}"t´¯ú4”&ŸÍÅû‘Mz!µ$k†ò-½¬Ôƒ¼äòÈ ¢Õ¨ÜæÝ™´Z +„$ÆÕ$N‚, y_‘žáþÑ2Ÿ?<‘定½÷4·Š—$ ›@s«á®«9.4]C&κ–i—0¿”]6ô]×Ñí›Èñ–¯+v¹&”sßäž&Mg—¦L;M¹zEÓ:@Ó:’¦ Q&¿{öªHA—™¬LhÀ=Ù8gÓPžŽå9Éžëá§ËHòŸJ‹ùOXG´žîÖD)žXÌYw¨ƒ„6™wO™â£}"C+#‘à± BG‡²÷ƒ”L„Ìûû@ ]}!Z,dp‘G#Èêª&Çⱬ¤:L%¬H­‹Ø„ˆß6y°U…)y¾¯Ë.Õm½·¸C[Åñ3¹x³`ÚS$œ¨¸;q öŒÆ¡‚TâÚ]O  +YÕOü©ÊVzO×þÜàç¬.÷]™6,îvö\êèë{›w_!mî×,™/xž±¹2÷8¦î@ÏðÝšT¡Pm3_ß5íRÿŽ@íendstream +endobj +1408 0 obj << +/Type /Page +/Contents 1409 0 R +/Resources 1407 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1388 0 R +>> endobj +1410 0 obj << +/D [1408 0 R /XYZ 85.0394 794.5015 null] +>> endobj +454 0 obj << +/D [1408 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1292 0 obj << +/D [1408 0 R /XYZ 85.0394 748.6299 null] +>> endobj +1407 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1413 0 obj << +/Length 1090 +/Filter /FlateDecode +>> +stream +xÚÝX[sâ6~çWø:#Å’ï³OÙ”¤Ùé²-¥O”a[NÔõm%± Yúß+_³1`C2³í0ŒeÉçÓwnÒ‘¦«Ò,Úö4Ç3¡¥#Kó㞮ݫ±›ª¾ë@ý«÷“Þŵáhôllk“°†åBÝu‘6 ¦}b8PzÿêÓèúöæÏñåÀ1û“ÛO£À–Þ¿¾ýuX¶nÆ—?^Ž¹ê_ýrùÛd8.‡ì +ãýíèç²Ç+{@ÇÃëáx8ºf“½ád£K]_¤¹"_zÓ™®Jí=žkiêE‡Èó°÷LË€–i램÷Gï÷ `m´m´Ò!6lÜ`@Õ èêÐÖ”cyÐ6°Qp:¶®÷ýê ‰©(;þÒ-ý‘ðd­Ø}’rªúP9ú®|Ìrý €ô, ×F¢EVoÏÓL²4i²ˆ–-!9Kî ¢º`L„¤<aÊc"·*Iú$Wœ§ B©öcæ‹S«€HÒ¥:ÚÝ^T=ÂiÈ©x(v—“÷¨S@ÐK&’/ÏåqÄ"’ ”{Þ©y¦<I±s)£ã0ÐCŲ[c¤ê§jŽõpÞ›Í6|æù¹«ŠH?"Blj¿bÍi‚•Ë¬’xPõè»&[ì+qÄ è=ÉÏhµB¡•åðùgÉ‹‹ò9J«Œ¼³ˆÆ4‘4€?€…\Ü2‰¢ô|YP¾Ü©Üó¥Š +1WÇPÿ¡Vµ·)¬k˜`}p~ØW9ì£×=ì¿Rìý0wÿÝSûÿøÚíxÙt±gX0¿k¸†SÿjÒ³/ý¶7¢¦ª¿\oîó°Q»ÏÃŽ MWT¤reü‚ùúvð%õõ~Lendstream +endobj +1412 0 obj << +/Type /Page +/Contents 1413 0 R +/Resources 1411 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1388 0 R +>> endobj +1414 0 obj << +/D [1412 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1411 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1417 0 obj << +/Length 2117 +/Filter /FlateDecode +>> +stream +xÚµYÝsÛ6÷_¡Gú&DðÉñ““Ú9w.nÏQ_êf<”Y¼£HAYQ¯ýß»ÀmÓ‰OÇX.‹Åîo ™M(ü±I¦¹œ¤¹$Š25™¯èäæ>1/¡x(õnzôö\¤“œä O&Óå@WFh–±Étq½ÿçéÏÓ³«ã˜+%ä8V Þ]\þ€œ‡÷?]ž_|øåêô8•Ñôâ§Kd_Ÿ]]¾?;ŽY¦¬ç^à Î/þu†Ô‡«ÓO¯Ž?O<:›ögž—Qaò¿£ëÏt²€cÿxD‰È35ÙÁ%,Ïùd}$• J +8Õѧ£÷ +³né˜ÿ”ȈÊx:â@Éd4#¹ÌÓIªr’.œ¯ã„Òh]|‰»¶¨ÍR·qW®u\Ö8So×3Ý"}‚Ãg{nØ[}o£i¶í\#ó7ªh¹‘7ÅbáµþáT°4'‚§ +4‘T +éýÃM)’§i2ðA ÃÅ×›¦í,77öãóˆ}3DÀ¢`'ûŠñ]245yljžždÐTõ„©êûLåT.Ò|Ô¥EÕÅ/rë@ÛßbkN8S깶~Óµœ3ÂRšü=(à<%Lf|[£ã'Ý»×æ¦ioêæ°ÿ½©ulº¢+MWÎÍÏΞEѳÂèç¦Þ½Ã¬Ë:nõ²Õfå*Äw•[g^¯ÄYÒµû©`íx©ŠûVl«®Œ×…颯$æ‚äÌ%ø@ÕŸ'aƒ0m¹6Ú‡¸ßÔE°ðz^ÆxþÑ=¦¶ÛoüŠeÓîŠvqòWx‘C5uµÿcY¶¦;dÃ3üáõèÖûÐæ>‡‰ù­Ü"„„ýÜðçs°­+} ÒÔ±=ÀË#ÂF#"_ö "ì<ù&:Þžs6éÙKk\à”£bÛ´p¨€Œzã°AùµB¯uÝáçú7Jy]Úm‘SÔ $~1Å­î÷9´ Ö&ûæwúµßizœƒŸ7Úzï9ï#€âo«rPUÔÈ.*ÓŒÝm†±×Ú Ç i7u#ìÚZ2ë#åøv/F@„¢w{ä-ô²€nå F?t£~AÜ.`zÌ%æùÌMY„×7Oy¤rܵ#º Ørå€ |<2¬œyÁùª¨oõ?°:Q¸Bb‡Àw¶ œÃÝrïzY!¥Å¾Êi¡±³Ü™^ö8³sÎ`;1²,çaàX:}C‚E‚ u²5ÊcNÛh·.î ¹’´ßÎ@Ë.p=‚¤‡ý½=-  –§PX9éá—§ƒå‡+æ¡-Îï‚%5G9p1@‡KEËÙ•Ý +©‡¦[ÞôÓŤà…oÍR4.–^-ê²^ymöœvtñq©¿x3šxp. ç°Ä½º&”ð7“šy‘\2]¿° +ܦ@õ†ØÅ°Æc 7Áªj©ÒŒº ‘i#Î^’‚ro[Õ@¦xÎ!9ì—·¨Þ P`,pèýÚ+„×]ÛÙúœ$Г…UË°jľ žS†÷B¯kÞ¬¡Ê,œíœA2–õ<v86Kç<»â£Ù=T-m-ÚnP{àêª\—£´†Zéoy{ýÈ<ªAqFæ΂IW9A`jwå¢[Y3]6A"ÔðÐ1€p…•êÖK`V›qÏ(j¿¡"‰4êÚ Ë%/pVÛÚgÙ"Ì,½ìªÙ°Íà è0Åj Jm\ûbg,´%Ö¾j:œÖLãu |sûC2 +üîvM\d+äBùwÕÍN™ùJ¯½´o¦xßø  +w_LÉs‘þ2¶b½©ô›Cw åºo=€6n—…*Ÿù}]ƒp¿ùQŒdðtð-‚þâö Ë‘n"ɈR]Gy»êp—MUÌu¸?tø¹…©øƒ‡’Ïd¨Ëp¹wx¿Ú¯²v…¨‡>#­(Ü1Á#ÖKNhÊUoýÛ¯ K T™Ä‹ïVÚß/5 Š¥<(ÑÆgbp‡u‡WzÿÜÿÙ: AuˆaOØöÜ]ƒDu ‰Ûù†¾]þ —ye¡Cì# siô± Ê€;Ü=‡ðiöÍk3†¨™^!~¤ˆ<¶[’TÍ®Ú#·\â¸o¶Hl¶JÁ!‘C13~¡‹¨¥ +¯ ªü^‹Ò—¿®M>âòwü™1ìß_÷&<ó¿0f”€Qc?ÓÓIðЫÿ)pø 4ÙÐÿñþr¿K§ ÉxžÂû›X]62©xäŒðß/50ý/—$Šendstream +endobj +1416 0 obj << +/Type /Page +/Contents 1417 0 R +/Resources 1415 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1423 0 R +>> endobj +1418 0 obj << +/D [1416 0 R /XYZ 85.0394 794.5015 null] +>> endobj +458 0 obj << +/D [1416 0 R /XYZ 85.0394 421.6574 null] +>> endobj +1419 0 obj << +/D [1416 0 R /XYZ 85.0394 391.5435 null] +>> endobj +462 0 obj << +/D [1416 0 R /XYZ 85.0394 391.5435 null] +>> endobj +1420 0 obj << +/D [1416 0 R /XYZ 85.0394 367.1321 null] +>> endobj +1421 0 obj << +/D [1416 0 R /XYZ 85.0394 367.1321 null] +>> endobj +1422 0 obj << +/D [1416 0 R /XYZ 85.0394 355.1769 null] +>> endobj +1415 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1426 0 obj << +/Length 3415 +/Filter /FlateDecode +>> +stream +xÚ¥ÙrÛFò]_Á·@Uâx.\µOŠ#;J­å¬¬­Ýª$ ŠHH€!@ÉÌ×o_‚$'ërÉÓè¹zº{úš‰†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ž„âÍ@(Æj•ÃB“4ÎUâ¬#©´ÝîYóæ ƒ“L¥Þâö8èxéR PýÑÔ%ãªVúªuµ*¶ÜÝ5Œ,¤oU<—‡‰WæQùyVn:Ñ- ªŽn/M•›U5+ºRöhêÕiª¦Æ¨<Ž-‘×-augóèLž5ÔÎ[îlÜYðçºh»rË(>b«°ÅüxF¿~Yw¯}˜‡úè“è“ðñ”6‚äkaªÕ:ª›N°üÝvE=çsîØÛŽûĈøîîÓ?zÔžqƒÕûEeÑí†øvSΪŸµ¶³cZù†’ØàÎð>ñð’Uëͪ\Ãù‹®jj5vRâ°Å‡3;G³¢fÜcɈ][΃»!¦\êÔ eA/¨KG‹f˨§ÕN–aIûI‘U!†tÑ™¹JSêŽÑ"zè)ÃP~Þ”—&ª[ù&u€v]TÀ‡ª®ê'™Éx¾ˆ‹¦¸Ïv?Æk6r–ÔÑÆ0¹ìø›„ m]¬Ëе}FM¥Ñó9Ó߶¤V€‚Òý=¾ìI¢2›¥rq±¹š5õb䮃9HÁ&ÈPÐgç\ô°¬dý][< %€Â£L­ã©}rÌiRi÷4e +3'!’…@]¾0ä *>í¶¤T-ØçÌìgíC(ç¦Ým6ͶkGÅŒ{g Û‚HðK'‹#Ô²ŽˆÜK±¿4ÆàaS õV†ÊŽù7ãMd ¸n[Ôí¢Ü¶²Ób°~¯XÓ1a“¶Ù$› ¡™­vÄÄóõ»Ï,v.è«Yó±Æ€Ÿ-«•¨EÍR"#v5 ¦j„q,h—êh]t+RMóðü`2ˆ€jÔG„fèõj¼Î[™>kv«9ƒO%­vM¨—ª[†qõtŒÑºU6MøTÆtÔ–±,_„0ìdÞ"Xtšî àIó‘ñ‘ÀŽæ°àX!ÀiR”f»¤e³®>ãD°kàÄKÚÆ°?/º`‰{ѾZà'èRO¢{_¡ép´ò²U÷;·U–Z°Æ°µQ…zÀ>±çåÜô,³lf˜ù‡ GŒê%BË¢e€Å4B¢è§ö‡sŃ;OëΑNã¢bµâ~qq¾teËxæpäÐ!4BO±j›1©²g!O'oÉ› }_+öW÷ŠˆH>S¬û3ÅúìLæuÖ{GÙ;@”D~RgÁObŸ .¸á¥ùŽc+"Ÿ±;Ò!\Ñ! j›Õík?k„ºm]=UÏhAœ7èæΈKˆÛ¡'ôìK±Á¥ší(ìÃoòa8I£q»nÙl+ žË0†„9zÛÞ±ŸOÀóo CðqˆÀa +:%ŒaÿˆP¯øAç´l•aÊf[=KhSÊî¥ÙþÆ»v:.àúIÝ¿{kr“ñÇÀíÊ öÜI"ƒöT+†/éãƒ$éU aãtî¾Oˆ2ZUõ‰PÅvSŒøðÜ)ðÚF|8…VIÆsà +þ&9ñØB SnëbÅ£„¥40°4$gR²û›4Dz¦ÛÒ_\øà‹ëà“bS§™™Ï¼Ê—L†ùÌWæH^;Ä@³3¹&ÙßX´ŸòZâåR§|ÆIäHâElrñÄç6™,!~?^Ší|D–iªR £úÜËû<úÙZÏS$E@$êvðúqlñvz1øM×Úýdä`MÒlÄáêÊ£M9Ù°f3aM=m{jÁo]˹†|&9ŽEVúüìÖ©ô0’¢Ž²Þ€¢¯»ý¦[?Å×ÉÜ×ùë2•¤YÈmÉãêÀžN΂æã|}ˆ“íA.bv§§V¥yœžzéQ0zβL‚x÷M0Gû¹X¥ÖgÇçÁû4Â;¡úÛ®$öZV3´A­zZ„ŠÍ†"e4° £~ß•Ûª”ߘØdíñ-GkF<ÒiðÀÙA tïB|Üs·ŒK{Ïœ’¥!MI¢Û… š@l bäæ_áQYÚ‹Ÿx„“ÄÊ; g-9 £‹ƒíFl¼t؈ü†'5·åzÓí\U­ ZŒ +Ï$`Àžü­Êmò¯@ 1òª/@Ì%8’ñ`J\~|¤ÓËì|:8ù)®2/‘1¢ØÅzqû˜ô^q·c zXLƇ–vÖµÜsW„,w/©Ë2ö”’Ÿs晲Yâ…+͆Rıۜ¨¼çs¯ù'1ÄÅ»°Ù‚7Û7;^ +NÊØ>Zñ–¬úpóljüi•©WFögj}.Ézù‡ålYÔOG1% ,!Ь‚# “ûóiœoÁÜ Éǧ +5Æ\i«óžo½òʧùé™(.´ÞBökñÌ’>Ìï¬÷çn{Ñ‹lÛŽ=NîîDQi½±‰˜¼a‡,NŒôs5+y† ÅÕ˜&=î:®­°Ü"³e‰rL*7‰Äîõ õ6 e…§rhÒ±a ©R}lÃÆaÔ RYm±?'É2D?ý=äF_BžÔ€Sý;Q”Lx5ÜÑÐïs÷…:3\@±OJ,¯Ñ}±Îü@¬3Xt¨ºŠx\€ý¿eI4`¥PFC¼‰KHÛ—<)çÄŽCx\¨` ª$ÑG_!¨Mãþà +nr3}©á®ÀúÁ» ª¹¹¤.Ù çO’ˆ†[$œ*…&gjOçÐéGîKOf/´T—oêMI´nÚŽ!©8I©*‡“âáÆIÈ¿êSº©‹SöçØßp?VGþ°ûÅöXRÖJÊ=³UÑÊ Û»+ø8-œ`a±eÑâÌf½©Vå|JÎórQìV£Ivd$;2ƒã× 'Ò,*8qFï-RÇùÌå:‚`Nk†nïd•S7Ü>îªU7åî©…Tq:²ã«†cp'¿ê–ÌFæ ‚IìßX1ÌxÍpX“)¸W¨2èôr8Ì/3 +VåÕ‡§áùçÄ„89dUyoCØMÛ(´\JAˆ³Ê:MÈTe‚žÓí‰QÅNc§ ‹×‹mÑvÛKˆfý#ËŸ?¡ÅõD±¯Þ~üpÅ]w7ønyÅÕ¿÷ïÑ%)î»®ÃOݾp‘Ñ„,K…²z¸ÀÕ3lQÊ#ÆëÍ®Í8r+?ã+ÕÏ!k !>ø°¶Ho}f}ö¿g| ¡ Îú4ÅtìùŽ)/¨:orK~Úä.ºûïw?\ßÞ)F³dš7¥ ¡7šÃé ‚(eì#â +²8ªüL¼7¼Ú˜Xrï?Òð(.w©N‹‡«²„|G_«ç˜¿¨ÔpLì‚_¤b«#‚°ñ‚ˆûœQÄí8(‰Œ?èE3ñ°“Ž“Ø°éiûå°ex±¿ÎVÌÏáý‹ïò0'ÎããgùÿkR (P™ê ò³Ê%¨ðšöªoÓ ‚6ç&ø{ˆ}ÒÃÏ"Ž ò“ãS•¦&éaá?PP ·™œÉˆBhÜF´ð}¤drV¹oZ†Ù%#DµI8o—¿eÀ¢Y­š¾pš2ul nÈÝÒ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Ö!>'ýÿÞüendstream +endobj +1425 0 obj << +/Type /Page +/Contents 1426 0 R +/Resources 1424 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1423 0 R +>> endobj +1427 0 obj << +/D [1425 0 R /XYZ 56.6929 794.5015 null] +>> endobj +466 0 obj << +/D [1425 0 R /XYZ 56.6929 167.2075 null] +>> endobj +1428 0 obj << +/D [1425 0 R /XYZ 56.6929 139.8789 null] +>> endobj +1424 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1431 0 obj << +/Length 2969 +/Filter /FlateDecode +>> +stream +xÚµ[[sÛ6~÷¯Ð£'jYµÕºÚÚ[뮧ÈÛbã$í-´ÚŽ]¹Y-q±ç„/ÿ[íÝMÞæüP9 KgÏ:ß›ØCV„ -í¼¹/ìð4‡b]þ1í´BÇsÙ>Ú–Ñ O~ÅÉ 6ÂŒˆs¤úðÑ‚‚2Š˜T™C­·y6[ØPÖŠP”ʲŊIÄ” ´!Í®aŒ{/Á ‡¶¬öMD%Œ°–g’ Aù‰©ã@«!ÊŽ<™y2åÛmõ¼‚á/^ÆÊ 'ˆ+9£Ý£&ÔãFx†x¦Fú?ÅqDºÆ¦hÖuÙ…ÃvTáÕaʵ…±#ÕB!Í@³—û±£Œ0”ŽÚ›õ§…mÜ\öø—c¹ÖåõÑ9C‰L‚A¥ZÏÄÞ£æ ‰¤CÐI¶qH4ÉfØ6@%ØÖ£Žãô婨'È8ExZ¹GMhÉ&à.dÃ@ý[’Í;1æšDŠâÓ\ƒé‚GANrÍág<Žå¾žkÒ¼Ke–½GÍIKs kxå)9õ*Áµ5¦U @ +/Œ¤~š0  [®bÈõÿŒn*¦›óc¤\R$e&N34ÕB®¦×ãgœŽå¾šqK¤¥`éè{ÔŒ!±´$ã„!(3Œ¢N3ΣŽ#ÕÖù¾y€ÅT”à4¢T¥Õ÷  õßGkêK¾ ½)Ï2”IÐ}’oFxšâ[Ÿq:–ûú §’ +Ïß£æ ‰¤¥ù %aPÓ| |ëQÇ‘z:À +¹ˆÙ™KPÖîQêC¾A~cœ†úß’oG/Æl£HaÐ|šm\ a˜“lsø—c¹ß°v3´ÀY:ö5gH$-Í6äÄzŽmT‚m=Êh´#´:TÛr=±zSˆPÊÓê=jBH7f6Î24à£ßÎ56þ¹ýóHüXî[GB£'»ß´×¿u†”½vB Š°¾Â‘ÇcotÂ`Í7´4E«?ãZ,w’Vtê¥ °ôeé{ÔŒ!±´$­¸â¨Ó´¢NÓÊ£ÆÓ;üç¼Þ”ûOc;(†¸Áö1mˆGMX2tžbDºõÿÉg#‡Æ4' ­ÈÉÜÆ6W8 ¡ÇϸË}ýÊ œÍˆâéqð¨9C"iiB^`ŠÍ‘p€J°GÙ1kªSEK-Íg”{Ô„ö`Ȭ朗ÿ°ß¾@Ø©^îŠ|dyxÚÚërŠoàŒ^¿à?Yõ€å’²ßµvµ;˜Ã -lÛÔ Ñ>ö·ÿ®ö…ÉŠ˜-ï¬)ZÛö[+óõc¹/šþáÜÝ.·În›×…W•O”Ûh&—ª·ÿxÓ•Û „CFâ}QÏÖxo>Ü]_ýgª§¾¯Ç튦É?ÆçŸiXÿV¶Ïög6®çé`ÿ7 67ÞØÇb[6] Ó´÷ùÎõ6Eýµ¨‚?°À®˜jÍ÷#!‡ºÜå¶v`VÖú €¹ËAM ’<Á©óVg½ÐuØ>5¶•ï_lãúW×±ÙØqhš¢±Ï%QƒéJ¢1Å(,»¨ÈŽ9-˜Ñ,,ïK¦x®äò™WÕ­mírgÞ}1²åœ,Á,ºD[·5Ñ-€yæÂʈI*^e­ °¥Ïzk1²ÚªÔýÆõØSýL³¬±< RfEÒ°u›"¸c‚Š™ àõò?m{能 ‰aªœ¬ÊÌÉ@0)f<%HrÁ‡ 2;Àm#È5pm³©›·O÷¶ehÖ¸EÒÝñ¥è¬6½TÿÊ,v‡öÅ6Íl9™Ë™äˆc{:r:—Q§s¹GuùÇbýyefg¯RÊ”žQîQÚÃ# ‰ÉSú;›j8¤·n`.L¦ï©é&ž Xe{ûÚº\·îŽä<ÉkH×Ì°0Q&ïÈ ˜æeßæÙÎŽAæ¹¢nóÒiÞT;Ûæ6e5Π½Ï?’òQ®µù€,[š ºíž‚ Pû}ån˜tÝ5œ‡jßô¸AúßØž{&´³WÖEhì‹ö¹ª?wnÊRÌt'\|ÍëÒ°^W¤nIeeUSg@û“•öåP8 +_UõÄÔÊ2„a)Ö¿@¬ï“ç>Ò¢ƒu3#Z-†câÍ-‡çd<äåvjYoEMéô´élR¬÷5ÛüëԚŸ1ö†–ÚvªI¢œ-?5õ‰†,ÉÌÔ S¿G§þî¯hÞSØwjIÓš=jBu¸†ƒÝ©9 t¿ÍæaèÁø-+PÆÕé2/…!‚¨ÀÉÄfÁãgÜåžÚ,h ï2I4KÇÝ£f ‰¥%YF gÆgX6Df™GÇÖº›5líâƒo])Òú=j€0hÈÏJ…¼%׆~Ä D+•8X0»mLW“ ?ãt,÷ÕŒãØT5´LGߣf ‰¥¥' ¾˜ÐÆ P Æõ¨ãH•û¶øT—m¼E…‰‘ X4' ð¨ BÊ)óaˆ +MxKÊŽŒ9GÁ4Á9&aäXàkŠs=~ÆëXî7pŽ£ŒJ™¿GÍKKsÎ|eÂÔç¨çzÔq¨šò~;Që¾åàð +Lª÷¨ ý!ãâTëЀ·9¬Ü/0¤´Ö‰ãóé =M/8üŒÏ±Ü׿U5F”Òtì{ÐœcYI² Ü4­I² Q§ÉæQÝš´¨Í>vÕTùªm·q‚Ã0JD¥ ð¨ Bº¯’‘Є·¡Û„#cÂ)Äxâð¶œ*¸šÌo?ãt,÷øfÎ]OGß£æ ‰¤¥)T:G¹*A¹58βùásó9â\,!ÙŒ5aBÀ9‰‘ÔrdÃÛ¼T§<ô ³L&>€3å>94oî´ËágÜŽå¾þ­ +»1-2Ž¿GÍKK³Î|äÉ2iÖ P Öõ(£±­_Víú°ª‹‡ºh§ìÔeÚš°`œè,ø Þ&ÏMø1ÎsÉÄn•1¶ÁBoèB2Ï9üŒÏ±ÜoÈs°Ôð2Lß£æ ‰¤¥‡a᫲™|‡¨ãz”Ñh>Ÿ¾Ï›øÊá-Ûú¤fšPPj¤2X¬º»û®bÎû²&Ó]AÎvÙ‚%>ÚhïW¶÷Þ¡\Í”» +µ4mUÛ Ìq(÷Àî÷5EóÌñ‘‡ÊÒ¦¾à†64,,ã«Â›Í?þ¹xyvµJÐB¥­›¿°ý©í7ò…=M¢j™»›¹ýcJç¶ÕÅÏe[4‡|]¬6ŶܕîQ¹ìµ˜B=,)ÇpÔnë^ÎÈ–M±oË•;osv~ú-´t©Çêºa ¿³‡]=Úôu‡P¦Ñ<Ý7Å—'ûÛ=°ÒáüpqÈ›nŒ»àÓ“ùõAoF•6Çݾ/‚0q)huj«àÃ/Ižó—Ñ/Ö.WVãœyÔìKÌ'~Â2?ݘ˜]ðßüÿBäøón~lpr¹o +£Þ()Æ–ûŸ’Ħÿýì{endstream +endobj +1430 0 obj << +/Type /Page +/Contents 1431 0 R +/Resources 1429 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1423 0 R +/Annots [ 1434 0 R 1435 0 R 1436 0 R 1437 0 R 1438 0 R 1439 0 R 1440 0 R 1441 0 R 1442 0 R 1443 0 R 1444 0 R 1445 0 R 1446 0 R 1447 0 R ] +>> endobj +1434 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [312.6233 667.7189 381.2953 679.7785] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1435 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [310.4119 636.5559 379.0839 648.6156] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1436 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [340.2996 605.393 408.9716 617.4526] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1437 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [328.1051 574.23 396.7771 586.2897] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1438 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [320.3548 543.0671 389.0268 555.1267] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1439 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [359.1386 511.9042 427.8106 523.9638] +/Subtype /Link +/A << /S /GoTo /D (dynamic_update_policies) >> +>> endobj +1440 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [429.9426 480.7412 498.6146 492.8008] +/Subtype /Link +/A << /S /GoTo /D (access_control) >> +>> endobj +1441 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [286.0435 315.5214 354.7155 327.581] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1442 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [339.144 284.3584 407.816 296.4181] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1443 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [336.952 253.1955 405.624 265.2551] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1444 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [322.5463 222.0326 391.2183 234.0922] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1445 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [331.4327 190.8696 400.1047 202.9292] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1446 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [361.2812 159.7067 429.9532 171.7663] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1447 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [330.3165 128.5437 398.9885 140.6034] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1432 0 obj << +/D [1430 0 R /XYZ 85.0394 794.5015 null] +>> endobj +470 0 obj << +/D [1430 0 R /XYZ 85.0394 726.6924 null] +>> endobj +1433 0 obj << +/D [1430 0 R /XYZ 85.0394 700.1172 null] +>> endobj +1429 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1450 0 obj << +/Length 3050 +/Filter /FlateDecode +>> +stream +xÚµZ[sÛ¶~÷¯Ðô¥òL…q{LS;ÇÓ¤Çq§iú@‹”Íš"uD*®óëÏâFñ +6§éd2†€Ø]àÛÅâ‚WüÃ+ÆWD­„Š‹0[m÷ÑêÚÞ\`‡ÙxЦ‹úîîâÛk*V +)Nøên×éK¢HJ¼ºK[sDÐ%ô­_¿{{}óæçÛW—"^ßݼ{{¹!,Z_ßüûÊ–ÞܾúñÇW·—,^¿þ׫Ÿî®nmw}|wóö{[£ìŸ™No¯®¯n¯Þ¾¾ºüý«»Ö–®½8¢Úÿ^üö{´JÁì."D•d«gø!¬Yí/bF‹)õ5ÅÅû‹ÿ´vZͧ“ã‡#D('Hhg%FL)¶L!N¡IàÝc6Åxf»äT4öG^k˾½Žeç{NÅ‘¡úïŽ÷ÍWÕ“B’R(‡úF÷GýÀBÏêëK¼®m¹Lšü£Ÿ—›}¶¯Ž/öçñËu–nî‹dû´iìO¯iÒ$÷IÁ¤ÑH€¹é/j¬Ê¼œªÑŠ®6ŠÀK¾Ú`ŒcĨØ$O™ÖĈy8í³²©‘ù$¬³±4ØwÍcv±4^LŠ“@)uf¶áPÕu~_d¶)ßÙÚ$Mó&¯Ê¤°õg]ukz„8ºÞ“®ú>ËJ[WäåS–ÚÚ¼l*[Û<:`á{MRÃd¼~_í³Öc¬õ—:Ù +gn+ôl»kÉËmqJµ<ýë9omÉÈ3ŸæusÌïOÚ"[e[(«2›èÒ`»wß¼¸Þ,õÐÈ›0ó— aíÓì· MeÉ'¢G‹Ò£‘æ0‰‡¡XÉÀó XšÛõ>Ç@‘žØ÷Y6ϬÞóÃy8«s­® J ˆ€KFå2)ø)Ès0ì}èÓ3Ð6V¶pÛ1µÅ/Ø:î×»=›¥Ã5æT‚˜.1‘á1oQKŠŒzÓŠÌÓ b¬<^ W —G™ÊŠì!ÑÖoª²xÊ É‚-jBƒ®Ñ0òˆ:PÁ†wÅ×¢ˆ&ºÌÖFS›EnÂ$üÐQEÿ}„cI™Úªº9ÝÛÒ'poˆ›8ë›kÍz/ L ¡åãKVOp ¤(‘çUCGvpÒ©æÍød£ Èz΋ÂQÔNó{óàc…"%å ÐÛx”4>%.öémþº–û˜h;Ö%ï¦ý µNürp^¬•›g¬Ò–ò–uP–y”6kWŸ“c:”«("„±°\šÛ‹b‘ˆË¾Üwf(eë}–”yù°;nÚÙz·<17kºé1©mUbÿXåõ¼¤ný‹a©¨³ŒÅ†¾ã8cDÄ}&â}kŽ ì@f¹¶2·É©Îœ¬VÅ¢ªž šZ½+Û¸KòŠ@Çô •ì $8¾Àè2vd…Ê¡qºÑº4>dMÓ~RV¶2)ëg»ŽëÄIðõóc^LF\Jê¬ï&Ǻ™“8úQx®N…“ŸEõìt²5euÜëôDWùá0¶U¶Î{p0ïʳt–ýŒ1 &4Ï}êP_î0¶F°>GÀìà4–Ü‹M`f,þ]Ñ?×&Š`a‡渂d꘧™«}tÍf[ªvøPT÷fœ¡®O¤Ã˜²qs÷¡‰GÑy¬©¨Ù6×sîu0 ûÓEÉV¦°AjL# +[A`ë CÉ0§€‘¢„·ñÙV%ˆì¼Ÿa–.dv,³4ïÖ´Í5H…>óÇ2´µ#§3$“-Me¯v˜ n`$&ˆ°X-P²ƒ +pÒ£LÂõçÎh³1éý0*sDUaé4!½ÇË#W¤/þ—KEÌʆa‘<–b†è»Ó%i4}õOé݋ýaF\·–É>³UšI&(!Z%.¹ÓØ¢z°-"ýQŽ°Ù"ö•)\¯fÖueúò­Sö›"c`Ó%(}jYBÀîææ×ë[d‹ngÉí–*òˆc† µ­°ìáž1¶²íj ‚Ä@®OÛfø5^W7:7áµ3Ïâ¼iºÁìi´€Ã!+óáçBb—u  ªòþ‡¼_¹Ú^€ý£,'#ÆúL5ðgŒÝ[̹œµdÖgb;±Æ»¨yŸiQ=Ÿiö‡ÎaD‡±1[P¢EMhÑéIÂj´¾cË"eZmÍ™€Ï«ÎFÍïeÏGGRŸKàh}Ó1ƒªù‘& ²—H.Œti2,rÄîy’:MÊõ  ¹½l1†ý‡Šûr_¹tCz'’¤sä$[úº¶?- ikø,MbþºÕ6ÍJ½‰˜ÛéHÜïÕ¬8úsߪ¹>'ÃtØðy±Pªï€s>Œ`LbïÁÓ^ +¹¨ÒçC/µQB¯R†2î(«»Ñ´mrïÏlü«7Ñ8ˆóØë°Oj—N ¨ób¯CàD_ +Öá5­ }5aƒðL½@·'œ¡2•1)‚F5OåeíüsãX³©óOãˆ;âˆ-(àA +ôw×EÆ¥§Á—9È™²c ^H$³G:&ø%z¶ŽtZü‚Ùã~gt¢‘NƳðø·¨%MF½Ït((dÄ ¤ë ¤ó(?Y&óÙenÅÊ÷Ùf<#ö¨L†õp˜ 5zÔƒ]ã˜öõørÔ›³fÕ!)Õëä,y„0Ã}“CôøóÇýÎQP UÒûI1 ÏB‹ZPdÜ[˜°óŽ÷]T€59gyZL2VX~YX“5¡JŸ… ¥§¡«Ë?ÄÂŽECRÄ#IæYÈbÄ1=£C,ôøóÇý~ 1"Šð<´¨EƽYH¤DB.„Áhžƒ46ªS3Ž‚°2`…ƒz´ ±"=r « 0µ«É?=»n…¹š§ €¢QÏæ=š“䣈Æ*¬G +ÒQõ5ù{äSÁè7M>¥¯RÚì|jf0`¸kqp ¶è°éÃ>?ƒxRí°ñoAa%F}…‰K5añó:¨õ<Ên6úŒl¸yŽõ…« ‹õ  ±½Gzÿ¥Ý¼+öËí¬üp†!Ãâ¶×汶­ÐWXºìnRà+m®©j?ÿ˜Íí69‹4W1€®ó‡2Ù¸³gˆ 1¾]9ï´ˆ½ÍÓ¿ûþýÕk[Ö}‰ÕÃAŸí#bÞ:¼ØÒùº”èk»$õßÙ[˜jo¥yýdY¶×lP©\[åØëVb ܽœ•IÎJO¼Dô. Åî{ûWxÝð`§k–¿B "øBÚ×ͳ׃üñö¦n`Úê&ߎŸÀF\r,‚Ò[ÐX|/Lê+ˆ¦]ñ7»‰GUJ¿õ’ÿד*ÿf˼5åóSª§,;ø_ÎÞÄ5ååN¿qÜ… +Kló8+¯Ï¯³Œ ©®lmí6)ÛçYæozÚ²Ô²¶µ2ŠpŸÝËˉ·/B?Çðéêyb:‡Ã”CATh¿H3 ,‡×r-ÉÚ¡9¿2@s½)C3¯á¿óß¿ýüüB>ˆJ9—à C©WJÛ*øØWÜkñ±êÿ×è"Rendstream +endobj +1449 0 obj << +/Type /Page +/Contents 1450 0 R +/Resources 1448 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1423 0 R +/Annots [ 1452 0 R 1453 0 R 1454 0 R 1455 0 R 1456 0 R 1457 0 R 1458 0 R 1459 0 R 1460 0 R ] +>> endobj +1452 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [231.137 681.3376 299.809 693.3972] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1453 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [324.1075 378.783 397.7608 390.8427] +/Subtype /Link +/A << /S /GoTo /D (server_resource_limits) >> +>> endobj +1454 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [359.1555 347.5161 427.8275 359.5757] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1455 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [353.6164 316.2492 422.2884 328.3088] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1456 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [370.2338 284.9823 438.9058 297.0419] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1457 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [364.6948 253.7154 433.3668 265.775] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1458 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [226.7331 222.4485 295.4051 234.5081] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1459 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [283.1811 191.1815 356.8344 203.2412] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1460 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [287.6042 159.9146 356.2762 171.9743] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1451 0 obj << +/D [1449 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1448 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F21 702 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1463 0 obj << +/Length 2955 +/Filter /FlateDecode +>> +stream +xÚµ[Msã6½ûWè(WEX|¬=MϬS›IÖqjI‰²Y‘H‡¤<Ñþúm D$¨©8•J‰Ÿ¯»€njLVþ#+-f _©„#‰Xm7xõÏ>܇Ùt MõõãÍ?Þ3µJP"©\=î{¶4ÂZ“Õãî—õ7ÿz÷ããÝÃí† +¼–èv#$^}ÿñ[;’Øo~øøþþÃÏïn_?ÞÿðÑ?ܽ¿{¸ûøÍÝí†hAàûÔY˜ùÂûûßÙ«ï¾ÿþÝÃíoßÝÜ=z_úþÌŒ#Üüò^íÀíïn0b‰«ÏpƒIº:ÞpÁàŒu#‡›Ÿnþã öž¶_Š Êåj`"ŸŽ2FX@Ô6ŠÄ\uQ¦d*ÊÊD¹ÎŸ6¯é!ßåÍy“MVÁÝØw¢RZÓU‚€†GMð`=ø*™ˆ!‘Ÿ²ÌÆ¿yv»¬ÞVùK“—…(÷†ØÈ«D!L¹ +QwF†( +ö[y1ö˜iŠ(%jà±}X=­ìÅCÏw_ð=´k}ß^¼4R%1ædáñ,xÔ“Кa‚Ù;m)BÌÒLØCEØ¡ºŒÁÿE^ÞJž Iü5ñ%=ñ®Œæ×uæ¿1!<É'tèmLx~ÁïÐîAâãñ xÔ“ÐZTx.4Kd\x}Ô¼ðj^YÕ.é?÷¶ÒÙWåq³Ë÷檟¬ØNýz§ÐEéxÔŸa_!Çtȧ +“ +…I>Šy2¹³L Šœt;Õ’[ak µ†#l×}—¢­…Ã/Ä ´;P£q·ScØZÀ kÑdxÔ‘КÕãF +¾þ ü±l|fÒƦÆä(Lņ àLÌ&Oì‚^›8™g•VÔeä˜Ö ”äaâ`W†é:XZì&,¨O…ïëCú:U`1 +uŽ/è·Ïenxµ›gÚw'-œšnô5Í駃O›Ñ‘ü¿²pW‡ì5; ˆ"™]ß ÂÏéBµÒGEÖw‡2~üž!Öª¬ÎSÕqB1OïQó«ãC±0 ð6¥JàƸ:f<¢"Õ1EÐ7Ò§ÑêØá|íÎÔ)á‰kÞ½0½G-ѬÅO,N–ÄvE´æ@í=š|sY©C¥1$µÖÑ©=(œ{ 3®‘T˜ &›wcÆ*#\LæUF E1{è…~Lc÷vlsöÇPa) Mm,ä´@bl+*/ª’œ-üÔGÍ Ì£.§À¯ÓC¶Ù—ÕöÜàí;hˆBŸ%áQ,†ÝH Ã6 ñ6[ÚŒ3ãwïa%"’ªMHߘæ|ÁïÀê—üÎ åµXJ€G- ­yåUçHnŽ)ŽuŒáI%âPÙcŒ×ßž‹ô˜o­?¿ìÒÆeðÇòoóÉÚI¨TµuŒû7£\¶ÿf>êÓËKY5¦VàP}.ípz€ôi“¿fvà˜5Ï家7 öó©J‹&¿%ëâÉlyV4eUþôܸ±ÒNô’UF5vpçý‚›SëW݇ã™ñ¥_“™Å5ˆÛ²0Z|:ÙZggG?/JŸ*ºMш//óåç}æ öº/Õ†ÛR­û¥ÓšÚ¼˜ÜLžúZ(Ö•le»þœ;Ö‹úÅhŠ¯ó-!ÄêÆd“ºEbZD÷{öã´‹ RL\é`[„tuæöžjS2cµþ\V¿×öÒö5pQ§Çîiz¶©Ãä¦ôÇrýb½xÍË“{òšU58é̧‘$²—÷ýluå`OÂ^vêjã ‚ ŽÊt¿§¾Žy]ûß + >O½U“ç~¸·eû¹ó{àT´›«¼˜¨•‘WèrV4Jß\!è3“Q^(c뼶ŸEöÙ bŒv‹Fûaäj/ŒÜ׎¥o àÎ,Ÿ"Û@äó"shXUM‹)Öp ´>·m”¹º¬Wcß™´âÀ“a†ZÙÎ$œ²õ;@±®³¶ýà.ê2¢×§ƒí`„uFÍ‚È Ñl×. 4`óÉ. ŽXgéöy`à ç­Ê>èÔÕNXÙ绬È37vÑŽØw(×]¾æc8Øžlò`Œ-¬ú4_Êì½ÙÎ ží 5n.*û — Íb“7ÀbÇ _ßï-ÌÊ—mÔOaÖ̧¬nìC V§OîiîHš¶f9‰¶gn;å‰m7¯Ý.•7ÝzØN»®Ý¼Dýxüéþƒ[Uî ˜)pÛUN¬A3þÕh•¹œ‡ëÓ?né;óÛÔ-ÑO¾ÄiLR #¼‰uúà´&U¯[†›žàÌ€´+Lª¹…0„¥¯‘®XÙŠ“îHq 7¿Š¸¥;$pq8Ûác–šl¸?ì½Õªy`û€nlÙ0IÖÿ}Î +»>‰Òp¦µ'Éh pÍüŠŽÅõž%Ltèºð’g´%ÞTw>ÔðÀøš+¨"µ·—Ã=u% f•Ý™*{kÝÖs™¡ +wrõAH¤œæn²2ºjCÈ´ù3:\ø=ÇLÌ•š9(û÷µ$*™à¥h§ÅÖÙŸ©ÑymÇíê€a¿: xoÇR{ë6ƒöwóÒSÛÌÂÒÝÎùU[@îæ0¯”¬ž(ƒƒ-¡C=Ù/²×Ô„cæ‰rl²Éƒÿ±¿üGF—¿Àâ +1óÇ9ÓíÔ…š&ª#eœPÁ5PÖ#¡©š þ4A‘endstream +endobj +1462 0 obj << +/Type /Page +/Contents 1463 0 R +/Resources 1461 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1423 0 R +/Annots [ 1465 0 R 1466 0 R 1467 0 R 1468 0 R 1469 0 R 1470 0 R 1471 0 R 1472 0 R 1473 0 R 1474 0 R 1475 0 R 1476 0 R 1477 0 R 1478 0 R 1479 0 R 1480 0 R ] +>> endobj +1465 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [381.2254 737.5325 454.8788 749.5921] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1466 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [362.4163 707.2832 436.0696 719.3428] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1467 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [402.2465 677.0339 475.8998 689.0936] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1468 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [348.0303 646.7846 421.6837 658.8443] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1469 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [335.4973 616.5353 404.1693 628.595] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1470 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [363.1733 586.2861 431.8453 598.3457] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1471 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [365.365 556.0368 434.037 568.0964] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1472 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [393.041 525.7875 461.713 537.8471] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1473 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [402.9837 495.5382 471.6557 507.5979] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1474 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [320.374 465.2889 389.046 477.3486] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1475 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [348.05 435.0397 416.722 447.0993] +/Subtype /Link +/A << /S /GoTo /D (zone_transfers) >> +>> endobj +1476 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [488.512 404.7904 561.5676 416.85] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1477 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [397.3443 374.5411 467.1586 386.6007] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1478 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [321.49 332.3366 382.69 344.3963] +/Subtype /Link +/A << /S /GoTo /D (options) >> +>> endobj +1479 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [317.0267 302.0873 385.6987 314.147] +/Subtype /Link +/A << /S /GoTo /D (boolean_options) >> +>> endobj +1480 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [356.8967 271.8381 430.5501 283.8977] +/Subtype /Link +/A << /S /GoTo /D (tuning) >> +>> endobj +1464 0 obj << +/D [1462 0 R /XYZ 85.0394 794.5015 null] +>> endobj +474 0 obj << +/D [1462 0 R /XYZ 85.0394 256.8016 null] +>> endobj +1106 0 obj << +/D [1462 0 R /XYZ 85.0394 231.4888 null] +>> endobj +1461 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1483 0 obj << +/Length 3014 +/Filter /FlateDecode +>> +stream +xÚÍZ[sÛº~÷¯Ðœ'¹c!¸ìS}'õ¹8©ãN§““Z¢-6©ˆTœÌôÇw R LYJÎt|ä£,û—ÎTêÌè>8i*GËm3Z©¶eqòþäoè×ÔŸàL*+(ÕMʬ‚.Tàͼ¨iQm9¯¨’Q±>uãÍ"§Yþç²,š¢*©eQUŸê?£"^¼Ö"šŽ&2eÎ9?ÏÜðÓ‰å||¿Îʆªÿ¦b–—ߨT‚j46EÚËl™7ßVùö‹j¨À®šªI’ÞÂ[I’Ô‹r‘Mç »µÑÒàÃËUS½Zc™ dEÚVëâK±ÈïóТŒ¿-§ahFÅ2¯ëì>§¡ó,Œ«7Ó)tÜm‹o.k¦ó|ÖD9ƒ¯4œ«U¾Î‚²)ì,$K‘~AÅr™ÏŠ¬Éý.¥¥ø œ£µ@£_ËŒêY*eEåÝf s®iD¥´ëSáÆ9}ä_³eQæ3P–v|N­[=‡ÇpÙ®æyI5ZTê⾄{ë¡CM#‘N½v"°a˜/fgÔ×4 bÒõ']¿kPsQRc6V~¹³Œ6úŠf>À…àq +¢ jöˆÆÂ*Õ¶Þïmõ*Ÿžû,Ñr€˜jAÖÍ°TÉÄÏ}U!`E«q¨K¿KØF›ûySPeF½w՚Α‰Ï‘†9e€½_Ñt5©óÅÝÀ3‚))’@8ÌK2—˜–Ä6•ÞË,a2MU ë”¡EÒÊ[7 vê,^PÖd™­VEyO½/¨Xêî«WÜDª„)¢÷6oZ•È©³yËMÝD{¸³)P÷nŒ ÆwÛi M `9#¢-’ý‡–Œ>ŠÅlÚé¢=h³(¬—"!ÄøŒÆ5t ýãÒ›än§ëæýå›þüЀVž{#>p¬?å°>ÅÓñ¦ö8ƒZS‘XˆÌÐâ·‰V3°hToAš× 0.ÿðöû2*n~½ø'Õò¯ÓyVÞ‡¡Þ ã·ù©ûAð±#”Sš£›2°­çÙö`  y lÎöžr¥c à*Ë®»ÇVÇlÃð: ™»1~/°–Õ;ìÌFŠ×ݲ±¯ +¬6@c§´ðx”×èÀ[ýzDÙ xLŠ4jœ-êŠZ‘ã2¿¯š¢½Èð4æͼšQ¤ÂÚí7*ß¼?A|Ñçü C&Ç€€ìvQÔÁnJ0·aòèÐ)Ò[ÖÐÇî¥)¶[%R3þ5_ßæ^ûUM-pÓ—Ób•-èõ‰e7bº(`2Žûë}NÍY¼ Û9—€×Å]0_?Áb×™WäYµÌŠò§‹'xÂLj[C Š–© oylQuʼ£H.A«ŽÇÜ.±ZÂÎÖ ãØÖxs¨À¡ÔNï˜C44ÎîG÷"ªX ‘7€jºýW>mˆ®©¨ñÕÕûaVP¶ÊJ´¸žŒC‚ûûnïèÅ‚šÁÊ“d»Y–›ES¬ZÒ ™ݸtß êV¤LXp*×€Ÿ.„ÚUnÿÒ€ë¤ÉÚ»’ +ö·D°äxážr‰½ahq‚„^`e”IÔ1>qoØnBp°Wðfåêá>"¡´c OvÿݨVŒ¼ÃØ+ãÀ+T[ëÐg5é³,‘JviŽ¾!JÑ.{&™„Kô ;”p–"RãÅ×lÚL‚G¯gj™¡o„¿u<äJ°§»|ð£‹ãðƒ]•èàHAS;ùîUs›ûxM;9»³~"†®™)º!>¾¨vâ ¼FrJYòúÚîÇ·€„‰¥Õî€]¶LwWE¸ÄàÒi‘‚‚£mxÞÖ"ˆw®E‹ú¡h1j +™@‹ŒN^8}Ì´é3§ÉDÚ‹6÷ÑÆ«X qÔ:ˆbܲͨðM†P´õª»³PYïÐÙ3$œc\KóCmÍB2ÌYc¾ƒe;b?‚„e©Nôið•µV‡üŒ] WW‹C§¢„D§»›²ÈcÙyÝÊ’×ÞëÆJßëÆ–ØëViÒ%³Àä‚Úm²íRœ*#{¨c{¨ekµlKÀ”üØØ?¦i* Ì†B8ðB‹`3;ÁCÙWâ¥>Çh£Ÿž-[äx–툽xTJ1‡î?ŽžH¿ïñ#†Œ(b»Ÿ"µÛýÄž‡…&m8lÃnaSØOlìöÛ{‚yÙµc[[¤¤¦†Ô{l„?p¡%G„clVªvíÑÄ(¹çäÐ!àUOžPÈ[ù‹û² +JÁÒ5sȹáÛ?œzÏ« ^ƒ©*([;雩áºL¤Å½ 8.Ò¡ßËñQ{Ÿýë¼íO!lTÎÉáÞÁ†"€‰2øDKg?q~<ØþŽ¯%‹„ÿþÍendstream +endobj +1482 0 obj << +/Type /Page +/Contents 1483 0 R +/Resources 1481 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1423 0 R +>> endobj +1484 0 obj << +/D [1482 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1485 0 obj << +/D [1482 0 R /XYZ 56.6929 512.9872 null] +>> endobj +1486 0 obj << +/D [1482 0 R /XYZ 56.6929 501.0321 null] +>> endobj +1481 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R /F48 940 0 R /F62 1050 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1489 0 obj << +/Length 2789 +/Filter /FlateDecode +>> +stream +xÚÍZYsÛ8~÷¯à#U!8ûæq쌧f•¬¬©­ã!‹5©ˆ”ϯßn4@Q‡íÉ$S»•*l4€Fãë Š8üAªWY$YÄ4:X¬/xpcï/„ã{¦ñë»ÙÅÛ•Ëb³å`­”ñ4Á¬ø%¼úþòãìz:KÍØÆ:æáw·“wDɨ¹ú0¹¹}ÿÓôr”DáìöÄÈÓë›ëéõäêz4*ÒPn‰Ÿ?L®‰éæöÇëÑo³.®g½ÈÃc ®PÞO¿üƃN÷Ãg*Kuðœ‰,“Áú"ÒŠéH)O©.î.þÕ/8µSÏ©)â‚ ©U0±f åóûÒöu]¡2&¹ÖGû¹é”Ë”%™V½ò#1P¾ˆK•ÒA¢3+©¬ö㮉ƭ©–¨ ·7@ÝÏH8ˤB!󲪚Çœ! »•¡ΦÞf;ih~å\~vL ¶i8w¼»M‘w®?¢6¯]gvõ‘:‹¦6‹®lj”v Á2­¥ai7iÖ£±ŠR’BE^ +$Õ¦{l¶¿¹Ùñ™Y‹fK2·›¦.ÊúžÆo?>DÄãsBnV 8SZ„³UÙÎâ(¤V…eÝ™º0QQØæ¤?d˜Ü %ÄöÝäòŸ×44¶¦kg‚ä »É Ún±Å³a‡D|0ÛÖ:¢vlRD,Ñq$‚³HÄ韱)#¥€®³–r&1‹#þ%èö3ŽÀÝ‹7Ž•bI=n€j-Ë@J_öã,a"µÕÑd€jƒÀhœi%#‡ê£q wexâ$pQ¡`­Œ›ki­:øÆ£,SÄ5èÛãîÕ` oo×2x×À¡‚á¹üÊãáÒö\àö&(u &-¢ ‡Á5O¬Ð·º8e§(+ÓlMW.cO4´iÚ¶œ$+C ¶÷fyØ°Š…K’’9b§œƒ1¶#¡ÃìD*ei$eàî&ù÷ È⩆û޻ѯC£Là†x+BdJeö <.¸ ¦ ~}‰8'áÉQðøk³¼ "ΘJÜcpüàÐÓaÐ9 >ŠÇ Οä8g¸èÀ’Nc4èŠ ¼! ¸šÜà‹:‹ñfïu¬™éá:1`C <ê|mÎD3ˆ‰Žc‡©œK[ïÚŽzíÆ,Êå“€šå€>þ´Ë«ÒÎr“Šf—NTÜÑ"6gšA“€ö„eJ:ZaÝPÛ=m ú].Ãœœ%ÑÍçMU.Ê ¿­8´)ž_ÀL +0¶¥á®r×y·X7BŠ;ÜÆ|^˜MGäéôîöýêOî\çîÃeOº¾r ÕÍF’bçìx6Êxè¶I3%b$ NàžhU*Î!„-ªEùlìròl|hþþ¤0B'j·¡?)ÝQ³.ö$õæ\Œ{\•‹0©‡«@JŒkD³'R>µ(@(A™Çá¤éÜX·Ê;â~\·-•†y×™µ ˆö¸Î ?µ!Ja*ã—£ã‘0I¶EëFÛ¶Y”(‹Û²ìVnäÜM9……n‹¡Ö὇"ÝÊ,~÷X_Úä:&·*ÂÞç²íèÎúÀ èv;aÎÁDLE± Ÿ“S HJY!SPsÂϹ,º¬Ì~ê>òrt-,ND?• 7yˆDX¡Yº¤Ý´Ín»0þ d,üyk'é¿é²ÉÍO>—™­ÌúŒ/9 dKkÖ*•¼›‘mN‰àNã°"­Þ´i䘻T°yDí*}3ÂøôæŠÈP)Dn‘´‹m97-PZ©mK`G*ž‰9}ÒÁqå…ãž.9Ю¦S²›ú8tJàépo!°•P H+ÝØ®5ØD”%áµ!*I 6»9x·Ü&ÜvÄJ -:þÈ“°¼¼"zmi ÈX‰²ÊÜòsã* SwÞÙœ9HßåzS™50{|{?ÞÆ»Éëà±p`yÕ6~2º/<¹ìN ]•Ÿ¯=bÏCóU°]¢×Iûøƒ}ñ — uÐÒXîXšÂàݤ*¼¦‹sDê­òCv( hA{GÜ» Hµ¬Á5¬sw)½ÅA ”«Ê°Eÿ÷4ÆØ9<£jI¸Í¡c7ĹÍ#>ܜ؆¿É#Új6ù×Ú¤ývzƒž…0¬¹hÖÍúüþ­™¶ Ä/!–ý ÉÙÊœš³2Œ +ÊLRaæÀ º6²TÁ½®)*`[7ŽÐ–÷µ½LHŽdAl™Œ)ŽØIÏ}}Üšíƒåv-¯C +zª-ÖlöÚ¢^ÃÕ€ÖxùÁ,¶çΉê´ù9é«u$8 Ò÷àé0Š&Qh“˜$l›­ ƒ™ë]Õ•›ÊM·º’N'HؘíºìÈbá“" +·éÊuù‡CåÜmñ +[·YÏi>çh÷gc¿÷ûùŸ‹æûLp›ö™|;w̤NêÏûB¸ô/qÛvŒnãΘãúFEÇ" —à¢3fÜÞ» +o:Ì°=ÿx8á4Å>]Ï{çÞ=Ü;²@‰xRs Y<”¯Ã-Nš<×+’@ÁÏÀM‹CI\Ð9,õ4ŒsýgUÑó¿&ÀɺϪ":– ªa¦°ÄxQ=×+’œ®†’¸ +Š\&3ÈpJˆ™MÖCÕàå|˜ïx7Ù–A^æÂØ?ŽØ¿íI(õt’Æÿ«Rsàe¾ ~v3ž}°”:a±TÏÜHÿ`)cÁ$9…æ±öMn +‰dÇ õÑWîÓ„>£˜ºGç²õ)õ®.N_9 "NbH“‡Ò~öR±ìÅçç“%ýŒç•Š1hÓ¯(5ʘÔQF¾’ôÑ8Žb^¢ú²84õ¢¡ÆL‡"ÏËŽòjg¨ë¼10ìkÊÖy»4òX«Ñ¥Ð#kªÈó³c³9,i^¸© +¾N­û›Šð¨üKž¸üŒgoJ€¼i&_…¿ÔP§Eô¢9›ý¥3î@Ÿ€>˵C´á¸*Ñ*;ñÊN4€ŽWiÿàdOÌéSIwã@Â÷ì{kvÈW?_»º´.PQŽŠm ×U6ðG¾¼réØ6ÛroKû¸Ÿ»Ö8†¹£$AD²åι„aepR ÅdÓ†º”BÄuúÂÇ^T!v%~®èyž‡Uc¡Ø樴ˆ_·¦ÎülŽi·-|¾±l†N§ô¯Y«fW‡9IQ¶‹Üå§/ z—¯ƒàßê ³aY*_ó?"I˜–î½aQA¸˜;” P:p@ÙÞ¥½ÊŽŠ,Ëi€ï¦kME”e¾FÀA±ð¥‚+"Û.¯½ï9ŠéÃe_¸².¾•#ú;®L¥ŒãÎ+W¦‹…"G4}G?ÅâŸK|`ˆ#W-¦ò\qÔ"ïr0FH÷öœT.Rße©p¯nõl-EìáK‰y&x¬ ºFÜ-Äèa¥¯*l÷Âí Ôò­nïÿ惎vø3õ ¿üÑ,‹Ò—2È qŽåaj¼lðgÏþQÒ¿×Ø• ASå~  Çã3?(pB;.o“àÊÂçtíóY4¸œ(K³¿®ý}U!Y„åTr<Öé¹ÊƒÞ©|õÿ-Øÿÿ +pè*Må3u¥¿/(ª`-òfIvR7¬u*÷láÿ êê]endstream +endobj +1488 0 obj << +/Type /Page +/Contents 1489 0 R +/Resources 1487 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1499 0 R +/Annots [ 1493 0 R 1494 0 R ] +>> endobj +1493 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [341.1654 298.8688 414.8187 310.9284] +/Subtype /Link +/A << /S /GoTo /D (the_sortlist_statement) >> +>> endobj +1494 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [434.6742 298.8688 508.3275 310.9284] +/Subtype /Link +/A << /S /GoTo /D (rrset_ordering) >> +>> endobj +1490 0 obj << +/D [1488 0 R /XYZ 85.0394 794.5015 null] +>> endobj +478 0 obj << +/D [1488 0 R /XYZ 85.0394 509.1791 null] +>> endobj +1491 0 obj << +/D [1488 0 R /XYZ 85.0394 477.0735 null] +>> endobj +482 0 obj << +/D [1488 0 R /XYZ 85.0394 477.0735 null] +>> endobj +954 0 obj << +/D [1488 0 R /XYZ 85.0394 447.2177 null] +>> endobj +486 0 obj << +/D [1488 0 R /XYZ 85.0394 390.5598 null] +>> endobj +1492 0 obj << +/D [1488 0 R /XYZ 85.0394 368.2486 null] +>> endobj +1495 0 obj << +/D [1488 0 R /XYZ 85.0394 281.9323 null] +>> endobj +1496 0 obj << +/D [1488 0 R /XYZ 85.0394 269.9771 null] +>> endobj +1497 0 obj << +/D [1488 0 R /XYZ 85.0394 89.8526 null] +>> endobj +1498 0 obj << +/D [1488 0 R /XYZ 85.0394 77.8974 null] +>> endobj +1487 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F62 1050 0 R /F53 1017 0 R /F21 702 0 R /F39 885 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1502 0 obj << +/Length 2893 +/Filter /FlateDecode +>> +stream +xÚí[]oÛ:}ϯð£4\~‹Â>¥iÒúÞÖÉÚ)°»÷ÞÙV¡Žåµä¤Ù_¿3Ê–]ÛJÈö@9Q4uf8s8TE‡Ã_Ñ1–ÙD&8ÑÌpa:£û#Þ¹…{ŸDèsRw:iöúx}ô· w–Xi;×7±ãΉÎõøÈ2ÅŽaýû²w~|" .º_AJ}9½º>ïÓ º~ìö>‘&¡æì²wÑýü½zëèº{Ù#uÿüâ¼Þ;;?þëú·£óëå”›¯%¸Âùþçè¿xg o÷Ûg*q¦óœ‰$‘û#m3Z©Z39ýc9`ã®tLš &¤Q¥™ƒßÎÏ*íXÌã?Ë;'R±Dp½{,zŽÃXA¤'ÔÆP'‚'LÀ?`FeX,E²4£T 3 +a˜vq'6‚I F3žŸØX[l•TÑ]QV$¥ãñüX¸(+K4žL¢î”îTw ݵ£IZ–@Önæ%i©ÕQJ—Jž ó0v÷jËo€¥;±f‰1ÞI€Sü”•£y>ÌÆäù4øÈÅ ‰a›Ž¢MÌ´Hàm˜¼g´¨ÿ¯g'^0dý>»M?[ëZL'c¦ŒÒd:øs|¢µèƒ%0Öͦo‡Ï9»¾Æ¼^÷®+øÀ"Îó‚!ë'vÂg]Ì.T |ÐÂo[bV‚ëïOD×ÞñÞ( À 3lú5^ÎÒy•§“_ NrÃCÇrqƒ·þä\þµOLÇa¸éîOÇ9;ªò—!ت­_Ž LÓû =ÞeÔ/ŪG˜[EWÅÍÆk³GÎïâÄøÊíqJ3êÙ|€’@ÁƒíM±˜ŽKžDç?gÙ<¿Ï¦U: ª¦oBï<½%Åã]>º#†¸"i4É¡[x" ¼å°$ÆáÁ¼ºÛm†jÉjÐÔÏä‰:†mÐNÛ5A9”í4 (yü‚!ë'vÛNk¦íàvÛÎ@¾s‰ ,ð)¬!>ßÏf“tä×OG¿„@÷©‡ ä°~@*gÙˆ–ܘÞ.^‚%W!MÛxXÝN³!©‚¹G“¢øªDE‹ÙϢ̳ËdˆÙä‰zúõê½É_Mét²%?}¹VtQÏ b†[¸ßò]¹ªgÎzÌRÎÓðjƒLº¦¡ÌgRw$R[øvL÷Ó’îÑ/ÔQ +#d9kÓ!XˆñЋ +d1ï½}FB›wKHG{¼»á6¯sÅ7MFrf¤k‰LFYÆc"Soðûù¿ÀÜ*áÑ *ÍAúx‹A3[ 'ùˆäÙSHΈƒ7‚g¯ž*óÛi 7ü +)ÿ[LWñæd·«·„"®öl š(6ÔXÀv˜®…*!™°<„¢nY¥Y3”H‰‰îÒòŽ$\ئԣ¶!ª¼ ý½µ¬¡ƒ —O™¥ QFn±…„5»¾ÆxMT»›8(ÏÕNƒUz¿ñ´s=@Ÿ¯.Áxð˜ˤPn®ÛI1¬‰î¬(sÜöT‹Yéf¤¡FvVâ×˳=x6&úŽ©­¶œÅ°ÓjÁ3¶L&ÚyD¿t{—©pr“ÛŠ8` +ÂÙÕw¨Ò‹ +"`(y$áNJ—XÅ´‘¬(àŽwfèø +’Û|ÓwLr5$ §eÜbØ•Â^€\¼{58?óÉDÆJGW>B@j˵PtŸUwE*úB¤ˆh¯‘Êl«–ê{ˆTs_kÃ+´EˆK¯(k.÷«Â{N%$%Û¢‘tLÇšpé>õŽO 71’ÚL°bA¥&#©>h°ZO]åZ0Ãm @<7ª^÷ŠÜ¾¿ØÔ|ÓCä ÊÑ*Ž·¶…ˆi®™±ŠÂ™_8Ñ: SÊ/lê Ž²Ïàþ^#ƒã5eðÆSžy¡vzÆšè{YwÏ÷a=ÞæSŸŽhXݧ šžß +Iã#(u£@ƒ7æxD$•‹†‹jÛ®¢¬òIÈ}!2ƒX%Hƒîg,Gs,6·2rYõ1kevP%jÏ.¶i·ÃV”ºÞ•QLÛB•uÌ&Ž¨ãïÿê(”ØL•°þ}™ÍÕÌ ûs{¶[¿3¡:B]5pΛxY>Pëå è²Ï³V›.©øc4ÞòSA¥“\´_;ÈØÑR ˆKtá±…€¹LR&À¤Í§7…?)QkðBïëÒ(A!\lC×õ€¼ÝÆ´ßñÁžâ†A¤j‰¤JIæ”$x¿«›Düâê˜À°Q@$ò Iµ¯Ó¹z}Ä,K  ±HªzaéHåBoöä½p&7õU'¢‡t²"F¶Iñ藜㾪‡êaVã Çkp}SL°×8Ü}¢–& Ñá=ªBU$Hâ[bírÇ©Fâ™»¸$Ö^tß4ä¡Bë¬fÈÀhy ï•°KMlL¡µwzuÝÇâ®âQ€ÇŒ³–;Ï«§z;—OÁ–ø™Ë N-ùKD»QmN÷ '2-iAÕÆ…$í N¯ÔØùoS|­:«‹ùpšžÍòQõh´:™C 7 HwÒ͘ïùú!Ìû †ºYƒTÌŒ0-UmØ•1àû]¤ÖE×>¨xé¯)ÖI¢Ht¬L2IåBQuíÛg³æÖê™<`äh¾Ý;>Z ÙD·ù¸†þH YáüÌ…\ÍɵGÌ·KÚL—þshag¼ Dâ‹üþqŽ§¡¡ß]Z‘Ôï‡Gæ¤}™S4±–uúÐÿp2¨I©ÁÓ×”trÙKD>´=àVAûœF)*²ŸyYmŽ·%+aZ,ÑuïWôn õûÔVO3¿MB»úäÅF-)¼×ÒÐÔúIl;O öÂñ½EͦkêøvÉÖÙ—,Šú‰,¤eœ»–óe LIHäµ+0©ú¿ ¿;ÖréÂàJKSIü¢"ÎKRÜP­îË©I–$ïʃE¼&´av0»rÛ @w²éâ©oJK¨Ã€¼kÄÀȋ嫃vTÜÏTŠJ'ÞGb¤ê³lZbrÚ‚»Œ2,¼ŸH^¥*–¹ e2Š¬?‰ƒnõa:)Ó0 "À¨Ccå+ï'ÛÞv OíÉdÍöºEû¦åÁ%ãIË—RBÄÌÂo¬ÂÀÕq"£Óþé7 ÖÖáÀ†p`×à áÛ ë>^òVaƒŒ jiF鳈a xºÿ\èÖzý9Qíbþâv>ép.q.¡òô̈ßb鄯³ŠæœÅÒ:üŒY»õuÞi¥ìÏý~õ_ )çvPJ;pxŽ…¨;þËÇú‚3©¬¬{5¦þ?ʽ+fendstream +endobj +1501 0 obj << +/Type /Page +/Contents 1502 0 R +/Resources 1500 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1499 0 R +>> endobj +1503 0 obj << +/D [1501 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1500 0 obj << +/Font << /F37 791 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1506 0 obj << +/Length 3252 +/Filter /FlateDecode +>> +stream +xÚÍÙrÛFò]_Á·€U"‚9€lžYŠ•8²–b6®Mò#kà dùë·{z†iÊZ®R±Šèé9Ñw÷€õ"ø±žŽÃH¤²§RÆ‹{“ÙIÔ»‡¾ŸN˜3ðƒÝQ?ŽN¾¿ª—†i“Þ讳–#­Yo”ÿœ¿=»] ûGAöq?^]¿!LJó÷×—W?ý6<ë+Œ®Þ_zxqy1¼¸>¿è˜1‡„[âßï¯/hÐåÕ»‹þ_£ŸO.F«#w_‹EÏûß“?þŠz9¼ÝÏ'Q(R÷¡…,Myov"cÆR™žÜžüsµ`§×NÝE&±ñXÁ’«$Þ¿-mÁ¶ŒÓP©Xoí +o­B+$}¤CÎ×”ç¢Cy&E¨…ˆ{ +ÖIô!é¯?Œ€V’‰à·ÆäýÔiPVøÔÁ›ëÛÛ‹sµ5=3Y.úLfúäGçå$kWd-AÃaCÀcÙeò §d˜Æ1žœ!ÀíAêÇÊ,`gA•Íp5Îé$€Éè11‹6#_b0ª5‹‡lJø¼v«Ô-æSÙ´Ûëá9¢Í|®+XPÄ œ3'`ýnØz´ï†ÐpHÏöinUU?§Fc*7á®^ø¥éi5Ø<)CY̦݃Ҿ ²”Üñ‘ø<A½(ïË +߱ĩ¨A{ϧÙÄO?ÑóÚ²Ó-³ƒ´Ì¸l`[Á¢ài&‹rl—%²{£Æ]žr‡Ûj%A¯T’ð^G¿NÀ…Ô¡cÑp¦Uõ‹%ýŒ½:“h +&Õ¥IÒ4Ôq"-nFC40" ΀PRóÚÊ 5PUð™9Ï-AõVòzf…aj„š9ðí0ûìR’—Ã,‚w?À¢îËA·y$_”GIÊHŠcÀ"‡Ës§àiÂý6í¨þ°D`Nç­_–9/«@" e*ñ&æàmA·‘.ÃË\U`gY[ÖHÅÿœ›ESW 5­ç€(ÇSCHkQ¹¤Gˆ!=BÓ¥Tpñ –Àyƒýì)g`Ÿ³é3cú³ÖTxͼb<Œµ8jì¸Æ …ŒÝpx{õ¸!°wÁy]¡¶Ž­Ý6yД÷UÖ.½DTžµ—EQÜ¥/vQÁ-}÷rHFB yçm^Šè`-uÿ§ågì%z¬’P1Í=’!gΨûB#Ô "X/[3h 2dË{ˆ¦¸ˆƒ1F'6X.À@ ¨›¶!b1„0&§‰ì¨ìÁøA¦tS!ÛÏŠ¼$ÆN0”Õå† ù`Œ&£ sZ/>º®MC9Ð^3ת§•^ù·èoy¶ƒúØ%ú×1òÛʆŒ ¬àÇ2Nà 2M,Y¬:Æ:M;ê¨x´ +×ÞÒEDy]D˜âI„¬ +"âU<¹ß™ùS°x+Æ„ÂƘØãÌ¢lP¨•8…¶`ÁxÙÒ€¦-§S³Äí’k`7¬úgGü±£»Yǧ‘GT*Ø©é°ã¥¤æÄC1K ÐáÇâ¡XðPjI„¼}†‰Ø«t¯ü3Š¸ ˆ[»Ð¦µaªõÄwôÌh%G˶©iŸúŒ±ÀºÝ #cJçÎùÃ!j÷]_±g•©€øæ˜!%Šx,Ë‘›KÔcÑÕcé í³‚ð­©r›|SOËÉÁ— Hœ…fÙ£aÕlâp_>§2"§)ë(ê1|½Ÿuš¼fÎ%);ì˜ E +“DPLt;ìÇqð/L¹ÅŠòƒqmM\¢ƒGc-@+ô¯\ùHl4fñPNlZhã:Ƶٯ6¿ÿrël!râhª¡4?À© ^q(e !;f÷$$N*Îîݾ½¼ÁÐbÍíT0¶ÖM'ÁcöDmÌݱYæžùr<-›‚º3­G¹Y…å6v}4Oß5„EK[HCîÍb¾(«ö¹:Çãæ²K¢—â¤?ìó—ô3ösRˆÇªá$dUZr²—#[ªL €õS˜O-ÄÅ¥µ}æÏ­]ö:Ýó}Ý;[Û¥BV}„Œ\†Z«ÄÛ #fÎv+æ±·[>å¤@0q& ‘΄!¸2a8›°ÓýBÞ,q9Š¹àìö×ÑMŸñ48¥¶ËVpD×Ü,çózÑzæ¾-›b f{YØ¡Í+v?Î QÙ±¢½Œ¢0UŠˆùÇ9Ä*šN©Ù{ -¨ÈÏ!Ehís ±—©(ÝÊËöF _W&é¾íK1e}Ûrìúç¨Hm]ßü³üA¸N¡€i膑ڼöùâúGD`Ðxª0™T@T½‡ïþnJ@BñØ@¦ïêé´~ÄÜèüý¥H;3 §Ô¶Ã)“i†,¦q;ð4äBãlP¿²¥MMnmbvZX§¥+Ï ðƒÔ¬Zë0õMË-!iý @FømY©„@k•J¾-G£oâñãa©cz.˜­#’®]]÷ Þ­8…×  Ê4¬³ÏKy®oPøà +´EË—D$ÃXèÔÝãmX¯ó"« Âé:C… ûÝ^CM±nëI=%ÌÄU¨Zkµ0@o©ã׫!¬„‚$€Y™Xª¢CåýaÖ ™ @¾8 ¨ÒÖâ(V‹Úóåb^7_GTA4-¸c!¼ ÿ®ÙU!/Ëi;X9JpÅfáÕ®[]&ñs·&¼OÉ.€´uh¯€­`QÈ.ÀZ L±Ö¸Ãˆ(*ÁÜØý2Ùaö+®ÅqÉBænäÈ$HG˜(—¾…X*a @o Ð)GÚji/y!áÚb€ZåzÔÈ̓™Ösª•hº¤UV&mæ ËWþƒE×½Rx2[ae/æ:¸Â´/º1ä^$co%Óë›j{#ÞÍ]¡ßç®Ð÷-ÊzéVjžšEÚÖÌœCÀã8kVöeȧYøÞ{WÍž{„Í «`×Ôô!Ü/_픀½–¨B` å3£ +Î õÅBñÁ¨‚¥ e9YGŒûAw õáÆuÞµ¦r¨Ù|ZNÊÖVsu°ÈÜ-7·1¼„Re/'°á‘Èàûš@l¹+q»¸ŸîvC.k·²ù”Á¶Æí9˪§]0йQɺ,ß +V•M)——öpµ¤ †ÆYc Ø"£D2| ƒåÄ—Ò›Õn~á¦vvÆ‹ûSúJÃ]Ë`RP*£cú.qðÖ°ä5ª:·‘¸dÒrdÇËÑ 0'¢[Éìw(\rKʆPë°LúÂ.Xƒød- Œ.Lf‹ŠÔGø X +Š<½Ãsù N/ÝN¼mZû ¶‰(0 ³E{<¿BÚ/ypš– ïrwX’ Ôy<Üð }ï…gî<Ù"¾ZÛl˜•1>Nõ¡íªowŒ;6DU4d>Å WÇÓƒ¸ H_à43“'°ðmEXù¯:Ô#Œ-´OsjXuR¶îdG—37|ZÎÊ–Öó¨]_M»cAŒýþÚ“Ì»e>š¹[¥¬6všd“?'I ~þ´ëYËk[Tî3*¡@‰çsÔÄY_‚(wîãÁP:‚è.èøï׺>·x6mÜRH‰œàN±xí/Š wì7&êzÞ9VŽ ,˜c¼ôgG‰Üå²ì*©´GÃìäräqÄ·Ô± +u¸ÁË4{8÷)>Wkd9Ø9P0ƒÖV¥Î:àÔz,ÌÊý®—žn€r7q-%æ +¿åt§Ah€ø¨šá©‚¬H 06ôtÁ¤f®¸É<ð¬ülü„ Òφ.©·X¤¨ðøLÇ­WÛàbì¢S„ûÅ:Î02Ç)ÈÛÒ¸‘V#áé“™]ï67 ˜T¨4Ëû{ӸȄ´Ÿ Ó¸(B\ÔË© |Æ®›î \:K¾‹;'„ß,<¹UˆÝ)`))„ÇÞ´‡T»rs3z€µ¯îwÚ6RXžºS!½[Ø9¦&èÛ¤ö›¥NøbÑ4_Òå+ v¢³¦.Îë,ãÓéL;€­²Z™r¼_BT¾\8ïM¬ÜÁ!Z÷t+\Ã`Ôg>íj|±hœM>ºa.ª+½åFfû¼å!›.¿¨tlÚpÚ<Ü÷I¯À*“`»¾ÀzG“ûç~ï»þæYªPh½ç^bùS!õ4Û>;ä¹a¬¹ÚuøÿV!Ó•endstream +endobj +1505 0 obj << +/Type /Page +/Contents 1506 0 R +/Resources 1504 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1499 0 R +>> endobj +1507 0 obj << +/D [1505 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1508 0 obj << +/D [1505 0 R /XYZ 85.0394 337.2163 null] +>> endobj +1509 0 obj << +/D [1505 0 R /XYZ 85.0394 325.2611 null] +>> endobj +1504 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1512 0 obj << +/Length 2929 +/Filter /FlateDecode +>> +stream +xÚÍ]sã6î=¿ÂÎL¢?ôÁ{Ûf“6^Ú˦7;×íƒlѱneɵädýï @™väì^»w×ÉL’  ‚“þÄ$I£ÔH3ÉŒŽ’X$“ùê,ž<ÂØ·g‚q.=ÒeˆõÍÃÙ_nT61‘Ie:yX´ò(Îs1y(™¦‘ŠÎB<ýçw×ç—2‰§7·?$”Näôê»7?=\ßÓ@ʨßÜÞ½¥CŸ«ïnn¿ýùþÍy¦§·?ÞQ÷ýõÍõýõÝÕõù¯ߟ]? ,‡Û±B~;ûå×xRÂî¾?‹#eòdò 8ÆÈÉêL'*J´R¾§>{wö÷`0ꦎŠIÄ‘T©‘“TcrJL”*B9=,-ì ö^}APÕàWL{?tÿ–öÿÞPWgç}Õ6ÔhŒwßÑ̪£Žy±ÙT¶¤FÁ¼Ê¼]ͪ¦ðTÄ@{7;^¦ßTÍ£ŸØ0¥²]žÉ¦XÙ.B=€0.…ˆL’È`gI€°C'°Øœ‹|Ê8 jü¶µM_ï¨oÛ9Öf¾¤Ôë¶jz»é¦Þ¾¥o Ûð’$Ì„…‰Hž›·wï» (˜W*"0_I°Ö8ŽAòBˆ©ýÔo‹š¨ØOëí:^Â*HHD\—:2ZhGœôdd h¼¦Orp»7‚¶ƒb^´›A4ê­:ÖÅü£íyÇ|‡QØ>áÓBmßÎÛúâüRÅŠ c|m;Øu½{•IÇƈ ,«Ç¥›šš©mæmIÆh<ÿY<}^Ú†úº¾%ºŒSqA4šÒÙÍ“Ó4ô¶üeŽÚGàœ€GQi6½mh +Ÿ%àâS±Z×ΡÅBxªÊãEïo®h&¸}q¸72‘…&ë]m¬VU ²s ´J÷]=B‚íûpü®Š®·Œÿ!Ž¥ã ϘmwÇóHN¥=XJL»eûìe–æ-¨¨é™Z~ÁA>:M|hBÕ)õTô`R&ÓUÛÁV$,M,L`)ðÁõݹ¤;/R[ꪫÆ:‚zZÔý²Ý>.iy­š­wI0 Q;ƒ…@m-½YÍËn‘:0ZèB¿”EFÉ<ô¸ +4WlzÉ÷)o&Ê­Œœ>VOd-Á(l“ìodæý}DÀ-DÇSTÓ™}¬&ù\õË ë¢ùˆâåô|4ÆW®˜DÑuÛXȈ‰zÏ8³GN°£³¸V2ÓЕ È|ÚŸªvÛy/ð rK ×Õ±go½m¼/ž×ÛÒ;õEËΚ°‹²˜UuÕÕÜM[×í³S6žm2rH(pèÑ™túÌýu…öz€úððÃwíÖ–ñßþy Âdš‹£™nÏ\푆‰HŒ 8äGW]µM5ïÆ4TZ<÷Í£gí“;©÷ÆbgN †@ÌaÎö#™êxÑr³â !\ÊÖ%îC r÷÷ÎÄ¡·Ô]<µ•ç +2…Ç-ªæ ?Æ'ÙuËŒxÚ†Ò^¸îEâš{{FYuÿÂdUŽ›Ãâ­w+Û/B»F€v,†­„dˆÔêçbÇ00Ö£PbÍÎðnïB®Oî Ì—ÔÀSQo?wÚUÕ÷à  è³ò)Å™Æò—õPë»Ã“ +. )ã(7)ì%O£,ÉéÒðR"oÞò8-Ž`¥¯*ñUå‘Á]K¤Ÿ5˜LGy¬èâ|h˜«ƒÙ€¯Ê ÊH摉€%yZ2ÁšbKI Ð* +',%•Q®ùî:$¯È  þ'–Î"§êsÖ‘ 0¤!ë$y¡m§ ™K°àŸøШ$R‰Ÿ3 GAeù¡iøó¡N ! ÿ•„°¯¡ý?BÈ`CÚ˜ ¸Š(΋y/ŠzàN"pž(gÑy¦åëE=•›}Çå[J*ç´•Ô”4`Dzxâ!LâÝÐaª…CCª…çe5_*\»Êe8àn(Ò]qP¤—³ª§®f»š¹âÀ wirÀší‚Ij(ÍáÖW^/äeɉXw” ¹[OÿÀÕº))äéö§4¨ÂpXÉÃJ@q”R)IûráÆö/H¾’ý&|»:ÈüöYsÓUŸ†­ù´®èÈÞs{´oϸ-æËãÛ3ñtª:zÁ}G$_KH­}‘LB•*¥'J¦ ´,û²f~×3ÿ£\ÒïéR‰$‚kkrÊùã¨I&JäQ’ +€ïßG?\½‹þvûÀ)¥4Ýè0o‚C–‚_Ã8€Z¿tpàM Öþ£.Ð|åð¸„XgêTБ°2Ä3œ@Ññê»Pbº—öJ-ãÓ2 –ûJ2ùOÂÂ×·Z‘H0,(eF˜/ ¨æIj^ pf£X˜”QÕ½î~ø4»w”ô´px2 ù¬˜þÈSÜÒ<•Œ~qÊ}±Ó-«r±°¾¬:Ø׺W”!X,@,Iå⥑^Sü[ÊÛª›oG^N0T:ßjçí¦<õŠ’E™âSþÆáä´´Ý|SÍ\„ò—ДÙ{]ì§Gž3<5ÐXÕP¢  ããÃÜÊrÕH)G©wÎ5µÎñ!X¾álŠê#A}®2%œ”«´õÕ|ëÞ\»²®v£øÕN‰Ã-¸©³v‹êR±§âË1áH ÿ®Ї8‰9Ýp$™ ÿ„å¥ ªŽÍˆ4Ln zÚÅh¥ ¶, õi»Vøò`2Α ¿«\Ù S/;êv½L`‰»œð„ô±æ„MäÛ…ÿòÄÝÚÙô¬‹jCDB¹Ú*Gæ}°%‘ £bÊ”( UF¶Jê¯íSᎊvµµí +¥¦.BçÁK´9ÅÀ‘Ö) ðjÓU´òM­T .m‚ïÒÖk&³ëz»ê˜ ÙÒŠžp1zUÐTr1Á{~•÷Î*ÜÔ>mï§25”&ØÀ‘ñSçPTjxÈ©WQªGeКJ[ƒâ;§bóƯåÔø+D±å ª«["Ô­AEv^¹ +7¯à”©¸þ’=Fò\Òg½©ZWJ¥Î¦ô£c¥{o0:ãÜÙEOâúZ: ÷ÙÑxïÃ×\R>Ý€´ÛUí«ØÁú9x&ì}¸[»ç/}ïfö’sFÇùàÃ×mSòCÆðTžë) ñz`°Ük!4‹GŠ„9žÜšqApÇ*æy^Ë_O²±Ÿ˜FMŒ<:LJCÓ¼-âéOƒ áÒSGèe;f“äŽÁ©Ñ=SJF¼£®bÖµõ¶·ÔZÙ¢¡’<à|2£nàÔ£‚’æدI|à­Ñ /­~Q·qÄâŸdèâû@*p8HÅ{·¾S+àññ:ñ•Dø«œ‘ŸãÄ“ÏæØ_úãŸý ° ”ç'JCNÈL¡"òE7þ•aýßû -õendstream +endobj +1511 0 obj << +/Type /Page +/Contents 1512 0 R +/Resources 1510 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1499 0 R +>> endobj +1513 0 obj << +/D [1511 0 R /XYZ 56.6929 794.5015 null] +>> endobj +490 0 obj << +/D [1511 0 R /XYZ 56.6929 729.6823 null] +>> endobj +1514 0 obj << +/D [1511 0 R /XYZ 56.6929 704.98 null] +>> endobj +1515 0 obj << +/D [1511 0 R /XYZ 56.6929 519.4358 null] +>> endobj +1516 0 obj << +/D [1511 0 R /XYZ 56.6929 507.4807 null] +>> endobj +1517 0 obj << +/D [1511 0 R /XYZ 56.6929 339.3113 null] +>> endobj +1518 0 obj << +/D [1511 0 R /XYZ 56.6929 327.3562 null] +>> endobj +494 0 obj << +/D [1511 0 R /XYZ 56.6929 227.5589 null] +>> endobj +1519 0 obj << +/D [1511 0 R /XYZ 56.6929 200.4217 null] +>> endobj +1510 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1522 0 obj << +/Length 2732 +/Filter /FlateDecode +>> +stream +xÚÍZKsÛ8¾ûWè0ºj„Å“çæÉ8YOMœ¬¢­Jm&Z¢-ÖJ¤V¤âdýv£%Kv²Ijb6¯F?¾¤FþÕÈ;!MnGYn…“Êf«39ºƒ¶gŠyÆ‘i<äúuzö·ç&å"Ou:šÞÆòBz¯FÓù»äÙß/^O/'çcíd’Šó±KeòëÕõoDÉ©xöêúùÕ‹N.Î3›L¯^]yrùürryýìò|¬Œu0<Ä¿^]_Óó«?.ÏßO?»œöKnKIƒëýÏÙ»÷r4‡Ýý~&…ɽÝÇ*ÏõhufÎ)˳7gÿè´†®ÇÄäŒÎë순´9&'—‹Ô@Ê©.V%l-Õ:™.Êó±q6™7«¢ª©ŽíT»«>”L¬Z*»ØcUÌUÍ]Cåý¢š-0VKn­–\»‰Ó–K˜bs®|RÎyMWŠ<l6!¤ÍP¸…Õ¶e®½íj`’yÊL‹âOSÔÈ<[êâR›R"wN¾¢m›YUtåœN¹˜ÏiEmKúš5¡d¦?¥“Tz(/àÈŠ´ÎXã®/^²U2T·DÑÓ’é3L +åMÓ-°–Åqâ ú`‹8[ÝW¨|ùö3OÎû4×p)YRñˆå&´cÈ„i£Â)‘u“òè\åÁ²º«›êX'WuÛ•®ÈHÉ+ò9k vy8Èž •»Q ´åY¨¾.gWä[Á^ç*‰‚ò#Š´uSÕÝ`ª½­’BÞ|"å D :Pl ÀR~,VëeùË¡{Ê3!5Œ›fZdÆëÏòO:.SÙ¾úÿzÅu ¶xrÔOÂX\=ö‡Ç=ÓTŠÌ›Þ÷Y5pàŒ…•ÊŒÒÔ +“‚[@±œÄ¬Y¡¿1Ö&WŒ– ¹àû“·ü¡äù8“ì¿Ä^·;Âr½ –óuDQªÌèï"3ëD\h‹1*¥N «¬ Bc åA±C…¥c‚tôgŠ‡fÎpù˜Tø Ìë ùX)¬ËÍ ùè¡|ÄM1û÷v-šÍÝ#ÒÌûKBl®2÷”ÉiÀ'Ò’ç~h@c³gwGJ%ð_–Ñ`öXFJ£DžtK*œçó^FfÁð!éÓBLÿ­„´ƒ¢Eìƒ^Z7‘™ícâØØH0$Ès­wæql xPÀæ)<¼$¨0”†b­"pzP]W®ÖÉá“"ùáY;9Aj#j=0„#”È;,C¡ÃQs‚˃ê'FEóÚkî‚Ø5ÀÜFÍ;dRnÂ"Ó¾‡bc“)áS¥öqJÀ›ˆfË*@NB÷¼4mAîlV–(:9¬“'ä–‚: —ÈmçC‰M ål”3–c”‡>–àΪ×yè PT‰Ô§6ê„‚ Ã`hHÀ’oÊ®«ê;m:ý£=²€8èŸ j†îSBoiÒU«rÜ5cÜ6QHFYxi2™P€årN”,Z‡O£Ç7UÇM!ïHâ)£Ì5ç,%£ËÀElëªk‡3§igM=oÑD¤ßO™&ëMµ*6ÕòЖó“@55¼‚¶Y¹¶Dº_PŠbp“Ì6ƒ”±¤êdÒb°žÅ$*Uæe;ÛT7%´hlÂ@­ˆƒÄqyª›r0Ñ<Òn›]6d’ B(ÛE³]ö<Ç2ŽyÕÎ +¶ +Ì0Œ’ñPerÛ,—Í}¯Ý‚æàÖîÓºl÷í¶‡ºØ¯>f[Ê€àÔ–lAØ”-Ö܃Šÿ6u“O©ÁØC€R ~.³#ëRa³ÏÂú&7"“™ù2}¼×ë[ðcZ~ ˜‰=bP¿§±•^¤NðæJ+fÆ, Lðwdƒo^AØ´àJâÁÙdY´ÁˆÌÐØ ËÚF“4ÔUóͺ8B]ÞÛ2é«AÐaALÓEì†ÖQ–»l© 5õ-u¤l{6ÅZî\ÒD§ê8eãŒîÍõÕºƒ›]ŒãEÒÐÏ_¿ýíÕË‹«ëx1ᢱ®›º-ÛczK«]‘®}j¶â˜í÷–°*>V«-s£¯‹²‰Ña'.9×î:ÄP¹iw×+f‹~ˆ˜Atš‚Æ âë” ÕÙHïÁ˜òK†Œ=Nê­ñVdÞžP[ ˜ÎsVÿSpV{Ã7t‹‰y?ø%¾W ©bcÑQI—nÀÓ5k¢ û „8y¬‘¡f”÷ÐSî ¦@êƒT¼|jyÖÓZŽ{ ÇÂÃöæÁ)ÆŸã0×`éÿ3RºNendstream +endobj +1521 0 obj << +/Type /Page +/Contents 1522 0 R +/Resources 1520 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1499 0 R +>> endobj +1523 0 obj << +/D [1521 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1524 0 obj << +/D [1521 0 R /XYZ 85.0394 685.0919 null] +>> endobj +1525 0 obj << +/D [1521 0 R /XYZ 85.0394 673.1367 null] +>> endobj +498 0 obj << +/D [1521 0 R /XYZ 85.0394 537.6026 null] +>> endobj +1526 0 obj << +/D [1521 0 R /XYZ 85.0394 510.2982 null] +>> endobj +1527 0 obj << +/D [1521 0 R /XYZ 85.0394 468.8256 null] +>> endobj +1528 0 obj << +/D [1521 0 R /XYZ 85.0394 456.8705 null] +>> endobj +502 0 obj << +/D [1521 0 R /XYZ 85.0394 288.1559 null] +>> endobj +1529 0 obj << +/D [1521 0 R /XYZ 85.0394 258.1665 null] +>> endobj +1530 0 obj << +/D [1521 0 R /XYZ 85.0394 168.8733 null] +>> endobj +1531 0 obj << +/D [1521 0 R /XYZ 85.0394 156.9181 null] +>> endobj +1520 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1534 0 obj << +/Length 2208 +/Filter /FlateDecode +>> +stream +xÚ½ÛnÛ8ö=_¡‡}šÃ»¨ÁbLêt=Èe6õLÓéƒb3µ[J-9içë÷‡”¥DIºÛ΢@uBžû…f …,QšèœçI–K¢(SÉr{D“°÷戜iDšö±~Zýp*²$'¹æ:YÜôhBaÉbõ>ÕD P éɔ+šžÎÏbB*žžüóø—Åì +7t@ýi~ñWrüœ\^œÎßüzu<Édº˜_^àòÕìtv5»8™M>,~>š-:–ûb1*¿ŸŽÞ É +¤ûùˆ‘•ÜÔ°<çÉöH*A”"®lŽÞý«#ØÛõGÇÔÔáoDPžêZÆIž+9~-M¦F£Í3´ðZŒ'†¤VÔØãFtVä"aŒäJqgF͉ȘN2¥À´Íxá4ì1s¢´d‘Q¢Î=ÆådªYº€ÿyúÈ@“f%ŒP™çqz°õ ¿ðÃ|Ë“×5”ôdŠt§=Â^$Í{Ž þHp» DÓÜx~k‹2iÑCåÀ‡bQ¦¿]^Íß̃ì’R£¨x›²²Íd*rš–~[ ï;4ý\lo7¥Ø…­·UïðÛ]=a*½+Weõ—–uÕâñ6­Ÿ#\‚FÀh”'S4(¯®6_ŸÑôÎ3„ NÓ°¾ªñ[ÕmìÒ6M¼Oe<^ÜÞZ·&CAYäÅm.Û}±Axß­ZJê•}¸ À±}cW^Yçžõµu¸<3^v÷-«U¹,Ú¸º.Ú…¥žN‰¿;»)ÚònÂUú€fwvS6-0âá:ÿ±¬ÈC–:'Ü€'õcéÛÂÓ%•kˆÏCŠù¶äÑxI0‡ˆgýˆxZfÑÌt‰[(¥é%(h‡)÷÷º²!‹—›½.wv šE Y"F +õéPgâvSnLz^€ªwR&OOëÝÖ[V*Û²Ø8_q®ì”òÊÛÉïâÑ«Ó\€„¯*ª€³FRyÚì¯ûio«6R»¶¶BÈ~nmµ²+ç³à#ïÖŽ«ŸDo¹;ÚèD¸l»¹ pƒßå¦h¾loÝUÀ!ØM0´¬ýwÕ¡¬ç®ßî›@ì:¬ÔŽï¦ØÚ/¤Ò)˜ðBŽK#chíÀÕr³_…d +Žu0=àê™fcÙtà#.›rh+ïÕ)ð_ÃD$4¿89ûõõl„’‚ Êøê«Zä’a²Hs±8CEL¹†Â–S !IfT/ ±ˆºŒB áå8xû¥j‹Ï?Žð%QL«1¥©Ò2"çoUo‹²šVδ/׆p)£!ÞP@,‹—.ëíÖù䈥 Ì‚¼#ìOY® ® B’/äà2Ú¡±­÷+Ý•ÑÌÓ*¸.‹™ û£†ç¾N¹H˜5~‹ê ûêTªÒeÄá㸪$ Øpo'ÿ Ù…hf©#²kZôœ(Ê ú"éÂ]Ä$Æ0|}FuaÙ‘ƒ‹°]Bù*—e;U JNfò1aƒ˜ÑÀDô¿#‚ì#d$“Æ'ZÏ}” ±…¦>’úÇSRd,0‰TyôŒs¹ß¡ª1I!˜MvˆÐ§=¨/(jRö}À©»îÔŽŠNåÍ&p!7HóÍ­]ö|ä~ÛõX²ƒŽ€e¹~™ÙAØ^üûmWÊX.ÚaÙð­™Ïf×M½Ù·–ŒXÐDæP§Ðë +2õ¹™jH]{#ANÆÊÛ»wïÀû]’;¹8>wƒšøüx~1};»ú fµÑäÖ¿/ò •¶¼+6l`…ÇŠIAšh£»Êè20éwºàТ„8wv°¼Ft *¤Aš°øW×E¸ïvWº!ôáÑ‘|£ɺà®=†|#eô«ºZÚY7…jb`–zTß‘p”òã…­úÃJ±"O=ÃqµKðßãA,„s˜“¿~âŽ'žoÙû…1NšæßóAŒ©œH-Í÷ëS~úIŒ¹× +¤Ÿ e–‡ ZÚK9 na4#dÇEƒ·Ú{5Á…f]ï7+Ätý¹[ÛÙ¦­w6¬7~ÒtE5ò&''Z‚ÊìÛÂÆÀY{¾?†9(¡ü0J©Òk÷,µw¼Kík‚[téÂ}›[×âܯ->†¸ETÀ18tLžXÔÀŦ©Ãý!î"sÃÉ!¨Éõ@B…Wq‘)÷*.2÷\¼†”ŠøÝØÛ†³ _£ÜâÙð'l\ªší¶·+¤]ô?+ÿªvWÓÑ‘Ò©Ç=šÝìê-Bø“ásÌ+‹€ähÙ¢Ýïüá«Ã{›û:9ž~pëÇê·…ÿ_ùàÆ8Lš±þƒÛãJr +ÄdÿyA> endobj +1535 0 obj << +/D [1533 0 R /XYZ 56.6929 794.5015 null] +>> endobj +506 0 obj << +/D [1533 0 R /XYZ 56.6929 663.594 null] +>> endobj +1536 0 obj << +/D [1533 0 R /XYZ 56.6929 640.0743 null] +>> endobj +510 0 obj << +/D [1533 0 R /XYZ 56.6929 573.5829 null] +>> endobj +1537 0 obj << +/D [1533 0 R /XYZ 56.6929 548.3076 null] +>> endobj +514 0 obj << +/D [1533 0 R /XYZ 56.6929 357.2459 null] +>> endobj +1538 0 obj << +/D [1533 0 R /XYZ 56.6929 330.4365 null] +>> endobj +518 0 obj << +/D [1533 0 R /XYZ 56.6929 105.6253 null] +>> endobj +1539 0 obj << +/D [1533 0 R /XYZ 56.6929 82.6167 null] +>> endobj +1532 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F21 702 0 R /F53 1017 0 R /F11 1367 0 R /F41 925 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1542 0 obj << +/Length 3049 +/Filter /FlateDecode +>> +stream +xÚÝÉrÛ8öî¯Ð!¹ÊBc!¸ôÍí(O¥Œ­éêšt”HÛ¬¡HµHÅI¾~ÞøHìžt×T}„åo_@1áð/&±f\%Á$J¦¹Ð“ÕúŒO`îí™°kfnÑl¸ê§ÅÙoT4IXÊp²¸ÀŠc1Yd§W»ü°˜ßžÏ¤æÓÏtȧ?]ß¼¦‘„š«÷7o®ßþóöò< +¦‹ë÷74|;3¿ß\ÍÏgBZeAüëýÍœ½¹~7?ÿ´øûÙ|Ñ]yˆ–à +ïûûÙÇO|’v?ãL%±ž<ÁÎD’ÈÉú,Њé@)7RžÝý£8˜5[}dÒ*f:–‘‡NRùè¤*˜B:Ýå- “ðiû˜S'ËïÓ]iGçZO‹uî~%rZSÿ]ñÙŽþÆ5_,ÞA#hà¾ÞR§Ù-›ü÷]^YhÛsOóUmÚ¬¡Á§¢}¤Þ®Êòß8—UžÙóï { øô<:-‹Á öÄ4% 4\ß÷Èk€>3!X¢µ4ÈnÓê!'îñ™AÄ* "iàbUçÁF œPÁD,Q26`^ÁévÕ¾2dq [pQÑØ!J𳨬ˆ½¹¢ŽT<îÏìn{?™9x3¥™<4`QCK·âüsÚ´ùÖÊeQZç_Ú¼jŠºúñ|¦„c1L¼z;¿™ƒÐIVš_Û|Õ"OôeÀ’@$2_«6ýò£‡NpQ-ÂÀR`|ŠY­‡`CÅ8WÚ®ð¦|l<·Ð’Å\ÚÕ=ðS"ràÚ¶ôÀp\¤5Ÿè8¬„ ©C»nU¦ïF2aqÜ;„¢áƱˆöëÆâ·õâ»e¼ÁU½^£by %Æ÷ñi¦xÂT”8±ŽŽñk7”,Ò¡Ê·ÔÓ]cDz-ZNW¤‘i›ÓxJM“o‹Ün2z +-­lêé¬rph&úcÚÚÍUù•zYqKîèÃï{³£^˜<]=Ú ùvÉÒnM+j Л´…£ÀøTæ°’gIæ?Ž+W`9ˆæ÷‰™´¨¹¹£ön~ûËüö›ÿzùó‡wó—2¢î+j®n.¶“¯÷Ø!FÎu ?§%¹Oø L~ÚÇ–íºcP³'ŒØ`%¢C‘R0¥Àó:baƒàP9¢€8D¶tñh´#ŒÉªb­*¶ue:yhŸjê@@ºnÐ`ôÚtÛΚ¶ÞØ][jûñ –Ú04ˆjzí@=ÚC0˜Û6­ONð ?R`hÑÎ_ Ý¯›àAùf¼¬¡T6¯ƒÜ·ùº^ÖeCS˜¶GvéÖ>éHUBYØ~š‹BºH»)²œÀ÷i]èH¸)Ó… †q&>‘r~‹±tÛ˜IõÑù¾t—£Õ’.•Åñ‡¼¥NJÍ+»¹¢¶ƒVïÚÍΨìýZïh´Ê)ÈR6ÈRÀìUºÉûÍþ„rAxƒjÈ]6°C@™˜;B³LWÿn –z¤­š ¶‚¤£ +ÓÞÊ—"°$.’G„€"9{``…F¢K™*2XpBÄF§a%ˆ@»|tÿ™p~ +Öˆ,ëô+Q£Þ`°˜–¥ýmÚ{åúÉðGöBƒ6% ‚½¨v]gZw~‰ O&*­}¤ì‡Ic”1ù0Ö÷Ùné– 3 $u¤ŒÉËÌSdí#uÑ{Œõ2mPl#Lôá’çbÚß3‰zUQIBÛÒ5²Q\€9Î¥öŠ•P8a¹÷’y 'pv¨ |xv(Mߘ¨ˆ’I×›2¿ð\)ÔL(­ŸÃ*x)V3É/ÔEæ3 Sê#@RiY.ã‹Fјå-ˆ &²’Ë©äتaÞÎ¥µ`xµÛ’h›fŒ’BN7[õfo‡õµT¾„‰Ô.Hi:ËWÅ:-iÌ8¯~î[N—˜yÃ¥4Ë\vÛ)/þ0™æN‰¥S¬£7ÕÏiQ¦KW#B}“R·÷u°½¿£¦Òª×LrÊ®¾ù*ŒÇ‘è•V\Ø+¬Ú´´ü‰À´óXŽùsäÈQí©ö•ç˜V‰ˆ&-¢Øíá#ˆr‡Î9(NX :…ùâµGAÐi3(ŠGá!"ìaüê ; ¼ä]¨g +Öx§ÝfCb°}F$LŽ§Œ·2 ºâ8þè=¡XøŒÏL€ú„(ªÏå‡âܯ­H«N6ŽZœ``q´´‰NpÄ ++E0ýl$§“QyàUuKtÙÔå®5êÛ'TÁHÉ}œFÉ®¨îj=œ"8]F{§§ÀÏ +5—øE½²Ábm«+®:Ž±¼7Ü6VYIµ×MÚË¢,Zqö'ót[F$`KiX'ópE,N’ηùœ›P ±Âš¶ÀÄá»4â¡*¾Q˜£Ñö¨²Ây_pC<Ù¯b®ã}ÑÙÒ»‰V¬õy5.çu"3vkëYIg0bÎ@TçV¹pF?÷RE"\Û¤`ÐiºS3w*¤}göd¤¹Ì‡ómÑ:g³±R€»rr4îK«•{Ù8§»2?úˆ6¾c*ã:qᦈ÷Y‰ŽÔé§ LSrX‚¢ æ&ï*äC)Ï ûX€‚N$Ïû׿¼äèÏ*•üânŒψ»Àçäà$“NÉ»vñ˜Vv¿£Hi07”r÷H¹ˆ\¹–ÛŠ¬\§­yØÑÊ“ÓoXüó˜ìîÀ`ª6sUöÞœ[ñÿ&¶Cyø³ÄV*–œüðá¤Ûq\lÁ5ˆ(ŒŸ[K‰X÷o­Ï‰íeK2¶±YƒI3”p©;ÌÐK#Ùw3ãbaá74Ógß0þaq{AÃæUà‚F_wýxzyá-äÁŸõÕeìÍÝ Î Hò}dÔfíuþ€Ï¶;ŽsNk&¥xο +ã;¹ýDbK¹ãc¯ä ³1Ðtï# ½dõ:u +AQœÉÄ®÷4ž^¯ò¦qjÔkHÔ¶æa™^ÚÜ—'¸0@ïûHÖs¡ÿÌçñ„!Ž€Þ³ `B‘ipß|w¤8~±˜üòÑ8<ýÙQÓçT[Ïýö$;9þùˆ<ü|ÄEÏ™}ï¦oXFì¶ÂÑ-“»ïböTŽB)tÛŽóû.j ÚÉHçí®oôîd+.ÕÇô>¥y2Ó$"HÜ â:I¢AŸØIoÞì]¤{®Ç߶ÚI¿ðc¤1Wï.ïîFÅŠC)v\‹ŽŸ—y¾+ã“gMÂK¿bë¿ä L­Hú%¥({)¤R¬ôÏ}îvxõÿA‹¬Àendstream +endobj +1541 0 obj << +/Type /Page +/Contents 1542 0 R +/Resources 1540 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1547 0 R +>> endobj +1543 0 obj << +/D [1541 0 R /XYZ 85.0394 794.5015 null] +>> endobj +522 0 obj << +/D [1541 0 R /XYZ 85.0394 713.4234 null] +>> endobj +1544 0 obj << +/D [1541 0 R /XYZ 85.0394 686.2623 null] +>> endobj +1545 0 obj << +/D [1541 0 R /XYZ 85.0394 478.4096 null] +>> endobj +1546 0 obj << +/D [1541 0 R /XYZ 85.0394 466.4545 null] +>> endobj +1540 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F53 1017 0 R /F41 925 0 R /F14 729 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1550 0 obj << +/Length 3201 +/Filter /FlateDecode +>> +stream +xÚÝZKsÛ8¾ûWè¶rÕˆ‹ ‚Ç<œYOÕ&3Ž÷²³s %ØbE"5"eGóë· € DÉÉćTÊ%³ñn4¾n4Ðà|’©D¢˜äEšdŒg“ùú‚M ìç îêÌ|¥Y\ëõíÅ?ßÉ|R$…jr{õ¥¦5ŸÜ.~Ÿª$M.¡6}}ýþmq9›~¼½ÌÓé+üw{ýñöúÍÇËYQh1}ó¯W¿Þ^ÝP-5¤×ü͇÷ï®þÏëàÃ{ʾ¹zwusõþÍÕå·¿\\݆ Ä“äL"÷^üþ›,`®¿\°D:›¯Ý˜y…ö­Q–Rɲ„Mm|îD³.[P*Z Y¯¯âÔ"Lû6Í0ÉiÀ§¥©GFR0Ñ,¬ÚH×VŠç½hXݼÈ.á—x2“¶1-ô;°zXg$Êûή^æm²ÕÒmY·÷>¿q_Ë75ÚlVû Ó ª¾ÊnfÆ´žÓV+$a‚¥~4–öº ´Õݾ’·ŽH-º6fÑ H%BºYØ¥—(q—27̶u‰õÎSV_Y†byDÞ’ÊBB©!Ò±Óë«ãÇu±Û½Nà €\e_§›…æòX7A^­¬uÏA sÓ¶$+HAyí²Ù­D?à¼2EF ÒÎXçv†DѪØM@ÃÒWóå RN˜¯Ìr}4q‡“;‡'”­lÆܨÑ–9c^¬˜»ï«)¦7ˆ‰¯”$—ÙP’ÑeUlgBëDgààûjÕÁÌ–(x~boQ"Ñ…äÏ9`úä¡ã}îZÓö½[¢6ÝS³ýD‰»}ç²òä¬SI; K<6ÕÂõAÞÞ|Yu&ìô³…Ù˜zÚOuÈ'°µWÕC=£ùkp¦…<ØqÖ¶‘HÅ´mèÛ-K—Sù/ªd*­_„éõ΂(ôÉo”/ß4m[ÝÈÒô ïTÖÇHíŽë·ÛÔm·©Ûná Âs%UÝV ãy4ÄR ðpìƒÝr›ë¶{°íkÐ,¥9ÖJD­ +ò_!˜)Q^IYÎ¥… oÐ0×ú°Øp0`[’Œóg£Xz„èÔú×0Ⱥüd¼ôòÆÌ»rþi·qó¹ïù±AÏáÀc—K«Ö©‚ÈγtÌ EýA0(µÓõ 6~Lý‡§[ mp8#§×µ$Øž‚»£„;¥p:SRû3ª;jÅgTlß‚“qêx¥•tZs^µâö„ªÒ`&:øµ”»jì> +(WÌiûÞm~UÓ‚‘VNY±$xÌ ãzk HÎÎÚ6„ù¾œûBò©”EúÖåYI*ô5;×ù·Ê„»ø^EĨõó”=LA‰ŽO9Ê”®êùj·ðuí4RkÞìjØ?;âUÞ\õd¹ãx4ëÀ×I*hÊ ¹!áZLnmÊÔû~·ò' £Ã‘;ÕÃïΖT;^* ÐÒá¸j¸Ñ¸®XpÔå¹ÞKgl¨0¸OͶúË÷08T—ûfµjž‚ûþ8öCN×àv$W‘«I*³D@|ÑõOr¦†·#«‘ç5 +vê³×3ÔŽAWŽô-†]ÍüŒf)¬zŠNQ¸y‰•XAkÃÄÁz1!¹»)ƒ„vcþÜ™–nXb™I–'™ƒðmL‡.ŸáZrthx6d› ”Óz·¾³HÍɈc^ÕÏ Roߤb‚§› -Bã1¢/¦$¯ŽM?üúæÃÛ«c1 s*ø ŠÁ"É&³þŽíA¥Ô°[æ"{•L$9OÅ*Û™meNƒ2à¥@yžé”1×”2—”H[Ͼ=(1õ§›’MØ= ¼ í7ÛoÌi0¾œ¾0‚‰Ö*ûšù'Á˜±¤`ú0Ê\')Ëè2ùî{h¾ŒÑßÆsƳL0¸¶`L`DÁh¿aJàŒXdÁˆÄ1Ec&”#Q­=e"®ól¥¡ìþʳÇÚ¬Üåe2ù;Òoø ž0 ÉX¾˜¾3X¦/ KØO(ï3°„Ó„–˜òÿo¸Ÿµ6ÃÔe=7_ŽÍhÀÃæÙIôØŒg1À¦`Sy>¸ËB¦ÊÃÝŠ¢¸™á3’G³ÁøžŠÜiçݲ=uÙÝžAô‹Éîv8„RplQÏ Z2É„¤óñß¿Äñ/åsœç;€xÀx âT¥ˆS•y‹µÝJ038;{êñ³x+`ãR9§›ÃÜÝaR†w.0uì\Ì|Ð4ŒjÇßô1^Nâß ôS°F‚}Íöä[œ„>8–«g õEV‚Þ€Óé ÐÛ×îNâ¦5gn$âA¾ïûgï±sNþ6€/øÛ<'òÜ,½¡Bmi¬DŽ4æ`ÄvÓ´£@­ºê«eON3 ÷=”˜K1T,±÷w¶ìøgPEë™c j\;¦^mׄ{;©)Ôˆ_Ò/ æ´$Hb`ä®lá :˹ˆ}ô1¿è+´éÅÖðûÐ&%rž?i¢Šbðbêèå”Àc›–ø¦%ÐiqwþáOAlL’”_a¬UÀN~×ÚÛnæîÜáçüuÈ þ:Òñ+sa%øΛÕÊ’˜¿Çž—ÍSMäÆ÷áƒÔÂ]¿áC¡Ì…élÓhØeéÆ ¥å®[6[|*5ž0î’§>T‰lÌÚsq °ÒJù·t™Œñ„.D\(ö¤cíÎ’þ¹ÁÞŒõêèPŒ€2€þ·Æ pp­ÝoƒXZöÏ‹x.¾#¨º%e‚ˆªƒÇ~A€°êd ­N»è,…¼8xuíúnt›—6œ:¸9?èÑy„ñ+(8 u!N}ïŸ5„æ¾Ü­ºuw§ÍT¸•ðýJɇ/ËŒðÔPFwˆŠ@Ò{°ª öÈ(ØÓúÈñ …ŽA*¦jWRµ¾7´o²Y•”ÇÝ3Ia'ÿ&í¹øöÄJJiˆrQE¢ŠD^Ü`-ØÇVã}Pÿœ‡'ýDfý»¨Cƒ,‹>°_c͇Ý6„Ý´{„ƒV™»TǪ‹þ` ¶¥¯{ÞÖtÆž1¦jåŒjÅ7™Jã±Â7"šžvi1T Èž/˺6+*t/i4?%‚4ÃÇŠc¸nÆ”UgIž µ1.h¯iÑ-[ƒµÐ„, •CF¤§£çuP÷îÖ˜SoqU–H¬ƒe§¢íĈ›±—ÇQõÓ¯d]o +wù—Äìä!+œ[ñ¥1/G›Q¨tž…£¾¬%´ŽÈ €]ÅÄ#c²ð:ø›*÷Ds¨µç>츎)d^«#Îý‹æcÖÿQ(Tendstream +endobj +1549 0 obj << +/Type /Page +/Contents 1550 0 R +/Resources 1548 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1547 0 R +/Annots [ 1555 0 R ] +>> endobj +1555 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[1 0 0] +/Rect [55.6967 62.1828 116.8967 73.5749] +/Subtype /Link +/A << /S /GoTo /D (statschannels) >> +>> endobj +1551 0 obj << +/D [1549 0 R /XYZ 56.6929 794.5015 null] +>> endobj +526 0 obj << +/D [1549 0 R /XYZ 56.6929 769.5949 null] +>> endobj +1370 0 obj << +/D [1549 0 R /XYZ 56.6929 752.4085 null] +>> endobj +530 0 obj << +/D [1549 0 R /XYZ 56.6929 542.1781 null] +>> endobj +1552 0 obj << +/D [1549 0 R /XYZ 56.6929 510.0725 null] +>> endobj +1553 0 obj << +/D [1549 0 R /XYZ 56.6929 447.7453 null] +>> endobj +1554 0 obj << +/D [1549 0 R /XYZ 56.6929 435.7902 null] +>> endobj +1548 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1558 0 obj << +/Length 2647 +/Filter /FlateDecode +>> +stream +xÚÍZÍwÛ8¿ç¯ðQ~­¹üDqöÔ¦I'=¤­ãîÎÛéd[‰5+KKvšýë (YvìÊù˜÷ü|‚ ð¢EÃOô¢€qeüž6> ¸z“ùïÝAßÇ3áx5Ó Íõ~töK¥{†™P†½ÑmKVÄx‰Þhú»wþë»/£‹a î…¬?Bºþ@CóÏ×—W¿ ßõµï®>_yxqy1¼¸>¿èŒ‰$Œ÷[ÜØ›r#oFWç7ý?FŸÎ.Fm#W¨ý_g¿ÿÁ{S°õÓgÊDAï^8ÆÈÞüÌ |¥jJvvsöµØêµC÷¨ˆ‘Ô{P“bja¡’Ê¢††ÂÌýàœ{£YâL­â*-«tRÒûeš%h,ˆT-‘¼7>3¾ð­°fx•ü¨¨u[,ç±k—;B§«ù‚Zãä.Íõ>­fÔŠé‘¥yò¶nþ7ùÅé!¶õš%#«Ç›7oö›ñ¡™±aùÎn´‚P2¾±ßL¯7f*®½|5'Kj§9>#o/û"ò’¼š%eRºN÷Œé@äSâ›Ò¨oyúcPV™“\¥ó¸æ 0\IáÍ“¸\‘`7"v"ËdRäÓú%Í'N§8_ÅËboÑ*k‡`&¤µCÍ2„Þe‘eÅ}šß(>øof}¦ŒŸZh>cb)ÇQÜÒsË»Àæ·E_xèþ´ÈѾôîgéd¶-oWÉ]±Lÿ‡–áÀØuL“r²LÇ–ŒóŽ‹uÂȸ‹¤lYD9ÀÀÉþ¦ "öëx^/’d¹F÷ï‹4àîŒ#kÅ@ +ÝÒ[„ø³Q%uYxበ+—¨±T^Ò Þ*Nsr¼Wv +½í +t•WVYè\ÇÙÊñÝZÇ[Œkü@Ô´žò*Îè…²ì‹%T",(;i ˆÆ&N³$Z¼ŽÓ,gŽÅ©Uº¡—5Û˜b}V}!„‡†kÑ°“P¥À>‹× Ñb"Ô†@ qÇ@’‰–QËYqŸ-ÍkéÉ>Cw“ØwÎeqY³>Ê2Ú.ñaOBKh¡H«h˜vkI÷³¤V{‹£I@@L t +¹' Ó,oAäªVfk ,Ð|KfDËÆFÔëQ¥6™ÉÈSÙÏ—ò]JÝ•˜7<‡2³è5ÙTÀ„àº)gu1Û㼞ãê˜RW TgF¤T»ˆ´^¹šÏcL\ÔµåeÕV;Ð+ÒiO‚4C„…õm±ÏáB‚€²ÐRG.bº'25«ZSÒëí¾¤H<]r[Í‹Õ¨^¶šçÔccGðšU@²mV ¤gÀ`Jôòa>.2bÎm"Ä–ÕFˆÚF Ôé¶J`‘obZ:vRº™šÀÆZ†V¥¼–yÄ24¶Ú¸RƒËòüd’”¥MlÐ fP#vÝ¿ŽF_ˆ²% z&³8Ï“ 3’Šê-ñ–éÝÌ¡g¹ldXñõ.]'NJÁ@ëJ—”ÒlzÒÒ Ûä8„Îf=ÝMè´E¸ã¬,ˆRg.ìÌwDm™ˆ W×xUÙ)ÂÖÐÔñN‹Éj™Äé°(Ê2gÔéÊ) (3Äe_ØÍ‹iŠNœST (g`cœT¶a› žÆã4ƒ|+À…ñÞM§)¶¹ 8!]ÛµÍyü@ B‚dÒ³µœ¦DIÝôd¶(øqɽÏÇïóÕYh9^8G]û®™P>í¾-¦q•P¤†Rº@éF÷ÃCÏÓ‰ÛèZ/„·¥ú©Â+Œ`Qgia&´ÑnIã‡@ü i@y7ïòò˜<@ƒ€e’W‡sJô.à`aWÝ‘bRúaÁÈžÀ–«/™ˆÉQß`´E^=¢~Ot£ìÉâjF² P-˜ ߊçOþäðûéÇ‚([zž,–AÀ´ÔÕ]†)áËMpy48åæ(Ð iwÒeZËŽ‚.|ÍT`DƒË±ÇÕ>>¯v ÙÒòµ“¢§}©¯GìG*‡ DײVó¹¢ò »Ì›•½,í†òk½ŸTÆÔiq•ÙDéswgkì_„ðQ’ØÛUæÈyyßÜ ã‡Û}¸…‘ó$¦²ö袔î_Õæk­jîCét€ƒ.ýÑGÑß{”wýùb8ü<¤—vþv\ ÿÞ»Ë,‰í5y =»ĆÓÚ¡72"ŽÜâîµ#Ú?_ÍIvÜ!yĸ¤·<è…Aù…ÍæJ0 ;x|.ê{ûbUn}),·ùZÿŒ<ñ­hzYtþ}©J¾1aGî4 "%ëxÇÃéQÛ¨¯ÏOu¼Óçwwúø°ÛŽõCè¶T?ÕÏ^Z‰Ttäe°Pº›a@÷ºˆ¾ ýÞÍuüš`7Ÿž‰zˤ—¢1Á¡ TÈBùûþË{.9ö¿À›GcŒ¢Ö·È6ªŠ‡°áð€I^ÑD¤Ãáþ4ì¸ZªÿHIÝSendstream +endobj +1557 0 obj << +/Type /Page +/Contents 1558 0 R +/Resources 1556 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1547 0 R +>> endobj +1559 0 obj << +/D [1557 0 R /XYZ 85.0394 794.5015 null] +>> endobj +534 0 obj << +/D [1557 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1252 0 obj << +/D [1557 0 R /XYZ 85.0394 752.4444 null] +>> endobj +538 0 obj << +/D [1557 0 R /XYZ 85.0394 549.5629 null] +>> endobj +1560 0 obj << +/D [1557 0 R /XYZ 85.0394 524.9842 null] +>> endobj +542 0 obj << +/D [1557 0 R /XYZ 85.0394 417.5407 null] +>> endobj +1561 0 obj << +/D [1557 0 R /XYZ 85.0394 395.2295 null] +>> endobj +1562 0 obj << +/D [1557 0 R /XYZ 85.0394 395.2295 null] +>> endobj +1563 0 obj << +/D [1557 0 R /XYZ 85.0394 383.2743 null] +>> endobj +1556 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1566 0 obj << +/Length 2456 +/Filter /FlateDecode +>> +stream +xÚÍ[[sâ8~ϯàÑ©´º_Ó¹Ì25tf«kfç`gâ©Û$ýõ{dÉF€ÁÐSTWµ…Ðåè;ß¹è8†¤'$’†šž2 LDoòt‚{Áw?Ÿ?¦_ꇣ>NþuÅTÏ #©ì4ÂZ“Þ(þ#’ˆ£SXGŸ×æ´OŽnG§ŠGgö¿Ñàv48¿=í£itþï³/£Ë¡%ƒ‰®ÇO?¿¹¾üüÛÐ/psíº‡—W—ÃËëóËÓ?G¿œ\Žš„‡$˜YéŸOþø÷b8ë/'1£Eï>`DŒ¡½§.œ±ºçñäöäk³`ðm5µ 4Î5`ÈôFœÍ»º0ìê›”!cå\Þ´/ RŒÁ‚Šs„ ^¨’@ RÃ!ê)ad”Ujøš¿ “û$Ïǘ‚)DÕpاκϒõŒœÁQÚEXEQbjÊ\Ïó")÷` ¥j…1¶Ç2Æ>¯o.‡Ã›áÒ0 CQÏ|MËךfîË1j#‹c1ë̪:-—ªg+—{ÄìJNúéÆc2†¸d•KveËû\æ’í.Ù®~%vŸ5e{ñ[|7Ùjü1\«QÝ}ÉzÆ&®I&(ÞN6i ÒBòšl·à÷ÁsüçêTˆèlð+`¡±Œn¯Æé>>˸Â@è©h#lËÃ&6 ~ÝŒtxˆá² +59$Ôš#F¸ê€Z+d0iBÁÕÍð3X¢…D*@ø,èPûµ·ˆ|(`C匱RBÔÆœu«2\’Æa~»¸ù|6€„„TÈÂç}Â-a«á–øp ßÔk#÷чVh­9@; `[ˆmw‡1¬eã ãìi »® ) §šüc¡5TÂñ†VI!+fºËÝ Š0j‘ŽMæ0V_”Eë×øëždy}H'žãyáÃ*-W"Ém0r™{Î’ü>ËŸB¶Õ‚,Æqº"3QVŒ«Å8v‹A÷1¦ÓØ÷U»Ö.%Ä+)¡Ò5oaÜ:oÝÊïämžc•¸”€ù?GÜ€‡ŠÓÎ+%öY²ž±‰¸|‘’].P& +7±ãb>{L'ãÒ*›2 ¡cÞBL­yk›kl£æªmË2yš¹ÐbÇdî¹`«Ÿs7/]#N‹~o&™OÆìR²‰ñÔ=“ïiQ¦Ó¿Ü§ç¹½¹O. µ­J8Û(ÆO¾5øâŠcOÞ⧶gY^þÂ1^­þfÓY .ª>MaAÿuù6KÜ·ckJöÛÉã¸(|ߣÛf¿¹ïî’JlÛt”Íúm†;Á’lNUÛœj³9åð­žíV^_J©¼"ãFÿ-f©äÚÕË® æãÒa#¶Wçe´i|­?f(?Ôö@Z£Ýn|B¢†79òEžÍfÀåÝÍM(¿w ow¶YQÛ6j»³m0£%‹±}Öbì3ù”j5²"}±žMçOw• C»R™Ñ¥ÙÞ àÔ“žÏ`¼¨¶áü̯L¯…àµiY[ª-ÈòÜ[PÓ§qôê溋ù]‘ÀÞÓòñÍõ8ƒ®Þråd²ÍŠ¼—br£ môoT$§c½fC²²¡ê¹d-Ϊ ¹€{*]ø#6ÐóPFtø$k‚°’™‡›œ$'Ô·¸PÎó¤Ûˆn@•ô¢öáLÊ辚îÔoý« 3D3¤g†ØTØf(Éßô~£týfäJŒûÑÙLó¡ÒðÃW¸4ˆP";È ÀR°vÐ}»Ï‡ÉóE6Ý Cë,Šæºû?;É•+sÈqï]÷q’=Í“Òûv<¤ê𥅃â)"Rv” 9\Ñ”`Î'ÿ6‹!1¤à.Ó¨Ö*„=Ž ^ÇþÖ± Ë@Ê#Æ. ”ŽTÛ¾2€C™%,‹Ù;Á\TV÷@3óˆÑd Q!Iš¶ðÊ© +à$w«&^¼Az‘NvóÚGßëmE4õxˈqÀUº P¸Ôj­dèn®³Í=œåB´#f$6ˆqÑ•ˆŠ £ %5‡ê3L‘”zaJÌ,ÝB¨Bõ¶/Éýâöíé.{„› 74ºHŠIžÎJ_G ‘³©'ÆÎ^ìñ1¹-B k}À˜¶€‚HMÉ&¶ÕPÀDÀ.½ÎÊôþíf^¾ð#•àu!lðUT›Â,[ô®J‘LK´½P¬Ã¢wP"Y«…ë<ë@OSˆ/ܬ 'wAO¾ ½@¬cFOBò‰é@OÁÚ¨½ÁôCÔóõµ$}iÉ + Ò³ H8¹îÀP@ta\.cøîˆáB¸cæ!§HÚ…!‡0« 0&wC8…üÝ•v7ÂèÒª-03Ž rO¦dŽ¹8‘ «7gû˜âÏáßZt8Ä@²c¶e¢‘Ñ´+SŠ„4$pS~€dÇÌ@¬¦ª+Œ$a.Ÿ}»“ç½(h笕ä¶p ×ÃW½wT´# £‘Z-Á·÷†/”ë˜áÓ ZÒtÀ§á^ˆ!µ­@yû{ÃÈuÄÞ(WZÒ†‰X¸æKðíþýá ä:fö ƒ(–Ñ—HŠ”aÍ«ÛùÄþD'~¿¯½ÊÙôN¢°+&ñVDQQ®„w *0ÒL×€n(V¾Í µË”NƃæÝ«f?¢äŽ +1àÙº™ TíR7«^ê+¸ec¶½n¦9¢2øÙ A̗͆I‘=¾ÔšØµRÖÔ〠Ì]WeĽNnîú›šÅ¯Œ@íL‡…¶ô3_L¬¥²§ÕzMvȃ(“´Møÿml ºendstream +endobj +1565 0 obj << +/Type /Page +/Contents 1566 0 R +/Resources 1564 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1547 0 R +>> endobj +1567 0 obj << +/D [1565 0 R /XYZ 56.6929 794.5015 null] +>> endobj +546 0 obj << +/D [1565 0 R /XYZ 56.6929 352.0981 null] +>> endobj +1568 0 obj << +/D [1565 0 R /XYZ 56.6929 326.9775 null] +>> endobj +1569 0 obj << +/D [1565 0 R /XYZ 56.6929 326.9775 null] +>> endobj +1570 0 obj << +/D [1565 0 R /XYZ 56.6929 315.0223 null] +>> endobj +550 0 obj << +/D [1565 0 R /XYZ 56.6929 102.2008 null] +>> endobj +1571 0 obj << +/D [1565 0 R /XYZ 56.6929 77.0802 null] +>> endobj +1572 0 obj << +/D [1565 0 R /XYZ 56.6929 77.0802 null] +>> endobj +1564 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1575 0 obj << +/Length 2081 +/Filter /FlateDecode +>> +stream +xÚÍšÝoâHÀßóWðÒÒ×ßÙfYí$àV+íµ€lå¿¿j·mÚl¸äNh¤ 6U]å_WWUÓ& ÿHG „™áe8˜ˆÎly…;ßá»/W¤é—BýPêçéÕ¿†Lu 2’ÊÎô)K#¬5éLçvo~¹þ6Œ{}*pW¢^_HÜýytwëïÿçæþn8úòïñuOñîttçoÃÁxpw3èõÑôy0B¡;™:¥Bs2ÝLzO½L«’`æ¼ÿqõç߸3‡gýõ +#f´è¼ÂFÄÚY^qÁàŒ•wW“«‡jÀàÛ\õ4Î5°¢ªÓgi cœb–3Ä%­[ý¯”J?p§O2B4Ø÷z†*>–õ¡úüBp…¤Rd&ˆ“$$é(A• . +&oËÇdÑëKnh>wº˜»â>£œvom:ÛÄë,NVû3(C„3Ñ mìa5,aÈÏçÃR”˜Š%‡ø0ƒŽÏÃÖnÞ^8Ķ²;¾ÎPe*ÑB +çJ£oNÃaüê±MýEjW:0pîs’ÏHRRê€T!&ʳÊóÎ]lÂךÙg€æ,Æ6]'«ÔºâXªîx|NnzDw‹!ÒðÖÌÆ/vÞ€3põRqJc’·àĆ9«Ó”çÑ”¤zz©«[j… &¬™¦4q­LNæîÛû¯×#è +ã¢;†ëvœ;¥3ø¾]l4* —¤…ŸŒå0h~ö„è^~ƒ šwÇÃ(^´ƒtÚ Ú®ÏrÚg œ½X ’!cpK½–R!¡”¯×Ãûñ׬é>Ïãq8ØlÚ9VJgà \»X|‚B{-T >!¤Ô§ÇûìÙn€Y²q‘H4ú§ÌÕ<>»É&›óÒcàêŦGîþâ–Ú-Á>D¤¯ÝƒÛ» >m-;Ñ¿°Àþ#»ÞçÍ|‚1¶Eñi xx±AI5"T´”lÉRÄCü§Ë(›=CDûv»>¡fï´>V·w/)‘ˆ(L[ƒ”€öØÑ™ö,îÍv5‹2;o§9íGLwKRõ_v5ÇQ"Úª9VHcâ«ùoÑÒöú +»¼™nåê5¸¹]Øï‘ÛbŸG2ðòRI +C¦¥Œ #æRmzæR_Žr þ„=ãÃ.[ztÙn㸶›§d³l:y± 5¨bÞRÐ…fHâ ú—ÅÖ-äA·dŠñîdò–žõÆÝÄÿæóbÁTŸÜ¸%âxõ’üÓØ;ÑÛsHˆqÓRâ…‚A˜¤{€åÙ€å眿XÀB‚*o©þBÀ½âgê €Ok¤N Ü]cÕ5pøb¡rŽ83-õ_p0z?jO¦*?‘jàñ¥¶û°GG\ó–ú/˜DXa_ÿÏ»ªhqev¹ÎÚ©BÏ?Üxf/Ñ"žç @Á×Òˆ1pñbƒ“b$¨n+þ”#B„¨a¼ÿçcÓílfí¼‘`àÝg¤ rVo[j&)I¢ÛŠ¡ˆHÌjïì÷s *nj@ÌÿÂýUÞ¾X7^¹~*Ö}ghw¬åÓwÛ„÷1Zÿ»†%[zÖR´¸ÖÐ@ÖðŸ–Z›B¸-‘†®}VüîŽNÿÿ‡¢6†m +VìV±Vá \†%ÒÔIsÁ”ê#%°Áwo’å¸?Æ‹8+v¯qöìg6%ÁìQ…\tûÉËÌý‡©F° e!Tœ©Þ$ÛUf7éèè3¿„çÈpâϾ&iæÎ`i7ÍÀ»4‹g©»&ÝY9Vþmör¯Öe/½@üD ë¿ŒW‡\…,“ðˆï(tÁTRº{7\T3µH“ÂÕízlò Ž%0sô £¦0ZHŸ“×Ue¡ ï¸!.´‚é]*pDÉK±ÙΓÁÝ_*dyÙ /VIV¶ß ½ÍüÇd÷kçnòaóiÈwóI5@¡¾^ÛhSvò¥¸M÷Ú?tl ¢[B§qø/Ó…Ž/J*ße_çãŸÜ™ìxß2Ôb„Ýn¼Ñv%uÀz-ãIp’*]7?õÏϸ îvÅ…Gèî†q—vmS{(¸`+/dµúŽ—K»à‚1ç‰-\(¬ +hs“uဋ¯òËšÇó#G: Ú M°h9—€©†˜+¥ò˜»þcø>Úˆ„y³ÙJê€ÝZ´A +eœ¨ºáésœÖm±Ëõ ½bšÆy®Ü[¤þÃh5K–n–ò«‡ú{ 3GaRM‘¡T6à ¥ŽÃ¬¤r˜£‡w(1ä>,e³ÑJê€ÕJ ÈÝaoÍìç¢Û[›f§²Ч0®ZXR ,K©œåý:Kß&„’pMg“ÙJê€ÝMÀ€½n¸…fUB‚üç.òŸ„þRuNJ0eݲûfgµŠ”ÁÑ·¢®ƒ_­ßÍõ_ÓMZ¨¬ÑÌŸZêºZÿOÃÔR S[Jùsrˆ¹¿NŒä¼Ùj%uÀìþ:1\¨ºÝ#3 ‹j lËõÂ.-ÈÌ*¾)1¿‹ƒ7»èØ{•L ÷2ä'ÃÖ]Ò©ï\îÞBåÐIjM#ªšõ©¼™÷;èœ5U\ÿðçœendstream +endobj +1574 0 obj << +/Type /Page +/Contents 1575 0 R +/Resources 1573 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1547 0 R +>> endobj +1576 0 obj << +/D [1574 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1577 0 obj << +/D [1574 0 R /XYZ 85.0394 769.5949 null] +>> endobj +554 0 obj << +/D [1574 0 R /XYZ 85.0394 439.3709 null] +>> endobj +1581 0 obj << +/D [1574 0 R /XYZ 85.0394 411.7795 null] +>> endobj +1573 0 obj << +/Font << /F37 791 0 R /F39 885 0 R /F21 702 0 R /F23 726 0 R /F65 1580 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1584 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +endobj +1583 0 obj << +/Type /Page +/Contents 1584 0 R +/Resources 1582 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1547 0 R +>> endobj +1585 0 obj << +/D [1583 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1582 0 obj << +/ProcSet [ /PDF ] +>> endobj +1588 0 obj << +/Length 1324 +/Filter /FlateDecode +>> +stream +xÚ•WKoã6¾çW99@D‹¤DIÍi7ÛmS,Š¢ëžº=Ð2m ‘EUdÝbÿ{9R¶lÁÛÀ08¿΋…æGgiLBžE³$‹HÒx–ïoÂÙÖ¬ýtCLsGœ›ÉÄjó”Ä)KfÁ)ÈûåÍâ#£3!X<[n]"Iå,-×Îw²îTs°8œ'w-ÁmI҄¶ШHHœ±Ìnxÿôë”Îpø¬ò¾)ºÎuÕkÕÈ®0Ô€G#Â#ÁžˆI,¸…3¦Ü4 Ãù»&Œpu CkÙt…¦ÄB•.ˆ5ºûEU2ÚZk›z.šöÌ@¬UUÈr6°©È•{~Пá>p[»ÎT®Ó-·²¨ÚîA¸wúvܼ@‚ aÌõ~¯+ð‚=Oë·•ß®õÆf¦Õ†‘$c‹°eÊÜŸÅŸ§ÿZá(1 :LƇ‰ý-Ò¥gsv¾žÇü,ò"¦}£˜ò½Ð‘0S+–EÙ .)2Ń»Æã!¿ J' £7æEnš¾w±ÉýÜD\ÜU]B°]ŽøaãDÞ`é\ íÒ¦[¿_©æ;qñú|Xìð•ØßÑ¡ƒ:Æ·I¿ê¤'!öË#9B&º`³‹Ò©•Þô«&?aÞpÕ¨ã»ãqÈò«6yÈàÌ9ײé]9U·®±S¥·W\íÞ,‡ÚíÛËÖ\Û“m +ŽÛýâþá-ñÕa|ìkç›üÌYˆ2K›éœòá=4v{Ix ¬°7L ÉsaMc¸ ½ÁF¿ÇÙ 2܇0é«ïر2H`í¤[[)U¡*Cæ©Fç-´L`¯‹6˜,»•)tü›—Ã×¥ÿf„W¢ùúþô"ÁQ?>GÐP˜î”%4fô\Ûð){©î?‰Bá_endstream +endobj +1587 0 obj << +/Type /Page +/Contents 1588 0 R +/Resources 1586 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1592 0 R +>> endobj +1589 0 obj << +/D [1587 0 R /XYZ 85.0394 794.5015 null] +>> endobj +558 0 obj << +/D [1587 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1590 0 obj << +/D [1587 0 R /XYZ 85.0394 573.0962 null] +>> endobj +562 0 obj << +/D [1587 0 R /XYZ 85.0394 573.0962 null] +>> endobj +1591 0 obj << +/D [1587 0 R /XYZ 85.0394 542.127 null] +>> endobj +1586 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1595 0 obj << +/Length 3437 +/Filter /FlateDecode +>> +stream +xÚ¥Zm£Fþ>¿ÂßÎ#1ý4Ñé¤É¾\&íæv=º‹’|ÀÀØÜbpãüú«êªÆ`3™•¢ÕMÑTWw½=UXÌ|ø'fAè…±ŒgQ¬½ÀÁ,ÝÝø³ <ûçà9 7i1œõíêfù^E³Ø‹CÎVO^Æó³Uöó<ò¤wûëêûåû0Ì•¾HìqΛï>}ü¸¢Y#ŽÚxZÉÓî?¼âzR Ís>¿[=>¼`%¥UØ/yÿãêݧۅ |ñöèÏ¿}€,%¦Ëçwo?=¬~¢»7?|~xûîÓým¤ç«¸ÃunÞ­ú“ž¦ðÓo7?ÿêÏ28Ôïo|OÅ&˜áÆ÷DËÙîFÊ ´RŽRÞ|¾ùwÏpðÔ¾:©áà „rB=pÂê b/TðÏá}ÝÐæv0fžÓ]Q=ÕÍ.銺"‚»në# ºš®‡–_¹óC;~´·ë.O;"œê¯ÖæÍsÞà9Þ9³é¶9ko¨d%…™ØiïþñóP^ÌÙjFÕ‘gb_ðÜ${.Úº9û¤û†ÞbðÆB…p&QÍ`&"ˆûêß/õjOkÍ"-<éˆôAO¿ÌÜè_gݸÃ7¬jôpý+¾¸úS·ÿf¹„¿^rhӼ鼺ÙÀx¹?¬—LZºÝ-ïX€ûs0¢Øó}íeU{)¾V`d‘/Gò¿f Ò‹1Óæ¹è9¾²A0a8Öx¼Á¬¾–0ž_ð…Å÷³®W©õš.û61ÚSÇZølÞwxI¡‹^· áûàüÛ¦®ÙŽ“*ãøw‡"›0A¶¨†˜ é#z æþ‹£ Eëõ¼èˆZ´4o_·m±.s¢Zjsk懊hª€Z0ïdÂm¤ˆ<ÔyBº%‡œ’Y…^Gnr^=4½ÚåUGküâþ¡-ª æ|UO]ø¡gtÜS{pø&üSëO†~ÌÓŸUŠaÇN¶‹®Oøj(ö´/5ø¨ðâ  üÒîó´x:Y™”RV&Èù/RjZmd‰‘ï¹@²è&rìiŠåcY×{ sE`æ«-* J“ŠžoórO£bDZï9'B{j»|GóÛ<=4Ew¢'k¾îË$åMHÖ®åļ“ó¦Z0¿uý;ïèdŒ„à(#w0ÒÊ}Üé–ÌôX”%ÊbWtç@kY²K6n\W.<±­6=â8ŸÖn›»¢Í3›æÑò‡!ô¾ªa!|QÛ\ñt@I´˜?åIwèSŽöÉŽáÉv áÊbÞR2‚ûú‰f°ÅŠ¤Ý¦€¬‹Òž±¥Ötíh¸L–ä;Ç8a6 ߪ}S<e¾!±»œ1lˆÏí{ÂÚ$GÁÖv )ÁÈÚ0öÎü-Çk“£ûŒ†®V¨„?ÿÏm,]În›MÞ²vi«¹*ª±u¡‹Óöpg.‘ó^ŽÛÜÍj{Ó¾.£Òƒ0#_ŸòqáÉH:6нǾ |”2áØx¾Ë([ãÕº\óߓݾä‡`‹;–ñ¦,*&£æ-¥Nø»°-˜O2µ/x Öê+ö±Ó/{æÝC­<_úŽßò9i–U²›ŒÃ \i"7õ?œ÷{s;b[¾^ `^`Œ{½_òš”€%ã‹0Ѿ” ³G>¤Lâ3€{l%Ò— ¥´A)~o¤Éå¡m–e&år]T¼õEy|Â^:º^‘˜õrÛ«Ï„`S®Êœ©W.°¥ƒ”ýÓ§²ét€… +Êú`ZFs‚ÄîXËpþT7DŸ²˜@§âUƒ;P}n¼J²È—;ÖÍ¢p”ÝçMy¢gEå$¡ IÓé¡LXÒŒ¸ð¶À§`€ê7À®s7±X‰é!ƒU‚3å…Ap‘~_2b@?ÆDñ b¡!GkhÃI GUŽÆ€#kÜp£¤ÁªŽÈçáþêÀì[Û„GE•–‡,oy2äS·¥¬ +÷ìúÀWlÇK’?yh{zþžÓíÜíeä7ÈìoTãàZae㳩 HÏE~ÄØ];OÛ”¡;°^¶Ü‰ÚNA¶ ]ÀŨ8@cOm_d :ˆ)w ¼Ð„1.IÓúPqàxr2RËÙJD¢ÅE²z¬x›€ŽE·%$‘'MYþ±8¦åSÑl*@EKº£¡u‹XNû‚eyrü@Qð^ƒø±pòW“GÀœ¨O'¬h@ ŠÅå Z d`.3ÉuDSqßÛ.醒Wuãà<¢]`¹ ÛáE*Ú&¶PÂÓøºIšÂœAÈb#1>! 7h·G¢8O@\›ùwõ14LQ|ŸWÁ˜oŸé[Hð +²Smã3b¿£B‡ôÔ]r¢Ù|ŽÆ‚Ë2.­rÂÜ÷æSmÚK/—&B„K¸Ë,^þ‘7õBP^÷m±©£•é!«|…Úeˆ Ä(ý35dVÖ›ú.ÒÎÀÅÕʸXÜcžy—:èŠÝ”›…nê6ìM°)å‰(4=0p%üãÍr]cá¿çÒóÏqý±)êfèFr ¸¹¾¸v©Ø÷ †_ãR±s<*Pl„PÜnƒõ¦ùGPLHyh('’3(*ô]=t}©$,Lp[J·IµÉÝFPK‡ø˜·-WL¶Ä]8)uMC<Ðfëª~8A8ÂHéËLÑüi¶åé¶>NiGI/–¡ºÚ×e.®÷>ÙkÿŒf À~–N¢ çÁEÆ=‰A;”3ì¸ï9¨¼)p -q åÜdîç7EG…ÐT/YÁ©éX_ÕLp1`´Én1„˜ ×yÑ{>ðâ¡{ã¢ñ×¶Û +õë çŽýÁdsn—+p»É»¼ÛÖ‹Á4(Ð8ûàèPÊçgí춦)îÁX¸¢+I#p¿*—‘)0Ó-ŽßâéØBI¿>0½XyÒ¶ñ5ƒ6Ö`±#_¶5ŸxÝõ¢&ŽÅÓHøˆ´8:çeìùRÖ)¼¨+Oʾ¢™E?}¢6‡el#ÉvL膄…Áød`­Ð¥-“gžÚÀŽìH½å ~Dn‰Ã#•w\„ ¸ö!oh7ö˘g‘v ÔcÍ”á§ÔÓ¦0#pZìls +ä¤ëP·=\3µí«ÁÀ¹y ¦¡ž9—‚Ýõ{Œ§ú¯+z¸GzDßZ&Xñnø}Û,ð3`;Ãô€9€Ï6å_:ÔôÉa¢Ö9/zÆžÉ~ð¥Ê¢ÜÎ}37=ð Å0tæ‰O<ö'Ê·æÓZ qèKZˆÝâ0íç4 ³¾íßmlèçb?·Mnˉ To t³fîisÚwõ¦Iö[×kÀÇÉ$¨°ýÐåÌhÍkìò¤š>[4A™ÔÇm’²c„øµiSõ_)Zš„ÅÄêóÃ?ù N[‘ÇÃÚl¨_Š©qèiÝ—f¯ÇÔXônÞ;,,ãò*.Žé‚¨6ý‘@ Ѿä'Tà‹à¸b¾C§$1×-ÂÂ6†hyù]u¶\ãê£A¦q?öÈmŽÉ[þ> endobj +1600 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [63.4454 738.9144 452.088 749.0762] +/Subtype/Link/A<> +>> endobj +1596 0 obj << +/D [1594 0 R /XYZ 56.6929 794.5015 null] +>> endobj +566 0 obj << +/D [1594 0 R /XYZ 56.6929 723.0302 null] +>> endobj +1601 0 obj << +/D [1594 0 R /XYZ 56.6929 689.3491 null] +>> endobj +570 0 obj << +/D [1594 0 R /XYZ 56.6929 552.677 null] +>> endobj +1602 0 obj << +/D [1594 0 R /XYZ 56.6929 525.9649 null] +>> endobj +574 0 obj << +/D [1594 0 R /XYZ 56.6929 411.5673 null] +>> endobj +1603 0 obj << +/D [1594 0 R /XYZ 56.6929 383.9327 null] +>> endobj +578 0 obj << +/D [1594 0 R /XYZ 56.6929 225.6356 null] +>> endobj +1299 0 obj << +/D [1594 0 R /XYZ 56.6929 193.4614 null] +>> endobj +1593 0 obj << +/Font << /F37 791 0 R /F69 1599 0 R /F23 726 0 R /F39 885 0 R /F11 1367 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R /F48 940 0 R /F62 1050 0 R /F63 1053 0 R >> +/XObject << /Im2 1039 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1606 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›ëÄ"’é¹(;/É>V~yAþ.ýÐîÌendstream +endobj +1605 0 obj << +/Type /Page +/Contents 1606 0 R +/Resources 1604 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1592 0 R +>> endobj +1607 0 obj << +/D [1605 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1604 0 obj << +/Font << /F37 791 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1610 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +endobj +1609 0 obj << +/Type /Page +/Contents 1610 0 R +/Resources 1608 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1592 0 R +>> endobj +1611 0 obj << +/D [1609 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1608 0 obj << +/ProcSet [ /PDF ] +>> endobj +1614 0 obj << +/Length 1964 +/Filter /FlateDecode +>> +stream +xÚ¥X[ë¶~?¿ÂoѱV”D]Ò¢i³§I¶EÒ g¢íé-imõH¢#Rv7¿¾3œ¡,ÛJS »&çÎá7äˆbÁ¿Ø2Œ’2ÝäeÊHÈMÕ¿‹6{à}óN°L*“P¦I“îV&E(‹8ßl—F¾zy÷øu,6qfY,7/¯³¯,/Â2IËÍKýàé Ž¶¶±Œ‚âáŸ/"µ4Ì‹\ Z.d˜—Qá^„Á¨§]טƒÖ¶ö³šHÃ$ÍbVË’0Ï"òS„âa+¢( +žtßëþ0j0Ó›‹–Rz Ÿ‹Â˜M<ÛϤ ´¥ÁYŸ šßÐì Ï4¨{{¦ŸQ隣¡™ž¼öA]™=zØÉ‘%›2,³8ãÀ =e*RJÈ,%©v±42º›l‹‹Ä™Õ3õ„Ér“va¨®SI5Ô4¨ôÀQ.¸­1ScüøÚ¶UŸ8Šãø Š 95ƒÝSûF™‰8¬¹{Ã¥ábæœÃbLc݆nã<¦#þfA§÷û™ˆquh9»æU“ÕÄ‚å2¢„°ÞNÎêS[³˜"ºÑ`ÅdýJôC;Xvçòƒ´v¿=ç96X´Û0Ø5× n“ijÚ_LÝn+à¤ÓÃÂ…ïÒS +i ·¥Ý3éÀ–yíˆùðŠ&Â8K<æcø¡›‚hïCû™<»úÐŒ­êhüýÔï Æס\@•‰ó÷w= vVXƃÓÆ-ÈÊ@͉ο&DüL|Œãœ¤!š7¢±Þð+Ôʲb@4@™ þ@ŒN³¬CX;6úØÍ2\ô<Ò스‡yÑ· g°È”}sɘ†€G€"6ù93À͵úFtür²e€h$Òßàï»ïÞ¿ÿñÇ©*e§^[ú¤ïÜvzW¿ ×}kì…{½^¬0‘p‘ÒyE?°)e™í0‹Óàu² |d ‡Æ‹o<ÐĪôHÒÕßO'2ŸëaÍžÑ_5±¹Á’FŠ ÈœŒðiÍZ W +ŠØmT¹,(¾ÊÞñ‰}q´€¨\Â&|&d¾vKÈTÝVŒÐhÆKI›S?s@Õ+6¸k0mHšŽµÇrRϯÄ'¨›CZÙN,HÉÀk™ôjY`:ujˆN^®5ôÛé³'A´é°²\¤A®xYöÊ`3§Áçs³‰uÿŒ`°¡¬mú£]­7>)34n-_³•>¾ñ±ûzs„ašÃÙ`M t9hðÃ|K>xÌ«,«DM¿Š~|ª`x‘â\,Íq.¼éÓlŽò{½$çF.ÝÁÌJö¢´VËlo>ͱýãÓh®o›ÿ+Ÿtc‹lѸÄ"'ÛCv0 +ýf3GÕ51b‘æi‘diNŒ‘Œâ±ˆ±0·"ð0àâÄßZÕ7’\sÂw"ó‡&0ÍåþF—?$cRÍZº”í(õåŠ:éH^04g¢°û(½À ÙWáÓ7˜¿S,[>°úŒ¹…;î3`ô¦'bÕÀ¤Ö^ ïöEy˜]¹œ­Þv‹íçÞa¯Úák@n@þzh|ÇütÓOÓ0J¿mºã—¿ÞeÚâš(°ÁiÇEðá êÍâÀz҃ѣm§žæˆ§çOŒ$ ¸aѯt ÇtéùL]%ŒFèŠâ¹Bˆ%Ç#¥ e/v­Î©­XKí)™®×âX°Åu’_=ÿ~-ÃÔ¶GYðþÛ§päÏH—@ +­è×ØÚ:‰óÎÐÃBYn?z·XdÌqâd¾©Üä¤ÚNí:ørðï»QÕaáƒL·CÕMucVìâªV.Wª4 Û8Hü»Uoy)”@»Zìo+B)ˆ×­©ôD9ƒ©;B.ÊõTyåvÂ)Î6™îZds§¡ÁÓÏMí­µ°r=¶öä&vÓž®é^/yr€¡¶¯ÓP;«y Â1{9B€FãŸà{ËוÂM>p\×-ž‘7>å èWˆÌ¨WKÐÆ 5m"û¿À¥–€ã6WUŸÔž9ZØוå,¶VHbžþ‹'¯´=Í\¦pÀŸ'8TÃ[WyÌ#‰6Éyè5µÒÇî:4 ßál 3,•ßbÏ[œ+ªë/WF".ƒ›ËÊ?@”€/jŒu“1Ô¢+l',{_¼2ãâ•sä®ÏñÛªÊ ¿&–Bú–åç !G˜ +¥Ìrcø-Š¼ûãËü +“¤%œ¡i±Iæ² —â~ÚøÑŸ/¯6³Âv¡ámÒ¥ß;»è½‡CÀê/aïoãã<,EQ^Çsór4 ÝÅpµö;[ÃïVÎy7G)JΑOü©5­¿|hW°hpk·IQ„"é5¶ÏÍŽûª‡]Ù)C™‹_Ú‘Âõ%KÄQXDñ¯oʬ±]ªÜïʽe×SX{üâññ|>‡¼+¾,}w¸ÉÀUßÄx³Q³Ô}\Wù¸·ö߶ +ߣ«ª]qöü´Þíâ³äZÄ^d{‘¡Éep …E\æÞ†RÊ[oóûæ½»ÿ¡êŒêendstream +endobj +1613 0 obj << +/Type /Page +/Contents 1614 0 R +/Resources 1612 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1592 0 R +/Annots [ 1621 0 R 1622 0 R ] +>> endobj +1621 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 +1622 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 +1615 0 obj << +/D [1613 0 R /XYZ 85.0394 794.5015 null] +>> endobj +582 0 obj << +/D [1613 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1616 0 obj << +/D [1613 0 R /XYZ 85.0394 576.7004 null] +>> endobj +586 0 obj << +/D [1613 0 R /XYZ 85.0394 576.7004 null] +>> endobj +1617 0 obj << +/D [1613 0 R /XYZ 85.0394 548.3785 null] +>> endobj +590 0 obj << +/D [1613 0 R /XYZ 85.0394 548.3785 null] +>> endobj +1618 0 obj << +/D [1613 0 R /XYZ 85.0394 518.5228 null] +>> endobj +594 0 obj << +/D [1613 0 R /XYZ 85.0394 460.6968 null] +>> endobj +1619 0 obj << +/D [1613 0 R /XYZ 85.0394 425.0333 null] +>> endobj +598 0 obj << +/D [1613 0 R /XYZ 85.0394 260.2468 null] +>> endobj +1620 0 obj << +/D [1613 0 R /XYZ 85.0394 224.698 null] +>> endobj +1612 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F11 1367 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1625 0 obj << +/Length 69 +/Filter /FlateDecode +>> +stream +xÚ3T0BCS3=3K#KsK=SCS…ä\.…t œ;—!T‰©±ž©‰±1ƒEV.­knj©g`fA‚!ÂVŒendstream +endobj +1624 0 obj << +/Type /Page +/Contents 1625 0 R +/Resources 1623 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1592 0 R +>> endobj +1626 0 obj << +/D [1624 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1623 0 obj << +/ProcSet [ /PDF ] +>> endobj +1629 0 obj << +/Length 2543 +/Filter /FlateDecode +>> +stream +xÚuYYsÛ8~ϯð[誑ÂûØ7[ÎádìrYÎNÕnö"! k’`ÒŠæ×O7ºyØéTJ@£hôñuƒö.\øç]¤ÑÚ ²ð"ÉÂuäzÑE^½s/°öùÇ•²8T²îf²Þ:‹¢A6Ö^yƒì$Mú]·JîiøE™N·gšh&vGIƒ›û- D]°èíý \dë,öc>Ӈ˹!ë[vGÝŽ d¼ ~ø~gx©óÃuý\‰)´¶»ôyPu­êQ¬6sñ] UÓø^TLÝžM'+Éó¾mñ‰ú©3ð{YÊT÷V¯¦ß•*Òõx4ÜoEv%K>~Ú B'óÝßhÄ– +\Ó±8 ØãràÔòD3h Ä“0D,¤É[µ³:Ýê dÐ9 QÔ€EÒÔ'{)Áúrø®óɪ¢«q—µÑ$”ÄêY_ÝÔ'ÿ=>\f¾sUË"' Á_‘k/ƒ“†® +¦6pkK­é·ç÷'‘s[w²…-@Ø£åÌ­ßp,XBšÎÞ'h7ü•¿Ù*Œpv +÷Ãa…|‘¥nl Ø-H±ÈZyá6µ¨€÷ƒ( +RÜŠ1ÏuL~”6`l ¿‚~ZѨ¢<ÓCƒÚ̓ý¬j¢$¸æI·ÏÌ]¿(òAw·øYìÜÛ€eö¢ç9'ÉQ³m§Vu´:Åìe/¡P5G*@'ëR¢tGÑ­Ò…Â<x)aA· +’ r”OœBç=Á 1j"«¢ºÑpQɧUäzý"GöÄÙ G,ØÝfS6ä ÐBdz˜€z²Ó„Q™DÏ B0q¶Ah3>£Œ7«®sÙØ£FfÁ'‘«RuJãÆÕùö‘]ôçÛ/¨N‡ÝVM)gQø|$¶Ì­} 8Épat*ÌÒ¹Ã^‰©€ck ˜Ö…/ ‘úf8ùtTù‘w)Ë¥áZ½RÜ0†Oå:»^•˜Ã&Ù:v3*LO„Y‰ÅèÖt4™\a¼°[`\ÃÈÈö®ž„Ž—ÌÉAM´Ěû«„Ä„ €É,Ö£ÄvFø[vAé÷Aô´QêÜéüY4²³Álˆ†±ˆC¶ýB=ù¸!‚nÌÊw‰P‰ü¨jiˆ¯ÔàbºHêØ슆 Â÷ZÁµêμûž¶ºž–Ï܈RvµïY×ÛæÕ¨äjµ¤½¬s«I˜ŒéT×wìDDåïÛÍêv{K‹<õ0Ø>Þá0(î9±Þs@ܘe·ž«„D±é Ønu»ÁƒÖÄqE?cÔq,¦…îÀ³ÆúE£ÁĘŽAÄ)ôkÙ>ËRži6”šQÑÇÑ í%"Û2R¡q¼µ2$Q†£5ÄÞÞ3Xßñ±bɾ¾Ûºù~­(z‚Hׇ î †FX³Á¿,0x,ã&þ,<^ NÖÀY_Ö# ÆÃkfÝOUÿÕ‰[¸‘{Y›åj_¼ˆ1î𥑈6Hy ÿ/óŽ#窀Š +ã”U#7Cã@Q²€.ÿ¾ô™Ñ„K ÷yIJ­¥¥tG6µí a)\§ë€Ö&tÅŒ‚þ[år Òéú@Øèªé)ŽL½"Ÿûæ¢@ù<ópBµÙ>~æÜpËBtG‰ãÉYxEìÅbè á¥…9`°8#Û–8Ϲ6aù/3!(¬ÝˆUÐâ£:J¼TœpŠq«ëÄLM³ÿ@ÏM •($Ñì]€B‰±c€2i ?P‡nþmD4“Ç v;)*¼Q¾Ý3,$¶×`(‡æJý× éz`ê„Þw§Y1J†|%\‹B¡kùüEÙi¸U³“eÉJ}“/Ë…ü¦¯KÑX%=›4øªQÕ‘¢®óñg¯,•Ä²áŽg k ¥TŸ%#.Q=( ‚ש©ö¦7F ŸgàÑ[¦Ã–è@±¸ˆ$ŸægH@Ä%²ZI(Ž":ž( 6SaUŸiQc¢õFêƆEiX*×5ÔÏ]OÕ-ãÖXXE p³Í‚¥¢o¹‡›MÔºõÁùˆ4òK®øbðج–S€¼V(Ø&ˆ0ð[P£ ÄNg[iÝÑÒF´åêNuЧ—%KÞ©gI«w}o }U¯K­yHÝ2Ž"ÛüÁ×ý ÆŠýô3À‹¬ÉC–Påú‘?{°GÉÏæ#Sð¹c"ˆ£oë¥yó–þ®‚¸åé·žøqsˆ™Ìy™Àfá:ã¤m,ßû¶¿š°f¬…´íº¥®ÙÀoçÁâgþe5ñÐ7þùçìÀשŸ%ÃF¨g–¼=mü‹Áßû j=¢Xendstream +endobj +1628 0 obj << +/Type /Page +/Contents 1629 0 R +/Resources 1627 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1634 0 R +>> endobj +1630 0 obj << +/D [1628 0 R /XYZ 85.0394 794.5015 null] +>> endobj +602 0 obj << +/D [1628 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1631 0 obj << +/D [1628 0 R /XYZ 85.0394 573.5449 null] +>> endobj +606 0 obj << +/D [1628 0 R /XYZ 85.0394 573.5449 null] +>> endobj +1632 0 obj << +/D [1628 0 R /XYZ 85.0394 539.0037 null] +>> endobj +610 0 obj << +/D [1628 0 R /XYZ 85.0394 539.0037 null] +>> endobj +1633 0 obj << +/D [1628 0 R /XYZ 85.0394 510.2426 null] +>> endobj +1627 0 obj << +/Font << /F21 702 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1637 0 obj << +/Length 2893 +/Filter /FlateDecode +>> +stream +xÚ­ksã¸í{~…¿Õ™‰IÔ3ÛéL.›ls×Ë¥‰;íÌíÍ”–h[]Yò‰r²¹__€õ°•½›i“&Ê›¹ðïÍÂȉR?Åià„®βݙ;ÛîÓ™Ç4 K´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ãùë¶È¶o~]½½'¤º` ¤ˆ„w ‰ã:¸¹•Í€TßH(ýæÀù„x^:bÞ÷ÇCÙ¾«ÆÔ bOü?$$õ®Æ^<öÁ^nð¢ +æíœH¸>ø8þzduÖ+ž™ ‰èMY¯0† Ð:„™ ¼‰(5Dòâ=@¶«‡›}´ÁãBnÑŠw|º»!&ñÅÔeúìûÁ'ãL'Ž© ‡â àÎläࢩìÒG¯ÃÍq Iôo£´œ²<Ô‰PÓlÏÍ@ÔÁUæÄG» y¿Nxø¸ë=ãÝ=}ÊSK¨+Š˜5†þsºC:¡'¼£ªÜ¦ÂCìDPÚó’έþÐv±püPص”ï8AâÇcË,)?§½Er¤@@Žh T +$Œ©!cš JÓ©ÍüÉü°×Ê•Ü Ù™E AL&ÚûçÇsjÛ sîOM–c©6ÛòÍ$;³ +v!¨/rÍ[×½® ÞLh܇l›„´¦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º˜¼ý¿ÉY2„endstream +endobj +1636 0 obj << +/Type /Page +/Contents 1637 0 R +/Resources 1635 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1634 0 R +/Annots [ 1641 0 R 1642 0 R ] +>> endobj +1641 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [253.7995 146.8976 417.685 158.9572] +/Subtype/Link/A<> +>> endobj +1642 0 obj << +/Type /Annot +/Border[0 0 0]/H/I/C[0 1 1] +/Rect [63.4454 108.9117 208.8999 119.0735] +/Subtype/Link/A<> +>> endobj +1638 0 obj << +/D [1636 0 R /XYZ 56.6929 794.5015 null] +>> endobj +614 0 obj << +/D [1636 0 R /XYZ 56.6929 652.1213 null] +>> endobj +1639 0 obj << +/D [1636 0 R /XYZ 56.6929 614.8935 null] +>> endobj +618 0 obj << +/D [1636 0 R /XYZ 56.6929 614.8935 null] +>> endobj +1127 0 obj << +/D [1636 0 R /XYZ 56.6929 584.5024 null] +>> endobj +622 0 obj << +/D [1636 0 R /XYZ 56.6929 289.5256 null] +>> endobj +1640 0 obj << +/D [1636 0 R /XYZ 56.6929 251.3901 null] +>> endobj +626 0 obj << +/D [1636 0 R /XYZ 56.6929 251.3901 null] +>> endobj +955 0 obj << +/D [1636 0 R /XYZ 56.6929 222.7156 null] +>> endobj +1643 0 obj << +/D [1636 0 R /XYZ 56.6929 53.7852 null] +>> endobj +1644 0 obj << +/D [1636 0 R /XYZ 56.6929 53.7852 null] +>> endobj +1635 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R /F53 1017 0 R /F11 1367 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1647 0 obj << +/Length 2824 +/Filter /FlateDecode +>> +stream +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©SlÊ-lÌ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¥'@Ùä´“(FQª÷Û‰%å±-eì„ÓÀc'>hËNúØ;±Á;v*v"ÒwU§Ï»¼ÚŠfÊ3—ïçjGñéÉ:ŽBõ6fŠA¯“ÁEöR[;~†BŽ!粤< i)‹!O"óB[ õ± ÙàFÙOÙïÇL‡4cÙþ,Ô–oŠ´>Jj«–,é¼A“ã*—PkPÂÿßlQŒh„ϱeIyØÒRš-±‡-´ÅVÛÁ– þ¤´~ºOÔæ;ÕPZ€ã† ùˆn×Äl׃-FŒG]’¼a®»·ççSÉn,)7ZÊpys¢Úâ¦íàÆ¿É +¨¯…bãX•×"ÚÅÜ^óU&§&»M SÛ½œ“aO>ÒÆJ¸—±$|P,ÓÏ©öZÒ«áBгXÈüè¼&Oy|¹–¡…½rh¡èÿ5-†êÓÙlt_¦‡óÜ¢yk~‡šýQ;|•?—¯öÌ]ÇÊ*ø•éIÂÕýàén§æ>¬êÒ6?:¼¿É#hžúû›m£ÚÒÖl-}׶' ð0ö›µ-å6k#eÌšY{¡[³>Á6ëøm±nlL·•OYUî^µ¢Ç——òPŸtœ‹ùt(SG b†cÿ´,†êY¶ê†ì 'b§ôœÞ-)Þµ”Ñ{B©Gï>hKï}l‡ÞmðåVFƒ” /]xº{«òJÞ U‹ÿrk .ÌÖ\«­5¸Ò™@\Û™`8àSá$í^›X)ðúK^(h¹[Oz:¡,!!Ä‘îŒT=­íÔÓ@fè$“pŒŸÙ#µ¥Üd)MføÈôB·dž`“Ùo æv^À<ߪd>*×GÙÅh£`!,J²¼=sܹIBèXìb*HbÄóù,t=ý ؽW£?¦Õ²;/sŸVU¦#·ÜUNÛcD¤¸ªlx·ègnú#ŒâŸÙ/µ¥<ôk)‹~ϹŸÚ¢¿í ß1SÖm¢‡‘U)RIsÓ¤m +-©ôfªò·¸híEÜ™]§Áƒ ,>q­þ˜2.”öl¡H,[£÷JÜØ‚œ©mqƒÐ¡¾c!½3å¿h Pú2ÑŽûÁ’òƒ–²ŒÁ“P½Ð–1ô±Æ`ƒ««º\•bË +è}¹îí¦'DÕr:Ä‹Y¥ˆ¨ÞV)p'bŒG.» 1JBnsË + +íÆ3aGu1z¯Äµ]¨ð®Vî؃Nç]œp1èž +´ ¸ ¤ƒùÈ +’Tï*ÓªA<—Ǻ·ÃÐû"Âa‡˜%(ŒÏ´’–Û +µ9Te>#ôá¶6Ø6Ay2¾b$´ÌHÜ)³|Þ‰zA 4lY3ª#Óò`ï§6c¿ŒI0‚¶Æ¾[g;µú,{Ù•oúùFÿÍ+”Ÿë¯’ù Ø.…‚1¦‘•ß‹WñÈÌvìï&}•/\ u˜sê 8˜$Ðk“3©-å¡ZKY\{h½ÐÙ}lÛ6ø´Üïå®+Ö›­ßÁä\²Z*)#ý&ÇÍ:±¦‚ñwù·á£s£˜cû‰†Íçƒb‘÷Ç}ªO]žkÓçÁj%¬¼SƒS5ø´‰3zÝÏÞs–äWœ¹Ïw;sâû}&ÁDÂ(ò[„%ä6-Ô~P‘xN|¸­9ô‡­ÁF^d‡\•<ÛkÒlIdu¾ª2!³ðôtÖÅ:Úsq\û½I$Ø‚?Sÿ[Bn…k¡6ãû>ûòᶠ+ï+ÜF6Þuþ}^=gÛô5Õ Œ@õµ®­Ñ LKç„ }RÛˆÈBFo_#y5Y«YÈ°ƒŽAóañEXûDó*å!¯¶yJIŒ/…—(™»¼Øg¹vB½fgÉ>ÜprªÅ'¸ª LnÿË_úZ;‡1¢Iâ8L£A„ÂcýRâWpÞsóIðé«ÿ+Ab«endstream +endobj +1646 0 obj << +/Type /Page +/Contents 1647 0 R +/Resources 1645 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1634 0 R +>> endobj +1648 0 obj << +/D [1646 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1649 0 obj << +/D [1646 0 R /XYZ 85.0394 752.3015 null] +>> endobj +1650 0 obj << +/D [1646 0 R /XYZ 85.0394 752.3015 null] +>> endobj +1651 0 obj << +/D [1646 0 R /XYZ 85.0394 752.3015 null] +>> endobj +1652 0 obj << +/D [1646 0 R /XYZ 85.0394 746.3107 null] +>> endobj +1653 0 obj << +/D [1646 0 R /XYZ 85.0394 731.5461 null] +>> endobj +1654 0 obj << +/D [1646 0 R /XYZ 85.0394 728.1497 null] +>> endobj +1655 0 obj << +/D [1646 0 R /XYZ 85.0394 713.3851 null] +>> endobj +1656 0 obj << +/D [1646 0 R /XYZ 85.0394 709.9887 null] +>> endobj +1657 0 obj << +/D [1646 0 R /XYZ 85.0394 651.9592 null] +>> endobj +1071 0 obj << +/D [1646 0 R /XYZ 85.0394 651.9592 null] +>> endobj +1658 0 obj << +/D [1646 0 R /XYZ 85.0394 651.9592 null] +>> endobj +1659 0 obj << +/D [1646 0 R /XYZ 85.0394 648.8377 null] +>> endobj +1660 0 obj << +/D [1646 0 R /XYZ 85.0394 634.0731 null] +>> endobj +1661 0 obj << +/D [1646 0 R /XYZ 85.0394 630.6767 null] +>> endobj +1662 0 obj << +/D [1646 0 R /XYZ 85.0394 615.9121 null] +>> endobj +1663 0 obj << +/D [1646 0 R /XYZ 85.0394 612.5156 null] +>> endobj +1664 0 obj << +/D [1646 0 R /XYZ 85.0394 585.7959 null] +>> endobj +1665 0 obj << +/D [1646 0 R /XYZ 85.0394 582.3994 null] +>> endobj +1666 0 obj << +/D [1646 0 R /XYZ 85.0394 567.6349 null] +>> endobj +1667 0 obj << +/D [1646 0 R /XYZ 85.0394 564.2384 null] +>> endobj +1668 0 obj << +/D [1646 0 R /XYZ 85.0394 549.5337 null] +>> endobj +1669 0 obj << +/D [1646 0 R /XYZ 85.0394 546.0774 null] +>> endobj +1670 0 obj << +/D [1646 0 R /XYZ 85.0394 531.3128 null] +>> endobj +1671 0 obj << +/D [1646 0 R /XYZ 85.0394 527.9163 null] +>> endobj +1672 0 obj << +/D [1646 0 R /XYZ 85.0394 513.1518 null] +>> endobj +1673 0 obj << +/D [1646 0 R /XYZ 85.0394 509.7553 null] +>> endobj +1674 0 obj << +/D [1646 0 R /XYZ 85.0394 483.0356 null] +>> endobj +1675 0 obj << +/D [1646 0 R /XYZ 85.0394 479.6391 null] +>> endobj +1676 0 obj << +/D [1646 0 R /XYZ 85.0394 464.8745 null] +>> endobj +1677 0 obj << +/D [1646 0 R /XYZ 85.0394 461.4781 null] +>> endobj +1678 0 obj << +/D [1646 0 R /XYZ 85.0394 446.7135 null] +>> endobj +1679 0 obj << +/D [1646 0 R /XYZ 85.0394 443.3171 null] +>> endobj +1680 0 obj << +/D [1646 0 R /XYZ 85.0394 428.5525 null] +>> endobj +1681 0 obj << +/D [1646 0 R /XYZ 85.0394 425.156 null] +>> endobj +1682 0 obj << +/D [1646 0 R /XYZ 85.0394 355.0758 null] +>> endobj +1683 0 obj << +/D [1646 0 R /XYZ 85.0394 355.0758 null] +>> endobj +1684 0 obj << +/D [1646 0 R /XYZ 85.0394 355.0758 null] +>> endobj +1685 0 obj << +/D [1646 0 R /XYZ 85.0394 352.0499 null] +>> endobj +1686 0 obj << +/D [1646 0 R /XYZ 85.0394 337.3452 null] +>> endobj +1687 0 obj << +/D [1646 0 R /XYZ 85.0394 333.8889 null] +>> endobj +1688 0 obj << +/D [1646 0 R /XYZ 85.0394 309.8192 null] +>> endobj +1689 0 obj << +/D [1646 0 R /XYZ 85.0394 303.7727 null] +>> endobj +1690 0 obj << +/D [1646 0 R /XYZ 85.0394 278.3282 null] +>> endobj +1691 0 obj << +/D [1646 0 R /XYZ 85.0394 273.6565 null] +>> endobj +1692 0 obj << +/D [1646 0 R /XYZ 85.0394 246.9367 null] +>> endobj +1693 0 obj << +/D [1646 0 R /XYZ 85.0394 243.5403 null] +>> endobj +1694 0 obj << +/D [1646 0 R /XYZ 85.0394 173.5556 null] +>> endobj +1695 0 obj << +/D [1646 0 R /XYZ 85.0394 173.5556 null] +>> endobj +1696 0 obj << +/D [1646 0 R /XYZ 85.0394 173.5556 null] +>> endobj +1697 0 obj << +/D [1646 0 R /XYZ 85.0394 170.4341 null] +>> endobj +1698 0 obj << +/D [1646 0 R /XYZ 85.0394 144.9896 null] +>> endobj +1699 0 obj << +/D [1646 0 R /XYZ 85.0394 140.3179 null] +>> endobj +1700 0 obj << +/D [1646 0 R /XYZ 85.0394 113.5982 null] +>> endobj +1701 0 obj << +/D [1646 0 R /XYZ 85.0394 110.2017 null] +>> endobj +1702 0 obj << +/D [1646 0 R /XYZ 85.0394 95.4372 null] +>> endobj +1703 0 obj << +/D [1646 0 R /XYZ 85.0394 92.0407 null] +>> endobj +1645 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1706 0 obj << +/Length 2889 +/Filter /FlateDecode +>> +stream +xÚµšKsÛ8Çïþ:JU1>´¥ØJlÅ+ÙÙ™Êä@KtÌ2E:"•Äß~ă E‚™ÝÚòÁÐÄ_ÂÝ@7I&þÈÄõÒpâ‡r1q'Ûýž|ƒ¾«3"mΕѹiuqöÇ{æOBzÔ›Ü?c™Üï¾L#ÄÐ FÀÓ‹åÅÍòÓÕ:º»þkvN]<ý»8ZÍŇÍÃÕÕbs¿׋h¾\] ™û^ˆ§ÑÝÝb5_þ)ú#>*Ö­—‹Íìëý‡³Å½þÚæO#˜ñïüýìËW<ÙÁ/üp† wò>`DÂNögŽËë0¦Z²³ÍÙ¿ô€Fo}kïTŒ(óhÏ\Q2!…®K[“å†Èc”Õ“µNÊâxØ&r +’mq؉ëûÌÀÛkRþJFï;@ÃJ|)ÖPYñïôeýþ’€}í*Ja:\ß.­­NµYhhê#—úmíUò~>aÓùj#.ÖkÙü1ÍÓ*-òzN:?…`¦•yð%ø@ïà.Š§—èý,¤S$ÆXüH3LŸãCUéìŠêÿtzïã—¢”½kÙûeû8Ïå q¾Íw3BC5øm±}‰_“êÂÝðý`&ÔW:Ë@øǧmU<Â÷¨)âÃhˆ°†(ðœ¦Õ0am¥ ûØ&l•nŸh÷ni °ðÓW›èN-{îLÛz1ƒ¶ú¡ì/ø Òü›ø 0ñÑdïe‘%YË{ºœa>è3âp0¬,”•æø66iƒCW»Ÿƒ©ñµìOo“Ü .½éSqm‹_¯5¤,ÅdBçM±¹ë ‹eÆ{ÝàMSÙQ='âb^ìãTv®â½lݼ•U²ïÁÊ0A.¢ VFÀ{å`ñ´”mÏAÇç™ëNÓ_i"=Ns®/Œv?ó)z×YK¹*æéö%ÍË"—âüÞôºð†×…ÛžÃÆüÓ°²¬ e¥ÖÅ.µ¬ ›´±.ºÚýëÂÔ†uÁˆ+Ü”§Ž¿¼¡^übóšlÓ§·zeðÏ5rnÙ,Þ\ÊüéCžrP¢±³ÍBËr—äUÊÏUÉ¡MGò™ŠåЦc9Ó±œYc9C~à23–‡bæƒÅyšdb‹¡ñ©ø-om¡†=*Ëàk)ÖÇ<Ñ ýaÐ.EÌÙhÃÊZYiДa h›´º«ÝÚÔþ˜È5¾øµ}Žóor"æI–|SÛq'‘Û:\žÜzµé;Y.$2¬}°RG§¨jí‘ݳ“…£Èq¼1 +†•…‚²Ò`¯·P°IºÚýLíù&?ýã⯲s¬Ø,¯dSšwç]ù?ý +?â7?Òù1Щsàží’9(ô½6¡¹$´ˆË*‹_ÙÌjGß½Sçbá÷ÏšX8LŒÀÌ6 + 1eeó-ÄlÒ±®v?1S{½‰þ¸»°³øŠó‰,ú. çøÀ ǨVªÊª¡êXÎ1ViƒjW»Ÿª©=Oªxûœìþ›QdïF¢Ì.cŽûÞ*¤‘!ñFИVÃh´•Fã–€UºAs¢Ý‹¦¥]m|U§ Dä92˜–F€wH'óyJ¦Ï ÊWýi) ¢U‚]›5¯Ì|ò9ÇG$ð&D_ja £:Д„\£$t# eªb­°•]<?f„µHÞ'‡Y0m²IŠñp‰–y.Â4 #+À°²¬e¥W@H\Ë +°I+ «Ý¿Lí{Ôqî‹5eÇaÓèX=ö[½‰®»"ååÑÇ¡®¢»ûµðOÞ_3æ}í¬“wÉä¤?Èz®Óð†hÁSÃú.•®‘Wä‘ÊïlEÕMò +ñC§)vŽ ¶á‘#occa(lAFˆ%¼ZD ~mÕ~z*?èn®£s"`Èl„Ê£.¥”[ˆ™¼À•(ÔU½¥Fõ–èê-i2\l—ðÀŒ˜cˆˆ¿´uæåE\#þò‚tü&™ª1ZP"¦}Ô Ç‘…£4j@RKÝΦkì÷£4„£&]ÉøZ?¤üÑ`'¿¿IËJ¦ž"öâv1Ž7܉üðô+)‡²w7JcðìLÚ[ªz!¯*¶Ï'5+0ˆ8ˆ‘ÐÌ0¦Œ407´”lº °®p/0SXÔP8þª’¼¬ŸTÂŒEMþ—Ç××âP £åhü‘JQ6‡F¯¯2ㄽÐØêN7HÜqÿ\ìE¾À[/eëõ1_eëg]0‡®ešÇy%»D + ͪ§ÕÚÁ´8¦e™öÕ€0&Ì‹· !6¬,Œ••ÙRM°J”»Úý˜Mík˜´L?gTÎö¿äÅϼë´7ß“.×rí²·üC㇌¤ó]Ë*~*›ÌñtûcêL뽈KV0£ü LHû9­®lé:–~p0ÀòYÈqðH6­†™k«æÍL†™[¥æ'Ú½Ì[Úz>ù¶ØÀ_%ÕÏâðÒä0ݺà'˜¾Ão@Æ¢Ø ,aö³ù¡õÖX¯‡4SÉK0œ¼7D«˜VJʪ¡dÛ/­Ò¥®v?%S{|?¦bÛ'¹ÚõÙ<ò⟮ ½až«¹{ÍÒ­QHoʺ2r÷¹¥É“Ó)œ_â]2P.·Aaðcg¤^gZY (+ Å m®c“6 tµû¡˜Úãéý¦:·•“Igæg=[cè"ÏgN{ò?Hç¸À“þϯíUq± 8¼P2ڮ嗪+ñŸ|uõ‚ïéwÿ–¡OYendstream +endobj +1705 0 obj << +/Type /Page +/Contents 1706 0 R +/Resources 1704 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1634 0 R +>> endobj +1707 0 obj << +/D [1705 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1708 0 obj << +/D [1705 0 R /XYZ 56.6929 748.5056 null] +>> endobj +1709 0 obj << +/D [1705 0 R /XYZ 56.6929 748.5056 null] +>> endobj +1710 0 obj << +/D [1705 0 R /XYZ 56.6929 748.5056 null] +>> endobj +1711 0 obj << +/D [1705 0 R /XYZ 56.6929 743.7078 null] +>> endobj +1712 0 obj << +/D [1705 0 R /XYZ 56.6929 719.6381 null] +>> endobj +1713 0 obj << +/D [1705 0 R /XYZ 56.6929 711.8197 null] +>> endobj +1714 0 obj << +/D [1705 0 R /XYZ 56.6929 697.0552 null] +>> endobj +1715 0 obj << +/D [1705 0 R /XYZ 56.6929 691.8868 null] +>> endobj +1716 0 obj << +/D [1705 0 R /XYZ 56.6929 665.1671 null] +>> endobj +1717 0 obj << +/D [1705 0 R /XYZ 56.6929 659.9987 null] +>> endobj +1718 0 obj << +/D [1705 0 R /XYZ 56.6929 635.929 null] +>> endobj +1719 0 obj << +/D [1705 0 R /XYZ 56.6929 628.1106 null] +>> endobj +1720 0 obj << +/D [1705 0 R /XYZ 56.6929 601.3909 null] +>> endobj +1721 0 obj << +/D [1705 0 R /XYZ 56.6929 596.2225 null] +>> endobj +1722 0 obj << +/D [1705 0 R /XYZ 56.6929 569.5028 null] +>> endobj +1723 0 obj << +/D [1705 0 R /XYZ 56.6929 564.3344 null] +>> endobj +1724 0 obj << +/D [1705 0 R /XYZ 56.6929 549.6297 null] +>> endobj +1725 0 obj << +/D [1705 0 R /XYZ 56.6929 544.4015 null] +>> endobj +1726 0 obj << +/D [1705 0 R /XYZ 56.6929 529.6968 null] +>> endobj +1727 0 obj << +/D [1705 0 R /XYZ 56.6929 524.4686 null] +>> endobj +1728 0 obj << +/D [1705 0 R /XYZ 56.6929 500.3989 null] +>> endobj +1729 0 obj << +/D [1705 0 R /XYZ 56.6929 492.5805 null] +>> endobj +1730 0 obj << +/D [1705 0 R /XYZ 56.6929 467.136 null] +>> endobj +1731 0 obj << +/D [1705 0 R /XYZ 56.6929 460.6924 null] +>> endobj +1732 0 obj << +/D [1705 0 R /XYZ 56.6929 436.6227 null] +>> endobj +1733 0 obj << +/D [1705 0 R /XYZ 56.6929 428.8043 null] +>> endobj +1734 0 obj << +/D [1705 0 R /XYZ 56.6929 414.0996 null] +>> endobj +1735 0 obj << +/D [1705 0 R /XYZ 56.6929 408.8714 null] +>> endobj +1736 0 obj << +/D [1705 0 R /XYZ 56.6929 382.1516 null] +>> endobj +1737 0 obj << +/D [1705 0 R /XYZ 56.6929 376.9833 null] +>> endobj +1738 0 obj << +/D [1705 0 R /XYZ 56.6929 350.2636 null] +>> endobj +1739 0 obj << +/D [1705 0 R /XYZ 56.6929 345.0952 null] +>> endobj +1740 0 obj << +/D [1705 0 R /XYZ 56.6929 321.0255 null] +>> endobj +1741 0 obj << +/D [1705 0 R /XYZ 56.6929 313.2071 null] +>> endobj +1742 0 obj << +/D [1705 0 R /XYZ 56.6929 298.5024 null] +>> endobj +1743 0 obj << +/D [1705 0 R /XYZ 56.6929 293.2742 null] +>> endobj +1744 0 obj << +/D [1705 0 R /XYZ 56.6929 267.8297 null] +>> endobj +1745 0 obj << +/D [1705 0 R /XYZ 56.6929 261.3861 null] +>> endobj +1746 0 obj << +/D [1705 0 R /XYZ 56.6929 199.468 null] +>> endobj +1747 0 obj << +/D [1705 0 R /XYZ 56.6929 199.468 null] +>> endobj +1748 0 obj << +/D [1705 0 R /XYZ 56.6929 199.468 null] +>> endobj +1749 0 obj << +/D [1705 0 R /XYZ 56.6929 191.7053 null] +>> endobj +1750 0 obj << +/D [1705 0 R /XYZ 56.6929 176.9408 null] +>> endobj +1751 0 obj << +/D [1705 0 R /XYZ 56.6929 171.7724 null] +>> endobj +1752 0 obj << +/D [1705 0 R /XYZ 56.6929 157.0677 null] +>> endobj +1753 0 obj << +/D [1705 0 R /XYZ 56.6929 151.8395 null] +>> endobj +1754 0 obj << +/D [1705 0 R /XYZ 56.6929 137.1348 null] +>> endobj +1755 0 obj << +/D [1705 0 R /XYZ 56.6929 131.9066 null] +>> endobj +1756 0 obj << +/D [1705 0 R /XYZ 56.6929 117.2018 null] +>> endobj +1757 0 obj << +/D [1705 0 R /XYZ 56.6929 111.9736 null] +>> endobj +1758 0 obj << +/D [1705 0 R /XYZ 56.6929 97.2091 null] +>> endobj +1759 0 obj << +/D [1705 0 R /XYZ 56.6929 92.0407 null] +>> endobj +1704 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1762 0 obj << +/Length 2542 +/Filter /FlateDecode +>> +stream +xÚ¥Z[w£º~ϯð£½Ö˜Jqé›'Og’ÔÎô´kÎy ¶â°ŠÁœ9s~}·Ð‘<=]yH>Øß¾cEÓ…7›S„ÔêÍíf6„o¾¢éõêúóêñ~½xúø/qѯˆ¢ÅÃRœl¾Þßßnžoåéúv±\=܃žýöüéêöY?¶ùjþÌÿ¹úöšìà ?]!$1|‡äá$ñ'‡«€„¨•üjsõw}Cc·½tLU”ÄýhDW>ž`ì%”ú=eÑÄ ‰OZe-6⵬J›¬,jë[ Oq.-#€Œ‘%d8ú·õÝ (Šü6ÄÄyqÏïÕ2CT8ìP1¥^jÂ.ËCšâ½ÓÝ!+²º—/«Z¬•.Úóý)Û1?ãà•pH½ cx ~ßBü‹'þ.¸ç, +ÔÆCùÎ/¬g8‰#Ϫl Η6äP·!åP¸’Ò*§$r¨Üm(}ˆmQ» ~S¥T¼¶¼eÚ¤âè.Ë™8º)‹_ò÷'ÁƒX¼­ªŽ§œ¦*@™A>O3ì'SÉÇ5cUéÜ{Ü6¥AFB¬d„ †t!T™Rv2´”&#Á¾ 'tGÆö8=ðQ2tHséÅîÏRâcê…qì÷)Y*6ÒÊô;öRÍâé)­~hFB;#¼9EñF )#JJ1â#ŒŒ¸  F†ØFLð3åßTYêLºÇk)u]–Œ(éAz̆UשׁG£Tƒ ÆaŸ‡kÉ×´(²b?`»ç8ÿ˜Q:Í~ϘÅs<>Â_ ©r°$…4I>N$9p ŽÀŠ 䯵Twù:pœEž¥5«L=°æ{Yý»£(Û²qŽÂØ‹ü Ï$ÓC–7Êé4Ik¹ý ÷£*Û¿5‚"Ù+æ>I¶Pn ü@ÄHB;I ¡]Ktº8ól«ËGXáÝÄjù°P-Ã0MÀL(6ƒ‹º 'wiÞ@‰Úh¢¾ÀG°5Ø|=¤E»KžùóHž5Ì\‡€¶¨–ç¥fºÙ¾i¾íU…ôN‰!¸›RÆ•”A9vPî‚68b[H7Á9£ÂÅØ|šÒ„»>»i*°µÇ×€%Á /ŒxéÊÅÚØÏ÷Fâ(ßWæÃEtšDœ@Æ6}8@aÇ8¿Á¸¸WK8ßù¢W7é~§Åö5‚ð &ÐA]Ê榔p-eî(ƒÐágØã„÷ÀŸNÅm¹c<€Ó¨ó™^C‰U·„óó`Ê +‘gDDvXýZdüR±(’>¬Ž%PØ×q#êâ,«%7æ-y¨^ôB0WD¡õˈ…§JøŸrö³:û ¸ÊY'ˆŒ¨2”¨‚æËÓF @¨µ> ‡ÐÈ¿P˜R3RRº›‚ÐaF.hÃŒ†Ø32Á¿Ö­uˆ]Vçê(•:_ÝübU”¥ÜàÓ\ÄÞ¢zÉšªí‡Än¥ œ¼œKðˆ zløÓô´Eé˜éÛ EðÂñ…v”r¡¤4$pt‘Nhƒˆ!¶…\g„P×üPÔnppSŽiñ£Gkñž½y#$¾Äæt‡$dúÉWþ-gd¦vÕ×îÁw~áì”ù«¼@?½Ü„þ¯~ùÑEy¹Ns˜-b+Ÿ~D½(¼”.L);ŸZªã“:ŠG'tÇçö8Ÿ=ð…ž¾³¢‹Þ)—’UÁÀùTõÇg9µcºrÖ(£úÿ¬·é¶ÝM ¼ƒ ¼tBZ¤.éQäèá\¸)` 'òšA7FØÖ¨™-b¸"2ú]¨JÑŽ¼¡ Ý—àyõ`è×’5J%^ƒúû“¤¨sÆщ7àØN¡^€‚ ¥€)å JIi¦ 7;˜rAT ±-\™àKþåW²­›$œ.Nͨ¼ŒóÎÄ’ˆƒüH¹ùI4}çsñvõM42¼ùàç¼+KëFÞo·›u=êTt„) ºC(ù>Š»ïÚñ7ßµ„ž©«{ˆôíDB—-Ô…/{¦”ƒH%¥‰LËå\БCl ‘&¸®éVOÅxê¨Ò¢îŠ¼³/÷üÓjžlü›òž:Gkêå©Òžª”«­ÞëÊÙ6ìØ¥0Xfâ{1Oý™øãK]æ¬a4°´Ã1gˆýªó½ý^1ã+êyˆ±Ø&GÁXܶ`JÙmAK]”#):¡;[8÷…¸°?œÞvC8k£'ü¿gå¾JoहXùì(0Cß‹)MÌá(žÞxâ»T|dy.wÚ/&>tËÛ·Sþ“«)ÿ”³¬)˜þîH°äö–RšŽ]Ydd¥£ð{ó˜ÿ¡…×РînJ9(VRºî #G£ì„6(b[(6Á¯³B§­Ïé S=sv–iG{ +9±ôIŒ»©Òï¯bF²SÁà´?Õæ!±ò¡‘n !; J¨û$9úhnÇÁxœY8YŒ!à4¼ªÅœ7%ÿo6×°(£2ùP.ì÷ba¯¾ëÇÊ+à.kVœ¸¥7álE‘9ôˆAWܧ«»­Ì›òž[ݨϧÌøƧSþ3ŸŸxYAFméÿÿ ˘OF‰m3Ù…«‡j»#tö{1ýÓ­ógÿ/’#÷ðendstream +endobj +1761 0 obj << +/Type /Page +/Contents 1762 0 R +/Resources 1760 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1634 0 R +>> endobj +1763 0 obj << +/D [1761 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1764 0 obj << +/D [1761 0 R /XYZ 85.0394 748.4854 null] +>> endobj +1765 0 obj << +/D [1761 0 R /XYZ 85.0394 748.4854 null] +>> endobj +1766 0 obj << +/D [1761 0 R /XYZ 85.0394 748.4854 null] +>> endobj +1767 0 obj << +/D [1761 0 R /XYZ 85.0394 743.3452 null] +>> endobj +1768 0 obj << +/D [1761 0 R /XYZ 85.0394 728.6405 null] +>> endobj +1769 0 obj << +/D [1761 0 R /XYZ 85.0394 723.1655 null] +>> endobj +1770 0 obj << +/D [1761 0 R /XYZ 85.0394 708.4607 null] +>> endobj +1771 0 obj << +/D [1761 0 R /XYZ 85.0394 702.9857 null] +>> endobj +1772 0 obj << +/D [1761 0 R /XYZ 85.0394 688.2211 null] +>> endobj +1773 0 obj << +/D [1761 0 R /XYZ 85.0394 682.8059 null] +>> endobj +1774 0 obj << +/D [1761 0 R /XYZ 85.0394 668.0414 null] +>> endobj +1775 0 obj << +/D [1761 0 R /XYZ 85.0394 662.6262 null] +>> endobj +1776 0 obj << +/D [1761 0 R /XYZ 85.0394 599.7666 null] +>> endobj +1777 0 obj << +/D [1761 0 R /XYZ 85.0394 599.7666 null] +>> endobj +1778 0 obj << +/D [1761 0 R /XYZ 85.0394 599.7666 null] +>> endobj +1779 0 obj << +/D [1761 0 R /XYZ 85.0394 591.7571 null] +>> endobj +1780 0 obj << +/D [1761 0 R /XYZ 85.0394 565.0374 null] +>> endobj +1781 0 obj << +/D [1761 0 R /XYZ 85.0394 559.6222 null] +>> endobj +1782 0 obj << +/D [1761 0 R /XYZ 85.0394 534.1777 null] +>> endobj +1783 0 obj << +/D [1761 0 R /XYZ 85.0394 527.4872 null] +>> endobj +1784 0 obj << +/D [1761 0 R /XYZ 85.0394 502.0427 null] +>> endobj +1785 0 obj << +/D [1761 0 R /XYZ 85.0394 495.3523 null] +>> endobj +1786 0 obj << +/D [1761 0 R /XYZ 85.0394 420.5376 null] +>> endobj +1787 0 obj << +/D [1761 0 R /XYZ 85.0394 420.5376 null] +>> endobj +1788 0 obj << +/D [1761 0 R /XYZ 85.0394 420.5376 null] +>> endobj +1789 0 obj << +/D [1761 0 R /XYZ 85.0394 412.5281 null] +>> endobj +1790 0 obj << +/D [1761 0 R /XYZ 85.0394 388.4584 null] +>> endobj +1791 0 obj << +/D [1761 0 R /XYZ 85.0394 380.3932 null] +>> endobj +1792 0 obj << +/D [1761 0 R /XYZ 85.0394 365.6884 null] +>> endobj +1793 0 obj << +/D [1761 0 R /XYZ 85.0394 360.2134 null] +>> endobj +1794 0 obj << +/D [1761 0 R /XYZ 85.0394 345.4488 null] +>> endobj +1795 0 obj << +/D [1761 0 R /XYZ 85.0394 340.0336 null] +>> endobj +1796 0 obj << +/D [1761 0 R /XYZ 85.0394 325.269 null] +>> endobj +1797 0 obj << +/D [1761 0 R /XYZ 85.0394 319.8539 null] +>> endobj +1798 0 obj << +/D [1761 0 R /XYZ 85.0394 295.7842 null] +>> endobj +1799 0 obj << +/D [1761 0 R /XYZ 85.0394 287.7189 null] +>> endobj +1800 0 obj << +/D [1761 0 R /XYZ 85.0394 272.9543 null] +>> endobj +1801 0 obj << +/D [1761 0 R /XYZ 85.0394 267.5392 null] +>> endobj +1802 0 obj << +/D [1761 0 R /XYZ 85.0394 252.7746 null] +>> endobj +1803 0 obj << +/D [1761 0 R /XYZ 85.0394 247.3594 null] +>> endobj +1804 0 obj << +/D [1761 0 R /XYZ 85.0394 223.2897 null] +>> endobj +1805 0 obj << +/D [1761 0 R /XYZ 85.0394 215.2245 null] +>> endobj +1806 0 obj << +/D [1761 0 R /XYZ 85.0394 149.4956 null] +>> endobj +1807 0 obj << +/D [1761 0 R /XYZ 85.0394 149.4956 null] +>> endobj +1808 0 obj << +/D [1761 0 R /XYZ 85.0394 149.4956 null] +>> endobj +1809 0 obj << +/D [1761 0 R /XYZ 85.0394 144.3554 null] +>> endobj +1810 0 obj << +/D [1761 0 R /XYZ 85.0394 120.2857 null] +>> endobj +1811 0 obj << +/D [1761 0 R /XYZ 85.0394 112.2205 null] +>> endobj +1812 0 obj << +/D [1761 0 R /XYZ 85.0394 97.4559 null] +>> endobj +1813 0 obj << +/D [1761 0 R /XYZ 85.0394 92.0407 null] +>> endobj +1760 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1816 0 obj << +/Length 2121 +/Filter /FlateDecode +>> +stream +xÚ¥YIs㸾ûWèª*B°pÍM¶ÔŽ»=¶cy*™t÷¦`‰eŠÔˆ”»5¿>x J$5•”Äòà}x 6¢ðc#Ï'~Ä£Q¹Ä£Ì%›+:ZÁÜí34“šhbS]¿\ýí“F‰|î^Þ,Y!¡aÈF/˯Δ2 Ô¹¾»¾¿{¼}ž>ýã·ñ„{ÔùF=:}˜agñëíí|ñ27Ýçùtv÷p $l< üˆ:Ó§§ùÃìîß8?URi3z3_Œ¿¿|¾š¿4˶·Æ¨Pkþýêëw:ZÂ?_Q"¢Ðý€%,Šøhsåz‚x®õHvµ¸úg#Кլ¦b”páó[q6bŒDžÇ[Æò"â .´±_Ë"“•\âg c™ìwiu0¦ùtSönV¸Ð Ñ-*\›è±¦RKû +Z9õ½ï§šç`/VÝPë‘¥›ñ€xÇù>Þ”VØr­hÒÀúà\¤=ê’êxG¢ì QÁtz-äNwg)Ö¨(ëIsž Žª8êÃmpÔ‡<Þ¤ v~Ý.ãJvA1âòÈ‚PóüÖšaƒŸéM·»4Ãæ ~è“0 | +›ª‹†ªÃ~4¨úˆÆ™îN8Zº/Û¿h†ý($Š¼ÿƒ_bÝMÖ Q?~H"\ÈK6Õ5Uƒ 4ÀaHµ…éînlÝ5" ªUã Û " tž„\°˜ß`:Ôé*Oóv¦ûj]húsœ¸Ï ]EV¸ãܹ&Èø¯qÄ™e ©*tãÂy(>äæUî0ŒÕü­(Æ)¥ý˜‰ˆP7º„™E5€YMuÄ,¢˜ ©¶0;ÕÝ™­»'7.‚Ý›,Þ¥ß(åI\5ƒõ÷?E^»\Wû.§â, 4àaÛ«æÆ«îå´ìv"„õÂaÌ/bQ RS5€¸îP0Rmrª»[÷}ºI+ôÈÒÕZy¤àERl%Žo8dæ\çËü7y–e™)1SÏ2)vKl+w{~Ö®Ö¬! +¸÷‹Š{Jð/qYÊŽéZA/‰E©¢—›ÉÄv±Zæ©ñ^H=Hœ‡ê<›ªÒ†ªÔ÷ T}„ôLw'¤-ÝÏr)•óä):‚_í" :ÖɼJÁÃT¬çâ*Æ–¾QÌL”„þkZuaHC°ÈcL¤ c"ð´c"Ž!–Ðx4D·ûåfŸ/ËREM±Ú±‰¥µ—Š~HU uÙDD€" Ï<7¤×‚óDq7š–â™ÌäÊŠ‚*aÕvÐ m0éMËqý±¦îõGŽë†¬1MÄlÁ„JíyW—†j@›j’šªÁ$ô±!Õ(§º»Q±uß(Éáhö죶ÅM±Ù^¯iÖd··bW[íOÙájªD7j£³0è §¥H +\§Il‡·îLx‹j›šÊÂfà²4¨ÚÂæTw76¶î¦>wëºPµšúÚ:ƒ©†) ¡o¼ÆN¼H/2Æ‹P¬}9ƒþ<¯vl>i^¹ó§#Û§,^uà,à²ËÁ uLlF[1±vÎ/EöŽwgÕûlFÉ:;T­#¡£o_!dÝèO rÄ /Ý$lªþÓP5'&*‚UOÌ™îÎÓÒÝS•ž^ô…Oþ¬` u!Wt-ªçÙtìy΋òÌ)}*v›¸3ú°ò»mçÀqº_íËê«Ó‡±‰€á2ª!áA¹Gýæ‘' .Î]rsi$Ívñ[ÕULSHÊ.Dæj WèÕ\ÐÆ‚ïnV+ÀdÜ :º]ìWëÉRñààb÷®‹OÅ¿,’ýj’çTÉ¢¾ºîTómÍó|•æRî »1v\¾#1˜]X½01˜]K|P¢m/2kÔÅKèèëd8êÏ<ÁÑ_ +aÜo汆ÆÙ3¨¢sõd¥Ë*^ÉÛXxùÎR~ȬتýÁŠüˆ9w›m&U¿Øé½cïU¢Àâ,pò¢2ª‹ö6°L@ÎU\¿²q8.€6býN}×I?âL¥°Ž ®üHU®‹}fFµVÕx•øý}_à»*ê¬cIj†\m­17ÂÞÔ©ÏpÐƺû<3ú$)6“.|¶qžjéŒ:¯ü≀Æ2-“,N7:‡ê‰¸jH ññBçç®:s%võrá‹(+$-K¢èp +uüa„ÄøÉÒ7YÂò°§O+|Ëô'66E^­ /œ÷z‰?Ö)\6;6jVìÙ+†ÎRZ/ÙÉT[?뙉Wà +BRSOÄú1£ì ô<(AD]­Xx©°óZìM¬¸¾{˜åºP¬ú\J"VßCÞäN¹Qï3;¡Ô»pý²©Î“ ì‚™8 +ÓÙ„õç‘A­Ç> endobj +1817 0 obj << +/D [1815 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1818 0 obj << +/D [1815 0 R /XYZ 56.6929 749.4437 null] +>> endobj +1819 0 obj << +/D [1815 0 R /XYZ 56.6929 749.4437 null] +>> endobj +1820 0 obj << +/D [1815 0 R /XYZ 56.6929 749.4437 null] +>> endobj +1821 0 obj << +/D [1815 0 R /XYZ 56.6929 746.6461 null] +>> endobj +1822 0 obj << +/D [1815 0 R /XYZ 56.6929 722.5763 null] +>> endobj +1823 0 obj << +/D [1815 0 R /XYZ 56.6929 716.7581 null] +>> endobj +1824 0 obj << +/D [1815 0 R /XYZ 56.6929 701.9936 null] +>> endobj +1825 0 obj << +/D [1815 0 R /XYZ 56.6929 698.8254 null] +>> endobj +1826 0 obj << +/D [1815 0 R /XYZ 56.6929 684.1207 null] +>> endobj +1827 0 obj << +/D [1815 0 R /XYZ 56.6929 680.8926 null] +>> endobj +1828 0 obj << +/D [1815 0 R /XYZ 56.6929 656.8229 null] +>> endobj +1829 0 obj << +/D [1815 0 R /XYZ 56.6929 651.0047 null] +>> endobj +1830 0 obj << +/D [1815 0 R /XYZ 56.6929 636.3 null] +>> endobj +1831 0 obj << +/D [1815 0 R /XYZ 56.6929 633.072 null] +>> endobj +1832 0 obj << +/D [1815 0 R /XYZ 56.6929 609.0023 null] +>> endobj +1833 0 obj << +/D [1815 0 R /XYZ 56.6929 603.184 null] +>> endobj +1834 0 obj << +/D [1815 0 R /XYZ 56.6929 579.1143 null] +>> endobj +1835 0 obj << +/D [1815 0 R /XYZ 56.6929 573.2961 null] +>> endobj +1836 0 obj << +/D [1815 0 R /XYZ 56.6929 558.5914 null] +>> endobj +1837 0 obj << +/D [1815 0 R /XYZ 56.6929 555.3634 null] +>> endobj +1838 0 obj << +/D [1815 0 R /XYZ 56.6929 540.5988 null] +>> endobj +1839 0 obj << +/D [1815 0 R /XYZ 56.6929 537.4306 null] +>> endobj +1840 0 obj << +/D [1815 0 R /XYZ 56.6929 510.7109 null] +>> endobj +1841 0 obj << +/D [1815 0 R /XYZ 56.6929 507.5427 null] +>> endobj +630 0 obj << +/D [1815 0 R /XYZ 56.6929 477.5928 null] +>> endobj +1842 0 obj << +/D [1815 0 R /XYZ 56.6929 453.2532 null] +>> endobj +634 0 obj << +/D [1815 0 R /XYZ 56.6929 369.7201 null] +>> endobj +1843 0 obj << +/D [1815 0 R /XYZ 56.6929 345.3805 null] +>> endobj +1844 0 obj << +/D [1815 0 R /XYZ 56.6929 310.6805 null] +>> endobj +1845 0 obj << +/D [1815 0 R /XYZ 56.6929 310.6805 null] +>> endobj +1846 0 obj << +/D [1815 0 R /XYZ 56.6929 310.6805 null] +>> endobj +1847 0 obj << +/D [1815 0 R /XYZ 56.6929 310.6805 null] +>> endobj +1814 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R /F14 729 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1850 0 obj << +/Length 1945 +/Filter /FlateDecode +>> +stream +xÚµX[Ûº~ϯ0Ð>x#†wI穹µÙdS4[ô!Ù­MÛBdI±äÝEÿ{g8¤lyåcÅ+r8ü83œ-fþÄ,3Œ«\ÏÒ\3Ã…™-¶¯øl k{%6Š­L&V£2f2™Î’S·÷¯^ÿUŠ™äÌZif÷«á,›¦Œç³ûå×ù›¶uõ²üy“HÃçooî£]š¥Y*p‡Rf•±~ǧ¢Þñ·ÅÚuá™ÒV†=Ö0ËMæ÷¼eâ&œóù²\#?2¨”)kIŒ»b뎚å,·Ò%˜Ê@fäÂÍþÜoR¦4z÷…UÓ|ß·4Þ÷eUö‡£`‚åÆDÁ´`2¤Ì—CÝ´]éuxõá~°©åL(°¨– “«)» S}áR2Î@{Ç!ühq¢a¼’kÐÓ‚µ¾þ¥s»'·{Óä‘t2§F2e™äé9æ÷ÿævµè‰B¯7Y6KÿÝm³ëÿtÉÙù?®Š}Ad©X.¸:Çë¯âõ‡öÀûyÝi +O3i_Üüá*Ü×ͶXüú€ZÿúÝ&sÎtÎí9´FöÁgDr®¸ßÏW„Ž¼hŒ8öN'?önwhÚž1öp)öU*™NʼnýSˆË±?pc?Ù\ÍHfs•þÑN ~G´È5m]5E•Œ¬˜9X6šõJö}ÿáË»ÜþýþöóÝÀ=Jþ#P“ÿË +! ˆ(ñ7|Ùl‹²†B ù¼¬WÍn[ôeƒ•Ï×»‘Í›Öí€U¦ŽÖ +š~ã\¹ŸåcåˆÜ7ME+€a{·#¤5€×kâ¤Zë>¦=‰ÒwÇnÅÓùmOT8åꈷy‡ŽºŒü™ê°*"ÖKH,£][‡@î7ŽÈEÝ=Ãq‘Zôa›—5ðиßïj·¤å©²=#-DZ q;2.ááȈ3t€Ò-Ae³OM×Ç‚ª–·•²ò˶¬Ë1ïú]Ñ7^x ï;7á l>Tœ .ݲ1Û÷ ö¤äîµÛ4 ŠnùQŒ––auÛÑÒ£[(…_nVô-û°½„ kþ ,d`…â|Oáþöè¢gZ¥h«ìÁ| ƒ›ýwß·ûýGðùg¸›ÝËv=´ C‡BDúnŠ'¶`WàG«}½À˜(ªá<¸ÍzÂà +³‰1éï\³\«XûXÌΚeyn@Çœ¥iJÿ¦ê7Í~½™8Jè8•ºvµ2eàÁÀUJÎkŒñª:àÌ›{Iôç²ßmÑl·`ý¤*kGkëýÖÕ}‡Wg$\.qU×צè‰æE¿Ûf ü=ãšR7€ÕB¹»ýB(bŠ%%}r¡h©ëCŽ8†(ÎŽ™JVÎç;C´Gˆ½ »=(½;Ф DïÀxÆØ$õÔ$ä½ ··¨X7$̉ˆnw˜‘ßêùóÆÕ4Âtò²È§9Âêp‘ÉfÚ«Lfc@¤OØð]—O®Fõšÿ³®ÊïŽè®ØU¥˜`úEÑÁiJÙMZ3{{÷ž8ò€ºm!øA÷âxR³šŒ x‰¡¾X—Lj¢7ƒw6ÏdµDãÓ*züÛ}Õ—måN£»GòcX,»nïB”Ÿø…âÀ.7€Á ³áÆN‚lF)A‘ïK¥B1”phµ$Š?(¾°© J׺E‰N¸ y,{*Œ›TCV|i@ÉsïyÍ€^5繬ª XŠ2 —Ô«‚QÕ%jUvä–¨e=á‹Â&¤ˆêk×/^à ª©žb*Ëàá$@º‘¿/šz5!÷¸Ñ‘82ÿ¿(Fd ¿éɵ1&ŒÎH>ÀŽc\|a“ŽIëë ³É®Z_Èll}@ ^ñ}Ûßè!0\E᥮þ#:ötM0!ßmzì)¢¡,<ƒyfÇ–ò}“ÍBà§ðëºÐ Õ;(P;ØZêG¨;ZZºUÖÑ: +7Ñ[¤ʘÐ×ìbyíòTSþ*¤Ñ›þüïŸ?}øÏkx»Åb¦˜Í¬ü:5¿ßDU)ÇŸªŸ µƒ8Èa€\Ô¢7…r$sÍ´gõȇ½á'®ƒ“¶…ü¹ŒYÍu\¼œcN‘‚³N¦{ß`Bɺ½£/uµ0x÷‘¾ô{ƒo™1§tDm ¦«¢¥I¨í0ê¯ÂõMK`•{rÑè•ý!`zfó%5YH§Î-œ1ñ³¼eL–ÅBç£ëMÓÙ+5´‚çžy1W±»M—ª¢T£ªÊ!Å¢´¼:Ë/ ðw¿F“™C]ôª^®×"‡¤aÉ~\”,†Ïpî‰4êHi0Fë)šP´ƒ4ʧۻ˜@`eè¡¡„*œžõÐÈøîcäw H¨©Ômá/„íàÍ]tì¦}²÷/açïðãó˜áϲ“íÀ’yèÙÑo#\Ó/U€:q~ÜðïËóþ Ðažƒendstream +endobj +1849 0 obj << +/Type /Page +/Contents 1850 0 R +/Resources 1848 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1857 0 R +>> endobj +1851 0 obj << +/D [1849 0 R /XYZ 85.0394 794.5015 null] +>> endobj +638 0 obj << +/D [1849 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1852 0 obj << +/D [1849 0 R /XYZ 85.0394 573.0107 null] +>> endobj +642 0 obj << +/D [1849 0 R /XYZ 85.0394 573.0107 null] +>> endobj +1853 0 obj << +/D [1849 0 R /XYZ 85.0394 538.4209 null] +>> endobj +1854 0 obj << +/D [1849 0 R /XYZ 85.0394 504.6118 null] +>> endobj +1855 0 obj << +/D [1849 0 R /XYZ 85.0394 432.7569 null] +>> endobj +1856 0 obj << +/D [1849 0 R /XYZ 85.0394 303.3232 null] +>> endobj +1848 0 obj << +/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1860 0 obj << +/Length 3824 +/Filter /FlateDecode +>> +stream +xÚÍZÝoã6Ï_ õk•)‘ê}à²ÝMÑM÷6)®EÛÙVbamÉkÉ›¦ýÍp†´$KÉ÷rÑCŠçã7CÉsòßžéDE‰VÊS6g×gÿvzÝ«£"ŠUH –çRFY’Ä=$Y”ªX9\_¾{ÿÃkÚ×O×°)ܼ©:²çÐcS÷Ênvå2ßвú\/ó¶¬+ú]ßò<²3ˆ$¦nžUy7²˜4‘V:á1›ºþØД›òcñ-½ »³Î¥Ô‘N@vsiaÿ± ³ÏS8¹5Åþs±§U¾-¨ì#ËÏ“(3&õsÑŽï×ð¾´3Z¿wâ22R¦çišÂ ‰©¢Aóî(w@ÚŽ¨h…K3óƒe³8J«_Ö:]¶·ãÌD‰ÊLÙ…nAJkWl2’ê==/ßSO¾Z‘p~Î~ê]Hmk¢}:û‡gRʘšÊ²ÙÍÚ¯¾Ì+»à÷Ýo·ög=±zÉCVuÛ«9JNU Ôo¨!ŲÜ:¶jVÕ­W_øE{T¼žÂõR¦ô×S¼žš-ëM]ÍWŦܖ°pVØ™Ùì?ë‚G“l Ñv»M ã*&݃QÆD63’MᨠƒT6J­ÎxXîØã}k™F‰ û&¯wwØUËvËÆ•Óc]7-žÖóQë562{Úz•g™%Uo>¼N»ÎyeV +hÁáÊÙmMƒ‰ät¢¬î¦_bií´F‚JÜòzD”1¸<ÇñˆR%`”O‹2î‹R[%¿ßÛzÏÉÝ¡Éï8iX‹ÃÝlÃ3§¢TªA@©„S-%4àÈjÞ´°ÉÜ'(ØÉûQõöDEŸ‰OgWÐçb¦Hø<)BµSþ^É(QÖom¾ß}–h¼QXYÃf‹ÕX€`¢D7Œ~5²8¶à6ãÌí÷œtö¬)U;U°¹ÒYd;0„IE‹í +´Ý^Q«t0Q%ÕFjÕ´àé‡3zœbÖÙ;5ìzuuM Ú +¶üV° ñ‹öÇP/À"j{d0„O7¯Zó¼+{MÞT?~Yeaí£æ¢(X¿Áõ¡ë¹;³·NZìj!Õ Ne…Ñ´êe§jír’ ö“\\a«PÓÇ Ødáçz<  +'C–Ê—Þ–ãQÀ ±d2ªŠTzëp6ÓÖVy°‡E *Ûb‹q’àÓöyÕàþ±HêÊ¿£;41ƪà£Òÿß-¦ìã0 ©Ìöõ0¤J¢»ñ¿‚œ”‘ž×y;…MOs>#|Îg¤ªâˆ¯C)ÈñqP穼ù:" +˜ù²¥¸œÏµ$ãK@Wvÿ‘£ûuIAxŒU]Á¯•<õ‹Ë«Wì,øôˆŠ V¤T‹ä ­:–TJÆíMÑd?R¥7ÀH¸9)ÿ¸Ýÿãj $X%I:ÆÞ¬C‚2 Y,*îŠèʱEÈ“›ÖO¶\çÕ]ÑøŒÊç9”—ujô&&é­ê¢(pU ªÍYK/¢|Â7sÝ8Í×%¯¼˜®JßçÍÄ¥$êþ(Æ$Ê—¹^ ¤ô)ˆ9ñº[H)¼Ï›·_¥“!4„,Ó»[íw¬îVïV¦Ü-`B@D9N$p§îV¢`æÃ3ÔÌÛÆ~®j~f=”ÍúÈß 2ꌧXHÏÀBçBæ­Ýíkv˹ϧ\ºp>xÿ…á”üê©Ô\1Gò6ßíÈËÈÞ•¬Óh Q€ÖŽg&_ÎýM#ŽhÊ-8×PV“ì̤špé`%Ý›Äq—Ž8$Mž®¥TãnUtÜ߈c•·äÝ8_ ì;DE%5‘EZªAU³_ 5|] O¾?ÞC°ð·ÕÏéjÝ¡Y çôÆé· ã¦w +.ÜXÛmP”>–Å7Äò¼d¸Msá”`bÈÏ‚rÅ9€î^½aB±!ìY-ÿ’mÆ‹È&ák–GŠ{±4ªsá:ÂäßY*Ÿ¼‰ñ;Óë‘&AµI ¶õôM€×åüÐÖ[P€e¾q÷³(PºaÁç$íp'$Jy\×ÖM$L÷âû:‘¹xF¬ +£L¨¸Â›2Ž¤Šà˜ÊjŽŠåû]>ê|“(ÑÆô®³av½Ò»^q¬$C“¡Ç|qYðw)Ð÷þæ Wr–ÇëçbÙ–Ÿ‹ÿx…f&@Ã2Ô \ÙZ6Ýmž _•˜¡ áÁKa¸t…'z ù²ªr±ØðPý–‰¿¬>åý¿È¦endstream +endobj +1859 0 obj << +/Type /Page +/Contents 1860 0 R +/Resources 1858 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1857 0 R +>> endobj +1861 0 obj << +/D [1859 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1862 0 obj << +/D [1859 0 R /XYZ 56.6929 752.1413 null] +>> endobj +1863 0 obj << +/D [1859 0 R /XYZ 56.6929 501.191 null] +>> endobj +1858 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F53 1017 0 R /F11 1367 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1866 0 obj << +/Length 2981 +/Filter /FlateDecode +>> +stream +xÚ­Zmsã¶þî_¡o•' ’èL>øΗŒ;éʼn}Ót.þ@‹”űD:"eWÿ¾»X|IwÚÎÍœ@`‰]’-k¯?Ë›ü°/Jûèð€—j€ÏìíL\Pž®´¬ßÈy°å“1p¬Ê&Ͼ·§¼[V0ÇÁRº«­ï€F±Ï«c3x“€h̲à±np@žŠ¼¼M:Û¥±ésJ[·¬I|0Ânã: ˜N·qp0òh¥Sz„sÿVåvû‰³ù:Ï&ÞxÙíäuñdÕal9ÀÀ‡ ‰絿;¸Žcç0:B­xÒµ°&mDnYÄû,BCm°< É>a &£F-ï-7™„£€ëdÊ`ì #'¡½„Ø&t¹#©$5Z$Δ՘¯àÞBçÞL´¹Ëü ¶™ÞêÛò´$ß½†¯Æ +c §‘]×/HDëágp YÆqÞÇ%­i?µåkº;¢Ë\ðÏ;%ìÜÏ9uS&ƒ ÇkÇÓq€YÀ©c„ùDÛôuøâ¦:ìÇÈã N´K ¾£ud?ÛFàLD%QèC€SLzéœØûW²Ì[Ÿ‹Ç’¶þ¯g©2 ˜‚4\É8C%£¹½Zu¥Lf+“‘ÌÖK™U~+«‡fý2TÌP9bïhöRçªÌ‹á`ðî¯x¬þ[†[.!ªêŒåZ÷ŸniÌæÕÐe ¥ÔßÁTÌôS*l1mw²|“BL!™ÇQà9Æ'ôZ(b(Gj©ñõúÖR ×jp¢å.¯ÝΕô{õû¿YŸl}÷ïq>ÓjlÝ/ Ô­W/ìT.p@sÖÖ‹§ôcà0#UYRTéOL¹Þ˜„²ŽEïШ#5C#'åiôº>c&0I¨æ{©sÍq`ää=ÕÄ"éYÄ,‹¤g‘ô,bŽE’÷XÄ‹d—E +ªŽû-q6`¦4®ÒˆÊ&ýµëmU/ÿ” >í´aHâAÈ´+ñ +ë4eÈÅ…êS¯“áÙ@¾q|{L×Ïoi¸ Iö/P=»¢9]rÎÑM Îèp Äa(_×ø¿Ë C¨3¡âÐÓ·0jÖÇ¢Á±I¾ĮE¨çùÖ•šæ›—òhBô¨ùç b&óʽԹöAù­ Ñ—¼¯þ5»¬–—Pe•®ö„¢™3#Ob:lÎð>ß$ç <œþ4£qŠ²ÄÌÆ_Fe¬‘AóPã.âÀÇu[‡n„;Ñ™ ’:K)$a2 Ã~!˜f挎3.DBR'Ãæ·´#5³¥NÊliVíÓ¢üóiW^÷ö&Ï[à¥ÎMèï+ØAðî™p‡ ˆ\ª:'xЋÓÚ‰Tô ~¸Iq³ûïÁæíl›Ö5â!Bɨ–®ˆì.|`-DÍ$dq{!4£«˜¿ØmõK¾ö™·°V¥#ÅåJ@Mª åé'%][ûÕtÈHGþÊĦªMa²«ˆÔJ‚ ®Tÿ7뇼®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šæéÓ‡Gi 1ÚÊÝË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¸þrw÷ùµ_Ó]‘¥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%ñ¯<’‰*˜ „ÐÜ…0q¦†¦û?A:·ýßh @endstream +endobj +1865 0 obj << +/Type /Page +/Contents 1866 0 R +/Resources 1864 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1857 0 R +>> endobj +1867 0 obj << +/D [1865 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1868 0 obj << +/D [1865 0 R /XYZ 85.0394 674.4719 null] +>> endobj +1864 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F48 940 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1871 0 obj << +/Length 2837 +/Filter /FlateDecode +>> +stream +xÚ¥Z[oܺ~÷¯ØGITÞ%èC‚¤9hOÝ-øA^Ѷ­´Yic8¿¾Ã«HÝö´Å>ˆ"GœáÌ7’‹w~xÇE* +R첂¥a¾Û®ÐîÆ~¹Â–æ#zR½»½úÓ_i¶+ÒB±»}æÊS”çxw[}IÞ¥8½†Pòþã/×oˆàˆ$oon>üöþã¿á# „’¿¿ýíóÛ¿™¾›ëÈ~ùðéúîö׫·^˜P`Œ¨’äûÕ—;´«@î_¯PJ‹œïžá¥¸(ÈîpÅ8M9£Ôõ4WŸ®þé' Fõ§K +`6òú Íq2<éIz9 ×8©ÛGóÞ=D8ùý½y~E®qžèEÔ]kè+Ùצ» +lhïëÁ4êvÂîûYž^®1Æ €"C,¹}ªûéG¶D3Ý¿(•iäˆg  œ–¨VVɇòÜ ¯“äù©Þ?ÄŠ"9ȲíÕ‡  (Ð+2Î@«úóúÑÒDJÌÒ‚ˆÂÒ´ÝéP6Í‹™·—m¥$Dúø!ͨZ`-{X€*ù=PЫ•)¢ò€ýëØbT¤˜d|·9MgŒräá8Øi‡Î<¿"DÚÊ "MùÔê0ùÃvµåA:N?äÉNó`ñ߬æýã­¶îØégå¨ÊÁŒÊRG†ˆ±Yš*u´åE Ñ 円ZÚ:~)Ió<£ðPmà×Qyüz/ŒÀ Á‚‰<ßæí©æÌcœ2(bîQþ(Àú ˆÉ…09£pp‚F%ùXZhÁ±žÌȃ¶Mwˆ>Ær]7˜n ½"„^á ÔžÏHh¤ñΗsÄc+:X)䞪 ÁT- +@ãâ]0ƒ±î½±½&Óè‰wç<ÐE0…lõ KžLQ– ¹ìÉ>ÊoÒ:`=È“wÓÜå»t¡Fà8^»ö|B­{ô]£¿%ÌêF¬¡e=Qz•A·QEÉÇÁ >×P44yy蚦{™<ÈÓ©lz;<Ú<ÓÀæ@d-­Ò8ƒÔÿÔ={A\¤ñŽi*OÈîÏÎwG§C+ôï1<—ý˜‰ì`†«£Èë•:”Vüž ‘f$Û~R­û½§ò~¿?T3¯GP«cz³§š³ŽáÙ…lÂ{ôz¥0aCMŽ§ºLІn‚au_=(„”yßw‡ƒl78™¬;dz¬€®~xñs{*Q,ÇÇÙ)R¥þviÇ3ìhTjÑ®ÃZÙ¤´ô¶_+kFH=•0÷ÒiåñØÔªÔGE¶ÐUý£2¸- á©êÐxo™ùˆ³:IŽ.$›jtŽÊƒœð4¬&›MÞc²™1_N6÷ãÍ? V“VÝRížLqþŒ%^½2ÒY¬]çÞZËÇãHÝF r÷c éç°j ¦¶«y†·-R­[ÂSyK8§X-[7ÙeëŒÿrÙ ðéI‡vpÀ/:ÿ‚óUéhuð†®ïLŸ ïÐøxcÆʪ²Aµ7ºšS#G/3Ñùp/On‚ÒÍz6MÌœ½ÌŽ0K³œ.n“(gkÛ$žr&üÎÆÃ|º³m»=’«ÔaZãáis< Pœ||0½f>ÝT1-#´ýÎï†Ô‹iC„éU.À†×b“r:‚9dkÔ®–×-ä,-hÆãôØk»EHﻳæ¶wÈMc\Á cÕr¦Ñ±ïa:ábz=Žî[-ûšvÛ5O½9½HCª OrTc"5±·_÷¤-ö'Mù¯xR(@XCGZ·5’£,ÑÔ­ìãå¿6Ùó ƒN!ëö€Ê@ˆ_°G@µaG5æØrö«9f“÷˜cfÌ—sLÄݦcšûäMçäª=øºG½hµB#¨{ýƒyªUÔýPïû?«Ó¦BT?íä〓)A¡q(+ùZmFñH××?¥g°¾§ñ0N|l^&^Ü[swí&:î%T/µÛæþ‘”ÔCãÒWDE–2F.äÆjAžÊ#èûiÊ·ÈSN/°µ4s®“ª˜Bõ [àˆíͨ‘/•Õ’ŽÉ^]wëúr[zâš=8¡µÒ»¸ú{½>™û8æ¾qºFi–b¨ò·-1mÂvPLyÏZdÝâ=Ö)óå¸rwæPŠ6‡«Lü>E™Cq'áEÕo½Ü/f'Cuh(µ®¡i_ažÒÒúÂÚÚÂm‡ó©5…?+´Ó­+ÿu¹¯a³_¶Ê(´¯‚@™W t!Ó†TëpðTc™ßup$A·™{ª9÷Ih·$°m‹Ø¿ÓéÜCm¶½ÛØDZu ¹œ[{‹ñÇÓn”çë Ö +”]H¹!Õ†aÕh{Ö;ßM0”Ò¬ÀÛü=Õ\€Ø6PfSX,ÁhælÃœmXdæOŠQ2Š¬_GóИ‡ó°%ó Ìš‡…æaÖ<Ìš‡E§ËÛæ`E1»°ë©6Ìã¨FóTU­VW6sûu×’m à©æÄöI)Íc ógáÌ#"ódÎ<" DÖï£}˜°öÆ>bÉ>…³í#¬}„µOæí£ƒ©(Ҍ擊hÃh¸ )b]@´n2G4Z¬iVç¶ØŽgsS¾ËGs!ãOÒÆW¶íYÚ¦’go¾"DËÇõ* uF.\¼…T*rTæê°>È¿Ü®Ti›l]•6ãº\¥ElAC?.ï«ey§ÏáÝ\í@£4—íi·t% +®’ñÌÜß.ä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Ùÿn þ¥endstream +endobj +1870 0 obj << +/Type /Page +/Contents 1871 0 R +/Resources 1869 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1857 0 R +>> endobj +1872 0 obj << +/D [1870 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1869 0 obj << +/Font << /F37 791 0 R /F48 940 0 R /F23 726 0 R /F21 702 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1875 0 obj << +/Length 3266 +/Filter /FlateDecode +>> +stream +xÚ­ZÝsÛ6÷_¡™¾ÐÓŠÁ'?òàÔnÎmš¤µÓ»›¶”HÙœR¤*’NÝ¿þv±DŠ”Üi/™„¸À.¿]ì.Å þòE¢C&SµˆSjÆõb½½`‹x÷ö‚[š¥#Z©ÞÜ_¼úFÆ‹4L#-î7ƒµ’% _Üç?W?Þ¼¿¾ýÏåRh¼ /—š±àû«÷Ÿ®ÞÑØÇËTWooî i&€ˆ#YÄ‚ëÛ·—¿Þ{qsï… +Ì™DI~¿øùW¶ÈAîo/X(ÓD/>C‡…ýqà z#ƦÝôu^äsn ß‘a8ÛÏ›Ï֦᣹»} z gc¹p:`aï|AfWø“nœ†zÖ!Akõ­µÇŒxêÔú½/öÏv!;qeiÉ­ž²5ŽWb¤_°µÕ[sTÆÖŠ¼n_114…C}ž±§šr> +_пÉdÌú QnŒ6gl‰×U€µeSÛ÷ =½sãè+w^engú£Kh/&´¶ €ÑwÖHÏÊBÁ œÿiÿ¿ó?¾tjºàà˺Á#›q àõ¤%ݺ‚û¨=ºéHÛÂD‰6Z h7zˆ:Ž@šHžâê4=•Ù×Ïuóë‚°²*ëb‚Ç( cð­çù{ª©c<Æ °(Kðq_bÜ£Dbõ´nÌ3oi°*+¨eô‰»W؈ç'`ø€ÏŒ ÚUÓÚ™f§K³UÓ‡èd›YîJaë±ßfõ’PÌ;rßÄ7˳U… 1Áðã7¼âHÓ¥€ã>ÄÅ:Vbû;»u*²õ# Ž÷DchŽH•Q/6b,Ü ¢J¦~ÙM¶†ÓĘH¶°¶=ÜcG½°Zdtù ã.14P„â˺(èaÆx*© \+»þ´sÕ`Ð $7/`z@uÓŽÊcz“•Õ4;„ÐQÆÑyÖžjÊû(Ž‘ï¤cÞט$)HEšŽ:©,zÍ«âû®-öO&oT6m€çsÓ½ÅAa¢L|“ÑãîæÇK­ƒŸ¾¹ŒUpuû.¤á{·ü!©‚EL&¥lî6#–Kž€ÔˆE! ì+–Ç=‰jîÜÇÁj"ßyW‡î¬ƒªFK³®ºíúÕ£b·øª€,¹ôÃîNBGANÅ‹ÏCgHu:žÊCgU@.²×ÐMkÌä xª©GÖb{=᪃Äu‡ÁpDžBDàFÊvWeÏvÐ(HtètˆÆhFm¸ÜRÏVÄw2Re:¿"7ø± _xü`§l­„]&zŒ w•P™0ÏK ÏÀÞÉu ùi{úHeŠˆ½j ©Î©£òG +Ww[¬'Ç©d""9ÏÜSM¹š8V|ÌþÇ‚ψCÖ þÝÍ×Ôž\^œÒjólM1ÀŒ<»+aÇ@àxÁßÙ¥ú ÓìúüÏ©7#O£Ãìïçd¡3WÜZrT»™dñYž—„.Þ¶1áhêé2Ä(ä?™ÂE“0qCªÓ@ðTmù°~ÌÚ™HG„1¬q–»#šr²ÉX¤rÌþkÃv) ¾p‡&æ¯uÖõÞ4O°.‚v —7âÇVZzW¯i˜V`!n»++ch>ŒÁÖòz¦ ¬ªTªÑN_* ‹0M’d¾ ¼ô+¾ §´b¬–»Û·_ÿëêîæ4@éÂï<Tgðਠº}E§åoÅóë/àÏIÔ‰Èo'£GÆçÊÎì[GcP1S•*Ô©/¦}94#ù±”Ÿ&‡òÔRÀ²7&lE€éïnþëJžp,I*ç‚æC`k. ØÆ8s®£ì\À•0Ò } 1Z”&fá[ô2© nø·Ö+5Ÿ dS¬IË—Y—ù¹’gTMó1ØÌ–u i¹ÏMÅo±þÍq"Ô,v³ÀSΖª(Næ—WMbÜ'¯Æi§®´ò¯ÉßØG‚ÇpIÌWí¯vWõl†üp©¿íÞÊL|ðÀ[iæ¼´f½•ˆÑ•ªt!ÊøO½•_q9\rj®\KÌe|àü—¼•èó„½ðÅkHuÚ[y*{uÍΔÒ&qL‘Sç¹{ª)û£ë‹‡±æñ˜ÿ¿˜Kajû™Íyz¸ÊàÅñUÆÝUFí]±Ç€:M‡ -mq›R™g)„NÓc8Ák®›AÒÅt<ÆìßÃÇJœ´Ð x•þsŒ¹—Ã%g0†f­„>pþk1H”¾8©Î`ÌQyŒáG½“‰óYÖ‡ÄyÂ{6qñ¾­×UŸ» ²>.™¯ž6À> endobj +1876 0 obj << +/D [1874 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1877 0 obj << +/D [1874 0 R /XYZ 85.0394 179.5067 null] +>> endobj +1873 0 obj << +/Font << /F37 791 0 R /F48 940 0 R /F23 726 0 R /F53 1017 0 R /F41 925 0 R /F21 702 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1880 0 obj << +/Length 1912 +/Filter /FlateDecode +>> +stream +xÚ¥X[sÛº~ׯÐCgJ͉`Üx;oJlçøLŽãFÊ´Ç4 YœP„BRVÔNÿ{X¦$jt:=X@‹Ýodc +?6öÄ<‡±$>eþ8]èøæ>Ž˜[3mMû«Þ/FW·"Ç$x0^,{º"B£ˆÙ£÷žp2 Ôûíó|1™r?àÔ›=<ÜÜ_ßýÃŒ)¬”zÌî¿Î>¡ìasoöñf>yZü>ºYtÖô-fTS~ŒŸè8ÃQ"âÈï`@ ‹c>^¤/ˆ/…h%Åh>ú[§°7kÿ:ˆ£„‹€@ÀÅ~LS‚M‘« ¼’ÒÓ¥i}¯Y)¤z½NÊ ¥E^*€BÐÈ›•{\ðRèç¤Àù[U9±Þ4¹.k”£>U?SµipÒhÔ®n%ëÙÆ£˜PÆ}ðÈXõËc©ŸÒu†+½gý@¸…¸ìÁœÉ‰sâÙù _UUåY¦J£k<"&<ˆ¢ñ”1û>·jž÷ØëË´Þ¨4ÿF)OQZ«;zÙ[æD貈QïVW(V?“õ¦P¿xLÁqð1³üe2 Ï~ùQag·Û‘¼N‰®ÜLb`7éOl …ÃáÁb¿UWjPx +ãÑöõJïLÀBéAÏ­ï› yH)ìÆÚS,$A(Ú¦z[d¨ÒÚm­œdYMXäé5Ž0ãÂ~ÆÁÀdœ›×Ø®“ï­de(7,´þ¾ÝÔ¿ü~äÙéìþŸØie6ÖÕ@0à_ QèL7ÐcºHnΊ8Ì–èS$#‘Ì©yæ¡I*!…‡C:Ö +h´éK›RFÖ ©Z,̼Óá1]㈲àÉý¼¿Qªm›Õݧ.$ŒƒØÙûgý2ŒOâv- ˜]Ð>ÿúððùËÄ÷½Å0³s`³0Ä?-Æ/s¹ˆâ6ܘi2ðž' H·tƒm^4xÝîòf…B´Ò]ü2U•‰IÀ¤Èÿ…•Fàezäî¢.“µjïïÀ«·›®šw8²Ñƒ¶»Õ“´-$¯«L²¼ÞÉ¥¥.§.¾ÊÈ?<2³ù‡»;s¼Dg„ ÜQ“¤ª€¬¹„UÐ6¿‰ðrƒŒMUìq»T—ÀýM¦«¤JR'U™ê,/_pd/ƒ Qú¬–˜Œn\«Òþ‰‚SúáaR~b—ÊpNêö^ "ïÚ&;jU½›L_»ÖÁ †0ïEú6ÆC3ìÝéF·=H Üé„»—à}x·Ä‰½Þþ5ÃÅEn/öÎ$h·U‰Ë P»<л43&cÆX÷é¡ÛH»œÁu`Áƒ‹MNj]š›B€wÊr®ªqåpuÊ  + aWš½ +Ná¸Æ~<ö¹$ø¥?'q•è`á?í4Nû*mUx‡S`ÎH†o;¯ïæ³÷Ÿn†ÈÇ'TÊ–¤TùšcØʵ2üj@xM sŸ Sîû¼½<‹¹ÅÓanö†YÈó§ÌI—(u€B`b*©#¶mwB^Ëë£BÛòøÀ}5ãùK +ÙF¬šDÞ¶¬ÏP- HeˆTËã8¶¹½û„ï»Óº½G¯WªI¯*Uëâ•À _¶iÇ0ˆìŠ¿üû·ÏÜü犀U:d=Üx~sƒÞÏ>Í?_ä÷•®ôÌpè;ü£áŠÌ£ž0+ëZ¥Óïjÿ¢ÊÞ¤Ý@Ä}è¨Ád‡Ý—Ûð”õ‡J‚ˆ„~·n\*Á³·kìý×ó‹nAεgßeý£×gH÷új´ÆÎÚ¾‘νÍ:ûÀtØÇ^ÙÝ ä¼› ®m0ÁOx8ûvŽáásϩɸ‹ +nþó{×mEÑÖý¦¿mò"oöçÓ1›ïK½©á|ÑŽ`$Œà1FPQ@å1ðy€‘Ü7—Óð·0šÁ©ìi8å˜îË[ôæ¢yb>N“YQVõb÷úÔŠÒ¡BS˜'l/Ó´HêzðUB,-ÚEÂû…Â'Qà· Xfº9«/Œ~¹¬p»~VƒÏÅ€p.Ù±Ææ¢Æf¿üú!H̨<Ö÷÷‹úvIÞœÕ':}ø ‹‡à­ Â0>N×»´,’—¡]$‘at‚‚ìzëaíbeX <ûnÞ™]™J»£ñS{ûd(M‘ñáÏe<ô ü9h2N2˜Þ~};µý¿p"5endstream +endobj +1879 0 obj << +/Type /Page +/Contents 1880 0 R +/Resources 1878 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1857 0 R +>> endobj +1881 0 obj << +/D [1879 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1882 0 obj << +/D [1879 0 R /XYZ 56.6929 581.7741 null] +>> endobj +1883 0 obj << +/D [1879 0 R /XYZ 56.6929 460.6765 null] +>> endobj +1884 0 obj << +/D [1879 0 R /XYZ 56.6929 366.7195 null] +>> endobj +1885 0 obj << +/D [1879 0 R /XYZ 56.6929 293.4426 null] +>> endobj +646 0 obj << +/D [1879 0 R /XYZ 56.6929 247.3727 null] +>> endobj +1886 0 obj << +/D [1879 0 R /XYZ 56.6929 211.2315 null] +>> endobj +1887 0 obj << +/D [1879 0 R /XYZ 56.6929 172.539 null] +>> endobj +1888 0 obj << +/D [1879 0 R /XYZ 56.6929 96.3402 null] +>> endobj +1878 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1891 0 obj << +/Length 4197 +/Filter /FlateDecode +>> +stream +xÚÍ[[s㸱~÷¯ðÛ‘«F\\xOU¼3³'Yïdìœl*›Z¢,ÖJ¤F¤ìx}ú¢¨ÕlååÌ<j‚@£Ñýõ°¾Vð__»$R6¯³<Ž¥“ëÅöJ]?ûﯴô™ûNóa¯o¯¾ùÎf×y”§&½~\ Ær‘rN_?.ÿ9»ýôéãý‡»Ÿnæ&Q³o£›y¢Ôì‡Ûû¿Ýþ…iŸnr3»ýþãþL v2Ø-U³?þøðxó¯Ç?]}| Ü 9ÖÊ"+_®þù/u½Æÿt¥"›»äú~¨Hç¹¹Þ^ʼn’ØZOÙ\=\ý5 8xKŸNI ±.JœÉ&D`ôµÖQž$æHI¥ÖX’Á‡ï?ß}z¼ûñWCßôbS×s“EF©Œ:¯›¶“^vÐËèÈÆ:cŸª½™ÃJf?Új»Û”Øv³CWmªî_¬š=7våÚÛª~æßiš_»ämr;»ëx?~ ß›ŒvhË%·º†Ÿ‹¦~)÷òQ]lËöøýÝ'ás¹Üßh7+ÛºÀâ`ɼžy,«¨a|“ºÙKµ(¥UîÛ¸³©ý}]ÖL­~4êóa[Ö]Ë$\1=w]ÕÔí° ™Íž«—²~7± }‘Š“X„|n# ìpâwb·¯ÂÔ?Úuƒ"¡æa»-öo*›F™GÆ<Sv‹oöeÛl^"@äÕÿ°Æ4ÖV>ˆØ,¬5‘udŽ^>®Ë‰)¡‡N3/¥y11‡Ž£8Àø³J¸xè!Hɪd¥å—CõRlH9HFGב¯ò‚›`(«Â’æ/92 ³hÁ‰NÕ™H[m.˜²Ž\’ù <÷ÛâÚ'ª´ám'}nïÿq£Ðü¦À˜iœ»cÜf×gµ=#8…„ðD„ñ~J æ™ŽGÂÀ!Éá‰þ}Ê/‚¤•±æ"ªÅ.Ö#T³³@|»ë„ùŸf¶¬ÚݦxëWD‡o¹Áæ½hè¹îØììצ.'`Ì€à@Ž Îyº Ö’ùµ¬h†f+¬zžEÆ`õ +Æ„µ#£·OkâYqèÀÝW]ÑATÁ$>IoÕHfþ¡!À -\ Fºàc×ò5Î_3¬õãÅÇã1z¢»øY)S{†È‹Ð,òFzØo,T\ :†3qé!Ú ]5o.+XÍx ~°¯Á‘<øŽùbZOMœÕÔjBÕý D¸ €¬e¸À7lpH)˜@á-6Ðònôì‘Dá¹Øm;¥BZEn7O>èv¬Cyä\ÀBÜÀÄÀr+áŠ"œæ©ä'ÇÍC†ƒÃÚ˶j–ÂàÞƒIä´ƒï×EÓÖ¥lsGMq‡Í‹rH ŽA4ÄE~ãB˜1ÌcóÝ=?Èïê®ÜÃ̈æ£Íf|ú?‚°rÿÔ´4<ćnwè¸ÍCBä]Öå¾ß–¡ªN„P^$IP‘óÀ›Іƒ$;‡Ž6JÁ_x­[N»ŠD§^ëöSš SÚ$½ào`}âoz  *D¼×²Àók#" ) üX`6ð“â% ¾JóQþC¢›‰³Ùº@42±%$ÙmÇ`÷R-i€ÂÖŒŠÅ/¯E€[|ÉÉ@퉳IvPs« §;®|©šCË£ 6U`m°†wL™Þ›Äà­R{a?b"œ J˜·}­ºÅš—Ë©Åm¦.‚Pæ$È: —ô†UM1 +ûgÕ8ZÇÊR»+F9¡¾D +¾:Ê…‘ -þŸëP˜Ý#å¸Å£K'%.&Ò.cãîSÝÝ?ò_ ¡š–|ÞÇ_¿G‰³Ù±vU’v|þî½v`L¿åŠ½ÿõÙÄÁ +rrû™«¥¿CòFE*f9¿Ÿ¹l–œÄ\±ÅD £šØÇ“@ªÛ'J©HЖMß‚[ ± "ún>É >­EðI‡<ã|oCŽ©q¼N¦jø÷“L ép þŽ·|ÉïŠ'È”EÞ¹öRŸ +*o@ïÇ.Äï È|ðw>£m’ÄÌÐâØáÐ2vPŸ’5 +›-¤ %—Eh¸Éh)8ùììž Áø’p‹Z«ò•áÞ‰¶`«rp@ 2e4q|leø’ÉI³R÷³0îÒtoÆ1RÁ³-y‰‘fïçã)|¶7J†ØÖ§K2ã‚ŽŸã¸¨ê¦Ø®pegK;`þËÒ&ñ9Å°ƒ&|ƒéÉž²›Ùß>`…-ö¾¡ÛWe˱3Cù<6hÑ’ÂÀOÎx ÁfÎk]ÔÏloFtÉÓÑ‹É!â×}%çó„JN¢—S±Y¤MˆÀª&K˜& éCU/«(¾,vݼŠs ÝÆÙÿ¶¨ßø´¤«¶“Ñ„·Î9{±^bœMê%8(Ë~WzT)˜ìKH8­ Ân)†[7Bz.¥!Ï«Ç=°ËØ:ñ7øÝÓ<žã ªN&DàÑNËPw«©BrÒÏô1Îo‚Ã=Ö‘Ñ*êò¹èměү¼”æÝÈôóƒÒÚ1ó@Ꭽw°ÚÛŒðsd3÷M=Ë=@vó"þëËáÓ]1ë-À;Z²”®/•Í™Ø=O£,s^µçû3Úº'ÎÍ|¡”'¨„Þ…ƒqnž„Þyøü ?CÔÍ”Á"}Ne iÑqzâÛ*øS£´Œa”š=¡F¡žòû¤tP_hòÀDâA~æ.\m’/JWè\)öI LŠò0Ù¶,+…0'L)–¤P’W!0.«öߧËàŒ.M@8™;vR÷T[$6ú(ü øž¾b³y™Ìw`™&¶ñ×ä;=ðÏc§ÏÅ€Y¤t@¤s:¦úêiP à•SÜ) K3ºøòyi Ì FŽƒn«mµ™RBã©„˜±"W£ø¸”ä'òä*¨ÊSX(ƒ)OF*J5Ð,Gý`ãÈð(ûÔŒ;ÊV ?(Ž°NÍÊïÐSûo‰ixöªQúdÛã^Ýšj'£KhìÕU$Ú±… ¼î™ë¾ØŒ²‚†ÌYûS¤Éäà[”‰rOw3Î#•¦—7ÓjÙÊ¡pT`s¸G;ì…¯E¤£ö\†˜)P•ÇsJêâ %åÊMF¹<)q +îï½ðTÛËß:æ™Õ)I!Mããm «çµøcq,„‰Fêp¢—Ål…¹Ÿ*ç ŠPŠCaaÝ«àÏ}©;È9‡(O8mÇ÷¬_UP"<‚ïÞÉÁ¨EÎøô5•“b_‚‘*ïíOß}îÏëü©íegR{mT¤mª/ßÎHÃôd-V$QÖ&óÙ4ä&A֟Αd²kö”ÉdæÜé@,”Ãæéÿã5¦>¶1xY*PìPõ+ÿ=[Ä.:vÓbp&=9u’>:'‡#Æ1~"…ÍÛìy ¬"ímWNÅþ:K#•…*(°N^uÉœö(÷Pœä‹SÉ7æÆ×ÇžëêWæð„‰ÿE4ÏfïïoøøŽÉXd$Lâ¢Q,üðã-u4³‡»ï¥õç|þK?õ PÞ@î‡x¢óÉNÚáX1þ(ÙIM(}½lò<Trwêuû˜a[4 íSËSÂ_±“c†Ý¾‚”J„‘Û(NM>­}¸õ´¥ó²òo…4ÈQA:±¸×r“ÓxxÇÍgXG•&× ñÃOÜgTìÄny>{:È°Tqù¹ã +GV÷æþþŒžŸO8ä+0€¹uF{d—[y¤“Þç’6•SÄÔgÖ_ñ˜Ûdb}6‘²ö«V“æ¢ð #¹Xn3}âÍGœ| ãZHc\¥NG÷t€KÏ6_Í^À²é«tžñ)ìñÝÀᵬ©[w`ÐÜ"éÁs"ž¬ +Ķ+öq*º9PÂ_Ÿ@_ÏS™þXØ 0,Q¡:?0y! ÆYÖËpæ¿'_lüùþfÓ¼Ž¿ë+]I 7+ÿá0ÇX¢Œž¥Ê=—tåðmlœ¤™;{Ì5 +SqEZ ?_ ‚+W)°QðCj&Lð“b¹ÚL„¦î•6|Vg1fÊáy-ÓLgN‰‰²4ä8ó¿Ÿ9aqý ËäÁ"ޟʳpPózn˜ôCèÐT`Úÿ&Y”¤yòõ¬`‚åž;êK5øÇ`ð_{Ž5‘w¯L®üz2ªødy ÄÞÓˆcB®Ú‚íÕdwI’O— ÑX8ûªQÇìl#ØDEµš[.~zÛR¿.ªQ¿0ÖÙ0L[Êk¾ßAcø7Ⱦp/—¸¬=[M"[÷[J2c%x¹þÈ]ô.'•( ;ËE:M/c¥1#°ÄÁËZÍŠëØ dÞ2]êƒÛ’«)B >ÿîMU®Ä:£‡NbôЃÁñÐÔ(øxƒX‰|ã¹Ì$šKic7sA¨6NŸKÿf5Q?ƒk¹?!÷(ÊÿiýmÀWÛÃVnÈÒð*•‡aÔ­g?=@rÝõ7/Îü „Å3;õ *üQÂý÷ýŸÄHÑ™þOŽŒ[A˜dsí™B k•YIqÊû'Á endstream +endobj +1890 0 obj << +/Type /Page +/Contents 1891 0 R +/Resources 1889 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1894 0 R +>> endobj +1892 0 obj << +/D [1890 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1893 0 obj << +/D [1890 0 R /XYZ 85.0394 751.6872 null] +>> endobj +1889 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F53 1017 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1897 0 obj << +/Length 1971 +/Filter /FlateDecode +>> +stream +xÚ½XKsÛ8¾ëWè6RÕÁƒ £ËYÍdl¯¥líV&Z„$ÖP¤†¤œñüúmEJ°œ­Tmé@°Ñl4úñáƒÈÃŒy„"Iå8–!â˜ðñz?Âã-Ì}«8¥ ¯õ~5zwËâ±D2¢ÑxµéÙ AÆ«ôËä=bh +ðäæn¹œn–·÷¿ý:ÿÏ4 ±Àr2{x˜ßÝ,þ= (Ç ÚO~›Ý}ž}2²‡©¤“ÙÇùrúuõËh¾ê<ë{O0Óný9úòSØÄ/#Œ˜|ü ^0"RÒñ~r†xȘ“ä£åèŸÁÞlû©7#Ê"ê e¾pp‰"S:«Ò›xw’ž*‹a(Á¾Ö j£2°F8â” +«Rš¬,¦ãbÒ¨>:†O»®£V¯el0ýxûÁXÄ…ÙkÃ8p»Ðóaȱ´@ßR˜Á½i›=+ ˜!íT}v¼Šœ÷m.ÿÇ°mI˜]!¯÷n_ËüíàëÝN«½B’ó%#(IÄõ%’gÉ~ED0Œ!–ƒ%?»;óò³€˜ar~Á†ƒÕPa=™oË +n1{wïäø¤§6É1oήéew×µ—ß²Ù]®Y¤'åQ—*o€Êgáo$ §u%N«M}5×–<%àbIoúKÿ_Rðj€b ºqD®Ç§§ôzxœR‡ë|póƒÓNò®Ûê8óŒÍ¤¨ã5×:¥K߆´ BúŸ™¾oK€²µŽ\ŸLÐb~ +{AÈf†¬ë‰ç$?Úa¹ñ‚>dICß/ÿKÝåð|T‹ý¸kàeXoЕV»E[QIw%†—uâT²®ÇuÖh¢×þ¿…#RÿéêÉîÀô‡ÿÛ=ýƈ Aý5‚žƒ±uJÇ„|Ùö_àKßÿ üî¡Uendstream +endobj +1896 0 obj << +/Type /Page +/Contents 1897 0 R +/Resources 1895 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1894 0 R +>> endobj +1898 0 obj << +/D [1896 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1899 0 obj << +/D [1896 0 R /XYZ 56.6929 684.0716 null] +>> endobj +1900 0 obj << +/D [1896 0 R /XYZ 56.6929 572.8605 null] +>> endobj +1901 0 obj << +/D [1896 0 R /XYZ 56.6929 509.4701 null] +>> endobj +650 0 obj << +/D [1896 0 R /XYZ 56.6929 470.2699 null] +>> endobj +1902 0 obj << +/D [1896 0 R /XYZ 56.6929 433.5878 null] +>> endobj +1903 0 obj << +/D [1896 0 R /XYZ 56.6929 401.47 null] +>> endobj +1904 0 obj << +/D [1896 0 R /XYZ 56.6929 335.1577 null] +>> endobj +1905 0 obj << +/D [1896 0 R /XYZ 56.6929 244.1508 null] +>> endobj +1906 0 obj << +/D [1896 0 R /XYZ 56.6929 168.8052 null] +>> endobj +1895 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F39 885 0 R /F53 1017 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1909 0 obj << +/Length 1658 +/Filter /FlateDecode +>> +stream +xÚ¥X[wÚ8~çWð'±ª»å¾™„´i“4èžîiûà`A}jì,†¤Ù_¿#KœÐ=›óRµÏª}“E¡Âôu“^¨ÃdÓQˆBIdÛäGý\éõ0`„ –eªßÎÄ +죇<™i»,çöZûÌ,~ê!<ØæîI‘,õ),i´“JVC¢‹ÍRµ:Ȫ=EP$v‘–ËÄZ¦µ®¶áÄ›Ý!¶Æë@Aâ ¢8Ô8$Y$„-Þ‹2Ï˧m\ˇuV.øË䧋~¥‹Ê-Ë"¶+ÄæHæ7€^L +)˜¥¯çDCèå”ðBuF̺ª#Ê€ÃlÍò¤ª«H ÃE¯ÂÚ +âj×6AZÀ&z–÷ëýRª£iX½ü†Nõ<Ùäkç\÷âò^‘S{³©ô|“¿gÀ'Àñ0ŽB*Ø‘˜4¤^ Š—ª£’vs›Š„ç¶4[éÙº\=DF`9¿ +Î u€kEFÎÚè®Êò'”–ƒy¹²@yóH(1‚B±@7k±–r¦PD€%¬˜­´Êê…ªeÀBDŠ®óïi).C'™8¥–`[ e¸í„AÍ) ‹¢´¯R+ùôCvU”ë-´¶¶Ýùú% 艞#l*os¨ýöÍä9Š°„&Ã"$”%Ìñ—øúöjÜq, $lpsÃÔL¥IS2¸ßdyj–Ô§1LÞÇp•öéùÄ>¼»³÷óúœåÒ>5{¬ÃU3úR!…¡bÇä¿’å°á¬\¢ŒÙ ¶Ç@!ª(RQ´ËOâƘ#ñV€Ó¤Q2 õ(à +Áà"ö<š©­Ï§r“»å½ö¥_mtú¶ã@à@A[j«S¨¨*= Òj¾*—rH¼j¯¿Ü­Ziãây6v}Xe…£—ª\jàÿíXýÔ¯·šÈ`$¤ØðœEmâl®k½°˜Œãó8ŒC>Rçx+R9Âg”†q¬D)À«»h·uB¶q¸»+°#Ii«€Îâ!©÷ÏqlXz¼”âmŒš¡Ñ+ëþ•c¨ÄÍ>‹ìÑI$.ž”òVLK¿rS¤æ­Sø¨Šl¾çý–Ý_Yµ®Ðq¢˜ŒÇvG|5ùtü”ÝÙ{ÚJmÃÿ”…n¼®õÂèÑH¹fÞ(òE3º¼9·J"']fœ*È;ïNϵŠ™;æuRl’¼«#B+¥»ôèB£€">1î.άF&…êÎ"ÊùÏê¸ÀÑQuÝYÉ'1‰Úiž¾ÿtw> endobj +1910 0 obj << +/D [1908 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1911 0 obj << +/D [1908 0 R /XYZ 85.0394 575.4191 null] +>> endobj +1912 0 obj << +/D [1908 0 R /XYZ 85.0394 427.1073 null] +>> endobj +1913 0 obj << +/D [1908 0 R /XYZ 85.0394 329.3834 null] +>> endobj +1914 0 obj << +/D [1908 0 R /XYZ 85.0394 262.8864 null] +>> endobj +1915 0 obj << +/D [1908 0 R /XYZ 85.0394 196.3893 null] +>> endobj +654 0 obj << +/D [1908 0 R /XYZ 85.0394 155.0304 null] +>> endobj +1916 0 obj << +/D [1908 0 R /XYZ 85.0394 117.4002 null] +>> endobj +1917 0 obj << +/D [1908 0 R /XYZ 85.0394 84.3344 null] +>> endobj +1907 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1920 0 obj << +/Length 2406 +/Filter /FlateDecode +>> +stream +xÚ¥YÝoÛ8Ï_aà^ fù!RÒ½¥MÚdÛ:¹Úv¯ÛÅ–!²ä³äÙ¿~‡RmÚ^ààRä3CÎ'i6 ðc©ˆJy:ˆÓˆHÊä`¶º ƒ%Ì}¾`3r Qõazñþ“ˆ)IWƒé¢G+!4IØ`:ÿ9ü@"r èðz<™Ü|}¹ùãÓ÷ûo_¯>Ü|½1™$jxõðp3¾¾ûýrÄ%…%°€Òá·«ñ«¯8öp™òáÕç›Éå¯éo7ÓN¸þZ²ÿ]üüEsØÇo”ˆ4‘ƒWø „¥)¬.")ˆŒ„p#åÅäâ?ÁÞ¬Y<F ŠN„³c$•’{G"S¢æH&oU½nŠf+‚‘8Qb J¤d,ÄšÁqs ‘‹ÄŒ)«Gˆ±¢JK5¯š&Ÿžó·Å¦^•Ùc^^Ž¨a”iAß®;LÄ$J¢øêÅY¹¬7Eû´B¨Ï͈Ì-rT†¨Å$<±ä}HHH’()-êçh ÄIµ fVfM ÄS’$qjQ¿pŸ?G‹AŸé¢Ì–!z‰â„ïÓ{îzU€òHD”D‘+ê,VWÙ*oßÖy€M“„ÓxŸÍú¬ØëMÝÖ³ºüç4Û³4Èè+ £÷r–^™¿µnt•øôô!Ôw·Oà#KEà—"Æ#½¾™|ü~÷0½»w«v (,K!`1~ÔpQ_vq*¡Îü—yÛ\Ž„dCXf{¯àØkŸrì,‹—¼Ò]nlü’ KüZl.Y2¬WË°™mÞÖmý§Ì æ¯ØZzY5ÇÎã¶(ç; °ó'¥¼ÌË¡Þè] FNpÏæ04c¤ý“J:Ég[ÇHÁ< ³wø•5ØÎsÍ¢ÊçøYTØ~ÿd)Aœ’vE5ß›‹¨€¼P!õUwo´võm “`¾Q”ħ£aå‚ôa4ìP&L¹ 'ûaŠB€Ne(æõ…cœž€O”®CÄób#W„CªñÄ›äe>Ó6Ç£íKwÐb–›lýTÌp¨rª ÉpŠX9|ÉJ°¿­ýª!Ïc „eÅÂ1ÞÎy‹\m›Ù?ZÉêÊuÈðûäêÛµD“Ôž +ß&µJÛˆÎé,Ø´08¹½ÒÆ(D<¼ž\½Ãñ1˜°èO&8ŸÀõ-¶šÃu±Ðv® 9ÇÑÛ¼,WY¥ùê:FàÌ; §¶ÍMFцŠâbúÌúþ2ËšÜ9E“WMÑ‚ç·ŒƒIššeãºÕÈ8² •‚6³G´Ïšº§ö¾¤Û>Î ¶6 ÷©Ž,À=ÍêÕÈß2j(Îóù©mé  ·ÅðÐM(ضõ*k‹YV–o8Ô˜è©{hÉÐ=»`DE¶$ÇÜ?‚*DÄ2:íþ}Ôq÷ïP^•Òwÿ”0.ãý"¥/W*IL•<-—äòüžRˆÔñž`“u>+Œµî™­Øt×8´˜Œú±¹C»ä¢û‡ÉÅå‡/'ÿbÌ…û—b–£_ÓˆR©8£ê„>Êè£ +…cF »R£_7yј)Ñ$=-\‡ +HçGc×Ê}ñ|­¨Äž3tê×*×^¬[ ‡ƒ •Ÿ!CÚfŒ uœVÒÆi˜2§[ +Ò1aqW^ûÕ££¡ÚL…ðc4Í! Œ Ækàúßûñ Žh3À@™ ØR‘Lù‘"njaÀOm9¢‡4!¸û½4ÚŒ\I¨ÛûÉa†´7ãéÝôœÝÉÙ]¨ðëY‘µ¦ o¬»4$çÚìt'ÂŽw Žÿ˜Ü|×›åý#Wh«Úãª:®Š9ä¶É7{üpÂQ¼ŸÞö9펅à Í:ºk³2î|>lžžÉ3Á(ÝK>!—BšÆg*¨>ê¸Ëv(ã²³pÅ“û×3/†*¥xtZ0 +æÇPØ@*b_²»jé§5' —pM/Ç(Cwx—1@â䬮ڬ¨Šj¹· +:ÍS½--ú){É=6]´põ9ØíncUm…2hÔ¬N±,˜o±HÉÖæx¤¦{7¶±ß~ƒEΚø ‰ ðœ6ƒ>ê¸t(c‹`&U‰P{wjÏÀN•œËbyW5 õsÂ|±&¹)†ìåLw|­ÄÌÖºÏ1öÑ»I¼hå¥]eb{¹‹yHÊ7)­õXØp¯—W¦*‚žÃ-«â¯ HX†Ž˜€<”(ßé¿L¾ì²ø—ÜZ“biÍ>`Ô%¼ài13‘H‘8–g’{uÂDʘÈÓ>Ke¼õ K +°ì«?f„­Ígù°)*Wtf¶ +}ª7­ínW«lóæS]éT¯Û¢®š½›-ÆååV—Ù®4«¯ ª›S,wº9`ÔMŸåçJ¦ÌÝÐo$Ýó{Ä€ÃÚÅ((«9š}ßïØÕú¡¥h°TÔ’TØâ[tì;gÝ÷J¸ÂE”f;›åPynNØ1HAV=ÖW?¦·ïÇŸôXïph|0Èì E¸[¦QØy&1¾wkí*gõªoõÊZ½ò$ »!Ý“6D.ò›wÝ:’ÙcQí›?›ma¾jÍá[ÎY›iá…}™Öc†iÀ¤»lº£-탴yeÞ'ì»=jî*!LÐ3@=Ðqcw cë/á˜-¢8Úÿ»Â+[c’ò„Ÿ”Êa¥òo.œ¤4•žX“Dzyþ¸].»¢ÎHEŽýG*$Ñl¤¢Ýüÿýÿéîßâ(_JŽd#K‹•Jï1~¨gûOë¡ìÉŒI2endstream +endobj +1919 0 obj << +/Type /Page +/Contents 1920 0 R +/Resources 1918 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1894 0 R +>> endobj +1921 0 obj << +/D [1919 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1922 0 obj << +/D [1919 0 R /XYZ 56.6929 748.122 null] +>> endobj +1923 0 obj << +/D [1919 0 R /XYZ 56.6929 665.5133 null] +>> endobj +1924 0 obj << +/D [1919 0 R /XYZ 56.6929 579.9397 null] +>> endobj +1918 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F53 1017 0 R /F23 726 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1927 0 obj << +/Length 2100 +/Filter /FlateDecode +>> +stream +xÚ­Y_“Ú8ŸOÁÃ=˜Ú³V²$[~$ÉÌnBr©Û«ÙüuòŸ“éðÛü—»É¼«+:ÁTÉôß»çox° ~¹Ãˆ·ÁwxÁˆ¤i4ØÞ1Ng”º™ânv÷¯–aç«^ê3§q%[Dd@J9zÆà)ŠiDµ1@‹ÉÓHé;ŸŒö ›¼ü&íXà3¼%šÃ¿7²´D¤C¥`X†5Ѳ¬k¹ÿo«}µ-²Yx§ K¹]³¨¶»B6²iÔ‡ÅBÖõêPoCBHðO˜<Èó}·ÏËFÓ¦Af—40·6ãježÍFšÁªÚo ¬'7ÅH°8²BüZÂú)˲Ÿrõç‘:¤äÆÑ l ›ÊÑ샺ÉÊe¶,ÍLuhv‡‹Ì7ym¦Ý3+íûR–Mþ;ÆÑ"kòªtì¬n0UN6C›ZVHǹ1ÏMf'Ö²”û¬‘KtÑ•1E8Ǽ…*íy„u†‚vx)ûüŽIrº)Á ±äú®-Õù¶½“$Æ,îo«ŽÓs†QŒ&öÌÝœ[³Ì¶ò¢©bÁc↩ºT—MÕRÝ4ÕÕ]¦:ÛÖkªÞ¶àó>KaÄ"ð‚©ÊÃVîó…yÑÎ.wæQƒwüWÇcweV¬«}Þl¶— s$HBo¸CuÅÀŽê¶¯íÚ1ðé¶~w·½(4B4ñMo<ƒÜ»hçØaÁªª‰0I¡C€-P…[NÿR'€Ejs™ÁjÍw~‰ƒÕ\ßáx +¤Ú¼dµƒ‰I`Ü#vÚ&ÖåÒÌÐC>ØærE’\€m½D!5 tÄXª•Ao9ú¢ïÍËÓ³Ø^ +çíŠËK¾—9IC.I ʾ‚=Ò—GÉ qìúžkx(–µª_ÔtZu «^^!êòêPÛurq6of• èº*UìÒ˜ÂÁäõ‘£eYI;[V1\r' =Ãm²WÙ-9Šn‚Èl=´“ûm^×"ŽpÕ©_Á¼4ôkŽ³‰=ˆÑÇÙç›EêÕ`åB›ŠT¥„ùXçëR9Qç³fKÓnd$p~©C…wSU4Ó$HÍc´Üæe0•5‡aêI®¤Ñ³\H3õ)+™VI ¸Ê#wè>‰pû?½¿7#NS?F!1ûûìãÿv&–(C a¤ï Sê³ A >OM×!F_矟nzÂ#d“})m%<{«!Š-ŒÞƒ·Wû&?l›2DU3`Ø°ñÔ’ÐBwˆ1îû–Ê>"®I§ì.È8‹ù¹‡ÚlE‰™®ó$ýÛâ½­¨šª*~ nÞÊjWC,ŸÔ;14 òKSu†ÄWãõV`†]ç¥+ÔZ*ö1˜5´Õ'ï9&(&Â%#ö-׺>.|ñqƒ¾¶96¯ó?}˜Í$"ìèÂò"+aITyÓ¼í|¼ £ORáÄzf…»XY]û2IŠ„p;~3F{e;Zy8Cù™ð¶¨YÙÚÇšu0Ž³‰aHm„“\×7å·~ +xè±Tm{Oˆ\sw ±‡2®Ú.å«_ø·Ö2­o2…ü Ë5”·\­åÙxx†T©o*ºîŃßïúgÒ2~½)l!_eñƒîW‘î°Hy‚YŠÆ“ÙýÓã—ùã穧=¹’À=`§ˆGiÔw9ÓbÙfdoJDQ…®gªüÑYºýî*xËìò¥TÅOiÚ5¨yš¼ ÈIÜ®(—'ß Ý1u×Cyðؘ)UâêàrÒ÷2+êªMÓ&€úäÞçPÛo®ÃÂÁ|öøáØ·)V¾\g‹c˜AÁ“5VíºUîz¨§.¶êb§Öe”jŸõÏÎÚz›/DŠ"JèõœÒ!rW›ç)Åi”véƒ÷ÒJDÊ}Ù£×û³ÅQr]´–è\¶^bÐ(!xO¸™, QVfÌvo0XìßvMµÞg»î)aªs)ý‰Ð=|àÁ+Ô$8Ø·jå P@ì”ÆÄŸ+û½F ²µ¨³=ÔÙþÅJ¦[+=X™ Ÿf£Ocn›j( D”Ò¾÷*¯*åUæžVûªÐKg#íj) Ƴ‘¾ÇeÁâ‘ö?ê)GÁƒñƒy*Öã|¥ÜVw7föAÅ6+Ãr·ãçÑ}â»4-'q]š °éÁ]•fG0€†+s$ª-ë¼É_/ß|ª+{Ïà6Fþç_Ž÷]1¨è\ìõ¯’0°4%N(¥1!ôTôö7„sÙÿ(l7wendstream +endobj +1926 0 obj << +/Type /Page +/Contents 1927 0 R +/Resources 1925 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1894 0 R +>> endobj +1928 0 obj << +/D [1926 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1929 0 obj << +/D [1926 0 R /XYZ 85.0394 752.0811 null] +>> endobj +1930 0 obj << +/D [1926 0 R /XYZ 85.0394 529.0618 null] +>> endobj +1931 0 obj << +/D [1926 0 R /XYZ 85.0394 453.6936 null] +>> endobj +658 0 obj << +/D [1926 0 R /XYZ 85.0394 414.4777 null] +>> endobj +1932 0 obj << +/D [1926 0 R /XYZ 85.0394 377.7886 null] +>> endobj +1933 0 obj << +/D [1926 0 R /XYZ 85.0394 345.6639 null] +>> endobj +1934 0 obj << +/D [1926 0 R /XYZ 85.0394 279.329 null] +>> endobj +1935 0 obj << +/D [1926 0 R /XYZ 85.0394 194.9705 null] +>> endobj +1936 0 obj << +/D [1926 0 R /XYZ 85.0394 119.6023 null] +>> endobj +1925 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R /F39 885 0 R /F53 1017 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1939 0 obj << +/Length 2835 +/Filter /FlateDecode +>> +stream +xÚ¥Z_sã6ϧð£3³VHJ”ÄÞSº›Ý¤’½Ú¹^ÛÅ–ÍÊ’kÉIÓO J¤-Ë7;;¤È@€Ÿ0øÇ'2b%Ô$QQ —“åöŠM60÷åŠffA3õýâêæs˜LT bOk‡V°4å“Åê÷é÷ ®›~zœÏï>Î~¼ûíËÝãõŒ«TªéíׯwŸþs=’ ŒM¾}üõö'ûz­ÄôöËÝüúÏÅWw‹N,WtÎB-Ó_W¿ÿÉ&+ØÁW,Ãä >XÀ•“íU$Ã@FahGÊ«ùÕ¿;‚άY:¨ +ÎÆb@"tt‘ò@*%'‰TA”ÖÅcÝæ°©DMùw׳0VÓö%kqd]ﱃjú)›þ2¿ßßrœ)l3l¶YµÊÚzÿŽÐ¶&ÔvWæÛ¼"ºY¹©÷Eû²5“),">ó[‡,Ø_ótš/ëíLk¶;ã`÷Jïjö¬YÞ|–ÒA‚BS%ÁÀ ä[þÞÿäÇ¢q0±(äá¸lj@¸Ðc)ƒˆ‹Ä—n¾Ë—¨Fä ªÜèMwªÃö9ßc¿^cû\´+*Ýòi{ͧ¸‚ëmÐáÎ"&a)-_êb™û”4ÖtÌÆMo•ïÀ´ˆ~mé["ùË™…aò[ÓÄÍc˜Qhüí¹Á¦w!eø7ØÛš{ϹmÛ·<¯ðCr´>è¥u¿OÅZ{Ñ$NÞçe F?ÈnÀ­ óH9ÌრÍ)J‰9ŒDLÅDæZ7èÁ0Fl`íÊ Œ»‚N§œ‰¨'ìMê¶ùßÙ’Ène[@€Ú‹>dírq ù1I);ÝKÒ½tuüÈïQjiΓt‹/x²ƒñd‹2ž\]ôä*ÛæíûnÀ•ã b©®C Hç¹2̆Š _<Ï•EœR„NýViOúžÑÂáàÚCñ€+÷Æ=XO½få¡_f”¹ê< x§ª…#Ñ%+ZuÑùÙ\eLÑ€ëŸïpä&Þ‹ð‘Q`II¸»=ÓÃKS»š˜þSWÆ12™!MòŽ€A_\ÿÿ€¨û§ùa†´w‹‡Åo8ÛËÙݬiêe‘µù +¿ß`;Épà¥Æ(Ó‰ÐóöÙ¯ó»_ôf…»sä + r¸Æט[$Äý?œ°Ÿ÷.§^-‚49v 4ÄSüXfRTM^ & Mѯ¹ Wù:ƒèA1À¤+ÐÒiCom“ +û›lîúº:ëø =})Œû½:ïöd¼~9äõ:ùƒ”ÍxYÂIK¥b !¢Q©,æT*Ïݯ ÃvÅz¨V÷´æD¢Ð榗c´§;¢ËçL»ÂÉe]µYQÕæhtš—úPú%{Í=œ˜6]´±µô ³tú°Æ±ª&¡ -c&tÎqß@e¨OÓ}xôÓH¼âÏ“AÊô‚8¨°(c'®6¥x:ÎÒ‚XºçC7\Æcù°öíÞ”¹ ±Åç¦Ojðb5áûC§+ZƒM‰n»¡ÑüïȪ=«Î(1æ–Œ«ÓEWg‡2ê\¸”Gi“G­ËlsâPàsiœŽ‹eAb¹*W2€«„ûbÍMíPÒ©;¾‘'œŠÝ&öÐý$G{.i•¹j]d!)ßCµ%!ݾzyeªèYܦ‚¬yH¤]Œ‡A§±ïb?δ•Ü9LóbSuÆ£tGôÑ·+×MDh“åqP#&bQÆD6ùV%Ùy(í8Ù‚¬( ¡n•®C ˆç'[:H«Ô—O»g("Ï=õw†_葮Ў£†‘@GÕãí‹Žs]Ø\étL†bz[–õ›>v °×±aj¯cý!h¬" ¤Õk´L_°Ð· +.á0d[ó‰Ò(×´ÈR4à[¹%vwûb›cwmä©·¸ø—ÏqXÈPaï­(Kì=Ó×^¬‰^Ý4Ås™ÿK{„:?|+ÂkWHœV˜Zøw†8k¾aœŠEŠ~uÞ|;”1ß—“ #˜J.°´ –®IBÐbIzÄò뾨lNE®ð=é¢9l·Ùž|ÞÖgÝI½Ó‰UsTnÑuqÐoH}²†9½—ýG +LJ$ä—«ªiòå l¬i €M*™ÚÜéüÙè?Ž¦œ ÌÁ|;{0#üús9æ7x,¿/èP¤ç.›õ>)pX™£±½›-;«;¡T^(€{ÌyÍÆ(nw±øÝíë¶^ÖåÙâwD¬¾ô=–k°ðuƒ[Û¼)z+:™øƒÂ˜)*`õ¤©.<8=€¸rŸ±$Yœ§Šáƒ!|v/fÂyÇÐŒ`àXXº*ÈçYâ‡`!¥ÉžéáLîD3ø0Ñ ÚP7Ì–kPìÚr æžÈ€ kÃ'~uÅ›U€ÄÛF÷\OwGhuy­Ùc™©%©°5]w °KZF[<*ÿ +?šÃr™CÕº±ÝŠä’õ:¨ûµ(cÁûKYçį·«üõ4£€š%‰’qá:Ô€t¾Ë€ËؗΈeöå“A¥UÌa˜'T†Ù¤nQÚ*7UWKÌIú•€Üõ¹‰&ôg¸Å©Umù˜MO“}¿+Zž ¼ô„`¥\ ëò7 ¬kÔiDiêŸ< +9p €°0±wú$Ü_‡lÕ˜¡ö _,ss„Ò¾«Þ/ôO=<¥få¨Ç‹¦sïç:³µ°™©v¬‚Ž7BÆÇX:dGÛ%¢tÒ{÷ðO5²gš72ÂóÄÔšåK¶Ï–­ $€C r­&XÒ˜[Èk<)ÜÌ­²–ˆêGÝ>wJ·`¤¨À(²•/ÊxvEÏ8 ›=˜Mf%~`¤=Õ¥þùAòî‰Na5üDrn-¬pÞ9ð^l»b×9G“ïésì2|¼pž–GŸx"Çœs>âÆÄ›æâÃQÓîójÓ¾œÞ˜øh}D¬s"—ÿ«Ü5"Ž\ÁŽBýÍ: ûF&3b/NF?ݸh÷÷žØþÞ3H¥ F6ÝEÉÜ‹>ÁLí.µëóй:Ó +2å{Ùò°'Ž­ýð%#ƒ©èyq•ëW9Åî°‡2·†Ó¥ZpŸž·¨Y,.S>{ýîIJØ×ùžÀæ±[·–dö\”EûîÏf˜¯Z£|â ‘\ r*Ï`Ì0H¶ºª®§í<³çÕrÿ¾£0©Éžÿ \-¼Ðȯh2¶þzña§Ì_ó“"BA©+ ¨“ÊbN¥òŸÓTÍJzbaáÅ«üù°ÙtocFªàÜßž@¦ ÿ`d@*6±‡óÿ]Jÿ÷7Q¾t®‰ `ql…ÒûƒÛâôœé/XNeÿïN¥Qendstream +endobj +1938 0 obj << +/Type /Page +/Contents 1939 0 R +/Resources 1937 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1894 0 R +>> endobj +1940 0 obj << +/D [1938 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1937 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F55 1025 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1943 0 obj << +/Length 2184 +/Filter /FlateDecode +>> +stream +xÚ¥YM{Û¸¾ûWèЃüd‰½ÉŽ’x+i¤<Ý6ña‹»©){½¿¾ ( ½­} gï|Sd„៌C˜ÊhË1LØh¹¾À£Gxöþ‚XšÀ]ª«ÅÅßßÑx$‘ä!-:¼ÂBÑ"ý>ž|ù2½½ùå2_¡Ë€a<¾Ì¾M>™½/—2OÞOç—1‰ˆk2ŽÇogóùô:˜ß¼Ÿýçólzy·øùbºhë*O0ÕZý~ñýR8ÃÏQ)Øèn0"R†£õEÄ(b¥n'¿˜_ü³eØyÚ¼êƒQ˜c!‚$cáL"NCÚÀñ~:›~è/¦oÍù?Nÿ=×'ƒ÷iM<‚§($Òàø¯•*,éP…Â8Pk¢´¨*µ ~S/-u—'—(Ž¨%^–ëM®jU±W»åRUÕÃ.Ï_. !ãŸ`_Äã¬ÖW<Þl³¢¶´‰ÙªjØ{4[åƒÙ«WÊl<”ÛµQ!:P˜bXKb•øXÀz“$É›Lÿy”oŠB&í uiØk9@; +¢P Q> +Z쬪“"M¶—DŒSs¹«7»‹<^¬²Êl»kRØûTuöãp™ÔYiwÛ“Âf樰¼í˵¹®ËÌ ¶I­RÔë»8B”òp ð:T«‘¨‹,íðÒüÀ$>J€@ò(>/µ¥:{`J‚añC±Úž#†EØÝa~ +`‘¬U/T\pˆ‡(:U—ªª–jª³R÷PˆõBu œÞ‡w { *vkµÍ–æ¦ñoµ1— +·ã²M@vßLòÇr›Õ«u?À·5ÎÜ¡:°£øœÔÀÇbýwÅöe" >èû\ lÈÿÀ »ð(˺IŠ°I'7,F¡€„u ‘ˆWåèÃKÒ)·4¶Mš4Mi4®ŸK½`c­V®*ÈÒ”±ñ3Öèª É}R©Ôìj¯h^ׇÔÏÍÝS“Þ/]sŠbödk¤¡:=ð¤HJr”“—%8hVýÙÝçΡ5?W{š¤œzt"!øD_Ap°'€Ë£‰(•ŸUǾ 2µ&ã®k×¢‹•òi µ6Œ°¤ -JŽ]m3&“`ÞÑNß%úë~ÈÜCÏ`Æ=–¥«tz¯^%µe¢«š^Ü+ê­1;ì‚”þ|ügYXñ]U´Ó§™•TCwаÒa ŸZÏÛ3ùÛÍ,°¥™#.Ä‘\úövêª*½VÒ]Ï0´"qL\sÆâÀ²­8†7"]x£Nj ªZšêoèšàÏÓJ7¤"¿kN ûåýSVîìëÏ;xýÅ<²[•Eœœ‚A²jÏΩ–ʾ_”µ,}'‡€­’'Õí&ònîOlw³QÛuVUý½8^•`$P¸¡}ðÑñHºàI°ÇmzÞ"ŒµÙÍæ0@!fcÓ­ipb¾oœÌ³¦çÒ‹êe½VuSõ­*–Û—)zúµÖ–'4µ+ËÝî|¸\[÷Ôy„èÎòîÛ·Ìfõ¤ +—ÊÝãêLÞÒ¨ø³‡yìŽÖ°ý}49¸ý¾htÆ°eM›®µ™þ2¹ýòi:<,ôL¡{cJ x—D$×°Pf?1—˜‹à¾iU)ŒXó‰Ù5ÊR×ßÂŽ9)ì¤åbÅš]˜èHtÍŠú#Ñ#‚ÉÂ7|À©XÛØhŒ]=ÒÂÊû±£$zƒ1}rÂñ°¾7Mµ`._áÈ÷'OwGÐÑSòúÉÆíØÛÕ4•è2ÂiŠÜˆ‰t¹ªçŒ=)ŒpPºª³9 +¶Äm-n˜\A¥9îh„Ÿi=(ä=Ì]%ò~ÐÙ`{>µÕròiþy8XCTÙc¡«¹®ÝB—WkB*»l’9¥®nfö‹„´ÓuVdà‘IízÞ¯êAÛKë”·I±ƒšäsÎyð§ +@'Ú:þõݵáÓ¼ôð‹ 8j üev"bÿ;»è˜8=dç70• ‰ˆÄ~òmñáó×aÃÞ@»¾-”Mó— +Z'Û»^C«Qnël·Þ‹…ÊqWP"h[¥Я‡²€!—¹Šë(œÞmˆg0Lô¨&à\±×ç쨆±Y™¯xf½®©ÛTW—e>\ ç/E¹©²êx”„Ð#’ SǘžIRGwÈ´5½Ã-t”L4ѽgq:eº¸¥òž^׉ïArçVKs2v8‹HÑý˜—'•/é… »œÔrL='Á™ËЯC¯^n_¹¬ú o¼@WˆÑv#–yƒ3ôIí¯³1=qŽ_uþ5«Ai +…asœ r¬Ê$€q5Kò~m t œˆ“)¹ÃœðøW¬öÙ‹0£Ž'6çʽÇ=ĉ§mÚÕÖ#ë0¶ÐÔëT=õÄ7f'€WÀ×ɶî‹p PÜ6 -׺]=õ*íøç0Qå¯ÏrÞÙÞKH(fòhNûPÀ"I°C©JòÚû„&¢Çò> Çe­‡R˜6«×4±+]šäfö!!„îú>Å‚\ý;”§Vá¶>þß?wí¿éBV¡Bì¿ó~.m¾ïCb•ÒÇ#„«Þþ0vªû<¥ø¾endstream +endobj +1942 0 obj << +/Type /Page +/Contents 1943 0 R +/Resources 1941 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1952 0 R +>> endobj +1944 0 obj << +/D [1942 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1945 0 obj << +/D [1942 0 R /XYZ 85.0394 752.3199 null] +>> endobj +1946 0 obj << +/D [1942 0 R /XYZ 85.0394 504.8188 null] +>> endobj +1947 0 obj << +/D [1942 0 R /XYZ 85.0394 359.3246 null] +>> endobj +1948 0 obj << +/D [1942 0 R /XYZ 85.0394 298.3625 null] +>> endobj +662 0 obj << +/D [1942 0 R /XYZ 85.0394 260.8495 null] +>> endobj +1949 0 obj << +/D [1942 0 R /XYZ 85.0394 224.9084 null] +>> endobj +1950 0 obj << +/D [1942 0 R /XYZ 85.0394 193.5316 null] +>> endobj +1951 0 obj << +/D [1942 0 R /XYZ 85.0394 129.6476 null] +>> endobj +1941 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R /F48 940 0 R /F39 885 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1955 0 obj << +/Length 3093 +/Filter /FlateDecode +>> +stream +xÚ¥MwãÆíî_¡#ý±óIrÒ““u7N²Þmì¤M“h‰²ùV"‘ZÇùõŠ¤(i_k8Ä`|c(9ð/g6‰§Ü,u&¶BÚÙbs!f0÷öB2Î< ÍûX_ß_üí:¹Ø%*™Ý¯z{e±È29»_þ}'ñ%ì ¢7·ww×ßÌïnÞÞþçýíõå\f©L£«®oßÜüûr®¬t@"zwuûÓÕûpéTtõöúîò÷ûï.®ï;ÆúÌK¡‘«?.~ý]Ì–p†ï.D¬]fg/ð"b霚m.ŒÕ±5ZÈúâîâŸÝ†½Y¿tRRÄJ'jBJΤŒµj ëâD+íÅñæúî›o>Üß¼¿ÅÓø5{ Š8ÎR¡<ò²jšb1oÊÇ꯺*xî-HÓX+“ÂBÄGÄd–˜(LJŽpHT[Ý´z,ªb›·#Þ‚Nh"¯–úñGÐÁ¶—2‹ŠEíŸË°7!êèÙƒëånQ É"#ïö©Ø6e]ÑD½ÂC€è˜ïy'/`¿}*ËeÑ_`Q})#ϼ±ItOS.yì¶e s¯ hóv×Ð:ØÝÖźxÌ[ Ê+btCÓŽMz{èoŠö)o ^6_‚ü¤Œ^ž +X¸%œ6ð³x*×Kævhš“ÜüYE8$ùƒ?Ízã®·ô¬êKz)z.‹¶ØnJbÞ^éIäa@(š¢ZŒöËúÀÉ„Lßæ@G±eúX¼6E;aj:‹µ³'´ß„PkÞ}hùâ‰FA,0$ ¶Þó¹ +|J§±RÖúß{ç8ôu§R&³D›8ÂñMBš÷±‚kª éÎó1IŒs2;M2 MìK/aªåäÏ— «Ø–+Ök¾^Ó 8)Ë Ìœ••Uf"=#›Ö Ù,/›)T´Çôq¢Äb7͘1—Ä™Tæ4ci‚1= ppœÝ=‹±hF®é†mÑs6ðƒ©3Î)qÚTÇi"’Óâìcg‡åÅùqJœ2ÎœÕ{7³•%±…½OrÅ8LõEé$ä-€ ˜º¿t‚ã=Æ>ð˨鄻$råyÃÏ\yC-«Ç6ëmΫ×Ñ<Ðùcƒ©_iˆõ%ï^?·>sàx“3‰‡â9ŸSà|BeÔ²Ù­Ûò9ª¶Üœð«%Ø,<­îÖ u,¯îõ„º],• ‰{Yoò²3†Ÿd¬OrÖaM°6ôà-±fÈÛ[4½ôm£7?`Åõ3Á0xhY1ÒrY¶œÑmÔÖ%—‚×*Î`'üþúNlûÒHÜu»7¾@ÑœãaŽ¥áç}&Xþü\TË j(’D)kY='}ç®òMqÄïGuÍQ›0YáÚÉ6}¬ã6Ñay›Xž Ër[,Úz{¤R±Î{š»k‚½](¨Å’4ò÷C]Üg÷êÁ@ýœþO5‡b2÷Ñ®`™‰Sçm 2UYèçãØKIÁSâëtk3ØÄÉ–}¬º X^·•„…¶Â!&HJ~[-F${nŒ©ïnÒÊGÕÚ¨F ÓûRÞX³~ÌêCo•"ºþ³lZÓÏR|)CYó0p¿Mý©Xw=°Ë4qöŒzzX'Ô°¼zš³Å 4ÛvŽéâÐ÷’8…tuš½k‚¿ï¡ÁgýÃv5/ Eˆ«0X’zEhÔp®Üð$4'Õ_JH±oê`x¨$>`ÃK?åë­ŒålŒ‹¼ +¨…­€6«~.Jî’F{~>4õzçÙW–:ØXCŸö© žÍKÈèª"äþRCzÙãÒÈó§0?-Kè |f€øvIQZƒGµÛ<ÖJÞÿø{÷îÍ|تQn|óí·ïÞÝÝ¡½§ØŸùŽòïÔM+à‡Ò+¢€( @B?B|i¾2ö«0õÓ=pö }Eï|E í&6™Úøm± ’*º"¬¡”„0ÁoIÆ"ɼH:yd,,úâöK80›Òwl½%·ô€6µ®– ëÅz_@#KÜU-ÏýéèfE ªž óê„›t¶qߤba²„Q“½ÚïK²E¦±µi2* BB²Ê¥  ½Þq âîû©ÞmCȳ"”ЛÕ/㺮œ&›ÅËa¿kND8m\lTv&õ±ŽG¸ËG¸b:Â¥P]°$¡˜šŽo П<Í\‡5ÁÝ°¶€°š3d¯‹oÒqÎÆÅ7ùøæç¼’pDñm€ß‹oøÊñMº‰$„ÀâÏg. +|`ÑO¼@Àš²Q­¡\6Éç©uqº¿Aa‹4Za‰¯‡>êC"Ä^\³ª³FɆ#ž %/ãpÕE&„…Èä³Å¸Ðý–£8‹äjÆyb”W+÷Vž1gŒ9MÒóTÄAÅqhÐ-½îƒ +Àúwr!m8°âºt`Œð‡r]Ðw]ò¸ô-(œt<ĪG{½?ì3A}ãiTÿÚH>$NTõË·11Äáìdˆ“FÇ*Ù„»º1el/Âáæƒ7×Ð iA3Ëü•qöD6üiýR’ ‡yyùñ H4—3$'s•ÎÄ&ƒöp e±Ê¡…>ÂT*¡HÏôG}¬ã!¬Ãò!l5Ù3'™YïÚç];_•ëà æ]ϹÓìuXü ‹´4–Rª!ƒ¾[Õ2á.=»L„&àY$`¸0E8xA .݈À{ö +Ò8þ«»·"Ý“cÐB¯U¤XÓ;uÉSÑ,3˜4XYÌ! +ZDh£åPçÌın.´gívYùÃî[”ÌqËQYœ@|á¨äJâ9oš0›3Ì;&F¡¦ë¯‰ƒ‡¢_½%.UÐù'|tï”1rv®³$vd>pôp½:¬¨›q•ÿºX‡¶"ðo9c漘6p¾¢û‚Q×€Ý œ4žlh„wY z¬ª}W¡º®"§}BO ¡l§ +˜}ˆ|gW­ï³PÁ 6“ÝaQyœ½e0¯¦­0Œ{5èyÞcçûR6Å‘%pš¦\´rÉ”kz>0UÏ%]«À[SוßÌùÐ0U±´§ïXž×ù‚[¿4‹mb÷ LBuÔeéTÂ÷Úöo !°Õëè”(@|Á°†³m·iIÖÀ§õ_"þP´/9Y{ð}‹@5*t]eˆÃýEþXw5}h.Wt\ñ}Ä¡ûX»LšÏ(ÐDlŒ •Üäm(rà²ÏmhͼûŒŸÌG-í(˜&ÀDjäçÇyüÀ®C¾|ó‰» ÷÷yË­´jÔJï™Õ)]á0á^`XŸ"ëS´Y#BsÀœp‚{¤K`§E€BOÜÅ;½ÿöÏ´¥§†C&Pò2ÿI —û[I‡ø Ó‰;/N~¦çÂwWti—¾mw᣻¿öÏuÑt·Ï9ÃèxͲ „Ï%ÀK½ ÷®G}u*'ƒJU +å×É”ÜC:ž‘’OÈ7ç +mŸÂæ ù YÈ°ÒÎb) ®<Å\‡tȵL"˲{÷¡–fú06\hÛ}¡Í¥'ÎQZF ¡¾~6чºiÊ*À oÖpѼ·‚ƒê*Áï£Ý÷ èÓÚâÏŸ.§@jÝý +æ1¬t+ä)…Ú|èÚØUhÓ#²Í_ŽÑÀV$Sã2>â~ä¯|oëì>Í;Ø󶄚´\¿2œÑ]óoÔ?'dðN=#ŽÈÙa°|…â¾\ÐËþg4vÿ#×¼ÿ–Ɔ†–ï6Ï´"‰B›úa—¶1þk¨D÷K’ÿûG_ûŸ·šYväû©J!a83S(dp¹Co埇òþ_0¥Åendstream +endobj +1954 0 obj << +/Type /Page +/Contents 1955 0 R +/Resources 1953 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1952 0 R +>> endobj +1956 0 obj << +/D [1954 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1957 0 obj << +/D [1954 0 R /XYZ 56.6929 752.112 null] +>> endobj +1958 0 obj << +/D [1954 0 R /XYZ 56.6929 665.106 null] +>> endobj +1953 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1961 0 obj << +/Length 2978 +/Filter /FlateDecode +>> +stream +xÚ¥ZK“Û6¾Ï¯Ðm9UAGÇv¼N6c¯gRÙÚ8J¤FL$R©ýv£Š HªR[:l|Ý~€â ?¾HUȤŽ‰ŽBŸZ¬÷7lñ}ïo¸Å,hÙG}ÿpóê™,t¨c/6½¹Ò¥)_<俯?}zw÷öÃn—B±àûðv© ~~}÷ËëíÓ­Áë÷ïîo—óœIäꯛß~g‹öðã ¥NÕâ^Xȵ‹ýM¤d¨")ewsóïnÂ^¯:& %ÓP¥"‘†=ipí(^$J‡±„.”ÆÆÄ®€}GIPVøŒƒŒ^«ºZ¶Å×–Þ6õqŸÙöº®Ú¬¬Êê‘œyÖíÌ*j¬ì´MùX9!óòxËÓ X·»—[Îyr•L[ >5¶QohD»-íÄõ¡-k;w^»åªºE-€(–œ‡Z)aöµÏþ,H›ûÓzK­¦¨K„ÝP7™¿TÙ¾\á[]Mx¡X2”ð82IÇ­Ò‚–}éY¥C!¿Ë?pÉW?(ÕCê •Àäˆø£lÛâ8dŒKXT²xž³5šg"xã\û¼ýº-PìqlTIZc&@Cá¹l·Dˈ€ÆõÕ¨ÞŽÍÚéŸúwå¦hË}ñ¼&,Èv;¢þ ŒFYs©Í3o¨¿lš“›ÖØ$ÐZcA@À ‰&„–j Y¬´o ç­$:(¾¬aâ +)˜J¹?íÚ¬*êSÓ³T6„ õ`¬Ý?Œ¡¥¬Ö4Ù¾€s²ƒñ†Lç÷šÂÂÂL¨¬ ÷@CžJ³â²;4)™¤oãäÉp=)XpÈš±Rð ³´²:œZj¶5uŽ‘`æ>Þ&QÌH™’à±ç,;§4;õ6{*ü™Wö`ÌþÀqdÙÈVuÇqÓgûbìô¢A<‘VÆ3˜“õÏP‡ZÈôâh ì<£NxdaÎH.‚æP¬K´O³+PoFt;•i?—U^?S»Ýš}ð¹4ÒšÙ6j:°v(X«‘À +Ò‚C'­_¨Ö8SÃÀ*â0Ÿå¬C°æVX‘ X»÷|P¤¬Ÿˆ"klDD[£Ngç Œ³p?˜ê(øþ…zòb“AøBïÃi¨ì¬çh`i—mÚìHî@&3Bj‘¡~±•-$l h +;Q©œÞ|úeZ³ +2Û4ÕW4ÛCÍhÖ¡ŒfïÆ4‹‰·K™š:[‚Ï(³ÝÒ¦¯caƒ!Ì2Ù¡F¸ì+Y0&QûlšÔ6bIpÿñ56â€X"¢Ó4¶]ŠÔ:ÒZ7Ú%؉ ¨<ÜàSÝ4åjWôghè%;‡™8—‚Ãt°ï6¾ýY|ŽÅR¨-4sgæ SÌš4ùw#«Dbtê‚/ΊáÉ„¦‰%TÊ´ÓºýËY!I•ÈÞ¬§ªüŠ¾ejRjº fÊYÐ(\B5^cu¨evi¨®ÆêPc‚õ–)±HÅW–w¨‘å=7%!±ö×[»Z§sÔy¹:jcžT&‘yš!dž*N .J¨<Á¼àú°iÁu¨I›ñxˆÁe|… áÀ“]”'‘χ~Fõ7$fÚ§¦ËÌ>ÿð†\§Â†Í#ÔK{ÈÖÍŒp#j®ô5áö`3Âu¨©£ãËä¡¢ô + 5‚']R‚ðy¸/þ¶L]ÒèwÖ72žÜåÉ`B[êõv2RE\„Qþ{6RõQÓ‘ªC™HUç 2êY},Ë겺!$bžµ5›Ÿ„$PÔKå3÷ài Y£aÆäÃŒ +Þ¾÷8—NùwC]tÉžÓD{9{wå¤lÉŒg*úý0Ñtyl7‡ãkB2å üDÎ믚Ö_‡2úûx-Ó€Šêí‰,ƒ'$ÂØYþh„?O‡Ð çHú Ê„u)„L8%Ž‰«¶¡ALRÛ)ö:ï–Æ]!©ãÒlÛ´#†þsÚq^µ¡¡3iG‚i7¤^¯'·Р7>žuXÛÍ”†x“³ç©5’óTL¥}Áù‰#q%“í£fìË¡Œ}†Kê(Œ¢èÊ’4²dwêw¡Kþ‚7¡ÀHphŠS^/éÆIïgmFÏææiÝu’É:€êÑH‚ šrBÛ²P›¬i»k¦Hò`eŒT˜"µ½L°ªL±ËOÄÛ²…Š]ÎB%ι+‘c_$°¾+I,S"‘çËcì³jPAmN`þ;z¥]# wI(¼ @™‹bê1—Éðt]¥$Ȩ®?Ø5›š6¼¶Ó”ÍØýĮܗPqMš¢HÁåkyÅÕõQӦءŒ)Gï¡ãÂë‰:/ž.SÙ4ÃÅué•Ùdv¾e;Ýks®BÅ• EV ùxY+9wVVy¹¶ßàè~Ï&k¾éŽØ$†¥m}Úå~²…{žv;ôètâ;äÙíôP3nÇ¡ŒÛ¹Hš4ã$Šæ—t ‘%½‡±R‰¿ä§cé*º¦…óß`!æ_h®ëýaW`à˜”Oñ­ó飦%Ò¡ŒDž®Ö »â©ØÝ[ŠŠ½YÎ:ÔkÃ{K¡bŸ5¨ÚšAfž«ÓãcWíΦe¦¤ÎúJÕGÍÈÌ¡ŒÌ¾]X‘ ¥„ÌnvIYÒ³¢NœVþ’«ºÿeå§ûŸº*GfVîÚ#5l¢`>lï¾¥›.g}® Â$dZ–‚Á`WjÖ>jF–ed)Çì…Iª]&Ðd»ËZ‡CÞ-ÁPfëP#œyæ'¢0Lù¬½·o—  \ÇÁÝý»7’(ð¯ H¥OÒH4¦Š¤Çò©¨ˆ¶-¾R£¨ÖuŽ¾¸-pÞÿBÝyÖØY°±rñ +ˆ4†¤&M‚–xóÁ¢s-Ã-¿™åve·Dq)hHqþÝ&B…ªùÁGÓÎr*g9ȇWgKkZÉ7I÷YÐYdwÈ­ˆgDOÿK"çó+’8ƒfþ#aAÆ"ÿy­ +‡”™>ê]~ÍQi¨…³¬u KÞü«,Ð#“±Çܯ“âËÆ…×Éß Ù©hŸU/.Rwû&]n×W.g,œúGähÑxFÎΈþï+ÿ—%¡LÓ‰ ¹8\ÍS(?Γ!ëÝÿš.yÿgH,endstream +endobj +1960 0 obj << +/Type /Page +/Contents 1961 0 R +/Resources 1959 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1952 0 R +>> endobj +1962 0 obj << +/D [1960 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1959 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F55 1025 0 R /F41 925 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1965 0 obj << +/Length 1813 +/Filter /FlateDecode +>> +stream +xÚ¥XKsÛ6¾ëWðÒ©4 Q¼ˆÇQ±•ÄMb»‘2M'É–(‹Dº&åDùõ]EŠˆ“iG.ÁÅ>>ì "†‰„¦:’š£“$ZîF8º…o/FÄñÄž)îr=[Œ~{Îd¤‘TD‹uG–BX)-VÆÏD€Ç—Ó7³óøìåììÕÙÕåóIL¤`|<½¾ž]ž_¼ŸÄ4ÁÀÌßL/ßM_۵뉦ãé‹Ù|òiñûh¶h ëO03Vý3úð G+ðá÷FL«$ú/­i´ñ„¡„3æW¶£ùèV`çk³5OJ(QÌ8R ? A’`’‰F‚QÖBFI2Ïe ‹§§Ž +‰¤ ,ê +¨ôL•¬£RR$9=•n²b3ªÇ·Y‘ݧu^ÜÚ÷Ô>.ç³3fÉå&Ís•Õ–¨7™%®®¢ÆWïöý#Æ,u¢J·+ÝnBïÍ®lY6ÏUå‹•%V¥}eݳ23@E +©DF1!H' müq’Mô $›Å5¼6D^TÙroyìÊ*Ûf·@YThpîT%ˆb¢pô®GŽÞs»¿•EÑmvªZS$„Ô«öLÕÝÐ ÛS½Ø8œþ†^–E §ÝDƒy¯=“1Ô-•öyãÞ«ü¶ÈVß…N(Ž$êqèº\߇®å2öΧ:%C ãèôL½´Qˆ*r¢s~—-óõbüe“/7–[*KU›r¿]YºAžû*s+ v† 0s+Çd†ZÈ5¾XÛ¥¢<•ž¶k„cÌáe«§°"›ÓjÄʾXgnnÒÐÙeÒp ò$²¯é./s™ÏH¿óËù«Ù_vq˜_&skûÑêem¼˜OwÙWãæÖ1[=*ÇwôÖ×å¾pªSOo—åÈßvi½ÜØX…·»ûüÁ—ÜwË øÔ€“Ȇj`eµ+¹s±.ïBÈøi»å¸¹rÛ¬„pÇÝ­:æ¼ÁÎ&IšØn[G1åHcÁ1âФ‹gï§o®_Ï܆n`‚kT"*Y'‹]ÛmùÅ‚!HäÝÎbߌúÊ’ÆíF&W™ú ÅÐqwÛ €B!¦„çõƉzc•×Þ¨óùÔ&YÂò•å¼9´t¬€ˆ ¬†UQAÍŽAl؃5(Q\÷Ïü#Nð«Ž'è ´¦'DR.á”D[ü@@ãǯ¦) ÖNÈøà^vûª¶,7Žµé†Ê%™YØ¥U QÚоšc‚C»ëc:˜òîÝ ÇñV %¨cïÙžWM´Çœ˜c@I¼x(—Mgsx2Þ–åçÊ’&2‡†icUâq7Iý~hÓPA¹l 2›ôbB[l¸ CôÒ‹qN/³µ*ýÖ´¶ÔùÜ>‡Ã‚œ:Uͱ€àNh5.6ÜQÀ…QH.Ü–;;¬‚•;ßýQõB‘*Ä)#ÎÕø6t}ïÿ7– ó§YÜÿ¿ÿ›;þ É¡ß(EÃ÷t*›…7Ê8ãÃðïŒ(ƒpÚþ/?×>3endstream +endobj +1964 0 obj << +/Type /Page +/Contents 1965 0 R +/Resources 1963 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1952 0 R +>> endobj +1966 0 obj << +/D [1964 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1967 0 obj << +/D [1964 0 R /XYZ 56.6929 612.518 null] +>> endobj +1968 0 obj << +/D [1964 0 R /XYZ 56.6929 335.1485 null] +>> endobj +1969 0 obj << +/D [1964 0 R /XYZ 56.6929 267.4555 null] +>> endobj +666 0 obj << +/D [1964 0 R /XYZ 56.6929 225.2657 null] +>> endobj +1970 0 obj << +/D [1964 0 R /XYZ 56.6929 190.8284 null] +>> endobj +1971 0 obj << +/D [1964 0 R /XYZ 56.6929 153.8399 null] +>> endobj +1972 0 obj << +/D [1964 0 R /XYZ 56.6929 83.2251 null] +>> endobj +1963 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F41 925 0 R /F39 885 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1975 0 obj << +/Length 1710 +/Filter /FlateDecode +>> +stream +xÚíYßsÛ6 ~÷_áGû®bùC”ÈG7qÛt“Åκ[ÚÕ–µ–”JrÒô¯(’²$Ëö’f»ín—»„¢!ü|cÒÇðCú‚#̤Û÷¥‹8&¼?{¸ Ÿ½é#ãX!§.õjÖ{ùšù}‰¤G½þlYÓ%‚ôg‹«Áèü|<9>ù}èPŽ¯ÐÐáNG“ËÑ{½w>”t0z3žâ{”€PbLF§ãcçèíøè—?Î&ãá§Ù»ÞxV9Vwž`¦¼úÖ»ú„û 8ûFL +Þ¿‡Œˆ”´÷\Îw³;«Þ´÷k¥°öiùjœ Äõ;Р¤O’œÓ\"QVÂq<ž]œœÏNÎ&ê4å;qß¡.’¾ï•ÂI‡ g~οÎÓdi^`uÈ)ò)—ò¥d®Q-nB½È’"øþB?|^z‘¤E[.Œƒ¤ˆæ¹M—úo`^P¾è%øòcz½Î‚"J½©vV!ªU±^:ŒêL'ÆY Ât+¦a¹ãyq*dwB!§.eC°•”²ëÜ´MB]×=`Ò +u˜¬DJäRÞ2yžEIîu\[ä×qdîÄ ~ +´F‘GÐ<Ìs¨/pQAÄ‘ë)¬l s©ëÈ”e6ƒµ©½ÏRÍ£8ZÙÊìÎ+Ìl—µ¼3·¸ÄÈw…·?·êR»s«’*sën«òÒ;`Ò +u˜lTž€Xú-“]•wfyE[–åÔ§Û| Mª{&AËÇ&¶×Y?¦¸¡ó!Áá¿Ú¿*ÑÿÑ>c‚îµge¶íµ°gDò†½ó0[¦YÜÈÌ"ÌM4Vi°hõ™ÕJ/â /ÂL¯¤Ih™®-zQÒQõªsà‰Z¬ÐŽ0AGö¡-ÑÝ`IÊøHÔ¤ö„ÂJ•±ø² ‚<ßu÷›´B&ÑðÇÕ&?Ü„Éú(¹nFál)J³‹b(¢ªt¾¤ë, VM&ŠŠ*§ó"ß &†ø| ¡×¥ö€i¥ÔÉ´ß*Þ[ †)‰¹ßv%Õa¼Ñ‘¨„,g´i}VbÃü2áÔJ茆 llLði7@+÷>ÛÅ(Š†Á'K½«g6ËoÃy¤ÞjXsM @d.ƒõªÈ]Ý‘¹0ã˜ä󗛆3L.B¨]o?; +‰2$ vë…´5ý¹@ÌÄ·Ã_)x1ž]^LtÚü6`£÷—ãéóOÄ: ÈÚÜ2ð†€M·,‚b7¹ˆ43<Ì4‘gFì>´\=-ÂfÛ[+ŠÇF%dAvå§ã±~yô~zÖqÆ.P>bŽü"/j=^#¥‹»ú¸ÔÇd=³]ÅòĆñÕÉäX+‘ÆE%Pܾ©!æ‹pi@Hæ‡Ó Y7l»K<¨çy{³„Á—¢‘&£ËÙÛ³‹Ãœ$Ð0’Ðtúý#6¡:J“<ÍŠho¬B¹»5z\lžÔÁ‘€;(Æ[è••ÂÌEž ÒÄN‡kù„óvÂ*EÍà¤ñm´ +KúE©¿áãú½ÊL.Á*ZDE5×ÒŠÈm` ,`À)ªý"MW]€ãVÊ=$émåm +…†”çhpt":gz§Ww¼ŸÚë*Jvu»¨½’ê@oèx›+gñÉ®nªÕ—jõ­ZÝU«¹¹Õ4¸ ÒRJb†ù*Èó®¹BúvV¨4.;4 :¯UÓOPt1pC¬Òøúù4–Dî¹ÛM"¿r¢.,J·PÄé"ìB¢Aö•ß_ú½Wkë‹Nß–§Ïì_òÌúÒÃq6óMû®ë#A±ßÖ™wèt˜¡´0m&D^<¬Â¿ž÷ÓgŽNqP_ëßPÊ,('m¥÷‡Òãjõ¡C½Ç‘Ï™û ³Ùèªñ ‰le@=«;¯ +~:;×4ì&g+Tãæzk³ó8™«KœàOãä£gÎ͆ã&|Ä]ÏoÖåcUGÏ|ø;­ÿwi˜ u?' añ?kîdÍòi?Zâ‚c¨¯u:WCñO{´ùž Ò A»ÿÀ°úƒ$Ö)u(BdÛõê{¦mßÿÅl”–endstream +endobj +1974 0 obj << +/Type /Page +/Contents 1975 0 R +/Resources 1973 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1952 0 R +>> endobj +1976 0 obj << +/D [1974 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1977 0 obj << +/D [1974 0 R /XYZ 85.0394 752.397 null] +>> endobj +1978 0 obj << +/D [1974 0 R /XYZ 85.0394 692.2263 null] +>> endobj +1979 0 obj << +/D [1974 0 R /XYZ 85.0394 446.6274 null] +>> endobj +1980 0 obj << +/D [1974 0 R /XYZ 85.0394 386.4567 null] +>> endobj +1981 0 obj << +/D [1974 0 R /XYZ 85.0394 326.2861 null] +>> endobj +670 0 obj << +/D [1974 0 R /XYZ 85.0394 289.3231 null] +>> endobj +1982 0 obj << +/D [1974 0 R /XYZ 85.0394 257.1813 null] +>> endobj +1983 0 obj << +/D [1974 0 R /XYZ 85.0394 222.4882 null] +>> endobj +1984 0 obj << +/D [1974 0 R /XYZ 85.0394 159.3957 null] +>> endobj +1973 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F55 1025 0 R /F41 925 0 R /F39 885 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1987 0 obj << +/Length 2836 +/Filter /FlateDecode +>> +stream +xÚÍZ[wÛ¸~÷¯Ð£|N„Å•½‰³Í¶q¼·ÝÓÍ>ÐmsC‘ŽHÅq}gpáE¼HÞí9m|NDC`ðÍ7ÀÌlAá-TD"ÃÍ"6’(ÊÔb½=£‹{èûáŒy™UZu¥¾¿9ûî­ˆ†˜ˆG‹›»ÎXšP­Ùâfóëò{¢É9Œ@—Wï/߬^ÿåòõ_ÿõáêò|Å∳åÅõõåÕ›w¿œ¯¸¢ ”.ß_\ýýâo®íúÜðåÅ—Ï»ùñìò¦Q¬«<£µúröëot±5üxF‰0Z-žà†f _lϤDI!BK~öñì§fÀN¯}t F Aƒ³cÄ(Å{p(C"Á……ãÍåÇ×?¿»¾y÷á +WcŸi¤ X0‰©PV¸H¶éfµ~Hןÿ]©@tÐ’HKxå­d… ‰eýâ…\VÏE|sI±qYQ§÷»¬~víåïw½v2Ûð‰Rž§`–zW»ÆÇtwW‰@[×Ôê!—I5²N!4aVBÛuŽ¬n%9{˜x±r¸:JmÊ×rùôî*/“MVÜã[†vËÕ%ãË›‡¬r}Ûäs:¦‹xÆtW¥cÐÇÜ/¿¯Ò»}îæpÜ…}¼ÑÊ£ +íU¿†Ûå™^úÎuY`ÿý +ç>D”Hɸ›nç†ïü·î +ŒZº«ÄýÞ"tY¥»¯éî<–K2N;¦‰T¬G»rû˜åéÄê"œEÌ¯Þ ÓdÛ,OìêÙ”N¥$Ñ\šÓQ†ES®¼ü+Y/o÷µ›/«ÝTIþ”<{6ûí£¿tÔ„þ=Etë´¨ƒ@éŸ÷ê?¦ë»€‰%øaö -T] ª¼ñ:è][ânq ž,úKR#ãxy±ÙduVIž?Ÿ3ÆpY‚»;Èãcž!=ìPõ.[×`;Ûe¡ryú5Í+×|ûì~7é]²Ïk£5Šuê:,ø¢cWHû>UîëGDU0ðª,ÏÝÕmê~Ýw•Tþ·ð¿ëzŸxi‡2^5Ð0ç™áiÐsH .€KJª#› Ä8oœ”=&øòŸvÀ¡·I±·€Ú»¾ ¡vOY•"6ÂQÃûWD¸Ô¼oh3ºNÀ¯·ûªöV‡Þ$4Ýz_K¼°³\¿­~(«à’]û6=†Rd…óJ‚H-ÃÆö’ý.A¹ñÞæèY@ŽGõ""Z*c‡ù`Ï«áñËpÇŒ +œ”Á&=~Z:™UG(œ•ÃÈ!ᤫÍá|`)jâùù‚Ìp¾.J1#4Öýù.‹ä6÷¶Ù¤·ûû{ØbÉäš%±q1ÇÌ¢;R3«RvÙ“Ëž›²]÷`ÊÑ…w§¼†Ã¤n¹g/öUrˆºßn“ݳ'ráÙš~Ëêit8PZDGÐéHÍ ¤,:_&Ñ™›²Eg0å(:Ý)Úg©Gg[n<&«wµnºÊÂïê“èH SÆGü¥#4M²Ð|@£0xšŸ/È çëC‰´?ßk ƨš}Æ•SûÄë×Ðè%ñ–0"D6d*ïwÉö%Ä„¨ø˜Ûv¥fÀRýßè "xlæ§ B#Sv×ið‹þ”î쳇Püv¢xÚÇxíBÍds ü{¹ßxÛ“È[. ­êjTn‹Žy{WjÔ eA];(Õ#¤_,D ë<©ªCÅ œ]ŒËyłЈb¢7,㎞fñð¾{>Ñ)3 c Ì£]¾ó}EYO„Ÿ8—ï®ðoˆ*„°§›IK@ÒJb™yKt¥¦-ÑHYKd#–<¸ +™ÝÔ‚Ý"æÚÌ«„FÔê%naŽßSëÚe¢«„´´¬êº‚»õѨì%»Øá²S µY^—U•Ùs%q•“J|N6‰ÅD¢&$Ýh%Hýrk­á¶ÅqÇ4®Ÿ¨¢>H‡Köjdx) ÕFŒ¾B-ÁÇ'f‰ †‹bÖ¤IÃaæa2êǹ8\^®“)í! R’©™q%1šuµµÃS×)LP·î‘¡âîÈXtJON"ÕÔAˆ 홊û(êg·ï=Q­ +lV1?ݨæ°ê"$æY˜ •ÞÿâZÖ.ÅßTÝÆ;›Õ,¦¡Ø|ánË¿…cƒ8)¤Ò-¤5N"+VðÊ…v¤}½*ïVáD…=WÉx?÷ƒœ¤Æó·BJú=j%{s}hî)«•˜ÚÀÈí“M}ˆZœÚs©ƒ6>=dë‡n¿…Ìî«eHšVí9×,$íÎÕiöט^²“í¯Å¡ù¹懫?Ÿ+µü‡»r€›ðÑÒý^¸ŸÒ7{ qct8-àÆqGp@ 'h#øŸr ëÿ„<ŠôÉD€C)Ô_ÃNÀUÉdžÞ7ù·ZB"mGªú«‹üêì΀?¥ov¬âÚZVà]˜(DÉʲÂÓ!&"¦…®@àpCakÁØ—äUé®?€kïpuŸïý(Éfã”­¼ÐÐ+ ÑÒìö1¾lÕØ&5rÀõÚ2Š’Ž:«\5ä°¬u;Ѳ|s„ߊÄ2f/â7›å·³ø™Ú>Î ²¡"U•Û4°B«Ø”¶Ü$_ö™»ð§³Sì¿:6kÔM‹L­:®ÀÜ ­¤}7ö:É'©¤ñ c"I¸–òXÁ´d/_xÔD¾›¬ò•#!–þA¼áTÑy#­®z-ÚÓ¶6J×çÀÅ] $FߤzŒ,Í0®›ß¶`Ð'Ä_òmóÞÑ!­©³¯i·ñ>Ǽ_ž¼3yb¨ ¼Õ¬o”jàþ.öŸÈŸ˜åh¤æó§®ÔtþÔHÙüén4Š°Èävoc”.ù¼bAhD±~&”êk6žÉzm¦SÙ~)Ùn§m*ÕŽòÖéd +ÒI›2Ú¶N¿Õs¼eã¹T[yë¡Q]7ß%OSsÄÂÞM%F©‚)—1úU:R3T R–*oÇŠŒÙ8ãW1TéyÕ©Ýúl0QÃ1ØS®a‹ÐÒŸÑZ4lÁFd ¶ùNÙ¾YÒ¢}/¤{¯h€@W7o­œð4 F B0}v™™bj”A+ˆ‘¥éöâ‹—QɺÉ[8²Gü€C-¢?ñ^Ôzh8zý+òn‘iì매ðþžÞ!¬w°M{é}‘§¡„ªá…êø^¨N; +ÃÏŽùI+4ã&^ÈzÉçq/ÑF‰™Šî|FÏ+d†JõêQ1‘±é+ÊQ#U kÌ…t±Æ]¹°zœ=1èÁØa–©Ùò)³ŸæÁÉØÁûNh¸K²|â l@4ÐϨìùkj^0Ü\ÍKëîp† ÍW6 ¾8JZwkΈ±Íb‰¾+ÌŒHñ6#(¬A,atwŸxJvÅt0™h¸M¼Xï“]øØÆ!¼‰T×Ù}Qî&£!ˆÞhóͤsÆÄ›wΎдs!ëœÛ1ç”$Šš/?FSAX ÜœRAf¨Tÿð¢ÙÓª=»(Ã4n¼á®VGÇ2Rh¬Ê}¾q×ö{xÀš5õ¶rƒ‚©ïÅ×'¶ã!õ³5‘¾½ia,P¬dÔsIÀ¹¤Ëá4ÐLÿÔ™öSæ¡À&©šÏNªëþoyyXv§å$§Ã‹ X›}ÝF›oþô—‚í7‘2†Bóq"òXAð×^)Tœq:tGÿMáP÷ÿ–-–endstream +endobj +1986 0 obj << +/Type /Page +/Contents 1987 0 R +/Resources 1985 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1952 0 R +>> endobj +1988 0 obj << +/D [1986 0 R /XYZ 56.6929 794.5015 null] +>> endobj +1989 0 obj << +/D [1986 0 R /XYZ 56.6929 752.1653 null] +>> endobj +1990 0 obj << +/D [1986 0 R /XYZ 56.6929 611.3886 null] +>> endobj +1985 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1993 0 obj << +/Length 2490 +/Filter /FlateDecode +>> +stream +xÚµZ[wÛ6~÷¯ÐÃ>PçT(®$ðèØJënìdm§íé周ˆ§éåe]ï¯ßÁ…)”ÛdOŽ†À`ðÍÌ7ˆÉ Ã?2“a¦ø,Q LÄlµ¿À³ÏðÛwÄé,:¥E_ëÍãÅ·oY2SHÅ4ž=nzsI„¥$³Çõ¯Ñå‡˻뛟ç *pôÍãèöòîãå;+û0W4ºünù0_$¦”¤V‹qtwy»¼^\}¿¼úç/ïï–ó߸X>zÃúÆÌ´Uÿ¾øõw<[Ã~¸Àˆ))fÏð‚QŠÎö\0$8cdwñpñ/?aïWóiÈ\H$(g Á‘"J†]†à‚E‚Aâ]FIÈe–vÙâVoôÛ·Bô4‰@I‚%Ì®Uöå:;ö¡%‹YÉüVÀ2Ö_*”`¢†¦]m³Õóã,Ê7ö™ên¶¯ÕœÈ([•æ¹îË6YUÛ÷¦ì}Ê¢+}ÌÈNó¡¬ëüÓ.³¿èmºoR;‰õÌÀ‡TRÄ™Œk~£”oÒ|§ŸN»¿/*‡#vÊßæ‹a‰èÍöœVÅÈl,F€ØN ¼Î6i»k`HœÝÅ:°Æ‚%qœ08‚”Ô¯–.Ê*!†ig=: ‡ºX ° Ÿf_kš^Ë@³A“ ©›„&F’‹i»:¥€]C` +$i|dØÃS¶Ê7/Q‹ž·Y3'Ñ6«ìû݃}±Yk!êmÙîÖVáSfe+ óÌ 5Zb–YF¾4ÛÌ-ØÓˆÓõÚ¾ÖuVkXcуµÖp°î€D¼”˜Ÿ"d +Ý R\œâÑfÚ ìüt!ASŒºŠtŸ­«rÿ”ï²ÿ–EXEAÀQ*ËPID•T¯Œ#8J%ÔW0\ŸÜˆÙüˆiÏ;ÄÎQ€‰E?|•ÈÅB©3‘ÙÓšˆÌNËDfŽLƓΨ œ¨öÒItrŽ(Nø´q^+`Ý >¹BDÊdhÞOó„GUÞèÄÎHdNF8*Ûæ©m¬´q{àýݪÉ„ÒÀŽæ äœøX@ÌD7›À”¢D€ÏN ; Dtù=¯CsA'¾\,BÑ‚hB:hCÎ(ìfŸ;o`[AT7ÅÔWN€wÜF·ymµ­³M(ñ×S4eõ29qŒ¸Ää/‡¼: oœh›Î û 4n§d¼Z‡°e¤s|ݼìebXH9i–W:µkkŒ‘c20ìPu¤ÒG …-FVnŽ~[·û'SX@hƒ@~Øî28iN•­P¾l¹èæ«­æ Jt¸‰¤OƒÚÝh¡Pˆ{tB\ÌJÁ¬c$ÕçZU¶K›ü?cyQg„Å}à‡¦@²4…î#÷qkÂAFÚl7*«}Úر…¿„âY;IÝæMj¹¢Õµƒ'ã¢rõ7/>[YÚ6%Ì”¯ÒÝîÅŠ>¹gê&ËžÒ*mÜdõªÊŸLè%"z_XaÓX6šZèàn ¶ÙÙ‚Ó¾A:eìH‡õ‘•vE¢.¨÷eG!´tÛB/¬$]w{´•jðY³mk—;Z€ÌÁ¤óŽ²uÞ8G·kl,u™åm0Eàáá¼¢ºrKL}žÓ&ÒDEë2s£¢Ôå<‘Ñ*mëÌÊÒâŲÞí&[5N»-ônœ»uô8‘¨ÄGŒVeÑdEc8—Š£›Æ-±«Ëž)€±Ã=–ŽnlS}T–¸<ºÏÒÂ8Q¿(°³AŠ˜Ë¸ætbmŸ~æ&û³MžØ”ºx:{öµÆÓ§×2ùóá‹Xû¤]žµŸÚdíúvPhÚIx¦öñp?"úѾœô”⨧SCßûžR zJáÉ·Ñè)c„ ýŠ=%ìõ=eèhS© o*áâÿÓTrÉ"#× +ž}­qxz-Ï&O ‘Ô³u^AbФ愺•‹›6Îk¬€: +Å¡. Ì»ÚÚ‚¢c˜af©\ !㠽ǜRóY¿3šÌ¤ÛÔMŸ«]»Îì Ld±¯«Gí ÑÝWNRŸæŸ[(ayé~µ¬ÂŽ}‡ª_z2[Û„¨A<&Cä¤õ0ßUs iÙŽ?¹Ä˜ÚGïó]Zíœtå}fÈŽNº€Œc 0¨Ä¹ ‹¾Ö¶:-ƒ­çPêÓ×…ç±åÑ0eœ× +X7Ä`ÆCëV[}À@‡øª€ãJúPI„)§=P™9 ¨ôhHB´Ä‚CŸJ­pgاu“U}%;þÇÍÝÕ»×KûvL‡!Hs2>ªªÏeõ‡NÄ»¦_l\q,ÊêaßϬvŽ;èIŠ€Ë(†Ã¥¾ß²°ƒðØ„¼¦P’ˆ³M S)y®«ékƒÓkp^/ Í®áð“KvJ%ˆÃаd¸ä50(ë=Ç›`Ô²ó©õsZ”…¦Ë}R3zŒéî9}qcÀÔÚõTû T1ÆØß¾r?ª·@LUOkâ¨:-sT?}Ùü¤a‡;ùSË‚wòÓ|ªI¯¾ú4÷žúÅp"x®ÍR‰ë +@Ç»€8ßç…>cói¾[¯ÜíƒæÐ —ÑÝ´–j ,îLƒf˜+ ¾†E¥Ã +§.ÒyÇðj{áï¦oæ†Íé‡æ^­¿cå–íég[¬6¦/LØ7ÓJ¿«­¥ðzâÝç²Ê›íÞ¾j–uÿöʾ̸æZæîVèc áënru Œ’I}1E0ÿ 7¡ñhc>z]©s™òWU¯ä|ül=ixe –®Úìì¦Ôú9¯GÜÓ™;pÏÃri?¾|÷ð>°ÇStöögÜzJ¢ÞÏf>¦™üßØܨ݀™ÝòD¹Ï>¡ 9,ÒUü77w×v>åvµ†“×M¥¯®­è^7÷ƧÅʹõ6-Z¨C§Ë“X"ǃ[Æ¿2! kø÷{ùññû÷÷ç=zS@,2‡‡ É{wöWeQ—U“·û±?P€¤®ÿª ”Ø›øżpø3 (8LJŽn†uP¤3Joó±é‚Ièhi°ýî“;!endstream +endobj +1992 0 obj << +/Type /Page +/Contents 1993 0 R +/Resources 1991 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1998 0 R +>> endobj +1994 0 obj << +/D [1992 0 R /XYZ 85.0394 794.5015 null] +>> endobj +1995 0 obj << +/D [1992 0 R /XYZ 85.0394 225.6507 null] +>> endobj +1996 0 obj << +/D [1992 0 R /XYZ 85.0394 155.4035 null] +>> endobj +1997 0 obj << +/D [1992 0 R /XYZ 85.0394 85.1564 null] +>> endobj +1991 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2001 0 obj << +/Length 2597 +/Filter /FlateDecode +>> +stream +xÚÝËnÛHòî¯0‡‘«Ã~²X,ØN ÁÄ㉒h‰’ˆH¤F$g¿~«_M)ÀÎ^69°Ô,VUW×»'üÇ.PDMbÅ0Ÿ,vÑd ïÞ]`‡3óH³6֛NjWoi\~yüåâö±§-2Ž¨–寋O_¢É$ÿå"BTI>ù?"„•"“ÝãqF©_Ù^<\üÞl½5ŸU€#D¨ <Á Q/ÛJà +¯„ËŽ`‡y²K—zG@vF9Šá;ƒr/ô:У-Q(æ±Õ¦ýÜèç3!±…æy•ò´²¿–Å.Ér kt •éá9=8 0FŠsâ8ÐqÁ¤áðð=/öeVöµN1Š¥ AA‹–0ÈM8èqD…(ÖÎÚ$ŒXQƒÕÚ· ~š±/ ´°[ãmÝa‡s{McQä«l=[e[§è[gÁ)s¸ Ýe€.›œ;ÔeúT¯gÛô9Ýþ8ÙU­h`¥8 ûÏWÛdàAb±Ä}y€ÞŒJ‚0àË À7?-öu¢¬”±êSÞŸUʾ8T!z) ´Q6ÐC€rW…?í’—YY,¾†äŸ‹c.ûô«ó‡˜ÒEU¾‡ˆ2$¨·>K´.½Çõ‹ˆNŸ¿˜¨0£°]‰á4ÝY¿ÿ4ûWƒù`  ¢.ñ–ž,6阡[ùB S‰˜Œânh¸¹}¸þ0¿œÿv×|ÕTEXµ#Õ0 Q0VyŸ„83ƒ8MìãÆÅ. ›€h ‡ïe•î,ü9âÑÍÝ<°]p-fÓ+Xˆ£é>Ó3¯Š•}VGèÍüîÆBÊ>–YY²§ºÊ +Çuu¸ÄrZ8nó‡kd¡·ÅÁ»Â`¤î´Ün:Þ”å«â°K,Q|ýÓ¢ØÁ•ËnéÃÛëÒBÓèU2&ù²YãÈg,‘‚¶lRÃGÏÅW›'äô[VmŠº²o#üºÞ¥yU^NóQ w>£§3Ž¼}˶[Kßê&q¬Ý~ÄÈURo ‡?GYׇFErªW‚æŠã1ÚÄŒWiµxe¤B:žD“ +TB} ¸²çÄ ùDœôª-­Öðw dyVeÉÖ¥Ó¤JúG°³IÝ™®´ahà¯:=di‰~ Çþf|hXظÉ BˆÑZÌgÑ6–¯C†Y´ÁÒ|g¬ÏR0¤–§Yz¤ËNœ0¦¸Ëòcéì{~ÿ̼7l¢!g:-f«ž‡lŠÒÕ3;fYî–3ç#‹dŸr•PÎm]%ò”úÒÄ=ŸÊb[WnuŸTmv£Ñ…( $’ÓÑ¥5],]–¡è‚‘Tœ†ûæntÑóhÜOÊ×`ìFˆØ°ÒðÁŒK”;H ,“tWä?—΂VÄ…æ Œ-0f`Q…ÇÆd¼—_f<žÞèOÖÆêD‡d¡N3lÚ‘@¥Ž¡“W‚ž¯Ô!ûxù”Î\AŒ9Š`¹g…~\Ôt9æxôSáSxRö’´W•.Œ­ªl½påuéŠâ BsM;S궱N Ç2¸9B.äö“,=R€eÏ!¥€R¢ÃòCÝoó|0´úè½\9¯í×¾¹Ðn†RÝwb=Ís“¼Â÷Œ™fÿNu <®W¹"&gŠÇ6Ö ½z,£×õ@¯q¦Î°ôH–m½B¯ÇiÔcù7éµéÞÂÂÛóÖYì¶ðNÈžÞ+!¡‹<ÎwÊj™!ŸëŒF C‰ ‡x¦¶kcRƒeiŠ¾Ð• ¦z£Ä¶\Š#"$>-—G +ÈÕ Š”’L±®`PµDÓú`f-tjg.lº‹6ùÖê2Y§\âƂœJ“u©o +€È½ÏóÕ½³?’〦_;BA¢ˆf>§y +®ÎÔ3”Ŭ!câõù£T )˳Æt–N ¡a´ˆd½©ÑŸŠnhºžn’ët=»Eõò#•ªŽ`›Ô§Ø¡=›r_xo¬Šžÿήû†©Ã¬€VKð?µÓ\ùhö´öC>3OpÖ¦84bu ±<2Öûzû~  ¤ˆüwJè)žQ +DpwE¼¹}óñÝŸðϧç6]—‹Cö䯑²<Ôã2ª…ó6õ¬\¼/E›ŽÖ4磋ϥú6Ö‰hç±L´ËÏÖšÍýF'ÜI !ÈiÁŠ)8Œ_긇™í„ô‹äkjW’ås’W6 Â ÓÁÂs]k¶ß:¤ëû¥»~;Slèwå>]dº™I—¡a1Å:6Ò• Ð-ƒ1ÚëyÜÔ"v¥£¿ +s? 6 +åÎÎ{ôòÆy½{2‰ŸÙÝh\-¿]Ù»à’æ•]°)€Åñ Ì7Å‘rk¬Ixê@YÜùÊ®dŽhæ¸Õ¹›=1æª3ou¸í]´#\³‹ÖÔJï™]‘™Ï϶ü¹[2ݱµ¾›Áãn—£Þi\Aø?íŒ-¤q_ôHÆ÷g]Ñß v<‘ ¦äi¡<ÎP¨Î}i Þ§ºBýzbZß½Ÿ9ÞZöî‘™Ž±dp·y"úä7_õÊ÷ŽGõû¨æ’ä8â4Ì ÄéèaB¦Ÿ¹topÆÒᘓ,CbF¡c<ÁÌ£ ˜õ†rÐ|â6³?ôõÝ!óc _jØÕƒFuURÁQf‹òD‰®›qÁȱB×W_°*¡œÍŸú’UhìÏM Ó#ØwÔ\õü׊rüS¦ïáäÈHƒÄ`ß +`'”Þ&dhîV†²ÿŠfendstream +endobj +2000 0 obj << +/Type /Page +/Contents 2001 0 R +/Resources 1999 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1998 0 R +>> endobj +2002 0 obj << +/D [2000 0 R /XYZ 56.6929 794.5015 null] +>> endobj +674 0 obj << +/D [2000 0 R /XYZ 56.6929 769.5949 null] +>> endobj +2003 0 obj << +/D [2000 0 R /XYZ 56.6929 747.9385 null] +>> endobj +2004 0 obj << +/D [2000 0 R /XYZ 56.6929 712.2038 null] +>> endobj +2005 0 obj << +/D [2000 0 R /XYZ 56.6929 645.6981 null] +>> endobj +2006 0 obj << +/D [2000 0 R /XYZ 56.6929 561.1687 null] +>> endobj +2007 0 obj << +/D [2000 0 R /XYZ 56.6929 455.008 null] +>> endobj +1999 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2010 0 obj << +/Length 2569 +/Filter /FlateDecode +>> +stream +xÚÅZ_oÜ6÷§p•®Êÿ"qOÎ%¸hÝ\ãÞÐöAÞ¥m%Zi»’âäÛß ‡Òjwåu{N°Èáp8ÎüfÈ Oüã‰Õ“N%¹S™f\'ËõKî`ìõ<‹i1åzq}öÝ?ež¸Ìa’ëÛ‰,›1kyr½ú5½xóæÕÕËËÿž/„fé‹ì|¡K¼¸úå⢽9w"½xýê-t•’˜²–^]üøêåùï×ߟ½ºÕ™ªÌ™D]þ8ûõw–¬@óïÏX&ÕÉtXÆÉúLi™i%å@©ÎÞžýk8 SçL „ÍŒ49´l&8ÈøËJ aç—e`Ï<3ÆœØÍc +6‡û¢œÁ1(“,Œ=¹HÈ„óÌi-ð„8×™*Or)3†48¡+4pàt™6ŠF–i)GŽŸÎ†§×ðW¤¯eJ¡mb`·Ž[\:ù#áSÎIbš´ÃVw&„ï.×"yÙÀ†’éžÁ‹‰ä°)#&^Ç5ìÏ2›ä  +”F•¯ïËÝ+O›MW65µ‰fÒuQÖÕ§8~ÇêÎo}ÛQ¯kèûâòê%ÍqDXùsÉÒçB§¾j6~—)ê5Ö2|¢I7žˆ[¿nιŽóVhC<ÿñh@ãf ¬¹M—÷E}çWÔ)kúô¹í»~멽õ•/ZR³Ã3Q.Go•ÉÄžç`ÒÝA´-vAò<÷_—á ØÜC‰yäaà¦èJfœvç×|xF.´çâ-ùµÖSgá™uZF¿þÛºø¸h›åûöÈ©µÉrÎL2]øH»‘kF?9]Õp0wû +^TUócoº°Knsu¬‹5ùËL`eÕ°rW–ö­ }a€¬0«U&%ØeÎ +Ë‘ cVäò]{äoüÀ\J~päÒe*‡xþóÎ;Ny UÎ3f{5ÔtNÿ™ÃGžé,Df¹Èøsø{°òrl‹ôõ£ˆ©…ÉÀD„L §Áä´ýdÊS9}3u®ÀNN1ÓÙfB»½oújEígðíëÚ/}Û€Yì€z‹À` :Ý}ä W\…Þºx‡Ze¦EF¡-‚i€³…b +ÔñãÀ,`Â<)%¬„jK)Fµ‘º$­±9Aìšq8rúú¶¯ˆrã—E"d {@j»ñËò7Æ„"iSUÇGÌÇYa¹‹}•©Zz x­¸L«r]vé¸+¤G¶^y²Xõ©¬ïh´ýÔv~M o.3¢^žó´£&š$®³õñ`⊭ïâR˜g ûpvRÌD% ±"E_uDX65Úã®ßžs GýqÍ×R›,q”ÝxØÓ)ήFéí2:Ŧk¶q6fÔíèP Æ0ùŽ‹x~l ¹€Ã.·M½öuGœÁ?`ð}’ðCMdM$·ýfƒN©X'Œkì<ðÖ¸b¿¾Á# JÜÎ3à$ªñÿ^F§ÎÿªéÂ1@ÁPµ ¶0TŠŽhñÐapÙõ¸%l<—kZ–S°Og ô&zsQaqäЧ*»®š ¢p¬õ|@©(RõÐòÔØ3…S 1Nç‰2OÀK³—sH|2Ï“Ú.Iù”G&(Æ<á ÅnõhÖQ£Á…°=u! +½…`yf•ÍÜ'øW(¦F¸ÂB«k‡Š«ódÆàSH꟪²¦Yå™™ê+×YJi°Ùôþ0Wg\¡Îêfê,—q({ãA®Ê­_‚Ý?%B•Ã (‡¦ËWY׌v{>¦$yÈò{êýã@2Zƒ H˜ù‚Ê2'场k@ÁÇZ:p·ä+ vC«`R – +¡#,×kº@§*ë@†Ø sîzªö[ IžÞôQÏÛ„ñ(ƒÚÅ +¥÷æJ`W3舅ß ‹áþÃbÄ1¾ïºð ûˆ×ë¥ßtÔ·V—ît@j3“›à.– ©†ätSÖ«S© +j½ËåtoÒøÙ×mE*ì]¨-½Žc#<>Ь&ÞÓ¸EÜÑæð©Óþ÷À¦ßböV2§÷’áF H”þR9\¯¯‹ÎÃõ—3–Ð(Hoô@„“×¾¨£Ôxé–æ±Ç@T0{ºÄe‚ï•8$s|ZÁ< nÊn¡á²ÂÞãq +GÏ.Ç^ eâN=íµÒ +;)PäP(aÏR•Ô¦A‘‰Œ[b@ÅVˆî:œe¤Ïp .Qn±ÙzI;wŸ ªÓ£_9°ÜÍònM¡>c˜8èÁ®lú–˜Ö‹Ô&3œP‡šëÊ¡8¢îqаøèÃâ ô·¾+ÊP^ !Ÿ{ÃáûNH¥'‹9™åÎ ÿñBi +âÏL _¹Tr •öt¥40…úph¨­3<™ˆ:Znà9^o4Îf6Ï÷×ûÙcÂ?‹ ×ä~ÛŽ×ã:>ªa;þž~÷±ìŽÎ6̓I‹Ÿ° 4v<'~¹"ž`–™Åd ù©Å–£ÅöÊBȘ̺ébÿ§Mnú²ŠMB½ð|ñ´Õân¬””³;aÉgÏþY÷ßTcżU$Ã_õB»p!•×Pj+ò9íÿ Ï'endstream +endobj +2009 0 obj << +/Type /Page +/Contents 2010 0 R +/Resources 2008 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1998 0 R +>> endobj +2011 0 obj << +/D [2009 0 R /XYZ 85.0394 794.5015 null] +>> endobj +2008 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F21 702 0 R /F55 1025 0 R /F53 1017 0 R /F63 1053 0 R /F41 925 0 R >> +/XObject << /Im2 1039 0 R /Im3 1162 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2014 0 obj << +/Length 1639 +/Filter /FlateDecode +>> +stream +xÚÅXKoÛ8¾ûWè(÷HìÉmu‘ºÙØÁ.Ðö Zt"¬-e-9iö×ïP¤Ù’Ý]`aÀ¢ÈáÌð›'E ?‰¤¦:ˆ5G,7#ÜÃÚÕˆxš¨!ŠºTo£³KiIe°Xux)„•"Á"ý¾E£1°Àál~ws>Ç<\\Œ#J9“áäææbv>ýÞb Ä8ü8™ÝM®ÝÜÍXÓpru1]|],Zµºª̬N>ÅA +'ø0ˆi%‚gxÁˆhMƒÍˆ †g¬™Yæ£ß[†Õzë\($(— +CŒ*6 A1!@s‚HÌh %C€5T°è»=èÙ¥JÀ0VZwK²L–&Zeksˆ ¡1¢´ê +î©×R èǺRE”i¹¯àu‘¤Î4iR%n´ÚŽ‰ +‹W½Ë$ÆHÆØêò$ˆ“²9e–W…ã^=7¨w»a±:XKÍ*Ù­+÷ò”™gë7è EÐdŒ5b’ÿ”×0Uû³ö (ÆH1}œ•Û†•ú ûŒ¢F·H2QÁºV!i!¨…IõbE©@‡eÖ<…䤶°‰iìñœŒ#IÃÛúÿ$œ¶c^õ’HChœYѸV&ø0Єn–¨;®ÿŠI=q6ݰༀ3ÝczÆQ—s}LI»ÎG’ ¸KÉ‘$®±xÈÊqÄDUVän¼îÊʽå…|3î¹+Mj3‹‚#û¥–K¾~ñ£•_É+³5Ž— ­ ÚÙ·ÓÙ¹i÷H͘Ÿ©ͺx4ÛÒh½¡µ¨›ä6TbnKþâ^¬^ö¹5›bL„çâ)‹­{.’ü¾™Ìr÷LÜcµ«vÛ–ÉÚ$¥±|zÞÎ¥FTit=ê—|”óI Ù6zM’¿?ûnO¨TÝdÙqû&[ +ͬ?°àùôj6¹ž$°†¹¨ §A*C—¨vU–7am—XWzevŸ'ëÒ-–Ånmm@½[ÙÉo~§u+7ª<—E^9k·Çe'XÉ“)ÍöÉlóºv ƒ„SÅ}¤nót9p"JH6™ôUµ¾FÖ‹ËÊ$iÏ#šÊ$˜•|O–¯.ÕñòÕRyƒ¼¿»9«c„5!§Å6Db÷ª¦Ç”ï˽,jà—¾øºTÏA|6«W5œMlOr*#†ô¯Pu¨N@ÕPy¨¦³…-Soœ20±¸¸ýØ+êò¼ŠùiMZªUöà¶%Dã¾.;_:Óâ9? XŠCÐ…¸ÐħfÓ½l‹qziò4Ëï½ò¿ +b¶ž  =+½Ö¢gžh—§æ Æ47ÎÕs$&‘Š†ï>Í.§Ww·‹ùbúiöã´aÕW¢ÁœV]$ÚØNX1Ž0‘´é|ŠÜjz¿sÙªf¡YÛ*…¹+I0W…,‹ÍãÚ|w«•ŸLM¹Üfßš=y3[%ÙÚ-œÖPñxŒmÙ·”ŽYeº\_qÂyøèÒWäì =nl»[Òž²ÔøhÊ:ŽRêEÇçâ’0|W@-µvIºÉò¬¬ŽÂ[õÖ¬¼îyÇ“|—¬À%RÙf±É†ƒÖ‡L ±Þó‚ËéõÀeÂÇ1cÅ®õQ_\ „zCdEž™jyV» 7Xõ\"h6â“Ò[¢žøƒð&ˆ1µ'~1Ø#÷ÒN:‡<š ™m›û>ª5T5BOÉöl»ËJ«Ç,=T„bh"ק5i©úªìWT,a’íë2 —Œ¥)Ë(K{hõ|pÈœñ=ß›_\xï¿žˆ™ƒìs{ùnC¸ß² àp·â²ÉCoÚû:#ž ËŽÿ·ìÄO°³P—,#¸Æ-ÿ²¡ð ¬àô—ÿ)rs¸l;£Ã¹õ³/8é 3Ôˆn¥¨ˆ0(‰\$ºÿ%cµD]¯™Ü-Þºý™®.¹ñ;pã å»"/‹m•í6¯b9b\6e’CSE9m¿Ù€e1Æa^îášošË ƒ¤î:ï€{D% Môgumlö»xÖÔÎ_À8ÙÒ¿Ì澜wh¡E_gÕ˱¯>µ"ƒ__p è/zýòÅ¡WRêÈwè…l–Röà„ò~ň2@¼¯û¿C¤•endstream +endobj +2013 0 obj << +/Type /Page +/Contents 2014 0 R +/Resources 2012 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1998 0 R +>> endobj +2015 0 obj << +/D [2013 0 R /XYZ 56.6929 794.5015 null] +>> endobj +2016 0 obj << +/D [2013 0 R /XYZ 56.6929 586.3808 null] +>> endobj +2017 0 obj << +/D [2013 0 R /XYZ 56.6929 444.5078 null] +>> endobj +2018 0 obj << +/D [2013 0 R /XYZ 56.6929 369.9671 null] +>> endobj +2019 0 obj << +/D [2013 0 R /XYZ 56.6929 265.0122 null] +>> endobj +2020 0 obj << +/D [2013 0 R /XYZ 56.6929 190.4715 null] +>> endobj +678 0 obj << +/D [2013 0 R /XYZ 56.6929 151.8306 null] +>> endobj +2021 0 obj << +/D [2013 0 R /XYZ 56.6929 115.5088 null] +>> endobj +2022 0 obj << +/D [2013 0 R /XYZ 56.6929 83.5219 null] +>> endobj +2012 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F53 1017 0 R /F62 1050 0 R /F39 885 0 R /F48 940 0 R >> +/XObject << /Im3 1162 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2025 0 obj << +/Length 3855 +/Filter /FlateDecode +>> +stream +xÚ¥]sÛ6òÝ¿Âo•§ƒ$ûæÆI›ë%õÅÎô®i(‘¶9‘HW¤ìº½þ÷ÛÅ.@‚¦gn4#‚øX,ö{”Ç~ò8K"¡óø8Íã(29^oÄñ5Œýp$yÎÒMZŽg}yôü•Nó(7Ê_^`e‘È2y|Y~XœžŸ¿|{öúß'K•ˆÅ÷ÑÉ2bñæôíûÓRßùI®§?¼¼€Wk“¤ÀyF,Þ^¼??;=IãÅåË“—ÿ8zyéÑ£.…Fœ~?úðQ—p‚‰HçYr|/"’y®Ž·Gq¢£$ÖÚõlŽ.ŽþåŽFíÒ9R$:‹’L¥3´PòXÊ(O#É#£•¶Ä¸xhÚÛ®î¦G1€ ©ÖQjÐÌÖ­’Ú³,‘H€äË1‹V,çXäf!VM·¿-‹¾:Y`͇eùѵÎ|ëQ~þ*Ñ#`R§QœÅˆ‚ùp³-Öß}üT=4Ŷú®«Ö»ª§eRK œÉyÙi‹å§™TeYêfä«zSÍ€Œe”ÅZòiæø1¨~ì%k©¤X컪¤VßÒ³Û¯¶uOí3”ÏzÍ/o/¨ñžUÛ»™-ªß÷U×3Ä‚Ÿeõ›ªqà놞ï^½PR›pÏ‚HF¢ÚÝU;4f`ÝTž..oÈ/Ý9X€H/‹Í¦½Çf”ºvoëjÜ»ní³´ScÚW<©(K‹/4a¢Bë¶í¸²=í–WÐã϶©hþ}Ýß ÛîmÑìµz«Êº¯›kzéox[ªH¯MÖ`êOíiE¨',ßTä œ!Âöˆ Ô±.n´M_ÔÍ£iõXÀN {l?Mï["¿õ7>!ïT÷½Žê‘?xCâý+@d´²P{jn3|Ù7%ˆ‚m–NñF¼ØPÇ]]ÌhˆÌÀ«HcXð?§!I¤bá´·å= zœýøâœZ,›Ô^oJj7-c¿bÄ‘ß®è „c2,•Ž£,1YÈâ7Vdˆz s|´û0KARt½f^£ÄQË“g^»:ÁçÙE_„R°â‘MÛõs¼ºD™ÕI>Ãì¡w¤bØÉL…ÖÀTxaTI9´NõpÌRÞÃcÕÃ{ÒÇÖ‹ÌÄOâ°Q¹s%7ÅcƒÀçŠßQayîèÐ2Y®nFJš‰C%FÅéâÝ `±­b ’ÓôÔm)ŽÏBßðšmÑõ(`Ø !‚·†ÐÑS.êÀÖh<¬‰‚6aèjñæíé›—Ô´ó¬(Á„ö*@C94ÓCöâçÓ§ª4ŠÉL,ƒMíÔpYΰG¢Jçh[ˆ Zd„óS|r^<`½Ñ‘ÉÓìIœ×:@W;k<vÍ{”ÕjÍÛµ%²3‰s¦7vÞ’±¹zsO¿+ÖÖ ˜«v·-gò¾²~ÀN¼aéÏ…GŒ'áϼ)ï¼±eM/Æ6x[”ÕD¹‰Èí¦vúÏL«jrcÐ3rcã•ì‚“Ð¥ñAèòlŽÇqÇ>îr<¦ూœåIÚ f V4Ó ÝõÞÅÕ¸™3®–Ý×ä“ ûØ(ÎPC¬+>/ÅÌYšÂÆ^dzŽ4$âI.0žìŠ5‹MF¢¾nŠ~Ï&–ú¬;dž5P𤰠[ÖtÁ³ØÁ¬I®sÖ~lø(ξ`gA1‡ ùÙ °'./^ÿ0ŽÌ¹31Ô×?Üò((ÏzW¯* KklX˜Å ½0Îüšìÿ›€dþäáMƒÖ‰¶ SÒ·aéÕœ­³ç]J89mCz$s w¨¿ GwÃ*YÒ0&rö½§qR]šIœ€ Ó“ÌN|~jÚû†Ø* ¥"}J £áNöìa¥ã$B'õ¶…¶X¼Øï÷¦ô¤”‹g0 ô`¼´‘Ir +;†ÌáÕˆán³Þ=°~ã{±¹nwàÁ·ø/®ËØ鶴­GÃçoN_,ßœ%dqS¯o£äÂvóÀTj@ÛsÉÅÏͺ¢[8ÉnNŽ=fh-Ó±ÓNƒ­pÌ¢ýˆö3ž ¦vmmGGƒ÷õfCcME+5ù|è©€}ã «éªMe£ºÔåœLõí®&/‘Ži9#¾˜ic÷"¡Mê{H¡ ãSõÀsÀhPkd@ȧÁ´ª@Âã(ÑŽ¤d`ñÊê(L©›®/€ÄÏÐT$ u_¬6­âmœÚAž¡öÕöìæ˜rϯ&5Á§KÏ´š·ÎYå:sÒÿ¼ê×ÏQàËBæ«eÉa;“òô®¥MØÝj>Áfìµ×Û¦ Ñêºvͼ–ÉÎi˜œ„$¢Ð 5QŽÅƒP4­oùX{0Aæ _pŒŠ×çœL—%æŽl”çgÂŒ54‰"ÜAvݬ¢w{X!Sµ€ü%t‘ÖZ#ÁiÎ׋=#£àd;˜ÛýjcsÐP+/Øi-G{½+noÈXHúÑcªEKs(‘U½‡N{2 v„Îl™¸-ãÅvo“gèZñ´®o½uÇ6†~Þ輪ÿ¡þ©/ÂÁaîŒhÿé³f+O‘Ù¨ýI±Ø4ÃÅ’Hö$ïDHeëÂC›ºqbQÎ(„aà²'+¦ÝF§ã0h‚7E"ŠS‘AÑ—ôØ—÷º¡p0Œê<Ší.T{˜O8dì ×îæ">˜¥®¸éJ¯ŸƒâÒE‰µVrœ: Û‘qAÅ…Á<à8º7FÐÄâºj\ú¢¤«O>bÇ£ÐF¯èl@h•F‰N'éëÔöCŽ<ªýá‹­ýAç*y¤*¨b ieuUì7=SЇ-çÐQ‹“Ì›8BÔêèeð»ð²Ý÷T;›±Õë Ø¢;›s§rñËI*g-bzH28¸ùgG&ö¼&ÔžÍâH ¥ÔÏë[Ç2ÈH +[|Lž§"•ÊÐE¤Aª6^Få¹Ë¼#Q*ž» Ñ +÷6˜Áh«íx6@€’+¾‚wr9ñQè_´RN¨mŒ´«ŽC²žå΂üô‚ÿ;úV&iôí_TVÿ;_y7OL™æ‘ ½EY&Êp ›BžöKJôÎÔî@ºP8c1à7¦\¨ì±Š2™Æs(2Ò$Êtœ†Ðgw>µ…xJG`ÉÓè twƒQ•»ÌYŠ ++E˜™‰xñ Eh™< ×2‘‘^Ù¹4ÑÓ¤aÚâì %)–ÖâH‡Ž'Ko€JZëå“Êš±µåI¨±æîU"-=;íØ êö^k¸¦ù”ðFc‹6€«OçÝ¥Jrt!ac()‡j[(™Û8mF%ämJ9 ßóxè›ê«¢«LLUµËÀ{t‚uO±Þx{‚:ü{o3|®ÿ9͘±˜ ëÞ­’+=5˜ÑŠ +ìPÖݺÝïŠk+,1Ö˜¹­]{7‡&p SL^–Mkb*ÑÃàºÝn)Ñ€¾MÝpÚšg`6ÀÊ…Ï‚¿Þo)V)Elð\oª#|•-úêÞ–]•+»Âø¶x ÑÕ‰´¾ +šwuWÛ¤g ˆØvßßÚ!˜9²å0rÛaÄ*9bÅ©»1ŒÌ†šðJ¶í^Øz12µ½ß±ï+ÆÍåì£nØÂÈo8ðën GüªúžH¼?äCµN]ØGÄÒ9[:lQ2—»›Ç˜¯ §»­Öõ•[@IP=°tî„50=1Ú1zÄè0ˆ±¼6‹× k˜–Èz˜Ä)ˆúÓâ5‰£ðû³sjX‚ÚhÔ¦ŸjtÛ¨•¨ý|g•F·eH³¡¤”"`>ÎõYH¼õ†5´ +1B’ö¬×àTÍÄÔ‘Þ°ôøå“ R•û‰\[ÂÉÈOê¼|ÁË8VNjé¾ÜŠ‰> " +\J*¹›×==­Ã6kà22¹ÖOâ¬ÖF¬ èá9[S­)_çk-åY–N +¡^ØI‘Gw„¨\A °rWÒTL²ÂÍ“‹~Íw“Ö¾¶îB-Á˯3KÊ×}–ý³$ÌÔS³@@íæÚ¸ÂÝÿ¨·û-÷Ö[î.xÅ`>ÌD° cífõÀJj­ª«áöÞkžj«¼(ª)[ŸK‡ÅKù¹f¡…Œ“ž~Gn³mJkÇ Tøµ"g3ù$ÀqíçèþœõÀLoÓøËœ¯`G†AH÷óìBÄSvˆÄ±C8v@i148$°ŽP`¥ãRl"*µáĘp8©£§và…T–þŠzÿdJÙ`.vv;\Wã +D_xîÉ}þ{6÷¹ß=ùmÆ×yÍ~»ªv¡ú-¼îد›¾JQTª|H·›çL’ˆi1Cá8cœ™7# ß%‡¡‘!†6@#™q™À°ÎC§æY–)ð>f +~ÓÐw4’¿91#[âwsŠh|õÒØò±S™LéIòúÕ–Ff¾†0÷±˜„P¿OœýX, 4ä”änBÕ(x訣àþàëÅB¡x—|«Õü”H˜¸{}œi/¼ù²=t}µ¥¶«*š¨ \E®Vf&× 3ôI!®p²óŽýœP›9½É"!39úØãW` ¤ÿÊ3”»ÚÞ- …uÛëÄ–DÁúŠ& D᚟a­ÚÂ×ja&Äx³…›UÅÍϱs©ó> endobj +2026 0 obj << +/D [2024 0 R /XYZ 85.0394 794.5015 null] +>> endobj +2027 0 obj << +/D [2024 0 R /XYZ 85.0394 749.1471 null] +>> endobj +2028 0 obj << +/D [2024 0 R /XYZ 85.0394 677.0612 null] +>> endobj +2023 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F53 1017 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2031 0 obj << +/Length 3132 +/Filter /FlateDecode +>> +stream +xÚÅ]sã¶ñÝ¿Bo•gÎ >I oÎÄÉ\§ç\Ͼig’{ $êÌž$*"uç×w € EÉ—¤ÓŽgLp±X,ö{Añƒ?>Óy–[ag…U™f\Ï–Û+6ûs?\qsnR¬o¯¾ù^3›Ù\ä³ÇuBËdÌ>{\ý4ÿ6ã,»l~ÿðþíw·×…š?Þ]ß¡d>¿}ûöîþ»×ÿ‚wÍ0›¿¹½ûw‚½½¶b~ûÃÝÃõ‡Ç¿]Ý=F¶RÖ9“ÈÓ/W?}`³œàoW,“ÖèÙxa·V̶WJËL+)dsõpõH0™uK'E§2²rJÚf¹„)”ÅãSgbjÞî«e]nðEÏ?—›c…‡ûæ{ÅE‘‰V2·öSõ¼hÊÊ{)›](XïVõ²ìª–¶êžÊŽöñ®¹™¯h®Þí~²}jŽ^x.mµ…«óº%ÄfßÕÍŽ¶å3é¹~fLTŽÏÙ Eƹ-`Ä3«µp,n›®Þo*RpWo«6óçⳈ¸†ÝH8¦•Æ-{}ÿöý#­ùþÇwonÑ0ãº^° ¶eF[·l×÷+È”äT&„.¼äœhªr…'…Q ×nªÙ ’(t¦-÷Öõ¦Ú•ÛjZIÖª Íæ@„ۮܭz„]AêÜà®\>tÙl·€éQ<ƒp®ý¦®<Ô)ðk¹ì6¨nXtSï*¯’Ì…ó òÒf ; +w×BÏ8ˆƒúÝ[z#vÝŸ¯ñ$ºÚÖ»ºíeWöëöÇþiQ¹Ž 3„7ÝSuh‰@BMÌ«ghì•æÙÂ×f~\¢ñµî lhSŽÎç{¢Gÿ9Ömíˆp6_>UËO-a¡°ðÙ=…Éf×U».L¯GÓ¿ á +-î©j+šN)¶U)­jbÓÓ(;Bg#´Ó¡_>u*`DäÒ›fÛÝ`‰JÍ•‡.²Ÿ–Pfš½{ô`À ÄêÆ¿‚’ZZßxXí—–‹d@sÑäÝŒ¼ $ø BÓ3ãûöØz2 ±­:¿×š&âàÀdˆ°,BX­ÇA§•#n=ßðìz¶Çå²r1KI;ï–z”/õfC£Å€Ú¿«eç<ÈzÖl8,* &§ giL¨t]Ö›,NXH5 `âîsu·•EÞÛ~Q O“@¾%â´3UxþV]sÄ¡9Ë‚‰m=  S\{J.¾ Îo4Ýø MéžCôìÜXŸ‘ͦù2yîè¨îÊÅÆ,îò•cÂZBv1>;i'è j›õš¼áFI.Jˆ¥>„ N|Qû ÷ªÈ5p àNXî¶nÛz÷LÀ˜Ô{àl!Œ@0¼%ÈbSî>Ñ0ä㣵¡7;ÓódN³"“*Ï}f6§j¡2¥l¨|@÷H/KHöíˆÛr¹Šr™DQ®‚ÀpXîhAå_&V4 “Fœå4¹;‚.ž æ;GØêÖv*¹Ë=. Î‡#bÈÒ1Çs®Ïãx&È¢¢'z(¥BV~òs§iwIE3Ìõu«£OèíKzG1äÖíš~ÊC¼Ÿã¸£;Äà¸" IŽÆ>/¸º«­?îb)y6L@iüÜ…f)Öù0±B&¤íq"ù 4¼¹3—YH, 8ŒP µQj®áŽYúj +¹î-_úÒ‘›´7×`«ÁLÈ5€â;-$‡òD„ž#ÄØ (Y‘„ íSPîRÐm›Á›žv­BuÔccŒÆI;44—[ U})²€Î¹ˆÝÔå»C+cÙé 6(;`fßÑ˪‚jeë»9Z+;¨ºÀ[â4ôŒ±Æ‹²¥ÌÒ5_Jʇ'OÇ¥T?MIñŒéQN÷×|ç\‡ËŒ©^pë‚ë,¸6eHªnxÖyDa/s±&Ø8qfÅç>®´<[¹8þ2º­{íË”IsåRfÖê`¯tÄSkÁ¼W˜|PO~}•®n'™€V\ë`Œ¯ï'8úžxFùÂ@‚—:¿¬üë¼ò#–»è6¡YÅ ²öDñ r5ã—H ÏÊ ‘Ѐƒ^í¡ÅÄA/h„Ö[vnÏ»ÍÆÔbľ5½vMð~=äæäëIuò©góŒêÓûîLÈÓ ?1 7@r¹©ÊÙ#ù’ËBŸ>®êAçM@B1*Å vŠuÁ–ÿ†uzm³<ÐÕ÷0ØŒ[ö+k‚—¡w(¨ùˆ™a5,äPŠmÃ’jÒëão¢Œ¿ç‚çãÃën°2¡8Ý߆õ÷vCk ÈÆKVÀK/˜ñi   ÁB¾/ëäÖëF1 –ÏFUÖãäÍ!ñå…é˜Ú ÈY#‡÷†¾ú‚Föi4^ŸyåF-n`©^¹=é £Ïu9ñ=}Y«ØIßL²‹×œñ‚§9L¹˜<†Ê›O5Fœ‹¬-½:éûäSé_âÓ‘šC2k;¹‚˜[9iPãï6¯|ƒ©Yf¬(&>¢¦ +í ¿}œ×¾/),Aý Öý¬SÏ>Úª;Õ?Ý:¹šïCÏð‰Y`^gyq™Ùˆ5Áíø]3ävhÐô…)ýEäS_¦#4¹ÛXüò,é;Ñó F¿9é7-^…ˆÄ1>Tâœ×~5u墠qä*çCùº¢½ÜM±†™ PþŽØ£“f˜º‹ ª*+”ÊÿPSÑlkhACC½€{¢ÛÕ;èFwñ—É+Ð?n/\ºâo‘ŠüHλC@: ‡Ò ÈÖ9H§¬}A‚ôœÒnÅúo’½_(üçË-u‹Ú».EWÀ9ç +8xÁú¾øï¹ÿߺ‚É ä„"Öÿ^DûÄÉ30YýÿwŒp¿¡3üÅà„µ±XFþé&ö?ÀTømölr/ EÄÞž)<;ù©OûŸ0žòþ +¦ˆæendstream +endobj +2030 0 obj << +/Type /Page +/Contents 2031 0 R +/Resources 2029 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 1998 0 R +>> endobj +2032 0 obj << +/D [2030 0 R /XYZ 56.6929 794.5015 null] +>> endobj +2033 0 obj << +/D [2030 0 R /XYZ 56.6929 699.775 null] +>> endobj +2029 0 obj << +/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2036 0 obj << +/Length 2472 +/Filter /FlateDecode +>> +stream +xÚ­YQoã8~ï¯p—­dI¶ür@v¦3˜½™¢×f=ÌöÁMÔÆÇÎÄNÓÞ¯?J”Ûq’ÝÛCZ¦h’"©”ÂFþØHIBy*FI*ˆ¤LŽë+:z†¹OWÌñL=Ó´Íõóüê§<¥$£x4jÉR„*ÅFóå·ñìööúæÃçß&ÓHÒñÏd2•”Ž¿În~}AÚí$ƳO×÷𠣆/¦ã›û_o?Ì&‰ϯ'ó_®®çÁ¬¶éŒrcÓ«ot´„ürE O•íá…–¦Ñh}%$'Rpî)ÅÕýÕ¿‚ÀÖ¬ýtÈB*"#¦R’XñtØa”P ˜&\Å’88,bCó\Æa›­Þêèš·×í¶Ö ¾,«u–—Ó2[k$|[Y]?àKó¶qäeÖd„¾»¢4&‚K6jÛtdyà0·Lç”Áâžíó•6jú(Û¼x›¥ (0<ÆXëa²”Bʾáà8@ªûƬu(Ñ™Õ"Ѷ^†ÛÈ ØÂ,Q7òŸŸ†Ð²^]Øê1‰÷[}xs²”°øb鳂¼­¦XEœ¹ÊV½äK½|gH²¥C3iÁáf?gÇÎx4ÞçEÓ¶uõ¢—Ä@¡°@`§ò²ÑÛÒb,¼¬²™.!ºˆn ‡ô®‰ }ɇœ+aH…º€]< ÖK/+×ջͦÈÑhFO WJIDi(ÒM1ä~JDÔu¿1ü¹DÏ¡÷ͺJ¿&ÇâÂa¦Š¢Úû%C‘ÄÔÐ €Öc^äÍÛ„‚ŸÆh§¤H.ÀÊé ª8¦>¨dËå D1^ùûÉ8ò¬íéØø~7'Ru¬Ÿ-MÒò› x”zor ßÍt7ß‘¶Ï›Žl©0ƒz£ùï”Fƒ 1hÈ?Ÿ1,!)½ê»Á¢ ›š™cBiÎgz| I¸Lø$é´›'³Mʘ¨(:Ÿm-¦ÓÙæ™°{®ö}Œš™s*ӱΎ˜ <†S[[釼ÞÙ›Ù‘Iìú,v[L‡²AÂZ×uö¬ÍVVv&´y‰ +³™ÅÏ A'Îö#‹0Àmæ¨íôBB^.ôA*"ƒ8½2¹á‘M—ËÓ±c¦è^@ŠÓ™Ø9&ìÆ1麱ƒ½Ë”8«20ëìÆöu +³m¥÷ ÔA)úÛ`f'p@p (ðÙ=MP^²"𛣊¥›Ú…6è‡Ç"+¿ã°€ÓÍI'‹22J.ì6×i7.ÜÛõ’©ïi”XÅÉy½k@qÇ×QDâXu·öIÛÝ΀ÅÓ¾€¦IBµ¿à‹×_x.‹aúq÷|ì +{›ñój×€ÞnÚ)¢( uGñ|]æn[ú*î»n0ç2Æ5‹œ“$†ön +ý2Pn>ýYã|ø¨¹ †•¦•kµ^狪ðâ§"ì Ö u¯±èð´â Þ¸ÇÆ8M.t7Ʋëßf_o¿\ßTjê0áî/i, +Âñz½)ìzTë',’[¢ƒô^8™ˆLÿç `Y»FãX5X:½jW,Q…í>AÁ®ÖŽb7.Pò²ÖÛiè„#0 õø@· ¬‡k$«ÁÃ/S œ#Ùí_;ÈÂòC›a. î¨x|S59¢¸¹OÊ?r¤¼Üì\¡±g\ á•¡\|q•§Æ·ÌÉÙfÐ#úbäA +& HᨮúÊ3ä~Æ%î6vi´[Sl9sù–°í¤Y3 m­oüÞ IÌøÒî%}5Ôut®¬¡˜i×:M싧†.¹åv—ç‚u“Ú£$N•]Ñß&ÐIÒNÊõýdñ›±O3®ŠåªªÒ ·™˜u…±SÂl'mÐûaI*”z¡öÁ’‚„vÆb_„·oÛ³Ò^ˆq#Ú<ŽŸÓ½kfWk&·}Ôo/s”± KÇS¶4EÇ 6LEƒÎ0ýù6LÜŽvù×òU§Òc紇ɥ÷ÅÛÔNµsó`¤¡­|j;hfþ`ãŽoó¹û)âw*© æ+l×e TöMMÅoÙ_ñ@æÞòÅw³_:nü³i9$£Ÿ—ïof_¯]ÚUk}º¿š¥ós t€Âeîîô é¦ßÅ;ä0ðç‘ÃLW®Ç_éÅwÿE ’º™½ýRº +H8T¶ Hë<`ﱬ&wÔwŽƒ35è}“´\˜‹&`I;6ÂÎFs4‰„ªàª>àªñŒÚŠ•N¬r¿sXâÂ:*íi•ûÔÞŒ;e„É0f¸*{Ð]ÊZ ê°e¾'W¦ç®wιHpqÑ~¥»—¿!ÄÚ3š +*Y‰¶›qUÂÑŠç /›.E7ÁÐp=Oí½²)¨‘ÚNÀ·…½€T¶Z³4ß}|Ï(HD« 9CúÓð· K«õ'Ò²Ú}†·žP–m¨-­KV‘½c1³ù“³§-´îIÅWë6‚cƒWv§¡†Ö ä ,þQÛ0pæÒË$÷Ũnîï¯ßûÛ?œßD’K$ÚÍÇÝ’¬Auwz•½¸;Ä»»ûÏŸÞéÿ¼þ·`[; Þ…½H îžúÑ—Kb~©8ÐÐ$ÿå„?|‹„p¥¢S·W‚pž2o”q4‹’¾é’+"FŽmÿ/Ö°Ö·endstream +endobj +2035 0 obj << +/Type /Page +/Contents 2036 0 R +/Resources 2034 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 2039 0 R +>> endobj +2037 0 obj << +/D [2035 0 R /XYZ 85.0394 794.5015 null] +>> endobj +2038 0 obj << +/D [2035 0 R /XYZ 85.0394 372.4169 null] +>> endobj +2034 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F53 1017 0 R /F41 925 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2042 0 obj << +/Length 2188 +/Filter /FlateDecode +>> +stream +xÚíY[oÛ:~ϯðÛ:85Ë»¨Ç´I»>Û¦Ù&],ÐöA±e[¨,ùXR‚üûrHY’e§Ày]o£ápøÍf +l¢4Ñ1'Q,‰¢LMÛ :YÃÚÇ æifhÖ¥z÷pñöƒˆ&1‰5ד‡U‡—!Ô6yX~Ÿ¾#Œ‘K`A§_o¯ß_θ4±œ^ÝÝÝÜ^Ïÿ cE((~¾ºývõ çî.c>½úxsùóáÏ‹›‡Vœ®ÈŒ ++Ë_ßÒÉ$ÿó‚5y†%,Žùd{!• J +fò‹û‹· ;«îÓQ0J¸Ð|DœMàˆ±R¼§-¸pJø0ÿ4rF"Æô$âŒhÅ͉}‘hÖ¥rÛJ3¦ú@ew}›Ö‹·û´*ó'²(‹ÕP¦8BŠó´TÇ"Àé"0Á”îËÐTéï³.±Í–iQg«-ÓUÒä5Šd›b¯J÷Oéþ”ÆtÌåQt^c]ªÓk©¬´ÿ²;¾ýÀd—ÄQ¤·%X!A“$±a¸#3á‚ÄŒJO´~ ùÃjóF’#û]qöI±,·#|„"F+õš@Abò+}Þ§†0®Øùëh©Žï£ÎX³–ý yLªt¦%‚"-å2+Ö8*WØþóóÕûÙçk…#+§ë,ö—ÌLÓ¤ø{ ˆ+ª*]Ì€p?¨¢þ‹:…5M‰y^ÁZ‡ê ÖÕÿ±vk»}ö÷v„7Á Jž¿’–êøNúx¡L›þ¥´xcqovdñfÛÞìÈáÍvzx³~á Þ†±cÆ „ . Ò‚t*k°BÝßÜ t¯>ÝñßuBáÔlFb°ùúá=“~ƒßÀHPF°Ñ©#§Ý5%:k<ìÍÁO/Û£¼yÕ®†ç¤ýó½ûöñþõc=lll€œàá~þÑö˜7vèd.á,›b™uôóH”ØÖ—lú\b¿JwÉÞbÎ~PÊó–+ÈK¤P°wØ[6MpaµJÿj))Î;¯ EÕì–ž!ƒ(ˆnËîºqÀ¶§k5§»¾@5æÙã>Ù{_µÉ1hÖUpk/»º\ï“Ý&[xG¸KAô $ñ7vˆmœá&)Ö>´ºã[ÞMÝ ^pŒý< ¨:·&‰:Üšä$â±j;@8…´m_,áP`ìdQŽä¶uPG“Hs<ºûÚ‰ðƒóèD&€Ç(‹Ú‰Yæ8ÑÔYžÕ/g1†ÒÞ¿宂Û8Üh12&’åø¢ƒ-@ÿl è²ÀÀFb@Ku8º~Ÿ=â)TWS˜B2lU6ûE:K–KHê*ïF»{A´ËBòŸób„sß'Ûì0[ÏVYžŽ°Õp¥JÈ!Û_¯²û<ÅSFÄp yV¯ò;<ÐHKœÉÂr?ñn~{í-L‰R”÷Ü÷áºÌt¾^QÈìxþ”Æ&(ãž‘žÊ_!’>gõ§‹2ÄCĆ›Ì³ÂÔrçâN»˜mâ¤]7[¨mèØ×ø¤€Eíélª5OŒÖ ìâb¤e·BD +tªƒBðõQaÃH³³æŠ/g5˜-yò”dyò˜§!ÄùÔ™L½³q[4è8>«r8kj+dSd H#`k)¯pÛs’ŠH{@Û©)m¿l{ 6ïï,§HuÙMY€Ö%àËó\KyPû¼ ^_¸Ä¡ç…ì!/@AN—Ù:« c)[IÈ3$¥˜Î ¤DmÕ¢Ù#EQã +H_À(ÃCû‡À–¯bXRÚõZ]HL§¢ZŽ°”ÄqëVu_‚1Õ”=”Å=åYä Wi3Žžú’|]îA…[`­…³6Û†ZÃîiä3ä|\iªÔÓ$ØT›¤ÍrÝ8õIcëm›&EZ8Ré\¤@LA'`¤,àÆ´Œ}þk—:Nªêç±hp69ŸUõKîX™¡ +ÜœËj…ŽÂ†æà6ìņ¤ºª=°ÒÒ{Ðë¨=¸ñTÝï«MÍ­üp«<ïmT¥àÂÏš{›q¶ÁfÐEêÓÎmSyÊÇà^çdžäð"1¬dUL”Ž#€O±¿û[Ž³.Ë‘ªWCUÀº%ó±E-Êç¢ÿZwp pylC6:Ù,Mÿž›³g‰Cžê gtÆèî•«¬l¶nÚ`k¾0s(¡˜.Ó:Ýo1ÔÀô¦|Æy\wŒêdQûÉ' †è<¸vËtÇþ3†j»ÜZ)š²?Fß’Cth_¢2`Mî Í×+ã/.g:ýriöÊÃñ(z2},]°îš÷üîIÒ˜ÒžIGŽä  ÿV0öû Ôm¶¹|ÚBþoÿvsømJÚû4ü„ß‹Dp[ó PVÍŒ›cÃò¿òËþ?ƒü¨Jendstream +endobj +2041 0 obj << +/Type /Page +/Contents 2042 0 R +/Resources 2040 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 2039 0 R +>> endobj +2043 0 obj << +/D [2041 0 R /XYZ 56.6929 794.5015 null] +>> endobj +2044 0 obj << +/D [2041 0 R /XYZ 56.6929 752.0628 null] +>> endobj +2045 0 obj << +/D [2041 0 R /XYZ 56.6929 615.2568 null] +>> endobj +2046 0 obj << +/D [2041 0 R /XYZ 56.6929 551.6561 null] +>> endobj +682 0 obj << +/D [2041 0 R /XYZ 56.6929 500.3546 null] +>> endobj +2047 0 obj << +/D [2041 0 R /XYZ 56.6929 467.1661 null] +>> endobj +2048 0 obj << +/D [2041 0 R /XYZ 56.6929 431.4263 null] +>> endobj +2049 0 obj << +/D [2041 0 R /XYZ 56.6929 364.9038 null] +>> endobj +2050 0 obj << +/D [2041 0 R /XYZ 56.6929 292.3128 null] +>> endobj +2051 0 obj << +/D [2041 0 R /XYZ 56.6929 107.6861 null] +>> endobj +2040 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F48 940 0 R /F23 726 0 R /F14 729 0 R /F41 925 0 R /F53 1017 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2054 0 obj << +/Length 2477 +/Filter /FlateDecode +>> +stream +xÚ­Y[oÛ:~ϯðÛ:@Äò.ò1mÓ³9hÓnã.8=Š-ÇBm)kÉÉæßïŒHên»§SÃ9œë7›Qøc3£VÎb+‰¢LÍ–» :{„¹ß.˜ç‰SÔåz»¸xóAÄ3K¬æz¶XwÖ2„Ãf‹Õóë/_nîÞßþç2âŠÎß’ËHQ:ÿt}÷íú££}¹´|~ýÛÍ=´@”&þï3YÔ( Ôr›@À»q­Yøuš…Añ„J+ÝC× 8·n™Ç +ägTÈa(â6äû¦ÂÕ›4 cŸª`ôà)˜ªŽÇ34eµ9Ï®ñ¸êx~:[@ŸŠ}5ŠfðIë¤\iB®^,s…G»OÑqj«¶ùMT¸ßÅ»/nÄfn‰€Š<8ÄÐjšHòt[:;.ñööî½Ùx¼ëéòªN…·çr“äyºm…»ò¯CÕ;f^ƒ÷p+N›·Ëuܼ WmÞ·´8)$Γ[¦‰-{:¦“íoy“'ÁË!2Š‘Ûâñ1Ë+ArkvÆÇ»\'”¸j%¼Nû¸hsžG=g +sÌ{rk @àËdû5+Ž1 ÕýCd«q Zb4ã§×pMh®_Q%+Wý]¿ÕÆÓ>eã Áa½hS´IÕqmr +x‘ õë´Ù¬8¡Í^ˆ:‰)œuB#O”Õo¯]Xï +§v ºÔN&ó'‚Ùø¸j4‘Ð>È_§šfÅ3ªÚÚ2]5»Öm<øCp‹¼xñºÀú͵%I/YµiÕXu„ȱÙ{ø¦tHL©y²},öðÚÎ?ºj †,2«üsµ‡¤âÆ®æKDqÀ±r°@Õ°¨ rµšïß%~Ççd›­šr­|¥ËeŠµ9ÜÁ"¤,šºšQ„iÎ蘅ü  ÂP­ÿ¶±›£î’cc+¨ušÇªÝù¨±¤¯Dß3Nú(€§§t™¡Ç§«« ¸¤0Ëq}. èi¸äЮËîkPH±b?\cY›I‰û©ûKȇc4?þ:x o5•ö>byïðÒïCZ».¨ìÊyllPè u ƒtý ­Ý¢~n1¿êc~éÛ5òF3áüÔb$ž„ù +%Ñ(iYhºùÈuÛðb€­ïý­j¹[drí[%ȤçwEÝ#S$¢Æ/GíD„Ùâ:†*Éê a¦Ü$î¼+7ÛƱgMÌyNG÷-< +Qø¥4DÆN3¿š:ÌM‚Iߪà%;£ó[òÊMqØ®šÁ‰·.1q‰Âón’gOzLótŸøoƒ.}Çò)Îs'eÊ’øì(h8Œ!œq‡¬>ÔoÉp#!ë«‹§mZ¯ ñ~¢räÚô@è¨Ø¬­µ “¯S­Sx¡ùºÅ«°w:Íg YG¸^í²<ƒ|Tá _ÓµWf¾ô¯}JòèÌiA(ØipT·¿ßÈ'Îé²æòå§Ú5¬OÅÁÐyßãaà'î”Ø]†™Mº}r#_KH#Q#ô“4¤pj°4*•+´o?Ý.ê[ü·¸ý|w?qðhh„âìçÏão‘ºnùš_vnàϺЦMîH·1´Cf²SÖØÝO‹Ê,~ þs¨²mV½^2ÆæÁù!ÓZÃXßû!îðbѺ, +¿ËÃÞ{Pµ}u¤:ÃïKâ •'¸Œ[ñÒ«fБHaü@<¿bÔ]²®ú=Ù +Bo-ÚOA<ÞôËmDÀ¡¥ƒXܶ§ v`ð Ë Ôxjƒ¥ïëŸÛ¤˜:Û…ö!TOlrn¸#YnSo§ýe,瓱FûAvsãÞ½þxÿyâÔáUìøNUðùö'"œ€¬Žs¦3W#ÝIâäR°R‡¹IØ®?I˜†éÜ@ø“ )†‰Hm"}´sh­»mF K*ŠL¶¯Ìëo‹~þz^‹·y•îóqî_KÀ?Þªï‚@úÉ»v_lu0žd$|HÃ/ >ÞL— XŒŒ»wšÝïS½£ÀA-¡:v¨÷ëý8ñœìä²=, AeL膾s·NÒ\ ½œ,~žï¾æÅS™•Ãt¢!'Ž—ßDJ5ùá +’¬…VÆg¾4+ŒsGûÀ1´2õµK¶˜¼U¢Íÿö—èöS¼Œ‰0ä׿ö§àÊ‘ +À¸õdÂe@ŸcÙÿ9Īendstream +endobj +2053 0 obj << +/Type /Page +/Contents 2054 0 R +/Resources 2052 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 2039 0 R +>> endobj +2055 0 obj << +/D [2053 0 R /XYZ 85.0394 794.5015 null] +>> endobj +2056 0 obj << +/D [2053 0 R /XYZ 85.0394 409.4177 null] +>> endobj +2057 0 obj << +/D [2053 0 R /XYZ 85.0394 311.5951 null] +>> endobj +2058 0 obj << +/D [2053 0 R /XYZ 85.0394 250.1972 null] +>> endobj +686 0 obj << +/D [2053 0 R /XYZ 85.0394 212.3815 null] +>> endobj +2059 0 obj << +/D [2053 0 R /XYZ 85.0394 179.9082 null] +>> endobj +2060 0 obj << +/D [2053 0 R /XYZ 85.0394 144.7976 null] +>> endobj +2061 0 obj << +/D [2053 0 R /XYZ 85.0394 80.4778 null] +>> endobj +2052 0 obj << +/Font << /F37 791 0 R /F53 1017 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F39 885 0 R /F48 940 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2064 0 obj << +/Length 2904 +/Filter /FlateDecode +>> +stream +xÚ¥]oÜFîÝ¿b{¨Üf'ó¡’''qz.š4׸@^ä]Ùª•Ü•Ö®q¸ÿ~䣕vå8ÅÁqF$‡ßäZ-$ü©…uÂå:_dy*¬Tv±ÚœÈÅ ì}¢øÌ2ZŽO½¹› g´ ·}wþùíÏŸ./~úH¢IÕH4r¹Oéð¶Y¯Äªm®é¨ËÛfBç2 +±êN—ƪ¤¿-q!øêßRê›Ý¶è«¶¡]„Ô|àºÝ2Ö1J§Âé-20C[K‘f†Ï¼|™ÛS~sññ‘Ë Ð›’]¹½/·ƒýöTù¤­is×WuÕ?ž*¥0§tryK÷’#ÎUr[0°@Ö@bR ™§v±„luÕ¦ª $¦mÒ)ŸìVý., Z4kÞ~lúâ/Z÷íŒ^T*…O]ÊWÆ­ŸTL.²Ìz>Šællò¹/úrS6}ǤÇ|”ͪn»20“&UCЫm±*»Nûr»©ÀÅïU¥ …ÓZG)·àA9 +~S-WmÝ6ÀOjÒäm]ì:Ä®Áµ"ž +*D@7â7nÃKݵ|lÀÊßÌ1•Ëˆp×튚­Ú bf¾úÇ:r‰àmä.wwwíð¾v½p)ÊvßR”¸^X”L^~K°o_N?Èèƒï¾›ùä%Áú–ž%Ší5=ëª)ç°ýÒT£ûÇWb;ã«}18¡'D?Ñ©O6»Õ-®r´ÿ» ÁýmÑÌPË­0~Àñ÷¬ÚÈœõ Ä¢{"-¶+€ö·¤RÞØ[Õ+ú¼hè\{‡!ª;8õ‚6£“ƒ=¤Æ©Ãà€BÒç鵈/èñGùxpNÌi¯4ãÿp{㢠"¿ÇRJS‘K­ø܈##³ñŠ +ï‰o(²û’wÈÑk¼zŠ— +ieÜëòºØÕý’%pÌŠw"KmÌÇD¨UÌÁu[×íCˆ$ðvõHOŠã°a;ÈÞ(+ÒTªihiCl…x°^“š»Žhâaƒþ5F¡S•v³4Fmbˆ‡ÝÛ¶ëiõPÕ5­®øËGGØ»-ÆÛâSNðszuÄzSÝÇ +ñ=°}³c $Æ~}è’#“ûš”ˆwKíŠÔ™ð™özDó<Æêr!µu‡JÔžï—•РD³…“³V¹*s‘Éù‹h%´Ló±c,ɸR ¾e±K™üséœK.qçQßÇÄ!Bgö´«õ uUÍí¸VryrGåÇ}V¹7`(•\” ú Ì\”ˆŒñ+ŸÜsr†³jÕ®´Ùsâq25‡zœÄ¬=ï"™P 8Ò$¼nŠ~uË zjÕÜÌ(êõ ‘§ÂˆÚÕú£ˆWO•)þ¼ŠvL/d\^FOöìÉ~ðdO©!Åd ö¶Ô!ÙÑèÐ.¾a:¬~#ÑÃIŠ@,(ÏSÅ„lŠ±Yö„k:……zzàšXzÌH&K1#ù¦t`í$À:°6X—¼aÕƒ¶´„$Ñ”«oé“`”2ÖØ ënÚžQ±›ÃŠEl†2N¤ÒO…|J>áSЀ-ÆõÄí¡ÝË¡±™dDÂÓËà^ä[°O )†} @{ß’{ßÒ:`Opj€‹!ì~«{EùQ&ÜE:óXÐNp®yÿÁŒˆ÷‘K=ëIºÅ9O‚~—=)“#OÂE6’ ®«àJðdWÊØ•2ÉÆÆb'žÈ@`ç9tR‡¥D»Û®Ê%æsÌåÇ7PÆBÓ¬¢ nfÄUšp˜&7OdyïæèX-”³Ópˆå!X5§+¨|“U¨†A !¡ìHWö •*,.>ݧ´G"o©?\ñáQiSvìN‘·iQ@§îÀs¡Þ¨c;Ó¬œ]÷û¢|N9©¯çⲇ>ݧû¬òÐ&Ö/bí«îX"kkz­ ïÜ­K.¼ îú-Ú{Ea§~h0¼X®QØ %¡!,FM¾Þµ]W]Õü›Î«9'À,‘%É|^†Ü›¡V{1W€ï•}&epu¥¿è6P?JH'ñ ¹G9ç…Öˆ,÷zTjê,ŠIǺNËw¯…•‡­Óf‡å¶v†b-I».e (4¬ð,èAm”›è?3„=Ã-¡ IÍe„R<ÃU³Û\»D\à8TovXâyvi€ 2œk™ÀÅõtnÀÓ¹¦W!Ý08û¢¤è$?ÌðZSU†OLÔUˆ:TuÇÓÈ@ÀquŇ8^!¾¦ëË‚_‚Äc¨D†5*&tß&9/‚Ú¦ÔHåÐ7¨T8ÅK ¢,þ(iE‹ù²¤ð0¥Ê=Q¡Và³sÂtPüëXÝ>›B¼¹DGS”X öýUùBáíдÌðX9!4ÊÔdI'ä$&ƒô¬ꤠ)Síx LöšG +¤)4CÊ.ãñgüdœ]ðÈXù7òÈ™]B/•ê/÷ZH™ûãE*Ñ4o„×a¶e¾ f‚j ¯C‚@% ,abÊA(\¡*Á°…,ñ€7óžâ!š°¢;.ú‡6¶‰"séADZɱ °Øò&šeQß´[¸Íf~Ž®”æhûÖó‹áPdŒÆ)íö1Ö¹°±G^Ÿ˜§gP2ù¡zjx!}(Ts&”3¯±®K“ÕnK–Ñôõ#m¶ ­tòÏgo—ÞYž“åª/£§’¢ìíöƒÔa€G;Ùpbß³ {„ôÚ•+â£'ða=Ô +ãAnpÅÈŠ®\º”  ÍvÍ…FF.;>;÷›n.°u‡{lV8|½Œþ¸'\ÙÀºêâ\6ŽÞ”Ñ­Û](!pý纬î©Yá0ÆÇ–aÿ’Ã:j|²ä¡xì¸j rS6å–ßqc4ðÐÈ7®¯ÃÔm?¦ó#„ñ¡æRvø‡8œ€;²›m±™1UÄø‘©NG4±ÅÀþ|§#åðS ¥(¯X·LS’>÷Rº'àBh»¡uÔï z¥j3ÛWÐSŸË½Ðrè +ñç°µrÎ÷µÐ^Æ"z$¦Ã?u MûÐ0{ÝMéEjÒˆjS}¨Ê D_°ˆ­ +¹©™“èW Cˇ*‡ò±è2šuãñÁìݨ ‡ýkºâ†vâ¥ÂLén׋™‹ig…ö—e™Â:ö”-•r8ë‰vw[݈ ®ÈDq7gÎw}œ9{!s=Ç0uÞU] >ÃÀ¦hâÿ +ªMÇñàsY$êó_Ï>|úñœcº8‚‡h? ÐzOÄŸnºƒÃ%Ôb{ñ~†•Eê-ý¢éÎd,è$öG{Ž<üÒ°tR&ÿ ’‰¸ç»k®•†óu»*jlÓ^Ï…ÐñࢃŒ†÷×ÜêÎQúï€ 2²å[E²nLõY¦åÌ?OY}eÓýøý9Ò:å"á¹-µàÿÌü#€Pÿßÿv°ÿ‡Œ4Æ{½ÿ‚iiqÚí"Sx%G¬ÇP8æý§vÝ7endstream +endobj +2063 0 obj << +/Type /Page +/Contents 2064 0 R +/Resources 2062 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 2039 0 R +>> endobj +2065 0 obj << +/D [2063 0 R /XYZ 56.6929 794.5015 null] +>> endobj +2066 0 obj << +/D [2063 0 R /XYZ 56.6929 752.0756 null] +>> endobj +2067 0 obj << +/D [2063 0 R /XYZ 56.6929 252.6303 null] +>> endobj +2062 0 obj << +/Font << /F37 791 0 R /F53 1017 0 R /F21 702 0 R /F41 925 0 R /F23 726 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2070 0 obj << +/Length 1788 +/Filter /FlateDecode +>> +stream +xÚ¥XKsÓH¾ûW¸rY¹ š‡4ÒRLp‚8ŠâqP¤q¢E–‚%c»ÿ}{¦G²ìˆM(ÊÍô´zúùuËtèÁCŸx<C â{Ô&Ë7¼„³ãµWø<$~Èd/íø‚rFÂÀ£CéG$àŒgÄiºRU¥ª‘€~à#/“8¿*«·×åÊ®|îóG¸ü÷‘6èRJ"ßgÛ…k½¡+hÇCý¬nðÝ*^^çªÝþ0̽‚âü²\eõÕr’€õj'î2õ[ù]æJ%+…šzÎApt²ø[ðÓê»Èo.˜8*–O¾Gù‚æùóÓ?óïý6ÐûØP«ªþE ‚ûÀ„6àŒ?›†¯‚'/6Ñûͻ͌¿}ÿbýúñã{hýð⻽Ë}ˆ½ïÃÂ#ƒLÒ¬ÓÂÜäÔW +z+Œm@Ίí%;IFm’¡j€khk¤t’²Ð.׫¸ÎJýº MÉ2l q…šÃ1hn‹v…ÎׇÈ#:ªÖÞ4_Y4U³Ôq­–ª¨‘ži–¥j®1aÇ{¬‡z +fm‹‰° wè<;º'O}ÜÅùˆ:mŠÑYm_Ý*‹û$1Pz]uœ†Sn/¹ˆ+å7ªHÊ4+.qW.~¦ÐO +¾½:ˆÊËÊv&ðLËõ…‰¬¿¬Kpi……$…M=Õ’úB·X¡¨ãj‹83(fâvË„‚Ûw³ +ß\£zÜäWÑs£/ˆün|RîáH*©í%·h@“|·Þ€[”>Ð-ªÑƒÂ›zšÚÂ7V8"Aà®»­õ*vȹJtþ¥*”ˆ EŒdT¹Äõ~Ð(¨Ÿ(ò E±eW<,nŠ46ÁI›öÉ ƒ˜ïVd¹®¯×µ(b> ”J] ÷8„RȨ©‹Qû™îÁÚrÐèÓ#'"Ü— ÆœU™W}~…T½-c ¡fÛ¢\õÙ±)5 ÖéÏÂ0‚ aEo5ÉŽ]V׫L»Ä g! Ç’îBÑE³Ð_©šæ°PZõthxU""!eáÿU "ô°¼S*¹*qN;ø\”›Âοy¬Mþf‡`íf³ˆí4k¦¶Üüƒ=åh;bÝq¨PJsçl|2A»Ï'g#èÊoáaöú3czüæl¬½9ŸžÎú‹˜Äc‘u¼Éwئ̩ߢ§¦â¡WötÛúMR<5åÏ8IÔuœØ<4Õ‚4L +•e+RäiÞCaIyYdß­BX‰Àc XSªk•dúòæÖ¬èë‘vŒÙ/™€D<ˆîƒEÀIå-,â,j:§¼QcõiõuJgRÑÛ¬èU*ÓïSdðù¯ÑFD‘s®ÔžUÇÃÜ´½æ¸‡(‘\ȻĞO$ƒÍîÒÆ:ƒ¶Mý•<=ÅU„qºÌŠ¬ª¡°u5hÒ™Z(Œ{‘Ø×Nâbç[pÂiFÁD•ãsGiœOleŒ_žŸÞü: ôgA¨?ØîÜéûgM‘šO ¤›;xÔõ­Ô½Œ5 ø{ž¸m B¹A›=^q¹€ï7£w½3~3vzv·[¦€]«¢×ó› +Bm;Æ!$LNÙz¹½WÀ4Ñ€O_)àãȘ@?r©þ¸ÞŸ,Là ±„°˜¦Ñ§_1Èþ@²Ûó‰Ñç#|õlã†+Ù¶?Ptv–eþ³¿`@=Éõüaⵞýí¿g¶C Ix²öŸ—«¹.åm”Ò¦SN÷Uoÿȹ­û`&ã±endstream +endobj +2069 0 obj << +/Type /Page +/Contents 2070 0 R +/Resources 2068 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 2039 0 R +>> endobj +2071 0 obj << +/D [2069 0 R /XYZ 85.0394 794.5015 null] +>> endobj +2072 0 obj << +/D [2069 0 R /XYZ 85.0394 343.1761 null] +>> endobj +2073 0 obj << +/D [2069 0 R /XYZ 85.0394 255.6488 null] +>> endobj +2074 0 obj << +/D [2069 0 R /XYZ 85.0394 192.0319 null] +>> endobj +690 0 obj << +/D [2069 0 R /XYZ 85.0394 152.6743 null] +>> endobj +2075 0 obj << +/D [2069 0 R /XYZ 85.0394 115.923 null] +>> endobj +2076 0 obj << +/D [2069 0 R /XYZ 85.0394 83.7361 null] +>> endobj +2068 0 obj << +/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R /F48 940 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2079 0 obj << +/Length 3192 +/Filter /FlateDecode +>> +stream +xÚ¥ZYoãF~÷¯Ð£ D=}اIf8Øxf3°@6´HÛÄH¢"Rvœ_¿Õ'5%?°Ý,U«¾:I²ÀðGB"i¨Y(ÑÀD,ÖÛ+¼x„{?]‘@³ŠD«!Õ÷wWï~dja‘T.î¼4ÂZ“Å]ùûò{Dºxùëí‡V?|ºýñ§·×+b¸âË÷Ÿ?¼ýpóßëˆãå/ïo{ÿo¿÷ùÚÐåûŸ>~¹þãîç«wI¬¡è3+ÓŸW¿ÿ%<ÁÏW1£ÅâþÁˆCÛ+.œ±¸³¹úrõŸÄpp×ý4« +‚e’ftAÉ‚d„ #eƒ$£Ì)ãËë®Ù·u;}FÒ’-c+ªsGP4 ÜŒ\H"A¬ ''9E*+ÕaW®Wëf÷ðXí®Wôÿûªø#®î­°ï~„“{6X8Û2øZ½¶õß•'Ç Òœ‘@—x®3<™@Z +ѳ|¨7ßÀò)­¾f˜K”`¼g¾+¶ßÀ|QÞ}sè2ü(CÆbsÂïá·bàG9@+ÁȧؕÍvF€-¥„ž²o/Š[”å¡jÛ·k »Èrýthš®¬99ÁCE‚Kbz¼ÈôØV9~”#:`çÆî·b„‚3kXh¤ŒðÁèÃÇ/?üzóùîæÓmúQÏ/VT"!Œ8u O=‚CÓ) ©EWµ´´YÂÏþ‡1}<Â^Ýìü¦ÝÙDŠ‡æp††È„“™£)F\EPAÈäT-oºprN»¯üTXúUŽ.’ŒÏÕ®®vá—Ŧ«;÷9ü²küõåPw++è‡*Ä4—cŒÖ»G 4rÙ=åP +±Æ¸°šž Yµf “â4âÙëËs/° áŽp;ëæp¸&zYµûfWZ2êMQa"RàÔîÐlÚÌÉÌ .U„½=-ÃÍ MíƒH†ЀV"Ÿ¶HlAí—¹ÞeÔ#Á㌎lm`*çô#)R4…“ûWÏõ ÄEÞ>œpÈ]ÜŒíó¾·ìæõš²ü~ÉAkzÎh¸ð Ãµ^ÃÞKÝ=ùÝdÞ±Z„FDs¤Z9µ`¤˜ˆ‚7ûàÀÝ x·Uç7Ž{¿QdT¥42˜!’òfÖîŠNì=,ÿç¦.ƒ Oá±wU¶¬{ΊA¨@B©‘Aÿð!zñ¨q—³&ŽÉTF(y¼Œv‘Q7D ê~¤1at +ÅÀyÓ5<øáª0” ¡kÄ0 1Ôƒé“ Ÿ§ÕX(@‡¸«•<_¥ ©bñtZ¥$ªWÃ#%GÆ}þÈH”9räY°TöFG~p‚ϱk¶à>ëŒ9À%µ‚€x>`3ÄhŠk“ä`8ı»§ºõÇ­}\‹ÙDú€-#D2xä‚doò ©pÌ®ÙpÉ™ßUÝ:\%qï^;w_ž@ìçlÒ†bE3cqûÚZ·Hõ×BRC€õØ^l#Ú}µ®­:¬»ÚxãåÉ–°võýÍ퇰oÞëMÂÿo¢º6dY‚ ÷ÀÓ†Wwm þž +¨)%%,O')ðÍäxV¬Í0äÜ™"Ó«¯ n}èŽ{d3 åàauI¥vM–`>p³X3Á¶Æn6ÍK>Ë35#7â¢%6Ñ\.íÉŽ;{dtÙŒQ%Æ:q90ƒÈÇœóK–cˆCM=°œÀ>éÀbÓ¬‹_>5mˆÏ!éÂj×øëÃñàµûç$„8Ù!nB”Q :„~ƽè¿w»¼Þ ÔÇ‚šÚú.²g>“+(P™Š`rVi=¹÷8*äÒø<Ú5Ùøó3¬‡Æ†®:þ¡¤µG„³KçºÍ~UÙ½+ï7Å:Õ_ðCŸÕ²ª¥Ž…-GXˉ+ÌÖL¤ú;ÿ £býnΨÖçXD4dTÕmç‹k; 2c/ó4l+J%½^*#!ˆ‘/Q¥¬àB~lqó`ÏõƒÄËmãµë7«MqßØÖÇÿ{ÚùÀ&„Ú~Õy.±c*ýûלqhpͨuBÔÌCT«—UÔËüç±ö‹ÒÚDÒ xŽ¿Ší~£P@±?Î?5èQíAëV–¹½ZÓÙ«E¨½B!š•Ü¸mºAõ͸^¾6GOÐ>5ÇM"v•wFvòÔ§’ËÝ©0©¸´Àk ÀzY³U² E# Î;/[¢Ê7¶2T’„ª±t_R¹eáΩPvá$r«æar ú(›Û=—Íí¢÷u×Ú™/TŽ¿mîs›U¼v/U(IàêÀ A¨]0Çâ_°Ô Ù€1:›@¬¯HÀÜu0;¡zÖÚ¶Ð`vÖÚCªyk'*gíuÎÚv°L2óÏ‘µ¡%Sª“³²%ªŒpck3[ÿM¤û-d×a¾ÊÇ è­˜Jv¶ñש4Kÿ Û¹Zþá5v¾©=u‹A‰Ôÿ2ÎÆ@C“õ†ˆ+¨†±JÓ³9ãS “üB;¤:cüHåÔôtÒÇJ„ºpd$Ê9Ê}PÓ)=9òó¡%v9ÜjýɬýòÅù! y˜Ô Þdít0á‚åã1ÕVΞùN)UoLZJoÆ.™† =7xõYÓ ©æM“¨œi¾¾% +ÇWÙ(|V¶> +Ÿ +—Â#éFQØV³ÁF24I°p¢¹•·ã€Æ×,v5 Ì‘ƒ­LOÜa7¶Gß‘ÈT|þò\lÜø –e³-ê]/:„ï"®¦Ñ8Ó¶ÚILj®tþ‘GSÁ ƒÆÌl»¹Ö>ûl(#Œ"0:ˆTóÁ,Q¹hÖ^ìrŸ!d»œ³²õ]ΩpÙ.g$ݸš¢”,o>û +œÁ(ÎeD¹s¢.‚‰Örš-w?ˆ‚óûa9Ńa9Åã\é~3Ÿ+)–ˆöm¹2¼Ã„$1}Å?[·MgÙÍþ¾X ]ÂHƒ®ÛVÙE£6ì<DóXŒDŠ]6±šZ£¯WÆ•=$`"ÍYÉÑ©h#$RŽ„}Õ?”-´ÛÆÄvÛ˜¹v[ Í´¸0¥£Jòi»mÂÇpíÛmãºFf_Í!Ü9‹uaß,srëF¥Ï%^êÍƳNßÀÔîܸ©ÛŠCˆneøæ­ïô-UYÛgó™gì_‡É’Í|Š¢!djEßô¢”³ä¨Ax`ëÓ sßÄ\C¨vƒhøß+k¿ž±4Qç%6ÉOÔ 7ÛDäC>óŸdØê ðŸœúÐ]`°[¯}OÞ”&‡*87õUöæŨU I5(šû“A×ʲ‚Ówÿø#ÍþcTn?EÒ3-4Ud¦2 +e‡øvÂ眧²ÿ¯îŒ—endstream +endobj +2078 0 obj << +/Type /Page +/Contents 2079 0 R +/Resources 2077 0 R +/MediaBox [0 0 595.2756 841.8898] +/Parent 2039 0 R +>> endobj +2080 0 obj << +/D [2078 0 R /XYZ 56.6929 794.5015 null] +>> endobj +2081 0 obj << +/D [2078 0 R /XYZ 56.6929 748.9271 null] +>> endobj +2082 0 obj << +/D [2078 0 R /XYZ 56.6929 674.5821 null] +>> endobj +2083 0 obj << +/D [2078 0 R /XYZ 56.6929 573.362 null] +>> endobj +2077 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F53 1017 0 R /F23 726 0 R /F55 1025 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +2086 0 obj << +/Length 965 +/Filter /FlateDecode +>> +stream +xÚ¥VMoÛ8½ûWè(+–ß"NâdS$N6v€mª-;ÂÊ”×’äßïP$]Ùa›CÀJ3o†oF$ †?’(0Ó<É5G‘,·#œlàÝ͈xL@Ùu±}ºfy¢‘–T&‹õÀ—BX)’,V_ÓÉããtvuûeœQÓ 4ÎÆéýdö<¹sÏÇš¦“›é|œÍs Â,Nâôivu™]>Ì®o¦³ñ÷ÅçÑtq¤5¤N0³œþ}ýŽ“dðy„ÓJ$¯°ÀˆhM“íˆ †g,<©GóÑ?G‡ƒ·ýÖX)¸PHP.“LP¤0× #, ÿ,çI­Ö‹’X½ÊÖ+;Ø{ì¶pÂ{äÂvzã)Õuó©)‡Ödš Î.â—R0aö8Pç]þðÙœRÁòJËx̶0‡¢ö©6ÆVqs€ƒýýåžîÇ*=/+5šIs†*8šiFó#à <­A1ãLÂl‹ +‡]ê¤ Ët·¯LçÌÂýk‹í®Ž)[Ä؉®m䘰%4ú¹®ûfåŒe³w¢hwYUf9 ˜ªHæÄêöMÝFâ1PmN¹Ú o`)<&Þ€‘"~Ú:p[+S˹óûá“q‡i[î*“ù¢ne:ì!š]쉔—kÄqnŠ-´Á¯ê«íˆ 'ñ¡rÖˆäZÿF:‘vç}6ŸN]œÉÝüáãf³Þ¿aüÀ0Hƾƒ}²tï”68NQ"hêâvvå¶jOjµ­LÕvÐK%Oåºt3Kßš÷®ý"/¢R†Y? >¾¾§u™> endobj +2087 0 obj << +/D [2085 0 R /XYZ 85.0394 794.5015 null] +>> endobj +2088 0 obj << +/D [2085 0 R /XYZ 85.0394 687.41 null] +>> endobj +2089 0 obj << +/D [2085 0 R /XYZ 85.0394 561.6045 null] +>> endobj +2090 0 obj << +/D [2085 0 R /XYZ 85.0394 501.5525 null] +>> endobj +2084 0 obj << +/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F39 885 0 R >> +/ProcSet [ /PDF /Text ] +>> endobj +1187 0 obj +[694 0 R /Fit] +endobj +2092 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 +1598 0 obj << +/Length1 1628 +/Length2 8040 +/Length3 532 +/Length 8905 +/Filter /FlateDecode +>> +stream +xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä0 00Ì ÝÝÝÝ’‚R"‚´t ÒÈ‹>ïÞûüž³?³?½¿w¾Ìÿ^×Z׺î7¶‡Œ5Ü +¬‡¹rðpr‹ t´P(ÐWç…C­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.SEM#¶ÿöª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 +~"ÅVöè=”Žòíí`õ§ï3t;k‡–Bf?õ[¼„Y®¤¾ša£„+gl’ft]ÎB‚²w3ë‹,£ªˆôkêyô’­úÅ>¡ï„móW¯µrÅý¼0Ï”dË#»§BŠ¸ÝUJàžuÕñÆIÍôaòÔã·×¸§ ™ žL¦€Ädô<­cË-8àÒ—£t‰Äº4ú£|©D„¡¹šŒ]¸ãÏßE¯¡>ÓR·9xyôöŽ[Ìï`º~ͲûDœ¨'ˆº5e[-0GMÓ=KÊÊJþ&â&’PøS¤8ëãin,õ 2PU«r`ZÅÄí¢v8Q—ÁèÍ ×ë¯oã»o[2ÝO2Ó¾Ðm/Ÿß×Y¿üìvV¹"_=5Ó›é¶è áaÖ™7þv|g “y×&"YæЖ(¾+ÐMoûÁ|°>›à¦± vZÎI ÏW´Ä%^‘›üˆ¯­Ú]Ö%½ZÆÁ_Ï@ÄRdçÒÄ9è©‚†õ‘kãC¾¥HzõOlnÕžÝÍà™>{óbÙ7U^|ä-)G? +8òÞ¼x“mì¾%ÿjã=!•š[žž;[#ÆŠ™ éJ©/A%Ñv–µû`éióöí؜njP~^z•çQ•7˜¿\扯â ÈÛ.|âùúÁèéᙪ9 x°¶`÷V¶v™öÉÝçñ–%®¨eßùbU€|;0}õd¯ºGŠŸ¡*ºS{…Oi,ÚŸ‹í–0M¾U_jL¬@qª?Ôªuo›`ö@è­Åû-€›-0Múp_ðà*Kþ*š´ll´8ðc©ïÑJ+cCôcr÷®4$G¡ŒÕ<;i¨Wi Ùªµ‡ý^gµ£¾ÕN!Î*{¶£ô…ÆW5'xs ^ÅÍ&o`Cð¸OïŠPÑ©4e¼BÃ9jÝ’N7t’2_M´Ô¢äÔ¸/\ä_‰¢{\”ñw“Ï‘qú\®û7«X­”ƒÞAÁ¥}Æ +¸È÷»Œq„z`²\F棖ûEœ!~õT¦¾\Ž'4/ýCîe– 7,î9tãÒ¾Â1 ¦’·IM^y/¢˜kIm;˜¨½}O«•oÐHâ•¡Ç6—]í7ôh`† J­TÂcweófœkÔ­—ÕRÐÓ(9%Ö¯c +Ó·_Ü€¡èüêr_7ýGmÔ&œÐ‰lÞÆŽ +Kê#TðÖ†§øñÞ ¿šûDE&ñžËœ^QH¶!’Þ»¸>àáÉà̹ç$ÚxþF`Š×Í4IŽ@N@ÒÖ>_9²J¾ÃEúOêá˜/kIÉu~~¦r–æw0§øF¼Öë!ÅÞÍ<-Ñ:yLj]óC&üwÏö䟃!•“®²h!¶‘6òÕÝýOÒÑéÃVwc1Ì{õX/MHÕ¼“øÍT(¯m­)5~Þ÷ú?É6nðýYº³`æj¶]`.Ò’·Ã‹imzdëøjXJ[”˜OX8wâê^ÞÔGÓö†^& ÌèWZGÅï] ðÍ}Ù ¦L5«ûrkÎw¯C3íñTS‡n‡a†’Í|­ïDÔR”ˆŸÆþÚgòý·¯0,‚…þ«dñ6›ô@‡Úò ‹6~ƒ +uÿ'¢µ?s_¯Ð‡öÿŠ˜'u +BêH—‚?ý +$OíœàÅ€DÈåìصö„÷¥½O%©4žñ­¢¯‘ÔðQ±¡8M”¬|â ãhƒÂ!ãëaž!ÉÇ86e}YÐ7IÏWë]¶Ž`…ÏÜ&ÂcD×rZ‹î”…µöíòj—«§ÐŒô6ZÑóÉÎõ»§ ÉDdßÆçxãT  4ã¥éÐ|ùw%h± V–¾tf°‹ðÃ/ùäanЇhµ•]ªU•²ÆfÑhª¥Hm9Ôaêëô¦É’T›À…á/‰¡øOõ£èî.êš;{?W›¥~#ÂÝGÂÚM†ÑÐuEh 7m[E†lûÌì’ãÍcT±ˆU,ͧ˜¤÷Ö„½wú°aV.¯4žg®r ¯R«©*˜"‚¶±ºž¾<«0ÛÍÊõòÂh„Û‚†½z«Ã÷îîÛ²±žˆ©Ë_>)FMÁ¿EIÕú®´ËRÉs¡bÌo™ç-:ƒÒìXÖS¢ªÈœ‡(2³Ü{Y¥1³$Ê&?ÎIX>µWÑЃšÍçnPÊÉLÇ@¼¦‡2—­eýS¬+‹†^WD£gu¦í÷ùBü]8¸ïOÔ5mVl³Õé”VË(¼ÛmN^nml ÷’ s ÊõÙ±…- ™x³àiΛ*µ a1ןáu«+@Nñsâ),#Gu-/JÕ¥[òmš¬»º_ä>TÂåg?âD"gCó5®™,ý’ «gº%q\Éw&áÙ¤Û‡ø=rM±‰©þAÓǯ{Êò¾fņWÛ²%§›s¶J¡üêí;7¥ÒÂ"¡äÉU’wlQ-OfÌÚSá\Ð*¡BI:àà¬e’,Ï—¨xF)f‘ý\0l±÷„½Ý…ÇvãûÁ‚„@>:ûY´ÈÃ÷µ[e|&.$UÎ;M“íj¹ª_¸=*Þ äSó«—M¾¾rµøds‚ïP‚Ò*’÷Öåß `2¬„ šêÁT^£„J’¢¶¦ž¦Ÿ+õ¦ÐÛc8ÎÍ(¢•ÉÆOûX™rZu"Â&U =oöE±êPy*2ßî"VåÖTú•¼Ðc&úø¼-ÿ{ÄAÊ+jV•f³þ¥œÃš°8ãö©Ÿ· \b,>ÆÜ—(hwÌ©¹û†}ÞwW#3?¸šn/fƒ´ÛÇœ¥Ÿ— ˆ¯¼ø–HÕ‹ ÷S+AL—£vÊÑQ†¿«l0v^£žÁJIL”½}ÓÎß>ÏØ&é(üôãIßv0Ûu îò'+¢gôô÷Fvˆû§BôYO ­g©qq¯Ë+ä(ÖGb›‚±›Ì¿xê!±ùÒ‹§G +>C{(©¼Ê°nwð,K ?EÚ7þBq&‚´”jɸˆ·?è¦ú-ŸCØüƒ%¥uXcýøââBïÅ ´;ÁµÜ3höŬ ¶÷Ét(‡„šœì :î´cØ¢>:ƒ‚¯úò‚#ÑǤ_VItSÏ$ëŽ`ø~"ÔܲÜr$ŒU–Y7÷“ø?¢ê¹iâ¯ÉqÅõãÏØISª5ñ4Â…èÑb“EÝêÑÑn›p³ú†-.ä‰ìošå•Hû~B»ÎÂî‚T§Z§Ï_)©OqÓzèß÷>ë˜Ê;­dpI¡rr1ÛA +öÝPî2Pw]¶u¢èúä»(£ý/Ž¾ªˆ§þßÜ¿~&æ[1¸Aé-KžÚEО5JÃ÷.føzßwi°h“bLñB³ß6ˆ^ñ*£–—qº'À°´TÈ8‰ÂWÏõ—„ãŽly&V¬AÕ²Kò^ˆâ½þÅY;/Vwúí}<÷Gc…R“#]›gùDÏ råV¥k¿½p¾Õ¼¥}ÃvGšAÐg•†7PöŠ²S +ÃÐÙ²¶©HÈ  9^©;¢Ìœp»Ãm%{r7E•€ÏŒµÂE±…ʨ*o,„ó QÞúʭ䦀(ô$íªy{Çgk9©‘5Â1ª0Û˜F3ŒÛ!s0¸4XàŠú#r¥Æ2á\8nqå°Ãs}䮀„s–è5)q…i¹C9ad¼¿`u ^<‰2@´ÄR­×$âƳ—xº>áÈïž¡wdª‡}Té†×ÎÂËõ€Èøt\1Ü~‚9 ÿ½8ia D9©ì"Ð!gÑßqÝ ùA“ׯøŠ‰§j_dI*¡ +»]‚ÄÙªAÓ8ﯙÎd@Iî?_ɽŽbÎJÊ8&1ß’bçy·ÌJü®J_ƒ|¡iïÂC®¡L;¡Æ–=x8"ÆÝù\šGd'—®®ðÖ/B¿ÝÞpRÆ'µsñX'MÂÁd;ŸäÕEûtGmý«†g¾ ¿¨öùWí},¾Ï†Ä›tÓk„fªõžÑ »›&oô/L¿ÇGìü²•âBZmÎOw݉Úñ¼>–¶ü^ÝvšÉŽHk6Œ´­¶DM0¦›}Öda'¨šßo·é˾xWp¼311ïçdϘ9óÅ­Ô§?¯jò>*§¨¦‰Ð:’-+X}7¿$ÏL\œö¦nD™ðì¡ÉX˜vWŠñ=mç¡|'M}„ç‹çÄ_’øÏ£÷rci%Åës܃ ¨ÄÏ,n±±ˆ" 5Ù½6ìÉ6úQèÒõmŽ¬öó–à+q®Æ¾ùÃ$ô|Òî]¾öÒñÕäË&æèñ²€Õ„KfVº”DfƒŒåZóbúä`#öZ·<Ò_Ç÷-¦ªÏôª +_˜lg˜¨Î>«ŠTÂ70¡ðW~—ÛC!_ŽÎr¦x‰|„ŠúNx‡<7M–/&×gaÅj[²Ë±‹4—À¤ÀÖO–|¾1_JSw{ðÐıDÃP~ÜFY­Yy³]ˆ:¬aÔ_|žjÓM+ý­‚0@îhÅtÙl¿Êgšê…µAbDå·Ôw¿þ}ûYÕ×iîBÕ*jòýZö˦ÏN’FéT/Hn±úÁÖ“4ÑOEìØœz~Ÿ Þ88‡á ‹w|q£ªšîFªãÆÇ +TT>/5—䬽%‰”dðqÚnCÃ%Î4ÃXDmeß:#ƒU¹Ø•l1~à 4±GL§%ÕëEЈ®ìÒ\;ãÛ8Å+§êJZdº×d¡K©¡ZÅIŽf3zV#W•c[Û¡*_-߈¯Þ­—¶5k ª€º—,ìd¿»Ìë÷S/úò¢×Ž Nâ)uóÒY~ ]ßjÑ×Ù˜fšuž²K,tÊ÷“\'gy¿÷5­<TÏ4CUMà£Ægÿ3Q£8Nð²Ã‰ËzN5\/MØr®]SÝé}pæ§VD@™:]¬ÔË7>1ÌÈéC•'ÛEÆŒ!…Ù7aVì:ASQ×µ{|ãÇj9YÈ4Ö|m Î·*_íw4ø!D1 ñX¿Ù¤X•³ç +t‡Í=žÝbóÆÃwî6ß"£“˵?”JËOP2RÐ oQo+†â1)©w†¦ÜèådîI½ÈZ¿VÍ­(e÷åû È"QÔüFØs(úF$'‘qL ®/¶!õÔ ¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ° gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd +ÞyŠGÝ ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’ ¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?ÒK áéá@F)Ø,êw÷ó?È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý @¥-«ä%Å~jÉwXjz1îi´·î¬%uÕ3^¿±g¸`d+ÎK[ŽDe—„]âò†YèÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š” ™v_Å [ªJÖ®²9m=·âú?\‹k>¼à¬‡¤*³Ñ³ž,Y ê<‹ý¹uÓ Z/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_ï‚¿œ%%½¥åŒìé|°D>W²7}C–Í#—ZR¸­$º`bÛGο…a¿9gÝS%\”Á/œîñhC|?s§ Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O +üõí+uqfº`Îa‡„°£â,I§ã¯½/‘˜÷ÇÝ›Á¤'P6ߢH‚Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)wL=(‚Œ£± L|)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í; ¯åä²fùOî{&*‰äyÒ¯9ÛB±T¨d>è.ò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³—dOj nÌó®|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 +endobj +1599 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 67 +/LastChar 85 +/Widths 2093 0 R +/BaseFont /ZIFUNW+URWPalladioL-Bold-Slant_167 +/FontDescriptor 1597 0 R +>> endobj +1597 0 obj << +/Ascent 708 +/CapHeight 672 +/Descent -266 +/FontName /ZIFUNW+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 1598 0 R +>> endobj +2093 0 obj +[722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ] +endobj +1579 0 obj << +/Length1 1630 +/Length2 6133 +/Length3 532 +/Length 6981 +/Filter /FlateDecode +>> +stream +xÚíVuTÔí¶VA!¤†”ºQº¤»{€!f€J¤SJº !¤‘RBpé–NI%‰‹~÷;ßYß=ÝsþºëÎZ3ë÷îgïg?;~ïFZu-Ik¸%DCrpsr‰€t4õÔ--¬¡pe)¸£µ"ÒÂtñ¥]!H(&c„ˆ€ô Ö ˆˆ‡Ä-,, `Iý\¡¶vHó  û_–_. K¯?‘›HÔbºyp‡8 0ä Åÿ:P !í ¨#$­¦n ¨*b–WÕÉC`×›"ÔÝ,¡V e¨†€°€là® Ç? +8Ìú«4ç —$dB8C¬ 7aO+ˆó/ˆä qu‚"7Ï (dëjCÞô AaVŽnÖ¿ÜØmà¿9»Âo<œn°2u8‰°r…:#A7YÕeäþЉ´³@þÊ€ÞÀ ¸Í§5ÜÊíWI¿±ši…!@Hˆ'òW.KÈŠpv´ðºÉ}Cæì +ý-à …Ùþ¥€ä +±µpµv„ 747Ü¿ºóW ªÞÂÙÙÑëw4ü·×?4@‘ˆ£ '€›ç&§ò&·-ÿZE˜ ÄÍõ‡ÝÚÍùOÌâú»AÌ¿v†åF„…5æ貆ØÀªpäMJóÿnÊœÿ¹!ÿFüðd¼ÿÞpÿ>£z‰ÿÝ÷ùïÔrnŽŽªNßA ?ï2è×EúuÓ@­þGŒ…ÔÑë_EýÝSò‡Ô_dÇþà–„ÙÞÌ„C˜Sø+!õ„X«C‘Vv  Ç›ný¶ëÀ¬!®ŽPäfª¿ +âàæâú¦mµr€ýj?ÿfýwí7ƒú­¬£©¡¨,Éö¯o×ß¾ê7[€Ôör†€þ;‘ž +Üú‡_LRRpO7· ˆƒ÷F7— /H˜—ßç_dýMÄý×YÅé +õqqrqqƒn~ÿüþu2ù,Ì +nýko´0ë›Uû‡álåæêz3áßoÿMáž/=â ±LOÀ­DƒíS3ÒUä9=ý2F:¸1zBœ‹k´_çûWÀÛýRÃ…ËÌ/*C8kE®š¼Æ·/W•X×z;È·'Cöò¨|èYÞçÍ3½d[ ›ã§}Õ‹òÞS^À4àÒ][ê×Ð4-º¸|Ç늽ÊâOïžïOÊpâLàk•òöÕƒÂÚ[ÄUÛ_™6OOwõ}ìén?¼û~•’-û£¨;&>S¤¿K6åSCRÙò·ª·ãòŽXXðð+yÏ—×ro1XçFèÅR61žêDžeâ§Á ×^‰mùkT³ïT ¥ØÜ KCvá)µKö±éû¬l´¾úï.ú¹üA¢IὬ}‹xp—ÆÌ:…x÷dlt×VEæ¹®ëºB4ߢé:°h`M$z¯=Ä*óù ?7l &?QäÔ…ÚvÆ<=yÊÙûÃ㎣²=÷'ºçä ÄAŸßÊ}gw‡U¸'b%6—=\5Æ„¶O€X)Ô| 6*˜Ö}ØŒôDVs§Up ˆíbëÞ­×…+Ïo_MX`êÁWÉC.Âß6¼|í½ÏÊ)¥2ÉP0–b®G+kGõýZŠÿåÆ~+`çÑáËé#™~KˆjîβÍ5—‚ ÿ3zë5½ó-o'‰ŸžoJ| öñ Õê…k¯Hî÷’ô¿/üž“â«7Rîõî°F˧€NÚ´…”QOÆYÃÃöLNßÆe‡··Q&8LëÀ…cÙ Õˆ€éëèqo£F‚®ºqG’*¦²óà‚‹¥"ýbmÍHàv{(Ž?ªÍü-ë&wU¼m_A±FÀͼX[ÝuÞ80+l8]ò)áß½WMœ½RY.þä© Èóqº:Âo£ù¶ãí•MÑJôßY$‡‡Œ’`$íŠN î÷Þ×ó¨‡caíó )¹ óSçãa¼&ßi·õã¬P2ó§Ð„]¬ûãð#l3oñ{´„îªÌ ÁºqÙhiµGH‡:!F[ ŠcÙX±¯Á,þÙñ°“ŠÊP)½±×3 gwµy—Þ)¥åB¸*!œˆ—ÕëLwÑÔëe5íÕÄÆú¦d„’ÅÙ5jY®yr!Þ8RÖwòd€éî¨h:³ìç” Œ”´¹©¦úa!ǼÆêëÝSY·ÊhHçú—J§=\½ WšbN,8‘T‚Y³0©ÝZH;V$Ìëü›HÙñÙÞ¦eÊgTr>R‡>Ó£*X¿l WTh‚ˆsÝÍötº·)tÊ`D"ŒN€d÷¶kÅŸ×Ë)~>;ûHé¬\ýÉò%Œæuj Û²!>2M¤ |N¸»OŒÀ¸Å~Hª´+ˆ#Å"QÒ µl’9’kСA}S÷†né^W©]+žSüÁèû³,>VsIì)Í’©^ cFièr}Ú]ÜAƒŒ±9“"³ºÓÜö1x«ßiëÍ‚5ÃèÕp:¯©+Œ*‚_øˆ'û´”eÞW1qáÊã»NÞ`Ðß 'é »Îk+ñKÚ+ŸQÉ8¤¿'u l(-V;K!ªÆ¹áK‰IúäUW‹ÇtÎœ%6QK(ŒžJAÿÝëáæ…\™F{3dk*ƒA¸Äg5’òœA±ë¥ÙgwA•,Ï\÷3jT¢÷Åɪ™œüRÅy÷wF#«(Ùá²Zá”Y„FÞì¼\>LÉÈäAÝ ŸËi6ô¸ý•dèEͤ„ o€8qørŒ0m+êñûƒkŠ a6u÷} ÓÁÙ&Qûó©„rìî:?†:è +ù£ÜÛõŒÚGa¾Tµ ˵µ;¥¬W~òn+–lO­4 o¥ø!=ËMS¸âØ(kb¡,D ZÆ8T'p—.ø;2S•cf‘¦>dÇvË%·*­7 }Åçj£&ã—6Y”«Dd¥×VÑà›lh`2爙0#·êZ=4í%牵7h%Å Y$Zü¬ˆv±?‘©‡É=áមð;Ïcc„—÷:IêÖá°5ž’”ö×yÇUµD2>ÃÙ}ÐŽvk2š>2òQ× ›yôASLPkQ¡âZõ>×_À +ZŒvR¸pdÎ& QºÒàî¯E¦âx|E&ù'Ar0Ëèh" ’çÏvÙý½Ï»ÓçêßV¤0²iRÂyO„jßÌé&šH¹£(Âμ4™ +V1-S8`_3D ÝËúÅ7BëbØ r¨Ãt©aÊÓêغ0‰¼•5ï´ñïâ¨Î)9É@[gbL¦')Ä?Ê„ãÐ÷*éT“꟱Eê+ãIõ_â‚R§—«·>noߢiŒ!L½<©35¢$2MIÝs™ôäu¢¨bâ8 ûVÇÌšDT£ä¶"Q TFÉ…Cóuø9dcÝI¥Z’f@A +»<¶ÚL9’00#†ô}à…ê¬ëè¾>€à)†fbˆù†7sÑ¿×ÀÅ}ä׊³ÒgÍ¿?FІæNP˜ké÷2è´à2|Ö§™¥£[¶WDMåtè3?èù:28¢È;Xf1S§³EŠ$´×å0Ä0d—5ŤÐ4|ybæ)OÄ|˜léË@Èu±}µ\"üSÀd5ŒÃkùp ü3ʇ×Î ++˜^p€&9I‘òÝÂcJ-Ù.Eâ.ÂÄSL”„Ä`4œÚÁ¤7\N>frÖi¼ÝÏPüTì,1êÈ@^'èMuèï\ ékJj§^ æü12Ït¦ˆLVéøŠ>iÜ猆ž=ZƒÎÈVO(Îʾu™÷ѶÏÐÔfh=}̹öm{âý”2¶£ÆI±»põ-¾¹+ýZC—±­ËôKo¹‰nÞ”×|ßòË?mztÖ9ÖåçÄe/°¦Õ•äÂúö*~”2è½ÞQšKþ´$Ï*§ú·æøšÿ]íùu¢@ñÁâ°ÆÈzúçîߥnK~£ÒwRdˆµU +”kx±saóÝÒ÷ÁÜ÷Kk ]ö¾ô3 ·/*ÉmÌKgƒwõÇ–ˆýIô‰ù¤ŽòŒ¿Ù=a£ïe€üvû# }Llb9_ÚEƒˆÓFHRòæ›=ë­GýTùH:ñ9ˆe¬ù6PÃ%BÒ§4ž£Ò.n+¿ƒª°ÿ9ÌèÙïc‚4Ã_gÇÓ¶ú‰s+>傹»˜‡¬9,Épª½è!׉·ïhuF ÒiU2Æâ-A6L;iY­"Û ±+hô3…RÝOïi¦¹Í —Š‹ä©ˆÏHžn5÷ò”JDýÉ›³¯pôÝÞó4ÇÃøJ~t‰•|§›19äÚ¸N±)¸}> ˜5.¶5Œ¥¿þ“ <ö¨õëGš±×1{!•Å²ê3‚A-üMÉcÂ[ ×%Üû/¾¶°½9oØPO;fiv±}½•@ÃœJ#(G9j>2š?¤Æ ñ?~ªÑWåïBç¡ÛµO±B¥™Ÿ†ñúÃ&e“v”3†­ÉÞ&™<)ïÈxbý'.¼Ï\Ì_³Ÿ±‡Ý'0þààõªckêUPe¤cne„žÁVó“pÜ Ê½ö>ÄÐ +½c–î3Ó5¬´0ÏÚEdÊŒƒH(‘©,ðÉôä‚Nnád¥,_½ù°/ä +ecŽ¡ñ³b2•ßÃÄœ¯ît¸âËA".0mÕjÛ;÷$èÓ#Ó“]Q;Ò­vü‘‡¦ýO ¢Â{'ˆÈ‚1N ;$F_Õ~@Ü©Jw“+gfCš§¸Aëßå~üv»s=í,€–ƒÔÊ‚ü À† +ÈÃñôß[Ƥ7œàÀfIŸŠ¿iÍPŽêb FDt¨%Sc<ØCÞ±‰¤_¥}#툎~áß\°ÕÃjC¾35𮾌ŠãÖEf˜ä÷q}ÔUp¬$Ú¿•×çyD*û*ݷ÷î@òQŒÞ7¬â¢¾yçã,£êìª%É0®š¹î³È6¸½}ˆŸ^½÷s®Ã´ÔøÛܪ{‚€79»#¼¸ùߣf²sË©W½ørÄ(€Db^Ð*A|üÙÀø乪“ÐzÜÙ™N>uêתͲ, ¤Õè/‡üî¥IM€©*õO ÀgÆC”kìþ‡•Â—•ß×±GJ«€ŸVp+;çÔñG—ó±Ð¶"u¢»}e/—¤ÜbÎò7žÖ®Œ•0ð¥ëŠ[Fv7íXëÕ5Ì›ì¬É„Ac_ü¯ƒò{LEÊgL®ç'õÇlÒé'‹½6I Þž {Ÿ¯¬iëdºOIi옂-i©Š“b«U«B굦 HìK¹cÈŒƒ´úúipÏÈêµE[ªOâáÏx’"‹V)úÌZWïŸÖ‡ƒéüL¯Pã}<ÇY:{ˆÚ%~Ëõ( cΧçƒþCN…ˆ§tO&Žç„V™(7íuq›]©&Ä=5Þ¬£éÖZìržOÔ¯énuÏ)§†£9‚¨¢ß–Eä@Šz?»a`Yû äÄ Vnœþ˜`~i·R‘öÁc\Æ—ïî§%DJ^Ÿ£h˜Ö„ýΨڦ·.Jú«ùt…F^ÈòcXþ3OQ¡d϶0§,÷”Še&uùÙ¾ˆï‡OÄY˼zõ¹Wô,i9d•0nçvKîhQ"K•Q¾Zø@0M¨âÒ¤xÑRõ†‚›ÇŽ$J­´çwR0ˆ+Û6UÕ¾/שM”B®±XÆçÅÚ«'ªM]D›„]ÊQÈî]Ä-ucIg|ÇZÙdŽg>ÂŽï|ê™5È(ü…ëù®êè –ÄмÂNЕë4P“÷ÞÏîèÖ ‡8—‰$—ØBt¹úÑBCšÛöç™yxWûãz×±ÛýD0ϛȘÅñÅ„oJXOWi öì»×.çä_MàSgDd]ÞíR–}Áõ÷ã¶ÂŠ”È[¤«Ý†\~‘_ZÞ}ÕRë\à=cÆmï¢æŸH4Òn˜ ®/™Ë[ßlÏ¢œ\mÓŒ]Ë; 1ÐBVû \±–·´åµ‚µ¯ÊN*I"/ïm?áIÂÙNr©ä —ë?>}7›ùâžàÙZ˜æñ`kËG.¯–*O˃åé]®$£lì©VÌú‚§«/]´~è µW,=ÖÞDÞýQ C96­DñtÏeŘ'”V[ĶtûPðôÝûîú@ò$Æ.ƯúÅœï}ù½Ï *[7›#lUÊ[“|öÄcÃÅšgêDE2_¡ÃMÕ^}üÆkOÛŒäCã±åSPΟZc¯\ð̸™ð '-ÖÄ®1švÆeÐË“=û’Òk÷Óc½æÁ×í%ƒ‰á½: °C¹Ø\Ð`]“˘ˤ¦¸Xºr©·! îη¯Œ_‰_Tó¾ +Ÿó/°Kê¼-œ [—¿çÃq-øz~Ii‡³®>ëGGÈF¶Üšqˆ‹¢À¤^Ý µºÜzœòŽLy*Ø!$ëȯ²È¿Äøý9Àõ—x»Ë+Jé.Õ­”÷yKr¬àKñnD$ïÇÇûùSŽ¸+¹ºfS4æHõ¿ÞzyàÂ*/ç%Šâ׻͠ÏØõæãmº'7]ìå±ÅöK)ØÑÁ@£b…î\çÑÄÝÊ‚×[g“©»U©«ÅÖ¡’v'¯ÔíÌ¥ºiMD?3AqÑgœ‡ ÊŸ¼ίªóÑÓ3NoTšv [YAóOL®·´MHËJ°ý‡ãĬí«å Ä\]NG”¤;F¸<D†ŽR›æ.MÃ>ÂW5ßÏI“1øi^{Ñz·ö´·‰¾¯½bÅ=YV6S$øqr,påÑr·¦s<Ýþº•l+¢dÙôú~«ÉR1xøà`äÛÔ€²K[å.Nµ;ãUûŒ2ó¾jÂÓ’D€Ì»«™Ï5o~"Çý'…|¤0i"í.>_0'BT¦ž¹{Ñ`IíJÓ(`ÌW¾­ÇaKPÓŒSÃ$(L÷8k•·ýAcc·òd3–âm¸L>b@”©k?OÙ#ün*3oÄHóÉÐàCíúd“GW;¯y‡™¬.÷Ì¡@Ðñ}“à¤Ô-´ý^½R¸'EæòÑ¡wuº>ó<5{Ž´€KÃ7®Ì[NŠpÓèªÉš•Q•Ýk|}kÑçc(?72•­ã»9 +Òí¸FúïšyË«mn£°MWÑl‡ög2w™SçäSCþ¹A¡‰&Š²Èkª|3Ø`ê‡ÄcïÑ+Ó\ºŽ’3®óø‚ÿVŽ W$ÜÉÂÕð_0y§endstream +endobj +1580 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 66 +/LastChar 78 +/Widths 2094 0 R +/BaseFont /URQILA+URWPalladioL-BoldItal +/FontDescriptor 1578 0 R +>> endobj +1578 0 obj << +/Ascent 728 +/CapHeight 669 +/Descent -256 +/FontName /URQILA+URWPalladioL-BoldItal +/ItalicAngle -9.9 +/StemV 114 +/XHeight 469 +/FontBBox [-170 -300 1073 935] +/Flags 4 +/CharSet (/B/D/I/N) +/FontFile 1579 0 R +>> endobj +2094 0 obj +[667 0 778 0 0 0 0 389 0 0 0 0 778 ] +endobj +1366 0 obj << +/Length1 771 +/Length2 1151 +/Length3 532 +/Length 1711 +/Filter /FlateDecode +>> +stream +xÚíRiTSבª¡¬2©¤j=,ŒiF !¡€D ¢a”Abî ¹%¹—^n )ƒˆ•TeYÄF—Œ¢¢TXUê€RK¬B 8‘VJXÖ"U«"àÔ ÖÕUúó½_o½sþœýíïìýïlš[„Œ!‚° p0† “#R©„Ãä™Í¦Ðh8,' ’°p/°R«Üe€Íò– y| + bizIQÀ#>Aâ‘Æ…R9¡‚5d …\ d˜ =ˆÔj°vâF:X §Ãx 1)€6À)JaMh’ J ðßÀ6ím*ÆÓIQÀcR&"! Uë+)¬pŒì“Zþ²¦ÖªÕárÍDùI§þ•—kµþ/¦IÓ0¤ãèTj üFœ†­fjVBÈÕˆB„¦¨aÀà,g²—¿Á‘ô`DC¡P¥\Oâ0 +MUBú7©ƒµZíù××N&#äJDêÓ`Àþ›=sþŽI“pDâÙL6›CÉýö”8¥™U`‚¦.Ï Èq\®§CDF<Å +Á:ëHÅ,&Šä@:“”N™øW/6`©áôô ô À¬”‰Ù#Ý›Àþý´€L—ÅXÆ .lÅ^î ø¤Aoc%Bz +Ã:XA1ßÀ>[>Þ{j[M®¸ªó¨-=}¾ñð–ös[O}˜C½>N×ðÆ#áþpÜêø1rÌ¡d8ì+¤äõQO‰²MY2ÖÖG“½ ½bŸlÆÅPBÒ´Kem­ïil¿k^hIkô|ð“ûÓ;çlëVÝãð+©Ã…ÓknÞxù87ucGŸÙîKÈ}°„’XvzÕ8ú×;EWÆï‡`U˜¹úÒÜ„}O_™©­·»SoÙ†2©Íu£ï‹YlºNÙßAáìO]hŽ-¬” gÎ÷º]nVïûºcýš›Â¤¿Ïè¢ ÜŒïvKòsJBc$Q#óŽV8)jæ©}Cª©Öp}ëºz¡ÀR¿&ß)µ¾“ë[ÌIkÜC[›<ö’öÇ¢ÓŸ$>ÞûìµÚò@‘åfåz|ZŒ§÷~ÿ Ï!z;›j{õ3“[œ\õÅ]BäÚk·ÂЦùÁ¿?»yT +b×ó\nùÌÝ̥܎iö–(]çùu“iw‚Xg%ˆ»ˆ~Ô_ùð·‹-†ýܤàÀøÞä3‘7=/Õ6œ¯ +r®-˜žhj +®ZÔ4ë˜ëæç<ßg¶ƒ(Á T;ͺuE÷Ug³xãc Ž ½t¿ðü±$ÊÔ8|ØkA®íàæy©;™÷#—fyÿns.¬6Yßé]{Âôýœ%{¡ÈlÆš½©ÇjÂj¶iô³öÔ?äØ”gŸ}"júNY†:°O—ÒÛhë/×>"Š"žW&3ñ8ÿ3-­(ŽZŽeepϬ^ÏóIHyÕíwxíÁê¬]<º¹|Áöõ¡]Ï€€š&þ´$÷õ–‘ž­£¸©=ÞŒÞ=j¼ý}"Ø|ö £ÖÝ7ö«Å~-Ժ󿌮XÃà:*#³Øê8ÏBëþqÔ\©©u¡A.–Kò³«Iêü­ä‰+jjN3l &h‡^ž¨*‰fåZzVœôr#VV +QÙbÉ)õR«i·§>.qµ<Å7¸Êo(ß ùߪˆX7R1î{§k\›ç|y¸°ãçÓˤJéëxÙžä¹ÊL½®sNfSWé<‡r] ÃcËéÕYŸs¿8ehÜd5—D@ßX«Ú·]s¾m¯álŽè¸ÏŽÄväÛ¼›S¸’Jý5,®Õí« -µôÙq13êýÓh×RqÉ+ë¸èºÁv버C\¡S£¢±Þ°ûBe±ýGÑê@¼42_Ñv+ióÊ!i]Ãñ]vÛ9UÙÅ]³ šgÌß±é'—GK2d_®ó;ÇÏψ>ÌëóŸõ­ûÂ"%åœ,WH¹+î Í~æÿÝ{Ð;¶A#‹Çœ1<·¨zO{—K†.wŠn¶î¦Õv©›ªK vKg×8­'ÄáPûeáUß]íÅí¼OÚƨKˆ¯âO.uùZŸ\Ä ê6< iY• ¡‡[° ûðÞF§6f^ž¨4 ëúÎaURCǵ²¼ŸÑ(Yu¼­jß,NT˯m¾P`3ãÞWâ>ý&¹š?0z^Ü’xµçó‘5;ø/̉,zbCN¬èæÍ1ox’q(¿ŠZÛÏþåÿþ' +(Ô°'0O¥ü ÛGŒŸendstream +endobj +1367 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2095 0 R +/FirstChar 60 +/LastChar 62 +/Widths 2096 0 R +/BaseFont /OICPNV+CMMI10 +/FontDescriptor 1365 0 R +>> endobj +1365 0 obj << +/Ascent 694 +/CapHeight 683 +/Descent -194 +/FontName /OICPNV+CMMI10 +/ItalicAngle -14.04 +/StemV 72 +/XHeight 431 +/FontBBox [-32 -250 1048 750] +/Flags 4 +/CharSet (/less/greater) +/FontFile 1366 0 R +>> endobj +2096 0 obj +[778 0 778 ] +endobj +2095 0 obj << +/Type /Encoding +/Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef] +>> endobj +1052 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(m XÃà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ÈdM oÅÏØ'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–?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Úüì|*endstream +endobj +1053 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 36 +/LastChar 121 +/Widths 2097 0 R +/BaseFont /ZKLPWP+NimbusSanL-Bold +/FontDescriptor 1051 0 R +>> endobj +1051 0 obj << +/Ascent 722 +/CapHeight 722 +/Descent -217 +/FontName /ZKLPWP+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 1052 0 R +>> endobj +2097 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 +1049 0 obj << +/Length1 1166 +/Length2 8309 +/Length3 544 +/Length 9124 +/Filter /FlateDecode +>> +stream +xÚízeTÛÖ-– ‡à „à. îîîN4Òî‚÷àÁ-ÁÝÝBp—sîwî}÷Üû~½o¼îµ÷š«æÚkîY£ªÆ(JufQ 3”ÆÌÎÂÆTÛ›¹@ÕM! +Ìj +àsÛ@C£†Ùþ~ÄA¦0°DÂöŒkX»Ml@v6>¶÷|ÜìÏc6οœù€*Î`{O  +r¶Cž! s{¦îâèhY¨ .Îæ (ÐòyeÿY(îàèá ¶²†é4Õ´é™þaçååšyü…%@P°øöyà +²spü£Ò3…4r~^´Å¹*–¦’`Øíé¬a0G>VVGKSÐsŒjÉÁXéŸ* ±w°ÿƒ +øC3 °3Èü¹)Ö¿ëf qpƒxýGØ ±ø³% GVMØÉ$+ñ?ÉÏ!À¿bV ›ƒ—r‚ÜÍ­Yÿ(©ááúdÿ#l +±ðörtpZšÚAAÞ`KÐóà5uaÎ. o¯ÿø÷€h6‡Í@VÏÛð/öç0ÈòsES˜3بÏÆÂÆÆdûãÿÏ‘áó†Z8@ì<þ•®dj²Š*ȨÈ)2þ½÷f‰‰98–D2ê›-¯X 2n‚LñK€ú +ÝØ)[7q\ä딬Ÿâ}2Ç”¥Wº4BâÃ8êÁø¾d7z»{NÊ/IÈKsËQ•÷fèy eì|Tù^N ~“`³ IA“k¯¿¥•ÓC«?¸Æ-oÃ1™žéÃàö +–ÀªOÌHt‹ßñ}n縳.i±¼«tÌå–ã4t\dêÍFÔÏZïÖEη2Úú`¿Lè-Š²FsŽ]Ä!JÞlø*@çìwÓ>ׇ&ª©æˆy²¥@¥]kU>=­rEÞ-çŠÇ™°V£¨ÙaQmL1!h²R%^×àj¸Öl;ÓÛì^R‹×5{/¶ ¸»ßËwU°s:NXµ‘÷ +8ÆßÆûOvj(øÏñTÔ¤\¥+Ö#2\…¿n5;ÿH¯i}¤ß®£Ñå~º9$m`Ƶ'4É)ù6b›•½.†eC[•+ÚËG}*”µ>A¼­dÏGæjøf¬%€Ê4ìªÉ$›Š ÛwÃPoÄd‰÷ú´ÊÈÓƒ8~Gžõ‘÷Èe¦_h‘Q¤Ç‹×g\<©‡3Ѿ¯òJ­’ûÁ«‘e‚gìº N¦bŽO+ÞÀ“îS­™c­Hœ4ÞCØKH÷²m:§dÔ’ÆC»t½€!…Âæ©.—IóÉ^!Øæ¾ÔD’ZÐZ¢˜ÝËMïQ•¦ùÜȇ®CÄTÄZÅ‚zŽz­‹Ä#EÄ7ÏLm}.éF?:ÃÓ¬v­Ä3*ŸH“¾˜sLfZžÓ$Vf‹B4®»%DÚ”6òÛì!Ó7ôRI¿S{ŽØ¸Õü ØKÒG;ë¢Od€V@Sp¾¿–_Û«°ÅníË5n̈XÛØ~ô¡ ½ÖRb…LKúÄ6!T²ªNËg¡å‹Åí„\æ |7AÏâO“fgYPg~ø¡õ´Æϳ譑!†Øç]äÆÀ +eÀ_±2äÀéŠê×Ü÷qóºÄÃfhÙzÇð#e6Pw=3vd[¼¶#mýç;±ýO߇P÷LèLI Š `ßy·bgh¶£ûô•À|ª¿2Õ 1äÔ@ßX ˆãàç¹ÒH_Li¹=YK/0¯§E ÒÀ(èù\²ÈÖ«:˜ðCÃkX[ÐBf µÝ÷l¼ +¥ô€áëÖKŒ× m5X€>ÚíÀ½ æؙԄ(QjiVJÒ˜˜¢`ßÛCÄ9UoðzÙ„íÖðWvªD+žoÜhe…Rj;5ö}_”òWЖõoD…åö|ký—¹&ùü5jÖC±8.’óÓYª´'åÉrö'À+Þ@ÖŠt¦ïØÀf p2:7ßu°%¤STÇ9-g9ÜX–ÙG]td1KâƒÑŠQ¶SF$‰·U¥8:ï¾Ó5Ÿ½OÜÇ'vp¦3gGp|wã›À„J÷Wó¯c¶LLËFÊY7pŠäh·nK.q ¥'Œ/®Â9bŽ‡±Ïw 9_2ÇÐfÊê¶VWdÞ·¸áË™w7‰œ"Óù}R4T˾jVø?âó~:Ãí1~uÊæ|*€Ó”ʱŒ«HÂ@pÎúNšú 7¹á8[³?p~¨y4Ñ5r€»ö£õ5C6Œæѵ,âM˜“ÕQÓ8®‚ùÐùU7 ¬Ûþ§>S+zâŸ[VÑUŠ<¥< s²Ê&:Nð )ÎIJÀÃTãÃX×ò„W• ¥jƒddŸv¤øZ’¾p›Kv£ZmÜ"Osë“(šn­¦ô¶yëŒZ¿gó!™PˆÉVŽõä†þ… k¥Hó'´åå0‰’šÉÍq Ž\±Ÿ‘’® Û¾Õeq_*Z¨ÒZ>ÍÆÀ¸ü¾m!Wò §ØiON²¥:LÆÁ·::¤¼Öe8èšDŽ^®´õÎ÷WàÓ;ú…co÷ +ÓsñŸ¬5ŠN!úŠNÌJiJ¥…+kkŸÏÆròæ¢ß ÛŠ)Äxžcé\Œ>Ð~í.í¯râ<èªëf׌Óy¬VÑ‹ÌYÝn§ FÈK Rd"1f…U´†ÇŠŠ”> ¿¬öH‰Bç9Ÿâ‚â%¨„$‘ûò$,gÊóMV0êôÈ­ž·ñQÔ‡‡´æ¦-‚¢óßÐÙÕþúiU:Ö-/P°Ø/%ëºAwð˜Mwk¾¿úñò›ž¨bØ©ÕEú‹÷1¼»ãÅò—{*7¯ú–eß0_.Ä?”?0: |‹Ô¡b9K½JöòÖ+Ÿ{îÞŸ©p.îë°Fˆàú75ÚT­7¬uÈìrAéÝLK4ýGý?!‘ZîäšeŒ¢#hty0£„†I^Øpw»‹õÄ/&Ä%fV-G¥ôñL8å”çѨHBr¯Ÿ­ùØóå]‘L.÷Þ”*V†Í•êüõ¡KlÜK–C†àh8%QoHZ‘×à-–šÒ‘Ô©2‹áâ"ï4ΡÇ%3£Ë!¾Ê¦ÉZý!üÌ#4øcð©“±¦¨vŠ9dB?(‹N=¦{®žu3$‘dàÝÊP^ãû%æ$±†Øx˜ØŒLûkmË‹‡ýˆ8NkšÈÙR,€ñ9#áEÅè§*ÿc¤7¡ ±sù‘$VƒpÐ3šZäñísG +åƒb3èu¯ÃízSHø”Ç!=ÐSV«ènÞèõÐ`åÍ’ª;qg?Ìj†o+ÌÊ€/F;=!`ž· ÀË!¢Ëþiú)*z‘ñÄïø.ëœØ½ 8Òà4AgÉ—õ:fÞv\JÞàrdqÍxøœ]€GÞ‡¿SÓ“9ïiŸ`ã´U´{*=©›ö„%R–ë×M[«'0¨º~×ÔZ]—röUňaÖ·<šúµìH±Jþu"­îIV5‰¹! ˽/Insã°žÆõªª<{Ïñ5gÝl ‡×;{•¬)’#ÐJ¾çzYÅçµ32%2I)OÊ>IhJãÕµÅWobAnK:B¡&ÐítEM•ËÜf-¾¢®Ë&Iº5?RDƒ} 3ez¯jcCçÀÞ½‘SÐìp)WZ¦gâjpå‰Ë6ÓŽ\‡£;vj¼ÍSl·kVÆäø÷õíþ¬ú6-A~H<ÔVï÷3ÎX7ñߟ&7$S/·ý²Ø£ÕY1ê¢Ø‘Åe5Òlß}Hù nû>…!Í:Äè¼Î/à·ŽýßMHÙµ¢ñsÕÝ"=4‰yz-Ú§ÀNèůzYj”7ÎÏ=k|ëæ] Iš>ÒL£ÄSØùIÌÓJm?IrÈ‚U¥›/ΛaÞñ)ƒ²D>´ïËKÃîÆÕ,ao$ÎdiÀ©ˆ¦7õ­œåê¥Æ7Hõ‰‹^ÃõÕÛÓÚ®Œ¶°ÇÚÆÌ_¦/Ä‘ ØM¢Sl'µII37JDÁxñš®3S¤å;Ü_rÝ’}Ò³ôò^Ü%.)ž7è!73iÓXƒÂ]r+œw"ëȦhá¯àûŒ½Ð Ú´Yä㺾ñüe?¾ [÷§“è‹MóûVö›ºÞwqt–Åw¦‘Ϩ°Óì¬è` „ì¿ßJãóf?6f'õ\ÇŒEià[ÿœ«×¨ØU»zšü[I¹hÜŸ#hÇKIçén ­R¹õ–Öi˜ž‰bш˜×5É/ÔÆu,Ì@{–‡Uºya)¨Ì˜:m/¼_iÿÓRÛå8"ž•‰6/Åfþìû—o bæ ‚¯¶ð^'d¦þ( ÷ÉšƒojþMóSêÌE¤]KS9ðHe&Ôz“Û×@U¥)zâ®|ä!aæÇûë<Ýžœ‚À%»Í=¿¦¡jÐ.‘¨µTW4Ô>½Î¯/¥^6|ð:u›Ð5™ ®õ+.›ÿÒ`þxüJYék!øTB¥(P’êi|`þ®0ymc¤ò+©ž ÐÎÏßDMøÈ© ;ßnF$¾¾xïÍÿ^õÆ·OF4ìJ²Ãþa8÷üL_šfÑÜ;’I—¼@öÃè‹VÊ‘¤¸Ý$l¤Ðn€¬¡¬æ04q|ˆ¿œ§à]Û;˜bù«ã›Ý öìô(Ôjo]º¿?Ásîit;ä +L^e°ls›NäºÔ§ßýšR6úù¤Û°éµÁkkùéÓü½I°±U-«a¾rBïñØ;e9Ïx¡‹K€q("Ãßj¯mµW.~ØÛüÔÚuf«ù)ýûU=¼?R‹ï7éÙ5ĺºWéŽò¹ÊaÉ[Ð4Œ@Çrßg|óy¢X–%}ƒ _l3÷ó*CÈz:â0ÂÈ(PóÇŽZÝô†vÌ£1Í5KUFêçöóÉ„¨Bß¹DóV¿ý\öâ•GþÐò$uI“!š›*«±5í1ÀÌD(©u›P¹©üò®¤Ãóãõ€2^DõÚTnÀo—£AÜžÈ77lŽ×¿2+ó33£‚…VØsùÜÁ&ùK + + ×yLˆßº§(Pœ(4Ä3dBmÝkÇ–?v7‹]çì£ PܹïÏ›ËèÓ}@ NdàÛæ]KT/¶@\¤·t‡Ÿ1jà1†œ]ú?p»~ˆÎV”PMy­ŸÍ~ÙçºtóÒ¾_ûᦗGPòÓu-+{Nüß"pÉU‰¹ýÕê-¨Æ·`EF^pÈ}‚%ׂ,”Á—¤O3‡PÍ2E4ÉGÿëaµÎ à§6Õ}›ê×4Q㦷^ÓÙw›«Z+J6lrÎ # s Ð<£ä3ÐfÅç¢ +ð(8ôðY&Ò”}„yäÖ5ð±KêÑ&Ek)Oá†x°ñîs=BˆFÆðïDœxѯÁÛìÍ㓶‹]Õ¼ô½Ó lIÃÏ6<<*°OÖehÞÁ»GÝ„1S¯¿–Z£K§ïË·nN ¾X{\»€#P/ö梢֜«8Ö–¨²²5 8~««Q›s(ƒé¨Ô,Ž­ÁŸn‰vÆ­Æôòç>65˜[P^·Œç"K)u€t3‘5¢²_xËœBÏ1ä_X™ÍÇ¿Êw3Ù%%T2(>b‡r©ê×ÆjÓhÁ8©téññê9¢ùE5’~4¦*%‘'0`W"ÆæÜ" Ní1FûÎÎBâ$¼æÜq[Ü£ef¤°À9t„-„BÆKG«•Ñ2Ä.«j/‰µ/$¤ji½õ4&oØwãI¥»¢w¼6á-UFK»· ñû*­Äfk›öx‘Ô—í"ÃHmKêg@ˆ{(#¼’YD¹ÿBž›ì1ºU5Õ{˜_«H׿ÝbGû ‡*¶†u„üθ­ßáSœáxDž$q*€›¯å ’Ú‚…ÆTHAøiGõ<h7¸Zt³ÁìãX4G’Tßä±£h^ŠÃw­v2¢%%¦2äÁ0æïð¥ŽÀëÚ|Å}sÌ;Á»‡F!GÞßâýë_í\z& ‰hÍ¡ñn€4©D2©b  Ê‚ÎŽ3Ü£fü’1¯æ‚±Ê¶¶f›'C9qoÝ ×ÊÐh´À­J7ŽW1ÒžB*»élMäYyÝ£k­“þ]ÎŽ‚ÁNÌúÔ6¸Å–=h¾Ÿ/š>e +4; ÃkÊZTwïG¶¾htû»Ï4êªÖR¡Þ'­ DIn>˜Qâܤ¹*'_I¦äÆ6 ¦æ>»\<º¿UQ, ‘baà&#ç^ËmÛÝ[oâù$Ç©e$òÔqµ=¿=jY ÄPs˜³ûD<‰™*Jß–¡£fo,_mSBºØɾ z ªS Q_øi¼ÔR@¯KFÀ®+µ™øìiåÁMwš”¶µ<ñiÒ^ìjg–Öëã~f쇬òÑK§kY¤ÓÅx +¾¨¾TKÛzÌ‚Ä?éÁÓ€¡^ É”eÁ.5-]ãPò÷2× EQà{‚°rëáÞ8,~;;ÁWâŒÄ¯Fõ9ŠCá•Øí9c{û¸´pö²ÃŒN¸4ðÚÑù/ààWðö“µËcÌÜM¿À“¡-¿*{ÝÒÙ9ò*N²Žå ¥÷„I3ŽÖ #‰³¤~–”@¸ÂfÅÆ®»¢H2#ÌǸW·£M˜øð‡ÂMOa~Hî÷ñRj¬ nÓ‹ê÷\J”.„sÆ«ño) +j[ÕeÀUoóOõe¹#´M7îL°”XËzÛƒñ…Œ‚´Wvû¼‰¼†Æ«<¶eªhYÃ<ÀæþÆêè²o¦ B‹Ï¯¢:YAW󹄛é_³óöÛЛë7.ï.¹m{(Az>oɧÊé^˜ë@Zc—‰7*wÈê +›»WVö]°dÙ®ã\öý™fÛµ‰t9¶¤V}îñìÝØì¾Vᱸ¨Ô3Z( -ógWÎà iÔ“g±Âî1µúnG¿Õi/ Ö®aª\z6wH5VkÃÂXŒYg týSH}vˆqé-ÂY/Dbø¼ýdyP8s +$RÇÌvé…h'w$K´|†·í…§™;Y¸ñç?óg›+HGÓðF~pQD=YwW´äL;v£ˆ§&Ì3p}OG_½¼¯2y¼¢@Õï·URåo<õ4"¶ÐþÁ€àþ2½öÝCI;¥ €)ª¤ÿéì¼Íµ¾ZnùˆÛ„œß~‹øŒþ—¢@™ðÔ6!†%ÿKu9Èš¸ØA`ŸÊŒa¦ ±¾!¿¯yÙ´FmîLRÂöqu8.ó‹j5Žó®Ö?ÍžÉÎÅ¿ïÅ4‡ôc…g96·¼ oìŽ~¬ðBGÆY6-¹ª…M6õÐêY Z`–ÄR:´t‰¡¼JÆB ÂP™\µÔäœöF-ÂâÉb[&èëÛXåõ‡ R'䄉¥ü"Üñý"É)¥F{WqÜj³‡h!YNéðˆ~~ò"ÙÐ5Œ©»Xçà ‡‹-Ýxä%ñqÉ>ÿó1¹rP*#7 +¶²çìÞê’ñ¬Õ(àmÆÊÞš± ~µnH¤a0³•JT½6‹’¾eËŒL£õ•ÃSóM ›ºá8'#-¹É\ÕÕW«£¡è)͓ᤛ±AççÆl‘ tΗm;"‘¿¾:A½K£ãcôF‘–m PÕ̆3s§$Ç`ÝÈbwÈæ!Þ)‚þTìû k±oqË»g™o˜:™Æ®Xå‡S:´ žø&i{ºˆÞ ó}ÜÕG”twÏ8»ŠÂŽ¥™r&âgؘz^?6×ÐP)ÕâIî–}ú¡hö‘k±+:ÐÏÊ®®ˆ“¤0ÞÇ}#3¼;ßٳƼJ£oèߟ„¡!}|Wš|÷ŽCdI‚¤¥ZÂ?Bë̦3uqà¢?Ò¨D,FTÈÏ,ÔvˆX3íÊQ–Y˜dª¾LÇA8^ÛI6—¬¹R –-uÞmR¼óIs] 2Åúxd«ät9÷9Ñ༡ßB-B ©Ë¦J Ï;gÇÐ ¹Ndfg|§µHOÐeßóšëºšj/{f1Ê=Ä~Æ«½ó±;wjS¯FûuвÕÐùåôX¯C%‚v“µãe»ò-jÒkë-âd¤/1Tĉ>ü² Æç{¶—|ûÅ´¾F¤¯2Ä3Ò—ùôüÚʆzNŸ¦·”‚5áz;κ7MšVà9>›.¦.7UüðD= +Ëȯúô$ šü=Z¤ïs£öjïM ­È"±óBc!¤d³£©Ëb”ű‰„g²@›€³y‹u[ñBQÊüñ‡2+QÉnÎÕ…lÍ É¬Ë½p¤+M)zÙ>û!Ÿ>ÅÏ +¢ï,Ý™Š£°ƒûüµ±ÒI‡c&”ü¼ün®'ñ°~ÅH¿ßýø ‡é+RúŸRû#Ì»’ŒŒ[È1Z‚«„äî<úüEþ„þ'¢DEPˆ¨½|”‘s¼j#U(»1é·–½,ÝÓ4Ešç×Ü WŸuÓ‚S{:D¦àæ }ª¯ÏB%Ö^‰$—Y –Œ8Ǹ %³šc&h˜!ç¹ÙG£ÀŽ–+([;3ˆý¡ŸA`´ž°ç£G°øªlV˜SÞRÿS”W~V'¦—,É*ZÊÿëH™­ >FþrRZ§³¹™ª$@!È¿Æf'%N¯Íqg'á4¤ÄÛeù+¡D‚A¿x0J1»ôÖ©Cøp:©¡Ý69‡Ñr;âš>ã|º‹Úˆ²;h“Ùé gÖÐŒíõÒ½Ó’iH)è¿iŸö&Iû RKÈÜ-‹Åx°VÅ Ec°ÖH·1ÁïX™hF¸íµnQtCç¬``*s¬Räxƃ<¬ˆI·$¿Ã“,Wp¨þ>VDI`×Ï!JØÁÁH¡aÆJC××J\ë(üÕ7“íÿòøÿÿO˜ÛLaö¦Î¶/gæàüÇgR€ÿ®äendstream +endobj +1050 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 2 +/LastChar 151 +/Widths 2098 0 R +/BaseFont /ALHPJM+NimbusSanL-Regu +/FontDescriptor 1048 0 R +>> endobj +1048 0 obj << +/Ascent 712 +/CapHeight 712 +/Descent -213 +/FontName /ALHPJM+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/endash/emdash) +/FontFile 1049 0 R +>> endobj +2098 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 556 1000 ] +endobj +1024 0 obj << +/Length1 1624 +/Length2 8579 +/Length3 532 +/Length 9445 +/Filter /FlateDecode +>> +stream +xÚíwePœë–.Npwkîî îNpo Fº¡iÜ‚ \Ü!Á îî4¸CȽï™3uîüš9¿nÝ®ê®ï]ÏZÏÒw}ÕLôÚ¯¸dl¡Ö E(ÎÅÇÍ+лX{¸k@!ê\²Pg[-kg0à Âdb’ƒ€p0"„ƒÄ† [€<ÈÀÏàÃdÈA]}``{8€U_׃ƒóŸ’?*kŸ O–î`{€ùéÁä uuAàOÿcÃW îØA9-mcM%«’¦>@ Á€Îm§Tlê`ÄÄ°ƒÂÎ6Pˆ-øOjîÜO\2î ÀÝd~2yÛ€\ÿ@œWÌìîþô »ìa@ü©p( ±qö°ýÀ“ÜúW@®0蓆ËöD¦ u‡»ÛÀÀ®pÀ“WmyÅ¿ã„;á|»ƒŸ`ÔîIÓjãñ'¥¿°'š'CÜp7ü/kÀìîê ôyòýDæ +ÿ†‡;bÿÏ80=fë rw¢yâþSæ ø/Ù]]}þ²†þ¥õŸ1€áî g;nL>þ'Ÿ6ð'ßö`&ÏŸaQØA|¼Ëm=\ÿy‚`ˆõÏÌ°=´…Bœ}¶ ;LM(üÉ%€õÖeî_“ÿ -þ·4øßÒÞÿ]sÿµGÿåÿoïó¿R+z8;k]žàï%xÚ2P€:àÏžüY4n ÿËèvöùo¬þUÑôw¤ÈþSŸÊ!±j ?7ïßb°»"Ød« †Û8ì€ÎOÕúK®±ÁœÁÐSWÿ*è“/ï¿`z`'ÈŸò ý ¶ÿûS£þŠœGAAOÍؘã¿Û­ij?Í\ÏÇø?n 5 ¶ÿyøÃ#+ õøq ó¸øED¢‚¼Q¾€ÿÆã_4|ÿ³ß]¶UÙwºHY:Ó@'ÔÏÙ¾¬2·‰pì„òX”àdÆùΨ¯£˜óìlŽèèZ|ø…F3Ö&{vzËüܳ0˜˜ñÆ7Ð&½þ I;~#amÑ÷Cæ”ýÛ–ÞÁ¯ý}ç¨_¶©8rß`0Ix¢à0Ç»åRI™èWøÅ0¾T&À2K‘cXöà ŒñC¤[ÔÉ¿&˜,£u®NKz½A„þßlH‹µc@™ê +qh<ë/=íq|ÜÞ>“f¾WV “Ž]m(;Íe J[<ÃaÃlœùb\¾¡ æúžè×}#-#ÈÉq©¾çeÏ[9Já¼ù¢_¸ØWaøáÖß +ié”ç-ÚX'ÕE1xãÕ^r%LSõ)çœ+眛 Ë +õÞÇÂ[&Zêy#ƒ0Xæ]&òCO#ÅÛ¤ø²¹2Eí úIlºgÌéÝ·akÃÎÇáòû¥Næ ´ÃöÚ™5ÍËÓV¾“/M,-±çDÇZÛ>Wk˜DCÏ7rRIÝŸ’¬ð1È‹diøÚ¿Sü€Ar%çÎ{*“AèÊôŽÙ.… ®mÏ«Í–ÐW®ýkD -ca¥ˆ:ÚŒás#ñ€îÀpolí›ò¾°ÍDŠNsíò2¸‚Ö#Œe +·&üÖ!Bë}àBA¨ÛÀΡXÐm|¢]æpvKºXKõ‹•‚Eí3MâɤáÝìdtÉa~´K_\ â4HÎý**iœ·É\Ìe:ŸHÄ6]«W•}]¿­ÑêS%S´w< Ü‹åîOìkkQ^¸ù‹Kû`ïJí¦¼W&MÕ½%)–›D6Bc<\ë¿ï’+8H„ +uŸ1Í‹K +|TúÁ.øó-x{dœñØZWäû¬eÙ—n¶R^v&ëgD& Ê&>2P&õ£±•_aG*Þëýï°`eNNAU{yßÅi\îÓÇê#‹0xðØï†×c¥•¾\ûõL$ü•ü¦ð·ÒæªØ,ªl'<]ÔLI½à†ž­Ñ¦°¥ú_Ûµtk2aÁŽ§ØÚC~4¶âµm1²¯I+ðí^a ¤Ft(†VP É Ç[è>C×ÿ:_!yà»uµ ÎVfVúôz–ÙÀOX¨{ëµW°{מQcVõª)ÝŠ…?÷dɱ8~EÎHo)3'ï÷*Ò]_™¾ÓÄÔ~Ÿ®vx¥ÞòÊ¡ÀØÕ&˜žØHHyÛbœ6ÅFÝM ÆèD,y5¨˜ ß~2‘{Yî ”±¥¥r¢­ãÉÕ>»8Ÿz“ –R…•RÒõÐò˜ç·ÇoÐÁÀTÊ]ÈÂD9îæìðêàkÎdߨ².pÔáò[ ¥`«Ë„‰ä9“2Cƒ‘i‡“žÆáWö.—6Æ™ÖE(}Ruã̱«˜10Ë _S0-ÏkH“¢JéG³ÂÌV³ßz/gѺÇ;Öö#ejö¨0Øt5¤^yE½mqÝ(X q(Ú2”*n#œ³tWtV¡èžã`Yõ±Á±º l/W¢Ù©kü:e·´\úö†K+=à7éë¥ý7§B´ÌYUÄØŒbTáœü"¡ o–ãú£ùwh rU ‡¾á%y›?qp©V«?e4¯Ue iPŽ—YFüF$Má…­s¥E>œŸ²G»ˆÏIÝ®6‰"t:Jí¿Sy“]Åá·IߠȼhåiÖ'«šÜÝ_Û¯Abí±šŒbuQç“:)õµÕÃR)Xß–j“rJ=Úð†6þÒË+ï«‹ jvð©´OÞ'”¥‰änÑ ›éí’Lp¤Xk²W:=KO$ÛÝó#VÅ­Ý Gèwua[¿ÍL5DIÊiÜ·Bj «½x[$K@"šà­ ’ìeÀ¸„^Y·5o`f^œñ2é…ÎXÐï•rN}þix—PÕÊ WõÀÍê݉ aä{âÕÃÄ¢%F'SÛI-ºàLÉž@«ò­Vê–¹Ö‹y+ƒM"º%ãÁÞ÷d¨Oª<ïË5F¸½‡·¨t'ù :rÕت}O¥nÌåðêsú|I5cd ô<™Çë,©ŽO¡ÏtûgM]O ááÓ÷ƒ™YÌzt/xßõk?ÖH¬¾·ç±SÅånÍT3‹št:°#ž'º +ýL?ë´êpUn¿TöùVnEÁê?Ø×_¾´pãúâ`(ý”b z@¾‡ínüºSw©õÙ,"ÃeçÝ4b‹x™-R†ÁÊÚî™â “”„üKKëšÄ¶´Ÿ­äü”Fõ.Ÿ1´c~¯U¹¯M]p¤)ûIoΰ2$Z`8+B5®Óµ³ÎJ}ô²?ä\ –³[¢›.ü ¤Æ°Yd¶SêZDh»¹áYºœü€~IÒG>\ {áxÊ/õÉ®[ávÅË/¡‡')Ù®oº«;ùqÄuj 4Ö„bùàgÈ•ÝçOñsÆJŠwí^ùÏõ £†þè©ÿj/(xý¬Úñõôó//]ÈÝÅüæOë~Ó×ʶ•àt`e/ûïè ãûcOû) …WU/“Ñ‚¯Í–Þ´Gù­ÙïÜwTîÏW.¼)ð—«{žÿE4%ŽxôÕ×ñO‰Ö¡ìѱüBú®^?² Ò7Ú‡6i–”“´šü»;ÈÂœ{Ô¯6-®dó7 +DŽãlÀŸ_¶—s@“Mú§„ây¬ödæº/ŠP‡}øe(x¿ÔR^¾ŠÎæ +5ËéZôO±N>%¨ˆ¹aâôOZ3)€å}íÖN¤§fQrÍ›d²~©d›Ã«°]µmä_—–õo‡öé´6š·§¯t`0ˆ'¬bXšz˜g­âA;Ìƺ‡:ÄŽ/0´ ³’YÍ“Ó^O¬œ.~èÿé“1 m«ð(¦Ìÿ#~+ÿÄ@è…†–1‡¬üþÖZš‡ÑÏMŽc…#ë,…põ «—½ ãQ›q„~ݶDwRÉ­±­ðç}ˆãêЀlqâÂmƒéN¡òºât»ÉÒy•qÝGŽó©6ƒïXd,7DýiF}/JáP*Z°ýƒ[ïÊñåx´NÞl¾d¯÷ÝêèïM‹Í¼:,ýdÅx#µÅøÇ—ÄæÂч7jèÜÛÓáöâ¡Ï˲¬¸x›·wê¾Â'_=Sz<Ï,NîË!É.öš«çY¢¬-j=-¨¦a”%m].'Û¦œ|ó+êçÞ Û!)Žoh\ð(~r£hc*o±q× q+fõ³ïóäÒå62†™·«ª vVij^×Lb‰—'ä¦ÜÌÖR8ˆ +à–¨ÞÏÙCãr±`Í1º'Þ3©$.GæEHÇçʚʗrhüúŸ·Òb¥éuž!&¨qΉ6öQnªÒ$:ZC}˜i%¹Ê­»ßàÅË]¡;J¤ü¥íÄáÈ¡¥æê?^0ß-±9,ƒÖ?¾oŠ¯*4ë™XÏ¢ÔVúåœó5Ë%`*fÝÓ áõ €¹Jx¬ŸÁ«|ÉÜ-MW¸Æ1–Máù*ȼRé¹!;vúŽËE”¨Km+F´ˆ´zç*ëئ‰å›«ŠÍ5¥êi¼Áa}4ÞU•Õü<4·ˆp2IÝb“I{Ù·¥ÙGL‡<‡¨)L™¼§6<{OÚ‰õJëù‡)=Ž`W Ti+Ô/ëy§Oul3`C¡Zª¬8Íçë)ƒz5f(mNnLe[C~‡HèÝ:«é3oî=vc"¾53b/Ba•Pâž‘Á©gtgºeغîõ`Έê;¶Õ$´T¨z‡Ró™Ú$F2æz__híÜže .#‡9Öžc蛫w¿YøIoÇÑÛ>;V;Íúå¥~$»Ï¨AÒIK(¢Û³@Õ0¦Ô£20¸Ê )$çÔ*í> Lª×5z(Ro,ÙõÝ#ÿ}àQàÉçÙÛy\1°Èöºc.FÚËcuÉÎÎý D­P”0Çj XS;ióé,¶hqPÞQ×I®y² Y%Ó&tÅú­;ôþþ ¹„ÙsQdÐ+-\yª×¹L&¯Ÿc݇)ùÈ69ëzTê|øÚÞo–ÖÕwÙY\9C +¹oú•ÿ™„WÀ ßóÇÓNV]UÅw¥Uf]F}å'Æ ~’Ò›Xœ#Ëçž¾cvB¯W/¤™iÐÂò:Èû°?¥Zï³ÚÜt!r¨±w(P¶¨^á ô Û}3e/¹N \J¡ñ¢ufý\˜‘ãLT(1 „™YÍdãºIé;o¤äú9oÒ>ÒçMªá8rCŒuÁÀ߉DL6¦ëÕŸ¦D¹í[v¿ 8½£ÉICxY'ž%¸)4ãl¤Ã!þ"2J)/E¼4²%º㉜Ɵ1gr P +×¢<Ð;’A m&%`»‹ý,]@QwÚÛ²R×jArÝ;Â9†¤q›~ c<Ÿ;–º¬#v·K÷ñI2`=Ìáä4 H™óÔ~÷ïAÀ–fZrëÆ)8UFžRÓT*¥¸¼ý  +b&c,±í™Ðò´6@ýMãÇlå‚¢Ý+§¤õþŠ´JX)Ò~Ú ®~_òŒ`|µ*ÊOw`à™]ÃtíÓ?³Ý…‰ÎZÖz¾xï¥ÝQøP&_DFáî?¸jÂÎóï¨Ùšø•À„¯çäHËlÅוäÀŸ/¢p«·ýj/ +¿¼I-*-]‚×X![0O²h¾µuí©±°njî¼Ùõˇix6·ÇüvàÁ~ó©O‘Àù‚˜lMT(Ûf™)Ea¡ +«f\‡Ð¦¡$ƒ±È=Ñ3{UvŽyo{VîÏë ù P`üñŒT¶Ve¤âZ­²<§EnÚâ)ÚQû´%¾ ¦¸7ïI¸tƒæ¹H)w)I¿¯r8Ú'‰uŠ‘VäaÊ^äZ¬Øy·ºÉ’ðô`ù³d^z¸)Æ6Â:F´lÙGNŒî;T“Aß<68açÛœ\Í„˜P&-‰*Tù–†‚û9n‰ƒMŠ.Ö _®¾˜ì»[tTç5u|e±ô(z¿‘1­ÄE¤m½9FGyü…Çݲýu %b«º&Ü“k®[“Jf—õvbè,úS0ëò£KvæOìÂT€l,Jc§wyÛezŠJ{ÍG¿+Ö¤²)¹¶Ú¯ã5ßõzÕ~^Ñ™,UËÜíj4¤fÒØÜÔ–Ÿ"^£Î|ÏvDÿpï2®ÀžDrng/ÿ¨F1}ël†±ùÝ/àíÀÈ/þ€%À!yjå—rG?v’ŠÁ÷ão¿1ÎÞVlJq§FÅã®|‰ú^òñ{¾°ì¤&>M†J|)§C'[¸@wÑ„¾»üë’N¨€‘ÇA,‰MÒ[PÊqu RÏëgì N™*>rˆÞÌþs“°Š¶ì×,¹v¸5½âz*¬Çsu€yÂ<·@t%'ºÎ)>þ÷k[1ÞyãçM–i‚Óµ»ùêÛ9ûÙhYéTŠDá]ô-$@auS¡s™ +wñÈ6úà ”mÕé²ÂþYTñ0¶ŠŠn˜ÄVûÄ*ª¾“z<ÓËåoœÈ-ÜÌ€9ð®Éü̸˭ojÊÁª&ÁU/ðޭ목;íNˆ"ç}%éÁ´ä}£‹>òΰLžž4^ùÂí°Ä`üÃ\½[s!ªÝÎLð.ó¦ŠÜlµ ò"±Úu +Ú匓$S¢’ 6CSûT ßé3çDIЩ49VTÑÞê_Eb:ÚÃæšúa,M[a¥1a=“Ûÿ³6]<·1Š\KŒŒjì…¹¯ònð /u Än锊ê&½7Sl x±*#Á ÆxpC‚yC[ >F=ÂT@Dæ©F ¨j`ŒT-Fbj ×t0ÿJ"Ã.c0@mY{PJ 5¤Ì'¶WŠô(æ +w:©ÿrŠ®­|¢©Â¸¦z$:S÷5ýe!Óné³úÇÈ‚®¥kîciqç`“&"Œ»ñ¯[’¿ +Þ^aæ’W~Þ¸‡ï¼¾L¥ [þ¼RB ¶¸¦ÓP?¸O/Kch™iÆìɶ69eý«Æñ0C¯zÚV»\€3ÓF6F’×PK(Â}<….õñG¢7uª–íöx?Q:¢/³«¡ÝUf7ù0ýÖgß´—-hyŽéT¤ÂpÕ äX´Ùð!Gf“$~°Úù‡A—ñÃ0¦é!Áy[—¬Ê™kØtó̸Ã[x-¬Vgûi æ_£,îiH0Ÿ9´>fDâ´¼µ¾éþ…¯P$ÞÏa$ùÁÌ È«×ÅØ¥p*7'ZtÐg;9N{9*Z—ê^‹Ã@jò£ +É]g¤ÌÒìÃ<¥)7‚Ñì¦aìnd0² ã‹ï»¡.{tm)«ÿÚ;ðÅû¥™¢ËÀOû&*‘8$nÎ ¢7ï A +/TÍ®vi6Ð9¸Í>4â|ßï½@G_C )$œôÀÁ¡S霿<+sK…¦–s5KÃóøêÄ寶Pþ}JýHgëeC÷ÁUf2‹ïU ¦(^9g­5Þ’‡®?¯¸ËÎïPrtAFžÕŸþzo…‡“Œ:¾æ$žýf¾ ÙéÝ›S”¦]¾‘õÉŒ·‡¶3­×žÂBR­Ì]þ +诮ñqÂmdàÔ`7nƒ¨RWºÓE[œ–™Ù6‘9¶?`ƒ=p®ç3Lã,oئDLß÷˜¯ÙTýŽ§Ý¯eW‘öîònQÆ—a)ähF%ö¤5ÙÍqXÒÜâDÍPá±S)ô|ÒÞôÔŽUYïÃÛ›ær¬f~0?rén#º«mH¼Ÿú„Âl#¦u¬…85ˆ#FìEeU§ ¼¹Ô_ k<ÿk¦°ÙbA%R7@"ÿÔ÷»Â2aë}ñó± Í„½![/©¬‡DpÙn/Éo ´=ý!"o×Ï¢ðœoâ}Nó’Ïúýk'´$ó ’;ŠTÅã8æWÌuTš+Èó1pT>×v€n +^õ,mÝ>µsªÇÍóQ™“™:…&ÚÞ0Å(ÛHj…`ÌðSòèí$¬=Ý3UÊõú”ûµ̒yæMŸ"¦*lÊKÓã)¯ý¼ð^lØb$vÖˆH 0癥l{< +ø_Ê'Œ.ÌGöª‹é–Q}é•.t(f2‰ûjéŲ¼[Õ +§m#dì^Àz#ÎHc3ŒÕA›Þ@4ýÆaù ÃM¸gGs´+l®ºhXÉ¿N5ÙbHË5toï<Ÿ¶¤UxÑ£(½¶§b^j +Ûó–ÊŠEVÛ*l‘(¯;Ä¢føqOóÊE½WÇçT(ÝkEfAó¼žýÂdù’†¸æ¦n®»Æ8ô¸©%ê XVŸP®Hè¥SûzëÈÑT5JÊ»khOiÅ©Sá[$#þÀ~yÖÓ àŠuq~»ty5ÈßZäë¸îE¡Í ƒ£ç<–õ?ž|¡ÿk7Iä¬óX‚Ö†¯¨Ãw¨JÀÆ!¶vŸ]@ŒÆ „˜ì¦{SL+SªÕT5ìÊnÂI’8˜$ØÛwk:P—zŸm”ñ¢7dTyïÍšVìL~åò0„­(ÕC‘¥H›â{*SniNƒ;о ¸î +rW²tˆjêÏéIœmyhžrñšxÓÍΔ{.2û˜Ö=2£&Gl þhÕuµÈ}«ƒË±GgYúô‚á1*ëlänȹ¹YEÒºOúʼÓ\/QÐ4Çê§ JLn%!ê‡-ÛêÑ–tzŒüâ!rÈ~¶Ç*¥ì”o‘‰šo6õÖÆe›DÈ7äð+÷&³áøÚsŽNvÊ0± +¼õ¥¦Ø[?°qI„Kõ⬟5~•)ž¢7StûŒ•_ÑባûŒÒOLû-ˆè•ÕóåÉú¹@¡dÉE’]_VJDù»ýõW……¿].²dt~ˆ˜ˆ ëM„í[z:ð1¼meãðÎW &If° ânË5èŒqJ ùHçq$?HÒàºN÷œ³ÄtÉÕ¶øhÎ=øi2Ó1\‡>ÆQºO€Iep3ó¡5_€lª§~—å6í×ðnþ4à ;h·M±VH½r4­ÊvV & ¯Ž¼ ml߇K€#×?xÇ”³îL3sÆ™¸Ö‹ô¥{Îcj+;ó÷ˆ™¢à#ÃZIü7£aÛG+ˆñøÝÔ›QEíÀ’¢#­ƒ™)­ìÕ¼`¤øÍíø´) ’J±4ŽL_$/Ö.,ÇÑYéácòwjÖlžvÉ[ÓáþhÉðþð‘æó|[×L.6y¾WLMèJÕ€¯ŒþØ;©>âÏ  ‘Y‰è4‚ïÓ+Å·®‚›m=Ø”°YXÓIp}å°ñ YÙ߉ŽqûN<Ëúæ=´ûÔg·>ÚܼŽq9ºT†¸ÃèGSyçm÷p0ðÞû[  ‡s‰³3 Éî%ø¥/ÝðúµnAi•wÖ,[é5SõˆcÜÕ°Öº×èÏÕÇFÍ,Œ;nòAï-´´€Ä߬ug¬À!ˆ <*’Ïã´ñ—Ü›£D•îÔO/ý-?*¹Ww×%sUc‚ö6a u¤´ƒ·¶ªVq«ù|4F;2¤¬«šßh1Î2éj˜ô÷8æºÚÀ¤¨Ä•½š:q‘— 8roBÎJìÞÉK<<æÓ?6tð4)=Oö¹nÝ úy33ç4ç«"s_ʯrXZœ´¿":¿y€Ø`eóúþèÇi™f*õÀdP[S Ú^D$24³ªSpÙçr«u +¯X£ð\½àá)™—Úùìû.¹ò‰¬vY·S‹È¸w´þÓÄœŸ£ãì/âìœb†Î#aÂ]ôG1ë-ñÒ8;iµ¡ø LÃ,c¥&]#¨£V¥¨wʈտ™f_ŒWi—²]Šã—â¬3—ÄGBßèòQB]Pö½!FUßs³Ó¨ú­™¼‘JÂÀFGí +†Þ[ÕñºòŽABjÙhaLMô\¸©·UÇ2lucJQ¹ô@!5@ç;*>ƒìïâ _\Hñà‹Ea{¢ê’7ÎV[ˆso'Ƈ.–¼{èãrœÇ<˜Ê¢©5û&/gý©~ò†…p´F7Û,‹™éÞ& ƒ–PvZœÆé<ÙX<Ç~ÚñDRx›±Î°mé¿,œÏxIÀBµüïgE/Hý£öÓçVB[1úüû¼×+,(ëÈj‘õ8¶DšÈ1éV%á*>ºÑÌÏ-ÉbW®V§…* ßcoÃÉ«Šx›B¶>GžÀ>­š-QFÜHÑÃâ•°8ð8—ÿTO¼VJ›Jfo!ŠËKÌ4,pB@<ɵŒhÛ*ô¬W¤ˆ¿™Ù³[¯6€œÚ§óªE:§…¼L¤åê•B¼¦aíe®7·víÀe™4U8Žm]èÝÜA±ÁYažr}‰Í#1ã™Ûµ*j”ÿ ÑŒáè+àu–L _#Ƶö»Ìñ˜S}­—qmm(›1öÑà kªuÊ}$ìL„_hH÷,½ÔtÚšw½álœADöâ‹Ctkôq¶ÁîV1)Òö" Ô»gFbØ_ p(xÿ—ÌÿOðÿ3ƒC]€0'Ìÿ_‚*-endstream +endobj +1025 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 35 +/LastChar 122 +/Widths 2099 0 R +/BaseFont /EETKYY+NimbusMonL-BoldObli +/FontDescriptor 1023 0 R +>> endobj +1023 0 obj << +/Ascent 624 +/CapHeight 552 +/Descent -126 +/FontName /EETKYY+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 1024 0 R +>> endobj +2099 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 +1016 0 obj << +/Length1 1630 +/Length2 10814 +/Length3 532 +/Length 11687 +/Filter /FlateDecode +>> +stream +xÚíteT\ë–-w‚-Ü ®ÁÝ]A (\ +ww‡à…;AÁÝ!¸÷à—Ç9·»oûúWwÿzãÕ»ÆþÖ\k.™kÔä*êÌ¢fö&@){;03 +?@ dkââ¬ho§À¬´pQ6±Þ.djjq' 1do'a ò´f  )€ÀÆÇLJL ·wðpYX‚tšjÚôŒŒLÿ´üå0ñøwä-Òda y{qÚØ;ØíÀoÿí@u ¶ÌA6@€¸²Š®¬’4€NZI ´:ÛT\ÞZ1(€LvÎ@z€¹½À怩½è¯ÖœYÞ¸DÆg )è- èn +tø b8lAÎÎoï3ÀÂÉØü6°=dgjãböWovsû¿ rp²ó°}ÃÞÈTìÁΦN 0à-«Š„Ô?ê[ƒÿÊí zƒöæožfö¦.µô7öFó†‚AvÎ0ÐüW. À äì`cìñ–ûÌÁ ôw.Î ;‹VÀpZ;™ÙßhÞ¸ÿšÎ?ûü§îl<þŽ¶ÿÛë?j6æ,Èlìo9MÁo¹-@vÈÿZY;s{ë?ìf.ÿŽ¹þÝ_;CÿV„±™½À hŽüQÉü–@÷ßS™åOäÿ‰ÿWþ_‘÷&î¿jôŸ>âÿé÷ü¯ÔR.66Jƶo ðKðvËØÝ36ÆN€¿îGàÿfl ²ñø/ÿÕQøbÿï_aY°ñÛPDí,Þ„afcgaý‡ä,rš©€À¦–sc›·™ým×´3:Ù€ì€oÚþ=Ö· VÖÁ4,A¦Öv‰Àõhgö¯å¿Éõwñ5%Tµdÿ«öoO•·Mkx8ÿ–F[ÑÞì?ñˆ‰Ù»¼˜¹ÙÌì<N/›Ï‘ño¶žÁN wÀgVVV6ÀÛÿ¿?ÿ<ü ¤©½Ù_›£6¶3{[¶ÿ0ü›º89½iü÷÷ÿÖô¿Ÿÿ^{ ÐhŠ¼4oo*l•–™®ÅÏ“øÜÓÅ3âPÒ QTà_mßé—¾ÁWaôTÂÒ8ÁÿÒê1wäð¼#Ç°;Ô…gCÛùxšOìCIß]ð~¦‡q7ðã—´ôcíh¯³Y…uX=nV­ÝÍ1Uµ/'x’‰6'ij[zJתt_ÓÔú8ÜvÌF(¬Ú£cš¤ƒÛÚ¾áÁþÎ ¸î"Æœ8$jWX4š(Ç"a=Í +¯Æíwu»d±Ý‰¹ÜÆXæ§R÷)Áxãi³åyª¶š—ܾí9ÞYò<0”jûˆ/²­pÛ2 D¯"k<û¶¨ó¼ˆ­pΛlxEv'Ê%Ëž…¹`|R_•·–ñÿd{÷ç9óÙ¢Ü߶e@°-Q–äÿˆO$¯ê2Á³|ÀnåäÉ4¸Ø¢¶œ£íG>ÐK´®‹²üE{ÝsÔGµ÷Î~ï—¶Gí'Ä”›’V¬Éà‡$¾}¿6?dÊ—|ñÔ'Hr;ùMŒ]IJd÷d“ÂUu?¥¾q¬Àe¢zœUú… ~Æ¡dë/O *‘¶²læ ³,D/L§­„Ÿ5)¹;+În3†Ô¼Á¼ô× ÃXؘA¢(¦! rµšT ®çjm¿‚ˆ"ê:=8„é‰ÓvÅÒýÒ´ÉoèwÌ»ã¿ÛŽû«h»‚¬Î.zµŒ4Í$‚Ÿ!‹8s»wè«© }ÌT8-TCšP×í±¿Ò‡š…ß¾*hÔ>_˜A‚»êEžä>A£%»Y÷¾¼Ó‡— +bEh;m&¶2q@¤}Ï7 ëX£ÇuénÉ=µLiØ®Z#‹ ÒÃxLçÜȾÓ>•ƒàÑYô…Í ¤qk#è3‡ãMà¸ò“üLvq|ìD\0D¿Åv „|uw•­ K³KòÉôﺸ씪ÊÌ=½Ðz ¢˜A‘'¨÷GêîéÃä}-.ÍÒ!˜ 1†Akµ§„öŒÜ̆(;¿+ñ‘7ÕÖÊ(C²I|ÒAÿG÷CŒuŒrQÑV…=3åŠè’>·uŠ?œ5Trh¯©ŽòÒ^¢HNåç4 ’/Sîˆë‘~_Ë.ÿôa÷rû»õPã ôdìo0gùš²þ›D"îbHèœé–š”¢‘:æ]jx6Ϥ0õ!5½‹%CDAçK*Ë3W'Á¤='€.I5p4¬›#CF¢NóÕ`Âv'F.ÛB|Ê]ÞOŠá€íú #&ãøÆ6“¦P~…‡mŒo7±™›1Ϩ)b´S«ü²h*^‹ÅÇâçü¸ð1~çŠæÆß_ÒEàj¦cþسի9ôžÆP±&*Y £ xkâÇ¡r_u¦Ó«8¦Ca1è³M/FìÝHHºq˜ÜÂb¿Ïá[l×êkû¬úËƦ¡¶¯F$¹äÆÇ´vyW +†üdË‘È)ÜÑ˹ʱ„ƒ¡¼(«BuV•ÚèHbNÒnAÂé¨X^‰$2a€ÕóEч(¤hÉãcTsë5V»´"ËŒV÷o¿=ÍÊ~€íçÙ7¡èûÉ;ÊÝ/ÁP®}€ ƒ·õMDK°+Ãä²4'ø«<£¥sâáÙ9,ìú)t aúBD.ÈÊ?ÃîƒÑ $ÜjIàsT¦9õ¸zNÓõ% (ªÎ»é}ìsZ^N Û÷FÎ9PJ‡¦4k[«ç f4e«’ùN·C Ì«üj}B¨ª–^xÄ€(4ì—ß«qe Ë:m“®Æ ö¤¼êͶW=§µjØÊo„’Œ 3²8yj‰ê`nûÁâ'YÚTKM”‹ùÂÔì %Ù³¹Â]¢þãEš ®ßHœÑ"P/V,N~οPóÙ3ãþ™Ç ­ù¡cÈeü¤S¯ƒ´ +ýÏTa%ª£3»Ùª]`ÁQ êó}³x:HX¿U;úŒ hHØõKጬ‰•Y)f.¤«â£Þ„ÇG8îàôº¯a»p7åsÚBc£µÎ¥7apx X&_­ð¬)wMÔY„«9y™ÁŸe!Ë×÷*$“ §E¿jéŒ)f?ÂwJ×ÓŽRIßU±($ {û‹xÜ©ÎMYÈÅäJõÅc?—Þ^Ì:yðý¡_nA7üÕ©Ô–?Ài¤kðÉPHRòÎzçiÞY­Ýû+Öäˆ2…tzW3¦Ž­à:]q¨¢–½¾:µ;›ôšÿL±î\ì{¯1üÛüë]¥ôî•ÀJªÏªœûÄøø¾z$A)ŽöNÏÊþû>ϾЇÑu—ßR±Â ö’ºÛua{Ø°¨ï•›)wËÜ%ÒUùœ×“ǘy‰–wè–š7ô¹ÇÑöˆøoµÃî:5Nö˜~ø§•ûß¾ËPéä—b@3¢€iÓ,m ¥däg àø¤'®/}"Lø¡-”ÉP&kB;…}ü§D7×±0œ^þ +ú)[¾ž¤.ª×VYzd,Ò#áx]RÁÜõ]òe&`”2Ÿé3WÀâ•ZŽ°X…Eµ®ÙßWÌ¿vAJ|,„$={Kýë§Ò/Ð0Ñ4ͨÙEiÜ.äîOîþŸmÏ)¶9ÜÂOq?¸ ííë[ï]ÄtŽþF™]ðL7 +—ÑÅW%HkÂE©(ˆö6i°¶&b°Þ¨ïnwÓ÷߀MÙð#îVbjXèÿÞ«[k‹ÄA³±8Õ 7j/I$Êý¥í¼ž;‘zJFžÀÊÓÔµFÑÌ®mÆ"F̶ƒ°‰¢2­`Ÿ¨3pCQŽf©:ÇvlÔÁþZ[zCºåçš8ÓîŠu¤ì5í¶rÅŸßÛ¾25ùŠ †ÒVÔgó°Õ_Γæ@ÒïÅ™…Á)DWÐ6+Þ­ë ‡ñß¼©MüâÆaªƒi>_ªóCËLD CP]ÐúÂL½\=ö›ŠLE Ñ:Ç¡õ>_ç¾”ÕÓDÀ`h{#oÜ1§ÌT«®X²é¦ nh¿,ÿá2ž’ ‰ˆFÙ`TMN>ÜïO?èdÚg>|Y×ð²,"ë•ÊWBJ° ‰ëÊw ª7¹·DþAG—/Øi¬\¤C§õœ.óbƒAÆ.Iµ +ËÁúŸõ#¤½ü?PÝuØ¡™BŽTÜksmuçÛÇ¢,3ÔZ’ÌQ|7û³Û;eOŒF<¸7ƒWÜRgò Ó· pVÖÿÐÄ÷èæjnr–+zóX܆;$¾Ô%€ë›<«×³!ãq/:˜µõϼ¾†<…ö  ÝðáÌ´w4`›x©¢†1ÖñÉê^ah¤K¸$J^¿ö†[ÖÓ¯õîs ¼ëÿz†¢Ä?÷å~.õŽÇá[„P¬€Ûð»-kë‹ý‰ÕL°§™ªï 4ÁÚ‡þ Ir¾ëýéÝ´g3ì=jï©l¾\þd×Gpá"V‘tÏÀ¶5Øq\ Ýv¿r›âÝß {?ƒ™1¿"‰IRœ<-²*Þ]²=¹E7œA©B±:Ž#¼²ôäÃSPÇ­^1¦?˜"PPŽuáùíWý˜òiÕÒ‰¸’§‰_D³-ZV4áÐ%TLo bæñÛR_—žãö“øì«úá”ýcuW Ÿ¡Ï9 GÓZ¨Œh2Ù×’Þµ¨,©û)õ悃Lµâ·õ $Wjþ%ÚZ¯Ôfß¾«¦W¹êdî-î ±íynæÂÄ(è1ö2|N¥ô]kÃÅ%200*«›ºR„1¬/ÊðN÷ìóùû‹¨HfÅ¥KÂe«]ú,fY…b!Ã)ã¾ íÜà…F˜´ïú¾rùª‘œ4å*Ù÷îÝ`ÿ6[ítïhwýÞ¿}ù´¨Å0VÅ‹IE™B;§5 ÁÁ"MLýÝI'òÛlo©?œ¸Q Mù%K²Ñú—¦ŸŠ½¤†Â…¬–ŽŠ6tÙÌ ª‰ÃjºyUqjRì™IP?þ3i^p…úÊ*÷a]mVºúÔ†‰lHÑ!_ €è&c[Ï“â)¬;²ü´®ÅêüôÕÒ¤’ÞúÞž¢ùI1c¥3N¨œ£´ ’©JçâçESNÝ“Qˆ8jn'Z, €"¬ õϧwßÊ[…—~Œ»÷‡zÖíO‘ +rÍå…Œ†ê# Rßò,"lêþ¨¨T"‚è:‰¹'\â­CrÞ×z,Õ¸ §A:æ‹Ïg<¬>Ú'dPîÐÿ¡1ŸibT,­L”¡ïéd¢º6[*1½[)R«¢x úJ6Ž°ÉÊlÅß ùЇº¾“¾%ß6%€ÌZ€ÿ@ ×/Û:œŒœPœLö'½<Òpk\yOO6ÒÐÆÈÔ©B"ÑitÚ>€Bµ8o)vçùêµFÕ¬$¾üESúÀŸüY=ÁÂýŠŽëWÝÏ¿6nhϽ±ý;]¢f%(ÞŸèA¸Ž‡yÛ$o/Aûv sÙzOÖÆ’±È^d¡›_Û"Õ3ôܱS+­¸Œâz»ö­‡?5Šž:¡ô´Ä)lI_%Š¨ ªÂý»6}ê™;Ç]CË‹/—øMÊ›md>&ö3¾OÝÑzÙ¢²ÛbÒ¿'•?OäºÈ"`ùÌθrÌJâ˜ô튓yðYtè»;íAýºû);†1åO¯º2¶€ér´¥Ró˜”LÓ Á©^šv¤öŸ‡G/„ß_ú±Ø«'.‰ªÔM“k—K26é÷ÿôWSºÛ§¯÷ŸšN×V¦KÃã|³DZ£…C3¿åB”‰…³[ÏY *J“›Ûä—añüïM–͇»‡[R»³Ÿ"ýŽ‚fç¹8¬™^} µö:›QòbSpìØcø±gÊX?KÀð~íó‡6ÞOX¸:âZôÍ  ++Ë,¶öyL,Z&1ÝÍz*ÐßeÑIå²ONçÓ‡õ™Í#ùÝ1Éq…•-eÀh‡ÛQ$ßn:pEä®Àì]05‰°=5˜®‡¶­2P‰5eÃí+–an„UÐŒºÎ’x Ù?ò­ëue¢¯ÓÒ )Ý7º:n:<\6¶c¬ÅÎjt(âHe¸¹Tس`8œâß?0­•ÇÌщZžôOöŠ¿^üŠõ·="æ>ÖÝJ+u@ãW•DÞ,똒7•|›ðÝ쨾ýµ€€@Ò¾g[^VÙMÅÎÁ/kÍô)$œ4Â}ekñ{3ç~ÖOøA)D*v"ŸX{Rwª*S +aÉÁ_¹5wCs̲ÕûÖþŸjÆàùØ÷–¯ž™‘ÌJþ¯swQ⢃³F‘1b˜üÒ|ë FžøßIµç+x-Jï)#ÌÙªëÃn¾(ýpð»*tYÜÇÎ}Å›Ço¸Æ³jÞÒ±ko{!dhÖ- \˜`[Kþ)pLžXlø ÈÖQø~‚¸×Çl7¬S¹þ›¥*¼”>§Â.öÝìþñÃdi‘;`‰‚j#–•µß¯XB`ZdHnh“¿èI¤Ž$Ì‚Õvz!Œ^ !+NypÛÈŸVͧÁ`f–fU®äi l'Nªw!]ÅúŸÑ|È'Žb&‘$US —ŸÞF`'CŠ‡r(¾Kª‰;Æf+eZ´X‹+öÿ说oÙËøX9—í¸*¬^™FRЙÿ£ÑFï…ÅAUÂ͸)¡Q#>£0Æ*Ú¹:R…€à”%áee¨±¸ì¤|üi3bNdoÊåo3Ç\³RŒ†ø9`S? — ®ó·´ƒQEûõï©3ë-1F]ÚKé"Np÷#Ò~ ‰JIa†ôTA}Zê˜ ÷V¸ ƒnq7; v›™QC'C÷"¸®_o†™»NIÆgŸìø‘Y¿_µi´ÿgD>Øæ° âe©!EG² 'f«µÙ_—ï~r›þÊÂIöÉéS·y_!ºn×®æHQ–r5¡XÓh€šé©)Ñjw(üÜ}ÌðÏ4|Dp_CSàë€ÚÏ!œñ)— -Á?§†Ï9?³7mhÓÑzô±Tk¤Mˆ»’jÕ´¤Ò«ÑÞ™aä­"5šÑ´ïGZ‰CFp)6õçV{d0¥álƒ%8ç= -R §Ïò‘”-ý©¿+ÛU4¢.^1Q0¼[ç>ÙÙg¼9!‹/JÂ@¸N´eiÁ—23Âoæ+Ãçu#•!O°éÔ ìâY@—!WùAŽ…ó¢fÂŒpV[¾Á)?E ‰/Tc¹Þ]¬É0×aH¥RÜóªq¼¯)XßúdᎪC…Ð鑼gˆˆzéže¯¶-…¼ÏΩ?iž¡}Q'ÓÁfü Þ÷ž¬c6_|5µMZ@·1úf ñ9êês ª]ÜÔæBZ +®0QU?Åt v¤T1_¼Yp¯ÏÑn1×’äê'ŒWÔZB¾y¶¦}Âw’ ë°È‹G¤Î +f‡dúë‘|3ÝÖ¬9»pï°h1ûó¸í•½ÈW©”qn‘9¤pÙ²Q@ýDîã6Ó>ëo\,«m÷º·óSP¼ÕÆé‹cŠ˜/»f€¾-Ïxˆ®;SëP´JáŒU'â#VúÝ](ëeQb}–¡˜hïá\¢°»­ŸÓ¢aKY3Ê´R°ÝĦŽTWòã?É ç4ÙÚ¼~pÕôÉs;.“=@K?ò°ÞŸmG¢«Óg‘n1»€˜ótÆ[;ËæW{¼«ó¼¶¤êqáãï876} ÎÆEòY‚i›XëzPD}ÕÓq>ÌÖ=¨[ÓeÚÚÛ-DuoãáTç+ÄGQ½Ma.Ù¹êÜ×,r„U16W Ý¡UPÎQâ sªÞûÛT—ž´Þ>UtB%®Q?™†o\?‡c ©ãàò DíDÞÌÁ<¨‘‘å±cW'}¿ü%)yõ(¶Lz,£›Ú÷=Á‹º“Ûˆƒ„ªk_mÖø'\ÿg:óÈm§j³.”ŽÑ}½³‘šÞJAàȶ¨â>ÓÇBt^¿æt8Lyäån¨ðª~ÛÓœ„×RD"Ÿ"nN4U¨·áìDz./)6dÏXã¼;Îi8D• ÊV7yüöX¨å! v”kÝÛÓ¬ÙÛ’Æ9G +#ª5¶ãƒýŠŒ[ônjŸÛ\vù$/ãRÖyÕ\-¨üKŽà|B8x“AíÁ.O_JŸqD×=®_ž~:? ³7—2⊦Ý|jèÚ~e“hŒ¬Ò`2Æ`PzwL˜,Á”‚Ó­à¸=] {¸â>uD-‡UÙð›Ãí÷Qri|& +Ô>ÏíFŒòóGL2Õ×i#yûyNÕÓSáÄ.ì(¢ ê—´®u߃]bùž¹Tè²ÕV YŸ(uAyFìT½ª7?‰ã[×4¯#ã:ªÞš|1¥·cÿÂÄ=SŸ¶Q,hÛñðh]©¤ßûàzÑ÷ùÝQywÚë\ç£V}—À&}nJÎ_#2ž½+¢û%Ì°Ë=NIW™H9ถÃM”†òó?¹>HÛÀh[ÃdýÀ#þñøV¸°ÏjT̆Š½Úß'9Q£•ðD +ƒ¥=Ûe!sdê)‚.l4lóþE¿‹'@ÑN“Œ +žKXø4¼]íywbZâü™rœ¤ÂQ-<µÏ¬À¯´)"‡£]·ˆçÚ\¹çyy/Àbý‚ .G¢×.èßY÷®! É>a'c6CU¢y{nÞ#‹MÝ¢UüišB|!# V­}'­5®Ð±äNÆ ]túPÑ:/­ò¦X˜f9Žó¦žWv·Ô•©:N"õ³g²N î‡íæV¾–HYÈ.J°M¼FWÁqAéoÑxJ!&Wðˆâ­Tþ“$(®m Xïe{Ì××Ð8]/^¾g«Äo‰M·9}SO‹ý‹³n£zbÏ<3³ºÍö½9dÏDy6ÔDPM:Žð˜S“ wh…µ„cK´Äã‹{:Qö¦Ò-‘þh[N½œ;M7 !ìX¶lç +ûÆnÅOøÙ/šåvýÑ;Á¿Š(æÀêzÑÊ–>ì9¬Ç”°n÷ùv®Û·Y^+ùå+ÔÅKl—‰æÀ+gbïç6Å”E”vÕ8÷¸Ü¯¸.ÔF,ÜcjÇqx"3¦Ò™L•*×5FžÅVÝMçï©Év%¿ã´Þ'£N·ò6iM¯È-ËÅ8ò̉Xµ3<³ƒE´p“®Rºçègk,¹,1MwðM»¥&©v#(&aWgXñïs’ÓCˆoRlãB& ¬Wb_ÎíîŽNGW 6Øgåëg5ˆ¦:”'réÑü_³Ž§ËoÈtö¤¶egSÌUlåÓuD%ÝÐ=Ü~¯à0Úò•K èñ”ê ƒ\¼Úˆ½ À'&Ñ>—Ä÷VåTËïuXg2YèfôŽ ¿™€!m†×<^¢¼™=¹†\„¤žºŸ3>hÙà …ìwÈc>Ûºa/AØÛŒk1M,ø}GΨ|ÐÕ¿ÕSÞ=t@†šÆZ‰œà¾‡_ö}ô€–d0£¹¯”xP× òóvSF¢Mv˜Hv¶y@¼ ½„uØ1åÐØ,*Á×ÍE +® v'ö½Îln;mÿFN• +/Ÿ3Áô1êˆõí‰~4HFz>5#Ε{}mBl+ï Èà+S>îϵ ³3™ýžYZÍ?º°ü|(ø«8EÛN¼-Zr^’3©ÒÓ8 3ÅX£n Õ¤îc„Ô#gAGŒT3$kÿu‰mßêÃ0¦ô%BV¾®”ÍXKƒ²ÿ )¦|¶¼,–…WTгOð Dt&’vm‚¿[ñ²âñ‰hÿOr£æ§E·úÔ‘”˜l LkO$&¿Tƒc¶“Ùå€ýfSœªÝËX¿aП‘$ŽÒ(HÆ[®²—|þ§¸™¬b 5Q*ëkbC™%x=ÒqYŠ€¢y•#HÏGNJq¥RÚ‡o•C¡ +«÷îõç‡k¥¨9îx]R Éé !lŸàk<“™HÏÕ2Ú3'Ð_}Á±nwYíÖP¤z™$z¸ˆå¬uBZö˜ò,ïД‰ˆ6”E׋8'<óٔ᭦ó'îôÇÇ)§Óˆ%£‰[LgPÌùÃ[VëÁçµü÷=iˆçv¸#¨<¼‚¿ÏûN¶Ë9·©\qwqVb§E9¤»çóÆØ';†0€z!1q*L»_E³%)dª8„qb" Béãkë}™`_ölz?d(d𠺢¼ùŠú·nöM|Îëv N–È1@´é}Þ…gðvÉ–ßoµµRj¸Mk5"YŸ~bÐW¯ÔÛǦ¤}wQ1øA³x/ÆP/3Þ‘,¼#[¹3'Ì™^4ªýJw“çM›vŠ%Y37ÚZ-í!ÚZ„¯Nêý÷ÆA@U/#ÀJG4½øˆ®Lš„(Ûq¤—ZDÉŒf%)1[1$EβU?ç]ùÅÏ÷àº|/»çº86е"¿(8°™NWÎÿJÙf[ÙÉ(áåÊ=L 1û•œãBJ9 q•Cqƒì.¤Cj]ÃðÎ/b J:Hüäë0=—›g»W†0¡N¸ 4Òa,‰FˆÐtoÕ¬’«]G=ç#þ*½QÇÅ[àr4XÅ,[‹LŒÑÆÀ%D줫v‚SËBYtD\éLrg¡ÒsX?ìbW,%´ŸOZM3 Ý$Ë ÓÑïÜ„u“={Êãe†pæëaú<ž¬,®O1·—ŸbÍIÞÐÅPE¿p’·^¼à|ˆüÔµC?Ìçm£ù kòúšQ ½ U*<\£›Œj¶sP‘>N¯Ý(Ó ñjùz£¼uRX,Ã"É"˜z2Â[°À´3Žœ}ØÏ"/³Ö@~Ž!¶Q'–Mªý.¤äøx®9Í“xNKÚ¸ìì +ÏÆ^é(t{äg^Ì)¾^Äyoߊ“8E˜‰YjÚ é]ÁØ¥ÙDf’ø iÌÌR¥®Û·‘•¿#ëÊቛ¯½ð“_“9>~"iú +M)Ã9Âp:Ä'°ÂyFJv5„yfù¾ZF|šÿ˜Œû;àcêØBüß›©î¬ÃŽNÌtèÔd/O7ðŠëË–“Õ7ÑyD¿‹31ÓóÏ÷ÈJ¶b@=­Ö“4Õ +G‘áR웸5™UP®ÇÇ°H„×5Åã>½,TGè±8ñª4ô~È®š††,h»®ß z¿š l–,hËÐ%ˆÁC}ìÜbÒŽy’Ÿ&þÕöZïtï|çil¸#é¹–8!}BÌ’ñé{‘ˤFX.K·¿ìܦ|ºgÀM¤ûÆ¢•Ü=ÿ=²X_S`ìÿ<ì)ú¸Ô#»oøý–‹¿ˆ‰´ƒAF;ûû +Ûwôd¡Üw÷xgXøÉ\›ôi3“ŒIDί¹N%àŒ±éï\á>Ø°tmÖ$¼ãÅ,ñá…uÛæþCU˜Å6é*xsÈé4矾½–çëOf%,RKÁÖñ¦¤EÎL_2¾›Š‰iŸ¯œ±zÇÍÃÁs}~± à)Ë~ת0üÈ»€ñ¹R.Ä•!/`9ºz\h­õx–jÖ‘þ:9OñÉÉjð‰¬”ÔÌ°–˜Þè.h1ýdftX*ÿ7=™q FB1w)ÝúiC$ü9œsðàÒŽžQÔÄÚÂdÝ@BN~CªÝ©.ÉÊ¢^r’¹º¨JªÂ˜ †C4|¡" ‰j&m¤cYõ"¡ +#‡O/$v$R®cià¤Çâ÷Û¹6AçU‘©®¼n„ ¥Ä£Ïš‘mÛ«ðáäwãëuÃ&µ!¿®êÐ0š{©Ld"Ö½þ¤´4¡æmTu{5v÷­õýT_ekp¤¹¾r§Ð~ Q4ËÍRK2'¿ÊÀRŽõ‹l9Ù‚<£G{{©ÅVØeÞ=þ½ãøkæÈr by&?Ý!`@Ê‘Ъu iBškÿSéɾûmE@Ï4Y×^Y´ ~MÅǨp¸ägÃýö¥fÜtUAJgi/MüañD…+×»v­ø‚|ø¨.‡£0å÷]°k{r|xœ4Cäcüá5üº)µb2sàŠyÄjÌð%Ç)œ¯¹©ß81-?­ ‘#™ÄJ›áå#“DtC=ýHn¥?n^p ǧaÎ’òÆClÍOäË°¡·¯?xæÇñô, $Í 0ôfD ~xa*îD«­†S˜Å8×ü¼Ž/ÐÞQ]‘E „7d+À©'8Ôô«÷Õ™X²ü¾†IÓ:Ùÿ=Õ-¼°îŠ1tgþFHHÙ´.ʦ¤œGºßFúÄÇÜ=f¯h®N½]Ï©6»‘Cò°xVÍgŽÓ´¯*ʯÃÛ2†Ÿln»`Oêçl~’»×&PÑàoÇAóa|TtžòP—7ÿÂÖ›xS4ð‘Ìâ»[kSø˜¬O¡Ås§EÏSa$(’§œ¹¼m1¾>¨AAç¥ü‹#’ëµñاw“t“Í•…EYOU)-&5[ÍÕ” ÐYÙ>uï¯tH¸KJrãGÛà´ç«š4¥`Ê,c%ò¤üš½›õêó­‰îÖ­æda WÓæ'öj¹·„x!o“E¬{Ÿ×I„¨€>×ô¯R.ÁŸ_fnÇŽÜgJúvájï JPnÑ‚ûÇO⮊²]À¼^Aî^‡H_¾ö•ÑJr(•³¡ I[ Pȇy°ôQëG»ÉöQ  Ø}ê˜;AÊýì:ìº#=É“(þÊ|>ä®ö’ÚJ³òW³§‹„²ý:wR­äL +5«€ßbÑdûClC‚eÑ3›i“É_É>`"cGKó‚+îœÂ”SË%ëŽX½úð±Å­¾ç2]p ×9¢øõÛu“°WÙ8å{‘+cc"]•Á½[ˆ‹uÔ§Š®åëÜe\¾"Õ?M!©Ø‘5Yñ>>ƒg™. faSçõ"VY %¨öôÒPâÀ}ç_~[Š3šXh¬Xâ&4ã‡4ó ZòU‚õ(c˜äœMÈ>õ”D{Ê=ëÚ +B4½0üÂåZ8CÆzh¹Äõ ë­ÍÙ”™\ÛÑíÎ¥+ò—áE¢ì¹:BZ +ï!ÖdÙÌ>‡·‰—´ß•D¿l,¸Y‡þl½P ºñé:®DÁUÃñî+k#/™P¼|±ÔTa=Õ*¥­T^훳ø®Q¶t°HKZ®Åœ~`LgÊ`ømq%['=§!Y§ù“%–±y»¾nrI Kvß3g&r–÷é¹ÄÈ<j<~o™4iu¶ßL‚Ó´äÛðrœ..½¥×hÀ³È*ÂKÐh©Oañø.[ždZÏáƒçÆ"òŒ\#`"*äªFí¾a„tßÓÅ*YõaJFÏ*‹÷öýä(ŸÇ%hmdfRñ›„Æn[C ñŒSÄoÖÿáùÿü?A`j4vÛÛ;Y#ÿch»Žendstream +endobj +1017 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 34 +/LastChar 122 +/Widths 2100 0 R +/BaseFont /TMDQVH+NimbusMonL-ReguObli +/FontDescriptor 1015 0 R +>> endobj +1015 0 obj << +/Ascent 625 +/CapHeight 557 +/Descent -147 +/FontName /TMDQVH+NimbusMonL-ReguObli +/ItalicAngle -12 +/StemV 43 +/XHeight 426 +/FontBBox [-61 -237 774 811] +/Flags 4 +/CharSet (/quotedbl/numbersign/parenleft/parenright/plus/hyphen/period/four/six/colon/B/C/D/F/I/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 1016 0 R +>> endobj +2100 0 obj +[600 600 0 0 0 0 600 600 0 600 0 600 600 0 0 0 0 0 600 0 600 0 0 0 600 0 0 0 0 0 0 0 600 600 600 0 600 0 0 600 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 +939 0 obj << +/Length1 1606 +/Length2 17112 +/Length3 532 +/Length 18022 +/Filter /FlateDecode +>> +stream +xÚ¬µct¦ÝÖ%ÛvîضY1+¶mÛ¶Y±mÛIŶm[õÕsNw¿=Î׿ºß×מ síµÉˆ”è„Œí MÄìlé˜è¹r6†.N²v¶2tÂvÖÆ€¿J622Gg ;[Qgn€š‰1@ÔÄÀÌ `âââ‚!ˆØÙ{8Z˜™;(U~ªQÑÐÐþ—怡Çÿ´ü=édaf ÿûãjbmgocbëüâÿú ’‰ ÀÙÜ`jam‘WДPŠË©ÄMlM ¬ +.†ÖF #['*€©#ÀúßÀÈÎÖØâŸÒœèÿb 9 Nö&F™¸™Øÿc¢Ø›8ÚX89ýýX8Ì lÿöÀÙ`akdíbüOõ¦vÿJÈÞÑÍ_Û_0;'g'#G {gÀߨ +¢bÿÎÓÙÜÀùŸØNÍ;Ó¿žÆvF.ÿ”ô/Û_˜¿Vg ['€³‰»ó?± MÆNöÖcÿ³w´øW.N¶fÿ•-ÀÑÄÌÀÑØÚÄÉé/Ì_ìºó_uþ·ê ìí­=þuÚî_^ÿ+ g'kSz&æ¿1œÿÆ6³°…aøgP$mMíLŒÿÖ»ØÿO›«‰ã¿DùÏÌPýMÂÀØÎÖÚ`lb +à gçü7$€òÿŽeúÿ>’ÿ(þo!ø¿…Þÿ7rÿ“£ÿíÿ¿Þçÿ„s±¶–3°ù;ÿ^0€¿Æ øgÇüÿ| l,¬=þÞÿé¨fòï ÿO ’ÎÛ dkö— +FzÆ+-œÄ,ÜMŒ,œÌ¦Ö{ô/½Š­±‰£µ…­É_.ÿÕF#ãØ”Í-Œ¬lÿi:Û¿M&¶Æÿ™ù_zþ•7ƒªšœœˆ<ÍnÓy)üeÝYÙÃþobÿ£Y;ãÿ%üƒ!,lçð¢ceÐ1spØ9™œL>ÿ‡hÿ‚aú/YÖÀÙÑ õ·dF¦þ?¾ÿ’tþ懭‘ñ?S¢äl`küw°þ—ⳑ‹£ã_>ÿu×ÿü?帉‰»‰ÌÚ²O°eú¯ ç:ÌÜ‘IQ­>&БûÒFå¢ÿ»^¿ôð]®JýÏÚú¦iîïv¥sû¯C)꣱> kŠÞT“ë|<ªþä-òNš£@ÝRøŒ µh¯›E™0MvFÕ£½IÅŸº%ŸøÓ,ŽP7/Tþ$®þh¤Ïö¾Fi qè]HM@(u…çäI§/ÏC¿GG†{ïÀûqirâ Éx\ÁàÉ£ürp4U*½"¨—Ž3Ç'­1/ÍzG$91Ø7™Ây¶*GÜ|®1ïOåñ•`GíGˆ\.­=û“æúüq†;÷šLÉ»‰î«;¿ÐÄ“n\¤ÎõðÖYNùÜóÒ1àL—ëFb$]#b²ûób€aOžcxwK÷ ‘„%&B™‚ºo"ä¾²’UÏìU(­Ñdù?ç ‘îj\I‘näQÒ÷í9~5\ýYsÈ 4Õ;¯>ꪅª®c`r *§Ž¾í1I>T +Ð÷ª-KCºæì¢]•ß@e›‡á±Í R©e7ãÝ8æ¥X¼Ý ú^¯bª¿fiWã¦Ç6hé("ôæ?ü…$ØVS̓÷â¹-Àõæ}DJš2½œœ$~T’D™ˆ‡…:Nq®ó#5ßì" 󧈼ˆÎQჶL–­Èµðc“Êç؉/WöýîŸX2ŸÈÈðxª©-“[¿F7žsWÆ{4B +pÇ€úâLV›‰¨ÛE°¼õ`K«Vá½Öž\ºÍªk:K?>1ÁÆy9ãd™5 @P2ƒ÷Í°]öþ6Í(9Ð`®¦ ~ Ì¢ß +¹9y´Æ¢]’ˆåþJ¿*ú¨ gÒöK“]?e’CÌ(m +D\ïN¤Ô´|˜Ǧ¡‹Uf¥—øŒÉïÀúÒáè +ûÙ £)¨Ž&‹"º–Qª86Æ…‡â9xV6jƒxlˆÊù†º’2–^ù +|Ò Ä;c g¯lt_´û•jP°– ¼ãT³mê=-ŽÙ + ËÖ /¨é?&§ Ã­¤oø +%Ñ]µÃ³V‹Éµ‡†#hižrX£2¾K±²Å?²©Ç‹t3V<«×üHl'}µ“œ7ÂnhJ권buKÉ)O^Œ Z5‰OßöÚÖ?ý<ÿs88z™l­; %ÔVæ ËŒõ”ððßEôÌH«íjÚ ~öÖ´Öb}ë­MùñÍê+GÝq’Yµ£[N¢+C1¸Ë¯öýµgî;ƒBµÖcæ4vP“"d×sžåxñ^ÚÁ9O^jŒŸ»e: £$‰µåf~)Z–Tz=a“2¨ÕæSÐÞ»V›áçp"êcýK¹Wåã»/Íx=‹ +RÚ8Ýw>SÓ¯S®A˜Ç©ó-×;%¾À˜úeiH—faP$÷Då€ãCã&¢A†C ѾB&eQ/MN¯µÊQg¿NÊèÑ8o©­?²ËˆR(iæŽO¿Œz‹~€èßöØ°ŸŸÊ€ù#!Î4uðÏU¤ KqŸV!rÉœt„Èä´n"/«åâPH<8±Ìà%!*áÂÇbhO‰†o‹›Cd¨· †Q>ÎN{©’ÑòíÀkÕÍ=ý.8}"Æî™Ux§ñ~Ê©jG¤SY¹Ÿc[kÑ‘pœr)h‹xŽ7ó—Š›Æ]BöTx¿0¬ÝcàÏ}0p²¢A17y,óUø‚‚¢·…ø¿K,ZS¥VÇìóK—Àd=ˆúÓ‡j €Ÿ;¢’Ÿ×¡ôã+J‘RPl3ï˜ùÆïy4¬Ôx_½´oõƒŠHÅÔ·vS_ü AåÒg˜Î_Ý„õ’~w?@’4ýQîï(á"[Eq¬ã si5׳¬ÄÈ—D|ÌŸ|çå¸K¬m@e½)ÿø’– +ß$TAÂrü—ÇDUËx,¬mCFË„vh”V¬èæÝod%·Ýͼc‹ò¡R´©kð97Aa¸ö<ër Ñ¿5{ßîRÖÀª—Öì6 °¿ÒÅŽð.Îe“ž¿|€³ÉŒÎ¤Àa;ó›c ø1憀^Ñå݈2ð#"ÎúÎøYkK?¤ãž4rIt\IIÛaë°†;ÒD™øÃW=ü÷œ÷YÅ+˜©rM‘!ˆÑ'ëâ§λ‡Þl è‡ÕŽ¿MZaÆ©wO/ˆ¤ÿä‘¿<y±Ç-û"å{a«Øçé¹WÑs<¨ðÀ%ìÝH(*ævØÃíý¢_õ¦fŽÏZ5X¥¥6­›Þj<ßó±/¹ç*£ÅJÏ“o“¾™ˆÒ¼¬¡µ6"£Í·@¼çÂKtÛF3c‰¬#«;¾HõOR¹éGA½qW/}gTHLŠ‡Ö-'¾ŸÔkí2„}ÆÅ6ðû {î56Ë!l<À-€èÇUq;=t}ÃY)¬8Ýø3yìáœ9oÙìF€s#MSþ‘»Ží®@§$Ùýû(§îºÑ¶±ý¯ë È>loD‚K{à[ì1_s©–¤ ÑLâ”Z|µÙÿ‡L§/:OMz}ÈÔïKHï~-ð_Åt¦¶Ÿ ë­‹­åÁüW“Ý$ýAƘ¹ß3¯œl×âr,ëâ€y¥&0•²jmÚqý[„ìÑL6Qb~´+¹PÄ-sÙø¿µ$ÈÑ*ªï ¥ ðÈOÓ…¦JûèY[éýSækŒ¹©[üm}ÿ˜Ð6L÷èO³[²ò½¼ƒëÆÐNOp:„ùHïä7CĬ“ü]½yî´¶ïïÃ>Õ“·aý'×M½®qê äîbà_w– ž]4ðÚÀˆ²öÒøÞó¬n +: § Ìô 8û›cÑJR[2£mXÅw‹}y7ˆ×ÅLeD$ç,?Yh{³ÛÆBÅΙki¿ŽøК¿ Ø1ò°ºŸ;eó‚T›n|˜)94µ9uæÐ¥x´ ƒã½R +>ç³]æoM%„£¬ÎG)³‘4°ký‡ïbZ~ø ¼`_[hã»8ë<¾4²}$.îÁ³ÖÄ‚(¥ªæu†&ÿaÜÀ™y£Û2¤³‹Ô»¹T+ªJÀҙçÍÁØØJJ,šëò¾v\TP‚Êü´iÚõ pÃsùâäFáã!ÌnT)^”"²À±R'ºƒÀ q)J‡4`¿s]¼ÉZGâï”œÒ Òœƒ(BÖqˆú(““v&ø­3UÏ‚Bþñè› ™Œb‹Zˆüù Ir2Ÿվ ¾îÄ›7ïX)c¼5&•‚OϺ÷•—2nµÏÄGýÓ¯?74¥Ü׳ Ž²Å­Tj(–Eãs‹ &‰Rð³ÐѵL‘ˆÁ3²pæuy6©Ì7k‰¨‘}¤TêÄoÊ"´wÂñls ò­Eâë2¦'jQ®,ßéàHˆ]í„äÛct? ÁÕÑÊ,Ga³ýý¥­Ý2^¤d0•NUx¤$"e`à%~7*ýþ¬Ø挭©Ÿˆ{cÃl³?hZFCH7U£*´Ü‹Ç‚Ìy|±°8ô.šÎXAÐufóË ".Ä-_Z “MÄâë뙤—¡¹Â‡Ý÷í[áÉ\DZQR÷¡ x“à¼K)Ý)‚pÊåDÃ’«¼m“­HÁ• <¨üˆ´Ÿ_Ä1ÉðkH/·)(_|ýû2ª,B³i‡Ðñ4V®ÌCøY¹5õB2Ey»…yö47£h¬Bù\=m‡r94ÚOäjùãwiºð_w ÎvMíð¬òüò[°4ê©—Tÿ³š™\Ó¯r»N1†c-8!âΤұtzžK,בZÅ5…ÍCÅg€„ »öˆÍÐJÎÑ=–|üËÊ,u‘,Yƒغù‹ÑîÇôBÞ¬ƒé\¦SM„ L¿ÐÛºp`i5U])ÖìUæt™PÚŸhlA¨6`¦ãqµ"~g2è2êþ6d`{#Cn³W!Ïw¦I¼Lwdk J)ýK‡"™¬ô&¶ºV0ÀfÓ¡?þr83)J‚$È4?$ àE•´Åì²›¯:Ÿ +Œ(iýŽà-º 7~õSLcüýkÅ!.0Yü:7— `hPêoˆÜä¦ójÂlƒG¥v‚j»8Ç«Á¨›ÕäÅÆ6nÂN'éú3ÑX®ÐH¨Ïü%›zl½ ýƒ©´T~Ú}ÂwlzŒ(D:ooV¯Ãúe@Xrݪ#ç‡ d4C:«G‚nxŠôÒ¤Xç©þƒê¢dÑ^øÎg’´k½›Ú}Áîí{åÅÄõW·F°;ª¬ë§Â×òh`7d H—”µNº’7G«5–-™¥Ïà 1‹†d ®\É(¸¬®&Á€%þg› R¤q[â’ÖÀ.Ê¡\ÔýÔG&ùƒÔä1Gô!ríØŽHÀÊÏôØD¾!eeÈ2¯ª ­òûôÅ![é@8Í1J©áRJËÁE·¤]wú³{D1Â_¤ Ó¿’²\ýz¯ö §D‚ßìñ¯Ìd$!ÉÝ–#/û$ÅVrþlAŒÕ„ž­·:@¬RÏhV‡ƒTW÷ði¼&ßVQžb‘¦°$Í?^ªøŠJj ¹vQÕ±:³´FRƒK«}ÏGL©ôÐ÷±ûûAÜ8€)dä±”Z®N¨æîuQÕw_ ºLã®páý±•¯ŽÄ—¢9Qök¼`EËih[úª•³Á5?M”õÝãõû ØÃ)’'¸Q·*ó4yΊìðüC[I&«Ýrx”/Ø`x0…oÝûsËÙsïsìêƒø—弫Œ诗´% \˜Ò„-qBÏÐá¹ †^ n u^CE ’¡ù‰ÝĶAµXþ¤@á¼ömÿÒ’JÀf)Ë‹MÞÈRÁëVSi•#w6VBÐù£®QŒßk¨£1#ð9‚ïq?ô¥VAØAÿו° ¶ì.Ü5.óQøw¿­'zÁ7°…#|ÝX#c½r"ëòUt™îÖÔRìáϳ—åd—ã0Â{)ÒuŒÉô˜t’’•û6°Aêõvƒz»§ö»`~LÑ%óÌ·«š™,"QW½^CDDûa.˜ª¨ƒµ ÜöBŒvUÛaÀvæƒ~ç÷%ƒ#™D@¬Êž±H •e—„7tà›¹¬6–O_pãÊÑŸÀ)ÏÐ÷#lžtñôË.jLt•¤ÍÊv)nè>¡á˜T‚nü%´öª•K]^sõ'lÙ²k2]¿÷þ5#Ä®j@o^'Å|³ÂÎp?èÅyIß»7ç ¶ÞJ\pA·F¾#Û÷jYó\a@D‚Y>›‘Sa? +)‡¿ ÕÖÏéÛNÄD]*¾ÔŸæ›õ· ­‡.kÙõ£a ü:ræ\e·ûá&ÈÉDŽ¿Œ™%_$$3}9šü• Š8$½¬€È¢þàÎg×™„¿ZuÎÚ8רË=~³a#›L]gŽyiðÎ+.ÐÇå‹6{™jšSksÀ›ø¥qéD¾ ~Èͯõ{Ó·Æm'¤v;?«A%qÐ7ú"úpM°!(ïx[„Ô]Ä,…u‹0~‘—Ý›°ùot…ÿ‘vm¸oŸÓÔ/˜àyÝSÝñ}Ó"‡ÍÿImñ@üñ¥Çýawú™¿9Zôèý öI„÷,`¯ImJ /¿!UÕ†[ƒÒni$%µÖwjÂíÏ÷•y†’Úª? ü¸Ôî¿¥8«?—ÇÍá4êµq5‡g7¶}E¹l“lRŒg{ ©Ò2±°Ÿ. nÇL^ªJéˆYç¹¾‡(Š©?fÔ2ciÛŒ<¦É¥¼""—@ƒ Èí•Ú!kŽ 5+V=ÑÅQA+žß͸ÒË;vƒô% ÎFº+s*)¼Xs9NÛß™üÑ¥˜L¦ºÿ[YÛyt¼ÿ²ô„ xÚ:tés®` [Öx³(³û¥šrvrÓ vÝW+—ºù.myÙï=Ÿ†Ì†Q54ÕxÑîÊa•Ÿ‚T`ò—`È „^3¥>5¥UºaÝH‚c™'x‚.löÓ°g™~»uFˆÄÈ8ˆò€ b ÿ.¸%Û »ðPâ*¡L;.w_÷<Ê/¸‚óŸ‡o£ ov£~8ù8‘ïV¶qãf +åÚ`qÈoa’:Üà}ÒË’àóI¡ Å¡H±`í ¾‹¢R¯u²Í3}›’«˜Œ(-ž ŒßDÇîwëôêé‚t­»Ìt«Ã¯W¹4#UâRwXPƯY“4ìg·FRß vßû<ÔxP>†uÂËe&+W-\O+NcÓÈ«¦ˆdÉÊç°Ÿuµ‚^¸Îö%oH¦£¾]ü¨G,ïjçís”'Ù#~3’âø‘JÝ’J¯E«N²A»‘_l ØÙ1U¶c3  ˆ¾G»m+–¦VÙû©|¬-íÛ`»õ¿lf³$Ú«ôŒóÌžÕÅ›±Ëšûvy7ÅtU¯Z¥lÂÙñÏ,¿ Nªä@Ëäþ‡¼%NRs¦P†[¼‰P?ß”ÛI¤eo Õ wö¹¥@´!è&/Ä8Ù×öÐŒëÝñ‡þî…l<œ%š.Ò™{A•£@lŸA µÆ? wR,»SQ,H›ÀuQÚå¯>¡UAﻵÔ/£²­™Ï&/Ö…JVíù9@(üˆõ›œÏt\ F;éœt­Ha|þ­ZÇ)Ýb®4¶H„¸îbtÜ©. +Dì2Çüߢ¿¢‚IÔnèEYÒÒÇe)ü²:V ùUš>иɚúq:…mɲ¶þUñNžY±B§Ýêƒ&³Ã¼]Rý*ÃŽûý=*n…ѽKv„hf0ó;!ØÅ .&f«RÚ„ Ï‹ë&e¤ãe}|“x$Ó½ââ;£kgž=çyÅg©Þ+a…¶’û.Î)†Ú`NËiߜʼnW«Uäç*i¼/W 6æø>±§“ t6ó –p2/ÉõÚzî„øÑ=h>±` +n5TÁšëÑ”’ÐX"GEÉ.4–ú&µ¼ ØØ…'Àú|€PÜLêar ¾0N1fo÷í¼Á¶Uå" ‹*0âù$]s¨>ÓΆ”'â¾ÞÑØèÝf6qì©)¡}mZ€šÍûIÄN§ +Îþ@PD # V{¿Ö%þVõ|3ùÈ”JE3)&Níð{_’ Ê m3™Î1 oåñ S“•/bì~O«¸8/*™Œ²éëíZφä(.Pÿ§žÏdÔö¤¾X<é§îrî9YJÛ)E抰z6Ø/v0 ¡ ªD °¾T㹋˜€7ýP“Ú¡ûµ¿^¶û°iDØF…ṳ̈9Ô\ðØDˆ“Ï%Ë;¥Ø—qëŒà2ß œNý.¶8bWÉI0Uy®ƒÎÈfPw³‘ Õ8ŒÌ" Çsäs +ZmØFÐÃʶÞïPhzI÷™ð€*qaBrÒ·Ø^ðƒMâÝàí-Õ¨ô¡À˜å®™ÂÞžÑÉö>u¼ ‰ŠÏãonŒ{óæâ<ŠéU¿˜f);›Íp±OË,¾†ª™ŸÔL~‡(ÂJšWQû¨ +`þ* ÎŒÔÀh0±ì$(]J+?!uR[LGÓOÁ +>DGÓyØ}—(l ø &‰åSß}fÄ †ù©»7«ôÖÞ •ŸÑ;!)îüP_©cEìì_Ï“Á’TYj¥àê§ïS({ çÑd +± éÇ¥µ¨ÿ‹0Ò±«ö¡`¢/³I Ph¦€ZhtDįcÅxBkô¹õ¾z힢Uˆ1áû-C^­î@\’ž¶Ê#f„†µ]òOÍÕ5 Ñôh‚˜CGÚc(hƼ<@žðŒe/ºˆ¾]úyèŸãgT —–B„W‹:ƒÅ‹"p+EŒŒûE|ë7p<*6~¾R—”{N f.]Æ&‡•è…MÀNsr'=d/UMzW¿¨8ûÎ=ªŽ´n¸ÚvDôÓM=×ArY8sœ‹ªf(ú²"’å®êvj×;¥ôŠË7/“æÖö¹]Ë\Ù”7Ùë•azgòá¶gÌ)RàÞ%H}!³¡i°Re<Ñ 7¡%ý¿¹a¢d:£gteµIˆ­¨*’ +‡–oü‘éO' °xd"뙂T¯·3z ^‡ø~LËÿ¡IÖBcP/giй.^ÿâ×úÔ¡/jƒX©ÛQÕ ­€ÒÆ-Ô¦4Ê{Ù·hïgZ¼'ªF§ó.²$2ÈÙB Æúž07êÅÌJFØ “|Àmv®å·Ìù´"Ëæn0jª8xB¯QÎïïˆþ”âÞþÐßÙ«À|˜­jiu›¡lQæ5ý%ßzÅŒãÎv¥ú…>GïÀ•Nv.óY‹=Šð ðô"¦k ¿E)û›™,$i{;vÓSë œ†œSW¿BPPúËj…+ýá{ÛÏáûg¬ššLœ/ +¹,6:üâƒ^ÔX'€å9U¿œ‹fkM6¼¿tî˜è^‚(Ò2g¡I›yÕ²˜RôÓ(.ãcÃÿBM¶SaÓv¨‚/uø¹!&jìdR¥ *ÿ!´BSJ‡ã !DË¢FT=B–žýÏm+›ä’…0Ñ¢­½ãmëIÆ}ÈATZS¾Ø ûú=óÀrèƒ!÷v§} ‚ü |8âìñ,¼ + ’¦ž~o8LÃć4»DÜ϶ÒlÊô‰'´:Y'ϵ:X–¹ȃKKÖr97…ü dé2 +{¡„Fuœ·3žÍÇoÕ‹Ü2C7§jy¸-Í@Šæ,dL//¢„KàôÌ°FYîÊ„³Ýþ9Å™êVþ©\ªGôZמL6ú3‹:—g›:‹¡RB£–†‘ž/Îç»v­KH©—Ôï[¾­mÁò¥®S%{ D4ÌuBÞ…ø,&ñ~‰‚F?Âì–\WöÉ¡r€ägµUê—ÚqqÜ6Mgy0#Ï•`¯Ô&Â~Œ[¢é°ŒnÒ#u"%`£–ŠžÏr­çgäeùÝy£ç#HZ@#‰F•Xý”ÚèíTÃl’Ä’2”XÇQ[ľN1’ÔD͸©ØÎbÜÙ{òdEÿÍžó¦˜ßTŸß¯£Y4v̪ߔcƒ>´ã¦´ŸÆ½;åø³U>.Y'²–¹.NŸöLM-©Í•åÂ߈¾x6·w\uÂTõ *ÁtÛ©X„ø6‡{AFi íDñËèŒ}âýì¬pK?N2%-MK2{%¾,æ)ÝPÍh5WtK¼˜/ä%‹(ü¦„¶â VÝ?Èþ¾uôÎEšwž]“¨Jb $Ùd+¦_wZ+MVÇ3”Fíh¹ÝG{>ôº0 ¬{ðÀ“ [^Ž O0~öãÊô`1õYû +*–÷oz ×PýÚúŽÇä–G”30¢ ò ¡€?Žê)^¿)’£Êw8:B-sìFDò±û¹Õ.¯ýaËmwñ¶ÀBUôz8sš3&¥JÎ|ñ$¡9ê +¿’ƒ½[žBš´¾™Kåd H*ž±yÈ"ýƒß ýzêXê>ªµÌWÕŽ“Ѥi$&N“yu°BIsŒŒÓoLª¸IòD·»ñŸ’ÆãÇ•ÑlèE)÷—¡OŠÌ:˜¶O-h/_cÂ:u* ý ‚(ÖÛõî9ç}y}F)ß×]>9]¾¬šæù%†­Ž8[pµŠ Úˆììˆ4eAäÙoÀÄÜ# Ò¹äY¼I©[ˆˆu÷Ìp•)ÁæDÚøõ l¡ù})¼ºjoÌa %h1•l­õíP”Eöd¡‹#ò!Œí±Y‡q4NaB¢#@÷3ÁÜ´*ìåFÖ‡ù–[>¼üózëþ2‰ØMÌDn…Þ ÜwKØ¢Y(i£X‹ßüƒd¤ú9ò ¯L,ÿì“^^ñëàö­ÂóY%)µ4ÙZ\ÔötôÕW¯ù­i ¢7,qK“ñâ”-Ç?ÑúE@•àë#¼‰&+ƒÄ0¸Ø¡¸04ºœ5Ö–›ÿë“WåÔ/¶fLƉèß‹›¥0³Å¡u±yØ°Ðu:¯Û{®[’ĸ2Ï}’ cu¶Þ÷²' )¦Z`‡`\… c¬—ÖÙ±{OÑØD°Çré ám;€¸LÐl} JÜ„Ž6 ‘nþ‹‚>°§nºxŽPc=‰6pÊè)L[‡+»†%ª}'¿P°aŽ‘45¨lG½>(ÅûE&-#Èkií·jEüÅ×Ö "ŸûmUó˜SvL „„§=ªA2Ÿ¶_5J¶Ôø¿ÒU‹‡_O·V°mîl= +æ7ÒÁÒq3‚`¦ t.Ó„c‰Nä•×wíÝZKGº¦Ô›.(ðÔà^æÕ—w[.,ÕZåŒ +cGM}!;4šÍCnœ®2'ÖÊïìù®? Œå¯@9ÖË'Ñ®æp]CÖ-C¼Dû]QPÓ-}yhÎëzqã©Ýcô‚®ËÚ+›ß™A;tocšn’Éæ¤-O‹ÛÃWÓ•ºžÛóÛž:]‚é#Â_fbÈ°g‘øÌÇ õPŠ€Ú†ÑPÅŽO£ªõdU “ï6dÍpŒ‹bçÆ©\¦©Þ÷Œ­;£&{"ÿÚé,–ŒO_»ÔÇÐ9V¼47M=ÍaÍ]:mÎïGAã›P.4”ªþ3€ãd—&•É–è*HfÅ„÷‚¼M:ÞÌk(g +4–·öÈZýjH sóG··»èV üY).üjcPÌ¥’»nÞÝtïw¼RÓTÔBÇA4MÚgw†çsI2½¾C®æÀɳ/™CŸÈ<€µƒòðð½·J'“8.}äjðg$Y[ì3úØ“ü=¸ ŒdÇäRŸ\4˜Y^ ßZóÖãD`LŒ³8äûX‡¸xã-·òú:Õ]PUˆo3‚¡©q¢ÎÈí¯¸âçü%­F~Ÿd¡Ü17br'ÓP¯Ú.~ÈFôêg´ªš’í2\x%ÃE…§é[#ùÍ[8‘çðÞÞª'Õª{±ôV2ZâvWùS×ve?sL¾d5׬¨sôßaJý.–óÌê0Í›øñ(#­FÎv}MD"]˜2?µfÕ_kÜ͇±MÞí'–‘nÇ[ gÞi×ê¨SÖ—¬€ðp:ªÌð/šEù3/ùkÑÍ Û1Æ•U +ŠéÑ:kÅÖ ›r}’õéŽVbbérªïHÎ7Õã³ßêí¥‹_©¼“×2[ëAõ°çô­JCRz!»‘<ùq3mÔ¢W[M0hÒ VÊíaL¦3zb¥ÿÐCNãú?O“lVŠšßÍÒ4Øë>Rj•·•ÛéD[÷87ž9(ÎÔ ëR„Ç?Jáf±;V¬32Ýy‚¢ÈÚ«òßü2ž°é: ;QU–8Ííx„µt¾n +vÚÑKâåÅíÍÓ¿½Í~¬?קS§ÎªôÉžµè6.¤K±“H?R‡yþnv8Âax9™:¯¼&ýµêo<çßb%ðórÿDí;Ú%§1M–UΗUÈÁXÒ6G«NJ"€Ùíì£â%Àì”w¶ðtý—_7×¾`!—ø§‰×o>v²|îÁÈç™±ÈBu:ºXXv9’nn*Ç÷ÝŽ#*%)½—-“u¸3ôž¶ú¯?N ` +;ÜÆŠF¸*Cb&Znf]C¡ÈN‹×6Á.þÂÑ, èW91£ðà«iK;m+úbTèSpïGsÊuÊkÏ&ALH^Ö™FV{ð$ ÝkúÝMbxáñå6ÿa˜ƒØÅYå›a¹5°þ¦J0Ëšëö“©¾é™ý¡ +Ó†©"S—Ïz_¥¬Sþ@Î lÀ£ì†D/®¨÷þ¹B­c0ˆb( º +ƒËsˆŸ.ÍÏxP£þþ\ næèJµõN*·ƒ7A—^…¯f£èïnò˜Øc#ï|<ÐŒ¹a=íÂèœL¹Çt}N9@œí2ò“º¬ð;ŒÔ’`Ÿš瘓gÛ–» “(kw“Hˆ«fz# ü«TU5aQW.;ì§øtÁTK!bñ6Û¨Ú±A2®Èü„è-£þ|âáŒMÍU5j2~áúˆ^]i‘åe-·¨^žÿWeoÙ~äèžÞÊ„×Cô®ïw= ý² {ì}Åï÷šNå)àÒ„½\Š*‹Jò|±WŽMí¡±Òøòo- kÈ“èZ±Õ6"Ù™þ\W7ϧGÂ}VÁc§Úª4ØXoM7ùwÂá›P«cþÕ’Ûl{lY B‰©Ù/šÌÝÖíü¾ì–­˜T¡ÁÜ?ï°êšš+‰¾Å’Ñs­êŠGô†äv5¶ÈÍÌ?ÈÖ§éBÄ<wsÕÆصŸ×ŒD¦¤9 ߥKòã_Ý»›’«á`Ž]} ‰µñnÃáhDÜÀÂ\É&*NNk…¤û0œ†»™¥ ›ýÔº˜Å9}­Q}lêœDª0ŸœÛj2wü“¯µJ÷‹¡œéÃvµvz¬,Æ}úè"öìijƒŠyñý›·î ’±¼cæOˆq¸Ìpãd:3ö¬Õ¹$c¿_W#ò4ºÑ1¬ç¥†Á z,8ÚÈÕD-æ h•’ö5Cº ͧáƒ_%wÒªu¿ â#¤Ç”g!]7¾ô/BŒ]eh©IKôŠ2¦WTŸuÊÊŒk84æÍ¥0Ç‚AÞÈ;b•1b°mÍH;í>nôÏ¢ÖR /#NìqHºà0gÚ…>tí°§Vûa¶ ˜/æöŸñü |¥sçYà¨q³Ý,ÙŽÆ™(®” ¿œ^õÏ‚~¢­Ö>ʧÐÃwHv«;ø´þâÎMÌÿ$ìe ™´´_ÚژтX–KµÆZåÀËÎ)\uñ–Ã2îvKËý XåEÛÒ7ÉG’”¡":1£ëV G½°â”ÀÑ&–Ê(è1ó›Û9‡?³3˜FÛRâåGcM-,‘kÖ!í¯±òÎuÈþ7æ;r…½VÌ+r“l«á¢ü” ³˜¿4{k{#í"øKMaëb³y÷ý©ÐØ l/W^ïo<9[<˜W(§H‚I§,âkíŒ{·)G<«ªfÉÝqIbÙÈKá«J-p_¶×&,xÖú~Ã!C‘FŠ‘Aã”Vh0–à¼ùMeœ·È¾„B‰?MÓQNqXA÷žŒ#´wøÏ4æm¼ðS"u^5^á1vÛv"®3P£ÂîƒÃ Âù^Ú&5ÄùïzFƒ@PD‹oŽ+'.ë²Üãa9…@4uÝlXÃÇ1ߟ¡X3Žª‡µ?c(µNn¢--0žà1ò†´Ñžácó—W¬¼ˆÉâL¦â™w ·9 +Ú…W¨•fI•M@ï±–KÉ­7‹û)Cc¢ïS`…,8'Îl[stÂ<¡\nc«¡T&8Ñew‹¹ƒã'}'ÅrW÷ ŸMì7#X1nfœ÷ ~¸ŒÓ2Û*¡U§ %›ˆÁÇ:èDMÂ|Ò.Ž«ªˆàc:š®)IËü*ŠÎ¿žê³Â:rê2:Ò©iWLÁÎ=¢wßÎÙàì­J5 d'XZ;UïÑ[ˆÉô+j£"dgO5!nYÙÚõmÒ/‡`ÈÛZ¦  Ã9LcZp)©Ê›ÓQ$7ÐâänX튌X,ðO“˜£Òâ'ؾe6\0˜`À2ÊâL— ÁøÁbÂrQu +ºâreA5n!Ñ…êì]Œ¨ÁºØ»‚õOWìõHƒ:Ô…—‡uÀÏk2Q:ú†Édf¬š¢ µ‡$EÏÐï8f±æ™€âNØÔ@Gœ¹}\=ñõ°¨öˆ¨‹¼_W/nÀÄbÛíÿ¸¯ß0^8U¤>¾û=O?°g›¾U̧[aý;óþÓSX¦ä”gÚLÁ´·¹‹.võ@/Ò&ÿ”i:dÏk0G£u¨ð“rÏBž7gO‚w üúàü•–”À‰KY&j øœ7¼r 2–á°WNÎxëh“õÒ¿Í7§LŽ„×VC@]ÒÖóºÁ*óë-Å ÃA;}üvñïiCU…—.úZl¬ õå?²ŠcHÕ¸´Ôu½ö!» »†ó±œW‚Ñ/ðó\Hvq•bf€úOÕy3¹;¾Ð¤ ² ÜŒ°š'ÿˆêIܯE|Ÿ¹ š­p:ÔC9èc!¦²VûCÕ7òÿ2]„2ø²âª³ç½ã,}Êø%(ê’r‡ɆfQþÏÈéª{ÃÅ3’u7õ(;†>Dî`…°éö'xN°?1jaóXDOÄOTÕYe¸S;&bïæ„Ÿ"=_ƒÕL+Æe)ëõP +gŽ}“ú£qÍòÛ¨ù›ÂN•¥•îÉ/­„¼Ÿ¿¨ÎwýéN­ъ”⃞êöÉ(ú˜i.ŽJÓY{Ê…ë߃ˆêo&ãX +Ë|åT¬N!{¶ L•„«a` K=ETBÔSEÐATMb§œ +Q‡Æ~ËJlQ‹Rü¶×ZB§©{g¯ ^x™‡¾m€ï¨LŽ1p%õïø×ké\¤~}ôO½Ü8Ûu·×çqÏÜV»ì*æGj¸ÙÛ9ýèOâ÷Žû’VuûtñCv.¯ÉÞ¯²”ì U=Ú·rèöI3 Í¢¹ØO7( S~ãÈ”‡ «ÒÛšt”š®`½öÈl/ÅY¦37›„Û¦š ;ŠôÑ à<‹ÆN–T‘Z.!`ßêã…”´I¼M%0,(`Y³¡mm¡ §&ymr¦-åɽ.§æo·œ¢ŒEŸ¼B91Œâƒ!ÈD4B\\ò.½ Ÿ†‡b.ô¾=ƒq™“s,|Ö?¼´~8£»»³­ +Ñÿž¶l ÷ö" •äjÓ`Zo…hbµÌ}åÏ0—ŸùoÎ*˯µŸÞµöñæ/~ úÕ'Kü@Tƒ¯k5{<‹i»ö—ROBz@-+µyÚª«1èûŒÂ·–µZë¿ÊnòEp7âPi«ú€pV¢;g.Oã­pÈTA3V.ÀÙòV…I’]UAÍÊ&¯æwú{¥,¿f +ý’OP\h{†!Ë/:9*ÁþNª‘À„y†Ý¢›¼~¸®<rÍ¥Ø.k¹áR\ÄKÀõ=™Ê³ô¤µéšàš)É  +Ìó¬¤^©êzX-Ta’•éÔUÚjLØ–‡ÁPϲ ‘ Ú €,j%‚‹Bè_|³yŒß]¶to7ɹ¿"Á¡ÒW¾7ÉÔ9NÙbdÌ÷Î2s—O‹D"—MêÓ†l›Ñc,Å=Æ/¿ÎWDk¿þ-ţø¬‰tF%ÿÐjwÕïS;ù^É£ ñšo?ñ +ÆQ'?ßœ†*×3;ùQhþà“R¿«A±FÌb<\gÜÝ@ƒ×oìfg,ÙS¿´íw*0=a{ æŽ!Ù5"OBŃð4ûbü[ïR«r‰2Ó'VìÖĵv\PjÐÝh «»Œd ­ªÌ'3çÜŸ¬ô£uªü”.ø¡×cšÎO +DSmÝ÷dU«TòȨr7)z¡mYÅÀX˜Ä5ê¦[Ø÷ËÅŸ"f ‰@êéqD„ç™Õ'~ñHA[€‹Vû¤“õ^C +ݓ׀-xú€°šNceŸ[å˥ߺŽ1½é˜Ê®aYÝ«ÀF5PYåaÉ|3ãä¡ïbøM@©Nyav.åh­nî×ņ®ô²¡RŠÅ—ȬŒWyŸ¦Þtƒ7×ÔÀOkB¬œC@ƒž©êo´dÏ “I¿ü“Z©þä}\žÅ’gÎBT…bM+5êõHzJžìfy®âq +C¸ÎÞ•¡‡›û/ìë aLãdU±Å,[g¯úWСÖX·V7~æQÈ¢%+ð?éצµ!ùUè³Êk5ãø&Z£Q‚É [äxŽ-b÷uP…#Ïñ¾†E@qIÀ$ä;®ŽVçæ$#ÜíkôëtJ€\¶p5žr„º‘¢€$|H{U¡øæòƒK]N}¬ò†Ÿ€E×D° +FÏ-¶ 6© †Â ߸ŒçânVä^… ]šMg\ÔKÇ·ä 9·/£‡õü7o¼¾¾Ð¼­ÎÉSö'ž”Q®¬þ´òB†‡Òe|°ià”¸[‹_Ý‘†6ùŒë.'¸cä½M½åÕr\S>‚K䃔t§C稶h5uREæ‹LU§­Òƒ˜Oôz VÇ‹;¬¤'áS™ÇOXñË€¿®›¦™;µWEƒeÔ #:0츜BøUª,ØÞèb +Òó…2pÈ^Ù†:0|&e¦Õ,?‚HFkJæU'ý!qÆYµwß³HžÿÔ«œ;…ª»ž–3ª[œé@—hžÏuãrnL‘;®ˆ=bªy7¥E>°áíîä=HøŠõzŒ³šâs|Ó߶ª`KA +Œõ_P-ç'„HS +Л¨'ÁÚæãy¿ˆ Re†êi[‘¯²2Ê2ýQ%™ÒZâû®žm-c¢‰LPe³o“=ÒÜi:èÑ'Ðr^ùÑ­ßÔ{?z$É&aM%*Æð®iÞ ïÚ‹š%4Üôí#6¼± +´!;h¾þGáÁj2Á|O¸D ‡?ûµ“îw¹´`ªÓ¢¿¸‚’cçÅò¢†‰‡Î·¤ÌaŸŒÄÆ툗62A»wÆÕ(†“Øs/A'viÙ.Ü]Á‰µ‚7*‹4¥'O ¢ °vŒ÷øF34§¡Æág¢O¿u¬.t¼“®rõ–s}/¸šä”ôÛºö˜#=ÕdrõÔVL­WVŒªÙÄKã‰éS.“ (Õ;ãh"’€}R>•lÏs¯ì³²Ô!¶‹lAËE:ßy&ôœh»Æ2©×Äë2+Ù®HѳÁŸ¨0An´ë‡Lš@°ƒy‡ß[q8^:ZËÄc hjð-¦B _¦–¨ñº€ÛJT§ûš5j9È«>Ú)¢Û»nSÑj=³ÕXër÷Hl_—rß:¯0)]F: ”Ùtë,,pQ£î÷s²•õÒœúåx.Þ!ª±…» šMdÙŽ%󌥢À>­×בtÍýh;ÑN}ÅO™~ìx[ôÒ[ ô)Ò`Ç™[z€Ð¥Ç;ÿµbä¸ ý· ZÛ±ýW=mVùD×®9, «Ÿ³e,ëKj}Ü üï J¼,®bðýÂò3Þ2¼ ­h=Á‰U,jï% +ìé×¾ Ä92¯kƒG`µÕÂKþ{|*Œ”)ÎêÒˆÁÄRéAîCêD´Ó®ïÒ‰svѬµ>cj +6müÍpHr£\Ik[xi×$¼šÉH$S<ÂÐ]­H;"þÏ] …h!ÎK Ùç wœÙƒaƒ!Wo§têQ‘21¸¦e}œDó—ýªM¢Ê&ëÅ"þçÍÜ1IpÅQè—{ØAÛ»kJ‡³÷4°6ŒíîO«Ö*“YŒÝ*³A"Õ±«Ì Õ r¤eKãùŒ©$a^Hœ›Œ×ý‰ÞFïNûé)•7µ»‹i?¦: ¤®ý§"×ñ—á +¦y¼5âéx Î?8€†,ÄÙ%š¼ø*%q$GÐ]È%\íðÀ¸¯±ÆLÆø¤z*­Ë"7›U0ž$¥¨ ×”€ïøq*櫸×\~ghL[ü ¢rñY{âkây9‘ä¹_­-¡„­“ߣ|ÒœZ¿€ë˜û.†zžÜbé>1aNÓßø–à—ÒK!5hI¾?K3²< áŸ,ÞÅÁ¸²Ü$j:=úzåmÈ_N4ƒ˜Fäûq +°’胱«T«þÃ5jíaƒ"¯‹¬Î×Эô'7kˆ]ú†A§òuSà‰epÀƒZ˜%ÆÅ…¹­Â¬¾=úð¤´~¸Pù*€üÕÝ+àŒVd˜¥ódqɈÎEX—dÓJHÁ+°:ƒÊ}Ð)#ôø@ײ!R»ÿ©€£ì–ù +;\ùˆ¹¥e7ÍHÖx³¡l½ [sÉHù[êƒáëXôËUNÑõ¢i X–Ø«c4ë7û\Aº0«<{ Evg]8xp[lZщ5õè¹r÷ûGâÈm*Nêê:Q+|‡gµ}ÁÞ\d„äO¾>hžDä¡GXnöº +b¸¬óÇ;½tÛÓÆŒ£6lÄ”Å>4ÌÑÑ0a=‡ˆ …˜Øà zb¸»6û€x{³IÝ)KÞí­[×î÷7ÑÙ€ ï²jP8b*æñÛGŒŠw4£V³ü2ÎŒfu3^üL9OOW3èPq½*z5la:ÏÆ> ?Òæ3zîÔL¢Ãùïú÷~¾­ÔŠŸ+qqj²„îÌoƒ¤ 2^›6Mäck~·H‡Ogi$q5|©/̾®¿îÁÛë3úï.7ÿ”,—síÃ[|EØ9 ®+Á +ÐQk|/Û9¾ÑxÜÜúÙP7˜ªl©¼å© 敱<ý6œÍ¶Â=Ÿù …3ñTI‡@TƒÌ07ƒI`5¼áô‡lcoƒ|áþü]¤ãÏ(^¡¥µºÈÕ6ÿCÞŒ Ú롾—lšÒÚ´ë÷aµ1Óþÿ×Îœÿ3¡¹—çÈÊ–#Ɔå‘yLî£æhm+÷U¹bó±'ñ˜#GÒ,Ga<ç,÷s¤„9a§¥|I@µ>¬Ó ‘ŸÂînÞñ ±mŒ¼?Áá¼ÃñqJ˜.áC{¸Ús oÐþƒ–B•(­dfá¹È|ÄÕñÂï„Ó84šÁç2ˆ¥(phëž7ÓŽd5ÈìDÀµ€ÛæIl]Bå'IÑ¥ôFÛ܊ꨤ!šFó…L`0\ÁàÛ˜‰¾Q¹u3!skA$TˆBØó“É°`¬ âŒéúŠƒŠ–%¹Î× Aä÷öoŽûŸ»­w‡¾ÙºïÁ° bCL?í<:Ú _Þi 8eT)ŠD¨á~ÑH½ØÏ7ceÐès6µ™Â$ï|ûŘ‘ùË âæIPÈkfåöVÔBÓ(ü +šþˆ/KnèEKØ(xÆÈìƒww¦\3¥kÔ!›ùÑÆlð›Qe8‚nÛh’8¯tãær|BUw•Q“)€gÏ£ŽWºè¥@Pñ„¥¾‡LZð7×(fÐlç9¬Œ bf r·Ñá·šPæ}p +øš*›íßyýá“ãûB/1;Aì2ÕÙ3ÕSs±‘woÃñÕ“VÝÝíßv¼¯å¹ÜÆ{¯’XcÇú9'*:ÞÒˆVÂ)BSzŠ)Xý_ƒÓŠÖpm{§z¼¸—±u±)ôc¹ÿÕ)€+H2Qi·'Âڱ׉×b@akÊE¿¢vÉÃBakR‡å:›ñ†‡Fˆ~¨êÈ’Ìm®g4šv~\œI©¸ +^ýì¶<[7Û-ú%çq´Å5mââËÊž¶t“Bdc;|WÝÚú7–xSyåÈ4ØÇÖv´¦×Åõ Q«´˜„2ã¹Rwr\Œ¨ÇÂCÀVD +­`Ú5øy÷»é@k"¢™5)Ï1·ØRù-DÒH Ö»¼ÍDdM†o3w»5Gv`LÐ2îä¯uÈoêb—r›[ˆv^Ð^P€ó]üQ¨‹ÔS^?¨Ïóè_û³£ 'C2T5ÍyÅ [<;ËÛÜ}‹hLé4mMmÖéҎ/À}"ÑçB0%’éVE~µb(e’ ”峕UòïiN“ýië€ëÜ„{X#Œ=dÓ[娽 ÿÆOƒHð”£Vê ªëvGJMGÚêåÄLX^9ymiZPpù˜B5«¬Âø#…sW+* ¨)¨OñD¾Ë_*Ïøy81¢ÎsY×/NI„8wÖ¦.¶v.rþ÷¥äïûˆÍžá¹ˆ“¤;éë7¤{®ÈEÕîÄìø‘VYƒÉïÌ|ÝWN`ÄþÅW‡Ù¾—›º‚ÔÂâsh™ËúÊIÆ(ˆxó^m¸ƒž²Ê+»O':QGrçÉ×æ[XFRž;j¸±·ùI•šà5A0 {Ab8A²T†’QmO@ i©Vél³¤Ó¸£CX;䆔¢$ŸaP÷ga†kq*Õ{²…nøglƒ’¼2GÞ Y•.ß“­õSlôŽß-%-½¯·e—ppÔW³8©×‘fÅ¡Ú=ΆþKbÿÿ‰À/$À'ê,öžä÷³endstream +endobj +940 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 34 +/LastChar 125 +/Widths 2101 0 R +/BaseFont /VWNNCO+NimbusMonL-Bold +/FontDescriptor 938 0 R +>> endobj +938 0 obj << +/Ascent 624 +/CapHeight 552 +/Descent -126 +/FontName /VWNNCO+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/nine/semicolon/equal/at/A/B/C/D/E/F/G/H/I/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 939 0 R +>> endobj +2101 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 600 0 600 0 600 0 0 600 600 600 600 600 600 600 600 600 600 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 +924 0 obj << +/Length1 1612 +/Length2 18760 +/Length3 532 +/Length 19672 +/Filter /FlateDecode +>> +stream +xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)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ÿ¢ÎðC\S^X™æ?ßÔ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£v SO`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†·Õ04 y\·ç¤Í¨ƒÎ¬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Ë–„\ü_¢øð?¸ùº»Áý\}(þGªßendstream +endobj +925 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 33 +/LastChar 125 +/Widths 2102 0 R +/BaseFont /XFYNBR+NimbusMonL-Regu +/FontDescriptor 923 0 R +>> endobj +923 0 obj << +/Ascent 625 +/CapHeight 557 +/Descent -147 +/FontName /XFYNBR+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 924 0 R +>> endobj +2102 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 +884 0 obj << +/Length1 1620 +/Length2 20127 +/Length3 532 +/Length 21036 +/Filter /FlateDecode +>> +stream +xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø%ìlA ,ŒÌ<5e ECkkC ;Y)¡5௙’RÔh²°³3y@€Ðð퀅›› jgïîhafPÿå ¡££ÿ/Ë?.#÷ÿ@þF:Y˜Ù¾þ}pZÛÙÛmA)þ¯U€@È0µ°Dµ¤ä%Ô’òjI -ÐñoŠÎFÖÆY c ­`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&ùïòbšŠtÿû½ú/?Å¿úƒTÝí€ÿ?‰†œÉ.þa±sx2°p2X™Ùÿ»¿›Åûÿñ_D,ÿµ–39Z¸´™™™Y¿ÿãó_+ÝÿF#nklgòÏŽQÚšüÝdÿiø6vvtü«í¿Îýߦÿcý¯íºÖWìŒyƒ,Ó2ÓAu¸¹#SbÚ},#Áö¥ªE~5v½¾ia»Ü•µÁŒM3<¿ÛÝ—Ïí?¥iÆúp¬©zS€×ùDÞ4ýè[_;9鎘ôJ‘Ó/4¢:2Ü{ ÝHH— OÉë…ü5ÒÏ!‡Pð‡Z…xUó«Óö”ê&BÏØ>ŸŸÙ‡PvE‘Ŧ—µ‚ÏÕàO͘ƒá†€l¬„ÔÈW"æþx²À £ŽïIx%Q¼Kâ¦No¿­ùWcwúŸò‚ßÄÎ׊ü;L§V‘;fT° £Ö.ãG¶íúÌÓÎõ=®>ÕÎ7èX¬JÌ[ÃZUýùbªÜîA+_®›xF»Íc¨À( ¥ã©ƒv¸\Å$L Ò…õ)_,Ò ¡Ã4ŒR4r-Ø“©¾ˆ3ø‚2Ž‰Œ€$¿ d-ô~“„}¼Dä9&G9?á¬;Ô6®£ÛB‘œ´Xsÿó/w†ßöèWŸ.S?649ú0|‘ßãš@΀ƒëì˜ç3¾>9È%æú!.à—¼Áô/mH‚Þ¹U'g7¬«T¨y㨒Cº4œÖ)7%Š_0iôGàìáä}²›„ ƒåÔ›xêÙÄ6\/ÓÁ¹Ô¢ÑCnoãÐ5-Ûu. ê24|jþb'U//g7~u®›œ÷äkƒÓ—8•†n¤3€j}_R:âàÎ>)[kÛAP++Ïú;iw9¶»¼ª½ ·c¸A{÷¿Y‰ü j¿3à aÉ»ðSr°Ñœ¨t2ýV å +o(:¨Ñ_‚ä¤ñOFuØI)Q’¬¥®‰Í:T\+kÀ2ñ´Ò(ÏË2+­Ô»Ð]é¾çAM¾×Q­?A"tto¯$ÏÊAœÇÛwÎB¼ã¢ü1lþUxq¨eÝÒäöt¼d"$ÀÇŒ‡™M ,tEÃ2g§ö“0ACª•ƒÇ“IyàbLżê|cÔd€&ó­Ðƒ}7ÆÐJVóJfŒ!`/—ö©Ä~iCB2l´–¼â¸¡Å·Û‘ÜÁøÈÆ + )/úh½0HéZ=`|K›@?ôî3Ob¨cËLádÍíìÉQûcz‹þú7¾cèü¹$ Æ>2Í%—¹ß°%F +>@í£dJî'¾T¨WÝ– ’ÆÑë«úþ®@Zl—,P* ï™7o6x©bäÀ×ZëíùOרc ‰^à°HY¹ê¶]¼„qGÝx- $v·úyüJŠÑ‹lüwÝ„ze|5lÇ¢‰Û&^^Y†¯d¤å¸=眫Ø'ZðþžQ.,°#p¯ü°Éøù¨~j‡|i¯ÖÍ_)¢é<-ëqHb_Ò»S3‚4~«Ò/²Jú +ó»kœAUyÑ® D‰ˆ„’"µpVk_í+t·—$ïÒBhtçß’¼`ª-‘C†Èù}îÒôƒ¡OQN¢¾hÉlÙ‚¦X©ÍÉÃÚ-ðÝ󜚮Ӳå‰f]D–„]fp`ÝLWý£ÄÄEäÑOT¢ÿ«0ûž†zܾòïþ׬M +‘ו‡ošDƒŒ ¾”¹yÙÚ<1Þö÷Š3 +9à Ù÷:Å„Ÿ\ÉFlý¹ŽNÁçµ±½F¥1¢{1I#ù#gÐM!Å&Ð!ùf¸¸<:â‘[Ç‚êÞ—dx²UÃü9‰Åm³{¦¨F®Aº/b›ƒÞŸ&ŽiÊù0ÆÊ<É{ –3Á—)t;¾ +I…ÆÄ8á J’«2ðÚÁF–û†t÷+àK‘D:rtËSα£³ÒFX°Y¿ƒw0¢ºãÎo‰Õ"Ú-P¼L>Vš˜ñפ2 Ynîë|CVÞZsZú Ó†x9„ĶU&bNž\@š'üýlNÔÞû1ãWÎèjöE¡¬¨ÿI1©~´Ç)¨¥P#çP&¦B5ãrEò¬é&ÜìPÿgÖ©‘ŽrÏ3ä5ë(h“‹£66q¨ JÄ·­ ï|à·Ë Ç#·û:[‘úìƒîi0žì­ÎÚoœ*3ö8¡|SgrJ_ˆ·¬»TáZ‡%{ÍbË„pøTþÃiK¢`È$Ñò-ž— r38‘nü9jNÒúzzç÷˜ °î¸×ÃÈm‚t ßk–ßnŒ.ƒjÅâGr Ÿ¶~Ýòz^o +g}%ž¿<ÿš¦¢§y>ÕdsŸZˆ—ŸäØt‘ùB<*Cuù­ Xò4RWJY¾?Ôse4¿¦öÁGGøË=1nI6ö>â¶dxøÛzÀÛö§úø÷^`K­™u ÒZ¹$gMÍÍE®Ý§R‰³› |~Π;âIךÚCXFçÔ[ "9Û\(:Ô/œê4Ùè´G÷b^LG9DyÈ‚6ú+ìÖ?óÍv_æÜ@Úz¬ºy4r ²ÕEëæfNfS\ý(„w!Ð+`'èìõö½Ãºk0Ê1pI?ص€ÝK?lÜT›åœ¼lîSè’›šæC`-ëJœª{K'éͺ¯ÊÕ Çƒ„¶õÄ&]_\ãN*Ž²ýÈ˜Í ¶q™â?tâ‹>Ú»ª¿[h]ØÎDi‹Ø?•ƒ] q‚ŒêH¿(OßM Þýa›kP …Ìùj†§lL_Iª3e#9_zÇ…q»¢«¾I¤DKi‹KÂ|Áô-ïì¾æãEP+ëÂû; KOã%; EýkêÂJþþ‰ò{¢M; +%Všy¯Žç½wd`õ\¥Sd˜4¬Å¥øïhj-Ó)¢1Ù¯tê…hE‘¼Æ’§@c]ŒQº,ÃÙPJ±Zõjæ¨u¯žYuÉÔÅ›òÊqzú‘Ÿc¸×µ#Gr<’çâØP|Â~Rq‚a?–Ôà?ÌÕ…¢ò-›ðå&•ZëCnŽ‹¨H鬄™NN~g’±ÜLwgz̹{Q\CÂàkîËãMN®-Ø\ÝmbdDÀ!pŒ,*-eG¾v²M×<Ÿ»)¦Õî°ÚQ ¬Ìô²Åc¬ÇáÓ7/ZÓÀ¥¢–ôæ!ùOInWþþXÞ€8ä„áU„4ƒÜ42ôgYzY,lsûtˈSòî’üZQ”²8 !Êó@¨`úžnLnï¬?'@‰R§³ÓÔcz’jýzçÑGD”ÖlþhkUé.ÁôÅ0…{)ÿûŒ<Ë) ÔCçÆŒ¿v—f6„øzÒ˜êïUì³^¯È€žžs<Œ¨+ (œ× +?>Lîw\_¼__º‚+úˆ—Ï*×5²,Üâ~‡ +ËGBÐ×4$<]q…x\6_ÌI_ϱȸtÓ<< ±ã[ôV(“K—ê£hAÑLÿžƒ«±î«k”“Á™-H¼~„ÈëRtàÆ;ê¬ԧОSŸ«,Ä>x›ºQmMΠà¸ÀöH|’MÇD-2:s»ÁK¾jÍ)yu$–©Ó:ž•([mq!+GŒ™SÞz‚PùÒ†ÞjLñpö«Ys%²Ý¶p¬z.M[›t]Þ§ÀŽKxÀKPų½×ÕêL•ªçLý=à'd{ì-¥?Ö­#†‚­¢E^+#6#– ñ/–“õ­ñ¼ÍTñÖ<ínÀZ‰/”Ú8Y2ÓØ/gÓAÓ›øæ±,dx +v]šÑØ}a(ôÉ:eÝX!±«AÏ[–Ž×ÊÜ’ÀæƹƣÞ3a‘^£ãxR°šË\ì2ª<2€ÿŒÍmxÕîQžæ‘QáE‚žÈ¿¼=±HF,ÃØðªÊжÌ>Èü]¼¾Ø¨ÍqZ\Q0³“×-|/SS´æ;ª? [B«˜jÜë&BØ’ÆIRòu“$€„ƒƒj°i&ÝY³$——½å£-B’ +ç¨÷i ¼%0¸)xëõdïIG•&Ž¿œÃtɳ6†ž7|¸.&õ + -ΈŸçf™ÕÈPMC°3p§î¸eÚìq²áBÞæh‡~ò¨,þ¶¢Æ®¹ÿã +¥;Kƒ{jPÌCÛf¯¨“Ø£_:©Ãb*¬Ž–Ôº°AïhµûÞÈq‚F΃a¹¦Ô9›X´Öò€)t‘ÚQPAng©§âÏíÿ4»š†ü˜©>¹I¡Îúîá”JO¼AÌ°#­úEñÛÅŽÉ<æT»;×ý.Fíô«déÝj¸bÙ«k“ú§V«,þ|D—æ‘,4‡Ûj·vÝ–²ºyAñ—‘ùþP´›ç€8îf3A|æž{a­ +-5ù\;³½2>V®±*T# +sê«®0V—0p ÒÀPô4¹7®“Þ¾Ê܃#›}Là®Ižß˜ä•¾9h_ê3ú 76¤Z&!‡Ÿ†‰Y‚Aý±Â;¥§!ûÅóë\š[S±eG»tö™€JË ¾qWp‡þ¬ÎˆN7ÝId¸1c[9H©èMu„hžä?ø³Ùo°‡T2­„Œåm¬ÔæZ5·}Oîͺ!bîÛÉ$<~éø::¥½½ž„2Ž €O1W© +@0‡cz´ëðcL"¸¶©ˆ1tQ mhž7OyÙK/=mŽ1Ü´iüŒÇŠ··ôŒÄŒ%¥”v= \lB­×9Ɔ½‰ü‘“WŽÄõÝ©s;Ú¾†øðýa_ 7,Z±jg[À6¾bV¤ÊY—qá=›TLÀTæù4¸©ŒZä¹xæÇ©D S7Aof„ûoŽ¦¹¶†d¬Å(?# Í”¡4÷Ú7©¯;˜Ác%$P„P|¹Ú“k½T˜dpR(áæÓþ; @UÂŽåo.P +·?å?«ì:º;rº¶;(œåÒHBÐUQ%Wy¯ÇûcEàÝÚóÌãÁÏbמgo@¦ð­q´ÔDÖèÈ' )øóÁ«ÄhåHø*²ï›#™·ZÏYHá( %Òïg!›µ ß¿ûW{|êõhñGÆq¡ÄL»»o–DTèd·ºãú±‚e6D²]}~Ç¢jé‰fÙ1HD,zÉDx¤[®'tC,ôC“2ßíÓ[+'aæ%¬vâ×òAµƒŒc;ÎC:e›sÓ’/ŠVÿ¸lÞ+ã,¬zïpÂ%¿ìg.#C‰ž4¥ì#,þà¦ÉÃý\¬Á—¤&‹öðcç[5—&b†ì~wcÖͳQy•†øÀWœ±k´Ô¨ÿ ³6QÃÁ»kÓÞW´ÌvŽËËf³í®Ào×>¥‹;ùk/E'’r×i'4hözUZj +S(xÚ#oÓÜõç ç‚͘©ØÔäs½6º~ï6?\$Ý“ Ûp¿øæ ´wÅ@¸º·ÑG´=/á1^ØûûWM€Õ}ýÐ駋–Ê{ÅóZˆÔ(sï[6ìÂO ‘züñÉ'ý1(¸MáCªš˜ãôº)–æD8ŸåÏ=’´ŽMæ2_Úû+ࢊ.hmËÞycÀ‹0w¯ƒ&¬í9r7µqB´!KRëhlo:®SZrEýñž:™%ÓF¤ûX¬ö@fÔ3™Ö`¶ÉbcгûË€yŠ|{¸ ¡ïì¹Fn§È…çA™kÙYÔëÚ½ |â­±ôÈìÓDáw E)³*j³sý«‹Û–]vŠSl|œ¦ÆEÔô5L‘–Ñ – :Z™ÜŠ2Mù…%–Ð`ß¿1¹¤²¿‡T@@jL¨Ph˘Ԩs*ô½§ Ëâå®è‚ +I³ÙêéÇ–T©-˜R§5߇›‡þÚ@ÂÇŒçoT§÷uf‘‚‚Ÿ£;?®IÖB,$ÊqªG¶vÚâ¯PIJ •£Æ»¨(¡àœ•SÕ`RHáRp·É/i¼™É6rƳ¬È»ÚôÊvökU;]äW¸é­ysV†$Z k›oÀëãõK„ö Î£ æe*|LÞ¹*p¼§}¸ò× }an²éÜ¥ºÏ¡öÚò´Ú7dîyˆg9ÏÅõð¤éFOdtã’ý‰,5FYrè¼c}í¤Ná§à:†KÐe fŸvE#Ÿ?Íю˪̘ í‘0S(Ó¿£ME J+dL©¬¼I­ð^>|$½g'IàŠ´?"týy0ïù4=:9W8ùÉÝ1ÕØ”D…—ÒšòÒ»³/Ã1ðý¥C¬£ù#öŽi÷é1Dr‘ ?ÇBì6R6VdÒkšÙâ” \šž¯ÀßgÐ>ç¼u]'6ªû©$c6!Çác¢Ä£Ü¢Ãvƒ +6AdQ›¹Í,>N)¥Ò©ðOã’ÛÍ·o}ŠÓ3U¢ªõ3“ÏŠC…}àp)Æó¿a™FK›ó+ •W1{‘¨íœiNŒZ?¿~Ô<îZÛ×Áˆô~ô}“IU?û +^ºö*ÕÊ;â˜<\éæjB† :æ‹ãk‡o™ùžËýtaA=« ÓÔ'ŸÔÐH•ÄN!z^“«ÿw¢ëKËÌ´«vߪý'ZÎØS³_-Ÿ!¡ÑÐ9†˜­yƒ±<`–ìÜkÚìƒ8˹‚®UF¡èýÒ¿äâôëO‹¦3xª©‡ì†°b$pãÀfN2rI[ ÷Ð`-IêѸ\\AIëÇz£AÅ ;²;»¬·Ó@sûÑ’Ðë"ø ,méG(;vø™Ùd×"|‘"¦ŠÄ`྅Óé‘«¬óõlýÖ!|t]Œjø0Š–¬¿Ö¾ª0Z )ˆM&çEî+É÷Éœ GÌ7kʱ—Ed`X]ŒÚE•ÀQd¸À'D5õüDU°p¯)+7sZz Ce´– +Ý)k=g< +ýÀ”å•LâàÛìàwD#XY«yû¸é ‰zp£^àž¡°óRÈÒˆþ‰B˜D²¼¾Ý_v|˜÷ÕìÆ”¡v’S|*B‰ã˜D#ÑŒ¹N7uˆ'ôx’ÎvïNEy-‡UI 9̽Ç|iýB[}¥­ Ó¨ÜE>T ”;pf4_·Ñ%ÙøN} T…—Äï÷uĘ¿”õ‰¦ûñ,Ri.ï +„y„ÑŠ<¦ªòÐYtÍþz`Õ4ŠMÇ>f·ÅH3¯ð(±…¼]¨!9‡çߤ–šà›cà +è°ƒXC#Ä1ž7róѧƒ†1÷‹þØ*:½Ý +¾¬üš"¨ùᶓ°P ¾¢®tþkºô¡ßs˜8ÁºÌÈ8õc°ã9­•Qæ3EåŠü±¹ÙΆq«¿tÔöÙËCCY^"fDzJ +ÛnÂ÷Ù'Î{ü®ÒÿŒŒ®AiD–Xg‰¸N8T£lõß Ý¼ùõšâq’Þ¸+U‹í7›™Z¨ Á©Þ¼{U ìôtœ&ñ6»=¹3gT’>Ë€ijév¦r‚Kºr‚ÞDƒœR7$ál^é•4mtn$êEÒÙeÜã8½¹ƒVã=R¶W…C8.Œ.'~Všë[²­:fÉHn‚™MÂû¯®2P8¼Ï`@¹G´=qHw¾•Ø[_û7*²C™r³ŸºkÞ²¬Ã1‚¤Á7ú>< +Ã2k}„‡Œ°±hd7,=½åÒp3{9 uN4Òœ°T—£b ؆F–i$ïó‹'p‘}¾Ÿt¥™´ð^ɨ"3±Ut¢¡zx²ØÆx4D K¬ZógÜ–z‘xC6‹]äÂØý9&yóï³t6?ðÌ"% +‘¼FøCAÌÑð}>€¶6‡¢ÓVÛþ\ý di B´«ÙQ¯è.Ç~Þ‚´ÈÌ=ìäm’6yS$ý-Ñ¥ª¶™)P‚´)keÅÃvM¡Gã¶Ëe·5%¬_ØYûMŠKÒ}ƒ†Œ8 îÕŸÃl5wìóµ Ô<öÅ·£„²3dz’œVÉ ÷ + žóø.Ñ°\éd¥(š˜>¯–LãPÊ  Ôš3,¿Ô16še¤³Û²˜BG»OåÔÏæ¦_ƵW‚®e oÎP×½'”@ç×Ò KLýº-/ÞJ[ýŒxw]öG8förˆVƒÉcvÄþh;Ìšé£è‡µŸõ!qîL¾Â mÕBÇïã@håR}ºûür†¢'rû⣖í5qq!Š¥¥¾Üt¿°wô¯µžQ8É@Œ‹«}Hë%‚Õ›E1TâìGäìï¢vF9Õ´½Öœþó«õ‚y¦¹ØÍYG$RXs³ ¢ÖÌÄxŒÕ}èÔ²®å†ˆ¶DR¢$GG0!°Ýº˜ÇêQàQv‡{ÎúlÀf×rh`>-¸O×HÿËtÈG¾è¤Â³8˜RG#zÛƒ–´N–˜0NGéìl%¡§¢Ë.læ¦äyð»R×|~e@!ŽŽÔGê`ª0棋«å=,–v_æyN¸À(:¶óÌ¥kÔ/˜´@ÚщÝ2Ï$4;ô™d1Sží±B;·šjü“ < Iiß\ÿ ê™™Î9£<È;ôÈypckÜl"ºÇdcß]ªPí’›öĪ®Ê™x³}YÚð²UöWÓÖ°Å÷ê êy´NpY¨Jý°ÐKöd¢_Ì|¶jUM‰Üßíùº=B78b5í9S]âh?7 ØD) ƒšƧ̗ÌÛgäX‚ǵx–!6YßÃÛ.R8WÐ^õØ!žÃüJ½:±³tñÀ{›lnZú|£€xÎÈ›Éú¾¹[ÄÇÍ U7NÑoÁ/¼\€ZëôJ(šøºa™Ùi¤•?€üa/J£ˆEÿýý"«€ev×!€Ã?ü‡¦1áå©Qá<>ÝZ¬|¥“hà]12fʸ™§ž(Cj‘ÃS¦™úêûW%W%N_ììÉÕÈiü‡Ÿg='tÖ¾Íö¤â„6ùWÊÕfKd2žÊ]'Á±†[–àÎGÂÑ%Zu$o[fìÀ(ÿ÷KŸml>H×ýá<ňe~Òußɯ,gVi®ÔŒ¼³¶FUjé‚YKò–eŸ¨?ŽD‡.^– åª$y6àj)¼¹è 'Ç"äMï{fÅ´cäì²Üz+¢1 +°YN0ÛæxôÞù¾•·Z1#‘pÐG)œïò±ž{+¿ÝªjwÒ±E©áš=P´Þ7±ÙÑ[7û¦“¸NYYÇU¸ydyÀ3yzdC|`×¾„CBݤ0âF½Æ&nœÐ~,‰ÄÖº ô"µðóo›Á·¶±zÚŠ7¡t<=›¯z`é†Fx¿¯!­„OL¥ó¼‰cä¹àåOsLÊ…©V-Ľaw^ß +¢ˆÉd)$± ¶Š¸[a# :‘ÁÜ.‹ÍÉü7LÓ„(èòGÚyö é안øžwbMŽÓüÇÞNËe?ZÎÂfRc¯PÌeš²ªéQÚ"äI8 +4Æg÷ÎüôL¬¾¾Ò?Âlœá6_±Â؈u‡ëî$àÝÌ;ÇDpBÝu¢Cbî›#13º;Ï +*‡Kò·¶‡;¼-’"+ܦ˳-ý<ÎÈt_üöYëÎ’áBÁ‚¡$üé©Ò.&>Ùe¸R¸¡3›Áÿ]u7üaÌõñ.R8‹zAµÓãvnXLûçpYTÓôª['ÒøUÒà=|¹üº*ÚÜOAŒ/–*CØ ¿?CÞêh67÷ Wáïx,V½ªŽ_RÆò^/H–}èÈ;‡¨=+mä káÕÊuS®ÉẇNbnN’²‹Y)êctž-yá¬JHw‡d`‹£Mó®úí}KÕ4¬«–!øWù…sYÚá•MS |•Ð§D Nß"æµdYDéÖáÄúÑ¥õÇ*1öEÒ.úMµü–r±ÀÒüØ +Á4õ5’KÄó}†#‘.§­¤‹R‹« +õS—¸­oïV‚•¦x{ì—?]Ž{øjA}øé{¶$õ†BÇÃh>/o†"U¹»ý´P‡SkwUçn0þ€8âàB¶ü¾F;u¶pL)#–àa–é†EI!ù+hâJXÓP%*;fÑðáCyê¬ã}ÝoÒ¼¿¡ɧR,çÇ?’˜Sl9Ò«W¶ä'j˜¸¬UÆ)šµæ•Ïˆ°gí®œÙ­cø•XÞ|‚qbÈ£!1{¼ùelÇgÅ™0Ù—^už…ÒÊç„D_ºö¡l*·ðd¾Flú`‹Í,¨X KTŒŠf­—;û²#q~hŸ7¡¤Y'ÕynÚsëÙ¤…Ϭâ¾Ü{äcÍ2–ô-ÙþŒÜ×’QîPt®ÄóðZs‡’„¼Å·Q·œêŬÇàâr´iÔhKEF<ýçn|Ñ ;ÃÎ*½½Æ¢¨O~TÍËiƒ„½• ñÑrQ˜šÂ\QxöórÅs]‰‡ÉK‰×Öt©RŒ{±þÄTq>°/í¯ èÀYˆ8~'}j+U¤5]¦tj7ѳø6²ÉOŒô%òœíüØe¡ ÿýkFÁÍÄI÷-IƒZÚ[fã犴Šˆï;£À»¹{ý£›¨æÜ 6pÂédʬ ÊL +}c6!„L¹âP’{ƒá;D¾dçqí¨ˆz`Ë2«f§µ­])ÊFDŠÜ›/˜[öÃð"§Ê^wHZÁ‘³"¯oD{¼_7züä5àb«;ýS@$ú¡W °²ZðDò¢òuÙÙ‡W{fMÞ2ó ¥I*,~…Ä©¹#xÖÖŠìz‰KkVßL™E›)¹‚¢ÞIXbÄSóùÈ»´[N[lº3íLX¬˜üçw^@dqór®©aœ€ÿˆÈ«^œ©úQÔëèŽ0¼KÔÎs?Å$#ÅEA‰i×&ɇݻÁ‘$Ò©ü¥Sy‡1;HèWuP)½N® ‚’¯W¹s×![PÛwÚä” ïÜiCéW.䦄NMb‹Õžçáâ—¢ VTOþNÂ^K_çÛ.€ m†uÅÎåÏ0úvaiÞAœ,g5YaØ‘â×Ái¡Þø\¥œÑÖž-©* +G%vA)ÁÃG¬³¤f‹o¥¿ñ`Ý­LF™óVõ‹ÔK‰óÔÝwø`ø?qŸàÁ¨Í tj@®ÈÎê3cçÈEÑØK×O»Õò:;?I ¡ ýÅ!˜t¿£dæ[)¹¨øLIÃ-…Í6mïÄ;ðëjoà'ø|Q¸>ElŠ§Ôþ"$+Ä/ÊÑótb/w6ŠäƒôÝ~pióÁ …§Î`ÕÊgŠ²g²:¡;÷Y2&Ô%ó +ž(—NÑÄåi¾%¦Še¿€Ù?ó‡ Ÿ›o†`ƒbîª0Ø– õÚ MR¾Ýmc,ÛtóÓÇ@6UÓ +Xá…<§õ0ØC"ôñŸjè(–ŸÚŠeÂÑ_{Ú#‹p7ƒLìÙ5`:ì¥~Áì4«¼„?ãL®Ý8Qó\‡,OÇ™ÒÀ;ŒmhT Î§µVÄ! ¿h¥¦ž;t*ê¿ôŸçq !·Ë,·*¤Z…ΟÐWŸ¼T‘*”„6C‰:(ç›ø9ÖɵQçQÈÔGæǦߑ_<Â9ç×YÛ­ÐÚºMîƒ3u"JL üüÒ¦Q#ÆV_©©…vYTóVKYðçæÄÞU™gÔ»ð¼ òù‘Ïz‘Z(ßC?¢1Ý=žâD®jŠR8€‘%öøg×Èži2v»n›„¸MM¢t QdÂ*l%–¿‡RS7ÌÖgj¿¤‚<ÿWßÊ}#ó9¼ˆ¯†eç^™êgÞÀ Ïõ#²z:Ý¢ +Ha\»¤ÿEH Ü„Ôçì¾f• %bA¯üIÃvÊ¥lPsw‰8º8Ö­æŽÚz1IÝûQgÜûØÍMw­©•—#ŠC$=ꤡ ºí=ŒjâwÔŸD*/ÜÒdêÅÎVÇ ,M¹·KÎ?ß´—GM‹-ø’S,‡rYŠãÙ§¢](?*¢/GØRèÌõݲOR毙(š:4 ú™æÒøxÝ`£BÎ ´;á0dˆåÍvøÈnç”j¶ÐŸôwoå*ra|&£p8`ƒ1ÕªJs‡!ùåækz‡Fíãeo—É1.ƒ&xªMC1b¤‚Ïæ·x±Z8~"xOkËÄ¢¯×¼lT²”XQ  Mo¸cRt¡Þ aY7_.äNéT±JëñM2AJéŸÃ=k§Í"Ž‘Zíë%a]¶•æsð¡|jËNèNÙ Ùcš|GXŽÈc|G¸[«‰5G¶,€/œR\n‹l_`m>üTO‰+©b0é³lG¾u8ÂfÓºÞC#ÏzÆ?/Ùel\‘´ˆW°‡Ý×ôøüº±Bì¯7z%ÀÀ·Ú(»w)ûV§â‚›î»vM†›»ó¨7Õ5K#;ù +ž‘õ÷¦ÝÔÆ.3±õƒ¤9ù]v\_17OnS{‡71¼ôtÝêÅËCgû!Ìõ’+Ì\\j·Äž¸,1Èßß62–e€Æ§¥ì¶£þ&kL¿ÜêWÎc½aàJÚQà&AY¸Úãt¼Å+«8•õàZõг…V|Òœ½ÅÆú¡/½99tsDõbÛ_ÇÜÛWp vµe>‡ÿö²fßé(!‡°~i0bkzì¾ÕIä­ÖÙ²¥©@ œæ‰R&ï…Ãi$|i ׶Π³ùòR¥ñ-f —ºŸ æžæœby,I꾟pXðØ©»›¦Æ)bF°¡K·b¬H‰ÌçubØJŽ%Yô¶yX}<¹ƒùÂ3éîe›i0Û~4f$­z6n/¾˜z¤ðvÀÓx$×ÂìÀˆæÑnmeõaàtçTŠEð­*>÷ËMÉCJÁ0Ýg¿WæWk¡0[(ÃL(”ÂÁÒ/;í:1J ÛÙÞ¯£ùþŽŠ'sÙìYœÑ$l“E! ÿŠ’úë}ÈѸ/áK#¨ÅA­Ž^Uë“Ø~L¿  Š‚±XYC§»¬þÄÜ¥¹¾a.áM\…ætrQ×üÀjq"Üm £ÏÖ¶î½-‡Tâ‚Û%JÅX›M³z¦¹7SÖ¨úf ï0´ô³V˜q7´2AÚ€úË»X®Õ’t•Ö3çfÚÌ3C’{Äc6 b€¸Pek8ÆÉ@G•«EWf¶rˆO»iuw‚xÜÒqÌÿ8ihø©à¬j›—UCÅH»Ê¹b?,£LrE =ƒ¹ôñ5Ý&*~ê%ÐÕc¾îÏòX¿,Û qBN)óYþÁµe¤*±~å`r|"ýç4[ØŒ¢¤¤€í·Ã|­íü·‚PžéÉ+Qu|¸ÃH:^R8MÿÅ›ª¾â,FU-°ràQ„³sœð §gVì5qï¢< êÎŽ -d9ÊÉ„™Ö´š1ìÏ¢ì¶1CZVXÉbןJÐA¹ÒKMöS–GõºwÑ×í‚cþ` È1aeÿñG©n¼õ÷Ñ™7çïŸÊœFŸînŸT‡êO÷6ήpMëgW7a=_ëŽ1T^¶Õo&Œ¦ßÓÔ‡\œ"ÚË •×)-E.eÃîi¨¨Ý·ŸsÿS„/ ü†š(Aæø+ÇŠI*ÎÓüúÆjÚˆšµmiäXý…EŸç¤9q/¥%p¯ëç As=ÜÙ}Ú•;Qlir®©ù“ ÿw-db&Ñ = ¡.b¸ÝÀ¹P¿¤àÅЭÑ#m„ɲ]¶ÇeÕù-÷uÆÇ9—ydrwÙxm£ ]Ô(IÇéÓÂQ„V‹I/öVxÞж[óVmyc~|´‹ÎññF-]£ÇõF$ô{Ç•þò"‡‹Èu*'¥æ/Tw)þñ/ ‰_bbèø†èh³H‚y5(Ô23^K~xɱVÊ+˜H©·1›)¿h¤GP~,”é;¸0ÇPÝîDÀ³Ø2y(ï³³RTkÂì¢þ•KÒíÛ/ Ôkz2,ƒÄUHH,[¤÷žÆ—ù­gÜBþîÕLM*g,ØG‰³Vî«LµÎ¸NÆ›þÜþ$î¯Di$uôìØ‚´)# 1%}>Ò-2¸ßL1­ø¿²s5ûvTëð$‡.2XPPù8ú¹ãsµïõîrRÎÁõ„¡Ï¸¨›â•þI=¹“ NOCÕ4rʷ鯲›lYõéjÀ‹¯>T1w=/&6‹ü9ìæ·äŽui]¹%3ÁÐ.{~Sé…*5s›3:Ô„Ù“ü*·ÂÖ5pFÍšm*sÚ»°©’aÅ:kïÃõb–^4M"s2Ë®EÑ8Õh¿]œ·R´Ɇ¥ŠÚh6lXq¦!JpAW©!lx’YŒ¡›=’ÍÓtúñPJ—ép —Ý@ÿÁ$]C2R7qlnOÊ—*k”(Ú…V¯{­²ÏRw#XLÀ#btJ—Ç-N‰zØÞ)VMÐS“Æ£<^É™¯ŒuK ¥¤‘îdçÖMø³[×ÐÁ÷ÛÞóÞkSÙèðËÄÚÎÍÞÕßßLØUÄ Ô:L}× ¤å°6a@/æ{н6X6ÿ]„Ë1_µ8.·$ñúëý2h¤ñ³O:þÉããhIU½”²·–2 Ÿð3”1®.øºò"îf/’’u.3éªZšœ˜­9µÀµ˜…”Û±†mùlË—‡Ï³'´8/Éu×µF±‹gKŽ‚Ç;`†øç:í·úGj¹ÃÊH‡õi¤ö@É÷²ÇÖiFèÅžo:Ë… õXWzŒ†˜g =çÇ$¥6¸i\üh¸Ôè¢ë9ÃËñüwÑ¿nÊm#p¯=7Ö8wK +†‚˜!Y5ª¬h›Âø IŸsëâÏç ùÕu8᱇¶QøFt“M$Ž×Óå“y'ž‘qŽ²ñÐEW fáx:„˜û;W7·H þ”ãWŽª—g=p.Ä"®¯·4š©øZKGœòÍ£¾O‡¯ wŽù¦Ú&þ¼­ÓØb½êÇý3ËÌ@1"†r=qoÃEó”ä×™v0™ºpݳ³Ë„ƒ"´Å¡‚’¶Éà#’¨¡Ü‹BÕÝkñ:FñHí ç絬¦æÐì âyPÞÛúóÐn#Z\›É72L‹Šã°-*CÌÚº§´á—µ'摃ì“Ùðú”ø>mã fË©¤7i0?˜ûû/‘ªªÚÜAñ‡®¸»¤ß3¶îew´°éÜÐ fL9QqØ]P ×·²¿èýöФ¤5BéÂKÖÔ( ÿRÂM«bd¦ñbÏJ®¿Ü>å#cãv“¯Š1‰«¹Ñrjºé×M —U;hKË’ºDÐWRIÔ®@$š@ì<‘ÍA´¨ÄDú&„IU©¦"ŸöÐ9~D”eùÖÔ ôTê¬ãœé(¤Çn.”.kðÿ´ ¥®ogï=ƒþ½»þsuFÝÏåþ¢‹·cËáäÖ„þ²÷‡ôŒÃ¢§gÖ™EBdeìºf|íö˜ Œ³Zw4Vçvž&Ê=®ÝÂ¥H‡,d|LÀâ3N‹'¹²7,šsL„Ô]øm³ n-@ܤ¬N&…¬$ÿÈûÃõKÐt|]Øl‡¢óJ>h– +’9„©²Íºi=ÿ¨nuþò©­'h¾N«˜4Õ 7<±–¹ûIíÓö†÷Õ=Î)iÇN{À$dQñãTË0¿‡h¹KÝçµÙÚÒ9äóÌèÍï@¢ËG¢ $éðfKvHÀÑ:ÓÝ&îûAoà `žŽ“DGO?Ìd¨ö3ìŒ Â̪i¢ì'Y"-°ö-¸™¸O-õÂ5¾4¡Ã­š6rMŸ4Éì’‰üË¢¸U9F4Ò±SÑU-ÚÆ +¡à£"Ð,‘gÏKîD~^ººÓÜÉ/Zn\Æ$ÿM­Œù–1ÄŒ)Á×BoÅ£E[âcQóh¨X*úêÊÒO>0”ëw+ÇœðaÚ¨F~¶zñyþþ{ ‡gS(êá9‡&IdÑX2)Fžb¡8ÚËp¤‹PX,Gæ(xõš2œS`º faje‰ªh.,w¤á«7 +cLÇý2 Ža®_š²HÎh2+ƒZj@¥üAnÆÝܧúœt`;æßgŒõµzê×îòx¤áï¹Ñ%–ž{æVp¨XU‘Ãí`ß Üv«%¸‰ø×îDß=pNÞßà`å7—Ò‡Rtó ž5•C{ +L­ysŽ>!qÓ±ôm«¢É‰Èåîãéoª#ÙÎÐ^?ï8–y_å¨õOÇ€«j;‚U㌠+¸Kþ­Óp’¹«³>ú±ägWüD³É÷?æKåÖôm#|žZ¡£ ¢Ieí "b0G`½t¢n¢J¯q¨ÜÜPé¢G08mÜ8Ùªç µÝ¯Ýã¤ßRf§2e±;$D/Æ&.mÈ—(Ân¹\çU"S#Ð!=7±æ +’Š±à÷+ÐáËú­qJ®lHsIw¹eòª zDëÞªÔ• NÚšO%ÒçÕñr‰½¯=W¸Ë„TF%:uÀ䀙2º,~u‘\ıáýú”oC}xù‘Žq"4{‰ +@ûÅ#\t£¼ó¿º™/K®Ÿ±UgR¯H€d~È +a«Ç|…Á|e¿g½¯ }ð”uT©ûa3s+³Ì¥•¿½ã1KÇ×1¼tþ~¸O`Ë’tyQ[ýÈ—M!›ªo®J¿¦½Á'‚K›ð⊿Sî|ÿ˜û\WAƒ#‰Å9Žê2]2Z³lp‰Fûû–†ÜûO¯†O &¤ ÜDpªV¦8ï…ñ™÷óìº è™zgØùÝg¢‚5¹’-É}P«†öž/£y+¢rC*î‹#&ï]:x"v˜rNµ4¥‹|ÓWíJû`føZ1mü-msFYîÐ:8[Ž–?[¯+v~ôðá²› ó&pÀs–K‘v£y¨¤}Üšÿˆ÷[â01%¸.cœY‰]j˜ª:Ç¿ùö:Qqæ!åµ¾©ÏÁÈégƒ¡¾{£6jÊÑõ({ö;¯`ôô«î½A$äÆä¥=ÿ7<‰†ÐZLLSXëFŠ}Db62×,èÿv;=›#˜‡Ãc(íˆFrEƒÎUA7Á¾ºñ°¤‘ïμ Ÿ³ËØ 0 + ·‘—Vh/†¸MƒD:•ÄÇNñü°†•:#Þþ>PLÇÒwïÿQ5GbÄñ Òû¦ªð@` Ìz(iVþÉOëµ6 ‘–`.¿ô#°Ý;Uº-AnGûnxf³lTÆíØHºcÍõ7<²q3)‘‘Ç~*Ún¥ ÑB«R‹Ï+K¥È›!®)w™øÄ•™þîêñþœCåaIyƒÎ³<–äxŸs²)¬•¢×®8zÅJäó £n©ÌsÌ™æEHœX-z/è=!s_å™B?Êóíwö;µŒ›ô7M»Õöî‚Œ“˜:¨’PGKÐ'¨MÖí éżAJN{QbÆu:V7^Ð(*mké«s櫬é)7,"[›CÓXåºñªÌq…»¡„GÂmb(GXT€,ùÅbo©ðp²‰Ï÷ÖnròΡÕ`‡ü'íÌI êÁ¤Ë­,,ÿ7üëlþ\K +³ãÆ Y§u ïèœÙ+èï°9¤- ˆíRUöMxöOþúíú¡ÅsC¨3‚Džú›„àyEà·£¸q ›—Rôd}ŽO± æé[ÞÄ™G`c·§;[‰^L–çÎ(Ön^v轈î½—’‚IA?‡Zdߦx¶ë‡0Þê5/„·ï0iñUE°—,¿"7ZE"Y÷­à ŒçÂëáÂBG¾8˜¯§µ#êÂ^ êa¹bÙø´­b÷VîæלuHmzæî +P̪è¥Ôqõ D·Š@ÞDzˆ‹òuçöÿäüfN?ag>-šŒÊM©a7šµjª)Ð¥0c1å˜Åêž&¶Á0®ï¸‚«n9¯ÀMæW )õêP&°C˜Ù‹÷¥J@eôOqðȾÿçx˜¡ù3ÜÏú\åušà$å·=„þ’»:0¥äí ¬ {]Û7°PPÎþm1ˆ’=pËvÑ18Zµ±ˆÀºrG»%±6.«ßÌ¢8Î8П«woZKÉ9'çêí#úG—ïj²X+§ÃšP8†»Œݸ¼0J…®D“-ýf¸=_U0óA­ú¤‰Lÿé-àK‘ú¥Ïã&zŽ^Lqêm²ù›_º´~æ9ö$ |òÔ«*9k+ôûÒ—eL€<•Ëu¼É]ý v¨Œº_rœ!¬ß§Ìèèn"X[,#ѬR;Ry\³¥»VXÀƒ±AA+w +©õŠÊ»üyž+¾û™%’I†2£mÞá­¥\÷¤uçó:µš¥WbÕ‘¹éˆ×h'¢IµCŒºÛ ¯uJ*ÓÉ<¸S!ÙÖdNPÂD)­çcÅkø2æòò›9b«Ë#¸ö••v² û›T“Z#¿FýŒcÄ̦ë»Éz,³ý‹ù¦Š{ªÖœÿV¦(Z‰šavQÖK>T«:œcn +JÎtŒa½µ~öB¿çn 8b¦”W»VŽn$èÍñ)4Üê¤÷VûËÌŒ;µ•èN ‰R£ËÐŪ§ýÿ×>Y¶5( QD‰!%ÝHîfà¨Ñ9º‘n i’"]Ò-Ý1ºKÝݵ÷þ‡÷Û}îùçÃyžã•”4|œ"ïñ`Ûý]_€ßÿ¼Ý²í\£$«:ê¯{¶F†Æ»lìÏ3¢?ÑL$G@Öóå×vmôãŠ#Žª×°tή4ËFIñê\é±¹†òã–ÊcLÏBÙðn¶²e™i¤ÿs;<¶ ¼ÿñÏ7JŸ¨ie/þ5÷“FàEZUuç!í¯îðœJMþ•³ŽôÓ }Ëß–~¸ +Âòé€z{JE‰FªM Û„u–æG0i ž³ÍÀ†^µYkúzþ'ôÍòH¬n“È([ÒKFR}ÿ^÷ôdk +±5b$ßì}Cd%#vﱓ*š°ßÉ ‘ú°»­¥8hñÀÜ_Œ»Ð7¥U½2f +b›oÒm÷ãÅY…½jãnQŒ˜fýÊm½­ªm&*þ8”Èç1|ñ˜a¬~– F‘«•¢ûÎòXQ;( _ÆSI0ü+p˜ý&á¸$BF +ý1ì_v#ZâÍ,µgªìVØ +*‹š@i‰úû¿ž8ëäCî3luRŽn£ÒsbX‰É ýÚNã0Lb£?yrK—Søƒ=ÕˆáÜá@Æ žÀlþ ¦Ã<˜'•AÅ87gñU˜ +Üxäø›Š•XGŠyº'üá9vµ,Õ½OÓà¬KÏýØIC`­” ¿¸9Âò§é¸ˆ ßcZ”Âh.RÕŒ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’T EíûÐÖ[ï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!§ïÒƒŒ‘Pu aÛ›”Ë 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þj sßÑ8v> endobj +883 0 obj << +/Ascent 722 +/CapHeight 693 +/Descent -261 +/FontName /NHNDXP+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 884 0 R +>> endobj +2103 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 +790 0 obj << +/Length1 1630 +/Length2 15892 +/Length3 532 +/Length 16775 +/Filter /FlateDecode +>> +stream +xÚ¬¹cx¥]³-Ûv¯ØfǶm¯$+6:ìض“Žm;éØè°culãëç}ÏÞû\ûœ_çÛ¿Ö=kTªY£æ¼îûZ”¤ÊjŒ"æ¦@I{WFV&^€†ª–²‰­­‰9ÈAžQÕÁÎð×̉@I)æ 4q9Ø‹›¸yZ@s€8Ð ÀÆ`ýúõ+%@ÌÁÑËdiå + ùËAKOÏð_–\¦^ÿütYÚ¨þ>¸mí€ö®)þŸÕ€@€«`²Ä””ud¥4RŠ) =ÐÙÄ ìfj 2ȃ̀ö.@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ÿªžYSWMSG•þÿ¸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Ê +Ga1Ã8‘¯YÛ«Ÿãн>½l•ê!¾™Ç”œ±Rš¶?àW'‡Ù_NÄåƒÆY4!aÔ„ø‰¥– +/ÓLòFºVÕa¥¹òÞ+sTe˜1‘G·G]<ÖlI¯7E³±+’Ò=‚,Cš«OÒØor.¹kÕ /ÁÓŒ’ÍU±Hi~|ŒÖwÚkµqš‡~ƒ¸Ö£7ö³"ÄÇYæ…ÅO k_ã1fo4,ëIoböm5¹‹²O½k‚uÒ¥2ƒÞ¡úd‹j¨7W})“Þ‹¤ÐϾÑdT¥wÇ„{•ü¦ÒfËç«Ø™#K˜€Nƒh çuÏÏ%¢>ÞØXñÿàÛñÝ%rá§_&ωbksà£uÂÑj£«ÓEŸ +ö:çkØ¥»ãÆðòvÏ5ÅΰÂÜ0p!.ZÍ2§.•`Õé;ûòÒŸ¾´E 'ôòL‹~­'"Bδ •RÛ…ê뚀ÄÌË1ú€Þ‚`0ýzл»-õ®‰ÑÆöø$·«|Â9˜ ühˆô`´6GÞ£h‹º¢:"ÎÙ;¾M¯_­µJ%îo%ÒÌnck—ý'y¾‘ýαšm¡‹¦ƒ”õíÞ*{ iwQ[™¤kžç Ë tîF!cö8äÞŠNßãÇx´ ’Ü!Ä’¥¼Ö¢¦¥Š—Î~_ó©àH¶ýÛ±1%Š–±Ú¹ Ͼº¦á¢Õ>ÝMÐAŸdZ˜Ê51Ýb1ܤɬUð/ +‡ØRŠ#ÿ>w@ÿyXõCulŽ+Œ†ÌA馹°\¾ç­ÚÔ¢bjdT9äú¶’¥«×zbzÎK÷÷§©¿”fí*õ }æiEÔAž[ÙI ßý¹+¬C ƒœí4IX¹˜z²rw}ô‰öRj÷yÉX@È[ªiË fó„zyuôtT5åú4B›I—”ÉK0Ë>oIqÖÛoß™KØgv † -Š…â!^ÊÄ,õˆ¨òæ–áë,…â­X˜È(q"=Ã/šëø4ßß2ku¢Ã§oÈ\ɘPTø$á9¶#=¼.ª…ªI$¹ Å“‹Îšø©™ˆûz·Êp^‹T6ÞmyD¨g=_¤.Ó Ê—ÜÌOcVP‡¤.â³ù{:²|GÂT˜Žë¿·Bo¦w·øÐõï:j‘´åêÿ€Z uHT©—btcý½B.÷IØÒå~¨2Ò7*Qõ>;³2û ÃP“\³uŸ;k¦«Œ¥3b@òÑ©6­ZKî#C\òËT2ÜhŒµ`{ÕÅAîK岦G«³_ÄZ¥öc¤Ü>ÜÈÀâ¤k÷égq}2Ïþ=¬«E(Š¿'Ž + օݧ{ÌæßÖRáï›I“¬ïØÃ4†ºéd`ðe'¢ò›KþÈé•ëÀ0 xö¯´ØQ¤Î]åhÓJ;ZL½"7Ò–ñà|êTñÌãço2R°×%‚¬Xs­üòc–>`pȸÔ¢D…Üo½I[«4uÉG ‡äÇ]F?bo÷ ¦"1I[#– x%‡x‹¹žÆɬ²×Á>Эs*´Ïühd&Cîx3Ôà9‹œkMŒ™"SàÈÕÍŠL€''ƒ™C¦eòœÿ@ËÞÀ4:%½BÔ‡?Ö´OH6c{h¦5/çÕ +5’QÄ„Qƒœqó™0=l­\αç +¥×$á_~Т:ò›l +Û…úMÚ„m>ô‹'Á†ž§MýO³qÎCÄ]´5CXá*\•MN£dtWî +BJ!•l!~X‡’Õ É•aó’1Ë"/°E©ø!Jü÷™oó§KDMk§Èéw“F±§Ûˆ{¹g,˜6Q4²«lía¤WÈw©4q’7_úU0"¾B` Ï"ø?(±*ë2­³G€ ¡fÓêQXŽŠJ5úºîÚ ñ%èÐäíb¡Ê¡ÓYÉ_c¸p'vÿЮ/]·mÐøD‘ /³îwòŸÙ|&æ>¡®GSÜ° ¯d9{¶£IóJŠK÷9fã¢éŠ ©þäÁõ@ñ¼9xŒi,P¾*=cùüà‰µNm6O—^ E› ªÖž©ÁôЮº +M2tÉ»bqJCgª`AjI@vr]Ú@Ö *Ó ä½è¼‰_‰ä”/ú¼æ/ +¨á"R’´‰öÆ$ä ÚU W=ŽgY·'æýÕ ±M‘‚‡{}•ÜÿöA®ô5±ò½UKмÎf6ÞÎ'2¦g¯,5ƒŽh­óçü¨6à«ÈÇ +g!ò)#îLI•eÇO~,EbÛà ¢.ÈÁî=íõÙL(Bćơ=²a~¡Ž LÌjSȤk²5ž€ŸH½ºFŒ§WiWམXøwÖýï… \#A†%ñ³‘Ë2‘j Ç´½Û¡õ´„P2’åíC¶²‹’³o K,\QÛ²ÔŽ‹¼Ü3WÚ ‰SÁ™Û3èF#ëšlËñ°ÁºÌ¬§T{ô?êu5DZ—b!⺂Æn9Š#M‘y^Qi$ë\Êo#£ :“ÐÇÏq`{‹!ˆC%oÝË|°¢’N½`^¾VÄ:z´ßÂØÚ˜Å,Žž”\uyFÌOàø6ëÞÀ…?z†t+A×ÜéEî>VµÝ´çröt'ˇÅ<Ë9¶]ÄöýÞCðò—|fŒK¨ª£µ®ß( ­Â‹%SrÜ3ÀðYÙ%ŸTu3×dhtéõn&ƒà)pMþ¬'Ö]ÛPB4ÿA÷ÃID€à·GPDŠ¸U\%%2à!¬ÂúKÄÖ£Ée”Ø“ê6,Ù:'Û((í,ïÌ»DÜBó¦úƒˆ®õI›™½a'=I˼\ùKrå.;_ ŠRP,¦èÜ J¥0Ÿ(„Ï ÂmÃ*¨ù}‹ZP¼>iI*ëz¦á-µŽdy áäQ‡~zò,!Ÿ«ËöHéqŠûˆ\óD#k4I6ðsÝö:ïBéã Îö'è$Ë/©ŸìöU]€’’ƒLWF: KEÑx.A?C;ù'CvãR§S=ËÀÝ•jX( “ûµÏ~&/H«¼‚‡6œÀ#Žz„˜»»Jýx0ëÖ0MÞu J£ Ä’¹)AË©GOûØ+VôývŸsÉŠJǾYNaú»È[sûË#…ù«YñÙ/%AœrºWó¾B¬ÕDTi;þä$wÐy.×oöiÉÕÙªne\½þ„1Xï§Áõˆ_°ˆÔ‹ i‰}]hœ‘DÉF•X8)RŒ(êe+QBöìøYýú$ø𙨗wš4ÉAÑåFç[/Ìï(=Š|ú11ǹÌYfFã–s»Ø'ú[þµwù|¼ŽÇÛ,ë¢39i¯æ¼Žõšm!¸«uEÖê†î .>Pr˜áËóOªbeå£/Ï”£à?cÛ^0ô²³Ë«Lâ9}IÍv#VSgzºŽÙÑ‘ðîàê)˜¶©£p.´ÊI*ðwgÚË&)ƒâ²oUÌäšH€+ßÞÉ¥al‘BéiWŽÎG^ç˜ÀØl8„¬~ÇH/«æ5Àc/ý +q,‘ô¡ÇúGåKco IÛ³ø©‚Ž Nv#j»£)Ÿ—“Ì·‘¶ý¤C±Œmm§ +ÄáÛì‡VJ@ÂyÜ4A“ß(9,”÷-mZË)é‹ò8ÕªÇ+“lvÕcÊž|:"Ú!ý XjñÕ,NÛO¤y|¯aëŸÚaƒ™zßÀæÚ:µfm¦M?3r»’~°OƒïäɈö…‡«Ê2´Xñ#L9¡!&ySzDØõvÿæIp o<Èk`Ð S“˜ó¬º=âp¬ Y1'&ŒDŸpªT„¥‡˜VôëÿD·Xø}ÓË%0“{ Üò<‡·Ë|¬ôùØ8¯¿¦‘‰ÿ¨Ý.‚hƒÍ¢Ij9ì¤AææÕþpƒjFÓ›¯ +ôhЗ$™-ëM š:ËpYÒRYýæQ®îCš¯pc[`÷ÜñYÎþ^b}oï¿-æ‡qTBäò÷ÎõÀ”¸x•½ªµÏÜ«i HL›´,H÷RQf.úYaáVx þ&ѼzkK.|×{ih—W¦ˆvJwÂmà@Ãt i» ß–ü¸Ç.ö• £ˆ¢&ExìÓªúp6î#_8?¥œÕ”#ȹFøØËò4xITëèŸU¤l&€rùÞc—ßÜ°ÕÝ«C°*¿÷›Ãq(E–ðŸ2㾿Gµ:Í>‘ùÎâ>ỹ†o÷S¨æ÷yoúšíUCôM-&7qD¥jüãR…ñKs30¿¾»eçψѦ[óÚâ/×ÓI–<÷ÉgÓAiÐfþÃ.|ùž÷F?—$àvGQyuº‡ÚwòÄ@ÕTˆ•MU‰ѵEf|ähÝÖ̘®8 äiÌ‘D=_ND¹½aŸˆ?Æ)þVELK‹ÎR—èp-´ÇhÆÓDºøZXFÛ!¹àºYû,£ùðŒtó×ìX·¿Ñ¬7$ Ž»¤©„,óYch÷Ç›#—s³™&úÞ Ä¯Ã4~Œ•5-ò~Çc½ëweAdð)9Æ’6Éò‘Ðo¿Ý¥Ä3'ÄjhD(ÅêÁëi¾­!ÕrßÙÃpp¹g¼pä¹&<¸$LÎ}’²OÏÆ1™3Ñi Ê®0®©Ü•.;Y£34wçP×äU%± ` 6=ñfÛ8ÅT…Gç+\TÔ³7½ú¿üš«²ò³k“eNµLXQt0‡îÀÕÒ:_‡YšÉéxOmY|AÀ×^ÙZY Ò|4’ø†â·à:Ê>²Å)ZaYñ7¬Ö›ÅìiYyG×ì—'R>PìÕÕ™ùòrÖ¹š°[}Vì Ãr1¨ £É¢iÔUi©D¯ lu2CR.’ÉQtUÌä¡8ÆÍm+½Dø"‚Tq_…„p/×Ù^$Àw,säÞÚÁ­Á„¬±Ð%çͧÇŠŒÚ·7Öaeýì³^›)ô,ˆò]tïéÍþ²IäúœH¨õ4öM‚…QˆŽ+¶”/ #lífä±³Ëb!^sKQ5UúL0tŒØ…=0ØæåkZŒÜ‚û°ðâ>õ™^éÐÍJD&kÅkL=úïˆãÔá?OdG’’Ž“" æ™·?à37Î[-‰ç¤˜ô6ÀŒi,ÌÃ#‰ Ä‘£2¦‚ìDM(ª­ÂbYäGGÑw²Î¤‡ ¾Ó€v|uËÛ³aŒþÖÝF>d’çJy½þTf'X3i2]JÞé‘N»P¹ SwE©º3‹Pfèáüq9èºñ#kñ|?öèØô"’ÙY0(Æf·%‹ µòÂÐÇÎs>SŸE¢ö&*Âßš ²mÌIy’&ϾxÇÜ€~™~V XxDÑ:ÏbŒÕ©ê¥Ä4ávü\è<‰BÕ„0ÙTÄQ)9BÙHq9ætñÊê`í86[vƒ¡×\ø‹×«/…'YqZX«ÇSüýŠja axäa° ¨'m6q¬§Ï¢óÌzÉODB<ïô{†Ð/ºa#²Ü ªÐ©¦õ‰ô& ПÏL%ýÒÏmØ’NMQ_æ]¤Êåà‡~–zÞóÙ8Ñ\ë W@¿íÜ®¹pá]±ú¶}”òŠTGjf&ÓâÉèÃúVìûÙÄÕaɆ’¨5n 'Å4E“Œ¤CàÌùVˆw¤Ów"ýúx{Ê*X2&~䯯QP.Ì×ðRÚ•{kccÐe˜7ñÀ:¸‡_Va%±©â5G+£\÷t(§@évx©Jø™îñví,·WG Û KbýœÉ¢ðj:lêò‚.Gwé"oœúäÆL¬5“íÜÕÊï0CCŒú¿OéSyÌ!¨Þö&ü/=MÔ‹m?Ú|;uÓPö¥Zž°j[¿ÄU ;=aµ¯a`®îÈß}\ßöœ¯ç·xÂÚHÒ¶E‚ IDQ¸¿çÍõ‡Y­¤)„t®=°^Ùd•†{ 媒Sΰ];S ]“[^&PÁÙAÔ›qcàÊÞækt5ñt +"q‚x”Ad€Äœˆ®wÒ4°ÈJÙ¼­Ì8ø¿Wöwm B\ëê ìáQïÞÌæºÙ2çŠ'=|J¸^Ö{~ %ÒffÞ2*„ÿ¹UU£î[œRnÖûÎ ç äà/︊»æÕµ±úøÖ[²@“¬½¡Í—5NCCOQ~Ù/N»ùÞq¾!ê ‚„ÙHÔÚä5Ôû3õíya÷UTE‡3BŒýóGN½Ü‡ÄlXþÔGõ“) Âå§aow;é5’-Vy3Å„§J%™èvsQ¾ó\¥Æ0wW˜jS4ÂÒlêWbØ9z%ò¶;,_*EéÃŒ¯ïw1wÙ=ò^D%IßïÿèÀ ‘´ÃΉ™ûÆk¸ß‰y(@ÞqH·DêÇÊQsfT+Û©Õ©s>ÁK@BªB¥¦¤¹já»AÙSg(c¯Ì^¹ŸˆˆÄ>Ò k]5¾`®³ŸFU÷ÚI4û†˜0–—ûcw~¸øTàëö÷Kìµ/ØÐS ^¶KÃðàø¶úN†.é*fQÃïÊÛ…¸SÚK>2 +«°;‡5Î9ø%ÏçL¿ôw_†hÝ¥‰’ 6°V… +^”ØD>#û|ïzïÔ>Œ_ƈP‰ÌäFY„“ðÉQ[ÜȾo £zsT¸8ŽZv?=ªÅHAÓB[LÒÒâvl.èÆí“ÚGÆv‹7"E‰†O¥Ojn(`²¯—½Wb°¡vs÷;îù+®{¿ÈýÀX°«§º½[ŽÓì1˜'½Û6ˆUÊYø“÷dÌe`3ºæç³¼6àHÅ©ÜÁ­ ¾ØÅú(n°ƒù‹"uY»¦·[F’¼3  J +ÓdŠ®ÂlÀZ(”ŸRO¹Œ»“69Û€Ìà†ûŽDQäìUJE5ý*rÍ@¥”Ê~2ÉèeS2N˜ôBÔéø½S[©P°öÐ}—Ìjùjª¨Ÿ´ôÛíýc‚I‰ží õëš(ñÍß>‰/ÜagªœÁáµãº¸›þƒàà出ÅÛó,TúG–-N­ê½Pó5ø¯­ 4hi!Öøß|tÄ:/tô—nx•²åÕüÇßC)7µd|%çC§/;üÿœ/zm’.ØD×ÿa•¸·†iýAæØÚPƒ1.<-¿å¯ö”¶Ð¢›ÉWVž@£ÄUGà†áûÔËÍÖ* +(§[$$Òè,ŠÕ%%yÔ »´Æ”V°ß{Ó(±3· Z„Ö= (0ÜHnƒ«%1œÍBz;¦ßŽÚsÌ9û=u›UÛþígàÑv±Ú9Ž{â’®0ÝùÙ7ý#÷í¡J ÐF¦pß.Ð4·HóRØ°hÀ+;™ëŠÿjHj´JìÛ}Œ¹Úã /x|fðÙµcs|“úúa SNwX¨ÁCWú±Î~\ƒ6›Ðpr;h±8R÷>by;yÛÍálÈ0#e©Ðu?¼¥tMÕ€ž^g¯ªòn$Nß_ävSìêõíX?áûL•†ä³s«¡¡÷ Wþ¤Rââ5G5ºŸ~–²@í—OöŒ¬vË1¤ Š@ ÈÅÎt·»·¾Ãþߺš£pÊjUˆÂØÙ©®¼ú€5ëïžþôè+ +ø%IÆãа¬"£H_|B +DÈôZ¨K~¡ºy±'§«š—˜Â2ZSŸÄ*_Žs°¬¿áüy­•4á’DˆìG„V!3ÆÓä.¦ŸõÒÀ~Yx²ÚQ3æ0ËÉ*À‚äêJÛnïPýúúx ëW11u‚:Ow aA” ^†’ÃÆ„fÚÒRW—Ø(˜¾àBß|d9™eŸÇì x¹|nzç¥üí’]áÍOúåð;={É—êž/Ý„x_ ?à^ÊÃxVòWû‚¼%uÅ ºs+§iTO˜²ýôˆí^êÓqFÆï;ëá[1IÑÇ@ÑIÍEÃÎXq{tUå½ÊZ$ÊÈ/.·Ë3¨-Î ï_ßa?›@ñÅPlTÁLþŒ?iy1s•ÂyK°€[å>su ñ-UXr§m;¨:ª•Kó£*gò¤Åú‰᪠Y&–Ì1Z°ÏÚ¬½ÙQ‘~r"¬JÅÌ`\Š}‰rí&–¡[@²¦Ú»Eû($:¥ºøeÖÌÈ|½C¾Ö(ß~™„¡0¹ª‘ÉË]ô¢/áÉÈÂÜmúüpxQ[kñPÝVÙE·T+†L|­¢D©¦hèGR †.QÎ^Ïs)P>¸õ”.y•y=Oª\î­Ê¹¥ÕȤèGµÓà8þp·—¢®*7”:^&-fVl®ª¬.è<€:T`c…’`'×+mi£HÄÁÏÊ™³9E”ÓNÄJù>ÉVŽu“”=ÜÓ‡“Äòq|1,¬évÅDÒžZä-û4X…»´üÒhÓ%…¥!1ÑÙ:ՠãz&çkÙ> GžŸsêEL¢yeiªlŒþ[Mà Ô({§>¨)âNäþXP¤¨¯owÜô¼.⯠Š–4ãÞEUmVÏ“bD‰;Yª¿TÂíG¹=6ä’-Œ¿Ç@^» ‡¹OSä™aä]Çeiˆ)Vª´û~†Î•¢‡¡j¹×¦Ð;ûvÓ~$ÂV”¸ÃeEÛE³.£2§|Õ_ƒ ‰€G­™uè‘1—ñ½‰æ—DV‡„+j +ö99'(ÜÛG(#?‚iÎä²qßÇɲZ®[ÛÂääßýIbËw‚Õi™£KÝQSûž)VøÒŸ6+Ηݓà Æ8,LýA娒¤ÈåàãÍP9?¬CÚ+|…ëÍÁ^óøúÒ¼²Í·rôjÅ6À¹Ž‹ßuæ +[(†ºÍ öt bÚ[·ö- +HÉU +’7ø“’ðüÅšŽ,<ëÀ¢ Ò½è ¥;KY±7¨n’7qÍþL3Œ8Œ@×SÿCŠtv‰jáY²Ž¶bb»¸iS +ÕL;&ÜÚ社Q²;»UjNN{)òèÈù¥@Ã:è0>nOG"ýya,.ÉàÙ zi™TÄë:q!$*nK\Â)÷.¬’í8>‹ –Éîu¾J~&Õ†»M[oȳ©žJ´2Ëxy˜3Ÿ‰“ýÖ.¿”©tü.ó–5”Ï8Až «Z¦´´òÏn‘Kœ'‘[àõ•úV‡54›»Ü,eW~o§5X9mó‹jœkÑ$'<àYœ@ªùA-G-_ÚmVó ` «ú„£ù”Ó¹×”Šó“$È»²™©CÕr1¹"ÄÃ$AŠíŽ)й¦?¤Í0HÝÅŸàcËÉ&kžm,¡¿j%‘z´Üt/DÅ2—ð£xD*íÒú`s1VKó߉wAwcuÇ$aD_Û*_? +.g4“Mâ'M¦ï(ŠMÑ|éÖˆð…õ²›ÓĘ#5Ç´=È•ò~u¦5Vê£R¯/®£­óHÄ®f§ŒŠN¿:¿lŒTmoú_ ˆ[O»1Â̤§ké&èIN†‹v@‹þH,€tŒt¦á>Õ'R¥•K.zgóJ˜ë(+Á5¯2ìkÚ Ý϶¨Â[ú3Änè^ þ^×ÌæQ¡T d`v+f<ñ'yжj~›q)ž\k,°ý”škQí—½`µ‰OÒ«cìÔ\,& šîJ +íiW‡ fÈ“$#Ò±"÷qHÀŠJ\èWxZ'dô•ÿŽç[œÀþ‰Rèyý©ƒäHñ'þŽŸr9Ø®cpøÝ…uÑ{cBíÙ‹Ü$Ÿâë ŽX +'î»ìØ•Ë#>¼ºê£Z*¶ ?fôÑ1sm%$¥ž +aþ2rž¯Y"`¿/Éü +E¢Ì®_Q²HL‰@Zá~fNS^ÿœí^®<+9;ÚyÜúMtéÔtßæN9ïJAñÀئ{½ùMÌJXQ—DÎ+vûÔÕ†|bs”F-Ë•§EJ òó8}]ÕzÙeRéÀd.Ly’ö|ÿDl>Åõ]Ãh­W[®!ûÄT‡‡ÞuýÝ!"ƒgúˆ.’FHD•‘õÝÖÚšgì$Ð6MNâjpx#2ì,y]®“ê™ _ŽwrÀ% Oqp¶,Ô†´}–úy.Ì0ØÖ³pßãOS*³ã‡ïwâE †ó0m‘¨ü…YiEµ ‹X‚EiyÂ’“ F/ɪô¶­‚´J´ž—‡@%aHøèÕ?7ôÝŽ¨Â'’J‡ˆ2LäÍÝDœŒŸh¸Ì¢±·,Žh¶è„CYö]Ñß´­úgmkôfÆ#ÔíÈä¡J¸Umßý¶ªæö1ãïÕâ•Æ»Å†-eQCÕsoŸ½Ø‰ Í™ªLlmwÓšÞ—Jš¶9¾!&5#é»~kÃÓ•±9wX§Mk‘ŠHg¥éÌÐ6ÓÂx̱Ùõr>%Cçñ#ñ“(ž¢Rm|™$×B\µÉ AvV7Áû¯…00À(ä1˵ÕÝÝK¦Ü¹Ù~éo»T9z˜~Yã{òÑ=Mq0ûJA «ø}/£1Äí«e—Ѧn/*ómF¿Äxù q¬äyJS*\€d­-†:¯Ø]yÜÔåTƒ‡¿øƒØE@ÍfvTü6íÁ2~lW=_xãSeþ<ùBÐÊÒm"¿‹g|£žŽ/>¡„ïn‡œ0'OK_5b«F¾ìؽ°`‚ýÔš´ú&¯Ï¸?`;ãõð æzâŠ×=k-"c ª)k¡@2×Ül SÕs'tÜ«f€p!Ó«‡¢¤H|ö‘¾×Á[ú 4ô‹ê9_¹ªÒSGUPâI%¸5– +¯ò\†¦ U¥ÙˆŠ G (Õc˜Ã +qQ)[‡ŸäW=Òлe~ÙŒB‘»ëó´#âý mω;y»Š%üŽ@D$zfªéA%OÕtØ9ø»«óu 6’RáÞŠxƒ„ï”…íãÄg“Aý; Ã^ËŸæ‹ÜlÏÀc¸_!. ¹À2ÇŒaj¸ Öl§i»fâ^Ù'µÓ<3`¡. `oØNÖ˜©4kÄ®+ÉϺþô.×Zá4ñk Ãi‚" ·æÃDÙ»úˆ›§7æ¹í„ Ó³WæÃW¹i±1àüS ë™ §yBžÖ'ö^2V“j7¶Åˆºi³õ _“¹5·pDÆâwŽK/h,WÐU›4Ä:Ó~¸\+HÂÜ­$”¸ÃˆC»…ŽMŽ­ù•e–â.¥pzÝ?$f‚Y¦ &º2>4ÿ~j‡}áW(í ˜‹·¢ÓÕŠ£‘(kC°JS!ÛšgjäÈ&Em½õDeÏQz›ñ„ûá^–öŽ‘ámªºú$‹ª/ù^T@n®XEò´i#9äšÅ0x»M›×õio‚qÆ;aà̓µ!( ~ÚÀz,˜;ß@å3=7ƒ8L‰¸²±=_òóÏr~“ì”{÷Þ5#©7ûôÄU”Y]ôÇÚØû“ÂV¤íb‰; —Ëæ¨Iæ—‘ª@àQâü)ý4"«Šöâv=<èy9ãÀ+q Q® ð>-ÕOÆ©®@A¤K® m²v$i0KƒÏÛg•m‡D•g<’o9iTÎ’cÕ&™Û¤2)¢'ap¸—È–7 E›§kw†ÚSçšò¶8&drM )I% +2:RÒ]š¡¸\•´²DÊ™º´^-;nðÇY~þ0Ÿ1Í»PÒø¤0«¬}¦“?f0­úÙq†cŒ¶[ú¾;¶96Ø/çCð¶ aF nð¦Å;gF—´þàøåÒçNŸ†UçæÆ»ÚÜŸúDíÌꇺÿįõi›nWƒ¤Å…ß ËY»³»¶v»:ûBXW9aÇá‘ïíYÞ·+Kþ%ýY&ÕûÌÚ3.û×ö€4‚0åe3Â_C¸{½n™rn*6Âܒįì–ž?d&Æ å3²Èp]Í"å™:jW"w…¤ýÈò›ù;Õ+†éY/¯RËB ? +P„ é*Ë~fûiöðÐÁ± y;§‹¸Ãà’ßÐpù<3A, +HG€BÊ!´q<6õûœp—-HM¶Ýu'¯ýôhË)&)|àÞšÙbÎÇU$¨™4ªC‹äCQW +Ûs'&ÞHË¥Á§õŒñ¾QNç—‰Ÿ8[/»'ÚýtÐMs¾Z!Å7ÃFjA¡;Pì;ÎÓ<Ø:ô‹hX[ÇñxWÓ·MéxWÕòћӼaç~ݯJürÎÇû®³`ù²ÏÉF™m¨1£áú§U, Å€ÎÌ÷;:ÖÇ9½èyÄÂ1žìPUºÝS‹QRUib3íWëA(W×â“ÙÅ€µ†„äõ6ú¡Q{I–àÆ/Š†#¿I¨ +RW¥Ï +Òd<—ñ*õ/^›žˆu“ ”Ö†´06f¾Dx>É3ÓÐ6 $cºŽ~{V +´.ÎlTÖ±ð`­çÐÖátžë¾±ÉŸÜÖR)z’ºª^ Å}bû»Îd7 +Á~‡+Ò«‡´¬©Bcá#šUQˆµ»ž2ßÓ5:a]C>+×­ 7ø×B +lwÏÍ ¤Á;e£“/~Å©ô6€bDPö€Àì5 ßhàdÓ'±1ãŽÔH®—äI¯Ãz£íFR… R꿧ù‰´Ôö~ZB‹µü|†šïs>vŽ(B¯)ˆä<µ¢+þ‰>wÓ*>‰v»P°ÈÒÕìn݇32B‰;¾}0ñ\d3í•©Þlýöu>Ø5¹¿ å'Všµ«7ŽìòÂn@ÐŒ_÷ u,c!Üy&iÏ6I¿ÓpǾ +I3qn»#q.¢+j¨lx¥šÏw$àmE8L/ëÄŸ4Æ‹ jìhz:¼‡“nÚé(åw‚ +i}ü8c©+V\‚ØH}Hȧ¿`$¾³O4Waˆ©þ«ùůµbâbõê¿Þ™þz[›aó¬^QÅç¿o¹59ô>Ÿ%{q‡óx§òêÕ/ ìŸ)¨1£7i-ɉ<ô–Îy×`áÌ~)/B,ÔŒÄ ’$¯üÈà‡Š} Ðqƒq\­¸Ôä9XÇÊ&Y Ä~ÛÙ?FÑ«âÖ7AhnzräÍç$"wÅ:XÞ#uq^ß>\xb1Ò»Ïtá6J•ßOõ;‹ŽÉ–a¨Ûß„f {âe# zP$ü®)И'´³ýyòÓûÕn&såÚd´‘ôòh0×Qš>™ÒsA”>2Ì„8¹º—£q}ªé·Lm¯‚Ódx¯N›GQðLÚþ‡Yô2V÷«½ 1±ÅµXè*ýõ ÷q¦69+ÛÞ¥Ÿá0ë8õ¯Ü§Xî´ÏÚæs>Þ¡v5js+¹¢ˆ´Qaïe÷|* û½*$!ÿ½ËI ̽n(9Jºd`t=:™bڃĞ€»¡môÅñNqÖr¾¶Ù¿LÌ¿öåÊ`T0ÐElbiâPŠélº¤Ã¨:îi…wZ’„A[ž–áÇõVm#Ù®©ÂãôCÐÉ/‰ïF6r¨.]ª^|\¤†ÕḔ ¦k)–:õקàX9LÈí¾)b[ôŸSÕG¯Ê"2ƱµJѸRMxÝ]ÙrÿÅ:K¥ÓS%œx&Á¥€¢[bÜlñ™]Œ ·ðØ&T¡Tœ(j!Í'^‰1ýž¸Žƒû7îIÕäÁzes P©.—6Lb"Ž£“k2áKøvxxo¾ô Î@èô*sJc†*¢Zr»“”€—l§^c‹ÓœÌ¤¥øÅú2ÉÒq™ÍŸ8Ð 3?9Fõ<}UíçUr\°V +æ¨5-lçÖwŠ?v¹Í“!‰P£C´é¹2üÇ6$í.ªM¬—¿òÔöž8ü¨=Cî<:6¤Ò*À8€Ëi¾‚’¬ˆ§eœxÁ7gSL¥]ü÷MÁl϶É_LÎ[¯>7‘~KÔC¿ bÖ¡ùMÙDSG„l,Ô±ÿ…ô4¨·ÕõvOój˜ývXÚ‹>N]'#èØÌ×!óþÇ7îð*xîG™õñÌþÀ!%aóЦ_èõ\{¸®qf__ÌjävU“j3ùêEo/ž4 16ìž-AXðIŸsþã¹ßZI‚–>ÛýNA¸­s´Kp‹²ê˜"ÏGx ™?þ³Kl\jß»¬“aÒۗ샜+€uÊtC—hÇîá• +¿n$rÝ XðD˜t ÎõÓ…”2§—n„sÞmOÆ„ ˆ;²ÃßshuåU9ñÖ&;y-sõP~K*ªÅz4rnp´}ª÷œõ)RB—+«å—>¢cI£Ž¹w× éhz€Ì\mm £MúHþ×<×|Ìï­&‰ Ÿw³s£Üë+\?VË´<=yò‹ØH»M'²ñÑ67Cøoí+A5x5½·x¯'_Ë +c!vÜ~óÓ4¶bIpµP]ãH^ŒúÀnkLßYßÙ„æÀ,•‰)tCœrÀ‘ Çi†Ï±m$hýÈn.ÿ¶»öO¿ªWÂ[–{OFChÓ'žWùÆ*6L‡1±’g^H]u Ââa3ð¸g@—TÕL_1@d7¾ùÁ“†µ‹Œ:…‘XF.ÿ§Òfb1\ÄñSÙ£Ö®TÁIS ÒŽã{9.´ v´ôPš_$ ƒºÃ™.T€Áj”¤RÚ.zàÂiXÎ^;-”ûkwå0HMKyÃûSc-‘tkâôk'a.*bí Û¶4ŠdÇ&ž*qÉŸX‡ÒÝÓä"c°4 *+9‚3£ +cáE¢Lg%ãŸïÁó§KíÚï©=ëg‡~Q)œu‘Še7@ô`­¥¡c˜„s2¬ìe/ï´Ã÷5ØI*·[ÔrHîD4;"«hntRÉ´c¬¥ŸýÝ„u å{ÿÁØ }hë …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 +endobj +791 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 40 +/LastChar 90 +/Widths 2104 0 R +/BaseFont /VZSVYR+URWPalladioL-Roma-Slant_167 +/FontDescriptor 789 0 R +>> endobj +789 0 obj << +/Ascent 715 +/CapHeight 680 +/Descent -282 +/FontName /VZSVYR+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 790 0 R +>> endobj +2104 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 +728 0 obj << +/Length1 862 +/Length2 1251 +/Length3 532 +/Length 1860 +/Filter /FlateDecode +>> +stream +xÚíUkTgnõJÀ+Å€€¸ +æ2%X4-wDP¤2$H20I0@¹,P ‚A…ÊE ÒJi½ ”‹ÁŠ‚§F„‚Ü4 +& X¹ê +ºè±KîþÚ³3æ}žç{¿gž÷;ç33ñð&8²‘ ØŠ ¤N®ÞA2É833'†ÄràqçÖÉÚ¸¼ë;Y·î¹0=ð"ç4sÇA;hš}„ àD(Vž#Ž-wUÊ£úìùõîéMþÒ'Æ©¦)fÏZ½Ë¥3i±†Ñ¿ß ÓÄßIË(žùÊ] ×d̸6p[žt]IÊŒßÛhìbÔöКûrs›•›ì£`ò õª‹#µí!|~®S^«47—Å>/‡B jr÷<‰ +ÿ®~çœ>#†øEõ©ƒOKëåÚÝõz î®»½N™/ +µÜ:4Ò(®’+³²Zîñ1~xܦ£ûöÞÒ‡ñ‚÷t ¾ýÊ3 —á9¿ÒÈhcÍ~eV”žÂDV)äqNkÏf¦gx¸yú}¡w¸9/)À=à™ZÝ÷¼âirfÇØ–„1_u2óxë‹Á «)Ѹ·6ýbW©_Š¡y$|±ÁÁf¦@Ó±üÌzSä´ß`ø]ØßÅ-LÎæFM¥žýÍôEÜà“ßm, +!üm94¡ÜÜ—=7âjp¢ŒûLé^g_]flB쵧%õ„DàPYR»rÍü ëÀÎCûîSŒÃ㲎„™xh躗Ë.Ûk'$Ô\—-”…ÌîЉМV*¦…­FÔ=2À5½[wì™üPûR×ÈÉ?ª)–’Öokö³ïOWûlzyàYC?÷£ÐèÎú©_†çÍVS¹Ëúä—pïç7J¿üñ·¡ÒÉðõùWoʯʉ΄։Öþ›E¶TÅÑ“Êk•×Ç$ 7ìÍe$å-ŠOÂé,¶ižï…ÔË*‹GUM=uó)ƒ¢…0订êcú<Êyê<^a?YYêOÿÔ{߯qT1ç„ãó_N’^'v?רk••ù2ªR¦¦K´Z_oõÈjrÔ“ÍYY2(Õk$ûš @šÝî~Ã{8sç—Úµ¬÷U$FÛéx7:á,?ÔyòÓæݯ¸ùOiD§È‡‹øÄuþ÷T«TêSFaô{ò€Š1b]aÚù_Ýv*S’ç#¶ä]k¬Øu ÙìÝò€vlÃlÓËD Õ7™U¦«‹ûJ*ƶábuÁÀ$ñö²×p}Â(5ñiQBCG¸ÇÀ\—$§!7!ÇM~9Šœù¸)ökµÑ)Ç÷D_uo€£ŒÚjnÿ=Õáh׺™;wáÔúBÙ˜‹jU´fŸîNç²QÝÖ…Zöî–[£!CŽWµ$Aü6ÍŸd‡š@Â!ß¼tÍ› ‰ˆINzÀxwÁv}ÃuÙF{I¾?>¬iÿ˜ú`v«ç íøT6Ý1¿é0S x}Î䇯£Ž¨Fü׆þÜ×¢¯ª«;rª³+Ù7ÖÅt®]šrZ9µqg{7áø®l÷GÌ}Ÿ3\NkôÏɵV'•Ç²;Bêmиƒ’ž˜l/^·`m`onç=òøàþßà¢vuC¨@h(î_<þuendstream +endobj +729 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2105 0 R +/FirstChar 13 +/LastChar 110 +/Widths 2106 0 R +/BaseFont /CWTQLU+CMSY10 +/FontDescriptor 727 0 R +>> endobj +727 0 obj << +/Ascent 750 +/CapHeight 683 +/Descent -194 +/FontName /CWTQLU+CMSY10 +/ItalicAngle -14.035 +/StemV 85 +/XHeight 431 +/FontBBox [-29 -960 1116 775] +/Flags 4 +/CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash) +/FontFile 728 0 R +>> endobj +2106 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 +2105 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 +725 0 obj << +/Length1 1616 +/Length2 25334 +/Length3 532 +/Length 26225 +/Filter /FlateDecode +>> +stream +xÚ¬ºc”¤]°%\]î²,Û¶mÛvuÙ¶mÛ¶m£ËU]¶í¯ß÷Î;ëÎüšo~äZωˆ³cGìsb­'3Iä•hŒí MDílhhé9*ŠjòÖÖÆvÒ4Šv6€¿f(!' ;[a'N€š‰1@ØÄÀÈ`ààà€"ÙÙ»;X˜™;ÈÿbPPQQÿ—埀¡ûzþît´0³þ}p1±¶³·1±uú ñ½QÉÄàdn0µ°6ÉÉkHÈŠÈÅdUb&¶&ÖygCk #€´…‘‰­£ ÀÔÎ`ý €‘­±Å?¥9ÒþÅpíMŒ,þn3q32±ÿÇE °7q°±ptüû °p˜9Ø:ýí“ÀÂÖÈÚÙøí¦vÿ²w°ûaó×÷LÞÎÑÉÑÈÁÂÞ ð7«¼°èðt27pú'·£Å_7ÀÎôo¤±‘ó?%ýëû ó×ëd`aëp2qsú'—¡ ÀØÂÑÞÚÀýoî¿`öÿÒpv´°5û/Ô3ckGÇ¿0±ÿéÎÕ ø_ª7°··vÿw·Ý¿Qÿ“ƒ…“£‰µ)-ãßœFNs›YØBÑýsT$lMí ôÿa7v¶ÿOŸ‹‰Ã¿ "ÿçÌPü%a`lgkí061…¢“µsú›@þ§2íÿ;‘ÿHüÿDàÿ'òþÿ÷¿kô¿\âÿ¿÷ù¿C‹:[[Ëؘü» ðŸ3 øgÈØþoÑ6Öîÿ§øÿ©fò$ÿ0N[!`köWzZúÿ0Z8ŠZ¸™Ë[8™L ¬ÿöé_»Š­±‰ƒµ…­É_=ÿm%€†žþ¿ù”Í-Œ¬lÿi<˸Llÿ;÷¿ýËœNMMB^TŠêŸ©ÿÆÉÿÕÞIÙÝþ/µÿQŠŒñÿ\üƒ"(hçð¤a`eÐ0²3ý½rŒ f&ïÿCÆþk-càä`áÐú[6=ÿÅÿÏ­tþŒˆ­‘ñ?§EÉÉÀÖøïûŸ†ÜFÎuý÷Îÿ-ú?×ÿu7#¨µßvF\A–i™éNuè¹#SÂZ} #Áö¥ÊE~5v½¾ia8*õ?jƒi›f8¿ÚÝ—Ïì?$)ÇúЬÉzSL®òq¼‰(ú ·H;Ù¨ètKaÓÏÕ¢<¯—¤w@5YéUw§uK>Àqg:™ ¯Ÿ)üˆ\ +üPˆŸìá|ŒRbQ»š€ê +ÏÎIOžŸÈ†ÆGG†{oÁú°©rb’p¹€Â’FúýÊÁæÓT©©jUmÛëÕb3ô]ÿ””s +Îl~^õ­H¹²çŸÈôÿbاÑÙ®ï岞ÒæNHÙ ™C ½‰h1R^iC«ÙÂ{»AùÖˆqwÛÁxyÒWcÁ·ÿ¡y÷'‡—ÁOéTñ´šŸ­wôêuòÓsPMTUËçýNÀ(5±†ÅÄ ö¶‘ÛMüc,‚¨×]EI[™Y… ¸îˆ0^ ÆMÏm}™× Ë 3ž@óÉ ª0öGƺ°>KÛyE‡“åÜTh6þÁØŸøÐJ¢w¢§æ_[c ³öB8xÕ¾Vk”Ô‚—I¯¿ä„÷gÞk‰òŒ+(}‘²Å+åýdä„P9Œ,U•äD¡&w("Z·´U¾D£|yÛ)Õ‚þ0ŽÖ)¹` Á6l¬NÒµ½žŒÍ&²˜ W WâãÆ[.¸N5ÈõëZS† +€gÍý¬ÌV” C†û3æèºnMp»-˜…Z‘˜æj¤¯gÜ\}–ʈ}—}ÍšP«¤{}ò#U/ÉXÑ…€¼ðk¬¾ëÜV­Ð<´eÁºµýt.<Á0œ7Íw©~‹A“1²Ù°¢%îßD?âÝjÑä¤[,È4ý© +ÔI™Èüíç‘,ª!Û^ó&I|ú,~C¼ð O¯JëŽs/)'UgL—æªöÛ'ŒŸKnõætÉËÁ!;ÙÜ\õýâÚõþ#ˆ%æÈMµB”j!ˆªÎŒ o¢†PU&ø’¿ß¹PÃ$Þ;Ž‘»w©*t!Šꌄ|Õj”1íw-¡LÕÙ—›ö‚ߎ…>ßË>#ÈQƒ›a"¦´Ú×5ù“97Ûô ,h˜Ú?ä°wïا*\Dxc(uè³?^NWù,±CVØñÁáŒÅú3ý XÎfM.êÈ4Æ$œFß©þsÂ&^ÎtI¼\nk2NÓrÅ[>K¿·ŽñtPã(–v°õø¸qËxm°T +š[_]ÓHÑZŸæ¶ÅaŸhj¨Â-.åÂÄi⩾ÌRLC°ñáÎÍ|Æcþ®#snu„Áïr‡1¥—‚uÔîwÚosàðFÉ =ÂÐÜ:ž:ÎUšelòéÕY󸚉ƒ+ŽÜ×$í¸‡„ýM·bƒI”Âïò´Úê`9åÃÄu1КBPbdÁ‰[OQWúŒªø Á Ðë+Ç~1˜ö»z'à£R74ņš’”&üg½†W E¦÷àÆ»¨¸ð«ÊŸÅ\> ½’Ц¾®ŠÝ‡Phoº×ŸÜÝfaÄJ5¦ ³¢¤úЈ2G¨jÁ›žª{ôï÷1ïñÎ?EËKgå+ž³µÃ|ú$$Í¡ÃûyÕ´p À~·X5 +Ïþu¿^ù5cÔÃ[î˜4mô–CÌb^Ûe m¦Ýìž88ç}gõi.Ó 6Û²¡{ÇÙº[·:±’‚~s¼r^®µ{×y"j¾À`UŠ2f5?+ún ¸ ¼â@œî׿…@“%5£shàî‚Œš¶{++¬#ÂЙH¼GH–T l™!Ñ+PH­ÞPË9­«·Ä[ZYIçi\eyr*–¨Ö{Gnðx*yçK ’„èD2JG«L¸Vä±èG6<… †Žçð9‡X¹;‹X‡ã$]Hñ8ÇR™¿}t%بêŸZ¥ +´êÄÐÓ +Þkvßèåà?`Hdò8Ÿáz„û%u•$õAºu™\›+Gr*|wݨWÔÐæ>zuÚÐÜHq…ȃŠ0?‰Ù“]¢¨=+ûfUˆb9TV¶54ç,Te5®ÅjÈzÃà͹ÿšôÖ§"´ø´[mIƒ¡®\úàâLˆ½áï]šæÊ}Ëu_:jÆPß +–€íÖ—ݯUÛˆ¢¿ß$»Zµg-SÃ]‚.(#º™‡`¿ Ât´Üæ 6¿mà¯ò™9M}§’ˆù'WÃÙð´£ÜNæÜ‚é§$# ÁIÀq¯¹™|rË­$Àq·Ô”ÒÿZ¸“…m9à ¬0ãÞqVËZžÔÉúD?Ç‹™ýCòö± )'êwîß4'–½”ÑŒèšóaºáÇìY_ ÷]×ÌmÝäÍv784"œT&؈0‹ öµ­’üÞ£ZŽ3£¾¥Æ#­Ä#©K¼VNªÅªË¼T­¶¸¼¬Ó¿ç 'æ>Ç丕\<¥¥º€w)¦0©þí’%¼bŸ¬ðómiM—†E¹Tƒï4•Z)‚NuÝ1CèÌó,$U˜¿–³,âù$Ù*䵜 JøÃò…Ÿ`¾Bd,O/Y2çÑ}ðÂg¹±ñˆ‰£¨,áW9ç·³ +ýl…;œë‚$#¥Rј'ûBYâSö JLj N·—“\ð“ë¨zå0y¥~Сª{úë#Òsa¢¸²ÆfÙà´ñéöªðc~ßâ} ]˜ V42lï +T ›+=Ý"N¸F{VwÜ«Ýê'O¼o3Mk¹‘)& Y)‘-ÍÇaÊgþÆ®“¬AmIÂùϺvUÐiÝZw,:ÃzáÌxƒ âöÌjT21î n¢å­ Ç-§ä>1Ó,Æ×ò¹`uC¼ƒc ·¦¦ßæö%E_GOä ¬ ºTs'\- ¼òé1ʈ-Ð!^eʧý7íñB9 - §Mâc9ߺ4ôn9IÀ삲£(ê‰`ì5±bú–ÝèxMò±8õ1é]ôÎc-LðÛDZv;8lA¼ó/Y“º«,•×¨öã}íøá{˜®à0˜ÅUVÉ+c`¾˜f×~§¨¾¦Aлw~”æ¿ógfL¶vÔí,ÿ Š +˜r ]w9jr‡šØ[O§ÎéåMÍÏÞ@Í?éÀ0ÕíµDJF„rFhS[ͺ.ÆŠz¤9dR’XL +fÎ$Ë\nÞq94e#q0r±MnJïù» 1ç5Gö>’JôFí¶ú•,„DZ”í:ïºÂ €…´i*Œ•²Êcé”À‡nIÊQ“:­PݤNíYSXœÜvu›Aò=„•îÙ®A«bÉÖAŠ¬ö<$X#ÄøœR}X&¢UÎÈK"4áÕö¶ÿPbe¼ÎŠÅ— +ª *Aº\Õ@^¿>V1Ö†ÑîçhµäÀɱ~°ìj-ýflâÉL8D¼ÈV©§p¤‡Ekc4²îþÝc=´BªÔ"–¹² + „›šíwp ‹ÚjOI­{4°ؘ…‹VxáOR¡®TÈGA ì³+ ®À©„”À3ã×ËbÀõøϬ¸»eéj .5ß?.4?‚w1¤ÉÙ,ðà_–yC Qöê¶9›«¾_¼­pJ-G¥™Ñx¨^ð5xŽ“L¼ðh¼D°A€'áO¶0„0²8t³˜¡hÀ~AÛ{ˆ&î)'`Gï^¦‰m ½\‹HBõoW"Þt.Äñ˜êò[Ê&G>¬šX>­|¶F‹ÿF9ÈG: +}ˆÀu‰‡FëOðѾÒ`g!ë˶’Si™Ûs„×dŒìΈ”’G‹ŒÒ÷¤úPXŸ‘ÊX*òp¾š£µô†;pšX ¯»Õ䄾ÐÐÅ·.ÊÆ™³õK· ó§r±çÌg<¢åûœs§0œRÁãýËdò3‹Lqø%$ØDë=+¶X—¥ˆÚHï´m%¾”+pÔg­2œÐSíÛ&ÛÆ’ú‡®–ø‘™ÔD”sƒVL?‘¯Ž +ˆ!Ýkk»†“×ÉÇ.¾á®ì6Ëq_6…áNÝ«—6™T¶Sµ–F¦›–‰0;4Kÿ½26aþ2+Ai};bŸÀ‰ŒIu)I£YÅï“y¨)õ‹—­VïEeõ–œ+e"ÑèËF ÏèwéV¹Õ> ^;"ZÀÌ}¯å®I„ +ÚŒW?ð9ÉšjgÄO¤¨Ê£%Oy-¨Ê¾ÆÃt­ŠÉ2¶”êy (6eÅF~!²×9ÞÕ=¨NdÔ_Èí]Þ[‰+£øþþ>»`.‡`ÔŠk™½¼CæêU¬ùôÃÅN²3Ë +Ú¬wî‘ê"¹¼|=’4v§Ù:¬)ÈÝ%¿Ÿë°yÔÅ)aÆÃ=Ax•qÊ8úçUûƒòM[iñÊŽBËE7ø·džŒ¿_SMé)7ç \=aY„2Ǹ,DôÝØÌ¿ðÿtöÒãž¿â K‚7Ö–ªëÏ«wV÷ž®a@¡ §¶¦Û£;4É™ÕÖYYøuzD×/e£*)£‘ò9fS$ 6úÀ÷ÒlE;ûrðã`Û¸ËCë*‰{•mÖƒºàÊ–Mx¥PJÇn7ß7Á±^m©Þ®;±ùM6ÂqN;Me.”·k–ü¸¿mF²jkÁÒ⥠êv„,Î8½Õ­Mþk´«Á5­ ÜªUô æ^NÁ&ºg3w‘²X4YeWn)•#~…¼qòõh¯jH¨Åö¤Tpû÷ؾö|]–öÎ…¸GxÖÀ´K<$LŠ+êT +ÔUñ`•5Þ +¶¾¨1&µwÉù|ì9UÛ39TQ÷䆹í| ¡Ã(=̨º; GLâ§6ÿãì¸Ì¡"¾Ž•w…B|(iïˆ'Å'º¬ú[7ô ¹r+£²*iÌÆä;¹E}—ûOþÊF\]¦l{YåAF=AD +»÷I¦aôIãÔ'§»ÞÄû✨œùZzñÌkåÌú9¡ÓŸ&G ‡Iiä¿–žÓîè½À¤Œêˆc­Òئ¼¹!·5â[$µúÙÌZÜ›˜@_q´öOAš +´afÓ´s!(ˆ)§é‡¸˜Š  Mí0Âß<_°7;3s]˜(ª¬Þ)JÁsTæû°€½F’§Ò“_íç#¹ÏïЉ¯"#(àÖ!È¢‹ù£áõDóòöÔfÆë"S§ÔtN'Þf~¥ê:#Ï¡Ú®“×5¬'9/ŠŲº©C;ÀÞºñ Ñ8 0×[ÐÎ"F‡LÃJ½†¸§Ì0Hx_Ò#—ä˜ L슷>72ŸÂa¦ЧÖÛ×w¬l’ö‚º>„ÕžU’v7“[ø×û†÷¡¯f}&å}µ @-rá™Õ +1«¬Ù]͊¼аŽÎžl_ø)J%r˜#sŽ-Àë÷­Ýà,Ó’µÿV¨ðyºoèLLe·rÝLû—‚ f{ûc†lî %Gä·Ú÷<{­ëk†¯¹­ey4X«Þ>¹×¢ìØÀª"¬‰åLóp å4I»{lî5QÞ9ãÃôId3–Ò_`gbת}û +rÂWf¯(¾ Ê.Tsûœ$rG~‡ÌR)G…-ú²O2cl?ÂBüX CÇäd"iXćÏà÷ÈÏ:ŽDN?’OÁLf4ÍÔ ©é9÷°Ó?—P5Â+ ¼þÒ† yÓôÔ#ß3-­Ò.\±´ù¥„• çÄŽV¿¸:…ŸÏj¥×ÎÛ|M¿Ÿ®'Š©iÕἨ;¹‹*ƒúŠðºG£o´×ã®æ¬Ñ@z-Ã=å÷îÛƒîØ_¯.1êeEV'†–¤þ%@X`5ª¦ÔeÎ*‡kúÌa¾heäY„‚šaÛ<-î‘^]üiˆã–ºZË'ºÿEeŽÃïõ§]Ã3¤¬„0¥`ñÊ“êí~¹/^C«ÿÊZ¸Ödá·›¹±å¤@§ùÅßQ4Ìo@÷4‡wÜ-5꓉êÁGÚSŽÛËÏnj¬ß" gNïTåå48‡Zõ¶YQªéø-0¯ÏCÒþØ´EI%±ÀÄ,ueíËÚ 8–ÇþÓW¥ÂÔr×!KšÂÎèü`‡ž„Õà@l®/«Øþæ.z”ÈÙä+ö…m\0 ‹¾¾„,qÚd~ï#ç7K{êºýÂI_r(®¬µ׉ÒõN/ˆÏñó÷¦ÙèbDßÑÑ#…iâ·d‡W¸ˆ½÷2šЛ­ðƒ‹_e ". (ø§ãÙ”'§ÉDØd (F¸Úù¶|‘³e¾Q6 j1‰jߢÂü®ºÛ2SRßè²+6\Ž¹FÝ‘ZüýuMb±*eR^ÞzWjSC¹0r”2â²]òÃ5|ô¹Ñ^òI€Õ+`쫆‹ÐtúIÚÙô©Úòó¬ƒ î +ä¶Ôñ{mƸM¯ýœîdßËæ6Ú´Qµœ +‹¬)Ì Ÿž6Ö=jÖdÃ;í¡Ô¶„µ¼n:_>;y""¸ü,߸藵’ðȲd Ëd¨Q TÇëìÙÚÏÜ­•ïØ`.ø|Mõíº$õ´#É*šö7 ´¢Z•—Ã^SúëVa=žBžk#UõuƒKVQVQJÕÞL§Q¶Å¡ïºÜöÞÖøMØ¥b]k®Ûý7>ݳd«,B?.ÿ@uÏD®3uçæM ‰0).WòòÉÈhW' Vws˜‡×ˆ¢ƒ•\ +=;3؇ZÑíx§fÇu1{©‚qnˆé%Ñ)(Û+Ë*jóºpd±NãÎH¶›áóú E‹´Ø*ë_ªŒ®MuL¡Q°­èlq±ô¦‡³ý4ýCÂ4Š +õgðeµ™ ýÙabÎbg›iÏRZkaPC+ˆrÖƒŒF&õ*4¥vè°½4ü`o²O¹Û•{6oŽ;ǧ5M²*ËË»mýæAd/œvH&TvןŠ•×èë§fè"W"Ô ˜_©§D´ß-ê{IU#\Ôw€18_1mGwÃI&Ùj™6j%µΑ4»o»R.*Z¼Ê…jº…i7“—n+2{'oœnó„É^*½mp`6id¢ýU•DoPþO z¯@@W7Q!˜ã¯º| —qu ËNƒò,ÖÆ8þÉòê’xÅ“œ-LÂæ“š¤Ö,Q‘ݾŠY]ò:ú©s¸÷8UsÞ ð„Œ)ü<²oD¹B2 +Q9ÁïÕ@[E£©ë|å»Þ¡–åq¡¢ pȫУá'¨h æl¥ËˆxKw,Š–Z=S÷z ë‹TgÔèŸ)¸ yXɶÚj"С~Ù·©y¾Wjǵ­ +)˜Y?þÄô‰H;§#ËaY‹zv,„krÇ)Æ-¼›è™«Ÿg\VÆAÜ®ô ×f-²”x éH9ØM±·‘úÕ¿)ÇDEðHÅ#Àë-WΈbe8Ôç˜y•ÛaÈÓ¶#„ŠB€s¨Ô[¿Ñ¬å=%*žÞ$ŠÞµmu|6$)!¨z°ŸøǸô†áîÊMÌ]Ê„hf⃕ðH! +Z_!ÎØÏ™P°‚ž§TÙ s§ÌÛ ˆo{V®!(H”4o|ؤvIÒ†¹./ÔPÒùä³L6ŠH±ÞNÛ¯9s=N­ âkûrë¡¡ #Ž™.|eìÀ‡Ú½ìðâ+}(|ô’‹Ñ<w–ãÇûpÌ'ä çEFeÆZeý‰¶{ÌÌŠZâ;•–½D±Õ½v)<Ô3ÿ./|\×øÁ¨b÷ïWSDh~2vLñÛ¥“¤KE'LúlŸvQiuRî–±Å+{J¼Q*P­/QÁÓ÷“M¶äÂh$ÞE?&•é—ŽåaX&’@7?“Ÿ¢£DsüÛ™µ×Ìò"²"3]CxÏ}Þ“|mï/ÏC¼ãÜÔAÕ5ÙÐLÚ;î ¨ÅGX¾çE˜Ç¸–SÈŒáÄäóþ©Ò"eÌ/(qxBšp+²zGJÏð/ð^3£¦¯DüÆÕqŸfk)KÏpHóÚ¥÷$tÏ–9%7³2ÜAP ï¡~+)@°‰Tù©Ža™p¢ °µWƒV'Æv+ÀW¦_|\1gýÕ›ÿä°Wˆ–FAXq‚¬cà×¼²)sø¿íFã»)Q~žéüÈ Û°¯Cë5Ýp }PqfEÓ3zÎâºî#˜Ý€†.„¢-o ¿t61ßÔúªONkØݧ”¦ãWå'Šéi›Î¥lvê”ô÷ÞÕ8R¼Ù[M\šÅ2‡çà +O>´?ˆw]°÷¨Ãæ'²€n]*¼½ZX6ÏvJgv’‚¶Á =£;–ðO ½‘*-ŸâÝx>G( †Væ3ÀamÔ­{b|¥ %D~!Ù;'½Xï×>Å{2\ôsA¢›åÖOUiCYxm]¦ý,+“+ÎLïûôcK”¿´ãOn¶Ó†2pÖh¿EßµWê¼Ý†a#’Á°ImǨÐ5<,”ç'—ÇI$º¬ªêßbŒ>"1^ÓZ-âáÛÝ-ƺ%·£¹¤“—Í¥’IÙ ÕÛzbÑéš}¶~Ä©âLÄ6 ãaÕÁqðP2´6GðâPx,ro½sayjñ¥\Mó8Ë49öÑ~q|¾^þZ:@MSAÜÓÕ}$\æý¸ú† +ÔSßõ}FÆúcþ„"Ã\|¯*)ÕI ÓÔ–,õ†˜¥I" +n½ü.ñø*ì AÆtþØãR‰øæåUçÙ +KùMg”m{·Hn-dðƒ­ +'´ ‡úÃi©šTâ¦a4ÛÀór4C{$ÐI™}ø¢Ù>a‘Z(žxSomgìY/àOêÛ–·Go<Ü;œö£~NCbŸPT{ŸíþBÎÞ×pR½P¤ä¹ÃV‹»MÿpžíÜ*¨‚]”Yè=¡zéêÛCœ£LŸ3t7_>&IZoômG‘f~•¤Ôóþ{àMßq;:Š»Åu ¦€©ÓZOk˜ˆ<´XmümŸãT`»u6J+kŽ¦‡+Ö3ê~ªdô›™Ò]þAO†ðq†Â…“”ÈH®è$#c*ÿ1^ïÉ’^‹ÍR¹aéc‚ç'JžÂF°úÝŽH18LVÙë`¨çòö«;nQRGí\vß]"zÊ°¼~Ë *¬‰@ÔàÀ°··¹Kâ•ÂëÐÎF>:W®Þ¾eÎA°îÁ¯ñ6\¶ÍEäO5ÏOéÄšKÒÉ›b$ÆLñ™Z +ª`Ί‹šXN”ÀU?Ž¢®ºëÈ5ËXrB0n9½âà!§æ®»u*PSçoiyµÚÒLNöolU®/'²ºNl¾+ +z·ô̇oŠ%ž}Áwiô[ªÙ׶K¸pWâ^­níåÛiíèf.\«™CÐ f¤: l©N}Vâk¿3 Ê[‹æ+>C²W97û&Î_lûnú6±pÎÈè?9+Ì^?…ö z×û±·ÝIÉ*ð¸ãEu…nÄsA´Ç×ñ^dŒ–kC2^FvBñ§ Ó¬Yƒ¸†|óIÔµ%y$¥Í•Èƒ’¬¿BPÞƒúuÓ?fÒrJZÔø¯e¢ú +WL©,ãõ®<ò ¼z8ØAÚBeåŽýAf!Òç.P£MX“mtŠž¼ßZ‰^`«-Þè|‘ ª<:´N†„¥,ûP£—ærÌö)ìÆFSuê‘Ù-Qà‘×® +õó"KŒŸIF€¥%(³–_@k°„ +j-éù•_"R§‡7D.àúœµÁK`RŠcàÅRÓ¶µËê‘V¡€Â‚¾±Ð ‡‰ŸV':–ðê$íôÃDgènº¾Í·ìM‡k/‡&ŽNYúÞVÆ3‚tӾݭæ;["Û‰`Ëk•¬‡~bŒók-<ÓLÄHsH‡X®¡Ê%¨};É„ÞÌ“Äo·ç™HV²[]û:ûýã÷ön±Út‹©¯¼€ x-0å­ ¤ò3(×|–¤á#¸Úª$xœ£“µ[=~©øwBˆ¢ÞЦîx´-«’Â@iaéLßü` la"qÞÈ çïÃ+®(XÿµgˆTäq·¼O$:ʃú^ÐØwàÇ7Å棣t4i–êk3´A·‰púTœ« 檾{<\-ÚHœžÜ›Ðð_%{žjoÉe«=’»sþ)¢ñô0Ùšª:Êò7çVÀ×RÄpi´Z=<=z…\Ë!õ4$ed銛Kju~’á, §Å.?&‰@\ š¾_x6ÝÍä­[<v0$å#‹EԪѦ*=6Á?0KJŽ†«êé†à9ñ‡:‚£´°Ou¹zÖ˜öèè+I‘ž~™DØ8þY %èàt:eòñ$ÃlÁ)ls®€ Ž¶;;˜‚Q²‚;3Ùöµ1`˜çÑ.*dýý€%ÚcªÏÓSeË€ƒæô¢òœÀœ„PÚÜ ½mÎF|P™îi¡ñµGwÐáÙQQ¯9µlôœfûü­"8›»´áb…ùv9Ï2{s’¡HË8!¹<°ðwô¨3¬¶hÛ¸£nvâàßÒj}-Ÿ »b` s«¾o×,Å—ˆ2í? +–qÇÙ¶â(ŽÇwû',»_eßùÈvôÕÝU]wùd}ðy0=˜$IyO›ÍÈ€œ=»U9e~5ÉŒœ¼uo{´Ñä¬nEhÕkPía˺OoÑQ2úˆ9Ôì&\`}ÕGÈÔ³ktð´bÖ¬5‰\5 °ÀÃbC“ +8×Ù¾]“’h·À¯6æâYn%«çŒò2Ã>¾õúŒP?$8uŽÁp+F + ™ðˆfd;®"¤¹dA¾£B·KµAPùsF_óuª†. áŠD*Aü¨ÊiðÔ•Çð—3+¥]ª„kyÕ£dfÕp¥ß†ÜŒ&è tÝøgXÕ€Š¢ ãŸ6MªE×ôR¦™–/œÅOtÞÖôÝýÙbE€(àºè±GÑ@…¸A¦½¹ûÆŽJÉìÁÚ ˜‘êæ§p„¼a¦ÎïbH—@$ÕflÕ?îTù×7íÛ|¯œ1¿T({i•ò¡Òj[T b>J°ÿ܃>Ž.èh‹æ +v¡=å ze׶)ö\à˜¯y€Š|É) Àµêú<`I@Nw¦éŠHræ­Ôóºƒuy.)ø·Û‰Ýê‚í\üèG®øÜè 8tÏ»ôanퟒJRo╨,ëE…cc!U!ž¤ºõN±“¤×[zçQ¤QC"5ä ã‚Ê|7ù9s0˜L½I½\ðî §¼õq·aø‹_®sÅ$Ö꩜Ė]dyé=t°P‚Ö¦—3YoÝçÒ2Ëp•ç]Lò2†ÎïOñfÊäNªQJUfî‰8¶÷$ý›°‰¯öOv¢8ÉæòLvViÊZã¬à¥Wf¥2# =ÛiïXs»&ÇjšœhèL¡2ïŽ9Ä! Pé\L mØ:É<¥Æ‘Ä“$ó?jÂùTA>—1Ûƒçtu„³°0w|h¾6bzÀ¿–ÙɸâœV©<Á,Z"X¼×e3„RÄrç*ÌLå¿¡höç~uÊQw³[K,…^ÃâÏ ð{Ç©¸<_=ë í8B³–·Åc¨z,êF½g-¦UÎ’Û3tl¿tÜ\º­æÖMžIWiª­XSsZ"³`«nÍ[ýá#ì~FÓ°RJMFÖÅZÿÃxåAÖT< K%ž/ÚÙ‰#Ê(¢µÑôzâHT†‘^h•#PZ‘i}1Œä=û}Jn gI¦ãá]Ûìd°?÷M{;þ"*ž‡‹w1EòË|øz•ÐØÿ¡Èÿ.²·CdÛƒ+Ž>ìuÒ,låj±ô@x÷¬,’óržI&vË`XÓRz“GkOš( +<”â׭Ҫܹçò3¼+çÓ2> $´‰G£éœ'¹’Ž¼ˆÔ +ªwQå\T1‡`ï–*!7Ñb¬§¤ƒÌ%©©Â+¨÷|¸M·äv×·vã„z²Žç§ñN4És÷ôq€ÔüY ÐW8­-²¼ +!STlÕȇ=f¿lOtÀGF­FTØÌ]¾Žr»j€¨7mÞ±Ï[Üû)ѢÈõ|ÿ`yzŠöÒé±<‡‡a^!½Ì=UÆø×ÈÂúa¤Î†¯=Æ%L€®"¿ý%âwQ˜H_éwõ#"ÜH„-»Ö0PõºÞ¥@°lÛt´+Ã=¼~•¬Z>ñ~)E‚®8¿’…@ Å²!tiv6diü•â¨n© J@u˜$íoá}ÝÉ–i3Áñ§EÊ®äK„o«9 ‘9Px¶:lrÔpÊÕ²²`¸uÓ/µo­î’h±†™º¤Õá¤Üôƒa30 ?GÝf× k!{h¢Ræ×;ì]OËÄ(«‹ž<üÓÎÃijW$Ä,= B‘Å)HS†b@‚ÕIw´«–¨;¬Ùlͨn³]]CþÃzÃÅH4¯9¦d˜«çï¡~¬ˆÊ \ES ·Â>VjPÈ7³ßtë™LËYýUå€(ÉxpЋØÁß`›¿ÃTdߢ}éøO Éñ¬1°y°‰¼wx;l¦"–SH{ïÚË“°ØéÆÛ'µ‚ ‰œõO +‘xÑ6@·î“ü <SË~m!¾áº™Àƒøu’°ag¥Þ¼ÃæÚ ñŠw­“ë•Î2z­B•CÜ.7 `˜Uy̨²Bzx’qê/›ä?º—d¾¨¢ ѧcŠA×<38æª"<ž ‚õÆ—½!A.Á& ­¼ém³y%U6L_éµµ'¶TŸ€^Òšè¯`3k‘«åìpÕŽ)r™ôž(ªêýx:Ú‰•'‹µ?.×Uô1n mÏKÆúC³ÆË¥‡Hörºðµ’h† ;$•úÆ6 û}TOVè—뀘¦†ÑÑœ‘¤rµ¬ÁÇJÈ–÷©¯+®…"|a ‡‚΃Éê°ùd@œgø²ú@0ÂRü+1Ï©tÓOÊ|ò—\¦»'© ­í|çì7=áü÷8þEËžsmRà…‡[T{ â›ÌHƒ–°±F‘ç3Ôù½&åó?e1OAh¹¿æTÛ*&MׄR’íUVJÖUüB’c_8ܽ›ÌËï¿žÚzÍS}XâË´] Nâ®@"ÂÈì·ŸPoêj"~])HIÿs#õ²½]Â1í¬à2ù)ˆÓFvL|]-Aøè›\™ÈÐ/KÊ +;i÷¤ð =¨?³F‰%dr,¯Ô=wxŽ$Ì„½‹eÐQ˜ } èax>,¢RÔ÷ÕüMoÖ+&Dù ={ùfs9 µ¨<|ó\¡Ð’0së·§!Æì¡K^j1®!çóã7ƒÂF!2ùš/ÞQ ýW…!dHc±g±Ä{«£Pa,†S™"GÂd¯Íçe䶬ÍöáÇþ°ËV¼Èˆ€CaDÜøçf:*ºXþÉÁŽ)2Å·áV׫ÂPHLVz륚íä«Ÿ96? Í2åÈÕZrÍ­Í »È»Tn¢"Öhd T3‡½:¬&™t0M ;Éà¡?„R„ùHÌ÷ŽlߪeÌ—cN^Žaî[¦|©"ÏP%]Éúí9F{ ,R˜,wÃy'kÊ?Ázï×J#ů§¼¶7èÑf[ØÖ¸Ü8m>é,Õ£ñgsöèîǼ–Ÿ >¢’mƒ»šz¶‡–œµýdïŽf[¹öEódd@â?õ–ûn±áH¬‘YÄ.·äÈ"R½¨³® ®c41V8;MmàZË¢ò·ÝHu0”`QMĦ‹Â‘.;¢¯|í/âcbÇóŽ—GÛR>BŒÛb}7krê«À¡꓃ BÓwè‰)YXP›Ålè•1«€KDà©)ÎýâÌ2~eœM=¤®%Õ3– Cu^yQ ä7ô£¿˜ e*²»ž¬js»¯ù‘1'¡Û~POœÓü T™æ·UFaØ­ŸsA?Áè¼³Þïê/Ã×›Ý/ˆ' xû:ï+#™>ãàiýƒžþˆ¶ âh1CJi•ÅĨ 0+íˆ ªä›Ò¼fÓjæ®3„":b^¿’ž¾>œ ÒGßzHűI ŠÍ2‚W<—ø­î±aj4Dµ“ 5«\6†3Ÿ‚ c½Fbá¯8çÒIzTp…!‡ˆ­W@Ö…•Le2ˆm¿MߨC8Žžç¾|à̤ÞBÂîÞÄx˜1=WUTw.ÒB²è¾Ôç+Sïj©zx¡Ê-iSŒÌ¥ŠvÔ¼+ù$zÁÏ™FK0&}–ã㪼¬Y‡~9M+Ã¥SÐ%Ì.äÛ¼­=éšâÒá™>uMÎWÐ_Jú±Å("3²8Bwú÷7Ôm´pJ°B4¥”Nƒk[‰urÙÍù¤†sH÷Ö°aÍúFŒÆ]bføÓy<;X†4Ò²RÖ:’êa“‘qXL¢e9G膥`ÓC®%…›ëTÕ“PnòDXup­<§Û­Èž¤ODZ‹ø5­¦/»#øí>¹Ý¨€º ~'–®y×âSï2ˆÊ²„´` l—Ú-|Us¡o(ШUó4¶ƒ¼&‘níüÅçcè¯7Lçdk~Üæî…MTx€iÊL1ĺŠœŽõ‰4Ábͯ†Á¬R=ÐFÿ‡ hC(íú6IÙÇ0”¬ aúÊBJiÞþv£¬zh7ùp¢wÉ×é–WŠ|WXva,qkOæê¸ü¢AÂLR¿i9ßv«!Uno¿¾Ó7…­EýØé2CGÊHß soo¹°®âîç´ÃÓ.·ü‰XÝ[ä +sŽ[ò¯ÆºŽÏ ZªT˜Fu醭aw;ôfI´ª|fÜÚâñ‚ÑîB5ç:ô›C]Åt)´¨ [³')Öá(Ö²Xý” ©A8çŒFŠƒ9'™ûkóm Áh%žºË!]Çqf°pPŠpÛh T€[LœPv?çM4™£nÓMZw ×Ð]ÚUå)nÆ<DíÃÐ0ŸJç!pº­µB‡#_JÔ&bƒfç×M2ÇjH@§ùåAßÄt +Ópd½Ô[`çCDîãY`=O¨ã<IÅÿò‹I‡ªF< óPZä„N|£Ñkÿh!Jž¾”Ú§x¼¬ÃÇ`3´üµj¥mÛ*õ·ÒÝ“$Á³a†£òÑ*ààw¥+}ü[=5êÔ;ºžiþÜÉzÇS^ dSuœÏóÿüÿ,.Ä2lsŽ¸@î³ñÀH²Ç¦¸c;däýHŽˆEpcæ2®ªÉ'ýœ²( HñíÀfº6¢~ãÍè’6yÏØlêÖ¿Œ·ð‘®ª_0°—j†BƒLgxN†N¼¸4tãr&ð$Òá“×⳦\׬#RdBÚsdz/¬Ôü(Lš]ÓÄ>ºís~þ”êýÆ ›¦£€Ó‘(?¾lˆ$Æ_L¯þN_‘çSQìÎ8µG–æoWåŸw<þÞÅ`2(n4~i-ºª©[íòU®Ü€GO ‚6 }€ÞÓŠáºý rU«"K£;Ûðž_csû¸W–àTÕm wÅ›ð®Û>üì‘\£þ‡¯ïútàùëÏAW*‘˜ SôÛoba£¾u‚Ѥ5÷„®Ç.¶ï(>KK? 9àR©â‚?¿$cHp‹ëʳ&¾4(b£R\uÖ¿íØ×ÿÅ`Tf`lqñ¿è•¶‡Þ¬ Ê®£JñŸ9W¥3}ZV~ý¡’„¶ßt°üèR=>ëYmâ…lÊü“«Ám”’)é²Ó³ÏZ¨B©}šè&­ +Á¸ç‡ÂúIo>¢ž Y†¬ƒ;¢+A²neçΚ[czýMµm/p5@?¶~t€pð’ºF°‹[Ç + }W—ÔÖ¤í®dÏê3Æ­­Ò‡¿$ºÕVP› øÅVc%3¥@¡íä&žH˜.ÀýÁ6vÀáõ£…z…BqÛNÉš›2•TûD:½õ®àxü\Æ/(tùDѦ$C‹%Ð}B–ÌCÀèçQÅÞ §ŠµHËÅL9Ú~[[f︙¼mZŒ=6% Ù]NÐu¤s0E‚ÿYð»\I'T‹p>̵†ƒ"H= ‘ª-ùQLO*I!P9RÖ° ´ŽšL¾QfÈýíDzjDûYEùœÑåZòËëâ¹ Ü 8ê²€È}†Ýù«]5ÖôV‡Š2Ûy¿Ì¯Ê”¨ÈHs¾©Ónb„ÏçXÊ°& ëçï‹šß÷¦‹:ü…諭==’åÐýzúÙL}ˆÀ^Úíéˆù×½ê9a´¹©ôz£œ]?¯™ ,}QhyÜK(þ|Íöªgˆ˜€!¨Z Ñ„œpaÌ9…åôÀ!ñ¥ —Þã⢻IW±~W)ôXäW³ü€@óœMÝ>Ç똾r-ên´}h†,#Pû +tE$ úoÜK‚†¥ocÙÙ E/¥ïµªmí’£ær`![Ô¬Oå¡ôVqé;9Í¥¤Ýý}K œUåzWiÒÚ=þ º«ë#óç'ý/Š>a¥ìsµ +žž3¬ªA9^éH_ˆÊ3ìšæدÙnà‹)áâm>À}ÐhàÄšŒ åø3ÓÝŸ•Tw²•ä!l}òrû´žMßÁž}µe¤Ä¨(ÔvÇ µþ«Š ÉpÝ8})Z¯ìfä8»8Iƒ~±žH.<³»k—Ã¥ÌdÕ¹<™Xð’hɤbÕs!÷Müÿ´/$¥nŒñIpƒR{Ä„'âcêRIÙ=\XÌDçl„ñÙ7<²´-œà SæÞ’ÇVûñâ¸bå#É^e‚ÏÙþ*Y¥µ +÷5bóWŸüÕôt³C9D$š)I®«K$j tR(PPÀ"“‰ìXjÄrÍq=L7Dã`f*n^˜ÑééÍz˜`ÕîÊ_Òºn°u|ù5Öe3Œ?Ä‚! ×J„·LR8“*'²¸¢hŽ•ˆã€AŒe~ô"ž^'Ô®qiÙ&­´fˆÄãow^xvÁoóÏRvÎ?îè†÷ÖlùÑ2ú«4Nc|mOdòpÝ.#8£²#îK²nd¹!6Hßçw¿Mï;ž†‚ìÞ BUuו€‚CTl®´ÔZ¡ØlAi!Lëö.¨N«¬œÏÂðNÕ ÷?õaØÞ&.8ï †‹Gq2x4Sâ@ò~ê–œ%´Æ­j¤«¦³úN‚Ó˜N SˆWVµêYkÇ°¬5²¥áŽ¥ôbûz\séeñ½kQZy¤h*Z–E(ÚRˆ3 Fè~˜;ã|$ªÓÃ[®ÍÖ-˜N]ˆÉáÙP<|Å:³èôFÎõSº6¾Ï,)£Tÿ¨²š +ÑåêB:­ÃÖŠ Êx$To9@H¸%±.¨Ì~jô&+A 7—ê³Óê®ãO ºQœß ÝÓ¼UëªðKŒGf´Â8Jý?âá~«¦°,i´KRQFÈ:çZÔ²öhÚO>Oɽfx‡2ȪA™`dµjg ÞqÚþæb[{e=?_)ºüDÁêÊl[TÌ37Æ8)Ñn+àAíMõ­¨Š"z´CE'h˜¹BÅQqzïªö0|#aÄ—loàÊ—v’³XfŒ´xè@—zÁÄJ/Ÿa‰¹­2ŸÝ¥1%~¬uÂ…ÚÐ63íè4(ÖOHv´Éã‡6ø‚æ *ñ;yŸÄp+íKÈG?üþúI‹À7 \sNw%Ø’‰î;J¸To•Ö!NÉSenéN†£²p¬î“‹vÇìàà¥vŸæ:ûó”Åáê–Ê Å’gäÝÙ›¼í*p1IýŽµm©– Ý¥Þ™P`<êÿk¿œ–+Q,š¤Ó±­Û¶qb»cÛÛ¶m۶ӱѱíŽçþüMÍú€õ´jWmâžnâGa¯/e®_°^èd!xìí¢ ¯¾>äÂH³Œ’L­‰uw›Õbd>)ÅxWÛµWã h”M¬Sçà’.³™FðuÖîë' $ä|?3¹O€úu?,€XFc”ÝÙP;™ò~ÃSG\iÈÑI¦„õðçBl9Áó<×`Xzr˾uӷÑH?sÝ‚±LɱT†UJʇ ß6¯BOcE7W‹oûvO¾ÍTúŽ§¯KˆwÙÔôã¢K)]€úøoé)c«¨T½«ÄBgOBiž?Ôu$i6§(`«N"¤VqôB¨/ç¾›G’¶ÝÁaäz©¶îp”kQGU©·T½qk”D”øŸ*Íø^nãGò 4¯ d¶¯'ã*Öáå,Ù£b|Êsé†,§²Ð¦Z¢€%¦N<4¯ƒåôbtß+ÁxÎq„íöU'éù³“ÁÄ€?å(Ÿ6î §SÕY·ùÑØ5E¬©ƒi• Ó¶ ã;Ü«Q²õò¿ßÃNè[ÿŠòÞÓ1äï[}ˆ·8—^°xôï¬3¶µ±‘¢5:ÿˆÏÝ•AOoË° +4­úWM‹~©¡CÏßÊÿU-Ÿ}ìŽY¾†¢á_±@Yh€íu›øbÔnW,ø”=ízt<îKfp¥]“ŸqæÅÞ-3Æn’aZ|ìŠï|=AW?~†ŠŠ¬‘-šë\ïb;üšsî¶j÷Žmùé4§xßîh&ô¥ü"{kƒ³é|‡l#g nl+Ï7#R±´Ö>õŒ™Y©âeë:@³Í¿xçc…/}RÖ¸g´µõIßârÎëýM•4yþ^Ú'ȇ·ø§–ýͬ&‘^×Á7È:6'ó'r2!LÇ1¤Abw>ñg²*¯Ž¾O‚Gk(9ïu +%¶íV,ÜQòQÛÆtäf‡ÅuZý~J´A{3’ÀJ™‰&Ð0M\ý\¶XÀö1S¤³ô;5¯EaÏôJ0·/›Í4j³} +eOLÌq3©¶Ô}ÅÂù„וSmZógÀ:dôe7ðA¡€5úêKíÿ¹â®RâáÏÚçËÀ BE* h} Ý9htå_W´Ô½3ÁmªÅŸ¾?~M_ï9be·â™ô¹-ð`á\Wqv|®³8_'Óey‡ÈŒƒ‚ï°óƒ~Ø//ê,·"FxÀÉ€[.+OftI8gÀAÃÝþ’âüQ¸¸Ør~€rKò¬IlòJ‘+6¬¾•~Æíöî.ìRÖÎgmîàYÑ€´g±ëë7LÒ(©Ùü|I#¯–>Sy go§Éè0Ø‹P['3o^‡× ‰G=Û%Y¯?&IO¼VD .©7AÕÂÝC+äàº)Nmè:me°ÆO3›_ÅòvóBÊ›¬L.hÜLÏå\®¼5~ѦùËLÀöœmf°™ö.%0랇>¸2UáSB/o›ú"¥uŒ +…™¡é*®ïÏZžx;À-Ïåìƒ"ïÚ†ùòù·)*¤¥3ËÚ^ý=äÜúP~Ø.†ÜT Ë ‹ùæ(Õ¯ ^þkΛ±¢é ¤TrÌ°íåZãÒm5Xî3·#xæÓÄ·¼+»b{ÿÃ0œ}-å1˜Ë¾•áQÎÁz‰Â¬ÊÞ¹tEpyIêY`à7¢K KÀ½1«Òâ ++aëØ “)¯[L’ïµ' ò+Ÿ°Ÿl‘\ñ™ÛtôÍ<ÌÖëwÊ¢bð59Ð*ßCdŠã•Q¦T¹/®¬“¯}%%§º/»ï³t.fÌ fMÚ˜Õ]Õ4}/ ÃÆѾ9ÿ5$ÉýÓ\úP/eë1WÞ³…Óv`ÓHT»Š@NùÛèjÔø«Â2¬ËXì^â{ËÆmô«—Ä 3¥è)Ç UGø:ÿ‚|…o?W6Á~ÇÈ!]ØâgÆ®±ê3_áoxFP²¾Nµ¢CŸs|’u(ÙR«ãòâü)ÞNcZöÒ¼°nPF›‘úâP‰6úÓ(1êv¾o*ï›”|QÐù#$!4SzâS#Ž·uþI6Då%3פx{ˆé´¯KKÁçÌ®CÌ|HuæË‚Þ||ó_¡Ò£)®+yû|(ëîßâ‡Ë@Ü2…Ž—2DӪæÇNA´[÷õrðtSðø{ƒhóÉ®p‘þ7.Ï(’u€Øfl1©Ü•Ô<†âÌnj$~à-Ì£ølÉFb@êD•ˆ,X äÊ[ÝŠ•>´³cxË%ssøɆ£M>ÃJ¦öÇ\\|ía¶d:£ãÏO(c‹ÝÒ$ôèq˜±58Ãrt îv&ßÆSŽ}O «Û©-$ï‰#‡`gÃíñ‰Ÿ +mèLj¿I¼Äyê4¢“xC‹´¾}í_dšÈb‡a¼Ð˜,ÇÁ”jÿ»¡| +ôÏ™¶ôúû¿ +h?IOø¿{EÁk–X4~Ôåqp „DuNLi’ã¨L’¸œKŒ}ƒ—Öxåp·UÚ¡e=.L,¾uêÀ±Ó>Ø6¶Ëh ¾­I ©¥2ÈæýkæYל2oíˆ6KîØà|ž ° +4£|í 4öî #a`ãåƱÂcJN¿$DÁäÊ:ß÷”¶Sù¿š0'x\n)|”"<jÈàlZñL|ìó “ ¨EëhÈ`TdÈægòㄲ'{°›ö…`*ÌñN¦ÈKìí111—Q'ÁX¢‡^¡8fŽ$°}d+xÑW_Ìñ÷õ•Â  Rö>ü?ëáˆò$ƒ‚EÍ›z`…Ó.´ïîÞ9C˜Lö*¸`b@åMlå½/O‹EW98d¨T36ã±ÄuÝY;h?»Ä˜¯?S/óÉL\ ÞÂÞá·˜É=8ŒõÁ e÷µ¡? +¦?Ä›Q‰ìó +€u“¶o-ռζÈFE£ð.åƒÊŠë>{‰*¨òwµš°s÷ãÁ±A +Ä¡gK°–jྤvÖ?”lMöV([®™4úÊáD3p½$V¶Å,t‰#”ò·k¼Í_y´©¡4A{;D9"š;ó;ée$X|9T7N®åüok½µÏÝ3äñ= àŠŸœó ,çPzìýªk,AUóÚd¢`VX¬@a!G»¸¬³^„žÍdSïÄâzy’_W}T kÓˆ}¯µj,BMðî´¥{¦XS~§aN·¶®žc“£Ô‘«8³s&ëÊ‹·Å &èñÜ”?äý«>ÀÞ×]Q´®óP™Øk`ßäÕÝf û®‹Y×Z«ruì=È3€1\&ÀHCNXùlu[80ëFÝŨïØìNÄ]© +˜%0œÒAJ^ý´¼%¤w}/ ö‡î²òAæìQæãžûnúéùÎÕŽÙPÒòçÌÃzÈ/Z;ž)\x‘ÚìëÖÞ9”U.‰Ó_>ò_øá5Uûc-­@6 QEæ*D}X2a/GúGc1§OMc-Œ¾2å\¶ý„ÆP¶ó2¥‡`1”{݆àYšU!²TQŒywµÄB´¶BSÒhឤ2šA1±3_oyPüTIŠ¼û«õ[»TW”—¡6ŠÅ~u‘#·ëõpmðI„#³ZÕY$Øóyø2XõþÇ0†¸-{ñÍ·¾ªå¼2ñåÐèœ/ûY-T !ÓXÈ`lgÀðß‹Ù§¦ßªY¥.ÓJÔÝ2ù¦Qâ2¼·ÓýÎhð4[YŒX¾i‘å÷Í6C1ï²ÂlA`ü_ð¦rk: +_ÃýS‡µ )1ŒÊOesLQ² +Ôqµwˆlød {ŽÞ‹t¢ Þâ+ïí[^.\1} )ÃÌÚtú¢à›%×ùRO|cÇŠˆ?ô€L]£µúem˜m…pRn7+o“Þ«¶›4s·Í –çë:yÊtôÒ² ê+ã\æ—‹HöɈD#|q™eѺTÀ?È6@å¦}Òú”¶¢§†ñ®ÐJÛ?ûÝ( +!N™<‘cÞšó¬1¬ +Jµ¸Q¾n ݧ¿žc@\é—‚õ’®TŸ3«0ÔꑯJñ­c81ÚGe:’¸ëðîÞ€0c(¤¢H¸ŽhÏ)^÷MÉ*ïYŽ0… +¸* ÞNK +Ä'Εo äNïçÊòHª,—üw*»ú.|¶0ÚIÐ ž4[Vƒç›-Gy2½ û{(b'óXèŽïÝÕˆYzåeø’ºkSoðÕzN +…Ï\{¥?!݈¿Q 圲,é“Ó{Ü™Óó½%·‡ƒR™ØKY,áëÎú¤ÌLŠšàßÎÐc+t_5ñ‡^€ ¨aà¹3n<‰¨ t6.ôÌö›Šûƒì-w\£ÐZÆ.ž(¯íôúDÀëôèT!þYÑPêÒ•m‘Q•ôƒMƒhØ›‹Öš– Z¿,ÃCó +ËÝ@Á¢gßqìöD€¶þ¸µÿO™ë&Ñsu€r“·NŽ¸¬¸Ü/½à=Nº&F¼«F_ L-C§ˆ}yï=]Ií˵¦² †¤Ä,Õmza­®4@Aĺ@q‘s “†D(7–Øuç´qçGªw=cP Ïú#ÆÅ·¹ªËPl²Uø¾d¤GË^ôë/mŠ¯,¾RÁõw虎ðÏËxuë¡‚êìI¡Ï™Cè<«ßÙÈIz‡¿T/H$ø›Ÿ1ZÉvPæªhÊ'ŒåÇDS.„˧M6ΰP¸%É‚Siæ*aÓõû@ ~ä¢×Ûê—}¿ÊcM$ îœGéµírжJYÉÿ|#1ƒÔ;àÐ7pð8rü5%_yÞ„r”]ãk‚ò‚ˆ<"ê™kk?IÚSþOXÍ̳ߙñʱi `eV`Én‰R‰v«qu×Jzb;7ŽÖ_íETL"Ð8a$ÓìÜ8;tHiúÑÒi:!ZFQ«Ë²¹ÆÐ!»€d8Ú6,èÇ%\&¬H‹\ZØQ·§CÏâZZ4AÁi¹ZòÇÛzجêS×Qר˜¡óù•Hî,?X´†àñÃðnÛº‰9ß–ü_/‘ñé3ÄýBOÃö%O«ððÖ9Eçp¯¡œªJÁYÉN0Ä%ÏÚïêEZÔ!”øÚßÜ“‚ïW<Àf§¡&½äŒ/I?aB'·ú‰²Y«·y45,¹Üjʪ<=ÛVáje{‚¿œÄÑõK>K$9Ü21s–ÀáÍÞ·­XlO[!9NìP%§ØKBÄûïi+‰¦óÁ×ZRÑòYÈÙÅB±á‹‡”#(!¦Ò–+±ÕŠø®ÚK®<]rk—À!‡jÉ¥¡æì<Õ í‘Ϥ@™Xä¨L:¤µ¸Ë$E䪕âxKq\ÿD.bá%,Chm±$T~Ùàó^ã±Ê]ÊÐGùNÆ "§I,~ÞQ†ždºÙ ù°–`NÖ"Sj1¯…i+gK¤·!Éõný\VÌøºNnqy‡Üsä §©«ww~=Äq‘b²­GŸ¥Ã›×û2·J³ID¢DŒØDIôLÓV –­~&J‹=—YN«ýœúËY#é¬QZ¹ˆ˜|aÛ`„·›ÊºÿA!ß¹ ZbëíæC"ÑB^@*ztc9„)þœNIÛ E:2"ù1ÂrŽ(”qØŽÔÔu$æzÝ€LêL¦ÌÅ&â-3Ïû€Q ê´[?ô‘Ý}·]C,È×çŒ5Cè•\Å©$Ãæϯ£È§{ýÂ[VNB¨æ(êî¶ OÝÒnÝšÀîL|H¢ð˜²÷¬žTÍý.”ò–â„Aã¡,ÇسÞÉz`Þ¾¼k~AÙTÇ]°ý眆÷ùóØG`9mMüFGŠŽÆGù5œ…R¿!ÁBö²*u¨¢|¼Û}õ}l¶x«$˦­k¢ÿ¾Æv^ü¥ÄP##nÓÒÆGnÙ €•&:Ž3k'*ø0 |ñOh”IßòcØÇF”Ù7""QÙMP†O2PO:¶?Ñ°Õõ:)ï*קMB_q«Ûêã¼j­'wú±3ɤ’Þ&‹7KÙ3ºº‰+Uu}••²-}AœÓئPVǘ@‘ï3«CÜLx¶°^MÓÆ?` äijbH )-™ Ã8 Gn¤R\/üd~–òÅî<¤'aÀÍ´Éy¬.ŒbZÀ¯ÄÐh3ëÓ-ÏÇi[ºx}Ñ?[íÙe§ÍM@^‚šÉoþ7졇ßK°1ÝBéÚK™üoPº-¨Ï^Fž+wñYø¢WÛŸ³ã®ðS·‹:>ÓÖ¶¨±ÎieÎß fmô„ÜΓê‘ÖºÃgt2ˆ ]¥…sRÈú‹:÷®oü']­eò-ÄdÞ¦+v{ÇÂeaTÊ•µpj諪µ7SX 3OéiØ®ªwOPj:ÚÔ‰~¾žiÏØIXÛÖ;‘bâc†´®M£<‰ê¦ë)¡D·'²\ªïJmú¶gáåãVÛ¤úµŒ —Óë‹ú¦áîJ~°¥R¤±Dé@>c#÷‰,rrXå{*ãh'=iU³ºi÷–EŽmk÷r6ÄB¤V9Ïzs“ã]­(‚-‹ïkÕZ@½Æñ´…J:,õ(!TÏaj®Ác}ãö‹Íf†|ä„ Úz²€+•“¹yïÉ|Îøúö¯ü «˜ŠçܪΙ¢¿­ü|”z<¡¸d!+iéûž¯i£bݘ ,¸¹Y¿Û-³Gõž—û2z¨_-R·`Á`¥ÅŠ‚nü먋á,ªê/Öꎇ@ñçÅÀ‡µ"z¡Œ{«C˜ï¬ëÚm`J`öÙÿx<òxà!º Ѹ÷Uâù€nöé.R€Aå)\á{«^×S'©/ÏkCpb@hÙ,R=RqæëfâLsÆåªÐ‡vÌáà |Àyéäg,åå~B’fwñÝ—&Y4Üõbã>¤8·õLªº\ÑI¦·öIºõW°£ž¼§UÃ)KBB”¬öÿÿew= 4—ïSJle7ê$6Æ…WÀ‰6Ï7òõý¸ð.üÂöWIÙ{Ùíoû8ëäU±Û=6ÉÛ ÝÆÒ¬åhn@‰æq æ[Ž% +¶Èãé©t²„4å¼н”n_0gþZXßåì…×bKÀ!È*Š¢Só±[¸ùq]²Q¨ù8Èßu‡HTs5ÞV¥XH¶{í»Œ†í`Ù·Tî+ž†äLC"ábYàÁ™ÈŒšyU'ÊCÿn.ÐG£ù=ñïxÔÑ' +R㻯ÙQôÏŽ}Ô Z—7“Á ¬¤jžé ñ"FOiŠ>?ÎyÛ!änQT)Æd§ Õ©Jü[—p1}àn‹߯¶ñˆ#ªU{¹SV}¿W†yT¼"~,*0W‰™ý.ÜXxäݾw‚”ÕÏ#hïyª ?N8,¬Ÿ¢Ò‚÷†—ó]ÅŒPpFÅKÕ~G‹kýj Ý¿þKIÕ$õºÁÞº©‰uVé¡OýC±ÉåMìi ž2C´gyƒ?’ËvH4åËÌŠJ ÂCéØK!ÄÕãþIêf|ÐÝþs/ô³@Ä:÷8=]׆ËlÙím1qGoi{tÒ-3î.¡¡¡)òË“–š1®”9c¿X;È:Œ5ð4‘t# `bK)qA¢ ©˜æš ›c´­5ÁzZ1ŠÞÖª)\“²1ì×±u27Õ@}}·f RÙáÝoW9Ç\P¦0»EÆ}UB%×/y×—¶¤^â¡26ýù,bÍŽóPI2ƒM<¦éË:ª‚ »û­h¡1¢Yâl8.ì4„ãGóqj#ÊÑYœÆïüO«È#!˜na¬âldfk“ ÅÎ.Ô{aTOFç x˦â[ô)fËádï°ÏçºU.‡¹¨¤93ž°‘òóT@œEgf>êd ³·N­[±mÕ_ „Éå¡«åc +bJÁœ>ZÔ¶X-wJÂp²u©âÆ0S§±sª3KÅæóì“#‹yžÇ­¶÷ âÙØn¼ú}åÔ\C"…}ñõkRO‘"ÆÉصCŸ°Ç&î—»ýl#˜LV¢n÷‘¡ÈÀ)5~ÁrioΟeÓH²ƒ'¨ŠÒc~1GÙÏVÛÔ&¶b®Æz†­(óÞçy]µu9Û³·ºSß<ñ‘¨¥ÔÆúµ•†Š·ý]n>+`½÷£¯´¢w¬lŤŸÊPh;w#7Ž®vUs Ë0 ÒÕ1©HÖW¦Bü0%Ï x4î/ƤúEGû ¤y+Ë(§ÛH·ïv²x¹1= ›uBCpƒÉŒ5¾ÂÇ™Ò{A•0žÑ5'†:]+³ lYô9²Ÿo Û;O%í§æe½;ió]…J.Å*¸½ÚWféë]šÆ¨’IFD>’!(š 9$˜Õ{è{W»‰êå|rg,fi©†Yœž›V™êkS3ððŠ³Œê£s(h"ñÞJÚ¹‚ërG×ȃ®Ÿ¦Ô\ãûö! ]aX +=ÄWDe1ˆ¦H”L9ʳ‹Šâ(ÉLU~f 3Š^ùž©DÃUBAB´m0Ap ÿØÁ÷4@-ð³ÅÌO­‰D^¯-;H'?Çé +A™âõ2ѶŠŸÓ¶Äøí÷w6Ê+–IºÓœnµq×oúWïkN)ï‡mÖ8/1aÀÈ[­ø'! ´ŒÄPxÉ¢rB<–ðœØEÔ?Pr|7°™2­²3Dá ÄWUOš9¬hÓÄ5@)NI´°›s0ÇÖnŸ[fö½U¹fHɸ>›»|¾¸¬{ü*ÄØ*X‰À¤ø‹Ã’mdñ„]8Î̱r¯éúë$Ÿ5îyôÅ 1™ú&àv(WØáñªLŽe½pò‰õTàb{´ŠÄB!ð¸YRE!ɾdä\ÁÔ| +Äôò} 0á·Ï<ðx­×³5(©²ÓÇXõ̼‰h8L©m¢Í°]ºÓŒx$“ +­u|Ðí8t^ˆš/€‹MÝp­_’<{*ñ>Jn ÐÅ—6¹s²R¯aÆ‹úr×€]9ä¯:²(`\‰áÉlA7¾ĦK”ž·†9z8nb64Ë¢jE¢$µ1V|·ZBËÐöX#Y»ͪföWßqYûlf/ö»­8Fj…›ë_X1¡ÁèínÕ (N1©þ¢CÑð´ýÆ9(AÄEêÞ–«ôáÃÉ€ÖÜÑf}_¢£J¾:¤ íéJ$<ÂBÿˆSUÅöìMø›Yr¤˜¾ÃÈ×`Qíå?›Ù±VƒÝŽˆ½¸ÂˆÚÖñhÃÙƒXÔ‡7Ó¶,Í!Á•FÿÁEè^F ¸¯xÀÁ¦ÿàB*·ÛvªR&¤N<•ê`¢µ+çN¼é¬ +g¤£Ê¾2f~mû„m}…i¶xÄãæužÙÆœ»‚ÙüÂx\Ôt{™C Àåò ›ËøýÈ·'5' ªzqvipd×kµ»¶j©@ƒæ…:Íw¾?bøàôVs,%ãIP¡ÍSÃ…„A³ô‰ìDª`Ïûñ,{r˜¦fY—AÀ˜EÏ¡+LNä^õ,¸¬Y¼B™¡9ÛœÐç†dbTC4è¿JLWl©0Âkž ^¸ùT›Úò«¾¦ét«§^Þí§/‡3SÄ蚇dQœv(CÜ쇵È%#¾j0Æ7›5pEZ‡ì—,í¼éÀOÇéÃõ¤¯(CæýéZb4üÁP”™Γ{5Þ…k`åùÃJÙãpÔféAvs,µp̈Õ.¨±g¸Ño¡µ°±P9:Ý,'c|Ì1eÁh†M~‘fQÞúûdú9’LÈúôÖN0–"/Ó|8׃ҿ]‰/ óûÚûس˜z$©Ôü³[<~q÷é#ƒä2 +'óP4I×¥ŸÐ?`b¬FH. ÷R}ÿÀ#] «iÀAñ7FÌÐ5øùq6O‰ Ç/êúWbõÑFåq-¢´ð §]xžök%˜Ã–td˜¯‘ŒÎ¼r¿?qEµÀ¡Glq_åOÎ1ŠL$HülÓ‚|²ëÅ›:vÐ Ø›¨†À<¬è2ëg8„7ë%j ÅL/ARWˆŠmõƒÑ ±)Cðî&œ£Ò(q14ŒED;ÌjdW åqêÒÚ8ß'‡õt˜{r›`üz$¸~ЗV-ðr#QcªžÉ¹=H­EÍëCóIîÁÕŒ–aYÅuz8UG²þºÝ¡HJP+dGR]¤IؘNd'×DóN'é[ºqÆIÒĵF,·;Å—d•”©7•‘W­_ˆF®kô­é¢á£tΘ ~­ yTjænUÀNöÂߥ6”éŸì¶\e>:3‚t{ù^÷p*kõ!1ñÖ3«/¥tŒëÖÈ|æeWç¯ÛQ#`IbýÍÃ$ŒPÍXÉSKUŽž¡’` ËAÅžþ›m­%N©ò’÷Y ¥Ê¡K_º`ÕsYGõ¾ìŸö¨,4ƒ“³›¯HC'Ÿû89cá[ã Û2?ÆN¼ ü±ù#°¥ª0ägã¶,Š¢œ¡. éj”¿ê?ÉxG# Ò+“Å.ă-†cå-Yo¢UÄVõñÈö15Ò»æ¾Ýc@@íéíAŸ LüUÜêÏÉ…ÜÔ¿©ÿÌZÏ‚ñåÎSUn9“mbµf[‘€Š±ÑT8D1¿4г#hqÙך½E9É{Ь¶uîœb…M'­?/ÖGÐÿéε%¨˜Gš±Ñ3 ?hßó¤¸þa¶„çŽØyžÓ€’^`´ý×Þz\‹÷¶v«áP{ÑÑ•Ih~×`5»æ0ïfM…ÂÛ +ä&oH[œ¯A•9fÜË•ÿ+J†'¡1ê’ëyC \<†æ›îyʇfäiX.²¢¦ ËÅoöøA…°•#ó3ÆÎÑ—ï;¦ûÁ_;râw‚›ìĽÅzi“Ã+Yxh­ÀêÐÃz5xu¾5)sþ³py}Mµ~à óÿ¸ÿüŸ˜Øš9ÿv°3r¶û?s¹Kendstream +endobj +726 0 obj << +/Type /Font +/Subtype /Type1 +/Encoding 2092 0 R +/FirstChar 2 +/LastChar 216 +/Widths 2107 0 R +/BaseFont /WWIPFK+URWPalladioL-Roma +/FontDescriptor 724 0 R +>> endobj +724 0 obj << +/Ascent 715 +/CapHeight 680 +/Descent -282 +/FontName /WWIPFK+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/endash/emdash/Oslash) +/FontFile 725 0 R +>> endobj +2107 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 500 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 +701 0 obj << +/Length1 1614 +/Length2 24766 +/Length3 532 +/Length 25647 +/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þÉmfa E÷Ϩ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:MAaQiªÿó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“Ó½«D¡;MMM¬:NNIˆ0þŒÞû+âÝzzÜðà\ +Š—€’»qt‰ÿß)âxô0EBå)¦d4Ôà,Y=2€Ä„ÖÈ=ðK86iÓ·½µS(ç óQôx;”ˆwMÒÝ\]°Ň„ŒŒÄŽ¸¼'Ž‚ŒHè¬|Ûd@I¹²‘E —çê‰xERµÆ[ºª–ØÞ÷6µt×Ûô”Uâ£ÀíÇÏcí—‡²áŠù¥t/ëE½N r…5õƒ‡À}[ÖvÞbO¿öxî3–^üX³~ݱÚtX”·úbÛ»Ze¦B}Dþ¡¥±{dyÉÞâþÝbæZR4ŠR`s§Ú1w p˜aºÃVÒ}ŽÔŠ'X7zÉ(S†Å£À¥AKÝÁÆçr&ì椫û\šì‘F­ÆLu×c¶X‡YÈnT<)—l%WªzÈ +Ì0Lo”2´“4c×±¢»ò“÷é·%¶œìÔr÷«rOxRæ@oÑ[#OóÐY„ý‹UՈʼn%?¼H»@yÖÞãLùbùÛq÷›c}DNCýŸoì sÑr?áƒÔÝÛóŠJx>æ?¤å‘]ò;ÔHbÓ‘¾tTï¨)Âm"È|Ó\¹¢óCÁ†e`ç'(Ël-zÝÇ.æf ì„©ƒ5 /Â/‘˜ÅÓSþÃEÞW;mdu‘ýêØ®=)À6li»ÙæüÖEÍX»Æn–ç]6 +Ȇ§yð»Ô™6üÏ2Röv•ŽQvvåôTÂ*¦(?ç)m¶5”OVÀ#8”¦Ú•4áîPñ"!Ýa¶é]\yc™··sãAZPU6gbß+:*(¥Þ'V­PÜ…¥Û)+#®¦.ráýô[yÞ]²ÅÕ¦<×µAÅÊ|…ø Ý&Û¦ÖŒß,`ÄÆ +\w­wñ0‹²R§ËJ†H®oQSÓâ(b½,íµ‚9¹/#Ýýo ¹|Êq3d›p+¯º>2£~ìîšzµ´[=1#„ãW*Ža†Æ4õzð­âü¦`E'K‡vU?Ê ±lyZ¨ö©­O›iÁ&6xDÏ/ -8øªˆž!/ˆalÁæG¼¸PIQÔ'âf΂ÏÈs%ÔÊbÞ)r1X#Þm@i°c€B  x›¦çë}4ÕU _ÚI ߪÒ­gë–i“êÞ* ]pÕ~éÆ)‘¾ùB½Çµ6úþD+.|qŒæê²^”¥1=XXOV°kØ2å<’*«9°ŽxòH ´›ñû]·ñ8l35Çï>oøeD-ª ï(cÛ¶.ûK@!¨ õ¾5üE³DP:[ÞŽ3ÆôŠˆ}ÕFŒPˆ¡‰„Ü6t±ä͉ +|\4YÍùô\VŽAò¡iÙœÐV•1ë#~Ú¦c®IhòT3S–ÎÎÛÞc|³!6½ñà †ã;–iòྲྀ\{ê€ ß„†EødAØÆ(éžDô öè"Oï?órš"µkñ㥡} põCÛ|TŠ°jö·1.+îq æš½ÕÖÓ¨0A" BZ8Okaƒ¦Ø;oHÇóô$Dœì@_æ‚y:hã0 ›š®Ï/óÞš~½dç"¤ªÛ•E¹ž(ÓmÅlQ$uÑU/Ã| b·8œߺ©17Ñ€2‚èe¾z@ypO2Mé—”Ý÷n‚pnA'¿1ٷل‘ñSoˆ*[¤.€ jÔ=R`>oQ³‰voqÜÕ€,ì;ÕùoƒÂUp…ø<Þ¼nd‹*Θ`Ð…²2€·½OÛ§²|#ün”5¸•õ²ùœ×¼¬³Õ²¬0'MSh%.é4îVáÏlx +'Œ†Ý¥ýrˆøœ]E ‚ˆó(‚ƒ+c[€Éj‹®¦Qíä¼_Þâgˆí44U÷“É;2–×LC +JOÉÒ4WÑœž:óû\™Ñ™ïÞ! ×yÖ\3Ûø=«/Τ€çÞ¸ ¯æŸ/8ˆÇîc+Š GI1(yBª5ŠÝ¾^ºk½“»¿Btœ'Ïá‚<ÚÂÓè¸Gù‰4E–'m$âÖ…;©ßÈ€,ÌH©ÈªÎØuW7ðÅ}Qgg.UÜ€‹öË„¯Ô—+D+K.j’™pìlîw>k»«áª‚˜NYK/ >œ$¢/Ü×ë°R +ˆÐ÷™êq¥@ûÏ|åRøíçÒ¨Zqé1#.²[Â^%â”(:^ŒD”ÚPØ•/ð +ÐJºN$†¦ædœÆak¯n¡mk5¼{n +©.׬nà'' 2‘î3ˆ2?g‚Ó<ûeZ‘™a÷­6™'zOÁt­:ñÕBzÚFÑ£AjÅ6©²}Ôq”‹ðü¬fŠ™ðaNõRäm€É€e‰aS—š=ø„PD‹ Å©?Κ-Év“Ü*.ºå„í_óÄpçÂ’EJ-Mn’†´#Îó¿?JýjÌàUàTƒ* + dªÑ‹ï­M1–7°¤*’±¹+DÞÄZ·íøjâ?å½Ü ðûLÃ+“:öýÇÈç?·Œ=¹>y.ž¡Qvãà…Ï™\Tz‚ëv<Štbèû°Ú¥€gÒgñ] ÃÊ JÛv§¬µë-èÀ\Õé)Ñ&ë!d9¯!(MX0Ý?Tpï.mêßýßVýÔÅJ/Qq“êå5„ +”;çÙßëÀÓùÙ—8Ç!‚Kùz.Áøò¯Xñ€¯ÈHêKŠ\M(€Á½µBO8 çXE_æsÃYZ·èp6aaLÞ5f(wS;áKéªOÙÓzôx +Õ§µ÷YÍÛž—™®Î燸-f: sôqó957ì>\Ç´¶ ¬C½}8$;DPì…eªì¢V¼'­ØíÄ<È“½Ü¾NO(߈]øé¦ÛÅr_[Þ*ʇ¡ÆËÆ<Òx ç˜î®l!™(Gζt Ë¡J6Úöž¡Z|û±¹¥Ø¦‹±<)”ávs"¯ÿB77ù>±9 +Ä’£×¬÷°zJmp¤0ZgôìuáÜí™ô!F…ªä Œb“Ð.ƒ ‰¢9wØhQÝ+âGùTjx­~wtñ».^jËð‘g&rÖ̹V§#KÚý®Œ¿çqÑHºö”Å~àlsLÓfH9áNjn£W4`oÑ£:»Øš^ÀÅK¥ŽÒúƒòL9ôlÊ0Û‰B˜ÚÔ#k|yË¢\Ÿ=*XˆÕÄ óRi× à¦H~&¸·—ϲSz…€ÕhßÝ0Ö/äH—Ì-Z‘m®Ûû <€úQ³Õ0zÒבß8r¨tIÏ'Õ`™@*ØÆ®@fÃ&€IѪ¥v%QÏ:®Á:.s&ŸëF­¤ƒQüʸúW ›_!Ò0sI"A4ªØ¼D×Ä÷¨C!n†Ñðú;+‘Öº{ýŠ÷ÊdÒ”üÝz/176ßÆÊê0l®«ßCヤb£s0 N­÷ä?‰ X! ¦œ´Î`ÿ¾‰$ý:Š¾]‘µß«kw#+‡üåj$P®¶½¬6>žæØñ^70•öKú€ø$ˆ]ïï­óÝo¸@g\³°Gé_›_¯›ÓŒÉeeXY¿³}ôiºiG(Œ·´‚&*ú~ŽÇzªF`4&šš8+‘o""7÷Ý3ƯU¡³ß-Aöêxáªî]2ÌÀçpÛdJ˜ +9ÅùbW<-—Ô9âEjRœáÖÚîö©ÝRËâG^ì sJ¬¾bíÇAÂxÙýeØ­ÒæÊ>•¸jÀ ,WÐs +ñÝ‹¼I2ˆô|ß{1¦[y#²š‹9ö_ÀSƒæŸ’™fyf+(ý +K#Îø/÷2ž;¼£§Zç$Êò^Mú½0)íN(ïó‘µ<‘Š6lþ;9ÅуŸ)Ðæ¦óF}»ºÐ=À¸¶V Û˜Å/éGŽIÌYW¯µ=·ŒìŶÑ;˜vìbs¯+YÈý/âwåáNV­&Þ÷¥0óŸ7¯Â$6/ ÈÉa…Ø藺¢ z|£>†²ª=–û&‘*hGTщÌ÷]š‚ëœ1Õ­šƒ”éYr}Ë!Øŧ¿åÈ<œ#ëý«Y)‡òöx~¿˜æ}{rÑ\¨®ÚK±ÈýZFÅ>V;H4®WV<^»óF†â„íÔ—î²\ƒj4Õ!š¼2¯6Gp?“‹Zi_<ÎnnŽiµ)Xg¬N~_@–GÑI; ñöa±»ùu: øàý‡—¶ËÙloOµŒ…6÷¼V¹1 ‚*ÞÕÀ³Ü2 ŽOÚy‚³OÀBwFÆSwß× Må·>æ"ng,Ÿ¬$¤€w;ÌEÞf7âúe-¥nXe€žªpºLa :¡…ÏÃŒ^^r¸ØˆÁOäÓ· XF“ã®qœø±NÈ…!-# +«Mˆí&/·}Î I Ø%΄%0W¦É·¤¬´{âI\5d§1ÖÙA)£7½¡TDƒÖcÆãM~ÉÛ0l4ÚÔÕÝ„ùäˆ÷)—h7¿d~aùruÖ[l¡F÷è\)ãƒ|9Ù¦'ýŒÓoX™!Ï·²6…ñCìÿDapï“AVá ösò߬!»eÅX#}°;©JƒaíJÁ,;ÏÊó-%•6¹“ÉÓ1­Ù7Ó.QŽMœé`èð!s™ãÆÒb¢Vyz×¾Ï@ä[ RÒ…¸•°¡½oºì=Å0Î/˜ƒíÃ݆ÛÝ4uCaåïæT{!¤$šb-»™5– 4³dtõTÁP ­»ž:0ÛªÍÜ|njŽëéY Žž0“|1&‰•rœR»)ÂPåø2SÙà Là ÔÍD›ñØ•¼ƒe¸Ñ¸üñ§fžÚ£ƒrÿCâ"Ci°Õz(¾7ª‡V6c·µ^_ŽõÝX±–Ú¿ÿ¶ƒ,ºx@#f×ÍÉ—ÔÐt<­µÑÞ¯SwE[Øx-Í­.¸éOÞ¥f¹xpõº¼›ÅÅ?¬’ágI!Ó~lñ¿ö]>i}aÙ£™ÚØåƵ3.žÇ,>Fa´—ìy‹”li‡ WMq9WÍ!.iÒwy, +‰¾É%|¾Uůx¯¸;%ÒŠƒ}5]åD„¢J›œ)h#?yºâþ-^ø*#G„ Ú”¢‘üÀÄi;IÑÉ2çŽÌ/~é)Ñu 죯ã3noዯ78]P³]nÃ|¾g +6ψ6o‘PBšP'̧AFæêdf?P0dGC×´rW›çB¼¼6&³SÊr¥Ü •¬SS‰ÓòñÞõT9Žú¼K)Œ\û)°bç¶Õ†3´$ZÞ#&†×ææjsmÂCf‰àS4XäHF Z”ÔzϘ(Pt +|ÿÖc2›#á¦$'j‡ß|c›xß3ÃlÞ“”3Bm€Ü9ºš?¨ +LÈJ„5(µ +S|ØHˆGð—Ã=>ôԑʇÞw1®V®Áç€R=äŽK‚uW—e“ 4¤µZ^ öçý†Ï#ÃÎDžâØmwp#ŸT-Œä{Mô§SqêßÑZ!¯È¥û;Åcï¤ág´SƒqÑq/V1aŶõrR€ñùòdfN51©é‹å=túúöp›˜Ùøfqû— áoœOwÖÚu»a?Oƒ=ûàÃ<´ç{±Yúk}Wy†C†³Änµ›à’v€­âfI‰Ïì•Öˆ 5À×¥µ#t }¿ÍÓËx¹¯W–Éw \[^ü©®¢¾ÛèßWñ{‰³èGªAÁ”9•¦Ð˜¥H®!’¾¬²²Üc§c‡-Pâ©P¤!A¸öÕO“L¾S¸p¼²pàx]øŒ©cYÑF6ÚÖdòmýqJ•·àØM¸Ø[?§€YJ2”µ„,,º›]£/oŒÉcQ`»Îßr¢_ÒG[‚e5ÞÖ'·Ù€@®­·;úÚFºñ(êÒÝM#4{èÄ ¶o+¶Ê^\¸g9–À ™«„!pÔ÷Ào¬99Æ"ŠâÜùüçÜ[êJG“DÝñ±h0D´«U? ©$-p®IOŒæ·­-–Ò¨#­l6±…šå$Þ<÷š©^AåyŽ·±TðºÇIæ±k¯Ì{gþ2Ð'‚S»iï:+£Ö0NAr=”kˆ¡j+¥)¸’d¼ñeKpÓÿþKô^MËQŸØøjiíD$bÙbQ>}W"йÝÍÆa]ptYˆQèxwU?X`Ù*5wi|­`ÿT{o¢”¥TÕAñÛ÷=ø9½‘ß@šÖ}¼"D–˜G®ê“[­Op¸Ì¯¤E.€Tä”?Wç+:±B¤Ýê/ýµ»Ôt0¦æ<¨ökºíúðƒ–Ë$N‰öWÏ:^åßm +#‘%‘Ï+0{—¹Vx³½û³IÏßç@ ›AÖå]d˜± ÜšfÓ 3.ˆ•Lçû^«ªwkFOpªÍm“é éâKL§.ã¬f0æµ2x‘$âGÈÛ~Í…†ÙgpèÙzœlŸTêŸß'Ah7‹#m¢(´â'Z %åÝa&˜P[&W)íýyÝaHÄrÇxg+Ešê»ÎÑû ^äŽ(úÖß `–ºr¶jºù7Yþsß›ûPDS"äÊ"pqšQ¦Mê´šsËÚ‰ÉöR'  )Ú0çöÌzlšºð•`^•¼ßÖ ——úq2‹ãqÙ•ÚüŒmÄàðr²ÉEhÈဘÏ˽ÇEFá}y:%rÜ€ŠíÀƒ +¤á¾}˜D'N+nš~¯Ðß0’ƒo™¬WOÜs:¡ðwaz;A³cJ©ÚäA çÖûÈ<’+UȯÉCvL¥ºøPô‚Û²sùô* ze-£Šü;2 «ù«#_š¤£s¾þ vêÄ‹úñe‡Î‡CØ“¨Ï>¼»,æñ’peàùhôm2’ÏÝ°MÍ[®¼¬Ý’‹÷ €"_o UÅôh£ ÖB57„ý^æÛT'kiWCEÏr§ó•vOƒ*åµA´™Ç94\Ò»`´—ͯ{Ø­²ÈÈÛáåúX&¾øoä¦0ÔØðk> HøöŸ+åªØ=âø†M¼·‘vk[|º$»öð¦»tâ—@m ÇÂ:°€Ë8WùŠ7Š²ZƒÝ3Sq4@ÄtWð‘)6ýî D0ø)×ï)5ë¦xÅ"YÖQ¡-Yz»²4û&X³ZþË¥FßJÙU§Õ1l…ìDô¶¿+GÊȵ|Æ¥4>Û"ð Dz»}ªkÄCV­¿•îá•a‡ÁuìSÅÚFpÚý¡ôú=Þ O«‘NM/-: 7‰Ï”;É)6V©ìenìRvNì‚ ‘è“íƒr—#Go“ô¦ŠFWÔl™ŠQe¸ß(„ضêKIÚ-™š”…5(žÛ—Dî;Ϫ" äÈUºÉª¿kY›#ìÏaFÎϬ0>"_ø6ð"§XÂ[]ób +©ØWÚ¿\N[Ž”ÀöŒÍ&nâáµ9vdµÍ¢–£¡!Šã5iAÅ@ñ/*w.¸Ã(:³›Åå×Î6îu1Ü3î᪾ûõW¤®48ð“ã‹KÓ^¥3Tòte:ëù`Ë"‰‹º‚p­,»iAX/†HÛ˜?äµÞ)RR«Y?êxjÒ/½)‚P8ñ“—»C>Är–BŒ!†¬gÝ@¯kîÚ“èNü½?DÆF¹U<þ5”I.:´s¾Ÿj-p“Ã䊰"ŸªcÂ#Œ:B +?/P— wég&åoï²û×!æ9œa pñ|Š®¥Þ²K5lïøŠÑ9„CF †ºž/õ¬;¿G@!íxc|ȹD¤.׎n^H$ßÄÛÂÓq]Èõ+É{¸i™’ +“*ÅûÖ€H-eëpg,eƒ|ÍaJtžŒ/dŒú*Λ¢ 6ºK2;”‹x'.QŸ[å ÌñÚ:ŸÄTß $$¯µ“Í¥¤·4UA +~:Š0NÇŽŸÂy¨r“Ñ$85¿Aš«`!¨WÄF'*nNÁbt*Ú*¼ëëÂæ;ŠEôû”ÕaÇòõT~ÔÖ“S4Ÿò3<5×Ø\ÛJ´Æß&æ–“O=P©[¨P$“Óµãñ€ èiªš_`Ž.Šó{h/"•"v¥¯CŸ)-FßE¶ÛA<Ýï KF‡é9 ‚'ýøa¢4*$'=ÝèO áequGf0[éÒ´ò¢ïÑÞ7™Ë©4€ÐóØxâ%%Ì:¼ã/º.@ªã#)NˆÈÌaÀSt–k ’»´jˆ5b;¦¿J;÷Ò±C°7·ä°ƒÂKŒwA¹5S‚é%8.nN`ºê9_Žû¡ôÓ;Sæüê\g|¢Häae#§û×çÛu¦;¯ºÖÈÊXšŠäo+7×m4”°‹ª0Ýë#4åâ8hù‚˜RË9«»åì{°S©ã£›ªˆ¿z rª“ÊûýÎœ•VØÖi!z_)õ¸¨VS[i²sõq£Ë%®µe?åw«ìbØ-…97Á |Êš aü’Þ[ +4%Å5k£½02ƒÁw¿b¶8y<•«ápÁÒ*Á–Èp«¯,”&«‚rÃæG€Tëƒç¦£¤å¿”X{Š”ùH;_ÕZ ¼ë/i)ï1Èû£.5n仯ðå9 =)ÂéÌW%^}@|Ѧ{P`Áíea°,pS L§Ü”üÚ®Û7CÖÄbÀtÝzÏ3$rX§5Ø¢Pü–„˜jW~\\{ 7NìySE¼9 ]ºž½"„i5¿ÓúÅXôxBää\„“y”\á¼¼!‡k(MÂÖL]*/öðéžä§FJ{Y<Á&eš¯lõ‰Ïƒï…Ì‚+üŽŠ<Ù@9vOŽ’¤ä[RY·ZßUMZûp4–DagPcZ‚%V_©Þ\;=MåWÛ¾ÖG +›¶ƒ¯ñ¦¯<¢—h¸E“;Ukê ñÏCX ™¹&]U;Ûh VýÛ›ˆ‰±È“pc‚Ûùí tTÚ½JŸzõE™ ’O›IG©ÎWð€A\~a OÄãö!!Š×K+˜eè-£¢~½'‘Þ$i²º„‚&ᩯ† þï8^%:'†Æ¨HÆè cYòÝEMÆä˜éb§™å>à&©/8!¹ ½¦e +J±&éù雈‹˜9›âÆæZue)äG $ LË#[|íÕϬ4ÈÝÕbO +€£AÚ¤x8mw›þÖµÔ„±ßxèÍ#ºaýªU!˜ù´TßN.ÓÙÇ-É™Q‚«iy@ŒWc²8qá/øç ‹ïåqYw'`:ÓN·ˆ=óC$?Œ¸m¦÷öÕû—ÂhÀSx/JÌ.Ló±˜× +*¥6©!bÆ¥$ž)ÈFå¨3Çx=H3/xR ÎWGzÊt¡Dc€Ê'ÒHD´öXM-®ÁöpáØîÐÌ’!#ŠÅø*ÒÕ Íè/<Ô¢8>§Ð†ó÷‰rŠeÀìåtѦ’ ¾Lñp m… U?ˆ+Ã:N¤5ûÕt'°‡¡†µÐuî¸_‘ßçêZÚÃ黲s™x¸ÅâÉÚ¿dŽ «K²/gº†™xÆÄᇤ'Õ¼bpb4C¢êš×²ë”€¹j6‘oÑ¿š…JŽi8É—©ßNN1˜ëÑ]l€c²ŸHFç¶îv/qt¤ª½ :[¥§ÌOýýÞ6ä éè­áF2“¶ÿ™ ÷•æÙy+àäjLã,Æ«J5ïr{òZÄ÷ ݆̃§cè‰áÕÏÝAj¿©U¥ÚÖ­c¿jdO×h=ö–®¸H*í%„Sb¡Î¦Ö”2+½22Êç(&ƒCWœdQ÷ßCÅ_%;Ù*Ô ^õj'Dx÷tÈ6 +½ŽîÏ>¿ÇrøKKíùƒrÍAfjxy‘ ^W_ª^ø‘UŠäNGReÈ\®v/ÖVö†¶Rú׌hÉýy3˜Œßc¼b'óÑl«ð‘Ä›k,¢°§ƒ.ˆkx„Kªý( 9×^ÅÈüsk%áIÔ5fð÷ mV:Bô— óütÑ×LmÇIL£F¤ê\@ñþ¬d<?©Ÿ¸ü*Yáv°8/æ6²¬çYF|±¼Û(=<èÝ`[AbÝdƒ#´zäè|œüK÷ŽUŸF¡Öt õÒyŪ)è´rSSd}ë"`!ê÷”Æìê×ÑúŒïÅõ +…d«…œ#£}þÂÀÑÜÂG( ÑhQ/Um+‹|“·^±OI$ѸÙ0ãÆVèþ )ÆJ3ÍLJ_ñ·ÿÑLÖ÷¥Ÿn­Þo”vÒJáØêqmìíçâ%Á­Ãcœ~ªzVÈ‘søqÕ g%ŽQÌ4³æ`£E–/T““?§púyÂå[uïлJ÷ödhºHÐÈÜlM~MTüpÜ„Ÿ[,1|-iÈÀ…´²"ùÄûø„pÐ ŠCCà ˜ÒFŸÃ^'ŽI…42ñÉ…Éš¥†¼*sjx'-ž¯ÿÌ`”Ú¿Èk¯‡?£ID9/ø†h wÍ_lÿ’Z²T,Úy(Â5ù ¡õŒê}ûÈÃ9'¹õ_dÐ]ôAGò¤¬J\YL¶ÈÛ×ÙøǦÀ©‹cÝ›øõNÀ9nÌ;­Åyç¨ÚðV‡., HYÁä{»[úœ„8!\V\¡üè<‰'bÜšDÏgw—ì£;ÞüÒéYÀõ¥"²AL$ý,ÇÉIÃÊrôH™i3>¨¶‡¾sÍnAR~§Þ…vXI³eÙM4.ñT §ÅÔ—³­:×÷öZëœnžŠÖ¥a£ð¬øyHi:štú•YŽÝ’-h¹Ò7‹NQNÅ"$:í»›{fžòO›©¡‰¦œ×µK‚7“½au@J$k-Ç8ÿÅœ*G£uÐð‘ÂF³c|&É}UëVÄNlƒÚ÷‰x^±EJ“9[k<S]óØÝîDÎæ¨ê.Ê~PÓž­üömÍnOõ)-àW…kÖ“~(>@¨o­*ˆ[eF¡Õ…•I@XgL¡Mdæ3•Ï\ÒúÚÓ!™JÕãÁuÃQš„ˆ¸q{sÍÆ£‡µ&7š}ÀKUL»_¿øŒ@ÎÄGƘÅy +Å s?Òr&Fd¿Ä6ë&>N´.Š ¦¾1:¹rP1ûØ——k¡f)ØdQmŸèÄI BÐä5Mþ¦1T¿`m[;­z!î_µ±=ñp)ä5^Išõ@ÑðÈ š¢žAò'tG<ÞÊÁæa¯šm-mn(ØdxDØ‹o=€ôœr‚Ãl( µÔžÀ¥V´êä¼ ‚ØyÒØ% +‰|¿"]ˆnŸ†GhS”C£ãžä.%^=‰Â žš| È%ÿÅ%Ÿ/†5¥ntnt I-¿ÊÍÈ.-ÚŠ +˜4ƒ¿à†tæ-ws(›¢ü À.}!Ë•™ª^‘ 805D|~ØfÌWŸ½æ°›ã‰Å9ãqÀy[eN ù~TÒ€J…gD›¼à%HõŽN´W¤Vê Ü©&QXS²;^Æ#~o ÄSÙÄòQ¯¹Omº¿kÊ–»{.ŽwC«§Y¯[Ý›H¤Î©:¦1BQäcÕùV‹jzˆý“#:^£[~ŒŸ¬Ï¿7ûKWÙ­\ÕèþbÔÔ™î=ùµ„ÔNÎÎ4i¦Èö1häêZ:H÷ÈñÌ«ñ 0¦DR>BÒâ2'BIζ:Mˆë¯ÆZg­tí´š“I:ŽÝA_¹ÂXÿ ¾09¨‘©RI¿b»Ún¹bÕ]¶4 ê¬=/û(ª¢ïŒçÄ„F;–#ã1±¢ÊC»;*æÀ‰®ëÍ­ÔÃÅmQ I’TaYXÉßñ–#OÞÑÓÃÅÓ%”3<¯)>ÿ¸³ÜM`®C;mãð%ÿ?Äél“•òAҬ̊X ÏróüÏXâWàË’Y¤Äi0ƒŒ¦¶zšãÔøª~MÒò¦ôW”¨¡½ ƒ.W³t~ß Xx7 ÷Çý¦8•fÜ®‚’ aø÷¤¢X”dŸ›¿]c5l†i¬ro¼!Q@:Ö1«¥Ä1ûa4±µx”^pj´9KTë‹}¢6[}ßO"ÝJVÕôʼn»ÐŸ|†ö©R<3±CáBÖ°ADæG.îcZ{ÃM,—ž•Ÿ/à ËT@À¥B®Å=‡êêDY–¸Ìén^uÂ]_ö¨€·GÀ›fNPÄ„¡æ}ì[ÊÀž¤/Rø`Ð4I]]õØ Óû¡{%=àÂüc2‰ó‚êì4Ÿ +àé%.@”ØÀÄZPÑ}ú¥ÄÝØÇ<†,2xˆá+„P À:І¢€XH‚9É2¯!I‰¥“–mõ놀)ÓLvÒÀªÊŠ‘¤®­‰ŠI¾ž´ÀJ€-um~5SµÏ?¼‘ÞËxXkDZÎS§ꊿʥ'ÿâA“EÈz©Ltª=ø½¿ˆÀ¯’ëÊ›2{@?ï5ºûšõ¨N …&øºòȨŽ3HKãGš‹6hXle¡ïÿ–kMžÍMxßqhìàV…Ú¤ki1IƒË‹ë°ª¶ƒÊ9UFmwY¥YññW>èYM Ð7u +Ç:êhפ­ߛ֙C9߇¬o“‚/¶z>‡”8Õ"¬pÔ"8f@xk©óí…f¸®söšË‚ý(†'ï »Úƒ½pLjt:1[ɘú‚ËHâûŠK¥Q¹ÞAH)†3W.‡å¬ÉüÖÀU7¹þ"ݨ²_mz$(®$åÔ^ÕìÊÆŸ‡EÄÆvPºÄ¤7/' ìl\du#vتç¾½ììÄ“QP‹qH{Ä$5ƒlíÛóyïd? 2$yá9MLºG%[!/J™Í2an¶ÁœÞOz~ØŠ9@5ꎥ;V7ÎF FsÕàd—ûãת?siÜ5$$éD_j(¯Ü‡ËOÒðBO¿šq€îôN»#.Æ/8ZëùkVŒè‚¹ép›ÆjÕGpéÎØzÇöÛI9´HÓ®"!ÕJˆá«OY¢Úîµ5¤=.J×ø2yØPK0úÍÙÃPI¼ ÌIñ$GÈ^˜ÆºÌ‚cý%úE˜òï„cijñ¼•9‹ž9Ñ’l{ˆ‰$ 0¢w¯¡&jjia>’4\¸ KDÃ{pÊŒ#?ÓA þ0›9 °ñ-D>"ª:c?ܺÚ~†‡^e55¸l +:kb¾ÉLQÒcèâåSŠÛ€ …l±Ã{Y14¯ŸË#Y‘·IUHš6‰·'&:,q[ÞÀÑçºËÔg+ñA¼dÖ/LŒn”•ÿRÔ›”È€ ñ²4ˆŽ7åÚƒRÃoíئS[›IÍqÉÛ³å±FÞéÛv´.19÷Ï.í¥+åh¨>ÌíŸs”q×0u\—…Ãt|<ú§´ä ÞœJSiën@-ø;`®=ô!·þö»$¯ u#îò>(5~¯ìÕ{ âeÎÈmPHXÊ¥í‚_Þ…‡ý”ä¨H*ùÈ*ÖPÓT¼žÚ´_¨­ËÓ9¼×0ÍäúRóyÂò”ë¥k#šLkF@D,}œÐ +ˇ—ÕøêMCEýŒw·òÞPðÃ]ï-¼5L-§Ô²%\ðd*]®K¬qtmpMó¹{Â6Dm1Ð[2m¢ºûw*QÝd‹Q“÷\ÒBq¶˜™2<ôÜå `ve¹¿*9GiÐÍ + .ÓÐ']ÒÀ^Od°â®D—üå„,?#ÞWÖ³bRªv×èSž¼˜Î§ÁØ$ôÊ`mñ 2D=ón“þ´ÁžD㔹=õk½IPïÅvƒJ<¨±ÏÞtݘÍZ´G U^W0äõ¬’”¤¡ÌšÙ=JéSQŠT#’åOµŸ>]žAß÷åʇȆ³Z!“Œ®Íïå>÷Ô‹fÜ.å¾Ó;ö§h gXUãÿ‚yXÛ%…6,˜Ä™T¸«úÊ*1²ö°Ò”"‚ï3Y¶m"ˆ†s¸µÌ· Rþ;ÕõµU§é±8fŠ•ì0A¾Ç¤‘oxZ¼ÒÀá¸+ÊNVkú÷#$ Ë£6\4Štó V·‘D^2'lRw‚ fÈ2Ñ[£Ø߇`Ÿk5Ñs kÜË·g¤Ãs© ÛÂÍÝÍŸ¬B?1 |k6*yf¡3ñÚP‘|Büu+ÁËNõ8XÄôÈä‘¡ù EUQÊFÿµð¥¸ËôiÔ2¼ð`Næ}ïT´?AËÒiÎâ ú[¼5¿«-ŠCLÓÇUY$ÐÀéëh¤®WNÉJB-þ¾ÜaìÚvvÚT¤‡dŽò[µ>Æ–ø|sÔrèCd `¦Ÿü^†ÕÁÊãDÃ*ã%­ã»òýÏŸ‚«ˆ›óñÚ àfX¡6øvçŽÒ]©Â—ñV¤M"BÝèù£=&w>8Kºä*¯+– ¡ oèKᣵ4æx( =¾$h%H +£VâRÑ +ï82Ö&)°"¶E;Ü´”ŤUYvƒÜìVZ9M*­µjQSJ­)‡Ÿï@LH§Ò5Èþ¥ +½~ÒoÍdW)(Ö€çÜÀæP»€Zø¦ÂP³¢½OU®æ’mèß´¨§raäÓw@„&7ìVÛÌyå\çøiÃH47+ù׉L%wÃ8vZq‡#¨¿S·,È_N ŽÅG ÚÅ•},%šc)dù…t1Z’bw' Ý–ˆQÞ’5p4#19B¹Ô/‚ÒÖPº¥}ⱡu±âv† ×àk讌z´?O «¢kês*A„1Øb÷F–o(Êf +^e`˜Ö«ç˜Yªó[c"VÌ{ƒÝŸæDDùÛ„@†€Q"é&º±s±tÞ¤cð>ÄÜÚ.èíÊHÁçÛJ¢b^ûY­&è×`}»'бTZ}¹ë&½ÑÞæa^бŒj7Y¥0ßbªÐDý¨ªN1„á3G¾_²Þý&1UF·b üÂO|=ÇΙדnj‡üGÀ´Çδ.Œè1§ÚÖ%t|šx¨@gzM†ª)dï2^G!¥nÿ¬¡Rý•QE‰)ÖÒ•*Ñÿ}úÖ€ÚûçRTWˆ¾Ü’ŽØ¿¶eŠ-(ÒØQDñ +µQu-W€»×4~Q.£ÎÐ)ÅÈLHQ-Û(èÖü¥> ø|kúÜ„X`Ž×¾®º] #.ëwx+«;.ñml3ÁѪ۰çµsߟ֚ÝÑ­ÍÃà³ +:Ê(׸B®Ó'=êû’ýeÅ9,†`óÙ‡{ß%€ª ¢0<ý}õ¬YâÁ}‹­i@âËÂTÃEóEÎRYöõžN Gö¼ =ã4,4…B™Øi:ò 1tüʼnW¡©Ç½?PÓîºövVÓ'õœ±éÞ"Øì ‚´ñïÀñµý¹• ©JÂzùíž,JøÄUw5ç«Ø«âu«”›<k1%zQ1‚¥[f15À“¤'¦’Â3÷ ÙÇWuùµÐÐ%ßï7iåœG¥Þ@ñ¿’|ÅÇåý©G—lFê¾LŠ Ñîᄹ,¼‹ Ë°—š‚„³³’%MC+–:ôSŸO±ös£]ƒ6&#r´K—è˜#kD—·¥KØ¥ý1ù›Y|£¶0› Ö!ꇫ“tnÞ€ðžUéBN“Y£æ›Ni70R2ÝžC¾«Ü-{*ý“-Ž“˜Ñ +ˆ¬BÙp:©Ñx”Mî§?ó}¢Ø×4¹„“ùïüGßßaWGÄð«àøêÖ +«1,u6AS£áx\|czíR¢€oÀbÐ.P³¦‹Ý=Öö+<µU ZäÍ&zÐÑÅReu–«ŠŽÈ*Yìü”-RGû>çHHn;åSÃêFR"Ìf‡Åfðq¦-#†©cE/NX[\VC`“e’UWYþ¶&ãLÿîC‹Ü8Ëw°šhÁÄ‹£¥±‰¶¬j‚RÂôœ½â¶÷Ñ!/¡àÀˆ´7D­'b ß½¿ë™ÝRȧ/5ÈáqL ÝéõäírâŸÏKªú~sµÀÔ«)ôh'¢Ù`ñ:~­(IÃÕmc+Õ‚Wo¿ZåX˜§™†öŠ9£›à„V×U©%-½˜‹c현Tü’uC|ºõÛ$Y~ˆ^(c­/êE)^Ì>,­¬ˆ•Â‹Ùý¤µ†ò\Ù9Ï—›éu¬#~«ùn_©38ŒàÍ^PCÑ€dp_:»’óÆŸÌ·qÙ¿H(Yï7çüX{yÊïŸw[€°5zf[7 "¯sÅvÅô̳‡Óá2 +[5ÖðÆê_ka‘¢Þ÷£ø‘*q¥=¡R4Ð/@™jÂHµ0M’$Ùþz„ +˜É¦p8çˆC¡·š•òÏq0ÞSGD¼ÆSâT2J¹Ôi­¸É½°½äA iÎáDµ9)î“>oâÚàЂ,®DOͺ؀¢À¨&¯¬±ßŸ“ãùí„í½O Ä[¢:&ßQC—Ýåy˜1ŸÜ¨^Nò`ϯȌ)†¬!îÍÓ¤~»,˜7Õ$á/°Ûº¤zé5"™4¾bø–ˆÛM]üè»o~E®5p‰ñðJÌs¨{•moœäÜ%Ö¡A;›<Ñíô¦óñÜý¦¦@=®Ð@ZR¸ôGv Ö}¬ÇàƒO³þ›§—ÙA´|:÷©‡ž™Ï @pmðïÑçñ€R Àw<—a°Ý½7#øSBG8-(v> Û žq<]ùÞÚÖÁPdöÙò @JÞâõ•WÑ2|¥ —Ê„s’¨Ê‘i% Ìî3² °6“NP&0ž>>ÀI2åOø®¾Ój¬ŠÛ¯)ÒÀŠÜÚJ8¯Öß*fzU;.ÏZÜ$ÚùdL±’Ïëì·~‡ˆ‘#_Úq@ï1ÓÝ)§/f V¤Â†~’ŠÕ.-e`Yë1†ˆÅ&ÉÜyS¬S<Í„c)fœs Ò†fÇßyã·=%±ÒD=°©lø” ⦱Wèz©ßš!ÁÁ™ÔÊçÓ_[éŒÌ|œÐÕzÂõlkÜo[Ö>ððã²æe×ÕX¤ñîÎ×þ_¢;ë#7Õ ?q2Þ|~€\áÄðPëÁ'i]°Ñ®(”Ç¢:îšÆx7I£ +×D½í¤»a £ªâ*¶‰ÂÀÜÙš*û(Œõ¤qÁÃåäÌ°[¨.xÔŒHhý {§ú·–æýy澡:ÔuÓçg¦¨÷œ4k ÜÀ=ñïElD+Ž9Ó{û¤Î=£n„ÉÐE:xª»n½†í·ô^j>³ÎÄpbH4_de›Ó^S.t¾¤™_l¿ 3)VÐñ,ÿ²8Änd2€ø»Ì@צÍ*€]ÉãhsÀž”nä¦(ºÎõ§ÕŸW‘ÉÒî#ÐósD–&ôؤžm<[ã Xp.7ôâ(5%ö‘ì>B8‘'ÇÏÉÄ-ŽM%f+ùo0à8}¤{+Ãþ/®ò ¡‹pp… ‚óìô½ÙW¬ÒCF8fÎÞßòä6ŽÓ‘æBVÎÒP,-{DÞBЪðß“úé,¢îN`:¹ ¾ÔŒ/™t>¯‘¾ÀýÝ«9Ñ>á…‡]`5TæÑ’zûvyWX2FüºþbfO–f§>}al÷¨\ÔMê—´ìù¥ìâVPÇsp¥²oøâÇШ›x¨³N O_Ž»N=𣳧ND˜ÿ«ýzZ¯@(5Ic{Çv³cÛ¶mÛ¶m۶ƶm»Ñ™w8wóÍz€ÿ~eŸYçÞ*D+_—‚#ioÛçT¢{?Ø Ï|Xž!ÃS)Ëb×ß[ñ_ˆqM`Õ|)é)vÉEåN”ŸmÝ­ÔâÑÜêCrçéú¡]¶é +ï%,3”1•äœJñÙwG¯üûñšøoeüªyDhéNÁÁϹݎÓRþ ~¯›GßB‚\ÌŽ™;؆r•R-ŸEGT±ùø°ãѶ÷Žz ‡¤/z”Þ‰…3 ¿µf!KÜt[¢áqQ‰(¤Õþˆg§þ¬EÒudV;~_€dr‡çI;17 a £ƒžq”„)b±¿²‡s(…0 +IfLt´& +¸Õ‰]ª¼ÖÀ·ü´¨ˆúWÓž•N€ÓáÚ îËè ¥·I­Ñ—Øü:k b-F”ÛÈØyŒÔLúcÙY># S·ÿý¢žæãþx5¥ÁõëU­N)r×&O¼ë‡hÛ‚$‡Øöñ1j2Ç< up& )æDÓ˜‹Ô9TÌИϦ]ÛûÑ)Z‹HAJ›0ø¼vøg^V}o2Qâ +ŽsU ? ë{x[òq=4£øŠÉTññbEK'òmç±v§9ˆçì‘È$“CXcþ©\“±>ÊG˜m@>¥¼lX1 ©ô¸dwO AþŠEÒÖ’±Sc¸I/cK+–5>¶V‘+"zg1´:Ë™T¤þÎ +*»åMì•¡p_ÐV—+}¤ªÞTžY!æĹ(K§i"üÇ(*wOzŒF®¯’«X`Ž¡ÿ­Š¢ÉÂ9•ûóV[h#´$$£¸ +™*r[¶Â—n³î+ˆm•€Î êËÜun2qÄi"P6h£.ü·T”•OdÉ_ùüånµ~ ‡q#$i5’2ÍçšuÛOÖL[˱ÙE¶IkQñßå:¢_é²w«®º!É·Õ7ˬÞýóÌlÒλª> ^ØH•€ þfuĶgŽÍÆm4N}ÒY‡‰Fð/þM(zK¦COåúë·½Ì\?½c<'}ÚÞu*gi·êhôQ´•Vhš»7ª&º=è8?NI@ý ·Axgz¯fckp5[ü>À¦ÉÍ—>ý®ÂóKÓL†™f EÚ³:â£]åÕN³Äèx÷ú9,Ѓô^¾Æ´m=WäÔ>x ÷"9N‘Øyw#DZ.‰ÞÌi*„¸úR/ÝsF©ÚPS.çYŠÈòŽfb-?F|…í-¬{ÝOžà»ÛTháÜ=ªK8[9öMâ™ÍÃßv\©«ù P$€Ë~*À^ÄçÝTŽ]ÝLyî O¬!±KÔŸÒ`ä÷þ;ËQyC¬¿k¦ÂËᬩ£Ž” Â_Ñ#ý:{;„YSý5§È9N€˜gyä¶~ ËsÐ^Üûlœ'Q +žº²Üà9UwgÒBkÙãƒËÚž½Gr˜u)ÔëÛß°û„{¢T?,Ì’xýà‘Ò$b¿ªép×Å°·‰©È{ÃXá¤,#½ÜPÝ"QL$*/éÆù£ˆ:ÿxrG­Ñömi´Ã. DêBU%ÔEñï˜Aàâ»ÿü V¾£¥Úö°±]àÚøÖfâ¹›rƾÏcÁ¬FšF"¾7+ZÍ4´ˆ'|Áaèp›“GLÍptmL0°Ëd™Ò§l³CÙÊ5ç²k·›™²u•†(¢^§Ì€SÀóþtJ̦ îÒù<‰Ó¿`—+ƒéíÀ~Ûf&°üØ̱iZž\|¾ÙV?P¥QüèçÍ6GTqÔQ—m¡’>Ú߈3ßþ'{ãËDˆ/Ñ`ˆÚbNŠ"{YL¬ÇY‘Ô¿†•†´É»ž8 UÅt"gæ´LþÊÝ»åE´;aw#"‚Æ`l1naO)º +èòÔAé›ðöÖ_ß5Xuïwo%~’KG`4÷B9MXÄ—›Ý*¬â=cÉwú¦¶­r±¼§˜½ïÙ ÌèÀXmgsÌ{ná>³.ëÀS±¾ü¾ºÈÙ”¦ŠQ®Ÿ6È4ȤÍzÚ9Ú—¦Å÷K\ ìkCì«›!ê;àú¸èy¢Å + +"¿‘©ÜŒ˜%(–PL•„àà}çô—ìd¸A4HVs_™c‚Ò„µÜÅ‘nÜŠ¡Vz*-‰To­”â 7*úï #{y‚íl¤â:n\Æ>‡áos.ø¨ŠsýE×õ©É¡Ã<äm¶ E±¸@ˆx²îkrŸËÁ}G=1ôƒNl.&·´Mf‰2À4îۯ0ö€6Ñð G¥í¤B§R“Bt•¯º%õĪÜ~ç$`XÞ(ÿ¶ˆphíÒ[, ²·wÄ.„ˆØeæÒ$HÃù”±åá<€;]vÛàr Öù›–ÞpuU“J¯ÐœA£½<ÚÓ¤ïõV1r¿Â¥“e8Õè7Þ)h(²¼Eð¥GðЖ„ñ˜WÒMæ _Y£õ‡æÒËfcØŠ¡ÌõCÒ0—£Û²u—§§äùp3¦~ùÌ[yÔ5!Áy˜Ý Ð-¹9¨ÉŠ%Q-} /DšC¦—jn¦%>HLgùh:âî…¶Bldš½üuô݈°½‹IÖ#o½¿ùði9žìtå‰ò2¯̉ê³æÖ®Ê2VÂ^­.îÔ +ëÿ8±² +òo·Ä‰è8²{ãqÍED§G×æë±ÆöåÜbùÜß°”\&Ü‘ù­òÏ2qsÈÆ°Ûy¾>bò´ÌOX(oÁYÓ‹Þ"4Ù†w7 «~Lé'ƒ]‰v }Oä8ÝMª)Ž–X’EÀ,3bQ*ÞWAš 0 N5<_8%)FľJVßr”[‰=Wÿ:¯&,o/ÑQƒ+"%N†êémü‡*VtŸ_-’È°”´sPàkX‹'ÙÊ‘FâbMüzyixûŸGG1SÝ(&¦F›Å8'Ç9qr«E™Lôð‹ÜÒ{î}pJ‡ç"3„žœ®NÔ1 `2SÚ;{{ÿÚ«”ìŠ÷ ÿŽ¦Ï˜ 1a|67¥œtؽ_”½áFÜ•g/š:EšR˜3²F (´†»nDM†ÀÒUœÁÌVÕåq–¹4òBä£à?;±¿®Uy7-Ò¿£;©©D'eaè;Å:ÎCÂ)n.fï&#–œ¸ˆ2?\Î2 +mÁR!/¤ïmYz'Úò”¦ÀÀh'¨1I ÌѨõéI¹;b ’@\Öq×Ü[¤µ*ýôF£½™ÃØ»ÚRqõ¶›0ý×nD%ŒãßÉ€¦ ]:bĨvÿŽ“U®ïqî{ĤgÑ5Àee4ê}ââsë?†'Jïg/žÄ1àÞ¼–'=ÌNŠ³)—NcëULtbðÏ$ mw?:ji½Í€E4Èê6öʺµÉm>·’ºS î¸£”=~ø$ÄV9N·€ø.Ü.®z;…•ý37Uxõò~Z–¥]5ä´Ñ<ÒZµn•}—Vo)I +Èù#†ð÷†(£ÃÐw¾áR¼­ñ¿ø; h@À‘Ä8~©Lp©™¦¿RÒtª3ª5/0Ò¡S0±nÍ&9=Ó ÷-Áz;¢IrH©3©Òpdl²l[‹}B¿p“šÌN2ùòw Д˜…¥UhpO·  +FÖ—bowÖç'<{†Ëe/>w¤ìºO Óyf4,%[n‹¦ó<ÑȲ’Dø¯7XQ`õì¹;ðkgýÑt{D¯VC|n$è_ +5±)Ä;À†íkPAs~6wD¦l¹Y²˜'À&>)Ž:•„ΊÙtAʘxñI…Å©Ñ’"Vï·´—Á}“Ôl—Üœ2Ê?«RÙª¦» Ñ2ø¡†LŠ¶Ð*¥ÕùÏ•Õz¢W¯íPO!Zñšâ:¡••3ìv{´3:9¨;8 ~†»Gcã–XÇ*ؾƔrõFÉ×<ͤŸ”WSs¤ù€ûñúóRXÙlN|PLò4ŠÒñ£l8¯´Àøî[ë†4 Àñɽ.zšcF­{ý†ÄT¢¸ˆŽ¾‘Ð[™()ä ‡¦f¾ÆF£ðÝ´Z"gº…´>Ôæ5âµlÏâ,¥÷y”¦Ä“1Êe]#¾{Gš!ÓK±¾„OÍ÷¢ü¤ïï!Œ^{ßðÉ‘F'U0BBo÷LÉ7„ob¨AÏqØ5ƒ£&ÜçîYd5K­ÜeíO%:Ó 6™zD-߹̫\šM07œÄûga\)³?ÎÍØU>Yë7“ÚNÿM³ƒ†yŒµ¿_asáL³í|¿Œ‚Ñi(¡Ñ›à¬ìz™XHGªáO\DzŠ~o9EÁNº>¨¢r4!Öî€1/;{k=¾·¥ïTRëö îì½:¹c‹GÃáÐÙaí¿[ò!É­©Ð†Ꭰ—fÝ}†c¢³R[#ð:wAò»p@‚Ò@NÞ†ÓDùNËöî”yRbÒ%y™ÔÌњǡã0-KdiÛBqÁ+a`½£é6!ÆìÂÖ÷šóø53"%)k(h0OGµž32Š!¯‘¼ù_“Û’¸6fÜYײ#–=MBùBo)QI¶ÍE3Aè¢öh(‘‰±9ŸmûÜLH©*q2:ã¿}45«1Û¶*…Ë; õq4—ÉFeÈ»r-daº’õ¿×X}ÜÁÈ'ö ‚TjÙTûõ®Bç’¡X5>¤hŸ`Ÿ" ¤pñ5Ѽb\*]–Ù“»$BößÓžøãÊL½bð¨Æ@¶x}€×)j¹ïÀËŠh4HÄlªA§k7÷¥ßjMó*ùf“VlÜ%´þ¢.’£uXà}{ÁoT˜ ’ÓK7ú‰Éñ-5?»™ýuª¦ý5G¢M9|¬à+´¡ï˜I¯qRÒOÖÛ‘ñ0Dç"fb×a²ØtÿV¤Ÿ@-¿«¤ÆÐ$u².~@baæ|*¾ê3©%…îG÷ïã´‡N‡ ‰49‡˜"Xˆ¡|S¸ßÌFÉW壓ô?eÃýåL£Ø&tb^Ué.¸2N%æ’äMÖOw”¯çe/Öʹsê"›Y #•|mËMsßÒÉYàœÑLLz™63<>9ŸšwßEBèˆU¾D¿îÁö{'÷·n‰æŒLžkp±磚‘rôCÖP€³rúgœ§câˆE$kš¿Ÿ,­×©à>€ü3ªŸ2ÈÛ=cuT¤ `+š«6E@éú*ẳ~5¿¬'Z>t %š=:þ¤RŽeìþ«nO»ý’y0HÈë4ÚµüÍ‹;ô¨K‹iþzª +¯'l­Õ_‡2›.vèKâÔ€fïø¯âˆÚ\ŸÙÊ¡òËà.¶¸iAìU„‹Åss*’ñªÛ +ó Ë.ºÞJy'k<¬¾T¨u®rï p¦±2Äéyš˜¾Á0^øÓí ›H v,¥wó!éùž1ÄVûr#Âp_JI´¿4ŽÎ¸6ú˘ì{2{ã• <[—)¾Íj°xÔo~y‘S¿mäó¼—¯ùh§NWp¡Q2¬ð‚‰>÷ËgCX ÀõVUé³½æ·ÝbM†Ðñù6 kh*†4¬† ·ÚTã’#­Ò<÷òwHÜ2ÈAœS¼WR¬v"«¡™Ô1í2•¢¨¡;ŽÞuE@L ±Âà‘Œ”ª^4þÕŒl«áÇü̺-€¾¨“\Z™Òçtä %p´§”î–©ÚËjKûr¦ä¦¥Æ¢[~ÕÇÆêþÕ&÷»6øxŽÔߤÐ3òÛøñøíp…ò¯Ý@åjCŒ,:°”v—Vj¶ ’/—4â3Vÿ¢§öžÛuá<¤ÓÄø -Z¬Å…Fv˜fU*¬ê&'°áÚÑÌÖÿ«&45¸h+Ë Ch/äΖãoýÓ(…§A]]fçþ$ni6ñ–ÖaöqRÜ:¹µÓa¯yÌ]¿jñïšëté¤ÜK…ïÚNÝR/RàÚ¯{|Ý+î8|H@bÛr®fEéÊl.°_½€ZNe‚œæ>>îI”¢kf 5ùùª‚Ÿ»ßÈy˜Ë{2LC6þ¸ôØÅ~Û5 7Çíí=E4ÅÑjè!¹A=Ï·tg åƒ&%§ƒ—!~T‡ºÀ–¾U§/T1ìåoù¾—±Ú¨¿L—7ÛÎ…B»ñúð©JIª‘Èã¬B6ÂÀŸØ2¥7j•C†Ðâ.ü”3"OBv U‹C9jEm{‰ü6ºJÀ¶¦Gáà•PŸ… Ù(úV…yÄfö·› ²–“mTèÁ’½ú‰L9--ö´»¿sµx#¢ª}«q‹“Y*ÔV·ôZwa§:Tu$~ËÇ!5‰íåBòdô’µÀåŠWü©æºÍ”þ†ëÞ­ËêJ‘kíOµUEÉ0µ³ât¿yÎhÂRUO©x ç&<)O±\b:EÛôØ$Jpÿ‰–ÎÍS|Ût 9–dtþq6 QˆÙéDÐIÛß0âFò'¸JÌìY7¯»°:}…çqy¹•·ÜçüŒaÊ~oà韪Àæâ6°c5Œ#MóbðAÖHa5E18G:*ï }Ù5âìħϪ•Ü<—,$l]ղؗô ümn]78TÓKrº +eÁ½õiÐGÓ8¿ÙñCÊI´‚¥º]u¯˜Ôjù -JtáBÊk(WI)Í’ˆÇ ¨kFîÈJi…Õ FS„Éãâ…—¹l;£—¬(¯cgHÖ5§ýUj®¦›¤ÞNX*1a"˜…J[å?x¯5Mï@ 7‰íɳ't"Mrmc §Õnœ€rÍÖÔ<.ïo°öÝｦk¶åÎM¾×ÅŸ“p40¶Y¤ÉçŠÀ^s ëµ¬d>Rõ~YîZ_Ä둹v0§Gm‡‡N®3çï7G$*›½th•ëùý¹¡Òg)ˆ, &ƒM€¶ïÎ3«yÔ&o¹Ù›ïu–ž4«ô,öZÎOkÜ÷ªÔD%«†Déz¡v?ò‡/óÀ; Š'?§îºËcšý‹Üè~Ü÷.ïs +µ(à\èaª +E‰7jŨi¥oòƒŒ:½úþ·cêSJo*>»u+Æ#@Ä«áb\[k!s&D “‹Ãd`È´Êëš”ïhc{·5?ú¡iiîÅbx[РƒÜ¸²à‹™÷̾`_rª»“ž!R4>‚K]J…wvýqL\¶Š– þ AÓ!÷¯Kÿüê@7¿-ü'²ØAAضӃÖe ¢Þߺö;ˆsôÍxyÈDUE…ýøsÙæp£/kït6ÎîX/Ûžua·Q‘\/œ;^tøÊIø&dÖC+ƒT&a“ļMØ{$UT‘«ø.ÙN '”ýBþTŽiÔ|us)î³”n2s2tLn”Óš`$}ÂlŠx`j6#Ô—Vn3DÅBƒ¾Üâ")47#UtùÖRÓ“³8‹û‡mÂq¸ÀVôYÅshž£ºí¨ûöàÂÏÏûºyžkkÒ;ÔJÙ/c¯º6ï,ø4ë$ä[Ff&—8ãÔOø0€#›ì'L¨âJá0äï‚ž=Äï y¢z¯ëmjMU(0i´ÓòÁB­úg”GX¿‚rë•{µ)ùºà  ×·f"Õõ®‹‘†­,``ª“}BT]ºˆ»Y®ì}Þ´¶Ì‚i•Æ´A„]|(ìÓQÍííê—ÉH8ï +j!H·îà3ÁE. + ø!{mž/ƒòZú+p%Œ«u–}Fcí¿ èýˆ/ì…Ƶ1>§ÌM)ÔÐ O%Sýù8½î×Çâõ‰;‹¸¡Û#;üe,ã ’ÆÄ\õ0þ#tÎȾ³k훯"’ÃÅÆ{Ã÷âJÉt¿R4ú‡£da`{ó‚ŵ_Â÷ú¼*S½ŽµÁ˜¢eŒñ'»2òãTÊÀhÜD7Ð š^BðàF°²•B„z@jø­z„…Ä÷z‡=éYU¬×:sB®gæ#²ÁÛÔE·Ù"-‘ +dˆür4îŠ$#œ™/à·Ñw $–+3¸]Ì„5¼T87Å]ý—‰Ø¥–…ZPŽü¢ X¥Ì[šÿ8™XpÉþCi€ó`KpmMƒ*­y¨À&ÕÇ*é\—l¹ïˆü° xr#L?)¨ù¹kvü¯â|V{þ–aÀB$ÇÉÎàj`ñh›Îëæîõ­QUdj5Ë$k>7¦|©™¬âÃöõÚ¾¤,ˆÇSÎbÎ=¯ 6¢ŽIÛž‚2üúð?÷ò)CÎ|æ¡î0)ukt ùþîo#‘Æ$÷s‡³Wgª~„ŸÙñôÀԥ;ºaâlèQÌãæƒhË›ƒÌð`¾ªD`;˜ßl)Zþ¸+‚´öœ¸"nƒbî…•Wãìˆý2@4Jn²k‰Àüš>,¶èŒo¯×ý½cSò¬‚~NDD«TNo,ŠYv£ÐƒÒ˜÷-R¢%d¬ò™êe‰»CÀ÷ûú”Īoà/ŽâÈüo%×ÄR’1Ãó—G$TW~}Úæ¾Ó¬r' i kI +Z®§Ñœ8Îeä¾ÏFþ±Ã,ô\5ˆI.èÑaM 4Ž´mÇÕ‹èqWM‘±•î·egcØøí «\[þT +¿Á…æËU¨—xÙLDÞsäÓš¨Iÿµíe¬ âæN™V¸åJ‘ÑÏn§Y ÎY½–\fÐN€¨ ¡B‚?&{¬D·š‘zµÝ¥å +Iö×~pºóE¦f}^!˜tQ°Ù’‹ƒEäì>‰ n|'ÆV²5D9_äå‹7â̬FJvõ˜2È­ÛŒ’ý;Û£K¿>Z&ú‰Àš¤þØɉ,-¯,Yت–=–ÏÞáÆX8?¸#…m èÓð¥žçßèðž–u¤<5åÑwÒ6¨´ÍÔ™­×#0±q“²Qý‰±ÀåÙëã=¥—;1Â&<ˆ2’¨ਛ4ÿ1=´ˆñ¯”uà t jlÔ»<$¼³lt‡7¶Â~ølRh¸¤Â…ò^JÁuò‘{{#Xè +| f Ég¬,=‘¥vp‘·xMŒé‰_b¬5 +µœóû¿ µ§öÈ4¿À#è¸?§ß7LíXʳŒ”ñkÌ€Zî»vSLR‡û 4 ƒ?&4 =cwÓ™7mÿ­8 ‡L¡ž~šËmé0Rƒù]N9ÄO:;e0vÈ(©6‘÷ôŒ÷ÃæÓ=ÔèÖ‡7œŠ?­)Í'á ž àÇ38ƬpYBà³Â|ƾC¬D?ÖD‡§-QÊ(6ò˜¤>Œö)€*#£˜òDUdùªé³ÓvU‹ùaaæ6#÷7M‡jƒ8K §ZøP‹øÕ‰ãw© 3ê±,ÄaAÅÃÒO¦Í•Ç½,R!®(e¡|ÉÒj£_µ3b: ö[Ï㥻w©{Î u\öAøo†êm¶¿ïÆñ’8ÁX˜ž‰’ÍèQR^ÈåkP’AÛa—ËÚwÄ*ù™ü óñ»v̽–ÆÍKy ¯_È„&ÕýÜý|ÚòK6ã¥L§ñîÏ}¬O?2Y‹gl$mÓ¢ÛÏb»\feþ]'ái¬}n¦s+.Û¤TíD•6s²rý ´ ·†döNQH瘊Ø3Âs%´‰ ƒQ”Ìæç(©mIÊé`1‘rCÓ)NòÒB‘,›÷4JÓ‹d—W]M„=beÞºe(Ë ÄE&›fg¬esÅ ×"tO†2ÄÎБ.Õ(îõâwwÓú¨e¡Ž Úà"šm°Çó" +¥í’bWWž^¿§M?¼ªßªéë;ëš<™áh ±Kñŵž¢¨ÚÆóV1îcÖOÏ "ž³x4tÅ:l¼t@i×uÅ«»‡‹Á0“öë]RϺM'Ü>Á™?#ÉABlž=fÌì…ïé ÚiózõÔ¨¿!…+°2Ô’Ýzôµ¥Îb—B +y‘üP'càÜ^M#R°·ñÃ4 {LJ B«œ»×ën¾HïŸMc–9|þ*S5ïV®ñKãÁ“üvÚJ¦‰‡’à°áR‹ÁPKw©ä;ÉͳðåH-ºOÖ²ÉâØÉ*Wü—¼éýšö•p…+èó®a7AÔºº;˜âR·~4ÿÕ|S®‘mƒ®W•~ ©Ãâ‡}DL×WF5J‰åéØ|¨i÷>#\2®˜Æíß»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 +700 0 obj << +/Ascent 708 +/CapHeight 672 +/Descent -266 +/FontName /ZBDFML+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 701 0 R +>> endobj +2108 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 +703 0 obj << +/Type /Pages +/Count 6 +/Parent 2109 0 R +/Kids [694 0 R 721 0 R 731 0 R 786 0 R 850 0 R 912 0 R] +>> endobj +941 0 obj << +/Type /Pages +/Count 6 +/Parent 2109 0 R +/Kids [929 0 R 943 0 R 957 0 R 968 0 R 975 0 R 987 0 R] +>> endobj +999 0 obj << +/Type /Pages +/Count 6 +/Parent 2109 0 R +/Kids [992 0 R 1001 0 R 1012 0 R 1020 0 R 1027 0 R 1033 0 R] +>> endobj +1056 0 obj << +/Type /Pages +/Count 6 +/Parent 2109 0 R +/Kids [1041 0 R 1063 0 R 1073 0 R 1078 0 R 1082 0 R 1089 0 R] +>> endobj +1105 0 obj << +/Type /Pages +/Count 6 +/Parent 2109 0 R +/Kids [1097 0 R 1108 0 R 1115 0 R 1120 0 R 1129 0 R 1136 0 R] +>> endobj +1148 0 obj << +/Type /Pages +/Count 6 +/Parent 2109 0 R +/Kids [1140 0 R 1151 0 R 1156 0 R 1164 0 R 1172 0 R 1181 0 R] +>> endobj +1199 0 obj << +/Type /Pages +/Count 6 +/Parent 2110 0 R +/Kids [1189 0 R 1201 0 R 1207 0 R 1213 0 R 1219 0 R 1223 0 R] +>> endobj +1237 0 obj << +/Type /Pages +/Count 6 +/Parent 2110 0 R +/Kids [1234 0 R 1239 0 R 1243 0 R 1248 0 R 1254 0 R 1258 0 R] +>> endobj +1273 0 obj << +/Type /Pages +/Count 6 +/Parent 2110 0 R +/Kids [1265 0 R 1276 0 R 1280 0 R 1284 0 R 1294 0 R 1301 0 R] +>> endobj +1310 0 obj << +/Type /Pages +/Count 6 +/Parent 2110 0 R +/Kids [1307 0 R 1312 0 R 1316 0 R 1320 0 R 1328 0 R 1334 0 R] +>> endobj +1346 0 obj << +/Type /Pages +/Count 6 +/Parent 2110 0 R +/Kids [1340 0 R 1348 0 R 1356 0 R 1361 0 R 1373 0 R 1378 0 R] +>> endobj +1388 0 obj << +/Type /Pages +/Count 6 +/Parent 2110 0 R +/Kids [1382 0 R 1390 0 R 1395 0 R 1404 0 R 1408 0 R 1412 0 R] +>> endobj +1423 0 obj << +/Type /Pages +/Count 6 +/Parent 2111 0 R +/Kids [1416 0 R 1425 0 R 1430 0 R 1449 0 R 1462 0 R 1482 0 R] +>> endobj +1499 0 obj << +/Type /Pages +/Count 6 +/Parent 2111 0 R +/Kids [1488 0 R 1501 0 R 1505 0 R 1511 0 R 1521 0 R 1533 0 R] +>> endobj +1547 0 obj << +/Type /Pages +/Count 6 +/Parent 2111 0 R +/Kids [1541 0 R 1549 0 R 1557 0 R 1565 0 R 1574 0 R 1583 0 R] +>> endobj +1592 0 obj << +/Type /Pages +/Count 6 +/Parent 2111 0 R +/Kids [1587 0 R 1594 0 R 1605 0 R 1609 0 R 1613 0 R 1624 0 R] +>> endobj +1634 0 obj << +/Type /Pages +/Count 6 +/Parent 2111 0 R +/Kids [1628 0 R 1636 0 R 1646 0 R 1705 0 R 1761 0 R 1815 0 R] +>> endobj +1857 0 obj << +/Type /Pages +/Count 6 +/Parent 2111 0 R +/Kids [1849 0 R 1859 0 R 1865 0 R 1870 0 R 1874 0 R 1879 0 R] +>> endobj +1894 0 obj << +/Type /Pages +/Count 6 +/Parent 2112 0 R +/Kids [1890 0 R 1896 0 R 1908 0 R 1919 0 R 1926 0 R 1938 0 R] +>> endobj +1952 0 obj << +/Type /Pages +/Count 6 +/Parent 2112 0 R +/Kids [1942 0 R 1954 0 R 1960 0 R 1964 0 R 1974 0 R 1986 0 R] +>> endobj +1998 0 obj << +/Type /Pages +/Count 6 +/Parent 2112 0 R +/Kids [1992 0 R 2000 0 R 2009 0 R 2013 0 R 2024 0 R 2030 0 R] +>> endobj +2039 0 obj << +/Type /Pages +/Count 6 +/Parent 2112 0 R +/Kids [2035 0 R 2041 0 R 2053 0 R 2063 0 R 2069 0 R 2078 0 R] +>> endobj +2091 0 obj << +/Type /Pages +/Count 1 +/Parent 2112 0 R +/Kids [2085 0 R] +>> endobj +2109 0 obj << +/Type /Pages +/Count 36 +/Parent 2113 0 R +/Kids [703 0 R 941 0 R 999 0 R 1056 0 R 1105 0 R 1148 0 R] +>> endobj +2110 0 obj << +/Type /Pages +/Count 36 +/Parent 2113 0 R +/Kids [1199 0 R 1237 0 R 1273 0 R 1310 0 R 1346 0 R 1388 0 R] +>> endobj +2111 0 obj << +/Type /Pages +/Count 36 +/Parent 2113 0 R +/Kids [1423 0 R 1499 0 R 1547 0 R 1592 0 R 1634 0 R 1857 0 R] +>> endobj +2112 0 obj << +/Type /Pages +/Count 25 +/Parent 2113 0 R +/Kids [1894 0 R 1952 0 R 1998 0 R 2039 0 R 2091 0 R] +>> endobj +2113 0 obj << +/Type /Pages +/Count 133 +/Kids [2109 0 R 2110 0 R 2111 0 R 2112 0 R] +>> endobj +2114 0 obj << +/Type /Outlines +/First 7 0 R +/Last 639 0 R +/Count 10 +>> endobj +691 0 obj << +/Title 692 0 R +/A 689 0 R +/Parent 639 0 R +/Prev 687 0 R +>> endobj +687 0 obj << +/Title 688 0 R +/A 685 0 R +/Parent 639 0 R +/Prev 683 0 R +/Next 691 0 R +>> endobj +683 0 obj << +/Title 684 0 R +/A 681 0 R +/Parent 639 0 R +/Prev 679 0 R +/Next 687 0 R +>> endobj +679 0 obj << +/Title 680 0 R +/A 677 0 R +/Parent 639 0 R +/Prev 675 0 R +/Next 683 0 R +>> endobj +675 0 obj << +/Title 676 0 R +/A 673 0 R +/Parent 639 0 R +/Prev 671 0 R +/Next 679 0 R +>> endobj +671 0 obj << +/Title 672 0 R +/A 669 0 R +/Parent 639 0 R +/Prev 667 0 R +/Next 675 0 R +>> endobj +667 0 obj << +/Title 668 0 R +/A 665 0 R +/Parent 639 0 R +/Prev 663 0 R +/Next 671 0 R +>> endobj +663 0 obj << +/Title 664 0 R +/A 661 0 R +/Parent 639 0 R +/Prev 659 0 R +/Next 667 0 R +>> endobj +659 0 obj << +/Title 660 0 R +/A 657 0 R +/Parent 639 0 R +/Prev 655 0 R +/Next 663 0 R +>> endobj +655 0 obj << +/Title 656 0 R +/A 653 0 R +/Parent 639 0 R +/Prev 651 0 R +/Next 659 0 R +>> endobj +651 0 obj << +/Title 652 0 R +/A 649 0 R +/Parent 639 0 R +/Prev 647 0 R +/Next 655 0 R +>> endobj +647 0 obj << +/Title 648 0 R +/A 645 0 R +/Parent 639 0 R +/Prev 643 0 R +/Next 651 0 R +>> endobj +643 0 obj << +/Title 644 0 R +/A 641 0 R +/Parent 639 0 R +/Next 647 0 R +>> endobj +639 0 obj << +/Title 640 0 R +/A 637 0 R +/Parent 2114 0 R +/Prev 603 0 R +/First 643 0 R +/Last 691 0 R +/Count -13 +>> endobj +635 0 obj << +/Title 636 0 R +/A 633 0 R +/Parent 623 0 R +/Prev 631 0 R +>> endobj +631 0 obj << +/Title 632 0 R +/A 629 0 R +/Parent 623 0 R +/Prev 627 0 R +/Next 635 0 R +>> endobj +627 0 obj << +/Title 628 0 R +/A 625 0 R +/Parent 623 0 R +/Next 631 0 R +>> endobj +623 0 obj << +/Title 624 0 R +/A 621 0 R +/Parent 603 0 R +/Prev 615 0 R +/First 627 0 R +/Last 635 0 R +/Count -3 +>> endobj +619 0 obj << +/Title 620 0 R +/A 617 0 R +/Parent 615 0 R +>> endobj +615 0 obj << +/Title 616 0 R +/A 613 0 R +/Parent 603 0 R +/Prev 607 0 R +/Next 623 0 R +/First 619 0 R +/Last 619 0 R +/Count -1 +>> endobj +611 0 obj << +/Title 612 0 R +/A 609 0 R +/Parent 607 0 R +>> endobj +607 0 obj << +/Title 608 0 R +/A 605 0 R +/Parent 603 0 R +/Next 615 0 R +/First 611 0 R +/Last 611 0 R +/Count -1 +>> endobj +603 0 obj << +/Title 604 0 R +/A 601 0 R +/Parent 2114 0 R +/Prev 583 0 R +/Next 639 0 R +/First 607 0 R +/Last 623 0 R +/Count -3 +>> endobj +599 0 obj << +/Title 600 0 R +/A 597 0 R +/Parent 583 0 R +/Prev 595 0 R +>> endobj +595 0 obj << +/Title 596 0 R +/A 593 0 R +/Parent 583 0 R +/Prev 587 0 R +/Next 599 0 R +>> endobj +591 0 obj << +/Title 592 0 R +/A 589 0 R +/Parent 587 0 R +>> endobj +587 0 obj << +/Title 588 0 R +/A 585 0 R +/Parent 583 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 2114 0 R +/Prev 559 0 R +/Next 603 0 R +/First 587 0 R +/Last 599 0 R +/Count -3 +>> endobj +579 0 obj << +/Title 580 0 R +/A 577 0 R +/Parent 559 0 R +/Prev 567 0 R +>> endobj +575 0 obj << +/Title 576 0 R +/A 573 0 R +/Parent 567 0 R +/Prev 571 0 R +>> endobj +571 0 obj << +/Title 572 0 R +/A 569 0 R +/Parent 567 0 R +/Next 575 0 R +>> endobj +567 0 obj << +/Title 568 0 R +/A 565 0 R +/Parent 559 0 R +/Prev 563 0 R +/Next 579 0 R +/First 571 0 R +/Last 575 0 R +/Count -2 +>> endobj +563 0 obj << +/Title 564 0 R +/A 561 0 R +/Parent 559 0 R +/Next 567 0 R +>> endobj +559 0 obj << +/Title 560 0 R +/A 557 0 R +/Parent 2114 0 R +/Prev 243 0 R +/Next 583 0 R +/First 563 0 R +/Last 579 0 R +/Count -3 +>> endobj +555 0 obj << +/Title 556 0 R +/A 553 0 R +/Parent 539 0 R +/Prev 551 0 R +>> endobj +551 0 obj << +/Title 552 0 R +/A 549 0 R +/Parent 539 0 R +/Prev 547 0 R +/Next 555 0 R +>> endobj +547 0 obj << +/Title 548 0 R +/A 545 0 R +/Parent 539 0 R +/Prev 543 0 R +/Next 551 0 R +>> endobj +543 0 obj << +/Title 544 0 R +/A 541 0 R +/Parent 539 0 R +/Next 547 0 R +>> endobj +539 0 obj << +/Title 540 0 R +/A 537 0 R +/Parent 531 0 R +/Prev 535 0 R +/First 543 0 R +/Last 555 0 R +/Count -4 +>> endobj +535 0 obj << +/Title 536 0 R +/A 533 0 R +/Parent 531 0 R +/Next 539 0 R +>> endobj +531 0 obj << +/Title 532 0 R +/A 529 0 R +/Parent 243 0 R +/Prev 479 0 R +/First 535 0 R +/Last 539 0 R +/Count -2 +>> endobj +527 0 obj << +/Title 528 0 R +/A 525 0 R +/Parent 479 0 R +/Prev 523 0 R +>> endobj +523 0 obj << +/Title 524 0 R +/A 521 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 507 0 R +/Prev 515 0 R +>> endobj +515 0 obj << +/Title 516 0 R +/A 513 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 507 0 R +/Next 515 0 R +>> endobj +507 0 obj << +/Title 508 0 R +/A 505 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 479 0 R +/Prev 499 0 R +/Next 507 0 R +>> endobj +499 0 obj << +/Title 500 0 R +/A 497 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 479 0 R +/Prev 483 0 R +/Next 499 0 R +>> endobj +491 0 obj << +/Title 492 0 R +/A 489 0 R +/Parent 483 0 R +/Prev 487 0 R +>> endobj +487 0 obj << +/Title 488 0 R +/A 485 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 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 243 0 R +/Prev 275 0 R +/Next 531 0 R +/First 483 0 R +/Last 527 0 R +/Count -7 +>> endobj +475 0 obj << +/Title 476 0 R +/A 473 0 R +/Parent 459 0 R +/Prev 471 0 R +>> endobj +471 0 obj << +/Title 472 0 R +/A 469 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 459 0 R +/Prev 463 0 R +/Next 471 0 R +>> endobj +463 0 obj << +/Title 464 0 R +/A 461 0 R +/Parent 459 0 R +/Next 467 0 R +>> endobj +459 0 obj << +/Title 460 0 R +/A 457 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 +/Next 459 0 R +>> endobj +451 0 obj << +/Title 452 0 R +/A 449 0 R +/Parent 275 0 R +/Prev 447 0 R +/Next 455 0 R +>> endobj +447 0 obj << +/Title 448 0 R +/A 445 0 R +/Parent 275 0 R +/Prev 443 0 R +/Next 451 0 R +>> endobj +443 0 obj << +/Title 444 0 R +/A 441 0 R +/Parent 275 0 R +/Prev 439 0 R +/Next 447 0 R +>> endobj +439 0 obj << +/Title 440 0 R +/A 437 0 R +/Parent 275 0 R +/Prev 435 0 R +/Next 443 0 R +>> endobj +435 0 obj << +/Title 436 0 R +/A 433 0 R +/Parent 275 0 R +/Prev 431 0 R +/Next 439 0 R +>> endobj +431 0 obj << +/Title 432 0 R +/A 429 0 R +/Parent 275 0 R +/Prev 427 0 R +/Next 435 0 R +>> endobj +427 0 obj << +/Title 428 0 R +/A 425 0 R +/Parent 275 0 R +/Prev 423 0 R +/Next 431 0 R +>> endobj +423 0 obj << +/Title 424 0 R +/A 421 0 R +/Parent 275 0 R +/Prev 347 0 R +/Next 427 0 R +>> endobj +419 0 obj << +/Title 420 0 R +/A 417 0 R +/Parent 347 0 R +/Prev 415 0 R +>> endobj +415 0 obj << +/Title 416 0 R +/A 413 0 R +/Parent 347 0 R +/Prev 411 0 R +/Next 419 0 R +>> endobj +411 0 obj << +/Title 412 0 R +/A 409 0 R +/Parent 347 0 R +/Prev 407 0 R +/Next 415 0 R +>> endobj +407 0 obj << +/Title 408 0 R +/A 405 0 R +/Parent 347 0 R +/Prev 403 0 R +/Next 411 0 R +>> endobj +403 0 obj << +/Title 404 0 R +/A 401 0 R +/Parent 347 0 R +/Prev 399 0 R +/Next 407 0 R +>> endobj +399 0 obj << +/Title 400 0 R +/A 397 0 R +/Parent 347 0 R +/Prev 395 0 R +/Next 403 0 R +>> endobj +395 0 obj << +/Title 396 0 R +/A 393 0 R +/Parent 347 0 R +/Prev 391 0 R +/Next 399 0 R +>> endobj +391 0 obj << +/Title 392 0 R +/A 389 0 R +/Parent 347 0 R +/Prev 387 0 R +/Next 395 0 R +>> endobj +387 0 obj << +/Title 388 0 R +/A 385 0 R +/Parent 347 0 R +/Prev 383 0 R +/Next 391 0 R +>> endobj +383 0 obj << +/Title 384 0 R +/A 381 0 R +/Parent 347 0 R +/Prev 379 0 R +/Next 387 0 R +>> endobj +379 0 obj << +/Title 380 0 R +/A 377 0 R +/Parent 347 0 R +/Prev 375 0 R +/Next 383 0 R +>> endobj +375 0 obj << +/Title 376 0 R +/A 373 0 R +/Parent 347 0 R +/Prev 371 0 R +/Next 379 0 R +>> endobj +371 0 obj << +/Title 372 0 R +/A 369 0 R +/Parent 347 0 R +/Prev 367 0 R +/Next 375 0 R +>> endobj +367 0 obj << +/Title 368 0 R +/A 365 0 R +/Parent 347 0 R +/Prev 363 0 R +/Next 371 0 R +>> endobj +363 0 obj << +/Title 364 0 R +/A 361 0 R +/Parent 347 0 R +/Prev 359 0 R +/Next 367 0 R +>> endobj +359 0 obj << +/Title 360 0 R +/A 357 0 R +/Parent 347 0 R +/Prev 355 0 R +/Next 363 0 R +>> endobj +355 0 obj << +/Title 356 0 R +/A 353 0 R +/Parent 347 0 R +/Prev 351 0 R +/Next 359 0 R +>> endobj +351 0 obj << +/Title 352 0 R +/A 349 0 R +/Parent 347 0 R +/Next 355 0 R +>> endobj +347 0 obj << +/Title 348 0 R +/A 345 0 R +/Parent 275 0 R +/Prev 343 0 R +/Next 423 0 R +/First 351 0 R +/Last 419 0 R +/Count -18 +>> endobj +343 0 obj << +/Title 344 0 R +/A 341 0 R +/Parent 275 0 R +/Prev 339 0 R +/Next 347 0 R +>> endobj +339 0 obj << +/Title 340 0 R +/A 337 0 R +/Parent 275 0 R +/Prev 335 0 R +/Next 343 0 R +>> endobj +335 0 obj << +/Title 336 0 R +/A 333 0 R +/Parent 275 0 R +/Prev 331 0 R +/Next 339 0 R +>> endobj +331 0 obj << +/Title 332 0 R +/A 329 0 R +/Parent 275 0 R +/Prev 327 0 R +/Next 335 0 R +>> endobj +327 0 obj << +/Title 328 0 R +/A 325 0 R +/Parent 275 0 R +/Prev 315 0 R +/Next 331 0 R +>> endobj +323 0 obj << +/Title 324 0 R +/A 321 0 R +/Parent 315 0 R +/Prev 319 0 R +>> endobj +319 0 obj << +/Title 320 0 R +/A 317 0 R +/Parent 315 0 R +/Next 323 0 R +>> endobj +315 0 obj << +/Title 316 0 R +/A 313 0 R +/Parent 275 0 R +/Prev 311 0 R +/Next 327 0 R +/First 319 0 R +/Last 323 0 R +/Count -2 +>> endobj +311 0 obj << +/Title 312 0 R +/A 309 0 R +/Parent 275 0 R +/Prev 307 0 R +/Next 315 0 R +>> endobj +307 0 obj << +/Title 308 0 R +/A 305 0 R +/Parent 275 0 R +/Prev 303 0 R +/Next 311 0 R +>> endobj +303 0 obj << +/Title 304 0 R +/A 301 0 R +/Parent 275 0 R +/Prev 299 0 R +/Next 307 0 R +>> endobj +299 0 obj << +/Title 300 0 R +/A 297 0 R +/Parent 275 0 R +/Prev 295 0 R +/Next 303 0 R +>> endobj +295 0 obj << +/Title 296 0 R +/A 293 0 R +/Parent 275 0 R +/Prev 291 0 R +/Next 299 0 R +>> endobj +291 0 obj << +/Title 292 0 R +/A 289 0 R +/Parent 275 0 R +/Prev 287 0 R +/Next 295 0 R +>> endobj +287 0 obj << +/Title 288 0 R +/A 285 0 R +/Parent 275 0 R +/Prev 283 0 R +/Next 291 0 R +>> endobj +283 0 obj << +/Title 284 0 R +/A 281 0 R +/Parent 275 0 R +/Prev 279 0 R +/Next 287 0 R +>> endobj +279 0 obj << +/Title 280 0 R +/A 277 0 R +/Parent 275 0 R +/Next 283 0 R +>> endobj +275 0 obj << +/Title 276 0 R +/A 273 0 R +/Parent 243 0 R +/Prev 247 0 R +/Next 479 0 R +/First 279 0 R +/Last 459 0 R +/Count -26 +>> endobj +271 0 obj << +/Title 272 0 R +/A 269 0 R +/Parent 263 0 R +/Prev 267 0 R +>> endobj +267 0 obj << +/Title 268 0 R +/A 265 0 R +/Parent 263 0 R +/Next 271 0 R +>> endobj +263 0 obj << +/Title 264 0 R +/A 261 0 R +/Parent 247 0 R +/Prev 251 0 R +/First 267 0 R +/Last 271 0 R +/Count -2 +>> endobj +259 0 obj << +/Title 260 0 R +/A 257 0 R +/Parent 251 0 R +/Prev 255 0 R +>> endobj +255 0 obj << +/Title 256 0 R +/A 253 0 R +/Parent 251 0 R +/Next 259 0 R +>> endobj +251 0 obj << +/Title 252 0 R +/A 249 0 R +/Parent 247 0 R +/Next 263 0 R +/First 255 0 R +/Last 259 0 R +/Count -2 +>> endobj +247 0 obj << +/Title 248 0 R +/A 245 0 R +/Parent 243 0 R +/Next 275 0 R +/First 251 0 R +/Last 263 0 R +/Count -2 +>> endobj +243 0 obj << +/Title 244 0 R +/A 241 0 R +/Parent 2114 0 R +/Prev 231 0 R +/Next 559 0 R +/First 247 0 R +/Last 531 0 R +/Count -4 +>> endobj +239 0 obj << +/Title 240 0 R +/A 237 0 R +/Parent 231 0 R +/Prev 235 0 R +>> endobj +235 0 obj << +/Title 236 0 R +/A 233 0 R +/Parent 231 0 R +/Next 239 0 R +>> endobj +231 0 obj << +/Title 232 0 R +/A 229 0 R +/Parent 2114 0 R +/Prev 131 0 R +/Next 243 0 R +/First 235 0 R +/Last 239 0 R +/Count -2 +>> endobj +227 0 obj << +/Title 228 0 R +/A 225 0 R +/Parent 219 0 R +/Prev 223 0 R +>> endobj +223 0 obj << +/Title 224 0 R +/A 221 0 R +/Parent 219 0 R +/Next 227 0 R +>> endobj +219 0 obj << +/Title 220 0 R +/A 217 0 R +/Parent 131 0 R +/Prev 203 0 R +/First 223 0 R +/Last 227 0 R +/Count -2 +>> endobj +215 0 obj << +/Title 216 0 R +/A 213 0 R +/Parent 203 0 R +/Prev 211 0 R +>> endobj +211 0 obj << +/Title 212 0 R +/A 209 0 R +/Parent 203 0 R +/Prev 207 0 R +/Next 215 0 R +>> endobj +207 0 obj << +/Title 208 0 R +/A 205 0 R +/Parent 203 0 R +/Next 211 0 R +>> endobj +203 0 obj << +/Title 204 0 R +/A 201 0 R +/Parent 131 0 R +/Prev 199 0 R +/Next 219 0 R +/First 207 0 R +/Last 215 0 R +/Count -3 +>> endobj +199 0 obj << +/Title 200 0 R +/A 197 0 R +/Parent 131 0 R +/Prev 195 0 R +/Next 203 0 R +>> endobj +195 0 obj << +/Title 196 0 R +/A 193 0 R +/Parent 131 0 R +/Prev 159 0 R +/Next 199 0 R +>> endobj +191 0 obj << +/Title 192 0 R +/A 189 0 R +/Parent 159 0 R +/Prev 187 0 R +>> endobj +187 0 obj << +/Title 188 0 R +/A 185 0 R +/Parent 159 0 R +/Prev 183 0 R +/Next 191 0 R +>> endobj +183 0 obj << +/Title 184 0 R +/A 181 0 R +/Parent 159 0 R +/Prev 179 0 R +/Next 187 0 R +>> endobj +179 0 obj << +/Title 180 0 R +/A 177 0 R +/Parent 159 0 R +/Prev 175 0 R +/Next 183 0 R +>> endobj +175 0 obj << +/Title 176 0 R +/A 173 0 R +/Parent 159 0 R +/Prev 163 0 R +/Next 179 0 R +>> endobj +171 0 obj << +/Title 172 0 R +/A 169 0 R +/Parent 163 0 R +/Prev 167 0 R +>> endobj +167 0 obj << +/Title 168 0 R +/A 165 0 R +/Parent 163 0 R +/Next 171 0 R +>> endobj +163 0 obj << +/Title 164 0 R +/A 161 0 R +/Parent 159 0 R +/Next 175 0 R +/First 167 0 R +/Last 171 0 R +/Count -2 +>> endobj +159 0 obj << +/Title 160 0 R +/A 157 0 R +/Parent 131 0 R +/Prev 151 0 R +/Next 195 0 R +/First 163 0 R +/Last 191 0 R +/Count -6 +>> endobj +155 0 obj << +/Title 156 0 R +/A 153 0 R +/Parent 151 0 R +>> endobj +151 0 obj << +/Title 152 0 R +/A 149 0 R +/Parent 131 0 R +/Prev 147 0 R +/Next 159 0 R +/First 155 0 R +/Last 155 0 R +/Count -1 +>> endobj +147 0 obj << +/Title 148 0 R +/A 145 0 R +/Parent 131 0 R +/Prev 139 0 R +/Next 151 0 R +>> endobj +143 0 obj << +/Title 144 0 R +/A 141 0 R +/Parent 139 0 R +>> endobj +139 0 obj << +/Title 140 0 R +/A 137 0 R +/Parent 131 0 R +/Prev 135 0 R +/Next 147 0 R +/First 143 0 R +/Last 143 0 R +/Count -1 +>> endobj +135 0 obj << +/Title 136 0 R +/A 133 0 R +/Parent 131 0 R +/Next 139 0 R +>> endobj +131 0 obj << +/Title 132 0 R +/A 129 0 R +/Parent 2114 0 R +/Prev 91 0 R +/Next 231 0 R +/First 135 0 R +/Last 219 0 R +/Count -9 +>> endobj +127 0 obj << +/Title 128 0 R +/A 125 0 R +/Parent 111 0 R +/Prev 115 0 R +>> endobj +123 0 obj << +/Title 124 0 R +/A 121 0 R +/Parent 115 0 R +/Prev 119 0 R +>> endobj +119 0 obj << +/Title 120 0 R +/A 117 0 R +/Parent 115 0 R +/Next 123 0 R +>> endobj +115 0 obj << +/Title 116 0 R +/A 113 0 R +/Parent 111 0 R +/Next 127 0 R +/First 119 0 R +/Last 123 0 R +/Count -2 +>> endobj +111 0 obj << +/Title 112 0 R +/A 109 0 R +/Parent 91 0 R +/Prev 107 0 R +/First 115 0 R +/Last 127 0 R +/Count -2 +>> endobj +107 0 obj << +/Title 108 0 R +/A 105 0 R +/Parent 91 0 R +/Prev 95 0 R +/Next 111 0 R +>> endobj +103 0 obj << +/Title 104 0 R +/A 101 0 R +/Parent 95 0 R +/Prev 99 0 R +>> endobj +99 0 obj << +/Title 100 0 R +/A 97 0 R +/Parent 95 0 R +/Next 103 0 R +>> endobj +95 0 obj << +/Title 96 0 R +/A 93 0 R +/Parent 91 0 R +/Next 107 0 R +/First 99 0 R +/Last 103 0 R +/Count -2 +>> endobj +91 0 obj << +/Title 92 0 R +/A 89 0 R +/Parent 2114 0 R +/Prev 67 0 R +/Next 131 0 R +/First 95 0 R +/Last 111 0 R +/Count -3 +>> endobj +87 0 obj << +/Title 88 0 R +/A 85 0 R +/Parent 67 0 R +/Prev 83 0 R +>> endobj +83 0 obj << +/Title 84 0 R +/A 81 0 R +/Parent 67 0 R +/Prev 79 0 R +/Next 87 0 R +>> endobj +79 0 obj << +/Title 80 0 R +/A 77 0 R +/Parent 67 0 R +/Prev 75 0 R +/Next 83 0 R +>> endobj +75 0 obj << +/Title 76 0 R +/A 73 0 R +/Parent 67 0 R +/Prev 71 0 R +/Next 79 0 R +>> endobj +71 0 obj << +/Title 72 0 R +/A 69 0 R +/Parent 67 0 R +/Next 75 0 R +>> endobj +67 0 obj << +/Title 68 0 R +/A 65 0 R +/Parent 2114 0 R +/Prev 7 0 R +/Next 91 0 R +/First 71 0 R +/Last 87 0 R +/Count -5 +>> endobj +63 0 obj << +/Title 64 0 R +/A 61 0 R +/Parent 23 0 R +/Prev 55 0 R +>> endobj +59 0 obj << +/Title 60 0 R +/A 57 0 R +/Parent 55 0 R +>> endobj +55 0 obj << +/Title 56 0 R +/A 53 0 R +/Parent 23 0 R +/Prev 39 0 R +/Next 63 0 R +/First 59 0 R +/Last 59 0 R +/Count -1 +>> endobj +51 0 obj << +/Title 52 0 R +/A 49 0 R +/Parent 39 0 R +/Prev 47 0 R +>> endobj +47 0 obj << +/Title 48 0 R +/A 45 0 R +/Parent 39 0 R +/Prev 43 0 R +/Next 51 0 R +>> endobj +43 0 obj << +/Title 44 0 R +/A 41 0 R +/Parent 39 0 R +/Next 47 0 R +>> endobj +39 0 obj << +/Title 40 0 R +/A 37 0 R +/Parent 23 0 R +/Prev 35 0 R +/Next 55 0 R +/First 43 0 R +/Last 51 0 R +/Count -3 +>> endobj +35 0 obj << +/Title 36 0 R +/A 33 0 R +/Parent 23 0 R +/Prev 31 0 R +/Next 39 0 R +>> endobj +31 0 obj << +/Title 32 0 R +/A 29 0 R +/Parent 23 0 R +/Prev 27 0 R +/Next 35 0 R +>> endobj +27 0 obj << +/Title 28 0 R +/A 25 0 R +/Parent 23 0 R +/Next 31 0 R +>> endobj +23 0 obj << +/Title 24 0 R +/A 21 0 R +/Parent 7 0 R +/Prev 19 0 R +/First 27 0 R +/Last 63 0 R +/Count -6 +>> endobj +19 0 obj << +/Title 20 0 R +/A 17 0 R +/Parent 7 0 R +/Prev 15 0 R +/Next 23 0 R +>> endobj +15 0 obj << +/Title 16 0 R +/A 13 0 R +/Parent 7 0 R +/Prev 11 0 R +/Next 19 0 R +>> endobj +11 0 obj << +/Title 12 0 R +/A 9 0 R +/Parent 7 0 R +/Next 15 0 R +>> endobj +7 0 obj << +/Title 8 0 R +/A 5 0 R +/Parent 2114 0 R +/Next 67 0 R +/First 11 0 R +/Last 23 0 R +/Count -4 +>> endobj +2115 0 obj << +/Names [(Access_Control_Lists) 1591 0 R (Bv9ARM.ch01) 932 0 R (Bv9ARM.ch02) 978 0 R (Bv9ARM.ch03) 995 0 R (Bv9ARM.ch04) 1044 0 R (Bv9ARM.ch05) 1132 0 R (Bv9ARM.ch06) 1143 0 R (Bv9ARM.ch07) 1590 0 R (Bv9ARM.ch08) 1616 0 R (Bv9ARM.ch09) 1631 0 R (Bv9ARM.ch10) 1852 0 R (Configuration_File_Grammar) 1168 0 R (DNSSEC) 1111 0 R (Doc-Start) 699 0 R (Setting_TTLs) 1526 0 R (acache) 985 0 R (access_control) 1290 0 R (acl) 1176 0 R (address_match_lists) 1149 0 R (admin_tools) 1018 0 R (appendix.A) 602 0 R (appendix.B) 638 0 R (bibliography) 1640 0 R (boolean_options) 1060 0 R (builtin) 1368 0 R (chapter*.1) 734 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) 558 0 R (chapter.8) 582 0 R (cite.RFC1033) 1767 0 R (cite.RFC1034) 1652 0 R (cite.RFC1035) 1654 0 R (cite.RFC1101) 1749 0 R (cite.RFC1123) 1751 0 R (cite.RFC1183) 1711 0 R (cite.RFC1464) 1789 0 R (cite.RFC1535) 1697 0 R (cite.RFC1536) 1699 0 R (cite.RFC1537) 1769 0 R (cite.RFC1591) 1753 0 R (cite.RFC1706) 1713 0 R (cite.RFC1712) 1809 0 R (cite.RFC1713) 1791 0 R (cite.RFC1794) 1793 0 R (cite.RFC1876) 1715 0 R (cite.RFC1912) 1771 0 R (cite.RFC1982) 1701 0 R (cite.RFC1995) 1659 0 R (cite.RFC1996) 1661 0 R (cite.RFC2010) 1773 0 R (cite.RFC2052) 1717 0 R (cite.RFC2065) 1821 0 R (cite.RFC2136) 1663 0 R (cite.RFC2137) 1823 0 R (cite.RFC2163) 1719 0 R (cite.RFC2168) 1721 0 R (cite.RFC2181) 1665 0 R (cite.RFC2219) 1775 0 R (cite.RFC2230) 1723 0 R (cite.RFC2240) 1795 0 R (cite.RFC2308) 1667 0 R (cite.RFC2317) 1755 0 R (cite.RFC2345) 1797 0 R (cite.RFC2352) 1799 0 R (cite.RFC2535) 1825 0 R (cite.RFC2536) 1725 0 R (cite.RFC2537) 1727 0 R (cite.RFC2538) 1729 0 R (cite.RFC2539) 1731 0 R (cite.RFC2540) 1733 0 R (cite.RFC2671) 1669 0 R (cite.RFC2672) 1671 0 R (cite.RFC2673) 1811 0 R (cite.RFC2782) 1735 0 R (cite.RFC2825) 1779 0 R (cite.RFC2826) 1757 0 R (cite.RFC2845) 1673 0 R (cite.RFC2874) 1813 0 R (cite.RFC2915) 1737 0 R (cite.RFC2929) 1759 0 R (cite.RFC2930) 1675 0 R (cite.RFC2931) 1677 0 R (cite.RFC3007) 1679 0 R (cite.RFC3008) 1827 0 R (cite.RFC3071) 1801 0 R (cite.RFC3090) 1829 0 R (cite.RFC3110) 1739 0 R (cite.RFC3123) 1741 0 R (cite.RFC3225) 1685 0 R (cite.RFC3258) 1803 0 R (cite.RFC3445) 1831 0 R (cite.RFC3490) 1781 0 R (cite.RFC3491) 1783 0 R (cite.RFC3492) 1785 0 R (cite.RFC3596) 1743 0 R (cite.RFC3597) 1745 0 R (cite.RFC3645) 1681 0 R (cite.RFC3655) 1833 0 R (cite.RFC3658) 1835 0 R (cite.RFC3755) 1837 0 R (cite.RFC3757) 1839 0 R (cite.RFC3833) 1687 0 R (cite.RFC3845) 1841 0 R (cite.RFC3901) 1805 0 R (cite.RFC4033) 1689 0 R (cite.RFC4034) 1691 0 R (cite.RFC4035) 1693 0 R (cite.RFC4074) 1703 0 R (cite.RFC974) 1656 0 R (cite.id2504427) 1846 0 R (configuration_file_elements) 1144 0 R (controls_statement_definition_and_usage) 1031 0 R (diagnostic_tools) 966 0 R (dynamic_update) 1054 0 R (dynamic_update_policies) 1106 0 R (dynamic_update_security) 1299 0 R (empty) 1376 0 R (historical_dns_information) 1633 0 R (id2464966) 933 0 R (id2466572) 934 0 R (id2467531) 935 0 R (id2467541) 936 0 R (id2467713) 948 0 R (id2467734) 949 0 R (id2467768) 950 0 R (id2467852) 953 0 R (id2467945) 946 0 R (id2470250) 960 0 R (id2470274) 963 0 R (id2470372) 964 0 R (id2470393) 965 0 R (id2470423) 971 0 R (id2470526) 972 0 R (id2470553) 973 0 R (id2470587) 979 0 R (id2470614) 980 0 R (id2470627) 981 0 R (id2470721) 984 0 R (id2470731) 990 0 R (id2470763) 997 0 R (id2470779) 998 0 R (id2470802) 1004 0 R (id2470819) 1005 0 R (id2471224) 1008 0 R (id2471229) 1009 0 R (id2473110) 1036 0 R (id2473122) 1037 0 R (id2473515) 1069 0 R (id2473533) 1070 0 R (id2473969) 1086 0 R (id2473986) 1087 0 R (id2474024) 1092 0 R (id2474042) 1093 0 R (id2474121) 1094 0 R (id2474161) 1095 0 R (id2474286) 1100 0 R (id2474331) 1102 0 R (id2474345) 1103 0 R (id2474462) 1104 0 R (id2474599) 1112 0 R (id2474678) 1113 0 R (id2474759) 1118 0 R (id2474902) 1123 0 R (id2475169) 1125 0 R (id2475190) 1126 0 R (id2475291) 1133 0 R (id2475438) 1145 0 R (id2476300) 1154 0 R (id2476328) 1159 0 R (id2476522) 1160 0 R (id2476537) 1161 0 R (id2476567) 1167 0 R (id2476718) 1169 0 R (id2477161) 1175 0 R (id2477272) 1177 0 R (id2477419) 1179 0 R (id2477780) 1186 0 R (id2477797) 1192 0 R (id2477889) 1193 0 R (id2477912) 1194 0 R (id2478003) 1198 0 R (id2478197) 1204 0 R (id2478249) 1205 0 R (id2478942) 1216 0 R (id2479645) 1226 0 R (id2479719) 1227 0 R (id2479783) 1230 0 R (id2479827) 1231 0 R (id2479842) 1232 0 R (id2482169) 1261 0 R (id2484043) 1287 0 R (id2484102) 1289 0 R (id2484598) 1304 0 R (id2485793) 1323 0 R (id2485852) 1325 0 R (id2486200) 1337 0 R (id2486839) 1352 0 R (id2488339) 1386 0 R (id2489091) 1399 0 R (id2489142) 1400 0 R (id2489292) 1402 0 R (id2490761) 1419 0 R (id2490769) 1420 0 R (id2490774) 1421 0 R (id2491188) 1428 0 R (id2491221) 1433 0 R (id2492840) 1485 0 R (id2493223) 1491 0 R (id2493309) 1492 0 R (id2493330) 1495 0 R (id2493498) 1497 0 R (id2494737) 1508 0 R (id2494865) 1514 0 R (id2495022) 1515 0 R (id2495385) 1517 0 R (id2495522) 1519 0 R (id2495544) 1524 0 R (id2496017) 1527 0 R (id2496141) 1529 0 R (id2496156) 1530 0 R (id2496268) 1536 0 R (id2496291) 1537 0 R (id2496420) 1538 0 R (id2496489) 1539 0 R (id2496525) 1544 0 R (id2496587) 1545 0 R (id2497018) 1553 0 R (id2497363) 1561 0 R (id2497368) 1562 0 R (id2499022) 1568 0 R (id2499029) 1569 0 R (id2499405) 1571 0 R (id2499411) 1572 0 R (id2500259) 1581 0 R (id2500446) 1601 0 R (id2500592) 1602 0 R (id2500651) 1603 0 R (id2500731) 1617 0 R (id2500737) 1618 0 R (id2500748) 1619 0 R (id2500765) 1620 0 R (id2500964) 1632 0 R (id2501136) 1639 0 R (id2501255) 1644 0 R (id2501257) 1650 0 R (id2501266) 1655 0 R (id2501289) 1651 0 R (id2501381) 1653 0 R (id2501417) 1664 0 R (id2501444) 1666 0 R (id2501469) 1658 0 R (id2501494) 1660 0 R (id2501517) 1662 0 R (id2501573) 1668 0 R (id2501600) 1670 0 R (id2501626) 1672 0 R (id2501688) 1674 0 R (id2501718) 1676 0 R (id2501748) 1678 0 R (id2501843) 1680 0 R (id2501917) 1683 0 R (id2501925) 1684 0 R (id2501952) 1686 0 R (id2501988) 1688 0 R (id2502053) 1690 0 R (id2502118) 1692 0 R (id2502183) 1695 0 R (id2502192) 1696 0 R (id2502217) 1698 0 R (id2502285) 1700 0 R (id2502321) 1702 0 R (id2502361) 1709 0 R (id2502366) 1710 0 R (id2502424) 1712 0 R (id2502461) 1720 0 R (id2502497) 1714 0 R (id2502551) 1716 0 R (id2502589) 1718 0 R (id2502615) 1722 0 R (id2502641) 1724 0 R (id2502667) 1726 0 R (id2502694) 1728 0 R (id2502733) 1730 0 R (id2502763) 1732 0 R (id2502793) 1734 0 R (id2502836) 1736 0 R (id2502869) 1738 0 R (id2502896) 1740 0 R (id2502919) 1742 0 R (id2502977) 1744 0 R (id2503001) 1747 0 R (id2503009) 1748 0 R (id2503034) 1750 0 R (id2503057) 1752 0 R (id2503080) 1754 0 R (id2503126) 1756 0 R (id2503149) 1758 0 R (id2503200) 1765 0 R (id2503207) 1766 0 R (id2503230) 1768 0 R (id2503257) 1770 0 R (id2503352) 1772 0 R (id2503388) 1774 0 R (id2503429) 1777 0 R (id2503434) 1778 0 R (id2503466) 1780 0 R (id2503512) 1782 0 R (id2503547) 1784 0 R (id2503574) 1787 0 R (id2503592) 1788 0 R (id2503614) 1790 0 R (id2503640) 1792 0 R (id2503666) 1794 0 R (id2503689) 1796 0 R (id2503735) 1798 0 R (id2503758) 1800 0 R (id2503785) 1802 0 R (id2503811) 1804 0 R (id2503848) 1807 0 R (id2503854) 1808 0 R (id2503912) 1810 0 R (id2503939) 1812 0 R (id2503975) 1819 0 R (id2503987) 1820 0 R (id2504026) 1822 0 R (id2504053) 1824 0 R (id2504083) 1826 0 R (id2504108) 1828 0 R (id2504135) 1830 0 R (id2504240) 1832 0 R (id2504276) 1834 0 R (id2504302) 1836 0 R (id2504329) 1838 0 R (id2504374) 1840 0 R (id2504416) 1843 0 R (id2504425) 1845 0 R (id2504427) 1847 0 R (incremental_zone_transfers) 1066 0 R (internet_drafts) 1842 0 R (ipv6addresses) 1127 0 R (journal) 1055 0 R (lwresd) 1134 0 R (man.dig) 1853 0 R (man.dnssec-dsfromkey) 1902 0 R (man.dnssec-keyfromlabel) 1916 0 R (man.dnssec-keygen) 1932 0 R (man.dnssec-signzone) 1949 0 R (man.host) 1886 0 R (man.named) 2003 0 R (man.named-checkconf) 1970 0 R (man.named-checkzone) 1982 0 R (man.nsupdate) 2021 0 R (man.rndc) 2047 0 R (man.rndc-confgen) 2075 0 R (man.rndc.conf) 2059 0 R (notify) 1045 0 R (options) 1246 0 R (page.1) 698 0 R (page.10) 970 0 R (page.100) 1707 0 R (page.101) 1763 0 R (page.102) 1817 0 R (page.103) 1851 0 R (page.104) 1861 0 R (page.105) 1867 0 R (page.106) 1872 0 R (page.107) 1876 0 R (page.108) 1881 0 R (page.109) 1892 0 R (page.11) 977 0 R (page.110) 1898 0 R (page.111) 1910 0 R (page.112) 1921 0 R (page.113) 1928 0 R (page.114) 1940 0 R (page.115) 1944 0 R (page.116) 1956 0 R (page.117) 1962 0 R (page.118) 1966 0 R (page.119) 1976 0 R (page.12) 989 0 R (page.120) 1988 0 R (page.121) 1994 0 R (page.122) 2002 0 R (page.123) 2011 0 R (page.124) 2015 0 R (page.125) 2026 0 R (page.126) 2032 0 R (page.127) 2037 0 R (page.128) 2043 0 R (page.129) 2055 0 R (page.13) 994 0 R (page.130) 2065 0 R (page.131) 2071 0 R (page.132) 2080 0 R (page.133) 2087 0 R (page.14) 1003 0 R (page.15) 1014 0 R (page.16) 1022 0 R (page.17) 1029 0 R (page.18) 1035 0 R (page.19) 1043 0 R (page.2) 723 0 R (page.20) 1065 0 R (page.21) 1075 0 R (page.22) 1080 0 R (page.23) 1084 0 R (page.24) 1091 0 R (page.25) 1099 0 R (page.26) 1110 0 R (page.27) 1117 0 R (page.28) 1122 0 R (page.29) 1131 0 R (page.3) 733 0 R (page.30) 1138 0 R (page.31) 1142 0 R (page.32) 1153 0 R (page.33) 1158 0 R (page.34) 1166 0 R (page.35) 1174 0 R (page.36) 1183 0 R (page.37) 1191 0 R (page.38) 1203 0 R (page.39) 1209 0 R (page.4) 788 0 R (page.40) 1215 0 R (page.41) 1221 0 R (page.42) 1225 0 R (page.43) 1236 0 R (page.44) 1241 0 R (page.45) 1245 0 R (page.46) 1250 0 R (page.47) 1256 0 R (page.48) 1260 0 R (page.49) 1267 0 R (page.5) 852 0 R (page.50) 1278 0 R (page.51) 1282 0 R (page.52) 1286 0 R (page.53) 1296 0 R (page.54) 1303 0 R (page.55) 1309 0 R (page.56) 1314 0 R (page.57) 1318 0 R (page.58) 1322 0 R (page.59) 1330 0 R (page.6) 914 0 R (page.60) 1336 0 R (page.61) 1342 0 R (page.62) 1350 0 R (page.63) 1358 0 R (page.64) 1363 0 R (page.65) 1375 0 R (page.66) 1380 0 R (page.67) 1384 0 R (page.68) 1392 0 R (page.69) 1397 0 R (page.7) 931 0 R (page.70) 1406 0 R (page.71) 1410 0 R (page.72) 1414 0 R (page.73) 1418 0 R (page.74) 1427 0 R (page.75) 1432 0 R (page.76) 1451 0 R (page.77) 1464 0 R (page.78) 1484 0 R (page.79) 1490 0 R (page.8) 945 0 R (page.80) 1503 0 R (page.81) 1507 0 R (page.82) 1513 0 R (page.83) 1523 0 R (page.84) 1535 0 R (page.85) 1543 0 R (page.86) 1551 0 R (page.87) 1559 0 R (page.88) 1567 0 R (page.89) 1576 0 R (page.9) 959 0 R (page.90) 1585 0 R (page.91) 1589 0 R (page.92) 1596 0 R (page.93) 1607 0 R (page.94) 1611 0 R (page.95) 1615 0 R (page.96) 1626 0 R (page.97) 1630 0 R (page.98) 1638 0 R (page.99) 1648 0 R (proposed_standards) 1071 0 R (query_address) 1305 0 R (rfcs) 955 0 R (rndc) 1187 0 R (rrset_ordering) 1010 0 R (sample_configuration) 996 0 R (section*.10) 1776 0 R (section*.100) 2058 0 R (section*.101) 2060 0 R (section*.102) 2061 0 R (section*.103) 2066 0 R (section*.104) 2067 0 R (section*.105) 2072 0 R (section*.106) 2073 0 R (section*.107) 2074 0 R (section*.108) 2076 0 R (section*.109) 2081 0 R (section*.11) 1786 0 R (section*.110) 2082 0 R (section*.111) 2083 0 R (section*.112) 2088 0 R (section*.113) 2089 0 R (section*.114) 2090 0 R (section*.12) 1806 0 R (section*.13) 1818 0 R (section*.14) 1844 0 R (section*.15) 1854 0 R (section*.16) 1855 0 R (section*.17) 1856 0 R (section*.18) 1862 0 R (section*.19) 1863 0 R (section*.2) 1643 0 R (section*.20) 1868 0 R (section*.21) 1877 0 R (section*.22) 1882 0 R (section*.23) 1883 0 R (section*.24) 1884 0 R (section*.25) 1885 0 R (section*.26) 1887 0 R (section*.27) 1888 0 R (section*.28) 1893 0 R (section*.29) 1899 0 R (section*.3) 1649 0 R (section*.30) 1900 0 R (section*.31) 1901 0 R (section*.32) 1903 0 R (section*.33) 1904 0 R (section*.34) 1905 0 R (section*.35) 1906 0 R (section*.36) 1911 0 R (section*.37) 1912 0 R (section*.38) 1913 0 R (section*.39) 1914 0 R (section*.4) 1657 0 R (section*.40) 1915 0 R (section*.41) 1917 0 R (section*.42) 1922 0 R (section*.43) 1923 0 R (section*.44) 1924 0 R (section*.45) 1929 0 R (section*.46) 1930 0 R (section*.47) 1931 0 R (section*.48) 1933 0 R (section*.49) 1934 0 R (section*.5) 1682 0 R (section*.50) 1935 0 R (section*.51) 1936 0 R (section*.52) 1945 0 R (section*.53) 1946 0 R (section*.54) 1947 0 R (section*.55) 1948 0 R (section*.56) 1950 0 R (section*.57) 1951 0 R (section*.58) 1957 0 R (section*.59) 1958 0 R (section*.6) 1694 0 R (section*.60) 1967 0 R (section*.61) 1968 0 R (section*.62) 1969 0 R (section*.63) 1971 0 R (section*.64) 1972 0 R (section*.65) 1977 0 R (section*.66) 1978 0 R (section*.67) 1979 0 R (section*.68) 1980 0 R (section*.69) 1981 0 R (section*.7) 1708 0 R (section*.70) 1983 0 R (section*.71) 1984 0 R (section*.72) 1989 0 R (section*.73) 1990 0 R (section*.74) 1995 0 R (section*.75) 1996 0 R (section*.76) 1997 0 R (section*.77) 2004 0 R (section*.78) 2005 0 R (section*.79) 2006 0 R (section*.8) 1746 0 R (section*.80) 2007 0 R (section*.81) 2016 0 R (section*.82) 2017 0 R (section*.83) 2018 0 R (section*.84) 2019 0 R (section*.85) 2020 0 R (section*.86) 2022 0 R (section*.87) 2027 0 R (section*.88) 2028 0 R (section*.89) 2033 0 R (section*.9) 1764 0 R (section*.90) 2038 0 R (section*.91) 2044 0 R (section*.92) 2045 0 R (section*.93) 2046 0 R (section*.94) 2048 0 R (section*.95) 2049 0 R (section*.96) 2050 0 R (section*.97) 2051 0 R (section*.98) 2056 0 R (section*.99) 2057 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.6.4) 530 0 R (section.7.1) 562 0 R (section.7.2) 566 0 R (section.7.3) 578 0 R (section.8.1) 586 0 R (section.8.2) 594 0 R (section.8.3) 598 0 R (section.A.1) 606 0 R (section.A.2) 614 0 R (section.A.3) 622 0 R (section.B.1) 642 0 R (section.B.10) 678 0 R (section.B.11) 682 0 R (section.B.12) 686 0 R (section.B.13) 690 0 R (section.B.2) 646 0 R (section.B.3) 650 0 R (section.B.4) 654 0 R (section.B.5) 658 0 R (section.B.6) 662 0 R (section.B.7) 666 0 R (section.B.8) 670 0 R (section.B.9) 674 0 R (server_resource_limits) 1331 0 R (server_statement_definition_and_usage) 1274 0 R (server_statement_grammar) 1387 0 R (statistics) 1552 0 R (statistics_counters) 1560 0 R (statschannels) 1385 0 R (statsfile) 1252 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) 422 0 R (subsection.6.2.18) 426 0 R (subsection.6.2.19) 430 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 434 0 R (subsection.6.2.21) 438 0 R (subsection.6.2.22) 442 0 R (subsection.6.2.23) 446 0 R (subsection.6.2.24) 450 0 R (subsection.6.2.25) 454 0 R (subsection.6.2.26) 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.6.4.1) 538 0 R (subsection.7.2.1) 570 0 R (subsection.7.2.2) 574 0 R (subsection.8.1.1) 590 0 R (subsection.A.1.1) 610 0 R (subsection.A.2.1) 618 0 R (subsection.A.3.1) 626 0 R (subsection.A.3.2) 630 0 R (subsection.A.3.3) 634 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.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.26.1) 462 0 R (subsubsection.6.2.26.2) 466 0 R (subsubsection.6.2.26.3) 470 0 R (subsubsection.6.2.26.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 (subsubsection.6.4.0.1) 534 0 R (subsubsection.6.4.1.1) 542 0 R (subsubsection.6.4.1.2) 546 0 R (subsubsection.6.4.1.3) 550 0 R (subsubsection.6.4.1.4) 554 0 R (table.1.1) 937 0 R (table.1.2) 947 0 R (table.3.1) 1006 0 R (table.3.2) 1038 0 R (table.6.1) 1146 0 R (table.6.10) 1498 0 R (table.6.11) 1509 0 R (table.6.12) 1516 0 R (table.6.13) 1518 0 R (table.6.14) 1525 0 R (table.6.15) 1528 0 R (table.6.16) 1531 0 R (table.6.17) 1546 0 R (table.6.18) 1554 0 R (table.6.19) 1563 0 R (table.6.2) 1170 0 R (table.6.20) 1570 0 R (table.6.21) 1577 0 R (table.6.3) 1178 0 R (table.6.4) 1217 0 R (table.6.5) 1262 0 R (table.6.6) 1353 0 R (table.6.7) 1422 0 R (table.6.8) 1486 0 R (table.6.9) 1496 0 R (the_category_phrase) 1211 0 R (the_sortlist_statement) 1343 0 R (topology) 1338 0 R (tsig) 1085 0 R (tuning) 1354 0 R (types_of_resource_records_and_when_to_use_them) 954 0 R (view_statement_grammar) 1371 0 R (zone_statement_grammar) 1292 0 R (zone_transfers) 1061 0 R (zonefile_format) 1370 0 R] +/Limits [(Access_Control_Lists) (zonefile_format)] +>> endobj +2116 0 obj << +/Kids [2115 0 R] +>> endobj +2117 0 obj << +/Dests 2116 0 R +>> endobj +2118 0 obj << +/Type /Catalog +/Pages 2113 0 R +/Outlines 2114 0 R +/Names 2117 0 R +/PageMode /UseOutlines +/OpenAction 693 0 R +>> endobj +2119 0 obj << +/Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords() +/CreationDate (D:20081116011130Z) +/PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4) +>> endobj +xref +0 2120 +0000000001 65535 f +0000000002 00000 f +0000000003 00000 f +0000000004 00000 f +0000000000 00000 f +0000000009 00000 n +0000070820 00000 n +0000731720 00000 n +0000000054 00000 n +0000000086 00000 n +0000070944 00000 n +0000731648 00000 n +0000000133 00000 n +0000000173 00000 n +0000071069 00000 n +0000731562 00000 n +0000000221 00000 n +0000000273 00000 n +0000071194 00000 n +0000731476 00000 n +0000000321 00000 n +0000000377 00000 n +0000075519 00000 n +0000731366 00000 n +0000000425 00000 n +0000000478 00000 n +0000075643 00000 n +0000731292 00000 n +0000000531 00000 n +0000000572 00000 n +0000075768 00000 n +0000731205 00000 n +0000000625 00000 n +0000000674 00000 n +0000075892 00000 n +0000731118 00000 n +0000000727 00000 n +0000000757 00000 n +0000080171 00000 n +0000730994 00000 n +0000000810 00000 n +0000000861 00000 n +0000080296 00000 n +0000730920 00000 n +0000000919 00000 n +0000000964 00000 n +0000080421 00000 n +0000730833 00000 n +0000001022 00000 n +0000001062 00000 n +0000080546 00000 n +0000730759 00000 n +0000001120 00000 n +0000001162 00000 n +0000083518 00000 n +0000730635 00000 n +0000001215 00000 n +0000001260 00000 n +0000083643 00000 n +0000730574 00000 n +0000001318 00000 n +0000001355 00000 n +0000083768 00000 n +0000730500 00000 n +0000001408 00000 n +0000001463 00000 n +0000086696 00000 n +0000730375 00000 n +0000001509 00000 n +0000001556 00000 n +0000086821 00000 n +0000730301 00000 n +0000001604 00000 n +0000001648 00000 n +0000086946 00000 n +0000730214 00000 n +0000001696 00000 n +0000001735 00000 n +0000087071 00000 n +0000730127 00000 n +0000001783 00000 n +0000001825 00000 n +0000087195 00000 n +0000730040 00000 n +0000001873 00000 n +0000001936 00000 n +0000088275 00000 n +0000729966 00000 n +0000001984 00000 n +0000002034 00000 n +0000089985 00000 n +0000729838 00000 n +0000002080 00000 n +0000002126 00000 n +0000090109 00000 n +0000729725 00000 n +0000002174 00000 n +0000002218 00000 n +0000090234 00000 n +0000729649 00000 n +0000002271 00000 n +0000002323 00000 n +0000090359 00000 n +0000729572 00000 n +0000002377 00000 n +0000002436 00000 n +0000092896 00000 n +0000729481 00000 n +0000002485 00000 n +0000002523 00000 n +0000093155 00000 n +0000729364 00000 n +0000002572 00000 n +0000002618 00000 n +0000093284 00000 n +0000729246 00000 n +0000002672 00000 n +0000002739 00000 n +0000096500 00000 n +0000729167 00000 n +0000002798 00000 n +0000002842 00000 n +0000096628 00000 n +0000729088 00000 n +0000002901 00000 n +0000002949 00000 n +0000107160 00000 n +0000729009 00000 n +0000003003 00000 n +0000003036 00000 n +0000112147 00000 n +0000728877 00000 n +0000003083 00000 n +0000003126 00000 n +0000112276 00000 n +0000728798 00000 n +0000003175 00000 n +0000003205 00000 n +0000112405 00000 n +0000728666 00000 n +0000003254 00000 n +0000003292 00000 n +0000112534 00000 n +0000728601 00000 n +0000003346 00000 n +0000003388 00000 n +0000116796 00000 n +0000728508 00000 n +0000003437 00000 n +0000003496 00000 n +0000116925 00000 n +0000728376 00000 n +0000003545 00000 n +0000003578 00000 n +0000117054 00000 n +0000728311 00000 n +0000003632 00000 n +0000003681 00000 n +0000124364 00000 n +0000728179 00000 n +0000003730 00000 n +0000003758 00000 n +0000124493 00000 n +0000728061 00000 n +0000003812 00000 n +0000003881 00000 n +0000124622 00000 n +0000727982 00000 n +0000003940 00000 n +0000003988 00000 n +0000127456 00000 n +0000727903 00000 n +0000004047 00000 n +0000004092 00000 n +0000127585 00000 n +0000727810 00000 n +0000004146 00000 n +0000004214 00000 n +0000127714 00000 n +0000727717 00000 n +0000004268 00000 n +0000004338 00000 n +0000127843 00000 n +0000727624 00000 n +0000004392 00000 n +0000004455 00000 n +0000131746 00000 n +0000727531 00000 n +0000004509 00000 n +0000004564 00000 n +0000131875 00000 n +0000727452 00000 n +0000004618 00000 n +0000004650 00000 n +0000132004 00000 n +0000727359 00000 n +0000004699 00000 n +0000004727 00000 n +0000132133 00000 n +0000727266 00000 n +0000004776 00000 n +0000004808 00000 n +0000135910 00000 n +0000727134 00000 n +0000004857 00000 n +0000004887 00000 n +0000136039 00000 n +0000727055 00000 n +0000004941 00000 n +0000004982 00000 n +0000136168 00000 n +0000726962 00000 n +0000005036 00000 n +0000005078 00000 n +0000139609 00000 n +0000726883 00000 n +0000005132 00000 n +0000005177 00000 n +0000142684 00000 n +0000726765 00000 n +0000005226 00000 n +0000005272 00000 n +0000142813 00000 n +0000726686 00000 n +0000005326 00000 n +0000005386 00000 n +0000142941 00000 n +0000726607 00000 n +0000005440 00000 n +0000005509 00000 n +0000145423 00000 n +0000726474 00000 n +0000005556 00000 n +0000005609 00000 n +0000145552 00000 n +0000726395 00000 n +0000005658 00000 n +0000005714 00000 n +0000145681 00000 n +0000726316 00000 n +0000005763 00000 n +0000005812 00000 n +0000149865 00000 n +0000726183 00000 n +0000005859 00000 n +0000005911 00000 n +0000149994 00000 n +0000726065 00000 n +0000005960 00000 n +0000006011 00000 n +0000154684 00000 n +0000725947 00000 n +0000006065 00000 n +0000006110 00000 n +0000154812 00000 n +0000725868 00000 n +0000006169 00000 n +0000006203 00000 n +0000158401 00000 n +0000725789 00000 n +0000006262 00000 n +0000006310 00000 n +0000158529 00000 n +0000725671 00000 n +0000006364 00000 n +0000006404 00000 n +0000158658 00000 n +0000725592 00000 n +0000006463 00000 n +0000006497 00000 n +0000162385 00000 n +0000725513 00000 n +0000006556 00000 n +0000006604 00000 n +0000162514 00000 n +0000725380 00000 n +0000006653 00000 n +0000006703 00000 n +0000165534 00000 n +0000725301 00000 n +0000006757 00000 n +0000006804 00000 n +0000165662 00000 n +0000725208 00000 n +0000006858 00000 n +0000006918 00000 n +0000165920 00000 n +0000725115 00000 n +0000006972 00000 n +0000007024 00000 n +0000171027 00000 n +0000725022 00000 n +0000007078 00000 n +0000007143 00000 n +0000171156 00000 n +0000724929 00000 n +0000007197 00000 n +0000007248 00000 n +0000174630 00000 n +0000724836 00000 n +0000007302 00000 n +0000007366 00000 n +0000174759 00000 n +0000724743 00000 n +0000007420 00000 n +0000007467 00000 n +0000174888 00000 n +0000724650 00000 n +0000007521 00000 n +0000007581 00000 n +0000175017 00000 n +0000724557 00000 n +0000007635 00000 n +0000007686 00000 n +0000179033 00000 n +0000724425 00000 n +0000007741 00000 n +0000007806 00000 n +0000179162 00000 n +0000724346 00000 n +0000007866 00000 n +0000007913 00000 n +0000185987 00000 n +0000724267 00000 n +0000007973 00000 n +0000008021 00000 n +0000192355 00000 n +0000724174 00000 n +0000008076 00000 n +0000008126 00000 n +0000192484 00000 n +0000724081 00000 n +0000008181 00000 n +0000008244 00000 n +0000192612 00000 n +0000723988 00000 n +0000008299 00000 n +0000008351 00000 n +0000192740 00000 n +0000723895 00000 n +0000008406 00000 n +0000008471 00000 n +0000192869 00000 n +0000723802 00000 n +0000008526 00000 n +0000008578 00000 n +0000198137 00000 n +0000723669 00000 n +0000008633 00000 n +0000008698 00000 n +0000206589 00000 n +0000723590 00000 n +0000008758 00000 n +0000008802 00000 n +0000227810 00000 n +0000723497 00000 n +0000008862 00000 n +0000008901 00000 n +0000227938 00000 n +0000723404 00000 n +0000008961 00000 n +0000009008 00000 n +0000228067 00000 n +0000723311 00000 n +0000009068 00000 n +0000009111 00000 n +0000235196 00000 n +0000723218 00000 n +0000009171 00000 n +0000009210 00000 n +0000235325 00000 n +0000723125 00000 n +0000009270 00000 n +0000009312 00000 n +0000242275 00000 n +0000723032 00000 n +0000009372 00000 n +0000009415 00000 n +0000250260 00000 n +0000722939 00000 n +0000009475 00000 n +0000009518 00000 n +0000250389 00000 n +0000722846 00000 n +0000009578 00000 n +0000009639 00000 n +0000254380 00000 n +0000722753 00000 n +0000009700 00000 n +0000009752 00000 n +0000257620 00000 n +0000722660 00000 n +0000009813 00000 n +0000009866 00000 n +0000257749 00000 n +0000722567 00000 n +0000009927 00000 n +0000009965 00000 n +0000261821 00000 n +0000722474 00000 n +0000010026 00000 n +0000010078 00000 n +0000265032 00000 n +0000722381 00000 n +0000010139 00000 n +0000010183 00000 n +0000265290 00000 n +0000722288 00000 n +0000010244 00000 n +0000010280 00000 n +0000274081 00000 n +0000722195 00000 n +0000010341 00000 n +0000010404 00000 n +0000277408 00000 n +0000722102 00000 n +0000010465 00000 n +0000010515 00000 n +0000281163 00000 n +0000722023 00000 n +0000010576 00000 n +0000010632 00000 n +0000284537 00000 n +0000721930 00000 n +0000010687 00000 n +0000010751 00000 n +0000284666 00000 n +0000721837 00000 n +0000010806 00000 n +0000010883 00000 n +0000284794 00000 n +0000721744 00000 n +0000010938 00000 n +0000010989 00000 n +0000289362 00000 n +0000721651 00000 n +0000011044 00000 n +0000011108 00000 n +0000292729 00000 n +0000721558 00000 n +0000011163 00000 n +0000011220 00000 n +0000292857 00000 n +0000721465 00000 n +0000011275 00000 n +0000011345 00000 n +0000292986 00000 n +0000721372 00000 n +0000011400 00000 n +0000011449 00000 n +0000293115 00000 n +0000721279 00000 n +0000011504 00000 n +0000011566 00000 n +0000297818 00000 n +0000721186 00000 n +0000011621 00000 n +0000011670 00000 n +0000301909 00000 n +0000721068 00000 n +0000011725 00000 n +0000011787 00000 n +0000302038 00000 n +0000720989 00000 n +0000011847 00000 n +0000011886 00000 n +0000306096 00000 n +0000720896 00000 n +0000011946 00000 n +0000011980 00000 n +0000311992 00000 n +0000720803 00000 n +0000012040 00000 n +0000012081 00000 n +0000323134 00000 n +0000720724 00000 n +0000012141 00000 n +0000012193 00000 n +0000330383 00000 n +0000720592 00000 n +0000012242 00000 n +0000012275 00000 n +0000330512 00000 n +0000720474 00000 n +0000012329 00000 n +0000012401 00000 n +0000330640 00000 n +0000720395 00000 n +0000012460 00000 n +0000012504 00000 n +0000341427 00000 n +0000720316 00000 n +0000012563 00000 n +0000012616 00000 n +0000341814 00000 n +0000720223 00000 n +0000012670 00000 n +0000012720 00000 n +0000345189 00000 n +0000720130 00000 n +0000012774 00000 n +0000012812 00000 n +0000345448 00000 n +0000720037 00000 n +0000012866 00000 n +0000012915 00000 n +0000348312 00000 n +0000719905 00000 n +0000012969 00000 n +0000013021 00000 n +0000348440 00000 n +0000719826 00000 n +0000013080 00000 n +0000013132 00000 n +0000348569 00000 n +0000719733 00000 n +0000013191 00000 n +0000013244 00000 n +0000348698 00000 n +0000719654 00000 n +0000013303 00000 n +0000013352 00000 n +0000352344 00000 n +0000719561 00000 n +0000013406 00000 n +0000013486 00000 n +0000356394 00000 n +0000719482 00000 n +0000013540 00000 n +0000013589 00000 n +0000356523 00000 n +0000719364 00000 n +0000013638 00000 n +0000013678 00000 n +0000359826 00000 n +0000719285 00000 n +0000013737 00000 n +0000013784 00000 n +0000359955 00000 n +0000719167 00000 n +0000013838 00000 n +0000013883 00000 n +0000360084 00000 n +0000719088 00000 n +0000013942 00000 n +0000014001 00000 n +0000363183 00000 n +0000718995 00000 n +0000014060 00000 n +0000014124 00000 n +0000363442 00000 n +0000718902 00000 n +0000014183 00000 n +0000014239 00000 n +0000366164 00000 n +0000718823 00000 n +0000014298 00000 n +0000014360 00000 n +0000368398 00000 n +0000718690 00000 n +0000014407 00000 n +0000014459 00000 n +0000368527 00000 n +0000718611 00000 n +0000014508 00000 n +0000014552 00000 n +0000372713 00000 n +0000718479 00000 n +0000014601 00000 n +0000014642 00000 n +0000372842 00000 n +0000718400 00000 n +0000014696 00000 n +0000014744 00000 n +0000372970 00000 n +0000718321 00000 n +0000014798 00000 n +0000014849 00000 n +0000373099 00000 n +0000718242 00000 n +0000014898 00000 n +0000014945 00000 n +0000377366 00000 n +0000718109 00000 n +0000014992 00000 n +0000015029 00000 n +0000377495 00000 n +0000717991 00000 n +0000015078 00000 n +0000015117 00000 n +0000377624 00000 n +0000717926 00000 n +0000015171 00000 n +0000015249 00000 n +0000377753 00000 n +0000717833 00000 n +0000015298 00000 n +0000015365 00000 n +0000377882 00000 n +0000717754 00000 n +0000015414 00000 n +0000015459 00000 n +0000381321 00000 n +0000717621 00000 n +0000015507 00000 n +0000015539 00000 n +0000381450 00000 n +0000717503 00000 n +0000015588 00000 n +0000015627 00000 n +0000381579 00000 n +0000717438 00000 n +0000015681 00000 n +0000015742 00000 n +0000385344 00000 n +0000717306 00000 n +0000015791 00000 n +0000015848 00000 n +0000385473 00000 n +0000717241 00000 n +0000015902 00000 n +0000015951 00000 n +0000385602 00000 n +0000717123 00000 n +0000016000 00000 n +0000016062 00000 n +0000385731 00000 n +0000717044 00000 n +0000016116 00000 n +0000016171 00000 n +0000409752 00000 n +0000716951 00000 n +0000016225 00000 n +0000016266 00000 n +0000409881 00000 n +0000716872 00000 n +0000016320 00000 n +0000016372 00000 n +0000412612 00000 n +0000716752 00000 n +0000016420 00000 n +0000016454 00000 n +0000412741 00000 n +0000716673 00000 n +0000016503 00000 n +0000016530 00000 n +0000430434 00000 n +0000716580 00000 n +0000016579 00000 n +0000016607 00000 n +0000437928 00000 n +0000716487 00000 n +0000016656 00000 n +0000016696 00000 n +0000440723 00000 n +0000716394 00000 n +0000016745 00000 n +0000016788 00000 n +0000446647 00000 n +0000716301 00000 n +0000016837 00000 n +0000016874 00000 n +0000453150 00000 n +0000716208 00000 n +0000016923 00000 n +0000016962 00000 n +0000462862 00000 n +0000716115 00000 n +0000017011 00000 n +0000017050 00000 n +0000465578 00000 n +0000716022 00000 n +0000017099 00000 n +0000017138 00000 n +0000475305 00000 n +0000715929 00000 n +0000017187 00000 n +0000017216 00000 n +0000481121 00000 n +0000715836 00000 n +0000017266 00000 n +0000017299 00000 n +0000495077 00000 n +0000715743 00000 n +0000017349 00000 n +0000017378 00000 n +0000498576 00000 n +0000715650 00000 n +0000017428 00000 n +0000017462 00000 n +0000504687 00000 n +0000715571 00000 n +0000017512 00000 n +0000017549 00000 n +0000017918 00000 n +0000018040 00000 n +0000025869 00000 n +0000017602 00000 n +0000025743 00000 n +0000025806 00000 n +0000711071 00000 n +0000685128 00000 n +0000710897 00000 n +0000712096 00000 n +0000020903 00000 n +0000021120 00000 n +0000021189 00000 n +0000021258 00000 n +0000021326 00000 n +0000021394 00000 n +0000021443 00000 n +0000021490 00000 n +0000021823 00000 n +0000021845 00000 n +0000022013 00000 n +0000022178 00000 n +0000022347 00000 n +0000022526 00000 n +0000022835 00000 n +0000022995 00000 n +0000027233 00000 n +0000027048 00000 n +0000025969 00000 n +0000027170 00000 n +0000683907 00000 n +0000657386 00000 n +0000683733 00000 n +0000656701 00000 n +0000654557 00000 n +0000656537 00000 n +0000038940 00000 n +0000030289 00000 n +0000027318 00000 n +0000038814 00000 n +0000038877 00000 n +0000030823 00000 n +0000030977 00000 n +0000031134 00000 n +0000031291 00000 n +0000031447 00000 n +0000031604 00000 n +0000031766 00000 n +0000031927 00000 n +0000032088 00000 n +0000032250 00000 n +0000032417 00000 n +0000032584 00000 n +0000032749 00000 n +0000032911 00000 n +0000033077 00000 n +0000033238 00000 n +0000033393 00000 n +0000033550 00000 n +0000033706 00000 n +0000033863 00000 n +0000034020 00000 n +0000034177 00000 n +0000034331 00000 n +0000034487 00000 n +0000034649 00000 n +0000034811 00000 n +0000034967 00000 n +0000035124 00000 n +0000035286 00000 n +0000035453 00000 n +0000035619 00000 n +0000035780 00000 n +0000035935 00000 n +0000036092 00000 n +0000036249 00000 n +0000036411 00000 n +0000036568 00000 n +0000036725 00000 n +0000036887 00000 n +0000037044 00000 n +0000037206 00000 n +0000037373 00000 n +0000037539 00000 n +0000037701 00000 n +0000037863 00000 n +0000038025 00000 n +0000038187 00000 n +0000038349 00000 n +0000038504 00000 n +0000038659 00000 n +0000052318 00000 n +0000042272 00000 n +0000039025 00000 n +0000052255 00000 n +0000654006 00000 n +0000636925 00000 n +0000653822 00000 n +0000042862 00000 n +0000043025 00000 n +0000043187 00000 n +0000043350 00000 n +0000043508 00000 n +0000043671 00000 n +0000043834 00000 n +0000043989 00000 n +0000044147 00000 n +0000044305 00000 n +0000044461 00000 n +0000044619 00000 n +0000044782 00000 n +0000044950 00000 n +0000045118 00000 n +0000045281 00000 n +0000045449 00000 n +0000045617 00000 n +0000045775 00000 n +0000045938 00000 n +0000046101 00000 n +0000046263 00000 n +0000046425 00000 n +0000046588 00000 n +0000046750 00000 n +0000046912 00000 n +0000047075 00000 n +0000047238 00000 n +0000047401 00000 n +0000047570 00000 n +0000047739 00000 n +0000047903 00000 n +0000048066 00000 n +0000048230 00000 n +0000048394 00000 n +0000048557 00000 n +0000048721 00000 n +0000048890 00000 n +0000049059 00000 n +0000049228 00000 n +0000049397 00000 n +0000049566 00000 n +0000049735 00000 n +0000049904 00000 n +0000050073 00000 n +0000050242 00000 n +0000050412 00000 n +0000050582 00000 n +0000050752 00000 n +0000050922 00000 n +0000051092 00000 n +0000051262 00000 n +0000051432 00000 n +0000051601 00000 n +0000051771 00000 n +0000051932 00000 n +0000052093 00000 n +0000065459 00000 n +0000055941 00000 n +0000052416 00000 n +0000065396 00000 n +0000056515 00000 n +0000056678 00000 n +0000056841 00000 n +0000057004 00000 n +0000057167 00000 n +0000057330 00000 n +0000057493 00000 n +0000057656 00000 n +0000057824 00000 n +0000057991 00000 n +0000058159 00000 n +0000058327 00000 n +0000058484 00000 n +0000058646 00000 n +0000058811 00000 n +0000058977 00000 n +0000059139 00000 n +0000059301 00000 n +0000059463 00000 n +0000059625 00000 n +0000059792 00000 n +0000059959 00000 n +0000060126 00000 n +0000060288 00000 n +0000060450 00000 n +0000060607 00000 n +0000060774 00000 n +0000060936 00000 n +0000061103 00000 n +0000061270 00000 n +0000636036 00000 n +0000614704 00000 n +0000635862 00000 n +0000061437 00000 n +0000061604 00000 n +0000061759 00000 n +0000061916 00000 n +0000062073 00000 n +0000062235 00000 n +0000062396 00000 n +0000062552 00000 n +0000062707 00000 n +0000062864 00000 n +0000063026 00000 n +0000063183 00000 n +0000063340 00000 n +0000063496 00000 n +0000063652 00000 n +0000063813 00000 n +0000063970 00000 n +0000064132 00000 n +0000064289 00000 n +0000064451 00000 n +0000064613 00000 n +0000064775 00000 n +0000064931 00000 n +0000065086 00000 n +0000065241 00000 n +0000068260 00000 n +0000066412 00000 n +0000065570 00000 n +0000068197 00000 n +0000066626 00000 n +0000066783 00000 n +0000066940 00000 n +0000067096 00000 n +0000067253 00000 n +0000067409 00000 n +0000067566 00000 n +0000067724 00000 n +0000613738 00000 n +0000593771 00000 n +0000613565 00000 n +0000067882 00000 n +0000068039 00000 n +0000071445 00000 n +0000070635 00000 n +0000068358 00000 n +0000070757 00000 n +0000070881 00000 n +0000071006 00000 n +0000071131 00000 n +0000071256 00000 n +0000071319 00000 n +0000071382 00000 n +0000592977 00000 n +0000574660 00000 n +0000592804 00000 n +0000712214 00000 n +0000076016 00000 n +0000074836 00000 n +0000071569 00000 n +0000075330 00000 n +0000075393 00000 n +0000075456 00000 n +0000075580 00000 n +0000075705 00000 n +0000075830 00000 n +0000074986 00000 n +0000075179 00000 n +0000075953 00000 n +0000330576 00000 n +0000385795 00000 n +0000080671 00000 n +0000079635 00000 n +0000076140 00000 n +0000080108 00000 n +0000080233 00000 n +0000079785 00000 n +0000079947 00000 n +0000080358 00000 n +0000080483 00000 n +0000080608 00000 n +0000096564 00000 n +0000083893 00000 n +0000083333 00000 n +0000080795 00000 n +0000083455 00000 n +0000083580 00000 n +0000083705 00000 n +0000083830 00000 n +0000087320 00000 n +0000086179 00000 n +0000084004 00000 n +0000086633 00000 n +0000086758 00000 n +0000086883 00000 n +0000087008 00000 n +0000087133 00000 n +0000086329 00000 n +0000086481 00000 n +0000087257 00000 n +0000281227 00000 n +0000088400 00000 n +0000088090 00000 n +0000087405 00000 n +0000088212 00000 n +0000088337 00000 n +0000090485 00000 n +0000089800 00000 n +0000088498 00000 n +0000089922 00000 n +0000090047 00000 n +0000090171 00000 n +0000090296 00000 n +0000090422 00000 n +0000712332 00000 n +0000093412 00000 n +0000092524 00000 n +0000090583 00000 n +0000092831 00000 n +0000092960 00000 n +0000093025 00000 n +0000093090 00000 n +0000092670 00000 n +0000093219 00000 n +0000093348 00000 n +0000265096 00000 n +0000096757 00000 n +0000096310 00000 n +0000093524 00000 n +0000096435 00000 n +0000573985 00000 n +0000561996 00000 n +0000573806 00000 n +0000096692 00000 n +0000100548 00000 n +0000100358 00000 n +0000096883 00000 n +0000100483 00000 n +0000561455 00000 n +0000551709 00000 n +0000561276 00000 n +0000105074 00000 n +0000104676 00000 n +0000100714 00000 n +0000105009 00000 n +0000104822 00000 n +0000171091 00000 n +0000107419 00000 n +0000106970 00000 n +0000105213 00000 n +0000107095 00000 n +0000107224 00000 n +0000107289 00000 n +0000107354 00000 n +0000110116 00000 n +0000112663 00000 n +0000109960 00000 n +0000107544 00000 n +0000112082 00000 n +0000112211 00000 n +0000112340 00000 n +0000111759 00000 n +0000111921 00000 n +0000550839 00000 n +0000541419 00000 n +0000550665 00000 n +0000540855 00000 n +0000531769 00000 n +0000540680 00000 n +0000112469 00000 n +0000112598 00000 n +0000712455 00000 n +0000111588 00000 n +0000111646 00000 n +0000111736 00000 n +0000206653 00000 n +0000242339 00000 n +0000117183 00000 n +0000116248 00000 n +0000112819 00000 n +0000116731 00000 n +0000116860 00000 n +0000116404 00000 n +0000116569 00000 n +0000116989 00000 n +0000117118 00000 n +0000389821 00000 n +0000120797 00000 n +0000120417 00000 n +0000117335 00000 n +0000120732 00000 n +0000120564 00000 n +0000122047 00000 n +0000121856 00000 n +0000120922 00000 n +0000121982 00000 n +0000124750 00000 n +0000124173 00000 n +0000122146 00000 n +0000124299 00000 n +0000124428 00000 n +0000124557 00000 n +0000124686 00000 n +0000127972 00000 n +0000127265 00000 n +0000124888 00000 n +0000127391 00000 n +0000127520 00000 n +0000127649 00000 n +0000127778 00000 n +0000127907 00000 n +0000132261 00000 n +0000131363 00000 n +0000128097 00000 n +0000131681 00000 n +0000131810 00000 n +0000131510 00000 n +0000131939 00000 n +0000132068 00000 n +0000132196 00000 n +0000712580 00000 n +0000323198 00000 n +0000136297 00000 n +0000135719 00000 n +0000132386 00000 n +0000135845 00000 n +0000135974 00000 n +0000136103 00000 n +0000136232 00000 n +0000139738 00000 n +0000139418 00000 n +0000136435 00000 n +0000139544 00000 n +0000139673 00000 n +0000143070 00000 n +0000142311 00000 n +0000139850 00000 n +0000142619 00000 n +0000142748 00000 n +0000142458 00000 n +0000142877 00000 n +0000143005 00000 n +0000385537 00000 n +0000145810 00000 n +0000145232 00000 n +0000143238 00000 n +0000145358 00000 n +0000145487 00000 n +0000145616 00000 n +0000145745 00000 n +0000146250 00000 n +0000146059 00000 n +0000145909 00000 n +0000146185 00000 n +0000150252 00000 n +0000149486 00000 n +0000146292 00000 n +0000149800 00000 n +0000149929 00000 n +0000150057 00000 n +0000150122 00000 n +0000150187 00000 n +0000149633 00000 n +0000712705 00000 n +0000154748 00000 n +0000154940 00000 n +0000154493 00000 n +0000150351 00000 n +0000154619 00000 n +0000154875 00000 n +0000158787 00000 n +0000158210 00000 n +0000155065 00000 n +0000158336 00000 n +0000158464 00000 n +0000158593 00000 n +0000158722 00000 n +0000161394 00000 n +0000162773 00000 n +0000161268 00000 n +0000158925 00000 n +0000162320 00000 n +0000162449 00000 n +0000162578 00000 n +0000162643 00000 n +0000162708 00000 n +0000166049 00000 n +0000165343 00000 n +0000162928 00000 n +0000165469 00000 n +0000165597 00000 n +0000165726 00000 n +0000165790 00000 n +0000165855 00000 n +0000165984 00000 n +0000171284 00000 n +0000170496 00000 n +0000166161 00000 n +0000170962 00000 n +0000170652 00000 n +0000170803 00000 n +0000171220 00000 n +0000510397 00000 n +0000175146 00000 n +0000173875 00000 n +0000171422 00000 n +0000174565 00000 n +0000174694 00000 n +0000174823 00000 n +0000174952 00000 n +0000174040 00000 n +0000174192 00000 n +0000174378 00000 n +0000175081 00000 n +0000712830 00000 n +0000179291 00000 n +0000178842 00000 n +0000175272 00000 n +0000178968 00000 n +0000179097 00000 n +0000179226 00000 n +0000183212 00000 n +0000182833 00000 n +0000179416 00000 n +0000183147 00000 n +0000182980 00000 n +0000186051 00000 n +0000186245 00000 n +0000185796 00000 n +0000183324 00000 n +0000185922 00000 n +0000186116 00000 n +0000186181 00000 n +0000189675 00000 n +0000189484 00000 n +0000186357 00000 n +0000189610 00000 n +0000192997 00000 n +0000191830 00000 n +0000189787 00000 n +0000192290 00000 n +0000192419 00000 n +0000192548 00000 n +0000191986 00000 n +0000192140 00000 n +0000192676 00000 n +0000192804 00000 n +0000192932 00000 n +0000194483 00000 n +0000194292 00000 n +0000193109 00000 n +0000194418 00000 n +0000712955 00000 n +0000196016 00000 n +0000195825 00000 n +0000194582 00000 n +0000195951 00000 n +0000198266 00000 n +0000197946 00000 n +0000196115 00000 n +0000198072 00000 n +0000198201 00000 n +0000202789 00000 n +0000202420 00000 n +0000198378 00000 n +0000202724 00000 n +0000202567 00000 n +0000359890 00000 n +0000206718 00000 n +0000206398 00000 n +0000202927 00000 n +0000206524 00000 n +0000210794 00000 n +0000210300 00000 n +0000206843 00000 n +0000210599 00000 n +0000210664 00000 n +0000210729 00000 n +0000210447 00000 n +0000215794 00000 n +0000214662 00000 n +0000210919 00000 n +0000215729 00000 n +0000214845 00000 n +0000215002 00000 n +0000215186 00000 n +0000215359 00000 n +0000215544 00000 n +0000713080 00000 n +0000289426 00000 n +0000220074 00000 n +0000219883 00000 n +0000215975 00000 n +0000220009 00000 n +0000223936 00000 n +0000223745 00000 n +0000220199 00000 n +0000223871 00000 n +0000228196 00000 n +0000227253 00000 n +0000224048 00000 n +0000227745 00000 n +0000227873 00000 n +0000227409 00000 n +0000228002 00000 n +0000228131 00000 n +0000227579 00000 n +0000297882 00000 n +0000232129 00000 n +0000231567 00000 n +0000228365 00000 n +0000232064 00000 n +0000231723 00000 n +0000231893 00000 n +0000373163 00000 n +0000235454 00000 n +0000235005 00000 n +0000232298 00000 n +0000235131 00000 n +0000235260 00000 n +0000235389 00000 n +0000238850 00000 n +0000238659 00000 n +0000235579 00000 n +0000238785 00000 n +0000713205 00000 n +0000242404 00000 n +0000242084 00000 n +0000239019 00000 n +0000242210 00000 n +0000246107 00000 n +0000245916 00000 n +0000242560 00000 n +0000246042 00000 n +0000250518 00000 n +0000249704 00000 n +0000246276 00000 n +0000250195 00000 n +0000250324 00000 n +0000249860 00000 n +0000250453 00000 n +0000250021 00000 n +0000254509 00000 n +0000254014 00000 n +0000250673 00000 n +0000254315 00000 n +0000254444 00000 n +0000254161 00000 n +0000257878 00000 n +0000257429 00000 n +0000254634 00000 n +0000257555 00000 n +0000257684 00000 n +0000257813 00000 n +0000261950 00000 n +0000261283 00000 n +0000258033 00000 n +0000261756 00000 n +0000261885 00000 n +0000261439 00000 n +0000261601 00000 n +0000713330 00000 n +0000265418 00000 n +0000264650 00000 n +0000262119 00000 n +0000264967 00000 n +0000264797 00000 n +0000265160 00000 n +0000265225 00000 n +0000265354 00000 n +0000269455 00000 n +0000269083 00000 n +0000265601 00000 n +0000269390 00000 n +0000269230 00000 n +0000274209 00000 n +0000273530 00000 n +0000269623 00000 n +0000274016 00000 n +0000273686 00000 n +0000531414 00000 n +0000529417 00000 n +0000531249 00000 n +0000274144 00000 n +0000273849 00000 n +0000356458 00000 n +0000293050 00000 n +0000277537 00000 n +0000277217 00000 n +0000274335 00000 n +0000277343 00000 n +0000277472 00000 n +0000281291 00000 n +0000280972 00000 n +0000277662 00000 n +0000281098 00000 n +0000284923 00000 n +0000284346 00000 n +0000281433 00000 n +0000284472 00000 n +0000284601 00000 n +0000284730 00000 n +0000284858 00000 n +0000713455 00000 n +0000289491 00000 n +0000289000 00000 n +0000285035 00000 n +0000289297 00000 n +0000289147 00000 n +0000293243 00000 n +0000292193 00000 n +0000289603 00000 n +0000292664 00000 n +0000292349 00000 n +0000292792 00000 n +0000292921 00000 n +0000292511 00000 n +0000293179 00000 n +0000296310 00000 n +0000296119 00000 n +0000293355 00000 n +0000296245 00000 n +0000297947 00000 n +0000297627 00000 n +0000296422 00000 n +0000297753 00000 n +0000299421 00000 n +0000299230 00000 n +0000298059 00000 n +0000299356 00000 n +0000302297 00000 n +0000301718 00000 n +0000299520 00000 n +0000301844 00000 n +0000301973 00000 n +0000302102 00000 n +0000302167 00000 n +0000302232 00000 n +0000713580 00000 n +0000306225 00000 n +0000305905 00000 n +0000302409 00000 n +0000306031 00000 n +0000306160 00000 n +0000312121 00000 n +0000309387 00000 n +0000306337 00000 n +0000311927 00000 n +0000312056 00000 n +0000309651 00000 n +0000309813 00000 n +0000309975 00000 n +0000310136 00000 n +0000310296 00000 n +0000310458 00000 n +0000310629 00000 n +0000310791 00000 n +0000310953 00000 n +0000311114 00000 n +0000311275 00000 n +0000311438 00000 n +0000311601 00000 n +0000311764 00000 n +0000317105 00000 n +0000315364 00000 n +0000312233 00000 n +0000317040 00000 n +0000315583 00000 n +0000315744 00000 n +0000315913 00000 n +0000316075 00000 n +0000316237 00000 n +0000316399 00000 n +0000316560 00000 n +0000316723 00000 n +0000316877 00000 n +0000323263 00000 n +0000320266 00000 n +0000317230 00000 n +0000323069 00000 n +0000320548 00000 n +0000320702 00000 n +0000320856 00000 n +0000321010 00000 n +0000321164 00000 n +0000321325 00000 n +0000321487 00000 n +0000321647 00000 n +0000321807 00000 n +0000321969 00000 n +0000322129 00000 n +0000322288 00000 n +0000322439 00000 n +0000322602 00000 n +0000322753 00000 n +0000322915 00000 n +0000326791 00000 n +0000326470 00000 n +0000323375 00000 n +0000326596 00000 n +0000326661 00000 n +0000326726 00000 n +0000331027 00000 n +0000329830 00000 n +0000326960 00000 n +0000330318 00000 n +0000330447 00000 n +0000330704 00000 n +0000329986 00000 n +0000330156 00000 n +0000330769 00000 n +0000330834 00000 n +0000330899 00000 n +0000330963 00000 n +0000713705 00000 n +0000334374 00000 n +0000334183 00000 n +0000331209 00000 n +0000334309 00000 n +0000338114 00000 n +0000337793 00000 n +0000334460 00000 n +0000337919 00000 n +0000337984 00000 n +0000338049 00000 n +0000341943 00000 n +0000341236 00000 n +0000338226 00000 n +0000341362 00000 n +0000341491 00000 n +0000341554 00000 n +0000341619 00000 n +0000341684 00000 n +0000341749 00000 n +0000341878 00000 n +0000345707 00000 n +0000344868 00000 n +0000342055 00000 n +0000344994 00000 n +0000345059 00000 n +0000345124 00000 n +0000345253 00000 n +0000345318 00000 n +0000345383 00000 n +0000345512 00000 n +0000345577 00000 n +0000345642 00000 n +0000348826 00000 n +0000348121 00000 n +0000345832 00000 n +0000348247 00000 n +0000348375 00000 n +0000348504 00000 n +0000348633 00000 n +0000348762 00000 n +0000352603 00000 n +0000352153 00000 n +0000349023 00000 n +0000352279 00000 n +0000352408 00000 n +0000352473 00000 n +0000352538 00000 n +0000713830 00000 n +0000356782 00000 n +0000356024 00000 n +0000352742 00000 n +0000356329 00000 n +0000356587 00000 n +0000356652 00000 n +0000356717 00000 n +0000356171 00000 n +0000360343 00000 n +0000359635 00000 n +0000356907 00000 n +0000359761 00000 n +0000360019 00000 n +0000360148 00000 n +0000360213 00000 n +0000360278 00000 n +0000363634 00000 n +0000362992 00000 n +0000360455 00000 n +0000363118 00000 n +0000363247 00000 n +0000363312 00000 n +0000363377 00000 n +0000363506 00000 n +0000363570 00000 n +0000366293 00000 n +0000365908 00000 n +0000363746 00000 n +0000366034 00000 n +0000366099 00000 n +0000529136 00000 n +0000521853 00000 n +0000528956 00000 n +0000366228 00000 n +0000366760 00000 n +0000366569 00000 n +0000366419 00000 n +0000366695 00000 n +0000368655 00000 n +0000368207 00000 n +0000366802 00000 n +0000368333 00000 n +0000368462 00000 n +0000368591 00000 n +0000713955 00000 n +0000373228 00000 n +0000372285 00000 n +0000368767 00000 n +0000372648 00000 n +0000521532 00000 n +0000512319 00000 n +0000521346 00000 n +0000372432 00000 n +0000372777 00000 n +0000372905 00000 n +0000373034 00000 n +0000374270 00000 n +0000374079 00000 n +0000373465 00000 n +0000374205 00000 n +0000374697 00000 n +0000374506 00000 n +0000374356 00000 n +0000374632 00000 n +0000378010 00000 n +0000376784 00000 n +0000374739 00000 n +0000377301 00000 n +0000377430 00000 n +0000377559 00000 n +0000377688 00000 n +0000377817 00000 n +0000377946 00000 n +0000376940 00000 n +0000377112 00000 n +0000378464 00000 n +0000378273 00000 n +0000378123 00000 n +0000378399 00000 n +0000381708 00000 n +0000381130 00000 n +0000378506 00000 n +0000381256 00000 n +0000381385 00000 n +0000381514 00000 n +0000381643 00000 n +0000714080 00000 n +0000385987 00000 n +0000384768 00000 n +0000381794 00000 n +0000385279 00000 n +0000385408 00000 n +0000385666 00000 n +0000384924 00000 n +0000385103 00000 n +0000385859 00000 n +0000385923 00000 n +0000392873 00000 n +0000389045 00000 n +0000386140 00000 n +0000389171 00000 n +0000389236 00000 n +0000389301 00000 n +0000389366 00000 n +0000389431 00000 n +0000389496 00000 n +0000389561 00000 n +0000389626 00000 n +0000389691 00000 n +0000389756 00000 n +0000389886 00000 n +0000389951 00000 n +0000390016 00000 n +0000390081 00000 n +0000390146 00000 n +0000390211 00000 n +0000390276 00000 n +0000390341 00000 n +0000390406 00000 n +0000390471 00000 n +0000390536 00000 n +0000390601 00000 n +0000390666 00000 n +0000390731 00000 n +0000390796 00000 n +0000390861 00000 n +0000390926 00000 n +0000390991 00000 n +0000391056 00000 n +0000391121 00000 n +0000391186 00000 n +0000391251 00000 n +0000391316 00000 n +0000391381 00000 n +0000391445 00000 n +0000391510 00000 n +0000391575 00000 n +0000391640 00000 n +0000391705 00000 n +0000391770 00000 n +0000391835 00000 n +0000391900 00000 n +0000391965 00000 n +0000392030 00000 n +0000392095 00000 n +0000392160 00000 n +0000392225 00000 n +0000392290 00000 n +0000392355 00000 n +0000392420 00000 n +0000392485 00000 n +0000392550 00000 n +0000392615 00000 n +0000392680 00000 n +0000392745 00000 n +0000392809 00000 n +0000399519 00000 n +0000395955 00000 n +0000392985 00000 n +0000396081 00000 n +0000396146 00000 n +0000396211 00000 n +0000396276 00000 n +0000396341 00000 n +0000396406 00000 n +0000396471 00000 n +0000396536 00000 n +0000396601 00000 n +0000396666 00000 n +0000396731 00000 n +0000396796 00000 n +0000396860 00000 n +0000396925 00000 n +0000396990 00000 n +0000397055 00000 n +0000397120 00000 n +0000397185 00000 n +0000397250 00000 n +0000397315 00000 n +0000397380 00000 n +0000397445 00000 n +0000397510 00000 n +0000397575 00000 n +0000397639 00000 n +0000397704 00000 n +0000397769 00000 n +0000397834 00000 n +0000397899 00000 n +0000397964 00000 n +0000398029 00000 n +0000398094 00000 n +0000398159 00000 n +0000398224 00000 n +0000398289 00000 n +0000398354 00000 n +0000398419 00000 n +0000398484 00000 n +0000398549 00000 n +0000398614 00000 n +0000398678 00000 n +0000398742 00000 n +0000398806 00000 n +0000398871 00000 n +0000398936 00000 n +0000399001 00000 n +0000399066 00000 n +0000399131 00000 n +0000399196 00000 n +0000399261 00000 n +0000399326 00000 n +0000399391 00000 n +0000399455 00000 n +0000405692 00000 n +0000402254 00000 n +0000399631 00000 n +0000402380 00000 n +0000402445 00000 n +0000402510 00000 n +0000402575 00000 n +0000402640 00000 n +0000402705 00000 n +0000402770 00000 n +0000402835 00000 n +0000402900 00000 n +0000402965 00000 n +0000403030 00000 n +0000403095 00000 n +0000403160 00000 n +0000403225 00000 n +0000403290 00000 n +0000403355 00000 n +0000403420 00000 n +0000403485 00000 n +0000403550 00000 n +0000403615 00000 n +0000403680 00000 n +0000403745 00000 n +0000403810 00000 n +0000403875 00000 n +0000403940 00000 n +0000404005 00000 n +0000404070 00000 n +0000404135 00000 n +0000404200 00000 n +0000404265 00000 n +0000404330 00000 n +0000404395 00000 n +0000404460 00000 n +0000404525 00000 n +0000404589 00000 n +0000404654 00000 n +0000404719 00000 n +0000404784 00000 n +0000404849 00000 n +0000404914 00000 n +0000404979 00000 n +0000405044 00000 n +0000405109 00000 n +0000405174 00000 n +0000405239 00000 n +0000405304 00000 n +0000405369 00000 n +0000405434 00000 n +0000405499 00000 n +0000405564 00000 n +0000405628 00000 n +0000410270 00000 n +0000408006 00000 n +0000405804 00000 n +0000408132 00000 n +0000408197 00000 n +0000408262 00000 n +0000408327 00000 n +0000408392 00000 n +0000408457 00000 n +0000408522 00000 n +0000408587 00000 n +0000408652 00000 n +0000408717 00000 n +0000408782 00000 n +0000408847 00000 n +0000408912 00000 n +0000408977 00000 n +0000409039 00000 n +0000409103 00000 n +0000409168 00000 n +0000409232 00000 n +0000409297 00000 n +0000409362 00000 n +0000409427 00000 n +0000409492 00000 n +0000409557 00000 n +0000409622 00000 n +0000409687 00000 n +0000409816 00000 n +0000409945 00000 n +0000410010 00000 n +0000410075 00000 n +0000410140 00000 n +0000410205 00000 n +0000413065 00000 n +0000412421 00000 n +0000410395 00000 n +0000412547 00000 n +0000412676 00000 n +0000412805 00000 n +0000412870 00000 n +0000412935 00000 n +0000413000 00000 n +0000714205 00000 n +0000417403 00000 n +0000417083 00000 n +0000413178 00000 n +0000417209 00000 n +0000417274 00000 n +0000417339 00000 n +0000420874 00000 n +0000420618 00000 n +0000417556 00000 n +0000420744 00000 n +0000420809 00000 n +0000424122 00000 n +0000423931 00000 n +0000421013 00000 n +0000424057 00000 n +0000427851 00000 n +0000427595 00000 n +0000424248 00000 n +0000427721 00000 n +0000427786 00000 n +0000430691 00000 n +0000429983 00000 n +0000427990 00000 n +0000430109 00000 n +0000430174 00000 n +0000430239 00000 n +0000430304 00000 n +0000430369 00000 n +0000430498 00000 n +0000430563 00000 n +0000430627 00000 n +0000435364 00000 n +0000435108 00000 n +0000430830 00000 n +0000435234 00000 n +0000435299 00000 n +0000714330 00000 n +0000438315 00000 n +0000437542 00000 n +0000435490 00000 n +0000437668 00000 n +0000437733 00000 n +0000437798 00000 n +0000437863 00000 n +0000437992 00000 n +0000438057 00000 n +0000438120 00000 n +0000438185 00000 n +0000438250 00000 n +0000440916 00000 n +0000440207 00000 n +0000438468 00000 n +0000440333 00000 n +0000440398 00000 n +0000440463 00000 n +0000440528 00000 n +0000440593 00000 n +0000440658 00000 n +0000440787 00000 n +0000440852 00000 n +0000443940 00000 n +0000443555 00000 n +0000441068 00000 n +0000443681 00000 n +0000443746 00000 n +0000443810 00000 n +0000443875 00000 n +0000447035 00000 n +0000446261 00000 n +0000444080 00000 n +0000446387 00000 n +0000446452 00000 n +0000446517 00000 n +0000446582 00000 n +0000446711 00000 n +0000446776 00000 n +0000446841 00000 n +0000446905 00000 n +0000446970 00000 n +0000450308 00000 n +0000450117 00000 n +0000447201 00000 n +0000450243 00000 n +0000453409 00000 n +0000452699 00000 n +0000450434 00000 n +0000452825 00000 n +0000452890 00000 n +0000452955 00000 n +0000453020 00000 n +0000453085 00000 n +0000453214 00000 n +0000453279 00000 n +0000453344 00000 n +0000714455 00000 n +0000457067 00000 n +0000456748 00000 n +0000453574 00000 n +0000456874 00000 n +0000456939 00000 n +0000457003 00000 n +0000460443 00000 n +0000460252 00000 n +0000457193 00000 n +0000460378 00000 n +0000463120 00000 n +0000462477 00000 n +0000460583 00000 n +0000462603 00000 n +0000462668 00000 n +0000462732 00000 n +0000462797 00000 n +0000462926 00000 n +0000462991 00000 n +0000463056 00000 n +0000465837 00000 n +0000465063 00000 n +0000463272 00000 n +0000465189 00000 n +0000465254 00000 n +0000465318 00000 n +0000465383 00000 n +0000465448 00000 n +0000465513 00000 n +0000465642 00000 n +0000465707 00000 n +0000465772 00000 n +0000469228 00000 n +0000468907 00000 n +0000465990 00000 n +0000469033 00000 n +0000469098 00000 n +0000469163 00000 n +0000472297 00000 n +0000471912 00000 n +0000469341 00000 n +0000472038 00000 n +0000472103 00000 n +0000472168 00000 n +0000472233 00000 n +0000714580 00000 n +0000475693 00000 n +0000475114 00000 n +0000472436 00000 n +0000475240 00000 n +0000475369 00000 n +0000475434 00000 n +0000475499 00000 n +0000475564 00000 n +0000475629 00000 n +0000478674 00000 n +0000478483 00000 n +0000475833 00000 n +0000478609 00000 n +0000481314 00000 n +0000480605 00000 n +0000478885 00000 n +0000480731 00000 n +0000480796 00000 n +0000480861 00000 n +0000480926 00000 n +0000480991 00000 n +0000481056 00000 n +0000481185 00000 n +0000481250 00000 n +0000485767 00000 n +0000485446 00000 n +0000481510 00000 n +0000485572 00000 n +0000485637 00000 n +0000485702 00000 n +0000489361 00000 n +0000489106 00000 n +0000485893 00000 n +0000489232 00000 n +0000489297 00000 n +0000492296 00000 n +0000492040 00000 n +0000489487 00000 n +0000492166 00000 n +0000492231 00000 n +0000714705 00000 n +0000495466 00000 n +0000494691 00000 n +0000492422 00000 n +0000494817 00000 n +0000494882 00000 n +0000494947 00000 n +0000495012 00000 n +0000495141 00000 n +0000495206 00000 n +0000495271 00000 n +0000495336 00000 n +0000495401 00000 n +0000498834 00000 n +0000498190 00000 n +0000495632 00000 n +0000498316 00000 n +0000498381 00000 n +0000498446 00000 n +0000498511 00000 n +0000498640 00000 n +0000498705 00000 n +0000498770 00000 n +0000502306 00000 n +0000501985 00000 n +0000499000 00000 n +0000502111 00000 n +0000502176 00000 n +0000502241 00000 n +0000504879 00000 n +0000504301 00000 n +0000502432 00000 n +0000504427 00000 n +0000504492 00000 n +0000504557 00000 n +0000504622 00000 n +0000504751 00000 n +0000504815 00000 n +0000508675 00000 n +0000508290 00000 n +0000505017 00000 n +0000508416 00000 n +0000508481 00000 n +0000508546 00000 n +0000508611 00000 n +0000510245 00000 n +0000509861 00000 n +0000508815 00000 n +0000509987 00000 n +0000510052 00000 n +0000510115 00000 n +0000510180 00000 n +0000714830 00000 n +0000510430 00000 n +0000521774 00000 n +0000529362 00000 n +0000531661 00000 n +0000531630 00000 n +0000541154 00000 n +0000551267 00000 n +0000561743 00000 n +0000574367 00000 n +0000593432 00000 n +0000614319 00000 n +0000636463 00000 n +0000654358 00000 n +0000657188 00000 n +0000656958 00000 n +0000684495 00000 n +0000711606 00000 n +0000714910 00000 n +0000715033 00000 n +0000715159 00000 n +0000715285 00000 n +0000715402 00000 n +0000715494 00000 n +0000731830 00000 n +0000750703 00000 n +0000750744 00000 n +0000750784 00000 n +0000750918 00000 n +trailer +<< +/Size 2120 +/Root 2118 0 R +/Info 2119 0 R +/ID [ ] +>> +startxref +751176 +%%EOF diff --git a/doc/arm/Makefile.in b/doc/arm/Makefile.in new file mode 100644 index 0000000..d727da9 --- /dev/null +++ b/doc/arm/Makefile.in @@ -0,0 +1,67 @@ +# Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2001, 2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.20 2007/06/18 23:47:33 tbox Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_MAKE_RULES@ + +@BIND9_VERSION@ + +MANOBJS = Bv9ARM.html + +PDFOBJS = Bv9ARM.pdf + +doc man:: ${MANOBJS} ${PDFOBJS} + +clean:: + rm -f Bv9ARM.aux Bv9ARM.brf Bv9ARM.glo Bv9ARM.idx Bv9ARM.toc + rm -f Bv9ARM.log Bv9ARM.out Bv9ARM.tex Bv9ARM.tex.tmp + +docclean manclean maintainer-clean:: clean + rm -f *.html ${PDFOBJS} + +docclean manclean maintainer-clean distclean:: + rm -f releaseinfo.xml + +Bv9ARM.html: Bv9ARM-book.xml releaseinfo.xml + expand Bv9ARM-book.xml | \ + ${XSLTPROC} --stringparam root.filename Bv9ARM \ + ${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl - + +Bv9ARM.tex: Bv9ARM-book.xml releaseinfo.xml + expand Bv9ARM-book.xml | \ + ${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl - | \ + ${XSLTPROC} ${top_srcdir}/doc/xsl/isc-docbook-latex.xsl - | \ + @PERL@ latex-fixup.pl >$@.tmp + if test -s $@.tmp; then mv $@.tmp $@; else rm -f $@.tmp; exit 1; fi + +Bv9ARM.dvi: Bv9ARM.tex releaseinfo.xml + rm -f Bv9ARM-book.aux Bv9ARM-book.dvi Bv9ARM-book.log + ${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1) + ${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1) + ${LATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1) + +Bv9ARM.pdf: Bv9ARM.tex releaseinfo.xml + rm -f Bv9ARM-book.aux Bv9ARM-book.pdf Bv9ARM-book.log + ${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1) + ${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1) + ${PDFLATEX} '\batchmode\input Bv9ARM.tex' || (rm -f $@ ; exit 1) + +releaseinfo.xml: + echo >$@ 'BIND Version ${VERSION}' diff --git a/doc/arm/README-SGML b/doc/arm/README-SGML new file mode 100644 index 0000000..e33c937 --- /dev/null +++ b/doc/arm/README-SGML @@ -0,0 +1,329 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +The BIND v9 ARM master document is now kept in DocBook XML format. + +Version: $Id: README-SGML,v 1.17 2004/03/05 05:04:43 marka Exp $ + +The entire ARM is in the single file: + + Bv9ARM-book.xml + +All of the other documents - HTML, PDF, etc - are generated from this +master source. + +This file attempts to describe what tools are necessary for the +maintenance of this document as well as the generation of the +alternate formats of this document. + +This file will also spend a very little time describing the XML and +SGML headers so you can understand a bit what you may need to do to be +able to work with this document in any fashion other than simply +editing it. + +We will spend almost no time on the actual tags and how to write an +XML DocBook compliant document. If you are at all familiar with SGML +or HTML it will be very evident. You only need to know what the tags +are and how to use them. You can find a good resource either for this +either online or in printed form: + + DocBook: The Definitive Guide + By Norman Walsh and Leonard Muellner + ISBN: 156592-580-7 + 1st Edition, October 1999 + Copyright (C) 1999 by O'Reilly & Associates, Inc. All rights reserved. + +The book is available online in HTML format: + + http://docbook.org/ + +and buried in: + + http://www.nwalsh.com/docbook/defguide/index.html + +A lot of useful stuff is at NWalsh's site in general. You may also +want to look at: + + http://www.xml.com/ + +The BIND v9 ARM is based on the XML 4.0 DocBook DTD. Every XML and +SGML document begins with a prefix that tells where to find the file +that describes the meaning and structure of the tags used in the rest +of the document. + +For our XML DocBook 4.0 based document this prefix looks like this: + + + +This "DOCTYPE" statement has three parts, of which we are only using +two: + +o The highest level term that represents this document (in this case + it is "book" + +o The identifier that tells us which DTD to use. This identifier has + two parts, the "Formal Public Identifier" (or FPI) and the system + identifier. In SGML you can have either a FPI or a SYSTEM identifier + but you have to have at least one of them. In XML you have to have a + SYSTEM identifier. + +FP & SYSTEM identifiers - These are names/lookups for the actual +DTD. The FPI is a globally unique name that should, on a properly +configured system, tell you exactly what DTD to use. The SYSTEM +identifier gives an absolute location for the DTD. In XML these are +supposed to be properly formatted URL's. + +SGML has these things called "catalogs" that are files that map FPI's +in to actual files. A "catalog" can also be used to remap a SYSTEM +identifier so you can say something like: "http://www.oasis.org/foo" +is actually "/usr/local/share/xml/foo.dtd" + +When you use various SGML/XML tools they need to be configured to look +at the same "catalog" files so that as you move from tool to tool they +all refer to the same DTD for the same document. + +We will be spending most of our configuration time making sure our +tools use the same "catalog" files and that we have the same DTD's +installed on our machines. XML's requirement of the SYSTEM identifier +over the FPI will probably lead to more problems as it does not +guarantee that everyone is using the same DTD. + +I did my initial work with the "sgmltools" the XML 4.0 DocBook DTD and +"jade" or "openjade." + +You can get the 4.0 XML DocBook DTD from: + + http://www.docbook.org/xml/4.0/ + +(download the .zip file.) NOTE: We will eventually be changing the +SYSTEM identifier to the recommended value of: + + http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd + +NOTE: Under FreeBSD this is the package: + + /usr/ports/textproc/docbook-xml + +NetBSD instructions are coming soon. + +With packages listed below installed under FreeBSD the "catalog" file +that all the tools refer to at least one is in: + + /usr/local/share/sgml/catalog + +In order for our SYSTEM identifier for the XML DocBook dtd to be found +I create a new catalog file at the top of the XML directory created on +FreeBSD: + + /usr/local/share/xml/catalog + +This file has one line: + + SYSTEM "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" "/usr/local/share/xml/dtd/docbook/docbookx.dtd" + +Then in the main "catalog" I have it include this XML catalog: + + CATALOG "/usr/local/share/xml/catalog" + + +On your systems you need to replace "/usr/local/share" with your +prefix root (probably /usr/pkg under NetBSD.) + +NOTE: The URL used above is supposed to the be the proper one for this +XML DocBook DTD... but there is nothing at that URL so you really do +need the "SYSTEM" identifier mapping in your catalog (or make the +SYSTEM identifier in your document refer to the real location of the +file on your local system.) + +HOW TO VALIDATE A DOCUMENT: + +I use the sgmltools "nsgmls" document validator. Since we are using +XML we need to use the XML declarations, which are installed as part +of the modular DSSL style sheets: + + nsgmls -sv /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + Bv9ARM-book.xml + +A convenient shell script "validate.sh" is now generated by configure +to invoke the above command with the correct system-dependent paths. + +The SGML tools can be found at: + + ftp://ftp.us.sgmltools.org/pub/SGMLtools/v2.0/source/ \ + ftp://ftp.nllgg.nl/pub/SGMLtools/v2.0/source/ + +FreeBSD package for these is: + + /usr/ports/textproc/sgmltools + +HOW TO RENDER A DOCUMENT AS HTML or TeX: + +o Generate html doc with: + + openjade -v -d ./nominum-docbook-html.dsl \ + -t sgml \ + /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + Bv9ARM-book.xml + +A convenient shell script "genhtml.sh" is now generated by configure to +invoke the above command with the correct system-dependent paths. + +On NetBSD there is no port for "openjade" however "jade" does still +work. However you need to specify the "catalog" file to use for style +sheets on the command line AND you need to have a default "catalog" +mapping where to find various DTDs. It seems that "jade" installed out +of the box on NetBSD does not use a globally defined "catalog" file +for mapping PUBLIC identifiers in to SYSTEM identifiers. + +So you need to have a "catalog" file in your current working directory +that has in it this: (these are probably more entries than you need!) + + CATALOG "/usr/pkg/share/sgml/iso8879/catalog" + CATALOG "/usr/pkg/share/sgml/docbook/2.4.1/catalog" + CATALOG "/usr/pkg/share/sgml/docbook/3.0/catalog" + CATALOG "/usr/pkg/share/sgml/docbook/3.1/catalog" + CATALOG "/usr/pkg/share/sgml/jade/catalog" + CATALOG "/usr/local/share/xml/catalog" + +(These would all be "/usr/local" on FreeBSD) + +So the command for jade on NetBSD will look like this: + +jade -v -c /usr/pkg/share/sgml/catalog -t sgml \ + -d ./nominum-docbook-html.dsl \ + /usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + ./Bv9ARM-book.xml + +Furthermore, since the style sheet subset we define has in it a hard +coded path to the style sheet is based, it is actually generated by +configure from a .in file so that it will contain the correct +system-dependent path: where on FreeBSD the second line reads: + + + +On NetBSD it needs to read: + + + +NOTE: This is usually solved by having this style sheet modification +be installed in a system directory and have it reference the style +sheet it is based on via a relative path. + +o Generate TeX documentation: + +openjade -d ./nominum-docbook-print.dsl -t tex -v \ + /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \ + Bv9ARM-book.xml + +If you have "jade" installed instead of "openjade" then use that as +the command. There is little difference, openjade has some bug fixes +and is in more active development. + +To convert the resulting TeX file in to a DVI file you need to do: + + tex "&jadetex" Bv9ARM-book.tex + +You can also directly generate the pdf file via: + + pdftex "&pdfjadetex" Bv9ARM-book.tex + +The scripts "genpdf.sh" and "gendvi." have been added to simply +generating the PDF and DVI output. These substitute the correct paths +of NetBSD & FreeBSD. You still need to have TeX, jadeTeX, and pdfTeX +installed and configured properly for these to work. + +You will need to up both the "pool_size" and "hash_extra" variables in +your texmf.cnf file and regenerate them. See below. + +You can see that I am using a DSSSL style sheet for DocBook. Actually +two different ones - one for rendering html, and one for 'print' +media. + +NOTE: For HTML we are using a Nominum DSSSL style instead of the +default one (all it does is change the chunking to the chapter level +and makes the files end with ".html" instead of ".htm" so far.) If you +want to use the plain jane DSSSL style sheet replace the: + + -d ./nominum-docbook-html.dsl + +with + + -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl + +This style sheet will attempt to reference the one above. + +I am currently working on fixing these up so that it works the same on +our various systems. The main trick is knowing which DTD's and DSSSL +stylesheets you have installed, installing the right ones, and +configuring a CATALOG that refers to them in the same way. We will +probably end up putting our CATALOG's in the same place and then we +should be able to generate and validate our documents with a minimal +number of command line arguments. + +When running these commands you will get a lot of messages about a +bunch of general entities not being defined and having no default +entity. You can ignore those for now. + +Also with the style sheets we have and jade as it is you will get +messages about "xref to title" being unsupported. You can ignore these +for now as well. + +=== Getting the various tools installed on FreeBSD +(NetBSD coming soon..) + +o On freebsd you need to install the following packages: + o print/teTeX + o textproc/openjade + o textproc/docbook + o textproc/docbook-xml + o textproc/dsssl-docbook-modular + o textproc/dtd-catalogs + +o on freebsd you need to make some entities visible to the docbook xml + dtd by making a symlink (can probably be done with a catalog too) + ln -s /usr/local/share/xml/entity /usr/local/share/xml/dtd/docbook/ent + +o you may need to edit /usr/local/share/sgml/catalog and add the line: + + CATALOG "/usr/local/share/sgml/openjade/catalog" + +o add "hugelatex," Enlarge pool sizes, install the jadetex TeX driver + file. + + cd /usr/local/share/texmf/web2c/ + sudo cp texmf.cnf texmf.cnf.bak + + o edit the lines in texmf.cnf with these keys to these values: + + main_memory = 1100000 + hash_extra = 15000 + pool_size = 500000 + string_vacancies = 45000 + max_strings = 55000 + pool_free = 47500 + nest_size = 500 + param_size = 1500 + save_size = 5000 + stack_size = 1500 + + sudo tex -ini -progname=hugelatex -fmt=hugelatex latex.ltx + sudo texconfig init + sudo texhash + + o For the jadetex macros you will need I recommend you get a more + current version than what is packaged with openjade or jade. + + Checkout http://www.tug.org/applications/jadetex/ + + Unzip the file you get from there (should be jadetex-2.20 or + newer.) + + In the directory you unzip: + + sudo make install + sudo texhash + + NOTE: In the most uptodate "ports" for FreeBSD, jadetext is 2.20+ + so on this platform you should be set as of 2001.01.08. diff --git a/doc/arm/isc-logo.eps b/doc/arm/isc-logo.eps new file mode 100644 index 0000000..c6a1d7a --- /dev/null +++ b/doc/arm/isc-logo.eps @@ -0,0 +1,12253 @@ +%!PS-Adobe-3.1 EPSF-3.0 +%%Title: Alternate-ISC-logo-v2.ai +%%Creator: Adobe Illustrator(R) 11 +%%AI8_CreatorVersion: 11.0.0 +%AI9_PrintingDataBegin +%%For: Douglas E. Appelt +%%CreationDate: 10/22/04 +%%BoundingBox: 0 0 255 149 +%%HiResBoundingBox: 0 0 254.8672 148.7520 +%%CropBox: 0 0 254.8672 148.7520 +%%LanguageLevel: 2 +%%DocumentData: Clean7Bit +%%Pages: 1 +%%DocumentNeededResources: +%%DocumentSuppliedResources: procset Adobe_AGM_Image (1.0 0) +%%+ procset Adobe_CoolType_Utility_T42 (1.0 0) +%%+ procset Adobe_CoolType_Utility_MAKEOCF (1.19 0) +%%+ procset Adobe_CoolType_Core (2.23 0) +%%+ procset Adobe_AGM_Core (2.0 0) +%%+ procset Adobe_AGM_Utils (1.0 0) +%%DocumentFonts: +%%DocumentNeededFonts: +%%DocumentNeededFeatures: +%%DocumentSuppliedFeatures: +%%DocumentProcessColors: Cyan Magenta Yellow Black +%%DocumentCustomColors: (PANTONE 1805 C) +%%+ (PANTONE 871 C) +%%+ (PANTONE 301 C) +%%+ (PANTONE 7506 C) +%%CMYKCustomColor: 0 0.9100 1 0.2300 (PANTONE 1805 C) +%%+ 0.3569 0.3608 0.6353 0.1882 (PANTONE 871 C) +%%+ 1 0.4500 0 0.1800 (PANTONE 301 C) +%%+ 0 0.0500 0.1500 0 (PANTONE 7506 C) +%%RGBCustomColor: +%ADO_ContainsXMP: MainFirst +%AI7_Thumbnail: 128 76 8 +%%BeginData: 10692 Hex Bytes +%0000330000660000990000CC0033000033330033660033990033CC0033FF +%0066000066330066660066990066CC0066FF009900009933009966009999 +%0099CC0099FF00CC0000CC3300CC6600CC9900CCCC00CCFF00FF3300FF66 +%00FF9900FFCC3300003300333300663300993300CC3300FF333300333333 +%3333663333993333CC3333FF3366003366333366663366993366CC3366FF +%3399003399333399663399993399CC3399FF33CC0033CC3333CC6633CC99 +%33CCCC33CCFF33FF0033FF3333FF6633FF9933FFCC33FFFF660000660033 +%6600666600996600CC6600FF6633006633336633666633996633CC6633FF +%6666006666336666666666996666CC6666FF669900669933669966669999 +%6699CC6699FF66CC0066CC3366CC6666CC9966CCCC66CCFF66FF0066FF33 +%66FF6666FF9966FFCC66FFFF9900009900339900669900999900CC9900FF +%9933009933339933669933999933CC9933FF996600996633996666996699 +%9966CC9966FF9999009999339999669999999999CC9999FF99CC0099CC33 +%99CC6699CC9999CCCC99CCFF99FF0099FF3399FF6699FF9999FFCC99FFFF +%CC0000CC0033CC0066CC0099CC00CCCC00FFCC3300CC3333CC3366CC3399 +%CC33CCCC33FFCC6600CC6633CC6666CC6699CC66CCCC66FFCC9900CC9933 +%CC9966CC9999CC99CCCC99FFCCCC00CCCC33CCCC66CCCC99CCCCCCCCCCFF +%CCFF00CCFF33CCFF66CCFF99CCFFCCCCFFFFFF0033FF0066FF0099FF00CC +%FF3300FF3333FF3366FF3399FF33CCFF33FFFF6600FF6633FF6666FF6699 +%FF66CCFF66FFFF9900FF9933FF9966FF9999FF99CCFF99FFFFCC00FFCC33 +%FFCC66FFCC99FFCCCCFFCCFFFFFF33FFFF66FFFF99FFFFCC110000001100 +%000011111111220000002200000022222222440000004400000044444444 +%550000005500000055555555770000007700000077777777880000008800 +%000088888888AA000000AA000000AAAAAAAABB000000BB000000BBBBBBBB +%DD000000DD000000DDDDDDDDEE000000EE000000EEEEEEEE0000000000FF +%00FF0000FFFFFF0000FF00FFFFFF00FFFFFF +%524C45FD1CF852FD63FFF820272726272727264B27272627272726272727 +%26272727264B20F827FD63FFF827FFFFFFCFFF84365AFFFFFFCFFFFFFFCF +%FFFFFFCFFD04FFCAF852FD63FFF827CFCFCACFCA2F0607A8CFCACFCACFCA +%CFCACFCACFCACFCACF7CF827FD63FFF800FFCFFFA8A8070D06A8CFFFCFFF +%CFFFCFFFCFFFCFFFCFFFCFA7F852FD63FFF800077E2F0D060D060706537D +%CF7D2FA8CFCACFCACFCACFCAFF7CF827FD63FFF8000D062F070D062F070D +%062F2F0D062FCACFCFFFCFCFCFFFCFA1F852FD63FFF8050707062E517651 +%522807060706072ECFCACFCACFCACFCAFF7CF827FD63FFF8002F067C757B +%757C757B512F072F2FFFCFCFCFFFCFFFCFFFCFA1F852FD63FFF805075251 +%75517551755175512F062FCACFCACFCACFCACFCAFF7CF827FD63FFF8F859 +%75765176757C517C757B2E2F07A8CFFFCFCFCFFFCFCFCFA1F852FD63FFF8 +%00517551757CCFCAA751755175060753CFCACFCACFCACFCACF7CF827FD63 +%FFF8F87C75757CFFCFFFCFA7517C752F072F59A8CFCFCFFFCFFFCFA7F852 +%FD04FFA87D527DA8FD5AFFF827757551A1CFCFCAFFA0755175280D060706 +%A8CFCFCACFCAFF7CF827FD05FF27F827FD5BFFF8F87C51767CFFCFFFCFA0 +%517C752F062F060D84FFCFFFCFFFCFA1F852FD05FF7DF87DFD5BFFF80552 +%7551757CC9A7A05175517606072F7E7DCFCACFC9CFCAFF6FF827FD05FF52 +%F852FD27FFA8FD33FFF80059757C7575517C517C517C2E2F06CFCFFFCFCF +%9293CAFFCF6FF852FD05FF7DF87DFD04FFA8FD05FF7D7DA8FF527D7D7D52 +%7D52A8FFA8527D527DA8FF7D7D527D52FD05FFA8FD05FFA87D7DFFFFA852 +%7D527DA8FF527D7D7D527D52A8FD19FFF805075275755175517551752D0D +%0653CFFFCFFFA78C6899939344F827FD05FF52F852FFFFFFA8F87DFD04FF +%7D27FFA87D7DA8F827A87D7DFFA8F827A8527DFFA8F852A827F8A8FFFFFF +%7DF8FD05FF2752FFFFA8F827A8527DA87D7DA8F827A87D7DFD19FFF8F82F +%0752517C757B757C2E0D062FA8C999CFCFC28C928C8C8C6EF852FD05FF7D +%F87DFD04FFF8F87DFFFFFF7D52FD05FFF852FD05FFF87DFD05FFF852FFFF +%F852FFFFFF7DF8F8FD04FF7D52FFFFFFF87DFD07FFF852FD1CFFF8000607 +%062F2852282E060D0607067D928C9293688C6892688C44F827FD05FF52F8 +%52FFFFFFA85252F852FFFF7D27FD05FFF87DFD04FFA8F852FD05FFF852FF +%FFF8A8FFFFFF7D5227F8A8FFFF527DFFFFA8F852FD07FFF87DFD1CFFF800 +%852F2F062F070D062F072F062F0D9A8C928C928C928C928C6EF852FD05FF +%7DF87DFD04FF27FF52F852FF7D52FD05FFF852FD05FFF82752527DFFFFF8 +%52FF527DFD04FF527DFF27F8A8FF7D7DFFFFFFF82752527DFD04FFF852FD +%1CFFF827CFCF7D2F060D062F2F7EA82F062F938C68928C8C68926E994AF8 +%27FD05FF52F852FFFFFFA827FFFF52F852A852FD05FFF87DFD04FFA8F852 +%FF7DA8FFFFF82752F8A8FD04FF7D52FFA827F8A87D7DFFFFA8F852FF7DA8 +%FD04FFF87DFD1CFFF827FFCFFFA80D062FA8CFCFCA927693928C928C9292 +%75517C7B51F852FD05FF7DF87DFFFFFFA827FFFFFF52F8F87DFD05FFF852 +%FD05FFF87DFD05FFF852FF52F8A8FFFFFF5252FFFFFF27F8277DFFFFFFF8 +%7DFD07FFF852FD1CFFF827CFCFCACF06062ECFCAFF928C688C6892688C6E +%765175517C26F827FD05FF52F852FFFFFFA827FD04FF52F852FD05FFF852 +%FD04FFA8F852FFFFA8A8FFF87DFFFFF8F8A8FFFF5227FD04FF27F8A8FFFF +%A8F852FFFFA8A8FFFFFFF852FD1CFFF827FFCFFFCF7E53A8CFFFCFC99292 +%8C928C92757C757C517C7551F852FD04FFA852F852A8FFFFA8F8A8FD04FF +%527DFD04FF7DF827FD04FFA8F827525252FF7DF827FFFFFF2727A8FF5227 +%A8FD04FF52A8FFFFA8F827525252FFFFFF7DF827FD1CFFF827CFCFCACFCF +%CFCAFD04CF93688C688C6F7651755175517C4BF827FD05FFA8FFA8FFFFFF +%A8FFA8FD0BFFA8FFA8FFFFFFA8FFA8A8A8FFFFFFA8FFA8FFFFFFA8FFA8FF +%A8FD09FFA8FFA8A8A8FD05FFA8FFA8FD1BFFF827FFCFCFCFFFCFCFCFFFCF +%C38C928C8C6E7C7576517C75767551F852FD63FFF827CFCFCACFCACFCACF +%92928C8C688C6875517551755175517526F827FD63FFF827FFCFFFCFFFCF +%FFCA938C928C928C99517C757C517C757C7551F852FD63FFF827CFCFCACF +%CACFCACFA093688C6892757551755175517551754BF827FD63FFF827FFCF +%FFCFCFCFFFCFFF998C8C926E7C7576517C7576517CA7A1F852FD06FFA87D +%527DA8FD58FFF827CFCFCACFCACFCAFFCF996892686F5175517551755175 +%7CFF7CF827FD05FF7D2752A82727A8FD57FFF827FFCFFFCFFFCFFFC2BB8C +%928C8C6E7C757C517C757C51CFFFA1F852FD05FF2752FFFFFF52FD58FFF8 +%27CFCFCACFCACFCF99688C68928C6F5175517551755175CAFF7CF827FD04 +%FFA8F852FD5CFFF827FFCFCFCFFFCFFFA0998C928C926E7C517C7576517C +%51CACFA1F852FD04FFA827F87DFFFFFFA8527DFD04FF527DFFFFA87D52A8 +%FF7D527D527D527D7DFF7D7D527D527DFFFFFFA8FD06FFA8FD04FFA87D7D +%7DFD26FFF827CFCFCACFCACFCACFCF99688C6893517551755175517575FF +%7CF827FD05FF52F8F852FFFFFF52F8A8FFFF7D27A8FF5252A8A852A852A8 +%7DF827A87D7DFFA8F852A87D52FFFFFFF8A8FD04FF5227FFFFFF7D27A8A8 +%52A8FD25FFF827FFCFFFCFFFCFFFCFFFA08C8C92927C517C757C517C7575 +%7C7CF852FD06FF52F8F852FFFFFF27F8FFFF52A8FFFFF87DFD07FFF87DFD +%05FFF852FD06FFF827FD04FF2727FFFFFF2752FD29FFF827CFCFCACFCACF +%CACFA799688C68927575517551755175517526F84BFD07FF52F8F87DFFFF +%A8F87D7D52FFFFFFF8F87DFD05FFA8F852FD05FFF87DFD05FFA8F8F8A8FF +%FF7DF8F8A8FFFF52F852A8FD27FFF827FFCFFFCFCFCFFFCF9368928C928C +%995176517C7576517C7551F852FD08FF7DF8F8FFFFFF52F827FD05FFF8F8 +%27FD05FFF87DFD05FFF8277D527DFFFF7D52F852FFFF277DF8A8FFFFFF52 +%F8F87DFD26FFF827CFCFCACFCACFCAFF938C688C688C6875517551755175 +%517C26F827FD09FF27F8A8FFFFFFF852FD06FF52F827FFFFFFA8F852FD05 +%FFF852A8A87DFFFF527D7DF8FF7D52A8F87DFD04FF7DF8F8A8FD25FFF827 +%FFCFFFCFFFCFFFCFCFCFC98C928C92927C517C757C517C7551F852FD04FF +%7DFD04FF7DF8FD04FFF852FD07FF7DF8A8FFFFFFF87DFD05FFF852FD05FF +%52A8FF272752A8FFF87DFD06FFF8A8FD25FFF827CFCFCACFCACFCAFD04CF +%99688C688C6E7651755175517C4BF827FD04FF5227FFFFA8F852FD04FFF8 +%7DFFFFFF7D7DFFFF7D27FD04FFF852FD05FFF852FFFFA8FFFF27A8FF7DF8 +%52FFFFF852FFA852FFFF7D27A8FD25FFF827FFCFCFCFFFCFCFCFFFCFCF92 +%928C928C926E7C517C75767551F852FD04FF7D272752277DFD04FF7DF827 +%FFFFFF7D27525227FD04FFA8F852A8FFFFFF7D2727525252FFA8F8A8FFFF +%52FFFFFF2727A8FF275252527DFD26FFF827CFCFCACFCACFCACFCAFF998C +%688C688C688C68755176517526F827FD07FFA8FD07FFA8FFA8FFFFFFA8A8 +%A8FD05FFA8FFA8FD05FFA8FFA8A8A8FFA8FFA8FD07FFA8FFFFFFA8A8FD28 +%FFF827FFCFFFCFFFCFFFCFFFCFCF92C29A928C928C928C99757C7551F852 +%FD63FFF827CFCFCACFCACFCACFCAFD04CFFF998C68928C8C6892689344F8 +%27FD63FFF827FFCFFFCFCFCFFFCFCFCFFFCFCFCFC98C928C928C928C928C +%68F852FD63FFF827CFCFCACFCACFCAA8537ECACFCAFF938C6899688C688C +%689244F827FD63FFF827FFCFFFCFFFCFA8072F07FFCFFFCFCF992F0D5992 +%928C928C68F852FD08FF7D7D527D52A8A8FD54FFF827CFCFCACFCACFA70D +%060753A87DA8CA5A0607069368929AC244F827FD06FF7DF8527D7D7D52F8 +%27FD54FFF827FFCFCFCFFFCFCF2F2F070D062F072F062F07539993C2FFFF +%76F852FD05FF7DF87DFD06FF27FD54FFF827CFCFCACFCACF7D0D060D0607 +%060D0607060753FFCACFCAFF76F827FD04FFA8F827FD07FFA8A8FD15FFA8 +%FD3DFFF827FFCFFFCFFF592F062F072F2852282F072F072F7DFFCFFFCFA7 +%F852FD04FF52F87DFD0CFFA87D7D7DFD05FFA8FD05FF7D7DA8FFFFA87D7D +%7DFFFFFFA87D527D7DFD04FFA8527D527DA8FFFF7D527D527D527D7DFF7D +%7D7DFFFFA8527DA8FFFFA8527DFFFFFFA8FD06FFA8FFFFF827CF5959CA53 +%07060D066F688C6892684B060D06077DCFCFCF7CF827FD04FF27F8A8FD0A +%FFA82752A87D52F852FFFFA8F87DFD04FF7D27FFFF7D27A87D52FFFF5227 +%7DA87D27F8A8FFFFA8F827A827F8A8A852A87DF827A87D7DFFA8F852FFFF +%A8F827FD04FF2727FFFFFFF8A8FD04FF5227FFFFF827A9062F070D062F28 +%928C928C928C928C92282F072F847E5953F852FD04FFF8F8A8FD0AFF2752 +%FD04FF7DF87DFFFFF8F852FFFFFF7D52FFFFF8A8FFFFA8FF7DF8A8FD04FF +%27F8FFFFFFF87DFFFFF87DFD04FFF87DFD05FFF852FFFFFFF87DFD04FF27 +%52FFFFFFF827FD04FF2727FFFFF8272F07060D060D278C688C68928C8C68 +%8C688C060D0607060D06F827FFFFFFA827F87DFD09FF7DF8FD06FF27F8FF +%A85252F852FFFF7D27FFFF27F87DFFFFFF2727FD05FF7DF852FFA8F852FF +%A8F87DFFFFFFA8F852FD05FFF852FFFFA8F852FD04FF5252FFFFA8F8F8A8 +%FFFF7DF827A8FFF827FF2F2F070D06938C928CBCC9CFC9BB8C928C6F070D +%062F0706F852FD04FF27F852FD09FF52F8FD06FF52F8FFFF27FF52F852FF +%7D52FFFFA827F827A8FFF852FD06FFF852FFFFF852FF7D7DFD05FFF87DFD +%05FFF852FFFFFFF87DFD04FF2752FFFF7D52F852FFFF277DF8A8FFF827CF +%CF2F0D064C689268C2CFFFCFFFCFC2688C682E0607062F52F827FD04FF7D +%F8F8A8FD08FF52F8A8FD05FF52F8FFA827FFFF52F852A852FD04FF7DF827 +%FF2727FD05FFA8F852FFA8F82752F8A8FD04FFA8F852FD05FFF852FFFFA8 +%F852FD04FF5252FFFF7D7D7DF8FF7D52A8F87DFFF827FFCF59062F6F8C8C +%99CFFFCFFFCFFFCF938C8C4B2F0759CFA7F852FD05FF52F827FD06FF7DFF +%A8F852FD05FFF852FFA827FFFFFF52F8F87DFD05FF7DF8FF52F8A8FD04FF +%A8F8A8FFFFF87DFF52F8FD05FFF87DFD05FFF852FFFFFFF852FD04FF277D +%FFFF27A8FF272752FFFFF87DFFF827CFCF2F070693688C99FFCACFCACFCA +%FF998C686F060759CF7CF827FD05FFA852F8F87DFFFFFF5227FFFF52F87D +%FFFFFF5227A8FFA827FD04FF52F852FF527DFFFF5227FFFFF827A8FFFFFF +%2752FFFFFFF852FFFF27F8FFFFFFA8F852FD05FFF87DFFFFFF52F8A8FFFF +%7D27A8FFFF27A8FF7DF852FFFFF827FFF827FFCF53062F6E928CC2FFFFCF +%FFCFFFCFC28C926F2F077ECFA7F852FD07FFA8FD06277DFFFFFF7D27277D +%527DFFFFFF7DF8A8FD04FF527DFFA827525252A8FFFFFF5227527D52A8FF +%FFFFA8F852A8FFA82727A8FFA8F852A8FFFFFF7DF827FD04FF52277D5252 +%A8FFFFA8F8A8FFFF52FFFFFF2727A8F827CFCF2F07066F8C8C92FFCFCFCA +%CFCFCF8C8C8C4B060D59CF7CF827FD0BFFA8FD09FFA8FD05FFA8FFA8FD09 +%FFA8A8FD07FFA8A8FD05FFA8FFA8FD05FFA8FFA8FFA8FD05FFA8FFA8FD05 +%FFA8FD05FFA8FFA8FD07FFA8FFF827AF2F2F070D4B928C8CA0FFCFFFCFFF +%998C8C92280D067ECFA1F852FD63FFF8270707060D0607688C688C99C9CA +%C9938C688C680D0607065A76F827FD63FFF8275A062F070D07528C928C92 +%8C928C928C928C2F070D062F072EF852FD63FFF84B842F597E0607064C8C +%8C68928C8C688C6828060D0607060D52F827FD63FFF827FFCFCFCF7E060D +%062F6F928C928C934B2F070D0684A85A59A1F852FD63FFF827CFCFCACFCA +%590607060D06282728060D0607067ECACFCFCF7CF827FD63FFF827FFCFFF +%CFFFCF59062F070D072F070D062F2FA8CFFFCFFFCFA7F852FD63FFF827CF +%CFCACFCACF2F07060D0607060D06070653CFCFCACFCAFF7CF827FD63FFF8 +%27FFCFFFCFCFA82F070D59CFA8A8A859060D07FD04CFFFCFA1F852FD63FF +%F827CFCFCACFCFA82F0D2FCFCACFCFCFA80D060DA8CFCACFCAFF7CF827FD +%63FFF827FFCFFFCFFFCFFFA8FFCFFFCFFFCFFF7E7EA8FFCFFFCFFFFFA7F8 +%52FD63FFFD09F820FD07F820FD07F820F8F827FD63FF27F827F820F827F8 +%20F827F820F827F820F827F820F827F820F827F87CFDE2FFFF +%%EndData +%%EndComments +%%BeginDefaults +%%ViewingOrientation: 1 0 0 1 +%%EndDefaults +%%BeginProlog +%%BeginResource: procset Adobe_AGM_Utils 1.0 0 +%%Version: 1.0 0 +%%Copyright: Copyright (C) 2000-2003 Adobe Systems, Inc. All Rights Reserved. +systemdict /setpacking known +{ + currentpacking + true setpacking +} if +userdict /Adobe_AGM_Utils 68 dict dup begin put +/bdf +{ + bind def +} bind def +/nd{ + null def +}bdf +/xdf +{ + exch def +}bdf +/ldf +{ + load def +}bdf +/ddf +{ + put +}bdf +/xddf +{ + 3 -1 roll put +}bdf +/xpt +{ + exch put +}bdf +/ndf +{ + exch dup where{ + pop pop pop + }{ + xdf + }ifelse +}def +/cdndf +{ + exch dup currentdict exch known{ + pop pop + }{ + exch def + }ifelse +}def +/bdict +{ + mark +}bdf +/edict +{ + counttomark 2 idiv dup dict begin {def} repeat pop currentdict end +}def +/ps_level + /languagelevel where{ + pop systemdict /languagelevel get exec + }{ + 1 + }ifelse +def +/level2 + ps_level 2 ge +def +/level3 + ps_level 3 ge +def +/ps_version + {version cvr} stopped { + -1 + }if +def +/makereadonlyarray +{ + /packedarray where{ + pop packedarray + }{ + array astore readonly + }ifelse +}bdf +/map_reserved_ink_name +{ + dup type /stringtype eq{ + dup /Red eq{ + pop (_Red_) + }{ + dup /Green eq{ + pop (_Green_) + }{ + dup /Blue eq{ + pop (_Blue_) + }{ + dup () cvn eq{ + pop (Process) + }if + }ifelse + }ifelse + }ifelse + }if +}bdf +/AGMUTIL_GSTATE 22 dict def +/get_gstate +{ + AGMUTIL_GSTATE begin + /AGMUTIL_GSTATE_clr_spc currentcolorspace def + /AGMUTIL_GSTATE_clr_indx 0 def + /AGMUTIL_GSTATE_clr_comps 12 array def + mark currentcolor counttomark + {AGMUTIL_GSTATE_clr_comps AGMUTIL_GSTATE_clr_indx 3 -1 roll put + /AGMUTIL_GSTATE_clr_indx AGMUTIL_GSTATE_clr_indx 1 add def} repeat pop + /AGMUTIL_GSTATE_fnt rootfont def + /AGMUTIL_GSTATE_lw currentlinewidth def + /AGMUTIL_GSTATE_lc currentlinecap def + /AGMUTIL_GSTATE_lj currentlinejoin def + /AGMUTIL_GSTATE_ml currentmiterlimit def + currentdash /AGMUTIL_GSTATE_do xdf /AGMUTIL_GSTATE_da xdf + /AGMUTIL_GSTATE_sa currentstrokeadjust def + /AGMUTIL_GSTATE_clr_rnd currentcolorrendering def + /AGMUTIL_GSTATE_op currentoverprint def + /AGMUTIL_GSTATE_bg currentblackgeneration cvlit def + /AGMUTIL_GSTATE_ucr currentundercolorremoval cvlit def + currentcolortransfer cvlit /AGMUTIL_GSTATE_gy_xfer xdf cvlit /AGMUTIL_GSTATE_b_xfer xdf + cvlit /AGMUTIL_GSTATE_g_xfer xdf cvlit /AGMUTIL_GSTATE_r_xfer xdf + /AGMUTIL_GSTATE_ht currenthalftone def + /AGMUTIL_GSTATE_flt currentflat def + end +}def +/set_gstate +{ + AGMUTIL_GSTATE begin + AGMUTIL_GSTATE_clr_spc setcolorspace + AGMUTIL_GSTATE_clr_indx {AGMUTIL_GSTATE_clr_comps AGMUTIL_GSTATE_clr_indx 1 sub get + /AGMUTIL_GSTATE_clr_indx AGMUTIL_GSTATE_clr_indx 1 sub def} repeat setcolor + AGMUTIL_GSTATE_fnt setfont + AGMUTIL_GSTATE_lw setlinewidth + AGMUTIL_GSTATE_lc setlinecap + AGMUTIL_GSTATE_lj setlinejoin + AGMUTIL_GSTATE_ml setmiterlimit + AGMUTIL_GSTATE_da AGMUTIL_GSTATE_do setdash + AGMUTIL_GSTATE_sa setstrokeadjust + AGMUTIL_GSTATE_clr_rnd setcolorrendering + AGMUTIL_GSTATE_op setoverprint + AGMUTIL_GSTATE_bg cvx setblackgeneration + AGMUTIL_GSTATE_ucr cvx setundercolorremoval + AGMUTIL_GSTATE_r_xfer cvx AGMUTIL_GSTATE_g_xfer cvx AGMUTIL_GSTATE_b_xfer cvx + AGMUTIL_GSTATE_gy_xfer cvx setcolortransfer + AGMUTIL_GSTATE_ht /HalftoneType get dup 9 eq exch 100 eq or + { + currenthalftone /HalftoneType get AGMUTIL_GSTATE_ht /HalftoneType get ne + { + mark AGMUTIL_GSTATE_ht {sethalftone} stopped cleartomark + } if + }{ + AGMUTIL_GSTATE_ht sethalftone + } ifelse + AGMUTIL_GSTATE_flt setflat + end +}def +/get_gstate_and_matrix +{ + AGMUTIL_GSTATE begin + /AGMUTIL_GSTATE_ctm matrix currentmatrix def + end + get_gstate +}def +/set_gstate_and_matrix +{ + set_gstate + AGMUTIL_GSTATE begin + AGMUTIL_GSTATE_ctm setmatrix + end +}def +/AGMUTIL_str256 256 string def +/AGMUTIL_src256 256 string def +/AGMUTIL_dst64 64 string def +/AGMUTIL_srcLen nd +/AGMUTIL_ndx nd +/agm_sethalftone +{ + dup + begin + /_Data load + /Thresholds xdf + end + level3 + { sethalftone }{ + dup /HalftoneType get 3 eq { + sethalftone + } {pop} ifelse + }ifelse +} def +/rdcmntline +{ + currentfile AGMUTIL_str256 readline pop + (%) anchorsearch {pop} if +} bdf +/filter_cmyk +{ + dup type /filetype ne{ + exch () /SubFileDecode filter + } + { + exch pop + } + ifelse + [ + exch + { + AGMUTIL_src256 readstring pop + dup length /AGMUTIL_srcLen exch def + /AGMUTIL_ndx 0 def + AGMCORE_plate_ndx 4 AGMUTIL_srcLen 1 sub{ + 1 index exch get + AGMUTIL_dst64 AGMUTIL_ndx 3 -1 roll put + /AGMUTIL_ndx AGMUTIL_ndx 1 add def + }for + pop + AGMUTIL_dst64 0 AGMUTIL_ndx getinterval + } + bind + /exec cvx + ] cvx +} bdf +/filter_indexed_devn +{ + cvi Names length mul names_index add Lookup exch get +} bdf +/filter_devn +{ + 4 dict begin + /srcStr xdf + /dstStr xdf + dup type /filetype ne{ + 0 () /SubFileDecode filter + }if + [ + exch + [ + /devicen_colorspace_dict /AGMCORE_gget cvx /begin cvx + currentdict /srcStr get /readstring cvx /pop cvx + /dup cvx /length cvx 0 /gt cvx [ + Adobe_AGM_Utils /AGMUTIL_ndx 0 /ddf cvx + names_index Names length currentdict /srcStr get length 1 sub { + 1 /index cvx /exch cvx /get cvx + currentdict /dstStr get /AGMUTIL_ndx /load cvx 3 -1 /roll cvx /put cvx + Adobe_AGM_Utils /AGMUTIL_ndx /AGMUTIL_ndx /load cvx 1 /add cvx /ddf cvx + } for + currentdict /dstStr get 0 /AGMUTIL_ndx /load cvx /getinterval cvx + ] cvx /if cvx + /end cvx + ] cvx + bind + /exec cvx + ] cvx + end +} bdf +/AGMUTIL_imagefile nd +/read_image_file +{ + AGMUTIL_imagefile 0 setfileposition + 10 dict begin + /imageDict xdf + /imbufLen Width BitsPerComponent mul 7 add 8 idiv def + /imbufIdx 0 def + /origDataSource imageDict /DataSource get def + /origMultipleDataSources imageDict /MultipleDataSources get def + /origDecode imageDict /Decode get def + /dstDataStr imageDict /Width get colorSpaceElemCnt mul string def + /srcDataStrs [ imageDict begin + currentdict /MultipleDataSources known {MultipleDataSources {DataSource length}{1}ifelse}{1} ifelse + { + Width Decode length 2 div mul cvi string + } repeat + end ] def + imageDict /MultipleDataSources known {MultipleDataSources}{false} ifelse + { + /imbufCnt imageDict /DataSource get length def + /imbufs imbufCnt array def + 0 1 imbufCnt 1 sub { + /imbufIdx xdf + imbufs imbufIdx imbufLen string put + imageDict /DataSource get imbufIdx [ AGMUTIL_imagefile imbufs imbufIdx get /readstring cvx /pop cvx ] cvx put + } for + DeviceN_PS2 { + imageDict begin + /DataSource [ DataSource /devn_sep_datasource cvx ] cvx def + /MultipleDataSources false def + /Decode [0 1] def + end + } if + }{ + /imbuf imbufLen string def + Indexed_DeviceN level3 not and DeviceN_NoneName or { + imageDict begin + /DataSource [AGMUTIL_imagefile Decode BitsPerComponent false 1 /filter_indexed_devn load dstDataStr srcDataStrs devn_alt_datasource /exec cvx] cvx def + /Decode [0 1] def + end + }{ + imageDict /DataSource {AGMUTIL_imagefile imbuf readstring pop} put + } ifelse + } ifelse + imageDict exch + load exec + imageDict /DataSource origDataSource put + imageDict /MultipleDataSources origMultipleDataSources put + imageDict /Decode origDecode put + end +} bdf +/write_image_file +{ + begin + { (AGMUTIL_imagefile) (w+) file } stopped{ + false + }{ + Adobe_AGM_Utils/AGMUTIL_imagefile xddf + 2 dict begin + /imbufLen Width BitsPerComponent mul 7 add 8 idiv def + MultipleDataSources {DataSource 0 get}{DataSource}ifelse type /filetype eq { + /imbuf imbufLen string def + }if + 1 1 Height { + pop + MultipleDataSources { + 0 1 DataSource length 1 sub { + DataSource type dup + /arraytype eq { + pop DataSource exch get exec + }{ + /filetype eq { + DataSource exch get imbuf readstring pop + }{ + DataSource exch get + } ifelse + } ifelse + AGMUTIL_imagefile exch writestring + } for + }{ + DataSource type dup + /arraytype eq { + pop DataSource exec + }{ + /filetype eq { + DataSource imbuf readstring pop + }{ + DataSource + } ifelse + } ifelse + AGMUTIL_imagefile exch writestring + } ifelse + }for + end + true + }ifelse + end +} bdf +/close_image_file +{ + AGMUTIL_imagefile closefile (AGMUTIL_imagefile) deletefile +}def +statusdict /product known userdict /AGMP_current_show known not and{ + /pstr statusdict /product get def + pstr (HP LaserJet 2200) eq + pstr (HP LaserJet 4000 Series) eq or + pstr (HP LaserJet 4050 Series ) eq or + pstr (HP LaserJet 8000 Series) eq or + pstr (HP LaserJet 8100 Series) eq or + pstr (HP LaserJet 8150 Series) eq or + pstr (HP LaserJet 5000 Series) eq or + pstr (HP LaserJet 5100 Series) eq or + pstr (HP Color LaserJet 4500) eq or + pstr (HP Color LaserJet 4600) eq or + pstr (HP LaserJet 5Si) eq or + pstr (HP LaserJet 1200 Series) eq or + pstr (HP LaserJet 1300 Series) eq or + pstr (HP LaserJet 4100 Series) eq or + { + userdict /AGMP_current_show /show load put + userdict /show { + currentcolorspace 0 get + /Pattern eq + {false charpath f} + {AGMP_current_show} ifelse + } put + }if + currentdict /pstr undef +} if +/consumeimagedata +{ + begin + currentdict /MultipleDataSources known not + {/MultipleDataSources false def} if + MultipleDataSources + { + 1 dict begin + /flushbuffer Width cvi string def + 1 1 Height cvi + { + pop + 0 1 DataSource length 1 sub + { + DataSource exch get + dup type dup + /filetype eq + { + exch flushbuffer readstring pop pop + }if + /arraytype eq + { + exec pop + }if + }for + }for + end + } + { + /DataSource load type dup + /filetype eq + { + 1 dict begin + /flushbuffer Width Decode length 2 div mul cvi string def + 1 1 Height { pop DataSource flushbuffer readstring pop pop} for + end + }if + /arraytype eq + { + 1 1 Height { pop DataSource pop } for + }if + }ifelse + end +}bdf +/addprocs +{ + 2{/exec load}repeat + 3 1 roll + [ 5 1 roll ] bind cvx +}def +/modify_halftone_xfer +{ + currenthalftone dup length dict copy begin + currentdict 2 index known{ + 1 index load dup length dict copy begin + currentdict/TransferFunction known{ + /TransferFunction load + }{ + currenttransfer + }ifelse + addprocs /TransferFunction xdf + currentdict end def + currentdict end sethalftone + }{ + currentdict/TransferFunction known{ + /TransferFunction load + }{ + currenttransfer + }ifelse + addprocs /TransferFunction xdf + currentdict end sethalftone + pop + }ifelse +}def +/clonearray +{ + dup xcheck exch + dup length array exch + Adobe_AGM_Core/AGMCORE_tmp -1 ddf + { + Adobe_AGM_Core/AGMCORE_tmp AGMCORE_tmp 1 add ddf + dup type /dicttype eq + { + AGMCORE_tmp + exch + clonedict + Adobe_AGM_Core/AGMCORE_tmp 4 -1 roll ddf + } if + dup type /arraytype eq + { + AGMCORE_tmp exch + clonearray + Adobe_AGM_Core/AGMCORE_tmp 4 -1 roll ddf + } if + exch dup + AGMCORE_tmp 4 -1 roll put + }forall + exch {cvx} if +}bdf +/clonedict +{ + dup length dict + begin + { + dup type /dicttype eq + { + clonedict + } if + dup type /arraytype eq + { + clonearray + } if + def + }forall + currentdict + end +}bdf +/DeviceN_PS2 +{ + /currentcolorspace AGMCORE_gget 0 get /DeviceN eq level3 not and +} bdf +/Indexed_DeviceN +{ + /indexed_colorspace_dict AGMCORE_gget dup null ne { + /CSD known + }{ + pop false + } ifelse +} bdf +/DeviceN_NoneName +{ + /Names where { + pop + false Names + { + (None) eq or + } forall + }{ + false + }ifelse +} bdf +/DeviceN_PS2_inRip_seps +{ + /AGMCORE_in_rip_sep where + { + pop dup type dup /arraytype eq exch /packedarraytype eq or + { + dup 0 get /DeviceN eq level3 not and AGMCORE_in_rip_sep and + { + /currentcolorspace exch AGMCORE_gput + false + } + { + true + }ifelse + } + { + true + } ifelse + } + { + true + } ifelse +} bdf +/base_colorspace_type +{ + dup type /arraytype eq {0 get} if +} bdf +/doc_setup{ + Adobe_AGM_Utils begin +}bdf +/doc_trailer{ + currentdict Adobe_AGM_Utils eq{ + end + }if +}bdf +systemdict /setpacking known +{ + setpacking +} if +%%EndResource +%%BeginResource: procset Adobe_AGM_Core 2.0 0 +%%Version: 2.0 0 +%%Copyright: Copyright (C) 1997-2003 Adobe Systems, Inc. All Rights Reserved. +systemdict /setpacking known +{ + currentpacking + true setpacking +} if +userdict /Adobe_AGM_Core 216 dict dup begin put +/nd{ + null def +}bind def +/Adobe_AGM_Core_Id /Adobe_AGM_Core_2.0_0 def +/AGMCORE_str256 256 string def +/AGMCORE_save nd +/AGMCORE_graphicsave nd +/AGMCORE_c 0 def +/AGMCORE_m 0 def +/AGMCORE_y 0 def +/AGMCORE_k 0 def +/AGMCORE_cmykbuf 4 array def +/AGMCORE_screen [currentscreen] cvx def +/AGMCORE_tmp 0 def +/AGMCORE_&setgray nd +/AGMCORE_&setcolor nd +/AGMCORE_&setcolorspace nd +/AGMCORE_&setcmykcolor nd +/AGMCORE_cyan_plate nd +/AGMCORE_magenta_plate nd +/AGMCORE_yellow_plate nd +/AGMCORE_black_plate nd +/AGMCORE_plate_ndx nd +/AGMCORE_get_ink_data nd +/AGMCORE_is_cmyk_sep nd +/AGMCORE_host_sep nd +/AGMCORE_avoid_L2_sep_space nd +/AGMCORE_distilling nd +/AGMCORE_composite_job nd +/AGMCORE_producing_seps nd +/AGMCORE_ps_level -1 def +/AGMCORE_ps_version -1 def +/AGMCORE_environ_ok nd +/AGMCORE_CSA_cache 0 dict def +/AGMCORE_CSD_cache 0 dict def +/AGMCORE_pattern_cache 0 dict def +/AGMCORE_currentoverprint false def +/AGMCORE_deltaX nd +/AGMCORE_deltaY nd +/AGMCORE_name nd +/AGMCORE_sep_special nd +/AGMCORE_err_strings 4 dict def +/AGMCORE_cur_err nd +/AGMCORE_ovp nd +/AGMCORE_current_spot_alias false def +/AGMCORE_inverting false def +/AGMCORE_feature_dictCount nd +/AGMCORE_feature_opCount nd +/AGMCORE_feature_ctm nd +/AGMCORE_ConvertToProcess false def +/AGMCORE_Default_CTM matrix def +/AGMCORE_Default_PageSize nd +/AGMCORE_currentbg nd +/AGMCORE_currentucr nd +/AGMCORE_gradientcache 32 dict def +/AGMCORE_in_pattern false def +/knockout_unitsq nd +/AGMCORE_CRD_cache where{ + pop +}{ + /AGMCORE_CRD_cache 0 dict def +}ifelse +/AGMCORE_key_known +{ + where{ + /Adobe_AGM_Core_Id known + }{ + false + }ifelse +}ndf +/flushinput +{ + save + 2 dict begin + /CompareBuffer 3 -1 roll def + /readbuffer 256 string def + mark + { + currentfile readbuffer {readline} stopped + {cleartomark mark} + { + not + {pop exit} + if + CompareBuffer eq + {exit} + if + }ifelse + }loop + cleartomark + end + restore +}bdf +/getspotfunction +{ + AGMCORE_screen exch pop exch pop + dup type /dicttype eq{ + dup /HalftoneType get 1 eq{ + /SpotFunction get + }{ + dup /HalftoneType get 2 eq{ + /GraySpotFunction get + }{ + pop + { + abs exch abs 2 copy add 1 gt{ + 1 sub dup mul exch 1 sub dup mul add 1 sub + }{ + dup mul exch dup mul add 1 exch sub + }ifelse + }bind + }ifelse + }ifelse + }if +} def +/clp_npth +{ + clip newpath +} def +/eoclp_npth +{ + eoclip newpath +} def +/npth_clp +{ + newpath clip +} def +/add_grad +{ + AGMCORE_gradientcache 3 1 roll put +}bdf +/exec_grad +{ + AGMCORE_gradientcache exch get exec +}bdf +/graphic_setup +{ + /AGMCORE_graphicsave save def + concat + 0 setgray + 0 setlinecap + 0 setlinejoin + 1 setlinewidth + [] 0 setdash + 10 setmiterlimit + newpath + false setoverprint + false setstrokeadjust + Adobe_AGM_Core/spot_alias get exec + /Adobe_AGM_Image where { + pop + Adobe_AGM_Image/spot_alias 2 copy known{ + get exec + }{ + pop pop + }ifelse + } if + 100 dict begin + /dictstackcount countdictstack def + /showpage {} def + mark +} def +/graphic_cleanup +{ + cleartomark + dictstackcount 1 countdictstack 1 sub {end}for + end + AGMCORE_graphicsave restore +} def +/compose_error_msg +{ + grestoreall initgraphics + /Helvetica findfont 10 scalefont setfont + /AGMCORE_deltaY 100 def + /AGMCORE_deltaX 310 def + clippath pathbbox newpath pop pop 36 add exch 36 add exch moveto + 0 AGMCORE_deltaY rlineto AGMCORE_deltaX 0 rlineto + 0 AGMCORE_deltaY neg rlineto AGMCORE_deltaX neg 0 rlineto closepath + 0 AGMCORE_&setgray + gsave 1 AGMCORE_&setgray fill grestore + 1 setlinewidth gsave stroke grestore + currentpoint AGMCORE_deltaY 15 sub add exch 8 add exch moveto + /AGMCORE_deltaY 12 def + /AGMCORE_tmp 0 def + AGMCORE_err_strings exch get + { + dup 32 eq + { + pop + AGMCORE_str256 0 AGMCORE_tmp getinterval + stringwidth pop currentpoint pop add AGMCORE_deltaX 28 add gt + { + currentpoint AGMCORE_deltaY sub exch pop + clippath pathbbox pop pop pop 44 add exch moveto + } if + AGMCORE_str256 0 AGMCORE_tmp getinterval show ( ) show + 0 1 AGMCORE_str256 length 1 sub + { + AGMCORE_str256 exch 0 put + }for + /AGMCORE_tmp 0 def + } + { + AGMCORE_str256 exch AGMCORE_tmp xpt + /AGMCORE_tmp AGMCORE_tmp 1 add def + } ifelse + } forall +} bdf +/doc_setup{ + Adobe_AGM_Core begin + /AGMCORE_ps_version xdf + /AGMCORE_ps_level xdf + errordict /AGM_handleerror known not{ + errordict /AGM_handleerror errordict /handleerror get put + errordict /handleerror { + Adobe_AGM_Core begin + $error /newerror get AGMCORE_cur_err null ne and{ + $error /newerror false put + AGMCORE_cur_err compose_error_msg + }if + $error /newerror true put + end + errordict /AGM_handleerror get exec + } bind put + }if + /AGMCORE_environ_ok + ps_level AGMCORE_ps_level ge + ps_version AGMCORE_ps_version ge and + AGMCORE_ps_level -1 eq or + def + AGMCORE_environ_ok not + {/AGMCORE_cur_err /AGMCORE_bad_environ def} if + /AGMCORE_&setgray systemdict/setgray get def + level2{ + /AGMCORE_&setcolor systemdict/setcolor get def + /AGMCORE_&setcolorspace systemdict/setcolorspace get def + }if + /AGMCORE_currentbg currentblackgeneration def + /AGMCORE_currentucr currentundercolorremoval def + /AGMCORE_distilling + /product where{ + pop systemdict/setdistillerparams known product (Adobe PostScript Parser) ne and + }{ + false + }ifelse + def + level2 not{ + /xput{ + dup load dup length exch maxlength eq{ + dup dup load dup + length dup 0 eq {pop 1} if 2 mul dict copy def + }if + load begin + def + end + }def + }{ + /xput{ + load 3 1 roll put + }def + }ifelse + /AGMCORE_GSTATE AGMCORE_key_known not{ + /AGMCORE_GSTATE 21 dict def + /AGMCORE_tmpmatrix matrix def + /AGMCORE_gstack 32 array def + /AGMCORE_gstackptr 0 def + /AGMCORE_gstacksaveptr 0 def + /AGMCORE_gstackframekeys 10 def + /AGMCORE_&gsave /gsave ldf + /AGMCORE_&grestore /grestore ldf + /AGMCORE_&grestoreall /grestoreall ldf + /AGMCORE_&save /save ldf + /AGMCORE_gdictcopy { + begin + { def } forall + end + }def + /AGMCORE_gput { + AGMCORE_gstack AGMCORE_gstackptr get + 3 1 roll + put + }def + /AGMCORE_gget { + AGMCORE_gstack AGMCORE_gstackptr get + exch + get + }def + /gsave { + AGMCORE_&gsave + AGMCORE_gstack AGMCORE_gstackptr get + AGMCORE_gstackptr 1 add + dup 32 ge {limitcheck} if + Adobe_AGM_Core exch + /AGMCORE_gstackptr xpt + AGMCORE_gstack AGMCORE_gstackptr get + AGMCORE_gdictcopy + }def + /grestore { + AGMCORE_&grestore + AGMCORE_gstackptr 1 sub + dup AGMCORE_gstacksaveptr lt {1 add} if + Adobe_AGM_Core exch + /AGMCORE_gstackptr xpt + }def + /grestoreall { + AGMCORE_&grestoreall + Adobe_AGM_Core + /AGMCORE_gstackptr AGMCORE_gstacksaveptr put + }def + /save { + AGMCORE_&save + AGMCORE_gstack AGMCORE_gstackptr get + AGMCORE_gstackptr 1 add + dup 32 ge {limitcheck} if + Adobe_AGM_Core begin + /AGMCORE_gstackptr exch def + /AGMCORE_gstacksaveptr AGMCORE_gstackptr def + end + AGMCORE_gstack AGMCORE_gstackptr get + AGMCORE_gdictcopy + }def + 0 1 AGMCORE_gstack length 1 sub { + AGMCORE_gstack exch AGMCORE_gstackframekeys dict put + } for + }if + level3 /AGMCORE_&sysshfill AGMCORE_key_known not and + { + /AGMCORE_&sysshfill systemdict/shfill get def + /AGMCORE_&usrshfill /shfill load def + /AGMCORE_&sysmakepattern systemdict/makepattern get def + /AGMCORE_&usrmakepattern /makepattern load def + }if + /currentcmykcolor [0 0 0 0] AGMCORE_gput + /currentstrokeadjust false AGMCORE_gput + /currentcolorspace [/DeviceGray] AGMCORE_gput + /sep_tint 0 AGMCORE_gput + /devicen_tints [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] AGMCORE_gput + /sep_colorspace_dict null AGMCORE_gput + /devicen_colorspace_dict null AGMCORE_gput + /indexed_colorspace_dict null AGMCORE_gput + /currentcolor_intent () AGMCORE_gput + /customcolor_tint 1 AGMCORE_gput + << + /MaxPatternItem currentsystemparams /MaxPatternCache get + >> + setuserparams + end +}def +/page_setup +{ + /setcmykcolor where{ + pop + Adobe_AGM_Core/AGMCORE_&setcmykcolor /setcmykcolor load put + }if + Adobe_AGM_Core begin + /setcmykcolor + { + 4 copy AGMCORE_cmykbuf astore /currentcmykcolor exch AGMCORE_gput + 1 sub 4 1 roll + 3 { + 3 index add neg dup 0 lt { + pop 0 + } if + 3 1 roll + } repeat + setrgbcolor pop + }ndf + /currentcmykcolor + { + /currentcmykcolor AGMCORE_gget aload pop + }ndf + /setoverprint + { + pop + }ndf + /currentoverprint + { + false + }ndf + /AGMCORE_deviceDPI 72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt def + /AGMCORE_cyan_plate 1 0 0 0 test_cmyk_color_plate def + /AGMCORE_magenta_plate 0 1 0 0 test_cmyk_color_plate def + /AGMCORE_yellow_plate 0 0 1 0 test_cmyk_color_plate def + /AGMCORE_black_plate 0 0 0 1 test_cmyk_color_plate def + /AGMCORE_plate_ndx + AGMCORE_cyan_plate{ + 0 + }{ + AGMCORE_magenta_plate{ + 1 + }{ + AGMCORE_yellow_plate{ + 2 + }{ + AGMCORE_black_plate{ + 3 + }{ + 4 + }ifelse + }ifelse + }ifelse + }ifelse + def + /AGMCORE_have_reported_unsupported_color_space false def + /AGMCORE_report_unsupported_color_space + { + AGMCORE_have_reported_unsupported_color_space false eq + { + (Warning: Job contains content that cannot be separated with on-host methods. This content appears on the black plate, and knocks out all other plates.) == + Adobe_AGM_Core /AGMCORE_have_reported_unsupported_color_space true ddf + } if + }def + /AGMCORE_composite_job + AGMCORE_cyan_plate AGMCORE_magenta_plate and AGMCORE_yellow_plate and AGMCORE_black_plate and def + /AGMCORE_in_rip_sep + /AGMCORE_in_rip_sep where{ + pop AGMCORE_in_rip_sep + }{ + AGMCORE_distilling + { + false + }{ + userdict/Adobe_AGM_OnHost_Seps known{ + false + }{ + level2{ + currentpagedevice/Separations 2 copy known{ + get + }{ + pop pop false + }ifelse + }{ + false + }ifelse + }ifelse + }ifelse + }ifelse + def + /AGMCORE_producing_seps AGMCORE_composite_job not AGMCORE_in_rip_sep or def + /AGMCORE_host_sep AGMCORE_producing_seps AGMCORE_in_rip_sep not and def + /AGM_preserve_spots + /AGM_preserve_spots where{ + pop AGM_preserve_spots + }{ + AGMCORE_distilling AGMCORE_producing_seps or + }ifelse + def + /AGM_is_distiller_preserving_spotimages + { + currentdistillerparams/PreserveOverprintSettings known + { + currentdistillerparams/PreserveOverprintSettings get + { + currentdistillerparams/ColorConversionStrategy known + { + currentdistillerparams/ColorConversionStrategy get + /LeaveColorUnchanged eq + }{ + true + }ifelse + }{ + false + }ifelse + }{ + false + }ifelse + }def + /convert_spot_to_process where {pop}{ + /convert_spot_to_process + { + dup map_alias { + /Name get exch pop + } if + dup dup (None) eq exch (All) eq or + { + pop false + }{ + AGMCORE_host_sep + { + gsave + 1 0 0 0 setcmykcolor currentgray 1 exch sub + 0 1 0 0 setcmykcolor currentgray 1 exch sub + 0 0 1 0 setcmykcolor currentgray 1 exch sub + 0 0 0 1 setcmykcolor currentgray 1 exch sub + add add add 0 eq + { + pop false + }{ + false setoverprint + 1 1 1 1 5 -1 roll findcmykcustomcolor 1 setcustomcolor + currentgray 0 eq + }ifelse + grestore + }{ + AGMCORE_distilling + { + pop AGM_is_distiller_preserving_spotimages not + }{ + Adobe_AGM_Core/AGMCORE_name xddf + false + Adobe_AGM_Core/AGMCORE_in_pattern known {Adobe_AGM_Core/AGMCORE_in_pattern get}{false} ifelse + not currentpagedevice/OverrideSeparations known and + { + currentpagedevice/OverrideSeparations get + { + /HqnSpots /ProcSet resourcestatus + { + pop pop pop true + }if + }if + }if + { + AGMCORE_name /HqnSpots /ProcSet findresource /TestSpot get exec not + }{ + gsave + [/Separation AGMCORE_name /DeviceGray {}]setcolorspace + false + currentpagedevice/SeparationColorNames 2 copy known + { + get + { AGMCORE_name eq or}forall + not + }{ + pop pop pop true + }ifelse + grestore + }ifelse + }ifelse + }ifelse + }ifelse + }def + }ifelse + /convert_to_process where {pop}{ + /convert_to_process + { + dup length 0 eq + { + pop false + }{ + AGMCORE_host_sep + { + dup true exch + { + dup (Cyan) eq exch + dup (Magenta) eq 3 -1 roll or exch + dup (Yellow) eq 3 -1 roll or exch + dup (Black) eq 3 -1 roll or + {pop} + {convert_spot_to_process and}ifelse + } + forall + { + true exch + { + dup (Cyan) eq exch + dup (Magenta) eq 3 -1 roll or exch + dup (Yellow) eq 3 -1 roll or exch + (Black) eq or and + }forall + not + }{pop false}ifelse + }{ + false exch + { + dup (Cyan) eq exch + dup (Magenta) eq 3 -1 roll or exch + dup (Yellow) eq 3 -1 roll or exch + dup (Black) eq 3 -1 roll or + {pop} + {convert_spot_to_process or}ifelse + } + forall + }ifelse + }ifelse + }def + }ifelse + /AGMCORE_avoid_L2_sep_space + version cvr 2012 lt + level2 and + AGMCORE_producing_seps not and + def + /AGMCORE_is_cmyk_sep + AGMCORE_cyan_plate AGMCORE_magenta_plate or AGMCORE_yellow_plate or AGMCORE_black_plate or + def + /AGM_avoid_0_cmyk where{ + pop AGM_avoid_0_cmyk + }{ + AGM_preserve_spots + userdict/Adobe_AGM_OnHost_Seps known + userdict/Adobe_AGM_InRip_Seps known or + not and + }ifelse + { + /setcmykcolor[ + { + 4 copy add add add 0 eq currentoverprint and{ + pop 0.0005 + }if + }/exec cvx + /AGMCORE_&setcmykcolor load dup type/operatortype ne{ + /exec cvx + }if + ]cvx def + }if + AGMCORE_host_sep{ + /setcolortransfer + { + AGMCORE_cyan_plate{ + pop pop pop + }{ + AGMCORE_magenta_plate{ + 4 3 roll pop pop pop + }{ + AGMCORE_yellow_plate{ + 4 2 roll pop pop pop + }{ + 4 1 roll pop pop pop + }ifelse + }ifelse + }ifelse + settransfer + } + def + /AGMCORE_get_ink_data + AGMCORE_cyan_plate{ + {pop pop pop} + }{ + AGMCORE_magenta_plate{ + {4 3 roll pop pop pop} + }{ + AGMCORE_yellow_plate{ + {4 2 roll pop pop pop} + }{ + {4 1 roll pop pop pop} + }ifelse + }ifelse + }ifelse + def + /AGMCORE_RemoveProcessColorNames + { + 1 dict begin + /filtername + { + dup /Cyan eq 1 index (Cyan) eq or + {pop (_cyan_)}if + dup /Magenta eq 1 index (Magenta) eq or + {pop (_magenta_)}if + dup /Yellow eq 1 index (Yellow) eq or + {pop (_yellow_)}if + dup /Black eq 1 index (Black) eq or + {pop (_black_)}if + }def + dup type /arraytype eq + {[exch {filtername}forall]} + {filtername}ifelse + end + }def + /AGMCORE_IsSeparationAProcessColor + { + dup (Cyan) eq exch dup (Magenta) eq exch dup (Yellow) eq exch (Black) eq or or or + }def + level3 { + /AGMCORE_IsCurrentColor + { + gsave + false setoverprint + 1 1 1 1 5 -1 roll findcmykcustomcolor 1 setcustomcolor + currentgray 0 eq + grestore + }def + /AGMCORE_filter_functiondatasource + { + 5 dict begin + /data_in xdf + data_in type /stringtype eq + { + /ncomp xdf + /comp xdf + /string_out data_in length ncomp idiv string def + 0 ncomp data_in length 1 sub + { + string_out exch dup ncomp idiv exch data_in exch ncomp getinterval comp get 255 exch sub put + }for + string_out + }{ + string /string_in xdf + /string_out 1 string def + /component xdf + [ + data_in string_in /readstring cvx + [component /get cvx 255 /exch cvx /sub cvx string_out /exch cvx 0 /exch cvx /put cvx string_out]cvx + [/pop cvx ()]cvx /ifelse cvx + ]cvx /ReusableStreamDecode filter + }ifelse + end + }def + /AGMCORE_separateShadingFunction + { + 2 dict begin + /paint? xdf + /channel xdf + begin + FunctionType 0 eq + { + /DataSource channel Range length 2 idiv DataSource AGMCORE_filter_functiondatasource def + currentdict /Decode known + {/Decode Decode channel 2 mul 2 getinterval def}if + paint? not + {/Decode [1 1]def}if + }if + FunctionType 2 eq + { + paint? + { + /C0 [C0 channel get 1 exch sub] def + /C1 [C1 channel get 1 exch sub] def + }{ + /C0 [1] def + /C1 [1] def + }ifelse + }if + FunctionType 3 eq + { + /Functions [Functions {channel paint? AGMCORE_separateShadingFunction} forall] def + }if + currentdict /Range known + {/Range [0 1] def}if + currentdict + end + end + }def + /AGMCORE_separateShading + { + 3 -1 roll begin + currentdict /Function known + { + currentdict /Background known + {[1 index{Background 3 index get 1 exch sub}{1}ifelse]/Background xdf}if + Function 3 1 roll AGMCORE_separateShadingFunction /Function xdf + /ColorSpace [/DeviceGray] def + }{ + ColorSpace dup type /arraytype eq {0 get}if /DeviceCMYK eq + { + /ColorSpace [/DeviceN [/_cyan_ /_magenta_ /_yellow_ /_black_] /DeviceCMYK {}] def + }{ + ColorSpace dup 1 get AGMCORE_RemoveProcessColorNames 1 exch put + }ifelse + ColorSpace 0 get /Separation eq + { + { + [1 /exch cvx /sub cvx]cvx + }{ + [/pop cvx 1]cvx + }ifelse + ColorSpace 3 3 -1 roll put + pop + }{ + { + [exch ColorSpace 1 get length 1 sub exch sub /index cvx 1 /exch cvx /sub cvx ColorSpace 1 get length 1 add 1 /roll cvx ColorSpace 1 get length{/pop cvx} repeat]cvx + }{ + pop [ColorSpace 1 get length {/pop cvx} repeat cvx 1]cvx + }ifelse + ColorSpace 3 3 -1 roll bind put + }ifelse + ColorSpace 2 /DeviceGray put + }ifelse + end + }def + /AGMCORE_separateShadingDict + { + dup /ColorSpace get + dup type /arraytype ne + {[exch]}if + dup 0 get /DeviceCMYK eq + { + exch begin + currentdict + AGMCORE_cyan_plate + {0 true}if + AGMCORE_magenta_plate + {1 true}if + AGMCORE_yellow_plate + {2 true}if + AGMCORE_black_plate + {3 true}if + AGMCORE_plate_ndx 4 eq + {0 false}if + dup not currentoverprint and + {/AGMCORE_ignoreshade true def}if + AGMCORE_separateShading + currentdict + end exch + }if + dup 0 get /Separation eq + { + exch begin + ColorSpace 1 get dup /None ne exch /All ne and + { + ColorSpace 1 get AGMCORE_IsCurrentColor AGMCORE_plate_ndx 4 lt and ColorSpace 1 get AGMCORE_IsSeparationAProcessColor not and + { + ColorSpace 2 get dup type /arraytype eq {0 get}if /DeviceCMYK eq + { + /ColorSpace + [ + /Separation + ColorSpace 1 get + /DeviceGray + [ + ColorSpace 3 get /exec cvx + 4 AGMCORE_plate_ndx sub -1 /roll cvx + 4 1 /roll cvx + 3 [/pop cvx]cvx /repeat cvx + 1 /exch cvx /sub cvx + ]cvx + ]def + }{ + AGMCORE_report_unsupported_color_space + AGMCORE_black_plate not + { + currentdict 0 false AGMCORE_separateShading + }if + }ifelse + }{ + currentdict ColorSpace 1 get AGMCORE_IsCurrentColor + 0 exch + dup not currentoverprint and + {/AGMCORE_ignoreshade true def}if + AGMCORE_separateShading + }ifelse + }if + currentdict + end exch + }if + dup 0 get /DeviceN eq + { + exch begin + ColorSpace 1 get convert_to_process + { + ColorSpace 2 get dup type /arraytype eq {0 get}if /DeviceCMYK eq + { + /ColorSpace + [ + /DeviceN + ColorSpace 1 get + /DeviceGray + [ + ColorSpace 3 get /exec cvx + 4 AGMCORE_plate_ndx sub -1 /roll cvx + 4 1 /roll cvx + 3 [/pop cvx]cvx /repeat cvx + 1 /exch cvx /sub cvx + ]cvx + ]def + }{ + AGMCORE_report_unsupported_color_space + AGMCORE_black_plate not + { + currentdict 0 false AGMCORE_separateShading + /ColorSpace [/DeviceGray] def + }if + }ifelse + }{ + currentdict + false -1 ColorSpace 1 get + { + AGMCORE_IsCurrentColor + { + 1 add + exch pop true exch exit + }if + 1 add + }forall + exch + dup not currentoverprint and + {/AGMCORE_ignoreshade true def}if + AGMCORE_separateShading + }ifelse + currentdict + end exch + }if + dup 0 get dup /DeviceCMYK eq exch dup /Separation eq exch /DeviceN eq or or not + { + exch begin + ColorSpace dup type /arraytype eq + {0 get}if + /DeviceGray ne + { + AGMCORE_report_unsupported_color_space + AGMCORE_black_plate not + { + ColorSpace 0 get /CIEBasedA eq + { + /ColorSpace [/Separation /_ciebaseda_ /DeviceGray {}] def + }if + ColorSpace 0 get dup /CIEBasedABC eq exch dup /CIEBasedDEF eq exch /DeviceRGB eq or or + { + /ColorSpace [/DeviceN [/_red_ /_green_ /_blue_] /DeviceRGB {}] def + }if + ColorSpace 0 get /CIEBasedDEFG eq + { + /ColorSpace [/DeviceN [/_cyan_ /_magenta_ /_yellow_ /_black_] /DeviceCMYK {}] + }if + currentdict 0 false AGMCORE_separateShading + }if + }if + currentdict + end exch + }if + pop + dup /AGMCORE_ignoreshade known + { + begin + /ColorSpace [/Separation (None) /DeviceGray {}] def + currentdict end + }if + }def + /shfill + { + clonedict + AGMCORE_separateShadingDict + dup /AGMCORE_ignoreshade known + {pop} + {AGMCORE_&sysshfill}ifelse + }def + /makepattern + { + exch + dup /PatternType get 2 eq + { + clonedict + begin + /Shading Shading AGMCORE_separateShadingDict def + currentdict end + exch AGMCORE_&sysmakepattern + }{ + exch AGMCORE_&usrmakepattern + }ifelse + }def + }if + }if + AGMCORE_in_rip_sep{ + /setcustomcolor + { + exch aload pop + dup 7 1 roll inRip_spot_has_ink not { + 4 {4 index mul 4 1 roll} + repeat + /DeviceCMYK setcolorspace + 6 -2 roll pop pop + }{ + Adobe_AGM_Core begin + /AGMCORE_k xdf /AGMCORE_y xdf /AGMCORE_m xdf /AGMCORE_c xdf + end + [/Separation 4 -1 roll /DeviceCMYK + {dup AGMCORE_c mul exch dup AGMCORE_m mul exch dup AGMCORE_y mul exch AGMCORE_k mul} + ] + setcolorspace + }ifelse + setcolor + }ndf + /setseparationgray + { + [/Separation (All) /DeviceGray {}] setcolorspace_opt + 1 exch sub setcolor + }ndf + }{ + /setseparationgray + { + AGMCORE_&setgray + }ndf + }ifelse + /findcmykcustomcolor + { + 5 makereadonlyarray + }ndf + /setcustomcolor + { + exch aload pop pop + 4 {4 index mul 4 1 roll} repeat + setcmykcolor pop + }ndf + /has_color + /colorimage where{ + AGMCORE_producing_seps{ + pop true + }{ + systemdict eq + }ifelse + }{ + false + }ifelse + def + /map_index + { + 1 index mul exch getinterval {255 div} forall + } bdf + /map_indexed_devn + { + Lookup Names length 3 -1 roll cvi map_index + } bdf + /n_color_components + { + base_colorspace_type + dup /DeviceGray eq{ + pop 1 + }{ + /DeviceCMYK eq{ + 4 + }{ + 3 + }ifelse + }ifelse + }bdf + level2{ + /mo /moveto ldf + /li /lineto ldf + /cv /curveto ldf + /knockout_unitsq + { + 1 setgray + 0 0 1 1 rectfill + }def + /level2ScreenFreq{ + begin + 60 + HalftoneType 1 eq{ + pop Frequency + }if + HalftoneType 2 eq{ + pop GrayFrequency + }if + HalftoneType 5 eq{ + pop Default level2ScreenFreq + }if + end + }def + /currentScreenFreq{ + currenthalftone level2ScreenFreq + }def + level2 /setcolorspace AGMCORE_key_known not and{ + /AGMCORE_&&&setcolorspace /setcolorspace ldf + /AGMCORE_ReplaceMappedColor + { + dup type dup /arraytype eq exch /packedarraytype eq or + { + dup 0 get dup /Separation eq + { + pop + dup length array copy + dup dup 1 get + current_spot_alias + { + dup map_alias + { + begin + /sep_colorspace_dict currentdict AGMCORE_gput + pop pop pop + [ + /Separation Name + CSA map_csa + dup /MappedCSA xdf + /sep_colorspace_proc load + ] + dup Name + end + }if + }if + map_reserved_ink_name 1 xpt + }{ + /DeviceN eq + { + dup length array copy + dup dup 1 get [ + exch { + current_spot_alias{ + dup map_alias{ + /Name get exch pop + }if + }if + map_reserved_ink_name + } forall + ] 1 xpt + }if + }ifelse + }if + }def + /setcolorspace + { + dup type dup /arraytype eq exch /packedarraytype eq or + { + dup 0 get /Indexed eq + { + AGMCORE_distilling + { + /PhotoshopDuotoneList where + { + pop false + }{ + true + }ifelse + }{ + true + }ifelse + { + aload pop 3 -1 roll + AGMCORE_ReplaceMappedColor + 3 1 roll 4 array astore + }if + }{ + AGMCORE_ReplaceMappedColor + }ifelse + }if + DeviceN_PS2_inRip_seps {AGMCORE_&&&setcolorspace} if + }def + }if + }{ + /adj + { + currentstrokeadjust{ + transform + 0.25 sub round 0.25 add exch + 0.25 sub round 0.25 add exch + itransform + }if + }def + /mo{ + adj moveto + }def + /li{ + adj lineto + }def + /cv{ + 6 2 roll adj + 6 2 roll adj + 6 2 roll adj curveto + }def + /knockout_unitsq + { + 1 setgray + 8 8 1 [8 0 0 8 0 0] {} image + }def + /currentstrokeadjust{ + /currentstrokeadjust AGMCORE_gget + }def + /setstrokeadjust{ + /currentstrokeadjust exch AGMCORE_gput + }def + /currentScreenFreq{ + currentscreen pop pop + }def + /setcolorspace + { + /currentcolorspace exch AGMCORE_gput + } def + /currentcolorspace + { + /currentcolorspace AGMCORE_gget + } def + /setcolor_devicecolor + { + base_colorspace_type + dup /DeviceGray eq{ + pop setgray + }{ + /DeviceCMYK eq{ + setcmykcolor + }{ + setrgbcolor + }ifelse + }ifelse + }def + /setcolor + { + currentcolorspace 0 get + dup /DeviceGray ne{ + dup /DeviceCMYK ne{ + dup /DeviceRGB ne{ + dup /Separation eq{ + pop + currentcolorspace 3 get exec + currentcolorspace 2 get + }{ + dup /Indexed eq{ + pop + currentcolorspace 3 get dup type /stringtype eq{ + currentcolorspace 1 get n_color_components + 3 -1 roll map_index + }{ + exec + }ifelse + currentcolorspace 1 get + }{ + /AGMCORE_cur_err /AGMCORE_invalid_color_space def + AGMCORE_invalid_color_space + }ifelse + }ifelse + }if + }if + }if + setcolor_devicecolor + } def + }ifelse + /sop /setoverprint ldf + /lw /setlinewidth ldf + /lc /setlinecap ldf + /lj /setlinejoin ldf + /ml /setmiterlimit ldf + /dsh /setdash ldf + /sadj /setstrokeadjust ldf + /gry /setgray ldf + /rgb /setrgbcolor ldf + /cmyk /setcmykcolor ldf + /sep /setsepcolor ldf + /devn /setdevicencolor ldf + /idx /setindexedcolor ldf + /colr /setcolor ldf + /csacrd /set_csa_crd ldf + /sepcs /setsepcolorspace ldf + /devncs /setdevicencolorspace ldf + /idxcs /setindexedcolorspace ldf + /cp /closepath ldf + /clp /clp_npth ldf + /eclp /eoclp_npth ldf + /f /fill ldf + /ef /eofill ldf + /@ /stroke ldf + /nclp /npth_clp ldf + /gset /graphic_setup ldf + /gcln /graphic_cleanup ldf + currentdict{ + dup xcheck 1 index type dup /arraytype eq exch /packedarraytype eq or and { + bind + }if + def + }forall + /currentpagedevice currentpagedevice def +/getrampcolor { +/indx exch def +0 1 NumComp 1 sub { +dup +Samples exch get +dup type /stringtype eq { indx get } if +exch +Scaling exch get aload pop +3 1 roll +mul add +} for +ColorSpaceFamily /Separation eq + { + sep + } + { + ColorSpaceFamily /DeviceN eq + { + devn + } + { + setcolor + }ifelse + }ifelse +} bind def +/sssetbackground { aload pop setcolor } bind def +/RadialShade { +40 dict begin +/ColorSpaceFamily exch def +/background exch def +/ext1 exch def +/ext0 exch def +/BBox exch def +/r2 exch def +/c2y exch def +/c2x exch def +/r1 exch def +/c1y exch def +/c1x exch def +/rampdict exch def +/setinkoverprint where {pop /setinkoverprint{pop}def}if +gsave +BBox length 0 gt { +newpath +BBox 0 get BBox 1 get moveto +BBox 2 get BBox 0 get sub 0 rlineto +0 BBox 3 get BBox 1 get sub rlineto +BBox 2 get BBox 0 get sub neg 0 rlineto +closepath +clip +newpath +} if +c1x c2x eq +{ +c1y c2y lt {/theta 90 def}{/theta 270 def} ifelse +} +{ +/slope c2y c1y sub c2x c1x sub div def +/theta slope 1 atan def +c2x c1x lt c2y c1y ge and { /theta theta 180 sub def} if +c2x c1x lt c2y c1y lt and { /theta theta 180 add def} if +} +ifelse +gsave +clippath +c1x c1y translate +theta rotate +-90 rotate +{ pathbbox } stopped +{ 0 0 0 0 } if +/yMax exch def +/xMax exch def +/yMin exch def +/xMin exch def +grestore +xMax xMin eq yMax yMin eq or +{ +grestore +end +} +{ +/max { 2 copy gt { pop } {exch pop} ifelse } bind def +/min { 2 copy lt { pop } {exch pop} ifelse } bind def +rampdict begin +40 dict begin +background length 0 gt { background sssetbackground gsave clippath fill grestore } if +gsave +c1x c1y translate +theta rotate +-90 rotate +/c2y c1x c2x sub dup mul c1y c2y sub dup mul add sqrt def +/c1y 0 def +/c1x 0 def +/c2x 0 def +ext0 { +0 getrampcolor +c2y r2 add r1 sub 0.0001 lt +{ +c1x c1y r1 360 0 arcn +pathbbox +/aymax exch def +/axmax exch def +/aymin exch def +/axmin exch def +/bxMin xMin axmin min def +/byMin yMin aymin min def +/bxMax xMax axmax max def +/byMax yMax aymax max def +bxMin byMin moveto +bxMax byMin lineto +bxMax byMax lineto +bxMin byMax lineto +bxMin byMin lineto +eofill +} +{ +c2y r1 add r2 le +{ +c1x c1y r1 0 360 arc +fill +} +{ +c2x c2y r2 0 360 arc fill +r1 r2 eq +{ +/p1x r1 neg def +/p1y c1y def +/p2x r1 def +/p2y c1y def +p1x p1y moveto p2x p2y lineto p2x yMin lineto p1x yMin lineto +fill +} +{ +/AA r2 r1 sub c2y div def +/theta AA 1 AA dup mul sub sqrt div 1 atan def +/SS1 90 theta add dup sin exch cos div def +/p1x r1 SS1 SS1 mul SS1 SS1 mul 1 add div sqrt mul neg def +/p1y p1x SS1 div neg def +/SS2 90 theta sub dup sin exch cos div def +/p2x r1 SS2 SS2 mul SS2 SS2 mul 1 add div sqrt mul def +/p2y p2x SS2 div neg def +r1 r2 gt +{ +/L1maxX p1x yMin p1y sub SS1 div add def +/L2maxX p2x yMin p2y sub SS2 div add def +} +{ +/L1maxX 0 def +/L2maxX 0 def +}ifelse +p1x p1y moveto p2x p2y lineto L2maxX L2maxX p2x sub SS2 mul p2y add lineto +L1maxX L1maxX p1x sub SS1 mul p1y add lineto +fill +} +ifelse +} +ifelse +} ifelse +} if +c1x c2x sub dup mul +c1y c2y sub dup mul +add 0.5 exp +0 dtransform +dup mul exch dup mul add 0.5 exp 72 div +0 72 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt +72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt +1 index 1 index lt { exch } if pop +/hires exch def +hires mul +/numpix exch def +/numsteps NumSamples def +/rampIndxInc 1 def +/subsampling false def +numpix 0 ne +{ +NumSamples numpix div 0.5 gt +{ +/numsteps numpix 2 div round cvi dup 1 le { pop 2 } if def +/rampIndxInc NumSamples 1 sub numsteps div def +/subsampling true def +} if +} if +/xInc c2x c1x sub numsteps div def +/yInc c2y c1y sub numsteps div def +/rInc r2 r1 sub numsteps div def +/cx c1x def +/cy c1y def +/radius r1 def +newpath +xInc 0 eq yInc 0 eq rInc 0 eq and and +{ +0 getrampcolor +cx cy radius 0 360 arc +stroke +NumSamples 1 sub getrampcolor +cx cy radius 72 hires div add 0 360 arc +0 setlinewidth +stroke +} +{ +0 +numsteps +{ +dup +subsampling { round cvi } if +getrampcolor +cx cy radius 0 360 arc +/cx cx xInc add def +/cy cy yInc add def +/radius radius rInc add def +cx cy radius 360 0 arcn +eofill +rampIndxInc add +} +repeat +pop +} ifelse +ext1 { +c2y r2 add r1 lt +{ +c2x c2y r2 0 360 arc +fill +} +{ +c2y r1 add r2 sub 0.0001 le +{ +c2x c2y r2 360 0 arcn +pathbbox +/aymax exch def +/axmax exch def +/aymin exch def +/axmin exch def +/bxMin xMin axmin min def +/byMin yMin aymin min def +/bxMax xMax axmax max def +/byMax yMax aymax max def +bxMin byMin moveto +bxMax byMin lineto +bxMax byMax lineto +bxMin byMax lineto +bxMin byMin lineto +eofill +} +{ +c2x c2y r2 0 360 arc fill +r1 r2 eq +{ +/p1x r2 neg def +/p1y c2y def +/p2x r2 def +/p2y c2y def +p1x p1y moveto p2x p2y lineto p2x yMax lineto p1x yMax lineto +fill +} +{ +/AA r2 r1 sub c2y div def +/theta AA 1 AA dup mul sub sqrt div 1 atan def +/SS1 90 theta add dup sin exch cos div def +/p1x r2 SS1 SS1 mul SS1 SS1 mul 1 add div sqrt mul neg def +/p1y c2y p1x SS1 div sub def +/SS2 90 theta sub dup sin exch cos div def +/p2x r2 SS2 SS2 mul SS2 SS2 mul 1 add div sqrt mul def +/p2y c2y p2x SS2 div sub def +r1 r2 lt +{ +/L1maxX p1x yMax p1y sub SS1 div add def +/L2maxX p2x yMax p2y sub SS2 div add def +} +{ +/L1maxX 0 def +/L2maxX 0 def +}ifelse +p1x p1y moveto p2x p2y lineto L2maxX L2maxX p2x sub SS2 mul p2y add lineto +L1maxX L1maxX p1x sub SS1 mul p1y add lineto +fill +} +ifelse +} +ifelse +} ifelse +} if +grestore +grestore +end +end +end +} ifelse +} bind def +/GenStrips { +40 dict begin +/ColorSpaceFamily exch def +/background exch def +/ext1 exch def +/ext0 exch def +/BBox exch def +/y2 exch def +/x2 exch def +/y1 exch def +/x1 exch def +/rampdict exch def +/setinkoverprint where {pop /setinkoverprint{pop}def}if +gsave +BBox length 0 gt { +newpath +BBox 0 get BBox 1 get moveto +BBox 2 get BBox 0 get sub 0 rlineto +0 BBox 3 get BBox 1 get sub rlineto +BBox 2 get BBox 0 get sub neg 0 rlineto +closepath +clip +newpath +} if +x1 x2 eq +{ +y1 y2 lt {/theta 90 def}{/theta 270 def} ifelse +} +{ +/slope y2 y1 sub x2 x1 sub div def +/theta slope 1 atan def +x2 x1 lt y2 y1 ge and { /theta theta 180 sub def} if +x2 x1 lt y2 y1 lt and { /theta theta 180 add def} if +} +ifelse +gsave +clippath +x1 y1 translate +theta rotate +{ pathbbox } stopped +{ 0 0 0 0 } if +/yMax exch def +/xMax exch def +/yMin exch def +/xMin exch def +grestore +xMax xMin eq yMax yMin eq or +{ +grestore +end +} +{ +rampdict begin +20 dict begin +background length 0 gt { background sssetbackground gsave clippath fill grestore } if +gsave +x1 y1 translate +theta rotate +/xStart 0 def +/xEnd x2 x1 sub dup mul y2 y1 sub dup mul add 0.5 exp def +/ySpan yMax yMin sub def +/numsteps NumSamples def +/rampIndxInc 1 def +/subsampling false def +xStart 0 transform +xEnd 0 transform +3 -1 roll +sub dup mul +3 1 roll +sub dup mul +add 0.5 exp 72 div +0 72 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt +72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt +1 index 1 index lt { exch } if pop +mul +/numpix exch def +numpix 0 ne +{ +NumSamples numpix div 0.5 gt +{ +/numsteps numpix 2 div round cvi dup 1 le { pop 2 } if def +/rampIndxInc NumSamples 1 sub numsteps div def +/subsampling true def +} if +} if +ext0 { +0 getrampcolor +xMin xStart lt +{ xMin yMin xMin neg ySpan rectfill } if +} if +/xInc xEnd xStart sub numsteps div def +/x xStart def +0 +numsteps +{ +dup +subsampling { round cvi } if +getrampcolor +x yMin xInc ySpan rectfill +/x x xInc add def +rampIndxInc add +} +repeat +pop +ext1 { +xMax xEnd gt +{ xEnd yMin xMax xEnd sub ySpan rectfill } if +} if +grestore +grestore +end +end +end +} ifelse +} bind def +}def +/page_trailer +{ + end +}def +/doc_trailer{ +}def +systemdict /findcolorrendering known{ + /findcolorrendering systemdict /findcolorrendering get def +}if +systemdict /setcolorrendering known{ + /setcolorrendering systemdict /setcolorrendering get def +}if +/test_cmyk_color_plate +{ + gsave + setcmykcolor currentgray 1 ne + grestore +}def +/inRip_spot_has_ink +{ + dup Adobe_AGM_Core/AGMCORE_name xddf + convert_spot_to_process not +}def +/map255_to_range +{ + 1 index sub + 3 -1 roll 255 div mul add +}def +/set_csa_crd +{ + /sep_colorspace_dict null AGMCORE_gput + begin + CSA map_csa setcolorspace_opt + set_crd + end +} +def +/setsepcolor +{ + /sep_colorspace_dict AGMCORE_gget begin + dup /sep_tint exch AGMCORE_gput + TintProc + end +} def +/setdevicencolor +{ + /devicen_colorspace_dict AGMCORE_gget begin + Names length copy + Names length 1 sub -1 0 + { + /devicen_tints AGMCORE_gget 3 1 roll xpt + } for + TintProc + end +} def +/sep_colorspace_proc +{ + Adobe_AGM_Core/AGMCORE_tmp xddf + /sep_colorspace_dict AGMCORE_gget begin + currentdict/Components known{ + Components aload pop + TintMethod/Lab eq{ + 2 {AGMCORE_tmp mul NComponents 1 roll} repeat + LMax sub AGMCORE_tmp mul LMax add NComponents 1 roll + }{ + TintMethod/Subtractive eq{ + NComponents{ + AGMCORE_tmp mul NComponents 1 roll + }repeat + }{ + NComponents{ + 1 sub AGMCORE_tmp mul 1 add NComponents 1 roll + } repeat + }ifelse + }ifelse + }{ + ColorLookup AGMCORE_tmp ColorLookup length 1 sub mul round cvi get + aload pop + }ifelse + end +} def +/sep_colorspace_gray_proc +{ + Adobe_AGM_Core/AGMCORE_tmp xddf + /sep_colorspace_dict AGMCORE_gget begin + GrayLookup AGMCORE_tmp GrayLookup length 1 sub mul round cvi get + end +} def +/sep_proc_name +{ + dup 0 get + dup /DeviceRGB eq exch /DeviceCMYK eq or level2 not and has_color not and{ + pop [/DeviceGray] + /sep_colorspace_gray_proc + }{ + /sep_colorspace_proc + }ifelse +} def +/setsepcolorspace +{ + current_spot_alias{ + dup begin + Name map_alias{ + exch pop + }if + end + }if + dup /sep_colorspace_dict exch AGMCORE_gput + begin + /MappedCSA CSA map_csa def + Adobe_AGM_Core/AGMCORE_sep_special Name dup () eq exch (All) eq or ddf + AGMCORE_avoid_L2_sep_space{ + [/Indexed MappedCSA sep_proc_name 255 exch + { 255 div } /exec cvx 3 -1 roll [ 4 1 roll load /exec cvx ] cvx + ] setcolorspace_opt + /TintProc { + 255 mul round cvi setcolor + }bdf + }{ + MappedCSA 0 get /DeviceCMYK eq + currentdict/Components known and + AGMCORE_sep_special not and{ + /TintProc [ + Components aload pop Name findcmykcustomcolor + /exch cvx /setcustomcolor cvx + ] cvx bdf + }{ + AGMCORE_host_sep Name (All) eq and{ + /TintProc { + 1 exch sub setseparationgray + }bdf + }{ + AGMCORE_in_rip_sep MappedCSA 0 get /DeviceCMYK eq and + AGMCORE_host_sep or + Name () eq and{ + /TintProc [ + MappedCSA sep_proc_name exch 0 get /DeviceCMYK eq{ + cvx /setcmykcolor cvx + }{ + cvx /setgray cvx + }ifelse + ] cvx bdf + }{ + AGMCORE_producing_seps MappedCSA 0 get dup /DeviceCMYK eq exch /DeviceGray eq or and AGMCORE_sep_special not and{ + /TintProc [ + /dup cvx + MappedCSA sep_proc_name cvx exch + 0 get /DeviceGray eq{ + 1 /exch cvx /sub cvx 0 0 0 4 -1 /roll cvx + }if + /Name cvx /findcmykcustomcolor cvx /exch cvx + AGMCORE_host_sep{ + AGMCORE_is_cmyk_sep + /Name cvx + /AGMCORE_IsSeparationAProcessColor load /exec cvx + /not cvx /and cvx + }{ + Name inRip_spot_has_ink not + }ifelse + [ + /pop cvx 1 + ] cvx /if cvx + /setcustomcolor cvx + ] cvx bdf + }{ + /TintProc /setcolor ldf + [/Separation Name MappedCSA sep_proc_name load ] setcolorspace_opt + }ifelse + }ifelse + }ifelse + }ifelse + }ifelse + set_crd + setsepcolor + end +} def +/additive_blend +{ + 3 dict begin + /numarrays xdf + /numcolors xdf + 0 1 numcolors 1 sub + { + /c1 xdf + 1 + 0 1 numarrays 1 sub + { + 1 exch add /index cvx + c1 /get cvx /mul cvx + }for + numarrays 1 add 1 /roll cvx + }for + numarrays [/pop cvx] cvx /repeat cvx + end +}def +/subtractive_blend +{ + 3 dict begin + /numarrays xdf + /numcolors xdf + 0 1 numcolors 1 sub + { + /c1 xdf + 1 1 + 0 1 numarrays 1 sub + { + 1 3 3 -1 roll add /index cvx + c1 /get cvx /sub cvx /mul cvx + }for + /sub cvx + numarrays 1 add 1 /roll cvx + }for + numarrays [/pop cvx] cvx /repeat cvx + end +}def +/exec_tint_transform +{ + /TintProc [ + /TintTransform cvx /setcolor cvx + ] cvx bdf + MappedCSA setcolorspace_opt +} bdf +/devn_makecustomcolor +{ + 2 dict begin + /names_index xdf + /Names xdf + 1 1 1 1 Names names_index get findcmykcustomcolor + /devicen_tints AGMCORE_gget names_index get setcustomcolor + Names length {pop} repeat + end +} bdf +/setdevicencolorspace +{ + dup /AliasedColorants known {false}{true}ifelse + current_spot_alias and { + 6 dict begin + /names_index 0 def + dup /names_len exch /Names get length def + /new_names names_len array def + /new_LookupTables names_len array def + /alias_cnt 0 def + dup /Names get + { + dup map_alias { + exch pop + dup /ColorLookup known { + dup begin + new_LookupTables names_index ColorLookup put + end + }{ + dup /Components known { + dup begin + new_LookupTables names_index Components put + end + }{ + dup begin + new_LookupTables names_index [null null null null] put + end + } ifelse + } ifelse + new_names names_index 3 -1 roll /Name get put + /alias_cnt alias_cnt 1 add def + }{ + /name xdf + new_names names_index name put + dup /LookupTables known { + dup begin + new_LookupTables names_index LookupTables names_index get put + end + }{ + dup begin + new_LookupTables names_index [null null null null] put + end + } ifelse + } ifelse + /names_index names_index 1 add def + } forall + alias_cnt 0 gt { + /AliasedColorants true def + 0 1 names_len 1 sub { + /names_index xdf + new_LookupTables names_index get 0 get null eq { + dup /Names get names_index get /name xdf + name (Cyan) eq name (Magenta) eq name (Yellow) eq name (Black) eq + or or or not { + /AliasedColorants false def + exit + } if + } if + } for + AliasedColorants { + dup begin + /Names new_names def + /AliasedColorants true def + /LookupTables new_LookupTables def + currentdict /TTTablesIdx known not { + /TTTablesIdx -1 def + } if + currentdict /NComponents known not { + /NComponents TintMethod /Subtractive eq {4}{3}ifelse def + } if + end + } if + }if + end + } if + dup /devicen_colorspace_dict exch AGMCORE_gput + begin + /MappedCSA CSA map_csa def + currentdict /AliasedColorants known { + AliasedColorants + }{ + false + } ifelse + /TintTransform load type /nulltype eq or { + /TintTransform [ + 0 1 Names length 1 sub + { + /TTTablesIdx TTTablesIdx 1 add def + dup LookupTables exch get dup 0 get null eq + { + 1 index + Names exch get + dup (Cyan) eq + { + pop exch + LookupTables length exch sub + /index cvx + 0 0 0 + } + { + dup (Magenta) eq + { + pop exch + LookupTables length exch sub + /index cvx + 0 /exch cvx 0 0 + } + { + (Yellow) eq + { + exch + LookupTables length exch sub + /index cvx + 0 0 3 -1 /roll cvx 0 + } + { + exch + LookupTables length exch sub + /index cvx + 0 0 0 4 -1 /roll cvx + } ifelse + } ifelse + } ifelse + 5 -1 /roll cvx /astore cvx + } + { + dup length 1 sub + LookupTables length 4 -1 roll sub 1 add + /index cvx /mul cvx /round cvx /cvi cvx /get cvx + } ifelse + Names length TTTablesIdx add 1 add 1 /roll cvx + } for + Names length [/pop cvx] cvx /repeat cvx + NComponents Names length + TintMethod /Subtractive eq + { + subtractive_blend + } + { + additive_blend + } ifelse + ] cvx bdf + } if + AGMCORE_host_sep { + Names convert_to_process { + exec_tint_transform + } + { + currentdict /AliasedColorants known { + AliasedColorants not + }{ + false + } ifelse + 5 dict begin + /AvoidAliasedColorants xdf + /painted? false def + /names_index 0 def + /names_len Names length def + Names { + AvoidAliasedColorants { + /currentspotalias current_spot_alias def + false set_spot_alias + } if + AGMCORE_is_cmyk_sep { + dup (Cyan) eq AGMCORE_cyan_plate and exch + dup (Magenta) eq AGMCORE_magenta_plate and exch + dup (Yellow) eq AGMCORE_yellow_plate and exch + (Black) eq AGMCORE_black_plate and or or or { + /devicen_colorspace_dict AGMCORE_gget /TintProc [ + Names names_index /devn_makecustomcolor cvx + ] cvx ddf + /painted? true def + } if + painted? {exit} if + }{ + 0 0 0 0 5 -1 roll findcmykcustomcolor 1 setcustomcolor currentgray 0 eq { + /devicen_colorspace_dict AGMCORE_gget /TintProc [ + Names names_index /devn_makecustomcolor cvx + ] cvx ddf + /painted? true def + exit + } if + } ifelse + AvoidAliasedColorants { + currentspotalias set_spot_alias + } if + /names_index names_index 1 add def + } forall + painted? { + /devicen_colorspace_dict AGMCORE_gget /names_index names_index put + }{ + /devicen_colorspace_dict AGMCORE_gget /TintProc [ + names_len [/pop cvx] cvx /repeat cvx 1 /setseparationgray cvx + 0 0 0 0 () /findcmykcustomcolor cvx 0 /setcustomcolor cvx + ] cvx ddf + } ifelse + end + } ifelse + } + { + AGMCORE_in_rip_sep { + Names convert_to_process not + }{ + level3 + } ifelse + { + [/DeviceN Names MappedCSA /TintTransform load] setcolorspace_opt + /TintProc level3 not AGMCORE_in_rip_sep and { + [ + Names /length cvx [/pop cvx] cvx /repeat cvx + ] cvx bdf + }{ + /setcolor ldf + } ifelse + }{ + exec_tint_transform + } ifelse + } ifelse + set_crd + /AliasedColorants false def + end +} def +/setindexedcolorspace +{ + dup /indexed_colorspace_dict exch AGMCORE_gput + begin + currentdict /CSD known { + CSD get_csd /Names known { + CSD get_csd begin + currentdict devncs + AGMCORE_host_sep{ + 4 dict begin + /devnCompCnt Names length def + /NewLookup HiVal 1 add string def + 0 1 HiVal { + /tableIndex xdf + Lookup dup type /stringtype eq { + devnCompCnt tableIndex map_index + }{ + exec + } ifelse + setdevicencolor + currentgray + tableIndex exch + HiVal mul cvi + NewLookup 3 1 roll put + } for + [/Indexed currentcolorspace HiVal NewLookup] setcolorspace_opt + end + }{ + level3 + { + [/Indexed [/DeviceN Names MappedCSA /TintTransform load] HiVal Lookup] setcolorspace_opt + }{ + [/Indexed MappedCSA HiVal + [ + Lookup dup type /stringtype eq + {/exch cvx CSD get_csd /Names get length dup /mul cvx exch /getinterval cvx {255 div} /forall cvx} + {/exec cvx}ifelse + /TintTransform load /exec cvx + ]cvx + ]setcolorspace_opt + }ifelse + } ifelse + end + }{ + } ifelse + set_crd + } + { + /MappedCSA CSA map_csa def + AGMCORE_host_sep level2 not and{ + 0 0 0 0 setcmykcolor + }{ + [/Indexed MappedCSA + level2 not has_color not and{ + dup 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or{ + pop [/DeviceGray] + }if + HiVal GrayLookup + }{ + HiVal + currentdict/RangeArray known{ + { + /indexed_colorspace_dict AGMCORE_gget begin + Lookup exch + dup HiVal gt{ + pop HiVal + }if + NComponents mul NComponents getinterval {} forall + NComponents 1 sub -1 0{ + RangeArray exch 2 mul 2 getinterval aload pop map255_to_range + NComponents 1 roll + }for + end + } bind + }{ + Lookup + }ifelse + }ifelse + ] setcolorspace_opt + set_crd + }ifelse + }ifelse + end +}def +/setindexedcolor +{ + AGMCORE_host_sep { + /indexed_colorspace_dict AGMCORE_gget dup /CSD known { + begin + CSD get_csd begin + map_indexed_devn + devn + end + end + }{ + AGMCORE_gget/Lookup get 4 3 -1 roll map_index + pop setcmykcolor + } ifelse + }{ + level3 not AGMCORE_in_rip_sep and /indexed_colorspace_dict AGMCORE_gget /CSD known and { + /indexed_colorspace_dict AGMCORE_gget /CSD get get_csd begin + map_indexed_devn + devn + end + } + { + setcolor + } ifelse + }ifelse +} def +/ignoreimagedata +{ + currentoverprint not{ + gsave + dup clonedict begin + 1 setgray + /Decode [0 1] def + /DataSource def + /MultipleDataSources false def + /BitsPerComponent 8 def + currentdict end + systemdict /image get exec + grestore + }if + consumeimagedata +}def +/add_csa +{ + Adobe_AGM_Core begin + /AGMCORE_CSA_cache xput + end +}def +/get_csa_by_name +{ + dup type dup /nametype eq exch /stringtype eq or{ + Adobe_AGM_Core begin + 1 dict begin + /name xdf + AGMCORE_CSA_cache + { + 0 get name eq { + exit + }{ + pop + } ifelse + }forall + end + end + }{ + pop + } ifelse +}def +/map_csa +{ + dup type /nametype eq{ + Adobe_AGM_Core/AGMCORE_CSA_cache get exch get + }if +}def +/add_csd +{ + Adobe_AGM_Core begin + /AGMCORE_CSD_cache xput + end +}def +/get_csd +{ + dup type /nametype eq{ + Adobe_AGM_Core/AGMCORE_CSD_cache get exch get + }if +}def +/pattern_buf_init +{ + /count get 0 0 put +} def +/pattern_buf_next +{ + dup /count get dup 0 get + dup 3 1 roll + 1 add 0 xpt + get +} def +/cachepattern_compress +{ + 5 dict begin + currentfile exch 0 exch /SubFileDecode filter /ReadFilter exch def + /patarray 20 dict def + /string_size 16000 def + /readbuffer string_size string def + currentglobal true setglobal + patarray 1 array dup 0 1 put /count xpt + setglobal + /LZWFilter + { + exch + dup length 0 eq { + pop + }{ + patarray dup length 1 sub 3 -1 roll put + } ifelse + {string_size}{0}ifelse string + } /LZWEncode filter def + { + ReadFilter readbuffer readstring + exch LZWFilter exch writestring + not {exit} if + } loop + LZWFilter closefile + patarray + end +}def +/cachepattern +{ + 2 dict begin + currentfile exch 0 exch /SubFileDecode filter /ReadFilter exch def + /patarray 20 dict def + currentglobal true setglobal + patarray 1 array dup 0 1 put /count xpt + setglobal + { + ReadFilter 16000 string readstring exch + patarray dup length 1 sub 3 -1 roll put + not {exit} if + } loop + patarray dup dup length 1 sub () put + end +}def +/add_pattern +{ + Adobe_AGM_Core begin + /AGMCORE_pattern_cache xput + end +}def +/get_pattern +{ + dup type /nametype eq{ + Adobe_AGM_Core/AGMCORE_pattern_cache get exch get + dup wrap_paintproc + }if +}def +/wrap_paintproc +{ + statusdict /currentfilenameextend known{ + begin + /OldPaintProc /PaintProc load def + /PaintProc + { + mark exch + dup /OldPaintProc get stopped + {closefile restore end} if + cleartomark + } def + end + } {pop} ifelse +} def +/make_pattern +{ + dup matrix currentmatrix matrix concatmatrix 0 0 3 2 roll itransform + exch 3 index /XStep get 1 index exch 2 copy div cvi mul sub sub + exch 3 index /YStep get 1 index exch 2 copy div cvi mul sub sub + matrix translate exch matrix concatmatrix + 1 index begin + BBox 0 get XStep div cvi XStep mul /xshift exch neg def + BBox 1 get YStep div cvi YStep mul /yshift exch neg def + BBox 0 get xshift add + BBox 1 get yshift add + BBox 2 get xshift add + BBox 3 get yshift add + 4 array astore + /BBox exch def + [ xshift yshift /translate load null /exec load ] dup + 3 /PaintProc load put cvx /PaintProc exch def + end + gsave 0 setgray + makepattern + grestore +}def +/set_pattern +{ + dup /PatternType get 1 eq{ + dup /PaintType get 1 eq{ + currentoverprint sop [/DeviceGray] setcolorspace 0 setgray + }if + }if + setpattern +}def +/setcolorspace_opt +{ + dup currentcolorspace eq{ + pop + }{ + setcolorspace + }ifelse +}def +/updatecolorrendering +{ + currentcolorrendering/Intent known{ + currentcolorrendering/Intent get + }{ + null + }ifelse + Intent ne{ + false + Intent + AGMCORE_CRD_cache { + exch pop + begin + dup Intent eq{ + currentdict setcolorrendering_opt + end + exch pop true exch + exit + }if + end + } forall + pop + not{ + systemdict /findcolorrendering known{ + Intent findcolorrendering pop + /ColorRendering findresource + dup length dict copy + setcolorrendering_opt + }if + }if + }if +} def +/add_crd +{ + AGMCORE_CRD_cache 3 1 roll put +}def +/set_crd +{ + AGMCORE_host_sep not level2 and{ + currentdict/CRD known{ + AGMCORE_CRD_cache CRD get dup null ne{ + setcolorrendering_opt + }{ + pop + }ifelse + }{ + currentdict/Intent known{ + updatecolorrendering + }if + }ifelse + currentcolorspace dup type /arraytype eq + {0 get}if + /DeviceRGB eq + { + currentdict/UCR known + {/UCR}{/AGMCORE_currentucr}ifelse + load setundercolorremoval + currentdict/BG known + {/BG}{/AGMCORE_currentbg}ifelse + load setblackgeneration + }if + }if +}def +/setcolorrendering_opt +{ + dup currentcolorrendering eq{ + pop + }{ + begin + /Intent Intent def + currentdict + end + setcolorrendering + }ifelse +}def +/cpaint_gcomp +{ + convert_to_process Adobe_AGM_Core/AGMCORE_ConvertToProcess xddf + Adobe_AGM_Core/AGMCORE_ConvertToProcess get not + { + (%end_cpaint_gcomp) flushinput + }if +}def +/cpaint_gsep +{ + Adobe_AGM_Core/AGMCORE_ConvertToProcess get + { + (%end_cpaint_gsep) flushinput + }if +}def +/cpaint_gend +{ + newpath +}def +/path_rez +{ + dup 0 ne{ + AGMCORE_deviceDPI exch div + dup 1 lt{ + pop 1 + }if + setflat + }{ + pop + }ifelse +}def +/set_spot_alias_ary +{ + /AGMCORE_SpotAliasAry where{ + pop pop + }{ + Adobe_AGM_Core/AGMCORE_SpotAliasAry xddf + true set_spot_alias + }ifelse +}def +/set_spot_alias +{ + /AGMCORE_SpotAliasAry where{ + /AGMCORE_current_spot_alias 3 -1 roll put + }{ + pop + }ifelse +}def +/current_spot_alias +{ + /AGMCORE_SpotAliasAry where{ + /AGMCORE_current_spot_alias get + }{ + false + }ifelse +}def +/map_alias +{ + /AGMCORE_SpotAliasAry where{ + begin + /AGMCORE_name xdf + false + AGMCORE_SpotAliasAry{ + dup/Name get AGMCORE_name eq{ + save exch + /Adobe_AGM_Core currentdict def + /CSD get get_csd + exch restore + exch pop true + exit + }{ + pop + }ifelse + }forall + end + }{ + pop false + }ifelse +}bdf +/spot_alias +{ + true set_spot_alias + /AGMCORE_&setcustomcolor AGMCORE_key_known not { + Adobe_AGM_Core/AGMCORE_&setcustomcolor /setcustomcolor load put + } if + /customcolor_tint 1 AGMCORE_gput + Adobe_AGM_Core begin + /setcustomcolor + { + dup /customcolor_tint exch AGMCORE_gput + current_spot_alias{ + 1 index 4 get map_alias{ + mark 3 1 roll + setsepcolorspace + counttomark 0 ne{ + setsepcolor + }if + pop + pop + }{ + AGMCORE_&setcustomcolor + }ifelse + }{ + AGMCORE_&setcustomcolor + }ifelse + }bdf + end +}def +/begin_feature +{ + Adobe_AGM_Core/AGMCORE_feature_dictCount countdictstack put + count Adobe_AGM_Core/AGMCORE_feature_opCount 3 -1 roll put + {Adobe_AGM_Core/AGMCORE_feature_ctm matrix currentmatrix put}if +}def +/end_feature +{ + 2 dict begin + /spd /setpagedevice load def + /setpagedevice { get_gstate spd set_gstate } def + stopped{$error/newerror false put}if + end + count Adobe_AGM_Core/AGMCORE_feature_opCount get sub dup 0 gt{{pop}repeat}{pop}ifelse + countdictstack Adobe_AGM_Core/AGMCORE_feature_dictCount get sub dup 0 gt{{end}repeat}{pop}ifelse + {Adobe_AGM_Core/AGMCORE_feature_ctm get setmatrix}if +}def +/set_negative +{ + Adobe_AGM_Core begin + /AGMCORE_inverting exch def + level2{ + currentpagedevice/NegativePrint known{ + currentpagedevice/NegativePrint get Adobe_AGM_Core/AGMCORE_inverting get ne{ + true begin_feature true{ + bdict /NegativePrint Adobe_AGM_Core/AGMCORE_inverting get edict setpagedevice + }end_feature + }if + /AGMCORE_inverting false def + }if + }if + AGMCORE_inverting{ + [{1 exch sub}/exec load dup currenttransfer exch]cvx bind settransfer + gsave newpath clippath 1 /setseparationgray where{pop setseparationgray}{setgray}ifelse + /AGMIRS_&fill where {pop AGMIRS_&fill}{fill} ifelse grestore + }if + end +}def +/lw_save_restore_override { + /md where { + pop + md begin + initializepage + /initializepage{}def + /pmSVsetup{} def + /endp{}def + /pse{}def + /psb{}def + /orig_showpage where + {pop} + {/orig_showpage /showpage load def} + ifelse + /showpage {orig_showpage gR} def + end + }if +}def +/pscript_showpage_override { + /NTPSOct95 where + { + begin + showpage + save + /showpage /restore load def + /restore {exch pop}def + end + }if +}def +/driver_media_override +{ + /md where { + pop + md /initializepage known { + md /initializepage {} put + } if + md /rC known { + md /rC {4{pop}repeat} put + } if + }if + /mysetup where { + /mysetup [1 0 0 1 0 0] put + }if + Adobe_AGM_Core /AGMCORE_Default_CTM matrix currentmatrix put + level2 + {Adobe_AGM_Core /AGMCORE_Default_PageSize currentpagedevice/PageSize get put}if +}def +/driver_check_media_override +{ + /PrepsDict where + {pop} + { + Adobe_AGM_Core /AGMCORE_Default_CTM get matrix currentmatrix ne + Adobe_AGM_Core /AGMCORE_Default_PageSize get type /arraytype eq + { + Adobe_AGM_Core /AGMCORE_Default_PageSize get 0 get currentpagedevice/PageSize get 0 get eq and + Adobe_AGM_Core /AGMCORE_Default_PageSize get 1 get currentpagedevice/PageSize get 1 get eq and + }if + { + Adobe_AGM_Core /AGMCORE_Default_CTM get setmatrix + }if + }ifelse +}def +AGMCORE_err_strings begin + /AGMCORE_bad_environ (Environment not satisfactory for this job. Ensure that the PPD is correct or that the PostScript level requested is supported by this printer. ) def + /AGMCORE_color_space_onhost_seps (This job contains colors that will not separate with on-host methods. ) def + /AGMCORE_invalid_color_space (This job contains an invalid color space. ) def +end +end +systemdict /setpacking known +{ + setpacking +} if +%%EndResource +%%BeginResource: procset Adobe_CoolType_Core 2.23 0 +%%Copyright: Copyright 1997-2003 Adobe Systems Incorporated. All Rights Reserved. +%%Version: 2.23 0 +10 dict begin +/Adobe_CoolType_Passthru currentdict def +/Adobe_CoolType_Core_Defined userdict /Adobe_CoolType_Core known def +Adobe_CoolType_Core_Defined + { /Adobe_CoolType_Core userdict /Adobe_CoolType_Core get def } +if +userdict /Adobe_CoolType_Core 60 dict dup begin put +/Adobe_CoolType_Version 2.23 def +/Level2? + systemdict /languagelevel known dup + { pop systemdict /languagelevel get 2 ge } + if def +Level2? not + { + /currentglobal false def + /setglobal /pop load def + /gcheck { pop false } bind def + /currentpacking false def + /setpacking /pop load def + /SharedFontDirectory 0 dict def + } +if +currentpacking +true setpacking +/@_SaveStackLevels + { + Adobe_CoolType_Data + begin + @opStackCountByLevel @opStackLevel + 2 copy known not + { 2 copy 3 dict dup /args 7 index 5 add array put put get } + { + get dup /args get dup length 3 index lt + { + dup length 5 add array exch + 1 index exch 0 exch putinterval + 1 index exch /args exch put + } + { pop } + ifelse + } + ifelse + begin + count 2 sub 1 index lt + { pop count 1 sub } + if + dup /argCount exch def + dup 0 gt + { + exch 1 index 2 add 1 roll + args exch 0 exch getinterval + astore pop + } + { pop } + ifelse + count 1 sub /restCount exch def + end + /@opStackLevel @opStackLevel 1 add def + countdictstack 1 sub + @dictStackCountByLevel exch @dictStackLevel exch put + /@dictStackLevel @dictStackLevel 1 add def + end + } bind def +/@_RestoreStackLevels + { + Adobe_CoolType_Data + begin + /@opStackLevel @opStackLevel 1 sub def + @opStackCountByLevel @opStackLevel get + begin + count restCount sub dup 0 gt + { { pop } repeat } + { pop } + ifelse + args 0 argCount getinterval {} forall + end + /@dictStackLevel @dictStackLevel 1 sub def + @dictStackCountByLevel @dictStackLevel get + end + countdictstack exch sub dup 0 gt + { { end } repeat } + { pop } + ifelse + } bind def +/@_PopStackLevels + { + Adobe_CoolType_Data + begin + /@opStackLevel @opStackLevel 1 sub def + /@dictStackLevel @dictStackLevel 1 sub def + end + } bind def +/@Raise + { + exch cvx exch errordict exch get exec + stop + } bind def +/@ReRaise + { + cvx $error /errorname get errordict exch get exec + stop + } bind def +/@Stopped + { + 0 @#Stopped + } bind def +/@#Stopped + { + @_SaveStackLevels + stopped + { @_RestoreStackLevels true } + { @_PopStackLevels false } + ifelse + } bind def +/@Arg + { + Adobe_CoolType_Data + begin + @opStackCountByLevel @opStackLevel 1 sub get /args get exch get + end + } bind def +currentglobal true setglobal +/CTHasResourceForAllBug + Level2? + { + 1 dict dup begin + mark + { + (*) { pop stop } 128 string /Category + resourceforall + } + stopped + cleartomark + currentdict eq dup + { end } + if + not + } + { false } + ifelse + def +/CTHasResourceStatusBug + Level2? + { + mark + { /steveamerige /Category resourcestatus } + stopped + { cleartomark true } + { cleartomark currentglobal not } + ifelse + } + { false } + ifelse + def +setglobal +/CTResourceStatus + { + mark 3 1 roll + /Category findresource + begin + ({ResourceStatus} stopped) 0 () /SubFileDecode filter cvx exec + { cleartomark false } + { { 3 2 roll pop true } { cleartomark false } ifelse } + ifelse + end + } bind def +/CTWorkAroundBugs + { + Level2? + { + /cid_PreLoad /ProcSet resourcestatus + { + pop pop + currentglobal + mark + { + (*) + { + dup /CMap CTHasResourceStatusBug + { CTResourceStatus } + { resourcestatus } + ifelse + { + pop dup 0 eq exch 1 eq or + { + dup /CMap findresource gcheck setglobal + /CMap undefineresource + } + { + pop CTHasResourceForAllBug + { exit } + { stop } + ifelse + } + ifelse + } + { pop } + ifelse + } + 128 string /CMap resourceforall + } + stopped + { cleartomark } + stopped pop + setglobal + } + if + } + if + } bind def +/doc_setup + { + Adobe_CoolType_Core + begin + CTWorkAroundBugs + /mov /moveto load def + /nfnt /newencodedfont load def + /mfnt /makefont load def + /sfnt /setfont load def + /ufnt /undefinefont load def + /chp /charpath load def + /awsh /awidthshow load def + /wsh /widthshow load def + /ash /ashow load def + /sh /show load def + end + userdict /Adobe_CoolType_Data 10 dict dup + begin + /AddWidths? false def + /CC 0 def + /charcode 2 string def + /@opStackCountByLevel 32 dict def + /@opStackLevel 0 def + /@dictStackCountByLevel 32 dict def + /@dictStackLevel 0 def + /InVMFontsByCMap 10 dict def + /InVMDeepCopiedFonts 10 dict def + end put + } bind def +/doc_trailer + { + currentdict Adobe_CoolType_Core eq + { end } + if + } bind def +/page_setup + { + Adobe_CoolType_Core begin + } bind def +/page_trailer + { + end + } bind def +/unload + { + systemdict /languagelevel known + { + systemdict/languagelevel get 2 ge + { + userdict/Adobe_CoolType_Core 2 copy known + { undef } + { pop pop } + ifelse + } + if + } + if + } bind def +/ndf + { + 1 index where + { pop pop pop } + { dup xcheck { bind } if def } + ifelse + } def +/findfont systemdict + begin + userdict + begin + /globaldict where { /globaldict get begin } if + dup where pop exch get + /globaldict where { pop end } if + end + end +Adobe_CoolType_Core_Defined + { /systemfindfont exch def } + { + /findfont 1 index def + /systemfindfont exch def + } +ifelse +/undefinefont + { pop } ndf +/copyfont + { + currentglobal 3 1 roll + 1 index gcheck setglobal + dup null eq { 0 } { dup length } ifelse + 2 index length add 1 add dict + begin + exch + { + 1 index /FID eq + { pop pop } + { def } + ifelse + } + forall + dup null eq + { pop } + { { def } forall } + ifelse + currentdict + end + exch setglobal + } bind def +/copyarray + { + currentglobal exch + dup gcheck setglobal + dup length array copy + exch setglobal + } bind def +/newencodedfont + { + currentglobal + { + SharedFontDirectory 3 index known + { SharedFontDirectory 3 index get /FontReferenced known } + { false } + ifelse + } + { + FontDirectory 3 index known + { FontDirectory 3 index get /FontReferenced known } + { + SharedFontDirectory 3 index known + { SharedFontDirectory 3 index get /FontReferenced known } + { false } + ifelse + } + ifelse + } + ifelse + dup + { + 3 index findfont /FontReferenced get + 2 index dup type /nametype eq + {findfont} + if ne + { pop false } + if + } + if + { + pop + 1 index findfont + /Encoding get exch + 0 1 255 + { 2 copy get 3 index 3 1 roll put } + for + pop pop pop + } + { + dup type /nametype eq + { findfont } + if + dup dup maxlength 2 add dict + begin + exch + { + 1 index /FID ne + {def} + {pop pop} + ifelse + } + forall + /FontReferenced exch def + /Encoding exch dup length array copy def + /FontName 1 index dup type /stringtype eq { cvn } if def dup + currentdict + end + definefont def + } + ifelse + } bind def +/SetSubstituteStrategy + { + $SubstituteFont + begin + dup type /dicttype ne + { 0 dict } + if + currentdict /$Strategies known + { + exch $Strategies exch + 2 copy known + { + get + 2 copy maxlength exch maxlength add dict + begin + { def } forall + { def } forall + currentdict + dup /$Init known + { dup /$Init get exec } + if + end + /$Strategy exch def + } + { pop pop pop } + ifelse + } + { pop pop } + ifelse + end + } bind def +/scff + { + $SubstituteFont + begin + dup type /stringtype eq + { dup length exch } + { null } + ifelse + /$sname exch def + /$slen exch def + /$inVMIndex + $sname null eq + { + 1 index $str cvs + dup length $slen sub $slen getinterval cvn + } + { $sname } + ifelse def + end + { findfont } + @Stopped + { + dup length 8 add string exch + 1 index 0 (BadFont:) putinterval + 1 index exch 8 exch dup length string cvs putinterval cvn + { findfont } + @Stopped + { pop /Courier findfont } + if + } + if + $SubstituteFont + begin + /$sname null def + /$slen 0 def + /$inVMIndex null def + end + } bind def +/isWidthsOnlyFont + { + dup /WidthsOnly known + { pop pop true } + { + dup /FDepVector known + { /FDepVector get { isWidthsOnlyFont dup { exit } if } forall } + { + dup /FDArray known + { /FDArray get { isWidthsOnlyFont dup { exit } if } forall } + { pop } + ifelse + } + ifelse + } + ifelse + } bind def +/?str1 256 string def +/?set + { + $SubstituteFont + begin + /$substituteFound false def + /$fontname 4 index def + /$doSmartSub false def + end + 3 index + currentglobal false setglobal exch + /CompatibleFonts /ProcSet resourcestatus + { + pop pop + /CompatibleFonts /ProcSet findresource + begin + dup /CompatibleFont currentexception + 1 index /CompatibleFont true setexception + 1 index /Font resourcestatus + { + pop pop + 3 2 roll setglobal + end + exch + dup findfont + /CompatibleFonts /ProcSet findresource + begin + 3 1 roll exch /CompatibleFont exch setexception + end + } + { + 3 2 roll setglobal + 1 index exch /CompatibleFont exch setexception + end + findfont + $SubstituteFont /$substituteFound true put + } + ifelse + } + { exch setglobal findfont } + ifelse + $SubstituteFont + begin + $substituteFound + { + false + (%%[Using embedded font ) print + 5 index ?str1 cvs print + ( to avoid the font substitution problem noted earlier.]%%\n) print + } + { + dup /FontName known + { + dup /FontName get $fontname eq + 1 index /DistillerFauxFont known not and + /currentdistillerparams where + { pop false 2 index isWidthsOnlyFont not and } + if + } + { false } + ifelse + } + ifelse + exch pop + /$doSmartSub true def + end + { + exch pop exch pop exch + 2 dict dup /Found 3 index put + exch findfont exch + } + { + exch exec + exch dup findfont + dup /FontType get 3 eq + { + exch ?str1 cvs + dup length 1 sub + -1 0 + { + exch dup 2 index get 42 eq + { + exch 0 exch getinterval cvn 4 1 roll 3 2 roll pop + exit + } + {exch pop} ifelse + }for + } + { + exch pop + } ifelse + 2 dict dup /Downloaded 6 5 roll put + } + ifelse + dup /FontName 4 index put copyfont definefont pop + } bind def +/?str2 256 string def +/?add + { + 1 index type /integertype eq + { exch true 4 2 } + { false 3 1 } + ifelse + roll + 1 index findfont + dup /Widths known + { + Adobe_CoolType_Data /AddWidths? true put + gsave dup 1000 scalefont setfont + } + if + /Downloaded known + { + exec + exch + { + exch ?str2 cvs exch + findfont /Downloaded get 1 dict begin /Downloaded 1 index def ?str1 cvs length + ?str1 1 index 1 add 3 index putinterval + exch length 1 add 1 index add + ?str1 2 index (*) putinterval + ?str1 0 2 index getinterval cvn findfont + ?str1 3 index (+) putinterval + 2 dict dup /FontName ?str1 0 6 index getinterval cvn put + dup /Downloaded Downloaded put end copyfont + dup /FontName get exch definefont pop pop pop + } + { + pop + } + ifelse + } + { + pop + exch + { + findfont + dup /Found get + dup length exch ?str1 cvs pop + ?str1 1 index (+) putinterval + ?str1 1 index 1 add 4 index ?str2 cvs putinterval + ?str1 exch 0 exch 5 4 roll ?str2 cvs length 1 add add getinterval cvn + 1 dict exch 1 index exch /FontName exch put copyfont + dup /FontName get exch definefont pop + } + { + pop + } + ifelse + } + ifelse + Adobe_CoolType_Data /AddWidths? get + { grestore Adobe_CoolType_Data /AddWidths? false put } + if + } bind def +/?sh + { + currentfont /Downloaded known { exch } if pop + } bind def +/?chp + { + currentfont /Downloaded known { pop } { false chp } ifelse + } bind def +/?mv + { + currentfont /Downloaded known { moveto pop pop } { pop pop moveto } ifelse + } bind def +setpacking +userdict /$SubstituteFont 25 dict put +1 dict + begin + /SubstituteFont + dup $error exch 2 copy known + { get } + { pop pop { pop /Courier } bind } + ifelse def + /currentdistillerparams where dup + { + pop pop + currentdistillerparams /CannotEmbedFontPolicy 2 copy known + { get /Error eq } + { pop pop false } + ifelse + } + if not + { + countdictstack array dictstack 0 get + begin + userdict + begin + $SubstituteFont + begin + /$str 128 string def + /$fontpat 128 string def + /$slen 0 def + /$sname null def + /$match false def + /$fontname null def + /$substituteFound false def + /$inVMIndex null def + /$doSmartSub true def + /$depth 0 def + /$fontname null def + /$italicangle 26.5 def + /$dstack null def + /$Strategies 10 dict dup + begin + /$Type3Underprint + { + currentglobal exch false setglobal + 11 dict + begin + /UseFont exch + $WMode 0 ne + { + dup length dict copy + dup /WMode $WMode put + /UseFont exch definefont + } + if def + /FontName $fontname dup type /stringtype eq { cvn } if def + /FontType 3 def + /FontMatrix [ .001 0 0 .001 0 0 ] def + /Encoding 256 array dup 0 1 255 { /.notdef put dup } for pop def + /FontBBox [ 0 0 0 0 ] def + /CCInfo 7 dict dup + begin + /cc null def + /x 0 def + /y 0 def + end def + /BuildChar + { + exch + begin + CCInfo + begin + 1 string dup 0 3 index put exch pop + /cc exch def + UseFont 1000 scalefont setfont + cc stringwidth /y exch def /x exch def + x y setcharwidth + $SubstituteFont /$Strategy get /$Underprint get exec + 0 0 moveto cc show + x y moveto + end + end + } bind def + currentdict + end + exch setglobal + } bind def + /$GetaTint + 2 dict dup + begin + /$BuildFont + { + dup /WMode known + { dup /WMode get } + { 0 } + ifelse + /$WMode exch def + $fontname exch + dup /FontName known + { + dup /FontName get + dup type /stringtype eq { cvn } if + } + { /unnamedfont } + ifelse + exch + Adobe_CoolType_Data /InVMDeepCopiedFonts get + 1 index /FontName get known + { + pop + Adobe_CoolType_Data /InVMDeepCopiedFonts get + 1 index get + null copyfont + } + { $deepcopyfont } + ifelse + exch 1 index exch /FontBasedOn exch put + dup /FontName $fontname dup type /stringtype eq { cvn } if put + definefont + Adobe_CoolType_Data /InVMDeepCopiedFonts get + begin + dup /FontBasedOn get 1 index def + end + } bind def + /$Underprint + { + gsave + x abs y abs gt + { /y 1000 def } + { /x -1000 def 500 120 translate } + ifelse + Level2? + { + [ /Separation (All) /DeviceCMYK { 0 0 0 1 pop } ] + setcolorspace + } + { 0 setgray } + ifelse + 10 setlinewidth + x .8 mul + [ 7 3 ] + { + y mul 8 div 120 sub x 10 div exch moveto + 0 y 4 div neg rlineto + dup 0 rlineto + 0 y 4 div rlineto + closepath + gsave + Level2? + { .2 setcolor } + { .8 setgray } + ifelse + fill grestore + stroke + } + forall + pop + grestore + } bind def + end def + /$Oblique + 1 dict dup + begin + /$BuildFont + { + currentglobal exch dup gcheck setglobal + null copyfont + begin + /FontBasedOn + currentdict /FontName known + { + FontName + dup type /stringtype eq { cvn } if + } + { /unnamedfont } + ifelse + def + /FontName $fontname dup type /stringtype eq { cvn } if def + /currentdistillerparams where + { pop } + { + /FontInfo currentdict /FontInfo known + { FontInfo null copyfont } + { 2 dict } + ifelse + dup + begin + /ItalicAngle $italicangle def + /FontMatrix FontMatrix + [ 1 0 ItalicAngle dup sin exch cos div 1 0 0 ] + matrix concatmatrix readonly + end + 4 2 roll def + def + } + ifelse + FontName currentdict + end + definefont + exch setglobal + } bind def + end def + /$None + 1 dict dup + begin + /$BuildFont {} bind def + end def + end def + /$Oblique SetSubstituteStrategy + /$findfontByEnum + { + dup type /stringtype eq { cvn } if + dup /$fontname exch def + $sname null eq + { $str cvs dup length $slen sub $slen getinterval } + { pop $sname } + ifelse + $fontpat dup 0 (fonts/*) putinterval exch 7 exch putinterval + /$match false def + $SubstituteFont /$dstack countdictstack array dictstack put + mark + { + $fontpat 0 $slen 7 add getinterval + { /$match exch def exit } + $str filenameforall + } + stopped + { + cleardictstack + currentdict + true + $SubstituteFont /$dstack get + { + exch + { + 1 index eq + { pop false } + { true } + ifelse + } + { begin false } + ifelse + } + forall + pop + } + if + cleartomark + /$slen 0 def + $match false ne + { $match (fonts/) anchorsearch pop pop cvn } + { /Courier } + ifelse + } bind def + /$ROS 1 dict dup + begin + /Adobe 4 dict dup + begin + /Japan1 [ /Ryumin-Light /HeiseiMin-W3 + /GothicBBB-Medium /HeiseiKakuGo-W5 + /HeiseiMaruGo-W4 /Jun101-Light ] def + /Korea1 [ /HYSMyeongJo-Medium /HYGoThic-Medium ] def + /GB1 [ /STSong-Light /STHeiti-Regular ] def + /CNS1 [ /MKai-Medium /MHei-Medium ] def + end def + end def + /$cmapname null def + /$deepcopyfont + { + dup /FontType get 0 eq + { + 1 dict dup /FontName /copied put copyfont + begin + /FDepVector FDepVector copyarray + 0 1 2 index length 1 sub + { + 2 copy get $deepcopyfont + dup /FontName /copied put + /copied exch definefont + 3 copy put pop pop + } + for + def + currentdict + end + } + { $Strategies /$Type3Underprint get exec } + ifelse + } bind def + /$buildfontname + { + dup /CIDFont findresource /CIDSystemInfo get + begin + Registry length Ordering length Supplement 8 string cvs + 3 copy length 2 add add add string + dup 5 1 roll dup 0 Registry putinterval + dup 4 index (-) putinterval + dup 4 index 1 add Ordering putinterval + 4 2 roll add 1 add 2 copy (-) putinterval + end + 1 add 2 copy 0 exch getinterval $cmapname $fontpat cvs exch + anchorsearch + { pop pop 3 2 roll putinterval cvn /$cmapname exch def } + { pop pop pop pop pop } + ifelse + length + $str 1 index (-) putinterval 1 add + $str 1 index $cmapname $fontpat cvs putinterval + $cmapname length add + $str exch 0 exch getinterval cvn + } bind def + /$findfontByROS + { + /$fontname exch def + $ROS Registry 2 copy known + { + get Ordering 2 copy known + { get } + { pop pop [] } + ifelse + } + { pop pop [] } + ifelse + false exch + { + dup /CIDFont resourcestatus + { + pop pop + save + 1 index /CIDFont findresource + dup /WidthsOnly known + { dup /WidthsOnly get } + { false } + ifelse + exch pop + exch restore + { pop } + { exch pop true exit } + ifelse + } + { pop } + ifelse + } + forall + { $str cvs $buildfontname } + { + false (*) + { + save exch + dup /CIDFont findresource + dup /WidthsOnly known + { dup /WidthsOnly get not } + { true } + ifelse + exch /CIDSystemInfo get + dup /Registry get Registry eq + exch /Ordering get Ordering eq and and + { exch restore exch pop true exit } + { pop restore } + ifelse + } + $str /CIDFont resourceforall + { $buildfontname } + { $fontname $findfontByEnum } + ifelse + } + ifelse + } bind def + end + end + currentdict /$error known currentdict /languagelevel known and dup + { pop $error /SubstituteFont known } + if + dup + { $error } + { Adobe_CoolType_Core } + ifelse + begin + { + /SubstituteFont + /CMap /Category resourcestatus + { + pop pop + { + $SubstituteFont + begin + /$substituteFound true def + dup length $slen gt + $sname null ne or + $slen 0 gt and + { + $sname null eq + { dup $str cvs dup length $slen sub $slen getinterval cvn } + { $sname } + ifelse + Adobe_CoolType_Data /InVMFontsByCMap get + 1 index 2 copy known + { + get + false exch + { + pop + currentglobal + { + GlobalFontDirectory 1 index known + { exch pop true exit } + { pop } + ifelse + } + { + FontDirectory 1 index known + { exch pop true exit } + { + GlobalFontDirectory 1 index known + { exch pop true exit } + { pop } + ifelse + } + ifelse + } + ifelse + } + forall + } + { pop pop false } + ifelse + { + exch pop exch pop + } + { + dup /CMap resourcestatus + { + pop pop + dup /$cmapname exch def + /CMap findresource /CIDSystemInfo get { def } forall + $findfontByROS + } + { + 128 string cvs + dup (-) search + { + 3 1 roll search + { + 3 1 roll pop + { dup cvi } + stopped + { pop pop pop pop pop $findfontByEnum } + { + 4 2 roll pop pop + exch length + exch + 2 index length + 2 index + sub + exch 1 sub -1 0 + { + $str cvs dup length + 4 index + 0 + 4 index + 4 3 roll add + getinterval + exch 1 index exch 3 index exch + putinterval + dup /CMap resourcestatus + { + pop pop + 4 1 roll pop pop pop + dup /$cmapname exch def + /CMap findresource /CIDSystemInfo get { def } forall + $findfontByROS + true exit + } + { pop } + ifelse + } + for + dup type /booleantype eq + { pop } + { pop pop pop $findfontByEnum } + ifelse + } + ifelse + } + { pop pop pop $findfontByEnum } + ifelse + } + { pop pop $findfontByEnum } + ifelse + } + ifelse + } + ifelse + } + { //SubstituteFont exec } + ifelse + /$slen 0 def + end + } + } + { + { + $SubstituteFont + begin + /$substituteFound true def + dup length $slen gt + $sname null ne or + $slen 0 gt and + { $findfontByEnum } + { //SubstituteFont exec } + ifelse + end + } + } + ifelse + bind readonly def + Adobe_CoolType_Core /scfindfont /systemfindfont load put + } + { + /scfindfont + { + $SubstituteFont + begin + dup systemfindfont + dup /FontName known + { dup /FontName get dup 3 index ne } + { /noname true } + ifelse + dup + { + /$origfontnamefound 2 index def + /$origfontname 4 index def /$substituteFound true def + } + if + exch pop + { + $slen 0 gt + $sname null ne + 3 index length $slen gt or and + { + pop dup $findfontByEnum findfont + dup maxlength 1 add dict + begin + { 1 index /FID eq { pop pop } { def } ifelse } + forall + currentdict + end + definefont + dup /FontName known { dup /FontName get } { null } ifelse + $origfontnamefound ne + { + $origfontname $str cvs print + ( substitution revised, using ) print + dup /FontName known + { dup /FontName get } { (unspecified font) } + ifelse + $str cvs print (.\n) print + } + if + } + { exch pop } + ifelse + } + { exch pop } + ifelse + end + } bind def + } + ifelse + end + end + Adobe_CoolType_Core_Defined not + { + Adobe_CoolType_Core /findfont + { + $SubstituteFont + begin + $depth 0 eq + { + /$fontname 1 index dup type /stringtype ne { $str cvs } if def + /$substituteFound false def + } + if + /$depth $depth 1 add def + end + scfindfont + $SubstituteFont + begin + /$depth $depth 1 sub def + $substituteFound $depth 0 eq and + { + $inVMIndex null ne + { dup $inVMIndex $AddInVMFont } + if + $doSmartSub + { + currentdict /$Strategy known + { $Strategy /$BuildFont get exec } + if + } + if + } + if + end + } bind put + } + if + } + if + end +/$AddInVMFont + { + exch /FontName 2 copy known + { + get + 1 dict dup begin exch 1 index gcheck def end exch + Adobe_CoolType_Data /InVMFontsByCMap get exch + $DictAdd + } + { pop pop pop } + ifelse + } bind def +/$DictAdd + { + 2 copy known not + { 2 copy 4 index length dict put } + if + Level2? not + { + 2 copy get dup maxlength exch length 4 index length add lt + 2 copy get dup length 4 index length add exch maxlength 1 index lt + { + 2 mul dict + begin + 2 copy get { forall } def + 2 copy currentdict put + end + } + { pop } + ifelse + } + if + get + begin + { def } + forall + end + } bind def +end +end +%%EndResource +%%BeginResource: procset Adobe_CoolType_Utility_MAKEOCF 1.19 0 +%%Copyright: Copyright 1987-2003 Adobe Systems Incorporated. +%%Version: 1.19 0 +systemdict /languagelevel known dup + { currentglobal false setglobal } + { false } +ifelse +exch +userdict /Adobe_CoolType_Utility 2 copy known + { 2 copy get dup maxlength 25 add dict copy } + { 25 dict } +ifelse put +Adobe_CoolType_Utility + begin + /ct_Level2? exch def + /ct_Clone? 1183615869 internaldict dup + /CCRun known not + exch /eCCRun known not + ct_Level2? and or def +ct_Level2? + { globaldict begin currentglobal true setglobal } +if + /ct_AddStdCIDMap + ct_Level2? + { { + ((Hex) 57 StartData + 0615 1e27 2c39 1c60 d8a8 cc31 fe2b f6e0 + 7aa3 e541 e21c 60d8 a8c9 c3d0 6d9e 1c60 + d8a8 c9c2 02d7 9a1c 60d8 a849 1c60 d8a8 + cc36 74f4 1144 b13b 77) 0 () /SubFileDecode filter cvx exec + } } + { { + eexec + } } + ifelse bind def +userdict /cid_extensions known +dup { cid_extensions /cid_UpdateDB known and } if + { + cid_extensions + begin + /cid_GetCIDSystemInfo + { + 1 index type /stringtype eq + { exch cvn exch } + if + cid_extensions + begin + dup load 2 index known + { + 2 copy + cid_GetStatusInfo + dup null ne + { + 1 index load + 3 index get + dup null eq + { pop pop cid_UpdateDB } + { + exch + 1 index /Created get eq + { exch pop exch pop } + { pop cid_UpdateDB } + ifelse + } + ifelse + } + { pop cid_UpdateDB } + ifelse + } + { cid_UpdateDB } + ifelse + end + } bind def + end + } +if +ct_Level2? + { end setglobal } +if + /ct_UseNativeCapability? systemdict /composefont known def + /ct_MakeOCF 35 dict def + /ct_Vars 25 dict def + /ct_GlyphDirProcs 6 dict def + /ct_BuildCharDict 15 dict dup + begin + /charcode 2 string def + /dst_string 1500 string def + /nullstring () def + /usewidths? true def + end def + ct_Level2? { setglobal } { pop } ifelse + ct_GlyphDirProcs + begin + /GetGlyphDirectory + { + systemdict /languagelevel known + { pop /CIDFont findresource /GlyphDirectory get } + { + 1 index /CIDFont findresource /GlyphDirectory + get dup type /dicttype eq + { + dup dup maxlength exch length sub 2 index lt + { + dup length 2 index add dict copy 2 index + /CIDFont findresource/GlyphDirectory 2 index put + } + if + } + if + exch pop exch pop + } + ifelse + + + } def + /+ + { + systemdict /languagelevel known + { + currentglobal false setglobal + 3 dict begin + /vm exch def + } + { 1 dict begin } + ifelse + /$ exch def + systemdict /languagelevel known + { + vm setglobal + /gvm currentglobal def + $ gcheck setglobal + } + if + ? { $ begin } if + } def + /? { $ type /dicttype eq } def + /| { + userdict /Adobe_CoolType_Data known + { + Adobe_CoolType_Data /AddWidths? known + { + currentdict Adobe_CoolType_Data + begin + begin + AddWidths? + { + Adobe_CoolType_Data /CC 3 index put + ? { def } { $ 3 1 roll put } ifelse + CC charcode exch 1 index 0 2 index 256 idiv put + 1 index exch 1 exch 256 mod put + stringwidth 2 array astore + currentfont /Widths get exch CC exch put + } + { ? { def } { $ 3 1 roll put } ifelse } + ifelse + end + end + } + { ? { def } { $ 3 1 roll put } ifelse } ifelse + } + { ? { def } { $ 3 1 roll put } ifelse } + ifelse + } def + /! + { + ? { end } if + systemdict /languagelevel known + { gvm setglobal } + if + end + } def + /: { string currentfile exch readstring pop } executeonly def + end + ct_MakeOCF + begin + /ct_cHexEncoding + [/c00/c01/c02/c03/c04/c05/c06/c07/c08/c09/c0A/c0B/c0C/c0D/c0E/c0F/c10/c11/c12 + /c13/c14/c15/c16/c17/c18/c19/c1A/c1B/c1C/c1D/c1E/c1F/c20/c21/c22/c23/c24/c25 + /c26/c27/c28/c29/c2A/c2B/c2C/c2D/c2E/c2F/c30/c31/c32/c33/c34/c35/c36/c37/c38 + /c39/c3A/c3B/c3C/c3D/c3E/c3F/c40/c41/c42/c43/c44/c45/c46/c47/c48/c49/c4A/c4B + /c4C/c4D/c4E/c4F/c50/c51/c52/c53/c54/c55/c56/c57/c58/c59/c5A/c5B/c5C/c5D/c5E + /c5F/c60/c61/c62/c63/c64/c65/c66/c67/c68/c69/c6A/c6B/c6C/c6D/c6E/c6F/c70/c71 + /c72/c73/c74/c75/c76/c77/c78/c79/c7A/c7B/c7C/c7D/c7E/c7F/c80/c81/c82/c83/c84 + /c85/c86/c87/c88/c89/c8A/c8B/c8C/c8D/c8E/c8F/c90/c91/c92/c93/c94/c95/c96/c97 + /c98/c99/c9A/c9B/c9C/c9D/c9E/c9F/cA0/cA1/cA2/cA3/cA4/cA5/cA6/cA7/cA8/cA9/cAA + /cAB/cAC/cAD/cAE/cAF/cB0/cB1/cB2/cB3/cB4/cB5/cB6/cB7/cB8/cB9/cBA/cBB/cBC/cBD + /cBE/cBF/cC0/cC1/cC2/cC3/cC4/cC5/cC6/cC7/cC8/cC9/cCA/cCB/cCC/cCD/cCE/cCF/cD0 + /cD1/cD2/cD3/cD4/cD5/cD6/cD7/cD8/cD9/cDA/cDB/cDC/cDD/cDE/cDF/cE0/cE1/cE2/cE3 + /cE4/cE5/cE6/cE7/cE8/cE9/cEA/cEB/cEC/cED/cEE/cEF/cF0/cF1/cF2/cF3/cF4/cF5/cF6 + /cF7/cF8/cF9/cFA/cFB/cFC/cFD/cFE/cFF] def + /ct_CID_STR_SIZE 8000 def + /ct_mkocfStr100 100 string def + /ct_defaultFontMtx [.001 0 0 .001 0 0] def + /ct_1000Mtx [1000 0 0 1000 0 0] def + /ct_raise {exch cvx exch errordict exch get exec stop} bind def + /ct_reraise + { cvx $error /errorname get (Error: ) print dup ( ) cvs print + errordict exch get exec stop + } bind def + /ct_cvnsi + { + 1 index add 1 sub 1 exch 0 4 1 roll + { + 2 index exch get + exch 8 bitshift + add + } + for + exch pop + } bind def + /ct_GetInterval + { + Adobe_CoolType_Utility /ct_BuildCharDict get + begin + /dst_index 0 def + dup dst_string length gt + { dup string /dst_string exch def } + if + 1 index ct_CID_STR_SIZE idiv + /arrayIndex exch def + 2 index arrayIndex get + 2 index + arrayIndex ct_CID_STR_SIZE mul + sub + { + dup 3 index add 2 index length le + { + 2 index getinterval + dst_string dst_index 2 index putinterval + length dst_index add /dst_index exch def + exit + } + { + 1 index length 1 index sub + dup 4 1 roll + getinterval + dst_string dst_index 2 index putinterval + pop dup dst_index add /dst_index exch def + sub + /arrayIndex arrayIndex 1 add def + 2 index dup length arrayIndex gt + { arrayIndex get } + { + pop + exit + } + ifelse + 0 + } + ifelse + } + loop + pop pop pop + dst_string 0 dst_index getinterval + end + } bind def + ct_Level2? + { + /ct_resourcestatus + currentglobal mark true setglobal + { /unknowninstancename /Category resourcestatus } + stopped + { cleartomark setglobal true } + { cleartomark currentglobal not exch setglobal } + ifelse + { + { + mark 3 1 roll /Category findresource + begin + ct_Vars /vm currentglobal put + ({ResourceStatus} stopped) 0 () /SubFileDecode filter cvx exec + { cleartomark false } + { { 3 2 roll pop true } { cleartomark false } ifelse } + ifelse + ct_Vars /vm get setglobal + end + } + } + { { resourcestatus } } + ifelse bind def + /CIDFont /Category ct_resourcestatus + { pop pop } + { + currentglobal true setglobal + /Generic /Category findresource + dup length dict copy + dup /InstanceType /dicttype put + /CIDFont exch /Category defineresource pop + setglobal + } + ifelse + ct_UseNativeCapability? + { + /CIDInit /ProcSet findresource begin + 12 dict begin + begincmap + /CIDSystemInfo 3 dict dup begin + /Registry (Adobe) def + /Ordering (Identity) def + /Supplement 0 def + end def + /CMapName /Identity-H def + /CMapVersion 1.000 def + /CMapType 1 def + 1 begincodespacerange + <0000> + endcodespacerange + 1 begincidrange + <0000> 0 + endcidrange + endcmap + CMapName currentdict /CMap defineresource pop + end + end + } + if + } + { + /ct_Category 2 dict begin + /CIDFont 10 dict def + /ProcSet 2 dict def + currentdict + end + def + /defineresource + { + ct_Category 1 index 2 copy known + { + get + dup dup maxlength exch length eq + { + dup length 10 add dict copy + ct_Category 2 index 2 index put + } + if + 3 index 3 index put + pop exch pop + } + { pop pop /defineresource /undefined ct_raise } + ifelse + } bind def + /findresource + { + ct_Category 1 index 2 copy known + { + get + 2 index 2 copy known + { get 3 1 roll pop pop} + { pop pop /findresource /undefinedresource ct_raise } + ifelse + } + { pop pop /findresource /undefined ct_raise } + ifelse + } bind def + /resourcestatus + { + ct_Category 1 index 2 copy known + { + get + 2 index known + exch pop exch pop + { + 0 -1 true + } + { + false + } + ifelse + } + { pop pop /findresource /undefined ct_raise } + ifelse + } bind def + /ct_resourcestatus /resourcestatus load def + } + ifelse + /ct_CIDInit 2 dict + begin + /ct_cidfont_stream_init + { + { + dup (Binary) eq + { + pop + null + currentfile + ct_Level2? + { + { cid_BYTE_COUNT () /SubFileDecode filter } + stopped + { pop pop pop } + if + } + if + /readstring load + exit + } + if + dup (Hex) eq + { + pop + currentfile + ct_Level2? + { + { null exch /ASCIIHexDecode filter /readstring } + stopped + { pop exch pop (>) exch /readhexstring } + if + } + { (>) exch /readhexstring } + ifelse + load + exit + } + if + /StartData /typecheck ct_raise + } + loop + cid_BYTE_COUNT ct_CID_STR_SIZE le + { + 2 copy cid_BYTE_COUNT string exch exec + pop + 1 array dup + 3 -1 roll + 0 exch put + } + { + cid_BYTE_COUNT ct_CID_STR_SIZE div ceiling cvi + dup array exch 2 sub 0 exch 1 exch + { + 2 copy + 5 index + ct_CID_STR_SIZE + string + 6 index exec + pop + put + pop + } + for + 2 index + cid_BYTE_COUNT ct_CID_STR_SIZE mod string + 3 index exec + pop + 1 index exch + 1 index length 1 sub + exch put + } + ifelse + cid_CIDFONT exch /GlyphData exch put + 2 index null eq + { + pop pop pop + } + { + pop /readstring load + 1 string exch + { + 3 copy exec + pop + dup length 0 eq + { + pop pop pop pop pop + true exit + } + if + 4 index + eq + { + pop pop pop pop + false exit + } + if + } + loop + pop + } + ifelse + } bind def + /StartData + { + mark + { + currentdict + dup /FDArray get 0 get /FontMatrix get + 0 get 0.001 eq + { + dup /CDevProc known not + { + /CDevProc 1183615869 internaldict /stdCDevProc 2 copy known + { get } + { + pop pop + { pop pop pop pop pop 0 -1000 7 index 2 div 880 } + } + ifelse + def + } + if + } + { + /CDevProc + { + pop pop pop pop pop + 0 + 1 cid_temp /cid_CIDFONT get + /FDArray get 0 get + /FontMatrix get 0 get div + 7 index 2 div + 1 index 0.88 mul + } def + } + ifelse + /cid_temp 15 dict def + cid_temp + begin + /cid_CIDFONT exch def + 3 copy pop + dup /cid_BYTE_COUNT exch def 0 gt + { + ct_cidfont_stream_init + FDArray + { + /Private get + dup /SubrMapOffset known + { + begin + /Subrs SubrCount array def + Subrs + SubrMapOffset + SubrCount + SDBytes + ct_Level2? + { + currentdict dup /SubrMapOffset undef + dup /SubrCount undef + /SDBytes undef + } + if + end + /cid_SD_BYTES exch def + /cid_SUBR_COUNT exch def + /cid_SUBR_MAP_OFFSET exch def + /cid_SUBRS exch def + cid_SUBR_COUNT 0 gt + { + GlyphData cid_SUBR_MAP_OFFSET cid_SD_BYTES ct_GetInterval + 0 cid_SD_BYTES ct_cvnsi + 0 1 cid_SUBR_COUNT 1 sub + { + exch 1 index + 1 add + cid_SD_BYTES mul cid_SUBR_MAP_OFFSET add + GlyphData exch cid_SD_BYTES ct_GetInterval + 0 cid_SD_BYTES ct_cvnsi + cid_SUBRS 4 2 roll + GlyphData exch + 4 index + 1 index + sub + ct_GetInterval + dup length string copy put + } + for + pop + } + if + } + { pop } + ifelse + } + forall + } + if + cleartomark pop pop + end + CIDFontName currentdict /CIDFont defineresource pop + end end + } + stopped + { cleartomark /StartData ct_reraise } + if + } bind def + currentdict + end def + /ct_saveCIDInit + { + /CIDInit /ProcSet ct_resourcestatus + { true } + { /CIDInitC /ProcSet ct_resourcestatus } + ifelse + { + pop pop + /CIDInit /ProcSet findresource + ct_UseNativeCapability? + { pop null } + { /CIDInit ct_CIDInit /ProcSet defineresource pop } + ifelse + } + { /CIDInit ct_CIDInit /ProcSet defineresource pop null } + ifelse + ct_Vars exch /ct_oldCIDInit exch put + } bind def + /ct_restoreCIDInit + { + ct_Vars /ct_oldCIDInit get dup null ne + { /CIDInit exch /ProcSet defineresource pop } + { pop } + ifelse + } bind def + /ct_BuildCharSetUp + { + 1 index + begin + CIDFont + begin + Adobe_CoolType_Utility /ct_BuildCharDict get + begin + /ct_dfCharCode exch def + /ct_dfDict exch def + CIDFirstByte ct_dfCharCode add + dup CIDCount ge + { pop 0 } + if + /cid exch def + { + GlyphDirectory cid 2 copy known + { get } + { pop pop nullstring } + ifelse + dup length FDBytes sub 0 gt + { + dup + FDBytes 0 ne + { 0 FDBytes ct_cvnsi } + { pop 0 } + ifelse + /fdIndex exch def + dup length FDBytes sub FDBytes exch getinterval + /charstring exch def + exit + } + { + pop + cid 0 eq + { /charstring nullstring def exit } + if + /cid 0 def + } + ifelse + } + loop + } def + /ct_SetCacheDevice + { + 0 0 moveto + dup stringwidth + 3 -1 roll + true charpath + pathbbox + 0 -1000 + 7 index 2 div 880 + setcachedevice2 + 0 0 moveto + } def + /ct_CloneSetCacheProc + { + 1 eq + { + stringwidth + pop -2 div -880 + 0 -1000 setcharwidth + moveto + } + { + usewidths? + { + currentfont /Widths get cid + 2 copy known + { get exch pop aload pop } + { pop pop stringwidth } + ifelse + } + { stringwidth } + ifelse + setcharwidth + 0 0 moveto + } + ifelse + } def + /ct_Type3ShowCharString + { + ct_FDDict fdIndex 2 copy known + { get } + { + currentglobal 3 1 roll + 1 index gcheck setglobal + ct_Type1FontTemplate dup maxlength dict copy + begin + FDArray fdIndex get + dup /FontMatrix 2 copy known + { get } + { pop pop ct_defaultFontMtx } + ifelse + /FontMatrix exch dup length array copy def + /Private get + /Private exch def + /Widths rootfont /Widths get def + /CharStrings 1 dict dup /.notdef + dup length string copy put def + currentdict + end + /ct_Type1Font exch definefont + dup 5 1 roll put + setglobal + } + ifelse + dup /CharStrings get 1 index /Encoding get + ct_dfCharCode get charstring put + rootfont /WMode 2 copy known + { get } + { pop pop 0 } + ifelse + exch + 1000 scalefont setfont + ct_str1 0 ct_dfCharCode put + ct_str1 exch ct_dfSetCacheProc + ct_SyntheticBold + { + currentpoint + ct_str1 show + newpath + moveto + ct_str1 true charpath + ct_StrokeWidth setlinewidth + stroke + } + { ct_str1 show } + ifelse + } def + /ct_Type4ShowCharString + { + ct_dfDict ct_dfCharCode charstring + FDArray fdIndex get + dup /FontMatrix get dup ct_defaultFontMtx ct_matrixeq not + { ct_1000Mtx matrix concatmatrix concat } + { pop } + ifelse + /Private get + Adobe_CoolType_Utility /ct_Level2? get not + { + ct_dfDict /Private + 3 -1 roll + { put } + 1183615869 internaldict /superexec get exec + } + if + 1183615869 internaldict + Adobe_CoolType_Utility /ct_Level2? get + { 1 index } + { 3 index /Private get mark 6 1 roll } + ifelse + dup /RunInt known + { /RunInt get } + { pop /CCRun } + ifelse + get exec + Adobe_CoolType_Utility /ct_Level2? get not + { cleartomark } + if + } bind def + /ct_BuildCharIncremental + { + { + Adobe_CoolType_Utility /ct_MakeOCF get begin + ct_BuildCharSetUp + ct_ShowCharString + } + stopped + { stop } + if + end + end + end + end + } bind def + /BaseFontNameStr (BF00) def + /ct_Type1FontTemplate 14 dict + begin + /FontType 1 def + /FontMatrix [0.001 0 0 0.001 0 0] def + /FontBBox [-250 -250 1250 1250] def + /Encoding ct_cHexEncoding def + /PaintType 0 def + currentdict + end def + /BaseFontTemplate 11 dict + begin + /FontMatrix [0.001 0 0 0.001 0 0] def + /FontBBox [-250 -250 1250 1250] def + /Encoding ct_cHexEncoding def + /BuildChar /ct_BuildCharIncremental load def + ct_Clone? + { + /FontType 3 def + /ct_ShowCharString /ct_Type3ShowCharString load def + /ct_dfSetCacheProc /ct_CloneSetCacheProc load def + /ct_SyntheticBold false def + /ct_StrokeWidth 1 def + } + { + /FontType 4 def + /Private 1 dict dup /lenIV 4 put def + /CharStrings 1 dict dup /.notdef put def + /PaintType 0 def + /ct_ShowCharString /ct_Type4ShowCharString load def + } + ifelse + /ct_str1 1 string def + currentdict + end def + /BaseFontDictSize BaseFontTemplate length 5 add def + /ct_matrixeq + { + true 0 1 5 + { + dup 4 index exch get exch 3 index exch get eq and + dup not + { exit } + if + } + for + exch pop exch pop + } bind def + /ct_makeocf + { + 15 dict + begin + exch /WMode exch def + exch /FontName exch def + /FontType 0 def + /FMapType 2 def + dup /FontMatrix known + { dup /FontMatrix get /FontMatrix exch def } + { /FontMatrix matrix def } + ifelse + /bfCount 1 index /CIDCount get 256 idiv 1 add + dup 256 gt { pop 256} if def + /Encoding + 256 array 0 1 bfCount 1 sub { 2 copy dup put pop } for + bfCount 1 255 { 2 copy bfCount put pop } for + def + /FDepVector bfCount dup 256 lt { 1 add } if array def + BaseFontTemplate BaseFontDictSize dict copy + begin + /CIDFont exch def + CIDFont /FontBBox known + { CIDFont /FontBBox get /FontBBox exch def } + if + CIDFont /CDevProc known + { CIDFont /CDevProc get /CDevProc exch def } + if + currentdict + end + BaseFontNameStr 3 (0) putinterval + 0 1 bfCount dup 256 eq { 1 sub } if + { + FDepVector exch + 2 index BaseFontDictSize dict copy + begin + dup /CIDFirstByte exch 256 mul def + FontType 3 eq + { /ct_FDDict 2 dict def } + if + currentdict + end + 1 index 16 + BaseFontNameStr 2 2 getinterval cvrs pop + BaseFontNameStr exch definefont + put + } + for + ct_Clone? + { /Widths 1 index /CIDFont get /GlyphDirectory get length dict def } + if + FontName + currentdict + end + definefont + ct_Clone? + { + gsave + dup 1000 scalefont setfont + ct_BuildCharDict + begin + /usewidths? false def + currentfont /Widths get + begin + exch /CIDFont get /GlyphDirectory get + { + pop + dup charcode exch 1 index 0 2 index 256 idiv put + 1 index exch 1 exch 256 mod put + stringwidth 2 array astore def + } + forall + end + /usewidths? true def + end + grestore + } + { exch pop } + ifelse + } bind def + /ct_ComposeFont + { + ct_UseNativeCapability? + { + 2 index /CMap ct_resourcestatus + { pop pop exch pop } + { + /CIDInit /ProcSet findresource + begin + 12 dict + begin + begincmap + /CMapName 3 index def + /CMapVersion 1.000 def + /CMapType 1 def + exch /WMode exch def + /CIDSystemInfo 3 dict dup + begin + /Registry (Adobe) def + /Ordering + CMapName ct_mkocfStr100 cvs + (Adobe-) search + { + pop pop + (-) search + { + dup length string copy + exch pop exch pop + } + { pop (Identity)} + ifelse + } + { pop (Identity) } + ifelse + def + /Supplement 0 def + end def + 1 begincodespacerange + <0000> + endcodespacerange + 1 begincidrange + <0000> 0 + endcidrange + endcmap + CMapName currentdict /CMap defineresource pop + end + end + } + ifelse + composefont + } + { + 3 2 roll pop + 0 get /CIDFont findresource + ct_makeocf + } + ifelse + } bind def + /ct_MakeIdentity + { + ct_UseNativeCapability? + { + 1 index /CMap ct_resourcestatus + { pop pop } + { + /CIDInit /ProcSet findresource begin + 12 dict begin + begincmap + /CMapName 2 index def + /CMapVersion 1.000 def + /CMapType 1 def + /CIDSystemInfo 3 dict dup + begin + /Registry (Adobe) def + /Ordering + CMapName ct_mkocfStr100 cvs + (Adobe-) search + { + pop pop + (-) search + { dup length string copy exch pop exch pop } + { pop (Identity) } + ifelse + } + { pop (Identity) } + ifelse + def + /Supplement 0 def + end def + 1 begincodespacerange + <0000> + endcodespacerange + 1 begincidrange + <0000> 0 + endcidrange + endcmap + CMapName currentdict /CMap defineresource pop + end + end + } + ifelse + composefont + } + { + exch pop + 0 get /CIDFont findresource + ct_makeocf + } + ifelse + } bind def + currentdict readonly pop + end + end +%%EndResource +%%BeginResource: procset Adobe_CoolType_Utility_T42 1.0 0 +%%Copyright: Copyright 1987-2003 Adobe Systems Incorporated. +%%Version: 1.0 0 +userdict /ct_T42Dict 15 dict put +ct_T42Dict begin +/Is2015? +{ + version + cvi + 2015 + ge +} bind def +/AllocGlyphStorage +{ + Is2015? + { + pop + } + { + {string} forall + } ifelse +} bind def +/Type42DictBegin +{ + 25 dict begin + /FontName exch def + /CharStrings 256 dict + begin + /.notdef 0 def + currentdict + end def + /Encoding exch def + /PaintType 0 def + /FontType 42 def + /FontMatrix [1 0 0 1 0 0] def + 4 array astore cvx /FontBBox exch def + /sfnts +} bind def +/Type42DictEnd +{ + currentdict dup /FontName get exch definefont end + ct_T42Dict exch + dup /FontName get exch put +} bind def +/RD {string currentfile exch readstring pop} executeonly def +/PrepFor2015 +{ + Is2015? + { + /GlyphDirectory + 16 + dict def + sfnts 0 get + dup + 2 index + (glyx) + putinterval + 2 index + (locx) + putinterval + pop + pop + } + { + pop + pop + } ifelse +} bind def +/AddT42Char +{ + Is2015? + { + /GlyphDirectory get + begin + def + end + pop + pop + } + { + /sfnts get + 4 index + get + 3 index + 2 index + putinterval + pop + pop + pop + pop + } ifelse +} bind def +end +%%EndResource +Adobe_CoolType_Core begin /$Oblique SetSubstituteStrategy end +%%BeginResource: procset Adobe_AGM_Image 1.0 0 +%%Version: 1.0 0 +%%Copyright: Copyright (C) 2000-2003 Adobe Systems, Inc. All Rights Reserved. +systemdict /setpacking known +{ + currentpacking + true setpacking +} if +userdict /Adobe_AGM_Image 75 dict dup begin put +/Adobe_AGM_Image_Id /Adobe_AGM_Image_1.0_0 def +/nd{ + null def +}bind def +/AGMIMG_&image nd +/AGMIMG_&colorimage nd +/AGMIMG_&imagemask nd +/AGMIMG_mbuf () def +/AGMIMG_ybuf () def +/AGMIMG_kbuf () def +/AGMIMG_c 0 def +/AGMIMG_m 0 def +/AGMIMG_y 0 def +/AGMIMG_k 0 def +/AGMIMG_tmp nd +/AGMIMG_imagestring0 nd +/AGMIMG_imagestring1 nd +/AGMIMG_imagestring2 nd +/AGMIMG_imagestring3 nd +/AGMIMG_imagestring4 nd +/AGMIMG_imagestring5 nd +/AGMIMG_cnt nd +/AGMIMG_fsave nd +/AGMIMG_colorAry nd +/AGMIMG_override nd +/AGMIMG_name nd +/AGMIMG_maskSource nd +/invert_image_samples nd +/knockout_image_samples nd +/img nd +/sepimg nd +/devnimg nd +/idximg nd +/doc_setup +{ + Adobe_AGM_Core begin + Adobe_AGM_Image begin + /AGMIMG_&image systemdict/image get def + /AGMIMG_&imagemask systemdict/imagemask get def + /colorimage where{ + pop + /AGMIMG_&colorimage /colorimage ldf + }if + end + end +}def +/page_setup +{ + Adobe_AGM_Image begin + /AGMIMG_ccimage_exists {/customcolorimage where + { + pop + /Adobe_AGM_OnHost_Seps where + { + pop false + }{ + /Adobe_AGM_InRip_Seps where + { + pop false + }{ + true + }ifelse + }ifelse + }{ + false + }ifelse + }bdf + level2{ + /invert_image_samples + { + Adobe_AGM_Image/AGMIMG_tmp Decode length ddf + /Decode [ Decode 1 get Decode 0 get] def + }def + /knockout_image_samples + { + Operator/imagemask ne{ + /Decode [1 1] def + }if + }def + }{ + /invert_image_samples + { + {1 exch sub} currenttransfer addprocs settransfer + }def + /knockout_image_samples + { + { pop 1 } currenttransfer addprocs settransfer + }def + }ifelse + /img /imageormask ldf + /sepimg /sep_imageormask ldf + /devnimg /devn_imageormask ldf + /idximg /indexed_imageormask ldf + /_ctype 7 def + currentdict{ + dup xcheck 1 index type dup /arraytype eq exch /packedarraytype eq or and{ + bind + }if + def + }forall +}def +/page_trailer +{ + end +}def +/doc_trailer +{ +}def +/imageormask_sys +{ + begin + save mark + level2{ + currentdict + Operator /imagemask eq{ + AGMIMG_&imagemask + }{ + use_mask { + level3 {process_mask_L3 AGMIMG_&image}{masked_image_simulation}ifelse + }{ + AGMIMG_&image + }ifelse + }ifelse + }{ + Width Height + Operator /imagemask eq{ + Decode 0 get 1 eq Decode 1 get 0 eq and + ImageMatrix /DataSource load + AGMIMG_&imagemask + }{ + BitsPerComponent ImageMatrix /DataSource load + AGMIMG_&image + }ifelse + }ifelse + cleartomark restore + end +}def +/overprint_plate +{ + currentoverprint { + 0 get dup type /nametype eq { + dup /DeviceGray eq{ + pop AGMCORE_black_plate not + }{ + /DeviceCMYK eq{ + AGMCORE_is_cmyk_sep not + }if + }ifelse + }{ + false exch + { + AGMOHS_sepink eq or + } forall + not + } ifelse + }{ + pop false + }ifelse +}def +/process_mask_L3 +{ + dup begin + /ImageType 1 def + end + 4 dict begin + /DataDict exch def + /ImageType 3 def + /InterleaveType 3 def + /MaskDict 9 dict begin + /ImageType 1 def + /Width DataDict dup /MaskWidth known {/MaskWidth}{/Width} ifelse get def + /Height DataDict dup /MaskHeight known {/MaskHeight}{/Height} ifelse get def + /ImageMatrix [Width 0 0 Height neg 0 Height] def + /NComponents 1 def + /BitsPerComponent 1 def + /Decode [0 1] def + /DataSource AGMIMG_maskSource def + currentdict end def + currentdict end +}def +/use_mask +{ + dup type /dicttype eq + { + dup /Mask known { + dup /Mask get { + level3 + {true} + { + dup /MaskWidth known {dup /MaskWidth get 1 index /Width get eq}{true}ifelse exch + dup /MaskHeight known {dup /MaskHeight get 1 index /Height get eq}{true}ifelse + 3 -1 roll and + } ifelse + } + {false} ifelse + } + {false} ifelse + } + {false} ifelse +}def +/make_line_source +{ + begin + MultipleDataSources { + [ + Decode length 2 div cvi {Width string} repeat + ] + }{ + Width Decode length 2 div mul cvi string + }ifelse + end +}def +/datasource_to_str +{ + exch dup type + dup /filetype eq { + pop exch readstring + }{ + /arraytype eq { + exec exch copy + }{ + pop + }ifelse + }ifelse + pop +}def +/masked_image_simulation +{ + 3 dict begin + dup make_line_source /line_source xdf + /mask_source AGMIMG_maskSource /LZWDecode filter def + dup /Width get 8 div ceiling cvi string /mask_str xdf + begin + gsave + 0 1 translate 1 -1 Height div scale + 1 1 Height { + pop + gsave + MultipleDataSources { + 0 1 DataSource length 1 sub { + dup DataSource exch get + exch line_source exch get + datasource_to_str + } for + }{ + DataSource line_source datasource_to_str + } ifelse + << + /PatternType 1 + /PaintProc [ + /pop cvx + << + /ImageType 1 + /Width Width + /Height 1 + /ImageMatrix Width 1.0 sub 1 matrix scale 0.5 0 matrix translate matrix concatmatrix + /MultipleDataSources MultipleDataSources + /DataSource line_source + /BitsPerComponent BitsPerComponent + /Decode Decode + >> + /image cvx + ] cvx + /BBox [0 0 Width 1] + /XStep Width + /YStep 1 + /PaintType 1 + /TilingType 2 + >> + matrix makepattern set_pattern + << + /ImageType 1 + /Width Width + /Height 1 + /ImageMatrix Width 1 matrix scale + /MultipleDataSources false + /DataSource mask_source mask_str readstring pop + /BitsPerComponent 1 + /Decode [0 1] + >> + imagemask + grestore + 0 1 translate + } for + grestore + end + end +}def +/imageormask +{ + begin + SkipImageProc { + currentdict consumeimagedata + } + { + save mark + level2 AGMCORE_host_sep not and{ + currentdict + Operator /imagemask eq DeviceN_PS2 not and { + imagemask + }{ + AGMCORE_in_rip_sep currentoverprint and currentcolorspace 0 get /DeviceGray eq and{ + [/Separation /Black /DeviceGray {}] setcolorspace + /Decode [ Decode 1 get Decode 0 get ] def + }if + use_mask { + level3 {process_mask_L3 image}{masked_image_simulation}ifelse + }{ + DeviceN_NoneName DeviceN_PS2 Indexed_DeviceN level3 not and or or AGMCORE_in_rip_sep and + { + Names convert_to_process not { + 2 dict begin + /imageDict xdf + /names_index 0 def + gsave + imageDict write_image_file { + Names { + dup (None) ne { + [/Separation 3 -1 roll /DeviceGray {1 exch sub}] setcolorspace + Operator imageDict read_image_file + names_index 0 eq {true setoverprint} if + /names_index names_index 1 add def + }{ + pop + } ifelse + } forall + close_image_file + } if + grestore + end + }{ + Operator /imagemask eq { + imagemask + }{ + image + } ifelse + } ifelse + }{ + Operator /imagemask eq { + imagemask + }{ + image + } ifelse + } ifelse + }ifelse + }ifelse + }{ + Width Height + Operator /imagemask eq{ + Decode 0 get 1 eq Decode 1 get 0 eq and + ImageMatrix /DataSource load + /Adobe_AGM_OnHost_Seps where { + pop imagemask + }{ + currentgray 1 ne{ + currentdict imageormask_sys + }{ + currentoverprint not{ + 1 AGMCORE_&setgray + currentdict imageormask_sys + }{ + currentdict ignoreimagedata + }ifelse + }ifelse + }ifelse + }{ + BitsPerComponent ImageMatrix + MultipleDataSources{ + 0 1 NComponents 1 sub{ + DataSource exch get + }for + }{ + /DataSource load + }ifelse + Operator /colorimage eq{ + AGMCORE_host_sep{ + MultipleDataSources level2 or NComponents 4 eq and{ + AGMCORE_is_cmyk_sep{ + MultipleDataSources{ + /DataSource [ + DataSource 0 get /exec cvx + DataSource 1 get /exec cvx + DataSource 2 get /exec cvx + DataSource 3 get /exec cvx + /AGMCORE_get_ink_data cvx + ] cvx def + }{ + /DataSource + Width BitsPerComponent mul 7 add 8 idiv Height mul 4 mul + /DataSource load + filter_cmyk 0 () /SubFileDecode filter def + }ifelse + /Decode [ Decode 0 get Decode 1 get ] def + /MultipleDataSources false def + /NComponents 1 def + /Operator /image def + invert_image_samples + 1 AGMCORE_&setgray + currentdict imageormask_sys + }{ + currentoverprint not Operator/imagemask eq and{ + 1 AGMCORE_&setgray + currentdict imageormask_sys + }{ + currentdict ignoreimagedata + }ifelse + }ifelse + }{ + MultipleDataSources NComponents AGMIMG_&colorimage + }ifelse + }{ + true NComponents colorimage + }ifelse + }{ + Operator /image eq{ + AGMCORE_host_sep{ + /DoImage true def + HostSepColorImage{ + invert_image_samples + }{ + AGMCORE_black_plate not Operator/imagemask ne and{ + /DoImage false def + currentdict ignoreimagedata + }if + }ifelse + 1 AGMCORE_&setgray + DoImage + {currentdict imageormask_sys} if + }{ + use_mask { + level3 {process_mask_L3 image}{masked_image_simulation}ifelse + }{ + image + }ifelse + }ifelse + }{ + Operator/knockout eq{ + pop pop pop pop pop + currentcolorspace overprint_plate not{ + knockout_unitsq + }if + }if + }ifelse + }ifelse + }ifelse + }ifelse + cleartomark restore + }ifelse + end +}def +/sep_imageormask +{ + /sep_colorspace_dict AGMCORE_gget begin + /MappedCSA CSA map_csa def + begin + SkipImageProc { + currentdict consumeimagedata + } + { + save mark + AGMCORE_avoid_L2_sep_space{ + /Decode [ Decode 0 get 255 mul Decode 1 get 255 mul ] def + }if + AGMIMG_ccimage_exists + MappedCSA 0 get /DeviceCMYK eq and + currentdict/Components known and + Name () ne and + Name (All) ne and + Operator /image eq and + AGMCORE_producing_seps not and + level2 not and + { + Width Height BitsPerComponent ImageMatrix + [ + /DataSource load /exec cvx + { + 0 1 2 index length 1 sub{ + 1 index exch + 2 copy get 255 xor put + }for + } /exec cvx + ] cvx bind + MappedCSA 0 get /DeviceCMYK eq{ + Components aload pop + }{ + 0 0 0 Components aload pop 1 exch sub + }ifelse + Name findcmykcustomcolor + customcolorimage + }{ + AGMCORE_producing_seps not{ + level2{ + AGMCORE_avoid_L2_sep_space not currentcolorspace 0 get /Separation ne and{ + [/Separation Name MappedCSA sep_proc_name exch 0 get exch load ] setcolorspace_opt + /sep_tint AGMCORE_gget setcolor + }if + currentdict imageormask + }{ + currentdict + Operator /imagemask eq{ + imageormask + }{ + sep_imageormask_lev1 + }ifelse + }ifelse + }{ + AGMCORE_host_sep{ + Operator/knockout eq{ + currentdict/ImageMatrix get concat + knockout_unitsq + }{ + currentgray 1 ne{ + AGMCORE_is_cmyk_sep Name (All) ne and{ + level2{ + [ /Separation Name [/DeviceGray] + { + sep_colorspace_proc AGMCORE_get_ink_data + 1 exch sub + } bind + ] AGMCORE_&setcolorspace + /sep_tint AGMCORE_gget AGMCORE_&setcolor + currentdict imageormask_sys + }{ + currentdict + Operator /imagemask eq{ + imageormask_sys + }{ + sep_image_lev1_sep + }ifelse + }ifelse + }{ + Operator/imagemask ne{ + invert_image_samples + }if + currentdict imageormask_sys + }ifelse + }{ + currentoverprint not Name (All) eq or Operator/imagemask eq and{ + currentdict imageormask_sys + }{ + currentoverprint not + { + gsave + knockout_unitsq + grestore + }if + currentdict consumeimagedata + }ifelse + }ifelse + }ifelse + }{ + currentcolorspace 0 get /Separation ne{ + [/Separation Name MappedCSA sep_proc_name exch 0 get exch load ] setcolorspace_opt + /sep_tint AGMCORE_gget setcolor + }if + currentoverprint + MappedCSA 0 get /DeviceCMYK eq and + Name inRip_spot_has_ink not and + Name (All) ne and { + imageormask_l2_overprint + }{ + currentdict imageormask + }ifelse + }ifelse + }ifelse + }ifelse + cleartomark restore + }ifelse + end + end +}def +/decode_image_sample +{ + 4 1 roll exch dup 5 1 roll + sub 2 4 -1 roll exp 1 sub div mul add +} bdf +/colorSpaceElemCnt +{ + currentcolorspace 0 get dup /DeviceCMYK eq { + pop 4 + } + { + /DeviceRGB eq { + pop 3 + }{ + 1 + } ifelse + } ifelse +} bdf +/devn_sep_datasource +{ + 1 dict begin + /dataSource xdf + [ + 0 1 dataSource length 1 sub { + dup currentdict /dataSource get /exch cvx /get cvx /exec cvx + /exch cvx names_index /ne cvx [ /pop cvx ] cvx /if cvx + } for + ] cvx bind + end +} bdf +/devn_alt_datasource +{ + 11 dict begin + /srcDataStrs xdf + /dstDataStr xdf + /convProc xdf + /origcolorSpaceElemCnt xdf + /origMultipleDataSources xdf + /origBitsPerComponent xdf + /origDecode xdf + /origDataSource xdf + /dsCnt origMultipleDataSources {origDataSource length}{1}ifelse def + /samplesNeedDecoding + 0 0 1 origDecode length 1 sub { + origDecode exch get add + } for + origDecode length 2 div div + dup 1 eq { + /decodeDivisor 2 origBitsPerComponent exp 1 sub def + } if + 2 origBitsPerComponent exp 1 sub ne + def + [ + 0 1 dsCnt 1 sub [ + currentdict /origMultipleDataSources get { + dup currentdict /origDataSource get exch get dup type + }{ + currentdict /origDataSource get dup type + } ifelse + dup /filetype eq { + pop currentdict /srcDataStrs get 3 -1 /roll cvx /get cvx /readstring cvx /pop cvx + }{ + /stringtype ne { + /exec cvx + } if + currentdict /srcDataStrs get /exch cvx 3 -1 /roll cvx /xpt cvx + } ifelse + ] cvx /for cvx + currentdict /srcDataStrs get 0 /get cvx /length cvx 0 /ne cvx [ + 0 1 Width 1 sub [ + Adobe_AGM_Utils /AGMUTIL_ndx /xddf cvx + currentdict /origMultipleDataSources get { + 0 1 dsCnt 1 sub [ + Adobe_AGM_Utils /AGMUTIL_ndx1 /xddf cvx + currentdict /srcDataStrs get /AGMUTIL_ndx1 /load cvx /get cvx /AGMUTIL_ndx /load cvx /get cvx + samplesNeedDecoding { + currentdict /decodeDivisor known { + currentdict /decodeDivisor get /div cvx + }{ + currentdict /origDecode get /AGMUTIL_ndx1 /load cvx 2 /mul cvx 2 /getinterval cvx /aload cvx /pop cvxs + BitsPerComponent /decode_image_sample load /exec cvx + } ifelse + } if + ] cvx /for cvx + }{ + Adobe_AGM_Utils /AGMUTIL_ndx1 0 /ddf cvx + currentdict /srcDataStrs get 0 /get cvx /AGMUTIL_ndx /load cvx + currentdict /origDecode get length 2 idiv dup 3 1 /roll cvx /mul cvx /exch cvx /getinterval cvx + [ + samplesNeedDecoding { + currentdict /decodeDivisor known { + currentdict /decodeDivisor get /div cvx + }{ + currentdict /origDecode get /AGMUTIL_ndx1 /load cvx 2 /mul cvx 2 /getinterval cvx /aload cvx /pop cvx + BitsPerComponent /decode_image_sample load /exec cvx + Adobe_AGM_Utils /AGMUTIL_ndx1 /AGMUTIL_ndx1 /load cvx 1 /add cvx /ddf cvx + } ifelse + } if + ] cvx /forall cvx + } ifelse + currentdict /convProc get /exec cvx + currentdict /origcolorSpaceElemCnt get 1 sub -1 0 [ + currentdict /dstDataStr get 3 1 /roll cvx /AGMUTIL_ndx /load cvx currentdict /origcolorSpaceElemCnt get /mul cvx /add cvx /exch cvx + currentdict /convProc get /filter_indexed_devn load ne { + 255 /mul cvx /cvi cvx + } if + /put cvx + ] cvx /for cvx + ] cvx /for cvx + currentdict /dstDataStr get + ] cvx /if cvx + ] cvx bind + end +} bdf +/devn_imageormask +{ + /devicen_colorspace_dict AGMCORE_gget begin + /MappedCSA CSA map_csa def + 2 dict begin + dup dup + /dstDataStr exch /Width get colorSpaceElemCnt mul string def + /srcDataStrs [ 3 -1 roll begin + currentdict /MultipleDataSources known {MultipleDataSources {DataSource length}{1}ifelse}{1} ifelse + { + Width Decode length 2 div mul cvi string + } repeat + end ] def + begin + SkipImageProc { + currentdict consumeimagedata + } + { + save mark + AGMCORE_producing_seps not { + level3 not { + Operator /imagemask ne { + /DataSource [ + DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse + colorSpaceElemCnt /devicen_colorspace_dict AGMCORE_gget /TintTransform get + dstDataStr srcDataStrs devn_alt_datasource /exec cvx + ] cvx 0 () /SubFileDecode filter def + /MultipleDataSources false def + /Decode colorSpaceElemCnt [ exch {0 1} repeat ] def + } if + }if + currentdict imageormask + }{ + AGMCORE_host_sep{ + Names convert_to_process { + CSA map_csa 0 get /DeviceCMYK eq { + /DataSource + Width BitsPerComponent mul 7 add 8 idiv Height mul 4 mul + [ + DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse + 4 /devicen_colorspace_dict AGMCORE_gget /TintTransform get + dstDataStr srcDataStrs devn_alt_datasource /exec cvx + ] cvx + filter_cmyk 0 () /SubFileDecode filter def + /MultipleDataSources false def + /Decode [1 0] def + /DeviceGray setcolorspace + currentdict imageormask_sys + }{ + AGMCORE_report_unsupported_color_space + AGMCORE_black_plate { + /DataSource [ + DataSource Decode BitsPerComponent currentdict /MultipleDataSources known {MultipleDataSources}{false} ifelse + CSA map_csa 0 get /DeviceRGB eq{3}{1}ifelse /devicen_colorspace_dict AGMCORE_gget /TintTransform get + dstDataStr srcDataStrs devn_alt_datasource /exec cvx + ] cvx 0 () /SubFileDecode filter def + /MultipleDataSources false def + /Decode colorSpaceElemCnt [ exch {0 1} repeat ] def + currentdict imageormask_sys + } + { + gsave + knockout_unitsq + grestore + currentdict consumeimagedata + } ifelse + } ifelse + } + { + /devicen_colorspace_dict AGMCORE_gget /names_index known { + Operator/imagemask ne{ + MultipleDataSources { + /DataSource [ DataSource devn_sep_datasource /exec cvx ] cvx def + /MultipleDataSources false def + }{ + /DataSource /DataSource load dstDataStr srcDataStrs 0 get filter_devn def + } ifelse + invert_image_samples + } if + currentdict imageormask_sys + }{ + currentoverprint not Operator/imagemask eq and{ + currentdict imageormask_sys + }{ + currentoverprint not + { + gsave + knockout_unitsq + grestore + }if + currentdict consumeimagedata + }ifelse + }ifelse + }ifelse + }{ + currentdict imageormask + }ifelse + }ifelse + cleartomark restore + }ifelse + end + end + end +}def +/imageormask_l2_overprint +{ + currentdict + currentcmykcolor add add add 0 eq{ + currentdict consumeimagedata + }{ + level3{ + currentcmykcolor + /AGMIMG_k xdf + /AGMIMG_y xdf + /AGMIMG_m xdf + /AGMIMG_c xdf + Operator/imagemask eq{ + [/DeviceN [ + AGMIMG_c 0 ne {/Cyan} if + AGMIMG_m 0 ne {/Magenta} if + AGMIMG_y 0 ne {/Yellow} if + AGMIMG_k 0 ne {/Black} if + ] /DeviceCMYK {}] setcolorspace + AGMIMG_c 0 ne {AGMIMG_c} if + AGMIMG_m 0 ne {AGMIMG_m} if + AGMIMG_y 0 ne {AGMIMG_y} if + AGMIMG_k 0 ne {AGMIMG_k} if + setcolor + }{ + /Decode [ Decode 0 get 255 mul Decode 1 get 255 mul ] def + [/Indexed + [ + /DeviceN [ + AGMIMG_c 0 ne {/Cyan} if + AGMIMG_m 0 ne {/Magenta} if + AGMIMG_y 0 ne {/Yellow} if + AGMIMG_k 0 ne {/Black} if + ] + /DeviceCMYK { + AGMIMG_k 0 eq {0} if + AGMIMG_y 0 eq {0 exch} if + AGMIMG_m 0 eq {0 3 1 roll} if + AGMIMG_c 0 eq {0 4 1 roll} if + } + ] + 255 + { + 255 div + mark exch + dup dup dup + AGMIMG_k 0 ne{ + /sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 1 roll pop pop pop + counttomark 1 roll + }{ + pop + }ifelse + AGMIMG_y 0 ne{ + /sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 2 roll pop pop pop + counttomark 1 roll + }{ + pop + }ifelse + AGMIMG_m 0 ne{ + /sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec 4 3 roll pop pop pop + counttomark 1 roll + }{ + pop + }ifelse + AGMIMG_c 0 ne{ + /sep_tint AGMCORE_gget mul MappedCSA sep_proc_name exch pop load exec pop pop pop + counttomark 1 roll + }{ + pop + }ifelse + counttomark 1 add -1 roll pop + } + ] setcolorspace + }ifelse + imageormask_sys + }{ + write_image_file{ + currentcmykcolor + 0 ne{ + [/Separation /Black /DeviceGray {}] setcolorspace + gsave + /Black + [{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 1 roll pop pop pop 1 exch sub} /exec cvx] + cvx modify_halftone_xfer + Operator currentdict read_image_file + grestore + }if + 0 ne{ + [/Separation /Yellow /DeviceGray {}] setcolorspace + gsave + /Yellow + [{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 2 roll pop pop pop 1 exch sub} /exec cvx] + cvx modify_halftone_xfer + Operator currentdict read_image_file + grestore + }if + 0 ne{ + [/Separation /Magenta /DeviceGray {}] setcolorspace + gsave + /Magenta + [{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {4 3 roll pop pop pop 1 exch sub} /exec cvx] + cvx modify_halftone_xfer + Operator currentdict read_image_file + grestore + }if + 0 ne{ + [/Separation /Cyan /DeviceGray {}] setcolorspace + gsave + /Cyan + [{1 exch sub /sep_tint AGMCORE_gget mul} /exec cvx MappedCSA sep_proc_name cvx exch pop {pop pop pop 1 exch sub} /exec cvx] + cvx modify_halftone_xfer + Operator currentdict read_image_file + grestore + } if + close_image_file + }{ + imageormask + }ifelse + }ifelse + }ifelse +} def +/indexed_imageormask +{ + begin + save mark + currentdict + AGMCORE_host_sep{ + Operator/knockout eq{ + /indexed_colorspace_dict AGMCORE_gget dup /CSA known { + /CSA get map_csa + }{ + /CSD get get_csd /Names get + } ifelse + overprint_plate not{ + knockout_unitsq + }if + }{ + Indexed_DeviceN { + /devicen_colorspace_dict AGMCORE_gget /names_index known { + indexed_image_lev2_sep + }{ + currentoverprint not{ + knockout_unitsq + }if + currentdict consumeimagedata + } ifelse + }{ + AGMCORE_is_cmyk_sep{ + Operator /imagemask eq{ + imageormask_sys + }{ + level2{ + indexed_image_lev2_sep + }{ + indexed_image_lev1_sep + }ifelse + }ifelse + }{ + currentoverprint not{ + knockout_unitsq + }if + currentdict consumeimagedata + }ifelse + }ifelse + }ifelse + }{ + level2{ + Indexed_DeviceN { + /indexed_colorspace_dict AGMCORE_gget begin + CSD get_csd begin + }{ + /indexed_colorspace_dict AGMCORE_gget begin + CSA map_csa 0 get /DeviceCMYK eq ps_level 3 ge and ps_version 3015.007 lt and { + [/Indexed [/DeviceN [/Cyan /Magenta /Yellow /Black] /DeviceCMYK {}] HiVal Lookup] + setcolorspace + } if + end + } ifelse + imageormask + Indexed_DeviceN { + end + end + } if + }{ + Operator /imagemask eq{ + imageormask + }{ + indexed_imageormask_lev1 + }ifelse + }ifelse + }ifelse + cleartomark restore + end +}def +/indexed_image_lev2_sep +{ + /indexed_colorspace_dict AGMCORE_gget begin + begin + Indexed_DeviceN not { + currentcolorspace + dup 1 /DeviceGray put + dup 3 + currentcolorspace 2 get 1 add string + 0 1 2 3 AGMCORE_get_ink_data 4 currentcolorspace 3 get length 1 sub + { + dup 4 idiv exch currentcolorspace 3 get exch get 255 exch sub 2 index 3 1 roll put + }for + put setcolorspace + } if + currentdict + Operator /imagemask eq{ + AGMIMG_&imagemask + }{ + use_mask { + level3 {process_mask_L3 AGMIMG_&image}{masked_image_simulation}ifelse + }{ + AGMIMG_&image + }ifelse + }ifelse + end end +}def + /OPIimage + { + dup type /dicttype ne{ + 10 dict begin + /DataSource xdf + /ImageMatrix xdf + /BitsPerComponent xdf + /Height xdf + /Width xdf + /ImageType 1 def + /Decode [0 1 def] + currentdict + end + }if + dup begin + /NComponents 1 cdndf + /MultipleDataSources false cdndf + /SkipImageProc {false} cdndf + /HostSepColorImage false cdndf + /Decode [ + 0 + currentcolorspace 0 get /Indexed eq{ + 2 BitsPerComponent exp 1 sub + }{ + 1 + }ifelse + ] cdndf + /Operator /image cdndf + end + /sep_colorspace_dict AGMCORE_gget null eq{ + imageormask + }{ + gsave + dup begin invert_image_samples end + sep_imageormask + grestore + }ifelse + }def +/cachemask_level2 +{ + 3 dict begin + /LZWEncode filter /WriteFilter xdf + /readBuffer 256 string def + /ReadFilter + currentfile + 0 (%EndMask) /SubFileDecode filter + /ASCII85Decode filter + /RunLengthDecode filter + def + { + ReadFilter readBuffer readstring exch + WriteFilter exch writestring + not {exit} if + }loop + WriteFilter closefile + end +}def +/cachemask_level3 +{ + currentfile + << + /Filter [ /SubFileDecode /ASCII85Decode /RunLengthDecode ] + /DecodeParms [ << /EODCount 0 /EODString (%EndMask) >> null null ] + /Intent 1 + >> + /ReusableStreamDecode filter +}def +/spot_alias +{ + /mapto_sep_imageormask + { + dup type /dicttype ne{ + 12 dict begin + /ImageType 1 def + /DataSource xdf + /ImageMatrix xdf + /BitsPerComponent xdf + /Height xdf + /Width xdf + /MultipleDataSources false def + }{ + begin + }ifelse + /Decode [/customcolor_tint AGMCORE_gget 0] def + /Operator /image def + /HostSepColorImage false def + /SkipImageProc {false} def + currentdict + end + sep_imageormask + }bdf + /customcolorimage + { + Adobe_AGM_Image/AGMIMG_colorAry xddf + /customcolor_tint AGMCORE_gget + bdict + /Name AGMIMG_colorAry 4 get + /CSA [ /DeviceCMYK ] + /TintMethod /Subtractive + /TintProc null + /MappedCSA null + /NComponents 4 + /Components [ AGMIMG_colorAry aload pop pop ] + edict + setsepcolorspace + mapto_sep_imageormask + }ndf + Adobe_AGM_Image/AGMIMG_&customcolorimage /customcolorimage load put + /customcolorimage + { + Adobe_AGM_Image/AGMIMG_override false put + dup 4 get map_alias{ + /customcolor_tint AGMCORE_gget exch setsepcolorspace + pop + mapto_sep_imageormask + }{ + AGMIMG_&customcolorimage + }ifelse + }bdf +}def +/snap_to_device +{ + 6 dict begin + matrix currentmatrix + dup 0 get 0 eq 1 index 3 get 0 eq and + 1 index 1 get 0 eq 2 index 2 get 0 eq and or exch pop + { + 1 1 dtransform 0 gt exch 0 gt /AGMIMG_xSign? exch def /AGMIMG_ySign? exch def + 0 0 transform + AGMIMG_ySign? {floor 0.1 sub}{ceiling 0.1 add} ifelse exch + AGMIMG_xSign? {floor 0.1 sub}{ceiling 0.1 add} ifelse exch + itransform /AGMIMG_llY exch def /AGMIMG_llX exch def + 1 1 transform + AGMIMG_ySign? {ceiling 0.1 add}{floor 0.1 sub} ifelse exch + AGMIMG_xSign? {ceiling 0.1 add}{floor 0.1 sub} ifelse exch + itransform /AGMIMG_urY exch def /AGMIMG_urX exch def + [AGMIMG_urX AGMIMG_llX sub 0 0 AGMIMG_urY AGMIMG_llY sub AGMIMG_llX AGMIMG_llY] concat + }{ + }ifelse + end +} def +level2 not{ + /colorbuf + { + 0 1 2 index length 1 sub{ + dup 2 index exch get + 255 exch sub + 2 index + 3 1 roll + put + }for + }def + /tint_image_to_color + { + begin + Width Height BitsPerComponent ImageMatrix + /DataSource load + end + Adobe_AGM_Image begin + /AGMIMG_mbuf 0 string def + /AGMIMG_ybuf 0 string def + /AGMIMG_kbuf 0 string def + { + colorbuf dup length AGMIMG_mbuf length ne + { + dup length dup dup + /AGMIMG_mbuf exch string def + /AGMIMG_ybuf exch string def + /AGMIMG_kbuf exch string def + } if + dup AGMIMG_mbuf copy AGMIMG_ybuf copy AGMIMG_kbuf copy pop + } + addprocs + {AGMIMG_mbuf}{AGMIMG_ybuf}{AGMIMG_kbuf} true 4 colorimage + end + } def + /sep_imageormask_lev1 + { + begin + MappedCSA 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or has_color not and{ + { + 255 mul round cvi GrayLookup exch get + } currenttransfer addprocs settransfer + currentdict imageormask + }{ + /sep_colorspace_dict AGMCORE_gget/Components known{ + MappedCSA 0 get /DeviceCMYK eq{ + Components aload pop + }{ + 0 0 0 Components aload pop 1 exch sub + }ifelse + Adobe_AGM_Image/AGMIMG_k xddf + Adobe_AGM_Image/AGMIMG_y xddf + Adobe_AGM_Image/AGMIMG_m xddf + Adobe_AGM_Image/AGMIMG_c xddf + AGMIMG_y 0.0 eq AGMIMG_m 0.0 eq and AGMIMG_c 0.0 eq and{ + {AGMIMG_k mul 1 exch sub} currenttransfer addprocs settransfer + currentdict imageormask + }{ + currentcolortransfer + {AGMIMG_k mul 1 exch sub} exch addprocs 4 1 roll + {AGMIMG_y mul 1 exch sub} exch addprocs 4 1 roll + {AGMIMG_m mul 1 exch sub} exch addprocs 4 1 roll + {AGMIMG_c mul 1 exch sub} exch addprocs 4 1 roll + setcolortransfer + currentdict tint_image_to_color + }ifelse + }{ + MappedCSA 0 get /DeviceGray eq { + {255 mul round cvi ColorLookup exch get 0 get} currenttransfer addprocs settransfer + currentdict imageormask + }{ + MappedCSA 0 get /DeviceCMYK eq { + currentcolortransfer + {255 mul round cvi ColorLookup exch get 3 get 1 exch sub} exch addprocs 4 1 roll + {255 mul round cvi ColorLookup exch get 2 get 1 exch sub} exch addprocs 4 1 roll + {255 mul round cvi ColorLookup exch get 1 get 1 exch sub} exch addprocs 4 1 roll + {255 mul round cvi ColorLookup exch get 0 get 1 exch sub} exch addprocs 4 1 roll + setcolortransfer + currentdict tint_image_to_color + }{ + currentcolortransfer + {pop 1} exch addprocs 4 1 roll + {255 mul round cvi ColorLookup exch get 2 get} exch addprocs 4 1 roll + {255 mul round cvi ColorLookup exch get 1 get} exch addprocs 4 1 roll + {255 mul round cvi ColorLookup exch get 0 get} exch addprocs 4 1 roll + setcolortransfer + currentdict tint_image_to_color + }ifelse + }ifelse + }ifelse + }ifelse + end + }def + /sep_image_lev1_sep + { + begin + /sep_colorspace_dict AGMCORE_gget/Components known{ + Components aload pop + Adobe_AGM_Image/AGMIMG_k xddf + Adobe_AGM_Image/AGMIMG_y xddf + Adobe_AGM_Image/AGMIMG_m xddf + Adobe_AGM_Image/AGMIMG_c xddf + {AGMIMG_c mul 1 exch sub} + {AGMIMG_m mul 1 exch sub} + {AGMIMG_y mul 1 exch sub} + {AGMIMG_k mul 1 exch sub} + }{ + {255 mul round cvi ColorLookup exch get 0 get 1 exch sub} + {255 mul round cvi ColorLookup exch get 1 get 1 exch sub} + {255 mul round cvi ColorLookup exch get 2 get 1 exch sub} + {255 mul round cvi ColorLookup exch get 3 get 1 exch sub} + }ifelse + AGMCORE_get_ink_data currenttransfer addprocs settransfer + currentdict imageormask_sys + end + }def + /indexed_imageormask_lev1 + { + /indexed_colorspace_dict AGMCORE_gget begin + begin + currentdict + MappedCSA 0 get dup /DeviceRGB eq exch /DeviceCMYK eq or has_color not and{ + {HiVal mul round cvi GrayLookup exch get HiVal div} currenttransfer addprocs settransfer + imageormask + }{ + MappedCSA 0 get /DeviceGray eq { + {HiVal mul round cvi Lookup exch get HiVal div} currenttransfer addprocs settransfer + imageormask + }{ + MappedCSA 0 get /DeviceCMYK eq { + currentcolortransfer + {4 mul HiVal mul round cvi 3 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll + {4 mul HiVal mul round cvi 2 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll + {4 mul HiVal mul round cvi 1 add Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll + {4 mul HiVal mul round cvi Lookup exch get HiVal div 1 exch sub} exch addprocs 4 1 roll + setcolortransfer + tint_image_to_color + }{ + currentcolortransfer + {pop 1} exch addprocs 4 1 roll + {3 mul HiVal mul round cvi 2 add Lookup exch get HiVal div} exch addprocs 4 1 roll + {3 mul HiVal mul round cvi 1 add Lookup exch get HiVal div} exch addprocs 4 1 roll + {3 mul HiVal mul round cvi Lookup exch get HiVal div} exch addprocs 4 1 roll + setcolortransfer + tint_image_to_color + }ifelse + }ifelse + }ifelse + end end + }def + /indexed_image_lev1_sep + { + /indexed_colorspace_dict AGMCORE_gget begin + begin + {4 mul HiVal mul round cvi Lookup exch get HiVal div 1 exch sub} + {4 mul HiVal mul round cvi 1 add Lookup exch get HiVal div 1 exch sub} + {4 mul HiVal mul round cvi 2 add Lookup exch get HiVal div 1 exch sub} + {4 mul HiVal mul round cvi 3 add Lookup exch get HiVal div 1 exch sub} + AGMCORE_get_ink_data currenttransfer addprocs settransfer + currentdict imageormask_sys + end end + }def +}if +end +systemdict /setpacking known +{ + setpacking +} if +%%EndResource +currentdict Adobe_AGM_Utils eq {end} if +%%EndProlog +%%BeginSetup +Adobe_AGM_Utils begin +2 2010 Adobe_AGM_Core/doc_setup get exec +Adobe_CoolType_Core/doc_setup get exec +Adobe_AGM_Image/doc_setup get exec +currentdict Adobe_AGM_Utils eq {end} if +%%EndSetup +%%Page: Alternate-ISC-logo-v2.ai 1 +%%EndPageComments +%%BeginPageSetup +/currentdistillerparams where +{pop currentdistillerparams /CoreDistVersion get 5000 lt} {true} ifelse +{ userdict /AI11_PDFMark5 /cleartomark load put +userdict /AI11_ReadMetadata_PDFMark5 {flushfile cleartomark } bind put} +{ userdict /AI11_PDFMark5 /pdfmark load put +userdict /AI11_ReadMetadata_PDFMark5 {/PUT pdfmark} bind put } ifelse +[/NamespacePush AI11_PDFMark5 +[/_objdef {ai_metadata_stream_123} /type /stream /OBJ AI11_PDFMark5 +[{ai_metadata_stream_123} +currentfile 0 (% &&end XMP packet marker&&) +/SubFileDecode filter AI11_ReadMetadata_PDFMark5 + + + + + Adobe PDF library 6.66 + + + + + + + 2004-10-06T16:15:40-07:00 + 2004-10-22T21:51:43Z + Illustrator + 2004-10-06T16:15:40-07:00 + + + + JPEG + 256 + 152 + /9j/4AAQSkZJRgABAgEASABIAAD/7QAsUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQAB/+4ADkFkb2JlAGTAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoK DBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAmAEAAwER AAIRAQMRAf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWxQiPB UtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE 1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZ qbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEy obHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp 0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo +DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8AiX5AfkB5O/MTydea1rV5 qNvdW+oyWSJZSQJGY0ghlBIlhmblymPfMfLlMTQbIQBDOPM//OKX5U6B5e1DWZ9R1uSOxhaX0hcW il2H2U5G0NOTUFcOCcskxAVuWOaoQMj0Y1+Wf5EflJ56N+kUuvWEtgImZHu7OTmJS4+Glmv2eG+3 fMvXYJ6etwb8v2uPpNRHNdCqZz/0Jp+WH/V01v8A5H2n/ZLmv/MSczww7/oTT8sP+rprf/I+0/7J cfzEl8MO/wChNPyw/wCrprf/ACPtP+yXH8xJfDDAfzv/AOcc/JHkPyHN5g0i+1Oe9juIYVju5bd4 uMrUYkRwRNXw+LJ48xkaRKAAfT/5V/8AksPKH/bE07/qEjzJaiynFXYq7FXYq7FXYq7FXYq7FXYq 7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq+BfyU/MTzH5Nhnn0yUPbSzt9ZsZqtBJ8CAMVBFGHZ hv8ARtmz0uihnwkS58XPryDrdVqp4sorlXL5st1/z/8AmP5whlgu7p20+b7VnCqwW9AwYL250YD7 TE5eI6TSncgS+Zccy1OoGwPD8ggfLXmTzl5HvJLzTD9X9YKtwroksUiqSVVjvTc9iDlkp6bVjhsS +wsIxz6Y3Vfc9B1b/nJjWZ9Hhh03TYrPVmH+lXTt6sQp/vqM/wA3+UTT365iY+w4CVyNx7v1uTPt eRjsKk9s8j+YrjzH5W0/Wbm0aymu4wzwtsCRsXTcng1KrXemaHV4RiyGAN07jT5TkgJEVae5jNzx v/nLL/yT91/zG2v/ABM5dg+pjPk9M/Kv/wAlh5Q/7Ymnf9QkeZzjllOKuxV2KuxV2KuxV2KuxV2K uxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV+eX5W6Yl7aztLvBDMSy/zEqtB8tsyJ644NP6fr lI18hZcX8oMuf1fTGP6S9h0Ly3rGtzm20q1M7RgF6UVEXtyZiFHTbOa3ke8u52Adr3lvWNEnFtqt qYWkUlCSGRx3oykqeu+DeJ7iuxDANasU07UIriJFaF29RYmAK8kILKVPVc7bsjWnUYiJfVHY/oLy /aOlGHIDH6S+zNB1K31TRNP1K2UJb3lvFPEg6KsiBgu38taZzGaBhMxPMF6DHMSiCOoR2VM3jf8A zll/5J+6/wCY21/4mcuwfUxnyemflX/5LDyh/wBsTTv+oSPM5xyynFXYq7FXYq7FXYq7FXYq7FXY q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq+A/yedP0NepT4xccie5BRR+FMxNfE8ET0uX+9bNP IcZHWh+l9K/kxr2kW1neaZcSxwXskwmjaQhfUUqF4qT1Kla098wMUg5Mgq/nNrujzada6XDKk9+s 4mbgQ3pIEZaMR0Lcht9PhjlIWIeCebnQQ26U+MszA+AAAP31zoPZyJ4pnps6ftqQqI67s3/KGD81 YPMejRFNVh8ts6tKJ0mFp6HAsOPqDgFYUoVzYdonTGEvp4/hduJoRnE4/VwfY+lCyggEgE9B45yr 0Lxb/nLe8tYvyoe2kkCz3N7bmCM9W9NqtT5A5bhI4wFlAmBI5B6l+Vf/AJLDyh/2xNO/6hI8z3EL y3/nLq+1nQPJem69oWsalpWoyapHZytZX11BG8UltM5BijkVK8oFoaePjir0v8ooJB+W/lq8nu7u 9vNR0uyvLy5vbme6keaeBZXPKZ34jk52XbFWYYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7F XYq7FXYq7FXYq7FX5z/l3fy2Nq88Y5D1mDodgylE2zaafSR1GnMJfztvI0HWanUSw5xIfzf0l6Zb a3plwnITrGe6SkIR9+x+jOdz9k6jGa4TId43dti7QwzF8Ve/Zq61zTLdORmWU9kiIcn7th9Jw6fs nUZD9PCO+W37Vzdo4YDnfu3S3y5bW3mjzpptlqVwtnZ3U6xO5JoEFTwBAPxP9kH+Y+GdXDCNJpyI CyBfvPf+Ojz5ynU5xxbAvozTPzt/L2W4vbT60bO109R6E8qFY5kX4SIVUF9uylakduucN+aiSbfQ Z9gamMYkC+LoOnveJeYvzDnP5kTeatBmlMUUoayS7qRxMYSRCgbZHPLYHp4HMKWT18Qet03Zo/Kj DkA5b179vixD84/zA8y+btFi/TEsbJaSVt44o1jVTIRy6bn7I6nMzRZJSyi+4un7Y7OxabSS8Mcz G32N+Vf/AJLDyh/2xNO/6hI83jwxeUf85q/+Ss0r/tuW/wD1CXeKvVfyn/8AJWeTf+2Hpv8A1CR4 q8j8x/nX5n8ifnH5nGr28+o/l4tzp9rNKnxtp082nwSckAqQklWYp0Y1K/FUFV7F5gutN1/yJe6h pmoSNaT2M1xY6jp1zJC1fRfi6SwMh2PY9+o2xVjP5faLe+ZPyb8tx3WtanDPqNraXmo6jHeXBvpD QSMqXLSGSIOwAbifs1HeuKvOfzm0m/8ALHnz8tdI0fzJ5hhsfMmqG01aNta1GQyRC4tI6KzTEp8M 77rir2bQfIEWia5+kbXWtYurZ7SW2msNQ1G7voS7yROkyC4kk4OgjZajs2KvH9Is9R1n/nJrzd5Q utf12Py9p+mRXtnZQavqEQjmaOxJIZZg1K3D7Vpvir2Xy/5JTSdO1PTZdW1PUbS9ujcW8l3fXUlz bxmGKMwpcmT1uIkjZx8X7WKvB/8AnH/RPMX5gflhrGqaj5x8wQa/BqE9rYagNWvfTjEdtBLH6kLS NG685TyqtaYq9K/5xr86+aPOH5Yw6n5kJlvYbqa1hvWADXMMQUrK3EAVDM0ZPfjirHPzm/M7zt5G /M6wvNIt5NV8u22jC78waSrbCD620RuUG5R0LKC4FKfa23Cr1fyr5t8s+ePLcWraHeG5066HFzG7 RTROAC0UnAq8ci13FfwOKsS/JBbuS183fXNQv9Qaz8y6rp1s97eXFyUtbaVUijX1XYLxA6jfFWA6 RZ6jrP8Azk15u8oXWv67H5e0/TIr2zsoNX1CIRzNHYkkMswalbh9q03xV6vB+XE8Oi3+ijzJrJs7 2/S8W5e+uJL6GBI4gbWK8eQzIjSxFiQfssy964q8i/ObSb/yx58/LXSNH8yeYYbHzJqhtNWjbWtR kMkQuLSOis0xKfDO+64q9n0DyDFoWvDU7XWtXurdrWW2m0/UdRur+Eu8kTpMq3MknF0EbLUdmxVl WKuxV2KuxV2KuxV8tf8AOKPkvyrr35Z6zJq+mQ3k02qy2zTSL+8WJLa3dVRxRk+JyaqQcqnqsmMj hkR1T4EJg8QtKPzn/LXS/JV9pzaXNNJaakJisc5VijQlKqGULUfvO4zoezNdLODxAXGnR6/SRwkc PIsk/Ln8gtN17QNP17V9RnSO9VpPqMCKhCh2VaysXryVQ32B1+nMXW9ryxzMIgbdf2ORpezIziJS PPownzdp3kO384XUWjyXMOkWbMrRg82kkiFCsEjVKhn25PWg+LfZc1uP2mIgRKPFLoeh9/7Ofk9P H2GyT4JxkIxl9Q6x93f+hj2oXjXt9cXjIsbXEjStGleILmpArU985ORs2+nYcfhwEbJ4RW/PZG2X l+4mAec+ih6LSrn6O2TjiJdNre38WI8MPXL7Pn+Pek/5j6Pa2nliWWMuW9WMfEQep9gM2GhxgZHm O0u2cuoxGEhER8v7X2j+Vf8A5LDyh/2xNO/6hI83LzpeUf8AOapH/KrdKWu51yAgd6C0uv64q9V/ KYg/lZ5Np/1Y9N/6hI8VYb5Q0/SvMf5j/nBpWq2yXNhdzaVbXVq+4ZBp/p12oQTwqCNwehqMVea6 5Yeb/wAgZ9Tgtlm1r8qtdWWJVrym0+edCq1rQA1NK/ZkHg2Kvevyiiji/KrycqDip0TT2I93tY2Y /STiryz/AJyO/wDJp/kv/wBtw/8AUXp+KvoDFXzXp/lvSfMH/OXnney1P6x6CaPbzJ9VurmyfmsG nKKyWskLkUY/CWp3psMVe6+U/LmkeW0vdK064llV5hfGK5nluZo1nURqGlneSRlLQNxLH27Yq+XP yK8n+e9f/IrzOPKfmS5025fULiJdIRLcQ3LLa2zOPXaP6xE8qNwqkqjYV74q93/Ij8xPLvmnyhBp tjaR6Pq2hItnqnl9FMZtnj+CqI3xemxB3O4NQ2+KqFxLDN/zkwllKitGfJMpYPQhxLqiqUKkb7R4 q8984/l15r/JzzNP+YP5axNd+WZjy8w+WBXikIqzMgFf3a7lSByj90qMVehf8476tZ635O1fXrON ooNZ8watqCJJTmFuLkugehI5BKA0xV57p/lvSfMH/OXnney1P6x6CaPbzJ9VurmyfmsGnKKyWskL kUY/CWp3psMVe6+U/LmkeW0vdK064llV5hfGK5nluZo1nURqGlneSRlLQNxLH27Yq8e/5yO/8mn+ S/8A23D/ANRen4q+gMVdirsVdirsVdirsVfOv/OGn/ksNU/7bc//AFCWuYeo+pux8ntWreX9C1hE TVtOttQWLl6X1mFJeHOnLhzB41oOmQx5pw+kke5M8UZ/UAUFq3mDyp5P0+zhv7iLTLI0t7KMIxUB F+yqxq1AB36ZTlzC7kdy5ek0OTN6cUb4Q+XvzM13S9c866lqGmRJHZO4SOSMcfWKDi0xG28h36dO u+arLIGRIfRey9PPDp4xmfV93l8EHoGmqVF5KtTX9yD2p+1/TJ4odXS9vdpkHwYH+t+r9f8AanuZ DyTEPzS/5RKX/jNF/wASzJ0f1teb6X2H+Vf/AJLDyh/2xNO/6hI82zhlb51/K3yR52EK+aLGXUYr ducMBvLyGJXpx5CKGaNOVO9MVTHy15Q0Ly1p0em6MlxBYQp6UFvJd3VwkaDosYnll4AduOKoTRfy 68p6Lr1/r2m29xDq2qFG1G4a9vZfXMYIT1ElmeNuAYhart2xVPNS03T9TsJ9P1G3ju7G6QxXFtMo eN0bYqynYjFWtK0yx0rTLPS9Pi9CwsII7W0hBZgkMKBI1qxZjxVQNzXFWO+avys8j+a9VstV16xm u7/TW9TT5heXkIgcFTyiSGaNENY1NQOoxVlFvAkEKQoXKIKAyO8jfS7lmP0nFWDXn5Gflnd69P5g n066Ot3NPW1FNT1KOZqKEHxpcqacVAxVO9F8g+WdFsr6z02K5ij1Fle8le+vZZ3ZAFWlxLM8y0Ap RXGKqPkr8s/JfkmGWDyxZSafbzuZZbf63dzRNIVCl/TmlkTlxUCtMVWXX5XeRbjzT/ir9Gm28wkF ZNRs7i5s5JAQAfVFtJEslaCvMHFVWb8ufKU3mtfNklvcnzAkRt0vhfXqlYCxcxCMTCMR8mJ4caYq yUgEUO4PUYql2g+W9D8v2cllotlHYWck0lw1vCCsYklNXKrWignstBirFLz8jPyzu9en8wT6ddHW 7mnraimp6lHM1FCD40uVNOKgYqyLyx5N8v8AllLpNHhmjN66y3Ulxc3N5I7KvFayXUkz0A7A0xVL vNX5WeR/Neq2Wq69YzXd/prepp8wvLyEQOCp5RJDNGiGsamoHUYqyi3gSCFIULlEFAZHeRvpdyzH 6TiqpirsVdirsVdirsVfOv8Azhp/5LDVP+23P/1CWuYeo+pux8nvOY7Y8/8Azo8q6Nq/lK61O/eW O40aCaayeJqLzYCiupqCGZVB75j6mAMbPR3XYeryYs4hGqmQC+XIYmlmjiX7UjBR82NM1z3+XIIR MjyAtmqIqIqIKKoCqPADYZmgU+X5MhnIyPMm12Fghvzc8i6jZ/lNJ5hvHEKS3FsLe1pV2SRtnY1+ HboMy9JH1W1ZTs+nfyr/APJYeUP+2Jp3/UJHm0cQph5t84eXfKWjSaxr94tnZIwRWILvJI32Y441 DO7t2Cj8MVYZqX57aRpCQXOs+V/Mel6ZcOkUep3ViiwBpCAgfjM0sfIttzQYq9MxV2KuxV2KuxV2 KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KvnX/nDT/wAlhqn/AG25/wDqEtcw9R9Tdj5P ecx2x4p+e3lfzteTXGr2dy7eXLa1Q3NoJ2ChkY839H7J6jf2zC1MJXfR6z2f1eniBCQ/emWxr9Lw yw/3utv+Mqf8SGYkeYen1wvBP+pL7mZZmvmTsVZ7/wA5N6hZ6h+Rn12zINtNc2bRhabDkfh27r0O bDTm5Boyci9X/Kv/AMlh5Q/7Ymnf9QkeZ7jF43/zl1Lrmk3vkTzVBAbvSNC1Fp7m3IPpfWFeGWES 0rtIsLqK9PpxV6v5X84+R/zX8mXB06cXFleRGDULJqLc27Ov2ZENeLKd0bcGlQTiqF1P85dE0r8w NN8j6ppGp2OpauwXTr6ZLX6lKDWhWVbhm+0OPHhyrTbcYqnfn7z3pvkrRYtWv7S7vo5rmGyhtbBY pLiSa4PGNUjlkh5knspJ9sVa1vz9pOg6TZX2t29zY3WozJbWGjlY576a4k+zFHHbPOrN40eg7nFV C2/MOI6rHp2p6DqujGaGa5hur2O2Nu0cCeo/7y3nuOLcd+D0b2xVj+t/njDofl6TzFq/kvzJZaPC sby3M0OnrxEzrGnKP676gq7qKccVRNp+cf1rSrPWU8meYho97HDPFf8Ao2DRiC4CskzLHePIE4sG Y8dh1xVW8+/nFpHknXNH0bUtG1S7u9flNvpDWS2jpPMGjTgPUuYmU8p0HxAdcVR+kfmFNfa7a6Pe eV9a0aW9SV7e6v47P6uTCvJkL29zcEMR0FMVTTW/OGiaLrWiaPqEpiu/MEssGnGg4GSGP1CrGu3I bLtudsVTvFUj8u+cdD8w3utWelymWTQb06ffNQcfXWNXbgQTUKX4GtPiU/MqobzF5/0XRdZtNBEV zqfmC+jae30iwjEs/oKeLTSF2jiij5bcpHUE9MVVPLXnBNb1HUdNl0nUNH1DTEgkuLfUY4V5JcmV Y3ikt5biKRawOCVfFWQ4q7FXYq7FXYq7FXYq7FXYq+df+cNP/JYap/225/8AqEtcw9R9Tdj5Pecx 2x51+eHmy/0HysLa2sUuYdZE1jPPIW4xCSOlAi05MyluPxbU6HMfUzMRXe7zsHRxzZrMqMKlXfu+ YCHR6EFXU7g7EEZrn0AgEeTMrO5W5to5l/bHxAdj3H35mRlYfNNbpjgyygenL3dFbJOIxj80NQvk 8i3Fis7izluIXe35HgWVtm49K++ZWj+trzfS+u/yr/8AJYeUP+2Jp3/UJHm1cMpxrekaHr2nXeh6 vbxX1lcxgXdlLQ1jcnixA+JfiQ8WHcbbjFXx/wCefJXmT/nHvz/p3mzy1cyXHli9mMSo7fEU+1JZ XIFA1UFUf2rsVxV9Efnb+XUf5geRuWnEx6/ptNR8vXa1WRZlAb0ww+IeqAB7NxPbFWLfk35j1D83 LrTPOOsxenY+VIhaW9r+xNrTxA3N5xB+ykLqIlP2S7HFU7/Pv8vvN/mO20LzF5MuBH5o8p3El3YW zlQswlCc1Bf4OX7paB/hIqD1xVA/lD+ek/mzXn8necdGOh+drBWlELIyxSlFIdo1kq8T8GJpUgrU hqbYqmH/ADlH/wCSJ8zf9GP/AHULfFWVflQA35VeTlYVB0LTQQehH1OPFXkn/OTk89v+Y35Pz29u 95PFrEjw2kbIjyut1YFY1aRkQFzsCzAeJxV61onm/wAwahr0Ol6n5SvdFR4JrlLy6uLKaP8AcsiF V+qzXB5H1h1ptirxr/nJzRvMHmLzXZRaFM8eoeTNDm8ywrGKuXN7DH8BrXmEt3kX4TulO+Ks6i/O car+TVj5q0dFk8x6z6el6fp43/3MzH0fTof2Uesu/wDusVxVhn/OMdldeWPP/wCYvkq8uWu5rOe3 uVuXJ5SGsgkkIPd/UQ4qmv5xeUPzP0Pz/b/mj+XcS6ldrZDT9X0dl9RpIUfn8EYKtIrUWqoeYK1F a7Ksv/Jv839H/MewvZVsW0rzDphSDWNOloXQ1fgVchWZOQfZgCpqCO5VejYq7FXYq7FXYq7FXYq7 FXYq+df+cNP/ACWGqf8Abbn/AOoS1zD1H1N2Pk95zHbGiqkgkAlTUHwNKfxxS+UPzkutEufzA1KT SkdOLCO+5rwU3UfwylFNDTYVr1apzV5iOI0+jdiQyR00RP4f1ejGNK1RrOQq9Wgf7Sjsf5hkYTpe 1ezBqY2Nsg5H9BZRDNFNGJImDoejDMoEF4TNgnilwzFFif5pf8olL/xmi/4lmVo/rcXN9L7D/Kv/ AMlh5Q/7Ymnf9QkebZwykHm1PzQ0f8w18xeWdIh8w6BeaZBYajpf1uO0uVnt7i4lSaJp6RfZuaHf f2oDirH/ADj5I89/mxe6Rp3mfSI/K/k3TLpb+8tXuoru/u5kVkRF+r8ook4uwJ5k71xV7DdzSW1o 8kFs908Y/d2sJjV27UUytGg+lhirx7/nGDyX5z8keT7/AEHzPo0thcz6lLexTie0miMb28MYH7ma R+XKE/s4qzXzNqX5haV5piutG0L/ABB5euLRIrq2huoLa5guY5Xb1Y1uWjidWRwGHMHb23VY/pvk zzH5j/NnTvzB1/SU0CDQbGSz0ywaaK4vJpZxIjyTvbs8KIkcrBUDtua1xVGf85AeXvMnmb8r9V8u eXtNk1HUtSNuIwstvCiCC6hnYu08kXVYzTjXFU9/LC11iw8haBpGr6bLpt/pWnWllcRyyW8oaS3h WJijQSSgiqV3p1xV5z+fXlHz/r/nbyHq/lny9JqsHlO+a/umN1Z26y1mtZljT1plf/j3YElcVZ/p 3mfz3qGr6fay+TrrRtPeR21HULy70+ZUjWJyqpHbXE0jM8vBelAN8VSnyzpHmVvzd8z+YNU0S4tN Jv7KxsNKuZJbSRSluJHnMkcVxI68pHAX4DXvTFWOflr+Q0vlP8ytZ1R5eflS3ma78q6dyDJFc3iB LiUx/stCiekh7qcVdZ+TPO2hf85H635ztNElvfK+uWEdrNPBPaKVlWKD4/Rlmhf7dvStD9onFWXX ut/mbpHmnWI4/K7+YfLtzJFNpNzZ3tpDNCBbRRywyxXckAoZkd1Kt3xVB/lr5C1ew84eavPWu28O nap5nkhWLSbdxKttb26BAZJFCq8spHJ+OwPc1xV6RirsVdirsVdirsVdirsVdir51/5w0/8AJYap /wBtuf8A6hLXMPUfU3Y+T3nMdsQGoa9omnT29vf30FrcXTrHbQyyKryO7cVCKTU1O2WwwzkCYgkB hLJGJomrQd15K8p3eoXWo3WlW897ex+jczyIGZkC8e+wPHao3zGOKJNkOdDXZoxEYzIjE2Hyf5k0 uzj81alp2hRTzWkFxLHbRspaXhETy2ArQUPUVp1zWGO5p9G0+c+DGWUgSIHuspTBc3Fu/OFzG3en eniO+AGm7Pp8eWNTAkEr896vd3Plp4JuLD1IzzpRtj7Gn4ZsNBMnJReT7d7Jw4cByQsGx12/Hxfb v5V/+Sw8of8AbE07/qEjzePFFlOKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV 2KuxV2KuxV86/wDOGn/ksNU/7bc//UJa5h6j6m7Hye85jtj5B/OE2S/mVrEun3KTwvKkglicOFkM amReQJ3WSvyztuzb8CIkKeW19eMSCzGx/wCcmfMNvaWsM+k29zJDGqTztI6tKyinPYUUnqeuYM+w 4EkiRDlR7XkALDBvzG8+t5y1tNSXT49NVIkQxxkO7utfjkkCoXO9FqNhmZoezoaeyN5Hr+hp1naW TOBAkiEeUb2vvZjpf5M+bNeg8vanNJHLYX8UL3tz6oNwkUjGQu4YDkwjYKtGY9K0zi+1cHFqZcIA jfT7ftfRewO2oYNCIzMjkAJF7+4Wln/ORn5QaL5T8irq+k3F1KGvIYJobgo6qrh25hkRKfEoXfxy OlwCGQENGt7ZyanBKExEcjt7w+kPyr/8lh5Q/wC2Jp3/AFCR5tnnCxj88Pzoi/LzTrSz061Gpeat YPDSrA1KD4gvqyhSGK8moqjdjtUbnFXaF+WHnPUrGO988+dNYfV5xzmsNGuf0bZ25bf0k+rKkknD pyL7+GKpJ5+/Lfz15b0afzB5N89a4X04fWbvTNUufr8UluhDS+m8ysyssYLDlyrSm2Kva8VdirsV dirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVfHH5K/mFceTPyPvZrD021W98wzR2qyg soSO0tGlYgUqKUXr+1lul0Yz5al9IH9jRqtUcWOx9RKa+aP+cgPNGu+XW0lLaLTZ5zS7vLV3BeKm 8aK1SnLueZ22za4Ox8eOfFfF3AutzdpznDhqnmkUApyfv0X+uYHavb/gyOPFRkOZ6D9r1Hs97HnU wGbOTHGeURzkO/yH2nyVQqAEBVofYE/ed85qXbOqJvjP2Pcx9l+z4x4fCj9pPzu1jwIw+H4W/A5t tB7RzEhHNvH+d1H4/FvOdsew+MxM9L6ZD+AmwfcTuD7yR7no/wCT/wCbcnlK4k0vWZJJNAkDsigF 3gmAJ+AdeLnYr47+Ob3tHs8ZwJwri+8PBaLWHCTCd19xX/n5+cXlzzh+Xt/pGm29zC8c1vOs1yEQ OElClVVWc/t1zUz7MyYQJSI+Ds8WvhlJiL5Poj8q/wDyWHlD/tiad/1CR5BtL5u8+3Bv/wDnMzSL bURW1srrTYrMP9mgt0uEpX/l4kP04q+usVaIBFDuD1GKvMPzU/MTW7LzT5d/L3yq6QeZvMzGR9Rk QSrZWUfIyTLEdncrE/Hl8PwmuKprc/lSs9sKebPMkeohaDUE1OZfiofiNsKWp3PT0sVYX+Vv5k+d NP8AzL1L8qfPk6alqVtGZ9F1xEETXMKp6gEqr8JJiPIECoKsGJ64qk/mP86/M/kT84/M41e3n1H8 vFudPtZpU+NtOnm0+CTkgFSEkqzFOjGpX4qgqvYvMF1puv8AkS91DTNQka0nsZrix1HTrmSFq+i/ F0lgZDsex79Rtirz6383eYPLf/OMsHm2ykn1PXhpNvdtPezS3bmacokkzGZnNIw5k49NsVVfI9jo /nfybZavoHnbVbvzAkcMt7cDUp1CXNFd4LmwRhBGjMrLQRV4/ZJGKorzz588wal+Zenflf5Uuf0b dzW5v9f1wIkstraAEiO3SQMnqybfEynjyFB4Kpxqn5TyT2kh07zd5isNVKn0b46lPOgfqC9rITbs teoVF9qYqxj8kvzR806t5j1/8u/PHpyeafLvJhfwKI1urdHWMyFV4gNWRGBUCqsNgQaqsa0qz1HW v+cmfN/k+58wa7F5fsNLjvLOzt9Xv4hHM8diSVZZq0rcOaHbfFU5/KrV/PVl+avnj8ur3WLjWtI0 i2juNN1i9P1ie3kuFjeGKSQ8WkJSY1qesZpSuKqX52eTpvJv5R6vrmkeZ/Mn6Y09bQRXk2tag9TL dwwuzR+sI/iSRv2cVT3yT+Xh1n8v/LesnzL5ii1m+0ywv5Lg6zfyRtcSQRzNzheVozGzn4lp02FM VY//AM5AX+sad+Zf5X22m6tqVha6/qv1XVra0vrqCKaFbmzjCmOORUX4ZnBKgVrirJv+cj5b3Sfy d1fVdK1C+0/UdNFoLS6tby5hkAkvIYW5tHIvqVRyKvXFWUflR6z/AJa+WLu4uLi7u77S7K7urm6n luJXmnto3kYvMztuxrQGmKsJsDej/nJi80U6lqLaPF5bXU49Oe/vGtxdC8ii9T0mlKH4CRxI4+2K oX8/fzcvPIHm/wAivDK/6PknuZddtkJo9n+6hqyjqV9RnT/KXFXsFzrGmW2kSaxNcoumQ25u3u61 jECp6hkqP2eG+KvJf+cd/wAz9U8+XnnafUGkQQanHNY2cvW2tJ4jHDEFJ+Ha3JbsWJPc4qwz/nFD QdH138oNY0/VrWO7tJNbn5RyDofqlrRlI3Vh2INcx55pY5iUTRZ+HGcakLDyTU7a1j1y9t7RWW0i uJlgSQ1YRI7cQxHU8RnU6zUyxaaWT+IR+0/tdN2Xo46jWwxfwyn/ALEbn7GWflb5Oh82+bodPuiR Ywo11ehTRmijKjgDsRyZ1Wo7Z5tihxy3fae1dZ+VwcUef0x/Hk+p7Py/oVlYiwtdPt4bMLxMCxIE I/yhT4vpzZDHECqfPZ6nJKXFKRMu+3g357/l3pegyWuu6PCLazvZDBdWqCkaTcS6NGP2Q6q1V6Cm 2YOoxCO45PY+z/aU8wOOZuURYPk8buFHIMB1G/zGdr7O6g5NPwn+A18HgfbbRRw63ijyyR4vjyP3 X8WX/mR+VFlon5Kx+a57trnUL9rKW3iQcIoormj0Nfid+JG+w9u+U63tE5JnEBUQfudfo9EIR8Qm yR976m/Kv/yWHlD/ALYmnf8AUJHmI5heIf8AOUv5ZeY013TfzQ8qxPNeaV6LalHEC0kbWr+pBdKg 3YL0enQAHpUhV6z+U/5y+VPzE0aGayuY7fW1QfX9HdwJo5AKsUU0Mkfg4+mhxVkHnfzlpXlPQZtT vpYxMR6en2jtxe5uX+GKGMAMxLuQDQGg3O2KvEvzwFx5K/PPyX+Z1xE7+XkjGm6jOoLiAsJomYge MNyWXxKnFX0LZXtnfWkV5ZTx3NpOokguIWDxujbhlZSQQfbFXhOlab/i7/nKm58z6YPV0XyhYfUr m/XeKS9khkiMKMNmZBcNy8OPyqqyDyhp+leY/wAx/wA4NK1W2S5sLubSra6tX3DINP8ATrtQgnhU Ebg9DUYq811yw83/AJAz6nBbLNrX5Va6ssSrXlNp886FVrWgBqaV+zIPBsVe0/l3e6Lp/wCVHkSz 1Dgtvq+l6dZRxygGOSW4sRIY2DbH1OLCncmmKvHPze/Ke0/K7U9L8/8A5cXMumajLqMFmdAVyYrl rhifSiqeXF+NGiNVp0pTFUx84T/8q9/5yis/OOsAxeWvNdqti+pN/dQyiFIOLtSi0aCNmr+yxPY4 q+jY54ZIVnjkV4HUOkqkFSpFQwYbUp3xV4P+VWlN5k/5yB88fmNZrXy6iLpOn3Y/u7meKOCGV4mG zov1U7jb4hiqS2Wk6vqn/OXXniDStauNBuk0eCT65bRW87Mog05fTZLqOZOJLBthXbriqffkj5qf yz5r1v8ALfzoEg85zXcl7DrT1H6YSUkpJzcmrhBRFFBxHEAFWxVkX/OUf/kifM3/AEY/91C3xVlX 5T/+Ss8m/wDbD03/AKhI8VeVf85Hf+TT/Jf/ALbh/wCovT8VZv8A85HaVeap+Snmi1s4zLOsENxw UEnha3MVxIaDwSJjiqY/kjrFhqv5S+U57KVZUt9LtbObiQSs1rCsEqNToQ6HFWN+Xok1T/nJTzLr Fk/rWej6Bb6PeSrui3c1wtx6XIbFkSP4h2OxxVCeavK+n+f/AM1vNXl6+/3ktPKtvp4f7XpXF7dt dJMFr9pTbxMNv2cVYD+WeqeavNGi235IazBLDcaBfNH5mujXidFs3V47cPt8U0pWJaf7qFcVZL+W PDRP+coPzD0FVEUOo2kOoQqo4oSBDJRen/LU3TwOKsC/5x7/ADR0byR+VF8LqGW71C61m5a0tYxx Vgtpagl5SOKip7VPtksWglnnsaiObVm1kcMd9yWBTXZn1Ca6ICGeR3I6hfUJr91c6DXabxNPLGOf Dt7xydZ2TrRg1mPMeQnv7jz+xmf5V+cYPKfm+HULsH6jPG1relRVljkKtyA/yXRSfbPNcU+CVvtf a2jOpwGMfq5j8e59U2etaPe2Iv7S9gmsqBvrKSKYwD4tWg+nNkJgi7fO54JxlwyiRLup4D+fP5ga ZrtxaaJpE4ubSwdpbq4jNYnmI4qEYbMEUt8Q23zB1GUSNDkHs/Z/s6eEHJMVKXIda/a8duGqwUGo A3HgTna+zmnMNPxH+M38HgvbbWxzazgibGOPCf63M/oHves/m/5m0DV/+cb7S10y8WebTjpltdQH 4ZY3iURnkh3oSux6HNbqcE4ZyZD6iSGjTZYSxARPIB75+Vf/AJLDyh/2xNO/6hI8LIspxVg+v/kl +VOvXbXupeWrRrx25vc2/O0lZ615F7ZomLe9a4qoaR+Q35S6TqUGp2nl6Nr+2dZbe4uZ7m7ZHQhk ZfrMsoBUio8MVZvf6fYajZzWOoW0V3ZXC8J7adFkjdT2ZGBUj54qwy1/JD8s7MsLPS5bWByS9pBf X8Vq1a15WyTrCRv0KYqy7StG0nSNOi03SrSKwsIV4xW1sgiRR7BKUPviqT6L+XXlPRdev9e023uI dW1Qo2o3DXt7L65jBCeokszxtwDELVdu2Kp5qWm6fqdhPp+o28d3Y3SGK4tplDxujbFWU7EYqk+p +QPJ+qeV7XytqGmR3Og2McMVnZOzkRLbJ6cPF+XqAouwblX3xVB6P+VPkTSdSt9TttPkmv7Ov1O4 vru7v2gqKfufrcs/pmn8tMVT/WtD0bXNOl03WLKHULCYUltrhFkQ+BowO47HqMVYnbfkj+WltEbe HS5VsmrXTzfX7WdD1H1VpzBT24YqzOysrKxtYrOyt47W0gUJDbwoscaKOiqigKo+WKsXsvyo8jWX mqfzZbWdxH5iul4XOo/X79pJEAUcHDTlWWka7EU2GKovzf8Alz5L84NaP5h0xLyexYPZ3SvLBcRM CG/dzwPFKvxAGgbrirfmL8v/ACt5k0BdA1yC4vtJWnK3kvbwF+Lh19WRZhJLxZQRzY0xVHeXPLOj +XNMh0vSI5YbC3RYreCW4uLgRxpsqoZ5JSoAPQYqlPmn8rfJHmnVrHV9dsprvUNMcSafMLy8hEDg q3KJIZo0U1jU1A6jFWTRW0UVuLccniA40lZpWIP8zSFmb6TirCh+SP5ZJczXNrpD6e9weU8en3l7 YxOf8qG1mhiP/A4qyjy/5c0Ly7pqaZodjDp9ihLCCBQoLN9p2PVmPdjviqA0nyH5Z0nX77X7GG4T VtT9P9IXEl7eTCb0UKRc45ZnjPpqxC/Dt2xVMLPy/otlq+oaxa2ccOp6qIRqN2oo8wt1KRcz/kKa DFUmvPyw8k3fm7/GEljKnmQoIjqMF3d27lAnphSsMsaEcRTdcVfOX/OO/wCXGled/wApJ7e+mktm svMFzJHPCFL8XsrUOnxVA5UU/Rjj1stPMkC7DDLpY5ogHoU9/M/8hodE0RNU8r/WLtLQMdRgmZZJ TH19VOCp9n9oAdN+xzZ6Dtc5J8OShfL9TrtZ2aIR4oWa5vHIphTi/wBDf1zF7V7A8WRyYtpHmO/3 eb0vs97Yfl4DDqAZYx9MhzA7j3j7R5qoZCvLktPmK/d1znD2Nqga4D9n38nuI+1HZ5jxeLH7b+VW sedR9j4j49vxzcdn+zkuISz7D+b+s/qeX7Z9uIcJhpbMj/Gdq9w5376rzZn+Xv5ReYPOkFzeRyCw sYgRDdzozLNNX7C0INB+029OmdDq+0MenqNWe4dA8Dp9HPPcifiepQv5oflBrHlD8vdZ1PWJYZJP XtLayNuxdGV5eUjnkEYEcFA27nNZrO0o5hGML7zbsdJoZYiZS+D6p/Kv/wAlh5Q/7Ymnf9QkeYbm FlOKuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV2KuxV86/wDOGn/ksNU/ 7bc//UJa5h6j6m7Hye63Mxht5ZgjSmNGcRoKs3EV4qO5PbKYizTMmg+NNH8sa75q85nSVga31C7u He8EiFfQBYtK7qeJASvT6O+dzlzww4uK7iBt5vJwwyy5OHkSfk9Lk/5xf1YT0j16BoN/jaB1f2+A Mw/4bNUO3o19Jv3uw/kc/wA77Hk+q6PdeW/M8um6nCJJdOuAs0RFVkRWDAivVZEoR7HNxjyDLj4o /wAQdZPGcc6l0L7Wso7SO0hSzRI7RUUW8cahECU+EKoAAFM4ORNm+b18QK25PIf+csv/ACT91/zG 2v8AxM5Zg+pE+T0z8q//ACWHlD/tiad/1CR5nOOWU4q7FXYq7FXYq7FXYq7FXYq7FXYq7FXYq7FX Yq7FXYq7FXYq7FXYq7FXYq7FXyD5H/Lj/nLDyRpMuk+XLW1tbGedrqSN5dPlJldEjLcpGY/ZiXbK 5YxI7s4ypkX1b/nNfws/v0vI+BHuZcZUv0Z/zmb9Z+tehYfWuHp+vx0r1OFa8OXXjXemHwhVb0ji 3vZV+rf85r+Fn9+l4PAj3J4yl0nlT/nLmXVv0vLp2lyaoEWMXjx6S0oVCStGIqKV6jLBYjw2eHut rIjxcVC0x+rf85r+Fn9+l5X4Ee5s4ykfnHyH/wA5becdEfRdftrW5055ElaJZNOiPOM1U8oyrYY4 gDYQZW+m/IelXuj+R/Luk3yhL3TtMs7S6RSGCywW6RuAw2NGU7jLWsp7irsVdirsVdirsVdirsVd irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVf/9k= + + + + + + + uuid:c63b31d6-45fe-11d8-8e7c-000393cd9a96 + + + + application/postscript + + + + + +% &&end XMP packet marker&& +[{ai_metadata_stream_123} +<> +/PUT AI11_PDFMark5 +[/Document +1 dict begin /Metadata {ai_metadata_stream_123} def +currentdict end /BDC AI11_PDFMark5 +Adobe_AGM_Utils begin +Adobe_AGM_Core/page_setup get exec +Adobe_CoolType_Core/page_setup get exec +Adobe_AGM_Image/page_setup get exec +%%EndPageSetup +Adobe_AGM_Core/AGMCORE_save save ddf +1 -1 scale 0 -148.752 translate +[1 0 0 1 0 0 ] concat +% page clip +gsave +newpath +gsave % PSGState +0 0 mo +0 148.752 li +254.868 148.752 li +254.868 0 li +clp +[1 0 0 1 0 0 ] concat +54.9161 147.252 mo +1.5 147.252 li +1.5 1.5 li +54.9161 1.5 li +54.9161 147.252 li +false sop +/0 +<< +/Name (PANTONE 7506 C) +/0 +[/DeviceCMYK] add_csa +/CSA /0 +/TintMethod /Subtractive +/TintProc null +/MappedCSA null +/NComponents 4 +/Components [ 0 0.05 0.15 0 ] +>> +add_csd +1 /0 get_csd +sepcs +1 sep +f +7.82032 17.3956 mo +12.9034 12.8946 20.6797 13.3624 25.1856 18.4405 cv +29.4395 23.2481 29.1768 31.1573 24.5225 35.4014 cv +19.4395 39.9131 11.2784 39.8477 6.76954 34.7637 cv +2.26661 29.6758 2.73926 21.9004 7.82032 17.3956 cv +cp +11.7549 43.3096 mo +12.2579 48.5938 li +16.7979 48.8663 li +17.9268 43.7178 li +20.3682 43.4747 22.7608 42.7344 24.8936 41.4756 cv +28.8946 44.7803 li +32.2999 41.7657 li +29.4512 37.3243 li +30.8975 35.3721 31.9356 33.1631 32.5196 30.8428 cv +37.9678 30.3233 li +38.2413 25.7842 li +33.0137 24.6417 li +32.794 22.21 32.0909 19.837 30.8458 17.6924 cv +34.1573 13.6866 li +31.1416 10.2813 li +26.8135 13.0518 li +24.8252 11.46 22.5674 10.3506 20.1846 9.75684 cv +19.6973 4.61329 li +15.1592 4.34083 li +14.0616 9.35645 li +11.6202 9.62598 9.22754 10.4092 7.04786 11.7168 cv +3.06153 8.42383 li +2 9.36426 li +2 15.0967 li +2.42969 15.7667 li +2.27442 15.96 2.14551 16.167 2 16.3663 cv +2 42.168 li +5.16114 40.1416 li +7.12208 41.6631 9.37012 42.7315 11.7549 43.3096 cv +/1 +<< +/Name (PANTONE 301 C) +/CSA /0 +/TintMethod /Subtractive +/TintProc null +/MappedCSA null +/NComponents 4 +/Components [ 1 0.45 0 0.18 ] +>> +add_csd +1 /1 get_csd +sepcs +1 sep +f +19.8682 23.167 mo +21.6221 25.1495 21.9336 28.1055 19.6426 30.2452 cv +17.7315 32.5264 13.9385 32.1124 12.1084 30.046 cv +10.2051 27.9034 10.4053 24.626 12.5489 22.7256 cv +14.6924 20.8213 17.9698 21.0293 19.8682 23.167 cv +cp +24.5225 35.4014 mo +29.1768 31.1573 29.4395 23.2481 25.1856 18.4405 cv +20.6797 13.3624 12.9034 12.8946 7.82032 17.3956 cv +2.73926 21.9004 2.26661 29.6758 6.76954 34.7637 cv +11.2784 39.8477 19.4395 39.9131 24.5225 35.4014 cv +/2 +<< +/Name (PANTONE 871 C) +/CSA /0 +/TintMethod /Subtractive +/TintProc null +/MappedCSA null +/NComponents 4 +/Components [ 0.3569 0.3608 0.6353 0.1882 ] +>> +add_csd +1 /2 get_csd +sepcs +1 sep +f +42.0054 124.904 mo +38.6949 132.106 29.9537 135.87 22.7505 132.561 cv +15.5523 129.245 12.4058 120.72 15.7144 113.527 cv +19.0259 106.334 27.5503 103.179 34.7427 106.488 cv +41.5435 109.62 44.98 118.187 42.0054 124.904 cv +cp +52.1324 108.189 mo +46.0132 109.425 li +44.6382 106.935 42.775 104.731 40.4371 103.029 cv +42.0914 97.1954 li +37.271 94.9756 li +33.9527 99.9629 li +31.0816 99.1973 28.1519 99.0762 25.3277 99.5635 cv +22.3921 94.2989 li +17.4175 96.1416 li +18.6011 102.011 li +16.1207 103.443 13.9351 105.404 12.2232 107.825 cv +6.41944 106.179 li +4.2046 111.001 li +9.19288 114.318 li +8.42237 117.192 8.30616 120.126 8.78467 122.94 cv +3.52295 125.882 li +5.36475 130.86 li +11.2349 129.672 li +12.6656 132.151 14.6226 134.34 17.0562 136.049 cv +15.4068 141.854 li +20.23 144.069 li +23.5582 139.057 li +26.3648 139.764 29.271 139.844 32.0865 139.344 cv +35.1089 144.747 li +40.0816 142.907 li +38.8687 136.883 li +41.3609 135.473 43.5679 133.563 45.2554 131.213 cv +51.0806 132.864 li +53.2984 128.045 li +48.1685 124.64 li +48.7964 121.878 48.8687 119.031 48.4048 116.281 cv +53.9722 113.169 li +52.1324 108.189 li +1 /1 get_csd +sepcs +1 sep +f +25.3804 126.851 mo +21.3306 124.99 19.5601 120.199 21.4234 116.152 cv +23.2847 112.103 28.0757 110.342 32.1226 112.198 cv +35.8609 113.921 38.1509 117.934 36.23 122.414 cv +34.9371 126.865 29.2769 128.645 25.3804 126.851 cv +cp +34.7427 106.488 mo +27.5503 103.179 19.0259 106.334 15.7144 113.527 cv +12.4058 120.72 15.5523 129.245 22.7505 132.561 cv +29.9537 135.87 38.6949 132.106 42.0054 124.904 cv +44.98 118.187 41.5435 109.62 34.7427 106.488 cv +/3 +<< +/Name (PANTONE 1805 C) +/CSA /0 +/TintMethod /Subtractive +/TintProc null +/MappedCSA null +/NComponents 4 +/Components [ 0 0.91 1 0.23 ] +>> +add_csd +1 /3 get_csd +sepcs +1 sep +f +51.919 34.2159 mo +50.1553 34.3702 48.4336 34.6612 46.7647 35.085 cv +45.0293 31.7598 li +41.462 32.9639 li +42.0958 36.6563 li +40.4815 37.3428 38.9317 38.1573 37.4639 39.085 cv +34.7881 36.46 li +31.7666 38.7081 li +33.5157 42.0323 li +32.1993 43.1778 30.9776 44.4268 29.8624 45.7686 cv +26.5 44.0938 li +24.3194 47.1651 li +27.0049 49.7813 li +26.1094 51.2696 25.3331 52.837 24.6817 54.4659 cv +20.9756 53.917 li +19.8526 57.5108 li +23.2159 59.169 li +22.8292 60.8477 22.5831 62.5772 22.4659 64.3418 cv +18.7579 64.9659 li +18.7999 68.7315 li +22.5225 69.2696 li +22.6778 71.0323 22.9639 72.7549 23.3868 74.4249 cv +20.0635 76.1573 li +21.2667 79.7266 li +24.959 79.0928 li +25.6456 80.709 26.46 82.2569 27.3887 83.7256 cv +24.7627 86.4004 li +27.0127 89.4219 li +30.336 87.6729 li +31.4795 88.9883 32.7305 90.21 34.0713 91.3243 cv +32.3975 94.6895 li +35.4698 96.8663 li +38.085 94.1827 li +39.5743 95.0782 41.1387 95.8555 42.7725 96.5069 cv +42.2208 100.211 li +45.8155 101.335 li +47.4737 97.9708 li +49.1524 98.3584 50.8799 98.6104 52.6456 98.7227 cv +53.2696 102.43 li +54.8282 102.401 li +54.8282 90.2071 li +50.5508 90.4063 47.168 89.4581 43.1543 87.2188 cv +31.6788 80.8194 27.5655 66.3292 33.9717 54.8516 cv +38.3282 47.044 45.9112 42.2872 54.8282 42.667 cv +54.8282 30.4581 li +52.4581 30.4971 li +51.919 34.2159 li +1 /3 get_csd +sepcs +1 sep +f +33.9717 54.8516 mo +27.5655 66.3292 31.6788 80.8194 43.1543 87.2188 cv +47.168 89.4581 50.5508 90.4063 54.8282 90.2071 cv +54.8282 73.5127 li +54.4903 73.5616 55.1485 73.5948 54.7969 73.5948 cv +50.8213 73.5948 47.5987 70.3731 47.5987 66.3975 cv +47.5987 62.419 50.8213 59.1944 54.7969 59.1944 cv +55.1485 59.1944 54.4903 59.2286 54.8282 59.2764 cv +54.8282 42.667 li +45.9112 42.2872 38.3282 47.044 33.9717 54.8516 cv +1 /2 get_csd +sepcs +1 sep +f +3 lw +0 lc +0 lj +4 ml +[] 0 dsh +true sadj +54.9161 147.252 mo +1.5 147.252 li +1.5 1.5 li +54.9161 1.5 li +54.9161 147.252 li +cp +0.99 0.99 0.99 1 cmyk +@ +0 0 0 1 cmyk +%ADOBeginSubsetFont: TrajanPro-Bold Initial +%ADOt1write: (1.0.21) +13 dict dup begin +/FontType 1 def +/FontName /TrajanPro-Bold def +/FontInfo 7 dict dup begin +/Notice (Copyright 2000 Adobe Systems Incorporated. All Rights Reserved.Trajan is either a registered trademark or a trademark of Adobe Systems Incorporated in the United States and/or other countries.) def +/Weight (Bold) def +/ItalicAngle 0 def +/FSType 8 def +end def +/PaintType 0 def +/FontMatrix [0.001 0 0 0.001 0 0] def +/Encoding 256 array +0 1 255 {1 index exch /.notdef put} for +dup 67 /C put +dup 73 /I put +dup 83 /S put +dup 127 /Nsmall put +dup 128 /Tsmall put +dup 129 /Esmall put +dup 130 /Rsmall put +dup 131 /Ysmall put +dup 132 /Ssmall put +dup 133 /Msmall put +dup 134 /Osmall put +dup 135 /Ismall put +dup 136 /Usmall put +def +/UniqueID 45714 def +/FontBBox {-248 -284 1528 985} def +end +systemdict begin +dup /Private +15 dict dup begin +/|- {def} def +/| {put} def +/BlueValues [-17 0 750 775 638 660] def +/OtherBlues [301 305 405 408 -261 -256 -222 -209] def +/FamilyBlues [-17 0 750 767 638 656] def +/FamilyOtherBlues [301 305 405 408 -273 -255 -214 -209 -252 -239] def +/StdHW [47] def +/StdVW [118] def +/StemSnapH [47 55] def +/StemSnapV [118 126] def +/ForceBold true def +/password 5839 def +/MinFeature {16 16} def +/OtherSubrs[{}{}{}{systemdict/internaldict known not{pop 3}{1183615869 +systemdict/internaldict get exec dup/startlock known{/startlock get exec}{dup +/strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse}executeonly]def +/Subrs 5 array +dup 0 <1C60D8A8CC31FE2BF6E07AA3E541E2> | +dup 1 <1C60D8A8C9C3D06D9E> | +dup 2 <1C60D8A8C9C202D79A> | +dup 3 <1C60D8A849> | +dup 4 <1C60D8A8CC3674F41144B13B77> | +def +put +dup /CharStrings +14 dict dup begin +/C <1C60D8A8C9B6D5A0DEDEC57B918D61DDFA401F5A49FEA3B89C6864173301 +6BDC674395116B42D2387AF24DF2F1DC60C61A5B6585CC0DA86F050A110B506B +B65171C092F0636620BAA275DBDEA04B3E655EC58BDFB8B9B535650BF4DE0E82 +1C2ADFD8C9F649E0C395722C228833505318AA21D61F3D55D035246FCF9BC983 +692D83F8C9AF492468B91F4CB872C7D1953185BF38A8E7A5B72C7F51E36572D3 +718D9C26EEF5DDFAB02F3E79248875F4CA6CC06F7C289C017B388B2CFE4B85A5 +1B0090> |- +/I <1C60D8A8C9B77771C05B04C6A1CDBDED73825D1016AD1A9F739BE3AE28A3 +2F89A16FA0ADB365C478020BF11BB9ADC332932373DC2832A2FD54E961E2B084 +4B0EB81447C317CA2A36F9297140F653C6CF38B651D9BF313FA9254650245A3A +6E604D8E9EFFEAAF12423E3B4CFD19A9AFAFF5FC58BD3FF4189B6F8AF938C510 +BD91FB49103F7E5C2AE8440096A8B2CFB59E1B448BD934D6C96663C7ECAD3789 +1B4FEEBF9172B6A7CCC0965D9AA12297E39BBF30EB7B8F6243DD70D9185FBD81 +8CFC74B60F41E69C4533165A53D5C2FC5A9B44BA5F12F31CB79A71FA4F70F551 +E84E63E5837361F7B7736F91> |- +/S <1C60D8A8C9B7F51B95A0DFD92CF0B9552EA2D8DB80CD668D35E3A70F4576 +D4238E8EEA2F046EF8BC16C7785D1607E04A62100A5AFF084F37B544AFC2004C +0BC4AE1356D2B0EC8700AB99117F620401AEDDDFA69D53F0F4E5314303A9C779 +D85053ADE7DEA169C445735EBAC333F65F31A077498B479248885315A58C9DAE +7AD6ABA3F9562E1A36EA3EA3274E191D557F04A6CB9FA3B240660C95B31FD1EC +ACE3874E2F240022DE09CA2256274ED580EE94FBAA5793BD5F9D37682BE7C541 +ACC5EE4D95FB35149493D2CCA9BEA729ABD0DCEC9C95E902EA9DD124CA919CBA +F3364C7699DDBE268B46D54393CC359D98EA67700B83CEF348489F1F90A16D> |- +/Nsmall <1C60D8A8C9B6BC88BD85FE8659C453EEEB8E1BD03325A00213B3F3D +4D450DC128DD37CC24C857B6D60D557A08CD43D812DF35B5BD6760576A63576C +506A238602F1E6EA5D2CF18DAD28B193AFC0FA899C7F243B47EAB7B8460C0CB0 +4242476B1602C4D8E3342E27EB421C00D297126C6E43889F0137C7A1C441FC72 +2BE08EFEBABED7A59A7395971A284A820995BDAAE7D9478AB8745D9C9402C363 +B7514AFE9E3D0AF6A39663E1D555B5F7BDA2CE94F32DDC1E19216692DC849907 +7A3E6206E838004DD8DB4A986C8F31EDCAB6E6B82F722A0EF26221ADD2189144 +83D5E5F90B6CEB939F64EF523B4531C4C0B4ED4F521923EBA94C1FE7AE3B2648 +AB7B1D48BCD570F1DED35E03DBB412CF55B5989A09E378971DDF42BBC4FD1669 +7B92AE130992922E13408AB712F27D256F7305A6C6B07A0AD7C13FE23EFB63CE +65111A1A787D3875B8B8D9507C694904CE3BA8114CCE10FF99A55> |- +/Tsmall <1C60D8A8C9B66C0E1D18F4614EAB544F0CEC538C8C01A016933AA12 +429EBE5390D596C5F67CFF90C2108DEC0E3557EFE47A84AD0A504C83D7E8F287 +5DCBB9233950E37680119C5422B9BA74EB5E3A2AE4E2F090670CEE3CC015972E +6CE8DF50DCD73A5ECEE824E6627364F3B83B1B73833AA7E396445D318F119C4C +5EA2429D5B49B0EDBDDF4808A5790BF8CDC63B184CD3A9CE7C22C4D23ACC081C +FF7BCA42342880880724EDF5A0F6F9059ADD736C441B65FC95D81D78B14BCAE7 +32E0959A4FEDBBA605D7DB559BC1CFFED39160EF11111F189C967E86115A679A +21BB269B7452490D7C600719A2B02BE0A92DC8D7E101DFFE6011D579AD666FD2 +6352E7C3F88546D427880A3ED55A53668B9B911F227F478005846196CB2A821D +9436A361DD997E24624546B193AD16A013BF60C83D456FEFAB524A4C3C4DAF51 +640204EE51B9A6B98D186E77DE45F4BD3696405A93E6DE14A3A251AC1EF6440B +3F074B20C4913F3447DE56969C6BBDB2354148031166D8E9781263F94442062C +991765ADD918972AAE466DE6B9C6E0991428CD75BCCEE> |- +/Esmall <1C60D8A8C9B7FBE1B006E95A68A3EFE857D335EDE0BE9AEA4BE7F95 +2FA0109C6CB803A7F2B985E7BDE818880C9FD186C7136A63CCA57CEDB6AF2828 +DE38E8685BB8771E2988A810F73E0345E8908310C31FD0F7C222F54500389519 +240356E338A96366351A20F484B5651422D1A0FDAE927D548045766A19F6150D +CC390EA0D98D6C0EC5E1C97E0B4512533CA015299550D65A6EA9A741DBD81A7F +575EC26534A2210CD8BC3335B163A776277B6F29843653C092C384FA226EA0E5 +F40EBE1799B10828B444468B3DA053A6ABB46879088C5CDBC46D899C794B325A +A3C97D044BB760BC39839995FB64819C682832A40321F78B99C09513B805CEC3 +996F9F6C14C0DA278CFDCC8EE83409A0C9BCAE8289E42BA209582E05976E48A0 +66222F364CA72855AA1A8DD971B9E012D88EC883F11B6B8DD1F7A3A1A193533F +B42207516FD3B0F5443A7865F511A1795EBD587D37DBDF03F04386AD8496835A +76A8A2EA2B1821C0A26A3284A32DDD223178AF712B0015CA9C866D881702FB56 +88AFCD83EBB5B8B70C983ADB28C933F563180B2F5D693852DE904FE07D55275B +BF14C6F4184BD1B4A9AECA29C644CB5A0BE9622ABA21F24CFE079641418F3570 +3415A4A73F296C050FA68AD25A13C7E948BFB4A1F5816B4ED0207AE7F70F6A21 +CEF402873ACC39E699949E03BE7A042549D2AB51127EAC04572696553A61D3AD +7A50684611A83B8CC45B07DFB59CE66FF4633DDD79F> |- +/Rsmall <1C60D8A8C9B6232B67C2503515E3E19A361BD6B49811E165A598B41 +3BB79166E3FDF489EB666983D5C7D39CD639562A5B5DFFD54539B03730F39196 +01122BFF4EFD30EC733326ACD5E99E075E6AD0B22300446FDA3039558CE7D82F +A6C33C70F1D07536B16D4B1DC2398D650AD9DE1FE1EEF9FC8801CF7C62691F3D +44ABC62967E1B752BCC2F000EEC07286667F57839EF2E6B9C04C2DA9F22FCE01 +4B7A5598EA7A603107AC2DBC5AB39CAF9666BA8BD1E17DD88F1B0183C4C1C3F1 +1214AD45BA4F39EED6AE5D1943AADDA9D1EC079FB2B1E8FDACACF0141DE87287 +5FA936F561AD9761380B6FCDEE2C83C4F292D6BC0EFBBEBA1571BC78DB7E53A3 +C2355971E9941081B36BC438EEEB16D9D4B14BD1644AC5E58981D2AC452FD6A5 +580957C704505040E5A864423A1DEC798AD589C92753FF4E99FE4D12AC55E99D +5F0AB1E5E4B10AE2F480F509E7AF89EE8CEFA0BA716FB8CEAE96307008D32070 +D365B7F6583B829884DD2FE6EB7D95965527303A93BC3BED5A9AD904DA3DA> |- +/Ysmall <1C60D8A8C9B7CDD8BD7DBD65E184B9680768C945EF501FFBAF34DB2 +EB89B7C35DCB2E8CDE46F9D37FB471E35DF335DEED86CBC9BD25ACBBBE505717 +85D55C56B45ACC3A263ED736CAA051A570F787892A1CB6821A2FFAD018F8067C +A681AE9EC8078E3C7AFE94C42C7FD5A558E11749ACDE333C8BDC9884D4FA3DAC +AE8A34DD32D0843E9B8D09766739B4ABA55282A00532DD1F8B6DE1183006D340 +67C1700BABA7CDD73E0CDB5BE2DDAE32FBEED1C6D7EEEA3B5CEB4C4205571F0D +CF1A506D8FC5DC8499A45715F34A9B98FE00C59CEE5F28BBF36D76480FA97A6C +7DA2BD1F5844A8385287554D6A25D036C1B44B3D155C43934FF8AA5F5EFA8691 +C8A756E6E6312D494BA1468BA6D0686CD0C8B3FDB8C0351FA65E6040F976F25D +799285A835570C29A2FB34B27E1A794353E610FC2C4A30406992C247A28AA7F6 +E944BDFAB0BBA11598F8F567A868E003F8F3944F74A873C0B590A5CBD543024C +D6E3B83887E8B4201> |- +/Ssmall <1C60D8A8C9B79FB048C852057885B7FB39D71FC3016435158EC7538 +3A43C835122312509B1BFED76A61F209ED65A42B34BB62984E18488BC60B5218 +01752FF5C2563FA0352A4574582BF27E08DA350B6E25230194888F1FA389A5D9 +3FBF39576DDF170A31E4F9A79349B244BDF70FC82577F5D740926CBB4F2ACA8D +2425F341518CF5F38A11D5613BD07DDED6A6C9CC2A89D2BA18004761AD9B9FC3 +4EDA3D0BA2574B07F9B17535C3DFBDB872ECFEEFC15F4D3F7BCA04E0B730A15B +DD0D5BCB061E10476825BE14CC3CD57D1B8CD428D2118BB782F85F1A67B39448 +980A962927A8E8DBBBF65E6278D0AFECB529564B170722C87DEFBDB> |- +/Msmall <1C60D8A8C9B5BDB4869BB7396C2BCC7E2D035A8DDF69463A769AD1A +A49DB431BF0660A482C35C477875AA9502C9E16D281765C1FE89158C85EF4F3E +57125A0E615EF95AE1B7077390D7D5D6DDBA63FCBAB687625D16C58A812887A3 +BF8B333347AF25B78756DD80DFD049480BBC5CC2E60C8AAAAAEC52485278ACB4 +CB64431DB98372ED33A1281E6970D65A9DEE7B405CB6932D27F2DFA40B98C2E6 +9A163099093F74C6495CCB4C78B91CF36A00F110217924E037A2F56731347A29 +95E8AFF22D6698D628918F5A55716FEBDE556231C95D2821D1B0DE3CCFA65E60 +C9DDB56BAFC7C7328AEA86A4824D8004029A0A0834D297E9E2EE5DAE0DFFB8A2 +CC6F17A3EDC65> |- +/Osmall <1C60D8A8C9B6AE36D8AFC06EF7691CEA7388408CB5711A90AA9C8BB +7DF107C83E9F4C9D93C2707EED4FFD917928C910BF7966EA41381731C2EDBAD2 +707004603AE29A600E85B2D80CC1F8253013508BECCA2FDAB8779E3B7D43916A +0E2CE1B80BB3DF3> |- +/Ismall <1C60D8A8C9B704CCC403F91AADD9CB2F76DB90BC6EC90EF3D45C6A9 +10C33779B027A5893F399469312EDD288FF0EA2B3848F5A530D7C0162C275993 +6728784ECB91933A5B31FC0120544923268E389858466EE39EB2181D57CD3BF7 +07FB3669BB94B89A418CD729CFF5FBF8DC7045D58C25F7CB07F19116123D927E +59434BBF93B4FE5DBF40C126B117E6B60590BBF45DA98B6DE8B19144213326F9 +87495E510476E3585AE1A21D73828E47A902A177877DAAAB4C0EE1255BEF7F14 +75F7B919B37EA781F4D15EE851B6A63CFE7192BA2E00BB3BF61621837B8C6E3E +7AB8CE9EC58E9FFE71C29175C76E5> |- +/Usmall <1C60D8A8C9B6ED055F5BB1EE84E1A93ADDC8E7C125E88D8FF53587C +17D959293900B8FD46371B21619962E4E05301A5E3EA5963AEEE83B21393A2AB +3695359695D60CA9917C3B4C055638C566E55787F9201E25FB6F1ED940BE5C4D +321EC5E70BC368233DBA0CBD12DA827A229D0CC8A349901F7F6297A8D2B5EE1C +32919F009B7DEC73D0710E8891AA9A0D36238E9E944FAFD91D10D63C6B88D5BD +C3A7985808BE85B22B832353DB0C8315F69AE576B8073207A5E9FE25F5A1E4F5 +9C748E9F7D4D5B9763098CB580B40B6CD00897D0384713B624EAD8EE1E24E326 +A2BE8083CCA899DE1FAB4FB90AF9AEB63CFCC24D405FB6596CE1D598C7EFABAD +D016781F1785ACBA6641462356572572D87FF66C89B7A4AFB38B24B24E1E7B07 +44FD561E659DB89FDAA3D90E0980DCB66> |- +/.notdef <1C60D8A8C9B7A73DC56ED86593A26411A239A9F576A4BB06AD4079 +CBD73625AFEDCD129CE8B573E3C4C05A38ADB9D43C2E751D7FE69FF5F6F4BCAD +D50244964753D5C819FE275F32A27920BE3EA3D1AFD957ADA922B28CD2CD8E15 +58DDDC89C143A1> |- +end put +end +dup /FontName get exch definefont pop +end +%ADOEndSubsetFont +/FDJFDP+TrajanPro-Bold /TrajanPro-Bold findfont def +/FDJFDP+TrajanPro-Bold*1 +[ +67{/.notdef}repeat /C 5{/.notdef}repeat /I 9{/.notdef}repeat /S 43{/.notdef}repeat /Nsmall +/Tsmall /Esmall /Rsmall /Ysmall /Ssmall /Msmall /Osmall /Ismall +/Usmall 119{/.notdef}repeat +] FDJFDP+TrajanPro-Bold nfnt +FDJFDP+TrajanPro-Bold*1 [32 0 -0 -32 0 0 ]mfnt sfnt +63.709 49.9312 mov +(I) sh +FDJFDP+TrajanPro-Bold*1 [26 0 -0 -26 0 0 ]mfnt sfnt +78.333 49.9312 mov +0.080658 0 128 0.288605 0 (\177\200\201) awsh +131.874 49.9312 mov +-1.83563 0 127 1.73947 0 (\202\177\201) awsh +188.218 49.9312 mov +(\200) sh +FDJFDP+TrajanPro-Bold*1 [32 0 -0 -32 0 0 ]mfnt sfnt +63.709 85.9316 mov +(S) sh +FDJFDP+TrajanPro-Bold*1 [26 0 -0 -26 0 0 ]mfnt sfnt +81.7983 85.9316 mov +0.213654 0 132 -0.177307 0 (\203\204\200) awsh +127.864 85.9316 mov +-0.0141907 0 133 0.276245 0 (\201\205\204) awsh +FDJFDP+TrajanPro-Bold*1 [32 0 -0 -32 0 0 ]mfnt sfnt +63.709 121.932 mov +(C) sh +FDJFDP+TrajanPro-Bold*1 [26 0 -0 -26 0 0 ]mfnt sfnt +88.9883 121.932 mov +(\206) sh +109.841 121.932 mov +(\177) sh +130.882 121.932 mov +(\204) sh +144.271 121.932 mov +(\206) sh +165.124 121.932 mov +(\202) sh +182.77 121.932 mov +(\200) sh +199.487 121.932 mov +(\207) sh +210.59 121.932 mov +(\210) sh +230.869 121.932 mov +(\205) sh +%ADOBeginClientInjection: EndPageContent "AI11EPS" +userdict /annotatepage 2 copy known {get exec}{pop pop} ifelse + +%ADOEndClientInjection: EndPageContent "AI11EPS" +% page clip +grestore +grestore % PSGState +/FDJFDP+TrajanPro-Bold*1 ufnt +Adobe_AGM_Core/AGMCORE_save get restore +%%PageTrailer +[/EMC AI11_PDFMark5 +[/NamespacePop AI11_PDFMark5 +Adobe_AGM_Image/page_trailer get exec +Adobe_CoolType_Core/page_trailer get exec +Adobe_AGM_Core/page_trailer get exec +currentdict Adobe_AGM_Utils eq {end} if +%%Trailer +Adobe_AGM_Image/doc_trailer get exec +Adobe_CoolType_Core/doc_trailer get exec +Adobe_AGM_Core/doc_trailer get exec +%%EOF +%AI9_PrintingDataEnd + +userdict /AI9_read_buffer 256 string put +userdict begin +/ai9_skip_data +{ + mark + { + currentfile AI9_read_buffer { readline } stopped + { + } + { + not + { + exit + } if + (%AI9_PrivateDataEnd) eq + { + exit + } if + } ifelse + } loop + cleartomark +} def +end +userdict /ai9_skip_data get exec +%AI9_PrivateDataBegin +%!PS-Adobe-3.0 EPSF-3.0 +%%Creator: Adobe Illustrator(R) 11.0 +%%AI8_CreatorVersion: 11.0.0 +%%For: (Douglas E. Appelt) (Mad Doug Software) +%%Title: (Alternate-ISC-logo-v2.eps) +%%CreationDate: 10/22/04 2:51 PM +%AI9_DataStream +%Gb"-6CMtIYE[^blnitWj!HrIdV0lorEFGN3p=d2AK:U\*q_!hY[_$iT*gP5UX1]SSqSRQ?_'$)V>TY%qP`SMZ@PZ&5]GQS5IeD7R +%m`Y!QleGQ7K.p&6?3aPlR\_,pU'rp&CDDZ00VZam^DTYCI"bGS,pf>eC0p"$ku^->l[*"R8fVlPU'FAYD. +%pH<]YO.ZB_I5g)6.fSi&qjT5\No0V,*'aApjM1[&?VKA;s5+k>*rNhPC\4:.?Tp^0SRbF/qI]^'n%Sf"Iau[8YhK*1=8[PW@95Bj +%feh2gC0m5p>Dk5X:Z"Oie +%_>('6rT`ihmf%TV6aJF?pEP/0^\r2;05#YbIeS'\a5_%#Z`D +%M#tCQSj(t84WKTq]6a,!Z/=Ac38STd5'sfM!j\oF_"j]3hd,(Bg28!D:rMsrhk/^7$3khgXInb)kR&(e;*iD*,)s5!YHLWE;hFu@_jloh"cpiZ.#*V2om4is<'4&SdBk2#Kl=D(W,jr6[thj\_UF8BI"+-&1Xoq"0D1+W8Dh:JnpT+i +%?bp*J"_3/!:^b8g,Gjj:7.;#X^kgo%N*@Djcbc(-0AOC"i%MH*E2&Y,7.;#4%A-H(@tJn;2!Os8$cW@"U!DTsAMQKsF+Q,4Oe;i, +%kt)dRoq)"TIA=8=cXi-4#5pe=(a&[0Q=pJ:eFXd+(jnY%(n]#+6%tnan\JSBK@/*E_dD[hPe^Y)"lk6M1lI#5"BTn6]MWVJH7nt; +%F%6*QW'`.gS%s_I:;)FS;nqP0e?[:7eW:lO"/?ORK[IWb1huk&`Wq!e(?%32O'k<#_I'5DUT;*AbSJnUaO(q4]*3rnOg5*b&bcUD"n*]8_:'!OK[Sm3$^B[6 +%5`Z&2n8s>%6#pdm^#=2R9LnWSF!M=0COrQI(Rca192k+D=8^58KSZe<]Rr1otMX5/e. +%i[=]kpN.KAl),"U`6Vl[i%N>*h9-geqXLul[N?!kAp]o#p95J:So\,F?=@Y?r9HTE9mTU-eQ5>%g-7NM(++>09[hd@j04RP-UK1TF%c8k1lR(l6i1KQ.D>/ZiP77uF=:=.,l*oJ5h?SSg[%2rnj-9S%rs]G0#5Y%NI9>jRd)*Dm_=p:p6Ha4( +%%s]7ECC]5b_C2&frY,1V!dlA`)%DM2%tN!shJ!Ad=ANrJE#?0-pjfm:H\(YXcc>jYILn%7LGPCXK7=doF?NF3Tq-Amq6356p8p]/ +%6aLY9>CE'2qW-gq0ue!MF2[/GR +%ID^&7gH`q9k)StGE/[64elI6>-HA)u?IH9bK3#J6Y3dN$<6>cP#CnF3fQ7'/b18A51>EE4/c=%\dK7XPDtQBgl"Sm!\%$3Y`+g>^ +%phb4CTn#q_5Gi]fcCeRTY4"5qE(gL_B,hStRio_GnkVgFj:;#QGL.SM!pD(QA:T_K#IUb-.^[@YnKl!DO]%%E@$]M0nJRC?TJaO/ +%[/OG4$eMo?o)eM8UH$VVn0^Oaf&iE!L-:Ue^bO'_&jB#SoZSTJ1gB+)*ZLLtcG87`T*)j!Fq4E8\oG`8B]7Fc")p\s#s\DC1H6&Z +%^V)m8VOV"`D@n-.9Ri:D?2".%s#oN+DNk$.ZdGU'mT6QL,4qBY+@H[MF!OkpI7,gZ#I6AsAq1^9,N+OLJ_ +%0Uc_EnIin#3eBHQ$c%8\>ec#;QRRJ25F&?&^'+35b_\N[GM$P^0gZ\=Xp$HD=ZE^Y$$\,Fqge4XF^7(gSot56ST)P"8AU6<-)7,Q +%UpuHR/l2P/J=dI!&;Q>Z5h'uT%#cI\]flh6U9K+%qklsH<82S$i^Hu'LXNQmOTH#g)t?H/7.Z$'dRL#8OCRF`K,oY:V.i/9 +%6)H_q\\OhK#AX7.#W%%uFnAA(PN@jK0cnHeo(4+86'6O_)EI+eS)ToS`:0W?-MjmcVDF>)bc3-+I\o]2!?0a6sf"DnFd0hfJ5) +%\rN<5l"eD!!=b>g:hX64>lD +%i`;cm+I."DJKlOj`I80gcMO&DUHLk:Uti3!YmPSWJ0`AeoMEF;oMh?aKV!aA7%S/TP\ARfcOZbDd4]kh[C4_BbZ!$4@E+trFtD[Y +%JjO)n0TcLpVOTL6d`BmG(5\YKJ(H7+f#5moL'QgDl\XCe\.c9Y7emMN[R1WS&E\YX*rEF$ILt,.D8b;n1#3d.J)-X@/Vp+ZtJ<>D"11Z@q@ATG6L%WhJZTRLR+L/Zi,iT\cg0.(BXI7/.T$`VXDO5J0!,;0gilp_l^?ft$cOeN8]rFHV4KH5c.$C>L'c39Qq9D?s5N.7UUD!7#`V>hS`R7pP.&nB&VgH0O'61pfquQW9(N(dBXOB*5Nth7HqL%'4duc(9>$L^\o$7a=ck_HMh$i# +%U_*o&d28')d7gtLiXT!2b3)f(:Ab9oS^Y\CrcHUQjV/<9iG$odb.+72JK5HUV@"4Oeu45M\0cX&'5ItAGNeXIXkBQX2E9VG?LM53 +%CKeCbhf\7%kSMSsi+KF>#h5[;'N2HH[]=0C-EtO,g$UPR"maTmgp,MlBbrA4f^kY9;[:sA&NeecGlt/b"Q*&E7Z7Idl#mijK9L`g +%M[&hpCi6ju>86t'XOXQ4>L@2Mge2HoM:Qa0HfjEu*>RsKA^(RRNqTd2E`(FL#Rgqs3'Y"qfU3"_iutR%qi/B(m>?\$dOp0Rg=9ue +%1l7Q7BphR9il8ne78KT,**L+Plk=.OQ)n-gb-a"AQ8"Y^VGkjii-D6&3l"rNc+5U@F732Dc=;s!*\q3aT!J>rQ3O1h"^NO:8gGY) +%:snJ:C;h5G3n>@M^BLRTdVSQ[2EAj;efM-EmQ_a%g;"`1_J$=kpM+*KnI7)=&]%"8ViA:^+gp6j'fs3%H4VrOXW9fech-gF2?f+09bSrjX;81`e2)5b>9sNr +%Sj\lFfNjA\DD.;``k4=5K&ZX*Cun;HO#WaeO(*0e(gW`VPUjmI$^thg\cYj0T;!oOpSlAl)4nO=LN:;O4['aCP"O-AV>@Q0$`*dc +%n^,a"[3bTF[$M"kk\9_r;ao:Flh`A6P(k/\BA*_pqk9aLN4<(!,Lu*`ZE6PV&hZ[p7s%0J?-E.\)e)pS-epH/\=ti)io;3GAS*e9 +%?n%PAXKAnm/>LfI\tR#eh?/1hlk`mP+ma!'#U?N!`H`4nF,Y9EdX&m`,@t$_OOOi42m2)37!>F5C/LT52P*U_:0/>&4@k+Cc:K]M +%&/;@6ABkLn]ja:]&ab)FMtV-]ng8FliDD\;5slM]i2Apple@,k#IY>CV4reK?3L8]Db,J]lU[.'TemP=,K72KG!OdQ-o/QsJFs.$Jb'Q0XfDq'AX5Ds'oGR3d,LaU%1F78@74ZEh)W3pqF +%F]%_t66M/\_\F#Yef+'r0JfDs>b>N>8L>oW4@]\cZV +%U,PR.JR9'*ej4tgqL7/9ITO0H+;@XbU/:n2c#&GbY!;)/;VoThfae;,?)JuAT>%eH4_ps&m;G4>HRJd$]fUe7m:UG:r9""Hk3`KN +%0)UdfI!^89nu;Iae[`kQs)RjQr-Wqi_p*2_`lfIlYQ!Pf/u4j"&(ejKs39`MotCD%Er5k2iVM^!l>hCIrl`4Lo(N[H2]n'H?V@fl +%nrMad/#mWDX^,8H^V53tjn/**pn*mSYmrpHKoNj6`fKn*Fa9cQO6Y,&Gk@Gn^SX'DWm5acF,S:EQZlF'Np>K#\p'k9*HgHO;KS??`or;"?"koTf*I;9oWhqrkYq&]IT +%0-BVc4rd@"pHMq]+2[=rDXSW1*'[c4pQo6:^:F+<@hjkbh0f$G]"\+U/'6u#a4ned(L(-Up#P`4rkldODsI2m#lgO"5/7,<"#j-: +%b*V_Ss8C.21CWilh-Y%QO8o%Tk3@X"HL/4lIs'cn#Z#l]\au#SGN4H3I]AI,]8)m9a+nn0O>u+P>^q?fJ,XQ_rckuNa]L@)n]1Y" +%%WLM&KC@7MnUr!?a<&:PW8(4=GSeQ&nAFpK>Q]Q\TEU__9DIu9r>!T@rlb6\p(Sr%oGd8'\a&bG[3%)tLO\pW-i]dM%tGc^f9+AX +%I.d:P3f#`/lGJ[,?TrfNW@ld07JH*I2.=KgFDamIq(7m3T.U?Ln5a"Ond>hslih->ARn8ro!Hi3.!rKVl8qJMANo#!\>s4uikVrM\r^\;)5bQ+rJrU'JD#Vu8$lMEE6a%#k% +%l-`P@2"esZs1A<')Ya/+RU3*\h#7'Dh9V^ReXr;8@Cfc&;g7KbF8Ybc=#U]IFEr<3dF6.Rc\guf-GjRg]6kiid\JP +%](p=Dn`-Gfg^3!k/jJ1LIJEBiZ\E8QiWCkphu)gn^HNZf\6;ml)_O9$!('jHDS!LWj<+.mmY.,`GK62.X&[pHN4khJrp+h+_f=6# +%2,q<[q#(*"5G.q&GOtbZI<#l%%=KA/Idc7nNLqI%4/dW.$,2hBs5rI%s6B(@n%O2GmHqs+l;n7ZeMe%PE.@cXXoIS)e`QkSk9!d_ +%h;-obHBhOhYG`32o):r,55PgsGId\)d#6W7??q9W>kn/DWVOF*iB9i[SpfSVk3Dp_gVDS5H1o?uh]jOB]hH0JN>J0GrrtlJld)K] +%YUYM05DBc!U2E*fr>_9"gXrcTfDd"Jk8W.r5Mk4geC7slrq8R:2g:l.(dj/COfNuC])T.e/G.5Ol3@ibDnfOA*90HESN]?dip,8? +%YYT3EVF+7k/g?`BesV(S_%*WF$2I2.FQK>4NuhJc1C;7 +%@_M5E:fiaFd$G?3;:m*.i39sY[JL>4LGZfa`a;q`'C'&YEPa)nh&^48_7>3og>_b7IdX+_oMaW@?/Kt0Y.I'1 +%pO1qB)\2r#c/$l8aDUH$ZE660ep`arpB\D(W4N8;/e$_V4F22md36I"i/rNP!OhNkFe1KE$X:dl<78\cmSt3 +%GK_;HJ%Dd?aqonV6mA2J&8?bbg*)Rg8>Hn3WN1!TJOm7@UjFB8)Mtgi,$cPE*KoY1,uYpa:So1&UPG(HS/jS5Y0@HrRACLkFpt4%g"=(kbV<4C%$H@]JY8qQ +%&o34'0rftq'FoQ.@BXstHQI'_6QLE=:Qg5JQ+gtY-Hikt81cTH9eAgS#(EnD?g\A:Y.=_JYT"#aLfY/.0X +%pN625*ng%=Qa"[P(nVJI-+l^I-.E^A,m7;6 +%)qeF)g>,ndS+,/[ESKau]3X@'ou5kdU,nR`WLd*QYBFONh!3Sco36nT(06C<=O"+>j^atM9_2LjJMh3`MC1M?B[NVdcLn:)H1s+% +%l)BH[s+QL8+.X!,U,_jmcGoGikPA57m`7S!( +%$i"C3Hqt@m&i>%aZ"3i +%VVKeZm"/5'N!!X<_=+NkI(9#up$GO>s16W;^9p`&"L8U298N5/bVbm5/=UV;iNGlQfl*$hCTa5=m*@u#MEVMmE])uoc./5_O&s\VUF."[_05&L?rO.$PJh+8J<%pVG4J5=">)Q,J>*FrRfMp7/_qZ[HPG^sqk6T;sjV(RaQg3ZG;kB?@ +%jV(RaQg3ZG;`:IPes8dOckpjhdJr@%"hL?7ME\NV>+oVa]:^8*<<_Bc_\M`WKW>J^cW@>kBX+/8l4fqnt +%]#Uu=nLE[9cX544'ae#`m]+Q^]m)..<*@&pVCJ%(CWNb>A$3A8+DC^iYm)Ws%TK>aI\YGnd[0`.4cb\NY&6fLJf<0)L1I_:P7@>\Z.,hpPQ0*RETcDbQGpA&J(mE^heM0Amsm8am3Yrh^iD-UcUH<+E=MG_ +%9dC[]jT?Xb3_'ifktCp'7Fr5%I&Xu(M!UW.j+j[j]DL.XkG'E3jOUfm$aBk)PVTHW+]B_hH$h)2]OE#[J^tF7VN>O#>%=d_K1D[d +%-kE9YOXLfNDGj,aF?o,h8e_Z8>%mTG.N)F;8CS)H34-i%eW-/BS7o<5[W$mq]<5bM2S*AK;XmZJVMKDfgK+OiYLFg_u6)A6fC20 +%bPCSU]P:^Xql8b'.=eS`tR# +%>2Ql:Hgi'3^"bYRQ-I3"[glJNoC0r*_c>APr,V+B[CFQS6L/T%c,4iL4kW)gPMMF>@;Gbf]s:7IDl9(9D:gBYQnQ]m[ql_$bNp9o +%>:&%Z7.g:E2j1plFYaEhO9:Z>ib^iT1^@1G+4%7,SAZX(qW2)MEHk229Jm\W_oo?WZYJ6 +%\46!,"Dl_@NAiN>&ZE)62^4l7S9J3g?cZ&<:(_VpN9E:j9. +%Y7sX%;jJIeF+pC@JTW%.Cq>4RYVp63@qdO.)h51P@b +%HC\tSDVD'rk?F4@L9&r%ll?0g@\Oj;W?8u2(o9V!]mM4>PfYj9NSc9A)pA^(nH&W)(RIa(RLtdjr0/2Qj?FI[k,2u0qp$>2o +%8M#?kO&^Gm71EE2h'ZRJR(Ki@r^So'bJ),8iP56cT@P,&P[:VB.]o;B[u'("X/G6"@QE9>:#^`&BiQf^4L!n.qj=1/<)7dE5C-!l;k@'UEQ$#UYtEVkq5TPY[Vj9dE1BV#n;7CVL(:D&L8Q1['m%Q.[YM2'=Mh4?9YhW63T[[X4JBl]>G+&V$37bF8Tpn&@krCh(h]?]#6W1Q]*'aA49($)^.tjGV?.^0m +%F`^NKPE"2(kuom/bB@Z?SZ17[-Mkr.N:t)++`+sQ)@h=Cp]Xj="?eBjZ*Y\HWRV:SA:M^(31$5>7Q=5Pm"?<./]OYe&(e8Y^-)VlYZT" +%A-;Z;%H/#.pP+Fl@BSJ<&3e^r>8k@-qe,7shDDAT:r.tlUr*#/auT[7<:XRJr=`N3T[i9jek+/%6W0OBim6? +%)=)f)kB'dmYJH?R-SO(7j?!"P<-bekY=],2-j'Q!JoGQ/.rEMUO9M=B?Bpi;/`t_)LW6LMMc.TiNZ6/?b4Mp:NgIUp-lh+=?]"_k(P>$sjr +%ahC)/CkpEj%@^iJT[,QYMS-P])nQK-Y,QFt)n^,-=JGTMe^MX_6cq%EkJ>)]X`\\73jKVQ\_3"Z+UUP^6gZ>(QLfZ7iN!X]S)J<759pRkX/%'4K/]FSAQa3oi<3+B"6gdr1_)t6 +%eBGUl/AR)O\6=^$=bs]KYa\PK%>We>@N=Oo)i:EHF%-F1&AaJgRuiunKkj`@7#P!S`cG4O8D"083!(AYp!ADge;RAb)R.`WW"\b+ +%et+k"`*H'#(]1Jj[%):i?peKF0)u;[UUpMS?gUaU^87nl/N#GF(K94i<'L!`MTk$\pVV]W5#p?d6)3Q#GJf+R[(_ilA)/1FQnCK] +%\lEN9>l9nP3c;"c]Pc4n8qf'.@-u?-]$FD-DDm)pV&$$e^a=C.k;;ns!% +%nXOASG?&:i*+*_d`T$.D=+u.*Hf'GRjI+UU4j9N9@J,?]+*2(`=(Z2p/2uTe#"J=)H\3%#dBlldV.'j:>4jd&guJ7=HHB#$k8#Z" +%o5^,;U.(QCB=57=_@fY1H$%056D=q.FJt?>c-KY6)&Zt/0Q)KbcSf#I^=M8+,D0UB4J\tt*=Y4''i%`^amhi+\0Ope9_ZVoA@6]n +%YBYt+\e0EMI'(:4k8MV(&l'(M;;cb_8IC4fIN4b8Z[4m56ZJeb=f))nIGqJW/U+2$W)RpLHeAOj0m[&2BbnCm$DH;L)@P.n\-ftE +%V9jdV_e83]j"b2$e<1>XamV*Rad]6D2"B.["jZNr]]c0.?VXc"mlP+BnPcK!a&nsMF>*qb +%`j=cgcDkNJ=nMp\K<"9dY]sVWaZh.E_,hr.3BP@!a*p%nOIoSh'C\G_SEQ*a<,-'.W&Z+^92Bm/;`oa;r+HIBBZ4ocoG653RcnjZ +%DRf2OlbJnI3E<7%3*5JZ:Y&sa(n4[s<]s?EX@_(+?KG\cq[;#"3krjIQ,5O9f'695p,,kl&(H3)#>4qV>*U''\K^1;OK$)_MRf+" +%9)cM'fO/aS[DLk3I#9+<$_8\hU>RbOpaS*-D'f40Z5YDh.To`-+@8p>KM`]6$,dJYX,q+'P0*./Tn%/%?p"a7@N":Eq1%Ai5M7Qj +%_O5n+g+f5qUq_0"hgQTlpqu_%eDYlQ?p@_lF8b*dIUYO9ZVJWP,F01OL!:k>Hp3@cn5C'Z?Dpop%^QA4D,lZCAnKd-G=TZ22U?g/Z-Tcu>IYAYGbKe75qou6jBB#-L-n7L7l\83n,?8Kpai%F=JE:,k#HkdJXS`\D@fV:D'q("AuZL]QPl_Ohn5/"cX +%8kRjk[A@0`g@J-**UK[5mbV?ecLF(dGN$,VbZ]Fr4uo0#0k?!Y/JEoU3#=G7R:e^/6JY_B&8cD[U,?-fY>7a^f1r"2P\SP6WdB0>W.bGJS(fFe +%kQ"bCr"D\_5j'-\n=#@KGU2\Nf;#^Xln!d@,1/?WrU2=A"TDRI"$V.10_At?QHb2kKu[@@U]1dEtlc[\;I!t'+0>C?!IPDN^HUb +%Po&HN;&48l_["I%(j5ZJU@%WA:J\'qA,\W4E@Nh2W11qma6UH7TF=8?1-k&+&1G]ahYQ*$]*_=!FB,lprpj(3o4BXqniq?cSoBCU +%C:j,EH,?u7YK@Qh-X?8RX%M@bcQXkoE^%ir]q9u8c>ms5`.0[a>:*Dhkf9a"gHP3d+KUIQh.e_>hj +%&,YYZ&qSEHZ?j^\%j9)r\'4gOiiIJ%b#4_hrd*_bs#CND_,Sa@:OM7"T@@8CbWb8Bm=]#r&oA@YMI.^b`sDFeoNI:hmht\Ub2sSj +%d%_kfLq"p4nRG2U'?ocsQ:WrWI(]'pRp3PEa2X[A%t(6;L6hQOE3B:pM.i6&c_:%2W`YLl&VddO*:H8=S:b>2NB2s2+*[mK`*UWT +%3H1#\ZBs+OMcg@n;5S/hS=*CTf@&9rlB*VP#%pX3/pAM@JgRgo&BfO^e%T#*7hl7m:$`hiK^0_*=orp?6pb7&f.AI +%j'%HlN59KH+K%Tf-qKBEl'4e"F]pH#cRP`Wkn^^L%4sC +%duChn1@!It2SgS[B\eR;p#@7H\Vo;hZcYK'[/(K/6OVh41@s%FASjBV\uA_7HV^_=$h9pG2oCg40A-/t'7(+:[b@dJhc"7^4lsC> +%A5nl[ba/j(`*9an#&^_pgSml]ajr&=]qG(jo3jD#$NB]OU[1LHB1CQ4!I@t.5EtknML.ltbcMO-V6ZUm8m'WC)jPT?SV/lBuS8=g1j5:c`eSce/Ea98E4'oba;F[-`E#kH;ZI +%Pc)Klm!Pt6:5Lb +%5SG[WB9,&64,@'Vj^1l:?$%mllTtM.bO`JJ5p'u(UG3tR6HRP2bUVh#4*55LB\5Nmp^g5H0@!PYi21fD\1&kVcI29UI_:+hrkEnJ +%H1h.a^Ud*VIB11#g%3e.T9?=KRPcS$'.U4>5")c(NE*K!'X$<\\,\8k=)W:f!#^Kkf3!`"7cEVic2I>&_tEC-J+GT+\+LQfmm"WI*I[P(e\f;prmi=m +%qYk`IqSSXA4Jmm`=&!a5:L1"bPCJ>LkIZ*c4 +%r<_BZ2'ib8JVqkerU/Ci:SINboKMY70E"PenrE@]53JcIn7-tip$i+X+rp:gCrFSSh.n#o3k>\p%Pr:+SM+0M4,1%a]'u0P%/6@Y +%go;AJ`hDd#':_oV\CD@dJ[2kbZ50Kch%4M&\Y8nOmsP`:Om/TWC'W#7DOTK@j4o]rEV9`-^M;`&*oIk9#9,*rl<3;_^,&M#FZ5@X +%B7_]T\;+\6B__S?J#7!7I+9[1FT^7[ICXiE\8TkQ>W,7ldocK.gr;%DmudMAe2Q_eW5F&VpR\hRGi4#j"Tg[CTa*ic"<^'UiMh89 +%5T+2Jd`M5Kk1AL7cJq2-%GrB53]cCqauV`pc?H[?(Of(4YC0_nCeH..`OT_lT\oWOj#FngM.`JoPoR^.8#T[2s^$Z]`$,Ho3n^T#m\?^o]V=N^^)#__7^75*BGXqu283Y2pS( +%05]]cPFrd&ecVk=h'/YKC&Ki8+#PY=p^P7!ESc=m+@h_N(Vt>SB'6tru"7_h>kJSCI +%<>StFc`W?'C19LIlqKPE.^h&kjre4tZacC^C&sr*N47kETGWD;$;=PZp*_d'KQ%$+Y07mp'^S[B-(XKaLa>jjd-j"P3=fu%n)N'd +%0_X'^]94LgYIr`TOW#64^uqAYMR18ojt:B3O`G`"gT+1&#Q)KX."9L$q%Bfl.6Y>dmYhQZ")F>VhCa; +%.Rp(7H!?HR4P15MmsMGM%0&pqR+'4'b;RWj4$BsW@]Wj1-eUa:+Nc7ZE&l)FEt%aEQj=d>/41qK(@[=grq@<_:lHcY#"Z\-qZJ1n\A2<6$h9V]h5?-'K*jHBg:)M\JX?YfKdHfjd)UJL!@DA6 +%kW"+iT_!DG2hMSsN'Z?jB;P'JmcIi!0*+d+Pb8&merBm,P+'.c-R[e4YdVAcfFs`S]b+b/6#aU9DG5mRjGoj4ZDk\#+='S$M=iZmh,bc +%HVHiTDmkDE"+p]J"!,aLFTdD9kQ&6,ejC.;I$ +%+>O]TdO!*t!Mfa;@4'9u&b`%K@N]C*Cra_O9::`M6AA?S$h&N\\dCqo?=5[\Bo3*P44QG*4g(X>^&8@akrbMhL=IO/.]BIM[EV\. +%P'U@U0ggL0Oa805cm+R;.;ig<0)IpO;i)0abf]K3MmsP51ZU2#a>q43=B*lcM`NT25kjb@r<>6SkU)jeTqg5ijhC2(rM9a1']]@q +%5^i+?Y$Vu#:XrJkiV$A321aN";4h:\Gj]2p8epnB32iPBcsWI+Du6e^JJ*8GaQO7J^ip+p6mCj2psaO<;YQS7coJC_LbdEuDI@&V>'N?,&#P-8+IHZ`?<'0jnR7DnsXZmjtK?r%k-[hT3R;_OWN*ESur$q>Tp,7=e8 +%0!$NF7B?jgT%3mC9-e.PUu@sm-HkDFT.V#^UkfiecCk8N@#"E3/nG6\f.am9"%3=WN=+Z,3`#DMqG0* +%(8ASR%4(i9MS+Rl>Z30k881c[fHe(%ZU`*@=jUC^n>qjsn-O61h")Stf*gtB2PUH[\#=\8ZWC2dXr1(+##*$B19[O^Ng9Z!`XWj< +%J;^ga*9Zn46TNK*6Wp^09sjLO_fm?mFj5A<55T>C['A/. +%S-P-6@hXg-ZU^)p2\XTK3(9LpM2>sK*q'0-74TOo6t*:&>Y>uKo'h*0Y_d^_P:"1+hB:Qf9NR\tM$B!CDV!?\SHe41)1Z3ilgdT^lZr8c^m*n-tK+t4Em;*Z1nZ9(RJjUVR +%`)*A3Y[87C!BHQ@^FgFh%g>]ePXSRhmPMZ!]k2%X7Vp>e'5=BN.go,\n+*!EIYGf1YiM;K;6_B@'rh\?8,*eESrfu?Z7$gCAPkXe +%b6;CCZ!\@Vgl"X@0pGm0q@Xqt`+Fk25d/DbI2UZl!]\!V3CZc9@r"Yi9Mt#LfKm;.MhNHNc&HDf`g5<:=<[7=l1uPQ7,TL$#+J%s +%UU$hUSC&q4[L0Ad:Y=^5HXJ/35D*M1]jRnk^6i7LG[==#aA\b'CrP)p#I?Kh_J+r&O3inVWn?ob +%@#MX1AL@r=?"E7-#C7d!'[%K[WV$tV'+U8"^.G[g//t(_`JXCBm'&P!U@aJ,K<7Jm"_*72#@!%E'8LePMQCjXFrfh_&r-P6WQjcr +%N(FkEMF3dtDt[F5b2t.'%p]b-?F,Vf`c3ETL;]J#HZU6boL7)$' +%Xk<9`=HqWkju%mXJIrfj-H5C;pR+$a@b29M\XJ6Q,)jX4$K40H-F$k)L;\Q2CUD594cuS4oJBsU_*_^@J7Cs%":5e4bMloiUDY+W>gI*B%(ue41,N(,b6%(.[(Sa(I`N/> +%+Wuma%KW%/0He/'%$H-(bcR<4Lb@e^/N`bU<@7KLYc$uF68-bNQ:B7q*r$?p&LNOU,f4tn]L@np_^)#e$'SIVZ4ma"P3.R:E8=>W +%JQU3PCt0Z94=ASbVW2n6EO'\j\1plDNDlNo0W7;LMNg[<&jIu\81!WI`*4_i$3H@q.P;;7Lu8mhcq78p +%R^Je"T2rE%=X\eP'PNJ2'p>RJm>.o]V^1SnCVS`6M +%%'^(;5dE0u6FKf?2>GO<40UMn%fim8/9;-@8M$cBk!kJC=cSdKq5i;mWfHFq1Of"iE/4C15Zr1ZOUZ7Y8:jW(TfmMkc,aJ.,f,bL5FX,iU25#haJ#ETor_2;nTFANE-1\!HeL?.mKnSr'RlA5XbN'8_G+.:b6>]\GgUt)`sZ'$F7 +%@Wk)t">9Hhf5o[+P:i(jTULOKN!1[6"(d+Xrn=(.^c2QS%G2*]q>?2I["KQ^Re]:+ii!`uP=UIt7=L&X$8@TM.17E?'c,Sd9;,W, +%MA_WdD^kG"p9lY%a&F2?)\#XA1og>1@K8nAk3WbYA@pPUWE#m'&1,Mr_L`,cqBQs]mlac5)?Xln9i-1@kXWDr7_Jru%n_baO'9CI +%_,*RtOgC;co)Ua!hCE:@Mf/[/o(ereg*&k<:kha,6BjCs"FX)cM(#i+W6r[bi>0;;6G,a,apWHV@88_V_S@a:b#*D;TIJ9h6A/DW4bn8b&3X0C +%9;9Lb;&mIQ65YLI^C\F_#'E*OfmMm(ZbnQ9/k#k+U:Y!T'pYJO";;+od]dt5oIf\i$-rmi9Y2n[F\/)ddXhY^s/;`H%X/L6+lP$t +%-7%BCAD5.K8+OogdKYU;DD:o5"3VnEZ"GS).<&(/XW"aKA[>sZ6tJ\/TgY72Xo@4Eo`'$*O4D1Qd3jf^f]a'SQu)GP=:?oJ+r3Q, +%=TO`3BPh@G-b\Mt/1P.=$hT3(:l+*D'r\Sk:g[+OP)-d[YSlNnff:"dDr)I5pS<<7#`@ZLgaM2ajiGq#V?H*s@][&"$5X4EOMe,\]m<_Bs7FZ/c%6&#\>hUE#[sMm[AUSh0&&r/)Bk\2%??c1^%BulHG^1D"AFc\2Bg1:fBu+Q6Jt$4'["ukp9.oJ0KOg(2sk" +%$gtqKP>6uc"DkEs=Mi_7?>%N.\]Jcaa!JODJL`f;2dK7GTb(F]sT3Oe!a4M8@j$p"J_ +%$#mmRO;SXfO?;W.CpE=@q+6el8@@rh`B-)2/+10@!#!S%_^s0-5[2:\k3*(M9=->(7T3H^t-0IZIU5s +%buqF4i$B_2*LB=g=2DLo^PI&ZM!$!K-c(\F4G^'dn$q;YDg]"Od:pU*rRbL+!BAekpHTl]V#`dJq,hW9uG^;$,06c]isf!!!b`-MgiC +%_to`'`YGV1/-.'Z7jOnKr5`,X+*j_qM9HN?(V&51H)bU.OU*>R5bs?Gah\;3.IF]!*LBSG)46'a'l>5I;:R_5(>K"o$Xr1,=S+pR +%0uRNt$-S.h8jJ.c>m68lAlc=hVbWA(,fZQ/)aimUDAVXGg;7I68X@X8r,rVi!).YoG0A=1*^FL"Z<^n;>VW/9[l64-X/Jk5,)9HR'k-H@dPF0>Dhg)l"P,skB'?i +%[jSTMNWR/AQXq&QEluP0&jIu;>f2^t>T9NH6oG2ad\I59[]kU?-"WfY8Jk?^F$2t(e.As'B(%;D9?R*1l]oho,2lW9@KfHF:bC-R +%4F(Z1(AK8bYSEaF=`T)hPSdB:]eV&Ze(?]YjdlUr-<9.AP%9C@"9gTL?d#)n""V]_SPM?)q,$Es/N=([3u;15h-NlKTlQ1#k+o0*(8lJ0u9CYrB,+ +%A]K\Pr??=0=S.>S5ec5IL#(%s2S@2s)iJ-Y2Csdl)WJW":&R`V;!N)PD"c`61b@[8TV!EnfmT?+@qTdTAXAU3FjjA/C-rjX9F"U" +%>ILIWaZJ0F2t0:Zb>*@T@`+W%d4n#!h$grag9SoT5^TI^];,nC=k>.2G,RfQEm!hpcVKbSX7/Z'Xc!h@8fq15^.*$H3l/ +%9KoNk<63@/`2V/V`IS/_1ZOg8;mQI&)SM_Ogi?5?u)'>[`6WQ")2asjsi%!+Ir-WPo!0/\/uhNC?r&JH(!qYW8PD4#GM]u>SZ2,MZS\l.@+L8<-Uj2)lB,#:tUu)A\ZNQ*=8NIkuoj3/Z/W63h54gZr+]I!]F4u?,GfUop.'7 +%P]P+tB4,`1.-KiGFTbBD0Mn^XPOo*+r3bf+k_8[HlX58@&DQ+[nODb*kb'tYS9J$S=Qr3U2]$bGjkgr*0+fS.8T*51GbdIDD.a(% +%,tNZ+/lFU3Q]![t+rMV/XlM'*B6KQ%nV37^(`[^6U8Ce.)7&9^0s^#:)F0NqPqkGE$qk8mBqefmHje@[E16!61_:]CK\=C9b//^8 +%gd[DW/Jk]tWi44='5&Z#2#1e^Q#*X+P,1<#,:ea;K91dp)9OBqYmdPKPRQTXN3*6EF1Q269BKiD37`.I[?U?sl-QY*m+K&+W%cDd +%j&-hnhOXgJ)igIhq6*2Yn&Z3rE`c&^hMWrhh1uuuW]g*J%J($UP4WRXDqL6t$q=kO7Pf+eK6Cof855>T5#_F,W03EM>\k&<+l<_s +%\G%W8:uB8sKc\ZVNQeD=*nhd+MHH\ofP]+c4&k[cWAguO>&sY5poFR!6CMI[`X_;[9LUb/S2'+.`c:*ZN!5g54U,rC#n6QsWON"L +%)_c"4(M;Tara=W.dUgiWgZpW\YjB?7T6t0Z5-f6Yc?>LLA5=CC@$BZe`j(88Q6hMJdqZ#9>LJH[1@CY?n3kM`3JA:1+>gQ%h5t@c\9Uq)$eDY5VUAKa$8b:Df%k(mF5;=Z&5!SRg.=1V"+2oc>C#Y>F +%Kcs0kq[gZJSXKj=[2J+QH"M(2[ep[m5"!t$:<27pBcZX +%/G5O/bYXZM^_2XL,G5iIXIgc9.h!k*S+n6SFT@+X!_f^af.\%OeNQQe0mm3CGgUd(R_ZM>NBV=LM*%k#pV_[tjX[n)dqInWPs.dC +%)EA%sQ=IG>#R2p4BOi6[nYl?+q[.*oj$K*nA>?NE]`0M$nV5)6ORbCCjF)&hXapCF(@iIF:W+^9!FL!<-0sZJ>"f>dS +%;T?.)*Otd!kghi7Z;02'nQ^r#ghVgU.$KkB\n'j,@,L8%n[+S![3j$Uhoan]1So/1eNkoEMZ=dR,?)EKpR%A*l9a15\"E5Z$t[p6 +%3b3s=p$ANM\tk@R^g7Q<]I9OY0G<#DH+Rjam=X-+;S/:,0_[#F=SsW,R.u8UACqZBFpVhS&a3%Z(NZ-P!,4\;:9 +%4G%heIAUQ4Z`I>]E`rt2&Ai2ZPk\Ds"4FOMSp:2UrT>aTa^I8i4Xh;X\>d>%s](OdbWL0V>o9(gmA_:WLe7*A'aX,t. +%a$]Lc-&3Aj]7ih]'5&]$2#3QEcJ%j[PrANa[N)g-ZeoTBJR,)erAfpFq[UPSZf8G0J^QVr5I,_R`cB@qf@&q5idI%.>"/5Bt!--SXuBaV:@hm.VpL)QK*sNG-^JgOQ7YH1B-H.G=q2J1WIOVR$FdW!YJ_eo4f$JAp^Ai]"R3(Sr1#"]/HFN0ZV1qaZ>(92#O:3G>%/0DN9I[3![B5:)0PU1jA,hag1X;HfX +%lr#U(H]>,#N$CAFNU.MHQhG,7;RSfNWE:S%Yi[rG>in%H>f(n-BhF6j/!%"bOfVfBnLFcBXH'!7*2:GFCsdr2cA,k?B9Mk[L(J?` +%a/LIjS`CJ,@\=AVikn$j'D%SLBmoMH\h*^DBs"mQJ=)d)X2&-4E=C;Q0d`ogSGJHp:ORg$iDr[1PR1uljQIKDCh7"Nn?h[;c&$F' +%['#63pVi2N-A3\9GSr])Th+<@fG+'^'<:\,1_AoVBHTaUR'gj:qffkGDXHYUS\7E_QJ*lI('rL;%2^^O\'KG\;LjSHH2F;CbeK-fEu/;7ZAr04`/Q[Ygb*`3HjtN69F9\QM2qiUDT.mEjcuK +%\cpDkR\Ls3_r3uA?H$%^lJR4eToG5sf/htrLY\+lYAsKJNkn@0W^Yfrgl'*sR:NaN4*L6kiOBpX)`Xpsi@(hi/bjA1;6d=5:%M-7 +%YAIuKbe+^>,HUouorhI;9+ejR[q&\dgWhM-?$8<2ZjAGW0E`XG*ufA5,j2sLgm5:9&U(LTK[pq3+!D_R`qJ5KD/i@Rm):.EZ.#l- +%YmaPDn<1Y.6@tT\3J>PuDQDekUpA_^@H_.sa2M#)iX5-6;l7(A43j'>mbLY"@[&j;E6\bO83"n%X6q2Gi3JcWf1MRUCr23Ejd@62 +%.T.TJ.+3k*lh@>5m#/f]KQBo0]iu#&SaL(-icHgb&XK/AVXl,=:I0PVP%K8X75b0Wil&Vco;_5b9`RlY!R>GCkmZq&?u2!"B.EM, +%"D6&4AE-8`[jDat1_%RN?iZRY;0\J8+PO8QMlcQH-\A2C;iAb;EDlLdO_Bs^o;)jopC8?5`>Lu%Pb?D/Sb4_A8"'_XBoIe2!EuFs +%X<>]jGd]]!+]KJP1B?-"r.*gTW[.ekER<_/+s$to2mcDUQ].dmc(1P$9tL^KQft'Z4(QDFhB=#(^]P$(M,Ig(W[S0d=U^*'F$?Zu +%VYX92aM*0J(4ut_.!3@K1)gH':cQ`2.fg@4C?V(7$O9L!R06>W)auU,0[\nE+tPh>&BAlt6Ph]"lS`lU#mIt/7=GB5Q8fN,S/Y0:T9*8k@9+*aT+H_LiiL[=VkOC0%%f^m(E*U6DB,KHo#pqIkg`;Tk"9qPDbLTs3YmBI/+dNo"_*1ECK/*f9KgeT%l<:e1p\ +%A.Y<,0W7gA@U*(c0J/766DFgm&nDIk_2_i=M@Y^1kGRVk!\4FYT13%,V+XZ%PX,^3$/?#/gqoV>$4#@sV?! +%&Ogq0$af,nq4VUt-+0,r$("beX=\DmeJYs2B +%:Ip=YcL[uEa9X)7RtKl=Z?`J#%Hap@0(Q&U3%P<0:X+0!''gFtmhpF_0&nK\Z(MrZ#QWC,+`AuR,_rgWJ^mt=[LCnfKG5b:6&WL:NN%UZG\$7.;iRX>=:%2Mbm*/'IKaIeXY)/ +%rU:R$L;3qcmLYd/e1G"`#pa&62t1)ZBaK/gN)0i<%D2A/(P_=(d2_2nFOj^M^m@C@_&"t/G4;oXOH;+mY'cFPVsUQ(R2,aIdD[(KB>lJYp-8T,$'B)(JH%qR:dcb5sjTe^6*E$1B.Z[ +%LZ^\9R0689:)=3a:*6O+oPJ):k$$)-iNga$0N-%k1T"BN:Pk/GeRDEl$regUdR%=k/HfN+l\o94:UJ9Ko;/9oM#S&9)$5=V8erf; +%9GEp5-SrGp=_6s$5_g!2,q@;QZMiN]We$j2ZP=]VE:`iNiX7AFI, +%q+M6m"o_>-+bmlKQk4RLM%V+@=$b#5j8^'ia>cc:D_f8?UerD1F+2*&LX55s$??*413)]*SD63]/$#[ +%cT"&m:eA\RJ1:u/2#&%U(4[9a5H7!V&R\_"3db30DE +%3E=?s#"8h)&m6V+5p@huJR6YL`GI;'X/VcPI(GgsSC95>83p%J.`4.jEe.RHNpXDR&k=5GQ8g'+=2@FXn>7[Vh)n +%72,W?+IcNFLQ"1C`b94N`_:*/e08l=d5ckI=K-sm#V.K&90..Ie.rXh?q&;`N4CBh6d8%!P>F'_s%5bAVhDB&8nMrUZ"B2_BuTea +%p9ZZHF%W;Q>TLYV"@s_D$6mQKWD&6cph>TJ-4DmZR5U>X'([B.#1?Ik5*Rp=b`aGX"ho+;VTn$So6J7*/_eU+T!:W*.Z5K4mC40= +%C%,'$T1Nja!3ekZ+0-7?W(39G1rJoWI*o7FN3O.3S-D!N;2_0jPm1s-+N'?D-CkN[/'Y;PRt^/g`9Ym&_D&@6kUdIT9QFRQQ6MBI +%0#nTnK-r<'LK*']uNZeN9!%*H90f8-U@iGU3q9\e_MKOhaXfRt1VD +%V#p`p$Io:Z>LM(HqYOpAiRG6,,6&;D(])gjUt1nD(_6IN&0F*V?=A9hn_Y2PUF>&d[4Lf?D34p&e>dRR_ila?"D(Gl0XK]*"Yu_m +%U+ckqU?YR%;.@&=P6YZM:m;7LFOt8i+F\U9O2KHCpfsdp((1G<%^r9qZ=<7U;nsa=fbB^nmV-q-];7 +%"9]'d-3sl.:G@qR5QC0'M[2a#+q-T-LjY#Cnle@/J>c1Ak0D&(5U@s,'Tj)DjAdI'R_Vhf;No$O[7XCdngIDVCPeh9_*j\/XLo+e +%&0VSk6R7D`$P=8=/6HLPW[JM!,#+:_*9;jO#SA%C&0a(872-'fNTgI+b9f.n7uTg6Hpc3S\9s`79'4OsNjWVMlBe0g(fEcuV2Yj_ +%n<8m)P6H.d:LO4k+kPVpOf5(Nm(5n%kkU%9IKW$*l(:#R.%_0)SJ9K5VSl!l-*p:7>rDBE8['.e-/.1?++ +%j[E96M%Pa*Cc7:b\ioqUJu%RK1SFl)a8qG7UUl4T5"KP,cgYg/]$t-D\R!Te4#.p;8gj%hH_X>Ir]3J%35SP2E?i[CuEYJ%b^PiVr]&naiq7F-"rTHu]o:bk@RVV7g46KE(]'I,SF5rT\U-5Q,B2qLI]- +%r!1)%KK;#F@Del:YJu',rk-5Mi@2t^JfXX,Js`03J"]btam\0CPgtcnmopD=K'NAl:uSuqW&oaF:Bo=0f=/fHa45Cc2[$)?*n*Dt +%SU>\-?T[gUK22^.Q[Bd65V?pH'MIKjmmp@@QR-3JrE[uTK_Zj$B7@)BC6iQTR>'H1`]%UXh7T_n7=Jj(fE@&9rXF8-8-NHa\':5JRBg9 +%I[B]S%7@)g:=\Bk]usUf0B&%M@0YW+E.V,dP>Y35L."R_.TM\pj>@umTj\MQ,Jq@mNc;q'[18,W(/DR3BiE]cgI"&2DFnr6nCfJ. +%A4qtCaGL=9NXi0/q\kM^C4YJ5r^gLs^(&[OUc3`q$3Vo+D=kUs(5TE>p*JAB8A.#T>NT`[Nr\JnfS64Z@qh+0fhA#R53%?Dn@+S;&i]bqtN/-DRN"g9!S#ji>`%bl]q2p=PFhuJ.* +%J:MLc8M18OHp8qJ`_V'`%#O<^#bDL@&AUG.TE(a?h*-BV!.IGmA,^f`KK0VeRuZ6BNY7)aGQ&Vc#%tZAoniN3jrV)lof,Wk:!;sd +%T[NM3U4YNMN7P6\n1C>Uf20X-?Ak36+U6,>H*h/=)4GFlgUh"G8(:qrCRZ*1;.m*LqYRG`-QE0@04AlKJc^2Eb522U#"lfp%kLf_ +%?Y136635F>P5,G!!9IgEF9=-R\GYlTE%nR((nf/F_k(7o(Jl'sKHW%&f2&c,&280\>M2idlpF@(PQ0T?/`74f1="cKLMPQ]4.u +%O=)W6E`G%\DsHJ:8%>N,n>+3GLs5M]:#N`$(dG$c&2Q3<=r'4a3/F\\E:+uqP*6Z3[$7gd6W-q,K+Ym4l\'7XSkeP\:Rc*r@1J_YR$BZYe9>?@':P^hj&[q;ND6d-aqMO%95GQr +%np<(tH%I3:WlLkJ*V_a>"!qJf(6/o%%?H*(AG)/L]gTjBL%lCETKRt9EAp!1)Z(SfJ_frM@Fhn1;8C''2I].ld=s[jNR.ks9YX(3 +%+jdPYC>]REZZR8%UQ"XM*&+VV\HN+#P16E48VP!]kk,L[kOHWCn0H8W%lY_O(bkS#:'cF/)t@4t:a-:S\ +%EOegb&_KWE"b(G>Ta$QX=s-@hGLUWAPh-MTKCd?"nebtmAjg^kHndlO5.!GFU!le$9jQN"6#t,k#?2Gc.N_i-3$;8Y!k.]7(6e7o +%WZpX>0IZuI#^H&;@2?m+Lcs5UfO>>p#!_9Ia.k2aXO7;H&R3s1re]Kd\u7BX@Z3$Y"+!DQH]D3#,oS\!RGt2C>$^O"JF7rJ5b;J_qYk8a*n:B +%\9#'FII3/Sqt*1k"E)iYN+gr\KR%ocb>SBE['X!N9Ar:)2,kW5uX+'S],c +%&ZT`rNNWAh.Zc's$D8j5YM=no!Z59"U"p<@bk3L'St+t0&,M,?'?E?*Gn0BtjL$dj7C4r2F@Wn'rL3Wc30D6hHA:nGPC/a>*Jg05 +%FWc)Nh9Yj;HtFWRCbW[g3JmmX1r*UPCA^4ufKd+a<:\qW(7')@pl9S"](\.f0Pk^ALu-)";GBcL*i@Y%l-KaM#Q$TM2DE`S_q?2` +%N6ncI[tCP;?8Z,";ZI=hn\_n7,OFjYaqje&7Yo,K_h[eME`p^k9Z)9S6+nle%r1t!hbRL +%CC22'Q%l[tk2VuZ'Jg9U5YV:GZ_?Z4.)b(n`+1PX!N^GGUPWJ4!7m\K/$#7FCWIkBMub%ZAc;^"&8[Ke6c499>in'B#j^;ch\/LM +%I-H&h$m]j4D/7ks*glsa/V=n7LE#0U$']b-ZNNl&_&8o!S'QUC3,?71V?8rdK2k`_#4ct.EYBksIL;9fWC20W2?oh$d +%+FjrqdL>CQ)"L/Y66IUZJhoGqTt1:`/^Wcd%Q`l#2'F#nL,_R7bP)DfFS(p*T%A,D^8#M\!218MY8KZ;b4cI949Gb0!1c/9VKn7( +%`*1Y"%=mRZJ=f)?Uo58`ciBL6i..C">VTX&%f(sfYso"EEJd#]EKr6l6Ik#O`'>Nu#bZ.(:^.QH#(SQ&,9CZej0R%3mQWUI%)>(N3fCnF4)&6@06Bp'H*np,Xqt +%iSfF(9>`,toe`rT%q)\1<<*q,Ekq,EHR=MS"?"7XL(PsUi44:P'6h@,\E+sFd$i_]9FlB8inV"a\7Z?^*I&92 +%95-)0cRlE!%Q&\Jjg!SrHuPJuAUR:MZ>e^J;&^oeRP%.H)1r`Un\EVh]5\i!gph2LeRgo8#!Ogp-<'\!g'n,Y[!e#$s1)Q\Z3@+g +%NDtJ-V*N54_,rjp3RhUX7(E$4QJ<0tWG4a*!;MA'ei+U8"lgOk1*O_%6>7cBJ5?Ir@M>@7XMTB9?j)(-I7#M5[.)[\>X^RUkRO## +%HJr3L87!V,)N.#M=j`nPH-^7!k;1Z%7/cDZm/"Z>VNl-&W,1$h(suo34pB` +%EMOVu4`3&MKUaXhSMH,DLg_^%C>/9JqRYd2"/`lL<$_j0\f_h(N'P=CQ9"LO=:Lr^bb"<_Gro'g[mPIa$[PWD=rXUi-NOhuj.Y^, +%[SpS+#aH<)155h/%Hec;fHVU5?4dJ;%&A%bqcLndH(+">cNcm`a>/Lc3f-Hdk+G?H?=cDj?AmWL!"4YN0gcG6=; +%5kNYc%L^_$.O]S@XZ-fj-3m#EBMBcI4[9SMDus3$a`jD?G(cfsViAb82n4C,M'nEm!8f#c@#kZ#>"]mg`G3#0n&SC\PQ[C[K[]ZP +%\WiZn<0Ncjd=D?%XF?ZK:BHQ5L+WQR4F+0Ie]'^Ao+dcH$A"St=;?o%bQcjcmPkeoMEi(oO1lXoZ/ZK&W,ij7#[jRAB;t/^fI2b: +%,-m2qo+4oQL@0$n;H&m9FKi&ieRNG6C_O5*MAAD'/d-'I@RHf=e<=F(_u.]f/^`TB/"X?c\t"dY.G&36q.%[MD[:8kVZmEJX?!A> +%%MPT@HsL6I@A"@AMed^]9FY!,LGclr$Z>,KFWrr=bL7#ub2il*QA]J\h9:`g3.anm0;>'^bDD,f8.8n^cmpAZ%m5C$hMgKObBWY4 +%CFHb)?ch=u#jer3<,d,jq/I_Y7Q13+KI;u_Tb#De5UL$dkHsk +%[K5D.1,'EB.e->>3286/WH^XW`l\D%AuKE@NL#:nV87]nQ.uL@E+#Yl7WJ!,b&2Y(@6RMQ8k#%4,EDf +%[QS86lh>>4N9G+H5*.=Jdfcnf_4goP&fR!hciWRcA`Eu*]d=>rUrHe`GopIP]qg$C#ClLMqj;t(#IM)%RNZ7g>%%b_.LW/k_?OH/ +%gB?%p,ugc=W4Lalg0&KF#pU?,<$G6Tdm2.eN^&6ss4c[G;]QFI1Tm6UjPX"Z533]2t&_''G4PZJ(O"D2Xc7[bb7L4=a7q#6HU0-<5:j]SZaVNcDH5/s]X>"ET +%oK_14KY4d_0PX2-'*RG&Q69NR1/ef,Pb+<]7K2n%3:Rl&32A:G#O7dFIg[QJsH0`g4#?=PrQF!KuUl%pN)2k;Gs=@*=$ +%&AB9[**kN)1hMiWjd.^8NL97o7K@t)+!A8reqL,-30;krb#<7![\+_"it4q-:I1Lf$dRi$_M*uDIb&)kci@';k(Y&5$-sSXWK5FU +%^l5j5-5?b'IfuJidBN(W&Fs0[/iW6A6#boggSW]sr^uJM!UA?sD^O1Fue90Eq/" +%88`CJ%Z?4H.9[+KJsRV2$@^<66SP5-3BS_?69a^rS$@n&^26.PQ!On\Tgh!/183b64T9CmDhHuoKD[q-_mITIHmlcGp#A>J*Rlfc +%Q]bku7g"8k0ZNft!!,KhU2:)g=Q=ISXfY+BbT1$sDS:5]6a+8G=k7S)F,7'pdd?#tn5+X"RI;5*d>fQ?&Wr.Uc3G0:ssQo/7j8VEjq] +%SjAYU:d0X7IHY'0r4$$"Q6<:GG=3>#N_-676AH.TB:FMC)m;)klUD8UL*7Pt011%)T8qnNpLi,HOde+^n8rCjPfhH@if=YfmBhSM +%cZt3X,H6q$Ysldk+d7@@TltGUeI;g/q*@`UZ8uF9`mdE5N(d^\*.&`$.NYn9<"\QNE4-QaD_11'6`q8'a\*_*5)9Kp*Y#R]M$*_ANq/9%_F]k)^X]e:c\lrmu?,8T92.OL.PRiT+k*p@Z%D\Ecmj$Z'[XF\0C=jtAUL>.0s[l2:uci9(e5sNOb3.Shbq(o>drH]gU3ia]7VDhk, +%_ijj/*a,32+l:atC=7&dp`h(F+O\Dnb"'Bs3Pk6P?X?lq`ReRFjn9_M[sbXAX@=m,-%@uVTY?Y;74Q'G."s4LY&/53hslsaP'^OmQ\I,30D=dTE%b>91& +%P06Z,JD]d)e.JZ[V@5``1i_el*TD+.r%0s\L_>f;$>5%e]c9`FHN;`@mRZDg`Su2BtF5C%//e%^#IE +%8m>q#(u1tH9obEVb.&HQ,+asYCM0f)`\h%m0-O;&7DTRN/(IjH%4,?AlV(S*gJT;$hA?,#r!#=br^sErZ`8Q*7oM$Z@.<]$#ZD;a +%T)#==&Zq5]#fUcU`jb_<9hD+*%%F]U0UaLH(s;!72M4Y4+`"raI-*4*FZ3&#Bu#0Tl>8S29GC?DAq]&fE;19p0NSGZ-_E,/1VfIa +%0TX[[9qm76!Oq[S_8L;4`=)&3fkHCE4X"P^K?Js+bSr*i,I2!7)!>dhnG(@rn%TFm/kV$X&6rh3N>D_7@q<`L9`eUB!`]R=lq_#P"]X;D=ur79dR//,7OL[Y2DO\B2h@b +%j)8Ra(?b$o:RM`d.G5nEo+Bo=Y75XtS2A,9uK-WGUD +%B:`6:jFf.2W(`R)/SH=S52qTg92>Z?k?d"REY_8Y\u8,r0=YdDl(2Zoald+asFCJMg7#;FZCJdW)A(K#W]T.Ep77&ST7mPD>C/Aft;1 +%gnd]UT6WhfGG@PChSS*O[gDm!q)e0*nAa2)/B)F-,kr$(+fu81jCY8:jrHQ)!atMAA=YEJkPTVqM>8U'S'W,J;J3:ur$qadm%RD\ +%N[_@G&2ulg!Ej4XM>+!jdPpI%>_YiPj\LDRhJ_)X4k"uR"F?!MIUb4UIE&a<*k*XUa):NUOh0kq#C&_HD#65EO;:?.e$mW#AJug\bco@'Td6#%[N(E?EqJqTfL*W7Xi^aFParo5 +%*!'Q$"-N%51jI4TI$8feF\DQe%6m-G4^=&&$\9$7hr8@/!uIP"+779B?G.k5i=o7f'A+EuVSTN3'Gl"bqjL!=M)VY=rmoo,\*1E:67T8_f.5\Tf="1\$Wj(Qo/Z6*$I+mKo"L\j%!Gi=h(OK_1,7uhIbihF=R:(Ae_5/F +%;tH)T+R/8r`JSU('Vhpq2-FQ]1/ad(!jf&S>c(7Ea"mj<_Zac+1btm0fg4+nJ$J@H!H#iK/oE7CIib]&*t/-Se.25uG4G22gau/Ode1fhYk"ff=#Vc&QN?9 +%aFnql(47`\Lng6/EgBVOFDi"%3V.f@,P4gBkGGJS]*Joamg$nDbj.<&UE8d*A&"IRhV[3(^G?#/f +%JE%u#AO0/$hV0%.GJi9LjN#J&m>6g\#LgBg&DE@/9M`$6L+59)8s##!>&'5\l)OT$%n0)\$`;'-2Xfg&;R(G>UkE"X:'g"('>k1Z +%G.M;c0--!n0Q>PVV+I%D`r:Sq&aor\k'c(L4OLJRb4-)q9?*=.BBVFA];K22.nVZuH'u(_Q1aGBbaI&o45AgMq6s;i!l#TG2BtHK +%f4@&r1O:]e7MHIN+6iYeK";Ye,+]@k(7eN1FL\LY3sdSP`iE7._+1(lM-Lee?@%UL3Oq\P_8)dZb +%e+/[`N%>_5PY^/+&Q,Q;8"`9TX(pq!dk?Dh91I!eVJWKJg9d'V'D'SAmG8O\@rW0FUPoO7P=I]9::q[OT2_s2.0dYC"#7so%UYAY +%-BoTI?si#;i>59ORG"$@Vgb60QFqe..5DZ[TbQn60<BikeWRFp\l:)[KN^6. +%X@.a-nQ=nA%7Kp-ZFAoF^Jm@$'>XVfh[0L^qI/"0c;Du."Tpn]rkX;nAFnI#9=]8>.IW3e+I%8pH,3TUE,b,UCh&sfA.`V]liNfG +%UiqgJTP5D.j2GqZStCoL;j)t7"YJ`9N2e8Y>L@5@SP-Po+XINh!hpti-.`;F)2C-qOq95eRuYm+;arcLc.f07qg=IYFQ=?_]EC

'V(m;R69]Ku\j_VAEaUc\k +%E50eMroNNcaIf(\^GqH97tt\q#@W^87p,)h%s>.[PW[]8#qR,(r%<=Jk_9;1UnTb)gW.3*%ZCTb9RJ1TXgrC7p,Ao^$8p`4dIB]+B]bV_ftG]A*SX +%q/l\HU&UXP.qSqD0nsQD[s(#o`9bbtSn+k3ETl3NBOoVLhI+`WL+XYPq"MFBcn;G^/%]XSL7VDZGn-B*ruf'aIQ8K9'XeTLq%\QR +%rAoJ`d!s8k_'`t[^8cE2s7ZHdY:KWm:T*KG(jDP96D\b,GW+"%35Yd_i__q,Q93JhoVZ9*CZ+N?[%)[XAb]cnXEp_e?cDo?_T7&\,@<=mBJh8\PP-&D8ek`,Ld +%qqJ?):@)BC0G+?KFIL7.:!LVC"5#BbcEH77j%f$:AVj_._K(CeP-L400A3MP])Vk?lhra0WfZh!i*C&h(q=lWZI:/e>\'Y#X-HM1 +%)8L+Q5A*f3F2WMSmF'nNI4_.##2p#%dTi72[BcZm?t8;BpGbO4V'pu3";P/+VA!6h39/c?kA$(9":jJ%2S&1GK@gs*ANN&RZA+k/ +%^Yf&Lnt/hq,c]*men"@JgIm*o/`M2G=_4(5etarGj04D^W9*(XZ]9^OEaWNYZ\V%Sk^\JO2aK157pa^]rJ,lia,ZuYh.>?k%7X[t +%?f1lAo)G!j^a;[m:p"JVQ*DQjeO4LE.p#)Zg]p"%Jf[P.`e\DS\KN8CF;df&,HeE.OLmJFT0jra,).Z,#-`L0Ce(Q2o&)6H`7O=i +%7iW$!oD02J#:=Af%@6_.B4+R3\`oN2[F3L0LFWUa<6B7?;Yid\'ST)eI1?1D?m^o+/b<0D@2FMe(3Be$OZZt?23Ml-+["T*I"Zt< +%9*#DqLjZG-W9LN\-.uLNPLq\uOmQFGK*aH8NU!MZf`DoM@BG)4@SK@QP_tOEmTLGeGbA*qEQB_eca%FrX5f-.eCX<_=/1a!K>E$XBj#V36SdJR:%6Pa)iit-d]AA&RO;bSSm#,?g7h"GW]VYLB!M;0ZY$C[K +%F9&hF\Lp>fJ3MhVO*>sV+@72Fk\Luo1D2Z@;P=8l:TsN2Fu&jo(^$:&o_%Qs`^OPK(*GF.?kNU4T[/OBK**((`kM_d<"+_:mA4]@ +%0ipJEnhh2<$_XgPKI:o$NYs\G:_Fq)r"lY\`3sRnO0E^_W3jVPB6U3F+aY$s"/)]+[k!4!-EHt]h@pag&%e4A:?PY4kEiZ*NGU,e +%(esb@737>!o'#eqZ[l\$aCKoR1-h8jk#ItqVFTlL0FH)kVc\sa^h[o]cFsKq?pkE`r\HUKPmI27a4D^OjR'1adF-R>b(lp/We$>C +%:[T6&P6^[V?%3=o+o4WRph37?]H0CN,eHB-9sUd(%.5GKHlH;las-E=/-O69]HiQ)HjdK@9]5(oeeo[B6EC2LhtM51%uhLXE$"Fl +%+##.p-"[Jr-E##.I-(NcK:Xk]o[c2\jO:cu0g*=\d?NK3O)TTnf.[Eop7VdEl+i)X$J551mlrVc=BkqWZ7K%blrH@uoM4'AGP+3L +%St*lU#T/,9,_ +%?WE/.Uji\,i1SQum?cFP?"-=*?_m1V,LMF?`Lc)J8g.L\k82kYVeSnIk(dY+@sFejaMKs;)W:lI?q4q_U^-U5^\:,L&ppQ2d9Mn_a,hEL#.#_KW +%;nH$]h1rZjg;1)ZA5$[#Ma+5Mae5geFa9Pa*nfmtXra4iBtDG=IV+O*%dI9ghK46(].SR"M&h@$;h_od`Y=2Ku'>I@rX0`P>#KT\qe-R)'!m;Y[mAfN/9e2P#VRq\A;W'I!)91Gq9+]V;Sa56*-=_h#W0*;UEJ6Qf +%FM]/c`T!hb+Kf2jXlT)nc(VuGh>*rseddI88(ELb!n3]N= +%&RrmU")]NZc32NQ!fJFp@.aqEX88Lu[7@T@#@8@na@X7cbb']\;DkL4_n[A#:)Cl_Ic1=5o64K)_2KstV!dhFPe;7_#Y@H<$Z8M@ +%%qbD+_ub'lZBHFi6PqC#)CI,^gPs-:!nq`W*mK9:\*EgY=8UMS73\\E%Or;f0jTZrL> +%A0[&AggY`PekSgOTVu6#YB*Pg2Q$V*5]F)$1q)-@*i=6f=@Z#!-c6QM6!9T1&6P)dI!i*JSG8"2q4X*Y^jZb==.>bR/L!-+ndPVc +%9[!ou3.7O?VE0ZeNO^V-QSM'hk`%M"ghKHs!`hj22aQX]0m("=Gd7Gd$4AY2b:jh^Y]UVF/j%aQ`GXG^U]`S0_.Lm[+CBCmU&)Z+ +%YA3i$,R-Z6jVd2LS-K.Z.RkV)QpuU)OFA,GS$Y6Ua:d)^0k(:-IEp9:UAY_S`U'G"#_A(:DNo4d8TJU6""nY^H0lU&,npL5L!DO- +%.p]k';nakYVYeU&<.c$)Gp/Z?C#>o4SErnc%tH0Ii$BY<*)/@-/@BphN:dr=:inMtUf')\`YTunL,^[`H,Q;Dk/LP="IG*0 +%YJm>JDk!gGX])4I`8h\Ckp]'a6kNo4gEm5VDTuK+.H'-_(iF%",a;>3]8$opdS:K@FCih7C+kXl +%$\H&M_n_d;egQFU87R^9$Y>HUuFCr51R@'=d))R"lmqPprheK/;:-!l+-p(Aq"*&hK9#bYXXJ^d)?e;&;f3,dK6`fcnZk085!EOc&7mE`0t)O#%_jft;C53,;AG/cF$L'PCEBA0OiTgWEE*$+-8nXb@+GBJSFlQI`d.rt#j=t+S8:mQE5I'3XtIF[Z&4*"cUT1`1!/cPOCpLT,`>sOPnMO2!&1>o6u?A1hn`D< +%(n+aH?M0t>LiS#XQ5C\`rlYWkfbIs1\4?5JB,A^p9eKNh,LY5=NsD:%E?FPoP"LTf\+T$l[1?/t!_'Y-o9:_P>3miBUUoMTUff+D +%M:.X'$X!"LES1rNJ=\+^3Rk"q:U?Go.E+'4&jU1u1F53*m^$faJZZX$p=[>H"2U%t.HkOFW@Kisb7G$NT3ksmH;K(A9_8IO*_T/L +%(?#UoQ"ojLCuEI%V'Cn_IQQ@Q2RM37X7U4dAlt#r>g_F5HOD*uJh?MC.Od!bQDZZ;5pARJA(ZmbY].T)!Td^0aQ;GC5l]lO":!Ea +%m_'>e+QIF@mq=*$;M^R,8e;*IA?rLSaKpsd7n_@f/PW$>8ntF]ZHK_-<)(@DKK*KtR+''?.K-L@;!M=EArK=B&$@qAU(ha+4tZFC +%YC`!=p#^-T/jAlk(6`h=a6ctsrC2)V=hIK6G#)ohfo505(c4#TC`tCYpm?3gF0%'NOegk9lL?/.'>=;kpBPQ]_\sob#[[Z:^7YAh +%rZ<'GAn!NR@VleN+Q,#K>Bk)>Qj6h4H/=P)>Rl=.R%U1=WP0#oY*-`>I$]2"dEZPr&H,oHR]-%;j;#2)VH@7tD3J74T@Y6\N2DY\B&,X?C^*u#kUu`L\en'cf3@DZ@n<-$8b:GMY4@b9B1[*;.++]Z +%(g*^?JJ82YWoa4CODJ_K\pPZa>o\k+#=ZV1LQ2=/JKU)l#[ +%o-Bu(oI4p<4%To4"ClrHe5@>@b6B1X**e*Bf9:h=Wig,8EmdN4SfUmYGt*@J..M;/Zt!"B%KfF_3f]P/,#e."3MJpm09>RA'Vc,# +%A[[I4Xbe/B(4M/pWp\r+hOosY=@">;eYF8D&U,$b<^JJlg#n@U[@;`Ka_"!r/ul$Anktno)JJ4*PL*1soCHEUX%ml.R4KW;5YhjV +%"/iHV\jY@@kfpJM[>U$0rY72kcb[=h010)Y\F1KJ>M+c"/a5>(`D!oAhPTV\YjKKn'GZQGF17[WWY2:uak&'=7=*PQ5S(j7jjPo5&D_XLqCbR@7JDH^JWi^nn4*M+g!a)Zl%hJb:nZ`56NM2W\.h*%0`4*^r:X\(n@kb&m(_LNe +%MGffIcr#B*"e%>L#,=ck%Ftt2!X2Pg$k_M07(?9]q&]:2<,P,d[hBLC:/)7bdgetePjsp+'hFZb>?R"n[#dfl-,Fo:<>\Tj,;3aj +%:2IA]ZkPk9lu<`KTcfDj+dcfK1Wum,gP@g"4!30)fEPm7`5;?lo%TB[[+2T6;-D0Q +%>;`a[+qfNuLY-X*+Ghukd6MMW)DDl7co0QFZ$Q5SOH+1s6Xid[&/Y)W!aUY[@VUK0U+Np7_cAnQZDCa1\`C.C&K?As+utY3=tmHI +%GugCi]fS&sT*'P->/aFa/gnc_Kp<@tbA[,>=SL6`gn$bHH> +%@QSQW6)t,r]7tb_dRIHPN/'Q05U/XNb>P\#"ZD!R'5,h)ki\Vrk"$q9fH+"8YZ@QU8GH+qE+pQE(:Iu'5*LD]p_OMjFatjm`&kn9 +%Q^tK8k"5a1D3qE2,T<+r>p4&GZH3&4h#]W,aQ]e+e#OeVP\*uTTXeZ/(/Oh1&=[,1((Mtr#?kM6Pa*dOr\EcJa\GB;1(D"K0,2up +%Zk%;,MY#>d$aZ^q+b+a+JA%>MQ@rncZ"p(.1$(H3LFuL.jLDRA3_eGnb=,M]MU;`D])6@rG`fpg;nndag`4J36TV3&S!iTt[US4i +%;!QOWXt_[c<(a';%Jb/+&ruT6C8Bb=_HPLp.#9_&&pT$3>0TeE[Us$WKfPJ4,cde*/l!8"$9'6Xu0^-5(gSSdg +%J5`d.29S/j,eK0."=b$]=L5%;8u1GMN5[,IZQa''4AaJF:Z\:AK79;?XO:*:_.2SB=`'(g0\qX#(H2e\,esuD<`D39hOqi)4s]dA +%4LO-Q#?Rm!77)%Y*`3Jj$I>rfC'kY-gm3>,'a1t>&(W:rDU.mba8cHfZdC'81G5M+l'*$h%d-dW.m3Bo,CZ1KX=t/O +%eBC.8!(ZJ63Z:^:$&MIKG"bPjG9skE;qh_,>)"$Ejj[A:J/OAUA59C/-YX>Hd^%6"/!ben+TUecM>N\Y[L/nu6!'?9;_51BlL3b> +%i&I3D4Ci(IS>`g9%7*;@kC?ne!3>/k\MD<1;GfEH3t*!&nmO,$1i4[9bTO5tl%5NaARocF-i'Cq(:BjW70pV)<1Y3;M'=)_Gas65 +%53bO.:`c^ZpOa,#KSY$'f`mC.3A*=fATFg +%Pj@"g^kL2Td9l&^^p-9A'&M`V-ZIu%`[;:GVtqXI4?WH$E]>?0i,?K$E.OZCSAZ:>8#f=NmDQKX7j;'m@ZnNDLC#,tU6a<\J7#56 +%5h=T_HS,?W@\D9"79WF5:6m=2:8eqDhuM\138cM+^`#q(2A2&T0"Q\HADmGo%d'_>NuZ`DHI8 +%Olpa$2FP<\W*+&MN?\.KQ^0(-/Y`"PWa"hCF5gI1ni_;Gf@5t]Xj=_l@ +%Ig(C*Q,c/!-`_EG1dNhB_+=4QSP#i52oJVP8L<%:p=es)_JDkU;2fUAFA"3?lC3h8^Wf_D/e"e&$BRN'PQdJQnl":hX/R(<:]Asl +%a_bsi5ThjLPu2$3LDo?U;cM,U.[L8aIoQ5FirOAX2(+V2S)ZuMB#l8TackBj7d<(.V:Y$PKUa*4J8W/!8:P"n71uVcgUBAnE$:>9m(n@o83-S#:`%ur2_pO$%0Fmc)':NZ'^%Rgg+A+]3 +%5c!M"0PosRJes.@%[6El5)?d?h1/%(Nac21k@oIUWN0I\A&u(^E<'S`%c;*&(3c[oVs(Hp\1-[2;gj6a4gN<,o,s'JN&q(db&r*e +%#"Sf*`7,GV":4`:15`:Ub*_]m2u@(M&lJ!gll")nEl4Uh#oH9:%Tcl<\hMdUdqET!)f.MM@7F*K(p/VXpRK?b%1a,bc!jQI"lSi# +%D$-8fDUbbV(75Rc(mkqmNc%P6/=-iA:U1FVD)149REM;l:Z2f%_A^-Wm1aOP1u/u2M52U,;oP5l44rAd*K)g(l6IQ]t:od%7dLCS5HM?0D$KM$+$#:J?b0M_k(0Xe/;IL7sJMmq\R?goW/IVAB;0' +%*:u8;1J.M"XXePMQ`>Bj)K@U+j[<7Hm]q=D\Jh#u<0t4rHk&XZUZe-bp>^q/]h]$Kc#$=V:X@Dh[,m[a`d%a^'UFA=O.D-CY?Qa' +%3dGGg!B`3@:4hL4[iHd+&nRsYbe\>)JY9SJjeAW>i&m3fXns)N/-%pZX#LRDVS$tb%LuVOpEnTAdFlEdhrP$M+>sZ\a:_,e"Va>Ft9j3l[[V-%6hK@u?H$j'gA3&).VKkkUF;,\15-p6.#+&mpoea)%H5.utlcH67_uRs]jaA1ik.48Q#_uR$D*#6i3;L?4dPIpad**ab +%U[te-[2bhJMW(9']j>>"C=e(X1VZ)ns#))+eQP*0Ys2_6g8t^ba*h$"2u`4r;H1jrFqa!dKG8^T/ilKb:f-u*G9DHrF.l_r3r2^K +%,_;a0XuT#]T4bIh.NE-mZYE6#bpc)WVJjnRl9^i2aXdK%H&8N#:.W7=")n1m5ZII2bMg4)$^BGrX^-C5$Is,-pJ[[`R/.O's7Omb-If'OJ&Rj3Cu;3Ha\` +%5B1J,&oBCo."73TD5N8V$^K$QM[&i(?O*_W3\M&_/;_`9ZlMU\?l(C+q&#)ghlt$'((0=E_bhQe/"CZ7>Mr]>d('J#p"L][*%O_h +%I#>rb]?S@0DQ6+ACik;rh;G.<$s-(U6"1SW"g:N0FJgj5mUA%;LAs/KL=;gGf]pLn<9'j:ZP<:ZY:V_th'EDq.%Bt/>OMn2!_hA$ +%i%rTjh57B)CDhlq:J\!i@,`PkeB6J\/M.LEH,Xh1rNL"`,16p=TrtAb&`T#dF!`+>qN,KL:/JuJFB!5Aq?Hp;s4\e;Ho3IjZ.(OB +%].kB0]9(=8W2U3K/("f7g(l$8?J%7*:t-T\KpkoM!s%\b*LES=8iWL2`k:sumoMX2MI5-/E?V\.>/Tj5OT7aJ#u:tJJpkFHokAR^ +%oM"F@6ilT[#7S1>YrB8%*en*):BS7(WcdnF_U7XW\0?1lQRh\q*a;tg?-L7`9,IUf2`\Tl.r+" +%O"DT%4lKugX=Z7T^tW%ZfiUZLg!H>P5;8hNl"9c\&ouY!#H&$;/NiI[V=:rhV/W&Zs7c.(VM7l?[:\,tK95Gr1g;WUWADC2%'a8V +%GV%NS9K5DD(7+41_]r.aE$^eZIqNC?c%d"H_e;Y+Nr[R`:PpC?`B"go0EnYfi[J(BQPR&@2anXJ*oZYLX@&Ij@mXcqF<.VEgo*g2,4*E*Eus=)-%CuYn1^rSu>85i>Wp+SlN#*Y4UHDLAo'^6-ucNfc"=ADCSnGWb0d?[M9,6otWHh +%["!2).VmStA51>":C<0J%',p8h58emrgVf2H'siM]"L?qd7l2\#_7.YPaehe0;\o:;-@^WdghKgo3#O*?tR[k!6gB2aTEZZa1YuH +%``J[(>=m[+^iIO"E0LDKC5`EG(_uP1.GEs%L=Z,nWt&#$a3T9YN&oc)"\m!!m<4-obI!Q6CmK.:NWkc2ZM/Pf^!59)Q@W$E^B>Ya +%)]-&XBsFXK=TR;0B[$os(Sm0)])AeNaI_[*k6S_&=ntS]O41\2=f=#lI&!X4A=3Q9M3?tN%g($57$19S%t%hi@d:+:$ld*#f*,?_CsCEP,:u@SPA_"S+q%*bcSYo/di:T^M@PH8SYcMFnYhp +%S]$7Ng38?X,Rj$X'O@F`$OSpJ0&/>7K%8)`]\T\d[o/mO]^.oRB:G6'1O^Z?mm.5Tl!K4'h/Mlpa#0OSJEb)N6I;G]4Jl$Ndn6f! +%J9V@p*+%G:?\_Z)-)A#Hr/?*Ch,>TDb97BpiVfp%8O*<./(CdeG%AL5+6qOQD(eL:+5$E^@E6>:j;^M/V;$cV&gX$iWfEDtOtMtj +%XO0M'V"dX4G4@E.cNlTc0!7Y+,Nj%$1i.^s75%*B/HfFh7P+CfLR$_.$+K"X!XEN,ZI',r)ibbg&Q-5,J3pJI'$+oH;:,:0<=+U6 +%4;[o7/;^092[(D-]*,kUlc*#-n\*.T%Q>lM=4D5@I7!@ElY,2We6ML@fH8E()ZTm25/]kg&Nc:T1o[AtTdd"WV:gp`f7/9AMt3>F:*=8F.KH8fRgn`rM;$L*T0XPD8sD\J/crLjpUG9[J0n.=Lf!V;.".83#] +%Ba/r-:*.?`\3>AnZD?[lZ8*Q?!9>$YA)62jYV)%!kTL5t``J$G)##Y3rAam;Ai2=\1^\,9cBF)W&VJLa^M@DDh[u9'paf(k*JAbV!R7*& +%ra>?;2l["a/MDZg@6&A4#^3^QKLEt8OChkMS&]0rQ<.l"9G1[A(R#I="KlA(O]$RP!qAQk;84[cgNiL\dGnr9\!]n)c*:/344Vb> +%)5s\GU.GLA!3Hs+ZOK;BbL/[)Z_"uOdS!H8;0OHmB/VAn-Urepe9FteH1X"a_+%dSp*6ZWA+**]^ +%>5&nfC#^_or>&[&))2k\:BCHeQ'iG,65EQNMi3;+D7ig-ZY`>^ZM9j!FY[s]UmV7F<8#aL,QRHJp3aM*[,-mI_Q6,Mj2XA6:abMBh>!UUQZ>m>Ak2l2pcc5qtroL+BV2H35LMU^5,9;!Gq.N/0%L5(hgE+[p3Bn5^2a +%@!=OeNSAU2>dJ#@"JDt3@[FgFnnRYq3fP6=Ii.9O[L_m(&)hcijH`N19lLY_m9&PAgP)Qo +%OpT_8BZ&77NGhM40"!#-<.Nn/Q?,sRSf>f4i`3IaHt39`2%6r% +%cq.;q`.hij'S_UN\CGa?EJouZFELen%6cFtI4%bC0_nP-11bj1SLei2^,+i6_M^c9)KoYs-s[,rG"68o8kqCQW/9P0L:nJght+*t +%@&ZOd&;*\LhumkPr%"+mO@Uo]iDaIl4:iG1]0fLB6K!!][K=(Y+%8HHe*dOk5%:49h70c+Y[56P# +%fJF>8D,]l,o,[FUUL.t:_3U#mXSZAYW*-P'&j!]SINg?F@._o;Dc=*"Lqbhp.YDQ).-k'4A&>DKcZd`c@pUNH6h8'dbOM]u/]e6@ +%$\#NN?e7N'PQ.Gu!tlt^;F[i6p*7kpRoIPW]`.mp(Xj^79X);CV_hG"1IEk<8DkEf:@*%>4fudhe#[+"pG9: +%[2/0Ba[.C]F7@ct`SAfC.okEp`@GT1+M:(f46Znm*AsDGgM5&(qnF1Il.Z=heb7YN<92I4'f9E*[-*9MXt')G'9SW3'Wm([VE%c28ErVEW2Y<4"<)Ar5,T`!.(b]Pf>Y-`i>.et=]C`n-;.U@ +%lR"EcJUX##$&]__d<&^*BQB43Ih(s//H#)Zl)QA41`.%$@OFLpLNS7a13Urb;oQ)#.>4T')KBEZc"2g8Y99(pMS4`Z,%-rbeus't +%5\qq-f!U*P5jBTBZQnP*m.Zidi(K,h3LohcSV$Hpi"',B[@8$%3R"sX8;]Xi*6WBCK5$g[Bh_VEK=iOK?.d2t8^4;kiiY%41E"r1 +%)(6B>[$eJ].,cFt^CpI31_@WN\AWe^;i<$oLmO7TF,u=\*177X[)0GW_\B/0%Nrn,eP,]2EP>$iOpI9d(0NYoYRX+Zb2Khp$j2R% +%-CB4oGRi179h:l#AZ^ob%DNTo8KWb!]Md6B`fV^pN!&+%))DpUIu4.QK)[TdBdghZ"Js^F4=k+^4]j\+]9NoA7f#"Z8D;Rh:(RJ[ +%%[VH`@qUU+;Wj^;@$U!>r*`So2X6/n+K6J.M7a>/`@P:Z@UF*uNd7rC$!iJGS2QNOlfZ$,3AdZ'^5UQ@`]jO5fZ<9]*D*WY"=g[# +%`]UqAK706:PCR4VT,Q1q@3t<8d(0<@+5;[1TPX0KA0ps0raij$i7++-;HDe'K&[1om4#k"))>Rs[TGR9Dr)8W_[3m<*D"$/;G+$*Z8uTl9NRMB +%9*HoI.9);gR&Mg&nms,B]8o30rbf,[2L2Q)-pS$;U_Fo'I@4]B[P)BKka@#i(Hh=PFO=o)buRFaYnSuY3hM/)6[>(M#;m'5+]i[W +%(28J+2iQfPic&i-^6Wa7Qk#TD.OKH`GIbtq*9(&8>(:5H7o6$b0NfhDpe@fZI?,t9WVR;Pt)ET!03eU1khZ\-'Ca+uL_*lKUq9)=dVS+D(JSGO\ +%3J521_UuQ.5B_rg.[jd=E+s6ElI8Hk,&Z-<[n/T$.H:mj&eDbC_?3;BA6>i"8#bD)Z]'KYE!M,2qMpi2G5/A+IFk7FMl6erRnM`` +%$rO7@7^ErRIC*ok=AmdR,X^M%L7)/<7N4'l%eA:(T&%VXl#`8[NZ^)Q7N<#idS?*=iRb]1UM2&I4-$qUZ278%!R"@IKMOHY]+'&R +%$m4nL.U0Hr,8l%_%6mP;;9%FEB'CTlI1>me5)P[SS=lR9\BoX<3Kau^8"-C[E?',DAL-iAr8h3VeZrX8&[s?W3)O57\bs/P)*I'=p!Y&$"-.]pgLR>$u's`ps#C?rV,([DZ^[hfn@*50b:Z^.)`#/Vq\!1&((b_$>a99"6-7!M +%)3Me=kCu'[\ua+c&VQ0eU=M_W?ogkdMcCW>!-mI1EtZsVSb'%b<$g;l$A=2;5Js@!IFcKmsq,N`R[djLu9*M&O)ON +%&kX7kXMmqhnS:RESI;u,A;C'pk(2bpL^F3=Y+M)t&oW=R\YhIfn,L$&"&AAc"bXI#JOC*7TE%Dc2*1usXi/pr/BDsK2+Y>oUVdm< +%I2^s=0uVaD6/a8G*/HM("e1DRCYikKED6cBA?1R3@Ddl +%'%O/%Y[@ss5]u5QF1tfkj(GmcflbsO+G(,(,g&S\mAmW2!+r6rU#\VGW>P,$UfSWJ\g.4+PL9X+_&qN5+o&A1D,,Na*Y&c(i8.4+ +%1E:!KAZlP,;1Gle(f\Ag&_n+Y]BkhTdCHAOK4ATb]Mg.+;hD=1R,:^F^lBo+Y\10o_R"R-*!WMXC6Jdhb$AI0b!4T)D!siF&5-HA +%D%W*>Mam6i>]JUG$Kd=CLsAr]('0+2/nsR'k9Eo\OY]8k.Y@14SB#;)cH$@VHMVSig]%`Inbc1`PiWLLVccR]&;^\K1Q$=Hloe@\ok\ZJ)bTJ%'a:+_S!H@_VN"at)rm?J;^95S.MIGt^ +%X#oj!:'/+T6V3L+<`>2eB_.1qH"0+?t%R6^,Z0 +%MUF(r7d"Fij\_RCTu7="a!)cMS3hOVnF+8c!oU"ee^G-O2V$<[feDA5PfDA?([>Fkc@Nadt\o86SIF8%U/Q-RFG?9HQ- +%dPsTGNL2NW,p`@fA#BB[,\DI#,$19@X4[=RaFM\Kd+6-mq-Qp-Q2400^!1%FDR9*?::$oL#=lYZ;Y\Yhmnls<:gW3iZD_qKP/qff +%?'cqu)`_4]!psOs+<3(pV/QJYM\uX+#bo@9$m]%(Q%/ouil7?Q`kmqhm-I(5P[^WiU\S;nLhVi3KW(E0IeECp;1.#O,(G7pbdto` +%rN!(QS%o7Q38:AU[Od#65o0ru&dTUK=b`G$FI`=pArqNDk+B.dmZVX[^n9#I71mF8F1^U3fcpT%J6SMe!EauOM"Dp&d9Nb"'F)4] +%Ui\?l#<]pq9p#s)n7q$$juF]iSOm@TT+Y4U<5:-L,\9^\%V$)pLIcllpeO#-/4#A(Q4lM(:e4"FR.P$+p_phfIQ"!9'_$%2@9JSA +%%'uq5mQrpe1b&I)7cGlW+R>:e+fH +%lj.h\-6l3D%"&;2SOFn6U,&n8/qZ2K@)J^mfa)N@FG..O!3?1-"-1dMVk8RIPY@:/ak2@_,5u7L2S\7PF;jEPG0]4pfB4Hs\S\0: +%dcPfc`Ffs3m%p8F%"e8lA+KF\LQN=)L&+O(A&U00sd;FjUlE6]>&&0!") +%R/YHnfRf$!!VV+J/l)%h?aKGa+hqPloRS3$AM$eWFbH+*-;=&W2=*N[U=Fe:=R^m:E@f9EL"I&LHn$Ll;bV"bX+fc`da +%2D\s7hs&i;eR,R4kWddu`$Z@F/Ib>Z1#K%bk@Ybi\Xg'-5O6J*bUA(Oe"WYc^nSPnAraG^2)*C38D,N`.lTW<'_1\i;lsq;%05;n +%AG<5:'6Jn91\bI]I.$Lp"TPCRVob3<]*1.o:+CX+"gld>%9k==0Y=&:)TJLcR +%D)%'EnY.M-@ILMbQ=Umea5V$rGiU_sd?K,;;*9"5Z]LJ%q*nFL-pGKsW9NY@rN)LE$)d![J!eIudmFC`\i0VL)`lL0[c+C.3B^&b +%f#;(LeM$:"AL-#`^;N;H^o]NoWb`pPVc`35ZPfOW?C#B8i^utK]j"&K#;3h\<@C/+"fJ@6A4$\_(Pc$LNb:ed +%Go?H;X?eKhHp5tYR_sm6\u+b3[$p/$1PZ`[:l +%;FD>+ebM$2*&d?^7&:*<_Z'bXn8o/7X73HYg/*MJ3'a<[pZn"jQegTiKdfKoV82=U:N$V"fORusVZEXs9UOp&AM_s?=a<@ldjRi\ +%ZjUAZkD=&;W2;IrPc.?gK]2ugmc<0O6CqG6QE[-7+C2-U?rHJqs-2Om#5]k^Q.Z]@0fShkROFH3S,/5^H8SY)@,=+3j1Z?Wi]'0g +%U;A4+h.2A)N#)!jKHEFJ3.c/+HB<4^9Q(Mo[/J)N@2i6p@0ipI'ja,%l#"+J7?&\\$ufi%EAeN[ +%l2:TO&bS"iHeDsq,`6Xr\2&l0RL2YATd\&r@o%r\DHZ'4GCQk>K9K%ukd&KCZ$ohL0Q(DH&Wn'$`afeD$pDF[Xe7Sf&@4pq[C?qt +%5%C^KPAkt_nn-/g:M0.fR7J?,+nUm[_33eKkFs7W^Hf-S)+F$tRsJg1-U-osUl\hk]2R[??\a"E=FI\7rb%j>B&%[Wdb?fcS-ZW6 +%ST_k<@G(Y#8BuHmTJf&b(bg8GuDQ:d#'u/_mnXRi7HG$leQJY-d"?A3[eJaW$FFpG#>@ +%?Jo$nTeqj&&I%2S(rYJ0qD8lt@=q\(R-B@[d:0`Ta>*;'9CFuQQ\.=sXb9h0p_ASpq-*P,6Ypj?WFr4#V:/gh&XlJ^3:pVXA5M@65 +%e\jD8a@$W1,rJ\Pc.&jXq-t!@:!72qfV859:08;IB6HlKSGGdVB+sC#_(f4;nX$8D_rGCF:f/=3MN+-`!JP/P:VfYpQ%K7]O1V`s +%qeQO."Ao4!=#;RXU.Va@$PEcd$E;&k&/RsKJ86IYZQkq*cM@6*J*9B2M39!,@$s;/R]T5LQ*GH&2Z>*aR`PCMY6tJ'BSeGCiPU%% +%X8c:6+d(HL9Ms=]tVT-W`K8l;&RO"E$E;EFV#CdP:'(!>oiT]AC-]8YBEkr$I:G`Z#A=^LA +%<4:'XTgY9H\skf2@rsYT;GGI`4LB[U*O>*Q(R\![*!.^0"^3kYTLB8AKgVbnl#%::mo>K^"h1TB&^;=/]t3X$:q0c6!((S*j7mG3 +%X,I\KWKI?r7X%FQTEs%.K#+mOklDYI!XF/>%oKW1#>1`#+oI@"]1%_&:^Y(=2?4=ci4I[R8PA)UC37jrIl`tuAW,+f.r0p[;8U0Q +%?2@4KJ]Y[+RWUDIB.<$5YhL`0s071'9L?CF;7=%"XDZLf3K!tf-gDW67jer"T>TMcB84-!6^UuID*e1\Q&11snd.%I'l)f?=.A63 +%KJ*?fkhruG&;`N@e:],9AI:/a81K>;.JDiYk"GAt]?usI%$GB%%69#+h.5jaFOBYtX.]-P2?YJAVXj.g];*lB>%\r.],CR^(ECf% +%#B''#`&8(m`bB)AS,'>JBdX9o<&VYXZOPb>AK'H?'%"^#_#i\V19J\lpiIXP*Qp3-7$6P(JL$/_=Pob4B$H?MO$ngk@/I1b+MeJ$aDs!4T%GY_<^!?31;p-,DrK&^tXTlg^o"[4+[#HEdF[D[6B\*@!PaHp30%m4C=1jp=Xm8M$8fg^]]mQ6[Ms0>AD[.7Rr$'C072C1eUkf9j^o_"uiMGPX +%AE.2V7J%5YkJM=YPOm]N@`:uHQ47/borgPF,^5W0$NcG(ou-bg/<6+UI&C,(<=gHa6R_0fT7H9*67_T/_$j/ILa&cCK>Z]fh-\,Z +%`s7o1O$="#[0-.l]T`^Rfr3uhmG3G8^Y?A!"Psiuc)@3X>$^b[_G@;.jnh^JTjoUJm82%$>Wu(0^r(221ZYZoL'^DhE)8=97/rur +%AJDSZ/@L(k!@p@ghGrjGr_AYlfuLl2BdB_mb5>SK]L1;u#pP/q&Bc_%Hn==#99nDl.OJctBnpM/(1rO(%6U\Z:?F',DKMDC&e?.m +%,Dcj5_HKL=gukRbaaKeRVNQRg.,[X(`tqa#E-`b+XRbQSZEm%Tb*`k(HDd4[*gV8Cj9?q,AC?7J`:K`PdMu-8SV%^h+(Hb=mZ0(c +%`.@b(TN4F)JT>#?iFT8MghWD7>t`kg@e/J$b1L1M9,6HF^E:3Lk;Xo*pn$afa%T<3>HIUI!-4ZQ-!1PN-t=EtO*ju6Qc+;q>W'1? +%:-Gr$j/E6M,J0eC1*flD)LlJ5JVE>rj:D?iPpV`:Pl&VF-ZHp9E'u@?L&N(7.Fn^/3 +%Y]@.3TGi/F/IG(+-SQs,/(i<,$%pbXW)ed(OpA"A6"jbRFqb.]@Cqt++mD\%j6Iibh$4,c]DLrZfT?U8^ebQiR)6j[9O6]HNjb'^ +%Fhf/l.SPR2V4"*))#8$;)&!%#IF-;qdm?&HDA%WcU],mBeM9O-*+],C6X5*up6 +%n;fUF4V)AV)N+/@%_5QOQD&>Pb`>!.7-*t.>t![FZAk-FY>tbs/8W!HV1Z+KMlr>d:7Y"]ZD173Fa8i=P.)]<+Vt5u$:9MJ=7[]Y +%9@gdY%>SoVWc!ZL,XLr"niB19#"`K"5I0\#8d/ +%-UH0Br^I^_s0T(LeX\qT9',0Z,R`&Ng+^rmd!7s_:0aTX/b;qTP%8DL9t2[R3ab3IJF.Z8R+1O(>CZqM*4'/'k_,cWhV,5aaU\5a +%<`+N-iJK..hNFTN[nh;TnOsnoH6FO:_2FL=\D-Z5PH9#$bgPg!D]hfJ_TA&]g!o_b+tij3qu@r;nSELGa#CU#3)f1_[Da)eW90h& +%&,UC'7iU6r3)mHl/@!jdbd@g5M0VcWS]O#pRhC$I<%&*XD'M`74\9$O(NSk5-hpT'>;MtjqK+*iE;\_s\Hh-7-K +%Hd\;,kY`;:_?Ku1Yl=t*d7>EWe_mY#)F$hXqC<`s +%!L+Q5(g)f-D:<:N;hjU-*r+j/Mtp)n5DJn/s1E*:kgh.P'KE0XgoZUhgj*_"&?*_MrmHk*9NWGFZ1/!.!-!VF,])0dmNi!Y-[?f) +%IKOk-`3%$1-*c<*CJm:dA5d.g=U(if4GBdkdT3(=+!^!DM#iO\A-2OAHoJD0QoAZT\<=qr81d0^#e:*YeF8]=(Blnl,)%-u=IYcF +%r`aaRi?]sVs6/'I<'ZRB60/),;7Zm%<'$-*Qtipt_0Z7WR\WcI%?l>$U>udX"rf)&R(uf@G=o>Z5n!k88Q()s$1o5"bre4+PM&6U +%L0D?X%I5IfZG;SaK:G2L?HQ[Z^lmS0I=Gb#4h-c#h1YLh'.no3\-F,;!HaJ%&6m%PN]eF9TiqK +%ncu+S.Y\U]@gELa--n'f.=HB_=2lA/oQgtc,L8Y^QMD>V0uP9k^$L[T>6?(M5($,0V`W'RT57&8`*"PnY#;-TYFs>E,pV0!Z!=5q +%G)JJfmBKUdL42E_(V]qaT%F]eA/Z@[ZJ7HN6#[f`a,@FD[\71KK7IfX;PC+FbPX*7Rq[>u&1\)+)'RNCL10oiINoJs2@L0"&.&M* +%e-?NeIrnYG;O1Zu.^4pe$mV0LV(Q_[n^su?3QXmO3nf0_!(n5q[9k+@JbU#kR;-cLiOBGj;Q)7$qf8#Z$Lf(Q2*f<;C\9F)Rq[XO[F=men?0JXUfShQWXsF.9FboY]CQ(4,r$^i1,s?q@."XCIL;?(0oA$(;:;)VO +%mX9"3Xn\W*f(i'AXhs4/Hr6Gb#AmjLjdL`AN_Y,S]9hI1WEd +%:b[9Uo4FVeQ+Eu6UFgS"#Ue#L?TJp<*sIco$(Sd>E#6$*oR*S#DQnPfB*muVl2WYH2)pG7]hlf\Z#).,W"_"?=+t0'@KWF:lSK4> +%P&OO2Zl>VT8jgQO.##2W#`sJmh1p83cd.2J;^iZ=_V5q^GciUd+C3L+1p%/Ae.?R;XBbSYJ+kR,RVrOgp4j/4kSmJC0K/1XfW,Xp +%k;u,r@%1-=YRh`^c,cmo>)FT[P\mEmaP*HC>4-')_?NC`&Jdi>lT*+sR42rUf(F!h3A&Z(+0pPLJouoA(o?BL +%csm$61=4)J@>gcH<-@9bj_&fo`&L$-$L\Xn7&kf%`d%rq +%ISA^"B2VPI0TltXKFM0]$A&gHra.;Ei\#!5;5?2B<>1dJP69["Z!h>WPh22_EAc)VWk6E8]jf(=e>_lXTMNf4Wq&b[icM4Gi*k9mFSqN(Wm5CRjqFF5dc2l='k&#c,_3-FFt\aS&$O`+82ddI[Oe-L.ATb'CWZ/h +%d885-G_f[a<>si;,f-VI$77>)DNZQqaQ]-M>+$*VDa9Gh%re,jkZD^pM_V@ij)4eVlIJI'"f*d&@E*[kiOoLWJ=.AI[>`@-o"(lp +%i8T]uXX0F*l?3M>nq]i.B"^pZO*NJJKq+Fn.5RiRi&=>";K7Nu/Fp5_gH[ZG9)LP:K,PMp"_*n6"B]W3EM'&Lh,dKOf"m)MRLCf2 +%>P9XH:L=#U�qm^(B9L6P4oJZf/cQ^iIj$g9?*Run?2+=dfR +%&^_0,*6o.?beplu3Vi.>\8$#JE-=5b9mJWB8pQ?*Tna8aoE`HqE%ah;(/8:k0OR8h,%,GWp55$A7G%`="uWQ'<_oSrL]Qm7\O=fp +%iD$#h'A+.D01ljC:rS0s7OT?!0Uf<4m&Fs]N5*SWMjPJ"c!-H8pJd5KJ/g"Cfp1uC3>FcT$AOR1='k+7i24;PMgscqgd:WqNHt]7 +%r0[MbL2/P>br[6s@Tf";n`j)3=VB?eW+nj)JNLX\6F:Gc)B\K-Xqp;_0!7abiQMqZ"(e!gDQT_LpiP@40>MPE. +%L"0dpoGW/A#!O,9_=tR%Nu/:aQrJp[I=3<.blS^qm`HdGnO0'"nB@XpnD@Bn7gJ.>l9uN`2t^>T,+L^I#FtF$9@Zlm0[6/ +%#o^AhQLc/qps(STr4ZUKoqqnA:u'l' +%XnLf.?sb$KMH*l5<@U7tJ0cGuEj%,SbO@9#gXZD(!@#VUnVaWSKo-\ET0.6D^`HT8-k)\#nE0rq]0UC/s#cE-"lCpi]eTuj4W7??7* +%?M6kGJ/'5PT/c-cCp_0,j9[9O#m2iH$`+m,NQh:($_e^;%o\K`86_\mfP]K4^2].>s&7gS^mlY->68nIqaFI#jA)^I`Un/$ck2rB +%F;f=FPRAb^ib@-$Pl-b+`a+:X#fL&S5*>nKc$VK1S!rtUjT&oQSYr.JSe!,bQXn?\#W#Z=3o>fP6(/bWZ41K@SA6kQ%\]qpU8 +%bZ!![P;`sRmD#4Mi3FmpJ>fYJ(^Q=A%bF,9`j*a/FU0Y1e;7/[C=*I*K+V2h?A`bd*R+6Zj1rqqkBJ`K9,@V5Z6AKja)P:^$:+5r +%m]sSq=r@aS7n93)TAoZC11=t3U;fjl:K==le9=lV1FkAiR)2da*"`"dl,.MDbHC@o$TKqsRG8nFKmDDG2CC`O`pjPKPu(JA*[r:P +%1Ui1qaC>#VL;SZZ"%8$V<_]"`*15,B2(-#.<)9p;-]&b^74e4mN6WR45hFros`c.+mb@GS6>i=M\aHOf:cQ!q>kPRk$F,2*;DukSM*'86`g*T +%NIATOo)%28X>>leqnS+O]#B:u*d).@o&NF##+-H0^``'"]"M$r0Qe-0RabS!bRUNbk`'1K`(]F&Y,([40RO*26l +%YZUQg9Al@d#cYd:6,1eodH\Al4(XsQr[[ig8SR#oTW9Y+H6/;;)$Vq\lVrIkbtQo/lED6UruafXMoPn"=0J>jiPV\)7+K&nc$e+_ +%8@BS)#uqaG<#DWGA6/bcPio\_VnYN7ZuK1[L(oUA^_A[>%kM9l+j7Wb:u:EY +%3?-YrnNmU?m6Bf!Jq_pAKtnpq>CWYB#a9oA&-l+$,RnQ\!hg%KC0RA],`i`H:[OHg +%_nP$P^iD"ia7D3g%qZ[@\%6T/[KDG_JFd?pQ6BH9c!9g;W-U_0ZkJ.L#/$lJ*_Qgm"RqeG=[EfjPKYG\""Bic=&,0,FegR(\'baV +%%?5O=Ub+Y^C"BELmdrXSG[_Nf)UI/S3nfUNj;VRCV]?0i)()k!MWqog&,EhR9F2+@"AhY^=h9m?EbJW"fU=uq[d"TKSjM'D2)H_r +%fT/R!!#-aK)\`439V&VE6U9_`@,eL"m,>W"m&Ch.'?_gnl1g`n4KL`Bf?WV[snLM6aX!Pr,]2?US2W([ULCiRaBCWS`Zo."1L.t@VP)G2;*%?)i+cZFpF +%2J0LU5)6\)?1?hNO*\l9`.1fT[H=WNfid[+$(,,rR"/!H':)>pN=u5A.+2T,2!_sZ76FDb%ZjAE.9.S=-PjRI1iK^r"ssQ`9Ytsf +%3/'1D9KRrtV/j*`<`k%qm:,%q7XgCJfF95mi7Cb3fOf[;0p_nP6_W8AW+-EP#DfpPXeQJqDR'io)p&FS_W:o)=CSX!/+OP&g[$0e +%En$lXTn<@*<)F/+Y;!c0QK6b`34e=06KB@@(%<:6Do3i`'H..C;&7LLdNO381GJN#5Q^[W-fYBnFh1>>%X"2!YU$=r,7r,OXYT>J +%$t,&#PJ2hD2CiH$9*"ujp^5ULV>N9!Qg%J0Ak>IMVjJj(7W@c#[.Mj5aDQ1E]"-V91b4VW4OJ:uc7X'EOf068#/6Hq/=5*O&N61Z +%fcUZq\#sf]lBmB(7,K%sGa&jDkam#%*@3BG_T0]9hPS&bn?NVLDYB@(Jd[,)(E'.'I5JNm(8U\Z.R6r$^gHZ8Uh\?]F5I=5VB)!pa)RDY +%;sHan_NU]bV`$=j_T6VHJ"VF@/AM;.!Xqs,CSf=gaNLgYJ`2(ej__;;.ZZEDW1!Y93Ou[/R*Kp!gi2SV\P#+.9/??)>?HM@7F9%O +%UETD+EVL^JP#$](>$i\XfDB@BUjidHDC@M>-&kRV;2G1M_3gqB\JK,\(IP<$GRDQ5&!.Y&6_gr!0D9Do_)gP!pMqAT[YZ9PU9 +%G7W.eFB-g\f."-3L81-W#^*/nQ!(Z#Wi9F:\QnG<66YA7$!l]564mms&P4;U4-C)ZE7lL^m'^&Z/cW&%<&mRfmnSW\?+?\<"!:`@ +%Ve@jt"X4o?I2\J*m4nCFBq(f((X<\e+FcI\5Zb6qFM!o<#*?B3jCY3"+dp(biQ@$GFY@T&a93(@D/s*4[BeHJU**0Fdb><^1[WsF +%'m@VlUtKe[_t`DJs'o+.s2q;.4crTe-:KMD/OSpsPMAC8?4'+;jp#V5tJ($Pm5P_T"t +%d=asG0#ZMAo&Djai)?["[KjF5*q$TOrc1!;lbJ>ojOC#c;PM8K)nsO+HP4A272Le/5;9reDHiqYQEhel4aj([eQ\7,InZQgoM$s" +%cN(P0:#oPkj/.%;V8iuS4pD=RMsG?Ai5[,=>qd9F=M?B_2W)qY<#30_bE?P`b4>PKcpo<;O^8 +%;1t1EEg^`%a2+osQLGo`LjnGIOQF&HWOXH2Z,ANu4c5SoQEH=7N9S$&0=0I@E>(?9Md=@HU9SOp!\P#m0Mi%-\'Onu,$>KGVJ7F7 +%WT/ciF@Pj^c\_jT,&%qqLrc]l00SR#o6=&'3SJhSc2jtnT030hqp3uKR)NPdDj)_XJ4Iu2D3K?AKi-NhLVF*C#I8$6d^r,T;D?qG +%/1_Oe_qdsU1#lLKaCH.#\1VGs\&^_8@ISY`:3i:JTA;Z*;*EJWP/U8Hh>d)SN><3L#J&UE@IoDmhlsDf%Q?Z#EAt-ET1%3\SCb0lo3le;tu$>:c/o8&lAR` +%X/&@O%u7L)\Tr4o5R5h?PO+LPJXHO,QsHqd:h7`%/acd0e5C0:pm.FmXo/m@C-Ehr@>&+d$$[s*:El/Cr/T91.oWTn!t"";G,`3DbQF;.7G3I-SFAM0h-Z,gN$P6&V(]7S=hJHPT=&D!8F[RibTV)4m5[PFh\0G!m^U],0s;.fVnit%rS +%oKHe6nr(U%crWC0Wr#oYQ_$bp6JZI\fj+%("*pA(WCfG7Q>]'&Vq@F823TcTgSc8^V?g'GNaY'Y!TN]MB_40H\+u$C@c^K\MCcQ/22DkfJ*Mi^H6>c5WN8W>\*15#ls#(Y +%:l:0]/g-f8$3R'$AA[ +%k#?JK+Ya.M-H"q4!X8@]0uPc1i@cj\,5WQAF:nBR).UJ$NVG62Ui'EuJ&qVF,1>J3s.kRJ)krhNV<.fS5JTa8.=k90K1(8mEj)2O +%]d./[3e..*+\FYkU.nJh80PEE0OXL+PcSbTfTC0??p1CVC$^@oQ6Ks/_nY%PFS7L&A +%jPSp6i,(Zm(]TGoa`aD6Vl\sZG#fB*3iNG1@U(2-o_iPs`T&Vr/nn-);8]^;Q3,PcMA.1DLM[*L\%os^9=J$l!0;YDAp78"SdQmr +%)/=oA2m7C]Sg2.2L,EXh=IP9Uo4k.3*!04nUG-DL6L)am?krKY92ohZC5s^"!Z>H4,5]gd/[o2A@g,UWKLCE4Ijg'W?2uCbgP,W&g;OK^-VI'dmc`5OY:t_A9NegmU$[kCm6//VqUZu +%YTcf0MT7j"oH.!JZ[4G;_bi_EoHC4WZMSM;J5p9IdTM5*fXU%-=<7o37h)$&a2#+]'I!P`GG:suhlZUlro0er_m45spa&&H;<"c/'`,EQ"[qP%]=:bs]FQS2)E+-ZUX+(q=&MV$$&*.R9V+W:n> +%q,5S"!.A((N]^@P6DncOJ*GSS5fC&uFhqO"B!9ZU:#O9&(J?Qm)-'DePeGd^2^;W,uZ37K2ZncL:P22a-^bS +%OBgl!$M]OuD<^g=SQ21]U9O)q;.`J<]1&Q`?3[8?\Zg'&FAPY\<^J`K'i&)=&G" +%4WGiX?Z+\4]*MXPH;r[,CE<1%alXOrloJU`TJ0_A72)2iBF^]hY5&meP-]F2P@K;PYJ\YC:Q;?Db$*B[0TLD`Vgp(E7Lca\su +%mT;?Kn9q25N,uJ?^7H$D"=Gf;?t,P@3MkI#&0c^Mb>O05!&jbgDKJ%WcaX2+-A^Oc'PN_]6bJ1VO%-9>T%_X-pKa:IcqKM%5e@I9 +%Itih>5Wfmo$pPj*9f_W7PRJ?_^mU!dJWR]n91cuqpRA-/BKY:"p_]h2TEIBL,l)?g*ask6\[0.^1N+%H8aCs:Z"o!7$Mfgh'`M(h*JboP];cDbUF:4N`<7PJ0NMd!,Vlm!o0)MG*+Rf$E&?Ql +%M3P8c#sJQ!'=N7[?#*$)\cr1h[,8(5AV8&\q-DJr0!@"CJAh&E8q)UbN,d)Of[B!09UE#@;+Y1Qu!YC+R7+#_Z.'*?rC;^Qb!,dlK&, +%]Xktep^SL:_+3-^mI;up4%rSqRsGY99tp\+**I"1jn1EE7d12+_Gioq7B$g)MpO1N(8"$rCTn-gqBf7&`E5_;2'pteT!u?k.;Z,% +%5=D2-tdQmQ^< +%St@BBe\5hiMFhOpc_*&J>jQ%/T#H+.SQ.-S[rcSp96HZ&p72B(Eq_?J0#Gb;;ELSh&ncR4FR"M<]Wm8t*J#s.:sH3b)N;26#6eIt +%Do*f,Q.W-545]c\92?&js7S,+RRB8u\86(\qa6qli3Ma54*7]:a)0V_SW^$1nLgi`/N7WYW:5&@EVFp:aZ^t/==5a7i7p[9+&X#6 +%7E-n'><\9?f8=pE#pLo:$7'9MEpP-%`13,MMYPg>8IhqR2FaJl'>^@6(-\XSCk7'CpG,Zd'FD`X>m8GLTLdlBa0_'a_4HOI5/3.2 +%H9$8,KMn!9Q3jK\Ejk'"+a*&Y_k)_lZB7`r+%;s(i@S&6mUUS>Vi>:WnM=8B_9cQnA0$/kP"n!,d.Ts;oPlc!G;D@.jJ%qdc?FD: +%X%=Q?;_agd=N*qQG6\h=;>+3e.\`W99_DjBh/KHhA;sOr"iFa?D-/AiP1%csSMq3+UWGXJjPn)\Z&]TK$.,3_i]W3gV#g@@6OW[- +%s%pjnWE:2DJ!*BEKJeihAUpD#nF*J5Pm0W@jW:-``,dJ6iaD1<)XnRU3=)Zf]g1-Ki9iHi-aTi1IP%spBS]%6\Rg4mX::nsG*[7! +%07u9[A>plS=1]C>SB4M],WHsHnU?K+mZ'u'6@OKTNM3A%L7?t0ARKg4eqhdu-mE4BbAM/6s7ti]pG.Zs:g%/Fh^T'O'n$p*9BM5u +%r:p5]YUK-K_P$A-s +%1aA6P!in6B$=1"',4fHB9GU806J4sj$G))QT;W/3`)\KY056'H6>/9Ri]mf;s7q",f4j@>f*!+:F/'@/dj`/X-j!LeDYK^4Ku +%Zbn)tW&'pAg=e6kZ'njRUBm-SLo6"+a)/k<]H$Ze85I@T)"0/B&b.Zi<.'`h3/Sh8I^VID9J@m#dD\)bCZgaA1]JKN%9U[[8c+pa-HQA/K +%;;Q,20q?`(lnER#Pf"WjSg\5o.Y5?I#$?i%UFJ^\P+LrfAEDL'`)JtpI`gs2JoAh#<08@r[muS$kp\fE0Yu^/7&O3@Aq.2"([M$Y +%E=oXjXu;J"B''%ipMRU+,[#q:1g%<64X./;&OO>4P\2i +%R;L]*mBr0tR?E-=MLr/O>kQ1Q=L3'?+ioL;m$@ul(f:a',SlT>dQ9::+r&h#M+Jkfq%N^WISb(S]n:gi@"fnc:j7qs'3>)p,1j1A +%gA1TT'ch@)G+Pt\Hd9]LdeSm?L@nU1>Nmkjo'qNt#9<:aSbaqY#$?.%otU;P@\-[F6p:CKm!T+^(5A6Zg'enP*Ru97fTBE(\0arG +%M6$ht%]F?9*"ofM&Q-AR9q'^HY't2i<,71F-RKDk'MKP=n%1?tpS)F@'h@U1&M=J&*e8>LjGTV`aI^!6g6fJ^<&)J7=+H'eEuuPp +%E4CI+RoAuQ3VrqAXf`WAd.T'B`*bQch^8!2F&@P9'.pX?67p1m\fX*`NGBi*6."j]J^1j'/a-3^kKSmHAb*`N`K44^kFQ.>G^4J= +%QHRW=]8`)[BI&NAgbYT35XSClk,FEEUKdFPTZMssV:X/7L`HRT[=)'ukiU9&gXtLp9J%(:i&>Cc_gKXRolDC$j5PM6+%$9#jOs.X2QFp*gb\qFdo>I5i7Mca:.Q'a\B4QdMBAg=O>XKoY-(?4;,@Z92ri'n[jU9Z">1X5fF:=#mM4G#X&`h/2L^QTe[g(`[#F>,gLRX&=frR]j=-!_aJ;W +%*G]2e8I_/l1k/J"=B.1uQ.81R@Q?kR40FL[J0$lKeX>PY"(r/:maS[k0"jKG.rWMj)T;%^k;T(KDfTKHGi]rBB3=)%1]#?3sHjt/jFVnf>3Xi7W'U+W-_\%#2 +%n;`5R_)4[2+@re:CTI@W:,j[EeT8:O95=(UV)L;adu<8P\o./!qf!AY0S&i?`FR;C&j:@o+T9O8c'UF5aQ@5HWt@&KfG(9M@UjUK +%P:DGag5$LKQm^.T(L=e3I86F0U2;!HgETC[Q(SYBFXXNF9=qK69t0dO=P^M,,f="`Z"E$Y$JeG4+It)>\piqXHfu]5o9jM61;3UJ +%G`1^"%/rP1gYWU2K*7+E%d]V1=hKj"7h>-n6-jV*#I/e6*j)dHYD*WmOHs%64\)3n9hKn&THA%.YD]d.Rq$hIl +%m&sqX6KX5576@0I\3ZV`r?khGbr4-XORKa"'4rYeJm[Lm(j@N*/>%\6\U&A+D]T5%Eh9^FoorV/?g9525dO3$5QGF^POg@_e8FU[ +%4Sp`?c0iD-L0;ia=ef_f5>PYUm;ALnLq(<#i^E&*!IF!tHb>?bD8pn1AMLEOZT'/LaUj#&HI:Ls'hR.LLnc7Jul0YOc:)&LcKJ)lWTY$([Kj9A4N'WCm)M +%`gCaqf(]4Z3`EuIP2cD\ro&*VB>Gh]D4#,OSs=3GTf$4?c_5F&:\+QCZQ>#.F0Eo8NG?uE$`TY,.8P*jO?,I]`0,[]_"G1C`R0t* +%iUD3gmWFBLZE#.Rn7Z@O$_E=H@K;3\,Q$U(N^G64%irRKrK7P2-F4H?)d'6G82=b[9t8DTkm>*?d3lf.kZk@9'gnD\.3L#sZ0PWC +%fJ)B.&A-(#Icf[Wqi@GK,OdY17tXZ*==$#1VlH+UO)=FX)CT- +%Z1A,AbG&4neT`C5G9>/FPNsJg8;?J;/VdP#T[5,KO_gIXfU-XWrXo:mr?00dHr"7KRi4NQgR+uP#3)Su<9=%LU7`nA`,<@4=[[tV +%-n\=,D:TOm.3U_>/8NI4kF$7^ujoc'o;@`';&PL0;dUn,Q*juTkWgDX!(ehBWfh&8C1@raA>[nY305++@-^SJYgeD`.jS`3OiU[oC7KPVOPNq3F1-uokmX>ONTf^'TiYkVhuS5 +%O*H/2(`"*UW!@LNNu!M.RkRsJ7':)brAfJh9G)Mn.$F0)9S9_.EPpNC32tP\E%k8oM9%Z0W1G*sS/=CLhZ*K(G-g/>IKFjZ-]p7Xj_Y%!2`=^.V*NA#+a%pn*:?LG")T0N@p?iKuTs+-gAePH5$^\j_i +%s8K5$r]g?7J,I?:r0r32H[Yl8s5s@ZgV7sUs7#Ver7aI8h;A4n:\rCIktc\c6/Hs)MiTsuPP.TI1&_%%rsq?nlc26iY=IW&rOMn) +%Dh%cDraYg#5I(0js#pCGfXEAJnHn\-83pZlF#ng:6Lj+ai"bcVc2(8`$fl(@M*EAD.jFn$? +%iR'G;i6STVAkZ(d#&4eR5#EQ:3>L*Mq6@,3kR-DP<'H`e3B>8_Ml&CO)@45m`CPfs_)rqrHg9u]d?k3U8Jij=cPRf%KNg*-h@cFe-45W^sp6+ +%jSlRJOT98Q<,='6NlU11IY4i7Z5.Z3/e]Gl5T2N1mVP3#,7:ahun[OuYH`X8/6'jG-euZ3g!S$,U`hH$Kri_&K,@Zh[Y#E0 +%'Q2VFV%%ZMXG5ST:#BAu/Z&MW^*!GL`^MjO3:p+!D[c1VWpH^Q]s*uqacs$TTFoA%3Ptn"%ftf,p?pmbNX:mFq2T,F#GE5)gCA3T +%0MM'6rm" +%5Ybt'@35JDK)'YLkT^Jj5d1g[5M][LjuqoXlj!O-1P$+efCt>Tnb/!b#+Xg7\c)ru/Bn/[.llp^9'q`c-H4QCi1_V^XL#m/ReWdjTN%JoqBNktut;&mp47E"`\m@t^ejBP*&7P';IRbl`&QYu_o`+NaF!F]Hhik_j7AXC=ee*6j0ZDtq014VBQ +%R`dledQX27n#,c%T:R+kEgeJND=ElMqSuPPJ't!r<6ZJi%/:MMnTr8.kRRK&EH>NA,2FJnmT2!\S0(<[`^je4UojJB?la@_bk'?*iKk/M*Q!(Yj!ns-6]b4Ieh@EN6Q%q4 +%k[ZXDeJH!F#YNS6UlfCOV;R*h'16.D4XcRSfYfQ[Ea3.JO`+>u/%GD',]>lgX^W!bd+Qame7r7]=U2REpdKq^k]<$<1K\)tCJ"s0 +%cr]EtXZF0o/0pk[4m4H[Ae#h!>OboFdkRE6,g-W4m\0( +%+/-_+BTg-ee:[b4CBXT1G)8OR![,8o`#j`^G9?fpA`3-d^]'`NH4C-:g4LD&838@&$Agk7@n +%+]TWq,@FS`E6h=.4^6@^]uk[XQ[S&oo'*7M5fmC#J=J5=+OTIC0m_Cr@HB0gNV%]lS760"=ssdW'D@<8oc=dR(nbN=9VF.leT2`p +%,WL[#jK_X?7HH#.B43Vc^P/MJ9lM=R(j*A^`"^f*_+gVII_03\Vs/MMYcK6BTnHC7oCjL177\#:43?fHu$pF63H +%K/?sj2V=LeqpER'-=[d].q6sA(&e(\b7dmH%DKO&'ore]>UMOV$D@u +%Fch=F\(AF4c(OEGd?\7`m@ne?r+7duRmOp\rpaP=.4gRa(NhNtm*DjR0oi8I24Jon/D!nk%HkIO6gF0([##0\8I_W%EV0TF05\^8 +%pt99ai3]!OYg5KIOSM1h_In/m'[d]S"C#+cQ\>QTdh6Ps?-6_7)k4>?UpjqeW:nCZuRRaWkAA4Ye4[DZi\$EX0*Z+p*UA)N+t)uT%3lJ(@92^$B,N6)5j#I^.`dZi&^I,s\5Eb.XubGeEH.N^YQW,O]F,drehK0k/O/Z*(s*@c<0?2qh_P +%^43"([6K/PXmq)2H%'uc\3E:G(JgBC>C!g*S'Sd'@ZPiH:-0=M'>Jo/ImI19\IOV-pH9RNC?UU/LJ#nt5JC"sk,YHca"!B7amX%\jmi:@s2Oi.$CLq\?bNnKq4_Cb?ncHkP<*5%p,fs^&;kHcB8 +%BS1:mhuJfo,V*7"\AYX46d.4cN83>q7OMZkH?VfiYBi+RpJsq]K""dk.<[3G<19Z)?C,(JN?X+6f +%_77Oho#;M(%!0)Z3p@qrK!$>U5o^+9qi3?:BcZ?^02',514)e95Ne<:#5eiS^@T\Ndn`2eK#ZM#L^X-(CU'\/I9>WY!DDM]f25;+ +%c2!&,SDWGVRU`a<"@u0n,:`1Q%C@]*XZR#!m7r-\[>, +%$OtK,A9`ou8+![@UJ[(Hg"aV-IaqKCZ?kRTOsJ"GRm(BU>d9hdnAD-PJR>h0W.R=X-*s[IA6T:q)\=a^s@:`$`pmb +%.mEq^&"5N-BERQ3MS5dZ!TZt7BT5C$O(+TlimF>L+c*E:%4J8h+3P0engq]">S8gLM'QR9EPc,VG(P)LJh#OsR3.Qd7g?gqK42]U +%R&obU*8kF+-pi(ZQL4W[&q3^h_c;8JA&s0%(o"FR'VC!Uu'"VV!HhIW(t.]C.tCFM]%Ob +%FnQqZ3HpHt^3"?(fFjYZ.(W@YX!+-9SHm*XFCAmi<(7T)"*P0maX`?a>BE-s8]FdZGYehNXu]!;QQh>3*\:OjIL_2[bFd:GQC&;R +%W$99-H..:t!V6esGB!gL$OWQ8%"LHPI1DUc3jIr\RgDb\3Lcrk,Ph]@7_^lIHC]uFlOdm7=J[g0&Lm^+5 +%;sFA,Fr0g+ef`0dXA+rD:0d&i`*,EiX7W&:T[Ia]9r\Tf@aT<;61[`\H'8DK)MEroa4B7KKkn63SYYu>XW46`Afe#>.cuJc*q%Gj^e.+biG)EcGC8_AB60a7T6J81Z6ie`5 +%cu$>S/.ira(aSe^$TGkJk]kMdAC_&ZbknD^S4U*G3ksZ&OD<\uLjQp]5_]?AK;EpLl0Z"[Eki3pF[=Fs?^WBfVta@OiQ(9-L/%T( +%^Nt#iIrm.L\3X&EmEHBj-5?-0="oAF_U(Ou-/il0j,KI"g/-RC4S&Q8TksRAK+b\Cg8Icq,"6LB2 +%nkY&Q,jLE:q'.03Jse%VgJiT0eV]!W`=!d5Nu6Y3@aIPrW:!b'`aQ\@EJ6S!FWUcQrNm$:_6/H6('N')n%`+_e-(]SUf.Yj_T%>E +%U)=n,ODRTX/QIB(3$#cVnq=!5o#bgPK\'$:M*p'bb6U?2a_We`-U%uqhfKbT+1M"s5Hk?[&"&$]KDcI3G%7+e;sfV'f%ZLrZY +%Q+0JUpiM'/cUMQMlWI]uLfMA@&:$I$AI5UgC0OU.JmLmO.CqD_#qtJNUbR^%cF6l":b^?FaD)@!(*>:.P87\l@iC;jQ"u#[/?1t9 +%jK,CM!;VbJ"hG$JAeE(Vi2TT]KfT:n."VEknl"XaZ'6meFafE@+lH8n1h8s>F?&UN=>HJWJ^@E.23*8Cg&eYkKJRVT,p]^^B\Pt. +%38o*L/_JVf"lu)pU#W]7V)r5>2,:mbNYFgWp]Nj<;-nPkHKO;W$.0*WF1Ps,K3k9S1o\Xt +%2g$/XHj[lg*n#YM^oe3O6q@C`^AX8@[pG@HMe@`W;@d7]5RD7"dFW<$82EXu"G%3:Uci=i":OFRm#0X&CD%hS>Br%><,V+RU-sK[ +%cZA/N,&%8VZFLGdD+1+*iiNe]Se`p9.;kX/ZH5.WeJUgF"h7H)Z$hMDQjjKNr@E'(b"iSP,0nYOf-V*2CtTI5D^3Fs'Y(2%6+>EV +%r$96u5s0sYQkrf1Cu&::=>5S_81dDoM2;&Vlp`$lP&$`V4$]snCk +%b-GGWJHaOGZ!.8M1Uj__`l$gKC1I.PY`'8Ao%>'p1PIWQRJ!YQa2A;`g>Q^Z2F@KoXcm6MPFBus0,*@RiG1F1Uf"L:0A(m?cnuB\ +%J^^+b8$83R:#2I:/?(]rK*JE$2Q$V7guRZMb>.'`".$$*JaY-Xpm.,'oJT9N/g[^KaGmMPo`BRd"<=jVj7.pfhJU<=N>F2=SV$a/ +%3&o7[f@PE@U-Dfkp$_nO5Q:&RJ,HpNs6tOm.Thi"9&/n5eFq]ZWF*$ciadRh]G+'*>NX%@5tn4$NA9TDtrs)C`*OiR#?qg*#Dh#rYK,^#!O^Dgm/uDJ8o#HlA4rA)i\6WueD6BqS$C3q!GqU*^q& +%Hl$`8_MrrH/\_)WmG2Xj0_Ck$#g)'hll-HhVn00l6LW[2M)=Pc^af\)Gd#A!rVZA,f)m;@S]<^oL@*l3U/1POL_H=HZeMA'Q3Mnf +%[k5>kq47E=*e8Qu8Ni^O8K%XQBDMsl+DkC+LU@>`_Q4*dS8XG\tJo#856S;3gDn$L&X5JM9SlPY/Uk.:Hs*^c=SBcB"C9,cf6gWF(JYP3rf +%-ou_.O8jC2KG[$X1?s#=C\'JL^U_rdHFiD`?+9cU[FB?T"BGs'`-ZA"HD'GJIDj^pK7G@9C&W$P$\B<7YV9O,DnXW^Dgm.VYMYma +%e>4MDk[R_HLYH[IHT/A7k52j#q!RIp6XbPf^Y +%hF+27ZMkV#1h,'cGc[8+5nr7H(4Y`CgH0hZA)V(Y0$(fkVqk24FV?_U$qn@af&M%Ime"+\"n*Z,`1?%VB+Re&^lEP"%cf%qC\(Ul +%^V/Al-5?@cP.H;-1S&n/gAktn;;P0bh\P,Jr6G7)[%qNO$0bPZ/'r-E?LIs!"0_H*>C?2:488Wni_A:QbZNgY^M'AHj7,H,"obAF +%^A%GoHc>H'oW[qBs89A+nAi:jS8nH;k!6sbd:Fu.fcAR05klQ'o+!gbGPu]#M]6GsGl>29f(f7-GOB_sLjZT+`MXk2B0ZF^T:"tk +%m.V,8RDI-*\nIHur"dGQT\#U]_j3XEmSiCeg[Un#r'\3=9LSX,6!TpOR*m$g?Y4b&+a.FJGlceO8CJ(`eEA;CP]D[/&H3HmfsSK3PFeTr\XiBmK3"D&2JFL>[aY&^KM`3*P2spZ +%EG`RR/gQ#E<\8/G5+O(q+UC[t_MlUYcK$_oM\Hk3%/$gb9\UZ%SJGehq*"S%KSAo%N"^irYU(JeU^fU_\NJeL6q2;AtrJ"mdr)g7\B5Upgt96*0h@17-fJM%!I60eGlC76l#%-U.sB(^tJ5o,qpN/2%/9F8>?KF8W*Jqs\/*_;`h +%D]Y]7\3&aY9/ibXD^).\J?Q!f]UER"FCPp?*7^d,$,OSdK_n8gPhM,";LlJk0uH#A\If6]9ak1KFfm0\MKC_S'>^?=E)5_Jnj(-G3/i"]"ZY6)0:dB4D +%`,46_JSAWiEQ3)PnB.oB`Gs$>ph[JRIA%"R#$R4#EjmU'lnMXGBngdZu'XJm/:45aL:0Q`\Q= +%1@_]LH:ch%C>#a9?_3+8,bp*9r"A:#?4<$NI +%>qGk-RF7\gXSZ*;$>*A@r#(jQ]^JLCgl<\(pN8T^]3=J_7o[=gD6Dr_hjD_?H1q/qV49$[><+mMjdFUbbYs2]t;;r=):HoKAIZKq'WViX[9G/0FX< +%Y!X>g"6-D]7Lq9b=`Q4T<(Y1qcKQjLd)QVTUs3+8RDQA5GHF,%]P%q!i-NO1Q=Yb#\mHUSiR-Ld[@aOJHa@\qYPSd>VTf7Z(uBT[Sl%52njEIr0gV^D\e"k7^A'-A[Vr +%%TURS,gK>N*)B9E!?trJC2t17-G6u[Cclq'kpe"FEAZ[7])7R^au.:s\)q-J/;?Q;!km@(*Y%Q!OdH.rVuTf!F?pHXfpDR;hH'cW +%/V"M(.g`CEgBYT!/pYo`%3AJI`ePW*SsnX]3Pu0BlL,G:Ap*.3fME45or02t3PGS@FgDD4!q +%ZiubPCi(IR(-PQbK,i7rmeaf4gRfgMFf:9dX-%`.$NCV:K7b! +%I2_tc'R$e'mS4NJa%@Y_883'bKu2?3eabPT7/r6Q;FPPZbhHX]JO'dMkYON>pO)?cI18pC$NCYQRM^t+npLP?-L_<)a^>3>[_.uL +%Rr6Z[[IMJ")%W,+/m9r40RNnodj.r/F5lhkK,j4r'nJGX.$@fIS&o/YnEG]tK)/WO=(*=);L(#/BZ&mp +%O+#BMhto0i-$IBXlfc3@LN+HSJl?13#-p@ooEi\ha!7BcPbqh_Qj$=*H/'/m=?BB6QpSL4=S'_5YT=>M)kPVq;oV@#1m+*AV!$PE +%TeLWL?qm?a@Zg#A;FZW]TSeH9P[-Vm@6l5uoop6:88.-lrF2CTN8L+jlQF#'rp/Q@:3omQEniY6s(k.;Ko.EE2:lSu;A@E+:k\O8Y$% +%+hu_W@mjdmJs,O,a"+-'R@rXdc`q7EGSPGT,ujok]:s^#9J0$8P75E%$I:i^P1L@<$8;i +%Ml[P-iYac\&+9V8!d=9X$O%Yn3NOTG)aIXJ=TrqdZ+fh[]?$-/p>!2QbOauQ+h0j\/N2@Pl;Q"1+H+<9oIR:Y,S!!YCM`-3^S\&% +%;=Zp6l-QHZot"'+ZTDrgiBtRm +%d_t7_oO5VeAc@X:W<_B!KY6i^9JnklRb2#cBSqd7T,T.dm._R`.a;iRjec"98[Qe)5*=E,nZ`4K9rNqPb-Y[E;DUIB82SHEA9V`:,$L&F,cBrKtS2=:oY-Qe)sFh+;Pu&t+`K-o;GP=aQTTJl"Q.fR.QSA\IhYh)UoVF5GH::0E.U-ErbO1C$/&'+@ndBEK,d(G +%rYs18*R&X"LBAiJVTpcIf>"kY'nMa.d[FPi(<[6R?=%j]!\-VuMsGh:I$Mc:N7ef"2!*YXmfWZ\+ikPfB@s?uesrVA^G^bHiF?G5 +%%0\>]`YL'c-&]^KmBWf@e#lZfE?F#&>6/4V^6J#qK4LiN-VG=5_\_NFJL>7^86FqTI%P8$IZ0Ll1If +%r@6*$_K&S4Nne):g"_RP"MANKKdqrnZKoEaa#XRfVnh3M=gb-2C2h9V7CF((4M%gk>;9c?d`Ic'UpgDZVNA6P$ilX_o,4L1/h`!e +%B#J +%a7MR7!U.3J!HE'C"LXZ=>HQ`M7iX.gO5Y!RG3"pD47\ab(8S-k6';k2Io+G?sp1FuCVe1OiE@r1t6Gr<:*jC6i$ih2Ge#611Q$bd#.Z6LJ8bsPIqRr%&QHkN_Je&%6?&bX$-SNki7h1?j:.WG@8+7H>@ftM +%8N3/2:\K`m2A^XT?$X$6?8CjEE]O")%Zq1K^2>Ve:(g`Pm0Z`)*+r>\3$$1OC^Yc$'Ll>7p'$0mL-3`;f/QPrR1:j>/3mcC_QgJq +%KNo/u%VB1bD-Ag?UOKeL`3JlU6U6]OX?/A:?:J(9n&LepC/X^e('!jpI97[&K+odeOi\3/O$&U-Iainqkl>;BPqIbf3f\Hk +%QB42$%!G#i_&ZC-i%hVL!@]6]B.1#:&Qp/D9pQKd1>69(^I21,L0ogg\8c(6FbZ%G5S7:V+/@n@^rmQc9bL:*Th%_Tq"3#=0Ok*1 +%9D_D<,C&k&.b?XmSm4=+bnr75dd&q:1FCOO4XdY74F5r0(g8@T,8+\0?cV+hOCl!UH/D@%)et+LH>Wc:1Y+*u6`oICc*Aa#gOYh_ +%em;2g$Sk3"rnu%gZS+<=B29EB5b-4O<^2BroHlj0!BJV2hRrS=V,S,aSnA`K8jF&\#mEt6J&cqghFZG_Gree+C\DO%!Rid6AHehJ +%2UIeYeB]7O*_i1Uc8:sKf7(d[n +%8,,ih('4Y@8dj$MP%2^?X;1hjd]ZJ!i#qi-F9hNKoj=K;M>@M82/CWZ2u9&4R<+U$B"Bg;dc2mdiPTO60b_)$2kr%Or+_<<*3=sQ`rb`@ucj!fASl#r,S+R;]5S-YGq=!aDN +%$"aT/T@[Jm7j7'qlTb?c5Q9Krr8g`E&$Sf&iT"qO`PDOZ.A5biFoV*[WiLQZUMD!SNcW:S?[g(4(B!/R9t)e4X);'J5tqfek5OWF +%oABO3U-IT6JYAi2rdtenjDuD%rKAdqqZsUSqdJ"npU6(k2E+&u*^>8YI:XN?`f`%bI)-5G-1qsb\cN%5jQGep$:FKpN:p#*6S&h:&"[^ +%.3?fT4`;H3j/#j7_h9R3Upb;"rTsE`S*@ulGTDTMB>(139g>5Ege>JrR1@-deQ\N0/'n:R9V:?k +%Iu``:Y^bG%5J*!FA,F7sq`HcU9q-RNXPQW89XESLHG;3+qeMDTt +%k&@_NRn/"nZu'loGAaiL>\uc6IlFptlgBCjr6487_V*7?DpKEl]5GsC:>>_1[LM6q*nB(qh9YOEm_A)V,(t(8NTFT]:HNTj5*%lf +%G+P0a,^ZLUZcTlUFJl>2N9i9TRpIuQHO0WO$(26+Y@c8h`Y-dQXDZ]i6p3l-FqJ\4p3^nYqWr;NP`t\19L<`0$62AV5EToBKH<.] +%_2&:UA`NBc>5B`dn=gAgL7l7qk)fPA/X$l=^$5pA]0dM$7qkX55`c'EXD!aVs&ZuF8>[P-+;N9:]@ou"32@Djp[Wmh/b[`XMg*\O/LaBoT6'r+d"[Mpg?1TjKlV#tp +%We^D@a&\9WF.)A>`4AbSbM;6Q1r3G>eFGE9W[LF[D/G*qZ<;Po@tK&9*+7-cZt7kGGV-JjH;P[a]R:R9=q7NiVZ2j(Dhe:mW]f)L +%7i2^h]BNtr6iSTiIV@r-'LZgW8k8pkPN2UQ#d9qO=>]`t@7ARD['u&OJ_6f<9Q*:*Mq^d%SlMYHk5ed'cHBTTA(nF^Dj,F)9almf +%YQLgdJu%YA9Hdt%:nM8(A68*oE!?prf8XhK>sfa62FUG&:;Z4Vr#F`3FI4VG9hat&YT$[(#Z2E3A-`*M4)"UgZQ8PJMVeH%'0lT1 +%WO8iQ6QhYa+o"5rG'putAVM=[[H*?p:iQpgBda4X3WpXHKh`W))0;boW(E@,li<_[3)d%H6q8DG"1*NP_;9P?+4ADmq+82Xi7:>t*uR%adq!i.>[;[3^ap!pkgF*g)U<-^],^(L-r`:@'m))/9C`q;dN$QEP0rs:pAj^`-;ca_PB"@fOs4hC7d"eR3L`TqH^q[i"0--KosbIKUhAIJnA:+:CJsjT;%khY3l%@O\hd%)%SZi7__1"A +%,t[]Ver##.">isu!UmiN>uUtAh1cGDk?3kfT#`h.WQk0pK?I_U,bsG%>Mm7TYlR(8ZuMc_l:$gE66(o+kdq!r5M:D\N8#=)=u@AK(u;iJR(]hW5>M!G5o +%,nN-Xbe0iK/&4='.6goDEj3N0oK]5H9i(:n#%1XS-s!\Mt@h>g6Xd[TWpL0"6D+g^:"&$ +%-@pb;@/"hFP=Q^YK]9Kd(^qLYE;HN!lRi;$GK^DQGT'#\L)@nW,q'JdJH?TNV$Z`bLCHlL_CcBN!(<^k%TRa9GT+kgmLV`=f%6+D +%8D86o_:&IT!hakq*\pW]aR(2HEXl5cb?#WIlT>%B.`6r\EuG"LaE"$qsL7;*ic#J3k^[W +%JMeLf]ZC"eQg\�GiX=aB#RMdi5,Fc:S9["(s$_]j+XaL!:E8=n.Ni]I'tc6,!"@*MUuQ< +%$3Ukk(e!f;@gibcF&101OC_t98FD;nB2s;q#PPXda5-2X!gBM]I.M6ANC>iT!+<].%./kr@]"K0g5B%=S +%W^5mSV4o?+5p`AYdr=/eNuuC-YuRG5&GX(fAlL&gMp_6$Ha/5(DJ]MAke!s'0mB'2,1Q93%ZdGMQRf;^hlmT("@]ErQpQ';EQIY+M^buD7i19YDEC-Fcn>iVpDfDoh%d4Si?Ue*PflJ*?'iiZkBDb0e90A]pr)dRk!"%dNHO+<*q\%\f'>JVq]7,pdoP;N\=)`/A%$T&]Zdh!A%)8og"u)\,KoIr]iDaklbM6hBb-gj"!,]g%/ofG=CCW(Z6RA3l!/G?ASlPVAf#G- +%_@:M"Ba5!fL2e5%,[/,pj*.E\"j!U3[c[&8C_XDb?[(k2qjHp1m1JZt/`.QrQ8DT.i;<34B:d^1MB!1WGMfQES>PE&FkM1h>F)ON +%Z`hg-cf]cKG+J4f3,[U,i]U%D+alT(oCgW"ADH>P!c#>3ccP-#HKr9/e(ai@37j^FA'O:3T)tGKrk!!FabR5G[H4DG^Cs_(7a3]kZEYSo!tbni^_GN<8VD+t$+*)p4^<92?:'1*V?>*_B3K`+C8KX!6hf9f#/>O-kEXo>kkE9=gLCi\o$< +%NtYB!2,pdb@,5,M"N;fo[g3d^3nL(nQ*_PD-IBEDJjU2UQ;c?KX,G"a8%])^""J)C&.qT)86[8d$*9f]OR?EIiIpk<)-A](c8TUU +%Hm4Hff2M.\@h$Qk6t6DFWZ4G0cnifgStr0\235ZuW0f;[)u*YX"/QC)<(8;9.ob +%r6WuJ9U'Cn59h(:Y%Z",igM;F"_IgT(r2Y#&HmE-W94]'Eckmu!@V&49tDb8JYRX8']SAd;5a+.Ks?mNV`nt&O;76k#]5bho*fqh +%gjL?0aFI5qb)RtB\AN*'C`WD-`k5DRR-@uopZo.>MHIUA8P;pi$7XLK8n\Fp(i8IMZac(Q%qCPkML9NSDBhk.\tV#Q*":1;;mjuL +%"(b`XrQE&r[O#Bb(eqnL`mQ,Gr!MJ7JPomH3T`ELUd/ZkeZE#.3,s8-CX:nZ9m"umV/D7Ke8(0iR"D.A/q@LF7D=f>=JNDoAVG5& +%>7YOPbti$ZWAJ8HF.2Fk1&Ld,;]NMra%2(b"\2JE%B>#9-t2Z/T((Qek?^tZ70T&G'#+JUU@C&'+':ji)D4Zh@6n(;8h,'$0R?s0 +%k\2k:*R$3t6-BiM[N'e^p +%,K5HeJ7l;gi(H\.YqQbieN?1=3%,:VQW2Fqco=G#n=FVj>WafE#q.PfSumt\H"eU#pAsbO!%YS><&L*MnR\6dj<8slZ5LS+\hG3JF>I\T"D&_V,\@]Y(8.t1Zn.Q"+9jU)?9BunX+kC5I#+e8F'LV>DjiHi`ok+ +%9P&rq`8fa[6fSfr)7IU6Wp?+IL/:=LcfD)^PbQOmH:LkMX(7ET86!c?hpC#HGG9g;%i^?"D^G+eqeE*W)U#HFg`>`mA:@Es`8f*O +%p_G$.U6K`,e1/$?&TNsNU]U[li*3Qsa.UYlT^Y11qa<-np5"`FPV+oMFdo +%H.3K_)"7g"\F%B48_/2@Tu`,@)r*(Zr+O!K,2#L7,oaiXPkDg'T/<3d1AQ8gbBq\^dgSs8gcSJlZ%oQF+0Np$BItR7>_?JTKRF3# +%GmI392[t+%24k7?:NbgKG^^XCPk@E@Ad->qD#&1ocp2dj&!o0$AhV$cQC.96gVe]GXEC4/<0loChB5"7l6b;BWeI'q2QQp]0.9>q +%[p1R>r5I,Ecj)6+l45,XVJ9]NN"\X2g"tJ4T)%J!r&W":+#1G&eaer2Z:##05!i&g9'>[QnN^1mJs.'"fqr+*W;UOeDK=@W1-WA_ +%OK1;UM]k>O!fEK.8qIs=ShpXW0D&EAW<&'sY2@BP,N1b]6VOuQAMAVS)9eI`eMV>$n2u_KYom*mn8#rFO?8AhF&RFlX`Urc?8Gf[ +%FVJRDTQGG%.4%$]JR/^H'mC3A-TnFrlk6.o_,'*(f:O;NR27bYYS'jjb).;XZh]"$0"N' +%"(N2b%b-$,&Bq5749N'ob&]<)[%E%f!;>J;.NY0J"ObeLWU.1**(To4<>fn*L57u8]$Sk3-;kYlD$`Rtmg#pk/r""+^/km_3@f&VNi3Yl$uffPUrR,=7@-.6?Y+Nj#hb2nX:(a7<*_0Y#L*La%&4"*hoNfgt[QAEE^"sjONEXoY+F"XC!UI&D`=X'qT+n5B[QZ/\"m;rBo+S"?uD:d)X2%\G)D)D(^u=Dppe? +%MGg-IT52ui5h!WW#W#l;%N4l@;sZ*>^&R?-pPGsQ=Zt*3#l>&`."p7eG$h!8F]Ra]a%s\"@;_HWhs#ObOm%0(b+KL`.qtd4!246' +%DL?YjS79A]88t0'-KQU?VPppJ*G&e`diY:AS0G%]fr)VC/7PQ0ep#=,e9*suB%IdXTO&?,72::]pTsSt:2iY>X4N"ZmJJSjN/+kC +%oIF%rOT,Ig(h_8FlbRW&H+L8Mib&6O@d3Vs%#.?A@9D363KS?o"BrGc3113o+7$1=Q:Z$%blk[3]#n.Dt3 +%6mO?(`l0^-E4WeT)+WSOhDnk12QYAdrm0uUO,VK*HB+p6,cmI"rjY4'eB(2hrpYBm4W\*oAY%dKt`RoMrCN;.CPn7i\_UBbpfq!cm?;+o1U(!XDPHmIK)%q.QFa0UJ"@*n-BL/VV +%ccA@qa#ifORBd`m,K)A<[mM$,GFFn)F10CEXS3K]/!Jc%?5#ZgTo;m*F0Rfh!7gs.[:!'fkQFM)]d%sFS$D3"Y +%@b=j30@]R&Il?DYtYNa;H%mH +%kI)qaPfRa__3%uQ3!G[hJQ`SE`HI+#PpC@ZmS$\:jPKN*da6`H:gjgOU4qqN8Q$OH&Sl_=)$A!HD]AY&As#1+/(UYrgU8nK_Su!` +%%LiYX,l("o'&ehFdMA/l%"esT8EmC\2+oM4;L;%K_0Tr['G!QUYDP=,Bn3A&r1UV"ST0X6&edIm9F/BgP1Xr:X7jZ:'-U1i=:%fE +%JIlQ]8T8hrLLjE?>LN)`=M#(Igt,-]ek*WZ9!YNTA9Vi(SV_pj=EanJW!K,-1Aq?'`]ZH:=C$iK<%*74E=/=Dr;D3Gh1[j.06+#[M==BrI8 +%!4Xm5o\'!)r](T-,i[6;Z\m!;gssuZrM']56NP'l5Socka!5lW+..%u5uS??npmB,_0H[r9p&a]k.,euVoD=2+d@SV7\n\C$n)=P +%J=*-33U)nm.1WgVT1kV@8HY#;/!aU1aCrCU>?Z#cl@KOt:;@>435S?o5%(?]7jc7-MpE(/$^7jTp%U#S+>(ki9O\5A;)XAo>`c:J +%/Ns"=_.U<@0>eX%5KkR:I)E0H4DX8g(fS&(X/=?8fNC>Jg3/Zn>Bm*o[`_[iUT8ftq)sZSF!3nngKk:F[S>*_/.Tb'(Y/H@L58"S +%@GD,"7iOX%SVk`JN3Mf7cQoAhN6`P7Ana"rfH*NHMe@tCcoa+f1=eJW&u(W +%5?#O*!^#LZ@Z\/CDHYO%UVNF)6^G=.E!X-fAThSA..&=(AXnr5B:["%KO>0q=L^fH`aXLR1KfTm]5a9DZ;^%a%22L\.n;`Ba!,9^L7O* +%!Bc*mSRDdSK0dDZe$PpY_T37%Am:0*e>?JMTt6L^`^chMEEkgYT\/pn!T`%CcS/&VJjD"m:d6^eaZ_m37lVT6T)l54`.f.;aqX90 +%'<<&'UGG*O'ug)"*^[jR9"iG`eo%1SK)#A8-q$ +%oscAI\[B:qGSg`m-r*9A`j!s=-q$),$@dtN4>tN[ +%ficS*Y75Y(90ZY`=Dg"pUNsa_@Np7AO8#M\*J`G:j:MEe_$CR8I3CG48;P@.an/%=8S>\j!?(j4GZSKN.r&VWWcs`^K5lNc[bPIQk*'.;XgDOL?#+RpE, +%i`#*t>"It62Pt:7gc-%#-(\Z=?qY`r@4S/M5q6G:Z&bRMRC3"p^5,b8]jiBP[-)mPE$eEA,rR2!aEXB7+s)Wj>8[Z\3LlfKdMW%u +%GTCThYHR\qV5.5D']C!!``t;pnrVi.*\-9mOh"_=1$%/NFkr\#e'.#,=n#PRd3R_1XW0?[U%f^NI-eS/8:u[ZW^pM%=5HnF$6oma +%9-a[=#dXgXR"ZkrE-VXFEEhW7s7g:bh!8tT_#AhloVMMV9M/6N>7i,`FFLNe`jW(Y!dHe;"4>['nn4$f.1%Brom$iOk^F2J^g'rk[@eU= +%?k0C@\7uQ^T&jSJ?%m^jV4o4W$X@(g;j2jA3VU85P.eI"2-q1\rTU=*6LT!ELoD/GS&@-PVer'Al7'/LJct7;c:-[NHTus9)dAl_ +%*JT7Qd0,OW5d^oIW>tmQD'Z`#TXXfe0q"*[$D^RdBZOc*co(DQ"4o<^>UYhh.#N)Y+G5Ll^fhAO9K/b.FH?!0fkJ"JKb8f +%HhS>Q2"'1ljWDbl*GRq.$bMl>4"N0or0[V-pYuh#hH*[7S2S8aUp'alY,T0TL.(,'cdYnCVO16MWu5bLF?YV>,$KM%JfPl"fGf)= +%eO?/kp#lo^B]f/X1.Rsd\r)+`mMpg+bu>B@Ye$'"WSVq/Q"T2MZG8B2CmetA?CBl?:(!5as/\(7!pm*r&Gm@<>9t_E0;_\Q`SQ"t +%Ad(D#`(e(L%YI/m1JhA70JZeh$Qk!UF3N)bn>:(Pa>Le'cCG8mn(!lt2#1FQTSUl/I6p+Nk'VfIo3t2li":XT7Vs99s$`MgdPf#V[+=l]R +%P@V\.?Kj(0[h4-5*Gq)p'mNK^oN\$.pVU>+EceuZQ!SK@i_aSIMT3r]j"QM]l4hkNEZ?f?.!T-A0O8*=fL<7N@&$`OFp][d)'PLn +%Q,=;nNa,=?n2u60V>sG43BKD@kE["\JIn9i"L0.=1o]I^3<$OU!mS9FV,1>l2'?86%'inl-[DrKW_O%4X..mqQ1ad@+2oj-Y.M=#_^>ON;"9-3Eo5Z[m4Y7QZf6.bg +%ZEt67Pj/m)""kJ:mAE!7"_gEY3Ng>I;na"\TtL`r1/I_BoFXfd_`I3S;rF*\o-!f]2h;LQo94eh_lkR_F&l+Q#-M'?Ie9!Bb3tYr=3Uo,(2T9a8WGe39 +%c4HpbU:n`>7Q+6J$Fm?iEto8K%@+%j(a"V2D`Ci-\[AqZk7&j\6H<.'7N#/BA1:bSU +%ikW!5Mlmjt&Rg)]EF)p3K]X\c%@T*'OH$mk$nb4@?pM]IG(>i2jtl9rBh7oM:'Xb/bH\hqQ0`#b(!$Z-o;4QdnV&ljgI +%m$M5DWQZJ9@HS<+B=JO?U.%M@1?@\=[\X;I>IAV#kd(A)#ip$%Z\_+&>0fTA<.6^TX;"b8^s`E\!F-,p`p\P-N8rRl(Vaj515&C8 +%NN0r^C0Zl7*%H>K1`e''1!`]j;A;]F(I:7rLT.kJ)E%:DKg77,UR8.-4Kf-`kX;])4$T2A^>/5nib$u_%\'@`bg%B`hc%gRoi8f1%n@7_kL[93b?)SC3lqE#s^P9"foJQ5BuI9=W217d&dYVj=Hfog`Z-qNs/[no"`?SOQ$_)6q,"A.d]S$NV!AUo9VRDb7+E`"_!HF-u"8L]dOs4/E8MVPnP?^Zk?7!E4Yjdo.`PskE(<@Yk:nlrTmO(2.b=#tIBf(3*FFNY\cn1.<@FH@H5Z%q9)mj4( +%fTLl1+oG6h"9WjQLoU5$]ol+&3r*'+I.VHsRL\3NZ%_]\L4&M>F;hhTi:6D&4$-r,\I3)%E%n-EVd]'eAoX;FViF_,ernfKK:MFU +%]k&sDVfb"ljG)>OTiB:C7?Yapmt(0(Fc?>?#GMS#Eud*7_kL9]2_(%+U@2%pRrrDao;4C>MCJKD[/:Y"C[;a8F#!HJ8OrNK.8uB'Ku7h/Qj5/iZ`EZ3')Ft`QId:/c[?)1_0k:+`bkuiDSc\ijX)0#9t=so +%Br]0@B%KP#j9/n2`Jc,i[$/[Q0)#hM%K,u1]h3f?j.VNJV][eW`\=ffR-KbjMtt@qrVA,gXdic6#TSVnpsD%XMpp9+1jXZ_Y?-KN +%b0W6T#J=u[4Y4.+7RWBL1$Ni);TBn&?M,n;H.k*A5I^.V=,a;h,IUn06@]74HBo*rW)4O=lP=CQ_Ze(-'`,W+a_0/i.@qdVd[0H`I68@Q^Kt*n*RZU%Q +%2,BA0E!Urm`"u6)(_:("/"N)^7n*agX!WK=PCu#Oodo"RW8PeS/)V;e'\B,Z`5m*F6QYc%,@k-\fmSOi2Kk(.W%NqT1R.umd!_&G\utVo`S!qL!>BAMK%.4:K'%&&A"W +%$G-.PkX/41;_VH+;a2=H.8T)gjPI3'l!dCsEQI^94cl&]#_*Ds;H7RuMZCiU)bBfnL'1m8H,-P6T"-B8jl,!I!hu#I3FhkiG=Udf +%`d<;aTrD9.mPqJ6=bk&B]CL_tXIH;l5tO0Gd\]@]?[fRWFf5"4W58o>M=;N_VFoYIWSq9Y."s)L]:4DMhe(dX=cjTFTXOp*[[\oH +%:EAF<,Lgk?C5#8TO7uaGXXE4XDnIDrPg$Y38J-nr%iCo&jT`%ICWMslP2nPjXJ98*Q%j%_!@pcb_#-bOYZN*0!t:\r_i8f-ZA.T/ +%@/OuolmJmS#P,ZM^i3>/WrP>$*2o/kL-0L;+1PEH=VEt&LA<$cJAI'k^D&OpaHFadUM\VtLF\H\NrjKoams?m#5\kE5%HgoE_m7g +%RhZ[G,`/.J,=F5%6u[ks[3W[g+B\^M-lAqi8#,ndDSCNtbYJaKXDr'F>D"jpKit\YkW9RF%Qd!2pf"qu'o'ah(!2E]#L:mN%CeBM +%A7-u1XL`WpPBSBZfD:Nr@*CcOMPCuM"@Mquql'H,PT\/.*Vg0*eP:*l"]%3.;kg;b +%h?Hea)EHOBMrH]HiL^]0nGaFN1_lV8kBA!.H@^:_X1H]Ak-k)_mkZ%>llZ#p\"Z8(/rON07>J5QCV.'<:d2'Ma1dI[E+,e2Vd0n-qlnd$a2 +%Zd7ICE^.?nC9[d8,(;4Nmap(d1TV1GeI[MOZJf+4lt';-eD7nbg+Y?>h?Bm*,2QLPC'.i]!>9I=N@M#4MTb-8[SJ0U:s_3U$iZk, +%a3ZY@5SBj*`7;DhO_VOgt +%%)"d@7n:nTR&n"XG-7eOrGe_>[T,J'C2,4E"A#-J!`07T4R#qtfpT$pRoa*4EZ""8E@M>!:>Rm%+;r)=T8O +%ML.B'%iFn`MoLjg]/eY'%B=4-Jh8qIAlY_]H?qrE5Mha#Q\Ts,m:bK]nm)3lqk-?(31%ZSfZ;f"%KsH_GD\[E=hPX/k<]1UK_aT_H".`$PW:j"t._M*2q6 +%&,cA=HLALFr6h4G4qX?3A\#%N;9o(0"s7%mbaM_sE.7Cn^_T5KouVaQYFOUrg8.mcW5mX)o,_,4T#OkU<`/1&D:15+aMJPLqBJ1oskZIHpEb?'"c(b"jCG-*HIP,,E6l$;-g8`;l9X(:5d7P_OKL\ki,I+5#/\"L2tE +%:VV%Dl8Fam4\\4.a(*e_=d#"1m'kd,H"#OpWf*.pP2nE_,N)NGPsrZ_e`X)2Lr\eR8E/0hB-$VYi,\9?2KtJ];oK,l00jkr&^+?0JnQRS33S8M=ZG& +%)1qKZ_RJ')aaBP-RU2',oFcU8[9q2@ODBTgU` +%s8&5R!SY<_>_MuJ'r1<0KEr`VHp$&T)ps:$S>1A#*@^6j/8_)U-JZ_McgdPR;eJHLWHei_pIQLn.3MsoVQFiA7i>q)dMD[je3J)n +%$>nk<7kl^pQ/..A.8LcS+8om#`N4s#!$mE:O%jDa;Cbs3BDQ.6OI`.D(c"FdVRP6Y,!MgM*t+pVG$a_olIm^IZo`g7$38AU;"j!: +%U,r6s(*s)&(-UAu&3t+*nu@K2W=b6%al'/c-F(S2I+,n/Qk0(t^\HcqWp"P^HZ^Q\YTf/7WJPZu:Pk&,0LC#O.j$4RFpO3ac$:9] +%?2e;V@aV4qTXoH7/7BXCb#PD+ZCHO'0;0%A$1b%B2XNYucgIk(g/n(_Mkoo$cBLmAD>"j2e)g8qhd,Z- +%l`r$,D5W.e=%ZSiN`?+UP(6?D]B6Z;0XC4?0<_TS(bBR<4`@btdEN@5M6r4u.5.%7;UM!=;qSo=9ZO#-aD%<]RO<*WU%GFf+/m&s\EV\KcbG,M\&3<(&*n;b;=bspY +%p43;=jl#ZNRL;s>UuHI<[6eK%WS%.5=-%D?.L:sRQgiYSOFMo3gm3L\_$Q&5QJOjCiEUL0-USX9d@H=.Otg:+)X1R@F]Q$]W#6OK^O +%/UZ19@t*S\_V'YPmp,hFRBs3l5d%tDVjEOA!N^LulMCCi4<5`ics'0PP#VaE?ch)dSpp>/;m.tdS/n-t`\jD`$$i+V<7QY37Pspo +%8,:W:>p;iDB#Q-^r?fRQP>rcEEIl%0f^P7AEL.h0SFoih,j5h"]KbT"K9Dr<*eK>"-qRKp&5Eq].VVat39-b*,:(/=\g\D50mo4. +%P7$6@589#e/"b9bH/O4KUN<\.`2=!Q37? +%+!0=a-<\Fpj`_cfSSoYEe_hCB,0COc[fG:k[M]JRdaBchqkL],NBe0/UE\\/4QbT7n0T#='NHVNb)Ra4&ZV8+bFmRB*#K3mdeN1( +%,:rGdXq&_1`N*G"Yr +%daB\<_9@I!FD9sV'oOSb[n6R&>]5'WTo_U1#eDRNPI)!YU019=c4m.IPI/0RUUr?&5u8cG-0//:%3BH +%Eg=ER^u).kWNt>2.XDdUKoTEh1-s#B]V::5CGeBJq*!_;X&sBRgp-3<'bE1$KX2Jg`bK-R.SIAb5Y:i)V@]-nYBimVIhEQm0nkH] +%,7LqLOt`OPU/hsg2I^*o+dOE:N/phaQfWUhM(DqAR)@iZNq2F75'g6Yl:=BLVUoi'[umi0mTa0G`fmPsY0Oa$/@_&L5.J%=d?c,6 +%(J&^;SJ(CMp\PU%_/uPe$!?cf-s5c9]#glf6Dgd8b>Wd'mLKRDiX.Fl8d>=s,8O0>^"LFG8V]T_rU^M#HT(u%aD +%?"ekWL]>b*mlAom=K*%4jXs_:/=V]g=S7fFP(Ig10&URO0tJN)0;cBbF0-t^`>#br#@54f?nae!N2E.crm$i:\&P3\q&9u +%:R?>_L!I3McS#h+*agd.(!KZAZ=49l'&@Y1,%m:Y_8*S>"0XXUpk6Q-R7VsN,*Ljb1<;1KCaBZOd/.e.M^GK[a%*fRS`"Ba'btQB +%N1n:+q2;]GWK;m;jL+)H0+IUI;UE5>L>6!1bS3rg,bImr$u.k&J0hKXTEtj@6MI7T!BD)"9-gOH7E4B(/ZN6]6N-Mo>gGgrPk;\Z +%9hnsD]c;kAL]>;VB/P*mq6c\gk=LRH&)2URgcg$"R6"nNYOeSPImg77s-lQC+d($Wb'Hl"rC@C$>*3S4E`PmK@hCs8#+b^)5\sHs +%YoBQ;QjE'`S*@&PUj";&VEZ^)O$b#7d>a"IC_n2d''86hkLT4mcX(@SY6t$$<0ahr8-n7"lAJ^3l8Bu+eD'; +%W%D+r`8J'8SN_0*[a7*[oXAHJXq`Gij\tSH>SrX7ZdZi1LJI-OEH^8^#ppshcgVmAG,!,d80mdi8U?>V@96T#gLt&u^I%-4fZj*$ +%*L#%Ni&C#M(T\(?N#X38Z2QILqnM>V>@kDt?rEO2/=bK,mhrc1D[lWiW^pj?]_1bN2Q<\Pod7oS6LMO'c-P\nhbSuIqIl"%j]9hJ +%XahDZ:\'"?l@A=-i<*Ssf[LU4:oK'k6HX34E-l^B&H&rH8Q^Zj=_]f'HkFE5lRI`aO*d))\5WX79n?B.b]?5ej^q%BN.[o)!hhDD +%o\[$>?q5aIh^";cqNit?pj1`ua2W.KS-]U'1[c&Q,+N$:U7+JohlipFXt/*?LL(*U7aY#d:$_'l#@&F!'2:-tE8U/N#\6M8?BIoJ +%.(FNkW!chrX_R@80S#'03ud!Da8u^I?DC*/E\9=q2_[X""eAR*BeXOW^TQ!$a1Y&O2!.FUV:@#%&)g#(QhWQ816aZVTV]JgL>(4\ +%S)+SubJU_1^'>kr,At\35kTHKnN>L9o'PoP>5P=,:&T/SM=i\0]LPOp5A`:>X`=SNV;=lihYI(m(h3!kUbRVNm\gf8ELOpD(CR@' +%i"4RVE`9!JM+pp?Bn$17&6@=]RM,^0VJ)62\2Ss\+[As+C9t'^h!Xn,BHMB,JBVU?E$g\4S!t7fa\%VDem#GuA'%@aL3tTs)8?%0 +%JqLa=K3a3""i*Q0oO42\GtH0iCN9i7+B^tFW^,.h$rWbmj4=]@G^#tc`f;Od@7!cXSGa).$]`Q,JlAI/)CqtG;!(4FI-:j1Bdpe: +%+3Ah-T0CTZq*]J!\p.6O8`5G5Ge<8TO06$#\O2PNM?%KoF"H5FreGMQgLQ[GBZY1-'9ucHKF8M&0l4gj:UK*5Lsk:e$<0)dn\O=7 +%\IeRT(H:A5gb]no0i]e7_/8#XV*7b=S'^ +%fNGsH_3;-hWVdtg^7C^#!gY[Zj=SJS`-E28F4SsW:*4)k`+39cLC&Zi'fm +%35Tg?j@/fg+Y[6o_T7m[Z%8gd12f6Y?A!6'>Q)[iV@&\*/KZ>JnA1l2kTB!J*i>GbN@_"bKVhkOqB[]:->[;t=m-Dkh)%/3jL5gY +%2fQ0Mr+h]Dm!I#G%KDgkA9%iJEm@c&*g<=DX0?)QJd]5u[qOMOLfN8KjkN'G*gc9r9rA\ZVm2_gELH$FS%jL(uH#AU\4K2)=d-Bo+j'_aIPK8k0g6$-W"N +%OMlGMX4Uuh.piPRqiHBG*bCV81+uWOI7pmH[J>3(U8H79`XLEo^$RbM*UO[\gW4D)`6XSAO6G9*1Vr#$7#kjord&qKV=-R'Qf3L_ +%=/i.\e8jh@Neo$j=YE`h&r>l5V-g@k!-eUe:1dg3no)@U&[0Fo*]P?MYe4_IpsT)DQtCTa0T*@BkG^,W,G*mJ`gL_?Oqc:/\0J*M6;Z,*);)/FJVNtbrPFY.sEo=DMk-LTF^UtZc1M-"ci[)U?A=S9ZY@"1@J=*q$ +%(/Okm@_/ZkV+gk+:Gu#j`5Zs""Q=RZr.@9/o>.J +%+M%cH3bBj`$aX].nQ<.3KmZb)f-7[^FkuBa*kGL^AXAM"aXDh.\be7.jRHEFOo7-5+4[etWA.(m3Z0?ap_O$tg3a`O;)K"-7N8>M +%J@7s1d7SY7dGhL3YKVE]Vr"Xp2Mopbmm7\7$aY7_7gY<8EVif_JOI^ru+iZ8p4?>elATP[MO`!)M2!AC- +%BCiKP^[[M'q'dksZ""W?mP'F9P'mlHob,rjZ"%\CkUlesD07#ie)5KY^ABBh-SR@)LMCs(QX2K"X8iB`'"IkYe&[Bii[gFp:]hE& +%oB*]B^UO\87a\_P\^*hBer:X`=&TY>T\oaQQ&IM8,7(KpE'YG@X7V)Df$pt%M(G"B#g%k8_U!*E=0kcIaHkE5DfM530p""T;dVmS +%%(nr*?!:W36hbT-i2$\`=oNu4O"*'0p^Vk@Ac_46V_qjk7Jmn5VJiNl*3T:-ng0MpF+TG\>m(d=,A%?":\FDq>K1e@IQQr/E/..Xk']89mZ[Qdhte2I17O2L`W3Z=P-H\$,JB]E +%it&.:126FP1(L0mbGo/6Wd+s#WD(\Ln38Zu"fDB]/jG<1;UIf$,%H'YEnu6FI<,F_;UC:[f.e(ke8a?UVUV +%?Pi:BEYD:r9m';=qA"E?:H=a'ER/4&i#A]I/L?BcYn]pfF`Xc:NUuD>Ac<(mA01H,Y;KY#E];0/qt!U +%X10gfO)saHkl1J"esX9qD(3/a%f+^oI#HgZc;5[7,)O=f1l.%"kd:gBj/s/)iNIOp$K2"RN&/Cr[slkNs/*]hl]:8$qpfk@b`(I@ +%D#%0Sr=%\1/mJH:o]oFE+*6-c5-2dp=Jcrr8m7S&3(qHff\nP2Nuqr`I[]H9>o)Z9&Au)K&Bp<=]s9:odVm_`P7@dIBXHs.Go.Mo +%Mn\\k,+Sid1UQgFHcFe68u9E0,F?SY0gc*R::>G0Skb2"(c[V5"1^fL1d'>osM/%o2,/J=k&=ck#IbFq-9e:1d0T. +%:Xs7EB5(G,Rq]U$IP%M]AbV_rK%@V6rE?;a[=4-rja@SjqRN4fB"gH/Ud(I5icSeSWT',Ee]LrSNK[DDa]+O,.s&J+*E6lXiI\gF +%TrkJGa\r'1aD*h][qE!ll2m4dIE>Zp>Ub3G?E83a"`LMD>LD!8;ld=@N$Cme?ab#MmhTlmp:EcDQb]^gps_JPlPf>O.+IXQB3_K; +%U39kM.@/).Yei>/oc[IU3r\b`_.T%@8Lef0N+blrUtGhYO..c/N3Z+]]SZ4?f&Bc?2a_*\dKAa3!rS#!cS=it-ml:MBSp&HpI +%TZo\@pn.>\BCb\9cF?W)bX60_5E_214fO0"XqPR)MM9:7@ES`&-tM/.g(c@'j$&I#$6kf%R+:$r'$=Q2;4gY)S]SlsChQ#QAb.g, +%lhq.?Z3knB"6/&+QD#Qp[BK=@R\E.ZR8jO0%7C.??`f6.R8q5V\mFSJ>ZV)A=!D&FD#0DQJ(9a.?$oa)++"W+[Qr4W[f1C7Yfs4k +%R@h'1p3Z_D-5^H6gI:hdm0oAh%i/[^O`dI)A#Q^;fERu>VK\=C6Il`qH0&2aB2&i[gHA+q?e(`L:k%(K=\L%k0=Wqk-CaHHd*TZg>n$JlSkPJ#L;>5q?@gdG8I,FXb_q:%@rSt8,2J\D^Dd*i2.I8/H1"K=a4g5=4eC6Rdn;nd"2I9] +%P63W`\3A&!Z.t%Qmab];U!@F*D=]kQek4b)btf^-^$jn0b^k=Ib_1:RaABKH04)TKDDG@n>msIbq4]"IK3u%ebY'm\A +%haP;sds%chqU9Yfr8GhC&Ztp-=j5fL('0QsnkipqH2/jXLL*10WH6seTWQ%W/u.f+,%'f4j0+JY1FSbqkOBt2o<-60pY,V%*54)& +%.&FS8qtJeIY(41ULDI1\DlD8JT@:^LX%6LeI+%8FcSViaRj';Q7QBkSHl#W00`-4CF'J$k +%V^f+B:Png0='O2][e/-nSUNa&B2NNrdWf)Gp=j@JiN(=D:E>I^7K5H=e3-?-]O0LEH(E.o$fN//$?D*O[VQiW7II[/`q1sTc? +%-W(L>dC^7j\nBhXN;rjs]>*Ns=92_qU*V*ohQrF=]CiOND._Dm9eU#Kh3qRUbK!IiCHd[ToSlksh3NoD_/40Caj.nIft-:)1QdBVf/sjS3#mG).T7orRBG1&@FShq-d8Vfg!3?]gt[0g=oI`7Wnlq;-B8GHFm=d2gU5pE+Mr +%leCcoZT_hl@!PA4g7!ERqc0cYS"=ErQP$l$#(3D)`@tc:,-4MQSB5e&"4ee/Y(YPa'qLAnD@"`N4Hl^@#*'h>]\#-&QZI_DZc5fS +%$`IAI/gr2=N81dX`DE\9cenQ[ISXqVYHN-!)F=+/_u$]"lMKBng63OpmG0PN[.eLpL.CrC[&9/shP+SXd>!*oihe=(G2f#JAG(TS +%>21c$+8GRPF\:St):-D$jaI!E1d;<37sR-Q>Sc36cdh@Lr\CprlYoKEmJ=80phDQnpk]hVcRk^?*dMh^eoqaCtbAI(_)V@J%s?+Xofq +%O\G<^qd_!4&q3rO:EOr]ZTV_36*6ds3>#Za)17+B6k7+I>H4cX(k[u$P?s(aKklEVR8T +%bHWE]m20(6#FOP!^b./)4!sl)EB)ViX+r4W!JQYNI[J,%%]Um].`!\6/TZBr,gFh-E@9STjBh#^/>i'`CQBgCTH*( +%*"uR,S3uW?oB1Oc?:>F*DC9ah"K:tZql7/`RoSIs82,rT)uFDJXoo:e.aSY;.m$s676(tlCFeF_CoG?b +%NY0GSPZ>BMSqe'O->Jj:.tV\k +%rF7De#a+CWT1.[^N!elO,g1RQWb@c&!s^'dA52s[:jI=2c/MdW/E8Z_J_V>jN<_/;]M\/Mp/dZC<=n0kojsa0j2"?IQ*.)u3#HY( +%C-7lYOtF![-k,Uo-UV/(bX9^5QQ%?rXpt/7cJ7.T:g$'p+T^Ad*H3a5fH"o>7-PJUW>WrQXD*1D2bqpN81_$!cn#$W9A`r3d6>>\_A/[2c3$ +%,lM6YZ0@>l'ifSU\po>>@7b"am&i[r3b7?;i8k0W(h?TOL[HqZX[+AY8,u&aW\G[p/t%!?5H-24)U&+@];8`Nknk(sW[?JV9m&Hr +%cF9d+CGH0oIa3(tX2/lf#K*W^7[OUimFM+q7tX*qf;mmm#>Y,>]m(?pK^U)""eq4!raAt;3GfUpCdF!t_-Xml.c +%Z2;93br%_e/nXY`4[tZk^n=ojMI[*`P_@.r8WGGqG+n^/eCJpB[llIU(=JIX(ZfJ@\W^AoRJ(-%;W"(;rncBhIW..SU,k/<8B'4V +%^9^'$]j4\t"#'ki#Be=0ibhTtG1T[CSpKE-*Cb.-8:oFeM5b\l[f\hX[,jN28i]UA4h]62(Q)c.![=9X4._VD["QZ:,:tss7m%Hh@33I'&<$,ZN +%Y-``sQi"HLj6,GdF^Pr\KRLOFj7r8%@V#*O*?!=n8q)q+>3-JXK<&l/.HbD`fm&)*d'9]?^u$*'b.Lc5EKQ@U7/Q1:&"(0[:5o1uI]"?>$u9bGPSRaD3c;d.Mi+:A`O]5'8n(lSZ(K +%>G7"R@HY,96%9@@dhmK,0dj+k"F@a8&rm)HM4MUJg(N=INR`;LeQqb= +%hHmTh/sO./+(niUQJ#QY/B'M1j1ISNmE>EVYIZuFkK(YFl>1c<'h(Ma8/"BTr&^@"r;>':lG7*.CbCjUDTB0@?f($QI7IaGaE(IC +%=7iP]&LJY3a^Z.pZI1NXVcgWW>J/33CS\)K\Y%m&67%t-SE=^gYdqXCihtCVDfnD]F?pp`Uo0$^%:l0'QO.9FpMJ3[FR$@Hn\dlB +%(p6DLgknP(.7p/_`o-N]j7`DnD^?#+;%pb;DSp1]GgX[r0(LL2aiJ\V]2ndY+"PY"Ip'`]Mtb=g,*e!b=abSU8$rgkmaU16H%DM% +%+.19_@Ip5OT%H#iD4^[P*Th_oBqW&dNFAFMpfm^mrT_;/NDJg[$Q1aL5ULrI^7AS9L=HifAfO-"-EQ'mgo=aB5<'b&Z4s5;>N4aM +%hSjs`\Xm_9,rpB2Ohl8QYTaJCd*F&[Oo7Xf6JXShZDd339EACZ.IF]P,3A[Nl\>i(VPd`s^SOaY+?ke"$sdq;IU55*ZEF_*C(5[c +%OldHEd>_9V6Z8)$.R!12LHk2$c_hq8&&[2G2fK(>]cpr=InJl]T7+4m`(*'s5\M)b=MF/ +%(9>4$NAoZ1D"Apo1Wp`NEShrs>=F=(Xs"YSG+M]+`S8#uiW-P=04Z34]0)\_B^JF7(c"e=FeSME-(NBEaR!,LIQ?(^:Y4s,)-;^` +%&-/X$"%4$@RP.&3(maXRFO7B0>pjn+Y_dA\>D9$B7Cp%VL*UrOHB4k^-!j=XI;H0P7\9SeI?i?.hluQZ@Z,]2_Q* +%W76Y2]mK#?>lV0O9ng6dX^"f`_l)Sk+ZQai&H'p6M[cS%[:BI`r;00?:o(3UD-29pGW)'qY[3um+m`+-f+\_.o6I)o/]2'KI;jdM +%ZWgTthP?hhFR>3T1ZlSWoYc&?G%+0p4naYFS!h34fkTAHLj*p*4Sm?bkghum[BpHc"SU0Ob'/%5E;(JlGb\c'ZCasiYhdZ:#/Ut8JT=)/9f`S&Krgi!5$p9P=0 +%iuo@BP=&3ne_,8&T>hn\Fde3nab*=c0siJS8)$^o%o&?A4o/'VhE80<"ZQ"A'!fig",IbNVXJ9;M8lg.WYL;@*i9L@_Vfc7W&-=6uC +%S$eK"N*0"KY@e&+'$N4<\tgfGr>DYZ^j05j@_fU>b!o+K8gj'9H0?/3j?tP\F,"pNjP,e_g;W4=U0bqp3GU7rXX5]0-m5V4Zl8*IR^,,)S9e+m;195LUmqMPg86@DW_;=QDl=/O3NTO15d!Zs.# +%fil]MM[9;dTUT(\/fB*Fisu((&'(5i:pa+k%(K1.VDSTsZ>:`)*OL?k2'iuA1;OS))\X&9?/Ru*YMR+Wu=QPE6lrnT)=u%p0H1\b=ZN%%h!O!0jOW<)c2hiHr:tWbhh@KO@M6fLOcr%Pm-MV +%h?ma=\kLIXFXq7NglF!!&hiYC103;^(fh]=0D"IEh<5m\]nWCLlRJ`)Rpm6g]b^^TJRTXCrh=pkOu*oL[j#X([YC1;paO-fW@^q9^=7EY'U?oRVM>O-C%l?SH,*gr:Oi;`kk_./Hk(SLD]Qq:CUWs2/\[-sL7kZ@<%a:*`[HW_X4N-LQW +%EW%A9Df?)Zr$!op;$m=aQ`N]h%,.d+p'OQrG_70Z(;^Vqqtl!hk1UTt#-FVU*+FK@/!U.OLRLia3$DYKmsF:-=jrTXn\199%kfdW +%E.KL2UhD*s$]&(0)AX)/aEX2a,A^2THEdNfAJ2W2<3g9X=ZeeiUH+GgRE]a4_#LG582c+g,[SBnX\`j7hNTY*L>2j[6IsR5B!#A/'JnX)%rP6W/0V +%P<--P2Q'u_WeOUgfXI[TZ\@SQf$K@pE?fMII#;_u*6ot6IiS6B)JqRS^R,V[_>OoA%ZIoRBK(i'1CF#;*EW`@!m2J4UgLk'HSp`ZFl!F6bRWC++u6W/^/+f"E:9ST>)phM@DMdmYa>?ZGK\ObSV9a(nU7`nJmTYpg^6],(26rcV&Ek-cXpZt_c+sf1G$nolJ%_V6Idc4BXeM,F=fJg +%^qL5OUs@GGjYsZ:[A;j0&'0*W2P<]!-^.PF3:<'N[tiU(+SNoFUkraBi['8h!e3-JId.LBm459:Wb)iR]7dpOH&jE62_5(WX38@i> +%+KS/bHq?$9;,e8B9*.(Pr4T22m+WtsfLNA#PEeVQ&tp(55C'AOX:i0t94M,i4\3_Rl>U0aj%]eaL7=!`!*RI&lGUG4eT[@E"^0Sl +%3u`NA;f'BLamr8!ErcA+=o+5W34"cp;JfC_RP2`MTg#eCAgJb1Jmo9<77=>*Xof7kD^.N'"@UA4Zt +%5&GpL>)''"c,V]Sg=J9lF_7T^5CfAuBm@s/cS0%hRqa +%FC'"X_Lo"$R[)Q?&?35YHA)bR*kR9pYSMS?-/3mR\Y3KJ.&5VM\b[([2g-0ubM]k^:RYA9NV1=GK[gE,50_$$B)XR/]VneiAh1-"WL(6%.m,/> +%+7q=63i(sZ^t^&J8&SAWN_Ts%@c))&Lo)OP2Nq/qKs42$G +%PeeA/F)ie3ZWM+/Hd,r+P<%@*/ebN_2qKPH3Ep[#i-AEtG61p$^YSU#1SuhC;d?sjgWS)opZ:&MZ'9C*8T=%&TZR%%29n717n('m +%^XrsXV?DacM5?D\n&:pW^T]/_l`l89A_SYl.E&n%bImG)fR')S?@mFq-f2rsD-0msS9j"7b'#-6.)?:h!u^3'-+--"KF+Ft=j2oR +%"Bp>X=FHGs72!PE3>b+)[OC"lDS0g_c_AkJq1S,nWY+c%A91[gX42&g\(,.X]nNk&*>k:hLHme,ZjNW]2dicE"\@YJaM=)>Sf_ +%diKN=_8*.8;,,d%S;b55+VMOlVO"6%B#Oc05om.',+Ho3TF!Urhn?FKoA185#4,qcc<3<*fS&Z_C;g9Qp^I.4!F[4jnZWdF^9$n:YXH#c;R^*:HI_Jon/77F%U%A" +%F=7fubQ>`)mY+fboFLh/#E+Ij4q*_%8_pHa(N9/q*&44)^lP]]AQf1l.W,)/hgug6J`6fMn%EP1Tr^=s1CY@bI86TWuL17WihIGhBFRV=8hg:@nj#9:\ +%f0FL[k`uXU@:3I3CpJULYdj\`5VgR1Qh`YW69'tHOOa1]Cl^5:(#n?3=D9h_<('rAARn1bf`K*dL(Ej#,fqh54Hf2k%oKq>5Jqf& +%b>9!CUrt+k_r*9%/0j*A6BR@A"(2MG)Dbn$XX^RLDZF<9=G!UX +%V?*c-?*OY99<=f'+afr^p]Q])&)%'S7V:8G=<-+s8K2]PV[7&1PC!A"`K9U?0W]EiQ=Q*+]L6&,4QNBp1rc+Vl9f@")'igO@U%t& +%QNU]^9JJN[nAUYUMip14?K<%K:lT[/KQc+n"RC)%N-N/7j_klC9fj4dPe];lg#$AdhC!Kd_^MT@XFB<[Yaq6UZb#G;X=-r>Y0t +%`aV6%at[+"&^S<36t#q%Z5EN`I*]7J#BH?m!q5,.)[c,MN66(+cXosDfsqjBjX\:ulX5R4Pl]>Qjb[do[gjB$3m+]E\j/M?DF-7h +%7FKY'c._BJbfM2qohPj/9@hg`SYT-o5er[*[M'YkGC,A>`R)SJCiR#Jo34_V,E4#+].^"E?Y&i8RY5,SGt,kUOD!?s[cdL$cgqWS +%pXSk>UV?+385g'r/;J>efuZ5E2+Q`LI+DuTNk%TqfYWAf2nS+/^i.pW9>A6C=Vt>uH@=K]]_CY`HE;-oX!o8A$lp%;Y)b)pr6 +%_ok";%f6!85/5sd]j86f`/ZghB`s:b/IRa,oVt'Gqeb@rT6>5%pRV"Q!ShdVkIWVHc?B^l`Notj1S\>e+uRG!E&IF4I8rkK_sG<3 +%c%=Z^%T[']Kq4^G"S$h&AZuET-2F'7:J;]YERpD07fYI@1ck9lrdD6`!j/hSO-=O"de+*W('U:@_VUFLt7BF6QCMe<$=&n77(!K!8(m#=`fEaO\\DUr?AJ+gr"5(gZ3!C!]7Pi['LT2T5%)k1( +%,hYL1d(TSGDSo$8I)0Ab[nUit\[`s2QA(7<+ +%MYJR)FkI_ip@A-']DaE%h61P'qdG7P2:QLfcrAaEaI"qRTF +%,QLRi)<`0>m[m2[T["aO(A@T9S/*!l%/7uG1GD2[c,:S[Gu#l$-O$6kKe,;Guui;d0a +%EE%Ju+/=S0QW<2\/jJN1cf2k*5V>\YK7=_0dsre+'J++n=p/f@/LsGL,>T]qN"Q/_\4uOt/[AY_Ks"\-blXS\dCYJ-pP(CYW_LOk +%YaE(9*$Ci)CK@h[r&l5GY.J*i'hj#aUqlL(d=3"#AH_T/h-=(FE:2uKB-;K`H"dsZ"-ELf7CIa9-(m[\G4P3r&kh<>997c>=GMWA +%6t6YQ@)d8l08*mLZBfB*fSs")]Wk!.<'u)u0k*qFJX--5@G-6\1.OouPaE1W9>gA>J;0sP7.sInUq>M$hdIB^aCY(M>=9GsRmYlC +%\ZLDh#61*a[gu\p]jfQ:Ms#nq!N-p)c8\DpXLcnA'@URqZ1[\3GZ7'QFe8ZV(P-FS..>mqCZ8Pf20N)sq&D,EDBKguJ>VNG +%+U=Je^aU:3oYC9V-'!##P&4a^YkYDO)IU@K/n$Z#h)U?-dHj>b"ZiDo,'BZQZ8nS)?@0SS3DeJ:prAkldZ!&GmG/"q2^E]OA7I=Z +%_8h+")cKfp`OWUmS!>Z!c-),-)Pk*&?oTBbh2Qlr!'$==82NLJQ59J>\YES@`#^ZfAn+gX6NHRL)MJBK%4A'l&g0AHaImm,s#n-' +%!gq.r_M>p0J0p,[#Nsr/.h\2AX>2_;*3MY/QeWe<1()M$T3BOH]_(K17[h4+^qhr1&!fgIRRB9K35Yg^/=p(sPpgle5(kOAe^(ONg"UDd:N%TGlL!h= +%IfBRjBtb!HMdOK5Y8F^srM6T^e,<]!;I#j7(hR[V7]@If1Z`ASBI*25b[-bJKER7Y[(lFZ5Mi0&D3f7nqsHVsU[9jY5/ZW2hb1QJ +%e#\Iu68JS;%&+I,9G=XMAFkr(=j_%qYY.qgK(MdMh\MSSgtT;,_ll_ +%['d[g#kFRaDjWu0A=ade0rEpuI=)!^hlW<9=Un!/hX\HlGdJRE[=<")S1=KtiJCi*)R:@[R]GNd2[*P)\%I*j>^GDiiUQ(ta5@f6 +%Q<>-F-?G6=GFj0Wc4BU%11M=90;mOB8d!/>RqLSpJmr,17XJZ,gaOT`+__D=6bnB6TSA:)n>6ca9L'DibaBS-p'-03[8%[nncKs% +%D)1[:"WUB=raL"+B`;#P(2;;i[CGRp:9m7mhs6%,.,\^+e25O;4eu^mMB!l]\?gH^@;:u?,DWJbP`BK5o_+^'MA9i*PPthWh.H/>51OTPA,6sdRN*]TBRQjp-GUkWD1"WH$%J'[W!/2$c1_q_)K!2LjN"](pE-C(AK#-'e\uu +%pe+_Y?r,H59]`2HJ%1OO:[,N([YIWP"?^q[i$&Oj;G:^^.10#dT^:.AaL0;IKO>go!G5u(+(!s2=R[\/8s\U\]85[/,.`SZ.WcG; +%p0MY]\enN60^PApj546\dpI`AJ`HR,m9d^ohV1lCq.I#S-D8jVdfP6b=D+IR&N=S%gp@-;bOg7e9iVpq2q\#Rp&o5L/$=Nr +%XhiV%k\6F]X;j)B_e%Ki2iE_0$chO#]SBmY-iSY:^_[r&k'k*JV2qta%GRW8./CurrL@2G@Hla']G*ejL1pWOX+niHd-8hQo@=7(poTVs=U7L'u,^WL*+@!%89mhQr%DS0 +%ct"F[)m93RBrT,5(h2n&Eb)1n2Ui3!h^smcZcS*,>q$9,>jW_Oc:7`Y$pNg8Gnt0NYE&Jm]?P1I(Qc@n"5b]KDmV,cY.OLnVr?[g +%""1r@mkb^dUA*Di+J*_/Bd@4OQQKS3j#ae9MAL=$VpKH]aZHkGf5fqZJCt[gN97A)39Mu!lGEF$6j?5^QAXSaTHf:(Nbm-@<6P'R +%XA8S:Tl;q;OW[tB2t0V?H"n*6m"m$M3`*h]2$B'*K2laJ4<+reS"m6Nf_Mo`jkagC_Ztfs(@>*e>*6QQlp'uuNP?Q)e7*;T!sNEd +%$QSNS3:8nb6u>Ri7WV.EZt6s.*$dehCs/9u>gi3O,g*K)eU(1Xo'Udt*4Am$Z2LV<8Wo'InX>6MeGg_&R(m*A3N(?Nm@(Pb'YVPr +%>+T&qk-TY=c1"Y$#U!Znt!GF7t(n+ZG9K/;8$n6!EW<'qtt +%MP=WnEIBaGM5TMn9JoquOC(+%bsSm*l',CaaWpiWEIoC4B31][B%YK*)(0@MVrM"W@msMQI'Es(;=c>7+\e]UF"*bLDX1[?]'Uo; +%bZW_ZIV:T&_CG`^$ZY/UUd0EHihdZ$#7]E-rnh9*P]u'(g%;XRhX-\5BR4+.eLpMWXH_j$KV`97,A&mqd98GU9(pEM>9(XMTc)q: +%+,1bDC,7&)8dm><2^I[67;&$*2(a^q1KsS`]]&g*:XH'NHC[IiRM[@o1#u7d8t)DA2.EE$[_^)1"QjX#DOFWW3#;> +%R:,n@n!2cqSnr`i-chPl[8KlWlt*KP%e8*(S:(*QfiQ#Hd:DcPn4I6?%$)9W+G)Sl/EZJ[bg^Q8_:t@67;M])#(UQ(*uVPJYYP<bH]4OfK(uiaa>3j_!fq:GZ=0E:\1+9(NV +%J,Jr\`..Rns7fC)hZ)Pis7lWQ^F]78J,(btqZ$R[hThblc*+n]h:I/OqhOn?o,lDAJ+<9j1'_\>)&m\ +%]m%rBWh7fA'9O`@"3d>_7#7u9,5GYk5O1D">lJu:L_KXqq1_V&ZdkXQ86Fs=R,r-Nrs7?Vl<+eR-DWb*9UKdpf_6SArF#r\Z`3H@ +%j$+78TdG4na4L^[Jsroq8!H=]!@Hn+M*g`tR+NhHq(.P:$->)^QdNS=@1Q,b?<['*22(3BDP_^3*bVjkefO"6$O;SRVdLU33,`ra +%7ie_7>h$P1h>kHB-H(o)F*)5sJ]CKo`3[_#Pod!a2[5&p`X$JD/k4HI^5^f)\DU.&D7C3E861UacTVbT'>hctau9T)AO_6-]1r9g +%Fr2dRa_,7kD]:7;/n*UnUO^Q$AC0iEU?QoY_8m$t&"fsaZ%4NR5WQ:Xm-SX:9b!YL4hm"<_`A!(NfFff +%euAq!&=Kc=S][;Hpjj"=cr.?Q/LQCQMa\j#0qp4(HoOk9&]lZ#&f/peiRhtT(0I?T7+hhL+f([O +%ALAN!Cf^%^Z:tV2m5%_J!:Pj5Fnep"2XFEa:ea-q?[0*MC*PB-1V7iBs`VX4>PE8+[!^9[.Cj!RE9MF=QTJ";gDu?DWCJo;/\8?Ye!= +%SuVHkBJTb.e$=Ji(oMpCLG(>SK908BG)iL&VJ5/A]8g#tn^?@%qeG!<'ej)t^<;n7B[8HAar6A="8#!bR`9aG=\$9_IaTSm'S;@6 +%-7;B9T>Q0;`%UZX[AVanPOV7.*LiDVaq/_h(pklH:n%c<$KY-5QU)U'<1Fc7`YOOBY7;,(C[[.Pf#0.a%0BOr9LiH-TeSATKg";.fSg#d2S/eS&f'<3mLHPo5Xjkg;6!>FF:]d6o=^)mmWG@+*ld^nXQQKFbD7lM'$#'=h[QS[rW/jF>hQ +%&HL.1`72'BmA;!K0fK$lT[=$=ACo'%4=tUk'agR]/-]l)Fl^"_<5sit!P!'*T$8uA0X\O=XDdL:9O%,A\Rj%*QRn'B\^`&H-ea'$;>tK!'32!&n7DLq0_QT:s6i +%a*KT#.LkWEp*QS)\nOSWYgea`."d2fk:Sc*_Kn;>=7?HBui<',Fl! +%PGdu>fJaI8O__=n9]+l:KjYXK?qbDU>VcC%6;YnZSJ<8G]5ggIGZ6W61?7%-Qad?Kfiu_4_C^$e-luls>sZ2!S6Aq)_Zu@V4P^jB +%UhR\.QC]?JR^Gfb?JSd&X#6TZ%BcT7Vj`]N_!^teZ\`P:,0@DTgP*aU2LQWU1QiS!ju<1Wf5fsX$TV_V,)[4aPsoG)MhK\oU1Sln +%V5C;:%s%_fpXct+o$fgP;gZ,N4l(CkF*LQTkY5W,eqr#%L0`(?l[HfNn9`gAVMhP/5"93Y3g"M-2s&n%$0.<^Um.kEAbQqL*t80Y +%igc0Y0Q;G]eR%laZ.g:0X?A>F<3?*?hB+f#YS?"O1*P2>c"+9KlmhFDb11o\G!,HW*funls#tXN!?lPo^E7W0T`\J*r-^$+pp85* +%_AnIdS+j]nd`2q^[6V,E.@)V=.tu*j;X$&NN[5KBF"(MINce+r1jB&:(?p1gVX^&XX&F(4M*NopPKMOg+1gQhFDAqjb2^MT_[QDl_pt"l8ojTX+FBn@!YAS#r]4@aJ)T$!;V8R$.+bQJRXat>rPFpBCV5Ag2E@Y1,1he(+(-d'$ +%!R9uV@A>2^TRE(+2f5IjA=5V.ln\9RVV"Aoahl79nnR,!i*o,'oO0*HrIPL)8)8cEpO;c#Dgq1PgAPrKL]-nLJ,^2lqqWCJGR9Q3 +%>Jk!SEgrUF*$/@7];Zs1hk%asF_!LsDblAjLA5KdnZmZEYbjl(ZH71jd-5V`T$f/nEmj"X_pJ0Fs^K;d":L +%mNi+RPIS_3$_a`Bb8;Ht8E+^ua'9o/=K/e6\'0bk$:5B9,EIOYg`f\UX\\R]5JBVUIiPBKBuY147rcp&"N`*MN?*A8%d5c?`3@J= +%cj7,ghjRgV;=g]rY_EC]!A.4Jfk$aaet$Y!ag2RI`O"nOi5'9F0B!7CiMuDmA-d-[!/@>sc--j;u5"Th$/21]6f/PsV#R4t;K2?,$bE5X4PDDV_mD6UE.Cm^S-,2=llt:nDI"L!1=IG"[ei +%Ir5Ma]sAfsFa0t3%459DVNBaib\f8K_strYZNK`]3Q1"fDAHUXU3MYt_rOO4DYJRk0,M^m("!4GS/UX#5O8&"]+\aT3Ssi_0(+4N +%Jk*n^2-lY@"Dl/ek',e?m#o[c,uekKh:0TQ1i1HY?5Qr +%F_&?Dm2k"iK/@kO;n/*[)tQL9A9U@kZ,03hq1P.%l,K0IJ(k^LJ6u+l!8pru4]29?VIpXGJoLM_Y6ZX3J3;Tn/GK&pi8=2H1CZ_. +%+(n!,(g-Cak#rgn,')>=[^fC`f3tGs%5D)k9IhT*@YGd8/*[j4X'6*826d/45c@=q-V@XLmpJUKoWg*)oiu?'"'OoPVUu\j+.'Xm +%^e3gq(<:=`nsT&[fNF9lN8i.nSgCc.*bN1a1?\k60Y;?/5Vc7faSI91P7%Y;*^]Y# +%CpXbak1t$m224cZ(Cr+g63_F9*f;i<*FsgSg(D$^&qoaZrG]XFi^3/i&TX<)YSm\0'g?X +%A!pb5Z[)V*7-l$Rt)T[;3-BBDl.s&?&`1di:(9,=_cGA8H3t>2q)0AE(lWlJ?/ZOTEfBK4bZGtY^=.PMl.hY.99XjUi*;a;PS=uR^T=@`cDFM4/E:q$b^0Z$7O[sH23=[ugEQj@:ji=,A1#")mGMaSn,E#Fr5HGKiNN7Fb9-`JT7?gO +%J,/Otrm),&T7(25['oOts7d]8cTh?N5Q1G>5Q9>CroIL7q=:^rs78JTiU?:&TE"[N4eDRY*rgRlX8Y_Xor;,1Z@&+E$@?@;Cl%X1 +%'%QB6Ys$pLqj;WaZ7R)oaA`^2?ZgNpDjEXnV,AUs+U&fNqZ=1TA1*QoN9\FiH,UY0Z#W^nZdN0qn.V]3rZ+qgaXEOJ^:#?R[rh\PnJ]:^m9Zg<.UEC=hN\i'#%=0a+ZeN^Hu]9gHe$&\ +%s.[W+3NEDVEfAK;$_cI7+lpauAO&=*0F/n;90I0%:!X_=#X[N-5?p^..TN9e1TJ1LEFBPf]ci;Gl)VFVbuTS5NS]#Qc:#BUd;Tft +%^Af$lM.I::7\f83Wg+M.1j,R/dIA3^qeECHk.<1IAmQ0T?IW&61(B<,dR&g>',]hCG;1'E-FCi%KI"huTge:G`8'<:Bm1N>DqpE2 +%2`%duroSfqpE3_k[79q\ +%poH-+;U'4WRf;CRb4_hl/E0BmIqpDjN`Ti4hJqY@)M^./dI]oOIF?n\%J4\!j +%Fpu3BPOKriiC/W`D0M#*,Do.+"^8%DY]e-4gN&pc=@*880S)oGW,Bs(Fk>0:Mq<0>4Vr;2g1N.K?Hc$_@01@$6M1S +%Hm^J+rsPHi3sFp*5b"X%lE(t*mC2SCY/G&!&.A6b'G3)n0T_p-]?(oa)2OdM:[5gjj,U=_q@K +%5@!0Rb.9]D._qDhO>*q7JLhWTbu;UR.9oc27(Km9KjK.*bt9VE_*81T"P5#o=.$[TqTl;ln!OYG/*# +%UDWmY-fHU^]b;,.bCR9a67;t81eCdqg8>9$:8IX8Y),^^$?]jko!\*XQ>jkHjr&24GSpe6IP8_rf:It;[1k7b)BsDg27K/iYa9;m +%>d6:s0;R!jOI)Un_W0![?t*@RjPUurSQe*7.OjU?E*U`-5agMm>Bq*b#WcUcff`n211jV.n@U\&"M]10D_2LQDK>uQ"?C5iVa)@E +%0Q#!Qb=l3&c#0Ib',nfE_IZO`5T,=4:f^g\g!q?@@`h^u>0B6DK*/dAo5!;1t1n6B1]fq +%'/J?Y6(_R<753^LnCh@1;!am3C6;p2PP^/f=Jd.FS$Y^r1#2+"u-kGf"ETG\)ZTpZu5Df!E],/eDt* +%fBQ:'11eph +%Frg5KRE3*S`9VH)M/;^ibV#&T4lGaF^(P_uS`")]_u],j_bOpDr\^BghW2`IR!0'W.66PG+\tbq:#]KG7fqd."%19(mBfK/+`!4. +%Ycb=Pe*7EqD[nd=f9RQYoZGi@qEi7mN2X-4S4L(D)]E`S\IChn%U[O"+GnN:X8B!pQU1Q7iY.=?B(C$/7FJDL:qs[c5CW<@oa"p& +%d/\/4QE:e\^.Ra*R2)>QiJ$WEG#i0si0M+l^ZLKB*LUJ2;d9A9QNNG-A-6CYkGo,pD/[9@UtmeMQac:[Nq6e),FQgraLuo?4IH\j +%_=+XR[^8U)CK_ho2q\j_\*Z,4Vq2"@,:!nne/8Gi?@Z1:Gp=S@;HC;f.g*[kem.M9E8/8%-@G`\6`bB.Gs=N`39's$qo[Qt^IgOZ +%&Y+X3kU(EGPH&C5*$*7Y_/?J>&g10u?t +%A_WfiJ"h2@MRpC'8NRKL.\RbMp.iPC:?#loH9lHmY2^/,Yj;mRq%cH3_Mj=5cr[iS#C8VOV[q5]YN!TL^-6eHBSZL9Y0A(gG!i]( +%1L[H@e';`Q<'`7JN5VT*+g_eh5&SJd*H8<8@H5B9#qo`LrL0%$@$_[SkrbXm$X9hZCbqsM\D!LN#e2bP7^h[Gs&fg+-$oBLMc)sl +%hrQX+WKV-Tjca:j8WE)Pl6k!+N)7I_R_(:d>aMo7fDK0iL&q[X.k3Sl,Wd>G*On1#A?8+@k^i;odq)#[jln[UK(MSlh$GY0K3_EHAYC_sl6q;1+NEc":N#fhK36f8h#^qt[m$:oqg4k3ot/'>CNt@PD5kAU=g>r<1Hk*h>+h +%':V8Vo[UoB]5j4lqB;@a6$AWN+"6Ud0&u(*rt%\f_"?qgP(GT.G>\^O@_`Gf[gX7`)EmNpCDU)JTNRJPpT?EJ"rg4< +%gn0XsC>l1'U>-dJ]L[XV=1(%O-r9P#ELL^),1#6D0LYAS"1fr!Z]iPZb.kSo7]JWm3_iFg^ei +%fW6r4_jjiZ@HupZ=0bo@Z@$manTK>l8JZ5#+L;kNRAUURVaen(qQUoR,[L$Vks[XJ^&KfO5-JEq0N--^/&56kaF*5$oal>Fd$aE; +%R@`XXX1d_U+<#Q3M9*94iX:tOLJ4i3^[R<($*@4MB +%eeq+Y,$2G#iO'Lc6,rsdRD+/@DN9UZ!&k.4pX=YqH.cF)TBOZTodOZlNn=onC0l--r&8HFU/rZ$k;$I'cnK0fMauSdb*N+t4RJ_6 +%6VgsS/C15!e?OaTjBLl2@PN'`YQEhAjLJjSId-3>_dNV#-'o4B6t\(!haLJtA?J^k'8b[AS+i?CHrbRARHjb' +%Cla\\=Z/Yj"Wg%Y7neX,\VBhK:l?`i)!1+>O^WDLHYa,-iX9OJRkO5S.q;*+DmC?]O(J1@O=VI76;Ntk+9(kq\Xpab3JNj/#7rTS +%abd"\1AL79G^`\b7^hT1rUIenqff#)RlLdOW6(D)U,gL +%KPC%[0[hN?Df7NuTTea]45T&[b+aU@;.pFdk^i#86f^7d0,"V.Y+Xe,$93K-%s^4R]=d +%)@g3H1TFURA=`XmW7kjqk];r?DPj&=4#l$(@;'-^($,KZ/'f%cV`O8T3=[0=s0j(WZprF0>!SnQqYs"G-[l-7D +%[oJ6gI`W=YADJ@Mb$e=Hg+Fn0YW.VGNL^5mTL-:99J#Za=hi_)mt'i`hE@&L13qc[^G+oN5U_4p +%Y"h`%p(B_)YZdTf-IGn)&W6#/r0('I7%!qe?+gf'DNZ5OaCbD$`Oap)f]S`^ARh%Y^T<]!ok`%(KhrZ?`NIa`5CT00nta''A4*+] +%5([U[E)AQiOSLRl4Z.m)&EL_'XP^MH#_Te7`QAC>2laODpDl4lios4mEWNqd3,]W-)#G4cPB<`qR$KrsJm'9g&QlXL&qt9>DkN'g +%>Eeeia#'*1RO?$_DciT<>o_*GWBO.$k?OY>F:\pX_*&d#BHVWf\QBF6qSrfYl2&+!5+'642k(s`P*R'*EffCHA-1WQiI!m#,b@<= +%T5D]"rjZ6H6>DYI%Te_sjhP=Kka\M$G^"96df%[K:(+6t-6K\n3fF*41bGm^EQ#sWb=ij3;6\p=2JFdeD>E"k6t4t@^%(X$c/"he=.(D7@FMVD\Cin;Ho19'2J=M.D' +%93D4Ln+Wgm,:J$m^\Fj&PLhm8k^L3"J;@Q-+emXZFG&sTK31])nN7f:q^h8[F>ko^krVS.M*0RhtlB=jNpU9pO)7rO2!5T@JI)+s2N\#)7elFmQIG00T(M>MpVR4'Xe["]Bl(3@^YM)lL5hfTdua"kA=V$_4c^+dKcYbJD6$#ZV]$ +%Pk5/"oi=E.&O8CRRrqNP,Wh8P,3>HshOQ-P![l$LW^[+n"6<(qa4HP-FR9Ms8-.>Ij^1j&^b=gQoq4=HB>g4*QZF.0Cd\QW>>aNf +%]E`<[-7cag%;_0#Ai$T+Ak$c&,gULF\3A\3N>+$Fm;$Tu3_qD@4F4f)U:k:K:0=YC'BjuelqeNnn]r2.MR9ZYFDO$qEOQ#foq"XW +%.HGM+ABp2B?f?=UGNkK^neEl-6u^be(%3;9%U?Q'*u"),I=58kB0/*A.H62Z`-,6KlW&R.3Cd&$:MV_:Xn)l'mXrg>OUsoKc8.a> +%YIdJ^W%LCD-oVl+&S>MC;S/oImd6V>2qiDbF+>4Br4^4ccZ;05Bo4TcHqj2MP-Yf/(bKd2m+,cnCNr\7a +%l=*@6MCe+"0@8_J?ll%kAbr'&\)!Q&/6O`Y)fJcH^fZ)VDUHS:P7>JY&M-p&"t@?XG]l'/V?cqDkR+hnEsB>D^pSK[G"aG.A`nXi +%:4='VS.%h2Tt$'?#Kn\Sj^j#6fc%IQE2p;diQIOp$hnam&L_3&^\B:`0e?/&N;%MD.Rn5A#R*j@Q=fsG)lR(d_niWp^t-i9jEV&Q +%G%$V'H/C?#&ZB#4ZN<9_2lh^9%!0_^!JrR$#*N?!$Z"6ZMLZ3E7EI#"k*>mU<'^QRo6G8I<:<"+dt:tdA]%e)HP!<:+)SsP^5\e. +%m<450&%l2u*4J4Q(eKe@5au'p$hWkb.b4;CWptoXF#r(aY:n(KID1r^:*4AGDYITsLBOrY4aufUV>Ofu"PS_?"Po6Mhn7M+LXg]Q +%kokL7[h=be@`A<"aW!PuRZIiq1JTP8VH2o5EVqgQm'%r;r-eZpNg9:C2I^5$-m=S;>.9Ik]sd;=@8th"*ZKVdH,r,VilfVnE'B34 +%l(c434Y'BF&XaQB9?Y;ll@^AnB$[GqQq]+!LaTfM3a=F=dl)jBU(o%cB*6UeIHeSi(`5TogGaK!J>81'Bl4S6f#B7rjhWu:^enJa +%*=)P$fY\RqNo,+K.QIK6o;&JK.oG=l"Q":q'Wq#/TPc0/Y:e\G=WJE<16QCI#;d-K/EL>g#QoJWEV4WgDL&JMj`KGkZE_tdfRqt^ +%Op">q4$4$t\(j^KrY*Sgp8^H6?QbYW$1i*A+U7%m^!N5>B`,?HUD> +%HY\X,s0s1I(!Lp1\@D@@nm7si_.7hE`IVOR`u\Qcjjqga[:9kB2BtSu=#P_HNDh4M(^l0V>/F[_9JD+%NYBK=&QMLf?0U^P2pT +%]n*nl(>3t6Te!kDC,H:ip\?Kr[YLkm_]KnsNa[u250m"Bi_,EP#?S +%)?fN@F&on_M6V7ha6&**4Z.*Zf@,BGE5[3t-i&1Z?0e.cGF%8c=M?PFU*ZT[5=3\S!U/&_lW2MeF-]P5lQk.XpN+Ot',S3=1]1P= +%?k-h&N994MRB4K.%PY&!6;O3qZ6h3:eZcC%Im.H]Pht$Rn?PGtDaji#Kh4H)aukEH%tb\b=_Kn5T8k4$3&b:0,,J15b!LXfOcI#ScH$KYS[^;b+ZYB^SF +%H9$7K7'K]$hVo:&P#Xqd@`ZXTn?.BaD:]TJ_[#SZbXthIK[ImrK&'US1-N'/&F@B +%p1ZNr-JVHL[VRV"F"G@e(AEr>LBM`FBo2DHSkK,m<(*jG0gI_S4sO]n[6"J*35`G>L1kr$Qri"cajQfIN:97FS5S)/O+gC;R5)S; +%_Pk4qkc<qOko(s1G)r?,:AWQ*98YYE>];;a7NhT[s@;!T)MTY%Uluo($J(^"hkO +%OjK*MV'JBbcaAb$lqLq8Xnm,WNPa)?QgcrT)+OATMd\`,LEX:l-/Qb9*&3.?*p,\X!;#OhCs*+;*X?:*;h]NZ0KMblY&SR$_Qg-fcpq9oAQ)p(3jR$9->\f<@pZX@CZ`gKgB6#)kj[2u140XKcC@0TG +%#$U:XUnIk"c.jbJ\/D]:#o8GQTiKmlNNQhI]IXMW^<)\)B(_NU)HirngL98I&Mn3#moIM.lmM1uQpXQG!ntmmFaMV(0_Oc?B2]uS +%4PkN@/`rlC>FlXb0d*+%4XrNH!>%r+aEQ+<:DQ.gTXJ7Zj'a#Lnk'j$!>O];MshaZYQMj%^!K@&6E:.4YYlhuaO\SG*+)(5Ea%q`5A2Hlpg@jRFS`\j4m%.\3/5j7D@9;pR:^cV6a";40j`XV1@R@6(Idc)jH,Lja?> +%3V7HtX!50-V/AIWT5F@Me2)H#]*"]"CMoQkWCAN*+VO`aciu]E\PHucDTS/82l_sl[4JnopRe+IfmpZX?fZaO7cU+'AaWR +%mQa.$LPL1A[9K3,ls]Kf'/tQ:(IYl/eTtf%Om"\ob`i/09%rOH/p&#A>NHmJT"un??e[J/"VTUD!d!Dt*h]`T?DN`?@gsQuYXn-& +%A35L2.foN4X-V[2Wku8Q,r6(uA]:i^WB#"A;k2DK:,"qV*5K957@La[W*8FDE&HO1DNclT)'c$jcZUsYmsKSoN[EqEnU1eZp?d+n +%^*`/e!o(&]MoV#FEX@i'8Y%^YYZ/ +%PBc=-rL0Tj`MIa#W*3*-s4lpo$`OnOD"kKrE;4D-tGS_1YFqoiT&'?V&"N9(,Cj)"n/3EQ"iS-dA,-10?PKV!Y*bmalXih,?e'img.+LLhN# +%kXJB4l#S)n9.[(($!f^20KJDCbUtRd;4o]?aPpX&S0OZmd)i"C?=_Br^75qpb-g*mf0QE(*;K#T!fe*n#4MK.&03e-g5%m#\b%\GjmjT51J.SB]3b0T,5D3]YACm'dl3N*Y;kHp907^6aW+NaBD5>rcogDj9I$=*!Sd16'i;09cee=Css(96XM$\0A6@7l%?@ +%F@^^5GD2J"^bH^LL&]qk*/O8M;/J8OOp*:O04sItA;R&nd&gV50^.n]k@6mC\_ADsQWaR,nWghKNqM<5nXr4+gtX7Q3Eq4cBAXp8 +%aU>/$N$qb7"O99[A&BS`2n@L3g+pc,d$qt&,Kkh[E#n6\rY,r&-pH%iVC3cK:GIB:a?/#0$fn*eUD2X'gh]%sA,=T2k +%p.B!s[5r"d94ml1AS%F*YSY7i@Qjk?Wkc/.;@m>GLuJ,204VHXZK/p5QE-%AZLT!iVFEqJ[d[GU]Hr[kcY&e#Wp=,r!gjSfVg80F +%S%H>_'FRHhWC`\q=-[WQmqPQm?I@nYK;fC7p#"=5KXrN'UgRW3k2W,l'VA)M3.u"PbPP5rQg7De] +%PN*5k#_dA-&aDe_\E\2f]+')h?M8K[oa=paZnJAWANZ`>oChj"_:4T)iaUG4*)"pM91N9ZC#3VS?>q-slhA+SS7EX?OFj(4WY4/j +%f,)ecZj%L)b4/Nd$Q=iIlHuQjpU0)KpIghsG!HhoQjSf,nImab;q\;=o%lYP>-F[6jFZXng6ZO<]?e?M1$S+.HCm/l^;OpjK#3#nZ_'7e\oQ17Da,[cGMW2BU-1P[<+S[6>?b,)Gf&hE# +%VXLH^!h!SQh<\(8JR^iQ+mMsgK8L)T/O)K1.Pf6"o).Jb<.XLpJ">PBCnKP9@3`G\a1ae>+_;`>s4h%=j4)o?G(k4*ph]-\e`73K +%?m=F?aW)^mY52]@2n'D_USb*kNLf-&6if3qgH8dILnhECM!B<"H,d2^4$dPuU(@O[Rh_ii%^@JR"U[EaJP[?n[qA4'GlKb1#O1_M +%\)9\N;=FS&mK\3%ieaE8^b5rM6jqA[nHFlKZ?bT0o?6!(W\&(uLsGNP<+=IFLTl/NG/sPb.$]@N:#%:PM0@As\WR\UUJRJcGkP+W +%hSE-0M@`%#Y&&NrOso91`X4Xd)7^j,YMIKB1O,hjCY2Js3QUoY5%;AIB$4:*lBs)b/7!(Tj$5HLTbTl7gaOTFg.re<:e@0Lf\6=O +%Y=X!*muaddh1tN3pbg2FS1)*PG8N-Qn$#lB:HtYMq^<*\3c>C!Of;[$T +%G2ZQJ(J"5Jci#TdboIX*jO+QI;gH/mr6V(;!+p;!OSQoIJC+/5bd2u?DD"JL)K@ZfVC-Z.K..LKYAl:!(DsY`L!2O9b5l'XJN[64 +%MW48Sl'*b`o3T=uQnCdKB11W1Pf(;o]dZmO3^kn5HS\^,QT`pS[7Q,e`SC@<'/L[r_aW;@gV*Aq?l)mPf?b5(*j;m%j[66\6=Jp:3ej?epjK8a[ah=\8g5qVYi"Ta0sP`=fm0K@R<#`T)4'\:?B&jFDC4C#@$P5].k8W>k2d((;2*[1Du4F<;#WadD7nD/ +%dH0El1b2>[=DfA9TTWa-r:`rSRKT;P1Q:l=1&[1.CF%a[(*cPG5uNu#b6u1C!gW&[Y^S?(caBF<*5R$Pc=rqRC7I4ZMUO&"W4r_E +%eh"=r]i_:ICQs_k^Q40f*HDRii\1V.e)WZ[;66k`2BlG2^1/.6IhVdoV\jLF\ViJ!FRP>J;(SrK28>Y@";Tg(hti&%6nWG.$<*8C +%[N>;s([VXL@=pXq)h^O]>r2#2B$GIr@n]MAOnTcY1C"ct2*F'Pal&4=E3KXjKh0Yt09GAp69#t\P3P)RkTr;O_TT"R@]?EQU=(L5 +%eone1S=:A6,6ES%]sHK_2Ie@$71`&#B"uYh1FHC9Ln7W;%EjVF#p&'Dn7]K7*8!p#DKJKYQG\94YK@pDlEC_F"B8q4rQ>("(ZhZI +%9?bMNE&)UOPC&^chC_,-GFnLD!7Pc%)96=YCJ5AU:64BJ[n^b"%hKIM6,s)T`JprLP7f[858!Vu"eh=>r+#_i7+bMTX_%;DL.FEc(!ldS5H@,+g,%>,ShH>%* +%CEs;mF75PY\Z<$A1=o#aXIJ6k/bT.EP5nPs5%JO-KI'FF03,tiPsP:)ZCpX]4M.qooStFGh.I>6=48^dWh3`j.[V.u>?A1FZ,pQd +%7%cW2Q_qFOmLEqTQfRdFW$U^d#V0qhY:8%>$9,dMW*JAF`c3Y.Y6@5p)P.)UXr=D=1*u%S[tN](@u&GE,@g8 +%-bh)`/>]Bp>tS18LggQ;M+45bMR%I'(c*sc7GRX.egh_eC')u+6F,>YiX/bi;#*g"!B7'MpB#mY`j,0pW[\h5(C21K5cut"k"I7P +%VtkI3e^'jYh;(i/TPW<;p5iRZdaIlF8I>_X9>I-A"cuAtm;J4JQUA&F"0$a6aG@`oA[;s%G\QBt*/#>W[MApRG/& +%[hk>t'[aiSC2::a%E9"6Sg&`?U.+.*1r(Xs1K0/Hnn'M%2DCHdb6.ZMnf^Bt[j7.'=c7Hp'Wh8!_dl&_C:i@X`d$f7D;fmUUn$^;1'Y2J#@"aJNgU]!f%W$#$->*liDgC9KKkeW*#AEkCI?EerD%QqV +%6-6p?FN'!5Z_iFLHD,a"^Oo0ETZti4I5CGU/l76ZXr>)^+];Z_La-3H(W+8%BD-/TmW#H/,4WpBBZP,r.+GCMncSgUd[ul&1kd^k +%?kiD(g';D)V?Ml6m/_b;N80Z+#aJGYpk-+R`m$^eM]HA(9kAY04adTIAHacjKei1j]pr8D4.X8@0lE$&Q+OD)'?)e)`C"CBpSRiJ(Jj>;V.pe:@F_.E@A9Stbi/)Om1FB*gkFsrl#)G99LPR_9@-pRKLpC)g!^n*t5ac@lFk^JD +%_B[Gu0WHc--)YpiQ*Nhafk)6onO!p%Kp\rI@IDOKh97[>?4E8"SRqm'1OR>!LQo/IOCa_>;:)rW01$9o3L[B@M-73',[\[tal/X2M:.+SVN3$Jbc9*p&P!]Ni'^EMcH%E=$cd#,N2$[/N7'm=G^s472'fjVt(4M +%^7RLhc^^+Ef&Os2a:]kl/FY[CVl)ZXgMe'.a`cV21i%$NaJO];M(7SOddLE@Pr`+q6N#V++l3je]X8N4-n/+Cr7ZP?`se[1(>R@h +%S@NG=aXZ0l&dL(2jgM!@=)QEhEqbePA((2?C2EbFm7Rdt@FkuX^"tu?6h[jS]'2003mNn\/D62JRS?jZO<>U`"65'HB8\\mZ4(s_f?<)FHW+'/]\_r/8# +%RKD`=n%`c*roJHaH0(sYS*W2L192Yn@f`(Q3O!mln/'&!Et)jZ$Yf[/`MA;t7LI8]5pR*U/*B_:9i +%cuO@Aq1c#t3Rhq&oFq"0d>pR(?umkPDPo4km7,\dmLY0B1^c=6UI06#2[XPPGM\iUgLN^beoW-]`JPnbfYk*qhsGfF\kp-2BCZck +%jXeOAS8Q"bP[(Q0n)AL\52?-bW;[.3&3#IZ>=33cXjD8A:gWbpbfm^iM0,61rF,mt!MEopuk?Yf>K6gl? +%(q2W0R.TjL$f\F9>W5W)oiUcfm0Sm7booK]j=[<3D=.=J-_f1b4?^(2-"#L1)f#OLh,UqJ9V864K0._s0J;Ki=sUIkT:ZaV:>p3[ +%n=ZI/oj&M"j/J&1`3pthCQE-f[ntEg2o)GcpK@?=OnZ(cI7ZT&;KC'CgD66#'W9,+Wr&A,Y;'o$7A_iiGmFXfp7)cm)Z*[Pt7=gZ#paiA_5j=D4p]TQ`gY8nGkqZKiFedmL3!F*&3Sef9`^!c!i`< +%KLk.#fq22Npcg@`]/XKJlP6=dl#09R(R&VhD@.;k4`3M\ooCge`$nGkC:jS4(F^q(#NXYI9^2?VGs<3#ogO'13S27":R0"(jXhL`UAL.dI-RE.e4e.2o"4>e'Doi0%S6FSk:h@" +%O."K#CdT"WI8!`3;s`l0P$QH],A6[p2EA.;@,u_$aY"Fc_i8 +%,7Q?'>D^8A!.Q=[Z?0g4Cth&HCL4Qd4#NP5S/h5.muPb:\0ORScPg>P*#qi)EE&*:MAYMG,oVX-YeL^k\6TGS,GfpI>#r26Km)ee +%92u,DGK^Z5/HL*[ZHQ;%n972h@>XKFma^$3W@)-^$=^9oG@"H;4*Q^FDYDg.[o-+G@G`SHGDNINU+gK,C6*(Q'qE[7Dl]nBnVQr3 +%5_:M',\`,)?Tjj"#LG6q4(r@06GU#m/DZPRWb'R(U4dqSJT\-Ibr9YBn2nkt25K'! +%\N9PVis$XYTcC_M[T*%#$/d@^]Kln+\'P'jr]E#r\"UH9g2q<>)9W%WB8IP#O%jDT-WmiCJH:CiOQFWtXb]sd<6^"?eJ6n9ge5;KMQ8k@?)j^P%^HZ`+k8E+)jl7GThh:_T48R8SS[cMdQ4K8(ZP6o)#9Xh0EK/%_2(9=UN^?Hl8lJ6du264kL +%3`d-<<['a`58004Bc`qQ`e-]0?nl)*`ia:(M=N@#WUBskj;S?VrARrP)F-I:-\]1gW0h_agaqK5`]5:E?JDb"3u;9]bb`q$U6'*] +%e9L($IZ$oYmD."M*%qmfmtsn!@I.^?[qd'b^6d!SXfcdBIn\5gHTkCu:';&5'V%7Rac:%;VuF8-"?^-_D:mZoU97[c`$T5MSO>Ep+7GDp3.X=5R9M\3BC/)b?.\M#SK>jk7A +%e#=pAs8"QZrDH)?Nj\W<0=!pZ.F8tNGld%-WS/JX7n_:a;8?%P"hbuqr]U`Nf!="EAV$9j$H*W8u8m:ss +%;5Pj7oKFf*NEH!1&?>O\].lO%p>C6`f#O!Ib*,K4Uf2&+';h6afD`_X:e6PUi4fT;sOijLm_W8*>&G'Q1+Ql=7p_T!-2*r?mf-F$bUnPY`7[KP!@\)'LA +%cE;<,%T[6M\K_;f.J/F9V:$&Y!7Ck/6SKT_X^ZVjbK]'cIN]IKAc@oA=ti4&:jYikp3XAD*U\5TCKp1()PG.-+Vm]e3='i@U^f9X +%dR!*Ih_Sd*gD&X:)mnht>s=@Zb.G6&eY4,3*'`eG6s"%eZPF*TE;,,ch#QXt-[jAClc&<&7-CDoV9VqLI"sqgr$b_gX5;j2gsO(\Xp&F=EFO! +%@8q0UIb1c-MS$PD[4luO&$U16b.OJ?64X(o\,qFI5j?[hFa#LnlA@pdN=`9O]tnB/o]_'pBW`Rk^_MS&^-@PkJSYF47lMOs-`:U3 +%.UK4['o9J8np,$t4@<6%-A<%#gQL:Bm@JuI)(>o.Cf%4b+tp^eKZ$QoQn4:6n0"4@>l= +%oj/XG*U@::SbL^1Gjj37ZgaBpK:3/\7ha)d5PJ)8>OTIf2Esjj%t/[%OL[e=@.j#XpL^Rg%YQRYf\)B`f5ck2\2)X`D91$fDteCJ +%"`M.bnX*bqgE61GU:NfuJY&W$R[r?pjQnKP)oM&\WVSKa7ON[9WKENF)`GL.L/U6]PaG)Z?$./'.tOc:h8j&@hAiMt`q0/cX4c6t +%lb7[GQ['m5qB]4jk("kaIK`3GhHHP=`)SJ'@d*lgbsY^UOrFV!L9*3._"WHNs8ZrluHNd1q3h/\+@,eD_$1k)EU#l +%l9f1;jP7uC*SJrp_f]7Sp;u\JS$H8MVgT&^*oDp^IZ#aOaMm/1LE6S'AnAVF +%m_Km"UA!D@PNX7$!$-4*34#e(YDBC9g(:7lFX8^5rPis"2>32iO[!LprPcp[>rmKlTL+fT/CAgH6d%b7`/GRsG++7s`q)gF_"IPE +%*1Ghu);K5q/'*T6'LqoMU;%N,dB\;iUjmD]P9B; +%1Su>)lkt<\Rh4T)-`HPh10%aA2=eJ.D,ZI]r(^aZ%_)RdQ:>-ioQ%qe>\`b1#!`[U^;qjqh\A$3)X"\b&'EHq[T9I*o1]b\J\/6T +%pAPKaY`s;mek9uGb@\5j+CH%31!?\a$t1SO+o1:Ado(cO18&!S'"qDR"3EkHo1BV'/O:CHoPr`l=Q;GKqcb\a[a-6n-hS)%/$KUgS]f9tW@nJQUrJ0`ZkV+fe1k];/Z2iq?k`=!N'SqWuAJt`f1L0/S!!AphEZ1m'`Y#]dJgsJB3cL->cpa8<3=MJWpieF?N0b[lL\BQ+#c5C+8,Qilio%kZ^37g?`g7p+09crP8N;91r5Y +%b\S&P]#I@jU26BYG*>n445bnGgaS"Q_?DM:?HTsFlkZ9NF.Kn>lUjX?*sNPc4@sUq!=9 +%(1uH*eOe];%Xj73>K$W*`C6AG".P\JI_sI,COu8fE5t/)&"83sCn[T\[f1p`\Q,q>L#k8-E4GL$jQa45JI,l;fIWj'2K).t"X\B@ +%4?G$(Wq=mkDG&?^cB'+9JRp_:5k#M_^Sq,0V7`!JnO)H_>8?r=.;4M0`7<-Q$>7o?%AtS8aL5I$HS/hAT#Jb:%4c6 +%YHZ:k<^7e;\o-E>W:_KY[Zl&YBD!5,>>Ff;4P5%:;2%G+o3D>ZX>YoufjltO[IiI8LU>`"(CiG!/;Z]8nuR3i5`#nD'HQl_u0,>**?/6c94S?#NL,l0n&fEqH`2U,$TM0Wi;GF3DJV8k_'jB0g+k()/a&(^TGj5G3b/(DS3>+XW)S+hSUWphPJ3lgZcJOG[qr?9?Wu5t-N +%a^kXJYf#FrZ,nDGGB*6oIk$4#c4ZngmYe$YZ9g,!+>Eo>Q)D66RtanEno;$`Q`X`FiBG&e'-N=[df<;$kYVjD46^\%a\aK"=,0l9,6Vo18beia`BPb=E@,*nqls37cGoKu+orkSE]hM%:*@c#/O%jqZFVTm`3F=+A%RLg/9NXQ+;J:A#AJ.Gcs_ +%`hLgdh=XJ7FC2Qn4*QIpSQ>bD0]ni-jSuCamWY=IbuTfsd[Ro5/J]j]CV +%IRbqo\a1Xi_'N,84dUI>eJnOkef.?=)B&)X<4f4S6,K#"doCX]EX%2lX#Gf+$`6/jQB!;GM5[F2dr[+XDaBdaG8S +%e3.HC2\pK@Jl*.uFZYX7oOBAZ56V:d$Im-Mei1;5tdh@W!:ncldCKRQcom#j!?U`inLk4QDO@(e.tW7HYrE9;2)c/C3<@L'L:mG7L?->,Eo/;+@;&I(]N%4-hZ9,_NOI5;^:I/PY[C0\[D0?H;!&sp\?eu42VKq8K"^'SL[1G24%hs2'1Gl$h5#EUY<0()lgWJJ*<<3l3ugni"B(Z2mg01.JOs)_a4]-GIRe]`f%!.re+ +%U0$LL4uk?'<<:FJduL4nFt;8#U7F4KDmP7&^NF=n0qu:8I:P^GNd0NRb&SnTeICkfd%c71RKL8o"H6,d[Q&p.\du4m<>ElFi,9PL +%4!Om4c'uihj5*e6I]>=:YrHo0c8?2QA\'&p*b):l<#BZ=K"+`tkTP)I[GFrXa5Q3`#,kZ1$88H<6D:9+*QhVB[m2ZZp?7OF><".1 +%g7/"^YhdI2^#/[;3:Z#rk"l'hXL]:E=%i0+h,:NTFR`"JgW_ukhE%CdN1nbd`c(&;12+`.n5h)hRNBB[jMq5dK4ZQLe[ll$SasAA +%A^U]5R"q]N:s@-@649)n9T\6Po(tDKmrq#e,->&lA1j,7X9BfjAW1aFL#1Rc]ZSd1P'[iGZL)4mjM"+pp=2$+DY, +%Ri$]U2][u^V1"8Sm#B8PTAMVY3+k&<=_U@aeP[VpP$'7"lW[*(AsuO-Xe)J$Y\U!l.AWbsLbarthTT4&4H0=@%\PEC@p:=ZN%k5f +%#Q#7di.3n`:[^i[5Wh:g`DT3082&&so<[j8Hp<\:2j/AKQ[5]!8dMMG`>2nGLJ-q3[00BZKH6EWmoq>BDi];K@(^2PB>H6M\cDgG +%YK6%&V&Ji[]DE/)BYV/>#LMc<.bp!Ief)L0VUMc>I4P74[Gu;kcNh_HO?*&.7JTg1[Rr5Q-YH(QE48mt%(Q91`8N;A$/s1#Q`e4&TkJDoMLg(KD->6*?/"!.8<%7Y?M%4#&u6k +%9\\)@"d"udHlmun>?^7!&>uC8(QR.b,C%U=h0e!pqL0JR\%Vp\FQ"bJ[F(Vk57OnGL4-n/K_4!51bn!3;oi$<"=n"LEmP`^#MBJR +%T@h*CBqal-\pK&1(g5:U>%@o(h2'B8!SMo?QCh("[gjCL`VlHTA1c"DWdrV3'3QjOAhG5-l`$HDkHX]A1\s]paD?>SMj_Of'M!:h8>HVKsa`5Ytp+Z&oM1N'N=[[6S'Hg*tJFCd'Ld&f#YIP9*4+mc-^TolY%,C"B'Bmj#7fK&`D0BP'e(S\PF6e@(Z,NCUGN722WpFV(C?6X! +%"HB51p[mrkq?RB0ErtSSH[BGc,PoCn-%aM"nOE0.c\$V+GIlGEB&5^kUX:H3i"gpJAI;/A0e6V1hRq_ENK7p[E;K/s)AMV4hB\Ol +%`V89i&T;37`2Y0eogU-Z(\/@]8ed-sRkE'*J2Y#_"MTcMQG6sEYr_"Dq"$T/H?4L/ek%;l7FJZja]0n9CXWX8(l_"/qnI;m5pc%B +%CXu\=G$+]khX<_=AkYp5\o*=&M@HD-"T4fkFg>k_RX[O3nNG_5;s:Zk/1n!55qLq0UhV@2iR_rNHUVOq+e8KHG>T*fA2YUE"Kb>/ +%mt0p37=kS$g:P9.$A)a;DcPare8=:F!VW>f1pCR$:%4fM(Rn;0,`G@i/ncGXFp`P;9BofPU1JCb!Rhd`_5@P87qRO0:)UiMIOOI1 +%Q$W&AgGB+n6IYFk65IaY6sdZf6$'.(0&CJ2G?/TWllh&U%-:LR2LXc=Hg<*pFn/;8Egt3herFqD&CUs!QB25Ed/p8G<>cJm;M_&@ +%l%&GW_7ngpVD#bOo"Ai&3Vr/K3cE8PltT%HRFtRrAM.b<1Cnm:jCclT0^(bdrReThMg^!L,p0o$F"L[;FcaGh@!r7IoR0uX^(thi +%!A)D!c%6-0i)F-L^Gqt0Rq3fh"E7e8W#>j)gURReZ-S]*iuMec1-++G6ci_MU@pma"MGn`aKCpikN8_+^CR(5D99rsG1J[O-1MH4 +%^r&\h6RS(!H\02^(7u8%SF>XGoqTp$3`/CSO!O,9'H!:1KIq4)JO(59l@k,:2bcl"Q-P28m+7!Q#uuf=bfI.['C?!%HpOG6pO9`% +%Nj2-.6m&JHm:\%c(OHZTVUibuoima+^fX8rqeM&V<+]J%(e=qO=A^-sn^GZ`U6F1ErZ.2e&F\;`oU1kDc7on^pt?Ser*1<@`AgkiruNf"qZ5mX&Frp<%0"'@74*+;kWiH@hLNU:WCs5A$A_iYG'-o)NWVsa#5J%WX6uc$QF_5 +%FDN28B_:'pf!NlYAdqfZdPGD&bJ3qlAn2_1M=e.R4GB-&S<=b2Q=&<&kf),Wo-OPuKJ/$^*m,$0eG%]0Z[uEn5%/h!G5oj+$7@[- +%-$=(W/3JnX%ZqVDY1OXrH8$/*d/_P#_=h3B\oG15[@*EPZ#6%_]?+7Id%/T1I+JVCi+P/].BFbSQQAe#DW/6X?^gAOcG3nqW&Ood +%`d'd9Uq]#FK)5E.j7&Rqol2flQEI'PB2`n@GBYAp$uk]e&2dt!/I/Ukge=Z:RjX^g1U81o%$L'Y6VZ?e":aO)2.(n>mV>X```FoG +%luU)L^K[V^ESG\81r,L]65dB?WYmm>:sl0X7dpA1Y;U?+F%"3R/(@P\\7J"g&_LsVg+S@e@ceQ-7nO0B!7;ra9dJkWg9,Xif)Rs% +%!@WU(@uU]>K/M<7(`N/r.@"#AG'0_ugL@T&$J85rZNV?-\hQii$c4t'0YEm$CQ"_)1S*+>8Z`$4bFS=W%rU_3b`/i!:g2;WBrYrJ +%LOV;,Xa>#b6MW/Fn$:[WG`\?bVtS$c[6ffFHK!bY[1?6j;6;ll$8Vba^G1i,3efOMrPGZlr4/ha6-U0jTZ3/\TYaPpB/p'-#hCf78d;R'i@"4rVUGTD1J;.FNhIiWfZo_7d#!+1"4g7KHs*]gMM@sgXXTWd!&.WX(J>qoaO\@[*E\_ +%2STd.4l@o%l1>g<^f%5#+NMr.']=Zh=2S?TO$CtFs.u$PpXu5*&h'+HT+lb7?=je]-$gT;_m2]lFAJ=l7;J(E4L[:a8sbf/WEc8m?hbsA`X5Ac;g:piCZ5EKB; +%);m*>NO12YRcT`XD<%U\<*W(he/b)5K."\ +%qKuOLYZ+^'eDjY_bI0s>)Rhe?oK1(scba&8&.R'jFtlst#*`&&b%!"o_fN?m2(*3!kZug-%F7$l5[/goM*g7[KWl(.Lqcilc`TMV +%Y2(&Z$Jaq2UZ1)VQ!78CRk':L(W]%cO)H7!;?YKt5SaXfVL[CJ!8h?/!b3C:J2-m/U\j"a>]'Y8:QVK_M`:>>=Ji_tRbWZ1^s>KCq5')b?";'9seJ1eR["$Qa'"iSA(;J="$d] +%4X2a]W].Q#W@Dm>P5nT`X/_q+EbUIJ"70c1K\KLX\a/1No]r]8nj7'ZZ8O@NLr,p2hIUe- +%#l2aeU%LH'UaQAY">D?MdgG35)Xn9*0f94 +%l@.W/2kW6:;;\hOZ#6bZ-$dE`[/1Mh%>WT1fFOApRjrs:bG^s'MDVSLfU6)Lkk"\2"$d1X +%e+#/12(&Ptmromu[&_$/GprpTad7;.>g12u,0X+rOI]J:`dJI\]^[g0IkU3gOOh^U':GB!!9F1uM+45!#:X@@P%$:+a`#c@gmO3A +%;FmBV3o.W5I;>HFeuc4-RAD$HN4`U#+V]2>\!dp5Tl=e5?]d&X^]2L7s7?9f+9%>9qnjNTiV1*>nLsq$huD0o5+2H;YC?5X^\de]^]1/1q3UE6^Nf_ODuS4PIt%@ZqBc)\q1&D+ +%5JR3ZIs_.3s78#EVdJ^Bs8+JLpA_jUq0TaIhgG5\k0&VNo?L63hHfY/WA""b[&%,"?Wb'm[Z6<&q"s4t*m?@Yn,2&AobUOP?GF!S +%;#PlMTt&W%o.RlOhsh%gZN8b!ie(i-/RW`jnM)&goNEkboSaB@[8('(\fhS\h<[[X%++"[4+@U*=T>(+8JF+l%*uc70$rtI?L6/B>1d9\^58%kMlDuESW13DpNh@88"A+n6@fs%iCR/K2E=7hR-*oD0l8#qt=Nc@>&X>!9fsH1)]!bgL)FatS\T,%" +%B,.60AZdGCn650^aZHa\rRfY7bcU*;104b*/^/:T[:AJ8^:&%#/sI^nPF)+,#&+Q^efDE_5Mg6[q[Q(H>cIqcDS('80]VY-?.TR2 +%=#L5pV`A'BWh7$ujdQ;!"[e)(@]i/2*UVLFJqdX<"agH&p[7,4-[$QjHq?d$X-04VI2Q]?Shr`&0-]R;QNk_2S<^mEKS"79%R#7#2K +%3':.!I@5L*tluV6S.-pXknR]Z/2PNWFCc3uQdH'B4\XWRYNq3nQPk +%^n9A-f$'/4ZXqsb$G?NXQ%dVV1]#j3".1QsVH`e`GBRD(-lD9sp6rS\+F>8q5;oQ(%;'^Z*e)=JoRG,$QW;E._QgX^913(>hBkRD +%m+AoGp1"D1m%Xo_cFA$O::8i^S;\DRg_M^/FjVdg]uA-ng$onH2kM^N0"tkGI!N6o39Ki$+7Ags<0&i.RC+C/\27EnMKZTG`pNE. +%1bntnj0Wj51GCiQL_S0#Wo3[W%^53n@c%s;Y:c37(>%GmH!6$E-2XpZD;7&F/Le,R4[Mk9hK-=&,Ru+23dP/Hb_@+UERrNbl")]j +%o$hBD*G8@E^6:Cfi"8q8UCjG$o')GRNOu=7U&C8_:oP!Cf@*75nTC +%)Q029NQ.;(iPt,8^]l$1l^56Ba1Z]]=&3hunGTm%]dg)3Tln>4e&d=c>%QJDIbOr2"E?t^f^KP??k,Z_b=lb.6t$BSfuS/N/8V=E +%,@9Nj0:@9u5J)&u9^X1b#u/79qgt9f%2LB:=33i-B5G"Gs2+SLptH_TNAnXZ2!TYYc/Hb6dc9Dt#IC27H1b*uE96kUYI +%oC0asPe3]%M=mZL2]\EWpeuHs'$&a\ +%>j=-H@_)[(7!?<1OY5J+7.C"-^0V+Q@.rH\"m0B''b@g;#?F:>Q%S4!RDj-SCELoeGmoG'B(S8.\Cldm)BWP[8r)*A8Z=EETPsh: +%Z[/-V.?fLQO=\c/>4oiS*`Cc1qA-]jV4@$\PjkpR-q`P3=,GViot'= +%70RQfo.6Blc,/\%)DK>*\W?lFOZNBCB[)'ISHD,]gl:)lI9r:`=k["1^U3'660k(R\N/MS'bbp_$tmR$Hc)4&#,k0nF",.@T[9R[ +%>HQ&F9gj_J[+"-WQcEk`7X_e!j4tcKlSo,;+QJ_;TAP4ii`90G4S1^WUS!G$R/9fiZ@ILm&cVZb&(J"Toa$hbQi4rWjs66m*ujZV +%0o."oiN$T52$XeV?jtuXDVc4V+hLUc4`RDSWhQ^?'s@Z!DD0(`@:HB1ogK(.,*b_!Xd9lt2?d>:B%\DR;]VB@QL442& +%NrA('?(17`P`6OA27%eWCWe$%7W-(_*5ol",*i^iQkFlj_t00fpYm6:sIXNR8)SkMGb2b +%MEneZgc2'PB%[:_5bHI^H)llMo'm@@@YldD2d;tr(12W:8LiQ%R&HN&SOn+gPC26iT,C-3]o4HKMun9.kN*<;32%.Ph1+hUQ]7i)(Z%9M?O;KBo*),QOXYD3T;"aO#*Cfci1k=Vcr4rAk`W2?P2r8-!I4"unm,?"Nc1Wmc!-Ct^L1WFe_>4$._KgV+F"R,U?cLgsN&g+! +%!9.V;r7tJ4]*:FW&;SY7M(d/Z1l%sC5.'B&C>s.T;DFHs'MhOYlo?G6"Cb\b_VM%bNN8s#4N8%S*T'M=eS4cP_QpZZEcq_>l4B(VLD;&+7iW3[gpq1Zo$)C +%O^8D?E!*Q,@kT+D$eE-ic3V=AT7J5iYamHF^(!,V2m[rm[H^-O*h52#p^S+s&<%)kFQ56!M$&So[Upr/3..(rC[>I3,Q6YGX,6W9 +%LQKM>"E"C>6B;1@bPMG1@/ +%(nL0&p_B#$Y6`.Kkl+M.**!T94VT,K;`Nel>@J25KXkq\E[kDPLWg$%h#5=HhhnW_AmA>si5nP!;"9_B\!iZsToZR> +%oF>5jSD6Hl2b/]ic](AO^m!5d92iF(,.^%Cm;ah]\6"@;@>rs0_WnXuGtmO;6^Z!QC+-1#RgiM5Oc6&u??+lN+j +%\o>e+!Zq:dTX=?sq+K9g9K4HfdY3b=qP>OP7:ohA)>"4G2PV)]%m$T3&Y$-MO4697.e,8@pA&j+Y9$qO[VJ'gLTo\,hP>&=<`0Y* +%NSJE8?()bfgu>dMGr#^CGkdZ,!FOq?[eL7lroXPV?LHil^RRL$O"ZQ$l/?E,q!O2i`,R_]fQeN]WPa2YYkK14alAD-hL1GHom'=t +%DuWT\`T^&V+$YOEl?K0hS:AScnp%/uSA<1oqVb[Dq>_meiPD^Bn3N*6b/(E0n:Hg\BkD7'R'*K1BmN)bn(!PtDFD@tf1";Y9_+UV +%`F$*S]o_.WZZS^SB!.?\9[DMjfouQiQDSot\FCV!l/QsdYk:4#'8H\OiUD+PW")>O_sqq5.Z]AM_ZB[S=MGsD%kbZF>rXk\#9W$> +%F2![?hgRT"[Z<)&YP>UE*Z!%8NL^jFC"8fAp\?mq#TO=?`^;`V&@rjuS7=hV(d&f@X^anF%,[)=hD$E@L6'A?o,*WSL9JWopD=Sd +%"6a7!I14##In0r0U_&RNL1=]P0o9mDGT9X,a#(pQlI/W`NCg#OEg7T#)Jth`m@Cmps*IEfHMpXUpjX1*%eC5SL%;m +%2PIj3%CaWs&qe.Ikr+k4R*'H\`[E`p47qM+gF>OLC08(<;NA$k@GH22!liKO,7K=/P2bR.o04#),C@9Xe(@W.)VnR\/il'M"!__? +%:Le!Sl?LRAiD_jtH3J`^S?i"s8&1(:6eUMi473na_M![1iC=n[6pgjcZ;":X\mK-*WlDn2[hi*_`07i-c8(>itVR[R'A/D`\0L[C:\P?FKZ&;dfJ@i437+"gY=I#6UQ#;Sf2!$5! +%]jd9"T(u$>@8[]-OA!2bm%,=t[80VRf5)o^DI\;/p:/?"3'\X)ef?,g%LT/Gp&p;CJO<%U;bTm_b[n9g7I$'rEs'RlXuU#';MWf\ +%r4c2>2>iJiOc5l9$=hZiFR^)?E2-Za!!/Mj7-@>l!egH,qapJT?9uKg'[45jWp3&dGS-soh=(KKd3g%O;2EIQRk"FWSVsqVik<7b +%n>$*=YW@2[0n'P2qQJcmM:0QE70@c]"i&rS]ZJo;p7&SES@VN#>XH3O"KL0u6?++G_)GM*]t +%Z+6YGW8F9h4rItL+!>2>62[X2cS^7Ai84nMP:]Qg37E.m0/rL\&L2%)^3^Q9Wb,ijE,K1^lOM[Ii3-40o>^Cs5h9,j24A-`S89JoP>2^N1-8St[i*)&G9.ubP3&fuEKlHD7fYU9Q@h18kB;<`/L'qfWAeNNQ+2s0J/1(.B(Qn0P +%JSFt8[Gd>cT0TiVSXIJ=\)j+V2\)K'->N\Wf9V"Kj2]PCt:,r\3bI%UO'Y_l&3##9V!I; +%a5Z9FFSh@U6k7`/Q,FlRLgk0JVN(>KlM;fXH)l-qMsh*:5UF"YK,C^5lcDGr\D^21!%UEU'<;.;[1$,84eI\Kl&ZV`>l,YO'EZ$o +%*aW1o&A:mNYYc'ok?DIQJ1gKqClXsb-+qH^?8,kd2Q'aa#tM094Im05$U!L0(`L#+AhA')qQW>n"4D^Bl&u/2G;nSN$ +%,BGDbYLm'*^HKAe:j2/aj[m8%BaT:,VnMaM[1]-i"b\0iS:6Cq&^C*+H^T+V6F?2AA`C7&1fNLp=`7dENDpc_V,tg'WG#4Z0V*[O:WHI`o\>=@K6#/gQ$*? +%A.Y^J;:\-J`tWJ?E"mA'...VH!OUhpW9,V]iPn;XQ3CO.WHQTmocZ**5/i]JVM,b#XFl=?F[?r/]e(:\l6#6A.YkOl.`82YgO^&! +%N+<<`Vk$5'Eu]C9ok1rr"5PQeN8=XW%ZPPUOZt'Z;,cDDT.p=oQ[)$iBIVX"":V)M/[@rOL\ATXo$B:4fKl73kVQ18SZg]0kiNW' +%@)0NE?7o;2RFciW%SFDd/rf.1lWAtaJ6?oHT\GfQ_q)2TN$;1Jb:Ls5_Z1/?Lp@kTD.]m2,&D.YP;n0O@0!oI10HqoZ0Vl0aAN6K +%&,e)!H'\O&bo=?*jBKJVnOOO`1f!\ZgKL.Tp]QT66L7Tl#79W(qQNu3!Jt%C6f[blgJVW=X&s#s.k*%R'#0QZ(iT'],j)g+hEeqX +%]@\i5m$7lF4UTpIOU/DUP:srMG%PL_?5e)dM66Pr*I1LQ3V[4A(/oW_YZkF@s-c,)dH'`73OR_(p[mZW% +%=WHpa:9-FN:dMKB51G)K>1D@KV9%\iJEqj`@qb+%?dnpcZ'3Dr(ime7R.M*GX+X.INnH_%IM4LUH]$7PkD?p[\\NorNP$fWr)n(3Tn/Xt40,M,p0U=o4rq?ZI\e'lC=lX(=5s,Iu8qanPMbj8I;"F\)Wc/mj]*l=6q6`Nk +%+'6`;URb4GkS%[N)SaZ&(*2s`__,QS@_b40OsO57]B!4(ehD]cJd;+r>97$p5P$4!FF6SPoYfe_[F8^ +%[KVl!j4*!l[LnP5+VmllnE$86#_on3S?=nljI!3q)d&&DbrCuOp%'+)Ui>4ofL`3G13U_#bW$G<*02m2rY?CYWMFu3DQI+s!PJOs +%Zs#T`pGQ3@dVn.N8H!>uZTp>:gjo?(J"'eDkF8U1^6b"K=2-?MFTL?2%M]6/g.QAs"?aV;"Eb8$lAV0]'X]mtdJg)1sP,/D94c'F'K5H=*& +%YGg`i%6q'2'1n3r-IpY^D@cm@j>BZKJ_ZZ-\Qc(@am6#BgDDtEk64p@2poS2UlWkZ=!di.T+#)TdWQr7Bm`;$@M1if7;[*BI?@+j +%4ZA;Nn+?^oe/9^TldE(rEfK[/Vma7g.2js--fD(hq=t@&]7Lr^FHe!bZ>]ut4q7=:DHpZ);Rsf+28i;qZM&NHmPnf0$8F[K1'@Ls:qP6l(>Go_&?VqIC:@BHeEuO:#6U7u^LM1hfI@q[<\YU+6u"i`n[Cr`*]I"Ac,qM;(g4p3&s">H +%9n-NQV+L&R-nLOEYa]!i^8tS4:!'>EsJ(p%lGU'b^QkuE12_IB:u$$L9eF&.gk16ODNC8Fn2]&^NX2=48`'en";X%E3H81:\_qY!c',?';*ES)ufgMQI47. +%JPol\Aeela(UGQoUTYSc+$-$R.;M0rR_2D1[M(-*TYBh"EI%$h6VU8'gt +%q#hpa2JlRE:CFd5]9-jKL.WbLaX'k@;5k&1eJ*6MN!Y^sT>4p[I,-3lQL3W565oG%"e3mt!>/%V:[2-AWe6;cRSno?iiK>+0GbhIL@/(g\ +%NB'6FVAsRb%NmU)6&c-X:5E)%!1.b/S1_Xf`X]d>'$J-LM:CP\PTO7_Q]a_'!t8il@T402&PtbJ\.p/Ap/?kN49j*ZSrj#>KTVPl +%)umk)^/_Aa;h.BWLO`2mJ[)K^e28<9+/o5;%p0O96h$GFIbJ1 +%%$V%:5asocJ^/TpX6-V4anQBmdmGMk#:=<=(O?m5[Yo*Sg1F9&U'q]+kECdCN'"p6]5]pbDX3$u0Yf!SA;Tl[g>W)P/6 +%Zl94J88Q-Oa3c=_KJZ\o^`;[bChiWL3r&RbY"K3q?-< +%GZ>_%_Dru02d3`ufm7\JC,i54pAndZ0V8uim0AO5qPIEk%?$uOnEqZ +%#9G9FB/YH30j4`qe>o[b1Od\%4<\2ZIX?TX=WJFB)D_^P0Q-'/q'3]MH-L[+4/WLF%14GO3Sm/.E4VL5o0%BQ2hlZp!H]K0bc"-6 +%#>YFd4X$PZl92HL[Ms?C$*52>Lap,jX4:#\`n';aatR1ff;^CP%-&TXM[aQg#AQ[[B_HVto=d6iRpo)=SH.nm_dJfdG["$J1%W-6 +%/-p;+]T@AgH]pl1!h%g@gAo&l((p!hFH"Ni[m=3T<+`A!IG'X-hSA?GUa8rC@%tD3Z3.W(QfZB<[(25#q=<4$lJZ\Li +%R8O$Z+SC]qB,'^_2lsF$"ZWN4J9DnfTk,U>5_E[O_F3m\0SquhYPSe&N'6_`B(U$P:Q*)k)[XKS +%a?[JFCp$d6tM/M]L*khV*sGf94n!.NBq=#^mHqRALfg\p[)E.rMO +%!e=WN-n%AK>;TC"d7_c=uWZV]sd?%aKUUCHtqur6oD<0e+e^HJLCr:)(6:'jeLI;7c8C$@k2)K.0>$AUc&!<989b2o1<_2 +%Pe]7\^ED`]N<3)=&#M^jUg-<(1a?u][Ond;E(.I_@;aJgWJJZ*itCQs'fd.T#HS;<("0@)F9`?Z1k<\f#LjX+bW!(GoPt(Tc`HTG +%Jo99kBsNC]g)8_D7/=&NBN;]uQg;sJDlSA>C$5s)`&U*82)_Pmg5`DV_fa-o-h%>EnS&?18qDE6mr)Z'BBZ'MeE9[2f&;%&-CohR +%-BiOQiaca@Ye]J,@VR/pb.SW)%h3Nk`sY`rA`&',#F2b4Z)fDRG2HaGAo+2JGm-*W6M)2\H,lrt:jCKC4@<$aLEN%AhuSYgd5lc7CcLcg-A7em$:`-+ZQ;Q\mXL_un';P!Ot5[sJrEEY@9p^I>mWo_/u +%!ml>"WB,I%Aid)[N!(YFN1@I;%.HkaR7;DD@9JQ\6,KhKB=]c,( +%NE8fac[VoDKmGO\JET]e#+,Zt$GXO)@(8*Rc@i0'CBdM/:^NA;GDIS#U+:_3`^!1b/gK#rhWUDaOAMQ,kEN2Xe(-c9h.EJ/%91I5 +%']:b(pk"H/dR*#ccj?r#BD+%1*RX;KY_04a+CaKTGePKm_c +%'H=>SN8Y`qm,('8noTjI5k!5C/qAX,_8,aS$8CtHK2,ui?sdb_5`g17",JPqDoU?'C#qKC'#2EK&>-U0#NmT@G]mV;ip9r@ql*H\ +%;aXfO`P3PWH,KtIE>ZElo%OSgQ#.3pcs4\D1mG#iO%"&Q=LSVZ4YNk2$SuCJOYuo-D@o^)l]+Z7l6b+p+;+U`SNu+1Etf0,eL[e:f9;k!U=hX<%uq`"e'@aVAWtmO2rg<6i$UGaIO(7R5J`g(2@G&WXB+0lc..G +%jlF_>Y<2ihD9U3HA+_=gKf_U;D&FgHITP%mM-R=CJ$(&D;Ig@KF8F_n[RBsBbVW,V#QIb6FmHe!FQ[c$S4%HW:jF4c!sGFLdD5?4ULP7q&WSK\1q4fRl$6;8hfenE_Q` +%G*GjNOBaliZQ4bT*_"rr!c]S:\[1SV=eP12AbRU"GEg01M!7&.mlcL!*T[,>V#QH1JO`#B#P#Wo:>o'sn3R!A.$St><.'d7I$/5, +%ME2d^+E8ih%q;b5iRj@2 +%lrf;@-sV+b\:'IV4\FlY7_qSHY2)1k*?j5+un%0C$%%-@TEBI*d7OH5npg +%&,_Q6U<.tIo"\OVi45?q0dlD5O_&UpiuGTk8"S%h&bNj[3YRJ_N2-^PdZNd9j?u0#ViG#_,:i)2_0$rK*Ece]%'gQ"m)VeG@'Deu +%h2].X'8Q"s[lZD;*a!e;_V^InprFXA0Fj_bM'jA)RIYU`7NQi>OdU@;-,E.V.eL5$/rV/)k`Ib!1UZk+JU1k-*dOlK*7uKCp;!bX +%@,[[_]16K%!t4mT1&T$CIc)A6E0a;\js(91aHo(GWukHr%ufm#\,/Pq5;L5SeFEh[qN8%3jL.;Bi/aE(1V*M'_gg\4+5-T?-%N=: +%^enIs6&XYe\)`NPP&'?RR'q(iRb`ag,6,Vi`G4VYkF&^OIkj:KJo,M:g%XL@#g->l`TqgVoK0%CWalo[KoUq7U71VP` +%nt9TR4Gi@Q#%h@*pl8@Zq>e'[)td4`W!IH@Y`fc6D"1rI,d.70\SOPb6ePb/]+1>04DI8IkXce[ViE6,#f4\;?)h-AEhW.P'nm03)61=A9)tU/*Gu39YWcK5(4Ls+jig)d +%@;+iue#/k?(B5baSf,u<*O327at"dDe''cceOOZ-bkY.?6-/N/'fEQ6?ac\*3;+u%>;]S_h:.82=(G4$7]%KU./B:B\_Y!JWRtF- +%.U\l@;@_Y#l>NoRUsXgrr;e8-24,5M:;^F4::=,5]ErU`MPk7jaN&WS[:fqE[\-7L^l3r"TIDTMS$k-B@&e2N)T$*eG>od#8t;st +%W"s5:XAud[#f0fjb0F4H<&`sUHgRTQ\-!bG%95P0RFqqp!]NlO]68@43Wua.)3kojTG156A25iC8Sdoq:h91Jj\+jZ0piL5?H1hl +%WrSkHLE$]Tig7uoR+:)s3878SSViFS;F]UL9NCSgX-'[g+',?I#Bhs8HV>_QIoRZ^$Bh']2`WM@Ir7]#O:V3.^KiZ1aI)Tq`MnO899:K`Cu +%QKRqTHHth6Q[Dqef.]!=Qn(qmS0RiVD2t"8q"SP_)IIus]V"=9VheuoS!l]j_CLFo;!7.''"DC:`.;IhoRe-HQSI)X6+Io8ABPGm +%.<#$fq?kSNP9-4E7,"nUEWHpQI8t>k]DF,CdattHM-:XLoZNWQigedp`C7/t('mD4E\W91TYpC:M;oaJ]No,'Hkuc&B')Zo"D45d +%8H9G\2DuA^.IDDLRkE*bcTPRCpW%I(Si]FDTe^tp4FO8)juSa)pB.$lgJWA`EnT`[n$/:-^:9"RH8/_bpM9ol?mNh%Z2]_3%E)>u +%(!tL3`CU[_n%C'bpNl58`FbFIBaP4APm&4H8b`s#-R`-ZmOA4F%1a5EOaq-6'8l=nI&-L>\UtWE,>::*II*%L*]7S,P +%#ROA5ajI(I,cPisQ)tqsnJ(g$q3p9m-%W3g9Xof*e0Gn5#MB*XU"n:qOBmAcM2EAg$Y@pj)mEBB#c*0cVFV])9t:9\.l?,hX_$=Z +%[19&3V6Yn>NuULY_usD8_J/HNnYj;=b9!+ +%/]DC8.Lt1?'MH!tRb'fF)&TOBlWUD`X_%k?CR7Y#F/mSp5!g==I3jm+JbNYUr>G7^"#Ob)p&Jf3b'P%CT]>qC]j,fW)*@oVba,VY +%LsPYJE(\@I9fM^'N?;W(^-3l/776\pmcUi9YT76h)NaEighm&G[#\*"b +%(Vf"C]0t>""&bAcE*.hHTL,q_XeX`'TXgJo

bT6=p=9(^$%Lnd\@Z9i<\6P'MaP!q)?k1c':T<:Y5(lW2'K4mH9(&2q(uV7Qm< +%5l-pHTHW/A#&&R!ksU7&:\?'U!&gnP)>nd*^J[%sO;d3tY7I'JG683K8>dPl!2JYDXh]e6$EN/g()Ll9EHcdmihFiZO'pO,VP&*LVD;c'Eq]%';R$Z[^;G#ZpI7B,%'I`T@YQ/ZTq +%d%rQ!;o@ER@P!'3(ccc0b_9UpMOA!&Vp'SL,%MJATnYqdMR6ILnf8M9O8"q-1;Ja:EPps,.l.R'D0SqI-k-PTk@'J7%O:!@'3>OF +%QR>H^8[R2IbXgs]6EU;Xj^]/E%N7STi[?ArDQs7,@GoXnEgopEZ:%k?:;P-`huP&7`heO\IS)8,[&Crfp8n/2M%Ln@.P!`r\Ps(! +%P5K2,D8\sP].,I5&hKM63JSB2k[maPrk/QGBapP#V9^$b.\T"n<=q%:K"fg,aGif:m@Z/QX=iO"mf\X&uooMl3Ohg-);%<<^YTh';Ugf.qF(_ +%,'QIB!f&cu:%XP6FXIGd'.nZ-e;=\m9I,O+V)rN8ZX_eqJ@.fLflT)!=3_/0_>QN!H7hjAdgm3YH7Y=_)pKU9!3`mXrg7?Z^H+V@ +%XiX$"L^4EN&I%)r?`;o@)V^FXWZZbV* +%BD%qmST8D6,E:ilh@=ar1G-Ze/CNN&jIc]5H#SEFcfH6[$j1f7KgP_nkTQg1,b]#YpIt]R^-*[P&8\b_]3g- +%4fnbiRqYq]R0A)aIiWTAa/mu^#4@ST46H2WF+D;YiBq5IR"`32]Hb$;Tj0mN2Z`feK[[:jXBK'p3.<>S6n"G?kh2upU:Q+E.HFaf +%-f4"p^f#uDR8LB$9Bs&OX[psLCTCD1M^:G/!WL6n`L>j&BBe\p>_3Andk]f?gC(Ds(n#.qUBHAp16BOmjYH]]DL?5Q>o#J->7VCQDi*eooGgbN#)6ZJ5#YW(`fPL'1c_nY +%eG4f\b(DTD6p"QYO!do?$02to*)<#t1dPP),I(9u/]uq\Mqi.;0%='Gc+-G_Prjk)F9B(&`PIg,$8#U7]N]Q4 +%O-#[uYeGF<6lhR9&_0mcJ&,nHk14F#KRS:">`o9G`ueP(<&Cr`F@fp[&3=/ecgqON43)e@h<56b]_X>tIpM7J>SNZU?\)"piRcla +%QA[Odl_/KgpXG@;l+7.>cR/atIPY$(p'rdMlRau1F3A$-m0^,2oEjnAb;A4[ocbj2FRqdE@$$TI?']il$^;*.bW%RId)g&n$^u!; +%[7f,70Pa/;"T3.g)KX;3cWo,$"sf(P1q\3_KT[ie/Nq1t6nhXnYr24:\QeTnT"EeZ<@IDPCSpgP=Yh984>nZI(RPNB1c)2)GtAk$ +%N5Qa*lm\0G.n-%/P@p&X%QrcQLpWn&C!rDT2>uiU]J.&W/L,3;YrRE[tm3D\W6-"P1!KpE*C^ub-1o(YnW+lp!T28AuJ5q`P?oY?nRTn32 +%Q`rJDelaQ11&TOcEjn-73<_H`30k-5@/ts?9,NQRCC+7F@<95jpE.Sqk0Tak +%T*jRP1o9\W6Yr32ZPb%r&HPD*77d*.AKZ?^aUW27gef9Q*2/"L+r,R4f*LF"'E+!ALC]=*j3-Ha4"eLE(@=%5 +%g'MaQqfAa^Z#^3+,D+cXT=rU2pFNHO+S`&ScinMi>+^gbH-Q`oD=Ua7^G^oAV?>FuH2?Q[&h +%-d]^T^-V\X(>5f0:!Kb#`ak00IYW1ITmi4n8DIV56k.he''_KOWUBWlS0/G_!!PV5@U32`"#7RBo"41iRO1B2AJk9`d`!&]gs[2oNkM+W_.)QK8?N?))WtCiQq+]6)*/,pJ6F1M'3L.9=5jOQ)TV-@"QpW +%mW'<#8M7i5jJ7tV13;GMYkjVYs03niX<.;e2#5n*oC:qiWB.UtLX#JC2W!I0rHUL)_#X]=93]0;.A^a]o=/ta&>8J))TR6S,8>o@ +%eKbub)(?9X<7sKZE#oPCo5X^(i-q0WGGk@kjoqDDD5#?kWA2J7e4g9j[]L%2/X'lP!(-^o416:iG"+1>Z/'uAKSg*B#3Z-]GkNCB +%!t?`BG2J:@I4MV*n7g)E%^%.^!LR_BLk0?NU\ba,4N&A_B]UhOH(Sg2:2'>`a,P`K](riMCbfM\YuO/SpiL?Ng(ANk$r7,kc5:(X +%_e\mD1$=LQqi:$mTFQ>JV?\Vlo*PA;,L]^?JC3ganAgd2hTrDPI*DaR#ADfP,n;'#NJgLhE>X/0MV.==SYaH(h&D1^ojBgi3 +%V$_4Q>_Eq[tQG2#k7$"M^?+Q +%"YV[,Y&&cKXM;M&O^AHLZYBcB3auAED)J!5F\,tgG_3A[PX_@Yg0u]\b=$92GQltU\Vt=j!LIn&Hu3k5\U`D`3[@>FbY=^gaH@DWdh/:1?JMqK+Q"2#grR4EKY)$oi:%)ardqM;^H +%i3ON1gkVQf+oHWoeW*2[Xu6^&&IV3)^9f'CW-i:\+$ch3@J0qI?6*l3d!1>1&Zq&T.WP-C%%t\4OSdIDjFVQ'!g#C*sY?`RA3J:L] +%".4Lb#,@_tCHnNI3\%*;\b4Fi83*IX?[)rUj0AE7DJ%An&\G(]"3+M9Sp>nZWGn":oh\'._oKJ=%jp9M3o]g'Bu3EIX!2/m_&BU4!H"6&=p'p<6<6Q-3Q?;&R@\Ph30PO?`6 +%%ln?YB]a7i1"9^BZ+$96J9c4s7ITe/.!4LWA%t7FiAlZCOsf:U@5WYUu-mYsmVAoV!rI-PtD_/J@Vj +%bp\)7s'tM'Qg6]8F3uA^45c1#S/d1LHhWKar35EFQ!O$Y,0/H;?+X&I#['\(5QOI"b1#f#QZ(*)[<`IP-&IiHWcO?*$r6H[H]Q?/ +%^7i3'dK!ECi"LYTLh\sh+02!mRVY&b6"J0r-Y']WKN.8:R)c$Q>]'f]P7T3t;AZX9;9Lc"R^&>K6o.1VE-YEH/V1KIXor+4&\'EA +%WhC%gD/uHU-8_V'Xbb4-7DMKrYtIEslQoeKA[*0'\a"a.[@/Q'-e"'U]a[r1<";+J<3!tPp/GG.bjl'JG+C/d\r+ILb,"Z5k*NCn +%<9RnGMU9k'2Wm[Oq[3@j;Ml5h9qbU]m4HHpOVjn8C4#P[7:F885``rg@BCkp]f4RNm=$@&Y71LCc@XC`fW8IKSh"d/$>Q\Z8rca) +%oP,,qF0ZUOlDgkmSg8ga\aH,E-)BcIICE3*HVZa[b3>N6ll^,`@gdo4V:\A;K-ariD!&C'Cp#J4Wp"3.:olD\1SiIG +%.SC>+?K,MNe)%8,\HE*OE6H$T_UU4aGZ?`<:sDrF<`0$e[e82*CI?dUSZSl\X#uSj:/k;u2L0Qoa,X_2 +%A^2hAO0WjaZ[`oe!;KQYqc+"Rj.n[aN(GKS&1Fi`)oT6gRK7l=\dE@`;2gi%rDJh&WEH&?.Gh*+Ca$#uW(_gK^ls[0@'>.bd:bQ$ +%$3VkJ:e#3VeM+J6cn`'\FfoBoW.Ueh]WkML=t36+-&l?&k$3ZA*_F6/'YBctQ"_kbYeQ;jYiT03l'4lID7(fBbBH682bpMV*:"[. +%Q$YO2`t"6=X/Oc&;+IK!'THX<<^+I#72`QS_>h:ejn$"f!TLZLN)3&cf"20'(Vkf?#u7\`QP-QATH6r$OI_jYcte'ukZksmcBW4! +%/":^jCZ#O)0>'+4G&Is^mbg7;pQ^Wd2b#FjU5nu*]8@R?9)LplZ;O@ZAX$U_AI9K^=HI?p*b9q^(QF)?5=-D.hr(mp@,!'l/LeCIkk@6H_5/n6.4:g*[(D;2D@$NK'pZ"r(Z"A7mF2BL<-7'tUdR2;=52D3aU-9Fa"WO^"NL)q*1EM?.n#4]9#VD>ieXLP8EdQUr\u6^*)]B=fI'0WPs\0e(&#fo;N(2%Bk/,!WFG4<=kt:7DF+%ZHV(1VI/dbHQg70`:\HsOrNeB:+MDc]Dl^\9BJ6T_I@]oZAXK5[Z(sLct.*/38R=(ih[4Et2 +%/@QgO_iSNQX#&<&mcI#cV;D@d;mfGLi;3BMVMu>(foH^mQfYJ.?*E\=tcpL*YB;[L*Ygo4jSP85"tPg<+F^ +%pU7a?9hE=bP&8NMCr,`kn[+(SkN:B6KG;bP%C6drZ9@q#gP1\ +%mT#O4V?p+VE67l$L#4Q_*otOOP,kqjAWujlE/.tO:.:(7893Wt:9[InJ"s8L1XJb##rI6%HVUNX]O'"2FtCO]@'O7s!"Hc[L3`u5 +%pSuh:Mb8g;>X:0J0kJ-]6ke675QbsZ7(^M'k>h1?NIs-%'WU%2)\Ahn,#[*>[lX!#-'ihlngFl,DBo0%e>:g5I7BJ'%"i9&gotG<(kRcTu)GRnp1$q3q;=KR?j%&oJ^6p>5clC1^`0?*\sJMc(VkROuJDV7`ldON\^`%"hlM.CJ$T[M(#Y1b)(t +%H!UTIDiBklFA2A+FU(U"#_Bte>]`Nn679\u9u>EV&icP?81;Ni(u1_Y/Q$5i9Qi3OO@51L:A+g_.FC^4"KHNE`)qC0``1$H%ishXrIq8RgfR9 +%^rmmdhLc)^cIK9OZ)q-a$ar[^C_:@2.-BX?iB+[(B&6SN06c]>YfJirj/\)>"2Q/i.KYZ@D@84&j+h$II]4K:&qPhdRqfb#%r`sV +%gu$IMjA=e'/*Q_LT8H;s@.`bck*L?=^slFB_2>?Gcj-:A&Z^tV/g)rP_'2hJ_XXR9UOAOEZhiE1biL?-JF`24"9VCNCZi(\P-GiG_jSWCl!h/WmhL-:An +%,k#'Hpd;Bp[MD/R_4*bkJS8#lFY;Xiki&7nRhD8E1l29/VcC-?77A.DF"<.*MNTqq-O6[7Gg^qg(_F3<]T>,I#c08qF0%-<%9^>u +%Hs\DZ@+EW^#b01LNg$1oQmh*=*7$iTO8TSd!\9'.p"qI`*FN&S2hs(!d3($`PX44439,8knP]q*?6(5s,h0%M`t5'-ELohnTb_>EHb*UL/aHR3AG>%tF1G\(q$e#07G&MRThHglLf7::_MR*(Q@*ADr^.TE*%!XZG#A%3lleC'6?_706QD>ccD,gRMF: +%VJoVW')oNLTi$]O5LCMtL%jYrpq[mY',Tj80C__,bLROP0<9P,b[9;Ia!\`=FNL'7#+13&->cbI"]Ae:SO+k%nUp?f(SGA\-,bAa +%d7Q5hZg(Pt(,#onN?CD6Wh69?bkm:']6Q.Ng^-hLjZ679[umMn=&q,G?T]AR1dYFn5:+QAAsM60"JSjn1*T[Aclpf+d(g^(.%<]/ +%5/^+2K^#i6@cTPQ'$&2(M+K"W<-J7hM3lW0%tIT@f]/C/,SPsSQG(]l6T/5VY,`Kr#n0/t,@73'1TO(n:JECL?i_pZ+?8Rh%9IS( +%dB)5?1*ge:%&%7[1Td8R(/QNGFu1&O`pQLD?1Qr,Krn$s[UZY0-GljSq@6'?%/PrjaF'G2rW/he]gT7FSO1SP5Hi)=bc+5;MCF!,X3ah#.R]^n*YXE2u4>9-@-:;LGJjJ>qLK<*/X[::hSg6Bn0G;dW:bmJ6<#=qa +%BL^$Ga\N+^OWB`Q"@]qF'W48QALEiJ^oYD1%a-70`t`Hd2+ +%Yua=?7WI+7;mAtO@9OT)g\atXTF3/Y-Kt.+..J.i''V7Xap^Qn"8L+J<+cBcZO[%>!=Q$fMFRB9'rY#2ZC8mk&=Zo%^/cn"!0eh[ +%22RirJSru;K0]l-1]C-bH8N.A\Q.loC('`Ll<&^t,QWNW+W$#hb%f./)Q,g=ag3mZ!k;c8`>L4'@XZ2R"2*fM0JJS1=@B96aBV=H +%MjU:U0L8348@l2U/`]kHPdBG4DW#YO@'$KG=]5E#Z^27t$:Cf!9:W8"+jF`VjL,fU_1M35Un!aFGE-^u:3a41EWh:3"BSTtB=LTu_!.8.IKF/$dp'#EV*fF*?L_$CR.;4JfnkeH +%7(<>Ua<[hV9Fjp"3f5C^mW3g&'VN,:f'<-qE7WojFS-B.I]WAVb_2Z]0fD3"L<;[jC5'^"c5A4m'uUCf6E=f)BP1,H+N;pSM[W7@ +%N/Eq&'K?u]65e"5?7`8jek;edG*ShV'(?3?LLKLdh9aIT2+1:Sa$&55UsK[PB,'e"/JLt!6QM<9-,r/Rbl +%I,eC*dQg9QnRS%e`&t%F@L^OlX&->MXDS2l[fY,"!;hK^^f@o&XC8D`Ak67]0 +%pW99V:/H\6=?7YmLEkeh8`\!UD\q"2APYqL-W'qa?8QBV$sf5+J)u!b6GbI[WN6s +%mOU)0K'&n\0$H1tX/Q%ScR[r^nIU>dZN18nN3JkRGY&5Mhb2n*,Gn6C^!2ToZZk\EdmQP:iT0L:>EUpF+q(W8'F[IMaeU[H*>lac +%H,#_[o?:(R1QC6i"%bMDJe9lmiT`B),7:FZ,/r"$=&mV*1+D^#e-0!1 +%Y:*hDk!J"?)!\I.!9+CERqVo!o%APlUdjSM19(<*)OR'(M%OJPMdZMc$A^2@2K4@P0ZdN^8Zko8I#bnH33^ML'DEqtAI1hJ]0g&aI1kFY]gdCMMFRkP.:$'tX;P#H&?].2 +%dNifKBqV-C+c2E>Gst[B'hT1k'k?]+F7qQKY9ec+7*?Rsm@9=G,n*GrfE.hXK;^,?mHR[knmj`U#o)Ys+3H6A!Ac`#H[*aK=\Ckr +%EbgjMN,_:t,-=2H0$BE!#0K`l$mgMd4".H)qpS??X\Sk#j1MPaCScpak/UiuQcrBrJUQ.?W&-jcRBg#(fjnfW<%H3Qs6?\!X\m:- +%%7*:9$6K""ds;qkr=1je\c09/nu5h+<+SKo.EAA(X[G`-$Jsk*TbjhO1)#+3b\I@L"(eXs!7>k[o[#CA'PcmlNY>Y\$2ME'L!fOT +%2H'`Z@E*YsMXepWML\6uJD2D:E/I=l]oqLsipVN%GBKcL$QtNOWtMDc=3UDs6kM@&.#Sh5GbsDR'2%NN6P9i#hFGNsKs^?+3(%M8 +%]MJfO>)@[O6Z(eDZNtV,?]1Cc.S@rB@ETsth'Xb9h#D%aoR'fJcbnX?9r0Zb[.'&:f$a/MP" +%-"[d0Vq*D0h]*>skSHFt6MJ6BMts)e#m)5qUPNYoF[uT;P(Xo.W1(hU^B" +%GkU9hm`AP$((E4_IENp`>Jsob^VPjSsYS"t` +%4Agd=1>G-`[F,@i0I!Pt9HLgI*/[MSfsELW47Rq@p'^X]k2o+^5Vk.*m'Wo=7k-ef8aJAG[a?Ap>@TR4=LVH8P%h&"]'^!A@JZH# +%Z19iN[-0deB-mr^AHil/!'NfA?lA*464^A-HB[lHYEf).<='b5'Ak<'/q7dNHTn0EDUS_l!`D^uV)TnX1Y%mmK[ZWbZ!=?@a4>Eb +%-SDH5-I.Vm&70$kEgJ9BSuJ1;?0]aY;.4G=I30CT+>fS258!Q!7h[i([21+Fe;bm["e=)jq^_G9]LY-#]4/2eFKOBKC2G[9Yq +%E5=D1j/Jca'I9Hi(0^m9CLQs:2NDN.%Pgr1)ur\i#:T)_e^pYA(hqTqJZj4=E)Be1o0&OZBjcXXHU-H$6M*Dd"Wu0JY>C4^d#nnG +%bfZpob8.%uUMub6[I"*-eWt&QAaA)-)C425l4t +%=%#@cpU,!hE.*@jV7!T:ZhLDMUP5gl4.^M2[=jOd"=5>1H#QfKMK,&9 +%$qNj%e/082/pjF.=LO[;+a1!t..E>%;DCEcS[-,8"thm]K:Y)g8;[INpcl(&tBK7YZ;OH=sUaD:'HQ,7\6;^"nhA&asKir[l +%_E=W0?D2Nh9Q8?jiNp[]GG\[q0V3oTfZag:`uCr[#-"9*&\jYBZdfQm)Yc$.d:V3LnhfX((\=iq\uo`J?-d2'DeVmrVo9Tg-$r>E +%c8NBA?h051huUoDKLT8O0(1dSQQ)W$l3P<-E/.2S]gZBd/2aHJ]ACFG"u,c9Yo=\1iF*eOR#(Q,P:9R%GD"5j"c;E-2P1/&/9cS,e3_iW[HJ>pOCl)AjF(q?7go'(tX)&E3'_a[X1T +%Um2Xk@CjoA0kr"kC*hhRR$om+iu4eBXX/a^'?Pu#B>aAKPuKXF0ek\g-n3)--U44pIR:#JlgPD'$f +%Y@^cSWpthi3&45XQ9sbN?Pd7N_;.4FOXmN-Q<7[m="^_?Br)J<'j%\9f^MG>[]0kfe:?nV!Rq)15>b/C',nRdfnrh'&I^b+i:jebibGVSP\niZ+)9Ms>mn6X8sq/gl4,6c*aQ +%/Hg-j2]'A!"#B%*Etb[ac2RK.PI-YmHDTV0%d>\%FI8IWb[Ol"GMUT(*Tk_/ZY`c!F,)cg_d)*,]\lWsnM&^B,r9g2KmB'M]TO"h +%gkbdVAD/RG*9!3\r$F;4VhH9b;^KJ5Acn?Hq["\jlJs(;0Fkk."lk$)Af_pa"fY?tMBXA]T%&/I?AW`ek[X^[:H7:/c5^#Q[sHK.oGOWI&UGGaT?.,6seW@W_CQC85F$+ +%TU:o*H,0uhC2E6`>,bU\36`Kg-"''qBVhnX#;gk;4Z0%Scub$CLZjWa5aII.kTdV6#h^7&,qbgA50sZ$,dk3Y8)Sc/?j,O46N5Tb +%"'/;+#"]%M#n"R\L1/fR+@Tb3Xtp/]_6uh\8e_EEGHdgKQ66Jk1;V)=jdef!/#81-qSs>Na<@\HOFV?dK0R]Yp9]Z<2@6:<<9I%8$Et^.nh_["d)Fj#65(2 +%E)pKsnEeUI-0XSSHg$Q(F9Q>@!+h5ddO<`$`CVcCUbHQYf0tc'dFF4O`C3[* +%0rru=@gD\HIn1t[c(CHcY>,t>3SW/EE0^^^,3^j3K8H)rk71`CY1]#I`8e?6*,cfY&DrS=(:]X,ITSNHOE;,B2E0Q\.td]l%fA0M +%LD:YYT=ka"WK=mhi`8of;uAo;UNYFoJMPAQkl[4?qck)-PVpr`=&'W+$aP"qr1\X8:A3\6QQAQ)(:,qd4E").\j3[N"?%<)!^h,+ +%"OnuNW[J'iCc_2mc5R[(Ji^9r&B==\[YBRK`$"FS@LUTa"XeXm^,.AJiOk06!U1*t109g3iP@Z.6dd'F@/rEXaQghNW%8(IC/P!C +%r<=p8P<:Moo48\YWucNZC8ZJHM^Y^3TWmSJI5^hILd3[16'eadTt%mS]S!5"o(n-Q(qiu;,$Y5MXa2\&&;7nr#[4Hl/Jnh5N[Gk> +%.:Y&P7&u&p1"\BeSS8/(:+LlKk)(9(*[68q@^0HW5P'J)/`d?4O5b=1,#nGZfA!!0T8B+ +%itrXo6rB!7Q7LV3+c^W"p`+oR=)as&`9@UiFb"!C@U<.*YsU)0&9YUBclJj+#IrY+N:71GG_eI'Tp1=gjtZRT"XcIO<"IC..nK%N +%Wd=pL]n-t@ilVK3oG+b0&D97c^^guVVlSaV!D7,2dDbWT,j?ba2Ec-qE1#SA?HLS5VK33p^/bocp63UQBkJq6C;XSj@G9I.MVKnV +%DO>[XP,($1kSpDuXeZ9+U_N6n*j-b;NY37cWK1h/P/EO,EUMp\Rc]&gk:lRM,u&KK;EDr`>tIs8A[DqG?WYZdLFKXKjP,qfh-j4M +%+T6L1A]8B;gpNMKpMS!K0JsNfgFB^sNRNAskId<)mJ'0hF_&Eu7T&JbH +%)\6;a)hq(tW]LV89^(:^-K-49hT(8c&3p=E&ff'sVsk8rD*,a/X(*fq'!PSW%b3"unr#+1X6XRs1T(tD:ep/)S>itVuk>'5jVL.K-''$66'>kbsA6DS"ZLqWB3dQGA?7FH`Kq;6I]dEZ6c?:`TH!VNjItb9NN +%SAp&I:u:IsP>m+m\/dOAW(HhEJ"o;8Hl++G-JP\t>BL#_aPLY>' +%ikl[0_*-Hs"9'U2U#"mH)R;E+'0oPCOs/ILN@G*0"k7tIJ[I+S$^J?::YKrfib#`M;0hSuOU3hn#K17G\mh70`6k6u=7H_j*).4u +%U`$@PnaLh+^<-Of4BXf;r,`ik*@PC_.)+c\pUr#YWT;?&KmPb&l.lMg2i,".lt6C^:Ej[VEXg6;dKPo;+BD!Y1.3VdKe[TRXD +%c?0A*^'9EOZpNM6:J/WR]?6O!jOY;*E=H$^p9"5*FRgrAILK-#LIpbq7RHuY2tr^NY#P>UR1G%E%N?F3@+a/kYQj/!UVb8;4<5j* +%4QQ,OY^``"3EK,]._JjTpI`G#=+jbZ"/:m$RO3Y,@AG;I;Cn,?)Iu9,^h9W6>,XGc[9;(Ci2U=g\\UhbZp+27";hPNSnkI@e$p%? +%TOcPEH)[',<5YG1.g<)1\Yc-te7&>k[:I#Z$LPj`8F-Z2r2Rt\(qisC>U0lU<-8coAeBW`]P-7+P$qOOUisr='B$Yl+CjCkk&5[U)K).eAl.JlV:i/-n@WE6[#l_OE-=p%XS:55T4WiNB.Ktq,]BJA`_!+Tl +%T2d4r3IY*J:jBUGr!h9SNo5\k(@4_XCnp=Y&b)!JP`VS]&.TGB<-j/-+T[cnLYnNi#_Ft +%6ffPfaU&hs"UR%k6Tkuo-Qfhug'C_8cp//T'uNsl&r?^qB`haKT[Oo91!FflRfHG5Oo\[je^I97A7gPU@Z:k-8=VCYfbb?BXAF," +%=?_Im+=kqb6^j,P8s04#aXZ>fLn%npiipJuE"=nNhR3H1_JkDB2WMs"?.n;Vj"NSV`@dc.DPk%Ze_o=H2stXK&!"Qck_rUjG&I++ +%*N,bL-S&Rjf82tia?cN8]eu73&Z*@+HsrSE@8QQ9=<2IZP30"6k-.&4?7jLdlEP/eChM=la[RoTB6gHtnJ_TE.N6'1UN%XgCGpc@i41/@&`\>bD=jF\8ihK$fGgieUDgN\Xb_3/;h4KGZ3:Am +%a-iAek/_kb(!BB_'t^G_:hIVW$M$oEW!uUcj$JY*7iW?;Zh4D7V]^,>UHAnAbXS6b3qr)lQhJ%=p"AX"L(ggQBh=+H80,JQ^l0Oeu3*VBcqc:n,[Lg4 +%driO%20,H($dtCrBt-A34)'shA4T3G,VE4C3Do+%Zf;sa#Z>'CAW(MX'Xbn>2[p3Q"6h2D`@F$jEL3]:<@=ORV:;f=V.HYt['5G< +%<#60n1aqkeH")"3NB(QNfOoq422"W.RVBpn',E%_?=E_*Yra.'E%+]9[,rFVodIQs%>*;-A#:O,3@l'\9;+u;p(2:I7L.kQfTc%n +%A@$=dnCa=""@\7cC''KO+4lAbX;:GA>'Z4*-ja$-Cr3$j&G9^/7S0LkC8Rj0)dW'P/$NDF6Y*W-nHl'f6O-_=^ce>.n+?28UJIZt +%$0jq`9@_0(\al=%?J`AbCmT9o=+/de2cmS/#=Lm'b+TPrU,=Eq+mIA]6.5`U)'5^+P;bIsUXQl%n;!@Kn2f77HJ\VY&Dg,h;re9/ +%K[l?F;%L"-Qn*OK4`j`?\OQ#adkt5,-ml1@Oh/T13b2N%AS<*i\INml7i\d$51q[^lj?Cf?\AO7=X6=PZcu)%,37LcEW)?7kWt6u +%=$!7$R^8&OK:=T-daD4rQpGij;A;-J\F;e%?Y".p&a\Lk,e'++\m4'A2gn_fBM`TauU=/8LPWbdIfnFPb9o*s%SiFr2'-J +%BLti%:Cdm`ArmbP8]AmWEQUBoHC7S3`h,M-Ci-&?='hB/TJGVs4roimS?DFl%#J;FUbLgi]#0-33tt:B"!b7N+YD.aKp2H58gWJ* +%c/N/[@qQ@p8H:]TGg&k&Z_B/N!K.[O5cELn,WHJk-gE[H9Ok73_6kK7UO(A+_UC#(W^l``LP;r+MIc>9k6ZT+53$s:PVIlHWk4o$ +%Q]i^qVh.-O`p`/f15?iAo`NRiXL(gJ[Z'sL*A9Cf_-:N"[0E.4bH$?@2h8/00FgMi-j&0=77KqSB(kHP[q``5k?NQ=U)Y:"SdBs* +%;T/<01NI,^>VQmu"IUkk8('XZ[GEld.n=?3.UC\\`0RIuV%Y2VkB`,&Fri)<+Lq$AYJ@M8>,7bH3W,-'+]`3O!lpEiHq:43Q.uIK +%:PK\]4WNX;qX7JsMfR"oT+*&e?ncS$,Bn"O/)Lh@]r(r1/e@&-Y#Gsr5p.ot)BbqtNKLI.NLm +%h]ui6ZBZhN1W.`PR#Ob9V"@mBE+=pT>"R7E,_!6@WEh)Hk-CcgM%2Uu*e_]1=b$`&#[OBAO97TKWN6(+P"Ljg2))"D>JM4,q1Tke +%BVG#9PSupl#F6:PTEnssgP!LJjV+I3BWi%(M&8pUciLHI&`oOI);*2m=;g4o.74k)SLcIckIQOeYVcG^"dH]#7`>Q-cP_FW;W:Pf +%J1+ad+&eiu"TJ[/f<2:9<;44MHQYl\c`L.Y*Rl%a9m^NbIP!p9QqP1l8S(_@AYhT68hHB`=#Ko=jIEL%j`\NTe^>[]ZBY>d/Z?JW=L9@S&#_D*%HTK#pE)f)IaG51+3o(?ce1J,u`t,rXEKgc6@ttc`mofm&]9g +%,h*69G#0HGc2d-2,`S<5LslD\$8`C_:AYh#nu.AsKAj,RU1,Y7a+!e]Ac%:L($OhbPg$Ambcj'dEJBTc=l&ks>7]/'qTdA)S6#Ee2hl$5k?"g%NF45W%L10n"4T4Zh4+T0Al@$rpoWdZM`X`i+Kh$fCn;j +%?bcO3mG$7Mr:0-uRu?$:&cVXdYF!jb`'=:rlg(mXMjGeB4]1`6oL=>\s5u&mobi,"Zf[T;pg;,-RgR$jEY.5L$cis&VS7k8e5[sLOIHQFgQ^m=89hiX%s.];KMa7_(qWshp\u."s'K\(EeD?TIYsZ/- +%#mS+?Z'/E/qF+t$?]1a,7QB1fATBjflJKReH"@:*LQ>@RV<<@Y$e1\qKZ/Fp7g7\.@h^*.tZ.2JVUhDms=o2rEAgHd[ +%0\Q].C]^S6$cZ5nRBZTs;o2pG2BWns8)'82QicqeKo4.5\WpP8L"iW-gk.&r>0oVSFE3`o&o5lZRWO"l:(JpQ7$!URQ+h?8a&^$. +%_W$ff+-S$ld<;Rl:::EDa$C6->LuL?'4r(aT.T*3VsgO5[-8d1*L?=Ok@&n',4Bu\:hL-eeC'Q.?I(tcK@oW4-4J=_^%YIo?*\/0?pEJAY#`]#-iglR4f\OZnjOUZ?qW`fEn)Ok4j]1BZmA#O,[XfZ22%43nO:?uHhDB5*N0hj8,F++m +%jj&&bX03CWF>sAIW@9E$e2n9NIhoLsE@YcTS+C/tGn6b%oW+-j\Ai +%E&0(h=i)V@^R(b+Y_cYts5=?5>UiJr7K$R%gX,8>q!]4T-!-dBG&^3#+uhIMKo/7@!O"cjFh?e)d]Sh1;AT,-\%uVD)2Vj[McWB$ +%9S"Qq78%A,*P7)q([%%TJEeS*'K,I9Kqp>9Di:3\BMW:0CBI-1&bt,%`!OJV7LT[P\1*#`KRO4YXl1"["_X-61+%*=6cK`+9!-EIF:KB0MiDg$YAf$ +%kC0st;pSiHF=_^-=$A#c5.fRV=op#de/];m>7PgX#OBCTcUg?g))*rh$0U#I60t=?:c5i`K#8V9:iRuJgd"'Z9m0M82#$_3n"@u[r8/IRpup@C"=+!PelLQ`g1_E +%2T0iF^lrDYUUe.T:sMBb)GFTJO&1GY.Fa'^=LUPJ8arUQRdOE,P=dqoBZ1`#EsNN0?B@K?P7k1DLS<\XUu6pT:[t5/f80>b$Ag00 +%N.*/fXb+beg/i&e1XYEiQ%EcqDCB.pGu`PqgiFkNJ$7r8=LXRaS$ +%DI>Y83-<)XL8RG_>EBE*=qk?L/e@'[>F;Nk(-AWM/L1,?]%'NNC^p"KkV9p[12(WO"K:`$9IFeP8Kb;#2f^LoWkVL`<_F*c=K))- +%(ZHD34i`(TSFDgWV0^X^P+ie[`,(o^L+E&[KZ)I0&Xk9(=;+:EclUX)NH5KRL9Zk%H#;Zkb-p'4LkrFm`'s,WLdkO(TBi2L%B+T5 +%Ket$U_n"%n?< +%m+WYQ$$s3S"IQ&E+>QFG!3L=jHM#KTJ$;@TXj.Fu@kuD]`a@q6:%k8]eJ/gjc&F>&X'&/a"9s*e,nXklM;KAd+(;K/oImdbnXdr. +%74m(L&Sf@673WcIIWN1C%RgPpm"XL>j6]nrf=qX'&?3lTn]@5F0RM:X<#/g9Z`L +%W)6RACfSB@ff;?,eRC=&iTr9,`dli46'Q@``ENF%_G3RP%Ohc7hpm\kg'6&g]rkX,lnGm/D.on^_dJ?JTas3@`<0:[/JiPjWamK7 +%&1@p,No,+Xh8N^;p/`_E:a/]K^(JKB)]gp'4)R!kG[Ya%U^b8-NL<# +%DWWfD3jJFfR0uX%F`9@*q3aedf2K-@W8snlQ5$1To_-_I3]qFE5.*>Z=6u\c\ +%akR/Y0B\7l[Nsd'nK"I!njtfn=Z?R5hGf]]_'OoK*+$HWErTm?RSVkBjg`@*HBkcmPP^nM(`nG[cS59klM2Z6Xq7gAnZmG8P[k`U +%C/B.c.<3-r46B8b,p0DQ%8[/Kiamf17K`VRJuPKc!m_,e(mBhRn]i$YdOH/c`>9eZk#;^U=D1A?7XjUDS$S&9iGO:>/^e??W-%_7 +%1\-?fI57ppllY`4S*;XN)hNaLG>Rfuo[c2$L63dgIYY:[DUNV]fP-Op$%h9KOKb2(D1t,b)LT%V7+_PTE`X7C`0n?%N!7NNV2[\K +%keO9<=9UT1OIBd18Mn6N/*R&i\sUu^:+p+DF(2II'1s-2MdjsXIOf9;$>aCNa)`#gdN?qT;5&hd]`d\f=edma!H2He)f"ngFe$X9 +%JPM=[.)]SS8qj:o3=LjEiR+[21XY:3D'`Ygg4tFj#*5gae.L/YL*(:_bT$b8:O+67#VCJ:!?T52"eFb(Nfg6'YP:bNoJ_@iKA-n(UC+.\T`s#$#U3<;^7T?EodR#F`gc%L*&Keu!C[)rG-M>k`$PWpffnh +%(0qd>^W.6^]/o^cN"r/sW6e1k%l\g0:A*aa,2a,rc\"OZKsno0Du;a7(_lY+gn64O:6REcB![8(n!8V=<'eg\,dMZkdQ,0D.B`;0`QgU%\X9D,gW&#lo%07Wl\:%#))NV8>E<,XR<.39gTB_@"hXkf)^:VJmY0:pqMo-d4o4)Gpi6+_`q<[Y\E("^3CfEh!kclMjk'hPWr! +%0`e]64;;*741)%NEsil5.a"@9T0UUOESs==eH+/'JJ(-8,,4@9+MN0.Q1^g\I7'?8(Db$ML_Hi_1]>"->%_ASXt=0eN:qP&CWN>/$(4@]4O>\j,7V(SO"6,"HOSJ]braK9u"/2QaY?>`,Amh:AW9bP% +%-/pGM1,KXZc^0UsZ+5"Uq"p?W&HY=KTR?*?k=(udp00QhU,,c6"n5W-0Lk+);/'d'7Bj6h)R+TVIQb)iV.0W7-<,3?1is2lMg/[! +%CH8.\?5WHrYeQs"Eja>GBndlC#ce9O:8EF5c":Dn'&euUXrAu+_?5!D4'AB4YQ.XBn6=V+$NjL,I\_UOirK[2b_pu].sB?W[R7Vk +%A.r$iYS[II`DiSdILDT=Ul8mK5j%_^$?[LUk%4ubeN2(L#,og@-,'fr_@H>'g&]2N[A?k=Zfnd%%'"hSAS'VQEu$-cYZD4Z.eb"_ +%=>[?&_^\PP7TR@J(K(dlA.O;p.'Y?$,;!]IAg6\2,W$W-+0-9Z;522d<"(>"Cqk!#%a[t>FA9V3+d0IiTQPf(Ke"IXjeG^B"/;E> +%UXU]"@pQl^E#VUoC6&IKqSR`l&W.sn,o.g6BO-@HgYrUd,Z:>S>?[\u^n7:$HJ.,E.RAWYT.fiW2AJN3(j4 +%%bOTSN1i\hV8MjT!,iPAZ@VgTcbr&/dob/>6WL1^+`8#J'Cs#g_*ZN+=.j-eH),?dZqA]hKOe+0F;)/;,GG_F[gpD*Dke,KSQ,1r +%S+T6m(P[c3P&(a6TW0qbeun.F$cYE9FIcgho'X1hna%l?!6#=n +%D#hVN6j=p,XnCn?D7e9"%YlL9TtiGk$tW2&K2TiWO;AIt!fUe%=0%2Lq[DJaSTaZ2M7D=AA):$AMoiate@K?H-.+J#0X$n=L%Nb" +%]Uf^K?(k5/[Wl^iN-'17pb?)AJ/#mSK-URDf[=fBR_QY +%hb8_K:@o*kBn0lfnEL#\I!Q#0J\5`*8W4s0?k,XPH-J`:#<"hR>+>c0UI9ma!,VOK>_,l%eFk/(F^dR2kS>!7i0/65jQEL8"2GS+\)m^<7uAg<%A+/ROcd,GgXl#,Ege_$Nge:7af +%gNqPgYZ7t>m+!dY>3aUHDDa+C$/HB?!d^,Hl:1+m6ZnRE.Bk`[/JXW%#aX+qME;DTZg^-$hp[:7;p+p#,-7*K#%p0j!"$+mSY`V_ +%T:U846@,qEjCs1TJJaFp>D!2cKW&f_NJs7,YZS*%AS[,a-X-MG0juidTSHJ%.:^,"A="K.8*ik`^=6hL0ML,9(R3AC_0ac/7i!m.gq[P'APjCe9E1[LbP=;BU$\paceJip5Fc!oYd.DV-V"P/*YX!-PEo;fVB("0V1goi_g.&Fdc9>pU??N)"\c1p>?VoH.DH5d +%T*$:>N2W(S%H_o*YPr'[J/i%Jg?6;fVs#4h$P9T)'L\N/)'s/cEZ +%VInt1l1g-K7WIage\=:/)]HD*T3Lm+mMs_P3HS?m;=`bq,KO1PhsPDS?sH@)p*m@sQ>Ci_gBDJSQKU:`Vm=ol-+I#@&]WY*HJ +%Ak1H\rB\95Br6@caFL!`VECk1/?2uq4Y>T:=g&KI[T##Y66P5Dg$qj_'hE-f/6C2\bA0!IC^d+/f,7si`:`@XfFum&k[,#P+Zttd1P_1)l6PUs?^^'e#p[EX;DN@8^hiCR3W.JZOeaph(5EqO(\M_*!M_"#.imY;j12^]H;&Ajo)tfPY +%3d@8+gd$2@A6C;fXWsrlFuef,+i7T=8C$FBk!leqHHc_,MP4E\^ck%'T0YZ`*l7,hK7:rl,VTI +%E&2iK2UI;D+Z!1t@fl:P9c4=JG(f*>G2u#QOD@'Y-CTS1\s8% +%X(VIqk'l[(N.09,f84>\h5:b>_5=kg/"8JM'>4PopZ/W9G@#^bJ3@E6I5r/6f5QgGk'3rr3-#m$4PZ.k3L5Kt,Lj(EJ#U$;KU7/i +%;_iig0HaqR5q +%(g/D&C>h]8Q;Ek_)"fX/Tp&`i,1O1p/Kl.B.&Eb^/"%Ke(q2kqXN=Bna9Oe)Vd"gNh6gRo1m"Qp!<&(,'?Zj.Rg^T4AIVnaA0\jr +%:a2dc^P>6Ukc^Lo!C2iAZp$&^LigWNGoq`p72f9?V$L1Y^b',kWYT3Z^mOlRPT*0n(_T2iD%A3,>TP4[XKZWX@ee +%G#>maY:JDL*d%"Z"O7uZeWukYf+#f9qPAdEB9sAcCboQu%lb%M19.0(_sM_"p=8.4X-K +%Mopm_V%L\!TP&-PbpjoiIOYHTbRPFG&<34'e=J-pVI8@ +%8@t2&#,Apl)eV*s5,g(i/JURI[`Bg(MsG=ol;EB3e\@a*e7L>\/oKf@6Zrp(%k0c/!#e8\mfir_1TKZ5[t=dR]M`0H`"#\QQXYE< +%N@L(/Z_o5uX_$T1W>PjMQks@fAcZ[]^`-A(>cYOB9>d,=RMls&YS#NM(hcs$K>17IquiD1)S9]dn$E[_mncJW/XR[%S[dd99Mm_PM"JI<7@OmLbWQbp]eE0V.%q$(cD+1[N1S=oke^.Zjf@XeXSOgP_#)OD=/9AD9tp0K--;XO(i8e92uK7 +%L*Xf($_C.Kf")IUoijLlc"JMg5[-[EZ9>)ba +%U"B!(3(0j9q[I!s"cC0O\7IcW!#/;H2<@0Kk/jS9WX#sY5C&gDQZ?_+G9tbuJr%9%-]@*?t@%oSen"soH +%q^pMOA-o*Uha`Sjc7JMP;8E-h*,jJ'G83S8=_.R?8`JpYl\]a+8;)4r.!QcpJsH7`aDVC`+b(Fn%]$hp99*T]WE5PBJpC;'_.6.6 +%qmXarmIZ`O:E8Oei7^J!31C,s)("@KL)e)^+\33^KZFNP`dYs7m-nhPrbIKb4-T0Whqq]=nb2PMc/nV*:JXF' +%"P_+Lq!@b4d_C#Ss7F:&s5g_VYBi!srR1]:jI\X5j^3K2iqGAb0D^1tr+d)I_oXRHGgkFBlcIKQIeE!;s4]"$0B29rLQc(m2ZD=C +%S\9?ms6NO1q6/Cgmf)79n%[t6qrP#!DpQ/TrR$Nf]tOC0mAl02o8B7!Va$gRrVW/.="eJFY5-t)F*[cIo&ff8G.2tL_E7Yfo/HE' +%_"nmsYWa['lFZ*MnuK6r?&,[`Ah`g?GCp]jrku&`Yd([];,/dm.J>9D_M+eD4g1`mi)[tY&7`'45IV4VX(]mIlMq!p,DjE +%h#e#=(sTA(GDGbcc/kGdDuOkSlMe%nhgE6^Ddu=^3rY%]IJSkmg["[[e[IK@0AgU:o")KJD]-:!H$amenLq@ahgTWl^5]P1]\_IF +%Qe-"7ItJORGP5qSDn`op4aV6khp]0N>X.`ik5O4Y'HXq2n%Z2Y[Z)`g];>Q,U%J9O]062^o&Z@KCY!h#h,aBUh7Yn)D_<[BqTZ_- +%bB=)@rpJQO0CKjrYQ"47>H)GEB* +%_=[Ef=]Z_QrVksMp!I=(QH?LrMrt>NR*ml^F0qVr25C]s%DW/LIcj2Y,?>/Z&t\9`K/,p@[apZg1u5HM^Y= +%pnKMb?6+,>D)A1S*DZT)Rp0cA1d\rVufb#5c:Z +%Y1NXMro*7uB?+*>#LMMFIs#ZLig&AlVrp"BDJoL=]5Q96P!?KPa5,Vje(`W\cd"2X3'Y$)BH'6$heb`/p4.."CKPYe59@<5-ZgeUC(O0u9Pi'KnEC'(5.X,[lLN1AcRr:;i=G!KIk4I;NSR?*51aGVQZ'UK\p1QH`E8`# +%j`pc?c+u,)iO1H@lKD!pfCYf^FkuM/4anM7+*D\'lh;IZX`Q]gnh'ap`U.#^MK`n+X7UmZnHHW+h:\6LrUR3*NXpO:\#$c#@.k-0 +%N?86HEuMK=Ed32:G;FYs,"s>#V>l=dA2Z6""(3n!^A-I%X"V1IH[55=[aGOI4?UaSDJm5fk2t4=?gkUQ2Ja1J`4,:L6V/>69>8&d +%FgdRF_jVTkrsc<"A_=oXh4D!T[$,>2M?Mn>!`\tCmL^`'gDDs?D +%qZlkEr8[$B:k[^jo"6#"M78^@r7+iNrZ<>FGU$_oJb"UUJu8D>o8"LahJMB%GfkZJOV;c=%rV-hps%pdDdT'+?X-lA^\Q^=[p+5? +%*dHSF7;4]#hgWqas*c*3B"%_'#35etG9]1^?Wm@,q);sK;G`nf1Oh'A!/@YfVg'd?XBirhV[W& +%q=WjM=8.&L/h[-9,JFuYn(kCZO+,D<^'C6WJ+in<4J\P9n*Jf`S#[&&XsmYig\j&i+,Jg.3kF>c^A")kH!\*cIql1VgHE6VX)dC< +%]=A^kq=@[Sf,&'=6%7+-hDsKVkARQ\^*@a1E-tr0jITQKH"Sre?XCIWr7enp\\2AmbXR=sS_hgihjiNZO$nEm-HtpRcaGilH?:"MU_WCu-PAp4k`uRgEAL@e7;_eq1g0$9p*$i;neM>N(9^8e$W:FT%'/@X]h+s/GUI +%4hnOQp$3'/P^#TDk5oo;FkoYG^FR['f46,o]J';,1%Fsm6<54AO-s520"5FcP"E&6eMaXfic^]/.n3jqFBoDg'T^D14:".4%6InO$+gDIqm +%$0U`qG%AHM1?"24?q`P(fAbPCZT#Y0s5(?"IX1JVjn3rmo:LD!XQ,oqV#RL?e=cbr9@c7V@q[[AE#?<=,IYr"q#9G8=5VlI?GE$p +%J2;V6+oLkaRN[m,b!,2#OVi>jjE@n`_+]NFYpM3>HIRGLQX@HrJ2.PL'!VmH'gUXtJRIjf2LBEW4Qn87FKA +%[P7dIkYBa]:@72Tme=<,L?-ujDC9RKVsF'uj/mDd4Ru3.-DNaN)0L;0kVa+I*Y\tYj5o/O?N'EEg%SikAM-4H7&BjuX[b6\id>s5 +%2tFO2qL"6(rd]4MV\?>rbtKk8i'-&F`]cj@pGAqQ">,Z,3f[([+*fid.-8Q*9)56aa>$;tNHI3M.C[\$:HV8FS'/"MIf'!$"jr8# +%@2quaS!m-m"T&,WeZ52.56's9`PqN5rFB5^hVYEX^YXA;\'(7B(N2LP]m0AKc0a3WWe9fYZ]/;UG!A,;innS]lX0hZ=O?PN+<:oe +%UOdMDOPYnHoUF%bu?N=o?Vpd[OYbs +%n@3:G9RH^ZO6aWRUlF.Qqu&^srR*:GD%,_QhoeNO[JSA,c'oZn-_I\k9Z_eAL\oW`Rm3KMY.cV4aN<9a;8j3op9k$Ga&N!(jKh&o +%'n7Iu\>Q.^De7LlOG^fC"Ie'c.U:0muBN(5MhcNN4Pc)FL6[\G0kC>?6AR-c"T#,VB+0pdIjEi6!NUMd1/4k5t="MdnB0Om%A]DhG^%r +%[Z(UK]6j"[HFMAt^[Lmp]??NO8/=j9,Q66^hAsKm(D"TEr4.km)$Kg5M^NiQ2A2T@H3-"g$2E!(gTTJJ]!u'@Va&V3%/8f5kuJio +%61WRZl\jZW?MsQP^(8edeh&Va9Sfqmq'#%Hp@Ns-?JcdOp"QN3o\K,Jqn\t1@9$G'GW14rq<%UE5@)"7Ik]J5?gu+j(t+t8 +%5;mP%^6SKjIU^g?Y(NhrGOZM4_Z.74m(`kmRB=^1Omlcu6[1R>.XU@ +%eF\aY.6`24rR9.0[r^JgqVk#K0A_1gs(iWQn9DUbFk?WWX&irss7Q2ELi0pi42617rBG/=0rr4fGW^GIjt"-A +%,P)U.k#U*o,P,M2mN-i%C]Vj@['^q_s8S).-$u>N0Rn*r`CEgLHRi5)a1C"hDT""#T'L94Wo2g5Bj,Fi#mP_P,Dq4oj@m7fB"6.[ +%K1fuu@mk[W*[,PFTI6$:&Zd#**=($dOgCE$L:W*p](//Wk@.u!dRC0;XHP(Gjgc[Yugk5+'<>09>& +%N;\3da7Y!t?i/YCC+LH\p\LYqRl<9f,6i@E?L(DQE,Ve9qT"R']Dl\cbKG%0#/?^ll;+>_^Ce0K.Fm@c1@&q`lh;IZX`XNHe_lL, +%fgai(D2mOHce&F:mGh-RR@EFI:YAd[re.1c/$JFUT!GJ?rNT/OYmAqp16]2*M0mD1J%4gK`TR9jLsRBtmmp9\-%_;,=(;nIoqQ1m +%4uRHk-+j;L'BCu(EJ>75+n\@LQ.c":H]iT)p/'c\N^,pF6L2*Yf'ra*QJXt0V#T]Qm/$D,mt#*>[r8Irs)!\Wo-'^&2eQK7jjb80R^d]oIZSn$S8?-=I&G;OUK-S@ +%l!KH4l$`#rBD'36Ch+drmA4/3pX4EG9E%;kQ@;5%n1X`srpAh77TT8Y1AF$rmt!Hc5Q'oU]n:;iP1R\d>!>sT_%BK<"]oStH<\j_83B%N0qOKN5AR55ObK/8$fa&3 +%@O>N1k,4SASnkZ]b)sX<=e4i"6GiN!(29Fc\$pMN+8fu(eg3o%FYO+!Z'oHlI^S7*r`JcG^T>b%%?Z-Vl@7qDBqY)IW;LAu5Y,#r +%/L>[Z1mT+P(nR#Rb/q2;2W`N)c-u;9pQ9H.q\QrT,jZO"26bFlb>VeWI9(B\IVGH.JnloTI8t%5#$`[Br0WB8-N!_IYGm*(s3/*J +%Zfk'?e6`?99[^G@&$B@1`T/iM[J)6\JDMh#7.eOP>RI*3R;fD]^ +%r,&'9""o*YP)TJ +%b7Lq@I$!`>V;`&%>_lD4gqGHHhI$mY7fs4Li3KZn+to?WI?iq!En'NSOQQgO%:3)@c]?:E?\jlOr`CXV(8Bp))7/alP%E\IBh/OT +%F0T+jHq[7pdmVB+XprlEKsG^qTuE(h'Tu.-haHR:3F=?(l_4j\D%l"n/\ZAR9&IiSXnH$d*T-*ImG#$00>3okO`0LR:4@,uG?.D( +%ZA*#69gNr:ErDg);V'LTo2R-#Y:C7:B>12d/!312@C(kDaBce9;6sP[I2BH<)lgB9VPl`1>[LiEM4.tJH;Znu^KPUU]$T']Zj0NP +%p!/S^l#EPs]:7D8o?0/_\IB#UC=a!`5A9N?^A'b#f>K#]Rhj#T1jAX&=oW95$(/u`UX1A[+s+7CF(:qV/YC.M$ +%Y<$I<<"1lmI;eEcom_J-df)k%.`'r3b/@r=(HF3*EDEZuhQL+hDNU*OSitt<.>N&(dIB5lVbKr^QggWZ-9IULjBMUgV^jV"rSFS; +%n\"K?8CPL%kVn7qIF4bN7ZVZF<0rQ;HIs,iXW?P.ot3sc2!07Ec;0YU#-ncL^&!b)oErs\@a8,; +%NZ?L&O+o02=4:C,W7?@$.qtljX/EhtK^Pp5[MJP@o&E+IcnUfp`I#0,EpnpU)IC;[_T'Y]efWEX<;?e\g*3jL8lb.<7OG`S,l1W) +%U>f9K[rugm?d^Bep-DWmYFiI;H@\"ieM#d-^3`PT_Sf&[(Y2/10:L0U\%2mlnQZeNmsa$[O2AA5-H/tkOG0dnXo2h\MfL8lWF$`p +%\k4'@j0b_e$eko.J!T:uA'RN?488WG\175VN0A.^9M\G_bopc8EdpJfGLB?/T'&2ag5;'A2e8O>Cp'Mt]i4%("RJiDnP*r@hGMk% +%pfaLum5^a[-Q6AWaeA5=jKuE_?(Wg]s1tQ>Efc71m+[&mk-ahG?stbD+NP!D(*5V;Q"P+tKo7:Ri\W^boe8gTW8pP%QERiu^WWJ2^%,BUVhhSWI:R2Gf!,1/r&on7U>f/)-7<4\ +%PBg8PHlrfNFjD[5?;F)VG=\\/V5b(??(G+FJ1a7CnTgiF^5B5TkTKHbpUdp'HW<#9$Gh.eG:%Sg05X7cj1@q<-\XL6(PPX'TGJd8 +%Zej"GT?k@q-!Kco>:X>R^8b2V]U7'RQ%O-9piZ=>'6a>,H^$FI<'aP-:@[GQg<2aV[ZO1dXjZt1#e\0t^g\B/\] +%(i!$hg#[fIWj.VKKV=l8=Ak-5$6D!T<$[K`5M,^Xf6Ws47a^6,/(H[ +%[(aQZ4l44kH;*B)jqC?FTfdl'qaksDQFW+SgaDH6[J<5Gm3c0m(9;Jl^.A,!+E%n);f^7@a`#UKGZdGRKm6s,9dk<@$ZiTX9''9C +%[V)%:p@cf'546%uk46&@I?$6q251F)0@UiEW(sj.$;s>S_"P#\tBB\bR@SF9d+Mt:!\SF@KLbI +%)HFKLk[_BK73Tfms(?N'SZ=]DGeUfd\BW)jnD3_BjC%&d"]';62\2s(_\:lKni!GAM)9.kCI>G-j!)/sB&/2`I\3ZuRhIF.i1"KW +%Ung(RA7/8OfR>,-2sH;+FYj8);7Yfjg1@P4&GNYagPt$jlGl?3I=A\_f^'@AB;(qI?CV.r+87^OqkUuMH6L[hP+BC.";98T*3Hr]!sq6>dp-"2^=o +%Du7\'fs05CqRqIB/"Rh<4eJdA/'-2`:PBW>Np[kC7HEKKigY""aGW+9(YO!Q?2R"bU5S=cLd0)1b!\,^]GH!Fhbcn(4==IJ.E_k" +%p;og#!_n)YW\p0fG=n!l+Ps-t^eWnS?J(VpKVph(EOu$aNO%HK_uu07-Rl^HM3n$"3qm# +%374m2$YRABFY`fq.B"Ok]EE;tii$Z#G$u&,@Nnl_(@PKDkF+4];,g3-`D&q=m;8hV#`C`)4I`IoFYGA4P+o53MT+g]hj"P,Y!^efA(EAR:k8"-%Iqg5l8'N$M<_=d:G+u^QITls:lN"?W\k^:Y2o2j^+GQ_k`HmR>eW4I(`bpC-M5aoCEBWWt84/Z0!'Sl(PtJ>o]j0p"2E3NYlCW;3a?*^2V'D[%LZoQD +%KcaT8+@PH[Q,Sslm!5A.OndJp4mKdDl-=$$X6m'L2@34%%+%;a9fBi;`(Egn[[Sn%?F&W=n23mAD*'@%nhWfh'ceclbu(!'I5@e" +%B@(p$Y9qhri8\cs#g$@*:6rWGqn%sN9.sp0;ET[K%Z2NqWd1bZ.bCV3`R-P2_Yu<'eo"ZAmtl^G!9WC2U,G9r**'((6kU7D1dmC? +%Yi!1K5Y<)!Aq(??Ug$sOs$!($;QG*r]U5sG43RVa@M[,T#:RLNm+9u=OYV\h)bUmAkbB.MMV>Uk(mpC=9sdZ"ik&!GF?l``)DBZD%hI*4b2Z$-B.uE]*ka +%/bT_7Okb0As2X-b\X?i4\+sgYYjD>HF7%H2jkDj`ZH5jBD;&6` +%fKl:h"50)Zn8t$<2_bBfM4sf3W1CZ%YEo$Z@3?U%o"#D +%duu*g!pX2u*!"NqD7:&-KD;Er4W30DO?I=;&C@#UE!U:+B'5#d^%l%H^jGV_LVWY[KnBAQ@fIJPi=da>+:t/%E<(qnB&We5+-+g6 +%TmUh%4;l@u]ljCG:RX6KcmMO-!9o[O%Kc=V>Our=+(jL4@%X"G&\&@HHoenNYK5/nIcaRS3lDQ#SHD-+n>[N0o95RhSDSGZo7&aq +%bQ%#1ooCW-5Gs`j6m$Vn:41K.Y@!m6roWS%Mj#YrVuo@s4@8eJ*[,Zp?'W=mI_RX^3OjHIIZ']gFp:S4o>6J=QegW3,UF>F(]u64I.t.YjAqmgL0fg=4-kfJC>DlJ +%T_ieG@QXZfnFCK`7cAOP23Qg!"O9_BSBE`>p;Frk`XV"ZjMZ46!K0)N\]F9\'1m+VNk0Lg%\-=CDsC]88UKKp@9-?-#j*;g-l8l7a/hPAu'a+E:jT#CS,V6t8l@Dr<8/0^,Yn +%AIu.D%*1MdUP"nZ;A5]0Z<;n7KJP2VOX8BZ-Manj-s%HBRkl84Wf0X2bsm;n?n,;QG0;BNZhoj'PKkAo,_ka*nbIXR,QVW&R +%?!%ST7ufdiqc8?^hIQa=pror6Rp#^dXur.GZ$O^XZ?A[+I/Ylm>E_gIOslT:ig5 +%hNXC)GD4#F71UYU_V:hh?aDZUW\p4JUr?Qhder:E2MkOoE,%r`c`N*NtP_YjbU\CE]l6VBhg\Jc^o6-HD[bmqQ,agM&VfnE[%]B9+2df"h%,Z%(`%!jcrK[9,;Gu=0[r0 +%7!bS\1Dq#iAI.u)FW0k<*#J2C#8O9O'A2r:MUtfD7NgT&oF)AKXCRI3K@RW6\C2h`V+\9pK3=BOc7I&h]9dOD)o(9a3,];4e!X_:rYbOs4md&IktT+O2lf +%m*KkIN@Um^"lRMt/]^OOGIW3%)"p!\_j(6@*I:o\7*8f_0LjBU,.=)^QXN@m[tsn,#qQ +%a\;0-4:.Oj_Y4Q;n)WW+`!Ns]EgCoM35>sG]]Wp]SMt\eN*a5e$1WjF0p.G5]IF5bRq[RM;0'c58:rM3&UJN +%1S+=MoRSFSjSe$!:BdZ3"ss'GC@U4\mOrO!l?$Q,YiqC!%VZ_-esLP`KbOcK8j[#&1Q`oE)ZQ[5m0\He/chZ8.1.72f`FpE7eW4] +%lbMJ\U#Iq=59^%rN*hTK)r2^1l);F7f#1,srZ>WgXt*/N.uA^@rkjjOYRY+`jE8kurA8(E%5 +%5^,m,LiE:j[HT6<@Bn;p:M\b1,92`lrMI2=h]ai@bJPO$F2BtWocT2.7r1'nT:qVhk\>`'NX\?`s*jc,@Ri7\#hYiV>$D41$[B2e +%+>"MS^7YE+lWM`@jm +%GH]nD'sfo@OnX16A#Vst6:?.1j*mDa;A%)[?hB:M,+[gQ91&fM)!er?kr1 +%::&aRJef?:1.lXScL,iYRodOXLT/h>-.Xf9:g2(^d4a>*6$LSBEgo5EYn9C2F&E&+&Q'Ft*^k%:3s6@N2'N5+h!PG`hBI`?!nR68 +%(,-p_?b01Sa8)jT"&cnh4Et":"O`^9+sZ["Bntr+?Z.8qRV?L,J3St@5p">\ouRB=B7qP?EGS(4dL3_NYW!SE!1Ns8HY29os0D9: +%$UHI0aUBDhe&]HIlGf=!mEcb9u0bgZ4_MYHj4<<@e]0+Wbe!YSbU?;Mc0c.=n%Dd2.??16]FXoKE6aQ3UeFt/!U +%7DOA':V?%N!L1$a!.DhbJt1-YUa:%\B4::R"`g"iJ]G2?Qkj)>&JCl>`96m'"\K:4FIN]Bfuk:P-9\RRH9VY6Q8H1G>JC..b41qS +%\%n\i^:lOJ8f`8/ajJ/%NU6!4$Xo#Yo+KuND+s?drlq=uc0*E??Uo>GE&XB+DL:_X9oQuQi9.ts%o=inUeYYGqY#/. +%h>l,Z6VY$gh<4/\&-4tDlb12RJ&fFhrA;BZ%*m30"l6rl+'cjkl)@nq.QPKiR"').A7[n/!O^i$\&L*">NI.q5oKkSp\8s#?c&Ae +%K^KVpG)MRCqpF0XC]+:dO4!Y5bpO@rPO_Xc9-hR*jDB*qf9N2M5X2CG@N5OG5Pf$FnhM`ti$da7Ekk^*_$7nZbWt'O +%rdJr$9-j-%*l*9!"rK/;^GLg*Hcn?Pb#)ukTKA,,]Lfe%2f2&OqK9L[Ql3Q8h+I!_R8qICGi)nB07-L3ICuH$K91YP_AgJaigWX[ +%-W+aJn;Jb\kn_*DiUjQ\A0&T=&EG?hD#7)p`ua:l36B;5p'/RB^\rPeX;MdWSU<]7l5j%,IV/'pVeCk;oq6/B\_eNe"ShrBQ7&5) +%ZEhZs,P0M\W'sjU;jDdn!noYqt(!cf440"Zn3uP +%[_O-)g7Q9i4sDPeG:`]5AHbftHg!'Bre"0&(/pOnIG>d=,=@?;!\%.51f`sZO1pW_IoHG+6.(kEUYs`G)7P5K_bMkZ9&6N4N4(TU +%Nm(r^E/pSq"YK(R>K;A:g;4l_=5t4m)dSA;'m5VuPI*a*niZAVpk[Jk$D6%YT;]&^=@P@G2XX:OPNFdi>B]r"N;26]*ZG,df0NJ! +%:T2ILW&WefUtE"5b+LYTj)CR+(5H:J$m9u3[RM=JJCU514hs?*@"`fo8oWVqrk6YN&8a"Js-iIq%T'Q(g6Q%q+>bcqJBn;p#N43n +%fqV9=$sp$Db=#j,Jb-UNV-B!0\)7pf[gfuO$s/"$Q*$/L>@s$]F`=oFK!->f74JJfi?f)),":N>E9KU(dK;\7JV.koAk,T7gB!W= +%l;OtID+(X=\BLW7;=4^9&,pljbFtm;["Ig#>Dor!/5^D%GlMBjcTaX5MMZfs)=1`G%NT'gsn$KkG(-,S2d4)-s`bZl#!4."V +%PF(#pmD]oaoWGEXL=PTtDLcYYc'2gf((n^$>G*>ZT>?H7"uL,XC\nG`XX.$(AC!LZ"gG4B.LMrC3E*dP#,C(3\KN]!^.*?71F.:X +%6U:/<7L"p/adPNQred>oTOTeQ..3.3EG)FW+)0XbRk);%'YDbB@c2FMgM[Zl&E(-;],5dbNtHR4j[Zq$J3j!o/RMUe/C0S4R?TPdkq&+J0s*2$r;r!^.p&-D#JptnU)n>f'%cV7"IoC+ab^9r;2u?PU<$9L0).j8cd[VEbL`fTsPRReX):El[_tkd+kc)(WHD +%8\&MaL)8tEccDJ4$U!FNRg&e!6Er]3pfBEIX8/>ON]$iaN%!LFc2*JQULAH))narVG+o)$:d4b(R/\&[,iE)0LR4P##Vq^hVF0"X +%kpUd?7ehYW90i"h.(EeJhqti4,6fa8@m:['!'3$(bgEj:*I\mr8dMprW\"BR>9pk^?XsI%f\c0V>iBhT[KV94BE\9qTt:A$%#^4S +%oD[A"7G/mLYrP,6pZnJ47cuef(g"Yt=b?6m+2aV5'DI]=MY'+Y2W)`+?'ZcS +%SK`?&2`eVY&b51X?6b0[P;.ZJ@bgD0A13OGU]'\)Du9T^7MO=:P`YtR+q!9h\=MuhK#HSf;41oJ'#D$rmM4'04ZG:HK0=Jg)gF&f +%=@%j8aWBBbKIa)-nN;GKV@E9F#0Z5:IiMBcK&X`?O2H\<&EJ=0aE*hm7Lk1>e!cnp*+Q6t +%cc6=/INsd0][LlM5YpQf@c:;?mu2CQ$bBd=r_;@W*B"GF*Ln@M\S[5Ddr7)OTlqp/Wc8Ei(6g'/K1.=AIBWm%2!YEb +%a9*!Q)ZRI@EDd!Z&m_F>g3Kr.",N1g$AaL\K,9G\p5O)S&02k">X8tkC?p>-mdOd\k06hjt=:NmC&;lrg!Y"d>)MS<`iTsc):hMZbST$<"6+0=pe^dGc+nl%2L:DOn +%\AETB@I8@"Kd-lGma',?It?c@WHTu1f/HspqX),5'MpJ731!Q=:#/M$q+;5YTV9V9!,O6ZHQ[rSj>lu3OJa>M^^(u%5Ro!REGX+i +%CP0.aiLrrSn])c)0+UT]<_OeO=m3`6>]3u9Y@,0nBD%p*\?HC#Utc"3HO]S4T.s')neK:LAROS`PlJ_/_m\SX>Nd`5a95/:WMG)* +%cQAQY/l9>j&dm9!?_J^3CK\LGb=Eg[?hY;lSi]>W"op(p;MR,2kI$d%NN?@l#.h4P)um;tp8q]57A]BYpTh6n&VN0966e<>Cd`lQUMM@j%t%g +%5@Y&K(-LG\H7]c;Z#1YMq>QFQ0l^!^k4thl]s1=_f)%U&O(JT$a1IY][W@V@2UFgM.:CO&^P9qLIIHdS/V(LDIr&=4M''Ql^Ae[) +%HfGB89I$YJT;!D8j/&Vj>.>siUTO9g]_)s9CUcak?M;q;RrX.f`.FX0CNmk2Yf[tADt:OnI^T&*/sa.?'E6XmY-ne@CN/DJl]q9U +%<9\`4.]55..XGgT3U]p^)8aO^Rr6?YCn.&BBK7kYaZ;jOa#j(1#?-9m6gCc`gL]tWL,J/lPq5BRL6FD1'&3/dACq>ga9:3X[<-Fa,@hl\MI0EQ9;0;KhrCAb%Aql75=S]bOk:i8 +%A(:4mq!QJ%i1GYA5=V">&;a`Um12*n&V)ncAMSbP&rn6uf3b?02d,_UZb>,l%=AP\J&7]E+n4?/(J[BiD\kblmD-bL.s +%]AW[lm_E7g]R_3*p/Lb,p7Y:D$27#E+n)kI*hX!&15!T,R@nuS"EO\6Rlc0I+'m>Y4=j,9./9*i5UY.'jFr#*g1'a)PS4E,1O?lP +%]Yq/,_"+UmJ-OKroJ+bQh)Rt+*tgPF6qHXQ4_LWnd:X9tQquVpN`K3A?M['q+p.(i9FE4OTJ,r)Id9OI/K=%us. +%-eQp`h0]Z,ht65:@beXEJFH(.J"s+fRgsAk +%::]II^Hn5q8,U)26eq6Img=UnEJVZ7Jb2YoE6]DRkoRYW/oE)H8ajRjD/)gb,8-dP:Le2;^U1s_&`C5g3n[.%Y:i\ao!m=q!h$'s +%Of$f'7)/^MSVmR7$u@'4_"[VX#^^g`,.hAK(l.+(LkkglGe60@_qhCI%@&SO;/6Xf_0fdK/\)F@Sro[R]"j8np2)(fg_!%nhrr=R +%i5Ta\j;FA*Al]d7BJ(H9L8Dmg4=AYT:]XOD9LFkghWEd3Y`n7)J-]m-5X#P5pX"P^@GI1(\&;""XL9-;+sLCQ9E?EO.I`"Bh#n8t +%!L_"-'!Tn+\X?erO1tu1gU2#1n#5C8Df@DVQ?puE)n(sHJhoFm<\nd0P2&Wl@R$7-fkgi%D,N[L)mgYOPA8gW,u[.2DICsg9CVg5 +%_FZ#AYmeVW$E'ma?_Z*UZB*Z>p1pquNrSC8b+.PL;],U72,F.A*3*)3A&b7dENPi+kOU%0jCW+u$Ui47`0F]11Xkd76!8/-AJ9E< +%XR +%QN/2B!8?Xll>;CG:ld^Z0RC*=GoIX8SOKhRGias^T^ufTTO03jrhB::dVbH^Ag49bEis>VN$-495Jg1Wgs0-#:>a[MKB+.!pk/VY +%_Ka/U6ig,4?XWS8#IRLE63u6&P%bHU[WI[:&W(e\qtBboKJ/G%1oUPB\a>l*gm6[t\q!GD@LYe-P%Vbse@pOsC7bE3S)Lp_=*>^stW/pRO$:"iHMU#_STED3=&pojpU=#5 +%B!`(H0A#rC(G&'a[*h_U7=EXAu(_\_@K:+8`(TUUJG+![:E6knFl*e2MC3OTWKX#rMnMKDL" +%C=j0BZt,E^-fa>=b3r)*bc"*0AA]mj/5ZDEmUokqjM5W\GInEjVL`^o$d#Tm."_38HY#7MI;&E<)`[#^1?NVqNu$]BdA9?18-t0d +%[nuCFaaTHAWb/YY_]r,fTh%)g[pUl^/j<1)AI\o?].Z)1mcF*b*,G2sX$7In"FdIU_Jnht:)QYbtm+5]&Z\lH>(dMl%B+`gt +%[M!*'K$c00/QPQ(7^qAI[R+R33F9n8ihS5`^eKHF(D2FF/+#c3aum+%[\No3Ke;_Z_b8_N(4'eUCt9!+G&S\t+2RD9^hXjor,KIO +%HhA`n*6Wd'h&3]94DPk%Y;nDJDZD"c<$CT-EU2/N:<-@I@[iA5_7U@M8^V6+ANdb%KV'l_:]&.+lIgWhEE(_ +%f.QHX[ZulI?[4MVNDQI4p +%)L(=qRt(Q]CVRulVe:X2Z$Z_G#KC>6S=mFMGL/P`-YPXogJ3pN+Pl$FOtk=?P[gA'lZgo&3-h35UI?E;Hik5%s*F>% +%WD`P+dig%)eD,HsR.HK*#JieeW1sqIIpXn;;ZY'cAd'rp,m/PS*;5i:A(u4jRt.Nq2E6&ai"djeqC$mD"?`u!Cg/$An1Rdnko"7+ +%03pu2YuEeaoEf39juBgX_Zs7'd6'B'P!D8(RM20lpX9heVR2q\.iLTTOf;cPcA4L*pn4jCUr&t8A>ApC@>Pl,0,0^FQfb*7hI +%@taGgYjtgclZLgEG:0PB6J"D20uLi`e`Y927P@(qiA,_-7_f!.U'hYZm*DU"Q]fI2* +%%Kj,rF2&gqAq^eO&`f3XY$4F5T`>3R*G'cr$"UM1:]:6**Ku6r"`a#Pp/b@+-1V79!=36]*!0dpqZ6=DGiC(8ThjK`IARn'be!+' +%J1r_,$rl_=dLHGX3Ah&68V4GZMfOFddND^5%-t&j=mZejgLa/\G[HO+T*kp25_9\hD2a7\Nf+%ri)/hBpo%e!efM&i>SE3,fteeR +%1^1=r"N?t7i-HA301e6m$t1"u/&+W$0Lb1N%;?!p%O?d!n`o2VRd^6INgp6V"\MaUZ"ZtVYRk,K"JBB%%g?@\0R#&0-;6#/Ur^;Sq];m.7NOfh$ZR\.A.;#;.Y),$eAfQo6L1T%R6'hWh7B8\bUD?f)W36*/D>I+/Fkl*"(TK4EPLr2dfeA18`,]IXpo)!IkeNq9) +%R9%(SpC5`Nl4psuJ+l=ZX(o>FiZH'N!$'o0_,hZ<9EN:!JBO3>9C%5#A9)Jg*!S])o?nV=-l+V='-8CoY09]_q4saL+V6+1[@)WU +%R0AtW9'n2(nZH3sK.<066]$U1:nn(2]Ygcs>&"6+23mr!Vc$fU:qZjsS.&okf-dDb3d&7I_tcIZZ[qk.W85o:ppVclQX=qd(L6AC +%H8Uko+2GH+!?A:4X_lm1(lHgHqVCPlH_;/g(3O:kij'-NP24aJ]EP-c5R1.P)8s1El6'[LoNm`J:>T"'"2n(%'h6q5BW4Rg]9Tgi +%LTt^^(*<^A?\.k1o!&$!H<[D+V"(Dnc:aCR$igo:,@o!#Y*Z(M6Ytk%P.#\V#`i&n;E\QI+t@5AkmG\FS.U9=0*GR(V4-!g-2O)N +%2K1d>H[Wk_bN=.>XffEoUX")37V!,gC%QBDpaY'j]XJd#l+&s +%Ih\%%fMje60"C+o1'jk_WmnTfrR`h:5S1j+f40JpWli5>G#b*q\6"5h@YK(C9$hFhZWlUkbHKcMaKWrO!;.2jKiFL/'n8,:p+:q9\b-jA+t%rcGc\Ej=BW-10VRm^:Z]8boAjGQfT<'8p;aEDs5h\2',C7;L(?3.R-m +%HY(QWZrN4^Esq29kW"f^.@c0gK"PDKW=H5CeZirf"'G"I)[Q +%D%"Q]:BfRSo_fUgQ>JET;Chr>:=r/4cEM[R':-!?jf?0dH)C^Ke,.Zq+4U^^$W2&kf1*5)[5P']?:BUI.D)QlBl^DcFHbVV@r+e. +%X(Zf'+LOP9b>^"N0rH2$KB3CO`>3nh$7Im%kt3b7'HL&QeSeB$pc0W6L*Qhe>I7:_focCDVN[s01ibFWI'?%&W,7`45Rbt-C+p"1 +%[=rel029J&#H!#*WJ?"uFXp+sYSI'9-K0V3(mO\_KU2F@ILcqn"mk^n(6P4["o&nfOr9t+*C>!P5*Q7Pidu+t+N`RQ^h;dc0__8l +%Zo'_F#QdFI9Mk[6)TZ!q-(#\t2ab93YUG`W"*)n@q!g#e-@- +%"k:?S0q?Q[+7LJEOc_68)Yob>95n`;k +%mUM'Yg$NjC5]$4Q0:5pu]E,g_gMf`HmqS?!QlV\AB9;-o*D?0#aE;q7rDpqp(7\p).TO:LJV2jt.tEl)Nr.#e;*Sc,[FuL +%XtQKS1XMO`^6Ec$A\pdL*_M%%#85(8ifEcU^6IW-F5V!P!TMZAl200FacPE3*3#0\N3`*Q4$VX@G)!2O@:u9c!inTgEA!`gD6](F,qkK8m81o`/FYAo\De- +%2QaLL3Y.^([1$NhDu;diTFK.2"PJmuU``NE42@#mOXD9j/IhMR4K^dI:$Rb7``>4)>R@r?j'h\2%Vsn#eU+H1DAM,K/l'k%hQ/:g;L67(uB$3RZDli+r&C_].MT63.8]+DCl[jS.5P +%8;!bJ^B$!B!1@*t]>7HNj%D]2[HNCh`lgI1I]j^QIW@A%ZUVI=m64^M?sm"jE"]4k!H=X.1*:a5:rp>M7#a:Rn!t.YAO#-bQ;aI7 +%V5R$qs6(8+=A%5/cQDSmUK!9ukYb::@BdPGJ@_U"ajV_`s$MAYV$C!\UmOOLJ6)^d3%GJtt>@!pWn[Z1WIA+6")\s0?afOg%+4_>T0/g:#fc>qj/C@-_E^*aE[r@,ZHAX+P[4ZF7rq[Wg/1h^OhjrB;H2 +%^/mn1jc#2Q/A2_+^B3R[SO#PJ)EkU5']93aFY(>$\;43WhcDMT]%#i_hn)$#RcY/N9XnS'E_D=84Qr$mn&m.6:Z-;B"8)gc^k(8$ +%R1*ZH^,o]s?F`Yd:?18<[t#qHj4-Q^@A:$Jenn=6o;ooj3Y-E+i/Rf$Xr6#3>dJ7+lQD]eLGS)h_q$BPG,uYJhQVNbW$VL)NF()' +%]qp0:kq&K-jc6/Q@o.<*D@j&Kr$Dq8p`8$!n\"Xp^*ug9FB=Y-GajK9d`Rro7jk/ld]V+ +%$]E`8hYfIFhY@KJ,i3KIp[t)pZI)!#0.T)fTnJ`fV(l?Gpkp/[ERD@L4tFEV+*7OV9!Cg2']r6[jJ'?3Amm_(,)Ed0E6/^=.b1iD +%d1V9l/bX7bIJ!A8#HC(b=Np7kda9B(XT]G86OE*]V4qjNr^"/B:ruS6VUj5f$o< +%r@R5<]P2(_iY;H'DM7$L'BgbL$J7KEdN=3bh<"nK$uP7'X#2]&c^I@e^$\Y+(S&qI0\EOf7rl1qJ_B)O?5#'5G#-E5m0:&4J_)_n +%(+`*bMqRPuo9#/J[Qr%.4J+1D()]Ep;QH`!=1Q0!H=[\Pn=e'=l"h`3fk+]1.*\a+#Kt+:+'71IV_-qSmO#8C$.$(p=9dd]>%1mR +%6,PFE\@$0WW!ejG]Ujenmd'r!hl?FR+O&dh.+\D?g@AgEeEVVN6Fe+CXJnW%Q&N-WGhneMm?74`k_S>[;o1gmN3[]bKCbcqWH6k=$Mlp`IRXQ*Bh-u:OoY3mKlk*["kTF68,BZ[MtHWAkH'K*\m +%/$f)l9%U1&XYcH%II-Q%i*$Erj8tTje\u>o1=Uk:,7G`MlON=1^j2gEm_f[,0i+cS_O!8a`A6nuNfnJ8fe\>lmI9p6Q-ZHV]r#*Y +%DoLM&^6B)P[/V2XQ/G@ci.1S"$n>VC8mG[a(nl,*J/tUVeut#G`B82V +%L/bPuN8@k*(rd',A`]u2'^bMWs[07j#`W51\;-4mT?pUH#(Va&H@/]rZJu)^a[[Cm9RAuq6WH]C*Q&^[d9pa/$ +%#Ql_,LN5"@UDXd'c3%$L_El6$iCgW`fnR%c1%7 +%RK+])[>4\\;VN&l'MQ3Y>d2lAVqBZ)j:sj.$Ic*q3ID_f<+*Z]AQBnXDu>!OGF/An21%o%nX&l>; +%D4/'`i$q_Kg`pmW;oT_sV@0+^kZ1/*bAoeRcP-B@h;tB.i@N=NC'Mp_."3)YlIlG;2r*%gkAa61p_$9kBbA&CZE@h+'/ohu=BF@7 +%n,"uN&A69WXSVAak8VWS=#O(s/B>ODHiN>$OIM<=S[/h"S5,6GdUJl:0;SpN=^r]GEP+46\%qk[4Rm1!;e1R'T7l17\5Ss*b*/FN +%k?&K1gup^H+8nu0K>uc?PfA!u!4n:3oDQ4$^[b#_pS9V@cSq5EXYr[W0&0U!fEZUEeilJA%Sgo3GpKO-K]h6G2cq[:IbK;X20B2m0]LrNA[`gjJ+,?r9IM);a1iRlF)P!Pd3RJu#O'&[r/T;2/=)`\Vpl^4r-4:L5q2u#LU#?`er +%`&XM\cok.W[CA(sgU!dWb"rXM7'cJa-'"%minpYn[I!YcC8dI_XXnKV5 +%"tm<\B"!*#iDDQ4aNQF7cFnAVfet_2o!@1=U,BNI!KXqm#_Lipn&CDH8%Ff<)<+OR/aCPh@;IG75.@*qbDsPaaA?3NVhj_\E5!*2 +%m'pr?F;lS2Cj1UkV->sTlssLYmaldh`CU7gk%sbX\< +%!bKO/Z,N3WH.qWjDC%gKh\P"`E%B&4J%bA+:\BLmKtXoqaGdhi]1J:$$2*UgA%Xq=\0E=BSC&70@k1a<1EB#21TF]O&^FK\g, +%]r($.k(^AeDRZ.10ZEGlEK0W)hgOA1ZhDrNmegXP4@0EccOb]k2s8uRgk"]FmPT2)cR3h]Y>R5i4)W_phojuHd'If<-k;\oeYV2r +%4mk7!"h76O75O8I6C/QA>=Xo\X&+@_P;cFJ@fV9=W7B&$)s4P5XS3%-`6@Ok"7*Ur2>2u2J^c!9H,Qh697D&un!P_MdPJ<"eW?Eb +%.\EXCR!J2Hd#&e1)Uf`X!eIll8$%=+'WrJJ;*edR!5&id'\*Be*8nET2)$&6WJGbRUr(_Te`%k]QXYe&=>7%(oZ2"_#JaRNXVkt0 +%c`/$Tb3%IM\_"4&igeE*RaU[30__#hVqUOrBfBumnpW[.o1k-Trh.G[1^*?+B:@nX>#oRP5Tn9%jRDq6U +%4CGO\gL6dRs1<`0c=^kgXTRdTj?p`er[6VHF>Wd,:MpjCbp\=r0M>QY-#^j_7\j#>Br^mR#(#F8b')oeC7_)8PFsWcV/UK0(F-Y1?(O_mri?bY>k +%fs-JJ$t;8IY>Te(0sJLiYQ(0"-\;]7R+L+E&9Milr^bZsJ&4)gV(j2NGF1rQq=2&Iat7cH+,BSRmF,M'pB6'C-?041%1LIL[:XWt +%,A$Si@bPGgO4qe^*pJ.EQZ@&g.c]ZSW?d1T%q^^9)0U;U-o2=AhsN;`2H2O,*hf\9OV8:=A7\jeBrK^!Kb)K^#g5++!duCk&qslbjK+b>m@T!jJD!Y+#FeP(R>L-IG>l)>n +%J-pIg`Ss3T@bI?3S0Rs)P!WP6AODgWi:Tpgc\8rch.Y9uB^euFEn')TiY2]\2;N,%$HQ!JrgY+Klij+TcQ9C]+_=HV1:LSs\@&_b +%U),Fu<&([pH4PDL,(U(##]=?cCB>2^ke0+&DQ,%GbS';+K.;edHfY(3Z0f(UgZg$IhG+DC6$LFq2WFV4SnRe<&?f:qhAKZ@!YhNl +%TLuslcLm%]B8E"ZMXXn:[Co[n1<[3Ar!*7*c<\Pbb+@&mJQ]8M_o^IG["JG1dm,[`A+$`$t."H9--1\8EnkfCZO+1j? +%;/1YpEaq$/gGW^3lR5acVjZ'QpLoG5**,Z"/tdM`VgV.u+j1olY4,>Re./3J35P((#W$A%8j+-*1*X0-r,kpEjC-J;H^d1F6(B_: +%8LC!eJR'P!o*n+D>(2q/@4Gd&Im*Y@8*aMLCJ:U4=LT^LH8"MC\'6SK!nnjWhR/IW]rg%KPF-s2]Q%F,&(X87!Yb3YM<6;CXhO;mE(ASclIC=i7.$DW8qG0N""H$?a/ +%p(>J*bn5X*KE+';jp:D`E/nnb(J*-H/9dTjFPdXK_Cn`2F]n(@ko:',@5r!a]HiDQ<]Q,Yd5H[`!Ld0$G]1U+C\N26l.7:'39Sj%=GhN2s1#+m.uoC&N2Zm+]*g[_LG5BsL":K+-C%nE#Qm[A6"f,T[!d8)/Ni<&LYr^?GGUkFb3"4S@Df3&SY +%X/1ihr.XeUXj[!Yi3G^OcMMV,;bPDSZ<-e1L\U;Zj4cYbkV0YU@Z:]_-`BO/di_SV+M'J`=SeQ(^_:H6S-K<5RFY +%<@Rm>BF_%["L^0^FT]Uhmkiu"4Z?tT=AnXSe_6A&05MN.IEn7PGH`!^bY9XZkHOZ?1oK"`N*mFm"XEKm^k4gFpSd736pAn3f7^;> +%]gCI"h1W!!M[i^&?dH4[:Mr\XXlUIsTPU9*]!LS,aIJ&jMtOVV4>ReLDVi6qB&%u`\KT/GM'.YB#0>..:1Ec6g6q3!(%rA$.#[7< +%M3A?1[5)kd\M--C.DI(*".%_:cLO:T]ZeRd)@;;V9`.rS0[5Hoo]\Jcb#;al!d[+boKE_sm4Z9!X#e+>nKfa:^5!mO;F'>68lkD6 +%qj,sO+:ujtj;S/F]Uij3F+2*L1qablOhBnriq\?HC.Vud'UR8`q90uq7elra'e1Mb)[X(0O]cUV,P1de_L?1lQYdiiYSs@TKrf?" +%N;"%[&?@c.N]!M%ODZpZM)4B!p?Jc*I2Ct)-H1+]O>RL+YV\$*p4a?3m)f!AA.7-,0gsF9G*!QY/HR>K$l@P8NAM`6S!f4Rd=hg< +%9AX9?('AWVN9s,ik$&JP`lA;pIj?epq=Dai>V#%/_LfUKBB4,#.JMZ5'MTO@5o0QC^@YWV(*$k#H'LM'tr>f-N +%p/%b%aY72?I&%*&g(>J4':+kJ!t,J.TVjKp]lhnEK"#\`;^H^bLtJbn`Y9?)r9f54.nP^(>C.$VeG +%3041E7EZN-3CgN]#$J)H>AtB#bpig?AW_Se+hj@4AR*^)JfmjmD&GPCR0t5j3UK'p,:%)Bg'Cd]WU@I[$m;V'S2@VY]OrbXi>P=W +%K-#usLGK-aarl.[q9XQQ3C=]g4Dq\8C+0Ue\"=as1dR2-Aac$Z0c(R!1@LV)nP0)g*_G17Yl9mqJ48H$P!Vo1MHT6i_%8lCIJ<-Q +%kJ4aZ5pQe9^c-Q>Or]97O&@pf\M,tkKim[3KJf.(2't1IMVPt$btt6/"SECm)nfbR=h>5,:VB^N2r1On0INg14 +%_VJE1q4&mLCUb;lS0BR%;(Q,(+^KOdZ%T#F@E.8=-%Q)-5)L\uHJ65q"G,VS3-0;rr_;s.dLa-9c7'dg-PsFl(Yh^JTkD%E#:4-h +%@/U!Hp#TEu%K!u7=\hPY8M>I':skD"UpEYk2YuTQ)R8gP)MQ0XXP9_[gFX'XTDDF>G72/SP5U*Nk&V@=r3W=%2RI4oVR#:$8ZCIiVS/?ess.(c%BX201/IZ'F^#7WK]@ +%FD&Dh=+of\11HI*pNpMP.[h%KSR&AD^ZjWE`r6rFup=+@G'+0H4TJGg.PuTcD7G`u6HR8js!IbXu3)'s#VD1YCb9+I@[$ +%ad*B^1+5a%]M/d?LG$S6XMQ>^>"'4Id#=Wi5j"H6?IRh[R"?3@\Rc=WH\G0R/OTR`$sO5l-qf0*:ff)RL37AOZ8Yk5N'9jc]f+RU +%9K>3jb8$Aifj\DKApBVVlSPC\?r,p?W<-o-RUlj'GnL6%[9Wk]=c-(\`s".KHJtFIg>3^T?Qiq6]iE9ZKpVU-#nRu;]S_).S4A1K +%9'C-JO(Of!"^DYq^W2VUug#0SR"ONc9O#[lTdQ(\Jk>+M[+)cFHJaQM+sXMC)_Xu&hkqUfJKb46ZlQ[&+6PENR/[0c4NG?;,= +%hKpU"Y7h=Eb7KD#MbkH_#Eu3cNS@Hdj*7.,A"V=/q/3HFEpcCLZ6b[`0'q8B@>=0G(!,pgV,Nna.u7L`*pXqEl]oL==,q;o.Oq]5 +%^B'&AnHU+-Y+4]j]KOq*Q.Ssu*bd3lm(c3WT=Aht5"8"Q;Tc;++@#H?T\u?U$L[B94THoR6=JY43UmYKq*["S_]Ineo*P/'q1q0M +%il(<-#[>8LDpV[H+Aulp?%e,[l4_6kH+(q"6>[;1I@omGB&HHc`UST"jkcCr7h3MX+%RGEofX\OT6n.i%JaK+TURP).1q4%!mBZ1 +%e#;Gip.BEmh=2:@_rrB7Fi7k\3P<.C]h]L\k7Ooc;KHH%!#ZN,_A:HfLKh@G%3J@RoOFts(NA`Jke*V+8qNFN;3`u3t>^`jLg?sXPXed52bJ/U98bSgo,r:9rMd%[J.Zsi89[u9]Zf&Al*Z*n.CFp5,/d9lBr?d%OHS&V^ +%Mqej`VtV0g*Mp&0MD&c$[sI-Olg;f=Sf:]Dq_V^?SC8LBa1DSYbY&t>.0!sh50GiZ"/EK_44^IiX:,*X!8Te"42n+Ud9[[`A)TAG +%,"2B&,>>9uK0U?Yl,,;$;M#@!"d*-l@655tI,/k90D9_sbSGF34=V.?/^aF,T<-1P23g-+/js81M0e`()Z><#k7-8[ODT_=[rIf9 +%hS6(l-X#*Nk7KQtNJF(eM%_]o>$%^R`0.Br5n/s)V<+RLMg/]qp-'K2!)I)baW6*I\tY*Ub$7sVVrr5$Of,Ufelu/D#Dlt).cS\/]&T?n8&'60b$tSrgG'&1:AbM +%/Ha)Mm(djA76.Xukhj1_,\/&P$Q*+B;KpaVJH_"[^gL+j&cOsoQbbX%*kl`NgU50Ub5D +%b@e_U],o8akWZ.%?f3+g1X_^C6;`8T!%UL7)9oD0B9,-"JH28^=QutT:`lM;]"g]V`_"e:7AA3N/cM#_Aq@lu3!q1pHaIRF0 +%&qkJ*CO?8k]Gj-X7te(g[b-sa@BWN)1K]pg.nmM/M^)6Ri,-cO%1?NLkt)N7&m)!YneH#JS0h!po*hO4gJ&!'kE-_dDEBd19^>EH +%b;S.cndX%0&Sf_ZpIS)F-aLc)>s+6HU$`&IC?k`%nX`1RlIssFRZXT&"&gc8> +%P[t.$pjA$>QIF'hY$-'+lO:'i-[QEu&VK7.'e@eE\%iPYE,-@Cjc>XE)^s"r..q=>-hC\^3@I%Z+42aOpA<@_C2,>_8(k^=4qY90 +%TRu]#VfN_p6a]&>\iA5q!Vh&$n55[km&X1C"#=oH\=s3J_LcJbg_'JE:!%rlHg)Lk[/>=lp!tcCc.D-IMsEYpY91sZ#\D@Y;.C,7 +%,%t]H.dd]6q&&($>0NCS^s^Z>W*\8gi2^)e8$$)'ZWfEoX@C>e#VT+,;S'aHC'*s$Sf)+['sZBgMG%dM`u0oG[Q57X14oKR*\--J +%CHXZ8p$dR5>[@Z=DYC#LWECVihb<00KEPGKeTBKf`?7C7*DTP0roph'm93@IO)osMV9n:+&&l_l=IfNaSB4=]M[YJ.e +%QPH-)/XF$Uhod$P'S(;?(VJYi%q<*<1P:8^ZtQGoOql8/$l>18CCBjm.aN!@:DU_A:!YNMXATP0FSHKHplt5Y.UuG'[FKM7Z'kh; +%-/VMDFDg[M=ct;_@MIDKjsi]*6P,O7%%]51#KdeUShCD*kZabb2S%Ym"CuK(`i*#&a]]Q6Ks4\F5un@P^"I0Mq5-i/Y=p:NRauR2 +%1.EZ"?.UU.BZmXTN&&fGf?(:`V3&G6%6j3#X_sf3nZRI:Vi9*gH_S=a^Oh[+`)kTb+&*J!_Jk=i'kTiVq+c_?GB9+jBm#qW&%cnH +%^lCq:-o^'/*PjCj("86'!bF&PK(P$`GF4_%:Z>;6>TLJok&IVAKn2n.2G$s%C;)LDJPH%5;=ZlBmm.`CZkeYBbi%i[I_TI<[QNHM +%pr>76@#[;Jn)4EMpNNa6oiX5R=1qC2]"\7jr0[?K,8dG-qWA^ln8Z6aNa&j4+YGb`3t:r1DVJTPP?QLU!:EX +%CtQII0q8/5j,SgN_PV[Ad:>3388XQa!_@Z*cqkSGVO-N69..@Sj=S1lFlMt*!qNL2iD*fmZs\[\jp59*QtukPc'0-?5.aP:jK>n_ +%FVsQ^qj,KhV2C%^EQKP1(5o9!,s6e?jDEh`dlVCi6npNA%%q(V$hW]C5V`=`Hs(ZR3seY;O/5pIcf"/C8!)kj#-OBhCB"tA +%,h"EmZY/+(!9BA%YS:%Ej1a*>/$jE7j/+`2$,6TSU]?d>V/9fcfbq'6^^;uRDh;J$nBTOahh%F_`Z`-B'5lk/'3Npt-K)to'3`4D +%*^)aP;/annd]h\7DF?Md9H2+Ndn<\)co-d-jQd"0n&tPc"q#Dm2)#7n_*_?49hEGW$0RhlK)=PE-Mp4_"u2iJqD;k>/"J]1bS5"o +%^q+EqbYAM$Y\1^5J@=3r$tekI9Xh9pm_K%*GB4ha.o8a^KS6if>2\t>U&2&>*5rmDT]HjXX?9=)-]Z08e>7NApblqWNCN%4jS?pT +%,AY`%7N$c'd%]Y`.<^3*9oC6)iXIN@?Q-QsR;$Z6[*Kf`SWLY;4BF[:'#GRN1"Oi"WQ37$PA0o!."W4Oa7)k/>T:1!!WE,gQuAu] +%8nMnIn$LQNF`>+5ai3W`-R7S'"@Xe+9=C^SVe-q'rkao=?.$m4UnYj9N7U3K5bG_QK<=bP!INU"#id3tQ#nX+PZD?& +%bAIO[$@Xf8gF'JNdr%9N,F6Nfc&&6q4@5)X/k"JiT\L@m#NV;EAHR4Vb[-m`kNg,Ak`b'n5364)4XV.%%rh5O9:r_WVol33H%@fS +%P$*nT]nZiEO=fiYP2MBLn/+CH_"Erdhlk*]>P%J*-o,JGMk>VA^Ygb>7.W4s(p_WW2E=c\)n'VL0Fpt!5fYa-AY5&2IX7f!VPI_B +%1X_LNe(::r13MtW;oebC'V(K4Es'`pa,p%TmXO9K3(XNi7f4SLHEPGe=m=c"(_knGZ7nl&-V:#5L0*'h2Gfh!\0TA0A:*JueO,?B%VhDe@mJ!JP2/-oa.;a,hPM9V^r=B?oW,H0YG+!NJ([PAtBK<8[MA+$_bQF6lQf%S)q7ju(i[ +%MI=4`9i>fN1te+SLB;o)f7P'12CGs.d"'0!B#\RoCN,GWr.;Q5h_r5J:1nlQ8LHobh[\MPerm)E^*d'=`\0Q%H&Jn%*E9M6SXT2V +%k00T8k[0QY-MC[\%uk]EC\\/BTkMYbgbL`#c_!"^k![-"/7*8[^!YW\G:M%>N-d1G+qN6SCCAmtga-M+Na%6,L^@gn9frZ*m;e"e +%rfL]rP&Y62S\\KmKd+j%5'JBOmG$F@dg;@,?[+MZJ&+4$8R=]T,*br +%`S@%,*Op/@W-ZY+s!&Ze`@PQt>8d$K1_Xl"-B*`)oI/1F<4#qZ(=^7)aCP-FDBnO71/_5mL#kfn&*Bh^lnCCV-H8;CCdsO8[3-), +%W1"pQC'sFLQSUNCeBfC/&4nD=:3/*oLObX(7eWlE[W8'hRa^[WTXn<[$#7R1MW2mlQ6c.(&MR'8I5Sb?hFn+6pCa\o2o4rH$`l"K +%"=L2:%%HFlcU)-lb)Fsd=\Ao'#X-\oQ@!^7_$nOjGYpW:Q=RokU9lV.?<6qNdlrF-$gr)QD%`7e)A\k6f,@-eLCie8Z@pgc +%BAmhbS-p(SMf.WC4D?DnB0%sg3G^U]0`l-HO*UXl:IL&Kf9BustWT./e(HBE)co!eC+bsi+;@f1! +%!nKjAaHa-N($jS:qV6:K1"8u_!^QI0n.F14fLlcF=i#j,iEWuS^?okJ_hl;bqMDa-<&44=,QK[`fK5L!0'!]C_bgi`^.Ope(2JcJ +%nN'LM6^^heD-1]6lT"bF(lUD,q_r=62\LYuNtFRkDr/9h#0R*Z$jlKh3Y3ulrk!9KFjFI=OoN?e;t&/Bi+BLA=(H@X$gu;5UTUMhXHE;pgG$nCD7!%S3o_#>$a&TW@a3Z:IS":D,&1(W!/kllZLNf;UkE&GGY%r!`jabsZ&W)ILmu0&$9l.aiKSFMCZ\ugAo9`$ +%Zs=BEW<7$"RLatsgBb6upJ;++J3@ApW:.'%bE;3Gl0YX?30Jq8E9&gAh"@'\K3)]%h%YbVXM?rD7u +%UL96^oR%DJ5Mm`YAXLG&SoW#KfeO$tGQF=30PPqE``+^qNPEM?B\6&g=*m-'5DR3_b1##76'PE/L1Y0`8F#=[%C>P8hc65u3Y5B' +%]2B3@gfqr^1)M=^VAOXOFuk`X`'E+b!G?RRpH!!9;L@%dn:r&=WT)QaH#':&5+,V%p^CgW#A&JVkb1h+3?9I/BI1KKp:qR?BV7#h +%9_&hmRNbNA7NAdG%mUgRWFNeP;s@u7aJ'E$KViDP]CR\KQ">^i[Jg):/Ko#P_G15qILd+poR_'E8OAe>2O>LE\P(##7_^s`2c"Ka +%YF)Zn->.J8.O1`@8cfE"WtsH[F4IA2G;QY5M,t*I)5,!$CoH"**e<+`MA@Bgo;G8PCMF#CelOQ>cD!8-K@&g[)EeHd=]s6+3Vek$ +%jTTrG)[2mDl@^Y,nM%1M-r!g07^Z-844=Nm[)_*`Ub/R_+d^+bS`q]K!]_phabMGqgTh0rFK:PN9h6',!jqcJlTsYU,Y:I*%34?Y +%IeGCE?j8P9p^I6c./-J\i'c$OPCW6-<7"prHioCfYb(goEjSWApF#H1__ihARQ0f"';b>N(o;_1b#^c@0NE2f!l_"QV: +%1;qf&0\9eh2mi%o#h-0@Nni9M[u?q-mO,i6D8m;GBI>H7q0i(O27Y+S;:VO(/@6:8hL.Pp>!Y +%:^gb;<=f:Gf&I5b.NuS8C`b&eF^*t&TGo6Q%0=M_XoH``(UMuH62'5Z?lX*%fr]mRMREZ_r>8rgfDQI)?GYqZoN-8hfl\4j9>Qg. +%Yl2h.!cR#(%<&XIi@WY&q"%(nYtH0(`7^1>^JRGK7lBe+(P(qs#Q]:JGWUjN=LZmP3u2NlJd2V/4"Lmm&F$_';=Y&Ur8I$cpSeHj,fh$+>OU2dO(ced4%:6q`_3C)N3rl/Aq8?YO@mOZ]@!lP.c_bWiLZGPm4;eQ9c+-fF2m&K!i@)mEZu/*m?@k<4L6%:$7%PmB?hQ#sm+8B\_agIr)KPYf#`UN6MLL&60_^ld/F03/`FOH^>AJ=^TMI#K`d[<8GT+kLqNKBAW +%TYN]_9F&W_@n<+N^+>;DE+@3@Hl& +%LoYX''c>?#W5>,p#g??.$D)6Mh_U'ki7D$2'.Z0_32((#EWITH8t(,_N\upoO_.#gC+lnijAj1#1Ec"OP$#&AoOKe_p#'=a^/pM% +%4n*5%"d&NXc6?7p')@:XLc5KI4^%MJ>)%PXg&(7!>`uP:I#jTV`/5UKL;k(L8qbn1mVVD<=>a^dUc3LZ!g&6,O'S*G/XX.sb:Af) +%f@/Qs2]^??O$W1O*:2&gnRBM1+6pI<7Z&ljqcAM8#^VSiW+"`q+NI,o\88NAR.1h01.To#2WJEQES[Kg`>.ar)=h:gfnHm0HY85W +%]g_A)++mhYl&0mcCWhZ7Oh4)Uei2[<8A:oBr$QHD9F+6"!EO2PVr\fD%+9;nc`DXiR,IaO"Z)$6Ub388'&X@n-F:`gb[J4Ahi7+2 +%MUV^(#6h;6)F5Fq^j9,gfn2';9A=c[]E5q[``FQjg/;Yf#H8Ck%*]&1./27W09J<0_AoiE]itQ@$m"[9empV+1G#C0p^"I\k@915 +%>%K=HM#Y3P9Ei2_oYJa;=j%jc>?25rhL5U*#c2f17ed*\OZ]^r;;sAtp7Pf(?'N[D';24\V5^IF.'#&oiB&)2M +%acik76Fn!0>-9BMM7S3fbbPr'#ZAMa-isaWN'!L@iPX'OF#(l8!;`I"$l%RVGAg@_X<&p\1t^`ID<8Hc0mLDAU9lLKU__U/J2f$, +%h4,AZD0*G]gC?m(lBCU?M:d%UX'L%/pi5`cgutXE/%[=kj3Z'-DmkC%1I1K, +%cFAqZ=hA7'o"NVO&X-Z-f>>Dl8iD!bnJ$-m5`4\5>86O:e4bn8PAF*VfJO>P<"'20qd>aXE=9Ao#9A0T/'El%FHF-s=I3l89UHU% +%kKf:hCm-"^#Hsu>7p2(piPYLqqQJ"%-V2G<@a(ps,&i(*?Ee[/nE?@,o;1^qaM=?Qh_9LslOFb*!!^`tGn6Q?FY]c]7u&`5gA1h$ +%WNqOGN&BKYljd<9m\\QY3L@?p`sUZ/i&0k-%QP$=T5.)Y8ff<7J6_P=r;8\.V60N>=^q!%'d)B"cU5JZ@#5&bSoK5gE#tq^hU?ba +%4cCLe;Js=,TJ-q1&uB=+UI$HGW!KA[T^#&r@S6*ic +%!dEJW#7(9XZmB$;oD2X">c8+^rRT.SNhTT^]9ZqDKtQ,DDqCIHXD&V-pg!ND% +%A&&cUIM4scd:+Yt'L3n,N7Jn:p2LYeU6V@JJL+=@>WL_V4rZd+g'!(#meI^YI9MBa>04-NPH.paA@Te1-_L`An0%Ir%]si]4tXSM +%r);?9m`-A2s/EJT=9CSHe2#b3d^7`^EXW[m_5NC2#2DT^`YTB%E;Kdi\dY4-N7.9f5;LF,%tq6 +%!m3L[H>s&m8/LdeCQ)2poq4S76%Q-C+56!FVUScUBZUbsa1+/dAD,+P'mKkPaR_.'+Qh:PfYH.R'E!:m5`\b,\E]lP4oL>NDI&Z0 +%T9O.^-YpN^UX%eLi>?N$C'*D)r_]\2q4iK2b/q_2jA=?%UWu2o*`pj;k_!!o7ZiQHP?i*"\9I6P3)@An47'[fBPtEX(UI9R>gV.+ +%H:EZ2Lr8j4YTC4:Q;AUFLZK?L$'ZLla0@B;a)V\R.&V'5"h)WVQk$uA&+\Cr?LU!O_8tZco/p-jbq>U#RA'VWeQ[sQ-!*-(6"Pn1 +%YQ:oI"LkjqT2WOKSU_:m)*Kqb_J`c0P@2.n$uJ!YXP0_MXa^!K^M*^iVI&RY"?>Tg]e*m@$oV"#3%(PTChMl'YPiR?ai(FL@\&]- +%Y62=.\!G[@J&"TFTkHnMWCV<,>ch&lAq/]r$',04+9r&-F'(c2/\sB[1TWTi=Q*kS-K3BpTB-T+7AT+d[ar+WAu1)C1,=8WAL-: +%PhSr$G-%7+Hk^EX`uP!28]DV'?*7S'mX*+lN.urd0OH@dWUg+,7rVl\7>LJC^B$VK5Fu0&1Z-7=,C#M7l8NS-gHKBRNg&lVSR2?) +%!cf?h=/bp@Y?O)\FK<28L^NB'0UY01> +%b2iYcLG'I"ZrJfVVKU[+J\iU]TZdICF:RI'^W430D$`,""h#J:J1\k.Du6-hH?90@O9NkTdKN1r-K(?&lop$/+3g,HIkH.:'<)4p +%\7lJXF&B`cAM$0U[8bk&PD9>*f7a9S&Eet*TmGGpZWdUm;;[Ee\$jfDK>(2IhZRoqD%@<,;m(lhjB_150EM_/qu!@q^b=9Q6@nMS +%grHi4^%FsRG[9$Zjtd9W!]2""Kk158s*`,kqX91mT(u_ljCL##4,a^lSo#!$anb0]66;_87hJ97%u/&J\F;t:M84tpG(<2epo\)hnY-@$3=arq%C'Q_=lN.Jmi/-N*"1TO>e_upL\-L4X(1N^h]/4:A30@8sBalWsFp@oW`Oa+WNFi'?%MdQ7 +%e*=d9GXd9e]Rn#D(5e`7Y=S^Q7fuPa#9"Rn(57k#6[M+0R5DM[7N(tDIQd;s6o301@Z-co2-B_7<0`3=CkiH(]+r*KFc6U_AaLc103)2"HKSbX/ndG`CXSclUe/c2+'6t_UgC!)-3?ePm^qt#/B#^LalR&ek$CZ5S +%n.pAek-\]jkWi\5fa..DD+uZ]hh#U`ICM(9qW^\A+h18g(n"_)PkCK8^cWiT6!9?/]*mm@4(DM"]'br91FX_7q@pTUF&;&kjl+$u +%pgX0e&hHW"$k*BLJp08#/1`[lOq5(e!$3DM"@]JGl[nT7VJ0ds-,\]:6=$?qYZ"`n45K9;fIOF-'.@5m5O=]iK-f=oUtXTO9Yi/9 +%Pg7&.El$RIBf-h5OFV[&_i)R7JkLQn4DBM%5oSD""eX7a$NBcBj(#+%_^cP9(T.9NnUUq^2ZV.VOumqZfi-7u(^F[".Km6n4K!Kf +%#LF;Pfi-C'Z<\:NE@es`Gj)\FF8S9:AAm]A4^7b]`2o&,.mc/`,YN%<->)co,^!=SK[kZLXs=BZ1(o<-8]hCl@FT+2TV$k(Up_]g)ppK/l=Q('M"s"hVK5-Z9l)a\/(\3al^b+SB-<(?>I8.@Sf=&%TB9L?/_A(W5YYi8$\`&J +%R$&&G=1B(iEc0!"C./@nOT,mqYLE7]WZmIR9gJBElHr`':s;_qD7Y=?_Yh+[pgOY-i9$6,E5Xu]7+t5O@)S=S#/k!&G,gWQ@l]/O +%`lPQb=lNRo41)RgbK5jb.iFSm,&:R@5\77^co)'3,(_h[&VdeA(#9VtaXH(4R?oF(,Y(T6bk0^B&jd":oY8K:tpZRS9,_T->Tg$#J_"rG)=kAU6%^[,K`.uYEVP(po:Am@/#W(0#PIaAmm"[M)o*pg;M;blKd%A +%!G9`&6Rf8a8eRgias>:<>MU^cUXUKb\lm;/@FP[qR$?6cqN`@qsMfsq:#(;1,Q'f^Gj?e,H[\ji@fINq8%0ZX; +%7;[DAEsJZZG\gjQ<*++4fYi`S8hP5Jg&d$B/7bPQ(Q>=67Sa>`.[5pfr_9(.,?ZLMY2A_!T5%'(uI^-VJ3HX#*Y7Y#nRY6QNY&Fs3UHAq"CYk#91<% +%*d9ZI2mM`k5l@5&!#=UK`QCLfUE\Jd^jXMG@Ga.c,R;e\[;.@WC;$h0%;I5b-"f!fK!hVL5-3(e_g\J5@Y(P#?"g%0D/q-u=&6SS +%ILdZBi\K5m,tGAIH)VY]Y&U*s]VhMtXHsIaa^8\#dq_")r6cB0TVcel2?L=5"-[6WcLO*kphSt(30kT2>)s*Wk60;$0,2W.I19Lk +%U[0XAEN4:$ln#bqc&rB;+.L<-k'\maH7R\#)$iaps-Z:4EUqI>V]A3kiu=K3*tQU@5,P!i[S>K&5)[7P7Z`t(U:L$oq]_`b@StnXI"o,K.'ng +%+tMM)E>u8ElPWdB24:[lQ;9=K#8[]E6GUUeBE==$'3XgHC`0*IT4.YcP"!lDP\F8N,W_s+fk3X5eWe&69Li[RjT.i@,b1Tk!1#dr +%;[!GlSL);Y`1le+q5(C)9)o63oO/3I![l&D5a>WeWs%U3gr\SbHe]odpI"j;4q2G@'N".3(0J>W%_.%Z0q_\09]Q=.rZ.Ea1:q:P +%BFS`[9JZ!rL`i_+=LV]SYoKD/g1r\jfDa>:]=HG](/PBiq_dh3Q4_9*hIhT?0+eEi0Ir8I1I@Z;;/";XPqUo]:.]``f"A\:3rheP +%"m6_/=WkECBZe+#++\9e!`-OhI)QIu6_2i3I;onca`_'HY;CFHA=C-nZ56MY!lM4dg'0='WAD$>9>llH0D\Iq($G(U7gKXE/;a=&/d+U.tk`(91$h?,->)jg,d-M"UZpNj$s$Y1]Y60ID4:cbQ!ZU-b9N"j_Deh@lp1rF_R +%fB`dCT'hET+$oHM!;qT!Qn10(F-Wk/.$f!W0NWit&GCe)37DIb1]b^"lUj61dfkk-e"Q^btW9NLXd<&p5cik[($h)bd,X9B*QF$m/S0I?f#D>2],J7qs1ae/\$H\a^=L@-ON7l`nb`Rj%8SM8( +%@^6nL5V9VF3pHi284'iF<8YZ'PgV:eA%Yrc\C488p^E6ri<;cC\W@7;^,FJ1HnjA:b;CtYl@>_&=9n:lk8iHd?'TJa! +%=pp'RFPSimEXP0J493-OA(?rBJt#A3Ys%\JCZdT;G8cFCI+Cb&._C0T%t.3!YI_MJ_+ZF&0TO9U@GOg8Q0`su^39F>\OIbC2a97B +%XLr<.l=_'@k?c^DSpu8\0Qgn0O6I@"7EUl:i1?T)a@ge[Z5$-RU0^.$H5+0`a#LLOJ-.#WEXcJ>f6(hnN[PYiZ<2HNc9.?N8nLP- +%B9E0Dgl0t<3#&97n0hr9JR[UK,:m:bEk%,<4-c#TPj7;O;fMu),[b;+o7==mj)f5Ln-Z?4cXe0VB1BHO#k$+sN-.s+-MCin4\3!N4V7]hfG%#cZl1C;k8@0g!-n2H*+sVb]cA)B6[^_"SeDb!#F$`&##Y>K,-!mY*@VL#VaX%+d +%Jk9aV!k\ca7u%V@N9Xf2_2<7Q_\d2LDM,hbJmgd=IE-NH^t4p'E'D#/TOrL@nB%l<`8Q(%!b?HY7[[A]#VK=^><$Yo/-k.ToHW]7nu1.AcMgX:'g>Y-KQ_HgO"d&C)+%:e^PrL3A^0kGtSEZtOd +%Xc>*f)gLpYbT5gLhSo)QRu&`>,pT_"a3@P;$eB`m+EsT4ms>rVR%nUHa@DZ!;RSB)CbAo/gs4Pq"Lh$_#2&2'L!FsHbP![+Pu3Ij +%OuujE`4c:?8aS8La-o_Sq#V'S\H=UgcI+HFL<3RT"\Y@[?;?kFkr#ro6*#9)O=TQ$$:!Qg4[MH@pro/bU%\Rc>uLf:7$jb[eq-)h +%SbX,tiYKGD#Ee23q-*neBF&SBN-T[!&bhd9*E`EWrdCD)SEd.*"<_NZhuKMR`W/J*^O0)in7lWb#S`f\FTf10Wh=lui^u07edXef +%GYS)2-GZYEh"WcU_.I)>$hOk!p#M-l/W(\6&SK-&*3AO$YRP!pLSJTB%tE$u(2TmgP/gnX6Cq;LC:S>),!YT%]b!j +%TK]tr%[)mW8:We(gG2G)%+Z*`k]KfA56:nclXA0r6E>idFG@?F@1j^,Y1eJsR/*D\&hlD>_buRfqZD(\pF[S8 +%E6T?Vh?[A7Jbt,bI3-KjNH;tHO."g@k](!]*)W3Y6eE4G0Q3a6^7l6/KVc")]YiKXaEIQO\W$hWAHok*UKbNPr;(O@"h[@M5`^%P +%FpK4OM+,"J!?,<)o?]&!i9#gJp<6nKafB8?BCao4cQIEPmsfsGDm[=6?lF:HLSU^+W^k$1"/k`Q37qd=E##5CN9Ge'M!jH1Q'ffL +%Bub-[Ya`mUe`iMiO>)((.ci'sN^:YnF]r`O7-K;EUs)U[%l8$9Md^N/uH(3r%i";cnd(mQA +%`OuZ#LV74MkL&sf`N)./UM@*%&oeCrN+KY-o/6kV;4Z#HI2T6",K;+ofe0tpZ2hn4@K';J?p8P-5VZjk=kr]F_(ZJ>-<49E +%g^@tc>-:M%IeON6Z[a,_[u'2QYU9MV=?,XY^V`@l5^j3Np;rfGp"h%_2OM6oVf)4J`R@1fa,J`-#0pGYVLVgeniIYV/[@X#cK-fr +%eIf[,@h8K&bnFKYObG]V3c]]OPBg=i"N(0=Z3Q!^O3r'=<3b.ok6h)j;H?d&Us+n_^nRi+R?VGb(B^7?/DoN]01/`VlWlc,q$%1l +%SZ*)!YtA9b)=!,H(^hs6*6R7/8Lp,0L^KN&E^Nl\#L4.:tL&R5>[FOS-E#! +%7d]cJgSUl73V;FSObeUDIVeimXFL:2hs,:)JQX'q2FDUpa^urr?(59AbN-mi&=0IpCHt."rrX+!C1Ri9bg;a./bVFd'7_Oi@/RpT +%n-8a#O)+B>N_9msQs#[#]SN5%Z#@.u#]j+W9T2Fm>.P[MU$Qb+.#sJrD,Ab9",;?"kG&Q(77$20(SOc"FSA6E0i`TV!1,Qo(-U)#q'%qWCo-.]<-\DGoC?U!.9`:I`W8 +%A3I!P`a+W,fWh_:jVB;MHhqTuSZf6/'K&C?=%3_O6KeIZ?5^RMAddAgOscMG`jm%sLkOLB,dLA'B!>k6E@n,`bXnogFnL^Od#G)[ +%55X^J;+D9kFQ5iC=:q@+e>97#`qU@B%RuB'<-amC$=qrVNo<-t7=WL^[n(Me*T]eiTQC@6LpHdK35FF#8%n/ke(p09d&+HDn:r#l +%7f<9EQZ4.R9g&J@TC9ra5gt?a2*@9l^u,4qkBn%:=6]r=JmVPqFgY7u-9oQkPS2W/U1V#;bKVOd_FcC1iQ.Rc$@CZ#=t+CEN7WS] +%q"!gtYcn;+qujui,U&FJcqnZ,R(FYO:P0CKY/h=1--aBJL,_3IsmQnTRNIM.D9;)YET?";M`KnmD\6n(THRLK*Q#6N-ri>L#X[T"/H1d[ur#6nlrL1Sdm!sVLpg$O%no1*fl9/P\cs!h.Qj,n!fBt(iX/a#7S>2bbP_\,+"'V@M/!r +%s+%>ef-'L"Lc\1<"=FtRWB;qmXk)R=$t(8mO&pS("$3IQXH:"IME<&sRE>/M[-7!pM],^2XVj,pVP$nGT7cJ2nj8^Q(U&@"Hp6mi +%UFDV)(F(mEnQ3M:`1L2Uj=2CPJOm[]j7YnBb_TNQ\2DOI-Sl*;DV#9Of&B8Gh5MMU_m\%F6q'R[,;Sq9L(P`XBY +%"rY3[.?P8.W[""$0tdhGKIP +%LiICY.QgSphSH75#%o4P/QloB<8biKF7:H"@_WqHVe78kg>.'F;s"?YqKGqiR:@qCpjLZ'oX6jSFogcXWZ!9M!/UCuCb#2Y>r)nUDV[otPJf:X]C<_m:3[`&Z/Nc7Nbs +%bX&N(6t=c4ie#U+CP+Xc3.$*;@O$]%&NRKt/OM6*r6Jl+V75en"05XKVTHa0f;6t=5'`V=.lP%$f\GFfGE4pt1A,[gCW4@HiiV]B0"GG,:Zi%7iQECfRp' +%rDPHF>!5=\B;lJm!d:o)_`K9XCKV`pd6JJW`**'K>=o$t-3%5#:,O"2=4bu4E1CTZ?h,7qqrJ41%aYR0rl5YoMeY!.J:pIf95gOABupcs]b`uo3L#-W5S'.C9:8PAe>mKe+YX>qrdbD^nL2<14T2Ol+4Vk:Tp +%$9'.+;BGT.qUZ!*?rSekaU;?,EO`m,6?m<>VR"e$_8/$F9O%*N(hCnq)NS@IPI8Wp&/_%h\dtZ@,L9gVSMX-Kj^=Z,qph$:rJNY8 +%K=1hOg[;UBK0LFUEI^RKg92)&lDP2VZ;)Il5^!RofWd5)%/5g0Wo]jS$W'>&'AQ]ak.s^LFACRQ?ZY0jTn5;hJ80@X,#l1^Pu"PEfh4PH+ki'2fr +%Y>[(odB?oC\\1<^a56M7#cm#7!%1le>@;VI6$\0sr9N\J!5]p6$=IdFBp8k51WWK_3Z!A,(GUsQCl5^Dhq%&e7E!X[DL>6f%>2>.6Js0UZkkg"S%*PhN"`6!BXZ0aEE=QpY#)RY?QMG_ARq*5nTZ>1@2LC(LQW*n6Y[*^T8GJ,3U0gO9;$`BY+3r?d'] +%JIP9tQ\$:T`\3&k7GI)D>OV2!cmFRp32d4$ql;4JC*tODUeHh3K)9<(K2nh?Jg(38.N^N-4EThaq7M?ig!ZVg`.]"nnoG.i1qI_S +%RW*drjX?L=3=+&6s.QPe?'aUMkDg:I]97afhol=FE$k7d\B=OHY]e+^@BH%*Y*+?W)DWkiqY-"^T[4?OUQuQ2b_D2"+UC'@qG*"`>DV;-Uh""Jli!cXb6),d^=/-1Jbo#e7:DOl)=9Wu"$3sqX[d_lJ$S]Ga`#)=(_&YrA'9*urMt0#?q[a>,K\cgd+eKqb=k][]KcYW2.,;%k"@Rn7:WIsboJ8/3sV<"CMO&V6Ol3FCFKjBg.NNgUTWcVh%,iTbm!ftR.CiC/QWehl4^;.0d +%C1>8IX,56"%PsRU\3[LP`6eiE(-q]IcVWS/r/_7U=;:m=C`KgQB&C9&5Z;VT^Z +%&X)[\jbi><_0J[Q0Q2dTat5=_B%>2U4fu_o.P'1)%9c+TY:Xmp7J49rG%n12qs/XAF\$IMJP4O;XkW<="_,U6ec\s]/8G8P!`^1= +%Mt//%R2"b`qZVmk#)GUG%&9OU^Y4-](?2t&P;!."[:daqjT7&;ePG&PLk;gSCP0T(-RTY`U($'`]6FA;=(H5<5kT;/NAR1FCIE5b +%,$l)'g%$@uoKrjD&_e.9>9AK)O0Ng;%12/$ONRhNQPcl>&e?@_'S=QJaNmBXa<4q@a:[M*W;VCuA(]ujpo]0Q+TfYO*.K&MHMp]u +%@H.C^r>8aVj*oW&NidMM3%h1A^o4AB7-5rG*j.(tmP9"ML/j#/AF98Ep>=K=P*Q*gDqE\YaOqd[J!C)jXf]qC[[@g,ld5sAAp`@] +%[0IS%b*g8sWj]VsqO?"ZPYXGt0n/KV*4[MQh9?iM*In(tSQ]b[Y5UHBthV4Klnn."@Oci?u4f"*(g"!KI3l@d:(LJPr'NNN#I9CFL?3-U@2K+BLt9YY9bJH:%f#b#Lfc/OZM$JKRbN>3TQkUiG+PY6WiXG>>S1m*24VjMq:(QQXJ4K?G`)d3 +%!@G:#C1l'q]j\97/ma)F/Vi:8I`:3N]9-f)-)(AYrp(_f\Qnl?\;B%\VC +%bsa`HXlMo#qk*$gf`ErLQ58ihnkoJPBSG?%N9p[Ca,rR6&jW*!1TFLjNrqo3Y&Cbb7J#O&QM$d,N^6Zg/q=l,[M +%fk(MP@65eI9&o6\IB4Oa^26c`br_9bc5<$-<8W]PX#dnBaT>79!IjjDYrB3DR'"CS+K7JPGi[PtRC;>DTq!ZD"*Eo[^u]`,DHPZP +%N6JkW9WK!r^s2nLXR/FVc0@+fBT;ajJ<'HCm:9!RI:rX'J@^S9/l`DGR5Cla+_Gepfk=?V6)`JdY@9%_o$G@Skl5AiP#?ttR.,N) +%fgEg)FUI7/rV$!aQSDQTUC.8Rm=h)tm=1%?/OQ3FKmgQddA'PDt5;' +%)O!-ZZ>/LaA6'%8%:iKtg]O%QSZIBq?Bk*XX;SS2STUS/6jM9/RSKuk,%ENR7J5Hke;uc4k#Zdan&ND^?U-FS,=hj.=,DaX.KK:e +%WM=T279Eu/'!,K0!C9uUp#YGVI^n4%B-$&iH0fF6l[c84cI,fOoj4Kc-/9g_nC+X<5u!*D^KchiA]8oq\N3VJ/Sk1H@_S.L1sB/, +%,>`O[_BR)`)0IAu,n*$UCA183jDutaT7Y/bN&W`8^:i=b^sqa^!_*=;2;o'aMlAYLDkop0`hMuq(o>FI_[aT:?SW.4PV?r8r&3D< +%Q>IuW+I#'lYi_7t0]$pJMXp('N_O75bVaB!gsT*B?s7=HC-\-f\8.qejlp6&pokf(QR;hs;Op=T^jMI6@Ia88HX&^P)(D_[GDATe +%a*RZ1h+,mLn;`A$(;(/fQKgUP3J1B=5^u;@G6*.#H))c,fF49;-Lu^cj3(!?87XTgat35'b[\=*jslW=VSsDUS8J@%1=oa_5q94R +%Km^L.">!?7!g[+F"=tom*(en5'r9!:]OK[\["@ePjTPlb'GiONLu^52T_gDuq".Bi'EERg*lUks*BmFQ6f&8BC)#]:=l7@=>r1eRe)-#^ccF"YH1K(8T5W6>EVY`m]8pTnr%dNEKG-PaPb^\C +%_H;4b)28AXXhsG/b$]OH^9Y$d.o-QPVECsp8'&iTf70lpX3C)Bn6kZW.-]Nlgu9pJVsTV.(&#*RHFUS"dRfk_1\m#WUcH20[mfjK +%9%5G<_7Ja8NeIiaK/ng]XH@%-LL47(*Y]%%Y)7/+XL8TA5g>*<<;lTL`h;!(OUf@2aWD03B_?b+"?+_ +%0hLG\AH%NV?!HGl79F\\"s2aL!^&moha0_]!A`g=Z0c[MJ-VN#/`8)VVXBT.1g?$DY99S*"<#s+aEnfJ +%i:o'[!;@`"dni:lK+p$N!@^-l>BkS,O4>-Gn8]W<1sqltQ=_(m55^^_@\*[%Kn$YXRt1"5/HXoN>m,8q/OK`mJg($4^A?HJqnU=, +%,ikdj(-idM]80bG$!*490/B0JjqP@-"CE=f>/^:*Fs@L@8IqD@[=Y?2\\K9bN4a%_)&@-$Y`<$Xj:i'$Td+50**IAtCt+/Ep?#Ka +%Z31RR'!Dk^lCg16db&Ln/mpZH(YEfUU/5P)5ncMF1Z6oMK,.?0>`e@]]%-]$qIibV@Q[%XE%Q!PjYMfW]MqoH@oHrB##kJuf.Z7^ +%cUbSC!-I%3KtRWTc[\jfmK+#H>"gH3pVe^l,Te4/$.E_^6hH8laO*](=^FWr)],\9V-#q.ik5_^hC&-FY0;/Y\B"oCGssC]"r%F. +%KnA[h16JZ!8h.UfN-s2R6BTXQJJk5NB4.P3%fqaF:dX+U&-CIh=+a'aRfmt=7(s@)EX%nHn951`JG?q5AHXPH+(DL2*R,DHT[,fSc4MAl!=rF]I++,Jp$lUt3N)G0K5.P(;e'^%3B2T]=B;k5 +%@2X7fjT(jqkdh+H3*A+N!\t2@+p%#nE(QbiC^"r,"^!F\<4=3Ip#/Vf5QY+2hPK^YL#"%$I+SO]62/nE1MXr^5&cUq4?Q6p;bN]( +%nYas^F86/-)>K>8R)kh2cbUo3.)YI4E;s;+R:Hm%eT<^dVoFqZm:GgfAWMRm2RD*)5./qgikD^7U'I(0mVk[l,kDcEZ/OtO5e8Q` +%)a>;Tb?0'I>THs5O%lbYFR7c,H/T@UParL3bNt?^WP@,1i%a6X-?)sUPHq+oE5$=SbsZ59`@[@(3p5mC:J&Pe@F^<#5T'kfI^s!0_pA(2rf7DE#f_ +%*&:*#G^gL@4-+NrgN.^BOT(_cogYrLPm/`$/Rp1**[1VpnU?-mk1XWHCBTpN3YmgV,,_!Mn*o3gg#NQjl1!4K0UsnrV,k@FXDSp' +%H'&[#2>&JUnp=-tojo/U3.$b#^!6V3L7H)T$crRjmA;6M2[b^2XJ]Rm`55_d@4!",a]B-/-[@qn2n,mBGi`XfI/q9U;*Q**`;4NK +%?FUD.!1+RVHdP'?%+TF@8o!mE+]uu(%`cVeY0(Bb3I>s4$A3FD($K! +%aj1t[Fg&0o7pRUN>.se)eAo\tApOqP//^5U_+=DokQXZ_K??W_!m#r.'H;st,D5`i*sk^4i3Xre=$bIqt:;i,>+igIPUVPQW'^g\%W:,F+Wn(Upfa%qZ4>eb5,Yrl6AO3e-RH>ii<&C +%=`<2[V5?^$.h%C^$]+e"ku(/-\9R,l[4O&-O?2LI;V,(>^6(WADbQ=\G7rik;Jp]A%/b4Z@GXKjQ?Au^W(EU`1gETo@i!uak;i_F +%T(<(d4%kTG9 +%WM4@(_f(+4[J$?\b@MX +%C88kYP:9BOpVf"dFV,<":MQBYQ.mM7%=U=ZGODTg`d5DePV>Xi^,DcYZXpUsaGc&>hAJ`)E!ck1jWk"cQJqXD!dMJ670'79=]N(+ +%*FTSjq*=]b-3:>7V!WKo%r##cNI;-d1Ou_D/_6+g["<7!MVIXQWgd"-6aHI`>q2;U-f8V*'#.ah6u!gVQn&FMDU,3H9ds3(UFbT1 +%k[4QSf4bEg'YoXOn9sJXH.HK>PR;YhD/*Zr'/(M-/8;s"go0E>Y,*p]be0DQ89`s6&7/t>(UMS5,-^bHbt_%VRiNk?nkhXkNR_lH=s`*g +%_"A%,<-AX&TQpqLY'XppA's(V*BDCWe:Re"Z'GT;"3oBXi9H)>\LZ=cE&8PJ!Zp4Xan*RVAm5lA_$Sb?,A>rFVG6:NE$l^I!r`MQ +%gnPA9B<[=(E(=E%"]Y)X!^^d7j[5V*hP6Z9@b94:.b-]m"DWQkWiT=;8h4*06L!^lHc\)hEdC]FlV>Cn=A*M;AXAV1Qrc!9[grSZFJ4C\3SUli,%mY]TZZE4=TZd/M'3)bncA5ZX +%)=I!?Yg6QJ@%)WgQ.0\?/-[L(RkZLe6b9D=Rd*2(@g2!NV6*^K:OLAL;X0CJ"&/fdLiUD)Fr&@jje+a5-b0VIB%\R1W&h +%(*-eg>r%V"q)2V?qODVJBX!t%b7fFZfMfFFj(AOXF$u)kSrS4KoeqHsQPI5NV,kX7Ihenh3bL.cUUg.TdW5_m`<*&lj8KH5\9IS# +%M`h):Mp1!q+^?S_/URPul\Nh`A4,I`iPq)b5%KM('6BR-j=Zu3)6TW*c!^=R(:eNY,u6(>>3jX0%D^T#ac6,7\!d3!iR^`g43\n> +%CcDWca.6h(a1?IPT'TAVE;JDpKPN=pjlH&n7?"U!E9:jXr,D\+NAGpPCaZ0N.8Jhn +%X6V?JfOl.;]4kFl(#\E$IB7oiSi42UMjMR]lNR!A,;-ETUG8L*[\J**C%$rtV#;hsKoqnAG%uL6DY:&\F=>)P!ou.^3]95fQEgJo +%mgh-8jF84E-Yltgjm6d>mK[.ph%p+Wc!K:Z46+d^2C7A^/`r1#S!'(W?cIij%3kqcW`dEhI#\)$=kp%8.AC\fXi=-Gb+4,TZ1OkJGR*&0kq_)5s0es +%.nF11E*o1f?Qg-Nqt`n\G:^K7(o;@9,4T`.)6ukM21bR$kn]kNrBMhuh!BFnl%*K/JZs6qjXiS#pu-BU/TUZ#V@g5m6&dL:@Xobl +%^!6FeS?/B.1]VHTL&ugKJ/O7P&WB.1h\\lSV,MMoBNSF\bJ[k<2-,I6YWpqpi$kVnluCkXfY$_Pg%p`EB5k1Eo'JVh0`DuW.,P*( +%QP6RXT>AG"]q61c$4?n64iYP_W*I%lL$oE,^YSgEUi/30kqep)@'0qQ>[e;jQ*9-!iN"qo1=#G +%=3B-mh@MJkN_p<3a$457qpN[!2*]>=l8$d7A(p1C3e(:mLEdu-d*`[G;DF=9W^Oen!hN!n:flc=%/c$-0Rk_< +%0=Nh>C+=`?\.moh7%Cc^5i;^OC?#eq424IK-rU-)Ld#1=7Ie6?PTYs5gE.64Q<8N1""X]B]E2fBJEh,PYg,i]=fP(AS78Dd=UJ94 +%n"A`I$n.LpS]h-/?)J?Z6,fh4@b1ZAZ2QNr$l`Z9DOQ)=Ka6LEJ@_ +%^<"j0Dh*&41/:To"f,qB,AJ:YBrsVTiL6=MShE +%br^/eH0&!"b"Y-fDY=>eC[f6WUXcY2gKf>[IBTl$K_.gIApD6Z^h^!A"d*6L+:TmE1Z6Ye'2U8>,6rci5:qrV%X)DE&5\;F9gFFN +%>tH0U`IGbWZg9ION!2>jGB4@8>T\60Br##c`erfin7's,dmM;c?LDbN>A>5j?qfm*f!"1E#[(e:b4)LBmK0eT4i5P[&28]8!k.K@ +%"F7TZ*sEbuT#'abgo[O@!jt-TK%hWFTWbAN[ganB#p=qqY.->%cpDN^qbl)&&)0,jV&Q&*'PpCYKVH_]@7%;#D&H)L'OOsH_sji_G8Lqd'gukE^p++1mq^k8;NZCAJ^a;/3#,0SUI]%#P@\W=@bd<=:JE9sm$BpIJBf96B6]sE5D+se)e9bJE1qo_#9R72%EV^5\<_NF3,W_u>J_R`V)@(Yn" +%l!+Sbl,e03L3^#",9@I6$3`%L$Q8=X;,A:+WU:/bU +%+2^bSW@:_7U.#H*QE(VN%29AXX)S8`HA(U"%_b9F:o!]\#F]].Td&aW7+SWeYAgHNI^tG4)K+,0fnr/<''=Wi"dp/7Qmn^:aCGc^ +%AK?/P!%IZTC&O`!0<.6:oYhRQ312N>FAjO@%aIQhn?@@cMqR_"In)hEqD1h.LDM$<9k?VX[_2NH!]`2iY7DFh6SC\M=mK)CaNBq& +%a\H'[&r^r!`MSU'nGShBm9>0tQY.gWkAe9e_Nu.\@F,K2W6!oJ[4p,--,W14fmJTR* +%[4Ak9Oq/rnPuE[*JE0kUT_atg4H+F'<60b0m.94@>.j+fSB?lMlS4HTE/Qf%h-[Sn_QL@lDIrK9L;,@[1YjoYnE-1_@mfG]o(k9G +%E6YLp#tD@'`erA@_IJqLL!L;oNqG&^VX1FpbC&9Y`E#H%4RU6WbeBqk+o\!;IB*AJhVArTCP5_-c05ToMo&AMIam1S4$,CXeKE +%lUT)u4I&T9k'*)I`;CItm?k-/q^0)hDD"G!u;u+ih-g9RVWHmbr(V!KQ`OBal6U2^7Qp!h^YZ"SRKcEGNNc6 +%:QFB#*NW`QoI$-EnA]DVA2ZV2r3N60$3VqZM(5)\'#;t#UjNmUXT\fgY2eFG87AodLH +%Ih-.?>"[H@'5?1niep8#U>^Bb]1[)6Y]s)NZEVktTUGI'?!&!a]O:0scFdQQ6#`E7]%l&[[U^Y,EQ:D?FU`hUF3)^>1=.!.DB+C4-*1 +%e*FYQSYmRnOJ1DJA:0U)ST4Rg_thT9C3YnT'=&h]Ig56=k*%HnkK@DrC"\Wu#+#G1nuP\$1DF6skb` +%_V:PmlOLnPFHr2$,/.Al0LCJc0u&DG9FH^C30n!#"\p&&^;JHh/q$tM^FE&Do&p-<<+r%gi%Ro_8sH$d@"H26+j]Ti?k%S!VX+r>)8o?JFG@HflTaBJr& +%2sq+N(*A;?Ne>s>K*B^SsH7j;6KM$hsE3+eqlBa02-1n:[Y)Pd0B%b+l)$["*`^dQa=C*C3`j==NO +%CHWQ-b(>fF1ec10KN^t:VJR[ZZNYIL,D3#hh->en'J4mmGrhon9@MqjjfN$d7AnG[$`N;0'G)s&=/Us.+K#D4p#Q[iMpS($]fGsN +%K9RSOFBZ?1gF^4;R!N*e2)GSaPLY6PEAo8!pQ*K73I\lb_>\:qWsRSk5;-&9BYd8*DYBDJOm$bL^nb1icCP?%PCB-_T!2@\dN=4^ +%k"_4Qa<[f<7_6j19b%?k@tGpV>:cADQOTNJ0t^E)?i+Bi5Ag+BCsi?Yb5[[?;*+MO&t1Y%;m+jk2+dW)c\>Ra/Dpi7.fnsEJW!G6 +%@Q"M=C`0qR$asfQb65?s]=jrFTV[:%2=OF,P)SbQ#C,ZK@9r@LFI8[/ZPFQ=)YKLca6PR4HAo*S,JMdgRM4UU8eI!m"Rgh!F**"]T,b\LpkkdGj!6g\_)U +%F/kQ%Fru!I7kC!M>"6VJI:d@;_b'!s-,F^$ELMaX`/XS/p_1P,31?(7[UE72RoV +%Up/Ci$L^dm/l4XPC#VQOL?\j*"=ZU2[gJH=CW4pb!QKksM(6fAQ,[9BbNGG44E+!SGG]GJS?8Q'%9@Ks;;1#G=1)I2VmKB3mD^sh[_!SoOU(>+\)!7U1t +%_8Gk'Q8uI*GRI)."2CLiI&F9CDUIS$QH,^R`$8%Zih^"o&DDZ40*gG4 +%bIZ#I0X`3iB,TBnkToOfb?/Y=dgSPF7@h+"W1r2:F]FKMpUo!(o[XG=7C%R>qd5,qF^\:NZ8g::TdH`JiPtb +%h(9"6dEQ^N/o5In2P3)a?b8VUN5(\&eu^S!I:5hV'faM!lKW0hssI$kcVL7@;Df1Sj&jgK1^YUdJ!ej$"-TTYbICU[>+ +%K^N=V``FTq73u2De].jUa1?epln0+72t8j^"%t3V+%h.6m=p.*PXu'oX[oPLqeTb6f4LFC++o>m&q7JL)[eP]c;q_ulpC5MFN5%2 +%k'i?Fm9\P?p65:`]Ss,S!j:'T+"e=:&eHiiY<:,hNSSPiUdZ(EQY17d(e9!Vhtq+pbYFlpq:M`KWOX0A<@cu;CA%h4YcD8<,"Mai +%=HY9!gKg-1Vr;A6``SUqDlWr&/PeTn1\b@hMT,J]?N.!Ts&X^Kq`k#G5JR6WT7?a-J,&u755hr,oW/#kqSutBnbS%=p\O49ZGuDh +%GGD25(-e$(kNS[6H\S(JRUGP6aM\$k\t?Kc??,m%9*%'6%VU$JYj+L4Trruqf*4R+?sXB>iR.o&i>s[(Cseqa/qMKQ$&Y+IRE#gB +%:+I)__/@r8qm88X+_$`H?i#GZm?AU:ZZ@r3oBj,!0%/E0nQ\M]`Qk5JP=49u%l=1R3*L'*HuSDe#8d)V54$FdYCjOrNhhIuni,de!BmV'i+>8*#\./bTE]AmHuWHW)N"d&+4/D(a>1=4Sd:u+%[_$)B\.b441Z"isQKSWgY%7ca$Sqf`2[Xj,sele,m*@'^]Y*,OX8fF`>,>2ff"D2scIBZd'/#$7=F`rn@uL\0rOV24miY1FTb(0YGS@V;%7 +%[kf:'l0(g+$3b"(")sb1pL]k0gQN)Xe_NYN=$UsQ_R'R"XtS&"a"G_kd/d9`.nC8k@ak/UWUSV-[923na@VJURN\`'K/5\UO_o5) +%dL-hYCQa"k$V'U&1?4k9@E#(Jod$6\$3pbK6sDAN^Ok'r#=*7cmLlcs,-K=i^m!@.QI,=aG0F57P"t*#g&^]s]j%'sf0_elQq8jR +%Eq\H.6up+$b>Kd``kmnd=@:'`qlO#8^4I:uU,;=")(HBX=8k`3hjp8J+SBBg9Ca-+D8@ +%8&P'FZe.3#SmJaZ@Sm>pNNq+*2EA%a,/d^1AI,5]k7^2;n,feS:.8F"oK3Fd=q9>LRWj>#8J5:dV%/3S95!((q@%J2je:hf.I=qe<95S-aobWO7=7Aenq7),7M\>l:MFC3da-^I +%C-o^7@[e_Z3"L*k'QH0p[.nMtncS,bY9mN +%)%EueiH%%lIg!Ud6kOL0j@Y$I6bpTW4-FOcX:<[%l4Q]5WfIo/$=BBd8F;Ci=^5-s)0,50DZ(]ceoBF9-@&]B,"T=.6)?T*eFY=o +%5jQH=TGTX3inVWYk[cj#b/"KskP5Lm("tsN&r=-;LYGjX)/;Q,teoT,Ia26TB`!n +%PVIQ)kMT"&-W(sh1d7)kKnpalYM6oSId@P*T$M/<0Uka!U^9iT5oTdN5[Rq&EuegcS@B<\MWgY4dMQPTkR>2"W61W,hu;"PGdc=-`Q7 +%$H@DBY=u#<*4b7!d4=JVR/[iM51C&@PA4N%0C.R`.`[J*%orQk9ek8Gp43;T^KL+!jT:hsgg@ +%'`mKB"R"p?[QC4>I1DcYWVPVcD`l(UJ1#p'7LiTN^V_>X"2]p>$hrH/]idNZR'_pV%Og7f`X#@E.,AI1=ccq9bL'@):3E]J\qI!1P6kS$D^%M<8^rmuKBpuT4 +%Y*M:g*oJp^\tq&Em)K7R(EA==M!KN&B?q8]0 +%)W*jcCFq^*`We4!I,T>@>6df#2>;>"@62=X-lYAf=NAu*pr,bP,V%Y<]0cSQ=;#YpOhmkgLW% +%@!O+\nb$a"aU7O1Omf`j]A +%WXr#SH)QbpnBKE?3>mgrbG&;<`ABQiKcsT9"gZ\)&+EtJT$:r@"MAhhod!f"s(nsLCm&\`m0EZo2mJeWmY)dl$h9+3+,X7poVOU- +%"kEalgfDI8-b)*u591@7'?,?bM$k@odj&8XbY-et);PP)0*O_BQ8Dh@O;l@s'g+I4]rD+8?mD]gg+Sm#aVHS5U/:2%5A2:t&m1gh +%mNa6u/CjZ`?Flb3,>&)M/UbT)0bt#U?n)VYj]F%:P')(*$'P+*Jf6(SS9#b8d`9lfBg!4K'Q?]d=FV1TalrO'%.C=sE'=qDc8PcN +%JA]2Z?AA[Dg%YutPQIH:!2ulM#*P'AEZ*0p/GHu8BRH-6&Sb0A)53=YFIQ$A.raU?.teO;^*;b=.3tXh9T*L885@&"q-CE3%on3j"[>Jn8De)SWJ6[r$b635bs42NVVq=s@>+=nXYU +%G8C7nKOnt-`e(U-8L[?j=,[mGC^8].$CZ*qYeu@R=L"P>iu%"c"7aWa"?(8^^UoC_;Dpe!Js4%/?2 +%gQN_&C,`cP=)1BVTk,Cj<22[ZktfX9D'0$JX37LA)>+CGLcMMahZ-9OAm-mrlFnBD:=s#'[5?!0Z4uH6j?Q%n,iApteT!9F2hGFQ +%C,Lb29I/8JgXuC.RC8r"MI*@Oj8k`jTV8H^%IVp`oYaeO\?@c.V.4;$Ea&]1-b[sXl\)9W0 +%5TlO\i.;`mrZ%=[M'\&1;aJ>n%JW$b6,Pe$AFh3#P+MZA/N05aj_)Q)g#K`rp$^H+snH72ukDmb>VdqDK8bUsl(A#uV1&5Vg'(7b"*$I'@KHkPT(QZX*iO +%7^fZ"^%i2Mr2H4-[>=9bK7\P0,+f>"f2*'.NP +%Z[sn4@B9cthdHmX4Pljkme5ecf%)E/gK_Gb]^0B`#N&GY@bH:C#D((\#[tU\UilAJY`HlhTE"\+k*N;MTnXcC;D2"VTH7gA\=-oPK3pHKl$"BThD1LS;%/WMV(4SiBQ*`ZKNn`8.-M.OL?j+LSV]na]Y':]L1B#W!Gi5KC!/H +%&1)n,=IP\?$uVX#Fbr7WBXrrP&jK-I*`]5dI2Me*2GB_Y1be347RSpab1gCZHjS(NFVm@"j99O +%^AAGk.li^`.j-@/]Hj=F?,Xgjct`1I!>hh!LqDt\6-YpqrRNhu#m80-\s(Z:nkU]J2Ge0f5-q6nS"Z.%,C9J-.huWVJ/)Md<\L\;/5oXSL-F3SaPG#Ea-j& +%S/QkZ$]fC=;p#/!iVCSPUaW2K?W*_4Z[Dp?J5!HrH,[S54#dNfgV/L5+4)$-_;Z769s_K3Br[u/tB85SCc#hGFH:M#)c+b9ja-bF/Ji].MVa\8ZC.X_6OP=*3c'sI1%jXqBm2*V>9[+B6FjnQ!^]Ik/f[MFM4)'N'[XP"o5,3Z[SHB2ZRU8K?d3*W1J1k3^,B&cHq)eqg0gi3W5RGi,U%g7r +%3_Q2JO<"mU9.-Bgk)L3;8r^2VPWR>pKH%'S9a=rJ65U7=LaXpBet+NCaW[LX3Ib)8OC?9(X2A>D'=-6__:8iUYPb,+$Rh2R6h=MR5C=c1MY%jsN&Vl?O#*Y+dt62+MO +%BN9O1%C0UQm^k4CWGa1F=8uO#5I?4>041WVMR"sEUD=F/W+^Q&/9PG-LrLkXTfV>A>9m$%^'`)?_!&b1J.iY+hTEZ"e931jJh.g] +%V;0:EE@<\JqDA4&a^X%!s(m@Dk,H%^s6C3?WT#I']df#"ICo&]FTtJ1bGGPZBP#o)r%L+_S,6#d]g+/F#V[M4b:d\'g7dFaDao\G +%lk#jjVb+hPn.8eg"%]Fk6Eq8!>eeBi9"9&m/iN)Ul*bYbMX5:k>SM(2!rkb%Zg#t53P`4dN^^uVWC$R2[> +%(2_Z(1#5.?I25YS,SYfGH?G>9Q80^n5:?NJ=dH.,=^qV_%fA7_[;utMirROo$O#'kp(i@jg/u6=i!jJ9qW]#3\.[; +%&7WJ^g_r!TALcJCe"UlMKi3>e^V^0-8p$!h#IYF>j3Z1)"LM[V%m2GVu<9'KofuT@q?Dhd('hqQ`DB.[&?mS +%+!sHuk8)Fu#5)Y@-t(ekgQD//q-d$/CeU`S52!MtUdF7K*ZOiiPkX1GpIsa#?p9eqq +%Z4A,S%;S8cR"C0\YtEHLg4(=edrDGt0A"==nF:D$($6U&NaOlMU^*V_=n9XsK0VJ1<)o90aMj'E9CU(qfS+U(WPh?bPA+`o"h=AC +%dD?M"OaNY,6HM2$$fg'p/9[r@_br]^"2j^HgBq/#EnPYk*/0-A:%Cs_GV+%n;YRT^Bo#U^NKK^(/g-XW-4k4Ts0X'':3HZ'I.L3g +%2m5BVj[Kc!YDZD12RER+^5R4,Zo,:N]TjA,@LH6_^U$G(JEA^&XqT["KUT#.@5e]jLsQX(3I.0KH5r/&kRns]=BH1& +%itE8G5mrL?nokZjQpg%XhG@IX)/fY[RJ4o8Usjr"&dr6Z$rL+W$Y-Z_()H'&f"tO)<^[O*h3_C6$BKmkI7I_IYK[E#!3Jc6.ljW9 +%5]:/jV(8/Bc>DaoNnp^/=2(X)6pSb[X)'V;#e0)h/SX:g>'?JChe4$sGa$u*IVA7>:MiWH;/hHN$XuC5YA"H^`bFC3YT]B`!=lQa +%8q2_i.#G'#Lf1A,bDl!Cpf@4.$4[GFIo['2!BR;jX[srcs6t,PleS<^muXomHDVbmCmCNL87O[2*V^QMhqB\/EE'6rS*MXS4EN,j8&j>He?$FY`cF90__Wt +%HVsu1?i`47aJuhR4QFYRV@*..O+)=aDu8/aJEnb^B'M&J(-e#c>T1n]-8r834!)ZY-_TRpBVn.MKg`k! +%ieIu/Uib7t/.ge>34r,\[(rZ&I>F$t,*:;(UT6>:5E'"Q;gs$7l!XpK_b%!:M7J'C>hqAsUB-m8c2]SN!$VWe6+Q"9&/em";Xd(P +%`I/(J4Y=\;qa&,n@sV=>0i-`9V+f\KbV5L0nqn=p_.9+M\pu3cfV0-WKle)K(gjgZX`G7/6+Tj/S[KkClXdI(53<;C:Fmd@`(E5# +%QFJGY/c6?*M^rkZ^/OS/dsik!_LS9nTOe<<1a:TJ"qVinM\fYVYkWt%)0[kHfYcTpFQ6UTR*;lc?b.(fo]+cgiJ'F +%:VY?r;8(=e(;!)9K:8lt6h7fdUUFD0K8dM3#0N,iIpHA!Q3>rV`_3r3*M+L[(Fs0%C'$/#[^4#]J>mEm(iCc5`*eNi8_;eo5!HWZ7/YI-+ +%gVGrJ'57_#O(oUu58CG!-4s>ir<%LNahX +%jRr3jG!r0LV8nMH2hmF-^N*tU[\O%ffCf-7;]`nTOi4Jr8,KYu:F+G,I!Ri11rDhueMmNeZl"o&J>FH_V1o@kooCQe61@$*R.G\G +%blUMW/>)gb\B@!Z,JM,-HUGofS&uW8olMiW+i.o*?]Bkr-XcWCked5P-c.u +%91C/&7)Wi7Rl3F_?1)PBBnhc5.GT*@2gt9>OI7NpFX)//G&iqD/^FNqibJgu4,=oF&[Yfg]C%l,+\bdKY6IZfjad4$j9P)NA`0D[ +%_!GSojC=p3U%k]/]oc;:]g9RT*eRodDE9JLMf*>l0[Nq.Ge;8AqoE^7JYVh+s'Udo`aamrcc3Wr)7`d4a`oir-q+#rbMH)D_35;' +%:RFJZ@6IH9Iu>DK'A:8D,dj8Vl.aL?(;8lON0KE>:W!^7M0I;uTjT20r=ad1RGqS&cuWt!oN-P:Rm2;s`F&Z$^3t>-mC2!Op5cua +%a%ua*5Q&FfIf8NcDu]@ZJ+;d<\OQOAf71"(qpg1ErBnWns6DoIi=E^&rGV]&+91iJ5QBlts5S$Is7a;*rBL5Ef=t,ArVRJbs8INC +%bs24+T>(9]^\n35qepr^:]L>3+MW1"LMss)Vr,[os5IVeo[h]EJ+]F?rqNdKqWm$Es8KLZJ,ep/?hr%Il!IcXTD$$Kor%,*r(kqZ +%r4a'?T0Ag(3pF+.kGMcMqAJb^]52\_cW_J,G@oct1u09A)>?B@Au]n$.N,:+VZK +%J58PArcI=5OehXW;C&j&arnM;6(Pi381%AE`uafC)u%kLL.Qt* +%3jE;(TR$&"baH@$GtFqeN8gMUTZ-Qr5:TL+O*P%9m3D@_8j]n/U\pua[r(.OIU^c[7"dqlFs +%j12Af^r3$ghP/T%4kXBVT`6n,$Z>UM]\\_,"b5c!pED10"3h1M8PG%:G;R`GKHl@?[T#J4)/udog:#IiE +%1q++569fOsY^=u^OdaOJc`"'=7u;jZ50D9NLKtb*q.JMoeB9CEp#hHA3V@do^qNNcj^8<:4giR_V%<$s,)qdcM:ao.roQ.V6#80@Mrm;Sra'VPG]XALO@3 +%VfC`?^9iK+-cp?%W23Png04]@h.Nie^/R!9[".o>ZdgMnA7u+jKRe$aceV5`UlS>bo,oUtE[.EOBL1,+((bLQ94j=7;^B(LSS'0# +%hr1Sc.*o6/gK:-TWCT'JC2a9uBGd^[N-:jQ_H!5[a3f*GJZ,!/SnUQMbmJU(SYB04BA;O9]"Af<1HL$`hN +%Aq8(t'7M/VtfGZhR +%8B_(dS^8pRGV@q#jKN0SY?9e]ZccKo^_s3X?3,2:9`")HX,.Y/*YRA7C>CoWD5h7>r+Re92pC[Ce^1_.Tk$H0KL$(u+V.n_#bbBg +%jqU2spM52b.7ddPemb]=Eh)bDa]DR6SI'XHBosRPV]*'+A,_+;J.-[VR@;(`mAZ)5$SN&Qtj+#:r.L&+3Gun'?-&B0.,%[ +%%-8k'nBajSOFu/+cnpn/V/1p$CSn-s@Z[T73h\d)!O*>L8sUh2^m"s8!.)Is?rM&htk-AcB_(hS0r +%YPMWpdBKR'(jr@Dl][Gp+e/-[W6tBLpO9(io)=OiYe$2X@)qO+`' +%;U0Q0CJb#=_fHsnjdRmUVV/\QD$3WfLO#hLgSg!co).m/1%u\kkf'=jh0@MXt3q_BJ>i$L7NLnujek&a(,q+W(p/Ra.Yp"Tie:/J!o+2Pb$LM-@FS/'B +%63sPf"Y#)Bo+G)F99^1J"%i%]qYYAPpN_j6i&6X,?cG48YNS+:o<;hRI@Z..Rp3SPK9sJ<[L#0VE]T)4ch6",,JU(no6%`=MjB!m +%dfpnIj:Sg-2MoOm9dH'&;>1/eo#^!t??LB4kR48--(RP:HX'q@TYW6L?u2")Q1nWm\-t=WWM+O%RQ@=/:P@955//)07n:k#W_&@1 +%_WOe??D,'e^er/Qm[tiqS5!.cDTj+El/ZMR,-4Sp"t.N1[,P\> +%?2G+6iFuffH#^VVd#.h#cbM^cmGR*kY1B:r_kGSqq&rmRC]\\eo06Iu6H>PF2G&nXNV]%sY(:JQ;FX0ArS_LsPH:Ge&TTn0n,-fQfS8DY)cmF.5Z\N?0a.t3jhop@nS2G/jLZG)h`a/;+-5M:cO]QT%o;-(bC01B+iqFrUF.-G"G?KecO:'Kc[T7d +%aJ+OK&JAOeofIalRLT,b_a=([h[p\\!T+V1iZ,ZW3+P%Sh\@4'4Q2nS+C`4ZcOUVUK^T6\R>C;='<-fV#o&eXmg0_sK^T6`h'VZ5 +%_F=/L^FN]6>?3s9AAgq,*C1n`nQfQJqb"URE5W:cB8;N6@=D#AaJSGii?OQU>lgbUF8.a=,c97B7hCMkMr,+9@RA@a"Hn!Sh[rI9 +%&`4D$8BI&pIr8*)1IZeB=NU,N^FQPL22=CT[,h$f5-V6+>N3]59FIr-=$+'$06o>VffUroPUa%$)&JV_d#5N[T'B(C!/ +%n/?.`Jo'N,L/dPAd]AoNg4m?eTED_V"GlsO@*?+:kh.^NdL61XWe$-m@_hjem/nIR/i@6'FP/)DbC0mQ3,+1b[kOj[m$\t:T\k@& +%)a%>IXPeA@]\N^J"gF#77m%'dON1BW7^R[8>\p(1?)/QS66hd/>-51K12l[[U&c)Fr^/VRJ7JhsQ;)&1UW]V:6Pa +%`M[*A[02l++C(pk]4\hp`_'#-d_$X8@_06+-9uF^^3I8lF10=0LZnA8ZST:KSsM4a61:$f%:/`?IBH1dHcB:Ja&Mt[j#%/K.)G%D +%cRcjr&YW+]/+3uA&Ff0HC9l5?a!]W`rricLN01]e[L/)jDDYt:hK?U0Ci4BjD\kV\GO"2S<8ur@aRkWkb.>=/)VS!4BK$PYD9juJ +%pM!EHqhi=7_.:0`X!o4XI7)-Hc@0?#2-XUnhU*Vkn` +%kS8eOk!!FTZ4LWT6L(W>(@\/P2Ua\9JAW/%e\M`9HVcV]AZRipKqQ;Y*oL2R5R]8$ckaOS@u\d\#f'P`W`-9ndh?9U-S'D+9Jn#RU;KLkR*R*BCD1Q0NaKiJeFhE4hX.$Hls>J2p3 +%g1U^-nb^$F'gW/=oV"F&buX!h3YD2RKQ.iQ=)2Yb3GlJK7B)2G9>Xhn\PF]k&Pnb(M:k%KXt"&!00gp/XE!pb1oAZ/CmH +%O!")kO%B#1nC9K;gDloXYF<07I65h\E>-n\det\-kW?(:cCNbTD8Z?qH5Edu]!@jGecMLJVS_X,T;_0X6EY-")^/*J/'&?sn"?.o +%W[KsI_$qrBjYWPnmBAANa27?q>U3:3M^LVo-V(R>8/6!)n3LqR^qGEPAt1iTHuhf@:XA66Pehc%[h[^dlEI4B4TTC#A=V^IS)Hk& +%CZnAUEncHDBe9Lg1$6U;a)f))df_dY!C,Z\u9UR +%eX<`n7U]eWl!K50mRB7<>!m@tYGi_?MphE,fa4c]gTA/`_H:u8oKMp;f`ol886.1.qekpuDs1bOT>kDHh.,58UYFC5J3_q`JdB4\ +%S%X)7/U\NN?D@dFGO5jYhD%JjV+YQu== +%jn!ST>_ffGZ6e^ak.RaO@ha%7^!*$*S4M4?&*.<`=r,0QaeQUs;00'c"[+42ouK=+A@>"rDhZ+t3@(TUb7`ZUE:J3L06&*NGZAE/ +%U^Z=U)H"+%d/;=5_(D(FFd*qbp2,@,kh=i`Nf6gumq2t>_lV\_W%*)4'ks20d, +%Ie[9B0B>'!iQ@=cr\4l>0I^iKH^!uG-i:G5D-]?]!MjA2k_gpY?HU"0T?%S'ls7T9@>g8%B3du0O9Wr84,]bP(2fhp3[Pac/VBn= +%R[IBe9H9e6*;M!qkX^j@3ftZ.?"pMhXtiAVH9A!/m6Fcg!s/;G/128if@0=lQDZc323kUo\,WjOV`lbSS;XLG-gln"\S0u;P065b +%@Q?T>-eNC[.Ou,$dt2/[G2pp6J7qDA-1M,s@]&-pc#$uY5SB2o:)[bHJo!H]o.j.EH-fQm+_fABGH0lTWmS2,iM"*.FnGO69_3U1 +%%7k.*9TaS"E]cE(/W-Oj%8saD5Dj;`4'Xbm:.2n6%o8/oMPt?W,X:W7ZVn7nG$g[Aqk:NsjWqrj5,f/!knhT*#kDkg/[Y_GWYQ/e?sTR/b_UV4OFU-Ib<:G +%nq;Us2psp4E:B,.is+8R;i_"i7'oSp2I0g9:*7m28q+"'d;=,8XU[C8PC""$GgHG\+`aVC/7BCkPn?cXZF:'XI3Qs0X;kftrR8Q%G^g&]+e`iAbcOJ&NE(VY;@@U,.K+8R_Va#H#!NjN1^IUZY/;=ho'^Q!?DA-#j8.-Y\_0MhKg0B]I['f51"T%^V%k7a]Sn[2dL!qcpkT:0\7`$$#u0:@@7*hi3]b`G2^X_b;p`193N[_+koZ^OP'\c&W@IVW +%T.2bF<1mmhOtGRhb10EJm"rks,+^3-cW.g%(W(Ci?[@rD0DkV#++O7dJ,[\W/Wp#s#2u135SX6r3-*b$a`Y3*^Ak;0s&:mWNP.m& +%V";nIfOGOkd;AOCKaY]e"*\[GY2&j_/E>Ghk/S;8QI5"sZK3_bYI +%dp(>HYHU5aB=ctOhDY&.#KCKtO<63cfflRUTPhd>7lNZS%YB_?APW0'Nt09p%R?$F +%g@Z)WfMb`[Km?$S_,VsuSO8HIo)mfo<.2$]Qtj]E9Ug/Ep^q"o +%2F2/FjTM,mST_CJ3%AYP"15j(bI]=]dEdRa_A30-!H8PbV=`6U@S48Ei`0.m/R5AY^1-Z6+:(4sJm/!iC*%ZAZ-..V5K\ +%>+o;oG[/8nIX;O`JURUPFt[0@$)Q=V$@L?LCfS4PqCVEnlEhJ1d",Pcb^4mZ33XS9 +%3Qk-7Z[9&U33)D,lQL*K,oXA]9WiIAp,Q7+n'Td%6M"/OXO%XK!/4:;16kI[U5Wt'9hE6t +%kS",%:IGDI9DS;GZ8r(?4F)fT8!]@6A&"@gm;6RTLo4nr7u_b2_]S=70Ii`QplA+H3\4RX5*<[Impi]H&`)f,Fl'\m$s:PgJ>!0> +%gt'(08VVHV7cD,:8b+)a!-,Iam[q/g8cLK.\bML)]!obG): +%DZa!pR[3FIYtVV?5*M-R*^-/YK#B6*JVN&L>,_+c9t!j>$a=MTUonH"oSqpR]VUENZCeUEX0ded:$5h +%8[q]GZSGPpHa:VLjM$S4M=B6Ec:ZA-D91dq%mff\1g&1n#*5(jdPTS+i;s0Pdg)R/9In*/'W8KA[X02YZ@G*d&YO4Y2S2gbcrFcL +%TS"5Ck'[h;Aas#/mkN46lc&hU9#BqI+@sHWWKhb1Hq=Pm)t_O*7D,g,.sJ7//BVju+4e>1SB*&e%G@eaS*se]0'"<[%:;Qj&P\jJ +%27LD^1S[e'd4b6uB%^]4gVs_jXtXi2A!nF93R_$Gg/W(75nt2e*XTX)*b+lJft/8<[,/d*0a`\5n(+KeQ?N`q-'0`F.T/?6FhY,5 +%g5C3MCEmKdc&`ZHPc%"M0E1)e55j$hs$9?E:VZ[OZ0hSRLL:)D+"nT45Q'?pR`58as7sPUs8/F;Qe_Y2-s6?oGbZqB?eQB5_lmg# +%Rn$%1$u!"Z0KZ6k.pN%T7E7O8:/BnS_,^q7CNiQ"(O4sh\X2S;dO;t41[L?Mn8#& +%*e*k?:dqb^JKqj1\Y=WYbs7M+S4RpYC&9g\Vs]FDl;H( +%.28!$l@O/Ne(.gRdT/jBU[D6l1+ET#k?f=^FD;qKnVZ?AMS)sk6I-5YFOI`bnI!ZR'X`V1XKiuEa>:cJffql0iUc,_tcoU4\_#5^JH"1)r9@IR(7$LG-_ +%W+e1,@I[S59g;Xu-t(MT#O5O[4.r$bmHpVDTXhXc'lTeQ`;Mp&4gS/O;/7V[5//qEj4`bOq:g(m=be;<-t@lE"HUf'bC*L%3qL+s +%DS8"'9hYLb;LBLU/Z*5)mI8%3G`qr,96@[):@%2Di(7ekLd^3&PN_(tNYq^fVn'hTq +%/9.nZNg:d?&TNQNFdZFX?u:<^SVmjMAnfTr,%@2pAnYZ)pJ3WN0sE8ei<*h4K48nMDcU2D/okW6`=M4t?1tYFd*rt9o3WY^[tQEF +%AD943+0!-:A0$e%jQMS^Mc@,3d&b3QV0'k?"".)aVSk%AhF>S_97SH(6L +%eH:H\M..4dbl+*fq"isW"le+'%;Mfl"+6p]aNRDU?iYK"oJ$9@_6=ll-ibZ:/S=2G#eaV%dmRRheSUIeDu=L:2(B +%4O@ZIgBAU.8)'^qp?G>KYbEsoW6nOX$.'1]#_*tDB-*0d>V'EBQU>E@B%E'CW/+;g4MIWoj[lH*mW,&#MK)drLf=iA`\)fKXPFI8n??T'e)rHb7nt"bNK'Q45HrFpB)P,&/6I"rLtS6OD!u)SF$)nH@S?9U3*9s+RU`PB?Zn!OhrcEmokABlYMKQlZBJHaYnVEYW$Z_2K0_oG6gBV4X?C$=&"h/(sHA,7.YRN +%aNP\#-o[TK?F_<&l.4BINM?9>>Wp-gK_Ra,!"'X%JUA5MERp*"$*W](U)5d/8Fg9p"e>dX0&)m!nV?F09#82A,$EO)pFRap[3!U\[W=nknT4E\8;'G&RX"e +%bMf9,p:.LeD$8C;n!b-2Fp9G)C)Ic(dZ=d,S`%=iCj9<]@6k@(%F^Is2Dc7#g#i>c6oel%*CJiN7SQ`eA++C(C@$N0bTNND#;*l+ +%7:_cOkm/__n*FdDH@Y>uT^YO=`dp'lR%INpe*!tlgg::lf%8JS4Ig&^TiN2-+0F>dBitGdF!DA]*'CjZ?q2tQoj)dgc_kk$;)Mjd +%@0M_3f8*L;_&ffNf8!nGKt-jemQ`T +%@<&".,[k,t%9-+jQ])&HXrZr)'U8s/\W'2=#+cBeeLuJaW>5 +%\4shQVm_H12(@^iVWp`i:mI5CAdi9=Vg?3:LXW5&S>dqcCeUZr_: +%8.2KkrDOR$DT,_0N9GZIJ^[G.@u3(E4/$@KQu8lA"[d7L?Ep1JGcW'ug5shHqD'+IJJ'cCB.uKKII]eX@%B;+2;4''S8"Cc\tLTL +%$VP`;lH#EieQ4m3.(/.PE#o=5Kf-40K6=f1;"e?)Ts=F1mP/L%%^T-k+TRhS6qdj*Qj#E;^tAf@%LsDP-W2E72Brb..+;u,%."J8 +%3F/c68S:9nM"JePab<@q8Q^^!F]lN9*Erag>=K*#S:>]H(nS,4&-_qrCc(h&C@:Y^f)=:7BLo,Z4k;rWQ)XoT%BsH0>;2.\P+@`NC +%0)!f-5\@V'-:/XkR`4Kf%(t_\RWnGho;4%(oPURj^!*fa"T;0@,t_5Y#+)45C58C[i,LS\L8S%p$-^)_Gl?=`/@#=\,*m`] +%APWY;5YL_=bcr_\f=c_Z5i]0N$U(WKqF"b5>%k4pM4kRp)KCuMmbsIIW\-1'l:Nf;*1_k3WPnUGq:DW&(P5]QU7gj6FD6KI]@KQG +%.,Fiel&,mP=AhC6V#m]HArFR:C+f`VkFul18Z%sB%GUk=V=kqM(ufpXnt/%a#!DmSPEP@.?gGETSU!X5j=th1fc6j)PV8.3jJb3C +%Bg)qP,83GA#.LTXp_P\K-niSA-pR2/MH>CdoMVgO2B=.Yf70(Z]Z+UHO.dQSqkhTT6H#IWo6AW4',/-W_kH2!oDc1aWJ"@D1]>L!Bc3Obb;N[_e*DjRg%Eo[:ic39s# +%;;fIdEe#271R\k8O_!e2**R`$>F7D:/>S[+6_e4.(1K$+U!gZVBR +%-UhM6%o\O.KO#sfB&L?<^EV=O$D%*fWd6L^FC(0$G4u2YB[UR +%bhg6-%;1f?CabfQ?+i%\-$g'<>H9HWL86@1;7,?.3?c4mgT-_AQ56i=\6<9L3l`6r$B(ari>!R!>&54aNmXppFaNOIVeoHLARVD9 +%7uWO(7F>L,U^m2:ZcIBS]B7re-UnY_@#acU&TPEf^!&C^lgI6TX+j<]r&Ur\4S5cI!,0II-Ngn:`K%eWIrbmrloU7 +%nMG'Z@S62k1G>%@CiWF+#JS%\C5&]V*IoJ8UG)lqMQON&X?dY.o3c!OnhXqoYmRGb"M1#5#0pbk@uDA+mBZ[^%jU[m3`S@bNgf49 +%FN$&E.pL[PdA,f$VEhlOl,JCi\HdJD#3?Rh"B9Of6pm2u`_/S=!4>8e=g1#_idPgk6,`s1WP\?dTWSh`*E3a1@66@Y?6Rj#)mE,M +%R'Ula:Si?="g#-/4(O625p]eS.Euc_4<-FrST'Jo7`.Xi">SZrY$]G?kQ$$F'l%ajdf6$1S;hL*MJ;Lg?!L$BfP=>I.0&+\KV?X:.[8ge(6j`WS#=jnMJ*:UW-aP%BR'Z@f31?r2>D0F+q<1".g +%ob\.=\XrF:+p'<'&@!C(hd@9])et(CK7uZal3f.DUfku+/0C>Gm'.]mAHq6Y83s*J"\?]u/G_^U-F`!`o?t"`_@GQhH4Ug]8./?t +%U&-N@Q/D$3,`iV)< +%kSi$5bpFRdXaICuF:U56$]Bm"4V=?t5SP3^VE*H?gte+$%hBJ.\*pZ"9RCW27cDU>NtZ!6`D^`3g9H4Wj!"Mj",j\"04&&QDU$i7 +%V)+&VM9*'^J@N$R;`mLI]AcJ[nggk8QtPNfbRdu]Q=6d6A1ZD-hH$c/"i)c7Ad_mFh%-j@HhTW`,N6HQg&ai;4iM\,RV$-R^@Eq= +%Y@j!?05S'CSeo-&_QuSlJg0aEpKa>7[9*S&Q.#r6Cr'.j.?t&?if!sG\.=fUB["b#a\[&OKi7WuOOPJ.I:`^uU!'+(1(;]HL8N]. +%MIJIX]'55?#O#b&Gm;F&HH!`%$b@`n-e%4>#d)$VQ'E:2Bc:s(o5%bj@P*(td" +%o>6W).4>0T-8FjWnfMU*6Zr8KLIKc`pk%#5C*5'G"_W5^cj_h!?apTCQ$`lm[WN20#!a,K.[: +%5jnQ5n5`'@0(s61SRM44Mj7hl_Bi9jIi12\$GTRI:LQ'.fY">*is=,pn3"IsEslkTC]_p6ib7bXd.FN*ASY=:Ane68LWJ`Za!57@ +%2F^p3bmmdK'W]h&3%`p8H-h*'H*_e=<$`]uJicViS+ecTRZm-77hAhId\I:XnC.#QS:Zr=RYQC8dV[+u,IR,_?raBDg>c^)R?KV= +%U^65F(O@pcm-)#kC/XS<@jM'Gd[13T$,RiO8F#` +%roOpE"'.!:QXIrIf->\'_K%IC1lKch5LtpZ7sdW5Bk1Z:d$.F"eo$M>*b?RPq&$30Q6pQg1A-%XlT"n$ +%f^:n&G)L",;Y!;4>bQ9i:[RXVe;_&&\`.=R`.-`ip^MgnQ,5S5[qbu5nRJaT#EdoF3*/?3Y%BSY,)8',0_1KOD2G2;W$ZOB*; +%fX;o6,OFd)YTm>X1R3&?#59F)Z&e-=,KhB]?dm/t^!J-PT_m9$N[#"+]5Qj$'>E,%!AAPCE,$0W3`W8sQB)%$5m!7qGP@Pc$afI1 +%o8%L57m-uI>PLQ2XK$afFd=6SlU"iNa+>H/JCi`PiT"5(.B<9k,&)l*iuC6IMlA\+Wa\/@r>SDfk4_;S&!ZZ +%/!"=aP;)O40ZdB[0rD"L<&ubcm0O'c(K+lV$_a#%Z?5f`5k^*k_JPgZ_>63H+e[2"d_sG%M]5e^"1;>$&:h>0eV?o>/Jr);N+hN4 +%Jr\B1a]][@aEZjG/j7sP`kdm7h^`nm**$qlIRi39@?6B,_dCUn0;RZM%JVijm@8V-;5T#hBqqjaXES*/7Vu#i`f;AM,55,'M.lB!1ARel9!12j$]K:3&Gj@Ka"jXn$F4M%B$e^B\6GEDLNBR*3"L6E<4/S& +%M[<`\OEHJ2^Vc&bLYi+^K9baQY"tr`[BJ&4ne"pgV[^uSnd:Dp-P5)BQkt]7g5K!Ag'VLCrBt*BT4!58:.AL5oVK0agj86NS8^], +%SMfS+C6`3W0L(NA,ZT!goO7uH8fdF:C0aI*hD2A/@d'PHSjhZ,Ws#5n\Y8YFG,0qoVJnWbWGW\fEl6/:,@=g8WXA6*>4 +%S5KEV>f6.$`jmmP`/u?2Yi-%cBsrTu#mZ7UX9$?<__.bO33_q*dQiC%i!DjYR))s<&Tob>;Pr)=(@(#jCP-ISeBR%.&/KF8[p=k, +%bEG3L?[S$uK^V8acDYaAe.EP*B>R=$4YdLfCC=8Omo@[HS&%Yu;E\FEbFo@XDB'+3>k^,*Ct[9kLar,r%%F("g.-t99E@j^R:f-F +%'\Fp2d2YGn*rU`IRo@p=XS5YG(7[XI`lt!'cX>Z>a(?^6q#D!l=?l/d\/B@!p5E<>)@UCqG7V-?@\u<%Qkc7KOo11Es2c(:.Q7Ao +%>/&a89IFH=gmCRG.$JgoJ$mCWk/%oE[L(LBkOgaQ3 +%[[kW[.\M%gMoNR5Z8u"D7_TCH04G[5EgWaX/HnWh3;F2jn)N>,XR)aT2$jP$XDFd4AB-rI_[=R.P?C&/!BWWhiJa-h^)(SfL#F&c +%:U*&F"Ua"WPa(CQ_F,L-13HFJ`XWO6d?A_r^%ShGArJm@bK,!@l"sc)rCQ!*"n6p4Xq0e(1IYN4X^e7Vm,j0^#Nd0kSo/r8\Q#<4 +%?#jQV`G^gR$h)\bkDOr[!8O-^Iku*a4uQ@C$&mWq]qa/ursd.:l#q'aaK?MK:M=*oct&f:aghG[S#"_c>2d\iUi"#Xo_)<=nb$mBb(:67e^SLG`qpee.cPs)(+co9/*cYe+4/qUp:;_>NjJQ6Jqn@&2u=$7h8U'SZ)Vc%,FLR +%%SJuR=S?cJ9HDpE4DQc-FTJ.7$!i")$fD/NU`/*,AkFukr<5@g8VeCq@.Fb$&W3[I2\*-q3"QB+JG"@.n'fL'HJ"`W:qRX#3n&T!2#&6^!I&fKPK9Ke@6"I5nBK1AIqq>Zh/HQC@s,Y@>/qAi&!6D,5ErZ_OQ];_)a?lLYR +%+HdZ+JdSE+H$cFCO2o@hHN=J5"dPZ@Su:R0^C_OLk%??gS%n +%G41K.dmpX1eiWGp\)X,b7KUi9VYW3V&.Z(8h*;6tUsIq'iN)fUXscV0npOcBF@8GX`#S'*97eTj(2,5K52hRDUJ\.`rX?Z'pE*T: +%X(KFj3!7!2T'-pOM+\M-Ve*R:,YthR-t_ts-'-4>NIou>/i:rp]JQWmnjA<.o3n!i"'?LU(Upl2JFq"C6=_C@#jt=R_IX,&@V'Q= +%Jld-PG[+ZZke#)oS?I%U9s[T*7qu$emp^[1fFcsu[-pT'S#M_HoH[-I5+\Ch`cj.U;D8ljdT&%N=W@/.l?q.BcCgEN^pdTu(0.M: +%3*%%O6!I3!q]QG]:?W8so<:,i:2&B\.'/XjdIMmUIo.BEN6ogP*RS^T:4Q,ZB]h-K\m--^0Mm#5EohGcYp,%%gjfR<]Z!nXL#O:1 +%]M"FY>TiCLCS%b;[n&tIm;#pi,q`4l_K.a5cc\HpY"OWlc\6`ffdu]AP_o +%aeE9[)(loLPe/5qP]i7#KSr\q3[+uC[KW6Gck +%PjWL(_=,)A-OD(p$GE4SYlk`5,-7cH=?84Cc-Mor];Q_oUk!=6RY+Y_4X:k!fUmKlhJPc#?N3rd,s^0gNj4+I]kA-,U:nfN?A;6` +%e_I';DHZ,)#9:>hn6O.JD3nnJD>JGMWNXtr6+=%i/=qH(43]b7^@.NFPFM>\!'HZFh1I"rZ'HDZd0@kl5:R6@P+GXsYA?GmQ_Xi! +%Mjg7cgNT<.p6`.!J"_$;\?H['V4.N+a9b&3MGN1aIN!#`)Y"C^g.HP.#k$3J'#oi%4k +%4WEcCII*JY(U)h5G&NEUD6*SHS7rGKcLN)hd'UjYF$5*uE9r]>7rN6b#d6!*+eO+KJNP6aIn!c_HfU,3L`dZ\(1f.@ps[!In6;#@QKN:#$@KcPJcB +%XC7kjF=8lBh8ZEp8-cXOmcDVd)o0I0qN)t3"'@o+=bSjYK5Y;JPLtf(A=FN^NQR"]^S#0QqJgX$TA9!M'kp\d7W(i(!F:1-1Qe"mR]7HXh,@7&VV?-4 +%h!*67=B(O[7dfN\j`5Wre(Y,mS9H!S-8#M/.\FZJq83+^l5me@.*jKh.'IkVEob0aY.W`+,(0!IdTXS--6mX'jsK`./Rtnh'AaG4 +%kN:ql?UQg)>C$:<,uSA*It+u;C>N0b&E]amM6JqW's3omjB;1VXX"+++rXf +%c*(?4nMmRNFXfiu]5u:u^J`OsFnQOeSLN6)!h?Un(3Bp>fs^_^YV4n:DG3%ZY\'+2io;ZEPSE@=E)kU"B[!XDQ@t_eJX?3<*J+L? +%XH2OJl7tVFc/a;rB4 +%hZ/WL3Wnn(f97Uab>,ZVQQ>.Te9g_q57P&AEu++WAM/P6P#]*J)n\id",@bq#u_i`f:_k0i,D>O%S2LqJ^-DQ'>Ql@oH4pBTA":` +%1GM^.dj-spl#-""Ng9:opLF.&(M60lEQ*de`NIi*/4ho-#4$8%r`hLU]ROb.Ijt&Gp1qhoaub2m.XHD9QK<9Not7bff$L&grSi03 +%7?+5Fq)7NXW2s!+,jhfF8j1iZ!U)%p"lCN#m$D_C/mF,EYAU9S=F6VRp4h)%0\&\bo=2q7>%4gF"-C7XWZ\@W''1]soaUfW'UI[$TR\>B'.6$o)MJMt@GCCC11XnKY6QC=d4*7DGRm8cm`5[OOP;$<*(T +%kWrc_R'Wa!G@MXMN1$8(N?X2fDV)#XS&DObI]FXl=>Kepem&FaYqs9&g>GBY,us"#O<.3cl<6Vq*hC-XpL(WPlb1/!4f_:525hQV +%GlB/bM_AK\Q]o,WCt[Z#F!#sRMN_:MXRC`\:1fL8$,QYK&T,>Y]gX=?q.[XM?Cj +%]0TV:?P3qtn/,Sj8&5P-kd8p)IB/hQ#\Yr5iAIe)=UHO0d&fM0Vk>@cfm;^q+MEMP8P@l/2QohPSEk/b^O*l=g7B;[s'OgV7aMQT-1n/A$h^0apmEN?od=2eMqsT#nf. +%GG:`*\6o1?&b_g^,ZaE1]Jgm@cermaiWYJhX;#=%s-uYRQBs*$8Fal>*IV=83KP\E^]Nn`J +%Y05n(g=cR\A1)kim"PDeFrRk+gXgeb?BT;Qg-1(YNXr:Em[$-!P,)%[e],++oY9RTbkA[J0-YL3&8L;0*n^^YJ5MeTio=/oIt*:4 +%^TYr(Ag7S2s'5Qb77lmLp7a$QM\@3mIK&1(I5n9o](]fHZHh_0]u[*l;F`>NcuT$)/IQW59uUM4\AD$80`4mKP5Xpi?5_(b*P +%Z#`5,PF\M)6J"C'ZPUnU[''YOEK^NWig?9<=lCklr9mol!$5pTQ)#U0]'T7i27%TakrhF;IUIeU0u"MV'Ld9OX(f43"0-q7ZJESS +%*c[.=2Y,VY%UGHCnVl3M0ig.U,KXP"+XKgW;Vllg@$[lDi6F7HV4DGm4lSs6;L7sNY?]HV5%:d*n*CJlr)&h^m/7q#%S7;Tm"&Yq +%:#YVlC(ku_rV_8'Rl28#]$sjg!>1Z%UcWa!4,klsX(V5D!7/kKdX0$j.Wdc]nMefWEO6KL\4)[e7XotQYT[nHn.JR"da]er=uR87:7M*h#%F*V#"-q&H.!cjk<%Z$TSd8;13Ekb=,m6qIS"+r`o +%[)@U";(ZiBOh2`1DgT4d>YB\f6D?3!`TZT2PaG\HD2Yj9kbZ@IY&kUTa&]@4-b8$']:q9nU`JPB6Tk=)V4>0H`u]3*Ks4p!@&*ol +%D9)\sp!&@/_Bg-B?h?_Sgj1gkDsJd(K'T`33?)?m%/hJW^84XifgYb:Qf/W_rCWn!G8L,a*kSQc$/9=2*U>h?VSFd+qNsChkM4(t +%Xp$Ni790#IY8HSHZi)X\Xf`*`;FE\m:g@AB>DF0Cuad`g%Rs0$IuH-nR#S +%^p'7rXhFGMPC.^Vg?*MZJS/aq#6BVIU0'iDQ1Bh![Gl!'6J@Hgr$!!&pM,0gFC+GLm'quan]2(LAVG&XI3Kub6R/u71C5!p:"1\HWEHHlVAS*.A2,(uOe^\?AhR6?pia0H6nk+(kGHTF_K*#C+PS)M>gG\l+Ioue&V03m(ebCQ+-df`Np=`8 +%U5k*U"fgK\"S[\H)TeA$CB%QAE:4Lu,cF=[D8nL+F0Z,h`r[oW__c_gAlWL.`9)e]fqe$n>cYt"q>,$OVb`d@o*rn_J37.UN""7+UARC8,R`!)'>7I7XWi6CEFr +%S_X^WBnoUAY:e$,@B7uP8g#.L,+$,+F?/7J`s@l!cu3bHNkDN,BsNT,_pX+#'ZU+>>VZ)mru]>BVuCDZKb!M_+ui#s`ab.a;&cNn +%9t5,B-h$@Z/%rjh84'F];a*Z>'?;aH9D?$nkX/?HP@oE[njGr,Q/Y5`lp61dMV5eCLBC3:>X4%^)/u5/E=j]YfoeKFbcV`0mWN46r^@(#;/Kb@F3BqXDR\+>O45@kg"\QH!^:aU@^bt,LFCjSbd:n%N[oNCr +%`%fU2SMgq2qmi=+.h1:>ITmXFeG.p/nEVCDUuP(6O##<70BA3Zt@fsh1TO&pZ-N$gK7 +%3bQJDbt(<13f3Mo2(U-fS'>PMggXGu_g\s5`\us$R_u>i^QgKc8O]mN8Dgc@IYOP$?10?/VEL??Gp-(3$7\Ho,#Y`kGl3lQC45Cj +%B5=B64Z/'CXj]8p80+hPX=Jmh0-*/DIB.F$S[#KH,(_="lEDOU*k[XWhJEQ:X1gaHMhU7:3Nc9[.9G1d_Ue-,jr*T+4l4b4)HP!H +%QBET,a?4ot>;WI3ZRW)#6D7O1[t7A4N&&/.>o(\kE3Gi$>h.%:iCgW7BgJQ2%]/-b-XUuJ*XReNEnS0`AfF*nAq@-4U) +%=(@$WY>!Bn"^SZE9HJN//(8*KQ`^fh.Y^@+ZO8m*^I2ZdKfjKb*e&;qp:S=Zmb=4?egVRPkfE;fDC%FP9qZf,rj&*n+(UEPHgI-k +%\]a+<]X4"D]NK_4>dR!oh9-hQ[p$kYkF=j#Gb$NA-CI)PMq<3^AAhqnO0kd!&q\Z^E=q>SN\u.2D`$U!WZbd/QE3]^C/r6aSUQ)D +%fb\PG8oD9;E;Kr@EgZ5=\0TK&Wn3"=06Lhq=HcuOE\i>IXNmJ-MsRce-=]Mm>Lq1^-U%.^L24E91BBu7kbl52rp[g&YO?Z144ZKV +%4RcjFnnpfN'[Q'tR:qRpdjs+b0Ib`pe4Mt"V_^-s_rNid,q,._ +%"suVZ3\5NdfnCCfJoe#Kjo>_u2eK"4?/aldN2j=@&atPi(-S%@a_e&^gQhTOj3GqX,!X,qFomPS_]#cDH]Qt% +%Id,])NPtFLq?K6T0rYC'`A.u=`7Ft&S?*P:m*'K7ZsQh8/"3Q\3K:-a=ui!qC+DO29CW8Hffjo_,!ORRNOrZBc(]Rsdm,Q1PJn,H +%>V51B-ji&rEWRjj2[1S&L'3]USH/[W7WC*G6BA,m(DeIqd9SGP`k%+u(=:]&u`*D5P'ZjCV:M +%T5!J![*`%/o1TbAqGbHm1dbj/S's&WR_ccP*]YVBjim-J+deHGM7C+]dLW!>+*74=CVqt"/irbVUum!@a?KiYAi=q0m/"m2cn^;* +%m'rF;NL(D-/BG3fT=l7%TFdt=gmU4H!SfoM#aFl2Y-c'hN3Xcb=[n=(a(,;^:e_5QZA$l4WOEU"Pum%UTYQ^S2XXi(dbN^Ao)7"1 +%/hAi%KL76T=GI?qP/[3p!)MGo&"T[k0[j"sb'rWQIJiKY@6"<#Wh.A^<&]QFaiod^P#`?bh_u325]5mSS40]k!&![JMu<=2FtXXE +%NnSF'+A;N*P7!JL"[.@i,/Y,)lYH.,/p7i,7*#^96*4LJ/b:%c;cTKHYkjM-=!tg3#$B=Y,8/e9o)GU/QY9.!XV4kOO'>f@`<*OX +%g@jLZT`e!cjQ393L2IfD$F]=:B)_\[mX@2%QZQ!EYA6d^;l,T=]"qp*,[cXn^H"D3SB`XZI)iOq_?,)jW[\Ygl9FY0g=6/jG1N6g +%;kp3KmIG!6"c1[tf,J#0G:M4[-C<.PkRa&^E;(D0[*#PFXscPtrK':(al8_SM<\ml%e"P:.?jJ/*s.2Y3Yb_lEko9_>EdmI%[Q(H +%]m.D18'AOl(1'p>6?'U2a#kk&f&u`,D-NtO]5j;apio46[i5r)\Fsmgl'%B2OKhG0"4P\@Lp]&7@fa-;n.=u-EK"_Cnq\dZ\PY(sR%[keccs;?]HFopi*r?]77*N*h-sF^8'iR#<\:A#^1e"!.8g4[\&map5JO<]V%aGK[ZZK9[ +%`piJ5?ke$bbtP3GMm]_((7S)_"a2,abbGpL808n>eJr(2c^=Jd%/12%Rua5hp-rGP?QA<2#hfnNG5U()>-prU"MgTok/XSeWA<[L +%]an`s?sPS4GCG6pN3>M#_Z:nmBLQmm(4!I2%UhYfOV4WGpXffg_8^ik>Urp2]8@!QdSBsu-ph["Rtd@UR-c:VS%7BXEq_b!mdj4, +%,m\D%ne_*iR$F#%F*XRN:Xp=R#7fjo4`n/2#sH/thF/l(-j'W!NJ4,[bgEIDK%;)XG\!2*frSqKB'"["X/T=)TUj=ON*I*+2Lsdl +%Mp#q>5baj948Rt8E9q/7mZ%0e*_VqKC*Y%M5bBgQMSjW\n@Yo,ej\Ve--W:CD#%L\bRO+a6sXjSLUj!HV=&F?Dk'VI=F"3;95A8V +%nCCIuga2p(d][ta:s%Y%*4.M"KW@b*Eg;Jhdj6Ot\dXaF(XEIHYYP].cXE)#3HrJTb`fD%Rj6F+ER:_c#gWp[HtXiaIS+YnK!#eo +%'I#R!qRU:,_e:XM%fCT><`l/ts1pe"(dEmpOlZ)9j+#>jOCMIH8o@i%6oo!d5WGICTE71OG:c'b]qmOsAR&D@!%MIBQ +%>2)&`0]J87Ofm4DEr/#8UD:<%He>bTY]sY'R/9s<&nJ5>JG$*+4-@`n7.Q+!Ht3S6-p/9YfGf0jFfA.Q\;4D+_5UD13eKb@46l[* +%V&q''.6*O`_Yu)s5QLe2V-S"ZER/8[6+CRdo2[)H+?fY4;/`YA!jFMM_R#.,8Db26$,R/e!YCUBMe$0Z<6):1qmme=c1d +%,onUb'Xd)AqZ'RoGh#f6!mPqsZ?R"e@M.K':V/mf#!Q`XZcR8u:l]o8CsIOa0gYh>]^/G2W(Ab$Qp@pq<1^l)kTcf0(O+7YM7O7q +%9`T+/':W]sW:^X)\U!H--$P([K*:7_"Od>\q(NH;P0>6L_>[Q%bkfisMR1iO2[%"<"#sTRd@am8$JtkA^GE<7M&9Z<:7I_^n7&:r +%lY6/seR&MK.02j0WBfaVq$j]j=%bFC^9*$4Pb7d]j>Var6s0<.?u\g]K&-=cR]7VFB'frT4/QA[g48sSd%fO)-:f*$>p=ZtB0jFK +%J9eQPF2+7lH,G1F1,tJQZ[V+!RUAhu^]25%:(aE\u3Ps>!A?Ip?dI!O6!YNp`KIV6GHYhR7B(-f\1/5`)[8ZDCioXNk]5eOh +%BW7_M9(Ln09+ektp:e&d;XCUthO,1^5D=T%/T'4KQco7\7jh%IHW=.,8\;d;C"kO=1(ro23B22F)B\\iW1?0JLC$u[WOW0-9cIO_ +%,J3`Q,HXH`-X>b-dO%(M]RD;$ZuEkX]+^^+%2Y5c3/?lSl$R307SjAn]5^O#EY#uqQT6j*>BgWe*Xpb-I*c6:l16]9N6EhiB5K_n +%S`OWHkoW'F+VL_A^Eo"?/VU6;DoH*UrO6qX/iXBIU@liJ=agYJJtd$cY6(#Xek4I]ABe6d*JqkrhYbmkbZ'M:/kuW&FP@pWHU="j +%BN/^PP52i4`&Qk`WqfQnYkLJ3BX[.]GC=)8J>u/W,/djMqA48X`9Zk":S^%*I7XG.YAqpAK +%Ou9Qg,6bsq4^@kNQA\(2RS%N_A"*mY;H5A'a3\DVD=).+2Gn%kOtYTOBc^EeRILL7.o5+WnqtX*/89>0;9Dl1RVDVgFoB*4jguJ9 +%pTfEmP7ZQrR?hi!Pn]#p?;+n2R-;&;s20Ntn#pO.I;;kh?DI%n>i9F6H,^n9qWM%[4$8YfqrWO$g6 +%0QMaPlZU"BB;>akg3HSK8:cmef<-_C')_&pqR?B+W(nDG"JSW^;bp6G3+ot1"GtBWGeHd]@r;iV8F>WtSSO6K.II4OX/lD9ZAKhS +%CL4sbFQZR-tEo'AQ&*HdJKp0iH`*= +%f6BtBL/>Ve5m5sIGtbo>1U-r) +%S.6lZ&]D9l%7#LuZ&C&-]d0f)a=r37OIR5#N>9n>#PVHHjl$0>6nk^XO6#qp5!NBOV$LS"B%X%)';G95-"MO6hqLGb-6QPuV=F7+ +%&6.?.Shsl:rde?S:o]hsMEQm^$+e6iXEcqsW?)^8Jt1aqjY9m%l1jgk^,?e_pB#[RTWZ-F4fFoYG9miE!Lrn/* +%nEG?[JCUAW(HEgU1-,IY\#e-u9Up%%G)313V/Ye^Sp-crJm$Gm!s3:joO(.WV2q$eZ>NB<`+WORN\#ZE.Zo1_Y$R147NWD<7r[nm +%HEE-J)XEs)@2OQD*M]MC;qdm5BDViXR^m@O9>jRdHXGcfi2R85?2Kl9++f?Z7p$G[aSKHio&%H$M+3:ZM+=0G)Q.ib?26.8C$j:D +%OA?AC.re,W:pu+V(!k,,(_s.hWN%tFG5g-TIg/.b:`6=l"Y)kBaY+ssl9Bs-ppns\+6(mJ(O2=6.N'!+]:B>ELRX.i?D'pAGIl", +%Ol]u/Pru>2>-D^H?Or':'f>5j#8HPU`GY?mK,UudE*_/`_$B_e;QR?=r9QI@%9sFSAA)0e/]\L4I3eXYbEq+f)8iI.ui*LqZI2(QAU4I[:boJ:)UpA#r3%9M^nec/sU/V3r$j([kU??^/tA)Vc._n9j$@qNiW +%AfJ_Qg&L[!eS$5]n@We60p7@'H&>'Abr\O/k#g_ka@S?>=krXK_J&RVJT?,9V`9O^*PgTR[*D/T)GLe +%S]`KNRj(Z,BeWJAh./D6#BgTZ(ja/XrRT7]OSVtV_>lpBT'M1FJ=1E.Q*(Vu6B#]BC8a/$7!Zm^nbgmCe]KYN^$8AEqt]O/[WSfF +%MToAse+-O?htD"'*kl1V1"TEGPh;9@Hdk19+ZOAo`kagoX^&?EHpMer?S0IKoShBo)3rH<;O8oL]dLib/pGr6bU%eiXNhJY4i%]S +%C+I+sS6g-.B.C/VcYP,Vd0#K+'+[XEasG1<[94dlpe'.aSq#91S9SWss!HPh&`8p.rN:53S[GdK,8J]7K:'0*.Sq<1\$dL2I[HI+ +%D;F"m&aTpckMjK>6EKVsGhG[@]D@;ED]ah&_O/e.h07e2C#q8UkVBDIf6=&:@^s8qPWdX\D>FK1OiJT%9g\`8,52qa%OXN,m/uUV +%[dl4J^J]t>Jf"3Om[?MQ)&dM70[`3G1b!)PEn#C-W<"8lMH"9!>2aMmY^S63Tk,1]A[EQ`WhPJ1$S+,f)"+!Qg_VZO>hrXBRoSVt +%$.!uI/&BRY*XktMf=0@Z[3)q"HArV]&,ts>X?,aOp[RWPRun_2"$/'3@m4K!V&7`7;%P#Ho4'Q`!7'k.Fmm"kSJWop/.9E?r:no8 +%J?W]i^_)pAl/"Dp^u.,j10B&m&,;'dSM<8OoO=lZ0KbF(1`kb`+LnFM0(hd5iWlT7HHeN\?TK=q.9kXJ)<&LJDD+ +%T)^0B&N8#qV#t0s.e$m";%CF1OQF^"f1^trjanRN[--tlB(G?#l;.aZ.-2pmjC^cgaW^'7('/1M53mo@?n1$l;\deO+Ge1'<*4f3 +%5Q(^gYD1V_l&B;s9IlGR3".#I9+<)8Ot?;k6?%h3jZ^kh9Hn/KB%^f,;:g`P$Q,(3,_A@,#N#.bjVXj9h'jbJDO)B1^W^CD1^Lso +%J(!+*Cs_EUD!ZmbRH-G-p_:!DDt1baG3@ZOj&I*(qOmuje-q*T.RD@d\DA>jPK.>NZY(@u"GOBY2OJ,2Zu6*"j]Sh0_?cAY"0j`@ +%TlH&rW:k5ToP2k5k!&dM?K=SAYRi>i0I!%cV)%B?O&98#ZYg_6HJ9Co*dn*nileM(pT=Magl4`VVqdgKb.-Rm8elf&K0du*+u444 +%=B+_P%9Re%E:jAd*`9TYl.HD5&uhPgS_,_,+"O)0'_@oK5/T-(@fFB3f8SZV=Ob32GDR[t75_.3&JP=A;S9^I:X\(C[c)0F3h&D*(RAM.=/_Q(/RkN@\p92uco),l%t4s`pm_bV7nWO?*-,fOo?DW3(E\[0_H +%$4FrMpsj%1kZQAkM]FG0"lDnX@Gj^:Ef&WObPDk +%I(pK'gdudVio(sd[j3NAXB.?\]&&m+hp)r->e+L%].t9>ocUl_^&LsO^@0hc*!fPmqU\A`8*aXkbmSY@mEEP)X&SFfQI/WaCOY^. +%=2m=q*.Q]'LbDA%0X[Ve(9;7`G>(6hcO0_KbC6p4%WfR0?PF1FVYph\fI-KLN?/lAl4PHh[Nfmpq@_k;&RhM"I:Y'SPRs;@@%ho,eXtDo>%$0D3P/(iA%"1[TmVk;l2 +%0;X6tZ2mY`C<)O\S1TR.j2k?/"piIeTl_S*WWpt'&D&gd,X%s%P%[eFfHK>ME9=DsA8G.0!sj2R6aIFF`<[,2Phoi\n*HMSo:e1t +%BKUGi\&$`,@5VE0OI8t,@*u'[c8WSIj_d:`A$+OQ2EOZO9?4*[2t"ubeN\#Y+b+%c +%4bC"%GWX."PLia#,#Cu'L-%Q1\\+?-e6`ES@jO1idX3q;DoHC`$2&;;O*`gPSO*mZWcb&W5C-'5S5A#DQl9gih4mciN5C>RXQ&?H8pmc`&"!=X,K@Zuho-IHhM_aq32bPb';R>GG>M[hQo`LZtGH)bQ +%+j9p$rY04ph9r7&W(W:GcIH7]qV"=e\6>_@H]8[p7n:j%W_BX.^L07"]_iFd2+7>Ge]QP7q0Sr#fp, +%%)T/Z$eY\]GibVLrh/qIKM.CYSWW#Z/0Q-XU-2p +%9=-Kf0ijt1Wqh]'?oui/>EmZF%H0kI9Q+s+3H@"`DY)"n6+Le7f)XKZcoA7&WK(pO5>[qiIG-YZ5!uHHbNDY*u;1BI/`+Z"dFKfLTXa4Z4+5i(:#OB%Ot1(H$iB.;r+G +%oNE==S&!t\#29[_Up9YD6L]et:=!]bKh!g]_$DPI3iT*_DMip!jbsG8KMkdjI1+]f!E+RV!E$iJ_=5"md$#_JMmIr04L\P#TB$Bfqdj(lU1Ul1h1I35Ya/"2o-c0k@ncNQ.E:SDY`a8_XEnmXkrp-1Q9AOrQ?Zs5h2T(2Q?u&% +%iicHf,TLk.iQcKu4Z*7L/iGqK]@h1i1j`o6Ziur_Uj'k!Btf!h3/KmI5HpaAS7YP:@(68P-YJJ.d#q +%E7WbR:?>Dr_J1M&YCpifF1ELX,tD6]4W>cl/C3^r4umHqY.tB&^Y'`nq5YFl[@[>!=X>KL +%q[pY]V*[!HH%"u+C[cg-`,ZZ(gfqmkMY4n@U5$ITO(aD9t0/3mO^/]_-Fk[fQ"X32bBbk^[ZGJ<*/PWQbC(3#-Dq8F^#S8X))l^ +%cpt>7P5#"UCNl`e>8%"JOW)Re&nVB@qU_MF8(_D4+E%VmD_UY1r))9UrhP?DKU9AA;C6_B.6I#lG6,=0KV52,eGobE#6QOR(t?/V +%aq4'0VPtThgUT;MViN]-"erS.^p=P4D9$T"qhfS[eN6KT.i&K.9mp9Q1.7s2^ZSd'L^/BAXEE^(hNKjVmV;2=OWq0hufsE"l:`5H!q4o?NZ_\ViNbT\"53(Na;Y9d&6VLr*C6(6h%55Fto1%%g^X4g4uj=UUh.P]kjReFDjIPo+.,1Y8X +%XX0C67Y,>A0s`5V]F\_ioMTH/@cdEbI77)hBum&?K6/Acl=$FZ>K?G;QGYkF:A"'?"kQ^(nef)JMTi(:&I4@O"8iF?WC"1Y`oO&P-GA,>#uR-_ZN0L`B/2-7,H?77Qn9` +%poNoELY[JV^pT5pIC%=UW8$%nM2aekp0sh2>7>I%qf+0UH^DNsdDIDgVI@M!@g()$UPMrF^Fkqljh&'D"W526N"MT@AiB6n7_W%N +%'hfjNU67>Hr>L!J)S*@E$ol^$kspGHL7H6>)..as`F*EJ0PC*^I/S=AhZEu+j/'L(iU)6n$SjU#/lq"n(E`cqoP0uB>XBcY/Hr&9 +%G4SYk+0gKoU0Gi#ESp?%'&;`#*ar,kfO6Oee%,_qDU.Zo6G"l1:A,hZfF5tfQ^DA#+8-k\G7:MU^EJ4k4"[n#j>=*r5?70BZW3u/ +%XB4[df`D^hVX!/SKU),0jCH2iV#XGs^Z2.7O)@+Q_9=G$Sn$VToWf\iJuLVMG!"aqdjh'tg;4T*JOCIN]*.ElE+d@$LtZr0d/fA)W,DFJg<-uV$^*cS +%ZKYmG7[7(iHek".+)sr:`P*"5bD6&a1AD3Gj<'6SD4RODp\PQZ/UC[d^1U9jih0Q2ZBAf*0&!tlRH$p2%-m.r\!94N>G_%q(>mR4 +%>PBef:EFk&\tX5dc1oPTUiAA=XJ6[? +%p9@$?j+Off,*K5T,nn'',9[$a`BWr7/oQU,EdUV[r]]$TIQ3N-.(Y4Fl(!nlQB1-QM9`Ni3Cd2jZV<-9_',q\SJ>#gAfcGk2^Nb1 +%&XN"rKB`aNdb=)0DtsZhqtUY8>&#BjI@V=#p-1rap`?:F>"#t3c!3)Mp$qG!fRC)6pJnd2;_*F7O5)G/cITr*VL6OX3eAZG5#_,& +%KV*+g@LHuXEqPX#L0"*J&i1Rf=4L(D#B5fh*P,VXhEcc\Ds>ElP6eY$eQ/"j/0;u5$ijEiE&6N0!$hZ?5Sho;(N?-!YdWlr-P3*D +%b2.qTG%$YRe0cZON)a13[]c=Q,;i:@YCll)B.[bL:gP6L0ZM8mc$.(N6rSQ?WfVP:,uCoF8?tjnSCQ4NDh7/8TI9$>h/cMf!l\)r +%+cqi]5th>lO;Vo(muG_&WrV3o.lCHC_f64.?Z4Nq^H@H*Om(6mC1DXc`'M+M<5FX?Wh7dY>1,Qn?#]R*/&PWFT,@"S&!c,d*8IZN +%Za2R\95PiX([#$(WLZ>4'TOcTXXdu__Co*k>"^ak**7LArCHhcTKr_H9uQ&i_Or%p_[/,`G"CqmRlsIp$:M:8QlWg?MV])#M!'os +%+3o"4_(EN%*1l%fKN9"KP69D[6LOARD$Ft2iN=UA3]^L@,4Cpf&Y]>7NO'AF14tmd'p$D3Elh2L=0A4F1HMC +%+cXf+n*fCYZ5+f(X'0@H^D39>T!lM8T6Qs/VSl2,#OWaaA5Bc_\4i@'58BcNl+cK?.lF1uQ=_5l.JpJ_FP:_QV`/473AF#+>S;RR +%lmfob5s1M-(/#X87D=)uVI:dTcYOO+9+ecj8\SbY#u[O$p1`,rfG0L'WsauRR8QQo(=O]uP'A6Ul&tFsLGTs?99'rJjQ_3Zb>^6V +%0WG--(,Sg9X!8GYRD:Qt,SU)<.;!iE(XRlHjfUDC-f_RQ_QJ+@VD>2(>M0K^N;fpN/7r6j%Ad3Z,%+.p:7r +%(8=dHQ."dIL)jAg_`;;HYLGSjM +%jWcHGU-%Qg9_^Ng0I%BoC9:C@fO/l]*:nd$fW6].P5SAR/:!O`VB-VLW`[M9$(2S5f=fnY3QArGjt@SnlLT9M-m]>1ch:S^&M_$BfO*:+C;V$'c> +%p3bP]7B-HG+%2GrdsbKnPLsXEja)L]C@Pj\BTLgW5F0NB#]&D,$#n.LW[t8BBU2_^6T*dE[-TK/qsLG2.NeI97Hb6/bh< +%XtYMJ4(WSt/b+7nacC:SnG/#h=*t=f1$h76U-u*;gdUW1Lq+iRjtajtLjiWSX"FkAd12J=fc0A#/Y@K6GqX#Sq8$Loq+*M<*YpqZ)%15jX`>a.LQJnoE1,rc&Po[&W"DW9^DDGmAeas0M +%`_Z2mpT^76Jr*0&Y(*afrU63os*1c,Nq:tQs4@;I?Tp^Sj,a65s8INIO#U2;o7+1HEN?H2jp#*A0.Wd%R`a$?DT\QY+NFT5J38H]67$VRI! +%)63(;'f0)i_Bktp?:UHUcldQgaL[h=qqW+@1hm!lSs8CNDeFK3j82\JkS'EDAk^O&SKX)b#J-@2XN>k_N"5&D9g63VB"OJ +%Gm6?5mbp,j(cbnS-!:N9qj)8Qhnk]<#epAr_g'9mMS"MV_'=jU]!*/nDCn[4S/%*/(L-53"SondMG-)t!\6Ura)6Gp`\>2%=$KC_ +%H4)jNf2npPSsuFQfGZQ9kT,eDFfpLP.gE1bQspQ,H)>F/$`K__/V?b.`=(^[W@fA:X$>YC%SAo`[)r;VcAWC'a6 +%V5ndJYKs7%LV?)=>NnjBD::NdhmL1p!-_O!7buH/ek,hU.HioEs-i^4D\7'!AN0:-PmRW3,G-iNVU)EUC=8+NBbZt-=>a/,LrMP$ +%4e'J@U012<>IS))BRKB$bPu7M<]e`\OKe=RJVFDe1#*F$k3pOI-2>,<99&;<2Pd%._c4X\iO;0qVQeH"Ph&&iNeg[1Z#g_k)g`5o,$&"FF8Lu2"T1:iR +%C]dKa/\pj[>R6\mCjt\P9(kYT'1eq0g,'u9'4UtnfOWqUWN0c7X1GtZ.5=mOoR@2VM6J=>jG-F$6]m-Hk=SM+GnRQE@!=h&W/,FF +%Mfh@tBd`k;HAF^%(dWAZZF9J_BWbR^N'S8Zl4?:p.e63*'HQTGaQO?(@ggHB=G?10C +%RQ]ENA'[6U5#_^5%WJ8V>I5nCpfmkTp5D&<.DN)Do;V!3*^_*8Vt3[pYt,/M,_4goTTfC(U,$d!1gS?Zn3jUVO]tLHEJ%ij4g,#X +%oOa:0*H6J@#2S'_`%nO94!>(NH+@`,iJe8h@HMD>N'SVdQ40)Y$9H4k!5S>=Q)UC=m%AcRSI=U^Asp]\Efb6G"$.k^=g!n, +%H#\'^6S-+>?nR:fKo4kJ\_+T,&F8Z1;$E3^WC5Dpj\OS^KJ$Z4o%Gd@/TUB"nDeEsQhdOhdqfA67eK1\QRLk@[&f(*k;)QMm1qNp +%2\_m9eU)pIk`R?G4G1JRmJF05I+bHCHO>o<15 +%^67C_G3[9m6"nn?kI"a9?p:h8ikY?:jO1UN4M*4+aGdg"\Am*EF5n<'W6d01(9-'`@`q_lSa/N_Q5hXE^1X_BS%lFkQRB +%5_Cb>he'UD1lk7]WA@dqB"$P7G0W^p*=J#j.qO>ANZZpJ+3o7,3Hh]W[j`WZXLMtsXjHC>+f0OJLS[6%jm>32s@6pZ)C(_RM#FQ>GT!s#Z:gX.c0@BTD/O1cHZ8=_>bpD&+e,](0_g4SB$2E,i&]kYho&;3@%6[m)$ts*[Acs(C9^!hPl6aU*3d*GK9c"mFtWKuLO=Y5)W\I^GB+l28387jtko:VBo$.)MGK +%TYB*d>9&Bt;Q;o_c,3R6Wi<5gI!O)m1_IhPfPc3HK`/1%%$'ksO-N/A'iY6WLl*k.k +%"P%c\"1A=:!-+6?.;;WA'RY`>8[Wt];;mjtF9"TdB`D1N(20_lT%c#a'Ro7R-+:ngCt*t4.5,=N;q;Nb*4;^fr:g\RklcRG:JW;` +%_,8GISp2M4(0&nWi]89"6/aY#Vj_A_%u[uT33qn%n?L]^.uY#9@C=[L%5;=hi8mJGiLmT]PQE&J1f-U5Md4Z&#em3dF=&`TLK>B# +%1:Z"9$O(a.&WFldkMO!*6BlCu4<.jX8KX!h=P5*S$+@g#k'Zq= +%<\*:W/nmjZ(^Fp%-0)dX':=;?R;bPg@h1qmEhPd+;_qs`h,>H)37)jS]Y& +%He?u:grcZCDRR6Vi_u5-rn/(E:@?$?hu7?BR&3*Cih,!R;"qOu4A!8ZZsZ>+L\i^_8W]!' +%o0bFm&I\pbEE`YXmC^URWQ=&GB/b!^9rfmjX7&.t9ANs2)Yh5^1j#bbg&'DffLp:1]sL>F%FTqX+OR,EMjBVc'NF)n%$u_mc;ZFt +%D.=M\p!(n8pQr*cJJZD%%\Hr*U<#$61s\+4ifOA=mD??ggj/OPl2H/!n;_3Tal,5QJ\s8Z;2JtQdgR'\r\@AE]Bq$gk"h\H8qZ:M +%&W&g*KHHerd8r?QY/gBGJU&-fH&*4TIFZ@YI(O:C9A5&]JOOJD@4Q\h4b3tl(AYDKWuODhp[s,3rZ#65[m?!-R+4j]!%K//_.Dg: +%0,Ic#(W[sDO&ELq#!JhI<-#L7[e1_g+4[R+Y5d1;NQA[l5j3eMqWErpnNS\^B#[VHU&-a*"/C+$%-e-UQ8NpiWlnHomG-$OMQ`.I +%;\P_K4OLR^XNIc>lu+,]ooZlf2Apcb8DYq'5umBl)ns"Tl$"%rMXn^#aZ[;KVH<+rf0JcMAN*9D)KqAISk0<\jhOKEeZ_mD9.nn47mTn2",,;.E'`FNc>dK32UH7[ldrkf]:6P^2mWl+10F4.O04m*h8!gohAB<@nfM9/e$EBPmT[2QEl1]GUSf^TP+8L&aOI(h$YePaTOE+)aM!Tc=Y%7Y+H`RBQB)]h*2&(.+O<<=T^-kT_'p<$Gk6u(ZB-+7p4#.^EcB/VZGqK]X]/bd^R+P.*=8082_g,L= +%#=VFM^h28M_*TamGi#7'pYRQH+2"p:U8`d*(egC.NY-a&m>A28K\VaZIu62JoG%7),0Gh!4u!t/QGH:nM'>C"pA!nko5Y4.c'u?pP^u-noL5ue/-5`a9B2Ik)pgGWZY&W]\#X-CBV!/_O0N7/)@+e#Xc_Y,]YOmAlCW)$(/^c:-+f4I +%&Yjq"8?p.JHJ8>DkN0XP[WXX61ng03rbT'EnK^*JM!nqMS2E5RI40qH\V5;dYgAg(5Xg9 +%1]8MUTI=:"c<_"cnYHd[Ms8PQW2a?hE#C!PIO4^i6G[eD:etl3O!>>6l(/iI4htbAhX(>FIn3OMqTu),)dsQM5UgP^KW6^.RV:<+ +%FgK0F9c$(4>-^>fXtZmqZa"GKDEn6EbPSQBqk_?p)@4mY(UIRD3*=1s5]a!]9nJ%mHS@i.MB?&7`>5q#nAiQ=fkS.u,[#;0R`[8P +%`tb@1LUZTj.>]0:WSk6DembifWRDgPR`h$Y7bf^^P%JV7OOIPjkXin3:i\P`I^4DoZm(^W&J1`kc!El0_SmU#3?sM?0h0Vg`_^b`4oIc\VKZfrle`m;\*s,XF4gATSMW'kqd[COkQ/0')slO<\qTQu))=Tp!G4\^Rg06&6N4WfA)R +%g4(#)e9c8l2&AQ$raJ/K!B$N:p?>(U[tsK6F10U7dDoZFZifp']7Fb'K]3<>UKeeXr +%.jKB^TOD?;me/bn4uo[]_e`QM"0F(`GERuj6r#"I1N(mNOO'lu%giH&[,tZSa:3Y5'6l8nhcVLooOT`nA.J`0[JZsm]`=JWsUq3Q3;h[l]lfYWH->nYAsP[a*t.#_IS\n(%t7AoV$PqJP[Y#OBL4RTiH(MjBcI$ +%a+9/"8ced/J9U8gmRm]8_b"#S*U3.s!pL9'lF/?C'M8GG!,?2.+?,u2[G8LU$Q8,]g/AiEmns[g#;!%N:(%:&99Sa?MM0 +%ghHL>F!B6njtm(9*@C![!^)gO4(H]`'%GA[`L)-^R_=M8,ET<5Q-/6si=]-=*A_bF%bu_qFDu))$.hO)Kpc'7`!M71T/=E/jg$:2N[A`EH!U0:2V>&U_7l-4RE]#i]!!.lO!&Js'Yip"obihdcTKfP1B$Fg\qb +%MGur0WgnG>#$.oqrYeoEY#06bMHnJE=luOcaqc\F3\lZHkL"\/6_Y\ +%aoXuXBtf_M+"QS#W%gV$c4IL+89!\8e6)Y6#3n?Qq.b_Fh]MrEc#D&<58=^*E2rT6Z)E,5Z;@9Xsr?2is^V^If\'-4KV#\n8A(8+M,n'ZAr$U\0m]m=P#^'9*!eh?C7>1 +%YYi<*F/X)[Fr_W*,+la%4Pu#5&7O`1e!mHUI1^$E\%,fpnB/IjVu^O_@KKWCSIpX'9ap_sl.:loQEf]rZ +%E=]u(N>.6f%^_Rg;a::]Iu2eGFI;RP_;O!PG;f'UYM_,TM2J[(:ZKb%k<&QhfO-L*E\e9.HBHUWi9XOiK`MuM95N1uSNZf?Ok^;' +%Hke>cOr>nB`4*?o;ZZ/g=Wp#J9c#ePmukXW3#S5ubjKS3q_m`K!Mfo)^1fL^qtjXO=pVS$G+3L:K'dG$!(?GC-FbQ-il-"8B5S:( +%3+fEj95WYrSSie85.X7\,r=)(Ag&A"KUDe5A(:bgg:R%to0o+ejS-hG.6Dhu#/@h.X%B#*/7tDOI;JMt=%1kO4u602Iqp\iR5j]] +%PCOpi)7[&NTghhHBW*^k*(&t1qS[n^rq7,@\l8WOCf?PoA?d^dQVrpa*iEF?0g)UCZU0>MGZ9c:9l(H/n:I""@HH;s?b*:fX:\W( +%pmIUWmK%(tg/]tmcCN_ADJ--Hab$G3Gt_'/m"#N)V8)%c(Tp\U^A48'ZU^qF%+NC`c_lti(h,GdJMc(jN- +%n*_SCBPE%67OD*K1oU*R;>5rl_4ul6(O=FRjjJ!Yq^@3`4\,!=U4j<.R+G"l7T"O6RaLI^#1tk:Ht:JQ5pTB/7&KutNAgagk +%5&N#0Df+]Ea[HRL(W(#A$01nQf/1-;#C"nW?3tENL.8s#@-mBDDsieUH#:4=I);%q$?hosI`RJtBrjFKl&-99rc$L9,m[@ijl=.U +%($oP#@'d^+R)r7-FubG(:%Wt)`a$?0V&TgBg3$1VWPE7<=Rj3QTqlJ7M!E&AHT\"bKj[S-YdZ&^hcSpTo7LG*7M)\<5qt;:Daa(P=ZsN^<7NTg_9-F[KBULW7Z/^BHVeDQQrsS\)X'Y.d2# +%n'ik5BUh*-@$6kG:+L>A-au0W@S&.ps%iF!=8)bC=_VN0I=IHG:?)9uV)7-GInZ2L1:0tJCf7(u;tj\)dH1UOGmnhY+k2l.*HOj@6Xgo#1Ra7WPm:E3Zp6&";ha:A*QqW9$`rUkC)0@c5g%OD7\Cl`s!L%B#61jQCN>+A?(pDjf5/h17l.B]Q>6mA;O=elY3.\kWNVRnU\FVfP +%q37.ilctVjm\"PBb@J>I9cZ%u+t0BIZZ(D%'LfZ\^oo1(T]@&l&s!25pW0re38:?m3&M"L[8AE1Rt\D35s/aN>HZJclYK>2h)uUZ +%T4#ee8s&DJPWQWB#YupCmL)IKA2N]N']Q]%mPdnaBV,)%fDHA[uQc.rgEVLuliB:IA3AX+<1OitgFA`&6_K6!p(*epMl6p/*"-a)>it+9Un48Di1S +%Wo(Ms=Z*]f1+RP$=".-U9WOZq^l.%%\KU,%+@>)hA-E@53WFHqK,NF)kB3VOi*Uag#*#aahob6BZ!s3IfX0G\D&QN-pDC9VDBK6kXBo=DkFK1q[i][8eU>8b'_6snE?";=9L,J1ZHBeAJ"cDT]<^&3fbG;I=9 +%!/?RPdGq6)`QlmJ!*I4.R!'\3Wk!WW^)-4s#L%Dnqjj.JDsL*A!q_poD.'ttIiE@3"*Q#+_V]aaEuG.QG?o&7a"L&m:LJ%+(QRIZ +%bBCXmAd#["j3udB(REpHobVkS15:X.ci8Gg9sR$LSW#)^EEGLZm!fK`&H^m3#:P1GOs\P4_sdfYLDN5_n*cU#%\VArOO5/oc4XF, +%Nrm=R+ZeE2?ggbRTuL"6j'M`7W+NYk)g+;MBJ@%8qii[6S?;>*ObKR'H4%n:\L=SlCE2cLK%Bg?;:;2qolY?:l!j"DI-khmHY)OQ +%9#Rukpd)(;j.;Fsi6NVk'F/KREsmMDm**RB7"ZI\SH.qkiW)X#iCY:maDTgl80R+$hj^s#?<0g.04BCE;\jheWqXuXKO1p+3S0`[ +%/;''rr\h!N/KLg,]C#=ogqT;ZHe`9@kCE!/:j$DFH.a#7G)i<;p/@oLCKN*0CB=Q4=;PY;3P8^3Q6T1X3VPm8JV6KU8d>=?&aSiD +%%K#MpF\6]4NY=HrIXf$T\:(R-.;-^nN4K;``2q6>gY%Jq:-G6$1dMKrbg*&F7,J'$l5irRfFa?Rc(t*oLEJ,%+meh4LQStlP_9K= +%:>Yjo1jDo!1/^NnAB/W97;>G8O?k6`>)@Y3rk_DgLRh\`Q@S@@US:4@DnE7$W@*Vok>FC6Pl8E9*"?j+UJ>f)%LBKn=c(>/?)Wl8 +%38H1j;(S>jRLc&Job_h`H3WNgJNg#/>(oIC3i(@Wr&h/W7ChKqU2ELZIsbu2FiqQO-d+=Bimq,7M=5;OmbkZ^kMGkrWOit_a2U6m +%'8ZdQe8u(@OUTrH>kI:q!i'!]K:rdkQsce02M)/#/G].((WE&0C2JYAP[CAA*oJMMpbdqc:\"l^lG9"cN1?X+QR=K#Za8^ffOcEZ +%haVVCJbh27Ca01H>M&O9!.Rn.gpIKG\R1#ui2^Inb+rqs_O2E=_A1j1HF]TlGn:t)fP&0Y@^-4ZbOk:((YJ1.n$P5I&^re[[\jA< +%dh3Se\;jt6cRE:RnDfDHlWBDKF^:'_7tsj/qKe>k"W[s%QLLg:7kqf`&V=J]j87]7=PK%Xtpl`4r1FuTs^fW?`7 +%m_\D6a0(r0SMdrAP?o_oTN&'asN&"no0)7"7_ga3g3T?]EcgYh$8o^BpIXkn4R4\\h&$I7F/bCSXND7>0^%r[89(Z?3? +%lhV'WMJ-f<*c&+G)guQd"-',@4+mT.:IF#)f<-$?;>d#Dpc5gss0)1_?gr%6#C9>K[srk0s4dSEofrKJIsh2j=BEQCIXb9?o!5Iu +%TDnSg>>YJ-^uTj<@/>ZXE7.1!Va>NAk"CI$?1:dBn`X"AeX6q1Y&SF2l\F,D[k82OQMGb/it"d.]GC]oY9MWQ-.T7:NjpieCj_/`=gC9BOlinN0;^4Hq:p+i@%X_ouWuH2$$K;rii2`h3ajDD"l8ll#q3? +%0`;Y=`,I1IIi-W2)Xp44%,(\5Jt$-I+dpA>_PtWq*@'(QQt-iu#^,nQb=;XZ +%@8JpaBQVb(WT'FG?UK2e*]aUcS&]u>YLOaVU]WL!%oPk\mg-NFs5E%dkBI9[5G71&pZonI&lcO'@m7U?C_GkuZYtqH<dp@*JuhP2`BR[P=*'BXE:+kk\jjrY]H`*e4P@%+o99+=$BHc +%nJW*u_#9pX&1WSO^0iar)CTGj&2af#88L05IoI(B^bfAd3I^;9XY_+0",B +%1.aB$^5b??K"HBnfN1H&,N9#V((gT-6i^_4BN/C81>UP#n/S(Oi[XB$LDPgB_fXjq-u$UB7cL,N(pWT9p\P3P%5j#&]1J2D*dr\C +%j)V`C10C<>n/C0XXN0YO=iK8p5g`h"_Fa)nfC6jei6-4Sro+W4K&sLS5C?JNjp.mi%TkL!a]CjmB)W)qA]c&7;[`4QN@ek1?Mu64@;fJXd;' +%3I@@:;#=c#Ti3oR56r.!$0gZo6)pMc#g0XO/D.EEIm=O5L=fcN3MU7oaHD+&[#_So_?8*q%O!-mco`8l%JF6Jd<,C[DBe$a];'_UNX+P-9qgG/n4#EhD7DH6>q +%nOlB-"@)YNb>#GX'Fp(G+rB>0UI7ZhYEq;N+RMAoR7<5IjeoaJo9A!X6/b_PFKi0M_F+"C=tV)6LPK:2"b`R^`dpA$co,(5A/SaK +%;[>h13&<_r8?G@QmVCB&mJWH;6H@Vg:W#FoW&fR(k)kE=o?SC#5A_B"Zlb0T%C3,(E3\(M7]?.A7Jt[#Onkq#3LKfM0g:4sgF0lq +%aC[VV#^3-KCZ4(J2.Z&ZW\tp04]S%=%+\j;l"`Tbb%HI;.5GNuFhN;\ls"TaJ[Z**.YW4q#/.lEW(h2'HW4LlH#j=qLMn'f2j-;_ +%5d?T7G,V#n!\+]TK??*M8PMS$%8W^pdnWH_72=NDUlJUU+LbB+KH,'\!Oo_M`mKCfUH)4aaUt>'Bf',8NrA]8\cPil/i"&di_2bW +%%,j<\2.(E2@)r\(I@bn>^a^E8%=of00sMmXQc_VD#",5J`Ub'Yo?(R>j74!FXq?k6Cm^$*+"$NVY!g.Ch?Q9r;$g4Q[(3;)%&L\L +%)B4*cWkFcq8Q4.IJMMjPE-!4YT,]+ +%Kl_AZF-RF96Vbfp%P_u0B`jl[<"^"@0#Q/(PuNc'pHFB"b!Xqh/oZA>Z8RXG\4!>mIo70`\FJqXiqnbU[Ut%DrZH&XOPooQ\&$<@ +%FRVS#qNWGFM$mM\gbp?IQ?"Z!Jqrpo*fWI3>&1LHIW%e.hiC:X5D]>X58#\UU>-[5s1T=W8bV9g`%Cbq)t?DnBJNZKob;0rppkP1 +%;HMoU0<(1c1j@J+XBkMG9Y2W5IS1U=,=d8uSqAH*C0ANJDl\Y[m!G;N.n$X0(#h^^K;PoSPlGNd`a^FlmYSTjAH;^cd;% +%cVSH9K!;A$%Y9&BcXHQBQ<96QlcD)h"E9aVrTl+l2+@2R\3:ZB,:M`j?#<-J+XBj656uVR=p8.C6(>(('Lf'@S07e2r.BLOoB>BB +%n,VnW8TYRB8g7i0$=NicGG6YWjLE.>];LqEf'ur1]ABK]j-'ajDK^g?F+.sPXVO2/Bg>j=h3/+T^p^=ib2$TO.'>T(p!\6M +%2Ap#M*);NeB$1H4g7k5YWOsYO!,O4`m5g[>*e6q'#qW)u0Wm>KZOZV,T4mPd+;gF8>S40Q`bQl8HJ:+^NY"57@/9L1*=WFd4UY@QpUH?Cd;,$0_s314Dg$uXV5)V/$fmoR15P"3IVps>Z +%PG[s6j2inDf6nC'HXFbdO5&W2a@2EZn,'oNcb.JtLc9-\UG4T:IV98O?IqVaOPGJiAW]j'\3\_Peg%#%6&[MGmA\op.1.oNG#,D3 +%N*VW!+Q`hk!d[!j&n\CmS$oBpBRpuTh6]S3U-Fr3&*W_Y$l4VAnKSHmn*XXd[>:k%T!6g.mY%_@DP\FtL9$;u,BSh__)uc"ap!aD +%`Y3sY68\CO)#(-^H]3hpZR6U"YWf[2AW>5V0GHfo`Z"18$o[7:BTp.$:@&RiV%Jfjr4ILjHRYAafY946K*TIIq2VU7SEa]^A!mtU +%XAKu;G91U!EEm)2\ZN.MYaQa)'b8D\]PhT=0:dkai^W:BWh-;_=!M<@XKlYT.occH(I^,Dn\!#PJgPK9t:'VJ*")J/RWW/qg%Yq2Qcu3gZs_"O!i]Js,hBZC2U1&^8WD?W73uTn&R(1gZ3'E#<$j$*tGBVAC.#3mrS^beLqKq +%/qpW**A-*$Qk,:kD]1QH?6.\eET8*fI=C=K+>,bB*2ZMY:q7Dm?S+4Fi=@>bIro\oKa2Tb,7JquFf#pO1($I;Mcj6&XcpWm6We#e +%g)>rG&SjnBn@6SaKL6[rLm@4GM3K8KGFQ8?WY]UZrA=iR98ZZ]'-VH"-A+("Jtu2Of%9kfU#.(*e!<$R?S>Kk*ZE)Y3UT-GU":OU +%Zuq\2.u4'q/EL=1P)NK%*L8JH(;8%:2N?.b3\bq=+3?(M#WFk:I5e7Z!kDI5W?E2r56VDndgsf2*eClUh)'KF5jXZb*d!T`M#gO)%>\eQo$U]?p+2_]5C-X/Jo:*qS%ReSj5[.=jrFm#YN-f9t;is*7+rcnW+b4'\Z,]u^Z)+I)p3U"dVg:$`$VS&\DD>A!C^>mC"ff\bhn(L9W +%gpo-rs*j[3,.#NR2&=g2BP;2H5Y0ei1\a"Pcb.jPk3FUbH=V=^rtG9G&(*J\a7VJ>`g2;o9_EO?;C2DT +%Uq^gM1l^u0CS!q5=05-poOA1#-/b8@hKQgTYJlt[%Uli@2N(/+'6-1?M?2i7/sJ/>MVkNE8GCE2r(,?<3tdOe_"BBd<8c`@g(J7)ZOq?On&HKW$%B8Xnabol1hG1Rbj`L +%F:^Pk;)al#MIZ\AY%E$]5rU4iBBc?\b+2VX+[-Ch]b*Ra%^9 +%F*!;U?ASC?b4IjnqKDd^MHpN]/UNUW=,nMim&=kT7)4aTEuNbir+Z@K_@j!8&XRo-;\&-naE.7$la2D0P7Y3O'MXP;B8MBhZ'%lH +%LsLH>%t,GX%qO),9@4iX@&P)$\@HgT.c-QW3:1?44(Xj)3%1Q%'V)5h(q+SoF2"29681n]im9,]aeOE!F-ScmO-@Ir*JksXN3Alj +%]#cT%hg+kLDT=@R--(5:/\l+h]3q&(N9>Mhmr='Hq:OBq2#!WZGb96sp*_AhCH\,e'2+9@?f?,?*E9An&>KTt!"s7S +%0IXa:7W_(0ebNaNf$%\ehHq&:@Q(@O'(M^$N,;,GqEW'%B^]rMTET?,TprnAg3:)T&t*$);RmK0\3IZh.`fB&.k=d+J*4c&'R6('l+"^+,;Y,7(kh:jdpX?h*.\H,'h_pd$0NDJuefAJ+ +%46LC88[8)X:XZf`\:\Y1?K8ZS!)14QLd<4Rr8H_rn#![a[*l^VCYTNW,X+$KNSq(%A$5cEd'o7"H\e+=k$k(o+3;qJ^JY%O_,F^W +%O8J^NT^r%pfl]ZCX]i77CO+C=aS%ggIBe%VI^'SS'S6.'q"Up`!C#28Hq4J@+YN,Il]8Op#Z!Dnkk--Li$+K1o:R((YBg%52f?EX +%/[MZ:RAt?Ffo)Z%"!UCepd_HK.IH@A=e1dO')7&H0:r%Pc(:I=KEPW;Mu\?R[;PYH>N'65SnF5sWM$O,R^CT[lmHUF42S(:VVSi;0AE+;+'B!;7Aop^u4*fdnCG9uhQI^0HX\>Dd +%jjfOf>=sid`eta3];Ta4l4tgmS^ugto?;)!H0pJmGSO$p/U=WkD!Sqb0.n!a1C^rblVN!1=M3=+Cod8($u'+,Z7uA36Q-5d.3XGk +%Mh1NE(3HrRnARrYAi#5JVH$BK9EILc*PUI_7T>pF?!4LtE.5P`I^3;Dpc1M56l9IJ +%OG`_!/PTr=`O%:o&W`[6L6f9pg1G=T>1O6cW%+a*>GO([6[.-S8I]CX/'t<^1Lb/Cr5A]A5h&K1aB([tLQtd'2Su_Y(9B%;E/DhK +%:H3Xt[MDaPad9TrLZTM\FWcSeX*YbcVDK3);Ap&n'8os[g71SYMo(EgcB?\_mojIG3C5HtE[Hp+d5^Ee;*qIR6lF3f +%$p\7'd;Yq.D\@&%%;$lhWtr]:eGIm[A38_dkhB^8`/;J/WZVg8L-bT"fSI`jm8Y +%AT!dYc>+Y?&Vk3M*7hR(=Wco(L;q;G>[gkVDk(GdL=R3Q;!_B92n2/P0E" +%qBjdj*54JJ$@8+cS5#YtT&]ac@pt7EEta:ck3*b5"`?no%VmOp?Ol6'f4/1$G6jJWj`SG9FACdh4GoiXR +%AJIcD'eDVPC?=;T>945E?H@/E]l1RNWYeUB^F.mena8F<$kn^>=sIL$'08p26J!qQS;LL\0jE_hD:N#_#JgqJTp>/elt]0_NkAAP +%9k+6gQQ;aD%cfVZMX)#IHn?/j8L@gP)F\oANo#S!cp5L^A]Pd4'\&:SDUN/Lo]4,0N3"9pq9`W&n=rt?'ZBS_Jt@BF1qGP6qj<^` +%nVoPI2`+W"WCEXFJgZ%K'h;+X]j<&UZGXVXd1JV<:fdLp>:\BE$Y;pUoieeE3(`WLi+/+rkIqnS1=[uJ]f,%I1ZXMm1?j:lQH]>ZLmr#G`b$JE:YsJlKL:GMY6`o&&43B"O_pVO +%`A;/>)%-uD;'Kua%;eki+JgJBi9JI)nM74deXNOm3S_J@V/MR32THbJ"s<^Q%^Y=&-oc'ia-ubqV+kDP[E\re_Y@TN[_cfWUH;a& +%6^@b3R-Vf$J"nKcLE/s#`1HlGi\!?akX;*&.!_3@Y[*k/4(sL"0XRJS7!H6Rf@\(?d3X&eJV'2m@4jV%MqMrG(M,:0 +%c/C@$fE#>NSqI3k8-e!OOD=?qlJ.+R/2LTQ>^MR4h8r8IDSD21AIU]?'#d"/U*jkL]L!?m>hT4XJa?J@YmME"=LId=R0AA66Cf@r +%+7aK*HF+e4<`>\*mC+C_`E_V+E,*MJRfY>Ifr5N.E1&Ja"MGW]$_pk/fhMHR15eoqXlBRk5)ASL8[&J*,h^&L:YoM>.IDZNOu0&U +%7Y^CGQkd#KK0r5[.WXl0R/K#_VZ>unl +%0#Jd-L>[g62!qcF\PFe8YKbOB[@l07?aN"cJLc)LVn5d3:-'/CN#;c@o+[aIk2Q8C+0VED>8Zuqn`adWn#Rr-@l]LPTT"UB()"(, +%3$oU=io0$BIpPn-=UcN,Yf0-*[k-Vk%XU4dIoh^0Ycq+H,@#"abJOl\pT:UrWqDL73m`H@]N7CO$l"\`NN.92h+1s:#':^iNAk'I +%Ji"6odRN8%SahYJ(Ie["2[YK3V.chOS>.'B*&fZ?,Mk#-:t*+`_b*dZ0PN6'm9oTqBl(+P9AG:&^0=hu,G:CC*#Lu]Q_TOZ:P5@D +%++4DU^0qaple.BQ3&iPMs4XtTNl(:aiX$JU.=<`KW+:(F$po&)Vm[Wo4l"8@9OAHLn;R.W%Em]"=?n$V;iI0jOSnCsd0RuGSObX_?AEX`C__G^ +%BIn!oOX\Qn3,Y6,H.,nY6`iRd=c3l.ojNYgQ*#UR`mRtR&kc0,gX?jg)O#[j@9%SD>^R`t$[gNbGIlP)b524L6VZ*Z+&uL'PoZ'n +%/lZ(J@j+ohnlSOjjF\r0e2T]:>:aK>=5H7nS,C.*p0'P.js\6n?reUR&,IKiPK#VVSYskf2$DoMWh)`JW+\i,(Lf:fKsp'm[Vc/h +%,j/qd^/s*jeg`)jltL?L`=*RR,a7k$l-t50!Qh"/,W^&t2`"%@.'T,p]k^FONc^AHd]_qh4Gb'1oJ +%&#TQ#8P^J@7Hdk=N.Ipll>n1L=17;M@O.7b5Tr"]D.,@/]UmNeikU91;>loq\6&Ag=/HGf6Cu?'[p,(h8Dodd%N,dRulQ&*/M +%^4HMsk*#IE[lXV=qj>f/SI>fWn0ZOAb=l=!0?MXY-m24C,mD'm7C(1IG:HD[hS'+e1EXng%U5^h3>a&tT`+k+`QQ7")N5'HU**ih +%hHnk-bC0BVLVJpVQYYe4m]r#-,Zt'9aZGM)VSSD*aUF@k;q[>m12r&pUj&$o.S+okd$r[b.?TlVc@P^/+U5%&8Y]u]2].`XYR[IG +%eJEJ_3kBMp%6!^O'(lnGJM=AqS>*68Lf&&QhQ&B<*^0l:c^:"VP$d(cHQi+BSa)=>()2;;EbeTr!d#Lk>@nLKDAd^%20Lm(pA4t-M%4o272=-ougE +%TW:EGki40,kiB!?kad]_2,ch)q$sh_c$qq9,Y+]KKVTt2TS_XKp,,Cp+H9SfPGYK`l`dqb(laH!]9-'tW&2Q@9!;^X8VdYuXW +%KC)hYRqfGe)e>LC;,Gu1PW=i*6Yf[6+JcT',bu!6N)m"@RUqYrZ"C1G>\sma9ics]A#;5`Z9K]84TH5.c_P[5fR*b>'j;p@gDTNS +%OF`Y96Fq;h#?NSKnb0SCq;.if":2/og4Z]`;rAFKbBc9g!("RXAZK/:-jDr +%`5_mrA$1')"mq7Gqt$Yb/[G/o-7@32O;';tRdk4U$#fr82Q5S'K]AmM^JBrR.Z*,t6%Xk\_Q+,[;T?]J=Y(8tR"@n=*1ZY-)@,X3 +%a??&_S'O>Lq2@7)Nc:fERd9]>bX?Kb2Lt,ckc*3Bl8IjPBlds?JTOEb/&tb%]UXPiCsZo92u$7BD9_:S;M4"2PFK-alK-=8\>sYW +%-Nl_nlY?d?$aHkoDmtnV>E&c]Z)'_*$6(gk3nN8uMFW:cI`#_,Z8+>YU?+],:%#t!^)E<[@S)J/4o(lZ>FS=UbOI1qOH1>gJ;LZ- +%".g883@=#a+)l?,"LQnRi605eB6=CEhq!T2M_Fi#`S57nn+O=t!hRrrNX/RPK,I%>s0rO;,p@=qH\C%jokorqm&C4= +%Z)a=<[PX_c9lP!!?]'9klJa-ff,:sHI!#J%l][;1>VtId<(aeoY>FppMA/>Z6hl35X&JbRm.E!\eA2m!4PI@@CWJkOCqd0\sf]ZXJ*U6^:Pl1P5'f,i9Y43CqnYXJWlL/0F@U>5M=62>hBdPs?^J@:E?9.tpA<[Yknd&4C;uWKq9p<"4C@O[MKD-5uf<2rTI"k[i +%f9Bl,qa4La.87Qr%rf,8:1q,62B#oIRb%Q):VT:gD3<7Fk[#6)W#@PF@MS*Wd?\Ed<[d>M+<)LE&!_+%l)SU;cu`fWF7DsE_DKi& +%@]DWj[;KrGWtkMVHQdH/C'Nn.1H*/dhDLX+8augU+,p(IG#/ePmqi^1Mg,f;*1=WD[MTfYCM$DQ_U>`2(*l(Vi.e_HeZ0rX@YUj+'&Uo99:"+Z\6mH`_\%tS]q-g6c: +%59c39*!7@6D`!Ye[(A7`gHm7qC.*VOoF?1r&.U4EdR[m&Y3k[Ll)Hg/@B$QL<"0rg2:K6npe1]_G6@@gq-l1QW:-cemTn8r>3--Q +%h4)#sBW3gTKhJ;E6+.R+Jk@u^l*?RV"uR@pj`U/gW=$tTX;QR$)?XOjO>YQc)hf#+V4;bWYlhJ38_XfCd`1DSgr4L/Gl)QFn*IKe +%?;bLYR!pL36[Nm3s3fLJ+jqaF67tnVIfNcBh,;JZ>=,u+OJl@YX<C\#HG(TruqBFIk4!Wl88)(>EY/)rWsX=kgE]QJ_ZK$GraUjc@c2"tNp@C[M.CPu#I +%[d59`f`$WO^Y/'?EZ*1]Bftq6N:g@KEUVJ)J%YRlfKgkFMRr<[-Q1--RjqVu6.CaT5qi>TL5Mq7SXc^,@FD#^hI47Fi5E*6'5pip +%T'V2tXW/.u#)El@@@ld6im!AAI//_#PmL8i(SuZ-]/GBPYXr5&RP[Wb+uanL3GTE%-$Jh4ZogW2Ek@ZTO9T.B9-79X8sQqTSt47s +%ROJNu)*IA%Q[B%KLmW4jj>?pX!Vp$P'hI`f"Lsb\KOYS^d6T2BOj"lZ9EcMO0eF'0!4@GZJR\*YN4I[a(RqbiWuo\^HpY7nhuRa$ +%*+L#)^R*Qs8K!l]5TP^B\A[mX.BCd,d'0!JTbF:@niAYEVq;=qRB1YU&8fCT]rqUn8ZTiYAcm,k(O*SF^".G]aC&uu[aO;oBNX*5 +%_.g:llfflNWT!=@-?"?.O12kZfT?fZRcLTtiqOlZ"63[X+\\.2aP%9oS'hae3fAb8,@5no:m&P9^,L7R\GW14b5m6!MI/PH`mJ9Ge0D'+5B +%eH<9X\+LoS$;gUXDPX/Ph9%X]h=18$4bNML('@96Rb4K_V@5V8%dV8T42#EX@it'/g[@8%ZLA9j9d8`lK7^@Rtt=#S71B`)DpgV2B\B>@Dlg@4fMlY4Wi\`:W=f2!g-7 +%&b6(6.sg,t.UN9U,W\m-;iCo%)9gRX>-en['99`[&cFhVS!hbKnDd'.6,p6Q"glZLO+j_^:;VISXP@-4V]i3_rm-GF]QRn/Hr;,Mq +%+2;Kt`WWmV-cUqfDDn,J&KFueQD[4FGGYO_/T-PTngm?X>MlShNSBMZ'!V<;�G#9J(I,`XI1-DHo]u$79)O]JgeE6:>naHl0)D +%T$WE,:$@Pe((^76H,JBCU#(er/G9&W"V?3tIEC:hP0M)8ahVbT6Wdjh)6>JnV_^oB<$IJTWgdB,F,@5a[5$`d'?d[YY19Cd9H9>B +%W,]jTSW'5SfH+T#!quQC[W>?)Sr<\npa.>e4H!>q\H4);YirORX$!+(A:TDg+4[ht@Ip_G55BXfC,6bWCSW\ae1WEE;[(XSMF))( +%>b2,m`nE>5%5h""!"j*C,gF3\(%A?@s!<\h:)$RIT#tO$Lm[rV*3cX0:FT +%>1*Gq3u['r[;FS&*%0)YDfe4pO/:quGLl0f_ch-JEci1>jV%bB<5QU8R_af\%^%J"VQfc!`J2*b@AiNo#uejq"g3ubB:BXUBrP(;4`O(n]6g&91R +%Lr"qMIMd9oC>8#o\?cl+UcUmu2M9s.CZ@][Ql?YG=fNa/.+en>/ +%dArb>p+7@-Qu*"%-=.]'@^S(FqXCiZd6H./]m#.(a)0'%mS#6DB=BGN?;@k,:q8TGf!6iAkent(>u[JEKD_eG0*T +%=gH_I]afR-_R,!G9CsS1.CS.43khH>BG[l?nb*oMH0(8d)oS9;m'3>EI^8OKe+Cg;e]$2Ca(X*@S8dS%08RR`hS=Pgo'4c9D=H#T +%j)F<"'qe,Jbk%dhARn-H<@.cVb>N7b#Y,!RDMk-gl&8?7#N22j$8J=KjFj*(Ho2\SrDPNB"K+QGEm64C^nkt'B"Y@6h^/"Xk`5(j +%8iP-^jHh/l\oD+6ULthHB"7*`ag^FJ*T!(u/UX7hSJT_t)AqU.$Ga52rr$5$@MZ^9r>o,'8?5f1c#XZ$QNib=YucfBP>m!5gsaCg +%\6K5DKpfAGPcP[2Nm_c!OT^;iVMTW:$6mKAh-RTfo7F!DY,*!9!9)A5k>.edmWPe^lJ%q(n.Ed>;^3p4*Rh7gX](bH%InKnoS\lruHH(#[BQ-_Gl_ +%:)6j=^p_T.6X7u6l0>[5dK\5*+`$aX;Q_g1T/bNl:://@QulV!"Aa%bL4sPkgKPrb@?n/NYGAVM4LW*,i"F$X>Ia7r:>CEG`[5LO +%92":NpjA4pnE6]K#oO'lN`FdV)EmX +%.`*I9I*uGZDba0Md!>bo2T[ibS`^!T]iH.FfPInV;Y=.TrOk*6]&VV99+e*t8+p..,7.=1Q0G$/B=J/>G$?1H8<-[eIiDH7)WOCFt1*8/4@=7sLB.l-oB^NhaR^9gW0M +%HGp804D((2T#sULVfM.,4Cf]]_F1K`Pk]#SYP]qJmg(SZoOb;6#'s&`1CLY)r-C=1OGbgQS_&O@K'k&n`-8T@,k9,%a=OR=`9=3- +%l=&@m]!D32G.JgXaik(*Q^5EMikrZ',>k_adQe@G85P;qK@=@nbqJ``JU%#\.^&2SUdS]CUrd.5_UXGAG]Ps.D;l@3kl9c]a+&N2 +%V58Yes8DZNc(B7ZF99Ea2GhbaGJl1;(>/qN[\:11%,d\1R>djde&>_B[W5L1C6i[M\Ri^7V8;Bm;o**%XRb@(AX.Bn+=8.QV"<>6 +%O8`;q(P.I+3KtJPsLkof]Ysq7ZiGH6h5Ce$8'E&NNnUtf4Z2+ED:aW(IdMmpiC;M +%:_GVuOt($(Y#K6fc5Is4g-P.DfspUg4jno.7MJ7-3d&n*W[N]RM/J_9!,;+)!eN'l+%mO&Lg+p+R;@;/[!hG?d=X$1iV^8#<-X.M +%Na@Ku@s-e4?Z.6nh/)_r4oWsAV=cZ*`P_9nUBJr[f8H9?g,>GIK,5UW\9N8-D*aEJ]4]_=)a4@mg(WB.'DoK.1NDS(hMcsk-G6dL\j<@b%Npr9XBQ-m[#WCTpn +%gJTnr2RI'3YKq4@U'-##_IE#tM/Q#p#FG's?_t?gl#H,&j8->3M!,VfN#ilEG*U@k)NT@OfBOtC+;C7^(Mc>))Oap1_&O;81ob"U +%V3&J/<_#)k/:hS(2,Y?.^qht'G!sS>D*0P>1b&A)NR)FdK1$fbRr\D>iSl>&Lm6n%3<6,U:GK(Z79Wj,o@i8@Oi8>7o,ULln4c9U!V`2BhV"9:*g,d'h3\Gf!i\DNLe1OD,p_Ej!C)C6cEWa@>`Wktg?&hLXcKH0VCNPr0Jn +%Qs.=O(Je#.q2C<3-clRT=cr[.m3cqRQ\rfO&^`"GSXd6b#*#^4!)RMV3+;>/[dop6b)$(RU1NTNbGoLVf +%)d>gBoqN.KYTT(_TS1i6%ocO5j>iVWF/_f[&0M1=gdJAgC%Q9e?rTU$[IAG^f$OaAL8Pk)V036Ro@6cCkATaO+g!f7"2!.(G]bH1 +%n0NZlPN#N""BS;0_Sb`CO?4?t_GoBOL.WY+7QNp>iP@T(QW9@0Q6]i?67$O#G\0bs,)^hRKVLj93siIEWmIR=>9K!KPqbcib!:#J +%+j:gn^6\[]D&mG1`P6o3Dq\)K9e!>eA##BhFI?><^BB^LOP3.tO?U,q>=/hGTV1=kY7TH&]hqd`W?`:JBkrK3]!TAjPF]btj^eN? +%kJu*TfuR?4-6&qS"e.k,*J8WYc#Ppk#A?[D/A07H;*m'E%p_4=PEBdf;\KXuZQ^q[(^&6JkL#W7XsELKXaQ,1R9*Xo8uYp;'WOa1 +%5+.R*HX%>-IVBg$.s&*-Dk$V(K:Fb`4"3gK+CII&9Kr/%+d`UmR((_nO2eTV0MJi2p9Ppd-Z*9$kdI8-dE''[]p'j9"H2g=fH7HB +%R+h +%LMF7kHnr)5-[0ZH1BKTDU0*N^7lYZgO4IrE:6:d?]/Hc(.I`nr]`))<`G\N%MV#lSF`Z7aCYHfF#89@*+1@3op1e:<'0%Nu107(G +%@5B`gW/ZYWf_b'5-A`]b`[[$W'0_S>*bg"cY7Hn2]87\1!sMPVE#`uSMZsAncEhetLhkWb\rgn(IL3XbZ$01FL'i."YrWI05SMjR +%Z0Xg5glc93%X"<,3pYk#'\40)#HjS0(<RE +%PtpRWN9Mk3[5I)46[0:;R$EG9gVl_o#8r,U<*[qjJ,s,Sf9j#&:n7XQ&5nBsJZ(=ESX5-7CXh'HG%-6JH?H^!b<+U7dqN`pE;;6)mKW!c;mSj.kqLDM^=*65S9`>msR,a.ZLGrE.b=oa)NGWW_1GOEQ1aJ +%PmGB9E,m+aJ'A3K=&2SP"T9MeD(@@oYaiX"`=X;S,j[pege0[4)@jANuFjTMja"W(\ +%61LNs4tQI0Y^;74=s?s<02C=*VbQ`BMb:$d7*DW@H`t[S%_!0l[9a[f?d?W0_D&B=2W_nW8FmO#8+COu&;eWl:k`,c/>#?4I!Ak7 +%LK/-4`\hG!d7:a#enGVD`CE%hm]FDRlPkrJ%fRc0:BX<)>9i&Ug6f[kUl71W[iq7S"mUOpKO'Ok^*oQ=fd#AOmglr=L"*OI0FHJ-EV'CpNe0bD0H?R93TL[-r6`rDbk:@?uedA$*(rQSD>6B,O+Kfs9"1\io +%1_?-O/+d%3Rq!gX`sU3pT2L8lhXPGtUXh<*Ffb/gG'1["+S>>%_D`[*l:aA2a%g%^c#6bj=(QP66g!1Ph9?nL]fgkMDp`#\"P+SM +%amhTtN_8SF&TrBgp,H<^Bcu0ep,#)`N1K7cJoOG4.S9uRO=ZWVYO\AfVC`-1n<3>nYXX1eZluFqZ%lmZ)m;.K6;s:A/`NM"Ca[t; +%=csC\,"#9W1!T%fKp\8PNML/;"KKQTg6"p*kN*T1A)sAC@$lf0A7&6dZ9frHR2Yig>(cru#,k$D/$Qi>cp,CIdNfK]#]MrVPfq') +%V3OQ-Rfc)'3epP>ZfML,8&s5G&L1A-;oW]7'4=r`/rabIU7D)8LG4+,FnB7/MM5*H8>u7KlJMu_aL.iVMLYbZm/58Kj,2CniaXGc"bj)_LU!/5AO]UghE:"PK12]O73,l8DP1HQW?Zsn8BhV(:NNEZs +%Y`XjYdZP*<_U.!T;T/DUQEO+Pj5ZJ5fjmK_`$nfsE/K4[q'J&VLC+r=?.XUj94RL53k.`MEG'tUB>s-?,i5V4o33^8;VH"fX$6F; +%3phshSP'3n_Saff>K=slCD=,Hi:!Y(KX4ETY'hXoqPOf/NXSq4c=#3,R@ntB)U&Bd@tdI=Wgn1B%m@2KfpH4/a#$uA*CIf,YRsQ$ +%,78\'iq1R%D`G0F1]4J"ODpCF`FK8*)C(Y)$2&r_p[dcB8V)k) +%c5SS8pt6:eCXD9^l4XE[=O]+fHCi\:W'/H`>A/L2[%]5N*_hb!Y(^&]Y%dOl#&V+*O%6fA.a2q0>2 +%\*f_Y"Y-_/bC9H!4+C@n7H2VTqoWnCqpHi$DRU%cF'<:D8<4/89PrQ[2F!P8,6W`[M3nthmtj"`/2X3.m#36OV;\MWlPUL+:#;8m +%m-=cSMDNF`CfF9PD%`-/QH&e-DPRdF,2R\][rGtlb9n5':4H@<`"nrKKL'gL'Vdtr?h+'DR^'lCGVSMhYldi1k8(#\`W`h-3Xjas +%iVH;BMjf]h-c),XirXkB*Vd=1rAY7!h$g`pjQLMM#o\AV2D,5/@$W*KBP1t9:ts@S>L55o6Xjg?ig"a*9mr!t!1"d0?"cB?bHXe]0Io+nB3(Y;( +%jJUNDOaT1i-^YUL7rl1E-FU2=O[%QN>?<>--=KCU;SNa.Be$GBN/=tD+V_01YtsU'1W)%QA5>/-8cFc5.^#jo@7%nkD6\*sO^&oD +%%U*,f.7cE.6I<[hO'4?LBT.p%U2+L,"al"8kMZu,Lm/COW-h^rS#"Qi`[8R)=H3L0!c78W_B%r&cWo/^]H\FeEAkV`a6TQ9 +%C0K(NS?R$hl+5cFjjhBDHSN&.[$\:;c'W13#D9IF@Bhk,SLbX9di$Z&;J;:O4-!=$mhkeWIIAZ8-lYZN0IPTjI)"lY:@;=Zq1Xf$ +%0O?i@HO>&n:;pL+-/NoY?t0]0+\pM@O2Yk@ja)9rKDW#unC-!mHp'Kjc&md'*$4F.*&*2_>O*8e#bS;_OO +%jJmbMabZn4JBPa9*P,/6d@jY[_=neGm*;II.'`:DTkQp`[#pU>1t,1qfF +%Od0"J`Nf&o4"5ThetH9rQt/720V:1&"&O2tSZMp%D]mOUMb%Z?"W>L$7GD6*U2@(*WHMB!<'!E/j^E;-N1oG$rq<&hlnZ`HK2niu +%$V%@X;bC9s0.>ptno4BVLP_=#`H<%tN_aNM`M)M7MZ*_A*OXOQ6V%utJhQdV*q>]B%&aY:W^uWt1mYDH3#"jo&6n@'ZCT8T0]k\j +%2[XD/i1qWe3ul3a*@TH:>\YnGiWd%cKu*?2IN68Cg9IF;-^#fY+I$=9+&k))k@jX^oa-4i5s'%M9QGLQBS+Y0joqVN@VOD=9#ZbJ +%o`R\NZ?m-=V2u2CSk1)JW?G'*'*b4Z1.(THgKIUbt!%PB/F/0KmEX?$!IOTDaFlFm*H4ADet%Wpt9fp+Ku +%dQWSZ'4.f)GBG;[.&Ub;,S5s"06PRGNGtuh`dO69BRgObgMDhJ?#80&cHX7'_8B1'--mVAerr`H\XhtI)*L%-8I3kJ_GHh3gd6_D +%3O=opD05I5jJ+;[CMQEeUH#87XYGmkH?Mp6<;dT4S[Fq)3sORXJ@M$gtR?O+[>VeB9Q85.c3g#I%Qc-A2n/X +%lmZjWA=,5on#X$/n4<3cD-+pb1r="*D?juQTNnGu]6^bFQ9NF.Qfl1jo-?8um$hdK"LMN"7gV+,Mntna-`:;lh7r5=e(/sfh>C_K +%h#@?s9Bk(Z't_pr-OT2lF1ce=M?umFkkGq/+&Be8-ZZNK)W%CNkqr("l(M>(7dj!#<6N[e-'V(_Bch41* +%9*?oT\0Af0)&pp^+n-WAMBcM`%V;]PDMSa!P4Rh5jrd"JEX2F@l41rB-D2S&&0Vc$9VV3b30(h&@O14X-3Na.fcj%.6KC`hL%p&# +%r%+QjeKo?,r+5;mOP6/r7)H/Cn_'@ug>F.Ym:AC=LFa]2/Jkqf_Qa+jU.c'&@`i%3-J\1R<_=t(@]G:$3fmR9148a8"0i8l]\H2c(I`-Aab9Z@:7']c3V_jE/kA8/+Un?8o&-7*7Fa$'j9#RBSc]3f5%QJu% +%YcTNDZr"Ef$FY4]kZ3_LACdj%W#*AUor1(k%!'%6XAKGoW:O!IVu!(';^UDpn:Z3-:X)gH@&c2_r/88as9poEsT +%>_uuJI;i!6E>"/?+OWQk8*!S`iooA=8g>_q_YP;"/u=YiO^Ss.3)sb_;gtN0.4rj"mVn2Th[Z:`(J8;D\r?-t4cKG%&q8T'5r&3fZQfDB7:fa(^of$eCT'-rVT'=X5#I +%nfsT&?/`IW(kT?_d,I4C0C+3M.:.^EKdne!7\8*DN`=F/aslOU[UrHCjZq_W_c94[:$6SQ-4b)pM/eQoOElC`\I'X:FlHW-/M&/^ +%Z;.7HJos:(,5gtW)3_fm)@)7Sg+K9a*'N5*8@N1"o-:W&526kG6i$pndk]d=N`l'RH5%j/Ak1TKku4BBLH(Zhg8!M;l[0@LuqdfdZJ:<_<7BfedZu*NN&P*TV\W"%UWA610drAT&1c"[4RbUXlF$c"*n&j#Ttd"Q5lZPO4C3W&`[R@ +%o2mLTE!G]K6ED*8E[o6,qB1Pf7fmQ;Oc=rXYAUu61(5NXhNZ[mRop&oW+t:jm4TC0RrU-S0f;'1`1h04OSrl^91eD=PN)(JKBho! +%I&1thSeArcgUr//)[&3/.3Qo1VX=uMsh'(U&Ep?]$Ze!hPNDRiV:caT+[HL-)-_pT[Q5\r7Z&"r5<,F!P&(&SoK59_cf]$UnWaQRBH>$De^ +%2&0Y-AQbePXm\^L`<50IAQlB?/KlVhJRV.9Um;U"d-YNV5n/J1SYa-/+l9-gk)CF(\7CSf$TWOp6`P_=p,a%mNUmLg.1D[ +%b\':JZU<)cX2FM%C5gU,bbX#5MZlondDV;u_a[:M^(HQAF6t^KTU)7JEFCk2TpSs">Nqe'\-?h@@90o66H+l:UFX<+?e@+$0]OeSVAZN#cNl6t#\gYH=Bq&M05@,-2C16MZ'+kOWQ3&3U=5HHNMI%aph7(T,'n"Mh_r$' +%Wh-A(cPd4j2C$FPC.^cd4.HFOA=[+nF?b2,\\dc5gbp"b,>a9-6)5]+CQ6KMGm&\-J]b&fVcS+/ +%GRE^^pZ`q-KWVP,@'Yh'H=/,#a^iasR%"#,>(Wq";G#/Cg4Q5QV?%?rp!@0bMFsb6mUh/MOfI*=SP$q.p4Vn-R,SiB5ZE')"(=.) +%8p2+50bpe[S>k(QEpl&W\_/@A+_\2\Dht,)'t0LI>fY>`%rD0HT<:)U(J/ +%I#h"t/<"J5p3;2;NKiJbm85:S5hl$ZDR&09nfEdC@Qf+>;UUR7:o0u=VIh(oe_`us%%"!gIdC-gfj!'0fH[36Qo2:h7JBE`N*gZn +%A;R-dMK;lZE=9KmhQ*J$X_f6s8Lm`W[oC'+Bq[EG*#nll##9e[jjUfO\N68=,7+D([hUJUB'+din$+,WUK(FN-e_;WV9M0nW5QhM +%%<7LY#a*f;(3F<.]UbMWJ"ClKX&St86C\OMert;Wj!rO\XZCBFWGqQu1`;b)6ai]TdI'\\;jei.]3/acOh?Nj.KgiW-u8:7=`2OXYukq)CE1YULNlKXkIEG0@OH]j:Tj1P/t%" +%hBeSQf.5++^l(r6-PcB@M==c?V#Fh;rXoNC"nVS.Z^144Cb/&o\;ZePWRCpW!t#3L<5QELKaLE@3fM4=$BW`gUX>oTiG`&*0gPD`TiORAK?aFAei9Cg;rY` +%*cf(.41il/;FOIQ1VZ8]8--1dp(!@HUKb$:X>G]6a +%,k?ba]I_-;'@p/QmR`\b@uZ2dKNTIZ9dnd[7Of2?R&XorsJm08$"SCZ:YcEY=ceQ3M;Q)\+ZdSLIT+^/85g+b;r7*T.M3<4WHL"%-DgkN!j-p,"!c +%W2l9=Q4u&0.9g,"3;s#=PtQa$jK`7[bH!25F!g4LE9%p') +%8JSBRBghAYe^>cX%]WXa)`iKmO@Be1NP^*0)C`?rlsq633:LSqe$1OTQUkAiN(?THTHb3&b6)`=9eer:Y;3&.]""_U!.f';G_TH\ +%s,>?/Zbb>AC/W@/Z$%&TDM>7.ge/%`[3p4.$26GFX##Q:_SgU5.61WB)bq[q/2Kkui@J9t+&NS.$-k^j4;3M7&'KVf!5d?/+;n@#r\n3(g +%J]i^`*LSrq?ilG!Rt;$5c&pA?c%)/O\%LZ52&rg-YAkqoQr_@0m4X^uBQZ->b"DJJJA>c<#/+D7)6+)06t9QXK*oai,P_^?o27%t +%#H!;,G?MWuVq7Ec047;*:-:'2!'K'%aFhCkZ[h;\lY6h,/%bi:7rd3dkW)b?iBbJD83KX]1iCEW'gadJW30V`^/EKK6R1euNcFBX +%7V^So:b=4HN3G=f#99&LL)H#W"jg%[TrM?>RT@\K^2D=5I1K#.\+S'l!+HoGMfbI[%kHg='tUY%9pa +%7<'iU\b!<]-fS.nYZ,;@)C./Vi!*7D)_L1r!a(?r>Q@k13>SBkB"jju"0AKW)?oM`YrSc>GM#nhW(9pIq=)3^9_:k;UlK>8*,]BK +%:kbo5qPi//!ZnKjiA=,k8qB2F4UEKmo(AK7psB,Rb,o//jegL>,?#hU!;t3I*kkQ&U1k&=,c3%S8(OX-NF@.nnA[;nWEZL%m?Cg\ +%6"I6q/G1pp_K@&dRUQ6@+]5N]rEb$T'R3S&rGu5/EU"d98FLB\Ls"8 +%1.d?AobtH%3d(YKN6n5HWA_u]; +%Ks93MA*cEW98+7ln\2%S2(+?k&L*i]9XO_Bd"^i"gb?:1A[E;cd$`J(`GmgO'7$*iga8FBoW8s@;Tg]KLGc@=BiG_q2$BtH#?_JB +%#e%@-NW=SdL;r\3cEoT@b>X@Bcr3'P)d)Lq&`hb"SZA\l4!m\og&,Sq^&,FZ9CS%)PXSd!?Co=WFZ6$1qMl4.Cbp6VIDdEFdP3Z^ +%U^f"L_h@.Vl])=l`V^;"^K*=g-[2(b9Yo@-on*aDRmk1hlUW#887"u(5-0j'kftJtTH$epkfg:4):6AY0p?TkF]Udu6Zf@j:Mucd +%;M]=`>fFF&Z:[.p>cSR*0Z,qlVm^os(eC/ZO?D5d(l[NG&(1IBXH1+LG@5%^PT,)*OkkXmN:Q[uW`s;]rK9PNB.VZSoUj?:bI`0D +%"2eIG#&AX`.:3K+SSrE($YuM5\p%=#@OOICGFf)p3L)-j:EP,%nDS4OmIV%um)Sso_uWttFf9cZ@Zii@$E2,UaL +%iXR&+\"Be`?JM8u;@lMR@fm2lIRrlp%<<F5!W<5st(%7(e"$%H#@c;qrjpMd:dfA71ol1K\LLd6P=9$t?QJ=l^uGXVc($0kW@i8)jRQ +%hpfsR6gX@Z6H;!+J![3Gp[km/2+SrTS#]]i&pOjS@jG1RR_F$Xl530!AiSjr1%#>bY;)0f(*SlnfMZ,VAn*TX1;+MZ9Le9*9R8PV +%\"Fr&3p8pG#.H*?J2)Z*d&QIYb;^r&L-c634YA9,)M`+aeE-"Gj)'Z1Dm09Ep +%lMt=ekLX\df+SiNYVm]28AD\cIg+H.LV[j]fkp!`2hX,W8,Gf:hKUU\6EeJ2/rq\fqrIl( +%IH^@(]>?3X+l"Rr`)&8iBlt*p,-E?,Fs)GT:Q-4?@CRiP5hY)+&LB\'7)KS)*a.qq,5i<0,062IeJ>[C``dQ*2OfXR>3fHTs +%gTF_aI][JeCY#=uf33lqrY1%7)?h.4%!h7CN'YLB5cHY#j:^iV.)q6E'6Trb%bT[TYVj;7aeDfP)+$S-Y>f`h#aWnlp-8&b=..VX@1>QJ[?P)@mC4*Mf=NQHh,1p +%7cWCVdc@Z!+X`'YCNfjEA,_eUf8rPB?;mcfB*YJo=jI0BO\.HK<_W\:k+;(*f*']M,!E3E<+s\rKD7Y*JjCuq'Q3Y5@F`7SRb"Er +%.lS:3ohO(@jeR4!Mr[>gMTI,U@jG?8eZlIP06YV0ik!CffELX?.moi/DXagM9$%O9]s3e7j`.HY'<:gHR=b*&Lur73,-7SS3(og3 +%(52gJTVkqsU1dPp.U_Ed?FMlLpK:BNhkh&E@*ocrk%rX< +%=rTT`-YbNi[R,8ilkE)jG2nan/tP(j$]mhL0'kq.C>!34H\qu/1$<;5ZKjr$HUhARWDKu+Z3!^tE7=MCfRCjff#]1j.,Ogb2U<13 +%#;duWa_fb?M?TCqkoMQ2YY`u3YA[2FrmLE^^h +%1$<-1-n86%r_NpK8dKiMnr85S="?WW4@&ktL]^=?Ipj@=PF2uK\Y(0u5ZW%q,M-bN[G?Tf#Yf*i));>>Ai5H,]8hf#7;Bdljt\B( +%>..;[!2'cYBkP^7G;^)&.^QNL%GC],8_a4.RA1c0F5[!WZ"dLM_IBKK.(gjmhiknXdnFJ;R,fVNH/-s<-)S'hD1LJNn+P"*.J38l +%kcOV[3`*Os'R0<0mDu>"0EB'!U6f,0g,0S`?E_`;%]WprLkmMH2'(C:l4M2&BOaYNXK-=Md6*e+*I[7`*b''CYC,,[\9[blEDJN6 +%RJt]/HGFa%$[0/6*k`dF%bMF5266?-2Q)Q_+#i!jl*.gcb-9K'^TuN6+tatO6F#c+qB9>([?9#)E18X!j$r&Qri,!kFAGP9PA*4S +%kRs(&6(mOKN#K!.hAB.La2+du*]>lTVhsMm"'P(HqZAHhH_\QP]Z#IU)VZCr>?op>?CaY##=uEao'r&kGOoDE&n\\A"E!D`/qSu> +%*48,T$it]H-&dH"5JLcPkU-isq04gG;UdDGb@HYY-SVhmnZ@\2O$>X:nc_4d!Y7+!)OufW[pIGeK$D`,-YZFo*,Y%(,N!me*6B^ckrd(6(j$,,+ru794R,[W5C>4g`+:%*6M'UU+@D`R)WD5cYWi&QXC< +%P=:D'EuN#67gTN*cr8XVl8oSd5dW_NY +%`![ns7dQ/?iG,M5j\SPDg32(D6[G1f@iiZ/Oo,fh=^7*.%b-%d9U6$j7_Yrl#deSd-Jli'%p,W"_cfT$hC*'Kd3_sclXp9o#$Y;G +%g)$e2.ekp@A$I6d("bY4eU90.41nW2,B@s: +%2^4TGOI+/m#rr0AfT.201I65rm1-R]c;f#<23(,qUWMj[&"<4NB0dd4\!D)6P"C!Z'ASJZ7$WFo +%L/[AlVbK1gCVP>B>?4`O1@_WKec)pu%.?a4B+l/<;SGj^@^jNnH4E4i+iblmpc30g?@:=NpC\p)V)T'=t2Z"h#1#m61(c)k?B&]&2pdSU:Kr_V$u/b?$XhZk!l[_P@FRgptfDB\/9M1\>F)O`_)!_^4"N'(Dbqr0Mj!M\fC4g3Oh]kK+&Cf)YJk!:BC8p7KL5+u$og*7j0gr+sm3GIf$DFLG[ +%WmK;hfj9'e\#nNEP^e,MrRYt:kHi2fT=t+!PLj0trO2.HmsXNn2g=`'s/d.+*a_)/o[ObMIsUjq++Nk1(O&ZY5(2tG]AGZPqHM!i +%NrT.,h`Um2YDn&0adY4B?@VrE?bC[[g#k#;n($amrq,k2?bL]t?11!1A,kJ25QCAf?TnAWeP#i;#;:Pug#m$ok79fSd?!2?IJ:u6 +%YJ9lagqA48kG+Y6qr7CC5)0h*FcroMb'j3Or-'j)c)8ae.'5 +%29,\8!N1hp#ocVaYDYE%bFs^Q"41e?Z@(hAb2[9/j-t8]IJ;"PcT_BVh)c^+nG_J.(Jiq6p#ZpuG$A_Omerb!YPpW0Nq75H +%rVl=Oi@s!RIP/AbN4^b0ci<7bgrE0"Xi8+GB*3"MFZ4,ae9fNM@I;[89M^_I;7B$?5R,l0F^%DhqsP&EoLr4t%MN4Loq)2X1W=8B[@Y +%L\20Z@$SabiQ+r5:V\$>hYgItWu[`WR]9k7N@]FE/lX6Y7\qUqV7P*f7gJ*",_>>Ne%$9Z<3lL0"`#S+'f3Hk?ns&iD2Y&im,g,o +%;4[/$%sVT2:-_*G@F@k#*'un=ei8)2d67Ffk5HWVFdpL4Z:LPpHA0q+_Au@#M-/L;&)W2K>9P7S&3;;9$3n!0/F)^uT%;AfRr)V*aWcE/MG#!a-E;)p)Rc0/>T@&ksrV`_C2)Q`$-d$G=u<^]>To#M_^ +%nOSS^OX"C;I#(f5.A]uE#h:b\F4k3W$m;s4W5dgR_22T[h)LhP*?15==$C!_K$sM4$<\o-KGppH,*L?5-cm:7?HZTgZ8)MKgh]t3 +%F((2aG9;+BmK\=TNuCb`Zl+BI5t73h(nfJN`<-aFJg +%X'jIs,mV(C.@\Ci)kib`P>k8r:8s+24,2rO$j)6=d!fe9V%VlH93q6d?JCXEpD/>_u5)>U2K1VP@&g>jICjg/fTBiP#gs0p"2N)j%('_@[R'Z=Ng"j3-Lq*ic/ERuaBOfsD*=`Y6C9.M`1ml\]%i3ms4UWT3P6KX+@D^$QfiV9bmqb*$?E%J7)*H<)UFK.^PFI?u"t0iXCdfd*ClFRs2*nHg1&EVL7S99Wc9jB=C140ptUuc,UCiAsR^c848"MB^t2q87KgNoI_+(\YbC,G)Kn<5gP;tPiQo$20*lLVUkAJ3bO:CK87,sl,?L4 +%]c^Kb:OJ"Fs1pc>1Xoh[\:_lBjGaOW,gR5b\?J/k_2]e^nj[7>jmIik3qk`;4^E@#VN8@b`6*X5ijB"C/&tq=qV/tX"N;b"Lc!`8XAJN$Y@;nUWXm9IOCW9LB8=Ga,P[cMFr&<>!X/*S1m`'_Me(F5^0P2\eC(V-%m^9]i9At'j/OKpgElQ+n_pnlkI?U\Il;-oP.PO0M-B=FCDt`JEknoJ@/m[;9f2c;$ZLFabWjB +%ZP5>[$mqhG]?@79EV%_jd,DO,"U-k\F1uXfgo4bjOumZG&,=NF^]#FE_]"3f9of&9,6L74^K\*;m.W&1u(nPOq4842LLH:nWGU5O'Io8>SS69-$WF$n.?W +%o?S@%ePteS)LKRC_&!)7@oZp!qW6NtVcnJ&,cl=I]G_3Ak+==cuD+MY`PAf+pVlOLBasW<0grQ(pA&66`>1"g9=[ +%cMW3uaA\+(iR4(?/+"Ic4el(>$S^3VI&0PYqstb.^1BtGT@jX=R$n97Zifa0LZRmJRR[u`pZE+^kE(',/c`lKTJg,2'"(Rd]_>5H +%7IM\3V`%rI=6"lAn&?p&h9i82U$cud_T'O6mLpQ,.L*ND@B?5cOB#\0L1@&p_KT1:4;_r[u+SK?s@P^mip(Jf\Bl`4[= +%@/&nWB@l')ND&k>*U\Oo28&`45h]eYR+f?_:">>cd&J1:,`CD]*\i_tGr6ise"uHVTd8J#.b`XF*/-2]YKQ.^NLg +%;ZHn[EN^2nJYW9lhY7a9fuAH$gQ3c:![V]^@Ek%ojn@gC_L45q'U%%U\HsFM2d&pTDEID]B5UrJb'dT4oIEeM*=FBo\fDnD!IJhA +%XE+,eqHTGCts_KfW=$8Ek&?E(F3IrZkmsrZcO$5ibZC`>fLCC0*K=9$PqOX +%_M;7OONhoO.$E\%/]c%f6actES,9Xe/=WEDJ1h^ViI]0f:?2K+D!pG;hcr.=$`p\FZ4#6i3P>e'FQ"DsaO''G06#>$H7p\pKqlA4 +%9:K/#&5LFK?Z;s%@)9]TXiS?\=`"1q"j+=]="F@'(>N"gY:U0gJ706[P6E2c67`L_k+S/r9tL\cCe1uLjOl5*.ibo>jNbT:%8XH" +%9cNY@"f338G7J"tLqXVjg9?&W/@H]*:ZU:MXO%&eBE[A,(SL4uk-/[$>=`;.kcir5>Ynpj:KKc.JS0qSqBkcQ/$m_E*?L0pMUIac +%LQ)1qY81ZjRK\`)+"J4kP[80UYf'?";#5LB,e,@jh7UJ&R+3#Z24a@+TDU#1j;8U +%CPi&h>=($2(O,I'pkBT#=!1"u\?TI>jiFkg#X=kJd`H)mPc*-n5j8iZQCLbJXk2a$fR/L/..u8S^2bgc]\t2h<=*.BXt'Prd*3Ng +%]m?6>::)f),V84Vcdpe/$m'CMT#`VB$ZW5?Bp<:/4.U<02^?F!Q\gHLHhr(EqHQJUCRiJ-[ +%Ib\P]cAU+%d6igDUZeoT&Pj`XF=;"?0\LWrD=V_WFr%;`7J4Z''Pb9>A'UTedG8*aaF9K/kb+'hG1ICJX1S_m9qL??[QAf3/*AQ( +%Q)eXUNm1dr+ASbQ>is!:C)eIZ^E\7b#npk_PZH*?dp>@Y=1>HlU'+g:ErX:kqrAd9Xii.1k_=Tg;*bWXkkt5IuTG")m&9IZNcc")&nkUnrS_6H3P^V=UZ;i7\D1KG<$kM>sPVZP#OTVu\HiQQuAc]WkjI'@E7J^=30'i!Pa<$]JoX0sYC6Sre@$^6g)@L-q8& +%GHp&a)?%/-K-e#r>j[&\q&lTA5o3CZ,Z)Y9M-b![!nYdR3^cOj+u_P@_b[Qr]bFd4[oeh#&G'?dBI!hN7H\O"\rHY();r6A`K#B* +%1f+:RL&Ih=O(co&H@jteX4,mp5bG]+dYM0l,cNaTrSir_(a5f4IsE"1/Y:pna!,g"NePmS,pc"@KR!CR)cfXZ]i55'0W0UVYgR^j +%!Q[al..I`N43cYF0?OS2lI5=;\rZ5*2/+lE>@0cRQM0Ru)9U)AQ&@dn=kQ:'NjGF#nlB>L]M@s2)nWltXpj#%F4aRVC%r`+SCIIa +%(],dVZ$O=EXt%1^hEe:Z*Y=4YRZj69k\,X:e/YC8?W*IYHI9p[4p6*(8XS3LVmoK]o,J%1bN,dt)mT"bD=%#\8Q).m:HlbXKCdN_ +%aOri,cG^B>L"+Pp8StZjD,mDd?Jo5SSFDBqr)B4"alHuW0\Y3)eg!khoL85NVXHqTpC`3m$'T+_'LFaSso^_i.t_o6g7@o1J%h:6B/[s5ngDN"07g/p7/+n9V>B*knma+JT +%6!%QGj57mK)ng6AMn:t+iW,DX:n3kNd6Co?cc8'IFL,&h-P_ec9[JqN5)EN9$L3)q7];Fo1g[kQ3&AAP+uI]h]t6X/#'6*q%m,ZVe_W<>$T_YMa*s4b@-8kM +%/PrY[f:&k@@_jOpm^(dsoR1;.2=,k%i8-Jh)nJlo`%1aO9db[TQeI;W4c9]S,Pu;\=$p6JaS@GAYbUM:Q*jkP$=RtROu^6Li!JO` +%Ks8];[Pn2'e_G[4[R;!87)n;t9Z$s/Bh-u:bB=32)L(sJ?"Y0$h;,`'o0$![#Z8B[O-Hl:cEF"q`f-9n?dRW#Zg3]h@--Xan#%=@ +%(b?o8$f+u8%d&>\RiN$?_r*Hi+P@=BAA5lo0CEf851$,3?Z-Nk^e4^0A[lqF%H\EC^6i@k@rj`=9,Md%`W6f)Mb`#FGp0qUZCc'A +%3rs6&iNj?i>fZ4!5i0s!hS+?[$Tq](s#)"f/]d@G(U/7\*iRX_CbKZ7aM/?FYs#*U=FA!QSq,RC$.WkXoBWEB!4d6!kB5+[<_\0_ +%Xa@&tPZ><"B&r&,MM6]j\+O!eFp +%P(]>%i^RHa]L>?5Dbsu,)a3RPf>(tYg3"%BIJ!U][Vb'=\;g)CjuSV5<7^P]O!tjg4:L(U-j.oJfLT&2nJ<`Fin$aUcq\tni%gNLUE!V!YeKpQ80(-o)oNmWW7n'JnZc^PD-=C'duE]+Bi7?(hPFZ93eqa7gC6!pgS&\gKSfS?jJb\i_le2i8Kp)#Vqk,g'*3tunk_]g +%*he>uI.t'roQW7FaU5XI!F44jKA.uTHsV1U5n!_Y;I(ZGNmKNtG%&`[G[p#04Z09)[?\0Jo,AQqAR1%9@gK0olhe1e;gX[^=L",Z +%$*?1m%-[o2TJ_8K.e=.8o&'CtQ)@f'gkNTsUQE0HXXB4(;rM?cf(7[pGL>s=*U8)[U=OXLP@H\gmG\VZo@KRn]@_T06MPH6[^SN[ +%h?oVX7KU8?[@65n^9)%T'm!;+2K2g,Q"W*opH$1(3#Jgej.+po?BnX&Q1tKrA?3G,cS\KT[Mfo&cd.u\W^hd\e$4+ZM;2Mj^P]9` +%'2nl/**)?udPL)-Ca'm-q>cqoh2C#Ih]jo;(Y43#e(9`;R$$Q<5!2rDBmQC\hEYt8<7?9`8c92&XUmmV29DG(E0O?eV:`KdgOd'N +%L>&L>OrT@(E?f*M!l,;Q\JEtp(8CNN,joU(@:W>64CQ/rPaV>e)hC=gKR#-``u-&1PdOuTmkItt:6C0s$tQo%Ho8d[D;53?!5:c5 +%H@]aQE$<8+G.cr[3)(#OC-g#&2FeTUcA*Xk+4&'S[KHZN8J#bm7Sf[oN-QGKn52];.tjYRi_eqtTBfk.NBi`q8f]-&*]1d[Q^A3J@m +%9iA1KI:IB+jrhj$]S)O,o!tsmA%Thlr3o0lG,1eO,'HYR7kN$%c4`/h`!dPc7RMK@Nm\Y$d@XV8eOu=k)R$^#90*dZK^Rollop'AlJ=#n`s7P0AcX%`>:a#;=fs@2u\tn]HU:31>I8i*clD\ +%bG.V]n?>^n)_G3Kr-UUa,JR(je7#Tl;(r3r[/b'@Z;NI +%Rbc#lc%:I)#LMW[a`jl"Ca'f__Sg8-@r=#?Dpj>="+YD][;Jo..@n-,3Z0aT5"h]>:oYq[R*M]@I0lG15ZIklK8g69R)f?'"Nnkg +%p!!c_=LZ$e0IBf*8**LInM!EN)Q-60,98G60#EWfITgb!Tn60/"Wi[t?DATT-%b"Ec;%GrQZ+[P%9b?*pT)^/EW%"#Z7n-7DUH.>@dIL +%A7A/f(R#(>6pWj@CNrClnH*L\KXg5RadmPKc +%X]/$eBItEI)PBP!0u&?ERtkfk4d_[81WCI4qdql@-AMiX6?U-(q(P[ZAsD%Y<]34PG_p<+fH%F-L_Nege[Q-omn`8tFma(4WdrUh +%gqUeMkVLQ67T_#QQ?59aQ6dC:TWW,8J(\as%%iB6YOYm0p+n#P3g[j+,k4c,^`M46cuCSdj,6p%g[pCSh6R(jg.OqG0ZVbqbJ^Nh1o+$6fB0HQ9R`GgjpPf#:U(I/I+=Z+7>IAbV'+8k?U^$*(4Hf',=aieUPo&fUXInpO'kO3odpMk9Soq/mCrFB1f9b7-odoSb]nUpSN21KR= +%i4EpAHMQP*lXr-YXJCf[W4c=8PY(:]**MGAR"\NrKJBdr4G,J*3"STD\Cg +%4I0`3p,R+f>#%bqs2#efD`IelaQkgGJCZMh?dDOH +%NV>[8hB.gYnE]kK^\2#^r7OkpnGE7-fC<)6IJE*rJ+`Anht\1>l>QU:bCB:OrXWrHS)=&\I]NJ(J+-86r."Nh++4U5ocO4mRt(!q +%J,)lirce@J?i=o.a+*^ts5K[LPLk^]+iEia;[LJ,]2WNhnK1oRH^Ms6p!\O8nkJYPo.5 +%`j`_XZ[_u#s6Ronr(hh(5P8g\I.Z=pq>^C0s60?pq5aOpj)t=ps82ilB4(Z+fC2_Rp>1;r&,s'MB!Ad3M;'kP;>Fr,mPAAZ,th;-0Isa,_J?R&1"8X+AjCf8T_DVR?.7)B."EkMA8s +%%rKn,pY'Ddpoa9Rn+6/g2/Z76?amrQju<(Mf4nk+);23morGgmTDf/spMAO6I0TF^@fECrqAn3df3)VVsg]Dgoqci$Z;j"J@jA@?>SigDptr65nE`6Z*m$6*]5.Pu%j\D58QhYH'$e0=ma"nahM;kE\t1hp.'E1XQ>ubbh]WJp6&IEW*h7jHWZe)"QXuR3OI[k3$$rQ#"bnX,32+ +%n!1q3]o[m8=uWlrJY\q:[U\JQS3<&l\V%c'Ll*=NS?*J_5O=GPS??5Ph +%PP:^W^L,AQH%T(p_4]ISQd$Dq,0r0'>-(.S:]FnAaq*5EH/)V>au:,hY&XL>NgVJ_`^PHYh'OfOFRdje2%&F7pj`08j<*i6T=8h' +%2_2m+:48!s\C9G)2hKAeH#2#mnk$U1SN2#qVk;6ReLJmOa?(!F9(ZH&j2d?'9*Q[)"BVF^?U5Fh>hV'5:!u0(7cV<,/RPb.poHT= +%a*nu8ZqC%!^@1^ij4i^>9%@_7CccS(Q/K":Sldp&WA'$@p\f(,WmBikA8qLr;c,n4D8>=i0&=0dm-?+&;S9+/n22S2#Of7th1E(l +%F%4"?HHfR+B(`GY?*!%#ec!Z5UNT\[rgt:Hp>Gr#,ASVOcTlDZcJ/RGG"TnL5i7s%t2N%_,J\XHfSPQH7_2q +%N7Ifl%t$++6/oaX@G%%/n6,K]YNqr2r:Y$Kae*GLB(LnZ*T%/:'DH%PJ,ZX68p!,?hfB[TlM3S9qNjqSX?!mF_Rt6aVp@.45<35t +%nu[95Cg&rsDKm<%h\*D/IsgLWaG7IaABL4EY\)ZS]mXdRpa.LUD"Ve81NMrT>1G_6]3_R!@,[E(8+pkgebS#T2/2s^oW&.j#$mY5 +%X+%hmD]\pn@[$"(HbIZo4"nB^jZYZ5Gte.Kla3.qiS_fkqcAc8%*[TSm?.BQkfr<0*-CL0d/LR9'`)qpec>C?4jq>9fegHVk/)`9N[IXfecj&^/h%7YSQK)b#0/^i*d\jgd, +%]\R)^!F.L&D]N%DWh,[&MtR)An9'%W0Q6e#!H_qq)`fHn!I-'P1./km?!ocj.51A`5HtufsE?/mp`V.gp#*A^*E-]B53ia,lJ`.q[mF4Z@UGAf]DTGZqQM'nNN'psYI0sSj-[$>a#6\,X6--SK2s!##2YX$e'l3^ +%rl8CGp/L%`ra)l.siXR$;Ll,jE=qc!"/f+6)@*9R.1k6q8P3_dE_6AbH*1oftt +%*T-)QnX`AaW5Veq;,MW"q@e(jGND#uIXKnj!uk.q.6D"VWI*!'^5-s#k;<'qK`0O?gJLUi3/b\T;kBD=+!mUGR^X$CP +%r3DfiFtO`!JM/N4nuL6U],k500roRZ)a<_fPqWi0m34DlGOF+Z>e&u3DY)89F0O*U?9c*82bjKFgK?V`5KJhrDP,Uk@U)ikhZX1o +%ou!5,Q,7'%LcrraR8K__hTO9`Y9-l:%>4AnqIA+u^QnSsgcK.m0'l^ffI3jbEJK=k=-Hk2]_kfVgTK5SbJu3*YLi&%FR5s?/P:_>>B.SBI/;EVc[-I` +%KT\J7mCelhM8AZ$2braBXiUj:.W]!_D9=ZhCXq/4manj?srL^!U9)ri=EFa&WYbl*Oj<`:_/g,eY^q>F#\3 +%<3=d3n#g]Jjb#'R2(ZiE[dH4n:f\iGBT;jOa%W'Y\4ueGa]`u6f?fNGr4%%afpp$ncN!&!mA-(Ss8IpbMhs+!I:DU5ZEZ@B"Qk9ZQ8al-)-%b1J`j%DO.JCPE:^S6`XA%n%A,ao<*&+b&k`bm&<+r. +%]`se^PTiiBY<$VWU#Y#jZ"@[;=KK[/FYnjXfDQ)h(Nd\-'e@jYjL"/]ZDti'^s0lI5F=LG:]7L1$[5`nr(c[^UFZ2,Otr^!MkkR4,-Z5q".Y,4(.5"GRa`^6MtDC^c6F]4*8D_nF_30gH7S0uTk3&s1p-S,eV>ct9oHK@IbHTVU;&XWYj&NZ +%ir6K,5&,it\k&TI;eJlHoR=G!A7tQ7@+(uKn$,a)*")NnO>_eVC=r?ZtJf_G%JUb$&gV%>cV4(Ni)$nV%lE-dJ/= +%Ufk>rp0uS=;3T&pBrELYn+Gd#*djlt6$qbMQ'p`arA&;EjlqiD4f!.i3%aEpBHO)%#'.Qg,$Mrm=-AHe#Hh*khYX9hqqJNA_kr3tp3)V&^4o +%'A@j0O*B,u/aGtdWRlIK`:86pC%6Je.eK4DGi!Bo:23S]"uF)\SPp/F$#[ce#HgS3Mf38H^?b(`KiqA@DTflV7s0;7ET^G4cmNVC +%SC[kte>tH@%5,n,G>G92E*qu!&XtGP(;%.jH7_fJqlW*,T*m.]/a"jljhT82gK-oKR+*%`lJ(-a4s&.RDOi,&Vm!!>E+Aq7pCc?u +%CV/l=Rdk;9?I4WPTDIqd:4$qtbCgdUCU#c"8+^_kGW>5*qmkIBSN=JtrSfgZ/R6!\`-!X-mA#RqP2Gro)>1.ZV`"r6%NjGDjY<0k +%n"*cCS7^[AX)o78]Q]RXPHaVq^-$H3f$2C9NugE&jQ'mDE:0@tC/D0g44D2fQS6.'n6,5.Yg;0U=Xs-r&"iTj:FT2Va7/%Nl6g\5 +%?uraI4:M/b[r:-9*R7%(%P5b_mXO+FdpUh.A!+1\rhT]I-hR>po6hG)6e;jmDaWZOhdXCbiEanGG+'/#Y!//a`l"Zla1Ntg^TSG( +%>GY*GnCbWcNo"dUlLE\7Fre17QLDu!Bf*PrYEh=lr:!IHik#DBlh2_=Qkps0:N.u!5>fBr/72Ct:[IJW;!?``.rkK'VQG>d<7?5L)#5i]IEa"]BI%W,W%Ib(Y0.6e3?n_34PqtKI1GPKgi +%o2fiV)/dPtn6J#f?`?8/qV2s@S&@Au.L\o)>(#/@FoCUUlSn:fbK9XQa;)&u:-U&1-8/UdZ[_fZd9"$cInP7DALTWj&Mu6q+ +%c[7g`hk\SArp\C!c*KLMFi-hH2OmGrr1<,`F7.sF]8iJtG4jq)&"?(OIBU#FqK`iTnlQUM.^4o4]@ +%F6-['G&!$#]8H@[r9,fd$feCj]4]WN^8obV097K!$@\E/`clLi8)Iuq1h$ar5)rH>re8GIbZj04"?:pJ)])F*4`P.>W]<%AFAiioYB!a +%lbacKgblQ.\Gn%G0kJhU?gYaK*a:e)IV@*+oj4rmi\.fl`Ei5`IP\H;7pD8=iEH_*1W<8WU:?YTR81a"O[="mO?g^!ur>5::#C!>B5.G2"Zp*rF9H>9b2'9MBlhBR[4R(U@ +%mbPBtik*I-:@6NC<1Y/M[i4o;E93*%0&1i;\(qQQ_FJcd=>H^kdkVHO3PSap`PC0-^--N1lKt58\t&YAD?N&hh&ASN1TGdkg7o50 +%L!$e@3r=hP#C\dZou?C2p[18eh_<,sE;0'cWu'*RpjVt7cf^>Sf=FSZ]T?gSl](J;qG1>$B'\ISG*\:3!!3KqGk)pk^0HDOMXkGRU.hrg7Q]dhH5mZCDAR:5,S5O2Gi21+Q33=[j;j#s*%CHNH"2K)ChC7t/5R8!NHPOJ43LtCaK;34:qTpKE@%>)ZFb/iD"?KJ-%r.$RlZa?](TU7D?ti)F!4B&Af7Ep-[+Ei)K1SM:+9)tsC3LZZ:+-N8B(:k"#Af3VY/;^DZ+5,sH2.2X$]H*\Q +%#d\ZAEB[P+AD6[DJ\s"43S63b#p]VM#*DBJmii2ek_IqPJO%L+)B>=?=Ga9#!F]Dp>"_t"JUr?-*eHd-e4F:Im%?StUt-So=AUpI +%6scC:IXoS]1RTpc(R?Bj;UZ*6QO1CRZe\/&'"s3?)GGp^H(jXd&NBjDNMB&L\fr]QM49T?:e]He16p:j.TZ$i.JF*^MaK$e\fJF7 +%T`gDD&m$M"bGU&&-a&*%LE]?DdH';![=t$]i9H2WA5kF'Zj0nHd +%"+:SSC_H?$Ja>r^%TqoD#7<9)M+hLQ4S3?]UI5%!_T8[og?6jOQg'IY5Sc[7?*b1k(f2#X771Dg7]Sr9.Z$hp$Z&-jI33c.T-P)YJf4?uF,'W#[M(B@VC<]\T(@l=C&k)$neHKXK&pd1t4\OK([f&*FRmJJ,K534 +%W%f0U@p$Ziet@Pq(%CmX4m*E$_iOEmrV)G%3E@i[qub=-r9J8CpPEEOl_CW'%]+OOYt6Cg[)^u`Q`+-N0qYDsZ1VT2Lt/`!6^HJdUpgobXgO_$sRLX;u?rMBuH$sEB9SLWgmJ6f4eqT.+&Q7a+KYTgc#f2ek\de(Or_k=/-/,-.6 +%_1*8D-dXsP6c"kXT[b>sf2tokXn@+kBg8,XGc0'L5MLhgnQX%\X4k`-uXnIhW.>$S8k,k'-M#SNB1cP1(i:+3& +%+,iiI&_3MeDJ:Kt]CX>F\S&p;^NH&*$c.#V,Ik\5eZ1'!TYIN[^RBN@F+nA10Q$d:2Xnaoj'r?u0AcV@48sTfM;4V>3m'*YlOU/9 +%J,HuFg_8eII(ae\,Gr*>$`\CRs%mjcnVc:HJ\PM#r@KuPFBu6=1O_pl\i[H(53;Y*\a/t&4l,&"f>?S65=%8Ve"tr=T>k;$o<.95 +%gX-'%XL@b1DXJQn8"jn?r;l&BZ6()H\uI(U]Cs6k6*^:5/+u0J]se_dV;@1+0lSQ_]_;j/fHK/8k2r6R"+O?XH6G6AaqAgIRir4, +%00!56m^mXa,lH'Z9CU86?OiX>droul&4h8`I+VNaFo;e5\Ft3UTQ91d6jM#g[R&oW+*)GkCrXUL;m3\n:oG(gn3P*8F*;.#n(L.= +%[Cn_r0nZ'IDBZBae[1<&EL!Vb+NOkeF)t,NMm_?]&F%)"A$Pa^n)rj"_QU#sXb4i'`qq@HiUec(<:T"H]*2,]Eb;RYmt80](RG2. +%`m5Qj.8s=@/fas$hZ"/D(IF[AReBKmb_b8iLV[9hLQ.D0m<0HPJEco;-9ABGlPHV7luMO-mEhcgmPTDd4as-Fi"8\8HCoO.iIT`j +%[u7ZjqKD;gAMD`d*^\@3^HIEgAM]tLU^E*';1$YHg/ +%=4A-IIseA#k,(3HhgOeM?ihdln>Gkb6UR_Hpgg[X7fA0bqS+':\ef;^@DuRPr``U3&VfZKrY+Ko%4BID-o#f9a%m%'Cp*q[gURi) +%R=".S+(sW4mJcdf38b`ORbU4J]^D^Q5s=tY`],#u];=`J^:ocIfXcIDD],3\RSFc">FnA-3kV%Hn\^GjqH)=K%M#.=HYbp[#A1-! +%1P[FsI\hK\lGg%e"MJP=N0TpAlc@Xg5,alE?p$0 +%m-cB!$pL8t-P#d7-RL*=C`ZCEi4YA`O"0]l7qi"jqH2%:?#7f1)i5#?JS!K*$g&,9J]ZQXJHhHeO=7;_d +%1D;!:r\L_WEaHdHYA5Ek^8,jfo+A`OZQohs"D>#u5keO7MY(0D-Kr1`g5:nM6pQ?'B1Wf%:_OXtKd%=Pm-_-b%>7SMceAIt@9[j@ +%g"GO:PqMU@pu5Xmmjs9"kTl(`(X\V?*ul(j/[(A5.ZH5l7:,I\Y\XDtI+$3nLd8$nK_LKKqA:?C`TP%KaZ_t/1Qn%*d-QZQ0aM)& +%lu>Hsp,'mA`CCnGF<^aGk+`-?A!+Nf:=st6CYJki-I#S/.9jJZH'JdM8;Mr^_&j"_%=k;8!T_>1dL]PUE0Pi?R2!AOt*+7 +%Q,_.>#0Maq\uXWO=bn#Ig1:^Tc^$9c%B7>I."7;?'\9i?>!82?Z"mB.3`+?s]\"Xo+;q\l_qI_aZ&8bsT:X,!JBXEu0mj2q!VAL% +%NAsQOmJm7+0t79Jp?[A4L8T^h`AJ^4Z:b]h\4-8*SjBrL<%0^aJ0@O35'XO&0E[mP_9:*WGk`nU)Y@/EJq*tTY6EY(\k"oV$6p$t +%cuTie(<\QIc_?,F/2!\X!$?dWOD-9&iYj-o:5Nm2SYh]I)(8?R:F8c*kRCV,T*=;(ODcunG$tr*#:+#Z!Am]M_[Xd2Tr(!0kV9omaKQL8o$f!#m406&M%V5id2bjOC#8WOIGS%!<_\jBRbR +%a;CHJ3l6O__@A'%37P!%P)gf"6XjC^ebVmCemTSB!!P?@.r^b9)^&$P6\0eZ7Mc8aXpH/m,*+^^Ee0$d)J?k716g6$/R0%tL"Sb6 +%#_O'JdD,7:^'\Q+=KJggnq)cLaYYI"8k:!K:K9su^`^uWd?jSokZ1M\JoLof@dtZ-U9(^SmHcq4!MJ.]EV%;0NRFI<2kLS#1kf'J +%e7Do@a0qcH+?S\+X&pS(Uate40Pj2K3U!o_Jl%!E]sN?h#C4IAmV-FH5hE(oN8ZdupoFQ/7kub-PfJGqe9pKaP,k]a]O7#O/7&F2 +%cfQ_(A\eSgc1e'J%,I3AL0#^a0LhNZnc^]Pi",ql-WIbh=paXTe]\5,_))IN@#lYs+S6M>Y8iOJ-US/Q`IUG)YR8+[Tj/2T(j9DR +%S-,h6Z?/`^H(V>fW#\Es3eV\[+XMhd"9bELd"]?#'(?\_R\Bms0np;:$hXRO/O=GN*K#^9dJ?Il]'aUA4LIJ!E=%(!;Y+W=#2N>V +%/h;VJ"j4C4)2p@6:h/aB1>s%M0a1C^P_U +%.S2)kAk*N=,9(+#'sT$9.UlPX+PCmB6B$4GD:u(*8jW`\i/6_>PkJ'1;Gn0M5jOKL;B;Ad^Tgs]dGkkd4oqJ&'J'e'VK6lA\q5kr +%PR.,oc>m"#!2n37(?IY,/HKZqYJRsYAA$"%"nX7)/c_e1#4GMXTGdABlGkS[n6?#eB!0,8Ub%7VW3f[g)i'q_,0Gbk>[ilgDU;0] +%1+Y*[1ha)0.#l28.]a8oan'dS+XRX$cm.,P'u5d)/V0h\,@OQX^p?aXON*Gf2O?[Z7mUHjd".2DdNf829#tSJns)?Q,g50JK#.XD +%Kg]Z0=M9rX(Y0pIaXZ[H4#GD+AU;uUM2C7B-/_T2$Ia)T*RRR"&$Tp(l?M7t%!o9.$Hb,ng.F:6n6E^(!YAb;-7%B4#D-6Q&iO=k +%6lR7RW8$LF&SS02W_K%\@"jWD3Yno)gk'(56N)Lq+e!$P-O[6.GSgPc`RZodaiU-id9)D>7N=&[P(?%J#\jVS:$NOLK0&-QCmSig +%K1$*4HS+*Y$i$6CG*YY6@ER+C'ibWpn]7GUnOjOc(#@@ChrEp6("aYr9:aF1;J^O/MkOY-Xscj5FP.D]N`]KS$#ICDL%D[F`3+`Q +%iG0jV*Mg6=Q'oWdkib"?D+uV>[NgF]%[AAL#,M4/`C!r=^nQc'bd!IU=<$./"i!+0oE#Q"/lA=f#g:PPY@T3\,H(T+aKQ(a-U?=7 +%js#%G-hBd\OO#I/9t"V!-fXsT$tToWYooOa$js#(&P5Kup.UekVD.$0[1Le73f@C*iR/_l7KNiX7T2[[jXZm6RMnjiD6$p%00h6T +%!u)Va0d24XD-Ab@Ymnf^!*_.cWZ?p&O@7b?55_Vd9UbMZdm9.Vo0mUG)TDjS"iWAl +%Fp5%K#nYdsE!O3]^VKk*XX6R!H[VOU9ZI$C`le"N4&!/6l%LtG$GT0.;1h@#,(SQ.>pYOpg0Gf&R/!O;5]j=nAn4p$nRh=@%Pqq/3jgnS=)+B^'TH^Hr5#OSM-\t\X$ +%%3sM3O5S\j!0+r"_,TFM3FI2V$b&77]kh81au,fD_.j%ZXm2!S#-3I?HMk1%[EaPlJlpT4DkZ[mO[_2'<`_T'+m+=ogeeEK:]M(s +%%2r(WF>?B[P6D5Lo;#->M67iTZDe)$AWs(+CX@WK)J?kK4t-DFgBFm.:'cOrbh<^p;JN)'I\+SY6li8er@^qs^uu#QRIM@9D/6U]E$)Cc=T2el-dHf=SD*2@90)?&/u>4dV8s +%BekVRp$F2N?CW!Kb6`r4ZouAlba\F$,((/GKm`!<5a1T7O"0($3kumbSXuTQ3mF)?,?dY#i1sb`k>P-#R97$M,QoJX=,\f?)C!%) +%[lEA<>$H'5"F]bpMea*?/llF8aun-MPGtCBoWf9&:Y;uFK2jH[CQ&-"a%^"U5qBNo!:Qt.CeFa8KEtC!6CJP27<)T.!,c!H[NW&) +%Hp+$J=u9RHH*i@fkZ5BgNo%Q"f(iMn$;0=l*LRl)]M=Y%+AL-@+@(XH#WONhfIHuo)3^,,H#JJp,&A"`/V'Ocp/HE[0H)r`%"_OD +%6mm4ce!/.i9/@o.E6E!NDBt[-iJ^H2ZX>oE"s4Q":#G)$3W0<=P!:$L3Q8NoP_k4J4/Q\uo8s.:B_)O)V"o.992R4oianTlAf+T[ +%$U>o>mh-cmi@(G?m=f>d&_T=gnnQP#dZPT]4q]lbZK6fkW@c,KJ5LEWB_Y%+qS8ela-B`Ggus^%kYbf.ijVRN4"UPD*iTL0*=]n0GN +%brdt+9S3di%AF9';!e!T`VMe>XHJX5rPsgsnKe):@]h-Y,Zp-OhBl708rC7>7s]ddqoEFc44l4c"%93fS1BH9ro[NN:Zs;-qY+>` +%6MB+1CE2G]4^I!f'nQDYg63?6,q#OVe)TOeZLj>RL[(/I4Ln:d;rsRjmq[ajpsn8Yr=6[2NtI]n%6jSnOCPQL-)el`qd\iI7=.!" +%$'`T2(5i2=rOG%58Wp5@6tMFN$T_GPY.Ya$P?OO^V(Ap4FP`';(*ga=!Lkb-e7nFX04uW]EfpW2>V:2r%:#5 +%%_VUn3#emB=,S!E'#.T_JDi'qD-kp[(452?R%6q1o_YRLh:!L-:o$_Z\,sF7%^>:pCVF#B'oTb+Z.aP]nL2_u*#0p=Ln?Wl[]C7X +%jfKkH!DP[epY"@i@^/6oZ9'=F%DCiWEBLb7]G._ap40(o7]^FPTp`/fo@4X!S6sl1(2G_+GK'>NSFTGIT78X(`a[JQ9H>0#Q)luh +%g#B7M2ZT<;i`G/qc(-Z#6(8Zj/7^unG84C[k6tbpYo<&L@sRPGi#fZO/k3Rna*Et@Xfst +%1'n+6:YZ\9.::pn]:lh9:S8M-Wd2;A7.W>>H9fBi$R[d_@YK3r%^-_S%Vm7bd^*`c(?aFZ0(KoSQaJlm0l"G(6S6&;H$[eEXD&uR +%Nu+s%^J'8_7hlU0qR4cQn$Hkp!Ih:_h1mkEB(@GD,,aVRd=Ad79#ID%ca$3eRra]u4I^nn%_&0.4 +%Hq(lDEtp6+X?_kWf!o/QYuiXhUrY^qTl%D%62>V"(1'"eE4\<%B3U!(pS^^kgoZ!^jo2kCqR$2lD>B[AKWi!NO)t_D&9p93bm"Ebf +%/O&""*J0#8&:",ioN9>U3PXh$$bcd#%%2UbtVt%Uo*K)dZG9)eXD\)YEgUTZsNE:r9jH[ +%^2+I`RK*`1\ZnNg:Vg\0S8^H@UgO.FPS-Y>RZ>6:,6`RGB2?iUVf1UX_EZ>K*.-Lg1%tV0(W23HS#0f7Ji2hY!KGn6$L`Ib@Vg(4 +%+O-JE?%XT8WYK!/+Y6V;Uhi62I,C[jk.gbIrhaID4*2>>T*5nE4M>p7cf +%;#5AHc]69tjk:i3qYg*/.O"(<2^oTX6O2-I1H@0C$3lRA(c\[Ff3T]:3hLU;\[OK(MKS`.@_Gn;:?o^J=2c[U241ZFX"A[Y5Ar('5'E1L@`3*'H2IJ(;qEHtNT[-lDjj47Oa6k7%U +%G&E^MD"oa_HZ/Xl*q/b$@fj+Z,P0!iI;o%]&,4Ot3&it1/iQo>7C\sCL>r*n:S+CFDK"eOrL>WacK+0aK^7W,=AqQsK#.8ApkcUXN"2G, +%eU$5=>urrXMaW5BhO'pl+Rsbs@WA_FIk*Htn'>[?F'fH=B]92Rhi.J$p;C=9erH^DMn@DM++?m5nP^sL--9,`cT^o%oX#Fc +%F\Bq&\E\N`4TA+S&'f#4QVtH%c&s1>q*fK[+'LZc[>M!Ap>c+<*`\R42pNH"\,D6,WFFfMWqjIIhk%K,-Z:l!];PCP[:![/Nf>,M +%!E-4;hmmO3n(PBlhnK&:I7(5Bq/IcF#I?((SEeoT87t.bhU'G1UVPFmn1^c`iI3DuO@h\)2"-[q'_)Yu(8<[qY`bg"BLK +%1E/N:U#@*RqQKCeK^bq)T3A2CIh[..7d#dt=UGkCd@s50AgQ1gCYQ4"PKkc&Q_Lr)WgMs$27p87Q;k4]"^lnRLSI./X,(\_%RsiW +%s3kE3MFW[^ET3bjdPAoDPKcjMQY6p^8)UYdmL!h70Lu>K6ru8)Q>E09YMt4JG"+t*7">B)*DcaAKS+OC!BWXHAf-OAqTq6Oa:o=7 +%]So!MSu,b+_5g7ji-.)uj%'J%=^r6hABO[)QOt_#b\-'A]"ssZEJupkjT$ninj%f9<+d&!6%DaN\%.sH!FLjsak'-qQW_6L3&BW1 +%\-CtT&=9;Bp&k[gj>$c"_-KN1$^"_R-M@J-U,0C1o-3gJ*1Z/9MWtZO+M,q?9.V/R]7=\B2oRpp\\=W]#eH[+3,29;].Up;!H$%8#S>-K_&a.T71=X-0*#f;["3HL`F\6;h2L?i +%_@H`f-3M?+2NXY*#*Ks_g'`a<*Q2,mF3ksQ-dZXD9$eW3N5<7YN_E[8kOMbRZ]ZmNOLT0./A@'MLDW[Yo)oabE'>Ur/R\(E)-(fJ +%6NMfP1'autHD;Y:+N,;98dUL#4jKci*J,6o>FIN,=[Lm!/%#La`+V7C8#oO*ZJ4rK/EpX-]gQfQE>;0<4He"MB;DAYB +%J?'6?0*FHoFOj;_X5LAG!(!.Udr_M*_4TL<'"=eQiNE[f\3u+)$FAd]NM?aL>j5.QFM>KTUVQ5QR]j +%#g+!+HQ+]2!"NV6"NE%)>i.%#d8b.65SlKp,%XF.PdEedMB-diD?U(%H3un^I7&T3RBed*3+9dZI4kF#=VOi"SOR%VRc5t(-iadI +%0_WhEfL,AR]?r#iNOl$c/+.1E=7 +%Fgl":#TTd[P9:i[rPF(Im[T;pq#JuW-M4_PX$P(t$HQ6.3IaRD;BN(Lt,(r+Y-'W_C5?I[j5(%.M'+p0[8LnT_"GYJO'+F(lZbU>(LO\q70L`Z'G-VhV5&<>(8_%dO08)["A +%6'9h5W977a_]dAJ`9B"W4.u!e_T!DYY00,1M9d\?/JN`1&6t5JcVD"%Ko(q1%B>s24,>^/7WF1c[OjoZ%6ukmjd7Y,S:P?8l5HtP +%#hI`#I#a;T_1B-84HLkP,V1JH2cUDA/>eB*%<4A1$3UBc,L]CX_OT89P3=8?mfngJ0`Hu5Qc1j4N)<1Oc!&P%PQ@F*Khjtr(Pq5t +%e/OX+:jY_6:Y8U>!t`,V)htupp^6JL>7lJB*/[^I0HOFb[5_V8!luWn:Eu'\fW5f.[c7[1$"@Qba<*P,5u7X1Wj<-8e-$[e*da"T +%'A&CT1YW[[qljdbn<`s=!?&m#=hIX*F`VMq$o%N[%OAKaBV6$ZLB=bbd5M%h8G;nZ!E`e^Eqk5nbm*'5]AIsenf@T&sQG,8Au!TS]D7(T;6(@3?nSTX$=q;?=Xra"ZE^*XcI43Q0Xf\.B^S.eq-D!9\S7)$4e;mb:a+rIF@5qM$+oWC,TPE&j.!_35L@ +%_*Qq.ab4&1.Y1B;#!aXJL'^F&kUIc@=@WY+&"t't#F'"UV+6dW?g`U38-3Ng9f?"q]o=a41_q7/+5!CR:*QCP0RL5,g0dW"N#SL@ +%R8F!YmQSYtgR@I6_?_Jj$+MA"R_aiCLn$.$rW3C4d4%lrAlesV(WI:KhGXGP5L0O/aF=cW&3snW73/rD!P,0>3DLhT)q`^-AU^>ZA*du3V +%Y!5(5cPuHW(B4;oYN6G.pq&X\qj6JUYJhY5o>WKH6(@h3rd)d>&_0\$)_IOLX8hi5034r>8G!o!pUi$=hss;k?GB8$V@d4cF)_rd +%mnmKKds9kYbI$`kX$m/up9OLAjOXH1_=Bf*N)uL8X'DR:g$_AVB$^9V,X45JIf"7PV*8D"eno0Bd:'XuV1B!LA^^uVIk"?i']nWP>]Cms'9ZW1k#+eQUDHEB5YQ)N30&\#F-IJ2HF.B(;E +%*P1@fm2J8134*J_Uoo]7#6X0ML7B$[>889*'g&k-`l"h%\<"Zh9[4h_j5]S]rig"SBBqc$G\FHl-M_F)q7O\ +%q=FJ"99Da%YP50c*c!KM3`BE&-ib-LD:GKsG(CQ7D#n,BB>AjQS$?N#q^Ji7qY?Qd'k9Zo%e!$Iq=gQ7:.A:]pTP!`k1NI\5@/RB +%19NWTfofd?PB&'3lEc2[7K.1[*_ip2(OS6?[2:Zn!tE;n=WPWg3>D.ZLAWYGXdIl/h8Ck5cM:orU7&$(mgad7"oHhPq0k,e7JQ81 +%I9Qk4<&fjSSkBN"^2diFVj&7;HHk[5n<]=r]TX.ifl'(sX#BO4q,fFrLG:$H%18H\=XIY0l4kNW]]&6Bhn=cXm-U[/DA;\W"Sl%9 +%Z0[ATi%(rjB#3QJ_>dlB=H/&WnKFO,?ed"9kDZ7`5BLoZ0rS+i[q+G&=hVBM?fPbE>Q=MdlEOI7"mZu_(R8`3Kr0oce(:aj(&aA; +%PP/@u[2Xs//!!fHk-MV)k"Gn'7-QFAG&3QSQ^"(1%(Q#>0'?p-r*0A>pkO@\QUhK1>.pXnP/XD6pZeneYVU!KNG9?0Dr[TL': +%kfspL[[k%9B/mVu'_?FY7VjR(aXF'nQXhl1,AE0fnkeQ.70VN'CH"`+$l7-@_=NZJ.G=O8N\efWPNihLq< +%*G7:T);6Vc=tj^c_9\Nr]%Il9U<%ma859'^B;][<>TT+mF2?"5oj`XKhp&i[?r:!C`pt^eqMa0SiTrT0e+DE9LFKn0.F_klq587O +%D\&;Ip%1gAgXK>Qo$4*!UO_R8B`7Z'kHEW[i2>>?=#L\fi\[u9u>S[ab"A:,&j[@h!_BWIcA1tDs('^C9oW,n9+G_Idb6>";'h21P[mt_\)_4i$IuVc*t+=WNREB +%Ce3I;(bUu^0aWGQjl#u2NmOgZI*%c-7MD]Y?_+VK^*Vt7Q>(JO'kkBA=a;kZMqhQkVEMDMOmL'`:E'L*ZcauBqn\E6h9*cE@@$c< +%+.l9Q6(b51rhMt[F:1$4"$@$"J +%ZI&aZ:#,o2RDUGHZQ$pq(d)[7Up`C)bKi9GYUjh`>s<8hLXYd4VjfmkhQp_B"GMHPqDg77S?%E/l_SF3T*H"@]PVb$)5oat]6kbH +%UXu%=e)JTJoN?qj'5$srVhK,0i4r6ZH18*0G]78;LKMFdhX&93a6aP@LEo6eC<\l&chb_nI=C(om8JSAhOAX1+74+7gl["h=,]d\ +%28W@7gg%oD?:+34)22pIh=-+_]VMX7i*uG3AjWS5cfKpTFM*rR%RJZke)PI(AL2Dg1WdCNjabh1,4T[6&SN?i+ipR[IIP +%;RVFob%.mJSDC"l?er;9mkoLO\uj_rXIRtA4&rj/g.6Bh@!Z>Dj&0i+4Z";mQNiPD>:Q=>`uPn^M-KRp;O +%:bPIt9n6i62(F_Fa5`@r:NI5*MJ)HnYic;e8_8jP#5VP?jjf,SA9T@J$kj0PZO#S0Cgq,m[LS;la3_fGntVeL6f;KZB:Wi!i#qS= +%)fT;Yn7"()"?;&c;kR=McpC\5F_"aS_&Y+-('FSRkI$5*&)=W0`lbo"kZt-nF?"\$Z$QO+/-P_hK_=>.TR^\SZTNR"YXp!eq +%6$+ZI#Wq+;RfQd0^;O=Y+;[OD*`HKG'(b^FJ'^$+<6J0U7)7"43IIXJ/07\lF0;#]WT2MJuu31G^r#OH=TZ3&cB!RUgdj +%o^KX'6_8I?XG/\QQ9Rm5DrH3KiFj:)0&\e"<9,cT)"jZN85.=n.1T3hD>FC[&"m/s@Uf4(QqCj8occoNsA1ZEO%% +%:#b:NE!A,%!-OH$[Y+&#@4qG=RFu4\")t[U,V8N!8)-Ib9@1eQlS+l%2?QO(dg@)Z[a'+&iM8lE?i?!4''d*!BI+l;[-;O6!PX?b>EL25ZV!QSWH-:CE4a!_KLG?g?/,c +%NEron1uX4U78=iS%"UYDT]5BM$8k)&")]Mk:^'7G#5k1E?%BJKqiF0mP3b,>Q#86A;@-]$>mk&g!aos^hl[]qG(cmr&$nQX)4n7S +%8M(4dE6LXi==/*cJh'lLeBA(%2uk:9%r#IG1)VhSrbbGB3:'!(/lOmY+^?(YkCR4J$:7+i@U8+T#5"ST=LT*Nm*.VNRXm#7b +%p]Ai#=YPD\PakFB-;-*O!CI\K'*2Q%#g)*r:d<%ek;$"%#bQXu=_WKB+fKs+Li)KG;LXDsTf$CoJ;$Jl7a!$BbA?jRNZT\N2`Dm! +%/Vi!KktZj2lrHZ'LN!pV)?>C+5mc=VBmqj*W#dL,9M"D9&S]'R8dZ\++"GHbX4T??Po*98VAVZ*L[,q)oYCO$eQXC-HU%_$T$drh +%:n8K_NW^$:,I8TH<8T6Th;gh1e5]'sK-SJF+$U%Ci((,cL_B +%+s8#cQ2$CC#]R`$n+mA&i"QIn;G'2>MRsH3J5=OA*si3,%J0U'5eui[QsD0pGBU^(a!(7MIJl%2/,R`Gs,aF6+o`NJEE?99!\Z_' +%^:^YRm!g\`Yl""$IN'm9/+1TAS\adp'\3&/iS@t(r>gB72ARe[3q_;9hEu0U@"lJoJ+f/*@kjac!ZbCNWY^[A?ID`.,\-o*GkMRp +%ZsU#&`,37mX`5'Z9b>qO;pUYOqJX^#AIs4N%mf"f!J0le>'=X'8;27,f+Zkh5:S3S_0:c'.17E:*aT-+n23TUBW_/S(=2jsl1Nrr +%0.rpOje_5[[>P.kFQ-.NYIkkPRn9Q5VSi81o@()@JfK4M?X1ZMrM3VXmPTW@^@Q6,#O2K%;!dWl(B3]m'3Sj.\4T!rfZ+?4UK"hj +%N1SV0==e&b.Mi+`kf)G8rRJ`AY;^@M#c4Y,^0WP^@kX&r/Z!>?Hf_o+Z.R62C0+G6bHI36NhA>i/SP;NRPRbMESkW\m%*(PZ*`t# +%'jsS%ch;7G=?W62m?>t7KLV=M\r$\o9@K%*\)obKm)*>9V/+sjGrpUd(n9t>0H$YG7J.:"Ap?Dh" +%4co3M3-N0HA`)\L+.)Zb25#0*)WG_]=@IlaV^KJnR3,0KZq9;'?[k]Ij+cU6Z7E0N%X)47qgRM^p=2K5%q2uYHXOk3^_Sj$, +%[suq`?8-MB#2RpS[s0Kbc-$B=p:pS_kC?amR.^:((JfNL8aMn<':gN`#GV6)#I3_jZe*<./Vk<#MOH>'l:l41M?'NkX?I0S5kF6bT+*m]3B +%h6V)lD/jW,ZWN(HNFgBe4"%$nHgb22ZhN2fER`k@G#2#1M^(&!(Y=_=0WJ&kq2Bd[76O#)%@fgYoh=KeBr,NUgNR;'*9r'DFY]+#N0?eo>\?GHk?#+3P[O +%j7o&TnJT8SeN_j`0HYSqFmGqW+13a@9>#"fYl7%>^?!-'P?[0kWL3T&.ABfsAEJZMW"jCT3^R +%mb^"9Do;L%D3E'a/P"9Mh$8A@If&QHMUV]@/Uf[+n\WC84#bCLf-Y)!PD[ei@m$YXn"Ffg0:P*Y]B'^9%SJZmn1[%dIt6k"*060> +%Gg'[tMAt'sZ`o6cn\<>$s3fk@W7@k_)DG%0&$-*>9^j$)$0V(1kuBJh3M2am!Mc@PlGplWLUs]j+GoR`(m"3rpiH6R]KZ0[i-#b[G'a$BY\\3Kf#/ +%\u\(=]e;SulQ?_%6;[QF+?j@$N'V2-9 +%gEt&CT=h_R.o'X=K;Kk@cE*5nfqFiU_@q1Xl/6Lg-T6-r5g6])j:;e[Ch_*fJt^fWd:22?n:!Y.P:Si\a"Al"O]0K0I$U!. +%NE=K.n:b?P*57R$D/ke"CjI>eDi/>HY#^g_O8.;!\OVQ7=GLifF74QS<,*>2id/KdE.o1<]BP!o`Fk@BS9 +%<,0jK6#,fO4B/>E'Wi[>Pkru\Q*M&l[3Z(,&t;-UY(ucfRBB4H,U" +%I-RsHe%^,e"F]PK84=1m*4hoEZWL+7EqMc&1-J+p=H#\"lJ^B0.>/611chF@Z:-kc$u&RG"IfF<6BGm-*6(#6Jm*\CQ2kfa%7cE_ +%a"Z%!#SQgoWcSXs/dp#?nc6lFN*GD""oskqGROh=GgJ6lWphm;!eOSb7P]+*he!o@a#'#q..e*(Kh\X];J(\AU&rNB8-l"X:Ml3U +%Lt8&NK>POOifVhQ,I%fKY/[Ute/53OU\Tcf/ieI7+q8Wg/Q_EZ7!8]8/`G]pBgQ>#*7L)5#M(>n\As,.NohJA'hM6[cOl0jQeMVo +%'J!G"6%MP4H#?Jq8d@P9smm +%LQ!)S;CcQT#!kKDW0Tk&:t'Y7@%q$PF]$la=@Q'.!/r7<6%U9?3V5Lg(pL`fOrLbr.iB[J2.M?OGRb(f)1nD)3.QXMOID>n_XMpi +%HEB9_>U_B--Hm6%k$Y-o\/6t6'!db24<_0IJ2MVC#.PL`4A!NF1o69rS&O0/[Sf9^ +%M'jtfI5f7lKc42gh7+.;F-M@\MI8b<"TU*gk. +%bQ7Yf!JT3hWclA#dod3_f8u>=/ZD$>6\K +%BumETPF3TtR>0/WF&WXrgC^:L!G%8f:bp"$*Ha;nYAbRuMCtc!*0[V23j-GYJSDps-4O]g?3lW;S]r%g,D-E(/)*d/F^e0,OefcT +%9uoTB_I9La`jLrY#!qpH&6JoVL2e\Sp0c4k.g_jH6kWq/n$>3UXb>AZ61:8.H6HBo7-eNCa?4jDmJ)Y3Zo+O9FU`r@ZJK\*c*.AL +%*tZN9F_"Y!:T>;@<*YU/W)R"/:"#9kV9)'%nekhO'gRkL9XJ38q*"mrZ'Wk/^+JDq/=eDYWEC:+Z1t3YEn+C.c:DIm(I93Mf%$KAe=;HLkNc)M(Z%eU2OK'U8dR9 +%)_D&6Rb5"jJAERWC64-@]&nO2jn#TRC@+n+S(9-PG,GY,i2$X9_"6n%+2S/&2Ts*4( +%dL,!t'i%Po'fRkpO>Bd-Nc\+b3DpZZn0-M5*`b6878k4L2]dS!%t$>:=]cHSct+OcaGhDt/D=j^$__(r$tYd-*IJZ_4TP"5.PV5G +%RrHRm7FA!NgEo7._o(T#38Oe^D]NsZJuJ2EHjM)'4br"n&k.C3'^%-mU@707]uY8Xn`H[qfuBP6N=kjIf^^3Y[b= +%mU@$W95F$Z.e82UZEQa*pT2$OiTd@\lDX`:anR4dqE$CGb(/E*q0(ts=W#Rgt%2dH[&6i(Da23BYI6N+aAVK4@J@7i[bi?'VOpe?osi +%,(j[3E!gU;b])1o\]iGNe1ST<@B]gdR'TW93_a0N-_;S@lq/-83]qRo:(@B`BJTi3)oms!^nF:q2Fit"1d$O(a3fg0W\'t4 +%ABJS/%5OBJTtk^"3?6!nGVb6_>S^Ir\u!Mg&M)1[G7n@FdT#'5Xo8kK@VHH0LTdE9atn_OgNCF[7(UGn$f]O3V+`"I.YW+890Y)dXK+jCC4S04A\M3*hX")++iPGV8 +%C>sOHG(mY`N&[s]RS^^2O3eW:.7B!UfN`Sj[13R.D;)h/MKl.0)+W!W#*.,b$+-&+;74:AJ0Nd1qKOa&om;0bO'8+bS_SB6_6],[Z$%&f[J\Ml35 +%gWYR>=2*"VT`oZ(MG_sQ1_0:Kl%#!U&KSGt?1pG82J&m1kb&njCMf8o_SC\A*ChJ1!1kPQk,98XI:RN>CC,c(L26;7RO?B3;o>%. +%fa7'TY0p;=]f>ckTIX9K_\+!VNt,1_[G(8R-cju$52U9_%1t0/eeRqbO[1*/^/g!'#Bdm]0]b?OH-p` +%@G=HsY6iH9*7.2Np>H5`@>&]GTdf^>=ob90bak?T+CV2AdJ$!!WCO,NbfC=S/([5[6j"*e%rlhk`'d+,&V3RLU$('g;P74-ai@aJ +%T95O.Vn6?G>$f-rnO1e*=P\D11N5J8Tom[(E\p>*gQ'XG0F(fD +%$Ls?+Tp7\(KcDoWkRR=(K>loPo0b<(@&9!CF!JC/?VZ6IQKd$D&j;cq^]BoI/a?1!2)r(8aB>K3U'_?`$+oo"kXuCEJL5<93)+DG+-PS-&TdclP]io8U-kX`a6snn"phEX*i[I!5$^f!ZCA\gUG@@gU'3nODZP0frf%q +%3!>m^rlXPQ[3hG+2s],)C0'LU/_`06e#m2?p)TWECXt4\^T%gc)aK3:\n/V5XptCM,HNl$:pmBbmFsHJ:npV&VEo,"nW[(I"@2gp +%+?;tA,RBN?[ap;6^-(A)6%bR:4mfPKinDU)@`"N_c%0gT5UY<`7Noh$Ab+k-/nG6$11p@]E+qPPp"cLq:#qf6oYb%^^Ql'&tI+d;DV=Hi,fjN$4>l\]Ih$` +%*!-[N@`!RXfQ#UCa$Z)j(bFbu1Vd#Qn[8`!8FU,_@VeuMRk/Sn)87Rf0EATiTads3K/"FuQ>%d<,+Q*gE&M,Hkd!FkU2tVoOFJm4 +%!Ue1rGu+2Q!%5Sm:(rS$QcCk:i$\8c1l2#;IYJ,"S,49bMeeeEQXK<+-5/\<$3p@u==")GrbZ\qJhu,40e&\'4D"X6)I-+(;Wh`":[d#iqC,soM")HA,j-nq"h)Nfj[5\@s!SuGr114UE'oHWYNi#qK=(a*eT=Wq.6Y/N%7PftM\Off!C10==Q +%.I)(;UHM.&5naSH=!cV^:Z]QRa,qT]Ba@Fh:S^g(9l1rhHN=FEk?bCX(mZ$"[]RY;RYV'^JL&,U?$95aOdiO\-+tY9C!rBU,##G! +%I)V?qD(jD5!%BAB(!^/S?-0QU%q!]e\WeI-Nb/K&BABV*IQC%QFrZ![XoRQIF`A&a2pcLql3-^pRJ](@QE9H0:T#>nDA!Y>d,bt*MI8fR9nd$LMHBJ.;cM3&mY +%5YkIGG+98PaTX+!d@m+qYiP>J\L6[,A@aM#$b9X.#Q_Yn,qIB29S@_;R9kV]P5pot0uQu@/5`^KfGK9DBYnRSB>p,#d(r,kIY>Cn +%%\!Ju/Z8`+N$qB\o4lQO="7=Z97fQTU:Z;G#\q=+o,V@_/?/^*c-iEI0V"9L#+)d[!-%+R'h_77J5h@DeWO`=B;KPnd6bH;XcT\) +%c87:*J6+:lm7a"\&Oj)]'\ef@LX@K^QDRi0TA60j$^>;BF +%-MrP_`*og_S"^%K80q*/NSGJ%=!ZDY3ljSG(faYKWiOJf`CA+2Rj_8l:L8dr&1DNWl4==K5n.KhcsZSS01Mipj;!C.9+Q'[h5V@G +%Ii74C=oqZ]hTK;Vg8cq4a)L5BR.,E^n#FVRRMm0Ljm_m*Uqnn:jXq*TlM.q9aqk2-8Fb>$[apnq/$fpAVkF_!S'F(9fh!&8E)i'H +%B56aK,pQY^L-f73mg*kR7h!/V"VZIF9S.e'>Ctcti4u]/40Rn'Z=&AbT(3l+nd*)<0i?o"b>Hk>*,d@+(9C]8iX^9Kc=]GI[J9kLnYs=_#D-Ai3T'63V$6H^m=paoK_<_tX!?:iR!@'$N@5:PB06lO[L+%D/oR6h2m18Y.dL8N.o?n)M#"2u)'h5_.?&-5L]&V<7u9dH9lD&reT_,;Rq#RE2\%Qagh +%MJ(NBFG]<^^iW*Q$p>QiU*(p_pj=6LL"HB5hP$VNAgR[iW5OXmipYFYr"G#Cad#J`c,\p0:6'>U!e@Q#1!LP#6`3q?8ONpp$$V)= +%RQh4TZ['&GHVdPG%RKQt@(nb@2!@\^WQ7SN-#0,D8[SSj[keY!AH:I9#/S^132-U+0oV4^`F3#07,S-.N9gNE,Psr4!aQTr\Dga( +%]+KSKoRoW%,?ck^]3M^eRY!#Ac%)_XnQcVu:B2ak-?knb$ofjTp4e6_OH&+6a2an8Jh1m12iKA>P_T?7Cj*^ipj*_rJskEH)R1gV +%iR!+_+,()q\)EVj4,0RDWXep'acljm+d'q*$"a#F:jcI]$Z;nqD!]n?]h:B;TiF2\eAb19'LcNb!$"D8l;mtinsRfji,B78JhTa: +%e:RrN$?(Ql3hl'Eibf1J`#sFoJjVd7MBPe)^<\tf$U"Br*WK9>bO#'ZL]kDX>d50r.+BSenoRqM!HAf4*8&3G"Rf9!^]oRo9lh$! +%JOB86peK_U7.J.Tcs-k/LI0uU.`SNA6"c(BKb-[Jd&\4k:U:iAKa3l].km_MZ',Zj:T;fH&Bfr@'_/j\joXL,/e1D(TEuVOUY@M% +%'[I=SFcT'#/;'=i.+,7Q?dk]A2#dh +%5<@_T7$]/4>mR&l^1dl3(E?Z.^bp6ph8.g_&1L_0/>\j=HlZnM6Mp:b'U_?o*28!9m>BrC[cPaPVm+M^nh>YEk-\Vs,c+p'VfLu:X@eRfA[#U5d]1hC3XalKuC_^=B$(4NPaR%8&"LL'2+Q76JB0ZkBt;#qIdgD:&GMV'6E +%FBm`]\>@/Qb$tZIk%q]\EbWp`;9J$_AZIg+KM9`,M&$([?gpTZ)GQ.p?ULCl=MK6W*A`-/9T\nW(/UC'FK2M6mN3O2Grj +%N;5i%Qd3;X-:OZh+e+(3I9e8]I#P5Zfe"=C8iW[:kpX]I3*+.O4!@oVA,!&B/Bd$?4-BrPJ)c;Xt +%Lq@;?:qA#_M;\>!Ya26pm73'5RafOP>'-H1*K&-pC4_j'PPnCqIc$eJ`>Bq:'Bt$$Z`q4V[%F4R%uF*:Z"%JdG8B:FFG]I@4Cb&m +%c?3^IM-CYYCL#$os2G;O&H6Q]I"m1;)tc(PQVtKJVdT`lR!;%FOie$OI@;%'DbpL=p7ipam0IEXa]F>>O_'0<^0G,AM:;MF]pds# +%9;pN6/=l9Y3e\J>N$1GJ1\po-%*K/!/&2uFq*f7L!ME/8+.ipFb[Y+8XDg:)n5(D+8"[]_`$NV4L,b>U"&"mIi#%oZ,%5lQ!]<7" +%/b*Hd3u0)gVC):XNo("iTZMXlfJGSSV8P>AJM>IAKZSW4#.Om*2\)h7E?YQ:b'1s<_!uNnF2]FEXBC;&duhH`8&GlI.tAXtKG8eO +%8%c^t3a#=%_XI"!SDgdY*"0ibggL5^B[,8j1r?"f8"b,/IKaeaV_.+)Of;8,SMVC5Ob:)s+oggA,DJ0*`i=I2U.@gONe +%%#;)nXS7D9:L`%3#or)9ksu^IeG)MsS$?:l@9G9[;rbXe]?/)^_Q4:?6b;m(fiVsP73`&F=JaBf3l$?JV4'nKa:Fm$?09' +%Xj)6FK@;_nt(b)!@l7$J1Kp!,-hsB$"R^QRlND#1JjST0l4i(mZ&2 +%mKLU^6)T((&*JY%=F>d!(t#E3muLc.LXLc`EU,V%bK@)+3^`caTUar5$!3X%%SB@9koN+1Bo?h`FrS@kOeiD"S^=!Cj6j55$2;]Y +%-'WZ(Mo"nH\97;Qd&,E:8G8AC;SaA+S`G&OA3Ah,U8&U`PINrF@1?C.c".IKbM50V3aGA_U&tGJT%\CNgBtANNZ?ARn1_![+E,8h +%Bo4;sBWX^'gm!dkIDV_r&RQ^-Ci[`'`O?,lOi]+:Yr75YF7Pg+blu9m*KUdi$1E@T`TST=V@4&jeFI3=]>Ndf!kf1]\;Cn\a&u\W +%i(*mu)8T=0,],$nVNUfbS4-s,;,LXim-qs'e/1rf'W1ej!1(H-Q;c\`/3X,MOQ8;"#\\fDq1tPC9'H]B0PL/t#T=s>*rO,XYWkB_ +%W*:_u^GC^4/D/e`%hqUK8VTL=(]';XFCXYnp+h818]it0UAPb=!9&0)mYdm,!T,A%5tE73;:Ik"7$9B>Z=.&+P\+kN'@$W=o`S%B +%5g;N0J&$W$R7*:R'7cJR,_@2;0.b4&?nDZl+,S280F:;G)4$9s^7<1g/\NM>-\^363*@q,8d#BQHK3qWnZ\gh5ebBo'X0uQcX9\7 +%"ElcLZfDiDSk-(;UBsdEII^i+g_`VNE.E.qKbPZaZ^c\%659S'dR5Blr!gs26a!=4bZKP2r'6R%J=%2>8tAZf*'eBX^qGqj74IIo +%W=eXFd9AXcVm-sIH]7!>,d0Cg1k;3t@1>UoKLJS"?jqBC,#jP`_EJV>R0c=d)OHL,*QLt%_^WJ[,TS[emf>GUkX,tBI55sb7KGk( +%8Bsc^]VlC^&qGDFJUP/_)?eh9*"epqM3>]-+]VC]@80>h7i(-g)%#.s5"t,9XOa5[9'n71+'m8_PZI;F,c\,"up%E4cr@ +%80S"I<"A:)73mRXP[8?`h3X:L`X%rl&/r5>L2^-q:1<99A]9t&%aG_`fQ<>h3oNJ+8->:#,1;t9d`UJU$CW)'P[iTDC^H<>24AdD.T7A=F0OeLg:r1`i)B6,KONFJOpBjXKgIcB:KP2c30-JO1EqnNFZGUjJYCLmmur +%;D'#Q'O:2K4Vj(K/Jb.^Le+S'iHU"V'>G.9%$6m,:cG3fOd7sR8pj:)Hm9oMnW"3L<+uV23Y,4fBTc>Vl4LlWP#ClC"FVGa\[2kE +%:*:XR1h[Zfk3,b0Sba1C8p0-'Kie?O]F0/;6eW;rNRKmKtt6:_RlAdeu%g4U'+,3<0h;S5Ft$Hg8q]AY$[#aV9Z?FWG#H!` +%I0'JuA4D_[VLN@S7^7)Jk'<,UN@K-krC^'D!S8W;raJi%URK!m705>T&k_FjS9H(i->*HO*n$;a'88P?W0@.8rO,h)_Tt\"q>@%q +%,Ke1d=jb,YH*5@ +%4rTH^VMl68E`WgL=(^A\Q*/`7jREGN;9B7rV_LieWX_ep*f;4ou'Hu%2a$YUh+2p#9*%@l)PH`RmuP2 +%UuDO6hUXIMFd[HhAB`7:A&cd! +%nHt`7B3eT.ghZ6D^`*X$'4NdERWJoM_G=9*60f4q&V;r1@a^/@#uQG75d'ro9M,U)Qe`m\5]q+t\f4=J.J4R$])sCC>i=R7CC*R\ +%N[n7P,gZt5cVbCT`oP@;nOQbSk"9].a67XHdi0q,51=^nn?Y@#*AY:u-N8@_YJ24o:e5p&N]o<7,oQ=DoV0a#PVG[SfeZu#([6iGdY_LG"p9FG +%^KHofj=I3I7HBNd6tHD?!B +%#Gh_63<0Jl.)-FOr[D-;O[kY'*`s^5YWfujalONL-`,9fYGE?\,0<"b&Z"/Q0N]"L3S(F5I`42dOn2>#RmLR@Yo(b&$DG$$6S)-d +%rIbCK(<86uF59^c!^)G\Qh)iYbcZ[\8Fu_l;Ma=Fc/1..KCZN6R!&_*5_/ckEFnDGY)8WYUeh@0@.=oW:qVCl5Q3NT\jZK'X! +%A*(?]W-);(Q-4.\%Dqtr$Mg'iom5H>\2O3I2JC4tE7ioJ$*T;b/(_!:3u19`.fktIQ]FH.@]q[qYptfmU.&\$NLM]&&;:IXJ(/eQ +%D2Zb!D@-oo[X:'1D]4bYjT+]7#;1e$Op^A9C;$g98n6YYf6])m"fZ;ZdFRjG92u6V`@-QYU@SD&NuLHm@7Xt1B`)3fA_^7#d-00t +%^T/OSC^b[.nOd@R*e#i`N13_s.F+Ba*WJ`n:`LZV%D=?]DGBg.dAMjmi*S`+q#AG8P>"C>^K*^mY@j9W8B4U&^K=&&5Nl;GJW;JP +%@^Y6r.1P?Q+qQ^W*I+^5rTKUNiFRYmALHQ7lRf.Q?4=l +%JjYiYZV`_HKLt_<%Cn7meS@la4/[_iT*,!%U^d1k_c\!8\P$RQA`j+((27kP)5K+gd?4k)jJ\eTm.Sd_Tdh7@mU1__+M[dC"EnI@ +%D-!LU["c$7Z;S+hkr.$K?nEt2M"pGPb:tT,)H#h5BMQJ0FfR5bb$YlHP%&NJ/%k]BEJZ#W]%(+YYIIV\Wb+L$:9WS^=447:ST8R0 +%A]uGZ*&MW/(A91b.QF^,kZg;@pfO,'K( +%bpS!D.F]7XLp"is63UPW_L8H,44Wc+B1k5TBW"a&b%N+UkWiTgkIOY\TDQMj>,A_!'`Y91oiCoh1;X7%IVq.1[d]=iqVqkOSKU&6 +%RMA.p2M_8!s%2NG)BB?dM!_k:>Ffc72.:pEXu3gK1.";'1hkHcBS=?.@lhR%)lQ!TDe6l1>.Pm8:M7cDA$gDpdFp1Y[;i8'6Yu.] +%p#CZL.Zh.VOEo/;#qFeDU]K"9/eWt4'<@(,%E)lKFMmZk1P6/\Cb_lQ`,+G9gRN_+p8?:(ZnDAlNI/&Fr]M)rWfU)o8l+Y062.L( +%>8qd%0MYM25;;J;7\?+NN2?O@\PX%BX2/Ls`akJ*Ib=NiMSCCQ^?9G5s$Wq%VQ;Q?2rh6g2V +%:TH4&+lEm@Y//s3%n@j$U<5uA>]3>GPYJ`./.J("f[r'-gOBD'7712I +%jh$^RYP*nP'9D>_RB"l;S^`OjQK=S'W"!#h$6NP+bgis,b(4!WrBH];W;'/j-S[gLAu#/^RnW\dK;U=i*p172faKI.sK7;bl2hJCl?*Xbl=age"s+c)dq**g';[oq6eL/8kCtb&*Ltl$Jd.kuc +%0V%*jE`9@V,0/`$<2og^/tP%GAEhOYO\EjId8BX05+p11%P#uX];>!\:"/T1F]TTCJNr7XG!<8O+a.Kfn,N0n-&S$qW)".bj61Et5Dl%1JjYgA2U"b92"qsaNCqs3+Du*75o1cGEhLp0U2teGJ21SAO +%>''J:@>Ql!(osb:cF)#n?<\$7b)2u\epE%HVEc.04J\1^PAf$l?XtbKnmW*VEbR@u&`RbY.iX]#Hu8ib0PU1!lCg-`j2Tt$%f\.9 +%Enk@,2Kn0PP^7.1[0DA,+ofhI'?W7?c&?tfoPQe)Xq%E3_D7`u:5M!,Ep]PLb@Td):pZ27_*?9&VRUklM`X%V]o?t-3N[*qp4(#h +%rXF;BZC'5V&L$nP<8,^Oq%"[h9ur82!F8VAKp-&0jiW=(3[P8r\>h(U^o:c2%MAo"KS\mh:0&Jb@pYiKd2" +%ftf7Yoaa$lQ,`hns)p*d[kYSr.IZGFmFQ%HH\>WVj.QAT%TD?q[CG+)m$jQR`@ZBbmR`<'e[(mkG'hZ+6KBk*q!+pOE?jWi-\""+ +%N#4OMBXe*XbW'.SN^H8E/5i#$$?5h85/4edr2Yif0H#R4BCKY6f_f-sr]QWuot_?[#1Y$)]S!2j0'b-Hhr.t_Ie$bCXeu#'F.d54 +%D(ojIR/`GWruU=;j=nW(<6G39))^U-ro.P=J#TPld6_2iQTMprLG=Q,QQt]s63R8i:Hf^W[".jI8G`-J4E.$`loe[ +%rhCiuQ@^s@a?P!FA4Ikd7kH)L7jReH2pn!L;2FKmS*82NI_Xi0j8\>"'!<1OB,&\DCncc9 +%oL-f]6Gc1G*DQO.-]04J[=:YH(d^GBe))D>oX@];AJ5mYo;FT3$/V*\_<'Ml.GDG/t%gMX2EHP8V,)GOZ34r;1 +%@-'rig(Kh!^"3qX9d$LqhQ=NKE[:;D"4n'HNf6) +%L8d\eE,/([/7[fS=gg%?O!Jl**+^0gPf*Nq<(R&;TE[IAJ-9$)^d3SB77]-1hb&HL8&cN,"VtbNpOBqYc>+)g1"3/r>H2\,3%KGF]tB7UHBKC@=pf!)qLkjdONQ]?g)F.!Y"q"KtMFY?OTggN)5I"-#0$oV,%Dm;heuk$]9C>FETYs\NB&raokL&tdBLuI?*p+Mr^8:gLVO%V1p@[c^\dmK(5C=t\_ai,&8*sib=\bbCJT]f[d2.6KM/0g(_KDRaKLADT.)61*8`('akTT2-H1=Or!.$STO5-oEbG.&5G=>1F"a3>XfLag;; +%IHQ>\*3Sn+EkB6YT'O/i,>nmJI9tk[oP8DILo9aRAKL51Wq-]8B>a*^mP6 +%?Z$KWHr&AXlNA4CR-tFL`Vm_dppJmRc,Fo$d@I^F5=-V2>$3-3l&UEqo"6r]A"(J-\J`hea%^j7[*=A,%jN<9NsBRJV]I+es@D$4!.CG&uVSU-_JPfEGHlpMcNbE+8U)QXb8b]eo_fn +%=*c`<7kpSY-mn"E>N>.Dh8*/gqApq=TjN/Q55eae-&R]seuja\7MCe@h$d.%9X\"%[8KJ28imp2GmRjrPf:mj-f=K.Tl)Oc:uOrs +%^iNmNCMbn6F@sk_NK9B?#D3V%.ggb38OA0FWHr_bOm7>Q"TCN"I+6Y6*lNt7mWMb@'b\A+_k/,-2#6?qn2K@/_e3G*Kq8>r2k@+M +%gd5T+CA#sIot"\e/DJMfQE[CW/=s1I*&epa`#^4+a7qDg<0)ij4@6Ts8/U,j(2et/dta$ +%[F)JlBs5)mcn7?I5!V%ml64UL3#g8rJ4<:KSQTgR&Mf?8tRC!X/fYYQ)+OM2!\nUjE3f@&!b2H$>M"A$X%%< +%B#ZIQEgMYbknBAfL'mQSK4pOaX6$CbWeKZ%MdZ@]Y9s]h7I81SYh7K-:h4QJN(0)&1)-l?,\%/b&Rh\T5p]sW,Qe2>*['hXhgu5m +%"L+rN7J65GY`aeM.lh;'5;)nQFOWlUKg@Gp<"]g76.4AJI\[nq_35%&6nT&])>g/C8Qm=[(.9u5\P+!BVYYW22d.jKV3P&GU7msZ +%(B"hF.q`Ef>uJ`Y'j[rR].QQ@bK!s84oYrTjD*Ge,W`p&i);!*cpc//M4mp&)jrgYX%nVN_^qN#_\muDA4V^V]fh"aJgY#CZS3._ +%#a%oJ?iBi*#L30r+Id-=(=j8;$pi'V4rfVIL454FrDooL2Ef*!2pQ-)3d%o2*0OG*ss7p)5#+Ls_9kuB-gQ(oEA7i]n<;&*F +%qu6N[!rVf^&)UQSQ;p*S\kO!+ESBquLIY7$pIj(];R6Kl`B`F.]i>r7`LT +%Ut9J]=,9('OihW$DR?^B\,M\7dLQ)>m1@10J1T!EN&LK+8Gs?'i7ZCFLrY+hGV],bc/q6lg&+E>'\LW#N(/DU=T!BtT0K1M$MmnR +%[#"1iDPJD4@/RL/3be*'C"7u;U`H&7g=+5b[f^p0lm=.:ec$mo1JZjeOgR_:rPM(ko&S&Y#-[S^^b8SR7HR\`>Q"oVLe!38+40@&F^$_,*kZANj&%R>R8o6]0hPlbE%Q5&&`faY@>I$U9_d$d=11`kmLmTkL.OkP) +%/ZBY=D:uKdL)Z%b8Jf,$n/(ZXtY0k:\=0>ae-)=d9Lhc4F +%[jE1T2+!c1QY:*0Mb;Ns/N!&72N]NuIgqK/5=C,+:EZJah\4eOchaXO?W8DF7@qI>KFpL"78/Hb'p\Ti3t`1:TTuD_+.$$B3U-fk +%UTO4#'AZH4S4a&>ZQ-2+W\kNl,]gV]R8&J-lHt1$'g`X%.rBRM@pCSS7gfBIFTe8Jf%\C'W& +%&4M3:k!/&hFO7&@e/1c4*^$bRE0&ES&J[%Lc%4-ORalp7XIQ]tB_?&f$E\bgNm"gbg,ZM]PKKte2R5;19jRr#S[Nu]fp&@UTjM^q +%bN!$CgM9rY]_gnN54g/_q.Y_Po0iol7D5`^)7qF6Ujctj_5EDYPub(fRj'=G)`DFoT[jGKcB;+Hfjf8/rA^u5WW$-+ruq"aIG.O% +%BB]VrO57,?XIR$G7?["rS)[)%Gf96?N1j?j0Gl:h8p8ud80Y1X7(\/mK!Rb\V?kTmd"4*bR#8KGImu^mpL(Ch$4KGLR8&6h>mlXc +%<\W_E^hL/.0H+B"[hTXXA&nnGTZOtap;uU!4dZF$Lj`H#%#QlgUN(W/ZY\338?kA,+/uun>jbAe/(h%b^F$jA4%Kbcmc%`q +%P2[lQ*KIYQp5f_.07ZW&`#i/WrMV`6X%(?2=roOk=jp"b5JUmN\FA[c54)*l#&foLJ63M:BX\lA6jb`Y.&2nHXAY$t1H7glJY_>3:(WYX1`?Is_aqq/H4UTDU1P&`CL=r\G/WN\EAPp&c,;%B6e]fYW57X>)LFM@QcQ>:s!Tc=a20c.8]F);$P8BJ^3.PLPIjT[:^j^WL7llqb?)C,_VNA%!ok'iO`V*_iS>HdJ,Fp(8\%8:tS2@U3(^$_f*j +%#J72k$3ZhA-upH%'[;N8(FUVt(/q=H;s-D7RNu^kJg7!Vp58i[g7tK6US`jNQigZ,q!'U&Rq#X00Ak3\c@]r29tZ$=?f9$JnfId>72/q +%PUe8N3`gjO)+D^KnnBC+Sru$2^gUp@NhWqAUhguHM`@ZZC_4,eEPh(t'(8HDbe$2s:;%rRVI)brVIJ[b+iSK[9?C%8B\geBSXW2EGj.O'04]W-*G&Z;[cEgMQnGr`caoaAUt@U;a`F*U;:<"t*j#&-!W2=K9jl3W1279i^/Z,tZPI6(4NgEXFah^S9:&]i/*tF$b%u@8t/LT:YA5u^GW"I2^JJQHG +%28[m&F(qb;,,pYA>:<$?iTdr-56i9`I8M7*3(m^icWZe81,hToEboI4.sr#r4tqYiHpqd^[-OW6f$S>CN3K:a.,N&35iq5!A@7UoV.K*V@'q?1 +%+Snkn#`^%h!XV[I%E.*LUn)@FN<@83am,V.hR(ZL7i[d(4";gC.P7$+NOj(Qdcg`-Op&(-e'd8;LqhZ(UHNLCc]iK$"QOY_R]XCo +%H2._88K7'-==S$q$N/'=)^RAJeR\i*0IG_KRk'A/sQ<-mi>".Q(g2rRKb+i,i[m"S)-QG0V7__hR +%$JYDl!Z&])CELq:Yg#p3oE:]FXMDlU,>JM(ieW+0:'`i=OFSQN#WSP'@$ZjA?^dI7,MWDAEC.I'T[pS`[2:Xc-JFStb`(=k1)/L. +%C2+:4:dIdqXs#A)#M"jS/WSiqli,2nn&&rnstiKt8kNp0(oc;C%"KO`d_*-4H`0df(CDFTjIMi_duXU^J$L:*u'lc9]O2<(V[ +%'.2"[`)T6jX$A!XXt!Zb3UV]lj%cO5mZZ_DY5[,7/gEfZ,$4p`.,Oj5d8pLX9TBYCXY[)W@Rr&kq>>HEuDd*IUopq2sRmo3ceRJ2* +%20qj6*b5.=QY/8H?6%tE:k._$VD>dRAHqhQK\"iVmUo;`$>\\lJU:G-bFY?e]H<3fr5%N0ZuD@9^#(8M2UhKB@c]Wq,jm.l]rh7H +%OXDmjY?u,eHq_F1&+=c<8$fs3cYSXp:(C'`PPmm`pFb\#'Sha3gVWa]0ndR<:bD*Hp):%&/2A-NWU00)#"QA]c[,<`r$mo`*XFF` +%"5u/#?Ydpoq-<1[Kf+tjOahS.g+EPLiqhMY4ubX:ai'h/*aG;h_al0l]iXqkg/TBXc*p2l+]COlcLelBhYX4LSWd2?GknU+*_5eW +%O;M1B*St[5ek'9n<3?u7;fAeBrGo0,NGXTSLrMtIn&*'53'F78V;"0D$%^EeC7VZ^\^i$'SDK.,__5rpWjTAPFm&[hOkm';F_gG, +%p+_"&9m20JZ_Y+=J)p;m-K=)+NTN,2gmKFJd-`9qe">h/^H^6?530,B5*''rT3KYsrKc:(;(/cuo#2\mSYBH[!`.FV&*R7?!^>EA+'_5-a8ua'kHCVWe&U:k +%=ZdflVn7[Y9a6`GAA'cst[.850?Is=WHBGd%$Jh;6G1iFXKfqB6_qdJ!Vk]GUdnXi=N`N&1O4dbk6[&d5H$6+Kqh;N2X-XW7V_=BD +%a1>#c0=9K[LM4#-dckfsoJ5Y7fUZ>rNr#*a7$uZlgMpVO:8QWKa.CG>gSE;RRo#g55@J`(\-T1I%poAAe7gmu4%3%@iC^Gcp`&V- +%*qnn0NW8OM[Y['\2thYGm7bhmn!g9bFLn[A'K,a_mIEeA5IR>"Kp/3SO*3QIf[A$orEO^?P>8Fp_QfC=DN?/(qekWi:o!\\Y&kYF +%k.3&[=CGo$7QN[D:'3PF\ikpU&4mOA:ZY?ZSZW(XYLNm)D,rmQEMbUXkVjI3FZPA.VPp:N86lCAbI]fO]iU%aD:RKP3pe+p](*KE +%;p'=?f7tlMIr"cN,?0!`bZJ4$k=;U4mkq)(p;";*UO#Z#ZPD)?N?s6:C#"oUK`:;qA+e^?1&W.H+/b])^F$nDlZ_s(+19]0jf<:< +%@VZk/qq*U)IC;!m&C%u@0AC3l=1i"I[EI)i]jt#&;=^#rD^OO\HfI2eC\q_E.k.B5@5Xn]>!JtpU_RBe^Wg\FND71EH0RJ/o<6L9 +%e=Q6]Y[['mfD)pkmE]Kl<&4FKFXq(-=C:X0N+SYP@iBnu6 +%'s8h/\8tlq4ro*kf&OmGDI?Cb96TDiUA-WpXrXB0_J9'\CFq#1c.gPQo<3s@f932o`a3pThqBW+n;8Ma@*h#-lc:]8bCR'dj=%L0 +%auqm9jcCe6/r@fVqYKlOD2Us*p?]AGf&c+@iL:4\`T#MK(S5Z"E;GQ(/k@;'m%2fg=p0uEi0qj/EBVs:9!7iF\b8U(kPV+j8,q@L +%bJYKL@1]Pi,TPRNKM"QEZ'VG%#0"q\1pT]/#5fO`>)nJtfT!!s7$'T5G\hc:GIi-DJ*\n5<[-OH,OQSq+uko,Ic'p'>N5At4SA%F +%(\,7JIEZkZX2S7=2a#[L6H.F012Ch]O+'#3(\r:0iB=hn%IRmmVUh!ULNdjJp1V']M3LUF>Y*R(*WdtEpdFWcXRLd;t,;?N2AZ!?NG)_\8+8=S9cCnT0V2IV8) +%4Ql[*Y;r;Z)QeXS>'rZWe'$OJm=ART>0U#mmW#Ln\DEq(?8TC*p<2;9'kKSfLb@)$1JcM41p62j7k=$OIipe^6VWhUeEk#9/8kid +%7NS'.7I;r&g1be2ImD>Zp[<,p-!3$Wqo2'd]g(ED%"kU99;[>_H*kKDZle.XBC.C$@]C\p5qSZRbZ^NVmfrXKRS9&mDD]gbH,tZ$ +%H$-R&h:Pi[%1[&fOkhuHpOS,^E0/WVf86&+2>/r5T00\6,Kn2eU_s)l\8`'@L7oU1NEo,gY8fpKTCQA4h9J#dQ\Vgb6X_eJ=UYVY +%kiZCLn.Bb%YE'TlePHqHWlH@_&_Wrb&j$LY8*GN__mYqFUg#okCQmMT3/S$+[`8B=_LrFM5cWWlnp`F(2`\% +%QcEfu8N2uR\Q@Zf9//6&4Tb*OM5=bG0e[YGo!,XYI7^RpHXDpoqNg`$8W8KO[8UeT#fV^Zc8Kq+/fI5,]XE+(WOLTc-utY"D>2HF +%E&ks8g?dQ*T.T29.>?LP7Z"O;E;++QQo7UZVnnOm,ker0^PAYeg[HfNTk#-l`l/dP)Y2:c$?2cVb@*\i$A +%TiXCh,@NLGlI6O<-l9 +%81r6*lX\.>PTdRs#PH*3c"QM1'2tI:;du]UejKZU?V,#dT!"nZGC>nSX#l,Nlt')@k!%e$;?$4[4"FUgi(cLt6d:To_4_I$@tg:j +%s(*s)`W3*AcHg"V?K"gCcg[aH9l6+-l;Q].HnSEZhJ>-AY0P+SFahSgNFqkce"(An(q^36lioj#gp$"+6kGb`k]r>:((YfgW?_+% +%k$km9*sTW;_hFuLnL@8tf[Pa9mfLW=Ls+i:Lg)F'[0o^f@hocrcopg@FcQX`6uUAD?KO2`:O$/Y/fRk^GWk.m?eC'%Dr7?+K6l4p +%C6?hrej!$W2NhPC:,FcCF2I60ZX9uuGKA&A@-^-HV\1=hm6p"-=2C!8X/ +%5E5r<>cKCg%oVL<^-on@Lb9uQ"F#2"P[<;?:"`fj+UVI1>(#qO?Uq$&*\OIRn_/8e`Ksa$PfHi7IjckqAG6UP;Ehh.np<)-0O$:3 +%Z;uo-LY7,L]@1qBj'eN;hB>`HM%$DtnU8/3"$f6%T/C]c@^f*%Hf(@QPoD657]k?0[o(qL;AS$Ic+L:_!a86dB^#1*k6Dg\,F_uO +%*L6LgiFR&JH^S@jLN<1X258]`(:gjT_VT:*?!(ESj"[:rpSJoTFP33l=LR_8D=r:=AKs;T#3GS2j6d9'L;B43/.:Y=$0LF7#a=ks +%4N+I`I\W;o2i[V8bEKYbnb'A5HlB*Bh8eijL!/li,)80HSHD0%?Y*M%WGm7I(JZ;&:`8c.9UE1V':)3n[(7bE)'NimP/n'@#3_P* +%7GH2n9HekHdN8iq"j:I!rG[7mn4c.?OMJC!/<3;LgoaAi!#1.-f!klTO7:TOk?DDSDBJ5B_q'IX3a"7fl-iq5-JQ:3*)f'U=$)[)MA:TN_+br6$Nt)*L\YSB*B\E+&rU#cC#gaD/7IQV9 +%SAOmh)HWFAa0Jhe1&Om-Qo9nP7'?@M,?/`BK^e1a;>)"_J]9Ze/mSnOh,GpmMf[]3BP<>NQ4XMZ1)J-AeMA7nJN'V#rb`=QXQ;.Q +%Wj#a5r;;Pn1;q'iogH%K>ZcuQN_jdIC.k(@F,FNdIU=-q?qFh<[X'!"Ne[bY_H&5"4FDqQq0N^YXJ`>=d`!t0F4j%ncRY==`emlA +%H$&R]^m0/T-').tK6snbK5F>$Fr95g/6_TCSe9XoY`cXGiCKgcoPM6_\UVA1\c4SMQMY:n.WqfoCj0]PQ8lelkq.6d9AFoYNK+QK +%b&MEY8OWNcBAYhseR_;>U\4J?g&$P`RFgnYfB]?(MlG=35-aeW=bMsDIH-tg/16Z]iu^VroE28D/;eRETTYM:M3B>[tNa\eG+`?TSkY?W3L +%R>Vq`G!&?5:#oem%ciW)J"4XV$.M4HI/Bf!B30L$5[LfD!Y5Q_CH((acDMtm/A\= +%o[N(A5l/D'UWVP5GBsd:h\&/6`21T,"#"0[@ +%.bG^uWc=quZTlM"jM;_bQn^Re*i`[(49JuL)[erWZG&c&a^pM?2S21(Dn,Ts]Y)]Nl@eMK9A\JAo"e69e'l6>>(DpJ(+)4F]OdZN +%RA*[dXWYg8Ksj^g-2.IE#EPqG`]6oRL:]\l,aT82RgY9dZ%*HW,PrZFJf_?*AfRqgBrNl>R"60#fX>;6S@DnE6">O.7IlJm>bole"u)DXc].paYK4TJ/EgTHJR)t/kJH=jB&'A:[XEu1KJ&>5;qO4l6h'T_,[&tF?&N`5>d3uJ(;>l% +%@h)\Lb1<>pkOS,OaJE*U:B@:p##G4jRR7qfbmW@A)!0(qqnbTQ0"aJXl8-QE,Du_=rDQ?i0CjW9MWsW)S'Ku +%M`EaR[W!SY[<;WMk(6huaE*'$OtSPOSRJ\\r/r1mmXL]4_U=s/\X<\O]$HYE92Y*0FO2IFP=$-T?t$HGi)OV3*76CIM0ADA^:mh" +%;e]"eflY1C*#d.8.u*)kQa1)/X@J:MOn:@a@[QXVC%dWf2KHpMNGLX$h1_LN\s?is\6tIVYCcG?C]bq"p9eV;)n9K8"O1n1AF)Xr +%7r94]Jb1ZtR[]X87uo[72oP.2r`$1a-0q_GIe+e7.D`XZ5XlD +%*[$f)8YIIie&V'jcq5eVW"HCQYeTSe,25Nn]`@?P4p-G$"k4W5PK]6g$cqErF'2?K$_8`:9[%U>'2o_$>b58teao6R?7FV8Hh[Cb +%98'BCV!so<9G>XZYd"W/'3[,'J1QTnj,^gV6UETgqW@=,/KuP3M%>-Es6+%bs0&$[@aoOQP%\"o;bcoL1)f8 +%hZ+;3jmD'=ml=t9^!n:Qd*AfNOdOi +%5n,Mc_\K`\&SC-Z_H:`/R6 +%?=^'+W-)jR@h`JWqj=5IVuWh%*u=1pWsq"TMb3OCLe1o\^C:MdHf49h3BM5G"5g;[ +%&*I1K"jmNAlS6RO?oPhP7gVd=j9nB./-jLXC!>PTYs$tIbdW=F12hI#9Vl&bqTAe$$Xc;Es)sO?*>YN:j\MH]B7.gb["[Cd!<^si +%W8]([+?*s*%MPAWn0lSmCj@(5K-TXcdtTHGb&VrOKIR0F0-`Ci6$b=BK$Lu1]ZKVUKW6%*P81sPOa^2GO3e^oZ-:]i/3eVG'$GGq +%SRotIfZg%a!$bZEiHm\nKnRLaeaaNbKCL@Lc2VLH#=-!"u#S*AJYU&HV'VQnR=(S/-G$='$KF"_t/as +%-([aAbGsC5?`mL[)_8O4.UVrm&WqY%k3b"X8ofI[PQ8OBk,UoYaSh?af7h3lpX'hmGgafVi]ch9#BP`fptOHN%:X43S"08<0BaDM +%BkP+Ga:M.CX*'p_plh*P$gJCHY9-#4*I7U"hG!taCX^RWAKOOEo8NkEgR,3QN_iV2=k"flcT_*-m-Jfd$*RR\`KRM+[QD2o\cUpF +%cecDsb]dL,G-ZF2jgfC[[LhhIq"aa)QGOO5@oqX5p$f2OmDVlu]3D!,/)sGKc>W\1[I8E)%[cJf@&D9*JOJFUq,$`r2&"G%<3:ME +%)LUR0n5-O\R;*?D[If6SFlcl"+*jegpIr!f>ipL6g2nr?IAg?D9Js*MQMs^g%`jQSq2'm,Fb>>Us%p+@E5i\'\3\JHckg.4o";k% +%a$\Cgn9lmoIVBkk"-?9C";6e0s"-ofHa?l`Bb +%#0nPXGp.Dj#<7(Uf,<*-C^tNN,Au9HT'\4LHs%7J7WA(V/*87q`?IN200G_68:Z%m`ncY4387;R;`6b-_fZ@BE^=rY[F<8,Q0&dP +%c#J'S?^0]-B6,7=(PHF:V#_7"D2c)G%+"&9B<,D&q?oTMrRff2*JZa-_2iS!df&9r%O>i.&cF0N'5'Su@D'7_= +%bR`$S5A\-gRMB%=DDM_]Ha+;A5,1"(ME*Q-c#fk?XLGd6ZNb&Xhg)\]B5;/6Ee_68 +%Hd?.=DeH+!f`oUAoldbmlr81iCj8+4CThR3cF/(NI5u4Yj4GDCTj56KBBu>AX^9=[%W!-2`T$Q,k;[5-gY);R)j^#;[P:j]"ch:[ +%f230! +%*b$+8OYGf[LDY5\oN.;BJJdR/*aB72mP$HLS;;16h-VX@HoW]hLD]3&-$(fZ\D#g>3Q1\ZaEhaB3"O;DEQ#A$m-%=Zj*%]&b<_(s +%<#W`7ru>M'EqboT(jBtiho-2f$8)X%pQ$K;kJef.6B#,]U0&1?SC6%Fo1069>2s9(t[3'nMXV?".9ZSY1I'2"u-UZ/+oZj5D'g9bLs9O +%@bd[U1+-NNEi5D2od(g%+ZGYb%V>HlEG'1sc\iWQ7,7_@@XL0mAjhTa@n4cT7>r#F5`G$8C&JHLggtSUrW$D4040/41!]Z.rF1S& +%LUkps7#WpC6S0<5^'"rQ#@^s0@a:#X`YgVAFKtcAc$TP&l%j?1$R!V_N3b970-;odpYP4V&EAf4r`k8!$b=#?`&Pk`E'NMi_5>th +%F+`saieo&$j`jG$GJ`MP^=E(DIgRpUrIWupLiHANpeh^aMLV_QaMknF`43M"[g^3bmR=Q+6B%CH2dIb>*.-Z>T=F&GqZatuoB\+< +%1!W,:=3V?;o:a&:Cq.[[F6IS>*:1jETu.UqZ-2`[k]#ju/.3K$_'Ass3daST&?+CM-h!Cm+jeBX-Cq'oqGp.:>dAQUMk\tm]fJ:h4g7-$Q +%6AO=.@(7J(\?Zp>=G8&r_bGOq91=UdfPnkCh%%fjHkG1mU;PLnh*6Z)B37_iJ.B'-=\*>;&3=(4L@b3:k!b'ONT$GWoJEtd5TK_j/^:o)'Ig>bOTgVR0TM\:P06H%$5DY+.NZ1\)4CE.oKXYEggV +%*Nk2.h)ciS7>EC(8:7X+K+:u:e)sS5-9>DJL>,*a/;+Kll7bGR%X5K;o:a((p18O5E!71u\9hL*3aC>X#0LOlk]#Vpb4toW5_gj_ +%a[C,$#p$2"@=A\,^=7NHU%VXMflAOlYK9F9=5P5Y![RUodn:c;HiM69!7^.b>VhS=;fW$%21NlHjOgnR.T:#0?cIm-VG["=^4pjC +%ja4i+<+bU6of&E-(#t4Wk`d&Q3NZ>@O/(C3fNWh`5_F+R`inWg6sJuBGF^_\F;Ngl2h9NCYgZYZ[o5IImHkh>:lQ'f9?2!LAW7,dh"L^.t>l\"Ss3-sH+9Xp]G +%rRJZHjh>DYGf7UBOBhaJV8R_Q:aFZPIS7IO0BnJG'--JSN48Ird'f$XCk.B44SX`#kR`cuBH*'CN-ELnq;d$XXrS.n(l)-E\nph\X%rlVK/]FIulTCZi7M_&Kp`_?[h;na)-Z:o"kOV[cAlEFK'@T,3A +%d63i:7,,OcgLYqDBWUlIc3>22O\'qTZd57a@.M:[Qolu2Pm><2k';67,HJiOE(S^3btNGI40O7\j5#a&*ganO\%WPm.``FAXY7S" +%_2Dk1O>,OLEPs!`Qd*<)=[5!6EhgOEVZX'\VJ395:jC:MNC%+rGlC>QJ0u;=Z'i5dikQ7L+V>a-R"Gh*,t98u#fGG;(Nu`pH`S+J +%qoB`6gPZn'Wm&JnV1g=+e@OB2@/Zh,*A67Aq8G@-CtgA(=YoBE0NXj:Oo%e?)Z6EYI^R$43CTI2UY9oaV +%n3]^"C^_bY9#ogru#p`eiK#)_Y4ZVgM>HnWmG$l[a?HN&`HZHO'9UZ6aD"anC`+*os?p +%liVjq)=;BirSH>^i\OTsF)g8hH/NlsR]p#Pfrn2],r-Qa +%I7NjgEjo^+[[eZ1YomkLU%mjn2MuZ#pfgRZ";78]NqV)!,7L)N6U/R/Pj:G"hdCh3].'9=t2%^CaN:XBMRk2#0 +%Ha@da%)?.[H`^BU:?C*hF)fZU.5@/Y`g^n-r'KQMSMk9-5NSZh7l&i5=# +%fiOeV%*61(1lBXhq(Q*fRK5I\PR+e4Zbg#AcE0678;G;G;RL,1nQmW)a5SB)hX$3)Fon8"2gffjbsZ&GPE4apiN0IbC*f%4#>aZH +%X7##Ihjl3&n#S^c`_u,f]=#<7CJ[%GBRPg@Z-(bo>PtOIeiEYS^\Bd*2^TKu(\M22/=FX[eiF`e5`Y"$>R89o]Ut&U61-SaMdL=0n2?_L[>MuNC2Q>S"d_`GEe2%J/J9]2 +%]=k"eWu&XC\B7PKLk4bB)R((3/CkMmk.AECmJc.*aIUpHLAuBM0(E:.9DO)2Vot)HUtV>HI$)7 +%?\D^TK/_i#V6?XA*T';#e!4C!RI\+-rtUiWgW'!InY1@^^K$0ijn#N: +%(8^bGc?LmHc5#jj&pr*`gdg`%!U\Fu21tV^:=I?!^3$4?=BVK3GU^qngE3'^OQrRuhEJ]dGP_HLnhf@B$nQ`!XjV;o)Qpg#l/"E\)ps"3&Q/UnoBHfmc&>2)3q/[\sVXmpWtdiY/Ud&cZLiOR:Y3R.gA]o.uViU:;,NK%*'C,9jfH5R3FB:u3+`u[t\Vh_7pgh5S/d$YsC*^i-dm+H4Xjq9>]^KljTebl1uLjaV'h[Ve7;NIW( +%B+"Zd5MV7/a)EI)no+J4s5@,"jiR3#)ZaX=#50g@rVB97Z<*Ie=>hqjH7JcGmm=`/Ge-;lG`NuAC/1InLOB!\/tVGNp;50#^(#,G +%5+W\!eG3/?$0^:]%il6`humqBcYjIcp\&a7pu[&eND2pHA[GMDgLr!QhpM(5<(F:+O(>7V#;sjq=Y1tKANjR2uc_Y8,O\EVo-MQN`C.tu":DEp#"$P@NM*FQpM1.!gaYOh'#6j_1La@23.gb%F/hBe'T +%kbEr)l/A^G&H/)ujUg&#^(/'6SPSfPTbANBZ0'V:'0:P()CkbT1gr@!krt-&W6mPq1n5n>.43)8=ZP5ag.gcT0C@TmYV75UN5o' +%p*#'QWG2Q_He,Kj8mqT[GJ6#W;1?nPRq/_*/oS%T_<_p*94H7n%N"D3pRmqF#%InCqkIET3\mNWE;Ir)2=J!Bo'NL")mJ7i@R1j7 +%kI56a\(DIC%-2VI]A?M"Y]5:b(A6cnPCj-H4*Ms,eY#`@4I[,D[Vo*;`a5X>&Qlb+na$aJAi]ti#j%mYL32b**^c8gWSHKh7BIcbHF&'f*qg\]QdZj6 +%qrq/(1E[IcnRU9)^7WY.PW/^*2nEGphgM#n"t>T&NKeW87Z_*WI=&I[h99d`UQJjS\)!7cS]U'qI5jI5cYDQ77*3R7hE`m,Ibi5] +%S?/![MA`YTIG.g-Z369q2q:O*atg?6^o-4,3@[KcN-B\j/66I2?kZX2Jee*`"`_"1jYLXj's0[eEoh0%9uYa-:/$ +%G,gtRd-)GTNVjQ]ottpZkMK:0.0etr6qp9$f(\C8`&VP@;Vo[0;H`2EJ!HLUT4W-^J\8penC +%4"N'@Qf%d3p2[V#"(kTV[pN4O8o*$K8F&WJrqR$:"+:u6-_ET00Z+H=Cj(MdH5Xiem2Z4Eq*&OE.3\uK=[QGAirnc<[hgJK&&-81 +%DmWY\I!mB)rf[XR='[AMcr&GEKH*DU_c9AX35Nt5s)+lq(C!YP>Cl9/;@oI2iTN-)J=",fZ&n_#Fli8b.A>JgTco,O2NCb3eW4Mh +%Q!Ynt;Z6cdKe55uid*J'Fj^'06oqZ/Q38=;5[p*FfmHsn%CASSXfmjU;B$B9)0pS?G'S8?+7mgtr,umL-2\:VGOLDQmn:,dYFNlF +%>A$7kj^p[Oe*MFkptT-Ci8'1G"N1;g;ksJ%\s'g:j#Pr,nTV=!n's/S(@/"D/,eRIC26%_>KXX/AN04_pXs'HD>MXA9GK]Jq84[k +%.51ROLHNR;cU]->;mX<[BTQ]+`3Xeu\4smW +%g1+cs5hLmQZX;tQ!&55"3H'Or$q5Y>HolKnM>m9^eE%!`2\2"UfhNOn7q\m]:cgVXM>@.eZ1p*I`PqSr^gT3$fIc;:E`Z3%;Go&4 +%j_3X:86t;"SrjMl]-HX[]6MWCcZ,VDmAK5ub/LcT0`,Vhs%^&[3C0R9'o%Z.d9L#1md.UeRh_"XY)m)n)8D!V$6@`,nSP_g6ot?P +%Wpn[5FDt=7hK(HKdcJt>)YQ^Tf0BD7Yn1os[R1q5Q)hn%f#EF)FYN0m/6GR@Q@#tJ$;0@J[X)1G]5cAQh(Qnm&@(,p#B;LbH8C^T +%Lc7c@T2mIumhD7!H0ga\)FY[\ls.4>[Q\">J^)&_Cko=0r[:%AWabk< +%He1FR:"8l0ZZ?;A/#c%o?g.914".Yq9\'>B@ob74gWjoNWP0$)SLa,RF`m`BaE".:eh[Ks6CM\gY^9O"buI!WenT;^B;X_U%ShY3 +%>%sT9Y[U-Cl.=Kjns7cXM?BZk"bX'MYf1)9*UkP/ +%bUrQ>SRSaASHI3gK8O-fK6fPe(fGf\0ccG#K=X2S>7F11.YDaq,\2,?6UEW,*E8u)NEqt_C9h%0KG9`8]Y*W:(13\h6_&l\FV3oP +%`Fd`\]A,pC(idH:3D))Z6B9HOfYcq;204%DH8K`Dc=M9P/F5=6d3jJgKUs=Zo3tfj7dn@"8YquebB +%c*_BK:<_*SSI?u;3l"B`(A49Hkqh=blt,QicahN'e!-M0<3Z+*=TLBrZE.Scn"u#S[@?U5+WX;;X_]g9\5drO2_NErhGG->8[?>] +%0@in9ZaJp_H5\"A5W^5J(Yq]N&#shp1!bqZjf-G`BM`a[$1Tb,6/bYgq:H9CqtplE#s3H7BHLp3+nak?[gr_L@F?SfO@UX5^Z')1 +%%uIY*RRF]d"*n:"cC]7B>edn+GFLJ$qb"??G=\h59QpGN1]>PO?P_tDJMK9L;U8q5_e2U)GkXphW]liCc)AU<#pmnd<%V%'W^njc +%U3\PX;t%AH)YSkV2U#cKF0^9P(TYqA9UeIKZajSR":n:#UY%r.C::g+Y^/#eY%00/")EBk%fquB@<,TpqF[M8%ndiAG5TTu2?Us* +%_5pd\0&Y/']#JpkNG"WX4M%FnnbrA!b@^)cf\O,1O&K];)s9baDT!iV?R_(n^KdrTb86$I7GHE&"f6"F%A[:FF^3V5RMft[m9G9k +%g:i!K6ba)FiHh]m%O;)d;#J;G/J`9Of9[\?q`q!1T0@^dY2F4YD4]i=aNBM-NI4`r[eAu1mh2t%GM!A,'epUZn]p*q$Q +%'N_UWhT?;A[\?e8Gi;-F=M,X]YGZE=dP^6tTSa!eYC'9e$?&,D&+pDkTNdRZ?%A19)h&2t11$<=[IW!lY7H!T"iWfZHW_I^p"V]bW0iJn_`r9-g`SV%p"CdYP +%ScA="RH)"=aToMn;9XNuh[>EFAk&9%kl2)-k!&47*&AkUZ37EMZHp\>"tDr=D2gO +%0D0I,\JpX6:qrh7>sI$ZkrPiKHC2;KbnfE$QDPOHE(rsFm"0&h%c7(KhGHVW>r!5%8 +%4)m,:QkMj\ +%5re!Q#,LiP&JPX_W/18be!;jG@*[(C-r,kg/e.#E=7'ilEEK!.B0'_pKDn"pl%=.Nb^"QEY.piVqB0TPkikm:[We9^M6ROg+ +%_h9Df7BK28^bLu$B:jFmd4H4S@Ud9o8X3?2(rJD?o6rj8-e;6jOjf[>nl-5r)2 +%3/np/meN^DSgQb;8$D+n<_e1_>XGgi/r-#aU=/jB57.hOR8Cu=24P,idW4^>NdcZ37T/=i#^ULSO+tj"u1%o>-cN& +%R,K*a)sC_lQ:&(1*FY]8W*dndKJM(dr/p>=$"'Vc0+@UL7NQ$kLlI?4U=B%-8EfY5+usuj45cSP*C^Aq]$]hR#<-:.VA7@V1"80C +%#2Z@(j:I+tX,L/JB:(dX^'[F9fjgaQhg$3*&6JDEmmd#oaTFr)Pm`S=+)uc&bt2t.Nn3W>)kN,EVVRSV^"K>KVR]p/+["H1rjTM* +%8a^t#p%c>_UgLB^1Z9=U=S+RY5Q&g@H0'D!,SKak!Fi%_,'1-.l1?bR]Xi#+0sS=pil7&4Yp:J$_aO'L%^c6](,fYKd=3/rJ_Sti +%:d7%eL>'AbD(,NtA$u+"HP[P[O(>bos#]!,m+rKrd?;-*T6Xq6^LBuW^6SR$?;:%EMr9mH4?Qu+l,pAl"T@Lq^9_t4b-gu%j6YBA +%&gFX<,-f0j1IAEV+:5?c4[Vot=$7,d)o?h%8,-Z1c3%!>^'bemLm3PW.]V;?%7(IrU]VZ>i:&>UEZ_G"ID[RdKTEniANY)o +%`!Z$F)Is"QaFR<]'%#PpPmmqlYS'B6:pV;@9hUCBY;HrYVf+hM5o``2]Fmj;hYJ9POk^*6Ej:YNF%.JY0`RG +%Xl7[;1oNP1iEI&*8,\(BrJ-`ad)j[9FR((:%>MRbm5n5rJIpt.67%.U@IXmIqpUaRa@dMp`P=%^Y!/b?*H[FuH-Q&WSuJ#40k@$b +%!MVk28ODL7n"'':e1T&*ZdV&u4q)eq-3ot[MQK8$e1Q3'J`cpKA,*PrabBJhq_\<^;5FSR@k>U(q!W7DGAD,I:$<&84!2B82K9%3 +%_/pC%I7-cD'-qLL8RoD%@X5WpW0\0/ZsiFcmPu3EFTGr>&tub\4:IeC54`I@NeFVq]U4+pm;X2#7kDgrIT0^R1P9csJC@CS4bL\$IUGRA;nP&ghr[PB)^M_^f*3YZ(Nh1[p+FK0\4MjrCZ:ho) +%+Kl[29RAXuMN[ScoEk]^%noqjB0)Wsh]behTWd@n87tI!>@2`5XDXMA9VdK*8Rr_LSYi!!BSS4HUu[Z"6RC&chlnS6g_>JDlc)Vf +%K"7fug[uS4f#$a@Gk-0JD[2jser9u+\RGo.MYk=OY/fqIe9uWP>Ib;`Gug-ZDsbP;kpeNe4qM^;nB$KLRuk/R29D24K/F8H+lp*1 +%LoZPgLUZ[9$lc_7lam[i"P$n(>n@+tl6s>8&>BL5GX&VpbF_Jr2Tbcjd6aH];"lX$4G8^h6H\Lt*`J=h;@"0m$8KqTUiu/>n]'6R +%p8WLb7D)biiZO/>lde++$?mFUj1%npY:%)f5eEtUg3@kIp%?L<=I:Tg[aYZ%?)Dpsd)SIPQ4%\J>n7/&_`E[u<^MC[E\&2QU/>7% +%??(W9!4K9CgFj@)fg'T0NV*]_j?HM'KQ%j&1%5`@W!]sHJrc=hok#f38ld%fb5@Z +%MC_RI&b]Pt*XdtcAdOaX(;lQbojTm:mN"Q;oQmst.W"79(Z%)bp3JM&(fU>D!5F>NL"a$%3UqOhi!`qBMhKffT8,tC2fA/S+=[9[ +%Pl#\TFNB;o>f+(n>0mE__O88T&r)6bL@S&FbWd-rKPdEN$+8)<0-K^3!5gCRK8!;-Q\Rpg=BIFGF$Wc)J5G6]S[(pgK>Bb"UPcUd +%pUgSPpc')8jR6H`3[e1:fi(ko+2j9_;;)C$q9h5^%ZCqtA8[ +%]=HK8BcMmg$]SY5mf64jr7tUR7L&@4rW1?m'*!gTr!?0:G7$?c]nKQ#d;2BCc9TL-TS;e%5[Gjag]cQ@_.q3$.CAuZZ">Y=qGQls +%^P)J-B')"2*T^W%;;F^,0eR\DZdp(%-PFE0j-L39@[QZhS?N@#k-s5-) +%2YIF95]ZSUS">tmA*(A=9UkjAcYT-:'LW[M$Q*]1%fdiDW#h4Y_+V1rADP?;o$?b\,0shV$o0GjfSbkeIO)KJ@e:bu>c0je\X*-p +%Hi9LQo^"Q-h$M#^4DWa3puLF(^?FCf`j/;o!8!62$GlA9GX`rcB%)aJl(WT6D%u%+M/Rh:^'Z`j[l1(cY`C.FV#COf#fEX:7tp!p +%987dm4A:fh`C8G +%YIDhMl\@.a(uA4/:OknGYI4'hWf8!CS30C\,tjNC=lV'd)OAg->>dJ@\-.sO7Edq^m5K59S@L^E".>WD7GK@A]j$!!SK=Y(&uW#@ +%dRi[+d<_aU/t;tuV>cA'\8e,F$^A_H\p5="hqB$",^Tui1WR;mP3<0YkCc;e%(a4TnHOf'FMC*i=_5t4RkpB@bScTA@jFM!0HDf= +%N[5-VPXs5\NR\&Pr*"(@Zp7FafFQH@YWWc9(d'Ph5qB]Q68Wk@ZqT@r-g][&3\tH;j`Ue+#fGcr%fRi9,&#$ULCjA8#_*NGDk`J> +%OA28=UmWA"?;ed$^%K*`+OinJRUs1uC)cL8p43knF`gt2anFWG;fj[PDK>E#1u/k,9)tN`e.DR11=Wi;0IBZ#4_mVEXQ[qYdGGJ0 +%Zf/M\JeJne9]7=6UE=#!_T1;Q1!uUciTN@"5\DtA0gOWf%YD3=Y*KorJV&re82dXC.Ki\b25'?`Paekq*%f:jk +%`PE#'n3F)2fkM8*Y=ge:oO6>\!D1f4)uEFo+bWVbM#77WeU?cl;;!VIVls_FS)&5:O=P60r=&QqU.mSl]X[9>m9rjs/i9NcW(ImS +%kK1D3Ih%&4HPm!>1I2Qlb/Qrei(O[bLO.oK^u.lt"GcMUP$r;V#_I\dD\NW*"@7"rPYj+o'*Q/1Hn6->B7_6cGfhEOS-af*E$&mO +%%*euAE3Lsi?uRFuJj[-W,@GI;#_GG=@j>B#-4#2*WuM:qo5SeI1kWQ40E?_]_'c.XPFar4jRGNT9J)P9K/5e)*(HPnL;B9##S-[8 +%&MQ2>5]H;Qp-rDF^"i%-gJipeXM.Jg%UjMqhr",BT4WRaG-1iu$:fmk-f#!j;bbQ*5hlnY(9"gJ@iqa#u*\*@O=G +%H#o^'\gS,J=K>I[lB4m-J]?g)NJ5BAcSOC$AJZa%=-gFkZcT."N#^3^\3'!JW&[YF20/,M\-W]:m[_$#iF:MJ$1_WQ/q8-'IU\BU +%c8[3tr'3gJ24&61S2i;kD6Mdaj5R[>g<68)Mm,9$JrV9bh/&??G"OQEgG>8CfrIpJ&BkT;gKFn6E_#T69OEm+^[h1nnbOA0-aETF +%l*a06o;je2[g'_,GnTB8'IhD4_(19[R)40!k1<2uiVKFj3s8hKpR.tD%+\'!"<#`:29e`ITE;U[D!-3/Q?JnSIGopLL6peAl@QsH +%,EU)e`HpeD4[^E>WE?M)UN.`gMk)f9q8RTddlkJGmS/I&@OP>#dH[?S[[oe514N5o^"2'I1ZgI-2gt_"Y>a1]#VM&.T3KLIHb$i0 +%B=\H0h9(dfk,EFG06a0Elnm86V3qN*?_r#GIRBE6[r]6)i^7moZiFI%^K`#NhdLI8BP=hSBJb`%ZNjho2g"JAWuL,K+K[2*9`3[0 +%SpLmH,ic&qrc^6]C[G@"s*cNUeXi6&et]Wd/`cU5S!t>qV07&_\'jWMk20`3 +%F2r3VgKV)O*Y)s=++>L[eY)Y!opRR#/h+Zug0#Y8R9Uj^!6`V,7[4Ft>3sZL@&D01b!UXKmkG53,O+ZI_cKHM)QVr&ON9 +%NGk@McMHarJ&a15F(.lk=SPqc]qpRV(F_TImQW?;SR:V-ZT[%%[^31l:rQ8S^qhdhic6c%mZoM,F4JZoSrH),[T?B\YQ%ol.:(eI +%bi_0^hX+\hl_a!)=uDc)![\1M_1J3_.dq*iDIIc@>qN3;j!Dh[njWF4Z[R?]]3)$#Im/f-66YJ!+hm=+IoUs+N=,+@;gfsc%4mupNTC2HjV#P`gkga*@q955X +%Yl36SjVS$Crl#$Z$,=^O%sOHLAe3jEm4`bR[?JnE)n!54]j/1Z=[%6II9b(E(Ar=TKPD%HlhBk^c\K_gbN_kdCF +%Y?sD`WGi`eB2m&1F*i3,leZ-9lM$i4jig>e,MQ%!9Jb(0oDX\Gm)l7cM +%[mpa)bZ8`BGgGOt?Yl!)-#tV2^H&KV9Tr?WF,6T9@/p"5"no=(=2P>)_=[e4elIONpG%p?Clb14M5mA>E +%)CqkH8\Mu3R;Y:M51cqfgb>7eVU"j5,S420.&VEUPG?h4/,VKmr5%D>8(e;k\7+lVl5q+gH]5:ZfdUlClqVfum0^W*&,q(TM,B9rtn09)H>.l8Nm@:2Qn)#t]SuSJfHa;!W>*fUqMDbqE?k"/[8M#S`.pMHc#O=L:>]oRc?gYN +%/]34MhbA]0+:P>.^03UQIM\I/C1o!,m!Uk=[5L32FR+\<(L,_U?$DEAX3KYd[t=nm?mjX(K.e8EQB%[:3OBkQndchTci(")LX`>Sab>YV&=N]3h!4M5P&\dY-A>dK3E["jiX`8?:A%(CD/ +%YMYSN2q^!no3d/irphrOru&\"#+[X(@SoTIoB%M!ODQZFA+^"bWRC[pbTtRt^]; +%Q0Xugo@']io#E,CdUhR@hQ+@=BQjXf1tkLEkGM/DX_-grPSa\4\J'l8MEdg +%r8("Ob5-R`f2n!8$X%d_HsN3tqUE?NAq;6*oAVL=^9aBPO>`I)l.;U"@q($sjaLe,4igM@-$!g\8FeGJ"_C?FLkJdB)V"*GOBs0j%/WmGa2Wpoi!fW#-$!g\a@$lL@?ej< +%0d9s+Bf6D0m!4s_jn9u;OVGd+7>W!',Efj^SjeJU)^CM$ +%fOn&*a2Wr%c/i;/,%$3>)1OF`2P8CeTGQOfNVON0Yl+m;T-Z@e@4i425>,`T92/3nr@FrDN12@Fg4#@;Hq$.Tg%MbJjth=I38+#3 +%UujJ^r\2IfZ_Z`iYeBHhrXCc'Gb8[H=]4i/!=hi4r@FrDN4e7_gWu%OcV2OR,hpY.Ra6:&4oaV^YSg9<8[b8)V"*ieq$jdZ?N0!B +%@&"r[PANNWC-KPH9Xt$PWVHr8RrJ7-;Y-<%@l;C%Z_Z_>I[`%=p9URW1\*5`D*L[.4u<)%PAEHVC-JD:(6`T"956ZNQF)LWT-Z@e +%@J)#'Ib&9u>JfSeJeU/imFZ[An:bZU33CAMB_f7#8/ +%C6+@dradNAlp'%V==*)m@Fo`(+;RVk.TB![a:O%9T*rl4m5Bb&d1G]M(GkQ2rpYaM];)SOtpY8.5R3HKFa,c!^+S[0U2n:IAqL?"PD'bdfSX!201NrG\]RmXfu!=6/XKBo>%)q]aTf(:P?5d +%O'6+25sb]UY&Bo1m;O=ilq&(pF(!K8UC3B'O64"k-a6aiHn:=!ON\hskX.lSXpg[EH/bKY;A$`r>cbZ5,_h(\(A`c@juA_K:C-Pm +%O?1krs59`L)'FG$pc8qc6?ABKB$I@@qGuB6$8=6)9FEfV6(iL_Fb!>JiFjf"0:iT*a33JQ4=f2?'O7"77QfZH,#ZdCRaGm*$^L9k +%aT8B*#ERm_"a'sTQZRaWMmQ`)QYrS[27I!ddT=YoE.,t6g^1+0:aSV4^oR['[Us'-otePMZAp/4VEXEZNL%ZEXn^[dR.Z5%nh&p' +%n2QdsS;QrTNP@U?8p2pmoUH>8WR/c*QuAjbAf-k$9N6"W-HJ<#qh-uLjcCUd\3u++T!0oBK&B8GSl#5P=.p`;'TFs[%`OS*Oskl+ +%M%*-Z4!$W&'>cG8/&?t!)*)lU50`h<\dc[?&7Laq;i\*XomTfMYAR$8U%%)i&%L)P0?1a]uCur+:reJ`f*O(2VE? +%E?BIP7:K>L&P.:mK.?G>jFJh3ET0XUM2WHg1*@auecUR2-l*eY+9s)=#WY)r,kMSd0,uO?$_rC8K:.$,-pCZ8WWED5rij]/E7lgQ +%Hlqm@KN2I$03n8fl+7htR$clpf7U`4NtiC%KT=aZL]l&&"0u*60.7-(">'d+-[_c$bnnggFUFcT=@3ujcru/i;?l(9='`QSJ8Ga& +%,SA:TmmZcsYot.PO^M1r`/:]Ac&u[unQ:huVC;;'a+[=kkTaBpfUBk/%]qh4K!,sD1]@pYk/552\D4k-N0AJEEjJ9!$O1]ERVd%o^hL"#rWb2;Z`\T!^SIs,Ut5l;4M\ncWDh'fo[<:%Bq8??U>Tekm6On-)cmUR;h2mBd6o8`^.8^Ldn=RQd*^CF, +%5PRS?Zmj6LnG%S#5XF?n@?+st@FM<2:5rj$BP!dZ/u?Z&n9c.>es'DVaZ%!BnGM5s9b&Rs>/'LY+_*fD8WQl9Hq7:UWM)tH#ojP2 +%1L,O-&mW6(Ze$uf%uHHYB+WFa#b07r5dT^]!DoZT6bIdU#D*lcm8EKu3M.Hl34PTF#=65#F=]V`TqH%\4]8SHFmF<0(k^RcBsB$a +%TH!#H5)7(E-H]gpA21('"J;nV$.DQ``h9sWKGpin3C;ea(_?m:\Yt@+dNM'!6UX2m+sr:Cc?L+,a]2M%4c.0+H=QjZM*8!%`b?_thT'?(3'9[Pc/3MQ;+-POlAAn=&o`cpl^R]G\uE-.r[ +%<)Z:LF=F!s+fE#SH8EK@Seb@ScF$WP`s&HSVF7J!>Sq/pO^)7I*l\jGLJsQ!6,br"`=gY0C_?1&#eHHR@)D)>63eq&@T?7nYgX:_ +%80/h@NC&aJ0L\TEAJCZNNn4<_l!a=D657FhR)#E)"?>[O]]#Zh2,I\ijn-<9_5mR6T'$=?E(WV/*(P0Y'Zn,c/. +%U>Zj_!MZhd0Jo-Y7*6C5a4c9V/#rP^p;A@KPH<-DjJG&j<8:tDr?r'FTgCAR)L;D>EC*6qRN'+PIlHG6j'A4R_+oT&+O>4SFSC.Y3WtVo-t4,YpKn4>ARZCi`_2nHBe:[R0QU +%-E=nd\ekZ0Uf;?I)ck8$#UN5Hp-GH-ZshF?S(FkV((uTa_5?7iD]HciK1L#+K5RP?_Asr5XWd.F89#G*kU,?8[#j?iP?`1aKc;*k +%jQGQs?oVO.7Kf$Q!&P[oN04W=Z_;=S$]0SuaI*TI@tC"\Z"P-gkX/4^OIR:9,n[CmK4se>,bDFQjYhh2$n.Dip!ZH>g4UR%MPS4S +%5&GDh,R*Q\po[a/nn_923g/b5X;T/A:*["ZT$(nBRlJ,?Q'.jN/m;"OF1?br$T9L0/=//,QaSb62Hg,?_hG*#Cu-K*-(a0=4PKKX +%,^S/IIiNO/>Z8@[-S`V]=CDZ_.mEVO!@f9-*=r]?XB(AqY4J9%!k'N/V:).!lH-W$nH0YUtA2lYI$_&UEP'2j(i5^i;X9IR,j1JU$O%ck0Q"dnqHtbK_,+dQ+VAM>A@I6]@-NNeF`Crl:q5M +%?#BMB[o55VlMoA9C9)LO=FI:.iu@<]?11#mFfTS1pD6\G96C"%FQl^aomb.>&V'~> +%AI9_PrivateDataEnd diff --git a/doc/arm/isc-logo.pdf b/doc/arm/isc-logo.pdf new file mode 100644 index 0000000..71d3fdd Binary files /dev/null and b/doc/arm/isc-logo.pdf differ diff --git a/doc/arm/latex-fixup.pl b/doc/arm/latex-fixup.pl new file mode 100644 index 0000000..b133b5a --- /dev/null +++ b/doc/arm/latex-fixup.pl @@ -0,0 +1,49 @@ +#!/usr/bin/perl -w +# +# Copyright (C) 2005, 2007 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 +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: latex-fixup.pl,v 1.5 2007/06/19 23:47:13 tbox Exp $ + +# Sadly, the final stages of generating a presentable PDF file always +# seem to require some manual tweaking. Doesn't seem to matter what +# typesetting tool one uses, sane forms of automation only go so far, +# at least with present technology. +# +# This script is intended to be a collection of tweaks. The theory is +# that, while we can't avoid the need for tweaking, we can at least +# write the silly things down in a form that a program might be able +# to execute. Undoubtedly everythig in here will break, eventually, +# at which point it will need to be updated, but since the alternative +# is to do the final editing by hand every time, this approach seems +# the lesser of two evils. + +while (<>) { + + # Fix a db2latex oops. LaTeX2e does not like having tables with + # duplicate names. Perhaps the dblatex project will fix this + # someday, but we can get by with just deleting the offending + # LaTeX commands for now. + + s/\\addtocounter\{table\}\{-1\}//g; + + # Line break in the middle of quoting one period looks weird. + + s/{\\texttt{{\.\\dbz{}}}}/\\mbox{{\\texttt{{\.\\dbz{}}}}}/; + + # Add any further tweaking here. + + # Write out whatever we have now. + print; +} diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html new file mode 100644 index 0000000..6a3ff6f --- /dev/null +++ b/doc/arm/man.dig.html @@ -0,0 +1,673 @@ + + + + + +dig + + + + + + + +

+ + + + + + + +
dig
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

dig — DNS lookup utility

+
+
+

Synopsis

+

dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m] [-p port#] [-q name] [-t type] [-x addr] [-y [hmac:]name:key] [-4] [-6] [name] [type] [class] [queryopt...]

+

dig [-h]

+

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

+
+
+

DESCRIPTION

+

dig + (domain information groper) is a flexible tool + for interrogating DNS name servers. It performs DNS lookups and + displays the answers that are returned from the name server(s) that + were queried. Most DNS administrators use dig to + troubleshoot DNS problems because of its flexibility, ease of use and + clarity of output. Other lookup tools tend to have less functionality + than dig. +

+

+ Although dig is normally used with + command-line + arguments, it also has a batch mode of operation for reading lookup + requests from a file. A brief summary of its command-line arguments + and options is printed when the -h option is given. + Unlike earlier versions, the BIND 9 implementation of + dig allows multiple lookups to be issued + from the + command line. +

+

+ Unless it is told to query a specific name server, + dig will try each of the servers listed + in + /etc/resolv.conf. +

+

+ When no command line arguments or options are given, + dig will perform an NS query for "." (the root). +

+

+ It is possible to set per-user defaults for dig via + ${HOME}/.digrc. This file is read and + any options in it + are applied before the command line arguments. +

+

+ The IN and CH class names overlap with the IN and CH top level + domains names. Either use the -t and + -c options to specify the type and class, + use the -q the specify the domain name, or + use "IN." and "CH." when looking up these top level domains. +

+
+
+

SIMPLE USAGE

+

+ A typical invocation of dig looks like: +

+
 dig @server name type
+

+ where: + +

+
+
server
+

+ is the name or IP address of the name server to query. This can + be an IPv4 + address in dotted-decimal notation or an IPv6 + address in colon-delimited notation. When the supplied + server argument is a + hostname, + dig resolves that name before + querying that name + server. If no server + argument is provided, + dig consults /etc/resolv.conf + and queries the name servers listed there. The reply from the + name + server that responds is displayed. +

+
name
+

+ is the name of the resource record that is to be looked up. +

+
type
+

+ indicates what type of query is required — + ANY, A, MX, SIG, etc. + type can be any valid query + type. If no + type argument is supplied, + dig will perform a lookup for an + A record. +

+
+

+

+
+
+

OPTIONS

+

+ The -b option sets the source IP address of the query + to address. This must be a valid + address on + one of the host's network interfaces or "0.0.0.0" or "::". An optional + port + may be specified by appending "#<port>" +

+

+ The default query class (IN for internet) is overridden by the + -c option. class is + any valid + class, such as HS for Hesiod records or CH for Chaosnet records. +

+

+ The -f option makes dig + operate + in batch mode by reading a list of lookup requests to process from the + file filename. The file contains a + number of + queries, one per line. Each entry in the file should be organized in + the same way they would be presented as queries to + dig using the command-line interface. +

+

+ The -m option enables memory usage debugging. + +

+

+ If a non-standard port number is to be queried, the + -p option is used. port# is + the port number that dig will send its + queries + instead of the standard DNS port number 53. This option would be used + to test a name server that has been configured to listen for queries + on a non-standard port number. +

+

+ The -4 option forces dig + to only + use IPv4 query transport. The -6 option forces + dig to only use IPv6 query transport. +

+

+ The -t option sets the query type to + type. It can be any valid query type + which is + supported in BIND 9. The default query type is "A", unless the + -x option is supplied to indicate a reverse lookup. + A zone transfer can be requested by specifying a type of AXFR. When + an incremental zone transfer (IXFR) is required, + type is set to ixfr=N. + The incremental zone transfer will contain the changes made to the zone + since the serial number in the zone's SOA record was + N. +

+

+ The -q option sets the query name to + name. This useful do distinguish the + name from other arguments. +

+

+ Reverse lookups — mapping addresses to names — are simplified by the + -x option. addr is + an IPv4 + address in dotted-decimal notation, or a colon-delimited IPv6 address. + When this option is used, there is no need to provide the + name, class and + type arguments. dig + automatically performs a lookup for a name like + 11.12.13.10.in-addr.arpa and sets the + query type and + class to PTR and IN respectively. By default, IPv6 addresses are + looked up using nibble format under the IP6.ARPA domain. + To use the older RFC1886 method using the IP6.INT domain + specify the -i option. Bit string labels (RFC2874) + are now experimental and are not attempted. +

+

+ To sign the DNS queries sent by dig and + their + responses using transaction signatures (TSIG), specify a TSIG key file + using the -k option. You can also specify the TSIG + key itself on the command line using the -y option; + hmac is the type of the TSIG, default HMAC-MD5, + name is the name of the TSIG key and + key is the actual key. The key is a + base-64 + encoded string, typically generated by + dnssec-keygen(8). + + Caution should be taken when using the -y option on + multi-user systems as the key can be visible in the output from + ps(1) + or in the shell's history file. When + using TSIG authentication with dig, the name + server that is queried needs to know the key and algorithm that is + being used. In BIND, this is done by providing appropriate + key and server statements in + named.conf. +

+
+
+

QUERY OPTIONS

+

dig + provides a number of query options which affect + the way in which lookups are made and the results displayed. Some of + these set or reset flag bits in the query header, some determine which + sections of the answer get printed, and others determine the timeout + and retry strategies. +

+

+ Each query option is identified by a keyword preceded by a plus sign + (+). Some keywords set or reset an + option. These may be preceded + by the string no to negate the meaning of + that keyword. Other + keywords assign values to options like the timeout interval. They + have the form +keyword=value. + The query options are: + +

+
+
+[no]tcp
+

+ Use [do not use] TCP when querying name servers. The default + behavior is to use UDP unless an AXFR or IXFR query is + requested, in + which case a TCP connection is used. +

+
+[no]vc
+

+ Use [do not use] TCP when querying name servers. This alternate + syntax to +[no]tcp is + provided for backwards + compatibility. The "vc" stands for "virtual circuit". +

+
+[no]ignore
+

+ Ignore truncation in UDP responses instead of retrying with TCP. + By + default, TCP retries are performed. +

+
+domain=somename
+

+ Set the search list to contain the single domain + somename, as if specified in + a + domain directive in + /etc/resolv.conf, and enable + search list + processing as if the +search + option were given. +

+
+[no]search
+

+ Use [do not use] the search list defined by the searchlist or + domain + directive in resolv.conf (if + any). + The search list is not used by default. +

+
+[no]showsearch
+

+ Perform [do not perform] a search showing intermediate + results. +

+
+[no]defname
+

+ Deprecated, treated as a synonym for +[no]search +

+
+[no]aaonly
+

+ Sets the "aa" flag in the query. +

+
+[no]aaflag
+

+ A synonym for +[no]aaonly. +

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

+
+[no]cdflag
+

+ Set [do not set] the CD (checking disabled) bit in the query. + This + requests the server to not perform DNSSEC validation of + responses. +

+
+[no]cl
+

+ Display [do not display] the CLASS when printing the record. +

+
+[no]ttlid
+

+ Display [do not display] the TTL when printing the record. +

+
+[no]recurse
+

+ Toggle the setting of the RD (recursion desired) bit in the + query. + This bit is set by default, which means dig + normally sends recursive queries. Recursion is automatically + disabled + when the +nssearch or + +trace query options are + used. +

+
+[no]nssearch
+

+ When this option is set, dig + attempts to find the + authoritative name servers for the zone containing the name + being + looked up and display the SOA record that each name server has + for the + zone. +

+
+[no]trace
+

+ Toggle tracing of the delegation path from the root name servers + for + the name being looked up. Tracing is disabled by default. When + tracing is enabled, dig makes + iterative queries to + resolve the name being looked up. It will follow referrals from + the + root servers, showing the answer from each server that was used + to + resolve the lookup. +

+
+[no]cmd
+

+ Toggles the printing of the initial comment in the output + identifying + the version of dig and the query + options that have + been applied. This comment is printed by default. +

+
+[no]short
+

+ Provide a terse answer. The default is to print the answer in a + verbose form. +

+
+[no]identify
+

+ Show [or do not show] the IP address and port number that + supplied the + answer when the +short option + is enabled. If + short form answers are requested, the default is not to show the + source address and port number of the server that provided the + answer. +

+
+[no]comments
+

+ Toggle the display of comment lines in the output. The default + is to + print comments. +

+
+[no]stats
+

+ This query option toggles the printing of statistics: when the + query + was made, the size of the reply and so on. The default + behavior is + to print the query statistics. +

+
+[no]qr
+

+ Print [do not print] the query as it is sent. + By default, the query is not printed. +

+
+[no]question
+

+ Print [do not print] the question section of a query when an + answer is + returned. The default is to print the question section as a + comment. +

+
+[no]answer
+

+ Display [do not display] the answer section of a reply. The + default + is to display it. +

+
+[no]authority
+

+ Display [do not display] the authority section of a reply. The + default is to display it. +

+
+[no]additional
+

+ Display [do not display] the additional section of a reply. + The default is to display it. +

+
+[no]all
+

+ Set or clear all display flags. +

+
+time=T
+

+ + Sets the timeout for a query to + T seconds. The default + timeout is 5 seconds. + An attempt to set T to less + than 1 will result + in a query timeout of 1 second being applied. +

+
+tries=T
+

+ Sets the number of times to try UDP queries to server to + T instead of the default, 3. + If + T is less than or equal to + zero, the number of + tries is silently rounded up to 1. +

+
+retry=T
+

+ Sets the number of times to retry UDP queries to server to + T instead of the default, 2. + Unlike + +tries, this does not include + the initial + query. +

+
+ndots=D
+

+ Set the number of dots that have to appear in + name to D for it to be + considered absolute. The default value is that defined using + the + ndots statement in /etc/resolv.conf, or 1 if no + ndots statement is present. Names with fewer dots are + interpreted as + relative names and will be searched for in the domains listed in + the + search or domain directive in + /etc/resolv.conf. +

+
+bufsize=B
+

+ Set the UDP message buffer size advertised using EDNS0 to + B bytes. The maximum and minimum sizes + of this buffer are 65535 and 0 respectively. Values outside + this range are rounded up or down appropriately. + Values other than zero will cause a EDNS query to be sent. +

+
+edns=#
+

+ Specify the EDNS version to query with. Valid values + are 0 to 255. Setting the EDNS version will cause a + EDNS query to be sent. +noedns clears the + remembered EDNS version. +

+
+[no]multiline
+

+ Print records like the SOA records in a verbose multi-line + format with human-readable comments. The default is to print + each record on a single line, to facilitate machine parsing + of the dig output. +

+
+[no]fail
+

+ Do not try the next server if you receive a SERVFAIL. The + default is + to not try the next server which is the reverse of normal stub + resolver + behavior. +

+
+[no]besteffort
+

+ Attempt to display the contents of messages which are malformed. + The default is to not display malformed answers. +

+
+[no]dnssec
+

+ Requests DNSSEC records be sent by setting the DNSSEC OK bit + (DO) + in the OPT record in the additional section of the query. +

+
+[no]sigchase
+

+ Chase DNSSEC signature chains. Requires dig be compiled with + -DDIG_SIGCHASE. +

+
+trusted-key=####
+
+

+ Specifies a file containing trusted keys to be used with + +sigchase. Each DNSKEY record must be + on its own line. +

+

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

+

+ Requires dig be compiled with -DDIG_SIGCHASE. +

+
+
+[no]topdown
+

+ When chasing DNSSEC signature chains perform a top-down + validation. + Requires dig be compiled with -DDIG_SIGCHASE. +

+
+[no]nsid
+

+ Include an EDNS name server ID request when sending a query. +

+
+

+ +

+
+
+

MULTIPLE QUERIES

+

+ The BIND 9 implementation of dig + supports + specifying multiple queries on the command line (in addition to + supporting the -f batch file option). Each of those + queries can be supplied with its own set of flags, options and query + options. +

+

+ In this case, each query argument + represent an + individual query in the command-line syntax described above. Each + consists of any of the standard options and flags, the name to be + looked up, an optional query type and class and any query options that + should be applied to that query. +

+

+ A global set of query options, which should be applied to all queries, + can also be supplied. These global query options must precede the + first tuple of name, class, type, options, flags, and query options + supplied on the command line. Any global query options (except + the +[no]cmd option) can be + overridden by a query-specific set of query options. For example: +

+
+dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
+
+

+ shows how dig could be used from the + command line + to make three lookups: an ANY query for www.isc.org, a + reverse lookup of 127.0.0.1 and a query for the NS records of + isc.org. + + A global query option of +qr is + applied, so + that dig shows the initial query it made + for each + lookup. The final query has a local query option of + +noqr which means that dig + will not print the initial query when it looks up the NS records for + isc.org. +

+
+
+

IDN SUPPORT

+

+ If dig has been built with IDN (internationalized + domain name) support, it can accept and display non-ASCII domain names. + dig appropriately converts character encoding of + domain name before sending a request to DNS server or displaying a + reply from the server. + If you'd like to turn off the IDN support for some reason, defines + the IDN_DISABLE environment variable. + The IDN support is disabled if the variable is set when + dig runs. +

+
+
+

FILES

+

/etc/resolv.conf +

+

${HOME}/.digrc +

+
+
+

SEE ALSO

+

host(1), + named(8), + dnssec-keygen(8), + RFC1035. +

+
+
+

BUGS

+

+ There are probably too many query options. +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
Manual pages Home host
+
+ + diff --git a/doc/arm/man.dnssec-dsfromkey.html b/doc/arm/man.dnssec-dsfromkey.html new file mode 100644 index 0000000..347c421 --- /dev/null +++ b/doc/arm/man.dnssec-dsfromkey.html @@ -0,0 +1,170 @@ + + + + + +dnssec-dsfromkey + + + + + + + +
+ + + + + + + +
dnssec-dsfromkey
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

dnssec-dsfromkey — DNSSEC DS RR generation tool

+
+
+

Synopsis

+

dnssec-dsfromkey [-v level] [-1] [-2] [-a alg] {keyfile}

+

dnssec-dsfromkey {-s} [-v level] [-1] [-2] [-a alg] [-c class] [-d dir] {dnsname}

+
+
+

DESCRIPTION

+

dnssec-dsfromkey + outputs the Delegation Signer (DS) resource record (RR), as defined in + RFC 3658 and RFC 4509, for the given key(s). +

+
+
+

OPTIONS

+
+
-1
+

+ Use SHA-1 as the digest algorithm (the default is to use + both SHA-1 and SHA-256). +

+
-2
+

+ Use SHA-256 as the digest algorithm. +

+
-a algorithm
+

+ Select the digest algorithm. The value of + algorithm must be one of SHA-1 (SHA1) or + SHA-256 (SHA256). These values are case insensitive. +

+
-v level
+

+ Sets the debugging level. +

+
-s
+

+ Keyset mode: in place of the keyfile name, the argument is + the DNS domain name of a keyset file. Following options make sense + only in this mode. +

+
-c class
+

+ Specifies the DNS class (default is IN), useful only + in the keyset mode. +

+
-d directory
+

+ Look for keyset files in + directory as the directory, ignored when + not in the keyset mode. +

+
+
+
+

EXAMPLE

+

+ To build the SHA-256 DS RR from the + Kexample.com.+003+26160 + keyfile name, the following command would be issued: +

+

dnssec-dsfromkey -2 Kexample.com.+003+26160 +

+

+ The command would print something like: +

+

example.com. IN DS 26160 5 2 3A1EADA7A74B8D0BA86726B0C227AA85AB8BBD2B2004F41A868A54F0 C5EA0B94 +

+
+
+

FILES

+

+ The keyfile can be designed by the key identification + Knnnn.+aaa+iiiii or the full file name + Knnnn.+aaa+iiiii.key as generated by + dnssec-keygen(8). +

+

+ The keyset file name is built from the directory, + the string keyset- and the + dnsname. +

+
+
+

CAVEAT

+

+ A keyfile error can give a "file not found" even if the file exists. +

+
+
+

SEE ALSO

+

dnssec-keygen(8), + dnssec-signzone(8), + BIND 9 Administrator Reference Manual, + RFC 3658, + RFC 4509. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
host Home dnssec-keyfromlabel +
+
+ + diff --git a/doc/arm/man.dnssec-keyfromlabel.html b/doc/arm/man.dnssec-keyfromlabel.html new file mode 100644 index 0000000..ca9f3da --- /dev/null +++ b/doc/arm/man.dnssec-keyfromlabel.html @@ -0,0 +1,210 @@ + + + + + +dnssec-keyfromlabel + + + + + + + +
+ + + + + + + +
dnssec-keyfromlabel
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

dnssec-keyfromlabel — DNSSEC key generation tool

+
+
+

Synopsis

+

dnssec-keyfromlabel {-a algorithm} {-l label} [-c class] [-f flag] [-k] [-n nametype] [-p protocol] [-t type] [-v level] {name}

+
+
+

DESCRIPTION

+

dnssec-keyfromlabel + gets keys with the given label from a crypto hardware and builds + key files for DNSSEC (Secure DNS), as defined in RFC 2535 + and RFC 4034. +

+
+
+

OPTIONS

+
+
-a algorithm
+
+

+ Selects the cryptographic algorithm. The value of + algorithm must be one of RSAMD5 (RSA) + or RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA or DH (Diffie Hellman). + These values are case insensitive. +

+

+ Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement + algorithm, and DSA is recommended. +

+

+ Note 2: DH automatically sets the -k flag. +

+
+
-l label
+

+ Specifies the label of keys in the crypto hardware + (PKCS#11 device). +

+
-n nametype
+

+ Specifies the owner type of the key. The value of + nametype must either be ZONE (for a DNSSEC + zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with + a host (KEY)), + USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). + These values are + case insensitive. +

+
-c class
+

+ Indicates that the DNS record containing the key should have + the specified class. If not specified, class IN is used. +

+
-f flag
+

+ Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. +

+
-h
+

+ Prints a short summary of the options and arguments to + dnssec-keygen. +

+
-k
+

+ Generate KEY records rather than DNSKEY records. +

+
-p protocol
+

+ Sets the protocol value for the generated key. The protocol + is a number between 0 and 255. The default is 3 (DNSSEC). + Other possible values for this argument are listed in + RFC 2535 and its successors. +

+
-t type
+

+ Indicates the use of the key. type must be + one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default + is AUTHCONF. AUTH refers to the ability to authenticate + data, and CONF the ability to encrypt data. +

+
-v level
+

+ Sets the debugging level. +

+
+
+
+

GENERATED KEY FILES

+

+ When dnssec-keyfromlabel completes + successfully, + it prints a string of the form Knnnn.+aaa+iiiii + to the standard output. This is an identification string for + the key files it has generated. +

+
    +

  • nnnn is the key name. +

    • +

  • aaa is the numeric representation + of the + algorithm. +

    • +

  • iiiii is the key identifier (or + footprint). +

    • +
+

dnssec-keyfromlabel + creates two files, with names based + on the printed string. Knnnn.+aaa+iiiii.key + contains the public key, and + Knnnn.+aaa+iiiii.private contains the + private + key. +

+

+ The .key file contains a DNS KEY record + that + can be inserted into a zone file (directly or with a $INCLUDE + statement). +

+

+ The .private file contains algorithm + specific + fields. For obvious security reasons, this file does not have + general read permission. +

+
+
+

SEE ALSO

+

dnssec-keygen(8), + dnssec-signzone(8), + BIND 9 Administrator Reference Manual, + RFC 2539, + RFC 2845, + RFC 4033. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+dnssec-dsfromkey Home dnssec-keygen +
+
+ + diff --git a/doc/arm/man.dnssec-keygen.html b/doc/arm/man.dnssec-keygen.html new file mode 100644 index 0000000..35fe743 --- /dev/null +++ b/doc/arm/man.dnssec-keygen.html @@ -0,0 +1,270 @@ + + + + + +dnssec-keygen + + + + + + + +
+ + + + + + + +
dnssec-keygen
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

dnssec-keygen — DNSSEC key generation tool

+
+
+

Synopsis

+

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

+

dnssec-keygen + generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 + and RFC 4034. It can also generate keys for use with + TSIG (Transaction Signatures), as defined in RFC 2845. +

+
+
+

OPTIONS

+
+
-a algorithm
+
+

+ Selects the cryptographic algorithm. The value of + algorithm must be one of RSAMD5 (RSA) or RSASHA1, + DSA, NSEC3RSASHA1, NSEC3DSA, DH (Diffie Hellman), or HMAC-MD5. + These values are case insensitive. +

+

+ Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement + algorithm, and DSA is recommended. For TSIG, HMAC-MD5 is + mandatory. +

+

+ Note 2: HMAC-MD5 and DH automatically set the -k flag. +

+
+
-b keysize
+

+ Specifies the number of bits in the key. The choice of key + size depends on the algorithm used. RSAMD5 / RSASHA1 keys must be + between + 512 and 2048 bits. Diffie Hellman keys must be between + 128 and 4096 bits. DSA keys must be between 512 and 1024 + bits and an exact multiple of 64. HMAC-MD5 keys must be + between 1 and 512 bits. +

+
-n nametype
+

+ Specifies the owner type of the key. The value of + nametype must either be ZONE (for a DNSSEC + zone key (KEY/DNSKEY)), HOST or ENTITY (for a key associated with + a host (KEY)), + USER (for a key associated with a user(KEY)) or OTHER (DNSKEY). + These values are case insensitive. Defaults to ZONE for DNSKEY + generation. +

+
-c class
+

+ Indicates that the DNS record containing the key should have + the specified class. If not specified, class IN is used. +

+
-e
+

+ If generating an RSAMD5/RSASHA1 key, use a large exponent. +

+
-f flag
+

+ Set the specified flag in the flag field of the KEY/DNSKEY record. + The only recognized flag is KSK (Key Signing Key) DNSKEY. +

+
-g generator
+

+ If generating a Diffie Hellman key, use this generator. + Allowed values are 2 and 5. If no generator + is specified, a known prime from RFC 2539 will be used + if possible; otherwise the default is 2. +

+
-h
+

+ Prints a short summary of the options and arguments to + dnssec-keygen. +

+
-k
+

+ Generate KEY records rather than DNSKEY records. +

+
-p protocol
+

+ Sets the protocol value for the generated key. The protocol + is a number between 0 and 255. The default is 3 (DNSSEC). + Other possible values for this argument are listed in + RFC 2535 and its successors. +

+
-r randomdev
+

+ Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev + specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

+
-s strength
+

+ Specifies the strength value of the key. The strength is + a number between 0 and 15, and currently has no defined + purpose in DNSSEC. +

+
-t type
+

+ Indicates the use of the key. type must be + one of AUTHCONF, NOAUTHCONF, NOAUTH, or NOCONF. The default + is AUTHCONF. AUTH refers to the ability to authenticate + data, and CONF the ability to encrypt data. +

+
-v level
+

+ Sets the debugging level. +

+
+
+
+

GENERATED KEYS

+

+ When dnssec-keygen completes + successfully, + it prints a string of the form Knnnn.+aaa+iiiii + to the standard output. This is an identification string for + the key it has generated. +

+
    +

  • nnnn is the key name. +

    • +

  • aaa is the numeric representation + of the + algorithm. +

    • +

  • iiiii is the key identifier (or + footprint). +

    • +
+

dnssec-keygen + creates two files, with names based + on the printed string. Knnnn.+aaa+iiiii.key + contains the public key, and + Knnnn.+aaa+iiiii.private contains the + private + key. +

+

+ The .key file contains a DNS KEY record + that + can be inserted into a zone file (directly or with a $INCLUDE + statement). +

+

+ The .private file contains + algorithm-specific + fields. For obvious security reasons, this file does not have + general read permission. +

+

+ Both .key and .private + files are generated for symmetric encryption algorithms such as + HMAC-MD5, even though the public and private key are equivalent. +

+
+
+

EXAMPLE

+

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

+

dnssec-keygen -a DSA -b 768 -n ZONE example.com +

+

+ The command would print a string of the form: +

+

Kexample.com.+003+26160 +

+

+ In this example, dnssec-keygen creates + the files Kexample.com.+003+26160.key + and + Kexample.com.+003+26160.private. +

+
+
+

SEE ALSO

+

dnssec-signzone(8), + BIND 9 Administrator Reference Manual, + RFC 2539, + RFC 2845, + RFC 4033. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+dnssec-keyfromlabel Home dnssec-signzone +
+
+ + diff --git a/doc/arm/man.dnssec-signzone.html b/doc/arm/man.dnssec-signzone.html new file mode 100644 index 0000000..237d19d --- /dev/null +++ b/doc/arm/man.dnssec-signzone.html @@ -0,0 +1,340 @@ + + + + + +dnssec-signzone + + + + + + + +
+ + + + + + + +
dnssec-signzone
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

dnssec-signzone — DNSSEC zone signing tool

+
+
+

Synopsis

+

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] [-3 salt] [-H iterations] [-A] {zonefile} [key...]

+
+
+

DESCRIPTION

+

dnssec-signzone + signs a zone. It generates + NSEC and RRSIG records and produces a signed version of the + zone. The security status of delegations from the signed zone + (that is, whether the child zones are secure or not) is + determined by the presence or absence of a + keyset file for each child zone. +

+
+
+

OPTIONS

+
+
-a
+

+ Verify all generated signatures. +

+
-c class
+

+ Specifies the DNS class of the zone. +

+
-k key
+

+ Treat specified key as a key signing key ignoring any + key flags. This option may be specified multiple times. +

+
-l domain
+

+ Generate a DLV set in addition to the key (DNSKEY) and DS sets. + The domain is appended to the name of the records. +

+
-d directory
+

+ Look for keyset files in + directory as the directory +

+
-g
+

+ Generate DS records for child zones from keyset files. + Existing DS records will be removed. +

+
-s start-time
+

+ Specify the date and time when the generated RRSIG records + become valid. This can be either an absolute or relative + time. An absolute start time is indicated by a number + in YYYYMMDDHHMMSS notation; 20000530144500 denotes + 14:45:00 UTC on May 30th, 2000. A relative start time is + indicated by +N, which is N seconds from the current time. + If no start-time is specified, the current + time minus 1 hour (to allow for clock skew) is used. +

+
-e end-time
+

+ Specify the date and time when the generated RRSIG records + expire. As with start-time, an absolute + time is indicated in YYYYMMDDHHMMSS notation. A time relative + to the start time is indicated with +N, which is N seconds from + the start time. A time relative to the current time is + indicated with now+N. If no end-time is + specified, 30 days from the start time is used as a default. +

+
-f output-file
+

+ The name of the output file containing the signed zone. The + default is to append .signed to + the + input filename. +

+
-h
+

+ Prints a short summary of the options and arguments to + dnssec-signzone. +

+
-i interval
+
+

+ When a previously-signed zone is passed as input, records + may be resigned. The interval option + specifies the cycle interval as an offset from the current + time (in seconds). If a RRSIG record expires after the + cycle interval, it is retained. Otherwise, it is considered + to be expiring soon, and it will be replaced. +

+

+ The default cycle interval is one quarter of the difference + between the signature end and start times. So if neither + end-time or start-time + are specified, dnssec-signzone + generates + signatures that are valid for 30 days, with a cycle + interval of 7.5 days. Therefore, if any existing RRSIG records + are due to expire in less than 7.5 days, they would be + replaced. +

+
+
-I input-format
+

+ The format of the input zone file. + Possible formats are "text" (default) + and "raw". + This option is primarily intended to be used for dynamic + signed zones so that the dumped zone file in a non-text + format containing updates can be signed directly. + The use of this option does not make much sense for + non-dynamic zones. +

+
-j jitter
+
+

+ When signing a zone with a fixed signature lifetime, all + RRSIG records issued at the time of signing expires + simultaneously. If the zone is incrementally signed, i.e. + a previously-signed zone is passed as input to the signer, + all expired signatures have to be regenerated at about the + same time. The jitter option specifies a + jitter window that will be used to randomize the signature + expire time, thus spreading incremental signature + regeneration over time. +

+

+ Signature lifetime jitter also to some extent benefits + validators and servers by spreading out cache expiration, + i.e. if large numbers of RRSIGs don't expire at the same time + from all caches there will be less congestion than if all + validators need to refetch at mostly the same time. +

+
+
-n ncpus
+

+ Specifies the number of threads to use. By default, one + thread is started for each detected CPU. +

+
-N soa-serial-format
+
+

+ The SOA serial number format of the signed zone. + Possible formats are "keep" (default), + "increment" and + "unixtime". +

+
+
"keep"
+

Do not modify the SOA serial number.

+
"increment"
+

Increment the SOA serial number using RFC 1982 + arithmetics.

+
"unixtime"
+

Set the SOA serial number to the number of seconds + since epoch.

+
+
+
-o origin
+

+ The zone origin. If not specified, the name of the zone file + is assumed to be the origin. +

+
-O output-format
+

+ The format of the output file containing the signed zone. + Possible formats are "text" (default) + and "raw". +

+
-p
+

+ Use pseudo-random data when signing the zone. This is faster, + but less secure, than using real random data. This option + may be useful when signing large zones or when the entropy + source is limited. +

+
-r randomdev
+

+ Specifies the source of randomness. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev + specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

+
-t
+

+ Print statistics at completion. +

+
-v level
+

+ Sets the debugging level. +

+
-z
+

+ Ignore KSK flag on key when determining what to sign. +

+
-3 salt
+

+ Generate a NSEC3 chain with the given hex encoded salt. + A dash (salt) can + be used to indicate that no salt is to be used when generating the NSEC3 chain. +

+
-H iterations
+

+ When generating a NSEC3 chain use this many interations. The + default is 100. +

+
-A
+

+ When generating a NSEC3 chain set the OPTOUT flag on all + NSEC3 records and do not generate NSEC3 records for insecure + delegations. +

+
zonefile
+

+ The file containing the zone to be signed. +

+
key
+

+ Specify which keys should be used to sign the zone. If + no keys are specified, then the zone will be examined + for DNSKEY records at the zone apex. If these are found and + there are matching private keys, in the current directory, + then these will be used for signing. +

+
+
+
+

EXAMPLE

+

+ The following command signs the example.com + zone with the DSA key generated by dnssec-keygen + (Kexample.com.+003+17247). The zone's keys must be in the master + file (db.example.com). This invocation looks + for keyset files, in the current directory, + so that DS records can be generated from them (-g). +

+
% dnssec-signzone -g -o example.com db.example.com \
+Kexample.com.+003+17247
+db.example.com.signed
+%
+

+ In the above example, dnssec-signzone creates + the file db.example.com.signed. This + file should be referenced in a zone statement in a + named.conf file. +

+

+ This example re-signs a previously signed zone with default parameters. + The private keys are assumed to be in the current directory. +

+
% cp db.example.com.signed db.example.com
+% dnssec-signzone -o example.com db.example.com
+db.example.com.signed
+%
+
+
+

SEE ALSO

+

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

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+dnssec-keygen Home named-checkconf +
+
+ + diff --git a/doc/arm/man.host.html b/doc/arm/man.host.html new file mode 100644 index 0000000..7d1fa9e --- /dev/null +++ b/doc/arm/man.host.html @@ -0,0 +1,249 @@ + + + + + +host + + + + + + + +
+ + + + + + + +
host
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

host — DNS lookup utility

+
+
+

Synopsis

+

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

+
+
+

DESCRIPTION

+

host + is a simple utility for performing DNS lookups. + It is normally used to convert names to IP addresses and vice versa. + When no arguments or options are given, + host + prints a short summary of its command line arguments and options. +

+

name is the domain name that is to be + looked + up. It can also be a dotted-decimal IPv4 address or a colon-delimited + IPv6 address, in which case host will by + default + perform a reverse lookup for that address. + server is an optional argument which + is either + the name or IP address of the name server that host + should query instead of the server or servers listed in + /etc/resolv.conf. +

+

+ The -a (all) option is equivalent to setting the + -v option and asking host to make + a query of type ANY. +

+

+ When the -C option is used, host + will attempt to display the SOA records for zone + name from all the listed + authoritative name + servers for that zone. The list of name servers is defined by the NS + records that are found for the zone. +

+

+ The -c option instructs to make a DNS query of class + class. This can be used to lookup + Hesiod or + Chaosnet class resource records. The default class is IN (Internet). +

+

+ Verbose output is generated by host when + the + -d or -v option is used. The two + options are equivalent. They have been provided for backwards + compatibility. In previous versions, the -d option + switched on debugging traces and -v enabled verbose + output. +

+

+ List mode is selected by the -l option. This makes + host perform a zone transfer for zone + name. Transfer the zone printing out + the NS, PTR + and address records (A/AAAA). If combined with -a + all records will be printed. +

+

+ The -i + option specifies that reverse lookups of IPv6 addresses should + use the IP6.INT domain as defined in RFC1886. + The default is to use IP6.ARPA. +

+

+ The -N option sets the number of dots that have to be + in name for it to be considered + absolute. The + default value is that defined using the ndots statement in + /etc/resolv.conf, or 1 if no ndots + statement is + present. Names with fewer dots are interpreted as relative names and + will be searched for in the domains listed in the search + or domain directive in + /etc/resolv.conf. +

+

+ The number of UDP retries for a lookup can be changed with the + -R option. number + indicates + how many times host will repeat a query + that does + not get answered. The default number of retries is 1. If + number is negative or zero, the + number of + retries will default to 1. +

+

+ Non-recursive queries can be made via the -r option. + Setting this option clears the RD — recursion + desired — bit in the query which host makes. + This should mean that the name server receiving the query will not + attempt to resolve name. The + -r option enables host + 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. +

+

+ 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 + require it, such as zone transfer (AXFR) requests. +

+

+ The -4 option forces host to only + use IPv4 query transport. The -6 option forces + host to only use IPv6 query transport. +

+

+ The -t option is used to select the query type. + type can be any recognized query + type: CNAME, + 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 + -C option was given, queries will be made for SOA + records, and if name is a + dotted-decimal IPv4 + address or colon-delimited IPv6 address, host will + query for PTR records. If a query type of IXFR is chosen the starting + serial number can be specified by appending an equal followed by the + starting serial number (e.g. -t IXFR=12345678). +

+

+ The time to wait for a reply can be controlled through the + -W and -w options. The + -W option makes host + wait for + wait seconds. If wait + is less than one, the wait interval is set to one second. When the + -w option is used, host + will + effectively wait forever for a reply. The time to wait for a response + will be set to the number of seconds given by the hardware's maximum + value for an integer quantity. +

+

+ The -s option tells host + not to send the query to the next nameserver + if any server responds with a SERVFAIL response, which is the + reverse of normal stub resolver behavior. +

+

+ The -m can be used to set the memory usage debugging + flags + record, usage and + trace. +

+
+
+

IDN SUPPORT

+

+ If host has been built with IDN (internationalized + domain name) support, it can accept and display non-ASCII domain names. + host appropriately converts character encoding of + domain name before sending a request to DNS server or displaying a + reply from the server. + If you'd like to turn off the IDN support for some reason, defines + the IDN_DISABLE environment variable. + The IDN support is disabled if the variable is set when + host runs. +

+
+
+

FILES

+

/etc/resolv.conf +

+
+
+

SEE ALSO

+

dig(1), + named(8). +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
dig Home dnssec-dsfromkey +
+
+ + diff --git a/doc/arm/man.named-checkconf.html b/doc/arm/man.named-checkconf.html new file mode 100644 index 0000000..5c6adcd --- /dev/null +++ b/doc/arm/man.named-checkconf.html @@ -0,0 +1,134 @@ + + + + + +named-checkconf + + + + + + + +
+ + + + + + + +
named-checkconf
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

named-checkconf — named configuration file syntax checking tool

+
+
+

Synopsis

+

named-checkconf [-h] [-v] [-j] [-t directory] {filename} [-z]

+
+
+

DESCRIPTION

+

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

+
+
+

OPTIONS

+
+
-h
+

+ Print the usage summary and exit. +

+
-t directory
+

+ Chroot to directory so that + include + directives in the configuration file are processed as if + run by a similarly chrooted named. +

+
-v
+

+ Print the version of the named-checkconf + program and exit. +

+
-z
+

+ Perform a test load of all master zones found in + named.conf. +

+
-j
+

+ When loading a zonefile read the journal if it exists. +

+
filename
+

+ The name of the configuration file to be checked. If not + specified, it defaults to /etc/named.conf. +

+
+
+
+

RETURN VALUES

+

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

+
+
+

SEE ALSO

+

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

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+dnssec-signzone Home named-checkzone +
+
+ + diff --git a/doc/arm/man.named-checkzone.html b/doc/arm/man.named-checkzone.html new file mode 100644 index 0000000..70b029f --- /dev/null +++ b/doc/arm/man.named-checkzone.html @@ -0,0 +1,300 @@ + + + + + +named-checkzone + + + + + + + +
+ + + + + + + +
named-checkzone
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

named-checkzone, named-compilezone — zone file validity checking or converting tool

+
+
+

Synopsis

+

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

+

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

+

named-checkzone + checks the syntax and integrity of a zone file. It performs the + same checks as named does when loading a + zone. This makes named-checkzone useful for + checking zone files before configuring them into a name server. +

+

+ named-compilezone is similar to + named-checkzone, but it always dumps the + zone contents to a specified file in a specified format. + Additionally, it applies stricter check levels by default, + since the dump output will be used as an actual zone file + loaded by named. + When manually specified otherwise, the check levels must at + least be as strict as those specified in the + named configuration file. +

+
+
+

OPTIONS

+
+
-d
+

+ Enable debugging. +

+
-h
+

+ Print the usage summary and exit. +

+
-q
+

+ Quiet mode - exit code only. +

+
-v
+

+ Print the version of the named-checkzone + program and exit. +

+
-j
+

+ When loading the zone file read the journal if it exists. +

+
-c class
+

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

+
-i mode
+
+

+ Perform post-load zone integrity checks. Possible modes are + "full" (default), + "full-sibling", + "local", + "local-sibling" and + "none". +

+

+ Mode "full" checks that MX records + refer to A or AAAA record (both in-zone and out-of-zone + hostnames). Mode "local" only + checks MX records which refer to in-zone hostnames. +

+

+ Mode "full" checks that SRV records + refer to A or AAAA record (both in-zone and out-of-zone + hostnames). Mode "local" only + checks SRV records which refer to in-zone hostnames. +

+

+ Mode "full" checks that delegation NS + records refer to A or AAAA record (both in-zone and out-of-zone + hostnames). It also checks that glue address records + in the zone match those advertised by the child. + Mode "local" only checks NS records which + refer to in-zone hostnames or that some required glue exists, + that is when the nameserver is in a child zone. +

+

+ Mode "full-sibling" and + "local-sibling" disable sibling glue + checks but are otherwise the same as "full" + and "local" respectively. +

+

+ Mode "none" disables the checks. +

+
+
-f format
+

+ Specify the format of the zone file. + Possible formats are "text" (default) + and "raw". +

+
-F format
+

+ Specify the format of the output file specified. + Possible formats are "text" (default) + and "raw". + For named-checkzone, + this does not cause any effects unless it dumps the zone + contents. +

+
-k mode
+

+ Perform "check-names" checks with the + specified failure mode. + Possible modes are "fail" + (default for named-compilezone), + "warn" + (default for named-checkzone) and + "ignore". +

+
-m mode
+

+ Specify whether MX records should be checked to see if they + are addresses. Possible modes are "fail", + "warn" (default) and + "ignore". +

+
-M mode
+

+ Check if a MX record refers to a CNAME. + Possible modes are "fail", + "warn" (default) and + "ignore". +

+
-n mode
+

+ Specify whether NS records should be checked to see if they + are addresses. + Possible modes are "fail" + (default for named-compilezone), + "warn" + (default for named-checkzone) and + "ignore". +

+
-o filename
+

+ Write zone output to filename. + If filename is - then + write to standard out. + This is mandatory for named-compilezone. +

+
-s style
+

+ Specify the style of the dumped zone file. + Possible styles are "full" (default) + and "relative". + The full format is most suitable for processing + automatically by a separate script. + On the other hand, the relative format is more + human-readable and is thus suitable for editing by hand. + For named-checkzone + this does not cause any effects unless it dumps the zone + contents. + It also does not have any meaning if the output format + is not text. +

+
-S mode
+

+ Check if a SRV record refers to a CNAME. + Possible modes are "fail", + "warn" (default) and + "ignore". +

+
-t directory
+

+ Chroot to directory so that + include + directives in the configuration file are processed as if + run by a similarly chrooted named. +

+
-w directory
+

+ chdir to directory so that + relative + filenames in master file $INCLUDE directives work. This + is similar to the directory clause in + named.conf. +

+
-D
+

+ Dump zone file in canonical format. + This is always enabled for named-compilezone. +

+
-W mode
+

+ Specify whether to check for non-terminal wildcards. + Non-terminal wildcards are almost always the result of a + failure to understand the wildcard matching algorithm (RFC 1034). + Possible modes are "warn" (default) + and + "ignore". +

+
zonename
+

+ The domain name of the zone being checked. +

+
filename
+

+ The name of the zone file. +

+
+
+
+

RETURN VALUES

+

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

+
+
+

SEE ALSO

+

named(8), + named-checkconf(8), + RFC 1035, + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+named-checkconf Home named +
+
+ + diff --git a/doc/arm/man.named.html b/doc/arm/man.named.html new file mode 100644 index 0000000..f01124d --- /dev/null +++ b/doc/arm/man.named.html @@ -0,0 +1,322 @@ + + + + + +named + + + + + + + +
+ + + + + + + +
named
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

named — Internet domain name server

+
+
+

Synopsis

+

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] [-V] [-x cache-file]

+
+
+

DESCRIPTION

+

named + is a Domain Name System (DNS) server, + part of the BIND 9 distribution from ISC. For more + information on the DNS, see RFCs 1033, 1034, and 1035. +

+

+ When invoked without arguments, named + will + read the default configuration file + /etc/named.conf, read any initial + data, and listen for queries. +

+
+
+

OPTIONS

+
+
-4
+

+ Use IPv4 only even if the host machine is capable of IPv6. + -4 and -6 are mutually + exclusive. +

+
-6
+

+ Use IPv6 only even if the host machine is capable of IPv4. + -4 and -6 are mutually + exclusive. +

+
-c config-file
+

+ Use config-file as the + configuration file instead of the default, + /etc/named.conf. To + ensure that reloading the configuration file continues + to work after the server has changed its working + directory due to to a possible + directory option in the configuration + file, config-file should be + an absolute pathname. +

+
-d debug-level
+

+ Set the daemon's debug level to debug-level. + Debugging traces from named become + more verbose as the debug level increases. +

+
-f
+

+ Run the server in the foreground (i.e. do not daemonize). +

+
-g
+

+ Run the server in the foreground and force all logging + to stderr. +

+
-m flag
+

+ Turn on memory usage debugging flags. Possible flags are + usage, + trace, + record, + size, and + mctx. + These correspond to the ISC_MEM_DEBUGXXXX flags described in + <isc/mem.h>. +

+
-n #cpus
+

+ Create #cpus worker threads + to take advantage of multiple CPUs. If not specified, + named will try to determine the + number of CPUs present and create one thread per CPU. + If it is unable to determine the number of CPUs, a + single worker thread will be created. +

+
-p port
+

+ Listen for queries on port port. If not + specified, the default is port 53. +

+
-s
+
+

+ Write memory usage statistics to stdout on exit. +

+
+

Note

+

+ This option is mainly of interest to BIND 9 developers + and may be removed or changed in a future release. +

+
+
+
-S #max-socks
+
+

+ Allow named to use up to + #max-socks sockets. +

+
+

Warning

+

+ This option should be unnecessary for the vast majority + of users. + The use of this option could even be harmful because the + specified value may exceed the limitation of the + underlying system API. + It is therefore set only when the default configuration + causes exhaustion of file descriptors and the + operational environment is known to support the + specified number of sockets. + Note also that the actual maximum number is normally a little + fewer than the specified value because + named reserves some file descriptors + for its internal use. +

+
+
+
-t directory
+
+

Chroot + to directory after + processing the command line arguments, but before + reading the configuration file. +

+
+

Warning

+

+ This option should be used in conjunction with the + -u option, as chrooting a process + running as root doesn't enhance security on most + systems; the way chroot(2) is + defined allows a process with root privileges to + escape a chroot jail. +

+
+
+
-u user
+
+

Setuid + to user after completing + privileged operations, such as creating sockets that + listen on privileged ports. +

+
+

Note

+

+ On Linux, named uses the kernel's + capability mechanism to drop all root privileges + except the ability to bind(2) to + a + privileged port and set process resource limits. + Unfortunately, this means that the -u + option only works when named is + run + on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or + later, since previous kernels did not allow privileges + to be retained after setuid(2). +

+
+
+
-v
+

+ Report the version number and exit. +

+
-V
+

+ Report the version number and build options, and exit. +

+
-x cache-file
+
+

+ Load data from cache-file into the + cache of the default view. +

+
+

Warning

+

+ This option must not be used. It is only of interest + to BIND 9 developers and may be removed or changed in a + future release. +

+
+
+
+
+
+

SIGNALS

+

+ In routine operation, signals should not be used to control + the nameserver; rndc should be used + instead. +

+
+
SIGHUP
+

+ Force a reload of the server. +

+
SIGINT, SIGTERM
+

+ Shut down the server. +

+
+

+ The result of sending any other signals to the server is undefined. +

+
+
+

CONFIGURATION

+

+ The named configuration file is too complex + to describe in detail here. A complete description is provided + in the + BIND 9 Administrator Reference Manual. +

+
+
+

FILES

+
+
/etc/named.conf
+

+ The default configuration file. +

+
/var/run/named/named.pid
+

+ The default process-id file. +

+
+
+
+

SEE ALSO

+

RFC 1033, + RFC 1034, + RFC 1035, + named-checkconf(8), + named-checkzone(8), + rndc(8), + lwresd(8), + named.conf(5), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+named-checkzone Home nsupdate +
+
+ + diff --git a/doc/arm/man.nsupdate.html b/doc/arm/man.nsupdate.html new file mode 100644 index 0000000..40ab5a0 --- /dev/null +++ b/doc/arm/man.nsupdate.html @@ -0,0 +1,568 @@ + + + + + +nsupdate + + + + + + + +
+ + + + + + + +
nsupdate
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

nsupdate — Dynamic DNS update utility

+
+
+

Synopsis

+

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

+
+
+

DESCRIPTION

+

nsupdate + is used to submit Dynamic DNS Update requests as defined in RFC2136 + to a name server. + This allows resource records to be added or removed from a zone + without manually editing the zone file. + A single update request can contain requests to add or remove more than + one + resource record. +

+

+ Zones that are under dynamic control via + nsupdate + or a DHCP server should not be edited by hand. + Manual edits could + conflict with dynamic updates and cause data to be lost. +

+

+ The resource records that are dynamically added or removed with + nsupdate + have to be in the same zone. + Requests are sent to the zone's master server. + This is identified by the MNAME field of the zone's SOA record. +

+

+ The + -d + option makes + nsupdate + operate in debug mode. + This provides tracing information about the update requests that are + made and the replies received from the name server. +

+

+ The -D option makes nsupdate + report additional debugging information to -d. +

+

+ Transaction signatures can be used to authenticate the Dynamic DNS + updates. + These use the TSIG resource record type described in RFC2845 or the + SIG(0) record described in RFC3535 and RFC2931. + TSIG relies on a shared secret that should only be known to + nsupdate and the name server. + Currently, the only supported encryption algorithm for TSIG is + HMAC-MD5, which is defined in RFC 2104. + Once other algorithms are defined for TSIG, applications will need to + ensure they select the appropriate algorithm as well as the key when + authenticating each other. + For instance, suitable + key + and + server + statements would be added to + /etc/named.conf + so that the name server can associate the appropriate secret key + and algorithm with the IP address of the + client application that will be using TSIG authentication. + SIG(0) uses public key cryptography. To use a SIG(0) key, the public + key must be stored in a KEY record in a zone served by the name server. + nsupdate + does not read + /etc/named.conf. +

+

nsupdate + uses the -y or -k option + to provide the shared secret needed to generate a TSIG record + for authenticating Dynamic DNS update requests, default type + HMAC-MD5. These options are mutually exclusive. With the + -k option, nsupdate reads + the shared secret from the file keyfile, + whose name is of the form + K{name}.+157.+{random}.private. For + historical reasons, the file + K{name}.+157.+{random}.key must also be + present. When the -y option is used, a + signature is generated from + [hmac:]keyname:secret. + keyname is the name of the key, and + secret is the base64 encoded shared + secret. Use of the -y option is discouraged + because the shared secret is supplied as a command line + argument in clear text. This may be visible in the output + from + ps(1) or in a history file maintained by the user's + shell. +

+

+ The -k 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. +

+

+ 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. + The + -v + option makes + nsupdate + use a TCP connection. + This may be preferable when a batch of update requests is made. +

+

+ The -t option sets the maximum time an update request + can + take before it is aborted. The default is 300 seconds. Zero can be + used + to disable the timeout. +

+

+ The -u option sets the UDP retry interval. The default + is + 3 seconds. If zero, the interval will be computed from the timeout + interval + and number of UDP retries. +

+

+ The -r option sets the number of UDP retries. The + default is + 3. If zero, only one update request will be made. +

+

+ The -R randomdev option + specifies a source of randomness. If the operating system + does not provide a /dev/random or + equivalent device, the default source of randomness is keyboard + input. randomdev specifies the name of + a character device or file containing random data to be used + instead of the default. The special value + keyboard indicates that keyboard input + should be used. This option may be specified multiple times. +

+
+
+

INPUT FORMAT

+

nsupdate + reads input from + filename + or standard input. + Each command is supplied on exactly one line of input. + Some commands are for administrative purposes. + The others are either update instructions or prerequisite checks on the + contents of the zone. + These checks set conditions that some name or set of + resource records (RRset) either exists or is absent from the zone. + These conditions must be met if the entire update request is to succeed. + Updates will be rejected if the tests for the prerequisite conditions + fail. +

+

+ Every update request consists of zero or more prerequisites + and zero or more updates. + This allows a suitably authenticated update request to proceed if some + specified resource records are present or missing from the zone. + A blank input line (or the send command) + causes the + accumulated commands to be sent as one Dynamic DNS update request to the + name server. +

+

+ The command formats and their meaning are as follows: +

+
+
+ server + {servername} + [port] +
+

+ Sends all dynamic update requests to the name server + servername. + When no server statement is provided, + nsupdate + will send updates to the master server of the correct zone. + The MNAME field of that zone's SOA record will identify the + master + server for that zone. + port + is the port number on + servername + where the dynamic update requests get sent. + If no port number is specified, the default DNS port number of + 53 is + used. +

+
+ local + {address} + [port] +
+

+ Sends all dynamic update requests using the local + address. + + When no local statement is provided, + nsupdate + will send updates using an address and port chosen by the + system. + port + can additionally be used to make requests come from a specific + port. + If no port number is specified, the system will assign one. +

+
+ zone + {zonename} +
+

+ Specifies that all updates are to be made to the zone + zonename. + If no + zone + statement is provided, + nsupdate + will attempt determine the correct zone to update based on the + rest of the input. +

+
+ class + {classname} +
+

+ Specify the default class. + If no class is specified, the + default class is + IN. +

+
+ ttl + {seconds} +
+

+ Specify the default time to live for records to be added. + The value none will clear the default + ttl. +

+
+ key + {name} + {secret} +
+

+ Specifies that all updates are to be TSIG-signed using the + keyname keysecret pair. + The key command + overrides any key specified on the command line via + -y or -k. +

+
+ prereq nxdomain + {domain-name} +
+

+ Requires that no resource record of any type exists with name + domain-name. +

+
+ prereq yxdomain + {domain-name} +
+

+ Requires that + domain-name + exists (has as at least one resource record, of any type). +

+
+ prereq nxrrset + {domain-name} + [class] + {type} +
+

+ Requires that no resource record exists of the specified + type, + class + and + domain-name. + If + class + is omitted, IN (internet) is assumed. +

+
+ prereq yxrrset + {domain-name} + [class] + {type} +
+

+ This requires that a resource record of the specified + type, + class + and + domain-name + must exist. + If + class + is omitted, IN (internet) is assumed. +

+
+ prereq yxrrset + {domain-name} + [class] + {type} + {data...} +
+

+ The + data + from each set of prerequisites of this form + sharing a common + type, + class, + and + domain-name + are combined to form a set of RRs. This set of RRs must + exactly match the set of RRs existing in the zone at the + given + type, + class, + and + domain-name. + The + data + are written in the standard text representation of the resource + record's + RDATA. +

+
+ update delete + {domain-name} + [ttl] + [class] + [type [data...]] +
+

+ Deletes any resource records named + domain-name. + If + type + and + data + is provided, only matching resource records will be removed. + The internet class is assumed if + class + is not supplied. The + ttl + is ignored, and is only allowed for compatibility. +

+
+ update add + {domain-name} + {ttl} + [class] + {type} + {data...} +
+

+ Adds a new resource record with the specified + ttl, + class + and + data. +

+
+ show +
+

+ Displays the current message, containing all of the + prerequisites and + updates specified since the last send. +

+
+ send +
+

+ Sends the current message. This is equivalent to entering a + blank line. +

+
+ answer +
+

+ Displays the answer. +

+
+ debug +
+

+ Turn on debugging. +

+
+

+

+

+ Lines beginning with a semicolon are comments and are ignored. +

+
+
+

EXAMPLES

+

+ The examples below show how + nsupdate + could be used to insert and delete resource records from the + example.com + zone. + Notice that the input in each example contains a trailing blank line so + that + a group of commands are sent as one dynamic update request to the + master name server for + example.com. + +

+
+# nsupdate
+> update delete oldhost.example.com A
+> update add newhost.example.com 86400 A 172.16.1.1
+> send
+
+

+

+

+ Any A records for + oldhost.example.com + are deleted. + And an A record for + newhost.example.com + with IP address 172.16.1.1 is added. + The newly-added record has a 1 day TTL (86400 seconds). +

+
+# nsupdate
+> prereq nxdomain nickname.example.com
+> update add nickname.example.com 86400 CNAME somehost.example.com
+> send
+
+

+

+

+ The prerequisite condition gets the name server to check that there + are no resource records of any type for + nickname.example.com. + + If there are, the update request fails. + If this name does not exist, a CNAME for it is added. + This ensures that when the CNAME is added, it cannot conflict with the + long-standing rule in RFC1034 that a name must not exist as any other + record type if it exists as a CNAME. + (The rule has been updated for DNSSEC in RFC2535 to allow CNAMEs to have + RRSIG, DNSKEY and NSEC records.) +

+
+
+

FILES

+
+
/etc/resolv.conf
+

+ used to identify default name server +

+
K{name}.+157.+{random}.key
+

+ base-64 encoding of HMAC-MD5 key created by + dnssec-keygen(8). +

+
K{name}.+157.+{random}.private
+

+ base-64 encoding of HMAC-MD5 key created by + dnssec-keygen(8). +

+
+
+
+

SEE ALSO

+

RFC2136, + RFC3007, + RFC2104, + RFC2845, + RFC1034, + RFC2535, + RFC2931, + named(8), + dnssec-keygen(8). +

+
+
+

BUGS

+

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

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+named Home rndc +
+
+ + diff --git a/doc/arm/man.rndc-confgen.html b/doc/arm/man.rndc-confgen.html new file mode 100644 index 0000000..5768d6b --- /dev/null +++ b/doc/arm/man.rndc-confgen.html @@ -0,0 +1,222 @@ + + + + + +rndc-confgen + + + + + + +
+ + + + + + + +
rndc-confgen
+Prev Manual pages 
+
+
+
+
+
+

Name

+

rndc-confgen — rndc key generation tool

+
+
+

Synopsis

+

rndc-confgen [-a] [-b keysize] [-c keyfile] [-h] [-k keyname] [-p port] [-r randomfile] [-s address] [-t chrootdir] [-u user]

+
+
+

DESCRIPTION

+

rndc-confgen + generates configuration files + for rndc. It can be used as a + convenient alternative to writing the + rndc.conf file + and the corresponding controls + and key + statements in named.conf by hand. + Alternatively, it can be run with the -a + option to set up a rndc.key file and + avoid the need for a rndc.conf file + and a controls statement altogether. +

+
+
+

OPTIONS

+
+
-a
+
+

+ Do automatic rndc configuration. + This creates a file rndc.key + in /etc (or whatever + sysconfdir + was specified as when BIND was + built) + that is read by both rndc + and named on startup. The + rndc.key file defines a default + command channel and authentication key allowing + rndc to communicate with + named on the local host + with no further configuration. +

+

+ Running rndc-confgen -a allows + BIND 9 and rndc to be used as + drop-in + replacements for BIND 8 and ndc, + with no changes to the existing BIND 8 + named.conf file. +

+

+ If a more elaborate configuration than that + generated by rndc-confgen -a + is required, for example if rndc is to be used remotely, + you should run rndc-confgen without + the + -a option and set up a + rndc.conf and + named.conf + as directed. +

+
+
-b keysize
+

+ Specifies the size of the authentication key in bits. + Must be between 1 and 512 bits; the default is 128. +

+
-c keyfile
+

+ Used with the -a option to specify + an alternate location for rndc.key. +

+
-h
+

+ Prints a short summary of the options and arguments to + rndc-confgen. +

+
-k keyname
+

+ Specifies the key name of the rndc authentication key. + This must be a valid domain name. + The default is rndc-key. +

+
-p port
+

+ Specifies the command channel port where named + listens for connections from rndc. + The default is 953. +

+
-r randomfile
+

+ Specifies a source of random data for generating the + authorization. If the operating + system does not provide a /dev/random + or equivalent device, the default source of randomness + is keyboard input. randomdev + specifies + the name of a character device or file containing random + data to be used instead of the default. The special value + keyboard indicates that keyboard + input should be used. +

+
-s address
+

+ Specifies the IP address where named + listens for command channel connections from + rndc. The default is the loopback + address 127.0.0.1. +

+
-t chrootdir
+

+ Used with the -a option to specify + a directory where named will run + chrooted. An additional copy of the rndc.key + will be written relative to this directory so that + it will be found by the chrooted named. +

+
-u user
+

+ Used with the -a option to set the + owner + of the rndc.key file generated. + If + -t is also specified only the file + in + the chroot area has its owner changed. +

+
+
+
+

EXAMPLES

+

+ To allow rndc to be used with + no manual configuration, run +

+

rndc-confgen -a +

+

+ To print a sample rndc.conf file and + corresponding controls and key + statements to be manually inserted into named.conf, + run +

+

rndc-confgen +

+
+
+

SEE ALSO

+

rndc(8), + rndc.conf(5), + named(8), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up 
+rndc.conf Home 
+
+ + diff --git a/doc/arm/man.rndc.conf.html b/doc/arm/man.rndc.conf.html new file mode 100644 index 0000000..59f915c --- /dev/null +++ b/doc/arm/man.rndc.conf.html @@ -0,0 +1,255 @@ + + + + + +rndc.conf + + + + + + + +
+ + + + + + + +
rndc.conf
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

rndc.conf — rndc configuration file

+
+
+

Synopsis

+

rndc.conf

+
+
+

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 + named.conf. Statements are enclosed + in braces and terminated with a semi-colon. Clauses in + the statements are also semi-colon terminated. The usual + comment styles are supported: +

+

+ C style: /* */ +

+

+ C++ style: // to end of line +

+

+ Unix style: # to end of line +

+

rndc.conf is much simpler than + named.conf. The file uses three + statements: an options statement, a server statement + and a key statement. +

+

+ The options statement contains five clauses. + The default-server clause is followed by the + name or address of a name server. This host will be used when + no name server is given as an argument to + rndc. The default-key + clause is followed by the name of a key which is identified by + a key statement. If no + keyid is provided on the rndc command line, + and no key clause is found in a matching + server statement, this default key will be + used to authenticate the server's commands and responses. The + default-port clause is followed by the port + to connect to on the remote name server. If no + port option is provided on the rndc command + line, and no port clause is found in a + matching server statement, this default port + will be used to connect. + The default-source-address and + default-source-address-v6 clauses which + can be used to set the IPv4 and IPv6 source addresses + respectively. +

+

+ After the server keyword, the server + statement includes a string which is the hostname or address + for a name server. The statement has three possible clauses: + key, port and + addresses. The key name must match the + name of a key statement in the file. The port number + specifies the port to connect to. If an addresses + clause is supplied these addresses will be used instead of + the server name. Each address can take an optional port. + If an source-address or source-address-v6 + of supplied then these will be used to specify the IPv4 and IPv6 + source addresses respectively. +

+

+ The key statement begins with an identifying + string, the name of the key. The statement has two clauses. + algorithm identifies the encryption algorithm + for rndc to use; currently only HMAC-MD5 + is + supported. This is followed by a secret clause which contains + the base-64 encoding of the algorithm's encryption key. The + base-64 string is enclosed in double quotes. +

+

+ There are two common ways to generate the base-64 string for the + secret. The BIND 9 program rndc-confgen + can + be used to generate a random key, or the + mmencode program, also known as + mimencode, can be used to generate a + base-64 + string from known input. mmencode does + not + ship with BIND 9 but is available on many systems. See the + EXAMPLE section for sample command lines for each. +

+
+
+

EXAMPLE

+
+      options {
+        default-server  localhost;
+        default-key     samplekey;
+      };
+
+

+

+
+      server localhost {
+        key             samplekey;
+      };
+
+

+

+
+      server testserver {
+        key		testkey;
+        addresses	{ localhost port 5353; };
+      };
+
+

+

+
+      key samplekey {
+        algorithm       hmac-md5;
+        secret          "6FMfj43Osz4lyb24OIe2iGEz9lf1llJO+lz";
+      };
+
+

+

+
+      key testkey {
+        algorithm	hmac-md5;
+        secret		"R3HI8P6BKw9ZwXwN3VZKuQ==";
+      };
+
+

+

+

+ In the above example, rndc will by + default use + the server at localhost (127.0.0.1) and the key called samplekey. + Commands to the localhost server will use the samplekey key, which + must also be defined in the server's configuration file with the + same name and secret. The key statement indicates that samplekey + uses the HMAC-MD5 algorithm and its secret clause contains the + base-64 encoding of the HMAC-MD5 secret enclosed in double quotes. +

+

+ If rndc -s testserver is used then rndc will + connect to server on localhost port 5353 using the key testkey. +

+

+ To generate a random secret with rndc-confgen: +

+

rndc-confgen +

+

+ A complete rndc.conf file, including + the + randomly generated key, will be written to the standard + output. Commented-out key and + controls statements for + named.conf are also printed. +

+

+ To generate a base-64 secret with mmencode: +

+

echo "known plaintext for a secret" | mmencode +

+
+
+

NAME SERVER CONFIGURATION

+

+ The name server must be configured to accept rndc connections and + to recognize the key specified in the rndc.conf + file, using the controls statement in named.conf. + See the sections on the controls statement in the + BIND 9 Administrator Reference Manual for details. +

+
+
+

SEE ALSO

+

rndc(8), + rndc-confgen(8), + mmencode(1), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+rndc Home rndc-confgen +
+
+ + diff --git a/doc/arm/man.rndc.html b/doc/arm/man.rndc.html new file mode 100644 index 0000000..1c49af4 --- /dev/null +++ b/doc/arm/man.rndc.html @@ -0,0 +1,203 @@ + + + + + +rndc + + + + + + + +
+ + + + + + + +
rndc
+Prev Manual pages Next +
+
+
+
+
+
+

Name

+

rndc — name server control utility

+
+
+

Synopsis

+

rndc [-b source-address] [-c config-file] [-k key-file] [-s server] [-p port] [-V] [-y key_id] {command}

+
+
+

DESCRIPTION

+

rndc + controls the operation of a name + server. It supersedes the ndc utility + that was provided in old BIND releases. If + rndc is invoked with no command line + options or arguments, it prints a short summary of the + supported commands and the available options and their + arguments. +

+

rndc + communicates with the name server + over a TCP connection, sending commands authenticated with + digital signatures. In the current versions of + rndc and named, + the only supported authentication algorithm is HMAC-MD5, + which uses a shared secret on each end of the connection. + This provides TSIG-style authentication for the command + request and the name server's response. All commands sent + over the channel must be signed by a key_id known to the + server. +

+

rndc + reads a configuration file to + determine how to contact the name server and decide what + algorithm and key it should use. +

+
+
+

OPTIONS

+
+
-b source-address
+

+ Use source-address + as the source address for the connection to the server. + Multiple instances are permitted to allow setting of both + the IPv4 and IPv6 source addresses. +

+
-c config-file
+

+ Use config-file + as the configuration file instead of the default, + /etc/rndc.conf. +

+
-k key-file
+

+ Use key-file + as the key file instead of the default, + /etc/rndc.key. The key in + /etc/rndc.key will be used to + authenticate + commands sent to the server if the config-file + does not exist. +

+
-s server
+

server is + the name or address of the server which matches a + server statement in the configuration file for + rndc. If no server is supplied on the + command line, the host named by the default-server clause + in the options statement of the rndc + configuration file will be used. +

+
-p port
+

+ Send commands to TCP port + port + instead + of BIND 9's default control channel port, 953. +

+
-V
+

+ Enable verbose logging. +

+
-y key_id
+

+ Use the key key_id + from the configuration file. + key_id + must be + known by named with the same algorithm and secret string + in order for control message validation to succeed. + If no key_id + is specified, rndc will first look + for a key clause in the server statement of the server + being used, or if no server statement is present for that + host, then the default-key clause of the options statement. + Note that the configuration file contains shared secrets + which are used to send authenticated control commands + to name servers. It should therefore not have general read + or write access. +

+
+

+ For the complete set of commands supported by rndc, + see the BIND 9 Administrator Reference Manual or run + rndc without arguments to see its help + message. +

+
+
+

LIMITATIONS

+

rndc + does not yet support all the commands of + the BIND 8 ndc utility. +

+

+ There is currently no way to provide the shared secret for a + key_id without using the configuration file. +

+

+ Several error messages could be clearer. +

+
+
+

SEE ALSO

+

rndc.conf(5), + rndc-confgen(8), + named(8), + named.conf(5), + ndc(8), + BIND 9 Administrator Reference Manual. +

+
+
+

AUTHOR

+

Internet Systems Consortium +

+
+
+
+
+ + + + + + + + + + + +
+Prev Up Next +
+nsupdate Home rndc.conf +
+
+ + diff --git a/doc/doxygen/Doxyfile.in b/doc/doxygen/Doxyfile.in new file mode 100644 index 0000000..620e3b0 --- /dev/null +++ b/doc/doxygen/Doxyfile.in @@ -0,0 +1,1269 @@ +# $Id: Doxyfile.in,v 1.2 2006/12/22 01:44:59 marka Exp $ + +# Doxyfile 1.4.7 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project +# +# All text after a hash (#) is considered a comment and will be ignored +# The format is: +# TAG = value [value, ...] +# For lists items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (" ") + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# The PROJECT_NAME tag is a single word (or a sequence of words surrounded +# by quotes) that should identify the project. + +PROJECT_NAME = "BIND9 Internals" + +# The PROJECT_NUMBER tag can be used to enter a project or revision number. +# This could be handy for archiving the generated documentation or +# if some version control system is used. + +PROJECT_NUMBER = $(BIND9_VERSION) + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) +# base path where the generated documentation will be put. +# If a relative path is entered, it will be relative to the location +# where doxygen was started. If left blank the current directory will be used. + +OUTPUT_DIRECTORY = + +# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create +# 4096 sub-directories (in 2 levels) under the output directory of each output +# format and will distribute the generated files over these directories. +# Enabling this option can be useful when feeding doxygen a huge amount of +# source files, where putting all generated files in the same directory would +# otherwise cause performance problems for the file system. + +CREATE_SUBDIRS = NO + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# The default language is English, other supported languages are: +# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, +# Dutch, Finnish, French, German, Greek, Hungarian, Italian, Japanese, +# Japanese-en (Japanese with English messages), Korean, Korean-en, Norwegian, +# Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish, +# Swedish, and Ukrainian. + +OUTPUT_LANGUAGE = English + +# This tag can be used to specify the encoding used in the generated output. +# The encoding is not always determined by the language that is chosen, +# but also whether or not the output is meant for Windows or non-Windows users. +# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES +# forces the Windows encoding (this is the default for the Windows binary), +# whereas setting the tag to NO uses a Unix-style encoding (the default for +# all platforms other than Windows). + +USE_WINDOWS_ENCODING = NO + +# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will +# include brief member descriptions after the members that are listed in +# the file and class documentation (similar to JavaDoc). +# Set to NO to disable this. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend +# the brief description of a member or function before the detailed description. +# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator +# that is used to form the text in various listings. Each string +# in this list, if found as the leading text of the brief description, will be +# stripped from the text and the result after processing the whole list, is +# used as the annotated text. Otherwise, the brief description is used as-is. +# If left blank, the following values are used ("$name" is automatically +# replaced with the name of the entity): "The $name class" "The $name widget" +# "The $name file" "is" "provides" "specifies" "contains" +# "represents" "a" "an" "the" + +ABBREVIATE_BRIEF = + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# Doxygen will generate a detailed section even if there is only a brief +# description. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all +# inherited members of a class in the documentation of that class as if those +# members were ordinary class members. Constructors, destructors and assignment +# operators of the base classes will not be shown. + +INLINE_INHERITED_MEMB = NO + +# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full +# path before files name in the file list and in the header files. If set +# to NO the shortest path that makes the file name unique will be used. + +FULL_PATH_NAMES = YES + +# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag +# can be used to strip a user-defined part of the path. Stripping is +# only done if one of the specified strings matches the left-hand part of +# the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the +# path to strip. + +STRIP_FROM_PATH = @BIND9_TOP_BUILDDIR@/ + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of +# the path mentioned in the documentation of a class, which tells +# the reader which header file to include in order to use a class. +# If left blank only the name of the header file containing the class +# definition is used. Otherwise one should specify the include paths that +# are normally passed to the compiler using the -I flag. + +STRIP_FROM_INC_PATH = + +# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter +# (but less readable) file names. This can be useful is your file systems +# doesn't support long names like on DOS, Mac, or CD-ROM. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen +# will interpret the first line (until the first dot) of a JavaDoc-style +# comment as the brief description. If set to NO, the JavaDoc +# comments will behave just like the Qt-style comments (thus requiring an +# explicit @brief command for a brief description. + +JAVADOC_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen +# treat a multi-line C++ special comment block (i.e. a block of //! or /// +# comments) as a brief description. This used to be the default behaviour. +# The new default is to treat a multi-line C++ comment block as a detailed +# description. Set this tag to YES if you prefer the old behaviour instead. + +MULTILINE_CPP_IS_BRIEF = NO + +# If the DETAILS_AT_TOP tag is set to YES then Doxygen +# will output the detailed description near the top, like JavaDoc. +# If set to NO, the detailed description appears after the member +# documentation. + +DETAILS_AT_TOP = NO + +# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented +# member inherits the documentation from any documented member that it +# re-implements. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce +# a new page for each member. If set to NO, the documentation of a member will +# be part of the file/class/namespace that contains it. + +SEPARATE_MEMBER_PAGES = NO + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. +# Doxygen uses this value to replace tabs by spaces in code fragments. + +TAB_SIZE = 8 + +# This tag can be used to specify a number of aliases that acts +# as commands in the documentation. An alias has the form "name=value". +# For example adding "sideeffect=\par Side Effects:\n" will allow you to +# put the command \sideeffect (or @sideeffect) in the documentation, which +# will result in a user-defined paragraph with heading "Side Effects:". +# You can put \n's in the value part of an alias to insert newlines. + +ALIASES = + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C +# sources only. Doxygen will then generate output that is more tailored for C. +# For instance, some of the names that are used will be different. The list +# of all members will be omitted, etc. + +OPTIMIZE_OUTPUT_FOR_C = YES + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java +# sources only. Doxygen will then generate output that is more tailored for Java. +# For instance, namespaces will be presented as packages, qualified scopes +# will look different, etc. + +OPTIMIZE_OUTPUT_JAVA = NO + +# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to +# include (a tag file for) the STL sources as input, then you should +# set this tag to YES in order to let doxygen match functions declarations and +# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. +# func(std::string) {}). This also make the inheritance and collaboration +# diagrams that involve STL classes more complete and accurate. + +BUILTIN_STL_SUPPORT = NO + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES, then doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. + +DISTRIBUTE_GROUP_DOC = YES + +# Set the SUBGROUPING tag to YES (the default) to allow class member groups of +# the same type (for instance a group of public functions) to be put as a +# subgroup of that type (e.g. under the Public Functions section). Set it to +# NO to prevent subgrouping. Alternatively, this can be done per class using +# the \nosubgrouping command. + +SUBGROUPING = YES + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in +# documentation are documented, even if no documentation was available. +# Private class members and static file members will be hidden unless +# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES + +EXTRACT_ALL = YES + +# If the EXTRACT_PRIVATE tag is set to YES all private members of a class +# will be included in the documentation. + +EXTRACT_PRIVATE = YES + +# If the EXTRACT_STATIC tag is set to YES all static members of a file +# will be included in the documentation. + +EXTRACT_STATIC = YES + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) +# defined locally in source files will be included in the documentation. +# If set to NO only classes defined in header files are included. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. When set to YES local +# methods, which are defined in the implementation section but not in +# the interface are included in the documentation. +# If set to NO (the default) only methods in the interface are included. + +EXTRACT_LOCAL_METHODS = YES + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all +# undocumented members of documented classes, files or namespaces. +# If set to NO (the default) these members will be included in the +# various overviews, but no documentation section is generated. +# This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. +# If set to NO (the default) these classes will be included in the various +# overviews. This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all +# friend (class|struct|union) declarations. +# If set to NO (the default) these declarations will be included in the +# documentation. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any +# documentation blocks found inside the body of a function. +# If set to NO (the default) these blocks will be appended to the +# function's detailed documentation block. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation +# that is typed after a \internal command is included. If the tag is set +# to NO (the default) then the documentation will be excluded. +# Set it to YES to include the internal documentation. + +INTERNAL_DOCS = NO + +# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate +# file names in lower-case letters. If set to YES upper-case letters are also +# allowed. This is useful if you have classes or files whose names only differ +# in case and if your file system supports case sensitive file names. Windows +# and Mac users are advised to set this option to NO. + +CASE_SENSE_NAMES = YES + +# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen +# will show members with their full class and namespace scopes in the +# documentation. If set to YES the scope will be hidden. + +HIDE_SCOPE_NAMES = NO + +# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen +# will put a list of the files that are included by a file in the documentation +# of that file. + +SHOW_INCLUDE_FILES = YES + +# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] +# is inserted in the documentation for inline members. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen +# will sort the (detailed) documentation of file and class members +# alphabetically by member name. If set to NO the members will appear in +# declaration order. + +SORT_MEMBER_DOCS = NO + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the +# brief documentation of file, namespace and class members alphabetically +# by member name. If set to NO (the default) the members will appear in +# declaration order. + +SORT_BRIEF_DOCS = NO + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be +# sorted by fully-qualified names, including namespaces. If set to +# NO (the default), the class list will be sorted only by class name, +# not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the +# alphabetical list. + +SORT_BY_SCOPE_NAME = NO + +# The GENERATE_TODOLIST tag can be used to enable (YES) or +# disable (NO) the todo list. This list is created by putting \todo +# commands in the documentation. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or +# disable (NO) the test list. This list is created by putting \test +# commands in the documentation. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or +# disable (NO) the bug list. This list is created by putting \bug +# commands in the documentation. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or +# disable (NO) the deprecated list. This list is created by putting +# \deprecated commands in the documentation. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional +# documentation sections, marked by \if sectionname ... \endif. + +ENABLED_SECTIONS = + +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines +# the initial value of a variable or define consists of for it to appear in +# the documentation. If the initializer consists of more lines than specified +# here it will be hidden. Use a value of 0 to hide initializers completely. +# The appearance of the initializer of individual variables and defines in the +# documentation can be controlled using \showinitializer or \hideinitializer +# command in the documentation regardless of this setting. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated +# at the bottom of the documentation of classes and structs. If set to YES the +# list will mention the files that were used to generate the documentation. + +SHOW_USED_FILES = YES + +# If the sources in your project are distributed over multiple directories +# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy +# in the documentation. The default is NO. + +SHOW_DIRECTORIES = YES + +# The FILE_VERSION_FILTER tag can be used to specify a program or script that +# doxygen should invoke to get the current version for each file (typically from the +# version control system). Doxygen will invoke the program by executing (via +# popen()) the command , where is the value of +# the FILE_VERSION_FILTER tag, and is the name of an input file +# provided by doxygen. Whatever the program writes to standard output +# is used as the file version. See the manual for examples. + +FILE_VERSION_FILTER = + +#--------------------------------------------------------------------------- +# configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated +# by doxygen. Possible values are YES and NO. If left blank NO is used. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated by doxygen. Possible values are YES and NO. If left blank +# NO is used. + +WARNINGS = YES + +# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings +# for undocumented members. If EXTRACT_ALL is set to YES then this flag will +# automatically be disabled. + +WARN_IF_UNDOCUMENTED = YES + +# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as not documenting some +# parameters in a documented function, or documenting parameters that +# don't exist or using markup commands wrongly. + +WARN_IF_DOC_ERROR = YES + +# This WARN_NO_PARAMDOC option can be abled to get warnings for +# functions that are documented, but have no documentation for their parameters +# or return value. If set to NO (the default) doxygen will only warn about +# wrong or incomplete parameter documentation, but not about the absence of +# documentation. + +WARN_NO_PARAMDOC = YES + +# The WARN_FORMAT tag determines the format of the warning messages that +# doxygen can produce. The string should contain the $file, $line, and $text +# tags, which will be replaced by the file and line number from which the +# warning originated and the warning text. Optionally the format may contain +# $version, which will be replaced by the version of the file (if it could +# be obtained via FILE_VERSION_FILTER) + +WARN_FORMAT = "$file:$line: $text" + +# The WARN_LOGFILE tag can be used to specify a file to which warning +# and error messages should be written. If left blank the output is written +# to stderr. + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag can be used to specify the files and/or directories that contain +# documented source files. You may enter file names like "myfile.cpp" or +# directories like "/usr/src/myproject". Separate the files or directories +# with spaces. + +INPUT = @BIND9_TOP_BUILDDIR@/lib/isc \ + @BIND9_TOP_BUILDDIR@/lib/dns \ + @BIND9_TOP_BUILDDIR@/lib/isccfg \ + @BIND9_TOP_BUILDDIR@/lib/isccc \ + @BIND9_TOP_BUILDDIR@/lib/bind9 \ + @BIND9_TOP_BUILDDIR@/bin/check \ + @BIND9_TOP_BUILDDIR@/bin/dig \ + @BIND9_TOP_BUILDDIR@/bin/dnssec \ + @BIND9_TOP_BUILDDIR@/bin/named \ + @BIND9_TOP_BUILDDIR@/bin/nsupdate \ + @BIND9_TOP_BUILDDIR@/bin/rndc \ + @BIND9_TOP_BUILDDIR@/doc/doxygen/mainpage + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank the following patterns are tested: +# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx +# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py + +FILE_PATTERNS = *.c *.h *.dox + +# The RECURSIVE tag can be used to turn specify whether or not subdirectories +# should be searched for input files as well. Possible values are YES and NO. +# If left blank NO is used. + +RECURSIVE = YES + +# The EXCLUDE tag can be used to specify files and/or directories that should +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. + +EXCLUDE = + +# The EXCLUDE_SYMLINKS tag can be used select whether or not files or +# directories that are symbolic links (a Unix filesystem feature) are excluded +# from the input. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. Note that the wildcards are matched +# against the file with absolute path, so to exclude all test directories +# for example use the pattern */test/* + +EXCLUDE_PATTERNS = */win32/* */lib/dns/gen* */lib/dns/rdata/*.h + +# The EXAMPLE_PATH tag can be used to specify one or more files or +# directories that contain example code fragments that are included (see +# the \include command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank all files are included. + +EXAMPLE_PATTERNS = * + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude +# commands irrespective of the value of the RECURSIVE tag. +# Possible values are YES and NO. If left blank NO is used. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or +# directories that contain image that are included in the documentation (see +# the \image command). + +IMAGE_PATH = + +# The INPUT_FILTER tag can be used to specify a program that doxygen should +# invoke to filter for each input file. Doxygen will invoke the filter program +# by executing (via popen()) the command , where +# is the value of the INPUT_FILTER tag, and is the name of an +# input file. Doxygen will then use the output that the filter program writes +# to standard output. If FILTER_PATTERNS is specified, this tag will be +# ignored. + +INPUT_FILTER = ./doxygen-input-filter + +# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern +# basis. Doxygen will compare the file name with each pattern and apply the +# filter if there is a match. The filters are a list of the form: +# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further +# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER +# is applied to all files. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will be used to filter the input files when producing source +# files to browse (i.e. when SOURCE_BROWSER is set to YES). + +FILTER_SOURCE_FILES = NO + +#--------------------------------------------------------------------------- +# configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will +# be generated. Documented entities will be cross-referenced with these sources. +# Note: To get rid of all source code in the generated output, make sure also +# VERBATIM_HEADERS is set to NO. + +SOURCE_BROWSER = YES + +# Setting the INLINE_SOURCES tag to YES will include the body +# of functions and classes directly in the documentation. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct +# doxygen to hide any special comment blocks from generated source code +# fragments. Normal C and C++ comments will always remain visible. + +STRIP_CODE_COMMENTS = NO + +# If the REFERENCED_BY_RELATION tag is set to YES (the default) +# then for each documented function all documented +# functions referencing it will be listed. + +REFERENCED_BY_RELATION = YES + +# If the REFERENCES_RELATION tag is set to YES (the default) +# then for each documented function all documented entities +# called/used by that function will be listed. + +REFERENCES_RELATION = YES + +# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) +# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from +# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will +# link to the source code. Otherwise they will link to the documentstion. + +REFERENCES_LINK_SOURCE = YES + +# If the USE_HTAGS tag is set to YES then the references to source code +# will point to the HTML generated by the htags(1) tool instead of doxygen +# built-in source browser. The htags tool is part of GNU's global source +# tagging system (see http://www.gnu.org/software/global/global.html). You +# will need version 4.8.6 or higher. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen +# will generate a verbatim copy of the header file for each class for +# which an include is specified. Set to NO to disable this. + +VERBATIM_HEADERS = YES + +#--------------------------------------------------------------------------- +# configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index +# of all compounds will be generated. Enable this if the project +# contains a lot of classes, structs, unions or interfaces. + +ALPHABETICAL_INDEX = YES + +# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then +# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns +# in which this list will be split (can be a number in the range [1..20]) + +COLS_IN_ALPHA_INDEX = 5 + +# In case all classes in a project start with a common prefix, all +# classes will be put under the same header in the alphabetical index. +# The IGNORE_PREFIX tag can be used to specify one or more prefixes that +# should be ignored while generating the index headers. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES (the default) Doxygen will +# generate HTML output. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `html' will be used as the default path. + +HTML_OUTPUT = html + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for +# each generated HTML page (for example: .htm,.php,.asp). If it is left blank +# doxygen will generate files with .html extension. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a personal HTML header for +# each generated HTML page. If it is left blank doxygen will generate a +# standard header. + +HTML_HEADER = isc-header.html + +# The HTML_FOOTER tag can be used to specify a personal HTML footer for +# each generated HTML page. If it is left blank doxygen will generate a +# standard footer. + +HTML_FOOTER = isc-footer.html + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading +# style sheet that is used by each HTML page. It can be used to +# fine-tune the look of the HTML output. If the tag is left blank doxygen +# will generate a default style sheet. Note that doxygen will try to copy +# the style sheet file to the HTML output directory, so don't put your own +# stylesheet in the HTML output directory as well, or it will be erased! + +HTML_STYLESHEET = + +# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, +# files or namespaces will be aligned in HTML using tables. If set to +# NO a bullet list will be used. + +HTML_ALIGN_MEMBERS = YES + +# If the GENERATE_HTMLHELP tag is set to YES, additional index files +# will be generated that can be used as input for tools like the +# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) +# of the generated HTML documentation. + +GENERATE_HTMLHELP = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can +# be used to specify the file name of the resulting .chm file. You +# can add a path in front of the file if the result should not be +# written to the html output directory. + +CHM_FILE = + +# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can +# be used to specify the location (absolute path including file name) of +# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run +# the HTML help compiler on the generated index.hhp. + +HHC_LOCATION = + +# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag +# controls if a separate .chi index file is generated (YES) or that +# it should be included in the master .chm file (NO). + +GENERATE_CHI = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag +# controls whether a binary table of contents is generated (YES) or a +# normal table of contents (NO) in the .chm file. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members +# to the contents of the HTML help documentation and to the tree view. + +TOC_EXPAND = NO + +# The DISABLE_INDEX tag can be used to turn on/off the condensed index at +# top of each HTML page. The value NO (the default) enables the index and +# the value YES disables it. + +DISABLE_INDEX = NO + +# This tag can be used to set the number of enum values (range [1..20]) +# that doxygen will group on one line in the generated HTML documentation. + +ENUM_VALUES_PER_LINE = 4 + +# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be +# generated containing a tree-like index structure (just like the one that +# is generated for HTML Help). For this to work a browser that supports +# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, +# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are +# probably better off using the HTML help feature. + +GENERATE_TREEVIEW = NO + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be +# used to set the initial width (in pixels) of the frame in which the tree +# is shown. + +TREEVIEW_WIDTH = 250 + +#--------------------------------------------------------------------------- +# configuration options related to the LaTeX output +#--------------------------------------------------------------------------- + +# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will +# generate Latex output. + +GENERATE_LATEX = NO + +# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `latex' will be used as the default path. + +LATEX_OUTPUT = latex + +# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be +# invoked. If left blank `latex' will be used as the default command name. + +LATEX_CMD_NAME = latex + +# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to +# generate index for LaTeX. If left blank `makeindex' will be used as the +# default command name. + +MAKEINDEX_CMD_NAME = makeindex + +# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact +# LaTeX documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_LATEX = YES + +# The PAPER_TYPE tag can be used to set the paper type that is used +# by the printer. Possible values are: a4, a4wide, letter, legal and +# executive. If left blank a4wide will be used. + +PAPER_TYPE = letter + +# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX +# packages that should be included in the LaTeX output. + +EXTRA_PACKAGES = + +# The LATEX_HEADER tag can be used to specify a personal LaTeX header for +# the generated latex document. The header should contain everything until +# the first chapter. If it is left blank doxygen will generate a +# standard header. Notice: only use this tag if you know what you are doing! + +LATEX_HEADER = + +# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated +# is prepared for conversion to pdf (using ps2pdf). The pdf file will +# contain links (just like the HTML output) instead of page references +# This makes the output suitable for online browsing using a pdf viewer. + +PDF_HYPERLINKS = NO + +# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of +# plain latex in the generated Makefile. Set this option to YES to get a +# higher quality PDF documentation. + +USE_PDFLATEX = YES + +# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. +# command to the generated LaTeX files. This will instruct LaTeX to keep +# running if errors occur, instead of asking the user for help. +# This option is also used when generating formulas in HTML. + +LATEX_BATCHMODE = YES + +# If LATEX_HIDE_INDICES is set to YES then doxygen will not +# include the index chapters (such as File Index, Compound Index, etc.) +# in the output. + +LATEX_HIDE_INDICES = YES + +#--------------------------------------------------------------------------- +# configuration options related to the RTF output +#--------------------------------------------------------------------------- + +# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output +# The RTF output is optimized for Word 97 and may not look very pretty with +# other RTF readers or editors. + +GENERATE_RTF = NO + +# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `rtf' will be used as the default path. + +RTF_OUTPUT = rtf + +# If the COMPACT_RTF tag is set to YES Doxygen generates more compact +# RTF documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_RTF = NO + +# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated +# will contain hyperlink fields. The RTF file will +# contain links (just like the HTML output) instead of page references. +# This makes the output suitable for online browsing using WORD or other +# programs which support those fields. +# Note: wordpad (write) and others do not support links. + +RTF_HYPERLINKS = NO + +# Load stylesheet definitions from file. Syntax is similar to doxygen's +# config file, i.e. a series of assignments. You only have to provide +# replacements, missing definitions are set to their default value. + +RTF_STYLESHEET_FILE = + +# Set optional variables used in the generation of an rtf document. +# Syntax is similar to doxygen's config file. + +RTF_EXTENSIONS_FILE = + +#--------------------------------------------------------------------------- +# configuration options related to the man page output +#--------------------------------------------------------------------------- + +# If the GENERATE_MAN tag is set to YES (the default) Doxygen will +# generate man pages + +GENERATE_MAN = NO + +# The MAN_OUTPUT tag is used to specify where the man pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `man' will be used as the default path. + +MAN_OUTPUT = man + +# The MAN_EXTENSION tag determines the extension that is added to +# the generated man pages (default is the subroutine's section .3) + +MAN_EXTENSION = .3 + +# If the MAN_LINKS tag is set to YES and Doxygen generates man output, +# then it will generate one additional man file for each entity +# documented in the real man page(s). These additional files +# only source the real man page, but without them the man command +# would be unable to find the correct page. The default is NO. + +MAN_LINKS = NO + +#--------------------------------------------------------------------------- +# configuration options related to the XML output +#--------------------------------------------------------------------------- + +# If the GENERATE_XML tag is set to YES Doxygen will +# generate an XML file that captures the structure of +# the code including all documentation. + +GENERATE_XML = YES + +# The XML_OUTPUT tag is used to specify where the XML pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `xml' will be used as the default path. + +XML_OUTPUT = xml + +# The XML_SCHEMA tag can be used to specify an XML schema, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_SCHEMA = + +# The XML_DTD tag can be used to specify an XML DTD, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_DTD = + +# If the XML_PROGRAMLISTING tag is set to YES Doxygen will +# dump the program listings (including syntax highlighting +# and cross-referencing information) to the XML output. Note that +# enabling this will significantly increase the size of the XML output. + +XML_PROGRAMLISTING = YES + +#--------------------------------------------------------------------------- +# configuration options for the AutoGen Definitions output +#--------------------------------------------------------------------------- + +# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will +# generate an AutoGen Definitions (see autogen.sf.net) file +# that captures the structure of the code including all +# documentation. Note that this feature is still experimental +# and incomplete at the moment. + +GENERATE_AUTOGEN_DEF = NO + +#--------------------------------------------------------------------------- +# configuration options related to the Perl module output +#--------------------------------------------------------------------------- + +# If the GENERATE_PERLMOD tag is set to YES Doxygen will +# generate a Perl module file that captures the structure of +# the code including all documentation. Note that this +# feature is still experimental and incomplete at the +# moment. + +GENERATE_PERLMOD = NO + +# If the PERLMOD_LATEX tag is set to YES Doxygen will generate +# the necessary Makefile rules, Perl scripts and LaTeX code to be able +# to generate PDF and DVI output from the Perl module output. + +PERLMOD_LATEX = NO + +# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be +# nicely formatted so it can be parsed by a human reader. This is useful +# if you want to understand what is going on. On the other hand, if this +# tag is set to NO the size of the Perl module output will be much smaller +# and Perl will parse it just the same. + +PERLMOD_PRETTY = YES + +# The names of the make variables in the generated doxyrules.make file +# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. +# This is useful so different doxyrules.make files included by the same +# Makefile don't overwrite each other's variables. + +PERLMOD_MAKEVAR_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the preprocessor +#--------------------------------------------------------------------------- + +# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will +# evaluate all C-preprocessor directives found in the sources and include +# files. + +ENABLE_PREPROCESSING = YES + +# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro +# names in the source code. If set to NO (the default) only conditional +# compilation will be performed. Macro expansion can be done in a controlled +# way by setting EXPAND_ONLY_PREDEF to YES. + +MACRO_EXPANSION = NO + +# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES +# then the macro expansion is limited to the macros specified with the +# PREDEFINED and EXPAND_AS_DEFINED tags. + +EXPAND_ONLY_PREDEF = NO + +# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files +# in the INCLUDE_PATH (see below) will be search if a #include is found. + +SEARCH_INCLUDES = YES + +# The INCLUDE_PATH tag can be used to specify one or more directories that +# contain include files that are not input files but should be processed by +# the preprocessor. + +INCLUDE_PATH = + +# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard +# patterns (like *.h and *.hpp) to filter out the header-files in the +# directories. If left blank, the patterns specified with FILE_PATTERNS will +# be used. + +INCLUDE_FILE_PATTERNS = + +# The PREDEFINED tag can be used to specify one or more macro names that +# are defined before the preprocessor is started (similar to the -D option of +# gcc). The argument of the tag is a list of macros of the form: name +# or name=definition (no spaces). If the definition and the = are +# omitted =1 is assumed. To prevent a macro definition from being +# undefined via #undef or recursively expanded use the := operator +# instead of the = operator. + +PREDEFINED = + +# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then +# this tag can be used to specify a list of macro names that should be expanded. +# The macro definition that is found in the sources will be used. +# Use the PREDEFINED tag if you want to use a different macro definition. + +EXPAND_AS_DEFINED = + +# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then +# doxygen's preprocessor will remove all function-like macros that are alone +# on a line, have an all uppercase name, and do not end with a semicolon. Such +# function macros are typically used for boiler-plate code, and will confuse +# the parser if not removed. + +SKIP_FUNCTION_MACROS = YES + +#--------------------------------------------------------------------------- +# Configuration::additions related to external references +#--------------------------------------------------------------------------- + +# The TAGFILES option can be used to specify one or more tagfiles. +# Optionally an initial location of the external documentation +# can be added for each tagfile. The format of a tag file without +# this location is as follows: +# TAGFILES = file1 file2 ... +# Adding location for the tag files is done as follows: +# TAGFILES = file1=loc1 "file2 = loc2" ... +# where "loc1" and "loc2" can be relative or absolute paths or +# URLs. If a location is present for each tag, the installdox tool +# does not have to be run to correct the links. +# Note that each tag file must have a unique name +# (where the name does NOT include the path) +# If a tag file is not located in the directory in which doxygen +# is run, you must also specify the path to the tagfile here. + +TAGFILES = + +# When a file name is specified after GENERATE_TAGFILE, doxygen will create +# a tag file that is based on the input files it reads. + +GENERATE_TAGFILE = + +# If the ALLEXTERNALS tag is set to YES all external classes will be listed +# in the class index. If set to NO only the inherited external classes +# will be listed. + +ALLEXTERNALS = NO + +# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed +# in the modules index. If set to NO, only the current project's groups will +# be listed. + +EXTERNAL_GROUPS = YES + +# The PERL_PATH should be the absolute path and name of the perl script +# interpreter (i.e. the result of `which perl'). + +PERL_PATH = @PERL@ + +#--------------------------------------------------------------------------- +# Configuration options related to the dot tool +#--------------------------------------------------------------------------- + +# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will +# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base +# or super classes. Setting the tag to NO turns the diagrams off. Note that +# this option is superseded by the HAVE_DOT option below. This is only a +# fallback. It is recommended to install and use dot, since it yields more +# powerful graphs. + +CLASS_DIAGRAMS = YES + +# If set to YES, the inheritance and collaboration graphs will hide +# inheritance and usage relations if the target is undocumented +# or is not a class. + +HIDE_UNDOC_RELATIONS = YES + +# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is +# available from the path. This tool is part of Graphviz, a graph visualization +# toolkit from AT&T and Lucent Bell Labs. The other options in this section +# have no effect if this option is set to NO (the default) + +HAVE_DOT = NO + +# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect inheritance relations. Setting this tag to YES will force the +# the CLASS_DIAGRAMS tag to NO. + +CLASS_GRAPH = YES + +# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect implementation dependencies (inheritance, containment, and +# class references variables) of the class with other documented classes. + +COLLABORATION_GRAPH = YES + +# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for groups, showing the direct groups dependencies + +GROUP_GRAPHS = YES + +# If the UML_LOOK tag is set to YES doxygen will generate inheritance and +# collaboration diagrams in a style similar to the OMG's Unified Modeling +# Language. + +UML_LOOK = NO + +# If set to YES, the inheritance and collaboration graphs will show the +# relations between templates and their instances. + +TEMPLATE_RELATIONS = NO + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT +# tags are set to YES then doxygen will generate a graph for each documented +# file showing the direct and indirect include dependencies of the file with +# other documented files. + +INCLUDE_GRAPH = YES + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and +# HAVE_DOT tags are set to YES then doxygen will generate a graph for each +# documented header file showing the documented files that directly or +# indirectly include this file. + +INCLUDED_BY_GRAPH = YES + +# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will +# generate a call dependency graph for every global function or class method. +# Note that enabling this option will significantly increase the time of a run. +# So in most cases it will be better to enable call graphs for selected +# functions only using the \callgraph command. + +CALL_GRAPH = NO + +# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then doxygen will +# generate a caller dependency graph for every global function or class method. +# Note that enabling this option will significantly increase the time of a run. +# So in most cases it will be better to enable caller graphs for selected +# functions only using the \callergraph command. + +CALLER_GRAPH = YES + +# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen +# will graphical hierarchy of all classes instead of a textual one. + +GRAPHICAL_HIERARCHY = YES + +# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES +# then doxygen will show the dependencies a directory has on other directories +# in a graphical way. The dependency relations are determined by the #include +# relations between the files in the directories. + +DIRECTORY_GRAPH = YES + +# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images +# generated by dot. Possible values are png, jpg, or gif +# If left blank png will be used. + +DOT_IMAGE_FORMAT = png + +# The tag DOT_PATH can be used to specify the path where the dot tool can be +# found. If left blank, it is assumed the dot tool can be found in the path. + +DOT_PATH = + +# The DOTFILE_DIRS tag can be used to specify one or more directories that +# contain dot files that are included in the documentation (see the +# \dotfile command). + +DOTFILE_DIRS = + +# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width +# (in pixels) of the graphs generated by dot. If a graph becomes larger than +# this value, doxygen will try to truncate the graph, so that it fits within +# the specified constraint. Beware that most browsers cannot cope with very +# large images. + +MAX_DOT_GRAPH_WIDTH = 1024 + +# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height +# (in pixels) of the graphs generated by dot. If a graph becomes larger than +# this value, doxygen will try to truncate the graph, so that it fits within +# the specified constraint. Beware that most browsers cannot cope with very +# large images. + +MAX_DOT_GRAPH_HEIGHT = 1024 + +# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the +# graphs generated by dot. A depth value of 3 means that only nodes reachable +# from the root by following a path via at most 3 edges will be shown. Nodes +# that lay further from the root node will be omitted. Note that setting this +# option to 1 or 2 may greatly reduce the computation time needed for large +# code bases. Also note that a graph may be further truncated if the graph's +# image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH +# and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default), +# the graph is not depth-constrained. + +MAX_DOT_GRAPH_DEPTH = 1000 + +# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent +# background. This is disabled by default, which results in a white background. +# Warning: Depending on the platform used, enabling this option may lead to +# badly anti-aliased labels on the edges of a graph (i.e. they become hard to +# read). + +DOT_TRANSPARENT = NO + +# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output +# files in one run (i.e. multiple -o and -T options on the command line). This +# makes dot run faster, but since only newer versions of dot (>1.8.10) +# support this, this feature is disabled by default. + +DOT_MULTI_TARGETS = YES + +# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will +# generate a legend page explaining the meaning of the various boxes and +# arrows in the dot generated graphs. + +GENERATE_LEGEND = YES + +# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will +# remove the intermediate dot files that are used to generate +# the various graphs. + +DOT_CLEANUP = YES + +#--------------------------------------------------------------------------- +# Configuration::additions related to the search engine +#--------------------------------------------------------------------------- + +# The SEARCHENGINE tag specifies whether or not a search engine should be +# used. If set to NO the values of all tags below this one will be ignored. + +SEARCHENGINE = NO + +# Local Variables: +# compile-command: "doxygen" +# End: diff --git a/doc/doxygen/Makefile.in b/doc/doxygen/Makefile.in new file mode 100644 index 0000000..d7d4620 --- /dev/null +++ b/doc/doxygen/Makefile.in @@ -0,0 +1,38 @@ +# Copyright (C) 2006, 2007 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 +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.4 2007/06/19 23:47:13 tbox Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +SUBDIRS = +TARGETS = + +@BIND9_MAKE_RULES@ + +@BIND9_VERSION@ + +# Until and unless we decide to ship all umptyzillion Doxygen output +# files, distclean for this directory implies docclean. + +doc docclean distclean:: + rm -rf html xml + +doc:: + BIND9_VERSION='${VERSION}' @DOXYGEN@ + +distclean:: + rm -f Doxyfile doxygen-input-filter diff --git a/doc/doxygen/doxygen-input-filter.in b/doc/doxygen/doxygen-input-filter.in new file mode 100644 index 0000000..015559a --- /dev/null +++ b/doc/doxygen/doxygen-input-filter.in @@ -0,0 +1,60 @@ +#!@PERL@ -w +# +# Copyright (C) 2006, 2007 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 +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: doxygen-input-filter.in,v 1.4 2007/06/19 23:47:13 tbox Exp $ + +# Input filter for feeding our source code into Doxygen. + +# Slurp whole file at once +undef $/; +$_ = <>; + +# It turns out that there are a lot of cases where we'd really like to +# use what Doxygen calls "brief" documentation in a comment. Doxygen +# has a shorthand way of doing this -- if one is writing C++. ISC +# coding conventions require C, not C++, so we have to do it the +# verbose way, which makes a lot of comments too long to fit on a +# single line without violating another ISC coding standard (80 +# character line limit). +# +# So we use Doxygen's input filter mechanism to define our own +# brief comment convention: +# +# /*% foo */ +# +# expands to +# +# /*! \brief foo */ +# +# and +# +# /*%< foo */ +# +# expands to +# +# /*!< \brief foo */ +# +s{/\*%( + + + + + +
+
+ + Generated on $datetime by Doxygen $doxygenversion for $projectname $projectnumber + +
+ + diff --git a/doc/doxygen/isc-header.html b/doc/doxygen/isc-header.html new file mode 100644 index 0000000..0773bcf --- /dev/null +++ b/doc/doxygen/isc-header.html @@ -0,0 +1,26 @@ + + + + + + + + $title + + + + diff --git a/doc/doxygen/mainpage b/doc/doxygen/mainpage new file mode 100644 index 0000000..990c4a7 --- /dev/null +++ b/doc/doxygen/mainpage @@ -0,0 +1,85 @@ +// -*- C++ -*- +// $Id: mainpage,v 1.2 2006/12/22 01:44:59 marka Exp $ +// +// Doxygen text. Lines beginning with two slashes are comments; lines +// beginning with three slashes are Doxygen input. + +/// \mainpage +/// \section mainpage_overview Overview +/// \par +/// +/// This is the beginning of an internals manual for BIND9. It's +/// still very rough in many places. +/// +/// \li See the files in doc/doxygen for the source to this page and +/// the Doxygen configuration that generates the rest of the manual. +/// +/// \li See the tabs at the top of the screen to navigate through the +/// generated documentation. +/// +/// \li See the Doxygen web site +/// for more information about Doxygen, including its manual. +/// +/// \section mainpage_knownissues Known Issues +/// \par +/// +/// Known issues with our current use of Doxygen: +/// +/// \li In a major departure from previous attempts to use Doxygen +/// with BIND9, this manual attempts to take the simplest approach +/// to every choice Doxygen gives us. We don't generate fancy +/// extra Doxygen tags files from the RFC database. We don't +/// attempt to use Doxygen as a wrapper framework for other +/// documentation (eg, ISC Tech Notes, the ARM, ...). We don't +/// try to generate the list of files to document on the fly. +/// Instead, we attempt to use Doxygen's native facilities +/// wherever possible, on the assumption that we'll add new +/// features later as we need them but should start as simply as +/// we can. +/// +/// \li Our use of \\file is wrong in many places. We probably should +/// be marking header files with the names by which we include +/// them (eg, "dns/resolver.h"). Doxygen reports filename +/// conflicts in a few cases where it can't work out which of +/// several files to use. +/// +/// \li At the moment we're instructing Doxygen to document all +/// functions, whether they have proper comment markup or not. +/// This is a good way to see what's been marked up, but might not +/// be the right approach in the long run. +/// +/// \li See doc/doxygen/doxygen-input-filter.in for local abbreviations. +/// +/// \li We're probably over-using the \\brief markup tag. +/// +/// \li We may in fact be confusing Doxygen to the point where it's +/// not finding markup comments that it should. Needs +/// investigation. +/// +/// \li At the moment I have all the cool "dot" stuff turned off, +/// both because it's a distraction and because it slows down +/// doxygen runs. Maybe after I get a faster desk machine. :) +/// +/// \li At the moment we're producing a single "BIND9 Internals" +/// manual. One of our previous complications was an attempt to +/// produce separate manuals for each library, then cross-link +/// them. We might still need separate library manuals, but, if +/// so, it might be easier to have the BIND9 Internals manual be a +/// superset of the library manuals (ie, reuse the same source to +/// produce differently scoped manuals). Would certainly be +/// simpler than the cross-linking mess, but partly it's a +/// question of how we want to present the material. +/// +/// \li Doxygen is slanted towards C++. It can be tuned towards plain +/// old C, but the C++ bias still shows up in places, eg, the lack +/// of top-level menu support for functions (in C++, the basic +/// unit of programming is the class, which Doxygen does support +/// directly). This is a bit annoying, but not all that +/// critical. +/// +/// \li If we ever get really ambitious, we might try processing +/// Doxygen's XML output, which is basicly a dump of what Doxygen +/// was able to scrape from the sources. This would be a major +/// project, just something to think about if there's something we +/// really don't like about the output Doxygen generates. Punt +/// for now. diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt new file mode 100644 index 0000000..1030e57 --- /dev/null +++ b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt @@ -0,0 +1,336 @@ + + + + +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 new file mode 100644 index 0000000..fffa8a5 --- /dev/null +++ b/doc/draft/draft-daigle-napstr-04.txt @@ -0,0 +1,1232 @@ + + +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 new file mode 100644 index 0000000..4a01d91 --- /dev/null +++ b/doc/draft/draft-danisch-dns-rr-smtp-03.txt @@ -0,0 +1,1960 @@ + + + +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 new file mode 100644 index 0000000..7b5e8cc --- /dev/null +++ b/doc/draft/draft-dnsext-opcode-discover-02.txt @@ -0,0 +1,241 @@ + +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 new file mode 100644 index 0000000..224e7ad --- /dev/null +++ b/doc/draft/draft-durand-dnsop-dynreverse-00.txt @@ -0,0 +1,240 @@ +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-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt new file mode 100644 index 0000000..fa41e76 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-2929bis-01.txt @@ -0,0 +1,928 @@ + +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-09.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt new file mode 100644 index 0000000..94c08ec --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt @@ -0,0 +1,992 @@ +INTERNET-DRAFT Edward Lewis +draft-ietf-dnsext-axfr-clarify-09.txt NeuStar, Inc. +DNSEXT WG July 2008 +Updates: 1034, 1035 (if approved) Intended status: Standards Track + + DNS Zone Transfer Protocol (AXFR) +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 December 31, 2008. + +Copyright Notice + +Copyright (C) The IETF Trust (2008). + +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) is defined in RFC 1034 and RFC 1035. +The definition of AXFR, has proven insufficient in detail, 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 the AXFR, new in the sense that is it recording an +accurate definition of an interoperable AXFR mechanism. + +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] (aka 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. + +Comments on this draft ought to be addressed to the editor or to +namedroppers@ops.ietf.org. + +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]. + +"Newer"/"New" DNS and "older"/"old" DNS refers to implementations +written after and prior to the publication of this document. + +1.2 Scope + +In the greater context there are many ways to achieve coherency among +a set of name servers. The AXFR, IXFR and NOTIFY mechanisms form +just one, the one defined in the RFCs cited. For example, there are +DNS implementations that assemble answers from data stored in +relational databases (as opposed to master files) relying on the +database's non-DNS means to synchronize the database instances. Some +of these non-DNS solutions interoperate in some fashion. As far as +it is known, AXFR, IXFR and NOTIFY are the only in-band mechanisms +that provide an interoperable solution to the desire for coherency +within the definition of DNS, they certainly are the only mechanisms +documented 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. + +"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 do not conform to +the entire range of DNS functionality. + +A DNS implementation is not required to support AXFR, IXFR and NOTIFY. +A DNS implementation SHOULD have some means for maintaining name server +coherency. A general purpose DNS implementation SHOULD include AXFR +(and in the same vein IXFR and NOTIFY), but turnkey DNS implementations +MAY exist without AXFR. (An editorial note to readers of this section. +The mention of IXFR and NOTIFY is for context and illustration, this +document does not make any normative comments on those mechanisms.) + +1.3 Context + +Besides describing the mechanisms themselves, there is the context in +which they operate to consider. When AXFR, IXFR and NOTIFY were +defined, there was little consideration 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 + +This document concentrates on just the definition of AXFR. Any effort +to update the IXFR or NOTIFY mechanisms would be done in different +documents. This is not strictly a clarification of the definition in +RFC 1034 and RFC 1035. This document will update those sections, and +invalidate at least one part of that definition. The goal of this +document is to define AXFR as it exists, or is supposed to exist, +currently. + +1.4 Coverage and Relationship to Original AXFR Specification + +This document concentrates on just the definition of AXFR. Any effort +to update the IXFR or NOTIFY mechanisms would be done in 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 synchronisation 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 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. + +This document will update the specification of AXFR in fully +specifying the record formats and processing rules for AXFR, largely +expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing +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. + +2 AXFR Messages + +An AXFR message exchange (or session) consists of an AXFR query message +and a set of AXFR response messages. In this document, 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 the AXFR exchange.) The reason for the imbalance +in number of messages derives from large zones whose contents cannot be +fit into the limited permissible size of a DNS message. + +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 +RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: +- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996] +- "Domain Name System (DNS) IANA Considerations" [RFC2929] +- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] +- "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] +- "Protocol Modifications for the DNS Security Extensions" [RFC4035] +- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] + +The upper limit on the permissible size of a DNS message over TCP is +defined in RFC 1035, section 4.2.2. Unlike DNS messages over UDP, +this limit is not changed by EDNS0. + +Field names used in this document will correspond to the names as they +appear in the IANA registry for DNS Header Flags [DNSFLGS]. + +2.1 AXFR query + +An AXFR query is sent by a client whenever there is a reason to ask. +This might be because of zone maintenance activities or as a result of +a command line request, say for debugging. + +2.1.1 Header Values + +These are the DNS message header values for an AXFR query. + +ID See note 2.1.1.a +QR MUST be 0 (Query) +OPCODE MUST be 0 (Standard Query) +AA See note 2.1.1.b +TC See note 2.1.1.b +RD See note 2.1.1.b +RA See note 2.1.1.b +Z See note 2.1.1.c +AD See note 2.1.1.b +CD See note 2.1.1.b +RCODE MUST be 0 (No error) +QDCOUNT MUST be 1 +ANCOUNT MUST be 0 +NSCOUNT MUST be 0 +ARCOUNT See note 2.1.1.d + +Note 2.1.1.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.) + +A server MUST reply using messages that use the same message ID to +allow a client to meaningfully have multiple AXFR queries outstanding. + +Note 2.1.1.b 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. + +Note 2.1.1.c The client MUST set this bit to 0, the server MUST ignore +it. + +Note 2.1.1.d The client MUST set this field to be 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 Query Section + +The Query section of the AXFR query MUST conform to section 4.1.2 of +RFC 1035, and contain 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 + +2.1.3 Answer Section + +MUST be empty. + +2.1.4 Authority Section + +MUST be empty. + +2.1.5 Additional Section + +The client MAY include an EDNS0 OPT [RFC2671] resource record. If the +server has indicated that it does not support EDNS0, the client MUST +send this section without an EDNS0 OPT resource record if there is a +retry. Indication that a server does not support EDNS0 is not an +explicit element in the protocol, it is up to the client to interpret. +Most likely, the server will return a FORMERR 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 ought not try again. Removing 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. Although this is not +predictale, future additional section residing records may 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 first message MUST copy the Query Section +from the corresponding AXFR query message in to the first response +message's query section. Subsequent messages MAY do the same. + +An AXFR response that is indicating an error MUST consist of a single +DNS message with the return code set to the appropriate value for the +condition encountered - once the error condition is detected. Such +a message MUST copy the AXFR query Query Section into its Query +Section. The inclusion of the terminating SOA resource record is not +necessary. + +An AXFR client might receive a number of AXFR response messages +free of an error condition before the message indicating an error +is received. But once an error is reported, the AXFR client can +assume that the error reporting message is the last. + +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 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 undetected 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 acknowledge as a warning to AXFR client +implementations. Any earnest query has the expectation of some +response but may not get one. + +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 session +terminated. The message ID MAY be used again on a new connection, +even if the question and AXFR server are the same. 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 retires nor an increasing (in +frequency) retry rate. + +An AXFR server implementor SHOULD take into consideration what this +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 attemping abusive behavior. + +2.2.2 Header Values + +ID See note 2.2.2.a +QR MUST be 1 (Response) +OPCODE MUST be 0 (Standard Query) +AA See note 2.2.2.b +TC MUST be 0 (Not truncated) +RD RECOMMENDED copy request's value, MAY be set to 0 +RA See note 2.2.2.c +Z See note 2.2.2.d +AD See note 2.2.2.e +CD See note 2.2.2.e +RCODE See note 2.2.2.f +QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all + following +ANCOUNT See note 2.2.2.g +NSCOUNT MUST be 0 +ARCOUNT See note 2.2.2.h + +Note 2.2.2.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. + +Note 2.2.2.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 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. + +Note 2.2.2.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. + +Note 2.2.2.d The server MUST set this bit to 0, the client MUST ignore +it. + +Note 2.2.2.e If the implementation supports the DNS Security Extensions +(see below) 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. + +The DNS Security Extensions (DNSSEC) is 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] + +Note 2.2.2.f In the absence of an error, the server MUST set the value +of this field to NoError. If a server is not authoritative for the +queried zone, the server SHOULD set the value to NotAuth. (Reminder, +consult the appropriate IANA registry [DNSVALS].) If a client +receives any other value in response, it MUST act according 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 value. +This value is not set as part of the AXFR response processing. The +same is true for other error-indicating values. + +Note 2.2.2.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. + +Note 2.2.2.h The client MUST set this field to be the number of +resource records appearing in the additional section. See Section +2.1.5 "Additional Section" for details. + +2.2.3 Query 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, MAY be empty. 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 later section on +encoding zone contents. + +2.2.5 Authority Section + +MUST be empty. + +2.2.5 Additional Section + +The contents of this section MUST follow the guidelines for EDNS0, +TSIG, SIG(0), or what ever other future record is possible here. The +contents of section 2.1.5 apply here as well. + +Note that TSIG and SIG(0), if in use, will treat each individual +AXFR response message within a session as a unit of data. That is, +each message will have a TSIG or SIG(0) (if in use) and the +crytpographic check will cover just that message. The same rule +will apply to future alternatives and documents covering them ought +to consider the impact on AXFR response messages. + +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 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 a +static set of records to a dynamically updated set of records to a +continually regenerated set of records. + +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", and in particular, section 4.2.1, +"Technical considerations". + +Unless the AXFR server knows that the AXFR client expects just one +resource record per AXFR response message, an AXFR server SHOULD +populate an AXFR response message with as many complete resource +records as will fit within a DNS message. + +Zones for which it is impractical to list the entire zones for a serial +number (because changes happen too quickly) are not suitable for AXFR +retrieval. + +3.2 Delegation Records + +In RFC 1034, section 4.2.1, 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 points and the +apex resource records are identical. For example, the SOA resource +record is only found at the apex, as well as a slew of DNSSEC resource +records. There are also some DNSSEC resource record sets that are +explicitly different between the cut point and the apex. The +discussion here is restricted to just the NS resource record set and +glue as these "describe cuts." + +The 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 a 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 of +the cut point. + +The question that arises is, when facing a situation in which a cut +point's NS resource records do not match the authoritative set, whether +an AXFR server responds with the NS resource record set that is in the +zone or 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. + +4) Beginning with an error state of two servers for a zone having +inconsistent zone contents for a given zone serial number, if a client +requests and recieves an IXFR transfer from one server followed by +another IXFR transfer from the other server, the client can encounter +an IXFR protocol error state where an attempt is made to incrementally +add a record that already exists or to delete a record that does not +exist. + +(Editorial note, the 4th reason was suggested, but I don't see how +it relates. A nudge for updated text on this.) + +3.3 Glue Records + +As quoted in the previous section, RFC 1034, section 4.2.1, 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 for glue records for any address family. + +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 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] (and including DNAME [2672]) operations 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 for to +the look up process. The addition of a DNAME resource record set 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 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. There are variations on this, such as a query +for the zone's SOA resource record first, and so on. + +Two issues have emerged since the original specification of AXFR. +One is that lack of specificity has yielded some implementations +that assume the TCP connection is dedicated to the single AXFR +session, which has led to implementation choices that prevent either +multiple concurrent zone transfers or the use of the open connection +for other queries. The other issue is the prospect of using UDP as a +transport has come to look promising because of trends in the past +two decades. + +Being able to have multiple concurrent zone transfers is considered +desirable by operators who have sets of name servers that are +authoritative for a common set of zones. It would be desirable +if the name server implementations did not have to wait for one +zone to transfer before the next could begin. The desire here is to +tighten the specification, not a change, but adding words to the +unclear areas, to define what is needed to permit two servers to +share a TCP connection among concurrent AXFR sessions. The challenge +is to design this in a way that can fall back to the old behavior if +either the AXFR client or AXFR server is incapable of performing +multiple concurrent AXFR sessions. + +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 are now possible and desirable. However, there +are still some aspects of the AXFR session that are not easily +translated to UDP. This document leaves AXFR over UDP undefined. + +4.1 TCP + +In the original definition there is an implicit assumption (probably +unintentional) that a TCP connection is used for one and only one +AXFR session. This is evidenced in no requirement to copy neither +the Query Section nor the message ID in 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 here is intended to enable better performance of +the AXFR exchange as well as 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 AXFR +clients as reversing the situation, older AXFR client and newer +AXFR server ought to induce the server to operate within the +specification for an older server. + +4.1.1 AXFR client TCP + +An AXFR client MAY request an 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 judgement for the AXFR client and the DNS +client. If the connection is used for multiple sessions, or it is +known sessions will be coming or is there is other query/response +traffic on the open connection, that is "apparent need." + +An AXFR client MAY cancel 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. Recovery from this situation +is not straightforward. If the disruption was a spurious event, +attempting to restart the connection would be proper. If the +disruption was caused by a medium or long term disruption, 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 applies is not +clear (momentary disruption, failure, policy). + +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 sessions. + +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 +as 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 + +AXFR sessions over UDP transport are not defined. + +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. All reasons are arguable, but the fact remains that +there is a requirement to provide mechanisms to restrict AXFR. + +A DNS implementation SHOULD provide means to restrict AXFR sessions to +specific clients. By default, a DNS implementation SHOULD only allow +the designated authoritative servers to have access to the zone. + +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." + +6 Zone Integrity + +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 sessions, 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. + +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 +earlier sections. + +Backwards compatibility is not necessary, but the greater extent of an +implementation's compatibility increases it's 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 it's documentation, encourage operators to +periodically review AXFR clients and servers it has made notes about as +old software periodically gets updated. + +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 if the client can +accept multiple resource records per AXFR response message. The +knowledge that a client is so restricted apparently cannot be +discovered, hence it has to be set by configuration. + +An implementation of an AXFR server SHOULD permit configuring, on a per +AXFR client basis, a need to revert to single resource record per +message. The default SHOULD be to use multiple records per message. + +7.2 Client + +An AXFR client has the opportunity to try extensions 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. + +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 + +No new registries or new registrations are included in this document. + +10 Internationalization Considerations + +It is assumed that supporting of international domain names has been +solved via "Internationalizing Domain Names in Applications (IDNA)" +[RFC3490]. + +11 Acknowledgements + +Earlier editions of this document have been edited by Andreas +Gustafsson. In his latest version, this acknowledgement 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: +Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain +Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, +... + +12 References + +All references prefixed by "RFC" can be obtained from the RFC Editor, +information regarding this organization can be found at the following +URL: + http://rfc-editor.org/ +Additionally, these documents can be obtained via the IETF web site. + +12.1 Normative + +[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. +[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. +[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. +[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, RFC + 2929, September 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. +[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. +[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication + Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", + RFC 4635, August 2006. +[DNSFLGS] http://www.iana.org/assignments/dns-header-flags +[DNSVALS] http://www.iana.org/assignments/dns-parameters + +12.2 Informative + +[BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. +[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. + Malis, "A Framework for IP Based Virtual Private Networks", + RFC 2764, February 2000. +[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", RFC + 3490, March 2003. + +13 Editor's Address + +Edward Lewis +46000 Center Oak Plaza +Sterling, VA, 22033, US ++1-571-434-5468 +ed.lewis@neustar.biz + +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. + +Acknowledgment + +Funding for the RFC Editor function is provided by the IETF +Administrative Support Activity (IASA). + + 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 new file mode 100644 index 0000000..438e800 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt @@ -0,0 +1,1397 @@ +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-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt new file mode 100644 index 0000000..bcc2b4e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt @@ -0,0 +1,442 @@ + + +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 new file mode 100644 index 0000000..3a800f9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt @@ -0,0 +1,616 @@ + + + +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-experiments-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt new file mode 100644 index 0000000..c8db709 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt @@ -0,0 +1,840 @@ + + + +DNSEXT D. Blacka +Internet-Draft VeriSign, Inc. +Intended status: Standards Track April 7, 2006 +Expires: October 9, 2006 + + + DNSSEC Experiments + draft-ietf-dnsext-dnssec-experiments-03 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on October 9, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 1] + +Internet-Draft DNSSEC Experiments April 2006 + + +Abstract + + This document describes a methodology for deploying alternate, non- + backwards-compatible, DNSSEC methodologies in an experimental fashion + without disrupting the deployment of standard DNSSEC. + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 10.2. Informative References . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 2] + +Internet-Draft DNSSEC Experiments April 2006 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [5]) and the DNS security extensions ([2], [3], and [4] is assumed. + + The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 3] + +Internet-Draft DNSSEC Experiments April 2006 + + +2. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC and to try these + changes on real zones in the public DNS. This creates a problem when + the change to DNSSEC would make all or part of the zone using those + changes appear bogus (bad) or otherwise broken to existing security- + aware resolvers. + + This document describes a standard methodology for setting up DNSSEC + experiments. This methodology addresses the issue of co-existence + with standard DNSSEC and DNS by using unknown algorithm identifiers + to hide the experimental DNSSEC protocol modifications from standard + security-aware resolvers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 4] + +Internet-Draft DNSSEC Experiments April 2006 + + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and servers that do implement the + DNSSEC standard. + + Non-Backwards-Compatible: describes experiments that would cause a + standard security-aware resolver to (incorrectly) determine that + all or part of a zone is bogus, or to otherwise not interoperate + with standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly may be used + if desired. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 5] + +Internet-Draft DNSSEC Experiments April 2006 + + +4. Method + + The core of the methodology is the use of strictly unknown algorithm + identifiers when signing the experimental zone, and more importantly, + having only unknown algorithm identifiers in the DS records for the + delegation to the zone at the parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithm identifiers. From [4], Section 5.2: + + If the validator does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + And further: + + If the resolver does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver will not be able to + verify the authentication path to the child zone. In this case, + the resolver SHOULD treat the child zone as if it were unsigned. + + While this behavior isn't strictly mandatory (as marked by MUST), it + is likely that a validator would implement this behavior, or, more to + the point, it would handle this situation in a safe way (see below + (Section 6).) + + Because we are talking about experiments, it is RECOMMENDED that + private algorithm numbers be used (see [3], appendix A.1.1. Note + that secure handling of private algorithms requires special handing + by the validator logic. See [6] for further details.) Normally, + instead of actually inventing new signing algorithms, the recommended + path is to create alternate algorithm identifiers that are aliases + for the existing, known algorithms. While, strictly speaking, it is + only necessary to create an alternate identifier for the mandatory + algorithms, it is suggested that all optional defined algorithms be + aliased as well. + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and + "5.dnssec-experiment-a.example.com". However, any unique identifier + + + +Blacka Expires October 9, 2006 [Page 6] + +Internet-Draft DNSSEC Experiments April 2006 + + + will suffice. + + Using this method, resolvers (or, more specifically, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of security-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiment's algorithm identifiers and + experimental semantics), and servers and resolvers that are unaware + of the experiment. + + This method also precludes any zone from being both in an experiment + and in a classic DNSSEC island of security. That is, a zone is + either in an experiment and only experimentally validatable, or it is + not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 7] + +Internet-Draft DNSSEC Experiments April 2006 + + +5. Defining an Experiment + + The DNSSEC experiment MUST define the particular set of (previously + unknown) algorithm identifiers that identify the experiment, and + define what each unknown algorithm identifier means. Typically, + unless the experiment is actually experimenting with a new DNSSEC + algorithm, this will be a mapping of private algorithm identifiers to + existing, known algorithms. + + Normally the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + OID private algorithm space instead (using algorithm number 254), or + MAY choose non-private algorithm numbers, although this would require + an IANA allocation. + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and declare + that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC + algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an + alias of DNSSEC algorithm 5 (RSASHA1). + + Resolvers MUST only recognize the experiment's semantics when present + in a zone signed by one or more of these algorithm identifiers. This + is necessary to isolate the semantics of one experiment from any + others that the resolver might understand. + + In general, resolvers involved in the experiment are expected to + understand both standard DNSSEC and the defined experimental DNSSEC + protocol, although this isn't required. + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 8] + +Internet-Draft DNSSEC Experiments April 2006 + + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. Under some circumstances, it may be that the experiment will not + be sufficiently masked by this technique and may cause resolution + problem for resolvers not aware of the experiment. For instance, + the resolver may look at a non-validatable response and conclude + that the response is bogus, either due to local policy or + implementation details. This is not expected to be a common + case, however. + + 2. It will not be possible for security-aware resolvers unaware of + the experiment to build a chain of trust through an experimental + zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 9] + +Internet-Draft DNSSEC Experiments April 2006 + + +7. Use in Non-Experiments + + This general methodology MAY be used for non-backwards compatible + DNSSEC protocol changes that start out as or become standards. In + this case: + + o The protocol change SHOULD use public IANA allocated algorithm + identifiers instead of private algorithm identifiers. This will + help identify the protocol change as a standard, rather than an + experiment. + + o Resolvers MAY recognize the protocol change in zones not signed + (or not solely signed) using the new algorithm identifiers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 10] + +Internet-Draft DNSSEC Experiments April 2006 + + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 11] + +Internet-Draft DNSSEC Experiments April 2006 + + +9. IANA Considerations + + This document has no IANA actions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 12] + +Internet-Draft DNSSEC Experiments April 2006 + + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + +10.2. Informative References + + [5] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [6] Austein, R. and S. Weiler, "Clarifications and Implementation + Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02 + (work in progress), January 2006. + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 13] + +Internet-Draft DNSSEC Experiments April 2006 + + +Author's Address + + David Blacka + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 14] + +Internet-Draft DNSSEC Experiments April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Blacka Expires October 9, 2006 [Page 15] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt new file mode 100644 index 0000000..7503c66 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt @@ -0,0 +1,616 @@ + + + +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 new file mode 100644 index 0000000..17e28e8 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt @@ -0,0 +1,896 @@ + + + +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-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-06.txt new file mode 100644 index 0000000..1dc9070 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-06.txt @@ -0,0 +1,504 @@ + + + +DNS Extensions working group J. Jansen +Internet-Draft NLnet Labs +Intended status: Standards Track October 23, 2008 +Expires: April 26, 2009 + + + Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records + for DNSSEC + draft-ietf-dnsext-dnssec-rsasha256-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 April 26, 2009. + +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 (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 1] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 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 . . . . . . . . . . . . . . . . . . . . 4 + 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 + 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 5 + 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 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource + Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Intellectual Property and Copyright Statements . . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 2] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + +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 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-2.2002] family + of algorithms is assumed in this document. + + 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. + + +2. DNSKEY Resource Records + + The format of the DNSKEY RR can be found in RFC 4034 [RFC4034], RFC + 3110 [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 {TBA1}. + + For use with NSEC3 [RFC5155], the algorithm number for RSA/SHA-256 + will be {TBA2}. The use of a different algorithm number to + differentiate between the use of NSEC and NSEC3 is in keeping with + the approach adopted in RFC5155. + + For interoperability, as in RFC 3110 [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 {TBA3}. + + + +Jansen Expires April 26, 2009 [Page 3] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + For use with NSEC3, the algorithm number for RSA/SHA-512 will be + {TBA4}. The use of a different algorithm number to differentiate + between the use of NSEC and NSEC3 is in keeping with the approach + adopted in RFC5155. + + 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 RFC 4034 [RFC4034]. + + hash = SHA-XXX(data) + + Here XXX is either 256 or 512, depending on the algorithm used, as + specified in FIPS PUB 180-2 [FIPS.180-2.2002], and "data" is the wire + format data of the resource record set that is signed, as specified + in RFC 4034 [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 + [RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 + [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 {TBA1} for use with NSEC, or + {TBA2} for use with NSEC3. + + The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as + specified in PKCS #1 v2.1 [RFC3447]: + + + + +Jansen Expires April 26, 2009 [Page 4] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + 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 {TBA3} for use with NSEC, or + {TBA4} for use with NSEC3. + + The prefix is the ASN.1 BER 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 + + +4. Deployment Considerations + +4.1. Key Sizes + + Apart from the restrictions specified 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 the hashing algorithm used in + the signing process. Therefore, RRSIG resource records produced with + RSA/SHA256 or RSA/SHA512 will have the same size as those produced + with RSA/SHA1, 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 resource + records with the RSA/SHA-2 algorithms. + + +6. IANA Considerations + + IANA has assigned DNS Security Algorithm Numbers {TBA1} for RSA/ + SHA-256 with NSEC, {TBA2} for RSA/SHA-256 with NSEC3, {TBA3} for RSA/ + SHA-512 with NSEC, and {TBA4} for RSA/SHA-512 with NSEC3. + + The algorithm list from RFC 4034 Appendix A.1 [RFC4034] is extended + + + +Jansen Expires April 26, 2009 [Page 5] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + with the following entries: + + Zone + Value Algorithm [Mnemonic] Signing References + {TBA1} RSA/SHA-256 RSASHA256 y {this memo} + {TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} + {TBA3} RSA/SHA-512 RSASHA512 y {this memo} + {TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 y {this memo} + + + +7. Security Considerations + +7.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. + +7.2. Signature Type Downgrade Attacks + + Since each RRSet MUST be signed with each algorithm present in the + DNSKEY RRSet at the zone apex (see [RFC4035] Section 2.2), 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. + + +8. Acknowledgments + + This document is a minor extension to RFC 4034 [RFC4034]. Also, we + try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509] + for consistency. The authors of and contributors to these documents + are gratefully acknowledged for their hard work. + + + + +Jansen Expires April 26, 2009 [Page 6] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + The following people provided additional feedback and text: Jaap + Akkerhuis, Roy Arends, Rob Austein, Francis Dupont, Miek Gieben, + Alfred Hoenes, Paul Hoffman, Peter Koch, Michael St. Johns, Scott + Rose and Wouter Wijngaards. + + +9. References + +9.1. Normative References + + [FIPS.180-2.2002] + National Institute of Standards and Technology, "Secure + Hash Standard", FIPS PUB 180-2, August 2002. + + [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. + +9.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. + + [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. + + + + + +Jansen Expires April 26, 2009 [Page 7] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + +Author's Address + + Jelte Jansen + NLnet Labs + Kruislaan 419 + Amsterdam 1098VA + NL + + Email: jelte@NLnetLabs.nl + URI: http://www.nlnetlabs.nl/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 8] + +Internet-Draft DNSSEC RSA/SHA-2 October 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. + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 9] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt new file mode 100644 index 0000000..dd8cbf0 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt @@ -0,0 +1,839 @@ + +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 new file mode 100644 index 0000000..2460cb6 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt @@ -0,0 +1,504 @@ + + + +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-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt new file mode 100644 index 0000000..2cdcdb1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt @@ -0,0 +1,928 @@ + +INTERNET-DRAFT ECC Keys in the DNS +Expires: January 2006 July 2005 + + + + Elliptic Curve KEYs in the DNS + -------- ----- ---- -- --- --- + + + Richard C. Schroeppel + Donald Eastlake 3rd + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list . + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for storing elliptic curve cryptographic keys and + signatures in the Domain Name System is specified. + + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + + + + + +R. Schroeppel, et al [Page 1] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve Data in Resource Records.................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Elliptic Curve SIG Resource Records....................11 + 6. Performance Considerations.............................13 + 7. Security Considerations................................13 + 8. IANA Considerations....................................13 + Copyright and Disclaimer..................................14 + + Informational References..................................15 + Normative Refrences.......................................15 + + Author's Addresses........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + +INTERNET-DRAFT ECC Keys in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC 4033, 4034, + 4035]. + + This document describes how to store elliptic curve cryptographic + (ECC) keys and signatures in the DNS so they can be used for a + variety of security purposes. Familiarity with ECC cryptography is + assumed [Menezes]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + +2. Elliptic Curve Data in Resource Records + + Elliptic curve public keys are stored in the DNS within the RDATA + portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the + structure shown below. + + The research world continues to work on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. So, representations are + defined for every type of finite field, and every type of elliptic + curve. The reader should be aware that there is a unique finite + field with a particular number of elements, but many possible + representations of that field and its elements. If two different + representations of a field are given, they are interconvertible with + a tedious but practical precomputation, followed by a fast + computation for each field element to be converted. It is perfectly + reasonable for an algorithm to work internally with one field + representation, and convert to and from a different external + representation. + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 3] + + +INTERNET-DRAFT ECC Keys in the DNS + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + + +R. Schroeppel, et al [Page 4] + + +INTERNET-DRAFT ECC Keys in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + + + +R. Schroeppel, et al [Page 5] + + +INTERNET-DRAFT ECC Keys in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of an RR and MUST be + ignored when processing an RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range + [0,P-1]. The coefficients are packed into fixed-width fields, from + higher order to lower order. All coefficients must be present, + including any 0s and also the leading coefficient (which is required + to be 1). The coefficients are right justified into the octet string + of length specified by LF, with the low-order "constant" coefficient + at the right end. As a concession to storage efficiency, the higher + order bits of the leading coefficient may be elided, discarding high- + order 0 octets and reducing LF. The degree is calculated by + + +R. Schroeppel, et al [Page 6] + + +INTERNET-DRAFT ECC Keys in the DNS + + + determining the bit position of the left most 1-bit in the F data + (counting the right most bit as position 0), and dividing by + ceiling(log2 P). The division must be exact, with no remainder. In + this format, all of the other degree and field parameters are + omitted. The next parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of + degree D is X^D (which is not irreducible). The next is X^D+1, which + is sometimes irreducible, followed by X^D-1, which isn't. Assuming + odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + +INTERNET-DRAFT ECC Keys in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + +INTERNET-DRAFT ECC Keys in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user's public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + +INTERNET-DRAFT ECC Keys in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof's algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user's public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + +INTERNET-DRAFT ECC Keys in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Elliptic Curve SIG Resource Records + + The signature portion of an RR RDATA area when using the EC + algorithm, for example in the RRSIG and SIG [RFC records] RRs is + shown below. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + R and S are integers (mod Q). Their length is specified by the LQ + field of the corresponding KEY RR and can also be calculated from the + SIG RR's RDLENGTH. They are right justified, high-order-octet first. + The same conditional formula for calculating the length from LQ is + used as for all the other length fields above. + + The data signed is determined as specified in [RFC 2535]. Then the + following steps are taken where Q, P, G, and Y are as specified in + the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two + different messages with the same K. K should be chosen from a + very large space: If an opponent learns a K value for a single + signature, the user's signing key is compromised, and a forger + can sign arbitrary messages. There is no harm in signing the + same message multiple times with the same key or different + keys.) + + R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted + + +R. Schroeppel, et al [Page 11] + + +INTERNET-DRAFT ECC Keys in the DNS + + + as an integer, and reduced (mod Q). (R must not be 0. In + this astronomically unlikely event, generate a new random K + and recalculate R.) + + S = ( K^(-1) * (hash + X*R) ) mod Q. + + S must not be 0. In this astronomically unlikely event, generate a + new random K and recalculate R and S. + + If S > Q/2, set S = Q - S. + + The pair (R,S) is the signature. + + Another party verifies the signature as follows: + + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. + + hash = SHA-1 ( data ) + + Sinv = S^(-1) mod Q. + + U1 = (hash * Sinv) mod Q. + + U2 = (R * Sinv) mod Q. + + (U1 * G + U2 * Y) is computed on the elliptic curve. + + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). + + The signature is valid if V = R. + + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for + hash(data)+Q or hash(data)-Q, if these happen to fall in the range + [0,2^160-1]. It's believed to be computationally infeasible to + find data that hashes to an assigned value, so this is only a + cosmetic blemish. The blemish can be eliminated by using Q > + 2^160, at the cost of having slightly longer signatures, 42 octets + instead of 40. + + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the + obvious thing". In the (mod P) case, E is simply a residue mod P, + and is taken as an integer in the range [0,P-1]. In the GF[2^D] + + +R. Schroeppel, et al [Page 12] + + +INTERNET-DRAFT ECC Keys in the DNS + + + case, E is in the D-bit polynomial basis representation, and is + simply taken as an integer in the range [0,(2^D)-1]. For other + fields GF[P^D], it's necessary to do some radix conversion + arithmetic. + + + + 6. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than + RSA and DSA. Creation of a curve is slow, but not done very often. + Key generation is faster than RSA or DSA. + + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of RR sets stored within the DNS + consistent with adequate security. + + + + 7. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + Some specific key generation considerations are given in the body + of this document. + + + + 8. IANA Considerations + + The key and signature data structures defined herein correspond to + the value 4 in the Algorithm number field of the IANA registry + + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in + defined in this document requires an IETF consensus as defined in + [RFC 2434]. + + + + + +R. Schroeppel, et al [Page 13] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Copyright and Disclaimer + + Copyright (C) The Internet Society 2005. This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Informational References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", + August 1999. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, June + 2005. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic + Curves", 1986, Springer Graduate Texts in mathematics #106. + + + + Normative Refrences + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security Extensions", RFC + 4034, March 2005. + + + + + + + +R. Schroeppel, et al [Page 15] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Author's Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: +1-505-844-9079(w) + Email: rschroe@sandia.gov + + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + + Expiration and File Name + + This draft expires in January 2006. + + Its file name is draft-ietf-dnsext-ecc-key-07.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt b/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt new file mode 100644 index 0000000..87bce00 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt @@ -0,0 +1,17 @@ + +This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted +from the Internet-Drafts directory. An Internet-Draft expires 185 days from +the date that it is posted unless it is replaced by an updated version, or the +Secretariat has been notified that the document is under official review by the +IESG or has been passed to the RFC Editor for review and/or publication as an +RFC. This Internet-Draft was not published as an RFC. + +Internet-Drafts are not archival documents, and copies of Internet-Drafts that have +been deleted from the directory are not available. The Secretariat does not have +any information regarding the future plans of the author(s) or working group, if +applicable, with respect to this deleted Internet-Draft. For more information, or +to request a copy of the document, please contact the author(s) directly. + +Draft Author(s): +Remco van Mook , +Bert Hubert diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt new file mode 100644 index 0000000..160afc3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-interop3597-02.txt @@ -0,0 +1,334 @@ +DNS Extensions Working Group J. Schlyter +Internet-Draft May 19, 2005 +Expires: November 20, 2005 + + + RFC 3597 Interoperability Report + draft-ietf-dnsext-interop3597-02.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 20, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 1] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3 + 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3 + 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4 + 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4 + 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 + A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 + Intellectual Property and Copyright Statements . . . . . . . . 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 2] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +1. Introduction + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. The test was + performed during June and July 2004 by request of the IETF DNS + Extensions Working Group. + +2. Implementations + + The following is a list, in alphabetic order, of implementations + tested for compliance with RFC 3597: + + DNSJava 1.6.4 + ISC BIND 8.4.5 + ISC BIND 9.3.0 + NSD 2.1.1 + Net::DNS 0.47 patchlevel 1 + Nominum ANS 2.2.1.0.d + + These implementations covers the following functions (number of + implementations tested for each function in paranthesis): + + Authoritative Name Servers (4) + Full Recursive Resolver (2) + Stub Resolver (4) + DNSSEC Zone Signers (2) + + All listed implementations are genetically different. + +3. Tests + + The following tests was been performed to validate compliance with + RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression") + and 5 ("Text Representation"). + +3.1 Authoritative Primary Name Server + + The test zone data (Appendix A) was loaded into the name server + implementation and the server was queried for the loaded information. + +3.2 Authoritative Secondary Name Server + + The test zone data (Appendix A) was transferred using AXFR from + another name server implementation and the server was queried for the + transferred information. + + + + + + +Schlyter Expires November 20, 2005 [Page 3] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +3.3 Full Recursive Resolver + + A recursive resolver was queried for resource records from a domain + with the test zone data (Appendix A). + +3.4 Stub Resolver + + A stub resolver was used to query resource records from a domain with + the test zone data (Appendix A). + +3.5 DNSSEC Signer + + A DNSSEC signer was used to sign a zone with test zone data + (Appendix A). + +4. Problems found + + Two implementations had problems with text presentation of zero + length RDATA. + + One implementation had problems with text presentation of RR type + code and classes >= 4096. + + Bug reports were filed for problems found. + +5. Summary + + Unknown type codes works in the tested authoritative servers, + recursive resolvers and stub clients. + + No changes are needed to advance RFC 3597 to draft standard. + +6. Normative References + + [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + +Author's Address + + Jakob Schlyter + + Email: jakob@rfc.se + + + + + + + + +Schlyter Expires November 20, 2005 [Page 4] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Appendix A. Test zone data + + ; A-record encoded as TYPE1 + a TYPE1 \# 4 7f000001 + a TYPE1 192.0.2.1 + a A \# 4 7f000002 + + ; draft-ietf-secsh-dns-05.txt + sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e + + ; bogus test record (from RFC 3597) + type731 TYPE731 \# 6 abcd ( + ef 01 23 45 ) + + ; zero length RDATA (from RFC 3597) + type62347 TYPE62347 \# 0 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 5] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Schlyter Expires November 20, 2005 [Page 6] + + diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt new file mode 100644 index 0000000..6bffb70 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt @@ -0,0 +1,560 @@ + +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-46.txt b/doc/draft/draft-ietf-dnsext-mdns-46.txt new file mode 100644 index 0000000..63d0b23 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-46.txt @@ -0,0 +1,1801 @@ + + + + + + +DNSEXT Working Group Bernard Aboba +INTERNET-DRAFT Dave Thaler +Category: Standards Track Levon Esibov + Microsoft Corporation +16 April 2006 + + Linklocal Multicast Name Resolution (LLMNR) + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on October 15, 2006. + +Copyright Notice + + Copyright (C) The Internet Society 2006. + +Abstract + + The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable + name resolution in scenarios in which conventional DNS name + resolution is not possible. LLMNR supports all current and future + DNS formats, types and classes, while operating on a separate port + from DNS, and with a distinct resolver cache. Since LLMNR only + operates on the local link, it cannot be considered a substitute for + DNS. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 1] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Table of Contents + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 4 + 1.2 Terminology ..................................... 4 +2. Name Resolution Using LLMNR ........................... 4 + 2.1 LLMNR Packet Format ............................. 5 + 2.2 Sender Behavior ................................. 8 + 2.3 Responder Behavior .............................. 8 + 2.4 Unicast Queries and Responses ................... 11 + 2.5 Off-link Detection .............................. 11 + 2.6 Responder Responsibilities ...................... 12 + 2.7 Retransmission and Jitter ....................... 13 + 2.8 DNS TTL ......................................... 14 + 2.9 Use of the Authority and Additional Sections .... 14 +3. Usage model ........................................... 15 + 3.1 LLMNR Configuration ............................. 16 +4. Conflict Resolution ................................... 18 + 4.1 Uniqueness Verification ......................... 18 + 4.2 Conflict Detection and Defense .................. 19 + 4.3 Considerations for Multiple Interfaces .......... 20 + 4.4 API issues ...................................... 22 +5. Security Considerations ............................... 22 + 5.1 Denial of Service ............................... 22 + 5.2 Spoofing ...............,........................ 23 + 5.3 Authentication .................................. 24 + 5.4 Cache and Port Separation ....................... 24 +6. IANA considerations ................................... 25 +7. Constants ............................................. 25 +8. References ............................................ 26 + 8.1 Normative References ............................ 26 + 8.2 Informative References .......................... 26 +Acknowledgments .............................................. 28 +Authors' Addresses ........................................... 28 +Intellectual Property Statement .............................. 29 +Disclaimer of Validity ....................................... 29 +Copyright Statement .......................................... 29 + + + + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 2] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +1. Introduction + + This document discusses Link Local Multicast Name Resolution (LLMNR), + which is based on the DNS packet format and supports all current and + future DNS formats, types and classes. LLMNR operates on a separate + port from the Domain Name System (DNS), with a distinct resolver + cache. + + Since LLMNR only operates on the local link, it cannot be considered + a substitute for DNS. Link-scope multicast addresses are used to + prevent propagation of LLMNR traffic across routers, potentially + flooding the network. LLMNR queries can also be sent to a unicast + address, as described in Section 2.4. + + Propagation of LLMNR packets on the local link is considered + sufficient to enable name resolution in small networks. In such + networks, if a network has a gateway, then typically the network is + able to provide DNS server configuration. Configuration issues are + discussed in Section 3.1. + + In the future, it may be desirable to consider use of multicast name + resolution with multicast scopes beyond the link-scope. This could + occur if LLMNR deployment is successful, the need arises for + multicast name resolution beyond the link-scope, or multicast routing + becomes ubiquitous. For example, expanded support for multicast name + resolution might be required for mobile ad-hoc networks. + + Once we have experience in LLMNR deployment in terms of + administrative issues, usability and impact on the network, it will + be possible to reevaluate which multicast scopes are appropriate for + use with multicast name resolution. IPv4 administratively scoped + multicast usage is specified in "Administratively Scoped IP + Multicast" [RFC2365]. + + Service discovery in general, as well as discovery of DNS servers + using LLMNR in particular, is outside of the scope of this document, + as is name resolution over non-multicast capable media. + +1.1. Requirements + + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +1.2. Terminology + + This document assumes familiarity with DNS terminology defined in + [RFC1035]. Other terminology used in this document includes: + +Routable Address + An address other than a Link-Local address. This includes globally + routable addresses, as well as private addresses. + +Reachable + An LLMNR responder considers one of its addresses reachable over a + link if it will respond to an ARP or Neighbor Discovery query for + that address received on that link. + +Responder + A host that listens to LLMNR queries, and responds to those for + which it is authoritative. + +Sender + A host that sends an LLMNR query. + +UNIQUE + There are some scenarios when multiple responders may respond to + the same query. There are other scenarios when only one responder + may respond to a query. Names for which only a single responder is + anticipated are referred to as UNIQUE. Name uniqueness is + configured on the responder, and therefore uniqueness verification + is the responder's responsibility. + +2. Name Resolution Using LLMNR + + LLMNR queries are sent to and received on port 5355. The IPv4 link- + scope multicast address a given responder listens to, and to which a + sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast + address a given responder listens to, and to which a sender sends all + queries, is FF02:0:0:0:0:0:1:3. + + Typically a host is configured as both an LLMNR sender and a + responder. A host MAY be configured as a sender, but not a + responder. However, a host configured as a responder MUST act as a + sender, if only to verify the uniqueness of names as described in + Section 4. This document does not specify how names are chosen or + configured. This may occur via any mechanism, including DHCPv4 + [RFC2131] or DHCPv6 [RFC3315]. + + A typical sequence of events for LLMNR usage is as follows: + + [a] An LLMNR sender sends an LLMNR query to the link-scope + + + +Aboba, Thaler & Esibov Standards Track [Page 4] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + multicast address(es), unless a unicast query is indicated, + as specified in Section 2.4. + + [b] A responder responds to this query only if it is authoritative + for the name in the query. A responder responds to a + multicast query by sending a unicast UDP response to the sender. + Unicast queries are responded to as indicated in Section 2.4. + + [c] Upon reception of the response, the sender processes it. + + The sections that follow provide further details on sender and + responder behavior. + +2.1. LLMNR Packet Format + + LLMNR is based on the DNS packet format defined in [RFC1035] Section + 4 for both queries and responses. LLMNR implementations SHOULD send + UDP queries and responses only as large as are known to be + permissible without causing fragmentation. When in doubt a maximum + packet size of 512 octets SHOULD be used. LLMNR implementations MUST + accept UDP queries and responses as large as the smaller of the link + MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 + octets for the header, VLAN tag and CRC). + +2.1.1. LLMNR Header Format + + LLMNR queries and responses utilize the DNS header format defined in + [RFC1035] with exceptions noted below: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + + + + +Aboba, Thaler & Esibov Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +ID A 16 bit identifier assigned by the program that generates any kind + of query. This identifier is copied from the query to the response + and can be used by the sender to match responses to outstanding + queries. The ID field in a query SHOULD be set to a pseudo-random + value. For advice on generation of pseudo-random values, please + consult [RFC1750]. + +QR Query/Response. A one bit field, which if set indicates that the + message is an LLMNR response; if clear then the message is an LLMNR + query. + +OPCODE + A four bit field that specifies the kind of query in this message. + This value is set by the originator of a query and copied into the + response. This specification defines the behavior of standard + queries and responses (opcode value of zero). Future + specifications may define the use of other opcodes with LLMNR. + LLMNR senders and responders MUST support standard queries (opcode + value of zero). LLMNR queries with unsupported OPCODE values MUST + be silently discarded by responders. + +C Conflict. When set within a request, the 'C'onflict bit indicates + that a sender has received multiple LLMNR responses to this query. + In an LLMNR response, if the name is considered UNIQUE, then the + 'C' bit is clear, otherwise it is set. LLMNR senders do not + retransmit queries with the 'C' bit set. Responders MUST NOT + respond to LLMNR queries with the 'C' bit set, but may start the + uniqueness verification process, as described in Section 4.2. + +TC TrunCation - specifies that this message was truncated due to + length greater than that permitted on the transmission channel. + The TC bit MUST NOT be set in an LLMNR query and if set is ignored + by an LLMNR responder. If the TC bit is set in an LLMNR response, + then the sender SHOULD resend the LLMNR query over TCP using the + unicast address of the responder as the destination address. If + the sender receives a response to the TCP query, then it SHOULD + discard the UDP response with the TC bit set. See [RFC2181] and + Section 2.4 of this specification for further discussion of the TC + bit. + +T Tentative. The 'T'entative bit is set in a response if the + responder is authoritative for the name, but has not yet verified + the uniqueness of the name. A responder MUST ignore the 'T' bit in + a query, if set. A response with the 'T' bit set is silently + discarded by the sender, except if it is a uniqueness query, in + which case a conflict has been detected and a responder MUST + resolve the conflict as described in Section 4.1. + + + + +Aboba, Thaler & Esibov Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Z Reserved for future use. Implementations of this specification + MUST set these bits to zero in both queries and responses. If + these bits are set in a LLMNR query or response, implementations of + this specification MUST ignore them. Since reserved bits could + conceivably be used for different purposes than in DNS, + implementors are advised not to enable processing of these bits in + an LLMNR implementation starting from a DNS code base. + +RCODE + Response code -- this 4 bit field is set as part of LLMNR + responses. In an LLMNR query, the sender MUST set RCODE to zero; + the responder ignores the RCODE and assumes it to be zero. The + response to a multicast LLMNR query MUST have RCODE set to zero. A + sender MUST silently discard an LLMNR response with a non-zero + RCODE sent in response to a multicast query. + + If an LLMNR responder is authoritative for the name in a multicast + query, but an error is encountered, the responder SHOULD send an + LLMNR response with an RCODE of zero, no RRs in the answer section, + and the TC bit set. This will cause the query to be resent using + TCP, and allow the inclusion of a non-zero RCODE in the response to + the TCP query. Responding with the TC bit set is preferable to not + sending a response, since it enables errors to be diagnosed. This + may be required, for example, when an LLMNR query includes a TSIG + RR in the additional section, and the responder encounters a + problem that requires returning a non-zero RCODE. TSIG error + conditions defined in [RFC2845] include a TSIG RR in an + unacceptable position (RCODE=1) or a TSIG RR which does not + validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)). + + Since LLMNR responders only respond to LLMNR queries for names for + which they are authoritative, LLMNR responders MUST NOT respond + with an RCODE of 3; instead, they should not respond at all. + + LLMNR implementations MUST support EDNS0 [RFC2671] and extended + RCODE values. + +QDCOUNT + An unsigned 16 bit integer specifying the number of entries in the + question section. A sender MUST place only one question into the + question section of an LLMNR query. LLMNR responders MUST silently + discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders + MUST silently discard LLMNR responses with QDCOUNT not equal to + one. + +ANCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the answer section. LLMNR responders MUST silently + + + +Aboba, Thaler & Esibov Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + discard LLMNR queries with ANCOUNT not equal to zero. + +NSCOUNT + An unsigned 16 bit integer specifying the number of name server + resource records in the authority records section. Authority + record section processing is described in Section 2.9. LLMNR + responders MUST silently discard LLMNR queries with NSCOUNT not + equal to zero. + +ARCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the additional records section. Additional record + section processing is described in Section 2.9. + +2.2. Sender Behavior + + A sender MAY send an LLMNR query for any legal resource record type + (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. + As described in Section 2.4, a sender MAY also send a unicast query. + + The sender MUST anticipate receiving no replies to some LLMNR + queries, in the event that no responders are available within the + link-scope. If no response is received, a resolver treats it as a + response that the name does not exist (RCODE=3 is returned). A + sender can handle duplicate responses by discarding responses with a + source IP address and ID field that duplicate a response already + received. + + When multiple valid LLMNR responses are received with the 'C' bit + set, they SHOULD be concatenated and treated in the same manner that + multiple RRs received from the same DNS server would be. However, + responses with the 'C' bit set SHOULD NOT be concatenated with + responses with the 'C' bit clear; instead, only the responses with + the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are + received along with error response(s), then the error responses are + silently discarded. + + Since the responder may order the RRs in the response so as to + indicate preference, the sender SHOULD preserve ordering in the + response to the querying application. + +2.3. Responder Behavior + + An LLMNR response MUST be sent to the sender via unicast. + + Upon configuring an IP address, responders typically will synthesize + corresponding A, AAAA and PTR RRs so as to be able to respond to + LLMNR queries for these RRs. An SOA RR is synthesized only when a + + + +Aboba, Thaler & Esibov Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + responder has another RR in addition to the SOA RR; the SOA RR MUST + NOT be the only RR that a responder has. However, in general whether + RRs are manually or automatically created is an implementation + decision. + + For example, a host configured to have computer name "host1" and to + be a member of the "example.com" domain, and with IPv4 address + 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be + authoritative for the following records: + + host1. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + host1.example.com. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + 1.2.0.192.in-addr.arpa. IN PTR host1. + IN PTR host1.example.com. + + 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. + ip6.arpa IN PTR host1. (line split for formatting reasons) + IN PTR host1.example.com. + + An LLMNR responder might be further manually configured with the name + of a local mail server with an MX RR included in the "host1." and + "host1.example.com." records. + + In responding to queries: + +[a] Responders MUST listen on UDP port 5355 on the link-scope multicast + address(es) defined in Section 2, and on TCP port 5355 on the + unicast address(es) that could be set as the source address(es) + when the responder responds to the LLMNR query. + +[b] Responders MUST direct responses to the port from which the query + was sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + responder MUST take note of the source port and use that as the + destination port in the response. Responses MUST always be sent + from the port to which they were directed. + +[c] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups, with the exception of queries with the 'C' bit + set, which do not elicit a response. + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + + + +Aboba, Thaler & Esibov Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[e] Responders MUST NOT respond using data from the LLMNR or DNS + resolver cache. + +[f] If a DNS server is running on a host that supports LLMNR, the DNS + server MUST respond to LLMNR queries only for the RRSets relating + to the host on which the server is running, but MUST NOT respond + for other records for which the server is authoritative. DNS + servers also MUST NOT send LLMNR queries in order to resolve DNS + queries. + +[g] If a responder is authoritative for a name, it MUST respond with + RCODE=0 and an empty answer section, if the type of query does not + match a RR that the responder has. + + As an example, a host configured to respond to LLMNR queries for the + name "foo.example.com." is authoritative for the name + "foo.example.com.". On receiving an LLMNR query for an A RR with the + name "foo.example.com." the host authoritatively responds with A + RR(s) that contain IP address(es) in the RDATA of the resource + record. If the responder has a AAAA RR, but no A RR, and an A RR + query is received, the responder would respond with RCODE=0 and an + empty answer section. + + In conventional DNS terminology a DNS server authoritative for a zone + is authoritative for all the domain names under the zone apex except + for the branches delegated into separate zones. Contrary to + conventional DNS terminology, an LLMNR responder is authoritative + only for the zone apex. + + For example the host "foo.example.com." is not authoritative for the + name "child.foo.example.com." unless the host is configured with + multiple names, including "foo.example.com." and + "child.foo.example.com.". As a result, "foo.example.com." cannot + reply to an LLMNR query for "child.foo.example.com." with RCODE=3 + (authoritative name error). The purpose of limiting the name + authority scope of a responder is to prevent complications that could + be caused by coexistence of two or more hosts with the names + representing child and parent (or grandparent) nodes in the DNS tree, + for example, "foo.example.com." and "child.foo.example.com.". + + Without the restriction on authority an LLMNR query for an A resource + record for the name "child.foo.example.com." would result in two + authoritative responses: RCODE=3 (authoritative name error) received + from "foo.example.com.", and a requested A record - from + "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled + hosts could perform a dynamic update of the parent (or grandparent) + zone with a delegation to a child zone; for example a host + "child.foo.example.com." could send a dynamic update for the NS and + + + +Aboba, Thaler & Esibov Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + glue A record to "foo.example.com.". However, this approach + significantly complicates implementation of LLMNR and would not be + acceptable for lightweight hosts. + +2.4. Unicast Queries and Responses + + Unicast queries SHOULD be sent when: + + [a] A sender repeats a query after it received a response + with the TC bit set to the previous LLMNR multicast query, or + + [b] The sender queries for a PTR RR of a fully formed IP address + within the "in-addr.arpa" or "ip6.arpa" zones. + + Unicast LLMNR queries MUST be done using TCP and the responses MUST + be sent using the same TCP connection as the query. Senders MUST + support sending TCP queries, and responders MUST support listening + for TCP queries. If the sender of a TCP query receives a response to + that query not using TCP, the response MUST be silently discarded. + + Unicast UDP queries MUST be silently discarded. + + A unicast PTR RR query for an off-link address will not elicit a + response, but instead an ICMP TTL or Hop Limit exceeded message will + be received. An implementation receiving an ICMP message in response + to a TCP connection setup attempt can return immediately, treating + this as a response that no such name exists (RCODE=3 is returned). + An implementation that cannot process ICMP messages MAY send + multicast UDP queries for PTR RRs. Since TCP implementations will + not retransmit prior to RTOmin, a considerable period will elapse + before TCP retransmits multiple times, resulting in a long timeout + for TCP PTR RR queries sent to an off-link destination. + +2.5. "Off link" Detection + + A sender MUST select a source address for LLMNR queries that is + assigned on the interface on which the query is sent. The + destination address of an LLMNR query MUST be a link-scope multicast + address or a unicast address. + + A responder MUST select a source address for responses that is + assigned on the interface on which the query was received. The + destination address of an LLMNR response MUST be a unicast address. + + On receiving an LLMNR query, the responder MUST check whether it was + sent to a LLMNR multicast addresses defined in Section 2. If it was + sent to another multicast address, then the query MUST be silently + discarded. + + + +Aboba, Thaler & Esibov Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + Section 2.4 discusses use of TCP for LLMNR queries and responses. In + composing an LLMNR query using TCP, the sender MUST set the Hop Limit + field in the IPv6 header and the TTL field in the IPv4 header of the + response to one (1). The responder SHOULD set the TTL or Hop Limit + settings on the TCP listen socket to one (1) so that SYN-ACK packets + will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This + prevents an incoming connection from off-link since the sender will + not receive a SYN-ACK from the responder. + + For UDP queries and responses, the Hop Limit field in the IPv6 header + and the TTL field in the IPV4 header MAY be set to any value. + However, it is RECOMMENDED that the value 255 be used for + compatibility with early implementations of [RFC3927]. + + Implementation note: + + In the sockets API for IPv4 [POSIX], the IP_TTL and + IP_MULTICAST_TTL socket options are used to set the TTL of + outgoing unicast and multicast packets. The IP_RECVTTL socket + option is available on some platforms to retrieve the IPv4 TTL of + received packets with recvmsg(). [RFC2292] specifies similar + options for setting and retrieving the IPv6 Hop Limit. + +2.6. Responder Responsibilities + + It is the responsibility of the responder to ensure that RRs returned + in LLMNR responses MUST only include values that are valid on the + local interface, such as IPv4 or IPv6 addresses valid on the local + link or names defended using the mechanism described in Section 4. + IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local + addresses are defined in [RFC2373]. In particular: + + [a] If a link-scope IPv6 address is returned in a AAAA RR, + that address MUST be valid on the local link over which + LLMNR is used. + + [b] If an IPv4 address is returned, it MUST be reachable + through the link over which LLMNR is used. + + [c] If a name is returned (for example in a CNAME, MX + or SRV RR), the name MUST be resolvable on the local + link over which LLMNR is used. + + Where multiple addresses represent valid responses to a query, the + order in which the addresses are returned is as follows: + + [d] If the source address of the query is a link-scope address, + then the responder SHOULD include a link-scope address first + + + +Aboba, Thaler & Esibov Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + in the response, if available. + + [e] If the source address of the query is a routable address, + then the responder MUST include a routable address first + in the response, if available. + +2.7. Retransmission and Jitter + + An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine + when to retransmit an LLMNR query. An LLMNR sender SHOULD either + estimate the LLMNR_TIMEOUT for each interface, or set a reasonably + high initial timeout. Suggested constants are described in Section + 7. + + If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, + then a sender SHOULD repeat the transmission of the query in order to + assure that it was received by a host capable of responding to it. + An LLMNR query SHOULD NOT be sent more than three times. + + Where LLMNR queries are sent using TCP, retransmission is handled by + the transport layer. Queries with the 'C' bit set MUST be sent using + multicast UDP and MUST NOT be retransmitted. + + An LLMNR sender cannot know in advance if a query sent using + multicast will receive no response, one response, or more than one + response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response + has been received, or if it is necessary to collect all potential + responses, such as if a uniqueness verification query is being made. + Otherwise an LLMNR sender SHOULD consider a multicast query answered + after the first response is received, if that response has the 'C' + bit clear. + + However, if the first response has the 'C' bit set, then the sender + SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect + all possible responses. When multiple valid answers are received, + they may first be concatenated, and then treated in the same manner + that multiple RRs received from the same DNS server would. A unicast + query sender considers the query answered after the first response is + received. + + Since it is possible for a response with the 'C' bit clear to be + followed by a response with the 'C' bit set, an LLMNR sender SHOULD + be prepared to process additional responses for the purposes of + conflict detection, even after it has considered a query answered. + + In order to avoid synchronization, the transmission of each LLMNR + query and response SHOULD delayed by a time randomly selected from + the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by + + + +Aboba, Thaler & Esibov Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + responders responding with names which they have previously + determined to be UNIQUE (see Section 4 for details). + +2.8. DNS TTL + + The responder should insert a pre-configured TTL value in the records + returned in an LLMNR response. A default value of 30 seconds is + RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc + networks), the TTL value may need to be reduced. + + Due to the TTL minimalization necessary when caching an RRset, all + TTLs in an RRset MUST be set to the same value. + +2.9. Use of the Authority and Additional Sections + + Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a + concept of delegation. In LLMNR, the NS resource record type may be + stored and queried for like any other type, but it has no special + delegation semantics as it does in the DNS. Responders MAY have NS + records associated with the names for which they are authoritative, + but they SHOULD NOT include these NS records in the authority + sections of responses. + + Responders SHOULD insert an SOA record into the authority section of + a negative response, to facilitate negative caching as specified in + [RFC2308]. The TTL of this record is set from the minimum of the + MINIMUM field of the SOA record and the TTL of the SOA itself, and + indicates how long a resolver may cache the negative answer. The + owner name of the SOA record (MNAME) MUST be set to the query name. + The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored + by senders. Negative responses without SOA records SHOULD NOT be + cached. + + In LLMNR, the additional section is primarily intended for use by + EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, + senders MAY only include pseudo RR-types in the additional section of + a query; unless the 'C' bit is set, responders MUST ignore the + additional section of queries containing other RR types. + + In queries where the 'C' bit is set, the sender SHOULD include the + conflicting RRs in the additional section. Since conflict + notifications are advisory, responders SHOULD log information from + the additional section, but otherwise MUST ignore the additional + section. + + Senders MUST NOT cache RRs from the authority or additional section + of a response as answers, though they may be used for other purposes + such as negative caching. + + + +Aboba, Thaler & Esibov Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +3. Usage Model + + LLMNR is a peer-to-peer name resolution protocol that is not intended + as a replacement for DNS; rather, it enables name resolution in + scenarios in which conventional DNS name resolution is not possible. + This includes situations in which hosts are not configured with the + address of a DNS server; where the DNS server is unavailable or + unreachable; where there is no DNS server authoritative for the name + of a host, or where the authoritative DNS server does not have the + desired RRs. + + By default, an LLMNR sender SHOULD send LLMNR queries only for + single-label names. In order to reduce unnecessary DNS queries, stub + resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS + queries for single-label names. An LLMNR sender SHOULD NOT be + enabled to send a query for any name, except where security + mechanisms (described in Section 5.3) can be utilized. + + Regardless of whether security mechanisms can be utilized, LLMNR + queries SHOULD NOT be sent unless one of the following conditions are + met: + + [1] No manual or automatic DNS configuration has been performed. + If DNS server address(es) have been configured, a + host SHOULD attempt to reach DNS servers over all protocols + on which DNS server address(es) are configured, prior to sending + LLMNR queries. For dual stack hosts configured with DNS server + address(es) for one protocol but not another, this implies that + DNS queries SHOULD be sent over the protocol configured with + a DNS server, prior to sending LLMNR queries. + + [2] All attempts to resolve the name via DNS on all interfaces + have failed after exhausting the searchlist. This can occur + because DNS servers did not respond, or because they + responded to DNS queries with RCODE=3 (Authoritative Name + Error) or RCODE=0, and an empty answer section. Where a + single resolver call generates DNS queries for A and AAAA RRs, + an implementation MAY choose not to send LLMNR queries if any + of the DNS queries is successful. An LLMNR query SHOULD only + be sent for the originally requested name; a searchlist + is not used to form additional LLMNR queries. + + Since LLMNR is a secondary name resolution mechanism, its usage is in + part determined by the behavior of DNS implementations. In general, + robust DNS resolver implementations are more likely to avoid + unnecessary LLMNR queries. + + As noted in [DNSPerf], even when DNS servers are configured, a + + + +Aboba, Thaler & Esibov Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + significant fraction of DNS queries do not receive a response, or + result in negative responses due to missing inverse mappings or NS + records that point to nonexistent or inappropriate hosts. This has + the potential to result in a large number of unnecessary LLMNR + queries. + + [RFC1536] describes common DNS implementation errors and fixes. If + the proposed fixes are implemented, unnecessary LLMNR queries will be + reduced substantially, and so implementation of [RFC1536] is + recommended. + + For example, [RFC1536] Section 1 describes issues with retransmission + and recommends implementation of a retransmission policy based on + round trip estimates, with exponential back-off. [RFC1536] Section 4 + describes issues with failover, and recommends that resolvers try + another server when they don't receive a response to a query. These + policies are likely to avoid unnecessary LLMNR queries. + + [RFC1536] Section 3 describes zero answer bugs, which if addressed + will also reduce unnecessary LLMNR queries. + + [RFC1536] Section 6 describes name error bugs and recommended + searchlist processing that will reduce unnecessary RCODE=3 + (authoritative name) errors, thereby also reducing unnecessary LLMNR + queries. + + If error responses are received from both DNS and LLMNR, then the + lowest RCODE value should be returned. For example, if either DNS or + LLMNR receives a response with RCODE=0, then this should returned to + the caller. + +3.1. LLMNR Configuration + + LLMNR usage MAY be configured manually or automatically on a per + interface basis. By default, LLMNR responders SHOULD be enabled on + all interfaces, at all times. Enabling LLMNR for use in situations + where a DNS server has been configured will result in a change in + default behavior without a simultaneous update to configuration + information. Where this is considered undesirable, LLMNR SHOULD NOT + be enabled by default, so that hosts will neither listen on the link- + scope multicast address, nor will they send queries to that address. + + Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is + possible for a dual stack host to be configured with the address of a + DNS server over IPv4, while remaining unconfigured with a DNS server + suitable for use over IPv6. + + In these situations, a dual stack host will send AAAA queries to the + + + +Aboba, Thaler & Esibov Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + configured DNS server over IPv4. However, an IPv6-only host + unconfigured with a DNS server suitable for use over IPv6 will be + unable to resolve names using DNS. Automatic IPv6 DNS configuration + mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely + deployed, and not all DNS servers support IPv6. Therefore lack of + IPv6 DNS configuration may be a common problem in the short term, and + LLMNR may prove useful in enabling link-local name resolution over + IPv6. + + Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], + IPv6-only hosts may not be configured with a DNS server. Where there + is no DNS server authoritative for the name of a host or the + authoritative DNS server does not support dynamic client update over + IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not + be able to do DNS dynamic update, and other hosts will not be able to + resolve its name. + + For example, if the configured DNS server responds to a AAAA RR query + sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or + RCODE=0 and an empty answer section, then a AAAA RR query sent using + LLMNR over IPv6 may be successful in resolving the name of an + IPv6-only host on the local link. + + Similarly, if a DHCPv4 server is available providing DNS server + configuration, and DNS server(s) exist which are authoritative for + the A RRs of local hosts and support either dynamic client update + over IPv4 or DHCPv4-based dynamic update, then the names of local + IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no + DNS server is authoritative for the names of local hosts, or the + authoritative DNS server(s) do not support dynamic update, then LLMNR + enables linklocal name resolution over IPv4. + + Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to + configure LLMNR on an interface. The LLMNR Enable Option, described + in [LLMNREnable], can be used to explicitly enable or disable use of + LLMNR on an interface. The LLMNR Enable Option does not determine + whether or in which order DNS itself is used for name resolution. + The order in which various name resolution mechanisms should be used + can be specified using the Name Service Search Option (NSSO) for DHCP + [RFC2937], using the LLMNR Enable Option code carried in the NSSO + data. + + It is possible that DNS configuration mechanisms will go in and out + of service. In these circumstances, it is possible for hosts within + an administrative domain to be inconsistent in their DNS + configuration. + + For example, where DHCP is used for configuring DNS servers, one or + + + +Aboba, Thaler & Esibov Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + more DHCP servers can fail. As a result, hosts configured prior to + the outage will be configured with a DNS server, while hosts + configured after the outage will not. Alternatively, it is possible + for the DNS configuration mechanism to continue functioning while + configured DNS servers fail. + + An outage in the DNS configuration mechanism may result in hosts + continuing to use LLMNR even once the outage is repaired. Since + LLMNR only enables linklocal name resolution, this represents a + degradation in capabilities. As a result, hosts without a configured + DNS server may wish to periodically attempt to obtain DNS + configuration if permitted by the configuration mechanism in use. In + the absence of other guidance, a default retry interval of one (1) + minute is RECOMMENDED. + +4. Conflict Resolution + + By default, a responder SHOULD be configured to behave as though its + name is UNIQUE on each interface on which LLMNR is enabled. However, + it is also possible to configure multiple responders to be + authoritative for the same name. For example, multiple responders + MAY respond to a query for an A or AAAA type record for a cluster + name (assigned to multiple hosts in the cluster). + + To detect duplicate use of a name, an administrator can use a name + resolution utility which employs LLMNR and lists both responses and + responders. This would allow an administrator to diagnose behavior + and potentially to intervene and reconfigure LLMNR responders who + should not be configured to respond to the same name. + +4.1. Uniqueness Verification + + Prior to sending an LLMNR response with the 'T' bit clear, a + responder configured with a UNIQUE name MUST verify that there is no + other host within the scope of LLMNR query propagation that is + authoritative for the same name on that interface. + + Once a responder has verified that its name is UNIQUE, if it receives + an LLMNR query for that name, with the 'C' bit clear, it MUST + respond, with the 'T' bit clear. Prior to verifying that its name is + UNIQUE, a responder MUST set the 'T' bit in responses. + + Uniqueness verification is carried out when the host: + + - starts up or is rebooted + - wakes from sleep (if the network interface was inactive + during sleep) + - is configured to respond to LLMNR queries on an interface + + + +Aboba, Thaler & Esibov Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + enabled for transmission and reception of IP traffic + - is configured to respond to LLMNR queries using additional + UNIQUE resource records + - verifies the acquisition of a new IP address and configuration + on an interface + + To verify uniqueness, a responder MUST send an LLMNR query with the + 'C' bit clear, over all protocols on which it responds to LLMNR + queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify + uniqueness of a name by sending a query for the name with type='ANY'. + + If no response is received, the sender retransmits the query, as + specified in Section 2.7. If a response is received, the sender MUST + check if the source address matches the address of any of its + interfaces; if so, then the response is not considered a conflict, + since it originates from the sender. To avoid triggering conflict + detection, a responder that detects that it is connected to the same + link on multiple interfaces SHOULD set the 'C' bit in responses. + + If a response is received with the 'T' bit clear, the responder MUST + NOT use the name in response to LLMNR queries received over any + protocol (IPv4 or IPv6). If a response is received with the 'T' bit + set, the responder MUST check if the source IP address in the + response, interpreted as an unsigned integer, is less than the source + IP address in the query. If so, the responder MUST NOT use the name + in response to LLMNR queries received over any protocol (IPv4 or + IPv6). For the purpose of uniqueness verification, the contents of + the answer section in a response is irrelevant. + + Periodically carrying out uniqueness verification in an attempt to + detect name conflicts is not necessary, wastes network bandwidth, and + may actually be detrimental. For example, if network links are + joined only briefly, and are separated again before any new + communication is initiated, temporary conflicts are benign and no + forced reconfiguration is required. LLMNR responders SHOULD NOT + periodically attempt uniqueness verification. + +4.2. Conflict Detection and Defense + + Hosts on disjoint network links may configure the same name for use + with LLMNR. If these separate network links are later joined or + bridged together, then there may be multiple hosts which are now on + the same link, trying to use the same name. + + In order to enable ongoing detection of name conflicts, when an LLMNR + sender receives multiple LLMNR responses to a query, it MUST check if + the 'C' bit is clear in any of the responses. If so, the sender + SHOULD send another query for the same name, type and class, this + + + +Aboba, Thaler & Esibov Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + time with the 'C' bit set, with the potentially conflicting resource + records included in the additional section. + + Queries with the 'C' bit set are considered advisory and responders + MUST verify the existence of a conflict before acting on it. A + responder receiving a query with the 'C' bit set MUST NOT respond. + + If the query is for a UNIQUE name, then the responder MUST send its + own query for the same name, type and class, with the 'C' bit clear. + If a response is received, the sender MUST check if the source + address matches the address of any of its interfaces; if so, then the + response is not considered a conflict, since it originates from the + sender. To avoid triggering conflict detection, a responder that + detects that it is connected to the same link on multiple interfaces + SHOULD set the 'C' bit in responses. + + An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD + log them. Upon detecting a conflict, an LLMNR responder MUST + immediately stop using the conflicting name in response to LLMNR + queries received over any supported protocol, if the source IP + address in the response, interpreted as an unsigned integer, is less + than the source IP address in the uniqueness verification query. + + After stopping the use of a name, the responder MAY elect to + configure a new name. However, since name reconfiguration may be + disruptive, this is not required, and a responder may have been + configured to respond to multiple names so that alternative names may + already be available. A host that has stopped the use of a name may + attempt uniqueness verification again after the expiration of the TTL + of the conflicting response. + +4.3. Considerations for Multiple Interfaces + + A multi-homed host may elect to configure LLMNR on only one of its + active interfaces. In many situations this will be adequate. + However, should a host need to configure LLMNR on more than one of + its active interfaces, there are some additional precautions it MUST + take. Implementers who are not planning to support LLMNR on multiple + interfaces simultaneously may skip this section. + + Where a host is configured to issue LLMNR queries on more than one + interface, each interface maintains its own independent LLMNR + resolver cache, containing the responses to LLMNR queries. + + A multi-homed host checks the uniqueness of UNIQUE records as + described in Section 4. The situation is illustrated in figure 1. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + Figure 1. Link-scope name conflict + + In this situation, the multi-homed myhost will probe for, and defend, + its host name on both interfaces. A conflict will be detected on one + interface, but not the other. The multi-homed myhost will not be + able to respond with a host RR for "myhost" on the interface on the + right (see Figure 1). The multi-homed host may, however, be + configured to use the "myhost" name on the interface on the left. + + Since names are only unique per-link, hosts on different links could + be using the same name. If an LLMNR client sends requests over + multiple interfaces, and receives replies from more than one, the + result returned to the client is defined by the implementation. The + situation is illustrated in figure 2. + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + Figure 2. Off-segment name conflict + + If host myhost is configured to use LLMNR on both interfaces, it will + send LLMNR queries on both interfaces. When host myhost sends a + query for the host RR for name "A" it will receive a response from + hosts on both interfaces. + + Host myhost cannot distinguish between the situation shown in Figure + 2, and that shown in Figure 3 where no conflict exists. + + [A] + | | + ----- ----- + | | + [myhost] + + Figure 3. Multiple paths to same host + + This illustrates that the proposed name conflict resolution mechanism + does not support detection or resolution of conflicts between hosts + on different links. This problem can also occur with DNS when a + multi-homed host is connected to two different networks with + separated name spaces. It is not the intent of this document to + address the issue of uniqueness of names within DNS. + + + +Aboba, Thaler & Esibov Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +4.4. API Issues + + [RFC2553] provides an API which can partially solve the name + ambiguity problem for applications written to use this API, since the + sockaddr_in6 structure exposes the scope within which each scoped + address exists, and this structure can be used for both IPv4 (using + v4-mapped IPv6 addresses) and IPv6 addresses. + + Following the example in Figure 2, an application on 'myhost' issues + the request getaddrinfo("A", ...) with ai_family=AF_INET6 and + ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both + interfaces and the resolver library will return a list containing + multiple addrinfo structures, each with an associated sockaddr_in6 + structure. This list will thus contain the IPv4 and IPv6 addresses + of both hosts responding to the name 'A'. Link-local addresses will + have a sin6_scope_id value that disambiguates which interface is used + to reach the address. Of course, to the application, Figures 2 and 3 + are still indistinguishable, but this API allows the application to + communicate successfully with any address in the list. + +5. Security Considerations + + LLMNR is a peer-to-peer name resolution protocol designed for use on + the local link. While LLMNR limits the vulnerability of responders + to off-link senders, it is possible for an off-link responder to + reach a sender. + + In scenarios such as public "hotspots" attackers can be present on + the same link. These threats are most serious in wireless networks + such as 802.11, since attackers on a wired network will require + physical access to the network, while wireless attackers may mount + attacks from a distance. Link-layer security such as [IEEE-802.11i] + can be of assistance against these threats if it is available. + + This section details security measures available to mitigate threats + from on and off-link attackers. + +5.1. Denial of Service + + Attackers may take advantage of LLMNR conflict detection by + allocating the same name, denying service to other LLMNR responders + and possibly allowing an attacker to receive packets destined for + other hosts. By logging conflicts, LLMNR responders can provide + forensic evidence of these attacks. + + An attacker may spoof LLMNR queries from a victim's address in order + to mount a denial of service attack. Responders setting the IPv6 Hop + Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP + + + +Aboba, Thaler & Esibov Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + response may be able to reach the victim across the Internet. + + While LLMNR responders only respond to queries for which they are + authoritative and LLMNR does not provide wildcard query support, an + LLMNR response may be larger than the query, and an attacker can + generate multiple responses to a query for a name used by multiple + responders. A sender may protect itself against unsolicited + responses by silently discarding them as rapidly as possible. + +5.2. Spoofing + + LLMNR is designed to prevent reception of queries sent by an off-link + attacker. LLMNR requires that responders receiving UDP queries check + that they are sent to a link-scope multicast address. However, it is + possible that some routers may not properly implement link-scope + multicast, or that link-scope multicast addresses may leak into the + multicast routing system. To prevent successful setup of TCP + connections by an off-link sender, responders receiving a TCP SYN + reply with a TCP SYN-ACK with TTL set to one (1). + + While it is difficult for an off-link attacker to send an LLMNR query + to a responder, it is possible for an off-link attacker to spoof a + response to a query (such as an A or AAAA query for a popular + Internet host), and by using a TTL or Hop Limit field larger than one + (1), for the forged response to reach the LLMNR sender. Since the + forged response will only be accepted if it contains a matching ID + field, choosing a pseudo-random ID field within queries provides some + protection against off-link responders. + + Since LLMNR queries can be sent when DNS server(s) do not respond, an + attacker can execute a denial of service attack on the DNS server(s) + and then poison the LLMNR cache by responding to an LLMNR query with + incorrect information. As noted in "Threat Analysis of the Domain + Name System (DNS)" [RFC3833] these threats also exist with DNS, since + DNS response spoofing tools are available that can allow an attacker + to respond to a query more quickly than a distant DNS server. + However, while switched networks or link layer security may make it + difficult for an on-link attacker to snoop unicast DNS queries, + multicast LLMNR queries are propagated to all hosts on the link, + making it possible for an on-link attacker to spoof LLMNR responses + without having to guess the value of the ID field in the query. + + Since LLMNR queries are sent and responded to on the local-link, an + attacker will need to respond more quickly to provide its own + response prior to arrival of the response from a legitimate + responder. If an LLMNR query is sent for an off-link host, spoofing + a response in a timely way is not difficult, since a legitimate + response will never be received. + + + +Aboba, Thaler & Esibov Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + This vulnerability can be reduced by limiting use of LLMNR to + resolution of single-label names as described in Section 3, or by + implementation of authentication (see Section 5.3). + +5.3. Authentication + + LLMNR is a peer-to-peer name resolution protocol, and as a result, + it is often deployed in situations where no trust model can be + assumed. Where a pre-arranged security configuration is possible, + the following security mechanisms may be used: + +[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) + [RFC2931] security mechanisms. "DNS Name Service based on Secure + Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes + the use of TSIG to secure LLMNR, based on group keys. While group + keys can be used to demonstrate membership in a group, they do not + protect against forgery by an attacker that is a member of the + group. + +[b] IPsec ESP with a null-transform MAY be used to authenticate unicast + LLMNR queries and responses or LLMNR responses to multicast + queries. In a small network without a certificate authority, this + can be most easily accomplished through configuration of a group + pre-shared key for trusted hosts. As with TSIG, this does not + protect against forgery by an attacker with access to the group + pre-shared key. + +[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to + support DNSSEC, LLMNR implementations MAY be configured with trust + anchors, or they MAY make use of keys obtained from DNS queries. + Since LLMNR does not support "delegated trust" (CD or AD bits), + LLMNR implementations cannot make use of DNSSEC unless they are + DNSSEC-aware and support validation. Unlike approaches [a] or [b], + DNSSEC permits a responder to demonstrate ownership of a name, not + just membership within a trusted group. As a result, it enables + protection against forgery. + +5.4. Cache and Port Separation + + In order to prevent responses to LLMNR queries from polluting the DNS + cache, LLMNR implementations MUST use a distinct, isolated cache for + LLMNR on each interface. The use of separate caches is most + effective when LLMNR is used as a name resolution mechanism of last + resort, since this minimizes the opportunities for poisoning the + LLMNR cache, and decreases reliance on it. + + LLMNR operates on a separate port from DNS, reducing the likelihood + that a DNS server will unintentionally respond to an LLMNR query. + + + +Aboba, Thaler & Esibov Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + If LLMNR is given higher priority than DNS among the enabled name + resolution mechanisms, a denial of service attack on the DNS server + would not be necessary in order to poison the LLMNR cache, since + LLMNR queries would be sent even when the DNS server is available. + In addition, the LLMNR cache, once poisoned, would take precedence + over the DNS cache, eliminating the benefits of cache separation. As + a result, LLMNR SHOULD NOT be used as a primary name resolution + mechanism. + +6. IANA Considerations + + LLMNR requires allocation of port 5355 for both TCP and UDP. + + LLMNR requires allocation of link-scope multicast IPv4 address + 224.0.0.252, as well as link-scope multicast IPv6 address + FF02:0:0:0:0:0:1:3. + + This specification creates two new name spaces: the LLMNR namespace + and the reserved bits in the LLMNR header. The reserved bits in the + LLMNR header are allocated by IETF Consensus, in accordance with BCP + 26 [RFC2434]. + + In order to to avoid creating any new administrative procedures, + administration of the LLMNR namespace will piggyback on the + administration of the DNS namespace. + + The rights to use a fully qualified domain name (FQDN) within LLMNR + are obtained coincident with acquiring the rights to use that name + within DNS. Those wishing to use a FQDN within LLMNR should first + acquire the rights to use the corresponding FQDN within DNS. Using a + FQDN within LLMNR without ownership of the corresponding name in DNS + creates the possibility of conflict and therefore is discouraged. + + LLMNR responders may self-allocate a name within the single-label + name space, first defined in [RFC1001]. Since single-label names are + not unique, no registration process is required. + +7. Constants + + The following timing constants are used in this protocol; they are + not intended to be user configurable. + + JITTER_INTERVAL 100 ms + LLMNR_TIMEOUT 1 second (if set statically on all interfaces) + 100 ms (IEEE 802 media, including IEEE 802.11) + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +8. References + +8.1. Normative References + +[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport: Concepts and Methods", RFC + 1001, March 1987. + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + +[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + +[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + +[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + +8.2. Informative References + +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of + Caching", IEEE/ACM Transactions on Networking, Volume 10, + Number 5, pp. 589, October 2002. + +[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + Internet draft (work in progress), draft-ietf-ipv6-dns- + discovery-07.txt, October 2002. + + + + +Aboba, Thaler & Esibov Standards Track [Page 26] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[IEEE-802.11i] + Institute of Electrical and Electronics Engineers, "Supplement + to Standard for Telecommunications and Information Exchange + Between Systems - LAN/MAN Specific Requirements - Part 11: + Wireless LAN Medium Access Control (MAC) and Physical Layer + (PHY) Specifications: Specification for Enhanced Security", + IEEE 802.11i, July 2004. + +[LLMNREnable] + Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work + in progress), draft-guttman-mdns-enable-02.txt, April 2002. + +[LLMNRSec] + Jeong, J., Park, J. and H. Kim, "DNS Name Service based on + Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT + 2004, Phoenix Park, Korea, February 9-11, 2004. + +[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December + 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + +[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic + Socket Interface Extensions for IPv6", RFC 2553, March 1999. + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + +[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + +Aboba, Thaler & Esibov Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of Link-Local IPv4 Addresses", RFC 3927, October 2004. + +[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirement", RFC 4033, March + 2005. + +Acknowledgments + + This work builds upon original work done on multicast DNS by Bill + Manning and Bill Woodcock. Bill Manning's work was funded under + DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge + their contribution to the current specification. Constructive input + has also been received from Mark Andrews, Rob Austein, Randy Bush, + Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur + Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, + Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, + Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike + St. Johns, Sander Van-Valkenburg, and Brian Zill. + +Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 706 6605 + EMail: bernarda@microsoft.com + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + Levon Esibov + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: levone@microsoft.com + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 28] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 29] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Open Issues + + Open issues with this specification are tracked on the following web + site: + + http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 30] + + + diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt new file mode 100644 index 0000000..90d1a06 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsid-01.txt @@ -0,0 +1,840 @@ + + + +Network Working Group R. Austein +Internet-Draft ISC +Expires: July 15, 2006 January 11, 2006 + + + DNS Name Server Identifier Option (NSID) + draft-ietf-dnsext-nsid-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 15, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. While existing ad-hoc + mechanism allow an operator to send follow-up queries when it is + necessary to debug such a configuration, the only completely reliable + way to obtain the identity of the name server which responded is to + have the name server include this information in the response itself. + This note defines a protocol extension to support this functionality. + + + +Austein Expires July 15, 2006 [Page 1] + +Internet-Draft DNS NSID January 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4 + 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 + 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 + 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8 + 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8 + 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 2] + +Internet-Draft DNS NSID January 2006 + + +1. Introduction + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. + + Existing ad-hoc mechanisms allow an operator to send follow-up + queries when it is necessary to debug such a configuration, but there + are situations in which this is not a totally satisfactory solution, + since anycast routing may have changed, or the server pool in + question may be behind some kind of extremely dynamic load balancing + hardware. Thus, while these ad-hoc mechanisms are certainly better + than nothing (and have the advantage of already being deployed), a + better solution seems desirable. + + Given that a DNS query is an idempotent operation with no retained + state, it would appear that the only completely reliable way to + obtain the identity of the name server which responded to a + particular query is to have that name server include identifying + information in the response itself. This note defines a protocol + enhancement to achieve this. + +1.1. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 3] + +Internet-Draft DNS NSID January 2006 + + +2. Protocol + + This note uses an EDNS [RFC2671] option to signal the resolver's + desire for information identifying the name server and to hold the + name server's response, if any. + +2.1. Resolver Behavior + + A resolver signals its desire for information identifying a name + server by sending an empty NSID option (Section 2.3) in an EDNS OPT + pseudo-RR in the query message. + + The resolver MUST NOT include any NSID payload data in the query + message. + + The semantics of an NSID request are not transitive. That is: the + presence of an NSID option in a query is a request that the name + server which receives the query identify itself. If the name server + side of a recursive name server receives an NSID request, the client + is asking the recursive name server to identify itself; if the + resolver side of the recursive name server wishes to receive + identifying information, it is free to add NSID requests in its own + queries, but that is a separate matter. + +2.2. Name Server Behavior + + A name server which understands the NSID option and chooses to honor + a particular NSID request responds by including identifying + information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR + in the response message. + + The name server MUST ignore any NSID payload data that might be + present in the query message. + + The NSID option is not transitive. A name server MUST NOT send an + NSID option back to a resolver which did not request it. In + particular, while a recursive name server may choose to add an NSID + option when sending a query, this has no effect on the presence or + absence of the NSID option in the recursive name server's response to + the original client. + + As stated in Section 2.1, this mechanism is not restricted to + authoritative name servers; the semantics are intended to be equally + applicable to recursive name servers. + +2.3. The NSID Option + + The OPTION-CODE for the NSID option is [TBD]. + + + +Austein Expires July 15, 2006 [Page 4] + +Internet-Draft DNS NSID January 2006 + + + The OPTION-DATA for the NSID option is an opaque byte string the + semantics of which are deliberately left outside the protocol. See + Section 3.1 for discussion. + +2.4. Presentation Format + + User interfaces MUST read and write the content of the NSID option as + a sequence of hexadecimal digits, two digits per payload octet. + + The NSID payload is binary data. Any comparison between NSID + payloads MUST be a comparison of the raw binary data. Copy + operations MUST NOT assume that the raw NSID payload is null- + terminated. Any resemblance between raw NSID payload data and any + form of text is purely a convenience, and does not change the + underlying nature of the payload data. + + See Section 3.3 for discussion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 5] + +Internet-Draft DNS NSID January 2006 + + +3. Discussion + + This section discusses certain aspects of the protocol and explains + considerations that led to the chosen design. + +3.1. The NSID Payload + + The syntax and semantics of the content of the NSID option is + deliberately left outside the scope of this specification. This + section describe some of the kinds of data that server administrators + might choose to provide as the content of the NSID option, and + explains the reasoning behind choosing a simple opaque byte string. + + There are several possibilities for the payload of the NSID option: + + o It could be the "real" name of the specific name server within the + name server pool. + + o It could be the "real" IP address (IPv4 or IPv6) of the name + server within the name server pool. + + o It could be some sort of pseudo-random number generated in a + predictable fashion somehow using the server's IP address or name + as a seed value. + + o It could be some sort of probabilisticly unique identifier + initially derived from some sort of random number generator then + preserved across reboots of the name server. + + o It could be some sort of dynamicly generated identifier so that + only the name server operator could tell whether or not any two + queries had been answered by the same server. + + o It could be a blob of signed data, with a corresponding key which + might (or might not) be available via DNS lookups. + + o It could be a blob of encrypted data, the key for which could be + restricted to parties with a need to know (in the opinion of the + server operator). + + o It could be an arbitrary string of octets chosen at the discretion + of the name server operator. + + Each of these options has advantages and disadvantages: + + o Using the "real" name is simple, but the name server may not have + a "real" name. + + + + +Austein Expires July 15, 2006 [Page 6] + +Internet-Draft DNS NSID January 2006 + + + o Using the "real" address is also simple, and the name server + almost certainly does have at least one non-anycast IP address for + maintenance operations, but the operator of the name server may + not be willing to divulge its non-anycast address. + + o Given that one common reason for using anycast DNS techniques is + an attempt to harden a critical name server against denial of + service attacks, some name server operators are likely to want an + identifier other than the "real" name or "real" address of the + name server instance. + + o Using a hash or pseudo-random number can provide a fixed length + value that the resolver can use to tell two name servers apart + without necessarily being able to tell where either one of them + "really" is, but makes debugging more difficult if one happens to + be in a friendly open environment. Furthermore, hashing might not + add much value, since a hash based on an IPv4 address still only + involves a 32-bit search space, and DNS names used for servers + that operators might have to debug at 4am tend not to be very + random. + + o Probabilisticly unique identifiers have similar properties to + hashed identifiers, but (given a sufficiently good random number + generator) are immune to the search space issues. However, the + strength of this approach is also its weakness: there is no + algorithmic transformation by which even the server operator can + associate name server instances with identifiers while debugging, + which might be annoying. This approach also requires the name + server instance to preserve the probabilisticly unique identifier + across reboots, but this does not appear to be a serious + restriction, since authoritative nameservers almost always have + some form of nonvolatile storage in any case, and in the rare case + of a name server that does not have any way to store such an + identifier, nothing terrible will happen if the name server just + generates a new identifier every time it reboots. + + o Using an arbitrary octet string gives name server operators yet + another thing to configure, or mis-configure, or forget to + configure. Having all the nodes in an anycast name server + constellation identify themselves as "My Name Server" would not be + particularly useful. + + Given all of the issues listed above, there does not appear to be a + single solution that will meet all needs. Section 2.3 therefore + defines the NSID payload to be an opaque byte string and leaves the + choice up to the implementor and name server operator. The following + guidelines may be useful to implementors and server operators: + + + + +Austein Expires July 15, 2006 [Page 7] + +Internet-Draft DNS NSID January 2006 + + + o Operators for whom divulging the unicast address is an issue could + use the raw binary representation of a probabilisticly unique + random number. This should probably be the default implementation + behavior. + + o Operators for whom divulging the unicast address is not an issue + could just use the raw binary representation of a unicast address + for simplicity. This should only be done via an explicit + configuration choice by the operator. + + o Operators who really need or want the ability to set the NSID + payload to an arbitrary value could do so, but this should only be + done via an explicit configuration choice by the operator. + + This approach appears to provide enough information for useful + debugging without unintentionally leaking the maintenance addresses + of anycast name servers to nogoodniks, while also allowing name + server operators who do not find such leakage threatening to provide + more information at their own discretion. + +3.2. NSID Is Not Transitive + + As specified in Section 2.1 and Section 2.2, the NSID option is not + transitive. This is strictly a hop-by-hop mechanism. + + Most of the discussion of name server identification to date has + focused on identifying authoritative name servers, since the best + known cases of anycast name servers are a subset of the name servers + for the root zone. However, given that anycast DNS techniques are + also applicable to recursive name servers, the mechanism may also be + useful with recursive name servers. The hop-by-hop semantics support + this. + + While there might be some utility in having a transitive variant of + this mechanism (so that, for example, a stub resolver could ask a + recursive server to tell it which authoritative name server provided + a particular answer to the recursive name server), the semantics of + such a variant would be more complicated, and are left for future + work. + +3.3. User Interface Issues + + Given the range of possible payload contents described in + Section 3.1, it is not possible to define a single presentation + format for the NSID payload that is efficient, convenient, + unambiguous, and aesthetically pleasing. In particular, while it is + tempting to use a presentation format that uses some form of textual + strings, attempting to support this would significantly complicate + + + +Austein Expires July 15, 2006 [Page 8] + +Internet-Draft DNS NSID January 2006 + + + what's intended to be a very simple debugging mechanism. + + In some cases the content of the NSID payload may be binary data + meaningful only to the name server operator, and may not be + meaningful to the user or application, but the user or application + must be able to capture the entire content anyway in order for it to + be useful. Thus, the presentation format must support arbitrary + binary data. + + In cases where the name server operator derives the NSID payload from + textual data, a textual form such as US-ASCII or UTF-8 strings might + at first glance seem easier for a user to deal with. There are, + however, a number of complex issues involving internationalized text + which, if fully addressed here, would require a set of rules + significantly longer than the rest of this specification. See + [RFC2277] for an overview of some of these issues. + + It is much more important for the NSID payload data to be passed + unambiguously from server administrator to user and back again than + it is for the payload data data to be pretty while in transit. In + particular, it's critical that it be straightforward for a user to + cut and paste an exact copy of the NSID payload output by a debugging + tool into other formats such as email messages or web forms without + distortion. Hexadecimal strings, while ugly, are also robust. + +3.4. Truncation + + In some cases, adding the NSID option to a response message may + trigger message truncation. This specification does not change the + rules for DNS message truncation in any way, but implementors will + need to pay attention to this issue. + + Including the NSID option in a response is always optional, so this + specification never requires name servers to truncate response + messages. + + By definition, a resolver that requests NSID responses also supports + EDNS, so a resolver that requests NSID responses can also use the + "sender's UDP payload size" field of the OPT pseudo-RR to signal a + receive buffer size large enough to make truncation unlikely. + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 9] + +Internet-Draft DNS NSID January 2006 + + +4. IANA Considerations + + This mechanism requires allocation of one ENDS option code for the + NSID option (Section 2.3). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 10] + +Internet-Draft DNS NSID January 2006 + + +5. Security Considerations + + This document describes a channel signaling mechanism, intended + primarily for debugging. Channel signaling mechanisms are outside + the scope of DNSSEC per se. Applications that require integrity + protection for the data being signaled will need to use a channel + security mechanism such as TSIG [RFC2845]. + + Section 3.1 discusses a number of different kinds of information that + a name server operator might choose to provide as the value of the + NSID option. Some of these kinds of information are security + sensitive in some environments. This specification deliberately + leaves the syntax and semantics of the NSID option content up to the + implementation and the name server operator. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 11] + +Internet-Draft DNS NSID January 2006 + + +6. Acknowledgements + + Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve + Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg, + Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and + Suzanne Woolf. Apologies to anyone inadvertently omitted from the + above list. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 12] + +Internet-Draft DNS NSID January 2006 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + +7.2. Informative References + + [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and + Languages", RFC 2277, BCP 18, January 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 13] + +Internet-Draft DNS NSID January 2006 + + +Author's Address + + Rob Austein + ISC + 950 Charter Street + Redwood City, CA 94063 + USA + + Email: sra@isc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 14] + +Internet-Draft DNS NSID January 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Austein Expires July 15, 2006 [Page 15] + diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt new file mode 100644 index 0000000..e169da8 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt @@ -0,0 +1,464 @@ + +INTERNET-DRAFT DSA Information in the DNS +OBSOLETES: RFC 2536 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: September 2006 March 2006 + + + DSA Keying and Signature Information in the DNS + --- ------ --- --------- ----------- -- --- --- + + 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 as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Abstract + + The standard method of encoding US Government Digital Signature + Algorithm keying and signature information for use in the Domain Name + System is specified. + + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DSA Information in the DNS + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DSA Keying Information..................................3 + 3. DSA Signature Information...............................4 + 4. Performance Considerations..............................4 + 5. Security Considerations.................................5 + 6. IANA Considerations.....................................5 + Copyright, Disclaimer, and Additional IPR Provisions.......5 + + Normative References.......................................7 + Informative References.....................................7 + + Author's Address...........................................8 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DSA Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC 4033, 4034, 4035] and additional work is underway which would + require the storage of keying and signature information in the DNS. + + This document describes how to encode US Government Digital Signature + Algorithm (DSA) keys and signatures in the DNS. Familiarity with the + US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier]. + + + +2. DSA Keying Information + + When DSA public keys are stored in the DNS, the structure of the + relevant part of the RDATA part of the RR being used is the fields + listed below in the order given. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR such as RRSIG which signs + and authenticates the RR containing the keying information. + + Field Size + ----- ---- + T 1 octet + Q 20 octets + P 64 + T*8 octets + G 64 + T*8 octets + Y 64 + T*8 octets + + As described in [FIPS 186-2] and [Schneier], T is a key size + parameter chosen such that 0 <= T <= 8. (The meaning if the T octet + is greater than 8 is reserved and the remainder of the data may have + a different format in that case.) Q is a prime number selected at + key generation time such that 2**159 < Q < 2**160. Thus Q is always + 20 octets long and, as with all other fields, is stored in "big- + endian" network order. P, G, and Y are calculated as directed by the + [FIPS 186-2] key generation algorithm [Schneier]. P is in the range + 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G + and Y are quantities modulo P and so can be up to the same length as + P and are allocated fixed size fields with the same number of octets + as P. + + During the key generation process, a random number X must be + generated such that 1 <= X <= Q-1. X is the private key and is used + in the final step of public key generation where Y is computed as + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DSA Information in the DNS + + + Y = G**X mod P + + + +3. DSA Signature Information + + The portion of the RDATA area used for US Digital Signature Algorithm + signature information is shown below with fields in the order they + are listed and the contents of each multi-octet field in "big-endian" + network order. + + Field Size + ----- ---- + T 1 octet + R 20 octets + S 20 octets + + First, the data signed must be determined. Then the following steps + are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as + specified in the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate a random K such that 0 < K < Q. + + R = ( G**K mod P ) mod Q + + S = ( K**(-1) * (hash + X*R) ) mod Q + + For information on the SHA-1 hash function see [FIPS 180-2] and [RFC + 3174]. + + Since Q is 160 bits long, R and S can not be larger than 20 octets, + which is the space allocated. + + T is copied from the public key. It is not logically necessary in + the SIG but is present so that values of T > 8 can more conveniently + be used as an escape for extended versions of DSA or other algorithms + as later standardized. + + + +4. Performance Considerations + + General signature generation speeds are roughly the same for RSA [RFC + 3110] and DSA. With sufficient pre-computation, signature generation + with DSA is faster than RSA. Key generation is also faster for DSA. + However, signature verification is an order of magnitude slower than + RSA when the RSA public exponent is chosen to be small, as is + recommended for some applications. + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DSA Information in the DNS + + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient, it + is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying and/or signature + inforamtion consistent with adequate security. + + + +5. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + The key size limitation of a maximum of 1024 bits ( T = 8 ) in the + current DSA standard may limit the security of DSA. For particular + applications, implementors are encouraged to consider the range of + available algorithms and key sizes. + + DSA assumes the ability to frequently generate high quality random + numbers. See [random] for guidance. DSA is designed so that if + biased rather than random numbers are used, high bandwidth covert + channels are possible. See [Schneier] and more recent research. The + leakage of an entire DSA private key in only two DSA signatures has + been demonstrated. DSA provides security only if trusted + implementations, including trusted random number generation, are + used. + + + +6. IANA Considerations + + Allocation of meaning to values of the T parameter that are not + defined herein (i.e., > 8 ) requires an IETF standards actions. It + is intended that values unallocated herein be used to cover future + extensions of the DSS standard. + + + +Copyright, Disclaimer, and Additional IPR Provisions + + Copyright (C) The Internet Society (2006). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DSA Information in the DNS + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DSA Information in the DNS + + +Normative References + + [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital + Signature Standard, 27 January 2000. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Informative References + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, 11/01/1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, 11/01/1987. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS)", D. Eastlake 3rd. May 2001. + + [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. + Jones, September 2001. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. + + [Schneier] - "Applied Cryptography Second Edition: protocols, + algorithms, and source code in C" (second edition), Bruce Schneier, + 1996, John Wiley and Sons, ISBN 0-471-11709-9. + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DSA Information in the DNS + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Labortories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554(w) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in September 2006. + + Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt new file mode 100644 index 0000000..f6e8588 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt @@ -0,0 +1,580 @@ + +INTERNET-DRAFT Diffie-Hellman Information in the DNS +OBSOLETES: RFC 2539 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: September 2006 March 2006 + + + + + Storage of Diffie-Hellman Keying Information in the DNS + ------- -- -------------- ------ ----------- -- --- --- + + + + +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 as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for encoding Diffie-Hellman keys in the Domain + Name System is specified. + + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Acknowledgements + + Part of the format for Diffie-Hellman keys and the description + thereof was taken from a work in progress by Ashar Aziz, Tom Markson, + and Hemma Prafullchandra. In addition, the following persons + provided useful comments that were incorporated into the predecessor + of this document: Ran Atkinson, Thomas Narten. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 1.1 About This Document....................................3 + 1.2 About Diffie-Hellman...................................3 + 2. Encoding Diffie-Hellman Keying Information..............4 + 3. Performance Considerations..............................5 + 4. IANA Considerations.....................................5 + 5. Security Considerations.................................5 + Copyright, Disclaimer, and Additional IPR Provisions.......5 + + Normative References.......................................7 + Informative Refences.......................................7 + + Author's Address...........................................8 + Expiration and File Name...................................8 + + Appendix A: Well known prime/generator pairs...............9 + A.1. Well-Known Group 1: A 768 bit prime..................9 + A.2. Well-Known Group 2: A 1024 bit prime.................9 + A.3. Well-Known Group 3: A 1536 bit prime................10 + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + similar information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC 4033, 4034, 4035] and additonal work is underway which would use + the storage of keying information in the DNS. + + + +1.1 About This Document + + This document describes how to store Diffie-Hellman keys in the DNS. + Familiarity with the Diffie-Hellman key exchange algorithm is assumed + [Schneier, RFC 2631]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + + + +1.2 About Diffie-Hellman + + Diffie-Hellman requires two parties to interact to derive keying + information which can then be used for authentication. Thus Diffie- + Hellman is inherently a key agreement algorithm. As a result, no + format is defined for Diffie-Hellman "signature information". For + example, assume that two parties have local secrets "i" and "j". + Assume they each respectively calculate X and Y as follows: + + X = g**i ( mod p ) + + Y = g**j ( mod p ) + + They exchange these quantities and then each calculates a Z as + follows: + + Zi = Y**i ( mod p ) + + Zj = X**j ( mod p ) + + Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared + secret between the two parties that an adversary who does not know i + or j will not be able to learn from the exchanged messages (unless + the adversary can derive i or j by performing a discrete logarithm + mod p which is hard for strong p and g). + + The private key for each party is their secret i (or j). The public + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + key is the pair p and g, which is the same for both parties, and + their individual X (or Y). + + For further information about Diffie-Hellman and precautions to take + in deciding on a p and g, see [RFC 2631]. + + + +2. Encoding Diffie-Hellman Keying Information + + When Diffie-Hellman keys appear within the RDATA portion of a RR, + they are encoded as shown below. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR such as RRSIG which signs + and authenticates the RR containing the keying information. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEY flags | protocol | algorithm=2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | prime length (or flag) | prime (p) (or special) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / prime (p) (variable length) | generator length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | generator (g) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | public value length | public value (variable length)/ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / public value (g^i mod p) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Prime length is the length of the Diffie-Hellman prime (p) in bytes + if it is 16 or greater. Prime contains the binary representation of + the Diffie-Hellman prime with most significant byte first (i.e., in + network order). If "prime length" field is 1 or 2, then the "prime" + field is actually an unsigned index into a table of 65,536 + prime/generator pairs and the generator length SHOULD be zero. See + Appedix A for defined table entries and Section 4 for information on + allocating additional table entries. The meaning of a zero or 3 + through 15 value for "prime length" is reserved. + + Generator length is the length of the generator (g) in bytes. + Generator is the binary representation of generator with most + significant byte first. PublicValueLen is the Length of the Public + Value (g**i (mod p)) in bytes. PublicValue is the binary + representation of the DH public value with most significant byte + first. + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +3. Performance Considerations + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient. But + it is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying information consistent + with adequate security. + + + +4. IANA Considerations + + Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires + an IETF consensus as defined in [RFC 2434]. + + Well known prime/generator pairs number 0x0000 through 0x07FF can + only be assigned by an IETF standards action. [RFC 2539], the + Proposed Standard predecessor of this document, assigned 0x0001 + through 0x0002. This document additionally assigns 0x0003. Pairs + number 0s0800 through 0xBFFF can be assigned based on RFC + documentation. Pairs number 0xC000 through 0xFFFF are available for + private use and are not centrally coordinated. Use of such private + pairs outside of a closed environment may result in conflicts and/or + security failures. + + + +5. Security Considerations + + Keying information retrieved from the DNS should not be trusted + unless (1) it has been securely obtained from a secure resolver or + independently verified by the user and (2) this secure resolver and + secure obtainment or independent verification conform to security + policies acceptable to the user. As with all cryptographic + algorithms, evaluating the necessary strength of the key is important + and dependent on security policy. + + In addition, the usual Diffie-Hellman key strength considerations + apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p + SHOULD be "large", etc. See [RFC 2631, Schneier]. + + + +Copyright, Disclaimer, and Additional IPR Provisions + + Copyright (C) The Internet Society (2006). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Normative References + + [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2434] - "Guidelines for Writing an IANA Considerations Section + in RFCs", T. Narten, H. Alvestrand, October 1998. + + [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June + 1999. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Informative Refences + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, November 1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, November 1987. + + [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley + and Sons. + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in September 2006. + + Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Appendix A: Well known prime/generator pairs + + These numbers are copied from the IPSEC effort where the derivation + of these values is more fully explained and additional information is + available. Richard Schroeppel performed all the mathematical and + computational work for this appendix. + + + +A.1. Well-Known Group 1: A 768 bit prime + + The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its + decimal value is + 155251809230070893513091813125848175563133404943451431320235 + 119490296623994910210725866945387659164244291000768028886422 + 915080371891804634263272761303128298374438082089019628850917 + 0691316593175367469551763119843371637221007210577919 + + Prime modulus: Length (32 bit words): 24, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + +A.2. Well-Known Group 2: A 1024 bit prime + + The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. + Its decimal value is + 179769313486231590770839156793787453197860296048756011706444 + 423684197180216158519368947833795864925541502180565485980503 + 646440548199239100050792877003355816639229553136239076508735 + 759914822574862575007425302077447712589550957937778424442426 + 617334727629299387668709205606050270810842907692932019128194 + 467627007 + + Prime modulus: Length (32 bit words): 32, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 + FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +A.3. Well-Known Group 3: A 1536 bit prime + + The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. + Its decimal value is + 241031242692103258855207602219756607485695054850245994265411 + 694195810883168261222889009385826134161467322714147790401219 + 650364895705058263194273070680500922306273474534107340669624 + 601458936165977404102716924945320037872943417032584377865919 + 814376319377685986952408894019557734611984354530154704374720 + 774996976375008430892633929555996888245787241299381012913029 + 459299994792636526405928464720973038494721168143446471443848 + 8520940127459844288859336526896320919633919 + + Prime modulus Length (32 bit words): 48, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D + C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F + 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D + 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt new file mode 100644 index 0000000..8f84fd4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt @@ -0,0 +1,480 @@ + + + + + + +DNSEXT Working Group Paul Vixie, ISC +INTERNET-DRAFT + March 17, 2008 + +Intended Status: Standards Track +Obsoletes: 2671 (if approved) + + + Revised extension mechanisms for DNS (EDNS0) + + +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 IETF Trust (2007). + + + Abstract + + The Domain Name System's wire protocol includes a number of fixed + fields whose range has been or soon will be exhausted and does not + allow clients to advertise their capabilities to servers. This + document describes backward compatible mechanisms for allowing the + protocol to grow. + + + +Expires September 2008 [Page 1] + +INTERNET-DRAFT EDNS0 March 2008 + + +1 - Introduction + +1.1. DNS (see [RFC1035]) specifies a Message Format and within such +messages there are standard formats for encoding options, errors, and +name compression. The maximum allowable size of a DNS Message is fixed. +Many of DNS's protocol limits are too small for uses which are or which +are desired to become common. There is no way for implementations to +advertise their capabilities. + +1.2. 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. RFC 2671 originally has proposed +extensions to the basic DNS protocol to overcome these deficiencies. +This memo refines that specification and obsoletes RFC 2671. + +1.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 [RFC2119]. + +2 - Affected Protocol Elements + +2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit +word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of +1-bit flags. The original reserved Z bits have been allocated to +various purposes, and most of the RCODE values are now in use. More +flags and more possible RCODEs are needed. The OPT pseudo-RR specified +in Section 4 contains subfields that carry a bit field extension of the +RCODE field and additional flag bits, respectively; for details see +Section 4.6 below. + +2.2. The first two bits of a wire format domain label are used to denote +the type of the label. [RFC1035 4.1.4] allocates two of the four +possible types and reserves the other two. Proposals for use of the +remaining types far outnumber those available. More label types were +needed, and an extension mechanism was proposed in RFC 2671 [RFC2671 +Section 3]. Section 3 of this document reserves DNS labels with a first +octet in the range of 64-127 decimal (label type 01) for future +standardization of Extended DNS Labels. + + + + + + + +Expires September 2008 [Page 2] + +INTERNET-DRAFT EDNS0 March 2008 + + +2.3. DNS Messages are limited to 512 octets in size when sent over UDP. +While the minimum maximum reassembly buffer size still allows a limit of +512 octets of UDP payload, most of the hosts now connected to the +Internet are able to reassemble larger datagrams. Some mechanism must +be created to allow requestors to advertise larger buffer sizes to +responders. To this end, the OPT pseudo-RR specified in Section 4 +contains a maximum payload size field; for details see Section 4.5 +below. + +3 - 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. + +Allocations from this range are to be made for IETF documents fully +describing the syntax and semantics as well as the applicability of the +particular Extended Label Type. + +This document does not describe any specific Extended Label Type. + +4 - OPT pseudo-RR + +4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data +section of a request, and to responses to such requests. An OPT is +called a pseudo-RR because it pertains to a particular transport level +message and not to any actual DNS data. OPT RRs 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. + +4.2. An OPT RR has a fixed part and a variable set of options expressed +as {attribute, value} pairs. The fixed part holds some DNS meta data +and also a small collection of new protocol elements which we expect to +be so popular that it would be a waste of wire space to encode them as +{attribute, value} pairs. + + + + + + + +Expires September 2008 [Page 3] + +INTERNET-DRAFT EDNS0 March 2008 + + +4.3. The fixed part of an OPT RR is structured as follows: + +Field Name Field Type Description +------------------------------------------------------ +NAME domain name empty (root domain) +TYPE u_int16_t OPT (41) +CLASS u_int16_t sender's UDP payload size +TTL u_int32_t extended RCODE and flags +RDLEN u_int16_t describes RDATA +RDATA octet stream {attribute,value} pairs + + +4.4. The variable part of an OPT RR is encoded in its RDATA and is +structured as zero or more of the following: + + : +0 (MSB) : +1 (LSB) : + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | OPTION-CODE | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | OPTION-LENGTH | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 4: | | + / OPTION-DATA / + / / + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + +OPTION-CODE (Assigned by IANA.) + +OPTION-LENGTH Size (in octets) of OPTION-DATA. + +OPTION-DATA Varies per OPTION-CODE. + +4.4.1. 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. + +4.4.2. Any OPTION-CODE values not understood by a responder or requestor +MUST be ignored. So, 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. + + + + + + +Expires September 2008 [Page 4] + +INTERNET-DRAFT EDNS0 March 2008 + + +4.5. The sender's UDP payload size (which OPT stores in the RR CLASS +field) is the number of octets of the largest UDP payload that can be +reassembled and delivered in the sender's network stack. Note that path +MTU, with or without fragmentation, may be smaller than this. Values +lower than 512 are undefined, and may be treated as format errors, or +may be treated as equal to 512, at the implementor's discretion. + +4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP +reassembly buffer. Choosing 1280 on an Ethernet connected requestor +would be reasonable. The consequence of choosing too large a value may +be an ICMP message from an intermediate gateway, or even a silent drop +of the response message. + +4.5.2. Both requestors and responders are advised to take account of the +path's discovered MTU (if already known) when considering message sizes. + +4.5.3. The requestor's maximum payload size can change over time, and +therefore MUST NOT be cached for use beyond the transaction in which it +is advertised. + +4.5.4. The responder's maximum payload size can change over time, but +can be reasonably expected to remain constant between two sequential +transactions; for example, a meaningless QUERY to discover a responder's +maximum UDP payload size, followed immediately by an UPDATE which takes +advantage of this size. (This is considered preferrable to the outright +use of TCP for oversized requests, if there is any reason to suspect +that the responder implements EDNS, and if a request will not fit in the +default 512 payload size limit.) + +4.5.5. Due to transaction overhead, it is unwise to advertise an +architectural limit as a maximum UDP payload size. Just because your +stack can reassemble 64KB datagrams, don't assume that you want to spend +more than about 4KB of state memory per ongoing transaction. + +4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) +are structured as follows: + + : +0 (MSB) : +1 (LSB) : + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | DO| Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + + + +Expires September 2008 [Page 5] + +INTERNET-DRAFT EDNS0 March 2008 + + +EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that + EXTENDED-RCODE value zero (0) indicates that an + unextended RCODE is in use (values zero (0) through + fifteen (15)). + +VERSION Indicates the implementation level of whoever sets it. + Full conformance with this specification is indicated by + version zero (0). Requestors are encouraged to set this + to the lowest implemented level capable of expressing a + transaction, to minimize the responder and network load + of discovering the greatest common implementation level + between requestor and responder. A requestor's version + numbering strategy should ideally be a run time + configuration option. + + If a responder does not implement the VERSION level of + the request, then it answers with RCODE=BADVERS. All + responses MUST be limited in format to the VERSION level + of the request, but the VERSION of each response MUST be + the highest implementation level of the responder. In + this way a requestor will learn the implementation level + of a responder as a side effect of every response, + including error responses, including RCODE=BADVERS. + +DO DNSSEC OK bit [RFC3225]. + +Z Set to zero by senders and ignored by receivers, unless + modified in a subsequent specification [IANAFLAGS]. + +5 - Transport Considerations + +5.1. The presence of an OPT pseudo-RR in a request is an indication that +the requestor fully implements the given version of EDNS, and can +correctly understand any response that conforms to that feature's +specification. + +5.2. Lack of use of these features in a request is an indication that +the requestor does not implement any part of this specification and that +the responder SHOULD NOT use any protocol extension described here in +its response. + +5.3. Responders who do not understand these protocol extensions are +expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or +to appear to "time out" due to inappropriate action by a "middle box" +such as a NAT, or to ignore extensions and respond only to unextended + + + +Expires September 2008 [Page 6] + +INTERNET-DRAFT EDNS0 March 2008 + + +protocol elements. Therefore use of extensions SHOULD be "probed" such +that a responder who isn't known to support them be allowed a retry with +no extensions if it responds with such an RCODE, or does not respond. +If a responder's capability level is cached by a requestor, a new probe +SHOULD be sent periodically to test for changes to responder capability. + +5.4. 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) DNS response, +possibly setting TC if the response will not fit in the unextended +response message's 512-octet size. + +6 - Security Considerations + +Requestor-side specification of the maximum buffer size may open a new +DNS denial of service attack if responders can be made to send messages +which are too large for intermediate gateways to forward, thus leading +to potential ICMP storms between gateways and responders. + +7 - IANA Considerations + +IANA has allocated RR type code 41 for OPT. + +This document controls the following IANA sub-registries in registry +"DOMAIN NAME SYSTEM PARAMETERS": + + "EDNS Extended Label Type" + "EDNS Option Codes" + "EDNS Version Numbers" + "Domain System Response Code" + +IANA is advised to re-parent these subregistries to this document. + +This document assigns label type 0b01xxxxxx as "EDNS Extended Label +Type." We request that IANA record this assignment. + +This document assigns option code 65535 to "Reserved for future +expansion." + +This document assigns EDNS Extended RCODE "16" to "BADVERS". + + + + + +Expires September 2008 [Page 7] + +INTERNET-DRAFT EDNS0 March 2008 + + +IESG approval is required to create new entries in the EDNS Extended +Label Type or EDNS Version Number registries, while any published RFC +(including Informational, Experimental, or BCP) is grounds for +allocation of an EDNS Option Code. + +8 - Acknowledgements + +Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, +Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten, +Alfred Hoenes and Markku Savela were each instrumental in creating and +refining this specification. + +9 - References + +[RFC1035] P. Mockapetris, "Domain Names - Implementation and + Specification," RFC 1035, USC/Information Sciences + Institute, November 1987. + +[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119, Harvard University, March + 1997. + +[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671, + Internet Software Consortium, August 1999. + +[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC + 3225, Nominum Inc., December 2001. + +[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site + http://www.iana.org/assignments/dns-header-flags, as of + June 2005 or later. + +10 - Author's Address + +Paul Vixie + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 423 1301 + EMail: vixie@isc.org + + + + + + + + +Expires September 2008 [Page 8] + +INTERNET-DRAFT EDNS0 March 2008 + + +Full Copyright Statement + +Copyright (C) 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 provided by the IETF +Administrative Support Activity (IASA). + + + + +Expires September 2008 [Page 9] + \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-13.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-13.txt new file mode 100644 index 0000000..13195bb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-13.txt @@ -0,0 +1,952 @@ + + + +DNS Extensions Working Group S. Rose +Internet-Draft NIST +Obsoletes: 2672 (if approved) W. Wijngaards +Updates: 3363,4294 NLnet Labs +(if approved) May 2, 2008 +Intended status: Standards Track +Expires: November 3, 2008 + + + Update to DNAME Redirection in the DNS + draft-ietf-dnsext-rfc2672bis-dname-13 + +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 3, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2008). + +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 + an update of the original specification in RFC 2672, also aligning + RFC 3363 and RFC 4294 with this revision. + + + +Rose & Wijngaards Expires November 3, 2008 [Page 1] + +Internet-Draft DNAME Redirection May 2008 + + +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]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + + 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3 + 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4 + 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5 + 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 6 + 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 + + 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. CNAME synthesis and UD bit . . . . . . . . . . . . . . . . 7 + 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 + + 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10 + + 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 . . . . . . . . . . . . . . . . . . . . . 12 + 5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 12 + 5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12 + 5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13 + 5.3.2.2. Valid Name Error Response Involving DNAME in + Bitmap . . . . . . . . . . . . . . . . . . . . . . 13 + 5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 13 + + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 2] + +Internet-Draft DNAME Redirection May 2008 + + +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 an update 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 redirection 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. DNAME is also used for the redirection of ENUM + domains to another maintaining party. + + This update to DNAME does not change the wire format or the handling + of DNAME Resource Records by existing software. A new UD (Understand + DNAME) bit in the EDNS flags field can be used to signal that CNAME + synthesis is not needed. 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 November 3, 2008 [Page 3] + +Internet-Draft DNAME Redirection May 2008 + + + 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 is the case of 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 November 3, 2008 [Page 4] + +Internet-Draft DNAME Redirection May 2008 + + + 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). 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 of 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 Apex 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 + + + +Rose & Wijngaards Expires November 3, 2008 [Page 5] + +Internet-Draft DNAME Redirection May 2008 + + + resource record types at that domain name, except DNAMEs or CNAMEs. + This means that DNAME RRs are not allowed at the parent side of a + delegation point but are allowed at a zone apex. + + The reason for this decision was that one can have a DNAME at the + zone apex. There still is a need to have the customary SOA and NS + resource records at the zone apex. This means that DNAME does not + 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 domain name subordinate to the + owner of a DNAME RR. To get the contents for names subordinate to + that owner, the DNAME redirection must be invoked and the resulting + target queried. A server MAY refuse to load a zone that has data at + a domain name subordinate to a domain name owning a DNAME RR. If the + server does load the zone, those names below the DNAME RR will be + occluded, 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 is not specified. + + RFC 2672 stated that the EDNS version had a meaning for understanding + of DNAME and DNAME target name compression. This document updates + RFC 2672, in that there is no EDNS version signaling for DNAME. + However, the flags section of EDNS(0) is updated with a Understand- + DNAME flag by this document (See Section 3.3). + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 6] + +Internet-Draft DNAME Redirection May 2008 + + +3. Processing + + The DNAME RR causes type NS additional section processing. + +3.1. CNAME synthesis and UD bit + + When preparing an response, a server upon performing a DNAME + substitution will in all cases include the DNAME RR used in the + answer section. A CNAME RR record with TTL equal to the + corresponding DNAME RR is synthesized and included in the answer + section for old resolvers. The owner name of the CNAME is the QNAME + of the query. DNSSEC [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 DNAME record. + + 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. DNAME aware resolvers can set the Understand-DNAME (UD + bit) to receive a response with only the DNAME RR and no synthesized + CNAMEs. + + The UD bit is part of the EDNS [RFC2671] extended RCODE and Flags + field. It is used to omit server processing, transmission and + resolver processing of unsigned synthesized CNAMEs. Resolvers can + set this in a query to request omission of the synthesized CNAMEs. + Servers copy the UD bit to the response, and can omit synthesized + CNAMEs from the answer. Older resolvers do not set the UD bit, and + older servers do not copy the UD bit to the answer, and will not omit + synthesized CNAMEs. + + Updated EDNS extended RCODE and Flags field. + + +0 (MSB) +1 (LSB) + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 0: | EXTENDED-RCODE | VERSION | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 2: |DO|UD| Z | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + 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. + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 7] + +Internet-Draft DNAME Redirection May 2008 + + +3.2. Server algorithm + + Below the server algorithm, which appeared in RFC 2672 Section 4.1, + is expanded to handle the UD (Understand DNAME) bit. + + 1. Set or clear the value of recursion available in the response + depending on whether the name server is willing to provide + recursive service. If recursive service is available and + requested via the RD bit in the query, go to step 5, otherwise + step 2. + + 2. Search the available zones for the zone which is the nearest + ancestor to QNAME. If such a zone is found, go to step 3, + otherwise step 4. + + 3. Start matching down, label by label, in the zone. The matching + process can terminate several ways: + + A. If the whole of QNAME is matched, we have found the node. + + If the data at the node is a CNAME, and QTYPE 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. If the EDNS OPT + record is present in the query and the UD bit is set, the + + + +Rose & Wijngaards Expires November 3, 2008 [Page 8] + +Internet-Draft DNAME Redirection May 2008 + + + server MAY copy the UD bit to the answer EDNS OPT record, and + omit CNAME synthesis. Else 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 + 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 + + + +Rose & Wijngaards Expires November 3, 2008 [Page 9] + +Internet-Draft DNAME Redirection May 2008 + + + 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 or refuse dynamic update. + +3.4. Acceptance and Intermediate Storage + + DNS caches 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. This conflict + situation is a transitional phase, that ends when the old data times + out. The cache 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. + + DNS caches MUST perform CNAME synthesis on behalf of DNAME-ignorant + clients. A DNS cache that understands DNAMEs can send out queries on + behalf of clients with the UD bit set (See Section 3.1). After + receiving the answers the DNS cache sends replies to DNAME ignorant + clients that include DNAMEs and synthesized CNAMEs. + +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. + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 10] + +Internet-Draft DNAME Redirection May 2008 + + + 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. + + 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]." + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 11] + +Internet-Draft DNAME Redirection May 2008 + + +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 + any domain names that may exist under the added DNAME. + + A server MUST ignore 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 + +5.3.1. DNAME bit in NSEC type map + + When a validator checks the NSEC RRs returned on a name error + response, it SHOULD check that the DNAME bit is not set. If the + DNAME bit is set then the DNAME substitution should have been done, + but has not. + +5.3.2. Validators Must Understand DNAME + + Examples of why DNSSEC validators MUST understand DNAME. + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 12] + +Internet-Draft DNAME Redirection May 2008 + + +5.3.2.1. DNAME in Bitmap Causes Invalid Name Error + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + foo.bar.example.com. IN A + ;; Answer + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + If this is the response, then only by understanding that the DNAME + bit 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.2.2. Valid Name Error Response Involving DNAME in Bitmap + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + cee.example.com. IN A + ;; Answer + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + This reply 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.2.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 answer shown above has the synthesized CNAME included. However, + the CNAME has no signature, since the server does not sign online. + So it 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 for every query + name. The validator must verify the DNAME signature and then + recursively resolve further to query for the foo.bar.example.net A + + + +Rose & Wijngaards Expires November 3, 2008 [Page 13] + +Internet-Draft DNAME Redirection May 2008 + + + record. + +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. + + This draft requests the second highest bit in the EDNS flags field + for the Understand-DNAME (UD) flag. + +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. + + 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]. + In Section 5.3.2 examples are given that 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 + Hines 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. + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 14] + +Internet-Draft DNAME Redirection May 2008 + + + [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. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [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. + +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 November 3, 2008 [Page 15] + +Internet-Draft DNAME Redirection May 2008 + + +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 + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + Phone: +31-20-888-4551 + EMail: wouter@nlnetlabs.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 16] + +Internet-Draft DNAME Redirection May 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 17] + diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt new file mode 100644 index 0000000..0af13c6 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt @@ -0,0 +1,755 @@ + + +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 new file mode 100644 index 0000000..9c73c68 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt @@ -0,0 +1,1292 @@ + + + + + +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 new file mode 100644 index 0000000..eaf6865 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt @@ -0,0 +1,1501 @@ +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 $. + + + 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-05.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt new file mode 100644 index 0000000..0285259 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt @@ -0,0 +1,729 @@ + + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Intended status: Informational November 29, 2006 +Expires: June 2, 2007 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-05 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 2, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against N-1 key compromises of N keys in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor(s). + + This mechanism will require changes to resolver management behavior + + + +StJohns Expires June 2, 2007 [Page 1] + +Internet-Draft trustanchor-update November 2006 + + + (but not resolver resolution behavior), and the addition of a single + flag bit to the DNSKEY record. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5 + 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8 + 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9 + 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9 + 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 + 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 + 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 + 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 + 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 + 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 + 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . . . 13 + + + + + + + + + + + + + + +StJohns Expires June 2, 2007 [Page 2] + +Internet-Draft trustanchor-update November 2006 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has + come to the realization that there will not be one signed name space, + but rather islands of signed name space each originating from + specific points (i.e. 'trust points') in the DNS tree. Each of those + islands will be identified by the trust point name, and validated by + at least one associated public key. For the purpose of this document + we'll call the association of that name and a particular key a 'trust + anchor'. A particular trust point can have more than one key + designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key replacement/ + rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1. Compliance Nomenclature + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119]. + + + + + + + +StJohns Expires June 2, 2007 [Page 3] + +Internet-Draft trustanchor-update November 2006 + + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a + DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section + 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is + validated by an existing trust anchor, then the resolver can add the + new key to its valid set of trust anchors for that trust point. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example, assuming a single key + compromise, we need to prevent an attacker from adding a new key and + revoking all the other old keys. + +2.1. Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a self- + signed RRSet and the key has the REVOKE bit (see Section 7 below) set + to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this + key as a trust anchor or for any other purposes except validating the + RRSIG it signed over the DNSKEY RRSet specifically for the purpose of + validating the revocation. Unlike the 'Add' operation below, + revocation is immediate and permanent upon receipt of a valid + revocation at the resolver. + + A self-signed RRSet is a DNSKEY RRSet which contains the specific + DNSKEY and for which there is a corresponding validated RRSIG record. + It's not a special DNSKEY RRSet, just a way of describing the + validation requirements for that RRSet. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + + + + +StJohns Expires June 2, 2007 [Page 4] + +Internet-Draft trustanchor-update November 2006 + + +2.2. Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in both the + attacker and owner being able to sign data in the zone and have it + accepted as valid by resolvers. + + To mitigate but not completely solve this problem, we add a hold-down + time to the addition of the trust anchor. When the resolver sees a + new SEP key in a validated trust point DNSKEY RRSet, the resolver + starts an acceptance timer, and remembers all the keys that validated + the RRSet. If the resolver ever sees the DNSKEY RRSet without the + new key but validly signed, it stops the acceptance process for that + key and resets the acceptance timer. If all of the keys which were + originally used to validate this key are revoked prior to the timer + expiring, the resolver stops the acceptance process and resets the + timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3. Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + + + +StJohns Expires June 2, 2007 [Page 5] + +Internet-Draft trustanchor-update November 2006 + + + RRSet or half the RRSIG expiration interval and no more often than + once per hour. The expiration interval is the amount of time from + when the RRSIG was last retrieved until the expiration time in the + RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 * + origTTL, .1 * expireInterval)). + +2.4. Resolver Parameters + +2.4.1. Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the + original TTL of the first trust point DNSKEY RRSet which contained + the new key, whichever is greater. This ensures that at least two + validated DNSKEY RRSets which contain the new key MUST be seen by the + resolver prior to the key's acceptance. + +2.4.2. Remove Hold-Down Time + + The remove hold-down time is 30 days. This parameter is solely a key + management database bookeeping parameter. Failure to remove + information about the state of defunct keys from the database will + not adversely impact the security of this protocol, but may end up + with a database cluttered with obsolete key information. + +2.4.3. Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validating the revocation. + + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + + + +StJohns Expires June 2, 2007 [Page 6] + +Internet-Draft trustanchor-update November 2006 + + + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + The resolver's view of the state of the key changes as various events + occur. + + This is the state of a trust point key as seen from the resolver. + The column on the left indicates the current state. The header at + the top shows the next state. The intersection of the two shows the + event that will cause the state to transition from the current state + to the next. + + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + + State Table + +4.1. Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after it's been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with + its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + + + + + +StJohns Expires June 2, 2007 [Page 7] + +Internet-Draft trustanchor-update November 2006 + + +4.2. States + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but either hasn't yet + been seen at the resolver or was seen but was absent from the last + DNSKEY RRSet (e.g. KeyRem event). + AddPend The key has been seen at the resolver, has its 'SEP' bit + set, and has been included in a validated DNSKEY RRSet. There is + a hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. (Note: this state is + more or less equivalent to the "Start" state, except that it's bad + practice to re-introduce previously used keys - think of this as + the holding state for all the old keys for which the resolver no + longer needs to track state.) + + +5. Trust Point Deletion + + A trust point which has all of its trust anchors revoked is + considered deleted and is treated as if the trust point was never + configured. If there are no superior configured trust points, data + at and below the deleted trust point are considered insecure by the + resolver. If there ARE superior configured trust points, data at and + below the deleted trust point are evaluated with respect to the + superior trust point(s). + + Alternately, a trust point which is subordinate to another configured + trust point MAY be deleted by a resolver after 180 days where such + subordinate trust point validly chains to a superior trust point. + The decision to delete the subordinate trust anchor is a local + + + +StJohns Expires June 2, 2007 [Page 8] + +Internet-Draft trustanchor-update November 2006 + + + configuration decision. Once the subordinate trust point is deleted, + validation of the subordinate zone is dependent on validating the + chain of trust to the superior trust point. + + +6. Scenarios - Informative + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and should) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +6.1. Adding a Trust Anchor + + Assume an existing trust anchor key 'A'. + 1. Generate a new key pair. + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while (i.e. for various resolvers timers to go off and for + them to retrieve the new DNSKEY RRSet and signatures). + 6. The new trust anchor will be populated at the resolvers on the + schedule described by the state table and update algorithm - see + Section 2 above + +6.2. Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revocation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator should include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + + + + + + +StJohns Expires June 2, 2007 [Page 9] + +Internet-Draft trustanchor-update November 2006 + + +6.3. Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been + in the DNSKEY RRSet and is a valid trust anchor, but wasn't being + used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator should include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +6.4. Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 6.3) + above assuming 'A' is the active key. + +6.5. Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 6.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' should continue to be + included in the RRSet for the remove hold-down time. + +6.6. Trust Point Deletion + + To delete a trust point which is subordinate to another configured + trust point (e.g. example.com to .com) requires some juggling of the + data. The specific process is: + 1. Generate a new DNSKEY and DS record and provide the DS record to + the parent along with DS records for the old keys + 2. Once the parent has published the DSs, add the new DNSKEY to the + RRSet and revoke ALL of the old keys at the same time while + signing the DNSKEY RRSet with all of the old and new keys. + 3. After 30 days stop publishing the old, revoked keys and remove + any corresponding DS records in the parent. + Revoking the old trust point keys at the same time as adding new keys + that chain to a superior trust prevents the resolver from adding the + new keys as trust anchors. Adding DS records for the old keys avoids + a race condition where either the subordinate zone becomes unsecure + + + +StJohns Expires June 2, 2007 [Page 10] + +Internet-Draft trustanchor-update November 2006 + + + (because the trust point was deleted) or becomes bogus (because it + didn't chain to the superior zone). + + +7. IANA Considerations + + The IANA will need to assign a bit in the DNSKEY flags field (see + section 4.3 of [RFC3755]) for the REVOKE bit. There are no other + IANA actions required. + + +8. Security Considerations + + In addition to the following sections, see also Theory of Operation + above and especially Section 2.2 for related discussions. + +8.1. Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible for + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision to + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +8.2. Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + +8.3. Dynamic Updates + + Allowing a resolver to update its trust anchor set based on in-band + key information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + + + +StJohns Expires June 2, 2007 [Page 11] + +Internet-Draft trustanchor-update November 2006 + + + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + + +9. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +Editorial Comments + + [msj2] msj: To be assigned. + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + Email: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + + + +StJohns Expires June 2, 2007 [Page 12] + +Internet-Draft trustanchor-update November 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +StJohns Expires June 2, 2007 [Page 13] + + diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt new file mode 100644 index 0000000..00476ae --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt @@ -0,0 +1,522 @@ + +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 new file mode 100644 index 0000000..9cf88a5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt @@ -0,0 +1,1063 @@ +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-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt new file mode 100644 index 0000000..0855ba3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt @@ -0,0 +1,1232 @@ + + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: August 14, 2006 VeriSign + February 10, 2006 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-05 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 14, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This memo describes DNS iterative resolver behavior that results in a + significant query volume sent to the root and top-level domain (TLD) + name servers. We offer implementation advice to iterative resolver + developers to alleviate these unnecessary queries. The + recommendations made in this document are a direct byproduct of + observation and analysis of abnormal query traffic patterns seen at + two of the thirteen root name servers and all thirteen com/net TLD + name servers. + + + +Larson & Barber Expires August 14, 2006 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. A note about terminology in this memo . . . . . . . . . . 3 + 2. Observed iterative resolver misbehavior . . . . . . . . . . . 5 + 2.1. Aggressive requerying for delegation information . . . . . 5 + 2.1.1. Recommendation . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Repeated queries to lame servers . . . . . . . . . . . . . 7 + 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7 + 2.3. Inability to follow multiple levels of indirection . . . . 8 + 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9 + 2.4. Aggressive retransmission when fetching glue . . . . . . . 9 + 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10 + 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10 + 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11 + 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11 + 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12 + 2.7. Name server records with zero TTL . . . . . . . . . . . . 12 + 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13 + 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 + 2.9. Queries for domain names resembling IPv4 addresses . . . . 14 + 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 + 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15 + 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15 + 2.11. Suboptimal name server selection algorithm . . . . . . . . 15 + 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16 + 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 + 5. Security considerations . . . . . . . . . . . . . . . . . . . 19 + 6. Internationalization considerations . . . . . . . . . . . . . 20 + 7. Informative References . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . . . 22 + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question () asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses (i.e., the + same query received simultaneously from multiple IP addresses). + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of indirection must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. None of the changes recommended affects the core DNS protocol + specification; instead, this document consists of guidelines to + implementors of iterative resolvers. + +1.1. A note about terminology in this memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and cause confusion resulting from + a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + to answer questions about certain zones authoritatively. This entity + is an iterative resolver combined with an authoritative name server + and is often called a "recursive name server" or a "caching name + server". + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + + + +Larson & Barber Expires August 14, 2006 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + because the focus is usually on that component. In instances where + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". As an example of the + difference, the name server component of a recursive name server + receives DNS queries and the iterative resolver component sends + queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address record" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +2. Observed iterative resolver misbehavior + +2.1. Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRset in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRset to one of the parent zone's name servers. (Note + that queries with QTYPE=NS are not required by the standard + resolution algorithm described in section 4.3.2 of RFC 1034 [2]. + These NS queries represent this implementation's addition to that + algorithm.) + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This implementation performs + this query to a zone's parent zone for each recursive query it + receives that fails because of a completely unresponsive set of name + servers for the target zone. Consider the effect when a popular zone + experiences a catastrophic failure of all its name servers: now every + recursive query for domain names in that zone sent to this recursive + name server implementation results in a query to the failed zone's + parent name servers. On one occasion when several dozen popular + zones became unreachable, the query load on the com/net name servers + increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent would be pointless: this query to the parent would come so + quickly on the heels of the referral that it would be almost certain + + + +Larson & Barber Expires August 14, 2006 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + to contain the same list of name servers. The chance of discovering + any new information is slim. + + The other possibility is that the iterative resolver successfully + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [3], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the TTL of the target + zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRset left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + + This section should not be understood to claim that all queries to a + zone's parent are bad. In some cases, such queries are not only + reasonable but required. Consider the situation when required + information, such as the address of a name server (i.e., the address + record corresponding to the RDATA of an NS record), has timed out of + an iterative resolver's cache before the corresponding NS record. If + the name of the name server is below the apex of the zone, then the + name server's address record is only available as glue in the parent + zone. For example, consider this NS record: + + example.com. IN NS ns.example.com. + + If a cache has this NS record but not the address record for + "ns.example.com", it is unable to contact the "example.com" zone + directly and must query the "com" zone to obtain the address record. + Note, however, that such a query would not have QTYPE=NS according to + the standard resolution algorithm. + +2.1.1. Recommendation + + An iterative resolver MUST NOT send a query for the NS RRset of a + non-responsive zone to any of the name servers for that zone's parent + + + +Larson & Barber Expires August 14, 2006 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRset: + + 1. is not authoritative for the zone (i.e., lame), or, + + 2. returns a server failure response (RCODE=2), or, + + 3. is dead or unreachable according to section 7.2 of RFC 2308 [4]. + +2.2. Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers + are unavailable or misconfigured. Different failure modes have + different expected durations. Some symptoms indicate problems that + are potentially transient; for example, various types of ICMP + unreachable messages because a name server process is not running or + a host or network is unreachable, or a complete lack of a response to + a query. Such responses could be the result of a host rebooting or + temporary outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + + It should also be noted, however, that some authoritative name server + implementations appear to be lame only for queries of certain types + as described in RFC 4074 [5]. In this case, it makes sense to retry + the "lame" servers for other types of queries, particularly when all + known authoritative name servers appear to be "lame". + +2.2.1. Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e. lame servers). + If this caching is performed, lame servers MUST be cached against the + specific query tuple . Zone + name can be derived from the owner name of the NS record that was + referenced to query the name server that was discovered to be lame. + + + +Larson & Barber Expires August 14, 2006 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers based on a time interval from + when the server is discovered to be lame. A minimum interval of + thirty minutes is RECOMMENDED. + + An exception to this recommendation occurs if all name servers for a + zone are marked lame. In that case, the iterative resolver SHOULD + temporarily ignore the servers' lameness status and query one or more + servers. This behavior is a workaround for the type-specific + lameness issue described in the previous section. + + Implementors should take care not to make lame server avoidance logic + overly broad: note that a name server could be lame for a parent zone + but not a child zone, e.g., lame for "example.com" but properly + authoritative for "sub.example.com". Therefore a name server should + not be automatically considered lame for subzones. In the case + above, even if a name server is known to be lame for "example.com", + it should be queried for QNAMEs at or below "sub.example.com" if an + NS record indicates it should be authoritative for that zone. + +2.3. Inability to follow multiple levels of indirection + + Some iterative resolver implementations are unable to follow + sufficient levels of indirection. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in existing gTLDs, increasing the + number of delegations using out-of-zone name servers. + + + + + + +Larson & Barber Expires August 14, 2006 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +2.3.1. Recommendation + + Clearly constructing a delegation that relies on multiple levels of + indirection is not a good administrative practice. However, the + practice is widespread enough to require that iterative resolvers be + able to cope with it. Iterative resolvers SHOULD be able to handle + arbitrary levels of indirection resulting from out-of-zone name + servers. Iterative resolvers SHOULD implement a level-of-effort + counter to avoid loops or otherwise performing too much work in + resolving pathological cases. + + A best practice that avoids this entire issue of indirection is to + name one or more of a zone's name servers in the zone itself. For + example, if the zone is named "example.com", consider naming some of + the name servers "ns{1,2,...}.example.com" (or similar). + +2.4. Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers non- + recursive queries from iterative resolvers looking for information in + zones it serves. With glue fetching enabled, however, an + authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a glue- + fetching name server can send queries that reach other name servers, + but is apparently prevented from receiving the responses. For + example, perhaps the name server is authoritative-only and therefore + its administrators expect it to receive only queries and not + responses. Perhaps unaware of glue fetching and presuming that the + name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + + + +Larson & Barber Expires August 14, 2006 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + prevents it from receiving responses. If this is the case, all glue- + fetching queries will go answered. + + We have observed name server implementations whose iterative + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1. Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5. Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it can't respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + + + +Larson & Barber Expires August 14, 2006 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + servers, which could explain how such a situation could persist + without being detected. + +2.5.1. Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries to pass through but not the resulting replies. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6. Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRset from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4 of RFC 2181 [3], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a non- + authoritative answer. Thus the "example.com" NS RRset just received + from the "example.com" authoritative server overrides the + "example.com" NS RRset received moments ago from the "com" + + + +Larson & Barber Expires August 14, 2006 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in address + record queries to the "com" authoritative servers. Queries for such + obviously bogus glue address records occur frequently at the com/net + name servers. + +2.6.1. Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the apex of the zone the + NS record appears in. Note that further levels of delegation are + possible, so a missing trailing dot could inadvertently create a name + server name that actually exists in a subzone. + + An authoritative name server SHOULD issue a warning when one of a + zone's NS records references a name server below the zone's apex when + a corresponding address record does not exist in the zone AND there + are no delegated subzones where the address record could exist. + +2.7. Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + + + +Larson & Barber Expires August 14, 2006 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want iterative resolvers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + +2.7.1. Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone. + +2.8. Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + "internal root" design, there could conceivably be private, non- + + + +Larson & Barber Expires August 14, 2006 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + public TLD or root zones that would be the appropriate targets for a + dynamic update. + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining closest enclosing zones for future updates. Once + the closest enclosing zone is determined with this method, the update + will either succeed or fail and there is no need to send further + updates to higher-level zones. The important point is that walking + up the tree with queries yields cacheable information, whereas + walking up the tree by sending UPDATE messages does not. + +2.8.1. Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level names to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9. Queries for domain names resembling IPv4 addresses + + The root name servers receive a significant number of A record + queries where the QNAME looks like an IPv4 address. The source of + these queries is unknown. It could be attributed to situations where + a user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1. Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + + + +Larson & Barber Expires August 14, 2006 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + bandwidth. A possible solution is to delegate these numeric TLDs + from the root zone to a separate set of servers to absorb the + traffic. The "black hole servers" used by the AS 112 Project [8], + which are currently delegated the in-addr.arpa zones corresponding to + RFC 1918 [7] private use address space, would be a possible choice to + receive these delegations. Of course, the proper and usual root zone + change procedures would have to be followed to make such a change to + the root zone. + +2.10. Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offers recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use + name servers that do not offer recursion, but we are not aware of any + stub resolver implementation that offers any feedback to the user + when so configured, aside from simply "not working". + +2.10.1. Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be immediately notified if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11. Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under specified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + + +Larson & Barber Expires August 14, 2006 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1. Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + + o Do not make assumptions based on NS RRset order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for "a.gtld- + servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other 12 authoritative servers for "com".) + + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +3. Acknowledgments + + The authors would like to thank the following people for their + comments that improved this document: Andras Salamon, Dave Meyer, + Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, + Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We + apologize if we have omitted anyone; any oversight was unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +4. IANA considerations + + There are no new IANA considerations introduced by this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +5. Security considerations + + The iterative resolver misbehavior discussed in this document exposes + the root and TLD name servers to increased risk of both intentional + and unintentional denial of service attacks. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +6. Internationalization considerations + + There are no new internationalization considerations introduced by + this memo. + +7. Informative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS + Queries for IPv6 Addresses", RFC 4074, May 2005. + + [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, + RFC 1918, February 1996. + + [8] + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 20] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + Email: mlarson@verisign.com + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + Email: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 21] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Larson & Barber Expires August 14, 2006 [Page 22] + diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt new file mode 100644 index 0000000..230c036 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt @@ -0,0 +1,672 @@ + + + +Network Working Group M. Andrews +Internet-Draft ISC +Intended status: BCP June 5, 2008 +Expires: December 7, 2008 + + + Locally-served DNS Zones + draft-ietf-dnsop-default-local-zones-05 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on December 7, 2008. + +Abstract + + Experience has shown that there are a number of DNS zones all + iterative resolvers and recursive nameservers should, unless + configured otherwise, automatically serve. 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. + + + + + + + + + +Andrews Expires December 7, 2008 [Page 1] + +Internet-Draft Locally-served DNS Zones June 2008 + + +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. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6 + 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 + 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 + 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7 + 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Appendix A. Change History [To Be Removed on Publication] . . . . 10 + A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10 + A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10 + A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10 + A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10 + A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11 + A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11 + A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11 + A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11 + Appendix B. Proposed Status [To Be Removed on Publication] . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + +Andrews Expires December 7, 2008 [Page 2] + +Internet-Draft Locally-served DNS Zones June 2008 + + +1. Introduction + + Experience has shown that there are a number of DNS [RFC 1034] [RFC + 1035] zones that all iterative resolvers and recursive nameservers + SHOULD, unless intentionally configured otherwise, automatically + serve. These zones include, but are not limited to, the IN-ADDR.ARPA + zones for the address space allocated by [RFC 1918] and the IP6.ARPA + zones for locally assigned unique local IPv6 addresses, [RFC 4193]. + + 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. + + [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled + locally. This document extends the recommendation to cover the IN- + ADDR.ARPA zones for [RFC 1918] 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 [RFC 1918] addresses but do not follow the last + paragraph in Section 3 of [RFC 1918]. + +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 [RFC 2119]. + + + + + +Andrews Expires December 7, 2008 [Page 3] + +Internet-Draft Locally-served DNS Zones June 2008 + + +2. Effects on sites using RFC 1918 addresses. + + For most sites using [RFC 1918] 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 [RFC 1918] 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 + 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." [RFC 2606]. 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 December 7, 2008 [Page 4] + +Internet-Draft Locally-served DNS Zones June 2008 + + + The SOA RR is needed to support negative caching [RFC 2308] 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 [RFC 2136] 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. RFC 1918 Zones + + The following zones correspond to the IPv4 address space reserved in + [RFC 1918]. + + +----------------------+ + | 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 December 7, 2008 [Page 5] + +Internet-Draft Locally-served DNS Zones June 2008 + + +4.2. RFC 3330 Zones + + The following zones correspond to those address ranges from [RFC + 3330] 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 ([RFC 3596], Section 2.5 IP6.ARPA Domain) for + the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291], + 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 [RFC 4193] already required special treatment of: + + + + +Andrews Expires December 7, 2008 [Page 6] + +Internet-Draft Locally-served DNS Zones June 2008 + + + +--------------+ + | Zone | + +--------------+ + | D.F.IP6.ARPA | + +--------------+ + +4.5. IPv6 Link Local Addresses + + IPv6 Link-Local Addresses as of [RFC 4291], 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 | + +----------------+ + + +5. Zones that are Out-Of-Scope + + IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and + IPv6 Non-Locally Assigned Local addresses [RFC 4193] 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 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) [RFC 4193], + there has been no decision made about whether the Regional Internet + Registries (RIRs) will provide delegations in this space or not. If + 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 + [RFC 4159]. + + 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). + + + +Andrews Expires December 7, 2008 [Page 7] + +Internet-Draft Locally-served DNS Zones June 2008 + + +6. IANA Considerations + + This document requests that IANA establish a registry of zones which + require this default behaviour. The initial contents of which are in + Section 4. Implementors are encouraged to check this registry and + adjust their implementations to reflect changes therein. + + This registry can be amended through "IETF Consensus" as per [RFC + 2434]. + + 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 [RFC 1918] + 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 [RFC 4035] by publishing and using DNSSEC trust + anchors. This will protect the clients from accidental import of + 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 + + [RFC 1034] + Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + STD 13, RFC 1034, November 1987. + + + +Andrews Expires December 7, 2008 [Page 8] + +Internet-Draft Locally-served DNS Zones June 2008 + + + [RFC 1035] + Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND + SPECIFICATION", STD 13, RFC 1035, November 1987. + + [RFC 1918] + Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC 2119] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2136] + Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC 2308] + Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2398, March 1998. + + [RFC 2434] + Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC 2606] + Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, June 1999. + + [RFC 3596] + Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IPv6", RFC 3596, October 2003. + + [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 4159] + Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, + August 2005. + + [RFC 4193] + Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + + + +Andrews Expires December 7, 2008 [Page 9] + +Internet-Draft Locally-served DNS Zones June 2008 + + + [RFC 4291] + Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + +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-00 (work in progress), + February 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-00 (work in + progress), February 2007. + + [RFC 3330] + "Special-Use IPv4 Addresses", RFC 3330, September 2002. + + +Appendix A. Change History [To Be Removed on Publication] + +A.1. draft-ietf-dnsop-default-local-zones-05.txt + + none, expiry prevention + +A.2. draft-ietf-dnsop-default-local-zones-04.txt + + Centrally Assigned Local addresses -> Non-Locally Assigned Local + address + +A.3. draft-ietf-dnsop-default-local-zones-03.txt + + expanded section 4 descriptions + + Added references [RFC 2136], [RFC 3596], + [I-D.draft-ietf-dnsop-as112-ops] and + [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. + + Revised language. + +A.4. draft-ietf-dnsop-default-local-zones-02.txt + + RNAME now "nobody.invalid." + + + + +Andrews Expires December 7, 2008 [Page 10] + +Internet-Draft Locally-served DNS Zones June 2008 + + + Revised language. + +A.5. draft-ietf-dnsop-default-local-zones-01.txt + + Revised impact description. + + Updated to reflect change in IP6.INT status. + +A.6. 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.7. draft-andrews-full-service-resolvers-03.txt + + Added "Proposed Status". + +A.8. 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 December 7, 2008 [Page 11] + +Internet-Draft Locally-served DNS Zones June 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. + + + + + + + + + + + +Andrews Expires December 7, 2008 [Page 12] + diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt new file mode 100644 index 0000000..bcd0d14 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt @@ -0,0 +1,396 @@ + + + + + + +INTERNET-DRAFT D. Senie +Category: BCP Amaranth Networks Inc. +Expires in six months July 2005 + + Encouraging the use of DNS IN-ADDR Mapping + draft-ietf-dnsop-inaddr-required-07.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + +Abstract + + Mapping of addresses to names has been a feature of DNS. Many sites, + implement it, many others don't. Some applications attempt to use it + as a part of a security strategy. The goal of this document is to + encourage proper deployment of address to name mappings, and provide + guidance for their use. + +Copyright Notice + + Copyright (C) The Internet Society. (2005) + +1. Introduction + + The Domain Name Service has provision for providing mapping of IP + addresses to host names. It is common practice to ensure both name to + address, and address to name mappings are provided for networks. This + practice, while documented, has never been required, though it is + generally encouraged. This document both encourages the presence of + + + +Senie [Page 1] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + these mappings and discourages reliance on such mappings for security + checks. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Discussion + + + From the early days of the Domain Name Service [RFC883] a special + domain has been set aside for resolving mappings of IP addresses to + domain names. This was refined in [RFC1035], describing the .IN- + ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA + was added [RFC3152]. This document uses IPv4 CIDR block sizes and + allocation strategy where there are differences and uses IPv4 + terminology. Aside from these differences, this document can and + should be applied to both address spaces. + + The assignment of blocks of IP address space was delegated to three + regional registries. Guidelines for the registries are specified in + [RFC2050], which requires regional registries to maintain IN-ADDR + records on the large blocks of space issued to ISPs and others. + + ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger + allocations. For smaller allocations, ARIN can provide IN-ADDR for + /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to + update IN-ADDR, however the present version of its policy document + for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft + copies of this document. As of this writing, it appears APNIC has no + actual policy on IN-ADDR. RIPE appears to have the strongest policy + in this area [RIPE302] indicating Local Internet Registries should + provide IN-ADDR services, and delegate those as appropriate when + address blocks are delegated. + + As we can see, the regional registries have their own policies for + recommendations and/or requirements for IN-ADDR maintenance. It + should be noted, however, that many address blocks were allocated + before the creation of the regional registries, and thus it is + unclear whether any of the policies of the registries are binding on + those who hold blocks from that era. + + Registries allocate address blocks on CIDR [RFC1519] boundaries. + Unfortunately the IN-ADDR zones are based on classful allocations. + Guidelines [RFC2317] for delegating on non-octet-aligned boundaries + exist, but are not always implemented. + +3. Examples of impact of missing IN-ADDR + + + +Senie [Page 2] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + These are some examples of problems that may be introduced by + reliance on IN-ADDR. + + Some applications use DNS lookups for security checks. To ensure + validity of claimed names, some applications will look up IN-ADDR + records to get names, and then look up the resultant name to see if + it maps back to the address originally known. Failure to resolve + matching names is seen as a potential security concern. + + Some FTP sites will flat-out reject users, even for anonymous FTP, if + the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when + itself resolved, does not match. Some Telnet servers also implement + this check. + + Web sites are in some cases using IN-ADDR checks to verify whether + the client is located within a certain geopolitical entity. This + approach has been employed for downloads of crypto software, for + example, where export of that software is prohibited to some locales. + Credit card anti-fraud systems also use these methods for geographic + placement purposes. + + The popular TCP Wrappers program found on most Unix and Linux systems + has options to enforce IN-ADDR checks and to reject any client that + does not resolve. This program also has a way to check to see that + the name given by a PTR record then resolves back to the same IP + address. This method provdes more comfort but no appreciable + additional security. + + Some anti-spam (anti junk email) systems use IN-ADDR to verify the + presence of a PTR record, or validate the PTR value points back to + the same address. + + Many web servers look up the IN-ADDR of visitors to be used in log + analysis. This adds to the server load, but in the case of IN-ADDR + unavailability, it can lead to delayed responses for users. + + Traceroutes with descriptive IN-ADDR naming proves useful when + debugging problems spanning large areas. When this information is + missing, the traceroutes take longer, and it takes additional steps + to determine that network is the cause of problems. + + Wider-scale implementation of IN-ADDR on dialup, wireless access and + other such client-oriented portions of the Internet would result in + lower latency for queries (due to lack of negative caching), and + lower name server load and DNS traffic. + +4. Recommendations + + + + +Senie [Page 3] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + 4.1 Delegation Recommendations + + + Regional Registries and any Local Registries to whom they delegate + should establish and convey a policy to those to whom they delegate + blocks that IN-ADDR mappings are recommended. Policies should + recommend those receiving delegations to provide IN-ADDR service + and/or delegate to downstream customers. + + Network operators should define and implement policies and procedures + which delegate IN-ADDR to their clients who wish to run their own IN- + ADDR DNS services, and provide IN-ADDR services for those who do not + have the resources to do it themselves. Delegation mechanisms should + permit the downstream customer to implement and comply with IETF + recommendations application of IN-ADDR to CIDR [RFC2317]. + + All IP address space assigned and in use should be resolved by IN- + ADDR records. All PTR records must use canonical names. + + All IP addresses in use within a block should have an IN-ADDR + mapping. Those addresses not in use, and those that are not valid for + use (zeros or ones broadcast addresses within a CIDR block) need not + have mappings. + + It should be noted that due to CIDR, many addresses that appear to be + otherwise valid host addresses may actually be zeroes or ones + broadcast addresses. As such, attempting to audit a site's degree of + compliance may only be done with knowledge of the internal subnet + architecture of the site. It can be assumed, however, any host that + originates an IP packet necessarily will have a valid host address, + and must therefore have an IN-ADDR mapping. + +4.2 Application Recommendations + + + Applications SHOULD NOT rely on IN-ADDR for proper operation. The use + of IN-ADDR, sometimes in conjunction with a lookup of the name + resulting from the PTR record provides no real security, can lead to + erroneous results and generally just increases load on DNS servers. + Further, in cases where address block holders fail to properly + configure IN-ADDR, users of those blocks are penalized. + +5. Security Considerations + + This document has no negative impact on security. While it could be + argued that lack of PTR record capabilities provides a degree of + anonymity, this is really not valid. Trace routes, whois lookups and + other sources will still provide methods for discovering identity. + + + +Senie [Page 4] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + By recommending applications avoid using IN-ADDR as a security + mechanism this document points out that this practice, despite its + use by many applications, is an ineffective form of security. + Applications should use better mechanisms of authentication. + +6. IANA Considerations + + There are no IANA considerations for this document. + +7. References + +7.1 Normative References + + [RFC883] P.V. Mockapetris, "Domain names: Implementation + specification," RFC883, November 1983. + + [RFC1035] P.V. Mockapetris, "Domain Names: Implementation + Specification," RFC 1035, November 1987. + + [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): + an Address Assignment and Aggregation Strategy," RFC 1519, September + 1993. + + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", + RFC 2026, BCP 9, October 1996. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation + Guidelines", RFC2050, BCP 12, Novebmer 1996. + + [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," + RFC 2317, March 1998. + + [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August + 2001. + +7.2 Informative References + + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date + unknown, http://www.arin.net/regserv/initial-isp.html + + [APNIC] "Policies For IPv4 Address Space Management in the Asia + Pacific Region," APNIC-086, 13 January 2003. + + [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 + Address Space in the RIPE NCC Service Region", RIPE-302, April 26, + + + +Senie [Page 5] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + 2004. http://www.ripe.net//ripe/docs/rev-del.html + + + +8. Acknowledgements + + Thanks to Peter Koch and Gary Miller for their input, and to many + people who encouraged me to write this document. + +9. Author's Address + + Daniel Senie + Amaranth Networks Inc. + 324 Still River Road + Bolton, MA 01740 + + Phone: (978) 779-5100 + + EMail: dts@senie.com + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + + + +Senie [Page 6] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + + Internet-Drafts are working documents of the + Internet Engineering Task Force (IETF), its areas, and its + working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by + other documents at any time. It is inappropriate to use + Internet-Drafts as reference material or to cite them other + than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be + accessed at http://www.ietf.org/shadow.html + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + +Senie [Page 7] + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt new file mode 100644 index 0000000..bf2afcd --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt @@ -0,0 +1,1848 @@ + + + +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 new file mode 100644 index 0000000..1276f9f --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt @@ -0,0 +1,1682 @@ + + + + +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 new file mode 100644 index 0000000..b2e2341 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt @@ -0,0 +1,300 @@ +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 new file mode 100644 index 0000000..6bece56 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt @@ -0,0 +1,389 @@ + +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-01.txt b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-01.txt new file mode 100644 index 0000000..8298bb2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-01.txt @@ -0,0 +1,1008 @@ + + + +DNSOP W. Hardaker +Internet-Draft Sparta, Inc. +Intended status: Informational September 3, 2008 +Expires: March 7, 2009 + + + Requirements for Management of Name Servers for the DNS + draft-ietf-dnsop-name-server-management-reqs-01.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 March 7, 2009. + +Abstract + + Management of name servers for the Domain Name Service (DNS) 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. + + 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. + + + + + +Hardaker Expires March 7, 2009 [Page 1] + +Internet-Draft Name Server Management Requirements September 2008 + + +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. Namespace Collision Protection . . . . . . . . . . . . 13 + 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 + + + +Hardaker Expires March 7, 2009 [Page 2] + +Internet-Draft Name Server Management Requirements September 2008 + + + A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Intellectual Property and Copyright Statements . . . . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Expires March 7, 2009 [Page 3] + +Internet-Draft Name Server Management Requirements September 2008 + + +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 March 7, 2009 [Page 4] + +Internet-Draft Name Server Management Requirements September 2008 + + +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 March 7, 2009 [Page 5] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 March 7, 2009 [Page 6] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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. + + The requirements in this document explicitly exclude dealing with + management of stub resolvers. Management of stub resolvers is + considered specifically out of scope of this document. + + +3. Management Operation Types + + Management operations can traditionally be broken into four + categories: + + o Control + + o Configuration + + + + + +Hardaker Expires March 7, 2009 [Page 7] + +Internet-Draft Name Server Management Requirements September 2008 + + + o Health and Monitoring + + 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 March 7, 2009 [Page 8] + +Internet-Draft Name Server Management Requirements September 2008 + + +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 March 7, 2009 [Page 9] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 March 7, 2009 [Page 10] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 March 7, 2009 [Page 11] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 March 7, 2009 [Page 12] + +Internet-Draft Name Server Management Requirements September 2008 + + +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. Namespace 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 March 7, 2009 [Page 13] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 Hines. + + +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 March 7, 2009 [Page 14] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 March 7, 2009 [Page 15] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 nameservers 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 March 7, 2009 [Page 16] + +Internet-Draft Name Server Management Requirements September 2008 + + + 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 March 7, 2009 [Page 17] + +Internet-Draft Name Server Management Requirements September 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. + + + + + + + + + + + +Hardaker Expires March 7, 2009 [Page 18] + 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 0000000..b041925 --- /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 new file mode 100644 index 0000000..c6ec7e4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-serverid-06.txt @@ -0,0 +1,618 @@ + + + + +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 new file mode 100644 index 0000000..3353b3b --- /dev/null +++ b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt @@ -0,0 +1,1588 @@ + + 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 new file mode 100644 index 0000000..2d5c87e --- /dev/null +++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt @@ -0,0 +1,1200 @@ + + + + + + +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 new file mode 100644 index 0000000..a272d81 --- /dev/null +++ b/doc/draft/draft-ietf-secsh-dns-05.txt @@ -0,0 +1,614 @@ +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 new file mode 100644 index 0000000..3578d2a --- /dev/null +++ b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt @@ -0,0 +1,519 @@ + +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-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt new file mode 100644 index 0000000..d857cd9 --- /dev/null +++ b/doc/draft/draft-kato-dnsop-local-zones-00.txt @@ -0,0 +1,295 @@ + + + +Internet Engineering Task Force Akira Kato, WIDE +INTERNET-DRAFT Paul Vixie, ISC +Expires: August 24, 2003 February 24, 2003 + + + Operational Guidelines for "local" zones in the DNS + draft-kato-dnsop-local-zones-00.txt + +Status of this Memo + + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference material +or to cite them other than as ``work in progress.'' + +To view the list Internet-Draft Shadow Directories, see +http://www.ietf.org/shadow.html. + +Distribution of this memo is unlimited. + +The internet-draft will expire in 6 months. The date of expiration will +be August 24, 2003. + + +Abstract + +A large number of DNS queries regarding to the "local" zones are sent +over the Internet in every second. This memo describes operational +guidelines to reduce the unnecessary DNS traffic as well as the load of +the Root DNS Servers. + +1. Introduction + +While it has yet been described in a RFC, .local is used to provide a +local subspace of the DNS tree. Formal delegation process has not been +completed for this TLD. In spite of this informal status, .local has +been used in many installations regardless of the awareness of the +users. Usually, the local DNS servers are not authoritative to the +.local domain, they end up to send queries to the Root DNS Servers. + +There are several other DNS zones which describe the "local" +information. .localhost has been used to describe the localhost for +more than a couple of decades and virtually all of the DNS servers are +configured authoritative for .localhost and its reverse zone .127.in- + + +KATO Expires: August 24, 2003 [Page 1] + + +DRAFT DNS local zones February 2003 + +addr.arpa. However, there are other "local" zones currently used in the +Internet or Intranets connected to the Internet through NATs or similar +devices. + +At a DNS server of an university in Japan, half of the DNS queries sent +to one of the 13 Root DNS Servers were regarding to the .local. At +another DNS Server running in one of the Major ISPs in Japan, the 1/4 +were .local. If those "local" queries are able to direct other DNS +servers than Root, or they can be resolved locally, it contributes the +reduction of the Root DNS Servers. + +2. Rationale + +Any DNS queries regarding to "local" names should not be sent to the DNS +servers on the Internet. + +3. Operational Guidelines + +Those queries should be processed at the DNS servers internal to each +site so that the severs respond with NXDOMAIN rather than sending +queries to the DNS servers outside. + +The "local" names have common DNS suffixes which are listed below: + +3.1. Local host related zones: + +Following two zones are described in [Barr, 1996] and .localhost is also +defined in [Eastlake, 1999] . + + o .localhost + o .127.in-addr.arpa + + +Following two zones are for the loopback address in IPv6 [Hinden, 1998] +. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush, +2001] , the old TLD .int has been used for this purpose for years +[Thomson, 1995] and many implementations still use .int. So it is +suggested that both zones should be provided for each IPv6 reverse +lookup zone for a while. + + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa + + +3.2. Locally created name space + +While the use of .local has been proposed in several Internet-Drafts, it +has not been described in any Internet documents with formal status. +However, the amount of the queries for .local is much larger than +others, it is suggested to resolve the following zone locally: + + + + +KATO Expires: August 24, 2003 [Page 2] + + +DRAFT DNS local zones February 2003 + + o .local + + + +3.3. Private or site-local addresses + +The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site- +local addresses [Hinden, 1998] should be resolved locally: + + o 10.in-addr.arpa + o 16.172.in-addr.arpa + o 17.172.in-addr.arpa + o 18.172.in-addr.arpa + o 19.172.in-addr.arpa + o 20.172.in-addr.arpa + o 21.172.in-addr.arpa + o 22.172.in-addr.arpa + o 23.172.in-addr.arpa + o 24.172.in-addr.arpa + o 25.172.in-addr.arpa + o 26.172.in-addr.arpa + o 27.172.in-addr.arpa + o 28.172.in-addr.arpa + o 29.172.in-addr.arpa + o 30.172.in-addr.arpa + o 31.172.in-addr.arpa + o 168.192.in-addr.arpa + o c.e.f.ip6.int + o d.e.f.ip6.int + o e.e.f.ip6.int + o f.e.f.ip6.int + o c.e.f.ip6.arpa + o d.e.f.ip6.arpa + o e.e.f.ip6.arpa + o f.e.f.ip6.arpa + + +3.4. Link-local addresses + +The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden, +1998] should be resolved locally: + + o 254.169.in-addr.arpa + o 8.e.f.ip6.int + o 9.e.f.ip6.int + o a.e.f.ip6.int + o b.e.f.ip6.int + o 8.e.f.ip6.arpa + o 9.e.f.ip6.arpa + o a.e.f.ip6.arpa + o b.e.f.ip6.arpa + + + +KATO Expires: August 24, 2003 [Page 3] + + +DRAFT DNS local zones February 2003 + +4. Suggestions to developers + +4.1. Suggestions to DNS software implementors + +In order to avoid unnecessary traffic, it is suggested that DNS software +implementors provide configuration templates or default configurations +so that the names described in the previous section are resolved locally +rather than sent to other DNS servers in the Internet. + +4.2. Suggestions to developers of NATs or similar devices + +There are many NAT or similar devices available in the market. +Regardless of the availability of DNS Servers in those devices, it is +suggested that those devices are able to filter the DNS traffic or +respond to the DNS traffic related to "local" zones by configuration +regardless of its ability of DNS service. It is suggested that this +functionality is activated by default. + +5. IANA Consideration + +While .local TLD has yet defined officially, there are substantial +queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the +traffic sent to the Root DNS Servers are related to the .local zone. +Therefore, while it is not formally defined, it is suggested that IANA +delegates .local TLD to an organization. + +The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918 +address and the link-local address. It has several DNS server instances +around the world by using BGP Anycast [Hardie, 2002] . So the AS112 +Project is one of the candidates to host the .local TLD. + +Authors' addresses + + Akira Kato + The University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + Tel: +81 3-5841-2750 + Email: kato@wide.ad.jp + + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063, USA + Tel: +1 650-779-7001 + Email: vixie@isc.org + + + + + + + +KATO Expires: August 24, 2003 [Page 4] + + +DRAFT DNS local zones February 2003 + +References + +To be filled + +References + +Barr, 1996. +D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912 +(February 1996). + +Eastlake, 1999. +D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999). + +Hinden, 1998. +R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in +RFC2373 (July 1998). + +Bush, 2001. +R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001). + +Thomson, 1995. +S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in +RFC1886 (December 1995). + +Rekhter, 1996. +Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, +"Address Allocation for Private Internets" in RFC1918 (February 1996). + +IANA, 2002. +IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002). + +Vixie, . +P. Vixie, "AS112 Project" in AS112. http://www.as112.net/. + +Hardie, 2002. +T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast +Addresses" in RFC3258 (April 2002). + + + + + + + + + + + + + + + + + +KATO Expires: August 24, 2003 [Page 5] + diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt new file mode 100644 index 0000000..f9eaf26 --- /dev/null +++ b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt @@ -0,0 +1,1830 @@ + + + + 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/draft/update b/doc/draft/update new file mode 100644 index 0000000..6ac2090 --- /dev/null +++ b/doc/draft/update @@ -0,0 +1,46 @@ +#!/bin/sh +commit= +for i +do + z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'` + if test -n "$z" + then + i="$z" + fi + if test -f "$i" + then + continue + fi + pat=`echo "$i" | sed 's/...txt/??.txt/'` + old=`echo $pat 2> /dev/null` + if test "X$old" != "X$pat" + then + newer=0 + for j in $old + do + if test $j ">" $i + then + newer=1 + fi + done + if test $newer = 1 + then + continue; + fi + fi + if fetch "http://www.ietf.org/internet-drafts/$i" + then + cvs add "$i" + if test "X$old" != "X$pat" + then + rm $old + cvs delete $old + commit="$commit $old" + fi + commit="$commit $i" + fi +done +if test -n "$commit" +then + cvs commit -m "new draft" $commit +fi diff --git a/doc/misc/Makefile.in b/doc/misc/Makefile.in new file mode 100644 index 0000000..501e3be --- /dev/null +++ b/doc/misc/Makefile.in @@ -0,0 +1,48 @@ +# Copyright (C) 2004, 2007 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.7 2007/09/24 04:21:59 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +@BIND9_MAKE_RULES@ + +PERL = @PERL@ + +MANOBJS = options + +doc man:: ${MANOBJS} + +docclean manclean maintainer-clean:: + rm -f options + +# Do not make options depend on ../../bin/tests/cfg_test, doing so +# will cause excessively clever versions of make to attempt to build +# that program right here, right now, if it is missing, which will +# cause make doc to bomb. + +CFG_TEST = ../../bin/tests/cfg_test + +options: FORCE + if test -x ${CFG_TEST} && \ + ${CFG_TEST} --named --grammar | \ + ${PERL} ${srcdir}/sort-options.pl | \ + ${PERL} ${srcdir}/format-options.pl >$@.new ; then \ + mv -f $@.new $@ ; \ + else \ + rm -f $@.new ; \ + fi diff --git a/doc/misc/dnssec b/doc/misc/dnssec new file mode 100644 index 0000000..4451e6c --- /dev/null +++ b/doc/misc/dnssec @@ -0,0 +1,84 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000-2002 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +DNSSEC Release Notes + +This document summarizes the state of the DNSSEC implementation in +this release of BIND9. + + +OpenSSL Library Required + +To support DNSSEC, BIND 9 must be linked with version 0.9.6e or newer of +the OpenSSL library. As of BIND 9.2, the library is no longer +included in the distribution - it must be provided by the operating +system or installed separately. + +To build BIND 9 with OpenSSL, use "configure --with-openssl". If +the OpenSSL library is installed in a nonstandard location, you can +specify a path as in "configure --with-openssl=/var". + + +Key Generation and Signing + +The tools for generating DNSSEC keys and signatures are now in the +bin/dnssec directory. Documentation for these programs can be found +in doc/arm/Bv9ARM.4.html and the man pages. + +The random data used in generating DNSSEC keys and signatures comes +from either /dev/random (if the OS supports it) or keyboard input. +Alternatively, a device or file containing entropy/random data can be +specified. + + +Serving Secure Zones + +When acting as an authoritative name server, BIND9 includes KEY, SIG +and NXT records in responses as specified in RFC2535 when the request +has the DO flag set in the query. + + +Secure Resolution + +Basic support for validation of DNSSEC signatures in responses has +been implemented but should still be considered experimental. + +When acting as a caching name server, BIND9 is capable of performing +basic DNSSEC validation of positive as well as nonexistence responses. +This functionality is enabled by including a "trusted-keys" clause +in the configuration file, containing the top-level zone key of the +the DNSSEC tree. + +Validation of wildcard responses is not currently supported. In +particular, a "name does not exist" response will validate +successfully even if it does not contain the NXT records to prove the +nonexistence of a matching wildcard. + +Proof of insecure status for insecure zones delegated from secure +zones works when the zones are completely insecure. Privately +secured zones delegated from secure zones will not work in all cases, +such as when the privately secured zone is served by the same server +as an ancestor (but not parent) zone. + +Handling of the CD bit in queries is now fully implemented. Validation +is not attempted for recursive queries if CD is set. + + +Secure Dynamic Update + +Dynamic update of secure zones has been implemented, but may not be +complete. Affected NXT and SIG records are updated by the server when +an update occurs. Advanced access control is possible using the +"update-policy" statement in the zone definition. + + +Secure Zone Transfers + +BIND 9 does not implement the zone transfer security mechanisms of +RFC2535 section 5.6, and we have no plans to implement them in the +future as we consider them inferior to the use of TSIG or SIG(0) to +ensure the integrity of zone transfers. + + +$Id: dnssec,v 1.19 2004/03/05 05:04:53 marka Exp $ diff --git a/doc/misc/format-options.pl b/doc/misc/format-options.pl new file mode 100644 index 0000000..b0b8d52 --- /dev/null +++ b/doc/misc/format-options.pl @@ -0,0 +1,49 @@ +#!/usr/bin/perl +# +# Copyright (C) 2004, 2007 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2001 Internet Software Consortium. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: format-options.pl,v 1.5 2007/09/24 04:21:59 marka Exp $ + +print <) { + chomp; + s/\t/ /g; + my $line = $_; + m!^( *)!; + my $indent = $1; + my $comment = ""; + if ( $line =~ m!//.*! ) { + $comment = $&; + $line =~ s!//.*!!; + } + my $start = ""; + while (length($line) >= 79 - length($comment)) { + $_ = $line; + # this makes sure that the comment has something in front of it + $len = 75 - length($comment); + m!^(.{0,$len}) (.*)$!; + $start = $start.$1."\n"; + $line = $indent." ".$2; + } + print $start.$line.$comment."\n"; +} diff --git a/doc/misc/ipv6 b/doc/misc/ipv6 new file mode 100644 index 0000000..4060bc3 --- /dev/null +++ b/doc/misc/ipv6 @@ -0,0 +1,113 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +Currently, there are multiple interesting problems with ipv6 +implementations on various platforms. These problems range from not +being able to use ipv6 with bind9 (or in particular the ISC socket +library, contained in libisc) to listen-on lists not being respected, +to strange warnings but seemingly correct behavior of named. + +COMPILE-TIME ISSUES +------------------- + +The socket library requires a certain level of support from the +operating system. In particular, it must follow the advanced ipv6 +socket API to be usable. The systems which do not follow this will +currently not get any warnings or errors, but ipv6 will simply not +function on them. + +These systems currently include, but are not limited to: + + AIX 3.4 (with ipv6 patches) + + +RUN-TIME ISSUES +--------------- + +In the original drafts of the ipv6 RFC documents, binding an ipv6 +socket to the ipv6 wildcard address would also cause the socket to +accept ipv4 connections and datagrams. When an ipv4 packet is +received on these systems, it is mapped into an ipv6 address. For +example, 1.2.3.4 would be mapped into ::ffff:1.2.3.4. The intent of +this mapping was to make transition from an ipv4-only application into +ipv6 easier, by only requiring one socket to be open on a given port. + +Later, it was discovered that this was generally a bad idea. For one, +many firewalls will block connection to 1.2.3.4, but will let through +::ffff:1.2.3.4. This, of course, is bad. Also, access control lists +written to accept only ipv4 addresses were suddenly ignored unless +they were rewritten to handle the ipv6 mapped addresses as well. + +Partly because of these problems, the latest IPv6 API introduces an +explicit knob (the "IPV6_V6ONLY" socket option ) to turn off the ipv6 +mapped address usage. + +In bind9, we first check if both the advanced API and the IPV6_V6ONLY +socket option are available. If both of them are available, bind9 +named will bind to the ipv6 wildcard port for both TCP and UDP. +Otherwise named will make a warning and try to bind to all available +ipv6 addresses separately. + +In any case, bind9 named binds to specific addresses for ipv4 sockets. + +The followings are historical notes when we always bound to the ipv6 +wildcard port regardless of the availability of the API support. +These problems should not happen with the closer checks above. + + +IPV6 Sockets Accept IPV4, Specific IPV4 Addresses Bindings Fail +--------------------------------------------------------------- + +The only OS which seems to do this is (some kernel versions of) linux. +If an ipv6 socket is bound to the ipv6 wildcard socket, and a specific +ipv4 socket is later bound (say, to 1.2.3.4 port 53) the ipv4 binding +will fail. + +What this means to bind9 is that the application will log warnings +about being unable to bind to a socket because the address is already +in use. Since the ipv6 socket will accept ipv4 packets and map them, +however, the ipv4 addresses continue to function. + +The effect is that the config file listen-on directive will not be +respected on these systems. + + +IPV6 Sockets Accept IPV4, Specific IPV4 Address Bindings Succeed +---------------------------------------------------------------- + +In this case, the system allows opening an ipv6 wildcard address +socket and then binding to a more specific ipv4 address later. An +example of this type of system is Digital Unix with ipv6 patches +applied. + +What this means to bind9 is that the application will respect +listen-on in regards to ipv4 sockets, but it will use mapped ipv6 +addresses for any that do not match the listen-on list. This, in +effect, makes listen-on useless for these machines as well. + + +IPV6 Sockets Do Not Accept IPV4 +------------------------------- + +On these systems, opening an IPV6 socket does not implicitly open any +ipv4 sockets. An example of these systems are NetBSD-current with the +latest KAME patch, and other systems which use the latest KAME patches +as their ipv6 implementation. + +On these systems, listen-on is fully functional, as the ipv6 socket +only accepts ipv6 packets, and the ipv4 sockets will handle the ipv4 +packets. + + +RELEVANT RFCs +------------- + +3513: Internet Protocol Version 6 (IPv6) Addressing Architecture + +3493: Basic Socket Interface Extensions for IPv6 + +3542: Advanced Sockets Application Program Interface (API) for IPv6 + + +$Id: ipv6,v 1.9 2004/08/10 04:27:51 jinmei Exp $ diff --git a/doc/misc/migration b/doc/misc/migration new file mode 100644 index 0000000..21856bf --- /dev/null +++ b/doc/misc/migration @@ -0,0 +1,267 @@ +Copyright (C) 2004, 2007, 2008 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001, 2003 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + + BIND 8 to BIND 9 Migration Notes + +BIND 9 is designed to be mostly upwards compatible with BIND 8, but +there is still a number of caveats you should be aware of when +upgrading an existing BIND 8 installation to use BIND 9. + + +1. Configuration File Compatibility + +1.1. Unimplemented Options and Changed Defaults + +BIND 9 supports most, but not all of the named.conf options of BIND 8. +For a complete list of implemented options, see doc/misc/options. + +If your named.conf file uses an unimplemented option, named will log a +warning message. A message is also logged about each option whose +default has changed unless the option is set explicitly in named.conf. + +The default of the "transfer-format" option has changed from +"one-answer" to "many-answers". If you have slave servers that do not +understand the many-answers zone transfer format (e.g., BIND 4.9.5 or +older) you need to explicitly specify "transfer-format one-answer;" in +either the options block or a server statement. + +BIND 9.4 onwards implements "allow-query-cache". The "allow-query" +option is no longer used to specify access to the cache. The +"allow-query" option continues to specify which hosts are allowed +to ask ordinary DNS questions. The new "allow-query-cache" option +is used to specify which hosts are allowed to get answers from the +cache. Since BIND 9.4.1, if "allow-query-cache" is not set then +"allow-recursion" is used if it is set, otherwise "allow-query" is +used if it is set, otherwise the default localnets and localhost +is used. + +1.2. Handling of Configuration File Errors + +In BIND 9, named refuses to start if it detects an error in +named.conf. Earlier versions would start despite errors, causing the +server to run with a partial configuration. Errors detected during +subsequent reloads do not cause the server to exit. + +Errors in master files do not cause the server to exit, but they +do cause the zone not to load. + +1.3. Logging + +The set of logging categories in BIND 9 is different from that +in BIND 8. If you have customised your logging on a per-category +basis, you need to modify your logging statement to use the +new categories. + +Another difference is that the "logging" statement only takes effect +after the entire named.conf file has been read. This means that when +the server starts up, any messages about errors in the configuration +file are always logged to the default destination (syslog) when the +server first starts up, regardless of the contents of the "logging" +statement. In BIND 8, the new logging configuration took effect +immediately after the "logging" statement was read. + +1.4. Notify messages and Refresh queries + +The source address and port for these is now controlled by +"notify-source" and "transfer-source", respectively, rather that +query-source as in BIND 8. + +1.5. Multiple Classes. + +Multiple classes have to be put into explicit views for each class. + + +2. Zone File Compatibility + +2.1. Strict RFC1035 Interpretation of TTLs in Zone Files + +BIND 9 strictly complies with the RFC1035 and RFC2308 rules regarding +omitted TTLs in zone files. Omitted TTLs are replaced by the value +specified with the $TTL directive, or by the previous explicit TTL if +there is no $TTL directive. + +If there is no $TTL directive and the first RR in the file does not +have an explicit TTL field, the zone file is illegal according to +RFC1035 since the TTL of the first RR is undefined. Unfortunately, +BIND 4 and many versions of BIND 8 accept such files without warning +and use the value of the SOA MINTTL field as a default for missing TTL +values. + +BIND 9.0 and 9.1 completely refused to load such files. BIND 9.2 +emulates the nonstandard BIND 4/8 SOA MINTTL behaviour and loads the +files anyway (provided the SOA is the first record in the file), but +will issue the warning message "no TTL specified; using SOA MINTTL +instead". + +To avoid problems, we recommend that you use a $TTL directive in each +zone file. + +2.2. Periods in SOA Serial Numbers Deprecated + +Some versions of BIND allow SOA serial numbers with an embedded +period, like "3.002", and convert them into integers in a rather +unintuitive way. This feature is not supported by BIND 9; serial +numbers must be integers. + +2.3. Handling of Unbalanced Quotes + +TXT records with unbalanced quotes, like 'host TXT "foo', were not +treated as errors in some versions of BIND. If your zone files +contain such records, you will get potentially confusing error +messages like "unexpected end of file" because BIND 9 will interpret +everything up to the next quote character as a literal string. + +2.4. Handling of Line Breaks + +Some versions of BIND accept RRs containing line breaks that are not +properly quoted with parentheses, like the following SOA: + + @ IN SOA ns.example. hostmaster.example. + ( 1 3600 1800 1814400 3600 ) + +This is not legal master file syntax and will be treated as an error +by BIND 9. The fix is to move the opening parenthesis to the first +line. + +2.5. Unimplemented BIND 8 Extensions + +$GENERATE: The "$$" construct for getting a literal $ into a domain +name is deprecated. Use \$ instead. + +2.6. TXT records are no longer automatically split. + +Some versions of BIND accepted strings in TXT RDATA consisting of more +than 255 characters and silently split them to be able to encode the +strings in a protocol conformant way. You may now see errors like this + dns_rdata_fromtext: local.db:119: ran out of space +if you have TXT RRs with too longs strings. Make sure to split the +string in the zone data file at or before a single one reaches 255 +characters. + +3. Interoperability Impact of New Protocol Features + +3.1. EDNS0 + +BIND 9 uses EDNS0 (RFC2671) to advertise its receive buffer size. It +also sets DO EDNS flag bit in queries to indicate that it wishes to +receive DNSSEC responses. + +Most older servers that do not support EDNS0, including prior versions +of BIND, will send a FORMERR or NOTIMP response to these queries. +When this happens, BIND 9 will automatically retry the query without +EDNS0. + +Unfortunately, there exists at least one non-BIND name server +implementation that silently ignores these queries instead of sending +an error response. Resolving names in zones where all or most +authoritative servers use this server will be very slow or fail +completely. We have contacted the manufacturer of the name server in +case, and they are working on a solution. + +When BIND 9 communicates with a server that does support EDNS0, such as +another BIND 9 server, responses of up to 4096 bytes may be +transmitted as a single UDP datagram which is subject to fragmentation +at the IP level. If a firewall incorrectly drops IP fragments, it can +cause resolution to slow down dramatically or fail. + +3.2. Zone Transfers + +Outgoing zone transfers now use the "many-answers" format by default. +This format is not understood by certain old versions of BIND 4. +You can work around this problem using the option "transfer-format +one-answer;", but since these old versions all have known security +problems, the correct fix is to upgrade the slave servers. + +Zone transfers to Windows 2000 DNS servers sometimes fail due to a +bug in the Windows 2000 DNS server where DNS messages larger than +16K are not handled properly. Obtain the latest service pack for +Windows 2000 from Microsoft to address this issue. In the meantime, +the problem can be worked around by setting "transfer-format one-answer;". +http://support.microsoft.com/default.aspx?scid=kb;en-us;297936 + +4. Unrestricted Character Set + + BIND 9.2 only + +BIND 9 does not restrict the character set of domain names - it is +fully 8-bit clean in accordance with RFC2181 section 11. + +It is strongly recommended that hostnames published in the DNS follow +the RFC952 rules, but BIND 9 will not enforce this restriction. + +Historically, some applications have suffered from security flaws +where data originating from the network, such as names returned by +gethostbyaddr(), are used with insufficient checking and may cause a +breach of security when containing unexpected characters; see + +for details. Some earlier versions of BIND attempt to protect these +flawed applications from attack by discarding data containing +characters deemed inappropriate in host names or mail addresses, under +the control of the "check-names" option in named.conf and/or "options +no-check-names" in resolv.conf. BIND 9 provides no such protection; +if applications with these flaws are still being used, they should +be upgraded. + + BIND 9.3 onwards implements check-names. + +5. Server Administration Tools + +5.1 Ndc Replaced by Rndc + +The "ndc" program has been replaced by "rndc", which is capable of +remote operation. Unlike ndc, rndc requires a configuration file. +The easiest way to generate a configuration file is to run +"rndc-confgen -a"; see the man pages for rndc(8), rndc-confgen(8), +and rndc.conf(5) for details. + +5.2. Nsupdate Differences + +The BIND 8 implementation of nsupdate had an undocumented feature +where an update request would be broken down into multiple requests +based upon the discovered zones that contained the records. This +behaviour has not been implemented in BIND 9. Each update request +must pertain to a single zone, but it is still possible to do multiple +updates in a single invocation of nsupdate by terminating each update +with an empty line or a "send" command. + + +6. No Information Leakage between Zones + +BIND 9 stores the authoritative data for each zone in a separate data +structure, as recommended in RFC1035 and as required by DNSSEC and +IXFR. When a BIND 9 server is authoritative for both a child zone and +its parent, it will have two distinct sets of NS records at the +delegation point: the authoritative NS records at the child's apex, +and a set of glue NS records in the parent. + +BIND 8 was unable to properly distinguish between these two sets of NS +records and would "leak" the child's NS records into the parent, +effectively causing the parent zone to be silently modified: responses +and zone transfers from the parent contained the child's NS records +rather than the glue configured into the parent (if any). In the case +of children of type "stub", this behaviour was documented as a feature, +allowing the glue NS records to be omitted from the parent +configuration. + +Sites that were relying on this BIND 8 behaviour need to add any +omitted glue NS records, and any necessary glue A records, to the +parent zone. + +Although stub zones can no longer be used as a mechanism for injecting +NS records into their parent zones, they are still useful as a way of +directing queries for a given domain to a particular set of name +servers. + + +7. Umask not Modified + +The BIND 8 named unconditionally sets the umask to 022. BIND 9 does +not; the umask inherited from the parent process remains in effect. +This may cause files created by named, such as journal files, to be +created with different file permissions than they did in BIND 8. If +necessary, the umask should be set explicitly in the script used to +start the named process. + + +$Id: migration,v 1.49 2008/03/18 15:42:53 jreed Exp $ diff --git a/doc/misc/migration-4to9 b/doc/misc/migration-4to9 new file mode 100644 index 0000000..008cbed --- /dev/null +++ b/doc/misc/migration-4to9 @@ -0,0 +1,57 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +$Id: migration-4to9,v 1.4 2004/03/05 05:04:53 marka Exp $ + + BIND 4 to BIND 9 Migration Notes + +To transition from BIND 4 to BIND 9 you first need to convert your +configuration file to the new format. There is a conversion tool in +contrib/named-bootconf that allows you to do this. + + named-bootconf.sh < /etc/named.boot > /etc/named.conf + +BIND 9 uses a system assigned port for the UDP queries it makes rather +than port 53 that BIND 4 uses. This may conflict with some firewalls. +The following directives in /etc/named.conf allows you to specify +a port to use. + + query-source address * port 53; + transfer-source * port 53; + notify-source * port 53; + +BIND 9 no longer uses the minimum field to specify the TTL of records +without a explicit TTL. Use the $TTL directive to specify a default TTL +before the first record without a explicit TTL. + + $TTL 3600 + @ IN SOA ns1.example.com. hostmaster.example.com. ( + 2001021100 + 7200 + 1200 + 3600000 + 7200 ) + +BIND 9 does not support multiple CNAMEs with the same owner name. + + Illegal: + www.example.com. CNAME host1.example.com. + www.example.com. CNAME host2.example.com. + +BIND 9 does not support "CNAMEs with other data" with the same owner name, +ignoring the DNSSEC records (SIG, NXT, KEY) that BIND 4 did not support. + + Illegal: + www.example.com. CNAME host1.example.com. + www.example.com. MX 10 host2.example.com. + +BIND 9 is less tolerant of errors in master files, so check your logs and +fix any errors reported. The named-checkzone program can also be to check +master files. + +Outgoing zone transfers now use the "many-answers" format by default. +This format is not understood by certain old versions of BIND 4. +You can work around this problem using the option "transfer-format +one-answer;", but since these old versions all have known security +problems, the correct fix is to upgrade the slave servers. diff --git a/doc/misc/options b/doc/misc/options new file mode 100644 index 0000000..3416a3b --- /dev/null +++ b/doc/misc/options @@ -0,0 +1,537 @@ + +This is a summary of the named.conf options supported by +this version of BIND 9. + +acl { ; ... }; + +controls { + inet ( | | * ) [ port ( | * + ) ] allow { ; ... } [ keys { ; + ... } ]; + unix perm owner group + [ keys { ; ... } ]; +}; + +dlz { + database ; +}; + +key { + algorithm ; + secret ; +}; + +logging { + category { ; ... }; + channel { + file [ versions ( "unlimited" | ) + ] [ size ]; + null; + print-category ; + print-severity ; + print-time ; + severity ; + stderr; + syslog ; + }; +}; + +lwres { + listen-on [ port ] { ( | ) + [ port ]; ... }; + ndots ; + search { ; ... }; + view ; +}; + +masters [ port ] { ( | [ port + ] | [ port ] ) [ key ]; ... }; + +options { + acache-cleaning-interval ; + acache-enable ; + additional-from-auth ; + additional-from-cache ; + allow-notify { ; ... }; + allow-query { ; ... }; + allow-query-cache { ; ... }; + allow-query-cache-on { ; ... }; + allow-query-on { ; ... }; + allow-recursion { ; ... }; + allow-recursion-on { ; ... }; + allow-transfer { ; ... }; + allow-update { ; ... }; + allow-update-forwarding { ; ... }; + allow-v6-synthesis { ; ... }; // obsolete + also-notify [ port ] { ( | + ) [ port ]; ... }; + alt-transfer-source ( | * ) [ port ( | * ) ]; + alt-transfer-source-v6 ( | * ) [ port ( | + * ) ]; + auth-nxdomain ; // default changed + avoid-v4-udp-ports { ; ... }; + avoid-v6-udp-ports { ; ... }; + blackhole { ; ... }; + cache-file ; + check-integrity ; + check-mx ( fail | warn | ignore ); + check-mx-cname ( fail | warn | ignore ); + check-names ( master | slave | response ) ( fail | warn | ignore ); + check-sibling ; + check-srv-cname ( fail | warn | ignore ); + check-wildcard ; + cleaning-interval ; + clients-per-query ; + coresize ; + datasize ; + deallocate-on-exit ; // obsolete + dialup ; + directory ; + disable-algorithms { ; ... }; + disable-empty-zone ; + dnssec-accept-expired ; + dnssec-enable ; + dnssec-lookaside trust-anchor ; + dnssec-must-be-secure ; + dnssec-validation ; + dual-stack-servers [ port ] { ( [ port + ] | [ port ] | + [ port ] ); ... }; + dump-file ; + edns-udp-size ; + empty-contact ; + empty-server ; + empty-zones-enable ; + fake-iquery ; // obsolete + fetch-glue ; // obsolete + files ; + flush-zones-on-shutdown ; + forward ( first | only ); + forwarders [ port ] { ( | ) + [ port ]; ... }; + has-old-clients ; // obsolete + heartbeat-interval ; + host-statistics ; // not implemented + host-statistics-max ; // not implemented + hostname ( | none ); + interface-interval ; + ixfr-from-differences ; + key-directory ; + lame-ttl ; + listen-on [ port ] { ; ... }; + listen-on-v6 [ port ] { ; ... }; + maintain-ixfr-base ; // obsolete + masterfile-format ( text | raw ); + match-mapped-addresses ; + max-acache-size ; + max-cache-size ; + max-cache-ttl ; + max-clients-per-query ; + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-ncache-ttl ; + max-refresh-time ; + max-retry-time ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-transfer-time-in ; + max-transfer-time-out ; + max-udp-size ; + memstatistics ; + memstatistics-file ; + min-refresh-time ; + min-retry-time ; + min-roots ; // not implemented + minimal-responses ; + multi-master ; + multiple-cnames ; // obsolete + named-xfer ; // obsolete + notify ; + notify-delay ; + notify-source ( | * ) [ port ( | * ) ]; + notify-source-v6 ( | * ) [ port ( | * ) ]; + notify-to-soa ; + nsec3-test-zone ; // test only + pid-file ( | none ); + port ; + preferred-glue ; + provide-ixfr ; + query-source ; + query-source-v6 ; + querylog ; + queryport-pool-ports ; // obsolete + queryport-pool-updateinterval ; // obsolete + random-device ; + recursing-file ; + recursion ; + recursive-clients ; + request-ixfr ; + request-nsid ; + reserved-sockets ; + rfc2308-type1 ; // not yet implemented + root-delegation-only [ exclude { ; ... } ]; + rrset-order { [ class ] [ type ] [ name + ] ; ... }; + serial-queries ; // obsolete + serial-query-rate ; + server-id ( | none |; + sig-signing-nodes ; + sig-signing-signatures ; + sig-signing-type ; + sig-validity-interval [ ]; + sortlist { ; ... }; + stacksize ; + statistics-file ; + statistics-interval ; // not yet implemented + suppress-initial-notify ; // not yet implemented + tcp-clients ; + tcp-listen-queue ; + tkey-dhkey ; + tkey-domain ; + tkey-gssapi-credential ; + topology { ; ... }; // not implemented + transfer-format ( many-answers | one-answer ); + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; + transfers-in ; + transfers-out ; + transfers-per-ns ; + treat-cr-as-space ; // obsolete + try-tcp-refresh ; + update-check-ksk ; + use-alt-transfer-source ; + use-id-pool ; // obsolete + use-ixfr ; + use-queryport-pool ; // obsolete + use-v4-udp-ports { ; ... }; + use-v6-udp-ports { ; ... }; + version ( | none ); + zero-no-soa-ttl ; + zero-no-soa-ttl-cache ; + zone-statistics ; +}; + +server { + bogus ; + edns ; + edns-udp-size ; + keys ; + max-udp-size ; + notify-source ( | * ) [ port ( | * ) ]; + notify-source-v6 ( | * ) [ port ( | * ) ]; + provide-ixfr ; + query-source ; + query-source-v6 ; + request-ixfr ; + support-ixfr ; // obsolete + transfer-format ( many-answers | one-answer ); + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; + transfers ; +}; + +statistics-channels { + inet ( | | * ) [ port ( | * + ) ] [ allow { ; ... } ]; +}; + +trusted-keys { ; ... }; + +view { + acache-cleaning-interval ; + acache-enable ; + additional-from-auth ; + additional-from-cache ; + allow-notify { ; ... }; + allow-query { ; ... }; + allow-query-cache { ; ... }; + allow-query-cache-on { ; ... }; + allow-query-on { ; ... }; + allow-recursion { ; ... }; + allow-recursion-on { ; ... }; + allow-transfer { ; ... }; + allow-update { ; ... }; + allow-update-forwarding { ; ... }; + allow-v6-synthesis { ; ... }; // obsolete + also-notify [ port ] { ( | + ) [ port ]; ... }; + alt-transfer-source ( | * ) [ port ( | * ) ]; + alt-transfer-source-v6 ( | * ) [ port ( | + * ) ]; + auth-nxdomain ; // default changed + cache-file ; + check-integrity ; + check-mx ( fail | warn | ignore ); + check-mx-cname ( fail | warn | ignore ); + check-names ( master | slave | response ) ( fail | warn | ignore ); + check-sibling ; + check-srv-cname ( fail | warn | ignore ); + check-wildcard ; + cleaning-interval ; + clients-per-query ; + database ; + dialup ; + disable-algorithms { ; ... }; + disable-empty-zone ; + dlz { + database ; + }; + dnssec-accept-expired ; + dnssec-enable ; + dnssec-lookaside trust-anchor ; + dnssec-must-be-secure ; + dnssec-validation ; + dual-stack-servers [ port ] { ( [ port + ] | [ port ] | + [ port ] ); ... }; + edns-udp-size ; + empty-contact ; + empty-server ; + empty-zones-enable ; + fetch-glue ; // obsolete + forward ( first | only ); + forwarders [ port ] { ( | ) + [ port ]; ... }; + ixfr-from-differences ; + key { + algorithm ; + secret ; + }; + key-directory ; + lame-ttl ; + maintain-ixfr-base ; // obsolete + masterfile-format ( text | raw ); + match-clients { ; ... }; + match-destinations { ; ... }; + match-recursive-only ; + max-acache-size ; + max-cache-size ; + max-cache-ttl ; + max-clients-per-query ; + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-ncache-ttl ; + max-refresh-time ; + max-retry-time ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-transfer-time-in ; + max-transfer-time-out ; + max-udp-size ; + min-refresh-time ; + min-retry-time ; + min-roots ; // not implemented + minimal-responses ; + multi-master ; + notify ; + notify-delay ; + notify-source ( | * ) [ port ( | * ) ]; + notify-source-v6 ( | * ) [ port ( | * ) ]; + notify-to-soa ; + nsec3-test-zone ; // test only + preferred-glue ; + provide-ixfr ; + query-source ; + query-source-v6 ; + queryport-pool-ports ; // obsolete + queryport-pool-updateinterval ; // obsolete + recursion ; + request-ixfr ; + request-nsid ; + rfc2308-type1 ; // not yet implemented + root-delegation-only [ exclude { ; ... } ]; + rrset-order { [ class ] [ type ] [ name + ] ; ... }; + server { + bogus ; + edns ; + edns-udp-size ; + keys ; + max-udp-size ; + notify-source ( | * ) [ port ( | * + ) ]; + notify-source-v6 ( | * ) [ port ( + | * ) ]; + provide-ixfr ; + query-source ; + query-source-v6 ; + request-ixfr ; + support-ixfr ; // obsolete + transfer-format ( many-answers | one-answer ); + transfer-source ( | * ) [ port ( | + * ) ]; + transfer-source-v6 ( | * ) [ port ( + | * ) ]; + transfers ; + }; + sig-signing-nodes ; + sig-signing-signatures ; + sig-signing-type ; + sig-validity-interval [ ]; + sortlist { ; ... }; + suppress-initial-notify ; // not yet implemented + topology { ; ... }; // not implemented + transfer-format ( many-answers | one-answer ); + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; + trusted-keys { + ; ... }; + try-tcp-refresh ; + update-check-ksk ; + use-alt-transfer-source ; + use-queryport-pool ; // obsolete + zero-no-soa-ttl ; + zero-no-soa-ttl-cache ; + zone { + allow-notify { ; ... }; + allow-query { ; ... }; + allow-query-on { ; ... }; + allow-transfer { ; ... }; + allow-update { ; ... }; + allow-update-forwarding { ; ... }; + also-notify [ port ] { ( | + ) [ port ]; ... }; + alt-transfer-source ( | * ) [ port ( + | * ) ]; + alt-transfer-source-v6 ( | * ) [ port ( + | * ) ]; + check-integrity ; + check-mx ( fail | warn | ignore ); + check-mx-cname ( fail | warn | ignore ); + check-names ( fail | warn | ignore ); + check-sibling ; + check-srv-cname ( fail | warn | ignore ); + check-wildcard ; + database ; + delegation-only ; + dialup ; + file ; + forward ( first | only ); + forwarders [ port ] { ( | + ) [ port ]; ... }; + ixfr-base ; // obsolete + ixfr-from-differences ; + ixfr-tmp-file ; // obsolete + journal ; + key-directory ; + maintain-ixfr-base ; // obsolete + masterfile-format ( text | raw ); + masters [ port ] { ( | [ + port ] | [ port ] ) + [ key ]; ... }; + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-refresh-time ; + max-retry-time ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-transfer-time-in ; + max-transfer-time-out ; + min-refresh-time ; + min-retry-time ; + multi-master ; + notify ; + notify-delay ; + notify-source ( | * ) [ port ( | * + ) ]; + notify-source-v6 ( | * ) [ port ( + | * ) ]; + notify-to-soa ; + nsec3-test-zone ; // test only + pubkey + ; // obsolete + sig-signing-nodes ; + sig-signing-signatures ; + sig-signing-type ; + sig-validity-interval [ ]; + transfer-source ( | * ) [ port ( | + * ) ]; + transfer-source-v6 ( | * ) [ port ( + | * ) ]; + try-tcp-refresh ; + type ( master | slave | stub | hint | forward | + delegation-only ); + update-check-ksk ; + update-policy { ( grant | deny ) ( name | + subdomain | wildcard | self | selfsub | selfwild | + krb5-self | ms-self | krb5-subdomain | ms-subdomain | + tcp-self | 6to4-self ) ; ... }; + use-alt-transfer-source ; + zero-no-soa-ttl ; + zone-statistics ; + }; + zone-statistics ; +}; + +zone { + allow-notify { ; ... }; + allow-query { ; ... }; + allow-query-on { ; ... }; + allow-transfer { ; ... }; + allow-update { ; ... }; + allow-update-forwarding { ; ... }; + also-notify [ port ] { ( | + ) [ port ]; ... }; + alt-transfer-source ( | * ) [ port ( | * ) ]; + alt-transfer-source-v6 ( | * ) [ port ( | + * ) ]; + check-integrity ; + check-mx ( fail | warn | ignore ); + check-mx-cname ( fail | warn | ignore ); + check-names ( fail | warn | ignore ); + check-sibling ; + check-srv-cname ( fail | warn | ignore ); + check-wildcard ; + database ; + delegation-only ; + dialup ; + file ; + forward ( first | only ); + forwarders [ port ] { ( | ) + [ port ]; ... }; + ixfr-base ; // obsolete + ixfr-from-differences ; + ixfr-tmp-file ; // obsolete + journal ; + key-directory ; + maintain-ixfr-base ; // obsolete + masterfile-format ( text | raw ); + masters [ port ] { ( | [ port + ] | [ port ] ) [ key + ]; ... }; + max-ixfr-log-size ; // obsolete + max-journal-size ; + max-refresh-time ; + max-retry-time ; + max-transfer-idle-in ; + max-transfer-idle-out ; + max-transfer-time-in ; + max-transfer-time-out ; + min-refresh-time ; + min-retry-time ; + multi-master ; + notify ; + notify-delay ; + notify-source ( | * ) [ port ( | * ) ]; + notify-source-v6 ( | * ) [ port ( | * ) ]; + notify-to-soa ; + nsec3-test-zone ; // test only + pubkey ; // obsolete + sig-signing-nodes ; + sig-signing-signatures ; + sig-signing-type ; + sig-validity-interval [ ]; + transfer-source ( | * ) [ port ( | * ) ]; + transfer-source-v6 ( | * ) [ port ( | * ) ]; + try-tcp-refresh ; + type ( master | slave | stub | hint | forward | delegation-only ); + update-check-ksk ; + update-policy { ( grant | deny ) ( name | subdomain | + wildcard | self | selfsub | selfwild | krb5-self | ms-self | + krb5-subdomain | ms-subdomain | tcp-self | 6to4-self ) + ; ... }; + use-alt-transfer-source ; + zero-no-soa-ttl ; + zone-statistics ; +}; + diff --git a/doc/misc/rfc-compliance b/doc/misc/rfc-compliance new file mode 100644 index 0000000..4c87c66 --- /dev/null +++ b/doc/misc/rfc-compliance @@ -0,0 +1,62 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +$Id: rfc-compliance,v 1.4 2004/03/05 05:04:53 marka Exp $ + +BIND 9 is striving for strict compliance with IETF standards. We +believe this release of BIND 9 complies with the following RFCs, with +the caveats and exceptions listed in the numbered notes below. Note +that a number of these RFCs do not have the status of Internet +standards but are proposed or draft standards, experimental RFCs, +or Best Current Practice (BCP) documents. + + RFC1034 + RFC1035 [1] [2] + RFC1123 + RFC1183 + RFC1535 + RFC1536 + RFC1706 + RFC1712 + RFC1750 + RFC1876 + RFC1982 + RFC1995 + RFC1996 + RFC2136 + RFC2163 + RFC2181 + RFC2230 + RFC2308 + RFC2535 [3] [4] + RFC2536 + RFC2537 + RFC2538 + RFC2539 + RFC2671 + RFC2672 + RFC2673 + RFC2782 + RFC2915 + RFC2930 + RFC2931 [5] + RFC3007 + + +[1] Queries to zones that have failed to load return SERVFAIL rather +than a non-authoritative response. This is considered a feature. + +[2] CLASS ANY queries are not supported. This is considered a feature. + +[3] Wildcard records are not supported in DNSSEC secure zones. + +[4] Servers authoritative for secure zones being resolved by BIND 9 +must support EDNS0 (RFC2671), and must return all relevant SIGs and +NXTs in responses rather than relying on the resolving server to +perform separate queries for missing SIGs and NXTs. + +[5] When receiving a query signed with a SIG(0), the server will only +be able to verify the signature if it has the key in its local +authoritative data; it will not do recursion or validation to +retrieve unknown keys. diff --git a/doc/misc/roadmap b/doc/misc/roadmap new file mode 100644 index 0000000..f63a469 --- /dev/null +++ b/doc/misc/roadmap @@ -0,0 +1,47 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +$Id: roadmap,v 1.2 2004/03/05 05:04:54 marka Exp $ + +Road Map to the BIND 9 Source Tree + +bin/named The name server. This relies heavily on the + libraries in lib/isc and lib/dns. + client.c Handling of incoming client requests + query.c Query processing +bin/rndc The remote name daemon control program +bin/dig The "dig" program +bin/dnssec The DNSSEC signer and other DNSSEC tools +bin/nsupdate The "nsupdate" program +bin/tests Test suites and miscellaneous test programs +bin/tests/system System tests; see bin/tests/system/README +lib/dns The DNS library + resolver.c The "full resolver" (performs recursive lookups) + validator.c The DNSSEC validator + db.c The database interface + sdb.c The simple database interface + rbtdb.c The red-black tree database +lib/dns/rdata Routines for handling the various RR types +lib/dns/sec Cryptographic libraries for DNSSEC +lib/isc The ISC library + task.c Task library + unix/socket.c Unix implementation of socket library +lib/isccfg Routines for reading and writing ISC-style + configuration files like named.conf and rndc.conf +lib/isccc The command channel library, used by rndc. +lib/tests Support code for the test suites. +lib/lwres The lightweight resolver library. +doc/draft Current internet-drafts pertaining to the DNS +doc/rfc RFCs pertaining to the DNS +doc/misc Miscellaneous documentation +doc/arm The BIND 9 Administrator Reference Manual +doc/man Man pages +contrib Contributed and other auxiliary code +contrib/idn/mdnkit The multilingual domain name evaluation kit +contrib/sdb Sample drivers for the simple database interface +make Makefile fragments, used by configure + +The library interfaces are mainly documented in the form of comments +in the header files. For example, the task subsystem is documented in +lib/isc/include/isc/task.h diff --git a/doc/misc/sdb b/doc/misc/sdb new file mode 100644 index 0000000..552028a --- /dev/null +++ b/doc/misc/sdb @@ -0,0 +1,169 @@ +Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +Copyright (C) 2000, 2001 Internet Software Consortium. +See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. + +Using the BIND 9 Simplified Database Interface + +This document describes the care and feeding of the BIND 9 Simplified +Database Interface, which allows you to extend BIND 9 with new ways +of obtaining the data that is published as DNS zones. + + +The Original BIND 9 Database Interface + +BIND 9 has a well-defined "back-end database interface" that makes it +possible to replace the component of the name server responsible for +the storage and retrieval of zone data, called the "database", on a +per-zone basis. The default database is an in-memory, red-black-tree +data structure commonly referred to as "rbtdb", but it is possible to +write drivers to support any number of alternative database +technologies such as in-memory hash tables, application specific +persistent on-disk databases, object databases, or relational +databases. + +The original BIND 9 database interface defined in is +designed to efficiently support the full set of database functionality +needed by a name server that implements the complete DNS protocols, +including features such as zone transfers, dynamic update, and DNSSEC. +Each of these aspects of name server operations places its own set of +demands on the data store, with the result that the database API is +quite complex and contains operations that are highly specific to the +DNS. For example, data are stored in a binary format, the name space +is tree structured, and sets of data records are conceptually +associated with DNSSEC signature sets. For these reasons, writing a +driver using this interface is a highly nontrivial undertaking. + + +The Simplified Database Interface + +Many BIND users wish to provide access to various data sources through +the DNS, but are not necessarily interested in completely replacing +the in-memory "rbt" database or in supporting features like dynamic +update, DNSSEC, or even zone transfers. + +Often, all you want is limited, read-only DNS access to an existing +system. For example, you may have an existing relational database +containing hostname/address mappings and wish to provide forvard and +reverse DNS lookups based on this information. Or perhaps you want to +set up a simple DNS-based load balancing system where the name server +answers queries about a single DNS name with a dynamically changing +set of A records. + +BIND 9.1 introduced a new, simplified database interface, or "sdb", +which greatly simplifies the writing of drivers for these kinds of +applications. + + +The sdb Driver + +An sdb driver is an object module, typically written in C, which is +linked into the name server and registers itself with the sdb +subsystem. It provides a set of callback functions, which also serve +to advertise its capabilities. When the name server receives DNS +queries, invokes the callback functions to obtain the data to respond +with. + +Unlike the full database interface, the sdb interface represents all +domain names and resource records as ASCII text. + + +Writing an sdb Driver + +When a driver is registered, it specifies its name, a list of callback +functions, and flags. + +The flags specify whether the driver wants to use relative domain +names where possible. + +The callback functions are as follows. The only one that must be +defined is lookup(). + + - create(zone, argc, argv, driverdata, dbdata) + Create a database object for "zone". + + - destroy(zone, driverdata, dbdata) + Destroy the database object for "zone". + + - lookup(zone, name, dbdata, lookup) + Return all the records at the domain name "name". + + - authority(zone, dbdata, lookup) + Return the SOA and NS records at the zone apex. + + - allnodes(zone, dbdata, allnodes) + Return all data in the zone, for zone transfers. + +For more detail about these functions and their parameters, see +bind9/lib/dns/include/dns/sdb.h. For example drivers, see +bind9/contrib/sdb. + + +Rebuilding the Server + +The driver module and header file must be copied to (or linked into) +the bind9/bin/named and bind9/bin/named/include directories +respectively, and must be added to the DBDRIVER_OBJS and DBDRIVER_SRCS +lines in bin/named/Makefile.in (e.g. for the timedb sample sdb driver, +add timedb.c to DBDRIVER_SRCS and timedb.@O@ to DBDRIVER_OBJS). If +the driver needs additional header files or libraries in nonstandard +places, the DBDRIVER_INCLUDES and DBDRIVER_LIBS lines should also be +updated. + +Calls to dns_sdb_register() and dns_sdb_unregister() (or wrappers, +e.g. timedb_init() and timedb_clear() for the timedb sample sdb +driver) must be inserted into the server, in bind9/bin/named/main.c. +Registration should be in setup(), before the call to +ns_server_create(). Unregistration should be in cleanup(), +after the call to ns_server_destroy(). A #include should be added +corresponding to the driver header file. + +You should try doing this with one or more of the sample drivers +before attempting to write a driver of your own. + + +Configuring the Server + +To make a zone use a new database driver, specify a "database" option +in its "zone" statement in named.conf. For example, if the driver +registers itself under the name "acmedb", you might say + + zone "foo.com" { + database "acmedb"; + }; + +You can pass arbitrary arguments to the create() function of the +driver by adding any number of whitespace-separated words after the +driver name: + + zone "foo.com" { + database "acmedb -mode sql -connect 10.0.0.1"; + }; + + +Hints for Driver Writers + + - If a driver is generating data on the fly, it probably should + not implement the allnodes() function, since a zone transfer + will not be meaningful. The allnodes() function is more relevant + with data from a database. + + - The authority() function is necessary if and only if the lookup() + function will not add SOA and NS records at the zone apex. If + SOA and NS records are provided by the lookup() function, + the authority() function should be NULL. + + - When a driver is registered, an opaque object can be provided. This + object is passed into the database create() and destroy() functions. + + - When a database is created, an opaque object can be created that + is associated with that database. This object is passed into the + lookup(), authority(), and allnodes() functions, and is + destroyed by the destroy() function. + + +Future Directions + +A future release may support dynamic loading of sdb drivers. + + +$Id: sdb,v 1.6 2004/03/05 05:04:54 marka Exp $ diff --git a/doc/misc/sort-options.pl b/doc/misc/sort-options.pl new file mode 100644 index 0000000..4251521 --- /dev/null +++ b/doc/misc/sort-options.pl @@ -0,0 +1,50 @@ +#!/bin/perl +# +# Copyright (C) 2007 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 +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: sort-options.pl,v 1.3 2007/09/24 23:46:48 tbox Exp $ + +sub sortlevel() { + my @options = (); + my $fin = ""; + my $i = 0; + while (<>) { + if (/^\s*};$/) { + $fin = $_; + # print 2, $_; + last; + } + next if (/^$/); + if (/{$/) { + # print 3, $_; + my $sec = $_; + push(@options, $sec . sortlevel()); + } else { + push(@options, $_); + # print 1, $_; + } + $i++; + } + my $result = ""; + foreach my $i (sort @options) { + $result = ${result}.${i}; + $result = $result."\n" if ($i =~ /^[a-z]/i); + # print 5, ${i}; + } + $result = ${result}.${fin}; + return ($result); +} + +print sortlevel(); diff --git a/doc/rfc/fetch b/doc/rfc/fetch new file mode 100755 index 0000000..17ce40f --- /dev/null +++ b/doc/rfc/fetch @@ -0,0 +1,6 @@ +#!/bin/sh -f +for i in $* +do + i=`echo $i | sed -e 's/^rfc//' -e 's/\.txt$//'` + fetch "http://www.ietf.org/rfc/rfc${i}.txt" +done diff --git a/doc/rfc/index b/doc/rfc/index new file mode 100644 index 0000000..fea5f71 --- /dev/null +++ b/doc/rfc/index @@ -0,0 +1,119 @@ + 952: DOD INTERNET HOST TABLE SPECIFICATION +1032: DOMAIN ADMINISTRATORS GUIDE +1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE +1034: DOMAIN NAMES - CONCEPTS AND FACILITIES +1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION +1101: DNS Encoding of Network Names and Other Types +1122: Requirements for Internet Hosts -- Communication Layers +1123: Requirements for Internet Hosts -- Application and Support +1183: New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT) +1348: DNS NSAP RRs +1535: A Security Problem and Proposed Correction + With Widely Deployed DNS Software +1536: Common DNS Implementation Errors and Suggested Fixes +1537: Common DNS Data File Configuration Errors +1591: Domain Name System Structure and Delegation +1611: DNS Server MIB Extensions +1612: DNS Resolver MIB Extensions +1706: DNS NSAP Resource Records +1712: DNS Encoding of Geographical Location +1750: Randomness Recommendations for Security +1876: A Means for Expressing Location Information in the Domain Name System +1886: DNS Extensions to support IP version 6 +1982: Serial Number Arithmetic +1995: Incremental Zone Transfer in DNS +1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) +2052: A DNS RR for specifying the location of services (DNS SRV) +2104: HMAC: Keyed-Hashing for Message Authentication +2119: Key words for use in RFCs to Indicate Requirement Levels +2133: Basic Socket Interface Extensions for IPv6 +2136: Dynamic Updates in the Domain Name System (DNS UPDATE) +2137: Secure Domain Name System Dynamic Update +2163: Using the Internet DNS to Distribute MIXER + Conformant Global Address Mapping (MCGAM) +2168: Resolution of Uniform Resource Identifiers using the Domain Name System +2181: Clarifications to the DNS Specification +2230: Key Exchange Delegation Record for the DNS +2308: Negative Caching of DNS Queries (DNS NCACHE) +2317: Classless IN-ADDR.ARPA delegation +2373: IP Version 6 Addressing Architecture +2374: An IPv6 Aggregatable Global Unicast Address Format +2375: IPv6 Multicast Address Assignments +2418: IETF Working Group Guidelines and Procedures +2535: Domain Name System Security Extensions +2536: DSA KEYs and SIGs in the Domain Name System (DNS) +2537: RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) +2538: Storing Certificates in the Domain Name System (DNS) +2539: Storage of Diffie-Hellman Keys in the Domain Name System (DNS) +2540: Detached Domain Name System (DNS) Information +2541: DNS Security Operational Considerations +2553: Basic Socket Interface Extensions for IPv6 +2671: Extension Mechanisms for DNS (EDNS0) +2672: Non-Terminal DNS Name Redirection +2673: Binary Labels in the Domain Name System +2782: A DNS RR for specifying the location of services (DNS SRV) +2825: A Tangled Web: Issues of I18N, Domain Names, and the + Other Internet protocols +2826: IAB Technical Comment on the Unique DNS Root +2845: Secret Key Transaction Authentication for DNS (TSIG) +2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering +2915: The Naming Authority Pointer (NAPTR) DNS Resource Record +2929: Domain Name System (DNS) IANA Considerations +2930: Secret Key Establishment for DNS (TKEY RR) +2931: DNS Request and Transaction Signatures ( SIG(0)s ) +3007: Secure Domain Name System (DNS) Dynamic Update +3008: Domain Name System Security (DNSSEC) Signing Authority +3056: Connection of IPv6 Domains via IPv4 Clouds +3071: Reflections on the DNS, RFC 1591, and Categories of Domains +3090: DNS Security Extension Clarification on Zone Status +3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) +3123: A DNS RR Type for Lists of Address Prefixes (APL RR) +3152: Delegation of IP6.ARPA +3197: Applicability Statement for DNS MIB Extensions +3225: Indicating Resolver Support of DNSSEC +3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements +3258: Distributing Authoritative Name Servers via Shared Unicast Addresses +3363: Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS) +3364: Tradeoffs in Domain Name System (DNS) Support + for Internet Protocol version 6 (IPv6) +3425: Obsoleting IQUERY +3445: Limiting the Scope of the KEY Resource Record (RR) +3490: Internationalizing Domain Names In Applications (IDNA) +3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) +3492: Punycode:A Bootstring encoding of Unicode for + Internationalized Domain Names in Applications (IDNA) +3493: Basic Socket Interface Extensions for IPv6 +3513: Internet Protocol Version 6 (IPv6) Addressing Architecture +3596: DNS Extensions to Support IP Version 6 +3597: Handling of Unknown DNS Resource Record (RR) Types +3645: Generic Security Service Algorithm for + Secret Key Transaction Authentication for DNS (GSS-TSIG) +3655: Redefinition of DNS Authenticated Data (AD) bit +3658: Delegation Signer (DS) Resource Record (RR) +3757: Domain Name System KEY (DNSKEY) Resource Record (RR) + Secure Entry Point (SEP) Flag +3833: Threat Analysis of the Domain Name System (DNS) +3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format +3901: DNS IPv6 Transport Operational Guidelines +4025: A Method for Storing IPsec Keying Material in DNS +4033: DNS Security Introduction and Requirements +4034: Resource Records for the DNS Security Extensions +4035: Protocol Modifications for the DNS Security Extensions +4074: Common Misbehavior Against DNS Queries for IPv6 Addresses +4159: Deprecation of "ip6.int" +4193: Unique Local IPv6 Unicast Addresses +4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints +4343: Domain Name System (DNS) Case Insensitivity Clarification +4367: What's in a Name: False Assumptions about DNS Names +4398: Storing Certificates in the Domain Name System (DNS) +4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record +4408: Sender Policy Framework (SPF) for Authorizing Use of Domains + in E-Mail, Version 1 +4470: Minimally Covering NSEC Records and DNSSEC On-line Signing +4634: US Secure Hash Algorithms (SHA and HMAC-SHA) +4641: DNSSEC Operational Practices +4648: The Base16, Base32, and Base64 Data Encodings +4701: A DNS Resource Record (RR) for Encoding + Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) +5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence diff --git a/doc/rfc/rfc1032.txt b/doc/rfc/rfc1032.txt new file mode 100644 index 0000000..0e82721 --- /dev/null +++ b/doc/rfc/rfc1032.txt @@ -0,0 +1,781 @@ +Network Working Group M. Stahl +Request for Comments: 1032 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS GUIDE + + +STATUS OF THIS MEMO + + This memo describes procedures for registering a domain with the + Network Information Center (NIC) of Defense Data Network (DDN), and + offers guidelines on the establishment and administration of a domain + in accordance with the requirements specified in RFC-920. It is + intended for use by domain administrators. This memo should be used + in conjunction with RFC-920, which is an official policy statement of + the Internet Activities Board (IAB) and the Defense Advanced Research + Projects Agency (DARPA). Distribution of this memo is unlimited. + +BACKGROUND + + Domains are administrative entities that provide decentralized + management of host naming and addressing. The domain-naming system + is distributed and hierarchical. + + The NIC is designated by the Defense Communications Agency (DCA) to + provide registry services for the domain-naming system on the DDN and + DARPA portions of the Internet. + + As registrar of top-level and second-level domains, as well as + administrator of the root domain name servers on behalf of DARPA and + DDN, the NIC is responsible for maintaining the root server zone + files and their binary equivalents. In addition, the NIC is + responsible for administering the top-level domains of "ARPA," "COM," + "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it + becomes feasible for other appropriate organizations to assume those + responsibilities. + + It is recommended that the guidelines described in this document be + used by domain administrators in the establishment and control of + second-level domains. + +THE DOMAIN ADMINISTRATOR + + The role of the domain administrator (DA) is that of coordinator, + manager, and technician. If his domain is established at the second + level or lower in the tree, the DA must register by interacting with + the management of the domain directly above his, making certain that + + + +Stahl [Page 1] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + his domain satisfies all the requirements of the administration under + which his domain would be situated. To find out who has authority + over the name space he wishes to join, the DA can ask the NIC + Hostmaster. Information on contacts for the top-level and second- + level domains can also be found on line in the file NETINFO:DOMAIN- + CONTACTS.TXT, which is available from the NIC via anonymous FTP. + + The DA should be technically competent; he should understand the + concepts and procedures for operating a domain server, as described + in RFC-1034, and make sure that the service provided is reliable and + uninterrupted. It is his responsibility or that of his delegate to + ensure that the data will be current at all times. As a manager, the + DA must be able to handle complaints about service provided by his + domain name server. He must be aware of the behavior of the hosts in + his domain, and take prompt action on reports of problems, such as + protocol violations or other serious misbehavior. The administrator + of a domain must be a responsible person who has the authority to + either enforce these actions himself or delegate them to someone + else. + + Name assignments within a domain are controlled by the DA, who should + verify that names are unique within his domain and that they conform + to standard naming conventions. He furnishes access to names and + name-related information to users both inside and outside his domain. + He should work closely with the personnel he has designated as the + "technical and zone" contacts for his domain, for many administrative + decisions will be made on the basis of input from these people. + +THE DOMAIN TECHNICAL AND ZONE CONTACT + + A zone consists of those contiguous parts of the domain tree for + which a domain server has complete information and over which it has + authority. A domain server may be authoritative for more than one + zone. The domain technical/zone contact is the person who tends to + the technical aspects of maintaining the domain's name server and + resolver software, and database files. He keeps the name server + running, and interacts with technical people in other domains and + zones to solve problems that affect his zone. + +POLICIES + + Domain or host name choices and the allocation of domain name space + are considered to be local matters. In the event of conflicts, it is + the policy of the NIC not to get involved in local disputes or in the + local decision-making process. The NIC will not act as referee in + disputes over such matters as who has the "right" to register a + particular top-level or second-level domain for an organization. The + NIC considers this a private local matter that must be settled among + + + +Stahl [Page 2] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + the parties involved prior to their commencing the registration + process with the NIC. Therefore, it is assumed that the responsible + person for a domain will have resolved any local conflicts among the + members of his domain before registering that domain with the NIC. + The NIC will give guidance, if requested, by answering specific + technical questions, but will not provide arbitration in disputes at + the local level. This policy is also in keeping with the distributed + hierarchical nature of the domain-naming system in that it helps to + distribute the tasks of solving problems and handling questions. + + Naming conventions for hosts should follow the rules specified in + RFC-952. From a technical standpoint, domain names can be very long. + Each segment of a domain name may contain up to 64 characters, but + the NIC strongly advises DAs to choose names that are 12 characters + or fewer, because behind every domain system there is a human being + who must keep track of the names, addresses, contacts, and other data + in a database. The longer the name, the more likely the data + maintainer is to make a mistake. Users also will appreciate shorter + names. Most people agree that short names are easier to remember and + type; most domain names registered so far are 12 characters or fewer. + + Domain name assignments are made on a first-come-first-served basis. + The NIC has chosen not to register individual hosts directly under + the top-level domains it administers. One advantage of the domain + naming system is that administration and data maintenance can be + delegated down a hierarchical tree. Registration of hosts at the + same level in the tree as a second-level domain would dilute the + usefulness of this feature. In addition, the administrator of a + domain is responsible for the actions of hosts within his domain. We + would not want to find ourselves in the awkward position of policing + the actions of individual hosts. Rather, the subdomains registered + under these top-level domains retain the responsibility for this + function. + + Countries that wish to be registered as top-level domains are + required to name themselves after the two-letter country code listed + in the international standard ISO-3166. In some cases, however, the + two-letter ISO country code is identical to a state code used by the + U.S. Postal Service. Requests made by countries to use the three- + letter form of country code specified in the ISO-3166 standard will + be considered in such cases so as to prevent possible conflicts and + confusion. + + + + + + + + + +Stahl [Page 3] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +HOW TO REGISTER + + Obtain a domain questionnaire from the NIC hostmaster, or FTP the + file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA. + + Fill out the questionnaire completely. Return it via electronic mail + to HOSTMASTER@SRI-NIC.ARPA. + + The APPENDIX to this memo contains the application form for + registering a top-level or second-level domain with the NIC. It + supersedes the version of the questionnaire found in RFC-920. The + application should be submitted by the person administratively + responsible for the domain, and must be filled out completely before + the NIC will authorize establishment of a top-level or second-level + domain. The DA is responsible for keeping his domain's data current + with the NIC or with the registration agent with which his domain is + registered. For example, the CSNET and UUCP managements act as + domain filters, processing domain applications for their own + organizations. They pass pertinent information along periodically to + the NIC for incorporation into the domain database and root server + files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT + outlines this procedure. It is highly recommended that the DA review + this information periodically and provide any corrections or + additions. Corrections should be submitted via electronic mail. + +WHICH DOMAIN NAME? + + The designers of the domain-naming system initiated several general + categories of names as top-level domain names, so that each could + accommodate a variety of organizations. The current top-level + domains registered with the DDN Network Information Center are ARPA, + COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country + domains. To join one of these, a DA needs to be aware of the purpose + for which it was intended. + + "ARPA" is a temporary domain. It is by default appended to the + names of hosts that have not yet joined a domain. When the system + was begun in 1984, the names of all hosts in the Official DoD + Internet Host Table maintained by the NIC were changed by adding + of the label ".ARPA" in order to accelerate a transition to the + domain-naming system. Another reason for the blanket name changes + was to force hosts to become accustomed to using the new style + names and to modify their network software, if necessary. This + was done on a network-wide basis and was directed by DCA in DDN + Management Bulletin No. 22. Hosts that fall into this domain will + eventually move to other branches of the domain tree. + + + + + +Stahl [Page 4] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + "COM" is meant to incorporate subdomains of companies and + businesses. + + "EDU" was initiated to accommodate subdomains set up by + universities and other educational institutions. + + "GOV" exists to act as parent domain for subdomains set up by + government agencies. + + "MIL" was initiated to act as parent to subdomains that are + developed by military organizations. + + "NET" was introduced as a parent domain for various network-type + organizations. Organizations that belong within this top-level + domain are generic or network-specific, such as network service + centers and consortia. "NET" also encompasses network + management-related organizations, such as information centers and + operations centers. + + "ORG" exists as a parent to subdomains that do not clearly fall + within the other top-level domains. This may include technical- + support groups, professional societies, or similar organizations. + + One of the guidelines in effect in the domain-naming system is that a + host should have only one name regardless of what networks it is + connected to. This implies, that, in general, domain names should + not include routing information or addresses. For example, a host + that has one network connection to the Internet and another to BITNET + should use the same name when talking to either network. For a + description of the syntax of domain names, please refer to Section 3 + of RFC-1034. + +VERIFICATION OF DATA + + The verification process can be accomplished in several ways. One of + these is through the NIC WHOIS server. If he has access to WHOIS, + the DA can type the command "whois domain ". + The reply from WHOIS will supply the following: the name and address + of the organization "owning" the domain; the name of the domain; its + administrative, technical, and zone contacts; the host names and + network addresses of sites providing name service for the domain. + + + + + + + + + + +Stahl [Page 5] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + Example: + + @whois domain rice.edu + + Rice University (RICE-DOM) + Advanced Studies and Research + Houston, TX 77001 + + Domain Name: RICE.EDU + + Administrative Contact: + Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834 + Technical Contact, Zone Contact: + Riffle, Vicky R. (VRR) rif@RICE.EDU + (713) 527-8101 ext 3844 + + Domain servers: + + RICE.EDU 128.42.5.1 + PENDRAGON.CS.PURDUE.EDU 128.10.2.5 + + + Alternatively, the DA can send an electronic mail message to + SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the + DA should type "whois domain ". The requested + information will be returned via electronic mail. This method is + convenient for sites that do not have access to the NIC WHOIS + service. + + The initial application for domain authorization should be submitted + via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The + questionnaire described in the appendix may be used or a separate + application can be FTPed from host SRI-NIC.ARPA. The information + provided by the administrator will be reviewed by hostmaster + personnel for completeness. There will most likely be a few + exchanges of correspondence via electronic mail, the preferred method + of communication, prior to authorization of the domain. + +HOW TO GET MORE INFORMATION + + An informational table of the top-level domains and their root + servers is contained in the file NETINFO:DOMAINS.TXT online at SRI- + NIC.ARPA. This table can be obtained by FTPing the file. + Alternatively, the information can be acquired by opening a TCP or + UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA, + and invoking the command "ALL-DOM". + + + + + +Stahl [Page 6] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + The following online files, all available by FTP from SRI-NIC.ARPA, + contain pertinent domain information: + + - NETINFO:DOMAINS.TXT, a table of all top-level domains and the + network addresses of the machines providing domain name + service for them. It is updated each time a new top-level + domain is approved. + + - NETINFO:DOMAIN-INFO.TXT contains a concise list of all + top-level and second-level domain names registered with the + NIC and is updated monthly. + + - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the + top level and second-level domains, but includes the + administrative, technical and zone contacts for each as well. + + - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be + completed before registering a top-level or second-level + domain. + + For either general or specific information on the domain system, do + one or more of the following: + + 1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA + + 2. Call the toll-free NIC hotline at (800) 235-3155 + + 3. Use FTP to get background RFCs and other files maintained + online at the NIC. Some pertinent RFCs are listed below in + the REFERENCES section of this memo. + + + + + + + + + + + + + + + + + + + + + +Stahl [Page 7] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +REFERENCES + + The references listed here provide important background information + on the domain-naming system. Path names of the online files + available via anonymous FTP from the SRI-NIC.ARPA host are noted in + brackets. + + 1. Defense Communications Agency DDN Defense Communications + System, DDN Management Bulletin No. 22, Domain Names + Transition, March 1984. + [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ] + + 2. Defense Communications Agency DDN Defense Communications + System, DDN Management Bulletin No. 32, Phase I of the Domain + Name Implementation, January 1987. + [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ] + + 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname + Server", RFC-953, DDN Network Information Center, SRI + International, October 1985. [ RFC:RFC953.TXT ] + + 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD + Internet Host Table Specification", RFC-952, DDN Network + Information Center, SRI International, October 1985. + [ RFC:RFC952.TXT ] + + 5. ISO, "Codes for the Representation of Names of Countries", + ISO-3166, International Standards Organization, May 1981. + [ Not online ] + + 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031, + Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ] + + 7. Lottor, M.K., "Domain Administrators Operations Guide", + RFC-1033, DDN Network Information Center, SRI International, + July 1987. [ RFC:RFC1033.TXT ] + + 8. Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC-1034, USC Information Sciences Institute, October 1987. + [ RFC:RFC1034.TXT ] + + 9. Mockapetris, P., "Domain Names - Implementation and + Specification", RFC-1035, USC Information Sciences Institute, + October 1987. [ RFC:RFC1035.TXT ] + + 10. Mockapetris, P., "The Domain Name System", Proceedings of the + IFIP 6.5 Working Conference on Computer Message Services, + Nottingham, England, May 1984. Also as ISI/RS-84-133, June + + + +Stahl [Page 8] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + 1984. [ Not online ] + + 11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server + Design for Distributed Systems", Proceedings of the Seventh + International Conference on Computer Communication, October + 30 to November 3 1984, Sidney, Australia. Also as + ISI/RS-84-132, June 1984. [ Not online ] + + 12. Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET-CIC, BBN Laboratories, January 1986. + [ RFC:RFC974.TXT ] + + 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881, + USC Information Sciences Institute, November 1983. + [ RFC:RFC881.TXT ] + + 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010 + USC Information Sciences Institute, May 1986. + [ RFC:RFC1010.TXT ] + + 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020, + SRI, November 1987. + [ RFC:RFC1020.TXT ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stahl [Page 9] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +APPENDIX + + The following questionnaire may be FTPed from SRI-NIC.ARPA as + NETINFO:DOMAIN-TEMPLATE.TXT. + + --------------------------------------------------------------------- + + To establish a domain, the following information must be sent to the + NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA): + + NOTE: The key people must have electronic mailboxes and NIC + "handles," unique NIC database identifiers. If you have access to + "WHOIS", please check to see if you are registered and if so, make + sure the information is current. Include only your handle and any + changes (if any) that need to be made in your entry. If you do not + have access to "WHOIS", please provide all the information indicated + and a NIC handle will be assigned. + + (1) The name of the top-level domain to join. + + For example: COM + + (2) The NIC handle of the administrative head of the organization. + Alternately, the person's name, title, mailing address, phone number, + organization, and network mailbox. This is the contact point for + administrative and policy questions about the domain. In the case of + a research project, this should be the principal investigator. + + For example: + + Administrator + + Organization The NetWorthy Corporation + Name Penelope Q. Sassafrass + Title President + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA 94302-1212 + Phone Number (415) 123-4567 + Net Mailbox Sassafrass@ECHO.TNC.COM + NIC Handle PQS + + (3) The NIC handle of the technical contact for the domain. + Alternately, the person's name, title, mailing address, phone number, + organization, and network mailbox. This is the contact point for + problems concerning the domain or zone, as well as for updating + information about the domain or zone. + + + + +Stahl [Page 10] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + For example: + + Technical and Zone Contact + + Organization The NetWorthy Corporation + Name Ansel A. Aardvark + Title Executive Director + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA. 94302-1212 + Phone Number (415) 123-6789 + Net Mailbox Aardvark@ECHO.TNC.COM + NIC Handle AAA2 + + (4) The name of the domain (up to 12 characters). This is the name + that will be used in tables and lists associating the domain with the + domain server addresses. [While, from a technical standpoint, domain + names can be quite long (programmers beware), shorter names are + easier for people to cope with.] + + For example: TNC + + (5) A description of the servers that provide the domain service for + translating names to addresses for hosts in this domain, and the date + they will be operational. + + A good way to answer this question is to say "Our server is + supplied by person or company X and does whatever their standard + issue server does." + + For example: Our server is a copy of the one operated by + the NIC; it will be installed and made operational on + 1 November 1987. + + (6) Domains must provide at least two independent servers for the + domain. Establishing the servers in physically separate locations + and on different PSNs is strongly recommended. A description of the + server machine and its backup, including + + + + + + + + + + + + + +Stahl [Page 11] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (a) Hardware and software (using keywords from the Assigned + Numbers RFC). + + (b) Host domain name and network addresses (which host on which + network for each connected network). + + (c) Any domain-style nicknames (please limit your domain-style + nickname request to one) + + For example: + + - Hardware and software + + VAX-11/750 and UNIX, or + IBM-PC and MS-DOS, or + DEC-1090 and TOPS-20 + + - Host domain names and network addresses + + BAR.FOO.COM 10.9.0.193 on ARPANET + + - Domain-style nickname + + BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET) + + (7) Planned mapping of names of any other network hosts, other than + the server machines, into the new domain's naming space. + + For example: + + BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM + BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM + BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM + + + (8) An estimate of the number of hosts that will be in the domain. + + (a) Initially + (b) Within one year + (c) Two years + (d) Five years. + + For example: + + (a) Initially = 50 + (b) One year = 100 + (c) Two years = 200 + (d) Five years = 500 + + + +Stahl [Page 12] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (9) The date you expect the fully qualified domain name to become + the official host name in HOSTS.TXT. + + Please note: If changing to a fully qualified domain name (e.g., + FOO.BAR.COM) causes a change in the official host name of an + ARPANET or MILNET host, DCA approval must be obtained beforehand. + Allow 10 working days for your requested changes to be processed. + + ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites + should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for + further instructions. + + (10) Please describe your organization briefly. + + For example: The NetWorthy Corporation is a consulting + organization of people working with UNIX and the C language in an + electronic networking environment. It sponsors two technical + conferences annually and distributes a bimonthly newsletter. + + --------------------------------------------------------------------- + + This example of a completed application corresponds to the examples + found in the companion document RFC-1033, "Domain Administrators + Operations Guide." + + (1) The name of the top-level domain to join. + + COM + + (2) The NIC handle of the administrative contact person. + + NIC Handle JAKE + + (3) The NIC handle of the domain's technical and zone + contact person. + + NIC Handle DLE6 + + (4) The name of the domain. + + SRI + + (5) A description of the servers. + + Our server is the TOPS20 server JEEVES supplied by ISI; it + will be installed and made operational on 1 July 1987. + + + + + +Stahl [Page 13] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (6) A description of the server machine and its backup: + + (a) Hardware and software + + DEC-1090T and TOPS20 + DEC-2065 and TOPS20 + + (b) Host domain name and network address + + KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET + STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET + + (c) Domain-style nickname + + None + + (7) Planned mapping of names of any other network hosts, other than + the server machines, into the new domain's naming space. + + SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM + SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM + + (8) An estimate of the number of hosts that will be directly within + this domain. + + (a) Initially = 50 + (b) One year = 100 + (c) Two years = 200 + (d) Five years = 500 + + (9) A date when you expect the fully qualified domain name to become + the official host name in HOSTS.TXT. + + 31 September 1987 + + (10) Brief description of organization. + + SRI International is an independent, nonprofit, scientific + research organization. It performs basic and applied research + for government and commercial clients, and contributes to + worldwide economic, scientific, industrial, and social progress + through research and related services. + + + + + + + + + +Stahl [Page 14] + diff --git a/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt new file mode 100644 index 0000000..37029fd --- /dev/null +++ b/doc/rfc/rfc1033.txt @@ -0,0 +1,1229 @@ +Network Working Group M. Lottor +Request For Comments: 1033 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS OPERATIONS GUIDE + + + +STATUS OF THIS MEMO + + This RFC provides guidelines for domain administrators in operating a + domain server and maintaining their portion of the hierarchical + database. Familiarity with the domain system is assumed. + Distribution of this memo is unlimited. + +ACKNOWLEDGMENTS + + This memo is a formatted collection of notes and excerpts from the + references listed at the end of this document. Of particular mention + are Paul Mockapetris and Kevin Dunlap. + +INTRODUCTION + + A domain server requires a few files to get started. It will + normally have some number of boot/startup files (also known as the + "safety belt" files). One section will contain a list of possible + root servers that the server will use to find the up-to-date list of + root servers. Another section will list the zone files to be loaded + into the server for your local domain information. A zone file + typically contains all the data for a particular domain. This guide + describes the data formats that can be used in zone files and + suggested parameters to use for certain fields. If you are + attempting to do anything advanced or tricky, consult the appropriate + domain RFC's for more details. + + Note: Each implementation of domain software may require different + files. Zone files are standardized but some servers may require + other startup files. See the appropriate documentation that comes + with your software. See the appendix for some specific examples. + +ZONES + + A zone defines the contents of a contiguous section of the domain + space, usually bounded by administrative boundaries. There will + typically be a separate data file for each zone. The data contained + in a zone file is composed of entries called Resource Records (RRs). + + + + +Lottor [Page 1] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + You may only put data in your domain server that you are + authoritative for. You must not add entries for domains other than + your own (except for the special case of "glue records"). + + A domain server will probably read a file on start-up that lists the + zones it should load into its database. The format of this file is + not standardized and is different for most domain server + implementations. For each zone it will normally contain the domain + name of the zone and the file name that contains the data to load for + the zone. + +ROOT SERVERS + + A resolver will need to find the root servers when it first starts. + When the resolver boots, it will typically read a list of possible + root servers from a file. + + The resolver will cycle through the list trying to contact each one. + When it finds a root server, it will ask it for the current list of + root servers. It will then discard the list of root servers it read + from the data file and replace it with the current list it received. + + Root servers will not change very often. You can get the names of + current root servers from the NIC. + + FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to + NIC@SRI-NIC.ARPA. + + As of this date (June 1987) they are: + + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + +RESOURCE RECORDS + + Records in the zone data files are called resource records (RRs). + They are specified in RFC-883 and RFC-973. An RR has a standard + format as shown: + + [] [] + + The record is divided into fields which are separated by white space. + + + + The name field defines what domain name applies to the given + + + +Lottor [Page 2] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + RR. In some cases the name field can be left blank and it will + default to the name field of the previous RR. + + + + TTL stands for Time To Live. It specifies how long a domain + resolver should cache the RR before it throws it out and asks a + domain server again. See the section on TTL's. If you leave + the TTL field blank it will default to the minimum time + specified in the SOA record (described later). + + + + The class field specifies the protocol group. If left blank it + will default to the last class specified. + + + + The type field specifies what type of data is in the RR. See + the section on types. + + + + The data field is defined differently for each type and class + of data. Popular RR data formats are described later. + + The domain system does not guarantee to preserve the order of + resource records. Listing RRs (such as multiple address records) in + a certain order does not guarantee they will be used in that order. + + Case is preserved in names and data fields when loaded into the name + server. All comparisons and lookups in the name server are case + insensitive. + + Parenthesis ("(",")") are used to group data that crosses a line + boundary. + + A semicolon (";") starts a comment; the remainder of the line is + ignored. + + The asterisk ("*") is used for wildcarding. + + The at-sign ("@") denotes the current default domain name. + + + + + + + + +Lottor [Page 3] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +NAMES + + A domain name is a sequence of labels separated by dots. + + Domain names in the zone files can be one of two types, either + absolute or relative. An absolute name is the fully qualified domain + name and is terminated with a period. A relative name does not + terminate with a period, and the current default domain is appended + to it. The default domain is usually the name of the domain that was + specified in the boot file that loads each zone. + + The domain system allows a label to contain any 8-bit character. + Although the domain system has no restrictions, other protocols such + as SMTP do have name restrictions. Because of other protocol + restrictions, only the following characters are recommended for use + in a host name (besides the dot separator): + + "A-Z", "a-z", "0-9", dash and underscore + +TTL's (Time To Live) + + It is important that TTLs are set to appropriate values. The TTL is + the time (in seconds) that a resolver will use the data it got from + your server before it asks your server again. If you set the value + too low, your server will get loaded down with lots of repeat + requests. If you set it too high, then information you change will + not get distributed in a reasonable amount of time. If you leave the + TTL field blank, it will default to what is specified in the SOA + record for the zone. + + Most host information does not change much over long time periods. A + good way to set up your TTLs would be to set them at a high value, + and then lower the value if you know a change will be coming soon. + You might set most TTLs to anywhere between a day (86400) and a week + (604800). Then, if you know some data will be changing in the near + future, set the TTL for that RR down to a lower value (an hour to a + day) until the change takes place, and then put it back up to its + previous value. + + Also, all RRs with the same name, class, and type should have the + same TTL value. + +CLASSES + + The domain system was designed to be protocol independent. The class + field is used to identify the protocol group that each RR is in. + + The class of interest to people using TCP/IP software is the class + + + +Lottor [Page 4] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + "Internet". Its standard designation is "IN". + + A zone file should only contain RRs of the same class. + +TYPES + + There are many defined RR types. For a complete list, see the domain + specification RFCs. Here is a list of current commonly used types. + The data for each type is described in the data section. + + Designation Description + ========================================== + SOA Start Of Authority + NS Name Server + + A Internet Address + CNAME Canonical Name (nickname pointer) + HINFO Host Information + WKS Well Known Services + + MX Mail Exchanger + + PTR Pointer + +SOA (Start Of Authority) + + [] [] SOA ( + + + + + ) + + The Start Of Authority record designates the start of a zone. The + zone ends at the next SOA record. + + is the name of the zone. + + is the name of the host on which the master zone file + resides. + + is a mailbox for the person responsible for the zone. It is + formatted like a mailing address but the at-sign that normally + separates the user from the host name is replaced with a dot. + + is the version number of the zone file. It should be + incremented anytime a change is made to data in the zone. + + + + +Lottor [Page 5] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + is how long, in seconds, a secondary name server is to + check with the primary name server to see if an update is needed. A + good value here would be one hour (3600). + + is how long, in seconds, a secondary name server is to retry + after a failure to check for a refresh. A good value here would be + 10 minutes (600). + + is the upper limit, in seconds, that a secondary name server + is to use the data before it expires for lack of getting a refresh. + You want this to be rather large, and a nice value is 3600000, about + 42 days. + + is the minimum number of seconds to be used for TTL values + in RRs. A minimum of at least a day is a good value here (86400). + + There should only be one SOA record per zone. A sample SOA record + would look something like: + + @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( + 45 ;serial + 3600 ;refresh + 600 ;retry + 3600000 ;expire + 86400 ) ;minimum + + +NS (Name Server) + + [] [] NS + + The NS record lists the name of a machine that provides domain + service for a particular domain. The name associated with the RR is + the domain name and the data portion is the name of a host that + provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide + name lookup service for the domain COM then the following entries + would be used: + + COM. NS SRI-NIC.ARPA. + NS C.ISI.EDU. + + Note that the machines providing name service do not have to live in + the named domain. There should be one NS record for each server for + a domain. Also note that the name "COM" defaults for the second NS + record. + + NS records for a domain exist in both the zone that delegates the + domain, and in the domain itself. + + + +Lottor [Page 6] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +GLUE RECORDS + + If the name server host for a particular domain is itself inside the + domain, then a 'glue' record will be needed. A glue record is an A + (address) RR that specifies the address of the server. Glue records + are only needed in the server delegating the domain, not in the + domain itself. If for example the name server for domain SRI.COM was + KL.SRI.COM, then the NS record would look like this, but you will + also need to have the following A record. + + SRI.COM. NS KL.SRI.COM. + KL.SRI.COM. A 10.1.0.2 + + +A (Address) + + [] [] A
+ + The data for an A record is an internet address in dotted decimal + form. A sample A record might look like: + + SRI-NIC.ARPA. A 10.0.0.51 + + There should be one A record for each address of a host. + +CNAME ( Canonical Name) + + [] [] CNAME + + The CNAME record is used for nicknames. The name associated with the + RR is the nickname. The data portion is the official name. For + example, a machine named SRI-NIC.ARPA may want to have the nickname + NIC.ARPA. In that case, the following RR would be used: + + NIC.ARPA. CNAME SRI-NIC.ARPA. + + There must not be any other RRs associated with a nickname of the + same class. + + Nicknames are also useful when a host changes it's name. In that + case, it is usually a good idea to have a CNAME pointer so that + people still using the old name will get to the right place. + + + + + + + + + +Lottor [Page 7] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +HINFO (Host Info) + + [] [] HINFO + + The HINFO record gives information about a particular host. The data + is two strings separated by whitespace. The first string is a + hardware description and the second is software. The hardware is + usually a manufacturer name followed by a dash and model designation. + The software string is usually the name of the operating system. + + Official HINFO types can be found in the latest Assigned Numbers RFC, + the latest of which is RFC-1010. The Hardware type is called the + Machine name and the Software type is called the System name. + + Some sample HINFO records: + + SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 + UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX + + +WKS (Well Known Services) + + [] [] WKS
+ + The WKS record is used to list Well Known Services a host provides. + WKS's are defined to be services on port numbers below 256. The WKS + record lists what services are available at a certain address using a + certain protocol. The common protocols are TCP or UDP. A sample WKS + record for a host offering the same services on all address would + look like: + + Official protocol names can be found in the latest Assigned Numbers + RFC, the latest of which is RFC-1010. + + SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP + WKS 10.0.0.51 UDP TIME + WKS 26.0.0.73 TCP TELNET FTP SMTP + WKS 26.0.0.73 UDP TIME + +MX (Mail Exchanger) (See RFC-974 for more details.) + + [] [] MX + + MX records specify where mail for a domain name should be delivered. + There may be multiple MX records for a particular name. The + preference value specifies the order a mailer should try multiple MX + records when delivering mail. Zero is the highest preference. + Multiple records for the same name may have the same preference. + + + +Lottor [Page 8] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + A host BAR.FOO.COM may want its mail to be delivered to the host + PO.FOO.COM and would then use the MX record: + + BAR.FOO.COM. MX 10 PO.FOO.COM. + + A host BAZ.FOO.COM may want its mail to be delivered to one of three + different machines, in the following order: + + BAZ.FOO.COM. MX 10 PO1.FOO.COM. + MX 20 PO2.FOO.COM. + MX 30 PO3.FOO.COM. + + An entire domain of hosts not connected to the Internet may want + their mail to go through a mail gateway that knows how to deliver + mail to them. If they would like mail addressed to any host in the + domain FOO.COM to go through the mail gateway they might use: + + FOO.COM. MX 10 RELAY.CS.NET. + *.FOO.COM. MX 20 RELAY.CS.NET. + + Note that you can specify a wildcard in the MX record to match on + anything in FOO.COM, but that it won't match a plain FOO.COM. + +IN-ADDR.ARPA + + The structure of names in the domain system is set up in a + hierarchical way such that the address of a name can be found by + tracing down the domain tree contacting a server for each label of + the name. Because of this 'indexing' based on name, there is no easy + way to translate a host address back into its host name. + + In order to do the reverse translation easily, a domain was created + that uses hosts' addresses as part of a name that then points to the + data for that host. In this way, there is now an 'index' to hosts' + RRs based on their address. This address mapping domain is called + IN-ADDR.ARPA. Within that domain are subdomains for each network, + based on network number. Also, for consistency and natural + groupings, the 4 octets of a host number are reversed. + + For example, the ARPANET is net 10. That means there is a domain + called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at + 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA + (who's address is 10.0.0.51). Since the NIC is also on the MILNET + (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- + ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format + of these special pointers is defined below along with the examples + for the NIC. + + + + +Lottor [Page 9] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +PTR + + [] [] PTR + + The PTR record is used to let special names point to some other + location in the domain tree. They are mainly used in the IN- + ADDR.ARPA records for translation of addresses to names. PTR's + should use official names and not aliases. + + For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 + would have the following records in the respective zone files for net + 10 and net 26: + + 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + +GATEWAY PTR's + + The IN-ADDR tree is also used to locate gateways on a particular + network. Gateways have the same kind of PTR RRs as hosts (as above) + but in addition they have other PTRs used to locate them by network + number alone. These records have only 1, 2, or 3 octets as part of + the name depending on whether they are class A, B, or C networks, + respectively. + + Lets take the SRI-CSL gateway for example. It connects 3 different + networks, one class A, one class B and one class C. It will have the + standard RR's for a host in the CSL.SRI.COM zone: + + GW.CSL.SRI.COM. A 10.2.0.2 + A 128.18.1.1 + A 192.12.33.2 + + Also, in 3 different zones (one for each network), it will have one + of the following number to name translation pointers: + + 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + In addition, in each of the same 3 zones will be one of the following + gateway location pointers: + + 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + +Lottor [Page 10] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +INSTRUCTIONS + + Adding a subdomain. + + To add a new subdomain to your domain: + + Setup the other domain server and/or the new zone file. + + Add an NS record for each server of the new domain to the zone + file of the parent domain. + + Add any necessary glue RRs. + + Adding a host. + + To add a new host to your zone files: + + Edit the appropriate zone file for the domain the host is in. + + Add an entry for each address of the host. + + Optionally add CNAME, HINFO, WKS, and MX records. + + Add the reverse IN-ADDR entry for each host address in the + appropriate zone files for each network the host in on. + + Deleting a host. + + To delete a host from the zone files: + + Remove all the hosts' resource records from the zone file of + the domain the host is in. + + Remove all the hosts' PTR records from the IN-ADDR zone files + for each network the host was on. + + Adding gateways. + + Follow instructions for adding a host. + + Add the gateway location PTR records for each network the + gateway is on. + + Deleting gateways. + + Follow instructions for deleting a host. + + Also delete the gateway location PTR records for each network + + + +Lottor [Page 11] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + the gateway was on. + +COMPLAINTS + + These are the suggested steps you should take if you are having + problems that you believe are caused by someone else's name server: + + + 1. Complain privately to the responsible person for the domain. You + can find their mailing address in the SOA record for the domain. + + 2. Complain publicly to the responsible person for the domain. + + 3. Ask the NIC for the administrative person responsible for the + domain. Complain. You can also find domain contacts on the NIC in + the file NETINFO:DOMAIN-CONTACTS.TXT + + 4. Complain to the parent domain authorities. + + 5. Ask the parent authorities to excommunicate the domain. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 12] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +EXAMPLE DOMAIN SERVER DATABASE FILES + + The following examples show how zone files are set up for a typical + organization. SRI will be used as the example organization. SRI has + decided to divided their domain SRI.COM into a few subdomains, one + for each group that wants one. The subdomains are CSL and ISTC. + + Note the following interesting items: + + There are both hosts and domains under SRI.COM. + + CSL.SRI.COM is both a domain name and a host name. + + All the domains are serviced by the same pair of domain servers. + + All hosts at SRI are on net 128.18 except hosts in the CSL domain + which are on net 192.12.33. Note that a domain does not have to + correspond to a physical network. + + The examples do not necessarily correspond to actual data in use + by the SRI domain. + + SRI Domain Organization + + +-------+ + | COM | + +-------+ + | + +-------+ + | SRI | + +-------+ + | + +----------++-----------+ + | | | + +-------+ +------+ +-------+ + | CSL | | ISTC | | Hosts | + +-------+ +------+ +-------+ + | | + +-------+ +-------+ + | Hosts | | Hosts | + +-------+ +-------+ + + + + + + + + + + +Lottor [Page 13] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CONFIG.CMD". Since bootstrap files are not standardized, this + file is presented using a pseudo configuration file syntax.] + + load root server list from file ROOT.SERVERS + load zone SRI.COM. from file SRI.ZONE + load zone CSL.SRI.COM. from file CSL.ZONE + load zone ISTC.SRI.COM. from file ISTC.ZONE + load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE + load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 14] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ROOT.SERVERS". Again, the format of this file is not + standardized.] + + ;list of possible root servers + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 15] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI.ZONE"] + + SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870407 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of an hour + ) + + SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 KL.SRI.COM. + + ;SRI.COM hosts + + KL A 10.1.0.2 + A 128.18.10.6 + MX 10 KL.SRI.COM. + + STRIPE A 10.4.0.2 + STRIPE A 128.18.10.4 + MX 10 STRIPE.SRI.COM. + + NIC CNAME SRI-NIC.ARPA. + + Blackjack A 128.18.2.1 + HINFO VAX-11/780 UNIX + WKS 128.18.2.1 TCP TELNET FTP + + CSL A 192.12.33.2 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER + MX 10 CSL.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 16] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CSL.ZONE"] + + CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870330 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + CSL.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + A 192.12.33.2 + + ;CSL.SRI.COM hosts + + A CNAME CSL.SRI.COM. + B A 192.12.33.3 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.3 TCP TELNET FTP SMTP + GW A 10.2.0.2 + A 192.12.33.1 + A 128.18.1.1 + HINFO PDP-11/23 MOS + SMELLY A 192.12.33.4 + HINFO IMAGEN IMAGEN + SQUIRREL A 192.12.33.5 + HINFO XEROX-1100 INTERLISP + VENUS A 192.12.33.7 + HINFO SYMBOLICS-3600 LISPM + HELIUM A 192.12.33.30 + HINFO SUN-3/160 UNIX + ARGON A 192.12.33.31 + HINFO SUN-3/75 UNIX + RADON A 192.12.33.32 + HINFO SUN-3/75 UNIX + + + + + + + + + + + + + + + +Lottor [Page 17] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ISTC.ZONE"] + + ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + ISTC.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 SPAM.ISTC.SRI.COM. + + ; ISTC hosts + + joyce A 128.18.4.2 + HINFO VAX-11/750 UNIX + bozo A 128.18.0.6 + HINFO SUN UNIX + sundae A 128.18.0.11 + HINFO SUN UNIX + tsca A 128.18.0.201 + A 10.3.0.2 + HINFO VAX-11/750 UNIX + MX 10 TSCA.ISTC.SRI.COM. + tsc CNAME tsca + prmh A 128.18.0.203 + A 10.2.0.51 + HINFO PDP-11/44 UNIX + spam A 128.18.4.3 + A 10.2.0.107 + HINFO VAX-11/780 UNIX + MX 10 SPAM.ISTC.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 18] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRINET.ZONE"] + + 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 18.128.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRINET [128.18.0.0] Address Translations + + ; SRI.COM Hosts + 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. + + ; ISTC.SRI.COM Hosts + 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. + 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. + 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. + 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. + 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. + 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 19] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI-CSL-NET.ZONE"] + + 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870404 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRI-CSL-NET [192.12.33.0] Address Translations + + ; SRI.COM Hosts + 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. + 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. + 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. + 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. + 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. + 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. + 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 20] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +APPENDIX + + BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD + UNIX + + This section describes two BIND implementation specific files; the + boot file and the cache file. BIND has other options, files, and + specifications that are not described here. See the Name Server + Operations Guide for BIND for details. + + The boot file for BIND is usually called "named.boot". This + corresponds to file "CONFIG.CMD" in the example section. + + -------------------------------------------------------- + cache . named.ca + primary SRI.COM SRI.ZONE + primary CSL.SRI.COM CSL.ZONE + primary ISTC.SRI.COM ISTC.ZONE + primary 18.128.IN-ADDR.ARPA SRINET.ZONE + primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE + -------------------------------------------------------- + + The cache file for BIND is usually called "named.ca". This + corresponds to file "ROOT.SERVERS" in the example section. + + ------------------------------------------------- + ;list of possible root servers + . 1 IN NS SRI-NIC.ARPA. + NS C.ISI.EDU. + NS BRL-AOS.ARPA. + NS C.ISI.EDU. + ;and their addresses + SRI-NIC.ARPA. A 10.0.0.51 + A 26.0.0.73 + C.ISI.EDU. A 10.0.0.52 + BRL-AOS.ARPA. A 192.5.25.82 + A 192.5.22.82 + A 128.20.1.2 + A.ISI.EDU. A 26.3.0.103 + ------------------------------------------------- + + + + + + + + + + + +Lottor [Page 21] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +REFERENCES + + [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG, + Department of Electrical Engineering and Computer Sciences, + University of California, Berkeley, California. + + [2] Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET CIC BBN Laboratories, January 1986. + + [3] Mockapetris, P., "Domains Names - Concepts and Facilities", + RFC-1034, USC/Information Sciences Institute, November 1987. + + [4] Mockapetris, P., "Domain Names - Implementations Specification", + RFC-1035, USC/Information Sciences Institute, November 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 22] + diff --git a/doc/rfc/rfc1034.txt b/doc/rfc/rfc1034.txt new file mode 100644 index 0000000..55cdb21 --- /dev/null +++ b/doc/rfc/rfc1034.txt @@ -0,0 +1,3077 @@ +Network Working Group P. Mockapetris +Request for Comments: 1034 ISI +Obsoletes: RFCs 882, 883, 973 November 1987 + + + DOMAIN NAMES - CONCEPTS AND FACILITIES + + + +1. STATUS OF THIS MEMO + +This RFC is an introduction to the Domain Name System (DNS), and omits +many details which can be found in a companion RFC, "Domain Names - +Implementation and Specification" [RFC-1035]. That RFC assumes that the +reader is familiar with the concepts discussed in this memo. + +A subset of DNS functions and data types constitute an official +protocol. The official protocol includes standard queries and their +responses and most of the Internet class data formats (e.g., host +addresses). + +However, the domain system is intentionally extensible. Researchers are +continuously proposing, implementing and experimenting with new data +types, query types, classes, functions, etc. Thus while the components +of the official protocol are expected to stay essentially unchanged and +operate as a production service, experimental behavior should always be +expected in extensions beyond the official protocol. Experimental or +obsolete features are clearly marked in these RFCs, and such information +should be used with caution. + +The reader is especially cautioned not to depend on the values which +appear in examples to be current or complete, since their purpose is +primarily pedagogical. Distribution of this memo is unlimited. + +2. INTRODUCTION + +This RFC introduces domain style names, their use for Internet mail and +host address support, and the protocols and servers used to implement +domain name facilities. + +2.1. The history of domain names + +The impetus for the development of the domain system was growth in the +Internet: + + - Host name to address mappings were maintained by the Network + Information Center (NIC) in a single file (HOSTS.TXT) which + was FTPed by all hosts [RFC-952, RFC-953]. The total network + + + +Mockapetris [Page 1] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + bandwidth consumed in distributing a new version by this + scheme is proportional to the square of the number of hosts in + the network, and even when multiple levels of FTP are used, + the outgoing FTP load on the NIC host is considerable. + Explosive growth in the number of hosts didn't bode well for + the future. + + - The network population was also changing in character. The + timeshared hosts that made up the original ARPANET were being + replaced with local networks of workstations. Local + organizations were administering their own names and + addresses, but had to wait for the NIC to change HOSTS.TXT to + make changes visible to the Internet at large. Organizations + also wanted some local structure on the name space. + + - The applications on the Internet were getting more + sophisticated and creating a need for general purpose name + service. + + +The result was several ideas about name spaces and their management +[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a +common thread was the idea of a hierarchical name space, with the +hierarchy roughly corresponding to organizational structure, and names +using "." as the character to mark the boundary between hierarchy +levels. A design using a distributed database and generalized resources +was described in [RFC-882, RFC-883]. Based on experience with several +implementations, the system evolved into the scheme described in this +memo. + +The terms "domain" or "domain name" are used in many contexts beyond the +DNS described here. Very often, the term domain name is used to refer +to a name with structure indicated by dots, but no relation to the DNS. +This is particularly true in mail addressing [Quarterman 86]. + +2.2. DNS design goals + +The design goals of the DNS influence its structure. They are: + + - The primary goal is a consistent name space which will be used + for referring to resources. In order to avoid the problems + caused by ad hoc encodings, names should not be required to + contain network identifiers, addresses, routes, or similar + information as part of the name. + + - The sheer size of the database and frequency of updates + suggest that it must be maintained in a distributed manner, + with local caching to improve performance. Approaches that + + + +Mockapetris [Page 2] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + attempt to collect a consistent copy of the entire database + will become more and more expensive and difficult, and hence + should be avoided. The same principle holds for the structure + of the name space, and in particular mechanisms for creating + and deleting names; these should also be distributed. + + - Where there tradeoffs between the cost of acquiring data, the + speed of updates, and the accuracy of caches, the source of + the data should control the tradeoff. + + - The costs of implementing such a facility dictate that it be + generally useful, and not restricted to a single application. + We should be able to use names to retrieve host addresses, + mailbox data, and other as yet undetermined information. All + data associated with a name is tagged with a type, and queries + can be limited to a single type. + + - Because we want the name space to be useful in dissimilar + networks and applications, we provide the ability to use the + same name space with different protocol families or + management. For example, host address formats differ between + protocols, though all protocols have the notion of address. + The DNS tags all data with a class as well as the type, so + that we can allow parallel use of different formats for data + of type address. + + - We want name server transactions to be independent of the + communications system that carries them. Some systems may + wish to use datagrams for queries and responses, and only + establish virtual circuits for transactions that need the + reliability (e.g., database updates, long transactions); other + systems will use virtual circuits exclusively. + + - The system should be useful across a wide spectrum of host + capabilities. Both personal computers and large timeshared + hosts should be able to use the system, though perhaps in + different ways. + +2.3. Assumptions about usage + +The organization of the domain system derives from some assumptions +about the needs and usage patterns of its user community and is designed +to avoid many of the the complicated problems found in general purpose +database systems. + +The assumptions are: + + - The size of the total database will initially be proportional + + + +Mockapetris [Page 3] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + to the number of hosts using the system, but will eventually + grow to be proportional to the number of users on those hosts + as mailboxes and other information are added to the domain + system. + + - Most of the data in the system will change very slowly (e.g., + mailbox bindings, host addresses), but that the system should + be able to deal with subsets that change more rapidly (on the + order of seconds or minutes). + + - The administrative boundaries used to distribute + responsibility for the database will usually correspond to + organizations that have one or more hosts. Each organization + that has responsibility for a particular set of domains will + provide redundant name servers, either on the organization's + own hosts or other hosts that the organization arranges to + use. + + - Clients of the domain system should be able to identify + trusted name servers they prefer to use before accepting + referrals to name servers outside of this "trusted" set. + + - Access to information is more critical than instantaneous + updates or guarantees of consistency. Hence the update + process allows updates to percolate out through the users of + the domain system rather than guaranteeing that all copies are + simultaneously updated. When updates are unavailable due to + network or host failure, the usual course is to believe old + information while continuing efforts to update it. The + general model is that copies are distributed with timeouts for + refreshing. The distributor sets the timeout value and the + recipient of the distribution is responsible for performing + the refresh. In special situations, very short intervals can + be specified, or the owner can prohibit copies. + + - In any system that has a distributed database, a particular + name server may be presented with a query that can only be + answered by some other server. The two general approaches to + dealing with this problem are "recursive", in which the first + server pursues the query for the client at another server, and + "iterative", in which the server refers the client to another + server and lets the client pursue the query. Both approaches + have advantages and disadvantages, but the iterative approach + is preferred for the datagram style of access. The domain + system requires implementation of the iterative approach, but + allows the recursive approach as an option. + + + + + +Mockapetris [Page 4] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The domain system assumes that all data originates in master files +scattered through the hosts that use the domain system. These master +files are updated by local system administrators. Master files are text +files that are read by a local name server, and hence become available +through the name servers to users of the domain system. The user +programs access name servers through standard programs called resolvers. + +The standard format of master files allows them to be exchanged between +hosts (via FTP, mail, or some other mechanism); this facility is useful +when an organization wants a domain, but doesn't want to support a name +server. The organization can maintain the master files locally using a +text editor, transfer them to a foreign host which runs a name server, +and then arrange with the system administrator of the name server to get +the files loaded. + +Each host's name servers and resolvers are configured by a local system +administrator [RFC-1033]. For a name server, this configuration data +includes the identity of local master files and instructions on which +non-local master files are to be loaded from foreign servers. The name +server uses the master files or copies to load its zones. For +resolvers, the configuration data identifies the name servers which +should be the primary sources of information. + +The domain system defines procedures for accessing the data and for +referrals to other name servers. The domain system also defines +procedures for caching retrieved data and for periodic refreshing of +data defined by the system administrator. + +The system administrators provide: + + - The definition of zone boundaries. + + - Master files of data. + + - Updates to master files. + + - Statements of the refresh policies desired. + +The domain system provides: + + - Standard formats for resource data. + + - Standard methods for querying the database. + + - Standard methods for name servers to refresh local data from + foreign name servers. + + + + + +Mockapetris [Page 5] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +2.4. Elements of the DNS + +The DNS has three major components: + + - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are + specifications for a tree structured name space and data + associated with the names. Conceptually, each node and leaf + of the domain name space tree names a set of information, and + query operations are attempts to extract specific types of + information from a particular set. A query names the domain + name of interest and describes the type of resource + information that is desired. For example, the Internet + uses some of its domain names to identify hosts; queries for + address resources return Internet host addresses. + + - NAME SERVERS are server programs which hold information about + the domain tree's structure and set information. A name + server may cache structure or set information about any part + of the domain tree, but in general a particular name server + has complete information about a subset of the domain space, + and pointers to other name servers that can be used to lead to + information from any part of the domain tree. Name servers + know the parts of the domain tree for which they have complete + information; a name server is said to be an AUTHORITY for + these parts of the name space. Authoritative information is + organized into units called ZONEs, and these zones can be + automatically distributed to the name servers which provide + redundant service for the data in a zone. + + - RESOLVERS are programs that extract information from name + servers in response to client requests. Resolvers must be + able to access at least one name server and use that name + server's information to answer a query directly, or pursue the + query using referrals to other name servers. A resolver will + typically be a system routine that is directly accessible to + user programs; hence no protocol is necessary between the + resolver and the user program. + +These three components roughly correspond to the three layers or views +of the domain system: + + - From the user's point of view, the domain system is accessed + through a simple procedure or OS call to a local resolver. + The domain space consists of a single tree and the user can + request information from any section of the tree. + + - From the resolver's point of view, the domain system is + composed of an unknown number of name servers. Each name + + + +Mockapetris [Page 6] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + server has one or more pieces of the whole domain tree's data, + but the resolver views each of these databases as essentially + static. + + - From a name server's point of view, the domain system consists + of separate sets of local information called zones. The name + server has local copies of some of the zones. The name server + must periodically refresh its zones from master copies in + local files or foreign name servers. The name server must + concurrently process queries that arrive from resolvers. + +In the interests of performance, implementations may couple these +functions. For example, a resolver on the same machine as a name server +might share a database consisting of the the zones managed by the name +server and the cache managed by the resolver. + +3. DOMAIN NAME SPACE and RESOURCE RECORDS + +3.1. Name space specifications and terminology + +The domain name space is a tree structure. Each node and leaf on the +tree corresponds to a resource set (which may be empty). The domain +system makes no distinctions between the uses of the interior nodes and +leaves, and this memo uses the term "node" to refer to both. + +Each node has a label, which is zero to 63 octets in length. Brother +nodes may not have the same label, although the same label can be used +for nodes which are not brothers. One label is reserved, and that is +the null (i.e., zero length) label used for the root. + +The domain name of a node is the list of the labels on the path from the +node to the root of the tree. By convention, the labels that compose a +domain name are printed or read left to right, from the most specific +(lowest, farthest from the root) to the least specific (highest, closest +to the root). + +Internally, programs that manipulate domain names should represent them +as sequences of labels, where each label is a length octet followed by +an octet string. Because all domain names end at the root, which has a +null string for a label, these internal representations can use a length +byte of zero to terminate a domain name. + +By convention, domain names can be stored with arbitrary case, but +domain name comparisons for all present domain functions are done in a +case-insensitive manner, assuming an ASCII character set, and a high +order zero bit. This means that you are free to create a node with +label "A" or a node with label "a", but not both as brothers; you could +refer to either using "a" or "A". When you receive a domain name or + + + +Mockapetris [Page 7] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +label, you should preserve its case. The rationale for this choice is +that we may someday need to add full binary domain names for new +services; existing services would not be changed. + +When a user needs to type a domain name, the length of each label is +omitted and the labels are separated by dots ("."). Since a complete +domain name ends with the root label, this leads to a printed form which +ends in a dot. We use this property to distinguish between: + + - a character string which represents a complete domain name + (often called "absolute"). For example, "poneria.ISI.EDU." + + - a character string that represents the starting labels of a + domain name which is incomplete, and should be completed by + local software using knowledge of the local domain (often + called "relative"). For example, "poneria" used in the + ISI.EDU domain. + +Relative names are either taken relative to a well known origin, or to a +list of domains used as a search list. Relative names appear mostly at +the user interface, where their interpretation varies from +implementation to implementation, and in master files, where they are +relative to a single origin domain name. The most common interpretation +uses the root "." as either the single origin or as one of the members +of the search list, so a multi-label relative name is often one where +the trailing dot has been omitted to save typing. + +To simplify implementations, the total number of octets that represent a +domain name (i.e., the sum of all label octets and label lengths) is +limited to 255. + +A domain is identified by a domain name, and consists of that part of +the domain name space that is at or below the domain name which +specifies the domain. A domain is a subdomain of another domain if it +is contained within that domain. This relationship can be tested by +seeing if the subdomain's name ends with the containing domain's name. +For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". + +3.2. Administrative guidelines on use + +As a matter of policy, the DNS technical specifications do not mandate a +particular tree structure or rules for selecting labels; its goal is to +be as general as possible, so that it can be used to build arbitrary +applications. In particular, the system was designed so that the name +space did not have to be organized along the lines of network +boundaries, name servers, etc. The rationale for this is not that the +name space should have no implied semantics, but rather that the choice +of implied semantics should be left open to be used for the problem at + + + +Mockapetris [Page 8] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +hand, and that different parts of the tree can have different implied +semantics. For example, the IN-ADDR.ARPA domain is organized and +distributed by network and host address because its role is to translate +from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- +1002] are flat because that is appropriate for that application. + +However, there are some guidelines that apply to the "normal" parts of +the name space used for hosts, mailboxes, etc., that will make the name +space more uniform, provide for growth, and minimize problems as +software is converted from the older host table. The political +decisions about the top levels of the tree originated in RFC-920. +Current policy for the top levels is discussed in [RFC-1032]. MILNET +conversion issues are covered in [RFC-1031]. + +Lower domains which will eventually be broken into multiple zones should +provide branching at the top of the domain so that the eventual +decomposition can be done without renaming. Node labels which use +special characters, leading digits, etc., are likely to break older +software which depends on more restrictive choices. + +3.3. Technical guidelines on use + +Before the DNS can be used to hold naming information for some kind of +object, two needs must be met: + + - A convention for mapping between object names and domain + names. This describes how information about an object is + accessed. + + - RR types and data formats for describing the object. + +These rules can be quite simple or fairly complex. Very often, the +designer must take into account existing formats and plan for upward +compatibility for existing usage. Multiple mappings or levels of +mapping may be required. + +For hosts, the mapping depends on the existing syntax for host names +which is a subset of the usual text representation for domain names, +together with RR formats for describing host addresses, etc. Because we +need a reliable inverse mapping from address to host name, a special +mapping for addresses into the IN-ADDR.ARPA domain is also defined. + +For mailboxes, the mapping is slightly more complex. The usual mail +address @ is mapped into a domain name by +converting into a single label (regardles of dots it +contains), converting into a domain name using the usual +text format for domain names (dots denote label breaks), and +concatenating the two to form a single domain name. Thus the mailbox + + + +Mockapetris [Page 9] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by +HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this +design also must take into account the scheme for mail exchanges [RFC- +974]. + +The typical user is not concerned with defining these rules, but should +understand that they usually are the result of numerous compromises +between desires for upward compatibility with old usage, interactions +between different object definitions, and the inevitable urge to add new +features when defining the rules. The way the DNS is used to support +some object is often more crucial than the restrictions inherent in the +DNS. + +3.4. Example name space + +The following figure shows a part of the current domain name space, and +is used in many examples in this RFC. Note that the tree is a very +small subset of the actual name space. + + | + | + +---------------------+------------------+ + | | | + MIL EDU ARPA + | | | + | | | + +-----+-----+ | +------+-----+-----+ + | | | | | | | + BRL NOSC DARPA | IN-ADDR SRI-NIC ACC + | + +--------+------------------+---------------+--------+ + | | | | | + UCI MIT | UDEL YALE + | ISI + | | + +---+---+ | + | | | + LCS ACHILLES +--+-----+-----+--------+ + | | | | | | + XX A C VAXA VENERA Mockapetris + +In this example, the root domain has three immediate subdomains: MIL, +EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named +XX.LCS.MIT.EDU. All of the leaves are also domains. + +3.5. Preferred name syntax + +The DNS specifications attempt to be as general as possible in the rules + + + +Mockapetris [Page 10] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +for constructing domain names. The idea is that the name of any +existing object can be expressed as a domain name with minimal changes. +However, when assigning a domain name for an object, the prudent user +will select a name which satisfies both the rules of the domain system +and any existing rules for the object, whether these rules are published +or implied by existing programs. + +For example, when naming a mail domain, the user should satisfy both the +rules of this memo and those in RFC-822. When creating a new host name, +the old rules for HOSTS.TXT should be followed. This avoids problems +when old software is converted to use domain names. + +The following syntax will result in fewer problems with many +applications that use domain names (e.g., mail, TELNET). + + ::= | " " + + ::=