From owner-namedroppers@ops.ietf.org Fri Dec 1 01:32:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01358 for ; Fri, 1 Dec 2000 01:32:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141j63-000MY8-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 21:50:59 -0800 Received: from mg-206253200-76.ricochet.net ([206.253.200.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 141j5z-000MXX-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 21:50:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141dtf-00044H-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 16:17:51 -0800 Message-Id: <5.0.2.1.2.20001130110437.0343afd8@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 30 Nov 2000 11:33:21 -0800 To: Olafur Gudmundsson , Mark Kosters From: "David R. Conrad" Subject: Re: DNSEXT WG LAst Call: Dnssec OK bit. Cc: DNSEXT WG Mailing list In-Reply-To: <4.3.2.7.2.20001130120641.00d11c90@localhost> References: <20001130094127.C4428@slam.admin.cto.netsol.com> <4.3.2.7.2.20001129141118.00b65340@localhost> <4.3.2.7.2.20001129141118.00b65340@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark (and Olafur), At 12:12 PM 11/30/2000 -0500, Olafur Gudmundsson wrote: >>Why is an ANY query listed along with SIG, KEY, and NXT? SIG, KEY, and NXT >>have explicit security context whereas ANY does not. To me, an ANY query >>is ambiguious at best should have the OK bit set for a RFC2535 response. Somewhat unparseable sentence. However, making assumptions on what you meant, there are a couple of ways to view DO. One is that it differentiates between RFC 1035 and RFC 2535 processing. Another way to view the DO bit is as you have (I gather), namely when cleared, excise all DNSSEC related goop in a response. I took the first approach, and as a result an ANY query should return what is available, regardless of whether it is DNSSEC related or not. Rgds, -drc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 1 02:35:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15271 for ; Fri, 1 Dec 2000 02:35:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141kIb-000Nzi-00 for namedroppers-data@psg.com; Thu, 30 Nov 2000 23:08:01 -0800 Received: from roam.psg.com ([147.28.0.38]) by psg.com with esmtp (Exim 3.16 #1) id 141kIb-000Nzc-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 23:08:01 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 141ja9-00048Y-00 for namedroppers@ops.ietf.org; Thu, 30 Nov 2000 22:22:05 -0800 Message-ID: <3A26F5D7.29C55A7A@daimlerchrysler.com> Date: Thu, 30 Nov 2000 19:50:31 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: DNSEXT WG Mailing list Subject: Re: DNSEXT WG Last Call: EDNS0.5 References: <4.3.2.7.2.20001129113521.0338f460@localhost> <4.3.2.7.2.20001130152756.05e90b98@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Alvestrand wrote: > At 22:02 29/11/2000 -0500, Kevin Darcy wrote: > >I would prefer to see a more general mechanism in which both FEATURE codes and > >OPTION codes, for boolean OPTIONs, are included in the same sorted list: it > >seems a waste to have to specify such OPTIONs separately from FEATUREs when > >they are so similar in form and function. > > do we have examples of boolean OPTIONs? None that are drafted/RFC'ed, that I'm aware of. I have some ideas about a "don't send me extraneous RR's" option (as I brought up several months ago -- see "To Be Cached, ..."), but nothing concrete yet. It seems likely, though, that boolean OPTIONs will be proposed in the future. If the codes for OPTIONs and FEATUREs need to be co-ordinated, this is the time to do it. Otherwise, it may be difficult to retrofit once we have collisions all over the place. Note that sometimes there may be an affinity between a FEATURE and a boolean OPTION. The FEATURE may establish a default -- "do X" or "don't do X" -- and the corresponding boolean OPTION may establish a mutually-agreeable, per-transaction override of that default behavior -- "let's do X just this once" or "let's not do X right now". As FEATUREs get proposed, then, we may start to see boolean OPTIONs proposed in parallel. I'm not saying this is inevitable, only likely. > I would hesitate to jam them into the same mechanism if there is a chance > that we might want to turn them off/on per query - the FEATURE mechanism > was quite deliberately designed so that it was "relatively harmless" to > signal a FEATURE you did not have any use for. This is a requirement in > order to be able to subsume FEATURE lists into VERSIONs. I don't think mixing boolean OPTIONs with FEATUREs would get in the way of subsuming FEATURE lists into VERSIONs, especially if the OPTION codes and FEATURE codes are assigned from distinct numeric ranges. Since the list is sorted numerically, any reasonable algorithm can easily detect the demarcation between the two types of extension, i.e. can easily tell that it is done parsing FEATUREs or OPTIONs, depending on which direction it chooses to work through the list. The FEATURE processing is thus easily segregable from the boolean OPTION processing. The only thing it would hinder is if an implementation might want to do, say, a non-linear (e.g. log) search for a specific FEATURE in a large, unparsed list. How likely is that? My impression is that FEATURE lists would always be parsed into internal data structures which would be consulted for any FEATURE-specific decisions -- repeatedly searching the raw FEATURE list seems rather crude and inefficient. Admittedly, my suggestion ultimately only saves 4 bytes in the OPT RR (an alternative would be to spec a "boolean options list" composite OPTION which would exactly mirror EDNS0.5's FEATURE list, requiring an extra 2 bytes for the OPTION-CODE and another 2 bytes for the OPTION-LENGTH), and possibly some parsing resources, depending on implementation. In the grand scheme of things, 4 bytes is not a whole lot. But every little bit helps, and I'm not sure that there would be any significant downside (except of course the standards-process downsides of having to a) reword the draft, and, potentially, b) to deal with IANA on the issue of segmenting the range; I could perhaps assist with the rewording, but I'm unfamiliar with IANA processes and procedures). - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 1 11:36:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10611 for ; Fri, 1 Dec 2000 11:36:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141sTX-0004xI-00 for namedroppers-data@psg.com; Fri, 01 Dec 2000 07:51:51 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 141sTW-0004x8-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 07:51:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 141sTW-000I0p-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 07:51:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Fri, 01 Dec 2000 03:00:00 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 1 11:37:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11074 for ; Fri, 1 Dec 2000 11:37:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141sVY-000504-00 for namedroppers-data@psg.com; Fri, 01 Dec 2000 07:53:56 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 141sVY-0004zy-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 07:53:56 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 141sVY-000I2N-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 07:53:56 -0800 Message-Id: <200012011128.GAA23105@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-01.txt Date: Fri, 01 Dec 2000 06:28:54 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for encoding DHCP information Author(s) : A. Gustafsson, T. Lemon, M. Stapp Filename : draft-ietf-dnsext-dhcid-rr-01.txt Pages : 8 Date : 30-Nov-00 A situation can arise where multiple DHCP clients request the same DNS name from their (possibly distinct) DHCP servers. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients 'owning' them. This memo defines a distinct RR type for use by DHCP servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130114134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114134.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 1 12:36:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28000 for ; Fri, 1 Dec 2000 12:36:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141tnV-0007kw-00 for namedroppers-data@psg.com; Fri, 01 Dec 2000 09:16:33 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 141tnU-0007kq-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 09:16:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 141tnU-000Isf-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 09:16:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 1 Dec 2000 17:14:49 GMT From: ocl@salsa.gih.co.uk (Olivier MJ Crepin-Leblond) Message-Id: <200012011714.RAA30138@salsa.gih.co.uk> To: info-nets@rg.net Subject: Pointer to FAQ: International E-mail accessibility (2000.12.01) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Version date: 2000/12/01 The FAQ (Frequently Asked Questions) document "mail/country-codes" has been recently distributed around Usenet and is available in the Usenet newsgroup news.answers (and other newsgroups such as comp.mail.misc, comp.mail.uucp, news.newusers.questions, alt.internet.services, alt.internet.access.wanted, alt.answers and comp.answers). The document can also be downloaded in a number of different ways. Via the Web: http://www.nsrc.org/codes/country-codes.html (text mode) http://www.nsrc.org/codes/bymap/world.html (Worldwide maps) The whole collection of documents (monthly releases since 1992 !) is available on: http://www.nsrc.org/oclb Of particular interest are the pages on Internetology, with a snapshot of world connectivity maps every 6 months since 1993, on: http://www.nsrc.org/codes/bymap/ntlgy/ Here is a short extract of the latest version of the document: --- snip --- snip --- snip --- Archive-name: mail/country-codes Last-modified: 2000/12/01` Based on International Standard ISO 3166 Codes Compiled by Olivier M.J. Crepin-Leblond E-mail: Release: 2000.12.01 Release Notes: a. Somalia (SO) with Full Internet (FI) Eritrea (ER) with Full Internet (FI) b. ICANN announces new Top Level Domains c. Libya (LY) still in testing stage (PFI) d. No major new connectivity in 3 months e. Complete change of format: Country Code, Connectivity, Name of Country This document answers the question: "Has country X got E-mail or Internet access ?". The following table is a guide of country codes, showing the countries which have access to Internet or general E-mail services. The country codes have been derived from the International Organization for Standardization standard ISO 3166 found on: http://www.din.de/gremien/nas/nabd/iso3166ma/ A country code is taken as a top level domain once it is registered at the InterNIC, rs.internic.net so *not* all country codes listed are top level domains. At the bottom of the table, there is also a section of general top level domains, based on the information available at rs.internic.net. [...] IX. Archiving At each release, this document is archived in a number of archive sites around the world. Amongst them: ftp://rtfm.mit.edu:/pub/usenet/news.answers/mail/ #ftp://ftp.uu.net:/usenet/news.answers/mail/ ftp://src.doc.ic.ac.uk:/usenet/news.answers/news.newusers.questions/ (#) those may not be accessible via Bear access or direct PC access in some cases. The up-to-date, pre-release document is also available using a simple mail-server robot: Send E-mail to: with a subject: archive-server-request and the command: get mail/country-codes in the body of your message. The document is also distributed automatically once a month on a mailing list. To subscribe to that mailing list, send a message to: country-codes-request@nsrc.org with the command in the body of the message: subscribe The whole collection of documents (monthly releases since 1992 !) is available on: http://www.nsrc.org/oclb X. World-Wide-Web (WWW) documents A sister document is available on the World Wide Web. It is based on this FAQ, and has links to further information for each domain: http://www.nsrc.org/codes/country-codes.html A set of clickable international colour-coded maps is available at: http://www.nsrc.org/codes/bymap/world.html The pages are kindly hosted by the Network Startup Resource Center in the University of Oregon as a service to the Internet community. Web references for Top-Level information servers for a particular country should be sent to . Thanks to all who have helped ! XI. Internetology The Internet has exploded in size in the last few years. The present document has been edited monthly since 1993, and some Web pages have been put together to reflect on the continuing spread of Internet/E-mail in the world since that time. This section is called "Internetology". It provides a graphical history of the spread of the Net in developing countries, by taking snapshots of Internet connectivity every six months since November 1993. All of the maps tie-up with the information that is included with the FAQ on International E-mail accessibility. The reference for the Internetology pages is: http://www.nsrc.org/codes/bymap/ntlgy/ -- Olivier MJ Crepin-Leblond, Ph.D. |--> Global Information Highway Limited Phone: +44 (0)7956 84 1113 | http://www.gih.com/ | E-mail: Fax : +44 (0)20 7937 7666 | Always 60 seconds ahead of the past ! to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 1 19:06:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08220 for ; Fri, 1 Dec 2000 19:06:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141zkm-000Izi-00 for namedroppers-data@psg.com; Fri, 01 Dec 2000 15:38:08 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 141zkl-000Izb-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 15:38:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 141zkl-000MPI-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 15:38:07 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers X-Single_Recipient: yes Subject: test - ignore Message-Id: Date: Fri, 01 Dec 2000 15:38:07 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit sorry for this message. it is an attempt to flush out bad subs from behind the broken mail system at microsoft.com randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From randy@psg.com Fri Dec 1 19:26:50 2000 Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12969 for ; Fri, 1 Dec 2000 19:26:49 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1420Vr-000N7r-00 for dnsext-archive@lists.ietf.org; Fri, 01 Dec 2000 16:26:47 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: dnsext-archive@ietf.org Subject: test to dnsext-archive@lists.ietf.org Message-Id: Date: Fri, 01 Dec 2000 16:26:47 -0800 Content-Transfer-Encoding: 7bit if this message bounces, you will be unsubscribed from namedroppers. otherwise ignore it. apologies for the spam. randy From owner-namedroppers@ops.ietf.org Fri Dec 1 19:39:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08221 for ; Fri, 1 Dec 2000 19:06:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 141zcX-000Iog-00 for namedroppers-data@psg.com; Fri, 01 Dec 2000 15:29:37 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 141zcW-000Ioa-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 15:29:36 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 141zcW-000ML9-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 15:29:36 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers X-Single_Recipient: yes Subject: test - ignore Message-Id: Date: Fri, 01 Dec 2000 15:29:36 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit sorry for this message. it is an attempt to flush out bad subs from behind the broken mail system at microsoft.com randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 1 21:35:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08382 for ; Fri, 1 Dec 2000 21:35:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14223l-000LJ2-00 for namedroppers-data@psg.com; Fri, 01 Dec 2000 18:05:53 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14223k-000LIu-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 18:05:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14223k-000OI7-00 for namedroppers@ops.ietf.org; Fri, 01 Dec 2000 18:05:52 -0800 X-Single-Recipient: yes From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft-ietf-dnsext-apl-rr-01.txt Message-Id: Date: Fri, 01 Dec 2000 17:53:20 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit please remind me why we need to create yet another rr, in this case to store address assignment data in the dns. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 2 14:13:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26428 for ; Sat, 2 Dec 2000 14:13:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142Hbb-0008sT-00 for namedroppers-data@psg.com; Sat, 02 Dec 2000 10:41:51 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142Hbb-0008sN-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 10:41:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142Hbb-0006tW-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 10:41:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Paul A Vixie Cc: namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> Message-Id: Date: Sat, 02 Dec 2000 10:34:11 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit s/cidr blocks// but why do we care? cidr is a thing about rirs etc. which have other stores. is it is the dns's job to store the universe? randy > there's no existing rr that can handle cidr blocks > > > From: Randy Bush > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > To: namedroppers > > Subject: draft-ietf-dnsext-apl-rr-01.txt > > Message-Id: > > Date: Fri, 01 Dec 2000 17:53:20 -0800 > > Sender: owner-namedroppers@ops.ietf.org > > Precedence: bulk > > X-DCC-MAPS-Metrics: ib.rc.vix.com 666; IP=0/74 env_From=0/66 From=0/13 > > Subject=0/3 Message-ID=0/3 Received=0/3 Body=0/3 Fuz1=0/3 > > > > please remind me why we need to create yet another rr, in this case to store > > address assignment data in the dns. > > > > randy > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 2 15:32:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05090 for ; Sat, 2 Dec 2000 15:32:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142J89-000AEx-00 for namedroppers-data@psg.com; Sat, 02 Dec 2000 12:19:33 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142J89-000AEr-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 12:19:33 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142J89-0007k7-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 12:19:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: Paul A Vixie , namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> Message-Id: Date: Sat, 02 Dec 2000 12:19:04 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>is it is the dns's job to store the universe? >> s/cidr blocks// >> but why do we care? cidr is a thing about rirs etc. which have other >> stores. > No, but no other storage exists with global reach but DNS. actually, in this case, other global stores do exist, the rir routing databases, aka the irr. > Yes, this probably Apps Area should have solved long time ago is there even a coherent work item on this? a good wg name might be universalgarbagecan. :-)/2 randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 2 15:34:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05357 for ; Sat, 2 Dec 2000 15:34:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142J7w-000AEa-00 for namedroppers-data@psg.com; Sat, 02 Dec 2000 12:19:20 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142J7v-000AEU-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 12:19:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142J7v-0007js-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 12:19:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <200012021540.HAA97610@redpaul.mfnx.net> Date: Sat, 2 Dec 2000 14:13:36 -0600 To: Randy Bush , Paul A Vixie From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10.34 -0800 00-12-02, Randy Bush wrote: >s/cidr blocks// > >but why do we care? cidr is a thing about rirs etc. which have other >stores. > >is it is the dns's job to store the universe? No, but no other storage exists with global reach but DNS. If we had some other choice...well, then it would be easier to say no to the requests. Yes, this probably Apps Area should have solved long time ago, but this is a different story, and talking about it need a bar within close range. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 00:45:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11004 for ; Sun, 3 Dec 2000 00:45:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142RLt-000Ih4-00 for namedroppers-data@psg.com; Sat, 02 Dec 2000 21:06:17 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142RLt-000Igy-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 21:06:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142RLt-000CCQ-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 21:06:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <200012021540.HAA97610@redpaul.mfnx.net> Date: Sat, 2 Dec 2000 14:25:46 -0600 To: Randy Bush From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: Paul A Vixie , namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12.19 -0800 00-12-02, Randy Bush wrote: >> No, but no other storage exists with global reach but DNS. > > actually, in this case, other global stores do exist, the rir routing > databases, aka the irr. Ok, true in _this_ specific case, but not in the general case. > > Yes, this probably Apps Area should have solved long time ago > >is there even a coherent work item on this? a good wg name might be >universalgarbagecan. :-)/2 Nope, but the name is correct. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 00:45:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11043 for ; Sun, 3 Dec 2000 00:45:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142RV1-000Ire-00 for namedroppers-data@psg.com; Sat, 02 Dec 2000 21:15:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142RV1-000IrY-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 21:15:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142RV1-000CHv-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 21:15:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A29792C.4A0D1113@software-munitions.com> Date: Sat, 02 Dec 2000 14:35:24 -0800 From: Dennis Glatting To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Randy Bush , Paul A Vixie , namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Patrik F=E4ltstr=F6m wrote: > At 10.34 -0800 00-12-02, Randy Bush wrote: >> s/cidr blocks// >> >> but why do we care? cidr is a thing about rirs etc. which have other >> stores. >> >> is it is the dns's job to store the universe? > No, but no other storage exists with global reach but DNS. > If we had some other choice...well, then it would be easier to say no > to the requests. But there is, isn't there? LDAP, as in, for example, ldap.cisco.com. > Yes, this probably Apps Area should have solved long time ago, but > this is a different story, and talking about it need a bar within > close range. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 01:21:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19594 for ; Sun, 3 Dec 2000 01:21:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142RzR-000JYl-00 for namedroppers-data@psg.com; Sat, 02 Dec 2000 21:47:09 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142RzR-000JYc-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 21:47:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142RzR-000CZn-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 21:47:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <3A29792C.4A0D1113@software-munitions.com> References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> Date: Sat, 2 Dec 2000 21:08:28 -0800 To: Dennis Glatting From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: Randy Bush , Paul A Vixie , namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 14.35 -0800 00-12-02, Dennis Glatting wrote: >But there is, isn't there? LDAP, as in, for example, ldap.cisco.com. Ok, I have to take one step further down this slippery path: Question: You want to know the phone number of "Eva Fr=F6lich". What LDAP database do you search in? Even if you want to know more about "paf@cisco.com", what LDAP database do you go to, what query do you issue, and what schema do you use? What base DN is the record in? =46urther, even if you know "/C=3DSE/O=3DCisco/CN=3DPatrik Faltstrom", what LDAP server do you go to? Answer: LDAP doesn't work globally because of the lack of indexing (only strict hierarchies like DNS exists, and works) and noone have been able to create "the root" which should work as the root nameservers. If this root existed, you should still only be able to query for records if you knew the DN. Now, the DN is both the location and unique identity of a record which is what I call "overloading the DN with information". If a record moves from one server to another one, the DN changes. Because of this, I as a person can not have one DN for the rest of my life as a unique identifier for my record. So, as LDAP only handle the same kind of lookups as DNS (hierarichal when you happen to know the global unique identifier), is slower and doesn't have root servers in the world, people look instead at DNS as it works. But, as I said, this discussion need a bar. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 02:16:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19149 for ; Sun, 3 Dec 2000 02:16:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142SFG-000Jx9-00 for namedroppers-data@psg.com; Sat, 02 Dec 2000 22:03:30 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142SFF-000Jx3-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 22:03:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142SFF-000CjE-00 for namedroppers@ops.ietf.org; Sat, 02 Dec 2000 22:03:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A29E165.1BFB181F@software-munitions.com> Date: Sat, 02 Dec 2000 22:00:05 -0800 From: Dennis Glatting To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Randy Bush , Paul A Vixie , namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Patrik F=E4ltstr=F6m wrote: > At 14.35 -0800 00-12-02, Dennis Glatting wrote: >> But there is, isn't there? LDAP, as in, for example, ldap.cisco.com. > Ok, I have to take one step further down this slippery path: > Question: You want to know the phone number of "Eva Fr=F6lich". What > LDAP database do you search in? The same is true of DNS: which domain should you search? If you can't find something in DNS then how do you find it in LDAP, and visa versa? By pushing garbage from DNS to LDAP you at least have a hint of directory and database (the DAP part). DNS, it seems to me, is more of a locator service but people are trying to make it a database. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 12:42:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03376 for ; Sun, 3 Dec 2000 12:42:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142cml-0004Ck-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 09:18:47 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142cml-0004Ce-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:18:47 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142cml-000IXj-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:18:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Eric A. Hall" Cc: namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A2A7F0F.F52392CB@ehsco.com> Message-Id: Date: Sun, 03 Dec 2000 09:18:10 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > DNS is a crap directory. trains fly very poorly. but they're the only vehicle we have. so keep welding on them wings. :-) randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 12:42:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03429 for ; Sun, 3 Dec 2000 12:42:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142ciJ-00048n-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 09:14:11 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142ciJ-00048g-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:14:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142ciH-000IVD-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:14:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A2A7F0F.F52392CB@ehsco.com> Date: Sun, 03 Dec 2000 09:12:47 -0800 From: "Eric A. Hall" To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Dennis Glatting , Randy Bush , Paul A Vixie , namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Question: You want to know the phone number of "Eva Fr=F6lich". What > LDAP database do you search in? This is a problem for every federated namespace. BUT just because the problem is the same for all of them does not mean that you might as well use DNS. DNS has many other problems in addition to this one which make it even more unsuitable, not equally unsuitable. > So, as LDAP only handle the same kind of lookups as DNS (hierarichal > when you happen to know the global unique identifier), is slower and > doesn't have root servers in the world, people look instead at DNS as > it works. Tell me how you will index partial elements of a value in DNS? If I want to find all of the email addresses which contain "ehsco.com" how do I search for this? How do I setup the backend? This specific functionality is not defined nor is it even feasible with DNS. It is well suited to LDAP however. Second: how do you define per-RR ACLs in DNS? If I want to publish my work phone to all anonymous agents, my cell phone to fellow employees, and my home/emergency info to my family, how do I do this in DNS? Once again, the specs don't allow for it and no servers support it, and the protocol probably could not handle it without being morphed into an entirely new protocol. DNS is a crap directory. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 12:45:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04361 for ; Sun, 3 Dec 2000 12:45:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142cuT-0004L5-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 09:26:45 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142cuS-0004Kz-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:26:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142cuS-000Ibp-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:26:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <3A29E165.1BFB181F@software-munitions.com> References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> Date: Sun, 3 Dec 2000 09:02:32 -0800 To: Dennis Glatting From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: Randy Bush , Paul A Vixie , namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 22.00 -0800 00-12-02, Dennis Glatting wrote: >The same is true of DNS: which domain should you search? If you can't >find something in DNS then how do you find it in LDAP, and visa versa? >By pushing garbage from DNS to LDAP you at least have a hint of >directory and database (the DAP part). DNS, it seems to me, is more of >a locator service but people are trying to make it a database. Exactly, LDAP and DNS have the same "semantics", but with the big difference that LDAP doesn't have a root server. I.e. given that I know the DN (which is the owner in DNS) for a record in LDAP, there is no root server I can query to know what LDAP server to send the query to. Mapping from DN to domainname (which is needed) doesn't exist, given that you don't use the DC naming scheme that is, and people don't. And, you don't get _better_ service with LDAP as you only can lookup records given the DN. Global searches doesn't work, so you will never be able to find information about "Eva Fr=F6lich", just like you can not do indexed searches in DNS. So, I understand why people ask why one should use LDAP when it have worse performance than DNS. Maybe we should have a "GC" class (garbage can) for these things in DNS? paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 13:03:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09262 for ; Sun, 3 Dec 2000 13:03:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142d9f-0004bk-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 09:42:27 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142d9e-0004bd-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:42:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142d9e-000Ikf-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:42:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <3A2A7F0F.F52392CB@ehsco.com> References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A2A7F0F.F52392CB@ehsco.com> Date: Sun, 3 Dec 2000 09:36:33 -0800 To: "Eric A. Hall" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09.12 -0800 00-12-03, Eric A. Hall wrote: >This is a problem for every federated namespace. BUT just because the >problem is the same for all of them does not mean that you might as well >use DNS. DNS has many other problems in addition to this one which make it >even more unsuitable, not equally unsuitable. I agree completely. I am not arguing _for_ DNS. I just explain why people want to use it. >Tell me how you will index partial elements of a value in DNS? If I want >to find all of the email addresses which contain "ehsco.com" how do I >search for this? How do I setup the backend? This specific functionality >is not defined nor is it even feasible with DNS. It is well suited to LDAP >however. It is not well suited in LDAP either, as you might have referrals (like in DNS), but no server-server protocol which transfer the index which is needed. >Second: how do you define per-RR ACLs in DNS? If I want to publish my work >phone to all anonymous agents, my cell phone to fellow employees, and my >home/emergency info to my family, how do I do this in DNS? This exists in LDAP, given that the bind operations succeedes, and you agree with the server on what bind mechanisms you want to use. >DNS is a crap directory. I have not claimed that DNS makes searches possible. What I claim is that lookup (which you do in DNS) work crap in LDAP because of lack of root server, LDAP doesn't give searches etc etc. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 13:22:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14813 for ; Sun, 3 Dec 2000 13:22:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142dOx-0004vU-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 09:58:15 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142dOx-0004vO-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:58:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142dOx-000ItD-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 09:58:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A2A8970.FC3AD0EE@software-munitions.com> Date: Sun, 03 Dec 2000 09:57:04 -0800 From: Dennis Glatting To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Randy Bush , Paul A Vixie , namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I forgot to add one item to my comments. One problem I have with adding any new RR type to DNS is the core software (server and client), and across all vendors, must be modified to incorporate the new type whereas with LDAP you simply (YMMV) add a new schema and plug in data. In the case of DNS, you are introducing software complexity and error to a critical operating component of the Internet, worsened if you are relying on DNSsec. With LDAP, you are not. As you point out, the problem of finding a given piece of information whether you are using DNS or LDAP is pretty much the same. However, it is common practice to include a quasi-URL in a DN, such as ou=3Dwww.verisign.com/RPA often found in Verisign certificates (the "ou=3D" makes no sense to me). With this information one knows the DN, the server to talk to, and hopefully the question to ask. :) I am not saying such an approach is wonderful or even real-world, however it at least makes a plausible case to dump trash into LDAP rather than DNS. Is "Eva Fr=F6lich" a real person? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 14:03:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28294 for ; Sun, 3 Dec 2000 14:03:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142eAF-0005uY-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 10:47:07 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142eAF-0005uS-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 10:47:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142eAF-000JLw-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 10:47:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200012031843.NAA06331@ct.engin.umich.edu> To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= cc: Dennis Glatting , Randy Bush , Paul A Vixie , namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt In-reply-to: Your message of Sun, 03 Dec 2000 09:02:32 -0800 Date: Sun, 03 Dec 2000 13:43:38 -0500 From: Steve Mattson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Sun, 3 Dec 2000 09:02:32 -0800 To: Dennis Glatting cc: Randy Bush , Paul A Vixie , namedroppers From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Maybe we should have a "GC" class (garbage can) for these things in DNS? paf We do, it's called TXT. Steve to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 20:44:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27755 for ; Sun, 3 Dec 2000 20:44:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142k05-000DoY-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 17:01:01 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142k05-000DoS-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 17:01:01 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142k05-000MQz-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 17:01:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: Dennis Glatting Cc: namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> From: Simon Josefsson In-Reply-To: <3A29E165.1BFB181F@software-munitions.com> Date: 04 Dec 2000 01:55:51 +0100 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dennis Glatting writes: > Patrik Fältström wrote: > > At 14.35 -0800 00-12-02, Dennis Glatting wrote: > >> But there is, isn't there? LDAP, as in, for example, ldap.cisco.com. > > > Ok, I have to take one step further down this slippery path: > > Question: You want to know the phone number of "Eva Frölich". What > > LDAP database do you search in? > > The same is true of DNS: which domain should you search? If you can't > find something in DNS then how do you find it in LDAP, and visa versa? Now we're getting to the heart of the problem. It all depend on what you want to look up. If you want to search for personal names, DNS is not the right tool by any mean. In fact, no global directory would be the right tool, personal names are not unique enough to be useful as an address on a global scale. Department-wide, company-wide or perhaps country-wide LDAP directories is probably better suited. But if we consider things that got a natural hostname, such as servers, zones, ip addresses, email addresses, it's very appealing to use DNS to look up information attached to these addresses. This is because, DNS already support this infrastructure, and when it comes to servers (hostnames) DNS _is_ this infrastructure. My point is that some things are "natural" to store in the X.400 (L)DAP model, and other things are "natural" to store in the DNS model. Some things can be easily located in DNS and not in LDAP, and vice versa. > By pushing garbage from DNS to LDAP you at least have a hint of > directory and database (the DAP part). DNS, it seems to me, is more of > a locator service but people are trying to make it a database. I agree! But I still want to see garbage (like certificates) stored in DNS because they are vital when "locating" someone. In a secure world, knowing the address of someone isn't enough to contact someone. The certificate is similar to addresses, in that it's required to contact the remote entity. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 3 22:15:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19118 for ; Sun, 3 Dec 2000 22:15:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142lo1-000G09-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 18:56:41 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142lo1-000G03-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 18:56:41 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142lo1-000N6f-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 18:56:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Jesper G. Hoy" To: Subject: RE: draft-ietf-dnsext-apl-rr-01.txt Date: Sun, 3 Dec 2000 21:16:57 -0500 Message-ID: In-Reply-To: <200012031843.NAA06331@ct.engin.umich.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Maybe we should have a "GC" class (garbage can) for these things in >> DNS? > We do, it's called TXT. How about setting aside a range of record type IDs for "exotic" record types? The DNS message format allows for 65536 (2 byte identifier) different record types. What if we said that all record type IDs with high bit set are "exotic". In master files, they could be listed as "X1", "X2", etc. and RDATA could be hex format for all of them. This way implementers could treat all X... records the same, and thus no future changes to BIND etc. are necessary when someone wants to add another "exotic" record type. Comments please... Jesper to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 00:10:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04737 for ; Mon, 4 Dec 2000 00:10:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142nbL-000IEy-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 20:51:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142nbL-000IEr-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 20:51:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142nbL-000Nsp-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 20:51:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> Date: Sun, 3 Dec 2000 20:41:30 -0800 To: Simon Josefsson , Dennis Glatting From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01.55 +0100 00-12-04, Simon Josefsson wrote: >My point is that some things are "natural" to store in the X.400 >(L)DAP model, and other things are "natural" to store in the DNS >model. Some things can be easily located in DNS and not in LDAP, and >vice versa. But, as indexing doesn't work in LDAP globally, searching in LDAP (which you need for looking up names) doesn't work. This means that searching for information doesn't work regardless of whether you use LDAP or DNS. So I don't agree that some things that doesn't work in DNS work in LDAP. Some thing (like finding information given the name of a person) doesn't work in either of the protocols. That is my point. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 00:15:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05287 for ; Mon, 4 Dec 2000 00:15:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142naA-000IDV-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 20:50:30 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142na9-000IDP-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 20:50:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142na9-000Ns3-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 20:50:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <3A2A8970.FC3AD0EE@software-munitions.com> References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> <3A2A8970.FC3AD0EE@software-munitions.com> Date: Sun, 3 Dec 2000 20:24:36 -0800 To: Dennis Glatting From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09.57 -0800 00-12-03, Dennis Glatting wrote: >One problem I have with adding any new RR type to DNS is the core >software (server and client), and across all vendors, must be modified >to incorporate the new type whereas with LDAP you simply (YMMV) add a >new schema and plug in data. In the case of DNS, you are introducing >software complexity and error to a critical operating component of the >Internet, worsened if you are relying on DNSsec. With LDAP, you are >not. Well, basically I am of course agreeing with you and all others on this list. Yes, I am an apps person, but I have been working with DNS long enough (since 87 or so) that I use exactly the arguments you do. I just tried to in the beginning to this discussion explain why people which do _not_ understand how important stability of DNS is want to put more and more RR types into DNS. To continue that discussion, I basically don't understand why you have to add code to generic DNS software just because you add an RR. I.e. adding a new RR type and a new schema in LDAP is basically the same thing. res_send etc handle the records just fine, and only the software which really need the information in the RR have to be able to change it. Yes, of course you need to be able to enter the data in the primary DNS server, but that is something you have to do with LDAP and a new schema aswell. It's all length-prefixed blocks of bits. >However, it >is common practice to include a quasi-URL in a DN, such as >ou=3Dwww.verisign.com/RPA often found in Verisign certificates (the >"ou=3D" makes no sense to me). One should instead use the DC naming scheme (see RFC 2247). >I am not >saying such an approach is wonderful or even real-world, however it at >least makes a plausible case to dump trash into LDAP rather than DNS. Sure! >Is "Eva Fr=F6lich" a real person? I hope so. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 01:28:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21771 for ; Mon, 4 Dec 2000 01:28:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142ofc-000Jor-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 22:00:12 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142ofc-000Jok-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 22:00:12 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142ofb-000OPP-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 22:00:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001204065131.05202f08@127.0.0.1> Date: Mon, 04 Dec 2000 06:57:03 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Dennis Glatting From: Harald Alvestrand Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Cc: namedroppers In-Reply-To: References: <3A2A8970.FC3AD0EE@software-munitions.com> <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> <3A2A8970.FC3AD0EE@software-munitions.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 20:24 03/12/2000 -0800, Patrik F=E4ltstr=F6m wrote: > >Is "Eva Fr=3DF6lich" a real person? > >I hope so. while Eva Fr=3DF6lich is (AFAIK) an artifact of failed MIME decoding, Eva Fr=F6lich would probably have a much better retort to this comment :-) to put back some content: LDAP searches at the moment make the server-to-ask part of the search criteria, and one that is largely orthogonal to what you know about the info you seek. Added to the rest of LDAP's problems, the result is not good. DNS does not have search. I suggest we move the directory discussion to the directory@apps.ietf.org list. It's nice and quiet and not LDAP specific. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 01:53:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03148 for ; Mon, 4 Dec 2000 01:53:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142p6l-000KHv-00 for namedroppers-data@psg.com; Sun, 03 Dec 2000 22:28:15 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142p6l-000KHp-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 22:28:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142p6l-000Ocd-00 for namedroppers@ops.ietf.org; Sun, 03 Dec 2000 22:28:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <200012040624.WAA11028@gulag.araneus.fi> To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt In-Reply-To: References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> <3A2A8970.FC3AD0EE@software-munitions.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sun, 03 Dec 2000 22:28:15 -0800 Content-Transfer-Encoding: 8bit Patrik Fältström said: > To continue that discussion, I basically don't understand why you > have to add code to generic DNS software just because you add an RR. > ... > It's all length-prefixed blocks of bits. Because of domain name compression. An RR containing compressed names will be silently corrupted if it is transmitted as a mere block of bits. There is also a couple of other issues like the downcasing of embedded domain names currently required for DNSSEC canonicalization. draft-ietf-dnsext-unknown-rrs-00.txt is an attempt to address this. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 08:50:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22485 for ; Mon, 4 Dec 2000 08:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142vRV-0000GJ-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 05:14:05 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142vRU-0000GC-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 05:14:04 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142vRU-0001oi-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 05:14:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A2B46BA.BE7FECBF@software-munitions.com> Date: Sun, 03 Dec 2000 23:24:42 -0800 From: Dennis Glatting To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Randy Bush , Paul A Vixie , namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> <3A2A8970.FC3AD0EE@software-munitions.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Patrik F=E4ltstr=F6m wrote: > = > At 09.57 -0800 00-12-03, Dennis Glatting wrote: > >One problem I have with adding any new RR type to DNS is the core > >software (server and client), and across all vendors, must be modified= > >to incorporate the new type whereas with LDAP you simply (YMMV) add a > >new schema and plug in data. In the case of DNS, you are introducing > >software complexity and error to a critical operating component of the= > >Internet, worsened if you are relying on DNSsec. With LDAP, you are > >not. > = > Well, basically I am of course agreeing with you and all others on > this list. Yes, I am an apps person, but I have been working with DNS > long enough (since 87 or so) that I use exactly the arguments you do. > = > I just tried to in the beginning to this discussion explain why > people which do _not_ understand how important stability of DNS is > want to put more and more RR types into DNS. > = > To continue that discussion, I basically don't understand why you > have to add code to generic DNS software just because you add an RR. > I.e. adding a new RR type and a new schema in LDAP is basically the > same thing. res_send etc handle the records just fine, and only the > software which really need the information in the RR have to be able > to change it. > = Interesting point. I was thinking existing implementation. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 08:53:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23407 for ; Mon, 4 Dec 2000 08:53:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142vdt-0000Tx-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 05:26:53 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142vdt-0000Tm-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 05:26:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142vdt-0001w4-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 05:26:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3A2B535E.90898AE0@ehsco.com> Date: Mon, 04 Dec 2000 00:18:39 -0800 From: "Eric A. Hall" To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Patrik Fältström wrote: > But, as indexing doesn't work in LDAP globally, searching in LDAP > (which you need for looking up names) doesn't work. This means that > searching for information doesn't work regardless of whether you use > LDAP or DNS. It's not supposed to work. Federated namespaces are not easily searched. Instead, you localize a search to a specific realm and hope for the best from that. If you want global searching, write a catalog server to index all of the data and search that. There is room for an ldap equivalent of google, there are lots of first-run efforts out already (bigfoot, four11 and others were ldap searchable once). Somebody could do the same thing with DNS even, BUT the important distinction is that the DNS protocol doesn't provide for incomplete searches. The inverse query allows you to search by value and type, but it does not allow for incomplete value. Good luck finding a resolver which can wring out an iquery as well. From this perspective searching in DNS will not work using existing tools, while LDAP can be made to work. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 08:59:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24682 for ; Mon, 4 Dec 2000 08:59:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142vdR-0000TW-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 05:26:25 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142vdR-0000TQ-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 05:26:25 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142vdN-0001vl-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 05:26:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 4 Dec 2000 08:10:56 -0000 Message-ID: <20001204081056.2947.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> <3A2A8970.FC3AD0EE@software-munitions.com> <200012040624.WAA11028@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have a web page on this issue: http://cr.yp.to/djbdns/newtypes.html In short: There is no need for a protocol change. The standards already make perfectly clear that DNS caches (and AXFR secondaries) must handle unknown record types. The only problem is that one widespread DNS implementation is ignoring the standards. Andreas Gustafsson writes: > An RR containing compressed names will be silently corrupted if it is > transmitted as a mere block of bits. The protocol does not allow that situation to occur in the first place. Compression is forbidden in new record types. BIND used to screw this up too, but it hasn't had a problem since version 8.1.2, right? I strongly object to your draft-ietf-dnsext-unknown-rrs-00. We don't need more disasters like http://www.cert.org/advisories/CA-2000-20.html. Handling the compression allowed by the protocol---owner names, NS data, CNAME data, PTR data, MX data, and SOA data---already takes way too much code; adding more code to decompress bogus records is a really bad idea. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 10:08:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16656 for ; Mon, 4 Dec 2000 10:08:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142wrf-00021X-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 06:45:11 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142wrf-00021Q-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 06:45:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142wrf-0002gp-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 06:45:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200012041440.eB4EebE43837@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: draft-ietf-dnsext-apl-rr-01.txt In-reply-to: Your message of "04 Dec 2000 08:10:56 -0000." <20001204081056.2947.qmail@cr.yp.to> Date: Tue, 05 Dec 2000 01:40:37 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I have a web page on this issue: http://cr.yp.to/djbdns/newtypes.html > > In short: There is no need for a protocol change. The standards already > make perfectly clear that DNS caches (and AXFR secondaries) must handle > unknown record types. The only problem is that one widespread DNS > implementation is ignoring the standards. RFC 1034 and RFC 1035 are incomplete and badly worded w.r.t. treating new RR types as opaque data. Even after correcting the wording to say that new RR types should be treated as opaque data they are still incomplete. > > Andreas Gustafsson writes: > > An RR containing compressed names will be silently corrupted if it is > > transmitted as a mere block of bits. > > The protocol does not allow that situation to occur in the first place. > Compression is forbidden in new record types. Not according to RFC 1034 and RFC 1035. They actually allow compression in new types. Not that I agree that it should be allowed just that it was. > BIND used to screw this up > too, but it hasn't had a problem since version 8.1.2, right? > > I strongly object to your draft-ietf-dnsext-unknown-rrs-00. We don't > need more disasters like http://www.cert.org/advisories/CA-2000-20.html. > Handling the compression allowed by the protocol---owner names, NS data, > CNAME data, PTR data, MX data, and SOA data---already takes way too much > code; adding more code to decompress bogus records is a really bad idea. Actually the server was only doing *less* than what RFC 1034 and RFC 1035 allowed it to do. It was not compressing SRV rdata. If it was still compressing (as earlier versions did) the bug would not have been triggered. In fact it was treating the RDATA as opaque data, the only additional thing it did was to add the servers to the list of potential additional data to be added. draft-ietf-dnsext-unknown-rrs-00 doesn't want to add compression to new RRs. It also doesn't want the server to have to know where domain names are in rdata hence the changes to DNSSEC in there. > > ---Dan > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 11:16:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06011 for ; Mon, 4 Dec 2000 11:16:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142xhv-00033r-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 07:39:11 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142xhu-00033l-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 07:39:10 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142xhu-0003DF-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 07:39:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2BF3DC129E8DD4118B29005004CEFD7C370436@krumm.nxps.com> From: Mike Burns To: namedroppers Subject: RE: draft-ietf-dnsext-apl-rr-01.txt Date: Mon, 4 Dec 2000 10:13:56 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Dennis Glatting [mailto:dennis.glatting@software-munitions.com] > Sent: Sunday, December 03, 2000 1:00 AM > To: Patrik F=E4ltstr=F6m > Cc: Randy Bush; Paul A Vixie; namedroppers > Subject: Re: draft-ietf-dnsext-apl-rr-01.txt >=20 >=20 > Patrik F=3DE4ltstr=3DF6m wrote: > > At 14.35 -0800 00-12-02, Dennis Glatting wrote: > >> But there is, isn't there? LDAP, as in, for example,=20 > ldap.cisco.com. >=20 > > Ok, I have to take one step further down this slippery path: > > Question: You want to know the phone number of "Eva Fr=3DF6lich". = What > > LDAP database do you search in? >=20 > The same is true of DNS: which domain should you search? If you can't > find something in DNS then how do you find it in LDAP, and visa = versa? > By pushing garbage from DNS to LDAP you at least have a hint of > directory and database (the DAP part). DNS, it seems to me, is more = of > a locator service but people are trying to make it a database. >=20 >=20 There is already a service that is used for user information and it = does not require any knowledge of containers or server location. Finger is used = to retrieve user information based on email address. DNS is supposed to = be a small, lightweight, quick program. If we include a large amount of information in the data for DNS, the resulting searches will become = slower. ------------------------------------- Mike Burns net-linx Publishing Solutions - Ann Arbor Senior Systems Engineer/ Systems Engineering Manager ICQ#39636054 email: mike@nxps.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 12:13:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28364 for ; Mon, 4 Dec 2000 12:13:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 142yls-0003zx-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 08:47:20 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 142ylr-0003zq-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 08:47:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 142ylr-0003t6-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 08:47:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 4 Dec 2000 11:36:35 -0500 From: Michael Mealling To: Mike Burns Cc: namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt Message-ID: <20001204113635.I6081@bailey.dscga.com> References: <2BF3DC129E8DD4118B29005004CEFD7C370436@krumm.nxps.com> In-Reply-To: <2BF3DC129E8DD4118B29005004CEFD7C370436@krumm.nxps.com>; from mikeb@nxps.com on Mon, Dec 04, 2000 at 10:13:56AM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, Dec 04, 2000 at 10:13:56AM -0500, Mike Burns wrote: > There is already a service that is used for user information and it = > does not require any knowledge of containers or server location. > Finger is used to retrieve user information based on email address. > DNS is supposed to be a small, lightweight, quick program. If we include > a large amount of information in the data for DNS, the resulting searches > will become slower. While doing the NAPTR stuff I was walking this line very closely. My rule of thumb is that DNS should be used for pointing to services that actually contains the data your interested in but never should the actual data be in DNS.... For the LDAP folks, take a look at www.ldap.research.netsol.com for some ideas on how to get around the 'disconnected islands' aspect of LDAP. Its not a true LDAP directory becauses its insanely expensive to search the entire tree. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 14:10:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02226 for ; Mon, 4 Dec 2000 14:10:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1430UQ-0005VA-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 10:37:26 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1430UQ-0005V4-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 10:37:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1430UQ-00055T-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 10:37:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 4 Dec 2000 13:34:45 -0500 From: Olafur Gudmundsson Message-Id: <200012041834.NAA08222@hun.gw.tislabs.com> To: agenda@ietf.org, namedroppers@ops.ietf.org Subject: 49'th IETF DNSEXT agenda Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agenda (2000/12/13) (as of 2000/12/4) 49'th IETF DNSEXT WG meeting Wednsday December 13'th 2000. 9:00 -- 11:30 Chairs: Randy Bush, Verio Olafur Gudmundsson, NAI Working group items 03 min Agenda bashing Randy Bush 05 min WG status Olafur Gudmundsson 05 min Interop testing results Bill Manning 05 min Interop Status Olafur Gudmundsson Last call documents 02 min IXFRbis + RSA/SHA Olafur Gudmundsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-01.txt 05 min APL Olafur Gudmundsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-01.txt 05 min Message Size Olafur Gudmundsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt 05 min EDNS0.5 Harald Alvestrand http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt 05 min Zone Secure Edward Lewis http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-03.txt 05 min DNSSEC OK David Conrad http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt Other working group documents 05 min DNSSEC Roadmap Glen Rose http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-00.txt 05 min NO record Simon Josefsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr-01.txt 05 min AD is Secure Brian Wellington http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-00.txt 05 min AXFR Clarify Andreas Gustafsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt 05 min Unkown RR types Andreas Gustafsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-00.txt 05 min SRVbis Levon Esibov http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2782bis-00.txt 05 min GSSAPI-TSIG Levon Esibov http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-01.txt 05 min Local Multicast DNS Levon Esibov http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-00.txt 05 min Large site Multicast DNS Bill Manning/Bill Woodcock http://www.ietf.org/internet-drafts/draft-manning-dnsext-mdns-00.txt 05 min DHCID RR Mark Stapp http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-01.txt New items: DNS MIB's 05 min RFC161[12] retirement Rob Austein http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsmib-historical-00.txt 15 min The case for DNS MIB Richard Bar Hibbs New non WG documents 05 min DNSSEC opt IN Mark Kosters http://www.ietf.org/internet-drafts/draft-koosters-dnsext-dnssec-opt-in-00.txt 05 min ENDS handling unknown Michael Sawyer http://www.ietf.org/internet-drafts/draft-msawyer-dnsext-edns-attributes-00.tx 05 min ZONE and View options Michael Sawyer http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.tx WG future: 10 min New charter discussion Olafur Gudmundsson Non-document slots: 07 min Other items 03 min Summary to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 14:50:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12125 for ; Mon, 4 Dec 2000 14:50:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14317g-000667-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 11:18:00 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14317f-000661-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 11:17:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14317f-0005UC-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 11:17:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A2BE708.13FF14FF@ehsco.com> Date: Mon, 04 Dec 2000 10:48:41 -0800 From: "Eric A. Hall" To: Michael Mealling CC: namedroppers Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <2BF3DC129E8DD4118B29005004CEFD7C370436@krumm.nxps.com> <20001204113635.I6081@bailey.dscga.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > For the LDAP folks, take a look at www.ldap.research.netsol.com for > some ideas on how to get around the 'disconnected islands' aspect of > LDAP. Its not a true LDAP directory becauses its insanely expensive > to search the entire tree. Off-topic observation, their structure is malformed. For example, I have ntrg.com, ntrg.org and ntrg.net zones. Searching through their repository returns data that is practically unusable. You would think ntrg.com would be dc=ntrg,dc=com but instead they use dc=ntrg,c=us. c=us is an assumption, nor does dc=ntrg,c=us allow for multiple occurances of dc=ntrg. ntrg.org and ntrg.net are both stored as dc=ntrg (no secondary qual) resulting in zone collision in the referral database. This is a good idea as it provides a psuedo-root for LDAP, whereby any registered zone in the DNS root zone can have an LDAP link. But the implementation is really lacking. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 15:25:46 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21055 for ; Mon, 4 Dec 2000 15:25:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1431gk-0006i6-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 11:54:14 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1431gj-0006hz-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 11:54:13 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1431gj-0005oe-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 11:54:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200012041940.LAA14168@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: APL and other new RR's Date: Mon, 04 Dec 2000 11:40:27 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit DNSEXT and its predecessors seem to deal just fine with new RR's which have to do with the DNS itself (as in SIG, KEY, OPT, and TSIG come to mind here.) DNSEXT as an "oversight committee" for new RR types which originate elsewhere seems to work fine (NAPTR, SRV, LOC, NSAP, NSAP_PTR, are all examples) seems to work. All DNSEXT is being asked to do in those situations is ensure that the RDATA encoding and other DNS-relevant issues are right -- NOT determine whether the proposed RR is going to be useful or whether the design that it is part of is really the right way to build some Internet application. But trying to get something like APL "started" inside DNSEXT is not working, because the implicit question is "what has this got to do with the DNS?" and the implicit answer is "nothing." I have an application that needs distributed, reliable, coherent, autonomous access to a list of CIDR blocks. I would like to store these in the DNS since the DNS is already a distributed, reliable, coherent, autonomous "database." My application has nothing to do with the DNS protocol. DNS's existing types don't deal well with this. A RR's don't have a mask. I can't use subdomains like ._addr and ._mask because then a single RRset won't have the whole list (._addr and ._mask would be separate RRsets and are not order-dependable.) Apparently, from comments posted here in response to the APL RR draft, most of the DNSEXT WG does not understand why this is being discussed in DNSEXT at all since it has nothing to do with the DNS protocol, any more than NAPTR or NSAP does. Therefore I hope the author will withdraw the draft and reoffer it as an individual, non-WG product, on an "experimental" track, which is what worked when SRV ran afoul of this same lack of support. (I'm just sooooo sure that Microsoft worries about whether Win2000's SRV support is really "experimental".) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 15:25:48 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21071 for ; Mon, 4 Dec 2000 15:25:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1431Z3-0006aB-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 11:46:17 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1431Z2-0006a5-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 11:46:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1431Z2-0005jq-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 11:46:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 4 Dec 2000 11:15:09 -0800 (PST) Message-Id: <200012041915.LAA00396@gulag.araneus.fi> To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-apl-rr-01.txt In-Reply-To: <20001204081056.2947.qmail@cr.yp.to> References: <200012021540.HAA97610@redpaul.mfnx.net> <3A29792C.4A0D1113@software-munitions.com> <3A29E165.1BFB181F@software-munitions.com> <3A2A8970.FC3AD0EE@software-munitions.com> <200012040624.WAA11028@gulag.araneus.fi> <20001204081056.2947.qmail@cr.yp.to> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In short: There is no need for a protocol change. The standards already > make perfectly clear that DNS caches (and AXFR secondaries) must handle > unknown record types. I don't think the following text in RFC1035 is particularly clear: Pointers can only be used for occurances of a domain name where the format is not class specific. If this were not the case, a name server or resolver would be required to know the format of all RRs it handled. As yet, there are no such cases, but they may occur in future RDATA formats. To me this seems to imply that domain names in future non-class-specific types can safely compressed, which of course is incorrect. > I strongly object to your draft-ietf-dnsext-unknown-rrs-00. [...] > Handling the compression allowed by the protocol---owner names, NS data, > CNAME data, PTR data, MX data, and SOA data---already takes way too much > code; adding more code to decompress bogus records is a really bad idea. draft-ietf-dnsext-unknown-rrs-00 does not require you to decompress post-RFC1035 record types - it's a SHOULD, not a MUST. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 17:49:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04877 for ; Mon, 4 Dec 2000 17:49:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1433w0-0008z4-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 14:18:08 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1433w0-0008yy-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 14:18:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1433vz-00078Z-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 14:18:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 4 Dec 2000 21:24:35 -0000 Message-ID: <20001204212435.5458.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-apl-rr-01.txt References: <20001204081056.2947.qmail@cr.yp.to> <200012041440.eB4EebE43837@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@nominum.com writes: > Not according to RFC 1034 and RFC 1035. They actually allow > compression in new types. You're not looking at the complete protocol specification. RFC 1123, section 6.1.3.5, says ``compression must only be used for the contents of WELL-KNOWN, class-independent RRs.'' (Emphasis added.) The reason for such restrictions was already made clear in RFC 1035, section 4.1.4: ``Pointers can only be used for ... If this were not the case, a name server or [cache] would be required to know the format of all RRs it handled.'' I agree that the ``...'' isn't broad enough, but the rationale makes clear what to do. The fundamental point is that the protocol is extensible. RFC 1035 says that ``new data types ... should always be expected.'' RFC 1123 makes this even more clear: A name server may acquire, via zone transfer, RRs that the server doesn't know how to convert to printable format. A [cache] can receive similar information as the result of queries. For proper operation, this data must be preserved ... I realize that this isn't a capitalized MUST, but there's only one reasonable interpretation of the protocol. BIND's behavior of destroying unrecognized record types is not ``proper operation.'' BIND's behavior of compressing new types (now fixed, right?) is indirectly prohibited, because it doesn't interoperate with caches that do what RFC 1123 says. > Not that I agree that it should be allowed just that it was. No. The only compression allowed by the protocol is in owner names, NS data, CNAME data, PTR data, MX data, and SOA data. My cache and AXFR client do not decompress anything else. I object to your company's attempts to portray this as a bad thing. I'm not saying that decompression of other types should be prohibited by the protocol. It doesn't affect legitimate packets; I understand that it simplifies your code. But decompression of other types shouldn't be _encouraged_. There's no reason that my cache should know about RP packets and RT packets and AFSDB packets and so on. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 17:50:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05117 for ; Mon, 4 Dec 2000 17:50:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1433sO-0008vd-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 14:14:24 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1433sN-0008vW-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 14:14:23 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1433sN-00076C-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 14:14:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A2C11E0.4D0A523@daimlerchrysler.com> Date: Mon, 04 Dec 2000 16:51:28 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: APL and other new RR's References: <200012041940.LAA14168@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I realize it's a bit abusive, but why not use SRV records for this? The preference fields could be used as an index by which to associate the addresses with their masks. Heck, maybe the preference field could _be_ the prefix length, thus eliminating the need for separate address and mask subdomains. IMO, the root problem here is that DNS has no order-dependability, period. Perhaps DNSEXT could address this general problem, come up with a general solution, and this might obviate the need for all of these specialized solutions. - Kevin Paul A Vixie wrote: > DNSEXT and its predecessors seem to deal just fine with new RR's which have > to do with the DNS itself (as in SIG, KEY, OPT, and TSIG come to mind here.) > > DNSEXT as an "oversight committee" for new RR types which originate elsewhere > seems to work fine (NAPTR, SRV, LOC, NSAP, NSAP_PTR, are all examples) seems > to work. All DNSEXT is being asked to do in those situations is ensure that > the RDATA encoding and other DNS-relevant issues are right -- NOT determine > whether the proposed RR is going to be useful or whether the design that it is > part of is really the right way to build some Internet application. > > But trying to get something like APL "started" inside DNSEXT is not working, > because the implicit question is "what has this got to do with the DNS?" and > the implicit answer is "nothing." > > I have an application that needs distributed, reliable, coherent, autonomous > access to a list of CIDR blocks. I would like to store these in the DNS since > the DNS is already a distributed, reliable, coherent, autonomous "database." > My application has nothing to do with the DNS protocol. DNS's existing types > don't deal well with this. A RR's don't have a mask. I can't use subdomains > like ._addr and ._mask because then a single RRset won't have the whole list > (._addr and ._mask would be separate RRsets and are not order-dependable.) > > Apparently, from comments posted here in response to the APL RR draft, most of > the DNSEXT WG does not understand why this is being discussed in DNSEXT at all > since it has nothing to do with the DNS protocol, any more than NAPTR or NSAP > does. > > Therefore I hope the author will withdraw the draft and reoffer it as an > individual, non-WG product, on an "experimental" track, which is what worked > when SRV ran afoul of this same lack of support. (I'm just sooooo sure that > Microsoft worries about whether Win2000's SRV support is really > "experimental".) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 4 17:54:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06578 for ; Mon, 4 Dec 2000 17:54:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1433nk-0008rq-00 for namedroppers-data@psg.com; Mon, 04 Dec 2000 14:09:36 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1433nj-0008rk-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 14:09:35 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1433nj-00073W-00 for namedroppers@ops.ietf.org; Mon, 04 Dec 2000 14:09:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001204163201.05a22100@localhost> Date: Mon, 04 Dec 2000 16:33:58 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: 49'th IETF DNSEXT agenda Cc: agenda@ietf.org In-Reply-To: <200012041834.NAA08222@hun.gw.tislabs.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01:34 PM 12/4/00, Olafur Gudmundsson wrote: >05 min ENDS handling unknown Michael Sawyer > >http://www.ietf.org/internet-drafts/draft-msawyer-dnsext-edns-attributes-00.tx > >05 min ZONE and View options Michael Sawyer > >http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.tx Sorry these two URL's have error in them the correct ones are (missing last character both of them). http://www.ietf.org/internet-drafts/draft-msawyer-dnsext-edns-attributes-00.txt and http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.txt Sorry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Dec 5 11:14:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28037 for ; Tue, 5 Dec 2000 11:14:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 143K4B-000OIF-00 for namedroppers-data@psg.com; Tue, 05 Dec 2000 07:31:39 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 143K4B-000OI9-00 for namedroppers@ops.ietf.org; Tue, 05 Dec 2000 07:31:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 143K4B-000H9w-00 for namedroppers@ops.ietf.org; Tue, 05 Dec 2000 07:31:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001205130325.02b016f8@127.0.0.1> Date: Tue, 05 Dec 2000 13:10:54 +0100 To: Olafur Gudmundsson , namedroppers@ops.ietf.org From: Harald Alvestrand Subject: ZONE and VIEW options (Re: 49'th IETF DNSEXT agenda) Cc: agenda@ietf.org In-Reply-To: <4.3.2.7.2.20001204163201.05a22100@localhost> References: <200012041834.NAA08222@hun.gw.tislabs.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 16:33 04/12/2000 -0500, Olafur Gudmundsson wrote: >and > >http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.txt > > Sorry switching from agenda to content comments.... I am really confused by this draft. In particular, the ZONE option says that "If the ZONE option is allowed, it MUST return a normally formatted reply with a ZONE optional record, containing the same zone as the one queried. When replying to AXFR or IXFR queries with ZONE options, the entire zone, including out-of-zone glue, should be returned to the client." now, is the glue out-of-zone or in-zone? I know that it's common practice to include glue in the same file as the zone data - but is this an implementation requirement? perhaps the author is looking for a "configured" option, where the server replies only with data that are configured into it, no matter what its status, and never with data learned from other sources? That would at least make sense. The VIEW option "only" has the problem that there is no global namespace for views, no ways of finding out which views are supported by a server, and no specification of the naming scheme for views. Mumble. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Dec 5 13:14:10 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27543 for ; Tue, 5 Dec 2000 13:14:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 143Lyh-0000B5-00 for namedroppers-data@psg.com; Tue, 05 Dec 2000 09:34:07 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 143Lyh-0000Az-00 for namedroppers@ops.ietf.org; Tue, 05 Dec 2000 09:34:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 143Lyh-000IIf-00 for namedroppers@ops.ietf.org; Tue, 05 Dec 2000 09:34:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 5 Dec 2000 09:31:20 -0800 (PST) From: Michael Sawyer To: Harald Alvestrand Cc: namedroppers@ops.ietf.org Subject: Re: ZONE and VIEW options (Re: 49'th IETF DNSEXT agenda) In-Reply-To: <4.3.2.7.2.20001205130325.02b016f8@127.0.0.1> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Not sent to agenda@, since I think this is largely off topic there] > In particular, the ZONE option says that "If the ZONE option is allowed, it > MUST return a normally formatted reply with a ZONE optional record, > containing the same zone as the one queried. When replying to AXFR or IXFR > queries > with ZONE options, the entire zone, including out-of-zone glue, should be > returned to the client." I agree, on re-reading that is confusing. I think I can remove the "including out-of-zone glue" part and have it make more sense; I believe in hindsight that that clause is largely meaningless anyway. > The VIEW option "only" has the problem that there is no global namespace > for views, no ways of finding out which views are supported by a server, > and no specification of the naming scheme for views. Both of those "problems" were intentional. The primary goal of the VIEW option (which, in my opinion, is the more important of the two) is to provide two bits of functionality chich can't be done otherwise. Both of these are currently somewhat Bind9-specific, but I see no reason in the way VIEW is defined other people who code similar functionality couldn't use the option in the same way. Assume you have two views in the server (let's call them "internal" and "external"), where "internal" is the first one listed, and only members of your internal network are encompassed by the view. "External" is listed second, and encompasses the entire world. Your internal machines will match the "internal" view, thus will see the data served by that view. Problem one which VIEW was intended to address: You are the DNS administrator, and want to make queries to your server which match the "external" view to make sure it is serving the right data. Your option now is to log into a machine on the external wire and make the query from there. Personally, I consider this a Bad Thing, since either such machines are actually external to the company, such as the administrator's home machine, or are on both the internal and external wire, which should have fairly high security requirements, and using them to make test queries from isn's really a good idea. With VIEW, you just add that option to your query, and since you match the external view, just at a lower level, you get that reply. Problem two: You have two nameservers, say, for example, one on the west coast and one one on the east coast. These both serve internal and external views, with the west coast server being the master and the east coast being the slave, for zones in both views. You also have your own internal corporate, high-speed network between the two sites. The AXFR of zones from the west coast to the east coast is easy; it happens over the corporate network. However, transferring the external zone is harder. You either have to give the hosts addresses on the external wire (if you even have "external" IP space to assign) and allow the zone to be transferred over the public IP, assign external IP's as above and make special routing rules which force just those external addresses to route over the internal net, or try to setup the zone rules with enough keys that you can fine-tune which zone you get that way (which all of the authors agreed was more complex than we'd want to suggest to someone and filled with potential for error). With VIEW, you just have the server request the AXFR from a specified view (just as the query above), and it should just work. Regarding the lack of ability to get a list of views, that was intentional (as was the fact that it returns the same error code for view not found and you can't access that view). We considered it a security issue for an outsider to be able to get a list of views from a server, or even what view they are currently looking at. In our opinion, if you are using the VIEW option, for whatever reason, you should know what the views in the server are, a priori. The naming scheme was not specified, specifically as not to make it Bind9-specific. Bind9 basically names views as ASCII strings, but there is no reason some mythical server couldn't come along with views named as properly formatted DNS names, or numbers, or anything else. If there is a strong objection to not specifying this, I'm more than happy to add in a specification for the naming of views. I'm not quite sure what you mean by a global namespace of views. They are, by their nature, site-specific, and an administrator generally won't want to have someone outside the organization know what views they have configured. Views, at least as Bind9 understands them, aren't delegated in any way, and this will be the first time the name of the view makes it any further than the config and log files. Mike Sawyer Nominum, Inc. -- www.nominum.com On Tue, 5 Dec 2000, Harald Alvestrand wrote: > At 16:33 04/12/2000 -0500, Olafur Gudmundsson wrote: > > >and > > > >http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.txt > > > > Sorry > > switching from agenda to content comments.... > I am really confused by this draft. > > > now, is the glue out-of-zone or in-zone? > I know that it's common practice to include glue in the same file as the > zone data - but is this an implementation requirement? > > perhaps the author is looking for a "configured" option, where the server > replies only with data that are configured into it, no matter what its > status, and never with data learned from other sources? That would at least > make sense. > > > Mumble. > > > -- > Harald Tveit Alvestrand, alvestrand@cisco.com > +47 41 44 29 94 > Personal email: Harald@Alvestrand.no > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 6 09:14:27 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16536 for ; Wed, 6 Dec 2000 09:14:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 143ekw-0006sB-00 for namedroppers-data@psg.com; Wed, 06 Dec 2000 05:37:10 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 143eku-0006s5-00 for namedroppers@ops.ietf.org; Wed, 06 Dec 2000 05:37:09 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 143eky-000AFG-00 for namedroppers@ops.ietf.org; Wed, 06 Dec 2000 06:37:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001206081833.02451408@127.0.0.1> Date: Wed, 06 Dec 2000 08:29:06 +0100 To: Michael Sawyer From: Harald Alvestrand Subject: Re: ZONE and VIEW options (Re: 49'th IETF DNSEXT agenda) Cc: namedroppers@ops.ietf.org In-Reply-To: References: <4.3.2.7.2.20001205130325.02b016f8@127.0.0.1> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09:31 05/12/2000 -0800, Michael Sawyer wrote: >[Not sent to agenda@, since I think this is largely off topic there] oops....sorry. > > In particular, the ZONE option says that "If the ZONE option is > allowed, it > > MUST return a normally formatted reply with a ZONE optional record, > > containing the same zone as the one queried. When replying to AXFR or > IXFR > > queries > > with ZONE options, the entire zone, including out-of-zone glue, should be > > returned to the client." > >I agree, on re-reading that is confusing. I think I can remove the >"including out-of-zone glue" part and have it make more sense; I believe >in hindsight that that clause is largely meaningless anyway. dropping ZONE from the doc would make it stronger, IMNSHO. But I guess I still don't understand what it's good for - adding a more fleshed-out use case is probably good for DNS amateurs such as me. > > The VIEW option "only" has the problem that there is no global namespace > > for views, no ways of finding out which views are supported by a server, > > and no specification of the naming scheme for views. > >Both of those "problems" were intentional. The primary goal of the VIEW >option (which, in my opinion, is the more important of the two) is to >provide two bits of functionality chich can't be done otherwise. Both of >these are currently somewhat Bind9-specific, but I see no reason in the >way VIEW is defined other people who code similar functionality couldn't >use the option in the same way. three, not two..... global namespace was concerned with the situation where you have 3 nameservers and 2 views: Server A view INT primary for .company view EXT primary for .company Server B view INT primary for .firm view EXT primary for .firm Server C view EXT secondary for .company view EXT secondary for .firm view INT secondary for .club a client trying to check that the EXT view of .firm was consistent would have to configure himself with two different names for the same view. If views were globally named (say, with a domain name under the manager's DNS space), those names could not collide. But this may not be a problem worth solving. I'll accept your reasoning for the "no way to list views" - although it sticks in the craw from a management perspective, DNS isn't a management protocol. The third (naming scheme - wrote that one badly) is an issue that arose once where 2 implementations of a protocol interpreted a certain field - one could only enter ASCII, and the other was configured with a binary value as (unchangeable) default. (TSAPs in X.400, if anyone cares). This fun event left me with a permanent distaste for namespaces where the name is not specified to be either a specific charset or "pure binary". Saying that "the name consists of ASCII characters", "UTF-8 characters" or "binary octets" will all leave me happy. I understand and like the VIEW option, by now. Have fun! -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 6 16:17:10 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23538 for ; Wed, 6 Dec 2000 16:17:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 143kuq-000Gke-00 for namedroppers-data@psg.com; Wed, 06 Dec 2000 12:11:48 -0800 Received: from [208.47.134.198] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 143kup-000GkX-00 for namedroppers@ops.ietf.org; Wed, 06 Dec 2000 12:11:48 -0800 Received: from randy by 42:4c:57:42:31:30:33:35:31:32:0 with local (Exim 3.12 #1) id 143ktH-000ARw-00 for namedroppers@ops.ietf.org; Wed, 06 Dec 2000 13:10:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 6 Dec 2000 09:15:33 -0800 (PST) From: Michael Sawyer To: Harald Alvestrand Cc: namedroppers@ops.ietf.org Subject: Re: ZONE and VIEW options (Re: 49'th IETF DNSEXT agenda) In-Reply-To: <4.3.2.7.2.20001206081833.02451408@127.0.0.1> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 6 Dec 2000, Harald Alvestrand wrote: > dropping ZONE from the doc would make it stronger, IMNSHO. We have been discussing the possibility of doing just that. There's a good chance at the IETF, I'm just going to say, "even though the ZONE option is in there, it will be removed from the next revision." > Server A > view INT primary for .company > view EXT primary for .company > > Server B > view INT primary for .firm > view EXT primary for .firm > > Server C > view EXT secondary for .company > view EXT secondary for .firm > view INT secondary for .club > > a client trying to check that the EXT view of .firm was consistent would have > to configure himself with two different names for the same view. Actually, in that case, you wouldn't really need the VIEW option. Server C, being a third-party server would be outside the network, would get the EXT views by default. Now, let's say that server C was internal to one of the other networks. The way we plan to add the option into bind is that there will be an option in the zone along the lines of "remove-view EXT;" so that you'll not be required to have the views matching between servers. (Of course, under a single administrative domain, having them be different would be silly, but in the case you name, it make sense.) > The third (naming scheme - wrote that one badly) is an issue that arose > once where 2 implementations of a protocol interpreted a certain field - > one could only enter ASCII, and the other was configured with a binary > value as (unchangeable) default. (TSAPs in X.400, if anyone cares). In honesty, I largely agree with this argument. We're willing to change to either "any legal DNS label" or "any legal UTF-8 string" in a revision, probably leaning toward the first. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 7 10:53:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06568 for ; Thu, 7 Dec 2000 10:53:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1442eh-0009yy-00 for namedroppers-data@psg.com; Thu, 07 Dec 2000 07:08:19 -0800 Received: from [208.47.134.198] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1442eg-0009yr-00 for namedroppers@ops.ietf.org; Thu, 07 Dec 2000 07:08:18 -0800 Received: from randy by 42:4c:57:42:31:30:33:35:31:32:0 with local (Exim 3.12 #1) id 1442de-000Amb-00 for namedroppers@ops.ietf.org; Thu, 07 Dec 2000 08:07:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001207074748.02bbcab0@127.0.0.1> Date: Thu, 07 Dec 2000 07:58:23 +0100 To: Michael Sawyer From: Harald Alvestrand Subject: Re: ZONE and VIEW options (Re: 49'th IETF DNSEXT agenda) Cc: namedroppers@ops.ietf.org In-Reply-To: References: <4.3.2.7.2.20001206081833.02451408@127.0.0.1> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09:15 06/12/2000 -0800, Michael Sawyer wrote: > > Server A > > view INT primary for .company > > view EXT primary for .company > > > > Server B > > view INT primary for .firm > > view EXT primary for .firm > > > > Server C > > view EXT secondary for .company > > view EXT secondary for .firm > > view INT secondary for .club > > > > a client trying to check that the EXT view of .firm was consistent > would have > > to configure himself with two different names for the same view. > >Actually, in that case, you wouldn't really need the VIEW option. Server >C, being a third-party server would be outside the network, would get the >EXT views by default. let's consider view EXT the view belonging to an extranet, rather than "the public view"; that makes it more interesting. Apart from the name clash, the other interesting case is if the manager for B tries to look at his extranet's EXT view for .firm on C and gets returned the information for the EXT view for .company. This shouldn't be a problem unless they have conflicting definitions of something (the root zone, for instance), but could get confusing. Of course the paranoid among us see it as a security problem..... if you want to make a hard problem harder, drop the word "security" in - I think you need an option to specify that views are visible on specific interfaces only, in order to satisfy the paranoid among us. But you probably already have that, just not in this document. Sigh. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 11 11:22:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15668 for ; Mon, 11 Dec 2000 11:22:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 145V2P-000Nqn-00 for namedroppers-data@psg.com; Mon, 11 Dec 2000 07:38:49 -0800 Received: from [207.137.69.34] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 145V2O-000Nqh-00 for namedroppers@ops.ietf.org; Mon, 11 Dec 2000 07:38:48 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 145V2S-0000ph-00 for namedroppers@ops.ietf.org; Mon, 11 Dec 2000 07:38:52 -0800 Message-Id: <4.3.2.7.2.20001129132910.00ca6be0@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Dec 2000 19:48:51 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Re: WG Last Call: RFC2137 to Historic In-Reply-To: <4.3.2.7.2.20000803144629.00d147a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:59 PM 8/9/00, Olafur Gudmundsson wrote: The following last call has completed, the consensus is that this is not needed. Olafur >As we have a new specification that obsoletes RFC2137 (Secure Dynamic Update). > >This last call is to solicit opinion of the WG if RFC2137 status >should be changed from "Obsoleted by RFC2xxx" to "Historic". > >The reason for doing this is to make it real clear to anyone that RFC2137 >is NOT to be implemented. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 11 12:41:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07602 for ; Mon, 11 Dec 2000 12:41:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 145WSV-000P8u-00 for namedroppers-data@psg.com; Mon, 11 Dec 2000 09:09:51 -0800 Received: from [207.137.73.155] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 145WSU-000P8o-00 for namedroppers@ops.ietf.org; Mon, 11 Dec 2000 09:09:50 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 145WSS-00012K-00 for namedroppers@ops.ietf.org; Mon, 11 Dec 2000 09:09:48 -0800 Received: from [207.137.73.155] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 145WRc-000P7d-00 for namedroppers@ops.ietf.org; Mon, 11 Dec 2000 09:08:56 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 145WRY-00011x-00; Mon, 11 Dec 2000 09:08:52 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Olafur Gudmundsson Cc: DNSEXT WG Mailing list Subject: Re: WG Last Call: RFC2137 to Historic References: <4.3.2.7.2.20000803144629.00d147a0@localhost> <4.3.2.7.2.20001129132910.00ca6be0@localhost> Message-Id: Date: Mon, 11 Dec 2000 09:08:52 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The following last call has completed, the consensus is that this > is not needed. so therefore it should be moved to historic, or that moving it to historic is not needed. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Dec 12 00:26:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13341 for ; Tue, 12 Dec 2000 00:26:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 145hM3-000BJ1-00 for namedroppers-data@psg.com; Mon, 11 Dec 2000 20:47:55 -0800 Received: from ietf.207.137.73.155.tx.verio.net ([207.137.73.155] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 145hM2-000BIv-00 for namedroppers@ops.ietf.org; Mon, 11 Dec 2000 20:47:54 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 145hM1-0002cv-00 for namedroppers@ops.ietf.org; Mon, 11 Dec 2000 20:47:53 -0800 Message-Id: <4.3.2.7.2.20001211234444.00d49d30@localhost> Date: Mon, 11 Dec 2000 23:47:54 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT agenda addition Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I forgot this draft the first time around In other drafts Mark Andrews wants to discuss his draft "HTTP host and port selection using URIs and SRV RRs A generic mechanism for resolving port conflicts between URIs and SRV RRs" http://www.ietf.org/internet-drafts/draft-andrews-http-srv-00.txt Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Dec 12 18:03:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00593 for ; Tue, 12 Dec 2000 18:03:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 145xge-00064y-00 for namedroppers-data@psg.com; Tue, 12 Dec 2000 14:14:16 -0800 Received: from ietf.207.137.75.121.tx.verio.net ([207.137.75.121] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 145xgb-00064r-00 for namedroppers@ops.ietf.org; Tue, 12 Dec 2000 14:14:13 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 145xgb-0003cf-00 for namedroppers@ops.ietf.org; Tue, 12 Dec 2000 14:14:13 -0800 From: "Richard Barr Hibbs" To: "Namedroppers" Cc: "Danielle Deibler" , "Jon Saperia" , "Steve Hotz" Subject: Power Point Slides of New DNS MIB Presentation Date: Tue, 12 Dec 2000 13:56:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C06443.58FA77D0" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C06443.58FA77D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit attached are the slides from tomorrow's presentation of a new DNS Server MIB. --Barr Hibbs ------=_NextPart_000_0000_01C06443.58FA77D0 Content-Type: application/vnd.ms-powerpoint; name="DNS-MIB.ppt" Content-Disposition: attachment; filename="DNS-MIB.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAYwAAAAAAAAAA EAAAagAAAAEAAAD+////AAAAAGIAAAB+AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////+g Rh3w7D0AAL77Qo+6NeV73Q6x9uOegUL//9j/4AAQSkZJRgABAgEAlgCWAAD/7Q4CUGhvdG9zaG9w IDMuMAA4QklNA+kAAAAAAHgAAgAAAEgASAAAAAAC7AJA//j/7gMQAlItAwUoA/wAAv0AAlgCWAAA AAAYVhLABLAALQWgXuwAJggBAQEAGAABJw8AAQABAAAAAAAAAAAAAACAAAEAAAAAIBQAAAAAAAAA AAAAAAAAAAAAAAAAAAAASQQAAAAIAAQ4QklNA+0AAAAAABAAlgAAAAEAAQCWAAAAAQABOEJJTQQN AAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoA AQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAAB ADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD///////// ////////////////////A+gAAAAA/////////////////////////////wPoAAAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAADhCSU0ECAAAAAAA EAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAABOEJJTQQMAAAAAAvuAAAAAQAAAHAAAAA4 AAABUAAASYAAAAvSABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA/+4ADkFkb2JlAGSAAAAAAf/bAIQA DAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwM/8AAEQgAOABwAwEiAAIRAQMRAf/dAAQAB//EAT8AAAEFAQEBAQEBAAAA AAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcG CAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZE k1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5en t8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKS Q1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2 hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9VSSSSUpJV8PqGDn1vswsivJZW91Vjqn B4a9v063bCdr2yrCSlJJJJKUq+dnYfTsS3NzbW0Y1Dd1ljuAOB/Kc97vZWxvvsf7GI1ttdNb7bXt rrraXPe4gNa0Dc573O9rWtavFfrX9bcv6yZYdDqenUuJxMY/5v2m/wDeybG/+w1f6Gr/ALUW3y4M JyyoaRHzFfjgZmh9S9H1r/Grkm59PRMattLXENyskOcXiI314rDT6Pu9zPXt3/6THrXMZH1y+tWS 4Ot6peCOBVsqH+bRXX/0lns6Z1OzFObXhZD8MNc45LanmoNZPqvNwb6e2rY/1FWWljwYo6RiDW5P qLZjjxjbV6HA+v31rwiIzftTB/g8pjbAf+uV+hkf+Drtfq5/jK6d1FzMXqrB07KcIFxcDjPIA/wr 9rsZ9jt+yq/2f4P7TdcvKUtDodQeQUMnLY5jbhPeKpYYHpRfolJedf4tfrXa+wfV7qFrrJE9Ne4F xAYHPuxLLZ/wdbfUxd/+D9ar1fZjr0VZmXGccjE/77VlExJBf//Q9Ixer4WV1LN6ZS4uyemio5QL SA312utpDXH6f6Nn5qbqXWcHpluHVluc13UL24uPtaXD1Hglm/aPY32/6s3rC+rv/i7+t3/tN/8A bd6j9erKx1D6sVF7Ra/q9Lm1z7i1oc172t/dY6yvf/xiSnG+rHVz0zoXXyyvJdfZ1PqJptxsd+QK 3srqcx93pssrr/SbNnr/AKN//Feqt36vfWqo/VyjKza81z8bp4zMzJtxrWsfsaH3elkWMZTe9/8A O0+k/wB9Kyfqp/4lPrX/AOHuo/8Anpi0q/8A8lR/9MTv/bUpKdTH+tOBl9Vb03DoysnVzMjLrpd9 mosYz13Y2Zkv2NqyNu1jqfe+q79Dd6dqpWfX3pjC21uB1Ozp7mC09TbhW/Zm1Eep67n2NZd6La/0 nqMo+gpdLz+mfVr6hYOfkA14eLhUWPFTZc59rWfRYP8AC5OTd+d7PUt/S2KvVm/4yeoVV5mLhdL6 bRe0ObiZz8izIYD/AKc47Ka97v5z0tnqVfzd36VJTW+v31ix7PqbXk9MyG243V3toFzSdaS2y3JE fSa7bQ/Gvre3fXvsrf8ApVyeH/i4+tOXiDL9KnHLhubj5FjmXERubuYyq2upzv8AR227/wDS+mp9 MaHdJ+oQdHoHPyQds7d32vdT9L3fm/nLov8AGp1LqmDV00YmTdiY1r7jfZS51U2NFX2Zj8ivY9vt dkvbV6n6T0/+CVzDOcY44QoHISTKX9VlhKQAESBxHctnp2Fl4H+LDMw82p1GTTidQbZU/kHdlntL XNc3312M9ljP0jFw7fqP9YrOnY/Uaaa7qctlT8euuybXi/b6X6JzGMbtY/1b99vp0U+pbv8A0a77 Hy+oZn+LO/J6jJybOm5JLnCHPYGXNx7n/wAu/HFVz/66V3U8vpP+LPFz8MhuTV07EFT3AODS9lFP qbXe1zq/U3s3+xNhlyQlLhrinko9rWxnKMiI/pF4vL/xb/WnFwzl+lTeWt3PxqLHPuAjc6GPqrrt ez9yq3/ifVWZ0L6s9Z+sBcem0tdTWQ2zJtdsqaSN4buh9lj9v5lNVnp76/V2eou8/wAV/V+pZ+N1 CjOyH5QxrK3VWXOL7B6jXb2Osd9Jm6r2Kh9Xfrd0Po+R1foXUgcOg52W+i6lr/oOsdV6Tvsv61Xa zb+iyGf4P/C1PqYpjmzA5IUJThXyjof6rKcmQGUdyPBweqfU36x/VmlnWrDjWMwra7Q+p7nbLG2V /Z99V1VG9j7/AE2fo169g5dedhY+bUCK8mplzAedtjRY2f8AOXnXVvqV05v1cyesfVvqd9uA+s5N uK+zfRbVUfV2Nj03eribbHV/avtFnrV+l+is/SLt/qrP/NjpE/8AcHH/APPVagzz44RJPFIEx24D 9QxTlxUSbO23CX//0e26p9W863rA6z0bqZ6XlWVtpzGGlt9N7GEupdbS59P6evds9f1PU9H9FX6a o3fUjOzc7C6n1XrD8zP6fl15FDhSKqWUMJfbh04tduxlmTZs9bNsfddsoor/AMGutSSU4fQfqvV0 nB6jg3XfbKup5V+TYCz04bkNax9Hte/d7WfznsVPC+qnWqOj39EyutDKwH4VuDjs+ytY+sWNbRRY +1tx9f7LU17GV/ovV9X9JZ/NrqEklORf9W8PM+rLPq5nOddjjHqx32s/RuJpDPTvZ9PY9ttTLtn6 Sv8A0nqVqhi/Vz61MppxMv6yOvxaxsu2Yra8i2uNnpnO9e2yp+3/ALU1s+1fn+t6v6RdMkkp4T6z fVazpv1GZiYNn/I2S/PqNQcwsr9S+5zanPtusa7DqynWMtdc+z9X/wBIsvF/xrZjMSujP6bXm31g b8gW+kHuadzLTR9nubVZ7Wv/AEb/AOd/m/TXpr2MsY5j2h7Hgtc1wkEHQtcCvF/rf9VMn6u5x2t3 dMyHn7FcJIaD7m4dznF22+pv81vd+tVfpP531667fLe3Me3kGxuHT6MuLgPpl9C6V3+MnPyuj5nT czEbdbnV31uyRbsFbbg9jG1Ywx3ezGrft9+R6l359nvVXN+vD8v6qs+rZwQxrKKMf7V6xJPoel+k +z+g3+c9H6Hr+xcwkrg5fECCI7Hi3O7P7MLuutvQ/VP64P8AqyMsMwxmfaywmbfS2+mHN/0ORv3b 0bp/1ywsarNozOiUdRqzM67PDb7GkVuuj9G1luNc1/pNbs9b9Hv/ANGuYSJABJMAck8IywY5EyI1 lvqeiTigSSer2HUPrxndbwa/q30nAp6XVnFuGA15dDbXNqbVW2urHroq/wBP7Lv1f1P5v6a9TwsW rCw6MOmfSxq2U17tTtY0Vs3cfmtXC/UL6mZeGD1zOr9LODHDp2NbI2b27ftGS0fpGvsa70vR+nTT 6vqfprf0HT9N6r1vIvxqsvpvoVWVNsvyd5AY91TLvs7aHM9X1WXuups3/of0X876932avPz8BPDi rhjqdfmk1sgjdR2D/9L1VJfKqSSn6qSXyqkkp+qkl8qpJKfqpBy8TFzcd+LmVMyMe0RZVYA5pAO4 S138pfLaSQu9FPsvWv8AFSTYbehZTWMcdcXLLiGg7v5rLrbbbtb7Gsrupuf/AN2Vzd31A+t9Ti39 nG0AwH120lp8277arf8AOrXnyS0cX3qteGv6+/8AzWxD3q8PF9IxP8W/1tyHEWY1WIBw7IubB+H2 P7W5dr9XP8XXSukXNy8uz9o5lTw+h7m+nXWWztdXjB9jX2+7f6t77vT/AEfoeivAkkzmPvPCbrh6 +3/LiW5Pdr1fL4P1UkvlVJUWF//ZOEJJTQQGAAAAAAAHAAQBAQABAQD/4gxYSUNDX1BST0ZJTEUA AQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JH QgAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRi a3B0AAACBAAAABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAA AHBkbWRkAAACxAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAE DAAAACR0ZWNoAAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0 AAAAAENvcHlyaWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAA AAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEA AAABFsxYWVogAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZ AAC3hQAAGNpYWVogAAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3Lmll Yy5jaAAAAAAAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1 bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1 bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAA AAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAA LFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAA AEwJVgBQAAAAVx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABD UlQgY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBj AGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA 9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGx AbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwC tgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5 BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYF lgWmBbUFxQXVBeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0 B4YHmQesB78H0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJ ugnPCeUJ+woRCicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxD DFwMdQyODKcMwAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUP QQ9eD3oPlg+zD88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKE EqMSwxLjEwMTIxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYW SRZsFo8WshbWFvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpR GncanhrFGuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e 6R8THz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPC I/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYp OClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7u LyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1 TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvo PCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdD OkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrE SwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdT E1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuV W+VcNVyGXNZdJ114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk 6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5r bsRvHm94b9FwK3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54 zHkqeYl553pGeqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INX g7qEHYSAhOOFR4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaO zo82j56QBpBukNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/Jpo mtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum /adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOu tCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzB Z8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83 z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3Zbe HN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R 7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9 Kf26/kv+3P9t////7gAhQWRvYmUAZAAAAAABAwAQAwIDBgAAAAAAAAAAAAAAAP/bAIQABgQEBAUE BgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAEHBwcNDA0YEBAYFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8IAEQgAlwEsAwERAAIRAQMRAf/EAOsAAQACAgMBAQAAAAAAAAAAAAAHCAUGAgME AQkBAQADAQEBAAAAAAAAAAAAAAAEBQYDAgEQAAAFBAAFAwIFBAMAAAAAAAECAwQFAAYHCDBAETM3 EBITMjUgFRY2OFAhMRQiIzQRAAIBAgMEAwgMCwYFBQAAAAECAwQFABESISITBjFBMhBRYXFCUmIU MIFygpKyIzNzdLR1QJGhscGiwpOzJBUg0mOjNAdQ0YMWdvJDU2QlEgABAgIFCAgGAQUAAAAAAAAB AAIREhBAITEiMEGBMkJScrIgcZGxYoKSolFhodIDE1Dw0eHiQ//aAAwDAQECEQMRAAAAtSAAAAAA AAAAAYLt1jqwm6vKkeb19yvLnukONIUCF6PPwAAAAAAAAAAAAADUpUiuWhu4zsp/H6AAyXLnONJU z3R1Pq8+QAAAAAAAAAAABC1xZ1n0l90evoAAAG1RI9ucpm9lj8QAAAAAAAAAABClxZ1j0t/8+gAA AAM5w43Ox+Yz3DkAAAB5juOYAAAABp8uTS3Y6jp9fR6+fjh9++f36AAAA3+vhXIyOa+gAAAq+TIb 2eM9oAAABUHWaONbKePvx+gmDx0cz5lQNdpQAAABbLK52VquvAAAFYCYzCGolhQAAAa7I7Ua2us+ fT4+n6CYPHRzPmVA12l+H0fD6AH34+fUjV0G4WSzYEUnElgFUT3m3EMGJLDEfHWZczRqBgicDHXF nX2+uba5XO7dFjRbZT5XrK+OZ83RpsuXKqti2zsJtpqvC9utSdXosly8WhzVBscfjg+3WlOy1F8M Pku/58EJnEm4FJDfCYzBmpFhSg5cY3IA6ik5Jmhu9tixpkqK2v17cejz5nmkqY2sJusSZE4U1VGt jN1yR3m2mq4Yt7PNcuUgQIdRdVo/V58xrZT7vYvKbTG4CEziTcCkhvhMZgzUiwpR0vEcCrRjj2Gg ko6O9mSorNvixvz/AN3sefz5+gWDx0cWE3WJMicKaqpJs9Tr/ftfvC5CKLSwiyzsLOZuh9vjzoU6 XUzVaK3uTze6Q4whow5Pp0lDCWiYzCGolhSkJd4iYjItMeYo4TLf3O1xY8uVVdVbT3/q8ebP5uij awm6xJkThTVVGNtrMP16X/wmPii0sK4aG7xfXpPdFTz/AEVRVfT39is/S57hyGJKTk0GnGpkiExn tKhliCBC7xrBTomg1k04sPZz67aC6uHks1muPPT5UjJePGqSZGsSZE4U1VRjbazD9el/8Jj4otLD r+/ZZqq4a/I7VL1Oiurjsv8AQDpNbNkByOZ9MKczIncDzGvmzHA6PfqiG313V6Z7hy12R37vPn59 fH3s+fPN69fPr1ePPD794Ge4cRr8jvMlPV2hzVCAAAAAAAAABW/Q3cD3tuAAAAAAOz58uzjMttcW OAAAAAAAAAB4ffqlGy1OuSe4AAAAAE+0NPNlNVeX169njznePIAAAAAAAAAanKkU512lxPbqAAAA BK1VXWvy+fwXbph+vTz+vUgQYgAAAAAAAAAGtyO1U9RodHnSwAAB2fPk8UVRYmgpefwAAAAAAAAA AAAOJEdrYwrc2mhz5nX9+gZPlzlKrr53pKnbIscAAAAAAAAAAAAAADFdemizZXm9es1x5b1Ci9nz 4AAAB//aAAgBAgABBQDl0m6ilJwyo0WDCvyQtHhBpSLWLRiiUedbM1FhbxSSdAHT8SqJFAcw9HIJ R5phGCpRSgUOC6ZkWBy2OibmIxh8g8Rw3KqVwgZI/LM2wrKFKBQ9PlLQHKPCkGnzE5aLb/Gl6DQ1 F9/hSrb41OUao/IoHp1oaH/MX3+B19JRH3o8pCp9VHLgqRHD5RUQMIU0kzpiNRffl1TlOVyr1fSh hMJzDSLtRMWboFiP3wIAq7VUr3DSbpUlAX3EMXoPJwgf8ZhYTKUziQMV7FAQtRffmu5TKPMtTuJ+ MlQx+isqIiun7fcig1OCsUiagp4XotycJ9Eh3y/5CjAAgNRffmu5TEvtRVDqWojvSTAVaOmYg03k FUxQWBUj/v8AJwh6l0hKrTKTIYj6TIBai+/NdymnaP8ATUR3lHaZDdSHCVapELUL1+Jyf3KcnEqe 1Z41BYiyB0zU1ZnWM5IBVIvvzXcpp2j/AE1Ed6Y7wDXWkGx1RKQG6HKJnEhk1AOUxAMAM0eoAAB7 C0BAChIA18ZaAOnp8ZaAgBRigNCzRGis0goAAKmV/aTlYdz1DjGEAB44+VTlU1BIZq5KsTiyzykE BUEGphA7cxSco0dGROguVUvDkJAEgEetNlAIo1cAmDlwU5eVbuTomaPyLBwBEAB7LBQj15sB6U3l lCUjJonoDAP4FFyEpeYIWnDxRX+gJ+/qU7sK+V5SguRoevC//9oACAEDAAEFAOXTQOeiRag0ETX5 SWjRI0pHqloxRAedQanVFCOTJQB0/EokU4OIujFEo80zYCeilAA4LhqRUF0DJG5hgz9/FXQKoVZE Uzcs1QFU5SgAenyFoDgPCetvkJy0eh7E/Uaj+9wpFD2Kco3T95/wDUf3uFIJe5LlIsnVRdcEyru1 FBAw02kDkEaj+9JqGKcF1OruQMIicRpJwcgtXIKleOwSBRyoeuo0RwctAHuIYOg8nEh/aTV6qU1j QMV3HAQtR/elvrpoyFWnMb7C1FH6KSIiKxOnVJFuYFI5I1BToOivJxP0ve6X/IUYAEKj+9LfXTMv RJQOpajO6/ZipRyGKNIvVE6RVBQrzu8nEmqTT9qlNX5BK8fl9tR/elvrpt2z/TUZ3TuSEN1KcJFu mQKiuvxrm9x+TjVPaq6bgqVVEyY03bGVFcgFPH96W+um3bP9NRndkx/7fRFA6ggUEEeUIYSimcDF MQDV/qpUAAFCQKAgBQlAa+MtAHp8ZaAoBRigNC1SGgapBQAAVKK9CcrFuOocYRAAcrfIflSHEot1 wVLxZJ1SSInEG5hoyJgLyjZwZIyKxVC8N69BMBHrSBwKdusBAXXKYvKoLmSFs8IrwREAB1JUI9eb AaQkjkpKQSPQGAfwHWISlpQgUu6Op/QE/fQGchXyOqOK40PC/9oACAEBAAEFAOXuK+7PtwsvtDYr UzvbB2Jy7XTvWP2vZCMHsNjKUFhIsJBtzt95RtOy297bA3xcRjnOop+GCuOegHVhbOm90ZKR0qx5 rMGe0YE7168fO+DYOSLksmRsPIEBesPzGesxHgkhERHh2beE1aM7ZF5RF329wX0pGMAQcIOEeHlS /ULKtN48dPXfp+US9LR0iinwcM5HVsy6CHKcnA3j+14G8OmMUpYychpXhZ8vY1y3z6F+pv2NiPFH C11vY09ZnA3j+14H8O7RnOTCOlHjrgZEuT9NWUJjGERAKH+1F+pv/wCfYjxSIgFe4voH96AQH1EQ Cug9AEBrAVzGhMkeuy92XFa2MdZbtuO6sZejXLGRD7N7x/a4VnkF3rRlCD2fa2RhaI2Ce25hGI2A ZXFe2Uchxmy9/wCZ8pZFujCGPM/27kPMF655Wvw2C9n5qrjt3aPFbPAGcEclw20suZtZ9lWfLXdc NlYfsi1GqsdHrJ5I1/tqdaIlEqOxHinWe2rdl7afWBYpGWI9fokka0iIpmjdGN7LuZrk3Hr6xrkx Jih5fknbeMrFt1EWbQSzOPbHmk3LlOPuKPeJvWHpt/4c098PejL+Ye8f2vA/h3abwhpR46rZs7gm d8SY/j7FsX1dNW7trrOZSD2E2udGNNax2uixs6smbHSUfOYr2IfTM5WxHinVL9q1lbNcXYy2ONjQ uK4q2kiUV7K1ybNksWTf5r+T3JdmcYh5b+wuSIsxhEw4seGeY59Nv/Dmnvh70ZfzD3j+14H8O7Te ENKPHVZtRIvtFS66KCORNvJdzLtLM3CuxMNaNgFq1wZuWWxG1ZR/VuFAIGLJAypWAmOYWyiyTlIT ilsR4p1S/atZZkFX+SoRZRCarZjxngzMTO0BiJ2FmWxyEOW88JWHc6F2WxJWvcOGSmLi7022aLL4 Y0xlm7nGVPHjZkzxtP8A6h2U3j+14H8O7SgI4Q0o8dVmb+VVbSzDyMwxpPacQq1qSkWkbHa2vxkN hdsGBgV1nuJGQsGsoYHuqOn8SYHuR1P1sR4p1S/atZE/f8Z9zrZjxnC4+vGchBTnIV3rvf8Af01M 1tGDcuQLBjxjrI9LttqPue2op3kvXe/G26+PTNJ7J2TM9OY23Iqz9p94vteBvDuXLSc3djfBua3e I5Kw9nbQve9czfyprJVkNb3sixb2yBgC7C7q44/1pO+co5+Ph6Kjrb2o2SghkccY1v8Af2Rctq3j bt0xtZDyfbdkxthyjyWszYjxRql+1ayJ+/4z7nWzHjTWQiRMcKJJKARNNMt5ZAta0WDyTkckZOKU pC+rxiyfNwxRjEHDNkzZNxZMxWWatl6TTTTJU5ZNnTykLZ9pwYnZMzq+khFxkk3RxVjNBwiiiikD JmCs3EtZeHmYl3DyzJ++YuFMlZDUQVVVWVJJyaZFZGQWTQevW5fzeWo5znOAiA/m8vSz9+uRs7dN FW+SMgtyusj5AdkVVVWV1itQz+6+V2csMzd/xkEF3C+L7KTs6zeVnIWOm4i/rIlLMuPi644vOsvd t5x9rtnGR4FovG3rBSVz8pknHcTfEDdFrTVsTPDwzhl1drpBBFBG/wCDfTtpZEsV9c76wLEm4Ga5 W+bAt284rImI7qslxwEEFl1sXa5OFjoIIt0eaVSSWSvbW60Zo1y4KyTBGcILtleoegiAVDWxcc2r aesl3SBrJxdZtnJ8/O/pb4XkVrk4OS29aSGh22C0FEPg+Lg//9oACAECAgY/AKvhBKtLWq130Wse xWO+ium4VAiBr2EWbyi7G7+tnpwcJlH8Z8jvuUCIGtzv1PhvKAsGSg6/eUHVmd+ps+LKyuRa6rhu baUBdTeFYclZrt1ftq8TrPxfb0Rp5cnMNV/NtVVrfiekNPLkyc7MVVLt1vMi5ytMButV6g8zs91A 08qEpLcK1ndqLfxmA3laVFpUc+0rLXuWJxowuKgc7UR8Ko49SlzMoDvyZ9lTMzbNA08qbw0RjK1T NM0tBbvNR0ITau0sIY5WCQ/Khw8RqjuJO60KLaBp5U3hoaPlzIj5UeUqZuuPcoOEtF8zd1yDhnTu uqOHUpsz6AHmVw9yLWGZzqBp5U3hobwtR6qPKVK4ylZnD1IObhdHVoPF/ZOPiNUhvCVSm/ZUHCFE Bq7yc0XNKGnlTeGhvC1Hqo8pXlFMGhWbLfdVQ4XtQcLnKBEVGVvYoBXK5WhXCm4KwK0LVb2Kxrex WIMG3ytq36zm1cvEouzbPDVg4XhTDzZb9bfP9qgCI+JOIg79d8EHnVdVYi7aapmmzKSt1+RRKDjc jH4t9Ns/MpRmdh4JZatFqswu3cjEqX8fr+1RNcg7GPcr5T4lEdDEQ1QYJz7ViNm7s/wGCbyqz9nY 5f8AT0/4WL9nuVuS/9oACAEDAgY/AKvhEVbBqtd9FrKxyum4VA17CLN5ROM9ODhFRZ6VA31uZ+rz KAyVt+8oGszu1ebKylSmrwzbSgLqbwr8lZrNuq8c7+iNPdk4i59VDekNPdkyc7cVVJ3QpirTAbtE HYm0DT3IQJFi1ndqlZYN5WlRBUc+0rNYq00WEqBzhQqjipd2iZ+fMpmZqBp7kOGiOq1TNM0KCPiE dCEblhDSrMNDuKqHrTuum2gae5Dhob1I9VGhTN1lAiFF8R4kHBO66o4dSjvUAPMrgi1hiTQNPchw 0N4QjRoUrjArM4KLcLqDxJx+ZqkN5Qz7Kg4UWXbyIGYoae5DhobwhGjQtFMGhWbIqoIzIOGdWiK1 WqxXK5Wq6m5WBWrVatVqsQbvVaQ+XLxKLqsCLwojLfrb5vtUAQjC2RBxudVYhTNykrdfloBKPW3/ AGUBvYeCWWrRavg7dyMSpfx+r7a7B2Me5XynxKzoYiAsImWI2fwGGPlVn7Pctv0q2f3ZP//aAAgB AQEGPwD8HJvV2pqJ+kQu4Mp8US6pD8HBS3UlbcmHQ4RYIz7ch1/5eP5PltFTq41USf1Yxje5fpSO 8J5AfinAFx5dljHlPT1CyfiV0j+NhUlrpLZM2W5XRFFz+kTXH+NsLVUFTFV0z9iaB1kQ+JlJH4dn dKniVzrqgtsGT1D946cwET05Cq4kgoJf6HbGzAgpGPHZfTn2P+74eGkkYvI5zd2JLEnrJO0/2hVW Wvnt84OZaByobwOvYceB1bEdFznTDI5KLtSr0eGaAfGi/dYir7dUx1dHONUU8LB0YeAj8LnsHK7p UXpc0q67Y8VKetVHZkmHwI/K1NuYmrK2d6mrqGLz1ErF3dj1sx2n2L1m1zcSjkYGstspPAmHi8iT zZF3vdLu4W4WqTKRMlrKKQjjQSEdlwOo+Q43X/CX5XsE+m8zp/P1aHbSxONiKeqeQfu03u0y4zO0 npJ9khvFpl0zR7s0LZ8OaInejkHWrfqtvLinvVsbKOXdngYjXDMvbifLrX9Zd72JDXVcNIJMxGZ5 Ej1ZdOWojPLCT08izQyDVHLGwZWHfDDMH2Soue61wm+QtkDeXO42EjzIx8o/wfKxNWVcrT1VQ7Sz zOc2d3ObMT4T3f8AQVP7mT+7gyTUk8UY6XeJ1UZ9G0gD2JDUyH+h3ErDco+pOpJwO/ETvf4erCuh DKwzVgcwQegg+w8o/T1vxIccpfd8f6cFmIVQMyTsAGJzbK6CuWlk4NQ1NIkojkADFGKEgNkRu+xT 0sEmq2WXVR0wB3WlB+Xk9txo9zH3R4xiP3K/mxdPpaX7Qnsf9Kq5NdxsRWnJY5s1MwJgb3oDRf8A T9h5R+nrfiQ45S+74/04v5RipJpQSDlsNVECNmLx97P9nh9hu95BympqdvVvppPk4v8AMZcFmJZi c2Y9JJ6ScbdmMyCB3zswvjGIvcL+bF0+lpftCY2nHSO5s2+Lbjw9fd2nGeRy7+RxsOeKGJ300t2D UE46tUm9Cf3qqPff2Jbry/XPb7gtZTxCojCltDltQ3gw25YW68wVz3C4GuqIvWJAobQgTSu4FGzP utyq18nPL4vUtL/T9MejgrqyTPTry2edjlH6et+JDjlmHkGYwcxmlpDDIHijIjDnib0252cV8/PF e03LSmL12Mz0b5kyqI92Ia/ndHRisk/23rDT2dasrVIJaaPOo4aEnKcavm9HRu4rpP8AcmsaotLU hWkUzU0mVRxEOeUG983r6d3EHK1NfZouXpLnbo2ocouGIZ0haRMyurSdTeVis5W/2jhqBaaFjHPc 6PJJJiDpMjVD6VpoCR8lvI8na1eQtHWc31NbNy+8NQtUstxFVHrMR4euPiv5eWk6cS8of7cW/wDl IaeGWe5pArFXmBJDz1B9Xjyy3Rp14E93539VkO3hf1Cr3c+rTAgjHvcNfBzBUXO0Up1VMsVS9dFG ufTLBVLqCec4TSvnLiohroUpOZLYF9egiz4Usb7FniBJZQWGl0zbQ3lb+Lba0ORuNZrkHfSnQtl8 N0xT2S2KBLLm007A6IYl7cj5dS97ym0riMU9ClbcABxblVqskzN1lc81iX0Y/wBbBjlpopIzsKOi spHiIxLW8u08dpviAvGsQ0U05G3RJGN1C3VImn0tWI1YZEKAR4QMXT6Wl+0Ji7y3W10tfLHXBI5K mGOVlXgqdILgkDM4qHXl63KVicgilhzGSn0cU195vp/W6ypUS09qkzEUKNtUzKPnJCNuhtxOzpZs CGkooKeFdixxRIigeJQBh4Lra4XkYEJVxKIqhD31lUBvaO76OHtkzmoopl41vqyMuJETlkwGwSId 1/heViVpZWpLJREeu1SgF2Ztohiz2ayNrMfm197hY7ZZ6dZFAzqZUE07EdZlk1N+LGkwxkd7SuX5 sFLnY6OfP/3OEqSe1Imlx8LE1Vbhw46KtaWiXMtpWGYtGNR2nIKu3FNWRfN1MSTJ7mRQw/P3Zvr9 J+dsL941X5k7rf8AkM37WOUfp634kOOUvu+P9OL/AO6pPtcWLx97P9nh7l8amZkqP5QRNGSG1Gli AyI254ttkpolWq4SzXOYDelq5FBlZj16TuJ5qKv9ialqYxLT1CNFNEwzVkcFWUjvEHEtngYincXG gkGfSkGp1z99AuOX6TPdjpp5cvC8ir+xie/un83eJmVHI2inp2KKo91JxGPve5U2flSGBo6JzDUX GoBl1yocnESAquhTu621asU9i5phgjkrWEVHcacGNeKezHKhLDfO6rqe15Pldy6fS0v2hMXv6+v8 FO5FboKX+pXqZBKafXw44oyclaVgGObZbqKPg4p7Je7bHQPXNw6OqgkZk4p7Mbq4zGvsqwbtdygu WQ49DXKit18OoRgw+EkZxQyQgcSeepkqCOkyCUpt94iYrv6QUF14EnqJl+b4+k8PV6OrLDG+XG8U EqnaSWihJ9ExgQsvucaaqsju9MQQYqtF17RlmssYV8x6WvBLbSxJPt45bnY5sbfArHwxoEPxe7N9 fpPzthfvGq/Mndb/AMhm/axyj9PW/Ehxyl93x/pxf/dUn2uLF4+9n+zw9wwOM0luFpRh4GjgB7kk 87rFDEpeWVyFVVUZszE7AAOnD2P/AG2t61GcnBhuc0bTSzvnl/LUw6iewZNbP/8AEuBU1t5qbPFL tCT1a0JyP+DSjWvidFwHqOfgJDtINfcWyPj04o6Kql49VTSXGGefMtrkjgmVnzbeOphnvYsrdRoG A8YmP/PHLmjLL1bbl3+I2r9bFS0PzyxOY8unUFOX5cFnJLkksT0knpxDLCSJo3VoiOnWrArl7eEL jJyoLDvHLbi6fS0v2hMXv6+v8FO5zHPIxYrWyQLn1JB8ko+CmLdPGcpIqqB0I6isikdw/Xqb9rE1 jvuoWSql40NUoLmnlYANqUbxifIdneRvdYWqtVdBXU7DMSU8iyDb39JOXt4KuoZW2FSMwR4QcSMa FLZcWB4dwolETBuoui5Ryjv6hq9JcVljuIHrNG+Wtc9EiMNSSLn5Lqc8cuBhkfVAfaLMR+Tu10ka kimq6SWTLqXiaM/xuMV1uVh6xb7lKZE69E8aMje2Vce97k9ZVyLDS00bTTzOclSNAWZie8qjPFtv oGS3O+TVSA7CFlaRlHtKcco/T1vxIccpfd8f6cX/AC6mpPtcWLz97P8AZ4e5H95Wj4lP3LyaVij1 rwUcjr0iKaUcQe/QFPfYvvNM0SS3SGdKCkdgCYYzGJJCmfZMupV1eamnzu5VXGskEVJRxPPUSNsC xxqWY+0BihryMjWPcZyD1cWCV/045cuIG6RU07Hw/Juv7WDaS/8ANWaoeNk6+FOxljbxZtIvvO5V V3LlC9zs1ZI00UdPk0sBc6miaPtFVJ3GXVu9rFJeOZ6NrdaqGRZ1pJ8hNPIh1IugZlIwwzfX2uyv ndy6fS0v2hMXv6+v8FO5zJ951f8AGbFH9Yi/iDuH69TftYlvVmtslfQwTGnl4BDSq6qHPyWethkw 2oGxr0Vdsq0Paylp5AfHutiotV2lmudnip2k9enUl4ZFICrxst/iZtuOWbyvO7lI0eXGNtjM+XfE sunP3uLDREZNBQUyOPS4Slvy925cv3EE0dygenlI7S6huuvpI2l19JcVDVND6zbqn5GbUGFHXwKc 0eOUA6JU6V8uLUyumlsB6mzXWKqy2wIsEiZ94SGVPiY/7Q5NtL2bliZwLrcJCXziBBPrEyhUROv1 ePVJL2dTLiz2C3AihttwoaaNm7Ts9NGGdvSkkdnPusco/T1vxIccpfd8f6cX7l+ly9crKYmkDHIG aJhLGpPVqdAuLrY+YLXUS26plBq6ZQI6qmqYhoJCSaQ2pd10Yp2V3vOoeV7Pba2J61Jn9bq+FGqm GJpMgiNKW1aculcR/eVo+JT9y68tVDiH16LKCcjPhzxsJInI7yyKur0cV1svlneSgrCFrKKQlEl4 ZISopZ8mRthO3JlZd19LdjW1ouwqMvmQlORn3tfG/ZwOW+WbS/LvJMsi/wBWu0xLl41OZVpMkRuj /TQ6mZvnJOHgWSj1Cioay40NMZDmxWOCVF1Hzm04lrEXOW01MVVs6dBJif8AJJq97iO6wIZ6SReD cKTPLiwk57OoSId6M+97LYSvslYlVEwBkjByliY+TLGd5GHh7kktbOs1zZT6nbI2BmkbLd1AfNx+ dI36zbuLLdK1g9XXUkVROwGQ1yLqOQ723Zi6fS0v2hMXv6+P4KdzmT7zq/4zYo/rEX8Qdw/Xqb9r DZOpklrqiRkBGoDJEGY6R2MZSIrjvMAfz40ooRe8oyH5MPVXmtSOQKTDRoQ1RKeoJGDq98dxfKbF PNUJokvFZDAkCnMRU4YKFz69EQLM3namwFUZKoAUDqA/sNTVtPHVU79uGZFkRvGrAg49Y/7UtPGz z1epQdPi0ZYSmo4I6anj2JDCixoviVQAMcYwRmbMHiFF1ZjoOeWeAJ4kl09nWobLPvZ4CRqERdiq oyAHgA7gkvVkoblKAAJaqnilfIdA1Mpb8uM7NZqK2tllrpaeKFsvdIoOOK8EbS5g8QopbMdG0jPu mmuNJDW056YaiNJUPvXDDHrMXKtpScHMOKKDMH4GFihRY4kGSRoAqgDqAGwY4wgjE2efECLqzPXn lnittVUM6augkp5R07silSfazxWWqsXTVUMz08w9KNiMx4G7QwKmhqZaSoXszQO0bj3yEHHAfmS4 mI7CvrMgOXjB1YaaaRpZnObyOSzMe+WOZOFSOsqERRkqLLIAAOoAHBjmq5pYz0o8rspy8BJGCtPU SwqxzZY5GQE98hSMf66p/fSf3sF3Yu7HNmYkkk9ZJwCNhHQcf6+p/fSf3scOeqmmjzz0SSO65jry YkYE1LPJTyjokido2/GpBwFh5kuKquwA1MjD9YnBSo5juLodhX1mRQfgkYaWZ2llfa0jksx8bHM4 quYZkzprPEY4GI2GoqAV2e4i1/DX8Gp+caKP5Cq00100jsyqMopT7tRwz6SJ53s8dPBGZZ5nWOGJ RmzOxyVQO+xOKK0HI1mRnuEi+VUSbX29YTZGvop+DVdpuMQmoq2MxTp15HrB6mU7ynyWxPZ64FkH ylFVZZLPATuuPD5Lr5L+zJztd4SIYsxZYXHbbstU5HyV7MXpan8zCVVfSVs9KwJknpIDMkW8qjiE EaNTOAvnYslPcIau31F/leChhqoDE6vGwX5UE/Jh2ddHnasXPlukd3uVpRHrN3KMa8t1X8phq3h+ Ctb6v5Gshzkt9cBm0MuX60b9EieV7rTia0XiAwVcO0HpSRD2ZI28pG/9W97JHeLxG0PLUDZgHNWr GU9hP8LP5yT3ieckcEKLFDEoSONAFVVUZBVA6ABivtVDo9aqeFw+ISq7kyOcyAfJU4o3gZI4qeir ohKzEPHVS8F6WRRkexLDqbC3O5SRT1FVbdNznRiWkuE1XJUzsBpHyYEiojej2fwY0F4hzdMzS1ke Qngc+VG3xkbcfDyVMRrbOTlDdYFJjyPQJV2mF/dbnmO3sKQQRtNPKwWKKNSzsx6AqjMk4hu/OqcK AZPDZQd9+sessOyv+Eu95+nsYSCCNYoYlCRRIAqqqjIKqjYAPwtopUWSJwVdHAZWB2EEHYRiSrsb mx1zZsY4110rHwxZgx/9JlX0MOxtpudKueVTbzxwQOsx5CYfu8GGpieCZdjRyqUYeNWAPd2nLAjs 9sqq9j1wRO6jxuBoX22wk3MFTFZqU7WhQioqSO9kp4SfDb3OAbTRBq0jTJcZ/lKhu/vkbgPmxhF/ 4B/+/wCo8D/73B0/5uzBM78tq56dFTSxH9SRcahNy+T4a+Jh+IzHCrajy4ZvJ4UlHI+fgObNhfV9 PBy3OHlpy8GWz2L/2QAAAAAAAAAAAAAAAA8A6APuBAAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAA BQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyAxYBAAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QdM AAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAABhWlgWc2hIAhNoSAOyg BzAIAAAAAAAAAJzaEgBXbw0wABQGEgAApA8KAAAAhABgAAQA/////wAApQ8MAAAAAAAACC4AAAAH AAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAA AABAAgAAAAAHAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSoAAAADwAA8KAAAAAAAAbwIAAAAAIMAAADAAAA CgAAAAIAAAABAAAABwAAAAIAAAAFAAAAHwAB8CwAAABSAAfwJAAAAAUFvvtCj7o15XvdDrH2456B Qv8A9D0AAAEAAAAAAAAAAADJAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAA AAAAAIAAAAAADwDQB6UBAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjttTs3JAMqaOwEBAAEPAPoD ZwAAAAAA/gMDAAAAAQEAAAD9AzQAAAApAAAAZAAAACkAAABkAAAA7KAHMAgAAAAAAAAAkNoSAAAA AAAAAAAAlP///57+//8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAA AAIAAAQMAAAAAAAAAAAAAAACAAAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAAC82hIA LoENMEzeEgABAAAAAAAAAAAAAAAAAAAAAAAAAAABEgAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABk AAAAZAAAALzaEgAugQ0wTN4SAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAESAA8AiBNmAAAADwCKE14A AAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE0AAAAAPAK4POAAAABAArw8IAAAAAAEAAAEAAAAA AKwPIAAAAAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAAAAAADwDwDw8BAAAAAPMDFAAAAAMA AAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1J QgAAoQ8UAAAAFQAAAAAAAAgAAAAAFQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKgPZwAAAEdlbmVyYWwg RGVzaWduIENvbnN0cmFpbnRzDUJlIGluZGVwZW5kZW50IG9mIHNlcnZlciBpbXBsZW1lbnRhdGlv bnMuDVV0aWxpemUgU05NUHYzIGZvciBhY2Nlc3MgY29udHJvbC4AAKEPLAAAABsAAAAAAAAAAABN AAAAAQCSAAAAAQATIAAAGwAAAAAAAABNAAAAAAQAAAAEAADqAwAAAAAPAPgDnAgAAAIA7wMYAAAA AQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAAAAP8A////AAAAAAD//wAA/5kAAAD//wD/ AAAAlpaWAGAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAP// /wAAAAAAMzMzAAAAAADd3d0AgICAAE1NTQDq6uoAYADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kz AIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAACAgIAAAAAAAP/MZgAAAP8AzADMAMDAwABgAPAH IAAAAP///wAAAAAAgICAAAAAAADAwMAAAGb/AP8AAAAAmQAAYADwByAAAAD///8AAAAAAICAgAAA AAAAM5n/AJn/zADMAMwAsrKyAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAA QAIAAAAABwAAAP//7wAAAAAA////////LAAAAAADAAAQAKMPfAAAAAUA//0/AAEAIiAAAGQAAAAA AAAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8AAAAAAP///////yAAAAAAAQAAgAUAABMg1AEgAQAA AgAcAIAFAAAiINACQAIAAAIAGACABQAAEyDwA2ADAAACABQAgAUAALsAEAWABAAAAAAgAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////wwA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACj D1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMA AQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAA AAUAAAAAAAAAAAACABwAAQAAAAAAAAACABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAA AAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAA AAAAAgAQAAQAAAAAAAAAAgAQAA8ADATWBAAADwAC8M4EAAAQAAjwCAAAAAYAAAAGBAAADwAD8GYE AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATw0gAA ABIACvAIAAAAAgQAAAAKAACTAAvwNgAAAH8AAQAFAIAAZIWWBYcAAQAAAIEBBAAACIMBAAAACL8B AQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAAAAAA AAEAlgUPAA3wVAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGl0 bGUgc3R5bGUAAKIPBgAAACEAAAAAAAAAqg8KAAAAIQAAAAEAAAAAAA8ABPAWAQAAEgAK8AgAAAAD BAAAAAoAAIMAC/AwAAAAfwABAAUAgAAUiJYFgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIAAAQ8AgAAADgBLAB0BQADw8AEfAQAAAAAADDCwgAAAABAAAAAgCWBQ8ADfCeAAAAAACf DwQAAAABAAAAAACoD1IAAABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQg bGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAAN AAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATwtgAAABIACvAIAAAA BAQAAAAKAACDAAvwMAAAAH8AAQAFAIAA8IyWBYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACAAAEPAIAAAAYA+wAWAGgBAPABHwEAAAAAAAwwsIAAAAAgAAAAcBlgUPAA3wPgAAAAAA nw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAA4AAAD4DwQAAAAA AAAADwAE8LgAAAASAArwCAAAAAUEAAAACgAAgwAL8DAAAAB/AAEABQCAACySlgWBAQQAAAiDAQAA AAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAfQDoAQDwAR8BAAAAAAAMMLCAAA AAMAAAAJApYFDwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAA AQACAAAAAAACAA4AAAD6DwQAAAAAAAAADwAE8LgAAAASAArwCAAAAAYEAAAACgAAgwAL8DAAAAB/ AAEABQCAAACXlgWBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAP IBDQFIAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIApYFDwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAA ACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAA4AAADYDwQAAAAAAAAADwAE8EgAAAASAArw CAAAAAEEAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAIAC6DxwA AABEAGUAZgBhAHUAbAB0ACAARABlAHMAaQBnAG4ADwDuA94CAAACAO8DGAAAAAEAAAANDgAAAAAA AAAAAIAAAAAABQAAAA8ADASOAgAADwAC8IYCAAAgAAjwCAAAAAQAAAAECAAADwAD8B4CAAAPAATw KAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgAAAUAAAAPAATwcgAAABIACvAI AAAAAggAACACAABTAAvwHgAAAH8AAAAEAIAAPKWWBb8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAA gAGwAdAUIAQPABHwEAAAAAAAwwsIAAAAAAAAAA0AlgUPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCI AAAAEgAK8AgAAAADCAAAIAIAAFMAC/AeAAAAfwAAAAQAgADkpZYFvwEAAAEA/wEAAAEAAQMDBAAA AAAQ8AgAAADgBLAB0BRgDA8AEfAQAAAAAADDCwgAAAABAAAADgCWBQ8ADfAiAAAAAACeDwQAAAAB AAAAAACmDw4AAAD4AAAAgAFwAmADUARwBQ8ABPDcAAAAsgQK8AgAAAAECAAAAAoAAEMAC/C0AAAA fwCAAIAABEEBAAAABcGcAAAABgEBAAAAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAg AFMAZQB0AHQAaQBuAGcAcwBcAEIAYQByAHIAIABIAGkAYgBiAHMAXABNAHkAIABEAG8AYwB1AG0A ZQBuAHQAcwBcAE0AeQAgAFAAaQBjAHQAdQByAGUAcwBcAFUARABOAFMAXwBjAGwAcgBfAHMAbQAu AGoAcABnAAAAAAAQ8AgAAADADFAQ0BQEDw8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADd 3d0AZgBmAAAAAABmAGYA/5kAAAD//wD/AAAAlpaWAAAAchcQAAAAAQAwAAAAAAD2BAAAmg0AAAAA 9Q8cAAAAAAEAAO0OAAMAAAAAgBAAAAEAAAADAAAAAQDyBQ8A6AOBBgAAAQDpAygAAACAFgAA4BAA AOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyAxYBAAAvAMgPDAAAADAA0g8EAAAA AQAAAA8A1QdMAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAABhWlgV8 2hIAZNoSAOygBzAIAAAAAAAAAHzaEgBXbw0wABQGEgAApA8KAAAAhABgAAQA/////wAApQ8MAAAA AAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAA AGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA/7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAAr J7PZMAAAACxSAAAMAAAAAQAAAGgAAAACAAAAcAAAAAQAAACQAAAABwAAAKQAAAAIAAAABAEAAAkA AAAYAQAAEgAAACQBAAAKAAAARAEAAAwAAABQAQAADQAAAFwBAAAPAAAAaAEAABEAAABwAQAAAgAA AOQEAAAeAAAAGAAAAFBvd2VyUG9pbnQgUHJlc2VudGF0aW9uAB4AAAALAAAAQmFyciBIaWJicwBQ HgAAAFcAAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXEJhcnIgSGliYnNcQXBwbGljYXRpb24g RGF0YVxNaWNyb3NvZnRcVGVtcGxhdGVzXFVsdHJhRE5TLnBvdAAAHgAAAAsAAABCYXJyIEhpYmJz AHMeAAAAAwAAADEwAHIeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AGluZ0AAAABQb56ODgAA AEAAAABwMcy7d2DAAUAAAAAwVgQ6g2TAAQMAAACrAAAARwAAALRQAAD/////AwAAAAgAiRBnDAAA AQAJAAADUigAAAIAoScAAAAAEQAAACYGDwAYAP////8AABAAAAAAAAAAAADAAwAA0AIAAAkAAAAm Bg8ACAD/////AgAAABcAAAAmBg8AIwD/////BAAbAFROUFAUALQAuAAyAAAA//9PABQAAABNAGkA pwAKAAAAJgYPAAoAVE5QUAAAAgD0AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAM AAEAAAABAAAAAAAAAAUAAAALAgAAAAAFAAAADALQAsADBQAAAAkCAAAAAgUAAAABAv///wIFAAAA BAENAAAABQAAAAcBAwAAAKEnAABBCyAAzAB4AKAAAAAAANACwAMAAAAAKAAAAKAAAAB4AAAAAQAI AAAAAAAASwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAA wNzAAPDKpgAEBAQACAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCA fP8AUFD/AJMA1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAz mQAAM8wAADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/ AADMAAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZAAAz mTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YAM/+ZADP/ zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYzzABmM/8AZmYA AGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAAZswzAGbMmQBmzMwA Zsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkAzACZAAAAmTMzAJkAZgCZ M8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYAmZmZAJmZzACZmf8AmcwAAJnM MwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/zACZ//8AzAAAAJkAMwDMAGYAzACZ AMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAAzGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAA zJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzMZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM /5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA/zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxm ZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+ZZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zM AP/M/wD//zMAzP9mAP//mQD//8wAZmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cA hoaGAJaWlgDLy8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA /wAAAP//AP8AAAD/AP8A//8AAP///wDx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fFh8WHxYWHx8WFh8fFhYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHxYfFh8WFh8WFhYfFhYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fH///// /////////////////////962trzi9v////////Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx//////////////////// ////toKCh4eDgrbd///////x8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f////////////////////+9r4KHh4eDh4OH qbz/9P//8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fH////////////////////2r4eHg4eDjIeHjIOC3b3d//Hx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx///////////////////214eHg4eHh4eDh4OHh6/////x8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/x 8fT0//T09P//3hv//4KCgoyCh4KHh4KHqYKpvP//8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fG86+/r67wH7Oy88W2Y bbWN9N3e3bbegq/etrb/trb///Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx7wf/7Ou87weS8bzsvI2N1/SCtt229IKv 3Y2vvde2///x8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8e+8/5LrvAe8kgf/vLzsjby9r7bxtv+vtt629LaNr///8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fEHvP+S7O9t7Ozs7++S7LWp9N293bbetv+1r97dr7b///Hx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx /////5IH7wf/9PT/9P//goeCtt2pgoyCg4yDgoK2///x8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f////8H8f////// /////7CHh7C2goeHh4eDh4ev3v//8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fH/////////////////////goeHgoeH g4eDh4eptv////Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx/////////////////////92Ch4eHg4cFh4OMtv/////x 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8f//////////////////////va+DBYeHh4eNtv//////8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fH/////////////////////////3bavsLbd3v////////Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYWHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WFhYWFhYWFhYfFhYWHxYfFhYWFh8WFhYWFhYWFh8WFhYWHx YWHx8WFhYWHxYWFhYfHxYWFhYfFhYfFhYWFhYWFh8WFhYWHxYfFhYfHx8WHxYWHxYWHxYWHxYfFh YWFhYfFhYfFhYWHxYWHxYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fFhYfFh8WFh8WHxYWHx8WHxYWHxYfFh8WFh8WHxYfFh8WFh8WHx8fFhYfFh8WFh 8WHx8WFhYfHxYfHxYfFhYfFhYfFhYfFh8WHxYWFh8fFh8WFh8WHx8WHx8WHxYWFh8WHxYWHxYWFh 8WFh8WFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx YWHxYfFhYWFhYfFhYfFhYfFhYWHxYWFhYfFhYWHxYWHxYWHx8fHxYWHxYWHxYWFh8fFhYWFh8WFh 8WFh8WHxYWFh8WFhYfFhYfFhYWHxYWHxYfFhYfFhYfFhYfFhYfFhYfFh8WFhYWHxYfFhYfHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYWFh8WFhYWHx YfHxYWHx8WHxYWHxYfFh8WHxYfFhYfFh8WFhYfHxYWFhYfFh8fFh8WFh8WHx8WFhYWFhYWFhYfFh YWFhYfFh8WFhYWFhYWFh8WFhYWHxYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WFh8fHx8fHx8WHx8WFh8WFh8WHx8WHx8fFh8WHx 8WHxYfFhYWHxYfHxYfFhYfHx8WFhYfHxYfFhYfFh8fFh8fFhYfFh8WFh8WHxYWHxYWHxYfHxYfFh YfFhYfFh8WFh8WHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fFhYfHx8fHx8fFh8fFhYWHxYWHx8fFhYfHxYWFhYfFh8WFh8WHxYWFh 8WFh8WFh8fFhYWFh8WFhYfFhYWHxYWHxYWHxYfFhYWFhYfFhYfFhYWHxYWFhYWHxYWHxYWHxYWHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHxYWFh8fHx8fHx8fFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHxYWHxYWFhYfFhYfFh8WFh8WFhYWHxYWFhYfHxYWFhYfFhYWFh8WFh8WFhYWHxYWFhYfFh YWFh8fHxYfFhYWFh8WFh8WHxYWFhYWHxYWHxYWFh8WFh8WFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WHx8WHx YWHxYWHxYfFhYfFhYfFh8WFh8WHx8WFh8WHxYWHxYfFh8fFh8WFh8WFh8WHxYfFhYfHx8WHxYWFh 8fFh8fFh8WFhYfFh8WFh8WFhYfFhYfFhYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYfFhYfFhYfFh8WFh8WHx YWHxYWHxYWFh8fFhYfFhYfFhYWHxYWHxYWHxYWHxYWFhYWFh8WHx8fFhYfFhYWHxYWHxYWHxYWHx YWHxYfFhYWFh8WHxYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx 8fHx8fHx8fFh8fHx8fHx8fHx8fHx8fHx8fFh8fHx8fHx8fHx8fHx8WHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fFhYWHx8fHx8fHx8fHx8fHx8fHx8fFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFh8fHx8fHx8WFhYfFhYWFh8WHx8WFh 8fFh8WFh8WHxYfFh8WHxYWHxYfFhYWHx8WFhYWHxYfHxYfFhYfFh8fFhYfFhYWFh8WFh8WHxYfHx YWFhYfFhYWFhYWHxYWFhYfFhYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx8fHx8fFh8fFhYfFhYfFh8fFh8fHxYfFh8fFh8WHx YWFh8WHx8WHxYWHx8fFhYWHx8WHxYWHxYfHxYfHxYfHxYfFhYfFhYfFh8WFh8WHxYWHxYWHxYfFh 8WHxYWHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8WHx8fHx8fHxYfHxYWFh8WFh8fHxYWHx8WFhYWHxYfFhYfFh8WFhYfFhYfFh YfHxYWFhYfFhYWHxYWFh8WFh8WFh8WFh8WFh8WFhYfFhYWFh8WFhYWFh8WFhYfFhYfFhYfHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8WFh8fHx8fHx8WFhYfHx8fHx8fHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fFhYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WFhYfHx8fHx 8WFhYfFhYWHxYfFh8WFhYWFh8fFhYWFh8fFhYfFh8WFh8fHx8WHx8WHx8fFh8WFhYWHx8fFhYWFh YfFhYfFhYfFhYWFh8fFhYfFhYWFh8WFhYWHxYWFhYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx8fHx8fFh8fFhYfFh8WHx YfHxYfFh8fHx8WFhYfFhYWFhYfFhYWHx8WFh8fFh8fHxYfFh8WFh8fHxYWHxYfHxYfHxYfHxYWFh YfHxYfHxYfFhYfFhYfFh8WHxYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WHx8fHx8fHxYfHxYWFhYfFh8WHxYWFhYWHx8WHx 8fFh8WHxYfFhYWHxYfFh8WHxYfHx8WFhYWHxYWHx8WFh8WFh8WFh8WFh8WFhYWHx8WFh8WFh8WFh 8WFhYWFhYfFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8WFh8fHx8fHx8WHx8WHx8fHxYfHx8fHx8fHx8fFhYWFh8fFhYfHx8WFh YWHx8fHxYWHx8fFhYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYfHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYfHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fFh8fHx8fHx8WFhYfFhYfHx8WHxYfFhYWFhYWHxYfFhYWHxYfFhYWFhYWHxYfFhYWHx YWFhYfHx8WFhYWHxYfHxYfFhYfFh8fHxYWHxYWHxYfFhYfFhYfFh8WFh8WFh8WHxYWFhYWFhYWHx YWFhYfFhYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfHx 8fHx8fFhYfFhYfHx8fFh8WHxYWHxYWHx8WHxYWHx8WHxYWHxYWHx8WHxYWHx8WHxYWHx8fFhYWHx 8WHxYWHxYfHxYfHx8WFh8WFh8WHxYWHxYfHxYfFhYfFh8fFh8WHxYWHxYfFh8WHxYWHxYWFh8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WHx8fHx8fHxYfFh8WFh 8fHxYfFhYfFhYWFhYfFhYfFhYfFhYfFhYWFhYfFhYfFhYfFhYfFhYfHxYWFhYfFhYWHxYWFh8WFh 8fFhYWHxYfFhYfFh8WFh8WFh8WHxYWHxYWFhYWFh8WFhYfFhYfFhYfFhYfHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFh8fHx8fHx8WFhYfHx8fHx8fHx8fHx8fFh 8fHx8fHx8fHx8fHx8fFh8fHx8fHx8fHx8fHxYWFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx YfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fFh8WHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHxYWFh8fFhYWFhYfHxYWFh8WFhYWHx8fFhYWFh8fFhYWFh8WHxYWHx8WFh YfHx8fFhYWHxYWFhYWFh8WFh8WFhYfFhYWFh8WFhYfFhYWFh8fFh8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFh8fHx8fHx 8fHxYfHxYfFh8fFh8WHxYfHxYfFh8WFh8fHxYfHx8WFh8fHxYfFh8WHxYfFh8WHx8fFh8fHx8WHx YWHxYfHxYfFh8WHxYfFhYfFh8WHxYfHxYfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYfHx8fHx8fHx8WHx8WFhYWFh YWFh8WFhYWHxYWFhYfHx8WHx8fFhYWFhYWHxYfFhYWHxYWFh8fHxYfHx8fFhYWFhYWHxYWHxYfFh 8WFhYWHxYWFh8WHxYWHx8WHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYfFh8fHx8fHx8fHx8fHx8fHx 8WHx8fFh8fFhYfHx8fHx8fHx8fHx8fHx8fHx8WFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYfHx8fHx8fHx8fHx8fHx8fFh8fHxYWFh8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8WFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYWHx 8WHx8WFh8fFh8fFh8fHx8fFhYWFh8fHxYWFh8fFh8fFhYWHx8fHx8WFhYfHx8WFhYWFh8fFhYfHx 8WFhYWFh8fHx8WFhYfFh8WFhYWFhYWFhYWFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WHx8fFh8WHx8fHxYfHx YfHx8fHx8WHx8WHx8fFh8fHxYfHxYfHxYfHx8fFh8fFh8WHx8fFh8fHxYWHx8WHx8fFh8fHx8fHx YfFh8WHxYfHxYfHxYfHx8WHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFh8fFhYfFhYWHxYfFhYfFh8fHx8fFh8fHx YfHxYfHxYWHx8fHx8WHx8fHx8fHxYfFhYWHxYfHxYfHxYfFhYWHxYfHx8fHx8WHxYfFh8WHx8WHx 8WHx8fFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHxYfFh8WHxYfFh8WHx8WHxYfHx8fHxYfHx8WHx8WHxYfFh8fHx YWHx8fHx8fFhYfHxYfFh8WHx8WHx8WHxYfFh8WHx8fHx8fFh8WHxYfFh8fFh8fFhYWFh8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8WFh8fFh8fFh8WFh8WFhYWFh8fHx8WHx8fFh8fFhYfHxYfHxYfHx8fHx8fFh8fHx 8fFh8WFhYWFhYfFhYfFh8WFhYWHx8fHxYWHx8fFhYfHxYfHxYfHx8WHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFh 8fHxYfHx8fHx8fHx8fHx8fHx8fFh8fFh8fHxYfHx8WHx8WHx8WHx8fHxYfHxYfHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8WFh8fHxYWHx8WHx8WHx8fFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fFhYfHxYWFh8fHx8fHx 8fHx8fHx8fFhYWFh8fHxYWHx8WFhYfHxYWFh8fHx8fFhYWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8WFhYfHx8WFhYWFhYWFhYWFh8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx 8fHx8fHx8fHx8fHx8fEFAAAABwEBAAAACAAAAPoCBQABAAAAAAAAAAQAAAAtAQAABwAAAPwCAQAA AAAAAAAEAAAALQEBAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD///// AQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8iAAAAFAAAAF/AkeNBqgAACgD0AwMA awRCYXJyIEhpYmJzCAAAAEIAYQByAHIAIABIAGkAYgBiAHMAAABTIFNlcnZlciBNSUIADBAAAAYA AAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAEAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAA AQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAAGAAAAAAAADAAAAGgBAAACAAAA5AQAAB4AAAAP AAAAT24tc2NyZWVuIFNob3cAAB4AAAAVAAAAVWx0cmFETlMgQ29ycG9yYXRpb24AAHIAAwAAAGca AAADAAAABgAAAAMAAAABAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAABcQCQALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAADAAAAEAAAAFRpbWVzIE5ldyBSb21hbgAPAAAA RGVmYXVsdCBEZXNpZ24AFQAAAEEgTmV3IEROUyBTZXJ2ZXIgTUlCAAwQAAAGAAAAHgAAAAsAAABG b250cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAA AFNsaWRlIFRpdGxlcwADAAAAAQAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAABwAAAAgA AAAIAAAABQAAAAkAAAAHAAAAHwAB8CwAAABSAAfwJAAAAAUFvvtCj7o15XvdDrH2456BQv8A9D0A AAIAAAAAAAAAAADJAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI QAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAUAAAAAAAAAAAAAAAEAAIAA AAAADwDQB/MBAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjttTs3JAMqaOwEBAAEPAPoDZwAAAAAA /gMDAAAAAQEAAAD9AzQAAAAkAAAAZAAAACQAAABkAAAA7KAHMAgAAAAAAAAAcNoSAAAAAAAAAAAA sv///yj///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQM AAAAAAAAAAAAAAACAAAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAACc2hIALoENMCze EgABAAAAAAAAAAAAAAAAAAAAAAAAAAABEgAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAA AJzaEgAugQ0wLN4SAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAESAA8AiBO0AAAADwCKE6wAAAAAALoP DgAAAF8AXwBfAFAAUABUADkAAACLE44AAAAPAK4PhgAAABAArw8IAAAAAAEAAAEAAAAAAKwPIAAA AAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAAAAAAEACvDwgAAAABAQAAAQAAAAAArA82AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwEAAwABAAAAAAAAAAAAAAAAAAAAAAAAAAAAPwDZ DwwAAAAAANoPBAAAAAAACwBPANkPDAAAAAAA2g8EAAAAAAA9AA8A8A9aBAAAAADzAxQAAAADAAAA BAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAAAAAAoA8kAAAATgBlAHcAIABEAE4AUwAgAFMAZQBy AHYAZQByACAATQBJAEIAAAChDxYAAAATAAAAAAAACAAAAAATAAAABAAAAAQAEACfDwQAAAABAAAA AACgD/oBAABHAGUAbgBlAHIAYQBsACAARABlAHMAaQBnAG4AIABDAG8AbgBzAHQAcgBhAGkAbgB0 AHMADQBCAGUAIABpAG4AZABlAHAAZQBuAGQAZQBuAHQAIABvAGYAIABzAGUAcgB2AGUAcgAgAGkA bQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgBzAC4ADQBVAHQAaQBsAGkAegBlACAAUwBOAE0AUAB2 ADMAIABmAG8AcgAgAGEAYwBjAGUAcwBzACAAYwBvAG4AdAByAG8AbAAuAA0ARABvAG4AGSB0ACAA cgBlAGkAbgB2AGUAbgB0ACAAcwBlAHIAdgBlAHIAIABjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBu ACwAIABjAG8AbQBtAGEAbgBkACAAYQBuAGQAIABjAG8AbgB0AHIAbwBsACAAbQBlAGMAaABhAG4A aQBzAG0AcwAuAA0ARABvAG4AGSB0ACAAcgBlAGkAbgB2AGUAbgB0ACAAcwBlAHIAdgBlAHIAIABh AHUAdABoAG8AcgBpAHoAYQB0AGkAbwBuACwAIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4A LAAgAGEAbgBkACAAYQBjAGMAbwB1AG4AdABpAG4AZwAgAG0AZQBjAGgAYQBuAGkAcwBtAHMALgAN AAAAoQ88AAAAGwAAAAAAAAAAAOIAAAABAJIAAAABABMgAAABAAAAAQCTAAAAAAATIAAAGwAAAAAA AADjAAAAAAQAAAAEAACqDxIAAAD9AAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAYAAAAEAAAAAgAA AAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1JQgAAoQ8WAAAA FQAAAAAAAAgAAAAAFQAAAAQAAAAEABAAnw8EAAAAAQAAAAAAqA+aAAAAUHJpbmNpcGFsIFNlY3Rp b25zOg1NQVgtQUNFU1MgcmVhZC1vbmx5IG9yIGFjY2Vzc2libGUtZm9yLW5vdGlmeQ1TZXJ2ZXIg SWRlbnRpZmljYXRpb24gR3JvdXAuDUNvdW50ZXJzIGFuZCBTdGF0aXN0aWNzIEdyb3VwLg1TZXJ2 ZXIgQ29uZmlndXJhdGlvbiBHcm91cC4NDQAAoQ9kAAAAFAAAAAAAIAAAAAAAAAEtAAAAAQAgAAAA AAAAAVkAAAABALIAAAABABMgAAAAAAABAQAAAAAAIAAAAAAAAAEUAAAAAAAAAC0AAAAABAAAAARZ AAAAAAgAAAAIAQAAAAAMAAAADAAA6gMAAAAADwD4A9YIAAACAO8DGAAAAAEAAAABAgcJCAAAAAAA AAAAAAAAAAAAAGAA8AcgAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA//8A/wAAAJaWlgBgAPAHIAAA AP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAYADwByAAAAD///8AAAAAADMzMwAAAAAA 3d3dAICAgABNTU0A6urqAGAA8AcgAAAA///MAAAAAABmZjMAgIAAADOZMwCAAAAAADPMAP/MZgBg APAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADwByAAAAD///8AAAAAAICA gAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAAAAAAADOZ/wCZ/8wAzADM ALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8A AAAAAP///////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAAAAAGQAFAAAANgAAABA AgAAAAAHAAAA///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkAC AAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABk AAAAAAAAAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASAB AAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAA AAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAA BAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAc AAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAA BQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAA AAIAEAAPAAwEHAUAAA8AAvAUBQAAkAAI8AgAAAAGAAAABiQAAA8AA/CsBAAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAkAAAFAAAADwAE8OAAAAASAArwCAAAAAIkAAAA CgAAkwAL8DYAAAB/AAEABQCAAHBv4AaHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA CQABAgIAAAgTACLxBgAAAL8DAAAABAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAAAAAA AAEA4AYPAA3wVAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGl0 bGUgc3R5bGUAAKIPBgAAACEAAAAAAAAAqg8KAAAAIQAAAAEAAAAAAA8ABPAkAQAAEgAK8AgAAAAD JAAAAAoAAIMAC/AwAAAAfwABAAUAgABMe+AGgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkA AQICAAAIEwAi8QYAAAC/AwAAAAQAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAC AOAGDwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQg c3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwA AKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8A BPDEAAAAEgAK8AgAAAAEJAAAAAoAAIMAC/AwAAAAfwABAAUAgAAkf+AGgQEEAAAIgwEAAAAIvwEB ABEAwAEBAAAI/wEBAAkAAQICAAAIEwAi8QYAAAC/AwAAAAQAABDwCAAAAGAPsAFgBoAQDwAR8BAA AAAAAMMLCAAAAAIAAAAHAeAGDwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAAC AAAAAAAAAAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPDGAAAAEgAK8AgAAAAFJAAAAAoAAIMA C/AwAAAAfwABAAUAgAD4gOAGgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIEwAi 8QYAAAC/AwAAAAQAABDwCAAAAGAPsAfQDoAQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAuAGDwAN8EAA AAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAQACAAAAAAACAA4AAAD6 DwQAAAAAAAAADwAE8MYAAAASAArwCAAAAAYkAAAACgAAgwAL8DAAAAB/AAEABQCAAESD4AaBAQQA AAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgTACLxBgAAAL8DAAAABAAAEPAIAAAAYA8g ENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgC4AYPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAA KgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAI AAAAASQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA3d3dAGYAZgAAAAAAZgBmAP+ZAAAA//8A/wAAAJaWlgAgALoPEAAA AFUAbAB0AHIAYQBEAE4AUwAPAPADwgUAAAEA8QMIAAAAAQAAgAAADTAPAAwEggUAAA8AAvB6BQAA cAAI8AgAAAAHAAAABxwAAA8AA/ASBQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAcAAAFAAAADwAE8MoAAAASAArwCAAAAAIcAAAACgAAgwAL8DAAAAB/AAEABQCAACyy 3QWBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAAAABQByABDwAR 8BAAAAAAAMMLCAAAAAAAAAAKAt0FDwAN8FIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYA AAACAAAAAAAAAAAAAgAAAAQAAgAEAAwAAAD5DwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAADwAE 8MwAAAASAArwCAAAAAMcAAAACgAAgwAL8DAAAAB/AAEABQCAAPS43QWBAQQAAAiDAQAAAAi/AQEA EQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAAkAngECABDwAR8BAAAAAAAMMLCAAAAAEAAAAH AN0FDwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxgAAAACAAAAAAAACAAAAgACAAAA BAACAAQADAAAAPgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAPAATwZAAAABIACvAIAAAABBwA AAAKAABjAAvwJAAAAH8ABAAEAIcAAQAAAH8BAAABAL8BEQARAP8BCAAJAD8CAQABAAAAEPAIAAAA sAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAgAAAAUA3QUPAATwFgEAABIACvAIAAAABRwAAAAKAACD AAvwMAAAAH8AAQAFAIAA9L3dBYEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAsApAAqAO0BQPABHwEAAAAAAAwwsIAAAAAwAAAAYC3QUPAA3wngAAAAAAnw8EAAAAAgAA AAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRo aXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAA AAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8NAAAAASAArwCAAAAAYcAAAACgAA kwAL8DYAAAB/AAEABQCAAPjE3QWHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB AgIAAAgAABDwCAAAAGAVAABQB4AWDwAR8BAAAAAAAMMLCAAAAAQAAAAJAt0FDwAN8FIAAAAAAJ8P BAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAAAAAAAgAAAAQAAgAEAAwAAAD6DwQAAAAA AAAAAACqDwoAAAACAAAAAQAAAAAADwAE8NIAAAASAArwCAAAAAccAAAACgAAkwAL8DYAAAB/AAEA BQCAAIzM3QWHAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAA AGAVkAngEIAWDwAR8BAAAAAAAMMLCAAAAAUAAAAIAt0FDwAN8FQAAAAAAJ8PBAAAAAQAAAAAAKAP AgAAACoAAAChDxgAAAACAAAAAAAACAAAAgACAAAABAACAAQADAAAANgPBAAAAAAAAAAAAKoPCgAA AAIAAAABAAAAAAAPAATwSAAAABIACvAIAAAAARwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB 3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgAPAO4D3gIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAQAAgAAAAAAHAAAA DwAMBI4CAAAPAALwhgIAACAACPAIAAAABAAAAAQIAAAPAAPwHgIAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMA C/AeAAAAfwAAAAQAgAA8pZYFvwEAAAEA/wEAAAEAAQMCJAAAAAAQ8AgAAACAAbAB0BTAAw8AEfAQ AAAAAADDCwgAAAAAAAAADQCWBQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8IgAAAASAArwCAAAAAMI AAAgAgAAUwAL8B4AAAB/AAAABACAAOSllgW/AQAAAQD/AQAAAQABAwMkAAAAABDwCAAAAMADsAHQ FGAMDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJYFDwAN8CIAAAAAAJ4PBAAAAAEAAAAAAKYPDgAAAPgA AACAAXACYANQBHAFDwAE8NwAAACyBArwCAAAAAQIAAAACgAAQwAL8LQAAAB/AIAAgAAEQQEAAAAF wZwAAAAGAQEAAABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4A ZwBzAFwAQgBhAHIAcgAgAEgAaQBiAGIAcwBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwATQB5 ACAAUABpAGMAdAB1AHIAZQBzAFwAVQBEAE4AUwBfAGMAbAByAF8AcwBtAC4AagBwAGcAAAAAABDw CAAAAMAMUBDQFAQPDwAE8EgAAAASAArwCAAAAAEIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiT AY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAN3d3QBmAGYAAAAAAGYA ZgD/mQAAAP//AP8AAACWlpYADwDuA94CAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAA AA8ADASOAgAADwAC8IYCAACAAAjwCAAAAAQAAAAEIAAADwAD8B4CAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAACAAAAUAAAAPAATwcgAAABIACvAIAAAAAiAAACACAABT AAvwHgAAAH8AAAAEAIAAIEfdBb8BAAABAP8BAAABAAEDAiQAAAAAEPAIAAAAgAGwAdAUwAMPABHw EAAAAAAAwwsIAAAAAAAAAA0A4AYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCIAAAAEgAK8AgAAAAD IAAAIAIAAFMAC/AeAAAAfwAAAAQAgAB89JYFvwEAAAEA/wEAAAEAAQMDJAAAAAAQ8AgAAAAgBLAB 0BQwDA8AEfAQAAAAAADDCwgAAAABAAAADgCWBQ8ADfAiAAAAAACeDwQAAAABAAAAAACmDw4AAAD4 AAAAgAFwAmADUARwBQ8ABPDcAAAAsgQK8AgAAAAEIAAAAAoAAEMAC/C0AAAAfwCAAIAABEEBAAAA BcGcAAAABgEBAAAAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBu AGcAcwBcAEIAYQByAHIAIABIAGkAYgBiAHMAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAE0A eQAgAFAAaQBjAHQAdQByAGUAcwBcAFUARABOAFMAXwBjAGwAcgBfAHMAbQAuAGoAcABnAAAAAAAQ 8AgAAADADFAQ0BQEDw8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADd3d0AZgBmAAAAAABm AGYA/5kAAAD//wD/AAAAlpaWAAAAchccAAAAAQAQAGcaAAADAEAA/jEAADQsAABWIwAA5DQAAAAA 9Q8cAAAAAQEAAO0OAANDGgAAyjcAAAEAAAAGAAAAAQDyBQ8A6APmCwAAAQDpAygAAACAFgAA4BAA AOAQAACAFgAABQAAAAoAAAAEAAAAAAAAAAEAAAAAAAABDwDyAxYBAAAvAMgPDAAAADAA0g8EAAAA AQAAAA8A1QdMAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAABhWlgV8 2hIAZNoSAOygBzAIAAAAAAAAAHzaEgBXbw0wABQGEgAApA8KAAAAhABgAAQA/////wAApQ8MAAAA AAAACC4AAAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAA AGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwToAAAADwAA8OAAAAAAAAbwYAAA AAUoAAALAAAAHQAAAAYAAAAKAAAABQAAAAIAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAcAAAAHAAAACAAAAAgAAAAFAAAACQAAAAcAAAALAAAABQAAAB8AAfAsAAAAUgAH8CQAAAAF Bb77Qo+6NeV73Q6x9uOeAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA AAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAA ABoAAAAbAAAAHAAAAB0AAAAeAAAA/v///yAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA ZQAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2 AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQA AABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAA/v// //7///9UAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAA YQAAAGwAAAD9////ZAAAAP7///9mAAAAZwAAAGgAAABpAAAAUwAAAP7///9SAAAAbQAAAG4AAABv AAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0A AAB/AAAA/f///4AAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAABCNgWSbT88RhuoAqgC5KegAAAAA AAAAAAAAAACwcAo6g2TAAWsAAADAAgAAAAAAAFAAaQBjAHQAdQByAGUAcwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB/////wIAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPQ9AAAAAAAAQwB1AHIAcgBlAG4AdAAg AFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAPgAAAAAAAAAF AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKAACAQEAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACgAAABcUgAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAHwAAAGWqAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAYAMAAAAAAAUAAIAEgAQAAAAADwALBKgAAAAPAADwoAAAAAAABvAgAAAAAgwA AAMAAAAKAAAAAgAAAAEAAAAHAAAAAgAAAAUAAAAfAAHwLAAAAFIAB/AkAAAABQW++0KPujXle90O sfbjnoFC/wD0PQAAAQAAAAAAAAAAAMkAYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/ AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAA AAAAAAAAAAAAgAAAAAAPANAHpQEAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaO21OzckAypo7AQEA AQ8A+gNnAAAAAAD+AwMAAAABAQAAAP0DNAAAACkAAABkAAAAKQAAAGQAAADsoAcwCAAAAAAAAABw 2hIAAAAAAAAAAACU////nv7//wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A /wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAA AJzaEgAugQ0wLN4SAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAA ZAAAAGQAAABkAAAAnNoSAC6BDTAs3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAARIADwCIE2YAAAAP AIoTXgAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTQAAAAA8Arg84AAAAEACvDwgAAAAAAQAA AQAAAAAArA8gAAAAAAAAAAAAAAAAAAAAAACAA///AQADAAEAAAAAAAAAAAAPAPAPogIAAAAA8wMU AAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAEEgTmV3IEROUyBTZXJ2 ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAVAAAABAAAAAQAEACfDwQAAAABAAAAAACgD/gBAABH AGUAbgBlAHIAYQBsACAARABlAHMAaQBnAG4AIABDAG8AbgBzAHQAcgBhAGkAbgB0AHMADQBCAGUA IABpAG4AZABlAHAAZQBuAGQAZQBuAHQAIABvAGYAIABzAGUAcgB2AGUAcgAgAGkAbQBwAGwAZQBt AGUAbgB0AGEAdABpAG8AbgBzAC4ADQBVAHQAaQBsAGkAegBlACAAUwBOAE0AUAB2ADMAIABmAG8A cgAgAGEAYwBjAGUAcwBzACAAYwBvAG4AdAByAG8AbAAuAA0ARABvAG4AGSB0ACAAcgBlAGkAbgB2 AGUAbgB0ACAAcwBlAHIAdgBlAHIAIABjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuACwAIABjAG8A bQBtAGEAbgBkACAAYQBuAGQAIABjAG8AbgB0AHIAbwBsACAAbQBlAGMAaABhAG4AaQBzAG0AcwAu AA0ARABvAG4AGSB0ACAAcgBlAGkAbgB2AGUAbgB0ACAAcwBlAHIAdgBlAHIAIABhAHUAdABoAG8A cgBpAHoAYQB0AGkAbwBuACwAIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4ALAAgAGEAbgBk ACAAYQBjAGMAbwB1AG4AdABpAG4AZwAgAG0AZQBjAGgAYQBuAGkAcwBtAHMALgAAAKEPLAAAABsA AAAAAAAAAADiAAAAAQCSAAAAAQATIAAAGwAAAAAAAADiAAAAAAQAAAAEAADqAwAAAAAPAO4D3gIA AAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAFAAAADwAMBI4CAAAPAALwhgIAACAACPAIAAAA BAAAAAQIAAAPAAPwHgIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA CAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/AeAAAAfwAAAAQAgAA8pZYFvwEAAAEA /wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BTAAw8AEfAQAAAAAADDCwgAAAAAAAAADQCWBQ8ADfAM AAAAAACeDwQAAAAAAAAADwAE8IgAAAASAArwCAAAAAMIAAAgAgAAUwAL8B4AAAB/AAAABACAAOSl lgW/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAMADsAHQFGAMDwAR8BAAAAAAAMMLCAAAAAEAAAAO AJYFDwAN8CIAAAAAAJ4PBAAAAAEAAAAAAKYPDgAAAPgAAACAAXACYANQBHAFDwAE8NwAAACyBArw CAAAAAQIAAAACgAAQwAL8LQAAAB/AIAAgAAEQQEAAAAFwZwAAAAGAQEAAABDADoAXABEAG8AYwB1 AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAQgBhAHIAcgAgAEgAaQBiAGIA cwBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwATQB5ACAAUABpAGMAdAB1AHIAZQBzAFwAVQBE AE4AUwBfAGMAbAByAF8AcwBtAC4AagBwAGcAAAAAABDwCAAAAMAMUBDQFAQPDwAE8EgAAAASAArw CAAAAAEIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAN3d3QBmAGYAAAAAAGYAZgD/mQAAAP//AP8AAACWlpYAAAByFxAA AAABABAAvBAAAAMAEABFFwAAAAD1DxwAAAAAAQAA7Q4AA5gQAAArGgAAAQAAAAMAAAABAPIFDwDo A+cIAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAQAAAAAAAAAAQAAAAAAAAEPAPID FgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAAGFaWBXzaEgBk2hIA7KAHMAgAAAAAAAAAfNoSAFdvDTAAFAYSAACkDwoA AACEAGAABAD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xgA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BOAAAAAPAADw2AAAAAAABvBYAAAAByQAAAoAAAAVAAAABAAAAAAAAAAHAAAAAgAAAAUAAAAAAAAA BAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAJAAAA/v///woAAAD+//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAQAIA ABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAyAAAAAYAAADQAAAABwAAANgAAAAIAAAA 4AAAAAkAAADoAAAACgAAAPAAAAAXAAAA+AAAAAsAAAAAAQAAEAAAAAgBAAATAAAAEAEAABYAAAAY AQAADQAAACABAAAMAAAA3QEAAAIAAADkBAAAHgAAAA8AAABPbi1zY3JlZW4gU2hvdwAAHgAAABUA AABVbHRyYUROUyBDb3Jwb3JhdGlvbgAAcgADAAAAZaoAAAMAAAAhAAAAAwAAAAYAAAADAAAAAAAA AAMAAAAAAAAAAwAAAAAAAAADAAAAFxAJAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAAAgAAAAQAAAAVGltZXMgTmV3IFJvbWFuAAkAAABVbHRyYUROUwATAAAATmV3IEROUyBTZXJ2 ZXIgTUlCABUAAABBIE5ldyBETlMgU2VydmVyIE1JQgAVAAAAQSBOZXcgRE5TIFNlcnZlciBNSUIA FQAAAEEgTmV3IEROUyBTZXJ2ZXIgTUlCABUAAABBIE5ldyBETlMgU2VydmVyIE1JQgAVAAAAQSBO ZXcgRE6BQv8A9D0AAAQAAAAAAAAAAADJAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAUAAAAA AAAAAAAAAAEAAIAAAAAADwDQB3cCAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjttTs3JAMqaOwEB AAEPAPoDZwAAAAAA/gMDAAAAAQEAAAD9AzQAAAAkAAAAZAAAACQAAABkAAAA7KAHMAgAAAAAAAAA cNoSAAAAAAAAAAAAsv///yj///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAf AP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQA AACc2hIALoENMCzeEgABAAAAAAAAAAAAAAAAAAAAAAAAAAABEgAfABMEPAAAAAAA/QM0AAAAZAAA AGQAAABkAAAAZAAAAJzaEgAugQ0wLN4SAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAESAA8AiBM4AQAA DwCKEzABAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExIBAAAPAK4PCgEAABAArw8IAAAAAAEA AAEAAAAAAKwPIAAAAAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAAAAAAEACvDwgAAAABAQAA AQAAAAAArA82AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwEAAwABAAAAAAAAAAAAAAAA AAAAAAAAAAAAEACvDwgAAAACAQAAAQAAAAAArA8gAAAAAAAAAAAAAAAAAAAAAACAA///AQADAAEA AAAAAAAAAAAQAK8PCAAAAAMBAAABAAAAAACsDzQAAAAAAAAAAAAAAAAAAAAAAIAD//8BAAMAAQAA AAAAAAAAAAAAgAP//wAAAwABAAAAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAACwBPANkPDAAAAAAA 2g8EAAAAAAA9AA8A8A/NBgAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAA AAAAoA8kAAAATgBlAHcAIABEAE4AUwAgAFMAZQByAHYAZQByACAATQBJAEIAAAChDxYAAAATAAAA AAAACAAAAAATAAAABAAAAAQAEACfDwQAAAABAAAAAACgD/oBAABHAGUAbgBlAHIAYQBsACAARABl AHMAaQBnAG4AIABDAG8AbgBzAHQAcgBhAGkAbgB0AHMADQBCAGUAIABpAG4AZABlAHAAZQBuAGQA ZQBuAHQAIABvAGYAIABzAGUAcgB2AGUAcgAgAGkAbQBwAGwAZQBtAGUAbgB0AGEAdABpAG8AbgBz AC4ADQBVAHQAaQBsAGkAegBlACAAUwBOAE0AUAB2ADMAIABmAG8AcgAgAGEAYwBjAGUAcwBzACAA YwBvAG4AdAByAG8AbAAuAA0ARABvAG4AGSB0ACAAcgBlAGkAbgB2AGUAbgB0ACAAcwBlAHIAdgBl AHIAIABjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuACwAIABjAG8AbQBtAGEAbgBkACAAYQBuAGQA IABjAG8AbgB0AHIAbwBsACAAbQBlAGMAaABhAG4AaQBzAG0AcwAuAA0ARABvAG4AGSB0ACAAcgBl AGkAbgB2AGUAbgB0ACAAcwBlAHIAdgBlAHIAIABhAHUAdABoAG8AcgBpAHoAYQB0AGkAbwBuACwA IABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4ALAAgAGEAbgBkACAAYQBjAGMAbwB1AG4AdABp AG4AZwAgAG0AZQBjAGgAYQBuAGkAcwBtAHMALgANAAAAoQ88AAAAGwAAAAAAAAAAAOIAAAABAJIA AAABABMgAAABAAAAAQCTAAAAAAATIAAAGwAAAAAAAADjAAAAAAQAAAAEAACqDxIAAAD9AAAAAAAA AAEAAAABAAAAAAAAAPMDFAAAAAYAAAAEAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQA AABBIE5ldyBETlMgU2VydmVyIE1JQgAAoQ8WAAAAFQAAAAAAAAgAAAAAFQAAAAQAAAAEABAAnw8E AAAAAQAAAAAAqA+aAAAAUHJpbmNpcGFsIFNlY3Rpb25zOg1NQVgtQUNFU1MgcmVhZC1vbmx5IG9y IGFjY2Vzc2libGUtZm9yLW5vdGlmeQ1TZXJ2ZXIgSWRlbnRpZmljYXRpb24gR3JvdXAuDUNvdW50 ZXJzIGFuZCBTdGF0aXN0aWNzIEdyb3VwLg1TZXJ2ZXIgQ29uZmlndXJhdGlvbiBHcm91cC4NDQAA oQ9kAAAAFAAAAAAAIAAAAAAAAAEtAAAAAQAgAAAAAAAAAVkAAAABALIAAAABABMgAAAAAAABAQAA AAAAIAAAAAAAAAEUAAAAAAAAAC0AAAAABAAAAARZAAAAAAgAAAAIAQAAAAAMAAAADAAA8wMUAAAA BwAAAAQAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAEEgTmV3IEROUyBTZXJ2ZXIg TUlCEACfDwQAAAABAAAAAACoD6YAAABTZXJ2ZXIgSWRlbnRpZmljYXRpb24gR3JvdXA6DVNvZnR3 YXJlIFZlcnNpb25pbmcgSW5mb3JtYXRpb24uDVNlcnZlciBTdGFydCBEYXRlIGFuZCBUaW1lLg1T ZXJ2ZXIgTmV0d29yayBJbmZvcm1hdGlvbi4NT3RoZXIgSWRlbnRpZmljYXRpb24gSW5mb3JtYXRp b24gYXMgYXBwcm9wcmlhdGUuAAChDywAAAAdAAAAAAAAAAAAigAAAAEAkgAAAAEAEyAAAB0AAAAA AAAAigAAAAAEAAAABAAA8wMUAAAACAAAAAQAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP FAAAAEEgTmV3IEROUyBTZXJ2ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAVAAAABAAAAAQAEACf DwQAAAABAAAAAACoD30AAABDb3VudGVycyBhbmQgU3RhdGlzdGljcyBHcm91cDoNVHJhZmZpYyBF bmdpbmVlcmluZy4NU3lzdGVtIFR1bmluZy4NWm9uZSBVc2FnZS4NT3RoZXIgQ291bnRlcnMgYW5k IFN0YXRpc3RpY3MgYXMgYXBwcm9wcmlhdGUuDQAAoQ9GAAAAHwAAAAAAAAAAAF4AAAABAJIAAAAB ABMgAAABAAAAAgCTAAAAAAATIAAAHwAAAAAAAABeAAAAAAQAAAAEAQAAAAAIAAAACAAA6gMAAAAA DwDuA94CAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAAAA8ADASOAgAADwAC8IYCAACg AAjwCAAAAAQAAAAEBAAADwAD8B4CAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAAAQAAAUAAAAPAATwcgAAABIACvAIAAAAAgQAACACAABTAAvwHgAAAH8AAAAEAIAA6JXg Br8BAAABAP8BAAABAAEDAiQAAAAAEPAIAAAAgAGwAdAU8AMPABHwEAAAAAAAwwsIAAAAAAAAAA0A 4AYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCIAAAAEgAK8AgAAAADBAAAIAIAAFMAC/AeAAAAfwAA AAQAgADYnOAGvwEAAAEA/wEAAAEAAQMDJAAAAAAQ8AgAAADwA7AB0BQwDA8AEfAQAAAAAADDCwgA AAABAAAADgDgBg8ADfAiAAAAAACeDwQAAAABAAAAAACmDw4AAAD4AAAAgAFwAmADUARwBQ8ABPDc AAAAsgQK8AgAAAAEBAAAAAoAAEMAC/C0AAAAfwCAAIAABEEBAAAABcGcAAAABgEBAAAAQwA6AFwA RABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEIAYQByAHIAIABI AGkAYgBiAHMAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAE0AeQAgAFAAaQBjAHQAdQByAGUA cwBcAFUARABOAFMAXwBjAGwAcgBfAHMAbQAuAGoAcABnAAAAAAAQ8AgAAADADFAQ0BQEDw8ABPBI AAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADd3d0AZgBmAAAAAABmAGYA/5kAAAD//wD/AAAAlpaW AA8A7gPeAgAAAgDvAxgAAAABAAAADQ4AAAAAAAABAACAAAAAAAcAAAAPAAwEjgIAAA8AAvCGAgAA sAAI8AgAAAAEAAAABCgAAA8AA/AeAgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAoAAAFAAAADwAE8HIAAAASAArwCAAAAAIoAAAgAgAAUwAL8B4AAAB/AAAABACAAHRB 4Aa/AQAAAQD/AQAAAQABAwIkAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAAN AOAGDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwiAAAABIACvAIAAAAAygAACACAABTAAvwHgAAAH8A AAAEAIAACBDdBb8BAAABAP8BAAABAAEDAyQAAAAAEPAIAAAAyASwAdAUGAwPABHwEAAAAAAAwwsI AAAAAQAAAA4A3QUPAA3wIgAAAAAAng8EAAAAAQAAAAAApg8OAAAA+AAAAIABcAJgA1AEcAUPAATw 3AAAALIECvAIAAAABCgAAAAKAABDAAvwtAAAAH8AgACAAARBAQAAAAXBnAAAAAYBAQAAAEMAOgBc AEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABCAGEAcgByACAA SABpAGIAYgBzAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABNAHkAIABQAGkAYwB0AHUAcgBl AHMAXABVAEQATgBTAF8AYwBsAHIAXwBzAG0ALgBqAHAAZwAAAAAAEPAIAAAAwAxQENAUBA8PAATw SAAAABIACvAIAAAAASgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA3d3dAGYAZgAAAAAAZgBmAP+ZAAAA//8A/wAAAJaW lgAAAHIXFAAAAAEAEAASOAAABwAgAABEAADmRgAAAAD1DxwAAAADAQAA7Q4AA+43AADMSQAAAQAA AAgAAAABAPIFDwDoAygPAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAQAAAAAAAAA AQAAAAAAAAEPAPIDFgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAFQAaQBt AGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAGFaWBXzaEgBk2hIA7KAHMAgAAAAAAAAAfNoSAFdv DTAAFAYSAACkDwoAAACEAGAABAD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAAC AAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8A AAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUA AIAEgAQAAAAADwALBBABAAAPAADwCAEAAAAABvCIAAAABTwAABAAAAAlAAAACAAAAAoAAAAFAAAA AgAAAAUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAcAAAAIAAAACAAAAAUAAAAJ AAAABwAAAAsAAAAFAAAAAAAAAAQAAAAAAAAABAAAAA4AAAAFAAAAAAAAAAQAAAAQAAAABQAAAB8A AfAsAAAAUgAH8CQAAAAFBb77Qo+6NeV73Q6x9uOegUL/APQ9AAAGAAAAAAAAAAAAyQBjAAvwJAAA AIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI 9wAAEB8A8A8cAAAAAADzAxQAAAAFAAAAAAAAAAAAAAABAACAAAAAAA8A0AevAgAAHwAUBBwAAAAA ABUEFAAAALoddewAypo7bU7NyQDKmjsBAQABDwD6A2cAAAAAAP4DAwAAAAEBAAAA/QM0AAAAJAAA AGQAAAAkAAAAZAAAAOygBzAIAAAAAAAAAHDaEgAAAAAAAAAAALL///8o////AQAAAHAA+wMIAAAA AAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8 AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAnNoSAC6BDTAs3hIAAQAAAAAAAAAAAAAAAAAAAAAA AAAAARIAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAACc2hIALoENMCzeEgABAAAAAAAA AAAAAAAAAAAAAAAAAAABEgAPAIgTcAEAAA8AihNoAQAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAA ixNKAQAADwCuD0IBAAAQAK8PCAAAAAABAAABAAAAAACsDyAAAAAAAAAAAAAAAAAAAAAAAIAD//8B AAMAAQAAAAAAAAAAABAArw8IAAAAAQEAAAEAAAAAAKwPKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAMBAAMAAQAAAAAAAAAAABAArw8IAAAAAgEAAAEAAAAAAKwPIAAAAAAAAAAAAAAAAAAA AAAAgAP//wEAAwABAAAAAAAAAAAAEACvDwgAAAADAQAAAQAAAAAArA80AAAAAAAAAAAAAAAAAAAA AACAA///AQADAAEAAAAAAAAAAAAAAIAD//8AAAMAAQAAAAAAAAAAABAArw8IAAAABAEAAAEAAAAA AKwPLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAAAAAAPwDZDwwA AAAAANoPBAAAAAAACwBPANkPDAAAAAAA2g8EAAAAAAA9AA8A8A+vCQAAAADzAxQAAAADAAAABAAA AAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAAAAAAoA8kAAAATgBlAHcAIABEAE4AUwAgAFMAZQByAHYA ZQByACAATQBJAEIAAAChDxYAAAATAAAAAAAACAAAAAATAAAABAAAAAQAEACfDwQAAAABAAAAAACg D/oBAABHAGUAbgBlAHIAYQBsACAARABlAHMAaQBnAG4AIABDAG8AbgBzAHQAcgBhAGkAbgB0AHMA DQBCAGUAIABpAG4AZABlAHAAZQBuAGQAZQBuAHQAIABvAGYAIABzAGUAcgB2AGUAcgAgAGkAbQBw AGwAZQBtAGUAbgB0AGEAdABpAG8AbgBzAC4ADQBVAHQAaQBsAGkAegBlACAAUwBOAE0AUAB2ADMA IABmAG8AcgAgAGEAYwBjAGUAcwBzACAAYwBvAG4AdAByAG8AbAAuAA0ARABvAG4AGSB0ACAAcgBl AGkAbgB2AGUAbgB0ACAAcwBlAHIAdgBlAHIAIABjAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuACwA IABjAG8AbQBtAGEAbgBkACAAYQBuAGQAIABjAG8AbgB0AHIAbwBsACAAbQBlAGMAaABhAG4AaQBz AG0AcwAuAA0ARABvAG4AGSB0ACAAcgBlAGkAbgB2AGUAbgB0ACAAcwBlAHIAdgBlAHIAIABhAHUA dABoAG8AcgBpAHoAYQB0AGkAbwBuACwAIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4ALAAg AGEAbgBkACAAYQBjAGMAbwB1AG4AdABpAG4AZwAgAG0AZQBjAGgAYQBuAGkAcwBtAHMALgANAAAA oQ88AAAAGwAAAAAAAAAAAOIAAAABAJIAAAABABMgAAABAAAAAQCTAAAAAAATIAAAGwAAAAAAAADj AAAAAAQAAAAEAACqDxIAAAD9AAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAYAAAAEAAAAAgAAAAEB AAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1JQgAAoQ8WAAAAFQAA AAAAAAgAAAAAFQAAAAQAAAAEABAAnw8EAAAAAQAAAAAAqA+YAAAAUHJpbmNpcGFsIFNlY3Rpb25z Og1NQVgtQUNFU1MgcmVhZC1vbmx5IG9yIGFjY2Vzc2libGUtZm9yLW5vdGlmeQ1TZXJ2ZXIgSWRl bnRpZmljYXRpb24gR3JvdXAuDUNvdW50ZXJzIGFuZCBTdGF0aXN0aWNzIEdyb3VwLg1TZXJ2ZXIg Q29uZmlndXJhdGlvbiBHcm91cC4AAKEPTAAAABQAAAAAACAAAAAAAAABLQAAAAEAIAAAAAAAAAFY AAAAAQCyAAAAAQATIAAAAAAAARQAAAAAAAAALQAAAAAEAAAABFgAAAAACAAAAAgAAPMDFAAAAAcA AAAEAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1J QhAAnw8EAAAAAQAAAAAAqA+mAAAAU2VydmVyIElkZW50aWZpY2F0aW9uIEdyb3VwOg1Tb2Z0d2Fy ZSBWZXJzaW9uaW5nIEluZm9ybWF0aW9uLg1TZXJ2ZXIgU3RhcnQgRGF0ZSBhbmQgVGltZS4NU2Vy dmVyIE5ldHdvcmsgSW5mb3JtYXRpb24uDU90aGVyIElkZW50aWZpY2F0aW9uIEluZm9ybWF0aW9u IGFzIGFwcHJvcHJpYXRlLgAAoQ8sAAAAHQAAAAAAAAAAAIoAAAABAJIAAAABABMgAAAdAAAAAAAA AIoAAAAABAAAAAQAAKoPEgAAAKYAAAAAAAAAAQAAAAEAAAAAAAAA8wMUAAAACAAAAAQAAAACAAAA AwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAEEgTmV3IEROUyBTZXJ2ZXIgTUlCAAChDxYAAAAV AAAAAAAACAAAAAAVAAAABAAAAAQAEACfDwQAAAABAAAAAACoD30AAABDb3VudGVycyBhbmQgU3Rh dGlzdGljcyBHcm91cDoNVHJhZmZpYyBFbmdpbmVlcmluZy4NU3lzdGVtIFR1bmluZy4NWm9uZSBV c2FnZS4NT3RoZXIgQ291bnRlcnMgYW5kIFN0YXRpc3RpY3MgYXMgYXBwcm9wcmlhdGUuDQAAoQ9G AAAAHwAAAAAAAAAAAF4AAAABAJIAAAABABMgAAABAAAAAgCTAAAAAAATIAAAHwAAAAAAAABeAAAA AAQAAAAEAQAAAAAIAAAACAAA8wMUAAAACQAAAAQAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPFAAAAEEgTmV3IEROUyBTZXJ2ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAVAAAABAAAAAQA EACfDwQAAAABAAAAAACoD+QAAABTZXJ2ZXIgQ29uZmlndXJhdGlvbiBHcm91cDoNRm9yIHNlcnZl ciBvcGVyYXRpbmcgcGFyYW1ldGVycywgTk9UIHpvbmUgZmlsZXMsIGFuZCB0byBhbnN3ZXIgc3Vj aCBxdWVzdGlvbnMgYXM6DUZvciB3aGljaCB6b25lcyBhbSBJIGF1dGhvcml0YXRpdmU/DVdobyBp cyBhdXRob3JpemVkIHRvIHVwZGF0ZSBhIHpvbmUgZmlsZT8NV2hhdCBpcyB0aGUgaGlzdG9yeSBv ZiB6b25lIGZpbGUgdXBkYXRlcz8AAKEPQAAAABwAAAAAAAAAAABSAAAAAQAAAAAAdwAAAAEAkgAA AAEAEyAAABwAAAAAAAAAUgAAAAAEAAAABHcAAAAACAAAAAgAAPMDFAAAAAoAAAAEAAAAAgAAAAUB AAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1JQgAAoQ8WAAAAFQAA AAAAAAgAAAAAFQAAAAQAAAAEABAAnw8EAAAAAQAAAAAAqA/KAAAARXh0ZW5zaW9ucyBwcm9wb3Nl ZCB0byBoYW5kbGUgU0VUIGZvciBjb21tYW5kIGFuZCBjb250cm9sIG9mIEROUyBzZXJ2ZXJzLg1T aW1wbGUgTUlCIHN0cnVjdHVyZSBpbnRlbmRlZCB0byBtaW5pbWl6ZSBzZXJ2ZXIgcHJvY2Vzc2lu ZyByZXF1aXJlbWVudHMuDVNvbGljaXRpbmcgY29tbWVudHMgb24gZGF0YSB0byByZXBvcnQgdGhy b3VnaCB0aGUgTUlCLgAA6gMAAAAADwDuA94CAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAA BwAAAA8ADASOAgAADwAC8IYCAACAAAjwCAAAAAQAAAAEIAAADwAD8B4CAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAACAAAAUAAAAPAATwcgAAABIACvAIAAAAAiAAACAC AABTAAvwHgAAAH8AAAAEAIAAIEfdBb8BAAABAP8BAAABAAEDAiQAAAAAEPAIAAAAgAGwAdAUwAMP ABHwEAAAAAAAwwsIAAAAAAAAAA0A4AYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCIAAAAEgAK8AgA AAADIAAAIAIAAFMAC/AeAAAAfwAAAAQAgAB89JYFvwEAAAEA/wEAAAEAAQMDJAAAAAAQ8AgAAAAg BLAB0BQwDA8AEfAQAAAAAADDCwgAAAABAAAADgCWBQ8ADfAiAAAAAACeDwQAAAABAAAAAACmDw4A AAD4AAAAgAFwAmADUARwBQ8ABPDcAAAAsgQK8AgAAAAEIAAAAAoAAEMAC/C0AAAAfwCAAIAABEEB AAAABcGcAAAABgEBAAAAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQA aQBuAGcAcwBcAEIAYQByAHIAIABIAGkAYgBiAHMAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBc AE0AeQAgAFAAaQBjAHQAdQByAGUAcwBcAFUARABOAFMAXwBjAGwAcgBfAHMAbQAuAGoAcABnAAAA AAAQ8AgAAADADFAQ0BQEDw8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADd3d0AZgBmAAAA AABmAGYA/5kAAAD//wD/AAAAlpaWAA8A7gPeAgAAAgDvAxgAAAABAAAADQ4AAAAAAAABAACAAAAA AAcAAAAPAAwEjgIAAA8AAvCGAgAAoAAI8AgAAAAEAAAABAQAAA8AA/AeAgAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8HIAAAASAArwCAAAAAIEAAAg AgAAUwAL8B4AAAB/AAAABACAAOiV4Aa/AQAAAQD/AQAAAQABAwIkAAAAABDwCAAAAIABsAHQFPAD DwAR8BAAAAAAAMMLCAAAAAAAAAANAOAGDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwiAAAABIACvAI AAAAAwQAACACAABTAAvwHgAAAH8AAAAEAIAA2JzgBr8BAAABAP8BAAABAAEDAyQAAAAAEPAIAAAA 8AOwAdAUMAwPABHwEAAAAAAAwwsIAAAAAQAAAA4A4AYPAA3wIgAAAAAAng8EAAAAAQAAAAAApg8O AAAA+AAAAIABcAJgA1AEcAUPAATw3AAAALIECvAIAAAABAQAAAAKAABDAAvwtAAAAH8AgACAAARB AQAAAAXBnAAAAAYBAQAAAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQCBAAAAggAAAIMAAACE AAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIA AACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAA AKEAAACiAAAAowAAAKQAAAClAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////24AZAAgAFMAZQB0AHQA aQBuAGcAcwBcAEIAYQByAHIAIABIAGkAYgBiAHMAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBc AE0AeQAgAFAAaQBjAHQAdQByAGUAcwBcAFUARABOAFMAXwBjAGwAcgBfAHMAbQAuAGoAcABnAAAA AAAQ8AgAAADADFAQ0BQEDw8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADd3d0AZgBmAAAA AABmAGYA/5kAAAD//wD/AAAAlpaWAA8A7gPeAgAAAgDvAxgAAAABAAAADQ4AAAAAAAABAACAAAAA AAcAAAAPAAwEjgIAAA8AAvCGAgAAsAAI8AgAAAAEAAAABCgAAA8AA/AeAgAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAoAAAFAAAADwAE8HIAAAASAArwCAAAAAIoAAAg AgAAUwAL8B4AAAB/AAAABACAAHRB4Aa/AQAAAQD/AQAAAQABAwIkAAAAABDwCAAAAIABsAHQFFAE DwAR8BAAAAAAAMMLCAAAAAAAAAANAOAGDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwiAAAABIACvAI AAAAAygAACACAABTAAvwHgAAAH8AAAAEAIAACBDdBb8BAAABAP8BAAABAAEDAyQAAAAAEPAIAAAA yASwAdAUGAwPABHwEAAAAAAAwwsIAAAAAQAAAA4A3QUPAA3wIgAAAAAAng8EAAAAAQAAAAAApg8O AAAA+AAAAIABcAJgA1AEcAUPAATw3AAAALIECvAIAAAABCgAAAAKAABDAAvwtAAAAH8AgACAAARB AQAAAAXBnAAAAAYBAQAAAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0 AGkAbgBnAHMAXABCAGEAcgByACAASABpAGIAYgBzAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMA XABNAHkAIABQAGkAYwB0AHUAcgBlAHMAXABVAEQATgBTAF8AYwBsAHIAXwBzAG0ALgBqAHAAZwAA AAAAEPAIAAAAwAxQENAUBA8PAATwSAAAABIACvAIAAAAASgAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA3d3dAGYAZgAA AAAAZgBmAP+ZAAAA//8A/wAAAJaWlgAPAO4D3gIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAQAAgAAA AAAHAAAADwAMBI4CAAAPAALwhgIAAOAACPAIAAAABAAAAAQ0AAAPAAPwHgIAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAANAAABQAAAA8ABPByAAAAEgAK8AgAAAACNAAA IAIAAFMAC/AeAAAAfwAAAAQAgACoQOAGvwEAAAEA/wEAAAEAAQMCJAAAAAAQ8AgAAACAAbAB0BTw Aw8AEfAQAAAAAADDCwgAAAAAAAAADQDgBg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8IgAAAASAArw CAAAAAM0AAAgAgAAUwAL8B4AAAB/AAAABACAAFgZ3QW/AQAAAQD/AQAAAQABAwMkAAAAABDwCAAA ACAEsAHQFDAMDwAR8BAAAAAAAMMLCAAAAAEAAAAOAN0FDwAN8CIAAAAAAJ4PBAAAAAEAAAAAAKYP DgAAAPgAAACAAXACYANQBHAFDwAE8NwAAACyBArwCAAAAAQ0AAAACgAAQwAL8LQAAAB/AIAAgAAE QQEAAAAFwZwAAAAGAQEAAABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQA dABpAG4AZwBzAFwAQgBhAHIAcgAgAEgAaQBiAGIAcwBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABz AFwATQB5ACAAUABpAGMAdAB1AHIAZQBzAFwAVQBEAE4AUwBfAGMAbAByAF8AcwBtAC4AagBwAGcA AAAAABDwCAAAAMAMUBDQFAQPDwAE8EgAAAASAArwCAAAAAE0AAAADAAAgwAL8DAAAACBAQAAAAiD AQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAN3d3QBmAGYA AAAAAGYAZgD/mQAAAP//AP8AAACWlpYADwDuA8gCAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAA AAAABwAAAA8ADAR4AgAADwAC8HACAAAAAQjwCAAAAAQAAAAEPAAADwAD8AgCAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAADwAAAUAAAAPAATwcgAAABIACvAIAAAAAjwA ACACAABTAAvwHgAAAH8AAAAEAIAAZMvgBr8BAAABAP8BAAABAAEDAiQAAAAAEPAIAAAAgAGwAdAU 8AMPABHwEAAAAAAAwwsIAAAAAAAAAA0A4AYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK 8AgAAAADPAAAIAIAAFMAC/AeAAAAfwAAAAQAgADEW90FvwEAAAEA/wEAAAEAAQMDJAAAAAAQ8AgA AAAgBLAB0BQwDA8AEfAQAAAAAADDCwgAAAABAAAADgDdBQ8ADfAMAAAAAACeDwQAAAABAAAADwAE 8NwAAACyBArwCAAAAAQ8AAAACgAAQwAL8LQAAAB/AIAAgAAEQQEAAAAFwZwAAAAGAQEAAABDADoA XABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAQgBhAHIAcgAg AEgAaQBiAGIAcwBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwATQB5ACAAUABpAGMAdAB1AHIA ZQBzAFwAVQBEAE4AUwBfAGMAbAByAF8AcwBtAC4AagBwAGcAAAAAABDwCAAAAMAMUBDQFAQPDwAE 8EgAAAASAArwCAAAAAE8AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIA EgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAN3d3QBmAGYAAAAAAGYAZgD/mQAAAP//AP8AAACW lpYAAAByFyAAAAABABAADEoAAAYAUAA8WQAAIlwAAAhfAADuYQAA1GQAAAAA9Q8cAAAABQEAAO0O AAPoSQAApGcAAAEAAAAKAAAAAQDyBQ8A6ANKDwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAA AAoAAAAEAAAAAAAAAAEAAAAAAAABDwDyAxYBAAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QdMAAAA AAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAABhWlgV82hIAZNoSAOygBzAI AAAAAAAAAHzaEgBXbw0wABQGEgAApA8KAAAAhABgAAQA/////wAApQ8MAAAAAAAACC4AAAAHAAAA AACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABA AgAAAAAHAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAF AABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQQAQAADwAA8AgBAAAAAAbwiAAAAAU8AAAQAAAAJQAA AAgAAAAKAAAABQAAAAIAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAHAAAA CAAAAAgAAAAFAAAACQAAAAcAAAALAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAOAAAABQAAAAAAAAAE AAAAEAAAAAUAAAAfAAHwLAAAAFIAB/AkAAAABQW++0KPujXle90OsfbjnoFC/wD0PQAABgAAAAAA AAAAAMkAYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAA AAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAABQAAAAAAAAAAAAAAAQAAgAAAAAAPANAH rwIAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaO21OzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMAAAAB AQAAAP0DNAAAAEAAAABkAAAAQAAAAGQAAADsoAcwCAAAAAAAAABw2hIAAAAAAAAAAACm////HP// /wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAA AAAAAAIAAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAJzaEgAugQ0wLN4SAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAnNoSAC6B DTAs3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAARIADwCIE3ABAAAPAIoTaAEAAAAAug8OAAAAXwBf AF8AUABQAFQAOQAAAIsTSgEAAA8Arg9CAQAAEACvDwgAAAAAAQAAAQAAAAAArA8gAAAAAAAAAAAA AAAAAAAAAACAA///AQADAAEAAAAAAAAAAAAQAK8PCAAAAAEBAAABAAAAAACsDyoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAADAQADAAEAAAAAAAAAAAAQAK8PCAAAAAIBAAABAAAAAACsDyAA AAAAAAAAAAAAAAAAAAAAAIAD//8BAAMAAQAAAAAAAAAAABAArw8IAAAAAwEAAAEAAAAAAKwPNAAA AAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAAAAAAAACAA///AAADAAEAAAAAAAAAAAAQAK8P CAAAAAQBAAABAAAAAACsDywAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAD//8BAAMAAQAA AAAAAAAAAD8A2Q8MAAAAAADaDwQAAAAAAAsATwDZDwwAAAAAANoPBAAAAAAAPQAPAPAP0QkAAAAA 8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKAPJAAAAE4AZQB3ACAARABO AFMAIABTAGUAcgB2AGUAcgAgAE0ASQBCAAAAoQ8WAAAAEwAAAAAAAAgAAAAAEwAAAAQAAAAEABAA nw8EAAAAAQAAAAAAoA/6AQAARwBlAG4AZQByAGEAbAAgAEQAZQBzAGkAZwBuACAAQwBvAG4AcwB0 AHIAYQBpAG4AdABzAA0AQgBlACAAaQBuAGQAZQBwAGUAbgBkAGUAbgB0ACAAbwBmACAAcwBlAHIA dgBlAHIAIABpAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AcwAuAA0AVQB0AGkAbABpAHoAZQAg AFMATgBNAFAAdgAzACAAZgBvAHIAIABhAGMAYwBlAHMAcwAgAGMAbwBuAHQAcgBvAGwALgANAEQA bwBuABkgdAAgAHIAZQBpAG4AdgBlAG4AdAAgAHMAZQByAHYAZQByACAAYwBvAG4AZgBpAGcAdQBy AGEAdABpAG8AbgAsACAAYwBvAG0AbQBhAG4AZAAgAGEAbgBkACAAYwBvAG4AdAByAG8AbAAgAG0A ZQBjAGgAYQBuAGkAcwBtAHMALgANAEQAbwBuABkgdAAgAHIAZQBpAG4AdgBlAG4AdAAgAHMAZQBy AHYAZQByACAAYQB1AHQAaABvAHIAaQB6AGEAdABpAG8AbgAsACAAYQB1AHQAaABlAG4AdABpAGMA YQB0AGkAbwBuACwAIABhAG4AZAAgAGEAYwBjAG8AdQBuAHQAaQBuAGcAIABtAGUAYwBoAGEAbgBp AHMAbQBzAC4ADQAAAKEPPAAAABsAAAAAAAAAAADiAAAAAQCSAAAAAQATIAAAAQAAAAEAkwAAAAAA EyAAABsAAAAAAAAA4wAAAAAEAAAABAAAqg8SAAAA/QAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAG AAAABAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAAQSBOZXcgRE5TIFNlcnZlciBN SUIAAKEPFgAAABUAAAAAAAAIAAAAABUAAAAEAAAABAAQAJ8PBAAAAAEAAAAAAKgPmAAAAFByaW5j aXBhbCBTZWN0aW9uczoNTUFYLUFDRVNTIHJlYWQtb25seSBvciBhY2Nlc3NpYmxlLWZvci1ub3Rp ZnkNU2VydmVyIElkZW50aWZpY2F0aW9uIEdyb3VwLg1Db3VudGVycyBhbmQgU3RhdGlzdGljcyBH cm91cC4NU2VydmVyIENvbmZpZ3VyYXRpb24gR3JvdXAuAAChD0wAAAAUAAAAAAAgAAAAAAAAAS0A AAABACAAAAAAAAABWAAAAAEAsgAAAAEAEyAAAAAAAAEUAAAAAAAAAC0AAAAABAAAAARYAAAAAAgA AAAIAADzAxQAAAAHAAAABAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAAQSBOZXcg RE5TIFNlcnZlciBNSUIAAKEPFgAAABUAAAAAAAAIAAAAABUAAAAEAAAABAAQAJ8PBAAAAAEAAAAA AKgPpgAAAFNlcnZlciBJZGVudGlmaWNhdGlvbiBHcm91cDoNU29mdHdhcmUgVmVyc2lvbmluZyBJ bmZvcm1hdGlvbi4NU2VydmVyIFN0YXJ0IERhdGUgYW5kIFRpbWUuDVNlcnZlciBOZXR3b3JrIElu Zm9ybWF0aW9uLg1PdGhlciBJZGVudGlmaWNhdGlvbiBJbmZvcm1hdGlvbiBhcyBhcHByb3ByaWF0 ZS4AAKEPLAAAAB0AAAAAAAAAAACKAAAAAQCSAAAAAQATIAAAHQAAAAAAAACKAAAAAAQAAAAEAACq DxIAAACmAAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAgAAAAEAAAAAgAAAAMBAAAAAAAAAACfDwQA AAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1JQgAAoQ8WAAAAFQAAAAAAAAgAAAAAFQAA AAQAAAAEABAAnw8EAAAAAQAAAAAAqA99AAAAQ291bnRlcnMgYW5kIFN0YXRpc3RpY3MgR3JvdXA6 DVRyYWZmaWMgRW5naW5lZXJpbmcuDVN5c3RlbSBUdW5pbmcuDVpvbmUgVXNhZ2UuDU90aGVyIENv dW50ZXJzIGFuZCBTdGF0aXN0aWNzIGFzIGFwcHJvcHJpYXRlLg0AAKEPRgAAAB8AAAAAAAAAAABe AAAAAQCSAAAAAQATIAAAAQAAAAIAkwAAAAAAEyAAAB8AAAAAAAAAXgAAAAAEAAAABAEAAAAACAAA AAgAAPMDFAAAAAkAAAAEAAAAAgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAABBIE5ldyBE TlMgU2VydmVyIE1JQgAAoQ8WAAAAFQAAAAAAAAgAAAAAFQAAAAQAAAAEABAAnw8EAAAAAQAAAAAA qA/kAAAAU2VydmVyIENvbmZpZ3VyYXRpb24gR3JvdXA6DUZvciBzZXJ2ZXIgb3BlcmF0aW5nIHBh cmFtZXRlcnMsIE5PVCB6b25lIGZpbGVzLCBhbmQgdG8gYW5zd2VyIHN1Y2ggcXVlc3Rpb25zIGFz Og1Gb3Igd2hpY2ggem9uZXMgYW0gSSBhdXRob3JpdGF0aXZlPw1XaG8gaXMgYXV0aG9yaXplZCB0 byB1cGRhdGUgYSB6b25lIGZpbGU/DVdoYXQgaXMgdGhlIGhpc3Rvcnkgb2Ygem9uZSBmaWxlIHVw ZGF0ZXM/AAChD0QAAAAcAAAAAAAgAAAAAAAAAVIAAAABAAAAAAB3AAAAAQCSAAAAAQATIAAAHAAA AAAAAABSAAAAAAQAAAAEdwAAAAAIAAAACAAA8wMUAAAACgAAAAQAAAACAAAABQEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPFAAAAEEgTmV3IEROUyBTZXJ2ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAV AAAABAAAAAQAEACfDwQAAAABAAAAAACoD8oAAABFeHRlbnNpb25zIHByb3Bvc2VkIHRvIGhhbmRs ZSBTRVQgZm9yIGNvbW1hbmQgYW5kIGNvbnRyb2wgb2YgRE5TIHNlcnZlcnMuDVNpbXBsZSBNSUIg c3RydWN0dXJlIGludGVuZGVkIHRvIG1pbmltaXplIHNlcnZlciBwcm9jZXNzaW5nIHJlcXVpcmVt ZW50cy4NU29saWNpdGluZyBjb21tZW50cyBvbiBkYXRhIHRvIHJlcG9ydCB0aHJvdWdoIHRoZSBN SUIuAADqAwAAAAAPAO4D3gIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAQAAgAAAAAAHAAAADwAMBI4C AAAPAALwhgIAAIAACPAIAAAABAAAAAQgAAAPAAPwHgIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAA AAAAAAAAAAAAAgAK8AgAAAAAIAAABQAAAA8ABPByAAAAEgAK8AgAAAACIAAAIAIAAFMAC/AeAAAA fwAAAAQAgAAgR90FvwEAAAEA/wEAAAEAAQMCJAAAAAAQ8AgAAACAAbAB0BTAAw8AEfAQAAAAAADD CwgAAAAAAAAADQDgBg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8IgAAAASAArwCAAAAAMgAAAgAgAA UwAL8B4AAAB/AAAABACAAHz0lgW/AQAAAQD/AQAAAQABAwMkAAAAABDwCAAAAMADsAHQFDAMDwAR 8BAAAAAAAMMLCAAAAAEAAAAOAJYFDwAN8CIAAAAAAJ4PBAAAAAEAAAAAAKYPDgAAAPgAAACAAXAC YANQBHAFDwAE8NwAAACyBArwCAAAAAQgAAAACgAAQwAL8LQAAAB/AIAAgAAEQQEAAAAFwZwAAAAG AQEAAABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwA QgBhAHIAcgAgAEgAaQBiAGIAcwBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwATQB5ACAAUABp AGMAdAB1AHIAZQBzAFwAVQBEAE4AUwBfAGMAbAByAF8AcwBtAC4AagBwAGcAAAAAABDwCAAAAMAM UBDQFAQPDwAE8EgAAAASAArwCAAAAAEgAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCU Ad69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAN3d3QBmAGYAAAAAAGYAZgD/mQAA AP//AP8AAACWlpYADwDuA94CAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAAAA8ADASO AgAADwAC8IYCAACgAAjwCAAAAAQAAAAEBAAADwAD8B4CAAAPAATwKAAAAAEACfAQAAAAAAAAAAAA AAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwcgAAABIACvAIAAAAAgQAACACAABTAAvwHgAA AH8AAAAEAIAA6JXgBr8BAAABAP8BAAABAAEDAiQAAAAAEPAIAAAAgAGwAdAU8AMPABHwEAAAAAAA wwsIAAAAAAAAAA0A4AYPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCIAAAAEgAK8AgAAAADBAAAIAIA AFMAC/AeAAAAfwAAAAQAgADYnOAGvwEAAAEA/wEAAAEAAQMDJAAAAAAQ8AgAAADwA7AB0BQwDA8A EfAQAAAAAADDCwgAAAABAAAADgDgBg8ADfAiAAAAAACeDwQAAAABAAAAAACmDw4AAAD4AAAAgAFw AmADUARwBQ8ABPDcAAAAsgQK8AgAAAAEBAAAAAoAAEMAC/C0AAAAfwCAAIAABEEBAAAABcGcAAAA BgEBAAAAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBc AEIAYQByAHIAIABIAGkAYgBiAHMAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAE0AeQAgAFAA aQBjAHQAdQByAGUAcwBcAFUARABOAFMAXwBjAGwAcgBfAHMAbQAuAGoAcABnAAAAAAAQ8AgAAADA DFAQ0BQEDw8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sA lAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADd3d0AZgBmAAAAAABmAGYA/5kA AAD//wD/AAAAlpaWAA8A7gPeAgAAAgDvAxgAAAABAAAADQ4AAAAAAAABAACAAAAAAAcAAAAPAAwE jgIAAA8AAvCGAgAAsAAI8AgAAAAEAAAABCgAAA8AA/AeAgAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAAAoAAAFAAAADwAE8HIAAAASAArwCAAAAAIoAAAgAgAAUwAL8B4A AAB/AAAABACAAHRB4Aa/AQAAAQD/AQAAAQABAwIkAAAAABDwCAAAAIABsAHQFPADDwAR8BAAAAAA AMMLCAAAAAAAAAANAOAGDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwiAAAABIACvAIAAAAAygAACAC AABTAAvwHgAAAH8AAAAEAIAACBDdBb8BAAABAP8BAAABAAEDAyQAAAAAEPAIAAAA8AOwAdAUGAwP ABHwEAAAAAAAwwsIAAAAAQAAAA4A3QUPAA3wIgAAAAAAng8EAAAAAQAAAAAApg8OAAAA+AAAAIAB cAJgA1AEcAUPAATw3AAAALIECvAIAAAABCgAAAAKAABDAAvwtAAAAH8AgACAAARBAQAAAAXBnAAA AAYBAQAAAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMA XABCAGEAcgByACAASABpAGIAYgBzAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABNAHkAIABQ AGkAYwB0AHUAcgBlAHMAXABVAEQATgBTAF8AYwBsAHIAXwBzAG0ALgBqAHAAZwAAAAAAEPAIAAAA wAxQENAUBA8PAATwSAAAABIACvAIAAAAASgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+L AJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA3d3dAGYAZgAAAAAAZgBmAP+Z AAAA//8A/wAAAJaWlgAPAO4D3gIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAQAAgAAAAAAHAAAADwAM BI4CAAAPAALwhgIAAOAACPAIAAAABAAAAAQ0AAAPAAPwHgIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAANAAABQAAAA8ABPByAAAAEgAK8AgAAAACNAAAIAIAAFMAC/Ae AAAAfwAAAAQAgACoQOAGvwEAAAEA/wEAAAEAAQMCJAAAAAAQ8AgAAACAAbAB0BTwAw8AEfAQAAAA AADDCwgAAAAAAAAADQDgBg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8IgAAAASAArwCAAAAAM0AAAg AgAAUwAL8B4AAAB/AAAABACAAFgZ3QW/AQAAAQD/AQAAAQABAwMkAAAAABDwCAAAACAEsAHQFDAM DwAR8BAAAAAAAMMLCAAAAAEAAAAOAN0FDwAN8CIAAAAAAJ4PBAAAAAEAAAAAAKYPDgAAAPgAAACA AXACYANQBHAFDwAE8NwAAACyBArwCAAAAAQ0AAAACgAAQwAL8LQAAAB/AIAAgAAEQQEAAAAFwZwA AAAGAQEAAABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBz AFwAQgBhAHIAcgAgAEgAaQBiAGIAcwBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwATQB5ACAA UABpAGMAdAB1AHIAZQBzAFwAVQBEAE4AUwBfAGMAbAByAF8AcwBtAC4AagBwAGcAAAAAABDwCAAA AMAMUBDQFAQPDwAE8EgAAAASAArwCAAAAAE0AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAN3d3QBmAGYAAAAAAGYAZgD/ mQAAAP//AP8AAACWlpYAAAByFxwAAAABABAA8GcAAAYAQABCdwAAKHoAAA59AAD0fwAAAAD1DxwA AAAAAQAA7Q4AA8xnAADaggAAAQAAAAoAAAABAPIFDwDoA0wPAAABAOkDKAAAAIAWAADgEAAA4BAA AIAWAAAFAAAACgAAAAQAAAAAAAAAAQAAAAAAAAEPAPIDFgEAAC8AyA8MAAAAMADSDwQAAAABAAAA DwDVB0wAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAAGFaWBXzaEgBk 2hIA7KAHMAgAAAAAAAAAfNoSAFdvDTAAFAYSAACkDwoAAACEAGAABAD/////AAClDwwAAAAAAAAI LgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAA AAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEAC QAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBBABAAAPAADwCAEAAAAABvCIAAAABTwA ABAAAAAlAAAACAAAAAoAAAAFAAAAAgAAAAUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA BwAAAAcAAAAIAAAACAAAAAUAAAAJAAAABwAAAAsAAAAFAAAAAAAAAAQAAAAAAAAABAAAAA4AAAAF AAAAAAAAAAQAAAAQAAAABQAAAB8AAfAsAAAAUgAH8CQAAAAFBb77Qo+6NeV73Q6x9uOegUL/APQ9 AAAGAAAAAAAAAAAAyQBjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAA CEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAAFAAAAAAAAAAAAAAABAACA AAAAAA8A0AevAgAAHwAUBBwAAAAAABUEFAAAALoddewAypo7bU7NyQDKmjsBAQABDwD6A2cAAAAA AP4DAwAAAAEBAAAA/QM0AAAAKAAAAGQAAAAoAAAAZAAAAOygBzAIAAAAAAAAAHDaEgAAAAAAAAAA AKb///+M/v//AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwD/AxQAAAACAAAE DAAAAAAAAAAAAAAAAgAAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAnNoSAC6BDTAs 3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAARIAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQA AACc2hIALoENMCzeEgABAAAAAAAAAAAAAAAAAAAAAAAAAAABEgAPAIgTcAEAAA8AihNoAQAAAAC6 Dw4AAABfAF8AXwBQAFAAVAA5AAAAixNKAQAADwCuD0IBAAAQAK8PCAAAAAABAAABAAAAAACsDyAA AAAAAAAAAAAAAAAAAAAAAIAD//8BAAMAAQAAAAAAAAAAABAArw8IAAAAAQEAAAEAAAAAAKwPKgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMBAAMAAQAAAAAAAAAAABAArw8IAAAAAgEAAAEA AAAAAKwPIAAAAAAAAAAAAAAAAAAAAAAAgAP//wEAAwABAAAAAAAAAAAAEACvDwgAAAADAQAAAQAA AAAArA80AAAAAAAAAAAAAAAAAAAAAACAA///AQADAAEAAAAAAAAAAAAAAIAD//8AAAMAAQAAAAAA AAAAABAArw8IAAAABAEAAAEAAAAAAKwPLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAP/ /wEAAwABAAAAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAACwBPANkPDAAAAAAA2g8EAAAAAAA9AA8A 8A/TCQAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAAAAAAoA8kAAAATgBl AHcAIABEAE4AUwAgAFMAZQByAHYAZQByACAATQBJAEIAAAChDxYAAAATAAAAAAAACAAAAAATAAAA BAAAAAQAEACfDwQAAAABAAAAAACgD/wBAABHAGUAbgBlAHIAYQBsACAARABlAHMAaQBnAG4AIABD AG8AbgBzAHQAcgBhAGkAbgB0AHMAOgANAEIAZQAgAGkAbgBkAGUAcABlAG4AZABlAG4AdAAgAG8A ZgAgAHMAZQByAHYAZQByACAAaQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuAHMALgANAFUAdABp AGwAaQB6AGUAIABTAE4ATQBQAHYAMwAgAGYAbwByACAAYQBjAGMAZQBzAHMAIABjAG8AbgB0AHIA bwBsAC4ADQBEAG8AbgAZIHQAIAByAGUAaQBuAHYAZQBuAHQAIABzAGUAcgB2AGUAcgAgAGMAbwBu AGYAaQBnAHUAcgBhAHQAaQBvAG4ALAAgAGMAbwBtAG0AYQBuAGQAIABhAG4AZAAgAGMAbwBuAHQA cgBvAGwAIABtAGUAYwBoAGEAbgBpAHMAbQBzAC4ADQBEAG8AbgAZIHQAIAByAGUAaQBuAHYAZQBu AHQAIABzAGUAcgB2AGUAcgAgAGEAdQB0AGgAbwByAGkAegBhAHQAaQBvAG4ALAAgAGEAdQB0AGgA ZQBuAHQAaQBjAGEAdABpAG8AbgAsACAAYQBuAGQAIABhAGMAYwBvAHUAbgB0AGkAbgBnACAAbQBl AGMAaABhAG4AaQBzAG0AcwAuAA0AAAChDzwAAAAcAAAAAAAAAAAA4gAAAAEAkgAAAAEAEyAAAAEA AAABAJMAAAAAABMgAAAcAAAAAAAAAOMAAAAABAAAAAQAAKoPEgAAAP4AAAAAAAAAAQAAAAEAAAAA AAAA8wMUAAAABgAAAAQAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAEEgTmV3IERO UyBTZXJ2ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAVAAAABAAAAAQAEACfDwQAAAABAAAAAACo D5gAAABQcmluY2lwYWwgU2VjdGlvbnM6DU1BWC1BQ0VTUyByZWFkLW9ubHkgb3IgYWNjZXNzaWJs ZS1mb3Itbm90aWZ5DVNlcnZlciBJZGVudGlmaWNhdGlvbiBHcm91cC4NQ291bnRlcnMgYW5kIFN0 YXRpc3RpY3MgR3JvdXAuDVNlcnZlciBDb25maWd1cmF0aW9uIEdyb3VwLgAAoQ9MAAAAFAAAAAAA IAAAAAAAAAEtAAAAAQAgAAAAAAAAAVgAAAABALIAAAABABMgAAAAAAABFAAAAAAAAAAtAAAAAAQA AAAEWAAAAAAIAAAACAAA8wMUAAAABwAAAAQAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP FAAAAEEgTmV3IEROUyBTZXJ2ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAVAAAABAAAAAQAEACf DwQAAAABAAAAAACoD6YAAABTZXJ2ZXIgSWRlbnRpZmljYXRpb24gR3JvdXA6DVNvZnR3YXJlIFZl cnNpb25pbmcgSW5mb3JtYXRpb24uDVNlcnZlciBTdGFydCBEYXRlIGFuZCBUaW1lLg1TZXJ2ZXIg TmV0d29yayBJbmZvcm1hdGlvbi4NT3RoZXIgSWRlbnRpZmljYXRpb24gSW5mb3JtYXRpb24gYXMg YXBwcm9wcmlhdGUuAAChDywAAAAdAAAAAAAAAAAAigAAAAEAkgAAAAEAEyAAAB0AAAAAAAAAigAA AAAEAAAABAAAqg8SAAAApgAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAIAAAABAAAAAIAAAADAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAAQSBOZXcgRE5TIFNlcnZlciBNSUIAAKEPFgAAABUAAAAA AAAIAAAAABUAAAAEAAAABAAQAJ8PBAAAAAEAAAAAAKgPfQAAAENvdW50ZXJzIGFuZCBTdGF0aXN0 aWNzIEdyb3VwOg1UcmFmZmljIEVuZ2luZWVyaW5nLg1TeXN0ZW0gVHVuaW5nLg1ab25lIFVzYWdl Lg1PdGhlciBDb3VudGVycyBhbmQgU3RhdGlzdGljcyBhcyBhcHByb3ByaWF0ZS4NAAChD0YAAAAf AAAAAAAAAAAAXgAAAAEAkgAAAAEAEyAAAAEAAAACAJMAAAAAABMgAAAfAAAAAAAAAF4AAAAABAAA AAQBAAAAAAgAAAAIAADzAxQAAAAJAAAABAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8U AAAAQSBOZXcgRE5TIFNlcnZlciBNSUIAAKEPFgAAABUAAAAAAAAIAAAAABUAAAAEAAAABAAQAJ8P BAAAAAEAAAAAAKgP5AAAAFNlcnZlciBDb25maWd1cmF0aW9uIEdyb3VwOg1Gb3Igc2VydmVyIG9w ZXJhdGluZyBwYXJhbWV0ZXJzLCBOT1Qgem9uZSBmaWxlcywgYW5kIHRvIGFuc3dlciBzdWNoIHF1 ZXN0aW9ucyBhczoNRm9yIHdoaWNoIHpvbmVzIGFtIEkgYXV0aG9yaXRhdGl2ZT8NV2hvIGlzIGF1 dGhvcml6ZWQgdG8gdXBkYXRlIGEgem9uZSBmaWxlPw1XaGF0IGlzIHRoZSBoaXN0b3J5IG9mIHpv bmUgZmlsZSB1cGRhdGVzPwAAoQ9EAAAAHAAAAAAAIAAAAAAAAAFSAAAAAQAAAAAAdwAAAAEAkgAA AAEAEyAAABwAAAAAAAAAUgAAAAAEAAAABHcAAAAACAAAAAgAAPMDFAAAAAoAAAAEAAAAAgAAAAUB AAAAAAAAAACfDwQAAAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1JQgAAoQ8WAAAAFQAA AAAAAAgAAAAAFQAAAAQAAAAEABAAnw8EAAAAAQAAAAAAqA/KAAAARXh0ZW5zaW9ucyBwcm9wb3Nl ZCB0byBoYW5kbGUgU0VUIGZvciBjb21tYW5kIGFuZCBjb250cm9sIG9mIEROUyBzZXJ2ZXJzLg1T aW1wbGUgTUlCIHN0cnVjdHVyZSBpbnRlbmRlZCB0byBtaW5pbWl6ZSBzZXJ2ZXIgcHJvY2Vzc2lu ZyByZXF1aXJlbWVudHMuDVNvbGljaXRpbmcgY29tbWVudHMgb24gZGF0YSB0byByZXBvcnQgdGhy b3VnaCB0aGUgTUlCLgAA6gMAAAAADwDuA94CAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAA BwAAAA8ADASOAgAADwAC8IYCAAAgAAjwCAAAAAQAAAAECAAADwAD8B4CAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgAAAUAAAAPAATwcgAAABIACvAIAAAAAggAACAC AABTAAvwHgAAAH8AAAAEAIAAPKWWBb8BAAABAP8BAAABAAEDAiQAAAAAEPAIAAAAgAGwAdAUwAMP ABHwEAAAAAAAwwsIAAAAAAAAAA0AlgUPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCIAAAAEgAK8AgA AAADCAAAIAIAAFMAC/AeAAAAfwAAAAQAgADkpZYFvwEAAAEA/wEAAAEAAQMDJAAAAAAQ8AgAAADA A7AB0BRgDA8AEfAQAAAAAADDCwgAAAABAAAADgCWBQ8ADfAiAAAAAACeDwQAAAABAAAAAACmDw4A AAD4AAAAgAFwAmADUARwBQ8ABPDcAAAAsgQK8AgAAAAECAAAAAoAAEMAC/C0AAAAfwCAAIAABEEB AAAABcGcAAAABgEBAAAAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQA aQBuAGcAcwBcAEIAYQByAHIAIABIAGkAYgBiAHMAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBc AE0AeQAgAFAAaQBjAHQAdQByAGUAcwBcAFUARABOAFMAXwBjAGwAcgBfAHMAbQAuAGoAcABnAAAA AAAQ8AgAAADADFAQ0BQEDw8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAADd3d0AZgBmAAAA AABmAGYA/5kAAAD//wD/AAAAlpaWAAAAchcQAAAAAQAQACKDAAADABAAdpIAAAAA9Q8cAAAABQEA AO0OAAP+ggAAXJUAAAEAAAAKAAAAAQDyBQ8A6APLDgAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAA BQAAAAoAAAAEAAAAAAAAAAEAAAAAAAABDwDyAxYBAAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QdM AAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAABgdawR82hIAZNoSAOyg BzAIAAAAAAAAAHzaEgBXbw0wAAAEAAAApA8KAAAAhABgAAQA/////wAApQ8MAAAAAAAACC4AAAAH AAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAA AABAAgAAAAAHAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQQAQAADwAA8AgBAAAAAAbwiAAAAAJAAAAQAAAA JQAAAAgAAAAFAAAABQAAAAMAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAI AAAACAAAAAQAAAAFAAAAAQAAAAcAAAAGAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAHAAAABQAAAAAA AAAEAAAAAgAAAAUAAAAfAAHwLAAAAFIAB/AkAAAABQW++0KPujXle90OsfbjnoFC/wD0PQAABgAA AAAAAAAAAMkAYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7x EAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAABQAAAAAAAAAAAAAAAQAAgAAAAAAP ANAHjQIAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaO21OzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMA AAABAQAAAP0DNAAAADAAAABkAAAAMAAAAGQAAADsoAcwCAAAAAAAAABw2hIAAAAAAAAAAACm//// lP///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAA AAAAAAAAAAIAAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAJzaEgAugQ0wLN4SAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAnNoS AC6BDTAs3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAARIADwCIE04BAAAPAIoTRgEAAAAAug8OAAAA XwBfAF8AUABQAFQAOQAAAIsTKAEAAA8Arg8gAQAAEACvDwgAAAAAAQAAAQAAAAAArA8cAAAAAAAA AAAAAAAAAAAAAACAAv//AQAAAAAAAAAAABAArw8IAAAAAQEAAAEAAAAAAKwPHAAAAAAAAAAAAAAA AAAAAAAAgAL//wEAAAAAAAAAAAAQAK8PCAAAAAIBAAABAAAAAACsDxwAAAAAAAAAAAAAAAAAAAAA AIAC//8BAAAAAAAAAAAAEACvDwgAAAADAQAAAQAAAAAArA8sAAAAAAAAAAAAAAAAAAAAAACAAv// AQAAAAAAAAAAAAAAgAL//wAAAAAAAAAAAAAQAK8PCAAAAAQBAAABAAAAAACsDygAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIAC//8BAAAAAAAAAAAAPwDZDwwAAAAAANoPBAAAAAAACwBPANkP DAAAAAAA2g8EAAAAAAA9AA8A8A90CQAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8SAAAATmV3IEROUyBTZXJ2ZXIgTUlCAAChDxYAAAATAAAAAAAACAAAAAATAAAA BAAAAAQAEACfDwQAAAABAAAAAACgD/wBAABHAGUAbgBlAHIAYQBsACAARABlAHMAaQBnAG4AIABD AG8AbgBzAHQAcgBhAGkAbgB0AHMAOgANAEIAZQAgAGkAbgBkAGUAcABlAG4AZABlAG4AdAAgAG8A ZgAgAHMAZQByAHYAZQByACAAaQBtAHAAbABlAG0AZQBuAHQAYQB0AGkAbwBuAHMALgANAFUAdABp AGwAaQB6AGUAIABTAE4ATQBQAHYAMwAgAGYAbwByACAAYQBjAGMAZQBzAHMAIABjAG8AbgB0AHIA bwBsAC4ADQBEAG8AbgAZIHQAIAByAGUAaQBuAHYAZQBuAHQAIABzAGUAcgB2AGUAcgAgAGMAbwBu AGYAaQBnAHUAcgBhAHQAaQBvAG4ALAAgAGMAbwBtAG0AYQBuAGQAIABhAG4AZAAgAGMAbwBuAHQA cgBvAGwAIABtAGUAYwBoAGEAbgBpAHMAbQBzAC4ADQBEAG8AbgAZIHQAIAByAGUAaQBuAHYAZQBu AHQAIABzAGUAcgB2AGUAcgAgAGEAdQB0AGgAbwByAGkAegBhAHQAaQBvAG4ALAAgAGEAdQB0AGgA ZQBuAHQAaQBjAGEAdABpAG8AbgAsACAAYQBuAGQAIABhAGMAYwBvAHUAbgB0AGkAbgBnACAAbQBl AGMAaABhAG4AaQBzAG0AcwAuAA0AAAChDzwAAAAcAAAAAAAAAAAA4gAAAAEAkgAAAAEAEyAAAAEA AAABAJMAAAAAABMgAAAcAAAAAAAAAOMAAAAABAAAAAQAAKoPEgAAAP4AAAAAAAAAAQAAAAEAAAAA AAAA8wMUAAAABgAAAAQAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAEEgTmV3IERO UyBTZXJ2ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAVAAAABAAAAAQAEACfDwQAAAABAAAAAACo D2sAAABQcmluY2lwYWwgU2VjdGlvbnM6DVNlcnZlciBJZGVudGlmaWNhdGlvbiBHcm91cC4NQ291 bnRlcnMgYW5kIFN0YXRpc3RpY3MgR3JvdXAuDVNlcnZlciBDb25maWd1cmF0aW9uIEdyb3VwLgAA oQ80AAAAFAAAAAAAIAAAAAAAAAFYAAAAAQCyAAAAAQATIAAAAAAAARQAAAAAAAAAWAAAAAAEAAAA BAAA8wMUAAAABwAAAAQAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAEEgTmV3IERO UyBTZXJ2ZXIgTUlCAAChDxYAAAAVAAAAAAAACAAAAAAVAAAABAAAAAQAEACfDwQAAAABAAAAAACo D6YAAABTZXJ2ZXIgSWRlbnRpZmljYXRpb24gR3JvdXA6DVNvZnR3YXJlIFZlcnNpb25pbmcgSW5m b3JtYXRpb24uDVNlcnZlciBTdGFydCBEYXRlIGFuZCBUaW1lLg1TZXJ2ZXIgTmV0d29yayBJbmZv cm1hdGlvbi4NT3RoZXIgSWRlbnRpZmljYXRpb24gSW5mb3JtYXRpb24gYXMgYXBwcm9wcmlhdGUu AAChDywAAAAdAAAAAAAAAAAAigAAAAEAkgAAAAEAEyAAAB0AAAAAAAAAigAAAAAEAAAABAAAqg8S AAAApgAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAIAAAABAAAAAIAAAADAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8UAAAAQSBOZXcgRE5TIFNlcnZlciBNSUIAAKEPFgAAABUAAAAAAAAIAAAAABUAAAAE AAAABAAQAJ8PBAAAAAEAAAAAAKgPfQAAAENvdW50ZXJzIGFuZCBTdGF0aXN0aWNzIEdyb3VwOg1U cmFmZmljIEVuZ2luZWVyaW5nLg1TeXN0ZW0gVHVuaW5nLg1ab25lIFVzYWdlLg1PdGhlciBDb3Vu dGVycyBhbmQgU3RhdGlzdGljcyBhcyBhcHByb3ByaWF0ZS4NAAChD0YAAAAfAAAAAAAAAAAAXgAA AAEAkgAAAAEAEyAAAAEAAAACAJMAAAAAABMgAAAfAAAAAAAAAF4AAAAABAAAAAQBAAAAAAgAAAAI AADzAxQAAAAJAAAABAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8UAAAAQSBOZXcgRE5T IFNlcnZlciBNSUIAAKEPFgAAABUAAAAAAAAIAAAAABUAAAAEAAAABAAQAJ8PBAAAAAEAAAAAAKgP 5AAAAFNlcnZlciBDb25maWd1cmF0aW9uIEdyb3VwOg1Gb3Igc2VydmVyIG9wZXJhdGluZyBwYXJh bWV0ZXJzLCBOT1Qgem9uZSBmaWxlcywgYW5kIHRvIGFuc3dlciBzdWNoIHF1ZXN0aW9ucyBhczoN Rm9yIHdoaWNoIHpvbmVzIGFtIEkgYXV0aG9yaXRhdGl2ZT8NV2hvIGlzIGF1dGhvcml6ZWQgdG8g dXBkYXRlIGEgem9uZSBmaWxlPw1XaGF0IGlzIHRoZSBoaXN0b3J5IG9mIHpvbmUgZmlsZSB1cGRh dGVzPwAAoQ9EAAAAHAAAAAAAIAAAAAAAAAFSAAAAAQAAAAAAdwAAAAEAkgAAAAEAEyAAABwAAAAA AAAAUgAAAAAEAAAABHcAAAAACAAAAAgAAPMDFAAAAAoAAAAEAAAAAgAAAAUBAAAAAAAAAACfDwQA AAAAAAAAAACoDxQAAABBIE5ldyBETlMgU2VydmVyIE1JQgAAoQ8WAAAAFQAAAAAAAAgAAAAAFQAA AAQAAAAEABAAnw8EAAAAAQAAAAAAqA/CAAAARXh0ZW5zaW9ucyBwcm9wb3NlZCB0byBoYW5kbGUg Y29tbWFuZCBhbmQgY29udHJvbCBvZiBETlMgc2VydmVycy4NU2ltcGxlIE1JQiBzdHJ1Y3R1cmUg aW50ZW5kZWQgdG8gbWluaW1pemUgc2VydmVyIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRzLg1Tb2xp Y2l0aW5nIGNvbW1lbnRzIG9uIGRhdGEgdG8gcmVwb3J0IHRocm91Z2ggdGhlIE1JQi4AAOoDAAAA AA8A7gPeAgAAAgDvAxgAAAABAAAADQ4AAAAAAAABAACAAAAAAAcAAAAPAAwEjgIAAA8AAvCGAgAA QAAI8AgAAAAEAAAABCAAAA8AA/AeAgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAgAAAFAAAADwAE8HIAAAASAArwCAAAAAIgAAAgAgAAUwAL8B4AAAB/AAAABACAABTb pwO/AQAAAQD/AQAAAQABAwIkAAAAABDwCAAAAIABsAHQFMADDwAR8BAAAAAAAMMLCAAAAAAAAAAN AKcDDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwiAAAABIACvAIAAAAAyAAACACAABTAAvwHgAAAH8A AAAEAIAAjLinA78BAAABAP8BAAABAAEDAyQAAAAAEPAIAAAAwAOwAdAUMAwPABHwEAAAAAAAwwsI AAAAAQAAAA4ApwMPAA3wIgAAAAAAng8EAAAAAQAAAAAApg8OAAAA+AAAAIABcAJgA1AEcAUPAATw 3AAAALIECvAIAAAABCAAAAAKAABDAAvwtAAAAH8AgACAAARBAQAAAAXBnAAAAAYBAQAAAEMAOgBc AEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABCAGEAcgByACAA SABpAGIAYgBzAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABNAHkAIABQAGkAYwB0AHUAcgBl AHMAXABVAEQATgBTAF8AYwBsAHIAXwBzAG0ALgBqAHAAZwAAAAAAEPAIAAAAwAxQENAUBA8PAATw SAAAABIACvAIAAAAASAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA3d3dAGYAZgAAAAAAZgBmAP+ZAAAA//8A/wAAAJaW lgAPAO4DyAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAQAAgAAAAAAHAAAADwAMBHgCAAAPAALwcAIA ACAACPAIAAAABAAAAAQ8AAAPAAPwCAIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAAPAAABQAAAA8ABPByAAAAEgAK8AgAAAACPAAAIAIAAFMAC/AeAAAAfwAAAAQAgAAU DmsEvwEAAAEA/wEAAAEAAQMCJAAAAAAQ8AgAAACAAbAB0BTwAw8AEfAQAAAAAADDCwgAAAAAAAAA DQBrBA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAM8AAAgAgAAUwAL8B4AAAB/ AAAABACAAPAYawS/AQAAAQD/AQAAAQABAwMkAAAAABDwCAAAACAEsAHQFDAMDwAR8BAAAAAAAMML CAAAAAEAAAAOAGsEDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATw3AAAALIECvAIAAAABDwAAAAKAABD AAvwtAAAAH8AgACAAARBAQAAAAXBnAAAAAYBAQAAAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAA YQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABCAGEAcgByACAASABpAGIAYgBzAFwATQB5ACAARABv AGMAdQBtAGUAbgB0AHMAXABNAHkAIABQAGkAYwB0AHUAcgBlAHMAXABVAEQATgBTAF8AYwBsAHIA XwBzAG0ALgBqAHAAZwAAAAAAEPAIAAAAwAxQENAUBA8PAATwSAAAABIACvAIAAAAATwAAAAMAACD AAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA 8AcgAAAA3d3dAGYAZgAAAAAAZgBmAP+ZAAAA//8A/wAAAJaWlgAAAHIXGAAAAAEAEACYlQAABgAQ AGukAAAKABAAUacAAAAA9Q8cAAAABQEAAO0OAAN0lQAAIaoAAAEAAAAKAAAAAQB0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA== ------=_NextPart_000_0000_01C06443.58FA77D0-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Dec 12 20:20:46 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24395 for ; Tue, 12 Dec 2000 20:20:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1460Fp-000CBG-00 for namedroppers-data@psg.com; Tue, 12 Dec 2000 16:58:45 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1460Fo-000CAD-00 for namedroppers@ops.ietf.org; Tue, 12 Dec 2000 16:58:44 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1460Fp-0003xc-00 for namedroppers@ops.ietf.org; Tue, 12 Dec 2000 16:58:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Dec 2000 16:05:31 -0800 (PST) Message-Id: <200012130005.QAA03208@gulag.araneus.fi> To: namedroppers@ops.ietf.org CC: Olafur Gudmundsson Subject: Re: DNSEXT WG Last Call: EDNS0.5 In-Reply-To: <4.3.2.7.2.20001129113521.0338f460@localhost> References: <4.3.2.7.2.20001129113521.0338f460@localhost> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt > > This draft is on standards track, if you disagree with that please state why > in your response. I object to advancing the draft. I do not think there is a genuine need for this kind of feature indication mechanism, for a number of reasons: First of all, it seems to be the consensus of the DNSEXT working group that the number of new DNS protocol features should be kept to an absolute minimum. Even if new features are introduced, it is not clear that a significant number of them will benefit from a mechanism to explicitly "determine which extension features the other party understands". Determining the feature set of a server before using it requires an additional round-trip, which causes considerable additional delays in a protocol like the DNS which involves many simple transactions with a large number of distinct servers. Therefore, new extensions should be designed to avoid such feature negotiation if at all possible. For those cases where an explicit indication of support for a new features is useful, there are existing mechanisms that can do the job without introducing additional complexity in the form of mandatory support for the FEATURE option. The support for a feature can be indicated by sending a feature-specific OPT RR, which may have an empty data field if no information other than the mere presence of the feature needs to be transmitted; with two or fewer features, this takes no more space than using the FEATURE option. Alternatively, each feature may be allocated a flag from the 16-bit "Z" field of the OPT RR header. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Dec 12 23:24:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29057 for ; Tue, 12 Dec 2000 23:24:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14632E-000KNh-00 for namedroppers-data@psg.com; Tue, 12 Dec 2000 19:56:54 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14632D-000KNb-00 for namedroppers@ops.ietf.org; Tue, 12 Dec 2000 19:56:53 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1461Hy-00048Q-00 for namedroppers@ops.ietf.org; Tue, 12 Dec 2000 18:05:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200012130140.RAA84836@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: EDNS0.5 In-reply-to: Your message of "Tue, 12 Dec 2000 16:05:31 PST." <200012130005.QAA03208@gulag.araneus.fi> Date: Tue, 12 Dec 2000 17:40:39 -0800 From: Paul A Vixie X-DCC-MAPS-Metrics: isrv3.isc.org 666; IP=0/272 env_From=0/328 From=0/331 Subject=0/8 Message-ID=0/1 Received=0/1 Body=0/1 Fuz1=0/1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt > > > > This draft is on standards track, if you disagree with that please state > > why in your response. > > I object to advancing the draft. I do not think there is a genuine > need for this kind of feature indication mechanism, for a number of > reasons: i tend to agree with andreas's reasoning here. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 13 13:19:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24785 for ; Wed, 13 Dec 2000 13:19:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146Fm8-0005vj-00 for namedroppers-data@psg.com; Wed, 13 Dec 2000 09:33:08 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146Fm6-0005vb-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 09:33:06 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146FmG-0005A9-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 09:33:16 -0800 Message-Id: <4.3.2.7.2.20001213091037.0270bf08@127.0.0.1> Date: Wed, 13 Dec 2000 09:22:46 -0800 To: gson@nominum.com (Andreas Gustafsson), namedroppers@ops.ietf.org From: Harald Alvestrand Subject: Re: DNSEXT WG Last Call: EDNS0.5 Cc: Olafur Gudmundsson In-Reply-To: <200012130005.QAA03208@gulag.araneus.fi> References: <4.3.2.7.2.20001129113521.0338f460@localhost> <4.3.2.7.2.20001129113521.0338f460@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:05 12/12/2000 -0800, Andreas Gustafsson wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt > > > > This draft is on standards track, if you disagree with that please > state why > > in your response. > >I object to advancing the draft. I do not think there is a genuine >need for this kind of feature indication mechanism, for a number of >reasons: I (obviously) disagree. >First of all, it seems to be the consensus of the DNSEXT working group >that the number of new DNS protocol features should be kept to an >absolute minimum. No argument from me here. >Even if new features are introduced, it is not clear that a significant >number of them will benefit from a mechanism to explicitly "determine >which extension features the other party understands". Determining >the feature set of a server before using it requires an additional >round-trip, which causes considerable additional delays in a protocol >like the DNS which involves many simple transactions with a large >number of distinct servers. My reply: We introduced this mechanism when we introduced EDNS. The problem with EDNS was that its mechanism is very coarse grained, so that we cannot do (for instance) negotiated tests with the next Binary Label-type extension without going through the heavyweight procedure of assigning a new EDNS number. The draft is not about introducing feature negotiation - we already did that. The draft is about refining the mechanism so that we can get testing and pre-new-version deployment done without it hurting too much. BTW, the draft does not require an extra round trip for the case where the option is supported, any more than EDNS0 does. > Therefore, new extensions should be >designed to avoid such feature negotiation if at all possible. > >For those cases where an explicit indication of support for a new >features is useful, there are existing mechanisms that can do the job >without introducing additional complexity in the form of mandatory >support for the FEATURE option. The support for a feature can be >indicated by sending a feature-specific OPT RR, which may have an >empty data field if no information other than the mere presence of the >feature needs to be transmitted; with two or fewer features, this >takes no more space than using the FEATURE option. Alternatively, >each feature may be allocated a flag from the 16-bit "Z" field of the >OPT RR header. This point is worth thinking about. I think that having one mechanism that everyone knows about is better than defining one mechanism per extension, and that the administrative procedure of collapsing a set of features into a version number gives us a chance to get our packet space back once the experimentation phase is over. But OTOH, the FEATURE mechanism is not useful for signalling per-call request differences; extensions might need their own OPTions too, in which case we do waste space. Other thoughts? -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 13 15:52:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20369 for ; Wed, 13 Dec 2000 15:52:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146IZ4-000CMW-00 for namedroppers-data@psg.com; Wed, 13 Dec 2000 12:31:50 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146IZ3-000CMP-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 12:31:49 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146IZE-0005RQ-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 12:32:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Harald Alvestrand Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: EDNS0.5 References: <4.3.2.7.2.20001129113521.0338f460@localhost> <4.3.2.7.2.20001213091037.0270bf08@127.0.0.1> Message-Id: Date: Wed, 13 Dec 2000 12:22:08 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The draft is not about introducing feature negotiation - we already did > that. The draft is about refining the mechanism so that we can get testing > and pre-new-version deployment done without it hurting too much. so, we already have the camel's nose. it won't open a much wider hole to let the head and neck in. and it will allow significantly more bactrian benefits. i am tempted. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 13 16:01:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21389 for ; Wed, 13 Dec 2000 16:01:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146IY3-000CLl-00 for namedroppers-data@psg.com; Wed, 13 Dec 2000 12:30:47 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146IY2-000CLc-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 12:30:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146IYA-0005Qe-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 12:30:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A37D695.AB9EAA7D@daimlerchrysler.com> Date: Wed, 13 Dec 2000 15:05:41 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: EDNS0.5 References: <4.3.2.7.2.20001129113521.0338f460@localhost> <4.3.2.7.2.20001129113521.0338f460@localhost> <4.3.2.7.2.20001213091037.0270bf08@127.0.0.1> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If I may make a suggestion: The EDNS0.5 draft appears to me to logically encompass 2 inter-related proposals: 1) A "Feature Code" Proposal: a proposal to implement FEATURE codes, which are similar in function and context to OPTION codes, but, unlike OPTION codes, which may be purely discretionary between particular clients or servers, or only for certain transactions, are "standards track", boolean elements of protocol behavior, expected to eventually -- assuming they prove themselves worthy -- be absorbed into protocol VERSIONs. 2) An "Aggregator" Proposal: a proposal to implement an OPTION which aggregates 2 or more 2-octet values, representing boolean "switches" of some sort, in a sorted list in its data area. This is primarily a space-conservation measure (since a standalone data-less OPTION occupies 4 octets), although as a secondary benefit, this aggregator might make composition and parsing of multiple booleans slightly more efficient. Obviously, these proposals have considerable synergy, given that FEATUREs, if implemented widely, could consume significant amounts of packet space if -- _sans_ some sort of aggregation mechanism -- they had to be presented as separate data-less OPTIONs. But, I think the two parts can be viewed and evaluated independently. The Aggregator Proposal, as I have previously opined, could potentially be used for boolean OPTION codes as well as just FEATURE codes, or mixtures of the two (providing that collisions were avoided somehow). Therefore, I think it has positive value -- as a pure space-conservation measure -- regardless of whether the Feature Code Proposal has positive value or not. Coincidentally, I think the Feature Code Proposal has positive value as well, because I strongly believe that DNS needs to evolve and grow in order to keep pace with the accelerating pace of other Internet protocols. But the acceptance or rejection of one part of the draft doesn't necessarily imply acceptance or rejection of the other part. Perhaps the draft should be split? In response to Andreas' specific point about an aggregator with a single FEATURE code wasting more space than a data-less OPTION expressing the same boolean concept, I think this is yet another reason why the ranges for OPTION codes and FEATURE codes should be co-ordinated with each other -- given collision-protection, a solo FEATURE code could, if desired, be presented as a standalone data-less OPTION element, to conserve space. Speaking of space-conservation, I also think that a client or server which implements no FEATURE codes beyond the ones implicit in the VERSION it advertises, should not be obligated to provide an *empty* FEATURE aggregator. The draft as currently written uses mandatory -- or at least non-discretionary -- language and seems to imply that FEATURE aggregators are *always* supplied by clients and servers. But where it conveys no useful information, I think the aggregator should be omitted in the interests of conserving space. Maybe the mandatory/non-discretionary language could be changed/clarified. - Kevin Harald Alvestrand wrote: > At 16:05 12/12/2000 -0800, Andreas Gustafsson wrote: > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt > > > > > > This draft is on standards track, if you disagree with that please > > state why > > > in your response. > > > >I object to advancing the draft. I do not think there is a genuine > >need for this kind of feature indication mechanism, for a number of > >reasons: > > I (obviously) disagree. > > >First of all, it seems to be the consensus of the DNSEXT working group > >that the number of new DNS protocol features should be kept to an > >absolute minimum. > > No argument from me here. > > >Even if new features are introduced, it is not clear that a significant > >number of them will benefit from a mechanism to explicitly "determine > >which extension features the other party understands". Determining > >the feature set of a server before using it requires an additional > >round-trip, which causes considerable additional delays in a protocol > >like the DNS which involves many simple transactions with a large > >number of distinct servers. > > My reply: We introduced this mechanism when we introduced EDNS. > The problem with EDNS was that its mechanism is very coarse grained, so > that we cannot do (for instance) negotiated tests with the next Binary > Label-type extension without going through the heavyweight procedure of > assigning a new EDNS number. > The draft is not about introducing feature negotiation - we already did > that. The draft is about refining the mechanism so that we can get testing > and pre-new-version deployment done without it hurting too much. > > BTW, the draft does not require an extra round trip for the case where the > option is supported, any more than EDNS0 does. > > > Therefore, new extensions should be > >designed to avoid such feature negotiation if at all possible. > > > >For those cases where an explicit indication of support for a new > >features is useful, there are existing mechanisms that can do the job > >without introducing additional complexity in the form of mandatory > >support for the FEATURE option. The support for a feature can be > >indicated by sending a feature-specific OPT RR, which may have an > >empty data field if no information other than the mere presence of the > >feature needs to be transmitted; with two or fewer features, this > >takes no more space than using the FEATURE option. Alternatively, > >each feature may be allocated a flag from the 16-bit "Z" field of the > >OPT RR header. > > This point is worth thinking about. > I think that having one mechanism that everyone knows about is better than > defining one mechanism per extension, and that the administrative procedure > of collapsing a set of features into a version number gives us a chance to > get our packet space back once the experimentation phase is over. > But OTOH, the FEATURE mechanism is not useful for signalling per-call > request differences; extensions might need their own OPTions too, in which > case we do waste space. > > Other thoughts? > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 13 17:22:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01983 for ; Wed, 13 Dec 2000 17:22:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146Jtp-000FRc-00 for namedroppers-data@psg.com; Wed, 13 Dec 2000 13:57:21 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146Jto-000FRV-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 13:57:21 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146Jtn-0000Hk-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 13:57:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Harald Alvestrand Cc: gson@nominum.com (Andreas Gustafsson), namedroppers@ops.ietf.org, Olafur Gudmundsson Subject: Re: DNSEXT WG Last Call: EDNS0.5 In-Reply-To: Your message of "Wed, 13 Dec 2000 09:22:46 -0800." <4.3.2.7.2.20001213091037.0270bf08@127.0.0.1> Date: Thu, 14 Dec 2000 08:43:40 +1100 Message-Id: <17485.976743820@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 13 Dec 2000 09:22:46 -0800 From: Harald Alvestrand Message-ID: <4.3.2.7.2.20001213091037.0270bf08@127.0.0.1> I think I agree with Andreas, this draft made me a little queasy... | The problem with EDNS was that its mechanism is very coarse grained, so | that we cannot do (for instance) negotiated tests with the next Binary | Label-type extension without going through the heavyweight procedure of | assigning a new EDNS number. I think that's a feature (of EDNS0). It makes it very hard to add new stuff, not something that can be easily done. What's more because it adds a difficult mechanism to add new features, it actually makes it more difficult than before EDNS0 when there was no mechanism at all (so something relatively simple could be invented - like "no-one currently sets this bit" - and maybe it would work). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 13 18:03:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08662 for ; Wed, 13 Dec 2000 18:03:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146KRc-000GLC-00 for namedroppers-data@psg.com; Wed, 13 Dec 2000 14:32:16 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146KRc-000GL4-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 14:32:16 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146KRa-0000Lz-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 14:32:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200012132216.OAA89240@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: EDNS0.5 In-reply-to: Your message of "Thu, 14 Dec 2000 08:43:40 +1100." <17485.976743820@mundamutti.cs.mu.OZ.AU> Date: Wed, 13 Dec 2000 14:16:11 -0800 From: Paul A Vixie X-DCC-MAPS-Metrics: isrv3.isc.org 668; IP=0/1142 env_From=0/1366 From=0/1468 Subject=0/58 Message-ID=0/1 Received=0/1 Body=0/1 Fuz1=0/1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | The problem with EDNS was that its mechanism is very coarse grained, so > | that we cannot do (for instance) negotiated tests with the next Binary > | Label-type extension without going through the heavyweight procedure of > | assigning a new EDNS number. > > I think that's a feature (of EDNS0). It makes it very hard to add new > stuff, not something that can be easily done. What's more because it > adds a difficult mechanism to add new features, it actually makes it more > difficult than before EDNS0 when there was no mechanism at all (so > something relatively simple could be invented - like "no-one currently > sets this bit" - and maybe it would work). It's definitely the case that EDNS was designed to allow protocol evolution rather than protocol brownian motion. We should not be standardizing things we're not sure of. The EDNS weakness identified by the 0.5 draft is that because there's a numerical comparison of version numbers, it's somewhat difficult to _experimentally_ deploy new elements. However once they aren't experimental any more, the protocol should not support their withdrawal. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 13 18:17:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11794 for ; Wed, 13 Dec 2000 18:17:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146KkG-000Gte-00 for namedroppers-data@psg.com; Wed, 13 Dec 2000 14:51:32 -0800 Received: from ietf.207.137.72.106.tx.verio.net ([207.137.72.106] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146KkF-000GtW-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 14:51:31 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146KkD-0000PE-00 for namedroppers@ops.ietf.org; Wed, 13 Dec 2000 14:51:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001213144016.0584cf08@127.0.0.1> Date: Wed, 13 Dec 2000 14:40:25 -0800 To: Robert Elz From: Harald Alvestrand Subject: Re: DNSEXT WG Last Call: EDNS0.5 Cc: gson@nominum.com (Andreas Gustafsson), namedroppers@ops.ietf.org, Olafur Gudmundsson In-Reply-To: <17485.976743820@mundamutti.cs.mu.OZ.AU> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 08:43 14/12/2000 +1100, Robert Elz wrote: >I think that's a feature (of EDNS0). It makes it very hard to >add new stuff, not something that can be easily done. What's >more because it adds a difficult mechanism to add new features, >it actually makes it more difficult than before EDNS0 when there was >no mechanism at all (so something relatively simple could be invented >- like "no-one currently sets this bit" - and maybe it would work). People have not stopped doing this. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 14 16:06:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16256 for ; Thu, 14 Dec 2000 16:06:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146dql-000LPK-00 for namedroppers-data@psg.com; Thu, 14 Dec 2000 11:15:31 -0800 Received: from ietf.207.137.73.1.tx.verio.net ([207.137.73.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146dql-000LPE-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 11:15:31 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146dqi-0000pG-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 11:15:29 -0800 Message-ID: <01bc01c065fa$b2c66630$ce4889cf@jamessonyvaio> From: "James Seng/Personal" To: References: <4.3.2.7.2.20001213144016.0584cf08@127.0.0.1> Subject: Large Zone and DNSSEC Date: Fri, 15 Dec 2000 02:21:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I discussed my idea for the large zone problem yesterday with a couple people. The responses I got is "speechless-ness", "gasp for air", and "dont go there, james". I gather I am, once again, onto something ranging from "nuts" to "very bad idea". The industry, whether the engineers like it or not, is moving towards a flatter lever. gTLD has always been flat, and other ccTLD is doing similar stuff. It is not going to be an isolated problem for one registry but all registry is going to be affected in one way or another. HOWEVER, I do not buy into the idea that the world is flat and "I rule, you fix my problem or die" speech, thank you very much. Now, back to the idea, considering the discussion at IDN on introducing the "presentation layer" (or others), we could view the large zone problem as a presentation problem. Put it this way, people like to have abc.com. They want to "see" abc.com on the web URL, their email etc. However, this does not mean the zone data in the DNS must be abc.com. (IDN ACE has same stuff, what you see is not what you get). What this means no one would really care if the technical folk maintain the abc.com zone as a.b.c.com. Wait, before you fall of the chair and bang your head, STOP. It does not matter what you put in the zone, so long you can translate abc.com to a.b.c.com in someway. It does not matter what the server do at the backend, or how it encodes it into the name server etc. data are data, are just bits on the wire and how we play with them and decide what they mean. User only really cares what they see on their screen. Of course, abc.com -> a.b.c.com 'transformation' is not going to work. It would fail for 123abc.com. But the basic idea is this. As some mention to me, this is also a kludge much like Mark proposal. I totally agree but this system have a silent way to introduce the hierarchy back into the DNS silently. A better solution is to relook at DNSSEC. I am not sure how we can fix it but I know DNSSEC is not going to fly at its current stage. It is beyond understanding for mortals. (We are talking about DNS admins who cant even get SOA record right.) Anyone at the IETF interested to speak about this, feel free to look for me. I am in a bright RED T-shirt which say "Bad Idea Fairy" courtesy of Bill Manning. -James Seng to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 14 18:21:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11284 for ; Thu, 14 Dec 2000 18:21:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146guC-0000JZ-00 for namedroppers-data@psg.com; Thu, 14 Dec 2000 14:31:16 -0800 Received: from ietf.207.137.73.1.tx.verio.net ([207.137.73.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146guB-0000JQ-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 14:31:15 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146guD-0000tI-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 14:31:17 -0800 Message-Id: In-Reply-To: <200012130005.QAA03208@gulag.araneus.fi> References: <4.3.2.7.2.20001129113521.0338f460@localhost> <4.3.2.7.2.20001129113521.0338f460@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Dec 2000 14:34:08 -0500 To: gson@nominum.com (Andreas Gustafsson) From: Edward Lewis Subject: Re: DNSEXT WG Last Call: EDNS0.5 Cc: namedroppers@ops.ietf.org, Olafur Gudmundsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:05 PM -0500 12/12/00, Andreas Gustafsson wrote: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt >> >> This draft is on standards track, if you disagree with that please state why >> in your response. > >I object to advancing the draft. Not to pick on Andreas, and not to disagree with the objections...but I'd like to ask the group how we will (or would) approach the retiring of the NXT RR in favor of the NO RR. Mind you, the NO RR is not a lock to knock out the NXT RR, but I think this is a reasonably realistic "challenge problem" to edns0(.5). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 14 18:33:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14732 for ; Thu, 14 Dec 2000 18:33:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146h7G-0000eC-00 for namedroppers-data@psg.com; Thu, 14 Dec 2000 14:44:46 -0800 Received: from ietf.207.137.73.1.tx.verio.net ([207.137.73.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146h7F-0000e6-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 14:44:45 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146h7H-0000vU-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 14:44:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A393FD3.22A10DA@daimlerchrysler.com> Date: Thu, 14 Dec 2000 16:46:59 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Large Zone and DNSSEC References: <4.3.2.7.2.20001213144016.0584cf08@127.0.0.1> <01bc01c065fa$b2c66630$ce4889cf@jamessonyvaio> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since we're floating potentially "bad" (catastrophic, cataclysmic, whatever) ideas, here's one that's been rattling around in my brain a while: A new kind of delegation mechanism based on regular expressions. Imagine being able to delegate "a[^\.]*\.com$" through "z[^\.]*\.com$" to DIFFERENT SETS OF SERVERS. No more monolithic "com" zone. Ditto .net. Ditto .org. Ditto the new gTLD's coming up. Within an organization, imagine being able to delegate all "^www\..*\.example\.com$" to the web server group, all "^mail\..*\.example\.com$" to the mail server group, "^ldap\..*\.example\.com$" to the directory services group, etc. without giving a damn about any subdomains (geographical, organizational, whatever) that may happen to be sandwiched between the initial label and the terminating domain name. I realize there are serious, perhaps fatal problems with this scheme. This is just my pathetic attempt to qualify for one of those "Bad Idea Fairy" T-shirts (since I'm not even at the IETF, I had to make it *extra* bad!) :-) - Kevin James Seng/Personal wrote: > I discussed my idea for the large zone problem yesterday with a couple people. > The responses I got is "speechless-ness", "gasp for air", and "dont go there, > james". I gather I am, once again, onto something ranging from "nuts" to "very > bad idea". > > The industry, whether the engineers like it or not, is moving towards a > flatter lever. gTLD has always been flat, and other ccTLD is doing similar > stuff. It is not going to be an isolated problem for one registry but all > registry is going to be affected in one way or another. HOWEVER, I do not buy > into the idea that the world is flat and "I rule, you fix my problem or die" > speech, thank you very much. > > Now, back to the idea, considering the discussion at IDN on introducing the > "presentation layer" (or others), we could view the large zone problem as a > presentation problem. > > Put it this way, people like to have abc.com. They want to "see" abc.com on > the web URL, their email etc. However, this does not mean the zone data in the > DNS must be abc.com. (IDN ACE has same stuff, what you see is not what you > get). > > What this means no one would really care if the technical folk maintain the > abc.com zone as a.b.c.com. > > Wait, before you fall of the chair and bang your head, STOP. > > It does not matter what you put in the zone, so long you can translate abc.com > to a.b.c.com in someway. It does not matter what the server do at the backend, > or how it encodes it into the name server etc. data are data, are just bits on > the wire and how we play with them and decide what they mean. User only really > cares what they see on their screen. > > Of course, abc.com -> a.b.c.com 'transformation' is not going to work. It > would fail for 123abc.com. But the basic idea is this. > > As some mention to me, this is also a kludge much like Mark proposal. I > totally agree but this system have a silent way to introduce the hierarchy > back into the DNS silently. > > A better solution is to relook at DNSSEC. I am not sure how we can fix it but > I know DNSSEC is not going to fly at its current stage. It is beyond > understanding for mortals. (We are talking about DNS admins who cant even get > SOA record right.) > > Anyone at the IETF interested to speak about this, feel free to look for me. I > am in a bright RED T-shirt which say "Bad Idea Fairy" courtesy of Bill > Manning. > > -James Seng > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 14 20:45:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23951 for ; Thu, 14 Dec 2000 20:45:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146ixz-0003mV-00 for namedroppers-data@psg.com; Thu, 14 Dec 2000 16:43:19 -0800 Received: from ietf.207.137.72.160.tx.verio.net ([207.137.72.160] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146ixy-0003mO-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 16:43:18 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146iy2-00013U-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 16:43:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20001215101351.A9307@connect.com.au> Date: Fri, 15 Dec 2000 10:13:51 +1100 From: Nathan Jones To: James Seng/Personal Cc: namedroppers@ops.ietf.org Subject: Re: Large Zone and DNSSEC References: <4.3.2.7.2.20001213144016.0584cf08@127.0.0.1> <01bc01c065fa$b2c66630$ce4889cf@jamessonyvaio> In-Reply-To: <01bc01c065fa$b2c66630$ce4889cf@jamessonyvaio>; from James Seng/Personal on Fri, Dec 15, 2000 at 02:21:36AM +0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, Dec 15, 2000 at 02:21:36AM +0800, James Seng/Personal wrote: >It does not matter what you put in the zone, so long you can >translate abc.com to a.b.c.com in someway. > >As some mention to me, this is also a kludge much like Mark >proposal. I totally agree but this system have a silent way to >introduce the hierarchy back into the DNS silently. > >I know DNSSEC is not going to fly at its current stage. It is beyond >understanding for mortals. Just as DNSSEC may be beyond understanding for many, I think the idea of silently introducing hierarchy by transforming abc.com to a.b.c.com is difficult to understand without some notes on how it will work. In the example, abc.com would still need to exist in the DNS in order to provide a translation to a.b.c.com, so the large zone (com) is not reduced in size anyway. If the intention is to change the protocol and the software that implements it such that resolvers just know to try a.b.c.com, then how would you orchestrate the change; and for what real benefit? Trying to get my head around your comments, I had a look through the IDN discussion (http://www.imc.org/idn/mail-archive/) where you said things like: "Lets go for a truely distributed structure with no centralized registry model." Does this mean there should be no unique namespace? I understand that you are referring to a next generation of DNS, but it reminded me of "RFC2826 - IAB Technical Comment on the Unique DNS Root" in which similar proposals were labelled technically naive. Perhaps some explanatory notes on how you see this "DNSng" working would help people better understand your suggestions. -- nathanj to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 15 03:45:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04665 for ; Fri, 15 Dec 2000 03:45:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 146piz-000EJ9-00 for namedroppers-data@psg.com; Thu, 14 Dec 2000 23:56:17 -0800 Received: from ietf.207.137.72.160.tx.verio.net ([207.137.72.160] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 146piv-000EIo-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 23:56:16 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 146piz-0001F5-00 for namedroppers@ops.ietf.org; Thu, 14 Dec 2000 23:56:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <01fd01c06666$23b92f10$0a00a8c0@jamessonyvaio> From: "James Seng/Personal" To: "Nathan Jones" Cc: References: <4.3.2.7.2.20001213144016.0584cf08@127.0.0.1> <01bc01c065fa$b2c66630$ce4889cf@jamessonyvaio> <20001215101351.A9307@connect.com.au> Subject: Re: Large Zone and DNSSEC Date: Fri, 15 Dec 2000 15:10:39 +0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Just as DNSSEC may be beyond understanding for many, I think the idea > of silently introducing hierarchy by transforming abc.com to a.b.c.com > is difficult to understand without some notes on how it will work. > > In the example, abc.com would still need to exist in the DNS in order > to provide a translation to a.b.c.com, so the large zone (com) is not > reduced in size anyway. Example, 1. Client send abc.com in DNS/EDNS packet to server. 2. Server receive abc.com from DNS packet, do internal process and break it do a.b.c.com. 3. Server do its normal DNS magic on a.b.c.com and then return answer to Client, with a.b.c.com readjusted back as abc.com. 4. Repeat for every recursion (i.e. .COM server need patch, abc.com server also need patch etc). So no, you dont have abc.com in your zone file. Instead, you have a.b.c.com. We are effectively breaking up a flat level name into hierarchy. And instead of dealing with one large zone, you can then deal with multiple zones. Once again, i need to remind everyone that transforming abc.com into a.b.c.com is probably too simplicity and wont work. We need more exotic transformation which will work with sub-delegation etc. Incidently, you notice that there wouldnt be any changes in the DNS clients or resolver/caching server. The changes only occurs for server side, and only for servers which wants to break their large zone. > If the intention is to change the protocol and the software that > implements it such that resolvers just know to try a.b.c.com, then how > would you orchestrate the change; and for what real benefit? No, DNS protocol dont change (at least not the wire format). Only software implementation. I would say it is an architecture change. > Trying to get my head around your comments, I had a look through the > IDN discussion (http://www.imc.org/idn/mail-archive/) where you said > things like: "Lets go for a truely distributed structure with no > centralized registry model." Does this mean there should be no unique > namespace? > > I understand that you are referring to a next generation of DNS, but > it reminded me of "RFC2826 - IAB Technical Comment on the Unique DNS > Root" in which similar proposals were labelled technically naive. > > Perhaps some explanatory notes on how you see this "DNSng" working > would help people better understand your suggestions. I was discussing this offline with some folk. But the general idea is if we were to do DNSng, and we got a chance to start all over again, Do we want to design a system which creates a monopolistic hierarchical structure again? I am not saying unique root is bad or suggesting alternative root. I am suggesting "NO ROOT". (Okay, I like to come up with bad ideas :-P). -James Seng to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 16 09:25:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19040 for ; Sat, 16 Dec 2000 09:25:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 147Hgq-0001dA-00 for namedroppers-data@psg.com; Sat, 16 Dec 2000 05:47:56 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 147Hgq-0001d4-00 for namedroppers@ops.ietf.org; Sat, 16 Dec 2000 05:47:56 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 147Hgq-00039p-00 for namedroppers@ops.ietf.org; Sat, 16 Dec 2000 05:47:56 -0800 Message-ID: <3A3B082E.84195F84@software-munitions.com> Date: Fri, 15 Dec 2000 22:14:07 -0800 From: Dennis Glatting X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Security comments re draft-ietf-dnsext-unknown-rrs-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One problem I have with this draft is blind Kashpureff attacks. One of the reasons Kashpureff was successful is that implementations didn't check returned data very hard, rather they simply cached it and passed it on later. What this draft does, I believe, and regardless of DNSsec, is make this kind of attack trivial again. Additionally, I can imagine a cleverly crafted unknown RR type that tickles an resolver implementation error, such as a buffer overrun or an off-by-one error, for a given set of clients, such as a particular unpatched version of Microsoft NT. Since a server simply passes data on, then you have no hope of distinguishing between proper data and bad data and protecting clients. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 16 20:02:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24368 for ; Sat, 16 Dec 2000 20:02:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 147Rl1-000DcR-00 for namedroppers-data@psg.com; Sat, 16 Dec 2000 16:32:55 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 147Rl0-000DcJ-00 for namedroppers@ops.ietf.org; Sat, 16 Dec 2000 16:32:54 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 147Rkz-0002jJ-00 for namedroppers@ops.ietf.org; Sat, 16 Dec 2000 16:32:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 16 Dec 2000 13:33:57 -0800 (PST) Message-Id: <200012162133.NAA06258@gulag.araneus.fi> To: Dennis Glatting Cc: namedroppers@ops.ietf.org Subject: Re: Security comments re draft-ietf-dnsext-unknown-rrs-00.txt In-Reply-To: <3A3B082E.84195F84@software-munitions.com> References: <3A3B082E.84195F84@software-munitions.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > One problem I have with this draft is blind Kashpureff attacks. One of > the reasons Kashpureff was successful is that implementations didn't > check returned data very hard, rather they simply cached it and passed > it on later. What this draft does, I believe, and regardless of > DNSsec, is make this kind of attack trivial again. I don't think so. I believe you are referring to a cache poisoning attack, and the reasons those worked was that servers cached RRs without checking their *origin*. This is an entirely different issue from checking their *contents*. Also, those attacks involve record types used by the resolution process itself, such as NS and/or A records, which are not unknown types and therefore not affected by the draft. > Additionally, I can imagine a cleverly crafted unknown RR type that > tickles an resolver implementation error, such as a buffer overrun or > an off-by-one error, for a given set of clients, such as a particular > unpatched version of Microsoft NT. Since a server simply passes data > on, then you have no hope of distinguishing between proper data and > bad data and protecting clients. Any client that does not sufficiently check its network input, be it from the DNS or some other protocol, is broken and needs to be fixed. The DNS specifications have never explicitly required servers to verify the internal format of the RR data, and adding such a requirement is likely to mislead client authors into trusting the server instead of doing proper checking themselves. I'm not saying that such server-based checking should not be done - it can be a useful part of a firewall designed to protect insecure legacy applications. It just shouldn't be required by the protocol. We don't require HTTP proxies to strip unknown HTML tags either, even though they too could potentially be malicious. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 16 20:19:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24367 for ; Sat, 16 Dec 2000 20:02:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 147RlT-000Dcp-00 for namedroppers-data@psg.com; Sat, 16 Dec 2000 16:33:23 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 147RlS-000Dcj-00 for namedroppers@ops.ietf.org; Sat, 16 Dec 2000 16:33:22 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 147RlU-0002jL-00 for namedroppers@ops.ietf.org; Sat, 16 Dec 2000 16:33:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A3BEF4D.D0250CCA@software-munitions.com> Date: Sat, 16 Dec 2000 14:40:13 -0800 From: Dennis Glatting To: Andreas Gustafsson CC: namedroppers@ops.ietf.org Subject: Re: Security comments re draft-ietf-dnsext-unknown-rrs-00.txt References: <3A3B082E.84195F84@software-munitions.com> <200012162133.NAA06258@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andreas Gustafsson wrote: > > > One problem I have with this draft is blind Kashpureff attacks. One of > > the reasons Kashpureff was successful is that implementations didn't > > check returned data very hard, rather they simply cached it and passed > > it on later. What this draft does, I believe, and regardless of > > DNSsec, is make this kind of attack trivial again. > > I don't think so. I believe you are referring to a cache poisoning > attack, and the reasons those worked was that servers cached RRs > without checking their *origin*. This is an entirely different issue > from checking their *contents*. > > Also, those attacks involve record types used by the resolution > process itself, such as NS and/or A records, which are not unknown > types and therefore not affected by the draft. > An unknown RR could be an A6. If a server doesn't understand an A6 then its cache can be poisoned and the resolution process impacted. Additionally, we cannot predict what future RR types will have on the resolution process. > > Additionally, I can imagine a cleverly crafted unknown RR type that > > tickles an resolver implementation error, such as a buffer overrun or > > an off-by-one error, for a given set of clients, such as a particular > > unpatched version of Microsoft NT. Since a server simply passes data > > on, then you have no hope of distinguishing between proper data and > > bad data and protecting clients. > > Any client that does not sufficiently check its network input, be it > from the DNS or some other protocol, is broken and needs to be fixed. > The DNS specifications have never explicitly required servers to > verify the internal format of the RR data, and adding such a > requirement is likely to mislead client authors into trusting the > server instead of doing proper checking themselves. > > I'm not saying that such server-based checking should not be done - it > can be a useful part of a firewall designed to protect insecure legacy > applications. It just shouldn't be required by the protocol. We don't > require HTTP proxies to strip unknown HTML tags either, even though > they too could potentially be malicious. > Yet the draft implies, assuming I am interpreting Section 3 correctly, a DNS content firewall is to ignore the data and pass it on. In that case, the draft says: DNS content firewall are non-compliant. I do not believe a DNS content firewall will simply pass unknown data. Assuming for the sake of argument that would be true, then the reality would be many non-compliant servers thereby rendering the draft moot. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 17 12:06:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03948 for ; Sun, 17 Dec 2000 12:06:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 147gf5-000Gz0-00 for namedroppers-data@psg.com; Sun, 17 Dec 2000 08:27:47 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 147gf3-000Gyu-00 for namedroppers@ops.ietf.org; Sun, 17 Dec 2000 08:27:46 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 147gf2-0004N3-00 for namedroppers@ops.ietf.org; Sun, 17 Dec 2000 08:27:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001216122834.056e3130@127.0.0.1> Date: Sat, 16 Dec 2000 12:42:25 -0800 To: "James Seng/Personal" , "Nathan Jones" From: Harald Alvestrand Subject: NO ROOT? (Re: Large Zone and DNSSEC) Cc: In-Reply-To: <01fd01c06666$23b92f10$0a00a8c0@jamessonyvaio> References: <4.3.2.7.2.20001213144016.0584cf08@127.0.0.1> <01bc01c065fa$b2c66630$ce4889cf@jamessonyvaio> <20001215101351.A9307@connect.com.au> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 15:10 15/12/2000 +0800, James Seng/Personal wrote: >I was discussing this offline with some folk. But the general idea is if we >were to do DNSng, and we got a chance to start all over again, Do we want to >design a system which creates a monopolistic hierarchical structure again? > >I am not saying unique root is bad or suggesting alternative root. I am >suggesting "NO ROOT". (Okay, I like to come up with bad ideas :-P). a few philosophical thougths: the central human question of naming is what happens when two entries wish to be known by the same name. The alternatives are: - Return data for both (search) - Return data for one (lookup) - Return data for none (hah!) DNS provides a name-to-unique-entry mapping; no search. So the first alternative does not work for the applications the DNS are used for. Across the DNS, we have seen multiple ways to decide which to return when both want them: - show reasonable proof that you are the rightful owner, then keep it (.se, .edu) - first asker gets it, and keeps it until evicted (.com) - nobody gets it because we can't agree on the rules (.) Specifying which decision mechanism to use is out of scope for the IETF (and most of the wars in ICANN have been over the "eviction" clause of .com) But the DNS has a simple way of deciding who the current "tenant" is: follow the chain of authoritative delegations from the root of your choice. (Specifying which root to use is also out of scope for the IETF; observing midly that the DNS is quite a bit less useful if there isn't agreement on a single "public" root is as far as we have gone.) So - any new proposal needs to specify which mechanism to use to decide which of two claims for a name-to-info mapping to believe; saying "the answer that got to you first" is not quite a specification to inspire confidence. A root is not the only answer. It's only the simplest (AFAIK). -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 17 12:06:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03973 for ; Sun, 17 Dec 2000 12:06:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 147gXt-000GYJ-00 for namedroppers-data@psg.com; Sun, 17 Dec 2000 08:20:21 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 147gXs-000GYB-00 for namedroppers@ops.ietf.org; Sun, 17 Dec 2000 08:20:20 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 147gXp-0004Ma-00 for namedroppers@ops.ietf.org; Sun, 17 Dec 2000 08:20:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 16 Dec 2000 19:53:25 -0800 (PST) Message-Id: <200012170353.TAA06445@gulag.araneus.fi> To: Dennis Glatting Cc: Andreas Gustafsson , namedroppers@ops.ietf.org Subject: Re: Security comments re draft-ietf-dnsext-unknown-rrs-00.txt In-Reply-To: <3A3BEF4D.D0250CCA@software-munitions.com> References: <3A3B082E.84195F84@software-munitions.com> <200012162133.NAA06258@gulag.araneus.fi> <3A3BEF4D.D0250CCA@software-munitions.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > An unknown RR could be an A6. If a server doesn't understand an A6 > then its cache can be poisoned and the resolution process impacted. > Additionally, we cannot predict what future RR types will have on the > resolution process. Unknown types are no more prone to poisoning than known types are. The anti-poisoning logic used by modern DNS servers is not based on examining the contents of the RRs. > Yet the draft implies, assuming I am interpreting Section 3 correctly, > a DNS content firewall is to ignore the data and pass it on. In that > case, the draft says: DNS content firewall are non-compliant. Yes, that's what it says. I'm not sure that's a problem - you could argue that any firewall system is non-compliant by definition because its very purpose is to sometimes fail to provide the services defined by the protocols being filtered. If necessary, the text of the draft could be changed explicitly make firewalls compliant, for example by changing "must handle transparently" into "must be capable of handling transparently". -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 18 01:23:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25021 for ; Mon, 18 Dec 2000 01:23:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 147t5d-0000Rs-00 for namedroppers-data@psg.com; Sun, 17 Dec 2000 21:44:01 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 147t5c-0000Rm-00 for namedroppers@ops.ietf.org; Sun, 17 Dec 2000 21:44:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 147t5c-000NTh-00 for namedroppers@ops.ietf.org; Sun, 17 Dec 2000 21:44:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200012171910.LAA22474@toad.com> To: Harald Alvestrand cc: "James Seng/Personal" , "Nathan Jones" , namedroppers@ops.ietf.org Subject: Re: NO ROOT? In-reply-to: <4.3.2.7.2.20001216122834.056e3130@127.0.0.1> Date: Sun, 17 Dec 2000 11:10:52 -0800 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng said: > I was discussing this offline with some folk. But the general idea > is if we were to do DNSng, and we got a chance to start all over > again, Do we want to design a system which creates a monopolistic > hierarchical structure again? Harald Alvestrand said: > So - any new proposal needs to specify which mechanism to use to decide > which of two claims for a name-to-info mapping to believe; saying "the > answer that got to you first" is not quite a specification to inspire > confidence. > > A root is not the only answer. It's only the simplest (AFAIK). Correct. When the DNS was designed, very little was known about distributed databases. Today I have been told by distributed database designers that it is within the state of the art to build a widely distributed database which will permit broad distribution of update operations, yet still converge on a single value of "truth" about a particular record. As Harald said, the proposal would need to specify a mechanism to use to decide how to converge on a single value. Once such a mechanism was designed and debugged, it would permit the system to automatically decide among competing claims to a name (e.g. based on the update timestamp, or on other deterministic criteria if the timestamps were identical). The important point is that the process converges on a single answer. It's even better if the process can't be manipulated to favor a particular player or class of players (so that they would "win" more often). Such a system would eliminate or reduce the power asymmetries that are built by design into hierarchies like the current DNS. This would reduce the likelihood that significant power over a DNSng would be captured by any particular faction (like SAIC, government lobbyists, trademark lawyers, or anybody else). This would provide a positive social benefit, by reducing the risk of abuse that has become obvious in the current hierarchical design. The Internet routing system, for example, is not hierarchical, and it's been much harder for any single player to abuse it. Despite government connections, nobody has yet exerted the kind of monopoly control that SAIC/Network Solutions abused to gain billions of dollars, and help their friends the trademark lawyers, at the expense of the rest of the Internet community. Such a DNSng project would definitely be research, and would take a minimum of a decade before the bulk of the Internet would choose to replace their use of the current DNS with it. The Electronic Frontier Foundation board has indicated some interest in sponsoring or otherwise assisting with some of the research required to bring this idea closer to fruition. I believe that the key is to interest a gifted distributed database designer, to lead the effort to clearly define the problem and produce a protocol that solves it. Know one? John Gilmore to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 18 11:49:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10943 for ; Mon, 18 Dec 2000 11:49:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1482mR-0000DF-00 for namedroppers-data@psg.com; Mon, 18 Dec 2000 08:04:51 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1482mQ-0000D8-00 for namedroppers@ops.ietf.org; Mon, 18 Dec 2000 08:04:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1482mQ-0002l5-00 for namedroppers@ops.ietf.org; Mon, 18 Dec 2000 08:04:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001216044327.00bdc7e0@localhost> Date: Sat, 16 Dec 2000 23:00:05 -0500 To: itojun@iijlab.net, Olafur Gudmundsson From: Olafur Gudmundsson Subject: Re: DNSEXT WG Last Call: Message Size Cc: DNSEXT WG Mailing list In-Reply-To: <16207.975548532@coconut.itojun.org> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 08:42 PM 11/29/00, itojun@iijlab.net wrote: > >This is a DNSEXT WG last call on this document, please send your comments > >to mailto:namedroppers@ops.ietf.org > > > >This document updates RFC2535 and RFC2874 (A6) to demand larger > >UDP message size than 512 bytes. This document mandates that any > >entity supporting either DNSSEC or A6 records must support EDNS0 on queries > >and responses. > >The motivation(s) for this is the increase in size of DNS answers caused > >by DNSSEC, IPng, TSIG and large the desire for large answer sets. > >The document assumes that modern operating systems can do UDP reassembly, > >thus this the single UDP message requirement can be relaxed and this is > >less costly than falling back on TCP for all large answers. > > > >This WG last call ends December 17'th 2000. > > I have one comment to the draft. Isn't it necessary for us to > document > some recommendation on fragmentation? for example, addition of the > following section would be better for readers... > > if it is out of scope of the document, i should come up with separate > document (actually, this is not a DNS issue but IPv6 UDP issue). I agree there might be some merit to do this but I'm not sure I want to put that text in this documentation. I think a small clarification in the host IPng requirements document is better. >itojun > > >Fragmentation and path MTU discovery > >Unlike IPv4, IPv6 mandates path MTU discovery. No packets will be fragmented >en route. Therefore, for both servers and resolvers, large UDP >queries/replies >may not reach the peer. Intermediate routers will transmit ICMPv6 too big >message in that case. >There can be couple of implementation choices. (3) is the easiest but >could be inefficient. (1) puts some assumption to operating system, can >be slow on catch up to the new MTU (due to timeout), but is easy enough to >implement. (2) should present the best behavior, but implementation could >become too complex, specifically for server side. DNS servers can be implemented as "answer and forget" servers thus it is not within scope to require that they implement retransmission in UDP. Storing state on the servers to do retransmission is more expensive than answering a new query. Not to mention the DOS potential of such mechanism. >1. Do nothing special, rely upon path MTU discovery. Send a large packet >as is. > If answer does not come back, retrnansmit the large packet again > after retransmission timeout, assuming that the operating system > has notified of smaller MTU and automatically fragment it. >2. Try to implement retransmission logic. When server/resolver receives > ICMPv6 too big message, retransmit query/reply using the new path MTU. >3. Always fragment large UDP queries/replies to IPv6 minimum mtu (1280 octets > according to RFC2460), to avoid path MTU discovery completely. The last option was my intention, BUT if the server can learn the MTU from the small query packet then 1.would be optimal. The middle solution will not work, as that requires server to allocate state that is only removed after time out, unless there is feedback that the data got to the client. Based on the experience we had in the DNSSEC/IPv6 WES we held Friday and Saturday after the IETF all the implementations present handle fragmentation well. The problems with large UDP answers are mainly going to show up in networks with high loss ratios. Message size combined with DNSSEC-OK bit will minimize the transmission of the MEGA DNS answers except to the hosts interested in DNSSEC. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 20 13:18:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08488 for ; Wed, 20 Dec 2000 13:18:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 148nBw-0008Zx-00 for namedroppers-data@psg.com; Wed, 20 Dec 2000 09:38:16 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 148nBw-0008Zr-00 for namedroppers@ops.ietf.org; Wed, 20 Dec 2000 09:38:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 148nBv-000OJq-00 for namedroppers@ops.ietf.org; Wed, 20 Dec 2000 09:38:15 -0800 Message-Id: <200012201215.HAA20429@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rsa-02.txt Date: Wed, 20 Dec 2000 07:15:29 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-rsa-02.txt Pages : 8 Date : 19-Dec-00 Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rsa-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rsa-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001219130544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rsa-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rsa-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001219130544.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 21 11:29:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23452 for ; Thu, 21 Dec 2000 11:29:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1497kS-0001wz-00 for namedroppers-data@psg.com; Thu, 21 Dec 2000 07:35:16 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1497kS-0001wt-00 for namedroppers@ops.ietf.org; Thu, 21 Dec 2000 07:35:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1497kS-0002cu-00 for namedroppers@ops.ietf.org; Thu, 21 Dec 2000 07:35:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200012211430.JAA32292@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: namedroppers@ops.ietf.org cc: lde008@dma.isg.mot.com Subject: draft-ietf-dnsext-rsa-02.txt Date: Thu, 21 Dec 2000 09:30:12 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI, this draft has only very minor changes. There was a one byte correction in the magic hex prefix to make a signature compatible with PKCS1, a few senstences discussing the possibility of keeping algorithm #1 for the RSA KEYs were dropped since the consensus seems to be to use the new algorithm # for both KEYs and SIGs, and author info was updated. Thanks, Donald ------- Forwarded Message Message-Id: <200012201215.HAA20429@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rsa-02.txt Date: Wed, 20 Dec 2000 07:15:29 -0500 Sender: owner-namedroppers@ops.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-rsa-02.txt Pages : 8 Date : 19-Dec-00 Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-02.txt ... to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 22 18:27:48 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16178 for ; Fri, 22 Dec 2000 18:27:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 149b2f-0003fX-00 for namedroppers-data@psg.com; Fri, 22 Dec 2000 14:52:01 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 149b2e-0003f5-00 for namedroppers@ops.ietf.org; Fri, 22 Dec 2000 14:52:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 149b2e-000LwQ-00 for namedroppers@ops.ietf.org; Fri, 22 Dec 2000 14:52:00 -0800 Date: Fri, 22 Dec 2000 22:05:42 +0000 (GMT) From: "Brian W. Spolarich" X-Sender: briansp@admin1.corp.walid.com To: John Gilmore cc: Harald Alvestrand , James Seng/Personal , Nathan Jones , namedroppers@ops.ietf.org Subject: Re: NO ROOT? In-Reply-To: <200012171910.LAA22474@toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 17 Dec 2000, John Gilmore wrote: | When the DNS was designed, very little was known about distributed | databases. Today I have been told by distributed database designers | that it is within the state of the art to build a widely distributed | database which will permit broad distribution of update operations, | yet still converge on a single value of "truth" about a particular | record. John, do you have any pointers to particular implementations that possess these properties and are available under some sort of open-source licensing arrangement? -bws to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 24 19:15:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09976 for ; Sun, 24 Dec 2000 19:15:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14AKnA-000Fat-00 for namedroppers-data@psg.com; Sun, 24 Dec 2000 15:43:04 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14AKnA-000Fan-00 for namedroppers@ops.ietf.org; Sun, 24 Dec 2000 15:43:04 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14AKnA-000EIk-00 for namedroppers@ops.ietf.org; Sun, 24 Dec 2000 15:43:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001224015647.00b63450@localhost> Date: Sun, 24 Dec 2000 02:02:54 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WGLC summary: Message size Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This last call has completed. The working group consensus is to approve the document, with few minor clarifications and forward it to the IESG. During the last call comment period no major issues where raised: Request for clarification on how to avoid fragmentation errors in IPv6 Request for minor word changes. One person asserted this was not needed but everyone else does. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 24 19:15:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09993 for ; Sun, 24 Dec 2000 19:15:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14AKms-000Fah-00 for namedroppers-data@psg.com; Sun, 24 Dec 2000 15:42:46 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14AKms-000Fab-00 for namedroppers@ops.ietf.org; Sun, 24 Dec 2000 15:42:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14AKms-000EIX-00 for namedroppers@ops.ietf.org; Sun, 24 Dec 2000 15:42:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001224015527.00b60d00@localhost> Date: Sun, 24 Dec 2000 01:56:41 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WGLC summary: Dnssec OK bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This last call has completed. The working group consensus is to approve the document as is and forward it to the IESG. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 24 19:23:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09975 for ; Sun, 24 Dec 2000 19:15:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14AKme-000FaW-00 for namedroppers-data@psg.com; Sun, 24 Dec 2000 15:42:32 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14AKmd-000FaQ-00 for namedroppers@ops.ietf.org; Sun, 24 Dec 2000 15:42:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14AKmd-000EIN-00 for namedroppers@ops.ietf.org; Sun, 24 Dec 2000 15:42:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20001224020531.00c40880@localhost> Date: Sun, 24 Dec 2000 02:07:30 -0500 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WGLC summary: Zone status Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This last call has completed. The working group consensus is to approve the document as is and forward it to the IESG. During the last call comment period no major issues where raised. Author is requested to look over the document once more and notify chair if this is his final version. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.