From bbf1dfca0159346fbb573e7a4f4c150c5906d6ac Mon Sep 17 00:00:00 2001 From: Doug Barton Date: Mon, 29 Mar 2010 20:15:32 +0000 Subject: Vendor import of BIND 9.4-ESV-R1 --- CHANGES | 4 + bin/named/server.c | 6 +- doc/arm/Bv9ARM-book.xml | 12 +- doc/arm/Bv9ARM.ch01.html | 52 +- doc/arm/Bv9ARM.ch02.html | 24 +- doc/arm/Bv9ARM.ch03.html | 28 +- doc/arm/Bv9ARM.ch04.html | 72 +- doc/arm/Bv9ARM.ch05.html | 8 +- doc/arm/Bv9ARM.ch06.html | 148 +- doc/arm/Bv9ARM.ch07.html | 16 +- doc/arm/Bv9ARM.ch08.html | 20 +- doc/arm/Bv9ARM.ch09.html | 182 +- doc/arm/Bv9ARM.ch10.html | 4 +- doc/arm/Bv9ARM.html | 148 +- doc/arm/Bv9ARM.pdf | 3943 ++++++++++---------- doc/arm/man.dig.html | 22 +- doc/arm/man.dnssec-keygen.html | 16 +- doc/arm/man.dnssec-signzone.html | 14 +- doc/arm/man.host.html | 12 +- doc/arm/man.named-checkconf.html | 14 +- doc/arm/man.named-checkzone.html | 14 +- doc/arm/man.named.html | 18 +- doc/arm/man.rndc-confgen.html | 14 +- doc/arm/man.rndc.conf.html | 14 +- doc/arm/man.rndc.html | 14 +- ...draft-ietf-6man-text-addr-representation-01.txt | 785 ---- ...draft-ietf-6man-text-addr-representation-07.txt | 785 ++++ doc/draft/draft-ietf-behave-dns64-01.txt | 1624 -------- doc/draft/draft-ietf-behave-dns64-06.txt | 1680 +++++++++ doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt | 1579 -------- doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt | 1571 ++++++++ doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt | 448 --- doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt | 444 +++ doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt | 395 -- doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt | 451 +++ .../draft-ietf-dnsop-dnssec-trust-history-01.txt | 504 +++ doc/draft/draft-kerr-ixfr-only-01.txt | 336 ++ lib/dns/include/dns/rdataset.h | 20 +- lib/dns/include/dns/resolver.h | 46 +- lib/dns/include/dns/result.h | 11 +- lib/dns/include/dns/validator.h | 6 +- lib/dns/ncache.c | 8 +- lib/dns/rbtdb.c | 40 +- lib/dns/rdatalist.c | 8 +- lib/dns/rdataset.c | 25 +- lib/dns/rdataslab.c | 6 +- lib/dns/resolver.c | 417 ++- lib/dns/result.c | 12 +- lib/dns/sdb.c | 6 +- lib/dns/sdlz.c | 6 +- lib/dns/validator.c | 160 +- lib/dns/view.c | 11 +- version | 4 +- 53 files changed, 8878 insertions(+), 7329 deletions(-) delete mode 100644 doc/draft/draft-ietf-6man-text-addr-representation-01.txt create mode 100644 doc/draft/draft-ietf-6man-text-addr-representation-07.txt delete mode 100644 doc/draft/draft-ietf-behave-dns64-01.txt create mode 100644 doc/draft/draft-ietf-behave-dns64-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt create mode 100644 doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt create mode 100644 doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt create mode 100644 doc/draft/draft-kerr-ixfr-only-01.txt diff --git a/CHANGES b/CHANGES index fbc9bfd7cd54..3b209d86e48b 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,7 @@ + --- 9.4-ESV-R1 released --- + +2852. [bug] Handle broken DNSSEC trust chains better. [RT #15619] + --- 9.4-ESV released --- 2831. [security] Do not attempt to validate or cache diff --git a/bin/named/server.c b/bin/named/server.c index 7bb2a6e0e298..c3fc858ab92b 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") + * Copyright (C) 2004-2010 Internet Systems Consortium, Inc. ("ISC") * Copyright (C) 1999-2003 Internet Software Consortium. * * Permission to use, copy, modify, and/or distribute this software for any @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.419.18.75 2009/07/11 04:30:49 marka Exp $ */ +/* $Id: server.c,v 1.419.18.77 2010/02/26 23:46:32 tbox Exp $ */ /*! \file */ @@ -4563,6 +4563,8 @@ dumpdone(void *arg, isc_result_t result) { } if (dctx->cache != NULL) { dns_adb_dump(dctx->view->view->adb, dctx->fp); + dns_resolver_printbadcache(dctx->view->view->resolver, + dctx->fp); dns_db_detach(&dctx->cache); } if (dctx->dumpzones) { diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 9d05255eeaaa..f2dce2132046 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> - + BIND 9 Administrator Reference Manual @@ -30,6 +30,7 @@ 2007 2008 2009 + 2010 Internet Systems Consortium, Inc. ("ISC") @@ -7422,6 +7423,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; }; 1800 (30 minutes). + + Lame-ttl also controls the amount of time DNSSEC + validation failures are cached. There is a minimum + of 30 seconds applied to bad cache entries if the + lame-ttl is set to less than 30 seconds. + + diff --git a/doc/arm/Bv9ARM.ch01.html b/doc/arm/Bv9ARM.ch01.html index 40005894c068..ac8f0a9d6971 100644 --- a/doc/arm/Bv9ARM.ch01.html +++ b/doc/arm/Bv9ARM.ch01.html @@ -1,5 +1,5 @@ - + @@ -45,17 +45,17 @@

Table of Contents

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

-Scope of Document

+Scope of Document

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

-Organization of This Document

+Organization of This Document

In this document, Chapter 1 introduces the basic DNS and BIND concepts. Chapter 2 @@ -116,7 +116,7 @@

-Conventions Used in This Document

+Conventions Used in This Document

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

-The Domain Name System (DNS)

+The Domain Name System (DNS)

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

-DNS Fundamentals

+DNS Fundamentals

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

-Domains and Domain Names

+Domains and Domain Names

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

-Zones

+Zones

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

-Authoritative Name Servers

+Authoritative Name Servers

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

-The Primary Master

+The Primary Master

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

-Slave Servers

+Slave Servers

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

-Stealth Servers

+Stealth Servers

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

-Caching Name Servers

+Caching Name Servers

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

-Forwarding

+Forwarding

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

-Name Servers in Multiple Roles

+Name Servers in Multiple Roles

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

Table of Contents

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

-Hardware requirements

+Hardware requirements

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

-CPU Requirements

+CPU Requirements

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

-Memory Requirements

+Memory Requirements

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

-Name Server Intensive Environment Issues

+Name Server Intensive Environment Issues

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

-Supported Operating Systems

+Supported Operating Systems

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

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

-A Caching-only Name Server

+A Caching-only Name Server

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

-An Authoritative-only Name Server

+An Authoritative-only Name Server

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

-Load Balancing

+Load Balancing

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

-Name Server Operations

+Name Server Operations

-Tools for Use With the Name Server Daemon

+Tools for Use With the Name Server Daemon

This section describes several indispensable diagnostic, administrative and monitoring tools available to the system @@ -739,7 +739,7 @@ controls {

-Signals

+Signals

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

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

-Split DNS

+Split DNS

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

-Example split DNS setup

+Example split DNS setup

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

-Generate Shared Keys for Each Pair of Hosts

+Generate Shared Keys for Each Pair of Hosts

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

-Automatic Generation

+Automatic Generation

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

-Manual Generation

+Manual Generation

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

-Copying the Shared Secret to Both Machines

+Copying the Shared Secret to Both Machines

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

-Informing the Servers of the Key's Existence

+Informing the Servers of the Key's Existence

Imagine host1 and host 2 are @@ -566,7 +566,7 @@ key host1-host2. {

-Instructing the Server to Use the Key

+Instructing the Server to Use the Key

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

-TSIG Key Based Access Control

+TSIG Key Based Access Control

BIND allows IP addresses and ranges to be specified in ACL @@ -626,7 +626,7 @@ allow-update { key host1-host2. ;};

-Errors

+Errors

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

-TKEY

+TKEY

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

-SIG(0)

+SIG(0)

BIND 9 partially supports DNSSEC SIG(0) transaction signatures as specified in RFC 2535 and RFC 2931. @@ -749,7 +749,7 @@ allow-update { key host1-host2. ;};

-Generating Keys

+Generating Keys

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

-Signing the Zone

+Signing the Zone

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

-Configuring Servers

+Configuring Servers

To enable named to respond appropriately to DNS requests from DNSSEC aware clients, @@ -932,7 +932,7 @@ options {

-IPv6 Support in BIND 9

+IPv6 Support in BIND 9

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

-Address Lookups Using AAAA Records

+Address Lookups Using AAAA Records

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

-Address to Name Lookups Using Nibble Format

+Address to Name Lookups Using Nibble Format

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

Table of Contents

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

-The Lightweight Resolver Library

+The Lightweight Resolver Library

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

Configuration File Elements
Address Match Lists
-
Comment Syntax
+
Comment Syntax
Configuration File Grammar
-
acl Statement Grammar
+
acl Statement Grammar
acl Statement Definition and Usage
-
controls Statement Grammar
+
controls Statement Grammar
controls Statement Definition and Usage
-
include Statement Grammar
-
include Statement Definition and +
include Statement Grammar
+
include Statement Definition and Usage
-
key Statement Grammar
-
key Statement Definition and Usage
-
logging Statement Grammar
-
logging Statement Definition and +
key Statement Grammar
+
key Statement Definition and Usage
+
logging Statement Grammar
+
logging Statement Definition and Usage
-
lwres Statement Grammar
-
lwres Statement Definition and Usage
-
masters Statement Grammar
-
masters Statement Definition and +
lwres Statement Grammar
+
lwres Statement Definition and Usage
+
masters Statement Grammar
+
masters Statement Definition and Usage
-
options Statement Grammar
+
options Statement Grammar
options Statement Definition and Usage
server Statement Grammar
server Statement Definition and Usage
-
trusted-keys Statement Grammar
-
trusted-keys Statement Definition +
trusted-keys Statement Grammar
+
trusted-keys Statement Definition and Usage
view Statement Grammar
-
view Statement Definition and Usage
+
view Statement Definition and Usage
zone Statement Grammar
-
zone Statement Definition and Usage
+
zone Statement Definition and Usage
-
Zone File
+
Zone File
Types of Resource Records and When to Use Them
-
Discussion of MX Records
+
Discussion of MX Records
Setting TTLs
-
Inverse Mapping in IPv4
-
Other Zone File Directives
-
BIND Master File Extension: the $GENERATE Directive
+
Inverse Mapping in IPv4
+
Other Zone File Directives
+
BIND Master File Extension: the $GENERATE Directive
Additional File Formats
@@ -455,7 +455,7 @@ Address Match Lists

-Syntax

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

 

-Definition and Usage

+Definition and Usage

 

             Address match lists are primarily used to determine access
             control for various server operations. They are also used in
@@ -542,7 +542,7 @@
 
 

 

-Comment Syntax

+Comment Syntax

 

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

 

 

-Syntax

+Syntax

 

             

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

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

 

-Definition and Usage

+Definition and Usage

 

             Comments may appear anywhere that whitespace may appear in
             a BIND configuration file.
@@ -797,7 +797,7 @@
       

 

 

-acl Statement Grammar

+acl Statement Grammar

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

 

-controls Statement Grammar

+controls Statement Grammar

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

 

-include Statement Grammar

+include Statement Grammar

 
include filename;

 
 

 

-include Statement Definition and
+include Statement Definition and
           Usage

 

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

 

 

-key Statement Grammar

+key Statement Grammar

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

 

-key Statement Definition and Usage

+key Statement Definition and Usage

 

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

 

-logging Statement Grammar

+logging Statement Grammar

 
logging {
    [ channel channel_name {
      ( file path_name
@@ -1102,7 +1102,7 @@
 
 

 

-logging Statement Definition and
+logging Statement Definition and
           Usage

 

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

 

 

-The channel Phrase

+The channel Phrase

 

             All log output goes to one or more channels;
             you can make as many of them as you want.
@@ -1665,7 +1665,7 @@ category notify { null; };
 
 

 

-The query-errors Category

+The query-errors Category

 

             The query-errors category is
             specifically intended for debugging purposes: To identify
@@ -1893,7 +1893,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 
 

 

-lwres Statement Grammar

+lwres Statement Grammar

 

            This is the grammar of the lwres
           statement in the named.conf file:
@@ -1908,7 +1908,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 
 

 

-lwres Statement Definition and Usage

+lwres Statement Definition and Usage

 

           The lwres statement configures the
           name
@@ -1959,14 +1959,14 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 
 

 

-masters Statement Grammar

+masters Statement Grammar

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

 
 

 

-masters Statement Definition and
+masters Statement Definition and
           Usage

 
masters
           lists allow for a common set of masters to be easily used by
@@ -1975,7 +1975,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
 

 

 

-options Statement Grammar

+options Statement Grammar

 

           This is the grammar of the options
           statement in the named.conf file:
@@ -3086,7 +3086,7 @@ options {
 
 

 

-Forwarding

+Forwarding

 

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

 

-Dual-stack Servers

+Dual-stack Servers

 

             Dual-stack servers are used as servers of last resort to work
             around
@@ -3286,7 +3286,7 @@ options {
 
 

 

-Interfaces

+Interfaces

 

             The interfaces and ports that the server will answer queries
             from may be specified using the listen-on option. listen-on takes
@@ -3719,7 +3719,7 @@ avoid-v6-udp-ports {};
 
 

 

-UDP Port Lists

+UDP Port Lists

 

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

 

-Operating System Resource Limits

+Operating System Resource Limits

 

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

 

-Periodic Task Intervals

+Periodic Task Intervals

 

 
cleaning-interval

 

@@ -4227,14 +4227,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 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).
-                

+                

+

+                  Lame-ttl also controls the amount of time DNSSEC
+                  validation failures are cached.  There is a minimum
+                  of 30 seconds applied to bad cache entries if the
+                  lame-ttl is set to less than 30 seconds.
+                

+
 
max-ncache-ttl

 

                   To reduce network traffic and increase performance,
@@ -4993,7 +5001,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 

 

 

-trusted-keys Statement Grammar

+trusted-keys Statement Grammar

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

 

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

 

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

 

 

-view Statement Definition and Usage

+view Statement Definition and Usage

 

             The view statement is a powerful
             feature
@@ -5301,10 +5309,10 @@ zone zone_name [
 

 

-zone Statement Definition and Usage

+zone Statement Definition and Usage

 

 

-Zone Types

+Zone Types

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

 

-Class

+Class

 

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

 

-Zone Options

+Zone Options

 

 
allow-notify

 

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

 

-Zone File

+Zone File

 

 

 Types of Resource Records and When to Use Them

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

 

-Resource Records

+Resource Records

 

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

 

-Textual expression of RRs

+Textual expression of RRs

 

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

 

-Discussion of MX Records

+Discussion of MX Records

 

             As described above, domain servers store information as a
             series of resource records, each of which contains a particular
@@ -7200,7 +7208,7 @@ zone zone_name [
 

 

-Inverse Mapping in IPv4

+Inverse Mapping in IPv4

 

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

 

-Other Zone File Directives

+Other Zone File Directives

 

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

 

-The $ORIGIN Directive

+The $ORIGIN Directive

 

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

 

-The $INCLUDE Directive

+The $INCLUDE Directive

 

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

 

-The $TTL Directive

+The $TTL Directive

 

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

 

-BIND Master File Extension: the  $GENERATE Directive

+BIND Master File Extension: the  $GENERATE Directive

 

             Syntax: $GENERATE
             range
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
index 58688d2165a5..8843c8652078 100644
--- a/doc/arm/Bv9ARM.ch07.html
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -1,5 +1,5 @@
 
-
+
 
 
 
@@ -46,10 +46,10 @@
 
Table of Contents

 

 
Access Control Lists

-
Chroot and Setuid

+
Chroot and Setuid

 

-
The chroot Environment

-
Using the setuid Function

+
The chroot Environment

+
Using the setuid Function

 

 
Dynamic Update Security

 

@@ -118,7 +118,7 @@ zone "example.com" {
 
 

 

-Chroot and Setuid
+Chroot and Setuid
 

 

           On UNIX servers, it is possible to run BIND
@@ -144,7 +144,7 @@ zone "example.com" {
         

 

 

-The chroot Environment

+The chroot Environment

 

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

 

-Using the setuid Function

+Using the setuid Function

 

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

 
Table of Contents

 

-
Common Problems

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

-
Incrementing and Changing the Serial Number

-
Where Can I Get Help?

+
Common Problems

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

+
Incrementing and Changing the Serial Number

+
Where Can I Get Help?

 

 

 

 

-Common Problems

+Common Problems

 

 

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

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

 

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

 

-Incrementing and Changing the Serial Number

+Incrementing and Changing the Serial Number

 

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

 

-Where Can I Get Help?

+Where Can I Get Help?

 

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

 
Table of Contents

 

-
Acknowledgments

+
Acknowledgments

 
A Brief History of the DNS and BIND

-
General DNS Reference Information

+
General DNS Reference Information

 
IPv6 addresses (AAAA)

 
Bibliography (and Suggested Reading)

 

 
Request for Comments (RFCs)

 
Internet Drafts

-
Other Documents About BIND

+
Other Documents About BIND

 

 

 

 

 

-Acknowledgments

+Acknowledgments

 

 

 A Brief History of the DNS and BIND
@@ -162,7 +162,7 @@
 

 

 

-General DNS Reference Information

+General DNS Reference Information

 

 

 IPv6 addresses (AAAA)

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

 

 

-Bibliography

+Bibliography

 

 
Standards

 

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

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

 

 

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

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

 

 

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

 

 

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

 Proposed Standards

 

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

 

 

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

 

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

 DNS Security Proposed Standards

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

 

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

 

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

 

 

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

 

 

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

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

 

 

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

 

 
 

 
Resource Record Types

 

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

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

 

 

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

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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

 

 

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

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

 

 

 

 

 DNS and the Internet

 

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

 

 

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

 

 

 DNS Operations

 

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

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

 

 

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

 

 

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

 

 

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

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

 

 

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

 

 

 

 
Internationalized Domain Names

 

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

 

 

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

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

 

 

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

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

 

 

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

 

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

 

 

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

 

 

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

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

 

 

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

 

 

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

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

 

 
 

 
Obsolete and Unimplemented Experimental RFC

 

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

 

 

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

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

 

 

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

 

 

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

 
 

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

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

 

 

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

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

 

 

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

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

 

 

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

 

 

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

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

 

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

 

-Other Documents About BIND
+Other Documents About BIND
 

 

 

 

-Bibliography

+Bibliography

 

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

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

 

 
 
diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html
index 9be4eb6191e2..cb6c21168916 100644
--- a/doc/arm/Bv9ARM.ch10.html
+++ b/doc/arm/Bv9ARM.ch10.html
@@ -1,5 +1,5 @@
 
-
+
 
 
 
diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html
index e37899055885..5b0a3c7788cc 100644
--- a/doc/arm/Bv9ARM.html
+++ b/doc/arm/Bv9ARM.html
@@ -1,5 +1,5 @@
 
-
+
 
 
 
@@ -41,7 +41,7 @@
 

 

 BIND 9 Administrator Reference Manual

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

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

 
Copyright © 2000-2003 Internet Software Consortium.

 

 

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

 
1. Introduction

 

-
Scope of Document

-
Organization of This Document

-
Conventions Used in This Document

-
The Domain Name System (DNS)

+
Scope of Document

+
Organization of This Document

+
Conventions Used in This Document

+
The Domain Name System (DNS)

 

-
DNS Fundamentals

-
Domains and Domain Names

-
Zones

-
Authoritative Name Servers

-
Caching Name Servers

-
Name Servers in Multiple Roles

+
DNS Fundamentals

+
Domains and Domain Names

+
Zones

+
Authoritative Name Servers

+
Caching Name Servers

+
Name Servers in Multiple Roles

 

 

 
2. BIND Resource Requirements

 

-
Hardware requirements

-
CPU Requirements

-
Memory Requirements

-
Name Server Intensive Environment Issues

-
Supported Operating Systems

+
Hardware requirements

+
CPU Requirements

+
Memory Requirements

+
Name Server Intensive Environment Issues

+
Supported Operating Systems

 

 
3. Name Server Configuration

 

 
Sample Configurations

 

-
A Caching-only Name Server

-
An Authoritative-only Name Server

+
A Caching-only Name Server

+
An Authoritative-only Name Server

 

-
Load Balancing

-
Name Server Operations

+
Load Balancing

+
Name Server Operations

 

-
Tools for Use With the Name Server Daemon

-
Signals

+
Tools for Use With the Name Server Daemon

+
Signals

 

 

 
4. Advanced DNS Features

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

 
The journal file

 
Incremental Zone Transfers (IXFR)

-
Split DNS

-
Example split DNS setup

+
Split DNS

+
Example split DNS setup

 
TSIG

 

-
Generate Shared Keys for Each Pair of Hosts

-
Copying the Shared Secret to Both Machines

-
Informing the Servers of the Key's Existence

-
Instructing the Server to Use the Key

-
TSIG Key Based Access Control

-
Errors

+
Generate Shared Keys for Each Pair of Hosts

+
Copying the Shared Secret to Both Machines

+
Informing the Servers of the Key's Existence

+
Instructing the Server to Use the Key

+
TSIG Key Based Access Control

+
Errors

 

-
TKEY

-
SIG(0)

+
TKEY

+
SIG(0)

 
DNSSEC

 

-
Generating Keys

-
Signing the Zone

-
Configuring Servers

+
Generating Keys

+
Signing the Zone

+
Configuring Servers

 

-
IPv6 Support in BIND 9

+
IPv6 Support in BIND 9

 

-
Address Lookups Using AAAA Records

-
Address to Name Lookups Using Nibble Format

+
Address Lookups Using AAAA Records

+
Address to Name Lookups Using Nibble Format

 

 

 
5. The BIND 9 Lightweight Resolver

 

-
The Lightweight Resolver Library

+
The Lightweight Resolver Library

 
Running a Resolver Daemon

 

 
6. BIND 9 Configuration Reference

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

 

 
Address Match Lists

-
Comment Syntax

+
Comment Syntax

 

 
Configuration File Grammar

 

-
acl Statement Grammar

+
acl Statement Grammar

 
acl Statement Definition and
           Usage

-
controls Statement Grammar

+
controls Statement Grammar

 
controls Statement Definition and
           Usage

-
include Statement Grammar

-
include Statement Definition and
+
include Statement Grammar

+
include Statement Definition and
           Usage

-
key Statement Grammar

-
key Statement Definition and Usage

-
logging Statement Grammar

-
logging Statement Definition and
+
key Statement Grammar

+
key Statement Definition and Usage

+
logging Statement Grammar

+
logging Statement Definition and
           Usage

-
lwres Statement Grammar

-
lwres Statement Definition and Usage

-
masters Statement Grammar

-
masters Statement Definition and
+
lwres Statement Grammar

+
lwres Statement Definition and Usage

+
masters Statement Grammar

+
masters Statement Definition and
           Usage

-
options Statement Grammar

+
options Statement Grammar

 
options Statement Definition and
           Usage

 
server Statement Grammar

 
server Statement Definition and
             Usage

-
trusted-keys Statement Grammar

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

+
trusted-keys Statement Definition
             and Usage

 
view Statement Grammar

-
view Statement Definition and Usage

+
view Statement Definition and Usage

 
zone
             Statement Grammar

-
zone Statement Definition and Usage

+
zone Statement Definition and Usage

 

-
Zone File

+
Zone File

 

 
Types of Resource Records and When to Use Them

-
Discussion of MX Records

+
Discussion of MX Records

 
Setting TTLs

-
Inverse Mapping in IPv4

-
Other Zone File Directives

-
BIND Master File Extension: the  $GENERATE Directive

+
Inverse Mapping in IPv4

+
Other Zone File Directives

+
BIND Master File Extension: the  $GENERATE Directive

 
Additional File Formats

 

 
 
7. BIND 9 Security Considerations

 

 
Access Control Lists

-
Chroot and Setuid

+
Chroot and Setuid

 

-
The chroot Environment

-
Using the setuid Function

+
The chroot Environment

+
Using the setuid Function

 

 
Dynamic Update Security

 

 
8. Troubleshooting

 

-
Common Problems

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

-
Incrementing and Changing the Serial Number

-
Where Can I Get Help?

+
Common Problems

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

+
Incrementing and Changing the Serial Number

+
Where Can I Get Help?

 

 
A. Appendices

 

-
Acknowledgments

+
Acknowledgments

 
A Brief History of the DNS and BIND

-
General DNS Reference Information

+
General DNS Reference Information

 
IPv6 addresses (AAAA)

 
Bibliography (and Suggested Reading)

 

 
Request for Comments (RFCs)

 
Internet Drafts

-
Other Documents About BIND

+
Other Documents About BIND

 

 

 
I. Manual pages

diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf
index 12dd76c113eb..a59e03a212f0 100644
--- a/doc/arm/Bv9ARM.pdf
+++ b/doc/arm/Bv9ARM.pdf
@@ -1176,16 +1176,13 @@ endobj
 /ProcSet [ /PDF /Text ]
 >> endobj
 682 0 obj <<
-/Length 999       
+/Length 1001      
 /Filter /FlateDecode
 >>
 stream
-xÚµVM“¢H½û+8jDS]|Õ‘FT&Àéؘ™ƒ­ØMD+®âtô¿ß„ªQ·/*«ò™ùòe@4?¢™²8åšÍ
dbbjëÝk¯à›ˆÄ`MLjq§qþ=øùk}ÈÓØ`D8§Ún`˜™cêä}¾·¡.¼*àu6Ý &¶¦39Àîuƒv(¢›šn›YŒ²ý”
'`rÄ-jiÙVslD1q´•m~½òðy,^ߪÑïì›fbdcÞPÃXÖµãqBŒ‹H:E¶ÅíF…û|´—”PCÄD16F:5qmšiu¦Ý™Ngraû*?îóJìÒÏS•ïNbã•ûSy¬ŠóîAa×h¤3‚›‰Qj©W/°%5ÕŸµ"F‘iY–fÆ›_*Þ¢õKø­ä„ÙÐk›wQÿMsújŽ;IgÒÎdwÕ-·ÕÇê8"Î0¿–]ëC
3ÃEð´œ/åS`ý}«žéÀÀRÒŬËYäÇ]q:å^pªJ±žO¹¬g
òŽ!C¹ß•›bÛ;Yí7åQØ›âT‹—s%k¬Þ
-9P§›ú·êO«ý§0çã¡ä$9Þ{îÉ
@4?¢™²8åšÍ
dbbjëÝk¯°7ÉÁšŽãN³ù÷àço¬m€ôm W?`‚áœj»a2dŒ©•÷A:øÞ†ºØU¯³é†‘aqMgr@Ü%é†lqd[6ÕtÛäÈb”Õì§lð8È·¨¥e[Í6m@¾–•m~½òðy,^ߪÑïì›fbdcÞ(ÃXÖõÆã„‘t
+	¹ÝX¢x¿À8Aí%%A½±!QŒ‡‘NM\C³ƒVí:ä-$X `_åÇ}^‰YúyªòÝIL¼r*UqÞ=(îtF0È4ñ/J õꦤV=ð³ÖOÂ(2-ËÃ47¿4¿eë—ô[÷	³áÔmÞEý7ûéÿi?î,%¤dwÝ-·ÕÇê8"Î0¿¶]ûíM)v4›2Ði9_Ú§Èú%ûÖ=ÓASÒŬËYäÇ]q:å^hªJ1žO¹¬g
öŽ!C9ß•›bÛ[Yí7åQàMqªŽÅ˹’5Vo…l¨ÓMý[õ§ÕþS€Ãùx(Orû£¨ÞR¼z¥Ä‚g"åד”îS(ñ$NTV™>]ø^à†ÊãÄ÷ê‰Ý,Aˆ¦FVßL/ŽRÿûTADлÓÖ‹ëä½Ýç™[gÉÒ
+KÔé¥Ë°Ym­Ÿ$ñ\§Éµ$ŒàÁxuÀËÔWµ‰ðÍôõ@G‚ÓéƒÒáC'}Ï]5zYGý£…²³ÄíyùÓ0˜ú‘ç÷3ÅMäZ+|P‡ô[4c2b6Ô/ÓË”2°›ikE¼ÌúJâ+Õ ,ò/w×¢½§àOïXë‹Ï雸ð蜹ÛÕ3ùêÊܾJä—3QýÁt÷»LåûÏßeºÊ¦6bŽCï¿Š¨ƒ·Y+ªy±Þ‡&§Ì¢w”ÿ¾Èjæendstream
 endobj
 681 0 obj <<
 /Type /Page
@@ -5201,22 +5198,22 @@ endobj
 /ProcSet [ /PDF /Text ]
 >> endobj
 1302 0 obj <<
-/Length 2472      
+/Length 2617      
 /Filter /FlateDecode
 >>
 stream
-xÚÅkoÛFò»…OÔ¡Úîû‘~rS'ç¢uzŠ‡CšŒDÛB)R©8¾àþ{g_ÔR¤lç’â`À\íÎÎÎ{fgÉÙ‰¤¡f¢G1YnÎðäÖ^‘3‹@³êÇÅÙ÷/™šd$•“Åu‚K#¬5™,Vo3‰(šœ½x}õòòÕ?ççSųÅåë«éŒ
-œ½¼üåÂ^ÍÏýõ|>-Höâïç¿-.æ~I?^^ýägŒÿœ@:¿xy1¿¸zq1}·øùìbÑñ’òK0³Œ|8{ûOVÀöÏg1£Åä~`DŒ¡“Í	ÎXœ)ÏÞœý£C˜¬º­£ò#Q&éˆ) 0H2X²¬ÛÛb\i–ÝÖMÛØ!ÍêÊOåþ³Zï¦DgŲ-ï=À²®*øY¬<@U´wõîÿãn]–jë·]ÇòÕÊÏ4MÑø)ÍÚÛ¼õ3M¾)zXA9ël^4Ûºê6¶µ>H`F2BÐ; ¤ûb·vÐð#Уªnýà}á¿M½>ÅgYÜ
-FµÃmËuÛ%ÆÙgw¼H	Æ#Þ(?{ˆ²^æ¥êÉoà©	¿ÿûßžè÷øEP7éSÏŠÑÎSˆD„ƒ`@8Ÿ7EÄëÝ
-DUÝ$¬„rd8áÉ¿n«/)²Í¾l×ÛÒÊPÊ,˜Gí¾«Æƒä~6…h÷»ÊÙ,¯+¿’ŒyÕÜ9ÝÙµÖ¯mò{?ñ> Ù7Åõ¾ôs`î¶ø;ÆôfŸžvàWM³Ìêë°ùöé#*Ù–ùÒQÍPíŽå<`€©`ÒÎ8ÁVØêÖ†!Œ *¤üín˜ÕVø#’	Þêa›6o‹MQµþÈm±Û¬³!þóvíü	 Ÿðí¨ìä`íö
@ÆDÑ’ M꛸S˜Nî?‰5À¯>žtî $‚³7E€Ï˦ö£v\nZAä"Ê"úáPhŒ#Lé±Ì¾;ÓŒJ^-&ÂÀ^Á´
˜~qw3ñƒya;øYºaa‡x-o Pz½¸TãÝ
h2j´a=š±¾ƒzŒ’6K	ò*eìÐHÛr‹çÕ˜è%€+H´³Õ”p8Ij­&BS>!OIzˆÓz<åÍ"ÂYŠÑ³Ø#
c$•‡ƒÒ·ÅrÄ0(E‹èMëV…u‘¬†éëº,ë»æyˆ¸ SƒE?¼]–yÓøƒDï ‰ ’ á *!)f%&¹­dØWK¬Ã8KQ:‘õˆ# NE­È"˜%²²	wDd‚yàäÍÛö~[Œ°
‘Hí$õ¸6 G¬å7ä:b|Œkp`ü+¸>÷¹0ä1ž?[Õ›|]
$	ߎñã#Œ3Ì‘ÄÀÞ€ñgcœ^gúœ²ç÷Që§Il/"l´GNQi¼¹„ôÄ‚Ì~uð7µž’,­?¯­—«ï`F‡Ìn7¬ŠëòNØÒŒF/
Þ¨¢‚ίþ=¤á‘
äÑyât ΀EIÛ¢;Ë-ž¤Í¤´é´)†8í’ÚC´É‡isÆ™ò†„É4‘ý2¦OnL·!rí§”Ž5
-\nËyl}&ÍÑ¡ŸmB0;YF®»2¿×"m"ëáõh[L2#Ž[<‘ƒí¶È-‡
-÷~„¹®	z…(9
ª£Ê,*€ÚR"R®‹jþS®0ìiÝ7=#øɪ
-)å—"qÇQHî^YlL4`qIhël’ó	åGLúãU¢¸J@‚Ñhú¯!Zlÿi6x”XÁÄ`bêäÄ Ìa&;Fpß_nèä§Ø™$E¼³±ãHÒÔGµmy¨	ÅÜcÝåÂñ${·-Œ¸JìpJDæmqJñáÜC)SkC†mZƨ¿(Â×™›Ü[D…ûÁ²ë}iŸS 
2vŸµD7Qù¯‘²#cߨ°Jgüg¹ßÍ|0QNe¦Ÿw€Õ½Ú(ðÓÚX¥ƒÀ a‡Í~»µq×Ð~ÆF4µ¦È^…!CÛÅ¿`aT=ILíëŒ×º‰0Ò|I=ñ°kõýAP-Æ˹F(Ü,mc/}Ká-e1%Ôdû*\5{Aî™üIƒHa'ð<Ì,:MI²„”ñgm[z²àðЩfxj/Å)„5!½Sßþ鞪ý潿«Ñð®@Áu–uåïÌ?ÖÀä2_ú=ÔeGX)ý{ŸÛ°û‘¬«ÕzéÞ3“
-öó«u“¿/‹€Õb³B'Y€²-†Åí:7ÚxaÀŠ!4¦«×‹±–Çlêè-fÍ
¸êªX!ÛÄð9vqª“2,3DV£i,3 Êküà^¸"8äÑuµo‹ÆíÒQµ:ÊY›üÓz³ß$=“‡È—£6[ù£ˆ§G"Þuµ-9lHÎÉ„ÈàFÄFO½Ÿ=õ¥üàÐÜ6¿4·çPã³H”SzmxR’þ'‹¾Bendstream
+xÚÅ]sÛ¸ñÝ¿B“'ªsÂá›@îÉ—8©oîœVV§ÓÉå–h›s©ˆT7ÓÿÞÅŠ”ì4¹édÆ„€Åb¿w±™`øG&B"©©ž¤š#‰˜,×gxrkoψ‡™ YõóâìÇ7,h¤%•“Åm„K!¬™,Vï‰(šœ¼zwõæòí?æçÓ”'‹ËwWÓ8ysùë…½ŸÿöÛù|:#JäÕ_Ïÿ¶¸˜»%éqü|yõÚÍh÷9‚t~ñæb~qõêbúañËÙÅ¢ã%æ—`fùxöþž¬€í_Î0bZ‰ÉüÀˆhM'ë3.œ±0Sž]Ÿý½C­Ú­£ò#Q&éˆ) ÐH2X2¬Ûû|\)–Ü×MÛ˜!MêÊMeî³*¶S¢’|Ù–`YWüÌW ÊÛ‡zû‡ûñP”¥ƒÚ¸m·á„lµr3M“7nÊD“ö>kÝL“­óVPÇ*™çͦ®ºmm„˜‚´´Ç(éã.ß~xš`TÕ­ÜäîÛÔ[àl`q:˜Á"ͨ²¸
`Y4°]bœ|±ÇKRÁx ÂåQÖˬ4Bý)ú
<5þ÷~ãàËIàÙÁn[u“>õ\ œ2Úy
+‘ˆppçó&÷’x·]¨ª;„õ‘PŽ4'Ü"ùç}nô%E²Þ•m±)¥L¼yÔö»jHæfcˆv·­¬ÍÀrQ¹•Ìc̪æÁêάµnm=º‰f×ä·»ÒÍØ/ØâïÓ»]|Ø[õ49Ì2©oýæû#¤¨dSfKK5g@µ=–s¦¼I[ã[e`«Xj„0‚¨
+ð´Û-h`VáH^`$RðVÛ´Y›¯óªuGnòíº°Î
+„ìùÏÚÂú@X>áÛQÙÉÁ(Ú‰¢%AŠê´oâVy`:™ûDÖ¿úxâ¹½N®sŸ•MíFí¸ÜT
+A‹ ‹à‡C¡1Ž0¥‡2ûá0L3*xµ˜
{S&`ºÅíÝÄ
æQ„íàgñ†a„â5t\C tz±©Æ¹!Ф!Ô(Íz4
b}õ%l†äTÊ8Ø¡–<„·Ô.žWc¢—./ÑÎVcÂá$©T:Š‚ð	yNÒ£@œRã)oÎbŒŽÅi#™¦b°Uú&_Ž¥ˆc¼©ðYa•ÇqÉØ¡Ÿ¾­Ë²~h^úˆ:ÕXôsÁûe™5;Hô’*	âê bÂPÊŒÄ$7•ûf‰ug1J+²qÔ™R#²fˆ¬LÂCš`î9ùàDó¾}Üä#lCd#’;	@=®5È+ù¹Ÿâ\ÿ®÷À}®yˆç/Võ:+ªcc‚$aâû1Þa|‚q†9’Ø0þbŒsÀëtŸó}öáž"jü4Š
ãE„‰öÈ**Ž7—~˜ÐP™¯ò¾b§Š)IüÐøsa¼4_ý3Êgv³a•ßfwü–f4z)ðÆ4(èüê_ã¡AjØ@#Nyâ4X4´É»³ìâQÚtL›:B[ʧ]R;E›¸ü0ì8Œ›©OS€äìH‚%qðo®)dé”	æóòåP p1±–æ:ï]8Ž.œ^`ÙÖ“ûäQ훞v(ä9–’P<Šp„M-4­±^¡cXóDdîÓìn
µ6wšÊ+%¡{	•šB˜ÐƒîJV>dM¿MyÜûODZÛg9­Ï¨9:ãó£fG"Ë¡‘›jµ×"m"ëþõd[L2-[<ƒÍ&Ï,-û
+÷q„¹®	z…(8
¦•1X”5¥D8¤,òkþS¡Ö§rNÔý'pÓÓ‚­ú ‘Rò¯ÉnÇ é^YLCÃÅ-ŽmCCF²N 'p5AÊhÅÈù*Ò\&‰» Áh0þw/H²€¿4<‹Nœ‚‘S¨¢SÈæèÉÇ	A˜kÍP4¶¼îe`'~¼\ÓÉë8šDLij³eJÒØO•i{Àù„£4®®G+{7.ŒxÙ┈ÄÙã”âýE¸‡Ò¦Rš[µŒQwY„¯593x4ˆrûƒ%·»Ò<©X@hÌ>cv¢r_÷*eFÚ¼Sá4žqŸån;s%…ÄÒÑ[Àj_nRðÕÚÙTy'€'Â›Ýfcb¯)¢ÝŒ‰j6rM½òA|– ¦“7,* óR¥Õ$6·o³`ã+BKý5EÅiÿê;føÈM(€ð	ˆÞ¤÷ "üƒÊbJ¨Nv•¿oö"'Ÿ"8œyÆs@³ê-ÊÐRB柵m9èÍ‚h£„S ‘ƒ{É.EXÒ?ø:w¯tÿŠPíÖ7îÚFýZÖ•»
+2÷n“ËléöP›(a¥tOvÃöS@RT«biŸ6üë
+vó«¢ÉnÊÜc5ØŒèIâ¡L·aq_xòF{0LÁ˜ÐM®Þ-ƺW¦ÌcúàÉ-$Ð5xì*_!ÓÏpévq¬©2¬8ãH+*(¸Æz@¸×M®ö)µ¨vmÞ¸£mfªVék}.Ö»uÔ>9E8Õ,CÔ8=ñ®ÁmÈaCrÂCdBð
*»å×`«öÊ¿ý¸g¬ÖÝ[J«³ðFg€Öp«iãW+ž´ÅÚ¯¾¾º¾¾xåÆÀb±êžÁDr›¥ô¯eQÿ€;\ííâµ"lp˜€»b6V-wâ­}¥ä±7ú®hêñÏ]7™Ÿ®`® …îÙº¸”#ð¢N]÷’ƒW4agV’u´|ape£‘Ož¼M?÷ÿ5ì#/7­JEÇcŽ¿‘±@”õ:¯þ?@Iÿ/c20nendstream
 endobj
 1301 0 obj <<
 /Type /Page
@@ -5249,10 +5246,10 @@ endobj
 /D [1301 0 R /XYZ 56.6929 501.5031 null]
 >> endobj
 410 0 obj <<
-/D [1301 0 R /XYZ 56.6929 144.8407 null]
+/D [1301 0 R /XYZ 56.6929 159.714 null]
 >> endobj
 1307 0 obj <<
-/D [1301 0 R /XYZ 56.6929 118.3973 null]
+/D [1301 0 R /XYZ 56.6929 135.3825 null]
 >> endobj
 1300 0 obj <<
 /Font << /F37 751 0 R /F23 686 0 R /F39 868 0 R /F21 662 0 R /F53 967 0 R /F62 1000 0 R /F63 1003 0 R >>
@@ -5260,28 +5257,20 @@ endobj
 /ProcSet [ /PDF /Text ]
 >> endobj
 1310 0 obj <<
-/Length 3899      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÍwã6¿ç¯ðm÷F*?õqL;™îìÛv3i/Ý=(6kÇ–<–”Lú×/@€²dÉNûš‘ 	‚À$¹ð/™…ÎÍ"ÍMl…´‹ÕîJ,ž ïÇ+Éþó–¨ïnþõ¯›»ëÿÞÿãêö¾ßËp¿RhÜÈ׫ßþ+kØö?®D¬óÌ.^àAÄ2ÏÕbwe¬Ž­Ñ:´l¯>_ý»ŸpÐë‡ÎéÏØ,¶Ê$‹H›8K`ŽY-‹XXÐZ”Ú|¡ÎöPÚ¦˵{,ºm;£'°r)UØðÑOn•:êdzè|À¶“™”9¤È„˜™G«Ø˜Ü2—ßͺ!Yÿ#¬ÐDnêîÐÀ³œ;áLŹ0êÏI.™}UTUÝÒ*îÛÊùó:e}¯,
š°W°–	¸±•AÄ‚/åvK¸ôàè·)·pðÛWzj×Ù²ÁZZAÁoJ?a%±,yoZ΂~žØƒZoÐð\l;O€ÑÐœX&—!iÈu’z® éóˆdl¬Ê./ßsͬ?F$_eäX€Ï®õ*KØE€8ºŸµÁ× ™|
ˆ—M¹ÚŒÆ`ûù“¥ß‘„<ë²*¯Ô‚¦¹¯›²-ÁõžZ&uô@i•y·ó6c@ü4“c§¾©ÌÂÀo]ᢙ]¾8÷…šp±”H4rƒÈH½¼¡Vþ<ü‘Fÿî¼Ì5µîŠW"VE×0gá7
-¬_;w(/ßòF®îPÑóg¸àAU¿~ÀÛøæã?ßÑØG3â&ÅØ!P­³å¶nZ¤rÒhC­Ô›Œïܺk¦ž»»Æ+Ò¸ó¦ÃCÞ‚[?}¦_©`Ç“ß>6ÝÀßw7DÓV|x
­IÞ°/–zÛyœm†ŽjOÚ\¹¦9ïgÊ‚iŠü
?p]ð³Àåý¬¬¢C]·ÍÄÇTk‰>viéžkfí‘Aè¢r#Ç‹óÍ‘¡Á³òeÕíÈeè(ñ—TDXš³S5ÔÕnŠ–(oæ6¨ükWr$A½ì¦!Ý‘Ë5í	;o>Z5;Yµ&–vBekN°X­Ü0=VŠ°]1pNDd¾ÞL6Ô—Hâ̦9_$j檱qž¦	3LG
-à„˜ì" ÌþH¨ª3ygó¡*Xm*cIŸ‹Æ	˜‹É0bJè€ÜB&â8ñÈ:yÎ
-ïF:x¤pz¸ä3®•ÈÂ6*(m™	¡BC.˜Ó…Œé±ëú|'\«î@íUÈ„8¢äDÛmýB$}ž´-weŸm»º³Ôœ`­¶õêçZ_ÜÖ7ÎFwF¦±ùÑÝë®>ºs×l"ÜÞ;“«¹fÏÝ^§¼¡qâAYŽ	ovy=×ÌF”›8‡”m¼‰{*aÈ”ë-¦¡0–"´-5ø£E"$]Nü­áøÐ9÷p>´›·)žK´ย_2‹GF¼MY=Q{A?¿“•iJž¾v¥¹Ã+s¶àûüÓ
«MQ=9NüB‡áBm?À¾€Ä~Mt{€„ï‘>a—¿4¸!—[ |òëµ7ç´:ø¤÷ã†h’-!.´ðf€*z/¬E½#HzèZj¥¤“9ã2.+@ëÃk?ˆˆ]Ñ`MŽ„ç}*ŸiÛÐÙl‹gæëfœzÍe˜-4 ¶>4ÁÛvüzhÞ#ŸC-„)G.ð|F\ e6´7ˆ¥Žö¦ÐÛérƶõ@î«é׫ÂóÐsŸãø6Ÿ^bk¹ÉÄðNX{k¡öàŽ§ïJwi4Ö?qP„§ŒþlLßô\(ùfK&i¤»õƒ‡[	Gä
/
-Á	{…àÃñäáÁ‡]D’•Žy}‘hÚîšP¨†—çnð•m±ÛÏB|Àm2l &ÚòP\­‡½íáõîÍÝû›>X[j^ç“q
ÉY.³ì2\¹ÎÃuÏån]5Q·ÞGMù»›½òXÉÌ\^¾çšY"ÐÓ±\ô‚@””D±÷iKªMÃóí{,‘ õËûŸ‰xè|IþÑ[EçÁ>qAŽWú‰kú»épÅãp—„ûbõ¼I.zæê‹+Ÿ1·¦ÈÂ;«Ó1PüŠÎv©¨eÄÀv¡ÃJE„zÈjAˆïÇÁsݵM¹vÄÖnJn> ÂSã–í|ýËp½úõZ\|ý¿®Áý¸5GKZ¤\æcyÀ„0lÆ!¨¨'½¬o^hhëš®ØÞˆøË
žÉ9|j€§5o™(|)ªØ«<­yƒõ•
-ªñùk
-ªºŠ¥Hy,'Ê~aÈ“c2,œ„ßXÐ
¹£UJN#?­˜HÓÕnȬº§
5<ÐóŸ6iá_‘V^éúQEËì¸!ùx(žBN‹ ò@šï<æÇxá'Ì~ú™«¬†¦“Ú;Œªˆ"Åp=é,2)HƒòD_¦Óy\
-L¡•’ØØ,½¸tÏ4][Ÿ”EÌxi$1Zk0
-¼1ÁuèÒ„g$d!ÕPßOŽV;ܨÜSB†Š$±n=÷
-ÉÄiÖ¿ÐáguþZF3a*"ùp Õ–CìA~ÆŽEUlÒÔžûì.wÞ:±MF$¤†ˆ„Ï="yvHØ̈„$K
Ô³ሂ„£‹ËH‚}Ç„4éß IËXFŸËæ”Ö,BrˆEø챉XÆ¥Y:xw	Š ·©`Î^ÐÏ‹°!lH¿iû!‹ ›’öøötÈæQÇŸ©ÌáLu¢Nƒ–áÍ5Ä"%Ì‹”/ýøŠ6²s‰e áÈ^°3`ÑhŒ	7´3§?¢0Ñg6þ:‡E\Û.›¾žM¿ÕÚíÁKÜifÜÇ]£Ð¢ÙüµÎ+úŠÒ‰h!âêÞWùô÷UÿÞwN1˜"•—ñtÈuP{.2cL†ðð·.ò_(´`Mtœ(]¢çš‘b­øæ^ÀQŽÄW)exkÅŸWl™fùämhuM»¢— ¡Øï)o
¹£Qg¶*•Ä-¸Ä¡x™ÛªˆµNçvêCrݶ¢ósݹÂWž,Ub­
-.
ýyXþzÍêsB
-g‰ÉßÒXaGRÒ¤»Ž>Pü)–¡<¾”í†8ÎÑ˦Ø1åMäÖ=»-1M8¬2¬H‘-z±'_Þ‘åé3…ˆióäm73Òö–PW¸ìSw(ø³B”ÛK.ÿÁ­Ñú×ÔüHæYqd¦Á>{˜8H—Šd`.\M¤úʸ†H…j¬!,xø8C+²“ˇr½ö0«S®þÓç!ð3,2ÃaÜã+¨¾ç¡h¨”Ñ¥MeµÚvk®ëã¤3çcÓ²'õç¡®ḆG‹¢í•¼
>„¹¯—µñ“㙘Gô_üå/›Ÿ}°C|ó2Âá‡.
-ë$î*ѧ’[
÷W¦ÒÑÿ­“š~endstream
+/Length 3813      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZÍwÛF¿û¯Ðmå÷Bf>ùqt§›¾Öé:n/m´4¶¸‘HE¤ì8ýEŠ”Ü}µg03ð¢œ	ø—³ÌÆBçf–æ&¶BÚÙbs!fÐ÷ã…dž(0E}®î.Þ~Ðé,óD%³»‡Þ\Y,²LÎî–Ìßýûê×»ëÛËHY1OâËÈ&bþÃÇ›÷Ô’Óãݧ›üíöê25ó»Ÿn¨ùöúÃõíõÍ»ëËHfVÂxÅ3œðáãÏ×Dýx{õË/W·—Ýýtq}×í¥¿_)4näëʼnٶýÓ…ˆužÙÙ3¼ˆX湚m.ŒÕ±5Z‡–õÅç‹ÿtözýÐ)ý›ÅV™d³VI6­eZ‹R#c™š´Ó²’SZ\¨åMñ-ªÅb墶]oZZ•ç³þÌ£õ;®	tOi“ØH©‡Ü]æj^ƒî•ï.e6wËýÂá»™W®}®w_¨³ÝØÿ§jAýEµ¤¾²ZÐØ¢qÔ²u»‡z·)ª…{ƒ-ù¼]qWãvOnG34mMê«ÜcÑ–OÌYTͳÛ51êåH›‘Í$VÃöeœ[«N¨óHI'RP²—~U=ß7nIT[Ó³q-É	—›ý†ÚHâÖUmYW<®Ü8¢`×Ü´r
·ñ>襬ºþ°VÐG轸L-çKÚü,
+‚óvÉGïü6/ÝC±_·zÕR…
ÿýäV©ƒ~<‹Î{,yœd`;Ä!E&ÄĦòXKô±sKw\k|L›XåFç›#C)‚gåój¿¹'—¡£Ä'©ˆ°4g§j¨«]-QÞÌmPù×}É‘õ²›f„t.×´Gì¼ù`ÕìhÕšXîÙ	•¬9vÂb±p[ÀdôX)ÂvEÏ9‘ùz3Y__"‰3›æ|‘¨‰«ÆÆyš&Ì02)€bF›¦Y›þPUg>òΦCU°ÚTÆ “:=0“aÄpª(H™\Ç*"sç iãDÁ=¿ٛž6`’[ÝEŸ.£DBP%j~=R
Lªág€|±É¥7ÙÙ×™Œ…ÉsM\=Úïö ßðöãFÍÞ×°§Y[aæ¨?µßW¢7l1 ÄŒ(#¸ñ†–‚o¶k·ûÝ›.6TôäĨ|tà&OãD'zÖWé?;%Á”9¤9Ñ!;ùg6\`'º‹Ñà%§ácë·WÀ,0ù¯|Œàº*—eûyð‡·Ñé§6N3Pyoú1¬¦±TQÓ̾Ÿ·nQbzâ¯#Á!6Øöw<)2ÓBámU
xØÃ%éaŠÞŸW®"êýÍçÏ×mWE`ä5‹}[oŠ6"pJEœ)m‡×N¹€[ú…éÑUnGÑ£–’.CécB|å™=ba³—Ú—/U±)Ô¸ß.a‚†zðn=V¼Vi¬4*3À,õi,uîÙ³n{gÐñGýãCÏKáÛ‚ò"”
îž‘4ëÙÜÊ4#;è¸^“a4ÊÀQ@‘jÆ}Ûòµ„aV.éRðÚ—˜Ìy¤4”IÈzôTÊ$LR´®8D‰€MÒ¥ª´º‡Ø_8æC²lè)=_\±ã&ŸB%	t@Ú?ˆq˜x`ÌRsnµX׋/œf}qÏXÚ8Ø¡b™˜Wj:}®3X¸ºÀÎ=ì\³Šp{oH Ì«¦š=w»{ó†Æ‘e9æºÙù-t\{xPnâ²µá&î¨z!sP®·˜†^Àº"b±*ªGÇù_h×_¨íØÓ/‰nwë=p®'ìü·—!ä|
„Ïûa½v5™Ñêà“Þ¢I¶…2Sî\àùŒ¸\ÞBéžÅA u°8˜€ØN×3¶-{âp_MO¯ÏCï]‚ãÛ|n‰­è&#Ó;bíì…ÚƒCëÇ• îÓh,~â Ï=Ú˜®é©$XòÍ–ŒÒ(Èuë{¸É›^‚v
+Á—ÃÙ˺ˆ$;",òú
+-,дû{jB¡^ž»Á[ÖÅf;eÑr“i1Ò–ãjÙïmw/xo†øÞÍØtáÚ²Wð:‰+¯­ÌÒó€Ýç:
Ø—?ºeÕDûå6jÊïn\ñÊc%3s~ùŽkbýa`0:O‡pÅBQRŨ-©0
ï×ï±>‚Ôoï%â~ïëñÞê|4úû¬9^|\è'®é9tÔþŠ‡áþ6…	·Åâx“œ7ôÎ¥W>abM±
xV§C›ù
œíR÷pˈžíB‡•Š/ô‘'Ô‚ ߃÷zß6åÒ[»*¹y‡OÏX³óÅ/ÃÅZèïkqñå÷
îÇ-9^Ò"åÚ0j&b~N=éeňôB3@Û¾Ùk"ÃÏ!þzƒwrN ŸZ„àqÁ[&
+‘
+%ì‘U¼“8ïÊTàó>ªºŠzuHy¨%ÊnaÈ£c2,œ„® ;G«ÔQ]Ü£­`"MCT»"³Ú?®¨ážÞ¿øÄIÿ»iå®U´ÌN¡’»â1$á´Ú!¤yë18Æ?böÓO ZÑNG…wUEŠ-zÒid‚Ø_eö•aŸë2®P‹?
LðX@³«w\Ëë£Âˆ9Z`IgŒÙLïMp º:á`	Yè€ÀoŠGG/=ÛíoV‰$VB†¢$³n9õ+’‰Ó¬ûM‡S9œÕùË„©ˆä#‚”[öùI8&U±IS{T/ì²$¸âý©ëÄrLa—êã¾w¸äÙ=.a3ã’,5P÷Ìv%
+e”:DJ,ã	öÓ¤û9IZÆ2MØ7§¶6 ’}DÂwHHœA$Hð!¥N{¿Á$ÈÄmj{ˆ„³ô 6„íé·#m7Ä#dSÒ~@í³yìñg*s8S¨ãÐ¥‡HxõI	3F$åK@¾¨ìœLb9¨‡H8²ìˆ4cÂ=­‡Ì‡éÌ}šJµO"—·Ë¦+iÓ³Zº-x‰;λèk`t›¿Üy~xaEWY:²-DœƒCýÝ[âŸîÖê~úU©S ÔyLí1†ÔÀD6ŒžüÚEþ…v¬‰Ž¥³³tLc°Š¿Ûco_†aR†Ÿ¬øÛŠ5Ó,œ§©î—qâxàl‹×	 ØTi¢ú9Wöìç·4šõ¨è—Í“XÇé¨J.r<ùô¬V;¦ó"Œæ:Sd¥	ð—õ+{Ùq²E>¡cÐjÀ/÷­°_¥ã¿?"¦7«$–ø£ÊàÓúMZ
+¹ðIçì³1
€%wÁrÕ&[N±À‡T.n.3ó%;Î[ѳ¦ÔI²š†–ñ°1ިƟS•¼²Ó4îbÑÃõˆ¢¾l»
+¶Áº*׺µMâ$SGj[ç_SøgèÔRxï½â·o~a¶ÕTÌ µO1C´¨7[Ї÷‹ñrËþT¯03?ø8Z“ñV¥?¶ÔÀUhn‰­åiYv(ÉeMŽš³Øæ&Âxpi•êSgΕç"}åh@Ñ°§÷̸®‹%ƪÃÏ10¨{%Ú¯•éმš¶Þ”¬¡¦öµÚ”~C¡M°V+·øÂr„1P§5VÏÖ|ü÷<š¿
V]㉈Su”L¢ž<áô–ÝiBƒ"ΤÌ^Õ F½sá|ð#Ͼ-àz\ì××ÏÆjÍM¬€áU¡r›©{OPé¼ÏÛÐ:ËšvEß+AC±ÝRƲF£NlU*‰¹Yp‰]ñ<µUkNíÔ‡
äº)lEçùÑ×t®ð5'KUX«‚K@Cw–?Z³ú”ÂÆYbòׄ4VØ”4éfO_	(þKP^ŸËvEÛèySl˜òŠ&rížÜš‹&VéעȽ…Ø£îÈòô	„BÄ´yòº›i;K¨+\öq¿+økB”Û•K.üÁ­Ñú_§ù•‚Ê“âÈLƒ}v0q"ò9’.;IÏ\¸ŽH••aõŠÔX=,Xð{wê»]mcüØvâÒÝgÿø›ÞÃÏŽx˜Ž`ðá…;Mô±äV„g*ýƒyT)endstream
 endobj
 1309 0 obj <<
 /Type /Page
@@ -5294,14 +5283,14 @@ endobj
 1312 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [326.242 468.2497 375.5914 480.3093]
+/Rect [326.242 452.6821 375.5914 464.7417]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update) >>
 >> endobj
 1313 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [353.2799 145.2015 410.176 157.2611]
+/Rect [353.2799 133.2463 410.176 145.3059]
 /Subtype /Link
 /A << /S /GoTo /D (zonefile_format) >>
 >> endobj
@@ -5314,30 +5303,29 @@ endobj
 /ProcSet [ /PDF /Text ]
 >> endobj
 1317 0 obj <<
-/Length 3504      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sä¶íÝ¿bߺž¹UÅ‘Ò¤Ó™Ë/u¦ñ¥¶ÛÉ4郬Õz5§•öV’ç× H.¥ÕÚÉ´sž[A@[Äð-©ŒgÉ(‰Y²(vñâƾ»`gåV!Ö·÷þ$ô"‹2ÅÕâ~ÐJ£8MÙâ~ýóRE<º
-ñòÃç›O×ßýóöý¥–ËûëÏ7—+žÄËO׿¢Öw·ïøáýí劥	[~øÛûï¯niHYß^ß|$HF?gˆÞ^}ºº½ºùpuùŸûï/®îý^Âý²XàF¾^üüŸx±†mG"K“Å3tâˆe_ì.d"¢D
-á õÅÝÅ?<Á`ÔL•‹#.Ÿ gS%Y–,t’EJpaø[Û”¸À.—Q¬3
 R{°(!9Æ¢T%Ò¢KNº±¹Ä=, Êb8tÕSI èÔ}Þ”íФ¸dKõ7 Y¦‘7/Ôx„Ù
5I¨¦‰“v±ðì¸H£D3§^™Q@i™:=þÚä»òÝ×þeÿuÞu3DS	•;å¯oÑ´&ûmÞ»–“@yx*ÍÓåsU×$H!ãH
-É É•åEQî‘@’.J”
-ûÙrm:í~_5„‘¯×Ú‰9^è[Œæv¤b‘Y†Që™]	ð4J»mni¥¾/wÄì¬%`WÖjõCc™ì·UG0§k8Û¨ŒÛ¼y,;’çàíðàFªäÖŒaÿô[·å¼³`1ê:A×å&Å¢ŽY«£v~”Y¼d±ˆx`‡pDiÆD6døfÊó
ÍnÛõšÚD|‘(‹ž@Ûö™;Ò\h¡ºV†–€7ÛYBÆÑÁ/©:4rúqŠM<‘12)6*?dWîó/¥e׆ç¯kë§Òï/«ÕK¸ôp!#L¾¼ÞÈú_æ,ÝHªµƒÇ-A§üµ(˵›UuøßÍhÚfšz×ÿŠÖÉŒ³‰Ö±%Øæ°+Ýj¹=ìÊn¤²<­Ë¼¶&Á`r¿µGnµLóHèLí¬i›••Ø¾mœ·RtBK[e@Î	>2>áE>ÓˆV؃¹%¹;:záÏWw+nzrjjê0h©¿›;[\Cd™åTÆñòWHælVv Gyg¯Á&ï§ð†Øƃ«ÛgºêPp5xL}¸O†UÕÆ"Yî¶yg™3$vyÕ2L·34ä&Ö³†
-‚=Õ³,â1O­þœ½—'Z—Æ¡'m’öM„õrrù‘iÍÍŸX±à´Ž®FxWW»Ê’j3,Ž·3iíL8¶	¸w£îþëÃÌ
-FµÓœ5ÄÀ#éæÏ8S¯Y'âçűe¢²’z5ö™È˜ÅÃÒ@Æ’§$cɵ‘1KÍêÁ@ cì:MK󇽂ÚåƒÍÖ̲óó†P«Ý¾íJ‹ñð2³KcŸ\HϸMÏᦙs`gCÕ]*ÎFð6T
±Î‡ª‹ÜY_m^Vë²ÎO"PÆ8„ü`¯®î±f–(ÓmI6^Ÿne
.ÒpÀ[¢¹¤‚.3)ÄöëÎ@%hcÿ\–~¨Y“ŸùIh»€aÚÁve×åF»µ»MœÓ:ot¿i2äÂèT6òI”i©Æçìtp.zZA
-“Å
-fH6Ù1íd
-þ ›ŒÁ¯};Tu¿r9úLž¬î‚”9Ó#0Fd3¸®¼XEz$&R¶Ü›OÕÚxZ5q¶¶e½ß5!®«ü±iÁ»48âý–H
[š‘Üy'á) ìÁo{Ä¿A«³¹ÁIÄLÁÕµïÊaÝ®úv¿ªË§²^­[tþ´}ˆHåÂ4»Ë=µŒ¨p˜ºÄ gRc3ŒiLW–窔S*nÊ4vx\Pãv®^⟚ë	UÜáD°¤Š,3ZÌÙ©ÓHÀˆtÄΌӰXopqJ-Hš€cêðdc£S„ìXèT½qŒ€•2îjÏÛªØYŠì1ƒÃ2‘¤Ë
)ÿŽÆl°:tjžE˜uŽE§°³Ä)ÑõÍÜeþBCÆG(ßø…I\²‡.’+›ÂcÝ>ä.iLÒH¦Ç–æ]M†7;mGn0"ÈÀCv³×:‹Rž:sËkðÎÞä°²ˆ=À9S#ßïëZ‹D™™Ë»³Mc=`Tâ쥨±)ËÚÏ 
e²+­«.¨G”mA²H¡'ñ½Y$)TºŒ	K~aÃIÈî"ØöeÆ—]cËÀ·à`'ó¼IÏœ?Üp2é[®†Eqâókëò-ºÆ“7æ:D8F/ø[þº¯«Â„ÒÐsóò99§–p$‘N³ILóŠ'd,s®õ˜rÁ­Ql}‚íbÊ°Ü0î€ðam)^wB¬óáŽÇ2r+! k›éºYÉäe-Î̪¡2pS"âѪ6¦Hýò¦Ó;¨·Bl»Â´Éª÷í¡·³«œöÇEøФ' iŠ§÷$æ´9‡hù‰ÎÜ—ëÁqâ³k“ ã*/û¹+S&‘™óR÷?ÝÏy2h
-G‘rRˆ«!šUgݥċž¿åÑu¤¸¿˜1´Ë¸
Š á=5vªŽ~{7JbÏkêù#ÃŽo mÈÌsì9j‰jHÆïöe(ÚäÌÕC,™êÉQØuæËêF÷¸›´Î™ò
-xmmÃUd‚r¹/9œ3@&£X1ù†X¯ ÃB^·V:Ý…
1„RJ½±²ÇšYzœ<‚l¥ž¬Mf¨Ô‘	ÓëØÛ¡
-
-xà×Gvcd‡Š
-2Jy;„¦tHóœ¦,’Z¹¢ªcèœ!š‚ÃØq‘y3„àì)MÄXK~—=ÂÜä|0Âç±øæ$©H
-Œ9ÛëŽw´ù¥|%<SᇸNŠmÕ¸tß…(n¶
-rŸÄ†1‹U
-ÁV*Ç’ÙP€KmnS.•¦úæXÂðÛFž€±›ªKaÂþPír£ØX; F7hc+™©)Ö”TÙÀA"›¿Ô¥Dg”4Ùú?¾¸@Ìg³=uÍš±y )ò®§É—‹©0b0Š~€ûùÅáwÏÀ›ñÐ…€ë@­c­’go98Ð-žòd¢ãD=Ü7sWŽˆt’:÷î=Å°™ˆbObØÿ‹¿ã˜^€Q¾îïB¬óþÎc6VºªõIØ¡¢ŒALþêêifu1
É!­n=ž^^ý“žóy:ðyjâóôÄçéSŸ§ßöyogR¹4ëúctwuû¯«Û¹”AA¬%ÄÄãÁ—ly6ö`,V$ö0φ¿2æ–CÚ2²²ßíô¸‹7xƟУO°Aþº|+|4±±	þR*íO!l,1çR9Ñ	A8êXœuÙ-Œ:Sà°xèZï tø’¡øëÞÇ:âøÏ؉!vÖEÄ­39ufΉ3PzªŸzäð™'Å&·å«¼Ë,RÊב&¬®½¯›cœXª'¥8§È‡nV³5ܺê­w0q™9,s«b‘Ûä¯Ün]ðÑõÊMno~íˆM“N†3ì¸r/¯±:ó\·#øÛðvœ{{))ðÊtV¨3ù&Xgœ%Ç繧8#GïLDÍ9øl¿è|?˜Ð˜ÏTpõl÷j·ï_¨ùï·êµô!Æ9וH½v	|O¢â,€‚‚ ôJ¢Ž(®´P”ÿÝç÷7>½¹£_ûyŠÖv¶©_ðÈà}ÉŒ|:¦X>Y|Ã%]3eÜkÆä3 T0ÏH™²¾Ã½"¤n‡æ¾#¨÷láÓxæ™r5¤#ñÜ#µÈcº¯YpÝôå¡)û?Y:ä(ë	±Î$é…s&ÄGÂRóQQAßÅÄRBzž^´öË
á‹YÐDCéöyQÚ	$‡~844~óÓÇÏ?¼¿¾¡^øÐÛYZ-Mh†¯Ç¶IX\®ŠÕì+i›$Õ¼¨pOJ'žiíä
b÷h~£§”_µ-ÃÄ-€‚B)ôn?} ),c©cNû8–,…€,ƒÂw8…‹Vw-M­š¢ÖåÙW.ø„cÁFøýjˆ-¯|R2*HÀ`4††uTQa¾-¨›r¦óŽ^Ý%ü<©ùòMS[Ä)Ê8ŽCFÚýjN÷r÷éÛ˜ÁðíZzК/Mûܜ̜‰„]¶Ž¬Ù
-X¼pâþŸ¿K!tA?óÑšÆl
ˆX¦Œç•§1¼ý€ñ”õÿæÏendstream
+/Length 3599      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Zmoã6þž_áoçkø"RD¤»Ù6Åm¶—äŵý Ø²-¬,y-9iúëo†CÒ”-'-î°ÁŠ¯ÃápføÌÐl’Â?6ÉT¢7md’¥,›Ì7éd}ß]07fæÍâQß>\üõ£Ð“ÅÕäaÑÊ“4ÏÙäañóT%<¹
+éôýçÛ7ßýëîêRËéÃÍçÛËÏÒéÇ›\Sé»»«OŸ®î.g,ÏØôý÷W?>\ßQ—r4¾½¹ý@-†>gˆÞ]¼¾»¾}}ùëÃ×a/ñ~Y*p#_/~þ5,`Û?\¤‰0y6y†Jš0cøds!3‘dRßR_Ü_ü3ŒzíÔQù±4áBñr	0gIfL6Ñ™I”€.`ûTîvÕbQ6°5¡§­ýæÓ‚>ÛrwÉòéì÷¶)݀ݰç©*Ÿ©ç±èªŽ:_¨©jæõ~Q5+Oä\±ˆ+žé$…
+ìùÙ]_î~IS^—³e»Û½›4ØJš˜,5nN×}¹)›ž}®úuå¶Ñ¯Ë‘5gB€I
Âc(eÜÒ±›<]ŒË$ÕF»Å`ÿ§J®2á†X‘ŒÒQ\gnÐcÝο:Yfá‹ÌÚ¼mP«ý®è«Öõ’L’•c‰fLM4Ó )\ŸQ4‹G‘†°1ó£Ñy]h»™?ð¯ûr÷òŽxÚ¿ÍFû¹äÂ$2Wìu6è>‡’”‰TZ}X—
+0UÓ®D]H3'Rh©šª¯ŠšZŸŠzïÚI³t›ýŠŒú‹fA½°?ì¡J³ß<–öôAm‡×Æ+y£v‰Zg¦Vå|¿ëª§’š: S÷ES¶ûŽZæ—lJ¢£ú’,ËÀê/TXÁ솊$T[DŽI»ØÀŽ@¥3ͼzýmDu¢eîõøkSlÊw_û—-ü?¯‹®!š«DôúïoÑt&ûuÑû’—@¹_Cfù\Õ5	RÈ4‘Bò¡%óy¹Eø’%ƒź™.l¥ÝnÉ­Àˆb±¨ÐNìñBÝid2f¨°#•
+ï9P‹‘]	ðºJûmYni¥
1;k©±+ë%•ú}ã˜ÔQ›×5œmÕ
+zçë¢Y•I€sðüxp	ø5SØ?}ëvµ*pS	–¢®Së¢\ XT±kuT.2K§,uÄ6¤V<°C¸a}Ã
Y¾™
+|C±[·ûzAe¢
+¾H”óžšÖí36¤¹PBu­,',o¶q„¬£ƒ/©:
+úxE‡"žÈp0)ªÐåVî‹/¥c×Fà¯kë§2ì/«ÓK¸&ŸÞ,©Éù_æ-ÝJªu‡-A¥üm^–?«ê"ñ¿»ãÀ6ó<¸þW´NÎŽ´ŽMÁ6÷›Ò¯V¸Ã®ÜF*ÇÓ¢,jgÌÞîÈ–ižmÔÐa5m3sÛ¶÷Vjz¸îIc É±MÞ©}`|"=Š|¦­p'sW%¹;:zÎW÷+.{rêØÔ¡ÓQ7v¶¸†0Æq*Ótº+*¤Šöl±­ì@/ƒlòá¸=¦á&64âÑõÕí3]u¨ØšŠ<¥:Ü'ûU«¥ä¸[cÎ’ØUCÊp¼}Cnbqd¨tr ØS=3	Oyîôçì½|Š¥"OÚ$Ý
š	çåäôw"ÓÚ›?sbÁ(\7¯®6•#Õf¸1ÁΤ³3á٦ƭïõ÷p>Ì®`U;7à¬ó#,™k:âLƒfˆ—Ÿ/àl¢
+Hõìs$c–J„è‘Œ%ÏIÆ€^¬Œ±!’±ÔÜ«ÏccÕhZš¿ßZAaÓc»Gù`±µ³Üü¢¡¡ÕfÛv¥ñø2ŽË@üèBÚy<ã7=áæÆ;°³P5ãYµ¯CÕxÔy¨F‘;ë«åËlQÖÅ	eŒCøÖñêêaÔÈòƒEà©%®O·²i9`ŒMÑ\rA—™F`
+Ø~ÑÙV	ÚØ?—eèj\¤:ò“P²vÝ´7jÛ”]W¬¬vk›BsAtÞè~s3äaT*‡¨	°Ï:Ñ…˜YS$°F«H…<ÈUäb"gÓ-ñùT-¬«Å^4°´.ëír_ÓÀEU¬šÜûœ:\`C¿&RûÕšfÔîÝ6á1`ÛcØÖˆ;ÌÎ'™‚»kÛ•ûE;ëÛí¬.ŸÊz¶hÑûÓö’FÚ%x¢2í=ùcÕŒÁ®AóXpÜ
­2ñr¸„dz￿ú|?B ¸É˜·1&FÀ¹Ð
+éû-c8ï}’Ý]±ë©dEE)¬Fƒ¥°㘮,Ï¥P¤X¬ öG}»Õ„
+wcÉ£xü©½žPÅÞ„%UdÆj1g§^# ò;#^Ãzƒ‹SjQÔµÃ)чíkp°Gó‚Iœ?\p2ù[®†%ilçò-ºÀ“7ö>Äv„/ø-ÛÖÕÜbi¨ùyùh9§–3®²DçæÔ¼â	3Þµb.¸5æëa{PçÆðŽP¬]°×ñN<ê<Þ	£¬ÜJ@dms¼®I™½±¬3²j,“%Rh1\ÕŠ<,o+½o
VˆeŸ9€2Yõ¶ÝõnvUPÁ}<ć"ažˆ¦Í
+œÞ“Ôf"àjÇOræ¾Ô˜O³^ÛWyÙŽ]™ˆ0ÞK=üô0æÉ (²CE¥‚BÑ
+:¦yÎs–H­|VÕ3tÎmÆah†¸È¸¸{Ê31Ô’?d07;¦@ø<Úô€$eI1o{µãm¿¯ÄGƒÍC„î®“ùºj¢±tßÅCülÅ>™ƒ1“Y`Ôa ™%e¸Ôô'½•6ýæYBøí'ŒXî‹…mÚÎÇ0a»«6…U¬ìw˜< V7 Ña+™G)©	kJJm`'€ˆÆ°ÐêA)ÑMtÇ .+˜m©j×Líɼèzª\p¹”2#vļßÃýüâÇwÏÀ›õPÀµ£Ò!YÉÍ[t‹ç<;Òq¢ƒî›±+G$:˽{ž0¬I*S=<½ÿ‹¿ã#rñF‚%uÞß…QÂÆTWµ8*10ù««ûA#«‹cHl°ºóxzzó!öOzÌçéÈç©#Ÿ§|ž>õyúmŸxÛHåì›ÉýõÝ¿¯ïÆBXKˆ#K\²éYìÁXªþö°ÏÂ_™r€å¶¬ì;=îñ7,ò	Ðzð	Dà×Ç[ñ«‰Ã&ø¥P†;ŸBX:bÞ-D¤
+¢;‚¸78‚X¼u¹-_:Sä°y¨:ï tü”¡øëÞ§:áøœŽØ‰%vÖE¤­3yì"ìœg ô±~ê3Àwž­pt[¾Ê»4‰R!tĺà:øº1öÁ‰åúè¥çÌ‹}7ªÙn]õÖC˜L¸4~”½U1ËmãWî¶.øàzå6¶·_wbц“ñwÎüÓ+…Vg«èvߎc¯#)žA™
+u$ÞëLMvx{Û3òôÎ jÎÁg‡EÇ3¸ÀX®1¦n6HáêÑîõfÛ¿Pñ?,a{kv&2Aï]_”(;MQFj%QÇ!>·­x÷Ÿ¯¨Ý>ù`ëí=}Ý,(S´p´Mý‚g§¤xr–ød•P±éò£Õ(·\Ò­1’Çm0iLN°‚}H2Ê9ÿˆ-u;÷Ãü/I 5¸¶øqÜDÈÜ(ŸD:ïè7MÆ=oÿ{h¸iúr×”ý_òž€s…˜h’ôÆ9‚±À“°Üþ¬hN¿Œ"SBž¡}ÞºßnˆÍ‚"ZJ·-楛@rè÷»†úoúðùÓÕÍ-Õâ§ÞÎÑjibD3~?–°M€Ùåj>}'­¥Ú7Hé,0­½Ü @Là]CØÃà1%ÃwmÇ0qMQ¦jwßÓfXîæØÓ>ôeS! Ì ü§ðâ†Õ]KSé÷qåÙg€?G6àúÝï†ØôæÇ'EMV©1Úõ¡aTTØ_T«¦\ é¼£wwO	 Ô|y¦M.âÄ2žã˜‘v;Ó½ÇÂÿømÈ`ü•w=(í›/MûÜœÌÂ>\ÇÖ(M'^Üÿó¯4£WÊâg~¶¦1\"Ž)ëyå)ˆw?ç>
 >> endobj
@@ -5358,19 +5346,19 @@ endobj
 /D [1316 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 414 0 obj <<
-/D [1316 0 R /XYZ 56.6929 504.3703 null]
+/D [1316 0 R /XYZ 56.6929 497.3965 null]
 >> endobj
 1322 0 obj <<
-/D [1316 0 R /XYZ 56.6929 478.0508 null]
+/D [1316 0 R /XYZ 56.6929 472.0732 null]
 >> endobj
 418 0 obj <<
-/D [1316 0 R /XYZ 56.6929 168.112 null]
+/D [1316 0 R /XYZ 56.6929 166.4376 null]
 >> endobj
 1324 0 obj <<
-/D [1316 0 R /XYZ 56.6929 141.3042 null]
+/D [1316 0 R /XYZ 56.6929 140.626 null]
 >> endobj
 1315 0 obj <<
-/Font << /F37 751 0 R /F21 662 0 R /F23 686 0 R /F11 1321 0 R /F39 868 0 R >>
+/Font << /F37 751 0 R /F23 686 0 R /F21 662 0 R /F11 1321 0 R /F39 868 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
 1328 0 obj <<
@@ -8588,7 +8576,7 @@ endobj
 stream
 xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä000Ì ÝÝÝÝ’‚R"‚´t	ÒÈ‹>ïÞûüž³?³?½¿w¾Ìÿ^×Z׺î7¶‡Œ5Ü
 ¬‡¹rðpr‹t´P(ÐWç…C­fL9g0ЇÉ]Á¢#°5@ðòxDDD0rp'/gˆ­+€ù‘ƒ…ý_–ß.+¯ ‘.[€ññÃ…;9‚a®ÿã@=0àjØ@ `€œ–¶‰Š¦€YIÓ †P€¶›¨C@`˜˜`w@ÿ:@p˜5ä÷Õ\8¹d\@€‹y{‚ÀN¿!v€ØÙââòø
€¸l0×ǸÂêfý[À£ÝþG“3üÑÃñ{$Ó†»¸º€œ!N®€Ç¬ÚòŠétµºþÎíy„p›GOk8Èí÷•þ`4¨+s¸‚=]粬!.NP ×cîG2'gÈn.˜í¿°œÁ¶@gk(ØÅå‘æ‘ûwuþuOÀ¹=ÐÉ	êõ'þÇëŸ ®.`¨
'&ïcNëcn[“ë÷¨¨Àlàî¿ìÖnNÿÀÜÁÎ
-Äü{fXE­á0¨ÀlƒÉ¥	w}L	`þŸu™ó?×äÿ@‹ÿ#
þ´÷×Ü¿÷è¿,ñÿvŸÿN­è…jÁ‚ÿxcê€ßÌs:B ^ÿÎýïžFà¿4þ;Wàc!d`¶Íàáäæù€¸(B<ÁÖÚWÀ}¬Ô»Ìì…ÀÀýSL7÷ß0};Èö»ôA`˜õßå?6éx.YMEc¶ÿöªrèA§Ë‚GPè¯íÇ9pÕ÷rþo:#
¸õ?¿ùdeáž^7Ïãú=*áðû7¹ÿñüë¬tu†x^psr?Fr~ÿsÿÎýOÀìo4
+Äü{fXE­á0¨ÀlƒÉ¥	w}L	`þŸu™ó?×äÿ@‹ÿ#
þ´÷×Ü¿÷è¿,ñÿvŸÿN­è…jÁ‚ÿxcê€ßÌs:B ^ÿÎýïžFà¿4þ;Wàc!d`¶Íàáäæù€¸(B<ÁÖÚWÀ}¬Ô»Ìì…ÀÀýSL7÷ß0};Èö»ôA`˜õßå?6éx.um¶ÿöª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
@@ -8611,7 +8599,7 @@ $O
 t‡Í=žÝbóÆÃwî6ß"£“˵?”JËOP2RÐoQo+†â1)©w†¦ÜèådîI½ÈZ¿VÍ­(e÷åû È"QÔüFØs(úF$'‘qL ®/¶!õÔ
¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ°gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd
 ÞyŠGÝ
 ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’	¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?ÒK áéá@F)Ø,êw÷ó?È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý@¥-«ä%Å~jÉwXjz1îi´·î¬%uÕ3^¿±g¸`d+ÎK[ŽDe—„]âò†YèÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š”™v_Å
[ªJÖ®²9m=·âú?\‹k>¼à¬‡¤*³Ñ³ž,Y
ê<‹ý¹uÓZ/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_ï‚¿œ%%½¥åŒìé|°D>W²7}C–Í#—ZR¸­$º`bÛGο…a¿9gÝS%\”Á/œîñhC|?s§Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O
 üõí+uqfº`Îa‡„°£â,I§ã¯½/‘˜÷ÇÝ›Á¤'P6ߢH‚Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)wL=(‚Œ£± L|)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í;¯åä²fùOî{&*‰äyÒ¯9ÛB±T¨d>è.òY[a-³ZyÏ•px9ÝØÜ>穾„»*|,4°ç	Žð=Ï	añŽ©{ZwLVqžCÅo, H;ç_7Gg[åGxd½DŽ…*~ÂJSÛ/
*ûÎÔF‹µëújQ‹jw	Ý]_-Òq;Œ,1t³õ2ߥÆíËòê{:Ö§Ùo$<×ð¬žôôJ©Àëóüλì„b›F=ÍçåcT”u;ÐuË›÷#³»Z1q“ÒYÖgHŠ^fiyv|‰¢,PkŠA±¢FH£s^…EËRôƇnQWEÛt%Ú·y3™{æÈŒõFbKã<%Æ)â"-L+{墒zS'“#é²ÊòZÃ+•÷U­Á׎#Ç©ÃCcæHŸ,êä;÷=íÏô.óYäg:¯jÔn¹¶Æô×êS:c¤¬UºW¹Þ/Ëf¹ŠšcO¥ÛøŒM¯lD‰Á¦9²ú:­ÈùÈßÛ˜ìÑËr6½õx§ç±2ú]úS¹‘	p7O¼,j1îöÐËÚ{ž$ªS7O–xYŽróæs÷â»ì(è˜Ýš‹ÏD‚@§­Y#žC²L%¯íáž›1A•Ã¸©3¾~M+ÖAîDí>¤¶¯cãµã-Nˆ¥”ûÚÔß	ÄÖtzâ"¹tãØ'>(˜“”hSðÕœM]ˆÎÛ…0ìŽ
ñâSPÓKD³—dOjnÌó®|KHtÞ‘Ñ+㢟S'÷@6„iõ“¨C,÷ág3B½žpÖáΡÄêφÖÑn‰Ü;ɦc“
_7T,Q1çTiHøBÕWL8­¡¾	 ,œ²£.±ßu2†)¶=–Oš ¹ÿêÚ´­Ùê²,
Aq¨¿râ^T!1í¢ëç2)áN\§‹¬‚)æÄËR…Ëbž÷ž6Cb5ü´çêÞ›Ô;ð¶¹mH“üÅL¸^Ȭü¤Ý¸Ê	{>«m@Ë›ðzéN‹›´×»ÔÌÃBÿ]¬—š@)õp[jÊâá…6붡²BSHQøר.öØ«N÷Ž`ðG¿§zŽ^n)?ìû±«892ÉÿxÈÌÄ÷Ù%¼­Ø3ÕÎZJðô]\ÿ^¸Äé„SXA㣅¸r}[(â0Ò@¥elöÉmi¶ö­EWÕ9úQѲ´ˆC¶Û¯µAñ=°g>MF{Q’= †*Ëk¨+™×Øõµk¤i@ïħÕW:x<›ó"Í}<=<²šC½Q¤4Æð÷i©UµSöA-ÒiMÛk×qnñÔÆèO“¦R<)D¾€÷/ÇT#î¡ÍM©	Æ$ÖžåÔ3³Ð¿Á¢\ç{Uª÷Þ<UW=ˆ$®&<ƒªZ€0óØÒgÒR*¹ÉÒO¦1‘'£ùŽŠj*5wË-·‰ûùT j4ÝióÍu``òh߯µ“K…ݻʔÑk‡‡A›”ôÈÔDôìtk¯ö2ÅÛö÷ú—¨§$ÌöZ¥ï@Î^ùÝêõ^E~§”Üúí¨u4߉<*ôŽ±§¸KJßùy/žn•C*}…ÃåLgI£J·8jŽ[“Þ³	”ØT7%JÈOïä,Á!ØžÈ+ÌÁ¯f—ÉȘs‡h`Úq¢O”1£<ƒ3(©dØOfBOŸ º'"p=Q£B¿âäpJ}ÝØü™ŸZ®¤!p{òëÈa}÷qÑ¥³äƒ£DKXôžòxÇ(žÏÑã
©¨“{ÏçÉšj¿dqX·ã·ŸP¦Üv£ä£Ï€³i¬¾AÕ;³@øyŠ*œoLœOœÕøë…ú¾›ºxOÛÝËc	-@YšUʳªø;žBiäMÖð.•\rž;ùU´¾Rø'î…ç)眄š˜	…@ƒi/_	A®ÉéÙêr«0áFx<×Er;¾zÇ´UÏšøSÂö²Ù„.¥mô÷Œhâæ¨É2Ø’ç/{I;õŠjÑm÷¬
-*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}U¹ôZø: hÁ‚)8f÷EµÔëÛDäµsüð¢ qTMŠ:ù‘ɸX!±l®ûÔ”Ëû΄,ñº17ýbŸgûŸ&fܽ×Y'jeAt
]ôÛïwV^þ%ÑåµÛR¼”tμ‡Ël¥¿é˜¦j¹„‚øϸ3èm>YjŸÖCƒÕ¸ÄžÄÈÊjbÆn“ªŒUý©?ô‹ïðu«ÈÃWøìý#ë,M€¾ߥJBQlŽ‰âXè-ebtxÃ]€s<—ÿ¢:XÝQ…¸w¶²-N;N¾?Vl¤‘vG‰…,Å%ë9êçöË'bìη9|1.…±!]¹¶DšÏó=RԌݬ¤Iˆg‰=Åh_ìŸ5rÿ/˜ÿŸàÿ	tv…;0ÿõ˜endstream
+*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}U¹ôZø: hÁ‚)8f÷EµÔëÛDäµsüð¢ qTMŠ:ù‘ɸX!±l®ûÔ”Ëû΄,ñº17ýbŸgûŸ&fܽ×Y'jeAt
]ôÛïwV^þ%ÑåµÛR¼”tμ‡Ël¥¿é˜¦j¹„‚øϸ3èm>YjŸÖCƒÕ¸ÄžÄÈÊjbÆn“ªŒUý©?ô‹ïðu«ÈÃWøìý#ë,M€¾ߥJBQlŽ‰âXè-ebtxÃ]€s<—ÿ¢:XÝQ…¸w¶²-N;N¾?Vl¤‘vG‰…,Å%ë9êçöË'bìη9|1.…±!]¹¶DšÏó=RԌݬ¤Iˆg‰=Åh_ìŸ5rÿ/˜ÿŸàÿ	tv…;0ÿÞ»õ´endstream
 endobj
 1506 0 obj <<
 /Type /Font
@@ -8620,14 +8608,14 @@ endobj
 /FirstChar 67
 /LastChar 85
 /Widths 1943 0 R
-/BaseFont /BINIFX+URWPalladioL-Bold-Slant_167
+/BaseFont /ALUQPY+URWPalladioL-Bold-Slant_167
 /FontDescriptor 1504 0 R
 >> endobj
 1504 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /BINIFX+URWPalladioL-Bold-Slant_167
+/FontName /ALUQPY+URWPalladioL-Bold-Slant_167
 /ItalicAngle -9
 /StemV 123
 /XHeight 471
@@ -8643,16 +8631,20 @@ endobj
 /Length1 771
 /Length2 1151
 /Length3 532
-/Length 1713      
+/Length 1712      
 /Filter /FlateDecode
 >>
 stream
-xÚíRkTSW‘ª¡¬òRIÕzX%2$¹Ñ
- ±hxÊCbî
¹%¹—^.4€ˆ*©Ê²ˆE—-0×¼Vp—Gµâ¬ô|'çODeA 95>”AïbJyŠ :DI3ßÄ•¾[?Ýwz{m®¸ºë˜-3}aé‘­ç·*õe
÷ù:]'š~ŠD>úÍq›ã§èq‡’‘°oØ°Š×O?-Ê6äìm½Ž&{få~ù¬‡Êᄤ—ËÛÛ>ÐÜqϼؒÖäùðg÷gw3ÏÛև߇øUô‘™µ·n¾z’›º©³ßl÷5ì>TBK,?¾‰þçÝ¢«BðjÜ\sy~ÂþgίÍô¶;=©·íKÆr™ÍR¿—s8Lj “H]lŽ-¬–g/ô¾]Q
-¬>ôs+õoi“ý:{°›)t+}¿GšŸS#]p¬ÒIY»@ãRC·FÚÖ·jý±‹–†µùN©
]\¿b(­i/c]òø+ÆoKvÎ|šøâEßó7FzëC¥ÁÍÊõÄŒOŸ™žÃÌÝöÚ&·8…ú«{¤( ´Ïn•±]û÷€ì–1ˆÜÈs¹yôw3—v_8®ÝWñ7ÙzÏo›M{Ä:+AÜ%ìãªGÿºÔj<ÀM’Å÷%Ÿ¼åy¹®ñBu°s]ÁÌDS³DR½¤y6Þ;8ßÍßy¡ï\Q‚%¨w™/ö芨Ïe;ñ&Æzìyé;ôSI”©iäˆ÷¢\Û¡-Rw±D.7øüjs>¬.YßåSwÒôã¼eûàÈl¯µûR׆Õn×êæì=&hxÙTdŸ{*jþAUNz°MÏ–3Û®Ô=&Š"^T%³ˆ¸€³­mYNŒ2¹g?ÙÀóMHyÝãdÝ¡ÃîMßZ¹hÇšÐn wP@O^’ûfëhoH†£¸¹#ÞŒÝ;VzçÇ~T0¸åÜ!Çw¿Øo–ú·Òë/üclÕZ/®£*ÒÀÑÄyZL0à–*mv±\T¤x˜]M2çï¥O]1SKšq»„d~u²º$šké]uÊÛ«bò¥ÒÓšåV3îÌ{RâjyFl>x-”ßX±¸]±~´rÂïn÷DFžó•‘ÂÎ_ά©doâå{“竲ôº®yYÍÝe*tA^[Ï|bø’ûÕicÓf«yÄiüµºcûuç«¡ÑöZhKŒ@Ç}~4¶3ßæýœÂÕtúg˜qiý˜n}h™¥ÿèÎKYQ˜îzD»–‰K^[ÇE×uX—'æ
-š”M
Æ=«Ší?ŽÖe‘ùÊöÛI[VËêOì¶ÛRgwÏ-h™µpçæŸ]/Ë”W~½Þÿk§/#_¾Ž?µÜå[}rÜc|ÒžcGZñ`û5}MNí¬¼ÿ.¹†?8vAÜšx­÷Ëѵ;ù/͉lfb‘—‚\ÕÛgÞø4+âp~5½n€ó.ÚÿüOPjAâZ‘Jû7+-Œˆendstream
+xÚíRkTSW‘ª¡¬òRIÕzX%2yj	 b,Þ/‰¹7ä–ä^z¹¤D|PIU–EltÉST”
+«Š@} Ô«0|‘V†°©Z_sÁººJÎüš5çü9ûÛßÙû;ßÙ4HCaáP%&G‚¥R	‡
È3›M¡Ñ‚qXN "'`!à>`µV
¸+›/ä­òøÆ2ô8’¦"€W0}’Ä"
Œ#
+9
+¤rBkÈ
+¹È0z&©Õ`ýäL°΄ñ,bR8!
+l„Ó”šÔ$A•à¿…!mÆ»TŒg’¢€×”L: EBªÖVRXk1²LjùoÈš^?—ëxÓOQðG¿9osþ9îT:ñ
Ròú©§E9fƒŒµ­×ÙìèF¯Ü/›õP1œ”2ãry{Ûšƒ;îY[3š¼þìùìnÖyûú5÷9ü*êHÑÌÚ[7_=ÉKßÔÙoqøò*¥$—ŸY³ŽùçÝâ«°jÌRsy~Òþg®¯-Ô¶;=é·Mc¹Ôî†Éÿå6]§è¤p¤/¶Ä•	VË„³ú\©0›ý=Lq-ÍÒ_gvÓƒ¦÷{$¹¥á±’èÑÇ*]µÔþa5T[¸¡-¡U€^,´6¬+pIoèâú—p2šöÒÖ§Ž¿¢ý¶dç̧É/^ô=c¤¶>T{^ú
ýTmn9â³(Ï~hË‚ô]ÌQË
¾¿Ú¨KÕwùÖ4ÿ8oÙ>(*‡±n_úñÚˆÚíýcÁœ½Ç
8v9瞊šP–ãÅ Þ+bÓ³åôvÚ†+u	§âÈU©L<>ðlkŠ£Öã†,îÙO6ðü’Ò^÷Y¨Æ°{ÓÃÇ·V.Ú±"tèP3ÄŸ—æ½Ù:Ú¦up7w$ZÐ{ÇLw~ìGƒ[ÎrÖzúÇ}³4 •Zác«Ö1¸ÎÊ([ï]d;0AƒZª4un4ÈÍz9Hžæeq7K]¿—Äš±*!*[*9­^n3ãÎ̱'¥îÖgøæƒ×Âù» ÀÛ•‘	£•þw»'´ù®WFŠ:9³Bª”¾I”íM¯ÌÖëºæe7w—-pªÐ3¼¶žùÄð%÷«ÓƦÍ6óðµ’Hè;[UÇöë®WÃc5œ-±÷ùѸλ÷s‹VS©Ÿ¡Æ¥õcºýõáeÖþ£;/eGXh¾ëã^&.}mS?Ôa[žt˜+tiR45÷\¬*qü8FŒ—E(Úo§lY=,­o<±Ûaç*§¤{naˬ…;7ÿìöxY–¬òë„€óü‚¬˜s¡¼þÀ9ß{..VPJîÉ¡bqÍÁ´{âÞðœç?|½g2ºäIìYSQ᫪ïŒoE‰døJ—èVÛZ]·º¹¦¬ptn­Ë†÷Âœw\^sòßÝQÒÁû¬}œºŒxù:ñÔr·oõ©Åœ㣰Ö5Ùz¤q\Û×äÒÈÌÏ•ußØ5¢Jiì¼^žÿ-k¤N´WïŸÃ‰Îg´ÏÂìfÝÿèjüçߥÖðÇ.ˆ[“¯õ~9ºn'ÿ¥%™EO.fȉU=¼y–O³#TSëØÿá¢ü¿ÀÿD…–㦑ãé”–-Œ–endstream
 endobj
 1321 0 obj <<
 /Type /Font
@@ -8661,14 +8653,14 @@ endobj
 /FirstChar 60
 /LastChar 62
 /Widths 1945 0 R
-/BaseFont /TLGFFE+CMMI10
+/BaseFont /BEZEGY+CMMI10
 /FontDescriptor 1319 0 R
 >> endobj
 1319 0 obj <<
 /Ascent 694
 /CapHeight 683
 /Descent -194
-/FontName /TLGFFE+CMMI10
+/FontName /BEZEGY+CMMI10
 /ItalicAngle -14.04
 /StemV 72
 /XHeight 431
@@ -8688,51 +8680,49 @@ endobj
 /Length1 1608
 /Length2 7939
 /Length3 532
-/Length 8790      
-/Filter /FlateDecode
->>
-stream
-xÚívgPTݶ-HPPÉIhrM‘œirNlèZº›,Q@¢ 9G%#A2HÎ9ƒäŒd âC¿{ιõ½óëÞóëÕÛU»j¯9çsÌ9æZµY´tyd K¨"ÂÍäåЀÙ[:£tÁj<²8pk&`a‘CBÁhÂAŒ†>B!y¨@@%`È!Ý‘0[4€]_ǃ‹‹û_–ß!K÷xnw¢`6ÖÛ(áhu@ßBü7êB¡´-`
ƒCršZÆ 
%»’†>@	êE‚á-gK8Ì
- ³‚:  kÿk°B8@`¿KCñÞbÉ `Êj»Ýu³‚:þvq¡H{
-uû
€¡6H°ú¶hæ`w†ü&pk·Fü!äˆDÜFØßúnÁ´(4Ê
-	sDn³jÉ+þÅmFÿ΂ݺëÛHÂÊùwI|·0·^4怠¡nèß¹,¡å»ßæ¾sDÂþÐpFÁlþÅ€€„Ú€‘8…º…¹ÅþÝÕ	øoÕƒáîv#þDý“‚­y	€·9­Ð·¹m`|¿ä`ùÿ²Cœÿás"ÿ4ˆý÷ÌpÜ’CpwjMÀ§@ߦ°ÿÏTæýωüø?"ðDÞÿ¸×è¿âÿíyþ;´¢3®¶¿€¿.Àí
ƒ¨~ß1ÿW,Øwÿ7Ñ4„þÅð߀ÐàÛ6È8ØÜJÁÏËÿ—†R„¹A!Z0´•-À¿íÑ»¾Š„à·Zþi#€(,ü7Ÿž-ÌÊÎáwÓŸˆþqA g~+ÏÞ|ª
-*Zº\¿MÿDiݪŽÖsw¼%ö_u¨# ÿ\üÆ•E¸jDâ~çðerÉö%e>w$ò¶J¨ˆ$k|X‰A\–³³Ëóõû9[GowWgó1Në:
Wz$>‹˜6!k˜¯S:”‰~‘g„e.0¦ãclKP«>»àÂÌ1yÕ’ ÀdÿS¡Õ¬çn9´éçï©|e>·'ëC‹›f§—ЛÙq€úYšµ«„8ë$fÚõSëÁ·RÞoÛ@*¾«ʹAÔguG…*|«eB‰;}ƒv©¢]ùßÖÒï6”‡yÛ}sx/Gj¢T«$Jñ£•H
âQ–®‹B~RlEÛ1w.ì*Çbr|¬½}$nÖ‡·Gs]> Ã?V1òx£+w¿³\õ9’e‡Ð†ŠØ¥ÍäÊv””7œœ¸äN­Ñ÷«/ùŠö.‹ú…&Ð)âá0äPùÝÚ…k¥èé¹éÛR§ö
-^8³÷&sݱ­|&éŸî#6cÕ¯‡‹úœ‚œEë=öÚÊÔïƒ.Œ}(pÚéc8hXÔêëeM±¸ÄÈpefI­|š
-8xÏŽo‚¹
Lœ¸Uˆ–¤¹ŸjñÝq*½ºÏáÃ'äy•JâêA@"]1\j-L¢3wØ°¥`”µÇ,–>aZ¦¶où¿-Ž~æÚn‹åãQQNq—5%
zh±)è#*õò¸”l\ÌÕ/(YfÿY½wç½Jt½o­QêÅTHú{ò=Ó™5Ú
-R!ß1Âr<;Þâ$ûg2³£§Ä¯Cǥs‹©Ï¹å‹E#‡„2‰ó9[ª«eÖb	äBñÇ›;qäë4‹¦y,'XÈ.ó¹^Ûû¾çm}l3S@+'éY“W[ZTç¤ay þR#ÁWeôùì¯w<Ààø!ËêHô‘ªÝ°a2Y'ŸxVc[ЃÖ̺«P‘|m÷L¨3X´•¢|FSp	õ6!wˆ¥qi­ÍÖ)/)y4ž^ÉdÏ—“¦'»À+Oð+Wë³Ã/HŽõ°8³:̨%¾0€°nô™¦RºNSX)šÄ©wo¸Vá"n®¡U®uë.ýe‡°ƒ5­†âÁ„v0äÓ=Ì­²Ðµ”ž²­ÔÂtwï‡tKy…‰	ö€À›Á²Ãí/hÆnfÔÛYÏß35|\Ã)͹b€½^s$QÛ<.'DÑ
-(^‹òp߬h7š” ~Ý¢ñí‚…Ë.^,°‰ðzÈî§D€×û3ÊZú’|JRA.KÞ&[å/0õî¼2³–ÛOy«óCúÒB«e€öžt‹:¹ïäCA2µÅËV‘ÀP½'Ûz”êÅŒ~,ÁÑ’ØAkQèoL¹>3a…\Ôô‘¯&û‡EÂË"g>1doµÖ‰g·s<î÷‚Ž!4ž„…ÊÚ%ôi®ä%-#£`‚h-GwX8n^]>ÃÇWÅîió¦p•ÞUÚåâãÎäIdØxÓ„LµvˆNÀî8‡Ä|x©îóÊØÆ|çBSP߮ଗ–g
Ô¢Jšóú¹mî9}Þ/@êcõH/š®JäÓü‚h_ÿܧ^à¼n‚K¼?71$ÕŽb¡’êRm:î^5c
¨íÇðêZDQ%qÞ©39ˆ;–*XgEvb»Ä#ªi.ƒRÍãÓLëŠ÷j;Už½À9ñû’šeÕôlëbZÊq5Sv‰¿P ÅùC»¬ÄÅYÚd42Ê¥¯XÜÿÑHC{€T óT½{bÕÞjÝ´?¦Ðàk)øeXïÙr™ÐWTbé£ÜlÝGN‹…1ß^¬ßNdVZ½”¤«ÔÀç,ZãˆÍaþgD¼äî-ç
-Çö7=s`[šzþáÞ•MåME÷¿€uG–h‰+÷ÜKI•9º¶Z¶ý3h#`+]¥J¢æ·šõ¬¥¸¦4G‹Æä5ÍɦŸñ
¨/„~
2…°ëIš%ƒR*µÈ¹ï¥‚CSž[çm•&ê,œ^ˆ®ül™ò‰0¼3F£!âù2°gáȺÝYzñ‚Ä^˜X@°æ¨Í›#díQ¿¸ ˜ßÈ?'ty…Š,ÿˆbx_¸Âæ••ÌDC«½¬}F0j|{¯Õ\þ˜ßsžù¬—}8$QŒáinúAµ$o<½öR•eµ#"Uòe¥rÞ‰KÿñÃ=Û`GS"“H®bʘ#6W?³æ—å‰ÖÎ+ëíø ·¯ô–-ÝI{ˆQeY:BøÂb¢÷‘>:_/!€ÐéË@íáÞÑȬýu¢‡3èµ+òLn¯óqŠq`Uúmò'ÄaeG-3¿rk	³o=m[¾Íbõ«	¢Ä"îE;A{°<¹æôþÊ1gŠº`F;¹Ex÷”‹S>EG‡t	62j"hkùýI5IëUÑ:ƒMn"A˜W¸Í(Î
-òÎqE„¹¯øç*+nû…Æ—²;OeŸöY:«*š“ïgœò'\Ý7"µkûl‡ÉqèËÑÌ'ð9‘Tgeix¿qVV^­ÐÅnOiêlÄ&Àh1ÿ¥n†	Šo-R’È!î±~x“ýè‘·ÞøyoÏõÏ4íÙ{¦Å\4X²‰¤÷•Ï´±ÝÈ/åµ½¸N%{’;4u)Ç!‹=íè¡ç"Â3¬¶Ðœš®`¬õ0¼f»åæ6ç-#vƒl|¯göÕšŽùí:qÄÔyN¿3-y„¨Å–UÇâ${Læ6¬ÆÚRøÉ™¼ó¥?"áZ¾þþË\øQ>È”	§{õîû7l]¢ÍK*;”]Rï¼Eú4à[·NhÀƒµŒÆëÍö—¹|j"œl‰\ö#Ã$,¼¡û4”Ÿµc2"S%öÍOZ5éê˜-=_~/•˜ñøˆLreá’ŽÙ7/Ý4w„_3ìƒý-Æ_õg$¨L&{[äã¤.¸4Ë<±I ½U€QrW(aRë*­ª)}¤{öÜùóš×Õ}ÿSM#¶ú¹”è>ž6ʈ~1ô–r¢„tBÖPÒ—µD 7S£á±iþ1N­@¤s‘e¸ö{‹>“õèÆw
-™mÜtW?e‡ÌŠØÇRXÝŸ¶«
qÐNøb%2t)(	æß-Ö§9¢A¸‰Éš2žŠŸ±;Njf:¯ƒ9NÃïÊœT)š…ùïš=l“'v!V‚»ú7?êÑš\“Äk=ò†º¦ù^š-2~ë‰Uïs‘.»o¨ËªüaMfsÍ%W2b+¯ø¾
-(Ì°?ø6|Kú‘œ™µÁ86<6zlDÌ)®VésF¢¹¦GfôZ¸èøJü
P!HlÆ<¼H›8ºîeg©õ/¶D-¾ú‰¤÷ ã›UêYœqáÕ±ÇøË
-*Ïp›Â¤AwÓ'v•ù7Vš4¶¨ž+jÙÚN9dB<ï·NZN,±$íŽÝ\ë|.ʳ4
-Úu&IFlµPÈ‹˜<>ê¼çO}ö•>ݧ·ðgžF±;YuQTˆ §ÿæ‡	¬ßôtD¤ûfP˜{s“cÞ·+J	.>xi¾’²È¦{¹3Åš®Þ~—ÛãŒd@ãa‚äÄ·Ž„kï887Kp¥ôRXŠCãóÑ°áTîEQæü^w~@³ßG±¸½Kë3rÎN¡ÀK’jùÚˆYi†Fý€ðF®ÒQG÷QÜKV1Wñ-ˆÄ]uÓ£¦¦Ç¦—D'Å4Žs^ï¥%͇aT{¦®ŒL7“ù—Šð¾äá®^8¡cññçî6S½¤(¸ZÉ€û`2$éß=ŸÝ›·4Žânâ%ÝÄ5Ì&¨¦ȇrŸšÉPjÔj©VÝJ%ž8#/Ô+¶tt:WšœÁcÓ0¤¾öíjMö“¼úŒº£èZ×aóŽÛÆýCØÛÉ7Û¾!-6‹Ú¯¿˜6œ6ÛÛj~ÁSis?ÛíS`¡°è%«èëÆ6¢™hSSÄrþû¤N¹’QëÔ_’­÷êsucÛUi¦¡G1ÞÔ‡´é<Õ
,¡7%ç”b>×Èê/7ÑÀdú^ÉÀŽ‹½ì±/ߤžâ:»özÝoW7…~Äf¥:7âTWÊxû¤¸1RTùã¢öƒ¿°ò}‘<}wD>‰ß­+=ó¦ºf7µ½îÓã'Z׫@='´EþMÅ)TÀSwú‹-Ñl:m‘Ÿ“¡ä÷ËG¡;r­ÒÐ/Ã*Ž¤fŠÞó-xz
-}~ÏLcÄçt>í	ÔN$c÷¬¤úœ ú=nÆ©ngþõžåÆIE^ÕÖŠdÙh›•™&|Œ݃Ûtmðp6ðQYMã©©SÝ;h†.¯ÚÉ/Švö˜ È6èDz‹~¾:ûK¸Æ&†Æ$€±sfƒr®©X¨Õ‡ìÝåö©6¸ÒY|CÈœ‘ÄHRÊ=›Ð<Ž3 S=ÍêU%6?Q<ÇÛSOújÞò5®+òr+׎™s[VŠ"ƒ¹ˆÛ­R@BLȼô½øóÉ*ùOx<‚Ýr”†a¯@$ñjKSMƒï”Øvª*8¬rŸâ¼Y¼ˆ5æ‡ßr¿™”‹ïÔØ	žÓâ8»­KÔ°§Ý;…§—?\—§Fä»j8‚\šO“§•×†øžŽu8a”öÖömÐú»«MÌø©rÛvÙjÐC;L‰C`„>Vx­iôALí+©Å[ƒ~þº†KIoä&žá2j4+»,~£7RQÅV$èÃL|‰<ÉœÄÐÖzÜÒýÁÏßo„˜0»T 2chÊ›îà
-!dÌFæö/¨˜õpŽI^ø©Ý©²‰µ([|«Fv/f»H/>_!üËê¹ocG¥%ÅÉs5“•ŽnÇ5¾Z‚ÏÝŸ¤±ðJ©ýšžÇÝ\UËúö¡
î[Ÿ2Êíß2û²Qx„úûs‘½¯Ø«PU XäxŠnO
-IÇäœ÷îÍóÍè	v ó4ýð
CihTðÞ²° ÇÒf%’2Žãl}Þç×^#ò†-¼hC¤ó|7ÄïçiжràÕýŠQÉH‚d.à–ŒñÆld„1(_¾wiNŽ3ªÖO^U·s5@p».ú0}¼ƒµ³W
-Oyâ|g܇;Òðh¬Ù#1|éôë6Ög²›œ·UëáÇ	rk_‹öw€º«¹j!:/œ*¼È_Ô¦¶S+³(#>û­pKÕs%ìÛø“hj£ê·ßN
-\O–ˆuõ–.½½h8¤Ëµ[%-n&í—o{Ø,OJ‹ä k ƒ$4Œsz!¼¢‡bÃ7Ú‡vçˆemÝÊ5Hcý™’W¤uÊTãO³‰³7	†³Ê;B¥È†“ŸÌõáõý"¡dËUŒtúÀóñ[í¹0!Ã<Ú—(U½›È>ä9íÁ;˜Ö€7¤ÊÞ­:À¤Õ²y£7À­ÔÁT}I”C¶–‘Qîì¹È\·ÞWõ3›Ã½ZÆ™&ÝhÄlÊÞK\o`~~çt!•†ó(à'¤§tq	Y†¶bëÑ4r3ÛDZëòa[ö_ó>(ÁÔE7	bO;8<0¹8Ô4;Õª>*ËVëu?+«h–H½~šq»x/·}$ãºÊá+¡V8|ýƒ!Ù‘`Ç©³Mò×ÎàåÇøQÝ'ï³eò^JYõžâ7:¯?¾kñs”ÛqWç®fa Š’Œý4>§ ÇZ'úy]Ü;_GdRÁú	È•†bn¥æf§çƒ\Qù²1³7›^voŸØ4Ò-מyþ«wýE’ñ$-¤;k3¡j¹õ½³"í§¬kEŸÄ¼ÕSíÇ»õ7ó´ÎˆÏÖ1ªÉœÛü¤¦Ð#,õ÷9ïÓ¬æ1Om—’÷Ÿ»uÄËnP“ÒZ}7LÎ$·*1e¥PÈ
mêõ¶ÇCgùVGŠñGÈÚ=Êïà9’"ðfÙ°ÙèRÒxªú;ø®^í,‚£åzOirŠ>׳wÈÍcÅ¥˜?!wÏÇFNyÆ/^€Â(Œ’‰‚SÌ—òñy`LÿâÅ”ÎàQwѳˆ.ýÌéììç ²7L‡²m³‚Ô-Ôc—†\ÂýÂ
îãE>`­X|úZ-‡ŒØ3!lüqÆ׃팚ˆfrMºîôaúKãŠÌˆxè¯Rnºí®{ɼD£?ø&´ÌFóŸ´T%ɘZ8­U6
-3ú·<Ȉ›h¥=¯`·C-ãZ*¾•‘Û3ØJ`+>…p˜;w	cÁ¿ù\åµdf؆:îÉVÂÊ£QÏ
-Ló¶Ú±{iC¤üD8þúñ7.4ß=£Nƒ~ØA·™Y¼ŸíQíì
-;dÕÚÞùYÌú.ëÅ3¬m
-Œ·Ò'OܧZM•ÈkÚEä»óÔAøV¿F+áÖØ\7H”ÕÁ¬–ÞÙ‹s±
-A7µ¢¿ï?å151"yUF„I×íòÏfwÊ*Q;1WG¬ä‡üÖWG9
-dòú“¢Ï¡ã6–±hò¶þ|áç RÖ/?‚jïVÈttf=]«­mîXCh-»E²`?|(“躃Øçw¹©”]“RÉÆè·¸¿½ú‚[O÷^Üä'^m[ñ™4]aÄ‘þÖ9ö5QºÄ”ÔbcÅ‘n"¾ÿ]½GF&<ç
¤3dRµ°%‘	”Ê.Óµ­ÉÂÆWòQmw)‡GÒDa™e¹ÔÖlNA|¦Z–ýÒ½‹Lýƒ÷ÛE}b\ÝîL» &épƒ·gr[‹÷šßžz÷ìòdÈÄº‚íüë£-«‡Z‹ÎîpnöŒ´Ð|˨)	2xqô¦S=w¶Æß
jIž6a›6Ä.OSy]ÆñþS§oa¶Ô«ˆÌ±â£Š51r»%ob2üpȈEÐ&â§ÜÈÕöIòÊp¤ì‚è¯ôV²í­NæçiX¯Ô²»Íæá‡A$­Ñe$D{òD¾Ÿû‡‡';,Ög¦•k\Ü Gái3¼q¸Qþ¥L‚¨99ö]/9(C쯆IV-u—ß$#ô?(Ð%¤<×~ü^nsÑÔpPpmªJÛ7'êüyô,YEj–lw‹hÓ>
;Ko·ˆíŲ"ƒÞhÆðÇû­uÔÌm:n=¦ÇŠX—N7ŒÐä£Ïà‘Çžßi®1zUL-íµf½+OGÅŽF÷Ù*v|­FO]ÆvGÓÙŸ¥¥>Š?$¡$ï.ÇpHSî	4ó¢1Ž‹,V‰Æ;…Š¥"mLôWµOËétoÕÛu_Ý„fhJ#ʯ\ü¦CÀ¹÷)O!òiç¸SÔD3ŸJ6IÐëYåÍW«;Õ9#%“UÔ…ò@KÁÝDFjðc¾®=ésË‹¯N|½Ý‘m*ú‰¯—œœR–Ph<ßûÒøºà;wíöÐ5Ÿ÷ãyí]³õ–èÏáÊ͇#
-Xæ"¢Úbò3¸ý]ub7¾‚夨õù-ÅsÅK>ˆ<–!!’=j‰Á
bê÷](åÏi·t9ù
-KÆ.Ha½+-Ε[åòÿÑÒñx Ciif|-is \‹¦ÿ€|6±m¦ÍñŠ =“1ä`K^!y9ÊÌßIjX÷žXHO~ûLýì«œÈF7v—")òï@µW™[zb™®ÕÚ4“*ý÷L´ªŽœ0–¯z$¹Š/‚„à{>UiO³ýE©²5êæ÷”t¦=Ä;î
-€¯À4?œt€sTeù›!4J%h¹‰¸—ŽQÏ:µ¿yÓ´(kY¸³½M>X‹–
sôqÀirÐÀ³8!ÂùÕÏS€¤Sì$óÅ­$R÷Ñ•amPÍ$?çÔg•ËŸ˜Vd[ƒ1ËiÇO°<Ø_¥¶%yÐœáZ.›eˆô¤Xþ*Iò{()õŠ_¼¾êW÷ºÛ£x}kã¾ããVÔ³Ö–I͵'EÜöGi‚õÂV;áåÏ¿Ø×6™+Ý$Éž	{ýTö"1Ðœä5v-V$ÍlÂÞ¯«ª›bݦ´³ã)º§ÊoS6”hLGñ…îÇ,v%¹u©I~®]%¾)Ñ}ú‚¸2¸ âoJ°]^¯ÿRÓ HmØ;Âúž³d¶ù핈`)ÑÑëùÄÚ”°•dv
-8>ÔfN-öÓ¥]¥rÆp4’	w0N¼‚+à.ƒÅf4¢ÎfŒý˜¬ê/7r¦ÀCêOÝpñ%\ï‚©.úÌ•â{šÞ‚§mÝ’ó³éÁm÷µp7ßßçŽÆQ}⥜ñMÃècFn°ãH¶ÈH¿­D^{D
^HÒœð.xØ´Yæ^¥$ÃNèR¾äK'^é’²td?õ’¸I}²ß©fxaúÁ(‹Œ™K‹ŠÖâ€MÓÞ*ôSæ›iô‘ h	šŒ%–ýb¢¨¦—úˆ*äÝ*Wæò(#]V’Ü<ši#ÒY²•Š‚DÁ°¡ÃÕFFV鹕6ÁóÑÕ+3ÙøÛM~o£¼Wö¥Ø…Ú©5QÐ8ÿµ;¼³Óæ?¾z¤á½³0MñÇ€nZ_:¾ª"‰4Oñ÷
™Ë±NGÕÛØW,vÕxF™GM2Îzä}ézÚZç=¯‘ZO+Itš_¿Êk÷ïMjëgàÒk/^R\LsG‰
-²©
-3ã½+ôÞÊ•÷aˆlª Ïn×–OBw:ëÌDöƒ^ቃ€¸Rn¹šd¢¯ÅÓò;SÓtd®ÌA~zM“èRVt}õÚ+'˜	†4~}µ÷°}³íÚš[T:áµ%|Å’Q"èXê³ÚÎÝ9"áòç0Tw³È‹d·¿Pô@åÉ@ÅìÓEâòxOæî¹Ã	åÏIXUb_4²üQ
¨:ù©^\õ47ãÇU¸µ&²ðc
óŒA«`á0Ôýµ˜—™žÌ‘¥ˆß·%¢y†.Sz¾M²hàž·ãý°óg
#$SÿçÅOÁëÏàBø[yã¦5åž Šq(OÜâƒL#‘'Þ/ãØ«*ûü©¯ð5X1œæ)ol×Ós[2L&³d´/øÿ—ÁÿøÀ
-#Ñ{0ÒŽàÿ",)ïendstream
+/Length 8789      
+/Filter /FlateDecode
+>>
+stream
+xÚívgPTݶ-HPPÉ™&çÐÉ™–œƒº–††î&K(HÎQÉH’sÎ 9#$ˆ€øÐïžsn}ïüº÷üzõvÕ®ÚkιÆsŽ¹VmVF-]^Yª„p@óùž4`ö–Î(]°ƒ¯ÜEXYå‘P0†pP£¡O†P@jÅÄÄXòGw$ÌÆ
àÐ×1ääææù—åwÀÒýžÛ(˜€íöÃ
+G8ÚCзÿãºP(mXÃàP€¼¦–1HCÀ¡¬¡P†:@‘`8@ËÙ³¨Á¬ (('ÀÀÿZ¬ØïÒP|·X²(€r„ZÁn·Aݬ Ž¿]<G(Ò†BÝ~`(€
쀾í€9XÁ!¿	ÜÚ­9"·ö·¾[0-
+²BÂÑ€Û¬Z
+JñDÛ‚Ñ¿s£`·nÂú6‚°rþ]Òß-Ì­
†9 h¨úw.K(C9ÂÁî·¹oÁ‘°?4œQ0›1à ¡6`$E¡nan±wç_uþ[õ`GG¸ûŸÝˆ?QÿäC£ pk> àmN+ômn˜ÿïA9X#@¿ìgÇø\ È?
âø=3œ·$À„ÜZðk з)ÿ3•ùþs"ÿ$þü‘÷'îß5úo‡ø{žÿ­ä‡k€íoà¯p{àj€ßwÌÿ¶‡ÁÝÿMôß
¡1üw  4ø¶
²6·Rð	üe„¡”`nPˆme°Ão{ôÇ®ï"á0è­–ÚàŠˆüͧg³²søÝôÇb\PÈß™ßÊó‡7?ÈPQUU…ûï·éŸ(­[ÕÑzÄþ«u䟋ßrr7€'/PTÀ+$ z{Ø„bÂb^ÿ&ß à¿Öê`4æx~[´ðOéÿõþkeö7E+ä÷œè¢ÁÛÑú§á·Ûʉ¼UôÏi¿-ùë?C…ºA­¾L!¬Ä^&¦$¡Ë(2ºž·µ±ºó>é½ÏöýˆhöI^+zq]ÈW9ôô¦Î}rÇñçú3®žr8{s<ô ‹Ö‹™³5ûÑ[ƒ(÷†?¿yaÒ®a¸çá„Ú¶Écƒ•móÜë»tC
BH¼ÃÌ.Ù¾¤,çŽDÞV	‘d+1ˆËrvvÙb¾~?gïèíîêl>Æi]§áNÄgwÁ&dóuJ§‘6Ñ/òŒ°ÌÆt|Œm	jÕçZ˜9&¯Z˜lá*´šõÜ-‡V#ýü=U®Ìçöïd}hqÓìô~3û!P?K³v•gÄ"H»~j=øVÚûmèÙïꂇJnõYÝÑ@á3þÕ2áľA»T±®üokéwÊÀÃ|í¾9|—#5Q	ªU’¥øÑʤñ(K×Ea?iö¢í˜;v•c19>ÖÞ>’7ëÃÛ£¹.᫘øϼу»ßY¯úɲ‚ChCEíÒfrå:ÊÊNN\r§Öè{DÔ—|Åú—EýÂè‰ðr¨üní‡Âµ2Üôm©S{….œ9z“¹ïØV>•òO÷Ÿ±ê׉ÃE}NÁ΃¢õ輶2õû c@
+œ6B†NšVµúz9S,nq2BÙYÒ_+Ÿ¦Þsà›`n'.@b%iî§ZüwœJ¯îsúð{^¥’¸úCHW—Z“èŒÁv,!ieí1«¥O˜–©í[oF‹£‡y‚öƒÛ¢Aùx@”SÜeMIƒZ|
+úˆJý€•<.%sõJŽÅ?ANïÝy¯2}oÁ[+B”z1’áž ‚`Ïtf¶¢tÈwŒ°ÏŽ·xÀ©þ™Ììè)‰ë{çqéœÅâêsn¹ÁâÑÈ!áLâ|®Å–êjÙµXùPüðáæN…:ÍâŸiËÉ#V²:~×k{ß÷|­t63´¢p’ž5µ¥Eu.úFÙê/5|Ÿmƒ>¿ˆâõŽ?d]‰=Rµ6LÆ"ëä—ÈjlzКYw*ú‘¿íþƒ	uF‹¶R”ψP
+.¡Þ&ä±.­µÙ:á%%¯ÆƒÀ+Ùì£àrÒôdxå	~åj}vøñÅɱWV‡µäfÖ>óÔAJ—Ãi
+E“õî
÷*\ÔíÀ5´Êµ³nÝ¥¿ìv°¦Õ°“@<˜ÐÀÁæ„|º‡¹Uº–ÒSCö¡•Z„þîýÐni¯0q¡~‘x3Xn¸ýÍØÍŒz;«ÒÙÁá{æ†k8¥9WŒ°×K`Îä 3jºrBô­€âµ(¯÷ÍŠv£IIê×-ºß.X¹íâŘ	¯‡ì~Jx½?£¬e(ɧ$â¶äk²UùøS_ñÎ+3kùýô·:ß8eî!-´ZhïÉ´¨“ûN>"S[¼l
ŒÕ{²¯G©^ÌèÇ-‰d±…ðÅ”ëÓ;VÈGMùjr|XP"¼ü :@7ó‰Q0{«µNü8»uø˜“®Ü:†Ðõ‚,ç
ðp\âm|ü¹1ˆ1©vs•T—’hÓy”p¯ðªk@m?†O×"Š*‰ëN™èAܱtÁ:²Û%QMs”jŸfZW¼WÛùì霿/©YVMO·.¦¥}wpY3•a—ø«ŠY\?´ËJ\œeÜAF#£ÜúJÅý4´H;O5Ðk°ÇVí­ÖMûcŠ
¾–BX‡õž.—	OpG%–>ÊÍÖ}ä´XøóíÅúíDf¥ÕKK¹J|΢5ŽØxJÄ'IîÞB7Wˆè8†¸p¼éɘÛÒÔ?ð®l¢,ïh*ºÿ¬;²DK\¹ç^JªÂÙµÕ²íŸAù³[ùz(U
+5¿Õ¬g-Í=¥á`8Z4~  iN6ý”@}!ôk °)„COÊ,”úP¹EÞ}/šòÜ:o«4QßФháôBlågË”O„á1
QÏ—=GÖíÎ2‹$ö"Ä‚B5GmÞœ!kÊ€ÅÁFþ9¡Ë+TdùGô“Àû"6®ld&Zíeí{4BQãÛ£x­æ
+Çžó,g½Ã!‰âŒOòpÓª¥øℱ—ê¨,«镨’/+U²ðN\ú_øHîÙ;š2™´@r•zPÆœ±¹ú™5¿,Oì°v^=³ŽÐŽrûÊ`ÉØÒd±‡U”£'„/,&z‰â£óõ¾Ôá­ÌÚ_'z8ƒ^»‚!OUáö:§˜VeÞö¨|BVvÔ0ó+·–0ûÖÓ¶Ú,V¿š J,â^´S´+kNï¯s¥8¡ËÐ	f´“[„wO¹¹Ržáè.ÁFFM„l-¿?®f$i½*Z§g´É-@$ˆð‰´…G©3ªV;eW„ôÆwœÃðÇkÝüÓï«Ï0¾B¸9lZàâèàø3x?Üßj¼¼ß· E=_a^ñêu(ývЕA‘0U…#­ûØ-a¶Áî¤SÙÃL
+-gھ蟖¤§I„²kZKéä”ð
+›û,¥ñ­º“ÛýÙU@žXÒÖrÝ}Â;´w`D­.à™Œ«ž¥ÅÇ3\™»ølð­…Ébñƒ¥‚U³¢ÌöMÌœÞÎÛJ”…¶WkÓhý j¢’«qµD¹Kz瑳³B|óG\Caî+þ¹*ÊÛ~¡ñ¥ÎGÙ§}–ΪJæÄäû§	W÷HíÚ>ÛÀaòœúò4ó	üN$ÕYYšžÇï_œ••W+vqƒÛSš:±	0ZÌ©„›a‚â[‹”%sˆ{¬Þd?zä­7~ÞÛsý3M{öži17ÍÖ‚\"éýGeã3mì7
+Kygm/®SÉçÍÄ\ÊqÈbO;z¸‰ð«-4'¤§€+k=ž~(6¸hLìÈÒúô<6»¯´yjÊ^"þxNLÝ°Ç%3jz˾‘e2 ÃÏfĺEÎ>_žÝ(¸š¤²uy•“®ƒ›{!Þ4l"ùíóQtñÚIÝE°ºÙu²¯‡Ån¹¹ÄùÂGˈÃÄ ›ßë©}µ¦c>]'Ž¸:ïéáwæ%µØ²êXœdÉ܆ÕX[
+?y“w¾G$ÜË×ß™‹<Ê™2ãtÏ¢Þ}ÿ†­@´yIGbc‚²Kê·HŸ|ëÖ	
x°–Ñx½Ùþ2—€_M”+=‘Û~d˜„“•/tŸ†ò³vLFd*°Ä¾ù±b«&}¢¥çË/à¥2?‘©"B¾,|BÊ1û楛æŽÈkf}°¿Åø«þŒ„g“IÆÞyã8‚©.ͲmhïF`”ÜN‚”ƺʨjÊéž=wþ¼æuußÆ?ÀTÓˆ½~.%º·2¢_½¥’()“5”ôe-èÍÜhxlšŒS+é\d®ýÞ¢Ïd=ºñbfýFÇO¹!3‚"Ž±6÷'íjCœ´¾X‰Œ]Š*ÅÂBùwK‡õiŽ€hn"d²¦…Œ·âg쎓š™Îë`ÎÓp¦»²'UJfaþ»f[Ĉ]ˆ•á®þÍz´&—À$ñZ¼¡®i¾—fG‹LßÇzbÕû\dÊÅï격|X“Ý\sÉ•ŠØÊ+¾ÿfÜŸ|>„%ýHÎÌÚ`=6"æ’P«ô9#Ñ\Ó#3z-Rô|%ñ¨$¾Gc^¤‹M]÷²³Ôú{'¢_ýDÊû1éÍ*õ,θÈêÝþ²â³Gƒg¸LMa2B Æ»é»*+M[TÏ•´lm§2!ž7V¦Ôˆ·nŠæ‘’¸†pj7ŒÙ>ò"$›XêÐ:{—­¶^˜u^9Ì’„‡DW¬9%%^ÑËå,W0ß²¦ÜÝ™ZÒ×ý/õ{øúÆ>²Ý” à/"ŽDkúmù0§_ì>WTxìÑéƹœ ‹›
+zƒ½Ê-%¯Oà¸L5“‡û’ªV,î½øÊáÃz‡>ò&ïw¼´rY6Ç—ÆJwŽGƒ±Â*ÜA5ƒ
+ëšSùSÕi…Ÿ*z~Öå{OrÛÎâ¿z»—­’M®læ|Pû„î"‡ãüi®WêæˆOâ›Ð'ñëgÏbíbœŒÉQùb³	3.ã…ñk›ÌBd¬ilüÖw_ãcÂŒ´¾,ã
ŽxË?
õ XËÇŸ8	´¬u¥Æà7äW~\EÌDÎøZÅ~+Œ;Äãèš–!Ûa{Í3†Ï¤>™èÝšñüp{["â‚Áºt¡ÿÒÝRÕ÷j.9ÿ4~s¼GÀæA¯=ÉbBõçò@Tm€87.Y© kTõc‘,ÄSy߯N-¸È~R>H9im8àÑšS$õ"OsjpQô¢’Å0Ê+¬΋7rÏû­Ó„–‹r.Ibû„c7×:Ÿ‹ñn'‚vÉE“[íÇ
+¢&tG÷ü©Ï¾2¤ûôþÌÓ(v'«.Š
+òôÿÑü0íû¾€Žˆtß
+sožbrÌûvE	²ÁÅ/ÍWRÙu/w¦ØÒÕÛïòxœ‘h6œÊ³(æÀ’ßë.höû(÷¢wÉbsFÞÙ)´¸qIR­P1+ÍШÙÈUÞ"êè>Š{ɦ3Fâ*±‘¼+«nzÔ4ãÂLW`zItRü@ã8çõ®QZÒ|FµgêÊÈt3™©(ßk@îê…:îac1ÕKŠ"Œ«•¸&³A’þÝóÙ½©qK3‘(ž&>ÒM\Ã\`‚jŠ Bø÷!÷©™åF­–jÕÍ Tâ™3òB½bKG§såÉiQ
+Ý‘o•~~æHj¦ä=ß‚§§Øç÷üÁ4fA|Nç“ž@íD2ÏJªÏ	ªßãfœêvæ_ïùQÎ`œTäUí`­Ø@–¶Y™i"Çø¡Ñ=¸M×g•Õ´1š:Uпƒfèò©ü¢hçˆ		Šl`‡N¤·èç«s¼„klbhL˜:g6(皊…KQ}ÈÞ]Ÿjƒ+ÅÁ7„,IL$¥<³	
Àãyª1ÕÓ¬^Ubó¥s¼=õ¤¯æ-_ãº"/·ÒøìX¸¶å¤)"¿öÑ7ôh‘=@
+ sœçã¸!q?Oƒ¶•G¯îW̳ŒÔ)HænÉøoÌF–A£Êå{Ç‘æä8£jýäUu;W+Aà¢ïóÇ;X;{¥ð”ÇÎwÆ}x"
Æš=×N¿nc}&±Éy[µ~œ ¿öµh¨»š«¢³ñ©"Ì‹üEmÊ`;µ
+Lj
+â³ß
+Ì Q=w¾?‰¦6ª~ûá¤àõd‰xW/aéÒÛ‹†Cú\»UÒâàfÒ~…¶‡Í
+¤´HNú2HBÃ8—GÂ+zq(6|£}h`wŽXn‘ÉÖ­\ƒd0ÖŸ9yEúQ§lõ8þ4»G“‘Èh(1›‚#Tšl8ùñ\^ß/Jö\¥H§¼¿Õž‹r2Σ}‰RÕ»Y€|áCžÓ|ƒi
xCªݪÌZ-›Çð0ÜJLÕ—D9dkùåΞ‹üÀu!!‘}U?³9Ü«eŒiÒF̦ì½Äõ–çwNRi¸Ž~ÑqÂzÊ—eh)¶M#±M¤µ.?¶%aÿ5ßóÀ€L]t“ö´ƒÓÈÙ‹CM³S­ê£²lµ^÷³²ÚfÉÔë'7±‹÷bqÛG2®K œ¾’j…Ã×?“	vœ:Û¤~í^~ŒÓ}ü>[6ï¥Ô‘Uïi!~£óú“á{±±?Gywuîj>S–µ¿ƒÆçò8CëD?¯‹{ÇéëˆLŠ"X?¹ÒPÌ­ÔÜìô|/*_6fñfwÀËîí›FºåÚ³Ìõ²¿H2ž¤…tgm&T-·¾wV¢ý”u­ä“˜·zªM·›Q_q3/HëŒøl£šÌµ-@j
+=ÂRŸó>ÍjóðÔv)Ùyÿ¹[G¼Ü5)­…ðwÃä¼Ar«òqsV
+…üЦ^o{<´p–…p¤(„¬Ý¡òž#%
+o–›.%§ª¿ƒàêÕÎ*4Z®÷„&§xás=G‡ü^P䶊ŧ¡¯ÕrȈ=ÂÆé2¾ldÔD4“kêœÐw§3\Wd†@$B}vÓmwÝK&à#ýÁ?¡e6êœÿ¸¥*IÖÔ*Àií¨²Q„É¿åAFÜd@+íy‡íj¡×Ré­¬üž±àV{ñ)„ÓÜy¸KþÍç*ï¬%3Ã6ÄÐqO®Vîz
+Pdž·ÕŽÝKcì" ÂñקÃ߸Ð|÷”:
úaAÞffñ~þµGµ³+ìMk{çg1Û»tîO±¶)0ÞʜڲÊ.ÔZlvp‡k³g¤…æ[FMIÁ‹£÷0ê¹³ÕvœøæhPKò´	ûäx´!vyÚ³×eœï?uúfK¿ŠÈ+>ªX'·[ò&&ÇŒÈSm"~Ê\mŸ$¯GÊ-ˆýJo%ÛÞêdyž†õJ-»Û¼`~DÒ]FB´§Aäû¹xx²Ãò`}fZ%±ÆÈr™6³Á‡å_Êf	 ˆš“óhßõ’ƒ2Äþj˜TÕRwù½@2Bÿƒ]BÊc	mºà÷ò›‹¦†ƒBkSUÚ¾9QçÏ£gÉ*R³äº^D›öñjØYz»El/–ôF{4†Óí·ÖQo°´é¸õ˜r+a]:Ý0A“SŒ>€Gè<5¾Ó\cô>3µ´×šõ®<;Ýgb¯Ø}ð´=uÛMo––ú(þ„!’¼»Ã!M¥'ÐÌ‹bÄ8.°X$ï*žŠ´1]Ð_Õ>-ÿ¥Ó½Uo×}Utš¡)ƒ(¿rñ›u‹äÞ§P:…(¤ãLQÍüϲIz„_Ϫl¾Z
Ø©Î1)™¬¢.TZ
+í&2PƒóuíIŸ[^|uÊàïíŽl«0x¦ŸøpÙ(ÈÅ%mé…ÆÃð½/¯±sqØo]óù>ž×Þ51[o‰þ®ÒLp8¢ˆe.*¦-®0ƒÛßU'~ã+TNŠZŸßR:Wºä‡(`)"Á"¹Ñ£FÑÜ æ~ß…R,vK—󑯈Tì‚äÖ»Òâ\ùU¾)ÿ-tÊK3ãkI\åZ4ýçäk¬°‰m3mÎWí™L![
+ŠÉËQfþNÒúðÄCzòÛgêg_åD6ºq¸I“ª¸ÊFØ2Ëv­Ö¦™˜¤Pé¿g¦Uu䂱~Õ#ÉUz$¼ßó©J{’í/F•­Q7¿§¬3í!ÑqW|¦ùᤜ£*Ëß¡ñP.AËOĽtŒzÚ©ýÍ›¦EEËÂýmòÁZ´\˜£‡¨N“û€žÅ	ί~Þä ½²D`'™(n%‘º®Ô[ƒj&ù9—>ó¨|þÄ´z$ûÔxŒEÁHû8&x‚õÁþ*µ-É‹€„žàטhtÙ,c¤'Åò·8PIÂßC)éW\øõU¿º×…Ù_Åë[÷·¢ž¶Þ°Nj®=.â±÷¨8Jª±Ú	/þž¶É\ù† IþôLÄ맊‰æ$Ÿ±k±ifö~]UýÛÛ6¥ýO±=U›²¡DczŠ/ô? `±+É•¨“HMòsí*‰MÁˆîÓÄ•ÁeØ0•@S‚íòzý—š%jÃÞù¶÷˜%³Íh¯DDk‰Ž^Ï'ÞЦ„­$³SÀñ¡0sj±÷˜>í*•û4†³‘L¤ƒiâ\w,>£u¦8[`ìÇlU¹‘3R²è†‹¯$ézLuÑg®ßÓôßt$0ŽÂèåŒoÖ@rƒGªEVæmý#òÚ#jðB’æ„wÁ¦¤Í:0Ï*%vBçÁ›œóW?3Z¶ðVegMö÷+†šÀ>ܪK—}9¥·…ãi6êåšð îs¼"ЊYÝklÓÄ™ãJmªø‘ò%:ñJ—´¥+ û‰—äMêè{ýN5“(ÀÓFYdÌR:XdøSb´lÒ˜ö~P±Ÿ2ßL£EKÐd,¹ìE5½ÔGT¹ à&X¹2—Gé²’äæÑL‘Κ­\$š†
®62±ÉÌ­´	~¨^™ÉÆßnò{{¥è]¸j´×(ÍŽ(ÔþXH¨‰‚Æù¯Ýá›6ÿñÕû }¯`è…iŠ?t»øÐêøÒñUI¤yŠ¿oÈ\–¨u:ªÞƾÂ`±«~ÀÀ3Ê|È4}ìý2Ž£ª²ÏŸú
+_ƒ
ÃižòÆv==·%!Ãd2KVûBàùü€ÿ'¬àP0°#íþ)ßendstream
 endobj
 1003 0 obj <<
 /Type /Font
@@ -8741,14 +8731,14 @@ endobj
 /FirstChar 36
 /LastChar 121
 /Widths 1946 0 R
-/BaseFont /KVEJPS+NimbusSanL-Bold
+/BaseFont /IWEKKH+NimbusSanL-Bold
 /FontDescriptor 1001 0 R
 >> endobj
 1001 0 obj <<
 /Ascent 722
 /CapHeight 722
 /Descent -217
-/FontName /KVEJPS+NimbusSanL-Bold
+/FontName /IWEKKH+NimbusSanL-Bold
 /ItalicAngle 0
 /StemV 141
 /XHeight 532
@@ -8768,45 +8758,31 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚízUX\[Ö-4Á½p'¸»»WA!T¡Á	àî‚»[p×àîšw÷Ë9ýŸîÛ§û>Ý·ûݪ‡½Ös9çXsµŠŠ\YIÄÜÎ$iudbeò!¶¦Np5¨<“*ÈÂ	ðrš`RQ©Cm@ÿA?b0‰#Ä*nâøÄ«[:L`6 €Èäáãd}ZÙÿ
-´ƒñ”a[»e#f>QâvfN¶ ¨£š“½½
d®
-‚Û9ÁÌ@p>ø©²ÿÌ
-³³wƒA,,´ªZtŒÿBXyyy¦n1qbP?-œA6vödz’AA°§¢ÍÿˆU›H˜Cÿh@kéèhÏÇÂb6=aÌp03äÈB÷T¨Ô\ÌÎö8枉C` ³§¦ÜXþî›5ÔÎêþ05ÿ³%s'{
(ÄÁ	$#þ?ÁOæ¿0#€Èä²@«™%Ë)ÕÝìA’¬À&PsOw{;{ØÄò„€AOLw¸‰3àsyºÿïÄ¿ï0YYæ3G€)Èâéþ¥þƒÀÿØ+˜8 ®= 3È
-þñýçÊàé@Íí 6nÿ
-W4±XDå%uEþÞû?£DEíž$™X¹9Ll<œO“ò¤ÈËÉþwÅzñ—¢Ê&ÿ©ø/I(ØÀûvž|ü«%gþ4›Ú?ǘðïúŠvŽ3€ö_££ä>MÍÓ…õ¿ŽÔ¿ñÿu°þžCÒÉÆæOWhÿaàÉ8@ð‡#6&°ÿ7±…ظý—þ¨úÇôÿtdMl f"P›ÚKB\AæÊG3ËŒË_.›ÿù‚”íà?žd+'ëß8uKˆ™5‡?ÅŸjþ·”P3;sÔ æø4•&0óÐfN0Ø“=ÐÓ½íÁ§A WæÜ´¿¿U¥ÓU¹‰Ó¯aöN.‹G§w˜a6ˆÌHŠ¯­H82Îy⾊+ÿ°*ÕCV@Fˆ$‘ãv±æmfFÃ'øŒ$D¼Ç\% È‡}„N;zì$Ž
-}¾-æÖ#}H^t¡C%$6„¯`GäMz¥»¹å „JBV”U‚¡´5MÇûòÆï@IÚÆK…u²¿Eh嘀%ÛZ;vM#«‹U»wIPÒŒo<5Ý%ŠÃé= …éXydJ¢SÀÍ×2ÔÊvcYؾ)ï·Ïâ”e7°_`ì΄ÔÎXnÖ„Î51X{á¡Ætç‡YbÁ"ðßÄoÔõ•
-PÂ|®Zg{°D4Tí_ý”¯UmQ25¥|AÖ)ëLȳZ¥ Ñb^nônú²ÞB…xM£îR£ùDK$j£sQ5RÓà¹Ð,àêz)ÙTÆËl;bÑBÛ²Ëe£ŽöèU½ã?%TV•t–*[ùêü¡ôgìG*†å^«¶z‡ëñÆ ”¾)ǖлuÈ/Öš ó<Ž–
-G¸»—Úä–Ú±æÂ-/é‹-åìÞ»âÆ,ã³ÿ3™4ǘ(¾€Ú÷ÌÑî‰+\]Èc7déþ¼§ñ
-ýWÉØEºëýhÀX㣄ÂÀf"Ót¯ÐƒpÑo^¯1±¸.öØHˆ=åªåœ÷îߙǹF/;¤Ëfù4£õ?Ò&V›ÚWG	IÞAÜ…tΛ§2GÀ@*7­¢µ\N¤,t(ð£šlED¢­|€ÕmÑG,]hR!¦æâ»™­¬Ô.)ªä^d>lí7Œù,̧—š‘ϸ$ßðÍ1QXžJ¸¼CÇçjP½Tä‘‹¥J]È<$5)‰É¬-²F3Ž­óSøóÛú´ ¾À;Óû4ï/çŠzíZ³ÄFMöD@7IÍŒ“Þ}¬?ªÜÓÕœ\Ç­2k¼¦ž¯#Fß¿†¬®ÿzð¢úrýA[H‘:%áYT΢2%—Ž•#õ;ð,/}Àh;?NTŠ•y^@Ipèþ‡æã*?ׂ§úWQäÏ|z8=Ѳ…~GX¯ÆÆ(‘•‹û9!}ãOnú	3Ÿ¤	Ö>¿ˆþ%VÝ–²¶Í-º“ø}`ã®k\ÇpoR²_ô 	ïƳ	o8à«F+¶WO¡£We)cÕ SK?W¿:öúª_?×…zêBBãõѼhjAŸY-úguœÜ®äÂ`g¤JÌu÷!-AséEŒV
-ô¢=úÒŸ¨8¯é›«p1{h~õ}Ú:cŠœNêC
-¡b!Ñè¨à%ØC½<«â	Y+·þyõ¡”ÿ}¬¯—Ÿ'A¸’|ÑK_
-›—ê«ø¬;Þè%Ïák-oòJlsùV{ϳŒsø«T-#ñõ$æ¦ÒUhŽJâesm¼ŸXÊRüÚð
æxlN¾Ë0´]DŽ•¹l–J»š·Òj1³âÖ[³´ƒÒ×9}gÿÊ“8­ Å{ƒ¸†3“år—ÝÑÇYµ3kð§Â=O{¾}ÑŒßyrwA¶¹ÿf<Üø*NåCkʧ©0‚lÊ°ãX
4ê:tfyökñ4Ûé«ô¥šÏGZ«‡°ìÄý‡ÑN­£<¤‹Õì†íŒgž5EWlÈŒ×P
ä•ßÈëÇ›à±éOŸQÜÏëtXà3H¢¬o€£LApg<ù·È@¬´c]VúÇÒ” îxx}<ñÞ«mj„цš¢öO9ñ&žt=?ÂŽÅ0tû%3ÁQeq8H°ô·I‰ñu‡½Ÿæ‰@ãÃ{«?š^Óg8R";‡P9è[ŠâßÔÈ›
zÈ­¸¨ã^÷>ö˜Xз{]³±Ð‹ª¼ËVÌV7c&-¯§e‡ô›àõ<{©ìw?ùý~´c©Ê«ò²½bdx‡f¸àRo‚1ï‡Ìz+…ÖØG¨Õi¤W¬Hª¥ª"uÃ
-î	…^×Æ}<3ï°÷Ñ;ýeúr¾Æ6¼uˆÄFQÕøê°Š	_¶ÀÇÐKQÇ·¸cq^Г‰Ä¥‚õEq5‡j½oLnÇ:#þŠÝâ°¥K+ÑX$mgãEXRmƒ>ôù’D–N¶¨éÆ{÷Ó#7Ýü¡§k™¼É©Ø6ÒË*‡@=&Å”\Å¢¼åÕÕä“ÑÌìÙpÊ!kQù··§¸Úg#÷4¥E½ì{5ÌP£ª1Z·•ÊA:ᙋë_	¹È!²¢ÜéPœ!deÍ¡Ñü|E4ÔJ·„0l®ÓY!8aÜKåÀ82o®˜¥49¾‰2í.Ù•Ó‚f¾wµÁÁ¹˜³S`úÏ{Aá9”´6Õ»ÛE£r…˜æ;E¤WØvn3©.un/~ ¶=½û[œ¥¢ð|àÝ+;ßR¾zÞ³$CÉt>}_rÏ`‡Ôªýž5â$é"ÞÝ]P«túqóöD™}aG›%D˜À·þ»UÅZÝj›ô&œÎŤPÃwÄ7ñÙ[ðï,cÒ´‚½l$õwÌaBC$(Vœ®¢]Ñ1Q±i•Fa	=|~ã9þr\êeqØŸ]kgªü»¾qçKgqnMªà~µºP™»ÜwŠŒBeÞ§GPñô…¦ä»÷_ãª*H+1,x¼ñLa¼×~X45<D·â+¯Ÿ¨Ö$J;ÀB<ÄÄ<¶3TåT_L|6¦ë—Á¦Õ9U	N¿šû,§ïÙD_Råù-â(¹ŠØhˆØ”T«´º˜å~}'$ŠÝ’*t¦Óè”áÕYÙH’·Ø¥÷»ƒAÎ.•DÜûrÚâÐíXÞ#÷î£DR}eùY{ìKÅxág”â[ï^º©âL‹bàbw©Î'Ä*\•ÕáƆ_îßàø!Ô[7t¿mäxîýqt¹$=+çË$¤v}¸‡c
-Ô!ó®£éÞn¢ò¿ŠM¡[òã¶%¹é!°	ª[ñ‹ÆÚ²1~cX윿Ú´ˆ­È—EÆ¡Õ)™K¦¶æEº Øà Û
KÛJúú¼)^^ºñÑœJ#D‘
-Nf›@‹JìžÔD÷ÊB:]µõ>“UÏ ãÙ™îÖÙñB=4@ŒKlÅÞ6ÂG&½øKzFäX1çl¸·’ÆE·Gs'06‚ð›õ[&–O–·ÚÁ=üœ{€„&™&÷Ú×]Bó¯Fqƒ(›¦Ï0w!rF¹âå‚Ȫ1»,%÷>o¢›d‹Ö$9ޥɼ&ª†Œýà°é$!òƱy/F³tñžŽ~¸Áàò«ýK'ÍÎJ¤@­ÅÏþg„èá×Þ]…µ dOÞaéU¯ŸÎ¬šølò–¾ö˜¿	ó”¹ÇÇPƒ™‹ÀZ¨Œþ¨GÊŸ±ñƒùÏ4˜]òy¿ˆÊÅBuvVÂ×T<ŸuÙ«é@Ö­¬bÀøö¯¶w6}z~Ò†ƒ¾Õ]àÒ
µŠ5êa&è
-ç£C×|h€I_*bMWB¤ÍOÞ$Æ4ŸØÇÛK–¹¹néZ›ÇP®¥µ-Åû¾É‹ÀmýÑ0VŸ©Ú&—ÃØcHGI[Ww÷M w’X{<­õlÏS¥0,ìš¿Æ`·ëÅC%HˆC¸¤êp–™ ˜°„”|@<Õ+ä„s:$¢íµ1Ü-ýÍKkïs|”™6¼W!ß¹XB}Û8ÇõVŒ¼e¿9a`¾ä|ÖÒ{3Úoãø±fíÆMÅ`i0Éâ¨ÆN‘AßÕIdŽxå^e
Q á8lqh—(úÌeeohë«ù/?äÅ(É@D-Ê°¹Z™×yå‚tD®|lG"¼/ö1Š£rÊ–È5·vû\?êïõŽâÜ	‰ìQÆLQ"‹Q6fß^S‡mY‚Úž"G#8QeùtY÷£ùAqT\ÙˆÚŽxc“Ì:2„¥5Z­ï‘Þ¯¶ý.Kª×j£cëá‰(yÀŒ}‰ª0Žõ;HRP^PxGlõ‡ê)ëqЕÉ	´¥a’;Ò¢‹öÊžMBZ~X^ìÌï¾äàá±úArpרˑ¦âFÀ´"nÚ6ë]p¬8fæýáE` ¯&`íEõƒNašp"²O`ûûeÆÞô>½Þâ\®e¥ÐËô¹¦¬¡•[¢‰<ˆ½Ô
-VæZ¡ác€†”'¹ííÒÌŸ‡k@…’SVŽþ<3#êZ¯
}â|çó÷
-72øæÃ)"ŠÖàÈŽÄuD"cWd	,?ñ¹ íŸžu
-
Êæ§=„2ñq¿X‹í41I²õMi~†A§^sy¾]áïý––¾xo7Ï8£™éÀ±É?'©ˆ”óé•5 ÐòÜGÙÖo
-'+¨£À7E6Šý5kI)‹4Ò¥(ib^—ücr8GCúg¶ªç‰˜é)oì…©yË[ï"åF³üò¦dîƒØ#Ê‚ã¼D}“M	uÖ¯ÙsvO¤*hÄ,?Œÿa<”ª6
-*ô
¦ßFòÙ9HÒHØS"‚Á{&í\ÐJ
-rý-Ñ_dg0%0kü$´J¥ó4Ö Åy¿ÒEn@~U±Tþ¬§d®’µÚËAƱÖ®]fmŒR]彺ãÉÛfÕÏ°{;AªÞ	7ˆiŒÈ}4K)R?~YŠL/6‰ïÏ`÷³j‘áǬq4Ÿï°ç¾ÞcP\Y§&¢#'m#×RΩ‡Q­dÍ[_n÷W©ãoÛ*m+Ö	 ÏVv—äà‚¯‘烦U²¢K‹—ÖˆÉÛ‚’èÅÙÍÊÜÛã$›°Åêy&×Óì·Eò«‚L²Â…Óxdvì(y"4|5ãnR·m2M?u¹׃i%Ö‘'´±-¸ÃzqzTª:cg‘§+²£ªPpJo„È|²DÝx¿êQV&FÃwƒòfu`9,ýLÝÚ÷¹åe>ïäì2ùrL½rì:›ZXê3c‘/åZÊd»¾S‹NìOM_6¾©©`D	e}Ž–R0Ðl\›OˆNêqÈ.HÓ8^$%ª†Ì¸ ±üKb<Ú—TL“ä^Ì5Ï6aR}Dqñ€åm .‘q,¾xíèÅ~¯^rµ’Agv^:­'rÍø¥Î-¿z4!Y[FΠI¥ÿ©xÄ\¾*U¹Mò¾¦l¯%¿}S²t¨ùi(Œ[±Úñ¾ÎûËþ’J~´ Õúø`Í[k+º¼y·	bvêO¬;òãUù	ñÃãæ«Ÿ#’p~ r±a®×^ixOog92Ú‘L÷ŸáR>_"èã½Vñ?ó»Õ2nÃ!/
-t"Ÿ8ˆ¥ï]zŽ8…`*‹ý©f´e†¡‡-áÒKˆR.Ķ”¤xæ:Ê1¡’_SÏõ<öªúÔufVÞjÚöË´ÂzqÙ+„…7Ô9	3•"Íâ”r)©£eïR‰Ó˜D§Í2’¡%=}'¶R5ÏïL÷Sº,‹Ä}#/7 nmFY,8gM8k˜1ür!¥€,…¡˜²±mǻ²jºAI±­…Ññ¥G1ùQC“#‰[nʶ€†Uòš}fip­Ïþªu­1gà°Èx$­yi_ —hÇŒDµ6öQ@Ç®…nSô€BÔöˆF‡ãj¾ñ~¢-n´éMҢƮsÁ|Ëy3{þâxfz[k.˜ʇÌJÅ,¯Õ’b–ñT÷vÁÛ±äóžá¨FÔ8èaØ{õí¹o‰“tF•G4m•Ò”î£)ÊS5ãx$N˜6#CŸ÷o
m‘Ç–¼´>x\ù70ŒÉZ}yÅä&®ûŽM“Ä‹ì#7üCJ6„Ьíþ[äPþuS¬ÐÌNì˜Zü9ÅC@æšâ®
-ÛCg‡Kh FýÂPŸúû£&FÙ^;+¡(Ú¢[åºC©Dìôa¦ëKU]~SKÅê¶%ï/O?7r/Å*Éö鱬ÆðsMYº4¨[†Ê‚^®ÔJ¥¢Ý|‰J ˆx!KÚ89‹â¾"x4º‹æÛ³^›Ù„M…º¶áñ²Q5¬S'A᎖±t­[þ“š~›%´OR;³ŽZ×#	/µšÞ5†vð4UÐ_E†IÕ R}Fc‡ÊÌb\}|›úlT櫾;MI¼9¢µD^Æu{õ1¶¿{´1öFy”"}±FúÃLf_ÜÅÅ;FOuæøþ|~5¦Î ÇëÄCš¢Õ„’+ê´Éø–õzÓ&丿ª¬’E牊ô‡Mâ‰t/&%Ï©J5ÛÑ¥Š‡¬GÊÔ:Îøö•¿ÒÖSØ:–’cˆº	—ûq«Å(Lä@Å"^$¿u1§.j¾ÀZ¬Ú=;ˆðá:Ø3ÈäÁÏ/én¼¡,*¢`\ÜäK}[¢pÊHTÁÞˆo`ÝÙýz„N¢&j¸'µ6ó‹|K×c6Qém)'	üÖšëv?.ßüê¼–®XÌ£¯íV]GOŸIª~Ib‚µ³ÉЄH\Ô‡óÉ}vÆù¾%°å1ù{'¾Ëgâ݇ûmœ‡½*œ‰VákÑJ£Ù9ÿ>IžÓZ䀴Òï³€!&A»p¬€Xy¬×ž£ùÅm{!éi„„·}¿·CÚ?/UÌ+¿r"*Ý=AVˆkr˜ˆºz)–þpÙæ YÔškªw¥°8ã	q·An;d„jê®ïé¤ñÄyâ™”‰váˆÒEjüHµjøÖ äzÑw
-ÐöD-.ž!?çìK‡½«ÎYWIaÕR@BJ‰êGBy´øxF^°D5w¯mÁŸ–y ÷|pµƒì{žù÷@¶¬,)9ÅÌÑVŒhj|C?Åã˜Df¡×›ìë¬)¡= SŠ ¯ª¢…¹"$ …\ÓŒçÖéiøœY¨õxïó>ÏPN1…6‚A\¡Ë´Ze77¦ßä"?Âì¦c»ÐY¶,2гøj_î(ØîÇbÿ·d>â^B®1{
ZŬ„†€dš
-u^îsï][øWü]¿›8¡e±É^&UÓR¨³tøÃÇ@XáѧF÷§€Rç ÙiîÌ#=sç&-<~èêÆŽœE×–¶÷.Ö}ìhrr²ë«À±æK<ó$wtÕ°Cn%µ@ݸ*…wN.߆Z¢r™NŽ:úõŒjLâTãPê".!)Où?dð<Ÿ½h·Óô¯=B­›B]	oº×bûJèo×°Æ°­\FØQêX¢öC@iSÑÕåÖ÷¥<7_±­¸ôˆ+²»ÞÌ3å³_Ž¾«–’ñ +¼Ì‚
¸~sOsÔ|ùÆ©-Ê §>8ß`@).æXIw5ßJyc¹RcÔŠª¨Ûý*OÆKVJ°î†<íãÞÐèDïñúa˜ô0ÂAEúÎØØ¿ôc:ª€|/#ÙwÅÊ®Åï>T¸"ä'‡$]jf|0™§ß²`È´eå\ÿ璉<2–Ÿ¾}¥ÔDüÈŒW>vŠ¾:JüÌʶ‘œ£+ˆ/“-×DOåߪ&(wg6Î1þ¸Ò÷þ]o…ˆ†*9iBy8³æ8êÓËØ—åM·óduû]Ã
9Ü8#΋´“Á&¦Î&‚(KF‚Ó·zÄ2ê¹:lÓñ$¼!ÁRÄ_Ù{•ü“l®W!ežE^X’)ý›¹RVÌÍ—^Ñ>ŽDLßäTíÁx)X\|ÏšF;¾Á¶:_wS#s¦›Ü9}µ‘àWú¢÷©¿“]üÔªârŸé†åFݳxUàÍÀ([¦Ü©Þò|ô "rýÛHSrÂÈ&ô^`Õš^zžMÑïŒsÇl
-Š'ù¾r*X¢!Ïñþ¦ü—E——Ïv¬ƒ­Ý¦·P3k,Á´ESpQÆ	<4»
ÕR{_5¤},ÓI;÷Aà·álUM„›¸èã>ÃÂø¸v\Þð]D.½ù'›ñé“¢êwm´¦ºo´Û…žI}³Þ9ñ‚;Z¯ËörMÅ@y=ÀxHéRÊËûrŠt$úyóy±‹	»…ò½­[Lös[ápkï1’שÛåw‰:Èy‡„VqÑ„\uË!ˆ²I™\±NzNÄV^Âê©(µy¿^#á@Pjîvaød~ûlt•ê²2I3±¯ó݉åU‰ZÈè´&~#ºGùŸxTHÍ™lú¾°mo÷&šŒüŒü‚jø=AÉ+´wܺ*ݬ/çöµ0oö/
-–ðO?}ÿJÎxEY{¶ Œàû±º<0„KuúE-+È+õq‰I{økå‰"ÞŠUj#¾~Å©IaÛþE5ùÕºýË»xHͺתèÈNÕ”nóNpðZíÁ+ì–«$ÛMÔžë=£˜l†xžlÜ8Ž×:(n
v#¹ÐWƒt@
-`Lᆫýó”5]ÿQ¸5åð—“/>ßà‰õ¡SÒLrÞð
š‹a¶ÅŽ	jé9Z	ç„ûc휮qövpÕw2™šŽ_
-™]Á·ea~šåè-q#Øt˜Q’0ÚŒ¯ÞáŒ:
Q
-f¯¦Ùü#K#üñàFÄ×`Ä÷ˆÛ7`Ë$‚ñlj9Äé“ÂÖ$(?¹Nùe–à%¨"Kä­^Ë«£¸EŸÇ÷!Ý”âû¿B&ôJä“g]œlùÅÞܸ!&B‹Ê樅ùÞë~ŸÙoE?/猛åXxÃÕò“×Ð*®j­Ø¶eJK}› ÉqAµ­×¹Å$øÙ4F;&ÿ¢ÎÒ³ô3]C9Â>¬w=ÄŸÂËUåæHßÌÜn
t¿”è®þÝâÖn—ü³¦h	?„K¤AØñì¶,á: á®Còí'ðÿòƒùÿþŸ0³™ÀílM`Ö˜î0ÜÑöÇ?Ÿ0ÿ\¡endstream
+xÚízUX\[Ö-4Á½p'hpw×*(¤€*Ü!‚»înÁ]ƒ»kÜÝ/çôºoŸîûtßîw«öZcÌ=æœcÍýíz(*r%U&3[ÐG[¨+3 ±1q„«Cå˜T@掀'Ó“ŠJ
â`
úú‰ƒŒ ¶Pqc‡'^Í o°¬@> 'ëÓÈþW -Œ ƒØغ”@ ˜5úD‰Ûš:Ú€ ªŽvvÖ™
+në3Áùà§Êþ3+@ÌÖÎ1·pЪ«hÒ100þaåå嘸þÅÄApˆ9@ý´pYÛÚý‘éIBÁžŠ6û#V	l,aqø£]­…ƒƒ‹Øô„1ÃÁÌPÝS¡P31[›?à˜x&LŸšreù»oVP[g¨ûÀ`ÔìÏ–ÌíXÔ¡{G´øÿ?A˜ÿÂÌAN ÈÙ@.¦,¤TsµýI²þCÍ<Ýílí`ck8È=]0ÝáÆN €Ìäéþ¿ÿ¾Ãde˜AL& ó§cø—úÿc/o샸tÌ@ +øÇ÷Ÿ+ý§5³…Z»þ+\ÁØ`QÒQ”’aø{ïÿŒµ}’dbåæ0±ñp>MÊ“"/'ûßÿéÅ_>ü‰*Cþ§Nà¿$¥¡`[ï?Úyòñ¯–œ@0øÓlhÿc:À¿ë+Ø:@LAÚŽø45OÖÿ:RÿÆÿ×Áú{ŽŽÖÖºBû;O~Àr€?±6†ýG¸±
ÄÚõ¿Üð÷@MÐ?¦ÿÿ #í`l
1š[ÿÓ&ü#Äd¦q0µøǸüå²ÙŸÏ!HÉùãI0±r²þS³€˜ZAApøÓYüI fK)5µ5ƒ@ͪOSi3û'ðmêƒ=Ùóç=Ýû×y*r™bÎMÛšòû[Vú7]•‹83ýfïäR¿xt|Çf¸ÁŒÔ¡ðÚª€„#ãœ'Ò¡R]dydÄ€H‰0ng+^Ñff4|‚ÏøHRAÄ{ÌU
+|ØGè´£ÇÀNâ¨Ð×	éÛb®=R‡äEÚTBbCøª¶DÞ¤W:›[öŠ¨$dEY%Š[Ót¼/oü¥¬½”ùP'û[Ä–~	X2­µc×42:Xµ{—%ÍøFSÓ]¢8œÞ“’˜•G&$ÚÜ|-C­l7…à›ò~»,Nv}»Æî,@HíŒÅfMè\ƒ•jLw~˜,rÿMüF]_©!Ìçªu¶KD]ÅîÅÑO¹÷šÕæ%SSJd2N„ì1«Uòêm!fÕá†ïÆ /ëÍ•‰×Ô8ê.Õ›O4E¢6:UB 5
žÍ..7’M%¼Ì¶#M´-Û\¶1êh߉PÕ;þSB%•N’ek!_>”þl€ýHåQ·8ÐmÕRëp9Þ”Ô3áØš`— ùÅ‚ÁZdžÇÑTæw÷RüÂR#Ö\¸å%u± œÝ{WܘòÃ`rRç&ƒæ°ÅPýþ‚9Ú=q…«yì†,ÝŸ÷4^¾ÿ*»Hg½
kt”PØLrœîZ`n#úíÌÁë5&×Å놄ØS~¡RÎyïþyœkô²Aªl–O#ZÏ6±ÚÄ®Z8JH’ð>â.¤}Þ<•Y8R¹j­år"e¡“@nª2i‰6r–·EnX$:ФBLÅw3[Y©]Ê’TɽÈ|ØZoóY*˜1N1.5"Ÿq}|Ã7ÇDaq*áüqdŸ«AåRkD6–*u!óÔ¸$&³^´ È
+ýÍ8¶öOáÏoëÓ‚úïLîÓ¼¿œ+è¶kÎ6ÙAÝ$=43Žºoô°Jü¨rOwVsr¶Ê¬ðšz¾Ž~ÿ²ºþëÁ‹êËõ-!蔄Wd=R9‹ò”l:VŽhÔïÀ³¼LôÃaìtþ8QIVæyU&Á¡û«ü\žj_E‘{<óéYàôDËæúløa½ê£D–Îîç„xô?¹é$Ì|’"Xûü"rø—Xu[ÊÚ6·èNâ÷AŒ»®qmƒ½Éý¢¹Hx7žMxÃ_Õ[±½z
+¼*K«™Zú¹úÕ°×Wý¢Øø¹.ÔR¯æESúLkéDÐ?«áäv%.;#•ûc~¨¹i
+šI-b´zŸŒU íÑ—þDÅyMß\…‹ÙCó«ïÓÖSätRR˜…$ùÛˆFy/Áê}äYeOÈZñ¸ÕÏ«¥¬øïc}͹ü<	ÂåŠ^úRX¿T[ÅgÝñF/yo\ky“Wb“Ë·Ú{že”Ã_¥b1‰¯ç(17•®LsT/“ks¸àýÄR–Ê8à׆h0ƒÄcsâð]€¡í"Z°p¬Ì¥`ÓTÚÕ¼V£ˆ™×Þš¥”¾Îé;»WžÄi%(¶ØÄ5œ™,—»ì>N*Yƒ?åïyÚóíʈfüλ»²ɽø7ãáFWqÊZS>M…ùdT„Ǫ;£Qס3˱_‹§ÙL_¥Ÿ€(U}Üh-²CöF;5œ}ó.T²¶/0žyÖ]±!3f\CÕ1WR|#¯o‚Ǧ?}Fq?¯ÓfÏ ‰²¾RŒ2Á	œðäÞ"#±ÒŽuXéKS‚ºãµãõðÄ{¯¶©F
+hŠÚ?åðP‘­||èuæsSQ2¨•PbHRóŠêÐ8ꎜ¹MS^MýÜÝ´Ó›û¶ÈnØU´]IÜl(óš–ªÉô˜ÔpXò,Î%0Œ1µky„Òæ®qú§°Ä	ßÉ`hˆ	Y›½	goû[rð`jϾªN¸tÇ\®»–ü»bIBj¬÷¯Âµ^‘•HÝ{”é·ÄÞê>µê9ÙY•Ó¯BšË‘!õõ詃W/lë²(»óT²œEÄ$
^î·lý"Ÿ»É¼µ÷/µ³ÃÚ…/ò½ŠBº¹Ë)E†…å(xˆ¬%ð©»O:Ä$¸]g¤Õ
¾JÑóæÞö…ÕѨ¶EŠŽH¹ïØϹÈGgÔgΨyîDŒg.uøò¤å…MeÕ.…î8ã ÃCK±(Ö.f5i@«v]Q„ƒ¯Å=@Ûp»CDlë£5e…„°
8óMù½€KöVò¯½hŸ’•±¨cÎÔlÊû%±È™‹•3V°°‚`÷b,ˆu®mvÎA“&­ÝTY–vÛ:ìL$cØÜxcšÊï• £\\ª^æû@Ä›xBÐeøü;ÃDÐéÿ˜	Ž*‹ÃA‚¥¼MJ$ˆ¯;ÌPïý47Ø0HïÞ#XýÑôš>ÃêÙ©8„2È^Ï|Pø¦~Œ@ÎtÐCvÅY
÷º÷±ÇØœŽ¸ÍÈëš…^¤Pù]¶B¶š)3iy=-;¤ßÿ¨çÙK%¿ûÉï÷£K}P^å—]èë$Ã;4׺´ˆy¿8¤×[)4±ÆÜ ²T§‘^±"©*
+Ô
+¸'º]÷ñ@f̼ÀÜGgìdô—éËùêÛðFÔ!k£«Ã*.$|™/mßFàŽùyAO&—2Ö…Õªõ¾1Ù«<Žø+vˆý–­Dce”­µEx`Iµ5úÐçK:™¢¦ïÝOÜtó‡ž.erƧbÛ,H/«äíuåí™RrŠò–WW“OF3³gÃ)‡¬Då"\ßžâjèßÓ”võVسïuÔt2C
«Æh]W*é„g̯%ä"‡È@Šr¤Bqf„•4†Fóó<ÐP+]°¹Ng…8à„q/•ãȼ¹b–Òdù&Ê´ºdVNšùÞÕç6bÎNé?ï…çPÒZWïn›vÊ
+bší‘v\aۺΤ:×}¸½øÚ"¤#"tl~–ŠÂó5‚ws¬@ö|KéêyÏ’4%Óù|ô}É=ƒ-RK¨Ö{Öˆ“¤‹xwwa@­â©Ûæí‰ûÂŽKˆ0oýwËŠµºÕ6©M8³q¡ºïˆoâ³·àßYF¤i{#ØHjî˜/„†HP,9;]D»¢ôc¢bÓ*ÃzøüÆísüe¹ÔÊâ°?»ÔÎTùw}ãΗÊâÜšTÆýjy¡1(`ãóŸ©3;çó~•…jffl¯©È{>ë²SÕ†¬[ZÆ€ñí^m5
+îlúôü4 
}ª9Ã¥jj:ÕÂŒÐåÏG‡®ù<Г¾TÄ.ê…H›Ÿ¼IôhÔ?±·!—,ssÝÒ´6¡Ø_KiYˆ÷)|“Ûú£a¬>S±I"(.‡±ÇŽ’¶®îîCî>`™ïñ´Ö³=gL”Ä0·mþƒÝ®•@ !á¬ÃYf‚bÂRò=ñT®Î鈶×Æp·ô6/­¼Ï•ñQfÚð^…|_äb	õm;à×]1Lð–ùæˆùFóYKïÍh¿µS [ÍÚ«²þÒ`’ùQ­"ƒž‹£ÈñʽÊ¢@ÃqØâÐ.Qô™óÊÞÐÖW³_~È‹Q5)Ãæh¥_ç•ÒI¸tò±‰ð¾ØÇ(ŽÊE([~ ×ØÚísqÓÛ9êŸ٢Œ™4¤D£l̾½¦Û²úµ9EŽ6Bp,¢Êòé²êG;òƒâ¨¸²µðÆ&;Ì™µ¥	íKk4[ß#½_mú]–T¯ÙFÇÖÃÿPò.€;4'.úU~ëwÐGA9Aá±Õ*§¬ÇAWö'Æ4RIîHkˆÎZ+{Ö	iùay±3_¼ø’ƒ‡ÇêÉÁ]£¶ÎGBˆÓ
+¸iÛ¬[tÁA°Âü™©÷‡¾ú€µÕÚ…i‰È>íï—{Óût{‹s¹"”C/Óçš²†Vn¥‰2$ò v’+X™gh
tò‡ê’ž0䶷KW0N¬e"HNY9úóÌŒ¨hA®¼Öô‰óÏß_ÈßHã›
§ˆ(X#;B×ý‰Œ\%°üÄ炶zÖÉ7(™öJÇgÄýb-¶ÕÀ$ÉÖ3¡ùzAÎåùv…s¼÷[Jêâ½QÜ<ãF¦=Ç&ÿœl¤rPΧWV€ntBcÈs%¿)œ¬ Žß™(ö׬%¥,R<†H—¢¤‰y]rÉá
MèŸÙªž'b¦§¼±¦æ-o½‹”ÍòË›’Ö¿¶g(>Žó–õM6!ÔX¿JdÏÙ=‘¬ðÜÙðM‰-¨u7¡F#]ÊHtæ@¢î{éÂ^¥‚ÜY”1(öó¢ÙHaè¸zÜÛ™ ììÎΕ›!ócÅWH™¶²ny ÈxtƲ‹5‘mtEîúÍ´¨	ûØ­bñÔŨA÷
+AEÂiæ·Ü¾^Ápš¡¶²S‹q”)ä—®}ÀÈ™’X¦‘Ñê	½ž¹I|&åYöd§œçI»Á~hÜ%i}ºZùñfǤXÂx,¯ðçÝÀŠÆTÀ;=ÝJi×î^‡É¦Öèz,€h?R9Ìó;@Öÿj—þY) Ƀp9:•Iß­¸ùG«
+gwoÔЇ¼V}ŽCsg@ˆÑÕ†šÒm
^©‰iÙ;4
+ú‹®fºÐ61^Ô˜±õƒøåiBž•1•ƒ—ÛÉŽ¸ïõ+üèªicöe	3+âòÖÛ'˜–ÍN¥ê“7ðÉi˜ì§ï´½~2¤bêó²ãò½õþ•`×Êê¯áÞØC?¹ÕÔÌ=u¤ÛˆU¸…Í"â#øŽ\f£N2ú-aäÀoŒâÕþÙ`S6¼T z¿Êqˆêëà5À¬³DÕÓÙ÷“G‹sRç\êõ/0+A¬£6àÄZ{Xv#¾K,,Wx§[~ð윲‹T\Æ…Ñѱ1n“w 
+wŸè’¡µ¸§¶”¬Õ¾Ï®HÁ=ˆÒT“³šÌ6X’>3¡6º­1•üVŽ mjƒ3/7¯=Íôþ
&!nIy<`e%aŠ{ƒ#0SÌ=²\:×Ñòz¤ØGàU%˜YMçËá.žÜÃ_bÔõ~¬›ÖwŸXöçÏ×{7¨‡¬MÅ6ê£BÊæz‘×´‡ïÝpä÷¹QØì‡G2n2ªDö.×hE#£“	Z½¼Y‘ñ&ÐëE\(ÃES¥cùlgK„ŽT@â91D±èc™×Àj…¤ÐiÞÚDÅëÁ»ÂЯ0Tµµ£bÅ$㪌íéyÑdö¸Ì„ýn&¢›\ ‹Hè^¶ÙôX\JÆÇH?!Ê¢ñ*zTD#Äßǧš¿¦3\UƒX¤~d«mNl›oåbã-ÙÜùUÅRù³ž’¹JÖj/3i‡Z+¸V=˜5¶1Jmt•÷êŽ'o›IT/Ãöí©Z'\?¦=0"÷Ñ4¥HíøeA(2½Ø$B¼?ƒíϪE†³FÑ|¾_DÀžûºAqeˆæŒœüµX\K9§†µkÞúšs»¿JÛViS°N}¶²»$|}Ôˆ<4­œ]Z¼´BdHØüˆ^œÝ¬$À½=N²	[¬žgr9Í~[$·*È$#\8GÖiËŽ’'BÃW3Þá*yÛ&ÝôS‡‹p=˜vPbyB^Ûœ;¬·§G¹ª3vipº";ªÚ§TáF8€Ì'HÔ÷«Žee`h>|7x gZ–ÅÒËÔ©}?‘[^æóN^Ö6“/ÇÄ+Ƕ³©…¥>3ÆùR¶¥L@¦ëû1µèÄþÔôe㛚
+F‘PÖçhé!ÍFµù„複ì‚4ãE¢Q¢ªÈŒêË¿$Æ£}IÅD0I>àÅlPól&ÕFXÞáÅâ‹×Ž^ì÷êÑ!W‹ é·qV`ç¥Óz"!׌_j¯Ñò«E’µeä—QúŸŠGÌå«P•['ïkÈôZðÛ5%K…š†Â¸ª¾àÛ㼿°è/©äGZ­Ö¸µ²¤Ë›w f§þĺ#7^•Ÿ?<Žàa¶Úñ9"	ç*‹æz]à•Öˆ·Ñôv–ý £-ÉTqÿ.åó%‚8Þkeÿ3¿[M£6ò¢@Gò‰ƒXúÞ¥çˆS&2ØŸjF[fzØ.½„ø'eCL`KI
+g.£Êù5õ\Ïc¯ªO]ffå,§m¾¼@+¬—q[¹ ,<¸¡ÎIPŸ©if8§”MIe({—Jœ~À$:­`š‘-éé;±‘¬y~`²ŸâÑjr+Ö-±˜…>IEƒfçl±¢ZV­®ô
ÛûUM½5
ßOÇRòˆœN@Èd£èF_ó³òÌu³Gö–l0êYiQ¶ˆrœÔÑeY$î9Ùq+SÊbÁ9+²ÀYƒŒá—)mdA(Å”µˆm;ÞUÓ
ŠÊˆm-Œ/=ŠÉ?ˆ)CHÙrS¶Ô-“×ìª0Kƒk}öW­jõ‰9‡ý@F#iÍKû½D;¦$*µ±¯ˆ:vÍuš
+ ¢6G4ÚWó÷mq£Mo’¾íü0zt™žà[ΛÙóïÄ3ÕÝZsÆÈP:dVÔ/fyŨV³Œ§²·ÞŽ%ŸðG5¤ÆA«ÀÞ«§hÏ}Kœ¤=ª4¢a3¨˜– xMPn”ªÇ#qp´ų́çxk lƒ<¶ä¥ùÁãÊ¿aLÆòË+&ç0qwl$^dnÜðy(ÙBÓ¶ûo‘#@¹×M±®@S#8±CjQðç}ékŠ»*lí,¡µ=êïΘexí¬„¢h‹®•ëö¥°gЇ™N¬/U
tùM-w*Û¼¿<ý\ɽ~,($ۥDzÁÏ5dèrР®Êº=¸’+•"‹~tó%Ê"â…,iãä,
+û
+àÑè.šoÏx­g6åëÚ†ÇËVDU±N…;ZÆÒ5oùOhú­—Ð>IîÌ:h^$¼Ôlz×ÚÁÓT	@ÿ}&YƒHõEŒ(=‹qåö6õÙ¨ôW=wš’xsDs‰¼:ŒëöÊ-¶¿{´1öFi”"}±FêÃLf_ÜÅÅ;FO5æøþ|y~U¦Î ‡ëÄCš¢Õ„’+ê´Èø–u{Ó&d¹¿*¯’E牊ô‡Mâ‰t/&%Ï©H6ÛÒ¥Š‡¬GJ×:Ìøö•¿ÒÒ•ß:–”eˆº	—ýq«É(LdOÅ"^$·u1§&j¶ÀZ¬
+Ú=;ˆðá:ØÓÏäÁÏ/én¼¡,*¢`\ÜäK}["ÊHTÆÞˆo`ÝÙýz„N¢&j¸'µ2ó‹|K×c6Qén)'	üÖœëv?.ßüê´–®PÌ£§åZ]GOŸIªvIbŒµ³ÉЄH\Ô‡óÉ}vÆé¾°å1ù{'¾ógâ݇ûmœ‡½*œ‰VákÑJÃÙ9ÿ¾<§µÈi¥ßgCL‚¶áX±rX¯=Gó‹Ûìö.BÒÓ	oû~o‡´~8:_ª˜WzåHTº{‚,×d?u-ôR,ýá²ÍþcQk®‰î•üâŒ'ÄݹQ쪡³¾§Æç‰g\&ÚQ„#J©Yð#Õ²á[ƒËEßE(@˵¸x†üœ³/ö®:g]!$…US	](%v¨	åÑÜ팼`‰jî&^Ûœ?-ó@öùàjÙ÷<³ïlY?XRr$Š™£-ÑTù†~ŠÇ/0‰ÌB¯7Ù×ìYSB{@&A^UEs	$DH@
+٦ϭÓ%"Òð9ÓPëñÞç}ž¡œb
+-ý¸Bçhµ0ÊnnL¿ñE~„éMÇv¡“LYd< gñÕ¾ìQ±íÅ EþoÉ|Ľ„\cvê´
+Y	
É4j"¼ÒÜçÞ»6ð¯ø»(~7qBËb“½L*&=¤ö4P'©ð·@Xáѧ†÷§€R§ ÙiîÌ#k]3§&M<~èêÆŽ¬y×–=¶÷.Ö}ìh"rr²Ë«À±æ<³$wt•°CnEÕ@¸*ùwN.߆Z r™LŽ:øõŒªOâTãPêŽ".!ÉMù?dð<Ÿ½h·Õð¯=B­›B]	oº×dûJèoÛ°Æ°­TFØQêP¢úC@qSÁÅùÖ÷¥7_±¸Ôˆ²»ÞÌ3å³_Ž¾«š’ñ #¼Ì‚
¸~sOsÔ|ùƱ-J?§>8_@1.æXIg5ßRic¹RcÔŠª¨Ûý*GÆKVJ°îŠ<íãÞÐèHïñúa˜ô0ÂAYêÎÈÈ¿Ô-U@®—‘ì»Be×âwª\ò“C’.US>˜ôÓ»,Ø "mY)×ÿ»	%´Å§o_)5ݘñÊÇNÑ÷`AG‰Ÿ9PÙ6R‚stñ¥³e›è©ü[Ueï¬ÐÆ9ÆWúÞ¿ë­QW!'M(gÖG}ú1ö%dyÓõz¹þm¤)9adz/°jE/5Ϧ`†€wƹc:…@Å“|_9,ÑçpSþ˼ËËg;VˆÁÆvÓ[¨™5–`Ú¢!¸(횈݆jª¾¯Òº@–î¤û ðÛ`¶ª&ÂU\ôqŸaá|\+.oø."—Þlˆ“Íèô‹qQõ»6Z7ZíBÏ‚$¿Y휅xÁ¬„×ez¹¦b ¼`<¤tI¥å}Y:½¼ù¼ØÅ„ÝB¹ÞVõ-¦»ƒ¹-†p¸•÷IŠËÔíò»Dmä¼CB˸hB®ºåD™¤L.ŠXG]GbK/aµT”Ú¼_¯‘p (5w»0|2¿}¶ºÊ5i¤™Ø×ùîIJŒ*D-dtš?Ý£üO<*$çŒ7}_Ø´·{MF~F~Aµüž è‚Ú;nU•nÚ—sûZ˜7ûÎKø§Ÿ‚%g¼À¢Œ[Fð}‰X]Â¥2ý¢–ä•z‹8ŽÄ¤5üµòDoÅ2µ_¯âÔ¤°mÿ¢šüj	Ýîå]¼@¤FÝÎktdÇjJ×yÇ8x­öàvËÕ’í&jÏõžÇQL6¬w=ÄŸÂËUdçHßÌÜn
t¿”è®þÝüÖv—ü³)¦h	?„K¤AØñì¶,á: á®ããÛ
Nàÿåóÿü?!`j
2†9ØÚì0Ýa ¸ƒ-ì>aþ/o¶endstream
 endobj
 1000 0 obj <<
 /Type /Font
@@ -8815,14 +8791,14 @@ endobj
 /FirstChar 2
 /LastChar 151
 /Widths 1947 0 R
-/BaseFont /BLFZAM+NimbusSanL-Regu
+/BaseFont /NHZOHJ+NimbusSanL-Regu
 /FontDescriptor 998 0 R
 >> endobj
 998 0 obj <<
 /Ascent 712
 /CapHeight 712
 /Descent -213
-/FontName /BLFZAM+NimbusSanL-Regu
+/FontName /NHZOHJ+NimbusSanL-Regu
 /ItalicAngle 0
 /StemV 85
 /XHeight 523
@@ -8838,42 +8814,37 @@ endobj
 /Length1 1624
 /Length2 8579
 /Length3 532
-/Length 9445      
-/Filter /FlateDecode
->>
-stream
-xÚíwePœë–.îîNCpwOpw‚o Fº¡iÜÝ	,¸$¸C‚ÜÝ!h€@p’Cö¾gÎÔ¹ókæüºu»ª»¾w=k=KßõU33è¼ä–µ…Zƒ” 87?Ÿ@ìbíá®	…hpËAmµ­Á€'@‹™YÂÁPˆ’l
- €€€_\\‹ uõíà6=#vNN®Jþ¨¬}þ® Àÿqc¤	µýÏÃ99¨7À[„À- *∉òü7ÿ¢áÿçY‡½¦|<||ü€§ß|ÿy2ÿEˆ
ÔöÏ̼„!¶OcöŸ‚?°öÔÝ¿nþSÒÿ8ÿ5ð 7Èkij#¯#ÏU0íéæGˆp-mÔ/)
-®veFoŠWZý®ài—xhõ™ûæz¿£Æ±;ØMæÌÚ•ú^HðŒýsáK»(çn(¯E)nÖ‘Q¼ßé¬ÆŠ‰ŸáîÖ¨®žÅûßh´ãí‚0ŒÓöàgžEÁ$L×®x6
¯I;šˆêŠ¿±¤Ü\³ö
}èïúúy‡š3ï5&³¤'
-.K\°[µ´‰A¥_ÓÅ¡Bl³TÙqÆ?ÜÀOqDú!Ý‚+©r:çšôäØMbôfÃÚlƒ*Ô—L›@“à9ù¨è#àÃÎΙËŠ"¹LBÜZcùi{P:Ø—W¨#pöó«ŠM¥Ðu—ÐwÄ¿ïšè€œANŽ3H
½/zßÈ“R‰ô:à/ÿÆù#·þZDG¯²`Ñ!Èö˜\aÌè_wÁ8Cݯ’ûC%×ð‡	²œà½¤VÙûôû‰Ð Ç7ÆEpƒZ‘ÀÇ9ÇZr*÷m7êÃûØŸoë‘Ûj_#Ì°_cvç°“Sÿæ$§­c2½~+/í‘ÉjŸ*_5.‘fĘDT¬t\¢–¤ohï¢ÅÛ7²N ñð~EjEÒ²²O*g§i–¨ 5«Q±1AS§Úsn¡fŸû½IT´©­j5¬ê¥~%FGä[šýD7Ìt4Ɔa°n¬k»,äûÞ&Ê7É	åóåJ† Ûïèßã2	W8?(s2o¤±×ɪmY™±òzhbi‰3/6ÞÖþ©FÓ$êøc37ì÷Ý)é*?£‚h¶¦¯mð[¥÷x¤WQòî|‡¡²™D®ÌoYìR	ãÛ÷½Úm‰|å;¾D”ÃÐ2W‹i¢Í?5‘ê
ŽôÅÕ½®èÛJ¢ì2ש(׌/l;Æ\¤tÛm&h&²>à.†º
ÞâùˆÝ$$ÙeäT²fˆ·Ö<_-\ÒÙ<Ó"™J.ù9ÙÃANŸæG·üÙ"A‹ä< ªšÎu“Â
ÁZ¡÷‰Dl׳zYÕßýhÖ&•ª³ëiÔè^"÷ݾv¨å%¡›¿„ŒΞÐnÚ{uÊTÃ[ŠJp¥Ytó04ÆõáÛ…¢Ó¡d¨pÏó‚„”àåŸB¿Þ€wF'˜N¬õD¿ÍY–åQdÿ)í%ig²qFlªjæ'eÑ<¼²ò+êŒBÅ=ø6YææVw´SôŸ/’Åçm3¨94¦µƒ‰Œ?6(¯öçÙod!¬4‡¿‘1WÃaUcÿÎÛMÃœ,Ù§	n¬åÝk[nø½SG¿.\èxʉ£3ÜäGkh+Q×#KVI`÷»p0-¢Så´’rX=ÁBÝàËB¥Ô¡ïöå
-8G…cDùcì‹¡ŸˆpÏw¬W°{÷¾qSv9Íš©@ýª…?ÏTé‰8aUÞX"ß ­Ù1IG N?öÉ; a½Þ6Ä“¬Í2þ*>Q'Ñ
-ùjêÆ×'ùæ¡y©Ãm¢•N{µÀÕ’¯+ÙÄꦛõóK¼âIR'¹èºGcSCê™ïßzÚÓ>Ñ€Ò;,búñÖú)®Ö‡ÒŸG Œ-Ò<ÌõOE,ÇH£òfd&¨³	:Šó¿0s[jöµMáÄk‘É ‡+ûv­el3¼)IZýU+Nšßø^’©‚´a¡üs…&2¡$ïâ±ÞµmC×/VÚ‡gÓUXRúTé¯.Mßjaé¼ËÐ;ºÔh}éP`ên—Ì(8j"¢ºiµΘâ î%Òàt#—½UÍDn¾
›È¿¨pPÎÜÖVý®­ëÉÝ1·´z(žZZÚýœÐúï¿ÏŸ`ØÉÈ\ÆS“ÄÊÄ9áæìðòðKîTÿ˜Šð.ŒnÔ1Û@žòÎìê­Á˜™?óPbJFªlY„¿•€œ‹±Ó;¸8©¯Ë'ÞšŽ]	NóS·Œ4ÍD›+՟¿Àçì.ù0yÕ-ƒhzºì“+§OÛ²˜
õ"ÕH)u}’1k¦ó—5ž'¿G¸ƒÅ|Ɔ0¿Íûóaì_½‹s¸øh)Ôæ2i"õƒY…±ÑØ´ÓI_óèG·K;Ól*Û”!¹¦iöÄUü0	Û@K(=ßkX‹²JåG»ÊÂ^{Ðv'oѶÏ7Þþ3uzî¸(Øt-¤AeU½}iÃ8X0i8Ú:œ&a#’³|[|V©äžë`Yý¡Ñ±¦0l?O²Å©{â*u¯
´Röæš[;#à‘,vù ÐÍi”-kN7F
1.³„U$· XxRÒ[³õ¤áxá-£|uã‘oøaiþÖ/\<ê5Ĥš™-ëÕ9šTå–ˆd©|ò
îôÈûgDÑ.óÒ7kÍb‚]ŽÒoU_çTsúm14ê$q/YyšõäK„ð©¥t¢GÔ
hBØz­¦¢Ø\”ÁdŽÃʽ@í@°4JV¡7e:E\Ò6|¡M¿õó+úëc‚Z|ªìSˆä¨Àã¢yÛ´#fú{¤“œ©ÖZUNɃáIä{û~$jxu{á®.ì7YiF(ɹMVHôuço*€ä‰HÄS‚|•¤AR}Œ˜ÐKëö–M¬¬ó3>– ýÐY†½á2N¡é¯"¿Œn«ÛxàjxÙ}»¤L<a±!^½Ì¬Ú²`ô·²5x]4b›ÎTìá‰tª_ë¤oXê¼X¶3Ù%£[3ïí}¿÷KWä¾Â·÷ð“题EG®þW}à	¡ÒK„¹]~ÊX(­aŠl…þHáõzí#G¦ëSä33ÐñÞYKÏSÒ(WQxäôÝPV6‹>ýs¾·:µ’kïìÁ$ùÔñƒEÛ³5,b&]΃ˆ?\……2κ¬ú&]U:.T|>„5„[Q²ùõ”„//žcŸ>?Î8¥\†Rì㸿ŠmÀÒ[n»A6‹ÈtÙ};ƒØ*Qn‹”i¸º¾w¦4Ä,-©ðÂÒº6©=ýW…•qƒ‹Ç'L˜Çõj÷õé+CÎt?™­Yö@Æ$Lgå"¨æU†NöááY™~ÎûÜË猪èæF‹?©h0mÖ‡˜q¬„Ä•»—Ú¯¯y—/¦¾ ÿ€$ -J’?wÇÁ¨qŒyöù……»¸ßÂiý#ý«:¹öRÜNìC‘ÿ]= QÂ@âi?cU‘ÈšêÑE
-Zð•ÙòëŽ(¿uûƒ‘›
-Ž**E×…þòõÏ
->‹¥Æ“Œ½ü2ñ1É:”#:N@ØÀÕë—b6TæZçÈ&Ý’jŠNë½O'y˜s¯Æå–Å¥\Áf¡èñP¼ƒ
øÓ‹Ž
-NhŠÉâ´p¯Õ¾ì|Ïy1ꈀ,%ïÒç:ª«±—ÑÁÜ¡f¹ÝK©ö#)§„•17³Ì\þÉë&…°ü/=:ItÀ¬c*î“,¶ÏµBìóø•¶k¶M2rcþÐ~ݶ&óŽŒÕNLF‰dÂ5LKó#óì5|h§ÙxOÓp—¢øÉ9¦¶PQv
-›yJzìÌQÀêéÒû_>™ƒ2¶Jâ*?¶¾
-?×Ô~Å)§p°½ž.Êiük‹óDñØß:[p1\#ÓêEãDÔV<DE¯=ÉÇLêC[\üY?â„$4 G‚¤hÇÆp¦Køš¢¾$C÷vªlF-MNRÿóÇwévÃoØä¬×Ä•šéÆý/îËàPj:°ý½[ßêÉÅÄ@´nþ\T"/Ÿ÷íÚØã–ÅV~=¶AŠR‚±z©RÂèKRË5ÑØýûÊkutž™p{‰ÐgåÙÖÜ|-;»õ_àS/1”~d•¤ôç’æ”xÍ7¼õ,UѳžR×4Ζ±®—kWI¹þõkÿšýˆ×/4>xŒ ¥I¬)¯˜äU÷w’6¬\Œo†2•vrÆEÙ7kjïw×hkc린%*óR¯çê(ÄñJÕ‰îæí¡ñyØ°–½ïÞ³i¤.†ÇæÅH™'?T´T.äÑ>m§ÇÉ0èb &ªsÍ‹5õSmŸªÑ&9Z½‚ú°ÐIqWX÷¼ÆOV¸Bw!U(HË;I#‘ÃË-4~>g¹]fw0þ¾Úøð®9¡ºÈ¬wr#›JGù·sî—l—€éÚ
7~.3„ØYK?µÈø£WŲ¹"ZºžH­c»â³5y•ò3#œ~ô]—ó(1—zº6ÌhQv®MTz¶ñ-Ë[7WU›+*µÓã†hüËj«…h^1ÑT²†Å(&‹01ï !z`K{€˜y/TWœ6y#ActöŽ¬û¥ö³÷ÓúœÁ®˜¨2V¨½^ÖNë+Ùg+ÁFÂtÔÙñZÏ6R»†ôkÍ0Q4Ûܘ˷‡ýŽÐ{t×2f_ßyìÅD|maÂY‚ª $½£CÓôgzå8zî
`Z®ˆš[öµdU´4¨F§0RË"¹úf
-ÖF½_hÝü¾e-=§c~	:‘sT¢IƒÐ|–Ö·oÂÄœ3Ñœ"x!‹‘pÉÝk6FŠª`OÜ¡[°ªfîªAe“ŒAï‹"Zv5ÛÂ$ÚaœœæÇ´3ÛFtü7¼–‚c†ž£Â(4,c›÷Ç,ó
- úªôÁšRú²Uc9óõßwŸÀB掾²4=D§Kú6Y\$•¦I¢&9M«,c4Òæû£H)¸Þû~ÑÑ/ÑÆ–â}r­=ÇÑ·ÖnYÉn&ÐÛ?9Ö8Íùå§}"¿Ë¬EÒMO,¦ß·@Õ|E¥Omhx™RDÁ¥]Ös˜Ü g|_¬ÑTºç{0NñxÍIÂQä-àÝß}X5´Èñºe)AÚÏgsÉÉÉ{/L£Xœ8Ïf¨T[7eóñ,®xiHÁQÏI¾eÒ²Y5Ë&tÉúµ'ôî~/µŒÕ{^lÐ/+Z½nнH¡h˜g;‡)ûÊ5;ëyTé¾üÒ1`–ÞÝ1€YR9C
-¹‘hþ]ð‰”OаÀóç(óÏ.6=5¥·‚eÕfÝÆ]ý…ß9_1úIÉla?p®Üÿðô·îŒ];—a9¡EËï¤èÇù˜f}ÀfsÝÈ©ÎÑ©HÕªv‰/Ø/b÷Õ”£ô*‘j9•ć֕ýkEp&Dž+IE°"Æ(ff5›ƒç&mà@²Y˜šçç¼E÷À?¥ŽëxÄy¥>&3Û˜nÔ|œã±nÛý64äòŽ¦ ác›ÄHtWlÁÝ&Ì€CüEe•S_ˆzi&æHvß%;M`°dq¢R‰Ô¡<Ô?–Em&'⸋ÿ*[DQpÞ߶ÒÐnErÝ?Æ=¤ó˜~cÜüp,sÙ@ìééç—bľ_(ÆÍm”6ç#¬ûæß‹€#üìÖƒ[q2¦‚<­®?¤\Jyq'ö9>ÄBÎTjÛ;©íimˆúHëÇbå‚¢Ó'¯¬ýî’¬ZD9Ò~Æ®qWŠA8±Vå§78ˆa×8S÷ôÏloq²«Žíƒ¾ï=þ;iO”Ñ}ú`w~”©ç‘Qx†®Z°·4ìÍÊ`¢Øyy²r[‰õ#eyð'Àó(¼š¿ºó¢Ï¯ÓŠËÊ–áµVÇ',S¬Zol]{Fk-¬›ÛDº®÷ü
-`šÞD-1¼8¯?ö+:Ÿ“¯‹	çج0§*.Vc×NèÙ4–f2»'yæó¬ÌͳŒâïÌÉ¿çí”T
-õ&œ“ÌJçhçSE*­×©(péSæ¥/¢wÌXaIØyó}—iÔú!ZÆ“KF:à«ŽöQrƒr´
y„‘ª¹;nÁ­~ª4<#Xá,Å„‘”nŠ¹Ãˆ°-Wþ³çÕdTÈ7ß…ÝNÔõ&7O+1&”YP[²U¡5„ñšðnžGòp‹²›íÆŸg .÷öÕy]ƒ@E<#ŠÁot\;iT	iG¿SžÉ‘P`ña¯ü`H…ئ¡Å÷äžïÑ¢–Ýc»™>‹†þʾøà’“õ§(
 ‡ÒÔå]Ñ~‘‘ªÚQûÁï’-¹|Z¾–½îËDí7ýÞ$õ_—ô&KÇ5²·šiYô6×u§ˆW¨³ßrÑßß¹L(r$“þ°³WøJ\«ƒ¾}6ËÔòö7ðfpô·@À2àœˆ"­ês…£iåл‰7_™æn*·¤yÒ¢ðV?Gý
-/ýð­@DnJ‹€6S5¡ŒË¡‹=\0ˆ§œxÒ‹À]aœmY7TÐØã0ŽÔ&ù
(õ¤&©7ƒcÑ)KÕGqÐ{ÅòÃ$¬2„½çÃkž^mŸ„¾*ÛÉ|=`(ß-P3CUÙ‰¾kš‘_àÝúvŒwþÄfËtM¡™º½Ê܃ÜM´ìj%âðn†VR Šîˆª†©ðÙJw‰Èv†àI”µ™{ò¢9T‰0öÊʘävÇ䪓F󋕯\È­“<,€yðžÉÂì„ËoZêášáeðέû²¹'ýVƒ˜2÷]ÙáŒÔ]“‹òîˆl¾¾~Åâ͈äPÂ6ã|ƒ[KªÝîg,ðË–ªü\,ò‰úU*­úŬ“s’²cs!Çt ß)†s'¢èTšƒ	+®ìÉhó¯&5ëewM{?ž®£¸Ú”¸‘ÅãNðI‡>çŠ|=kŒ¬Zܹ¹¯1ò^ðs/
ZÄU™ÔÊšfý×ÓìŒøqª£Á‰¯ðáF„F¶’üLúDi€ˆ¬SÍ@Põà8™zŒäô6žéP4Á¥d¦]æP€úŠÎ´`ZH¹O\Ÿ4ÙqÌ%ÞLòÀÅ4}{Åd	:Rå«Úš!Òè.½Xf†‹"B§c¼2Œ†‡ÈÂîå+F£î	ç`“fbŒ§é¿GJ Â+ÙYeá–[PyÖ´O༱B­˜[ù´ZJ¨¾´®ÛØ0tÀ Gkd™eÆìɾ>5mý»Öñ(S¿fÆV·Rˆ;ÛN>NšßXG$Ês2.ýág’7Mš¶íεD·q¢/‹«‘Ý­UVÅÃö'ßô­hùŽÔ”d"pµMä8´¹ða]G“d°ú÷C.GaÌ3ÃŒþB¶ø:d‡±?ŸGtù¹PkªˆÇ¼¨ŠaF)ƒéà›Àógs±/Àý´¼‡
-ØÆïk©1Äïi0]ëQy,ö*`uy³ÝÕ
„¨þ¶a¯()è©_šcT±R>ðNˆþVòÉÓÄ^eÑÇ«Ï4xi|jö¤8jP" Ùræ~‚ä¨×hSÜ«Âu3«Ë·s}·µ¹|MÌÐK ïÛô3Äk@0ýNnŒÍ'€ >ŸOR}»>©P_ºÅÑØîôæØï+àq&|¹\K¯3¬¼§Y0,͉÷B@>9ýX¶°üÍ/0Å,…`ÐHÓ´í[ÿçpûÖuäñSܼ˜=»„›Ä+Ñ.º1L’ú¾POBÉ=.jÊ.Ì«“¼òÅ ×ü›:.Yí¯ñrøàxË$®™»îˆ]~ÍB½¾ˆW¥14
@žhOÎU)Y¶Æännƒ©À-~’×±ª1Þî}&H¶ïÊ×$A&ηëoâÑFÊ(¢ùèsÁ¦’µŽC¿À‚×5²OÙÊf5‰yvÞhþ%ÊâŽîžáí¾(3·õ5¬íuÏoÅb‰Nc©÷ä†Å^}.¯\Š¦ór£Å†|vRâuV¢¢õ¨ï´90
¥§>¨’ÞvEÊ.#Í2.P™ò ÏmÅí…@†"3?û¾î¶GבV´šõøî_w+¾t·ü<ë\løqdÏD5—´Ë-¹Qì:â-4Hñ¹šÙå-Òf#:'Ùû&üïßúîîÑÑßÕÒ@Šˆ¦µbïGí‘-O8Õ~üýI‰`nǪŽ‘{óc—žvâÛJ¹Æ¤»é(,6âÚ·ÁÚˆÓC0Ä>T6
ªÀKÑ@Ո泟°J›mVTb
C$Šý•–‰ÛïJžoju"ìÛzIgß'é†ËõxI}M¤ë}³q…ï|àóý(?ålÀ¿nR[*"¸«D]2Ñ„kþaÕ\Wµåð¡’"Gåwíè¥â×ÌÑÕÐ8§yŒÒ>“M4™­W¼f¦ëSŠ²¤QÆÅ
-?¥ˆÞIÆÞ×;S£ÚhH}~ ²y^Ç"•oÞü1bºÒÁ¦¢,#2éÊÏÿù¦-fRWí«±âQA–|³Ôáïþ
-‰cK‘}âzåÔŸûdŠJ˜Mâ¿Øcy±®ìU·Á)ÅÚ‰˜z±_K0ÑZ‡ÅŒ`wÒe42 ͼvX9ÌtéÝÕ뛯)Qö¯WK±Öv
ÁßÿQ@WÚ&²d‹Y„^×[¹ =ãyCmÅ&¯k±HRÐfeU7ú°¯ué¢Ñ§ës*œáµ‰"»¨õ£ãÜdù‚–¤öº~¾§öUèIskÔa°œ‘|±ð§Ž¶ÑãéN”Ô·ÖÐÞ²ÊS§¢7HƸ
-l§™ÀUë’‚™Š¿µè—	½ó"›YFGÏlëE|…"ÿX7)Aäìq„m_:QGnQ•›MÃ캿8»˜MA19Íw¦XV¦Ôkiê8U=œDSŒ¤ñ0)°·ïöL $ÍûÓy_ȘÊþëuí¸Ù‚ª•[1êûfbKÑv¥ŸöÔ¦<2\†!· pý%ä¶tùÕ4ÔŸË’4×zß2íâ57ùº‡ƒ9ï‡èÜCzÏhȬº<É+ð«î»Ë%ž]<Î}z˲§¯q¡|W—H;fÌõõ’ö]ò–ÝÞàÉÂæy6?-PRJ)ñlÅV舶¬Ûkì—‘Gö³=Q-ã zƒìLÜr½¥¿>!ëØ,J±)OPµ?é˜Ï$Йp$t²S‰ïVâo,7ÇýÜþ‰ƒ«D*R¦oÑô)`L¶dšÁLÉí'2vTRBe§'®•Ÿ:¹ÎñK«g+S
ó«€"©ÒódmúþìÔˆŠ·/‹Š]γeuŠšˆ¢ëO†Xz:ð
-1¾icçô.P&Ma´âiÏ3ìŠqJ¤ý@ïq¤8LÖä¾Êðœ·ÄrÉÓ±ü`Î3ô	y*Ë1\—!ÆQ¦_Iuh+ë¾-”Pˆlª¯q›í>ãßøvá4Ó'h¯]©NX£j,­ÚvN0& ¿ž¢0}üÀ—[3Ï?x×”«þÌ+kÖ™¤Î‹ì…{îCZ¯ó·ˆCÙÁâàc£:)‚×ca˜;Ç«ˆ	=4[Q”…ÅÀÒâNcíÃÙi휵ü`¤„­„ôiÒ*]ñtÎ,_$/¶nlDZ9B™‘ÎWoÕ­Ù=íR¶gÂýÑF’àá£-?
-li]³¸Ùø_27£Ÿ+×¾0ùwâì¦!øH<3„Ff'¡Ón
-½Ë¨’ؾn±õ`WÆaeÊ Åó•ÇÁ<"bãx+6Îã;‰‘ýÕ{xï+™Ï^C´¹y=ÓJt¨q—ɶêÖÛîþ$`ð÷×@@/×2WW’/ÜK$ðs†-àôjý¢òßœYŽr,s1ͨcüåˆö†×دµç'Æ-¬˜L»n
-Aï,´u€$_­õ掭Á!ˆ |jÒOt	<[cÄUî4O/ƒm?Qjù—·W¥óÕãBö6Ma‰™õdtC÷7¶jVñk•ü´Æ»²dlkZ_é0ϲèk™
ö9ç»ÛÁd¨$U™}Zºñ‘¸ò¯CÎJíÞ*HÞ?äŠ0<4vò6+?Kñ¹nß	ùy³°ä¶¼*PCæzu¡°ÆUhiñ½ã¹4ñë{ˆ
vŸàÏ~p¼¶i–r/Lµ-Õ°ýyDÊc›%·}z·ˆRðª5
-ïås^ÞÒ¹éÝO¾ŸàR«ÉëVôºd±‰_uà5|œœ÷sÔgšûM’“[ÂØu,B´‡þ n½-Qo'£þ!” ±y„u¼Ì¤{u̪õV±æ‘ùpîàÕÝrŽK‰RÂr¼uÖ²øÒhèk=~*¨Ê7ĸú[^N:Ó€õ³RiØøx²CDÑÈ{»&A¯IÁ1HX=-Œ¹™A’/­ë¦úD–½~\¹3*ï^(¬è:äç@%`”{,	úÍ”@	>_±'®)}élµ8ÿfrbø|Ù»—!>oÑy܃¹b1šF«êbÎÿ·ÚGoXg[t‹ÍŠ¸™ÞM²ñ	he·Õi‚Þ“Õsü—1o$¥·Û,û¶ÞÈ‹¢…Ì„¬dQ+÷	~VB4ï1ë>~j#²5Ôg(¸ËÔŒ]eEÙ@îTlÀµ%ÖBŽÉ°ò,•WõÑ‹–dyfI·z¹ú0#\	ùwNQ]Ìײýž"ò;ìcКÙ2Uĵ4-	,A›“à§sÅ/$@¬rút
-G+q|~R–Q¡â÷<ˈö‘ ²!Ï%ÊȉëÙ}»CÈ©}ŸzT szÈ‹$:î>iÄ+Z¶>–sk÷±N<Ö)SÅ“¸¶Å¾­]œUf‘i×8¼’“¸ž9qÝ[¡bƈf¼¯Åرٲ­üM˜W:o³&>`M÷·^Ä··Ÿ£luÆØG,V®«Õ«ô“r0}¦mR"ݱöÑÐëhÝö…²ŸsÛK.Ó¯3ÄÛ»[ŤÊØ‹¾'„Òì‹ã|1Äu äû_~°þ?Áÿ6Î  uÂœ°þ_–*4endstream
+/Length 9444      
+/Filter /FlateDecode
+>>
+stream
+xÚíwePœë–.îîNCpwOpw‚o Fº¡iÜÝ	,¸$¸C‚ÜÝ!ÁBpOÙûž9Sçί™óëÖíªîúÞõ¬õ,}×WÍÌ ó’[Öj
R‚BàÜü<|-°‹µ‡»&¢Á-u¶Õ¶vža,ffyC!
+@8H`²(€l~qqq,f€<ÔÕ¶w€ØôŒØ99¹þ)ù£°öùòd鶇XžO¾ŸÈ\aà¿ÂðpCìÿ²ÂlAîîO4OܪóÏ<ÿ%{ ««³Ï_Öп´þ30ÜälǃÅ/ðäÓþäÛÁâý3,ª;(€Ÿïo¹­‡ë?0O쯱ý™ö§ €¶Pˆ³Àd‡Å«…?¹°ýϺÌóïkò¿¡Åÿ–ÿ[Úû¿kî¿öè¿\âÿí}þWj%gg- ËÓü½dO[
+ÐüÙ3€?‹ÆÍôÙ]ÀÎ>ÿÕ¿*þŽôÙ¿bªpàS9d!öO-áæàáû[vW{ƒluÀp€Ðù©ZÉ
 ¶ ˜3zêê_}2âãûLßlãùS~á¿!Äö_cjÔ_‘ójÈËɾäüïvë_š:O3×÷qþ#M¨íþðÈÉA½~Ü"ünQ1€˜@L”?à¿ñø
ÿ?Ïš@8ì
0åãáãã<ýþãûÏ“ù¿Ð(Bl ¶fæ%±}³ÿüm<`°§îþuóŸ’þÇù¯¼A6XKóPÉpÇÌì,xyþÀ¨‚iO7?ò@„ki£~IQp
´+(3zS¼ÒêwmOÓ¸ÄC«ÏÜw×ûoj;ƒÝdά]é ãBš€g쟋×XÚE9wBy-Jq³âýNf56PLDøw¶Fuõ,ÞÿF£o„aœÜ°?ó,
+&aºvÅ´ÉhxMÚAЄ@TWüý%uÿæšµoèË@×êçoÔœy¯1™%=QpYâ‚Ýò¨¥M*ýb˜^(b›¥ÊŽ3®øáÆxŠ#Ò¯é\N•Ó9פ'Çn£¿ 0ÖfëT¡¾D`Ú$šÏùËGEÏx¾};•a¹SQ$—Iˆ[k,?ÉcJ[`à²ã
+uÎ~~U±© îúŽø÷]3ÈÉq©¡÷EïyR*‘^ü…âßx8—aáÖ_‹èèU,:Ù“ë#Œ½ñë.¸g¨ûUrÏTr
ÏLåï%µÊÞ§ßO„=¾1.¨€ÔŠ>Î9~«%§Rpßv£>¸ýù¶¹­¶ð0²Àû5fw;9õoNrÚ:&Ó+à÷òÒÙ™¬ö©òeQãà2iFŒIDÅAÇ%j™ñHú†ö.Zܸ=#ëOïW¡V$-+{¤rvº‘f‰
+Z³
+4åqª=çjö¹ÇM¢¢MmU«aU/õ+1:"ßòÐì}h$ºa¦£Y06ƒuc]Ûe!ß÷6Q¾IN(Ÿ/W2Ù£ÇexÆœü4ô×Õ{¶>â|®p¾_ædÞH7b¯“UÛ²2cå;õ!ÐÄÒg^l¼­ýS¦I4Ôñl37ì÷Ý	é*?£‚h¶¦¯mð[¥÷x¤WQòî|¡²™D®ÌoYìR	ãÛ÷¼Úm‰|å;¾D”ÃÐ2W‹i¢Í?5‘ê
ŽôÅÕ½®èÛJ¢ì2ש(׌/lû¹"Hé¶ÓLÐ6Ld½Ï\,u¼Å=ôºIH²ËÉ©dÍo­y¾Z¸¤³yªE2•\(òs²‡ƒœ>%Ìnù³D‚Éy@U5ë&…‚µBï‰Ø®gõ²ª¿ûÑ­!M*UgÇӨѽDþîؾv¨å%¡›¿„ŒήÐnÚ{uÊTÃ[ŠJp¥Ytó 4Æõáû.…¢Ód¨pÏ)ó‚„”àåŸB¿Þ€¿N0Yë‰~Ÿ³,ÿ<Ê£ÈþSÚKÒÎdã”ØTÕÌOÊ¢yxeåWÔ…Š»ÿl²ÌÍ-¬îh§è?_$‹ÏÛfþPs`LklÜq=R^íϳßÈB"X-h#c®†ÃªÆ~ÌÛMÃœ,Ù§	n¬åÝk[nøý­Ž~]6,¸Ðñ„Gg¸ÉÖÐV¢®=F.–¬’Àî%vá`ZD§Ê'h%å°,z‚…ºÁ—…J©ßíËpŽ
+LjòÇØ9C?áž
îX¯`÷î=ã¦ìrš5SúUž©Ò#pª¼±þD¾AZ³c’Ž@6œ~2(ì“w@Ãz½mˆ'Y›e†}U|¢N¢2òÕÔ!¯OòÍCó.R‡ÛD+öj«%_W²‰ÕM7ëç—xÄ“¤NrÑuƦ†Ô3Çß{÷ÛÓ>Ñ€Ò;,búñÖú)®Ö‡ÒŸG Œ-Ò<ÌõOE,ÇH£òfd&¨³	:Šó¿0s[jöîµMáÄk‘É ‡+ûv­el3¼)IZýU+Nšßø^’©‚´a¡üs…&2¡$ïâ!±ÞµmC×7^¬´Ϧ?ª°¤ì÷©Ò_]š¾ÕÂÒy—¡vx©ÑúÒ¡ÀÔÝ.˜QpØDDuÓjœ1ÅAÝM¤ÁèF.{5ªš‰Ü|6‘Qá œ¹­­z¬­ëÉÝ1·´z(žZZÚýœÐúï¿ÇŸ`ØÉÈ\ÆS“ÄÊÄ9áæìðòàKîTÿ˜Šf¶¬WçkRM”[F<"’¥òAÈ7¸Ó#ïÏN‰8¢]$æ¥o֚Ż¥÷ߪ¾Î©æôÛbhÔIâ^²ò4ëÉ—áSKéD¨Є ±õZME±¹(ƒÈ‡•{Úai”¬BoÊt(Š¸¤løB›~ëçWô×ǵ8øTÙ§ìÉQÇEó¶iGÌôwI'9S­µ8ªœ0’ÓÈw÷üHÔðêvÃ\]Ø7n²ÒŒP’s›ö­éëÎßTÉ‘ˆ§ø*Iƒ¤ú1/ —Öí-›XYç§|,Aú¡³»ÃeœBÓ_E~Ý&V·ñÀÕ<ð²ûv"H™xÂbC¼z™YµeÁèoekðºhÄ6œ©ØÃéT¿ÖIß°Ôy±lg²KF·fÞÛûï÷KWä¾Â·÷ð“题EG®þW½ï	¡ÒK„¹^~ÊX(­aŠl…ž¥ðz½ö‘#Óõ)ò™èxﬥç)i”«(÷òµ‚ÃÝÜhñ'
¦Íú3Ž•¸r÷Bûõ5ïòÅÔ÷àô3H²òÈá¢$ùsÇfx™ONý*+~A)<1HÙvc³È]ÃÉ3¾“H¡©6Û‡ S¾ü®`Z€+NJ¢{÷Ò¾5ôgoøwGaásŒÇØ™gŸ_¸P¸‹û-œÔ?Ò¿ª“k/ÅíÄÎ1YñßÑ%Ä žô3&Q‰¬©^¤ _™-¿îˆò[·ßù°©à¨2P Rt]è/_ÿ¬à³Xj<ÉØË/“¬C9¢ã„
\½~)fCe®umÒ-©¦è´Þû÷t’‡9÷j\nY\ÊlŠþŠw°zÑQÁ	M1@œNàµÚ“ï9/Fñ¥ä]ú\Gu5ö2º ˜;Ô,·{Éc"Õ~$å„°2æf–™Ë?yݤ–ÿ¥G'‰˜õƒŠ{Á$‹ís­û<~e€íšm“À†ŒÜ˜´_·­É¼#cµ“Q"™p
ÓÒüÐÃ<{
Úi6ÞÓ4Ü¥(~tŽ©-T”Âfž’;s°z²ô~à—Oæ Œ­RÀƒ¸ŠÀÏ„í‚cCáçšÚ¯8åö·×ÓE9mq)þð·Î\×È´zÑÇ8µO@ÑkOòq'“úÐ×Ö8¡	
È‘ )úfc8Ó%|MQ_’¡{;U¶£–&'©ÿÀyv,Ýnø›œõš¸Rs ݸÿÅ}JM¶¿wë[=º˜ˆÖÍŸ+Jäåó¾]{ܲØʯÇ6HQJ0V/UJxuIj¹&»_y­ŽÎóm&Ü^"ôYy¶u#7_Ë·ú/ð©—ÊgY%)ý¹¤9%^ó
o=KUtĬg„Ô5³e¬+äåÚUR®GýÚ»f?$Ãuà#HikJã+&yÕ}LÒ†•Kƒñ}ÂÐCÆ¢ÒNθ(ûfM­ñýNâmml}À¶DEb^êõ\¥ƒ˜ ^©:Ñݼ=4>Ö£wè=›Fêbøü)óèÌAEKåBMÀàÓvzœƒ.b¢:×¼XS?Õö‰m’£Õ+¨w…uÏkü`…+tR…‚T°ü-i$rx¹åƒÆÏç,·ËìÆÇ+ ïšª‹Ìz'7²©t”;ç~Év	˜Î Ýpãç2Cˆ°ôS‹Œ0zU,›[ ¢¥ë‰Ô:Ʊ+>[™W)?3âÀéGßq9s©§`ÃŒ•ÑhçÚD¥gß2±¼usUµ¹¢R;I0XSJC¶Êa,gþ±þxç,dîè+KÓS@t²¤o“õÀåARiš$±`’Ó´Ê2Fc m¾7Š”‚ë½çýml)Þ'×Ús¼}kíáöÑ™UÀ‘ìf½ý“cÓœ_nqÚ!ò»ÌZ$ÝôÄbú=TÍWTúÔ††—y!E\Úe=‡É
zÆ÷ÅM¥»¾ûãל!\EÞÞ½‡UÃA‹¯[–¤½,q6—œœ¼÷Â4ŠÅ‰ól†JµuS6O㊗†õœä[&-Ë‘U³lâA—œ¡_{"Aï®á÷RËX½çÅöý²¢ÕûáÝ‹Š†y¶}p˜²¡\³³žG•îûÁ/féÝýX‘%õS¤‰æߟHù
<Ž2ÿìbÓSsQz+XVmÖmÜÕ_QxÌùŠÑOJfûktåþÌÓwÜN¸3ví\†åˆ-,¿“¢çcšõ>›Íu7"§:G§"U«Ú%¾`¿ˆÝWSŽÒ«DªåTZWö¯Á™y®$ÁŠ£@˜™Õlž›´ÉfajžŸóÝCþ”:®ã!ä•ø˜DÌlcºQóqZŒÇ¸m÷ÛÐKÈ;š‚,„m#Ñ}\±w›0ñ•UN}!꥙˜#Ù}?”@ì4Á’ʼnz@%R‡òlPÿ‡,Zh#09Ç]üWÙ"Šê„»ðÞ¶•†v+’ëÞÜ#H:éçP0VÀ}ÑÑ™c™Ëb§H‡L?¿#öýB1nn‹ ´9aÝwÿ^æe·ܲˆ£1äiuý!å’PÊ‹;±Ï‘ððñ  r¦RÛÞImOkCÔGZ?+>yeíw—dÕ"Ê‘ö3fp»R‰µê(?½ÁA»Æ™º§f»‹“]ulô}ïñßI{¢ŒîÑ»£ð£L=ŒÂÛ0tÕ‚ÜÒ°7(ƒ‰bçåÉÊm%Ö•åÁŸÏ£ðj¾ùÕ}~V\V¶¯µúpdÁ2ŪõÆÖµg´Öº¹M¤ëzׯ¦éMÔÒóèÀ‹óúc¿¡ó9	ùº˜pŽÍ
+sªâb5ví„.‘Mci&S±{’g>ÏšÁÜ<Ë(þ·9ù÷¼±’
+A¡À„s’Yéí|ªH¥õ:.}ʼô¥´3–BXvÞ|Çá2Zg¢e<¹d¤¾*áh%7(GÛG©úë°ãÜê§JÃ3‚NSLøIঘß60£åÊ?paöÜ¢šŒ
+ùæ»°›À‰ºÞäæi%Æ„2jKV£*´†0^ÞÍóHlQv³ÃøóÄåÞÞ £:¯k¨ˆgD1øŽk'*!}Óï”gr$T X|Ø-ßßR!¶ihñÃ=¹ç{´¨ewÙn&‡ÏÁ¢¡¿„²/>¸ädýÂ)JÈÅ¡4uyW´_d¤ªvÔ~ð»dK.Ÿ–¯e¯û2Qû]¿7Iý×%½ÉÒÙÛý@ÍÆ´,ú›ëºŠÄ+ÔÙï9Žèïï\&9’IÏìì¾×*Å oŸÎ2µ¼ý
¼ý-°8'¢H«ú\áèÇAZ9ônâÍW¦¹›Ê-iž´¨¼ÕÏQ¿ÂK?|/‘›’Ç" ÍTM(ãrèbâ)'žô"pWg[Ö
4ö8ˆ#µI~J=ª	DêÅàXtÊRõ‘Gôdñ‡œ™„U†°—â|¸bͳëí“ÐWe;š¯,à»jf¨*;ÑwM3ò¼[ߎñΟ8kv°Lך©Û-ÐøV™»³‰–A­DÞÍÐJ
+DÑQÕ0>“­t—ˆlgžDù¦6sO^40‡*Æ^YÙ“Üî˜\C5pÒH`~±ò•¹u’‡å0Þ5Y˜p¹ñMK=XÓ"¼ìÞ¹u_6wá¤ßjS澫";˜‘ºkr1@Þ‘Í×—Á¯X¼‘JØfœopk)BµÛùŒÞeÙRµ‘Ÿ«‘E^"Q¿
+R¥U¿˜u’bNRÒal.ä˜ô;ÁpîD”èBSb0aÅ•=mþÕ¤¦c½ì®iïÇÓuW›7²xÜ	>éâÐ'ð¼B‘¯g‘U‹;7÷5FBÞ
~î¥aA‹¸Ê#“ZYÓ¬ÿzš?Nu48ñ>܈pÁÈV’ŸIŸ(
1u¢ª'S‘œÞÆ3Š&¸”Ì´Ë
+P_Ñ’L)÷‰ë“&ûs‰7“5mý»Öñ0S¿fÆV·Rˆ;ÛN>NšßXG$Ês4.ýág’7Mš¶í·k‰nâD_Wÿ"»[«¬Š†íO¾é/ZÑò2¨)ÉDàj›ÈqhsáúŽ,&É`õ³÷C.‡aÌ3ÃŒþB¶ø:dû±?ŸGtù¹PkªˆÇ¼¨ŠaF)ƒéà›Àògs±/Àý´¼
+ØÆïk©1Äïi0^}¦Á+8HãS³GÅQCè„É–3÷$‡½F›â^®›Y]¾ë;­Íå#0hb†^}ߦŸ!^‚é1¹16Ÿn€ø|>Iõíú8¤B}éGc»kЛã›x_3á³ÈåZzaå]mÌ‚aiNtÏ0üCð½òÑÉDz…åï~)f)ƒFš¦mßû?‡Û·®#ŸàæÅìÚÍ Ü$^‰vÑa’Ô÷å€zJîqQSv`^ä•/¹æßô€ÔqȺh§x—ÃÇ[&qÍÜuGìòkêõED¸*=ˆ™ iÊðDxšp®Jɲ5&usÄHnñ“¼ŽUñv÷ô3A²}W¾&	2yt¾eX6RFÍGŸ6•¬uú¼®‘m|ÊV6«IÌÓýôFó/Qwt÷¤Xm÷E™‘¸­¯am¯{~(KpK½w 7,öêsyåR4—-6äó-%^g%*ZúN›ÓPzêƒ*émW¤ì2ÒÜ(ã•)‚¡ñÜ–QÜnd(²0ó³ïÛán{tiE«Ycÿº[Áð¥»åçYçb+À#»&ª‘¸¤]nÎb×o¡AŠÏÕÌ.wi‘6Ñ9yÌÞ7áßï»»GGWK)"šòÀÅ¥WíZ¸8­x}C¦ž{w9GËóøâÄí¯¶Py<¡y ·õ²¡ï‰*;•-°Îÿ2ËF¿‚«ÎÙCÏŸÐWÂå÷1”]ˆI”wí—¿þ‘‘dãÎ/¹I§,·!;}{óJ2t+w!r£Y	öÐæºXHš•¹ë¯ß5µ>NxMŒ\š¯Ú!j4U®¯èDb­÷N+,ì[ÈœßÞã€=p¯2Mã-¯Ù§EMßõš¯ÛT?&Ðí×q¨Êxw{·ªȲq¶ ’xÒ‹îæ:,iop£?Ãf©ñ9¨{?jlyêÄ©nôãïMJs;VpŒÜ›ÿpéi'¾­”kLº›þˆÂb#®}¬8=D#AìCeÓ 
+¼½4\‰h>û	k¡´ÙfE%Ö0D¢øØÿXi™¸ý®äÙø¦V'ÂÞ°­—tö}’n¸\—Ô×DºÞÑ7§QøÎ×	>LJù)§þu“ÚRù©À%ê’‰&\ó«æºª-•ù€8*¿k@/¿fŽ®~ŸÆ9Íc”öÙà˜l¢Él½â53]_˜R”m$b0.Vø	Eô·dì=½S5ª†Ôçû"›çu,RùæÍ#¦+l*Ê2(“®ü¼ðŸoÚb&uÕ¾
++•dÉ7Kýæñ |ì¡8¶°Ù§!®WNý¹O¦È¡„Ù$þ‹=–ëÊnuœR¬ˆ©gûµ­uXÌv']F#ÒÌk‡•ƒL7‘Þ­±î°ùšâeÿzµ‹am×Ðü½³ºÒ6‘%[Ìâ ôºÞÊéiÏj;(6y]›ˆE’‚Þ0+«ºÑ‡=­K>]Ÿá¯MÙE­³ŽsCåZ’ÚëúùžÚW¡GÍ­QÁrDòÅÂ/œ:6ÚFLwÒ ¤¾°†ö–Už8½A2ÆP`;É®Z—tÈTÔ€ü­E¿LèÙÌ2:z.`[/
+à+ùǺI¡x"gŸÅ¶5~éD¹EUn6
³wèþâìb6 Ää4ß™bY™R¯¥©ãTõpM1’ÆäÀÞ¾3Ø3’x4ûìcLç}!c*[ø¯×µãfªVF"lŨ-EÛ•~ÚS›zðÈp†Ü‚öMÀõ—ÛÒåCTÓP.HÒ\ë}Ë´‹×Üäëæ¼3ѹ‡ôžÑYuy’WàVÝw—K<7ºxœ{ô–eO/^ãBù®&.‘v̘ëë5$í»ä/,;½Á
’…Íól~Z ¤”6RâØŠ­ÐmY·×Ø/"ìg{¤ZÆAõÙ™¸åzK}BÖ±Y”bSž joÒ1žI 3ÿàHèd§ß©ÄßXnŽû¹ýW‰T¤L?Þ£éSÀ˜lÉ4ƒ™’ÛOd쨤„ÊNO\=*?ur7 â—VÏV¦æWER¥çÉÚôýÙ©o÷7^=ºœgËêþ5EןÛ·ôtàb|ÓÆÎé] LšÂh)ÄÓžgØã”HûÞãâ Y“û*ÃsÞË%OÇRðƒ9ÏÐ'æ©,Çp]†Gtš~A~$Õ¡­¬û¶`PB!²©b¼Æm¶CúŒ_|ãÛ…“L7vœ Ýv¥:aª±p´jÛ9Á˜€üzŠÂôñ}c\na4BÎ<ÿàS®úS¬¬Yg’:/²vî¹im¼Îß#d‹ƒÕI¼Ãüöc1 ‡f+Š²°¸XZÜi¬}0;­³–Œ”°¢“>mAZ¥+žÎ™å‹äÅÖí86G(3ÒùŠâ­º5»§]ÊöL¸?ÚH| |´å¬À–Ö5‹›]ÿ%s3ú¹r
à“'ÎN‚Ä3Chdv:í¦Ð»Œ*‰íËà[veV¶¡R<_y|ÁC"6Ž·bã<¾“Ù_½‡w¿’ùì6D››×3­D·€Êw˜üh«n½íîßy
ôr-su…!ù½D?÷gؾ@¿ Ö/*¯ñÍ™å(Ç2ÓŒ:Æ_ŽhoxýZ{~dÜŠɴã¦ôÎB[ÇHòÕZoî‡!8”OMúi‚.á‚gkŒ¸Êæé%`°í'J-ÿòöªt¾z\ÈÞ¦),1³žŒnèþÆVÍ*~­ ’ŸÖxG–,€mMë+æi}-³Áç|w;˜•¤*³OK7>ò¢WþuÈi©Ý[Éû‡\†‡ÆNÞfåg)>7Àí;!?o–Ü–WjÈ\¯.Ö¸
+--Ž;žKŸ]ßCl°søüöƒãµM³”{a²¨m©†íÏ#R†[Ø4(¹íóxÔ»E”‚W­Qx/Ÿóò–.ÈMï|òý—ZýH^·¢×%‹Müªo¬áã伟£>ÓÜo’œÜÆ®"D»èâÖÛeñv2êB	™GXÇËLºGQǬÊPoUk™æ^^­Ñ-縔(%,Ç[g-‹/†¾Ö㧂º ì{CŒ«¿çå¤Ó8
X?0{!•†Lvˆ(yo×$è5)8	«ç …173Hrã¥uÝTɲ×+wFåÝ2…Õ]ü¨Œr%A¿¹‘(ÁçK"öÄ5¥¯3­¶çßLNŸ/{÷2Äç-:{0W,FÓhõO]ÌùÿVûè
ál‹n±Y7Ó»I">-£ì´:MÐ{²³zŽÿ²#æ¤ô6c›eßÖyQ´ù‚•,jå>ÁÏŠAˆæ=fÝÇOmD¶†ºãwùƒš±«¬(Èê‘
¸¶ÄZÈ1V’¥’áª>zÑ’,Ï,ÉãV/Wf„+!ßãnÂ)ª‹ùšC¶ßSDÃ>­™-SE\KÓ’À”±9	~:WüÒHÄ*§O§p´Çç'e:! çYF´ï‹•
y6(QFN\ÏîÙmÔBNì3øÔ£ÓC^$Ñq÷I#^Ѳõ±4˜[»uâ±N™*ŵ-ömí Øà„¬2‹L»¾Àá•œÄõ̉ëÞ
+3.À@4ãEx-¶ˆÀˆÍ–måo¼Òy›5ñkº¿-ð"¾½ýe«3Æ>zd±r]­^¥Ÿ”ƒ™è3m“鎵†^Gë¶/<ýœ+ˆØ^bp‰p˜~!Þ6ØÝ*&UÆ^ô=!”f÷ÔXç‹!®%ßÿòƒõÿ	þŸ °qap¨æ„õ%*endstream
 endobj
 975 0 obj <<
 /Type /Font
@@ -8882,14 +8853,14 @@ endobj
 /FirstChar 35
 /LastChar 122
 /Widths 1948 0 R
-/BaseFont /VUTDPO+NimbusMonL-BoldObli
+/BaseFont /LCXBAS+NimbusMonL-BoldObli
 /FontDescriptor 973 0 R
 >> endobj
 973 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /VUTDPO+NimbusMonL-BoldObli
+/FontName /LCXBAS+NimbusMonL-BoldObli
 /ItalicAngle -12
 /StemV 103
 /XHeight 439
@@ -8905,38 +8876,43 @@ endobj
 /Length1 1630
 /Length2 10420
 /Length3 532
-/Length 11286     
-/Filter /FlateDecode
->>
-stream
-xÚíteTœí’-î\›à.ÁÝÜ]h ‘Æww—à.!$@ð Á=¸[p· Á!—|ßœ9³Î_3ç×]·×z{½Oíª]UÏ®·è¨Õ4Ù$-ÍArŽ(;§@ì`îæªìQbÓY»©šÛƒ//´;Bd€P@d	Y¸¹\‚‚‚htiG'/°µ
À¨­¡ËÄÂÂúOË€¹×?—HW°5@ÿòâ²wtrA /ÿã@Mµ¬Àö €´ªš¾¼Ê[ã[mÀ[ä´¨¹½´bP[€ ® &€•£ÀþïÀÂb	þÓš+û—¤+puY€_Â@ž §?+À	äâvu}y€]Ö.@ôå Ž0ÄÂÞÍòO/v+Ç¿
-rrq|ñpxÁ^ÈÔ]¡®.`'(à%«šŒÜßuBm€Ð?¹]Á/0ÀÑêÅÓÒÑÂíOKa/4/(†¸  OèŸ\æ €%ØÕÉèõ’û…ÌÉüWn®`ˆõ?+`¸€¬.–ö Wךî?·óÏ>ÿ¥{ ““½×_ÑŽyýg
`¨+ÈÞŠ‹û%§ô%·5‚ÆñgXä!VŽ.οí–nNÿÀÜA.]㟙az)hé±÷X‚¬Ð8T¡/)Œÿ3•Ùÿ}"ÿ$þ·üo‘÷'î¿jô_>âÿí÷ü¯Ôrnöö*@‡—ø{É^¶Œ#@	ðgÏØ]v³èÿ
-:€í½þ›ÀuÔý]ìðý+,¾\Š$ÄúE6.nvοÍ`W9°'ÈR
µ°Xí_îì/»6Ääb†€^´ýëZ_‚89ÿÓ²[ØAþˆÀû7‚Xþkù/rýU<‡¶‚²œ¾Ë·aÿòT{™¨–—ðit•-ÿóð‡GJÊÑàÃÆÇ`ã~Ãàççpqùý7ÿ¢áúçYu{9Ù99¹/ÿÿxþy2þYˆ…£åŸÉÑ„!–/ÃöŸ†?°…›‹Ë‹Æ}ÿ/Mÿãü×؃@ž ´Å9GáPÛŒìLh
Q~ÿwÃîN.øþ0§ò:­’¢À*ÇŽ€ŒÈuÁJ³Çê0öú1¡ç¯^³‡NOÛ
-Ì;ƒ„öé ÓBr?¦®"ÜUúV~–`“rÌÌ#ÝXŸ³¥5>Nïê&eHc­o\PÎn˜iÜ‹ñi¯°ü-Þ×&´áÔÃàÕѧìß\3ô
ô÷uœ#vm“±ä% Ò	»#`ÒÇ:瑉hWúD±lÁ}Ù¡ŠïJÎçâYÊÝ¥…ŽeÌ|,PwÐÖºàóoËóÍQä‡/Kk×ØC)3ù•kKКM,y]íÝ»IWàCn‹ÿ³ÑžŸEbg¬BY¶â	EœÞïýoÕÍ%¢_¹
p¿ž²Ÿ¬?BûZ·bŒ“ˆ·d*RˆÈÕÝÆø÷@÷¯¾òðgŸoÒÙÌ2ô!í¤Øô‡~‰±ùÁpÕ}ØK³ç¸ûC׫F%=ʾü+Þxè7§Á½€Ö4šçBé÷e©mÔ×q¨%Ù®ñF¥Ëª/4DÀxá‹dÍÛÌss¡¢¬Ù¯?¼eh%Z+r•ØÖ•,s„Q|p\6“¦«Óò·—]=¦LéB˜®ê*‡ð^á„H¢[„%)ÔhÓλÿÔnýBõ¥Ãë8yÆŽTf@F.õ5Ó¶UWbË‘Ã`î“”	‚²Ã2š&·äåêÜ+V	¢,éx”©›ÝmUØ#ÖâI±j†ð¤/]^{˽èभˢzÝŸóS¨ˆ—=¨¯ÆùN0¨®×|ï¢oäB¸F¿æÞŒþn"·3wBaÀBp®6à½ð´á›X¢1mS¯–G–èf9
et­çÞ®‹œÈCöê(1árkÝØ‹úÍâûR9/ORŸÉ/Œ®[–K‹†)5;ô‡Q¯¬puâi—╉Xüø’›öùÓvö®Ax-ÈEʸÄÜóãÍûÓûñ»úÅyR(qr4<³ÎJw9™Ш¥=Yì«ÂÎä÷~0fY²ÒãNªDí]÷qvqª%%›•ZLl4Ë’‹F|viˆbt0©á=e¨_h.eJÔ¦·a)PýYó‡Ýz›w„&ºÑÚàÖÂËØX©¯àÏ
-µå7„ùŸ{D/kÅ:NŠº3©1fæÁª®ÖÌ>›ˆ0œÊ-~ýdžR¨X<™6Ú4’ÑzVÆ„öO”ðµaÕ=åƒd!?Õ–¦.OB)»OÞ8:eõ4 ±ÎÌYÉzM—I[Øù\ó‰i·Ó¯‡‚¶j×ÍX‰õ­æáBJ÷[ØE¾RS×ß½c&È1Om+bi¬NÈŸ
-"¿¹V6Õ›dJ VOÆýräªÕpê9£åLV±Bï÷Õ&JÀà»<ëÈdRs΄5Ãc6âšþ=ó×½Ó#|õ‰2Ìu÷Ñà	7$tD;³Ì/>ä…¦+²Ø˜±%œýD@X;…1OžK(„ØfAH̦Ê"m…
`²­èF5óRX¯.èÝÀ1_|qãŸ2
-òâ¸ÚqÍ\ó°aTúËî3ìlŸBØ0UmËç:<¢Lµp.«ŒHa>7÷ ¡$é$aLŽW*æ—ôZÇÝඔ‚ªÖß.«UŸHeYê¦äñ4’5¡ö|Ž¥òïm´ÑË­çŠß“Trו?äÖÏä‹wJf–h÷3»7P¸bF»`œ/[ŸLÏ>¿¦td#ø5‡ÍPÝ®gÊ|Ô«ÕCY…#4WÚ*€¿0Z^oÖ,F±ãƒiôŽ¬÷“Ön4
‘EMI;h!ŸQ5r²©äÂÏ †uVrŒyq ò…f~IØA¼þ8«+ö}¤&ØõÃu"ažyº-¡Íß*Ã
ɹü#Líj)¸|›t¿Wu‹ü4°s!MRmYŒ5 0ÉWýŽƒýÝGiÅGÝD¥å²VŽ>5ºöæw&‚ß3F\Ü~'²Ý»µIËO™ù™õ¯âÑG÷4•ÌËX¥+© ¬ŠD¾I_åhkˆÀ/ÀŠr2ûHïíæ÷¹Õè9D¾ÏÔK1Íœõ.ÂÖf:¥©_ˆú™4LT™M7(¥o3iså—ò»ºö½_ÚC'¿{drmcN~µG§;ÝÚq´	ÓCLs:l
‚DFLS¤ÁrÚ'»HíÚGtH”ÁòaÀÉ©ZʼÎ÷h96åË—¤õÆ3ψ%6Ëpx¢OÚe.OSåÐœ©<³Œ)˾F‹´®7}Ë”#)_Z¥¢Ê
-7ÂÃD
R	‚¿è±¡~HYÑ+RÝ,=Ä-*Òÿ‚´-°?MVC˜$™œiĵ5˜Ãù–…Z¶a8W‘OYE«Pj5úïNhŸüˆ×KÈÜœƒ[—ÝËŒÇÓ]ûʲj¿æ2^*î_5—ð߸-Ýg…û®Æ¢…û#¢žö¿ô¾¹ë0ÖÌò·h'‡Œ²Æ2—ñeMÔ´!ƒ-ËŸŒ`Êz"ýÑ`¼ŒøñÉUÅæï~Q¨’:Ü&1:Äú7'â/é|ªÖOŨÔ	,‚ Qp˜¥ÒÝ5Çþ0-jŠ×Ñf‘	–šã#ƒ®fZBÕdeWYÉQ”y1°Ãgè¼*Ýy‹…ñP¹MIm]V¥‰Œ„=¸2Jc_ÞY¼itP³¬æC´KcƒHÕZ~¸=›þœF‚Y}üR>ôa&Úø è=-—þé:êèžXA<¤k­ÍûÛÖT@"7§½Ù2†;™áRÓŸºº3û;ÓׄÎøR®¼	¨ò;ûçVó€(§Ío–·ˆ8oMÅktöEáú‹Œ+6ì‹‚çØ{=ðEº8~꓾#‘šhl­,>õ]i^_ÇçDÁQê&ó¾~¸ÁkÚûïßš£BGIÁѧ´Äóé]•¬ÞOà#>+#¼‹¼ÞV·Q	9ßi¡öò}ø¨‰yF0ýäüÁä5ÇE†ˆø=V¢l%œ‚¥4è5f·ÖBОJÅÆÄ´WòÜŠVöÆêC«Wº§ê"MÞƒ@0ih”´í2ÿçE|d‘ó>s™×Æ,QáËŪ±qJr=­¡ïn<µ 
Å0ë’3²ë¶ª¶Þ4˜2cæ8›n½R^1][­#ÜÁZ*E#1
-eÕÔ×Ì:8}L¸Õ÷aÈN˜üŠûÔªÌéjb¾ú©;¯·»ñÐA¨1ÆE“¦{øc”’³l
-¶§£âŠîZ<3ýrãrö, ˜ú¡ü´sÛ£¦üÇçt™-’,ÊÁš2šv^I4{|ãfg£!Æ-’ßÏ
-l	,vßgª[™GV©SÓÄu rbðW„_±}\7Œ]KöÜÏŸŸ=8RÄC&)Ãù13S³à™ÜˆzÖó&Ü{Òâ®;›{ºw/L=®¹>Îi%Â+06wIœ¢¸/óÆ1qx≓–^½Û‚ŸVæø
aF©kH£ ¸p”6œB¨EAb¶¼4ƒ"Ògå#ß–ß]ßÙ¬’ÛžâÀÓÇQ´ÝKçãëA”œ˜jô¾ð‚p?Ѓú'[yõ|#—Qb9rȾÃFNw®Å^™Ý~¹6”Ô™ÓEŠïábä߬í#Áæ#ÚWŒ¯*È•:ëè$4×hÔË×öÂnD¹ïÜšÇS×¢FD¸}¸ÐXëÏI¢U1Øθ3o8ú8J)u£e<Ô…Þóh|¬"=–gfíÎ1`[u˜ÅQAØÇyïóÎp%oZ’øqa’…aÜýËC5¿‘ˆó^ÐŒ
-ûôÐÓ]2Žá×ðÂŽk•|½Ç7X>럾·Ù(´Í¾o÷ŸÔÌJmˆ•oXGUç²7w&¿#7¶Ù>E"]$H&íÍĦ^û0„“•¶}™–ŠŽÓQ¬W7ó,žWïG²ó©O]k®<ž‰Ý™mH¾ uÉ%—œ)09ÅÁŠ§ŸÚšaQºÍ³~aµÝ°ó¨cw˜[K¦;ÿ
-ê(O“ùRtS63ZÞ0CFv߲ͳZ
-|C·r®ÿµ?Øô¼©F¨$	@¯ÍrjB/áH
$=@"¿ƒ£ÓžíW'$êp+}“'!€ëeGUú!‹cI„Œ‚Ì‘JE#‹ï~üª_ò‘#’‡Ž‚æ\ÖèÍòîDñLîôx@ÚPqÈ&É@ýê4‘UªÏ0+	œeˆ×”¨ê÷]ïÔ¬ÎþÍÚ¶ûÜÂû)V¡²çOs凜åEj¨KØô„Ãzã¥ÈÖt3zÀZÁJË<ü›tBlš´7Éw1ÑD;ÓàWb´ÆhfX8h-´Ö6´kێג™ð±0vÐÕ8$Œgt¬Âzä"nÙ+¬FZ»ÏÛ	ýP‚ïŽl”zß19„DkrrЈ0ÖnœËâ{ÔäÎuõuƒÂ2éV¶KŒ
-€ñLœ #Ž|DøÓú$LP÷f(.€RC¿7é@
-ÿ³±Ž“ˆ¸*„e³VtØø®Ï`Áz)£`j|S’»§²×¨?È4·¼-ó5W¾”8˜‰¨WÑ÷ÒhòµÈ~à&JYÈ)0­ê¶D©:Ç4Á¬Ãšž“<Á$ ŽFô!uæýÔK~Smò¡z­2
;zëJŠfÕiu°„j–ó¼ÍÏ}ÃGL0tW’e³Þ‚å»0\èœCå™xà¶}½©âV<=Xeys¯”òLV²º3#†–¡ØNs‡Nɶ¢»H*åÀ›õ³?òБ´¥Ôo0͉L´0[„SS÷Ñz}k,œOÅffáL¤ßzMÞõ‹®Q½ [ßy]£=ÇÒÔ„‰ÈPmC
v¬M£F½\áÃÎ³‘“½›I¹Fålºs=˜•ø¨	žÕêiêÀádùY‹z±¸úž)fë’\ä14؛8æÖÑ–áB½d*ãó¬¿ÎNô®¦sËÖG–.‰£qÕÄErÓõxš1'6á2ì<›¼”gÔ*ÚP~’l¥ð±Ö
3gØr"¶*¦Ë÷Õ+ YŽ(ÓJ	aûM±)ø7qùkâá•ÞŠº	†µd
÷çíÌ«K^Gˆ¶J0 ‘d_áZ¨¿¢<“ÄeB¡xR¹¢¾Mœ^™Y²é)âÛ¶iÀ¿PòÅÜ¢¸‰j2ªñ¤Äœ³…nÎjÖá+Ÿ±U‹L(9 ¶ä,ÔYóÜøµÚ6ò:Æ>{Wµã1¡ò:›ýÚßípõ“DùËDÐ2V†Iq0³’Œ™}&Ïéz/–¤‰—¥¬cžÐÑ‹Å3?5¸œ´º¸ë§8ËÑs|#øq"‹åìüv÷U4Ç7%úÜÄäçÑõÕÓßÒ“³¬OèÚ-f53¨™côçìcJªÊêƒÍj[…2œC¢gŠ+§•tùÇÁŒ*°y¨AÇiÎ(JmßRÔÉtýmk¿0²n¿.UU;î質ÅÈV--q!½ôñžL MÖ³<·@[êÑaÃËBÔṆï[W¡tÌp§¨ýp	2<¾Kì-r ±ü7>ogoÝ	ëO?V'ÖäôÃ7üÀ f*,ÃýÙ
ê©¢eáV§#SšˆNÒ[ÚæóÛ"zʯÁ7ñ„—çÜÓw‡ñ!~h~Röb®ùÆH÷¶øV"ûàù\AÕ½Bl¤‡•-€gèƒSõ'¦Çñj“(ýŮ,gë4Zh’¨„à:“~9Ðëæû
-ÉÈصM"-!J$Th ¸þ`1/ù†ñ\âîô­ÜTQ‡ÐŒÈ[ÖNåÝW…ˆãíñò	Φ·9íïCÆ?öaô|ºé´Ó2gz µÚ|펋0T§ÃLÒº2ÖËàÃÍÄEßþ:–@A,™Š`k­ûúm«§”G6Š+Š9gÃÀº‚r~I÷Où­è·DÊ¢[{­‚¯´rÁ\CPÉ#†|m\¶}äh;¢µ…ÿ´fB­Ã0=­7ÍRô‡/œÀÐÀÝÔk¢1fR´^¤ÛºÙCñ®Çäß>0c(¤‚e(Ö.×ÈîJêùô
-Q9!™¨‘™y0‹½zÞ½iº˜^Ì	/D—Ó|eæèù>JB»!|A¿,S`&ǽï.÷L5ü±ï÷÷ˆCXæçÞŽ¬
å©aÜó‡Û
/}WRèŠ"µ±gÚѾ­øÿ;.¾‹œ2Q‹)3–+À#'[¼„ì×jéXÜö¤êáEIkÀò YBUµ<ÀòÝÉÛ‹QË¢Ÿ¹Ù¨ƒ-*›žP¹KG}Ãýºm<þ@h9á¹5+3WgÁ¸g×TÅÓ_¦P¿PØG’ž³>QîFÛ_DþÇÎP\òýò¶Þúº2ª‚á\¸+WÝÚtBVÂv±7×â«5ÒnáL
ªùµGˆ´³¾i•ñ™p&û¬Ý†˜"§©NÝ›Mu}äφð<þúˆÜ¡ì«–¦É•dRþ*D²WÒ~ïözjq¡6Än¿ç,àíd#%üîç& Vç
xœRðÕJ²,v~ó½="„))™ëÞ•‘-rt£gc®Áy7˜œn»’ՃĪwhN—&um6 njþ¬$)ˆ’f‚ÏF¤”d/¨4Ч2ábukÙL%‘v¼}
eAhÎê{µD(”ª˜[Gݯö>
‹¤LI’MFÖí‘ðÉAëU”¤Šz9EóÖk1"ŸNM¦ÄÈÊOÙ5ÞzKYRC,Õ`Ž¢ÊSt:Ãd1Iuu“bWê×7ØßâRÕi)‘«H”ïŽù±ÒV½QÏšÒŽ%Æ“©Ö›.ªOr½ÐvéŽZÑfá])Ù?ÓzúÆä`ËÊÚÀB»ìÝNr¿ÿ
^˃ô»‹s™!"ë¢ýpWD©åYËò¬ZÆÍû蜯ÌrC™9OÇÖ©u¼M¦¢Q3vv0OB®ù—ùå”Í/ÐivÏÞZÀAIW„·é•ëžÜVÚ8q`Œ•¼:œz”Hn5
Ts)Ÿät‡«·ŒÖàÊ>»Î¬‚ìŒPFùÖ„£?Îg¬šV+±¼	I›réh¢²þNâkíVHD‚ƒÓq§¡vey6’6³Õ>¼ò&f’Ù¯Þs¸µqž÷Æ<ÍÞ¡åFÂ'lÓjÃDšË׋†™p‹Î‚ÉLbÐs*}L
6÷=AÄž+0	 L^þrøV“¨XÌ“/(°	Î8UBÝ‘~úóü+~‰"•jñ¯®îoÙR( jˆ‚ò.©)Å=^•aæ°›%“DBQ=#ÍéBt[­r¡ [&e‡œ
9¢¤¦ÐƒcàΛug%¯ÜæpLyTÆIX‘š£,Prb«îSàúæ„ÄZôâÕ·e\Ýt$võª¢[aZJtã!å(WcÇb†ŸyÓ(´¤4‘éÍ£ôem'ÂWÃωPq¸ýßrÄ»÷qŽU‘²jjÓÄv‘AÈV’ÒœœsöSšXŒÚ#‹~[*LýDºûY>à†ÌK’³¹i-úá‹chåõç!ØÝ©ú«Î¶g“°:Ï2|pÄÆCׄ÷¥/šlBÿã©Ò›àÌâ7¡¿J¢Z ¡}ðÍãrçH†ÎFTõT˜<Í>Dä÷Ï19="ÒíFØCc´nlS“#‹&›Sô7ËÚ¶¦žO™èªÜsqƒµË×0>_u¿MTyÀsylîdI	J•¶1Ãy÷þ¢áĸ¸á™{mÕ´ÅT±š“´÷ÞGïÁ±ÄÏ‘ÌZ ­P‘ªM ÿ#~ç¬õªOp
ÀíÈ„ŠŒ0aËãÏWK†'‚äwè¼cèª=äÊPð5×€êþ@%`pCo	N^³9)üÎ\›Iž·“S«ÁßR‘-‰ñÞ° YŠ§ã6'0#è–±”Ô›¤H«Ì¹½ì	kIKRå‚iìÍQ¦Ù Óp]Ë¿µ“”Tû¢—­~š…¢«îlô~â†õàØü-³er@ÜYŒÖäžîj«ýT"ŠÒãÛ¨×KÜð%ì_í[~«¶¬ƒxRåøž&'q.kýØ®ƒ”ÞÑ‘ccšÀs1\ÖEÔõŠbº<&zò¹d£}‘l—¾¢@ ¢¯uR$î-±ÌM3ñÆö΋ÇV"¸3<›6@2dm¨YežqT÷5¢2ÝA?ÒîYÎ7½C”BU*uE9VA~w¢}½Y¬Ÿ#•pþ$¡-È6;ÐL Ÿ¼û»Õ…ƒõôí°zÝûgžgbAúi«á´ÅˆnÚbH›+À Ç§$X?å£ìW‹!j¬8ô3lËhß7§ÍUÔlîès5Ã¥i‹H'Î^á¦_|Zžo í l:ÕyjÔσ{]ñäS¼d2B”ÞHg~´ê#n‡Ö7Æ
-ñ,(ZÃ
…G!½½,‹8yKæ;~ã)_Çzá8´‹öÑÊXÐ/â&_5º(Ƀ|s5š)ˆÒá+>úÏ°c²±lj×ú²ˆ%¯ñQ
eÃü²†‚w¾ÙÁÜUú7|Þ–ýö‹ç4Ï‘³·¾hB²’Œh'à¨]NåD¡·T±TÎ$nñõ½Cm¼:1
S’•ÄéEÔ¨“¯Q/nHbç A(¯öÌ'rÀ/V±¼.p:F‹	Ö“»aûÏÕwïl0yß]Žˆ”.z2“ÖŸ~ÝÊü”— ³z^¢ä&Ÿ›ÚÕ_BXÌ].ùÞ,y4DñÓY=õN[“ou1~KM“éýeülÝQЃ$¾®QJÖ\â3¢¼ÛÚ7²_ÞU2æ°(²89j¢è‘X(ÍàRêôâ&*ÔÞ—«ÿ½—R„Kó(P
-ïÝåJÂYsD,~ ‹j%ûÏ.Ÿ(gªbç7ú[([7™>"Ä«1íKIkJ°rÚ(t~¨,{|†xáïÒ…CWá
§­›ƒpK¾}AµþÖoX4šÝØœÙ5)köa³ŠGöfeÌƦ¦»#%ÝÅM'zŠX³¸·®ËÂV‹ïÞ,]0.Ùìëî9¡ß‡'¼Ó+}ÅNw§s»çoXçð:¥r•Çu’Ÿ¨óUºÊ‡˜BsûîsŽ1ðô]¸ÑÊágE>èé6±:ËÖªbCÀÙ‘Pý\rËÿñfóªÙL[1Ë@í×õˆL
-Æý¾> X¿ ãŒ0ÛÙêpµ~è~ñnrÆÀf·*zW–Wµ8ÁˆåX“7`i
vXìq|¹*ÚÓÝ;É}…ºÛKå×B@ÅSCÂHØjIúœº3NøÎOm‡êuHÎ&¯õHì{ÃNIv-%ó2þb*BÁÁˆµ.Ú¿ÉË(-0ÆÃ.™
bÉJßÒú×קínjiF^Aƒ½x”®8¤á-	…Ž!
`ܯ¥	LÑËëû.íS@&Ÿ$ 1~G„¡é!nó[‡:sHæÏÄzŠê÷ ÜPÒõöoaÇ"Û£]¡{;XÎ	Fb
úzÛçŽw¯ëö‚ôƒ
¹’Ey­
-v{Â~[ Y퉷kë[ÊF.Ëë®R2:|µ&˶ù&~t±³íšá–kAYÆ-Ò’Qíç^Ü—³AÆPR˜R†ŸAÅ%®’+Âã9ÔR´¹«{ Ó’!ŒUW2i÷ø¹ó›
oO7BÁ._«¬ëyŠ
D(aá]k~®u–	®Ý‘»ÌF%ïýÐ×ÙÐdf»qÅ£ˆ=#ã j)Š¸)…ào}Ú|(¤»ó$5÷)ê:×eÝ–\KÒ|ý`S';ZU©ÜóÑâs—5žm¤_|à»Ïö˜iJTR#ŠéFeðnH©á$uv•Íž"¢òÌŽà–'	ýÛ³&B#çS5ïg#Ö´¤ñÖñ?œa™C‚a?|¸ügz|8xÉãÅ1Ž2,ëÐœ^ˆeQ–ÂDi«ÿªè¬0½¿8ÿ÷„ ÃD‡Ž-…6Lj@t}…xO{=œéª3ñSÒ¿€u÷Õ4¼”UÆÓ'¾zlaË®ÃàvÙŠ`GÒœW^Ã#"©´5ëSèË$ÝÌ9ôÁéžpß~dêúý0Þ‚}$d_ÆJÙ˲Ën
-Ÿü._¯	7#° ôcö›ÐB¥×¢fÜÈ=°ŽÏÚÜÙê?½zêý0íCÊ‘!´æûtÍç«1žu?K+.®o–/þRi†-zSÇ6ÊüdrhŽtFš(eL³‚/umDðN”Vï}º3,RÖŽXí;m?´oZ92íã“Á‚?†}æ]*ý|ðÊI¡¯W•’­Ké6¤,È5ßsx˜ ™ßV$$öøu"ÛºîŒw£¸ÔfÚÏëö-´*MŒ¹ŸtùÞ÷š^þò9CËt¼Ìþp€ŠÚ}{¯Ò¶>ÍëýH/[óÕFI=`k9!«n¨«Š.ôÊ$s(­y4ùrðÙâV€ªáÝ·Šm.ÛŠ}Ö/¸°•åoâä£h!ðv\wþó.¡}Ó‘R#îÌÝjœeÚ5¦.)þ0—Œ¥SMœgcE²MÑ¡ç÷Öb3Ší±ªì§Eºý3¼8ÝFа)hÜ”äŒ=¸—"ëë]l䳃!Zj»©n<%Lèl›œÿËÚÿ'ø‚ÀÂt::]ìÐþ«£–xendstream
+/Length 11283     
+/Filter /FlateDecode
+>>
+stream
+xÚíteTœí’-îîNÜ%¸{pw·iÜÝÝÝ݃kp×Á	,œ Á!—|ßœ9³Î_3ç×]·×z{½Oíª]UÏ®·¨)TÔ™Å,Ì€Ò`Wfv6~€ÈÞÌÍEѬÀ¬´rS6³Þ.$jj	g ©+È,iê
+äh-’@s€‰ áàèå²²vÐiªiÓ322ýÓòÇ`æõä-Òdм½¸íí`×7Šÿq :pµ,Av@€„²Š®¬ÒÝ%MÀ èljPq{kÅ 2‚]€ôKg€Ý߀¹Øô§5–7.1€)ÀÅhzzšÿ@LG ³=ÈÅåírX9›‚]ßîÀÕ›Û¹Yü)àÍnéðWAŽÎoöoØ™Šƒ‹«‹¹3ÈÑð–UERúï:]­M]ÿäv½ÁË7Os·?-ý…½Ñ¼¡®¦ °Àèéú'—`rq´3õzËýFæèú«7ØêŸ0œV¦Îv@—7š7î?·óÏ>ÿ¥{SGG;¯¿¢þòúÏ@®.@;K$vŽ·œæ®o¹­@`$Ö?Ã"¶t°³ým·psüætþë‚èþÌý[¦`;/€Ð‰UÉÁõ-%€î¦2Ë¿OäƒÄÿÿ-òþïÄýWþËGü¿ýžÿ•ZÚÍÎNÉÔþmþ^2€·-ãPüÙ3v¦Î€?»ÆÉ
ø…™Úƒì¼þ›ÀuÔþ]ìðý+,ëjúv)b`«7a˜Ù9XØþ6ƒ\¤Až@«¹5ÀÒÔîíÎþ²k‚-€Îv 0ðMÛ¿®õ-ˆí_0
k¹-ø\C@°Å¿–ÿ&×_ų*Ëʈki0þwö/O•·IpÕðrþ#¶¢ƒÅþðˆ‹;x|˜¹ÙÌïy<<œ^vv¿ÿ&ã_4ìÿ<+šº:ƒ<úl,ll쀷ÿ<ÿ<þØÜÁâÏ䨻š‚-Þ†í?
`s7gç7ÿúþßšþÇù¯±=æH_—ÌBm2s²\ðF?Kêö³C†9V4k”Ö9ôdFnóÕ˜<ׇ±´Ìð¿~òZ:v|ù.Ç°?ÞgGÛ—Ò½8‡êÖÍß<£)·£«¡äø„&åðî–vxblt¤ïvà;1c~"µ€;*ML S>±ˆžfOãTã>yü@r·)–å¹ôCZ(ÞtPæbu¡ª½¦Æ·w¾o®<tyZÚ„r£_y6¸]9b×ÑõÞûԅ>$68?ÛìxE÷gª¥ª^D¸ ý2~+ï®áÿÊk…úõ’óbUí:Òµc˜D°'Y•ø„O,¯ê6Ãóøˆý‰“'Çðr—Úz‰v~âP/eÌz4´1ÆúíÍàñ0YÌ”ÃÁ7m¯A„|ä(»ŠOX³¡½Ž)|?º(_‹$2žËS»)nãÀQkR³m
+×u”ø¦ñWÉê!r6Y—fü…øÙGRŸ¾yKR‰vUå)0o+Xä
+ ø`8ï&-Ô§|_wñ˜7¦æ
奿i®™ÀÂÆC6K’kФZqÿ©Üõ-„8ª±Ïë½=Iæ¾xV@f³6Å-ýwËÄÎûñÌq#Eûu$u±ë5Äel&Qül‰x„ù»ƒ#MeȦ’9ázÚð¤Æ¯ëÃÈ E¸½ëâíŸ+óˆ°×CˆØ³Üg¨´ä·[¾Ñ÷pÒ!ìSðŸò“Ø›9"ÐbòMÀ8Õëq]yZsY£4îV¯—…d<¥siáøÞù%Þ«¯ÔˆÝ¤qg'ä·„ãKä´¾ÀGq!»:½mQ!!&ßa?F±1Ž»ÁÞ¥Y†eP.hNø­1!/­öã÷œ½ð& 
‚¸a©7hèÛûŒýóÇÙ‡\š¯+D®ÉÑÐZƒœ0üÓvÄùØEýÉO¼ö~&ÙRm³ŽÊø=q¶qÊ¥¥»5ôÌ”ëb_
¸mÓa…©!RÇ<Ê)¯$KåT¾C’"ú3LºwìóÏ
#uCm…›®££¥b·B_iÊîð¼	]7‰Œõ•
ðeQ ,®€”]®ì­|va!Ø;ýF‰E=ÅÑ8³¬5)Å¢u,
ûÕðì^È ›Âê‡V+ƉC~~UY›¿>%<{ïè—ÒQs…ñpbÈNÖi¿KÚëC/`_IL»/\x7´×´mÂdšØÒeÖίð¸‡^ìë!>ûÙ;æ	ê¹MQU,¯ÕêÓÉKQBäg~—šö–S£,QØú¹¸_ìMjŽCçqTlÉJ6È£¾šø	(Ü×}Yô*NY&Xìs'«Q·’RïÍnƒa°1³'ù¶¢;\´ý6§eã3Qº7¢RÜ
+ã>õû~
+[`Ï—Ì/ù®—o
MyYU‹â¢/ÿ¼Ý›Âœ¢ÝˆÓ[³¶MlÆ£ç¬W®¦mTÈǨæ1dªveCž«Ø}z^<’%„áùaönxwŠ»%Q’¡Zû	o·UTK¨?Ûìª2?4]žÑÚ„9ùèâ'ÌÖ9daîRT.Ä&0Lh2_ióU@?"Ç’zZ=?…éæŠÆ
ÓèÛ†ÿ’Y˜ÇÞƒiâ’¡4ZþØ–ikoóÂŒªlS±Üçe¬q]Tg@QÛ1‡¤ƒ„1:ÝH¨ZYÓéšu7u§ÖítýÖsÞ¬ƒùØJ$ÅØÅ‚¢Ó9ákµz>LÚºS;Ö‡2&êÿ¦AÞÆƬ”½Ö_ê7ãÅ
+ËšÕ˜±{[½¤-üyª!Ø¥ò6¯Ë,ÝÏ–r‡{ŠÒþŽ•ðRö¢i³4:»ŒNt8¬¼GrØ¿š&¦².ÌP˜ã®—ae‘©Ö’ГÖNTX/ïbmåV¡îé1âûœ9åì¾ú;‘ùÑ­[BvÞÄÏdär{,‹&z¨½tEÒ2]A	fS0ò}úö4kwçXN!ZÔ¿£I5·›_m—Ákˆìˆ±—|šÓC„8Ìx^]·=´–(LHžI3(ed7iwã—⋪%ú£%wÚS?{drS[nA½G›;õ>Òi´ý'mLG:dŒhfL{¤ÞzÚGÛH,UAw™Ö
PÖê=µàŒ dn¶h˜¥‚Jï
¡ßÜè{ruIîÏžçS?èôQÚØŒjT3§Ïñ¤ŽYΡ¯jã"»t¡EM>í'ÎÄ—·pýèþÉR
?©0 o‹Oï|Ï‚®š!\Õsø” ¶ìOߨùu±°±Åê[¦ÛÍ’¾ú%_'Eχ—»¢±>‰jI4ZŒÜºµÜñáÉÎScî1*o,³ÌX“¼DZw)ºDf²”uöYŠ‹ë¨R, ¤H«ãô¹b²euJÊLPSœôDÑ@¥ è«!k2ÓÊ”
bEàÝÚSÜj‘ø;•|ÞÒéo£N)L«&´­4¹~û@óŠæåöôÀ»cg0ç2F³C7÷—~gbQ^«PW´›ª†üÎù¹×1&DËfýÛœñ,Æc‘­C!¨ÑbÚ#¹»âàe–ñaÁÖŸºD2¸’â_ÚºjJÎ}7ÚVAWñ¹QÐüdÚÉœÇïžî°Ú÷&LƒýïÍ]§‰@ÑOçT+0¬é5LÞO/ nK¬«üá.·iQißþžŠCè;W#’Ì`š¹•£¹)
+Ö«LA‘G´D©(aÿ	à;ÔAG´Õ JU;_^\‡uç.-©¤î,+»¼Z‘=•¿RæŸÐò…FIجóÔ~ÅÇ›º1“|÷dÈ…¾^¢§ =Ô**sç	«n-Ø[”Ú¶Q¶ñ¦D•œ1ÃØu®KÁ¦¿µÜ†y€´Pä†c(âÏnh0(iX²w¬N¸×õ¡ÍI˜û„ùÒ¥Èæbd¶ùq0«s°ö؆¿-ÆN™¦}ümšŒ­ü‡+ÈŽšœ=zàë…qãWÈÅ+¯|jeÅ5ÎtÿwˆŠoµé¼’{„Ùdã
å”=\bHv8†Nt{„¿_å<˜m«3²”K,Í"ëT)(ãú`ÙP¸&«Âo˜«·õ£C·’=øV–ŽŽ‚ä±à	Ë1>F,.6¬z&·!^ý‚÷ž·9š/–_Ý‹ROnOs!ºð±
+
ÍœçIËýMãèY=±Dˆ*Ø2‡ÐŠ¬¿ÁÍ­i¤¤Wúó0Mp×FP®°4Ùð“÷·¶z›$6çÐ4q¤=ú8:`GúF. fQ%
pt®‹K·Ð§Už.r!–5—ø3däBÿVìÉ}ã­¾˜öÔ²6\Dø×<7Î\Ó!:7þ¡||]a.¨¸ÌIK+¡£A­E¶ir'Ê}ÿÞ,ž¢	1"­òJmk8>o1ŸJIï‡@æ=@€aÇÁÇA\a)ó©9ô‘S­ºŽèR@–~’i0W?€yÓ~	C	æã}¼ŒþFþ‚8±zuŽ‘v4øËC¹ 
ŸíšÏ„™ýüØ×],Žö×äê¾KÌl‹G¯Z,·ÕOðȇªß‡/*&eÖŠwLÓÊË9»¼sŸ&aLw¾3Œ„»JKú±›zëó‡v@þÙísañнNÛtñÆÇŽxK(g”1‚²uRº“‹®NØԉ티VÐUÝGï²
:£t²¢g€
+Xÿ÷Ô­&?=b¬;”½î‚™ ¬«zGn£P6í±ÿû±Ù‘,œPýgµƒ6å	Åù„
˜:vn‹÷Ó‡²2#^Or3jK:vªªòÔ.–ŸÝ\„ì(ÎÇÈ××,ÖM[êIWÐì’±]d”KÞZx~wŠAÆ8Bxþ^®ן×B›é·‘œMGÖⶹ W™­qªµ¦1¨ƒ|ô†"l!‡qk:¸fV‡ž¾î­_ôn8ØÍÆ6÷ÖØ-hV]†}__Y ~ˆÃ¼l˜Z¬2 ¥G]1]ß3‰°½sÌ!¶
§±‡[LÀ¸ô
GøÂõ‰¢­pkk8ÛšöÎfÚi¨bÄ.*
Þ4êá`b\¼ÀÎošbhÆä*ͼJžê XúeУ]äév
+®õgJŒGâÖÜ3ûRÄë,’ Órw¨¾}óã”sᓱx&á=¥Ì\_Îƈ߾lz'¦vC>_	€1Ä8ïÁ'nX«ÄÿÔ_>E듸è3cióú‚"“š¿X.,\Œ:ÚÎä½s¿
‹Šs©h‰74’žÅïM$úÚ”t¹A¬Å‰V%è¼Úï¯àFð¥ìÌšjIp0!{»¢”§îYý2™‡5¥C)›¬ÜgªïvPc,ØÖ1#H¼l€àT3%H°øófØúï{l;¸¼ûüÓ	
¿@vt
MrO;¨|¡–Ï즪ègY§ÓùîîÆô[q£¿èÄ"
…W²Èj7ð!¸ÇŸnV¼ð’"ꘕ¤i$| ðæjlF„’U}	ÆÓhØ}w+Œž7S9|ç.ò
7¯îÖ„pÒÉå¸r¸ôŽq‚Áéç6&hdún ³ì_hÝw¸,<¸ªè}&—V†béN¿‚ú*Ò$‹ïʧËÂ[‰‰;¿3Æl–™¾§Þ¸Ôý4lŒ
m¬6,MÐh2žшzR˜’ÄÁ‘<@‘šNR]Ö'$jq(ôÊâB
³ *üŒÂ°À‡G€gM%§”‚ƒŽw?Å{&B‰ä¤&¥¼”ò5õf”9“¿îu}/
“ЗŸ°NÒS½9OdfÑϤeëcµ'*û}Ö97i¶{¿õ‚î¾üïqž‰¿üõãr†¸¢¬`E)³Ž@Ìp¼ø*1ï–væ°#H#Xa“g—šŸYÝžê.ù!&„Mª'Leˆd‚öÔ†„ÛIeeMµõÝáV,:ÂÖu3eÿ­¨¾˜Cê­
+ÃÚ¶lóE7÷³3™N/,*+¿PC.m.>ÊÖSyüŠô¥–ƒ®v«~@ P2ÝÒf­NMTP-OÏoIBeqì†bHpæÔt‡“ŽÄqj
µ¥u!Œ»MB“†#z«Vk™…ó³;¨b„èC5ãAÆyÝYïØü£D@ìpøÃò¾×{àOÅvcwQŠrøŽ	€e·52åeú/ZLé¹ÉË`~>\‚hX"'N¡Ã$wõ¶!•õ[5ièÑsh7â”›Ž›ã¥ä»l—Ý~ú,;>Â|¡bŒ»-挟 B—ík.D¿ÛµËïÅÓ€”ÖWQ”‘]H‰Õ÷gÆPіتïS+ØT
‹§y3ÕúÑ›:u–ù§™Ã×&_¡TT}4ÞÝÛ˜­¤¢ÓM2²%Òì½#øE=«Z˜£ë´-„R…œkalDÏ3¡¯òEr¦[­A¹B®rÿŠ=¯ÉÔÙ†ÎÝœ³t›bõ%¥ÄF|ÔÎÍúŠÀÉdÙ%óḖ¡y­ÛÒJv’Jô]÷®T3«Âè*‹pþab¥Ù•+¦_g:7yåÛSk×ј*"‚yé:œíð¨_v¡2ál=Û½Uªºi~î§p35O2dÚ°Ávɧˎ´ÈÁYLé)RIœð£ûÌ3Ëù·³û«c᜔ݹñ…ufOŽæï/_ªŠÝFu‰Ò"æÜ`š«b“]ˆaÒ#b‡Ôlhî¦6׬‡Š¹¿[·â\)ø¢î‘ÞEµ4x’¡.Û¸î.©7ã(^0×~‘²‡íÌ]m¶â|Ž‚SlÛ–ëƒcµqWÌ,­Ëk‘%§ÃÜl
+;½N¿êw<Ê©6Ùûƒ–9Gãà9èI—t§‚gÐBï_¿U­")Â~¥bEÀ’dÜ·äÓ´b†m…åw›q¢Âÿî2æçÒ¡­äE™¥Ô¯~T>5é%@Ö¡„Ú)”…‚p|£€Á~@YŽU.ôÚùù!FwoÖédÄÃßH^Ãë-ûS3íë‹°•d7žm¤N»ŠÄ¢z,¹AgR}v(YŠûçü.'“ܸ(_åä	’±",dVñdžqמSÍ(ÈZaÖ€Ž‹¼ßeì™="\’¡JêУ‘k
#¼ÛFßµž0›žé‰dvWl
+¸»v ½Ê…éÔÔqKoœâ\¶Ý€×Ÿ0	hïóÚR
+¨T5=š€áÅ
+•½*V^¾º1êrðŒ*
+®é/Š)T,¯}«2lÍ,ʽÆÎ[ÙŸMÕ° Ú~(¤ÞQò«Žã¶ÚœuÁ3°QÑ•×46™›œö¬}Ù6tF-„zôôÏ
+x0Æà K¾'¯g~y÷ý|Ž°ž¡CCëLFRçÔûCx“U2x’ì¤Ú€òzô8i½‚“ÀÀºP &&åËk剺âi-`JÜ&â,¿Ý¦¯˜Á¦¯z‚+Ý°G…˜Ö¬l†0ÏüÜÖ9oHƒT>vüŠ"nC1Ç=ˆ§XØ„?ýËzñŽ7½Ò!·51ضMcÿekxnºÒº1Èv&ÿ%V¯ŒQ¶Ù¾¡cÑ4~€Úgo¡ =;?§‹c6vÖÂ5NCÞ0è+wµ ý¶NùLCª•û‰­r,Ïbj¿ÞÀ×Otm‹yã«÷Q±âm·/SVæK|“D|VïáEV
¯-¢A–×pE¸6¥]“¼á£Êh3–©pD’&ä£Ä
É
+k«ût‹2üWŽÜª|nÈ<~'>m8MUš™Ö²Z†>?nÆšfcBeµvG5?ÛbêÀ:'	ñ”"enërv×Mq(‘¦aíÅýv&…æäüá —<šµWˆ¼üe®vz{óü·ÄÜÓòŽ¦G§IDÃ"b_ÖÍ%ËŒ‚²¢êx‡Ê^‘$Û„ù…üÆy
uÁéQ_p$@ÖU/Èãˆ(w¡id-êl¡å¾kT^{T“¼®‡Z{úUÙ¼|„ÖDEPD#qúC2Ð:ûU–ƒ·™9õ¤Q@ÿº±R`¹õ[Fצ+5Ô9â(T‚$§ï
+K§4xÈÔP¶—ÛÛ‰Õ[û‹ÕÇo›_¶¤uÃwü`@Àr4ýÃ¥Šùâu.Çc^ʈ~¢{ªŽËûb²OÁw}ñx×—`c™ãø?$?q;a—C¸GKÁCÐJ&Ÿò"t¸§'¥=€gh¥Þ¹êýs§H½Q”þ¯ÙN0ViT®I‚ÀRÜ#Š,šõ@¯»Ï„S; —nÑ´„(ÁPþ±Óí'ó±÷t—¢ç©¤ç‹ûø?0õK*`ÁÎöÄË’&8¡ßçöìd„ÌV }¼·Õ0£¢²Ü}çŽ	3ѬÅ@‘Òµ13LëÃAÏNÓó.WN8™œ	`c¥ý
+üm££O<+„ºlMË´p~Mý™[ñ©ø·hÊW·N–&9_	9øÂåÖ ÒgÙ0ª¸Lt»ÈéX+sÿõ„&ûI*ofʸèÊ
/ŒÀÐÀƒÔ[ü"¤}.¸ûæ¥c‘çäß>3D|åOVη}ðî
+(ª4rQ¹!Yzˆ‘Yù_‡u¼‡Ó´Q½Þˆ®¸ËÛÌ«
+|ø2C¸Yƒ~Y¤¬BþLŽË¬ðLÕûvè÷Í	³˜U@âçÖ¾”5Ù¹~ÜCåýŽœ—®‘ë†<…¡ÚÉ¡È„¿;÷Un¹ù¼‡	ã
à™9	ZTêS½D,f¥‘j@xqÒ–iEÐ+ž²J>`ýáìÃÕ´Eñϼœ#ÄñN%€õÐ7°Â9È£¥õqÛ&gÀ¿žZ±è»ØH¶`ßœo+¤fÓxýБ±;KÜ­#õÙËþjí€léŒ.ÊŸj>Ê/4;D±WWÙ}]×èòª„•7]Ô7¾º¢»oÑì2‚â „Tú˶úL‹7ÿ˜C¸¬õ½Êð\¨Âà2@Mdº°ÝµìdS?Ö)pÔe–FãûUöG,·EúÙúlHý“3÷œ†ú xšë
+l^¹C8I‘èe«3ÅA¤Ã¯ðÿØòk¾Z¬nk¢ªh±¡FÃ]ðÙ›·²îtxrJ¼‰Ù¿bo
+d©‘¯l};¥ZòM«yŽÏ‚ÐÛe´Æ;Î÷kßíªêÂ×¢èCsú?êÂr؇VÚýV.K“.ÅÍ"ûUg§ ™áön~	vµ2Ävgè"àÃ\ôAm»)Zÿh”RøÉR¼.|y÷¹'"ˆ*&–ç>™#xr§cm¦Æö0žœn³‘=ǤslF&~k2E«jlþ¬ Ƈf„ÃLbJ&ÆRXc6¦KnÄÎäÖ¹˜O"êûðΕ¦#{äÚª|^3ŨÊ;è44Âr1f5)·g¼_
ì(1%Õ
+rÒŽ½wÂø’>;Slêô‰‘5s¼uÖ²Å#&ëA¬!­ø5çÈÔúÉÂbªªF%.ïîÐ{ãRU©ÉàëNyÐÒ6½/ÚÓNEg“É·Û¯êÏò¼hžNº–Ž¡]Șùj©<}crÑ¥d­!]ìÜÎò>þ
ÞÄ	÷{€m6"ûªùø@P¡S†¸s}'V%ó.£zùˆí]¡I^(ÛùÌ6…–¯ƒÑ|4âsæþ>êYÈ-Ï:´¢Ù2åÁÅs(×±@¢
=}Åæ—U·n6ÈBC¯>Ç!Âû@u=å<²—1i=íÉú=ƒ-¨òZ—ÅM ­Â4÷–@tõJæv‘q½ãû´yç¾vr«Ï„¾VnEø„}j*7Si‹{=‹Áï£!æXàý1±J ='»Ê`W¸îÌÒìì;ïD}Âv-wŒ$ØM0½(ðö¨ÍéM$ÀzCç§ 3ß3XôåB£¼äõÆãêø%Âþˆ¨ÜA£›pP†©¢ª4µ+Ø<¢ÅJõ"S^샽9â@
+°œâ‘1é#V~Ö¤›½hBñ
åùjtw“bsYŸ´5	¬˜ºÿ“,W²ýÖ»X,+'z7ÂàOe~a.!dÊ«+¼˜å¡ñÊVóÎçõîú…*>3 þ»m'¯¼ŽpFTYDº9HÁ†“lPËÁsà–Žý„Ä&ä’ÍåìƒÔ„¶“MÊBW{a
+œây[ƒËu¦YÚr!ƒô$l³Øa£.†þÌGƒaW]èPj©"!w¦k?…Bm$¯œ:#ϯ˜R¡~+Oø0¹`5ÌP(ÅÍé=vÛ
„ú"þÀ‘—Ñî1+…¸Ý¸&ߘ óÚ*-‰Š ”8ÕÐYNÒcŸ˜¾üJìsMQj[F¸‹kzéú¸ä(ŽÀK¹öëÎá½gnä@@m35N-Í˨d²äí«hV]¨Áà^ƒì÷¾­Þ uŸ÷ÚÖ¦k‰-¾·UÉ[~¡‰è%?Ôé·SrJvı}Ñ™¾Ä=3¯rêÅÀØ›uYoaQ•L}F¡©›§ü¡à:Ežir¢,sÊÜ[¸©¿ÄG€ÇàðÿÀï>Â6SGÄT¤®I;@|&ÞHJstÊk=Lig¤5è‰,þm!7ÿîág=ò"Œ
+<uHîPe£C³PÍ2EíäÁ|ËMó«QX³g9(bçŠvà‹÷µ/’TÂèó¹ÂûàEÔ’÷¼¡¿J£ºV]CG ;f¥/ÁàL­÷mˆª©’’ùê#°ð¯¸1¹C‚U=è3TnÌó´sS_vçahîÖ5ImŒ=_²ž‘•9–ãÆ›Öo!|>i÷.T+=a9?wô²ÅùÄ˺éN¡¼‡Q²¡\Ýq.¿³lߣ¯ÚÌMú‘á£óäPêç@lʼnT
+¨JUŠÆ•ý¿Ñu3·àp G„‡ùbÃéÏÝDŒ%çwì´¯ïª9áÌ	ó5SsÕþ†ˆKë†Üœ¼e}Vô™¡)‹$?·,V§¨$Uã½cNùÕTD ½³#éˆF»œ±´Å(EB‰w%È
{|(¬3-I™¢m8W‘r…XÍe«àÞVLL¥Q.*Gõt¹IÚ¯±™^_Ø“’ÚÖÈûR˜Sö «îÒžÿk./·9Ï•ÅyÊo •ÓwÉ×°ïJwYâ‘ϱî¸6eÉÑœEɈeósS}¯E±X8‚ÕË#¤y㼟KuEüì£!o´öUöä”óÏéŽÃZX©¨,M|eÍóÉÝ)ƒ^»D¥?O­Ü]De×a$p*£<Ôu¸-‡•²·HÈÁÉ'.
JØ QíH2³&šÞ–é{IênÊf›êòËŽêõ0]\³Ç¸,Y|egσÜÍ–Ø,’ä¥à¦¥\ÂO°ÌA%hP
ŽmÀÙ3Y'Ä]ÄhÌýð±ÕÞì²›ODPxþõnº”å“]ç7CåÎm gªô÷ËÜÆu“óm‚5	:ª4kíusD󰈪KÀs¢'·»^Rå”XÄ
)>M“£<Áp©E^ˆž+vxE$¶ÆöÕ¸œ eMÁ$	÷Š¡|¨•ùìü–îøÈp¹[䢧ªT«-ĺ	ô{~Êfª~ý
WÑ8æôQT“yi¬W%>ùàw—3+¶ë‡IÕæŒ}'Î
'>š!	^ËÉ´¯ƒT%¼àn=0Z€ÞOi°nŠŒƒÔ'ó'~
+\´)(ät‹hß÷çuÌîÈÕyêáTÅD_.àÞM`¦_}\_i¥ê#k?×ziÓÍà‰Á¼­zñ)90¥7€•ØIgx¶}/b…42Ãö,,ÞÂ…F º¿.8û@ì;{ç)ÛÌtå0q€TmiÈçqW ]œäAr¸»MDfÿ	ùgØ)ñÌ:…KKyÄš×ì´š¢~Ayk¡ŒoN0GŨÝ×KÊ×È¥{_s$~)R1:¤ˆ3Д«mFÍ—"okññÜ9Ì‚ÛGGÚ¦xUJú$KÑó«¨iG_ƒaÌÄBÏq½PN.ÍÅ$€_LÂù t”N#´wýžŸ›22Ö¨\2×S‚eëãžD-çŸö²>æ'hm^–*¸É楌–â•pTˆe˜$O‡È¼h¡¥Øïn÷­/Áélh÷#Ú§Ù'‹_j>I3õ Œon—2­…•uÛZãàIöË?!φGb…!AL:e¦_K]ø:†ŠèjçË>šá¥áœÉ0m*Ž%ó@¶‘pÑ‹ÈȯGÆÓósÀ'ʉ“¼ÄÞé½îÂséÞ]–`&ÁfLÏZÒ–ÂHiMj?DÆÜmúýXáŽé¡›Ð†ú‰–òA˜¥½ˆV½£úÅÓ9mYcYR&•»u0º? ï¶gŒ!¬ûRÒ-Ü´¢ç	ÔK†›Ìm4°n¡MÒùââ0àí‰?\âùU¾`ßèÊ÷»#8^Ú¾ö¢]Bkd>•Iל6‹}¤(P¨˜ Í{<Í=:EÃÒuæ@ª€^o­ÔÑngrj©æ¯c†ÁØU®-½ç©¾Û½é0ÑB—ÏÖ“Búu;%™€€òx¨K
+(Ñ-ì@¹ÀËq²<Þl™xüú0·¨gOyP} Å¥\’`ÀxªÃÆ°6‹9)ü<»^íéîä>ƒ@1è¥ôk5 ê¥5a*ìH¹4}YÕ	#|ÿ§¦}ý68w…Ëj*6Ã㸟QmŽECÁ¬œ“§ÄƒOoül“³æoC’rR>s”Ù°ký“Xâ²Tþ--i»ê‘7`ù`/N…›'¶1	h<þS°=xÇ4î×ÚT¡ëÛÇÍs=@· 1~_¶ý)î;ÎnoŸ*CHÖÏÄÒú`^¨VY©êKŒ·€’ÃN±ÍÉÿ£†-$Û:5š›B§>™ÌwÍ?|4ã­ybÅù]r¶?*Ã~›ÃYþéÑÔµŠ\—ÕÞ$£³ÿdEŒmÒ+rrµÿÝ%Ó-7Öœ¬œC°3³ÞϽ¤?6*w‡˜¶´(¨2	½79M\']ŒÅy¬!oýÐü@­>!‰«ª`Ôãñsÿ73Öí9Ûòl’bk0ªLW3NžU¶¦õ‰»äN
×ãħ;©ÐdÛY%ù“ˆ\à 
+qÒ¸#q¹àÞMn¢¾ƒ†ÇU­ÛòAö5	îQ¤±£-•²x^€’ÙtÉ¥óçw¸_Ü ý‡ýZ;Ô4ò#qó)ùtƒ/UåÐnp©á„Ͷ5ž‚B²W ÎQÝNk›‹v<§sïU'¦J*"Ñx«xóoŽú¡…ÁÇ••×ÕqƧÇãç‘œ^¬³“RöéEhæå)ôd6ºØ¦Nr?â¿®¼Ä½`„ˆÇÐS#£‹c†MéáßÞÀ>RÝNf¹h}ù)æ_Èt€½-n™ùò‘»]Àbà8¸GRª*XÉ($ÛkrJ0•ªa{yp!—&"8ݪ÷[¶‘¶ß7Ã=Èg<–u´”Ù¶9íA8sŸe[Ô¡yW•ƒ]ǽA¨CÁFT®[Ñ…‹n$ÏEž'h¼§ÝîÌ-±ß¡ z?-ø±fòoù¾ÜrûªÍf?.Q‰‚Z:ÄDJkLÐ…îš™§^ŒŽÍà.ˆÅ
)!6pÄo
pe„¨t2Ò á²÷…›dx5ýz5r%{fç‚ù¾Mú¬8×øù`•Ã¹¾ÛTH¶Ä+£Þ7'QÏ`õ0B2»¯JHòëDv<D±«LV5_·í:©”Úéò>Êis¯êe_ÿò¹@Êr¸Î©ª5¿ç%o•é­úÎnSuÈÔˆ	YÓVQõ>>A6Š*ÑmËîñà¿âz8²ù,Î:åÎP8¨ÂfŽ[£Ù`ìœâqMÇZ6ßÎv1S,Õzùh%¼(/Ú«Ìr^¬=ºÈ…1hàö-‰#€Œ„nóZp{{€™di<¤MCå Õ³”™¹pW”íùCúÿÿO˜ÛM]ìMm‘þÄh–gendstream
 endobj
 967 0 obj <<
 /Type /Font
@@ -8945,14 +8921,14 @@ endobj
 /FirstChar 34
 /LastChar 122
 /Widths 1949 0 R
-/BaseFont /UJMFYR+NimbusMonL-ReguObli
+/BaseFont /OIHBVT+NimbusMonL-ReguObli
 /FontDescriptor 965 0 R
 >> endobj
 965 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /UJMFYR+NimbusMonL-ReguObli
+/FontName /OIHBVT+NimbusMonL-ReguObli
 /ItalicAngle -12
 /StemV 43
 /XHeight 426
@@ -8974,7 +8950,7 @@ endobj
 stream
 xÚ¬¸c”å_“%œ¶í¼iÛª´mÛ¶³Ò6+mÛÎJÛ¶ÍJ[oýŸgº{V¿ói¦?ܵ~'"ÎŽ±ãœuÖ%#RP¦4±72³·s¡c¢gäÈYÚ¹:ËÚÛÉÐ	ÙÛ˜þÙ`ÈÈ„L
],ííD]L¹ê¦&Sc33€‰‹‹† lïàédiná TUR§¢¡¡ý/Ë?!#ÏÿðüÝélin ÿûáfjcï`kjçòâÿz£²©)ÀÅÂ`fic
 –WД”PŠË©ÄMíLm
-®F6–ÆKcS;gS*€™½Àæ߀±½‰å?¥9ÓÿÅtœL-ÿn3õ06uøÇEp0u²µtvþû
°t˜;Ú¹üí‹=ÀÒÎØÆÕäíföÿ"äàdÿ7Âö¯ï/˜‚½³‹³±“¥ƒàoV±ót±0tù'·³å_7ÀÞìo¤‰½±ë?%ýË÷æ¯×ÅÐÒÎàbêáòO.#S€‰¥³ƒ¡çßÜÁœ,ÿEÃÕÙÒÎü¿ÐœLÍ
LlLÿÂüÅþ§;ÿU'à«ÞÐÁÁÆó_»íÿõŸ,]œMmÌèa˜˜ÿæ4vù›ÛÜÒ†áŸA‘´3³01þÛnâêð>7S§5ˆòŸ™¡úKÂÐÄÞÎÆ`bjà gïò7%€òÿNeúÿ9‘ÿ$þøDÞÿ7qÿ»FÿÛ!þ=ÏÿZÌÕÆFÎÐöïüû‚ü½aì2€î˜ÿ_¬¡­¥çÿ!ú¿ª›þ›áÿ	DÒÅðoíÌÿJÁHÏøo£¥³˜¥‡©‰‚¥‹±ÀÌÐæoþeWµ31u²±´3ý«å¿Ú cbdüo>Kck»šÎöo—©ÉgþWžñf“’”¤ùï·é¿¢þªî¢âéð—ØÿªCÖÞä?ÿ`	Ù{¼éXYtÌœvN&'ÓÏÿC¶Á0ý×ZÖÐÅÉÒ ý·dF¦þ¿~ÿµÒýo0¢vÆö&ÿL‰²‹¡ÉßÁúOÃ?ncW'§¿zþë¬ÿ-ø?ÖÿqSSSc˜µe{cž`«´Ìt—:ÌÜáIíþ^&Ðá‡ÒF•¢ÿû¿´ð]®JƒÚú¦iî¯vÏ¥s‡ÏC)ê£Ñ^Šž_¦òñ~’Põ o‘wrÐ2è•Â§_¨G{_/Êì€i±3ªíM**é•|@àOw²8A]?Sù“¸ø£‘>9 ø§6Ä¡w!5¡Ôž_'>?QŽõÜ‚÷âÒäÄA“ñ¸Á“Gù;æàòk©VzGP/gŒOÚ`\0š÷Kr>`°o„3…ólU»ÿüƒyw*¯;b¯8LäziíäØ—4×ë3˜Ø¹ÐdFþ›è®ºóM<éÚUê\oé”Ï#/
Îl¹n8FÒ-"&»//Øfàä)†w·tIHb"”)èwàu„ÜgV²Ú™ƒ*¥
šìy#E¤Û7R$Ïî¾t®ª_ô°e¨lYèu>.Kg¡±DæçÈéóxe>[·ÝAêä¸ôž_%]âªîCOÁA¢]G1ÂJêÔÇ<ʾÝÇ/F‹#J5‡¼@S=ó#nÚ¨º†¦@å4з='ÉKÞµ%`©H8»hWå÷ÅùQÙæaxìr‚TkÙÍy7Žy)oö‚¾Öë˜êÿ°´«sÓc¶wúü8ü
+®F6–ÆKcS;gS*€™½Àæ߀±½‰å?¥9ÓÿÅtœL-ÿn3õ06uøÇEp0u²µtvþû
°t˜;Ú¹üí‹=ÀÒÎØÆÕäíföÿ"äàdÿ7Âö¯ï/˜‚½³‹³±“¥ƒàoV±ót±0tù'·³å_7ÀÞìo¤‰½±ë?%ýË÷æ¯×ÅÐÒÎàbêáòO.#S€‰¥³ƒ¡çßÜÁœ,ÿEÃÕÙÒÎü¿ÐœLÍ
LlLÿÂüÅþ§;ÿU'à«ÞÐÁÁÆó_»íÿõŸ,]œMmÌèa˜˜ÿæ4vù›ÛÜÒ†áŸA‘´3³01þÛnâêð>7S§5ˆòŸ™¡úKÂÐÄÞÎÆ`bjà gïò7%€òÿNeúÿ9‘ÿ$þøDÞÿ7qÿ»FÿÛ!þ=ÏÿZÌÕÆFÎÐöïüû‚ü½aì2€î˜ÿ_¬¡­¥çÿ!ú¿ª›þ›áÿ	DÒÅðoíÌÿJÁHÏøo£¥³˜¥‡©‰‚¥‹±ÀÌÐæoþeWµ31u²±´3ý«å¿Ú cbdüo>Kck»šÎöo—©ÉgþWžñfPPPS¢ùï·é¿¢þªî¢âéð—ØÿªCÖÞä?ÿ`	Ù{¼éXYtÌœvN&'ÓÏÿC¶Á0ý×ZÖÐÅÉÒ ý·dF¦þ¿~ÿµÒýo0¢vÆö&ÿL‰²‹¡ÉßÁúOÃ?ncW'§¿zþë¬ÿ-ø?ÖÿqSSSc˜µe{cž`«´Ìt—:ÌÜáIíþ^&Ðá‡ÒF•¢ÿû¿´ð]®JƒÚú¦iî¯vÏ¥s‡ÏC)ê£Ñ^Šž_¦òñ~’Põ o‘wrÐ2è•Â§_¨G{_/Êì€i±3ªíM**é•|@àOw²8A]?Sù“¸ø£‘>9 ø§6Ä¡w!5¡Ôž_'>?QŽõÜ‚÷âÒäÄA“ñ¸Á“Gù;æàòk©VzGP/gŒOÚ`\0š÷Kr>`°o„3…ólU»ÿüƒyw*¯;b¯8LäziíäØ—4×ë3˜Ø¹ÐdFþ›è®ºóM<éÚUê\oé”Ï#/
Îl¹n8FÒ-"&»//Øfàä)†w·tIHb"”)èwàu„ÜgV²Ú™ƒ*¥
šìy#E¤Û7R$Ïî¾t®ª_ô°e¨lYèu>.Kg¡±DæçÈéóxe>[·ÝAêä¸ôž_%]âªîCOÁA¢]G1ÂJêÔÇ<ʾÝÇ/F‹#J5‡¼@S=ó#nÚ¨º†¦@å4з='ÉKÞµ%`©H8»hWå÷ÅùQÙæaxìr‚TkÙÍy7Žy)oö‚¾Öë˜êÿ°´«sÓc¶wúü8ü
 …$ØVW˃÷æ¹)Àõá}@Jš2»œœ$~P–D™ˆ‡…:Nq©ó#5ßì"	󧈼ˆÎQ僶J–©Èµôc“Êç؉/Wñýê›X²˜HO÷|¬®-“[ÿƒn2ç¡‚÷`ŒàõÉùKH}&¢~t–ßêÆ“-µZ•÷ÎäÒàMV]ÓYÚñ‰‘06Îó'ˬy?‚²9¼oºÝ²Ï—YzÉA€&s5õC`ýnXÙ°ðõɃ
í’D,÷gÚUÑ{MX8“Ž_ZœìÊø)“bzlS âz/ˆPr m¤–ÕýŒø86
]¬
 +½ÄGL~Ö§æ0GW˜RS4Œ–¢V˜,ŠÈZzU¨âè(ŠcÆÀXÙˆ-jà±*ç+êJ"ÈhZåðIƒ ïŒ
œƒŠñ]Ñîç/µÜhà÷ šEh3ŸiqÌVHXn´Nx-ÿQ9ƒ]ne£(‰ßU;aXSû¦Ÿæ¿rçG.môú¥»ÁÊ|a™â¡^>#þ»ˆ^驵]M»qÁO>Z6Úl ¯=µ)¢_¬¾rÔ—!U;:±å$z2»?Ô?÷,|gP¨Ö:`ÌG*p²Sí»Ï³œ.ÞJ;"8çÉK­ñs·Ìúe”%±¶ Ü-.EÊ’JÿLئh·ý,hïY«M÷s<ùi“©Ò£úþÕ›j2žE)mœÀî;Ÿ¡å×)× ÄãÜùšë_`Âý܃4¨G³0 œ{¢zÀñ®yÑ C‰ÁŸèP!“2Ž¨Ÿ*§_‹Z夻'ªá¯›ò
=2ç#µõ-»Œ(…’jáô˜iÜS$JbðuÓmË~~*öÓØ	q¦©ãÇ\EʧÉi"—ÌIG(ANë&ò²z.…ôû½S0ûÁÜ	^2¡2.|,†Î”HøF°ˆ‰DºFjEàÃì´791-ß¼vÝÜãßá‚3 bõȨÂ;÷Sù¥ŽpD:••û1ºµ	÷N¡¯Âv¿•€»‡ßЋ“f¢
 éèóQ.ž¾,Èv‹®Ç'Ÿ¤Îûz5+Éí.þÇÌHF.'_6®DWeN‡´¦j×I*92RÖ¾Ø.}ùÚu¯c†ß±©ŸoL¼`Åa\¯²ZÕãLƒÒË+-(þÍHUëO˵Íè|ºZÖe±šÜ.¢{sN"p6¨Wvg‘¨ÚTzVóeÿºŠÉßDbþ}fìkGa<ÊaÆ#sSs&ÓçQ‹Ö:“m€¦ý)®ý]ѺΈ¼ÂP€œ_—ÁJîY*ùEÇd@–NËoÀ*EëgšþÐ*Eì/5³jð»|ªPu?
<º…ÖË´u½²óÁјq½7Ú»ÝÎꀻüu-1ožÉΤåAúE¨÷ŸÚs,ªî_àboîT°q
ÏŠö‰Ï`ˆÇÉ•ž™î*å#çu=X„<ð0¾L…Çýü=ÊÔÛ`’õ’WVà´“ÁŠ™íGIòêY“ÚÎÝ&•>6è¾ä$‰N©Å¥`4E¾¥[?™…ŸŒ"STï,R2.
ħböMÒÓ£ªZàÉÃ9/	e”õ[ªgð/
@@ -9040,7 +9016,7 @@ r_
 WBˆuÀB="÷Mª†ß|j¤E˜&µ»“=W¸õNtéÁ¶5dPGŽj¿wj‡Sy®¾"‘Ê UW#¡4‚0‡©¸¿ô3‚´RÅÒ]ʽM§ù
Z–T‹0ž0Å•$í£[É‹Ícãu1ÞeEpv¡„(©šóˆí濸A·Â’ò·äûtô±(s¦“Fi2Åx\èE(×(9Å?UËÇ|O½¤2o{¸¯}a£ˆ²zŸ–δ€R"ô¥²¶‡ÀØßš)ë*m ôDs§úä}á·D
 À€èö}»!Xö&#’Qƒ÷ÄQo”Cþ¸G
FòñͳH³3ànGZ(ÎF_¯AYÔ%õˆøcŸ=ß0ßpMv¨ú¶Lbã1†ŽêÁ³†L	*öVt°Áëh-½m—œ(<ÊxSæN£X»œ$ÚÛع4›ŒbŸ…±´þÂÞ±Üã‹eõ”~ð^•ËÄ·¹©ëPXƼŒð;ö2nµ *’ç#i¥¥ÈÇNÚÝü…+3÷3ÌÌ^ët]XW¨²¸DLèi[Ó8OÛþ>M6¬˜NJ3ÆzU1nç€6QÐ19‹—Û¥ŒPÖáZvõ'P¶—YãšUrAIîžÅÅ€1›MejùzV+ÕÖù7¤¯¼/E^;æ{/ZÀHgâ×j\œÿ+jÚ¹U7ÿ1œ6Þõ‡cuªæ®öèT8ÀõÅXý]¿0Ô¦‹Y‡½ZybÅvë$n§ýõ£±#ù2 [*ÃwÅYårÄ9V@»”d5ÙKˆÙ"ûº°yóv	ƒ®'XiH!ó á3wIykÿ#J÷lÒ<¦s(sUø®û¤Tð|á:/pœs§Ô ëP’–<ˆrÞbL|}ä’0ω´üûÿÛÏgÌ_ögk=úÚú¥¯®®‚_{íÜíÿíü®Ò§à1ñƽœ[.I$Þhè
 ¶Ù½äÝîØðmŽR/´Ï8e°ûœ“|ñîëszC<’^'¬üš~xõ¹l­SÒ|úcä',ü~Ç+L`áƒm¡à¸Ô›;ΘÍfyüØbÏþ9%¼Wû^š¦ù¬ãFáuž©ªcMŸîVÿšW:áõdÝÂ}L“âÝK?ϼ|BóÂú–UvÞ•‹w|›&óyvÓê—šß²CÙvOË*|ð(-´zé>û‚Û\y–'$*·ñóÓÌ¿åÌoßoßîËÇ6Éý¯ÝI)–ö÷]³=ž+·ô»@siÿ–R¿‹Âs2š5ª¹rwö¤˜q	-¨
-¸wëB€tIÉ>NÖÃïÚ&ÇÚ4ä†11>Ú"³OzÓúv«_§ö°÷ßâW3ïý¿”é–7Òv(/z¼`ÖrËm_姷´—+vÙW²ÅÔfîK0庡û×2,¾ÝÜùÞºsÞÙÕ÷ïíK;b÷Ž9]„m/—èϵÏê7~ùp&,kÚÖŽ óKâ>„(vú^K¿{uYMd«WT~Ë5Û/Í}(ïÜnXªÃYÖðíÆ™þÙ®%|´<þ¯ÁuJx´nÎÖ×Þqr%M=6åŠÚ3ÆY·=4k<±;äã­ÿ]ßµâÜÙ“ŽI¢Éÿ­C—̈0Ø¢•–óñ‹õáü.Óëœùv%ÍÙÐ8³÷ eYU›ï&™·µg#žÝò¾ËuÉ5€Ã¤QÝ€BÀ5jÀ°0 9'5±¨$?7±(›k,x­endstream
+¸wëB€tIÉ>NÖÃïÚ&ÇÚ4ä†11>Ú"³OzÓúv«_§ö°÷ßâW3ïý¿”é–7Òv(/z¼`ÖrËm_姷´—+vÙW²ÅÔfîK0庡û×2,¾ÝÜùÞºsÞÙÕ÷ïíK;b÷Ž9]„m/—èϵÏê7~ùp&,kÚÖŽ óKâ>„(vú^K¿{uYMd«WT~Ë5Û/Í}(ïÜnXªÃYÖðíÆ™þÙ®%|´<þ¯ÁuJx´nÎÖ×Þqr%M=6åŠÚ3ÆY·=4k<±;äã­ÿ]ßµâÜÙ“ŽI¢Éÿ­C—̈0Ø¢•–óñ‹õáü.Óëœùv%ÍÙÐ8³÷ eYU›ï&™·µg#žÝò¾ËuÉ5€Ã¤QÝ€BÀ5jÀ°0 9'5±¨$?7±(›C¾xËendstream
 endobj
 890 0 obj <<
 /Type /Font
@@ -9049,14 +9025,14 @@ endobj
 /FirstChar 34
 /LastChar 125
 /Widths 1950 0 R
-/BaseFont /NLBIIA+NimbusMonL-Bold
+/BaseFont /PPUFPB+NimbusMonL-Bold
 /FontDescriptor 888 0 R
 >> endobj
 888 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /NLBIIA+NimbusMonL-Bold
+/FontName /PPUFPB+NimbusMonL-Bold
 /ItalicAngle 0
 /StemV 101
 /XHeight 439
@@ -9072,85 +9048,93 @@ endobj
 /Length1 1620
 /Length2 20127
 /Length3 532
-/Length 21035     
-/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ÖÆYc ­`jç°þ÷`lgkbñOkNŒ¹„†'{ ±Åß0 ›1Ðþˆ`t´±prúû°p˜9Ú‚þÎd°°5¶v6ù§€¿vS»dïh÷×Ãæ/ö—LÑÎ	ädìhaüͪ(&ñï:A憠r;Yü…v¦=MìŒÿié_Ø_š¿(ÈÐÂÖ	ºþÉe˜X8Ù[ºÿÍý—ÌÞÑâ_e8;YØšýWôG ™¡£‰5ÐÉé/Í_î¦ó_}þ—î
íí­Ýÿm÷/¯ÿ¬Áä´6eD`ùö7§1èon3[¦¶Š”­©€…ùßvgûÿÀ\€Žÿõ?{†æo†&v¶Öî )“¼èoJõÿÊŒÿs"ÿHü?"ðÿˆ¼ÿoâþwþ—Cüÿzžÿ;µ„³µµ¼¡
ð_A€ÿ¸c²€.ãÿÍÝÐÆÂÚýÿðß=5€ÿ®RhælmèøßáÓÛšýU„›‘ýßV'	7 ‰¢ÈØ`jhýwVÿ²«Ùš­-l5ý×8,ÌÌÿ
S5·0¶²ýgøìÿ†€¶&ÿ½ü¿2ý«x&e
YYºÿý^ý—Ÿâ_ýAªîö@ÀÿŸDCÎÎä?ÿ°ˆˆØ¹<X8™¬ÌìÝ߃ÇÍÆâýÈø/"–ÿZË‚-ÜÚÌŒÌÌ,€¿ßÿñù¯•î£·5¶3ùgǨ€mMþn²ÿ4ü;;:þÕö_çþoÓÿ±þ×vÝ€Æë+vƼA–i™é :ÜÜ‘)1í>È‘`ûÒFÕ¢¿»^ß´°]îJƒÚ`ƦžßíîËçöŸ‡Ò´Gc}8ÖT½)Àë|"o
-šþô­¯œtGLz¥ÈéQž7K²;P?8˜Õö¦””õJ>`ˆg:Yánžiü(\
-ü°¾<Ù£ø§6Äbw¡5aÔž_|M<}~¢î½…î?$¤Ë‰…§äuBþéçC(øC­B¼ªùÕi{Ju¡glŸÏÏìC(»ƒ¢ÈbÓËZÁçjð§fÌÁpC@¶VBjä+s^"ò“£œŸpÖj×Ñm¡HNZ¬¹Šù—;Ão{ô«OŠ—©š}¾ŽÈïqM gÀÁõ@‰Î
-vÌó_ŸäsýðKÞ`zŒ—6$Aïܪ“³ÖUªÔ¼qTÉŒ!ÝNë”›Å/˜4ú#pöpò>ÙMBˆÁrêM<õlb®‚‡é‹à\jÑhŽ!··qèš–í:—…u>5±“ª——‡³›G¿:×MÎ{òεÁéKœJC·Ò@µ¾/)qpgŸ”­µí‚ ¨•Šgý´»Û]^ÕÞƒÛ1Ü ½û߬Dþµß™á…°ä]xŠ©9ØhNT:™~«„r…7Ôè¯ArÒx‹'£º줔(IÖR×Äf*®•5`™xZi”çe™•Vê]è®tßó ¦@ßë¨ÖŸ :º·WH’gå Îãí;g¡ÎÞqQþ6ÿ*<È8Ô²nir{:^2‘@àcÆÃLˆ&º¢a™³SûI˜ ¡NÕÊÁãɤðÛeã‘[‹}­H}öA÷4OöÖgí
-„7N•{œP¾©3¹¥Œ/Ä[Ö]ªp­Cƒ’½f±eB8|*ÿá´%Q0d’hyŽÏË9€œH7þ5'i}=½ó{LXwÜëaä6Aº„ï5Ëo7F—Aµbñ#¹‰…O[?ˆny=¯7…³¾ÏÆ_žMSÑÓ<Ÿj²¹O-ÄËOrlºÈ|!•¡ÀºüV„,y©+¥,ßê¹2š_Sûà£#üåž·${qÛF2<üm=àmûS}ü{/°¥ÖÌ:i­‚ƒ‹\’³¦ææŒ"×îS©ÄÙM>?gЀñ¤kMí!,£sê-Ð@‘œm.êÎ@ušltÚŽ£{±/¦£¢a?©8AŽ°KjðæêBQù–‹Mør“J­õ¡F7ÇET¤tVÂÌ''¿3ÉØn¦»3=æܽ‰(®!að5÷åñŠ&'×ì
®n612"à8F•–²£
_;Ù¦kžO„ÝÓjwX	í¨FVfzÙâ1ÖãðÆé›­iàRQKzó€ü§$·+,o@rÂð*šAnú³,½,¶¹}ºeÄ)ywÉG~­(JYœ…Gåy T0}O7&·wŠÖŸ D©ÓÙé@ê±=Iµ~½sŽè#"Jk6ÿ´µªt‰`úb˜B½”ÿ}FžÎå”ê¡scÆ_»K3B|=iLõ÷*öY/È×d@OÏ9FÔ•Îk…&÷;®/Þ¯/]ÁH}ÄËg•ëYnq¿C…å#!èkšž®¸B<.›/æǤ¯çXd\ºiÐØñ-z+ŠÉ¥KHõQ´ h¦ÿFÏÀÁÕØ
wˆÇÕµÊÉàŽÌ–$^?Bäu):pãuÖêShÏ©ÏUbŸ¼ƒMÝ(¶&gPð	\`{$¾ɦc¢¹Ýà%_
µæ”¼:ËÔiÏ¿J”­¶¸•#HÆÌ)o=A¨|iÃHo5¦x8ûÕ¬¹Ùî?[8V=—¦­Mº.ïS`Ç¿%¼à%¨âÙÞëju¦JÕs¦þð²=ö–ÒkŒVH‹CÁVÑ"¯•›ˆøKŒÉúÖxÞfªxkžv7`­ÄJmœ,™iì‹—³é éM|ó‚X2<».Íhì¾0úd²n¬ØÕ ŽgÈ-KÇkenI`sã\ãQ
-ï™°H¯Ñq<)XÍe.vUÀŒ‹Ææ6¼j÷(OóÈŠ¨ð"AÏ@ä_ÞžX$#–alxUeh[fdþ.Þ_lÔæ8-®(˜ÙÉë¾—©)ZóÕŸÐ-Ž¡ÀULµîu!lIã$)ùºI@ÂÁA5ØÀ4“î¬Y’ËËŒÞòQ€!I…ó
-Ôû´Þܼõz2‹÷¤#‚JÇ_N‚aºäYCÏ>\z…„–gĈÏs³Ìjd¨¦!X¸ˆÓwÜ2mö8Ùp!os´C?yTÿ@[Qc×Üÿq…ÒŽ¥Á=5(æΡm³×	ÔIìÑ/Ôa1VGKj]Ø w´Ú}oä¿8A#çÁ°\SêœM,ZkyÀºHí(¨ ·³ÔŠSñçöš]MC~ÌTŸÜ¤Pg}÷p€‡€
J¥'Þ fØ‘Vý"‡øíbÇdsªÝë~£vz-t±~ŸU²ôn5\±ìÕµIýS«Uÿ	>¢KóHšÃmµ[»nKYݼ øËÈ|(ÚÍs@w³™ >sϽ°V…–šü	®ÙÞÇ+×Xª‰‘†€9õUW«K8†?é
`(zšŒÜ›×Io_eîÁ‘Í>&p×$ÏoLòŠJß´/õý…›R-“ÃOÃÄ,Á‰ þØFáÒÓýâùu.Í­Ž©X€²£ÝF:ûL@¥å߸‰+¸CVçD§›î$2ܘ±­¤‚Tô¦:‡4Oòü?ŒÙì7ØC*™VBÆò6Vjó­šÛ¾§
÷fÝÆ1÷ídž
¿ô|ÒÞÞ@OBG	À§˜«T ˜Ã1=Úuø1&\ÛTĉº(Ð64Ï›§¼ì¥—¿ž6ÇnÚ4~ÆcÅÛ[zFbÆ’RJ»žƒ.¶¡ÖkŽãÃÞDþÈÉ+GâzƒîÔ¹m_C|øþ0/–­Xµ³-`_1+Rå¬Ë¸ƒðžM*&`*ó|ÜTF-ò\<óãT¢Щ› 7³Âý7GÓ\[C2Öb”Ÿ‘„fÊPš{í›ÔW‹Ìà±(B(¾\íɵ^*L²€N8)”póiÿ *aG„ò7(…ÛŸòŽUvÝ9ÝÛ”NŽri$!誨’«¼Ž×ãý±"ðníyæñàg±ë?ϳ· ÓøÖ8Zj"kô䓆üùàÆUb´r¤|Ù÷̓ÌÛ­ç,¤p†é÷ƒ³ÍÚ…ïßý«½	>õz´ø#㉸Pb¦ÝÝ7K"*t²[ÝqýXÁ2¢?Ù®Î>¿cQµôÄ	
-³ì$"½ƒd"<Ò-דº!ú!áŒI™o‚öé­•“0óV;q„¿kù ÚAƱç!²‡Í¹iÉ—?E«\6ï•qV½w8á’Ž_ö3—‘¡DÏ	RöpÓd‡á~.ÖàËR“Eû?ø¿±ó­šK1Ã
-v¿»1	ëæƒÙ(ˆ¼JCü
-à+N‰Ø5ÚNjÔÐY›€¨áàݵiï+Zf;ˆ?Çåe³ÙvWà·kŸÒÅüµ—¢I¹ë´“F4{½*-5	…)2x¤iÎ#§·5ž.‰©sVñº^ñ¼ëÓýªÀ›`õVÙÅ¢UR¸¼ûpœ“åæ41$ûFÐ8ªŸ8lV{v”ƒîÞw©³î~¯ìýý«&À꾃~èôÓEKå½ây­
Dj”¹÷-vá'†H=~€Œøä“þܦð!UMÌÆ‚qzÝKs"œÏòçžNIZÇ&s™/í}‡•‚ðQE´¶åï¼1àE˜»×AÖö¹›€Ú8!ZŒ%©u4¶7×)-¹¢þxÏÌŠi#Ò},V{ 3ê™Lk0Ûd±À1èÙýåÇN@ˆñ€ÖXzdöi¢ð»†¢”YµÇÙ¹þÕ‚ÅmË.»ÎÅ)6>NSã"jú¦HËèË­LnE™ƒ¦üÂKh°ï_ŽÆˆ\RÙßC*  5¦
T(´eLjÔ9úÞÓ…eñrWtA…¤ÙlõtŽcKª¿ÔL©ÓšïÃÍCm á‚cÆó7ªÓû:³HAÁÏÑ×$k!å8Õ#[;mñW¨$¥„ÊQã]T”PpÎÊ©j0)¤p)8H‹Ûä—4ÞÌd9ãYVä]mze;ûµª.ò+ÜôÖƼ9+C­…ŒµÍ7ÈÀaÀõñú%B{PçÑó²ŒG>¦ï\8ÞÓ>\ùë
-¾07ÙtîRÝçP{myZí2÷<ijœçâzxÒô£'2ºñÉþD–£,9tÞ±¾vR§ðSpCŠ%è²³O»¢‘χæhÇeUfL†öH)”éßѦ"¥2¦TVÞ¤Vx/>’^Ž³Š$pEÚŸºþ<˜÷|š‡+œüäî˜jlJ¢ÂKiMù	éÝÙ—áø~‰Ò!ÖQ‡ü{Ç´ûô"¹HПc!v©+2é5ÍlqJ®‚MÏWàï3hŸsÞ:®ÕýT‡1›ãð1QâÑ?nÑa»A› ²¨ÍÜf§”RéTø§qÉíæÛ·>Åé™*QÕŠú™Égš¾p¸ãù€ß°L£¥ÍùŒ„Ê«˜½HÔvN„4'F­Ÿ_?jw­í€ë`Dz?ú¾É¤‡ªŸ}¯?]{•jåqL®tsµN!CPóÅñ5ˆÃ·Ì|Ïå~º0È žÕ	iê“Ojh¤Jb§
=¯ÉŒÕÿ;Ñõ¥efÚU»oÕŠþ-gì©Ù¯–Ï‚ƒ‡ÐhèCÌÖ¼Á‹Xž
0Kvî5möAœáÅ\AW*£PôŒ~é_rqúõ§EÓ<ÕÔCvCX±
¸q`3'¹¤­„{èF°–$õh\..‡ ¤õc½ÑŒ â†Ù]ÖÛi ¹ýhIèuü–¶ô#”;üÌÎl²k¾HSEb0pßÂéôÈUÖùz¶ˆ~ë>
-º.F5|EKÖ_kßU­†Ä&“ó"÷•€äûdÎ…#æ›5åØK"20¬.Fí¢Jà(2\࢚z~"‚*X¸×”•›¹-=‰Œ!‹2ZK
…‹3…~`ÊòJ&qðmvpˆ;¢¬¬Õ¼}ÜtЈD½N¸Q/pÏÐ@Øy)diDÿD¡L"Y^ßî/;>Ìûjö‚cÊP;É)>¡ˆD‚qL¢‘hF‡\§›:ÄzPªÂK
b÷{Ž:bÌ_ÊúDÓýx©4—wB<ÂhESUÈyè,ºf=°jŦc³Ûb¤€™×Nx”ØBÞ.Ô¿œÃóoRKŽNMðͱŒNpt
ØA¬¡âϹùèÓAØûElÞn_V~MTÈüð
-ÛIX¨_QW:ÿµ
]úÐÀï9Lœ`]fd„ú1ØñœÖʨó™¢r
-EþØÜlgøÕ_:jûìe‚¡¡¬¯	3"=%…m7áûìç‚=~WéFF× 4"K¬³DÜ'ªÑ?¶úï…nÞüú
-M
q‚8IoÜ•ªÅö›ÍL-Ô…`€ToÞ½*Pvz:N“x›ÝžÜ™3*IŸeÀ4µô
-;S9Á%]9Ao¢ÁN©‡’p6/€ôJš6:7õ"élÈ2îqœÞ܃A«ñ)Û«Â!F—?+Íõ­ÙV³d$7ÁÌ&áýWW(Þg0 ÎÜ#Úž8¤;ßJì­¯ý‰Ù¡L¹ŒÙOÝ5oYÖá˜
-AÒà}…a™5‚>ÂÃNFØX4²–€žÞri¸™½‹…:'é‹NÎXªËQ±lC#Ë4’w‰ùŸÈ>ßOºÒLZx¯dTH‘™‡Ø*:ÑP=@[›CQƒi«m®þ²´!
-ÚÕìΨWtŠã?oAZdævò6I›¼)’þ‰èRUÛÌ(Á@Ú”µ²âa»¦Ð£ñ	Ûå²ÛšÖ/ì¬ý&Å%é¾ACF÷êÏa¶šƒ;öùZjûâÛQBÙ„ãljÎYIN«ä…{Ïy|—hX®t²RML‡WK&q¨aEPjÍ–_ê›Í2ÒÙmYL¡£Ý§ÎŒrêgsÓ¯NãÚ‹+A׃²„7g¨ëÞÊN óké…%¦~aÝ–o¥­~F¼».û#3{9D«Áä1;â´æÍôQôÃZÏú8w&_a†¶j¡ã÷q ´r©>Ý}~9ÃQ‡“¹ýñQËöš‚¸¸ÅÒRß
-nº_Ø;úáW„ZÏ(œd ÆÅÕ>¤õ„‹ÁêÍ¢*qöŒ‚#röwQ;£œjÚÆ^kNÿyŠÕzÁ	tjY×rCD[")Q’£#˜Øn]Ìcõ(ð(»CÈ=g}¶F`³k940Œܧk¤ÿe:ä#_tRáYL©£½N‡íAKZ'	KLH§£tvH¶ÐSÑe6óSò<ø]©k>¿2 GÇNê#u0UóQŽÅÕòK»/ó<'\`ÛyæÒ5êLZ íèÄn™çšz‹ˆÆL²˜)ÏvŒX¡[M5þÉž„¤´‚o®HõÌLg‡œQäzä<¸±5î6Ýc²±ï.U¨vÉM{bUWåL¼Ù¾Î,mxÙ*û+‚ikX‚â{uõ<„NZ'8ƒ,T¥~Xè%{2Ñ/f>[µª¦Dîïö|Ý¡±šöœ©.q´Ÿ›l¢”„AMãSæKæí3r,ÁãZ<Ë›¬ïám)œ+h¯zìÏa~¥^Ø‹Yºxà½M67­
-}¾Q@°ë_Â!¡nÒ
q£^c7Nh?–Dbk]z‘Zøù·Íà[ÛX=mÅ›P
:žž‰ÍW½G°tC#<áß×VÂ'¦ŠÒyÞÄ1ò\ðÎòˆ¿ƒˆ§9&åŒÂT«âÞ°;¯oQ
-Äd²’Ø[EÜ­°¿ÈÇ`n—ÅædþǦiBŠFtù£¿
mŽ<{töJD|Ï;±Æ&G‚iþco§Àå²-çaA3©±W(æ‚2MYÕô(mò¤	œFã³{gþz&V__éa6ÎÇp›¯ØalĺÃuwðnæc"8¡n‡:Ñ!1w‡Í‘˜Ý¿g•Ã
ˆ%ù[ÛÃÞI‘nÓåÙ–~gdº/~û¬ugÉp¡`ÁPþôTiHŸì2\)ÜЙÍàÿ®ºþ0æ‡zx)œE½ Úéq;7,¦ýs¸ƒ,ª‡izÕ­éü*ið¾\~]•mî§Æ Æ
K•!ì†ß!ou4›¿›û‹†«ðw<«^UG‰/)cy¯$Ë‹>täCÔž•6rеð‚jåº)×ä;æC'17'IÙŬõ1:Ï–¼pV%¤»Ã
-2°ÅѦyWýö¾¥jÖÎŒUËü«üÂ@¹,íðÊ&©¾JèS"§oóZ²,¢tëpbýèÒúc•û"i}„¦Z~K¹ŠX`i~l…`šúI‹%âù>ÑH—ÓVÒE©ÆÅU
…ú©KÜÖ·w+ÁJS¼=öËŸ.Ç=|µ >üô=ÛŒ
-’úC¡ãa4Ÿ—7C‘ªÜ݃~Z¨‹ˆÃ©µ»*‡‚s·@qp![~_£Œ¿:[8&‹”ŽËNp€0ËtÃ"¤ü4q%¬i¨•F³høð¡HÁ81äј=Þü2¶ã³âL˜lƒK¯:ÏÂiåsB¢/]ûP6•[x²	_#6}°ÅfT¬…%*FųÖËÇ}Ù‘8?´Ï›PÒ¬“ê<7í¹õìÒÂgVq_î½ò±fKú–lFîkÉ(w(:Wâyx­¹CIBÞâ‚Û¨[NõbÖcpq¹Ú4j´¥"#žþs7¾hÐag•Þ^c
QÔ'?ªæå´AÂÞÊ…øh¹(LMa.‰(<ûù
¹â¹®ÄÃä%ÄkëºT)ƽØGbª8Ø—ö×tà,D¿“¿¾µ•*Òš.S:µ›èY|Ùä'Fz„yÎv~lˆ²Ð…ÿþ5£àfâ¤û–¤A-í-³ñsEZEÄ÷QàÝÜ=‹þ‹ÑMTsî›?8á‡t2eVe&…¾1›B¦\q(ɽAˆð"_²ó8ŽvTD=°e™U³ÓÚÖ®e#"EîÍÌ-ûax‘Se¯;ŠF$­àÈY‘×Ç7¢=HÞ¯½~òp±Õ¿þ) ’ýÐ+PXY-x"yQùºì€ìCˆ«=³&o™ù…ŠÒ¿$¿Bb‰ÔÜ“Q80ƒÁ˜jU¥9Ãüró5½C£öñ²·Ëä—A<Õ¦¡1RÁgó[¼X-	?¼§µebÑ×k^6*ÙJ¬(І¦7Ü1)ºPïNଛ/r§tªX¥õø&™ ¥ƒÆôÏážµÓfÇH­öõŒ’°.ÛJó9øP>µe't§l†ƒì1M¾#,Çä1¾#Ü­ÕÄš#[ÀN).·E¶/°6~ª§ˆÄ•T1˜ôY¶#ß:a³áI]ï¡‘g=㟗ì26®HZÄ+ØÃîk
-z|~ÝX!ö×½’F`à[m”Ý»”}«SqÁM÷]»&ÃÍÝùԛꚥ‘ü…@ÏHÈúûÓnê
-c—™XúAÒœü.;
®¯˜›'·Œ©½C›ˆ^zºnõâ塳ýæzI‡•f®.µ[bO\–äïoË2@c„ÓRvÛQ“5¦_nuˆ+ç±Þ0p%í(p“ ,\íqºGÞâ•ÕœJÈzpˆF­zè€ÙB+>„	iÎÞbcýЗޜ:È3\0/¡4ÜcàˆýÚTÑýŒ§mq¢Òß\cÇ úb{OhD~éì#­Hýð&Åû˜éì¿Íäj…¾d›ÐTC	ÿcä¢Be({fŸ9¢z±í¯ãîí+¸ƒ»ˆÚ2HŸÃ{Y³ït”CX¿4±5=vßê„$òVëlY„ÒT PNóD©	“¿÷Âá4¾4k[ç†ÙÎ|y©RøŒ³„‚KÝOsOsN±<
–$õ
ßO8,xìÔÝMSc1#ØÐ¥[±V¤Dæó:1lž ÔzÔ,•é$âλ›¼ôá·µ©¤C}cç
-RÐ%åØWÔ糖Î;ÇOÏØŒI“ëöL%Ç’,úÛ¼F¬>žÜÁ|á™ôaײÍ4˜m?3’V=·_L=Rx;`‚i<’kav`Äóè·¶²ú0
-pºs*Å"øVŸûå¦ä!¥`˜nƒ³ß+ó+ŽµÐ˜-”a¦¿FJá`éˆöF%†m„lï×Ñ|GÅ“ˆ9€lö,Îh¶IŽ¢‡…ÿNEIýõ>ähÜ—ð¥‡Ôâ VG¯ªuIl?¦_a‡EÁX¬¬¡Ó]VbîÒ\ß0—ð&®Bs:¹¨k~`µ8î¶ÈÑgk[÷Þ–C*qÁí%b,ˆÍ¦Y=S„Ü›)kT}3ÐwZúY+Ì¿¸‰Z™ m@}‹å],×jIºJëÇ™Œs³mæ™!É=â1P1@\¨²5ãd £ÊÕ¢+3[9DŒ§Ý´º;A‘þsš-lFQRÒÀöÛa¾Övþ[A(Ïô䕨:>Üa$/)œ¦ÿâMU_q£ªÀX9ð(ÂÙ9Nø†Ó3+öš¸wQžugGвeŽd‹@ÂLkZÍöç@QvÛ˜Š!-+¬d±ëO%è \é¥&û)Ë£zÝ»èëvÁ10䘰²ÿø£T7ÞúûèÌ›ó÷ÏeN£Ow·OªCõ§{gW¸¦u‡3Ž«›°ž¯uÇ*/[ê7,›¸GÜ°”¿¤Z·R	®²¡Ï”ÊÇ‚À“É*ì5tõŠQ,öO^ÇHO‡^!VçnõYç†ã2?K0eXËk¦·zy*’"\ü®æj‰¸gFÓïiêC.Níe†Êë”–"—²a÷4TÔîÛϹÿ)ÂP~CMH” sü•cň$çi~}c5mDÍÚ64òÀG¬þ¢ÏsÒœ¸—Ò¸×õs† ¹žGîì¾íʨ	¶49×ÔüɆÿ»–21“膞„P1Ün`‡\¨_RðbèÖ‡èΑ6ÂdÙ.ÛNã²êü–û:ããœÀË<2¹»ì¼‹¶Q†.j”¤ãôiaŠ(«Ť{+ÚE
-çøx£ƒ®Ñãz#ú€½ãJÿy‘ÃEäºF•“Róª»ÿø†D¯11tü@Ct´Y$Á¼šGj™¯%?¼äX+å•?L¤ÔÛ˜‡Í”_´Ò#(?Êô\˜ã@¨nw"àYl™À<”w„ÙY)ª5avQÿÊ%éömŒ—êÆ5=–AâŒ*$$–-Ò{OcŒËüŒÖ3n¡÷j¦&•3ì£Ç€ÄY+÷U&‡Zg\'ãMnÿ@÷W¢4’:zvlAÚ”‘…‡’>é„Üo¦˜Vü_Ù¹šÇ};*ˆux’ÆC,(¨ƒ|ýÜñ¹Ú÷zw¹)ç`‚‚zÂÐg\ÔMñJÿ¤žÜɆ'Ž§¡j9åÛôWÙM¶¬út5àÅWª˜»ž›Eþvó[rǺ4®€Ü’™`h—=¿©ÆôB•š¹ÍjÂìI~•[ak‰¸‹
-£fÍ6•9í]ØTÉ°bµ÷áú1K/š&‘9€‡e×¢hœj4Šß.Î[)Z
-dCŽREm46¬8Ó¥N¸ «Ô6<É,ÆÐÍÉÎæi:ýx(¥Ët8ÐËn ÿ`’®!©›86·§FåK•5JíB«×½VYg©»,&à1:¥ËãŒ'„D=lï«&è©IãQ
¯€äÌWƺ¥„RÒŠHw²ˆsë&üÙ­kèàûmïyoµ©ltxebmHçfïêïo&Hì*âj¦Î¾kÒrX›0 —
ó=è^›,›.Âå˜/Z—[’áXýõ~™?4ÒxÈÙ'€äñq´¤ª^JÙ[K™†OøHÊW|Ý@yw³IÉ:—ˆ™ôU-MÎLáÖœZàZÌBÊíXÃ6‚|6å˃ÃçÙÚœ—äºëZ£ÇØų%GÁc‡0Cüs‰ö[}‹#µ\ˆae¤Ãú4R{ ä{ÙãaË4#ôbÏ7áÅÂ…z¬«@½‰	FC̳„…žóc’ÒNÜ4.~4\jtÑõœáåxþ;²![EâOB
ÆwkäL•1Ó-M‰Ë㤶@fõ$²&©U"Ë*uA½
-¼ë0å ®ÏØ¿îZïܪc~[Q7µê4è©Hšñq‡Ôø°7ò=­³ž‰’§™òÆú˜“duˆ?ÎÕ+r^9kæÖq槜a^NžbÁ:ÐÞ“ªC=>JÅЕd›dg‡¼]ÕúˆËz@øeaªCšs5z Q/FÐé­Dú÷8È«âX²D›íŽO@Ñ%
U÷Méd>kZ|èdü%ÎÐ?,cYÎMw5ÊÃÃP|øTëZBŒåæxM~`Ô•ä×P
-Ïoé†-Ë»ç² ¹
Y¶ñ­Î±‹èÞÛ°ëÙC¼aŸèß7嶸מ
-뜻%CAÌ‚¬UV´‰Maü€¤Ï¹uñçó„áÜêÀ:œð؃CÛ(|#ºÉ&ÇëéòɼÏÈ8GÙx被Š³p<BÌýÀ«›[¤Êñ+ÇÕ˳ž8b׈×[ÍT|­¥#NùæQߧCW;Gˆ|SmÿFÞÖil±^õãþ™ef C¹‡¸·á¢y	JòëL;˜L]¸îÙÙeÂAÚbˆPAIÛdðIÔPîÅ¡êîµx£x¤ÀvóóZVSshö†ñ<(ïmýyh·-®Í䦊ŽEʼnqØ•!fmÝSÚ‡ðËZŒóÈAöÉlxýJ|Ÿ¶q³åTÒŽ4˜Ìýý—HUUmnˆ øCWÜ]Òï[÷²;ZØtnh3¦œ¨8	ì.(Ðë[Ù_ô~{hRÒ¡tá%kj†)á¦U12Óx±g¥×_nŸò‘±q»ÉWŘÄÕÜh95Ýô릆‚˪¿´¥eI]"è+©$jW
 M vžÈæ ZTb"}¤ªTS‘O{hŠ?"ʲ|kêz*uÖqÎtR‡c7J—‚5ø
Z‚†R
-×·³÷ŒAÿÞ]ÿ¹:#¥µI丙û@òñœPœ p9EñxŒ9"úˆçFëÒ1“ä2cÈÝVâârÌàOÜ>KÖ>uÒ»jì¡ír¡Ž#ú$ÝQoë<µƒº²#×_›Êÿ~†L²¸Q“Îxêœ-ñ9t­@i_Àš9™’»ÂuŸîçrÿ
-ÑÅÛ±åprkBÙûCzÆaÑÓ3ëÌ"!²2ö]3¾v{ÌÆY­»G«Œs»Oå×náR¤C2¾&`ñNƒ§Eƒ“\ÙÍ9È&Bê.üŒ¶Ù· nRV'“BV’äýáú%h:¾.l¶CÑy%4KÉÂTÙfÝ4„T·:ùÔÖ4_'áULšj€žXËÜý¤öiûÃÆûêç”´c§=`²¨øqªe˜ßC´Ü¥îóÚlméòùfôæw Ñå#ÑÇ’tx³%;$àh
én÷ý ‰7pP0OÇI¢£§f2TûvÆafÕ4Qö“ˆ,‘XûÜLܧ–zá_ÐáVM¹‡¦OšdvÉDþeQܪ#éØ©èªmc…PðQh–ȳç%w"?/]]‡iîä-7.ã’ÿ¦VÆ|K‰bÆ”`ˆëF¡·bÈÑ¢-ñ1Œ¨y4T,}ueé'ÊÇõ»•ãNø0mT#?[½ø<ÿ=†C³)õðœC“$²h,™#O±Píe8ÒE(,–#s¼zMÎ)0Ý‚³0µÀ²DU4–;ÒðÕ…1¦ãŠ~Ç0W€/MY$g´™•A-5 Òþ 7ãnîS}Ž@N:°óï3ÆúZ½Fõkwy<Òð‹÷ÜhŠKÏ=s+8T¬ªÈáö@°on»ÕÜDükw¢ïž@8'ïop°ò›KéC©ºyϚʡ½
-H¦Ö¼9Gž¸M‡ôº„þP¼¡ïÒ4Š›µ.¾êJøiˆG•Ä$…hÎX÷lÕ-DÞßÍ›á/c;§Ü?‚Ë¥9‡l®Ñ{Ä­Æ»òni†n½$›B×:õÒ©~’Xvyx’9c…Y
-	w/¼ÞU·O§”~EÁÏAç8Q•|ðŒGÇ=gý9,?YÁ2Ë2L"ôÄEñK‡æPüÚ÷AÍí"I1„'{†§³
úº¿¯c¼NøŒß_lbéøûö—
m„nĜɫí÷Zäo£‚³|t0ó>ú>S‹Â™ÔRú—°zaI¿ î%ÕA˜">©
•N~ú‚×-†®2-QVçh-‰úó
ýÞpܹâÛ/–¹"5vÎf—GWnT66þ8éô^úÞu¾4+k‹O5Q]¬NÙ 
¡-ël_M¸k˜ÚûAú=é&;4³áhgVå°CºìÞÃ5ÉÕMå×\Æ»8Ô\¬è”&fO³úÇ;^‘RÒ.æ,S–¼÷ƒ`÷‰†¹¼3y°f?s&†ñÊ;
WÙ,¼K#«©Ù¯®øbj[¸_VM2ë*BWMŠ¬3@¿1(Ÿ¸éŽ÷ÏÉXúŒ¶UÑäDär÷ñÇtƒ7Õ‘lg
h/‚Ÿw˼¯rÔú'‡cÀUµÁªqFÜŠ%ÿÖi8ÉÜÕYýXò³+~¢‹Ùäûó¥rkHú¶>O­ÐÑѤ²v†1˜#°^:á?Q7Q¥×8Tnn¨tÑ#œ6nœlÕóÚî×îŽq
-Òo)³S™2áØ¢c—¶FäKa·\®ó*‡©‘@èž›XsIÅXðûh‰ðeýÖ8%W6¤¹¤‹»Ü²yÕŠ½¢uoUêJP'mͧésŠêø?¹ÄÆŽÞמ+Ü¿eB*£HH:`rÀL]¿ºH.âØð~}Êη¡>¼üHÇ8š½D ýâ.ºQÞùÎ_]Ì—%×Ïت3©W$@2?d…°Õã¾Â`¾²ß³Þ׆>xÊ:ªÔý°™9•YæÒÊßÞñ˜¥ãë^:?Ü'°‡eIº¼¨-„~ä˦MÕ7W¥_ÓÞàÁ¥MxqÅß)w¾€Ì}®+È Á‘ÄâGu™.­Y6¸D£‰ý}KCîý§WçRPn"8U+Sœ÷ÂøÌûyvÝôL½3ìüî3QÁš\É–ä>¨UHC{ϊѼ•€Q¹!÷Å“÷.¼?;L9§ZšÒE¾é«v¥Ž}03|­˜6þ–ˆ¶9£,whœ-ÇËŸ­×;?zøpÙÍ„y8àŽ9Ë¥H»ÑHîÍÄû-q˜˜\—1άÄ.5HLUcß|{¨8óŒòZßÔç`äô³ÁPß½Q5åŽèz”=ûŒW0zúU÷Þ r	còRˆžÿžDCh-&¦)¬u#Å>"1™k–ôÿ»žÍÌÃá±N”vD#¹¢A窠›`_ÝxXÒÈwgÞ„ÏÙå솋ÛÈK+´CܦA"Ê
-âc§x~XÃJo(¦cé;‚÷ÿ¨š#1âŽøé}SUx °f=”4+ÿ䎧õZ›…HK0
-—€_úØî*Ý– ·£ý7<³Y6ªãvl¤ÎݱæŒú‹Ù¸™‡ÈÈc?m·Ò†h¡ˆÕ©Åç•¥RäÍ×”»L|âÊLwõø
Ρò°¤¼AçYKr¼Ï¹ÙÖJÑkW½b%òyQ·ŠTæ9æ‹Ló"$N¬½ôž‡9ȯòL¡åùö;û¿ZÆMú›¦Ýj{wAÆILTI¨£%èÔ&ëö…ôâÞ %§½(1ã:«/h•¶µôÕ9óUÖô”‘­Í¡i¬rÝxUæ¸ÂÝPÂ#á61”#,*@Š
–üb±·Tx8ÙÄç{ëG79yçÐê°ÀCþ“væ$Põ`Ò匀V–ƒÿþu6®%…Ùqc†¬Ó:†wtÎì•NôwØÒPÄv©*û&<û'ývýЊâ¹!ÔA"OýMBð¼"ðÛQܸ…ÍK)	z²>Ç'áØóô-oâŠÌ#°±ÛÓ­ÀD/&Ësgk7/;ô^D÷‡ÞKÉÁ¤ ŸCH-²oS<ÛõCoõšÂÛw˜´øŒª"ØK–_Š­"H‘¬ûVpÆsáõpa¡£_Ì×SÈÚua¯õ°Ü±l|ÚV±{+	wókÎ:¤6=s÷(HfUôRê¸zP¢[E ïcYÄEùºŽsûr~3§Ÿ°3ŸMÆ?å¦T‚°ÍZ5ÕèR˜±˜rL‰buO[ˆ`×w\ÁU·?‚‹œWà&ó+Дzu(“	Ø!ÌìÅûR% 2ú§8xdßÿó	<ÌЃ|Šˆîç}®rw‚RÕ:Mp’òÛBÿÉ]˜RòöÖ„½®íX((gÿ¶Ä?ɸ‹e»¿è­ÚXÄ`]¹#ƒÝ’X—ÕofQg	è¿ÏU„»7­‰¥äœ“sõö‘ý£Ëw5Y¬•ÓaM(Ã]Fƒn\^¥BW¢É–Œ~3
-ܯ*ù V}ÒD¦ÿôð¥ÎÈ
-}ˆÒçq=G/¦8õ6ÙüÍ/]Z?ó{P>yêU•œµú}éË2&@žÊå:Þä®þ;TÆ
-݂Ư9ÎÖïSftt7,-–‘hV©©<
®ÙÒ]+,àŒA‡Ø  •;…ÔzEå]þ<Ïßý‹ÌɤC™Ñ6ïðÖR®{ÒºsŽyZÍÒ+±êÈÜôÄk´ѤFÈZ‰!FÝmP€×:%•éd
-Ü)„lk2'¨á"€”Öó±âµ|syùͱÕe€\ûÊJ;YýMªI­‘_£ƒ~Æ1bfÓõÝd=–ÙþÅ|SÅ=UkΫ
-S­‚DÍ0»(ë%ªUÎ17%g:F‡°ÞZ?{¡ßs·1SÊ«„]«
-G7ôæøÆnuÒ{«ýef‚‰@ÆÚJt'D©Ñeèb
ÕÓþÿkŸ,ÛšŠ(
¢Ä’n¤Gw3pÔèÝH·„4I‘.é–îÝ%HŒîîÚ{ÿÃûí>÷ü€óá<ÏñÊ@J>N‘÷x°íþ®/Àï^ÈnÙv®Q’U	õ×=[#Cã]6öçÑŠŸ‚h&
’Œ# ëyƒòk»6úq
-ÅGÕkX:gׂ	še£¤xu®ôØ\CùqKå1¦g¡lø	7[Ù²Ì4Òÿ¹[PÞÿøç¥ÏFÔ´²ÿšûI#pŒ"­ªºóöWwxN¥&ÿÊYGúéÆ„¾åoK?\aùt@½=¥¢D#UŠ&ÐmÂ΃:Kó#˜´ÏÙf`ÃN¯Ú¬5}=ÿúfy$V·‹Id”-é%#©¾¯{z²5…رF’oö¾!²’»÷ØIáMØïä†H}ØÝÖR´x`î/Æ]è›Òª^3±Í7é¶ûñâ¬Â^µñŠ
-·(FLH³~å¶ÞÖ@Õ6Jäó¾xÌ0V?K£ÈÕJÑ}gy,‹¨†/ã©$þ¸Ì~“Æp\!#…þö/»-ñæ
–Ú3Uv+l•EM ´Dýý_O‰uò!÷¶:)
G‚·Ñ	é91¬ÄdÐ~í@§q&±ÑŸ<¹¥ËŠ)üÁžjÄÆpîp 	ãO`6ÿÓaÌ€“Ê ‰bœ›³ƒø*Ln•OA‚+«ä¿dWÍXäøkÚ—­ ÞÎÓÒU±?*›¢jžêß_
-+µ¸¹­Cí­u†Æ…¥v‹øò¬WU˜}öÔ“LÂØÏÚ(kœ¾¨RoiÍ^$Hé~ÒøÈz’Tñ׿·xû0­®Åψ_ShúÜ2\o­EŠã¦=U´ž$¸_N	Ó–jz͉Q
-Žò2Oa}=AÀmãUv”'·ýÆû9û¨,Yó‹Äg“ˆÐ‰$¥°®ÇªÍ3|Zí-Ä
-ïùnS;ÝŠM‚­fˆðÓ%¸<%kDpu47û95%–T+G“¢æ×*T‹J<Èü«˜t‡'On¬ÄÂ.ÚrÁ.0£€w=J/ê_GppÄÒ A߃Ðd=F¹­ÖO-ZÁ9†àU‹¯ùsÃÄh#a™jÔì‚NÌ– tNcñ§VF¢ïÎ{Ȭ¦ˆUŠñŽ*Cs~ö²sg_ܱu™É¢QªÀU4“å²7+ç!|¸`Të‘…>“¯7º–s™as¬G&S]EHøáWIÁ`³“èÖöAÊ;ÒteÞÇ¢œauÛ,>:.²
-ðž¯ÔÏ´ZÕ׈‚œâ^ž>ñ·!eÖ²ØäÛ¶(¥/J‹@Ëz¼–F]¢wò¿ÝÓÏõwÁ/…=£ÆhŒcsËtö„t˹¢Æ1|Pú1—ŠR,·²ÖÑï„$8É
-,f¬S¼‚Ô·Nï¡Ó¡›¾¼xœñÏ‚È¥éJ#ìKÛ1íü±SŸä{årsê,<+ö‰ÙöÙœ¼U1*µþôD'î¿ð|ÂBÕF5Ç	.‰Õ+‹f¬æ-åuÝÓ±oFã”’zeí­ðÓ„A Ç«á±™—KØ+·,V	cšðôŽ­/EþrË‹î ×öëMƒ}#j€œ§Z¬R‰¾^¢/dõäx”z[]ï9OµÈŒý/Âæ7¯>’òT-)AB鈢C•§x”ï±IàI稂i¸t¿@€"JUîU}mÐ'sÌ’™ž,Ð~bèºAòFKEOlÔýðp€.Xb¢ùçöÞ†£EcÌ9¦È<üE¶0mª¥±|ÿléæ3‰•Ïý="þØæœÖ¦wÆ:—æˆà#!¦%Ö§’\Fj¦¦Â‡ÊIK°';Iª…¢ö}hë­w™å9²T¥tM¸JÌtü‘á,H‡î"ûDHÔz	97qtÅÝÄŒ‰ÂuØVqtîÁô™?'¯`¹NøÊù3²–œGÜ*˜é²HÚªÒ ¾|W]ò{êîTõÌqý]A÷,’ùÚäÊÖoU¯¤h¨,Œ¶‰wnmƒk¥ºþ
Þžê|f¿â‰™TJ8‡6¨Š5¢äÇ„ãÒ¢1,Ôlvˆ^Ìýµ•Žã¦!ã½ìZ¿ÖæÚYôšÎß×b&¾¼ÿÕ‰šºCåu‹Îø{é±Âf¹ªÛy¡	"|ùª<ärÌÌ„)=¤˜ï0gxÛS°^Ø«šéqGGÙàèá´àL–{ù¾±~û™ÓwéAÆH¨º…°íMÊe:ùf>
*®b&¸Fd!$xöœóhú¤ýGr55õž?õ'GžLqú¬ÀœÖÕéž´AA´F߃ƒCÛw
´VøsÞkw{竱>·0¾8ÏöÖ >¿ô=Hq«•3õ¦x:ˆé©d9QL ­þ°¨]Y¦šÍ"±J[^}ÔÊåâÍò"5=4Ÿ*«cuýiÛë‹%ïQˆu8aA#&S¢"\£¥å^u›ìèès²	×CbGó|cïî•ûl.lض²¡5·•Ÿò6Ëü¥“)>5“ܸþäc%Y
ÒZ}ϲJ¼G=™ìf¡»ínÈ!Ò[\ŠÒ^H0©mÄõ˜Àw'¯E¹íTŠÀ—±¶À˜•«qRð}øù[õ{ñ½ÈLðƒD߶ÔÐWd6¬!Í<ã÷é](XâJKR
-K› ÀöYt^¬evQ&57Ñ„t9Æ©‘;ØQLV2²ûËI2­U^¹¨%Ô~ŸŒ×ˆzW¶¤¾ÌÄi~=úï°VÕõZ5dw0uÃ{+M	VÅkzÏjG‰7¸zb4@ˆKPñ±Ë6§ð]É"‡ÇÂЗË×øVà]ßQè³ø%áRˆ¥¯>2àsÙsÍ@ü+§hœýbyZÃ÷-ý$ËbÇ;¨´²*	#Œ6^ÿ´Œ‹Ä*jj¾}5™üÊ­tÿg ›­ûá=)ìGõ™;RVÛÚ½wV*îM\ˆšhßn`ÇPÙºzÇ'I~©VŽ;&븙i—wâc3:™S‹åa¥40ÏZ:	Moè¥Ø~ƒÐ#YcÑV„³IF^¸Övú¾&ÕÍBoªzôåÒ½¢šºˆ<è@ÕŽ!ÄVo£Cé·³s~íAãŸ)4°jsY™ÖÑÁ¤¤Òøɉ
cxg4Hc=‰‚­|(—æ3§‘»Ñô¯ðÑqr1¥~tÓ™²süçŸVý;Ë}I†õ„=*š½Â!³ ®8¸²ù	¢Ÿ{J½ÅhJ$‘¹Í2ÕtKcÇZ=P¶)»ûøÔÂwË,û«øƒˆcÌm#ãdxÐu!^	Ú9ûi7ŸÙJcÔŒ]+µ
jÆ»Ò_€[hI£YÉì0…òÇ*껪¦úݳj€í¨ž¨ß`Ù?8sGx9g3ÎîèñÙt÷:n:—SúluHx‹œ›ÍÉPo·«ÃJAüÕh€ß¾ÅW'ˆÃô´B ¶q…¡Jˆ`“ý kaæ®´bg>–MO”¶æB8uk—ÄþÙ7)Çê®Ü¿5GVQ(ë¿P­m-FG*åTA¸¡WK2z)·	Ž×?3Ì›QOl
-s¹xŽ5WË–§zGϺß?ÁyËÇDóÛ8Þ6<,óyÊœ³%ɾŠaîjôër¤ôç ³L.¸!åeÖ&A—¯y!qíµ¸`Û®8&ƒûCá°ˆ×P·KÄMZQƒñˆR“!»V¸x3ËßÀÃ'£l{…x|#”ÄÒ,ò9r&tã|¼a¥ïéæ3sawÄø²Ã××ÿuåÝ™×Ãùv¦&R®É;Ƴo©5$rÇâ¯%ì»iÕav·4ËEìØÔ;E6'µ…¹ïh;ž7\oqkÙñ*¯u¾+ÍNcýàÿOÃõÿû‚ÿ
-¹ƒ%ÔÕÝÙêjý±Uáòendstream
+/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ÖÆYc ­`jç°þ÷`lgkbñOkNŒ¹„†'{ ±Åß0 ›1Ðþˆ`t´±prúû°p˜9Ú‚þÎd°°5¶v6ù§€¿vS»dïh÷×Ãæ/ö—LÑÎ	ädìhaüͪ(&ñï:A憠r;Yü…v¦=MìŒÿié_Ø_š¿(ÈÐÂÖ	ºþÉe˜X8Ù[ºÿÍý—ÌÞÑâ_e8;YØšýWôG ™¡£‰5ÐÉé/Í_î¦ó_}þ—î
íí­Ýÿm÷/¯ÿ¬Áä´6eD`ùö7§1èon3[¦¶Š”­©€…ùßvgûÿÀ\€Žÿõ?{†æo†&v¶Öî )“¼èoJõÿÊŒÿs"ÿHü?"ðÿˆ¼ÿoâþwþ—Cüÿzžÿ;µ„³µµ¼¡
ð_A€ÿ¸c²€.ãÿÍÝÐÆÂÚýÿðß=5€ÿ®RhælmèøßáÓÛšýU„›‘ýßV'	7 ‰¢ÈØ`jhýwVÿ²«Ùš­-l5ý×8,ÌÌÿ
S5·0¶²ýgøìÿ†€¶&ÿ½ü¿2ý«x&ui‰ïÊ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†$Zk›oÀëãõK„ö Î£
æe*|LÞ¹*p¼§}¸ò× }an²éÜ¥ºÏ¡öÚò´Ú7dîyˆg9ÏÅõð¤éFOdtã’ý‰,5FYrè¼c}í¤Ná§à:†KÐe
fŸvE#Ÿ?Íю˪̘í‘0S(Ó¿£ME J+dL©¬¼I­ð^>|$½g'IàŠ´?"týy0ïù4=:9W8ùÉÝ1ÕØ”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{9uN4Òœ°T—£b؆F–i$ïó‹'p‘}¾Ÿt¥™´ð^ɨ"3±Ut¢¡zx²ØÆx4D	K¬ZógÜ–z‘xC6‹]äÂØý9&yóï³t6?ðÌ"%
+‘¼FøCAÌÑð}>€¶6‡¢ÓVÛþ\ý	diB´«ÙQ¯è.Ç~Þ‚´ÈÌ=ìäm’6yS$ý-Ñ¥ª¶™)P‚´)keÅÃvM¡Gã¶Ëe·5%¬_ØYûMŠKÒ}ƒ†Œ8îÕŸÃl5wìóµ Ô<öÅ·£„²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ú`‹Í,¨XKTŒŠ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’TEíûÐÖ[ï21Êsd©Jéšp•˜éø#ÃYÝEö‰¨õrnâ芻‰…ë°¬&âè݃é3N^Árÿœð•ó+fd-9¸U0Ód‘ ´U¥A}ù®º"äöÔÝ©
+ê™ã2ú»‚îY$óµÉ•­ßª2^IÑPYm3ïÜÚ×Juý¼=ÕùÌ~9Äÿ	2©”pmPkDÉ	Ç¥)DcX¨Ù콘ûk*+ÇMCÆ{Ù´~­Íµ)²è5¿¯ÅL|yÿ1ª5u‡Êëñ÷Òc9„ÍrU¶óBDøò3TyÈ嘙	SzH1ß+`Îð¶+§`½°W5Ó㎎²ÁÑÃiÁ™,÷ò}cýö3!§ïÒƒŒ‘PuaÛ›”Ë tòÍ|T\ÅL,pÈBHðì9çÑô)8H-úäjj*ê=êOŽ<™â:õY9­ªÓ=iƒ‚h¾!‡¶ïh­ðç¼×îöÎWc?|8na|qží+¬A}~é{âV+gê7L7,ðt>ÓSÉr¢$˜@ZýaQ»²L=4›Eb”¶¼ú¨•ËÅ›å/Dj {h>UVÇêúÓ·×!JÞ£ëp‚FL¦DE8"¸FKËyŠRŠàïQ¶ÖÿcFö,nc$õCèÛn^ºËø}ÃÞ‰ÔÕÃìm{ebèÅß5|:¼ê6ÙÑÑçd®‡ÄŽæùƆ^Ý+÷/Ø:!\Ø°meCkn+?
äm –ùK'S| j&¹qýÉÆJ²¤µúže•xz2ÙÌBwÛÝ:‘C¤·¸:¥½`RÛˆë1ïN^‹r+Ú©:/cm1+Wã¤àûðó·ê÷$â{‘™à‰¾m©¡¯ÈlXCšyÆïÓ»,P°&Ä•–¤–6Aí³è¼XË4ì¢Ljn¢	ér:S#7v°£˜¬dd÷—“dZ«¼rQK¨ý>¯õ®lH}™‰Óüzôßa­ªëµjÈî`ê†÷Vš¬ŠÖôžÕŽopõÄh€— âc—mNá»’E…¡/—¯ñ­(À»¾£ÐgñKÂ¥K_}dÀç²çšøWNy´bJºœñýÎ^y{D¹¿áöøȯ×ÍóWV?S¢6y‚
D\ë †µÆ†ûÿ
+Œ†<\a/r¼ˆvÈxµfíÉCvP€ÕóuóföÈy§Åm4ÍÛÆajùlW¤JÕ4pñûZ¢Aÿ6Ñ®–B][¢µš×´B©®¦Ö{?q£Q4¢«]*ê
f1
¬Œ*w5#Ò”HðŠ¼ª¡–©ÖËCšŒñÌ®¾”ëÓj¯¼Ã'gE¸FŽ:í·²ˆ¯%u0Aü¼$°aXÂ/÷ߵƪÂú¬(ß™uklê..Úá¨etV‡rÓ*$ß;>wYp®Ûr¡£îdʈ†éñÇVéÃhKñ«¸óWCÞ.ïò$.¢oÂÞQ#»Å¹* q¦ûÀ6¸JÔ	àÇæOŒù[ôÏQ7óeø^ðÏa:iÄçºb¢&ÙgAÑV£ç\tj†yçר™<£È„ì3tçV(ôßÌh©×OѬEf›½	éÝK•X?`Ãþ7ØokÓÈh_y,Ü÷í½?á¬{®Mpóßù‚z¯–ž§ûëeò eÌtÞøa‚s{ú(5J<iKfÙý6ZilX'Å¢ã6ÉñÃëÓÛ)'´Y¬¼ó4a ³Ô4ǸÔ;ÁñUÁÑu]h‡ÎlŽÑJqz$KЪ@ÊÛ3§Üo%ù˜CS÷.õ„ŠuáDâ°YkÊ5N-¸àî
)¦uóñ×RÒŽ»—,â,Öò‘ù;²eõ'h=ö:©aCDcjÏç¾µg"ÁÌû'…@ä¡e;éL7FK@»,ƒýëdE’¹¿eÊu]þ¦&ãñ*çXêR\×|ç>¤}Ð8ûÅò´†ïZúI–-ÄŽwp­íô	|Mª›…ÞTõèË¥{E-5uyЪ(Cˆ­ÞF‡ÒogçüÚ3‚Æ?Sh`Õæ²2­£=‚II¥ñ“ÆñÎhÆz[ùP.ÍgN#w£é_á£ãäbJýè¦3eçø1Î?­úw–û’ë	zT4{…
BfA]qpeóD=>ö$”z‹Ñ”H"s›eª+è–ÆŽµz lSvöñ©…ï–YöWñǘÛFÆÉð& ëB¼´söÓn>³•Æ¨»VjÔŒw¥¿·x¬ I’ERH·
|MÄãzÅsz{o ß–ž›ŒD3e'lÁb=âßç95K7ÁœÃ'çk+'ÂæxAS5#]¡~ Ú§¾wÅäoV¬1¿AÃÍÝ4šïOFG,j‹`Ý8ðE¡4™üøìi–¢L-C^+ÔÜF«Uݱǭ„ŽŠ(û89Aû[¡÷Ó­f)­Æa|é]l©ì™ùÀ`§ª¶p«B8Lúño@}þÐ’F³’Ùa8
+åUÔwUMõ»gÕ"&ÛQ=Q¿Á²p,æŽ ðrÎfœÝ‡Qã³éîtÜt6.§>ôÙêð97›“¡ÞnW‡•‚ø«Ñ¿}‹!®N‡éi…@lã
+C•Á&ûA×"4ÂÌ]iÅÎ|,›ž(mÍ…pêÖ.‰ý³oRŽÕ]¸kŽ¬¢PÖ¡ZÛZŒŽT2Ê©‚pC¯–dô.Rn®f™7£žØærðk®–-!OõŽž1t¿9~‚ó–‰æ·q¼mxYæó”9gK’}ÃÜÕè×å HéÏAf™\pCÊˬM‚._óBâÚjq
À¶]qL÷‡Âa¯¡n—ˆ›´¢('â¥&Cv­pñf–¿‡OFÙ2ö
+# ð:øF(‰¥YäsäLèÆùxÂJßÓ%ÌgæÂîˆñe:‡¯#0®ÿëÊ»3¯‡óíLM¤\“wŒgßRkHäŽÅ_KØwÓªÂìni–ŠØ±
¨wŠlNþjsßÑ8v> endobj
 882 0 obj <<
 /Ascent 722
 /CapHeight 693
 /Descent -261
-/FontName /RWLLBB+URWPalladioL-Ital
+/FontName /VJFHWR+URWPalladioL-Ital
 /ItalicAngle -9.5
 /StemV 78
 /XHeight 482
@@ -9187,7 +9171,7 @@ endobj
 >>
 stream
 xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ	ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)Mlpdd"@C's[QC' 7@h˜™L\\\pd[;wsS3'¥š²

íYþ	ütÿŸž¿™Žæ¦6ò¿.@+[;k Ó_ˆÿëD àd˜˜["
-ŠšRòJ	y5€Ðè`hPtþien57Ú8©&¶«F¶6Ææÿ´æHÿKÈ`p´™ÿMºíþqÑì€Ö掎¿æŽSC§¿3p²˜ÛY9ÿCà¯ÝÄö_„ìlÿFXÿõýS´utr4r0·sü­ª(*þožNf†NÿÔv4ÿëØšü4¶5rþ§¥ùþÂüõ:šÛ8œ€nNÿÔú	›;ÚYºÿ­ýÌÎÁü_4œÍmLÿ‹-Àhjè`lttüóûŸéüWŸ€ÿ­{C;;+÷eÛþ+êq0wrZ™ÐÃ11ÿ­iäô·¶©¹
Ã?‹"ecb`bü·ÝØÙîú\€ÿå?;Cõ—„¡±­•;ÀhÇ oëô·$€òÿNeúÿ>‘ÿ$þoø¿EÞÿâþ§FÿÛ%þÿ{ŸÿZÜÙÊJÞÐúïüûü}al²€Þ+C‡ÿW¸¡µ¹•ûÿ!á?5€ÿ&ùÿ#ådøwB6¦a¤gü·ÑÜQÜÜ
h¬hîdd01´ú;©ÙÕlŒVæ6À¿Šþk˜:&FÆÿð©š™YÚü3z¶»€6ÆÿIþ¯Hÿ¢Î §"¡!¯DóŸoê¿¢ÿjï¤ên÷—ØÿhEÎÖøþÁ¶uxÒý½tÌ,ö¿9™˜¼ÿÕþÃô_g9C's7€öß–™þÕøÿøý×I÷?`ÄlŒlÿÙ'Cã¿ëõ¿ÿ¸œþªú¯ÿ·áÿyþ×¢n@#¸Õ߶F‘ÿ$þ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ÿ¢Î "«)£¦AóŸoê¿¢ÿjï¤ên÷—ØÿhEÎÖøþÁ¶uxÒý½tÌ,ö¿9™˜¼ÿÕþÃô_g9C's7€öß–™þÕøÿøý×I÷?`ÄlŒlÿÙ'Cã¿ëõ¿ÿ¸œþªú¯ÿ·áÿyþ×¢n@#¸Õ߶Fö¥©F{1­(zR€—ùøÞ$T}¨›ä4z%ˆégQžW‹²ÛZìŒê»“JÊzÅïPߧ;X`®ž¨üH\
 üÐIí|ŒRëc1:QA¾Õžž‘'?=RŽõÜ@öíãÑäÄÂ’ñ¸@ ’GúÙçà	h©Ux†SA¥7!àÝ´_}jt{êå‘‘â’FX˾*šæ¯Ù´Ë¾'A¦·ð&Ê9H¶îWþÀ¼žŸŽäJœæšËýZw&sÄâmŸ
 쿵$
œÉ„®'~»¦ìw󬵮¦~íCÊ]™Qê,©wmÚ'c¤	w®Diµs$óÐY–1¾—f‡ÙÄ&>.jüäë賬9“5ÎÕu¨ÍÄV¤?m=Á8ib/4l¼˜’lºÖ’Ÿ$):Srïð¹ŒtéÇ#/sƒydŠü¡
_•vÏÐX¢ÖÙ"» ú”4Ú]Ô†Üf†·”-FêÕˆFG‚„ùs!kt>
@@ -9268,7 +9252,7 @@ i
 ^hâŒð·¹ œ£“hZ™Í/øÅ_à7œÀ+P¸¸&&êåî$+Nȶp®Ô
~I(–»c¹ÚŸYªÓÅg¶%ø¥p%ö>­’H¾iL¿\ÚõÐß(¦µâ_«8Cƒ—R{‹
 Žµrð¦ëØíû‹0Ê{‡˜ÊQê¸2‰«Zœa‰ƒ†*7Äc¹äJî„I›ÏüìÒ]©æÁ 1=Š¡å©òñS€MX¡¥GMøªéþP¢‹:*½ÙOT9†ÜD¨*ÀzÞÃ*Úž“¬ÿ°Ë_hg
 ‚œ«ê9ŸjˆŠ"J7Þ®(ðhT(ìâ ª¦¼ÜðÊ™§Ä‹V¬áÝq
-oò]ç}£¯9B‘7õ·	öœH{È­’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2
Ún“
RÂɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤Ëq¸ŠÖˆÕ"™[Ø m¥cA¸¶¹"t8Q+PK¥ìó÷Ñ”¶ëÛãh_“	®$+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝåûm®Ý‘(ãŸÄ"Þïòwnúê›»ÉÕ”^«¦y$3î3i=+iÿWuÈæÔmâ’<£Ⱥ][±÷QgShSÝ»¤SñºïX±wû@`z>ÍÛòÈëB¶"Æ®.(ñôAàN¥Ã|³w®3¬ín1eqÞ¸XäL%­1;¹MÊ®¦*Åÿ^OìU©‘yo•½§ìRùùÑ©	lå™Õº©RéÓåú’ØyšQÝÅêØÌ·XçY2‹†¸Ä¾ŒPñ+«Ö$ßo¼7SæDEÏ–GÙËËGªvË.¼–Õ£ª¾PH^ ÍuòñjzZ+3àÆ´¤Nc<ÃÃe™åGKB.þ/Qü?øŸÜ|Ý]ƒà~.>ÿx¦ßendstream
+oò]ç}£¯9B‘7õ·	öœH{È­’ëæi`T&éVÇãs"¹‡‡ªÃßÛçVMo¼iá÷׈â{C„^×;¿_g¿`,·÷þ2
Ún“
RÂɫǶ]ÅjÍuib°ƒãÏV!QÏÆ>²¦aO<ö”ñOÁxƒªH²$áófe°§Åû›ê¥úКxÇÑiêÅà>ò$­–Ìy"-Ú-ŵ ôý‰¤Ëq¸ŠÖˆÕ"™[Ø m¥cA¸¶¹"t8Q+PK¥ìó÷Ñ”¶ëÛãh_“	®$+ƒº‡¼S¾ÎúÜþµ$áØ™éezv~7EhÅZÞ‚¥ÓªãHÝåûm®Ý‘(ãŸÄ"Þïòwnúê›»ÉÕ”^«¦y$3î3i=+iÿWuÈæÔmâ’<£Ⱥ][±÷QgShSÝ»¤SñºïX±wû@`z>ÍÛòÈëB¶"Æ®.(ñôAàN¥Ã|³w®3¬ín1eqÞ¸XäL%­1;¹MÊ®¦*Åÿ^OìU©‘yo•½§ìRùùÑ©	lå™Õº©RéÓåú’ØyšQÝÅêØÌ·XçY2‹†¸Ä¾ŒPñ+«Ö$ßo¼7SæDEÏ–GÙËËGªvË.¼–Õ£ª¾PH^ ÍuòñjzZ+3àÆ´¤Nc<ÃÃe™åGKB.þ/Qü?øŸÜ|Ý]ƒà~.>ÿßendstream
 endobj
 868 0 obj <<
 /Type /Font
@@ -9277,14 +9261,14 @@ endobj
 /FirstChar 33
 /LastChar 125
 /Widths 1952 0 R
-/BaseFont /MSGWNQ+NimbusMonL-Regu
+/BaseFont /CLYKUW+NimbusMonL-Regu
 /FontDescriptor 866 0 R
 >> endobj
 866 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /MSGWNQ+NimbusMonL-Regu
+/FontName /CLYKUW+NimbusMonL-Regu
 /ItalicAngle 0
 /StemV 41
 /XHeight 426
@@ -9307,7 +9291,7 @@ stream
 xÚ¬¹cx¥]³-Ûv¯ØfǶm¯$+6:ìض“Žm;éØè°culãëç}ÏÞû\ûœ_çÛ¿Ö=kTªY£æ¼îûZ”¤ÊjŒ"æ¦@I{WFV&^€†ª–²‰­­‰9ÈAžQÕÁÎð×̉@I)æ4q9Ø‹›¸yZ@s€8ÐÀÆ`ýúõ+%@ÌÁÑËdiå
  ùËAKOÏð_–\¦^ÿütYÚ¨þ>¸mí€ö®)þŸÕ€@€«`²Ä””ud¥4RŠ) =ÐÙÄ ìfj2ȃ̀ö.@Z€…ƒ3Àö߀™ƒ½9蟭¹0ýåq˜\f ¿a@O3 ã?Àèlrqùû¹,Mì]ÿöÀÕ²7³u3ÿ§€¿v‡äèìð×Ãî/ö—LÙÁÅÕÅÌäè
 ø›UY\òßuºZ™¸þ“Ûô8Xüõ4w0sûgKÿÂþÒüE]M@ö.W §ë?¹Ls‹£­‰×ßÜÉAÿ*ÃÍdoù_0œ–&Îæ¶@—¿4¹ÿéÎíð¿íÞÄÑÑÖë_ÑÿòúÏ@®.@[&V¶¿9Í\ÿæ¶Ù#0ÿ3*2öV–ÛÍÝÿs:ÿ«A4ÿÌíß"LÌìm½æ@fE׿)4ÿo*3ýωü? ñÿˆÀÿ#òþÿ÷¿kô¿âÿ¿çù¿SKºÙÚ*šØÿø; øç’±ÿ?¼Mì@¶^ÿ7ÿÿî©üw‘ÿWW“¿­±·ü+ãW&–¯ÿ@.’ O ¹2ÈÕÌ
-`abû·Wÿ²kØ›mAöÀ¿šþ«FV–ÿ†©[Ìlìÿi>ç¿! ½ù¯ÿ¯LÿªžYLB[EU†þÿ¸WÕlÿΗ+÷¿#”ÿN‚«º—#ð¿Òi)8˜ÿçâ>QQO€7#+€‘‡ýïdc|å`÷ý¿äþë­L\Až=&Ö¿¤ÿü²ü“û?
ƒÿF#aoæ`þÏ쨹šØ›ÿ·ÿ4ü›¹9;ÿUù_7ÀßíÿÇú_ƒzÍV9˜ñ[§ge¸Öáæ
OŠë
ô±B‡8–6ªÔ8ôú§‡o­4~«
ajšæýh÷Z:q|ß—¥;íñ¥îM^ù’Óö¢ÿ¦êä¦?d6,EÎ8ÕŠö¾\”ß‚ÒåbÑ<Ø™TQ5,yƒ!žîdw†»|¤
 w/À¢xpDñ3KkˆÃîBkèûqrJ•tüø@=462ü³÷ºŸ>7ž’Ï
+`abû·Wÿ²kØ›mAöÀ¿šþ«FV–ÿ†©[Ìlìÿi>ç¿! ½ù¯ÿ¯LÿªžYDQ^KY›þÿ¸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Ê
@@ -9369,7 +9353,7 @@ MI
 ¿n$rÝ	XðD˜t
ÎõÓ…”2§—n„sÞmOÆ„ ˆ;²ÃßshuåU9ñÖ&;y-sõP~K*ªÅz4rnp´}ª÷œõ)RB—+«å—>¢cI£Ž¹w×	éhz€Ì\mm £MúHþ×<×|Ìï­&‰ Ÿw³s£Üë+\?VË´<=yò‹ØH»M'²ñÑ67Cøoí+A5x5½·x¯'_Ë
 c!vÜ~óÓ4¶bIpµP]ãH^ŒúÀnkLßYßÙ„æÀ,•‰)tCœrÀ‘Çi†Ï±m$hýÈn.ÿ¶»öO¿ªWÂ[–{OFChÓ'žWùÆ*6L‡1±’g^H]u Ââa3ð¸g@—TÕL_1@d7¾ùÁ“†µ‹Œ:…‘XF.ÿ§Òfb1\ÄñSÙ£Ö®TÁIS ÒŽã{9.´ v´ôPš_$ƒºÃ™.T€Áj”¤RÚ.zàÂiXÎ^;-”ûkwå0HMKyÃûSc-‘tkâôk'a.*bí	Û¶4ŠdÇ&ž*qÉŸX‡ÒÝÓä"c°4	*+9‚3£
 cáE¢Lg%ãŸïÁó§KíÚï©=ëg‡~Q)œu‘Še7@ô`­¥¡c˜„s2¬ìe/ï´Ã÷5ØI*·[ÔrHîD4;"«hntRÉ´c¬¥ŸýÝ„u å{ÿÁØ}hë …x;³°çlqf—š
“d79˜R€2õ¨)iµ†–Gö»€ê&‚—ÜÞ¨CšùŸeVò]ÏÓ~„ð¡T}îY¸dë`XÕìéÎ<òeJË»1ÒXê¤QáÀ#÷gX¹;«ÜÉà{}¤*½lÈ»€~.ž©kÜõVÅÇ®þÒ€§ú‘7ã$o—#€àkص<Éâ{
-¯41¶{ºQµÚâl·Pãg;‹($@QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þKTØ&§Ð9æ2ös³Ìü±×îªÊ›õäõ§=ìÌÉIx=ãç7åv[¿Céhw›«Ó(îl*ø®Ÿq	‰Ëb“ÛfÜèYàûYÚÿßRŸåÆ	|)¶U-*ª[rᇻ……øw8me-PÍsóQîñúW™N‡vé¸î²”š{e³ã=öEëe>*­xQÿuò_­Rñ„çÒ˜
¢þ«Iïç?d¯Y¹Æa½/Kz†Âc™›gZ6qæåØöì—3 p0,HÎIM,*ÉÏM,Êæ¼[fœendstream
+¯41¶{ºQµÚâl·Pãg;‹($@QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þKTØ&§Ð9æ2ös³Ìü±×îªÊ›õäõ§=ìÌÉIx=ãç7åv[¿Céhw›«Ó(îl*ø®Ÿq	‰Ëb“ÛfÜèYàûYÚÿßRŸåÆ	|)¶U-*ª[rᇻ……øw8me-PÍsóQîñúW™N‡vé¸î²”š{e³ã=öEëe>*­xQÿuò_­Rñ„çÒ˜
¢þ«Iïç?d¯Y¹Æa½/Kz†Âc™›gZ6qæåØöì—3 p0,HÎIM,*ÉÏM,ÊæLfªendstream
 endobj
 751 0 obj <<
 /Type /Font
@@ -9378,14 +9362,14 @@ endobj
 /FirstChar 40
 /LastChar 90
 /Widths 1953 0 R
-/BaseFont /CEXQRI+URWPalladioL-Roma-Slant_167
+/BaseFont /ANLWPX+URWPalladioL-Roma-Slant_167
 /FontDescriptor 749 0 R
 >> endobj
 749 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /CEXQRI+URWPalladioL-Roma-Slant_167
+/FontName /ANLWPX+URWPalladioL-Roma-Slant_167
 /ItalicAngle -9
 /StemV 84
 /XHeight 469
@@ -9401,18 +9385,17 @@ endobj
 /Length1 862
 /Length2 1251
 /Length3 532
-/Length 1862      
+/Length 1861      
 /Filter /FlateDecode
 >>
 stream
-xÚíUkTgnõJÀ+Å €¸
-æ2M°HZ TP¤2&“d ÉÀ$Ñ*°@Á¢* @¥•Òz-+Šž
-rÓ(š€`E.º‚îzìÚŸ»¿öìÌŸyŸçùÞï™çýÎùœy¡$–Ýû£2	$ƒLÀ/(t3H@2•àìì‡ÁAek!Ì@oo`)EH¨&ʤ3΀«Æ‘X¸ú}2%b,)Œ!|HA
-1,Å{ð!	ŠòX¡&,‰™Z!B`9Œí€d„¯¶Ã"DF L9âÈ„(À˜ÊØ7Ô“ã¦WÜä'nQ€Ê$j@	”`ßÆü7L½ÛÜ_)‘CÒ©öÓ)ý…‡¤ˆDýZJc•
-‚PŒÉÞ•†Á3æ‚`¢”¾Ërá³d"	@O2Õƒ>C rDxˆ‚/„DOã°Lð®<¾i#”€u,'Àýõ\§I„ÈÔ±0@}«ž®Á·5ž†¨€*™Jq!þ¾ùŠ|g³Ïd|T€ÈDî@©	ø	Â+:ˆL«X…;¦e¨_àÑì„(F˜+èPøÆ—Àü©©)¦Ø‚P¶ã™Ã‚¨4à >,…†=^Ã3C‹{á8„½ðp€#—@rñ4ü×àØlT•@¢y$o/üG@Ð`0è»þMÈWb,SLŸM<þ7µÁGÃ*˜OèhCù>iÑ5镉Ÿ»þý‹çÍU¦óÆ𳉅ˆ`W(ýÈzG‘¢¬¿ÔpfŸ–£·ýœïsÀ;½8+xï—#G­OœÉ,©ÏI¦7ÛC‰êÔLÍœ—î.ýmܦƒE_ì˜
ؽÃß,_Ñ1²<©ÙêˆÀÈÞr¬~¼§Ír¡[È~7§%ŒŽãæÝï/"ª»Þ\6|6©àÒ*þеÛQîŸé¢úZnÆî"…;ôz÷õXM·Œ†¶‚‰ùܽ
ªG»2œŸèB+T£™‰v	¿_‰5'ÞØ=U:úׂÐàÀ¾Ø}]›vÉ@ÉN^Wïhß|ÏCübI³{°æ#µÇcÖÉg·Dßßøs5˜ñÊh¾¤<ñYST›ï°öQ|ÜwçVo$fí"Qspóã²sZ˶s6 õê[~ÙÏ‹-‚¯šeÒ‚”gÆ4gÅû(ľAÏ«m×וÝK–¾gµøÛ¯ÖGÖ²¸ÿK³¬¦¾ž=ciNšV†½Ë—›^pfWÌ•u]$?z2y •Ùµ¬¾|³¼cÌÚš—ÈædÚä‹.¤Àj²wµ[ãBMM{ía¶ÓÊÁ¼Ëo£wÔT)¢á!˱ì½Y¼Èàõá_˜%mm,H‹äF>1™:ŸU>.G¯Xš2fJçìÓ=ïr*µdžl-Ï°sQÃ'ÏûzŽ™³*Ï7rôh^Ëevø‰
­ââô\qüÓÝG~szžÔóÇðwK¢I?&¸õ™¡WrG“-Þ_.~bàÖùÔ”;8’;¼iíÑ;¾˜&­Å0çñ²GÔÍ-whqI9ÛâyfÖÜ
-ÍiË”©I¸”6™Ý3“÷Ï*ýˆLgOÿ˜—ÎéX¶ríð‡–§ŠBXù£‰æ¦Ô}[»Aug¤fã¢WÙ›ž\eÛæóë±pÓ‹¸‚‰m}¦=F®¦S{Šð~a½ê{éë-Ž›_xáŠö‚–ìOÒ
麮”xÑõ;ï.V]Pž¿ì㢡®Ñ6¦ÊD”„øÁÄUóO]ïW7Ô·×MdDõÈ'c¡[úꙘð±ÿ`¥ÏpUYóÓЀ_“è
-á~Ö³_P^¥¶=3«Ó©ìËÃØÕOGŽZè^-ãå´ôr{l4ãînlZÍe@#	Èô^Óe·r­püøï*ï¦yƒaúÔo«Q½ÁíC«G?Ýh\óR\øxYB†¶¯„MLqÛ8Ëh:h˼­¬ ×gÿ5xu±!#}bÇÒÂÞ‹õ•«7pC›î2ö,kx‘êjü&»šç4Û¡´sòhÀ^ÞWj*êþ€¢XQÞgKêgò‡>-I95Ž×=ÞªÌ;ŸŸ’¬=OÍ~X†–†ë<­*ˆ¥í	§ämàxûæÚó‘×ÿ¾Ûwgë¼Ñ·àÝçŠ5ÆY	æ‹­oÜô/ï·ÖMž¬iºÖïÝ˺`¡Ü.i6ÿiR³¥!$m	+Øk>ê¹ uÌÛ9ØV´ÂÖn^®ý:ŠPAŒm˜ >¤ß[¶¾Çkði.“UØ°•#Õ?%süáëømÆsãúîl²5ÖÕm;x³5=,1Ði¼E•qÈðt᪖6Ò¾Õ¹ÜûœýŸ³™uk-f§U$
-®FŸóÄ’6+Ûw冘uhÄEs£:ò+…ïYQÿÇðÿÿ
ð«Â¨ÂbÿvþFendstream
+xÚíUkTgnõJÀ+Å€€¸
+æ2@	Š&X4–;((R’		$˜$ \(PÁ Bå"Pi¥´^€–‹ÁŠ‚g¹iL@°rÕtÐc—þÜýµggþÌû<Ï÷~Ï<ïwÎgfâáM ³‘ ØŠ	 ¤N®Þ‡@2É833'†ÄãM=çi,.-V^=!LJ*ô÷³Né¢W2ÜÒ¿š.ѽx5­¨Ü/+žÚDìñÆG&¦ÉÖ¼¶2eÊÞ.øFiHkBývÛöÞémqm:çØ*ÆáósƒÝÚ-½NZšn¶ë½ 9ðá&|äÀ“έ“µqy7v²&nßwazàEÎiæ
+Ž£vÐ44ûÀ‰P(¬pGžtCIÊŒßÛhìbÔöÈšûjs›•›ì“`ò õªK#µí!üR¦¼Qin.‹}Q…Ôäïyþ}ýιøŒâ—Õ§=+­—kw×뺻îõ:e¾,ÔrëÐH£¸J®ÎÊj¹'ÆHøáq›Žî;{KÅ>Ð1øîkÏ€\†;äüZ#£exðøõ0Š–©¬ËÎÈü«ƒ¯˜«Ë׊J,6‰J.Å%ÒúU7;»ÀªñŒ#9±ÌIfš^nðµGŽ·¯²lÞ(«Óë©9+“÷ékö+³¢ô&²Jq sF{63=Ã#ÀÍÓïK¸#ÍyIîÏÕê¾Ïʳ;ƶ$Œùª“™'Z_NXM‰Æ½µi—ºJýRÍ#áK
Ž63šôò³ëUL’Ó~“áwѧ‹[˜œÍšJ=÷Ó—qƒ¿O~¿±(„ðS´åЄrk_öL܈«ÁÉ2îs¥{Cu™±	±×~Ü.©'$çˆÊ’Ú•kžâoZvÞ÷€b—u4|ÌÄCC×½\vÅA;!A æºl¡,dv‡N„æü³R1-l5¢~ê‘®éݺcÏäÇÚ—¼FNíøIM±”´~WãÃ|0]}`ӛ̃Ï;ú¹Ÿ„þMwÖOý*¥Í£œgÎã“•¥þ´Ï½÷ýGsNÒ_üýéMb÷ºV©Q™/£*ejºD«õÍV¬ö!÷A=Ùœ•%ƒR½F²¯™¤Ùïî7ܱ‡3wá7©}˺q_Eb´½ŽWp£Îòc§?ßmÞýš›ÿì¸FtŠ|¸ˆO\ç_µJ¥>mF»/¨#Ö¦]øÕmW¡2%y>bKþÐõÆŠ]ó˜ÍÞ-íŽo˜mz•h¡ú6³ÊÃtµqqßBI%ÀØ6\¬.øˆ$Þ^6à®O¥±&>/Jhè÷˜ë’ä4ä&ä¸É¯D‘3Ÿ”"Å~­6:åøâžèË¢î
p”Q[MCÀ¿¦:ëZ7s÷œZ_(sQ­ŠÖì3нÛé\6ªÛºPËÞÝr{Ô1dˆ~MKÄoÓüyAv¸)$öÍKל±Ùˆ˜ä¤Œwl×7\—m´—ÄáûãÚæñO¨g·zÚŽOeÓèùMG˜Å“àèó&?~uT5â¿6|ô—¾}U]ÝÑÓ]ɾ±.¦síÒ”3Ê©;Û»	've»?fžìÛÏp9£Ñ?'×ZTËî©·AãIzb²½4zeÜ‚µ½¹œtÈÿáƒûƒÿ‰ØÕ
¡bD¡¡¸ôyþUendstream
 endobj
 689 0 obj <<
 /Type /Font
@@ -9421,14 +9404,14 @@ endobj
 /FirstChar 13
 /LastChar 110
 /Widths 1955 0 R
-/BaseFont /HGAPIH+CMSY10
+/BaseFont /GTAJFT+CMSY10
 /FontDescriptor 687 0 R
 >> endobj
 687 0 obj <<
 /Ascent 750
 /CapHeight 683
 /Descent -194
-/FontName /HGAPIH+CMSY10
+/FontName /GTAJFT+CMSY10
 /ItalicAngle -14.035
 /StemV 85
 /XHeight 431
@@ -9453,7 +9436,7 @@ endobj
 >>
 stream
 xÚ¬ºc”¤]°%\]èª.uÙȲmÛ¶]YV—mÛ¶mtÙ¶ºlÛÖ×ï{çÎug~Í7?r­çDÄÙ±#ö9±Ö“™$òJ4ƶ†@Q[GZzN€Š¢š¼••±¹­4¢­µ௙š„DÈhàhnk#làä¨Â@###€ƒƒš dkçfonjæ ÿ‹AAEEý_–B†nÿéù»ÓÁÜÔ@ú÷Áhekg
´qüñ½Q	8š&æV@€œ¼†„¬€\LV ´ÚXä­ÌÒæF@ ÀÄÖ`õ€‘­±ù?¥9ÐþÅpì€Fæ·]€vÿ¸¨v@{ks‡¿Ïs€©½ãß8ÚÌmŒ¬œŒÿ!ð×nbû/!;{Û¿Ö}ÁämŒìÍí³Ê‹þOG3Çr;˜ÿulMþFÛ9ýSÒ¿¾¿0½Žæ6G «ã?¹cs;+·¿¹ÿ‚ÙÙ›ÿKÃÉÁÜÆô¿Pì¦öÆV@‡¿0±ÿéÎÕ	ø_ª7°³³rûw·í¿Qÿ“ƒ¹£ÐÊ„šñoN#Ç¿¹MÍm éþ9*6&¶úÿ°;Ùý§ÏhÿoƒÈÿ93IÛÚX¹Œ&Ðt²¶ŽSÈÿïT¦ý'òÿ‰ÿŸüÿDÞÿâþwþ—Küÿ÷>ÿwhQ'++Ykà¿›ÿ9cÒ€†ŒÍÿm`mnåöŠÿï‘jÀÿ ù„‘p4øÛ
-Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†žþ¿ù”ÍÌ,mþi<˸€6Æÿû_‰þeN'/"ª¨,Bõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F3“×ÿ!ã¿@ÿµ–1p´7whý-›žáßâÿÇç¿V:ÿ
FÄÆÈÖøŸÓ¢äh`cü÷€ýOÃ?n#'{û¿ºþ{çÿýŸë:è
+Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†žþ¿ù”ÍÌ,mþi<˸€6Æÿû_‰þeN'+ %%$Kõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F3“×ÿ!ã¿@ÿµ–1p´7whý-›žáßâÿÇç¿V:ÿ
FÄÆÈÖøŸÓ¢äh`cü÷€ýOÃ?n#'{û¿ºþ{çÿýŸë:è
 4‚^ùckÄh‘š‘æX‹ž34!¬Õ×Ã6dWÒ \˜ï[mÛ퓺ÍQ¡ÿ^DÛ8ÅùÙê¶xj÷±/Iy0ÒƒfEÖ¼ÌÃñ"¢èÍGÜ mg£:ð§Ó-K;S‹ô¸ZÞ×d¥W=Ø™PPÔ-~ÿŽ;ÕÎduõDáKäœï‹Bühïm”RƒÚЂT[pzFšpüôH60:<4Ø}Ñ»M•óƒ„ËŽ4Â÷W66Ÿ¦J¹He‹êïÝn-6CoÑÕI9G¬ Œ¦§¥aŸáòäK‹Qîïcþ~Ÿ{4C›uÝ\VÚÜñÉëÁ3(!×áÍfª“ËѿѪ7ð^Å®Q¾4¢]G]·0žõÕX°G-Å¿iÞngó2ø*(žTñ³u_¾Œxô«‰ªjy¿Ý
 ¥$T³ØÄ^×âs:‰¿„³Ót»©È i+3«0€Ö~Z¦Ò‹Áº*ã¹®.òzbdÄhn“<£c¿§¯
 ë³ü>Ëä1os´˜™(ÏÂß_Ø⟣٦$z#zlúµ1R?m%„ƒWåc¹BI-8v‘øòKNxoŠá­†(׸œÒùÏ[4¹RÈFNH•ƒˆUIþj¢ïö…D«6Êh”oϯ[%Z0ïÆQ:Åç$؆­˜U‰ú!6Wã1YDæcô*þ`ß•ø¸qÅó¯Rrú†};V”¡ý!ÅYs>*²%èa¡ûG¶G\V­n63QËR]BlõõLƒšªNS±o³®Xãk”t¯Ž¿¥è%+Ú£|ŽÔuœÙ¨ýf4
l˜³®En>îg„	1æ„ÄNò]¨ß`Ф­×/i‰û5Òyµ˜7:ê	2M~¨‚´S&Ò>À{y$«É6W¼H?ŠÅÏÝÉÓ*S;£BÝŠÄIÕÓ¤¹ª|wf	ãÆ!â…@[|…9s³qÈŽ××—}>¹v¼¶±Ä¸©–ˆ2CÌQÕ™15Bj"«RŸóöÚ窙Ä;cF1rv/T…ÎeBPBœÐA/[ŒÒ'}¯ä •©Ú{rRŸñ[±p†âºÙ§9êppàÒ-ƒÅ”vÁ{:Æð"çd€BnRâtïn‹}¨Â‡‡5„P‡<ùáew”McÛb…
L™¯ÎýŽ’µú¹¬<,ÌÒ=¶I¥]¥¶‚•!ìk
ÎÔÄdùÝÊ:ó$q®éÞ®Šq¾ƒ¼Æ<ÃýÊ,svwA]¯cŽŸ™¾"{=Ÿ&ulc
^£çDÿ)a/{¦8N.§%	§q±ü5¥×KÇx20œqK;ÈjtTŽ¸y´&H*À͵§¶q¨p¥GsÓü G4%Dá—rnì$áD_f!º>Èø`k‹æógúCÞŽsNU¸ÁŸ2û¥çüUÔÎ7Ú-/3аÉt=ÂœZžZ÷öešElòÉåi³Ø!š±ýKŽœ—DíØûø½u×"ƒq”‚d¯²Ôšª 9僄U1ðêpbDþ±kWaGÚ”ªø5ÁÐç#Ç~ÞŸú§jÇÿ½B7$Åšš’”6ìG†g€y†µWÿÚ›¨¸ð‹Êö|Ÿ¹^qHcOG_ùÎ}ŒÝËîNÓPb¥j„úiQR}D™CTµ u(
Õ]ú·ð»è·¸{§¢e%‚ÓòåO™
Ú¡Þ=’Gf0ýa½<ŒjZ80P߬j…'¿Ú_/ü„ÑêaÍ·LšÖz‹€f1ÏÍRpÿß&áì88g=§u©Îc“ñÖ›í²!»GYº7ù:1’‚¾3¼rž.5»W¹"j> •Š2¦Õ?Ê{®!¹	ДÏ@ÏœüO©ªtºG©÷Ž’4Å%ü’Y×ÞöPðüid‘˃8LÖU/p„h[×ÿ1õ˜åô×îE¥JP(òCˆ¤‚§t¢8ꜧÝÎQ‹‚j%U×¼±†ÙŸJXµ¿LF-.=5†Oí~Ñ
 \jË9gWØÅ."FˆmßÝÔÇ‘ÓßAÌõ|ˆWj
p7MÐ"Kc20ȧåOh]9J°F®×Ò‡õíTNì)mC\Rà‰æ8èÄЗ|-	µÂ¸ÅæßËlÏB@\ë®4Ʋó˜•k™_̦CÍö˜T!Ô½\!ƒÂD×$×&miÀ槻ÁLÝ¢»?a|ÿ¤þë™ú*$÷¼66ÛëðÞºR¨p`N‹8¹Îs©2õóŸÉ×®aLç%¢)K–9CJN¼·ดÇÃ6ôqx~ë“;à@È÷<þ]ÍCļؽyùI©Ž6xóm·Lº¥—Óê©.Chøƒ‹ÿ<™a-^õÄÞU\u´úé,R8ô0V‰ƒÖ=iï$……ní±ª—Æ„®h„¸çM«KÈÅcóÇŒqØÌ8wƒZÃÊf;Íhi3‚{~„Ý($
 iÿót:ùÃûxxñÍš6ïÛ÷ÄKZ·ÏlŽ¸ŠŒbd|Oá±–kË¥þÎÏB™E‹¤»
-èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g ÅTÍ‘ûûÁ{Ë1LxméÌ­?b†‘Ü€±%Öé]¶çÛ'$5ˆç
}~Ü‹{Á47
ŒCS®¯çÏgá·!v(°Z^cß—"|ÏÉUÛëUÛ„³¾Éêºêo6–I‰®óì¢;ɬ	‹a6²ôÍEê—'ÅKÜv–Ý«kî]¥’*€Þÿ<þSÍ?´.õÞ>|»ùו{šV8IÉ€¸@²`!Cr}Ùu3MVÅògè¿<*4ËëαÁŸ%… Ò9zS7ú‘Ÿœ’âó:·©Ž6Z3_C¯h¬Q½ÉŒff]1.ärÔõ„ÀݺgŒ6 hnO+(HuXíY]dOUÝ&°†9&/×á!^cnȯ(«eHü€SdClvÌf‹•”ØME?ÛÔ³ÐZ›N˜´BfG1d>QÚj\¼È”Ï·îPΊŸ¿æà;j:Œáo2çI­`þ÷?Á…ÀÌÞÂÄÅÕÑÁÄÅîÿ¯¹¢endstream
+èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g ÅTÍ‘ûûÁ{Ë1LxméÌ­?b†‘Ü€±%Öé]¶çÛ'$5ˆç
}~Ü‹{Á47
ŒCS®¯çÏgá·!v(°Z^cß—"|ÏÉUÛëUÛ„³¾Éêºêo6–I‰®óì¢;ɬ	‹a6²ôÍEê—'ÅKÜv–Ý«kî]¥’*€Þÿ<þSÍ?´.õÞ>|»ùו{šV8IÉ€¸@²`!Cr}Ùu3MVÅògè¿<*4ËëαÁŸ%… Ò9zS7ú‘Ÿœ’âó:·©Ž6Z3_C¯h¬Q½ÉŒff]1.ärÔõ„ÀݺgŒ6 hnO+(HuXíY]dOUÝ&°†9&/×á!^cnȯ(«eHü€SdClvÌf‹•”ØME?ÛÔ³ÐZ›N˜´BfG1d>QÚj\¼È”Ï·îPΊŸ¿æà;j:Œáo2çI­`þ÷?Á…ÀÌÞÂÄÅÕÑÁÄÅîÿRk¹’endstream
 endobj
 686 0 obj <<
 /Type /Font
@@ -9551,14 +9534,14 @@ endobj
 /FirstChar 2
 /LastChar 216
 /Widths 1956 0 R
-/BaseFont /PEFRTE+URWPalladioL-Roma
+/BaseFont /NAKKCN+URWPalladioL-Roma
 /FontDescriptor 684 0 R
 >> endobj
 684 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /PEFRTE+URWPalladioL-Roma
+/FontName /NAKKCN+URWPalladioL-Roma
 /ItalicAngle 0
 /StemV 84
 /XHeight 469
@@ -9578,7 +9561,7 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚ¬zSm]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%c;CQ;[gZzNE5ykkc;iA;kc‚3)©£‰³…­°³	'š‰1°‰##)½‡£…™¹3ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿçJ&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
lzàlG`akdíbü»©Ý¿Ù;ÚýDØüø~Àä휜Œ-ì	~²Ê‹þOgsçr;Yü¸	ìL"íŒ\þ)é_¾˜¯³…­³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrúùÁþ§;ÿU'ÁÿV½½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþwþ·Cüÿ{žÿ;´¨‹µµ¬É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:I1Q%ªÿóFýWœüòÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`DlìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþõ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛdlTÇtº¥°jÑ^7KÒ» š¬ôªÇûS
+xÚ¬zSm]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%c;CQ;[gZzNE5ykkc;iA;kc‚3)©£‰³…­°³	'š‰1°‰##)½‡£…™¹3ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿçJ&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
lzàlG`akdíbü»©Ý¿Ù;ÚýDØüø~Àä휜Œ-ì	~²Ê‹þOgsçr;Yü¸	ìL"íŒ\þ)é_¾˜¯³…­³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrúùÁþ§;ÿU'ÁÿV½½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþwþ·Cüÿ{žÿ;´¨‹µµ¬É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:iaM1!ªÿóFýWœüòÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`DlìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþõ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛdlTÇtº¥°jÑ^7KÒ» š¬ôªÇûS
 Šº%`¸3LŽ7)ü‰]üQHžíá|ÒâP»šê
 ÿ\%ý}þ54>:2Ü{Ú„M•IÊå
 KåïƒÍ§©R!RÕDzÝžeÌ}øØ"œ³\ʤ!g?5íµ	Îk“T$f}QìŒ}}œ7Ãë–aI­zQ£Ø`{1®ËÊ›¡9sõ‰ór5úË<#¤=ø…ˆ´±36…è4Ó+òŽÇ¾a‘Ïp:‰é"“|:[5P6“Ó#\2®˜Æíß»OÍß
6.â'¢ÿp$iÊíù2ŸÒ;LÛ–Oòá ±Fóyº)‘ùµ©ãà~¥ŸC¡ë­„aø
ÅÑ«¨ÙûGæhg[&óâ<1—Xû²Âø{iª_“¸bf)¦Œ²§T˜
ÜÓ»GAe!ógF玦àUa!*ÚZ0Ÿðç/èa0¼€ž~£œ†äwÝo	âïfŸJ³xÛw®ÞaÇL¿õ0è^š`8¿Ú	Ù4Ùç÷Ï©4†V×"”]BÝ3pþà·½_) èIÞ\H$séåXŒ{Òb^Z,ÃÛ6ö©ÉÁ¬–R2µCÇŠ‰t(£ˆOܲÓ7‚9òó`e€²ä@y%0júAÈëRÿ˜à˜~xƒ4wÖ5çíÂàÖ±åmÝÓ×â}=Ð’tRX[>͔ҞÐRÔ "çH³l/é•_r> endobj
 660 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /UUJGFS+URWPalladioL-Bold
+/FontName /LADZGC+URWPalladioL-Bold
 /ItalicAngle 0
 /StemV 123
 /XHeight 471
@@ -11030,7 +11013,7 @@ endobj
 /Count -4
 >> endobj
 1964 0 obj <<
-/Names [(Access_Control_Lists) 1498 0 R (Bv9ARM.ch01) 879 0 R (Bv9ARM.ch02) 928 0 R (Bv9ARM.ch03) 945 0 R (Bv9ARM.ch04) 994 0 R (Bv9ARM.ch05) 1082 0 R (Bv9ARM.ch06) 1093 0 R (Bv9ARM.ch07) 1497 0 R (Bv9ARM.ch08) 1523 0 R (Bv9ARM.ch09) 1538 0 R (Bv9ARM.ch10) 1759 0 R (Configuration_File_Grammar) 1118 0 R (DNSSEC) 1061 0 R (Doc-Start) 659 0 R (Setting_TTLs) 1468 0 R (acache) 935 0 R (access_control) 1248 0 R (acl) 1126 0 R (address_match_lists) 1099 0 R (admin_tools) 968 0 R (appendix.A) 574 0 R (appendix.B) 610 0 R (bibliography) 1547 0 R (boolean_options) 1010 0 R (builtin) 1322 0 R (chapter*.1) 694 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 530 0 R (chapter.8) 554 0 R (cite.RFC1033) 1674 0 R (cite.RFC1034) 1559 0 R (cite.RFC1035) 1561 0 R (cite.RFC1101) 1656 0 R (cite.RFC1123) 1658 0 R (cite.RFC1183) 1618 0 R (cite.RFC1464) 1696 0 R (cite.RFC1535) 1604 0 R (cite.RFC1536) 1606 0 R (cite.RFC1537) 1676 0 R (cite.RFC1591) 1660 0 R (cite.RFC1706) 1620 0 R (cite.RFC1712) 1716 0 R (cite.RFC1713) 1698 0 R (cite.RFC1794) 1700 0 R (cite.RFC1876) 1622 0 R (cite.RFC1912) 1678 0 R (cite.RFC1982) 1608 0 R (cite.RFC1995) 1566 0 R (cite.RFC1996) 1568 0 R (cite.RFC2010) 1680 0 R (cite.RFC2052) 1624 0 R (cite.RFC2065) 1728 0 R (cite.RFC2136) 1570 0 R (cite.RFC2137) 1730 0 R (cite.RFC2163) 1626 0 R (cite.RFC2168) 1628 0 R (cite.RFC2181) 1572 0 R (cite.RFC2219) 1682 0 R (cite.RFC2230) 1630 0 R (cite.RFC2240) 1702 0 R (cite.RFC2308) 1574 0 R (cite.RFC2317) 1662 0 R (cite.RFC2345) 1704 0 R (cite.RFC2352) 1706 0 R (cite.RFC2535) 1732 0 R (cite.RFC2536) 1632 0 R (cite.RFC2537) 1634 0 R (cite.RFC2538) 1636 0 R (cite.RFC2539) 1638 0 R (cite.RFC2540) 1640 0 R (cite.RFC2671) 1576 0 R (cite.RFC2672) 1578 0 R (cite.RFC2673) 1718 0 R (cite.RFC2782) 1642 0 R (cite.RFC2825) 1686 0 R (cite.RFC2826) 1664 0 R (cite.RFC2845) 1580 0 R (cite.RFC2874) 1720 0 R (cite.RFC2915) 1644 0 R (cite.RFC2929) 1666 0 R (cite.RFC2930) 1582 0 R (cite.RFC2931) 1584 0 R (cite.RFC3007) 1586 0 R (cite.RFC3008) 1734 0 R (cite.RFC3071) 1708 0 R (cite.RFC3090) 1736 0 R (cite.RFC3110) 1646 0 R (cite.RFC3123) 1648 0 R (cite.RFC3225) 1592 0 R (cite.RFC3258) 1710 0 R (cite.RFC3445) 1738 0 R (cite.RFC3490) 1688 0 R (cite.RFC3491) 1690 0 R (cite.RFC3492) 1692 0 R (cite.RFC3596) 1650 0 R (cite.RFC3597) 1652 0 R (cite.RFC3645) 1588 0 R (cite.RFC3655) 1740 0 R (cite.RFC3658) 1742 0 R (cite.RFC3755) 1744 0 R (cite.RFC3757) 1746 0 R (cite.RFC3833) 1594 0 R (cite.RFC3845) 1748 0 R (cite.RFC3901) 1712 0 R (cite.RFC4033) 1596 0 R (cite.RFC4034) 1598 0 R (cite.RFC4035) 1600 0 R (cite.RFC4074) 1610 0 R (cite.RFC974) 1563 0 R (cite.id2500874) 1753 0 R (configuration_file_elements) 1094 0 R (controls_statement_definition_and_usage) 981 0 R (diagnostic_tools) 916 0 R (dynamic_update) 1004 0 R (dynamic_update_policies) 1056 0 R (dynamic_update_security) 1252 0 R (empty) 1324 0 R (historical_dns_information) 1540 0 R (id2466552) 880 0 R (id2466576) 881 0 R (id2467377) 1095 0 R (id2467534) 885 0 R (id2467544) 886 0 R (id2467716) 898 0 R (id2467737) 899 0 R (id2467771) 900 0 R (id2467856) 903 0 R (id2467948) 896 0 R (id2470253) 910 0 R (id2470277) 913 0 R (id2470375) 914 0 R (id2470396) 915 0 R (id2470426) 921 0 R (id2470530) 922 0 R (id2470556) 923 0 R (id2470590) 929 0 R (id2470617) 930 0 R (id2470630) 931 0 R (id2470724) 934 0 R (id2470734) 940 0 R (id2470766) 947 0 R (id2470782) 948 0 R (id2470805) 954 0 R (id2470822) 955 0 R (id2471159) 958 0 R (id2471164) 959 0 R (id2472979) 986 0 R (id2472990) 987 0 R (id2473374) 1019 0 R (id2473393) 1020 0 R (id2473828) 1036 0 R (id2473845) 1037 0 R (id2473883) 1042 0 R (id2473901) 1043 0 R (id2473912) 1044 0 R (id2474023) 1045 0 R (id2474149) 1046 0 R (id2474265) 1052 0 R (id2474279) 1053 0 R (id2474328) 1054 0 R (id2474465) 1062 0 R (id2474534) 1063 0 R (id2474613) 1068 0 R (id2474759) 1073 0 R (id2474889) 1075 0 R (id2474910) 1076 0 R (id2475012) 1083 0 R (id2476222) 1104 0 R (id2476250) 1109 0 R (id2476361) 1110 0 R (id2476444) 1111 0 R (id2476474) 1112 0 R (id2476549) 1119 0 R (id2476965) 1125 0 R (id2477076) 1127 0 R (id2477291) 1129 0 R (id2477652) 1136 0 R (id2477669) 1137 0 R (id2477692) 1138 0 R (id2477716) 1144 0 R (id2477943) 1148 0 R (id2478069) 1149 0 R (id2478121) 1155 0 R (id2478746) 1166 0 R (id2479514) 1172 0 R (id2479576) 1177 0 R (id2479965) 1179 0 R (id2480039) 1184 0 R (id2480103) 1187 0 R (id2480215) 1188 0 R (id2480230) 1189 0 R (id2482243) 1214 0 R (id2484179) 1240 0 R (id2484237) 1242 0 R (id2484737) 1257 0 R (id2485670) 1276 0 R (id2485798) 1278 0 R (id2486357) 1286 0 R (id2486856) 1305 0 R (id2488061) 1334 0 R (id2489252) 1352 0 R (id2489303) 1353 0 R (id2489453) 1355 0 R (id2490790) 1372 0 R (id2490797) 1373 0 R (id2490803) 1374 0 R (id2491293) 1382 0 R (id2491395) 1383 0 R (id2492864) 1431 0 R (id2493121) 1437 0 R (id2493139) 1438 0 R (id2493159) 1441 0 R (id2493396) 1443 0 R (id2494496) 1454 0 R (id2494624) 1456 0 R (id2494645) 1457 0 R (id2495076) 1463 0 R (id2495212) 1465 0 R (id2495230) 1466 0 R (id2495703) 1469 0 R (id2495828) 1475 0 R (id2495843) 1476 0 R (id2495955) 1478 0 R (id2495977) 1479 0 R (id2496038) 1484 0 R (id2496107) 1485 0 R (id2496144) 1486 0 R (id2496205) 1487 0 R (id2496821) 1508 0 R (id2496902) 1509 0 R (id2497030) 1510 0 R (id2497110) 1524 0 R (id2497115) 1525 0 R (id2497264) 1526 0 R (id2497281) 1527 0 R (id2497411) 1539 0 R (id2497582) 1546 0 R (id2497770) 1551 0 R (id2497772) 1557 0 R (id2497781) 1562 0 R (id2497804) 1558 0 R (id2497828) 1560 0 R (id2497864) 1571 0 R (id2497891) 1573 0 R (id2497916) 1565 0 R (id2497941) 1567 0 R (id2497964) 1569 0 R (id2498020) 1575 0 R (id2498046) 1577 0 R (id2498073) 1579 0 R (id2498135) 1581 0 R (id2498165) 1583 0 R (id2498195) 1585 0 R (id2498221) 1587 0 R (id2498296) 1590 0 R (id2498304) 1591 0 R (id2498330) 1593 0 R (id2498366) 1595 0 R (id2498432) 1597 0 R (id2498497) 1599 0 R (id2498562) 1602 0 R (id2498570) 1603 0 R (id2498596) 1605 0 R (id2498664) 1607 0 R (id2498699) 1609 0 R (id2498740) 1616 0 R (id2498745) 1617 0 R (id2498803) 1619 0 R (id2498840) 1627 0 R (id2498875) 1621 0 R (id2498930) 1623 0 R (id2498968) 1625 0 R (id2498994) 1629 0 R (id2499019) 1631 0 R (id2499046) 1633 0 R (id2499073) 1635 0 R (id2499112) 1637 0 R (id2499142) 1639 0 R (id2499172) 1641 0 R (id2499214) 1643 0 R (id2499248) 1645 0 R (id2499274) 1647 0 R (id2499298) 1649 0 R (id2499355) 1651 0 R (id2499380) 1654 0 R (id2499387) 1655 0 R (id2499413) 1657 0 R (id2499435) 1659 0 R (id2499459) 1661 0 R (id2499505) 1663 0 R (id2499528) 1665 0 R (id2499578) 1672 0 R (id2499654) 1673 0 R (id2499677) 1675 0 R (id2499704) 1677 0 R (id2499731) 1679 0 R (id2499767) 1681 0 R (id2499808) 1684 0 R (id2499813) 1685 0 R (id2499845) 1687 0 R (id2499891) 1689 0 R (id2499926) 1691 0 R (id2499953) 1694 0 R (id2499971) 1695 0 R (id2500061) 1697 0 R (id2500087) 1699 0 R (id2500113) 1701 0 R (id2500136) 1703 0 R (id2500182) 1705 0 R (id2500205) 1707 0 R (id2500232) 1709 0 R (id2500258) 1711 0 R (id2500295) 1714 0 R (id2500301) 1715 0 R (id2500359) 1717 0 R (id2500386) 1719 0 R (id2500422) 1726 0 R (id2500434) 1727 0 R (id2500473) 1729 0 R (id2500500) 1731 0 R (id2500530) 1733 0 R (id2500555) 1735 0 R (id2500582) 1737 0 R (id2500686) 1739 0 R (id2500723) 1741 0 R (id2500749) 1743 0 R (id2500776) 1745 0 R (id2500821) 1747 0 R (id2500862) 1750 0 R (id2500872) 1752 0 R (id2500874) 1754 0 R (incremental_zone_transfers) 1016 0 R (internet_drafts) 1749 0 R (ipv6addresses) 1077 0 R (journal) 1005 0 R (lwresd) 1084 0 R (man.dig) 1760 0 R (man.dnssec-keygen) 1809 0 R (man.dnssec-signzone) 1826 0 R (man.host) 1793 0 R (man.named) 1875 0 R (man.named-checkconf) 1846 0 R (man.named-checkzone) 1859 0 R (man.rndc) 1897 0 R (man.rndc-confgen) 1930 0 R (man.rndc.conf) 1910 0 R (notify) 995 0 R (options) 1203 0 R (page.1) 658 0 R (page.10) 920 0 R (page.100) 1779 0 R (page.101) 1783 0 R (page.102) 1788 0 R (page.103) 1800 0 R (page.104) 1805 0 R (page.105) 1817 0 R (page.106) 1822 0 R (page.107) 1833 0 R (page.108) 1838 0 R (page.109) 1843 0 R (page.11) 927 0 R (page.110) 1855 0 R (page.111) 1867 0 R (page.112) 1871 0 R (page.113) 1882 0 R (page.114) 1887 0 R (page.115) 1892 0 R (page.116) 1905 0 R (page.117) 1915 0 R (page.118) 1922 0 R (page.119) 1929 0 R (page.12) 939 0 R (page.120) 1938 0 R (page.13) 944 0 R (page.14) 953 0 R (page.15) 964 0 R (page.16) 972 0 R (page.17) 979 0 R (page.18) 985 0 R (page.19) 993 0 R (page.2) 683 0 R (page.20) 1015 0 R (page.21) 1025 0 R (page.22) 1030 0 R (page.23) 1034 0 R (page.24) 1041 0 R (page.25) 1050 0 R (page.26) 1060 0 R (page.27) 1067 0 R (page.28) 1072 0 R (page.29) 1081 0 R (page.3) 693 0 R (page.30) 1088 0 R (page.31) 1092 0 R (page.32) 1103 0 R (page.33) 1108 0 R (page.34) 1117 0 R (page.35) 1124 0 R (page.36) 1133 0 R (page.37) 1143 0 R (page.38) 1154 0 R (page.39) 1159 0 R (page.4) 748 0 R (page.40) 1165 0 R (page.41) 1171 0 R (page.42) 1176 0 R (page.43) 1183 0 R (page.44) 1194 0 R (page.45) 1198 0 R (page.46) 1202 0 R (page.47) 1207 0 R (page.48) 1213 0 R (page.49) 1219 0 R (page.5) 812 0 R (page.50) 1225 0 R (page.51) 1235 0 R (page.52) 1239 0 R (page.53) 1247 0 R (page.54) 1256 0 R (page.55) 1262 0 R (page.56) 1267 0 R (page.57) 1271 0 R (page.58) 1275 0 R (page.59) 1283 0 R (page.6) 874 0 R (page.60) 1290 0 R (page.61) 1295 0 R (page.62) 1303 0 R (page.63) 1311 0 R (page.64) 1318 0 R (page.65) 1329 0 R (page.66) 1333 0 R (page.67) 1339 0 R (page.68) 1345 0 R (page.69) 1351 0 R (page.7) 878 0 R (page.70) 1359 0 R (page.71) 1363 0 R (page.72) 1367 0 R (page.73) 1371 0 R (page.74) 1380 0 R (page.75) 1394 0 R (page.76) 1406 0 R (page.77) 1428 0 R (page.78) 1436 0 R (page.79) 1448 0 R (page.8) 895 0 R (page.80) 1453 0 R (page.81) 1462 0 R (page.82) 1474 0 R (page.83) 1483 0 R (page.84) 1492 0 R (page.85) 1496 0 R (page.86) 1503 0 R (page.87) 1514 0 R (page.88) 1518 0 R (page.89) 1522 0 R (page.9) 909 0 R (page.90) 1533 0 R (page.91) 1537 0 R (page.92) 1545 0 R (page.93) 1555 0 R (page.94) 1614 0 R (page.95) 1670 0 R (page.96) 1724 0 R (page.97) 1758 0 R (page.98) 1768 0 R (page.99) 1774 0 R (proposed_standards) 1021 0 R (query_address) 1258 0 R (rfcs) 905 0 R (rndc) 1139 0 R (root_delegation_only) 1390 0 R (rrset_ordering) 960 0 R (sample_configuration) 946 0 R (section*.10) 1683 0 R (section*.11) 1693 0 R (section*.12) 1713 0 R (section*.13) 1725 0 R (section*.14) 1751 0 R (section*.15) 1761 0 R (section*.16) 1762 0 R (section*.17) 1763 0 R (section*.18) 1769 0 R (section*.19) 1770 0 R (section*.2) 1550 0 R (section*.20) 1775 0 R (section*.21) 1784 0 R (section*.22) 1789 0 R (section*.23) 1790 0 R (section*.24) 1791 0 R (section*.25) 1792 0 R (section*.26) 1794 0 R (section*.27) 1795 0 R (section*.28) 1796 0 R (section*.29) 1806 0 R (section*.3) 1556 0 R (section*.30) 1807 0 R (section*.31) 1808 0 R (section*.32) 1810 0 R (section*.33) 1811 0 R (section*.34) 1812 0 R (section*.35) 1813 0 R (section*.36) 1818 0 R (section*.37) 1823 0 R (section*.38) 1824 0 R (section*.39) 1825 0 R (section*.4) 1564 0 R (section*.40) 1827 0 R (section*.41) 1828 0 R (section*.42) 1829 0 R (section*.43) 1834 0 R (section*.44) 1839 0 R (section*.45) 1844 0 R (section*.46) 1845 0 R (section*.47) 1847 0 R (section*.48) 1848 0 R (section*.49) 1849 0 R (section*.5) 1589 0 R (section*.50) 1850 0 R (section*.51) 1856 0 R (section*.52) 1857 0 R (section*.53) 1858 0 R (section*.54) 1860 0 R (section*.55) 1861 0 R (section*.56) 1862 0 R (section*.57) 1863 0 R (section*.58) 1872 0 R (section*.59) 1873 0 R (section*.6) 1601 0 R (section*.60) 1874 0 R (section*.61) 1876 0 R (section*.62) 1877 0 R (section*.63) 1878 0 R (section*.64) 1883 0 R (section*.65) 1888 0 R (section*.66) 1893 0 R (section*.67) 1894 0 R (section*.68) 1895 0 R (section*.69) 1896 0 R (section*.7) 1615 0 R (section*.70) 1898 0 R (section*.71) 1899 0 R (section*.72) 1900 0 R (section*.73) 1906 0 R (section*.74) 1907 0 R (section*.75) 1908 0 R (section*.76) 1909 0 R (section*.77) 1911 0 R (section*.78) 1916 0 R (section*.79) 1917 0 R (section*.8) 1653 0 R (section*.80) 1918 0 R (section*.81) 1923 0 R (section*.82) 1924 0 R (section*.83) 1925 0 R (section*.84) 1931 0 R (section*.85) 1932 0 R (section*.86) 1933 0 R (section*.87) 1934 0 R (section*.88) 1939 0 R (section*.89) 1940 0 R (section*.9) 1671 0 R (section*.90) 1941 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 478 0 R (section.7.1) 534 0 R (section.7.2) 538 0 R (section.7.3) 550 0 R (section.8.1) 558 0 R (section.8.2) 566 0 R (section.8.3) 570 0 R (section.A.1) 578 0 R (section.A.2) 586 0 R (section.A.3) 594 0 R (section.B.1) 614 0 R (section.B.10) 650 0 R (section.B.2) 618 0 R (section.B.3) 622 0 R (section.B.4) 626 0 R (section.B.5) 630 0 R (section.B.6) 634 0 R (section.B.7) 638 0 R (section.B.8) 642 0 R (section.B.9) 646 0 R (server_resource_limits) 1284 0 R (server_statement_definition_and_usage) 1231 0 R (server_statement_grammar) 1340 0 R (statsfile) 1209 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 330 0 R (subsection.6.2.12) 334 0 R (subsection.6.2.13) 338 0 R (subsection.6.2.14) 342 0 R (subsection.6.2.15) 346 0 R (subsection.6.2.16) 350 0 R (subsection.6.2.17) 430 0 R (subsection.6.2.18) 434 0 R (subsection.6.2.19) 438 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 442 0 R (subsection.6.2.21) 446 0 R (subsection.6.2.22) 450 0 R (subsection.6.2.23) 454 0 R (subsection.6.2.24) 458 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 482 0 R (subsection.6.3.2) 494 0 R (subsection.6.3.3) 498 0 R (subsection.6.3.4) 502 0 R (subsection.6.3.5) 506 0 R (subsection.6.3.6) 522 0 R (subsection.6.3.7) 526 0 R (subsection.7.2.1) 542 0 R (subsection.7.2.2) 546 0 R (subsection.8.1.1) 562 0 R (subsection.A.1.1) 582 0 R (subsection.A.2.1) 590 0 R (subsection.A.3.1) 598 0 R (subsection.A.3.2) 602 0 R (subsection.A.3.3) 606 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.10.3) 326 0 R (subsubsection.6.2.16.1) 354 0 R (subsubsection.6.2.16.10) 390 0 R (subsubsection.6.2.16.11) 394 0 R (subsubsection.6.2.16.12) 398 0 R (subsubsection.6.2.16.13) 402 0 R (subsubsection.6.2.16.14) 406 0 R (subsubsection.6.2.16.15) 410 0 R (subsubsection.6.2.16.16) 414 0 R (subsubsection.6.2.16.17) 418 0 R (subsubsection.6.2.16.18) 422 0 R (subsubsection.6.2.16.19) 426 0 R (subsubsection.6.2.16.2) 358 0 R (subsubsection.6.2.16.3) 362 0 R (subsubsection.6.2.16.4) 366 0 R (subsubsection.6.2.16.5) 370 0 R (subsubsection.6.2.16.6) 374 0 R (subsubsection.6.2.16.7) 378 0 R (subsubsection.6.2.16.8) 382 0 R (subsubsection.6.2.16.9) 386 0 R (subsubsection.6.2.24.1) 462 0 R (subsubsection.6.2.24.2) 466 0 R (subsubsection.6.2.24.3) 470 0 R (subsubsection.6.2.24.4) 474 0 R (subsubsection.6.3.1.1) 486 0 R (subsubsection.6.3.1.2) 490 0 R (subsubsection.6.3.5.1) 510 0 R (subsubsection.6.3.5.2) 514 0 R (subsubsection.6.3.5.3) 518 0 R (table.1.1) 887 0 R (table.1.2) 897 0 R (table.3.1) 956 0 R (table.3.2) 988 0 R (table.6.1) 1096 0 R (table.6.10) 1432 0 R (table.6.11) 1442 0 R (table.6.12) 1444 0 R (table.6.13) 1455 0 R (table.6.14) 1458 0 R (table.6.15) 1464 0 R (table.6.16) 1467 0 R (table.6.17) 1470 0 R (table.6.18) 1477 0 R (table.6.19) 1488 0 R (table.6.2) 1120 0 R (table.6.3) 1128 0 R (table.6.4) 1167 0 R (table.6.5) 1178 0 R (table.6.6) 1215 0 R (table.6.7) 1306 0 R (table.6.8) 1335 0 R (table.6.9) 1375 0 R (the_category_phrase) 1161 0 R (the_sortlist_statement) 1296 0 R (topology) 1291 0 R (tsig) 1035 0 R (tuning) 1307 0 R (types_of_resource_records_and_when_to_use_them) 904 0 R (view_statement_grammar) 1325 0 R (zone_statement_grammar) 1243 0 R (zone_transfers) 1011 0 R (zonefile_format) 1314 0 R]
+/Names [(Access_Control_Lists) 1498 0 R (Bv9ARM.ch01) 879 0 R (Bv9ARM.ch02) 928 0 R (Bv9ARM.ch03) 945 0 R (Bv9ARM.ch04) 994 0 R (Bv9ARM.ch05) 1082 0 R (Bv9ARM.ch06) 1093 0 R (Bv9ARM.ch07) 1497 0 R (Bv9ARM.ch08) 1523 0 R (Bv9ARM.ch09) 1538 0 R (Bv9ARM.ch10) 1759 0 R (Configuration_File_Grammar) 1118 0 R (DNSSEC) 1061 0 R (Doc-Start) 659 0 R (Setting_TTLs) 1468 0 R (acache) 935 0 R (access_control) 1248 0 R (acl) 1126 0 R (address_match_lists) 1099 0 R (admin_tools) 968 0 R (appendix.A) 574 0 R (appendix.B) 610 0 R (bibliography) 1547 0 R (boolean_options) 1010 0 R (builtin) 1322 0 R (chapter*.1) 694 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 530 0 R (chapter.8) 554 0 R (cite.RFC1033) 1674 0 R (cite.RFC1034) 1559 0 R (cite.RFC1035) 1561 0 R (cite.RFC1101) 1656 0 R (cite.RFC1123) 1658 0 R (cite.RFC1183) 1618 0 R (cite.RFC1464) 1696 0 R (cite.RFC1535) 1604 0 R (cite.RFC1536) 1606 0 R (cite.RFC1537) 1676 0 R (cite.RFC1591) 1660 0 R (cite.RFC1706) 1620 0 R (cite.RFC1712) 1716 0 R (cite.RFC1713) 1698 0 R (cite.RFC1794) 1700 0 R (cite.RFC1876) 1622 0 R (cite.RFC1912) 1678 0 R (cite.RFC1982) 1608 0 R (cite.RFC1995) 1566 0 R (cite.RFC1996) 1568 0 R (cite.RFC2010) 1680 0 R (cite.RFC2052) 1624 0 R (cite.RFC2065) 1728 0 R (cite.RFC2136) 1570 0 R (cite.RFC2137) 1730 0 R (cite.RFC2163) 1626 0 R (cite.RFC2168) 1628 0 R (cite.RFC2181) 1572 0 R (cite.RFC2219) 1682 0 R (cite.RFC2230) 1630 0 R (cite.RFC2240) 1702 0 R (cite.RFC2308) 1574 0 R (cite.RFC2317) 1662 0 R (cite.RFC2345) 1704 0 R (cite.RFC2352) 1706 0 R (cite.RFC2535) 1732 0 R (cite.RFC2536) 1632 0 R (cite.RFC2537) 1634 0 R (cite.RFC2538) 1636 0 R (cite.RFC2539) 1638 0 R (cite.RFC2540) 1640 0 R (cite.RFC2671) 1576 0 R (cite.RFC2672) 1578 0 R (cite.RFC2673) 1718 0 R (cite.RFC2782) 1642 0 R (cite.RFC2825) 1686 0 R (cite.RFC2826) 1664 0 R (cite.RFC2845) 1580 0 R (cite.RFC2874) 1720 0 R (cite.RFC2915) 1644 0 R (cite.RFC2929) 1666 0 R (cite.RFC2930) 1582 0 R (cite.RFC2931) 1584 0 R (cite.RFC3007) 1586 0 R (cite.RFC3008) 1734 0 R (cite.RFC3071) 1708 0 R (cite.RFC3090) 1736 0 R (cite.RFC3110) 1646 0 R (cite.RFC3123) 1648 0 R (cite.RFC3225) 1592 0 R (cite.RFC3258) 1710 0 R (cite.RFC3445) 1738 0 R (cite.RFC3490) 1688 0 R (cite.RFC3491) 1690 0 R (cite.RFC3492) 1692 0 R (cite.RFC3596) 1650 0 R (cite.RFC3597) 1652 0 R (cite.RFC3645) 1588 0 R (cite.RFC3655) 1740 0 R (cite.RFC3658) 1742 0 R (cite.RFC3755) 1744 0 R (cite.RFC3757) 1746 0 R (cite.RFC3833) 1594 0 R (cite.RFC3845) 1748 0 R (cite.RFC3901) 1712 0 R (cite.RFC4033) 1596 0 R (cite.RFC4034) 1598 0 R (cite.RFC4035) 1600 0 R (cite.RFC4074) 1610 0 R (cite.RFC974) 1563 0 R (cite.id2500881) 1753 0 R (configuration_file_elements) 1094 0 R (controls_statement_definition_and_usage) 981 0 R (diagnostic_tools) 916 0 R (dynamic_update) 1004 0 R (dynamic_update_policies) 1056 0 R (dynamic_update_security) 1252 0 R (empty) 1324 0 R (historical_dns_information) 1540 0 R (id2466555) 880 0 R (id2466579) 881 0 R (id2467538) 885 0 R (id2467547) 886 0 R (id2467719) 898 0 R (id2467740) 899 0 R (id2467774) 900 0 R (id2467859) 903 0 R (id2467952) 896 0 R (id2470257) 910 0 R (id2470280) 913 0 R (id2470378) 914 0 R (id2470400) 915 0 R (id2470429) 921 0 R (id2470533) 922 0 R (id2470560) 923 0 R (id2470594) 929 0 R (id2470620) 930 0 R (id2470633) 931 0 R (id2470727) 934 0 R (id2470738) 940 0 R (id2470770) 947 0 R (id2470786) 948 0 R (id2470808) 954 0 R (id2470825) 955 0 R (id2471162) 958 0 R (id2471168) 959 0 R (id2473118) 986 0 R (id2473130) 987 0 R (id2473514) 1019 0 R (id2473532) 1020 0 R (id2473968) 1036 0 R (id2473985) 1037 0 R (id2474023) 1042 0 R (id2474041) 1043 0 R (id2474120) 1044 0 R (id2474163) 1045 0 R (id2474220) 1046 0 R (id2474405) 1052 0 R (id2474419) 1053 0 R (id2474468) 1054 0 R (id2474604) 1062 0 R (id2474674) 1063 0 R (id2474753) 1068 0 R (id2474899) 1073 0 R (id2475029) 1075 0 R (id2475050) 1076 0 R (id2475152) 1083 0 R (id2475299) 1095 0 R (id2476226) 1104 0 R (id2476253) 1109 0 R (id2476364) 1110 0 R (id2476448) 1111 0 R (id2476477) 1112 0 R (id2476552) 1119 0 R (id2476968) 1125 0 R (id2477079) 1127 0 R (id2477294) 1129 0 R (id2477655) 1136 0 R (id2477672) 1137 0 R (id2477696) 1138 0 R (id2477719) 1144 0 R (id2477946) 1148 0 R (id2478072) 1149 0 R (id2478124) 1155 0 R (id2478749) 1166 0 R (id2479517) 1172 0 R (id2479579) 1177 0 R (id2479969) 1179 0 R (id2480110) 1184 0 R (id2480174) 1187 0 R (id2480218) 1188 0 R (id2480233) 1189 0 R (id2482519) 1214 0 R (id2484182) 1240 0 R (id2484241) 1242 0 R (id2484740) 1257 0 R (id2485673) 1276 0 R (id2485801) 1278 0 R (id2486292) 1286 0 R (id2486791) 1305 0 R (id2488000) 1334 0 R (id2489258) 1352 0 R (id2489309) 1353 0 R (id2489460) 1355 0 R (id2490796) 1372 0 R (id2490804) 1373 0 R (id2490809) 1374 0 R (id2491300) 1382 0 R (id2491401) 1383 0 R (id2492802) 1431 0 R (id2493059) 1437 0 R (id2493077) 1438 0 R (id2493097) 1441 0 R (id2493334) 1443 0 R (id2494365) 1454 0 R (id2494562) 1456 0 R (id2494583) 1457 0 R (id2495014) 1463 0 R (id2495150) 1465 0 R (id2495169) 1466 0 R (id2495641) 1469 0 R (id2495766) 1475 0 R (id2495781) 1476 0 R (id2495961) 1478 0 R (id2495984) 1479 0 R (id2496113) 1484 0 R (id2496182) 1485 0 R (id2496218) 1486 0 R (id2496280) 1487 0 R (id2496827) 1508 0 R (id2496908) 1509 0 R (id2496968) 1510 0 R (id2497116) 1524 0 R (id2497122) 1525 0 R (id2497202) 1526 0 R (id2497219) 1527 0 R (id2497417) 1539 0 R (id2497521) 1546 0 R (id2497708) 1551 0 R (id2497710) 1557 0 R (id2497719) 1562 0 R (id2497811) 1558 0 R (id2497834) 1560 0 R (id2497870) 1571 0 R (id2497897) 1573 0 R (id2497923) 1565 0 R (id2497947) 1567 0 R (id2497971) 1569 0 R (id2498026) 1575 0 R (id2498053) 1577 0 R (id2498080) 1579 0 R (id2498141) 1581 0 R (id2498171) 1583 0 R (id2498201) 1585 0 R (id2498228) 1587 0 R (id2498302) 1590 0 R (id2498310) 1591 0 R (id2498337) 1593 0 R (id2498373) 1595 0 R (id2498438) 1597 0 R (id2498503) 1599 0 R (id2498568) 1602 0 R (id2498577) 1603 0 R (id2498602) 1605 0 R (id2498670) 1607 0 R (id2498706) 1609 0 R (id2498746) 1616 0 R (id2498752) 1617 0 R (id2498809) 1619 0 R (id2498846) 1627 0 R (id2498882) 1621 0 R (id2498936) 1623 0 R (id2498974) 1625 0 R (id2499000) 1629 0 R (id2499026) 1631 0 R (id2499052) 1633 0 R (id2499079) 1635 0 R (id2499118) 1637 0 R (id2499148) 1639 0 R (id2499178) 1641 0 R (id2499221) 1643 0 R (id2499254) 1645 0 R (id2499281) 1647 0 R (id2499304) 1649 0 R (id2499362) 1651 0 R (id2499386) 1654 0 R (id2499394) 1655 0 R (id2499419) 1657 0 R (id2499442) 1659 0 R (id2499465) 1661 0 R (id2499511) 1663 0 R (id2499534) 1665 0 R (id2499653) 1672 0 R (id2499660) 1673 0 R (id2499684) 1675 0 R (id2499710) 1677 0 R (id2499737) 1679 0 R (id2499773) 1681 0 R (id2499814) 1684 0 R (id2499819) 1685 0 R (id2499851) 1687 0 R (id2499897) 1689 0 R (id2499932) 1691 0 R (id2499959) 1694 0 R (id2499977) 1695 0 R (id2500068) 1697 0 R (id2500093) 1699 0 R (id2500119) 1701 0 R (id2500142) 1703 0 R (id2500188) 1705 0 R (id2500212) 1707 0 R (id2500238) 1709 0 R (id2500264) 1711 0 R (id2500301) 1714 0 R (id2500308) 1715 0 R (id2500365) 1717 0 R (id2500392) 1719 0 R (id2500428) 1726 0 R (id2500440) 1727 0 R (id2500480) 1729 0 R (id2500506) 1731 0 R (id2500536) 1733 0 R (id2500562) 1735 0 R (id2500588) 1737 0 R (id2500693) 1739 0 R (id2500729) 1741 0 R (id2500756) 1743 0 R (id2500782) 1745 0 R (id2500827) 1747 0 R (id2500869) 1750 0 R (id2500878) 1752 0 R (id2500881) 1754 0 R (incremental_zone_transfers) 1016 0 R (internet_drafts) 1749 0 R (ipv6addresses) 1077 0 R (journal) 1005 0 R (lwresd) 1084 0 R (man.dig) 1760 0 R (man.dnssec-keygen) 1809 0 R (man.dnssec-signzone) 1826 0 R (man.host) 1793 0 R (man.named) 1875 0 R (man.named-checkconf) 1846 0 R (man.named-checkzone) 1859 0 R (man.rndc) 1897 0 R (man.rndc-confgen) 1930 0 R (man.rndc.conf) 1910 0 R (notify) 995 0 R (options) 1203 0 R (page.1) 658 0 R (page.10) 920 0 R (page.100) 1779 0 R (page.101) 1783 0 R (page.102) 1788 0 R (page.103) 1800 0 R (page.104) 1805 0 R (page.105) 1817 0 R (page.106) 1822 0 R (page.107) 1833 0 R (page.108) 1838 0 R (page.109) 1843 0 R (page.11) 927 0 R (page.110) 1855 0 R (page.111) 1867 0 R (page.112) 1871 0 R (page.113) 1882 0 R (page.114) 1887 0 R (page.115) 1892 0 R (page.116) 1905 0 R (page.117) 1915 0 R (page.118) 1922 0 R (page.119) 1929 0 R (page.12) 939 0 R (page.120) 1938 0 R (page.13) 944 0 R (page.14) 953 0 R (page.15) 964 0 R (page.16) 972 0 R (page.17) 979 0 R (page.18) 985 0 R (page.19) 993 0 R (page.2) 683 0 R (page.20) 1015 0 R (page.21) 1025 0 R (page.22) 1030 0 R (page.23) 1034 0 R (page.24) 1041 0 R (page.25) 1050 0 R (page.26) 1060 0 R (page.27) 1067 0 R (page.28) 1072 0 R (page.29) 1081 0 R (page.3) 693 0 R (page.30) 1088 0 R (page.31) 1092 0 R (page.32) 1103 0 R (page.33) 1108 0 R (page.34) 1117 0 R (page.35) 1124 0 R (page.36) 1133 0 R (page.37) 1143 0 R (page.38) 1154 0 R (page.39) 1159 0 R (page.4) 748 0 R (page.40) 1165 0 R (page.41) 1171 0 R (page.42) 1176 0 R (page.43) 1183 0 R (page.44) 1194 0 R (page.45) 1198 0 R (page.46) 1202 0 R (page.47) 1207 0 R (page.48) 1213 0 R (page.49) 1219 0 R (page.5) 812 0 R (page.50) 1225 0 R (page.51) 1235 0 R (page.52) 1239 0 R (page.53) 1247 0 R (page.54) 1256 0 R (page.55) 1262 0 R (page.56) 1267 0 R (page.57) 1271 0 R (page.58) 1275 0 R (page.59) 1283 0 R (page.6) 874 0 R (page.60) 1290 0 R (page.61) 1295 0 R (page.62) 1303 0 R (page.63) 1311 0 R (page.64) 1318 0 R (page.65) 1329 0 R (page.66) 1333 0 R (page.67) 1339 0 R (page.68) 1345 0 R (page.69) 1351 0 R (page.7) 878 0 R (page.70) 1359 0 R (page.71) 1363 0 R (page.72) 1367 0 R (page.73) 1371 0 R (page.74) 1380 0 R (page.75) 1394 0 R (page.76) 1406 0 R (page.77) 1428 0 R (page.78) 1436 0 R (page.79) 1448 0 R (page.8) 895 0 R (page.80) 1453 0 R (page.81) 1462 0 R (page.82) 1474 0 R (page.83) 1483 0 R (page.84) 1492 0 R (page.85) 1496 0 R (page.86) 1503 0 R (page.87) 1514 0 R (page.88) 1518 0 R (page.89) 1522 0 R (page.9) 909 0 R (page.90) 1533 0 R (page.91) 1537 0 R (page.92) 1545 0 R (page.93) 1555 0 R (page.94) 1614 0 R (page.95) 1670 0 R (page.96) 1724 0 R (page.97) 1758 0 R (page.98) 1768 0 R (page.99) 1774 0 R (proposed_standards) 1021 0 R (query_address) 1258 0 R (rfcs) 905 0 R (rndc) 1139 0 R (root_delegation_only) 1390 0 R (rrset_ordering) 960 0 R (sample_configuration) 946 0 R (section*.10) 1683 0 R (section*.11) 1693 0 R (section*.12) 1713 0 R (section*.13) 1725 0 R (section*.14) 1751 0 R (section*.15) 1761 0 R (section*.16) 1762 0 R (section*.17) 1763 0 R (section*.18) 1769 0 R (section*.19) 1770 0 R (section*.2) 1550 0 R (section*.20) 1775 0 R (section*.21) 1784 0 R (section*.22) 1789 0 R (section*.23) 1790 0 R (section*.24) 1791 0 R (section*.25) 1792 0 R (section*.26) 1794 0 R (section*.27) 1795 0 R (section*.28) 1796 0 R (section*.29) 1806 0 R (section*.3) 1556 0 R (section*.30) 1807 0 R (section*.31) 1808 0 R (section*.32) 1810 0 R (section*.33) 1811 0 R (section*.34) 1812 0 R (section*.35) 1813 0 R (section*.36) 1818 0 R (section*.37) 1823 0 R (section*.38) 1824 0 R (section*.39) 1825 0 R (section*.4) 1564 0 R (section*.40) 1827 0 R (section*.41) 1828 0 R (section*.42) 1829 0 R (section*.43) 1834 0 R (section*.44) 1839 0 R (section*.45) 1844 0 R (section*.46) 1845 0 R (section*.47) 1847 0 R (section*.48) 1848 0 R (section*.49) 1849 0 R (section*.5) 1589 0 R (section*.50) 1850 0 R (section*.51) 1856 0 R (section*.52) 1857 0 R (section*.53) 1858 0 R (section*.54) 1860 0 R (section*.55) 1861 0 R (section*.56) 1862 0 R (section*.57) 1863 0 R (section*.58) 1872 0 R (section*.59) 1873 0 R (section*.6) 1601 0 R (section*.60) 1874 0 R (section*.61) 1876 0 R (section*.62) 1877 0 R (section*.63) 1878 0 R (section*.64) 1883 0 R (section*.65) 1888 0 R (section*.66) 1893 0 R (section*.67) 1894 0 R (section*.68) 1895 0 R (section*.69) 1896 0 R (section*.7) 1615 0 R (section*.70) 1898 0 R (section*.71) 1899 0 R (section*.72) 1900 0 R (section*.73) 1906 0 R (section*.74) 1907 0 R (section*.75) 1908 0 R (section*.76) 1909 0 R (section*.77) 1911 0 R (section*.78) 1916 0 R (section*.79) 1917 0 R (section*.8) 1653 0 R (section*.80) 1918 0 R (section*.81) 1923 0 R (section*.82) 1924 0 R (section*.83) 1925 0 R (section*.84) 1931 0 R (section*.85) 1932 0 R (section*.86) 1933 0 R (section*.87) 1934 0 R (section*.88) 1939 0 R (section*.89) 1940 0 R (section*.9) 1671 0 R (section*.90) 1941 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 478 0 R (section.7.1) 534 0 R (section.7.2) 538 0 R (section.7.3) 550 0 R (section.8.1) 558 0 R (section.8.2) 566 0 R (section.8.3) 570 0 R (section.A.1) 578 0 R (section.A.2) 586 0 R (section.A.3) 594 0 R (section.B.1) 614 0 R (section.B.10) 650 0 R (section.B.2) 618 0 R (section.B.3) 622 0 R (section.B.4) 626 0 R (section.B.5) 630 0 R (section.B.6) 634 0 R (section.B.7) 638 0 R (section.B.8) 642 0 R (section.B.9) 646 0 R (server_resource_limits) 1284 0 R (server_statement_definition_and_usage) 1231 0 R (server_statement_grammar) 1340 0 R (statsfile) 1209 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 330 0 R (subsection.6.2.12) 334 0 R (subsection.6.2.13) 338 0 R (subsection.6.2.14) 342 0 R (subsection.6.2.15) 346 0 R (subsection.6.2.16) 350 0 R (subsection.6.2.17) 430 0 R (subsection.6.2.18) 434 0 R (subsection.6.2.19) 438 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 442 0 R (subsection.6.2.21) 446 0 R (subsection.6.2.22) 450 0 R (subsection.6.2.23) 454 0 R (subsection.6.2.24) 458 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 482 0 R (subsection.6.3.2) 494 0 R (subsection.6.3.3) 498 0 R (subsection.6.3.4) 502 0 R (subsection.6.3.5) 506 0 R (subsection.6.3.6) 522 0 R (subsection.6.3.7) 526 0 R (subsection.7.2.1) 542 0 R (subsection.7.2.2) 546 0 R (subsection.8.1.1) 562 0 R (subsection.A.1.1) 582 0 R (subsection.A.2.1) 590 0 R (subsection.A.3.1) 598 0 R (subsection.A.3.2) 602 0 R (subsection.A.3.3) 606 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.10.3) 326 0 R (subsubsection.6.2.16.1) 354 0 R (subsubsection.6.2.16.10) 390 0 R (subsubsection.6.2.16.11) 394 0 R (subsubsection.6.2.16.12) 398 0 R (subsubsection.6.2.16.13) 402 0 R (subsubsection.6.2.16.14) 406 0 R (subsubsection.6.2.16.15) 410 0 R (subsubsection.6.2.16.16) 414 0 R (subsubsection.6.2.16.17) 418 0 R (subsubsection.6.2.16.18) 422 0 R (subsubsection.6.2.16.19) 426 0 R (subsubsection.6.2.16.2) 358 0 R (subsubsection.6.2.16.3) 362 0 R (subsubsection.6.2.16.4) 366 0 R (subsubsection.6.2.16.5) 370 0 R (subsubsection.6.2.16.6) 374 0 R (subsubsection.6.2.16.7) 378 0 R (subsubsection.6.2.16.8) 382 0 R (subsubsection.6.2.16.9) 386 0 R (subsubsection.6.2.24.1) 462 0 R (subsubsection.6.2.24.2) 466 0 R (subsubsection.6.2.24.3) 470 0 R (subsubsection.6.2.24.4) 474 0 R (subsubsection.6.3.1.1) 486 0 R (subsubsection.6.3.1.2) 490 0 R (subsubsection.6.3.5.1) 510 0 R (subsubsection.6.3.5.2) 514 0 R (subsubsection.6.3.5.3) 518 0 R (table.1.1) 887 0 R (table.1.2) 897 0 R (table.3.1) 956 0 R (table.3.2) 988 0 R (table.6.1) 1096 0 R (table.6.10) 1432 0 R (table.6.11) 1442 0 R (table.6.12) 1444 0 R (table.6.13) 1455 0 R (table.6.14) 1458 0 R (table.6.15) 1464 0 R (table.6.16) 1467 0 R (table.6.17) 1470 0 R (table.6.18) 1477 0 R (table.6.19) 1488 0 R (table.6.2) 1120 0 R (table.6.3) 1128 0 R (table.6.4) 1167 0 R (table.6.5) 1178 0 R (table.6.6) 1215 0 R (table.6.7) 1306 0 R (table.6.8) 1335 0 R (table.6.9) 1375 0 R (the_category_phrase) 1161 0 R (the_sortlist_statement) 1296 0 R (topology) 1291 0 R (tsig) 1035 0 R (tuning) 1307 0 R (types_of_resource_records_and_when_to_use_them) 904 0 R (view_statement_grammar) 1325 0 R (zone_statement_grammar) 1243 0 R (zone_transfers) 1011 0 R (zonefile_format) 1314 0 R]
 /Limits [(Access_Control_Lists) (zonefile_format)]
 >> endobj
 1965 0 obj <<
@@ -11049,7 +11032,7 @@ endobj
 >> endobj
 1968 0 obj <<
 /Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20100121064739Z)
+/CreationDate (D:20100301013335Z)
 /PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
 >> endobj
 xref
@@ -11060,652 +11043,652 @@ xref
 0000000004 00000 f 
 0000000000 00000 f 
 0000000009 00000 n 
-0000067235 00000 n 
-0000679170 00000 n 
+0000067237 00000 n 
+0000679319 00000 n 
 0000000054 00000 n 
 0000000086 00000 n 
-0000067359 00000 n 
-0000679098 00000 n 
+0000067361 00000 n 
+0000679247 00000 n 
 0000000133 00000 n 
 0000000173 00000 n 
-0000067484 00000 n 
-0000679012 00000 n 
+0000067486 00000 n 
+0000679161 00000 n 
 0000000221 00000 n 
 0000000273 00000 n 
-0000067609 00000 n 
-0000678926 00000 n 
+0000067611 00000 n 
+0000679075 00000 n 
 0000000321 00000 n 
 0000000377 00000 n 
-0000071872 00000 n 
-0000678816 00000 n 
+0000071874 00000 n 
+0000678965 00000 n 
 0000000425 00000 n 
 0000000478 00000 n 
-0000071997 00000 n 
-0000678742 00000 n 
+0000071999 00000 n 
+0000678891 00000 n 
 0000000531 00000 n 
 0000000572 00000 n 
-0000072122 00000 n 
-0000678655 00000 n 
+0000072124 00000 n 
+0000678804 00000 n 
 0000000625 00000 n 
 0000000674 00000 n 
-0000072247 00000 n 
-0000678568 00000 n 
+0000072249 00000 n 
+0000678717 00000 n 
 0000000727 00000 n 
 0000000757 00000 n 
-0000076525 00000 n 
-0000678444 00000 n 
+0000076527 00000 n 
+0000678593 00000 n 
 0000000810 00000 n 
 0000000861 00000 n 
-0000076650 00000 n 
-0000678370 00000 n 
+0000076652 00000 n 
+0000678519 00000 n 
 0000000919 00000 n 
 0000000964 00000 n 
-0000076775 00000 n 
-0000678283 00000 n 
+0000076777 00000 n 
+0000678432 00000 n 
 0000001022 00000 n 
 0000001062 00000 n 
-0000076900 00000 n 
-0000678209 00000 n 
+0000076902 00000 n 
+0000678358 00000 n 
 0000001120 00000 n 
 0000001162 00000 n 
-0000079872 00000 n 
-0000678085 00000 n 
+0000079874 00000 n 
+0000678234 00000 n 
 0000001215 00000 n 
 0000001260 00000 n 
-0000079997 00000 n 
-0000678024 00000 n 
+0000079999 00000 n 
+0000678173 00000 n 
 0000001318 00000 n 
 0000001355 00000 n 
-0000080122 00000 n 
-0000677950 00000 n 
+0000080124 00000 n 
+0000678099 00000 n 
 0000001408 00000 n 
 0000001463 00000 n 
-0000083050 00000 n 
-0000677825 00000 n 
+0000083052 00000 n 
+0000677974 00000 n 
 0000001509 00000 n 
 0000001556 00000 n 
-0000083175 00000 n 
-0000677751 00000 n 
+0000083177 00000 n 
+0000677900 00000 n 
 0000001604 00000 n 
 0000001648 00000 n 
-0000083300 00000 n 
-0000677664 00000 n 
+0000083302 00000 n 
+0000677813 00000 n 
 0000001696 00000 n 
 0000001735 00000 n 
-0000083425 00000 n 
-0000677577 00000 n 
+0000083427 00000 n 
+0000677726 00000 n 
 0000001783 00000 n 
 0000001825 00000 n 
-0000083549 00000 n 
-0000677490 00000 n 
+0000083551 00000 n 
+0000677639 00000 n 
 0000001873 00000 n 
 0000001936 00000 n 
-0000084632 00000 n 
-0000677416 00000 n 
+0000084634 00000 n 
+0000677565 00000 n 
 0000001984 00000 n 
 0000002034 00000 n 
-0000086335 00000 n 
-0000677288 00000 n 
+0000086337 00000 n 
+0000677437 00000 n 
 0000002080 00000 n 
 0000002126 00000 n 
-0000086459 00000 n 
-0000677175 00000 n 
+0000086461 00000 n 
+0000677324 00000 n 
 0000002174 00000 n 
 0000002218 00000 n 
-0000086584 00000 n 
-0000677099 00000 n 
+0000086586 00000 n 
+0000677248 00000 n 
 0000002271 00000 n 
 0000002323 00000 n 
-0000086709 00000 n 
-0000677022 00000 n 
+0000086711 00000 n 
+0000677171 00000 n 
 0000002377 00000 n 
 0000002436 00000 n 
-0000089237 00000 n 
-0000676931 00000 n 
+0000089239 00000 n 
+0000677080 00000 n 
 0000002485 00000 n 
 0000002523 00000 n 
-0000089489 00000 n 
-0000676814 00000 n 
+0000089491 00000 n 
+0000676963 00000 n 
 0000002572 00000 n 
 0000002618 00000 n 
-0000089615 00000 n 
-0000676696 00000 n 
+0000089617 00000 n 
+0000676845 00000 n 
 0000002672 00000 n 
 0000002739 00000 n 
-0000092837 00000 n 
-0000676617 00000 n 
+0000092839 00000 n 
+0000676766 00000 n 
 0000002798 00000 n 
 0000002842 00000 n 
-0000092963 00000 n 
-0000676538 00000 n 
+0000092965 00000 n 
+0000676687 00000 n 
 0000002901 00000 n 
 0000002949 00000 n 
-0000103401 00000 n 
-0000676459 00000 n 
+0000103403 00000 n 
+0000676608 00000 n 
 0000003003 00000 n 
 0000003036 00000 n 
-0000108371 00000 n 
-0000676327 00000 n 
+0000108373 00000 n 
+0000676476 00000 n 
 0000003083 00000 n 
 0000003126 00000 n 
-0000108497 00000 n 
-0000676248 00000 n 
+0000108499 00000 n 
+0000676397 00000 n 
 0000003175 00000 n 
 0000003205 00000 n 
-0000108623 00000 n 
-0000676116 00000 n 
+0000108625 00000 n 
+0000676265 00000 n 
 0000003254 00000 n 
 0000003292 00000 n 
-0000108750 00000 n 
-0000676051 00000 n 
+0000108752 00000 n 
+0000676200 00000 n 
 0000003346 00000 n 
 0000003388 00000 n 
-0000113043 00000 n 
-0000675958 00000 n 
+0000113045 00000 n 
+0000676107 00000 n 
 0000003437 00000 n 
 0000003496 00000 n 
-0000113170 00000 n 
-0000675826 00000 n 
+0000113172 00000 n 
+0000675975 00000 n 
 0000003545 00000 n 
 0000003578 00000 n 
-0000113299 00000 n 
-0000675761 00000 n 
+0000113301 00000 n 
+0000675910 00000 n 
 0000003632 00000 n 
 0000003681 00000 n 
-0000120671 00000 n 
-0000675629 00000 n 
+0000120673 00000 n 
+0000675778 00000 n 
 0000003730 00000 n 
 0000003758 00000 n 
-0000120798 00000 n 
-0000675511 00000 n 
+0000120800 00000 n 
+0000675660 00000 n 
 0000003812 00000 n 
 0000003881 00000 n 
-0000120927 00000 n 
-0000675432 00000 n 
+0000120929 00000 n 
+0000675581 00000 n 
 0000003940 00000 n 
 0000003988 00000 n 
-0000123823 00000 n 
-0000675353 00000 n 
+0000123825 00000 n 
+0000675502 00000 n 
 0000004047 00000 n 
 0000004092 00000 n 
-0000123952 00000 n 
-0000675260 00000 n 
+0000123954 00000 n 
+0000675409 00000 n 
 0000004146 00000 n 
 0000004214 00000 n 
-0000124081 00000 n 
-0000675167 00000 n 
+0000124083 00000 n 
+0000675316 00000 n 
 0000004268 00000 n 
 0000004338 00000 n 
-0000124210 00000 n 
-0000675074 00000 n 
+0000124212 00000 n 
+0000675223 00000 n 
 0000004392 00000 n 
 0000004455 00000 n 
-0000124338 00000 n 
-0000674981 00000 n 
+0000124340 00000 n 
+0000675130 00000 n 
 0000004509 00000 n 
 0000004564 00000 n 
-0000128005 00000 n 
-0000674902 00000 n 
+0000128007 00000 n 
+0000675051 00000 n 
 0000004618 00000 n 
 0000004650 00000 n 
-0000128134 00000 n 
-0000674809 00000 n 
+0000128136 00000 n 
+0000674958 00000 n 
 0000004699 00000 n 
 0000004727 00000 n 
-0000128263 00000 n 
-0000674716 00000 n 
+0000128265 00000 n 
+0000674865 00000 n 
 0000004776 00000 n 
 0000004808 00000 n 
-0000131869 00000 n 
-0000674584 00000 n 
+0000131871 00000 n 
+0000674733 00000 n 
 0000004857 00000 n 
 0000004887 00000 n 
-0000131998 00000 n 
-0000674505 00000 n 
+0000132000 00000 n 
+0000674654 00000 n 
 0000004941 00000 n 
 0000004982 00000 n 
-0000132126 00000 n 
-0000674412 00000 n 
+0000132128 00000 n 
+0000674561 00000 n 
 0000005036 00000 n 
 0000005078 00000 n 
-0000135588 00000 n 
-0000674333 00000 n 
+0000135590 00000 n 
+0000674482 00000 n 
 0000005132 00000 n 
 0000005177 00000 n 
-0000138662 00000 n 
-0000674215 00000 n 
+0000138664 00000 n 
+0000674364 00000 n 
 0000005226 00000 n 
 0000005272 00000 n 
-0000138791 00000 n 
-0000674136 00000 n 
+0000138793 00000 n 
+0000674285 00000 n 
 0000005326 00000 n 
 0000005386 00000 n 
-0000138919 00000 n 
-0000674057 00000 n 
+0000138921 00000 n 
+0000674206 00000 n 
 0000005440 00000 n 
 0000005509 00000 n 
-0000141400 00000 n 
-0000673924 00000 n 
+0000141402 00000 n 
+0000674073 00000 n 
 0000005556 00000 n 
 0000005609 00000 n 
-0000141529 00000 n 
-0000673845 00000 n 
+0000141531 00000 n 
+0000673994 00000 n 
 0000005658 00000 n 
 0000005714 00000 n 
-0000141658 00000 n 
-0000673766 00000 n 
+0000141660 00000 n 
+0000673915 00000 n 
 0000005763 00000 n 
 0000005812 00000 n 
-0000145842 00000 n 
-0000673633 00000 n 
+0000145844 00000 n 
+0000673782 00000 n 
 0000005859 00000 n 
 0000005911 00000 n 
-0000145971 00000 n 
-0000673515 00000 n 
+0000145973 00000 n 
+0000673664 00000 n 
 0000005960 00000 n 
 0000006011 00000 n 
-0000150578 00000 n 
-0000673397 00000 n 
+0000150580 00000 n 
+0000673546 00000 n 
 0000006065 00000 n 
 0000006110 00000 n 
-0000150705 00000 n 
-0000673318 00000 n 
+0000150707 00000 n 
+0000673467 00000 n 
 0000006169 00000 n 
 0000006203 00000 n 
-0000154163 00000 n 
-0000673239 00000 n 
+0000154165 00000 n 
+0000673388 00000 n 
 0000006262 00000 n 
 0000006310 00000 n 
-0000154292 00000 n 
-0000673121 00000 n 
+0000154294 00000 n 
+0000673270 00000 n 
 0000006364 00000 n 
 0000006404 00000 n 
-0000154421 00000 n 
-0000673042 00000 n 
+0000154423 00000 n 
+0000673191 00000 n 
 0000006463 00000 n 
 0000006497 00000 n 
-0000154550 00000 n 
-0000672963 00000 n 
+0000154552 00000 n 
+0000673112 00000 n 
 0000006556 00000 n 
 0000006604 00000 n 
-0000158541 00000 n 
-0000672830 00000 n 
+0000158543 00000 n 
+0000672979 00000 n 
 0000006653 00000 n 
 0000006703 00000 n 
-0000161811 00000 n 
-0000672751 00000 n 
+0000161813 00000 n 
+0000672900 00000 n 
 0000006757 00000 n 
 0000006804 00000 n 
-0000161940 00000 n 
-0000672658 00000 n 
+0000161942 00000 n 
+0000672807 00000 n 
 0000006858 00000 n 
 0000006918 00000 n 
-0000162198 00000 n 
-0000672565 00000 n 
+0000162200 00000 n 
+0000672714 00000 n 
 0000006972 00000 n 
 0000007024 00000 n 
-0000162327 00000 n 
-0000672472 00000 n 
+0000162329 00000 n 
+0000672621 00000 n 
 0000007078 00000 n 
 0000007143 00000 n 
-0000166928 00000 n 
-0000672379 00000 n 
+0000166930 00000 n 
+0000672528 00000 n 
 0000007197 00000 n 
 0000007248 00000 n 
-0000167054 00000 n 
-0000672286 00000 n 
+0000167056 00000 n 
+0000672435 00000 n 
 0000007302 00000 n 
 0000007366 00000 n 
-0000167183 00000 n 
-0000672193 00000 n 
+0000167185 00000 n 
+0000672342 00000 n 
 0000007420 00000 n 
 0000007467 00000 n 
-0000170945 00000 n 
-0000672100 00000 n 
+0000170947 00000 n 
+0000672249 00000 n 
 0000007521 00000 n 
 0000007581 00000 n 
-0000171074 00000 n 
-0000672007 00000 n 
+0000171076 00000 n 
+0000672156 00000 n 
 0000007635 00000 n 
 0000007686 00000 n 
-0000171203 00000 n 
-0000671875 00000 n 
+0000171205 00000 n 
+0000672024 00000 n 
 0000007741 00000 n 
 0000007806 00000 n 
-0000175735 00000 n 
-0000671796 00000 n 
+0000175737 00000 n 
+0000671945 00000 n 
 0000007866 00000 n 
 0000007913 00000 n 
-0000182174 00000 n 
-0000671703 00000 n 
+0000182176 00000 n 
+0000671852 00000 n 
 0000007973 00000 n 
 0000008021 00000 n 
-0000185653 00000 n 
-0000671624 00000 n 
+0000185655 00000 n 
+0000671773 00000 n 
 0000008081 00000 n 
 0000008135 00000 n 
-0000189114 00000 n 
-0000671531 00000 n 
+0000189116 00000 n 
+0000671680 00000 n 
 0000008190 00000 n 
 0000008240 00000 n 
-0000191939 00000 n 
-0000671438 00000 n 
+0000191941 00000 n 
+0000671587 00000 n 
 0000008295 00000 n 
 0000008358 00000 n 
-0000192068 00000 n 
-0000671345 00000 n 
+0000192070 00000 n 
+0000671494 00000 n 
 0000008413 00000 n 
 0000008465 00000 n 
-0000192197 00000 n 
-0000671252 00000 n 
+0000192199 00000 n 
+0000671401 00000 n 
 0000008520 00000 n 
 0000008585 00000 n 
-0000192326 00000 n 
-0000671159 00000 n 
+0000192328 00000 n 
+0000671308 00000 n 
 0000008640 00000 n 
 0000008692 00000 n 
-0000198793 00000 n 
-0000671026 00000 n 
+0000198795 00000 n 
+0000671175 00000 n 
 0000008747 00000 n 
 0000008812 00000 n 
-0000206888 00000 n 
-0000670947 00000 n 
+0000206890 00000 n 
+0000671096 00000 n 
 0000008872 00000 n 
 0000008916 00000 n 
-0000224498 00000 n 
-0000670854 00000 n 
+0000224500 00000 n 
+0000671003 00000 n 
 0000008976 00000 n 
 0000009015 00000 n 
-0000224627 00000 n 
-0000670761 00000 n 
+0000224629 00000 n 
+0000670910 00000 n 
 0000009075 00000 n 
 0000009122 00000 n 
-0000229140 00000 n 
-0000670668 00000 n 
+0000229142 00000 n 
+0000670817 00000 n 
 0000009182 00000 n 
 0000009225 00000 n 
-0000232242 00000 n 
-0000670575 00000 n 
+0000232244 00000 n 
+0000670724 00000 n 
 0000009285 00000 n 
 0000009324 00000 n 
-0000232371 00000 n 
-0000670482 00000 n 
+0000232373 00000 n 
+0000670631 00000 n 
 0000009384 00000 n 
 0000009426 00000 n 
-0000239620 00000 n 
-0000670389 00000 n 
+0000239622 00000 n 
+0000670538 00000 n 
 0000009486 00000 n 
 0000009529 00000 n 
-0000247388 00000 n 
-0000670296 00000 n 
+0000247390 00000 n 
+0000670445 00000 n 
 0000009589 00000 n 
 0000009632 00000 n 
-0000247517 00000 n 
-0000670203 00000 n 
+0000247519 00000 n 
+0000670352 00000 n 
 0000009692 00000 n 
 0000009753 00000 n 
-0000251446 00000 n 
-0000670110 00000 n 
+0000251448 00000 n 
+0000670259 00000 n 
 0000009814 00000 n 
 0000009866 00000 n 
-0000251575 00000 n 
-0000670017 00000 n 
+0000251577 00000 n 
+0000670166 00000 n 
 0000009927 00000 n 
 0000009980 00000 n 
-0000254642 00000 n 
-0000669924 00000 n 
+0000254644 00000 n 
+0000670073 00000 n 
 0000010041 00000 n 
 0000010079 00000 n 
-0000258713 00000 n 
-0000669831 00000 n 
+0000258715 00000 n 
+0000669980 00000 n 
 0000010140 00000 n 
 0000010192 00000 n 
-0000261945 00000 n 
-0000669738 00000 n 
+0000262092 00000 n 
+0000669887 00000 n 
 0000010253 00000 n 
 0000010297 00000 n 
-0000262202 00000 n 
-0000669645 00000 n 
+0000262349 00000 n 
+0000669794 00000 n 
 0000010358 00000 n 
 0000010394 00000 n 
-0000271167 00000 n 
-0000669552 00000 n 
+0000271322 00000 n 
+0000669701 00000 n 
 0000010455 00000 n 
 0000010518 00000 n 
-0000271296 00000 n 
-0000669459 00000 n 
+0000271451 00000 n 
+0000669608 00000 n 
 0000010579 00000 n 
 0000010629 00000 n 
-0000277445 00000 n 
-0000669366 00000 n 
+0000277600 00000 n 
+0000669515 00000 n 
 0000010690 00000 n 
 0000010739 00000 n 
-0000277703 00000 n 
-0000669287 00000 n 
+0000277858 00000 n 
+0000669436 00000 n 
 0000010800 00000 n 
 0000010856 00000 n 
-0000281169 00000 n 
-0000669194 00000 n 
+0000281324 00000 n 
+0000669343 00000 n 
 0000010911 00000 n 
 0000010962 00000 n 
-0000281298 00000 n 
-0000669101 00000 n 
+0000281453 00000 n 
+0000669250 00000 n 
 0000011017 00000 n 
 0000011081 00000 n 
-0000289908 00000 n 
-0000669008 00000 n 
+0000290063 00000 n 
+0000669157 00000 n 
 0000011136 00000 n 
 0000011193 00000 n 
-0000290037 00000 n 
-0000668915 00000 n 
+0000290192 00000 n 
+0000669064 00000 n 
 0000011248 00000 n 
 0000011318 00000 n 
-0000290165 00000 n 
-0000668822 00000 n 
+0000290320 00000 n 
+0000668971 00000 n 
 0000011373 00000 n 
 0000011422 00000 n 
-0000290294 00000 n 
-0000668729 00000 n 
+0000290449 00000 n 
+0000668878 00000 n 
 0000011477 00000 n 
 0000011539 00000 n 
-0000292540 00000 n 
-0000668636 00000 n 
+0000292695 00000 n 
+0000668785 00000 n 
 0000011594 00000 n 
 0000011643 00000 n 
-0000298725 00000 n 
-0000668518 00000 n 
+0000298880 00000 n 
+0000668667 00000 n 
 0000011698 00000 n 
 0000011760 00000 n 
-0000298853 00000 n 
-0000668439 00000 n 
+0000299008 00000 n 
+0000668588 00000 n 
 0000011820 00000 n 
 0000011859 00000 n 
-0000303880 00000 n 
-0000668346 00000 n 
+0000304035 00000 n 
+0000668495 00000 n 
 0000011919 00000 n 
 0000011953 00000 n 
-0000304009 00000 n 
-0000668253 00000 n 
+0000304164 00000 n 
+0000668402 00000 n 
 0000012013 00000 n 
 0000012054 00000 n 
-0000319667 00000 n 
-0000668174 00000 n 
+0000319822 00000 n 
+0000668323 00000 n 
 0000012114 00000 n 
 0000012166 00000 n 
-0000323570 00000 n 
-0000668056 00000 n 
+0000323725 00000 n 
+0000668205 00000 n 
 0000012215 00000 n 
 0000012248 00000 n 
-0000323699 00000 n 
-0000667938 00000 n 
+0000323854 00000 n 
+0000668087 00000 n 
 0000012302 00000 n 
 0000012374 00000 n 
-0000323826 00000 n 
-0000667859 00000 n 
+0000323981 00000 n 
+0000668008 00000 n 
 0000012433 00000 n 
 0000012477 00000 n 
-0000331369 00000 n 
-0000667780 00000 n 
+0000331524 00000 n 
+0000667929 00000 n 
 0000012536 00000 n 
 0000012589 00000 n 
-0000335141 00000 n 
-0000667687 00000 n 
+0000335296 00000 n 
+0000667836 00000 n 
 0000012643 00000 n 
 0000012693 00000 n 
-0000335399 00000 n 
-0000667594 00000 n 
+0000335554 00000 n 
+0000667743 00000 n 
 0000012747 00000 n 
 0000012785 00000 n 
-0000338645 00000 n 
-0000667501 00000 n 
+0000338800 00000 n 
+0000667650 00000 n 
 0000012839 00000 n 
 0000012888 00000 n 
-0000338903 00000 n 
-0000667369 00000 n 
+0000339058 00000 n 
+0000667518 00000 n 
 0000012942 00000 n 
 0000012994 00000 n 
-0000339032 00000 n 
-0000667290 00000 n 
+0000339187 00000 n 
+0000667439 00000 n 
 0000013053 00000 n 
 0000013105 00000 n 
-0000341860 00000 n 
-0000667197 00000 n 
+0000342015 00000 n 
+0000667346 00000 n 
 0000013164 00000 n 
 0000013217 00000 n 
-0000341989 00000 n 
-0000667118 00000 n 
+0000342144 00000 n 
+0000667267 00000 n 
 0000013276 00000 n 
 0000013325 00000 n 
-0000342118 00000 n 
-0000667025 00000 n 
+0000342273 00000 n 
+0000667174 00000 n 
 0000013379 00000 n 
 0000013459 00000 n 
-0000346156 00000 n 
-0000666946 00000 n 
+0000346311 00000 n 
+0000667095 00000 n 
 0000013513 00000 n 
 0000013562 00000 n 
-0000348053 00000 n 
-0000666813 00000 n 
+0000348208 00000 n 
+0000666962 00000 n 
 0000013609 00000 n 
 0000013661 00000 n 
-0000348182 00000 n 
-0000666734 00000 n 
+0000348337 00000 n 
+0000666883 00000 n 
 0000013710 00000 n 
 0000013754 00000 n 
-0000352288 00000 n 
-0000666602 00000 n 
+0000352443 00000 n 
+0000666751 00000 n 
 0000013803 00000 n 
 0000013844 00000 n 
-0000352417 00000 n 
-0000666523 00000 n 
+0000352572 00000 n 
+0000666672 00000 n 
 0000013898 00000 n 
 0000013946 00000 n 
-0000352546 00000 n 
-0000666444 00000 n 
+0000352701 00000 n 
+0000666593 00000 n 
 0000014000 00000 n 
 0000014051 00000 n 
-0000352675 00000 n 
-0000666365 00000 n 
+0000352830 00000 n 
+0000666514 00000 n 
 0000014100 00000 n 
 0000014147 00000 n 
-0000356940 00000 n 
-0000666232 00000 n 
+0000357095 00000 n 
+0000666381 00000 n 
 0000014194 00000 n 
 0000014231 00000 n 
-0000357069 00000 n 
-0000666114 00000 n 
+0000357224 00000 n 
+0000666263 00000 n 
 0000014280 00000 n 
 0000014319 00000 n 
-0000357198 00000 n 
-0000666049 00000 n 
+0000357353 00000 n 
+0000666198 00000 n 
 0000014373 00000 n 
 0000014451 00000 n 
-0000357327 00000 n 
-0000665956 00000 n 
+0000357482 00000 n 
+0000666105 00000 n 
 0000014500 00000 n 
 0000014567 00000 n 
-0000357456 00000 n 
-0000665877 00000 n 
+0000357611 00000 n 
+0000666026 00000 n 
 0000014616 00000 n 
 0000014661 00000 n 
-0000360895 00000 n 
-0000665744 00000 n 
+0000361050 00000 n 
+0000665893 00000 n 
 0000014709 00000 n 
 0000014741 00000 n 
-0000361024 00000 n 
-0000665626 00000 n 
+0000361179 00000 n 
+0000665775 00000 n 
 0000014790 00000 n 
 0000014829 00000 n 
-0000361153 00000 n 
-0000665561 00000 n 
+0000361308 00000 n 
+0000665710 00000 n 
 0000014883 00000 n 
 0000014944 00000 n 
-0000364834 00000 n 
-0000665429 00000 n 
+0000364989 00000 n 
+0000665578 00000 n 
 0000014993 00000 n 
 0000015050 00000 n 
-0000364963 00000 n 
-0000665364 00000 n 
+0000365118 00000 n 
+0000665513 00000 n 
 0000015104 00000 n 
 0000015153 00000 n 
-0000365092 00000 n 
-0000665246 00000 n 
+0000365247 00000 n 
+0000665395 00000 n 
 0000015202 00000 n 
 0000015264 00000 n 
-0000365221 00000 n 
-0000665167 00000 n 
+0000365376 00000 n 
+0000665316 00000 n 
 0000015318 00000 n 
 0000015373 00000 n 
-0000389244 00000 n 
-0000665074 00000 n 
+0000389399 00000 n 
+0000665223 00000 n 
 0000015427 00000 n 
 0000015468 00000 n 
-0000389373 00000 n 
-0000664995 00000 n 
+0000389528 00000 n 
+0000665144 00000 n 
 0000015522 00000 n 
 0000015574 00000 n 
-0000392103 00000 n 
-0000664875 00000 n 
+0000392258 00000 n 
+0000665024 00000 n 
 0000015622 00000 n 
 0000015656 00000 n 
-0000392232 00000 n 
-0000664796 00000 n 
+0000392387 00000 n 
+0000664945 00000 n 
 0000015705 00000 n 
 0000015732 00000 n 
-0000410371 00000 n 
-0000664703 00000 n 
+0000410526 00000 n 
+0000664852 00000 n 
 0000015781 00000 n 
 0000015809 00000 n 
-0000417904 00000 n 
-0000664610 00000 n 
+0000418059 00000 n 
+0000664759 00000 n 
 0000015858 00000 n 
 0000015895 00000 n 
-0000424222 00000 n 
-0000664517 00000 n 
+0000424377 00000 n 
+0000664666 00000 n 
 0000015944 00000 n 
 0000015983 00000 n 
-0000433742 00000 n 
-0000664424 00000 n 
+0000433897 00000 n 
+0000664573 00000 n 
 0000016032 00000 n 
 0000016071 00000 n 
-0000436629 00000 n 
-0000664331 00000 n 
+0000436784 00000 n 
+0000664480 00000 n 
 0000016120 00000 n 
 0000016159 00000 n 
-0000443022 00000 n 
-0000664238 00000 n 
+0000443177 00000 n 
+0000664387 00000 n 
 0000016208 00000 n 
 0000016237 00000 n 
-0000452411 00000 n 
-0000664145 00000 n 
+0000452566 00000 n 
+0000664294 00000 n 
 0000016286 00000 n 
 0000016314 00000 n 
-0000456051 00000 n 
-0000664052 00000 n 
+0000456206 00000 n 
+0000664201 00000 n 
 0000016363 00000 n 
 0000016396 00000 n 
-0000465449 00000 n 
-0000663973 00000 n 
+0000465604 00000 n 
+0000664122 00000 n 
 0000016446 00000 n 
 0000016483 00000 n 
 0000016852 00000 n 
@@ -11714,10 +11697,10 @@ xref
 0000016536 00000 n 
 0000024677 00000 n 
 0000024740 00000 n 
-0000659836 00000 n 
-0000633893 00000 n 
-0000659662 00000 n 
-0000660861 00000 n 
+0000659985 00000 n 
+0000634042 00000 n 
+0000659811 00000 n 
+0000661010 00000 n 
 0000019837 00000 n 
 0000020054 00000 n 
 0000020123 00000 n 
@@ -11734,1302 +11717,1302 @@ xref
 0000021460 00000 n 
 0000021769 00000 n 
 0000021929 00000 n 
-0000026167 00000 n 
-0000025982 00000 n 
+0000026169 00000 n 
+0000025984 00000 n 
 0000024903 00000 n 
-0000026104 00000 n 
-0000632681 00000 n 
-0000606202 00000 n 
-0000632507 00000 n 
-0000605517 00000 n 
-0000603371 00000 n 
-0000605353 00000 n 
-0000037873 00000 n 
-0000029223 00000 n 
-0000026252 00000 n 
-0000037747 00000 n 
-0000037810 00000 n 
-0000029757 00000 n 
-0000029911 00000 n 
-0000030068 00000 n 
-0000030225 00000 n 
-0000030381 00000 n 
-0000030538 00000 n 
-0000030700 00000 n 
-0000030861 00000 n 
-0000031022 00000 n 
-0000031184 00000 n 
-0000031351 00000 n 
-0000031518 00000 n 
-0000031683 00000 n 
-0000031845 00000 n 
-0000032011 00000 n 
-0000032172 00000 n 
-0000032327 00000 n 
-0000032484 00000 n 
-0000032640 00000 n 
-0000032797 00000 n 
-0000032954 00000 n 
-0000033111 00000 n 
-0000033265 00000 n 
-0000033421 00000 n 
-0000033583 00000 n 
-0000033745 00000 n 
-0000033901 00000 n 
-0000034058 00000 n 
-0000034220 00000 n 
-0000034387 00000 n 
-0000034553 00000 n 
-0000034714 00000 n 
-0000034869 00000 n 
-0000035026 00000 n 
-0000035183 00000 n 
-0000035345 00000 n 
-0000035502 00000 n 
-0000035659 00000 n 
-0000035821 00000 n 
-0000035978 00000 n 
-0000036140 00000 n 
-0000036307 00000 n 
-0000036473 00000 n 
-0000036635 00000 n 
-0000036797 00000 n 
-0000036959 00000 n 
-0000037120 00000 n 
-0000037282 00000 n 
-0000037437 00000 n 
-0000037592 00000 n 
-0000051262 00000 n 
-0000041209 00000 n 
-0000037958 00000 n 
-0000051199 00000 n 
-0000602820 00000 n 
-0000585739 00000 n 
-0000602636 00000 n 
-0000041799 00000 n 
-0000041962 00000 n 
-0000042124 00000 n 
-0000042287 00000 n 
-0000042445 00000 n 
-0000042608 00000 n 
-0000042771 00000 n 
-0000042926 00000 n 
-0000043084 00000 n 
-0000043242 00000 n 
-0000043398 00000 n 
-0000043556 00000 n 
-0000043719 00000 n 
-0000043887 00000 n 
-0000044055 00000 n 
-0000044218 00000 n 
-0000044386 00000 n 
-0000044554 00000 n 
-0000044712 00000 n 
-0000044875 00000 n 
-0000045038 00000 n 
-0000045200 00000 n 
-0000045362 00000 n 
-0000045525 00000 n 
-0000045687 00000 n 
-0000045849 00000 n 
-0000046012 00000 n 
-0000046175 00000 n 
-0000046338 00000 n 
-0000046507 00000 n 
-0000046676 00000 n 
-0000046845 00000 n 
-0000047008 00000 n 
-0000047172 00000 n 
-0000047336 00000 n 
-0000047499 00000 n 
-0000047663 00000 n 
-0000047827 00000 n 
-0000047995 00000 n 
-0000048164 00000 n 
-0000048333 00000 n 
-0000048502 00000 n 
-0000048671 00000 n 
-0000048840 00000 n 
-0000049009 00000 n 
-0000049178 00000 n 
-0000049347 00000 n 
-0000049517 00000 n 
-0000049687 00000 n 
-0000049856 00000 n 
-0000050026 00000 n 
-0000050196 00000 n 
-0000050364 00000 n 
-0000050533 00000 n 
-0000050703 00000 n 
-0000050870 00000 n 
-0000051037 00000 n 
-0000064310 00000 n 
-0000054845 00000 n 
-0000051360 00000 n 
-0000064247 00000 n 
-0000055419 00000 n 
-0000055582 00000 n 
-0000055745 00000 n 
-0000055908 00000 n 
-0000056071 00000 n 
-0000056233 00000 n 
-0000056396 00000 n 
-0000056559 00000 n 
-0000056727 00000 n 
-0000056893 00000 n 
-0000057061 00000 n 
-0000057229 00000 n 
-0000057386 00000 n 
-0000057548 00000 n 
-0000057715 00000 n 
-0000057882 00000 n 
-0000058044 00000 n 
-0000058206 00000 n 
-0000058368 00000 n 
-0000058530 00000 n 
-0000058697 00000 n 
-0000058864 00000 n 
-0000059031 00000 n 
-0000059193 00000 n 
-0000059355 00000 n 
-0000059510 00000 n 
-0000059667 00000 n 
-0000059824 00000 n 
-0000059986 00000 n 
-0000060148 00000 n 
-0000060305 00000 n 
-0000060460 00000 n 
-0000060617 00000 n 
-0000060778 00000 n 
-0000060935 00000 n 
-0000061092 00000 n 
-0000061247 00000 n 
-0000061404 00000 n 
-0000061566 00000 n 
-0000061723 00000 n 
-0000061885 00000 n 
-0000062041 00000 n 
-0000062203 00000 n 
-0000062365 00000 n 
-0000062527 00000 n 
-0000062683 00000 n 
-0000062840 00000 n 
-0000062997 00000 n 
-0000063154 00000 n 
-0000063310 00000 n 
-0000063467 00000 n 
-0000063624 00000 n 
-0000063781 00000 n 
-0000584773 00000 n 
-0000564806 00000 n 
-0000584600 00000 n 
-0000063937 00000 n 
-0000064092 00000 n 
-0000064755 00000 n 
-0000064570 00000 n 
-0000064421 00000 n 
-0000064692 00000 n 
-0000067860 00000 n 
-0000067050 00000 n 
-0000064796 00000 n 
-0000067172 00000 n 
-0000067296 00000 n 
-0000067421 00000 n 
-0000067546 00000 n 
-0000563917 00000 n 
-0000542586 00000 n 
-0000563743 00000 n 
-0000067671 00000 n 
-0000067734 00000 n 
-0000067797 00000 n 
-0000541812 00000 n 
-0000524265 00000 n 
-0000541639 00000 n 
-0000660979 00000 n 
-0000072371 00000 n 
-0000071189 00000 n 
-0000067984 00000 n 
-0000071683 00000 n 
-0000071746 00000 n 
-0000071809 00000 n 
-0000071934 00000 n 
-0000072059 00000 n 
-0000072184 00000 n 
-0000071339 00000 n 
-0000071532 00000 n 
-0000072309 00000 n 
-0000323763 00000 n 
-0000365285 00000 n 
-0000077025 00000 n 
-0000075989 00000 n 
-0000072495 00000 n 
-0000076462 00000 n 
-0000076587 00000 n 
-0000076139 00000 n 
-0000076301 00000 n 
-0000076712 00000 n 
-0000076837 00000 n 
-0000076962 00000 n 
-0000092900 00000 n 
-0000080247 00000 n 
-0000079687 00000 n 
-0000077149 00000 n 
-0000079809 00000 n 
-0000079934 00000 n 
-0000080059 00000 n 
-0000080184 00000 n 
-0000083674 00000 n 
-0000082533 00000 n 
-0000080358 00000 n 
-0000082987 00000 n 
-0000083112 00000 n 
-0000083237 00000 n 
-0000083362 00000 n 
-0000083487 00000 n 
-0000082683 00000 n 
-0000082835 00000 n 
-0000083611 00000 n 
-0000277767 00000 n 
-0000084757 00000 n 
-0000084447 00000 n 
-0000083759 00000 n 
-0000084569 00000 n 
-0000084694 00000 n 
-0000086835 00000 n 
-0000086150 00000 n 
-0000084855 00000 n 
-0000086272 00000 n 
-0000086397 00000 n 
-0000086521 00000 n 
-0000086646 00000 n 
-0000086772 00000 n 
-0000661097 00000 n 
-0000089740 00000 n 
-0000088872 00000 n 
-0000086933 00000 n 
-0000089174 00000 n 
-0000089300 00000 n 
-0000089363 00000 n 
-0000089426 00000 n 
-0000089014 00000 n 
-0000089552 00000 n 
-0000089678 00000 n 
-0000262009 00000 n 
-0000093089 00000 n 
-0000092652 00000 n 
-0000089851 00000 n 
-0000092774 00000 n 
-0000523609 00000 n 
-0000512024 00000 n 
-0000523432 00000 n 
-0000093026 00000 n 
-0000096906 00000 n 
-0000096721 00000 n 
-0000093213 00000 n 
-0000096843 00000 n 
-0000511485 00000 n 
-0000501742 00000 n 
-0000511308 00000 n 
-0000101367 00000 n 
-0000100976 00000 n 
-0000097069 00000 n 
-0000101304 00000 n 
-0000101118 00000 n 
-0000162391 00000 n 
-0000103653 00000 n 
-0000103216 00000 n 
-0000101504 00000 n 
-0000103338 00000 n 
-0000103464 00000 n 
-0000103527 00000 n 
-0000103590 00000 n 
-0000106344 00000 n 
-0000108877 00000 n 
-0000106193 00000 n 
-0000103777 00000 n 
-0000108308 00000 n 
-0000108434 00000 n 
-0000108560 00000 n 
-0000107986 00000 n 
-0000108147 00000 n 
-0000500883 00000 n 
-0000491510 00000 n 
-0000500710 00000 n 
-0000490946 00000 n 
-0000481859 00000 n 
-0000490771 00000 n 
-0000108686 00000 n 
-0000108813 00000 n 
-0000661215 00000 n 
-0000107815 00000 n 
-0000107873 00000 n 
-0000107963 00000 n 
-0000206952 00000 n 
-0000239684 00000 n 
-0000113428 00000 n 
-0000112494 00000 n 
-0000109031 00000 n 
-0000112978 00000 n 
-0000113106 00000 n 
-0000112650 00000 n 
-0000112816 00000 n 
-0000113234 00000 n 
-0000113363 00000 n 
-0000369310 00000 n 
-0000116920 00000 n 
-0000116540 00000 n 
-0000113579 00000 n 
-0000116855 00000 n 
-0000116687 00000 n 
-0000118154 00000 n 
-0000117963 00000 n 
-0000117045 00000 n 
-0000118089 00000 n 
-0000121056 00000 n 
-0000120480 00000 n 
-0000118253 00000 n 
-0000120606 00000 n 
-0000120733 00000 n 
-0000120862 00000 n 
-0000120991 00000 n 
-0000124467 00000 n 
-0000123632 00000 n 
-0000121194 00000 n 
-0000123758 00000 n 
-0000123887 00000 n 
-0000124016 00000 n 
-0000124145 00000 n 
-0000124273 00000 n 
-0000124402 00000 n 
-0000128391 00000 n 
-0000127623 00000 n 
-0000124605 00000 n 
-0000127940 00000 n 
-0000127770 00000 n 
-0000128069 00000 n 
-0000128198 00000 n 
-0000128327 00000 n 
-0000661339 00000 n 
-0000319731 00000 n 
-0000132255 00000 n 
-0000131678 00000 n 
-0000128503 00000 n 
-0000131804 00000 n 
-0000131933 00000 n 
-0000132061 00000 n 
-0000132190 00000 n 
-0000135717 00000 n 
-0000135397 00000 n 
-0000132393 00000 n 
-0000135523 00000 n 
-0000135652 00000 n 
-0000139048 00000 n 
-0000138289 00000 n 
-0000135829 00000 n 
-0000138597 00000 n 
-0000138726 00000 n 
-0000138436 00000 n 
-0000138855 00000 n 
-0000138983 00000 n 
-0000365027 00000 n 
-0000141787 00000 n 
-0000141209 00000 n 
-0000139215 00000 n 
-0000141335 00000 n 
-0000141464 00000 n 
-0000141593 00000 n 
-0000141722 00000 n 
-0000142227 00000 n 
-0000142036 00000 n 
-0000141886 00000 n 
-0000142162 00000 n 
-0000146229 00000 n 
-0000145463 00000 n 
-0000142269 00000 n 
-0000145777 00000 n 
-0000145906 00000 n 
-0000146034 00000 n 
-0000146099 00000 n 
-0000146164 00000 n 
-0000145610 00000 n 
-0000661464 00000 n 
-0000150641 00000 n 
-0000150833 00000 n 
-0000150387 00000 n 
-0000146328 00000 n 
-0000150513 00000 n 
-0000150768 00000 n 
-0000154679 00000 n 
-0000153972 00000 n 
-0000150958 00000 n 
-0000154098 00000 n 
-0000154227 00000 n 
-0000154356 00000 n 
-0000154485 00000 n 
-0000154614 00000 n 
-0000157550 00000 n 
-0000158800 00000 n 
-0000157424 00000 n 
-0000154804 00000 n 
-0000158476 00000 n 
-0000158605 00000 n 
-0000158670 00000 n 
-0000158735 00000 n 
-0000162455 00000 n 
-0000161620 00000 n 
-0000158955 00000 n 
-0000161746 00000 n 
-0000161875 00000 n 
-0000162003 00000 n 
-0000162068 00000 n 
-0000162133 00000 n 
-0000162262 00000 n 
-0000167312 00000 n 
-0000166397 00000 n 
-0000162567 00000 n 
-0000166863 00000 n 
-0000166553 00000 n 
-0000166704 00000 n 
-0000166991 00000 n 
-0000167118 00000 n 
-0000167247 00000 n 
-0000468049 00000 n 
-0000171332 00000 n 
-0000170190 00000 n 
-0000167450 00000 n 
-0000170880 00000 n 
-0000171009 00000 n 
-0000170355 00000 n 
-0000170507 00000 n 
-0000170694 00000 n 
-0000171138 00000 n 
-0000171267 00000 n 
-0000661589 00000 n 
-0000175864 00000 n 
-0000175544 00000 n 
-0000171457 00000 n 
-0000175670 00000 n 
-0000175799 00000 n 
-0000179053 00000 n 
-0000178674 00000 n 
-0000175989 00000 n 
-0000178988 00000 n 
-0000178821 00000 n 
-0000182238 00000 n 
-0000182433 00000 n 
-0000181983 00000 n 
-0000179165 00000 n 
-0000182109 00000 n 
-0000182303 00000 n 
-0000182368 00000 n 
-0000185782 00000 n 
-0000185462 00000 n 
-0000182545 00000 n 
-0000185588 00000 n 
-0000185717 00000 n 
-0000189243 00000 n 
-0000188793 00000 n 
-0000185894 00000 n 
-0000188919 00000 n 
-0000188984 00000 n 
-0000189049 00000 n 
-0000189178 00000 n 
-0000192455 00000 n 
-0000191412 00000 n 
-0000189355 00000 n 
-0000191874 00000 n 
-0000192003 00000 n 
-0000191568 00000 n 
-0000191721 00000 n 
-0000192132 00000 n 
-0000192261 00000 n 
-0000192390 00000 n 
-0000661714 00000 n 
-0000194043 00000 n 
-0000193852 00000 n 
-0000192567 00000 n 
-0000193978 00000 n 
-0000195559 00000 n 
-0000195368 00000 n 
-0000194142 00000 n 
-0000195494 00000 n 
-0000198922 00000 n 
-0000198602 00000 n 
-0000195658 00000 n 
-0000198728 00000 n 
-0000198857 00000 n 
-0000203016 00000 n 
-0000202648 00000 n 
-0000199047 00000 n 
-0000202951 00000 n 
-0000202795 00000 n 
-0000277509 00000 n 
-0000207147 00000 n 
-0000206697 00000 n 
-0000203128 00000 n 
-0000206823 00000 n 
-0000207017 00000 n 
-0000207082 00000 n 
-0000211325 00000 n 
-0000210959 00000 n 
-0000207259 00000 n 
-0000211260 00000 n 
-0000211106 00000 n 
-0000661839 00000 n 
-0000216411 00000 n 
-0000215278 00000 n 
-0000211450 00000 n 
-0000216346 00000 n 
-0000215461 00000 n 
-0000215617 00000 n 
-0000215802 00000 n 
-0000215976 00000 n 
-0000216161 00000 n 
-0000281362 00000 n 
-0000220635 00000 n 
-0000220444 00000 n 
-0000216604 00000 n 
-0000220570 00000 n 
-0000224755 00000 n 
-0000224116 00000 n 
-0000220747 00000 n 
-0000224433 00000 n 
-0000224562 00000 n 
-0000224263 00000 n 
-0000224691 00000 n 
-0000292604 00000 n 
-0000229269 00000 n 
-0000228403 00000 n 
-0000224867 00000 n 
-0000229075 00000 n 
-0000229204 00000 n 
-0000228568 00000 n 
-0000228734 00000 n 
-0000228904 00000 n 
-0000352739 00000 n 
-0000232499 00000 n 
-0000232051 00000 n 
-0000229437 00000 n 
-0000232177 00000 n 
-0000232306 00000 n 
-0000232435 00000 n 
-0000235872 00000 n 
-0000235681 00000 n 
-0000232624 00000 n 
-0000235807 00000 n 
-0000661964 00000 n 
-0000239749 00000 n 
-0000239429 00000 n 
-0000236040 00000 n 
-0000239555 00000 n 
-0000243306 00000 n 
-0000243115 00000 n 
-0000239904 00000 n 
-0000243241 00000 n 
-0000247646 00000 n 
-0000246832 00000 n 
-0000243474 00000 n 
-0000247323 00000 n 
-0000247452 00000 n 
-0000246988 00000 n 
-0000247581 00000 n 
-0000247149 00000 n 
-0000251703 00000 n 
-0000251079 00000 n 
-0000247800 00000 n 
-0000251381 00000 n 
-0000251510 00000 n 
-0000251226 00000 n 
-0000251639 00000 n 
-0000254771 00000 n 
-0000254451 00000 n 
-0000251828 00000 n 
-0000254577 00000 n 
-0000254706 00000 n 
-0000258842 00000 n 
-0000258175 00000 n 
-0000254925 00000 n 
-0000258648 00000 n 
-0000258777 00000 n 
-0000258331 00000 n 
-0000258493 00000 n 
-0000662089 00000 n 
-0000262331 00000 n 
-0000261563 00000 n 
-0000259010 00000 n 
-0000261880 00000 n 
+0000026106 00000 n 
+0000632830 00000 n 
+0000606351 00000 n 
+0000632656 00000 n 
+0000605666 00000 n 
+0000603521 00000 n 
+0000605502 00000 n 
+0000037875 00000 n 
+0000029225 00000 n 
+0000026254 00000 n 
+0000037749 00000 n 
+0000037812 00000 n 
+0000029759 00000 n 
+0000029913 00000 n 
+0000030070 00000 n 
+0000030227 00000 n 
+0000030383 00000 n 
+0000030540 00000 n 
+0000030702 00000 n 
+0000030863 00000 n 
+0000031024 00000 n 
+0000031186 00000 n 
+0000031353 00000 n 
+0000031520 00000 n 
+0000031685 00000 n 
+0000031847 00000 n 
+0000032013 00000 n 
+0000032174 00000 n 
+0000032329 00000 n 
+0000032486 00000 n 
+0000032642 00000 n 
+0000032799 00000 n 
+0000032956 00000 n 
+0000033113 00000 n 
+0000033267 00000 n 
+0000033423 00000 n 
+0000033585 00000 n 
+0000033747 00000 n 
+0000033903 00000 n 
+0000034060 00000 n 
+0000034222 00000 n 
+0000034389 00000 n 
+0000034555 00000 n 
+0000034716 00000 n 
+0000034871 00000 n 
+0000035028 00000 n 
+0000035185 00000 n 
+0000035347 00000 n 
+0000035504 00000 n 
+0000035661 00000 n 
+0000035823 00000 n 
+0000035980 00000 n 
+0000036142 00000 n 
+0000036309 00000 n 
+0000036475 00000 n 
+0000036637 00000 n 
+0000036799 00000 n 
+0000036961 00000 n 
+0000037122 00000 n 
+0000037284 00000 n 
+0000037439 00000 n 
+0000037594 00000 n 
+0000051264 00000 n 
+0000041211 00000 n 
+0000037960 00000 n 
+0000051201 00000 n 
+0000602970 00000 n 
+0000585889 00000 n 
+0000602786 00000 n 
+0000041801 00000 n 
+0000041964 00000 n 
+0000042126 00000 n 
+0000042289 00000 n 
+0000042447 00000 n 
+0000042610 00000 n 
+0000042773 00000 n 
+0000042928 00000 n 
+0000043086 00000 n 
+0000043244 00000 n 
+0000043400 00000 n 
+0000043558 00000 n 
+0000043721 00000 n 
+0000043889 00000 n 
+0000044057 00000 n 
+0000044220 00000 n 
+0000044388 00000 n 
+0000044556 00000 n 
+0000044714 00000 n 
+0000044877 00000 n 
+0000045040 00000 n 
+0000045202 00000 n 
+0000045364 00000 n 
+0000045527 00000 n 
+0000045689 00000 n 
+0000045851 00000 n 
+0000046014 00000 n 
+0000046177 00000 n 
+0000046340 00000 n 
+0000046509 00000 n 
+0000046678 00000 n 
+0000046847 00000 n 
+0000047010 00000 n 
+0000047174 00000 n 
+0000047338 00000 n 
+0000047501 00000 n 
+0000047665 00000 n 
+0000047829 00000 n 
+0000047997 00000 n 
+0000048166 00000 n 
+0000048335 00000 n 
+0000048504 00000 n 
+0000048673 00000 n 
+0000048842 00000 n 
+0000049011 00000 n 
+0000049180 00000 n 
+0000049349 00000 n 
+0000049519 00000 n 
+0000049689 00000 n 
+0000049858 00000 n 
+0000050028 00000 n 
+0000050198 00000 n 
+0000050366 00000 n 
+0000050535 00000 n 
+0000050705 00000 n 
+0000050872 00000 n 
+0000051039 00000 n 
+0000064312 00000 n 
+0000054847 00000 n 
+0000051362 00000 n 
+0000064249 00000 n 
+0000055421 00000 n 
+0000055584 00000 n 
+0000055747 00000 n 
+0000055910 00000 n 
+0000056073 00000 n 
+0000056235 00000 n 
+0000056398 00000 n 
+0000056561 00000 n 
+0000056729 00000 n 
+0000056895 00000 n 
+0000057063 00000 n 
+0000057231 00000 n 
+0000057388 00000 n 
+0000057550 00000 n 
+0000057717 00000 n 
+0000057884 00000 n 
+0000058046 00000 n 
+0000058208 00000 n 
+0000058370 00000 n 
+0000058532 00000 n 
+0000058699 00000 n 
+0000058866 00000 n 
+0000059033 00000 n 
+0000059195 00000 n 
+0000059357 00000 n 
+0000059512 00000 n 
+0000059669 00000 n 
+0000059826 00000 n 
+0000059988 00000 n 
+0000060150 00000 n 
+0000060307 00000 n 
+0000060462 00000 n 
+0000060619 00000 n 
+0000060780 00000 n 
+0000060937 00000 n 
+0000061094 00000 n 
+0000061249 00000 n 
+0000061406 00000 n 
+0000061568 00000 n 
+0000061725 00000 n 
+0000061887 00000 n 
+0000062043 00000 n 
+0000062205 00000 n 
+0000062367 00000 n 
+0000062529 00000 n 
+0000062685 00000 n 
+0000062842 00000 n 
+0000062999 00000 n 
+0000063156 00000 n 
+0000063312 00000 n 
+0000063469 00000 n 
+0000063626 00000 n 
+0000063783 00000 n 
+0000584923 00000 n 
+0000564956 00000 n 
+0000584750 00000 n 
+0000063939 00000 n 
+0000064094 00000 n 
+0000064757 00000 n 
+0000064572 00000 n 
+0000064423 00000 n 
+0000064694 00000 n 
+0000067862 00000 n 
+0000067052 00000 n 
+0000064798 00000 n 
+0000067174 00000 n 
+0000067298 00000 n 
+0000067423 00000 n 
+0000067548 00000 n 
+0000564067 00000 n 
+0000542735 00000 n 
+0000563893 00000 n 
+0000067673 00000 n 
+0000067736 00000 n 
+0000067799 00000 n 
+0000541961 00000 n 
+0000524414 00000 n 
+0000541788 00000 n 
+0000661128 00000 n 
+0000072373 00000 n 
+0000071191 00000 n 
+0000067986 00000 n 
+0000071685 00000 n 
+0000071748 00000 n 
+0000071811 00000 n 
+0000071936 00000 n 
+0000072061 00000 n 
+0000072186 00000 n 
+0000071341 00000 n 
+0000071534 00000 n 
+0000072311 00000 n 
+0000323918 00000 n 
+0000365440 00000 n 
+0000077027 00000 n 
+0000075991 00000 n 
+0000072497 00000 n 
+0000076464 00000 n 
+0000076589 00000 n 
+0000076141 00000 n 
+0000076303 00000 n 
+0000076714 00000 n 
+0000076839 00000 n 
+0000076964 00000 n 
+0000092902 00000 n 
+0000080249 00000 n 
+0000079689 00000 n 
+0000077151 00000 n 
+0000079811 00000 n 
+0000079936 00000 n 
+0000080061 00000 n 
+0000080186 00000 n 
+0000083676 00000 n 
+0000082535 00000 n 
+0000080360 00000 n 
+0000082989 00000 n 
+0000083114 00000 n 
+0000083239 00000 n 
+0000083364 00000 n 
+0000083489 00000 n 
+0000082685 00000 n 
+0000082837 00000 n 
+0000083613 00000 n 
+0000277922 00000 n 
+0000084759 00000 n 
+0000084449 00000 n 
+0000083761 00000 n 
+0000084571 00000 n 
+0000084696 00000 n 
+0000086837 00000 n 
+0000086152 00000 n 
+0000084857 00000 n 
+0000086274 00000 n 
+0000086399 00000 n 
+0000086523 00000 n 
+0000086648 00000 n 
+0000086774 00000 n 
+0000661246 00000 n 
+0000089742 00000 n 
+0000088874 00000 n 
+0000086935 00000 n 
+0000089176 00000 n 
+0000089302 00000 n 
+0000089365 00000 n 
+0000089428 00000 n 
+0000089016 00000 n 
+0000089554 00000 n 
+0000089680 00000 n 
+0000262156 00000 n 
+0000093091 00000 n 
+0000092654 00000 n 
+0000089853 00000 n 
+0000092776 00000 n 
+0000523758 00000 n 
+0000512176 00000 n 
+0000523581 00000 n 
+0000093028 00000 n 
+0000096908 00000 n 
+0000096723 00000 n 
+0000093215 00000 n 
+0000096845 00000 n 
+0000511637 00000 n 
+0000501895 00000 n 
+0000511460 00000 n 
+0000101369 00000 n 
+0000100978 00000 n 
+0000097071 00000 n 
+0000101306 00000 n 
+0000101120 00000 n 
+0000162393 00000 n 
+0000103655 00000 n 
+0000103218 00000 n 
+0000101506 00000 n 
+0000103340 00000 n 
+0000103466 00000 n 
+0000103529 00000 n 
+0000103592 00000 n 
+0000106346 00000 n 
+0000108879 00000 n 
+0000106195 00000 n 
+0000103779 00000 n 
+0000108310 00000 n 
+0000108436 00000 n 
+0000108562 00000 n 
+0000107988 00000 n 
+0000108149 00000 n 
+0000501036 00000 n 
+0000491663 00000 n 
+0000500863 00000 n 
+0000491099 00000 n 
+0000482013 00000 n 
+0000490924 00000 n 
+0000108688 00000 n 
+0000108815 00000 n 
+0000661364 00000 n 
+0000107817 00000 n 
+0000107875 00000 n 
+0000107965 00000 n 
+0000206954 00000 n 
+0000239686 00000 n 
+0000113430 00000 n 
+0000112496 00000 n 
+0000109033 00000 n 
+0000112980 00000 n 
+0000113108 00000 n 
+0000112652 00000 n 
+0000112818 00000 n 
+0000113236 00000 n 
+0000113365 00000 n 
+0000369465 00000 n 
+0000116922 00000 n 
+0000116542 00000 n 
+0000113581 00000 n 
+0000116857 00000 n 
+0000116689 00000 n 
+0000118156 00000 n 
+0000117965 00000 n 
+0000117047 00000 n 
+0000118091 00000 n 
+0000121058 00000 n 
+0000120482 00000 n 
+0000118255 00000 n 
+0000120608 00000 n 
+0000120735 00000 n 
+0000120864 00000 n 
+0000120993 00000 n 
+0000124469 00000 n 
+0000123634 00000 n 
+0000121196 00000 n 
+0000123760 00000 n 
+0000123889 00000 n 
+0000124018 00000 n 
+0000124147 00000 n 
+0000124275 00000 n 
+0000124404 00000 n 
+0000128393 00000 n 
+0000127625 00000 n 
+0000124607 00000 n 
+0000127942 00000 n 
+0000127772 00000 n 
+0000128071 00000 n 
+0000128200 00000 n 
+0000128329 00000 n 
+0000661488 00000 n 
+0000319886 00000 n 
+0000132257 00000 n 
+0000131680 00000 n 
+0000128505 00000 n 
+0000131806 00000 n 
+0000131935 00000 n 
+0000132063 00000 n 
+0000132192 00000 n 
+0000135719 00000 n 
+0000135399 00000 n 
+0000132395 00000 n 
+0000135525 00000 n 
+0000135654 00000 n 
+0000139050 00000 n 
+0000138291 00000 n 
+0000135831 00000 n 
+0000138599 00000 n 
+0000138728 00000 n 
+0000138438 00000 n 
+0000138857 00000 n 
+0000138985 00000 n 
+0000365182 00000 n 
+0000141789 00000 n 
+0000141211 00000 n 
+0000139217 00000 n 
+0000141337 00000 n 
+0000141466 00000 n 
+0000141595 00000 n 
+0000141724 00000 n 
+0000142229 00000 n 
+0000142038 00000 n 
+0000141888 00000 n 
+0000142164 00000 n 
+0000146231 00000 n 
+0000145465 00000 n 
+0000142271 00000 n 
+0000145779 00000 n 
+0000145908 00000 n 
+0000146036 00000 n 
+0000146101 00000 n 
+0000146166 00000 n 
+0000145612 00000 n 
+0000661613 00000 n 
+0000150643 00000 n 
+0000150835 00000 n 
+0000150389 00000 n 
+0000146330 00000 n 
+0000150515 00000 n 
+0000150770 00000 n 
+0000154681 00000 n 
+0000153974 00000 n 
+0000150960 00000 n 
+0000154100 00000 n 
+0000154229 00000 n 
+0000154358 00000 n 
+0000154487 00000 n 
+0000154616 00000 n 
+0000157552 00000 n 
+0000158802 00000 n 
+0000157426 00000 n 
+0000154806 00000 n 
+0000158478 00000 n 
+0000158607 00000 n 
+0000158672 00000 n 
+0000158737 00000 n 
+0000162457 00000 n 
+0000161622 00000 n 
+0000158957 00000 n 
+0000161748 00000 n 
+0000161877 00000 n 
+0000162005 00000 n 
+0000162070 00000 n 
+0000162135 00000 n 
+0000162264 00000 n 
+0000167314 00000 n 
+0000166399 00000 n 
+0000162569 00000 n 
+0000166865 00000 n 
+0000166555 00000 n 
+0000166706 00000 n 
+0000166993 00000 n 
+0000167120 00000 n 
+0000167249 00000 n 
+0000468204 00000 n 
+0000171334 00000 n 
+0000170192 00000 n 
+0000167452 00000 n 
+0000170882 00000 n 
+0000171011 00000 n 
+0000170357 00000 n 
+0000170509 00000 n 
+0000170696 00000 n 
+0000171140 00000 n 
+0000171269 00000 n 
+0000661738 00000 n 
+0000175866 00000 n 
+0000175546 00000 n 
+0000171459 00000 n 
+0000175672 00000 n 
+0000175801 00000 n 
+0000179055 00000 n 
+0000178676 00000 n 
+0000175991 00000 n 
+0000178990 00000 n 
+0000178823 00000 n 
+0000182240 00000 n 
+0000182435 00000 n 
+0000181985 00000 n 
+0000179167 00000 n 
+0000182111 00000 n 
+0000182305 00000 n 
+0000182370 00000 n 
+0000185784 00000 n 
+0000185464 00000 n 
+0000182547 00000 n 
+0000185590 00000 n 
+0000185719 00000 n 
+0000189245 00000 n 
+0000188795 00000 n 
+0000185896 00000 n 
+0000188921 00000 n 
+0000188986 00000 n 
+0000189051 00000 n 
+0000189180 00000 n 
+0000192457 00000 n 
+0000191414 00000 n 
+0000189357 00000 n 
+0000191876 00000 n 
+0000192005 00000 n 
+0000191570 00000 n 
+0000191723 00000 n 
+0000192134 00000 n 
+0000192263 00000 n 
+0000192392 00000 n 
+0000661863 00000 n 
+0000194045 00000 n 
+0000193854 00000 n 
+0000192569 00000 n 
+0000193980 00000 n 
+0000195561 00000 n 
+0000195370 00000 n 
+0000194144 00000 n 
+0000195496 00000 n 
+0000198924 00000 n 
+0000198604 00000 n 
+0000195660 00000 n 
+0000198730 00000 n 
+0000198859 00000 n 
+0000203018 00000 n 
+0000202650 00000 n 
+0000199049 00000 n 
+0000202953 00000 n 
+0000202797 00000 n 
+0000277664 00000 n 
+0000207149 00000 n 
+0000206699 00000 n 
+0000203130 00000 n 
+0000206825 00000 n 
+0000207019 00000 n 
+0000207084 00000 n 
+0000211327 00000 n 
+0000210961 00000 n 
+0000207261 00000 n 
+0000211262 00000 n 
+0000211108 00000 n 
+0000661988 00000 n 
+0000216413 00000 n 
+0000215280 00000 n 
+0000211452 00000 n 
+0000216348 00000 n 
+0000215463 00000 n 
+0000215619 00000 n 
+0000215804 00000 n 
+0000215978 00000 n 
+0000216163 00000 n 
+0000281517 00000 n 
+0000220637 00000 n 
+0000220446 00000 n 
+0000216606 00000 n 
+0000220572 00000 n 
+0000224757 00000 n 
+0000224118 00000 n 
+0000220749 00000 n 
+0000224435 00000 n 
+0000224564 00000 n 
+0000224265 00000 n 
+0000224693 00000 n 
+0000292759 00000 n 
+0000229271 00000 n 
+0000228405 00000 n 
+0000224869 00000 n 
+0000229077 00000 n 
+0000229206 00000 n 
+0000228570 00000 n 
+0000228736 00000 n 
+0000228906 00000 n 
+0000352894 00000 n 
+0000232501 00000 n 
+0000232053 00000 n 
+0000229439 00000 n 
+0000232179 00000 n 
+0000232308 00000 n 
+0000232437 00000 n 
+0000235874 00000 n 
+0000235683 00000 n 
+0000232626 00000 n 
+0000235809 00000 n 
+0000662113 00000 n 
+0000239751 00000 n 
+0000239431 00000 n 
+0000236042 00000 n 
+0000239557 00000 n 
+0000243308 00000 n 
+0000243117 00000 n 
+0000239906 00000 n 
+0000243243 00000 n 
+0000247648 00000 n 
+0000246834 00000 n 
+0000243476 00000 n 
+0000247325 00000 n 
+0000247454 00000 n 
+0000246990 00000 n 
+0000247583 00000 n 
+0000247151 00000 n 
+0000251705 00000 n 
+0000251081 00000 n 
+0000247802 00000 n 
+0000251383 00000 n 
+0000251512 00000 n 
+0000251228 00000 n 
+0000251641 00000 n 
+0000254773 00000 n 
+0000254453 00000 n 
+0000251830 00000 n 
+0000254579 00000 n 
+0000254708 00000 n 
+0000258844 00000 n 
+0000258177 00000 n 
+0000254927 00000 n 
+0000258650 00000 n 
+0000258779 00000 n 
+0000258333 00000 n 
+0000258495 00000 n 
+0000662238 00000 n 
+0000262477 00000 n 
 0000261710 00000 n 
-0000262072 00000 n 
-0000262137 00000 n 
-0000262266 00000 n 
-0000267036 00000 n 
-0000266492 00000 n 
-0000262512 00000 n 
-0000266971 00000 n 
-0000266648 00000 n 
-0000266809 00000 n 
-0000346220 00000 n 
-0000271424 00000 n 
-0000270788 00000 n 
-0000267203 00000 n 
-0000271102 00000 n 
-0000481504 00000 n 
-0000479505 00000 n 
-0000481339 00000 n 
-0000271231 00000 n 
-0000270935 00000 n 
-0000271359 00000 n 
-0000290229 00000 n 
-0000274182 00000 n 
-0000273991 00000 n 
-0000271550 00000 n 
-0000274117 00000 n 
-0000277831 00000 n 
-0000277254 00000 n 
-0000274349 00000 n 
-0000277380 00000 n 
-0000277574 00000 n 
-0000277639 00000 n 
-0000281427 00000 n 
-0000280978 00000 n 
-0000277930 00000 n 
-0000281104 00000 n 
-0000281233 00000 n 
-0000662214 00000 n 
-0000286436 00000 n 
-0000285904 00000 n 
-0000281539 00000 n 
-0000286371 00000 n 
-0000286060 00000 n 
-0000286211 00000 n 
-0000290423 00000 n 
-0000289542 00000 n 
-0000286535 00000 n 
-0000289843 00000 n 
-0000289972 00000 n 
-0000290100 00000 n 
-0000289689 00000 n 
-0000290358 00000 n 
-0000292669 00000 n 
-0000292349 00000 n 
-0000290535 00000 n 
-0000292475 00000 n 
-0000294153 00000 n 
-0000293962 00000 n 
-0000292781 00000 n 
-0000294088 00000 n 
-0000295518 00000 n 
-0000295327 00000 n 
-0000294252 00000 n 
-0000295453 00000 n 
-0000299111 00000 n 
-0000298534 00000 n 
-0000295617 00000 n 
-0000298660 00000 n 
-0000298789 00000 n 
-0000298916 00000 n 
-0000298981 00000 n 
-0000299046 00000 n 
-0000662339 00000 n 
-0000304138 00000 n 
-0000302469 00000 n 
-0000299223 00000 n 
-0000303815 00000 n 
-0000302670 00000 n 
-0000303944 00000 n 
-0000304073 00000 n 
-0000302837 00000 n 
-0000302999 00000 n 
-0000303161 00000 n 
-0000303323 00000 n 
-0000303485 00000 n 
-0000303655 00000 n 
-0000468016 00000 n 
-0000309282 00000 n 
-0000307704 00000 n 
-0000304250 00000 n 
-0000309217 00000 n 
-0000307914 00000 n 
-0000308077 00000 n 
-0000308238 00000 n 
-0000308399 00000 n 
-0000308561 00000 n 
-0000308724 00000 n 
-0000308887 00000 n 
-0000309050 00000 n 
-0000315518 00000 n 
-0000312264 00000 n 
-0000309407 00000 n 
-0000315453 00000 n 
-0000312564 00000 n 
-0000312734 00000 n 
-0000312896 00000 n 
-0000313058 00000 n 
-0000313220 00000 n 
-0000313381 00000 n 
-0000313544 00000 n 
-0000313698 00000 n 
-0000313851 00000 n 
-0000314013 00000 n 
-0000314175 00000 n 
-0000314336 00000 n 
-0000314498 00000 n 
-0000314660 00000 n 
-0000314822 00000 n 
-0000314984 00000 n 
-0000315137 00000 n 
-0000315300 00000 n 
-0000319925 00000 n 
-0000319129 00000 n 
-0000315643 00000 n 
-0000319602 00000 n 
-0000319285 00000 n 
-0000319448 00000 n 
-0000319796 00000 n 
-0000319860 00000 n 
-0000324215 00000 n 
-0000323018 00000 n 
-0000320050 00000 n 
-0000323505 00000 n 
-0000323634 00000 n 
-0000323890 00000 n 
-0000323174 00000 n 
-0000323344 00000 n 
-0000323955 00000 n 
-0000324020 00000 n 
-0000324085 00000 n 
-0000324150 00000 n 
-0000327541 00000 n 
-0000327350 00000 n 
-0000324340 00000 n 
-0000327476 00000 n 
-0000662464 00000 n 
-0000331627 00000 n 
-0000331048 00000 n 
-0000327627 00000 n 
-0000331174 00000 n 
-0000331239 00000 n 
-0000331304 00000 n 
-0000331433 00000 n 
-0000331497 00000 n 
-0000331562 00000 n 
-0000335658 00000 n 
-0000334820 00000 n 
-0000331752 00000 n 
-0000334946 00000 n 
-0000335011 00000 n 
-0000335076 00000 n 
-0000335205 00000 n 
-0000335270 00000 n 
-0000335335 00000 n 
-0000335463 00000 n 
-0000335528 00000 n 
-0000335593 00000 n 
-0000339159 00000 n 
-0000338454 00000 n 
-0000335783 00000 n 
-0000338580 00000 n 
-0000338709 00000 n 
-0000338773 00000 n 
-0000338838 00000 n 
-0000338967 00000 n 
-0000339094 00000 n 
-0000342376 00000 n 
-0000341669 00000 n 
-0000339367 00000 n 
-0000341795 00000 n 
-0000341924 00000 n 
-0000342053 00000 n 
-0000342182 00000 n 
-0000342247 00000 n 
-0000342312 00000 n 
-0000346285 00000 n 
-0000345965 00000 n 
-0000342557 00000 n 
-0000346091 00000 n 
-0000348311 00000 n 
-0000347862 00000 n 
-0000346410 00000 n 
-0000347988 00000 n 
-0000348117 00000 n 
-0000348246 00000 n 
-0000662589 00000 n 
-0000352804 00000 n 
-0000351860 00000 n 
-0000348423 00000 n 
-0000352223 00000 n 
-0000479184 00000 n 
-0000469971 00000 n 
-0000478998 00000 n 
-0000352007 00000 n 
-0000352352 00000 n 
-0000352481 00000 n 
-0000352610 00000 n 
-0000353844 00000 n 
-0000353653 00000 n 
-0000353039 00000 n 
-0000353779 00000 n 
-0000354271 00000 n 
-0000354080 00000 n 
-0000353930 00000 n 
-0000354206 00000 n 
-0000357584 00000 n 
-0000356358 00000 n 
-0000354313 00000 n 
-0000356875 00000 n 
-0000357004 00000 n 
-0000357133 00000 n 
-0000357262 00000 n 
-0000357391 00000 n 
-0000357520 00000 n 
-0000356514 00000 n 
-0000356686 00000 n 
-0000358038 00000 n 
-0000357847 00000 n 
-0000357697 00000 n 
-0000357973 00000 n 
-0000361282 00000 n 
-0000360704 00000 n 
-0000358080 00000 n 
-0000360830 00000 n 
-0000360959 00000 n 
-0000361088 00000 n 
-0000361217 00000 n 
-0000662714 00000 n 
-0000365477 00000 n 
-0000364259 00000 n 
-0000361368 00000 n 
-0000364769 00000 n 
-0000364898 00000 n 
-0000365156 00000 n 
-0000364415 00000 n 
-0000364594 00000 n 
-0000365349 00000 n 
-0000365413 00000 n 
-0000372362 00000 n 
-0000368534 00000 n 
-0000365629 00000 n 
-0000368660 00000 n 
-0000368725 00000 n 
-0000368790 00000 n 
-0000368855 00000 n 
-0000368920 00000 n 
-0000368985 00000 n 
-0000369050 00000 n 
-0000369115 00000 n 
-0000369180 00000 n 
-0000369245 00000 n 
-0000369375 00000 n 
-0000369440 00000 n 
-0000369505 00000 n 
-0000369570 00000 n 
-0000369635 00000 n 
-0000369700 00000 n 
-0000369765 00000 n 
-0000369830 00000 n 
-0000369895 00000 n 
-0000369960 00000 n 
-0000370025 00000 n 
-0000370090 00000 n 
-0000370155 00000 n 
-0000370220 00000 n 
-0000370285 00000 n 
-0000370350 00000 n 
-0000370415 00000 n 
-0000370480 00000 n 
-0000370545 00000 n 
-0000370610 00000 n 
-0000370675 00000 n 
-0000370740 00000 n 
-0000370805 00000 n 
-0000370870 00000 n 
-0000370934 00000 n 
-0000370999 00000 n 
-0000371064 00000 n 
-0000371129 00000 n 
-0000371194 00000 n 
-0000371259 00000 n 
-0000371324 00000 n 
-0000371389 00000 n 
-0000371454 00000 n 
-0000371519 00000 n 
-0000371584 00000 n 
-0000371649 00000 n 
-0000371714 00000 n 
-0000371779 00000 n 
-0000371844 00000 n 
-0000371909 00000 n 
-0000371974 00000 n 
-0000372039 00000 n 
-0000372104 00000 n 
-0000372169 00000 n 
-0000372234 00000 n 
-0000372298 00000 n 
-0000379008 00000 n 
-0000375444 00000 n 
-0000372474 00000 n 
-0000375570 00000 n 
-0000375635 00000 n 
-0000375700 00000 n 
-0000375765 00000 n 
-0000375830 00000 n 
-0000375895 00000 n 
-0000375960 00000 n 
-0000376025 00000 n 
-0000376090 00000 n 
-0000376155 00000 n 
-0000376220 00000 n 
-0000376285 00000 n 
-0000376349 00000 n 
-0000376414 00000 n 
-0000376479 00000 n 
-0000376544 00000 n 
-0000376609 00000 n 
-0000376674 00000 n 
-0000376739 00000 n 
-0000376804 00000 n 
-0000376869 00000 n 
-0000376934 00000 n 
-0000376999 00000 n 
-0000377064 00000 n 
-0000377128 00000 n 
-0000377193 00000 n 
-0000377258 00000 n 
-0000377323 00000 n 
-0000377388 00000 n 
-0000377453 00000 n 
-0000377518 00000 n 
-0000377583 00000 n 
-0000377648 00000 n 
-0000377713 00000 n 
-0000377778 00000 n 
-0000377843 00000 n 
-0000377908 00000 n 
-0000377973 00000 n 
-0000378038 00000 n 
-0000378103 00000 n 
-0000378167 00000 n 
-0000378231 00000 n 
-0000378295 00000 n 
-0000378360 00000 n 
-0000378425 00000 n 
-0000378490 00000 n 
-0000378555 00000 n 
-0000378620 00000 n 
-0000378685 00000 n 
-0000378750 00000 n 
-0000378815 00000 n 
-0000378880 00000 n 
-0000378944 00000 n 
-0000385183 00000 n 
-0000381745 00000 n 
-0000379120 00000 n 
-0000381871 00000 n 
-0000381936 00000 n 
-0000382001 00000 n 
-0000382066 00000 n 
-0000382131 00000 n 
-0000382196 00000 n 
-0000382261 00000 n 
-0000382326 00000 n 
-0000382391 00000 n 
-0000382456 00000 n 
-0000382521 00000 n 
-0000382586 00000 n 
-0000382651 00000 n 
-0000382716 00000 n 
-0000382781 00000 n 
-0000382846 00000 n 
-0000382911 00000 n 
-0000382976 00000 n 
-0000383041 00000 n 
-0000383106 00000 n 
-0000383171 00000 n 
-0000383236 00000 n 
-0000383301 00000 n 
-0000383366 00000 n 
-0000383431 00000 n 
-0000383496 00000 n 
-0000383561 00000 n 
-0000383626 00000 n 
-0000383691 00000 n 
-0000383756 00000 n 
-0000383821 00000 n 
-0000383886 00000 n 
-0000383951 00000 n 
-0000384016 00000 n 
-0000384080 00000 n 
-0000384145 00000 n 
-0000384210 00000 n 
-0000384275 00000 n 
-0000384340 00000 n 
-0000384405 00000 n 
-0000384470 00000 n 
-0000384535 00000 n 
-0000384600 00000 n 
-0000384665 00000 n 
-0000384730 00000 n 
-0000384795 00000 n 
-0000384860 00000 n 
-0000384925 00000 n 
-0000384990 00000 n 
-0000385055 00000 n 
-0000385119 00000 n 
-0000389762 00000 n 
-0000387498 00000 n 
-0000385295 00000 n 
-0000387624 00000 n 
-0000387689 00000 n 
-0000387754 00000 n 
-0000387819 00000 n 
-0000387884 00000 n 
-0000387949 00000 n 
-0000388014 00000 n 
-0000388079 00000 n 
-0000388144 00000 n 
-0000388209 00000 n 
-0000388274 00000 n 
-0000388339 00000 n 
-0000388404 00000 n 
-0000388469 00000 n 
-0000388531 00000 n 
-0000388595 00000 n 
-0000388660 00000 n 
-0000388724 00000 n 
-0000388789 00000 n 
-0000388854 00000 n 
-0000388919 00000 n 
-0000388984 00000 n 
-0000389049 00000 n 
-0000389114 00000 n 
-0000389179 00000 n 
-0000389308 00000 n 
-0000389437 00000 n 
-0000389502 00000 n 
-0000389567 00000 n 
-0000389632 00000 n 
-0000389697 00000 n 
-0000392556 00000 n 
-0000391912 00000 n 
-0000389887 00000 n 
-0000392038 00000 n 
-0000392167 00000 n 
-0000392296 00000 n 
-0000392361 00000 n 
-0000392426 00000 n 
-0000392491 00000 n 
-0000662839 00000 n 
-0000396894 00000 n 
-0000396574 00000 n 
-0000392668 00000 n 
-0000396700 00000 n 
-0000396765 00000 n 
-0000396830 00000 n 
-0000400491 00000 n 
-0000400236 00000 n 
-0000397046 00000 n 
-0000400362 00000 n 
-0000400427 00000 n 
-0000403738 00000 n 
-0000403547 00000 n 
-0000400629 00000 n 
-0000403673 00000 n 
-0000407521 00000 n 
-0000407265 00000 n 
-0000403863 00000 n 
-0000407391 00000 n 
-0000407456 00000 n 
-0000410695 00000 n 
-0000409920 00000 n 
-0000407659 00000 n 
-0000410046 00000 n 
-0000410111 00000 n 
-0000410176 00000 n 
-0000410241 00000 n 
-0000410306 00000 n 
-0000410435 00000 n 
-0000410500 00000 n 
-0000410565 00000 n 
-0000410630 00000 n 
-0000415163 00000 n 
-0000414972 00000 n 
-0000410833 00000 n 
-0000415098 00000 n 
-0000662964 00000 n 
-0000418292 00000 n 
-0000417519 00000 n 
-0000415301 00000 n 
-0000417645 00000 n 
-0000417710 00000 n 
-0000417775 00000 n 
-0000417839 00000 n 
-0000417968 00000 n 
-0000418033 00000 n 
-0000418097 00000 n 
-0000418162 00000 n 
-0000418227 00000 n 
-0000421683 00000 n 
-0000421427 00000 n 
-0000418430 00000 n 
-0000421553 00000 n 
-0000421618 00000 n 
-0000424546 00000 n 
-0000423836 00000 n 
-0000421821 00000 n 
-0000423962 00000 n 
-0000424027 00000 n 
-0000424092 00000 n 
-0000424157 00000 n 
-0000424286 00000 n 
-0000424351 00000 n 
-0000424416 00000 n 
-0000424481 00000 n 
-0000428225 00000 n 
-0000427969 00000 n 
-0000424697 00000 n 
-0000428095 00000 n 
-0000428160 00000 n 
-0000431662 00000 n 
-0000431406 00000 n 
-0000428350 00000 n 
-0000431532 00000 n 
-0000431597 00000 n 
-0000434131 00000 n 
-0000433423 00000 n 
-0000431800 00000 n 
-0000433549 00000 n 
-0000433614 00000 n 
-0000433679 00000 n 
-0000433806 00000 n 
-0000433871 00000 n 
-0000433936 00000 n 
-0000434001 00000 n 
-0000434066 00000 n 
-0000663089 00000 n 
-0000437017 00000 n 
-0000436243 00000 n 
-0000434282 00000 n 
-0000436369 00000 n 
-0000436434 00000 n 
-0000436499 00000 n 
-0000436564 00000 n 
-0000436692 00000 n 
-0000436757 00000 n 
-0000436822 00000 n 
-0000436887 00000 n 
-0000436952 00000 n 
-0000440374 00000 n 
-0000440183 00000 n 
-0000437155 00000 n 
-0000440309 00000 n 
-0000443345 00000 n 
-0000442636 00000 n 
-0000440499 00000 n 
-0000442762 00000 n 
-0000442827 00000 n 
-0000442892 00000 n 
-0000442957 00000 n 
-0000443085 00000 n 
-0000443150 00000 n 
-0000443215 00000 n 
-0000443280 00000 n 
-0000446857 00000 n 
-0000446601 00000 n 
-0000443496 00000 n 
-0000446727 00000 n 
-0000446792 00000 n 
-0000449734 00000 n 
-0000449478 00000 n 
-0000447065 00000 n 
-0000449604 00000 n 
-0000449669 00000 n 
-0000452735 00000 n 
-0000451960 00000 n 
-0000449942 00000 n 
-0000452086 00000 n 
-0000452151 00000 n 
-0000452216 00000 n 
-0000452281 00000 n 
-0000452346 00000 n 
-0000452475 00000 n 
-0000452540 00000 n 
-0000452605 00000 n 
-0000452670 00000 n 
-0000663214 00000 n 
-0000456244 00000 n 
-0000455601 00000 n 
-0000452886 00000 n 
-0000455727 00000 n 
-0000455792 00000 n 
-0000455857 00000 n 
-0000455922 00000 n 
-0000455987 00000 n 
-0000456115 00000 n 
-0000456180 00000 n 
-0000459805 00000 n 
-0000459419 00000 n 
-0000456408 00000 n 
-0000459545 00000 n 
-0000459610 00000 n 
-0000459675 00000 n 
-0000459740 00000 n 
-0000462158 00000 n 
-0000461773 00000 n 
-0000459930 00000 n 
-0000461899 00000 n 
-0000461964 00000 n 
-0000462029 00000 n 
-0000462094 00000 n 
-0000465838 00000 n 
-0000465258 00000 n 
-0000462309 00000 n 
-0000465384 00000 n 
-0000465513 00000 n 
-0000465578 00000 n 
-0000465643 00000 n 
-0000465708 00000 n 
-0000465773 00000 n 
-0000467865 00000 n 
-0000467479 00000 n 
-0000465976 00000 n 
-0000467605 00000 n 
-0000467670 00000 n 
-0000467735 00000 n 
-0000467800 00000 n 
-0000468082 00000 n 
-0000479426 00000 n 
-0000481751 00000 n 
-0000481720 00000 n 
-0000491245 00000 n 
-0000501302 00000 n 
-0000511771 00000 n 
-0000523978 00000 n 
-0000542255 00000 n 
-0000564344 00000 n 
-0000585354 00000 n 
-0000603172 00000 n 
-0000606004 00000 n 
-0000605774 00000 n 
-0000633262 00000 n 
-0000660371 00000 n 
-0000663339 00000 n 
-0000663462 00000 n 
-0000663588 00000 n 
-0000663714 00000 n 
-0000663804 00000 n 
-0000663896 00000 n 
-0000679280 00000 n 
-0000696733 00000 n 
-0000696774 00000 n 
-0000696814 00000 n 
-0000696948 00000 n 
+0000259012 00000 n 
+0000262027 00000 n 
+0000261857 00000 n 
+0000262219 00000 n 
+0000262284 00000 n 
+0000262412 00000 n 
+0000267096 00000 n 
+0000266552 00000 n 
+0000262658 00000 n 
+0000267031 00000 n 
+0000266708 00000 n 
+0000266869 00000 n 
+0000346375 00000 n 
+0000271579 00000 n 
+0000270943 00000 n 
+0000267263 00000 n 
+0000271257 00000 n 
+0000481658 00000 n 
+0000479660 00000 n 
+0000481493 00000 n 
+0000271386 00000 n 
+0000271090 00000 n 
+0000271515 00000 n 
+0000290384 00000 n 
+0000274337 00000 n 
+0000274146 00000 n 
+0000271705 00000 n 
+0000274272 00000 n 
+0000277986 00000 n 
+0000277409 00000 n 
+0000274504 00000 n 
+0000277535 00000 n 
+0000277729 00000 n 
+0000277794 00000 n 
+0000281582 00000 n 
+0000281133 00000 n 
+0000278085 00000 n 
+0000281259 00000 n 
+0000281388 00000 n 
+0000662363 00000 n 
+0000286591 00000 n 
+0000286059 00000 n 
+0000281694 00000 n 
+0000286526 00000 n 
+0000286215 00000 n 
+0000286366 00000 n 
+0000290578 00000 n 
+0000289697 00000 n 
+0000286690 00000 n 
+0000289998 00000 n 
+0000290127 00000 n 
+0000290255 00000 n 
+0000289844 00000 n 
+0000290513 00000 n 
+0000292824 00000 n 
+0000292504 00000 n 
+0000290690 00000 n 
+0000292630 00000 n 
+0000294308 00000 n 
+0000294117 00000 n 
+0000292936 00000 n 
+0000294243 00000 n 
+0000295673 00000 n 
+0000295482 00000 n 
+0000294407 00000 n 
+0000295608 00000 n 
+0000299266 00000 n 
+0000298689 00000 n 
+0000295772 00000 n 
+0000298815 00000 n 
+0000298944 00000 n 
+0000299071 00000 n 
+0000299136 00000 n 
+0000299201 00000 n 
+0000662488 00000 n 
+0000304293 00000 n 
+0000302624 00000 n 
+0000299378 00000 n 
+0000303970 00000 n 
+0000302825 00000 n 
+0000304099 00000 n 
+0000304228 00000 n 
+0000302992 00000 n 
+0000303154 00000 n 
+0000303316 00000 n 
+0000303478 00000 n 
+0000303640 00000 n 
+0000303810 00000 n 
+0000468171 00000 n 
+0000309437 00000 n 
+0000307859 00000 n 
+0000304405 00000 n 
+0000309372 00000 n 
+0000308069 00000 n 
+0000308232 00000 n 
+0000308393 00000 n 
+0000308554 00000 n 
+0000308716 00000 n 
+0000308879 00000 n 
+0000309042 00000 n 
+0000309205 00000 n 
+0000315673 00000 n 
+0000312419 00000 n 
+0000309562 00000 n 
+0000315608 00000 n 
+0000312719 00000 n 
+0000312889 00000 n 
+0000313051 00000 n 
+0000313213 00000 n 
+0000313375 00000 n 
+0000313536 00000 n 
+0000313699 00000 n 
+0000313853 00000 n 
+0000314006 00000 n 
+0000314168 00000 n 
+0000314330 00000 n 
+0000314491 00000 n 
+0000314653 00000 n 
+0000314815 00000 n 
+0000314977 00000 n 
+0000315139 00000 n 
+0000315292 00000 n 
+0000315455 00000 n 
+0000320080 00000 n 
+0000319284 00000 n 
+0000315798 00000 n 
+0000319757 00000 n 
+0000319440 00000 n 
+0000319603 00000 n 
+0000319951 00000 n 
+0000320015 00000 n 
+0000324370 00000 n 
+0000323173 00000 n 
+0000320205 00000 n 
+0000323660 00000 n 
+0000323789 00000 n 
+0000324045 00000 n 
+0000323329 00000 n 
+0000323499 00000 n 
+0000324110 00000 n 
+0000324175 00000 n 
+0000324240 00000 n 
+0000324305 00000 n 
+0000327696 00000 n 
+0000327505 00000 n 
+0000324495 00000 n 
+0000327631 00000 n 
+0000662613 00000 n 
+0000331782 00000 n 
+0000331203 00000 n 
+0000327782 00000 n 
+0000331329 00000 n 
+0000331394 00000 n 
+0000331459 00000 n 
+0000331588 00000 n 
+0000331652 00000 n 
+0000331717 00000 n 
+0000335813 00000 n 
+0000334975 00000 n 
+0000331907 00000 n 
+0000335101 00000 n 
+0000335166 00000 n 
+0000335231 00000 n 
+0000335360 00000 n 
+0000335425 00000 n 
+0000335490 00000 n 
+0000335618 00000 n 
+0000335683 00000 n 
+0000335748 00000 n 
+0000339314 00000 n 
+0000338609 00000 n 
+0000335938 00000 n 
+0000338735 00000 n 
+0000338864 00000 n 
+0000338928 00000 n 
+0000338993 00000 n 
+0000339122 00000 n 
+0000339249 00000 n 
+0000342531 00000 n 
+0000341824 00000 n 
+0000339522 00000 n 
+0000341950 00000 n 
+0000342079 00000 n 
+0000342208 00000 n 
+0000342337 00000 n 
+0000342402 00000 n 
+0000342467 00000 n 
+0000346440 00000 n 
+0000346120 00000 n 
+0000342712 00000 n 
+0000346246 00000 n 
+0000348466 00000 n 
+0000348017 00000 n 
+0000346565 00000 n 
+0000348143 00000 n 
+0000348272 00000 n 
+0000348401 00000 n 
+0000662738 00000 n 
+0000352959 00000 n 
+0000352015 00000 n 
+0000348578 00000 n 
+0000352378 00000 n 
+0000479339 00000 n 
+0000470126 00000 n 
+0000479153 00000 n 
+0000352162 00000 n 
+0000352507 00000 n 
+0000352636 00000 n 
+0000352765 00000 n 
+0000353999 00000 n 
+0000353808 00000 n 
+0000353194 00000 n 
+0000353934 00000 n 
+0000354426 00000 n 
+0000354235 00000 n 
+0000354085 00000 n 
+0000354361 00000 n 
+0000357739 00000 n 
+0000356513 00000 n 
+0000354468 00000 n 
+0000357030 00000 n 
+0000357159 00000 n 
+0000357288 00000 n 
+0000357417 00000 n 
+0000357546 00000 n 
+0000357675 00000 n 
+0000356669 00000 n 
+0000356841 00000 n 
+0000358193 00000 n 
+0000358002 00000 n 
+0000357852 00000 n 
+0000358128 00000 n 
+0000361437 00000 n 
+0000360859 00000 n 
+0000358235 00000 n 
+0000360985 00000 n 
+0000361114 00000 n 
+0000361243 00000 n 
+0000361372 00000 n 
+0000662863 00000 n 
+0000365632 00000 n 
+0000364414 00000 n 
+0000361523 00000 n 
+0000364924 00000 n 
+0000365053 00000 n 
+0000365311 00000 n 
+0000364570 00000 n 
+0000364749 00000 n 
+0000365504 00000 n 
+0000365568 00000 n 
+0000372517 00000 n 
+0000368689 00000 n 
+0000365784 00000 n 
+0000368815 00000 n 
+0000368880 00000 n 
+0000368945 00000 n 
+0000369010 00000 n 
+0000369075 00000 n 
+0000369140 00000 n 
+0000369205 00000 n 
+0000369270 00000 n 
+0000369335 00000 n 
+0000369400 00000 n 
+0000369530 00000 n 
+0000369595 00000 n 
+0000369660 00000 n 
+0000369725 00000 n 
+0000369790 00000 n 
+0000369855 00000 n 
+0000369920 00000 n 
+0000369985 00000 n 
+0000370050 00000 n 
+0000370115 00000 n 
+0000370180 00000 n 
+0000370245 00000 n 
+0000370310 00000 n 
+0000370375 00000 n 
+0000370440 00000 n 
+0000370505 00000 n 
+0000370570 00000 n 
+0000370635 00000 n 
+0000370700 00000 n 
+0000370765 00000 n 
+0000370830 00000 n 
+0000370895 00000 n 
+0000370960 00000 n 
+0000371025 00000 n 
+0000371089 00000 n 
+0000371154 00000 n 
+0000371219 00000 n 
+0000371284 00000 n 
+0000371349 00000 n 
+0000371414 00000 n 
+0000371479 00000 n 
+0000371544 00000 n 
+0000371609 00000 n 
+0000371674 00000 n 
+0000371739 00000 n 
+0000371804 00000 n 
+0000371869 00000 n 
+0000371934 00000 n 
+0000371999 00000 n 
+0000372064 00000 n 
+0000372129 00000 n 
+0000372194 00000 n 
+0000372259 00000 n 
+0000372324 00000 n 
+0000372389 00000 n 
+0000372453 00000 n 
+0000379163 00000 n 
+0000375599 00000 n 
+0000372629 00000 n 
+0000375725 00000 n 
+0000375790 00000 n 
+0000375855 00000 n 
+0000375920 00000 n 
+0000375985 00000 n 
+0000376050 00000 n 
+0000376115 00000 n 
+0000376180 00000 n 
+0000376245 00000 n 
+0000376310 00000 n 
+0000376375 00000 n 
+0000376440 00000 n 
+0000376504 00000 n 
+0000376569 00000 n 
+0000376634 00000 n 
+0000376699 00000 n 
+0000376764 00000 n 
+0000376829 00000 n 
+0000376894 00000 n 
+0000376959 00000 n 
+0000377024 00000 n 
+0000377089 00000 n 
+0000377154 00000 n 
+0000377219 00000 n 
+0000377283 00000 n 
+0000377348 00000 n 
+0000377413 00000 n 
+0000377478 00000 n 
+0000377543 00000 n 
+0000377608 00000 n 
+0000377673 00000 n 
+0000377738 00000 n 
+0000377803 00000 n 
+0000377868 00000 n 
+0000377933 00000 n 
+0000377998 00000 n 
+0000378063 00000 n 
+0000378128 00000 n 
+0000378193 00000 n 
+0000378258 00000 n 
+0000378322 00000 n 
+0000378386 00000 n 
+0000378450 00000 n 
+0000378515 00000 n 
+0000378580 00000 n 
+0000378645 00000 n 
+0000378710 00000 n 
+0000378775 00000 n 
+0000378840 00000 n 
+0000378905 00000 n 
+0000378970 00000 n 
+0000379035 00000 n 
+0000379099 00000 n 
+0000385338 00000 n 
+0000381900 00000 n 
+0000379275 00000 n 
+0000382026 00000 n 
+0000382091 00000 n 
+0000382156 00000 n 
+0000382221 00000 n 
+0000382286 00000 n 
+0000382351 00000 n 
+0000382416 00000 n 
+0000382481 00000 n 
+0000382546 00000 n 
+0000382611 00000 n 
+0000382676 00000 n 
+0000382741 00000 n 
+0000382806 00000 n 
+0000382871 00000 n 
+0000382936 00000 n 
+0000383001 00000 n 
+0000383066 00000 n 
+0000383131 00000 n 
+0000383196 00000 n 
+0000383261 00000 n 
+0000383326 00000 n 
+0000383391 00000 n 
+0000383456 00000 n 
+0000383521 00000 n 
+0000383586 00000 n 
+0000383651 00000 n 
+0000383716 00000 n 
+0000383781 00000 n 
+0000383846 00000 n 
+0000383911 00000 n 
+0000383976 00000 n 
+0000384041 00000 n 
+0000384106 00000 n 
+0000384171 00000 n 
+0000384235 00000 n 
+0000384300 00000 n 
+0000384365 00000 n 
+0000384430 00000 n 
+0000384495 00000 n 
+0000384560 00000 n 
+0000384625 00000 n 
+0000384690 00000 n 
+0000384755 00000 n 
+0000384820 00000 n 
+0000384885 00000 n 
+0000384950 00000 n 
+0000385015 00000 n 
+0000385080 00000 n 
+0000385145 00000 n 
+0000385210 00000 n 
+0000385274 00000 n 
+0000389917 00000 n 
+0000387653 00000 n 
+0000385450 00000 n 
+0000387779 00000 n 
+0000387844 00000 n 
+0000387909 00000 n 
+0000387974 00000 n 
+0000388039 00000 n 
+0000388104 00000 n 
+0000388169 00000 n 
+0000388234 00000 n 
+0000388299 00000 n 
+0000388364 00000 n 
+0000388429 00000 n 
+0000388494 00000 n 
+0000388559 00000 n 
+0000388624 00000 n 
+0000388686 00000 n 
+0000388750 00000 n 
+0000388815 00000 n 
+0000388879 00000 n 
+0000388944 00000 n 
+0000389009 00000 n 
+0000389074 00000 n 
+0000389139 00000 n 
+0000389204 00000 n 
+0000389269 00000 n 
+0000389334 00000 n 
+0000389463 00000 n 
+0000389592 00000 n 
+0000389657 00000 n 
+0000389722 00000 n 
+0000389787 00000 n 
+0000389852 00000 n 
+0000392711 00000 n 
+0000392067 00000 n 
+0000390042 00000 n 
+0000392193 00000 n 
+0000392322 00000 n 
+0000392451 00000 n 
+0000392516 00000 n 
+0000392581 00000 n 
+0000392646 00000 n 
+0000662988 00000 n 
+0000397049 00000 n 
+0000396729 00000 n 
+0000392823 00000 n 
+0000396855 00000 n 
+0000396920 00000 n 
+0000396985 00000 n 
+0000400646 00000 n 
+0000400391 00000 n 
+0000397201 00000 n 
+0000400517 00000 n 
+0000400582 00000 n 
+0000403893 00000 n 
+0000403702 00000 n 
+0000400784 00000 n 
+0000403828 00000 n 
+0000407676 00000 n 
+0000407420 00000 n 
+0000404018 00000 n 
+0000407546 00000 n 
+0000407611 00000 n 
+0000410850 00000 n 
+0000410075 00000 n 
+0000407814 00000 n 
+0000410201 00000 n 
+0000410266 00000 n 
+0000410331 00000 n 
+0000410396 00000 n 
+0000410461 00000 n 
+0000410590 00000 n 
+0000410655 00000 n 
+0000410720 00000 n 
+0000410785 00000 n 
+0000415318 00000 n 
+0000415127 00000 n 
+0000410988 00000 n 
+0000415253 00000 n 
+0000663113 00000 n 
+0000418447 00000 n 
+0000417674 00000 n 
+0000415456 00000 n 
+0000417800 00000 n 
+0000417865 00000 n 
+0000417930 00000 n 
+0000417994 00000 n 
+0000418123 00000 n 
+0000418188 00000 n 
+0000418252 00000 n 
+0000418317 00000 n 
+0000418382 00000 n 
+0000421838 00000 n 
+0000421582 00000 n 
+0000418585 00000 n 
+0000421708 00000 n 
+0000421773 00000 n 
+0000424701 00000 n 
+0000423991 00000 n 
+0000421976 00000 n 
+0000424117 00000 n 
+0000424182 00000 n 
+0000424247 00000 n 
+0000424312 00000 n 
+0000424441 00000 n 
+0000424506 00000 n 
+0000424571 00000 n 
+0000424636 00000 n 
+0000428380 00000 n 
+0000428124 00000 n 
+0000424852 00000 n 
+0000428250 00000 n 
+0000428315 00000 n 
+0000431817 00000 n 
+0000431561 00000 n 
+0000428505 00000 n 
+0000431687 00000 n 
+0000431752 00000 n 
+0000434286 00000 n 
+0000433578 00000 n 
+0000431955 00000 n 
+0000433704 00000 n 
+0000433769 00000 n 
+0000433834 00000 n 
+0000433961 00000 n 
+0000434026 00000 n 
+0000434091 00000 n 
+0000434156 00000 n 
+0000434221 00000 n 
+0000663238 00000 n 
+0000437172 00000 n 
+0000436398 00000 n 
+0000434437 00000 n 
+0000436524 00000 n 
+0000436589 00000 n 
+0000436654 00000 n 
+0000436719 00000 n 
+0000436847 00000 n 
+0000436912 00000 n 
+0000436977 00000 n 
+0000437042 00000 n 
+0000437107 00000 n 
+0000440529 00000 n 
+0000440338 00000 n 
+0000437310 00000 n 
+0000440464 00000 n 
+0000443500 00000 n 
+0000442791 00000 n 
+0000440654 00000 n 
+0000442917 00000 n 
+0000442982 00000 n 
+0000443047 00000 n 
+0000443112 00000 n 
+0000443240 00000 n 
+0000443305 00000 n 
+0000443370 00000 n 
+0000443435 00000 n 
+0000447012 00000 n 
+0000446756 00000 n 
+0000443651 00000 n 
+0000446882 00000 n 
+0000446947 00000 n 
+0000449889 00000 n 
+0000449633 00000 n 
+0000447220 00000 n 
+0000449759 00000 n 
+0000449824 00000 n 
+0000452890 00000 n 
+0000452115 00000 n 
+0000450097 00000 n 
+0000452241 00000 n 
+0000452306 00000 n 
+0000452371 00000 n 
+0000452436 00000 n 
+0000452501 00000 n 
+0000452630 00000 n 
+0000452695 00000 n 
+0000452760 00000 n 
+0000452825 00000 n 
+0000663363 00000 n 
+0000456399 00000 n 
+0000455756 00000 n 
+0000453041 00000 n 
+0000455882 00000 n 
+0000455947 00000 n 
+0000456012 00000 n 
+0000456077 00000 n 
+0000456142 00000 n 
+0000456270 00000 n 
+0000456335 00000 n 
+0000459960 00000 n 
+0000459574 00000 n 
+0000456563 00000 n 
+0000459700 00000 n 
+0000459765 00000 n 
+0000459830 00000 n 
+0000459895 00000 n 
+0000462313 00000 n 
+0000461928 00000 n 
+0000460085 00000 n 
+0000462054 00000 n 
+0000462119 00000 n 
+0000462184 00000 n 
+0000462249 00000 n 
+0000465993 00000 n 
+0000465413 00000 n 
+0000462464 00000 n 
+0000465539 00000 n 
+0000465668 00000 n 
+0000465733 00000 n 
+0000465798 00000 n 
+0000465863 00000 n 
+0000465928 00000 n 
+0000468020 00000 n 
+0000467634 00000 n 
+0000466131 00000 n 
+0000467760 00000 n 
+0000467825 00000 n 
+0000467890 00000 n 
+0000467955 00000 n 
+0000468237 00000 n 
+0000479581 00000 n 
+0000481905 00000 n 
+0000481874 00000 n 
+0000491398 00000 n 
+0000501455 00000 n 
+0000511923 00000 n 
+0000524127 00000 n 
+0000542404 00000 n 
+0000564494 00000 n 
+0000585504 00000 n 
+0000603322 00000 n 
+0000606153 00000 n 
+0000605923 00000 n 
+0000633411 00000 n 
+0000660520 00000 n 
+0000663488 00000 n 
+0000663611 00000 n 
+0000663737 00000 n 
+0000663863 00000 n 
+0000663953 00000 n 
+0000664045 00000 n 
+0000679429 00000 n 
+0000696882 00000 n 
+0000696923 00000 n 
+0000696963 00000 n 
+0000697097 00000 n 
 trailer
 <<
 /Size 1969
 /Root 1967 0 R
 /Info 1968 0 R
-/ID [ ]
+/ID [<5A978E7AECC3CFD4A1B098C19FF78DD9> <5A978E7AECC3CFD4A1B098C19FF78DD9>]
 >>
 startxref
-697206
+697355
 %%EOF
diff --git a/doc/arm/man.dig.html b/doc/arm/man.dig.html
index fed552ef07b8..750457309d61 100644
--- a/doc/arm/man.dig.html
+++ b/doc/arm/man.dig.html
@@ -1,5 +1,5 @@
 
-
+
 
 
 
@@ -52,7 +52,7 @@
 
dig  [global-queryopt...] [query...]

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
SIMPLE USAGE

+
SIMPLE USAGE

 

       A typical invocation of dig looks like:
       

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

 

 

-
OPTIONS

+
OPTIONS

 

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

 

 

-
QUERY OPTIONS

+
QUERY OPTIONS

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

 

 

-
MULTIPLE QUERIES

+
MULTIPLE QUERIES

 

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

 

 

-
IDN SUPPORT

+
IDN SUPPORT

 

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

 

 

-
FILES

+
FILES

 
/etc/resolv.conf
     

 
${HOME}/.digrc
     

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
BUGS

+
BUGS

 

       There are probably too many query options.
     

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

 

 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
OPTIONS

+
OPTIONS

 

 
-a algorithm

 

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

 

 

-
GENERATED KEYS

+
GENERATED KEYS

 

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

 

 

-
EXAMPLE

+
EXAMPLE

 

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

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

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

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
OPTIONS

+
OPTIONS

 

 
-a

 

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

 

 

-
EXAMPLE

+
EXAMPLE

 

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

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

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

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
IDN SUPPORT

+
IDN SUPPORT

 

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

 

 

-
FILES

+
FILES

 
/etc/resolv.conf
     

 

 

-
SEE ALSO

+
SEE ALSO

 
dig(1),
       named(8).
     

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

 

 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
OPTIONS

+
OPTIONS

 

 
-t directory

 

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

 

 

-
RETURN VALUES

+
RETURN VALUES

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

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

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

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
OPTIONS

+
OPTIONS

 

 
-d

 

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

 

 

-
RETURN VALUES

+
RETURN VALUES

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

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

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

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
OPTIONS

+
OPTIONS

 

 
-4

 

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

 

 

-
SIGNALS

+
SIGNALS

 

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

 

 

-
CONFIGURATION

+
CONFIGURATION

 

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

 

 

-
FILES

+
FILES

 

 
/etc/named.conf

 

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

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

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

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
OPTIONS

+
OPTIONS

 

 
-a

 

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

 

 

-
EXAMPLES

+
EXAMPLES

 

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

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

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

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
EXAMPLE

+
EXAMPLE

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

 

 

-
NAME SERVER CONFIGURATION

+
NAME SERVER CONFIGURATION

 

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

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

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

 
 

-
DESCRIPTION

+
DESCRIPTION

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

 

 

-
OPTIONS

+
OPTIONS

 

 
-b source-address

 

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

 

 

-
LIMITATIONS

+
LIMITATIONS

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

 

 

-
SEE ALSO

+
SEE ALSO

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

 

 

-
AUTHOR

+
AUTHOR

 
Internet Systems Consortium
     

 

diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt
deleted file mode 100644
index f15b069b5ba7..000000000000
--- a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt
+++ /dev/null
@@ -1,785 +0,0 @@
-
-
-
-IPv6 Maintenance Working Group                               S. Kawamura
-Internet-Draft                                         NEC BIGLOBE, Ltd.
-Intended status: Informational                              M. Kawashima
-Expires: April 21, 2010                         NEC AccessTechnica, Ltd.
-                                                        October 18, 2009
-
-
-         A Recommendation for IPv6 Address Text Representation
-              draft-ietf-6man-text-addr-representation-01
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 21, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   As IPv6 network grows, there will be more engineers and also non-
-   engineers who will have the need to use an IPv6 address in text.
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 1]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   While the IPv6 address architecture RFC 4291 section 2.2 depicts a
-   flexible model for text representation of an IPv6 address, this
-   flexibility has been causing problems for operators, system
-   engineers, and users.  This document will describe the problems that
-   a flexible text representation has been causing.  This document also
-   recommends a canonical representation format that best avoids
-   confusion.  It is expected that the canonical format is followed by
-   humans and systems when representing IPv6 addresses as text, but all
-   implementations must accept and be able to handle any legitimate
-   RFC4291 format.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
-   2.  Text Representation Flexibility of RFC4291 . . . . . . . . . .  4
-     2.1.  Leading Zeros in a 16 Bit Field  . . . . . . . . . . . . .  4
-     2.2.  Zero Compression . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Uppercase or Lowercase . . . . . . . . . . . . . . . . . .  5
-   3.  Problems Encountered with the Flexible Model . . . . . . . . .  6
-     3.1.  Searching  . . . . . . . . . . . . . . . . . . . . . . . .  6
-       3.1.1.  General Summary  . . . . . . . . . . . . . . . . . . .  6
-       3.1.2.  Searching Spreadsheets and Text Files  . . . . . . . .  6
-       3.1.3.  Searching with Whois . . . . . . . . . . . . . . . . .  6
-       3.1.4.  Searching for an Address in a Network Diagram  . . . .  7
-     3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
-       3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
-       3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  8
-       3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
-       3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
-       3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
-     3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
-       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  9
-       3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
-     3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
-       3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
-       3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
-       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . . 10
-   4.  A Recommendation for IPv6 Text Representation  . . . . . . . . 10
-     4.1.  Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
-     4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
-       4.2.1.  Shorten As Much As Possible  . . . . . . . . . . . . . 10
-       4.2.2.  Handling One 16 Bit 0 Field  . . . . . . . . . . . . . 10
-       4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
-     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 2]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   5.  Text Representation of Special Addresses . . . . . . . . . . . 11
-   6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
-   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 13
-   Appendix B.  Prefix Issues . . . . . . . . . . . . . . . . . . . . 13
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 3]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-1.  Introduction
-
-   A single IPv6 address can be text represented in many ways.  Examples
-   are shown below.
-
-      2001:db8:0:0:1:0:0:1
-
-      2001:0db8:0:0:1:0:0:1
-
-      2001:db8::1:0:0:1
-
-      2001:db8::0:1:0:0:1
-
-      2001:0db8::1:0:0:1
-
-      2001:db8:0:0:1::1
-
-      2001:db8:0000:0:1::1
-
-      2001:DB8:0:0:1::1
-
-   All the above point to the same IPv6 address.  This flexibility has
-   caused many problems for operators, systems engineers, and customers.
-   The problems will be noted in Section 3.  Also, a canonical
-   representation format to avoid problems will be introduced in
-   Section 4.
-
-1.1.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Text Representation Flexibility of RFC4291
-
-   Examples of flexibility in Section 2.2 of [RFC4291] are described
-   below.
-
-2.1.  Leading Zeros in a 16 Bit Field
-
-      'It is not necessary to write the leading zeros in an individual
-      field.'
-
-   In other words, it is also not necessary to omit leading zeros.  This
-   means that, it is possible to select from such as the following
-   example.  The final 16 bit field is different, but all these
-   addresses mean the same.
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 4]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
-
-2.2.  Zero Compression
-
-      'A special syntax is available to compress the zeros.  The use of
-      "::" indicates one or more groups of 16 bits of zeros.'
-
-   It is possible to select whether or not to omit just one 16 bits of
-   zeros.
-
-      2001:db8:aaaa:bbbb:cccc:dddd::1
-
-      2001:db8:aaaa:bbbb:cccc:dddd:0:1
-
-   In case where there are more than one zero fields, there is a choice
-   of how many fields can be shortened.  Examples follow.
-
-      2001:db8:0:0:0::1
-
-      2001:db8:0:0::1
-
-      2001:db8:0::1
-
-      2001:db8::1
-
-   In addition, [RFC4291] in section 2.2 notes,
-
-      'The "::" can only appear once in an address.'
-
-   This gives a choice on where, in a single address to compress the
-   zero.  Examples are shown below.
-
-      2001:db8::aaaa:0:0:1
-
-      2001:db8:0:0:aaaa::1
-
-2.3.  Uppercase or Lowercase
-
-   [RFC4291] does not mention about preference of uppercase or
-   lowercase.  Various flavors are shown below.
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 5]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
-
-
-3.  Problems Encountered with the Flexible Model
-
-3.1.  Searching
-
-3.1.1.  General Summary
-
-   A search of an IPv6 address if conducted through a UNIX system is
-   usually case sensitive and extended options to allow for regular
-   expression use will come in handy.  However, there are many
-   applications in the Internet today that do not provide this
-   capability.  When searching for an IPv6 address in such systems, the
-   system engineer will have to try each and every possibility to search
-   for an address.  This has critical impacts especially when trying to
-   deploy IPv6 over an enterprise network.
-
-3.1.2.  Searching Spreadsheets and Text Files
-
-   Spreadsheet applications and text editors on GUI systems, rarely have
-   the ability to search for a text using regular expression.  Moreover,
-   there are many non-engineers (who are not aware of case sensitivity
-   and regular expression use) that use these application to manage IP
-   addresses.  This has worked quite well with IPv4 since text
-   representation in IPv4 has very little flexibility.  There is no
-   incentive to encourage these non-engineers to change their tool or
-   learn regular expression when they decide to go dual-stack.  If the
-   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
-   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
-   One example where this will cause problem is, when the search is
-   being conducted to assign a new address from a pool, and a check was
-   being done to see if it was not in use.  This may cause problems to
-   the end-hosts or end-users.  This type of address management is very
-   often seen in enterprise networks and also in ISPs.
-
-3.1.3.  Searching with Whois
-
-   The "whois" utility is used by a wide range of people today.  When a
-   record is set to a database, one will likely check the output to see
-   if the entry is correct.  If an entity was recorded as 2001:db8::/48,
-   but the whois output showed 2001:0db8:0000::/48, most non-engineers
-   would think that their input was wrong, and will likely retry several
-   times or make a frustrated call to the database hostmaster.  If there
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 6]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   was a need to register the same address on different systems, and
-   each system showed a different text representation, this would
-   confuse people even more.  Although this document focuses on
-   addresses rather than prefixes, this is worth mentioning since
-   problems encountered are mostly equal.
-
-3.1.4.  Searching for an Address in a Network Diagram
-
-   Network diagrams and blue-prints contain IP addresses as allocated to
-   system devices.  In times of trouble shooting, there may be a need to
-   search through a diagram to find the point of failure (for example,
-   if a traceroute stopped at 2001:db8::1, one would search the diagram
-   for that address).  This is a technique quite often in use in
-   enterprise networks and managed services.  Again, the different
-   flavors of text representation will result in a time-consuming
-   search, leading to longer MTTR in times of trouble.
-
-3.2.  Parsing and Modifying
-
-3.2.1.  General Summary
-
-   With all the possible text representation ways, each application must
-   include a module, object, link, etc. to a function that will parse
-   IPv6 addresses in a manner that no matter how it is represented, they
-   will mean the same address.  This is not too much a problem if the
-   output is to be just 'read' or 'managed' by a network engineer.
-   However, many system engineers who integrate complex computer systems
-   to corporate customers will have difficulties finding that their
-   favorite tool will not have this function, or will encounter
-   difficulties such as having to rewrite their macro's or scripts for
-   their customers.  It must be noted that each additional line of a
-   program will result in increased development fees that will be
-   charged to the customers.
-
-3.2.2.  Logging
-
-   If an application were to output a log summary that represented the
-   address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
-   the output would be highly unreadable compared to the IPv4 output.
-   The address would have to be parsed and reformed to make it useful
-   for human reading.  This will result in additional code on the
-   applications which will result in extra fees charged to the
-   customers.  Sometimes, logging for critical systems is done by
-   mirroring the same traffic to two different systems.  Care must be
-   taken that no matter what the log output is, the logs should be
-   parsed so they will mean the same.
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 7]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-3.2.3.  Auditing: Case 1
-
-   When a router or any other network appliance machine configuration is
-   audited, there are many methods to compare the configuration
-   information of a node.  Sometimes, auditing will be done by just
-   comparing the changes made each day.  In this case, if configuration
-   was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
-   0000:0000:0000:0001 just because the new engineer on the block felt
-   it was better, a simple diff will tell you that a different address
-   was configured.  If this was done on a wide scale network, people
-   will be focusing on 'why the extra zeros were put in' instead of
-   doing any real auditing.  Lots of tools are just plain 'diff's that
-   do not take into account address representation rules.
-
-3.2.4.  Auditing: Case 2
-
-   Node configurations will be matched against an information system
-   that manages IP addresses.  If output notation is different, there
-   will need to be a script that is implemented to cover for this.  An
-   SNMP GET of an interface address and text representation in a humanly
-   written text file is highly unlikely to match on first try.
-
-3.2.5.  Verification
-
-   Some protocols require certain data fields to be verified.  One
-   example of this is X.509 certificates.  If an IPv6 address was
-   embedded in one of the fields in a certificate, and the verification
-   was done by just a simple textual comparison, the certificate may be
-   maistakenly shown as being invalid due to a difference in text
-   representation methods.
-
-3.2.6.  Unexpected Modifying
-
-   Sometimes, a system will take an address and modify it as a
-   convenience.  For example, a system may take an input of
-   2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
-   RIR databases).  If the zeros were input for a reason, the outcome
-   may be somewhat unexpected.
-
-3.3.  Operating
-
-3.3.1.  General Summary
-
-   When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
-   0:0:1, the system may take the address and show the configuration
-   result as 2001:DB8::1:0:0:1.  A distinguished engineer will know that
-   the right address is set, but an operator, or a customer that is
-   communicating with the operator to solve a problem, is usually not as
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 8]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   distinguished as we would like.  Again, the extra load in checking
-   that the IP address is the same as was intended, will result in fees
-   that will be charged to the customers.
-
-3.3.2.  Customer Calls
-
-   When a customer calls to inquire about a suspected outage, IPv6
-   address representation should be handled with care.  Not all
-   customers are engineers nor have the same skill in IPv6 technology.
-   The NOC will have to take extra steps to humanly parse the address to
-   avoid having to explain to the customers that 2001:db8:0:1::1 is the
-   same as 2001:db8::1:0:0:0:1.  This is one thing that will never
-   happen in IPv4 because IPv4 address cannot be abbreviated.
-
-3.3.3.  Abuse
-
-   Network abuse is reported along with the abusing IP address.  This
-   'reporting' could take any shape or form of the flexible model.  A
-   team that handles network abuse must be able to tell the difference
-   between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
-   placement of the "::" will result in a critical situation.  A system
-   that handles these incidents should be able to handle any type of
-   input and parse it in a correct manner.  Also, incidents are reported
-   over the phone.  It is unnecessary to report if the letter is an
-   uppercase or lowercase.  However, when a letter is spelled uppercase,
-   people tend to clarify that it is uppercase, which is unnecessary
-   information.
-
-3.4.  Other Minor Problems
-
-3.4.1.  Changing Platforms
-
-   When an engineer decides to change the platform of a running service,
-   the same code may not work as expected due to the difference in IPv6
-   address text representation.  Usually, a change in a platform (e.g.
-   Unix to Windows, Cisco to Juniper) will result in a major change of
-   code, but flexibility in address representation will increase the
-   work load which will again, result in fees that will be charged to
-   the customers, and also longer down time of systems.
-
-3.4.2.  Preference in Documentation
-
-   A document that is edited by more than one author, may become harder
-   to read.
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                 [Page 9]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-3.4.3.  Legibility
-
-   Capital case D and 0 can be quite often misread.  Capital B and 8 can
-   also be misread.
-
-
-4.  A Recommendation for IPv6 Text Representation
-
-   A recommendation for a canonical text representation format of IPv6
-   addresses is presented in this section.  The recommendation in this
-   document is one that, complies fully with [RFC4291], is implemented
-   by various operating systems, and is human friendly.  The
-   recommendation in this document SHOULD be followed by humans and
-   systems when generating an address to represent as text, but all
-   implementations MUST accept any legitimate [RFC4291] format.
-
-4.1.  Handling Leading Zeros in a 16 Bit Field
-
-   Leading zeros should be chopped for human legibility and easier
-   searching.  Also, a single 16 bit 0000 field should be represented as
-   just 0.  Place holder zeros are often cause of misreading.
-
-4.2.  "::" Usage
-
-4.2.1.  Shorten As Much As Possible
-
-   The use of "::" should be used to its maximum capability (i.e. 2001:
-   db8::0:1 is not considered as clean representation).
-
-4.2.2.  Handling One 16 Bit 0 Field
-
-   "::" should not be used to shorten just one 16 bit 0 field for it
-   would tend to mislead that there are more than one 16 bit field that
-   is shortened.
-
-4.2.3.  Choice in Placement of "::"
-
-   When there is an alternative choice in the placement of a "::", the
-   longest run of consecutive 16 bit 0 fields should be shortened (i.e.
-   latter is shortened in 2001:0:0:1:0:0:0:1).  When the length of the
-   consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
-   the former is shortened.  This is consistent with many current
-   implementations.  One idea to avoid any confusion, is for the
-   operator to not use 16 bit field 0 in the first 64 bits.  By nature
-   IPv6 addresses are usually assigned or allocated to end-users as
-   longer than 32 bits (typically 48 bits or longer).
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 10]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-4.3.  Lower Case
-
-   Recent implementations tend to represent IPv6 address as lower case.
-   It is better to use lower case to avoid problems such as described in
-   section 3.3.3 and 3.4.3.
-
-
-5.  Text Representation of Special Addresses
-
-   Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
-   IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in
-   the low-order 32 bits of the address.  These addresses have special
-   representation that may mix hexadecimal and decimal notations.  In
-   cases where there is a choice of whether to express the address as
-   fully hexadecimal or hexadecimal and decimal mixed, and if the
-   address type can be distinguished as having IPv4 addresses embedded
-   in the lower 32 bits solely from the 128bits of the address field
-   itself, mixed notation is the better choice.  However, there may be
-   situations where hexadecimal representation is chosen to meet certain
-   needs.  Addressing those needs is out of the scope of this document.
-   The text representation method noted in Section 4 should be applied
-   for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
-   0:0:0:0:0:ffff:192.0.2.1).
-
-
-6.  Notes on Combining IPv6 Addresses with Port Numbers
-
-   When IPv6 addresses and port numbers are represented in text combined
-   together, there seems to be many different ways to do so.  Examples
-   are shown below.
-
-   o  [2001:db8::1]:80
-
-   o  2001:db8::1:80
-
-   o  2001:db8::1.80
-
-   o  2001:db8::1 port 80
-
-   o  2001:db8::1p80
-
-   o  2001:db8::1#80
-
-   The situation is not much different in IPv4, but the most ambiguous
-   case with IPv6 is the second bullet.  This is due to the "::"usage in
-   IPv6 addresses.  This style is not recommended for its ambiguity.
-   The [] style as expressed in [RFC3986] is recommended.  Other styles
-   are acceptable when cross-platform portability does not become an
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 11]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-   issue.
-
-
-7.  Conclusion
-
-   The recommended format of text representing an IPv6 address is
-   summarized as follows.
-
-      (1) omit leading zeros in a 16 bit field
-
-      (2) when using "::", shorten consecutive zero fields to their
-      maximum extent (leave no zero fields behind).
-
-      (3) "::" used where shortens address the most
-
-      (4) "::" used in the former part in case of a tie breaker
-
-      (5) do not shorten one 16 bit 0 field, but always shorten when
-      there are two or more consecutive 16 bit 0 fields
-
-      (6) use lower case
-
-   Hints for developers are written in the Appendix section.
-
-
-8.  Security Considerations
-
-   None.
-
-
-9.  IANA Considerations
-
-   None.
-
-
-10.  Acknowledgements
-
-   The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
-   Toshimitsu Matsuura for their generous and helpful comments in kick
-   starting this document.  We also would like to thank Brian Carpenter,
-   Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
-   Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
-   Vatiainen for their input.  Also a very special thanks to Ron Bonica,
-   Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt
-   Lindqvist for their support in bringing this document to the light of
-   IETF working groups.
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 12]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-11.  References
-
-11.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", RFC 4291, February 2006.
-
-11.2.  Informative References
-
-   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
-              (SIIT)", RFC 2765, February 2000.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66,
-              RFC 3986, January 2005.
-
-   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
-              Castro, "Application Aspects of IPv6 Transition",
-              RFC 4038, March 2005.
-
-   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
-              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
-              March 2008.
-
-
-Appendix A.  For Developers
-
-   We recommend that developers use display routines that conform to
-   these rules.  For example, the usage of getnameinfo() with flags
-   argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
-   except for the special addresses notes in Section 5.  The function
-   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
-   be called directly.  See [RFC4038] for details.
-
-
-Appendix B.  Prefix Issues
-
-   Problems with prefixes are just the same as problems encountered with
-   addresses.  Text representation method of IPv6 prefixes should be no
-   different from that of IPv6 addresses.
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 13]
-
-Internet-Draft          IPv6 Text Representation            October 2009
-
-
-Authors' Addresses
-
-   Seiichi Kawamura
-   NEC BIGLOBE, Ltd.
-   14-22, Shibaura 4-chome
-   Minatoku, Tokyo  108-8558
-   JAPAN
-
-   Phone: +81 3 3798 6085
-   Email: kawamucho@mesh.ad.jp
-
-
-   Masanobu Kawashima
-   NEC AccessTechnica, Ltd.
-   800, Shimomata
-   Kakegawa-shi, Shizuoka  436-8501
-   JAPAN
-
-   Phone: +81 537 23 9655
-   Email: kawashimam@necat.nec.co.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires April 21, 2010                [Page 14]
-
-
diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-07.txt b/doc/draft/draft-ietf-6man-text-addr-representation-07.txt
new file mode 100644
index 000000000000..3a9f1112f9fa
--- /dev/null
+++ b/doc/draft/draft-ietf-6man-text-addr-representation-07.txt
@@ -0,0 +1,785 @@
+
+
+
+IPv6 Maintenance Working Group                               S. Kawamura
+Internet-Draft                                         NEC BIGLOBE, Ltd.
+Updates: 4291 (if approved)                                 M. Kawashima
+Intended status: Standards Track                NEC AccessTechnica, Ltd.
+Expires: August 29, 2010                               February 25, 2010
+
+
+         A Recommendation for IPv6 Address Text Representation
+              draft-ietf-6man-text-addr-representation-07
+
+Abstract
+
+   As IPv6 deployment increases there will be a dramatic increase in the
+   need to use IPv6 addresses in text.  While the IPv6 address
+   architecture in RFC 4291 section 2.2 describes a flexible model for
+   text representation of an IPv6 address this flexibility has been
+   causing problems for operators, system engineers, and users.  This
+   document defines a canonical textual representation format.  It does
+   not define a format for internal storage, such as within an
+   application or database.  It is expected that the canonical format is
+   followed by humans and systems when representing IPv6 addresses as
+   text, but all implementations must accept and be able to handle any
+   legitimate RFC 4291 format.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 29, 2010.
+
+Copyright Notice
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 1]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 2]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
+   2.  Text Representation Flexibility of RFC4291 . . . . . . . . . .  4
+     2.1.  Leading Zeros in a 16 Bit Field  . . . . . . . . . . . . .  4
+     2.2.  Zero Compression . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Uppercase or Lowercase . . . . . . . . . . . . . . . . . .  5
+   3.  Problems Encountered with the Flexible Model . . . . . . . . .  6
+     3.1.  Searching  . . . . . . . . . . . . . . . . . . . . . . . .  6
+       3.1.1.  General Summary  . . . . . . . . . . . . . . . . . . .  6
+       3.1.2.  Searching Spreadsheets and Text Files  . . . . . . . .  6
+       3.1.3.  Searching with Whois . . . . . . . . . . . . . . . . .  6
+       3.1.4.  Searching for an Address in a Network Diagram  . . . .  7
+     3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
+       3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
+       3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
+       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  7
+       3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
+       3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
+       3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
+     3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
+       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  8
+       3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
+     3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
+       3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
+       3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
+       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  A Recommendation for IPv6 Text Representation  . . . . . . . .  9
+     4.1.  Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
+     4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
+       4.2.1.  Shorten As Much As Possible  . . . . . . . . . . . . . 10
+       4.2.2.  Handling One 16 Bit 0 Field  . . . . . . . . . . . . . 10
+       4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
+     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Text Representation of Special Addresses . . . . . . . . . . . 10
+   6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
+   7.  Prefix Representation  . . . . . . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 13
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 3]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+1.  Introduction
+
+   A single IPv6 address can be text represented in many ways.  Examples
+   are shown below.
+
+      2001:db8:0:0:1:0:0:1
+
+      2001:0db8:0:0:1:0:0:1
+
+      2001:db8::1:0:0:1
+
+      2001:db8::0:1:0:0:1
+
+      2001:0db8::1:0:0:1
+
+      2001:db8:0:0:1::1
+
+      2001:db8:0000:0:1::1
+
+      2001:DB8:0:0:1::1
+
+   All of the above examples represent the same IPv6 address.  This
+   flexibility has caused many problems for operators, systems
+   engineers, and customers.  The problems are noted in Section 3.
+   Also, a canonical representation format to avoid problems is
+   introduced in Section 4.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+2.  Text Representation Flexibility of RFC4291
+
+   Examples of flexibility in Section 2.2 of [RFC4291] are described
+   below.
+
+2.1.  Leading Zeros in a 16 Bit Field
+
+      'It is not necessary to write the leading zeros in an individual
+      field.'
+
+   Conversely it is also not necessary to omit leading zeros.  This
+   means that, it is possible to select from such as the following
+   example.  The final 16 bit field is different, but all these
+   addresses represent the same address.
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 4]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
+
+2.2.  Zero Compression
+
+      'A special syntax is available to compress the zeros.  The use of
+      "::" indicates one or more groups of 16 bits of zeros.'
+
+   It is possible to select whether or not to omit just one 16 bits of
+   zeros.
+
+      2001:db8:aaaa:bbbb:cccc:dddd::1
+
+      2001:db8:aaaa:bbbb:cccc:dddd:0:1
+
+   In case where there is more than one zero fields, there is a choice
+   of how many fields can be shortened.
+
+      2001:db8:0:0:0::1
+
+      2001:db8:0:0::1
+
+      2001:db8:0::1
+
+      2001:db8::1
+
+   In addition, [RFC4291] in section 2.2 notes,
+
+      'The "::" can only appear once in an address.'
+
+   This gives a choice on where in a single address to compress the
+   zero.
+
+      2001:db8::aaaa:0:0:1
+
+      2001:db8:0:0:aaaa::1
+
+2.3.  Uppercase or Lowercase
+
+   [RFC4291] does not mention any preference of uppercase or lowercase.
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 5]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
+
+
+3.  Problems Encountered with the Flexible Model
+
+3.1.  Searching
+
+3.1.1.  General Summary
+
+   A search of an IPv6 address if conducted through a UNIX system is
+   usually case sensitive and extended options to allow for regular
+   expression use will come in handy.  However, there are many
+   applications in the Internet today that do not provide this
+   capability.  When searching for an IPv6 address in such systems, the
+   system engineer will have to try each and every possibility to search
+   for an address.  This has critical impacts especially when trying to
+   deploy IPv6 over an enterprise network.
+
+3.1.2.  Searching Spreadsheets and Text Files
+
+   Spreadsheet applications and text editors on GUI systems, rarely have
+   the ability to search for a text using regular expression.  Moreover,
+   there are many non-engineers (who are not aware of case sensitivity
+   and regular expression use) that use these application to manage IP
+   addresses.  This has worked quite well with IPv4 since text
+   representation in IPv4 has very little flexibility.  There is no
+   incentive to encourage these non-engineers to change their tool or
+   learn regular expression when they decide to go dual-stack.  If the
+   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
+   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
+   One example where this will cause problem is, when the search is
+   being conducted to assign a new address from a pool, and a check was
+   being done to see if it was not in use.  This may cause problems to
+   the end-hosts or end-users.  This type of address management is very
+   often seen in enterprise networks and also in ISPs.
+
+3.1.3.  Searching with Whois
+
+   The "whois" utility is used by a wide range of people today.  When a
+   record is set to a database, one will likely check the output to see
+   if the entry is correct.  If an entity was recorded as 2001:db8::/48,
+   but the whois output showed 2001:0db8:0000::/48, most non-engineers
+   would think that their input was wrong and will likely retry several
+   times or make a frustrated call to the database hostmaster.  If there
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 6]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   was a need to register the same address on different systems, and
+   each system showed a different text representation, this would
+   confuse people even more.  Although this document focuses on
+   addresses rather than prefixes, this is worth mentioning since the
+   problems encountered are mostly equal.
+
+3.1.4.  Searching for an Address in a Network Diagram
+
+   Network diagrams and blueprints often show what IP addresses are
+   assigned to a system devices.  In times of trouble shooting there may
+   be a need to search through a diagram to find the point of failure
+   (for example, if a traceroute stopped at 2001:db8::1, one would
+   search the diagram for that address).  This is a technique quite
+   often in use in enterprise networks and managed services.  Again, the
+   different flavors of text representation will result in a time-
+   consuming search leading to longer MTTR in times of trouble.
+
+3.2.  Parsing and Modifying
+
+3.2.1.  General Summary
+
+   With all the possible methods of text representation each application
+   must include a module, object, link, etc. to a function that will
+   parse IPv6 addresses in a manner that no matter how it is
+   represented, they will mean the same address.  Many system engineers
+   who integrate complex computer systems for corporate customers will
+   have difficulties finding that their favorite tool will not have this
+   function, or will encounter difficulties such as having to rewrite
+   their macros or scripts for their customers.
+
+3.2.2.  Logging
+
+   If an application were to output a log summary that represented the
+   address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
+   the output would be highly unreadable compared to the IPv4 output.
+   The address would have to be parsed and reformed to make it useful
+   for human reading.  Sometimes logging for critical systems is done by
+   mirroring the same traffic to two different systems.  Care must be
+   taken so that no matter what the log output is the logs should be
+   parsed so they will mean the same.
+
+3.2.3.  Auditing: Case 1
+
+   When a router or any other network appliance machine configuration is
+   audited, there are many methods to compare the configuration
+   information of a node.  Sometimes auditing will be done by just
+   comparing the changes made each day.  In this case if configuration
+   was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 7]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   0000:0000:0000:0001 just because the new engineer on the block felt
+   it was better, a simple diff will show that a different address was
+   configured.  If this was done on a wide scale network people will be
+   focusing on 'why the extra zeros were put in' instead of doing any
+   real auditing.  Lots of tools are just plain diffs that do not take
+   into account address representation rules.
+
+3.2.4.  Auditing: Case 2
+
+   Node configurations will be matched against an information system
+   that manages IP addresses.  If output notation is different there
+   will need to be a script that is implemented to cover for this.  The
+   result of an SNMP GET operation, converted to text and compared to a
+   textual address written by a human is highly unlikely to match on the
+   first try.
+
+3.2.5.  Verification
+
+   Some protocols require certain data fields to be verified.  One
+   example of this is X.509 certificates.  If an IPv6 address field in a
+   certificate was incorrectly verified by converting it to text and
+   making a simple textual comparison to some other address, the
+   certificate may be mistakenly shown as being invalid due to a
+   difference in text representation methods.
+
+3.2.6.  Unexpected Modifying
+
+   Sometimes, a system will take an address and modify it as a
+   convenience.  For example, a system may take an input of
+   2001:0db8:0::1 and make the output 2001:db8::1.  If the zeros were
+   input for a reason, the outcome may be somewhat unexpected.
+
+3.3.  Operating
+
+3.3.1.  General Summary
+
+   When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
+   0:0:1, the system may take the address and show the configuration
+   result as 2001:DB8::1:0:0:1.  Someone familiar with IPv6 address
+   representation will know that the right address is set, but not
+   everyone may understand this.
+
+3.3.2.  Customer Calls
+
+   When a customer calls to inquire about a suspected outage, IPv6
+   address representation should be handled with care.  Not all
+   customers are engineers nor have the same skill in IPv6 technology.
+   The network operations center will have to take extra steps to
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 8]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   humanly parse the address to avoid having to explain to the customers
+   that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1.  This is one
+   thing that will never happen in IPv4 because IPv4 address cannot be
+   abbreviated.
+
+3.3.3.  Abuse
+
+   Network abuse reports generally include the abusing IP address.  This
+   'reporting' could take any shape or form of the flexible model.  A
+   team that handles network abuse must be able to tell the difference
+   between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
+   placement of the "::" will result in a critical situation.  A system
+   that handles these incidents should be able to handle any type of
+   input and parse it in a correct manner.  Also, incidents are reported
+   over the phone.  It is unnecessary to report if the letter is an
+   uppercase or lowercase.  However, when a letter is spelled uppercase,
+   people tend to clarify that it is uppercase, which is unnecessary
+   information.
+
+3.4.  Other Minor Problems
+
+3.4.1.  Changing Platforms
+
+   When an engineer decides to change the platform of a running service,
+   the same code may not work as expected due to the difference in IPv6
+   address text representation.  Usually, a change in a platform (e.g.
+   Unix to Windows, Cisco to Juniper) will result in a major change of
+   code anyway, but flexibility in address representation will increase
+   the work load.
+
+3.4.2.  Preference in Documentation
+
+   A document that is edited by more than one author may become harder
+   to read.
+
+3.4.3.  Legibility
+
+   Capital case D and 0 can be quite often misread.  Capital B and 8 can
+   also be misread.
+
+
+4.  A Recommendation for IPv6 Text Representation
+
+   A recommendation for a canonical text representation format of IPv6
+   addresses is presented in this section.  The recommendation in this
+   document is one that, complies fully with [RFC4291], is implemented
+   by various operating systems, and is human friendly.  The
+   recommendation in this section SHOULD be followed by systems when
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010                [Page 9]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   generating an address to represent as text, but all implementations
+   MUST accept and be able to handle any legitimate [RFC4291] format.
+   It is advised that humans also follow these recommendations when
+   spelling an address.
+
+4.1.  Handling Leading Zeros in a 16 Bit Field
+
+   Leading zeros MUST be suppressed.  For example 2001:0db8::0001 is not
+   acceptable and must be represented as 2001:db8::1.  A single 16 bit
+   0000 field MUST be represented as 0.
+
+4.2.  "::" Usage
+
+4.2.1.  Shorten As Much As Possible
+
+   The use of symbol "::" MUST be used to its maximum capability.  For
+   example, 2001:db8::0:1 is not acceptable, because the symbol "::"
+   could have been used to produce a shorter representation 2001:db8::1.
+
+4.2.2.  Handling One 16 Bit 0 Field
+
+   The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field.
+   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
+   2001:db8::1:1:1:1:1 is not correct.
+
+4.2.3.  Choice in Placement of "::"
+
+   When there is an alternative choice in the placement of a "::", the
+   longest run of consecutive 16 bit 0 fields MUST be shortened (i.e.
+   the sequence with three consecutive zero fields is shortened in 2001:
+   0:0:1:0:0:0:1).  When the length of the consecutive 16 bit 0 fields
+   are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero
+   bits MUST be shortened.  For example 2001:db8::1:0:0:1 is correct
+   representation.
+
+4.3.  Lower Case
+
+   The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
+   be represented in lower case.
+
+
+5.  Text Representation of Special Addresses
+
+   Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
+   IPv4-translatable addresses [I-D.ietf-behave-address-format] have
+   IPv4 addresses embedded in the low-order 32 bits of the address.
+   These addresses have special representation that may mix hexadecimal
+   and dot decimal notations.  The decimal notation may be used only for
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 10]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   the last 32 bits of the address.  For these addresses, mixed notation
+   is RECOMMENDED if the following condition is met: The address can be
+   distinguished as having IPv4 addresses embedded in the lower 32 bits
+   solely from the address field through the use of a well known prefix.
+   Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
+   writing.  If it is known by some external method that a given prefix
+   is used to embed IPv4, it MAY be represented as mixed notation.
+   Tools that provide options to specify prefixes that are (or are not)
+   to be represented as mixed notation may be useful.
+
+   There is a trade-off here where a recommendation to achieve exact
+   match in a search (no dot decimals whatsoever) and recommendation to
+   help the readability of an addresses (dot decimal whenever possible)
+   does not result in the same solution.  The above recommendation is
+   aimed at fixing the representation as much as possible while leaving
+   the opportunity for future well known prefixes to be represented in a
+   human friendly manner as tools adjust to newly assigned prefixes.
+
+   The text representation method noted in Section 4 should be applied
+   for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
+   0:0:0:0:0:ffff:192.0.2.1).
+
+
+6.  Notes on Combining IPv6 Addresses with Port Numbers
+
+   When IPv6 addresses and port numbers are represented in text combined
+   together, there are many different ways to do so.  Examples are shown
+   below.
+
+   o  [2001:db8::1]:80
+
+   o  2001:db8::1:80
+
+   o  2001:db8::1.80
+
+   o  2001:db8::1 port 80
+
+   o  2001:db8::1p80
+
+   o  2001:db8::1#80
+
+   The situation is not much different in IPv4, but the most ambiguous
+   case with IPv6 is the second bullet.  This is due to the "::"usage in
+   IPv6 addresses.  This style is NOT RECOMMENDED for its ambiguity.
+   The [] style as expressed in [RFC3986] SHOULD be employed, and is the
+   default unless otherwise specified.  Other styles are acceptable when
+   there is exactly one style for the given context and cross-platform
+   portability does not become an issue.  For URIs containing IPv6
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 11]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   address literals, [RFC3986] MUST be followed, as well as the rules in
+   this document.
+
+
+7.  Prefix Representation
+
+   Problems with prefixes are just the same as problems encountered with
+   addresses.  The text representation method of IPv6 prefixes should be
+   no different from that of IPv6 addresses.
+
+
+8.  Security Considerations
+
+   This document notes some examples where IPv6 addresses are compared
+   in text format.  The example on Section 3.2.5 is one that may cause a
+   security risk if used for access control.  The common practice of
+   comparing X.509 data is done in binary format.
+
+
+9.  IANA Considerations
+
+   None.
+
+
+10.  Acknowledgements
+
+   The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
+   Toshimitsu Matsuura for their generous and helpful comments in kick
+   starting this document.  We also would like to thank Brian Carpenter,
+   Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
+   Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
+   Vatiainen ,Dan Wing, and Doug Barton for their input.  Also a very
+   special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
+   Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
+   this document to the light of IETF working groups.
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+              (SIIT)", RFC 2765, February 2000.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 12]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+11.2.  Informative References
+
+   [I-D.ietf-behave-address-format]
+              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
+              draft-ietf-behave-address-format-04 (work in progress),
+              January 2010.
+
+   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+              Castro, "Application Aspects of IPv6 Transition",
+              RFC 4038, March 2005.
+
+   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
+              March 2008.
+
+
+Appendix A.  For Developers
+
+   We recommend that developers use display routines that conform to
+   these rules.  For example, the usage of getnameinfo() with flags
+   argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
+   except for the special addresses notes in Section 5.  The function
+   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
+   be called directly.  See [RFC4038] for details.
+
+
+Authors' Addresses
+
+   Seiichi Kawamura
+   NEC BIGLOBE, Ltd.
+   14-22, Shibaura 4-chome
+   Minatoku, Tokyo  108-8558
+   JAPAN
+
+   Phone: +81 3 3798 6085
+   Email: kawamucho@mesh.ad.jp
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 13]
+
+Internet-Draft          IPv6 Text Representation           February 2010
+
+
+   Masanobu Kawashima
+   NEC AccessTechnica, Ltd.
+   800, Shimomata
+   Kakegawa-shi, Shizuoka  436-8501
+   JAPAN
+
+   Phone: +81 537 23 9655
+   Email: kawashimam@necat.nec.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima     Expires August 29, 2010               [Page 14]
+
+
diff --git a/doc/draft/draft-ietf-behave-dns64-01.txt b/doc/draft/draft-ietf-behave-dns64-01.txt
deleted file mode 100644
index 25a6dd4d0726..000000000000
--- a/doc/draft/draft-ietf-behave-dns64-01.txt
+++ /dev/null
@@ -1,1624 +0,0 @@
-
-
-
-BEHAVE WG                                                     M. Bagnulo
-Internet-Draft                                                      UC3M
-Intended status: Standards Track                             A. Sullivan
-Expires: April 22, 2010                                         Shinkuro
-                                                             P. Matthews
-                                                          Alcatel-Lucent
-                                                          I. van Beijnum
-                                                          IMDEA Networks
-                                                        October 19, 2009
-
-
-DNS64: DNS extensions for Network Address Translation from IPv6 Clients
-                            to IPv4 Servers
-                       draft-ietf-behave-dns64-01
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 22, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 1]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-Abstract
-
-   DNS64 is a mechanism for synthesizing AAAA records from A records.
-   DNS64 is used with an IPv6/IPv4 translator to enable client-server
-   communication between an IPv6-only client and an IPv4-only server,
-   without requiring any changes to either the IPv6 or the IPv4 node,
-   for the class of applications that work through NATs.  This document
-   specifies DNS64, and provides suggestions on how it should be
-   deployed in conjunction with IPv6/IPv4 translators.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Background to DNS64 - DNSSEC interaction . . . . . . . . . . .  6
-   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   5.  DNS64 Normative Specification  . . . . . . . . . . . . . . . .  9
-     5.1.  Resolving AAAA queries and the answer section  . . . . . .  9
-       5.1.1.  The answer when there is AAAA data available . . . . .  9
-       5.1.2.  The answer when there is an error  . . . . . . . . . .  9
-       5.1.3.  Data for the answer when performing synthesis  . . . .  9
-       5.1.4.  Performing the synthesis . . . . . . . . . . . . . . . 10
-       5.1.5.  Querying in parallel . . . . . . . . . . . . . . . . . 11
-     5.2.  Generation of the IPv6 representations of IPv4
-           addresses  . . . . . . . . . . . . . . . . . . . . . . . . 11
-     5.3.  Handling other RRs . . . . . . . . . . . . . . . . . . . . 12
-       5.3.1.  PTR queries  . . . . . . . . . . . . . . . . . . . . . 12
-       5.3.2.  Handling the additional section  . . . . . . . . . . . 13
-       5.3.3.  Other records  . . . . . . . . . . . . . . . . . . . . 13
-     5.4.  Assembling a synthesized response to a AAAA query  . . . . 14
-     5.5.  DNSSEC processing: DNS64 in recursive server mode  . . . . 14
-     5.6.  DNS64 and multihoming  . . . . . . . . . . . . . . . . . . 15
-   6.  Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16
-     6.1.  DNS resolvers and DNS64  . . . . . . . . . . . . . . . . . 16
-     6.2.  DNSSEC validators and DNS64  . . . . . . . . . . . . . . . 16
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
-   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
-   Appendix A.  Deployment scenarios and examples . . . . . . . . . . 20
-     A.1.  Embed and Zero-Pad algorithm description . . . . . . . . . 21
-     A.2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in
-           DNS server mode  . . . . . . . . . . . . . . . . . . . . . 22
-     A.3.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in
-           stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 2]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-     A.4.  IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
-           server mode  . . . . . . . . . . . . . . . . . . . . . . . 25
-   Appendix B.  Motivations and Implications of synthesizing AAAA
-                RR when real AAAA RR exists . . . . . . . . . . . . . 27
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 3]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-1.  Introduction
-
-   This document specifies DNS64, a mechanism that is part of the
-   toolbox for IPv6-IPv4 transition and co-existence.  DNS64, used
-   together with an IPv6/IPv4 translator such as NAT64
-   [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate
-   communications by name to an IPv4-only server.
-
-   DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
-   from A RRs.  A synthetic AAAA RR created by the DNS64 from an
-   original A RR contains the same FQDN of the original A RR but it
-   contains an IPv6 address instead of an IPv4 address.  The IPv6
-   address is an IPv6 representation of the IPv4 address contained in
-   the original A RR.  The IPv6 representation of the IPv4 address is
-   algorithmically generated from the IPv4 address returned in the A RR
-   and a set of parameters configured in the DNS64 (typically, an IPv6
-   prefix used by IPv6 representations of IPv4 addresses and optionally
-   other parameters).
-
-   Together with a IPv6/IPv4 translator, these two mechanisms allow an
-   IPv6-only client to initiate communications to an IPv4-only server
-   using the FQDN of the server.
-
-   These mechanisms are expected to play a critical role in the IPv4-
-   IPv6 transition and co-existence.  Due to IPv4 address depletion, it
-   is likely that in the future, many IPv6-only clients will want to
-   connect to IPv4-only servers.  In the typical case, the approach only
-   requires the deployment of IPv6/IPv4 translators that connect an
-   IPv6-only network to an IPv4-only network, along with the deployment
-   of one or more DNS64-enabled name servers.  However, some advanced
-   features require performing the DNS64 function directly by the end-
-   hosts themselves.
-
-
-2.  Overview
-
-   This section provides a non-normative introduction to the DNS64
-   mechanism.
-
-   We assume that we have an IPv6/IPv4 translator box connecting an IPv4
-   network and an IPv6 network.  The IPv6/IPv4 translator device
-   provides translation services between the two networks enabling
-   communication between IPv4-only hosts and IPv6-only hosts.  (NOTE: By
-   IPv6-only hosts we mean hosts running IPv6-only applications, hosts
-   that can only use IPv6, as well as the cases where only IPv6
-   connectivity is available to the client.  By IPv4-only servers we
-   mean servers running IPv4-only applications, servers that can only
-   use IPv4, as well as the cases where only IPv4 connectivity is
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 4]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   available to the server).  The IPv6/IPv4 translator used in
-   conjunction with DNS64 must allow communications initiated from the
-   IPv6-only host to the IPv4-only host.
-
-   To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
-   learn the address of the responder, DNS64 is used to synthesize a
-   AAAA record from an A record containing a real IPv4 address of the
-   responder, whenever the DNS64 service cannot retrieve a AAAA record
-   for the requested host name.  The DNS64 device appears as a regular
-   recursive resolver for the IPv6 initiator.  The DNS64 box receives an
-   AAAA DNS query generated by the IPv6 initiator.  It first attempts a
-   recursive resolution for the requested AAAA records.  If there is no
-   AAAA record available for the target node (which is the normal case
-   when the target node is an IPv4-only node), DNS64 performs a query
-   for A records.  If any A records are discovered, DNS64 creates a
-   synthetic AAAA RR from the information retrieved in each A RR.
-
-   The FQDN of a synthetic AAAA RR is the same as that of the original A
-   RR, but an IPv6 representation of the IPv4 address contained in the
-   original A RR is included in the AAAA RR.  The IPv6 representation of
-   the IPv4 address is algorithmically generated from the IPv4 address
-   and additional parameters configured in the DNS64.  Among those
-   parameters configured in the DNS64, there is at least one IPv6
-   prefix, called Pref64::/n.  The IPv6 address representing IPv4
-   addresses included in the AAAA RR synthesized by the DNS64 function
-   contain Pref64::/n and they also embed the original IPv4 address.
-
-   The same algorithm and the same Pref64::/n prefix or prefixes must be
-   configured both in the DNS64 device and the IPv6/IPv4 translator, so
-   that both can algorithmically generate the same IPv6 representation
-   for a given IPv4 address.  In addition, it is required that IPv6
-   packets addressed to an IPv6 destination that contains the Pref64::/n
-   be delivered to the IPv6/IPv4 translator, so they can be translated
-   into IPv4 packets.
-
-   Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is
-   passed back to the IPv6 initiator, which will initiate an IPv6
-   communication with the IPv6 address associated with the IPv4
-   receiver.  The packet will be routed to the IPv6/IPv4 translator
-   which will forward it to the IPv4 network .
-
-   In general, the only shared state between the DNS64 and the IPv6/IPv4
-   translator is the Pref64::/n and an optional set of static
-   parameters.  The Pref64::/n and the set of static parameters must be
-   configured to be the same on both; there is no communication between
-   the DNS64 device and IPv6/IPv4 translator functions.  The mechanism
-   to be used for configuring the parameters of the DNS64 is beyond the
-   scope of this memo.
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 5]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   The DNS64 function can be performed in two places.
-
-      One option is to locate the DNS64 function in recursive name
-      servers serving end hosts.  In this case, when an IPv6-only host
-      queries the name server for AAAA RRs for an IPv4-only host, the
-      name server can perform the synthesis of AAAA RRs and pass them
-      back to the IPv6 only initiator.  The main advantage of this mode
-      is that current IPv6 nodes can use this mechanism without
-      requiring any modification.  This mode is called "DNS64 in DNS
-      server mode".
-
-      The other option is to place the DNS64 function in the end hosts
-      themselves, coupled to the local stub resolver.  In this case, the
-      stub resolver will try to obtain (real) AAAA RRs and in case they
-      are not available, the DNS64 function will synthesize AAAA RRs for
-      internal usage.  This mode is compatible with some advanced
-      functions like DNSSEC validation in the end host.  The main
-      drawback of this mode is its deployability, since it requires
-      changes in the end hosts.  This mode is called "DNS64 in stub-
-      resolver mode"".
-
-
-3.  Background to DNS64 - DNSSEC interaction
-
-   DNSSEC presents a special challenge for DNS64, because DNSSEC is
-   designed to detect changes to DNS answers, and DNS64 may alter
-   answers coming from an authoritative server.
-
-   A recursive resolver can be security-aware or security-oblivious.
-   Moreover, a security-aware recursive name server can be validating or
-   non-validating, according to operator policy.  In the cases below,
-   the recursive server is also performing DNS64, and has a local policy
-   to validate.  We call this general case vDNS64, but in all the cases
-   below the DNS64 functionality should be assumed needed.
-
-   DNSSEC includes some signaling bits that offer some indicators of
-   what the query originator understands.
-
-   If a query arrives at a vDNS64 device with the DO bit set, the query
-   originator is signaling that it understands DNSSEC.  The DO bit does
-   not indicate that the query originator will validate the response.
-   It only means that the query originator can understand responses
-   containing DNSSEC data.  Conversely, if the DO bit is clear, that is
-   evidence that the querying agent is not aware of DNSSEC.
-
-   If a query arrives at a vDNS64 device with the CD bit set, it is an
-   indication that the querying agent wants all the validation data so
-   it can do checking itself.  By local policy, vDNS64 could still
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 6]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   validate, but it must return all data to the querying agent anyway.
-
-   Here are the possible cases:
-
-   1.  A security-oblivious DNS64 node receives a query with the DO bit
-       clear.  In this case, DNSSEC is not a concern, because the
-       querying agent does not understand DNSSEC responses.
-
-   2.  A security-oblivious DNS64 node receives a query with the DO bit
-       set, and the CD bit clear.  This is just like the case of a non-
-       DNS64 case: the server doesn't support it, so the querying agent
-       is out of luck.
-
-   3.  A security-aware and non-validating DNS64 node receives a query
-       with the DO bit set and the CD bit clear.  Such a resolver is not
-       validating responses, likely due to local policy (see [RFC4035],
-       section 4.2).  For that reason, this case amounts to the same as
-       the previous case, and no validation happens.
-
-   4.  A security-aware and non-validating DNS64 node receives a query
-       with the DO bit set and the CD bit set.  In this case, the
-       resolver is supposed to pass on all the data it gets to the query
-       initiator (see section 3.2.2 of [RFC4035]).  This case will be
-       problematic with DNS64.  If the DNS64 server modifies the record,
-       the client will get the data back and try to validate it, and the
-       data will be invalid as far as the client is concerned.
-
-   5.  A security-aware and validating DNS64 node receives a query with
-       the DO bit clear and CD clear.  In this case, the resolver
-       validates the data.  If it fails, it returns RCODE 2 (SERVFAIL);
-       otherwise, it returns the answer.  This is the ideal case for
-       vDNS64.  The resolver validates the data, and then synthesizes
-       the new record and passes that to the client.  The client, which
-       is presumably not validating (else it would have set DO and CD),
-       cannot tell that DNS64 is involved.
-
-   6.  A security-aware and validating DNS64 node receives a query with
-       the DO bit set and CD clear.  In principle, this ought to work
-       like the previous case, except that the resolver should also set
-       the AD bit on the response.
-
-   7.  A security-aware and validating DNS64 node receives a query with
-       the DO bit set and CD set.  This is effectively the same as the
-       case where a security-aware and non-validating recursive resolver
-       receives a similar query, and the same thing will happen: the
-       downstream validator will mark the data as invalid if DNS64 has
-       performed synthesis.
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 7]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-4.  Terminology
-
-   This section provides definitions for the special terms used in the
-   document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-   Authoritative server:  A DNS server that can answer authoritatively a
-      given DNS question.
-
-   DNS64:  A logical function that synthesizes DNS resource records (e.g
-      AAAA records containing IPv6 addresses) from DNS resource records
-      actually contained in the global DNS (e.g.  A records containing
-      IPv4 addresses).
-
-   DNS64 recursor:  A recursive resolver that provides the DNS64
-      functionality as part of its operation.
-
-   Recursive resolver:  A DNS server that accepts requests from one
-      resolver, and asks another resolver for the answer on behalf of
-      the first resolver.  In the context of this document, "the
-      recursive resolver" means a recursive resolver immediately next in
-      the DNS resolution chain from an end point.  The end point usually
-      has only a stub resolver available.[[anchor5: I can't actually
-      remember why we needed the sentences following "In the context of
-      this document. . ."  Unless someone has a reason, I'll take it
-      out. --ajs@shinkuro.com]]
-
-   Synthetic RR:  A DNS resource record (RR) that is not contained in
-      any zone data file, but has been synthesized from other RRs.  An
-      example is a synthetic AAAA record created from an A record.
-
-   Stub resolver:  A resolver with minimum functionality, typically for
-      use in end points that depend on a recursive resolver.  Most end
-      points on the Internet as of this writing use stub
-      resolvers.[[anchor6: Do we need this in the document?  I don't
-      think so. 1034 defines this term. --ajs@shinkuro.com]]
-
-   IPv6/IPv4 translator:  A device that translates IPv6 packets to IPv4
-      packets and vice-versa.  It is only required that the
-      communication initiated from the IPv6 side be supported.
-
-   For a detailed understanding of this document, the reader should also
-   be familiar with DNS terminology from [RFC1034],[RFC1035] and current
-   NAT terminology from [RFC4787].  Some parts of this document assume
-   familiarity with the terminology of the DNS security extensions
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 8]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   outlined in [RFC4035].
-
-
-5.  DNS64 Normative Specification
-
-   A DNS64 is a logical function that synthesizes AAAA records from A
-   records.  The DNS64 function may be implemented in a stub resolver,
-   in a recursive resolver, or in an authoritative name server.
-
-   The implementation SHOULD support mapping of IPv4 address ranges to
-   separate IPv6 prefixes for AAAA record synthesis.  This allows
-   handling of special use IPv4 addresses [I-D.iana-rfc3330bis].
-   Multicast address handling is further specified in
-   [I-D.venaas-behave-mcast46].
-
-5.1.  Resolving AAAA queries and the answer section
-
-   When the DNS64 receives a query for RRs of type AAAA and class IN, it
-   first attempts to retrieve non-synthetic RRs of this type and class,
-   either by performing a query or, in the case of an authoritative
-   server, by examining its own results.
-
-5.1.1.  The answer when there is AAAA data available
-
-   If the query results in one or more AAAA records in the answer
-   section, the result is returned to the requesting client as per
-   normal DNS semantics (except in the case where the AAAA falls in the
-   ::ffff/96 network; see below for treatment of that network).  In this
-   case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response
-   (see Appendix B for an analysis of the motivations for and the
-   implications of not complying with this recommendation).  By default
-   DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
-   exist.
-
-5.1.2.  The answer when there is an error
-
-   If the query results in a response with an error code other than 0,
-   the result is handled according to normal DNS operation -- that is,
-   either the resolver tries again using a different server from the
-   authoritative NS RRSet, or it returns the error to the client.  This
-   stage is still prior to any synthesis having happened, so a response
-   to be returned to the client does not need any special assembly than
-   would usually happen in DNS operation.
-
-5.1.3.  Data for the answer when performing synthesis
-
-   If the query results in no error but an empty answer section in the
-   response, the DNS64 resolver attempts to retrieve A records for the
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                 [Page 9]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   name in question.  If this new A RR query results in an empty answer
-   or in an error, then the empty result or error is used as the basis
-   for the answer returned to the querying client.  (Transient errors
-   may result in retrying the query, depening on the operation of the
-   resolver; this is just as in Section 5.1.2.)  If instead the query
-   results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on
-   the A RRs according to the procedure outlined in Section 5.1.4.  The
-   DNS64 resolver then returns the synthesized AAAA records in the
-   answer section to the client, removing the A records that form the
-   basis of the synthesis.
-
-   As an exception to the general rule about always returning the AAAA
-   records if they are returned in the answer, AAAA records with
-   addresses in the ::ffff/96 network are treated just like the case
-   where there is neither an error nor an empty answer section.  This is
-   because a real IPv6-only node will not be any more able to reach the
-   addresses in ::ffff/96 than it is able to reach an IPv4 address
-   without assistance.  An implementation MAY use the address in
-   ::ffff/96 as the basis of synthesis without querying for an A record,
-   by using the last 32 bits of the address provided in the AAAA record.
-   [[anchor10: I changed this to say "neither. . .nor" because the
-   previous version suggested that it would return the error-or-empty-
-   answer to the querying client, and that can't be right.  Correct?
-   --ajs@shinkuro.com]]
-
-5.1.4.  Performing the synthesis
-
-   A synthetic AAAA record is created from an A record as follows:
-
-   o  The NAME field is set to the NAME field from the A record
-
-   o  The TYPE field is set to 28 (AAAA)
-
-   o  The CLASS field is set to 1 (IN)
-
-   o  The TTL field is set to the minimum of the TTL of the original A
-      RR and the SOA RR for the queried domain.  (Note that in order to
-      obtain the TTL of the SOA RR the DNS64 does not need to perform a
-      new query, but it can remember the TTL from the SOA RR in the
-      negative response to the AAAA query).
-
-   o  The RDLENGTH field is set to 16
-
-   o  The RDATA field is set to the IPv6 representation of the IPv4
-      address from the RDATA field of the A record.  The DNS64 SHOULD
-      check each A RR against IPv4 address ranges and select the
-      corresponding IPv6 prefix to use in synthesizing the AAAA RR.  See
-      Section 5.2 for discussion of the algorithms to be used in
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 10]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-      effecting the transformation.
-
-5.1.5.  Querying in parallel
-
-   DNS64 MAY perform the query for the AAAA RR and for the A RR in
-   parallel, in order to minimize the delay.  However, this would result
-   in performing unnecessary A RR queries in the case no AAAA RR
-   synthesis is required.  A possible trade-off would be to perform them
-   sequentially but with a very short interval between them, so if we
-   obtain a fast reply, we avoid doing the additional query.  (Note that
-   this discussion is relevant only if the DNS64 function needs to
-   perform external queries to fetch the RR.  If the needed RR
-   information is available locally, as in the case of an authoritative
-   server, the issue is no longer relevant.)
-
-5.2.  Generation of the IPv6 representations of IPv4 addresses
-
-   DNS64 supports multiple algorithms for the generation of the IPv6
-   representation of an IPv4 address.  The constraints imposed on the
-   generation algorithms are the following:
-
-      The same algorithm to create an IPv6 address from an IPv4 address
-      MUST be used by both the DNS64 to create the IPv6 address to be
-      returned in the synthetic AAAA RR from the IPv4 address contained
-      in original A RR, and by the IPv6/IPv4 translator to create the
-      IPv6 address to be included in the destination address field of
-      the outgoing IPv6 packets from the IPv4 address included in the
-      destination address field of the incoming IPv4 packet.
-
-      The algorithm MUST be reversible, i.e. it MUST be possible to
-      extract the original IPv4 address from the IPv6 representation.
-
-      The input for the algorithm MUST be limited to the IPv4 address,
-      the IPv6 prefix (denoted Pref64::/n) used in the IPv6
-      representations and optionally a set of stable parameters that are
-      configured in the DNS64 (such as fixed string to be used as a
-      suffix).
-
-         If we note n the length of the prefix Pref64::/n, then n MUST
-         the less or equal than 96.  If a Pref64::/n is configured
-         through any means in the DNS64 (such as manually configured, or
-         other automatic mean not specified in this document), the
-         default algorithm MUST use this prefix.  If no prefix is
-         available, the algorithm MUST use the Well-Known prefix TBD1
-         defined in [I-D.thaler-behave-translator-addressing]
-
-      [[anchor12: Note in document: TBD1 in the passage above is to be
-      substituted by whatever prefix is assigned by IANA to be the well-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 11]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-      known prefix.]]
-
-   DNS64 MUST support the following algorithms for generating IPv6
-   representations of IPv4 addresses defined in
-   [I-D.thaler-behave-translator-addressing]:
-
-      Zero-Pad And Embed, defined in section 3.2.3 of
-      [I-D.thaler-behave-translator-addressing]
-
-      Compensation-Pad And Embed, defined in section of 3.2.4 of
-      [I-D.thaler-behave-translator-addressing]
-
-      Embed And Zero-Pad, defined in section of 3.2.5 of
-      [I-D.thaler-behave-translator-addressing]
-
-      Preconfigured Mapping Table, defined in section of 3.2.6 of
-      [I-D.thaler-behave-translator-addressing]
-
-   The default algorithm used by DNS64 must be Embed and Zero-Pad.
-   While the normative description of the algorithms is provided in
-   [I-D.thaler-behave-translator-addressing], an sample description of
-   the algorithm and its application to different scenarios is provided
-   in Appendix A for illustration purposes.
-
-5.3.  Handling other RRs
-
-5.3.1.  PTR queries
-
-   If a DNS64 nameserver receives a PTR query for a record in the
-   IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME,
-   reverse the address portion of the QNAME according to the encoding
-   scheme outlined in section 2.5 of [RFC3596] , and examine the
-   resulting address to see whether its prefix matches the locally-
-   configured Pref64::/n.  There are two alternatives for a DNS64
-   nameserver to respond to such PTR queries.  A DNS64 node MUST provide
-   one of these, and SHOULD NOT provide both at the same time unless
-   different IP6.ARPA zones require answers of different sorts.
-
-   The first option is for the DNS64 nameserver to respond
-   authoritatively for its prefixes.  If the address prefix matches any
-   Pref64::/n used in the site, either a LIR prefix or a well-known
-   prefix used for NAT64 as defined in
-   [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY
-   answer the query using locally-appropriate RDATA.  The DNS64 server
-   MAY use the same RDATA for all answers.  Note that the requirement is
-   to match any Pref64::/n used at the site, and not merely the locally-
-   configured Pref64::/n.  This is because end clients could ask for a
-   PTR record matching an address received through a different (site-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 12]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   provided) DNS64, and if this strategy is in effect, those queries
-   should never be sent to the global DNS.  The advantage of this
-   strategy is that it makes plain to the querying client that the
-   prefix is one operated by the DNS64 site, and that the answers the
-   client is getting are generated by the DNS64.  The disadvantage is
-   that any useful reverse-tree information that might be in the global
-   DNS is unavailable to the clients querying the DNS64.
-
-   The second option is for the DNS64 nameserver to synthesize a CNAME
-   mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
-   name.  The rest of the response would be the normal DNS processing.
-   The CNAME can be signed on the fly if need be.  The advantage of this
-   approach is that any useful information in the reverse tree is
-   available to the querying client.  The disadvantage is that it adds
-   additional load to the DNS64 (because CNAMEs have to be synthesized
-   for each PTR query that matches the Pref64::/n), and that it may
-   require signing on the fly. [[anchor15: what are we supposed to do
-   here when the in-addr.arpa zone is unmaintained, as it may be.  If
-   there is no data at the target name, then we'll get a CNAME with a
-   map to an empty namespace, I think?  Isn't that bad?
-   --ajs@shinkuro.com]]
-
-   If the address prefix does not match any of the Pref64::/n, then the
-   DNS64 server MUST process the query as though it were any other query
-   -- i.e. a recursive nameserver MUST attempt to resolve the query as
-   though it were any other (non-A/AAAA) query, and an authoritative
-   server MUST respond authoritatively or with a referral, as
-   appropriate.
-
-5.3.2.  Handling the additional section
-
-   DNS64 synthesis MUST NOT be performed on any records in the
-   additional section of synthesized answers.  The DNS64 MUST pass the
-   additional section unchanged.
-
-   [[anchor16: We had some discussion, as an alternative to the above,
-   of allowing the DNS64 to truncate the additional section completely,
-   on the grounds that the additional section could break mixed-mode
-   iterative/forwarding resolvers that happen to end up behind DNS64.
-   Nobody else seemed to like that plan, so I haven't included it.
-   --ajs@shinkuro.com]]
-
-5.3.3.  Other records
-
-   If the DNS64 is in recursive resolver mode, then it SHOULD also serve
-   the zones specified in [I-D.ietf-dnsop-default-local-zones], rather
-   than forwarding those queries elsewhere to be handled.
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 13]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   All other RRs MUST be returned unchanged.
-
-5.4.  Assembling a synthesized response to a AAAA query
-
-   The DNS64 uses different pieces of data to build the response
-   returned to the querying client.
-
-   The query that is used as the basis for synthesis results either in
-   an error, an answer that can be used as a basis for synthesis, or an
-   empty (authoritative) answer.  If there is an empty answer, then the
-   DNS64 responds to the original querying client with the answer the
-   DNS64 received to the original AAAA query.  Otherwise, the response
-   is assembled as follows.
-
-   The header fields are set according to the usual rules for recursive
-   or authoritative servers, depending on the role that the DNS64 is
-   serving.  The question section is copied from the original AAAA
-   query.  The answer section is populated according to the rules in
-   Section 5.1.4.  The authority section is copied from the response to
-   the A query that the DNS64 performed.  The additional section is
-   populated according to the rules in Section 5.3.2.
-
-   [[anchor18: The cross-reference to how to do the additional section
-   can be removed, and replaced by "copied from the response to the A
-   query that the DNS64 performed" if we don't want to allow the DNS64
-   to truncate the additional section.  See the note above.  If I hear
-   no more feedback on this topic, then I'll make this change in the
-   next version. --ajs@shinkuro.com]]
-
-5.5.  DNSSEC processing: DNS64 in recursive server mode
-
-   We consider the case where the recursive server that is performing
-   DNS64 also has a local policy to validate the answers according to
-   the procedures outlined in [RFC4035] Section 5.  We call this general
-   case vDNS64.
-
-   The vDNS64 uses the presence of the DO and CD bits to make some
-   decisions about what the query originator needs, and can react
-   accordingly:
-
-   1.  If CD is not set and DO is not set, vDNS64 SHOULD perform
-       validation and do synthesis as needed.
-
-   2.  If CD is not set and DO is set, then vDNS64 SHOULD perform
-       validation.  Whenever vDNS64 performs validation, it MUST
-       validate the negative answer for AAAA queries before proceeding
-       to query for A records for the same name, in order to be sure
-       that there is not a legitimate AAAA record on the Internet.
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 14]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-       Failing to observe this step would allow an attacker to use DNS64
-       as a mechanism to circumvent DNSSEC.  If the negative response
-       validates, and the response to the A query validates, then the
-       vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
-       answer to the client.  This is acceptable, because [RFC4035],
-       section 3.2.3 says that the AD bit is set by the name server side
-       of a security-aware recursive name server if and only if it
-       considers all the RRSets in the Answer and Authority sections to
-       be authentic.  In this case, the name server has reason to
-       believe the RRSets are all authentic, so it SHOULD set the AD
-       bit.  If the data does not validate, the vDNS64 MUST respond with
-       RCODE=2 (server failure).
-       A security-aware end point might take the presence of the AD bit
-       as an indication that the data is valid, and may pass the DNS
-       (and DNSSEC) data to an application.  If the application attempts
-       to validate the synthesized data, of course, the validation will
-       fail.  One could argue therefore that this approach is not
-       desirable.  But security aware stub resolvers MUST NOT place any
-       reliance on data received from resolvers and validated on their
-       behalf without certain criteria established by [RFC4035], section
-       4.9.3.  An application that wants to perform validation on its
-       own should use the CD bit.
-
-   3.  If the CD bit is set and DO is set, then vDNS64 MAY perform
-       validation, but MUST NOT perform synthesis.  It MUST hand the
-       data back to the query initiator, just like a regular recursive
-       resolver, and depend on the client to do the validation and the
-       synthesis itself.
-       The disadvantage to this approach is that an end point that is
-       translation-oblivious but security-aware and validating will not
-       be able to use the DNS64 functionality.  In this case, the end
-       point will not have the desired benefit of NAT64.  In effect,
-       this strategy means that any end point that wishes to do
-       validation in a NAT64 context must be upgraded to be translation-
-       aware as well.
-
-5.6.  DNS64 and multihoming
-
-   Synthetic AAAA records may be constructed on the basis of the network
-   context in which they were constructed.  Therefore, a synthetic AAAA
-   received from one interface MUST NOT be used to resolve hosts via
-   another network interface. [[anchor21: This seems to be the result of
-   the discussion on-list starting with message id 18034D4D7FE9AE48BF19A
-   B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty
-   strange when stated baldly.  In particular, how is the multi-homed
-   host supposed to know that a given AAAA is synthetic?
-   --ajs@shinkuro.com]]
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 15]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-6.  Deployment notes
-
-   While DNS64 is intended to be part of a strategy for aiding IPv6
-   deployment in an internetworking environment with some IPv4-only and
-   IPv6-only networks, it is important to realise that it is
-   incompatible with some things that may be deployed in an IPv4-only or
-   dual-stack context.
-
-6.1.  DNS resolvers and DNS64
-
-   Full-service resolvers that are unaware of the DNS64 function can be
-   (mis)configured to act as mixed-mode iterative and forwarding
-   resolvers.  In a native-IPv4 context, this sort of configuration may
-   appear to work.  It is impossible to make it work properly without it
-   being aware of the DNS64 function, because it will likely at some
-   point obtain IPv4-only glue records and attempt to use them for
-   resolution.  The result that is returned will contain only A records,
-   and without the ability to perform the DNS64 function the resolver
-   will simply be unable to answer the necessary AAAA queries.
-
-6.2.  DNSSEC validators and DNS64
-
-   Existing DNSSEC validators (i.e. that are unaware of DNS64) will
-   reject all the data that comes from the DNS64 as having been tampered
-   with.  If it is necessary to have validation behind the DNS64, then
-   the validator must know how to perform the DNS64 function itself.
-   Alternatively, the validating host may establish a trusted connection
-   with the DNS64, and allow the DNS64 to do all validation on its
-   behalf.
-
-
-7.  Security Considerations
-
-   See the discussion on the usage of DNSSEC and DNS64 described in the
-   document.
-
-
-8.  Contributors
-
-      Dave Thaler
-
-      Microsoft
-
-      dthaler@windows.microsoft.com
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 16]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-9.  Acknowledgements
-
-   This draft contains the result of discussions involving many people,
-   including the participants of the IETF BEHAVE Working Group.  The
-   following IETF participants made specific contributions to parts of
-   the text, and their help is gratefully acknowledged: Mark Andrews,
-   Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet,
-   Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed
-   Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs
-   Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki
-   Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund,
-   Florian Weimer, Dan Wing, Xu Xiaohu.
-
-   Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
-   Trilogy, a research project supported by the European Commission
-   under its Seventh Framework Program.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
-              RFC 2672, August 1999.
-
-   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
-              (SIIT)", RFC 2765, February 2000.
-
-   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
-              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
-              RFC 4787, January 2007.
-
-   [I-D.ietf-behave-tcp]
-              Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
-              Srisuresh, "NAT Behavioral Requirements for TCP",
-              draft-ietf-behave-tcp-08 (work in progress),
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 17]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-              September 2008.
-
-   [I-D.ietf-behave-nat-icmp]
-              Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
-              Behavioral Requirements for ICMP protocol",
-              draft-ietf-behave-nat-icmp-12 (work in progress),
-              January 2009.
-
-   [I-D.thaler-behave-translator-addressing]
-              Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators",
-              draft-thaler-behave-translator-addressing-00 (work in
-              progress), July 2009.
-
-10.2.  Informative References
-
-   [I-D.bagnulo-behave-nat64]
-              Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
-              Address and Protocol Translation from IPv6 Clients to IPv4
-              Servers", draft-bagnulo-behave-nat64-03 (work in
-              progress), March 2009.
-
-   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
-              Translation - Protocol Translation (NAT-PT)", RFC 2766,
-              February 2000.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC1858]  Ziemba, G., Reed, D., and P. Traina, "Security
-              Considerations for IP Fragment Filtering", RFC 1858,
-              October 1995.
-
-   [RFC3128]  Miller, I., "Protection Against a Variant of the Tiny
-              Fragment Attack (RFC 1858)", RFC 3128, June 2001.
-
-   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
-              Address Translator (Traditional NAT)", RFC 3022,
-              January 2001.
-
-   [RFC3484]  Draves, R., "Default Address Selection for Internet
-              Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IP Version 6", RFC 3596,
-              October 2003.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 18]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
-              Address Translator - Protocol Translator (NAT-PT) to
-              Historic Status", RFC 4966, July 2007.
-
-   [I-D.iana-rfc3330bis]
-              Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
-              draft-iana-rfc3330bis-06 (work in progress),
-              February 2009.
-
-   [I-D.ietf-mmusic-ice]
-              Rosenberg, J., "Interactive Connectivity Establishment
-              (ICE): A Protocol for Network Address  Translator (NAT)
-              Traversal for Offer/Answer Protocols",
-              draft-ietf-mmusic-ice-19 (work in progress), October 2007.
-
-   [I-D.ietf-6man-addr-select-sol]
-              Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
-              "Solution approaches for address-selection problems",
-              draft-ietf-6man-addr-select-sol-01 (work in progress),
-              June 2008.
-
-   [RFC3498]  Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of
-              Managed Objects for Synchronous Optical Network (SONET)
-              Linear Automatic Protection Switching (APS)
-              Architectures", RFC 3498, March 2003.
-
-   [I-D.wing-behave-learn-prefix]
-              Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
-              of an IPv6/IPv4 Translator",
-              draft-wing-behave-learn-prefix-02 (work in progress),
-              May 2009.
-
-   [I-D.miyata-behave-prefix64]
-              Miyata, H. and M. Bagnulo, "PREFIX64 Comparison",
-              draft-miyata-behave-prefix64-02 (work in progress),
-              March 2009.
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 19]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   [I-D.venaas-behave-mcast46]
-              Venaas, S., "An IPv4 - IPv6 multicast translator",
-              draft-venaas-behave-mcast46-00 (work in progress),
-              December 2008.
-
-   [I-D.ietf-dnsop-default-local-zones]
-              Andrews, M., "Locally-served DNS Zones",
-              draft-ietf-dnsop-default-local-zones-08 (work in
-              progress), February 2009.
-
-
-Appendix A.  Deployment scenarios and examples
-
-   In this section, we first provide a description of the default
-   address transformation algorithm and then we walk through some sample
-   scenarios that are expected to be common deployment cases.  It should
-   be noted that is provided for illustrative purposes and this section
-   is not normative.  The normative definition of DNS64 is provided in
-   Section 5 and the normative definition of the address transformation
-   algorithm is provided in [I-D.thaler-behave-translator-addressing].
-
-   There are two main different setups where DNS64 is expected to be
-   used (other setups are possible as well, but these two are the main
-   ones identified at the time of this writing).
-
-      One possible setup that is expected to be common is the case of an
-      end site or an ISP that is providing IPv6-only connectivity or
-      connectivity to IPv6-only hosts that wants to allow the
-      communication from these IPv6-only connected hosts to the IPv4
-      Internet.  This case is called An-IPv6-network-to-IPv4-Internet.
-      In this case, the IPv6/IPv4 Translator is used to connect the end
-      site or the ISP to the IPv4 Internet and the DNS64 function is
-      provided by the end site or the ISP.
-
-      The other possible setup that is expected is an IPv4 site that
-      wants that its IPv4 servers to be reachable from the IPv6
-      Internet.  This case is called IPv6-Internet-to-an-IPv4-network.
-      It should be noted that the IPv4 addresses used in the IPv4 site
-      can be either public or private.  In this case, the IPv6/IPv4
-      Translator is used to connect the IPv4 end site to the IPv6
-      Internet and the DNS64 function is provided by the end site
-      itself.
-
-   In this section we illustrate how the DNS64 behaves in the different
-   scenarios that are expected to be common.  We consider then 3
-   possible scenarios, namely:
-
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 20]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   1.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
-       mode
-
-   2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
-       resolver mode
-
-   3.  IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
-       mode
-
-   The notation used is the following: upper case letters are IPv4
-   addresses; upper case letters with a prime(') are IPv6 addresses;
-   lower case letters are ports; prefixes are indicated by "P::X", which
-   is an IPv6 address built from an IPv4 address X by adding the prefix
-   P, mappings are indicated as "(X,x) <--> (Y',y)".
-
-A.1.   Embed and Zero-Pad algorithm description
-
-   In this section we describe the default algorithm for the generation
-   of IPv6 address from IPv4 address to be implemented in the DNS64.
-
-   The only parameter required by the default algorithm is an IPv6
-   prefix.  This prefix is used to map IPv4 addresses into IPv6
-   addresses, and is denoted Pref64.  If we note n the length of the
-   prefix Pref64, then n must the less or equal than 96.  If an Pref64
-   is configured through any means in the DNS64 (such as manually
-   configured, or other automatic mean not specified in this document),
-   the default algorithm must use this prefix.  If no prefix is
-   available the algorithm must use the Well-Know prefix (include here
-   the prefix to be assigned by IANA) defined in
-   [I-D.thaler-behave-translator-addressing]
-
-   The input for the algorithm are:
-
-      The IPv4 address: X
-
-      The IPv6 prefix: Pref64::/n
-
-   The IPv6 address is generated by concatenating the prefix Pref64::/n,
-   the IPv4 address X and optionally (in case n is strictly smaller than
-   96) an all-zero suffix.  So, the resulting IPv6 address would be
-   Pref64:X::
-
-   Reverse algorithm
-
-   We next describe the reverse algorithm of the algorithm described in
-   the previous section.  This algorithm allows to generate and IPv4
-   address from an IPv6 address.  This reverse algorithm is NOT
-   implemented by the DNS64 but it is implemented in the IPv6/IPv4
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 21]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   translator that is serving the same domain the DNS64.
-
-   The only parameter required by the default algorithm is an IPv6
-   prefix.  This prefix is the one originally used to map IPv4 addresses
-   into IPv6 addresses, and is denoted Pref64.
-
-   The input for the algorithm are:
-
-      The IPv6 address: X'
-
-      The IPv6 prefix: Pref64::/n
-
-   First, the algorithm checks that the fist n bits of the IPv6 address
-   X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n =
-   X'/n.
-
-      If this is not the case, the algorithm ends and no IPv4 address is
-      generated.
-
-      If the verification is successful, then the bits between the n+1
-      and the n+32 of the IPv6 address X' are extracted to form the IPv4
-      address.
-
-A.2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
-      mode
-
-   In this example, we consider an IPv6 node located in an IPv6-only
-   site that initiates a communication to an IPv4 node located in the
-   IPv4 Internet.
-
-   The scenario for this case is depicted in the following figure:
-
-
-      +---------------------------------------+         +-----------+
-      |IPv6 site       +-------------+        |IP Addr: |           |
-      |  +----+        | Name server |   +-------+ T    |   IPv4    |
-      |  | H1 |        | with DNS64  |   |64Trans|------| Internet  |
-      |  +----+        +-------------+   +-------+      +-----------+
-      |    |IP addr: Y'     |              |  |            |IP addr: X
-      |    ---------------------------------  |          +----+
-      +---------------------------------------+          | H2 |
-                                                         +----+
-
-   The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
-   IPv4 node H2 with IPv4 address X.
-
-   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
-   Internet.  This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 22]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   an IPv4 address T assigned to its IPv4 interface.
-
-   The other element involved is the local name server.  The name server
-   is a dual-stack node, so that H1 can contact it via IPv6, while it
-   can contact IPv4-only name servers via IPv4.
-
-   The local name server needs to know the prefix assigned to the local
-   IPv6/IPv4 Translator (Pref64::/n).  For the purpose of this example,
-   we assume it learns this through manual configuration.
-
-   For this example, assume the typical DNS situation where IPv6 hosts
-   have only stub resolvers, and always query a name server that
-   performs recursive lookups (henceforth called "the recursive
-   nameserver").
-
-   The steps by which H1 establishes communication with H2 are:
-
-   1.  H1 does a DNS lookup for FQDN(H2).  H1 does this by sending a DNS
-       query for an AAAA record for H2 to the recursive name server.
-       The recursive name server implements DNS64 functionality.
-
-   2.  The recursive name server resolves the query, and discovers that
-       there are no AAAA records for H2.
-
-   3.  The recursive name server queries for an A record for H2 and gets
-       back an A record containing the IPv4 address X. The name server
-       then synthesizes an AAAA record.  The IPv6 address in the AAAA
-       record contains the prefix assigned to the IPv6/IPv4 Translator
-       in the upper n bits then the IPv4 address X and then an all-zero
-       padding i.e. the resulting IPv6 address is Pref64:X::
-
-   4.  H1 receives the synthetic AAAA record and sends a packet towards
-       H2.  The packet is sent from a source transport address of (Y',y)
-       to a destination transport address of (Pref64:X::,x), where y and
-       x are ports chosen by H2.
-
-   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
-       Translator and the subsequent communication flows by means of the
-       IPv6/IPv4 Translator mechanisms.
-
-A.3.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver
-      mode
-
-   The scenario for this case is depicted in the following figure:
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 23]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-      +---------------------------------------+         +-----------+
-      |IPv6 site             +-------+        |IP addr: |           |
-      |  +---------------+   | Name  |   +-------+  T   |   IPv4    |
-      |  | H1 with DNS64 |   | Server|   |64Trans|------| Internet  |
-      |  +---------------+   +-------+   +-------+      +-----------+
-      |        |IP addr: Y'      |         |  |            |IP addr: X
-      |    ---------------------------------  |          +----+
-      +---------------------------------------+          | H2 |
-                                                         +----+
-
-   The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
-   IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64
-   function.
-
-   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
-   Internet.  This IPv6/IPv4 Translator has a prefix (called Pref64::/n)
-   and an IPv4 address T assigned to its IPv4 interface.
-
-   H1 needs to know the prefix assigned to the local IPv6/IPv4
-   Translator (Pref64::/n).  For the purpose of this example, we assume
-   it learns this through manual configuration.
-
-   Also shown is a name server.  For the purpose of this example, we
-   assume that the name server is a dual-stack node, so that H1 can
-   contact it via IPv6, while it can contact IPv4-only name servers via
-   IPv4.
-
-   For this example, assume the typical situation where IPv6 hosts have
-   only stub resolvers and always query a name server that provides
-   recursive lookups (henceforth called "the recursive name server").
-   The recursive name server does not perform the DNS64 function.
-
-   The steps by which H1 establishes communication with H2 are:
-
-   1.  H1 does a DNS lookup for FQDN(H2).  H1 does this by sending a DNS
-       query for a AAAA record for H2 to the recursive name server.
-
-   2.  The recursive DNS server resolves the query, and returns the
-       answer to H1.  Because there are no AAAA records in the global
-       DNS for H2, the answer is empty.
-
-   3.  The stub resolver at H1 then queries for an A record for H2 and
-       gets back an A record containing the IPv4 address X. The DNS64
-       function within H1 then synthesizes a AAAA record.  The IPv6
-       address in the AAAA record contains the prefix assigned to the
-       IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X
-       and then an all-zero padding i.e. the resulting IPv6 address is
-       Pref64:X::.
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 24]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   4.  H1 sends a packet towards H2.  The packet is sent from a source
-       transport address of (Y',y) to a destination transport address of
-       (Pref64:X::,x), where y and x are ports chosen by H2.
-
-   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
-       Translator and the subsequent communication flows using the IPv6/
-       IPv4 Translator mechanisms.
-
-A.4.  IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode
-
-   In this example, we consider an IPv6 node located in the IPv6
-   Internet site that initiates a communication to a IPv4 node located
-   in the IPv4 site.
-
-   This scenario can be addressed without using any form of DNS64
-   function.  This is so because it is possible to assign a fixed IPv6
-   address to each of the IPv4 servers.  Such an IPv6 address would be
-   constructed as the Pref64::/n concatenated with the IPv4 address of
-   the IPv4 server and an all-zero padding.  Note that the IPv4 address
-   can be a public or a private address; the latter does not present any
-   additional difficulty, since the LIR prefix must be used a Pref64 (in
-   this scenario the usage of the WK prefix is not supported).  Once
-   these IPv6 addresses have been assigned to represent the IPv4 servers
-   in the IPv6 Internet, real AAAA RRs containing these addresses can be
-   published in the DNS under the site's domain.  This is the
-   recommended approach to handle this scenario, because it does not
-   involve synthesizing AAAA records at the time of query.  Such a
-   configuration is easier to troubleshoot in the event of problems,
-   because it always provides the same answer to every query.
-
-   However, there are some more dynamic scenarios, where synthesizing
-   AAAA RRs in this setup may be needed.  In particular, when DNS Update
-   [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
-   servers, there are two options: One option is to modify the server
-   that receives the dynamic DNS updates.  That would normally be the
-   authoritative server for the zone.  So the authoritative zone would
-   have normal AAAA RRs that are synthesized as dynamic updates occur.
-   The other option is modify the authoritative server to generate
-   synthetic AAAA records for a zone, possibly based on additional
-   constraints, upon the receipt of a DNS query for the AAAA RR.  The
-   first option -- in which the AAAA is synthesized when the DNS update
-   message is received, and the data published in the relevant zone --
-   is recommended over the second option (i.e. the synthesis upon
-   receipt of the AAAA DNS query).  This is because it is usually easier
-   to solve problems of misconfiguration and so on when the DNS
-   responses are not being generated dynamically.  For completeness, the
-   DNS64 behavior that we describe in this section covers the case of
-   synthesizing the AAAA RR when the DNS query arrives.  Nevertheless,
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 25]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   such a configuration is NOT RECOMMENDED.  Troubleshooting
-   configurations that change the data depending on the query they
-   receive is notoriously hard, and the IPv4/IPv6 translation scenario
-   is complicated enough without adding additional opportunities for
-   possible malfunction.
-
-   The scenario for this case is depicted in the following figure:
-
-
-     +-----------+          +----------------------------------------+
-     |           |          |   IPv4 site            +-------------+ |
-     |   IPv6    |      +-------+      +----+        | Name server | |
-     | Internet  |------|64Trans|      | H2 |        | with DNS64  | |
-     +-----------+      +-------+      +----+        +-------------+ |
-       |IP addr: Y'         |  |         |IP addr: X     |           |
-     +----+                 | -----------------------------------    |
-     | H1 |                 +----------------------------------------+
-     +----+
-
-   The figure shows an IPv6 node H1 which has an IPv6 address Y' and an
-   IPv4 node H2 with IPv4 address X.
-
-   A IPv6/IPv4 Translator connects the IPv4 network to the IPv6
-   Internet.  This IPv6/IPv4 Translator has a prefix (called
-   Pref64::/n).
-
-   Also shown is the authoritative name server for the local domain with
-   DNS64 functionality.  For the purpose of this example, we assume that
-   the name server is a dual-stack node, so that H1 or a recursive
-   resolver acting on the request of H1 can contact it via IPv6, while
-   it can be contacted by IPv4-only nodes to receive dynamic DNS updates
-   via IPv4.
-
-   The local name server needs to know the prefix assigned to the local
-   IPv6/IPv4 Translator (Pref64::/n).  For the purpose of this example,
-   we assume it learns this through manual configuration.
-
-   The steps by which H1 establishes communication with H2 are:
-
-   1.  H1 does a DNS lookup for FQDN(H2).  H1 does this by sending a DNS
-       query for an AAAA record for H2.  The query is eventually
-       forwarded to the server in the IPv4 site.
-
-   2.  The local DNS server resolves the query (locally), and discovers
-       that there are no AAAA records for H2.
-
-   3.  The name server verifies that FQDN(H2) and its A RR are among
-       those that the local policy defines as allowed to generate a AAAA
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 26]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-       RR from.  If that is the case, the name server synthesizes an
-       AAAA record from the A RR and the relevant Pref64::/n.  The IPv6
-       address in the AAAA record contains the prefix assigned to the
-       IPv6/IPv4 Translator in the first n bits and the IPv4 address X
-       and then an all-zero padding.
-
-   4.  H1 receives the synthetic AAAA record and sends a packet towards
-       H2.  The packet is sent from a source transport address of (Y',y)
-       to a destination transport address of (Pref64:X::,x), where y and
-       x are ports chosen by H2.
-
-   5.  The packet is routed through the IPv6 Internet to the IPv6
-       interface of the IPv6/IPv4 Translator and the communication flows
-       using the IPv6/IPv4 Translator mechanisms.
-
-
-Appendix B.  Motivations and Implications of synthesizing AAAA RR when
-             real AAAA RR exists
-
-   The motivation for synthesizing AAAA RR when a real AAAA RR exists is
-   to support the following scenario:
-
-      An IPv4-only server application (e.g. web server software) is
-      running on a dual-stack host.  There may also be dual-stack server
-      applications also running on the same host.  That host has fully
-      routable IPv4 and IPv6 addresses and hence the authoritative DNS
-      server has an A and a AAAA record as a result.
-
-      An IPv6-only client (regardless of whether the client application
-      is IPv6-only, the client stack is IPv6-only, or it only has an
-      IPv6 address) wants to access the above server.
-
-      The client issues a DNS query to a DNS64 recursor.
-
-   If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
-   then the communication will fail.  Even though there's a real AAAA,
-   the only way for communication to succeed is with the translated
-   address.  So, in order to support this scenario, the administrator of
-   a DNS64 service may want to enable the synthesis of AAAA RR even when
-   real AAAA RR exist.
-
-   The implication of including synthetic AAAA RR when real AAAA RR
-   exist is that translated connectivity may be preferred over native
-   connectivity in some cases where the DNS64 is operated in DNS server
-   mode.
-
-   RFC3484 [RFC3484] rules use longest prefix match to select which is
-   the preferred destination address to use.  So, if the DNS64 recursor
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 27]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-   returns both the synthetic AAAA RR and the real AAAA RR, then if the
-   DNS64 is operated by the same domain as the initiating host, and a
-   global unicast prefix (called the LIR prefix as defined in
-   [I-D.thaler-behave-translator-addressing]) is used, then the
-   synthetic AAAA RR is likely to be preferred.
-
-   This means that without further configuration:
-
-      In the case of An IPv6 network to the IPv4 internet, the host will
-      prefer translated connectivity if LIR prefix is used.  If the
-      Well-Known (WK) prefix defined in
-      [I-D.thaler-behave-translator-addressing] is used, it will
-      probably prefer native connectivity.
-
-      In the case of the IPv6 Internet to an IPv4 network, it is
-      possible to bias the selection towards the real AAAA RR if the
-      DNS64 recursor returns the real AAAA first in the DNS reply, when
-      the LIR prefix is used (the WK prefix usage is not recommended in
-      this case)
-
-      In the case of the IPv6 to IPv4 in the same network, for local
-      destinations (i.e., target hosts inside the local site), it is
-      likely that the LIR prefix and the destination prefix are the
-      same, so we can use the order of RR in the DNS reply to bias the
-      selection through native connectivity.  If a WK prefix is used,
-      the longest prefix match rule will select native connectivity.
-
-   So this option introduces problems in the following cases:
-
-      An IPv6 network to the IPv4 internet with the LIR prefix
-
-      IPv6 to IPv4 in the same network when reaching external
-      destinations and the LIR prefix is used.
-
-   In any case, the problem can be solved by properly configuring the
-   RFC3484 [RFC3484] policy table, but this requires effort on the part
-   of the site operator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 28]
-
-Internet-Draft                    DNS64                     October 2009
-
-
-Authors' Addresses
-
-   Marcelo Bagnulo
-   UC3M
-   Av. Universidad 30
-   Leganes, Madrid  28911
-   Spain
-
-   Phone: +34-91-6249500
-   Fax:
-   Email: marcelo@it.uc3m.es
-   URI:   http://www.it.uc3m.es/marcelo
-
-
-   Andrew Sullivan
-   Shinkuro
-   4922 Fairmont Avenue, Suite 250
-   Bethesda, MD  20814
-   USA
-
-   Phone: +1 301 961 3131
-   Email: ajs@shinkuro.com
-
-
-   Philip Matthews
-   Unaffiliated
-   600 March Road
-   Ottawa, Ontario
-   Canada
-
-   Phone: +1 613-592-4343 x224
-   Fax:
-   Email: philip_matthews@magma.ca
-   URI:
-
-
-   Iljitsch van Beijnum
-   IMDEA Networks
-   Av. Universidad 30
-   Leganes, Madrid  28911
-   Spain
-
-   Phone: +34-91-6246245
-   Email: iljitsch@muada.com
-
-
-
-
-
-
-
-Bagnulo, et al.          Expires April 22, 2010                [Page 29]
-
diff --git a/doc/draft/draft-ietf-behave-dns64-06.txt b/doc/draft/draft-ietf-behave-dns64-06.txt
new file mode 100644
index 000000000000..f648a21029a1
--- /dev/null
+++ b/doc/draft/draft-ietf-behave-dns64-06.txt
@@ -0,0 +1,1680 @@
+
+
+
+BEHAVE WG                                                     M. Bagnulo
+Internet-Draft                                                      UC3M
+Intended status: Standards Track                             A. Sullivan
+Expires: August 19, 2010                                        Shinkuro
+                                                             P. Matthews
+                                                          Alcatel-Lucent
+                                                          I. van Beijnum
+                                                          IMDEA Networks
+                                                       February 15, 2010
+
+
+DNS64: DNS extensions for Network Address Translation from IPv6 Clients
+                            to IPv4 Servers
+                       draft-ietf-behave-dns64-06
+
+Abstract
+
+   DNS64 is a mechanism for synthesizing AAAA records from A records.
+   DNS64 is used with an IPv6/IPv4 translator to enable client-server
+   communication between an IPv6-only client and an IPv4-only server,
+   without requiring any changes to either the IPv6 or the IPv4 node,
+   for the class of applications that work through NATs.  This document
+   specifies DNS64, and provides suggestions on how it should be
+   deployed in conjunction with IPv6/IPv4 translators.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 19, 2010.
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 1]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 2]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Background to DNS64-DNSSEC interaction . . . . . . . . . . . .  7
+   4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.  DNS64 Normative Specification  . . . . . . . . . . . . . . . .  9
+     5.1.  Resolving AAAA queries and the answer section  . . . . . . 10
+       5.1.1.  The answer when there is AAAA data available . . . . . 10
+       5.1.2.  The answer when there is an error  . . . . . . . . . . 10
+       5.1.3.  Special exclusion set for AAAA records . . . . . . . . 10
+       5.1.4.  Dealing with CNAME and DNAME . . . . . . . . . . . . . 11
+       5.1.5.  Data for the answer when performing synthesis  . . . . 11
+       5.1.6.  Performing the synthesis . . . . . . . . . . . . . . . 12
+       5.1.7.  Querying in parallel . . . . . . . . . . . . . . . . . 12
+     5.2.  Generation of the IPv6 representations of IPv4
+           addresses  . . . . . . . . . . . . . . . . . . . . . . . . 12
+     5.3.  Handling other RRs and the Additional Section  . . . . . . 13
+       5.3.1.  PTR queries  . . . . . . . . . . . . . . . . . . . . . 13
+       5.3.2.  Handling the additional section  . . . . . . . . . . . 14
+       5.3.3.  Other records  . . . . . . . . . . . . . . . . . . . . 15
+     5.4.  Assembling a synthesized response to a AAAA query  . . . . 15
+     5.5.  DNSSEC processing: DNS64 in recursive server mode  . . . . 16
+   6.  Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 17
+     6.1.  DNS resolvers and DNS64  . . . . . . . . . . . . . . . . . 17
+     6.2.  DNSSEC validators and DNS64  . . . . . . . . . . . . . . . 17
+     6.3.  DNS64 and multihomed and dual-stack hosts  . . . . . . . . 17
+       6.3.1.  IPv6 multihomed hosts  . . . . . . . . . . . . . . . . 17
+       6.3.2.  Accidental dual-stack DNS64 use  . . . . . . . . . . . 18
+       6.3.3.  Intentional dual-stack DNS64 use . . . . . . . . . . . 18
+   7.  Deployment scenarios and examples  . . . . . . . . . . . . . . 19
+     7.1.  Example of An-IPv6-network-to-IPv4-Internet setup with
+           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 20
+     7.2.  An example of an-IPv6-network-to-IPv4-Internet setup
+           with DNS64 in stub-resolver mode . . . . . . . . . . . . . 21
+     7.3.  Example of IPv6-Internet-to-an-IPv4-network setup
+           DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 23
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
+   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
+   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+     12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
+     12.2. Informative References . . . . . . . . . . . . . . . . . . 26
+   Appendix A.  Motivations and Implications of synthesizing AAAA
+                RR when real AAAA RR exists . . . . . . . . . . . . . 28
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 3]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+1.  Introduction
+
+   This document specifies DNS64, a mechanism that is part of the
+   toolbox for IPv6-IPv4 transition and co-existence.  DNS64, used
+   together with an IPv6/IPv4 translator such as stateful NAT64
+   [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to
+   initiate communications by name to an IPv4-only server.
+
+   DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
+   from A RRs.  A synthetic AAAA RR created by the DNS64 from an
+   original A RR contains the same owner name of the original A RR but
+   it contains an IPv6 address instead of an IPv4 address.  The IPv6
+   address is an IPv6 representation of the IPv4 address contained in
+   the original A RR.  The IPv6 representation of the IPv4 address is
+   algorithmically generated from the IPv4 address returned in the A RR
+   and a set of parameters configured in the DNS64 (typically, an IPv6
+   prefix used by IPv6 representations of IPv4 addresses and optionally
+   other parameters).
+
+   Together with an IPv6/IPv4 translator, these two mechanisms allow an
+   IPv6-only client to initiate communications to an IPv4-only server
+   using the FQDN of the server.
+
+   These mechanisms are expected to play a critical role in the IPv4-
+   IPv6 transition and co-existence.  Due to IPv4 address depletion, it
+   is likely that in the future, many IPv6-only clients will want to
+   connect to IPv4-only servers.  In the typical case, the approach only
+   requires the deployment of IPv6/IPv4 translators that connect an
+   IPv6-only network to an IPv4-only network, along with the deployment
+   of one or more DNS64-enabled name servers.  However, some advanced
+   features require performing the DNS64 function directly in the end-
+   hosts themselves.
+
+
+2.  Overview
+
+   This section provides a non-normative introduction to the DNS64
+   mechanism.
+
+   We assume that we have one or more IPv6/IPv4 translator boxes
+   connecting an IPv4 network and an IPv6 network.  The IPv6/IPv4
+   translator device provides translation services between the two
+   networks enabling communication between IPv4-only hosts and IPv6-only
+   hosts.  (NOTE: By IPv6-only hosts we mean hosts running IPv6-only
+   applications, hosts that can only use IPv6, as well as cases where
+   only IPv6 connectivity is available to the client.  By IPv4-only
+   servers we mean servers running IPv4-only applications, servers that
+   can only use IPv4, as well as cases where only IPv4 connectivity is
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 4]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   available to the server).  Each IPv6/IPv4 translator used in
+   conjunction with DNS64 must allow communications initiated from the
+   IPv6-only host to the IPv4-only host.
+
+   To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
+   learn the address of the responder, DNS64 is used to synthesize a
+   AAAA record from an A record containing a real IPv4 address of the
+   responder, whenever the DNS64 cannot retrieve a AAAA record for the
+   queried name.  The DNS64 service appears as a regular DNS server or
+   resolver to the IPv6 initiator.  The DNS64 receives a AAAA DNS query
+   generated by the IPv6 initiator.  It first attempts a resolution for
+   the requested AAAA records.  If there are no AAAA records available
+   for the target node (which is the normal case when the target node is
+   an IPv4-only node), DNS64 performs a query for A records.  For each A
+   record discovered, DNS64 creates a synthetic AAAA RR from the
+   information retrieved in the A RR.
+
+   The owner name of a synthetic AAAA RR is the same as that of the
+   original A RR, but an IPv6 representation of the IPv4 address
+   contained in the original A RR is included in the AAAA RR.  The IPv6
+   representation of the IPv4 address is algorithmically generated from
+   the IPv4 address and additional parameters configured in the DNS64.
+   Among those parameters configured in the DNS64, there is at least one
+   IPv6 prefix.  If not explicitly mentioned, all prefixes are treated
+   equally and the operations described in this document are performed
+   using the prefixes available.  So as to be general, we will call any
+   of these prefixes Pref64::/n, and describe the operations made with
+   the generic prefix Pref64::/n.  The IPv6 address representing IPv4
+   addresses included in the AAAA RR synthesized by the DNS64 contain
+   Pref64::/n and they also embed the original IPv4 address.
+
+   The same algorithm and the same Pref64::/n prefix(es) must be
+   configured both in the DNS64 device and the IPv6/IPv4 translator(s),
+   so that both can algorithmically generate the same IPv6
+   representation for a given IPv4 address.  In addition, it is required
+   that IPv6 packets addressed to an IPv6 destination address that
+   contains the Pref64::/n be delivered to an IPv6/IPv4 translator, so
+   they can be translated into IPv4 packets.
+
+   Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
+   are passed back to the IPv6 initiator, which will initiate an IPv6
+   communication with the IPv6 address associated with the IPv4
+   receiver.  The packet will be routed to an IPv6/IPv4 translator which
+   will forward it to the IPv4 network.
+
+   In general, the only shared state between the DNS64 and the IPv6/IPv4
+   translator is the Pref64::/n and an optional set of static
+   parameters.  The Pref64::/n and the set of static parameters must be
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 5]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   configured to be the same on both; there is no communication between
+   the DNS64 device and IPv6/IPv4 translator functions.  The mechanism
+   to be used for configuring the parameters of the DNS64 is beyond the
+   scope of this memo.
+
+   The prefixes to be used as Pref64::/n and their applicability are
+   discussed in [I-D.ietf-behave-address-format].  There are two types
+   of prefixes that can be used as Pref64::/n.
+
+      The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved
+      by [I-D.ietf-behave-address-format] for the purpose of
+      representing IPv4 addresses in IPv6 address space.
+
+      The Pref64::/n can be a Network-Specific Prefix (NSP).  An NSP is
+      an IPv6 prefix assigned by an organization to create IPv6
+      representations of IPv4 addresses.
+
+   The main difference in the nature of the two types of prefixes is
+   that the NSP is a locally assigned prefix that is under control of
+   the organization that is providing the translation services, while
+   the Well-Known Prefix is a prefix that has a global meaning since it
+   has been assigned for the specific purpose of representing IPv4
+   addresses in IPv6 address space.
+
+   The DNS64 function can be performed in any of three places.
+
+   The first option is to locate the DNS64 function in authoritative
+   servers for a zone.  In this case, the authoritative server provides
+   a synthetic AAAA RRs for an IPv4-only host in its zone.  This is one
+   type of DNS64 server.
+
+   Another option is to locate the DNS64 function in recursive name
+   servers serving end hosts.  In this case, when an IPv6-only host
+   queries the name server for AAAA RRs for an IPv4-only host, the name
+   server can perform the synthesis of AAAA RRs and pass them back to
+   the IPv6-only initiator.  The main advantage of this mode is that
+   current IPv6 nodes can use this mechanism without requiring any
+   modification.  This mode is called "DNS64 in DNS recursive mode".
+   This is a second type of DNS64 server, and it is also one type of
+   DNS64 resolver.
+
+   The last option is to place the DNS64 function in the end hosts,
+   coupled to the local (stub) resolver.  In this case, the stub
+   resolver will try to obtain (real) AAAA RRs and in case they are not
+   available, the DNS64 function will synthesize AAAA RRs for internal
+   usage.  This mode is compatible with some advanced functions like
+   DNSSEC validation in the end host.  The main drawback of this mode is
+   its deployability, since it requires changes in the end hosts.  This
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 6]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   mode is called "DNS64 in stub-resolver mode".  This is the second
+   type of DNS64 resolver.
+
+
+3.  Background to DNS64-DNSSEC interaction
+
+   DNSSEC presents a special challenge for DNS64, because DNSSEC is
+   designed to detect changes to DNS answers, and DNS64 may alter
+   answers coming from an authoritative server.
+
+   A recursive resolver can be security-aware or security-oblivious.
+   Moreover, a security-aware recursive name server can be validating or
+   non-validating, according to operator policy.  In the cases below,
+   the recursive server is also performing DNS64, and has a local policy
+   to validate.  We call this general case vDNS64, but in all the cases
+   below the DNS64 functionality should be assumed needed.
+
+   DNSSEC includes some signaling bits that offer some indicators of
+   what the query originator understands.
+
+   If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
+   set, the query originator is signaling that it understands DNSSEC.
+   The DO bit does not indicate that the query originator will validate
+   the response.  It only means that the query originator can understand
+   responses containing DNSSEC data.  Conversely, if the DO bit is
+   clear, that is evidence that the querying agent is not aware of
+   DNSSEC.
+
+   If a query arrives at a vDNS64 device with the "Checking Disabled"
+   (CD) bit set, it is an indication that the querying agent wants all
+   the validation data so it can do checking itself.  By local policy,
+   vDNS64 could still validate, but it must return all data to the
+   querying agent anyway.
+
+   Here are the possible cases:
+
+   1.  A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
+       the DO bit clear.  In this case, DNSSEC is not a concern, because
+       the querying agent does not understand DNSSEC responses.
+
+   2.  A security-oblivious DNS64 receives a query with the DO bit set,
+       and the CD bit clear or set.  This is just like the case of a
+       non-DNS64 case: the server doesn't support it, so the querying
+       agent is out of luck.
+
+   3.  A security-aware and non-validating DNS64 receives a query with
+       the DO bit set and the CD bit clear.  Such a resolver is not
+       validating responses, likely due to local policy (see [RFC4035],
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 7]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+       section 4.2).  For that reason, this case amounts to the same as
+       the previous case, and no validation happens.
+
+   4.  A security-aware and non-validating DNS64 receives a query with
+       the DO bit set and the CD bit set.  In this case, the resolver is
+       supposed to pass on all the data it gets to the query initiator
+       (see section 3.2.2 of [RFC4035]).  This case will be problematic
+       with DNS64.  If the DNS64 server modifies the record, the client
+       will get the data back and try to validate it, and the data will
+       be invalid as far as the client is concerned.
+
+   5.  A security-aware and validating DNS64 node receives a query with
+       the DO bit clear and CD clear.  In this case, the resolver
+       validates the data.  If it fails, it returns RCODE 2 (Server
+       failure); otherwise, it returns the answer.  This is the ideal
+       case for vDNS64.  The resolver validates the data, and then
+       synthesizes the new record and passes that to the client.  The
+       client, which is presumably not validating (else it should have
+       set DO and CD), cannot tell that DNS64 is involved.
+
+   6.  A security-aware and validating DNS64 node receives a query with
+       the DO bit set and CD clear.  This ought to work like the
+       previous case, except that the resolver should also set the
+       "Authentic Data" (AD) bit on the response.
+
+   7.  A security-aware and validating DNS64 node receives a query with
+       the DO bit set and CD set.  This is effectively the same as the
+       case where a security-aware and non-validating recursive resolver
+       receives a similar query, and the same thing will happen: the
+       downstream validator will mark the data as invalid if DNS64 has
+       performed synthesis.
+
+
+4.  Terminology
+
+   This section provides definitions for the special terms used in the
+   document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   Authoritative server:  A DNS server that can answer authoritatively a
+      given DNS question.
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 8]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   DNS64:  A logical function that synthesizes DNS resource records (e.g
+      AAAA records containing IPv6 addresses) from DNS resource records
+      actually contained in the DNS (e.g., A records containing IPv4
+      addresses).
+
+   DNS64 recursor:  A recursive resolver that provides the DNS64
+      functionality as part of its operation.  This is the same thing as
+      "DNS64 in recursive resolver mode".
+
+   DNS64 resolver:  Any resolver (stub resolver or recursive resolver)
+      that provides the DNS64 function.
+
+   DNS64 server:  Any server providing the DNS64 function.
+
+   Recursive resolver:  A DNS server that accepts requests from one
+      resolver, and asks another server (of some description) for the
+      answer on behalf of the first resolver.
+
+   Synthetic RR:  A DNS resource record (RR) that is not contained in
+      any zone data file, but has been synthesized from other RRs.  An
+      example is a synthetic AAAA record created from an A record.
+
+   IPv6/IPv4 translator:  A device that translates IPv6 packets to IPv4
+      packets and vice-versa.  It is only required that the
+      communication initiated from the IPv6 side be supported.
+
+   For a detailed understanding of this document, the reader should also
+   be familiar with DNS terminology from [RFC1034], [RFC1035] and
+   current NAT terminology from [RFC4787].  Some parts of this document
+   assume familiarity with the terminology of the DNS security
+   extensions outlined in [RFC4035].
+
+
+5.  DNS64 Normative Specification
+
+   DNS64 is a logical function that synthesizes AAAA records from A
+   records.  The DNS64 function may be implemented in a stub resolver,
+   in a recursive resolver, or in an authoritative name server.
+
+   The implementation SHOULD support mapping of separate IPv4 address
+   ranges to separate IPv6 prefixes for AAAA record synthesis.  This
+   allows handling of special use IPv4 addresses [RFC5735].  Support of
+   multicast address handling is out of the scope of this document.  A
+   possible approach is specified in [I-D.venaas-behave-mcast46].
+
+   DNS64 also responds to PTR queries involving addresses containing any
+   of the IPv6 prefixes it uses for synthesis of AAAA RRs.
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010                [Page 9]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+5.1.  Resolving AAAA queries and the answer section
+
+   When the DNS64 receives a query for RRs of type AAAA and class IN, it
+   first attempts to retrieve non-synthetic RRs of this type and class,
+   either by performing a query or, in the case of an authoritative
+   server, by examining its own results.  DNS64 operation for classes
+   other than IN is undefined, and a DNS64 MUST behave as though no
+   DNS64 function is configured.
+
+5.1.1.  The answer when there is AAAA data available
+
+   If the query results in one or more AAAA records in the answer
+   section, the result is returned to the requesting client as per
+   normal DNS semantics, except in the case where any of the AAAA
+   records match a special exclusion set of prefixes, considered in
+   Section 5.1.3.  If there is (non-excluded) AAAA data available, DNS64
+   SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A
+   for an analysis of the motivations for and the implications of not
+   complying with this recommendation).  By default DNS64
+   implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
+   exist.
+
+5.1.2.  The answer when there is an error
+
+   If the query results in a response with RCODE other than 0 (No error
+   condition), then there are two possibilities.  A result with RCODE=3
+   (Name Error) is handled according to normal DNS operation (which is
+   normally to return the error to the client).  This stage is still
+   prior to any synthesis having happened, so a response to be returned
+   to the client does not need any special assembly than would usually
+   happen in DNS operation.
+
+   Any other RCODE is treated as though the RCODE were 0 and the answer
+   section were empty.  This is because of the large number of different
+   responses from deployed name servers when they receive AAAA queries
+   without a AAAA record being available.
+
+   It is important to note that, as of this writing, some servers
+   respond with RCODE=3 to a AAAA query even if there is an A record
+   available for that owner name.  Those servers are in clear violation
+   of the meaning of RCODE 3, and it is expected that they will decline
+   in use as IPv6 deployment increases.
+
+5.1.3.  Special exclusion set for AAAA records
+
+   Some IPv6 addresses are not actually usable by IPv6-only hosts.  If
+   they are returned to IPv6-only querying agents as AAAA records,
+   therefore, the goal of decreasing the number of failure modes will
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 10]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   not be attained.  Examples include AAAA records with addresses in the
+   ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
+   records with the site's Pref::64/n or the Well-Known Prefix (see
+   below for more about the Well-Known Prefix).  A DNS64 implementation
+   SHOULD provide a mechanism to specify IPv6 prefix ranges to be
+   treated as though the AAAA containing them were an empty answer.  An
+   implementation SHOULD include the ::ffff/96 network in that range by
+   default.  Failure to provide this facility will mean that clients
+   querying the DNS64 function may not be able to communicate with hosts
+   that would be reachable from a dual-stack host.
+
+   When the DNS64 performs its initial AAAA query, if it receives an
+   answer with only AAAA records containing addresses in the excluded
+   range(s), then it MUST treat the answer as though it were an empty
+   answer, and proceed accordingly.  If it receives an answer with at
+   least one AAAA record containing an address outside any of the
+   excluded range(s), then it MAY build an answer section for a response
+   including only the AAAA record(s) that do not contain any of the
+   addresses inside the excluded ranges.  That answer section is used in
+   the assembly of a response as detailed in Section 5.4.
+   Alternatively, it MAY treat the answer as though it were an empty
+   answer, and proceed accordingly.  It MUST NOT return the offending
+   AAAA records as part of a response.
+
+5.1.4.  Dealing with CNAME and DNAME
+
+   If the response contains a CNAME or a DNAME, then the CNAME or DNAME
+   chain is followed until the first terminating A or AAAA record is
+   reached.  This may require the DNS64 to ask for an A record, in case
+   the response to the original AAAA query is a CNAME or DNAME without a
+   AAAA record to follow.  The resulting AAAA or A record is treated
+   like any other AAAA or A case, as appropriate.
+
+   When assembling the answer section, the original CNAME or DNAME RR is
+   included as part of the answer, and the synthetic AAAA, if
+   appropriate, is included.
+
+5.1.5.  Data for the answer when performing synthesis
+
+   If the query results in no error but an empty answer section in the
+   response, the DNS64 attempts to retrieve A records for the name in
+   question, either by performing another query or, in the case of an
+   authortiative server, by examining its own results.  If this new A RR
+   query results in an empty answer or in an error, then the empty
+   result or error is used as the basis for the answer returned to the
+   querying client.  (Transient errors may result in retrying the query,
+   depending on the mode and operation of the underlying resolver; this
+   is just as in Section 5.1.2.)  If instead the query results in one or
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 11]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs
+   according to the procedure outlined in Section 5.1.6.  The DNS64
+   returns the synthesized AAAA records in the answer section, removing
+   the A records that form the basis of the synthesis.
+
+5.1.6.  Performing the synthesis
+
+   A synthetic AAAA record is created from an A record as follows:
+
+   o  The NAME field is set to the NAME field from the A record
+
+   o  The TYPE field is set to 28 (AAAA)
+
+   o  The CLASS field is set to the original CLASS field, 1.  Under this
+      specification, DNS64 for any CLASS other than 1 is undefined.
+
+   o  The TTL field is set to the minimum of the TTL of the original A
+      RR and the SOA RR for the queried domain.  (Note that in order to
+      obtain the TTL of the SOA RR, the DNS64 does not need to perform a
+      new query, but it can remember the TTL from the SOA RR in the
+      negative response to the AAAA query.)
+
+   o  The RDLENGTH field is set to 16
+
+   o  The RDATA field is set to the IPv6 representation of the IPv4
+      address from the RDATA field of the A record.  The DNS64 SHOULD
+      check each A RR against configured IPv4 address ranges and select
+      the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
+      See Section 5.2 for discussion of the algorithms to be used in
+      effecting the transformation.
+
+5.1.7.  Querying in parallel
+
+   The DNS64 MAY perform the query for the AAAA RR and for the A RR in
+   parallel, in order to minimize the delay.  However, this would result
+   in performing unnecessary A RR queries in the case where no AAAA RR
+   synthesis is required.  A possible trade-off would be to perform them
+   sequentially but with a very short interval between them, so if we
+   obtain a fast reply, we avoid doing the additional query.  (Note that
+   this discussion is relevant only if the DNS64 function needs to
+   perform external queries to fetch the RR.  If the needed RR
+   information is available locally, as in the case of an authoritative
+   server, the issue is no longer relevant.)
+
+5.2.  Generation of the IPv6 representations of IPv4 addresses
+
+   DNS64 supports multiple algorithms for the generation of the IPv6
+   representation of an IPv4 address.  The constraints imposed on the
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 12]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   generation algorithms are the following:
+
+      The same algorithm to create an IPv6 address from an IPv4 address
+      MUST be used by both a DNS64 to create the IPv6 address to be
+      returned in the synthetic AAAA RR from the IPv4 address contained
+      in an original A RR, and by a IPv6/IPv4 translator to create the
+      IPv6 address to be included in the source address field of the
+      outgoing IPv6 packets from the IPv4 address included in the source
+      address field of the incoming IPv4 packet.
+
+      The algorithm MUST be reversible; i.e., it MUST be possible to
+      derive the original IPv4 address from the IPv6 representation.
+
+      The input for the algorithm MUST be limited to the IPv4 address,
+      the IPv6 prefix (denoted Pref64::/n) used in the IPv6
+      representations and optionally a set of stable parameters that are
+      configured in the DNS64 and in the NAT64 (such as fixed string to
+      be used as a suffix).
+
+         For each prefix Pref64::/n, n MUST the less than or equal to
+         96.  If one or more Pref64::/n are configured in the DNS64
+         through any means in the DNS64 (such as manually configured, or
+         other automatic means not specified in this document), the
+         default algorithm MUST use these prefixes (and not use the
+         Well-Know Prefix).  If no prefix is available, the algorithm
+         MUST use the Well-Known prefix 64:FF9B::/96 defined in
+         [I-D.ietf-behave-address-format] to represent the IPv4 unicast
+         address range
+
+      [[anchor9: Note in document: The value 64:FF9B::/96 is proposed as
+      the value for the Well-Known prefix and needs to be confirmed
+      whenis published as RFC.]][I-D.ietf-behave-address-format]
+
+   A DNS64 MUST support the algorithm for generating IPv6
+   representations of IPv4 addresses defined in Section 2 of
+   [I-D.ietf-behave-address-format].  Moreover, the aforementioned
+   algorithm MUST be the default algorithm used by the DNS64.  While the
+   normative description of the algorithm is provided in
+   [I-D.ietf-behave-address-format], a sample description of the
+   algorithm and its application to different scenarios is provided in
+   Section 7 for illustration purposes.
+
+5.3.  Handling other RRs and the Additional Section
+
+5.3.1.  PTR queries
+
+   If a DNS64 server receives a PTR query for a record in the IP6.ARPA
+   domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 13]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   address portion of the QNAME according to the encoding scheme
+   outlined in section 2.5 of [RFC3596], and examine the resulting
+   address to see whether its prefix matches any of the locally-
+   configured Pref64::/n.  There are two alternatives for a DNS64 server
+   to respond to such PTR queries.  A DNS64 server MUST provide one of
+   these, and SHOULD NOT provide both at the same time unless different
+   IP6.ARPA zones require answers of different sorts.
+
+   The first option is for the DNS64 server to respond authoritatively
+   for its prefixes.  If the address prefix matches any Pref64::/n used
+   in the site, either a NSP or the Well-Known Prefix (i.e. 64:
+   FF9B::/96), then the DNS64 server MAY answer the query using locally-
+   appropriate RDATA.  The DNS64 server MAY use the same RDATA for all
+   answers.  Note that the requirement is to match any Pref64::/n used
+   at the site, and not merely the locally-configured Pref64::/n.  This
+   is because end clients could ask for a PTR record matching an address
+   received through a different (site-provided) DNS64, and if this
+   strategy is in effect, those queries should never be sent to the
+   global DNS.  The advantage of this strategy is that it makes plain to
+   the querying client that the prefix is one operated by the (DNS64)
+   site, and that the answers the client is getting are generated by
+   DNS64.  The disadvantage is that any useful reverse-tree information
+   that might be in the global DNS is unavailable to the clients
+   querying the DNS64.
+
+   The second option is for the DNS64 nameserver to synthesize a CNAME
+   mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA
+   name.  The rest of the response would be the normal DNS processing.
+   The CNAME can be signed on the fly if need be.  The advantage of this
+   approach is that any useful information in the reverse tree is
+   available to the querying client.  The disadvantage is that it adds
+   additional load to the DNS64 (because CNAMEs have to be synthesized
+   for each PTR query that matches the Pref64::/n), and that it may
+   require signing on the fly.  In addition, the generated CNAME could
+   correspond to an unpopulated in-addr.arpa zone, so the CNAME would
+   provide a reference to a non-existent record.
+
+   If the address prefix does not match any Pref64::/n, then the DNS64
+   server MUST process the query as though it were any other query; i.e.
+   a recursive nameserver MUST attempt to resolve the query as though it
+   were any other (non-A/AAAA) query, and an authoritative server MUST
+   respond authoritatively or with a referral, as appropriate.
+
+5.3.2.  Handling the additional section
+
+   DNS64 synthesis MUST NOT be performed on any records in the
+   additional section of synthesized answers.  The DNS64 MUST pass the
+   additional section unchanged.
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 14]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   It may appear that adding synthetic records to the additional section
+   is desirable, because clients sometimes use the data in the
+   additional section to proceed without having to re-query.  There is
+   in general no promise, however, that the additional section will
+   contain all the relevant records, so any client that depends on the
+   additional section being able to satisfy its needs (i.e. without
+   additional queries) is necessarily broken.  An IPv6-only client that
+   needs a AAAA record, therefore, will send a query for the necessary
+   AAAA record if it is unable to find such a record in the additional
+   section of an answer it is consuming.  For a correctly-functioning
+   client, the effect would be no different if the additional section
+   were empty.
+
+   The alternative, of removing the A records in the additional section
+   and replacing them with synthetic AAAA records, may cause a host
+   behind a NAT64 to query directly a nameserver that is unaware of the
+   NAT64 in question.  The result in this case will be resolution
+   failure anyway, only later in the resolution operation.
+
+5.3.3.  Other records
+
+   If the DNS64 is in recursive resolver mode, then considerations
+   outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant.
+
+   All other RRs MUST be returned unchanged.
+
+5.4.  Assembling a synthesized response to a AAAA query
+
+   A DNS64 uses different pieces of data to build the response returned
+   to the querying client.
+
+   The query that is used as the basis for synthesis results either in
+   an error, an answer that can be used as a basis for synthesis, or an
+   empty (authoritative) answer.  If there is an empty answer, then the
+   DNS64 responds to the original querying client with the answer the
+   DNS64 received to the original AAAA query.  Otherwise, the response
+   is assembled as follows.
+
+   The header fields are set according to the usual rules for recursive
+   or authoritative servers, depending on the role that the DNS64 is
+   serving.  The question section is copied from the original AAAA
+   query.  The answer section is populated according to the rules in
+   Section 5.1.6.  The authority and additional sections are copied from
+   the response to the A query that the DNS64 performed.
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 15]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+5.5.  DNSSEC processing: DNS64 in recursive server mode
+
+   We consider the case where a recursive server that is performing
+   DNS64 also has a local policy to validate the answers according to
+   the procedures outlined in [RFC4035] Section 5.  We call this general
+   case vDNS64.
+
+   The vDNS64 uses the presence of the DO and CD bits to make some
+   decisions about what the query originator needs, and can react
+   accordingly:
+
+   1.  If CD is not set and DO is not set, vDNS64 SHOULD perform
+       validation and do synthesis as needed.
+
+   2.  If CD is not set and DO is set, then vDNS64 SHOULD perform
+       validation.  Whenever vDNS64 performs validation, it MUST
+       validate the negative answer for AAAA queries before proceeding
+       to query for A records for the same name, in order to be sure
+       that there is not a legitimate AAAA record on the Internet.
+       Failing to observe this step would allow an attacker to use DNS64
+       as a mechanism to circumvent DNSSEC.  If the negative response
+       validates, and the response to the A query validates, then the
+       vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
+       answer to the client.  This is acceptable, because [RFC4035],
+       section 3.2.3 says that the AD bit is set by the name server side
+       of a security-aware recursive name server if and only if it
+       considers all the RRSets in the Answer and Authority sections to
+       be authentic.  In this case, the name server has reason to
+       believe the RRSets are all authentic, so it SHOULD set the AD
+       bit.  If the data does not validate, the vDNS64 MUST respond with
+       RCODE=2 (Server failure).
+       A security-aware end point might take the presence of the AD bit
+       as an indication that the data is valid, and may pass the DNS
+       (and DNSSEC) data to an application.  If the application attempts
+       to validate the synthesized data, of course, the validation will
+       fail.  One could argue therefore that this approach is not
+       desirable, but security aware stub resolvers must not place any
+       reliance on data received from resolvers and validated on their
+       behalf without certain criteria established by [RFC4035], section
+       4.9.3.  An application that wants to perform validation on its
+       own should use the CD bit.
+
+   3.  If the CD bit is set and DO is set, then vDNS64 MAY perform
+       validation, but MUST NOT perform synthesis.  It MUST return the
+       data to the query initiator, just like a regular recursive
+       resolver, and depend on the client to do the validation and the
+       synthesis itself.
+       The disadvantage to this approach is that an end point that is
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 16]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+       translation-oblivious but security-aware and validating will not
+       be able to use the DNS64 functionality.  In this case, the end
+       point will not have the desired benefit of NAT64.  In effect,
+       this strategy means that any end point that wishes to do
+       validation in a NAT64 context must be upgraded to be translation-
+       aware as well.
+
+
+6.  Deployment notes
+
+   While DNS64 is intended to be part of a strategy for aiding IPv6
+   deployment in an internetworking environment with some IPv4-only and
+   IPv6-only networks, it is important to realise that it is
+   incompatible with some things that may be deployed in an IPv4-only or
+   dual-stack context.
+
+6.1.  DNS resolvers and DNS64
+
+   Full-service resolvers that are unaware of the DNS64 function can be
+   (mis)configured to act as mixed-mode iterative and forwarding
+   resolvers.  In a native IPv4 context, this sort of configuration may
+   appear to work.  It is impossible to make it work properly without it
+   being aware of the DNS64 function, because it will likely at some
+   point obtain IPv4-only glue records and attempt to use them for
+   resolution.  The result that is returned will contain only A records,
+   and without the ability to perform the DNS64 function the resolver
+   will be unable to answer the necessary AAAA queries.
+
+6.2.  DNSSEC validators and DNS64
+
+   Existing DNSSEC validators (i.e. that are unaware of DNS64) might
+   reject all the data that comes from DNS64 as having been tampered
+   with (even if it did not set CD when querying).  If it is necessary
+   to have validation behind the DNS64, then the validator must know how
+   to perform the DNS64 function itself.  Alternatively, the validating
+   host may establish a trusted connection with a DNS64, and allow the
+   DNS64 recursor to do all validation on its behalf.
+
+6.3.  DNS64 and multihomed and dual-stack hosts
+
+6.3.1.  IPv6 multihomed hosts
+
+   Synthetic AAAA records may be constructed on the basis of the network
+   context in which they were constructed.  If a host sends DNS queries
+   to resolvers in multiple networks, it is possible that some of them
+   will receive answers from a DNS64 without all of them being connected
+   via a NAT64.  For instance, suppose a system has two interfaces, i1
+   and i2.  Whereas i1 is connected to the IPv4 Internet via NAT64, i2
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 17]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   has native IPv6 connectivity only.  I1 might receive a AAAA answer
+   from a DNS64 that is configured for a particular NAT64; the IPv6
+   address contained in that AAAA answer will not connect with anything
+   via i2.
+
+   This example illustrates why it is generally preferable that hosts
+   treat DNS answers from one interface as local to that interface.  The
+   answer received on one interface will not work on the other
+   interface.  Hosts that attempt to use DNS answers globally may
+   encounter surprising failures in these cases.  For more discussion of
+   this topic, see [I-D.savolainen-mif-dns-server-selection].
+
+   Note that the issue is not that there are two interfaces, but that
+   there are two networks involved.  The same results could be achieved
+   with a single interface routed to two different networks.
+
+6.3.2.  Accidental dual-stack DNS64 use
+
+   Similarly, suppose that i1 has IPv6 connectivity and can connect to
+   the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity.
+   In this case, i1 could receive an IPv6 address from a synthetic AAAA
+   that would better be reached via native IPv4.  Again, it is worth
+   emphasising that this arises because there are two networks involved.
+
+   Since it is most likely that the host will attempt AAAA resolution
+   first, in this arrangement the host will often use the NAT64 when
+   native IPv4 would be preferable.  For this reason, hosts with IPv4
+   connectivity to the Internet should avoid using DNS64.  This can be
+   partly resolved by ISPs when providing DNS resolvers to clients, but
+   that is not a guarantee that the NAT64 will never be used when a
+   native IPv4 connection should be used.  There is no general-purpose
+   mechanism to ensure that native IPv4 transit will always be
+   preferred, because to a DNS64-oblivious host, the DNS64 looks just
+   like an ordinary DNS server.  Operators of a NAT64 should expect
+   traffic to pass through the NAT64 even when it is not necessary.
+
+6.3.3.  Intentional dual-stack DNS64 use
+
+   Finally, consider the case where the IPv4 connectivity on i2 is only
+   to a LAN, with an IPv6-only connection on i1 to the Internet,
+   connecting to the IPv4 Internet via NAT64.  Traffic to the LAN may
+   not be routable from the global Internet, as is often the case (for
+   instance) with LANs using RFC1918 addresses.  In this case, it is
+   critical that the DNS64 not synthesize AAAA responses for hosts in
+   the LAN, or else that the DNS64 be aware of hosts in the LAN and
+   provide context-sensitive answers ("split view" DNS answers) for
+   hosts inside the LAN.  As with any split view DNS arrangement,
+   operators must be prepared for data to leak from one context to
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 18]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   another, and for failures to occur because nodes accessible from one
+   context are not accessible from the other.
+
+   It is important for deployers of DNS64 to realise that, in some
+   circumstances, making the DNS64 available to a dual-stack host will
+   cause the host to prefer to send packets via NAT64 instead of via
+   native IPv4, with the associated loss of performance or functionality
+   (or both) entailed by the NAT.  At the same time, some hosts are not
+   able to learn about DNS servers provisioned on IPv6 addresses, or
+   simply cannot send DNS packets over IPv6.
+
+
+7.  Deployment scenarios and examples
+
+   In this section, we walk through some sample scenarios that are
+   expected to be common deployment cases.  It should be noted that this
+   is provided for illustrative purposes and this section is not
+   normative.  The normative definition of DNS64 is provided in
+   Section 5 and the normative definition of the address transformation
+   algorithm is provided in [I-D.ietf-behave-address-format].
+
+   There are two main different setups where DNS64 is expected to be
+   used (other setups are possible as well, but these two are the main
+   ones identified at the time of this writing).
+
+      One possible setup that is expected to be common is the case of an
+      end site or an ISP that is providing IPv6-only connectivity or
+      connectivity to IPv6-only hosts that wants to allow the
+      communication from these IPv6-only connected hosts to the IPv4
+      Internet.  This case is called An-IPv6-network-to-IPv4-Internet
+      [I-D.ietf-behave-v6v4-framework].  In this case, the IPv6/IPv4
+      Translator is used to connect the end site or the ISP to the IPv4
+      Internet and the DNS64 function is provided by the end site or the
+      ISP.
+
+      The other possible setup that is expected is an IPv4 site that
+      wants that its IPv4 servers to be reachable from the IPv6
+      Internet.  This case is called IPv6-Internet-to-an-IPv4-network
+      [I-D.ietf-behave-v6v4-framework].  It should be noted that the
+      IPv4 addresses used in the IPv4 site can be either public or
+      private.  In this case, the IPv6/IPv4 translator is used to
+      connect the IPv4 end site to the IPv6 Internet and the DNS64
+      function is provided by the IPv4 end site itself.
+
+   In this section we illustrate how the DNS64 behaves in the different
+   scenarios that are expected to be common.  We consider then 3
+   possible scenarios, namely:
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 19]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   1.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
+       mode
+
+   2.  An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
+       resolver mode
+
+   3.  IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
+       mode
+
+7.1.  Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in
+      DNS server mode
+
+   In this example, we consider an IPv6 node located in an IPv6-only
+   site that initiates a communication to an IPv4 node located in the
+   IPv4 Internet.
+
+   The scenario for this case is depicted in the following figure:
+
+
+             +---------------------+         +---------------+
+             |IPv6 network         |         |    IPv4       |
+             |           |  +-------------+  |  Network      |
+             |           |--| Name server |--|               |
+             |           |  | with DNS64  |  |  +----+       |
+             |  +----+   |  +-------------+  |  | H2 |       |
+             |  | H1 |---|         |         |  +----+       |
+             |  +----+   |      +-------+    |  192.0.2.1    |
+             |           |------| NAT64 |----|               |
+             |           |      +-------+    |               |
+             |           |         |         |               |
+             +---------------------+         +---------------+
+
+   The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
+   address 192.0.2.1 and FQDN h2.example.com
+
+   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+   Internet.  This IPv6/IPv4 Translator has an IPv4 address 203.0.113.1
+   assigned to its IPv4 interface and it is using the WKP 64:FF9B::/96
+   to create IPv6 representations of IPv4 addresses, as defined in
+   [I-D.ietf-behave-address-format].
+
+   The other element involved is the local name server.  The name server
+   is a dual-stack node, so that H1 can contact it via IPv6, while it
+   can contact IPv4-only name servers via IPv4.
+
+   The local name server is configured to represent the whole IPv4
+   unicast space with using the WKP 64:FF9B::/96.  For the purpose of
+   this example, we assume it learns this through manual configuration.
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 20]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   For this example, assume the typical DNS situation where IPv6 hosts
+   have only stub resolvers, and they are configured with the IP address
+   of a name server that they always have to query and that performs
+   recursive lookups (henceforth called "the recursive nameserver").
+
+   The steps by which H1 establishes communication with H2 are:
+
+   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
+       a DNS query for a AAAA record for H2 to the recursive name
+       server.  The recursive name server implements DNS64
+       functionality.
+
+   2.  The recursive name server resolves the query, and discovers that
+       there are no AAAA records for H2.
+
+   3.  The recursive name server queries for A records for H2 and gets
+       back a single A records containing the IPv4 address 192.0.2.1.
+       The name server then synthesizes a AAAA records.  The IPv6
+       address in the AAAA record contains the prefix assigned to the
+       IPv6/IPv4 Translator in the upper 96 bits then the received IPv4
+       address i.e. the resulting IPv6 address is 64:FF9B::192.0.2.1
+
+   4.  H1 receives the synthetic AAAA record and sends a packet towards
+       H2.  The packet is sent to the destination address 64:FF9B::
+       192.0.2.1.
+
+   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
+       translator and the subsequent communication flows by means of the
+       IPv6/IPv4 translator mechanisms.
+
+7.2.  An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in
+      stub-resolver mode
+
+   This case is depicted in the following figure:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 21]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+             +---------------------+         +---------------+
+             |IPv6 network         |         |    IPv4       |
+             |           |     +--------+    |  Network      |
+             |           |-----| Name   |----|               |
+             | +-----+   |     | server |    |  +----+       |
+             | | H1  |   |     +--------+    |  | H2 |       |
+             | |with |---|         |         |  +----+       |
+             | |DNS64|   |      +-------+    |  192.0.2.1    |
+             | +----+    |------| NAT64 |----|               |
+             |           |      +-------+    |               |
+             |           |         |         |               |
+             +---------------------+         +---------------+
+
+
+   The figure shows an IPv6 node H1 implementing the DNS64 function and
+   an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com
+
+   A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
+   Internet.  This IPv6/IPv4 Translator is using the WKP 64:FF9B::/96
+   and an IPv4 address T 203.0.113.1 assigned to its IPv4 interface.
+
+   H1 needs to know the prefix assigned to the local IPv6/IPv4
+   Translator (64:FF9B::/96).  For the purpose of this example, we
+   assume it learns this through manual configuration.
+
+   Also shown is a name server.  For the purpose of this example, we
+   assume that the name server is a dual-stack node, so that H1 can
+   contact it via IPv6, while it can contact IPv4-only name servers via
+   IPv4.
+
+   For this example, assume the typical situation where IPv6 hosts have
+   only stub resolvers and always query a name server that provides
+   recursive lookups (henceforth called "the recursive name server").
+   The recursive name server does not perform the DNS64 function.
+
+   The steps by which H1 establishes communication with H2 are:
+
+   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
+       a DNS query for a AAAA record for H2 to the recursive name
+       server.
+
+   2.  The recursive DNS server resolves the query, and returns the
+       answer to H1.  Because there are no AAAA records in the global
+       DNS for H2, the answer is empty.
+
+   3.  The stub resolver at H1 then queries for an A record for H2 and
+       gets back an A record containing the IPv4 address 192.0.2.1.  The
+       DNS64 function within H1 then synthesizes a AAAA record.  The
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 22]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+       IPv6 address in the AAAA record contains the prefix assigned to
+       the IPv6/IPv4 translator in the upper 96 bits, then the received
+       IPv4 address i.e. the resulting IPv6 address is 64:FF9B::
+       192.0.2.1.
+
+   4.  H1 sends a packet towards H2.  The packet is sent to the
+       destination address 64:FF9B::192.0.2.1.
+
+   5.  The packet is routed to the IPv6 interface of the IPv6/IPv4
+       translator and the subsequent communication flows using the IPv6/
+       IPv4 translator mechanisms.
+
+7.3.  Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
+      server mode
+
+   In this example, we consider an IPv6 node located in the IPv6
+   Internet that initiates a communication to an IPv4 node located in
+   the IPv4 site.
+
+   In some cases, this scenario can be addressed without using any form
+   of DNS64 function.  This is so because in principle it is possible to
+   assign a fixed IPv6 address to each of the IPv4 nodes.  Such an IPv6
+   address would be constructed using the address transformation
+   algorithm defined in [I-D.ietf-behave-address-format] that takes as
+   input the Pref64::/96 and the IPv4 address of the IPv4 node.  Note
+   that the IPv4 address can be a public or a private address; the
+   latter does not present any additional difficulty, since an NSP must
+   be used as Pref64::/96 (in this scenario the usage of the Well-Known
+   prefix is not supported as discussed in
+   [I-D.ietf-behave-address-format]).  Once these IPv6 addresses have
+   been assigned to represent the IPv4 nodes in the IPv6 Internet, real
+   AAAA RRs containing these addresses can be published in the DNS under
+   the site's domain.  This is the recommended approach to handle this
+   scenario, because it does not involve synthesizing AAAA records at
+   the time of query.
+
+   However, there are some more dynamic scenarios, where synthesizing
+   AAAA RRs in this setup may be needed.  In particular, when DNS Update
+   [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
+   nodes, there are two options: One option is to modify the DNS server
+   that receives the dynamic DNS updates.  That would normally be the
+   authoritative server for the zone.  So the authoritative zone would
+   have normal AAAA RRs that are synthesized as dynamic updates occur.
+   The other option is modify all the authoritative servers to generate
+   synthetic AAAA records for a zone, possibly based on additional
+   constraints, upon the receipt of a DNS query for the AAAA RR.  The
+   first option -- in which the AAAA is synthesized when the DNS update
+   message is received, and the data published in the relevant zone --
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 23]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   is recommended over the second option (i.e. the synthesis upon
+   receipt of the AAAA DNS query).  This is because it is usually easier
+   to solve problems of misconfiguration and so on when the DNS
+   responses are not being generated dynamically.  However, it may be
+   the case where the primary server (that receives all the updates)
+   cannot be upgraded for whatever reason, but where a secondary can be
+   upgraded in order to handle the (comparatively small amount) of AAAA
+   queries.  In such case, it is possible to use the DNS64 as described
+   next.  The DNS64 behavior that we describe in this section covers the
+   case of synthesizing the AAAA RR when the DNS query arrives.
+
+   The scenario for this case is depicted in the following figure:
+
+
+              +-----------+          +----------------------+
+              |           |          |   IPv4 site          |
+              |   IPv6    |      +-------+     |   +----+   |
+              | Internet  |------| NAT64 |-----|---| H2 |   |
+              |           |      +-------+     |   +----+   |
+              |           |          |         | 192.0.2.1  |
+              |           |    +------------+  |            |
+              |           |----| Name server|--|            |
+              |           |    | with DNS64 |  |            |
+              +-----------+    +------------+  |            |
+                |                    |         |            |
+              +----+                 |                      |
+              | H1 |                 +----------------------+
+              +----+
+
+   The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
+   address X 192.0.2.1 and FQDN h2.example.com.
+
+   A IPv6/IPv4 translator connects the IPv4 network to the IPv6
+   Internet.  This IPv6/IPv4 translator has a NSP 2001:DB8::/96.
+
+   Also shown is the authoritative name server for the local domain with
+   DNS64 functionality.  For the purpose of this example, we assume that
+   the name server is a dual-stack node, so that H1 or a recursive
+   resolver acting on the request of H1 can contact it via IPv6, while
+   it can be contacted by IPv4-only nodes to receive dynamic DNS updates
+   via IPv4.
+
+   The local name server needs to know the prefix assigned to the local
+   IPv6/IPv4 Translator (2001:DB8::/96).  For the purpose of this
+   example, we assume it learns this through manual configuration.
+
+   The steps by which H1 establishes communication with H2 are:
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 24]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   1.  H1 does a DNS lookup for h2.example.com.  H1 does this by sending
+       a DNS query for a AAAA record for H2.  The query is eventually
+       forwarded to the server in the IPv4 site.
+
+   2.  The local DNS server resolves the query (locally), and discovers
+       that there are no AAAA records for H2.
+
+   3.  The name server verifies that h2.example.com and its A RR are
+       among those that the local policy defines as allowed to generate
+       a AAAA RR from.  If that is the case, the name server synthesizes
+       a AAAA record from the A RR and the prefix 2001:DB8::/96.  The
+       IPv6 address in the AAAA record is 2001:DB8::192.0.2.1.
+
+   4.  H1 receives the synthetic AAAA record and sends a packet towards
+       H2.  The packet is sent to the destination address 2001:DB8::
+       192.0.2.1.
+
+   5.  The packet is routed through the IPv6 Internet to the IPv6
+       interface of the IPv6/IPv4 translator and the communication flows
+       using the IPv6/IPv4 translator mechanisms.
+
+
+8.  Security Considerations
+
+   See the discussion on the usage of DNSSEC and DNS64 described in
+   section 3, section 5.5, and section 6.2. .
+
+
+9.  IANA Considerations
+
+   This memo makes no request of IANA.
+
+
+10.  Contributors
+
+      Dave Thaler
+
+      Microsoft
+
+      dthaler@windows.microsoft.com
+
+
+11.  Acknowledgements
+
+   This draft contains the result of discussions involving many people,
+   including the participants of the IETF BEHAVE Working Group.  The
+   following IETF participants made specific contributions to parts of
+   the text, and their help is gratefully acknowledged: Mark Andrews,
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 25]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Doug Barton,
+   Marc Blanchet, Cameron Byrne, Brian Carpenter, Hui Deng, Francis
+   Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter Koch, Suresh Krishnan,
+   Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata,
+   Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark
+   Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Florian
+   Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui.
+
+   Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
+   Trilogy, a research project supported by the European Commission
+   under its Seventh Framework Program.
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+   [I-D.ietf-behave-address-format]
+              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
+              draft-ietf-behave-address-format-04 (work in progress),
+              January 2010.
+
+12.2.  Informative References
+
+   [I-D.ietf-behave-v6v4-xlate-stateful]
+              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers",
+              draft-ietf-behave-v6v4-xlate-stateful-08 (work in
+              progress), January 2010.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 26]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   [RFC3484]  Draves, R., "Default Address Selection for Internet
+              Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
+              Address Translator - Protocol Translator (NAT-PT) to
+              Historic Status", RFC 4966, July 2007.
+
+   [RFC5735]  Cotton, M. and L. Vegoda, "iSpecial Use IPv4 Addresses",
+              BCP 153, RFC 5735, January 2010.
+
+   [I-D.ietf-behave-v6v4-framework]
+              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation",
+              draft-ietf-behave-v6v4-framework-06 (work in progress),
+              February 2010.
+
+   [I-D.venaas-behave-mcast46]
+              Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
+              IPv4 - IPv6 multicast translator",
+              draft-venaas-behave-mcast46-01 (work in progress),
+              July 2009.
+
+   [I-D.ietf-dnsop-default-local-zones]
+              Andrews, M., "Locally-served DNS Zones",
+              draft-ietf-dnsop-default-local-zones-09 (work in
+              progress), November 2009.
+
+   [I-D.savolainen-mif-dns-server-selection]
+              Savolainen, T., "DNS Server Selection on Multi-Homed
+              Hosts", draft-savolainen-mif-dns-server-selection-01 (work
+              in progress), October 2009.
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 27]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+Appendix A.  Motivations and Implications of synthesizing AAAA RR when
+             real AAAA RR exists
+
+   The motivation for synthesizing AAAA RRs when a real AAAA RRs exist
+   is to support the following scenario:
+
+      An IPv4-only server application (e.g. web server software) is
+      running on a dual-stack host.  There may also be dual-stack server
+      applications also running on the same host.  That host has fully
+      routable IPv4 and IPv6 addresses and hence the authoritative DNS
+      server has an A and a AAAA record as a result.
+
+      An IPv6-only client (regardless of whether the client application
+      is IPv6-only, the client stack is IPv6-only, or it only has an
+      IPv6 address) wants to access the above server.
+
+      The client issues a DNS query to a DNS64 resolver.
+
+   If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
+   then the communication will fail.  Even though there's a real AAAA,
+   the only way for communication to succeed is with the translated
+   address.  So, in order to support this scenario, the administrator of
+   a DNS64 service may want to enable the synthesis of AAAA RRs even
+   when real AAAA RRs exist.
+
+   The implication of including synthetic AAAA RR when real AAAA RR
+   exist is that translated connectivity may be preferred over native
+   connectivity in some cases where the DNS64 is operated in DNS server
+   mode.
+
+   RFC3484 [RFC3484] rules use longest prefix match to select the
+   preferred destination address to use.  So, if the DNS64 resolver
+   returns both the synthetic AAAA RRs and the real AAAA RRs, then if
+   the DNS64 is operated by the same domain as the initiating host, and
+   a global unicast prefix (called an NSP in
+   [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR
+   is likely to be preferred.
+
+   This means that without further configuration:
+
+      In "An IPv6 network to the IPv4 Internet" scenario , the host will
+      prefer translated connectivity if an NSP is used.  If the Well-
+      Known Prefix defined in [I-D.ietf-behave-address-format] is used,
+      it will probably prefer native connectivity.
+
+      In the "IPv6 Internet to an IPv4 network" scenario, it is possible
+      to bias the selection towards the real AAAA RR if the DNS64
+      resolver returns the real AAAA first in the DNS reply, when an NSP
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 28]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+      is used (the Well-Known Prefix usage is not supported in this
+      case)
+
+      In "an IPv6 network to IPv4 network" scenario, for local
+      destinations (i.e., target hosts inside the local site), it is
+      likely that the NSP and the destination prefix are the same, so we
+      can use the order of RR in the DNS reply to bias the selection
+      through native connectivity.  If the Well-Known Prefix is used,
+      the longest prefix match rule will select native connectivity.
+
+   So this option introduces problems in the following cases:
+
+      An IPv6 network to the IPv4 internet with an NSP
+
+      IPv6 to IPv4 in the same network when reaching external
+      destinations and an NSP is used.
+
+   In any case, the problem can be solved by properly configuring the
+   RFC3484 [RFC3484] policy table, but this requires effort on the part
+   of the site operator.
+
+
+Authors' Addresses
+
+   Marcelo Bagnulo
+   UC3M
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34-91-6249500
+   Fax:
+   Email: marcelo@it.uc3m.es
+   URI:   http://www.it.uc3m.es/marcelo
+
+
+   Andrew Sullivan
+   Shinkuro
+   4922 Fairmont Avenue, Suite 250
+   Bethesda, MD  20814
+   USA
+
+   Phone: +1 301 961 3131
+   Email: ajs@shinkuro.com
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 29]
+
+Internet-Draft                    DNS64                    February 2010
+
+
+   Philip Matthews
+   Unaffiliated
+   600 March Road
+   Ottawa, Ontario
+   Canada
+
+   Phone: +1 613-592-4343 x224
+   Fax:
+   Email: philip_matthews@magma.ca
+   URI:
+
+
+   Iljitsch van Beijnum
+   IMDEA Networks
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34-91-6246245
+   Email: iljitsch@muada.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bagnulo, et al.          Expires August 19, 2010               [Page 30]
+
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt
deleted file mode 100644
index b0a269b1113d..000000000000
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt
+++ /dev/null
@@ -1,1579 +0,0 @@
-
-
-
-
-
-DNS Extensions Working Group                                Edward Lewis
-Internet-Draft                                             NeuStar, Inc.
-Updates: 1034, 1035 (if approved)                              A. Hoenes
-Intended status: Standards Track                                  TR-Sys
-Expires: June  6, 2010                                 December  6, 2009
-
-
-                    DNS Zone Transfer Protocol (AXFR)
-                    draft-ietf-dnsext-axfr-clarify-12
-
-Abstract
-
-   The Domain Name System standard mechanisms for maintaining coherent
-   servers for a zone consist of three elements.  One mechanism is the
-   Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
-   The definition of AXFR has proven insufficient in detail, thereby
-   forcing implementations intended to be compliant to make assumptions,
-   impeding interoperability.  Yet today we have a satisfactory set of
-   implementations that do interoperate.  This document is a new
-   definition of AXFR -- new in the sense that is it recording an
-   accurate definition of an interoperable AXFR mechanism.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79. This document may contain material
-   from IETF Documents or IETF Contributions published or made publicly
-   available before November 10, 2008.  The person(s) controlling the
-   copyright in some of this material may not have granted the IETF
-   Trust the right to allow modifications of such material outside the
-   IETF Standards Process.  Without obtaining an adequate license from
-   the person(s) controlling the copyright in such materials, this
-   document may not be modified outside the IETF Standards Process, and
-   derivative works of it may not be created outside the IETF Standards
-   Process, except to format it for publication as an RFC or to
-   translate it into languages other than English.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress".
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 1]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   This Internet-Draft will expire on June 6, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 2]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
-   1.1.  Definition of Terms  . . . . . . . . . . . . . . . . . . .  4
-   1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   1.3.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   1.4.  Coverage and Relationship to Original AXFR Specification .  5
-   2.  AXFR Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.1.  AXFR query . . . . . . . . . . . . . . . . . . . . . . . .  8
-   2.1.1.  Header Values  . . . . . . . . . . . . . . . . . . . . .  9
-   2.1.2.  Question Section . . . . . . . . . . . . . . . . . . . . 10
-   2.1.3.  Answer Section . . . . . . . . . . . . . . . . . . . . . 10
-   2.1.4.  Authority Section  . . . . . . . . . . . . . . . . . . . 10
-   2.1.5.  Additional Section . . . . . . . . . . . . . . . . . . . 10
-   2.2.  AXFR Response  . . . . . . . . . . . . . . . . . . . . . . 11
-   2.2.1.  "0 Message" Response . . . . . . . . . . . . . . . . . . 11
-   2.2.2.  Header Values  . . . . . . . . . . . . . . . . . . . . . 12
-   2.2.3.  Question Section . . . . . . . . . . . . . . . . . . . . 14
-   2.2.4.  Answer Section . . . . . . . . . . . . . . . . . . . . . 14
-   2.2.5.  Authority Section  . . . . . . . . . . . . . . . . . . . 14
-   2.2.6.  Additional Section . . . . . . . . . . . . . . . . . . . 14
-   2.3.  TCP Connection Aborts  . . . . . . . . . . . . . . . . . . 14
-   3.  Zone Contents  . . . . . . . . . . . . . . . . . . . . . . . 15
-   3.1.  Records to Include . . . . . . . . . . . . . . . . . . . . 15
-   3.2.  Delegation Records . . . . . . . . . . . . . . . . . . . . 16
-   3.3.  Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18
-   3.4.  Name Compression . . . . . . . . . . . . . . . . . . . . . 18
-   3.5.  Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19
-   4.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . 19
-   4.1.  TCP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-   4.1.1.  AXFR client TCP  . . . . . . . . . . . . . . . . . . . . 20
-   4.1.2.  AXFR server TCP  . . . . . . . . . . . . . . . . . . . . 21
-   4.2.  UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-   5.  Authorization  . . . . . . . . . . . . . . . . . . . . . . . 22
-   6.  Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
-   7.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . 24
-   7.1.  Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-   7.2.  Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . 25
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
-   10.  Internationalization Considerations . . . . . . . . . . . . 25
-   11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
-   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 25
-   12.1.  Normative References  . . . . . . . . . . . . . . . . . . 26
-   12.2.  Informative References  . . . . . . . . . . . . . . . . . 27
-   13.  Editor's Address  . . . . . . . . . . . . . . . . . . . . . 28
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 3]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-1.  Introduction
-
-   The Domain Name System standard facilities for maintaining coherent
-   servers for a zone consist of three elements.  Authoritative Transfer
-   (AXFR) is defined in "Domain Names - Concepts and Facilities"
-   [RFC1034] (referred to in this document as RFC 1034) and "Domain
-   Names - Implementation and Specification" [RFC1035] (henceforth
-   RFC 1035).  Incremental Zone Transfer (IXFR) is defined in
-   "Incremental Zone Transfer in DNS" [RFC1995].  A mechanism for prompt
-   notification of zone changes (NOTIFY) is defined in "A Mechanism for
-   Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996].  The
-   goal of these mechanisms is to enable a set of DNS name servers to
-   remain coherently authoritative for a given zone.
-
-   This document re-specifies the AXFR mechanism as it is deployed in
-   the Internet at large, hopefully with the precision expected from
-   modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
-
-1.1.  Definition of Terms
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in "Key words for use in
-   RFCs to Indicate Requirement Levels" [BCP14].
-
-   Use of "newer"/"new" and "older"/"old" DNS refers to implementations
-   written after and prior to the publication of this document.
-
-   "General purpose DNS implementation" refers to DNS software developed
-   for wide-spread use.  This includes resolvers and servers freely
-   accessible as libraries and standalone processes.  This also includes
-   proprietary implementations used only in support of DNS service
-   offerings.
-
-   "Turnkey DNS implementation" refers to custom made, single use
-   implementations of DNS.  Such implementations consist of software
-   that employs the DNS protocol message format yet does not conform to
-   the entire range of DNS functionality.
-
-   The terms "AXFR session", "AXFR server" and "AXFR client" will be
-   introduced in the first paragraph of Section 2, after some more
-   context has been established.
-
-1.2.  Scope
-
-   In general terms, authoritative name servers for a given zone can use
-   various means to achieve coherency of the zone contents they serve.
-   For example, there are DNS implementations that assemble answers from
-   data stored in relational databases (as opposed to master files),
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 4]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   relying on the database's non-DNS means to synchronize the database
-   instances.  Some of these non-DNS solutions interoperate in some
-   fashion.  However, AXFR, IXFR, and NOTIFY are the only protocol-
-   defined in-band mechanisms to provide coherence of a set of name
-   servers, and they are the only mechanisms specified by the IETF.
-
-   This document does not cover incoherent DNS situations.  There are
-   applications of the DNS in which servers for a zone are designed to
-   be incoherent.  For these configurations, a coherency mechanism as
-   described here would be unsuitable.
-
-   A DNS implementation is not required to support AXFR, IXFR, and
-   NOTIFY, but it should have some means for maintaining name server
-   coherency.  A general purpose DNS implementation will likely support
-   AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
-   implementations may exist without AXFR.
-
-1.3.  Context
-
-   Besides describing the mechanisms themselves, there is the context in
-   which they operate to consider.  In the initial specifications of
-   AXFR (and IXFR and NOTIFY), little consideration was given to
-   security and privacy issues.  Since the original definition of AXFR,
-   new opinions have appeared on the access to an entire zone's
-   contents.  In this document, the basic mechanisms will be discussed
-   separately from the permission to use these mechanisms.
-
-1.4.  Coverage and Relationship to Original AXFR Specification
-
-   This document concentrates on just the definition of AXFR.  Any
-   effort to update the specification of the IXFR or NOTIFY mechanisms
-   is left to different documents.
-
-   The original "specification" of the AXFR sub-protocol is scattered
-   through RFC 1034 and RFC 1035.  Section 2.2 of RFC 1035 (on page 5)
-   depicts the scenario for which AXFR has been designed.  Section 4.3.5
-   of RFC 1034 describes the zone synchronization strategies in general
-   and rules for the invocation of a full zone transfer via AXFR; the
-   fifth paragraph of that section contains a very short sketch of the
-   AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
-   flaw in that specification.  Section 3.2.3 of RFC 1035 has assigned
-   the code point for the AXFR QTYPE (see Section 2.1.2 below for more
-   details).  Section 4.2 of RFC 1035 discusses the transport layer use
-   of DNS and shortly explains why UDP transport is deemed inappropriate
-   for AXFR; the last paragraph of Section 4.2.2 gives details for the
-   TCP connection management with AXFR.  Finally, the second paragraph
-   of Section 6.3 in RFC 1035 mandates server behavior when zone data
-   changes occur during an ongoing zone transfer using AXFR.
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 5]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   This document will update the specification of AXFR.  To this end, it
-   fully specifies the record formats and processing rules for AXFR,
-   largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
-   details the transport considerations for AXFR, thus amending Section
-   4.2.2 of RFC 1035.  Furthermore, it discusses backward compatibility
-   issues and provides policy/management considerations as well as
-   specific Security Considerations for AXFR.  The goal of this document
-   is to define AXFR as it exists, or is supposed to exist, currently.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 6]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-2.  AXFR Messages
-
-   An AXFR session consists of an AXFR query message and the sequence of
-   AXFR response messages returned for it.  In this document, the AXFR
-   client is the sender of the AXFR query and the AXFR server is the
-   responder.  (Use of terms such as master, slave, primary, secondary
-   are not important to defining AXFR.)  The use of the word "session"
-   without qualification refers to an AXFR session.
-
-   An important aspect to keep in mind is that the definition of AXFR is
-   restricted to TCP [RFC0793].  The design of the AXFR process has
-   certain inherent features that are not easily ported to UDP
-   [RFC0768].
-
-   The basic format of an AXFR message is the DNS message as defined in
-   Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
-   following documents.
-
-   o  The 'Basic' DNS specification:
-
-   -  "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)"
-       [RFC1996]
-   -  "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
-   -  "Clarifications to the DNS Specification" [RFC2181]
-   -  "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
-   -  "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
-   -  "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
-   -  "Obsoleting IQUERY" [RFC3425]
-   -  "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
-   -  "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
-   -  "Domain Name System (DNS) IANA Considerations" [RFC5395]
-
-   o  Further additions related to the DNS Security Extensions (DNSSEC),
-      defined in these base documents:
-
-   -  "DNS Security Introduction and Requirements" [RFC4033]
-   -  "Resource Records for the DNS Security Extensions" [RFC4034]
-   -  "Protocol Modifications for the DNS Security Extensions" [RFC4035]
-   -  "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
-   -  "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
-   -  "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
-       Records for DNSSEC" [RFC5702]
-   -  "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
-
-   These documents contain information about the syntax and semantics of
-   DNS messages.  They ought not interfere with AXFR but are also
-   helpful in understanding what will be carried via AXFR.
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 7]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   For convenience, the synopsis of the DNS message header from
-   [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
-   reproduced here informally:
-
-                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                      ID                       |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |QR|   OpCode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                QDCOUNT/ZOCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                ANCOUNT/PRCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                NSCOUNT/UPCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                    ARCOUNT                    |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   This document makes use of the field names as they appear in this
-   diagram.  The names of sections in the body of DNS messages are
-   capitalized in this document for clarity, e.g., "Additional section".
-
-   The DNS message size limit from [RFC1035] for DNS over UDP (and its
-   extension via the EDNS0 mechanism specified in [RFC2671]) is not
-   relevant for AXFR, as explained in Section 4.  The upper limit on the
-   permissible size of a DNS message over TCP is only restricted by the
-   TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
-   two-octet message length field, understood to be unsigned, and thus
-   causing a limit of 65535 octets.  This limit is not changed by EDNS0.
-
-   Note that the TC (truncation) bit is never set by an AXFR server nor
-   considered/read by an AXFR client.
-
-2.1.  AXFR query
-
-   An AXFR query is sent by a client whenever there is a reason to ask.
-   This might be because of scheduled or triggered zone maintenance
-   activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
-   respectively) or as a result of a command line request, say for
-   debugging.
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 8]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-2.1.1.  Header Values
-
-   These are the DNS message header values for an AXFR query.
-
-      ID          Selected by client; see Note a)
-
-      QR          MUST be 0 (Query)
-
-      OPCODE      MUST be 0 (Standard Query)
-
-      Flags:
-         AA       'n/a' -- see Note b)
-         TC       'n/a' -- see Note b)
-         RD       'n/a' -- see Note b)
-         RA       'n/a' -- see Note b)
-         Z        'mbz' -- see Note c)
-         AD       'n/a' -- see Note b)
-         CD       'n/a' -- see Note b)
-
-      RCODE       MUST be 0 (No error)
-
-      QDCOUNT     Number of entries in Question section;   MUST be 1
-
-      ANCOUNT     Number of entries in Answer section;     MUST be 0
-
-      NSCOUNT     Number of entries in Authority section;  MUST be 0
-
-      ARCOUNT     Number of entries in Additional section -- see Note d)
-
-   Notes:
-
-   a) Set to any value that the client is not already using with the
-      same server.  There is no specific means for selecting the value
-      in this field.  (Recall that AXFR is done only via TCP connections
-      -- see Section 4 "Transport".)
-
-      A server MUST reply using messages that use the same message ID to
-      allow a client to have multiple queries outstanding concurrently
-      over the same TCP connection -- see Note a) in Section 2.2.2 for
-      more details.
-
-   b) 'n/a' -- The value in this field has no meaning in the context of
-      AXFR query messages.  For the client, it is RECOMMENDED that the
-      value be zero.  The server MUST ignore this value.
-
-   c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
-      it.
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                 [Page 9]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   d) The client MUST set this field to the number of resource records
-      appearing in the Additional section.  See Section 2.1.5
-      "Additional Section" for details.
-
-      The value MAY be 0, 1 or 2.  If it is 2, the Additional section
-      MUST contain both an EDNS0 [RFC2671] OPT resource record and a
-      record carrying transaction integrity and authentication data,
-      currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931].  If the
-      value is 1, then the Additional section MUST contain either only
-      an EDNS0 OPT resource record or a record carrying transaction
-      integrity and authentication data.  If the value is 0, the
-      Additional section MUST be empty.
-
-2.1.2.  Question Section
-
-   The Query section of the AXFR query MUST conform to Section 4.1.2 of
-   RFC 1035, and contain a single resource record with the following
-   values:
-
-      QNAME       the name of the zone requested
-
-      QTYPE       AXFR (= 252), the pseudo-RR type for zone transfer
-                  [DNSVALS]
-
-      QCLASS      the class of the zone requested [DNSVALS]
-
-2.1.3.  Answer Section
-
-   The Answer section MUST be empty.
-
-2.1.4.  Authority Section
-
-   The Authority section MUST be empty.
-
-2.1.5.  Additional Section
-
-   The client MAY include an EDNS0 OPT [RFC2671] resource record.  If
-   the server does not support EDNS0, the client MUST send this section
-   without an EDNS0 OPT resource record if there is a retry.  However,
-   the protocol does not define an explicit indication that the server
-   does not support EDNS0; that needs to be inferred by the client.
-   Often, the server will return a FormErr(1) which might be related to
-   the OPT resource record.
-
-   The client MAY include a transaction integrity and authentication
-   resource record, currently a choice of TSIG [RFC2845] or SIG(0)
-   [RFC2931].  If the server has indicated that it does not recognize
-   the resource record, and that the error is indeed caused by the
-   resource record, the client probably should not try again.  Removing
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 10]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   the security data in the face of an obstacle ought to only be done
-   with full awareness of the implication of doing so.
-
-   In general, if an AXFR client is aware that an AXFR server does not
-   support a particular mechanism, the client SHOULD NOT attempt to
-   engage the server using the mechanism (or at all).  A client could
-   become aware of a server's abilities via a configuration setting or
-   via some other (as yet) undefined means.
-
-   The range of permissible resource records that MAY appear in the
-   Additional section might change over time.  If either a change to an
-   existing resource record (like the OPT RR for EDNS0) is made or a new
-   Additional section record is created, the new definitions ought to
-   include a discussion on the impact upon AXFR.  Future resource
-   records residing in the Additional section might have an effect that
-   is orthogonal to AXFR, so can ride through the session as opaque
-   data.  In this case, a "wise" implementation ought to be able to pass
-   these records through without disruption.
-
-2.2.  AXFR Response
-
-   The AXFR response will consist of 0 or more messages.  A "0 message"
-   response is covered in Section 2.2.1.
-
-   An AXFR response that is transferring the zone's contents will
-   consist of a series (which could be a series of length 1) of DNS
-   messages.  In such a series, the first message MUST begin with the
-   SOA resource record of the zone, the last message MUST conclude with
-   the same SOA resource record.  Intermediate messages MUST NOT contain
-   the SOA resource record.  The AXFR server MUST copy the Question
-   section from the corresponding AXFR query message in to the first
-   response message's Question section.  Subsequent messages MAY do the
-   same or contain an empty Question section.
-
-   An AXFR response indicates an error via a single DNS message with the
-   return code set to the appropriate value for the condition
-   encountered, sent once the error condition is detected.  Such a
-   message terminates the AXFR session; it MUST copy the Query Section
-   from the AXFR query into its Query Section, but the inclusion of the
-   terminating SOA resource record is not necessary.
-
-   An AXFR server may send a number of AXFR response messages free of an
-   error condition before it sends the message indicating an error.
-
-2.2.1.  "0 Message" Response
-
-   A legitimate "0 message" response, i.e., the client sees no response
-   whatsoever, is very exceptional and controversial.  Unquestionably it
-   is unhealthy for there to be 0 responses in a protocol that is
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 11]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   designed around a query - response paradigm over an unreliable
-   transport.  The lack of a response could be a sign of underlying
-   network problems and cause the protocol state machine to react
-   accordingly.  However, AXFR uses TCP and not UDP, eliminating
-   undetectable network errors.
-
-   A "0 message response" is reserved for situations in which the server
-   has a reason to suspect that the query is sent for the purpose of
-   abuse.  Due to the use of this being so controversial, a "0 message
-   response" is not being defined as a legitimate part of the protocol
-   but the use of it is being acknowledged as a warning to AXFR client
-   implementations.  Any earnest query has the expectation of some
-   response but nevertheless may not get one.
-
-2.2.2.  Header Values
-
-   These are the DNS message header values for AXFR responses.
-
-      ID          MUST be copied from request -- see Note a)
-
-      QR          MUST be 1 (Response)
-
-      OPCODE      MUST be 0 (Standard Query)
-
-      Flags:
-         AA       normally 1 -- see Note b)
-         TC       MUST be 0 (Not truncated)
-         RD       RECOMMENDED: copy request's value, MAY be set to 0
-         RA       SHOULD be 0 -- see Note c)
-         Z        'mbz' -- see Note d)
-         AD       covered by DNSSEC rules -- see Note e)
-         CD       covered by DNSSEC rules -- see Note e)
-
-      RCODE       See Note f)
-
-      QDCOUNT     MUST be 1 in the first message;
-                  MUST be 0 or 1 in all following messages;
-                  MUST be 1 if RCODE indicates an error
-
-      ANCOUNT     See Note g)
-
-      NSCOUNT     MUST be 0
-
-      ARCOUNT     See Note h)
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 12]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   Notes:
-
-   a) Because some old implementations behave differently than is now
-      desired, the requirement on this field is stated in detail.  New
-      DNS servers MUST set this field to the value of the AXFR query ID
-      in each AXFR response message for the session.  AXFR clients MUST
-      be able to manage sessions resulting from the issuance of multiple
-      outstanding queries, whether AXFR queries or other DNS queries.
-      A client SHOULD discard responses that do not correspond (via the
-      message ID) to any outstanding queries.
-
-      Unless the client is sure that the server will consistently set
-      the ID field to the query's ID, the client is NOT RECOMMENDED to
-      issue any other queries until the end of the zone transfer.
-      A client MAY become aware of a server's abilities via a
-      configuration setting.
-
-   b) If the RCODE is 0 (no error), then the AA bit MUST be 1.
-      For any other value of RCODE, the AA bit MUST be set according to
-      the rules for that error code.  If in doubt, it is RECOMMENDED
-      that it be set to 1.  It is RECOMMENDED that the value be ignored
-      by the AXFR client.
-
-   c) It is RECOMMENDED that the server set the value to 0, the client
-      MUST ignore this value.
-
-      The server MAY set this value according to the local policy
-      regarding recursive service, but doing so might confuse the
-      interpretation of the response as AXFR can not be retrieved
-      recursively.  A client MAY note the server's policy regarding
-      recursive service from this value, but SHOULD NOT conclude that
-      the AXFR response was obtained recursively even if the RD bit was
-      1 in the query.
-
-   d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
-      it.
-
-   e) If the implementation supports the DNS Security Extensions (DNSSEC
-      -- see Section 2), then this value MUST be set according to the
-      rules in RFC 4035, Section 3.1.6, "The AD and CD Bits in an
-      Authoritative Response".  If the implementation does not support
-      the DNS Security Extensions, then this value MUST be set to 0 and
-      MUST be ignored upon receipt.
-
-   f) In the absence of an error, the server MUST set the value of this
-      field to NoError(0).  If a server is not authoritative for the
-      queried zone, the server SHOULD set the value to NotAuth(9).
-      (Reminder, consult the appropriate IANA registry [DNSVALS].)  If a
-      client receives any other value in response, it MUST act according
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 13]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-      to the error.  For example, a malformed AXFR query or the presence
-      of an EDNS0 OPT resource record sent to an old server will garner
-      a FormErr(1) value.  This value is not set as part of the AXFR-
-      specific response processing.  The same is true for other values
-      indicating an error.
-
-   g) The count of answer records MUST equal the number of resource
-      records in the AXFR Answer Section.  When a server is aware that a
-      client will only accept one resource record per response message,
-      then the value MUST be 1.  A server MAY be made aware of a
-      client's limitations via configuration data.
-
-   h) The client MUST set this field to the number of resource records
-      appearing in the Additional section.  The considerations of Note
-      d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional
-      Section" below for more details.
-
-2.2.3.  Question Section
-
-   In the first response message, this section MUST be copied from the
-   query.  In subsequent messages, this section MAY be copied from the
-   query or it MAY be empty.  However, in an error response message (see
-   Section 2.2), this section MUST be copied as well.  The content of
-   this section MAY be used to determine the context of the message,
-   that is, the name of the zone being transferred.
-
-2.2.4.  Answer Section
-
-   MUST be populated with the zone contents.  See Section 3 below on
-   encoding zone contents.
-
-2.2.5.  Authority Section
-
-   The Authority section MUST be empty.
-
-2.2.6.  Additional Section
-
-   The contents of this section MUST follow the guidelines for EDNS0 and
-   TSIG, SIG(0), or whatever other future record is possible here.  The
-   contents of Section 2.1.5 apply analogously as well.
-
-2.3.  TCP Connection Aborts
-
-   If an AXFR client sends a query on a TCP connection and the
-   connection is closed at any point, the AXFR client MUST consider the
-   AXFR session terminated.  The message ID MAY be used again on a new
-   connection, even if the question and AXFR server are the same.
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 14]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   Facing a dropped connection, a client SHOULD try to make some
-   determination whether the connection closure was the result of
-   network activity or a decision by the AXFR server.  This
-   determination is not an exact science.  It is up to the AXFR client
-   implementor to react, but the reaction SHOULD NOT be an endless cycle
-   of retries nor an increasing (in frequency) retry rate.
-
-   An AXFR server implementor SHOULD take into consideration the dilemma
-   described above when a connection is closed with an outstanding query
-   in the pipeline.  For this reason, a server ought to reserve this
-   course of action for situations in which it believes beyond a doubt
-   that the AXFR client is attempting abusive behavior.
-
-
-3.  Zone Contents
-
-   The objective of the AXFR session is to request and transfer the
-   contents of a zone.  The objective is to permit the AXFR client to
-   reconstruct the zone as it exists at the server for the given zone
-   serial number.  Over time the definition of a zone has evolved from
-   denoting a static set of records to also cover a dynamically updated
-   set of records, and then a potentially continually regenerated set of
-   records (e.g., RRs synthesized "on the fly" from rule sets or
-   database lookup results in other forms than RR format) as well.
-
-3.1.  Records to Include
-
-   In the Answer section of AXFR response messages the resource records
-   within a zone for the given serial number MUST appear.  The
-   definition of what belongs in a zone is described in RFC 1034,
-   Section 4.2, "How the database is divided into zones" (in particular
-   Section 4.2.1, "Technical considerations"), and it has been clarified
-   in Section 6 of RFC 2181.
-
-   Unless the AXFR server knows that the AXFR client is old and expects
-   just one resource record per AXFR response message, an AXFR server
-   SHOULD populate an AXFR response message with as many complete
-   resource record sets as will fit within a DNS message.
-
-   Zones for which it is impractical to list the entire zone for a
-   serial number are not suitable for AXFR retrieval.  A typical (but
-   not limiting) description of such a zone is a zone consisting of
-   responses generated via other database lookups and/or computed based
-   upon ever changing data.
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 15]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-3.2.  Delegation Records
-
-   In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
-   the "should" in the quotation predates [BCP14], cf. Section 1.1):
-
-      "The RRs that describe cuts ... should be exactly the same as the
-       corresponding RRs in the top node of the subzone."
-
-   There has been some controversy over this statement and the impact on
-   which NS resource records are included in a zone transfer.
-
-   The phrase "that describe cuts" is a reference to the NS set and
-   applicable glue records.  It does not mean that the cut point and
-   apex resource records are identical.  For example, the SOA resource
-   record is only found at the apex.  The discussion here is restricted
-   to just the NS resource record set and glue as these "describe cuts".
-
-   DNSSEC resource records have special specifications regarding their
-   occurrence at a zone cut and the apex of a zone.  This was first
-   described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
-   specification of DNSSEC), which parts of RFC 2181 now in fact are
-   historical.  The current DNSSEC core document set (see Note e) in
-   Section 2.2.2 above) gives the full details for DNSSEC(bis) resource
-   record placement, and Section 3.1.5 of RFC 4035 normatively specifies
-   their treatment during AXFR; the alternate NSEC3 resource record
-   defined later in RFC 5155 behaves identically as the NSEC RR, for the
-   purpose of AXFR.
-
-   Informally:
-
-   o  The DS RRSet only occurs at the parental side of a zone cut and is
-      authoritative data in the parent zone, not the secure child zone.
-
-   o  The DNSKEY RRSet only occurs at the APEX of a signed zone and is
-      part of the authoritative data of the zone it serves.
-
-   o  Independent RRSIG RRSets occur at the signed parent side of a zone
-      cut and at the apex of a signed zone; they are authoritative data
-      in the respective zone; simple queries for RRSIG resource records
-      may return both RRSets at once if the same server is authoritative
-      for the parent zone and the child zone (Section 3.1.5 of RFC 4035
-      describes how to distinguish these RRs); this seeming ambiguity
-      does not occur for AXFR, since each such RRSIG RRset belongs to a
-      single zone.
-
-   o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
-      equally may occur at the parental side of a zone cut and at the
-      apex of a zone; each such resource record belongs to exactly one
-      of these zones and is to be included in the AXFR of that zone.
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 16]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   One issue is that in operations there are times when the NS resource
-   records for a zone might be different at a cut point in the parent
-   and at the apex of a zone.  Sometimes this is the result of an error
-   and sometimes it is part of an ongoing change in name servers.  The
-   DNS protocol is robust enough to overcome inconsistencies up to (but
-   not including) there being no parent indicated NS resource record
-   referencing a server that is able to serve the child zone.  This
-   robustness is one quality that has fueled the success of the DNS.
-   Still, the inconsistency is an error state and steps need to be taken
-   to make it apparent (if it is unplanned) and to make it clear once
-   the inconsistency has been removed.
-
-   Another issue is that the AXFR server could be authoritative for a
-   different set of zones than the AXFR client.  It is possible that the
-   AXFR server be authoritative for both halves of an inconsistent cut
-   point and that the AXFR client is authoritative for just the parent
-   side of the cut point.
-
-   When facing a situation in which a cut point's NS resource records do
-   not match the authoritative set, the question arises whether an AXFR
-   server responds with the NS resource record set that is in the zone
-   being transferred or the one that is at the authoritative location.
-
-   The AXFR response MUST contain the cut point NS resource record set
-   registered with the zone whether it agrees with the authoritative set
-   or not.  "Registered with" can be widely interpreted to include data
-   residing in the zone file of the zone for the particular serial
-   number (in zone file environments) or as any data configured to be in
-   the zone (database), statically or dynamically.
-
-   The reasons for this requirement are:
-
-   1) The AXFR server might not be able to determine that there is an
-   inconsistency given local data, hence requiring consistency would
-   mean a lot more needed work and even network retrieval of data.  An
-   authoritative server ought not be required to perform any queries.
-
-   2) By transferring the inconsistent NS resource records from a server
-   that is authoritative for both the cut point and the apex to a client
-   that is not authoritative for both, the error is exposed.  For
-   example, an authorized administrator can manually request the AXFR
-   and inspect the results to see the inconsistent records.  (A server
-   authoritative for both halves would otherwise always answer from the
-   more authoritative set, concealing the error.)
-
-   3) The inconsistent NS resource record set might indicate a problem
-   in a registration database.
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 17]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   4) This requirement is necessary to ensure that retrieving a given
-   (zone,serial) pair by AXFR yields the exact same set of resource
-   records no matter which of the zone's authoritative servers is chosen
-   as the source of the transfer.
-
-   If an AXFR server were allowed to respond with the authoritative NS
-   RRset of a child zone instead of a glue NS RRset in the zone being
-   transferred, the set of records returned could vary depending on
-   whether or not the server happens to be authoritative for the child
-   zone as well.
-
-   The property that a given (zone,serial) pair corresponds to a single,
-   well-defined set of records is necessary for the correct operation of
-   incremental transfer protocols such as IXFR [RFC1995].  For example,
-   a client may retrieve a zone by AXFR from one server, and then apply
-   an incremental change obtained by IXFR from a different server.  If
-   the two servers have different ideas of the zone contents, the client
-   can end up attempting to incrementally add records that already exist
-   or to delete records that do not exist.
-
-3.3.  Glue Records
-
-   As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
-   guidance and rationale for the inclusion of glue records as part of
-   an AXFR transfer.  And, as also argued in the previous section of
-   this document, even when there is an inconsistency between the
-   address in a glue record and the authoritative copy of the name
-   server's address, the glue resource record that is registered as part
-   of the zone for that serial number is to be included.
-
-   This applies to glue records for any address family [IANA-AF].
-
-   The AXFR response MUST contain the appropriate glue records as
-   registered with the zone.  The interpretation of "registered with" in
-   the previous section applies here.  Inconsistent glue records are an
-   operational matter.
-
-3.4.  Name Compression
-
-   Compression of names in DNS messages is described in RFC 1035,
-   Section 4.1.4, "Message compression".  The issue highlighted here
-   relates to a comment made in RFC 1034, Section 3.1, "Name space
-   specifications and terminology" which says "When you receive a domain
-   name or label, you should preserve its case."  ("Should" in the quote
-   predates [BCP14].)
-
-   Name compression in an AXFR message MUST preserve the case of the
-   original domain name.  That is, although when comparing a domain
-   name, "a" equals "A", when comparing for the purposes of message
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 18]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   compression, "a" is not equal to "A".  Note that this is not the
-   usual definition of name comparison in the DNS protocol and
-   represents a new requirement on AXFR servers.
-
-   Rules governing name compression of RDATA in an AXFR message MUST
-   abide by the specification in "Handling of Unknown DNS Resource
-   Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
-   Compression".
-
-3.5.  Occluded Names
-
-   Dynamic Update [RFC2136] operations, and in particular its
-   interaction with DNAME [RFC2672], can have a side effect of occluding
-   names in a zone.  The addition of a delegation point via dynamic
-   update will render all subordinate domain names to be in a limbo,
-   still part of the zone but not available to the lookup process.  The
-   addition of a DNAME resource record has the same impact.  The
-   subordinate names are said to be "occluded".
-
-   Occluded names MUST be included in AXFR responses.  An AXFR client
-   MUST be able to identify and handle occluded names.  The rationale
-   for this action is based on a speedy recovery if the dynamic update
-   operation was in error and is to be undone.
-
-
-4.  Transport
-
-   AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
-   1034 that states:  "Because accuracy is essential, TCP or some other
-   reliable protocol must be used for AXFR requests."  The restriction
-   to TCP is also mentioned in Section 6.1.3.2. of "Requirements for
-   Internet Hosts - Application and Support" [RFC1123].
-
-   The most common scenario is for an AXFR client to open a TCP
-   connection to the AXFR server, send an AXFR query, receive the AXFR
-   response, and then close the connection.  But variations of that
-   most simple scenario are legitimate and likely, in particular sending
-   a query for the zone's SOA resource record first over the same TCP
-   connection, and reusing an existing TCP connection for other queries.
-
-   Therefore, the assumption that a TCP connection is dedicated to a
-   single AXFR session is incorrect.  This wrong assumption has led to
-   implementation choices that prevent either multiple concurrent zone
-   transfers or the use of an open connection for other queries.
-
-   Since the early days of the DNS, operators who have sets of name
-   servers that are authoritative for a common set of zones found it
-   desirable to be able to have multiple concurrent zone transfers in
-   progress; this way a name server does not have to wait for one zone
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 19]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   transfer to complete before the next could begin.  RFC 1035 did not
-   exclude this possibility, but legacy implementations missed to
-   support this functionality.  The remaining presence of such legacy
-   implementations makes it necessary that new general purpose server
-   implementation still provide options for gracefull fallback to the
-   old behavior in their support of concurrent DNS transactions and AXFR
-   sessions on a single TCP connection.
-
-4.1.  TCP
-
-   In the original definition there arguably is an implicit assumption
-   (probably unintentional) that a TCP connection is used for one and
-   only one AXFR session.  This is evidenced in the lack of an explicit
-   requirement to copy the Query section and/or the message ID into
-   responses, no explicit ordering information within the AXFR response
-   messages, and the lack of an explicit notice indicating that a zone
-   transfer continues in the next message.
-
-   The guidance given below is intended to enable better performance of
-   the AXFR exchange as well as provide guidelines on interactions with
-   older software.  Better performance includes being able to multiplex
-   DNS message exchanges including zone transfer sessions.  Guidelines
-   for interacting with older software are generally applicable to new
-   AXFR clients.  In the reverse situation, older AXFR client and newer
-   AXFR server, the server ought to operate within the specification for
-   an older server.
-
-4.1.1.  AXFR client TCP
-
-   An AXFR client MAY request a connection to an AXFR server for any
-   reason.  An AXFR client SHOULD close the connection when there is no
-   apparent need to use the connection for some time period.  The AXFR
-   server ought not have to maintain idle connections, the burden of
-   connection closure ought to be on the client.  "Apparent need" for
-   the connection is a judgment for the AXFR client and the DNS client.
-   If the connection is used for multiple sessions, or if it is known
-   sessions will be coming, or if there is other query/response traffic
-   anticipated or currently on the open connection, then there is
-   "apparent need".
-
-   An AXFR client can cancel the delivery of a zone only by closing the
-   connection.  However, this action will also cancel all other
-   outstanding activity using the connection.  There is no other
-   mechanism by which an AXFR response can be cancelled.
-
-   When a TCP connection is closed remotely (relative to the client),
-   whether by the AXFR server or due to a network event, the AXFR client
-   MUST cancel all outstanding sessions and non-AXFR transactions.
-   Recovery from this situation is not straightforward.  If the
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 20]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   disruption was a spurious event, attempting to restart the connection
-   would be proper.  If the disruption was caused by a failure that
-   proved to be persistent, the AXFR client would be wise to not spend
-   too many resources trying to rebuild the connection.  Finally, if the
-   connection was dropped because of a policy at the AXFR server (as can
-   be the case with older AXFR servers), the AXFR client would be wise
-   to not retry the connection.  Unfortunately, knowing which of the
-   three cases above (momentary disruption, failure, policy) applies is
-   not possible with certainty, and can only be assessed by heuristics.
-
-   An AXFR client MAY use an already opened TCP connection to start an
-   AXFR session.  Using an existing open connection is RECOMMENDED over
-   opening a new connection.  (Non-AXFR session traffic can also use an
-   open connection.)  If in doing so the AXFR client realizes that the
-   responses cannot be properly differentiated (lack of matching query
-   IDs for example) or the connection is terminated for a remote reason,
-   then the AXFR client SHOULD NOT attempt to reuse an open connection
-   with the specific AXFR server until the AXFR server is updated (which
-   is, of course, not an event captured in the DNS protocol).
-
-4.1.2.  AXFR server TCP
-
-   An AXFR server MUST be able to handle multiple AXFR sessions on a
-   single TCP connection, as well as handle other query/response
-   transactions over it.
-
-   If a TCP connection is closed remotely, the AXFR server MUST cancel
-   all AXFR sessions in place.  No retry activity is necessary; that is
-   initiated by the AXFR client.
-
-   Local policy MAY dictate that a TCP connection is to be closed.  Such
-   an action SHOULD be in reaction to limits such as those placed on the
-   number of outstanding open connections.  Closing a connection in
-   response to a suspected security event SHOULD be done only in extreme
-   cases, when the server is certain the action is warranted.  An
-   isolated request for a zone not on the AXFR server SHOULD receive a
-   response with the appropriate return code and not see the connection
-   broken.
-
-4.2.  UDP
-
-   With the addition of EDNS0 and applications which require many small
-   zones such as in web hosting and some ENUM scenarios, AXFR sessions
-   on UDP would now seem desirable.  However, there are still some
-   aspects of AXFR sessions that are not easily translated to UDP.
-
-   Therefore, this document does not update RFC 1035 in this respect:
-   AXFR sessions over UDP transport are not defined.
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 21]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-5.  Authorization
-
-   A zone administrator has the option to restrict AXFR access to a
-   zone.  This was not envisioned in the original design of the DNS but
-   has emerged as a requirement as the DNS has evolved.  Restrictions on
-   AXFR could be for various reasons including a desire (or in some
-   instances, having a legal requirement) to keep the bulk version of
-   the zone concealed or to prevent the servers from handling the load
-   incurred in serving AXFR.  It has been argued that these reasons are
-   questionable, but this document, driven by the desire to leverage the
-   interoperable practice that has evolved since RFC 1035, acknowledges
-   the factual requirement to provide mechanisms to restrict AXFR.
-
-   A DNS implementation SHOULD provide means to restrict AXFR sessions
-   to specific clients.
-
-   An implementation SHOULD allow access to be granted to Internet
-   Protocol addresses and ranges, regardless of whether a source address
-   could be spoofed.  Combining this with techniques such as Virtual
-   Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
-   effective.
-
-   A general purpose implementation is RECOMMENDED to implement access
-   controls based upon "Secret Key Transaction Authentication for DNS"
-   [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
-   [RFC2931].
-
-   A general purpose implementation SHOULD allow access to be open to
-   all AXFR requests.  I.e., an operator ought to be able to allow any
-   AXFR query to be granted.
-
-   A general purpose implementation SHOULD NOT have a default policy for
-   AXFR requests to be "open to all".  For example, a default could be
-   to restrict transfers to addresses selected by the DNS
-   administrator(s) for zones on the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 22]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-6.  Zone Integrity
-
-   An AXFR client MUST ensure that only a successfully transferred copy
-   of the zone data can be used to serve this zone.  Previous
-   description and implementation practice have introduced a two-stage
-   model of the whole zone synchronization procedure:  Upon a trigger
-   event (e.g., polling of a SOA resource record detects change in the
-   SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is
-   initiated, whereby the zone data are saved in a zone file or data
-   base (this latter step is necessary anyway to ensure proper restart
-   of the server); upon successful completion of the AXFR operation and
-   some sanity checks, this data set is 'loaded' and made available for
-   serving the zone in an atomic operation, and flagged 'valid' for use
-   during the next restart of the DNS server; if any error is detected,
-   this data set MUST be deleted, and the AXFR client MUST continue to
-   serve the previous version of the zone, if it did before.  The
-   externally visible behavior of an AXFR client implementation MUST be
-   equivalent to that of this two-stage model.
-
-   If an AXFR client rejects data contained in an AXFR session, it
-   SHOULD remember the serial number and MAY attempt to retrieve the
-   same zone version again.  The reason the same retrieval could make
-   sense is that the reason for the rejection could be rooted in an
-   implementation detail of one AXFR server used for the zone and not
-   present in another AXFR server used for the zone.
-
-   Ensuring that an AXFR client does not accept a forged copy of a zone
-   is important to the security of a zone.  If a zone operator has the
-   opportunity, protection can be afforded via dedicated links, physical
-   or virtual via a VPN among the authoritative servers.  But there are
-   instances in which zone operators have no choice but to run AXFR
-   sessions over the global public Internet.
-
-   Besides best attempts at securing TCP connections, DNS
-   implementations SHOULD provide means to make use of "Secret Key
-   Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and
-   Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients
-   to verify the contents.  These techniques MAY also be used for
-   authorization.
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 23]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-7.  Backwards Compatibility
-
-   Describing backwards compatibility is difficult because of the lack
-   of specifics in the original definition.  In this section some hints
-   at building in backwards compatibility are given, mostly repeated
-   from the relevant earlier sections.
-
-   Backwards compatibility is not necessary, but the greater the extent
-   of an implementation's compatibility the greater its
-   interoperability.  For turnkey implementations this is not usually a
-   concern.  For general purpose implementations this takes on varying
-   levels of importance depending on the implementer's desire to
-   maintain interoperability.
-
-   It is unfortunate that a need to fall back to older behavior cannot
-   be discovered, hence needs to be noted in a configuration file.  An
-   implementation SHOULD, in its documentation, encourage operators to
-   periodically review AXFR clients and servers it has made notes about
-   repeatedly, as old software gets updated from time to time.
-
-7.1.  Server
-
-   An AXFR server has the luxury of being able to react to an AXFR
-   client's abilities with the exception of knowing whether the client
-   can accept multiple resource records per AXFR response message.  The
-   knowledge that a client is so restricted cannot be discovered, hence
-   it has to be set by configuration.
-
-   An implementation of an AXFR server MAY permit configuring, on a per
-   AXFR client basis, the necessity to revert to single resource record
-   per message; in that case, the default SHOULD be to use multiple
-   records per message.
-
-7.2.  Client
-
-   An AXFR client has the opportunity to try other features (i.e., those
-   not defined by this document) when querying an AXFR server.
-
-   Attempting to issue multiple DNS queries over a TCP transport for an
-   AXFR session SHOULD be aborted if it interrupts the original request,
-   and SHOULD take into consideration whether the AXFR server intends to
-   close the connection immediately upon completion of the original
-   (connection-causing) zone transfer.
-
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 24]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-8.  Security Considerations
-
-   Concerns regarding authorization, traffic flooding, and message
-   integrity are mentioned in "Authorization" (Section 5), "TCP"
-   (Section 4.2) and "Zone Integrity" (Section 6).
-
-
-9.  IANA Considerations
-
-   [[ Note to RFC-Ed: this section may be deleted before publication. ]]
-
-   No new registries or new registrations are included in this document.
-
-
-10.  Internationalization Considerations
-
-   The AXFR protocol is transparent to the parts of DNS zone content
-   that can possibly be subject to Internationalization considerations.
-   It is assumed that for DNS labels and domain names, the issue has
-   been solved via "Internationalizing Domain Names in Applications
-   (IDNA)" [RFC3490] or its successor(s).
-
-
-11.  Acknowledgments
-
-   Earlier editions of this document have been edited by Andreas
-   Gustafsson.  In his latest version, this acknowledgment appeared:
-
-    "Many people have contributed input and commentary to earlier
-     versions of this document, including but not limited to Bob Halley,
-     Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert
-     Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
-     Trenholme, and Brian Wellington."
-
-   Comments since the -05 version have come from these individuals:
-   Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
-   Ian Jackson, Andreas Gustafsson, Brian Wellington, and other
-   participants of the DNSEXT working group.
-
-   Edward Lewis served as a patiently listening sole document editor for
-   two years.
-
-12.  References
-
-   All "RFC" references by can be obtained from the RFC Editor web site
-   at the URLs:       http://rfc-editor.org/rfc.html
-   or                 http://rfc-editor.org/rfcsearch.html ;
-   information regarding this organization can be found at the following
-   URL:               http://rfc-editor.org/
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 25]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-12.1.  Normative References
-
-   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
-              RFC 793, September 1981.
-
-   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
-              August 1980.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
-              and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
-              Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
-              RFC 2672, August 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-              ( SIG(0)s )", RFC 2931, September 2000.
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 26]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   [RFC3425]  Lawrence, D., "Obsoleting IQUERY", RFC 3425,
-              November 2002.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006
-
-   [RFC4635]  Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
-              Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
-              RFC 4635, August 2006.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008
-
-   [RFC5395]  Eastlake 3rd, "Domain Name System (DNS) IANA
-              Considerations", BCP 42, RFC 5395, November 2008.
-
-   [RFC5702]  Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
-              and RRSIG Resource Records for DNSSEC", RFC 5702,
-              October 2009.
-
-12.2.  Informative References
-
-   [DNSVALS]  IANA Registry "Domain Name System (DNS) Parameters",
-              http://www.iana.org/assignments/dns-parameters
-
-   [IANA-AF]  IANA Registry "Address Family Numbers",
-              http://www.iana.org/assignments/Address-family-numbers/ .
-
-   [RFC2764]  Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
-              Malis, "A Framework for IP Based Virtual Private
-              Networks", RFC 2764, February 2000.
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 27]
-
-Internet-Draft      DNS Zone Transfer Protocol (AXFR)      December 2009
-
-
-   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
-              "Internationalizing Domain Names in Applications (IDNA)",
-              RFC 3490, March 2003.
-
-   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
-              Implementation Notes for DNSSECbis",
-              draft-ietf-dnsext-dnssec-bis-updates-09 (work in
-              progress), September 2009.
-
-
-13.  Editors' Addresses
-
-   Edward Lewis
-   46000 Center Oak Plaza
-   Sterling, VA, 22033, US
-
-   Email: ed.lewis@neustar.biz
-
-
-   Alfred Hoenes
-   TR-Sys
-   Gerlinger Str. 12
-   Ditzingen  D-71254
-   Germany
-
-   Email: ah@TR-Sys.de
-
-
-Editorial Note: Discussion  [[ to be removed by RFC-Editor ]]
-
-   Comments on this draft ought to be addressed to the editors and/or to
-   namedroppers@ops.ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis & Hoenes             Expires June 6, 2010                [Page 28]
-
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt
new file mode 100644
index 000000000000..935c709bcc21
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-13.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+DNS Extensions Working Group                                Edward Lewis
+Internet-Draft                                             NeuStar, Inc.
+Updates: 1034, 1035 (if approved)                         A. Hoenes, Ed.
+Intended status: Standards Track                                  TR-Sys
+Expires: July 18, 2010                                  January 18, 2010
+
+
+                    DNS Zone Transfer Protocol (AXFR)
+                    draft-ietf-dnsext-axfr-clarify-13
+
+Abstract
+
+   The Domain Name System standard mechanisms for maintaining coherent
+   servers for a zone consist of three elements.  One mechanism is the
+   Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
+   The definition of AXFR has proven insufficient in detail, thereby
+   forcing implementations intended to be compliant to make assumptions,
+   impeding interoperability.  Yet today we have a satisfactory set of
+   implementations that do interoperate.  This document is a new
+   definition of AXFR -- new in the sense that it records an accurate
+   definition of an interoperable AXFR mechanism.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79. This document may contain material
+   from IETF Documents or IETF Contributions published or made publicly
+   available before November 10, 2008.  The person(s) controlling the
+   copyright in some of this material may not have granted the IETF
+   Trust the right to allow modifications of such material outside the
+   IETF Standards Process.  Without obtaining an adequate license from
+   the person(s) controlling the copyright in such materials, this
+   document may not be modified outside the IETF Standards Process, and
+   derivative works of it may not be created outside the IETF Standards
+   Process, except to format it for publication as an RFC or to
+   translate it into languages other than English.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress".
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 1]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   This Internet-Draft will expire on July 18, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 2]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
+   1.1.  Definition of Terms  . . . . . . . . . . . . . . . . . . .  4
+   1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   1.3.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   1.4.  Coverage and Relationship to Original AXFR Specification .  5
+   2.  AXFR Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
+   2.1.  AXFR query . . . . . . . . . . . . . . . . . . . . . . . .  8
+   2.1.1.  Header Values  . . . . . . . . . . . . . . . . . . . . .  9
+   2.1.2.  Question Section . . . . . . . . . . . . . . . . . . . . 10
+   2.1.3.  Answer Section . . . . . . . . . . . . . . . . . . . . . 10
+   2.1.4.  Authority Section  . . . . . . . . . . . . . . . . . . . 10
+   2.1.5.  Additional Section . . . . . . . . . . . . . . . . . . . 10
+   2.2.  AXFR Response  . . . . . . . . . . . . . . . . . . . . . . 11
+   2.2.1.  Header Values  . . . . . . . . . . . . . . . . . . . . . 12
+   2.2.2.  Question Section . . . . . . . . . . . . . . . . . . . . 14
+   2.2.3.  Answer Section . . . . . . . . . . . . . . . . . . . . . 14
+   2.2.4.  Authority Section  . . . . . . . . . . . . . . . . . . . 14
+   2.2.5.  Additional Section . . . . . . . . . . . . . . . . . . . 14
+   2.3.  TCP Connection Aborts  . . . . . . . . . . . . . . . . . . 15
+   3.  Zone Contents  . . . . . . . . . . . . . . . . . . . . . . . 15
+   3.1.  Records to Include . . . . . . . . . . . . . . . . . . . . 15
+   3.2.  Delegation Records . . . . . . . . . . . . . . . . . . . . 16
+   3.3.  Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18
+   3.4.  Name Compression . . . . . . . . . . . . . . . . . . . . . 18
+   3.5.  Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19
+   4.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . 19
+   4.1.  TCP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   4.1.1.  AXFR client TCP  . . . . . . . . . . . . . . . . . . . . 20
+   4.1.2.  AXFR server TCP  . . . . . . . . . . . . . . . . . . . . 21
+   4.2.  UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+   5.  Authorization  . . . . . . . . . . . . . . . . . . . . . . . 22
+   6.  Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23
+   7.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . 24
+   7.1.  Server . . . . . . . . . . ..  . . . . . . . . . . . . . . 24
+   7.2.  Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . 25
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 25
+   10.  Internationalization Considerations . . . . . . . . . . . . 25
+   11.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
+   12.  References  . . . . . . . . . . . . . . . . . . . . . . . . 25
+   12.1.  Normative References  . ..  . . . . . . . . . . . . . . . 26
+   12.2.  Informative References  . . . . . . . . . . . . . . . . . 27
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 3]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+1.  Introduction
+
+   The Domain Name System standard facilities for maintaining coherent
+   servers for a zone consist of three elements.  Authoritative Transfer
+   (AXFR) is defined in "Domain Names - Concepts and Facilities"
+   [RFC1034] (referred to in this document as RFC 1034) and "Domain
+   Names - Implementation and Specification" [RFC1035] (henceforth
+   RFC 1035).  Incremental Zone Transfer (IXFR) is defined in
+   "Incremental Zone Transfer in DNS" [RFC1995].  A mechanism for prompt
+   notification of zone changes (NOTIFY) is defined in "A Mechanism for
+   Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996].  The
+   goal of these mechanisms is to enable a set of DNS name servers to
+   remain coherently authoritative for a given zone.
+
+   This document re-specifies the AXFR mechanism as it is deployed in
+   the Internet at large, hopefully with the precision expected from
+   modern Internet Standards, and thereby updates RFC 1034 and RFC 1035.
+
+1.1.  Definition of Terms
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in "Key words for use in
+   RFCs to Indicate Requirement Levels" [BCP14].
+
+   Use of "newer"/"new" and "older"/"old" DNS refers to implementations
+   written after and prior to the publication of this document.
+
+   "General purpose DNS implementation" refers to DNS software developed
+   for widespread use.  This includes resolvers and servers freely
+   accessible as libraries and standalone processes.  This also includes
+   proprietary implementations used only in support of DNS service
+   offerings.
+
+   "Turnkey DNS implementation" refers to custom made, single use
+   implementations of DNS.  Such implementations consist of software
+   that employs the DNS protocol message format yet does not conform to
+   the entire range of DNS functionality.
+
+   The terms "AXFR session", "AXFR server" and "AXFR client" will be
+   introduced in the first paragraph of Section 2, after some more
+   context has been established.
+
+1.2.  Scope
+
+   In general terms, authoritative name servers for a given zone can use
+   various means to achieve coherency of the zone contents they serve.
+   For example, there are DNS implementations that assemble answers from
+   data stored in relational databases (as opposed to master files),
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 4]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   relying on the database's non-DNS means to synchronize the database
+   instances.  Some of these non-DNS solutions interoperate in some
+   fashion.  However, AXFR, IXFR, and NOTIFY are the only protocol-
+   defined in-band mechanisms to provide coherence of a set of name
+   servers, and they are the only mechanisms specified by the IETF.
+
+   This document does not cover incoherent DNS situations.  There are
+   applications of the DNS in which servers for a zone are designed to
+   be incoherent.  For these configurations, a coherency mechanism as
+   described here would be unsuitable.
+
+   A DNS implementation is not required to support AXFR, IXFR, and
+   NOTIFY, but it should have some means for maintaining name server
+   coherency.  A general purpose DNS implementation will likely support
+   AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS
+   implementations may exist without AXFR.
+
+1.3.  Context
+
+   Besides describing the mechanisms themselves, there is the context in
+   which they operate to consider.  In the initial specifications of
+   AXFR (and IXFR and NOTIFY), little consideration was given to
+   security and privacy issues.  Since the original definition of AXFR,
+   new opinions have appeared on the access to an entire zone's
+   contents.  In this document, the basic mechanisms will be discussed
+   separately from the permission to use these mechanisms.
+
+1.4.  Coverage and Relationship to Original AXFR Specification
+
+   This document concentrates on just the definition of AXFR.  Any
+   effort to update the specification of the IXFR or NOTIFY mechanisms
+   is left to different documents.
+
+   The original "specification" of the AXFR sub-protocol is scattered
+   through RFC 1034 and RFC 1035.  Section 2.2 of RFC 1035 (on page 5)
+   depicts the scenario for which AXFR has been designed.  Section 4.3.5
+   of RFC 1034 describes the zone synchronization strategies in general
+   and rules for the invocation of a full zone transfer via AXFR; the
+   fifth paragraph of that section contains a very short sketch of the
+   AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
+   flaw in that specification.  Section 3.2.3 of RFC 1035 has assigned
+   the code point for the AXFR QTYPE (see Section 2.1.2 below for more
+   details).  Section 4.2 of RFC 1035 discusses how the DNS uses the
+   transport layer and briefly explains why UDP transport is deemed
+   inappropriate for AXFR; the last paragraph of Section 4.2.2 gives
+   details regarding TCP connection management for AXFR.  Finally, the
+   second paragraph of Section 6.3 in RFC 1035 mandates server behavior
+   when zone data changes occur during an ongoing zone transfer using
+   AXFR.
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 5]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   This document will update the specification of AXFR.  To this end, it
+   fully specifies the record formats and processing rules for AXFR,
+   largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it
+   details the transport considerations for AXFR, thus amending Section
+   4.2.2 of RFC 1035.  Furthermore, it discusses backward compatibility
+   issues and provides policy/management considerations as well as
+   specific Security Considerations for AXFR.  The goal of this document
+   is to define AXFR as it exists, or is supposed to exist, currently.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 6]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+2.  AXFR Messages
+
+   An AXFR session consists of an AXFR query message and the sequence of
+   AXFR response messages returned for it.  In this document, the AXFR
+   client is the sender of the AXFR query and the AXFR server is the
+   responder.  (Use of terms such as master, slave, primary, secondary
+   are not important for defining AXFR.)  The use of the word "session"
+   without qualification refers to an AXFR session.
+
+   An important aspect to keep in mind is that the definition of AXFR is
+   restricted to TCP [RFC0793] (see Section 4 for details).  The design
+   of the AXFR process has certain inherent features that are not easily
+   ported to UDP [RFC0768].
+
+   The basic format of an AXFR message is the DNS message as defined in
+   Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the
+   following documents.
+
+   o  The 'Basic' DNS specification:
+
+   -  "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)"
+       [RFC1996]
+   -  "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
+   -  "Clarifications to the DNS Specification" [RFC2181]
+   -  "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
+   -  "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
+   -  "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
+   -  "Obsoleting IQUERY" [RFC3425]
+   -  "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
+   -  "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
+   -  "Domain Name System (DNS) IANA Considerations" [RFC5395]
+
+   o  Further additions related to the DNS Security Extensions (DNSSEC),
+      defined in these base documents:
+
+   -  "DNS Security Introduction and Requirements" [RFC4033]
+   -  "Resource Records for the DNS Security Extensions" [RFC4034]
+   -  "Protocol Modifications for the DNS Security Extensions" [RFC4035]
+   -  "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
+   -  "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
+   -  "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
+       Records for DNSSEC" [RFC5702]
+   -  "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
+
+   These documents contain information about the syntax and semantics of
+   DNS messages.  They ought not interfere with AXFR but are also
+   helpful in understanding what will be carried via AXFR.
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 7]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   For convenience, the synopsis of the DNS message header from
+   [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is
+   reproduced here informally:
+
+                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                      ID                       |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |QR|   OpCode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                QDCOUNT/ZOCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                ANCOUNT/PRCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                NSCOUNT/UPCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                    ARCOUNT                    |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   This document makes use of the field names as they appear in this
+   diagram.  The names of sections in the body of DNS messages are
+   capitalized in this document for clarity, e.g., "Additional section".
+
+   The DNS message size limit from [RFC1035] for DNS over UDP (and its
+   extension via the EDNS0 mechanism specified in [RFC2671]) is not
+   relevant for AXFR, as explained in Section 4.  The upper limit on the
+   permissible size of a DNS message over TCP is only restricted by the
+   TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a
+   two-octet message length field, understood to be unsigned, and thus
+   causing a limit of 65535 octets.  This limit is not changed by EDNS0.
+
+   Note that the TC (truncation) bit is never set by an AXFR server nor
+   considered/read by an AXFR client.
+
+2.1.  AXFR query
+
+   An AXFR query is sent by a client whenever there is a reason to ask.
+   This might be because of scheduled or triggered zone maintenance
+   activities (see Section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
+   respectively) or as a result of a command line request, say for
+   debugging.
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 8]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+2.1.1.  Header Values
+
+   These are the DNS message header values for an AXFR query.
+
+      ID          Selected by client; see Note a)
+
+      QR          MUST be 0 (Query)
+
+      OPCODE      MUST be 0 (Standard Query)
+
+      Flags:
+         AA       'n/a' -- see Note b)
+         TC       'n/a' -- see Note b)
+         RD       'n/a' -- see Note b)
+         RA       'n/a' -- see Note b)
+         Z        'mbz' -- see Note c)
+         AD       'n/a' -- see Note b)
+         CD       'n/a' -- see Note b)
+
+      RCODE       MUST be 0 (No error)
+
+      QDCOUNT     Number of entries in Question section;   MUST be 1
+
+      ANCOUNT     Number of entries in Answer section;     MUST be 0
+
+      NSCOUNT     Number of entries in Authority section;  MUST be 0
+
+      ARCOUNT     Number of entries in Additional section -- see Note d)
+
+   Notes:
+
+   a) Set to any value that the client is not already using with the
+      same server.  There is no specific means for selecting the value
+      in this field.  (Recall that AXFR is done only via TCP connections
+      -- see Section 4 "Transport".)
+
+      A server MUST reply using messages that use the same message ID to
+      allow a client to have multiple queries outstanding concurrently
+      over the same TCP connection -- see Note a) in Section 2.2.1 for
+      more details.
+
+   b) 'n/a' -- The value in this field has no meaning in the context of
+      AXFR query messages.  For the client, it is RECOMMENDED that the
+      value be zero.  The server MUST ignore this value.
+
+   c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
+      it.
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                 [Page 9]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   d) The client MUST set this field to the number of resource records
+      it places into the Additional section.  In the absense of explicit
+      specification of new RRs to be carried in the Additional section
+      of AXFR queries, the value MAY be 0, 1 or 2.  See Section 2.1.5
+      "Additional Section" for details on the currently applicable RRs.
+
+2.1.2.  Question Section
+
+   The Question Section of the AXFR query MUST conform to Section 4.1.2
+   of RFC 1035, and contain a single resource record with the following
+   values:
+
+      QNAME       the name of the zone requested
+
+      QTYPE       AXFR (= 252), the pseudo-RR type for zone transfer
+                  [DNSVALS]
+
+      QCLASS      the class of the zone requested [DNSVALS]
+
+2.1.3.  Answer Section
+
+   The Answer section MUST be empty.
+
+2.1.4.  Authority Section
+
+   The Authority section MUST be empty.
+
+2.1.5.  Additional Section
+
+   Currently, two kinds of resource records are defined that can appear
+   in the Additional section of AXFR queries and responses: EDNS and DNS
+   transaction security.  Future specifications defining RRs that can be
+   carried in the Additional section of normal DNS transactions need to
+   explicitly describe their use with AXFR, should that be desired.
+
+   The client MAY include one EDNS0 OPT [RFC2671] resource record.  If
+   the server does not support EDNS0, the client MUST send this section
+   without an EDNS0 OPT resource record if there is a retry.  However,
+   the protocol does not define an explicit indication that the server
+   does not support EDNS0; that needs to be inferred by the client.
+   Often, the server will return a FormErr(1) which might be related to
+   the OPT resource record.  Note that, at the time of this writing,
+   only the EXTENDED-RCODE field of the EDNS0 OPT RR is meaningful in
+   the context of AXFR; future specifications of EDNS0 flags and/or
+   EDNS0 options must describe their usage in the context of AXFR, if
+   applicable.
+
+   The client MAY include one transaction integrity and authentication
+   resource record, currently a choice of TSIG [RFC2845] or SIG(0)
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 10]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   [RFC2931].  If the server has indicated that it does not recognize
+   the resource record, and that the error is indeed caused by the
+   resource record, the client probably should not try again.  Removing
+   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 applicability and impact upon AXFR.
+   Future resource records residing in the Additional section might have
+   an effect that is orthogonal to AXFR, so can ride through the session
+   as opaque data.  In this case, a "wise" implementation ought to be
+   able to pass these records through without disruption.
+
+2.2.  AXFR Response
+
+   The AXFR response will consist of one or more messages.  The special
+   case of a server closing the TCP connection without sending an AXFR
+   response is covered in section 2.3.
+
+   An AXFR response that is transferring the zone's contents will
+   consist of a series (which could be a series of length 1) of DNS
+   messages.  In such a series, the first message MUST begin with the
+   SOA resource record of the zone, the last message MUST conclude with
+   the same SOA resource record.  Intermediate messages MUST NOT contain
+   the SOA resource record.  The AXFR server MUST copy the Question
+   section from the corresponding AXFR query message into the first
+   response message's Question section.  For subsequent messages, it MAY
+   do the same or leave the Question section empty.
+
+   The AXFR protocol treats the zone contents as an unordered collection
+   (or to use the mathematical term, a "set") of RRs.  Except for the
+   requirement that the transfer must begin and end with the SOA RR,
+   there is no requirement to send the RRs in any particular order or
+   grouped into response messages in any particular way.  Although
+   servers typically do attempt to send related RRs (such as the RRs
+   forming an RRset, and the RRsets of a name) as a contiguous group or,
+   when message space allows, in the same response message, they are not
+   required to do so, and clients MUST accept any ordering and grouping
+   of the non-SOA RRs.  Each RR SHOULD be transmitted only once, and
+   AXFR clients MUST ignore any duplicate RRs received.
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 11]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   Each AXFR response message SHOULD contain a sufficient number of RRs
+   to reasonably amortize the per-message overhead, up to the largest
+   number that will fit within a DNS message (taking the required
+   content of the other sections into account, as described below).
+   Some old AXFR clients expect each response message to contain only a
+   single RR.  To interoperate with such clients, the server MAY
+   restrict response messages to a single RR.  As there is no standard
+   way to automatically detect such clients, this typically requires
+   manual configuration at the server.
+
+   To indicate an error in an AXFR response, the AXFR server sends a
+   single DNS message when the error condition is detected, with the
+   response code set to the appropriate value for the condition
+   encountered, Such a message terminates the AXFR session; it MUST
+   contain a copy of the Question section from the AXFR query in its
+   Question section, but the inclusion of the terminating SOA resource
+   record is not necessary.
+
+   An AXFR server may send a number of AXFR response messages free of an
+   error condition before it sends the message indicating an error.
+
+2.2.1.  Header Values
+
+   These are the DNS message header values for AXFR responses.
+
+      ID          MUST be copied from request -- see Note a)
+
+      QR          MUST be 1 (Response)
+
+      OPCODE      MUST be 0 (Standard Query)
+
+      Flags:
+         AA       normally 1 -- see Note b)
+         TC       MUST be 0 (Not truncated)
+         RD       RECOMMENDED: copy request's value, MAY be set to 0
+         RA       SHOULD be 0 -- see Note c)
+         Z        'mbz' -- see Note d)
+         AD       'mbz' -- see Note d)
+         CD       'mbz' -- see Note d)
+
+      RCODE       See Note e)
+
+      QDCOUNT     MUST be 1 in the first message;
+                  MUST be 0 or 1 in all following messages;
+                  MUST be 1 if RCODE indicates an error
+
+      ANCOUNT     See Note f)
+
+      NSCOUNT     MUST be 0
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 12]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+      ARCOUNT     See Note g)
+
+   Notes:
+
+   a) Because some old implementations behave differently than is now
+      desired, the requirement on this field is stated in detail.  New
+      DNS servers MUST set this field to the value of the AXFR query ID
+      in each AXFR response message for the session.  AXFR clients MUST
+      be able to manage sessions resulting from the issuance of multiple
+      outstanding queries, whether AXFR queries or other DNS queries.
+      A client SHOULD discard responses that do not correspond (via the
+      message ID) to any outstanding queries.
+
+      Unless the client is sure that the server will consistently set
+      the ID field to the query's ID, the client is NOT RECOMMENDED to
+      issue any other queries until the end of the zone transfer.
+      A client MAY become aware of a server's abilities via a
+      configuration setting.
+
+   b) If the RCODE is 0 (no error), then the AA bit MUST be 1.
+      For any other value of RCODE, the AA bit MUST be set according to
+      the rules for that error code.  If in doubt, it is RECOMMENDED
+      that it be set to 1.  It is RECOMMENDED that the value be ignored
+      by the AXFR client.
+
+   c) It is RECOMMENDED that the server set the value to 0, the client
+      MUST ignore this value.
+
+      The server MAY set this value according to the local policy
+      regarding recursive service, but doing so might confuse the
+      interpretation of the response as AXFR can not be retrieved
+      recursively.  A client MAY note the server's policy regarding
+      recursive service from this value, but SHOULD NOT conclude that
+      the AXFR response was obtained recursively even if the RD bit was
+      1 in the query.
+
+   d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore
+      it.
+
+   e) In the absence of an error, the server MUST set the value of this
+      field to NoError(0).  If a server is not authoritative for the
+      queried zone, the server SHOULD set the value to NotAuth(9).
+      (Reminder, consult the appropriate IANA registry [DNSVALS].)  If a
+      client receives any other value in response, it MUST act according
+      to the error.  For example, a malformed AXFR query or the presence
+      of an EDNS0 OPT resource record sent to an old server will result
+      in a FormErr(1) value.  This value is not set as part of the AXFR-
+      specific response processing.  The same is true for other values
+      indicating an error.
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 13]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   f) 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 response messages with a single resource
+      record, then the value MUST be 1.  A server MAY be made aware of a
+      client's limitations via configuration data.
+
+   g) The server MUST set this field to the number of resource records
+      it places into the Additional section.  In the absense of explicit
+      specification of new RRs to be carried in the Additional section
+      of AXFR response messages, the value MAY be 0, 1 or 2.  See
+      Section 2.1.5 above for details on the currently applicable RRs
+      and Section 2.2.5 for additional considerations specific to AXFR
+      servers.
+
+2.2.2.  Question Section
+
+   In the first response message, this section MUST be copied from the
+   query.  In subsequent messages, this section MAY be copied from the
+   query or it MAY be empty.  However, in an error response message (see
+   Section 2.2), this section MUST be copied as well.  The content of
+   this section MAY be used to determine the context of the message,
+   that is, the name of the zone being transferred.
+
+2.2.3.  Answer Section
+
+   The Answer section MUST be populated with the zone contents.  See
+   Section 3 below on encoding zone contents.
+
+2.2.4.  Authority Section
+
+   The Authority section MUST be empty.
+
+2.2.5.  Additional Section
+
+   The contents of this section MUST follow the guidelines for EDNS0 and
+   TSIG, SIG(0), or whatever other future record is possible here.  The
+   contents of Section 2.1.5 apply analogously as well.
+
+   The following considerations specifically apply to AXFR responses:
+
+   If the client has supplied an EDNS0 OPT RR in the AXFR query and if
+   the server supports ENDS0 as well, it SHOULD include one EDNS0 OPT RR
+   in the first response message and MAY do so in subsequent response
+   messages (see Section 2.2); the specifications of EDNS0 options to be
+   carried in the OPT RR may impose stronger requirements.
+
+   If the client has supplied a transaction security resource record
+   (currently a choice of TSIG and SIG(0)) and the server supports the
+   method chosen by the client, it MUST place the corresponding resource
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 14]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   record into the AXFR response message(s), according to the rules
+   specified for that method.
+
+2.3.  TCP Connection Aborts
+
+   If an AXFR client sends a query on a TCP connection and the
+   connection is closed at any point, the AXFR client MUST consider the
+   AXFR session terminated.  The message ID MAY be used again on a new
+   connection, even if the question and AXFR server are the same.
+
+   Facing a dropped connection, a client SHOULD try to make some
+   determination as to whether the connection closure was the result of
+   network activity or due to a decision by the AXFR server.  This
+   determination is not an exact science.  It is up to the AXFR client
+   to react, but the implemented reaction SHOULD NOT be either an
+   endless cycle of retries or an increasing (in frequency) retry rate.
+
+   An AXFR server implementor should take into consideration the dilemma
+   described above when a connection is closed with an outstanding query
+   in the pipeline.  For this reason, a server ought to reserve this
+   course of action for situations in which it believes beyond a doubt
+   that the AXFR client is attempting abusive behavior.
+
+
+3.  Zone Contents
+
+   The objective of the AXFR session is to request and transfer the
+   contents of a zone, in order to permit the AXFR client to faithfully
+   reconstruct the zone as it exists at the primary server for the given
+   zone serial number.  The word "exists" here designates the externally
+   visible behavior, i.e., the zone content that is being served (handed
+   out to clients) -- not its persistent representation in a zone file
+   or database used by the server -- and that for consistency should be
+   served subsequently by the AXFR client in an identical manner.
+
+   Over time the definition of a zone has evolved from denoting a static
+   set of records to also cover a dynamically updated set of records,
+   and then a potentially continually regenerated set of records (e.g.,
+   RRs synthesized "on the fly" from rule sets or database lookup
+   results in other forms than RR format) as well.
+
+3.1.  Records to Include
+
+   In the Answer section of AXFR response messages, the resource records
+   within a zone for the given serial number MUST appear.  The
+   definition of what belongs in a zone is described in RFC 1034,
+   Section 4.2, "How the database is divided into zones" (in particular
+   Section 4.2.1, "Technical considerations"), and it has been clarified
+   in Section 6 of RFC 2181.
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 15]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   Zones for which it is impractical to list the entire zone for a
+   serial number are not suitable for AXFR retrieval.  A typical (but
+   not limiting) description of such a zone is a zone consisting of
+   responses generated via other database lookups and/or computed based
+   upon ever changing data.
+
+3.2.  Delegation Records
+
+   In Section 4.2.1 of RFC 1034, this text appears (keep in mind that
+   the "should" in the quotation predates [BCP14], cf. Section 1.1):
+
+      "The RRs that describe cuts ... should be exactly the same as the
+       corresponding RRs in the top node of the subzone."
+
+   There has been some controversy over this statement and the impact on
+   which NS resource records are included in a zone transfer.
+
+   The phrase "that describe cuts" is a reference to the NS set and
+   applicable glue records.  It does not mean that the cut point and
+   apex resource records are identical.  For example, the SOA resource
+   record is only found at the apex.  The discussion here is restricted
+   to just the NS resource record set and glue as these "describe cuts".
+
+   DNSSEC resource records have special specifications regarding their
+   occurrence at a zone cut and the apex of a zone.  This was first
+   described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial
+   specification of DNSSEC), which parts of RFC 2181 now in fact are
+   historical.  The current DNSSEC core document set (see second bullet
+   in Section 2 above) gives the full details for DNSSEC(bis) resource
+   record placement, and Section 3.1.5 of RFC 4035 normatively specifies
+   their treatment during AXFR; the alternate NSEC3 resource record
+   defined later in RFC 5155 behaves identically as the NSEC RR, for the
+   purpose of AXFR.
+   Informally:
+
+   o  The DS RRSet only occurs at the parental side of a zone cut and is
+      authoritative data in the parent zone, not the secure child zone.
+
+   o  The DNSKEY RRSet only occurs at the APEX of a signed zone and is
+      part of the authoritative data of the zone it serves.
+
+   o  Independent RRSIG RRSets occur at the signed parent side of a zone
+      cut and at the apex of a signed zone; they are authoritative data
+      in the respective zone; simple queries for RRSIG resource records
+      may return both RRSets at once if the same server is authoritative
+      for the parent zone and the child zone (Section 3.1.5 of RFC 4035
+      describes how to distinguish these RRs); this seeming ambiguity
+      does not occur for AXFR, since each such RRSIG RRset belongs to a
+      single zone.
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 16]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   o  Different NSEC [RFC4034] (or NSEC3 [RFC5155]) resource records
+      equally may occur at the parental side of a zone cut and at the
+      apex of a zone; each such resource record belongs to exactly one
+      of these zones and is to be included in the AXFR of that zone.
+
+   One issue is that in operations there are times when the NS resource
+   records for a zone might be different at a cut point in the parent
+   and at the apex of a zone.  Sometimes this is the result of an error
+   and sometimes it is part of an ongoing change in name servers.  The
+   DNS protocol is robust enough to overcome inconsistencies up to (but
+   not including) there being no parent-indicated NS resource record
+   referencing a server that is able to serve the child zone.  This
+   robustness is one quality that has fueled the success of the DNS.
+   Still, the inconsistency is an error state and steps need to be taken
+   to make it apparent (if it is unplanned) and to make it clear once
+   the inconsistency has been removed.
+
+   Another issue is that the AXFR server could be authoritative for a
+   different set of zones than the AXFR client.  It is possible that the
+   AXFR server be authoritative for both halves of an inconsistent cut
+   point and that the AXFR client is authoritative for just the parent
+   side of the cut point.
+
+   When facing a situation in which a cut point's NS resource records do
+   not match the authoritative set, the question arises whether an AXFR
+   server responds with the NS resource record set that is in the zone
+   being transferred or the one that is at the authoritative location.
+
+   The AXFR response MUST contain the cut point NS resource record set
+   registered with the zone whether it agrees with the authoritative set
+   or not.  "Registered with" can be widely interpreted to include data
+   residing in the zone file of the zone for the particular serial
+   number (in zone file environments) or as any data configured to be in
+   the zone (database), statically or dynamically.
+
+   The reasons for this requirement are:
+
+   1) The AXFR server might not be able to determine that there is an
+   inconsistency given local data, hence requiring consistency would
+   mean a lot more needed work and even network retrieval of data.  An
+   authoritative server ought not be required to perform any queries.
+
+   2) By transferring the inconsistent NS resource records from a server
+   that is authoritative for both the cut point and the apex to a client
+   that is not authoritative for both, the error is exposed.  For
+   example, an authorized administrator can manually request the AXFR
+   and inspect the results to see the inconsistent records.  (A server
+   authoritative for both halves would otherwise always answer from the
+   more authoritative set, concealing the error.)
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 17]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   3) The inconsistent NS resource record set might indicate a problem
+   in a registration database.
+
+   4) This requirement is necessary to ensure that retrieving a given
+   (zone,serial) pair by AXFR yields the exact same set of resource
+   records no matter which of the zone's authoritative servers is chosen
+   as the source of the transfer.
+
+   If an AXFR server were allowed to respond with the authoritative NS
+   RRset of a child zone instead of a parent-side NS RRset in the zone
+   being transferred, the set of records returned could vary depending
+   on whether or not the server happened to be authoritative for the
+   child zone as well.
+
+   The property that a given (zone,serial) pair corresponds to a single,
+   well-defined set of records is necessary for the correct operation of
+   incremental transfer protocols such as IXFR [RFC1995].  For example,
+   a client may retrieve a zone by AXFR from one server, and then apply
+   an incremental change obtained by IXFR from a different server.  If
+   the two servers have different ideas of the zone contents, the client
+   can end up attempting to incrementally add records that already exist
+   or to delete records that do not exist.
+
+3.3.  Glue Records
+
+   As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
+   guidance and rationale for the inclusion of glue records as part of
+   an AXFR transfer.  And, as also argued in the previous section of
+   this document, even when there is an inconsistency between the
+   address in a glue record and the authoritative copy of the name
+   server's address, the glue resource record that is registered as part
+   of the zone for that serial number is to be included.
+
+   This applies to glue records for any address family [IANA-AF].
+
+   The AXFR response MUST contain the appropriate glue records as
+   registered with the zone.  The interpretation of "registered with" in
+   the previous section applies here.  Inconsistent glue records are an
+   operational matter.
+
+3.4.  Name Compression
+
+   Compression of names in DNS messages is described in RFC 1035,
+   Section 4.1.4, "Message compression".  The issue highlighted here
+   relates to a comment made in RFC 1034, Section 3.1, "Name space
+   specifications and terminology" which says "When you receive a domain
+   name or label, you should preserve its case."  ("Should" in the quote
+   predates [BCP14].)
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 18]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   Since the primary objective of AXFR is to enable the client to serve
+   the same zone content as the server, unlike such normal DNS responses
+   that are expected to preserve the case in the query, the actual zone
+   transfer needs to retain the case of the labels in the zone content.
+   Hence, name compression in an AXFR message SHOULD be performed in a
+   case-preserving manner, unlike how it is done for 'normal' DNS
+   responses.  That is, although when comparing a domain name for
+   matching, "a" equals "A", when comparing for the purposes of message
+   compression for AXFR, "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 understanding of the requirement on AXFR servers.
+
+   Rules governing name compression of RDATA in an AXFR message MUST
+   abide by the specification in "Handling of Unknown DNS Resource
+   Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name
+   Compression".
+
+3.5.  Occluded Names
+
+   Dynamic Update [RFC2136] operations, and in particular its
+   interaction with DNAME [RFC2672], can have a side effect of occluding
+   names in a zone.  The addition of a delegation point via dynamic
+   update will render all subordinate domain names to be in a limbo,
+   still part of the zone but not available to the lookup process.  The
+   addition of a DNAME resource record has the same impact.  The
+   subordinate names are said to be "occluded".
+
+   Occluded names MUST be included in AXFR responses.  An AXFR client
+   MUST be able to identify and handle occluded names.  The rationale
+   for this action is based on a speedy recovery if the dynamic update
+   operation was in error and is to be undone.
+
+
+4.  Transport
+
+   AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
+   1034 that states:  "Because accuracy is essential, TCP or some other
+   reliable protocol must be used for AXFR requests."  The restriction
+   to TCP is also mentioned in Section 6.1.3.2. of "Requirements for
+   Internet Hosts - Application and Support" [RFC1123].
+
+   The most common scenario is for an AXFR client to open a TCP
+   connection to the AXFR server, send an AXFR query, receive the AXFR
+   response, and then close the connection.  But variations of that most
+   simple scenario are legitimate and likely: in particular, sending a
+   query for the zone's SOA resource record first over the same TCP
+   connection, and reusing an existing TCP connection for other queries.
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 19]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   Therefore, the assumption that a TCP connection is dedicated to a
+   single AXFR session is incorrect.  This wrong assumption has led to
+   implementation choices that prevent either multiple concurrent zone
+   transfers or the use of an open connection for other queries.
+
+   Since the early days of the DNS, operators who have sets of name
+   servers that are authoritative for a common set of zones found it
+   desirable to be able to have multiple concurrent zone transfers in
+   progress; this way a name server does not have to wait for one zone
+   transfer to complete before the next can begin.  RFC 1035 did not
+   exclude this possibility, but legacy implementations failed to
+   support this functionality efficiently, over a single TCP connection.
+   The remaining presence of such legacy implementations makes it
+   necessary that new general purpose client implementations still
+   provide options for graceful fallback to the old behavior in their
+   support of concurrent DNS transactions and AXFR sessions on a single
+   TCP connection.
+
+4.1.  TCP
+
+   In the original definition there arguably is an implicit assumption
+   (probably unintentional) that a TCP connection is used for one and
+   only one AXFR session.  This is evidenced in the lack of an explicit
+   requirement to copy the Question Section and/or the message ID into
+   responses, no explicit ordering information within the AXFR response
+   messages, and the lack of an explicit notice indicating that a zone
+   transfer continues in the next message.
+
+   The guidance given below is intended to enable better performance of
+   the AXFR exchange as well as provide guidelines on interactions with
+   older software.  Better performance includes being able to multiplex
+   DNS message exchanges including zone transfer sessions.  Guidelines
+   for interacting with older software are generally applicable to new
+   AXFR clients.  In the reverse situation, older AXFR client and newer
+   AXFR server, the server ought to operate within the specification for
+   an older server.
+
+4.1.1.  AXFR client TCP
+
+   An AXFR client MAY request a connection to an AXFR server for any
+   reason.  An AXFR client SHOULD close the connection when there is no
+   apparent need to use the connection for some time period.  The AXFR
+   server ought not have to maintain idle connections; the burden of
+   connection closure ought to be on the client.  "Apparent need" for
+   the connection is a judgment for the AXFR client and the DNS client.
+   If the connection is used for multiple sessions, or if it is known
+   sessions will be coming, or if there is other query/response traffic
+   anticipated or currently on the open connection, then there is
+   "apparent need".
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 20]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   An AXFR client can cancel the delivery of a zone only by closing the
+   connection.  However, this action will also cancel all other
+   outstanding activity using the connection.  There is no other
+   mechanism by which an AXFR response can be cancelled.
+
+   When a TCP connection is closed remotely (relative to the client),
+   whether by the AXFR server or due to a network event, the AXFR client
+   MUST cancel all outstanding sessions and non-AXFR transactions.
+   Recovery from this situation is not straightforward.  If the
+   disruption was a spurious event, attempting to restart the connection
+   would be proper.  If the disruption was caused by a failure that
+   proved to be persistent, the AXFR client would be wise not to 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
+   not to retry the connection.  Unfortunately, knowing which of the
+   three cases above (momentary disruption, failure, policy) applies is
+   not possible with certainty, and can only be assessed by heuristics.
+   This exemplifies the general complications for clients in connection-
+   oriented protocols not receiving meaningful error responses.
+
+   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 to handle other query/response
+   transactions over it.
+
+   If a TCP connection is closed remotely, the AXFR server MUST cancel
+   all AXFR sessions in place.  No retry activity is necessary; that is
+   initiated by the AXFR client.
+
+   Local policy MAY dictate that a TCP connection is to be closed.  Such
+   an action SHOULD be in reaction to limits such as those placed on the
+   number of outstanding open connections.  Closing a connection in
+   response to a suspected security event SHOULD be done only in extreme
+   cases, when the server is certain the action is warranted.  An
+   isolated request for a zone not on the AXFR server SHOULD receive a
+   response with the appropriate response code and not see the
+   connection broken.
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 21]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+4.2.  UDP
+
+   With the addition of EDNS0 and applications which require many small
+   zones such as in web hosting and some ENUM scenarios, AXFR sessions
+   on UDP would now seem desirable.  However, there are still some
+   aspects of AXFR sessions that are not easily translated to UDP.
+
+   Therefore, this document does not update RFC 1035 in this respect:
+   AXFR sessions over UDP transport are not defined.
+
+
+5.  Authorization
+
+   A zone administrator has the option to restrict AXFR access to a
+   zone.  This was not envisioned in the original design of the DNS but
+   has emerged as a requirement as the DNS has evolved.  Restrictions on
+   AXFR could be for various reasons including a desire (or in some
+   instances, having a legal requirement) to keep the bulk version of
+   the zone concealed or to prevent the servers from handling the load
+   incurred in serving AXFR.  It has been argued that these reasons are
+   questionable, but this document, driven by the desire to leverage the
+   interoperable practice that has evolved since RFC 1035, acknowledges
+   the factual requirement to provide mechanisms to restrict AXFR.
+
+   A DNS implementation SHOULD provide means to restrict AXFR sessions
+   to specific clients.
+
+   An implementation SHOULD allow access to be granted to Internet
+   Protocol addresses and ranges, regardless of whether a source address
+   could be spoofed.  Combining this with techniques such as Virtual
+   Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be
+   effective.
+
+   A general purpose implementation is RECOMMENDED to implement access
+   controls based upon "Secret Key Transaction Authentication for DNS"
+   [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
+   [RFC2931].
+
+   A general purpose implementation SHOULD allow access to be open to
+   all AXFR requests.  I.e., an operator ought to be able to allow any
+   AXFR query to be granted.
+
+   A general purpose implementation SHOULD NOT have a default policy for
+   AXFR requests to be "open to all".  For example, a default could be
+   to restrict transfers to addresses selected by the DNS
+   administrator(s) for zones on the server.
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 22]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+6.  Zone Integrity
+
+   An AXFR client MUST ensure that only a successfully transferred copy
+   of the zone data can be used to serve this zone.  Previous
+   description and implementation practice have introduced a two-stage
+   model of the whole zone synchronization procedure:  Upon a trigger
+   event (e.g., polling of a SOA resource record detects change in the
+   SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session is
+   initiated, whereby the zone data are saved in a zone file or data
+   base (this latter step is necessary anyway to ensure proper restart
+   of the server); upon successful completion of the AXFR operation and
+   some sanity checks, this data set is 'loaded' and made available for
+   serving the zone in an atomic operation, and flagged 'valid' for use
+   during the next restart of the DNS server; if any error is detected,
+   this data set MUST be deleted, and the AXFR client MUST continue to
+   serve the previous version of the zone, if it did before.  The
+   externally visible behavior of an AXFR client implementation MUST be
+   equivalent to that of this two-stage model.
+
+   If an AXFR client rejects data contained in an AXFR session, it
+   SHOULD remember the serial number and MAY attempt to retrieve the
+   same zone version again.  The reason the same retrieval could make
+   sense is that the reason for the rejection could be rooted in an
+   implementation detail of one AXFR server used for the zone and not
+   present in another AXFR server used for the zone.
+
+   Ensuring that an AXFR client does not accept a forged copy of a zone
+   is important to the security of a zone.  If a zone operator has the
+   opportunity, protection can be afforded via dedicated links, physical
+   or virtual via a VPN among the authoritative servers.  But there are
+   instances in which zone operators have no choice but to run AXFR
+   sessions over the global public Internet.
+
+   Besides best attempts at securing TCP connections, DNS
+   implementations SHOULD provide means to make use of "Secret Key
+   Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and
+   Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients
+   to verify the contents.  These techniques MAY also be used for
+   authorization.
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 23]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+7.  Backwards Compatibility
+
+   Describing backwards compatibility is difficult because of the lack
+   of specifics in the original definition.  In this section some hints
+   at building in backwards compatibility are given, mostly repeated
+   from the relevant earlier sections.
+
+   Backwards compatibility is not necessary, but the greater the extent
+   of an implementation's compatibility the greater its
+   interoperability.  For turnkey implementations this is not usually a
+   concern.  For general purpose implementations this takes on varying
+   levels of importance depending on the implementer's desire to
+   maintain interoperability.
+
+   It is unfortunate that a need to fall back to older behavior cannot
+   be discovered, hence needs to be noted in a configuration file.  An
+   implementation SHOULD, in its documentation, encourage operators to
+   periodically review AXFR clients and servers it has made notes about
+   repeatedly, as old software gets updated from time to time.
+
+7.1.  Server
+
+   An AXFR server has the luxury of being able to react to an AXFR
+   client's abilities with the exception of knowing whether the client
+   can accept multiple resource records per AXFR response message.  The
+   knowledge that a client is so restricted cannot be discovered, hence
+   it has to be set by configuration.
+
+   An implementation of an AXFR server MAY permit configuring, on a per
+   AXFR client basis, the necessity to revert to single resource record
+   per message; in that case, the default SHOULD be to use multiple
+   records per message.
+
+7.2.  Client
+
+   An AXFR client has the opportunity to try other features (i.e., those
+   not defined by this document) when querying an AXFR server.
+
+   Attempting to issue multiple DNS queries over a TCP transport for an
+   AXFR session SHOULD be aborted if it interrupts the original request,
+   and SHOULD take into consideration whether the AXFR server intends to
+   close the connection immediately upon completion of the original
+   (connection-causing) zone transfer.
+
+
+
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 24]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+8.  Security Considerations
+
+   Concerns regarding authorization, traffic flooding, and message
+   integrity are mentioned in "Authorization" (Section 5), "TCP"
+   (Section 4.2) and "Zone Integrity" (Section 6).
+
+
+9.  IANA Considerations
+
+   [[ Note to RFC-Ed: this section may be deleted before publication. ]]
+   No new registries or new registrations are included in this document.
+
+
+10.  Internationalization Considerations
+
+   The AXFR protocol is transparent to the parts of DNS zone content
+   that can possibly be subject to Internationalization considerations.
+   It is assumed that for DNS labels and domain names, the issue has
+   been solved via "Internationalizing Domain Names in Applications
+   (IDNA)" [RFC3490] or its successor(s).
+
+
+11.  Acknowledgments
+
+   Earlier editions of this document have been edited by Andreas
+   Gustafsson.  In his latest version, this acknowledgment appeared:
+
+    "Many people have contributed input and commentary to earlier
+     versions of this document, including but not limited to Bob Halley,
+     Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert
+     Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
+     Trenholme, and Brian Wellington."
+
+   Comments since the -05 version have come from these individuals:
+   Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch,
+   Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly,
+   Bill Manning, and other participants of the DNSEXT working group.
+
+   Edward Lewis served as a patiently listening sole document editor for
+   two years.
+
+12.  References
+
+   All "RFC" references by can be obtained from the RFC Editor web site
+   at the URLs:       http://rfc-editor.org/rfc.html
+   or                 http://rfc-editor.org/rfcsearch.html ;
+   information regarding this organization can be found at the following
+   URL:               http://rfc-editor.org/
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 25]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+12.1.  Normative References
+
+   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
+              Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
+              RFC 2672, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 26]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   [RFC3425]  Lawrence, D., "Obsoleting IQUERY", RFC 3425,
+              November 2002.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006
+
+   [RFC4635]  Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
+              Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
+              RFC 4635, August 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008
+
+   [RFC5395]  Eastlake 3rd, "Domain Name System (DNS) IANA
+              Considerations", BCP 42, RFC 5395, November 2008.
+
+   [RFC5702]  Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC", RFC 5702,
+              October 2009.
+
+12.2.  Informative References
+
+   [DNSVALS]  IANA Registry "Domain Name System (DNS) Parameters",
+              http://www.iana.org/assignments/dns-parameters
+
+   [IANA-AF]  IANA Registry "Address Family Numbers",
+              http://www.iana.org/assignments/Address-family-numbers/ .
+
+   [RFC2764]  Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
+              Malis, "A Framework for IP Based Virtual Private
+              Networks", RFC 2764, February 2000.
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 27]
+
+Internet-Draft      DNS Zone Transfer Protocol (AXFR)       January 2010
+
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
+              Implementation Notes for DNSSECbis",
+              draft-ietf-dnsext-dnssec-bis-updates-09 (work in
+              progress), September 2009.
+
+
+Authors' Addresses
+
+   Edward Lewis
+   46000 Center Oak Plaza
+   Sterling, VA, 22033, US
+
+   Email: ed.lewis@neustar.biz
+
+
+   Alfred Hoenes, Editor
+   TR-Sys
+   Gerlinger Str. 12
+   Ditzingen  D-71254
+   Germany
+
+   Email: ah@TR-Sys.de
+
+
+Editorial Note: Discussion  [[ to be removed by RFC-Editor ]]
+
+   Comments on this draft ought to be addressed to the editors and/or to
+   namedroppers@ops.ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis & Hoenes            Expires July 18, 2010                [Page 28]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt
deleted file mode 100644
index 152d96efaca6..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-gost-05.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-DNS Extensions working group                             V.Dolmatov, Ed.  
-Internet-Draft                                            Cryptocom Ltd.    
-Intended status: Standards Track                      November 30, 2009
-Expires: May 30, 2010                                 
-
-
- Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
-                               for DNSSEC
-                 draft-ietf-dnsext-dnssec-gost-05
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May  10 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document describes how to produce signature and hash using 
-   GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS
-   resource records for use in the Domain Name System Security 
-   Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
-
-V.Dolmatov              Expires May  30, 2010               [Page 1]
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  Using a public key with existing cryptographic libraries. . 3
-     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 3
-   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
-     3.1 RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . . 4
-   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
-     4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
-     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
-     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 5
-     6.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 5
-     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
-     6.3.  Byte order  . . . . . . . . . . . . . . . . . . . . . . . . 5
-   7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
-     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
-   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
-   Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the signature and hash algorithms 
-   GOST [GOST3410, GOST3411],
-   and specifies how to store DNSKEY data and how to produce
-   RRSIG resource records with these hash algorithms.
-
-   Familiarity with DNSSEC  and GOST signature and hash
-   algorithms is assumed in this document.
-
-   The term "GOST" is not officially defined, but is usually used to
-   refer to the collection of the Russian cryptographic algorithms
-   GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. 
-   Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
-   the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-V.Dolmatov              Expires May  30, 2010                [Page 2]
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
-   GOST R 34.10-2001 public keys are stored with the algorithm number 
-   {TBA1}.
-      
-   The wire format of the public key is compatible with 
-   RFC 4491 [RFC4491]:
-
-   According to [GOST3410], a public key is a point on the elliptic
-   curve Q = (x,y).
-
-   The wire representation of a public key MUST contain 66 octets, 
-   where the first octet designates public key parameters, the second
-   octet designates digest parameters next 32 octets contain the 
-   little-endian representation of x and the second 32 octets contain
-   the little-endian representation of y. 
-   This corresponds to the binary representation of (256||256) 
-   from [GOST3410], ch.  5.3.
-
-   The only valid value for both parameters octets is 0.
-   Other parameters octets values are reserved for future use.
-   
-   Corresponding public key parameters are those identified by
-   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
-   and the digest parameters are those identified by
-   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1.  Using a public key with existing cryptographic libraries
-
-   Existing GOST-aware cryptographic libraries at the time of this 
-   document writing are capable to read GOST public keys via a generic
-   X509 API if the key is encoded according to RFC 4491 [RFC4491],
-   section 2.3.2.
-
-   To make this encoding from the wire format of a GOST public key 
-   with the parameters used in this document, prepend the last 64 octets
-   of key data (in other words, substitute first two parameter octets)
-   with the following 37-byte sequence:
-
-   0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 
-   0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
-   0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-  
-2.2.  GOST DNSKEY RR Example
-
-   Given a private key with the following value (the value of GostAsn1
-   field is split here into two lines to simplify reading; in the 
-   private key file it must be in one line):
-
-   Private-key-format: v1.2
-   Algorithm: {TBA1} (GOST)
-   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S
-             2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E=
-
-V.Dolmatov              Expires May  30, 2010                [Page 3]
-
-   The following DNSKEY RR stores a DNS zone key for example.net
- 
-   example.net. 86400 IN DNSKEY 256 3 {TBA1} (
-                                AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq
-                                tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6
-                                yB7i836EfzmJo5LP
-                                ) ; key id = 15820
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows RFC 4490
-   [RFC4490] and is calculated as follows.  The values for the RDATA 
-   fields that precede the signature data are specified 
-   in RFC 4034 [RFC4034].
-
-   hash = GOSTR3411(data)
-
-   where "data" is the wire format data of the resource record set 
-   that is signed, as specified in RFC 4034 [RFC4034].
-   
-   Hash MUST be calculated with GOST R 34.11-94 parameters identified
-   by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-   Signature is calculated from the hash according to the 
-   GOST R 34.10-2001 standard and its wire format is compatible with 
-   RFC 4490 [RFC4490].
-
-   Quoting RFC 4490:
-
-   "The signature algorithm GOST R 34.10-2001 generates a digital
-   signature in the form of two 256-bit numbers, r and s.  Its octet
-   string representation consists of 64 octets, where the first 32
-   octets contain the big-endian representation of s and the second 32
-   octets contain the big-endian representation of r."
-
-3.1. RRSIG RR Example
-
-   With the private key from section 2.2 sign the following RRSet, 
-   consisting of one A record:
-
-   www.example.net. 3600 IN A 192.0.2.1
-
-   Setting the inception date to 2000-01-01 00:00:00 UTC and the 
-   expiration date to 2030-01-01 00:00:00 UTC, the following signature
-   should be created (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
-                                  20000101000000 15820 example.net.
-                                  2MIsZWtEx6pcfQrdl376B8sFg0qxsR8XMHpl
-                                  jHh+V6U7Qte7WwI4C3Z1nFMRVf//C9rO2dGB
-                                  rdp+C7wVoOHBqA== )
- 
-V.Dolmatov              Expires May  30, 2010                [Page 4]
-
-  Note: Several GOST signatures calculated for the same message text 
-   differ because of using of a random element is used in signature 
-   generation process.
-
-4.  DS Resource Records
-
-   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
-   type {TBA2}.The wire format of a digest value is compatible with 
-   RFC4490 [RFC4490], that is digest is in little-endian representation. 
-
-
-   The digest MUST always be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1. DS RR Example
-
-   For key signing key (assuming {TBA1}==249 until proper code is 
-   assigned by IANA)
-
-   example.net. 86400   DNSKEY  257 3 {TBA1} (
-                                AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C
-                                RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu
-                                9tCz5oSsZl0cL0R2
-                                ) ; key id = 21649
-
-   The DS RR will be
-
-   example.net. 3600 IN DS 21649 {TBA1} {TBA2} (
-             A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A
-             A44649C6 )
-
-5.  Deployment Considerations
-
-5.1.  Key Sizes
-
-   According to RFC4357 [RFC4357], the key size of GOST public keys
-   MUST be 512 bits.
-
-5.2.  Signature Sizes
-
-   According to the GOST signature algorithm specification [GOST3410],
-   the size of a GOST signature is 512 bits.
-
-5.3.  Digest Sizes
-
-   According to the GOST R 34.11-94 [GOST3411], the size of a GOST 
-   digest is 256 bits.
-
-6.  Implementation Considerations
-
-6.1.  Support for GOST signatures
-
-   DNSSEC aware implementations SHOULD be able to support RRSIG and
-   DNSKEY resource records created with the GOST algorithms as
-   defined in this document.
-
-V.Dolmatov              Expires May  30, 2010                [Page 5]
-
-6.2.  Support for NSEC3 Denial of Existence
-
-    Any DNSSEC-GOST implementation is required to have either NSEC or
-    NSEC3 support.
-
-6.3  Byte order
-
-    Due to the fact that all existing industry implementations of GOST
-    cryptographic libraries are returning GOST blobs in little-endian 
-    format and in order to avoid the necessity for DNSSEC developers 
-    to handle different cryptographic algorithms differently, it was
-    chosen to send these blobs on the wire "as is" without 
-    transformation of endianness.
-
-7.  Security considerations
-
-    Currently, the cryptographic resistance of the GOST 34.10-2001 
-    digital signature algorithm is estimated as 2**128 operations
-    of multiple elliptic curve point computations on prime modulus
-    of order 2**256.
-
-
-    Currently, the cryptographic resistance of GOST 34.11-94 hash
-    algorithm is estimated as 2**128 operations of computations of a
-    step hash function. (There is known method to reduce this 
-    estimate to 2**105 operations, but it demands padding the 
-    colliding message with 1024 random bit blocks each of 256 bit
-    length, thus it cannot be used in any practical implementation).
-
-8.  IANA Considerations
-
-   This document updates the IANA registry "DNS Security Algorithm 
-   Numbers [RFC4034]"
-   (http://www.iana.org/assignments/dns-sec-alg-numbers).  
-   The following entries are added to the registry:
-                                     Zone    Trans.
-   Value  Algorithm         Mnemonic Signing Sec.  References   Status
-   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
-
-   This document updates the RFC 4034 Digest Types assignment
-   (section A.2)by adding the value and status for the GOST R 34.11-94
-   algorithm:
-
-   Value   Algorithm        Status
-   {TBA2}  GOST R 34.11-94  OPTIONAL
-
-9. Acknowledgments
-
-   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
-   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
-   and RFC 4357 [RFC4357] for consistency. The authors of and 
-   contributors to these documents are gratefully acknowledged for 
-   their hard work.
-
-V.Dolmatov              Expires May  30, 2010                [Page 6]
-
-   The following people provided additional feedback and text: Dmitry 
-   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
-   and Wouter Wijngaards.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-   [RFC3110]  Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC4033]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends R., Austein R., Larson M., Massey D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [GOST3410] "Information technology.  Cryptographic data security.
-              Signature and verification processes of [electronic]
-              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 2001.  (In Russian)
-
-   [GOST3411] "Information technology.  Cryptographic Data Security.
-              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
-              Standard of Russian Federation, Government Committee of
-              the Russia for Standards, 1994.  (In Russian)
-
-   [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
-             Cryptographic Algorithms for Use with GOST 28147-89,
-             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-             Algorithms", RFC 4357, January 2006.
-
-   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
-             GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
-             Algorithms with Cryptographic Message Syntax (CMS)",
-             RFC 4490, May 2006.
-
-   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
-             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
-             Algorithms with the Internet X.509 Public Key 
-             Infrastructure Certificate and CRL Profile", RFC 4491,
-             May 2006. 
-
-V.Dolmatov              Expires May  30, 2010               [Page 7]
-
-
-10.2.  Informative References
-
-   [RFC4509]  Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
-              "GOST R 34.10-2001 digital signature algorithm"
-              draft-dolmatov-cryptocom-gost34102001-06, 11.10.09
-              work in progress.
-
-
-   [DRAFT2]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
-              "GOST R 34.11-94 Hash function algorithm"
-              draft-dolmatov-cryptocom-gost341194-04, 11.10.09
-              work in progress.
-
-   [DRAFT3]   Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
-              "GOST 28147-89 encryption, decryption and MAC algorithms"
-              draft-dolmatov-cryptocom-gost2814789-04, 11.10.09
-              work in progress.
-
-V.Dolmatov              Expires May  30, 2010                [Page 8]
-
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: dol@cryptocom.ru
-
-Artem Chuprina
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: ran@cryptocom.ru
-
-Igor Ustinov
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: igus@cryptocom.ru
-
-V.Dolmatov              Expires May  30, 2010                [Page 9]
-
-
-
-
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt
new file mode 100644
index 000000000000..f651d1351ec1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt
@@ -0,0 +1,444 @@
+DNS Extensions working group                             V.Dolmatov, Ed.  
+Internet-Draft                                            Cryptocom Ltd.    
+Intended status: Standards Track                      December 12, 2009
+Expires: June 12, 2010                                 
+
+
+ Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
+                               for DNSSEC
+                 draft-ietf-dnsext-dnssec-gost-06
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on June 12 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document describes how to produce signature and hash using 
+   GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS
+   resource records for use in the Domain Name System Security 
+   Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
+
+V.Dolmatov              Expires June 12, 2010               [Page 1]
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
+     2.1.  Using a public key with existing cryptographic libraries. . 3
+     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 3
+   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
+     3.1 RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
+     4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
+   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
+     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
+     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 5
+     6.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 5
+     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
+     6.3.  Byte order  . . . . . . . . . . . . . . . . . . . . . . . . 5
+   7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+   10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
+     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Naming.  The DNS has been extended to use
+   cryptographic keys and digital signatures for the verification of the
+   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
+   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
+   Extensions, called DNSSEC.
+
+   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+   and specifies a list of cryptographic algorithms to use.  This
+   document extends that list with the signature and hash algorithms 
+   GOST [GOST3410, GOST3411],
+   and specifies how to store DNSKEY data and how to produce
+   RRSIG resource records with these hash algorithms.
+
+   Familiarity with DNSSEC  and GOST signature and hash
+   algorithms is assumed in this document.
+
+   The term "GOST" is not officially defined, but is usually used to
+   refer to the collection of the Russian cryptographic algorithms
+   GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. 
+   Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
+   the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+V.Dolmatov              Expires June 12, 2010                [Page 2]
+
+2.  DNSKEY Resource Records
+
+   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
+
+   GOST R 34.10-2001 public keys are stored with the algorithm number 
+   {TBA1}.
+      
+   The wire format of the public key is compatible with 
+   RFC 4491 [RFC4491]:
+
+   According to [GOST3410], a public key is a point on the elliptic
+   curve Q = (x,y).
+
+   The wire representation of a public key MUST contain 64 octets, 
+   where the first 32 octets contain the little-endian representation
+   of x and the second 32 octets contain the little-endian 
+   representation of y. 
+   This corresponds to the binary representation of (256||256) 
+   from [GOST3410], ch.  5.3.
+
+   Corresponding public key parameters are those identified by
+   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
+   and the digest parameters are those identified by
+   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
+
+2.1.  Using a public key with existing cryptographic libraries
+
+   Existing GOST-aware cryptographic libraries at the time of this 
+   document writing are capable to read GOST public keys via a generic
+   X509 API if the key is encoded according to RFC 4491 [RFC4491],
+   section 2.3.2.
+
+   To make this encoding from the wire format of a GOST public key 
+   with the parameters used in this document, prepend the 64 octets
+   of key data with the following 37-byte sequence:
+
+   0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 
+   0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
+   0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
+  
+2.2.  GOST DNSKEY RR Example
+
+   Given a private key with the following value (the value of GostAsn1
+   field is split here into two lines to simplify reading; in the 
+   private key file it must be in one line):
+
+   Private-key-format: v1.2
+   Algorithm: {TBA1} (GOST)
+   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
+             t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
+ 
+
+V.Dolmatov              Expires June 12, 2010                [Page 3]
+
+   The following DNSKEY RR stores a DNS zone key for example.net
+ 
+   example.net. 86400 IN DNSKEY 256 3 {TBA1} (
+                                GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa
+                                6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I
+                                9Jrfial/yyc5Og==
+                                ) ; key id = 10805
+
+3.  RRSIG Resource Records
+
+   The value of the signature field in the RRSIG RR follows RFC 4490
+   [RFC4490] and is calculated as follows.  The values for the RDATA 
+   fields that precede the signature data are specified 
+   in RFC 4034 [RFC4034].
+
+   hash = GOSTR3411(data)
+
+   where "data" is the wire format data of the resource record set 
+   that is signed, as specified in RFC 4034 [RFC4034].
+   
+   Hash MUST be calculated with GOST R 34.11-94 parameters identified
+   by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+   Signature is calculated from the hash according to the 
+   GOST R 34.10-2001 standard and its wire format is compatible with 
+   RFC 4490 [RFC4490].
+
+   Quoting RFC 4490:
+
+   "The signature algorithm GOST R 34.10-2001 generates a digital
+   signature in the form of two 256-bit numbers, r and s.  Its octet
+   string representation consists of 64 octets, where the first 32
+   octets contain the big-endian representation of s and the second 32
+   octets contain the big-endian representation of r."
+
+3.1. RRSIG RR Example
+
+   With the private key from section 2.2 sign the following RRSet, 
+   consisting of one A record:
+
+   www.example.net. 3600 IN A 192.0.2.1
+
+   Setting the inception date to 2000-01-01 00:00:00 UTC and the 
+   expiration date to 2030-01-01 00:00:00 UTC, the following signature
+   should be created (assuming {TBA1}==249 until proper code is 
+   assigned by IANA)
+
+   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
+                                  20000101000000 10805 example.net.
+                                  k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp
+                                  Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
+                                  HRFSm0XS5YST5g== )
+ 
+V.Dolmatov              Expires June 12, 2010                [Page 4]
+
+  Note: Several GOST signatures calculated for the same message text 
+   differ because of using of a random element is used in signature 
+   generation process.
+
+4.  DS Resource Records
+
+   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
+   type {TBA2}.The wire format of a digest value is compatible with 
+   RFC4490 [RFC4490], that is digest is in little-endian representation. 
+
+
+   The digest MUST always be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+4.1. DS RR Example
+
+   For key signing key (assuming {TBA1}==249 until proper code is 
+   assigned by IANA)
+
+   example.net. 86400   DNSKEY  257 3 {TBA1} (
+                                1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA
+                                EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi
+                                q/q4CwA4WR+ovg==
+                                ) ; key id = 6204
+ 
+   The DS RR will be
+
+   example.net. 3600 IN DS 6204 {TBA1} {TBA2} (
+             0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B
+             553BC61E )
+
+5.  Deployment Considerations
+
+5.1.  Key Sizes
+
+   According to RFC4357 [RFC4357], the key size of GOST public keys
+   MUST be 512 bits.
+
+5.2.  Signature Sizes
+
+   According to the GOST signature algorithm specification [GOST3410],
+   the size of a GOST signature is 512 bits.
+
+5.3.  Digest Sizes
+
+   According to the GOST R 34.11-94 [GOST3411], the size of a GOST 
+   digest is 256 bits.
+
+6.  Implementation Considerations
+
+6.1.  Support for GOST signatures
+
+   DNSSEC aware implementations SHOULD be able to support RRSIG and
+   DNSKEY resource records created with the GOST algorithms as
+   defined in this document.
+
+V.Dolmatov              Expires June 12, 2010                [Page 5]
+
+6.2.  Support for NSEC3 Denial of Existence
+
+    Any DNSSEC-GOST implementation is required to have either NSEC or
+    NSEC3 support.
+
+6.3  Byte order
+
+    Due to the fact that all existing industry implementations of GOST
+    cryptographic libraries are returning GOST blobs in little-endian 
+    format and in order to avoid the necessity for DNSSEC developers 
+    to handle different cryptographic algorithms differently, it was
+    chosen to send these blobs on the wire "as is" without 
+    transformation of endianness.
+
+7.  Security considerations
+
+    Currently, the cryptographic resistance of the GOST 34.10-2001 
+    digital signature algorithm is estimated as 2**128 operations
+    of multiple elliptic curve point computations on prime modulus
+    of order 2**256.
+
+
+    Currently, the cryptographic resistance of GOST 34.11-94 hash
+    algorithm is estimated as 2**128 operations of computations of a
+    step hash function. (There is known method to reduce this 
+    estimate to 2**105 operations, but it demands padding the 
+    colliding message with 1024 random bit blocks each of 256 bit
+    length, thus it cannot be used in any practical implementation).
+
+8.  IANA Considerations
+
+   This document updates the IANA registry "DNS Security Algorithm 
+   Numbers [RFC4034]"
+   (http://www.iana.org/assignments/dns-sec-alg-numbers).  
+   The following entries are added to the registry:
+                                     Zone    Trans.
+   Value  Algorithm         Mnemonic Signing Sec.  References   Status
+   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
+
+   This document updates the RFC 4034 Digest Types assignment
+   (section A.2)by adding the value and status for the GOST R 34.11-94
+   algorithm:
+
+   Value   Algorithm        Status
+   {TBA2}  GOST R 34.11-94  OPTIONAL
+
+9. Acknowledgments
+
+   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
+   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
+   and RFC 4357 [RFC4357] for consistency. The authors of and 
+   contributors to these documents are gratefully acknowledged for 
+   their hard work.
+
+V.Dolmatov              Expires June 12, 2010                [Page 6]
+
+   The following people provided additional feedback and text: Dmitry 
+   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
+   and Wouter Wijngaards.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC3110]  Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+              Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC4033]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [GOST3410] "Information technology.  Cryptographic data security.
+              Signature and verification processes of [electronic]
+              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 2001.  (In Russian)
+
+   [GOST3411] "Information technology.  Cryptographic Data Security.
+              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 1994.  (In Russian)
+
+   [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
+             Cryptographic Algorithms for Use with GOST 28147-89,
+             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+             Algorithms", RFC 4357, January 2006.
+
+   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
+             GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
+             Algorithms with Cryptographic Message Syntax (CMS)",
+             RFC 4490, May 2006.
+
+   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
+             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
+             Algorithms with the Internet X.509 Public Key 
+             Infrastructure Certificate and CRL Profile", RFC 4491,
+             May 2006. 
+
+V.Dolmatov              Expires June 12, 2010               [Page 7]
+
+
+10.2.  Informative References
+
+   [RFC4509]  Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
+              "GOST R 34.10-2001 digital signature algorithm"
+              draft-dolmatov-cryptocom-gost34102001-07, 12.12.09
+              work in progress.
+
+
+   [DRAFT2]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
+              "GOST R 34.11-94 Hash function algorithm"
+              draft-dolmatov-cryptocom-gost341194-06, 12.12.09
+              work in progress.
+
+   [DRAFT3]   Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
+              "GOST 28147-89 encryption, decryption and MAC algorithms"
+              draft-dolmatov-cryptocom-gost2814789-06, 12.12.09
+              work in progress.
+
+V.Dolmatov              Expires June 12, 2010                [Page 8]
+
+
+Authors' Addresses
+
+
+Vasily Dolmatov, Ed.
+Cryptocom Ltd.
+Kedrova 14, bld.2
+Moscow, 117218, Russian Federation
+
+EMail: dol@cryptocom.ru
+
+Artem Chuprina
+Cryptocom Ltd.
+Kedrova 14, bld.2
+Moscow, 117218, Russian Federation
+
+EMail: ran@cryptocom.ru
+
+Igor Ustinov
+Cryptocom Ltd.
+Kedrova 14, bld.2
+Moscow, 117218, Russian Federation
+
+EMail: igus@cryptocom.ru
+
+V.Dolmatov              Expires June 12, 2010                [Page 9]
+
+
+
+
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt
deleted file mode 100644
index ee35cb91af8e..000000000000
--- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                             A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                      September 23, 2009
-
-Intended status: Draft Standard
-Obsoletes: RFC3597
-
-           Handling of Unknown DNS Resource Record (RR) Types
-                  draft-ietf-dnsext-rfc3597-bis-00.txt
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors. All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types should not requires changes to name server software.  This
-   document specifies how new RR types are transparently handled by DNS
-   software.
-
-
-
-
-Expires March 2010           Standards Track                    [Page 1]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-1.  Introduction
-
-   The DNS [RFC1034] is designed to be extensible to support new
-   services through the introduction of new resource record (RR) types.
-   Nevertheless, DNS implementations have historically required software
-   changes to support new RR types, not only at the authoritative DNS
-   server providing the new information and the client making use of it,
-   but also at all slave servers for the zone containing it, and in some
-   cases also at caching name servers and forwarders used by the client.
-   Because the deployment of new DNS software is slow and expensive,
-   this has been a significant impediment to supporting new services in
-   the DNS.
-
-   [RFC3597] defined DNS implementation behavior and procedures for
-   defining new RR types aimed at simplifying the deployment of new RR
-   types by allowing them to be treated transparently by existing
-   implementations.  Thanks to the widespread adoption of that
-   specification, much of the DNS is now capable of handling new record
-   types without software changes.
-
-   This document is a self-contained revised specification supplanting
-   and obsoleting [RFC3597].
-
-2.  Definitions
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   An "RR of unknown type" is an RR whose RDATA format is not known to
-   the DNS implementation at hand, and whose type is not an assigned
-   QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within
-   the range reserved in that section for assignment only to QTYPEs and
-   Meta-TYPEs.  Such an RR cannot be converted to a type-specific text
-   format, compressed, or otherwise handled in a type-specific way.
-
-   In the case of a type whose RDATA format is class specific, an RR is
-   considered to be of unknown type when the RDATA format for that
-   combination of type and class is not known.
-
-3.  Transparency
-
-   To enable new RR types to be deployed without server changes, name
-   servers and resolvers MUST handle RRs of unknown type transparently.
-   That is, they must treat the RDATA section of such RRs as
-   unstructured binary data, storing and transmitting it without change
-   [RFC1123].
-
-
-
-
-Expires March 2010           Standards Track                    [Page 2]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-   To ensure the correct operation of equality comparison (section 6)
-   and of the DNSSEC canonical form (section 7) when an RR type is known
-   to some but not all of the servers involved, servers MUST also
-   exactly preserve the RDATA of RRs of known type, except for changes
-   due to compression or decompression where allowed by section 4 of
-   this document.  In particular, the character case of domain names
-   that are not subject to compression MUST be preserved.
-
-4.  Domain Name Compression
-
-   RRs containing compression pointers in the RDATA part cannot be
-   treated transparently, as the compression pointers are only
-   meaningful within the context of a DNS message.  Transparently
-   copying the RDATA into a new DNS message would cause the compression
-   pointers to point at the corresponding location in the new message,
-   which now contains unrelated data.  This would cause the compressed
-   name to be corrupted.
-
-   To avoid such corruption, servers MUST NOT compress domain names
-   embedded in the RDATA of types that are class-specific or not well-
-   known.  This requirement was stated in [RFC1123] without defining the
-   term "well-known"; it is hereby specified that only the RR types
-   defined in [RFC1035] are to be considered "well-known".
-
-   Receiving servers MUST decompress domain names in RRs of well-known
-   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
-   NXT, NAPTR, and SRV to ensure interoperability with implementations
-   predating [RFC3597].
-
-   Specifications for new RR types that contain domain names within
-   their RDATA MUST NOT allow the use of name compression for those
-   names, and SHOULD explicitly state that the embedded domain names
-   MUST NOT be compressed.
-
-   As noted in [RFC1123], the owner name of an RR is always eligible for
-   compression.
-
-5.  Text Representation
-
-   In the "type" field of a master file line, an unknown RR type is
-   represented by the word "TYPE" immediately followed by the decimal RR
-   type number, with no intervening whitespace.  In the "class" field,
-   an unknown class is similarly represented as the word "CLASS"
-   immediately followed by the decimal class number.
-
-   This convention allows types and classes to be distinguished from
-   each other and from TTL values, allowing the "[] []
-    " and "[] []  " forms of
-
-
-
-Expires March 2010           Standards Track                    [Page 3]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-   [RFC1035] to both be unambiguously parsed.
-
-   The RDATA section of an RR of unknown type is represented as a
-   sequence of white space separated words as follows:
-
-      The special token \# (a backslash immediately followed by a hash
-      sign), which identifies the RDATA as having the generic encoding
-      defined herein rather than a traditional type-specific encoding.
-
-      An unsigned decimal integer specifying the RDATA length in octets.
-
-      Zero or more words of hexadecimal data encoding the actual RDATA
-      field, each containing an even number of hexadecimal digits.
-
-   If the RDATA is of zero length, the text representation contains only
-   the \# token and the single zero representing the length.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 2010           Standards Track                    [Page 4]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-   An implementation MAY also choose to represent some RRs of known type
-   using the above generic representations for the type, class and/or
-   RDATA, which carries the benefit of making the resulting master file
-   portable to servers where these types are unknown.  Using the generic
-   representation for the RDATA of an RR of known type can also be
-   useful in the case of an RR type where the text format varies
-   depending on a version, protocol, or similar field (or several)
-   embedded in the RDATA when such a field has a value for which no text
-   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
-   0.
-
-   Even though an RR of known type represented in the \# format is
-   effectively treated as an unknown type for the purpose of parsing the
-   RDATA text representation, all further processing by the server MUST
-   treat it as a known type and take into account any applicable type-
-   specific rules regarding compression, canonicalization, etc.
-
-   The following are examples of RRs represented in this manner,
-   illustrating various combinations of generic and type-specific
-   encodings for the different fields of the master file format:
-
-      a.example.   CLASS32     TYPE731         \# 6 abcd (
-                                               ef 01 23 45 )
-      b.example.   HS          TYPE62347       \# 0
-      e.example.   IN          A               \# 4 C0000201
-      e.example.   CLASS1      TYPE1           192.0.2.1
-
-6.  Equality Comparison
-
-   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
-   to be compared for equality.  Two RRs of the same unknown type are
-   considered equal when their RDATA is bitwise equal.  To ensure that
-   the outcome of the comparison is identical whether the RR is known to
-   the server or not, specifications for new RR types MUST NOT specify
-   type-specific comparison rules.
-
-   This implies that embedded domain names, being included in the
-   overall bitwise comparison, are compared in a case-sensitive manner.
-
-   As a result, when a new RR type contains one or more embedded domain
-   names, it is possible to have multiple RRs owned by the same name
-   that differ only in the character case of the embedded domain
-   name(s).  This is similar to the existing possibility of multiple TXT
-   records differing only in character case, and not expected to cause
-   any problems in practice.
-
-
-
-
-
-
-Expires March 2010           Standards Track                    [Page 5]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-7.  DNSSEC Considerations
-
-   The rules for the DNSSEC canonical form and ordering were updated to
-   support transparent treatment of unknown types in [RFC3597].  Those
-   updates have subsequently been integrated into the base DNSSEC
-   specification, such that the DNSSEC canonical form and ordering are
-   now specified in [RFC4034] or its successors rather than in this
-   document.
-
-8.  Additional Section Processing
-
-   Unknown RR types cause no additional section processing.  Future RR
-   type specifications MAY specify type-specific additional section
-   processing rules, but any such processing MUST be optional as it can
-   only be performed by servers for which the RR type in case is known.
-
-9.  IANA Considerations
-
-   This document does not require any IANA actions.
-
-10.  Security Considerations
-
-   This specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-11.  Normative References
-
-   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
-               Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC5395]   Eastlake, D., "Domain Name System (DNS) IANA
-               Considerations", BCP 42, RFC 5395, November 2008.
-
-12.  Informative References
-
-   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
-               Means for Expressing Location Information in the Domain
-               Name System", RFC 1876, January 1996.
-
-
-
-
-Expires March 2010           Standards Track                    [Page 6]
-
-draft-ietf-dnsext-rfc3597-bis-00.txt                           July 2009
-
-
-   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record
-               (RR) Types", RFC 3597, September 2003.
-
-   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
-               Rose, "Resource Records for the DNS Security Extensions",
-               RFC 4034, March 2005.
-
-14.  Author's Address
-
-   Andreas Gustafsson
-   Araneus Information Systems Oy
-   PL 110
-   02321 Espoo
-   Finland
-
-   Phone: +358 40 547 2099
-   EMail: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 2010           Standards Track                    [Page 7]
-
diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt
new file mode 100644
index 000000000000..b5877705eb98
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                             A. Gustafsson
+                                          Araneus Information Systems Oy
+                                                       February 24, 2010
+
+Intended status: Draft Standard
+Obsoletes: RFC3597
+
+           Handling of Unknown DNS Resource Record (RR) Types
+                  draft-ietf-dnsext-rfc3597-bis-02.txt
+
+Abstract
+
+   Extending the Domain Name System (DNS) with new Resource Record (RR)
+   types should not requires changes to name server software.  This
+   document specifies how new RR types are transparently handled by DNS
+   software.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that other
+   groups may also distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document. Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document. Code Components extracted from this document must
+
+
+
+Expires August 2010          Standards Track                    [Page 1]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   The DNS [RFC1034] is designed to be extensible to support new
+   services through the introduction of new resource record (RR) types.
+   Nevertheless, DNS implementations have historically required software
+   changes to support new RR types, not only at the authoritative DNS
+   server providing the new information and the client making use of it,
+   but also at all slave servers for the zone containing it, and in some
+   cases also at caching name servers and forwarders used by the client.
+   Because the deployment of new DNS software is slow and expensive,
+   this has been a significant impediment to supporting new services in
+   the DNS.
+
+   [RFC3597] defined DNS implementation behavior and procedures for
+   defining new RR types aimed at simplifying the deployment of new RR
+   types by allowing them to be treated transparently by existing
+   implementations.  Thanks to the widespread adoption of that
+   specification, much of the DNS is now capable of handling new record
+   types without software changes.  Another development that has
+   simplified the introduction of new DNS RR types is the adoption of a
+   simpler IANA allocation procedure for RR types [RFC5395].
+
+   This document is a self-contained revised specification supplanting
+   and obsoleting RFC 3597, with the aim of allowing the specification
+   to advance on the Standards Track.
+
+2.  Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   An "RR of unknown type" is an RR whose RDATA format is not known to
+   the DNS implementation at hand, and whose type is not an assigned
+   QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within
+   the range reserved in that section for assignment only to QTYPEs and
+   Meta-TYPEs.  Such an RR cannot be converted to a type-specific text
+   format, compressed, or otherwise handled in a type-specific way.
+
+   In the case of a type whose RDATA format is known to be class
+   specific, an RR is considered to be of unknown type when the RDATA
+   format for that combination of type and class is not known.
+
+3.  Transparency
+
+
+
+Expires August 2010          Standards Track                    [Page 2]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
+   To enable new RR types to be deployed without server changes, name
+   servers and resolvers MUST handle RRs of unknown type transparently.
+   The RDATA section of RRs of unknown type must be treated as
+   unstructured binary data, and must be stored and transmitted without
+   change ([RFC1123], section 6.1.3.5).
+
+   To ensure the correct operation of equality comparison (section 6)
+   and of the DNSSEC canonical form (section 7) when an RR type is known
+   to some but not all of the servers involved, servers MUST also
+   exactly preserve the RDATA of RRs of known type, except for changes
+   due to compression or decompression where allowed by section 4 of
+   this document.  In particular, the character case of domain names
+   that are not subject to compression MUST be preserved.
+
+4.  Domain Name Compression
+
+   RRs containing compression pointers in the RDATA part cannot be
+   treated transparently, as the compression pointers are only
+   meaningful within the context of a DNS message.  Transparently
+   copying the RDATA into a new DNS message would cause the compression
+   pointers to point at the corresponding location in the new message,
+   which now contains unrelated data.  This would cause the compressed
+   name to be corrupted.
+
+   To avoid such corruption, servers MUST NOT compress domain names
+   embedded in the RDATA of types that are class-specific or not well-
+   known.  This requirement was stated in [RFC1123] without defining the
+   term "well-known"; it is hereby specified that only the RR types
+   defined in [RFC1035] are to be considered "well-known".
+
+   Receiving servers MUST decompress domain names in RRs of well-known
+   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
+   NXT, SRV, and NAPTR to ensure interoperability with implementations
+   predating [RFC3597].
+
+   Specifications for new RR types that contain domain names within
+   their RDATA MUST NOT allow the use of name compression for those
+   names, and SHOULD explicitly state that the embedded domain names
+   MUST NOT be compressed.
+
+   As noted in [RFC1123], the owner name of an RR is always eligible for
+   compression.
+
+5.  Text Representation
+
+   In the "type" field of a master file line, an unknown RR type is
+   represented by the word "TYPE" immediately followed by the decimal RR
+   type number, with no intervening whitespace.  In the "class" field,
+
+
+
+Expires August 2010          Standards Track                    [Page 3]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
+   an unknown class is similarly represented as the word "CLASS"
+   immediately followed by the decimal class number.
+
+   This convention allows types and classes to be distinguished from
+   each other and from TTL values, allowing the "[] []
+    " and "[] []  " forms of
+   [RFC1035] section 5.1 to both be unambiguously parsed.
+
+   The RDATA section of an RR of unknown type is represented as a
+   sequence of items separated by any combination of tabs and spaces, as
+   follows:
+
+     - The special token \# (a backslash immediately followed by a hash
+       sign), which identifies the RDATA as having the generic encoding
+       defined herein rather than a traditional type-specific encoding.
+
+     - An unsigned decimal integer specifying the RDATA length in
+       octets.
+
+     - Zero or more items of hexadecimal data encoding the actual RDATA
+       field, each item containing an even number of hexadecimal digits.
+
+   If the RDATA is of zero length, the text representation contains only
+   the \# token and the single zero representing the length.
+
+   An implementation MAY also choose to represent some RRs of known type
+   using the above generic representations for the type, class and/or
+   RDATA, which carries the benefit of making the resulting master file
+   portable to servers where these types are unknown.  Using the generic
+   representation for the RDATA of an RR of known type can also be
+   useful in the case of an RR type where the text format varies
+   depending on a version, protocol, or similar field (or several)
+   embedded in the RDATA when such a field has a value for which no text
+   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
+   0.
+
+   Even though an RR of known type represented in the \# format is
+   effectively treated as an unknown type for the purpose of parsing the
+   RDATA text representation, all further processing by the server MUST
+   treat it as a known type and take into account any applicable type-
+   specific rules regarding compression, canonicalization, etc.
+
+   The following are examples of RRs represented in this manner,
+   illustrating various combinations of generic and type-specific
+   encodings for the different fields of the master file format:
+
+      a.example.   CLASS32     TYPE731         \# 6 abcd (
+                                               ef 01 23 45 )
+
+
+
+Expires August 2010          Standards Track                    [Page 4]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
+      b.example.   HS          TYPE62347       \# 0
+      e.example.   IN          A               \# 4 C0000201
+      e.example.   CLASS1      TYPE1           192.0.2.1
+
+6.  Equality Comparison
+
+   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
+   to be compared for equality.  Two RRs of the same unknown type are
+   considered equal when their RDATA is bitwise equal.  To ensure that
+   the outcome of the comparison is identical whether the RR is known to
+   the server or not, specifications for new RR types MUST NOT specify
+   type-specific comparison rules.
+
+   This implies that embedded domain names, being included in the
+   overall bitwise comparison, are compared in a case-sensitive manner.
+
+   As a result, when a new RR type contains one or more embedded domain
+   names, it is possible to have multiple RRs owned by the same name
+   that differ only in the character case of the embedded domain
+   name(s).  This is similar to the existing possibility of multiple TXT
+   records differing only in character case, and not expected to cause
+   any problems in practice.
+
+7.  DNSSEC Considerations
+
+   The rules for the DNSSEC canonical form and ordering were updated to
+   support transparent treatment of unknown types in [RFC3597].  Those
+   updates have subsequently been integrated into the base DNSSEC
+   specification, such that the DNSSEC canonical form and ordering are
+   now specified in [RFC4034] or its successors rather than in this
+   document.
+
+8.  Additional Section Processing
+
+   Unknown RR types cause no additional section processing.  Future RR
+   type specifications MAY specify type-specific additional section
+   processing rules, but any such processing MUST be optional as it can
+   only be performed by servers for which the RR type in case is known.
+
+9.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+10.  Security Considerations
+
+   This specification is not believed to cause any new security
+   problems, nor to solve any existing ones.
+
+
+
+
+Expires August 2010          Standards Track                    [Page 5]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
+11.  Normative References
+
+   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
+               Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5395]   Eastlake, D., "Domain Name System (DNS) IANA
+               Considerations", BCP 42, RFC 5395, November 2008.
+
+12.  Informative References
+
+   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
+               Means for Expressing Location Information in the Domain
+               Name System", RFC 1876, January 1996.
+
+   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record
+               (RR) Types", RFC 3597, September 2003.
+
+   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
+               Rose, "Resource Records for the DNS Security Extensions",
+               RFC 4034, March 2005.
+
+14.  Author's Address
+
+   Andreas Gustafsson
+   Araneus Information Systems Oy
+   PL 110
+   02321 Espoo
+   Finland
+
+   Phone: +358 40 547 2099
+   EMail: gson@araneus.fi
+
+Appendix A. Summary of Changes Since RFC3597
+
+   This section summarizes the major changes between RFC3597 and this
+
+
+
+Expires August 2010          Standards Track                    [Page 6]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
+   document.  In addition to the changes listed below, there has also
+   been a number of editorial changes, such as updates to the text in
+   the Abstract and Introduction to better reflect the current state of
+   implementation, updates to boilerplate text, and minor
+   clarifications.
+
+   The reference to the DNS IANA Considerations BCP (BCP42) has been
+   changed from RFC2929 to the current version, RFC5395.
+
+   Downward references have been eliminated; specifically, the document
+   no longer refers to RFC2163 or RFC2535.
+
+   IP addresses in examples have been changed to use the 192.0.2.0/24
+   range per RFC3330.
+
+   The document no longer specifies changes to the DNSSEC canonical form
+   and ordering, as those changes have now been incorporated into the
+   base DNSSEC specification.
+
+Appendix B. Detailed Change Log
+
+   [NOTE TO RFC EDITOR:  PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
+
+B.1.  Changes between RFC3597 and -00
+
+   The reference to the DNS IANA Considerations BCP (BCP42) has been
+   changed from RFC2929 to the current version, RFC5395.
+
+   Downward references have been eliminated; specifically, the document
+   no longer refers to RFC2163 or RFC2535.
+
+   IP addresses in examples have been changed to use the 192.0.2.0/24
+   range per RFC3330.
+
+   The document no longer specifies changes to the DNSSEC canonical form
+   and ordering, as those changes have now been incorporated into the
+   base DNSSEC specification.
+
+   There has also been a number of editorial changes, such as updates to
+   the text in the Abstract and Introduction to better reflect the
+   current state of implementation.
+
+B.2.  Changes between -00 and -01
+
+   Moved the Abstract to immediately following the document title.
+
+   Updated boilerplate to the current version.
+
+
+
+
+Expires August 2010          Standards Track                    [Page 7]
+
+draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
+
+
+   In the Introduction, the text "Another development that has
+   simplified the introduction of new DNS RR types is the adoption of a
+   simpler IANA allocation procedure for RR types" and a reference to
+   [RFC5395] were added.
+
+   In the Introduction, the text "with the aim of allowing the
+   specification to advance on the Standards Track" was added to explain
+   the motivation for the draft.
+
+   In section 2, the text "is class specific" was replaced by "is known
+   to be class specific".
+
+   In section 3, the words "That is" were removed so as not to imply
+   that the transparent treatment of RRs of unknown type is only a
+   matter of how the RDATA field is handled.  The remainder of the
+   sentence was rephrased.
+
+   In section 4, the entries for SRV and NAPTR in the list of RR types
+   to decompress were swapped to make the list consistently ordered by
+   ascending numerical RR type.
+
+   References to RFC 1035 and RFC 1123 now include the specific section
+   numbers being referenced.
+
+   A Change History was added as Appendix A.
+
+B.3. Changes between -01 and -02
+
+   In section 5, the term "white space" was replaced by "any combination
+   of tabs and spaces", and the term "word" was replaced by "item", for
+   consistency with RFC1035 terminology.
+
+   In section 5, hyphens were added to mark the beginning of each item
+   in the the list of items comprising the RDATA text representation.
+
+   The Change History was split into a Summary of Changes Since RFC3597
+   (Appendix A) intended to remain in the document when published as an
+   RFC, and a Detailed Change Log (Appendix B) to be deleted on
+   publication.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires August 2010          Standards Track                    [Page 8]
+
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt
new file mode 100644
index 000000000000..c06705b0a714
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt
@@ -0,0 +1,504 @@
+
+
+
+Domain Name System Operations                              W. Wijngaards
+Internet-Draft                                                O. Kolkman
+Intended status: Standards Track                              NLnet Labs
+Expires: August 26, 2010                               February 22, 2010
+
+
+                  DNSSEC Trust Anchor History Service
+                draft-ietf-dnsop-dnssec-trust-history-01
+
+Abstract
+
+   When DNS validators have trusted keys, but have been offline for a
+   longer period, key rollover will fail and they are stuck with stale
+   trust anchors.  History service allows validators to query for older
+   DNSKEY RRsets and pick up the rollover trail where they left off.
+
+Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Status of This Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 26, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 1]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+1.  Introduction
+
+   This memo defines a trust history service for DNS validators -- the
+   component in a resolver that performs DNSSEC [RFC4034] validation,
+   validator for short.
+
+   A validator that has been offline or missed an (emergency) rollover
+   can use this service to reconfigure themselves with the current
+   trust-anchor.  Using a newly defined resource record (RR) that links
+   old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
+   RRsets and checks they form a chain to the latest key (see
+   Section 2).  The lists of old DNSKEYS, linked with the TALINK RRs, do
+   not necessarily need to be published in the zone for which the DNSKEY
+   history is being maintained but can be published in any DNS domain.
+   We will call the entity that offers the trust history the History
+   Provider.  The choice of the History Provider is made by the
+   maintainer of the validator, possibly based on a hint provided, using
+   the TALINK, by the zone owner.
+
+   The algorithm that the validator uses to construct a history and
+   reconfigure a new key is detailed in Section 3.  The algorithms for
+   how providers of trust history can fetch the DNSKEY data as published
+   by the zone they track and publish that are explained in Section 4.
+
+2.  The  TALINK Resource Record
+
+   The DNS Resource Record type TALINK (decimal 58) ties the elements of
+   a linked list of DNSKEY RRs together.
+
+   The rdata consists of two domain names.  The first name is the start,
+   or previous name, and the other name the end or next name in the
+   list.  The empty label '.' is used at the endpoints of the list.
+
+   The presentation format is the two domain names.  The wire encoding
+   is the two domain names, with no compression so the type can be
+   treated according to [RFC3597].  The list is a double linked list,
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 2]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   because this empowers low memory hosts to perform consistency checks.
+
+3.  Trust History Lookup
+
+   This is the algorithm that a validator uses to detect and resolve the
+   situation in which a trust-anchor is out of sync with the DNSKEYs
+   published by a zone owner.  The algorithm uses the TALINK RR type
+   which is used to link various old DNSKEYs as published by the History
+   Provider, to arrive from the outdated configured Trust Anchor to one
+   that matches the current DNSKEY.  The TALINK RR type is defined in
+   Section 2.
+
+   When the algorithm below results in failure the trust history cannot
+   be build and a new trust anchor will need to be re-configured using
+   another mechanism.
+
+   Step 1:  The validator performs a DNSKEY lookup to the target zone,
+      which looks like any other initial DNSKEY lookup that the
+      validator needs to match a trust anchor to the currently used
+      DNSKEY RR set.  If the keyset verifies with the trust anchor
+      currently held, the trust-anchor is not out of sync.  Otherwise,
+      store the DNSKEY RR set as result.  The algorithm will
+      successfully build a linked list to this DNSKEY RR, or delete the
+      trust point, or fail.
+
+      All nameservers (the ones authoritative for the zone or the
+      upstream resolver caches when the validator is not full resolver)
+      SHOULD be checked to make sure the DNSKEY RR sets are the same.
+      The results can differ if a key-rollover is in progress and not
+      all nameservers are in sync yet.  This case can be detected by
+      checking that the older keyset signs the newer and take the newer
+      as result keyset.  The keysets are distinguished by the average
+      over the middle of the inception and expiration dates of the
+      signatures that are validated by the keyset itself.  Otherwise,
+      the history lookup fails.  If the check fails then the
+      inconsistency may be the result of spoofing, or compromise of
+      (DNS) infrastructure elements.
+
+   Step 2:  Fetch the trust history list end points.  Perform a query of
+      QTYPE TALINK and QNAME the domain name that is configured to be
+      the History Provider for the particular domain you are trying to
+      update the trust-anchor for.
+
+   Step 3:  Go backwards through the trust history list as provided by
+      the TALINK linked list.  Verify that the keyset validly signs the
+      next keyset.  This is [RFC4034] validation, but the RRSIG
+      expiration date is ignored.  [Editor note: Are we shure that there
+      are no server implementations that will not serve expired RRSIG,
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 3]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+      are such 'smart' servers allowed by the specs?  In other words do
+      we need clarification in the DNSSEC-updates document?]  Replace
+      the owner domain name with the target zone name for verification.
+      One of the keys that signs the next keyset MUST have the SEP bit
+      set.  The middle of inception and expiration date from the valid
+      signature MUST be older than that of the signature that validates
+      the next keys in the list.  Query type TALINK to get previous and
+      next locations.
+
+      If all SEP keys have the REVOKE flag set at this step, and the
+      keyset is signed by all SEP keys, then continue but store that the
+      end result is that the trust point is deleted, see Section 5
+      [RFC5011].
+
+      If all SEP keys are of an unknown algorithm at this step, continue
+      and at the next step, when you verify if the keyset signs validly:
+      if false, continue with result a failure, if true, continue with
+      the end result that the trust point is deleted.  Thus, the keysets
+      with unknown algorithms are stepped over with an end result of
+      failure because the validator cannot determine if unknown
+      algorithm signatures are valid, until the oldest keyset with
+      unknown algorithms is signed by a known algorithm and the result
+      is set to deletion and step 3 continues to a known key.
+
+   Step 4:  When the trust anchor currently held by the validator
+      verifies the keyset, the algorithm is done.  The validator SHOULD
+      store the result on stable storage.  Use the new trust anchor for
+      validation (if using [RFC5011], put it in state VALID).
+
+4.  Trust History Tracker
+
+   External trackers can poll the target zone DNSKEY RRset regularly.
+   Ignore date changes in the RRSIG.  Ignore changes to keys with no SEP
+   flag.  Copy the newly polled DNSKEY RRset and RRSIGs, change the
+   owner name to a new name at the history location.  Publish the new
+   RRset and TALINK records to make it the last element in the list.
+   Update the TALINK that advertises the first and last name.
+
+   Integrated into the rollover, the keys are stored in the history and
+   the TALINK is updated when a new key is used in the rollover process.
+   This gives the TALINK and new historical key time to propagate.
+
+   The signer can support trust history.  Trust history key sets need
+   only contain SEP keys.  To use older signers, move historical RRSIGs
+   to another file.  Sign the zone, including the TALINK and DNSKEY
+   records.  Append the historical RRSIGs to the result.  Signing the
+   zone like this obviates the need for changes to signer and server
+   software.
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 4]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+5.  Example
+
+   In this example example.com is the History Provider for example.net.
+   The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
+   and paste of the data from example.net.
+
+   $ORIGIN example.com.
+   example.com. TALINK h0.example.com. h2.example.com.
+
+   h0 TALINK . h1.example.com.
+   h0 DNSKEY ...
+   h0 RRSIG ...
+
+   h1 TALINK h0.example.com. h2.example.com.
+   h1 DNSKEY ...
+   h1 RRSIG ...
+
+   h2 TALINK h1.example.com. .
+   h2 DNSKEY ...
+   h2 RRSIG ...
+
+   The example.net zone can advertise the example.com History Provider
+   by providing the TALINK shown here at example.com at the apex of the
+   example.net zone.  The TALINK at example.com is then not needed.
+
+6.  Deployment
+
+   The trust history is advertised with TALINK RRs at the zone apex.
+   These represent alternative history sources, that can be searched in
+   turn.  The TALINK at the zone apex contains the first and last name
+   of the list of historical keys.
+
+   The historical list of keys grows perpetually.  Since most validators
+   have recent keys, their processing time remains similar as the list
+   grows.  If validators no longer have trust in the keys then they need
+   no longer be published.  The oldest key entries can be omitted from
+   the list to shorten it.
+
+   The validator decides how long it trusts a key.  A recommendation
+   from the zone owner can be configured for keys of that zone, or
+   recommendations per algorithm and key size can be used (e.g. see
+   [NIST800-57]).  If a key is older than that, trust history lookup
+   fails with it and the trust point can be considered deleted.  This
+   assumes the validator has decided on a security policy and also can
+   take actions when the update of the trust anchor fails.  Without such
+   policy, or if the alternative is no DNSSEC, the approach below can be
+   used.
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 5]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   In general, the decision can be that any key - no matter how old or
+   how small - is better than no security.  The validator then never
+   considers a key too old, and the lookup algorithm becomes an
+   unsecured update mechanism at the time where the key can be trivially
+   broken.  The history provider SHOULD provide these broken keys to
+   facilitate clients performing the unsecured update.  If a key can not
+   be trivially broken then it provides a non-trivial amount of security
+   that the history lookup algorithm uses to get the current keys.
+   Conceivably after the update the result is stored on stable storage
+   and the client is thereafter safe - it performs a leap of faith.  The
+   validator operator can opt for this set up after considering the
+   trade-off between loss of DNSSEC, loss of connectivity, and the
+   argument that perceived security is worse than no security.
+
+   The history lookup can be used on its own.  Then, the trust history
+   is used whenever the key rolls over and no polling is performed.
+   This has associated risks, in that the immediate rollover without
+   timeout that it provides could be abused, and certainly when taken
+   together with leap-of-faith such systems SHOULD inform their user
+   that the key has changed and urge them to do immediate checks.
+   Initially we put a hold down timer on such rollovers to mitigate the
+   abuse risks but these make following normal rollovers impossible.
+
+   If a validator is also using [RFC5011] for the target zone, then the
+   trust history algorithm SHOULD only be invoked if the [RFC5011]
+   algorithm failed due to the inability to perform probes.  This is the
+   case when the last [RFC5011] successful probe was more than 30 days
+   ago.  If a new key has been announced, invoke the history if no 2
+   probes succeeded during the add hold-down time and there was no
+   successful probe after the add hold-down time passed.  Therefore the
+   time of the last successful probe MUST be stored on stable storage.
+
+   For testing the potentially very infrequently used lookup, the
+   following SHOULD be implemented.  For the test the lookup is
+   triggered manually by allowing the system to be given a particular
+   keyset with a last successful lookup date in the past and a test
+   History Provider.  The test History Provider provides access to a
+   generated back-dated test history.
+
+7.  Security Considerations
+
+   The History Provider only provides copies of old data.  If that
+   historic data is altered or withheld the lookup algorithm fails
+   because of validation errors in Step 3 of the algorithm.  If the
+   History provider or a Man in the Middle Adversary (MIMA) has access
+   to the original private keys (through theft, cryptanalisis, or
+   otherwise), history can be altered without failure of the algorithm.
+   Below we only consider MIMAs and assume the History Provider is a
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 6]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   trusted party.
+
+   Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
+   TALINK and DNSKEY data, can present some alternate history.  However
+   the DNSKEY RR set trusted that the history should arrive at is
+   already fixed by step 1.  If an attempt is made to subvert the
+   algorithm at step 2 or 3, then the result keyset can not be replaced
+   by another keyset unnoticed.
+
+   To change the keyset trusted as the outcome, the step 1 data has to
+   be spoofed and the key held by the validator (or a newer historic
+   key) has to be compromised.  Unless such spoof is targeted to a
+   specific victim, a spoof of the step 1 result has a high visibility.
+   Since most of the validators that receive the spoof have an up-to-
+   date trust anchor most validators that would receive this spoof
+   return validation failure for data from the zone that contains the
+   DNSKEYs.  An adversary will therefore have to target the attack to
+   validators that are in the process of an update.  Since validators do
+   not announce that they use trust history lookup until step 2
+   adversaries will not be able to select the validators.
+
+   A spoof of data in steps 2 and 3, together with a compromised (old)
+   key, can result in a downgrade.  At steps 2 and 3 a faked trust point
+   deletion or algorithm rollover can be inserted in a fake history.
+   This avoids the high visibility of spoofing the current key (see
+   previous paragraph) and downgrades to insecure.
+
+   Finally there is the case that one of the keys published by the
+   History Providers has been compromised.  Since someone spoofing at
+   step 1 of the lookup algorithm and presenting some fake history to a
+   compromised key, of course does not include key revocations and does
+   extend the history to contain the compromised key, it therefore is
+   not really useful for a History Provider to remove the key from the
+   published history.  That only makes lookups fail for those validators
+   who are not under attack.  Useful action could be to update
+   validators using some other means.
+
+   Rollover with [RFC5011] revokes keys after use.  If a History
+   Provider is used, then such revoked keys SHOULD be used to perform
+   history tracking and history lookup.  The old keys that the validator
+   starts with and final current keys MUST NOT be trusted if they are
+   revoked.
+
+   Depending on choices by the validator operator, it may accept a leap-
+   of-faith, and possibly allow non-hold-down rollovers.  Although this
+   allows very fast emergency rollover if all clients are known to do
+   trust-history lookups without the RFC5011-algorithm, it also allows
+   an attacker with the private key to attempt to take over a zone
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 7]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   quickly and get validators to roll to a trust anchor of the
+   attacker's choosing.
+
+   The SEP bit is checked to make sure that control over the KSK is
+   necessary to change the keyset for the target zone.
+
+   The algorithm can be used to get the inception and expiration times
+   of signatures on the current keyset, a clock.  A MIMA can attempt to
+   shorten history and put back that clock, but the algorithm attempts
+   to make this difficult to target and highly visible to others.
+
+   If the clock of the validator can be influenced, then setting it
+   forward is unlikely to give advantage, but setting it backward
+   enables a replay attack of old DNSSEC data and signatures.  This
+   vulnerability exists also in plain DNSSEC.
+
+8.  IANA Considerations
+
+   Resource record type TALINK has been defined using RFC5395 expert
+   review, it has RR type number 58 (decimal).
+
+9.  Acknowledgments
+
+   Thanks to the people who provided review and suggestions, Joe Abley,
+   George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
+   Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
+   Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
+   Matthijs Mekking.
+
+10.  References
+
+10.1.  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.
+
+   [RFC5011]     StJohns, M., "Automated Updates of DNS Security
+                 (DNSSEC) Trust Anchors", RFC 5011, September 2007.
+
+10.2.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3597]     Gustafsson, A., "Handling of Unknown DNS Resource
+                 Record (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 8]
+
+Internet-Draft            Trust History Service            February 2010
+
+
+   [RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                 Rose, "Resource Records for the DNS Security
+                 Extensions", RFC 4034, March 2005.
+
+Authors' Addresses
+
+   Wouter Wijngaards
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: wouter@nlnetlabs.nl
+
+
+   Olaf Kolkman
+   NLnet Labs
+   Science Park 140
+   Amsterdam  1098 XG
+   The Netherlands
+
+   EMail: olaf@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijngaards & Kolkman     Expires August 26, 2010                [Page 9]
+
diff --git a/doc/draft/draft-kerr-ixfr-only-01.txt b/doc/draft/draft-kerr-ixfr-only-01.txt
new file mode 100644
index 000000000000..837b255f1f76
--- /dev/null
+++ b/doc/draft/draft-kerr-ixfr-only-01.txt
@@ -0,0 +1,336 @@
+
+
+
+DNSext Working Group                                             O. Sury
+Internet-Draft                                                    CZ.NIC
+Updates: 1995 (if approved)                                 S. Kerr, Ed.
+Intended status: Standards Track                                     ISC
+Expires: August 30, 2010                               February 26, 2010
+
+
+               IXFR-ONLY to Prevent IXFR Fallback to AXFR
+                        draft-kerr-ixfr-only-01
+
+Abstract
+
+   This documents proposes a new QTYPE (Query pseudo RRtype) for the
+   Domain Name System (DNS).  IXFR-ONLY is a variant of IXFR (RFC 1995)
+   that allows an authoritative server to incrementally update zone
+   content from another (primary) server without falling back from IXFR
+   to AXFR.  This way, alternate peers can be contacted more quickly and
+   convergence of zone content may be achieved much faster in important,
+   resilient operational scenarios.
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 30, 2010.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 1]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
+   2.  IXFR Server Side  . . . . . . . . . . . . . . . . . . . . . . . 4
+   3.  IXFR Client Side  . . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  Applicability of IXFR-ONLY  . . . . . . . . . . . . . . . . . . 5
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 2]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+1.  Introduction
+
+   For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
+   Transfer (IXFR), which allows only to transfer the changed portion(s)
+   of a zone.
+
+   In the document, an IXFR client and an IXFR server is defined as in
+   RFC 1995 [RFC1995], a secondary name server which requests IXFR is
+   called an IXFR client and a primary or secondary name server which
+   responds to the request is called an IXFR server.
+
+   IXFR is an efficient way to transfer changes in zones from IXFR
+   servers to IXFR clients.  However, when an IXFR client has multiple
+   IXFR servers for a single zone, it is possible that not all IXFR
+   servers have the zone with same serial number for that zone.  In this
+   case, if an IXFR client attempts an IXFR from an IXFR server which
+   does not have zone with the serial number used by the IXFR client,
+   the IXFR server will fall back to a full zone transfer (AXFR) when it
+   has a version of the zone with serial number greater than the serial
+   requested by the IXFR client.
+
+   For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
+   a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
+   same zone.  An IXFR client that has the zone with serial number 2
+   which sends an IXFR request to IXFR server NS2 will get a full zone
+   transfer (AXFR) of the zone at serial number 3.  This is because NS2
+   does not know the zone with serial number 2, and therefore does not
+   know what the differences are between zone with serial number 2 and
+   3.
+
+   If the IXFR client in this example had known to send the query to
+   IXFR server NS1, then it could have gotten an incremental transfer
+   (IXFR).  But IXFR clients can only know what the latest version of
+   the zone is at a IXFR server (this information is available via an
+   SOA query).
+
+   The IXFR-ONLY query type provides a way for the IXFR client to ask
+   each IXFR server to return an error instead of sending the current
+   version of the zone via full zone transfer (AXFR).  By using this, a
+   IXFR client can check each IXFR server until it finds one able to
+   provide IXFR.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 3]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+2.  IXFR Server Side
+
+   A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
+   as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
+   for the serial number requested.
+
+   If the IXFR server is is not able to reply with an IXFR it MUST NOT
+   reply with an AXFR unless AXFR result is smaller than IXFR result.
+   Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
+
+   If the IXFR result is larger than an AXFR, then an IXFR server MAY
+   reply with an AXFR result instead.  This is an optimization, and IXFR
+   servers MAY only reply with AXFR if they are certain that the reply
+   using AXFR is smaller than an equivalent IXFR reply.
+
+
+3.  IXFR Client Side
+
+   An IXFR client who wishes to use IXFR-ONLY will send a message to one
+   of the IXFR servers.  The format is exactly the same as for IXFR,
+   except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
+   code.
+
+   If the IXFR server replies with IXFR, then the IXFR client is done.
+
+   If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
+   client proceeds on to a different IXFR server.  In this case the IXFR
+   server implements IXFR-ONLY, but does not have information about zone
+   with the serial number requested.
+
+   If the IXFR server replies with any RCODE other than CannotIXFR or
+   NoError, then the IXFR client proceeds on to a different IXFR server.
+   In this case the IXFR server does not implement IXFR-ONLY.
+
+   If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
+   them reply with an incremental transfer (IXFR), then it should
+   attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
+   IXFR servers which replied with an RCODE other than CannotIXFR or
+   NoError.
+
+   The method described above allows IXFR clients to operate normally in
+   situatians where some of the IXFR servers do support IXFR-ONLY, and
+   some who do not.  IXFR clients MAY remember which IXFR servers
+   support IXFR-ONLY and query those IXFR servers first.  However since
+   IXFR servers may change software or even run a mix of software, IXFR
+   clients MUST attempt to query each IXFR server periodically when they
+   attempt to get new versions of a zone.
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 4]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+   given IXFR server, if this is known in advance.  These IXFR servers
+   are treated as if they replied with an RCODE other than CannotIXFR or
+   NoError, although no query with IXFR-ONLY is actually sent.
+
+
+4.  Applicability of IXFR-ONLY
+
+   Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
+   completely.
+
+   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
+   specific zone.  This may be useful for small zones, where fallback to
+   AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
+
+   Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
+   servers, by shifting load to ones that support IXFR-ONLY.  If this a
+   problem, then administrators can disable IXFR-ONLY in implementations
+   that allow it.
+
+   If a IXFR client has a single IXFR server for a zone, it SHOULD use
+   IXFR rather than IXFR-ONLY.
+
+
+5.  IANA Considerations
+
+   IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
+   transfer only".  IANA allocates the CannotIXFR RCODE, which means
+   "Server cannot provide IXFR for zone".
+
+
+6.  Security Considerations
+
+   IXFR-ONLY may be used by someone to get information about the state
+   of IXFR servers by providing a quick and efficient way to check which
+   versions of a zone each IXFR server supports.  Zones should be
+   secured via TSIG [RFC2845] to prevent unauthorized information
+   exposure.  However, even administrators of IXFR servers may not want
+   this information given to IXFR clients, in which case they will need
+   to disable IXFR-ONLY.
+
+
+7.  Normative References
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 5]
+
+Internet-Draft                  IXFR-ONLY                  February 2010
+
+
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+
+Authors' Addresses
+
+   Ondrej Sury
+   CZ.NIC
+   Americka 23
+   120 00 Praha 2
+   CZ
+
+   Phone: +420 222 745 110
+   Email: ondrej.sury@nic.cz
+
+
+   Shane Kerr (editor)
+   ISC
+   Bennebrokestraat 17-I
+   1015 PE Amsterdam
+   NL
+
+   Phone: +31 64 6336297
+   Email: shane@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sury & Kerr              Expires August 30, 2010                [Page 6]
+
diff --git a/lib/dns/include/dns/rdataset.h b/lib/dns/include/dns/rdataset.h
index 2749f8a80eb9..4d3578cc496a 100644
--- a/lib/dns/include/dns/rdataset.h
+++ b/lib/dns/include/dns/rdataset.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.h,v 1.51.18.9 2009/01/19 23:46:16 tbox Exp $ */
+/* $Id: rdataset.h,v 1.51.18.11 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RDATASET_H
 #define DNS_RDATASET_H 1
@@ -104,6 +104,9 @@ typedef struct dns_rdatasetmethods {
 						 dns_rdataset_t *rdataset,
 						 dns_rdatasetadditional_t type,
 						 dns_rdatatype_t qtype);
+	void			(*settrust)(dns_rdataset_t *rdataset,
+					    dns_trust_t trust);
+	void			(*expire)(dns_rdataset_t *rdataset);
 } dns_rdatasetmethods_t;
 
 #define DNS_RDATASET_MAGIC	       ISC_MAGIC('D','N','S','R')
@@ -592,6 +595,19 @@ dns_rdataset_putadditional(dns_acache_t *acache,
  *			  information for 'rdataset.'
  */
 
+void
+dns_rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust);
+/*%<
+ * Set the trust of the 'rdataset' to trust in any in the backing database.
+ * The local trust level of 'rdataset' is also set.
+ */
+
+void
+dns_rdataset_expire(dns_rdataset_t *rdataset);
+/*%<
+ * Mark the rdataset to be expired in the backing database.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RDATASET_H */
diff --git a/lib/dns/include/dns/resolver.h b/lib/dns/include/dns/resolver.h
index 3fce33665c48..5ea1d6990e3e 100644
--- a/lib/dns/include/dns/resolver.h
+++ b/lib/dns/include/dns/resolver.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.h,v 1.40.18.13 2009/09/24 23:46:07 tbox Exp $ */
+/* $Id: resolver.h,v 1.40.18.15 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RESOLVER_H
 #define DNS_RESOLVER_H 1
@@ -491,6 +491,48 @@ dns_resolver_getzeronosoattl(dns_resolver_t *resolver);
 void
 dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state);
 
+void
+dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *expire);
+/*%<
+ * Add a entry to the bad cache for  that will expire at 'expire'.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ * \li	name to be valid.
+ */
+
+isc_boolean_t
+dns_resolver_getbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *now);
+/*%<
+ * Check to see if there is a unexpired entry in the bad cache for
+ * .
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ * \li	name to be valid.
+ */
+
+void
+dns_resolver_flushbadcache(dns_resolver_t *resolver, dns_name_t *name);
+/*%<
+ * Flush the bad cache of all entries at 'name' if 'name' is non NULL.
+ * Flush the entire bad cache if 'name' is NULL.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ */
+
+void
+dns_resolver_printbadcache(dns_resolver_t *resolver, FILE *fp);
+/*%
+ * Print out the contents of the bad cache to 'fp'.
+ *
+ * Requires:
+ * \li	resolver to be valid.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RESOLVER_H */
diff --git a/lib/dns/include/dns/result.h b/lib/dns/include/dns/result.h
index db5481b34c36..a43207e50876 100644
--- a/lib/dns/include/dns/result.h
+++ b/lib/dns/include/dns/result.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.104.10.6 2005/06/17 02:04:32 marka Exp $ */
+/* $Id: result.h,v 1.104.10.8 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_RESULT_H
 #define DNS_RESULT_H 1
@@ -147,8 +147,11 @@
 #define DNS_R_COVERINGNSEC		(ISC_RESULTCLASS_DNS + 101)
 #define DNS_R_MXISADDRESS		(ISC_RESULTCLASS_DNS + 102)
 #define DNS_R_DUPLICATE			(ISC_RESULTCLASS_DNS + 103)
+#define DNS_R_INVALIDNSEC3		(ISC_RESULTCLASS_DNS + 104)
+#define DNS_R_NOTMASTER			(ISC_RESULTCLASS_DNS + 105)
+#define DNS_R_BROKENCHAIN		(ISC_RESULTCLASS_DNS + 106)
 
-#define DNS_R_NRESULTS			104	/*%< Number of results */
+#define DNS_R_NRESULTS			107	/*%< Number of results */
 
 /*
  * DNS wire format rcodes.
diff --git a/lib/dns/include/dns/validator.h b/lib/dns/include/dns/validator.h
index 9708cc4ce7eb..befee5d66a40 100644
--- a/lib/dns/include/dns/validator.h
+++ b/lib/dns/include/dns/validator.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.h,v 1.27.18.13 2009/01/19 00:36:28 marka Exp $ */
+/* $Id: validator.h,v 1.27.18.15 2010/02/26 23:46:37 tbox Exp $ */
 
 #ifndef DNS_VALIDATOR_H
 #define DNS_VALIDATOR_H 1
@@ -151,6 +151,8 @@ struct dns_validator {
 	isc_boolean_t			mustbesecure;
 	unsigned int			dlvlabels;
 	unsigned int			depth;
+	unsigned int			authcount;
+	unsigned int			authfail;
 };
 
 /*%
diff --git a/lib/dns/ncache.c b/lib/dns/ncache.c
index 1fdc5c80e2d0..89106dad7c06 100644
--- a/lib/dns/ncache.c
+++ b/lib/dns/ncache.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ncache.c,v 1.36.18.3 2005/04/29 00:15:59 marka Exp $ */
+/* $Id: ncache.c,v 1.36.18.5 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -478,6 +478,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index bd168080e76d..fb561db3cf9d 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb.c,v 1.196.18.59 2009/11/26 23:46:11 tbox Exp $ */
+/* $Id: rbtdb.c,v 1.196.18.61 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -414,6 +414,8 @@ static isc_result_t rdataset_putadditional(dns_acache_t *acache,
 					   dns_rdataset_t *rdataset,
 					   dns_rdatasetadditional_t type,
 					   dns_rdatatype_t qtype);
+static void rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust);
+static void rdataset_expire(dns_rdataset_t *rdataset);
 
 static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_disassociate,
@@ -426,7 +428,9 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_getnoqname,
 	rdataset_getadditional,
 	rdataset_setadditional,
-	rdataset_putadditional
+	rdataset_putadditional,
+	rdataset_settrust,
+	rdataset_expire
 };
 
 static void rdatasetiter_destroy(dns_rdatasetiter_t **iteratorp);
@@ -5823,6 +5827,36 @@ rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
 	return (ISC_R_SUCCESS);
 }
 
+static void
+rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+	dns_rbtdb_t *rbtdb = rdataset->private1;
+	dns_rbtnode_t *rbtnode = rdataset->private2;
+	rdatasetheader_t *header = rdataset->private3;
+
+	header--;
+	NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+	header->trust = rdataset->trust = trust;
+	NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+}
+
+static void
+rdataset_expire(dns_rdataset_t *rdataset) {
+	dns_rbtdb_t *rbtdb = rdataset->private1;
+	dns_rbtnode_t *rbtnode = rdataset->private2;
+	rdatasetheader_t *header = rdataset->private3;
+
+	header--;
+	NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+	header->ttl = 0;
+	header->attributes |= RDATASET_ATTR_STALE;
+	rbtnode->dirty = 1;
+	NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
+		  isc_rwlocktype_write);
+}
+
 /*
  * Rdataset Iterator Methods
  */
diff --git a/lib/dns/rdatalist.c b/lib/dns/rdatalist.c
index 7229fa3e4511..b2c08123e31e 100644
--- a/lib/dns/rdatalist.c
+++ b/lib/dns/rdatalist.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatalist.c,v 1.28.18.3 2005/04/29 00:16:02 marka Exp $ */
+/* $Id: rdatalist.c,v 1.28.18.5 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -43,6 +43,8 @@ static dns_rdatasetmethods_t methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
diff --git a/lib/dns/rdataset.c b/lib/dns/rdataset.c
index f3c062da2f5c..56a386a9b51e 100644
--- a/lib/dns/rdataset.c
+++ b/lib/dns/rdataset.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.c,v 1.72.18.7 2009/01/19 23:46:15 tbox Exp $ */
+/* $Id: rdataset.c,v 1.72.18.9 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -179,6 +179,8 @@ static dns_rdatasetmethods_t question_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
@@ -707,3 +709,22 @@ dns_rdataset_putadditional(dns_acache_t *acache,
 	return (ISC_R_FAILURE);
 }
 
+void
+dns_rdataset_settrust(dns_rdataset_t *rdataset, dns_trust_t trust) {
+	REQUIRE(DNS_RDATASET_VALID(rdataset));
+	REQUIRE(rdataset->methods != NULL);
+
+	if (rdataset->methods->settrust != NULL)
+		(rdataset->methods->settrust)(rdataset, trust);
+	else
+		rdataset->trust = trust;
+}
+
+void
+dns_rdataset_expire(dns_rdataset_t *rdataset) {
+	REQUIRE(DNS_RDATASET_VALID(rdataset));
+	REQUIRE(rdataset->methods != NULL);
+
+	if (rdataset->methods->expire != NULL)
+		(rdataset->methods->expire)(rdataset);
+}
diff --git a/lib/dns/rdataslab.c b/lib/dns/rdataslab.c
index 4255b1d0002c..fb5a4b786d2e 100644
--- a/lib/dns/rdataslab.c
+++ b/lib/dns/rdataslab.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataslab.c,v 1.35.18.10 2009/01/19 23:46:15 tbox Exp $ */
+/* $Id: rdataslab.c,v 1.35.18.12 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -405,6 +405,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
index 7b41e72da729..95c7bd4a4f84 100644
--- a/lib/dns/resolver.c
+++ b/lib/dns/resolver.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.c,v 1.284.18.99 2010/01/07 23:46:07 tbox Exp $ */
+/* $Id: resolver.c,v 1.284.18.101 2010/02/26 23:46:36 tbox Exp $ */
 
 /*! \file */
 
@@ -318,6 +318,18 @@ typedef struct alternate {
 	ISC_LINK(struct alternate)	link;
 } alternate_t;
 
+typedef struct dns_badcache dns_badcache_t;
+struct dns_badcache {
+	dns_badcache_t *	next;
+	dns_rdatatype_t 	type;
+	isc_time_t		expire;
+	unsigned int		hashval;
+	dns_name_t		name;
+};
+#define DNS_BADCACHE_SIZE 1021
+#define DNS_BADCACHE_TTL(fctx) \
+	(((fctx)->res->lame_ttl > 30 ) ? (fctx)->res->lame_ttl : 30)
+
 struct dns_resolver {
 	/* Unlocked. */
 	unsigned int			magic;
@@ -361,6 +373,13 @@ struct dns_resolver {
 	unsigned int			activebuckets;
 	isc_boolean_t			priming;
 	unsigned int			spillat;	/* clients-per-query */
+
+	/* Bad cache. */
+	dns_badcache_t	**		badcache;
+	unsigned int			badcount;
+	unsigned int			badhash;
+	unsigned int			badsweep;
+
 	/* Locked by primelock. */
 	dns_fetch_t *			primefetch;
 	/* Locked by nlock. */
@@ -390,7 +409,7 @@ static void empty_bucket(dns_resolver_t *res);
 static isc_result_t resquery_send(resquery_t *query);
 static void resquery_response(isc_task_t *task, isc_event_t *event);
 static void resquery_connected(isc_task_t *task, isc_event_t *event);
-static void fctx_try(fetchctx_t *fctx);
+static void fctx_try(fetchctx_t *fctx, isc_boolean_t badcache);
 static isc_boolean_t fctx_destroy(fetchctx_t *fctx);
 static isc_result_t ncache_adderesult(dns_message_t *message,
 				      dns_db_t *cache, dns_dbnode_t *node,
@@ -1088,7 +1107,7 @@ process_sendevent(resquery_t *query, isc_event_t *event) {
 		if (result != ISC_R_SUCCESS)
 			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	}
 }
 
@@ -1946,7 +1965,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 		if (result != ISC_R_SUCCESS)
 			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	}
 }
 
@@ -2008,7 +2027,7 @@ fctx_finddone(isc_task_t *task, isc_event_t *event) {
 	dns_adb_destroyfind(&find);
 
 	if (want_try)
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_FALSE);
 	else if (want_done)
 		fctx_done(fctx, ISC_R_FAILURE, __LINE__);
 	else if (bucket_empty)
@@ -2371,7 +2390,7 @@ isstrictsubdomain(dns_name_t *name1, dns_name_t *name2) {
 }
 
 static isc_result_t
-fctx_getaddresses(fetchctx_t *fctx) {
+fctx_getaddresses(fetchctx_t *fctx, isc_boolean_t badcache) {
 	dns_rdata_t rdata = DNS_RDATA_INIT;
 	isc_result_t result;
 	dns_resolver_t *res;
@@ -2590,12 +2609,24 @@ fctx_getaddresses(fetchctx_t *fctx) {
 			 */
 			result = DNS_R_WAIT;
 		} else {
+			isc_time_t expire;
+			isc_interval_t i;
 			/*
 			 * We've lost completely.  We don't know any
 			 * addresses, and the ADB has told us it can't get
 			 * them.
 			 */
 			FCTXTRACE("no addresses");
+			isc_interval_set(&i, DNS_BADCACHE_TTL(fctx), 0);
+			result = isc_time_nowplusinterval(&expire, &i);
+			if (badcache &&
+			    (fctx->type == dns_rdatatype_dnskey ||
+			     fctx->type == dns_rdatatype_dlv ||
+			     fctx->type == dns_rdatatype_ds) &&
+			     result == ISC_R_SUCCESS)
+				dns_resolver_addbadcache(fctx->res,
+							 &fctx->name,
+							 fctx->type, &expire);
 			result = ISC_R_FAILURE;
 		}
 	} else {
@@ -2817,7 +2848,7 @@ fctx_nextaddress(fetchctx_t *fctx) {
 }
 
 static void
-fctx_try(fetchctx_t *fctx) {
+fctx_try(fetchctx_t *fctx, isc_boolean_t badcache) {
 	isc_result_t result;
 	dns_adbaddrinfo_t *addrinfo;
 
@@ -2835,7 +2866,7 @@ fctx_try(fetchctx_t *fctx) {
 		fctx_cleanupaltfinds(fctx);
 		fctx_cleanupforwaddrs(fctx);
 		fctx_cleanupaltaddrs(fctx);
-		result = fctx_getaddresses(fctx);
+		result = fctx_getaddresses(fctx, badcache);
 		if (result == DNS_R_WAIT) {
 			/*
 			 * Sleep waiting for addresses.
@@ -2995,7 +3026,7 @@ fctx_timeout(isc_task_t *task, isc_event_t *event) {
 			/*
 			 * Keep trying.
 			 */
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	}
 
 	isc_event_free(&event);
@@ -3165,7 +3196,7 @@ fctx_start(isc_task_t *task, isc_event_t *event) {
 		if (result != ISC_R_SUCCESS)
 			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	} else if (bucket_empty)
 		empty_bucket(res);
 }
@@ -3740,6 +3771,8 @@ validated(isc_task_t *task, isc_event_t *event) {
 
 	LOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 
+	isc_stdtime_get(&now);
+
 	/*
 	 * If chaining, we need to make sure that the right result code is
 	 * returned, and that the rdatasets are bound.
@@ -3785,36 +3818,80 @@ validated(isc_task_t *task, isc_event_t *event) {
 		FCTXTRACE("validation failed");
 		fctx->valfail++;
 		fctx->vresult = vevent->result;
-		result = ISC_R_NOTFOUND;
-		if (vevent->rdataset != NULL)
-			result = dns_db_findnode(fctx->cache, vevent->name,
-						 ISC_TRUE, &node);
-		if (result == ISC_R_SUCCESS)
-			(void)dns_db_deleterdataset(fctx->cache, node, NULL,
-						    vevent->type, 0);
-		if (result == ISC_R_SUCCESS && vevent->sigrdataset != NULL)
-			(void)dns_db_deleterdataset(fctx->cache, node, NULL,
-						    dns_rdatatype_rrsig,
-						    vevent->type);
-		if (result == ISC_R_SUCCESS)
-			dns_db_detachnode(fctx->cache, &node);
-		result = vevent->result;
+		if (fctx->vresult != DNS_R_BROKENCHAIN) {
+			result = ISC_R_NOTFOUND;
+			if (vevent->rdataset != NULL)
+				result = dns_db_findnode(fctx->cache,
+							 vevent->name,
+							 ISC_TRUE, &node);
+			if (result == ISC_R_SUCCESS)
+				(void)dns_db_deleterdataset(fctx->cache, node,
+							     NULL,
+							    vevent->type, 0);
+			if (result == ISC_R_SUCCESS &&
+			     vevent->sigrdataset != NULL)
+				(void)dns_db_deleterdataset(fctx->cache, node,
+							    NULL,
+							    dns_rdatatype_rrsig,
+							    vevent->type);
+			if (result == ISC_R_SUCCESS)
+				dns_db_detachnode(fctx->cache, &node);
+		}
+		if (fctx->vresult == DNS_R_BROKENCHAIN && !negative) {
+			/*
+			 * Cache the data as pending for later validation.
+			 */
+			result = ISC_R_NOTFOUND;
+			if (vevent->rdataset != NULL)
+				result = dns_db_findnode(fctx->cache,
+							 vevent->name,
+							 ISC_TRUE, &node);
+			if (result == ISC_R_SUCCESS) {
+				(void)dns_db_addrdataset(fctx->cache, node,
+							 NULL, now,
+							 vevent->rdataset, 0,
+							 NULL);
+			}
+			if (result == ISC_R_SUCCESS &&
+			    vevent->sigrdataset != NULL)
+				(void)dns_db_addrdataset(fctx->cache, node,
+							 NULL, now,
+							 vevent->sigrdataset,
+							 0, NULL);
+			if (result == ISC_R_SUCCESS)
+				dns_db_detachnode(fctx->cache, &node);
+		}
+		result = fctx->vresult;
 		add_bad(fctx, addrinfo, result, badns_validation);
 		isc_event_free(&event);
 		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		INSIST(fctx->validator == NULL);
 		fctx->validator = ISC_LIST_HEAD(fctx->validators);
-		if (fctx->validator != NULL) {
+		if (fctx->validator != NULL)
 			dns_validator_send(fctx->validator);
-		} else if (sentresponse)
+		else if (sentresponse)
 			fctx_done(fctx, result, __LINE__); /* Locks bucket. */
-		else
-			fctx_try(fctx);			/* Locks bucket. */
+		else if (result == DNS_R_BROKENCHAIN) {
+			isc_result_t tresult;
+			isc_time_t expire;
+			isc_interval_t i;
+
+			isc_interval_set(&i, DNS_BADCACHE_TTL(fctx), 0);
+			tresult = isc_time_nowplusinterval(&expire, &i);
+			if (negative &&
+			    (fctx->type == dns_rdatatype_dnskey ||
+			     fctx->type == dns_rdatatype_dlv ||
+			     fctx->type == dns_rdatatype_ds) &&
+			     tresult == ISC_R_SUCCESS)
+				dns_resolver_addbadcache(fctx->res,
+							 &fctx->name,
+							 fctx->type, &expire);
+			fctx_done(fctx, result, __LINE__); /* Locks bucket. */
+		} else
+			fctx_try(fctx, ISC_TRUE);	   /* Locks bucket. */
 		return;
 	}
 
-	isc_stdtime_get(&now);
-
 	if (negative) {
 		dns_rdatatype_t covers;
 		FCTXTRACE("nonexistence validation OK");
@@ -5589,7 +5666,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * Try again.
 		 */
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_FALSE);
 	} else {
 		unsigned int n;
 		dns_rdataset_t *nsrdataset = NULL;
@@ -6329,7 +6406,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * Try again.
 		 */
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_FALSE);
 	} else if (resend) {
 		/*
 		 * Resend (probably with changed options).
@@ -6390,6 +6467,27 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 /***
  *** Resolver Methods
  ***/
+static void
+destroy_badcache(dns_resolver_t *res) {
+	dns_badcache_t *bad, *next;
+	unsigned int i;
+
+	if (res->badcache != NULL) {
+		for (i = 0; i < res->badhash; i++)
+			for (bad = res->badcache[i]; bad != NULL;
+			     bad = next) {
+				next = bad->next;
+				isc_mem_put(res->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				res->badcount--;
+			}
+		isc_mem_put(res->mctx, res->badcache,
+			    sizeof(*res->badcache) * res->badhash);
+		res->badcache = NULL;
+		res->badhash = 0;
+		INSIST(res->badcount == 0);
+	}
+}
 
 static void
 destroy(dns_resolver_t *res) {
@@ -6427,6 +6525,7 @@ destroy(dns_resolver_t *res) {
 		isc_mem_put(res->mctx, a, sizeof(*a));
 	}
 	dns_resolver_reset_algorithms(res);
+	destroy_badcache(res);
 	dns_resolver_resetmustbesecure(res);
 #if USE_ALGLOCK
 	isc_rwlock_destroy(&res->alglock);
@@ -6550,6 +6649,10 @@ dns_resolver_create(dns_view_t *view,
 	ISC_LIST_INIT(res->alternates);
 	res->udpsize = RECV_BUFFER_SIZE;
 	res->algorithms = NULL;
+	res->badcache = NULL;
+	res->badcount = 0;
+	res->badhash = 0;
+	res->badsweep = 0;
 	res->mustbesecure = NULL;
 	res->spillatmin = res->spillat = 10;
 	res->spillatmax = 100;
@@ -7380,6 +7483,256 @@ dns_resolver_getudpsize(dns_resolver_t *resolver) {
 	return (resolver->udpsize);
 }
 
+void
+dns_resolver_flushbadcache(dns_resolver_t *resolver, dns_name_t *name) {
+	unsigned int i;
+	dns_badcache_t *bad, *prev, *next;
+
+	REQUIRE(VALID_RESOLVER(resolver));
+
+	LOCK(&resolver->lock);
+	if (resolver->badcache == NULL)
+		goto unlock;
+
+	if (name != NULL) {
+		isc_time_t now;
+		isc_result_t result;
+		result = isc_time_now(&now);
+		if (result != ISC_R_SUCCESS)
+			isc_time_settoepoch(&now);
+		i = dns_name_hash(name, ISC_FALSE) % resolver->badhash;
+		prev = NULL;
+		for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+			int n;
+			next = bad->next;
+			n = isc_time_compare(&bad->expire, &now);
+			if (n < 0 || dns_name_equal(name, &bad->name)) {
+				if (prev == NULL)
+					resolver->badcache[i] = bad->next;
+				else
+					prev->next = bad->next;
+				isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				resolver->badcount--;
+			} else
+				prev = bad;
+		}
+	} else
+		destroy_badcache(resolver);
+
+ unlock:
+	UNLOCK(&resolver->lock);
+
+}
+
+static void
+resizehash(dns_resolver_t *resolver, isc_time_t *now, isc_boolean_t grow) {
+	unsigned int newsize;
+	dns_badcache_t **new, *bad, *next;
+	unsigned int i;
+
+	if (grow)
+		newsize = resolver->badhash * 2 + 1;
+	else
+		newsize = (resolver->badhash - 1) / 2;
+
+	new = isc_mem_get(resolver->mctx,
+			  sizeof(*resolver->badcache) * newsize);
+	if (new == NULL)
+		return;
+	memset(new, 0, sizeof(*resolver->badcache) * newsize);
+	for (i = 0; i < resolver->badhash; i++) {
+		for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+			next = bad->next;
+			if (isc_time_compare(&bad->expire, now) < 0) {
+				isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				resolver->badcount--;
+			} else {
+				bad->next = new[bad->hashval % newsize];
+				new[bad->hashval % newsize] = bad;
+			}
+		}
+	}
+	isc_mem_put(resolver->mctx, resolver->badcache,
+		    sizeof(*resolver->badcache) * resolver->badhash);
+	resolver->badhash = newsize;
+	resolver->badcache = new;
+}
+
+void
+dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *expire)
+{
+	isc_time_t now;
+	isc_result_t result = ISC_R_SUCCESS;
+	unsigned int i, hashval;
+	dns_badcache_t *bad, *prev, *next;
+
+	REQUIRE(VALID_RESOLVER(resolver));
+
+	LOCK(&resolver->lock);
+	if (resolver->badcache == NULL) {
+		resolver->badcache = isc_mem_get(resolver->mctx,
+						 sizeof(*resolver->badcache) *
+						 DNS_BADCACHE_SIZE);
+		if (resolver->badcache == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto cleanup;
+		}
+		resolver->badhash = DNS_BADCACHE_SIZE;
+		memset(resolver->badcache, 0, sizeof(*resolver->badcache) *
+		       resolver->badhash);
+	}
+
+	result = isc_time_now(&now);
+	if (result != ISC_R_SUCCESS)
+		isc_time_settoepoch(&now);
+	hashval = dns_name_hash(name, ISC_FALSE);
+	i = hashval % resolver->badhash;
+	prev = NULL;
+	for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+		next = bad->next;
+		if (bad->type == type && dns_name_equal(name, &bad->name))
+			break;
+		if (isc_time_compare(&bad->expire, &now) < 0) {
+			if (prev == NULL)
+				resolver->badcache[i] = bad->next;
+			else
+				prev->next = bad->next;
+			isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+				    bad->name.length);
+			resolver->badcount--;
+		} else
+			prev = bad;
+	}
+	if (bad == NULL) {
+		isc_buffer_t buffer;
+		bad = isc_mem_get(resolver->mctx, sizeof(*bad) + name->length);
+		if (bad == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto cleanup;
+		}
+		bad->type = type;
+		bad->hashval = hashval;
+		isc_buffer_init(&buffer, bad + 1, name->length);
+		dns_name_init(&bad->name, NULL);
+		dns_name_copy(name, &bad->name, &buffer);
+		bad->next = resolver->badcache[i];
+		resolver->badcache[i] = bad;
+		resolver->badcount++;
+		if (resolver->badcount > resolver->badhash * 8)
+			resizehash(resolver, &now, ISC_TRUE);
+		if (resolver->badcount < resolver->badhash * 2 &&
+		    resolver->badhash > DNS_BADCACHE_SIZE)
+			resizehash(resolver, &now, ISC_FALSE);
+	}
+	bad->expire = *expire;
+ cleanup:
+	UNLOCK(&resolver->lock);
+}
+
+isc_boolean_t
+dns_resolver_getbadcache(dns_resolver_t *resolver, dns_name_t *name,
+			 dns_rdatatype_t type, isc_time_t *now)
+{
+	dns_badcache_t *bad, *prev, *next;
+	isc_boolean_t answer = ISC_FALSE;
+	unsigned int i;
+
+	REQUIRE(VALID_RESOLVER(resolver));
+
+	LOCK(&resolver->lock);
+	if (resolver->badcache == NULL)
+		goto unlock;
+
+	i = dns_name_hash(name, ISC_FALSE) % resolver->badhash;
+	prev = NULL;
+	for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+		next = bad->next;
+		/*
+		 * Search the hash list. Clean out expired records as we go.
+		 */
+		if (isc_time_compare(&bad->expire, now) < 0) {
+			if (prev != NULL)
+				prev->next = bad->next;
+			else
+				resolver->badcache[i] = bad->next;
+			isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+				    bad->name.length);
+			resolver->badcount--;
+			continue;
+		}
+		if (bad->type == type && dns_name_equal(name, &bad->name)) {
+			answer = ISC_TRUE;
+			break;
+		}
+		prev = bad;
+	}
+
+	/*
+	 * Slow sweep to clean out stale records.
+	 */
+	i = resolver->badsweep++ % resolver->badhash;
+	bad = resolver->badcache[i];
+	if (bad != NULL && isc_time_compare(&bad->expire, now) < 0) {
+		resolver->badcache[i] = bad->next;
+		isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+			    bad->name.length);
+		resolver->badcount--;
+	}
+
+ unlock:
+	UNLOCK(&resolver->lock);
+	return (answer);
+}
+
+void
+dns_resolver_printbadcache(dns_resolver_t *resolver, FILE *fp) {
+	char namebuf[DNS_NAME_FORMATSIZE];
+	char typebuf[DNS_RDATATYPE_FORMATSIZE];
+	dns_badcache_t *bad, *next, *prev;
+	isc_time_t now;
+	unsigned int i;
+	isc_uint64_t t;
+
+	LOCK(&resolver->lock);
+	fprintf(fp, ";\n; Bad cache\n;\n");
+
+	if (resolver->badcache == NULL)
+		goto unlock;
+
+	TIME_NOW(&now);
+	for (i = 0; i < resolver->badhash; i++) {
+		prev = NULL;
+		for (bad = resolver->badcache[i]; bad != NULL; bad = next) {
+			next = bad->next;
+			if (isc_time_compare(&bad->expire, &now) < 0) {
+				if (prev != NULL)
+					prev->next = bad->next;
+				else
+					resolver->badcache[i] = bad->next;
+				isc_mem_put(resolver->mctx, bad, sizeof(*bad) +
+					    bad->name.length);
+				resolver->badcount--;
+				continue;
+			}
+			prev = bad;
+			dns_name_format(&bad->name, namebuf, sizeof(namebuf));
+			dns_rdatatype_format(bad->type, typebuf,
+					     sizeof(typebuf));
+			t = isc_time_microdiff(&bad->expire, &now);
+			t /= 1000;
+			fprintf(fp, "; %s/%s [ttl "
+				"%" ISC_PLATFORM_QUADFORMAT "u]\n",
+				namebuf, typebuf, t);
+		}
+	}
+
+ unlock:
+	UNLOCK(&resolver->lock);
+}
+
 static void
 free_algorithm(void *node, void *arg) {
 	unsigned char *algorithms = node;
diff --git a/lib/dns/result.c b/lib/dns/result.c
index fdb58e0df7f4..504de7ebbf76 100644
--- a/lib/dns/result.c
+++ b/lib/dns/result.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.c,v 1.115.10.7 2005/06/17 02:04:31 marka Exp $ */
+/* $Id: result.c,v 1.115.10.9 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -155,7 +155,11 @@ static const char *text[DNS_R_NRESULTS] = {
 	"must-be-secure",		       /*%< 100 DNS_R_MUSTBESECURE */
 	"covering NSEC record returned",       /*%< 101 DNS_R_COVERINGNSEC */
 	"MX is an address",		       /*%< 102 DNS_R_MXISADDRESS */
-	"duplicate query"		       /*%< 103 DNS_R_DUPLICATE */
+	"duplicate query",		       /*%< 103 DNS_R_DUPLICATE */
+	"invalid NSEC3 owner name (wildcard)", /*%< 104 DNS_R_INVALIDNSEC3 */
+
+	"not master",			       /*%< 105 DNS_R_NOTMASTER */
+	"broken trust chain",		       /*%< 106 DNS_R_BROKENCHAIN */
 };
 
 static const char *rcode_text[DNS_R_NRCODERESULTS] = {
diff --git a/lib/dns/sdb.c b/lib/dns/sdb.c
index 972b72a985f8..42a1ce364096 100644
--- a/lib/dns/sdb.c
+++ b/lib/dns/sdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdb.c,v 1.45.18.19 2009/06/26 06:25:20 marka Exp $ */
+/* $Id: sdb.c,v 1.45.18.21 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -1374,6 +1374,8 @@ static dns_rdatasetmethods_t methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
diff --git a/lib/dns/sdlz.c b/lib/dns/sdlz.c
index 6c9a521b05f2..9dcaa57e3330 100644
--- a/lib/dns/sdlz.c
+++ b/lib/dns/sdlz.c
@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2005-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005-2007, 2009, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -50,7 +50,7 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdlz.c,v 1.2.2.14 2009/06/26 06:25:20 marka Exp $ */
+/* $Id: sdlz.c,v 1.2.2.16 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -1198,6 +1198,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
diff --git a/lib/dns/validator.c b/lib/dns/validator.c
index 387c433f5450..9642791ad1ac 100644
--- a/lib/dns/validator.c
+++ b/lib/dns/validator.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.c,v 1.119.18.51 2009/12/30 06:44:05 each Exp $ */
+/* $Id: validator.c,v 1.119.18.53 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -170,9 +170,16 @@ static inline void
 markanswer(dns_validator_t *val) {
 	validator_log(val, ISC_LOG_DEBUG(3), "marking as answer");
 	if (val->event->rdataset != NULL)
-		val->event->rdataset->trust = dns_trust_answer;
+		dns_rdataset_settrust(val->event->rdataset, dns_trust_answer);
 	if (val->event->sigrdataset != NULL)
-		val->event->sigrdataset->trust = dns_trust_answer;
+		dns_rdataset_settrust(val->event->sigrdataset,
+				      dns_trust_answer);
+}
+
+static inline void
+marksecure(dns_validatorevent_t *event) {
+	dns_rdataset_settrust(event->rdataset, dns_trust_secure);
+	dns_rdataset_settrust(event->sigrdataset, dns_trust_secure);
 }
 
 static void
@@ -337,7 +344,7 @@ fetch_callback_validator(isc_task_t *task, isc_event_t *event) {
 		if (eresult == ISC_R_CANCELED)
 			validator_done(val, eresult);
 		else
-			validator_done(val, DNS_R_NOVALIDKEY);
+			validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -407,7 +414,7 @@ dsfetched(isc_task_t *task, isc_event_t *event) {
 		if (eresult == ISC_R_CANCELED)
 			validator_done(val, eresult);
 		else
-			validator_done(val, DNS_R_NOVALIDDS);
+			validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -547,10 +554,16 @@ keyvalidated(isc_task_t *task, isc_event_t *event) {
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
 	} else {
+		if (eresult != DNS_R_BROKENCHAIN) {
+			if (dns_rdataset_isassociated(&val->frdataset))
+				dns_rdataset_expire(&val->frdataset);
+			if (dns_rdataset_isassociated(&val->fsigrdataset))
+				dns_rdataset_expire(&val->fsigrdataset);
+		}
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "keyvalidated: got %s",
 			      isc_result_totext(eresult));
-		validator_done(val, eresult);
+		validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -597,10 +610,16 @@ dsvalidated(isc_task_t *task, isc_event_t *event) {
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
 	} else {
+		if (eresult != DNS_R_BROKENCHAIN) {
+			if (dns_rdataset_isassociated(&val->frdataset))
+				dns_rdataset_expire(&val->frdataset);
+			if (dns_rdataset_isassociated(&val->fsigrdataset))
+				dns_rdataset_expire(&val->fsigrdataset);
+		}
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "dsvalidated: got %s",
 			      isc_result_totext(eresult));
-		validator_done(val, eresult);
+		validator_done(val, DNS_R_BROKENCHAIN);
 	}
 	want_destroy = exit_check(val);
 	UNLOCK(&val->lock);
@@ -802,6 +821,8 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "authvalidated: got %s",
 			      isc_result_totext(result));
+		if (result == DNS_R_BROKENCHAIN)
+			val->authfail++;
 		if (result == ISC_R_CANCELED)
 			validator_done(val, result);
 		else {
@@ -867,6 +888,7 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
  * \li	DNS_R_NCACHENXRRSET
  * \li	DNS_R_NXRRSET
  * \li	DNS_R_NXDOMAIN
+ * \li	DNS_R_BROKENCHAIN
  */
 static inline isc_result_t
 view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
@@ -876,9 +898,12 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
 	dns_rdata_t rdata = DNS_RDATA_INIT;
 	isc_result_t result;
 	unsigned int options;
+	isc_time_t now;
 	char buf1[DNS_NAME_FORMATSIZE];
 	char buf2[DNS_NAME_FORMATSIZE];
 	char buf3[DNS_NAME_FORMATSIZE];
+	char namebuf[DNS_NAME_FORMATSIZE];
+	char typebuf[DNS_RDATATYPE_FORMATSIZE];
 
 	if (dns_rdataset_isassociated(&val->frdataset))
 		dns_rdataset_disassociate(&val->frdataset);
@@ -888,6 +913,16 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
 	if (val->view->zonetable == NULL)
 		return (ISC_R_CANCELED);
 
+	if (isc_time_now(&now) == ISC_R_SUCCESS &&
+	    dns_resolver_getbadcache(val->view->resolver, name, type, &now)) {
+
+		dns_name_format(name, namebuf, sizeof(namebuf));
+		dns_rdatatype_format(type, typebuf, sizeof(typebuf));
+		validator_log(val, ISC_LOG_INFO, "bad cache hit (%s/%s)",
+			      namebuf, typebuf);
+		return (DNS_R_BROKENCHAIN);
+	}
+
 	options = DNS_DBFIND_PENDINGOK;
 	if (type == dns_rdatatype_dlv)
 		options |= DNS_DBFIND_COVERINGNSEC;
@@ -896,6 +931,7 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
 	result = dns_view_find(val->view, name, type, 0, options,
 			       ISC_FALSE, NULL, NULL, foundname,
 			       &val->frdataset, &val->fsigrdataset);
+
 	if (result == DNS_R_NXDOMAIN) {
 		if (dns_rdataset_isassociated(&val->frdataset))
 			dns_rdataset_disassociate(&val->frdataset);
@@ -1240,7 +1276,8 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 		/*
 		 * We don't know anything about this key.
 		 */
-		result = create_fetch(val, &siginfo->signer, dns_rdatatype_dnskey,
+		result = create_fetch(val, &siginfo->signer,
+				      dns_rdatatype_dnskey,
 				      fetch_callback_validator, "get_key");
 		if (result != ISC_R_SUCCESS)
 			return (result);
@@ -1255,7 +1292,8 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 		 * This key doesn't exist.
 		 */
 		result = DNS_R_CONTINUE;
-	}
+	} else if (result == DNS_R_BROKENCHAIN)
+		return (result);
 
 	if (dns_rdataset_isassociated(&val->frdataset) &&
 	    val->keyset != &val->frdataset)
@@ -1503,8 +1541,7 @@ validate(dns_validator_t *val, isc_boolean_t resume) {
 				      "looking for noqname proof");
 			return (nsecvalidate(val, ISC_FALSE));
 		} else if (result == ISC_R_SUCCESS) {
-			event->rdataset->trust = dns_trust_secure;
-			event->sigrdataset->trust = dns_trust_secure;
+			marksecure(event);
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "marking as secure");
 			return (result);
@@ -1680,8 +1717,7 @@ dlv_validatezonekey(dns_validator_t *val) {
 			      "no RRSIG matching DLV key");
 	}
 	if (result == ISC_R_SUCCESS) {
-		val->event->rdataset->trust = dns_trust_secure;
-		val->event->sigrdataset->trust = dns_trust_secure;
+		marksecure(val->event);
 		validator_log(val, ISC_LOG_DEBUG(3), "marking as secure");
 		return (result);
 	} else if (result == ISC_R_NOMORE && !supported_algorithm) {
@@ -1782,8 +1818,7 @@ validatezonekey(dns_validator_t *val) {
 				keynode = nextnode;
 			}
 			if (result == ISC_R_SUCCESS) {
-				event->rdataset->trust = dns_trust_secure;
-				event->sigrdataset->trust = dns_trust_secure;
+				marksecure(event);
 				validator_log(val, ISC_LOG_DEBUG(3),
 					      "signed by trusted key; "
 					      "marking as secure");
@@ -1810,11 +1845,14 @@ validatezonekey(dns_validator_t *val) {
 			 */
 			dns_name_format(val->event->name, namebuf,
 					sizeof(namebuf));
-			validator_log(val, ISC_LOG_DEBUG(2),
+			validator_log(val, ISC_LOG_NOTICE,
 				      "unable to find a DNSKEY which verifies "
 				      "the DNSKEY RRset and also matches one "
 				      "of specified trusted-keys for '%s'",
 				      namebuf);
+			validator_log(val, ISC_LOG_NOTICE,
+				      "please check the 'trusted-keys' for "
+				      "'%s' in named.conf.", namebuf);
 			return (DNS_R_NOVALIDKEY);
 		}
 
@@ -1875,7 +1913,8 @@ validatezonekey(dns_validator_t *val) {
 				dns_rdataset_disassociate(&val->fsigrdataset);
 			validator_log(val, ISC_LOG_DEBUG(2), "no DS record");
 			return (DNS_R_NOVALIDSIG);
-		}
+		} else if (result == DNS_R_BROKENCHAIN)
+			return (result);
 	}
 
 	/*
@@ -2024,8 +2063,7 @@ validatezonekey(dns_validator_t *val) {
 			      "no RRSIG matching DS key");
 	}
 	if (result == ISC_R_SUCCESS) {
-		event->rdataset->trust = dns_trust_secure;
-		event->sigrdataset->trust = dns_trust_secure;
+		marksecure(event);
 		validator_log(val, ISC_LOG_DEBUG(3), "marking as secure");
 		return (result);
 	} else if (result == ISC_R_NOMORE && !supported_algorithm) {
@@ -2231,6 +2269,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 						  "nsecvalidate");
 			if (result != ISC_R_SUCCESS)
 				return (result);
+			val->authcount++;
 			return (DNS_R_WAIT);
 
 		}
@@ -2252,8 +2291,7 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 				      "noqname proof found");
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "marking as secure");
-			val->event->rdataset->trust = dns_trust_secure;
-			val->event->sigrdataset->trust = dns_trust_secure;
+			marksecure(val->event);
 			return (ISC_R_SUCCESS);
 		}
 		validator_log(val, ISC_LOG_DEBUG(3),
@@ -2284,6 +2322,8 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 		return (ISC_R_SUCCESS);
 	}
 
+	if (val->authcount == val->authfail)
+		return (DNS_R_BROKENCHAIN);
 	validator_log(val, ISC_LOG_DEBUG(3),
 		      "nonexistence proof(s) not found");
 	val->attributes |= VALATTR_INSECURITY;
@@ -2315,6 +2355,58 @@ check_ds(dns_validator_t *val, dns_name_t *name, dns_rdataset_t *rdataset) {
 	return (ISC_FALSE);
 }
 
+static void
+dlvvalidated(isc_task_t *task, isc_event_t *event) {
+	dns_validatorevent_t *devent;
+	dns_validator_t *val;
+	isc_result_t eresult;
+	isc_boolean_t want_destroy;
+
+	UNUSED(task);
+	INSIST(event->ev_type == DNS_EVENT_VALIDATORDONE);
+
+	devent = (dns_validatorevent_t *)event;
+	val = devent->ev_arg;
+	eresult = devent->result;
+
+	isc_event_free(&event);
+	dns_validator_destroy(&val->subvalidator);
+
+	INSIST(val->event != NULL);
+
+	validator_log(val, ISC_LOG_DEBUG(3), "in dlvvalidated");
+	LOCK(&val->lock);
+	if (CANCELED(val)) {
+		validator_done(val, ISC_R_CANCELED);
+	} else if (eresult == ISC_R_SUCCESS) {
+		validator_log(val, ISC_LOG_DEBUG(3),
+			      "dlvset with trust %d", val->frdataset.trust);
+		dns_rdataset_clone(&val->frdataset, &val->dlv);
+		val->havedlvsep = ISC_TRUE;
+		if (dlv_algorithm_supported(val))
+			dlv_validator_start(val);
+		else {
+			markanswer(val);
+			validator_done(val, ISC_R_SUCCESS);
+		}
+	} else {
+		if (eresult != DNS_R_BROKENCHAIN) {
+			if (dns_rdataset_isassociated(&val->frdataset))
+				dns_rdataset_expire(&val->frdataset);
+			if (dns_rdataset_isassociated(&val->fsigrdataset))
+				dns_rdataset_expire(&val->fsigrdataset);
+		}
+		validator_log(val, ISC_LOG_DEBUG(3),
+			      "dlvvalidated: got %s",
+			      isc_result_totext(eresult));
+		validator_done(val, DNS_R_BROKENCHAIN);
+	}
+	want_destroy = exit_check(val);
+	UNLOCK(&val->lock);
+	if (want_destroy)
+		destroy(val);
+}
+
 /*%
  * Callback from fetching a DLV record.
  *
@@ -2534,6 +2626,24 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
 			      namebuf);
 		result = view_find(val, dlvname, dns_rdatatype_dlv);
 		if (result == ISC_R_SUCCESS) {
+			if (DNS_TRUST_PENDING(val->frdataset.trust) &&
+			    dns_rdataset_isassociated(&val->fsigrdataset))
+			{
+				dns_fixedname_init(&val->fname);
+				dns_name_copy(dlvname,
+					      dns_fixedname_name(&val->fname),
+					      NULL);
+				result = create_validator(val,
+						dns_fixedname_name(&val->fname),
+							  dns_rdatatype_dlv,
+							  &val->frdataset,
+							  &val->fsigrdataset,
+							  dlvvalidated,
+							  "finddlvsep");
+				if (result != ISC_R_SUCCESS)
+					return (result);
+				return (DNS_R_WAIT);
+			}
 			if (val->frdataset.trust < dns_trust_secure)
 				return (DNS_R_NOVALIDSIG);
 			val->havedlvsep = ISC_TRUE;
@@ -2584,6 +2694,7 @@ finddlvsep(dns_validator_t *val, isc_boolean_t resume) {
  * \li	DNS_R_NOVALIDSIG
  * \li	DNS_R_NOVALIDNSEC
  * \li	DNS_R_NOTINSECURE
+ * \li	DNS_R_BROKENCHAIN
  */
 static isc_result_t
 proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
@@ -2800,7 +2911,8 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 			if (result != ISC_R_SUCCESS)
 				goto out;
 			return (DNS_R_WAIT);
-		}
+		} else if (result == DNS_R_BROKENCHAIN)
+			return (result);
 	}
 	validator_log(val, ISC_LOG_DEBUG(3), "insecurity proof failed");
 	return (DNS_R_NOTINSECURE); /* Couldn't complete insecurity proof */
@@ -3007,6 +3119,8 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	val->seensig = ISC_FALSE;
 	val->havedlvsep = ISC_FALSE;
 	val->depth = 0;
+	val->authcount = 0;
+	val->authfail = 0;
 	val->mustbesecure = dns_resolver_getmustbesecure(view->resolver, name);
 	dns_rdataset_init(&val->frdataset);
 	dns_rdataset_init(&val->fsigrdataset);
diff --git a/lib/dns/view.c b/lib/dns/view.c
index 4851cf008455..801654be365d 100644
--- a/lib/dns/view.c
+++ b/lib/dns/view.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008, 2010  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: view.c,v 1.126.18.16 2008/06/17 23:46:03 tbox Exp $ */
+/* $Id: view.c,v 1.126.18.18 2010/02/26 23:46:37 tbox Exp $ */
 
 /*! \file */
 
@@ -1194,10 +1194,11 @@ dns_view_dumpdbtostream(dns_view_t *view, FILE *fp) {
 
 	(void)fprintf(fp, ";\n; Cache dump of view '%s'\n;\n", view->name);
 	result = dns_master_dumptostream(view->mctx, view->cachedb, NULL,
-					  &dns_master_style_cache, fp);
+					 &dns_master_style_cache, fp);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	dns_adb_dump(view->adb, fp);
+	dns_resolver_printbadcache(view->resolver, fp);
 	return (ISC_R_SUCCESS);
 }
 
@@ -1218,6 +1219,8 @@ dns_view_flushcache(dns_view_t *view) {
 	dns_cache_attachdb(view->cache, &view->cachedb);
 	if (view->acache != NULL)
 		dns_acache_setdb(view->acache, view->cachedb);
+	if (view->resolver != NULL)
+		dns_resolver_flushbadcache(view->resolver, NULL);
 
 	dns_adb_flush(view->adb);
 	return (ISC_R_SUCCESS);
@@ -1232,6 +1235,8 @@ dns_view_flushname(dns_view_t *view, dns_name_t *name) {
 		dns_adb_flushname(view->adb, name);
 	if (view->cache == NULL)
 		return (ISC_R_SUCCESS);
+	if (view->resolver != NULL)
+		dns_resolver_flushbadcache(view->resolver, name);
 	return (dns_cache_flushname(view->cache, name));
 }
 
diff --git a/version b/version
index 7d97c13f850f..61b21455d9b1 100644
--- a/version
+++ b/version
@@ -1,4 +1,4 @@
-# $Id: version,v 1.29.134.28 2010/01/21 01:10:54 marka Exp $
+# $Id: version,v 1.29.134.29 2010/03/04 00:25:25 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=4
 PATCHVER=
 RELEASETYPE=-ESV
-RELEASEVER=
+RELEASEVER=-R1
-- 
cgit v1.3