From owner-v6ops@ops.ietf.org Mon Sep 1 14:00:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10100 for ; Mon, 1 Sep 2003 14:00:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tstG-000Bws-SX for v6ops-data@psg.com; Mon, 01 Sep 2003 17:54:58 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtp (Exim 4.22) id 19tssE-000BsT-RA; Mon, 01 Sep 2003 17:53:54 +0000 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h81Ht6hs020235; Mon, 1 Sep 2003 10:55:06 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h81HrrV00988; Mon, 1 Sep 2003 10:53:54 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 1 Sep 2003 10:53:53 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: v6ops@ops.ietf.org cc: ops-area@ops.ietf.org Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502582093@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 1 Sep 2003, Wijnen, Bert (Bert) wrote: > Mike, thanks for your detailed review. > I have a few additional comments inline. I have some clarifications to add for a few of those items. > > | 3.2 RFC 1155 Structure of Management Information ... > > There should also be a subsection for RFC 1212, and perhaps also RFC > > 1215, since RFCs 1155 and 1212 form STD 16, and together with RFC > > 1215 define SMIv1. > > > It might also be good/wise to mention that SMIv1 is currently still at > STD level because some other documents at STD or DRAFT STD level still > depend on it. But there is NO new work being done based on the SMIv1 > STD, and (at least all IETF standards track) work is now using the > new SMIv2 document set. I agree with that suggestion. Note that the text I proposed for the analysis section 7.1.1 makes reference to the "NO new work" part, as it states that "the limitations identified in this Internet Standard do not require any action." As an aside, I'll mention that part of the reasoning applies also to RFC 1213 (MIB-II): a number of STD or DRAFT STD level still depend on it, too, so it will probably never be retired, either. But that probably doesn't need to be mentioned in the survey doc since there is at present a stronger reason: we don't yet have replacements for the IP group, the ICMP group, the TCP group, and the UDP group, although that is being worked on. > > | 3.8 RFC 3416 Protocol Operations for Version 2 of the Simple Network > > | Management Protocol (SNMPv2) (OPS-MIB) > > > > Remove "(OPS-MIB)" ... the mnemonic is misleading, as this document > > does not contain a MIB module. See also the note below. > > ... > > > > | 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network > > | Management Protocol (SNMPv2) (TRANS-MIB) > > > > NOTE: I would like to suggest that it is more useful in the case > > of standards that contain a single MIB module to use the MIB module > > names instead of the sometimes strange and seldom-used mnemonics > > that are listed in STD 1, Official Internet Protocol Standards. > > I will be making this suggestion for each spec that contains a > > single MIB module; in the present case the change would be: > > > > s/TRANS-MIB/SNMPv2-TM/ > > > I agree with Mike. > Please do NOT invent your own "MIB-XXX" names that do not exist. In fairness to the authors, it seems that it was this practice originated in STD 1, Official Internet Protocol Standards -- currently RFC 3300 -- where the RFC Editor staff appear to have made up the acronyms and was carried forward into this document. For instance, it says in RFC 3300: 3.3. Draft Standard Protocols Mnemonic Title RFC# ------------------------------------------------------------------------ [ ... ] INTERGRMIB The Interfaces Group MIB 2863 -------- Host Resources MIB 2790 SNMP Definitions of Managed Objects for Extensible 2742* SNMP Agents -------- Agent Extensibility (AgentX) Protocol Version 1 2741* [ ... ] VACM-SNMP View-based Access Control Model (VACM) for 2575 the Simple Network Management Protocol (SNMP) USM-SNMPV3 User-based Security Model (USM) for version 2574 3 of the Simple Network Management Protocol (SNMPv3) SNMP-APP SNMP Applications 2573 MPD-SNMP Message Processing and Dispatching for the 2572 Simple Network Management Protocol (SNMP) ARCH-SNMP An Architecture for Describing SNMP Management 2571 Frameworks [ ... ] SNMPv2-MIB Management Information Base for Version 2 1907 of the Simple Network Management Protocol (SNMPv2) TRANS-MIB Transport Mappings for Version 2 of the Simple 1906 Network Management Protocol (SNMPv2) OPS-MIB Protocol Operations for Version 2 of the Simple 1905 Network Management Protocol (SNMPv2) I squawked about using INTERGRMIB instead of IF-MIB for RFC 2863, about using SNMP for any MIB module, about using OPS-MIB for RFC 1905 (now 3416), about using TRANS-MIB instead of SNMPv2-TM, and about many other such things. I didn't squawk about VACM-SNMP, USM-SNMPV3, SNMP-APP, MPD-SNMP, ARCH-SNMP, or any acronym for a non-MIB document unless it was clearly wrong, like OPS-MIB. I'm not sure if it would pay to pick a fight with the RFC Editor about this practice, but I also don't think it's a good idea to follow the practoce in the case of MIB modules because no-one in the MIB community does so. I know quite well that IF-MIB means the MIB module in RFC 2863, but I'd have had no clue what INTERGRMIB meant if I hadn't seen it in RFC 3300. That's why I raised this issue. > > | 5.033 RFC 2013 SNMPv2 Management Information Base for the User > > | Datagram Protocol using SMIv2 (MIB-UDP) > > > > s/MIB-UDP/UDP-MIB/ > > > > | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in > > | the note reproduced below: > > > > s/OIDs/object definitions/ > > > > | IESG Note: > > | > > | The IP, UDP, and TCP MIB modules currently support only IPv4. These > > | three modules use the IpAddress type defined as an OCTET STRING of > > | length 4 to represent the IPv4 32-bit internet addresses. (See RFC > > | 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 > > | internet addresses. > > | > Might want to add another editors note that RFC1902 has been obsoleted > by RFC2578 (STD 58) in the meantime. > > Would it make sense to mention that IPv6 WG is working on this? > (In fact they are getting close to deliver a replacement document > I believe). Hmm, I think that might be a distraction here. My understanding is that the authors intended for this section only to report the "raw data" ... all the analysis is in Section 7. And the text in that section (with the proposed edits) does address both of those points. This same comment applies also for RFCs 2011, 2012, and 2096. > > | radiusAuthServerAddress OBJECT-TYPE > > | SYNTAX IpAddress > > | MAX-ACCESS read-only > > | STATUS current > > | DESCRIPTION > > | "The IP address of the RADIUS authentication server > > | referred to in this table entry." > > | ::= { radiusAuthServerEntry 2 } > > | > > | There needs to be an update to allow an IPv6 based OID for this > > | value. > > | > s/OID/object/ > > Mike... you seem to have forgotten/missed this one? > Or Mike would probably say: > > Reword with: > This object needs to be deprecated and replaced by one that > supports both IPv4 and IPv6 addresses. > > And I agree. Yep, I missed that. > > | 5.086 RFC 2669 DOCSIS Cable Device MIB Cable Device Management > > | Information Base for DOCSIS compliant Cable Modems and > > | Cable Modem Termination Systems > > | > > | This document states: > > | > > | Please note that the DOCSIS 1.0 standard only requires Cable > > | Modems to implement SNMPv1 and to process IPv4 customer traffic. > > | Design choices in this MIB reflect those requirements. Future > > | versions of the DOCSIS standard are expected to require support > > | for SNMPv3 and IPv6 as well. > > | > And in fact a new revision is being worked on by IPCDN as we speak. Section 7.3.23 mentions that fact. > > | 5.097 RFC 2749 COPS usage for RSVP > > | > > | There are no IPv4 dependencies in this protocol. > > | > > | 5.098 RFC 2769 Routing Policy System Replication (RPSL) > > > > remove "(RPSL)" > > > > | There are no IPv4 dependencies in this protocol. > > > > Is this an OPS Area spec? It looks like a routine area > > spec to me. > > > Routine Area? Or Routing area? That's an amusing typo :-) > In any event, the document was done in a WG that used to be in > the OPS Area... Oh well. OK, then it's probably listed in the right place. I was just asking because I wasn't sure. > > | 5.107 RFC 2925 Definitions of Managed Objects for Remote > > | Ping, Traceroute, and Lookup Operations ... > > | pingCtlDataSize OBJECT-TYPE > > | SYNTAX Unsigned32 (0..65507) > > | UNITS "octets" > > | MAX-ACCESS read-create > > | STATUS current > > | DESCRIPTION > > | "Specifies the size of the data portion to be > > | transmitted in a ping operation in octets. A ping > > | request is usually an ICMP message encoded > > | into an IP packet. An IP packet has a maximum size > > | of 65535 octets. Subtracting the size of the ICMP > > | or UDP header (both 8 octets) and the size of the IP > > | header (20 octets) yields a maximum size of 65507 > > | octets." > > | DEFVAL { 0 } > > | ::= { pingCtlEntry 5 } > > | > > | > > | traceRouteCtlDataSize OBJECT-TYPE > > | SYNTAX Unsigned32 (0..65507) > > | UNITS "octets" > > | MAX-ACCESS read-create > > | STATUS current > > | DESCRIPTION > > | "Specifies the size of the data portion of a traceroute > > | request in octets. A traceroute request is essentially > > | transmitted by encoding a UDP datagram into a > > | IP packet. So subtracting the size of a UDP header > > | (8 octets) and the size of a IP header (20 octets) > > | yields a maximum of 65507 octets." > > | DEFVAL { 0 } > > | ::= { traceRouteCtlEntry 6 } > > | > > | There is clearly an assumption of IPv4 header sizes. > > > > Please rewrite this last sentence: > > > > The DESCRIPTION clauses need to be updated to remove the > > IPv4 dependencies. > > > > Note that there is nothing wrong with the objects themselves. I guess that's true ... and the only change that's needed is: s/size of a IP header/minimum size of a IP header/ since the minimum size of any IP header (v4 or v6) is 20 octets (the smalled IPv6 header is 40 octets). But that detail probably doesn't need to go into the survey document. Once again, let me say that despite all the criticism we owe the authors of this draft a big debt of gratitude for all the hard work in collecting this valuable information. I hope that our comments will serve to make the work better. Thanks, Mike Heard From owner-v6ops@ops.ietf.org Mon Sep 1 15:48:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12407 for ; Mon, 1 Sep 2003 15:48:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tuYV-0002rb-Bw for v6ops-data@psg.com; Mon, 01 Sep 2003 19:41:39 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19tuYR-0002r0-Su for v6ops@ops.ietf.org; Mon, 01 Sep 2003 19:41:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h81JfYR25924 for ; Mon, 1 Sep 2003 22:41:34 +0300 Date: Mon, 1 Sep 2003 22:41:34 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Work in the GGF IPv6 WG (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=------------2C39F8267F6AC9A668BD9AF4 Content-ID: X-Spam-Status: No, hits=0.0 required=5.0 tests=USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------2C39F8267F6AC9A668BD9AF4 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: FYI, Brian et al. mentioned collaboration with a pending Global Grid Forum IPv6 WG in the Vienna IETF; we should be able to increase the relevance of our work by working together :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Mon, 25 Aug 2003 16:20:48 +0200 From: Brian E Carpenter To: Robert Fink , Pekka Savola , Jonne.Soininen@nokia.com Cc: Piers O'Hanlon , Randy Bush , Peter Clarke Subject: Work in the GGF IPv6 WG Dear v6ops chairs, Piers O'Hanlon and I are co-chairs of the about-to-be-created IPv6-WG in the Global Grid Forum. I've attached our draft charter, and if you should want to join the mailing list, you do so by saying "subscribe ipv6-wg" to . We don't yet have a WG web site, but when we do, it will be somewhere at http://forge.gridforum.org/ . Our GGF Area Director is Peter Clarke. (Peter, the IETF work can be found at http://www.ietf.org/html.charters/v6ops-charter.html .) As you will see, our first two deliverables are not so different from some of the work in v6ops. In fact, Rute Sofia, who is co-author of draft-ietf-v6ops-ipv4survey-apps-01.txt, will also be working on the GGF equivalent of that draft. We will also look carefully at draft-shin-v6ops-application-transition-01.txt. This is FYI at the moment, but as we progress with our deliverables, closer cooperation might be a Good Thing. Feel free to forward this note. Regards Brian -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK --------------2C39F8267F6AC9A668BD9AF4 Content-Type: TEXT/PLAIN; CHARSET=us-ascii; NAME="IPv6-WG-proposal.txt" Content-ID: Content-Description: Content-Disposition: INLINE; FILENAME="IPv6-WG-proposal.txt" 1 DRAFT 2003-08-07 IPv6 Working Group Global Grid Forum, Data Area Administrative Information Name and Acronym: IPv6-WG Chairs: Brian Carpenter Piers O'Hanlon Secretary(s)/Webmaster(s): tbd Email list: ipv6-wg@ggf.org Web page: http://forge.ggf.org/projects/ipv6-wg Charter Focus/Purpose IPv6 is now emerging as a significant factor in operational networks, and continued scaling up of the Internet (and thus of Grids) will require the additional address space and management features of IPv6. It is therefore important that all GGF specifications work as well (or better) with IPv6 as with IPv4. The purpose of the working group is to identify any GGF specifications that do not meet this requirement, to provide appropriate guidelines for future specifications, and to communicate any issues discovered with IPv6 to the IETF. Scope The scope is IP version dependencies in the output of all working groups in all GGF areas. However, it is expected that many WGs will be quickly eliminated as having no such dependencies. Any specification that involves the handling of network I/O or IP addresses, or the processing or display of URLs is likely to be affected. Goals Either two or three deliverables are planned, according to the result of the work. 1. IP version dependencies in GGF specifications. This will be an Informational document identifying each GGF specification (approved or public draft) that contains dependencies on IPv4 (principally address format and length). It is intended to be used as a checklist for planning the necessary document revisions by the WGs concerned. Milestone for draft: GGF9 Milestone for final: before GGF10 2. Guidelines for IP version independence in GGF specifications. This will be an informational document describing how to avoid IPv4 dependency in GGF specifications. It is intended to be used by all GGF WGs and as a checklist for document approval. Milestone for draft: GGF9 Milestone for final: before GGF10 3. Issues in IPv6 specifications. If the work on these two deliverables identifies any issues in the IETF specifications for IPv6, the third deliverable will be an Informational liaison document to be sent to the IETF describing these issues. If no such issues are found, or if they are accepted by the IETF through informal liaison, the document will not be produced. Milestone for draft: GGF10 Milestone for final: TBD Management Issues Evidence of commitments to carry out WG tasks Brian Carpenter and Piers O'Hanlon are committed to lead. We have at least 6 other people who have indicated willingness to contribute actively. Pre-existing Document(s) (if any) Two highly relevant IETF drafts: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-01.txt http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-01.txt We will in fact investigate whether direct collaboration with the IETF is possible. Exit Strategy It is not expected that the WG will have any reason to continue after the deliverables have been published Any other relevant information n/a --------------2C39F8267F6AC9A668BD9AF4-- From owner-v6ops@ops.ietf.org Mon Sep 1 18:34:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15152 for ; Mon, 1 Sep 2003 18:34:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19txDt-0008Ui-RE for v6ops-data@psg.com; Mon, 01 Sep 2003 22:32:33 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19txBJ-0007ik-RQ for v6ops@ops.ietf.org; Mon, 01 Sep 2003 22:29:54 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19txBJ-0008MC-9T for v6ops@ops.ietf.org; Mon, 01 Sep 2003 15:29:53 -0700 Message-ID: <3F536833.4020304@nal.motlabs.com> MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 01 Sep 2003 17:39:31 +0200 From: Alexandru Petrescu To: Pekka Savola Cc: Soliman Hesham , Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: Re: [mobile-ip] RE: Comments on draft-tsirtsis-dsmip-problem-01.txt X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Pekka Savola wrote: >>> If you wanted a tunnel setup protocol, you would not need MIP in >>> the first place, just dynamic VPN mechanism. >> >> => Like what ?? MIP sets up tunnels dynamically between the MN and >> HA (v4 and v6) and any-to-any (MIPv6 RO). > > > If you just wanted MN<->HA communication, all you would need is a VPN > which updates your care-of address to the HA regularly. RO is the > thing that sets it apart. I would not call MIPv6 RO a tunnel, and it > is not parcticularly useful in this context as the transport is > heavily IPv6-specific. Sorry for interfering, me too risking to trivialize and loose sight, I would summarize Mobile IPv6 behaviour as dynamic tunnel setup and RO and also proxy ND. With respect to dual-stacks, the thing I'd like to have is the Mobile IPv6 MN-HA tunnel to be a v6-in-v4 tunnel instead of v6-in-v6, and moreover that tunnel to drill through the NAT gateway, and even stay up when applications are silent (heartbeats bubbling or such). This would allow an IPv6 mobile host to attach to an exclusively-v4 public-access-private-address ISP, and then to another, while maintaining a fixed IPv6 Home Address. By my reading, the draft already covers this case, so I don't complain. Alex GBU From owner-v6ops@ops.ietf.org Mon Sep 1 18:34:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15181 for ; Mon, 1 Sep 2003 18:34:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19txAU-0007I9-Gc for v6ops-data@psg.com; Mon, 01 Sep 2003 22:29:02 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19tx9a-0007De-S2 for v6ops@ops.ietf.org; Mon, 01 Sep 2003 22:28:07 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19tx9a-0008LA-1I for v6ops@ops.ietf.org; Mon, 01 Sep 2003 15:28:06 -0700 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502582091@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain From: "Wijnen, Bert (Bert)" To: "'radiusext@ops.ietf.org'" Cc: v6ops@ops.ietf.org Subject: Potential MIB work? Date: Mon, 1 Sep 2003 15:53:04 +0200 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >From draft-ietf-v6ops-ipv4survey-ops-02.txt: 7.3.20 RADIUS MIB (RFC 2618) The problems have not been addressed and a new MIB should be defined. 7.3.21 RADIUS Authentication Server MIB (RFC 2619) The problems have not been addressed and a new MIB should be defined. There is more detail in the survey document itself. So if a RADIUSEXT WG is formed, do we want to at least evaluate these? Thanks, Bert From owner-v6ops@ops.ietf.org Mon Sep 1 18:35:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15197 for ; Mon, 1 Sep 2003 18:35:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tx9v-0007Fz-BW for v6ops-data@psg.com; Mon, 01 Sep 2003 22:28:27 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19tx9P-0007DK-NQ for v6ops@ops.ietf.org; Mon, 01 Sep 2003 22:27:55 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19tx9O-0008L3-Uc for v6ops@ops.ietf.org; Mon, 01 Sep 2003 15:27:55 -0700 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502582092@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Wijnen, Bert (Bert)" To: vrrp@ietf.org Cc: v6ops@ops.ietf.org Subject: MIB work Date: Mon, 1 Sep 2003 15:53:04 +0200 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pls take a look (and comment if needed) on draft-ietf-v6ops-ipv4survey-ops-02.txt A few snippets ... snip .. 5.099 RFC 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol As stated in the Overview section: Since the VRRP protocol is intended for use with IPv4 routers only, this MIB uses the SYNTAX for IP addresses which is specific to IPv4. Thus, changes will be required for this MIB to interoperate in an IPv6 environment. ... snip ... 7.3.27 VRRP MIB (RFC 2787) The problems have not been addressed and a new MIB should be defined. .. snip .. I have told them that you are working on it, but you may want to keep an eye on the survey doc as well. Thanks, Bert From owner-v6ops@ops.ietf.org Mon Sep 1 18:35:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15217 for ; Mon, 1 Sep 2003 18:35:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19txFK-0009ZT-KY for v6ops-data@psg.com; Mon, 01 Sep 2003 22:34:02 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19txED-0008iD-55 for v6ops@ops.ietf.org; Mon, 01 Sep 2003 22:32:53 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19txEC-0008Mj-MG for v6ops@ops.ietf.org; Mon, 01 Sep 2003 15:32:52 -0700 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502331462@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain From: "Wijnen, Bert (Bert)" To: "'C. M. Heard'" , v6ops@ops.ietf.org Cc: ops-area@ops.ietf.org Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments Date: Mon, 1 Sep 2003 20:20:51 +0200 X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > | 5.033 RFC 2013 SNMPv2 Management Information Base for the User > > > | Datagram Protocol using SMIv2 (MIB-UDP) > > > > > > s/MIB-UDP/UDP-MIB/ > > > > > > | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in > > > | the note reproduced below: > > > > > > s/OIDs/object definitions/ > > > > > > | IESG Note: > > > | > > > | The IP, UDP, and TCP MIB modules currently support only IPv4. These > > > | three modules use the IpAddress type defined as an OCTET STRING of > > > | length 4 to represent the IPv4 32-bit internet addresses. (See RFC > > > | 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 > > > | internet addresses. > > > | > > Might want to add another editors note that RFC1902 has been obsoleted > > by RFC2578 (STD 58) in the meantime. > > > > Would it make sense to mention that IPv6 WG is working on this? > > (In fact they are getting close to deliver a replacement document > > I believe). > > Hmm, I think that might be a distraction here. My understanding is > that the authors intended for this section only to report the "raw > data" ... all the analysis is in Section 7. And the text in that > section (with the proposed edits) does address both of those points. > This same comment applies also for RFCs 2011, 2012, and 2096. > Yep I saw that later. And indeed your remarks make sense now. Thanks for clarifying and elaborating. So you can ignore those hints to add ptrs about work-in-progress and such in sect 5. And same for some other similar comments from my side. Bert From owner-v6ops@ops.ietf.org Tue Sep 2 14:20:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23345 for ; Tue, 2 Sep 2003 14:20:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFfM-0007H0-Kq for v6ops-data@psg.com; Tue, 02 Sep 2003 18:14:08 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.22) id 19uFYY-0006Uw-Hk for v6ops@ops.ietf.org; Tue, 02 Sep 2003 18:07:06 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h82E2n426557 for ; Tue, 2 Sep 2003 17:02:49 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 17:02:49 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 17:02:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] Date: Tue, 2 Sep 2003 17:00:31 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A8E@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment (fwd) Thread-Index: AcNg11xpYOFzBwG9SoyFkeB+44tULwQgClog From: To: , Cc: X-OriginalArrivalTime: 02 Sep 2003 14:02:49.0048 (UTC) FILETIME=[E4769D80:01C3715A] X-Spam-Status: No, hits=1.1 required=5.0 tests=BAYES_30,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, ok, this is the last issue I have not yet commented on the list. The = comment sent by Pekka was about "IPv6 in IPv4" tunneling performed in = the UEs. Pekka does not want to require or recommend the implementation = of any automatic (or configured) tunneling methods in the UEs. = Justification for that: high number of IPv6-capable UEs, implementation = footprint of UE's is expected to be small, upgradeability of UE's is = poor and we are concerned about 3GPP *deployment* not early trials or = piloting in this document. Quite a long discussion followed including = 3GPP architecture, different PDP context types, roaming (which has not = been discussed so much in our document, anyway, 3GPP roaming is = happening at layer 2, not IP layer), etc. I must say that I agree on many points above - I do not believe that = tunneling in the UE is a scalable solution for a very large number of = terminals. What this section in our document tries to explain, is how to = solve such a situation when the operator does not support IPv6 in its = network (GGSN / SGSN / HLR is/are lacking IPv6 support) and the UE = (user) wants to access IPv6 services. And in that case you MAY use = tunneling in the UE to get IPv6 service. The recommended (longer term) approach for this problem is that the = operators deploy basic IPv6 support in their 3GPP networks (can in most = cases be done by making a sw upgrades) - and we must convince them to do = that as soon as possible! What do you think, could that be one key = recommendation in our document? Karim also commented that the soon = starting IMS period also makes basic IPv6 support reality in 3GPP = networks. And it removes the need for tunneling to be done in the UEs. So, could I get more wg comments / discussion on this issue, please!? = How should we mention UE based tunneling in this document, or should we = not mention it at all? The current text is: "However, the UE may attach to a 3GPP network, in which the Serving GPRS = Support Node (SGSN), the GGSN and the Home Location Register (HLR) = support IPv4 PDP contexts by default, but may not support IPv6 PDP = contexts. If the 3GPP network does not support IPv6 PDP contexts, and an = application on the UE needs to communicate with an IPv6(-only) node, the = UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 = packets using a tunneling mechanism. This might happen in very early = phases of IPv6 deployment, or in IPv6 demonstrations and trials. The UE may be assigned a private or public IPv4 address when the IPv4 = PDP context has been activated, although it is more likely that it will = receive a private address (due to the lack of public IPv4 addresses). = The use of private IPv4 addresses in the UE depends on the support of = these addresses by the tunneling mechanism and the deployment scenario. = In some cases, public IPv4 addresses are required (one example is 6to4 = [RFC3056]), but if the tunnel endpoints are in the same private domain = or the tunneling mechanism works through IPv4 NAT (Network Address = Translator), private IPv4 addresses can be used (examples are [ISATAP] = and [TEREDO]). In general, if tunneling from the host is needed, ISATAP = and 6to4 are preferred and TEREDO is a mechanism of last resort when = neither of these are applicable. One deployment scenario example is using a laptop computer and a UMTS UE = as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop = computer and an IPv4 PDP context is activated. Although "IPv6 in IPv4" = tunneling can be either automatic or configured (by the user), the first = alternative is favored, because it is expected that most UE users just = want to use an application in their UE; they might not even care, = whether the network connection is IPv4 or IPv6." BR, -Juha- -----Original Message----- From: ext Karim El-Malki (HF/EAB) [mailto:karim.el-malki@ericsson.com] Sent: 12 August, 2003 16:36 To: 'Pekka Savola' Cc: 'v6ops@ops.ietf.org' Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment (fwd) > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > > > Or let me phrase this differently: > > > > >=20 > > > > > Would roaming with 3GPP UE work if the roaming agreements=20 > > > > > would include=20 > > > > > an indication whether the foreign network=20 > supports the same=20 > > > > > PDP context=20 > > > > > types as the original network. > > > > >=20 > > > > > I.e. the user can prefer those roaming partners which=20 > > > > > provide the services=20 > > > > > they want. That should be enough of an economic incentive. > > > >=20 > > > > Basically the UE won't know until it tries to activate > > > > a v6 connection and it gets refused. > > >=20 > > > This seems like a potentially fatal design flaw. > >=20 > > When I plug into Ethernet or WLAN I don't know if the network > > supports IPv6 until I get an RA.=20 >=20 > Very true, but the expectations are entirely different (or=20 > that's my take=20 > at least). When I use my laptop and roam in the world, I generally=20 > *DON'T* expect IPv6 to be available. Hence, I'm equipped=20 > with some useful=20 > tools to enable IPv6 in the case network doesn't support it=20 > (e.g. 6to4 or=20 > configured tunnels). >=20 > However, I think the expectation with 3GPP is entirely=20 > different: network=20 > supports IPv6, period. (And it would be unreasonable to=20 > assume the huge=20 > number of 3GPP devices to implement all the possible=20 > mechanisms required=20 > in every possible network scenario, be it 3GPP or regular=20 > old-fashioned=20 > Internet.) To be precise it's 3GPP IMS services that support IPv6. I hope this will get all operators to support IPv6 for the obvious reasons such as peer-to-peer connectivity. However it is a different thing to expect any 3GPP network in general to support IPv6 from day one. In fact there are commercial 3GPP operators today (WCDMA and GSM) whose networks do not support IPv6. Also, all I have been saying is to recommend support for at least one type of tunnelling in this case. ISATAP does what is needed IMO, so you don't need to support every possible mechanism.=20 > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6=20 > > > support in=20 > > > remote SGSN's/GGSN's be avoided ? > >=20 > > You could do that, but it would be an overkill IMO to run PPP > > over wireless. Since we're dealing with an expensive bandwidth > > limited link it's not an attractive alternative. >=20 > I think it would be useful to try to analyze the overhead of=20 > PPP in this > scenario. It might not be that high, and it might only be=20 > the fallback > solution where other mechanisms (i.e. finding an operator which would > support IPv6, or refraining from using IPv6) would not work. That would be asking for equipment to support IPv4, IPv6 and PPP to cater for a case which we hope will be rare. I would definitely limit it to IPv4 and IPv6 so that people would have to tunnel for the special cases and operators would have an incentive to migrate to native IPv6. PPP will not solve the problem in a clean way and will be a disincentive to migrate to native IPv6. > > For example today operators have gprs (IPv4) roaming agreements > > with certain operators and only voice with others.=20 >=20 > Do you know if there is a regional perspective to this? =20 > That is, if there=20 > are multiple potential roaming partners in an area, could=20 > you say that=20 > they often support different capabilities? > If they support different capabilties, it might be easier to=20 > conclude that=20 > it's reasonable to expect some of them to support IPv6=20 > (while some others=20 > wouldn't) -- and then cycling through roaming partners until=20 > finding a=20 > correct might be a thinkable approach. Personally I wouldn't see why an operator would want to limit its market to certain type of services in a certain area. From what I know the above cannot be taken as a rule. I don't think I would design a standard based on a single business model anyway. > > If you're in this special case (which will hopefully become > > rare in future) and you want to have a way of using IPv6 services > > then tunnelling is an attractive solution. >=20 > What I'm looking for is a way or two to work around that=20 > requirement; I=20 > would loath to see a requirement to implement tunneing=20 > solutions on mobile=20 > terminals to make the service work in areas where the 3GPP operator=20 > doesn't suddenly support IPv6. >=20 > I think we should try to ways to leverage 3GPP network's=20 > capabilities to=20 > ensure that either: >=20 > 1) the user is able to obtain IPv6 PDP context somehow;=20 > this is an issue=20 > when roaming to some other operator's network. Whether from=20 > that operator=20 > or by trying someone else doesn't matter. >=20 > 2) the user is able to work around the issue by requesting PPP PDP > context until the roaming partner supports IPv6 >=20 > 3) the user is able to stick to just using IPv4 when=20 > roaming in a network=20 > where there are no ways at all to get IPv6 using any means. Number 1) is unworkable as I've explained before. There are also = business issues that will make it useless in many cases (i.e. there is only one data roaming partner which is common today). Number 2) isn't = workable either. You're not going to convince operators to get support for PPP (which is normally not there today) only because they need IPv6; they = would get native IPv6 directly. Tunnelling is fine as a migration tool and = we've tested it. It's the only feasible choice and it will lead to a migration to native IPv6. /Karim From owner-v6ops@ops.ietf.org Tue Sep 2 14:23:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23869 for ; Tue, 2 Sep 2003 14:23:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFZf-0006e9-Ji for v6ops-data@psg.com; Tue, 02 Sep 2003 18:08:15 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19uFTp-000622-Di for v6ops@ops.ietf.org; Tue, 02 Sep 2003 18:02:13 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h82I2Bu29093; Tue, 2 Sep 2003 11:02:11 -0700 X-mProtect: <200309021802> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdICNtxt; Tue, 02 Sep 2003 11:02:10 PDT Message-ID: <3F54DD57.9020803@iprg.nokia.com> Date: Tue, 02 Sep 2003 11:11:35 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Follen, Stephen" CC: v6ops@ops.ietf.org Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 References: <05829C8A6277594395457B34D6A3A6DD2840BB@MAANDMBX2.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Follen, Stephen wrote: >On one hand, yes, this would be a packet being filtered, >suggesting that it should be dropped silently; > >however, the "filter" here is not something purposely set >up by a system admin - its not a firewall or similar. >The filtering here is happening because of the >incomplete configuration of a tunnel - more like a >broken link, where a DU would be appropriate. > If the decapsulator (and filtering node) B sends the DU as an IPv6/IPv4 encapsulated packet to A who was the encapsulator of the original packet, it should be OK *provided* the IPv6 dst of the DU (which is the same as the IPv6 src of the original packet) is one of A's IPv6 addresses. Otherwise, A might forward the DU onward to some unsuspecting node C, i.e., if the IPv6 src of the original packet was spoofed. >I'm not sure about the security issues, hopefully >someone more qualified in that area can chime in here... > I think it might be nice for A to learn that B is dropping the packets due to ingress filtering, but I don't see a way to send a DU that is guaranteed to stop at A and not be forwarded onward to some unsuspecting node C. Do you? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Sep 2 14:55:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26704 for ; Tue, 2 Sep 2003 14:55:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uGF3-000Bgm-UW for v6ops-data@psg.com; Tue, 02 Sep 2003 18:51:01 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 19uFMZ-0005P9-E2 for v6ops@ops.ietf.org; Tue, 02 Sep 2003 17:54:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14826; Tue, 2 Sep 2003 12:59:42 -0400 (EDT) Message-Id: <200309021659.MAA14826@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-intro-03.txt Date: Tue, 02 Sep 2003 12:59:42 -0400 X-Spam-Status: No, hits=2.9 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME, RCVD_IN_OSIRUSOFT_COM,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@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 IPv6 Operations Working Group of the IETF. Title : Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-intro-03.txt Pages : 0 Date : 2003-9-2 This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in currently deployed IETF documented standards. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which type of RFCs that has been documented, and a concatenated summary of results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-v6ops-ipv4survey-intro-03.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-v6ops-ipv4survey-intro-03.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: <2003-9-2100313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-2100313.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Sep 2 15:04:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27576 for ; Tue, 2 Sep 2003 15:04:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uGG4-000Bmt-7B for v6ops-data@psg.com; Tue, 02 Sep 2003 18:52:04 +0000 Received: from [12.25.1.120] (helo=ctron-dnm.enterasys.com) by psg.com with esmtp (Exim 4.22) id 19uGDT-000BX2-D7 for v6ops@ops.ietf.org; Tue, 02 Sep 2003 18:49:23 +0000 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA27765 for ; Tue, 2 Sep 2003 09:26:54 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xmaa27568; Tue, 2 Sep 03 09:26:09 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Tue, 02 Sep 2003 09:26:03 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Sep 2003 09:26:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Subject: RE: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 Date: Tue, 2 Sep 2003 09:26:02 -0400 Message-ID: <05829C8A6277594395457B34D6A3A6DD2840BB@MAANDMBX2.ets.enterasys.com> Thread-Topic: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 Thread-Index: AcNua8N+YkKlUoTGT+2TjEbqlQ1wdQC55/OA From: "Follen, Stephen" To: "Fred Templin" Cc: X-OriginalArrivalTime: 02 Sep 2003 13:26:02.0783 (UTC) FILETIME=[C16D4AF0:01C37155] X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On one hand, yes, this would be a packet being filtered, suggesting that it should be dropped silently; however, the "filter" here is not something purposely set up by a system admin - its not a firewall or similar. The filtering here is happening because of the incomplete configuration of a tunnel - more like a broken link, where a DU would be appropriate. I'm not sure about the security issues, hopefully someone more qualified in that area can chime in here...=20 =20 -----Original Message----- From: Fred Templin [mailto:ftemplin@iprg.nokia.com]=20 Sent: Friday, August 29, 2003 4:35 PM To: Follen, Stephen Cc: v6ops@ops.ietf.org Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 On further consideration, isn't the situation here logically equivalent=20 to the case of the filter occurring somewhere in the network between the IPv6=20 source and the tunnel decapsulator; for example, at a firewall? What do=20 firewalls do when they discard a packet due to filtering? I don't know this for=20 certain, but don't they simply do a silent discard w/no ICMP sent back to the source? In any event, I don't see why the tunnel decapsulator should do anything different. Your thoughts? Fred ftemplin@iprg.nokia.com P.S. I could be wrong, but wouldn't sending back an ICMP DU run the risk of a reflection attack when the original packet uses a spoofed IPv6=20 source address? Follen, Stephen wrote: > A question related to Ingress Filtering of decapsulated [tunneled] > IPv6-in-IPv4 packets: > =20 > Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that > "... a decapsulated packet MUST NOT be forwarded unless the node has=20 > been explicitly configured to forward such packets ..." and in section > 4.3 "The decapsulating node MUST verify that the tunnel source address > is acceptable before forwarding decapsulated packets ..." > (the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6=20 > Transition Mechanisms provides similar guidance in sections 3.6, 3.9=20 > and 4.1) > =20 > The question is what to do in the case that the packets are filtered > / not forwarded: > =20 > 1. silently drop the packet - simple, but provides no feedback of the > "broken link" (see below); > =20 > 2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a > poor approach since > (a) the IPv4 [tunnel endpoint] address was reached and > (b) a response may never get back to the originating IPv6 host > (section 3.4 of RFC 2893 indicates that an encapsulating node=20 > MAY generate > a v6 ICMP when it gets a v4 ICMP back); > =20 > 3. send a v6 ICMP DU - this probably won't get back to the originating > host either since > its unlikely that there's a path back to it (the do not forward=20 > decision occurred because > the tunnel was not set up); > =20 > 4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information > in the incoming > IPv6-in-IPv4 packet to generate this, and it would likely get back > to the originating host, > but to do so would effectively send a packet via a tunnel which=20 > had not been configured. > =20 > "broken link" - [in the case of legitimate traffic] the filtering > which would occur here is not > the result of a specifically configured ingress filter, rather, it is=20 > the result of not fully configuring > the tunnel; a tunnel is effectively a link, so I see the filtering to=20 > be similar to a broken link. > =20 > Any thoughts would be greatly appreciated. - Thank you > =20 > Steve Follen > sfollen@enterasys.com > =20 > =20 > =20 > =20 From owner-v6ops@ops.ietf.org Tue Sep 2 15:11:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28525 for ; Tue, 2 Sep 2003 15:11:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uGIT-000C0P-UN for v6ops-data@psg.com; Tue, 02 Sep 2003 18:54:33 +0000 Received: from [12.25.1.120] (helo=ctron-dnm.enterasys.com) by psg.com with esmtp (Exim 4.22) id 19uGBH-000BHY-Tp for v6ops@ops.ietf.org; Tue, 02 Sep 2003 18:47:08 +0000 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA25146 for ; Tue, 2 Sep 2003 14:47:14 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma025135; Tue, 2 Sep 03 14:46:19 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Tue, 02 Sep 2003 14:46:11 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Sep 2003 14:46:11 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 Date: Tue, 2 Sep 2003 14:46:10 -0400 Message-ID: <05829C8A6277594395457B34D6A3A6DD2840BD@MAANDMBX2.ets.enterasys.com> Thread-Topic: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 Thread-Index: AcNxfG+lEnF+ifcQS2qmi12VJYbHMAAA4k6Q From: "Follen, Stephen" To: "Fred Templin" Cc: X-OriginalArrivalTime: 02 Sep 2003 18:46:11.0361 (UTC) FILETIME=[7AA1B110:01C37182] X-Spam-Status: No, hits=0.4 required=5.0 tests=EMAIL_ATTRIBUTION,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Fred Templin wrote: >If the decapsulator (and filtering node) B sends the DU as an IPv6/IPv4 encapsulated packet to A >who was the encapsulator of the original packet, it should be OK *provided* the IPv6 dst of the DU >(which is the same as the IPv6 src of the original packet) is one of A's IPv6 addresses.=20 >Otherwise, A might forward the DU onward to some unsuspecting node C, i.e., if the IPv6 src of the >original packet was spoofed. >I think it might be nice for A to learn that B is dropping the packets due to ingress filtering, >but I don't see a way to send a DU that is guaranteed to stop at A and not be forwarded onward to >some unsuspecting node C. Do you? You have a point here. No, I don't see a way to protect "unsuspecting node C". (If node A were a router encapsulating IPv6 traffic, you would actually want it to forward the decapsulated DU back to the originating host [for legitimate traffic] ). Perhaps the draft should direct that ingress filtered packets be silently dropped ? From owner-v6ops@ops.ietf.org Wed Sep 3 07:40:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25922 for ; Wed, 3 Sep 2003 07:40:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uVsb-0009fj-3V for v6ops-data@psg.com; Wed, 03 Sep 2003 11:32:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19uVs1-0009cw-JI; Wed, 03 Sep 2003 11:32:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h83BV2O18020; Wed, 3 Sep 2003 14:31:02 +0300 Date: Wed, 3 Sep 2003 14:31:02 +0300 (EEST) From: Pekka Savola To: "C. M. Heard" cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for a *very* extensive review of the ops document. I'll try to respond to your points somehow inline.. I've included all of your comments which may need addressing in the quote, so that it's easier for the document editor to go through the spec. Three generic comments: 1) (now) HISTORIC documents being included. Unfortunately, the survey was executed in a non-optimal method, and these historic statements still appear here, due to examining the RFC's in the "vacuum". (The best way to do the analysis in the first place would have been to skip those which have been obsoleted, made historic, etc., but we lack the time machine.. :-) I'd like to go through this with a "minimum update" policy, and we state that the document is historic in section 7. Unless there is strong feeling that we should really throw away these historic documents completely (implies that we should look at which documents made them historic, replacement documents etc.), I'd keep them here for now. 1.b) new RFC's since about RFC3200 (in most part, obsoleting or making historic those that are still analyzed) have not been taken into consideration. The analysis was Phil's work, who has retired. We don't have resources anymore to do more substantial work anymore, so we prefer to keep doing minimum updates. 2) protocol/specification. I totally agree that we should refer the RFC's by "specification" because that's generic enough to cover any RFC. 3) MIB acronyms like TRANS-MIB in: 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) (TRANS-MIB) .. these do not appear in the original RFC's, but are invented by RFC-editor for some RFC indexes. My opinion is that we should get rid of these bogus abbreviations completely, but I would also be OK with it if they're changed to be correct. Whatever works for you.. On Sun, 31 Aug 2003, C. M. Heard wrote: [...] > In general, this draft is on the right track, and the author/editor > deserve much thanks for all the work they put in to create the > document, but in my opinion there are quite a few minor issues that > need to be resolved before it is published. Comments are inserted > in-line with the text of the draft, which is indicated by a vertical > bar in the left margin. Proposed replacement text is has no > vertical bar but is always indented relative to the commentary. > > | 2.0 Document Organization > | > | The document is organized as described below: > | > | Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, > | and Proposed Standards, and Experimental RFCs. Each RFC is discussed in > | its turn starting with RFC 1 and ending with RFC 3247. The comments for > | each RFC is "raw" in nature. That is, each RFC is discussed in a > | vacuum and problems or issues discussed do not "look ahead" to see if > | the problems have already been fixed. > | > | Section 7 is an analysis of the data presented in Sections 3, 4, 5, and > | 6. It is here that all of the results are considered as a whole and the > | problems that have been resolved in later RFCs are correlated. > > There are some important technical specifications that do not fall into > any of these classifications. For instance, RFC 1215, which is part of > the (obsolescent) SMIv1 specification, is an Informational RFC. And RFC > 3584 (the coexistence document that replaces RFC 2576) is a BCP. I'm > not aware of any other such specs, but some may exist. Certainly it > behooves us to include at least those two in the survey. One possible > way to handle RFC 1215 would be to include it in Sections 3 and 7 along > with its companion SMIv1 documents (RFCs 1155 and 1212). I'm not really > sure what to do for RFC 3584; maybe a separate section for BCPs would be > appropriate. One thing for sure, it would not be a good idea to lump > all non-standards-track stuff (BCP + informational + experimental) > together. The problem here is that it would be difficult for *us* (read: those non-experts in the subject matter) to decide what is relevant and what is not. The analysis was already done by Phil, and we don't have resources to extend it. But I think we can address this situation in practical terms. Where applicable, add notions about these documents in the "analysis", section 7, like: 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 2576) There are no real issues that can be resolved. ==> add a sentence like: The document is obsoleted by RFC 3584. (or something else, if RFC3584 addresses the concerns) .. that way, we could have somekind of a "forward pointer" even to informational/BCP documents which may be relevant. Would this satisfy your concern? If so, could you submit some wording that would be appropriate for these cases? > | 3.0 Full Standards > | > | Full Internet Standards (most commonly simply referred to as > | "Standards") are fully mature protocol specification that are widely > | implemented and used throughout the Internet. > | > | > | 3.1 RFC 1157 Simple Network Management Protocol > | > | Beginning in Section 3.2.6.3.2 atTable Object Type Names thru the rest > | of Section 3 there are numerous references to the use of IPv4 addresses > | as part of OIDs. > | > | Section 4. Protocol Specification specifies the format of an SNMP > | packet which uses the overall format of: > | > | RFC1157-SNMP DEFINITIONS ::= BEGIN > | IMPORTS > | ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks > | FROM RFC1155-SMI; > | > | > | Section 4.1.3.1. Example of Table Traversal has many uses of IPv4 > | addresses in its example of table transversal. > | > | Section 5. Definitions reiterates the use of IPv4 addresses. > | > | RFC1157-SNMP DEFINITIONS ::= BEGIN > | > | IMPORTS > | ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks > | FROM RFC1155-SMI; > > As previously noted by Juergen Schoenwaelder, RFC 1157 is HISTORIC > (i.e., is no longer an Internet Standard) and should therefore be > excluded from the survey. see the generic comment 1) I'd like to go through this with a "minimum update" policy, and we state that the document is historic in section 7. Is that good enough? > | 3.2 RFC 1155 Structure of Management Information > | > | Section 3.2.3.2. IpAddress defines the following: > | > | This application-wide type represents a 32-bit internet address. It > | is represented as an OCTET STRING of length 4, in network byte-order. > | > | There are several instances of the use of this definition in the rest of > | the document. > > There should also be a subsection for RFC 1212, and perhaps also RFC > 1215, since RFCs 1155 and 1212 form STD 16, and together with RFC > 1215 define SMIv1. We could add here a sentence like: Note that RFC 1212 and RFC 1215, which have been omitted from analysis, together with this specification define SMIv1. The same issues apply to all of them. would that be OK? Another piece of text? (I'm purposely trying to "wave away" the need for formal analysis sections..) > | 3.3 RFC 1213 Management Information Base > | > | There are far too many instances of IPv4 addresses is this document > | to enumerate here. Clearly the entire IP OID sub tree is rife with > | IPv4 dependencies. A new sub tree needs to be defined to deal with > | IPv6 addresses leaving the current sub tree intact for IPv4 address > | information. > > The above paragraph contains the first of many instances where the > term "OID" is misused. It is an abbreviation meaning "object > identifier," and is NOT the same thing as an object definition, a > textual convention, or any SMI construct other than an object > identifier. I am sorry to be so picky but I find this abuse of > terminology really annoying, and I'll be asking that it be fixed > everywhere I see it below. In addition, it is useful for the sake > of later analysis to identify the problems in this MIB module a > little more concretely. Here is the proposed rewrite: > > There are far too many instances of IPv4 addresses is this document > to enumerate here. The particular object groups that are affected > are the IP group, the ICMP group, the TCP group, the UDP group, > and the EGP group. Seems reasonable, thanks. (The reason why OID was misused was probably just because the original author was not enough aware of the terminology.. which is why we're bugging YOU about it :-) > | 3.4 RFC 1643 Definitions of Managed Objects for the Ethernet-like > | Interface Types > | > | There are no IPv4 dependencies in this specification. > > In the recent protocol action which elevated the following documents > to Proposed Standard: > > o draft-ietf-hubmib-etherif-mib-v3-03.txt > o draft-ietf-hubmib-mau-mib-v3-04.txt > o draft-ietf-hubmib-wis-mib-07.txt > > the IESG also approved the following as an informational RFC: > > o draft-ietf-hubmib-1643-to-historic-01.txt > > and reclassified RFC 1643 to HISTORIC as it recommends. I therefore > suggest that RFC 1643 be dropped from this survey. Due to the way survey is done, I'd like to keep it as is (minimum changes), we could add a sentence like: Moreover, RFC 1643 has been superseded by other MIBs and reclassified to HISTORIC. If that's what you'd prefer? > | 3.5 RFC 2578 Structure of Management Information Version 2 (SMIv2) > | > | Section 7.1.5. IpAddress defines: > > Rewrite the above sentence as: > > Section 7.1.5 defines the IpAddress data type: OK. > | The IpAddress type represents a 32-bit internet address. It is > | represented as an OCTET STRING of length 4, in network byte-order. > | > | Note that the IpAddress type is a tagged type for historical reasons. > | Network addresses should be represented using an invocation of the > | TEXTUAL-CONVENTION macro. > | > | Note the deprecated status of this type; see RFC 3291 for details on > | TEXTUAL-CONVENTION macro. > > Rewrite the last sentence as: > > Note the deprecated status of this type; see RFC 3291 for details on > the replacement TEXTUAL-CONVENTION definitions. OK. > | 3.6 RFC 2579 Textual Conventions for SMIv2 > | > | There are no IPv4 dependencies in this specification. > > There is no mention of RFC 2580 (which is also an OPS Area Internet > Standard). I don't think there are any IPv4 dependencies in RFC 2580, > but it should be mentioned here for sake of completeness. It's PS, so I guess it should be included, with like: 3.6 RFC 2580 Conformance Statements for SMIv2 There are no IPv4 dependencies in this specification. .. if you agree that that is a true statement? > | 3.7 RFC 2819 Remote Network Monitoring Management Information Base > | (RMON-MIB) > | > | There are no IPv4 dependencies in this specification. > > RFCs 3411, 3412, 3413, 3414, and 3415 are also Internet Standards; > they replace RFCs 2571, 2572, 2573, 2574, and 2575. Please move > the sections for those last five RFCs here and update the RFC numbers. I don't think the editor should have moved RFC3416 etc. here in the first place, but as it has already been done, I see no harm doing the same for those five other RFCs either. > | 3.8 RFC 3416 Protocol Operations for Version 2 of the Simple Network > | Management Protocol (SNMPv2) (OPS-MIB) > > Remove "(OPS-MIB)" ... the mnemonic is misleading, as this document > does not contain a MIB module. See also the note below. Yep, it should be removed, in this case. > | Section 4.2.2.1. Example of Table Traversal and Section 4.2.3.1. > | Another Example of Table Traversal both use OID's from MIB2 whose > | data contains IPv4 addresses. Other than their use in these example > | sections there are no IPv4 dependencies in this specification. > > Please correct this usage error: s/OID's/objects/ OK. > | 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network > | Management Protocol (SNMPv2) (TRANS-MIB) > > NOTE: I would like to suggest that it is more useful in the case > of standards that contain a single MIB module to use the MIB module > names instead of the sometimes strange and seldom-used mnemonics > that are listed in STD 1, Official Internet Protocol Standards. > I will be making this suggestion for each spec that contains a > single MIB module; in the present case the change would be: > > s/TRANS-MIB/SNMPv2-TM/ I do not know why those (TRANS-MIB)'s are there in the first place, but in case there is a strong reason to keep them there, I vote for removing them completely. What we want is that the title here is identical with the RFC title. My suggestion: remove all of (*-MIB) from the document. Would that be good for you? > | Section 2 Definitions contains the following OID definition: > > Please correct this usage error: s/OID definition/definition/ > (a TEXTUAL-CONVENTION is not an OID)/ OK. > | SnmpUDPAddress ::= TEXTUAL-CONVENTION > | DISPLAY-HINT "1d.1d.1d.1d/2d" > | STATUS current > | DESCRIPTION > | "Represents a UDP address: > | > | octets contents encoding > | 1-4 IP-address network-byte order > | 5-6 UDP-port network-byte order > | " > | SYNTAX OCTET STRING (SIZE (6)) > | > | Section 8.1. Usage Example also contains examples which use IPv4 > | address, but it has no significance in the operation of the > | specification. > > Wordsmith the last paragraph: > > Section 8.1, "Usage Example," also contains examples which uses IPv4 > addresse, but it has no significance in the operation of the > specification. There is typo above, but in practice OK. s/IPv4 addresse/an IPv4 address/ ? > | 4.01 RFC 1493 Definitions of Managed Objects for Bridges (BRIDGE-MIB) > | > | There are no IPv4 dependencies in this specification. > | > | > | 4.02 RFC 1559 DECnet Phase IV MIB Extensions (DECNET-MIB) > > s/DECNET-MIB/DECNET-PHIV-MIB/ > > | There are no IPv4 dependencies in this specification. > | > | > | 4.03 RFC 1657 Definitions of Managed Objects for the Fourth > | Version of the Border Gateway Protocol (BGP-4) using SMIv2 (BGP-4-MIB) > > s/BGP-4-MIB/BGP4-MIB/ suggest removal of the acronyms. > | The MIB defined in this RFC deals with objects in a BGP4 based routing > | system and therefore contain many objects that are limited by the > | IpAddress 32-bit value defined in MIB2. Clearly the values of this MIB > | are limited to IPv4 addresses. No update is needed, although a new MIB > | should be defined for BGP++ to allow management of IPv6 addresses and > | routes. > | > | > | 4.04 RFC 1658 Definitions of Managed Objects for Character Stream > | Devices using SMIv2 > | > | There are no IPv4 dependencies in this specification. > | > | > | 4.05 RFC 1659 Definitions of Managed Objects for RS-232-like Hardware > | Devices using SMIv2 > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 4.06 RFC 1660 Definitions of Managed Objects for Parallel-printer-like > | Hardware Devices using SMIv2 > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ good catch * 2 > | 4.07 RFC 1694 Definitions of Managed Objects for SMDS Interfaces using > | SMIv2 (SIP-MIB) > | > | This MIB definition defines the following subtree: > > s/MIB/MIB module/ ok. > | ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 } > | > | -- Although the objects in this group are read-only, at the > | -- agent's discretion they may be made read-write so that the > | -- management station, when appropriately authorized, may > | -- change the addressing information related to the > | -- configuration of a logical IP subnetwork implemented on > | -- top of SMDS. > | > | -- This table is necessary to support RFC1209 (IP-over-SMDS) > | -- and gives information on the Group Addresses and ARP > | -- Addresses used in the Logical IP subnetwork. > | -- One SMDS address may be associated with multiple IP > | -- addresses. One SNI may be associated with multiple LISs. > | > | ipOverSMDSTable OBJECT-TYPE > | SYNTAX SEQUENCE OF IpOverSMDSEntry > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The table of addressing information relevant to > | this entity's IP addresses." > | ::= { ipOverSMDS 1 } > | > | ipOverSMDSEntry OBJECT-TYPE > | SYNTAX IpOverSMDSEntry > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The addressing information for one of this > | entity's IP addresses." > | INDEX { ipOverSMDSIndex, ipOverSMDSAddress } > | ::= { ipOverSMDSTable 1 } > | > | IpOverSMDSEntry ::= > | SEQUENCE { > | ipOverSMDSIndex IfIndex, > | ipOverSMDSAddress IpAddress, > | ipOverSMDSHA SMDSAddress, > | ipOverSMDSLISGA SMDSAddress, > | ipOverSMDSARPReq SMDSAddress > | } > | > | ipOverSMDSIndex OBJECT-TYPE > | SYNTAX IfIndex > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The value of this object identifies the > | interface for which this entry contains management > | information. " > | ::= { ipOverSMDSEntry 1 } > | > | ipOverSMDSAddress OBJECT-TYPE > | SYNTAX IpAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The IP address to which this entry's addressing > | information pertains." > | ::= { ipOverSMDSEntry 2 } > | > | ipOverSMDSHA OBJECT-TYPE > | SYNTAX SMDSAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The SMDS Individual address of the IP station." > | ::= { ipOverSMDSEntry 3 } > | > | ipOverSMDSLISGA OBJECT-TYPE > | SYNTAX SMDSAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The SMDS Group Address that has been configured > | to identify the SMDS Subscriber-Network Interfaces > | (SNIs) of all members of the Logical IP Subnetwork > | (LIS) connected to the network supporting SMDS." > | ::= { ipOverSMDSEntry 4 } > | > | ipOverSMDSARPReq OBJECT-TYPE > | SYNTAX SMDSAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The SMDS address (individual or group) to which > | ARP Requests are to be sent." > | ::= { ipOverSMDSEntry 5 } > | > | > | Although these OIDs are intended for IPv4 addresses, a similar MIB > | can be defined for IPv6 addressing. > > s/these OIDs/these object definitions/ ok. > | 4.08 RFC 1724 RIP Version 2 MIB Extension (RIP2-MIB) > > s/RIP2-MIB/RIPv2-MIB/ suggest remove altogether? > | As might be expected, this RFC is filled with IPv4 dependencies since > | it defines a MIB for an IPv4 only routing protocol. A new MIB for RIPng > | is required. > > s/a MIB/a MIB module/ > s/IPv4 only/IPv4-only/ ok. > | 4.09 RFC 1748 IEEE 802.5 MIB using SMIv2 (802.5-MIB) > > s/802.5-MIB/TOKENRING-MIB/ > > | There are no IPv4 dependencies in this specification. > | > | > | 4.10 RFC 1850 OSPF Version 2 Management Information Base (OSPF-MIB) > | > | This MIB defines managed objects for OSPFv2 which is a protocol used > | to exchange IPv4 routing information. Since OSPFv2 is limited to IPv4 > | addresses a new MIB is required to support a new version of OSPF that > | is IPv6 aware. > | > | > | 4.11 RFC 2115 Management Information Base for Frame Relay DTEs > | Using SMIv2 (FRAME-MIB) > > s/FRAME-MIB/FRAME-RELAY-DTE-MIB/ suggest remove * 2 > | This MIB has several examples of mapping IPv4 addresses to multiple > | Frame Relay DLCI's and monitoring their connections. A new set of OID's > | needs to be defined to allow this functionality for IPv6. > > The last sentence is incorrect: there are NO IPv4 dependencies in the > actual MIB objects, only in some explanatory text describing how > table entries in the MIB module might relate to entries in MIB-II's > ipAddrTable. This relationship is expressed by ifIndex values, not by > IP address values. Ergo, rewrite: > > This specification has several examples of how IPv4 addresses might be > mapped to Frame Relay DLCIs. Other than those examples there are no > IPv4 dependencies in this specification. Ok, one can remove section 7.2.6 too then: 7.2.6 Frame Relay MIB (RFC 2115) The problem has been fixed in RFC 2954, Definitions of Managed Objects for Frame Relay Service. > | 4.12 RFC 2571 An Architecture for Describing SNMP Management Frameworks > | (ARCH-SNMP) > | > | There are no IPv4 dependencies in this specification. > > This document has been replaced by RFC 3411, which is an Internet > Standard (see note above), so this sub-section needs to be retitled > and moved into Section 3. > > | 4.13 RFC 2572 Message Processing and Dispatching for the Simple Network > | Management Protocol (SNMP) (MPD-SNMP) > | > | There are no IPv4 dependencies in this specification. > > This document has been replaced by RFC 3412, which is an Internet > Standard (see note above), so this sub-section needs to be retitled > and moved into Section 3. > > | 4.14 RFC 2573 SNMP Applications (SNMP-APP) > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > This document has been replaced by RFC 3413, which is an Internet > Standard (see note above), so this sub-section needs to be retitled > and moved into Section 3. > > | 4.15 RFC 2574 User-based Security Model (USM) for version 3 of the > | Simple Network Management Protocol (SNMPv3) (USM-SNMPV3) > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > This document has been replaced by RFC 3414, which is an Internet > Standard (see note above), so this sub-section needs to be retitled > and moved into Section 3. > > | 4.16 RFC 2575 View-based Access Control Model (VACM) for the Simple > | Network Management Protocol (SNMP) (VACM-SNMP) > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > This document has been replaced by RFC 3415, which is an Internet > Standard (see note above), so this sub-section needs to be retitled > and moved into Section 3. Ok for all of these (even though I disagree a bit with this approach). > | 4.17 RFC 2790 Host Resources MIB > | > | There are no IPv4 dependencies in this specification. > | > | > | 4.18 RFC 2863 The Interfaces Group MIB (INTERGRMIB) > > s/INTERGRMIB/IF-MIB/ remove? > | There are no IPv4 dependencies in this specification. There is some > | discussion in one OID about an interface performing a self test, but it > | is IP version independent. > > s/OID/object definition/ > s/it/the object itself/ ok > | 5.0 Proposed Standards > | > | Proposed Standards are introductory level documents. There are no > | requirements for even a single implementation. In many cases Proposed > | are never implemented or advanced in the IETF standards process. They > | therefore are often just proposed ideas that are presented to the > | Internet community. Sometimes flaws are exposed or they are one of > | many competing solutions to problems. In these later cases, no > | discussion is presented as it would not serve the purpose of this > | discussion. > | > | > | 5.001 RFC 1239 Reassignment of experimental MIBs to standard MIBs > | (STD-MIBs) > | > | There are no IPv4 dependencies in this specification. > | > | > | 5.002 RFC 1269 Definitions of Managed Objects for the Border Gateway > | Protocol: Version 3 (BGP-MIB) > > s/BGP-MIB/RFC1269-MIB/ > > | The use of BGP3 has been deprecated and is not discussed. > | > | > | 5.003 RFC 1285 FDDI Management Information Base (FDDI-MIB) > > s/FDDI-MIB/RFC1285-MIB/ > > | There are no IPv4 dependencies in this specification. > | > | > | 5.004 RFC 1381 SNMP MIB Extension for X.25 LAPB (SNMP-LAPB) > > s/SNMP-LAPB/RFC1381-MIB/ > > | There are no IPv4 dependencies in this specification. > | > | > | 5.005 RFC 1382 SNMP MIB Extension for the X.25 Packet Layer (SNMP-X.25) > > s/SNMP-X.25/RFC1382-MIB/ > > | There are no IPv4 dependencies in this specification. > | > | > | 5.006 RFC 1414 Identification MIB (IDENT-MIB) > > s/IDENT-MIB/RFC1414-MIB/ suggest removal of *-MIB text for all of these, as above > | There are no IPv4 dependencies in this specification. > | > | > | 5.007 RFC 1418 SNMP over OSI (SNMP-OSI) > | > | There are no IPv4 dependencies in this protocol. > | > | > | 5.008 RFC 1419 SNMP over AppleTalk (SNMP-AT) > | > | There are no IPv4 dependencies in this protocol. > | > | > | 5.009 RFC 1420 SNMP over IPX (SNMP-IPX) > | > | There are no IPv4 dependencies in this protocol. > | > | > | 5.010 RFC 1441 Introduction to version 2 of the Internet-standard > | Network Management Framework (SNMPv2) > | > | There are no IPv4 dependencies in this protocol. > > This document is HISTORIC and should be removed from the survey > (otherwise, I'd say s/protocol/specification/) I'd rather keep it in, if you prefer, just stating something like: Moreover, the document has been reclassied HISTORIC. > | 5.011 RFC 1461 SNMP MIB extension for Multiprotocol Interconnect > | over X.25 (X25-MIB) > > s/X25-MIB/MIOX25-MIB/ remove? > | The following OIDs are defined in Section 4 "Definitions": > > s/OIDs/objects/ ok. > | mioxPleLastFailedEnAddr OBJECT-TYPE > | SYNTAX OCTET STRING (SIZE(2..128)) > | ACCESS read-only > | STATUS mandatory > | DESCRIPTION > | "The last Encapsulated address that failed > | to find a corresponding X.121 address and > | caused mioxPleEnAddrToX121LkupFlrs to be > | incremented. The first octet of this object > | contains the encapsulation type, the > | remaining octets contain the address of that > | type that failed. Thus for an IP address, > | the length will be five octets, the first > | octet will contain 204 (hex CC), and the > | last four octets will contain the IP > | address. For a snap encapsulation, the > | first byte would be 128 (hex 80) and the > | rest of the octet string would have the snap > | header." > | ::= { mioxPleEntry 4 } > | > | mioxPeerEnAddr OBJECT-TYPE > | SYNTAX OCTET STRING (SIZE (0..128)) > | ACCESS read-write > | STATUS mandatory > | DESCRIPTION > | "The Encapsulation address of the remote > | host mapped by this table entry. A length > | of zero indicates the remote IP address is > | unknown or unspecified for use as a PLE > | default. > | > | The first octet of this object contains the > | encapsulation type, the remaining octets > | contain an address of that type. Thus for > | an IP address, the length will be five > | octets, the first octet will contain 204 > | (hex CC), and the last four octets will > | contain the IP address. For a snap > | encapsulation, the first byte would be 128 > | (hex 80) and the rest of the octet string > | would have the snap header." > | DEFVAL { ''h } > | ::= { mioxPeerEntry 7 } > | > | mioxPeerEncType OBJECT-TYPE > | SYNTAX INTEGER (0..256) > | ACCESS read-write > | STATUS mandatory > | DESCRIPTION > | "The value of the encapsulation type. For > | IP encapsulation this will have a value of > | 204 (hex CC). For SNAP encapsulated > | packets, this will have a value of 128 (hex > | 80). For CLNP, ISO 8473, this will have a > | value of 129 (hex 81). For ES-ES, ISO 9542, > | this will have a value of 130 (hex 82). A > | value of 197 (hex C5) identifies the Blacker > | X.25 encapsulation. A value of 0, > | identifies the Null encapsulation. > | > | This value can only be written when the > | mioxPeerStatus object with the same > | mioxPeerIndex has a value of underCreation. > | Setting this object to a value of 256 > | deletes the entry. When deleting an entry, > | all other entries in the mioxPeerEncTable > | with the same mioxPeerIndex and with an > | mioxPeerEncIndex higher then the deleted > | entry, will all have their mioxPeerEncIndex > | values decremented by one." > | ::= { mioxPeerEncEntry 2 } > | > | Updated values of the first byte of these OID's can be defined to > | support IPv6 addresses. > > s/OID's/objects/ ok > | 5.012 RFC 1471 The Definitions of Managed Objects for the Link > | Control Protocol of the Point-to-Point Protocol (PPP/LCPMIB) > > s?PPP/LCPMIB?PPP-LCP-MIB? > > | There are no IPv4 dependencies in this specification. > | > | > | 5.013 RFC 1472 The Definitions of Managed Objects for the Security > | Protocols of the Point-to-Point Protocol (PPP/SECMIB) > > s?PPP/SECMIB?PPP-SEC-MIB? > > | There are no IPv4 dependencies in this specification. > | > | > | 5.014 RFC 1473 The Definitions of Managed Objects for the IP Network > | Control Protocol of the Point-to-Point Protocol (PPP/IPMIB) > > s?PPP/IPMIB?PPP-IP-NCP-MIB? remove * 2 ? > | Every OID in the MIB contain IPv4 addresses. A new MIB must be defined > | for OIDs for similar IPv6 addresses. > > The general idea is right, but this is not accurate as written. > Here is the proposed replacement text: > > This MIB module is targeted specifically at IPv4 over PPP. A new > MIB moduld would need to be defined to support IPv6 over PPP. > > Note that the problem is not IPv4 vs. IPv6 addresses per se, but > rather IPCP (PPP IPv4 Control Protocol) vs. IPV6CP (PPP IPv6 > Control Protocol). See RFC 2472 and citations therein for more > details. ok. > | 5.015 RFC 1474 The Definitions of Managed Objects for the Bridge > | Network Control Protocol of the Point-to-Point Protocol > | (PPP/Bridge) > > s?PPP/BRIDGE?PPP-BRIDGE-NCP-MIB? > > | There are no IPv4 dependencies in this specification. > | > | > | 5.016 RFC 1512 FDDI Management Information Base (FDDI-MIB) > > s/FDDI-MIB/FDDI-SMT73-MIB/ remove * 2 ? > | There are no IPv4 dependencies in this specification. > | > | > | 5.017 RFC 1513 Token Ring Extensions to the Remote Network > | Monitoring MIB > | > | There are no IPv4 dependencies in this specification. > | > | > | 5.018 RFC 1515 Definitions of Managed Objects for IEEE 802.3 > | Medium Attachment Units (MAUs) > | > | There are no IPv4 dependencies in this protocol. > > This specification will soon be officially obsoleted by > draft-ietf-hubmib-mau-mib-v3-04.txt, which will also > replace RFC 2668. Since draft-ietf-hubmib-mau-mib-v3-04.txt > is in the RFC Editor's queue as we speak, I think it would > be reasonable to drop RFC 1515 from the survey. Note that > it actually should have been obsoleted by RFC 2668 but was > not, owing to an oversight. (s/protocol/specification/ -- Andreas, please check that this is OK everywhere!) I suggest keeping it for now, but if you prefer, adding something like: Moreover, this document has been Obsoleted. > | 5.019 RFC 1525 Definitions of Managed Objects for Source Routing > | Bridges (SRB-MIB) > > s/SRB-MIB/SOURCE-ROUTING-MIB/ remove ? > | There are no IPv4 dependencies in this specification. > > Regarding these sections: > > | 5.020 RFC 1611 DNS Server MIB Extensions (DNS-S-MIB) > ... > | 5.021 RFC 1612 DNS Resolver MIB Extensions (DNS-R-MIB) > ... > > As Juergen Schoenwaelder has pointed out, RFCs 1611 and 1612 > have been declared HISTORIC and should be dropped from the > survey. (Once a document has been declared HISTORIC, it is > no longer a standard of any kind.) Yeah, I would hope Phil would have known that when he made his analysis :-( I think we should keep these here (for consistency), but if you prefer, cut the unnecessary text out and just say something like: 5.021 RFC 1612 DNS Resolver MIB Extensions There are multiple IPv4 dependencies in this specification. (and not waste paper in going into details when we say in section 7 that it's historic..) > | 5.022 RFC 1628 UPS Management Information Base (UPS-MIB) > | > | There are no IPv4 dependencies in this specification. > | > | > | 5.023 RFC 1666 Definitions of Managed Objects for SNA NAUs > | using SMIv2 SNANAU-MIB > > s/SNANAU-MIB/(SNA-NAU-MIB) > > | There are no IPv4 dependencies in this specification. > | > | 5.024 RFC 1696 Modem Management Information Base (MIB) using SMIv2 > | MODEM-MIB > > s/MODEM-MIB/(Modem-MIB)/ > > | There are no IPv4 dependencies in this specification. > | > | > | 5.025 RFC 1697 Relational Database Management System (RDBMS) > | Management Information Base (MIB) using SMIv2 RDBMS-MIB > > s/RDBMS-MIB/(RDBMS-MIB)/ > > | There are no IPv4 dependencies in this specification. > | > | > | 5.026 RFC 1742 AppleTalk Management Information Base II (AT-MIB) > > s/AT-MIB/APPLETALK-MIB/ suggest removing *-MIB (for all)? > | The following OIDs are defined: > > s/OIDs/objects/ ok > | KipEntry ::= SEQUENCE { > | kipNetStart ATNetworkNumber, > | kipNetEnd ATNetworkNumber, > | kipNextHop IpAddress, > | kipHopCount INTEGER, > | kipBCastAddr IpAddress, > | kipCore INTEGER, > | kipType INTEGER, > | kipState INTEGER, > | kipShare INTEGER, > | kipFrom IpAddress > | } > | > | kipNextHop OBJECT-TYPE > | SYNTAX IpAddress > | ACCESS read-write > | STATUS mandatory > | DESCRIPTION > | "The IP address of the next hop in the route to this > | entry's destination network." > | ::= { kipEntry 3 } > | > | kipBCastAddr OBJECT-TYPE > | SYNTAX IpAddress > | ACCESS read-write > | STATUS mandatory > | DESCRIPTION > | "The form of the IP address used to broadcast on this > | network." > | ::= { kipEntry 5 } > | > | kipFrom OBJECT-TYPE > | SYNTAX IpAddress > | ACCESS read-only > | STATUS mandatory > | DESCRIPTION > | "The IP address from which the routing entry was > | learned via the AA protocol. If this entry was not > | created via the AA protocol, it should contain IP > | address 0.0.0.0." > | ::= { kipEntry 10 } > | > | > | 5.027 RFC 1747 Definitions of Managed Objects for SNA Data Link > | Control (SDLC) using SMIv2 SDLCSMIv2 > > s/SDLCSMIv2/(SNA-SDLC-MIB)/ remove ? > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification right. > | 5.028 RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2 > | 802.5-SSR > > s/802.5-SSR/(TOKENRING-STATION-SR-MIB)/ > > | There are no IPv4 dependencies in this specification. > | > | > | 5.029 RFC 1759 Printer MIB (Print-MIB) > > s/Print-MIB/Printer-MIB/ remove ? > | There are no IPv4 dependencies in this specification. > > Note: this document is slated to be replaced someday "soon" by > . When you issue an update > of this draft, check the status of RFC 1759 to see if it has > been replaced. Ok, one could add, if you prefer, something like: Moreover, this specification is being Obsoleted. > | 5.030 RFC 2006 The Definitions of Managed Objects for IP Mobility > | Support using SMIv2 (MOBILEIPMI) > > s/MOBILEIPMI/MIP-MIB/ > > | This document defines a MIB for the Mobile IPv4 documents described > | immediately above. Without enumeration, let it be stated that a new > | MIB for IPv6 Mobility is required. > | > | > | 5.031 RFC 2011 SNMPv2 Management Information Base for the Internet > | Protocol using SMIv2 (MIB-IP) > > s/MIB-IP/IP-MIB/ suggest remove x 2 ? > | Approximately 1/3 of the OIDs defined in this document are clearly > | IPv4 dependent. A new MIB for IPv6 OIDs is required. > > Rewrite as follows: > > Approximately 1/3 of the objects defined in this document are > IPv4-dependent. New objects need to be defined to support IPv6. Ok. > | 5.032 RFC 2012 SNMPv2 Management Information Base for the > | Transmission Control Protocol using SMIv2 (MIB-TCP) > > s/MIB-TCP/TCP-MIB/ remove ? > | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in > | the note reproduced below: > > s/OIDs/object definitions/ ok. > | IESG Note: > | > | The IP, UDP, and TCP MIB modules currently support only IPv4. These > | three modules use the IpAddress type defined as an OCTET STRING of > | length 4 to represent the IPv4 32-bit internet addresses. (See RFC > | 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 > | internet addresses. > | > | > | 5.033 RFC 2013 SNMPv2 Management Information Base for the User > | Datagram Protocol using SMIv2 (MIB-UDP) > > s/MIB-UDP/UDP-MIB/ remove ? > | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in > | the note reproduced below: > > s/OIDs/object definitions/ ok > | IESG Note: > | > | The IP, UDP, and TCP MIB modules currently support only IPv4. These > | three modules use the IpAddress type defined as an OCTET STRING of > | length 4 to represent the IPv4 32-bit internet addresses. (See RFC > | 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 > | internet addresses. > | > | > | 5.034 RFC 2020 IEEE 802.12 Interface MIB (802.12-MIB) > > s/802.12-MIB/DOT12-IF-MIB/ remove ? > Note: the actual title is "Definitions of Managed Objects for > IEEE 802.12 Interfaces" ... I've not been checking this; does > it matter? we should use the correct title, I think. > | There are no IPv4 dependencies in this specification. > | > | > | 5.035 RFC 2021 Remote Network Monitoring Management Information Base > | Version 2 using SMIv2 (RMON-MIB) > > s/RMON-MIB/RMON2-MIB/ remove ? > | The following OIDs are defined: > > s/OIDs/objects/ ok > | addressMapNetworkAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The network address for this relation. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the protocolDirLocalIndex component of the > | index. > | > | For example, if the protocolDirLocalIndex indicates an > | encapsulation of ip, this object is encoded as a length > | octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { addressMapEntry 2 } > | > | nlHostAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The network address for this nlHostEntry. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the protocolDirLocalIndex component of the index. > | > | For example, if the protocolDirLocalIndex indicates an > | encapsulation of ip, this object is encoded as a length > | octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { nlHostEntry 2 } > | > | nlMatrixSDSourceAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The network source address for this nlMatrixSDEntry. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the protocolDirLocalIndex component of the index. > | > | For example, if the protocolDirLocalIndex indicates an > | encapsulation of ip, this object is encoded as a length > | octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { nlMatrixSDEntry 2 } > | > | nlMatrixSDDestAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The network destination address for this > | nlMatrixSDEntry. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the protocolDirLocalIndex component of the index. > | > | For example, if the protocolDirLocalIndex indicates an > | encapsulation of ip, this object is encoded as a length > | octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { nlMatrixSDEntry 3 } > | > | nlMatrixDSSourceAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The network source address for this nlMatrixDSEntry. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the protocolDirLocalIndex component of the index. > | > | For example, if the protocolDirLocalIndex indicates an > | encapsulation of ip, this object is encoded as a length > | octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { nlMatrixDSEntry 2 } > | > | nlMatrixDSDestAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION > | "The network destination address for this > | nlMatrixDSEntry. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the protocolDirLocalIndex component of the index. > | > | For example, if the protocolDirLocalIndex indicates an > | encapsulation of ip, this object is encoded as a length > | octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { nlMatrixDSEntry 3 } > | > | nlMatrixTopNSourceAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The network layer address of the source host in this > | conversation. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the associated nlMatrixTopNProtocolDirLocalIndex. > | > | For example, if the protocolDirLocalIndex indicates an > | encapsulation of ip, this object is encoded as a length > | octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { nlMatrixTopNEntry 3 } > | > | nlMatrixTopNDestAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The network layer address of the destination host in this > | conversation. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the associated nlMatrixTopNProtocolDirLocalIndex. > | > | For example, if the nlMatrixTopNProtocolDirLocalIndex > | indicates an encapsulation of ip, this object is encoded as a > | length octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { nlMatrixTopNEntry 4 } > | > | alMatrixTopNSourceAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The network layer address of the source host in this > | conversation. > | This is represented as an octet string with > | specific semantics and length as identified > | by the associated alMatrixTopNProtocolDirLocalIndex. > | > | For example, if the alMatrixTopNProtocolDirLocalIndex > | indicates an encapsulation of ip, this object is encoded as a > | length octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { alMatrixTopNEntry 3 } > | > | alMatrixTopNDestAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The network layer address of the destination host in this > | conversation. > | > | This is represented as an octet string with > | specific semantics and length as identified > | by the associated alMatrixTopNProtocolDirLocalIndex. > | > | For example, if the alMatrixTopNProtocolDirLocalIndex > | indicates an encapsulation of ip, this object is encoded as a > | length octet of 4, followed by the 4 octets of the ip address, > | in network byte order." > | ::= { alMatrixTopNEntry 4 } > | > | trapDestProtocol OBJECT-TYPE > | SYNTAX INTEGER { > | ip(1), > | ipx(2) > | } > | MAX-ACCESS read-create > | STATUS current > | DESCRIPTION > | "The protocol with which to send this trap." > | ::= { trapDestEntry 3 } > | > | trapDestAddress OBJECT-TYPE > | SYNTAX OCTET STRING > | MAX-ACCESS read-create > | STATUS current > | DESCRIPTION > | "The address to send traps on behalf of this entry. > | > | If the associated trapDestProtocol object is equal to ip(1), > | the encoding of this object is the same as the snmpUDPAddress > | textual convention in [RFC1906]: > | -- for a SnmpUDPAddress of length 6: > | -- > | -- octets contents encoding > | -- 1-4 IP-address network-byte order > | -- 5-6 UDP-port network-byte order > | > | If the associated trapDestProtocol object is equal to ipx(2), > | the encoding of this object is the same as the snmpIPXAddress > | textual convention in [RFC1906]: > | -- for a SnmpIPXAddress of length 12: > | -- > | -- octets contents encoding > | -- 1-4 network-number network-byte order > | -- 5-10 physical-address network-byte order > | -- 11-12 socket-number network-byte order > | > | This object may not be modified if the associated > | trapDestStatus object is equal to active(1)." > | ::= { trapDestEntry 4 } > | > | All of the OIDs above (except trapDestProtocol) imply IPv4 addresses > | but since they use a SYNTAX of OCTET STRING, they should work fine > | for IPv6 addresses. A new legitimate value of trapDestProtocol (i.e. > | SYNTAX addition of ipv6(3) should make this specification IPv6 > | functional. > > s/OIDs/object definitions/ > s/imply IPv4 addresses/mention only IPv4 addresses,/ > s/IPv6 functional./functional for IPv6./ ok > | 5.036 RFC 2024 Definitions of Managed Objects for Data Link Switching > | using SMIv2 (DLSW-MIB) > | > | The following OIDs are defined: > > s/OIDs/textual conventions/ ok > | TAddress ::= TEXTUAL-CONVENTION > | STATUS current > | DESCRIPTION > | "Denotes a transport service address. > | For dlswTCPDomain, a TAddress is 4 octets long, > | containing the IP-address in network-byte order." > | SYNTAX OCTET STRING (SIZE (0..255)) > | > | -- DLSw over TCP > | dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 } > | -- for an IP address of length 4: > | -- > | -- octets contents encoding > | -- 1-4 IP-address network-byte order > | -- > | DlswTCPAddress ::= TEXTUAL-CONVENTION > | DISPLAY-HINT "1d.1d.1d.1d" > | STATUS current > | DESCRIPTION > | "Represents the IP address of a DLSw which uses > | TCP as a transport protocol." > | SYNTAX OCTET STRING (SIZE (4)) > | > | Additionally there are many OIDs that use a SYNTAX of TAddress within > | the document. Interestingly the SYNTAX for TAddress is an OCTET > | string of up to 256 characters. It could easily accommodate a similar > | hybrid format for IPv6 addresses. > > above: s/OIDs/object definitions/ ok > | A new OID to enhance functionality for DlswTCPAddress can be added > | to support IPv6 addresses. > > above: s/OID/textual convention/, s/can/could/ ok > | 5.037 RFC 2051 Definitions of Managed Objects for APPC using SMIv2 > | (SNANAU-APP) > > s/SNANAU-APP/APPC-MIB/ remove ? > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.038 RFC 2096 IP Forwarding Table MIB (TABLE-MIB) > > s/TABLE-MIB/IP-FORWARD-MIB/ remove? > | This MIB defines many OIDs that are IPv4 dependent. It is expected > | that another MIB for similar IPv6 addresses will be developed. > > Rewrite the last paragraph: > > The MIB module's main conceptual table ipCidrRouteTable uses IPv4 > addresses as index objects and is therefore incapbable of > representing an IPv6 forwarding information base. A new > conceptual table needs to be defined to support IPv6 addresses. ok s/incapbable/incapable/ > | 5.039 RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater > | Devices using SMIv2 802 (3-MIB) > > s/3-MIB/SNMP-REPEATER-MIB/ remove ? > | There are no IPv4 dependencies in this specification. > | > | > | 5.040 RFC 2127 ISDN Management Information Base using SMIv2 > | (ISDN-MIB) > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.041 RFC 2128 Dial Control Management Information Base using > | SMIv2 (DC-MIB) > > s/DC-MIB/DIAL-CONTROL-MIB/ remove ? > | There are no IPv4 dependencies in this specification. > | > | > | 5.042 RFC 2206 RSVP Management Information Base using SMIv2 > | (RSVP-MIB) > | > | All OIDs in this MIB have options for both IPv4 and IPv6. There > | are no IPv4 dependencies in this specification. > > s/All OIDs/All of the relevant object definitions/ ok > | 5.043 RFC 2213 Integrated Services Management Information > | Base using SMIv2 > | > | This MIB is IPv6 aware and therefore there are no IPv4 > | dependencies in this specification. > | > | > | 5.044 RFC 2214 Integrated Services Management Information > | Base Guaranteed Service Extensions using SMIv2 > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.045 RFC 2232 Definitions of Managed Objects for DLUR using > | SMIv2 (DLUR-MIB) > > s/DLUR-MIB/APPN-DLUR-MIB/ remove ? > | There are no IPv4 dependencies in this specification. > | > | > | 5.046 RFC 2238 Definitions of Managed Objects for HPR using > | SMIv2 (HPR-MIB) > | > | There are no IPv4 dependencies in this specification. > | > | > | 5.047 RFC 2266 Definitions of Managed Objects for IEEE 802.12 > | Repeater Devices > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.048 RFC 2287 Definitions of System-Level Managed Objects for > | Applications (SLM-APP) > > s/SLM-APP/SYSAPPL-MIB/ remove ? > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.049 RFC 2320 Definitions of Managed Objects for Classical IP > | and ARP Over ATM Using SMIv2 (IPOA-MIB) (IPOA-MIB) > > Remove the second occurrence of "(IPOA-MIB)" ok, or remove both ;-) > | This MIB is wholly dependent of IPv4. A new MIB for IPv6 is > | required to provide the same functionality > | > | > | 5.050 RFC 2417 Definitions of Managed Objects for Multicast > | over UNI 3.0/3.1 based ATM Networks > | > | There are many OIDs defined in this MIB which are IPv4 only. A > | similar MIB for IPv6 OIDs should be created. > > Rewrite, by stealing from previous section: > > This MIB is wholly dependent of IPv4. A new MIB for IPv6 is > required to provide the same functionality ok > | 5.051 RFC 2452 IP Version 6 Management Information Base for the > | Transmission Control Protocol > | > | This RFC documents an IPv6 MIB and is not considered in this > | discussion. > > s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ ok > | 5.052 RFC 2454 IP Version 6 Management Information Base for > | the User Datagram Protocol > | > | This RFC documents an IPv6 MIB and is not considered in this > | discussion. > > s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ ok > | 5.053 RFC 2455 Definitions of Managed Objects for APPN > | (APPN-MIB) > | > | There are no IPv4 dependencies in this specification. > | > | > | 5.054 RFC 2456 Definitions of Managed Objects for APPN TRAPS > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.055 RFC 2457 Definitions of Managed Objects for Extended Border > | Node (EBN-MIB) > | > | There are no IPv4 dependencies in this specification. > | > | > | 5.056 RFC 2465 Management Information Base for IP Version 6: > | Textual Conventions and General Group > | > | This RFC documents an IPv6 MIB and is not considered in this > | discussion. > > s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ ok > | 5.057 RFC 2466 Management Information Base for IP Version 6: > | ICMPv6 Group (ICMPv6-MIB) > > s/ICMPv6-MIB/IPV6-ICMP-MIB/ remove ? > | This RFC documents an IPv6 MIB and is not considered in this > | discussion. > > s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ ok > | 5.058 RFC 2493 Textual Conventions for MIB Modules Using > | Performance History Based on 15 Minute Intervals > | > | There are no IPv4 dependencies in this specification. > > Note: this document is due to be replaced by RFC 3593, > which will be a Draft Standard and will have the same title. > > | 5.059 RFC 2494 Definitions of Managed Objects for the DS0 > | and DS0 Bundle Interface Type > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.060 RFC 2495 Definitions of Managed Objects for the DS1 E1 > | DS2 and E2 Interface Types > > s/DS1 E1/DS1, E1,/ > > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok for all of the above > | 5.061 RFC 2496 Definitions of Managed Object for the DS3/E3 > | Interface Type (DS3-E3-MIB) > > s/(DS3-E3-MIB)/(DS3-MIB)/ remove ? > | There are no IPv4 dependencies in this specification. > > s/protocol/specification/ > > | 5.062 RFC 2512 Accounting Information for ATM Networks > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.063 RFC 2513 Managed Objects for Controlling the Collection > | and Storage of Accounting Information for Connection- > | Oriented Networks > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok for both > | 5.064 RFC 2514 Definitions of Textual Conventions and > | OBJECT-IDENTITIES for ATM Management (ATM-TC-OID) > > s/ATM-TC-OID/ATM-TC-MIB/ remove ? > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.065 RFC 2515 Definitions of Managed Objects for ATM > | Management (ATM-MIBMAN) > > s/ATM-MIBMAN/ATM-MIB/ remove? > | This MIB defines the following OIDs: > > s/OIDs/objects/ ok > | AtmInterfaceConfEntry ::= SEQUENCE { > | atmInterfaceMaxVpcs INTEGER, > | atmInterfaceMaxVccs INTEGER, > | atmInterfaceConfVpcs INTEGER, > | atmInterfaceConfVccs INTEGER, > | atmInterfaceMaxActiveVpiBits INTEGER, > | atmInterfaceMaxActiveVciBits INTEGER, > | atmInterfaceIlmiVpi AtmVpIdentifier, > | atmInterfaceIlmiVci AtmVcIdentifier, > | atmInterfaceAddressType INTEGER, > | atmInterfaceAdminAddress AtmAddr, > | atmInterfaceMyNeighborIpAddress IpAddress, > | atmInterfaceMyNeighborIfName DisplayString, > | atmInterfaceCurrentMaxVpiBits INTEGER, > | atmInterfaceCurrentMaxVciBits INTEGER, > | atmInterfaceSubscrAddress AtmAddr > | } > | > | atmInterfaceMyNeighborIpAddress OBJECT-TYPE > | SYNTAX IpAddress > | MAX-ACCESS read-write > | STATUS current > | DESCRIPTION > | "The IP address of the neighbor system connected to > | the far end of this interface, to which a Network > | Management Station can send SNMP messages, as IP > | datagrams sent to UDP port 161, in order to access > | network management information concerning the > | operation of that system. Note that the value > | of this object may be obtained in different ways, > | e.g., by manual configuration, or through ILMI > | interaction with the neighbor system." > | ::= { atmInterfaceConfEntry 11 } > | > | atmInterfaceConfGroup2 OBJECT-GROUP > | OBJECTS { > | atmInterfaceMaxVpcs, atmInterfaceMaxVccs, > | atmInterfaceConfVpcs, atmInterfaceConfVccs, > | atmInterfaceMaxActiveVpiBits, > | atmInterfaceMaxActiveVciBits, > | atmInterfaceIlmiVpi, > | atmInterfaceIlmiVci, > | atmInterfaceMyNeighborIpAddress, > | atmInterfaceMyNeighborIfName, > | atmInterfaceCurrentMaxVpiBits, > | atmInterfaceCurrentMaxVciBits, > | atmInterfaceSubscrAddress } > | STATUS current > | DESCRIPTION > | "A collection of objects providing configuration > | information about an ATM interface." > | ::= { atmMIBGroups 10 } > | > | > | Clearly a subsequent MIB must define equivalent IPv6 OIDs. > > s/subsequent MIB/subsequent revision of this MIB module/ > s/OIDs/objects/ > s/must/should/ ok > | 5.066 RFC 2558 Definitions of Managed Objects for the SONET/SDH > | Interface Type > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > Note: this document is due to be replaced by RFC 3592, > which will be a Draft Standard and will have the title > "Definitions of Managed Objects for the Synchronous > Optical Network/Synchronous Digital Hierarchy (SONET/SDH) > Interface Type" If you prefer, we could add something like: Moreover, the document is obsoleted by RFC 3592. (or even move up to the draft standards if you really, really want) > | 5.067 RFC 2561 Base Definitions of Managed Objects for TN3270E > | Using SMIv2 > | > | The document states: > | > | The MIB defined by this memo supports use of both IPv4 and IPv6 > | addressing. > | > | This specification is both IPv4 and IPv6 aware. > | > | > | 5.068 RFC 2562 Definitions of Protocol and Managed Objects for > | TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) > | (TN2370E-RT) > > remove "(TN3270E-RT)" at the end remove both ? :-) > | Several OIDs rely on imports from RFC 2561 and therefore the > | protocol is both IPv4 and IPv6 aware. > > rewrite: > > This MIB module inherits IP version-independence by virtue of > importing the appropriate definitions from RFC 2561. ok > | 5.069 RFC 2564 Application Management MIB (APP-MIB) > > s/APP-MIB/APPLICATION-MIB/ rem ? > | The following OID is defined: > > s/OID/textual convention/ ok > | ApplTAddress ::= TEXTUAL-CONVENTION > | STATUS current > | DESCRIPTION > | "Denotes a transport service address. > | > | For snmpUDPDomain, an ApplTAddress is 6 octets long, > | the initial 4 octets containing the IP-address in > | network-byte order and the last 2 containing the UDP > | port in network-byte order. Consult 'Transport Mappings > | for Version 2 of the Simple Network Management Protocol > | (SNMPv2)' for further information on snmpUDPDomain." > | SYNTAX OCTET STRING (SIZE (0..255)) > | > | > | A new OID should be defined to handle IPv6 addresses. > > s/OID/TC/ > > | 5.070 RFC 2576 Coexistence between Version 1 Version 2 and Version > | 3 of the Internet-standard Network Management Framework (SNMP) > > remove "(SNMP)" ok for both > | This document states: > | > | (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST > | be changed to IpAddress. Note that the use of NetworkAddress in > | new MIB documents is strongly discouraged (in fact, new MIB > | documents should be written using SMIv2, which does not define > | NetworkAddress). > | > | and defines the OID: > > s/OID/object/ ok > | snmpTrapAddress OBJECT-TYPE > | SYNTAX IpAddress > | MAX-ACCESS accessible-for-notify > | STATUS current > | DESCRIPTION > | "The value of the agent-addr field of a Trap PDU which > | is forwarded by a proxy forwarder application using > | an SNMP version other than SNMPv1. The value of this > | object SHOULD contain the value of the agent-addr field > | from the original Trap PDU as generated by an SNMPv1 > | agent." > | ::= { snmpCommunityMIBObjects 3 } > | > | This clearly points out a lack of IPv6 awareness in this specification. > > That last sentence is incorrect. The presence of this stuff > is not because the specification has a lack of IPv6 awareness; > it is there because it is necessary to allow a MIB translator > or a proxy forwarder to do its job ... and that job is to allow > legacy versions of the SNMP (SNMPv1 and SNMPv2c, both now Historic > protocols) to coexist with SNMPv3. I think Randy Presuhn has > complained about this before. Here is the suggested replacement: > > Since purpose of this document is to describe how legacy > specifications with IPv4 dependencies (SMIv1, SNMPv1, and > SNMPv2c) can coexist with current ones (SMIv2 and SNMPv3), > the IPv4 dependencies documented above are acceptable and, > indeed, unavoidable. > > In addition, note that RFC 2576 has been replaced by RFC 3584, > which is a BCP. So the title needs to changed, and sub-section > itself needs to be moved. ok > | 5.071 RFC 2564 Application Management MIB (APP-MIB) > | > | The following OID is defined: > | > | ApplTAddress ::= TEXTUAL-CONVENTION > | STATUS current > | DESCRIPTION > | "Denotes a transport service address. > | > | For snmpUDPDomain, an ApplTAddress is 6 octets long, > | the initial 4 octets containing the IP-address in > | network-byte order and the last 2 containing the UDP > | port in network-byte order. Consult 'Transport Mappings > | for Version 2 of the Simple Network Management Protocol > | (SNMPv2)' for further information on snmpUDPDomain." > | SYNTAX OCTET STRING (SIZE (0..255)) > | > | > | A new OID should be defined to handle IPv6 addresses. > > This sub-section is a duplicate of 5.069 and should be removed. good catch > | 5.072 RFC 2576 Coexistence between Version 1 Version 2 and Version > | 3 of the Internet-standard Network Management Framework (SNMP) > | > | This document states: > | > | (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST > | be changed to IpAddress. Note that the use of NetworkAddress in > | new MIB documents is strongly discouraged (in fact, new MIB > | documents should be written using SMIv2, which does not define > | NetworkAddress). > | > | and defines the OID: > | > | snmpTrapAddress OBJECT-TYPE > | SYNTAX IpAddress > | MAX-ACCESS accessible-for-notify > | STATUS current > | DESCRIPTION > | "The value of the agent-addr field of a Trap PDU which > | is forwarded by a proxy forwarder application using > | an SNMP version other than SNMPv1. The value of this > | object SHOULD contain the value of the agent-addr field > | from the original Trap PDU as generated by an SNMPv1 > | agent." > | ::= { snmpCommunityMIBObjects 3 } > | > | This clearly points out a lack of IPv6 awareness in this specification. > > This sub-section is a duplicate of 5.070 and should be removed. good catch, thx > | 5.073 RFC 2584 Definitions of Managed Objects for APPN/HPR in > | IP Networks > | > | Many of the OIDs described in this document assume the use of the > | IPv4 only TOS header bits. It is therefore IPv4 only in nature and > | will not support IPv6 interfaces. An updated MIB should be created. > > s/OIDs/object definitions/ > s/IPv4-only/ > > | 5.074 RFC 2591 Definitions of Managed Objects for Scheduling > | Management Operations > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.075 RFC 2592 Definitions of Managed Objects for the Delegation > | of Management Script > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.076 RFC 2594 Definitions of Managed Objects for WWW Services > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok for all > | 5.080 RFC 2619 RADIUS Authentication Server MIB > | > | This MIB defines the followings OIDs: > > s/OIDs/objects/ ok > | RadiusAuthClientEntry ::= SEQUENCE { > | radiusAuthClientIndex Integer32, > | radiusAuthClientAddress IpAddress, > | radiusAuthClientID SnmpAdminString, > | radiusAuthServAccessRequests Counter32, > | radiusAuthServDupAccessRequests Counter32, > | radiusAuthServAccessAccepts Counter32, > | radiusAuthServAccessRejects Counter32, > | radiusAuthServAccessChallenges Counter32, > | radiusAuthServMalformedAccessRequests Counter32, > | radiusAuthServBadAuthenticators Counter32, > | radiusAuthServPacketsDropped Counter32, > | radiusAuthServUnknownTypes Counter32 > | } > | > | radiusAuthClientAddress OBJECT-TYPE > | SYNTAX IpAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The NAS-IP-Address of the RADIUS authentication client > | referred to in this table entry." > | ::= { radiusAuthClientEntry 2 } > | > | There needs to be an update to allow an IPv6 based OID for this > | value. > > rewrite: > > This object needs to be deprecated and replaced by one that > supports both IPv4 and IPv6 addresses. ok > | 5.081 RFC 2622 Routing Policy Specification Language (RPSL) > | (RPSL) > > remove 2nd occurrence of "(RPSL)" ok. > | 5.082 RFC 2662 Definitions of Managed Objects for the ADSL > | Lines (MIB) > > remove "(MIB)" ok > | There are no IPv4 dependencies in this specification. > | > | > | 5.083 RFC 2665 Definitions of Managed Objects for the > | Ethernet-like Interface Types (MIB) > > s/MIB/EtherLike-MIB/ remove? > | There are no IPv4 dependencies in this specification. > > Note: this document is due to be replaced by > draft-ietf-hubmib-etherif-mib-v3-03.txt, which > the IESG recently approved as a Proposed Standard. > When you issue an update of this draft, check the > status of RFC 2665 to see if it has been replaced. ok, could add something like, if you prefer: Moreover, this specification is being Obsoleted. > | 5.085 RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium > | Attachment Units (MAUs) (MAU-MIB) > | > | There are no IPv4 dependencies in this specification. > > Note: this document is due to be replaced by > draft-ietf-hubmib-mau-mib-v3-04.txt, which the > IESG recently approved as a Proposed Standard. > When you issue an update of this draft, check the > status of RFC 2668 to see if it has been replaced. like above > | 5.087 RFC 2670 Radio Frequency (RF) Interface Management Information > | Base for MCNS/DOCSIS compliant RF interfaces (MIB) > > remove "(MIB)" > > | This MIB defines the following OIDs: > > s/OIDs/objects ok for both > | DocsIfCmtsCmStatusEntry ::= SEQUENCE { > | docsIfCmtsCmStatusIndex Integer32, > | docsIfCmtsCmStatusMacAddress MacAddress, > | docsIfCmtsCmStatusIpAddress IpAddress, > | docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero, > | docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero, > | docsIfCmtsCmStatusRxPower TenthdBmV, > | docsIfCmtsCmStatusTimingOffset Unsigned32, > | docsIfCmtsCmStatusEqualizationData OCTET STRING, > | docsIfCmtsCmStatusValue INTEGER, > | docsIfCmtsCmStatusUnerroreds Counter32, > | docsIfCmtsCmStatusCorrecteds Counter32, > | docsIfCmtsCmStatusUncorrectables Counter32, > | docsIfCmtsCmStatusSignalNoise TenthdB, > | docsIfCmtsCmStatusMicroreflections Integer32 > | } > | > | docsIfCmtsCmStatusIpAddress OBJECT-TYPE > | SYNTAX IpAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "IP address of this Cable Modem. If the Cable Modem has no > | IP address assigned, or the IP address is unknown, this > | object returns a value of 0.0.0.0. If the Cable Modem has > | multiple IP addresses, this object returns the IP address > | associated with the Cable interface." > | ::= { docsIfCmtsCmStatusEntry 3 } > | > | IPv6 OIDs should be defined. > > Rewrite this last sentence: > > This object needs to be deprecated and replaced by one that > supports both IPv4 and IPv6 addresses. ok > | 5.088 RFC 2674 Definitions of Managed Objects for Bridges with > | Traffic Classes, Multicast Filtering and Virtual LAN > | Extensions (MIB) > > s/(MIB)/(P-BRIDGE-MIB)/ remove ? > | 5.90 RFC 2720 Traffic Flow Measurement: Meter MIB > | > | This protocol is both IPv4 and IPv6 aware and needs no changes. > > s/protocol/specification/ > > | 5.091 RFC 2725 Routing Policy System Security > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok for both. > | 5.092 RFC 2726 PGP Authentication for RIPE Database Updates > | > | There are no IPv4 dependencies in this protocol. > > Is this actually an OPS Area specification? this could be moved to security, that's true. however, we felt that RPSL was so strongly OPS stuff, so this could logically belong here too (doesn't really matter as there are no dependencies). > | 5.093 RFC 2737 Entity MIB (Version 2) > | > | The TAddress Syntax is used in this MIB which contains IPv4 > | assumptions and need to be updated. > | > | entLogicalTAddress OBJECT-TYPE > | SYNTAX TAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The transport service address by which the logical entity > | receives network management traffic, formatted according to > | the corresponding value of entLogicalTDomain. > | > | For snmpUDPDomain, a TAddress is 6 octets long, the initial > | 4 octets containing the IP-address in network-byte order and > | the last 2 containing the UDP port in network-byte order. > | Consult 'Transport Mappings for Version 2 of the Simple > | Network Management Protocol' (RFC 1906 [RFC1906]) for > | further information on snmpUDPDomain." > > The statement that the TAddress SYNTAX value "contains IPv4 > assumptions" is actually not correct. The TDomain/TAddress types > allow for arbitrary transport domains and addresses to be > represented. It is true that the DESCRIPTION clause quoted above > spells out details only for snmpUDPDomain, but that does not mean > that entLogicalTDomain and entLogicalTAddress can't represent IPv6 > transport domains and addresses. See RFC 2579 and RFC 3419 for > further information. I therefore propose to replace the preceding > two paragraphs with this: > > There are no IPv4 dependencies in this specification. perhaps this could be spelled out a bit more, but ok. > Note: this RFC is due to be replaced by draft-ietf-entmib-v3-03.txt > or a successor; when published it will be a Draft Standard. Check > ftp://ftp.isi.edu/in-notes/rfc-index.txt before updating this memo > to determine if this has happened. would you prefer to add a piece of text on that? > | 5.094 RFC 2741 Agent Extensibility (AgentX) Protocol Version > | 1 (SNMP) > > remove "(SNMP)" ok > | This protocol contains definitions for IPv4 only objects, by reference > | and all examples use only IPv4 addressing. However, there does not > | seem to be any reason that it could not easily be modified to support > | IPv6 addresses. > > I think that a more accurate statement would be: > > Although the examples in the document are for IPv4 transport > only, there is no IPv4 dependency in the AgentX protocol itself. ok > | 5.095 RFC 2742 Definitions of Managed Objects for Extensible SNMP > | Agents > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.096 RFC 2748 The COPS (Common Open Policy Service) Protocol > | (COPS) > > remove "(COPS)" ok. > | 5.098 RFC 2769 Routing Policy System Replication (RPSL) > > remove "(RPSL)" agree! > > | There are no IPv4 dependencies in this protocol. > > Is this an OPS Area spec? It looks like a routine area > spec to me. routing area, yes, could be a target. but all of the RPSL stuff is in here, so perhaps it's best to keep it here esp. because there are no dependencies. But ok to move if you prefer. > | 5.102 RFC 2837 Definitions of Managed Objects for the Fabric Element > | in Fibre Channel Standard > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok (I still can't figure out why when the editor changed some of those to "specification" he didn't change all.. but have been a bug or something..) > | 5.103 RFC 2851 Textual Conventions for Internet Network Addresses > | > | This MIB defines a new set of OIDs for that allow new MIB's to > | use multiple versions of IP. Currently IPv4 and IPv6 addressing > | is defined. Update of the many MIBs previously identified as > | having IPv4 dependencies could easily be updated using this new > | set of IP address abstractions. > > This document has been replaced by RFC 3291 (also a proposed > standard). Please update this subsection accordingly. does it change the content of the issue, described above? ok to change. > | 5.104 RFC 2856 Textual Conventions for Additional High Capacity > | Data Types (SNMP) > > remove "(SNMP)" > > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.106 RFC 2895 Remote Network Monitoring MIB Protocol Identifier > | Reference (RMON-MIB) > > remove "(RMON-MIB)" ok for all > | This MIB is both IPv4 and IPv6 aware and needs no changes. > > s/MIB/specification/ > (the document does not contain a MIB module) ok > | 5.107 RFC 2925 Definitions of Managed Objects for Remote > | Ping, Traceroute, and Lookup Operations > | > | This MIB mostly is IPv4 and IPv6 aware. There are a few > | assumptions that are problems thought. In the following OIDs: > > s/problems thought./problems, though./ > s/OIDs/object definitions/ ok > | pingCtlDataSize OBJECT-TYPE > | SYNTAX Unsigned32 (0..65507) > | UNITS "octets" > | MAX-ACCESS read-create > | STATUS current > | DESCRIPTION > | "Specifies the size of the data portion to be > | transmitted in a ping operation in octets. A ping > | request is usually an ICMP message encoded > | into an IP packet. An IP packet has a maximum size > | of 65535 octets. Subtracting the size of the ICMP > | or UDP header (both 8 octets) and the size of the IP > | header (20 octets) yields a maximum size of 65507 > | octets." > | DEFVAL { 0 } > | ::= { pingCtlEntry 5 } > | > | > | traceRouteCtlDataSize OBJECT-TYPE > | SYNTAX Unsigned32 (0..65507) > | UNITS "octets" > | MAX-ACCESS read-create > | STATUS current > | DESCRIPTION > | "Specifies the size of the data portion of a traceroute > | request in octets. A traceroute request is essentially > | transmitted by encoding a UDP datagram into a > | IP packet. So subtracting the size of a UDP header > | (8 octets) and the size of a IP header (20 octets) > | yields a maximum of 65507 octets." > | DEFVAL { 0 } > | ::= { traceRouteCtlEntry 6 } > | > | There is clearly an assumption of IPv4 header sizes. > > Please rewrite this last sentence: > > The DESCRIPTION clauses need to be updated to remove the > IPv4 dependencies. > > Note that there is nothing wrong with the objects themselves. ok > | 5.111 RFC 2954 Definitions of Managed Objects for Frame > | Relay Service (FR-MIB) > > s/FR-MIB/FRNETSERV-MIB/ remove? > | 5.112 RFC 2955 Definitions of Managed Objects for Monitoring > | and Controlling the Frame Relay/ATM PVC Service > | Interworking Function > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok > | 5.113 RFC 2959 Real-Time Transport Protocol Management > | Information Base > | > | There are numerous uses of the included TAddress Syntax which is > | IPv4 dependent as noted above. > | > | For example: > | > | rtpSessionRemAddr OBJECT-TYPE > | SYNTAX TAddress > | MAX-ACCESS read-create > | STATUS current > | DESCRIPTION > | "The address to which RTP packets are sent by the RTP system. > | In an IP multicast RTP session, this is the single address used > | by all senders and receivers of RTP session data. In a unicast > | RTP session this is the unicast address of the remote RTP system. > | 'The destination address pair may be common for all participants, > | as in the case of IP multicast, or may be different for each, as > | in the case of individual unicast network address pairs.' See > | RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' > | sec. 3. The transport service is identified by rtpSessionDomain. > | For snmpUDPDomain, this is an IP address and even-numbered UDP > | Port with the RTCP being sent on the next higher odd-numbered > | port, see RFC 1889, sec. 5." > | ::= { rtpSessionEntry 3 } > | > | There are a total of 8 instances of this. > > As explained above under 5.093, this does not necessarily mean that > there is an IPv4 dependency. Please re-evaluate this MIB module and > update this section accordingly. I'd bet that this spec doesn't really > have any IPv4 dependencies after all. we don't have resources for re-evaluation, unfortunately. unless someone more knowledgeable does it, we'll have to keep it as is. > | 5.116 RFC 3014 Notification Log MIB > | > | This document contains OIDs that are IPv4 specific: > | > | nlmLogVariableIpAddressVal OBJECT-TYPE > | SYNTAX IpAddress > | MAX-ACCESS read-only > | STATUS current > | DESCRIPTION > | "The value when nlmLogVariableType is 'ipAddress'. > | Although this seems to be unfriendly for IPv6, we > | have to recognize that there are a number of older > | MIBs that do contain an IPv4 format address, known > | as IpAddress. > | > | IPv6 addresses are represented using TAddress or > | InetAddress, and so the underlying datatype is > | OCTET STRING, and their value would be stored in > | the nlmLogVariableOctetStringVal column." > | ::= { nlmLogVariableEntry 9 } > | > | > | Not withstanding the note in the DESCRIPTION. > > THIS DOES NOT CONSTITUTE AN IPv4 DEPENDENCY. As explained in > previous comments to one of the authors, this MIB module has > the means to represent in a log ANY object syntax that is > allowed by the SNMP and the SMI. The fact that it can > represent objects of type IpAddress in a log does NOT make it > IPv4-specific or IPv6-unfriendly, as the last paragraph in > the above DESCRIPTION clause makes amply clear. So, please > remove ALL of the verbiage in the section and say instead: > > There are no IPv4 dependencies in this specification. ok. > | 5.118 RFC 3020 Definitions of Managed Objects for Monitoring > | and Controlling the UNI/NNI Multilink Frame Relay Function > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.119 RFC 3055 Management Information Base for the PINT Services > | Architecture > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.120 RFC 3060 Policy Core Information Model -- Version 1 > | Specification (CIM) > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ > > | 5.121 RFC 3084 COPS Usage for Policy Provisioning (COPS-PR) > | (COPS-PR) > > remove redundant "(COPS-PR)" > > | This is an IPv4 only protocol. A version for IPv6 must be defined. > > s/must be/may ned to be/ ok for all of above > | 6.05 RFC 1792 TCP/IPX Connection Mib Specification (TCP/IPXMIB) > > s?TCP/IPXMIB?TCPIPX-MIB? remove ? > | There are no IPv4 dependencies in this specification. > > s/protocol/specification/ ok > | 6.06 RFC 1901 Introduction to Community-based SNMPv2 (SNMPV2CB) > | > | There are no IPv4 dependencies in this protocol. > > RFC 1901 is now HISTORIC and should be dropped from this survey. should keep it here, but could add a statement here, like: Moreover, this specification has been reclassified HISTORIC. > | 6.07 RFC 1909 An Administrative Infrastructure for SNMPv2 > | (SNMPV2AI) > | > | There are no IPv4 dependencies in this protocol. > > RFC 1909 is now HISTORIC and should be dropped from this survey. > > | 6.08 RFC 1910 User-based Security Model for SNMPv2 (SNMPV2SM) > | > | There are no IPv4 dependencies in this protocol. > > RFC 1910 is now HISTORIC and should be dropped from this survey. same for both of these > | 6.09 RFC 2593 Script MIB Extensibility Protocol Version 1.0 > | > | There are no IPv4 dependencies in this specification. > > This document has been obsoleted by RFC 3179, which specifies > Version 1.1 of the protocol. Please update this section > accordingly. ok. > | 6.11 RFC 2758 Definitions of Managed Objects for Service Level > | Agreements Performance Monitoring > | > | This protocol is both IPv4 and IPv6 aware and needs no changes. > > s/protocol/specification/ > > | 6.12 RFC 2786 Diffie-Helman USM Key Management Information Base and > | Textual Convention > | > | There are no IPv4 dependencies in this protocol. > > s/protocol/specification/ ok for all of above. > | Of those identified many require no action because they document > | outdated and unused protocols, while others are document protocols > | that are actively being updated by the appropriate working groups. > | Additionally there are many instances of standards that should be > | updated but do not cause any operational impact if they are not > | updated. The remaining instances are documented below. > > This may need to be updated based on corrections above. > I've not checked it. yep. > | 7.1 Standards > | > | 7.1.1 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) > | > | The limitations identified have been addressed; RFC 1157 is HISTORIC, > | RFC1155 is obsoleted by RFC 2578-2580, and RFC1213 has been split to > | multiple modules which have been seen to. > > The above actually concerns three separate STDs. > > STD 15, RFC 1157, is SNMPv1, but it has been retired ... that is, it has > been reclassified as HISTORIC and therefore is no longer an Internet > Standard. So it should be dropped from the survey. disagree, due to the process differences (if we just had the time machine..) > STD 16, RFCs 1155 and 1212, is SMIv1. Officially it's still in force, > although it's no longer used for new work. Note that RFC 1215 is part > of the same document set, although it is an Informational RFC. > > STD 17, RFC 1213, is MIB-II. Officially it's still in force, but the > parts which are still relevant have been or are being replaced. ok > So I would suggest replacing the above with something along these lines: first, something like: 7.1.1 STD 15 Simple Network Management Protocol (RFCs 1157) RFC 1157 has been reclassified HISTORIC. > 7.1.1 STD 16, Structure of Management Information (RFCs 1155 and 1212) > > RFCs 1155 and RFCs 1212 (along with the informational document RFC > 1215) define SMIv1. These documents have been superseded by RFCs > 2578, 2579, and 2580 which define SMIv2. Since SMIv1 is no longer > being used as the basis for new IETF MIB modules, the limitations > identified in this Internet Standard do not require any action. ok. > 7.1.2 STD 17, Management Information Base MIB II (RFC 1213) > > The limitations identified are being addressed: the IP group, > the ICMP group, the TCP group, and the UDP group are being > replaced by IP version-independent MIB modules now in development > in the IPv6 working group (for more details see the entries > below for RFCs 2011, 2012, 2013, and 2096). No replacement is > being contemplated for the EGP group because EGP is a historic > protocol that is no longer in significant use in the Internet. ok. > | 7.2 Draft Standards > | > | > | 7.2.1 BGP4 MIB (RFC 1657) > | > | This problem is currently being addressed by the Inter Domain Routing > | (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt). > > s/draft-ietf-idr-bgp4-mib-09.txt/draft-ietf-idr-bgp4-mib-11.txt/ ok > | 7.2.2 SMDS MIB (RFC 1694) > | > | See Section 7.1.22. Once a specification for IPv6 over SMDS is > | created a new MIB must be defined. > > Where is Section 7.1.22? Change this to a reference to the Internet Area standards. > I agree with the 2nd sentence, BTW, if > "must" is changed to "should"; it stands alone quite nicely. agree. > | 7.2.3 RIPv2 MIB (RFC 1724) > | > | See Section 7.1.24. This problem is currently being addressed by the > | RIP WG and an ID exists (draft-ietf-rip-mib-01.txt). > > Where is Section 7.1.24? routing, now.. > I agree with the 2nd sentence, except > that the draft is now draft-ietf-rip-mib-01.txt; it stands alone > quite nicely. the draft name you mentioned is the same as listed, perhaps you meant something else? (btw, the draft has expired in the meantime) > | 7.2.4 OSPFv2 MIB (RFC 1850) > | > | This problem is currently being addressed by the OSPF WG and an ID > | exists (draft-ietf-ospf-ospfv3-mib-04.txt). > > s/draft-ietf-ospf-ospfv3-mib-04.txt/draft-ietf-ospf-ospfv3-mib-07.txt/ ok > | 7.2.5 Transport MIB (RFC 1906) > > s/Transport MIB/Transport Mappings for SNMP/ > s/1906/3417/ > > | The problem has been fixed in RFC 2454, IPv6 Management Information > | Base for the User Datagram Protocol. > > RFC 1906 has been replaced by 3417, and RFC 2454 is irrelevant. So, > move this section to the Full Standards part, change the section > heading, to point to RFC 3417, and rewrite the text as follows: > > The limitations of this specification have been addressed by RFC > 3419, which defines TCs that can be used to specify transport > domains in an IP version-independent way. RFC 3419 recommends that > those TCs be used in place of SnmpUDPAddress when IPv6 support is > required and for all new applications that are not SNMP-specific. ok. > | 7.2.6 Frame Relay MIB (RFC 2115) > | > | The problem has been fixed in RFC 2954, Definitions of Managed Objects > | for Frame Relay Service. > > This section should be deleted. As noted above, there is actually > no problem with RFC 2115 to begin with; and anyway, 2115 is the > MIB module for Frame Relay DTEs whilst 2954 is the MIB module for > the Frame Relay service implemented on network elements. right, remove. > | 7.3 Proposed Standards > | > | > | 7.3.01 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) > | > | This problem has not been addressed. A new specification should > | be created. > > rewrite: > > This problem has not been addressed. If a user requirement for > IPv6 over X.25 develops (which is thought to be unlikely) then > this MIB module will need to be updated in order to accomodate it. > > Note that the analysis in Section 6 suggests that a whole new MIB > module isn't necessary, just updates to some object definitions. ok > | 7.3.02 PPP IPCP MIB (RFC 1473) > | > | There is no updated MIB to cover the problems outlined. A new MIB > | must be defined. > > s/must/should/ ok > | 7.3.03 DNS Server MIB (RFC 1611) > | > | This document is HISTORIC and no action is required. > > If it's HISTORIC it's not a Proposed Standard anymore. > Drop it from the survey. disagree > | 7.3.04 DNS Resolver MIB (RFC 1612) > | > | This document is HISTORIC and no action is required. > > If it's HISTORIC it's not a Proposed Standard anymore. > Drop it from the survey. see above > | 7.3.05 Appletalk MIB (RFC 1742) > | > | The problems have not been addressed and a new MIB should be defined. > > rewrite: > > This problem has not been addressed. If a user requirement for > IPv6 over Appletalk develops (which is thought to be unlikely) > then this MIB module will need to be updated (or a new MIB module > will need to be created) in order to accomodate it. I'd soften the tone a bit, because AFAIK, some Apples are still using appletalk, so s/is thought to be unlikely/may be unlikely/ but ok as is too. > | 7.3.06 The Definitions of Managed Objects for IP Mobility > | Support using SMIv2 (RFC 2006) > | > | The problems are being resolved by the Mobile IP WG and there is > | an ID (draft-ietf-mobileip-rfc2006bis-00.txt) > > s/draft-ietf-mobileip-rfc2006bis-00.txt/draft-ietf-mobileip-rfc2006bis-02.txt/ ok > | 7.3.07 SMIv2 MIB IP (RFC 2011) > > s/SMIv2 MIB IP/SMIv2 IP MIB/ > > | The problems have been addressed in RFC 2851, Textual Conventions > | for Internet Network Addresses, and RFC 2465, Management Information > | Base for IP Version 6: Textual Conventions and General Group. > > RFC 2851 has been replaced by RFC 3291, and RFC 2465 is going to be > replaced because implementation experience has indicated that it was > the wrong approach. I therefore recommend that the above paragraph > be rewritten as follows: > > This issue is being resolved by the IPv6 WG and there is an > ID (draft-ietf-ipv6-rfc2011-update-03.txt). > > Note: please insert the tag for the latest version of the I-D; > my understanding is that -04 is expected "any day now" with > changes to resolve WG last call comments. ok > | 7.3.08 SNMPv2 MIB TCP (RFC 2012) > > s/SNMPv2 MIB TCP/SMIv2 TCP MIB/ > > | The problems have been addressed in RFC 2452, IPv6 Management > | Information Base for the Transmission Control Protocol. > > RFC 2452 is headed to the dustbin, so pls rewrite: > > This issue is being resolved by the IPv6 WG and there is an > ID (draft-ietf-ipv6-rfc2012-update-03.txt). > > Note: insert that tag for the latest version of the I-D; > my understanding is that -04 is expected "any day now" with > changes to resolve WG last call comments. ok > | 7.3.09 SNMPv2 MIB UDP (RFC 2013) > > s/SNMPv2 MIB UDP/SMIv2 UDP MIB/ > > | The problems have been addressed in RFC 2454, IPv6 Management > | Information Base for the User Datagram Protocol. > > RFC 2454 is headed for dustbin, so pls rewrite: > > This issue is being resolved by the IPv6 WG. > > At this time there is no I-D: draft-ietf-ipv6-rfc2013-update-00.txt > did exist but it has expired. A new version has been promised; > the main obstacle is lack of an editor (volunteers welcome). ok > | 7.3.10 RMON MIB (RFC 2021)? > > s/RMON MIB/RMON-II MIB/ > remove question mark > > | The problems have been addressed in RFC 2819, Remote Network > | Monitoring Management Information Base. > > That is false: RFC 2021 is RMON-II, and RFC 2819 is the full > standard version of RMON-I (formerly RFCs 1271 and 1757). There > is a work underway to update RFC 2021, however; so the correct > statement is probably this: > > This issue is being resolved by the RMONMIB WG and there is an > ID (draft-ietf-rmonmib-rmon2-v2-00.txt). > > In fact draft-ietf-rmonmib-rmon2-v2-00.txt doesn't actually address > the problem but I have raised the issue on the RMONMIB mailing list. so, maybe reword: This issue is being resolved by the RMONMIB WG and there is an ID (draft-ietf-rmonmib-rmon2-v2-00.txt); future revistions may address the problem as it has been identifier and brough to attention. ? ok > | 7.3.11 DataLink Switching using SMIv2 MIB (RFC 2022) > > s/2022/2024/ > Note: RFC 2022 is the multicast over ATM spec (MARS and so on) > > | The problems have not been addressed and a new MIB should be > | defined. > > s/a new/an updated/ ok > | 7.3.12 IP Forwarding Table MIB (RFC 2096) > | > | This issue is being worked on by the IPv6 WG and an ID exists to > | address this (draft-ietf-ipngwg-rfc2096-update-00.txt) > > s/draft-ietf-ipngwg-rfc2096-update-00.txt/draft-ietf-ipv6-rfc2096-update-05.txt/ > (it was posted on 29 Aug 2003, should be listed on IPv6 WG charter page by now) ok > | 7.3.13 Classical IP & ARP over ATM MIB (RFC 2320) > | > | The problems identified are not addressed and a new MIB must be > | defined. > > The previous paragraph should be rewritten along the following > lines: > > The current version of Classical IP and ARP over ATM (RFC xxxx) > does not support IPv6. If and when that protocol specification > is updated to add IPv6 support, then new MIB objects to represent > IPv6 addresses will need to be added to this MIB module. ok, replace xxxx in to point to the CLIP RFC though (in routing survey?) > | 7.3.14 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) > | > | The problems identified are not addressed and a new MIB must be > | defined. > > The previous paragraph should be rewritten along the following > lines: > > The current version of Multicast over UNI 3.0/3.1 ATM (RFC > xxxx) does not support IPv6. If and when that protocol > specification is updated to add IPv6 support, then new MIB > objects to represent IPv6 addresses will need to be added to > this MIB module. ok, same here. > | 7.3.15 ATM MIB (RFC 2515) > | > | The problems identified are not addressed and a new MIB must be > | defined. > > rewrite: > > The AToM MIB WG is currently collecting implementation reports for RFC > 2515 and is considering whether to advance, revise, or retire this > specification. The problems identified have been brought to the > attention of the WG. > > I know that last sentence is true, since I just sent a message to that > effect to atommib@research.telcordia.com :-) ok :-) > | 7.3.16 TN3270 MIB (RFC 2562) > | > | The problems identified are not addressed and a new MIB may be > | defined. > > rewrite: > > The problems identified are not being addressed and a new MIB > module may need to be defined. Ok > | 7.3.17 Application MIB (RFC 2564) > | > | The problems identified are not addressed and a new MIB may be > | defined. > | One possible solution is to use RFC 3419 TCs. > > rewrite: > > The problems identified are not being addressed and a new MIB > module may need to be defined. One possible solution might be > to use the RFC 3419 TCs. ok. > | 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 2576) > | > | There are no real issues that can be resolved. > > rewrite: > > There are no issues that need to be resolved. > > Note also that the coex doc is now RF 3584, which is a BCP. ok > | 7.3.23 DOCSIS MIB (RFC 2669) > | > | This problem is currently being addressed by the IPCDN WG and an ID > | is available (draft-ietf-ipcdn-device-mibv2-01.txt). > > s/draft-ietf-ipcdn-device-mibv2-01.txt/draft-ietf-ipcdn-device-mibv2-05.txt/ ok > | 7.3.24 RF MIB For DOCSIS (RFC 2670) > | > | This problem is currently being addressed by the IPCDN WG and an ID > | is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt). > > s/draft-ietf-ipcdn-docs-rfmibv2-01.txt/draft-ietf-ipcdn-docs-rfmibv2-06.txt/ > > | 7.3.25 Entity MIB Version 2 (RFC 2737) > | > | The problems have not been addressed and a new MIB should be defined. > > Delete the above paragraph, as there really are no problems in > the ENTITY-MIB. > > | 7.3.26 AgentX Protocol V1 (RFC 2741) > | > | The problems have not been addressed and a new protocol may be > | defined. > > Delete the above paragraph, as there really are no problems in > the AgentX protocol. ok, for all > | 7.3.28 MIB For Traceroute, Pings and Lookups (RFC 2925) > | > | The problems have not been addressed and a new MIB may be defined. > > s/may be/may need to be/ ok > | 7.3.31 RPSL (RFC 2622) > | > | Additional objects must be defined for IPv6 addresses and prefixes. > > s/must/should/ Keep it as MUST. but you can say: draft-blunk-rpslng-01.txt defines extensions to solve this issue, and it is being considered for publication. > | 7.4 Experimental RFCs > | > | > | 7.4.1 Protocol Independent Multicast MIB for IPv4 (RFC 2934) > | > | The problems have not been addressed and a new MIB should be defined. > > s/should be/may need to be/ ok. > This concludes my comments on draft-ietf-v6ops-ipv4survey-ops-02.txt. THANKS! We haven't had such an extensive review in ages... :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Sep 3 08:16:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27458 for ; Wed, 3 Sep 2003 08:16:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uWVD-000CoX-UM for v6ops-data@psg.com; Wed, 03 Sep 2003 12:12:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19uWUh-000CmX-IO for v6ops@ops.ietf.org; Wed, 03 Sep 2003 12:12:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h83CBEV18457 for ; Wed, 3 Sep 2003 15:11:14 +0300 Date: Wed, 3 Sep 2003 15:11:14 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is an explicit request for feedback from the WG on a very important issue. To quote Juha, So, could I get more wg comments / discussion on this issue, please!? How should we mention UE based tunneling in this document, or should we not mention it at all? That is, what kind of transition architecture should we suggest *in this document* for 3GPP UE's? (of course, v6ops is not mandating what vendors/users/operators will or will not do regardless of that advice.) Waiting for WG input.. Pekka as WG co-chair ---------- Forwarded message ---------- Date: Tue, 2 Sep 2003 17:00:31 +0300 From: juha.wiljakka@nokia.com To: karim.el-malki@ericsson.com, pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] Hi, ok, this is the last issue I have not yet commented on the list. The comment sent by Pekka was about "IPv6 in IPv4" tunneling performed in the UEs. Pekka does not want to require or recommend the implementation of any automatic (or configured) tunneling methods in the UEs. Justification for that: high number of IPv6-capable UEs, implementation footprint of UE's is expected to be small, upgradeability of UE's is poor and we are concerned about 3GPP *deployment* not early trials or piloting in this document. Quite a long discussion followed including 3GPP architecture, different PDP context types, roaming (which has not been discussed so much in our document, anyway, 3GPP roaming is happening at layer 2, not IP layer), etc. I must say that I agree on many points above - I do not believe that tunneling in the UE is a scalable solution for a very large number of terminals. What this section in our document tries to explain, is how to solve such a situation when the operator does not support IPv6 in its network (GGSN / SGSN / HLR is/are lacking IPv6 support) and the UE (user) wants to access IPv6 services. And in that case you MAY use tunneling in the UE to get IPv6 service. The recommended (longer term) approach for this problem is that the operators deploy basic IPv6 support in their 3GPP networks (can in most cases be done by making a sw upgrades) - and we must convince them to do that as soon as possible! What do you think, could that be one key recommendation in our document? Karim also commented that the soon starting IMS period also makes basic IPv6 support reality in 3GPP networks. And it removes the need for tunneling to be done in the UEs. So, could I get more wg comments / discussion on this issue, please!? How should we mention UE based tunneling in this document, or should we not mention it at all? The current text is: "However, the UE may attach to a 3GPP network, in which the Serving GPRS Support Node (SGSN), the GGSN and the Home Location Register (HLR) support IPv4 PDP contexts by default, but may not support IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism. This might happen in very early phases of IPv6 deployment, or in IPv6 demonstrations and trials. The UE may be assigned a private or public IPv4 address when the IPv4 PDP context has been activated, although it is more likely that it will receive a private address (due to the lack of public IPv4 addresses). The use of private IPv4 addresses in the UE depends on the support of these addresses by the tunneling mechanism and the deployment scenario. In some cases, public IPv4 addresses are required (one example is 6to4 [RFC3056]), but if the tunnel endpoints are in the same private domain or the tunneling mechanism works through IPv4 NAT (Network Address Translator), private IPv4 addresses can be used (examples are [ISATAP] and [TEREDO]). In general, if tunneling from the host is needed, ISATAP and 6to4 are preferred and TEREDO is a mechanism of last resort when neither of these are applicable. One deployment scenario example is using a laptop computer and a UMTS UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and an IPv4 PDP context is activated. Although "IPv6 in IPv4" tunneling can be either automatic or configured (by the user), the first alternative is favored, because it is expected that most UE users just want to use an application in their UE; they might not even care, whether the network connection is IPv4 or IPv6." BR, -Juha- -----Original Message----- From: ext Karim El-Malki (HF/EAB) [mailto:karim.el-malki@ericsson.com] Sent: 12 August, 2003 16:36 To: 'Pekka Savola' Cc: 'v6ops@ops.ietf.org' Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment (fwd) > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > > > Or let me phrase this differently: > > > > > > > > > > Would roaming with 3GPP UE work if the roaming agreements > > > > > would include > > > > > an indication whether the foreign network > supports the same > > > > > PDP context > > > > > types as the original network. > > > > > > > > > > I.e. the user can prefer those roaming partners which > > > > > provide the services > > > > > they want. That should be enough of an economic incentive. > > > > > > > > Basically the UE won't know until it tries to activate > > > > a v6 connection and it gets refused. > > > > > > This seems like a potentially fatal design flaw. > > > > When I plug into Ethernet or WLAN I don't know if the network > > supports IPv6 until I get an RA. > > Very true, but the expectations are entirely different (or > that's my take > at least). When I use my laptop and roam in the world, I generally > *DON'T* expect IPv6 to be available. Hence, I'm equipped > with some useful > tools to enable IPv6 in the case network doesn't support it > (e.g. 6to4 or > configured tunnels). > > However, I think the expectation with 3GPP is entirely > different: network > supports IPv6, period. (And it would be unreasonable to > assume the huge > number of 3GPP devices to implement all the possible > mechanisms required > in every possible network scenario, be it 3GPP or regular > old-fashioned > Internet.) To be precise it's 3GPP IMS services that support IPv6. I hope this will get all operators to support IPv6 for the obvious reasons such as peer-to-peer connectivity. However it is a different thing to expect any 3GPP network in general to support IPv6 from day one. In fact there are commercial 3GPP operators today (WCDMA and GSM) whose networks do not support IPv6. Also, all I have been saying is to recommend support for at least one type of tunnelling in this case. ISATAP does what is needed IMO, so you don't need to support every possible mechanism. > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > > support in > > > remote SGSN's/GGSN's be avoided ? > > > > You could do that, but it would be an overkill IMO to run PPP > > over wireless. Since we're dealing with an expensive bandwidth > > limited link it's not an attractive alternative. > > I think it would be useful to try to analyze the overhead of > PPP in this > scenario. It might not be that high, and it might only be > the fallback > solution where other mechanisms (i.e. finding an operator which would > support IPv6, or refraining from using IPv6) would not work. That would be asking for equipment to support IPv4, IPv6 and PPP to cater for a case which we hope will be rare. I would definitely limit it to IPv4 and IPv6 so that people would have to tunnel for the special cases and operators would have an incentive to migrate to native IPv6. PPP will not solve the problem in a clean way and will be a disincentive to migrate to native IPv6. > > For example today operators have gprs (IPv4) roaming agreements > > with certain operators and only voice with others. > > Do you know if there is a regional perspective to this? > That is, if there > are multiple potential roaming partners in an area, could > you say that > they often support different capabilities? > If they support different capabilties, it might be easier to > conclude that > it's reasonable to expect some of them to support IPv6 > (while some others > wouldn't) -- and then cycling through roaming partners until > finding a > correct might be a thinkable approach. Personally I wouldn't see why an operator would want to limit its market to certain type of services in a certain area. >From what I know the above cannot be taken as a rule. I don't think I would design a standard based on a single business model anyway. > > If you're in this special case (which will hopefully become > > rare in future) and you want to have a way of using IPv6 services > > then tunnelling is an attractive solution. > > What I'm looking for is a way or two to work around that > requirement; I > would loath to see a requirement to implement tunneing > solutions on mobile > terminals to make the service work in areas where the 3GPP operator > doesn't suddenly support IPv6. > > I think we should try to ways to leverage 3GPP network's > capabilities to > ensure that either: > > 1) the user is able to obtain IPv6 PDP context somehow; > this is an issue > when roaming to some other operator's network. Whether from > that operator > or by trying someone else doesn't matter. > > 2) the user is able to work around the issue by requesting PPP PDP > context until the roaming partner supports IPv6 > > 3) the user is able to stick to just using IPv4 when > roaming in a network > where there are no ways at all to get IPv6 using any means. Number 1) is unworkable as I've explained before. There are also business issues that will make it useless in many cases (i.e. there is only one data roaming partner which is common today). Number 2) isn't workable either. You're not going to convince operators to get support for PPP (which is normally not there today) only because they need IPv6; they would get native IPv6 directly. Tunnelling is fine as a migration tool and we've tested it. It's the only feasible choice and it will lead to a migration to native IPv6. /Karim From owner-v6ops@ops.ietf.org Wed Sep 3 08:29:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28369 for ; Wed, 3 Sep 2003 08:29:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uWjR-000E0c-SW for v6ops-data@psg.com; Wed, 03 Sep 2003 12:27:29 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.22) id 19uWin-000DyD-3O for v6ops@ops.ietf.org; Wed, 03 Sep 2003 12:26:49 +0000 Received: from consulintel02 ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 25-md50000000007.tmp for ; Wed, 03 Sep 2003 14:29:06 +0200 Message-ID: <099901c37216$e9909700$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) Date: Wed, 3 Sep 2003 14:28:41 +0200 Organization: Consulintel 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 03 Sep 2003 14:29:06 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_NJABL,REFERENCES, X_NJABL_OPEN_PROXY version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we can survive with only the 1st paragraph of the actual text, and forget the 2 that follow. Once the IPv4 PDP context is established, with a private or public address for the UE, you can use any type of tunnel or transition mechanism that you like, just obvious to me. Regards, Jordi ----- Original Message ----- From: "Pekka Savola" To: Sent: Wednesday, September 03, 2003 2:11 PM Subject: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) > Hi, > > This is an explicit request for feedback from the WG on a very important > issue. To quote Juha, > > So, could I get more wg comments / discussion on this issue, please!? How > should we mention UE based tunneling in this document, or should we not > mention it at all? > > That is, what kind of transition architecture should we suggest *in this > document* for 3GPP UE's? (of course, v6ops is not mandating what > vendors/users/operators will or will not do regardless of that advice.) > > Waiting for WG input.. > > Pekka > as WG co-chair > > ---------- Forwarded message ---------- > Date: Tue, 2 Sep 2003 17:00:31 +0300 > From: juha.wiljakka@nokia.com > To: karim.el-malki@ericsson.com, pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 > deployment [issue 6] > > Hi, > > ok, this is the last issue I have not yet commented on the list. The > comment sent by Pekka was about "IPv6 in IPv4" tunneling performed in the > UEs. Pekka does not want to require or recommend the implementation of > any automatic (or configured) tunneling methods in the UEs. Justification > for that: high number of IPv6-capable UEs, implementation footprint of > UE's is expected to be small, upgradeability of UE's is poor and we are > concerned about 3GPP *deployment* not early trials or piloting in this > document. Quite a long discussion followed including 3GPP architecture, > different PDP context types, roaming (which has not been discussed so much > in our document, anyway, 3GPP roaming is happening at layer 2, not IP > layer), etc. > > I must say that I agree on many points above - I do not believe that > tunneling in the UE is a scalable solution for a very large number of > terminals. What this section in our document tries to explain, is how to > solve such a situation when the operator does not support IPv6 in its > network (GGSN / SGSN / HLR is/are lacking IPv6 support) and the UE (user) > wants to access IPv6 services. And in that case you MAY use tunneling in > the UE to get IPv6 service. > > The recommended (longer term) approach for this problem is that the > operators deploy basic IPv6 support in their 3GPP networks (can in most > cases be done by making a sw upgrades) - and we must convince them to do > that as soon as possible! What do you think, could that be one key > recommendation in our document? Karim also commented that the soon > starting IMS period also makes basic IPv6 support reality in 3GPP > networks. And it removes the need for tunneling to be done in the UEs. > > So, could I get more wg comments / discussion on this issue, please!? How > should we mention UE based tunneling in this document, or should we not > mention it at all? > > The current text is: > > "However, the UE may attach to a 3GPP network, in which the Serving GPRS > Support Node (SGSN), the GGSN and the Home Location Register (HLR) support > IPv4 PDP contexts by default, but may not support IPv6 PDP contexts. If > the 3GPP network does not support IPv6 PDP contexts, and an application on > the UE needs to communicate with an IPv6(-only) node, the UE may activate > an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a > tunneling mechanism. This might happen in very early phases of IPv6 > deployment, or in IPv6 demonstrations and trials. > > The UE may be assigned a private or public IPv4 address when the IPv4 PDP > context has been activated, although it is more likely that it will > receive a private address (due to the lack of public IPv4 addresses). The > use of private IPv4 addresses in the UE depends on the support of these > addresses by the tunneling mechanism and the deployment scenario. In some > cases, public IPv4 addresses are required (one example is 6to4 [RFC3056]), > but if the tunnel endpoints are in the same private domain or the > tunneling mechanism works through IPv4 NAT (Network Address Translator), > private IPv4 addresses can be used (examples are [ISATAP] and [TEREDO]). > In general, if tunneling from the host is needed, ISATAP and 6to4 are > preferred and TEREDO is a mechanism of last resort when neither of these > are applicable. > > One deployment scenario example is using a laptop computer and a UMTS UE > as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop > computer and an IPv4 PDP context is activated. Although "IPv6 in IPv4" > tunneling can be either automatic or configured (by the user), the first > alternative is favored, because it is expected that most UE users just > want to use an application in their UE; they might not even care, whether > the network connection is IPv4 or IPv6." > > BR, > -Juha- > > -----Original Message----- > From: ext Karim El-Malki (HF/EAB) [mailto:karim.el-malki@ericsson.com] > Sent: 12 August, 2003 16:36 > To: 'Pekka Savola' > Cc: 'v6ops@ops.ietf.org' > Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 > dep loyment (fwd) > > > > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > > > > Or let me phrase this differently: > > > > > > > > > > > > Would roaming with 3GPP UE work if the roaming agreements > > > > > > would include > > > > > > an indication whether the foreign network > > supports the same > > > > > > PDP context > > > > > > types as the original network. > > > > > > > > > > > > I.e. the user can prefer those roaming partners which > > > > > > provide the services > > > > > > they want. That should be enough of an economic incentive. > > > > > > > > > > Basically the UE won't know until it tries to activate > > > > > a v6 connection and it gets refused. > > > > > > > > This seems like a potentially fatal design flaw. > > > > > > When I plug into Ethernet or WLAN I don't know if the network > > > supports IPv6 until I get an RA. > > > > Very true, but the expectations are entirely different (or > > that's my take > > at least). When I use my laptop and roam in the world, I generally > > *DON'T* expect IPv6 to be available. Hence, I'm equipped > > with some useful > > tools to enable IPv6 in the case network doesn't support it > > (e.g. 6to4 or > > configured tunnels). > > > > However, I think the expectation with 3GPP is entirely > > different: network > > supports IPv6, period. (And it would be unreasonable to > > assume the huge > > number of 3GPP devices to implement all the possible > > mechanisms required > > in every possible network scenario, be it 3GPP or regular > > old-fashioned > > Internet.) > > To be precise it's 3GPP IMS services that support IPv6. > I hope this will get all operators to support IPv6 for the > obvious reasons such as peer-to-peer connectivity. However > it is a different thing to expect any 3GPP network in general > to support IPv6 from day one. In fact there are commercial > 3GPP operators today (WCDMA and GSM) whose networks do not > support IPv6. Also, all I have been saying is to recommend > support for at least one type of tunnelling in this case. > ISATAP does what is needed IMO, so you don't need to support > every possible mechanism. > > > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > > > support in > > > > remote SGSN's/GGSN's be avoided ? > > > > > > You could do that, but it would be an overkill IMO to run PPP > > > over wireless. Since we're dealing with an expensive bandwidth > > > limited link it's not an attractive alternative. > > > > I think it would be useful to try to analyze the overhead of > > PPP in this > > scenario. It might not be that high, and it might only be > > the fallback > > solution where other mechanisms (i.e. finding an operator which would > > support IPv6, or refraining from using IPv6) would not work. > > That would be asking for equipment to support IPv4, IPv6 and PPP to > cater for a case which we hope will be rare. I would definitely limit > it to IPv4 and IPv6 so that people would have to tunnel for the special > cases and operators would have an incentive to migrate to native IPv6. > PPP will not solve the problem in a clean way and will be a disincentive > to migrate to native IPv6. > > > > For example today operators have gprs (IPv4) roaming agreements > > > with certain operators and only voice with others. > > > > Do you know if there is a regional perspective to this? > > That is, if there > > are multiple potential roaming partners in an area, could > > you say that > > they often support different capabilities? > > If they support different capabilties, it might be easier to > > conclude that > > it's reasonable to expect some of them to support IPv6 > > (while some others > > wouldn't) -- and then cycling through roaming partners until > > finding a > > correct might be a thinkable approach. > > Personally I wouldn't see why an operator would want to limit > its market to certain type of services in a certain area. > >From what I know the above cannot be taken as a rule. I don't > think I would design a standard based on a single business > model anyway. > > > > If you're in this special case (which will hopefully become > > > rare in future) and you want to have a way of using IPv6 services > > > then tunnelling is an attractive solution. > > > > What I'm looking for is a way or two to work around that > > requirement; I > > would loath to see a requirement to implement tunneing > > solutions on mobile > > terminals to make the service work in areas where the 3GPP operator > > doesn't suddenly support IPv6. > > > > I think we should try to ways to leverage 3GPP network's > > capabilities to > > ensure that either: > > > > 1) the user is able to obtain IPv6 PDP context somehow; > > this is an issue > > when roaming to some other operator's network. Whether from > > that operator > > or by trying someone else doesn't matter. > > > > 2) the user is able to work around the issue by requesting PPP PDP > > context until the roaming partner supports IPv6 > > > > 3) the user is able to stick to just using IPv4 when > > roaming in a network > > where there are no ways at all to get IPv6 using any means. > > Number 1) is unworkable as I've explained before. There are also business > issues that will make it useless in many cases (i.e. there is only > one data roaming partner which is common today). Number 2) isn't workable > either. You're not going to convince operators to get support for PPP > (which is normally not there today) only because they need IPv6; they would > get native IPv6 directly. Tunnelling is fine as a migration tool and we've > tested it. It's the only feasible choice and it will lead to a migration > to native IPv6. > > /Karim > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Sep 3 11:17:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14723 for ; Wed, 3 Sep 2003 11:17:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uZJU-0001vH-5w for v6ops-data@psg.com; Wed, 03 Sep 2003 15:12:52 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19uZJO-0001un-AG for v6ops@ops.ietf.org; Wed, 03 Sep 2003 15:12:46 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19uZJM-00039x-WD for v6ops@ops.ietf.org; Wed, 03 Sep 2003 08:12:45 -0700 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502331497@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Wijnen, Bert (Bert)" To: "'Kalyan.Tata@nokia.com'" , vrrp@ietf.org Cc: v6ops@ops.ietf.org Subject: RE: [VRRP] MIB work Date: Wed, 3 Sep 2003 12:22:56 +0200 X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Kalyan MMM... you seem to keep calling me Bret, while it is Bert. I am not offended, just noticed. Inline Thanks, Bert > -----Original Message----- > From: Kalyan.Tata@nokia.com [mailto:Kalyan.Tata@nokia.com] > Sent: woensdag 3 september 2003 4:01 > To: bwijnen@lucent.com; vrrp@ietf.org > Cc: v6ops@ops.ietf.org > Subject: RE: [VRRP] MIB work > > > Hi Bret, > Thanks for the pointer. Browsing through the ID, it looks like they > are proposing two different MIBs too. I contacted the authors about > their input on the pending one MIB vs two MIBs issue. > I do not thing that they are proposing two MIB modules. They say: - Thus, changes will be required for this MIB to interoperate in an IPv6 environment. - The problems have not been addressed and a new MIB should be defined. Maybe you conclude from that second bullet that they propose a 2nd MIB. But I do not think that is the intention. A "new mib module" could either be: - a complete replacement that includes both IPv4 and IPv6 support - a complete replacement that adds IPv6 support to current module - indeed a 2nd MIB module for IPv6 only. It is up to the WG (with MIB dcotor help maybe) to decide what the best path forward would be. Bert > Thanks > kalyan > > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: 01 September, 2003 06:53 > To: vrrp@ietf.org > Cc: v6ops@ops.ietf.org > Subject: [VRRP] MIB work > > > Pls take a look (and comment if needed) on > draft-ietf-v6ops-ipv4survey-ops-02.txt > > A few snippets > > ... snip .. > > 5.099 RFC 2787 Definitions of Managed Objects for the Virtual > Router Redundancy Protocol > > As stated in the Overview section: > > Since the VRRP protocol is intended for use with IPv4 > routers only, > this MIB uses the SYNTAX for IP addresses which is > specific to IPv4. > Thus, changes will be required for this MIB to interoperate in an > IPv6 environment. > > ... snip ... > > 7.3.27 VRRP MIB (RFC 2787) > > The problems have not been addressed and a new MIB should > be defined. > > .. snip .. > > I have told them that you are working on it, but you may want to keep > an eye on the survey doc as well. > > Thanks, > Bert > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp > From owner-v6ops@ops.ietf.org Wed Sep 3 11:37:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16335 for ; Wed, 3 Sep 2003 11:37:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uZfP-0003db-8l for v6ops-data@psg.com; Wed, 03 Sep 2003 15:35:31 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19uZfI-0003d6-7x for v6ops@ops.ietf.org; Wed, 03 Sep 2003 15:35:24 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19uZfH-0003nk-OS for v6ops@ops.ietf.org; Wed, 03 Sep 2003 08:35:23 -0700 Message-ID: <103150000.1062600281@classic.viagenie.qc.ca> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Date: Wed, 03 Sep 2003 10:44:41 -0400 From: Marc Blanchet To: Pekka Savola , juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: Re: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] - the input I got from the business side is that IPv6-only UE is not so real. They are v4 right now, and will be/are dual-stack now/later. So this scenario of IPv6-only device (not PDP context) seems to me not useful to consider and is the one that causes many issues. - if the UE is dual stack (anyway), then to save one PDP context, you tunnel the other IP version on the established PDP context. example: + your PDP context is IPv4. you need IPv6: tunnel v6 in v4. + your PDP context is IPv6. you need ipv4: tunnel v4 in v6. Marc. -- mercredi, septembre 03, 2003 15:11:14 +0300 Pekka Savola wrote/a ecrit: > Hi, > > This is an explicit request for feedback from the WG on a very important > issue. To quote Juha, > > So, could I get more wg comments / discussion on this issue, please!? How > should we mention UE based tunneling in this document, or should we not > mention it at all? > > That is, what kind of transition architecture should we suggest *in this > document* for 3GPP UE's? (of course, v6ops is not mandating what > vendors/users/operators will or will not do regardless of that advice.) > > Waiting for WG input.. > > Pekka > as WG co-chair > > ---------- Forwarded message ---------- > Date: Tue, 2 Sep 2003 17:00:31 +0300 > From: juha.wiljakka@nokia.com > To: karim.el-malki@ericsson.com, pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 > deployment [issue 6] > > Hi, > > ok, this is the last issue I have not yet commented on the list. The > comment sent by Pekka was about "IPv6 in IPv4" tunneling performed in the > UEs. Pekka does not want to require or recommend the implementation of > any automatic (or configured) tunneling methods in the UEs. Justification > for that: high number of IPv6-capable UEs, implementation footprint of > UE's is expected to be small, upgradeability of UE's is poor and we are > concerned about 3GPP *deployment* not early trials or piloting in this > document. Quite a long discussion followed including 3GPP architecture, > different PDP context types, roaming (which has not been discussed so much > in our document, anyway, 3GPP roaming is happening at layer 2, not IP > layer), etc. > > I must say that I agree on many points above - I do not believe that > tunneling in the UE is a scalable solution for a very large number of > terminals. What this section in our document tries to explain, is how to > solve such a situation when the operator does not support IPv6 in its > network (GGSN / SGSN / HLR is/are lacking IPv6 support) and the UE (user) > wants to access IPv6 services. And in that case you MAY use tunneling in > the UE to get IPv6 service. > > The recommended (longer term) approach for this problem is that the > operators deploy basic IPv6 support in their 3GPP networks (can in most > cases be done by making a sw upgrades) - and we must convince them to do > that as soon as possible! What do you think, could that be one key > recommendation in our document? Karim also commented that the soon > starting IMS period also makes basic IPv6 support reality in 3GPP > networks. And it removes the need for tunneling to be done in the UEs. > > So, could I get more wg comments / discussion on this issue, please!? How > should we mention UE based tunneling in this document, or should we not > mention it at all? > > The current text is: > > "However, the UE may attach to a 3GPP network, in which the Serving GPRS > Support Node (SGSN), the GGSN and the Home Location Register (HLR) support > IPv4 PDP contexts by default, but may not support IPv6 PDP contexts. If > the 3GPP network does not support IPv6 PDP contexts, and an application on > the UE needs to communicate with an IPv6(-only) node, the UE may activate > an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a > tunneling mechanism. This might happen in very early phases of IPv6 > deployment, or in IPv6 demonstrations and trials. > > The UE may be assigned a private or public IPv4 address when the IPv4 PDP > context has been activated, although it is more likely that it will > receive a private address (due to the lack of public IPv4 addresses). The > use of private IPv4 addresses in the UE depends on the support of these > addresses by the tunneling mechanism and the deployment scenario. In some > cases, public IPv4 addresses are required (one example is 6to4 [RFC3056]), > but if the tunnel endpoints are in the same private domain or the > tunneling mechanism works through IPv4 NAT (Network Address Translator), > private IPv4 addresses can be used (examples are [ISATAP] and [TEREDO]). > In general, if tunneling from the host is needed, ISATAP and 6to4 are > preferred and TEREDO is a mechanism of last resort when neither of these > are applicable. > > One deployment scenario example is using a laptop computer and a UMTS UE > as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop > computer and an IPv4 PDP context is activated. Although "IPv6 in IPv4" > tunneling can be either automatic or configured (by the user), the first > alternative is favored, because it is expected that most UE users just > want to use an application in their UE; they might not even care, whether > the network connection is IPv4 or IPv6." > > BR, > -Juha- > > -----Original Message----- > From: ext Karim El-Malki (HF/EAB) [mailto:karim.el-malki@ericsson.com] > Sent: 12 August, 2003 16:36 > To: 'Pekka Savola' > Cc: 'v6ops@ops.ietf.org' > Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 > dep loyment (fwd) > > > > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > > > > Or let me phrase this differently: > > > > > > > > > > > > Would roaming with 3GPP UE work if the roaming agreements > > > > > > would include > > > > > > an indication whether the foreign network > > supports the same > > > > > > PDP context > > > > > > types as the original network. > > > > > > > > > > > > I.e. the user can prefer those roaming partners which > > > > > > provide the services > > > > > > they want. That should be enough of an economic incentive. > > > > > > > > > > Basically the UE won't know until it tries to activate > > > > > a v6 connection and it gets refused. > > > > > > > > This seems like a potentially fatal design flaw. > > > > > > When I plug into Ethernet or WLAN I don't know if the network > > > supports IPv6 until I get an RA. > > > > Very true, but the expectations are entirely different (or > > that's my take > > at least). When I use my laptop and roam in the world, I generally > > *DON'T* expect IPv6 to be available. Hence, I'm equipped > > with some useful > > tools to enable IPv6 in the case network doesn't support it > > (e.g. 6to4 or > > configured tunnels). > > > > However, I think the expectation with 3GPP is entirely > > different: network > > supports IPv6, period. (And it would be unreasonable to > > assume the huge > > number of 3GPP devices to implement all the possible > > mechanisms required > > in every possible network scenario, be it 3GPP or regular > > old-fashioned > > Internet.) > > To be precise it's 3GPP IMS services that support IPv6. > I hope this will get all operators to support IPv6 for the > obvious reasons such as peer-to-peer connectivity. However > it is a different thing to expect any 3GPP network in general > to support IPv6 from day one. In fact there are commercial > 3GPP operators today (WCDMA and GSM) whose networks do not > support IPv6. Also, all I have been saying is to recommend > support for at least one type of tunnelling in this case. > ISATAP does what is needed IMO, so you don't need to support > every possible mechanism. > > > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > > > support in > > > > remote SGSN's/GGSN's be avoided ? > > > > > > You could do that, but it would be an overkill IMO to run PPP > > > over wireless. Since we're dealing with an expensive bandwidth > > > limited link it's not an attractive alternative. > > > > I think it would be useful to try to analyze the overhead of > > PPP in this > > scenario. It might not be that high, and it might only be > > the fallback > > solution where other mechanisms (i.e. finding an operator which would > > support IPv6, or refraining from using IPv6) would not work. > > That would be asking for equipment to support IPv4, IPv6 and PPP to > cater for a case which we hope will be rare. I would definitely limit > it to IPv4 and IPv6 so that people would have to tunnel for the special > cases and operators would have an incentive to migrate to native IPv6. > PPP will not solve the problem in a clean way and will be a disincentive > to migrate to native IPv6. > > > > For example today operators have gprs (IPv4) roaming agreements > > > with certain operators and only voice with others. > > > > Do you know if there is a regional perspective to this? > > That is, if there > > are multiple potential roaming partners in an area, could > > you say that > > they often support different capabilities? > > If they support different capabilties, it might be easier to > > conclude that > > it's reasonable to expect some of them to support IPv6 > > (while some others > > wouldn't) -- and then cycling through roaming partners until > > finding a > > correct might be a thinkable approach. > > Personally I wouldn't see why an operator would want to limit > its market to certain type of services in a certain area. >> From what I know the above cannot be taken as a rule. I don't > think I would design a standard based on a single business > model anyway. > > > > If you're in this special case (which will hopefully become > > > rare in future) and you want to have a way of using IPv6 services > > > then tunnelling is an attractive solution. > > > > What I'm looking for is a way or two to work around that > > requirement; I > > would loath to see a requirement to implement tunneing > > solutions on mobile > > terminals to make the service work in areas where the 3GPP operator > > doesn't suddenly support IPv6. > > > > I think we should try to ways to leverage 3GPP network's > > capabilities to > > ensure that either: > > > > 1) the user is able to obtain IPv6 PDP context somehow; > > this is an issue > > when roaming to some other operator's network. Whether from > > that operator > > or by trying someone else doesn't matter. > > > > 2) the user is able to work around the issue by requesting PPP PDP > > context until the roaming partner supports IPv6 > > > > 3) the user is able to stick to just using IPv4 when > > roaming in a network > > where there are no ways at all to get IPv6 using any means. > > Number 1) is unworkable as I've explained before. There are also business > issues that will make it useless in many cases (i.e. there is only > one data roaming partner which is common today). Number 2) isn't workable > either. You're not going to convince operators to get support for PPP > (which is normally not there today) only because they need IPv6; they > would get native IPv6 directly. Tunnelling is fine as a migration tool > and we've tested it. It's the only feasible choice and it will lead to a > migration to native IPv6. > > /Karim > > > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Sep 3 13:06:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21878 for ; Wed, 3 Sep 2003 13:06:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uaxQ-0009ob-Lz for v6ops-data@psg.com; Wed, 03 Sep 2003 16:58:12 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 19uaxO-0009o2-J1 for v6ops@ops.ietf.org; Wed, 03 Sep 2003 16:58:11 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 3 Sep 2003 12:58:06 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CCC@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Marc Blanchet'" , Pekka Savola , juha.wiljakka@nokia.com Cc: v6ops@ops.ietf.org Subject: RE: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechan isms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) Date: Wed, 3 Sep 2003 12:57:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > - if the UE is dual stack (anyway), then to save one PDP context, you > tunnel the other IP version on the established PDP context. example: > + your PDP context is IPv4. you need IPv6: tunnel v6 in v4. => Where does the IPv6 address come from? Unless you have a v6 PDP context you can't get an IPv6 address. > + your PDP context is IPv6. you need ipv4: tunnel v4 in v6. => Same for the IPv4 address. Hesham From owner-v6ops@ops.ietf.org Wed Sep 3 14:58:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29635 for ; Wed, 3 Sep 2003 14:58:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ucdJ-000025-ID for v6ops-data@psg.com; Wed, 03 Sep 2003 18:45:33 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.22) id 19uccl-000Pvk-Bu for v6ops@ops.ietf.org; Wed, 03 Sep 2003 18:44:59 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2003 11:56:57 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h83Iivlv025857 for ; Wed, 3 Sep 2003 11:44:58 -0700 (PDT) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALC36500; Wed, 3 Sep 2003 11:34:53 -0700 (PDT) Date: Wed, 3 Sep 2003 11:44:55 -0700 (PDT) From: Suresh K Satapati To: v6ops@ops.ietf.org Subject: Re: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk I would prefer to see as a recommendation: "the operators deploy basic IPv6 support in their 3GPP networks (can in most cases be done by making a sw upgrades)" And UE based tunneling to be removed entirely from the document. On Wed, 3 Sep 2003, Pekka Savola wrote: > Hi, > > This is an explicit request for feedback from the WG on a very important > issue. To quote Juha, > > So, could I get more wg comments / discussion on this issue, please!? How > should we mention UE based tunneling in this document, or should we not > mention it at all? > > That is, what kind of transition architecture should we suggest *in this > document* for 3GPP UE's? (of course, v6ops is not mandating what > vendors/users/operators will or will not do regardless of that advice.) > > Waiting for WG input.. > > Pekka > as WG co-chair > > ---------- Forwarded message ---------- > Date: Tue, 2 Sep 2003 17:00:31 +0300 > From: juha.wiljakka@nokia.com > To: karim.el-malki@ericsson.com, pekkas@netcore.fi > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 > deployment [issue 6] > > Hi, > > ok, this is the last issue I have not yet commented on the list. The > comment sent by Pekka was about "IPv6 in IPv4" tunneling performed in the > UEs. Pekka does not want to require or recommend the implementation of > any automatic (or configured) tunneling methods in the UEs. Justification > for that: high number of IPv6-capable UEs, implementation footprint of > UE's is expected to be small, upgradeability of UE's is poor and we are > concerned about 3GPP *deployment* not early trials or piloting in this > document. Quite a long discussion followed including 3GPP architecture, > different PDP context types, roaming (which has not been discussed so much > in our document, anyway, 3GPP roaming is happening at layer 2, not IP > layer), etc. > > I must say that I agree on many points above - I do not believe that > tunneling in the UE is a scalable solution for a very large number of > terminals. What this section in our document tries to explain, is how to > solve such a situation when the operator does not support IPv6 in its > network (GGSN / SGSN / HLR is/are lacking IPv6 support) and the UE (user) > wants to access IPv6 services. And in that case you MAY use tunneling in > the UE to get IPv6 service. > > The recommended (longer term) approach for this problem is that the > operators deploy basic IPv6 support in their 3GPP networks (can in most > cases be done by making a sw upgrades) - and we must convince them to do > that as soon as possible! What do you think, could that be one key > recommendation in our document? Karim also commented that the soon > starting IMS period also makes basic IPv6 support reality in 3GPP > networks. And it removes the need for tunneling to be done in the UEs. > > So, could I get more wg comments / discussion on this issue, please!? How > should we mention UE based tunneling in this document, or should we not > mention it at all? > > The current text is: > > "However, the UE may attach to a 3GPP network, in which the Serving GPRS > Support Node (SGSN), the GGSN and the Home Location Register (HLR) support > IPv4 PDP contexts by default, but may not support IPv6 PDP contexts. If > the 3GPP network does not support IPv6 PDP contexts, and an application on > the UE needs to communicate with an IPv6(-only) node, the UE may activate > an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a > tunneling mechanism. This might happen in very early phases of IPv6 > deployment, or in IPv6 demonstrations and trials. > > The UE may be assigned a private or public IPv4 address when the IPv4 PDP > context has been activated, although it is more likely that it will > receive a private address (due to the lack of public IPv4 addresses). The > use of private IPv4 addresses in the UE depends on the support of these > addresses by the tunneling mechanism and the deployment scenario. In some > cases, public IPv4 addresses are required (one example is 6to4 [RFC3056]), > but if the tunnel endpoints are in the same private domain or the > tunneling mechanism works through IPv4 NAT (Network Address Translator), > private IPv4 addresses can be used (examples are [ISATAP] and [TEREDO]). > In general, if tunneling from the host is needed, ISATAP and 6to4 are > preferred and TEREDO is a mechanism of last resort when neither of these > are applicable. > > One deployment scenario example is using a laptop computer and a UMTS UE > as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop > computer and an IPv4 PDP context is activated. Although "IPv6 in IPv4" > tunneling can be either automatic or configured (by the user), the first > alternative is favored, because it is expected that most UE users just > want to use an application in their UE; they might not even care, whether > the network connection is IPv4 or IPv6." > > BR, > -Juha- > > -----Original Message----- > From: ext Karim El-Malki (HF/EAB) [mailto:karim.el-malki@ericsson.com] > Sent: 12 August, 2003 16:36 > To: 'Pekka Savola' > Cc: 'v6ops@ops.ietf.org' > Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 > dep loyment (fwd) > > > > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > > > > Or let me phrase this differently: > > > > > > > > > > > > Would roaming with 3GPP UE work if the roaming agreements > > > > > > would include > > > > > > an indication whether the foreign network > > supports the same > > > > > > PDP context > > > > > > types as the original network. > > > > > > > > > > > > I.e. the user can prefer those roaming partners which > > > > > > provide the services > > > > > > they want. That should be enough of an economic incentive. > > > > > > > > > > Basically the UE won't know until it tries to activate > > > > > a v6 connection and it gets refused. > > > > > > > > This seems like a potentially fatal design flaw. > > > > > > When I plug into Ethernet or WLAN I don't know if the network > > > supports IPv6 until I get an RA. > > > > Very true, but the expectations are entirely different (or > > that's my take > > at least). When I use my laptop and roam in the world, I generally > > *DON'T* expect IPv6 to be available. Hence, I'm equipped > > with some useful > > tools to enable IPv6 in the case network doesn't support it > > (e.g. 6to4 or > > configured tunnels). > > > > However, I think the expectation with 3GPP is entirely > > different: network > > supports IPv6, period. (And it would be unreasonable to > > assume the huge > > number of 3GPP devices to implement all the possible > > mechanisms required > > in every possible network scenario, be it 3GPP or regular > > old-fashioned > > Internet.) > > To be precise it's 3GPP IMS services that support IPv6. > I hope this will get all operators to support IPv6 for the > obvious reasons such as peer-to-peer connectivity. However > it is a different thing to expect any 3GPP network in general > to support IPv6 from day one. In fact there are commercial > 3GPP operators today (WCDMA and GSM) whose networks do not > support IPv6. Also, all I have been saying is to recommend > support for at least one type of tunnelling in this case. > ISATAP does what is needed IMO, so you don't need to support > every possible mechanism. > > > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > > > support in > > > > remote SGSN's/GGSN's be avoided ? > > > > > > You could do that, but it would be an overkill IMO to run PPP > > > over wireless. Since we're dealing with an expensive bandwidth > > > limited link it's not an attractive alternative. > > > > I think it would be useful to try to analyze the overhead of > > PPP in this > > scenario. It might not be that high, and it might only be > > the fallback > > solution where other mechanisms (i.e. finding an operator which would > > support IPv6, or refraining from using IPv6) would not work. > > That would be asking for equipment to support IPv4, IPv6 and PPP to > cater for a case which we hope will be rare. I would definitely limit > it to IPv4 and IPv6 so that people would have to tunnel for the special > cases and operators would have an incentive to migrate to native IPv6. > PPP will not solve the problem in a clean way and will be a disincentive > to migrate to native IPv6. > > > > For example today operators have gprs (IPv4) roaming agreements > > > with certain operators and only voice with others. > > > > Do you know if there is a regional perspective to this? > > That is, if there > > are multiple potential roaming partners in an area, could > > you say that > > they often support different capabilities? > > If they support different capabilties, it might be easier to > > conclude that > > it's reasonable to expect some of them to support IPv6 > > (while some others > > wouldn't) -- and then cycling through roaming partners until > > finding a > > correct might be a thinkable approach. > > Personally I wouldn't see why an operator would want to limit > its market to certain type of services in a certain area. > >From what I know the above cannot be taken as a rule. I don't > think I would design a standard based on a single business > model anyway. > > > > If you're in this special case (which will hopefully become > > > rare in future) and you want to have a way of using IPv6 services > > > then tunnelling is an attractive solution. > > > > What I'm looking for is a way or two to work around that > > requirement; I > > would loath to see a requirement to implement tunneing > > solutions on mobile > > terminals to make the service work in areas where the 3GPP operator > > doesn't suddenly support IPv6. > > > > I think we should try to ways to leverage 3GPP network's > > capabilities to > > ensure that either: > > > > 1) the user is able to obtain IPv6 PDP context somehow; > > this is an issue > > when roaming to some other operator's network. Whether from > > that operator > > or by trying someone else doesn't matter. > > > > 2) the user is able to work around the issue by requesting PPP PDP > > context until the roaming partner supports IPv6 > > > > 3) the user is able to stick to just using IPv4 when > > roaming in a network > > where there are no ways at all to get IPv6 using any means. > > Number 1) is unworkable as I've explained before. There are also business > issues that will make it useless in many cases (i.e. there is only > one data roaming partner which is common today). Number 2) isn't workable > either. You're not going to convince operators to get support for PPP > (which is normally not there today) only because they need IPv6; they would > get native IPv6 directly. Tunnelling is fine as a migration tool and we've > tested it. It's the only feasible choice and it will lead to a migration > to native IPv6. > > /Karim > > > > > From owner-v6ops@ops.ietf.org Wed Sep 3 15:10:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00949 for ; Wed, 3 Sep 2003 15:10:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ucx4-0003Gu-DL for v6ops-data@psg.com; Wed, 03 Sep 2003 19:05:58 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19ucwQ-00039U-4Q for v6ops@ops.ietf.org; Wed, 03 Sep 2003 19:05:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h83J3aO23286; Wed, 3 Sep 2003 22:03:37 +0300 Date: Wed, 3 Sep 2003 22:03:36 +0300 (EEST) From: Pekka Savola To: "Wijnen, Bert (Bert)" cc: "'Kalyan.Tata@nokia.com'" , , Subject: RE: [VRRP] MIB work In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502331497@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 3 Sep 2003, Wijnen, Bert (Bert) wrote: > > -----Original Message----- > > From: Kalyan.Tata@nokia.com [mailto:Kalyan.Tata@nokia.com] > > Sent: woensdag 3 september 2003 4:01 > > To: bwijnen@lucent.com; vrrp@ietf.org > > Cc: v6ops@ops.ietf.org > > Subject: RE: [VRRP] MIB work > > > > > > Hi Bret, > > Thanks for the pointer. Browsing through the ID, it looks like they > > are proposing two different MIBs too. I contacted the authors about > > their input on the pending one MIB vs two MIBs issue. > > > I do not thing that they are proposing two MIB modules. > They say: > - Thus, changes will be required for this MIB to interoperate in an > IPv6 environment. > - The problems have not been addressed and a new MIB should > be defined. > > Maybe you conclude from that second bullet that they propose a 2nd MIB. > But I do not think that is the intention. A "new mib module" could > either be: > - a complete replacement that includes both IPv4 and IPv6 support > - a complete replacement that adds IPv6 support to current module > - indeed a 2nd MIB module for IPv6 only. > > It is up to the WG (with MIB dcotor help maybe) to decide what the > best path forward would be. I totally agree with the last paragraph -- it may be that Kalyan read a bit too much in the words in the survey document :-). The wording of the document is not always optimal. _We_ (as in, v6ops folks) don't know what's best for VRRP; we just try to fumble with words and say that there seems to be a problem with VRRP MIB. Whichever path you (VRRP WG) choose to take is probably best. Please send substitute text for the document when the path is chosen. Thanks, Pekka as v6ops co-chair From owner-v6ops@ops.ietf.org Wed Sep 3 15:13:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01412 for ; Wed, 3 Sep 2003 15:13:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ud1m-000420-2G for v6ops-data@psg.com; Wed, 03 Sep 2003 19:10:50 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19ud1G-0003wZ-Pk for v6ops@ops.ietf.org; Wed, 03 Sep 2003 19:10:18 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19ud1G-0009yL-9Z for v6ops@ops.ietf.org; Wed, 03 Sep 2003 12:10:18 -0700 Message-ID: <31590000.1062612751@classic.viagenie.qc.ca> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922CCC@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A01922CCC@ftmail.lab.flarion.com > MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Date: Wed, 03 Sep 2003 14:12:31 -0400 From: Marc Blanchet To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: RE: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechan isms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] -- mercredi, septembre 03, 2003 12:57:55 -0400 Soliman Hesham wrote/a ecrit: > > > > - if the UE is dual stack (anyway), then to save one PDP context, you > > tunnel the other IP version on the established PDP context. example: > > + your PDP context is IPv4. you need IPv6: tunnel v6 in v4. > > => Where does the IPv6 address come from? Unless you have > a v6 PDP context you can't get an IPv6 address. if you use some tunneling technique, then you will get one. Tunnel broker, as an example, will give the tunnel endpoint (UE) through the TSP session the ipv6 address to use over the tunnel. It could also send the ipv6 prefix in case the UE is a router/gateway to a personal network. Other tunnelling techniques will give the Ipv6 address (6to4 or teredo based on the ipv4 address). > > > + your PDP context is IPv6. you need ipv4: tunnel v4 in v6. > > => Same for the IPv4 address. again, as an example, tunnel broker with tsp and dstm will provide the iPv4 address. Marc. > > Hesham > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Sep 3 15:47:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03759 for ; Wed, 3 Sep 2003 15:47:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19udZ1-0009rb-RI for v6ops-data@psg.com; Wed, 03 Sep 2003 19:45:11 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 19udYQ-0009jb-9G for v6ops@ops.ietf.org; Wed, 03 Sep 2003 19:44:34 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 3 Sep 2003 15:46:12 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CCE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Marc Blanchet'" Cc: v6ops@ops.ietf.org Subject: RE: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechan isms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) Date: Wed, 3 Sep 2003 15:46:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > - if the UE is dual stack (anyway), then to save one > PDP context, you > > > tunnel the other IP version on the established PDP > context. example: > > > + your PDP context is IPv4. you need IPv6: tunnel v6 in v4. > > > > => Where does the IPv6 address come from? Unless you have > > a v6 PDP context you can't get an IPv6 address. > > if you use some tunneling technique, then you will get one. > Tunnel broker, > as an example, will give the tunnel endpoint (UE) through > the TSP session > the ipv6 address to use over the tunnel. It could also send > the ipv6 prefix > in case the UE is a router/gateway to a personal network. > Other tunnelling > techniques will give the Ipv6 address (6to4 or teredo based > on the ipv4 > address). => So a tunnel broker will be needed even if the GGSN is dual stacked. Hesham From owner-v6ops@ops.ietf.org Wed Sep 3 15:49:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03891 for ; Wed, 3 Sep 2003 15:49:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19udbG-000AEz-Te for v6ops-data@psg.com; Wed, 03 Sep 2003 19:47:30 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19udak-000AAh-Vl for v6ops@ops.ietf.org; Wed, 03 Sep 2003 19:46:59 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h83Jkfk04227; Wed, 3 Sep 2003 12:46:41 -0700 X-mProtect: <200309031946> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOtQ1Oe; Wed, 03 Sep 2003 12:46:40 PDT Message-ID: <3F56475B.5010904@iprg.nokia.com> Date: Wed, 03 Sep 2003 12:56:11 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Blanchet CC: Soliman Hesham , v6ops@ops.ietf.org Subject: Re: FEEDBACK REQUESTED -- RE: 3gpp-analysis-04: Transition mechan isms at UEs; 3GPP IPv6 deployment [issue 6] (fwd) References: <748C6D0A58C0F94CA63C198B6674697A01922CCC@ftmail.lab.flarion.com > <31590000.1062612751@classic.viagenie.qc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marc Blanchet wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to miss > and therefore delete posts by non-subscribers. if you wish to regularly > post from an address that is not subscribed to this mailing list, send a > message to -owner@ops.ietf.org and ask to have the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > >-- mercredi, septembre 03, 2003 12:57:55 -0400 Soliman Hesham > wrote/a ecrit: > > > >> > - if the UE is dual stack (anyway), then to save one PDP context, you >> > tunnel the other IP version on the established PDP context. example: >> > + your PDP context is IPv4. you need IPv6: tunnel v6 in v4. >> >>=> Where does the IPv6 address come from? Unless you have >>a v6 PDP context you can't get an IPv6 address. >> >> > >if you use some tunneling technique, then you will get one. Tunnel broker, >as an example, will give the tunnel endpoint (UE) through the TSP session >the ipv6 address to use over the tunnel. It could also send the ipv6 prefix >in case the UE is a router/gateway to a personal network. Other tunnelling >techniques will give the Ipv6 address (6to4 or teredo based on the ipv4 >address). > You should mention also isatap, in which the UE automatically discovers the address of the isatap router from which it may solicit IPv6 RAs. The UE can configure an IPv6 address via stateless autoconfiguration using a prefix advertised from the isatap router, or via stateful autoconfiguration using DHCPv6 (by treating the isatap router also as a DHCPv6 server/relay). It can also get an IPv6 prefix using DHCPv6 prefix delegation, i.e., in case the UE is a router/gateway. Authentication is assumed already performed by the IPv4 PDP context establishment. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Sep 3 16:47:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06910 for ; Wed, 3 Sep 2003 16:47:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ueT6-000JXC-Rs for v6ops-data@psg.com; Wed, 03 Sep 2003 20:43:08 +0000 Received: from [192.11.226.163] (helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.22) id 19ueSC-000JNj-VA for v6ops@ops.ietf.org; Wed, 03 Sep 2003 20:42:13 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h83KfvC18528 for ; Wed, 3 Sep 2003 15:42:04 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 3 Sep 2003 22:41:56 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023314B0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Kalyan.Tata@nokia.com'" , "Wijnen, Bert (Bert)" , vrrp@ietf.org Cc: v6ops@ops.ietf.org Subject: RE: [VRRP] MIB work Date: Wed, 3 Sep 2003 22:41:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Opps sorry about the misspelling Bert. > Thats OK. > Yes I agree that my conclusion was wrong, it was based on the "The > problems have not been addressed and a new MIB should be > defined." I assumed that "New" means a separate mib for IPv6 support. > Good that I made the clarification then > I haven't yet received a reply from the authors on what there > opinion or suggestion is based on the vrrp situation. > I was hoping that they will have a better picture having looked at > various protocols that have IP version dependencies. we probably should > come up with general guidelines while defining MIBs with IP > version dependencies. As can be seen from the survey ID, > there are a number of to be addressed MIBs. > Well, actually there is a general guidelines as per RFc3291 and as per draft-ietf-ops-mib-review-guidelines-02.txt > On the question of one MIB vs two MIBs : > I think ICMP faced the same problem as VRRP when defining the > MIB for ICMPv6. Both these are IP version specific and look > almost the same, have the same statistics etc. > Again, I am not saying that we should follow what the folks at ICMPv6 > did, we can use the thinking process and see is it "makes sense". > > RFC2466 defines the MIB for ICMPv6 > RFC2011 for IP MIB. > But those MIB documents are being revised and obsoleted by work in an IPv6MIB design team and the IPv6 WG. There are new IDs that you can look at. And they are using the new concenpts as per RFC3291. Bert > thanks > kalyan > > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: 03 September, 2003 03:23 > To: Tata Kalyan (NIC/MtView); vrrp@ietf.org > Cc: v6ops@ops.ietf.org > Subject: RE: [VRRP] MIB work > > > Kalyan > > MMM... you seem to keep calling me Bret, while it is Bert. > I am not offended, just noticed. > > Inline > > Thanks, > Bert > > > -----Original Message----- > > From: Kalyan.Tata@nokia.com [mailto:Kalyan.Tata@nokia.com] > > Sent: woensdag 3 september 2003 4:01 > > To: bwijnen@lucent.com; vrrp@ietf.org > > Cc: v6ops@ops.ietf.org > > Subject: RE: [VRRP] MIB work > > > > > > Hi Bret, > > Thanks for the pointer. Browsing through the ID, it > looks like they > > are proposing two different MIBs too. I contacted the > authors about > > their input on the pending one MIB vs two MIBs issue. > > > I do not thing that they are proposing two MIB modules. > They say: > - Thus, changes will be required for this MIB to > interoperate in an > IPv6 environment. > - The problems have not been addressed and a new MIB should > be defined. > > Maybe you conclude from that second bullet that they propose > a 2nd MIB. > But I do not think that is the intention. A "new mib module" could > either be: > - a complete replacement that includes both IPv4 and IPv6 support > - a complete replacement that adds IPv6 support to current module > - indeed a 2nd MIB module for IPv6 only. > > It is up to the WG (with MIB dcotor help maybe) to decide what the > best path forward would be. > > Bert > > Thanks > > kalyan > > > > -----Original Message----- > > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: 01 September, 2003 06:53 > > To: vrrp@ietf.org > > Cc: v6ops@ops.ietf.org > > Subject: [VRRP] MIB work > > > > > > Pls take a look (and comment if needed) on > > draft-ietf-v6ops-ipv4survey-ops-02.txt > > > > A few snippets > > > > ... snip .. > > > > 5.099 RFC 2787 Definitions of Managed Objects for the Virtual > > Router Redundancy Protocol > > > > As stated in the Overview section: > > > > Since the VRRP protocol is intended for use with IPv4 > > routers only, > > this MIB uses the SYNTAX for IP addresses which is > > specific to IPv4. > > Thus, changes will be required for this MIB to > interoperate in an > > IPv6 environment. > > > > ... snip ... > > > > 7.3.27 VRRP MIB (RFC 2787) > > > > The problems have not been addressed and a new MIB should > > be defined. > > > > .. snip .. > > > > I have told them that you are working on it, but you may > want to keep > > an eye on the survey doc as well. > > > > Thanks, > > Bert > > > > _______________________________________________ > > vrrp mailing list > > vrrp@ietf.org > > https://www1.ietf.org/mailman/listinfo/vrrp > > > From owner-v6ops@ops.ietf.org Wed Sep 3 17:27:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08813 for ; Wed, 3 Sep 2003 17:27:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uf6M-000PQC-2V for v6ops-data@psg.com; Wed, 03 Sep 2003 21:23:42 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19uf6A-000PMY-Ak for v6ops@ops.ietf.org; Wed, 03 Sep 2003 21:23:30 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19uf69-000Dob-Dz for v6ops@ops.ietf.org; Wed, 03 Sep 2003 14:23:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4D7B558499107545BB45044C63822DDE03873B56@mvebe001.americas.nokia.com> Subject: RE: [VRRP] MIB work Date: Wed, 3 Sep 2003 13:13:20 -0700 From: To: , Cc: X-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_20,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Opps sorry about the misspelling Bert. Yes I agree that my conclusion was wrong, it was based on the "The=20 problems have not been addressed and a new MIB should be defined." I = assumed that "New" means a separate mib for IPv6 support.=20 I haven't yet received a reply from the authors on what there=20 opinion or suggestion is based on the vrrp situation. I was hoping that they will have a better picture having looked at=20 various protocols that have IP version dependencies. we probably should come up with general guidelines while defining MIBs with IP version = dependencies. As can be seen from the survey ID, there are a number of=20 to be addressed MIBs.=20 On the question of one MIB vs two MIBs : I think ICMP faced the same problem as VRRP when defining the MIB for = ICMPv6. Both these are IP version specific and look almost the same, = have the same statistics etc. Again, I am not saying that we should follow what the folks at ICMPv6 did, we can use the thinking process and see is it "makes sense". RFC2466 defines the MIB for ICMPv6 RFC2011 for IP MIB. thanks kalyan -----Original Message----- From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: 03 September, 2003 03:23 To: Tata Kalyan (NIC/MtView); vrrp@ietf.org Cc: v6ops@ops.ietf.org Subject: RE: [VRRP] MIB work Kalyan =20 MMM... you seem to keep calling me Bret, while it is Bert. I am not offended, just noticed. Inline Thanks, Bert=20 > -----Original Message----- > From: Kalyan.Tata@nokia.com [mailto:Kalyan.Tata@nokia.com] > Sent: woensdag 3 september 2003 4:01 > To: bwijnen@lucent.com; vrrp@ietf.org > Cc: v6ops@ops.ietf.org > Subject: RE: [VRRP] MIB work >=20 >=20 > Hi Bret,=20 > Thanks for the pointer. Browsing through the ID, it looks like they=20 > are proposing two different MIBs too. I contacted the authors about > their input on the pending one MIB vs two MIBs issue.=20 > =09 I do not thing that they are proposing two MIB modules. They say: - Thus, changes will be required for this MIB to interoperate in an IPv6 environment. - The problems have not been addressed and a new MIB should=20 be defined. Maybe you conclude from that second bullet that they propose a 2nd MIB. But I do not think that is the intention. A "new mib module" could either be: - a complete replacement that includes both IPv4 and IPv6 support - a complete replacement that adds IPv6 support to current module - indeed a 2nd MIB module for IPv6 only. It is up to the WG (with MIB dcotor help maybe) to decide what the best path forward would be. Bert > Thanks > kalyan >=20 > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: 01 September, 2003 06:53 > To: vrrp@ietf.org > Cc: v6ops@ops.ietf.org > Subject: [VRRP] MIB work >=20 >=20 > Pls take a look (and comment if needed) on > draft-ietf-v6ops-ipv4survey-ops-02.txt >=20 > A few snippets >=20 > ... snip .. >=20 > 5.099 RFC 2787 Definitions of Managed Objects for the Virtual > Router Redundancy Protocol >=20 > As stated in the Overview section: >=20 > Since the VRRP protocol is intended for use with IPv4=20 > routers only, > this MIB uses the SYNTAX for IP addresses which is=20 > specific to IPv4. > Thus, changes will be required for this MIB to interoperate in an > IPv6 environment. >=20 > ... snip ... >=20 > 7.3.27 VRRP MIB (RFC 2787) >=20 > The problems have not been addressed and a new MIB should=20 > be defined. >=20 > .. snip .. >=20 > I have told them that you are working on it, but you may want to keep > an eye on the survey doc as well. >=20 > Thanks, > Bert=20 >=20 > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www1.ietf.org/mailman/listinfo/vrrp >=20 From owner-v6ops@ops.ietf.org Wed Sep 3 20:28:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20449 for ; Wed, 3 Sep 2003 20:28:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uhuZ-0000wF-Kt for v6ops-data@psg.com; Thu, 04 Sep 2003 00:23:43 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtp (Exim 4.22) id 19uhsD-0000Zu-K1; Thu, 04 Sep 2003 00:21:17 +0000 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h840Mhhs001086; Wed, 3 Sep 2003 17:22:44 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h840L9R20962; Wed, 3 Sep 2003 17:21:09 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 3 Sep 2003 17:21:08 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: v6ops@ops.ietf.org cc: ops-area@ops.ietf.org, pekkas@netcore.fi, andreas.bergstrom@hiof.no Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 3 Sep 2003, Pekka Savola wrote: > Thanks for a *very* extensive review of the ops document. I'll > try to respond to your points somehow inline.. > > I've included all of your comments which may need addressing in > the quote, so that it's easier for the document editor to go > through the spec. I'm going to trim this down just to the stuff where we still disagree. > Three generic comments: > 1) (now) HISTORIC documents being included. > > Unfortunately, the survey was executed in a non-optimal > method, and these historic statements still appear here, due to > examining the RFC's in the "vacuum". (The best way to do the > analysis in the first place would have been to skip those which > have been obsoleted, made historic, etc., but we lack the time > machine.. :-) Actually, that's not entirely true ... some of the reclassifications (in particular for RFC 1157, SNMPv1, and RFC 1901, SNMPv2c) postdate the original work. > I'd like to go through this with a "minimum update" policy, and > we state that the document is historic in section 7. A "minimum update" policy that precludes putting in the most recent versions of important specifications is not a good policy, IMHO, as it would seriously compromise the utility and credibility of the document. If I see a lot of stuff in it that I KNOW is obsolete, then why should I (as a non-v6ops type) pay attention to it? > Unless there is strong feeling that we should really throw away > these historic documents completely (implies that we should look > at which documents made them historic, replacement documents > etc.), I'd keep them here for now. I find it hard to accept your proposal in its entirety, but I will agree to this much: I won't ask the editor to re-survey the status of all the RFCs. I will, however, continue to push to have something done about the specific document that Juergen Schoenwalder and I have explicitly identified as HISTORIC documents. Now, my original reason for asking that the documents identified as HISTORIC just be dropped was to make minimum work for the readers of the document. And since the document needs to be updated anyway, it seems to be a fairly straightforward matter for the editor to just delete those sections. On the other hand, if the WG feels that there is some value in keeping the parts of sections 3, 4, and 5 for the HISTORIC specs that are still widely deployed then I won't disagree. But it will be necessary to make sure the text is accurate (I will try to help in further comments below) and then in Section 7 you must replace ALL the verbiage for such specs with a statement like this: This document has been reclassified as HISTORIC. It has been replaced by . If there are cases where there is no replacement then the second sentence can be left out. But as for things that are not now and have never been widely deployed (such as te DNS MIBs), I don't see any reason to keep them in the best strategy; and even if you do you should not bother wasting the reader's time by spelling out their deficiencies. You should leave such things decently buried in the document graveyard and not exhume the corpses for forensic examination. > 1.b) new RFC's since about RFC3200 (in most part, obsoleting or > making historic those that are still analyzed) have not been > taken into consideration. > > The analysis was Phil's work, who has retired. We don't have > resources anymore to do more substantial work anymore, so we > prefer to keep doing minimum updates. Allow me to propose this compromise: fix the sections on HISTORIC documents, or documents that have been updated by newer RFCs, where the reviewers have identified a specific fix, but accept no obligation to re-survey all the RFCs. Can you and the editor live with that? I think it's understood that the subject matter is too much of a moving target for the survey to remain cmpletely accurate for very long. > 2) protocol/specification. I totally agree that we should refer the > RFC's by "specification" because that's generic enough to cover any RFC. > > 3) MIB acronyms like TRANS-MIB in: > > 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network > Management Protocol (SNMPv2) (TRANS-MIB) > > .. these do not appear in the original RFC's, but are invented by > RFC-editor for some RFC indexes. My opinion is that we should get > rid of these bogus abbreviations completely, but I would also be > OK with it if they're changed to be correct. Whatever works for > you.. Getting rid of the acronyms and relying on RFC title and number alone would suit me just fine. But if they remain the acronyms must be the right ones (MIB module names in the case of MIB modules). Note that in some cases an acronym appears twice, once in the original title, and the once again and the MIB or protocol name; in those cases remove only the second occurrence. > On Sun, 31 Aug 2003, C. M. Heard wrote: > [...] > > There are some important technical specifications that do not fall into > > any of these classifications. For instance, RFC 1215, which is part of > > the (obsolescent) SMIv1 specification, is an Informational RFC. And RFC > > 3584 (the coexistence document that replaces RFC 2576) is a BCP. I'm > > not aware of any other such specs, but some may exist. Certainly it > > behooves us to include at least those two in the survey. One possible > > way to handle RFC 1215 would be to include it in Sections 3 and 7 along > > with its companion SMIv1 documents (RFCs 1155 and 1212). I'm not really > > sure what to do for RFC 3584; maybe a separate section for BCPs would be > > appropriate. One thing for sure, it would not be a good idea to lump > > all non-standards-track stuff (BCP + informational + experimental) > > together. > > The problem here is that it would be difficult for *us* (read: those > non-experts in the subject matter) to decide what is relevant and what is > not. The analysis was already done by Phil, and we don't have resources > to extend it. OK, I understand that. > But I think we can address this situation in practical terms. Where > applicable, add notions about these documents in the "analysis", section > 7, like: > > 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 2576) > > There are no real issues that can be resolved. > > ==> add a sentence like: > > The document is obsoleted by RFC 3584. > > (or something else, if RFC3584 addresses the concerns) > > .. that way, we could have somekind of a "forward pointer" even to > informational/BCP documents which may be relevant. > > Would this satisfy your concern? If so, could you submit some wording > that would be appropriate for these cases? I'm not too keen on the specific suggestion above. But, given your lack of resources, I can accept that you would only address the specific documents mentioned above (namely RFCs 1212, 1215, and 3584). I can also accept the following editorial strategy: mention RFC 1215 in conjunction with 1155 and 1212 (since together they form a package, and really are part of the same de-facto standard), replace all mentions of RFC 2576 with RFC 3584, move RFC 3584 to Section 3, and re-title Section 3 as follows: 3.0 Full Standards and BCPs That would entail an addition to the lead-in text of that section: > > | Full Internet Standards (most commonly simply referred to as > > | "Standards") are fully mature protocol specification that are widely > > | implemented and used throughout the Internet. The OPS area has one technical specification (RFC 3584) which is classified as a Best Current Practice, or BCP. That is another "terminal" classification. It was used for this specfication because it was deemed mature and unlikely to see further evolution, but did not meet the formal requirements for Full Standard. Suggested text for the other stuff will appear below. > > | 3.1 RFC 1157 Simple Network Management Protocol > > | > > | Beginning in Section 3.2.6.3.2 atTable Object Type Names thru the rest > > | of Section 3 there are numerous references to the use of IPv4 addresses > > | as part of OIDs. OK, if we want to keep this one (which would be justified because of its wide deployment) then make this fix: s/as part of OIDs/for identification of object instances/ Technically, the use of the term "OIDs" is correct here, but I much prefer the more precise language. > > | Section 4. Protocol Specification specifies the format of an SNMP > > | packet which uses the overall format of: > > | > > | RFC1157-SNMP DEFINITIONS ::= BEGIN > > | IMPORTS > > | ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks > > | FROM RFC1155-SMI; > > | > > | > > | Section 4.1.3.1. Example of Table Traversal has many uses of IPv4 > > | addresses in its example of table transversal. > > | > > | Section 5. Definitions reiterates the use of IPv4 addresses. > > | > > | RFC1157-SNMP DEFINITIONS ::= BEGIN > > | > > | IMPORTS > > | ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks > > | FROM RFC1155-SMI; The above is OK. > I'd like to go through this with a "minimum update" policy, and we state > that the document is historic in section 7. > > Is that good enough? For this one, yes. > > | 3.2 RFC 1155 Structure of Management Information > > | > > | Section 3.2.3.2. IpAddress defines the following: > > | > > | This application-wide type represents a 32-bit internet address. It > > | is represented as an OCTET STRING of length 4, in network byte-order. > > | > > | There are several instances of the use of this definition in the rest of > > | the document. > > > > There should also be a subsection for RFC 1212, and perhaps also RFC > > 1215, since RFCs 1155 and 1212 form STD 16, and together with RFC > > 1215 define SMIv1. > > We could add here a sentence like: > > Note that RFC 1212 and RFC 1215, which have been omitted from analysis, > together with this specification define SMIv1. The same issues apply > to all of them. > > would that be OK? Another piece of text? I can live with that, if we fix the analysis sections for 1157/1155 properly. See below. > (I'm purposely trying to "wave away" the need for formal analysis > sections..) I won't quite let you get away with that but I will write the analysis for you :) > > | 3.4 RFC 1643 Definitions of Managed Objects for the Ethernet-like > > | Interface Types > > | > > | There are no IPv4 dependencies in this specification. > > > > In [a] recent protocol action [...] the IESG reclassified > > RFC 1643 to HISTORIC [...]. I therefore suggest that RFC > > 1643 be dropped from this survey. > > Due to the way survey is done, I'd like to keep it as is (minimum > changes) I don't understand why that's a consideration > [but] we could add a sentence like: > > Moreover, RFC 1643 has been superseded by other MIBs and reclassified > to HISTORIC. > > If that's what you'd prefer? I do not like this proposal. I know that you have not had the time to read draft-ietf-hubmib-1643-to-historic-01.txt, but the gist of it is that the technical content of RFC 1643 has been subsumed by RFC 2665 (actually by its predecessors), which is already part of the survey. I don't understand why it is so hard to just drop RFC 1643 from the survey. However, if you insist on keeping it, could you rewrite the while section like this: 3.4 RFC 1643 Definitions of Managed Objects for the Ethernet-like Interface Types This specification has been reclassified as an HISTORIC document and is not considered in this discussion. > > There is no mention of RFC 2580 (which is also an OPS Area Internet > > Standard). I don't think there are any IPv4 dependencies in RFC 2580, > > but it should be mentioned here for sake of completeness. > > It's PS, so I guess it should be included, with like: You mean FS > 3.6 RFC 2580 Conformance Statements for SMIv2 > > There are no IPv4 dependencies in this specification. > > .. if you agree that that is a true statement? Sounds OK to me. Note that the section number will need to change. > > RFCs 3411, 3412, 3413, 3414, and 3415 are also Internet Standards; > > they replace RFCs 2571, 2572, 2573, 2574, and 2575. Please move > > the sections for those last five RFCs here and update the RFC numbers. > > I don't think the editor should have moved RFC3416 etc. here in the first > place, but as it has already been done, I see no harm doing the same for > those five other RFCs either. I do think that the editor should have moved RFC 3416 stuff here :-) > > | 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network > > | Management Protocol (SNMPv2) (TRANS-MIB) ... > > s/TRANS-MIB/SNMPv2-TM/ > > I do not know why those (TRANS-MIB)'s are there in the first place, but in > case there is a strong reason to keep them there, I vote for removing them > completely. What we want is that the title here is identical with the RFC > title. > > My suggestion: remove all of (*-MIB) from the document. Would that be > good for you? As I said up above, using the exact RFC title with no extra adornment works for me. ... > > Wordsmith the last paragraph: > > > > Section 8.1, "Usage Example," also contains examples which uses IPv4 > > addresse, but it has no significance in the operation of the > > specification. > > There is typo above, but in practice OK. > > s/IPv4 addresse/an IPv4 address/ ? Yep. Sorry :-( ... skipping down to the proposed standards ... > > | 5.010 RFC 1441 Introduction to version 2 of the Internet-standard > > | Network Management Framework (SNMPv2) > > | > > | There are no IPv4 dependencies in this protocol. > > > > This document is HISTORIC and should be removed from the survey > > (otherwise, I'd say s/protocol/specification/) > > I'd rather keep it in, if you prefer, just stating something like: > > Moreover, the document has been reclassied HISTORIC. No. Absolutely not. This document has been HISTORIC since 1996 (when 1901-1907 appeared) and should never have been part of the original survey. I repeat again: why do you insist on keeping this stuff? It does not help your readers or your editor. > > | 5.018 RFC 1515 Definitions of Managed Objects for IEEE 802.3 > > | Medium Attachment Units (MAUs) > > | > > | There are no IPv4 dependencies in this protocol. > > > > This specification will soon be officially obsoleted by > > draft-ietf-hubmib-mau-mib-v3-04.txt, which will also > > replace RFC 2668. Since draft-ietf-hubmib-mau-mib-v3-04.txt > > is in the RFC Editor's queue as we speak, I think it would > > be reasonable to drop RFC 1515 from the survey. Note that > > it actually should have been obsoleted by RFC 2668 but was > > not, owing to an oversight. > > (s/protocol/specification/ -- Andreas, please check that this is OK > everywhere!) > > I suggest keeping it for now, but if you prefer, adding something like: > > Moreover, this document has been Obsoleted. I don't like particularly like the idea, but I can live with keeping it if you insist; since the replacement for RFC 2668 is not yet published, this RFC 1515 is not yet "officially" obsoleted. If you do keep the section, here is the rewrite I'd like to see: 5.018 RFC 1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) This document is not considered in this discussion because it should have been obsoleted by RFC 2668; due to an oversight, however, it was not. That oversight will be corrected when the replacement for RFC 2668 (now in the RFC Editor's queue) is published. > > | 5.020 RFC 1611 DNS Server MIB Extensions (DNS-S-MIB) > > ... > > | 5.021 RFC 1612 DNS Resolver MIB Extensions (DNS-R-MIB) > > ... > > > > As Juergen Schoenwaelder has pointed out, RFCs 1611 and 1612 > > have been declared HISTORIC and should be dropped from the > > survey. (Once a document has been declared HISTORIC, it is > > no longer a standard of any kind.) > > Yeah, I would hope Phil would have known that when he made his analysis > :-( It wasn't Phil's error, since the reclassification from PS to HISTORIC postdated his work. However ... > I think we should keep these here (for consistency), but if you prefer, > cut the unnecessary text out and just say something like: I disagree, as all it does is waste space in the document and divert the reader's attention. Unlike 1157, 1643, and 1515, we don't even have the excuse that these things are widely deployed. They aren't: see RFC 3197 Applicability Statement for DNS MIB Extensions, R. Austein, November 2001, which says: In view of the community's apparent total lack of interest in deploying these MIB extensions, we recommend that RFCs 1611 and 1612 be reclassified as Historical documents. In view of this I can see no reason to waste even one character of text on these documents ... > 5.021 RFC 1612 DNS Resolver MIB Extensions > > There are multiple IPv4 dependencies in this specification. > > (and not waste paper in going into details when we say in section 7 that > it's historic..) ... but if you absolutely must keep them (which is not quite as unjustified as 1441, which was simply an error from the beginning) how about this: 5.020 RFC 1611 DNS Server MIB Extensions (DNS-S-MIB) This specification has been reclassified as an HISTORIC document and is not considered in this discussion. 5.021 RFC 1612 DNS Resolver MIB Extensions (DNS-R-MIB) This specification has been reclassified as an HISTORIC document and is not considered in this discussion. and then removing the corresponding analysis in Section 7. At least this will spare us an examination of the corpses. > > | 5.029 RFC 1759 Printer MIB (Print-MIB) > > > > s/Print-MIB/Printer-MIB/ > > remove ? > > > | There are no IPv4 dependencies in this specification. > > > > Note: this document is slated to be replaced someday "soon" by > > . When you issue an update > > of this draft, check the status of RFC 1759 to see if it has > > been replaced. > > Ok, one could add, if you prefer, something like: > > Moreover, this specification is being Obsoleted. I was just suggesting to check ftp://ftp.isi.edu/in-notes/rfc-index.txt as the document was being edited to see if the section should be re-titled with a new RFC number. If you don't care to impose that burden on the editor I would rather leave the section as-is. The moving target nature of the subject matter makes some things like this unavoidable (even if the drafts are up-to-date when approved, they'll have plenty of time to grow stale while sitting in the RFC Editor's publication queue). > > | 5.034 RFC 2020 IEEE 802.12 Interface MIB (802.12-MIB) > > > > s/802.12-MIB/DOT12-IF-MIB/ > > remove ? > > > Note: the actual title is "Definitions of Managed Objects for > > IEEE 802.12 Interfaces" ... I've not been checking this; does > > it matter? > > we should use the correct title, I think. So out would become (modulo a possible section number change) 5.034 RFC 2020 Definitions of Managed Objects for IEEE 802.12 Interfaces There are no IPv4 dependencies in this specification. OK by me. > > | 5.058 RFC 2493 Textual Conventions for MIB Modules Using > > | Performance History Based on 15 Minute Intervals > > | > > | There are no IPv4 dependencies in this specification. > > > > Note: this document is due to be replaced by RFC 3593, > > which will be a Draft Standard and will have the same title. That has now happened: the announcement has just been sent to the IETF-Announce list, and RFC 3593 is now available in the on-line repositories since yesterday. So, please change the RFC number from 2493 to 3593 and move this sub-section from the PS part to the DS part. Yes, I know this contradicts your minimal change doctrine but I don't agree with that doctrine. > > | 5.066 RFC 2558 Definitions of Managed Objects for the SONET/SDH > > | Interface Type > > | > > | There are no IPv4 dependencies in this protocol. > > > > s/protocol/specification/ > > > > Note: this document is due to be replaced by RFC 3592, > > which will be a Draft Standard and will have the title > > "Definitions of Managed Objects for the Synchronous > > Optical Network/Synchronous Digital Hierarchy (SONET/SDH) > > Interface Type" > > If you prefer, we could add something like: > > Moreover, the document is obsoleted by RFC 3592. > > (or even move up to the draft standards if you really, really want) I really, really, want, especially since RFC 3592 is now available in the on-line repositories (cf. 2493 -> 3593 above). The relocated section should just say: 4.xxx RFC 3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type There are no IPv4 dependencies in this specification. > > | 5.068 RFC 2562 Definitions of Protocol and Managed Objects for > > | TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) > > | (TN2370E-RT) > > > > remove "(TN3270E-RT)" at the end > > remove both ? :-) No, "(TN3270E-RT-MIB)" is actually part of the official title. > > | Several OIDs rely on imports from RFC 2561 and therefore the > > | protocol is both IPv4 and IPv6 aware. > > > > rewrite: > > > > This MIB module inherits IP version-independence by virtue of > > importing the appropriate definitions from RFC 2561. > > ok Now, since I promised specific text for documents that have been updated since Phil's original survey: > > | 5.070 RFC 2576 Coexistence between Version 1 Version 2 and Version > > | 3 of the Internet-standard Network Management Framework (SNMP) > > > > remove "(SNMP)" > > ok for both s/2576/3584/ Move to Section 3 as discussed above and assign a new sub-section number. > > | This document states: > > | > > | (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST > > | be changed to IpAddress. Note that the use of NetworkAddress in > > | new MIB documents is strongly discouraged (in fact, new MIB > > | documents should be written using SMIv2, which does not define > > | NetworkAddress). The equivalent text in RFC 3584 is: (10) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress). > > | and defines the OID: > > > > s/OID/object/ > > ok > > > | snmpTrapAddress OBJECT-TYPE > > | SYNTAX IpAddress > > | MAX-ACCESS accessible-for-notify > > | STATUS current > > | DESCRIPTION > > | "The value of the agent-addr field of a Trap PDU which > > | is forwarded by a proxy forwarder application using > > | an SNMP version other than SNMPv1. The value of this > > | object SHOULD contain the value of the agent-addr field > > | from the original Trap PDU as generated by an SNMPv1 > > | agent." > > | ::= { snmpCommunityMIBObjects 3 } This is unchanged in RFC 3584. > > | This clearly points out a lack of IPv6 awareness in this specification. > > > > That last sentence is incorrect. The presence of this stuff > > is not because the specification has a lack of IPv6 awareness; > > it is there because it is necessary to allow a MIB translator > > or a proxy forwarder to do its job ... and that job is to allow > > legacy versions of the SNMP (SNMPv1 and SNMPv2c, both now Historic > > protocols) to coexist with SNMPv3. I think Randy Presuhn has > > complained about this before. Here is the suggested replacement: > > > > Since purpose of this document is to describe how legacy > > specifications with IPv4 dependencies (SMIv1, SNMPv1, and > > SNMPv2c) can coexist with current ones (SMIv2 and SNMPv3), > > the IPv4 dependencies documented above are acceptable and, > > indeed, unavoidable. > > > > In addition, note that RFC 2576 has been replaced by RFC 3584, > > which is a BCP. So the title needs to changed, and sub-section > > itself needs to be moved. > > ok Glad you agree, details filled in above. > > | 5.083 RFC 2665 Definitions of Managed Objects for the > > | Ethernet-like Interface Types (MIB) > > > > s/MIB/EtherLike-MIB/ > > remove? > > > | There are no IPv4 dependencies in this specification. > > > > Note: this document is due to be replaced by > > draft-ietf-hubmib-etherif-mib-v3-03.txt, which > > the IESG recently approved as a Proposed Standard. > > When you issue an update of this draft, check the > > status of RFC 2665 to see if it has been replaced. > > ok, could add something like, if you prefer: > > Moreover, this specification is being Obsoleted. I'd rather not add that text; it would probably be better to just leave it alone. Please see the note under RFC 1759 for more explanation. > > | 5.085 RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium > > | Attachment Units (MAUs) (MAU-MIB) > > | > > | There are no IPv4 dependencies in this specification. > > > > Note: this document is due to be replaced by > > draft-ietf-hubmib-mau-mib-v3-04.txt, which the > > IESG recently approved as a Proposed Standard. > > When you issue an update of this draft, check the > > status of RFC 2668 to see if it has been replaced. > > like above yes, like above :-) > > | 5.092 RFC 2726 PGP Authentication for RIPE Database Updates > > | > > | There are no IPv4 dependencies in this protocol. > > > > Is this actually an OPS Area specification? > > this could be moved to security, that's true. however, we felt that RPSL > was so strongly OPS stuff, so this could logically belong here too > (doesn't really matter as there are no dependencies). I was just asking. If you think it's in the right place leave it (RPSL evidently is, according to Bert Wijnen). > > | 5.093 RFC 2737 Entity MIB (Version 2) ... > > [ ... ] I therefore propose to replace the preceding > > two paragraphs with this: > > > > There are no IPv4 dependencies in this specification. > > perhaps this could be spelled out a bit more, but ok. > > > Note: this RFC is due to be replaced by draft-ietf-entmib-v3-03.txt > > or a successor; when published it will be a Draft Standard. Check > > ftp://ftp.isi.edu/in-notes/rfc-index.txt before updating this memo > > to determine if this has happened. > > would you prefer to add a piece of text on that? No, see note under RFC 1759. > > | 5.098 RFC 2769 Routing Policy System Replication (RPSL) > > > > remove "(RPSL)" > > agree! > > > > > | There are no IPv4 dependencies in this protocol. > > > > Is this an OPS Area spec? It looks like a routine area > > spec to me. > > routing area, yes, could be a target. but all of the RPSL stuff is in > here, so perhaps it's best to keep it here esp. because there are no > dependencies. But ok to move if you prefer. Bert Wijnen agrees that it belongs here (I was just asking, since it seemed "suspicious"). > > | 5.102 RFC 2837 Definitions of Managed Objects for the Fabric Element > > | in Fibre Channel Standard > > | > > | There are no IPv4 dependencies in this protocol. > > > > s/protocol/specification/ > > ok (I still can't figure out why when the editor changed some of those to > "specification" he didn't change all.. but have been a bug or something..) > > > | 5.103 RFC 2851 Textual Conventions for Internet Network Addresses > > | > > | This MIB defines a new set of OIDs for that allow new MIB's to > > | use multiple versions of IP. Currently IPv4 and IPv6 addressing > > | is defined. Update of the many MIBs previously identified as > > | having IPv4 dependencies could easily be updated using this new > > | set of IP address abstractions. s/OIDs/TCs/ or if you prefer s/OIDs/textual conventions/ > > This document has been replaced by RFC 3291 (also a proposed > > standard). Please update this subsection accordingly. > > does it change the content of the issue, described above? > > ok to change. Nothing needs to be changed except the RFC number. You could use the text as-is. > > | 5.113 RFC 2959 Real-Time Transport Protocol Management > > | Information Base > > | > > | There are numerous uses of the included TAddress Syntax which is > > | IPv4 dependent as noted above. > > | > > | For example: ... > > | There are a total of 8 instances of this. > > > > As explained above under 5.093, this does not necessarily mean that > > there is an IPv4 dependency. Please re-evaluate this MIB module and > > update this section accordingly. I'd bet that this spec doesn't really > > have any IPv4 dependencies after all. > > we don't have resources for re-evaluation, unfortunately. unless someone > more knowledgeable does it, we'll have to keep it as is. OK, I just had a quick look at this RFC and it looks OK to me ... the object rtpSessionDomain, which is of type TDomain, allows IPv6 transport to be represented by all the TAddress objects. So here's the rewrite: 5.113 RFC 2959 Real-Time Transport Protocol Management Information Base There are no IPv4 dependencies in this specification. (modulo a probable sub-section number change). > > | 5.121 RFC 3084 COPS Usage for Policy Provisioning (COPS-PR) > > | (COPS-PR) > > > > remove redundant "(COPS-PR)" > > > > | This is an IPv4 only protocol. A version for IPv6 must be defined. > > > > s/must be/may ned to be/ try that again: s/must be/may need to be/ Please consider adding a sub-section for this brand-new proposed standard: 5.xxx RFC 3591 Definitions of Managed Objects for the Optical Interface Type There are no IPv4 dependencies in this specification. ... skipping down to the experimental RFCs ... > > | 6.06 RFC 1901 Introduction to Community-based SNMPv2 (SNMPV2CB) > > | > > | There are no IPv4 dependencies in this protocol. > > > > RFC 1901 is now HISTORIC and should be dropped from this survey. > > should keep it here, but could add a statement here, like: > > Moreover, this specification has been reclassified HISTORIC. If you insist on keeping it, here's the appropriate rewrite: 6.06 RFC 1901 Introduction to Community-based SNMPv2 (SNMPv2c) There are no IPv4 dependencies in this protocol. (Note that it has been reclassified as HISTORIC but is still widely deployed.) In case you keep this leave "(SNMPv2c)" in the section heading, since it's probably better known under that name than any other. > > | 6.07 RFC 1909 An Administrative Infrastructure for SNMPv2 > > | (SNMPV2AI) > > | > > | There are no IPv4 dependencies in this protocol. > > > > RFC 1909 is now HISTORIC and should be dropped from this survey. > > > > | 6.08 RFC 1910 User-based Security Model for SNMPv2 (SNMPV2SM) > > | > > | There are no IPv4 dependencies in this protocol. > > > > RFC 1910 is now HISTORIC and should be dropped from this survey. > > same for both of these These are not now and never were very widely deployed, so keeping them in the survey does not IMnsHO serve a useful purpose. But, if you do insist on keeping them around, here are the rewrites: 6.07 RFC 1909 An Administrative Infrastructure for SNMPv2 This specification has been reclassified as an HISTORIC document and is not considered in this discussion. 6.08 RFC 1910 User-based Security Model for SNMPv2 (SNMPV2SM) This specification has been reclassified as an HISTORIC document and is not considered in this discussion. ... skipping down to the analysis section ... > > | 7.1 Standards > > | > > | 7.1.1 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) > > | > > | The limitations identified have been addressed; RFC 1157 is HISTORIC, > > | RFC1155 is obsoleted by RFC 2578-2580, and RFC1213 has been split to > > | multiple modules which have been seen to. > > > > The above actually concerns three separate STDs. > > > > STD 15, RFC 1157, is SNMPv1, but it has been retired ... that is, it has > > been reclassified as HISTORIC and therefore is no longer an Internet > > Standard. So it should be dropped from the survey. > > disagree, due to the process differences (if we just had the time > machine..) As I said above, I agree that there is some practical justification for keeping RFC 1157 in the survey since it is still widely deployed, and I can live with your proposed rewrite, modulo a little wordsmithing. Here goes: 7.1.1 STD 15 Simple Network Management Protocol (RFC 1157) The limitations identified have been addressed: RFC 1157 has been reclassified as HISTORIC, and the replacement documents (RFCs 3411-3415) are compatible with both IPv4 and IPv6. 7.1.2 STD 16, Structure of Management Information (RFCs 1155 and 1212) > > RFCs 1155 and RFCs 1212 (along with the informational document RFC > > 1215) define SMIv1. These documents have been superseded by RFCs > > 2578, 2579, and 2580 which define SMIv2. Since SMIv1 is no longer > > being used as the basis for new IETF MIB modules, the limitations > > identified in this Internet Standard do not require any action. > > ok. 7.1.3 STD 17, Management Information Base MIB II (RFC 1213) > > The limitations identified are being addressed: the IP group, > > the ICMP group, the TCP group, and the UDP group are being > > replaced by IP version-independent MIB modules now in development > > in the IPv6 working group (for more details see the entries > > below for RFCs 2011, 2012, 2013, and 2096). No replacement is > > being contemplated for the EGP group because EGP is a historic > > protocol that is no longer in significant use in the Internet. > > ok. ... skipping down to the draft standards ... > > | 7.2.3 RIPv2 MIB (RFC 1724) > > | > > | See Section 7.1.24. This problem is currently being addressed by the > > | RIP WG and an ID exists (draft-ietf-rip-mib-01.txt). > > > > Where is Section 7.1.24? > > routing, now.. So update the cross-reference, or remove it. > > I agree with the 2nd sentence, except > > that the draft is now draft-ietf-rip-mib-01.txt; it stands alone > > quite nicely. > > the draft name you mentioned is the same as listed, perhaps you meant > something else? (btw, the draft has expired in the meantime) I think I meant to say draft-ietf-rip-mib-02.txt but as you say that's only a note saying that the draft has expired and the WG has concluded. So how about this: 7.2.3 RIPv2 MIB (RFC 1724) There is no updated MIB module to cover the problems outlined. A new MIB module should be defined. ... skipping down to the proposed standards ... > > | 7.3.03 DNS Server MIB (RFC 1611) > > | > > | This document is HISTORIC and no action is required. > > > > If it's HISTORIC it's not a Proposed Standard anymore. > > Drop it from the survey. > > disagree Even if you leave it in the survey there is no point in analyzing it, especially if you update the stuff in section 5.020 as I suggested (saying that the spec has "been reclassified as an HISTORIC document and is not considered in this discussion"). > > | 7.3.04 DNS Resolver MIB (RFC 1612) > > | > > | This document is HISTORIC and no action is required. > > > > If it's HISTORIC it's not a Proposed Standard anymore. > > Drop it from the survey. > > see above s/5.020/5.021/ in my reply > > | 7.3.05 Appletalk MIB (RFC 1742) > > | > > | The problems have not been addressed and a new MIB should be defined. > > > > rewrite: > > > > This problem has not been addressed. If a user requirement for > > IPv6 over Appletalk develops (which is thought to be unlikely) > > then this MIB module will need to be updated (or a new MIB module > > will need to be created) in order to accomodate it. > > I'd soften the tone a bit, because AFAIK, some Apples are still using > appletalk, so > > s/is thought to be unlikely/may be unlikely/ > > but ok as is too. softening the tone is OK by me > > | 7.3.10 RMON MIB (RFC 2021)? > > > > s/RMON MIB/RMON-II MIB/ > > remove question mark > > > > | The problems have been addressed in RFC 2819, Remote Network > > | Monitoring Management Information Base. > > > > That is false: RFC 2021 is RMON-II, and RFC 2819 is the full > > standard version of RMON-I (formerly RFCs 1271 and 1757). There > > is a work underway to update RFC 2021, however; so the correct > > statement is probably this: > > > > This issue is being resolved by the RMONMIB WG and there is an > > ID (draft-ietf-rmonmib-rmon2-v2-00.txt). > > > > In fact draft-ietf-rmonmib-rmon2-v2-00.txt doesn't actually address > > the problem but I have raised the issue on the RMONMIB mailing list. > > so, maybe reword: > > This issue is being resolved by the RMONMIB WG and there is an > ID (draft-ietf-rmonmib-rmon2-v2-00.txt); future revistions may > address the problem as it has been identifier and brough to attention. The reworded text itself needs rewording :-) How about: This issue has been brought to the attention of the RMONMIB WG. Currently there is an ID (draft-ietf-rmonmib-rmon2-v2-00.txt) to update RFC 2021, but it does not address the problems that have been identified; it is expected that there will be a resolution in a future version of that ID. For those who are curious, look here: http://www1.ietf.org/mail-archive/working-groups/rmonmib/current/maillist.html to see the discussions over the past few days about this. One possibility is to and an enum to trapDestProtocol and to update the trapDestAddress DESCRIPTION clause. Another is to do nothing, and insert text rfc2021bis saying that the tables in RFC 3413 should be used to provide this functionality. Stay tuned! > > | 7.3.11 DataLink Switching using SMIv2 MIB (RFC 2022) > > > > s/2022/2024/ > > Note: RFC 2022 is the multicast over ATM spec (MARS and so on) > > > > | The problems have not been addressed and a new MIB should be > > | defined. > > > > s/a new/an updated/ > > ok > > > | 7.3.12 IP Forwarding Table MIB (RFC 2096) > > | > > | This issue is being worked on by the IPv6 WG and an ID exists to > > | address this (draft-ietf-ipngwg-rfc2096-update-00.txt) > > > > s/draft-ietf-ipngwg-rfc2096-update-00.txt/draft-ietf-ipv6-rfc2096-update-05.txt/ > > (it was posted on 29 Aug 2003, should be listed on IPv6 WG charter page by now) > > ok > > > | 7.3.13 Classical IP & ARP over ATM MIB (RFC 2320) > > | > > | The problems identified are not addressed and a new MIB must be > > | defined. > > > > The previous paragraph should be rewritten along the following > > lines: > > > > The current version of Classical IP and ARP over ATM (RFC xxxx) > > does not support IPv6. If and when that protocol specification > > is updated to add IPv6 support, then new MIB objects to represent > > IPv6 addresses will need to be added to this MIB module. > > ok, replace xxxx in to point to the CLIP RFC though (in routing survey?) Oops, I think I meant to fill that in and forgot. It's RFC 2225. > > | 7.3.14 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) > > | > > | The problems identified are not addressed and a new MIB must be > > | defined. > > > > The previous paragraph should be rewritten along the following > > lines: > > > > The current version of Multicast over UNI 3.0/3.1 ATM (RFC > > xxxx) does not support IPv6. If and when that protocol > > specification is updated to add IPv6 support, then new MIB > > objects to represent IPv6 addresses will need to be added to > > this MIB module. > > ok, same here. RFC 2022. Sorry about that. > > | 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 2576) > > | > > | There are no real issues that can be resolved. > > > > rewrite: > > > > There are no issues that need to be resolved. > > > > Note also that the coex doc is now RF 3584, which is a BCP. > > ok Just to be clear, the last sentence an instruction to the editor, not text to be included. That is, the updated text (module sub- section number) would read: 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 3584) There are no issues that need to be resolved. > > | 7.3.31 RPSL (RFC 2622) > > | > > | Additional objects must be defined for IPv6 addresses and prefixes. > > > > s/must/should/ > > Keep it as MUST. As I understand the V6OPS WG charter, an update to the RPSL MIB (or to RPSL itself) is out of scope for this WG. If that understanding is correct, a V6OPS document can't mandate an uppercase MUST here. Anyway, there are other things wrong with this text since the spec defines a language, not a MIB module (as suggested by the word "objects"). > but you can say: > > draft-blunk-rpslng-01.txt defines extensions to solve this issue, and it > is being considered for publication. How about this: 7.3.31 RPSL (RFC 2622) The ID draft-blunk-rpslng-01.txt defines extensions for IPv6 addresses and prefixes, and and it is being considered for publication. We agree on the fixes to the analysis of experimental RFCs, so we're done. > THANKS! We haven't had such an extensive review in ages... :-) Thank you for yout detailed reply. I hope that I have strong-armed you into making a few more changes than your "minimum update" policy would mandate, maybe with the help of the carrot of providing some actual text :-) //cmh From owner-v6ops@ops.ietf.org Thu Sep 4 00:13:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02988 for ; Thu, 4 Sep 2003 00:13:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ulN7-000AaK-It for v6ops-data@psg.com; Thu, 04 Sep 2003 04:05:25 +0000 Received: from [192.104.59.100] (helo=arda.Nesser.COM) by psg.com with esmtp (Exim 4.22) id 19ulN1-000AZa-ND for v6ops@ops.ietf.org; Thu, 04 Sep 2003 04:05:19 +0000 Received: from A30P ([192.104.59.191]) by arda.Nesser.COM (8.12.8/8.12.6) with ESMTP id h844NjWG000513 for ; Wed, 3 Sep 2003 21:23:45 -0700 (PDT) Reply-To: From: "Philip J. Nesser II" To: Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents Date: Wed, 3 Sep 2003 21:05:18 -0700 Organization: Nesser & Nesser Consulting Message-ID: <0d1901c37299$c0e769e0$bf3b68c0@A30P> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear V6OPS Group, I would just like to take this opportunity to make a few statements on the survey documents. First, I would like to apologize that the rest of my life came crashing down on my head earlier this year and I pretty much had to drop out of any real IETF activity. I would also like to publicly thank the WG chairs (especially Pekka) for pushing these documents without my active help over the last 6 months or so. Finally, my thanks to Andreas Bergstrom for taking over the editing of the docs and helping to move them to their eventual publication. Second, I would like to provide a bit of background on these documents. Most of this work was done in a vacuum by my self and although I like to think of myself as a generalist there are way too many standards and documents for me to keep track of them all. I can't tell you how much I appreciate all of the comments that I have seen coming over a variety of lists in the last month or so (as well as all of the previous ones over the last couple of years). Those looking at the drafts now might wonder at some points that seem a little strange, so here is an explanation of some of them. 1. The weird tags at the end of many RFC names (i.e. MIB-Ethernet). I originally took the RFC titles from the RFC Editor web site and they were all included there, so I left them in. I have no feelings one way or another if they are left in or removed. 2. The stopping point RFC 3274 (or whatever it was). That was the last published RFC at the time the work commenced. There was a general discussion that the IESG should not let any documents pass that had IPv4 dependencies after that (or at least requires a big note pointing it out). The fact that there are so many drafts and RFCS after 3274 that fix problems with earlier RFCS is somewhat of a testament that either the problem was already identified and known or that someone read one of the drafts and initiated work to fix the issue. Either way this is a success in making IPv6 some small steps closer to its ultimate realization. I would make a few cautions here. The comments pointing to published RFCS that fix problems should definitely be included, but be careful of adding references to drafts since they can change/die/be replaced etc... and cause more confusion. (It might also cause the RFC Editor to hold the documents but since I am don't remember the exact rules so someone who knows for sure should be consulted (or speak up)). Although this process has been long and I am anxious to see the final publication of these documents, I would like to suggest that the V6OPS group keep this process alive in the following way. Once these are finally published there will be a list of outstanding specifications. Once a year or any cycle that is agreed upon, a new informational RFC should come out that lists the problems that have been fixed, and the remaining outstanding items. This should not be a large effort since there should be no real analysis required, just a bookkeeping effort. Phil P.S. I would also like to publicly thank all of the kind words that various people written about the work. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBP1a5/g6aViIxlRuuEQKdqQCgoTfEXgSCyHx5hoTZm+njIMlKdVcAn2Q2 CVEEGYhibMxGo3EYbi0Htb7m =J+AQ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Thu Sep 4 03:27:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27224 for ; Thu, 4 Sep 2003 03:27:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uoNq-000IY1-CR for v6ops-data@psg.com; Thu, 04 Sep 2003 07:18:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19uoNj-000IX1-QF for v6ops@ops.ietf.org; Thu, 04 Sep 2003 07:18:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h847HBW31104; Thu, 4 Sep 2003 10:17:12 +0300 Date: Thu, 4 Sep 2003 10:17:11 +0300 (EEST) From: Pekka Savola To: "Follen, Stephen" cc: v6ops@ops.ietf.org Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 In-Reply-To: <05829C8A6277594395457B34D6A3A6DD2840B9@MAANDMBX2.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for bringing this up. The RFC is under revision, and this thing should probably be specified in more detail. There are two-three distinct cases here (I think): 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint" ==> the node should _not_ "acknowledge" the existence of the tunnel, otherwise this could be used to probe the acceptable tunnel endpoint addresses. That is, node should either silently discard the packet, or send an ICMPv4 Protocol Unreachable message. (I guess that depends on what happens when a node receives a packet of an unknown protocol -- whether it sends anything back or not.) 2) "node receives packets from a configured tunnel endpoint, but from the wrong direction (e.g. "internal IP address" from the direction of the Internet), if that kind of policing is implemented/enabled. ==> silently discard, I think. 3) "node receives packets through a valid tunnel which fail IPv6 ingress filtering tests" ==> silently discard, I think (if ingress filtering fails, the error won't probably get back anyway) On Thu, 28 Aug 2003, Follen, Stephen wrote: > A question related to Ingress Filtering of decapsulated [tunneled] > IPv6-in-IPv4 packets: > > Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that "... > a decapsulated packet MUST NOT be forwarded unless the node has been > explicitly configured to forward such packets ..." and in section 4.3 > "The decapsulating node MUST verify that the tunnel source address is > acceptable before forwarding decapsulated packets ..." > (the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 Transition > Mechanisms provides similar guidance in sections 3.6, 3.9 and 4.1) > > The question is what to do in the case that the packets are filtered / > not forwarded: > > 1. silently drop the packet - simple, but provides no feedback of the > "broken link" (see below); > > 2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a poor > approach since > (a) the IPv4 [tunnel endpoint] address was reached and > (b) a response may never get back to the originating IPv6 host > (section 3.4 of RFC 2893 indicates that an encapsulating node MAY > generate > a v6 ICMP when it gets a v4 ICMP back); > > 3. send a v6 ICMP DU - this probably won't get back to the originating > host either since > its unlikely that there's a path back to it (the do not forward > decision occurred because > the tunnel was not set up); > > 4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information > in the incoming > IPv6-in-IPv4 packet to generate this, and it would likely get back > to the originating host, > but to do so would effectively send a packet via a tunnel which had > not been configured. > > "broken link" - [in the case of legitimate traffic] the filtering which > would occur here is not > the result of a specifically configured ingress filter, rather, it is > the result of not fully configuring > the tunnel; a tunnel is effectively a link, so I see the filtering to be > similar to a broken link. > > Any thoughts would be greatly appreciated. - Thank you > > Steve Follen > sfollen@enterasys.com > > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Sep 4 04:02:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29630 for ; Thu, 4 Sep 2003 04:02:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19up2D-000PmE-PF for v6ops-data@psg.com; Thu, 04 Sep 2003 08:00:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19up28-000Pko-B4 for v6ops@ops.ietf.org; Thu, 04 Sep 2003 08:00:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h847vCp31606; Thu, 4 Sep 2003 10:57:15 +0300 Date: Thu, 4 Sep 2003 10:57:11 +0300 (EEST) From: Pekka Savola To: Alexandru Petrescu cc: v6ops@ops.ietf.org Subject: NAT traversal and its relation to IPv6 [RE: Comments on draft-tsirtsis-dsmip-problem-01.txt] In-Reply-To: <3F536833.4020304@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'm picking up one issue here which may be interesting for a bigger audience too. I'm also tailing down the Cc: list. On Mon, 1 Sep 2003, Alexandru Petrescu wrote: [...] > With respect to dual-stacks, the thing I'd like to have is the Mobile > IPv6 MN-HA tunnel to be a v6-in-v4 tunnel instead of v6-in-v6, and > moreover that tunnel to drill through the NAT gateway, and even stay up > when applications are silent (heartbeats bubbling or such). This would > allow an IPv6 mobile host to attach to an exclusively-v4 > public-access-private-address ISP, and then to another, while > maintaining a fixed IPv6 Home Address. By my reading, the draft already > covers this case, so I don't complain. My concern is this: we already have about half a dozen IPv4 NAT traversal techniques (IPsec, MIPv4, STUN, TURN, a number of others) -- and some have been proposed to allow IPv6-in-IPv4 tunneling to also traverse NAT (none taken up by this WG, at the moment, though.). So you want to implement and specify one for dual-stack Mobile IPv6 *too*? :...-((( My _personal_ two top priorities in this context: 1) make sure NAT traversal stays an _IPv4_ problem. Traverse a NAT to get a global IPv4 address, then activate an IPv6 transition mechanism. Everything is transparent to the IPv6 transition mechanism. 2) failing that, provide *one*, *very simple* (most likely, a bidirectional tunnel or something like that) mechanism which is close to bulletproof to enable IPv6 tunneling over NAT. When you have an IPv6 connectivity, you don't have to worry about NAT's anymore in any of the scopes listed above (MIP, IPsec, etc.etc.). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Sep 4 06:49:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10537 for ; Thu, 4 Sep 2003 06:49:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19urWo-0000oR-B9 for v6ops-data@psg.com; Thu, 04 Sep 2003 10:39:50 +0000 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.22) id 19urWF-0000j9-4y for v6ops@ops.ietf.org; Thu, 04 Sep 2003 10:39:15 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h84Ad2HN029404; Thu, 4 Sep 2003 03:39:07 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h84AcvLR001559; Thu, 4 Sep 2003 05:38:59 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id B8F3C2EC86; Thu, 4 Sep 2003 12:38:59 +0200 (CEST) Message-ID: <3F571643.80107@nal.motlabs.com> Date: Thu, 04 Sep 2003 12:38:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft-tsirtsis-dsmip-problem-01.txt] References: In-Reply-To: X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >> With respect to dual-stacks, the thing I'd like to have is the >> Mobile IPv6 MN-HA tunnel to be a v6-in-v4 tunnel instead of >> v6-in-v6 > > My concern is this: we already have about half a dozen IPv4 NAT > traversal techniques (IPsec, MIPv4, STUN, TURN, a number of others) > -- and some have been proposed to allow IPv6-in-IPv4 tunneling to > also traverse NAT (none taken up by this WG, at the moment, though.). Good to have a rich set of proposals, selecting is easier than building. > So you want to implement and specify one for dual-stack Mobile IPv6 > *too*? No, I want Mobile IPv6 to not require its MN-HA tunnel to be v6-in-v6 but to require it to be either v6-in-v6 or v6-in-v4. > My _personal_ two top priorities in this context: > > 1) make sure NAT traversal stays an _IPv4_ problem. I've heard this concern before, so I guess it is right. Also, there were concerns expressed that NAT's are unqualifiable and unclassifiable beasts, so one can not really find a common means to drill through all of them. Which is perfectly right to a certain extent. > Traverse a NAT to get a global IPv4 address, then activate an IPv6 > transition mechanism. Everything is transparent to the IPv6 > transition mechanism. > 2) failing that, provide *one*, *very simple* (most likely, a > bidirectional tunnel or something like that) mechanism which is close > to bulletproof to enable IPv6 tunneling over NAT. When you have an > IPv6 connectivity, you don't have to worry about NAT's anymore in any > of the scopes listed above (MIP, IPsec, etc.etc.). Sounds like a good stepwise scheme, provided that one can identify that most simple bullet-proof mechanism, and that mechanism is not an "IP over SMTP" April's fool. Because I doubt that, I'm bringing back the mobility aspect: mobility systems are deployed only in a limited set of kinds of systems (say GPRS and hotspots, but there are others), cover only a limited set of types of NAT; for those 3-5 types of NAT's maybe a common NAT traversal mechanism can be found. Alex From owner-v6ops@ops.ietf.org Thu Sep 4 16:19:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20018 for ; Thu, 4 Sep 2003 16:19:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v0NZ-000Iof-0k for v6ops-data@psg.com; Thu, 04 Sep 2003 20:06:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19v0NK-000ImP-2E; Thu, 04 Sep 2003 20:06:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h84K5X107435; Thu, 4 Sep 2003 23:05:33 +0300 Date: Thu, 4 Sep 2003 23:05:32 +0300 (EEST) From: Pekka Savola To: "C. M. Heard" cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, First of all, let me give a conclusion reached during an off-list thread with you and the document editors. We seem to be in agreement that the Historic documents should be removed, and those documents which have been obsoleted (should be only those which have been done after RFC3200 or so) be updated to point to the most recent versions. I'll respond to other points inline (which don't seem more or less trivial); I'll remove those which are moot with this agreement. Andreas, if you have time, please try to edit the ops document to address the concerns and text updates soon and pass it over by Mike when done or when trying to figure out what kind of wording to put in there. That way we can (hopefully) get the loop closed pretty fast, and minimize the risk of having comments fall through the cracks. I think we can go off-list for further issues, and come back to ops-area/v6ops after we have a new shiny revision of the document ready :-) Thanks for the work, everybody, especially the MIB folks. (Mike, if you'd like, I think it would be fair to add you as a co-editor of the document due to the huge amount of effort you've poured into it, but it's as you prefer.) On Wed, 3 Sep 2003, C. M. Heard wrote: > > 2) protocol/specification. I totally agree that we should refer the > > RFC's by "specification" because that's generic enough to cover any RFC. > > > > 3) MIB acronyms like TRANS-MIB in: > > > > 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network > > Management Protocol (SNMPv2) (TRANS-MIB) > > > > .. these do not appear in the original RFC's, but are invented by > > RFC-editor for some RFC indexes. My opinion is that we should get > > rid of these bogus abbreviations completely, but I would also be > > OK with it if they're changed to be correct. Whatever works for > > you.. > > Getting rid of the acronyms and relying on RFC title and number > alone would suit me just fine. But if they remain the acronyms must > be the right ones (MIB module names in the case of MIB modules). > Note that in some cases an acronym appears twice, once in the > original title, and the once again and the MIB or protocol name; > in those cases remove only the second occurrence. Agreed, in all counts. Let's remove the RFC-editor's "invented" names entirely. > > But I think we can address this situation in practical terms. Where > > applicable, add notions about these documents in the "analysis", section > > 7, like: > > > > 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 2576) > > > > There are no real issues that can be resolved. > > > > ==> add a sentence like: > > > > The document is obsoleted by RFC 3584. > > > > (or something else, if RFC3584 addresses the concerns) > > > > .. that way, we could have somekind of a "forward pointer" even to > > informational/BCP documents which may be relevant. > > > > Would this satisfy your concern? If so, could you submit some wording > > that would be appropriate for these cases? > > I'm not too keen on the specific suggestion above. But, given your > lack of resources, I can accept that you would only address the > specific documents mentioned above (namely RFCs 1212, 1215, and > 3584). I can also accept the following editorial strategy: > mention RFC 1215 in conjunction with 1155 and 1212 (since together > they form a package, and really are part of the same de-facto > standard), replace all mentions of RFC 2576 with RFC 3584, move RFC > 3584 to Section 3, and re-title Section 3 as follows: > > 3.0 Full Standards and BCPs > > That would entail an addition to the lead-in text of that section: > > > > | Full Internet Standards (most commonly simply referred to as > > > | "Standards") are fully mature protocol specification that are widely > > > | implemented and used throughout the Internet. > > The OPS area has one technical specification (RFC 3584) which is > classified as a Best Current Practice, or BCP. That is another > "terminal" classification. It was used for this specfication > because it was deemed mature and unlikely to see further evolution, > but did not meet the formal requirements for Full Standard. s/specfication/specification/ > Suggested text for the other stuff will appear below. This would be a special case for including BCP's (other areas don't include them because analyzing them would be more work..), but you strongly prefer having it in here, I guess we can agree to that, as long as you provide the text :-) Personally I'd just like to handwave it away (somehow), for consistency reasons, but I understand if you'd like to have it included explicitly. > > > | 3.1 RFC 1157 Simple Network Management Protocol > > > | > > > | Beginning in Section 3.2.6.3.2 atTable Object Type Names thru the rest > > > | of Section 3 there are numerous references to the use of IPv4 addresses > > > | as part of OIDs. > > OK, if we want to keep this one (which would be justified because of its > wide deployment) then make this fix: > > s/as part of OIDs/for identification of object instances/ > > Technically, the use of the term "OIDs" is correct here, but I much > prefer the more precise language. It's historic, and could be removed due to the policy.. but if you'd prefer to have it enabled, we could reword the text (and resolution in section 7) to your liking. > > > | 5.058 RFC 2493 Textual Conventions for MIB Modules Using > > > | Performance History Based on 15 Minute Intervals > > > | > > > | There are no IPv4 dependencies in this specification. > > > > > > Note: this document is due to be replaced by RFC 3593, > > > which will be a Draft Standard and will have the same title. > > That has now happened: the announcement has just been sent to the > IETF-Announce list, and RFC 3593 is now available in the on-line > repositories since yesterday. So, please change the RFC number from > 2493 to 3593 and move this sub-section from the PS part to the DS > part. Yes, I know this contradicts your minimal change doctrine but > I don't agree with that doctrine. Good.. because now we have agreed to a close-to-minimal change doctrine :-), which should be sufficiently low-overhead for us, while enhancing the reader's usability of the document. > > > | 5.068 RFC 2562 Definitions of Protocol and Managed Objects for > > > | TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) > > > | (TN2370E-RT) > > > > > > remove "(TN3270E-RT)" at the end > > > > remove both ? :-) > > No, "(TN3270E-RT-MIB)" is actually part of the official title. ok. > > > | 5.092 RFC 2726 PGP Authentication for RIPE Database Updates > > > | > > > | There are no IPv4 dependencies in this protocol. > > > > > > Is this actually an OPS Area specification? > > > > this could be moved to security, that's true. however, we felt that RPSL > > was so strongly OPS stuff, so this could logically belong here too > > (doesn't really matter as there are no dependencies). > > I was just asking. If you think it's in the right place leave it > (RPSL evidently is, according to Bert Wijnen). Ok. > > > | 5.113 RFC 2959 Real-Time Transport Protocol Management > > > | Information Base > > > | > > > | There are numerous uses of the included TAddress Syntax which is > > > | IPv4 dependent as noted above. > > > | > > > | For example: > ... > > > | There are a total of 8 instances of this. > > > > > > As explained above under 5.093, this does not necessarily mean that > > > there is an IPv4 dependency. Please re-evaluate this MIB module and > > > update this section accordingly. I'd bet that this spec doesn't really > > > have any IPv4 dependencies after all. > > > > we don't have resources for re-evaluation, unfortunately. unless someone > > more knowledgeable does it, we'll have to keep it as is. > > OK, I just had a quick look at this RFC and it looks OK to me ... the > object rtpSessionDomain, which is of type TDomain, allows IPv6 transport > to be represented by all the TAddress objects. So here's the rewrite: > > 5.113 RFC 2959 Real-Time Transport Protocol Management > Information Base > > There are no IPv4 dependencies in this specification. > > (modulo a probable sub-section number change). nice. > > > I agree with the 2nd sentence, except > > > that the draft is now draft-ietf-rip-mib-01.txt; it stands alone > > > quite nicely. > > > > the draft name you mentioned is the same as listed, perhaps you meant > > something else? (btw, the draft has expired in the meantime) > > I think I meant to say draft-ietf-rip-mib-02.txt but as you say that's > only a note saying that the draft has expired and the WG has concluded. > So how about this: > > 7.2.3 RIPv2 MIB (RFC 1724) > > There is no updated MIB module to cover the problems outlined. A > new MIB module should be defined. ok > Thank you for yout detailed reply. I hope that I have strong-armed > you into making a few more changes than your "minimum update" policy > would mandate, maybe with the help of the carrot of providing some > actual text :-) Right. Thanks for your persistence, perhaps it is for the best :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Sep 4 16:45:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21222 for ; Thu, 4 Sep 2003 16:45:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v0vr-000OYq-RI for v6ops-data@psg.com; Thu, 04 Sep 2003 20:42:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19v0vJ-000ORW-Fe for v6ops@ops.ietf.org; Thu, 04 Sep 2003 20:41:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h84Kec807864; Thu, 4 Sep 2003 23:40:38 +0300 Date: Thu, 4 Sep 2003 23:40:37 +0300 (EEST) From: Pekka Savola To: Alexandru Petrescu cc: v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft-tsirtsis-dsmip-problem-01.txt] In-Reply-To: <3F571643.80107@nal.motlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 4 Sep 2003, Alexandru Petrescu wrote: > Pekka Savola wrote: > >> With respect to dual-stacks, the thing I'd like to have is the > >> Mobile IPv6 MN-HA tunnel to be a v6-in-v4 tunnel instead of > >> v6-in-v6 > > > > My concern is this: we already have about half a dozen IPv4 NAT > > traversal techniques (IPsec, MIPv4, STUN, TURN, a number of others) > > -- and some have been proposed to allow IPv6-in-IPv4 tunneling to > > also traverse NAT (none taken up by this WG, at the moment, though.). > > Good to have a rich set of proposals, selecting is easier than building. That's one perspective, with a set of tradeoffs. Some (many?) people also argue otherwise: with too much choice, the user if faced with a dilemma on what to choose, and the vendor is faced with the dilemma on what to implement (so it has to implement all), etc. > > So you want to implement and specify one for dual-stack Mobile IPv6 > > *too*? > > No, I want Mobile IPv6 to not require its MN-HA tunnel to be v6-in-v6 > but to require it to be either v6-in-v6 or v6-in-v4. But because you'd like that to work also where v4 NAT is done, a simple v6-in-v4 tunnel would not be enough -- it would have to be able to handle NAT traversal -- right? > > My _personal_ two top priorities in this context: > > > > 1) make sure NAT traversal stays an _IPv4_ problem. > > I've heard this concern before, so I guess it is right. Also, there > were concerns expressed that NAT's are unqualifiable and unclassifiable > beasts, so one can not really find a common means to drill through all > of them. Which is perfectly right to a certain extent. Well, I think this depends *very* much on how big holes you want to drill. Bidirectional tunneling? No problem. Drilling through from pretty much everywhere? Certainly there are issues. [...] > Because I doubt that, I'm bringing back the mobility aspect: mobility > systems are deployed only in a limited set of kinds of systems (say GPRS > and hotspots, but there are others), cover only a limited set of types > of NAT; for those 3-5 types of NAT's maybe a common NAT traversal > mechanism can be found. I'm not sure if we can make that kind of assumptions about Mobile IP deployment, but if we can, fine -- it's still a lot. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Sep 4 16:50:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21482 for ; Thu, 4 Sep 2003 16:50:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v12V-000Pkq-4j for v6ops-data@psg.com; Thu, 04 Sep 2003 20:49:11 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtp (Exim 4.22) id 19v12N-000Pjc-2y; Thu, 04 Sep 2003 20:49:03 +0000 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h84Kochs027925; Thu, 4 Sep 2003 13:50:38 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h84Kmr603575; Thu, 4 Sep 2003 13:48:53 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 4 Sep 2003 13:48:52 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: v6ops@ops.ietf.org cc: ops-area@ops.ietf.org, pekkas@netcore.fi, andreas.bergstrom@hiof.no Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 4 Sep 2003, Pekka Savola wrote: > First of all, let me give a conclusion reached during an off-list thread > with you and the document editors. > > We seem to be in agreement that the Historic documents should be removed, > and those documents which have been obsoleted (should be only those which > have been done after RFC3200 or so) be updated to point to the most recent > versions. > > I'll respond to other points inline (which don't seem more or less > trivial); I'll remove those which are moot with this agreement. And I in turn will have mercy upon the audience by only responding where necessary :-) > (Mike, if you'd like, I think it would be fair to add you as a co-editor > of the document due to the huge amount of effort you've poured into it, > but it's as you prefer.) A mention in the acknowledgments section would be sufficient (in fact I would prefer that). > On Wed, 3 Sep 2003, C. M. Heard wrote: [ ... a proposal for including RFC 3584 with OPS Area full standards ... ] > This would be a special case for including BCP's (other areas don't > include them because analyzing them would be more work..), but you > strongly prefer having it in here, I guess we can agree to that, as long > as you provide the text :-) > > Personally I'd just like to handwave it away (somehow), for consistency > reasons, but I understand if you'd like to have it included explicitly. How about just leaving it out altogether? I think you've already agreed that RFC 2576 is to be cut, because it's obsolete. And we've also agreed that there are no IPv4 dependencies in RFC 3584 that need to be (or even can be) corrected, so its presence in the survey does not add much value. My main concern was to get rid of the incorrect text in the section dealing with RFC 2576, and just cutting that section will accomplish that goal with a minimum of fuss. > > > > | 3.1 RFC 1157 Simple Network Management Protocol > > It's historic, and could be removed due to the policy.. but if you'd > prefer to have it enabled, we could reword the text (and resolution in > section 7) to your liking. Cut it, unless the WG wants to keep it. That's what I wanted to do in the first place; I offered the alternative as a compromise. That seems to cover everything that requires a response. We must be making progress, since these messages continue to get shorter :-) Thanks, Mike From owner-v6ops@ops.ietf.org Thu Sep 4 16:57:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21779 for ; Thu, 4 Sep 2003 16:57:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v18k-00012u-Bm for v6ops-data@psg.com; Thu, 04 Sep 2003 20:55:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19v18e-00011M-Lm; Thu, 04 Sep 2003 20:55:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h84KqAc08018; Thu, 4 Sep 2003 23:52:10 +0300 Date: Thu, 4 Sep 2003 23:52:09 +0300 (EEST) From: Pekka Savola To: "C. M. Heard" cc: v6ops@ops.ietf.org, , Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 4 Sep 2003, C. M. Heard wrote: > > On Wed, 3 Sep 2003, C. M. Heard wrote: > [ ... a proposal for including RFC 3584 with OPS Area full standards ... ] > > This would be a special case for including BCP's (other areas don't > > include them because analyzing them would be more work..), but you > > strongly prefer having it in here, I guess we can agree to that, as long > > as you provide the text :-) > > > > Personally I'd just like to handwave it away (somehow), for consistency > > reasons, but I understand if you'd like to have it included explicitly. > > How about just leaving it out altogether? I think you've already agreed > that RFC 2576 is to be cut, because it's obsolete. And we've also agreed > that there are no IPv4 dependencies in RFC 3584 that need to be (or even > can be) corrected, so its presence in the survey does not add much value. > My main concern was to get rid of the incorrect text in the section > dealing with RFC 2576, and just cutting that section will accomplish > that goal with a minimum of fuss. Well, someone sharp-eyed could some calling us and complain why it was not included .. :-) .. but just removing it is fine with me, and simpler; if you feel (as an OPS expert) that's the best thing to do, it's fine for us I think. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Sep 4 17:53:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24958 for ; Thu, 4 Sep 2003 17:53:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v1wU-000A6a-Ea for v6ops-data@psg.com; Thu, 04 Sep 2003 21:47:02 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtp (Exim 4.22) id 19v1wP-000A5Y-WA; Thu, 04 Sep 2003 21:46:58 +0000 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h84LmZhs029555; Thu, 4 Sep 2003 14:48:35 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h84LkqR26292; Thu, 4 Sep 2003 14:46:52 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 4 Sep 2003 14:46:51 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Pekka Savola cc: v6ops@ops.ietf.org, ops-area@ops.ietf.org, andreas.bergstrom@hiof.no Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.9 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_PINE,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 4 Sep 2003, Pekka Savola wrote, regarding cutting RFC 3584 from the ops document survey: > Well, someone sharp-eyed could some calling us and complain why > it was not included .. :-) True, I am living proof :-) On the other hand, you do have your policy to fall back on ("we didn't survey BCPs or Informational RFCs"), along with a reasonable justification for that policy ("because the cost-to-reward ratio was deemed too low, given the available resources"). > .. but just removing it is fine with me, and simpler; if you > feel (as an OPS expert) that's the best thing to do, it's fine > for us I think. Well, the main purpose of the survey was to uncover documents that needs to be fixed. Since this one doesn't need to be fixed, the only value that there is in having it in the document is to prove that the survey was reasonably complete. Well, we know we've done our homework, so I don't think that matters very much. If the OPS ADs are OK with leaving RFC 3584 out of the survey then so am I. Mike From owner-v6ops@ops.ietf.org Thu Sep 4 18:38:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28662 for ; Thu, 4 Sep 2003 18:38:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v2hN-000ITt-9w for v6ops-data@psg.com; Thu, 04 Sep 2003 22:35:29 +0000 Received: from [192.11.222.161] (helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 4.22) id 19v2gm-000IKS-A9; Thu, 04 Sep 2003 22:34:52 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h84MYml05602; Thu, 4 Sep 2003 17:34:48 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 5 Sep 2003 00:34:47 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023314D7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'C. M. Heard'" , Pekka Savola Cc: v6ops@ops.ietf.org, ops-area@ops.ietf.org, andreas.bergstrom@hiof.no Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments Date: Fri, 5 Sep 2003 00:34:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > .. but just removing it is fine with me, and simpler; if you > > feel (as an OPS expert) that's the best thing to do, it's fine > > for us I think. > > Well, the main purpose of the survey was to uncover documents that > needs to be fixed. Since this one doesn't need to be fixed, the > only value that there is in having it in the document is to prove > that the survey was reasonably complete. Well, we know we've done > our homework, so I don't think that matters very much. > > If the OPS ADs are OK with leaving RFC 3584 out of the survey then > so am I. > I am OK with that, but I assume that RFC2576 is not included either, right? Bert > Mike > > From owner-v6ops@ops.ietf.org Thu Sep 4 18:39:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28715 for ; Thu, 4 Sep 2003 18:39:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v2kM-000J1m-UM for v6ops-data@psg.com; Thu, 04 Sep 2003 22:38:34 +0000 Received: from [192.11.226.163] (helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.22) id 19v2jq-000Ivx-Sv; Thu, 04 Sep 2003 22:38:03 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h84MbwC03603; Thu, 4 Sep 2003 17:37:58 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 5 Sep 2003 00:37:57 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023314D8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Pekka Savola'" , "C. M. Heard" Cc: v6ops@ops.ietf.org, ops-area@ops.ietf.org, andreas.bergstrom@hiof.no Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments Date: Fri, 5 Sep 2003 00:37:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Mmm... I wanted to chime in earlier but was (too) busy with other (mainly IETF/IESG related) work. I believe I see people converging which is good. But I do want to state my support for trying to get the doc accurate and clean and to not have it list issues with now obsoleted or historic documents. That seems to me to be "editorial" changes, so should be easy. Of course I would also like to see thing fixed/corrected where the statement were not correct (I am not blaming the author(s), after all not everyone is a MIB expert). That is why I asked MIB doctors to take a look at it. Thanks to Mike! Thanks, Bert > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: donderdag 4 september 2003 22:06 > To: C. M. Heard > Cc: v6ops@ops.ietf.org; ops-area@ops.ietf.org; > andreas.bergstrom@hiof.no > Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 > documents > > > Hi, > > First of all, let me give a conclusion reached during an > off-list thread > with you and the document editors. > > We seem to be in agreement that the Historic documents should > be removed, > and those documents which have been obsoleted (should be only > those which > have been done after RFC3200 or so) be updated to point to > the most recent > versions. > > I'll respond to other points inline (which don't seem more or less > trivial); I'll remove those which are moot with this agreement. > > Andreas, if you have time, please try to edit the ops > document to address > the concerns and text updates soon and pass it over by Mike > when done or > when trying to figure out what kind of wording to put in > there. That way > we can (hopefully) get the loop closed pretty fast, and > minimize the risk > of having comments fall through the cracks. > > I think we can go off-list for further issues, and come back to > ops-area/v6ops after we have a new shiny revision of the > document ready > :-) > > Thanks for the work, everybody, especially the MIB folks. > > (Mike, if you'd like, I think it would be fair to add you as > a co-editor > of the document due to the huge amount of effort you've > poured into it, > but it's as you prefer.) > > On Wed, 3 Sep 2003, C. M. Heard wrote: > > > 2) protocol/specification. I totally agree that we > should refer the > > > RFC's by "specification" because that's generic enough to > cover any RFC. > > > > > > 3) MIB acronyms like TRANS-MIB in: > > > > > > 3.9 RFC 3417 Transport Mappings for Version 2 of the > Simple Network > > > Management Protocol (SNMPv2) (TRANS-MIB) > > > > > > .. these do not appear in the original RFC's, but are invented by > > > RFC-editor for some RFC indexes. My opinion is that we should get > > > rid of these bogus abbreviations completely, but I would also be > > > OK with it if they're changed to be correct. Whatever works for > > > you.. > > > > Getting rid of the acronyms and relying on RFC title and number > > alone would suit me just fine. But if they remain the acronyms must > > be the right ones (MIB module names in the case of MIB modules). > > Note that in some cases an acronym appears twice, once in the > > original title, and the once again and the MIB or protocol name; > > in those cases remove only the second occurrence. > > Agreed, in all counts. Let's remove the RFC-editor's > "invented" names > entirely. > > > > But I think we can address this situation in practical > terms. Where > > > applicable, add notions about these documents in the > "analysis", section > > > 7, like: > > > > > > 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 2576) > > > > > > There are no real issues that can be resolved. > > > > > > ==> add a sentence like: > > > > > > The document is obsoleted by RFC 3584. > > > > > > (or something else, if RFC3584 addresses the concerns) > > > > > > .. that way, we could have somekind of a "forward pointer" even to > > > informational/BCP documents which may be relevant. > > > > > > Would this satisfy your concern? If so, could you submit > some wording > > > that would be appropriate for these cases? > > > > I'm not too keen on the specific suggestion above. But, given your > > lack of resources, I can accept that you would only address the > > specific documents mentioned above (namely RFCs 1212, 1215, and > > 3584). I can also accept the following editorial strategy: > > mention RFC 1215 in conjunction with 1155 and 1212 (since together > > they form a package, and really are part of the same de-facto > > standard), replace all mentions of RFC 2576 with RFC 3584, move RFC > > 3584 to Section 3, and re-title Section 3 as follows: > > > > 3.0 Full Standards and BCPs > > > > That would entail an addition to the lead-in text of that section: > > > > > > | Full Internet Standards (most commonly simply referred to as > > > > | "Standards") are fully mature protocol specification > that are widely > > > > | implemented and used throughout the Internet. > > > > The OPS area has one technical specification (RFC > 3584) which is > > classified as a Best Current Practice, or BCP. That > is another > > "terminal" classification. It was used for this specfication > > because it was deemed mature and unlikely to see > further evolution, > > but did not meet the formal requirements for Full Standard. > > s/specfication/specification/ > > > Suggested text for the other stuff will appear below. > > This would be a special case for including BCP's (other areas don't > include them because analyzing them would be more work..), but you > strongly prefer having it in here, I guess we can agree to > that, as long > as you provide the text :-) > > Personally I'd just like to handwave it away (somehow), for > consistency > reasons, but I understand if you'd like to have it included > explicitly. > > > > > | 3.1 RFC 1157 Simple Network Management Protocol > > > > | > > > > | Beginning in Section 3.2.6.3.2 atTable Object Type > Names thru the rest > > > > | of Section 3 there are numerous references to the use > of IPv4 addresses > > > > | as part of OIDs. > > > > OK, if we want to keep this one (which would be justified > because of its > > wide deployment) then make this fix: > > > > s/as part of OIDs/for identification of object instances/ > > > > Technically, the use of the term "OIDs" is correct here, but I much > > prefer the more precise language. > > It's historic, and could be removed due to the policy.. but if you'd > prefer to have it enabled, we could reword the text (and > resolution in > section 7) to your liking. > > > > > | 5.058 RFC 2493 Textual Conventions for MIB Modules Using > > > > | Performance History Based on 15 Minute Intervals > > > > | > > > > | There are no IPv4 dependencies in this specification. > > > > > > > > Note: this document is due to be replaced by RFC 3593, > > > > which will be a Draft Standard and will have the same title. > > > > That has now happened: the announcement has just been sent to the > > IETF-Announce list, and RFC 3593 is now available in the on-line > > repositories since yesterday. So, please change the RFC number from > > 2493 to 3593 and move this sub-section from the PS part to the DS > > part. Yes, I know this contradicts your minimal change doctrine but > > I don't agree with that doctrine. > > Good.. because now we have agreed to a close-to-minimal > change doctrine > :-), which should be sufficiently low-overhead for us, while > enhancing the > reader's usability of the document. > > > > > | 5.068 RFC 2562 Definitions of Protocol and Managed Objects for > > > > | TN3270E Response Time Collection Using SMIv2 > (TN3270E-RT-MIB) > > > > | (TN2370E-RT) > > > > > > > > remove "(TN3270E-RT)" at the end > > > > > > remove both ? :-) > > > > No, "(TN3270E-RT-MIB)" is actually part of the official title. > > ok. > > > > > | 5.092 RFC 2726 PGP Authentication for RIPE Database Updates > > > > | > > > > | There are no IPv4 dependencies in this protocol. > > > > > > > > Is this actually an OPS Area specification? > > > > > > this could be moved to security, that's true. however, > we felt that RPSL > > > was so strongly OPS stuff, so this could logically belong here too > > > (doesn't really matter as there are no dependencies). > > > > I was just asking. If you think it's in the right place leave it > > (RPSL evidently is, according to Bert Wijnen). > > Ok. > > > > > | 5.113 RFC 2959 Real-Time Transport Protocol Management > > > > | Information Base > > > > | > > > > | There are numerous uses of the included TAddress > Syntax which is > > > > | IPv4 dependent as noted above. > > > > | > > > > | For example: > > ... > > > > | There are a total of 8 instances of this. > > > > > > > > As explained above under 5.093, this does not > necessarily mean that > > > > there is an IPv4 dependency. Please re-evaluate this > MIB module and > > > > update this section accordingly. I'd bet that this > spec doesn't really > > > > have any IPv4 dependencies after all. > > > > > > we don't have resources for re-evaluation, unfortunately. > unless someone > > > more knowledgeable does it, we'll have to keep it as is. > > > > OK, I just had a quick look at this RFC and it looks OK to > me ... the > > object rtpSessionDomain, which is of type TDomain, allows > IPv6 transport > > to be represented by all the TAddress objects. So here's > the rewrite: > > > > 5.113 RFC 2959 Real-Time Transport Protocol Management > > Information Base > > > > There are no IPv4 dependencies in this specification. > > > > (modulo a probable sub-section number change). > > nice. > > > > > I agree with the 2nd sentence, except > > > > that the draft is now draft-ietf-rip-mib-01.txt; it > stands alone > > > > quite nicely. > > > > > > the draft name you mentioned is the same as listed, > perhaps you meant > > > something else? (btw, the draft has expired in the meantime) > > > > I think I meant to say draft-ietf-rip-mib-02.txt but as you > say that's > > only a note saying that the draft has expired and the WG > has concluded. > > So how about this: > > > > 7.2.3 RIPv2 MIB (RFC 1724) > > > > There is no updated MIB module to cover the problems > outlined. A > > new MIB module should be defined. > > ok > > > Thank you for yout detailed reply. I hope that I have strong-armed > > you into making a few more changes than your "minimum update" policy > > would mandate, maybe with the help of the carrot of providing some > > actual text :-) > > Right. Thanks for your persistence, perhaps it is for the best :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > From owner-v6ops@ops.ietf.org Thu Sep 4 18:55:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29415 for ; Thu, 4 Sep 2003 18:55:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v2v3-000LMI-Ct for v6ops-data@psg.com; Thu, 04 Sep 2003 22:49:37 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtp (Exim 4.22) id 19v2tI-000KxF-Gn; Thu, 04 Sep 2003 22:47:48 +0000 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h84MnLhs031303; Thu, 4 Sep 2003 15:49:21 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h84Mlcf15307; Thu, 4 Sep 2003 15:47:38 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 4 Sep 2003 15:47:37 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Wijnen, Bert (Bert)" cc: Pekka Savola , v6ops@ops.ietf.org, ops-area@ops.ietf.org, andreas.bergstrom@hiof.no Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155023314D7@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 5 Sep 2003, Wijnen, Bert (Bert) wrote: > > If the OPS ADs are OK with leaving RFC 3584 out of the survey then > > so am I. > > > I am OK with that, but I assume that RFC2576 is not included either, > right? That was my understanding (and also something I explicitly requested in an off-line discussion with the authors and chairs). Mike From owner-v6ops@ops.ietf.org Fri Sep 5 10:01:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23210 for ; Fri, 5 Sep 2003 10:01:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19vH1j-000C1A-Fx for v6ops-data@psg.com; Fri, 05 Sep 2003 13:53:27 +0000 Received: from [194.196.100.238] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.22) id 19vH1b-000C0X-Py for v6ops@ops.ietf.org; Fri, 05 Sep 2003 13:53:19 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h85DpXYG036762; Fri, 5 Sep 2003 15:51:33 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h85DpfFU229648; Fri, 5 Sep 2003 15:51:41 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA47774; Fri, 5 Sep 2003 15:51:29 +0200 Message-ID: <3F5894D6.CBDBF13E@zurich.ibm.com> Date: Fri, 05 Sep 2003 15:51:18 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, bob@thefinks.com, jonne.soininen@nokia.com, cesar.olvera@consulintel.es, andreas.bergstrom@hiof.no Subject: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > Hi all, > > This is a WG Last Call for comments on sending the following the next > three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" > documents to the IESG for consideration as Informational RFCs: > > Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt 4.1 RFC 1771 A Border Gateway Protocol 4 (BGP-4) This RFC defines a protocol used for exchange of IPv4 routing information and does not support IPv6. A new EGP must be defined for the exchange of IPv6 routing information. This and other references to BGP4 seem to ignore BGP4+ (RFC 2858) even though it is listed! 5.1 RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments (IS-IS) This document specifies a protocol for the exchange of IPv4 routing information. It is incompatible with IPv6. There are substantial work being done on a newer version of IS-IS that should include IPv6 routing. s/are/is/. Also is this up to date? 5.2 RFC 1370 Applicability Statement for OSPF This document discusses a version of OSPF that is limited to IPv4. It is expected that a similar document be assigned for when a version of OSPF that supports IPv6 is established. s/be assigned/will be written/. Also is this up to date? 5.19 RFC 2338 Virtual Router Redundancy Protocol (VRRP) ... There are numerous other references to 32-bit IP addresses. There does not seem to be any reason that a new version of this protocol could be straightforwardly be developed for IPv6. Does this say what it seems to say, or is there a missing "not"? There are at least two places in the draft that need: s/depreciated/deprecated/ All this results from a superficial survey of the draft, so I suspect that there are other nits as well. This is not ready to ship. > Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt Did not review. > > Survey of IPv4 Addresses in Currently Deployed IETF Transport Area > Standards > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt From a superficial review, this looks reasonably OK to me, but I have not made a full review. Brian From owner-v6ops@ops.ietf.org Fri Sep 5 15:53:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15710 for ; Fri, 5 Sep 2003 15:53:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19vMVi-000E2b-Cp for v6ops-data@psg.com; Fri, 05 Sep 2003 19:44:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19vMVC-000E1A-DT for v6ops@ops.ietf.org; Fri, 05 Sep 2003 19:44:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h85Jh8K22193; Fri, 5 Sep 2003 22:43:08 +0300 Date: Fri, 5 Sep 2003 22:43:08 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org, , , , Subject: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: <3F5894D6.CBDBF13E@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, 5 Sep 2003, Brian E Carpenter wrote: > Pekka Savola wrote: > > > > Hi all, > > > > This is a WG Last Call for comments on sending the following the next > > three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" > > documents to the IESG for consideration as Informational RFCs: > > > > Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt > > 4.1 RFC 1771 A Border Gateway Protocol 4 (BGP-4) > > This RFC defines a protocol used for exchange of IPv4 routing > information and does not support IPv6. A new EGP must be defined for > the exchange of IPv6 routing information. > > This and other references to BGP4 seem to ignore BGP4+ (RFC 2858) even though > it is listed! True, but the comments you quote are all from sections 3-6, which should (according to the methodology), be examined in the "vacuum", not looking forward to documents which fix the issues. There has been some slippage from this though. Are there serious objections to this original approach? Note that at least half a dozen people who have reviewed the document have complained (to a smaller or greater extent) about it. This certainly needs some rewording, though. > 5.1 RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual > environments (IS-IS) > > This document specifies a protocol for the exchange of IPv4 routing > information. It is incompatible with IPv6. There are substantial > work being done on a newer version of IS-IS that should include IPv6 > routing. > > s/are/is/. Also is this up to date? Close, perhaps something like: This document specifies a protocol for the exchange of IPv4 routing information. Extensions are being specified to also handle IPv6. [and elaborate in section 7] > 5.2 RFC 1370 Applicability Statement for OSPF > > This document discusses a version of OSPF that is limited to IPv4. > It is expected that a similar document be assigned for when a version > of OSPF that supports IPv6 is established. > > s/be assigned/will be written/. Also is this up to date? Pretty close, but I'd say "may be written". I'm not sure if it's really worth the bits.. > 5.19 RFC 2338 Virtual Router Redundancy Protocol (VRRP) > ... > There are numerous other references to 32-bit IP addresses. There > does not seem to be any reason that a new version of this protocol > could be straightforwardly be developed for IPv6. > > Does this say what it seems to say, or is there a missing "not"? The sentence is too difficult to understand (IMHO) anyway, so probably best reword it to something like: There are numerous other references to 32-bit IP addresses. The protocol cannot be extended to handle IPv6. Instead, a new version protocol is being specified to work with IPv6. > There are at least two places in the draft that need: > > s/depreciated/deprecated/ Yep. > All this results from a superficial survey of the draft, so I suspect > that there are other nits as well. This is not ready to ship. Agreed. Thanks, -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 5 16:56:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18731 for ; Fri, 5 Sep 2003 16:56:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19vNUh-000IYG-Sq for v6ops-data@psg.com; Fri, 05 Sep 2003 20:47:47 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.22) id 19vNUB-000IXC-Bf for v6ops@ops.ietf.org; Fri, 05 Sep 2003 20:47:15 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h85KkAxS052017; Fri, 5 Sep 2003 22:46:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 5 Sep 2003 22:45:50 +0200 Subject: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: v6ops@ops.ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, sep 5, 2003, at 21:43 Europe/Amsterdam, Pekka Savola wrote: >> 4.1 RFC 1771 A Border Gateway Protocol 4 (BGP-4) >> This RFC defines a protocol used for exchange of IPv4 routing >> information and does not support IPv6. A new EGP must be defined >> for >> the exchange of IPv6 routing information. >> This and other references to BGP4 seem to ignore BGP4+ (RFC 2858) >> even though it is listed! > True, but the comments you quote are all from sections 3-6, which > should > (according to the methodology), be examined in the "vacuum", not > looking > forward to documents which fix the issues. There has been some > slippage > from this though. Ok, I'm new here, so I'm not aware of earlier discussions, but... How can it be useful to say that there must be a new EGP while in fact we already have multiprotocol extensions that enable BGP4 to support IPv6, which are widely implemented? This will only confuse people. From owner-v6ops@ops.ietf.org Mon Sep 8 05:25:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04798 for ; Mon, 8 Sep 2003 05:25:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wI6U-0003c2-5i for v6ops-data@psg.com; Mon, 08 Sep 2003 09:14:34 +0000 Received: from [194.196.100.235] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.22) id 19wI5x-0003ZN-VP for v6ops@ops.ietf.org; Mon, 08 Sep 2003 09:14:02 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h889DuEF031198 for ; Mon, 8 Sep 2003 11:13:57 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h889DlK9280908 for ; Mon, 8 Sep 2003 11:13:47 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA58096 for ; Mon, 8 Sep 2003 11:13:46 +0200 Message-ID: <3F5C483E.10EFBF21@zurich.ibm.com> Date: Mon, 08 Sep 2003 11:13:34 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On vrijdag, sep 5, 2003, at 21:43 Europe/Amsterdam, Pekka Savola wrote: > > >> 4.1 RFC 1771 A Border Gateway Protocol 4 (BGP-4) > > >> This RFC defines a protocol used for exchange of IPv4 routing > >> information and does not support IPv6. A new EGP must be defined > >> for > >> the exchange of IPv6 routing information. > > >> This and other references to BGP4 seem to ignore BGP4+ (RFC 2858) > >> even though it is listed! > > > True, but the comments you quote are all from sections 3-6, which > > should > > (according to the methodology), be examined in the "vacuum", not > > looking > > forward to documents which fix the issues. There has been some > > slippage > > from this though. > > Ok, I'm new here, so I'm not aware of earlier discussions, but... How > can it be useful to say that there must be a new EGP while in fact we > already have multiprotocol extensions that enable BGP4 to support IPv6, > which are widely implemented? This will only confuse people. Indeed. So if you want to stick to the original idea for sections 3-6, the whole sentence starting "A new EGP..." should simply be deleted. It's necessary and sufficient to state that the protocol does not support IPv6. Brian From owner-v6ops@ops.ietf.org Mon Sep 8 09:46:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19094 for ; Mon, 8 Sep 2003 09:46:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wMDF-000MQi-NS for v6ops-data@psg.com; Mon, 08 Sep 2003 13:37:49 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19wMCC-000MLf-TP for v6ops@ops.ietf.org; Mon, 08 Sep 2003 13:36:45 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h88Daeg29880; Mon, 8 Sep 2003 15:36:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h88DZ9HN079286; Mon, 8 Sep 2003 15:35:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309081335.h88DZ9HN079286@givry.rennes.enst-bretagne.fr> From: Francis Dupont cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft-tsirtsis-dsmip-problem-01.txt] In-reply-to: Your message of Thu, 04 Sep 2003 12:38:59 +0200. <3F571643.80107@nal.motlabs.com> Date: Mon, 08 Sep 2003 15:35:09 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > So you want to implement and specify one for dual-stack Mobile IPv6 > *too*? No, I want Mobile IPv6 to not require its MN-HA tunnel to be v6-in-v6 but to require it to be either v6-in-v6 or v6-in-v4. => you can't do that with Mobile IPv6 itself but it is still possible to use an alternative, i.e., something which looks like Mobile IPv6 but works for both IP versions. If you wouldn't like to get routing optimization (something a bit hard in this case :-), I suggest the "road warrior" IPsec VPN. But, even if RFC 2401 is clearly for any combination of IP versions, I am afraid that the v6-in-v4 is rarely supported... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Mon Sep 8 11:09:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29156 for ; Mon, 8 Sep 2003 11:09:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wNTl-00038R-IO for v6ops-data@psg.com; Mon, 08 Sep 2003 14:58:57 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 19wNTF-000373-Ja for v6ops@ops.ietf.org; Mon, 08 Sep 2003 14:58:25 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 8 Sep 2003 10:58:23 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CEE@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Francis Dupont'" Cc: v6ops@ops.ietf.org Subject: RE: NAT traversal and its relation to IPv6 [RE: Comments on draft -tsirtsis-dsmip-problem-01.txt] Date: Mon, 8 Sep 2003 10:58:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > No, I want Mobile IPv6 to not require its MN-HA tunnel to > be v6-in-v6 > but to require it to be either v6-in-v6 or v6-in-v4. > > => you can't do that with Mobile IPv6 itself but it is still possible > to use an alternative, i.e., something which looks like Mobile IPv6 > but works for both IP versions. If you wouldn't like to get routing > optimization (something a bit hard in this case :-), I suggest the > "road warrior" IPsec VPN. But, even if RFC 2401 is clearly for any > combination of IP versions, I am afraid that the v6-in-v4 is rarely > supported... => Francis, The IPsec VPN "road warrior" scenario is only applicable to just those "road warriors". You can certainly extend MIPv6 to _allow_ v6 in v4 tunnels, which is what Alex was asking. I don't see why someone who wants seamless roaming and already has MIP is required to have another IPsec anchor somewhere on the Internet. It's not what IPsec is used for and it doesn't need to be. Hesham > > Regards > > Francis.Dupont@enst-bretagne.fr > From owner-v6ops@ops.ietf.org Mon Sep 8 11:51:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03657 for ; Mon, 8 Sep 2003 11:51:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wOER-0006c1-Fi for v6ops-data@psg.com; Mon, 08 Sep 2003 15:47:11 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19wODv-0006Ya-Jl for v6ops@ops.ietf.org; Mon, 08 Sep 2003 15:46:39 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h88FkYg09130; Mon, 8 Sep 2003 17:46:34 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h88Fj5HN079823; Mon, 8 Sep 2003 17:45:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309081545.h88Fj5HN079823@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft -tsirtsis-dsmip-problem-01.txt] In-reply-to: Your message of Mon, 08 Sep 2003 10:58:19 EDT. <748C6D0A58C0F94CA63C198B6674697A01922CEE@ftmail.lab.flarion.com> Date: Mon, 08 Sep 2003 17:45:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > No, I want Mobile IPv6 to not require its MN-HA tunnel to > be v6-in-v6 > but to require it to be either v6-in-v6 or v6-in-v4. > > => you can't do that with Mobile IPv6 itself but it is still possible > to use an alternative, i.e., something which looks like Mobile IPv6 > but works for both IP versions. If you wouldn't like to get routing > optimization (something a bit hard in this case :-), I suggest the > "road warrior" IPsec VPN. But, even if RFC 2401 is clearly for any > combination of IP versions, I am afraid that the v6-in-v4 is rarely > supported... => Francis, The IPsec VPN "road warrior" scenario is only applicable to just those "road warriors". => I disagree, the only missing pieces are the v6-in-v4 support and a more friendly processing of handoffs. You can certainly extend MIPv6 to _allow_ v6 in v4 tunnels, which is what Alex was asking. => no, this is not easy at all because MIPv6 doesn't use only tunnels. You have to introduce IPv4 Care-of addresses and this is a major change. I don't see why someone who wants seamless roaming and already has MIP is required to have another IPsec anchor => not another one, just rename the Home Agent into the Security Gateway. Note you already have some IPsec between the Mobile Node and its Home Agent. somewhere on the Internet. It's not what IPsec is used for and it doesn't need to be. => extra security should not be a problem. The IPsec protection of all packets through the MN-HA tunnel is already an option, and IMHO this will be a commonly used option because the initial/last wireless segment of the path is not known for its security. Regards Francis.Dupont@enst-bretagne.fr PS: note that I suggest IPsec as an example of alternatives. There are many other ways to manage v6-in-v* tunnels, IPsec is just the standard one when someone'd like extra security. From owner-v6ops@ops.ietf.org Mon Sep 8 13:05:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08003 for ; Mon, 8 Sep 2003 13:05:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wPNI-000CfN-Ql for v6ops-data@psg.com; Mon, 08 Sep 2003 17:00:24 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19wPNG-000Cf3-8G for v6ops@ops.ietf.org; Mon, 08 Sep 2003 17:00:22 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19wPNF-0001Y5-Pa for v6ops@ops.ietf.org; Mon, 08 Sep 2003 10:00:21 -0700 Message-ID: <331260000.1063036342@classic.viagenie.qc.ca> In-Reply-To: <200309081545.h88Fj5HN079823@givry.rennes.enst-bretagne.fr> References: <200309081545.h88Fj5HN079823@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Date: Mon, 08 Sep 2003 11:52:22 -0400 From: Marc Blanchet To: Francis Dupont , Soliman Hesham cc: v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft -tsirtsis-dsmip-problem-01.txt] X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit to add to this conversation, tunnel broker with tsp does manage v*-in-v* with security (aaa). if the outer v* address change (i.e. v4 address change for v6 over v4 tunnels), then the tunnel is automatically re-established with the broker: "mobility feature". the ipsec need can be handled on the appropriate IP version. Marc. -- lundi, septembre 08, 2003 17:45:05 +0200 Francis Dupont wrote/a ecrit: > In your previous mail you wrote: > > > > No, I want Mobile IPv6 to not require its MN-HA tunnel to > > be v6-in-v6 > > but to require it to be either v6-in-v6 or v6-in-v4. > > > > => you can't do that with Mobile IPv6 itself but it is still > possible > to use an alternative, i.e., something which looks like > Mobile IPv6 > but works for both IP versions. If you wouldn't like to > get routing > optimization (something a bit hard in this case :-), I > suggest the > "road warrior" IPsec VPN. But, even if RFC 2401 is > clearly for any > combination of IP versions, I am afraid that the > v6-in-v4 is rarely > supported... > > => Francis, > > The IPsec VPN "road warrior" scenario is only applicable > to just those "road warriors". > > => I disagree, the only missing pieces are the v6-in-v4 support and > a more friendly processing of handoffs. > > You can certainly extend MIPv6 > to _allow_ v6 in v4 tunnels, which is what Alex was asking. > > => no, this is not easy at all because MIPv6 doesn't use only tunnels. > You have to introduce IPv4 Care-of addresses and this is a major change. > > I don't see why someone who wants seamless roaming and already > has MIP is required to have another IPsec anchor > > => not another one, just rename the Home Agent into the Security Gateway. > Note you already have some IPsec between the Mobile Node and its Home > Agent. > > somewhere > on the Internet. It's not what IPsec is used for and it doesn't > need to be. > > => extra security should not be a problem. The IPsec protection of > all packets through the MN-HA tunnel is already an option, and IMHO > this will be a commonly used option because the initial/last wireless > segment of the path is not known for its security. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: note that I suggest IPsec as an example of alternatives. There are > many other ways to manage v6-in-v* tunnels, IPsec is just the standard > one when someone'd like extra security. > ------------------------------------------ Marc Blanchet Hexago tel: +1-418-266-5533x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ From owner-v6ops@ops.ietf.org Mon Sep 8 13:10:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08559 for ; Mon, 8 Sep 2003 13:10:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wPUt-000DGr-RE for v6ops-data@psg.com; Mon, 08 Sep 2003 17:08:15 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 19wPUN-000DDd-Tb for v6ops@ops.ietf.org; Mon, 08 Sep 2003 17:07:44 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 8 Sep 2003 13:07:42 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CEF@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Francis Dupont'" Cc: v6ops@ops.ietf.org Subject: RE: NAT traversal and its relation to IPv6 [RE: Comments on draft -tsirtsis-dsmip-problem-01.txt] Date: Mon, 8 Sep 2003 13:07:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The IPsec VPN "road warrior" scenario is only applicable > to just those "road warriors". > > => I disagree, the only missing pieces are the v6-in-v4 support and > a more friendly processing of handoffs. => I was talking in regards to the deployment scenarios and not necessarily the protocol solution. > > You can certainly extend MIPv6 > to _allow_ v6 in v4 tunnels, which is what Alex was asking. > > => no, this is not easy at all because MIPv6 doesn't use > only tunnels. > You have to introduce IPv4 Care-of addresses and this is a > major change. => I don't see it as a major change. It's fairly straight forward. We have one example of doing so in: http://www.ietf.org/internet-drafts/draft-soliman-v4v6-mipv4-00.txt > > I don't see why someone who wants seamless roaming and already > has MIP is required to have another IPsec anchor > > => not another one, just rename the Home Agent into the > Security Gateway. > Note you already have some IPsec between the Mobile Node and its Home > Agent. => Only for MIPv6 signalling. It's not used in MIPv4 and it's not required to protect traffic in v4 or v6. It would be an unnecessary overhead if we used it for all packets. > > somewhere > on the Internet. It's not what IPsec is used for and it doesn't > need to be. > > => extra security should not be a problem. => It's a problem when it's not needed because it adds significant overhead. The IPsec protection of > all packets through the MN-HA tunnel is already an option, and IMHO > this will be a commonly used option because the initial/last wireless > segment of the path is not known for its security. => Your comments on the security of last hop are not accurate for cellular systems. But of course, sometimes you need e2e security, I agree. However, there is a big difference between that and mandating e2e security for all traffic. If we wanted to manage mobility with IPsec why did we ever develop MIP! ;) > PS: note that I suggest IPsec as an example of alternatives. > There are > many other ways to manage v6-in-v* tunnels, IPsec is just > the standard > one when someone'd like extra security. => Sure. Hesham > From owner-v6ops@ops.ietf.org Tue Sep 9 03:09:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23383 for ; Tue, 9 Sep 2003 03:09:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wc4d-000Dfs-Rh for v6ops-data@psg.com; Tue, 09 Sep 2003 06:33:59 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19wc4Y-000DfN-UH for v6ops@ops.ietf.org; Tue, 09 Sep 2003 06:33:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h896Wnn13124; Tue, 9 Sep 2003 09:32:50 +0300 Date: Tue, 9 Sep 2003 09:32:49 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: <3F5C483E.10EFBF21@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 8 Sep 2003, Brian E Carpenter wrote: > > On vrijdag, sep 5, 2003, at 21:43 Europe/Amsterdam, Pekka Savola wrote: > > > > >> 4.1 RFC 1771 A Border Gateway Protocol 4 (BGP-4) > > > > >> This RFC defines a protocol used for exchange of IPv4 routing > > >> information and does not support IPv6. A new EGP must be defined > > >> for > > >> the exchange of IPv6 routing information. > > > > >> This and other references to BGP4 seem to ignore BGP4+ (RFC 2858) > > >> even though it is listed! > > > > > True, but the comments you quote are all from sections 3-6, which > > > should > > > (according to the methodology), be examined in the "vacuum", not > > > looking > > > forward to documents which fix the issues. There has been some > > > slippage > > > from this though. > > > > Ok, I'm new here, so I'm not aware of earlier discussions, but... How > > can it be useful to say that there must be a new EGP while in fact we > > already have multiprotocol extensions that enable BGP4 to support IPv6, > > which are widely implemented? This will only confuse people. > > Indeed. So if you want to stick to the original idea for sections 3-6, > the whole sentence starting "A new EGP..." should simply be deleted. > It's necessary and sufficient to state that the protocol does not > support IPv6. Agreed, this should be OK. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Sep 9 09:04:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04727 for ; Tue, 9 Sep 2003 09:04:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19whx5-0005nK-6t for v6ops-data@psg.com; Tue, 09 Sep 2003 12:50:35 +0000 Received: from [129.188.136.101] (helo=ftpbox.mot.com) by psg.com with esmtp (Exim 4.22) id 19whwV-0005hu-Rt for v6ops@ops.ietf.org; Tue, 09 Sep 2003 12:49:59 +0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h89CnHkn018003; Tue, 9 Sep 2003 05:49:23 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h89CmsY8024238; Tue, 9 Sep 2003 07:48:56 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 376432EC86; Tue, 9 Sep 2003 14:49:11 +0200 (CEST) Message-ID: <3F5DCC47.5010103@nal.motlabs.com> Date: Tue, 09 Sep 2003 14:49:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Blanchet Cc: Francis Dupont , Soliman Hesham , v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft -tsirtsis-dsmip-problem-01.txt] References: <200309081545.h88Fj5HN079823@givry.rennes.enst-bretagne.fr> <331260000.1063036342@classic.viagenie.qc.ca> In-Reply-To: <331260000.1063036342@classic.viagenie.qc.ca> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marc Blanchet wrote: > to add to this conversation, tunnel broker with tsp does manage > v*-in-v* with security (aaa). if the outer v* address change (i.e. v4 > address change for v6 over v4 tunnels), then the tunnel is > automatically re-established with the broker: "mobility feature". the > ipsec need can be handled on the appropriate IP version. The idea to join the Security Gateway into the HA, or the tunnel broker into the HA can not stand, because the HA performs proxy ND for HoA of MH when MH is not at home. The Security Gateway/tunnel brokers is something that lies in the perimeter buffer secure zone ('DMZ'), while an HA is most of the time the router towards a link, most often a leaf link. Alex GBU From owner-v6ops@ops.ietf.org Tue Sep 9 09:05:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04739 for ; Tue, 9 Sep 2003 09:05:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wi2w-0006EN-FG for v6ops-data@psg.com; Tue, 09 Sep 2003 12:56:38 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19wi1m-0006An-QL for v6ops@ops.ietf.org; Tue, 09 Sep 2003 12:55:27 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h89CtGR26297; Tue, 9 Sep 2003 14:55:16 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h89CrfHN083144; Tue, 9 Sep 2003 14:53:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309091253.h89CrfHN083144@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: Marc Blanchet , Soliman Hesham , v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft -tsirtsis-dsmip-problem-01.txt] In-reply-to: Your message of Tue, 09 Sep 2003 14:49:11 +0200. <3F5DCC47.5010103@nal.motlabs.com> Date: Tue, 09 Sep 2003 14:53:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: Marc Blanchet wrote: > to add to this conversation, tunnel broker with tsp does manage > v*-in-v* with security (aaa). if the outer v* address change (i.e. v4 > address change for v6 over v4 tunnels), then the tunnel is > automatically re-established with the broker: "mobility feature". the > ipsec need can be handled on the appropriate IP version. The idea to join the Security Gateway into the HA, or the tunnel broker into the HA can not stand, because the HA performs proxy ND for HoA of MH when MH is not at home. => this is 100% contrary to actual experience: your objection is wrong. The Security Gateway/tunnel brokers is something that lies in the perimeter buffer secure zone ('DMZ'), while an HA is most of the time the router towards a link, most often a leaf link. => in both cases (SG and TB) in fact the mobile node is never at home so the position of the SG or TB is not a problem at all. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Tue Sep 9 10:23:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12623 for ; Tue, 9 Sep 2003 10:23:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wjI5-000DEU-Sv for v6ops-data@psg.com; Tue, 09 Sep 2003 14:16:21 +0000 Received: from [129.188.136.100] (helo=motgate.mot.com) by psg.com with esmtp (Exim 4.22) id 19wjHX-000DCO-5D for v6ops@ops.ietf.org; Tue, 09 Sep 2003 14:15:47 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h89EFD8M021456; Tue, 9 Sep 2003 07:15:14 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h89EF9LR024838; Tue, 9 Sep 2003 09:15:10 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5EA892EC86; Tue, 9 Sep 2003 16:15:11 +0200 (CEST) Message-ID: <3F5DE06F.8000408@nal.motlabs.com> Date: Tue, 09 Sep 2003 16:15:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Marc Blanchet , Soliman Hesham , v6ops@ops.ietf.org Subject: Re: NAT traversal and its relation to IPv6 [RE: Comments on draft -tsirtsis-dsmip-problem-01.txt] References: <200309091253.h89CrfHN083144@givry.rennes.enst-bretagne.fr> In-Reply-To: <200309091253.h89CrfHN083144@givry.rennes.enst-bretagne.fr> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > Marc Blanchet wrote: > > to add to this conversation, tunnel broker with tsp does manage > > v*-in-v* with security (aaa). if the outer v* address change (i.e. v4 > > address change for v6 over v4 tunnels), then the tunnel is > > automatically re-established with the broker: "mobility feature". the > > ipsec need can be handled on the appropriate IP version. > > The idea to join the Security Gateway into the HA, or the tunnel broker > into the HA can not stand, because the HA performs proxy ND for HoA of > MH when MH is not at home. > > => this is 100% contrary to actual experience: your objection is wrong. Right, and knowing what's wrong is good. > The Security Gateway/tunnel brokers is something that lies in the > perimeter buffer secure zone ('DMZ'), while an HA is most of the time > the router towards a link, most often a leaf link. > > => in both cases (SG and TB) in fact the mobile node is never at home > so the position of the SG or TB is not a problem at all. Ok. I think all I wanted to say is, as already known, that if one tries to use Mobile IPv6 on a mobile terminal on a typical commercial wireless access network, one often ends up with several levels of encapsulation which are obviously redundant. Having available several building blocks (NAT traversal, IPsec tunneling, tunnel broker) that help achieve this is a good thing. Eliminating some of the encapsulations by touching only the ends could also be advantageous. Alex GBU From owner-v6ops@ops.ietf.org Wed Sep 10 08:02:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26753 for ; Wed, 10 Sep 2003 08:02:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19x3WF-0002vX-Km for v6ops-data@psg.com; Wed, 10 Sep 2003 11:52:19 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 19x3WA-0002vA-ML for v6ops@ops.ietf.org; Wed, 10 Sep 2003 11:52:14 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8ABqAB20366 for ; Wed, 10 Sep 2003 14:52:12 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 10 Sep 2003 14:52:09 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 10 Sep 2003 14:52:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: 3GPP Analysis -05 published ... -> wglc (?) Date: Wed, 10 Sep 2003 14:52:06 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDE97@esebe005.ntc.nokia.com> Thread-Topic: 3GPP Analysis -05 published ... -> wglc (?) Thread-Index: AcN3kfTxsLKHFgH1T0S6XgNL9DXZ6g== From: To: X-OriginalArrivalTime: 10 Sep 2003 11:52:07.0198 (UTC) FILETIME=[F5A943E0:01C37791] X-Spam-Status: No, hits=2.0 required=5.0 tests=NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi! 3GPP Analysis document issues have been open for a while and I decided = to move forward and compose revision -05. I hope that the wg is happy = with this document and (at least 90% of ) the issues have been solved = well enough. If somebody thinks that there still are issues / all issues have not yet = been fully resolved, wglc would be a good way to find it out. I believe = that our document is now ready for wglc, but of course, that decision is = up to the v6ops chairs. Before the document can be found on the IETF servers, you can find it = here: http://danforsberg.info/draft-ietf-v6ops-3gpp-analysis-05.txt Cheers, -Juha W.- From owner-v6ops@ops.ietf.org Wed Sep 10 14:03:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10728 for ; Wed, 10 Sep 2003 14:03:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19x9Bh-000Ppf-VK for v6ops-data@psg.com; Wed, 10 Sep 2003 17:55:29 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 19x9BB-000Pmc-VA for v6ops@ops.ietf.org; Wed, 10 Sep 2003 17:54:58 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10352; Wed, 10 Sep 2003 13:54:51 -0400 (EDT) Message-Id: <200309101754.NAA10352@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-05.txt Date: Wed, 10 Sep 2003 13:54:51 -0400 X-Spam-Status: No, hits=2.0 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@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 IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-05.txt Pages : 19 Date : 2003-9-10 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-v6ops-3gpp-analysis-05.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-v6ops-3gpp-analysis-05.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: <2003-9-10103304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-10103304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Sep 11 02:55:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13656 for ; Thu, 11 Sep 2003 02:55:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xLGe-000Evl-Ab for v6ops-data@psg.com; Thu, 11 Sep 2003 06:49:24 +0000 Received: from [138.190.3.48] (helo=sbe3777.swissptt.ch) by psg.com with esmtp (Exim 4.22) id 19xLGL-000EvH-0C for v6ops@ops.ietf.org; Thu, 11 Sep 2003 06:49:05 +0000 Received: from sbe2172.corproot.net (138.190.70.54) by sbe3777.swissptt.ch (MX V5.3 AnHp) with SMTP for ; Thu, 11 Sep 2003 08:49:02 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxsmtp01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Sep 2003 08:49:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C37830.C84B0AC4" Subject: ISATAP deployment Date: Thu, 11 Sep 2003 08:49:01 +0200 Message-ID: <595362761E89B640A907F5112F8B89B802180297@sxmbx03.corproot.net> X-MS-Has-Attach: yes Thread-Topic: ISATAP deployment Thread-Index: AcN2pVFHujocpvlWSM+kW8/lRi9KIgBitVfQ From: To: CC: , , X-OriginalArrivalTime: 11 Sep 2003 06:49:01.0283 (UTC) FILETIME=[C86C9B30:01C37830] Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C37830.C84B0AC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello I was encouraged to post this to the v6ops mailing list:=20 Attached a technical article we wrote on the IPv6 deployment in the = Swisscom Innovations operational intranet using ISATAP. This might serve = as input to the v6ops design team. It is also a nice example of how easy (and cheap) the first transition = phase to IPv6 is. If you want to know more about that don't hesitate to = come back to me. Best regards Andreas ------------------------ Andreas Schmid-Pe=F1a Swisscom Ltd Innovations, Z=FCrich=20 P.O. Box 8377 CH-8036 Z=FCrich, Switzerland phone: +41 (0)1 294 8525 mobile: +41 (0)79 277 4804 fax: +41 (0)86 079 277 4804 email: andreas.schmid1@swisscom.com web: http://www.swisscom.com/innovations Swiss IPv6 Task Force: http://www.ch.ipv6tf.org ------_=_NextPart_001_01C37830.C84B0AC4 Content-Type: application/octet-stream; name="comtec0309_IPv6-Deployment_Schmid.pdf" Content-Description: comtec0309_IPv6-Deployment_Schmid.pdf Content-Disposition: attachment; filename="comtec0309_IPv6-Deployment_Schmid.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjI4IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzMCANL0ggWyAx MTgwIDM1MSBdIA0vTCAyNjY0NzQgDS9FIDEyODQ0OCANL04gNSANL1QgMjY1Nzk2IA0+PiANZW5k b2JqDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTI4IDM3IA0wMDAwMDAwMDE2IDAwMDAwIG4gDTAwMDAwMDEwODcgMDAwMDAgbiANMDAw MDAwMTUzMSAwMDAwMCBuIA0wMDAwMDAxNzM4IDAwMDAwIG4gDTAwMDAwMDE5MzAgMDAwMDAgbiAN MDAwMDAwMTk2OSAwMDAwMCBuIA0wMDAwMDAxOTkwIDAwMDAwIG4gDTAwMDAwMDI0ODkgMDAwMDAg biANMDAwMDAwMjUxMCAwMDAwMCBuIA0wMDAwMDAzMDQ0IDAwMDAwIG4gDTAwMDAwMDMwNjUgMDAw MDAgbiANMDAwMDAwMzYwNiAwMDAwMCBuIA0wMDAwMDAzNjI3IDAwMDAwIG4gDTAwMDAwMDQzMDEg MDAwMDAgbiANMDAwMDAwNTExMSAwMDAwMCBuIA0wMDAwMDA1NzU3IDAwMDAwIG4gDTAwMDAwMDU3 NzggMDAwMDAgbiANMDAwMDAwNjQ3NyAwMDAwMCBuIA0wMDAwMDA3MjY3IDAwMDAwIG4gDTAwMDAw MDk0MzYgMDAwMDAgbiANMDAwMDAwOTkxMCAwMDAwMCBuIA0wMDAwMDEwMTA5IDAwMDAwIG4gDTAw MDAwMTA0ODQgMDAwMDAgbiANMDAwMDAxMTA5MiAwMDAwMCBuIA0wMDAwMDExNDIyIDAwMDAwIG4g DTAwMDAwMTE0NDMgMDAwMDAgbiANMDAwMDAxMTk0NCAwMDAwMCBuIA0wMDAwMDExOTY1IDAwMDAw IG4gDTAwMDAwMTI0NzggMDAwMDAgbiANMDAwMDAxMjQ5OSAwMDAwMCBuIA0wMDAwMDEzMDEyIDAw MDAwIG4gDTAwMDAwMTMwOTAgMDAwMDAgbiANMDAwMDAxNzcxMCAwMDAwMCBuIA0wMDAwMDIxODEx IDAwMDAwIG4gDTAwMDAwMjQ0ODggMDAwMDAgbiANMDAwMDAwMTE4MCAwMDAwMCBuIA0wMDAwMDAx NTEwIDAwMDAwIG4gDXRyYWlsZXINPDwNL1NpemUgNjUNL0luZm8gMjYgMCBSIA0vUm9vdCAyOSAw IFIgDS9QcmV2IDI2NTc4NiANL0lEWzxlYTkxMTIzMWNlMmEwMjc3NjJkYjllNmNjZmFlNjhmZD48 ZTg3NWIzZjdiOTMzMDhjZGNjYWFlMDJjZjc2NTA4N2Y+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0g ICAgDTI5IDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDI1IDAgUiANL01ldGFkYXRh IDI3IDAgUiANL1BhZ2VMYWJlbHMgMjQgMCBSIA0+PiANZW5kb2JqDTYzIDAgb2JqDTw8IC9TIDE2 NiAvTCAyODggL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA2NCAwIFIgPj4gDXN0cmVhbQ0K SIliYGBgZmBgmcPAxsAgVsIgyIAAggysQFEWBo4KIOdNLNt+oIpHH5gEShTNGxCqmA7ZSvq0ad6t /PGiKJmb40vSvIjk2uvLFh5Wcis6P2nCwqnPM+pWPCs4dMhWIrWrXLb2ldobEDiARCIz1iAJIKwE 2sPLwHydHUgrArE22GZRoAtjGbQOMDkwMPB9AHqCiYGBkQUoEbjAMEC4g4GB1YeZkcWIodBBzEFM QSiC5QpQ/gFQvhqI5Q4wnnC/I/+AK+HUNoY5Dp4MzA0CHmw/FGYwJrJJNgQ1KiTAfSjOwMKxD+RT IPYGCDAACFJfdg1lbmRzdHJlYW0NZW5kb2JqDTY0IDAgb2JqDTIzOCANZW5kb2JqDTMwIDAgb2Jq DTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyNSAwIFIgDS9SZXNvdXJjZXMgMzEgMCBSIA0vQ29u dGVudHMgWyAzNCAwIFIgMzYgMCBSIDM4IDAgUiA0MCAwIFIgNDQgMCBSIDUzIDAgUiA1NSAwIFIg NTcgMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4 NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTMxIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgL0ltYWdlQyBdIA0vRm9udCA8PCAvRjEgNDEgMCBSIC9GMiA0NSAwIFIgL0YzIDUwIDAg UiA+PiANL1hPYmplY3QgPDwgL0ltMSA2MiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1OCAw IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMzIgMCBSID4+IA0+PiANZW5kb2JqDTMyIDAgb2Jq DVsgDS9JQ0NCYXNlZCA2MSAwIFIgDV0NZW5kb2JqDTMzIDAgb2JqDTQyMSANZW5kb2JqDTM0IDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzMgMCBSID4+IA1zdHJlYW0NCkiJ XJRJjtwwDEVP4DvoBG6Jg0its8gBcgQDSTdQyabuD4SD5FL1xvArTp9fcn38ePZyPUs9G4o/AeLJ 5Xn9Oz5+/mrlz/PA8lUOxVNUCuLJbZS/G5NIceIRhODUFRZdnttJFj82Zh3J36jz4m1ul/Ku4jo+ PXtgTG6NU5dizIYh2U1bdEPI+hH1yLMbBcnUqT1ZIzpaqibYiJEyd3IHKlEZU7sGCdwUuQy0+LGx a979+M7Iyy9+Z9Hxlr958EhXpPkPWiFNGXiz0tlqpPdGG+EIE25ukmt7JZwjz2K9x1bkZ7FCOaDp 633untAhulEeX+jYRV676kGUqqnyYqPGGp1y3iS084wxk2sEyXUpt5dmh9iu+nYzSCesKt1o9rxZ avhUW9/UvKRex++DOLKg27VoJp7MRr2ZzCQoIOaCLBjn6F6baIpqtZh17HnpuFA/q+oES+z2RfQV E4vNu0tOnDYDdU8Vsw69KaB/BZ5d46zsnngfZAeuOQT7osuFx6c8o7aG3Xds9vndYH8RTTLVGfRU UY8yxZI6rJDNGll0/RdgAKet2wUNZW5kc3RyZWFtDWVuZG9iag0zNSAwIG9iag00NTYgDWVuZG9i ag0zNiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM1IDAgUiA+PiANc3Ry ZWFtDQpIiWSUy20DMQxEK9geVAEh8SexngWCHOL+rxnqs46Rm58lkkNytJc66ZDCnUZY0U5VrfCg ypykpkms5b6ApppXWaX8JDfcAtfeSybKUKdorahRr3rovr4uE6rhRSpxi/I6jOQWvRgT95gyDNRI RA7dl1VqvR3WgI4Z6RGHMq9wqtzcaFQpiNSmRZis2sm7CXnzx3hOt8JG7lw+9d7X92VKDKn5Dyb2 ehjRHvO+IZeQumQlFT+0VPFBHSQYFQrF4IfQY8tmN2ezeRoIiRzkGJ5pW8ihew4xB7NPlyAMRryX T7m5AldqMsdYa0MDm6GjdsNC3xzmxYWCfbbXRtIcx6L7cqY24jnFYHlGZuCGChPNq4t3WZRBp0P/ ccoY/YMHLAGqbZxCFtTsrcIGjPGosE7SZ6Ai/tCRsfkpa07M9o+RK00PNnj3bQ6bSZPSoIZlLRpp usNCbLFi+9q3CGKdXOap5JagY1lD9OiSOdnoqwe8mFSR9sVbk1mn8rqa+RNrTgrs086BDjAL1T49 1j0Hlb7ZdOdQRzuIjTRfreElg9LimVVk7Uv7LOrgXLTrEwnVf7MqXu87rcFqGTcwxw3YfeDj8SvA APWe19cNZW5kc3RyZWFtDWVuZG9iag0zNyAwIG9iag00NjMgDWVuZG9iag0zOCAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM3IDAgUiA+PiANc3RyZWFtDQpIiWSTQY7kMAhF T5A7+ATIBgPmPJFGs6i+/3Y+uJyunl5FL9h8+ODLlHg1dup9tNdlk4aMb/5zWZCYNDZa1r4uc1ox 3wiYXKdl6kOLoku7rzfLoKUzcxtNZPrFgtsr+X3+f0aFbMm7ErDP+OBz3jsC/JsfPZx3/cWMj44P XmQRDaS4DZqLG3J19kN35mb1j6jKSlKR9tZNWrrPFsNTiV2XcDoY4imzmI+fn17fMN+VpqLkTlHu u0AhDr+KIzsypAIEChemvmbzSWrj0J2pBssTReKVF7391Livv5djnp4/FL58HWTigVaNFEbAZMWC QMQGH4IIk2ETTnSghFLUdaDT6FVOITxZFg3XvMe7b+T0GI8JKC+N3iFsDNvZTtQ1Zm0fR6WEo1a+ O0x8JYvPmlFotunoHyRWTffwQ7g7UeQT3C6DlkpRigbWogqCHd0Pv4pn+dc7t8c7XtJ+GJnzXIN2 Zy5pbNBwPuyLxqqnGPJNQeGlujmXN6AStF/KXNGQVGUeulMk9juoKKOnHWVNcttvjPONgjXHsjfo lcxZMhZDKnNgWik6rHTsAK52MnsYxKNWcbg/hGnLPpqIZgbWNS9qTUL1qf5N9z8BBgBtlOGPDWVu ZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmoNNTk2IA1lbmRvYmoNNDAgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAzOSAwIFIgPj4gDXN0cmVhbQ0KSImsUstu2zAQ/AL+wx7JoKL5 EEnx2CIN4J4SVEAPSQ6GTDdq9UgkNa4/oP/dXSoP31sIMHfJ2dnZ8bJKy6hKMJV0LkJlpKXYW0ex V4GyUEVoGObBazBB6lJDR7k1HoyXMSBay6AtZVWwlOnXuGEH9sQ0tMAUVKUBFx0UFEzp5aZn32Bg SirtKMcTQaWMMeMoRShBNNA3NwQ21Tk2GHcOPrCbt6YZ6ZR04JXFYRDnKokzEekFNf5XWU/MK7wP tgSFX+WiNMZZyK2LisShDz3bbHsNlyNqu/lvlnyq2eaKXKkPLOKMJIBO57z0Jf1BQSqE1z0rkE4p A3WDTeoj48aJ+geW27W8VLkaD+wQImr21kvjDBW/W080wVii4fVIDErGynssrS/zq65yE37c0avG PYlnr0r5LIEiRzpu+bSfQRS4SXx5SHD41YlCO+l4B5fpsRsFxSe803j2aVjEff2FFbiAGjey0KiR yDNjuTKOB9hiQZQlv3728AfpQyb/LDQuNv/9mCZ8V/jepqFJsFtJ6wvy5tWgr+t0ZYVbc6ZfE+It pHbHdp4bgXSRjz1sh2EUEeNnYaw0fCestHxpx2HOTTZXZnVc6+w4HsagTSFEDEqZfemxsbYBl0gb k3/duvlrx4+HJU3Q74YTnNJumgEnXtK8tMN3aAeYhA4y8DTj2xo2DzCk5ThOP+cPQE5g2O2P7T5l TSr7GEygMW/5nnw/kdeZGOHbYcmWBZwLieD6hXdcxmbs4DlNMw4IHu74Fi2/EySjGfs+vQpod524 /yvAAFpbBukNZW5kc3RyZWFtDWVuZG9iag00MSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0 eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDIxMyANL1dpZHRocyBbIDI3OCAz ODkgNTU2IDU1NiA1NTYgMTAwMCA2NjcgMjc4IDI3OCAyNzggNTU2IDYwMCAyNzggMzMzIDI3OCAy NzggDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDYwMCA2 MDAgNjAwIDUwMCANODAwIDY2NyA1NTYgNjY3IDY2NyA1MDAgNDQ0IDcyMiA2NjcgMjIyIDMzMyA2 MTEgNDQ0IDg4OSA2NjcgNzIyIA01MDAgNzIyIDU1NiA1MDAgNTAwIDY2NyA2MTEgOTQ0IDYxMSA2 MTEgNTAwIDI3OCAyNzggMjc4IDYwMCA1MDAgDTIyMiA1MDAgNTU2IDQ0NCA1NTYgNTAwIDMzMyA1 NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiANNTU2IDU1NiAzMzMgMzg5IDMzMyA1 NTYgNDQ0IDc3OCA0NDQgNDQ0IDQ0NCAyNzggMjIyIDI3OCA2MDAgMjc4IA02NjcgMCAwIDAgMCAw IDAgMCAwIDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDAgDTAgMCA1 NTYgMCAwIDU1NiA1NTYgMCAwIDAgMCAwIDgwMCAwIDAgMjIyIDI3OCAwIDAgMjc4IDYwMCAyNzgg Mjc4IA0wIDU1NiAyNzggMjc4IDI3OCAyNzggMjc4IDAgMCAyNzggMCAwIDAgMCAwIDI3OCAwIDI3 OCAyNzggNTU2IDU1NiANMCAyNzggMCAwIDAgMCAwIDUwMCAwIDU1NiA1NTYgMCAyNzggXSANL0Vu Y29kaW5nIC9NYWNSb21hbkVuY29kaW5nIA0vQmFzZUZvbnQgL0hCSUtNTytGcnV0aWdlci1MaWdo dCANL0ZvbnREZXNjcmlwdG9yIDQyIDAgUiANPj4gDWVuZG9iag00MiAwIG9iag08PCANL1R5cGUg L0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDc1MCANL0NhcEhlaWdodCA2OTggDS9EZXNjZW50IC0y MTAgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTE1MiAtMjUwIDEwMDAgOTExIF0gDS9Gb250TmFt ZSAvSEJJS01PK0ZydXRpZ2VyLUxpZ2h0IA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDYzIA0vWEhl aWdodCA1MTAgDS9TdGVtSCA1NCANL0NoYXJTZXQgKC90d28vZml2ZS9uaW5lL3NsYXNoL3plcm8v dGhyZWUvc2l4L28vZC9hL3kvcXVvdGVyaWdodC9zL3NwYWNlL0kvbi90L2UvclwNL2kvYi9oL2h5 cGhlbi9QL2MvbC92L2ZvdXIvcGFyZW5sZWZ0L3BhcmVucmlnaHQvcGVyaW9kL0EvcC9rL3cvVy9t L2cvdS9vXA1uZS9jb21tYS9FL3gvZi9TL0gvTi9UL0MvRC9SL1UvY29sb24vai9laWdodC9lbmRh c2gvcXVvdGVkYmxsZWZ0L3F1b3RlZGJcDWxyaWdodC9NL2JyYWNrZXRsZWZ0L2JyYWNrZXRyaWdo dC9xL0YvRy9ZL0wvQWRpZXJlc2lzL2RpZXJlc2lzL0Ivc2V2ZW4vWFwNL08vWi96L2d1aWxsZW1v dGxlZnQvZ3VpbGxlbW90cmlnaHQvSi9LL2xlc3MvZ3JlYXRlci9udW1iZXJzaWduL1YvdWRpZXJl XA1zaXMvb2RpZXJlc2lzL2FkaWVyZXNpcykNL0ZvbnRGaWxlMyA1OSAwIFIgDT4+IA1lbmRvYmoN NDMgMCBvYmoNNjIxIA1lbmRvYmoNNDQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl bmd0aCA0MyAwIFIgPj4gDXN0cmVhbQ0KSIlsUstu2zAQ/AL9w54Ku0gUS7JexwBOgaSXtFFPTQ+0 tIqYUKRKUlb8of2fLmnJdYtCgIQhd2dnZ1Q9BNXHYCXRTkq/GeAGpJrAsjcuX2AQrMYQbg1n8LxC M2DNmRBHeGADk8BkA09qtN26enU031eflV5HeZivkD2vHZlA1jgm2yFM7LguI7oM4W6c69SArqxV QqjJFU7cdsCgZ8bwA93J6/WP6uHEfkBje5SWTuH+8ZBdL8MEs9jA1w87GBbeV6ytCeEr1tQg5sFX Xse3p1vomFl4V8Yy7fqtAoOaq9HQhrWShjeo/aAr2qOB/dG373Cgeq9DtYSu5+1XLUqD5NNO7Wh5 2zHrViMPpfQWKMB3rEeLnqYdhQCrGY2xXEnHRcdnJ4meL+sBAdSD5kR//whzWI7QiXO64s2mCM8L PU3cmFr1cC+lOjBHb9zGsEeUoMeTHt9ryVI4p99SfIuAnyMnpQymjgu88lnXo14kOU/9GhSg9hOY oHFuH/Rr+3zwMj22JxNDqDq6JQN5LRD2mmNLTJw65+CasUYqkLO+PwYZSpJRPBeMpKlBU2u+pxZ8 JykcpWt/YVxSYu1C2nutDQ5CHZfkPD+XZ9fUqM8bhM6GKIUNPfTZxmFepgnkaR5utmUMVR9E4B5T SxLyP8N/weMy/UWzvsfTD3fzybVVbVCGJ3r3LYpwm8UpxERPSTr6TRglOdA7jv07nUeVN5T1OsqI N/GEd1XwJSiSMC9ySJIwjUroL/A2z8GhtPQoiR3KinhBtavNtvmCxQVOi/KE/0FZuuCLuVkOf6uo g85Vl4mfHJGN/W8BBgAdmVBIDWVuZHN0cmVhbQ1lbmRvYmoNNDUgMCBvYmoNPDwgDS9UeXBlIC9G b250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyMTMgDS9XaWR0 aHMgWyAyNzggMzg5IDQ4MSA1NTYgNTU2IDEwMDAgNzIyIDI3OCAzMzMgMzMzIDU1NiA2MDAgMjc4 IDMzMyAyNzggMzg5IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4 IDI3OCA2MDAgNjAwIDYwMCA1MDAgDTgwMCA3MjIgNjExIDYxMSA3MjIgNTU2IDUwMCA3MjIgNzIy IDI3OCAzODkgNjY3IDUwMCA5NDQgNzIyIDc3OCANNTU2IDc3OCA2MTEgNTU2IDU1NiA3MjIgNjY3 IDEwMDAgNjY3IDY2NyA1NTYgMzMzIDM4OSAzMzMgNjAwIDUwMCANMjc4IDU1NiA2MTEgNDQ0IDYx MSA1NTYgMzg5IDYxMSA2MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgNjExIA02MTEgNjExIDM4 OSA0NDQgMzg5IDYxMSA1NTYgODg5IDU1NiA1NTYgNTAwIDMzMyAyMjIgMzMzIDYwMCAyNzggDTAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCANMCAwIDU1NiA1NTYgMCAwIDAgMCAwIDgwMCAwIDAgMCAyNzggMCAwIDI3OCA2MDAgMjc4 IDI3OCAwIDYxMSAyNzggDTI3OCAyNzggMjc4IDI3OCAwIDAgMjc4IDAgMCAwIDAgMCAyNzggMCAy NzggMjc4IDAgMCAwIDI3OCAwIDAgMCANMCAwIDAgMCAwIDAgMCAyNzggXSANL0VuY29kaW5nIC9N YWNSb21hbkVuY29kaW5nIA0vQmFzZUZvbnQgL0hCS0VHRytGcnV0aWdlci1Cb2xkIA0vRm9udERl c2NyaXB0b3IgNDcgMCBSIA0+PiANZW5kb2JqDTQ2IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMjA3NyAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJdFR5WBT3GZ5h dmYQYUhcZl12cGaVGjWimAaRQ1TAi4LBgyBF5QhyitygVBFWEHaX3QVB8WqyGETx4JDDCw3UC4JH Y6g2trZV0yTk2kgMfMPzQ5/OYvLU2vaZZ/6Y32++93u/93u/D8dkNhiO48rlAcFLli6ZGZYUvyJ5 a0B66sZZK1Njk9Osd64ih4suMnGSvSJ29F0X6m8usn0kvOYIc1+D0Nc7XMYtmIAREsSkWcfVIblx 6thstXpjvHpZVnp6jvotb2+PMaT/QsZw6cEmYthUHHsTw97CMA8cC8CwxQQWhGMrZNgaGkvHcHs1 5oktxoOwldgaPBaLI5LwVFkW/QmG8RJzjMBkWA52AxvC7fE4vBt/bBNmc5BwIJKIegJknrJIWQ85 kYwi+ygHKpaqpwnaiz5M37d1sw3MZpirRYCDBmxgGtjgXeAKycARYhtsY0Ex/x9IERyek5DG6w2m /aa9xj3Ow8c+vQ3juNo6nbZWAJI2bMs0bOdQJpqGZqM6FPrVGxKE29MnMFlAXAG7bGPE0sXJ1+5c aenuv9kas4hnwLUMCDEOcPwOKOAMqIkROxhkQYOcB1C8l7dWF84/m0vrrvZq73CQAW7gANsFpNaw yMM9EMkzM4ymfF5cRxtrjxmOczD76lw0VWBSy4GA4CHweQFMiEEKIJAGgiF3COVKxxrAR4ln82gG VZWbRxzNY3/BesXIPKSwHkunkAoY5A+NEfO3qlApprCgnPMZ8gkK1WvD+GfzpJudtO7QofJ9HHj9 8CNMlKosZgPCon31fOEOg3GHALm04eDB8kPc560xywQmrwhIMQMwvA14mAoCIb4H8SwkopYocFB1 nm68195RUnSarwKKrIqLroznkKebF7IXUBY0X0esakVERlDkuzX74/li5EAWdXSWdnLg82QA5AJT UG4W24HAYbW14mKxlwViNAcREDjaCwqxl2aOab4H5d+HLPhpYMAbnAixpZr9K51mTK7IrrAFDQ14 1A3kERy8I/+3fI2arOvoOXiO6z+SsVbIoJEfsgtB4327Ir6429t6pU4w6MmyTP3mNNVN3Wemvmpb tAnWs6ExoSEJubUn2463Ascz03dKjbg0jDeCihD5A6ykO1mQkVCSzHmmXHv4dXvPg5MnijVHhf1A kHs2JVYmc2ixDxqP3JHfo0Dguy/u3d8oMB8XDUHfE7wJVBAGckLsf4n1iAMdYPTThhTb+tINusay ujJbpKBNuVsMeRzynoFs0Xw0pWcOOPz5cuvlesFIlWXoNmWpbv3MOQVMrGec3/JVGZ0D4Nh1/k+H D2tLP+QZjeYH4B9bvpaYKyXbSEkzoJUFx2ALmopmzEMy5IYCP58Pv/64r6a2my+0kFtiwosiOfcN 5wYMAvRSplqD+fcqJG9gUTDVU9XS2s39oTFhhU5g0AKpUYwFJj3Fv7EC242ksbsz040ZHHJZEYQ4 Ic5j+uPRKSAXp4CtBdl20LeONFz54ENdiZlnuqTY14fxu+AES6TguyP27DN76aOEfnzp7s3OA6lr efQpyGGQfpzYj2R+qxPWWOeVrGowdhxXQQrtb1ygDX5JLAblSZDO/+wDd3xQQgTdiJw9k9gYHZOY FBvTnHTmbHPTGX4bmsxaI1+WedQV5NIA7S43W+kQEDWSzr6KbuVGM6LdC9YSvjRKE6TXiRi5o4Bv aCDDu2fOC4uIzOE7CxO63ub8Qze+s1nQUxUNxpY6VdArnbWmlEZu4PKd6xf3JkTy6I8S2k76u2u3 rlzYlxIufdPMX/6dy6oQZIml7PL/Qd0q2Ud3b154VTKfVe+t3GyVrLLe2FqnYhokz0K3NLOnJCdk gZIQD0ENCwvn3EeT0cxfSU5wR0u+DIDJMOMnkMEcHilL2DfWRYT4J3QNDl45e/Ve49qZPHMb7TJD igX6fhqjFiYNxKDoyj5zGqtIW/uBvo6DRV9IufxhWvBDZLcoPGlVuqCjKuoNp45ISiz8jwqgH/Es cly7ISAzz7R7Cw88/bDt/u1rR9fN5hk0SVpfz2HCi4b+XwGiaeDP93y1ld8NE+ZWrQvLDnHWUbub TG31KkatscC97/B2UH5i3X0OMJuFuSgm8YHqRJ350olTpcXH+IonZOXmTRVpHFIvDvQQkB9suPS2 KmXTlsj4+KrqVF47hSw92VzWzIHLo1vfS8afoZFWarcFfM34l1bHDJjYH+nS/BxtHhe9/f0bAqSB gwU5QCiNnJJJNMtz+iNUSSPbxjiwaWqprD7JM0+LhkW5Gbf87H/x+UurQHRFclRCe0T4/2Z9wYku Hvrppcb52qAXdZ8aWw0VtEdzIJAPrrVfb+CNerI0XR+f88s2YPIl72ww4yZRS4jl4i4WuVC+aGth sia+OFnSZmdTYVth03zIUSI1BSGju0hQUAwckdS+Cd74npH3iZGj1rCJ1BoUvj1SE62JkMI0FwvP 5l99B1YqkSMVisILogujNGHOeqrwo4JLOy6GWy8kPDcrnpLqg7j97TWn9553NlB7YquTapL7UaYS BIqpeMGuRjQR4gEF8oJKcAcdiSZTbyKvmeAlKUZJTdKjhaiChFnUt+D7LfIlmVxkGBafm/FysYwQ y6z8JlErkd+2DXnLi6IkGkXndlzcfmY5rFaiKRQEj+763TrSPzN9ayyXnVdRlSMUIxuytPao9jAH VNcFcL8uMNlQADIJUNJJCwUsyEa1SEYzRTXirn3gU0MhYzXN1wZW2I8btgP5eEu1vT3Iq+wdDPYM pDmJtey/BBgAoaFr+Q1lbmRzdHJlYW0NZW5kb2JqDTQ3IDAgb2JqDTw8IA0vVHlwZSAvRm9udERl c2NyaXB0b3IgDS9Bc2NlbnQgNzUwIA0vQ2FwSGVpZ2h0IDY5OCANL0Rlc2NlbnQgLTIxMCANL0Zs YWdzIDI2MjE3NiANL0ZvbnRCQm94IFsgLTE2NiAtMjUwIDEwMDAgOTM1IF0gDS9Gb250TmFtZSAv SEJLRUdHK0ZydXRpZ2VyLUJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTQwIA0vWEhlaWdo dCA1MTUgDS9TdGVtSCA5OCANL0NoYXJTZXQgKC9BL2YvdC9lL3Ivc3BhY2UvbS9hL24veS9zL28v aS9nL2MvaC93L2svY29tbWEvbC9kL3AvSS9QL3Yvc2l4L3BhcmVubGVmdFwNL3BhcmVucmlnaHQv cGVyaW9kL0ovUy91L0svRS9oeXBoZW4vUi9hbXBlcnNhbmQvRC9qL1UvYi94L3R3by96ZXJvL2Vp Z2h0XA0vcS9UL3F1b3RlcmlnaHQvQy9PL00vTi9XL0cvSC9mb3VyL0Ivc2xhc2gvb25lL0wvY29s b24vZml2ZS9GL3RocmVlL1opDS9Gb250RmlsZTMgNjAgMCBSIA0+PiANZW5kb2JqDTQ4IDAgb2Jq DTw8IA0vVHlwZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDMyIC9zcGFjZSA1NCAvc2l4IDY4 IC9EIC9FIDczIC9JIDgwIC9QIDgzIC9TIC9UIDk3IC9hIDk5IC9jIC9kIC9lIA0vZiAxMDQgL2gg L2kgMTA4IC9sIC9tIC9uIC9vIC9wIDExNCAvciAvcyAvdCAvdSAvdiAvdyAveCAveSAxMzMgDS9l bmRhc2ggXSANPj4gDWVuZG9iag00OSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDMwMSA+PiANc3RyZWFtDQpIiVRRTW+EIBC98yvmuE0P+L27CfFi08RDP1K3vbM4WpOKBPXg v+8AxqYHmMdj5j2Y4VX9VOthAf5uJ9XgAt2gW4vztFqFcMd+0BAn0A5q2U9+V6M0wKm42eYFx1p3 EwjB+Addzovd4PScPkYPwN9si3bQPZxu8ecXEc1qzA+OqBeIoCyhxY7x6kWaVzkicFf2x902g5D4 c7wbTy3ORiq0UvcIIolKEJe8BNTt/ztWhIp7p76lZSEziigwkRYeU2Aiu3pMgYk85OQup4g9psC8 AQnEacnIZ1c89IOdyDJKyvKgljm1lHCeBcnUSTqiCN6FJy6OCA8gTIQifA6vKCoizokjQgbhYB8M 3Y/dGI7mqdVa6quflW+fa9yg8RinmYzrk1vsV4ABAPcekXsNZW5kc3RyZWFtDWVuZG9iag01MCAw IG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xh c3RDaGFyIDEzMyANL1dpZHRocyBbIDIxOCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTgx IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCANNTAwIDUwMCA1MDAgNjY3 IDQ5MyA1MDAgNTAwIDUwMCAyNzAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTMxIA01MDAgNTAw IDUwMyA1MTAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg DTU1MiA1MDAgNDI1IDU4NiA1MTQgMzU0IDUwMCA1NzYgMjk4IDUwMCA1MDAgMjcxIDg5OCA2MDMg NTUzIDU5MSANNTAwIDM4NyA0MTcgMzc1IDYyOCA1MDYgNzk2IDUyOCA1MDIgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIA01MDAgNTAwIDUwMCA1MDAgNTAwIF0gDS9FbmNvZGluZyA0OCAwIFIg DS9CYXNlRm9udCAvSEJLRUZFK1RoZU1peEJvbGQtUGxhaW4gDS9Gb250RGVzY3JpcHRvciA1MSAw IFIgDS9Ub1VuaWNvZGUgNDkgMCBSIA0+PiANZW5kb2JqDTUxIDAgb2JqDTw8IA0vVHlwZSAvRm9u dERlc2NyaXB0b3IgDS9Bc2NlbnQgNzMyIA0vQ2FwSGVpZ2h0IDY4NSANL0Rlc2NlbnQgLTIzNSAN L0ZsYWdzIDI2MjE1MCANL0ZvbnRCQm94IFsgLTQyIC00NDkgMTc1NyAxMTc1IF0gDS9Gb250TmFt ZSAvSEJLRUZFK1RoZU1peEJvbGQtUGxhaW4gDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTI3IA0v WEhlaWdodCA1MDggDS9TdGVtSCAxMDcgDS9DaGFyU2V0ICgvVC9vL3cvYS9yL2Qvcy9zcGFjZS90 L2gvZS9mL3UvbC9EL3AveS9tL24vSS9QL3Yvc2l4L2VuZGFzaC9FL3gvaS9jL1MpDS9Gb250Rmls ZTMgNDYgMCBSIA0+PiANZW5kb2JqDTUyIDAgb2JqDTQyMyANZW5kb2JqDTUzIDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTIgMCBSID4+IA1zdHJlYW0NCkiJbJRLruUgDERX kD2wAgT+YLOeSK03eL3/aZcN4eZKPcuJy6ZsnFzO1ZkKc6Vp5fcK7hrMZAVkeB2ki1ySjMqd2rHY Mzp7akXoRcqytJsHScnMPHV4ktGh1CrJw78v7rCWPMT+x6y0Wb/ZfH7pJ7/4JxU9Xnij8ncJDrvU 3lI+uryIZw7hcLfVdmRSnbPsqvmcXQnGdELrgO6f5937gkFZLVO2j7fJ++16iizX0vRhUFfPSuu8 TYz7zGM2twxK+HLtH88B2V2L7nZQKj1Z/qJd87C1nFPr4+XmY/W+/lyiqaKBtegwLxijHxYMiQoZ pmAPzDpH5C6Eo9YQQ8Wxlk6LjNrcN0A4qvp4YobY3l0J0jVmkhFSw+g4ihLHVxDqlneFPYk6rAHa 1iE8HrrDuOk8UbSBfededRxo2DNb0mDy6uYRVckmfSJRMRp7KM2L84nCD5pAZsNahFvNOiTLvGKq kJLwMt8pCzez8CuRugf7Nfa4CI3LHGGS+sRFbEZxxa0qJmIzbeCL0l6Z+aH7UnSGa90sEz4yMzZu U9TF/+X+J8AArrPYvQ1lbmRzdHJlYW0NZW5kb2JqDTU0IDAgb2JqDTQzNSANZW5kb2JqDTU1IDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTQgMCBSID4+IA1zdHJlYW0NCkiJ ZJPLsSMxCEUj6BwUASXET8TTVVNv4cl/O4Basj1v52PxucDtix2EtRHC7NSkAyM3GiBdmiAQ0ab7 kvwxzytB98pUHYc6DPSI/bmEYbjVP5Pa38ORrV7xErUIWCk7Memm+0pVYyNPIJZs5HMc6oBoGbp4 GMx89UjxNjRIsyw6bYoBoqnheV2CRhRQa99y7+vPpQxImJV7xxjg4dDRTdrrg120KYEPrfFwJtU6 Ft2XDsDp5zUWOyozEx/o0EeFLn7aRpuYdPIvThnTvniat6COczcSB5S3CpmAdlSIAVklcuRv2jIe Pm1FYQz5xVGLhZMFHN/mkCqaJJaEj63iRve1mWCIr1xb9yaKXAWleqW8UuhY1iDeuqg267ZmQCwV aV+DQdWnjxWa9RN7bipYy84eE8QumK08ZpqLSt88dOdSJ26Mi6Cu0ZiS0uJZlWjdi62aanAeWvlk hurPqgzi77ISVsu8GXt8IG7vnJGF75t/WfGV5vRw7bK2pjfD/pG4MICXg/LL2DRj7NK7OP1Sh1Ot r+wXr4W/Tvz/HArD76+tJNjYP3jHW4+HcfifAAMAx63aTw1lbmRzdHJlYW0NZW5kb2JqDTU2IDAg b2JqDTQzNSANZW5kb2JqDTU3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg NTYgMCBSID4+IA1zdHJlYW0NCkiJZJNBjuwwCERPkDv4BMgGA+Y8LX3NInP/7RS4nenRX0UvBAoK cnknn9xk0NLZ7suCxPU/Zjx0fPAii2ggRTZoLm6o1dkPvS4wq39EVVaSirS3btLS/W2xU5eADliA RiGeMouLliWIyRte17/Llaai5U6BN9+XCxTi8F0cOZGhFCDQuDD1NZtPUhuHXllqsDxRFF6Z6O2v xuv6utxhRL5Q+PJ9kIkHRjVSGCEQ7iNFDC/fBBEmm/pEB1ooRV0HOo1e7RTCk2XRkOY93nOjpsd4 TEB7afQOGU2urJ7lncYcSRxVEo5a+e4w8U4Wn7Wj0BzTMT9IrIbu4YeQO9HkE9wug5ZKUYoGzqIa gh3dD9/Fs/zrndvjHS9pf4zMfa5BezKXNDZoOB/2RWOtHCfkl4LCS3VzHm9AJbCMtHmuaCiqMg+9 UiQmP1HGTDvKmuRWmQIz8C2jNzsXdCdztozDkKoc2FaKDisdO4DUTmYPg3jUKQ73h7Bt2Z8mYpiB c81ErU2oPt2/aXffH87u64+U6t167cz3nHsW3mdQvUsuCmeA3xh1fMgx99P4XMSPAAMAhh7KoQ1l bmRzdHJlYW0NZW5kb2JqDTU4IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2Ug DS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTU5IDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggNDUyOCAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJ ZFQNUBRXEp5hd2YBYYEdZkt3dWcOBEVX9CKyiEgFUJSEH4OHGH8B+XENAi4riHriKYlaHqLEBKPm CtH4b9So8VTUQ9FBDGYqegQVS1ATDUETQOlZe6/q3mKuKpWrqfd63uvu977++nXTlNqNomlaPz02 4d2klNHxtuV2a16ObUyiNW+x3aURFCOt6NXKUC89mnHL69WvAxko94Gv/aShvFpHudH0J3vjCovK bC4PceSiEPHPEyMizGSeOG5gDhNjsguzcsSZZcX2nKXFYkLBokJbUaEt056THSqKMfn5YqrLt1hM zSnOsZWQ3f/BEK3FYqZot2Vm5yzNtH0gFuaKidaCQntZUc6Y6TnEMWaamFmQPbaQWBL/4uVZxdZs a6bNmlMc+odQKJp8lJqi3N0oby01jKIEigrwocZ7UNEUFTuEstJUIUWV0tR6ijpGUc0UdY+iOihq FiGIUlEMZaO2Uo2UQvvQgfR4+l36M/qym9rN6lbr9lKVpVqj9lSXqXerm9S9zAhmE3OPHcJGswvY evYx268ZpUnXLNUc0LS7T3Avcr/mIXpEedg9dno88TR6xnvme27w3DfIf1DhoAteQ7ysXke8Q7wz vNd5X/Lu0aq1S7VHta98Zvl87dPrO833I98m31/9Iv2K/E75tel8dbN1+bp9up85H24IF8CN4t4S taIWChvA3KA71heorHZm9UPNz5zcr29iD0MhA3o2HwuZN4u+htEsl1gLZqaX/Ll2kge0qP/9gk3r Z7mO5WhmUJXWx8LcBp4YuLzIYVpRsUPB5lLdbTBwGVztbcXOe1GNbBsUMG8TrWNjKX2mWQUfo8jH ghgNwRBugPA2CL4DoimTDcNhFgzEKANGPcTARzjM9MYHYppVdY6N/B0U2zAYww0YHo3BsSiazrCP YNhDCIQoA0RZIDAMXD5ogAK6AQJUDWjgm9l75HoLq02Hcpk+DVWq01DOQ5WMVQTS5of083bVc70X 1f4wkqy3lzhyS+l8eKbKL+dlFvY6cpl4VlshKU8kul6GO7IKDjuG8BC0E6ejO7qvJiIIg1bDdHAH 951EBAmSGpMzMA0tGHwIc2EuzD0EuSRYSwakYbKgrS1RPi+FQXcJU7Bf5trAR2nmTy5guIPAvGD+ Q8mO5CSNdrOkPJDoix2woVV1Ua9YJHzEgg5MzA8vesC7zwC6txqRSZ223DbbVJPIHLly8fNmo9yQ HhNuCbSEChiGUxkCHI5IsE2ilRCCfBR08DfZVnAvR68/mbMs7ydX708V1icwJVevVkhGEEH9b+Ce pd8OrRIqNR21UlOHAXzFetS8l7JmxWzTtneYuvrLn10xtnYsnox6DPibWShjSTwwQVLMMl3XDHXk GgWW8VjHQq1iZipZ7HQu5qETJ8gwoVcariwbz+Itp3UAmyxBjkQ/l2GbrFIWOJJ5dLAV2MfsvHS6 +roRPBvfRwrpMXPGzZlZs3ehMEVTdv5yxUUjhLy8C6Hgb/kejWkFFevtwlawM3DGlSholyBDWrVL d0WGWzLXDUcqeAjs+AmGQgz6/XPsO4lFM/KETSwEXIXRkLDRdOrcujUHBc5/WwvDmbfn5lbnGHFt FEZjnsB1Y8RXOAmSTJ8qg/nuS8lBY/4yJWj4vEedT683/+JKpEMn0deUaBWY9N+zUOfQMZIzOgVe a1xIlBL4RNKdk+fJcEyeL3O93Mhvla/4sbdm3baauOpxS6YuFA3oD97vgQrU4FUPw8BtyinzMRM3 vOV4W2OnAdgR9UibuJHh6DcfPQSuWvFABz86Mm/ipIgLd7sfHGg/arq55EX+eAOXj43Qx9/59vid b1oXx8RFL0jMN6UesJy6byBYFp4lpBBqdPUDrNTDIUcaj4HhY3AoxoDfgqffNO+/flwg2QqYiaMx YYtp0fztOwoEbvqHCQz393UnTlScNMLaexANhJZ6iMiGSZhkWusczI+a3dTz05XvenrPh00YOyNx hOCqKuh6qHvezmXANKWa9IBISzvL1UY6o/nfCg0+2FECLSWwspQ+p1SplIvKp7yzClcySRrFJVo0 zlhIV8hgfm97ntieX88rVbCSuaFxukSCRonDdCcZxPJL8hRTJIVvoXc4eNUO/S3y2FMYeMm2Ygpz m8VDjmRmMgtJznQer7JgVniG1Bl8IcEmSXdfhkp5rsy9vK8HgYUg8D0P5qcp18bvIsXArejcffpf TwxgEE8ia8JIVnbSfBPLvezpX4O+qAqwhQpxbKXSynex3Irrz/4ajKpRK2KFaBLsl+WS8kJa9oWu UeZkbpzS4nib5+R/5EVUZxkxn6QgBBdjPgzGICg6e7e67qSwQWKKF039cL4RE0eCH0yBmB7wh4T6 5gr7WYEcSJpDq0TflxV/Um8hDh3/KwvjgJuCVlyC/CScI6Sy8Sk8aFlYBZO7YRtkjIThuEXAGIJH Q2LeI0GlRHfKqk499Et4EvZAjYQ1UEnYwC5We51Q+WDApk1WtelleABVElYR/S4JO8ghP5RLUCfB PmnJUd1NWYkjtaY03eFLl8R9lPEH2E03K5Y2kBL7+CbDde+dF7Z91v+F3SbXHP5OgF9wVQqEa95k klx/o5R+LMMrWfV4AMErfECaYzzewFdwg/RltJASTC79DSLRkDZfLs294DCR1pogcydgC2kq8c7d bLwtObq0qGp7mYmbkazhtq6vPbhhjxHcL3T0Ez5L3hzTJau6yD09LPyIPUwX61QpDPz4X76rNSiK KwszMn1bCA5m2kGdWafREBglGlGDoBXF9wtFUEwUxIhA1CUr7iqDr+CiooiAgg+WiFr4WhGQKNkY wdVRBO1IHAlGRJToGkXdoKyVOj2cYWtPzwTXzY+tgpq63ff0PY/vnO+7cI8LoJGFdRzUTeY1NZm1 Nq2Zcu9KOGmvxRKblo6Vd2S2hCbb3KzaB1b5tpXgQv64ZTEo6HTjahjk2ty4rE438tHEhHLcbe/A PLmD81bQoVjKbc+JDhqt8ltWIZpiYUKi3JbFQ7u9jWtVAhP22zsyeAQyGuHMPkFKZbHKSVZXC7Tr cHnWK/SDhQZY+Ar8YHmWCOFZJgjBBAMmmDAEw+lJLVh0EHQLB6MJTePoJwiDxsFgMIHpFv0EUSp4 SvylWvirgg3IVuBhhUvPGbz98w3wgj6BddhbxBBmJXCp2T/Ozx+O2oGp74hRDhpwAoYqlkmwDCBY 1rNnzZuRDRqSOEoczybb++qojNWs7sS2gDPiS9zI3Wb4FhStPpd6Yk5u3yz+wV5r7U966DXqIvY0 4lQFq45AVxVpr1iJtIXG2kLduvKLG24YwAV6XIb+InyCDTvAW/9T04nvz1WlrS2mcblX4oTGwqi5 O5cZ0HPgJFSLOAMa1mI/vWniog+mRxUcjTU6QlXmNySSs4lULi3E1tpXh0Gss2UJRKpmq6wmampx oGgBQxYajD2wR+g9YEZ5AT3iMRb857e3g/95UL6ZnEllN6t2yc9d5XaymsJwQ6cbrqbyj2eQ3zmL u0VguZx5Rz6t8P/ujmFCecdo2jiN4YROFy6D4USbCxfEcIpzFUKriQyiyfI+Ey7CVFoTrCbR23vs NXJz5aeuuV5NDFZCPSzDeq6FYa7sCqnQwo1huADL8GMo40Yx+BxbuNdmcJhCP0wVrmKwT/YllYYr 8Ckug6fcaHpi9+Ucw0KZNYfkSNdDXnJkrd2dwb/lH4joQsIAeLuL/QeONJd3pa2iUmWVXK2k7iCw 0mSraKvEQPb6FfiS9IsnGYeBUW2dFaYoCHSU17L4K/i9BQIs2jNW2CMJVcJ6ubvXNZZelllcoYfV PPSdV43amGnrUuKMs/gT587vu2j4sXjRCHFlKo99cPomHCsKJQuLBsK7Un3J1ePGLLYFfHRzt6EO TeFRR74jbvXaCypjIdMop8ljLJBi1jZIcImYUJja4CUxoao5i59eemFFA6mgmyTl/OH9MFDjIL/5 4/+YJmZAUyiTVfZNOlMiMvRAdRx4tLaeAg/gwaMYmcmoqUm10JfNB7UVziE/Qt5OQ37XmkV/mWVA f1/shgE44C6+DUGVZ7IL/iZuqeE2xCekLTEgP+mfdGJP6yPwLK3YuL5UfNNNIuxLlBTZbEvThWJT BjuSNr/Bz4CDwlCN76P/TewO3g0Xjl8vJfYWJo6SeKHEroI8XVsxMPJPfRo9hgyJU3xGj0RgbUZH 0uEjC0yyqCqsUEL4Dr6rS/lsagrRTbfwh+AiQvtJBv1mQ3f0Qd0H6IpDcbCEDD48V72n8GsjfgvH dS3Vra1PTw0fZtR8RII22gILLH/eowWNJLSCxkuSo4G3IP81u5rW+qDwwNbN+UahT84lTliam5qU bTZg763o4i0m+ET+i9dgoiXpGARa5GFfLbb8GnIZuP83Cv5UAHoOiSU1yLyXvHxhFLSyEmMoE8rC M/ir0Yt2T3mdEu4CDoCR1y8fvaWkBH02oDsGzp3zxcE4ozAxPZQT0jcdvZrynQEmfEtpH+DQ40uV XKuaJDgiuTZ5SXCUPTr9C6hf7R873IjVElzhQZvwGPuFRCyek2R0wMFBPnKuGYa2aJuk3mQl55I/ QyVIIpUTOlJSdlBgthFdW1bgp7qMPYXbjhmeFF27J8pNofZ6fl56zIzUtdnZaUZhKIzpcO+ydQzi K8mQbIZ8xTOHWwUMdmIB95DhSSgnKk6mjsYUjOfkyFDeyYZpXZttaeSjPFcJTkkqxZah/PX6nVBl 2+4Fr/i28O99RodFha0yZrBH68YdiDGg6rMZS81ixg5OaH4wi8+JzVwSp7frJSjjSfMJN2qszcci JhjxifLkzTWveeOYI5JwVnG2jP146iXwD0tn+htRkqCJB3VUC2r7x0csTKYzhdmPu87QOHpHRQPg sdX1DBUWxQYSxsEQ3ED6QQRxPPTCYAwej71QNFq9wL3mGXSDbjXvUW3dZ79HzdVt9jNwN2owPJmA KI9RfHF2eHMDJugkOJ/FphVXLr/7m/5Gl7gxK9bRfUAw5bRyVL9oWYV5/9vmp5U26mrzNw9wArVZ 8JHNJHPJuDkogy9MjWtEl9806N3KkrpiMQvPS8yukuP/T3M6mymyjjIpWJU07iRMPTkG6hdf7M/Y mm+s47M3rsleb5j+ybyIVYrfs38O5XMSMpPn6DU5jjQSV1ZIMJ24snSfbs3Zqi1VhsaX5UpXj8ac 1Gf662cPXi87m7a+hIhyFzVk4/6YyF1JhpHB8b4imiDjAPbQh89bHrZgYf6BeHKIPjrMogIPGt8X KEwK510WuppDT7/IF/h3fkjOGFAXF+ftKjBuvcBtXrMu/U+Gj9d++Y0I96E77xxlS81dwJBXKpnC Mhb4qS/yI5Zde24EieYaj+rKkaD95cvqbw7RABemDr3Kb63IPHNaT4LLKs80q3bTNUtWrhPElCb7 TIUb+8szuckMxtlzHazajzZ2txKr5tp2CuW2fY6aYH/nXgPtHUvXG+dK77QMIsvbCquKtCZWFent bYf2pcZW5ckhrnleDQzegSTQYxJ3hzgaimAYbOYmMPTECOwBEcqFIhA3c5oaZ7M7HL1DZ9P3p9nz P4/hppnXxEQaVqXm5KSKWyK59EOHtxUZ6k/dvHmYxIt8n6OA/Owfctvp4EyL7GtRnZR7up70knta sJZBLfGyxa6OhEoea+1+nEZeBX+gIMGTfNKDRP//kZRwgPCC71OBrQgehiA2u995rNfYhDuAlX8e kgDf6R96Qs++R/+O/sH1O/p7tPACoL+3/QApCWD7rfA78TsQA5uqvyW/J7IKT/h+4nsiVilgyfS9 7SBj948O5u9tLD86Dv7pYMPhpg5ggikBGnKE7cb3PGDjQnjB7/rfeUgCWNw04fu800AVwCazwvfE 30DMGsD2XRJovfCB3yd+J2KVApZ8Pz7cF6q/9voaMByMf3wAqrp2H2jfgd/25lA2sEn3vfi73pnv MSAPyDe9ATGsm74zQ2lOIF0//aff9N8x079XTGf7vnLS58l/fkxkRxLk+L5i4tfJf/5N55Rb4D61 +T8P50GuU9w/Doj8EBUFCDAAQ3d9JQ1lbmRzdHJlYW0NZW5kb2JqDTYwIDAgb2JqDTw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNDAwOSAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0N CkiJZFUPVE3pFr9/Ouf298Y9juHe3HOUGg1GJaJYKCqplJI/oaIrN3F7txTPEIMlQ/HeEIOIpsjL vyTyJ6VcxhiKmpfHkMU8a73x3oy5b94+d/Zdb719k5llvXXWd751vm9/v++39/7tfeQyJ4VMLpfz 0eEzp0dFjYg0r843ZhnMo8JNOZmODUHSyaUBTpKX+0AMxdJfP/k1jIH1nnCof6uXpkEjU8jle49F mHLXmo1Zy/PF4Uv9xcAJ48ePpPeEgN53sDg107TEICatzcs3rMwTZ6xaajLnmswZ+YbMj0Vxak6O ONtxNk+cbcgzmAto9R0L0ZgnZoj55oxMw8oM8wrRtEyMNa4y5a/NNYyKNtDBqVFixqrM0SaypPN5 q5fkGTONGWajIe/j9z2RyemRqZQyD1fZYJlMJ5N5e8rGKGXjZbIwmSx8kCycwiBTyJSyQ7Irsp/l H8nD5Qvkq+Tb5PflvyimKCoVL5RhypNOoU5LnaoYDyadOcrcZazsHPZTtoy9yYJKo5qvKlb1OA9z 3uT8wkXpMtFlt8tl10jX464/uyW6HXN75r7Y/YD7dXe7R5BHpMdxj1fqUepS9WvPYM9dnl39BvWL 7neg3/P+fmq1pcg6rUBS7oP1/9TcAm0IaCEQ1GdBzaVyn0mRoOVX5qQVLdTFpFy4faOutrFS4Mad hEF8bnVmbZ226fyx8+fP5i9YkpSxfK3+UQT/14uWSz9ogRl2yd8f2ZShYQ3LWubpuWJULsyKD9Hi B6CMAH37w8prV/VcxuU4Bqaw2B/E1nsnnu56ORjV7PY5mxOMmc5qKRlKdxRqTsEyLp2rOCUl8+4y cGVfQSmDfqwan9qKC+V14K2EVFsx/yEOmYUajNPi5Fs49Ef00gPHjgWvBBgKk7UQZwHNcxii7zsG Ix3nBqPI/wu8vuoziQPNcDJBDduDQ271gc3CoeMITI0KKJUfA4PyGCp4ovF3Bw1fBw3IBoX8NBxU QhNk86DAg6hQqXeAKG8HUdk+kFiLIKJIttV7CmzLCuUV8JOyooi3slBsW8b4sGqxyCqVWQlEhCV0 Bmpe8cN2QtiL73fApDfWHTgpcMxODPMWfJxg8QWYD+Ng3FJYhOmYmIIJGIF+1WiEFYJarCiQzsAY ihocAZE7y7X/TTrJdwSA6w+M/QyItnjsp1KLO0AhbSDS9RAFnnSfVDKQaJ9TAQtO4A9eMFwLQ8be w8HTwteuiNWXoTNT09haZdG1ta2ciQNwEy6IiRXQhaCKQAGZNGIJDoCwLpXxn1zv2HxbB84w4gKE 9qS1B+0TSlQPqi2X/qEFfxxWMzYiesPqJP3n6MRUXm3ef0N3p2319Pj4nFHCTFTcZ1/ezZ0wLciU mDx3/+HUXp/A1wqt4EduHQQNRICWewLeUMJzr2EqtDIl2Mpiiw8PLehL6vV9aQ2S5mA4i1/YY5m3 FItpeFvlz2n7Q4fDG2zxvN2X3WJ3Y/bX1/+pQff4cU5g0GRjeHxqxRdGoRj7Mxsb73zaooPoV7/A BzADuUb/3IJtxeuEUvBn4GhvzmCPNeo+DAeF+UvNRRgAiyjmDZyrZLZN5blvD6Wmfj5PhwXxmImJ OL4Bx0IKBHX9CCOAj3iGgxLSV6dmC9tLGOuueoq7h+7yuaJ1ZwWMwXz+3vHYqLjc2JhI081vOqq+ ui/0SURDEsEB5EUCaFFN173kOiEE/stzL0OWpM2ZpEVvUCRQBvVvSNWPM26NbtDvVHHd3SfrOu9o wQWVTeiJ3MgE7K/nOsMbEzty9Fx3OQTxrU3Hm5prs+amZ6ZlrtenlsdV39JyL7fiM95S95drlfqb ayzZkdrEtOVJSfPrb+od+oYiEDWkcS69XXLjf5M5V2Hf5/S76C2Uv2AKfz2IlMA9tmSuW0qDYzym s1zPT1DPlLD4xn6DB1/2NgQzcIa9hTSNZrHaFs9gEKueS3qFxVaYAgrNE4JNJGA3uvbf8Ae4y3/D dnStDwiduC5GmMFKZqcWlpO+frA1NCJ8Q4Iwm0XRHsxDMcu1vYCgKpj2PObrkXtIj9yapwdabz7V wijUVQXqsZjuIaVIn4Fi1QnNZfDj2qXHwPF/zI4pStah/5j/kOR8vicmw65d2bKyWeAC9oIrw7Uf mRe/Z5GOasIPtbgZN0IgMlDQfGPvviZBbXGUmplqw8H7NvgpnwyEJJY6RuJDqIEaTHyI2QLSikhd 5RELLsAE40h6aHIRJrG9tQrzaEx5C0IAUhAVazUtltBcQhtfgsIeQN0lhCJtec+ULrXARjLbSIs7 yWwQ5cNRD8k0Fr7zFL6jinrNDbB52iZRTZXPmlkW+n8Ofdt98EiXILnjaeqEwzFGtTVv5TbDe4EJ ae0oMrcIvRl38Dhd2Ot27e9UatHS24REQqmF0w55VBTY4gv7OuXbPUefLAK11ENtOprWj+7kN9XV FJ/Tgc8VK1E4QSk1qObvCA8wFe7+8xq9etdbjN9c7i5hYRd2MzCTxesSA+fhOwbpL7MbmxloRlFF oXLkpefdGWk0hahS6nHcDaeoh3aCmrT6BLRSGYXmEqFqWZLtA1VJCSTYOxn6hASpkymxd4KWOOez GGqvYrbTJFUx9OmIgYNTF5WqBbTKLkKQDhOvI/bDDEymI1r7YTI/LB12UFODqk97csqH5EVCuQxW HrPBFf0hn3TuQX+sLMhCT4q9Cc3ojr6YrQe/geDZRj1RAKGNflieqElBDn3QJwU40Oh7m2c5pcJI yBRjiCFkMEg9/FX24W1TaGhs/nRhgaNG3HjaLbew8BG4WaijhKFwEUcKOJ3KgjAaCCOhDyPlHUYj 2/FoS0jwxE2RwiIHxjAHRsMl1lJeOPd/dFd7VFTHGS/Bey8PocrsxWRvvHeDRFeFQMBtPRWxAalI EeUloNSICg1gkYICNS5BVAzgA0LlxlOO4VGVQCgCRjyI1UNAjVaCxfKwNYi1kkTXnnZDv0uG09Nv dk00f/QPOGdm78x83ze/xzcfKGM0iwN/ns6Ak+amXW2pR146LDxQez67q4f1dFUJXSTTxbxNnVne qKB9iMQlyLsRYtTSmYKO1CTGVq2VMCu3GOqv0LfhSg99SR+5Mnt9XFzNyY1yIfXgdg+07B2W0MHd +sBXgUJ6JRHc9MOf1l7o7i4q6LSVQLvH3Gkbc9ZtCBAcIvanzyCQk+180B7nOwyz4PGTYagQ6drJ YPTGVZMjsFbWYjC3BQJ1TV1uMKSOgqusLWAgAnRnFKI8rcembMe+eYskQoInrObJZpil9aCwgcd0 DwfhPEQwKXuZJxV0Ds7gxf8Qf6eoTq72oScbLrDT3aYXrVqBY6unVoDAfMjDmIa15Ke3YcSfCfRv 01nM1iymcfD5KzhaPFrRe7YCa1FcyJ5HmrPYcr63rle6c2bHUuUNPnZ1SU6ikpiTtilYT8oWPoh7 eK2/ubdJPsyTkENvl6dXZDuRZOxo3u0obS1rdyprK2u/pL8pgE/En+jrMWF7chNk8tEgnRDvPDh2 Ve7jtx5I25Ul78jL/M0WaWPaiU4FhdPqN5HVCGNWyM1HR9DDHpTnTaQaNoMqDrZMjN9v8PnZypzF gQFZX96WyUoqUVUET554X0clPhHX/ml+rwQBfeCJF+kVDR40ICw5a0OaUoqerkdB2IFmO2bdXYOp GsgA8dcCtfdEMlCdtq0yXqKmQIo8oa/fowIs7+moUNuVA+DI7d2ZYk6VfDfd/urx5Zufnz25r6jh aaww1pxpixW3w1j1tlhXYqwDDV/dH2/xCw3J8g0IzHn0Z5lkQJEt1qliVMMLpTyp7t6aXB8u0YBo JJwXfaWPekLA9Z4PLnYohxmeLeA5AW4WB3YpBaBzhKVwTRyobLs0JA19GBtxVPkHDRZ3JMXmRkhL o7s+P6CAxkN4PMyhsXRJEIJ9IV3+ZCEED35y/FQ39p2nEL8mC8yzOoALKgm4MCkxgbOFOt/gO463 n2+sKdqvytWYcOWvUyvSpVeiQ72VUOPCJ4J7As2xgosVBut2TfhZv8t2CM5ZxeC08VsKcb/TOPZw tCU0UCZDpvSQH8uIXD+ReIWVCqT/Str6+lUSfe3nqCizqNyHHYfP0NW2zt9jpgH7qSM1poTX122R iyjPZd+4tu+yBNs/gRfBoBAPLVVgyqEtY3V2YJhIwehR4/VQwd+s/frx+KEfRcr0NI5HBXBaP07d w6Izk9LlUuhjV45L1XxsSHUeg6CfM8iSVnGe+H/Jegs96Gy4yLFOuT37ag/NEEtqTr1bJ4G+Fhxv K9pF1NlmYdlec+hBmfjfncoUny022I+oynfAtY7sBDiClP0pPcJBME+3Qxva5G7WgdAldAtXqq2x xzVV/GwFQwWqdx5LlFW4HzcJs//pXibd/bZN+f7qyQcj5as2yvQqGwvfH2P6wi/vUxIZnrVmu3wj K/FUqJQUlReZoiDakgfp7KeFZPs/rSMZeVpIcv7/lDJm57oUGdevu0WJwECP9HFg96+ixLXCeyI1 PqEuEAwrniCsjBBMnf9NfbHxcPamwTIYfieOfDx8/+8fvxFkyvbzfjX7i3syoik6DzZYMz6CsW9j YTwfGqBpIjNIb6hDNkfFdHWZkc2m59kclPhW0q9YPrrbVIffQJWf+LwmMI1Qvj0Axk4UfA+umo/t hKl0quOJVwhCM+py5obmFcj850ho6u063tuF0KRu2g/E51nMWK3YmTQPnKgT3r9LHkMMuWa79mie GP9Sjl2zg0xebGg4uF9ViBEk4ajZXF4oLYv7ycYDLPZw7J9dBSZGFnhkKTjBAvwCC8AMS6dVoGH9 NmXLsUjJa9EG6qjQKDAPzNcnxRem/+LN92tT5H30Ba6w+1LxHyVw+M8FmKlAFDUn3NV3nnu/tfvD feazjOw2dRq1eAD2GOQM/vcTX+2L+Fom6zqajladVsiZg5NcsXlnSa6U+M7ZTgX2g6sFu+H5AtVv 5rztrGebaMvyv0NLgdauqSLqFwPM6jyvRaaye9dlOI0zowJ1umwC91t9zRfPMksIDwNieyLarE3N 91C1RpINb3rCYh5iNJVjJKyls/DlhL6l01w56s0YUI4PEi5Pm2vrnKqnAL1wjSf4Mi98QZvLvHDG 9FwOAngIYJvgRVYYpmezPWZosznqz8+zj3g28rI5YRxdkQf/hCD2bND+gBtGsWdDGK3nYAEuxwdm HAg0joMlPA2BengNStlSYjDSoPkQZHs7GOwS4VCtNTlCIKuCkYek6TYuLiMtPqPgSOVuudjIFTc1 lzRLYGjCdxh/ToF4rYrZNWY5E2Nyf0edilJpggq5Kg+Nlf+qmv5GFeyTySoUqE44OVk1/V/V2eIC BtdDM92hSTe1WPyfAAMAvIwzGA1lbmRzdHJlYW0NZW5kb2JqDTYxIDAgb2JqDTw8IC9OIDMgL0Fs dGVybmF0ZSAvRGV2aWNlUkdCIC9MZW5ndGggMjU3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISq lTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6Wq tdUwCwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+J LdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKj MPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7 XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4 kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sA MPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo2 6rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68B r9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0 WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vB fnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEsqAAqgVSQ FjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6BU+AceAmsgmvg JrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEm kUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjY SfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDSSTKSgdRF2kLa R/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdU NlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/T v6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXm IxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K 7hj3DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJi jcV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsc tLlpC9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMx WBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuW u252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96 wV7BXmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8t EUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhL SEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJ SCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdNxHPi c+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPqmapPPZYG pyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3ZT3Nic/pybuW6 5xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8XRRU1FV0fYlgScOS c0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9 VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3 WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguNno1rGu81JTT9phlt ljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c 22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa 9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia 1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9 p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660 JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFn wePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfP uNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c 3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHt nO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p /br+S/7c/23//wIMAPeE8/sNZW5kc3RyZWFtDWVuZG9iag02MiAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDYwNSAvSGVpZ2h0IDg2MCAvQml0c1BlckNvbXBv bmVudCA4IA0vQ29sb3JTcGFjZSAzMiAwIFIgL0xlbmd0aCAxMDM2NDAgL0ZpbHRlciAvRENURGVj b2RlID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQABgQEBAUEBgUFBgkGBQYJCwgG BggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAY GhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8AA EQgDXAJdAwERAAIRAQMRAf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEB AQEAAAAAAAAAAQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEU MpGhBxWxQiPBUtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0 VtNVKBry4/PE1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo +Ck5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEF URNhIgZxgZEyobHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidk dFU38qOzwygp0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhY aHiImKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8AlN4kDKS4 4kCu+ZOO3tJJHLwLEA18P1ZkBIUmjPjWnfDahRckb4tsYkqsMpqP2T4Hp865VkxCXNyIZaGyLWjb AnwrmCOLEd/pbyRIeavExWvIVKkUI6b5mGAIcGWQg7o2J0qSeu34eGa/UaXqGQyWiAqlan7QrT78 ojMxHPe0E7rZbYEkkb0r75mRyyjY6NdxlRUSXGxFQeh8MPFGQuJ3bBY58nekhrxpSnQ75PxSNjzQ IBv0qUKmhbofbLDJjS9mkMfEHg23xHp4nKJwsd/3qSRy2KIQUo3iOuYHCRLuZmjs2JIRLE8kYdI2 DMjdKDY5lY5EggHhmRzcLU4rjfMB1zNdyl4bFYImiYpJ6Y4OaHrXrT6c0+M5c0blLi8i5WHT4sdS ISznczycLiR/Vj6JISwr3oTk8WCIPKiHPqMRYGxV7YxevGGX0iWoW7exzNhQPc1TvhPVdqtvN6kf NjJGD8Ljff3xzg7dyNPMUa2KnGZEULLRoiDQddzjxEAcXJkQCbHNuVEAHpEkgV8PoyuZHRYk9UOZ eThSPcZVxW2UpyKWbbcjpkTvyZgoi2TahHXM7BEONlkrGrGg2JNFI3qBmxjGnXTnaZWAHTYOQCPH wyGS2kEKlwgIWPf+YmnUjw32wxN7sOSBeLl8QHJjsQd++T4ujIDqu4gEGm6gb0/HMPxSSQ5XCCN2 mLcedN91r7Zkx4SKcOcTE25Jvj+FQAQAVPX76e+Qx6fgjV2k6izyWhG3kUBdvjr2I2HzyZ22KQb3 GykjcmDFgORI4t49dqYZjoyxTB3BQ11H6pWRlOx2HUdMsga2YZYiSAMRRQQwox6nuK1ocvBtw5RM dwuZUJIXYL9r2OENZ33CvbyKGowO/Qj+H35GQbIZL5r/AFSo48WNKA+1eg2+eNItdJL6U3NdwRup 7+3bBVpJQmoiN15RCiuKmn7NK1FPpwxUHZA2hKSqGNAew706k5IpviCaRFaqB70WnywW0yxqnBNy 27NsSPAHG2JFLwENVbdSTuOtcWsudWBVidugOFFLJDG7enIpNO2FiAk2rMkSenc1ezYr+88ANwDl kPLmzj5c0Dqhsb20iEBUTRKFM2/xcf5h2/rkoWC2RNFJUVQeJHx9cubEQsnHY716f7WRpjSpGeJD D4h1p4YqiqpKhYUpSjfPIsVMBKUXpXahr1wqqMIGPGhCgdz38RsNsCCoyWZYlVYepxLAg1FP9rJi TTIrYoZ1i9VqPDWjH54SAiOboVG+0mSVBNAVetAVB339slDJWxROIO4S+O3lRiCQGX3y0lrEwmFv bTPxZqBj0Pc/RlUi2CbI9P0+T0q1UMexalR7VzGMm7mmsFmyEM0iBeinYn5bZjzyC66ufhhLnSIS 1h2KzIGJq2xG+USkb8nMjVbDde0cNSDMDSlNj3yVMDkPKlpEKMSJq+zKR+quS4SWqWYRLuKkf3iM OxB267dhvhqmrxRLYqE6OpowBBG5BqKZIFqOx8ig7gGKRQEND8W3SuWDcNMjR2WlEk+MbNTfDdKQ Jcl0SgECSo71GJPcmEQPqRgUMBXfsGzFnOUTsLdnjxxkLaEAO4PFiae/+e2VQ1Fj1c286ejsuMRI 2IB8eowwlTOUbQ8wPMFjudhXvTL4kVs4074ha1Aldjx+KppvvQZXlyiPPq5GDEDuC1U+px7/AM9f 8981XEfG4uIcHd5/rdjXprqmmoKsispNCenyObPGKdcSkEkDRkg9D0PtmSCoksdiDtsMWYCxuJAJ FDizBa4qTXoB3GKVW3adGYHdK7AeGRMQVOSqpNbeWJwVOxI6DxrmPLGY/Sjj4+ap6fGm23Y+G+SE rYSjS9pnQheo8euDwolHiEKqTllND12Hy75hZMBibB/Hc22JCl4BdRUgNWop4U7++Y2TF6QeR/HJ YzMZUeTfoctxXfpT2yyJnw2dx3MvEF00QVWhqMycWQS5ftYyu2ivBTSpUdR7YDI3fNkAG4pZFGw2 PQH8MtMokAloMTZAKpxMqEft1ooHvtTMWNCVhsJNUVQ8PTeq+nK1FmPg47198xTh8KZH8M+X6mGG ZO3837kCjtzPrKGiNeL9xv8AtUyUTvvyc0jbbmii3pfA6iWNvtN1I/z7ZeTXmGmuLcbFDymRYj6L +pEw+IMPi+j78onYGx2bY0TuKKHiJY8WJAr0PvlQ822XkrNHQM1ajwHfGQYAoalV5EbmtMqG27a3 EjFum2W4YGXJhOQCMiQhegqNya0zZYoABwcs1wgoS2+29DsDTwzIEnFlRRdsopWhCbCtR198JaSG 45CKmqlf2vAgnx7UyJFpqlK5IR6JUIa7fPNXlzS4+Zc/DAcK3nuKinjk4T5JMVZQrAEd+3bpmTjn YsOPkHQoOeGSjOq1I3DdRWvgfY5mRk4c4OAliQCQ1I+0RvUnbfCQCxEjFRkii48gAoAoCvStRUb4 bLIcPMIMyTl6MORBqB0PyrlhiKaY5ZGVFcWbk1eibgUqf8/fAAyySIBpTEZ6g+ANetTk7aREncr1 UBhUbd/bFBAbMrIePhTr1wGKYzI2KyWX1GYmtevSg29hiGRFIK5ZqHsD1B8K5MNdrIJAVkTiDyAA 5divcHxwGKRKijYyxUUFCpoTXata4CzBtESFmRSAQKfaHQscAYkNxluh2PhhajFd6lBQ7HwxYmKs yIwFTyAoOQ2piCwkOFJddif6jJRRKiqQ3X4T7jwyyB3WB3YghMTHYlR1Xw/szJO7kndFFUkAIAPc U6inh45BhbXpAxqVJJpU9N+22StNtpzVulR3GKlWRDu6Hr+z2pgYqhVeoHFv2gO9fDFDS0b4eg7Y pVREAWIWq02GC2NIe9twqGQH4aDx65OEmnJGt0oS7lR6oxBr2PXL5QBa8c1dW9VuQJWTetDsf7cr 5NhiCmenwrJxDffXemVTLYAKTy3jjjX2XoCe/tlMi2Y42j0YEbbUpUdcxJY97LtoZNtlUEGldiK0 pkBGjbbKViurbgjtuOg75ZE20zsOapoW2U9DTplgcLIByPJSoydTsemSu2g45RO3JuSSq8T8VOny yPC3RyWN96U5fVbjxqDvQE4QaYShfILYhIrdaOeu38ckSiEKPmiKBkCP0KkEEfxGY0snCT5buwGI SAG+7du3BKKA6A9KbiuRGTxYiQFWmGLwiRdhUkRHoBsR4dxmBlhxSq9w58Ds10FO/v4YYZDHZNIO 6cMChWldvoyrNrTA1H07tkcEZDcWtjUKAANvHvmfxCUbIsj7/JqhAxNDl+Oaz4/UrTvWnbNVxz8S uE3z8ve523Dz2V5btWIWtT77dc34DqKpyenOSh2P7PffHkgmkFLAyksu4yVtkZIanYimSbLcAR0O 3XfFJKtAxD79dtsBYSRbcS4YbHv9GBp6Ii3uCDSTcDvlcodzOOSuaLKqylk3rv4fLKuKubZV8lJV aIA9PfJECTDeKrG4K0Y/FXeuY2TFImxuG+OQDmrCR+S9eFftDsMxhCMt4kgjoyIVT8QAJqN6ZCeK Z3HP7WMSBspyRN1Q79CD3y/FqBVSRKJ5h0ZhlXhukqdK9R40yyMOEkjeJa8gJ8i1bW2ozPI1snJo /iahoaDetMnlGLGASatxBq53wyFqrmYzLBLAAXHGVmNCpO6kb7itMxs0I5MRIPL1DuNNvGRISHIc 0ErcKtTlHQBl7E5jwO1jk7Ui9uqMWeKSFhGOI/aXuB88yhISGzjmJjLdDu5ErGOoIFT27dsxpyIk abgNt1KGr0L7Md69zlEPNnLbkvuKqoUGqmpI7gjJ5Bsxhuh1G1KdRlVdGwlVgBBOZGC4tOSiiVLU LH7JGbGBBGzg5NiuClitKjkfgPsNstHLdxpc9kU0QC8ASKU2BpQ165VHMDKmRhtbhGpJJrQijD5Y znQTEbqEql2EbECmw/szV54SyT3c2FRFhekYQdCSPh+ftmXp8ZAotGXJ1WKwZgUoNqgE9aHL/BEQ 1DLxHmrckPJTQgrurdKjtghNGTGeahcRURWi6ruOm/35lRLiSQU/rSTEoCyjcqQOo6jbLI1TTMm9 kLI8xNCCCx6fP+3LBENRySBWPFJGpUkgvuQdmof64ggs9wKRPGIqla1C/RU75X1cjmHEICaHcDfJ NBChcDqTQnwHtkgx96hTiwZqim/Hp74SGUZqNwY5E+L4ST1+ZxFhmYgqEERRi1KAj4qfryRLVwEI 1GPpqVJ5VrxP3/fkWQVEdgCpJof2e2/fbBSqqvU8uvLviwkFbiCAfHp74tRC6jcq9/2R4j3xYmXR Cao0vp+qleMQbnEOh28O+SixixeWyWVvVtgaGtIyKV8aZcJd7eJd6F9PgS0TbAbp7nrTJ2ytVhi9 ReSL8W3JN8SxOy74aEcSrgmlcVBVLeNqdK+IxKkqko5U8B94wKG0i9VQGIBHSvfG0FVQFF9Nq7Gh B8MCFOS7s6FHNFkFCrDb7xkhE82HEDskF1Z+hMOLco23Vh3y8TsNfh0UbZ2RkUkZTKbcAm9rbPGE 70+zSnfscrJSnFtGnCrMGBqKd6+GY2SdGnO0+O42remQTxNN9qZHjb/CPTZUBqO/v/TBTIy6LuRJ 8a9Kdh74gNcpdHI9Nie1ATk6cazZBWSUK9fk3hhCCQRSg4YNsPhPXJ82jhMTurLMNyDWm5+nKiHN hIdF6FCK9TWhynLMx3cnHCMlRl49jv3HXbfMbNLcSq+/v2cjFHmL9zkcBa9z+zTKo5IxHGLA/m9z Zwk7Hn3tLIvKvGlew6ZHHlhKVkUT1ZmJA2c4FaCpr27YziQaUKMi7bip7HbKM1RjxH4FnDnSjuNx sep9xmPk1JhEEfVzvv8Ae3RjZ35KHpr/ADfB04/jWuZ/8oy8Pi4R4ji/k9+G/R3ftQ1agV6983Lj br0ZkNQSCO4xpFqglI67kYKSFjhX9+/0fPFmFFgV/gfbCzCpEW5AD6dtzgYFXdSkfwKfUO3XAHA4 Zg7b/H7ETFVlCkU/HAW8lWHONqpuT1yMgCN2UJUrpKsgHMdepGYhxGJuLmCdjdxiP2k+L2+XTLhP oWsx6jddHPQhZKgjvlGXTA7jmmGXoVdpgo5gg7dMljgaosZSCpAysgNaD3yjUY92UZbOuFiCcpW9 JQSFY9TQdQBU98jLURxDnbCJlMkAbhfptxJHMZIZFlDIY5AhozK224OVZM2HPHgJ4T0vv8mnNikD chRcRJEWfmWt0JUsp+NK7bg7rmHDDwHhyAgHr0LkwnDJyrjUkt544maMB42+zG3Ubda5sY4yBtyb TkiTvsVH0VUgxgxSUoa9CcBgAdti2Cd89wvgeKRnSUESqKE9sp4xIkHmiQIAI5KTfCzLyqQPbx9s oFgkW2DdTZqmrdabHxyR82QDnUKu3U1plfkoVIa098zsNVu4+Q9ysgYD4jQHf/P55l7dHDl5ouCN KckNR0P31xM+hauFzMVkKkbt+vvlUcERco9WXiHkXNLRDUgOTtTMOeUwG/NvjAHlyUKcn5A14Dc5 iwmZHjLdVClRzK/xAFiBsOlT+rNxhmCN3By465LJkqEVVo7HcnYAAAU+QOXg7k3s4vD3IaW7IJDE AgVUiu/Xr0w+CObZHUdCt+t8+h+Kv2G+W4HjkhGmBIluEMs0jSMkpAcfZI6gg07e2WkCtnFBN0VU 8Ts4Brvy2qN/bt1yKb72mt435S1ryHWu21MIK11UiDGPE8eh6EGhw1axm1U8FANKD4wfu+nCk10U 5mPGp2p2HQf50whieSHO7VpWnUeOTDAxIUHfiNhUHcd9xtXAQ2wyUKQ6TspIGwp126YaTaIjNSGG zeH44EoxI6xCooT0I32yNoId+8V+I3UbMD3+WFrKOiZZI/8AKrsf1ZFrk00TlCFYgnw6/wAckC1F CXnMfERsSOla/LJxUJXOjG4MsZAZt28G/t98mGQKFniilPqRj05RswIpU+/9ckGQNNem8bcgODGm 2EEFJVQkUy8X2elAwwUhYIWiNCMbTa0oDxYdMKqkcRDhq9R9GBFqjhClHPEinxdwewrgQk2qWc0b FzvG+6sN1qcyMcw0ZMdlBQq4XiDseqnocZFsjdJrpZYVWh3+1XoDXKJtoCfwRbn4a8dqU6D3zX58 kq9Lt8OGI5hXjjp8XRjvT2yfFYXw+EqscgJIJ+E7fwyuEJVvzbJZI/BuQsGqQaH9qmWwApxssiDu 3G3I8a71yRDUJg+9ew5D4dwOv9MI2aZepbyHEhuo+yenbBJnisGiosEbcUqf4ZIMJ0S0OAbf9rpi Vw1yKugp8J2H8cpyQ4hRc3FPhRLKxoQaAbD6cwsokJWDy+1zoUR72o0YCrfb6HK4R2s/V1bCfk00 aqSVAp0FcpliEdx/YkEnZomla7EdRlwy1tJjXchxJVWGzb0OYvjSGOW3HR5N3ALG9KchVXqyfDTY dMw9fE2BHbax+ptxcmqxcug/1/8AMZruHJV702oX06bHw+ed66S21QnYD33xV3on6O/0YLTbQjLE 0PyHTG1EgpSBh16YW0FbGzBq9DhYyRaklVNa+P0YGkq0fToPngYFFLKlFDAALQEiu++5yBCgqzRx NSRDsKkkHfKDZ2IcgSEdwpB2ikLVGw69BjkNDlYZjhPI0VW5mkaMGVRVh8FOoxwyiR6SwkCDuLQQ lL9V9MnbY1zJppql8VxLGdjt27j55GUAUiZCLmnkmto5SAvFyC1KihG+3zzS6zFwZBR6fpczSSsl bBM1WkKpJEg4KFptXeo/jkIm99iHKnHpuCqQySTqwE5Jbbg7E1qO2+GGCEgwlERN19jdvLPAKS7R 1oCd6du2ZGIyjz5IyRjLlzRE0g9IkD1EJ/DxyzKfTtu044+ruKD+ARyFTVTup7jxzW8Qo05e9hTU gKCwHJjUnIxIrcMiF1ELMx7dK5MyFo3W15P8Ww6YYizaDsEREpAJG5y+q5OPIqy8lAalTmThlYaM iokixA06H9ntXfuMvMOMUXFJo2G+aOPhqG6UPbIiPBt0TfFv1acF0qRuM1erxk0BvTmYpNW6A1rs Kbk/fjpASuaVBVNRxFKjb6Ae+Z4hRcWWTuXBlCkSdP2f8zhiTaJRj06oC+t15grRaim3375mY52H DywS+4iIFAacT8JHiPDLg4pkR8FIORMjuxBqPUYdxX4umGtqZ8dm7Vg1u7qxJAOzEdwemRFspRHN WkdVHMVpTvuKfTiAwulqSq0fUEDt3Aw0gtGJCrcgeW1DUUr3xRdhQIZG4gVPjSvYnCyEhLYrZVjk LSIQGPXwqO3tiGUttq2S+ZtiDs3iMsDURSmib08aUwo4kQkZoO3Gg+/I0z40fbzFSvMcgD8Q36dN shKLOE3TTJHKRTf8KexxiFmFVAAgKdv2cWlUiekhZia0NMBXhWTenKKKQAKgDJMIjoUqngELEICy nqMmJW2xxknkg/T5gkDp3GS46cr8qCNl6KpYRz7dlfuMN9zRkwSi3JbtGQOtRsRkhK2og8nNJyUq wrXxxYkU70AVqu9TUjFbXRJvxIpvSmAqo37BbXnTkAfiIG4rt+OShza5pWLyUgp/eRN+y29B2ywx TCRajt1LVXp1oevjkDJsATWCOLiFY8artSn45j5JSAsC2/DjjI1I1aNhLIKMSSvfsRXvlExxbVsX YY/SNzuEfEQ0YKU6bDMWYlDk5UZCY3WtE1DUbDp7jMqGQFwsuI72pxSMtUYEqo+kZdKIO7hQyyjs dwiFVGFVyN02GIIsc26mvQU7jDTSTRtbK/qMKilKUA/jXERpByWpojFCeXxdge3ywk0mETLdchHw BhQ9h+GRIbYHvVuKvTqW8fllEpyjyDmiEZ8+bfNqAU+E7V60OYGfJx8t4k17nPww4RvsVRQzUbkK rWo7VHhlXDdG9x8mwqRlFdqjfKBnF0E8Bpe3FhRj9By/IBOrYRsclIp6bUAHzwYpyxyraIWURMb7 qbxq7tTdvE9N8ry4hknLh39/JuhIxAtS4HnTalae2YX5X1Ve3Jt8TZRJIFT08c6107cTilewOAqQ qFgSCe527YKYGXeh5PiaqmpbwO4yYcHKbNhTd5AQT9lQa1w01jUyHJWht2ljaen7ulQw6HI+TsDn qO6IQBYwKAg9D4VwIu9w5Sdh2xSV5O+BQvil4kHp1rkZxsUyjsbV/UQ1oAykUKnrkeFkSG3uSCjk gpTiNqUI2pTKp4IllCctwFVo4Z46qRy2r45jHIcUuvC3xHEN+aDntXRyqAvQVNPDttmZjziQtqni HIK4ZktUVX4ufiCAVYLX4jT8M1uuyCeQCJ3hz+PRt0eIgknkowwSC3aaIFo60LLtU9aMuY8I+mx+ Pg7GUxxUeapbxpJT1D6bAlgy7fQcuhEHnswnIjlujkoq8ZWqG3r226ZlR25uJMWduilKWiI9A1DV +A9Pn7ZRluH09W2Hq+rooI6NIpA9N1qGQ9DmACDIdCG4g13hZu56fdmJkmWfJayyRvxkXj/nXf3w YsgJ5osHkuNSRQ7dTmYCb2YGkdCrEAjr4Zsse4cOZc8xVCQOXHrXam/XMmEHEyFfMj+kZF6gAUIA rtWuTjzaDNZbEE0qDQc6gbnfHIWyEUQHBY9eOagZLl5ObWyoqla0O2xIpttmRDH1DVKQWlewPU/C epp88zLB6OJASjzKgeLM1XBf+TcDb+OTGzAkS96DkuVkIRxRQR8XifcfTlohTVLJfNDyKnIkNUnY ilK1PXLBbjVG1IBTXY0AND9OSaiKLlTiKggqRt3r3xIbY5ehVFcFqcaCn2D06eORpt2PJYKAgqKC tPnhYS5Kgc0YAVG5qBWlfbEhiN1s55VK7grQkbb0r+rANmZHEPNBODVRyoGNT4CpAO2SplCfRCuK T0YERgFo5h3dDsCO1R3wgsjG9+jcLj9oVHftSmStoljTGFAQHG6gfEx7Ht9+BqVPSB2606UyLITa lhaTcj4lxGzYZAhpJGiPwggcQN99+/0YWIFoheMm42fbfIFmCQtT4jwk+E1+FulKYLpmI22sMZk9 KanM/ZHZx7HxyEjQsOXhAJoqFxpnFjJEa1O6n5d8rjqAdi58cJjyWpaRS0BHFx9pTkjkMWXhiTUl kUHE/HGNx/MPll0M1uBm0VbjkhlgUsQaEdBTxGWmTSIiQpbLBJEwZR3qBk4ytxMsKLjxeMhTRye+ 4FMWpDSN6S0lFYn2NRUUP8MISl400vchYW5RNuCN6e2TM9kCNJstla2y8WerqRyUjMfikeTkCMRz KmRAZmMdYgFoh8W+n2weoDfdIlDi29PcioWNArHkV6n2Fdx45jZiIxJHKnYYJEmjuUQquaMpooH2 fnlGPMJxEujkyxkHZERPXY0qMlEA+oIka2LpITvx2r3zJhPbdwM2LewpKGUkjYDtlxouCJGCuOLR hh3PXKzsXKFSjai8b/ERUkddslxNBwE8lyRhge3EdOh/tyE5EN2HCJXfNeUPHl3B3A/DITyEchbk xwgtqK7AkHr8vbKssTIgg7A/NvxEAEVuR8l6wipZgR1JHbbMXFgEZGYBB7nKnO48N7d7W4Uim67h vGuHNjiI8Ue9jinInhl8+9RZiDTuOmaaczGTnCIIXqxKkH7zmTincSDyaZCjs08cnpg9afteAyWb DLgFH4+TLHMWovVeVfhY9/EZTKZiTfpl97MD4hR5tWnL4/tV/hg/lLJ4XDw+rvT+Wjx8XTuUWDgU YffnUW6mnK24Hh0GLKl6sDQdx0r8qfxwNcwOqm0QFSpABNAOvTwGTBdbkxdQvIidQKfET8QPcYN3 GquaKhPBTEilozvxI3+jAL682UzxdVQhaj0xxr+ydxj71hmlDkqTwSxrzZB6bfYddwflkIkHlzcm Or71D4SKgdz8xTvkiHIhqIkKUhdUJpU70p4ZGN9XIlIVcbXRykivT2wqQv5hh8XY1B98aRZCrHK0 b1HyI7EZXOAkKLOEiDYRVvOHc8lqVBbbY7An78ws9YYGQ5Do2TPHQrn1Sue7SW7dnQcDQKEJFAoo KGvfNNGQ4yZeq+ruMWHggIjojoppBAXLE1YAEdGA/nHtmeCav8fFplEXX4+CpCUI5jqa81G2/wDT LI97CQPJXQhuhpQCqeHyzIhR5NEyY8/mvCUZVAG+3A75VOO/6FEtr+1Ct6VX2IetBXbbxzUiUSZH rezki27aE1cFqKhpzG/XbMDUHhNJnJFm2qvpluXj36eP0ZiRnRto4+qENuY3odx9I/Xm00uW9mZn aKTYVBoTsDm8wRvdw8hWuWAO3NW338Kb1zMAcOR3UpCxoo+GgBAatNttqnLIhxpkW3ZtKJm2oO6/ M7ZXmAMXIwyIO6YJGGrx2ataDNd4VFy5T2REcPIUHYdD0y+OzjZJ0hqSJ0rTeoI75dsebEk9EPKF L12Uk/bpX78tjdNM6BtBTIHZ+I3AIAJodt/pGWjZpNSFjmhXDAFTuKfFxyxxx3WpBCpLK25A2+nD ahEKooAuxO3H2rgtEotcBU0602B3wlRIha3qKKg0odxufhPbA2g2pMCW5Lse5OEJIpaZXCkVrU0b 2w0wB3dWN0o1ASKIRuTTxyB2b8ZB5pdPQGgbkPGlB1yYZXQ5r4SGADDqRv8APC1mI5xTG2DRdgVP bxGLjkWjVCgUHTr9PhkWtU9Ou42I7ivfFFqdxbBgW+ye4wW2Y50st4yx4r8Mke5/yhkJFz4Y7CrF EZVY0HQgqw6fPIk0scaokStH9XnQNGPsMDupHgcqnIjcOTigOSnMJF2BBYUIY9x7++YGQg7j5O0x HoVDaR+YJDivTtksOehR3DKeLq71Gc8GIDrXoTvt2zNiK9zRI370K0JDVG/Q1/rmUJOvyY97HNYx VaEg8hlkXByx7+a1ljBZq7hammwAI2OTtxUunDyzLGr1jZasvXCzCYW9lGsQSMivUj9qnvkJTrdR AyNKjQoCWRTIw6n55iSyyO30uwhp4R3PrKFdFkHwji469t8lCZhzNhryY4z3iKPc3Dz5KtNx8PHo d+uWyEaMu9rxTkJCPcjlI5cSdq9vHNeIxmSB0+x3HEY1fX7VThQ8hsK/F+rMmMtnHnGzYcs4JIb2 yzgcY5aNFewBAb26eOEHownHewtKEElNi3j064eLvYDHXLquUEkk1+Gm/ucBZRkQWitWFe+9T4nr kCQNnIhHiNleylPiG++Y08pjv9Xk5scIPLYrvs1krRjsPoyuebwwT9QluGYxcXkQ1E7NVmrQmgBy nS6mUvq5E7M82EDl3br2PBQGO/Q5dqMojv8Aj4owwNUh5AOuxqeuYctP4huBHF3fqbJZRD6uXf8A rbH2SDsetTmILGx9LaQtDMVIrtua4IzlVE7b7sqFqErbUrWm/LI5Z3Gufm2Qjup829un8cwuDe26 g71FZQAfvzt3REUs4gMAd+uFFrgo7mi+2BEqrdUPpcgnRlpxNOlffBu4cpwBHevWzErKFPxVqD3x 4qWWKMgjEgnioTsaUJoOp9jiSC4csEhy3Ws1uYyH5JICAXG44/tVHyxPFezRuEVHFOEX05ElElPh G7UHt2ysyHcRS8lQ6datATGQruKqGqGoPtdNsrGWXFuw40sntbiP9n1E2PJTXY5kCQPk5eHVEeam vEglfpHhhLn48wk5koNt/wCmBttwrxJbcdKd8WNrrKZ4r+Mg1PIcTT7sxddXgTvb0ltjUh5ocFJJ JnY+oHbdujmp+0M57RgGFEe8O/NgAckelv6USNXkkm5/1f7M2IhQ9/3OOZ2T5Iz0kSHc8V7HrXMo xADiiZMmg0cimlfUWgqOmTBE/eGsgwO/0lvnyXiSVkA+E+PyynMbG/1NkI0bH0tSwiOKjjcgNU5r cuIRhy3ptjOzsvt7cNHU7V2NDv45pss9/cs50UaigKSRyFKsvQnw2zGcclC3LgvxKkI1ONdtzTMv EKZRCxFrRFPueQ6GvbNxoMxBo7sMosK0cMkch7rTrXbw+jbNzKWzgVZQbpyuDGa+orUVa1oDt1OX x5ONM0rQQkOxJoB16/MZTmnVV1LkYfUjoWZGVwaGvyNcxPFs8vx5t8obIkk1oRRuppk4kFpKGuVq FKufhJ9+37WZEGmV9UDIWDigBR6A1FQR1By0MShUSSIN6pBUbqB1oRTqfDLCQeTjgSHNSeFQ9Qac jVl+WS4mvwzeyHlPFSR326bbYQW3g3WJMVfeoA3J7+H8cJCOiKjdAQrGhp17YGkx7mmRQ3L7YBrQ 0phYiVIWRWQ8xutdjhptE7UWap22Y0r4HCGMlMtSRuOw7t3w0omQpMg5d96k+GIUyvmuiVenRutM aXjKYRsaBSSQ3QeByJC2SikDUK+FPiPU4GBRC8maqn4fAdfDIsCqpyK141NNvA4oUGtuL+qppQ9e vzyJczBmogFE1HEMVAlpR/A/2ZiylTu8cBIbrUmiJVSONNie+QOSuaZaYjcLbiMg8k3HXMHIak34 pWKKCqGPIEb9/n44ImJ8j9jkEEe5eEVmKkUPY++ZmDN0apwBClwAbgxqAf7MzhJwZw6LJ4GNaD4g TUdKd8tjJwssbKDkYpC6E7Ffh9+9MuBcCUKUNOtjBbm5lUvI7EcBuN/s4yN7MTMhPYLOSVKEAuBV mXb6B8sxJT38nMwwJjZ3kVt2oRfTXZE3Pz75q55ZZstD6QXZ4sYxwSoEvRv2g1D/ALebgh0IPqtW ADr8Ro3Zh1Byong9zsIjxOe0u9USI13NSKUpTt3wREL4oj6ubd6uUj9KqOfUV49x1FBhsFkARuFO WPkVZSKdz3plsJU4uaFnZ0burAE7EfZ9xkiAWELBpEoaig79R3rlTlCNjZzgEjcb/jkPEo8JScFj iC2pO3h/n3wzhfLmmEq5tugZqk0YHcdtswM2mBkCC52LKSNwuXi1VO6EdR0yPEDcT9B+TMit+qoQ AoAWtOmMthQF9yjdDSFhswPFjUnw+WYOSUonf6T+NnJhR5c1oVuB/wAnvlUIyiLA+nzTKj8V1Dx3 PE9vDLpT4/q2l9jAADYLJPhNNxlOWJge77mcd1F/tEkfRmLI872LaAp7/ap9HfK/F6MqU4wWY8xs OvzzuHRE9y70yDXqB0p1pgtVUIQORHv47YsDJFW8azEKDvX4aZEmnAz0qlY4HVTQOTxRSTsT13wW 1wEhGwrPIzxnl9sChHSvywgM450K5DbV+MGi7fdkgwzSB2RVpMC3GQcCw3ceI7kZXOOziG0XchuI HqFQwJjJqNzt38cpgRypqqtwpD1mKRgcS7UcGp6bjpk5SFWd6awd1M2CzvyBWN9xxQggncbA4Tk4 R3t0MxiVGXTZlUFJEYk8eJ+13rth8UdzlQ1hULiCaJPiXf2GMcgJpz4ZLF2P0ulQQQyPypxWinvy NAP45rO2M1QjEfxS39w5udoIcWRD29nJJIrw/Hw+Idia9BmHDGSbjvTuZ5ABRTd09dSI1CBdnjY7 VHXMz6uThA8PNDycoRxO6MPh70ycZGHTYsgBPlzDcPpnoaMB1PTLIcJG3Njl4gd94lG/u3jo1EcD 4R16d8jllY3+pohAxO30qdy0npqrfZG1OuYWqB4acjHV21bUKtSr8vhYDsDUbZoctg13JmjYIAic 49iOoJJPt1yiUr5tEpd6hcSvRAqcQKl+1a7Zl6aESakgBRi5LINt+wOZ0TwyrkmW4RF9NIlkWjX1 GAApTryzd6Ud7rcxrkllvIomEn7VK1Hf29szi4xNpt8Lxn025PQEilBUUrXKCLO4Zxlw8leOpFO3 2qb9P4Zjzxb23jKudVVVcNUdvkR4HGEK2CymDzQVxI8QcsxVaA1I2G32a7UqMyYi2iW3uUWuVkXh HWNypYkgUHXanjvlgj3tRl0Ciq+pycR8YaUAUUJPeo3pkjt72uJJvudLEwABANBTkBvt7fRiCFAl e6iSHj4VoK9ht+Pb3wsxsg5EWtQDx7ivY9MmCq+GnIB3CJ0Bapp37YJE9GNDq3uFYfskUodzuO+S tpMeqmxYqVK8SaVHbod8KBRQki05MooOwOSCLUeR2DCjDc/wH44VIpUU1ah96+GBFolY1OxrzAB2 69aH+3AoNI2OMoq1FKDfBbFExBeaq5qpOzHemRSZWqvAyPyWhpQqR0IwMbcgZgSAeQ7VwEshAleK NGQFA47gfPtTBbKWKUd1rhjF0oRsMxcsa3DvNDqARRQM1a0PzzFk7iKyO8ljNK1HhmJMdyZYgW5D FKDLEaGnxDt75jrGxsVscoOx+11B+WZWPJyBYzhW6o/Egmh57b9c22HJxBwc0a3Wq55H3G1fcZeH DnHiQMqPPcMf2FoKeJGXAinAlE8SNh+C9MXGscafDX+Y9cjPlbibcfknluiR2pL1qd6++a7USIGz t8G+6VX/AMNnIx2PSvfK9GLI23Z6qdRKTw81jUnqCe234Zti6YImN1YgnqK7e/yymUHNxZaCuPhp /LlAjXJzuKxuvIVjUdP11y0btRlw+5Y1FJHUHJhhJpfiahBrv+OEojK9mhQGgJFD18fbKc2Izren IxZRj2pVFeLdz2AymUTEb7hyISEuWy5pF5BWHWnX2yEswjIQP8TaIWL7nH7fxGhO/v32wToSFlMd w3F32qB0U7CuMJxyRuqIvbvYcMomrsKv7zjUdDSmQyxkGyJCHkkHPjSo75r8+o9dHk344emwsZOP Q/TlMwYcuTMStsGg3B9zhMhz+a0osCSSOg6ZjyzSgdjsejYAFrAEVJp49j1yebHHJ6oHbuPRYEjY 83eoK8qnlT7Vcw/BNUybltGRjTt1zuQXQcXetiXccd+xHgOuEpVPhC0I6GoPb7sDG3RsVIdSR2+f 0YWuWO91cMZGUuORHTbcnsciQwhAxRJmV2KSKPhFApHh4HIgVycXNp7Njm0bBZAHhkEj0+KLcOPo 74+LXMU40pHkVFG48o5QRXYno1Tlh3YpoTBdW5RVDAAVB2KhRxHTqa0zDIMDdsCCCSEsksb+3YmF vVFfjKtUClTRhsRlwyxlz2cmRjIbjn+KblnuhErNSnUqNiCp3BH05OMYktEYAcgibGeGRHAoLhiP gJCig7qx6HK8kSDfREoclO7jf6vCQTzmYqg33Apy69q5IEcRHc2aaNz3Q+tBITBaK37xVV5a0I5t so+gZzmfL4ucn+b6Y/peu7Nh6DPv+5Qs0VCzO5gfqOO6nL4RrnsfscvIb5bppIZCwaVaNQcHXYMM yOvq+biCq2Qs8srfbYddgfDMgGY32pIhD4rYFjY71Br8NPbCIxkO4rklOJ7wjzGwUK/xCtagbjwy nLCubXDIDuFrBm+JiSKbnMWZvctgoKJUq/NdhXttmuz4uobLsUUfHdosfDgWpQEj38K5rji3caUC un9J0SNSCdqBthSuTx2N2AsbqIijSlG5EbE9d613zLxyJKklW5AQvypxpQV6fL55vtNK6AcLNyS1 I1dwUNN9gTTY9/fpmytw6RfP4FcCn+SN6nr9GRARIqhmnqaEgD6ag7EGvzx4Q08ZQ/ryAgHou246 4eEMxMrUmjuU4qSm3Ign4SFO9D+vEimYlaDlR45P3bUD77fsj5dssB72qQ32RQuyJUKqWjp8afCF FRvTvkOFPEvL2s7P8RHpdHOwIIqKHGiEEi7KFMcMgaYSHeoqdlqNqb5KyNkiioEHZDs38w365JJW RCWL1FG6EASd9q1p+GJooJ2aYrxBXYjqd+/antTJU0k9CtEtHFV5DqyHuOla4SGIq0JKXUHiOSgk 1HXftvhCaQrMyAU6dQe/Sn8MmhEWwL8QKsdqKPHIkqASdkbb8mC+560/zptgLFMCCRVd2G/EdDkW LUVKBadKg1+eBUwj5MhQ9hXv0pSmRKFsaOzbD94Nwa5ElvjHuRM0MDhWpxkO5U06jMYkx5cnaYjx ipIMTxcylRy7V9sY5QRunJoJQPFDkg72JlZq716H2zFmCObt9PlEhsgSeVQdj45iyczksSORGG9N 8p4UmQKpUFq/tHbCI0WsqqM3HxHQA/PM7FIjk484gr53i9N5GahUEgU65scc+Lk4GaHCo2ENYPVb 5knwOW3vTh5BUeOuiJ0e3NzcCZhvMS9BvRAaD8MOWVB1OKPFJPLpgF4gEKNhX2zVWTJ3Q2DHfMV3 6enmgAJYAV7/AEZsNLho83C1WWwkolEix/apUMTuKUNeuZVOGjIn5MTUVpUEeHvgISCRyV1mqvx/ a7HtlZg5EcxVkdVbc1NK5Axb45LCpVWqDuDt/TGyyACka8qHsdj7ZNhe9LuAIoenbbv4ZG924bBc rBPtGngcjIWW+EhXk2kgfkpX2U5iQnxk2NnLkOEBdReQp2NN8sAiBdeTWSbpeuwqegP45AwB5G2Q yHrsudyCN9u4H4Zj5cpFfj3NsIrZVIFaDbt75h6iJq22B6KB5dxQHMQykRu3ABwPf26YASN+9SpM h2PHbtlJrpvTMFrgCQN65XKQ5sra4Rc/ppxp2yz8xLuF0jomZl5kh0DHuR751fBXIumG/RQNlA7f DVGJ6HeuA5pR5ix5KcIJ22KlLbTRUZl5KBSq/wARlsM0ZbA7tExKHMbd4UF8RuR4HLUiYPIqqy8p AqrUkVoOu2RJrmojar6rSMWY/Ed6ntXbGqa5wsebYYKKnqOlK/wxafCNUd3Ooah6cq7dajr1wgte TTjpspM00akglSB8RU02OHYuNLDKKIGpuQvNA+9eZqDlfgActmuQtbd3lvcsnw8CAAAN6nud/E5L HjMRztEYAbAIV6mnD7Q3r06Za2QgZGk1sl4RNeXLlhAKqh336gfTmo7T1Yww9P1y2H6/g52nwCc/ Dj1+r9SRSu8srzykszmrt8/EZpsUABb10RwjhCJtLlI2KSUaBiAUPb3zLx5QNj9LVkxkixzTOQlI COXKBt1PWn05miJA74/c4caMu6SAkcMooegHvtiJj3OQIm1a3AbcCtDUL0PTL5SEo2ByaDcDR69U xtZSEAmFBSpH6sxZZKq2ucBdh1woDDiKgimUZRvsyge9SCnga0p/HMScdmdqkVYwQAATSp/pmFKF sJbqsjQ0onUkkgdRQ9PYZUInq1bqS/bPcfsjxJ98yogUCpVWY8CgAI713A/2s3+mgKEnBzSPJCfV yA5FSTRgewFftDwzNtxSF0deFDSjGqsN+nTC0TKsZQqgPTwLDttTDTUSpiJJAxBB47bDep/28VCn 6SxpHQBSK0IFfGm49uuLISWSNGlxGgYKxXl0r0NePh3ONbMxJReIoFYKeNeRCnf3/XkrtHLdWikE 1sOBpGCCygU2H7O+DkWRAIXRFSjbChc8Nyfh6GtcSwjsoNGJFqACa7gdK07YQUmuaHcON6CvStKZ O2IAUWhYVNRShND39tslbGRBQczSx0MR5ClSprUfLJBjSxbhWWpHEneh8PnjSm1J1oGAJYMK17qK 9MKhfDGxPw+9adMbU7JlamhAINeo2qKf51yBYFMEYGjLuPbIoV441Y0/aXoT7+OBC5HfgUAqy/ZP em233YCaZ448UqVLRw8igGtDU7UoR2rvlOTvc/FDei1qVxOjB0INOp61+Y9swbJLutPjiRRSmRhM xNaSdge9cjwucBwjybW6cL6UvxKNq9xkhPpJqlh34o7FQuYKEvEeSHc0rtmLmjR25N2LJex5tR8i ePUDIxjZZTNNupUAgddwf65GQMSgEHmqiOdY915KN6jrTrl8YS6fJoJjahdSqwjiC7v9s9qZsMMg d+Xe4moJoirsbIXVZbuK2giiABkqpUb77V69qd8z8EQSS6PtCchCETtsyvynayppzzz/ABHaOMdK cRv1zF1e+waNKaK7UnAqAKN3BynBhpy8ubZiHmuY8ra3Aqx+NgRmxwR5lwc8uQU9PHKIs44jYAnv TwyUmIOy+RAJSoNKda4hkqRMzKBQcT9mp7DbAVV4pOLH37dKZEhlGRVlf4T4dPDKyHKxTLdAxIP2 Qdx4YxFMsmTiK6jDruB3yJETK+rdCcuGjyaZVIAIqBhBLLhC5eS0HgcqyEcqcnFZ6t80LACtOvvk JTAlw9SzjHijfRVG5NB36e1cqnDh3DOM72LY9ONTTqO1O+UccIw2HJsHEZc+a0kcBU1B6E+GYEyO EEnm3gG+S2RCeFDQZVkxGVUUwlVqbKcx5Gtm0FxQg7kEdzkYzJ8ldx5bHoOhOQMeqgt0FOO1Kfa+ nI72lGG1daGvqd6d/oOdXHVQlyNOqOMtAkbjsejdR9OWEApBpv1wBx5Af6337HIyxA8xaRJa8Ftc oJECqxrSRd6keNMMJ8Bq78nFy4BMcUdj3rI7RleqSKD0qRQb+HjlpkJDcOBk1M8Zoi/NTlVqmoqa 05LvXJgNkdYP4gto9QfwO1abd8LfDLGfItSV4jsCenv7Ys+FYXqOLDltvv1+nFBht3tcV4/CaePz PtkhJx56aJ5LlC05ClQMSWWPDwoyxsnuaGNaksFXwBY5XPIIiy0anJR4Qml9aIV+rUosTEAA1BJ6 sa9c43UyyZMhlIg/oDt9HCOKPp6pNPo8u5WpaldhXJQkQ7OOoCxVC8YbmM1Xq7b1zOwZ4yoSHxSe +JWgSRAqSfSIHxdvbMoCWL+qi4y36tFOQ+IVUdx4DMog1vuxExa6FlLF+XAfsN4+GVccDyPCUTEx tXEmscx9LhMNz+2OmV5cn85xxDf0rG6bn4TuPlmJPzbAuArQ7AHocqlZ3QSq+l8PzGXRxAjlu0me 6wco25KNxSh8KHMeeGz5KTbk3Nd6gk0O438MHhEGmJLZZuRRV416Glamlc6DGKi4OTmh5riMQheH Gnw+PT/by+ET3240ygxccWNfiU/snr0y0BokqRTBmZiTRfs9unbCQ1rWupGcPE3JVBBjA3IxpCOj kjlMbsvFyhogND2rschVJU4iGY+mDUNx6eHeuEramjNLLM9Sq8gqxsKDagqDiQz4lOVR6hpVaVUG m+3iMIQSstzbwStEv7uVwXIBJU+9MJssgq8QG5Iaf5SnqO9K4EWpS16kEDsfnXY5IMD5IWUArwJo pI6fryYYIC5cxSBeRdRWj0pWvfJDdKhcRh25Ka+PtthBSD0Q8MzwyKZFNGJ4MO1OtaYSLZGIpPtP W1aTlMW9Nxx+Hcjbb6MpycVbIx1dS5ImaFIZj6W6bU47mh2yOORI3TngIy25KvCWEqChVTWlff3x EweRapQkOYREb1aqqRxqfnhLBEBY3jLEUYCoPeuQKYSIIIS8S+jLyFVYkllI2J/rkDyegwxGQeay 5umKk9QftA+/hmBk9O7tMeNBshb4gNvDIbkW5AKpu394N/5stiBPY82iZ4eSvFHMvJVHJKfZ8a9s jHHUuE8mucgRxdV9qLYIzEE7gAU6V7ZZDT0aacuoPDYRa6WlxE7xUSRT8SE7H6MtlpolwP5TMeYQ 9vcNAGjkjqafBXt4YIYjE0fm2z1AyR4oHfuSu7cXGpM8Y+HpXoPc7ZflgOG+tOPo8sjk4enNLLu8 V9TchgwhUKhFabCnfvXM7HCoAOl1OXjyk+bN47uK10u1jZgrFFPInerCpzEMbJQJIC4uBNNQ/F0q e3XCBQbLMjuxDW7kXGtPw2RDxB6b08czMcag1zlckTbobe2COA3L4lQ71r75A7lmBQVj6cik7kGl Ceo8a5FkujEhlWNgAlPgbuSv8CMUK9Pio3bbb8RgLZjNG1qvxI7j2xXIReyupFajetBgYxKrGVIp 4dsqIr4ufjy38GmD8ulBXrkBDhO3JyRk4hvzXA1HTp2xPc2C+am29WU/FUr9I8crsRA4t2zc3Wyr BNz/AMll2KnqDkpRIP8ARa4ZBId0lRwOVTsfCuarNGPGTy/S50CeFpT8JDfMHvmHsQRLfzbeuy1n ViKdKZAzjIit6ZcJDjQgk+3fGQBu+iAabHAg1WhP+fbMIwkGdriGNa9B0BP6sjSrPi5dN6f59sNJ TIK4Cg/C/fwzdyxUbhycMS23akYUIlXoK8h4e2GOXIJAdfx8GFRMeIclGTT45PsNudhXf55lx1hB qQYGAQ6/WLdQoUIgOwpt1/jmWJRny3cacZDk19YUzI/Hjx+0p67Gu3jk+DanByT9QJH4/Sr2jQCR 25MC1GpT7O9coyRntXT7U3jIPPf7F09ukh+EDkCQ0gJ3J375bGdOEbBS9ldXorch2B2y7Yt+LUSi e9aQCaAce++B2EcoKm7EE9sIbC2jEVrtixLIdGPptAH/AG0kainblxNOvtmv15rFIuujvqPiiFNS SPir37j3zlp87d+vjYKANw1aAU6jxyyJYyFrnSC4I5p8QBB7Vrl+OiWIJjyQo8ufWyUguyhYEsjr VRQdBmdjl6a4mw6vg3MVkHllJIWEt4VKA/AFpUDr1OHYgDiNJlrSJWI80Rb/ALqIW8iLJGAQOSiv EZh5pmWx/axkLPENig7i14BjA5ZD+y29KYBllw1zDfGd8xuoqHVVBB26/fkbJZkhFQoaAkZlYMbj zkiVFeu1MzoDpTjSUyqPsCKnI/lwDfRHiOVFV6HqenufbCNPvbGWVYoVnLUJFeooKV/hmYI0KcWU 7KC1KMoWpR6j7Q2Fe/wjLcZ2aZ80qLCu9R4jL6aCVyvIJKAfu6EV+eKETbxqrcx8W/fqB3pTxyJK kbugaYXTStX02HGp8PDfCaqlKKViKDmeVeZk/ZoD0+eRYqd3LOErAA7AgcSQK+J23xDIAHmsuG9S MRtGZVNKkEAr7jxFdsICBJ0gAPOnwttyA7+BxCSe5T9QqwUkUJqvfap/XhpBKpUVO9DuQDQ7d6eG LElDScaEcRyNDy7qT/tZJFoKVgTTjyHc7d/7ckhC+kySclqYz4fI0rkrZ3a0xrK1QPipUp4+P34p Brmr6dKIz6QJpWrHrxrsAcEhaD3pzCiuOIpU7bDvWmVlgDuryPLJVGXv9qnUqKV65RjxQiTIcy5m fJPJEDoFqxzRnkp+EdSMusOERXNHU5IKAqG6kePvkGI5oSZOJ4sK1O2Ah2Omy9yEdAyVAqCaGvXM XLDueg0+WxvzUwfTFXBoD1yqOw5cm6XPmibf96KNxCCh9zyOZkACLDq9TmMDRVfSaCVXIYxncEV2 9snwuDHV8fpOxTQ6Za3EHrW59NqVO9dlHQgUwe9xDq5wlSFjvOVBKo5xr9pdmZQaip75OmmdHePL u7mtS1HTPqLPKRJKsZZtqEeG+GMTbSJEFi8N2sWnNekbspCKd9z+vJnHxSEejscWcwxmY+qWyj5e 0mbUtWhtyOfIma4foeC/ERmRlmIxdWRv5pr50UwosiHixoAD247UynT7plyS/SdS46dcTSuvqIPg BNCSfDLMkPVQTGeyR2xMshkP2mNXr3Jy6bGCd2vBwgP2kHxf7eY5cgFFGFCoO3MADbuR2yKrSp6j 4XJ+H5D5YqvZulTv1qMUg0s4pXcE0H3e2Kr0NKAbf57YqRXNUQjw3rXIybsY2rqeS8UPQ75iylHJ VHzdpihLGDxDyXNQU4/tDp2GQMyHKEAWlYV3+7Jxj1YSlSqkJkYcaB+56ZWcstq+nqiWGJ3P1LpV IoCp51pUZhavFYuA5d1OThydC24qffMLJUvItsTSkVB6DfxzDEaLdxNsqjqaj+mW5ZV9O4QN3Bhs Nge4ygStPCrM23EnoKN99dsrESTYYqVfi6/TlnDvbLonMpBcAsCp8BXN3GE4cxcXTY80Mm0TUlBT C1KkLX7JOOXBe4/HycmM5jn9jUoaFlpVg56qKgfPKhEgHdsEwea7mnEBwR4mm2McoHL0/cxOMk+S EuLEEViAYdlJ6V8M2GPVD+LZwsuA91hDBODgbq29FbYj+uZd24YhHpz+39qtFJIQSWpvuAN9h3H0 5ExDYcfEN2mRpGUqvGpry7Cm9adcQacY6Yk7clxjB/vUFDv6yDc+zDpiPI/BqnGWM7ckLcW4AJFG Qbhvb5ZYC5OHVi6KFPIGp7b1PfJOYU5066CpE43aBuRHcgdR91cx8+LjiY/zg67UAxmJJ3JCinnE 1Y3FU8ApzjZAiRjL6g7rFlE4gqUpJUBjuBvU13yUWyKmavQA0I7/ACy6I3ZclWAyNIvE8Za/AOzk 9suFk+bCVAeSPdFkX1EFdzzirSRD3ocmQDu0A1sf2KLxIG58eaV7/aGYcr6FsBKGmVSCAASRUdth 4++IZgoTgK08OuZEYsyVzcwPh3+WbfT8JDjZCVnrkKqlhy7jwzLEBzaDMrWLI1V2B35nv4j6MlTW ZKV1Nyorfqrv40yUQ1k2picMpBPImtCNj4/TkqazJCSs7t169ulCPfJBrJQrCpp49SexyYYlcnJe g360/HEpRMIagZejVp8iNsiUEN+pJyApQE9fHvTGkFEIF2XqD032+LxrgQtPFWdgSZG6iu/Ee3hX FbI5odrgLOY0TrXkabAZKtkLmmHEVqCxoab9fH2xpG4WkkMDSvhTrv7+GFF9ykXYKSpBoakHbqa0 xpSbUZZPjqRsw2p38MkFpDylg7y8iUKj4DQKCKmvjhUBciFSVIodjQ9qivb5jFDjbK5qGK0PI067 7Y2kSpXfRqyCYqBLIlVmU/aVe2R8RnR2pEW0jRSLG5ox8Opr0xO7URaZ26Ays3QCp4+/fKMhpztJ Z5rJ3gUq6MRWpp3NcjEyczJghIKUOpDdCCN9iuW1bq8umMVd3idSVPJX6r/EYKa4Eg9yAmio7UNV psR1GCnbYNRtRXWwVj6VwnJZPsnw98IjTHUZieR3V7zS2tmrCxePrwbqAehBwx8nDGs4hwz3Hf1R mmetKjk1khCkSDqQPEYycXLHhKlczx21zJbwSEIydiQanfCB1QZGfPmhLef15DFIQLs0UV2FACev yG2TMfk1CRiUg8xs0bGJhx5GjcTyBJ60P8MuxhZDa1Cfklha21ONSzsPlQD9eMR6iXIjK4CPvKbe VZ/qfrXrOq+pWJSewXc/ecGYXs40juh/NF6bxgprxDfD70HSmHDGmMixySUiFLZacEJYgjepzIre 0dGoiFABFAMSFBTG3mKFTSo/D6cpkHIiU3hnEiV6Hx8a5UQzXtXqdvADtTAq1qVrTagr70xStLBd vE7gYQpDqHbfr1xZCJKqoNa1ND1HavfbK8gJia5uVhoTF3wqhZgF2+1tUdvCuYeWZjIADY8y7LFH igSTv0boGG/UfZodslOAkQe5AyGII6lei/F0+jsceEWSzEiQAW4pSZCAenY7V9t8wfGEpED+HmO9 yuChv1Vi3GrA/a3plOSZxEmPM9ExHFzWK3LegA32yjGfEsUItkqG7W3vUeGY+SF7DmGQNc21rSh/ syBxkXfJeIFbwPUio8R/HKzhkBxDkz4g2RxAJ3FMhxLzW8t6U7ZdxHn1WkyjKkjn7UzrJ8njhwk7 K0ttDIu4+YruD28MwjcDY2c/HmyVX1BCu5iACkmhoF7j51yBwCZv+xmddQqQpzXcfLi2/Ib9gKe2 MdLKt6LL85jv0lTN0n2wQR3ANDv7HD+SF7EhEO0TW4BVQwYFuIdV2JP9cx5RyYvc5cTjy9Fi2tvI 1VJjPZe3hmTj1cuRG7TPR8O4Oy36tPbkM3xKooDXbw3GZEM0Z+RaqMaB6dVeGUUNWryqDT+OJjXJ uNEbrZIY2kQgcRQjmO59wcIJA33cXJpYzO2yX3ljNFVwoeLsy/xy2GUH3sseOcdjuELBP6Ugr9hx R6daHLiLY5cfGKZPpt4rxC2nYeiTWJ/5Sd/uOaPtLQcf7yH1Dn5uNps5xSoomRHjHBhXbY5pIl3U SDuFnoyn7A3btWtf8xlkY3yZcQ6rokSX4PsygjvQjwOWxAlyRIke5FWTep6qsaTj9sdTT9eINnza sgqu5qWUhaqoDA7nxplBAKYhDS+nIDyBSUj4fD6cnGTMWEOUIJB3ptXrmbgEZEALIqE7kE0qONOm bbDjADi5Z7rFRWLPxJB3IJ2P05e0EqbkAkMoEde2+1cIayUO5ZiIwdt2FT07eOSAYkqbVBUUoRWp BqD77dzhDXJSdjXrUiuTAauJZyDKKjfp8ziktoCzcF6gVam22ApC9KyU41QjcivGtO1MDK1ltRHN SxSnRj3wlSrtMka8mNBQb/P2GBhw9y+IKKdSa08WNffEo4lK49JVkAT1SwqQKVPthFqB3NLVY1UA qqgUB7DbwwqTezuf7KqAF3JGFrIpTZAatTY0qex70OKhCu6k7gFCdz4EYWQ8lmwBWvKOg360p2H3 4U/e6MblkJ7jbrUV3xSeSZxwKSNqbCo7dN8gS1IhEYVCiijcAeFewwIKyS1W4CvHvxFCB9oECmEG kgqlHWPl1eP59fo8cgQ5GHJWygI5ZVZqnfoO3Q4QG+eeveqR6fKGJVeXHuO/3ZLZonqCQrC3KxsR 8JAr1xLjcW7awMfgYUNPtU6+GRLLxK5KkNpG9Uk+xT4T0pTwxtByG7VA4lkW2uJCDH8KSUqwHgRj 5hiT1C1zJYSFgf3MqUL9qN0r4fTjzRxWKSu5jWerJTbf02qSDWg998siaXhSx7pZJEqwEyU9Jm6N /k/MdssAQdjuk2oXge5tkO/CT1JAeux6HLIx2LbIWEw1Ta9CLWiRVBPua9/mMjDksUwSZbezghKA cBWg3BLbknI8y484m0m1G5keTma1U7H3pl0QwpLpF4AKwqe5Hjk4m27JGgAqW6ROOtG/DBK2qKJg ZQ/BtqZAhtiU0toTxVh9n+OUktoVfVNeJrsaH6cCVzVIO9DXxrtiqz7VO5wsoxsokKp7dAP7cqcy +pX8SGB/a61rtTISnWzfjxXvyaFGYrUbeOVRyxNkfH3uR4UhQPw9zZpQqeoGwwGUgKv1FeCJPFWw XBWUVZt61UdPozDyWNyR9zmRA6BZ6p9QsVHPwzCnqJX9PqbhDbnsqpL0AWlRUjrQ5Ceblwjn0/So j3qpQv8AZFDkZwM+SBKubuG3xA08fDI+MQOGfTkkRF2GxQBielMiJkCypjvstDGp365RHIbPRsMd mjQbdsjOMf4eaQWqfHT9nrTI8RZJ1S3mIFAD2I6Z1BymO33vJy0u1jceS0gqTUB0JND8u2DiHPq4 84kiiVFlVq8wDvuSd6VymRIJMXLxgUBKjsoyIVQtWqxgnfcgVyzHms13teXR1uF6tEYzzjHw/CTT cnrl1HvdfKwVJmQktCaM7EcaUG3tg4bFFuwamcDs2JDz4uvE069j7jMeejBGztMXaZvfkiUkahGz pWhr2zHJnE8MvgXOgceQXFa0SMOcOzH9kjYH2Fcy4ZyPq3He0SwyH0/JQuZWR6TJxA6FTUZlQojY 20SymJ9YpTjundKI1ANgp/aPfCcYbMepiQgbq13Lp0O5A98sjJke8KmkXYWURy/ZOwqdqYZxcHU4 r3HNlFlMZ4JIGYNNAdmO3JCKqc5ztLTcEuMD0y5+9t0WboVNWeFjXapoPY5hQ2dqRaLlMU6qyj07 oUFPEjLjRPdJpjcfOKHZnEtG/dum1R45VI0OTaAKcHV+SuKsT+z7ZDYrVOMhqVlHwk7N1NBt3yUY EjbmxKkKAk7kdvHM7T4yRfVjOVKMjqxYBKkePWlM20I0HDlK1IQrU0AWnU1NMutpKnKRQgE9anY9 RvvTCGJKHeMsWmU7V+KtO/fJBrJQzjckVr77ZMNZKnuQSTQin9MKAGitaU37jFkHMH4q6faPj3xW qXrKkrcWNKfa7VIwVTJuinYHka0NAfDpTApCiawiRh3FDtUjJLxWQF0UiyKDWqg/CBsR4YkMCKK+ WMkkqaNT7NMILBCrcSq/HxP2TttkqUlXMilee+23Gnj3yKOijI4UHi23Ujf8cKqKkHelKdR4dtsU 04KVkqACrdU+fhim7VYE9R1XkIzXrTbr0OJKSKTGH1o2Mdwh4nZX7eHUZA78mFhGpFyUU+0KmvWu RayVttGiOQgCAkl06VJ3r9+ElUQYlLnlsO53ocjaT3hqO3HOgFGJFAehHzw2pkUzt3git2dqVBpQ 9SQe2RLWSSlUxuEmb4awtU8uq7k0O3yyYZKQlWU+kBwdd2UnbsB+vGlXxXDI3psnF08f7e2JCoa8 mdWEmxEbbvQcyADUV8e+SijkVyakz2k9uo9SG4XnxbcE9/x7Y8O9sqSS6lW3IUsfTCgo9avGaD4T XfjloFsq7kpnnWT4tgy703pvvtlgFMwBIIKyja6umkO4V1Qsffv+GTkaDSPSSEdLKJrq6lDVjdgI x1IHTr3yFbBugNkXNMK0oCOi17fLAAwISuY+o+w+Fdvp98s5MYCzaHk2Py2I/HJRXIoEsELDYjrl jiqsctXXken35AhlEpzpl5wqszbMNvnXKJxciBTAkMCQajvT5ZW2NkBSqt3GxBwDfk38PD9fXuWK KOKnbCiIoomOh2HQ/CCcqtzqHvVGFASPGhHzzHlIRodHNjAyBPVaxA2NAD9on3wzxk1VNYzxgCZL qcjUbkU6d8nIVt0a8UxLcFsorJXeoNa9dswtRhHCPJzcWSyooPj6bDr7HNNiBMjtQcyZ2VI/hcAN sT9o7DGR4TsUcxyVg9APEZXLUJGNUV1aP/KzIhkjOJvm1yiQVpO1PoP05hGRBPc2gLOlQcjsWTam h3+/HakO4rWvbrTDcvj3ptMJo461U8G9+hP8M67xCBuLH2vL+FEmweE/Y71mU8FBI8RuB/HMOQsf V83OERylD5KUcocnapJoWHWntlfFKFd32JnpIzBMTv5qwSvxA0A+0P8APrkSLNhqvgHDIKMvJKnj UEmvucy4Sv3utz4RzHzciiNRISaNQhQK9clxWaafBAFkq6CKQDlXY14kVNO1MNkNRG+y4wSIqyR/ EKb1AqAe23fbEgS2LZjzmJ5uQBgOfwSd65jSxSgbjvHudxg1gmKlzW3Vv6kRBWrruvu3YYNPIcRr bvbdRG4jr3LbeFDAq1U0qT2+LrvXp1zLBo28/O7vqhpbcpR4/sd0PUf2Zd73J0+oINIC5touAmh+ FgwDxntXuMnEm6LsIzjMWE7tbS8uJmnt39M24CKK/bpvTMfJkiKjL+J1nARuE5e0mkhV3pEeCtIK VIJFO3UZos+GMZkR5c3baXPcRe5WFZOK8wORPKop26GoyjJsN+rkgjopStJHQyqKmnAkV2/jkZGU fNnEA8ljL+7ZyKSrUinw9e9MojzpN9Oiz1WkUFzuuwP05n4MJBuLCRAc/EMrFtq7itOubfENuTiz koTR+rMPSfoDxJ7jrl0TQ3cc81oZEDgiqUoa70K5OmFrgivaO1RVTyFSeX0Y3uwKXOhUew3+/wAc sa7Q8o28KdD4gZJjSnwqAT3FflhtkuiBT4dmpSgP45Esg3zQcnWtErUe4O9MVWr6Ui8zVG3I2oPu OFBDnadEAU7k7mla40FjKi2/E0IO4HfbfEbJNFQZQjVBrXag6be2SBYEdFQvzJNftDevb3xpiSQ6 RVkPYMPsnCGBCH58GPJe9Pn264VWH94ppsW3AHTY0OKrDGw4sAeFaMB1HyxbAVeFmVqOtU2+LwPt gWQCdxaA08PqRkUNDXrWny+eUnKBzYxs8kVDZyRUEy1qRSvRt6ZEyvkiq5hUS2KqAi15DkoruADT HiUwtVexjktUkh5GevHpuu29KZETN7pMRWyE5yp/fLyQdWHt4+BybXXcjrS2EkhVTyDCiDpU4CWs lZqFnLCweOpCfEJB0U/5XhiCoKWrczLKYpZAkbAkHoD1NPpyygWdKN3ZekPXiNVkAYo3vtkgUBTn 1KKSyMU2z1AEg248eoamER3UR3QL6gI4Rb3ILQsaiZRuSf5h7ZLg3sJMO5Cev9U4hW5wEh0PYMOj fwOTq1Chf3PrQEsf3hJ5KB070+WGIptix+ebgrDudh45eAs49RzTHSvg0m5qPjZk4U7k1yE/qaiL KyWQRcUQ0qQzde39uIDkBp7hh9rxxAQQsSQBSNySasuEhhVKbpuT3PU98kCxIUD9NegHjk3GlFcq Veg2I+0PDEliAmEEbG3DEUANAabZRI7uREbIu2uygUO3w7gAdQfEjIEMwUavEmtaeA8Qd8hIlycM Iy5nkuCEGoGx3YZEzHJtOE1Y5IiMEfF0/rkZNuML2J4mlVr1+jMXi2s7Oxo8husVRuK99j198mcn DVtHgCcT1VlNSNqEeHbLDIVu4gwmJBiukk4025V7Zrs2fgI4Td9Ha4sfGNxSmzhlJAp/N88w5ZIy BI+PvcgRIK0KB/q+Ga3LAxHO2+JtVAFDuKHcZjCTJco+Goqe1clxEckFsAnr0yy+Io5LW32ByG4Z BrotfHpkeJW6/F/nT55LjRSKufrCTfFyKHaoOwqe4OdbjjGq5F5yc5TojePl+kKW3IlT7fD8J/4H plOQSIoj57j583Nw4qPP5bfZyVAsnIEGooK9uvyymOSNURw+7cfJtIPQ37+fzVY2k79PxyGTiu+n l+NmYjEj9aryJG/xdTT54BIW4OTBIC+Xu/QuCJJxH7Q6V9u2WQzbmjs4mXATEAjdv0kVTVQ6nr2O 2+xy+GW/JxcmnI3CIQ9fQcoQeJiboQd6bUyVd7jSJGxCi7AS0nUI1K+ogpQ0yyPJSBziWnkdVWgD hzQNWhIPc5XLDvxDYubh1hrhItdNAyVmTiT0dOgYe9O+OPJdDk3anT3uorIsjHh8B/lbqDT/ADOZ HIburMSEPeWlYmdQDTdlA6+/9mTiW7Dl4Si/L2oBZXgoT6jgAmu1cx9VgEhZ6M5SMSCOqftOXmDE EuWAVq7BVPQ5oYT5F24hQpbcgLKwReCId1BqN+++RybHlsyhuN0JLxdwH6jqBsAPlmIduW7dHYId 0Vn5iQMT07VA8MtxjeqZW4KeJoN982umjRaMp2QFy1CCCJHHVO/Tvm0i4Mio211IXJrRqUoPnXJm LC0VOAkIJI5E9QSNvpwDmxPJDkutA1eIBP0HJNZKlKRxp4V7174QxQ3wsRUEHrQZJQ7gwiBFCx6V /pgtmAtQlQOe3j44UL1kVRyC/CSOVNqcu+Cla+EgFxtX4f41woWGeRZPhPEEFURuh71740EbqM/B 1UgBhUsV8fbEhvwyETup2j0i9NxuTVTWpX299sJCJziSa5L2jIqy/abv2phBajuuTi432rvtiwOz ckdQB29/DfvhYWhvTYMtBQgj9eG0gJiqK5IbdkG3iBXK0I46OJYlaI0ai0UftV36ZHjpQSnejQyw P6Ui8Q46HfcGhpX9WUZvUFhKinq2Kv6nIUA3rWh3Hb+zNZPIY1Tl8V80HcacVUtEpbitAQKHp0y/ Fqb2kwlHqELD6luySAn01P71Vr0JFa/PMs7uMZI+50/T5Asygei/2qGvUbiuCMj8WsyIS2602W0R riBv3an4k+yaHYVrkwbRxXzQr3nrW7wmMN6jfCSTQMOzVPtk4pqksnCqZCUUHo1rSpUU7E5ZSUIs 6hOFVaOoI5j7DD9lh1GSSl2p8FblH+1/eD9k7Vr0yyLIC0DNNyXiWqNmA7k+DZMBkENKHRT6bc0c 7oelckFMQUHNMfTNDSh3XrQeGTARG4mjySZnee5VFHwKak++XVQUy4jXRPQGjVYKbD4m9iBSlcpK 4xZtBXMnJOQ/adQAOtK0yUQ2nkvLhmKnr0rgS0PhcYsS2TXft3OFhS2ReQ+HrTce2ENMx3KcZAcB vskb5ItATCGQUA/m37ZRIOTAr7YMZlIAqOvflv4YCyATcA1HHbwH05UeTfhu9lcKTsRv7nrQ5WTT sIAkbL0FBv26/LIS32ZxBAsc27gKSpSooN6+Pc5ganTSnOJGznYNRERN824YwW4sPhpucnmsnhI9 PejHVWOa4Iat3B/z3yzhiYcPRpFidtqrepRaCOm5PXMAxPEAK4APi5Yqr3slY6qDt1rtTpTMTNUN qrdtgba2NBQb7V7HMLNkEhtsW6IpVKFDQkHfp2zHgAR5rdqila8Sfavavjjuho8egOTCrDtQr1wG wGQdU/LxGCrVvk3TetPHamQpaTASq7hJNiAaU8c6eGUSO3J52enlEEj6h9qjNZPu0Z+LwqBUdyDl wyVsdwwjqDI2NpdR3+4rIpZEqsy/CDTetdt/kch4Mfqh+xJ1RupD9aJZWYkxMAwrVGHXb8MqAA5g jzbvHl/CfgWklIcCVSjN9IHftkzisd/3s4ayN1L0n7FWhJqjVr0OY0sO+xcoSjIeS4O6ghtwdsrB lDdhk08ZtuW5BoyF3AbavU75nYM4kN3VajRESscirLOJE4ygAAAA/sk9+vTLhTgTwmO43CxoiHIj FeRA9In9Ryy9t2oG3JNWqBSwP+62O4FcqniB3GxczDqzHaXqihpoI5XZoCFdKuQQeQPTc5bCRH1J nCB3ifmqiRWHE/un2BDfEvTclu2T397jGBHN2iQqdRaYilvCWavY+GU67Jw4jfM7N2IGUogJjRhI 5Cg7/aWu5+ec8IjlTv72XS3E7sI2q+2zH7WRmZS2I3CIwA3XCIp8VQxbcVB38a5jWgm1IW1W/d/C 1KlaZk4s0orIjqo3PKIb9em3jm600hMW42Q0lcp+2W2ZvhG1BuKdzmeHEJUgnpKG5V402+eS5sSq zXc00oaRt+IoPCmMYADZhKTbsAoYsTyHh4+BxYFCO1a1Patcmoa5HmCoBoNu1dsDIOc8h/LTrsNh 9HzwJUCAYyjMQpFQ4p86nJJBo2vAKxn+U7v47DfFhalGssZdiTIp/Z6GuFkSDXR0Kt9obf5B7Gvv ixmaO29LnUU27AVHffCwtDt8TcSKN/N/D54U2qjYUbYDt4jrjTDiU91Neo74s7tWBMZG+7CtAa/f g5tZDaoHlHH4l7jpQ9dsCUxjt2IVjuO1OtDtvkCWNpjbRhlAmIKx0KkHetR9GQJ7kDmzWK0tLqII 6AOwHGh3A8a5ppSnE2CW6TcltJGDHyLhF+Entt0yMpiXkUxNKlskUiFSf3h3I8DtSmR4jdFMih7y wjBDhaAfbAABPU7eOZeKZqrapG+aV2zfVpBFLX6vJUxMegNa71zLBv3tMooy8DRWyiOj+pVVY/FU Dodh0pjHm1Bit4FjbmsdYStJEBBI67gHxy8C20Je8TkBoW9Qli0UnUlfAjxGWgsrS26kt5XYqDb3 Qqsmx4sB418csALIBBTyeiGgYgFqGoGzU6UPUfLJAMgg7kIG5KSxbsflvXwyYSFOSReC9tqK/Ujw B98IZBI9Sn4BmBowH45fjFoyGor9LBYLOwAPD4j7jvjk7nHxg0rPNIltydiZZD8K9lB6fh1yAG7k RFBDO4RFBNACPwyYDImubVs/JHcmhH2B3av9MJDjSym0UQKfrytyXfFsPvGFDuYU77U7401yptUj eQV25ChPuN8bIDQYi2g5VvhPSpFdumKR5Jhp7F5wyLxX4efhXxyqQbolNlb4iTuCfllUnJxABXAA Y0+/5jKgT1c8xA5brx8VRT2rkLFtoBIc3Ku3Q/eSMiTZFdPsTGNWD1V4+FAfbbKOIEX0cmq2aUqP jIqo298rMjWw9KBHe+rrhuMYUChbevfMbVZBGNE03YhZQ3MnYsKnbfNZlyEDvLkxiF6OEYLQED36 165gAE7syF6AnYbe1euWDbcoK9acvGnVcJs8kFeACRttXftglGhsi1vEsW4qQAN265T4hG6bU2Z6 fFQ06HoaZZRv3shTXrx0rv0pxrvX54N7pPAUxNI3NRuDSvUDxzpJYP5rzWPtO9pBeXYCvUGm/bKs cZXuWzPKBHKwVxoVKkAmtArd8ujIg+Xk48941e/ms+rqKcSOJpQN1B9jk45gWs4JD8fcqCgHGReQ 6r47Y7XcTSDy39Q+1viKAKQGI2PEg1X5bHJ79Q0RIifTKm19Va+sBQ9XFAevfK8mAdD8HY6fXE/V 82yqMvw7g71HfMOcDE0dnY45g7jqsPqqRT6K9KZbj1FCpNc9NGR4hsVomADFW4KB9g9qEmqt7ZnY 535uq1WiqyNlX1raUKrSFWK0Q8T1p3PbLqIdbwkISS2uIQHWRkf/AHYAfhrX9WSiQUghfb/WblRG UUTuaDiQAwrT4vDEkDdmD0ZTp11Dp3+j+gswChZHIqA56H55osmbjmZHly9zscWl9AN0UNzmmnKI g9WQ1ZQQB8O+46dMo34iK3Ln0BGzyCHMcivy2QAnY9fbKDPeiOGuX6mywQujn5H05BxAPGg/EjKh DdEooiQvGP30dX40icGlFB6kDvl0Md8mjnyKCuwjRcW23rXr03zdabHwm7aMsuiSO7h924igKjNi A4pLRTfkdtq9v8+uFiVtAAADRev0++FgXGpHGtR1B98LG0OeXxE1Ht1AxZbOqAp3+bdO+LJ3Ntg2 60PTtjSkrSY6qrOFZuik7kV7eOKi1jyt6ZVgWlT4qDYEHphTV+5tHfpKKMdyagnFhKO1hpnAJ67d 8LG1gmZpSvEhRuGJ3OFSG0YMASdyOhFDt1OLAlsoOVSNh8NO9D1p92KqMsojqG2WhNT2HTfFIvoj LeIzRINjT4l77dRkTsxJR6WZShFCdqnbuchxLSJ5wg8UqprTf+Xvt7YACmkRbNHyRX6MSBQn4vD5 YkMaT7Tr8UTgASteSA/sj/KPWvhmNlw82cZMis7+KVaOODtsUb3398108NbhJC6WzgY1i+CSteu3 9mVxteI9XLOstUkjUyA0HLpsOprkoTYyjSGvrCGWKSFgFViPToKEE9MycczbWUga3vIKweqxZNlJ JHIfq+WZYkGOxSrUJHjlaSPeJeIkQD4h8NCd9hvl0VCU3cXrIZLcjmTzKgkc1XevT4WXuMtie9mE AJIb+PlNIy3dQI5NirKNiCNtweuWcmXJKr0Tqqxy/wB3y2JFQwB7Hr7775ZFmEIZJF5Om6AdO9D1 yVJQc8wLllFEbcrkgGYCTaj+8kjiX9o7n8cyMe27Rm3ICaJGsVrFFTrux9hlJNlnCO6Ed+cpbspK r/HJVs2BC3LFiFUfETUfMHLIBx88tqTKS2EcaI4IlABII6fLKxK2mI73KzA7b0G2NN3iUacpqoJw FuBsLZB8JHbtkg0ZAoxlxuD9GSLjxtfEXJ41oD1/XkZBnCwnunW4jjMnjvt0zHkbLkRGyPXiTtWn evT2plZtysdV59e5U9WhXYmpofavTIcNt/icPJWU71pvlJxC7rdzIZ7FW6jc1CkcjQ098hlBIFGm eKQBO10rsoXYj5n3pgBoWylZK2RmRg4/u/65hZckom/4XJhEHbqtlkR/3VDyXevXMXOYzuHUNsAY +pQJYCjD7J+D2B/XmuIl1bhXRcvEdNiTueuRIoeYTvaJjCg0oGDGgJ2ymR7mJbVdzvuPxw8XctuZ mr0yyI4kHZcJ348CSY+oAPf5ZQdPZsLQ5qZIapHf9nCNtiyClxWlOI8aYK3Z2nRK8gGUMG2rTqev 351MZCQsF4XLhljO/JT+rozciPhJrSuxHt9OTvdjHJSzhKoBWjIwqefQUNMdizjOyqvAWNSapQEn qQaZEDh5c20aji2ly8/0OVJRvG3JK0Kj9WJl/ODIRv6D8FWMBJA4RabGhNCKHevzy2MdnFzTvnsW 5lZOcgqd/hXqPDceGGr2XHkIKGYKVaSMMhU/Cw2AHy+nCBex3cjxuE+ldFPyIEnU1HIHp9GY2XTb el2On1gJ9SqsaMrcaELtQdsp4eE/zS5kcnFfI7qDxvFQ9EHSg/h4ZmYst7Hm4+o00ZDyCMgkWZOL UDn4WX9kr17ZZyLpMuGUOaP8vWEMMzzTIzWwb4KCrcQT0zB1+bYR69WzTwJNhFXASOVzbjnGCSV+ ydx8XIHfvmAZk33D8F3ENx6uaxI4z/dhUrue4Bp1+nKjMGgDX3fsZEnq6S15Cp3YDY9dspy3RWM6 UVT04QH3RqgNT4hTtvlcBZ82UpWVd5GWAq7qyE1qeq/TmdhxcUtuYceRAKS6lIiuArkGm7Hf9Xvm 9xg1u4k5BK3UHp1O39cva7bYLwqzEuKggjbw2whiSsYt1Y/DUA4WsrWZQSB2B69vlhVRZVY7du3v 74tgLuTdDUj2P04KSaboe/Q137U6YWu0LLDHcShllHwAA07eG+FujkMRyRNRJyq1QB22IPiTgYAk bjm4KNgRSn2Nj0wtZJUHDGrKoPRgRWtOlK+GDh3u26OQcHCQPeoopDF2HxAhSK9Kg0/AZJhLuHJc DGX6VFaN2A2wtRRCBxGDTktATQd674CtqDEkseAaM0ovz9j88UhG6VcQ2nwxoDCSQBU1Ut1qMjMW gglXuZZGBMLUVqE06EjpQ4I02Y8drbS6kIKyDpsxpU0OSICZYJdEwsblEn9Nh6sbdQe3aor3GRmN ttiwjAlNNOW5YevAC1ujnnuSRvUcgDXKZ5I3wn6kcBiU+i1DnJzCgykHnQ1qvtv8sx56fbYoE96K d28qyL0oSd6nY9s1eQ2d+bMxpzvHMzJKCroaBvoB2xhuw5clKST/AHW6jnT7fY077Zk4hexYS70B c0r6cihkcABqfTvmUNmljuoymMtG9PiBUMTWo6hW/hl8G0RYzfSC3Zfi5I4DSoeoJOxoOpXvmTEW yASy9aKbi1uqrOpJeNDRWFftA1pXfY5bFkFFL1Li1+rzksV/uwRStSKg+4w8NFNUld8JLdygeorW v9csjuzjul7HYk/Tk2xC6bH9YleUn4OVFPsO+WTNbONEk2UXcOxYgHr9n2XIBviNkKRSqjqO2SU7 Jh5a0pL+89aYEwg1HvxO2V6jLwRcUR45s11S3spbbheopHRZOhFdqhvbbMHFI8wyyCjuxTUNIlsr gxSuBtWKX9lgem/jmdDIJC3HkKKXlmQlW6/ryymyGSlORgV5LWhPfEBkZ2FIni256nfJNPIo20g9 VwN+lTTfplUjTfCNp/bRiNCtak71ygtqvGnw7bEdG8famQlzcjDRHn+Nl8bdOQpIOvschIOTjkOd epUX7VCNya1r44DySPqojmqJX1Fb7/llGUEgU5eA0Ta5ixLUoRv9+YU5yMjRFfpcuMAALWhGbc15 03/lNMrECTv9X2MuKhty+1UkiNRQ/PxwZoUdlhLZQc1br8vDMPJKyW6IpeioYyx+Fxsv9uayYIk2 WvQkVjfZT/mMBF7hT3r6Cvw7jxyVlDZFDvsclGW3mxW8DuwG3ttiJgGjzS7hv4DLJxEvegGl3pNz p+1WnvTKPy8+LhrdPGKTCcb0Hc0Nf4UzohAcw8uM8htIcUVP1+DcWTktCR3Ip1y7HdWdi42bFAn0 fJERNG0YYHkp2HfJVu4m4KrBxNUH2u+3QHtgPeVtWMK15LQHsadzg8iyhOuSi8fxkj4DQ1Ipv8wc Iscm/wASM/q+a03Co4RwKE7NXcZPchrnhAOy4zRtGAAOVQQCKgiu+Ja+Gmnt4pFqV4uNgRtXviJE JE90MYnEg9ByCf5unyyZqQ9Qb4ZpQNhes0oU+tGVp+2u4+ZAymWEDlv5Oyxa8S+rZbGxhug8XxGR TTf4aj3yzHvGj0XXxBhxMw0mGOSCI8X9RSVj9Mj9nrUH6c1WoiPF75OJhmRDpSyWwIuJaFgUqAGo TTrvTMUjfzDmxy+kKLwsXFSCNh0p+rICQJ32l+ObMS2VliPNtt1/Z708MryA3XRgZbIKWFmAKkGO ppuT27g9MliAvdnxIW5m9KMKRWvXxrXN9hxDm4uSaS3cnOSrA7Deu53zNiHHJUQqdXYUAPwDrTJI UmkUuaElSa1OGmJKwsKU61w0tqLKpNa8W/ZOFALkIAJpQDr39sU7tijglTX5Eb4qVJrq3D+lI1Q4 pUbjfbrhpkIHmtgs4LdmANWcnY+A8PHG2U8pk3GiIo41AcmoJxYyJJb9SRm4M3GOtarsRX+mAsog VZWTNxTiWqteo64URiLQwIJ40IpX4jXsadD45IFE4US2jMzKuxYdQD0wsCj1tIkArMOYFSEBYVp3 7ZElhanJAz0cGjKAQfE18MbVdAIwR65A5VAI+0D7juMiU7rpHa0FVqFYV4EGm9OhPT5YObZjnRtD NeytI8yRuBGAGAU1NRUCnce+IHe7iPDMXE7oiznieH1uYJU1oTU7/stiQQaapgdRRDKvK8dvqSIL ZnWRFAk4MV2FQtabGgyrJ6d5Ou1Mt9mS6X5fitnYRtyC7qla0+YrmFqs0qBDTGXenKqr/BX94vY5 qieLySdkHIkwLFyFoaq3fJRNMtmrhzIiqWG/RhuK98z8IEg48zSELMf3U256V7Uy9rLGNYZDIRIp 4LX95sWG37Q7jLoOTCO2zFNRguEX1uYljViDKtCB8wOle+ZeOQ5JScuyMeQ4qTVT/Kf6HL0rJw7R +oqFeO3LtUdcISEC0vqLxbdgOvjk6ZUgdUPpQBBXnJ8K098nDcsckqHvRNlEtrp3pkDk4IB+WRmb ksIUAO5D7Fiw6HYH2GSbAhbqUQsHPcFafRk4C2vLLh3ZN5Gu1SKWGVhtvEe3jmLrIW42KZiU8v54 pDCZpQiFgCjV4kg7EVHX55RjjXJlI3uVPXXt47VbdSeU392rAlSfpHw5PFd2wmkIFgwFvcgx3AFG k+fSozIuXMcmFDkUuuYTBJwHbof2T4EHLYm0XSDoC23UZNinGkCsg617Edq5j5HKxbJxUKpJPGm2 58cqbSrRkVoK8hvTschJuxEfFWUA0JFeO9PfKy5YN8+S/hSndD9+R4966p8Ohd7X8XbLSvyr02xl uGUDRV441GxrQkVFema6OEb2ObspTVAFUOevKgWp6b+2CUaOxXdDTS0JUGntmvzZ+GwXJhC91Dvu Nu2YIyCTeY0qeHc9slPn5MQrVBAG1R37nMciihdxdV5dPA+2AEWtqgYFaE1J6HCRvsxaA7VqK0wS ChcUr3Br8u+INLbVJacd69K5Z4sq57Ioc0VI7jlxNV7sQNvFaDOljj23eSnliTQUEkAorGpFaA/r yyUWkBcsrgBkorjqBsD8xiAx26oyC6VwEkHF6H4T0JAwGNbsDE9EYG3rT4DsD9Hji1t1UDYnwoR7 41a7qbInLcDenInetd6ZExJ5NsMvCUK8DwuxAIIH2e3+e+TjKxu2ExP0/JUS5hMdWO7EVUe3tgES CxmB0VhGaq+5pvxBHh3xLWCgriafkVArRasKE075bEBsjEnkuto5JZrehoJAwBNK8iR1yJIjbnEn wK86Z1p0EtpaJAiBp5E5LI32QCaksDmknIykZVz+5rjEVz2DuIaIo9TLMS8hHWnUEHwygiw33Rsc g76r1cx8nAopNdxT+GDeqO6+J0t26EMAWIWpFKn5ZEju5Iu0suoomYyw03+2On4ZlacUfUNmziNU kF+0hZ2YHn04+AU+3zzd4ogCg4s5WlbMTVSajruemX01cSyWPjsTUDYb4QUlbWu1AB0phYErXou9 Nh/HChQJoa9R/bhZLgQKhhXsP6YFtBUkhkEqHlGKCn9ck3cQkK6q3pW80SsVFF606+JwMeIh0kiU BUqXoVDd6fLGlHm0p4rXkH4bmp33PTfrkT3d7dCNkyGwDjIoqD8J6+3XJBrlEnpVqUkpB3Wh7k+x wojGju6OP1/s9RX94QR9B+ePJhI7opRFDCsKkVYhpyNq+AHiBiwVUUcQvfsfHIkqA66ZVUKhDEU4 kbbn+mQ4mzwyiv0PAYEaSrGQcuX2aEUr1rkYyJTW9BHxxxqgiAJi4gHkeQBqN9++3XFRDZRSzjgn JoOJPERHoQe2JLlY6HL8eatLoFnNO7KqozAc+K1c1B7fZ2bDGSMmplAVbWnaTrXl24TVQge1jNLj 0ia+mdiSh/WMhnzQkOA9fvcTaW4ei2N9aXdst3aFWDjY7Elfx3zSZoyiaKCFSqzhiDRlNeVNxTtt 1ysASHmp2UWuWDrDcEUU1B/mB6HLcZA2KDHqFG7g9Mng1E5VKnc/MZkRhKPqDXxA7FQcxywtyFeP 2gOo91y+M+LcNchWyQajaLMGq3UEIw6HsA1cuiab8cmJahaz2UrvCRyj+GQbMrg9nHce+ZcZA82y rCUXQiqxjUqqbyW9alN+qeK5dEsaQEbem3FqiJjvUHoPD5V3yxkh7qEF6qOJ7U7/ACyQKQUtm53F 2gI+GPb6TlkdgxlHcIqVS7pEvU0XIhsXSwKkjIBRV2C/IUxBUFSs9HOpah6L1EaDduoHc4ZZeCNu Lm9UqTj9FNpkQj4BizUX+aniKZSMnGbaSKZFBatOkcrIJIivH03NW2HX+zMcyptCnq8KCMScfgFR Jty4jtSvTDjKJBJZtNjvDziURT9mY0Rqf5R+yfnmQJ8LWRaAmQgNFKvGVdirbHLAeoYJd9XINR0r ue9cs4kiKb6WhjarbqO4yiZtyoCk3MSMpDCqsKH+uVWyK5UQjjT2B7ZGRIcjBGEtjzXgEFlFaHp4 1wA2GzJDhNK604+/h0+/KzdtsZCvNphsQPAkDtXK8xIiSObdhA4h3K0YYwhjShHX5ZgwnLwuI83O kRx0pSM0hJpxKmg965hZicn9EhyIER81syk0A3AFDmNnHEKbcZrdS4MaHqaZiQxENxkFVB0FRk5y pguWlakfd3ykjqqqjLT4q0wcJYlUTgHDAk07HE7hBXhldmPGgJwAbMeS4KAQKf2DAUEr6JypXbr3 r44N0WVWZVb94rV6kMDvXOwro8TxEbIe49QsPVA4n9sjr9OSgAE+5pY1oQDTsQd9+tcJiVjPvDnj cLVlIBPwkbVxBBZjyRKSTQsvoji3Wg6EHr1wcIPNlMxluBSJjuFYilNusZ33p1GDh72ginM1dxUA 7Hj26nLAGKkshMjFDVVGy9xv4YTHbdQsa1WVaxn05Nya+IOw+eR3HmGwTXJc8AiyikqAKP8AK6j9 WDh+SSO5VYCORywAXZVav2fb78rmCYmnL0U4iYtdb+q8nrOKIlBHSgoPE/dglQjTdqZgmh37s2IL WsAfkZ/hZmUmgIFQN/CuaaZA5NeMlV4DiGYmoO7n322GVp4lxgm2Qk9ax+GIiw4gh5pQjjmPTuAD yQ9JAo3K++XjEZBRJL72KOZCYWKyvuQdjWmX4CYHfkzNlit6LlHMc32upXvSubaFHcNEiUAQRWgA B698tYqfiOo+j78KtAbYUKEsTtJG4agU7jfvhZCW1NBQHr1J2xQh15xuQzc0Y1B3OFnIg8lXlHU7 9NifH54GO7hGsZqlQTvw7V9sbZKTQsXLSbfyt7VocU2pM8CqY3WrMQY5B4A9sSDbkwPpPe04njYy KBMjdSfiwgMJTE+exV7eSqkMnBwBt2pi48477btyAqPhNB4YsQpxyAjcdNqd6D/bwMiETG3wcaGt agjw6UyuRbYRtFWUSI7fWY+RqAhbcjpTbIJycqCZPIXIqA0aAIoXpxJ7ffhAaIHdCXnqRvwidgxN Qp3rTvypkhu52ONbhW0lVvC8iMOVA0kbH4W7V36ZGe2zMyAo9E0iklt5+LbmPp2r8j3wBw81SGye 2ephoPicLCV4uWAbY9qdspyYRLo4okp6bYjR7m6W2LiwlKskdRQFhUlT2B6Zp5ZTM8J+qO19/vcs iwCm0iCaEPDKylDxJpVh2oaZXTG65txyW95D9XPwsrEBRsdh9oZk49zu1yuO6G+KNmVj6iKdpfGv Y++ZcJGBotUgJbjmpyQUIkjI334nxydb7MSdkHMKluQ2faRaf8MMmsCgn0+2nUwTIFcjlDNT4iDv v4+4yVkNwydUmu/J8LTxLO3oq28VygND7fT75aM5DMTiRsxzWPLt1p0jR3K8oK8o5k7VNa+3yzJx 5hL3pBBDH76KS25fEHH7Ljpvl4laQgLeNlXkT7n3JyxknOhwQBLi4mUfCRHG7VopYHkdvnkJ9zjZ JniXahFCjtxq9Kc6/wAwArt0+WCJLYCqeWJJoLia2nZRIxLqo3PXxyGoAIBDTGVklM9Wd2uYEloU qCyr1G53rSvTKsQ2LCfNPXT00+Hfaop3FO+UA2W+vTaX6dfNfrJzhaJlPFkchg3yy2ceHqwBtbPp qiNvT/uAG9S36Hf+Vv2cImghItWtFBibhyicUd6bp/su/tmRjkwlFDx6exoCvNDTjJ8tqYTNnGKY RWyxrXw+7IXbarRmvwipG5AH9MBSASdly7KCO3tkT3NgieY3pUUq1Nup3PzOQlHq5GLUXUSFxlUM VCj7VA48fE5qY648dH6XcS0g4bGxch/fAAfD3zZT+l12GxOq2RoUcApPQAUzFxihRczILNhTYHj8 VKj7VOvXbMbLE1cm6BBNBDuQoJU1Ar79M1eSXDuN3LiL2LloxB+yadMqhK9+rMindaGn0/TlZHFy TyVFUsR3boBlZ22QV4Xi1CPhHUdMJNhivTYgofo8MiRalcamh9vfrjyYrt6nt44QqpyHGlRy6e+D h3YtzwvCwaPc96bqfozrIk1v+15GWWGTmKK9LyOdVSRaKPtoaD7u2QljI3DVwVyUW4pI1CWQAbnt X9eXY5Gt0EW3HLMCySKCpNQ1Nip8MuMQdw1clf0/UPJCa8a1PQeI2yiVxcnDKJ2l+Pe2sh9QGWMM 67kk0B/riKI2KZ4yCrBeS8kYljQLQbAHsR12wCdc+TQY2h5UcfD9lj0BOx32Iy8G2DYnoSZARQ05 UIoTTr44aVEqyOiK4Ugk0fr07b5UYm7DIFubk0KI68eVSx9q0HTw7YICmwHdPNB017qQ3UqD04WA VBTiX7cqdSMwtVk4RQ6s4kE2WSyUVTIADQ0etVoR33zXGO7ba40kBEbcmpXi21R3G2SMN2IlSXLq KGSSyuAYmRv3TGvSuwr05DMk4SIgxXqoNfQgyW2o1BI/cz9VIIoN+x3yyGE3xR+IUlLb+4uYIXDf GuyrOK9qbVHfMmGOJP6E8WzHruUzSVYkhBQe4B/tzLiKYE2gn2oQRkwilNe+/ffvtklcq1BA2Hhi hRlIKmhIIO4G9QBizAQ0d0kkjIqkMnfalB1wtksRAtqZGkUoH4mtajavt+OKIkA2pBnWKspCP0Hh Wm1ffCk7nZcsqJWUgq67NXc09saXfkrMpf415EgkqB9nh/XK7N+TaODg/pKU0W3qKRxNajr+GWW0 wPSlkbUFRXlUdxTjvWo8cd2RMa81YQoJC7VqaAD8cDDiJCyWpBA2O368UAbqUJC1qu5pxO9B92RL dYRcRMh5AcggJp0712yss4Ckys4zLIX5ExIaOTsDQd6eGVmVbIlG93GVjNIUblU1iNNj93TLq2a8 Qsuu/UeJY6qJh8aj7XXrvgBpzIQVrRSYY9QWsyk/v6faUp0NB1I7+2J50xMq2TqGeG55iT+7PxRs PD5jfGnXZdiEQ9q/FzbK3wrV0YghuP8ADKTMx58vuYiijtLvYXj4Tlmhkjj5AjZeNRTNHn2yy/rO WAeEEJglrdW1Zrb97GKVTqfoPfJCd8+fe1Eg7O4R3bloQYLxOqjYH55bGwPJiTXPkt+sBw9tOnGZ P2WHX3GZUd6tqIrcIeQT25LfaQ7iu9MsoNV2sbjOgXZZTsCPHJoukJNG1uRDOaxsf3UqndWpWmEN vPcc1dZR6f1S6pwcHhJWoPgPbHzYV1CX3kZ4G0u15RNUJKRUMN8LkYje4+TzfzVYRwymOBqxA/CD 3FczcOS+bfw7Wkir4CtNgPf2zLQU3adrWyisOIjIo87VryY775CrNuLEGRQmqXaJFLKpJelUoa7k 0HhXDCO7bLaKZaCbS8kW5eFoNQUDkJKjkfEDvlOaxtdxaIUUS889zqMcXp8jA3xjoKHqfoyIAEVP NkcgZ0qgBpTY5jDm27rEjXgOXwjYgdwcJLIAU7grAj7Sn9sd8bYkKE2nxSKQKLyqSvVST3plgmwQ CWJto2UHkh3ofwyfFbIIdod2G/EHfJW3RpopTp0rt40xBZTjIbuoKkHYdicLAbKqEbggb+PX6MiW yJ8laiH46fEep7fSMwTo48Vh2cdeREcS1aeopB6eHv8A7WGeThBDdGAmRJFcgK+wrT6cqM4mJIZg G1J1SnLcF/4VpX78x8sriAW2EQCSFJEUbeO30Zr/AA4jk5BmSvCAb5UYVuE8VrSnEjfr3GY8ZG2y 1w679TtTDV8ubG1YpQAk7kV+jK+SLaQBiaHbvTD5pKrUDavTAWC5RyYk7UGw8cjyQXeg/XvTp38c l4i2FekjkhhWm6Ed69q51YkIvEyrmhXj5UAoV7qete2X7IshVUKzBD2IADdmB2yqUa3ZCarBbSKf gIYAVYGu3b78eNJpekXEVBKsDVgfu3GWcVtZjS9o2koz7FhXpsa96bU3yHDXJsjlIFHcNKUjAB+B 6fapyBp39jkZAlelhdIshG4Vq0p0I8cMZIoFQeJZDxQlj1UdwD4E5aJ97GUSGoomSRY6lk8SKb+G /SmSJtACbWdhJf3hhgm9IRLyMh69d6D6cp5BnbLrWSG1jNqYz+7ADPUnkxpVienXMGWn4/U2cdOk v0ZCQP3g2cAc+NR1K91PtlQ0srtlxhBkzxKXG8PVZItxGx3qK9AT+ycyyI/Hz6sAgLh2uWjhlcSO /wASTAUKkDqR26ZKIEbIZ2g5JnZBa3Qrw/uqfaBLUqD4bZaIAGx1Y8SGa6MMJjloUYsVINRXp8u2 TMbKg0lVwV9Uld0yyKlBvUqN8mm1iOeh+Y+nCq+vTuOm2KhRT0lUhFKVY0rtU9MDZK73UbhiqM8S cm2otKVphDIDvU1Z5IwzD02I7YUEUVrRic+k+wFAj16nHkgFYIHgAjdiWXbj89x9GN2zO6r6ilCC TTod6GmFhR5hcil2Zh8KHYLvvUb4F4q3HNa8fqOq/ZatAPCvhkmFqk/7tREDVQD8XevXl/DIc1CE kkXiFANeoP6sWdLSwFN6itK9eh7fLAWQ3R8EckMXJ3oxqQTQUFKihyot99ERAheNnLUYkmpNOvgB 3yA5py7BUsoInn9IzshNdyAwG9RXp9OZJGzhjJw7gK9paTXMktq8R+sn4owW4g/6pP8ANlctt3N/ MgAFEWelXsE8npwnjy4lWqCnLdifbImUeG7XJq72ATfStPIUqgJaE8iu3Xfp86ZHJkDrZzJKaS2/ qfvLajM5USkNxrUEmldq0GY08lCidlhzSwXN1p87LNAUjuF+OM7ru7fEp3zDnATmeGq2cqP0gp9Y XbQRBkYy2bgHxKGnTKjHejzYSFom8i9al5aH94tWqNqge+Tga2PJrvoVGVxfCN6cJ1NKjqD0+7Lw KYE0oyzlapIKSfZqehr3y6JaSEHJbSeoRbtWhB49KfLLUiXe1MyzQukilZaVHiPfEWmq5KUKepGI LihrsprsO1QR3wkJlKjYU5awo1rdkvFQ+jJ4HHnuGyMgTY5vPvMCGSWRjU+mKCveu+ZGn5uxy1wh KtFtxJfpyUMsFZZamg22FTmbM7OLI7K2uwxlnaNCoU7A+GDGWMCl+ipHNqUaPR1VSxU77jphzGo2 shcgGZlVeMBow6jop2p7g70Oa6BN82zLEDakBaWc1vqBuQr/AFZiQeQqy9qnvTMqUgY11cMCjbJI KE1p8LdGrtTMQt43LTIwBqa9T07VxEmXCXRRqGIG1BSlPDwwWyACmYyduVBXcHev0ZPiYxhahLB6 YJI5A7HtTepNBkoztMsVJdJE4dq1Pt4Uy4FgB0WUqQKUJ3xbomzRcyFt+47eNcANNk9+SokYrQ18 CMBKRD7FzA8TTr2rkbZyFiuqy3Tmx7HuD0r1GVagAinJ0gIRMqFlofhAAqR1zWeGQTu54KgzKSKb Fdj3GRnkifItsYkLDIta/h75izkBu2RiW1bkwFfmMxTOzs2cNBUG618OhyMgCx5LgCdl+nIR2NlS VyDbqaeOGZHRDgo/r9GAJbUciDSuABSqbgLTYjvgDFf6i06mnh9ONIpfI7q43PMD4CNjTsKZ18Yg jyeGCxOLb1rtQCmSqlA2bWIBm/Zj+GntQdskqKgJAr0qwNe9B+vKpwBSJUrKxdWLHZTXfY9CetN8 rqim7bkhqV9N/iO3pnuSegyUMneGNKRoqlJ14k7b9NjQfjk6vcKC0sbwisZrH/leH+TkefNnYPku QI7812YfaToDQd8SNmcJ8J35NghuLKKcm4yV3I9/fDA9E5IfxDkU48vuBqLH0y9VfcAVXYAffQ5V lmIiyWMY3snE17NHG3NSJXYngKbrWlfltksZjIWOTGUCCh+XE8uVGZao3eh8B/DLCxalnTcTh4nI qkooAxOxBA+17VyuULZxkgJZYGZqx8J6Al0b4SwyQge/ZlxICe5L1WXqN1Pv88sAVAz3EvxJL8l9 t+uSASEA8pK0BqK7+4rk6VQLUO21cklcEotabkHFQpIr+nxLBjT4SRQV98S2CralNVUc+BFOvxdc DOI+KHuGYSL8RpuKgVrtkgkclJpUVKEU4dadcKmNqaMwk8Y2X5UOJY9ESeLcWkJZlHwUO3ywLa0l oxs+5qDTcdN9j7bZGhIbhu4zjNRNrY2DoFG7Kfh8T2ybQdkb+5qFrWQAhpOwqACAe/hXIFgosypV eooAe1O+/wBGNsgEtvXb1CI41ZAA0hJFACfww2zEVK1WaaQu0g4BqBAQdq7EkV64CnYJw3JljhBq G2+W22/Y+GVFsgbR1vbyxsFnXmaAAmp/4LAItM89ikRLaNbSkmq7B4zsxIrSlAcsErDVHdM4QLaa F5jUGhhlT4Tz4kgAHo3X2yucRIMjEx9yPvfMFrpaGe/ikjaoMVyF5xOzbhHcfZrWmYwwylt8x+pH PkkcnnyG01JS8TQqWUkSAoaNvX5cemZI01xa+C02vdQtAj6nZOr2zqDPGRVChoK7E0IrU5QMd+k8 0xsbrItahdvSl5NA7B7OR/jWQfZKA77DMTUaY2COY5uRil37WmcLS2M9VWkJWrxHpT28Rh2yCjzY yj1CYygxql1aOWSTcw1716DKgOhYXa29YGD6/bMfWUfvUG426in05OOx4TyawoW1wlwpieoI3Kts foy7cMJxpYY3hBYf3J/bFaj50ywSYHda6/WSyJRJ1aiNXxFcnxULbMcbUlYwkJcJxjJBdT2J22P7 O+HnyZ0RzGy27ljCSwvxlVlLht6hR3/twRHVhONcnnet1WzeRhR53ovuBtX7hmbhHqcziuIU9DjW LT7glo1mudgjrVilNuPtluQ2WqaG1RgsJVX5OFpL3rv0r9GSgmKB8vxtHfyH0hxI3krWm9cc5uLA n1stjoQN+o3P6s14FOSTxI+DioNeu1T47YJEsREDmvji9Nyy1CHrH4H2w8VtNEG1ejNTuvc0yBFN 0ZW6Oh3Io1aAjwxFpkHFASxpv2r45GUqZ4woTFQAGGzVq36shjkW8xBUJLMHcnrtmTHI0SxoJrVl ehB8ajLhNRHuXLH2pv165EltjHZUMdK7bbYLZAIaXhUgGpXt4V98qx6mMiQOjdk0xAB73RvwZa7s 3TMbLno1+Kc7HjoWryNzR0AoSBQnpvkDkMwQsY8JtL2VkcVNaDYjNVkiRJzoEELa1YM+/anhmOZk n1BtqhsiIgu1d/bL4CPVpmSq9wCPnlWUWVC4VpSlchLeghdtvT7sgR0VwIA9jkgaVpdj1ORPklVJ O2/Xb6MiGLt+lO30Uw0qIH7yNZJaByAC9R8QPQgDvnVwsGhyeJyEBDqrEck2r18dqZlNZRED7kDr /n2yJCLVRt8ajcV6b/gMCrlm/eUJACknka0p0FMTFUQPTegP2qVJ6d+g8cpMSEhRkjdxQ/Ep3P8A Nk4zA8lpaBLHVDV0XqD1+jJmjuq11NeamoIrUdfcEYGQO1Im2ZXBAp6jDx6+GVybIdyN8uzzQ6tK I6+mUBYVoOtaHBmgJR3Yg0ycSyPFzejvyojfykgiv05jxxxEqApeM0gn9N3KhQGjFGRh3p29x+OZ IBY2g7jiEZlPFh8LQvv91emTUJa8i8j04mpX2wsqQN/MOKIR+8ruelMIZAJXPdFhv2JrlgDOkMZq qNzXJUhwqzVJqfHFV6mmzEU2pXxxKQhXulkkESgxuGOzCtePXFyBioXzCryVo6GoJ8e/f9eBA2Uf UK7ON6EE9vbJJpDTxl5lUKFqPt9sIUSoNpDJTf5UJ3piUWFdERvs/Cx6NgYXTgC54KpLMdh3J9sL E7Klva+iC2/x7sKkEHIk2zlINzRkxH09iR9r2rQ0wIAQOovLDxmUhioWOJJK8A7ftfMDGmzGRyQV qlyGZp5hJGwPKPiFbam+xPfJUmRHQI/SYkuXMkiiKhKh1AUHfj8XvXpkSWmezJNIsomuZuqmNeQQ 7qwOxbfftlEjuzkSICuqNQW6ScmNeR24CoHY/wCZw24xQUt4izMkqc4dyzjcqKkVoOtKZYI9Q3Yg OfcjLaCOd47bk7C4CmBwfhNPHuhOQOws9GzNIS5H4Kut6bq9lDDa2kjT+k5YW0/GWOaMgn0+TUBA 8CK/PKsOSMjf4DVWzGJL26trgfU1ezufVYpotxREZSKf6PIar32WtMzAAee/mwI71unvNcXj22nO 2lahb/HeabdArC/xHlxG9A3cLtjMACzuO9B5KkN01vczW7wvCwAkuNPDF1RqUE9s/wC0hruuQMAd /t/WkS6Mz8u6yLqwit7hluEccbe5AK1I24tXoR1zA1Gm3sbIE6TG1dbU+rUSQNXnGTuu9K07ZUYm Wx5rIjouueDwevacuDn98gqABWorjAUeGXwY23AIbwMkikSK9EmGxptQHGQ4D5LvS6SKe3LRji6E fsn+GWCmpCUIIdSWpvID1XwYeI8cssNsR1HRYwnjQyVW5gcUZWoXNB+NMRR25FyCTXeEr1R1i0+S RP7yVeKVIJq+1O9csid/JoA4jQYhrCvf6raaTCpJiUJIwFaEjk5/2IzLxnhiZFyBGtkZqrxx3C28 acI4SBFVQKFQFrXwwY9xbAsavpgqScmqKFv8qu+ZMQkbI7Q7fhbLMyUaQAkHuO2Y2olvSMUbHEU6 t4lB5MxNTUA/s/LMeUnIhAc0fEQWFR0H2srvZlIWUWlab9O30ZTZvZBjtuvUIrbGleo7dclx2GAh TfEMu3UYg9Sz6bLN2XrUDYdsZ7JgbWsF6d6VyhuC1gpJUH7PUfPGUpDccmXvWuibhtqfwyUNSF4E OYYyTQggZeM1nZmIbbrGPDly6qK0yOTMBbZjxE0oNwcVUVqux7fLBDKJbgNxgRsShYDybsQDtXt/ tZiiZnImX9jkUANkY8QaKlasKGoy0wuNW1iW6Cl5Gg6U2r4U9s1+WRP45OXClNqsxr9J6b5h5bJJ LfHYKiBhUjpkRlo7IIViBTff2yUmAbVugHTscgApX0PXp2rgjzQt+e3viUtp8PXp1wXaldWu46e2 A7odtxrXen+ZxvdXKr27hD8cQNRTffrtXOwBsWHhyRLZXhniFNv9VtqGn8a5KiWsggq/pmtO56UP ieoxElaqY/hG6jow/jk+aG0uVZttq7b7r4nAYrarJRlPD4WArw7beGQCUMLmcyMCDxBVVpvud8gT vTlDEOC0cG5gI6/FuSwxHeHHQ87GNwV+E+O+Wc1DdqayBhUFftDtX+3IyGzIFHaE7vrEnAlTx+gl fHb3yM+QWXJk6PEvwPHVZAC0a+3dPk2UmN79WIKEug3qsxBkL7CRBRgRTcrvlseSoG+lkKgyLz7r OO/tkgyCS3lw8aqxpQAnbpkgGYFpPfXpabmaVJ3UZbENkYoSSSvKhNK7V2yQUuSp47dfDwwoVVNO IPfoPwOKKaYggIw5KTWnhQ1FcBboDubkdSoY0U7gE77D5YGXDuh3ZUWikqCaLXeh8cLOO/NdxHGg PKu5FKgYsShy0gHwtWm1O4yQYFWQcqM/wtTc9BXFhxKhjYgAHiQa17b4FElWMyetFy33FCNtyeuK NqbmLK8kYNWDUAG3Q12+WRUIa6aYxB03aB2MqpTdT7DGmyB3S+e6hnaVeXJSqugFSQCa7LTqD3wg M+EBDQJHFIHhD71KlhWgbaij3J3wMpHbdkWjytE8xeMSKGHxElWAK12AB/28MnFkyGxmghkdkAE0 gAHI718Knp8sokEEnkj7iK0mtHZE5tGpkl9IhX2FTUdfte2Yss9Gh9R2DbHF1OwYWJmmlMzJ6adQ DuoHav8ArZsoihV2yIA8mZeVLoqJ7MQhFk+JSQDSmx5HrTwzW9oYyQJg/BECLoquqXF5bpMscLXl tGqmTgVEsbcvtDuadsjpgJgH6T97LIa9zz7U9ZtNal+qyN9UnR+Jkkqsbsx+GQod42Hcjvm2hiMB fNo35pZqGry3M0UF5G6a/aNS11GB6iRhsPmGpuMsjADcfSejHon0lnq97PFLxSDVLKjSWbH4Xp9r 03HRXB6dsx+KMdv4SjoyzQbfT71JjpDrBfAD65p05+JJEAPOMnpU/QcxsszE+rl0LBlUS2VzCZDE qXIAWcDZgR1O3jmESR7lQ31H6vG0kJ9S3FPWhOxArXbDKd8/mmKOOnafcW6zW6FNvtISSP8AYnrT KJZJA0WYNKIhZFEcrCRafu5h0p4EHvl+OdhjIC0FLxWZQzgOQTFMv2DX9l6dMsG7KuH9aCuYOUuw +rgkOBXiCfEV6DLonbvRKdJBq9wn6UgtmX044FMkm4IqlGrX3GWAbNunjsZdUh8rzSPqOoaoxMak MiSDfi7tXc/hmTljsIpkaUGvuXMSNzdm2BG253HyJyYihKb6EScIYz6jSNQpuSKnxr88tia3RI7J 7CoSFIwDxQBRWvbbMDnJuO0KRsTkqCRWlfo7ZCYbcRFIqNqDfceI9srIZWiI5SaCvvkKBCyBBRCN t/HKbpNL1p8RpTpQ98kJEjdiRutJ5D3r8xjON8kgqbDx/wBvKjYbA1Q+G/fKjkLJbM1V4n7XQexO U+YbIc0LaijNU1APU1/jkoZCC35TsFZoY2epoSRT6MybjI2wjMgUhWt446gU+XgMsxxgNg2HJI7q EUY5kqwI/ZH4ZTPeyD7m29lWX1BEzU5UGw71GRM5cBoXSYVxBBuHZK8aNStPntmLISlG63cqNA89 lJValCOmY5Eq5bNti1SNdq9vfKhHqVkVZTUe2JkSxpsgfLCSTugbOr1p18MrtNNB6/a8Powk2tNj 5k/0yAS4UFB+IyRCruQrSp41rX+OQpjSlBcAFVcFo16/2Z2hB6PFGCPb0V4yJ8KSV+LZqeII775V Ek8+YRTamuwIBHTidjQ12J/jlol3sZRrkiOcbHjTgabV/phohrUpICu6ihJ7dPHCJIpTEjow3Pw7 gnwyWyFaK5iOwURsfhoRUb77HKZ4rbozICJ9UGqy0CqAeY7V+WREa5MFsqB6gkNy25djkgUrbcCE s8v93QEV6+4r3xlukJr5bq1xNKVosaULEfCWeppXIZEzTspGAQaNVQ8UY2YU2IO/bKwWClItSCXo 5BMbE7MPA5MJSi7nXdUFKVMiE7AU6j7smGbGb+6VUbgxCsBxHXLQG2ASWWWpLmu3Y+/jlgDbS9AS vIUp1/z+WFrKJiUHfuAOvfAxXstHqGNG6L1pTvtgtnELJ4+a1VvTcDrXxwOTilXPkhXDlwS55A0Z R0NMkGRKpF8QJNNugOJaiGpTJGheM7jELz5rEZfTUhPj6FadzhYSaUUVeXT4R8e5+k/PJNatHMFl dTWlK1O4r0wUhER8GZWFNiGHjgKFGUKWahPBi1fHi1d/HAzCERIVs7hA3FBHSr7GoHWuJZjcrbGS 3AS3aVASisrP1cAbnlQAb9q4VnupX+oRRM6W0QlCk8pC1VX2BHWnemEbsRE9UVpOsWx9JbhniaSp d6ErVf2eQrQ7bZCYK8FpretbXWoRPE0c8RjLyD7X2kqKf5Sldz9GURJtsMRGHna+wa4ajhyFkJog Y8QR/MD2PvhjjjE3W6OOUvSSryRo6qsb+nw2YMBUAb18Nzkrcyr25pjYajdWc9vcMqyQyU5yoa7d N1PTbbwwSxiUTFwckQDY6Mk1+xF3As8H7q4cfCxJUMOvFiO2afTZvCmYy5MhDiGzzy88luNVitb+ MJp12ryAk/F6yCpijn3KBlG1c3g1keAyB5fd7mnhN11RNn5OsIovSvALm2YkLcFQlxGDuOZX7XGn Wm2US1t8tifkW2WKrtR1LS/MGmj1k56hYooFvfxkfWoAd+EgFPUTbfLceSEtjtLu6Fx5DuZVbWFh rum2muafS31eHZpo9mDr1Rh3Q+GYsshxyMJbxYJ2kn6QhF1B+51CI8XB2BYbFfl4HKT6TR+kqiUu XckqCsyD95C3cV3GRnEKEZCFP7+0AjbpJCdgT/A5jSiWd96y8ZGHIAMpHJlp1+7vtmThrhtieaWC BIVF1GeURqWhbpTwHvlgJ5Fn025dyhLdrEHDIHs5KkL1oKdN+m+WRHXqwIs0Hm+t6hAz6tJbkhAy 28ZJr8J2O59sy8UNxbn8oAIry7cwReXo7dkBDFjKTQfE9SpJPtk8oPFbjS5pVqctvEIkEZqPt7UN D16daZbAFIUdMSGe6aYr8MKDgD/MxNK/LBlJEUVcqTLkePEAmu1QK7UzFiG3Kb2CLhWiAnavv1oM qMt3KjH0qqEgiuwA/HFjyVo2PL7/AMcBDIIxSCKqOvjmPOLMKgZtt67U2yFEMaDuQDKO3QV9ssiL YS2d1rU7+OY8iDzZhYhAY1r/ALWY8jWzZVr0VWJ3oCNsrtNtLECCyk77VPXbbIEs7alg+DpSuwPQ Y8dJid0K8QUHmNyKV708DmRiyAnfqzMj0Q0UKh+goNq+3hkxTZxmkQOBVgNtqVHbL8URLYdWuUiN 0Dcrxk26d9+vhmPnHBkqj325eGfFC1B+PIL7VJGY+WUQaB6OREGrXoOo/wA98xgQWRVAvwmn3ZGQ UFaNtz26VyPRLVfir9IyJpK7kOvQnoMBGyKctNwTQitCB1OKXKC1SO3U42guqvKlN+lcCVqL6YIc cl36fLqM7K7eQG2x3C8o6b1qo2269K7jDbWYdRuFRZW5VVqE7EfRQnBTFEIyMCJiQVI4levz28Me IjkxnjREc5UBJB6kRO0oHbfr4YSL3HNoOy25tzQunxKDWncD6MYz70UhhxaoFK1pRhQfdk0kKiyF KqCVJ24nocSLVdDzZ0UAqQRyTsa5GQZAopLVtSu1giPFQaKx2XkBWo+WQ4uEM+QZjp+m2VnCbW2T jEdpKmpY0r8R699sonK2u7WpCqTHgxZlA4+oKqVcUozde2xwWlA3LQqG9EcUr++tq1oR3U++TCUj 1S+haNlNHjK1EigBht0Iy2IZxDELmQF2oDxrVfcEZeA5I5KDkuArAkEeGSCmSJiUqoFBXriWq0TF RQzsQAANyaAbZEqBewVPh9OvIIpGx9ycDZH3IeU7cuvgB1rhbQhOfqANQhS3wj8KYWXJWFBUg8VI 6ntgUuLAtTeo+39HSnzwhrkpSIGYGtG33Gxrkgw4qK4BGorsOlSPHFrU5Kll7KD0GwNcLKJq3RO0 cdY2DBjx4jqB2O2Ap5lUWVWFab91Pv4fTgWqKy4T4Nl5VXi3y3+0MQtrUjDW5tpiq8UPBwvKq0rw PfEqCoxaUsEDBBsx/YHJRUgfF4YgqTuiDaQxjY8KVYFSaeFSemNotF2tmvrrMeSq1AR0HHpUVPfK yglNYUS1egNUZSU7/fgO4bsXrNFBNPDKSIq0H2eRoUNem3Ue+Hk53D81fSZ2hujHcqTC+zV3pXuv hTLDRGzr8sJDmz3RbszQR2U9WZBRZeoYb0r75pddp9+MMYSpBapYG4rYuWIDgxsWpQj7JB7EZhYJ mJuPx9zmiQIsqdtb3F88kYZYLyyWjk/t17/6pzLlIQNjeB+xx5naj9TaTtbyGKSMKWIEik1AJ68D /XLB69wXFnstntlsJzq2lUMcord2a9JFH7S0P2h+OXA8Q4ZfAtduaaUmPVNPrNEx/wBIgB4tQbbV 7+OSAH0yQU5ju7e7tknibkDuCPtLU04n5ZDwyEWujmKOXPVtn9/A5EDdNueWTl64o38y+PvTLOGu SqLysBI8AEkLKfVhbqG+WQq22JCVajWLSJJI25QopLq1KjLhz35rAA5BTyO9ZnmitWIDXM3J27bn j93XNpiG19wcnJLdONVsPSjVLR+cQIWpoOoB+nIwlfNpB70Ct4rShbkD1EFQ43PL+3JV3MqTCzQr bIduUjGRtqGp7ZRmO6MYs2roe3alMotyeE8wrxsQR4Hah65VIW5UCAEUgDNTqOgA61wXTXKO6stS RUUptv0wlY2iIffqO/tlRLIhXUcug6ClB1O9anIG2I2aY1qaVHtkd1IaFK06nt45TMC/NIbKcjQ9 dumYxNMw2pK/C2wHT6Mh7kqnpt6nqM5Kcdl2AqffKyN08Qqlbj+7Nemxr45EsQd0LLC3xAAEePj8 q4YimZnaGFrSXmu4Hb+uTE75tgntSyRKKQo41HbbMmM6GyRLfdAXUE0hB5cOPTvXIZY5clWeGnNw 5IR6WhiWDFSAHG1fEZizJujzcmIFX0VYxTtvlco1st2qhqA+JyNopawqO9f6YCSUhyinatO+QUlx 32O3t8sBUNtSgFOnfCFDXbY/ThKW/V+PltXwyFIrZVsYwj8ZCePQld967bHOxkbGzxsoyAtWlt3X 97GDU9PliD0RGfUc1J496dWpuR9+EFmYWdl0buwCqoqp8N9sTEXajKRsjIYzTlGQA5+JWG2USy1z bjgjkFhYklHIjBRySWQnahHY5kXfNwZ4jFUEVvOCSnCY9WJ609sbI9zWh5reVFKy0PdXGTEgeSgO kidlhPqemFryrXfATzZBPvLVozzG+CNxbksElB8JFQ1RXvmNll0ZdE9NxKwPprzcRklVNObD9kqR UH3yuRREWVG6nKxxXEb1jHwThgSCG2PIdipwx81IS68ggeOSTT7njMftRsaoQvda75bHzR72Gajd El048d9wPGlP15kAORCKVkGQk1qTsDlgbSaRKRghSdqbe9Ri0kqlOhp0xRTdUYlDRh+0P1VwNgFb r5AjxBSOSilB0oex2wMoSINoGWKRGEsUlezg98kHJ4wRRDQaorQjtvt88Ws7Ly5+zX3P6saRbUh5 OwOzk19jXxwgMSVq0EhHHiZPuyTVJZLIy8qUqftUHcdOuKAtSUsic9wAC9Kfqw0mQF7LY1T1iRLS mw2r/TY4rbh8Ug34leh33OAsxVIhH5KA4PTc+PvkWBC5aAsQBVl48hQf24qqx8hD6SkggkmnU++2 AqVJYyrkhRwANEFNt6AD78SVTexjY1DMAB0Sm1KUI+eVyYFEXUbRkFhSJtgo6io64Imw24ZGMhSQ 3UE1rdlhyUfsMfDLYmw7OrLIbSaCeA+rHU7ElQKg7fEBmNRB2KcoBG6a2dyYKIWKyKwo9aBlB7Vy RAkHV5cZiyeL0Lq2DtsZqUYndSDVflXNJPEcctl4/kkeq6fd2E0dzbSE8B8TDfck1B8aVyWPMJEx n1bb4gvjvIryGkqDl3B6EcdyO+XYsXCXGyFB/WJ9Pdnk5PYud2PWOvj4rmYPVt1+9x1WdhZzi8t1 ZreYAzIn2a/z+2MfUKKFS2UCb6/YSepBcH/SoSfs9uSjxr1w30PRU1Qcl3apJoD4HK770qZleCY8 xyiqB8j44eSbpZc8SPWRvTalA+1G23rkY+bOch05sS8yy+npVxGjlJJlKsO2/TMuB3DbhiTK6YIo kuPMSCFPVaMfuo+oqqV/XmwG2NjOVzdd6rdhmRkIAqGCim567eGMcYTxgGihYyl0ycSQeQDEfMZI 7M5S22ZQygFUG6jbb8M10y24gabIAWu23T9eQbolXTj8Fd2A+I065Dq3nkio234jYHcV7b03wENa uRyTj71yJ2ZBUj4gnwO48cjIMldSysTX4SO3YZVLyRTddh7GvX2yWPdqyGnKCQSSCSdvEDK8gpMS uWlAQ3TMSYZqpVXJqRSlW26dspulXKsgoFNFrv4f50yJKQQ20lBWnI9PHfIAp4VsqjiGFFbwP8cI KN10SRO55fD02H8cgFsgKN7pqib1QeJI27ilcnHJws4ZSRSAngZSajpXcjrl0cpIciBCXSRl6q4A PjlJlxmjzc+B4dw1+8iARt16hu+VmRjsW0VLcLowxDNT4RTfwr0ykTCyVOJBFN9t8NsW+JXcHrg2 Ra1wONK1p2yNbsgtNF8fbJfelbU126HAldy2p7UrtXBXVCZINww32zoDhlHlydcJQnuqokPXjv15 L1+7oRjDNIf0g4ufRRly2KHkR+XLoK7Mu9BmTjzxkHDlp5Y+fLv/AFue3QrWtSAavjHMeKi2TwRk LCkZniLANVh0PUHMjhEg4USYSVTWVK/Yk2qQfu6ZVECJro52XT8Ysc18M4UKJwQCP7zod/5st9zq p46RUzpwVC6uviDvTKxzYAIN4zcyCOMHbiQxpUDff50y2UhEWWcI2zGxkt7GxjsuDMUZggbr8R+0 a033zABMrLZkhRtq6uUj9BqhHJos5JNCdqfhlgi1gIS+lkmuViuFa0umBDyr8UE1R8J+nJ4xQ23C lKLmP0KW11WGUEm2nXpQ/sH2y4IYtfs0ly6M1XDfEdvwy8cnIhsFO1iYVqN+xyVsZndEniNugxQA sXkfY03wMqdRQSVX4jTk/bbahxZgqatT4f2QBXwxbKJ3Wl6/Cy0JNQdqfhhRSm/2aULAk0ptTFIK hHNIwcFSFX7J61GSMUCS5G9RQwONMZFetQKUrQCowtZU27BRTiepHj44UIeQqDy403IJG3thS4NU K6sQy96V2xVztWvFjyAqRWtPeuNMoypVW4fjxfckdR2qMjTKh0VUZn5FKMtaVHUDvgYFFwFmrQVI +HalSoyBYlUJ40p0J2PX78C0mVhxATioZuo++pyEmEgUVqEYZB1Eq7HsN9z1xxlAQwWGSIpcgsei sNiD4jJGJ6Ofj1NVxK1jbi2lMZoaAHl05A77HKZm3Lu+SLEySx1NF5bJJ3BB7j5YICi06gVFNLe5 lt7YGduPpghyDUHbb6QMjlxiVinXRvZF2WpfWIZXl2VnoAdjsPHwoc1+fTiJjEM+K0BcQJGUaE+m 1NiNht/HLsII2LVPcro5EeizABmrVTuGXptlpvo1KQnGnj00X1bQ/aWv2dx0rkq4/eilSFYrVjdW Q5W8m08VfsnrWngMkJE7HmpCLikmS49ZZvUgkUEoOinpVchw+SbRbTt6bHZkaoKkVO+Q8mUtxYSe VpeDtbkvbmpaP9pfoPUZaAmIYprmpJctHGBx419QH2qcvxw3cvHQBSfyGySa7eXjk8YYG4EbEFz4 9jTM3U7RAcIb2UJ5ieC5keSFqMBSvTp2OSxbNxhY3Q2iqsl4siQtG6AhyPiRtuo98cxIDXCO9MkM YrTqPH3zXlzYnallQO9DXr29sIBZDJHkiY6cQNwe2RIbBJERAAn6MhJlHzRCAUqNgNyPnlRbKpVU rUDv274CUUqoAT4ClDTvlZ3KyNBegoeuwrT2wDmxluG2b46EingPHK8rGA2XgbUH7Xc0zEkWa8oT 8JqNuvcHIEra9aKwSTp05/PsaZBKtIisF7sAGXwFMpKgoSTlUDj3qK9D8slHZlTo3CIHrRdhTqf6 5Hi3ZcNqzO1F6sOvXp74SLYBRmVSCqHkDu1ffvkCSG6A33SyaCtUVCVB2c9/llQJMnOiaHNTMRbk p3PY5lWJgg82QNboRVMbkEd6lfbMUxMdi5N8QVww5D3rQDtha6X0Zl+HcKOn68eSLU6CvtTcYWSk 229KU6DCWQWHqf1YLZNVNegrgWkTZa3pty5haUWt4CQ0EjClRsKP0zsZY5Ad4eSx5zH3Jky0o9OL EVFOhzCyYB9Q5uzwakT2cWYKKr23pmHOXk5QALQMbVp8JO5Hj88n4nE0nTgbjZ00CSmnGjAUVu30 5kwyShueThZcQlsdig1R4NmcD2GZQkJ7gNAMsRonZcZJJVAPxMtd+n4dMkAIpyYTLcbqZWWJwrKS KhgBv17YRIHdxzhkDuE7tbG4npJEgFW4DbapU7+5Ub5g6rJUeHvThiOOyKAT5LeRhFzJeZQAFqtW crVgCetPfIYZbMc5FoaSa2uZmt1VZAFrLA4pyCmjUr9lx7bZfRAthELopJX06kqvFPATC5cclaKt FJHgB3G+HqxKSa7KYFaG5CzWp/uJFJ+H+Wn0ZfBiB3MPl4l+IFTXbalcyA5FkBFCiRDbem/34tYF lTDB1JB3HUH54tnCs5UJ8B18DhTSsz038R0wMY80HNIyAyblRQqB4dMLkxFtB1ZQ1eXsemK1S6Ri OK8Tv1IpQDtviGJG6mIwm6dyQB228PDJWxoKCyPIWMYMbBulBvTJsCEW0qKgZ2qG6kDauRprUpKS N1qKfCPHxr9+FUG0vxA1/Zqw7V64aZNwmj02PjyrQdt8JQVZ7ciR3Dhoq1FKCm3jkbW1PiTHVfcC tQenhhTatac0B35VGyjrv4ZEhJkDzTKL03XmNj/MP7cgWvdU9N61Qih6nI0tp5okdvIjKVHMb860 I7bZRlJCefNvWkEJjRmJ5jkr+OSwniFpgCChoVBcHrwpyPauWEt8YCrTSSKFxG5IYr47GlOmY0gd 3KxTEdlF0XeNE3FCppQeODGTds8wuKlJO5gaB6M5+wxOwXx275lOordXtGCQtWoBIrQbVrQdemYm pF0kiijgwIUEnrRh1AFNt+5yqN/FhHns20YCHtvVT4YRJGQ2UtubgwsFNWBO3jsMviLYKmkXawSJ GW5JIN1HiABthyRsKQm4ZIpAoA9EmqnpRif1ZVZpY7FZd/36mBqE7nagqOo+nIx3bJxrcckt1K5u IlaeEemyiskZ6H3+WWRAZ44giubAfMepNd3d9cwj0wY1Wp7E/C3T55n6eFVaZ+mLHLKa6tYpJIXe OJ6IzrU9N98zpgE0XFiSBatH6103pgh6CqlOjE5HYNniEspsbJLW1jjUfFSrkinxEb5gZZ3u3Yo7 o0LU1U1HbMdySWvTBO4+jw74QWPCC5Aa8SD7U8cJZRV1ZulfnkabQil6Helf65TMW3RKotS/Tr1I yqQ6JCupX7NPmMiCEEFVBNKAUHemMmDTjYAA8u56igyiW/JRzVA/AABvntvTMWSQFUuidT8BOx+e VkquMg+AchQjdem/zyNKAsjkkA+1tQkV6UxNMqWSmtSR8TbeNMqJbIhCRPycoK70q3f6MIrm2EbI uOVQeDVII37ffjuObSY9VGdSrEJSpPhvv0yom3Ix781IykICwNOhYeNMidm8R32QMzty5Kem229c Ak5MQOqxxyPLvTYHbt45Zx2KKRssibenQ+GVkMiFflyG+1NsIYVSk432OTAZAqTbnfemLMLPhNa7 N2+eRS1v4GtcjaUPpmoeXtQtpPrEUS+sPiZUUEEH+Yg8du3TO4nCcTs8PuOSMt9MudJhM1neO9qr FjbzI3pkd1alTGR/MNsrlMTNEbshPe+qY2Wp21/HxQGG7G8lpL9unXkh6OvuMwNVpzEWN3a6bV2a l81zHelKe2a23ZhVicoPw3zIjl6dGuUQWiUZvipU9dtskZDi2JAYeEK5W2sS0PpUVhvTx/jmSDPl MWHHlGMQeE02sKTNwVSJAOW3anbb55bI8AsnZw/HMq96bWdxpNJYkmLWrsqMrsaJLH3oN6Pv8WaY 5xKV3zbpYckQLHq+8H9SZSSNLawpx4uqgh1NG+I1QM1ab/zeOZ2M04Mo7lBtDHC6wzSmVo35q5Xj PCX7n+dfHMi73awUYFlS4a1vHXnL+9s5UJoykAOm/wB9MjCuYYzPcxDX5mjV7JviUNWFh/L3Br4Z m4+9jAdUhgXdeQDeJ7jfLW2YRUwJFK1xDGJQQAVuld+uFyAvjjRiNvcYtc5FqWVlVyByYdFG3tTf FnCIPkhXDcWpQVoQD2+eFsDqN1Hwnt07YGYK5CCtB1NW32rimlIzcuW9FBoAaVr3ydNPesNCwKmj Dt4/dhYWvjJYhZPiB7dN+nTCWsruMa8U8K0BJGx98CEFLEORIPxLy9qbbAZIFkFrOWb4jUbKKUFd qdMWQj3IpCA4FAKbA9yT/XAwXyFHkdD8MhFQAevgcCFaFWIVSat1pWnTAVKOQgFSew3B6ZBiqp8N So+Gu4wFeaeaTDyQykFY6gEg0J+VMwtRl4durfjjarrkLTxRhBzkU8QvQAU2O/bKtLqIxvi2tnLE TySv6ve2zCEowFfjelM2IIkLDA5K96JIZEYliTQbk9ajBSBk4ju3HNGppKWoorQHuR3+jKpRvcOY JkCioW/OV3loOB+wB9+Wk9HB5G1zzSiUIXAFKjr1rX9WQkEEbppp8jCgfdW2rmHPmnLiAFxRNxL3 HQmu2wwxi4tpXcD1WqTSME1KnvmRHZLUYKKUFVHVWG9BXJFU7tZAYvSchhT4PkeuY8hugV1aV1Wb 0pTyb/dDHvSnIfPbGkk9ELqqiS1kqKkKRvsDTADTLGaLyjVFSJ2gVyfWagB68QanNxg3Fs85FUiL Xk1nBatF+6qZH7V59/uwnmSxAoIu20hBO8tuwQIaUG6sBtuPHK55NqKIjdN6ELTei7GvXbvmHMub ijQWxs1CPDpvTAWYAVC3X7zkbbODZeADXv2yTSOa5AK1A6dMDaDSvHUgEU8adDkCyBtEx/a33p/T KyGYPRXCg0qKb0H+3ldJul4+H59vDIEUxO68EGvLavhlGTkxqkRHC8iEKRxXo21d/nmJIqSAsEAF VcnfpTv8gciSz4ncEC8VBJO4UmhBG2Apta60AJG21F/pkWUVIuArKD0Px9+uAs6UiKGrde9PEeP3 5ChTMW2QyAvWpG1O4xXmVL1CJevIHojHKTE25AohbJQ1CtQDcA7n78atnDzQhd0YyL32cU2IyNOR QOymOJ36DsMkyVFBUEU6gfP6MB3YlzAElvHoPD2xAULCQag5MFksZTXbr/HCdkgqLVrvt/XFmG+X v26ZXR+C0keueXpNOu/rdhHW1duIiUkpWtGVW8R7532LNxCpc3iYHZux8yyIUgnd1WFy25IkQn5+ NN8E8HUJ4R0TmRbDU1iubWdLW9jf1OZFA4B/aVfstv1XKLMdiLCOSdPcICFvGEdwWooA3Kk0Vvce 4zXZNMJG4ubp9aY7S5NtBIpNPDb6cwpQPQbu3hmjILQFqQag0pQ98MI35MyXcnjHJKE9x7eGZeCd Hgm4mox8Q4o81Yy+lpsl2O7ekGQVZQw+Me1RmH2vlMTGAvfc+fc4/Z+PinvWyRrB9a1CKG2LcHYF nZtqU6ttmuiLlXR6Az4YEyegpEsSuPiljCqktN5FUgj9nshPxe1Dm1wmy8pnN+Sje3QjRILyMtHw HFyeQdR+0jD/ACeozMiO5xB3pdd3zxQpbTsZbevO1uf92Ivh7nLYx3tiTbG78yuzBm58fsuaVp7U y+LZGghYFGyEAN1+fvliyau5gr7bDCEwFoNQwYktUe/hi5R5KySKu1DQDqO+LTILJaKSKbtvxr13 wN1WAhGKnisbktypy6gkdickzHmvqwYk9tivXpiimiyuaVoyipFfHvjSbUWL+qRItVp8J69P9vJj ls1yItT5nmEqWIO49vbJNZBCuylkJBO/Q98DC2owwjpI3PcUJ8KbYrIi9lNnRia9yeJXpvjSEM9v GXDA8HHjv92StkCQrxtSnL4QNwfHfAgqpNWBpsxrXtT54FCLhYn4qUZRt7jIlAR8iTRQxPKAPU3A 7/TlMcgJIHRtyacxFtwS8Xo3QnrkyHHpOtPiYyJKAzQg1NBWldq7dsxsp282cOaMurx/rkgFQkQH AihB5rXp279c05xAAGv2OxxC9leGSXUbffiki0INKswH7RbxIoM2GnkY8/p73B1EAOSXXqlJKFeN aKV6/TX6Mzw0QNIKZZOE6qSzyfCjncACn3YKFt/i7UjbRAsYZhTbZT75VNEuSGaBzKXA+EnbBxs8 ZEtimMFdqdiMplyRn9NhWuRxPSqE7+2+OMuElE5Mcvw1MXLcAVpToaZkhUZYTq0nFV5oKfGT9uni O2RmNklNmiBt3aKMhmIIKnp/nTKDKtigBqSMPByergD4X/y+9PeuAc0JNqF7MIpYZKHagPv2I/jl ggGUTRt595iCx6gGoAVg5gjuW8Puzaaf6VyHkqaVGLxCQx9KNaAVoWfjQKPnTBM8LbI7UGRWUAgt UTjxcisnzO5GYmWTZp8aqfhG9T3zGu3OMaa9NWp7HHipBgskiAFQN/wwCdlsA2XRHYVG3T+uWW1S h3qpFR4f0xQNkRB1G1D771yPNkduStyKg9xjS3aIhcnYnIyCLVzShI2HUjK5sIk2pmgU7AkigFcx Zx7m9E2ty45VWsX7TAdBTMScAiUVxuvUJCryowAalB7ZUYkLw0skVlk4leLE0LE12ORZxWswCgtu gO2/Q482QCi0RcAjahwWztaoO4HzLf7eRLJW2LNVgtdwD45WSikHcoyt/Kf2nO+ByIELGR1cM4qa bMN618ch1bRIUhZVcbkV33p4Ybb4kNekOIZdqitMFp4m1UgMRWvcZJBKzkK77AfryNMqc6LQEHkf Ee2EFQVN6/1ydsgpEinIjbGurNZxXnSvw0rT2wWE3sx7S/MdzaK3ILLE4HJKVjcH7SyIdqk9xneT wgvGHGmskfl/XUUQgwXsYPor9pqgbBG/aFezZUJTx8+TDhISS7s9T0a543Kn0q7XAB9PkR9lv5Tl 8ZRyDZPEzHy75k0y/s0tLuQLIv2PU35D/JbxHj1zBzYJRNhgRXuZIYk9MBTzK/YYUFR2zDMBI7tm DIYHZAyQS1/eAgE/DXqPpyWTGDQDtNPqQb+5Dj42AQ/Ep+NT1+nIGBiKny6FtGQSJMdpdQtiLtZz WoILgmQtU/EEr0ptXicwu1YmozAsDn3i2WGURlv+cgrKMJqKAN+6kZUfffcbmi0PTNdCXXo7TKbg e8PQIbW5S3/ez7hUEUo6pxqq86faWhoTm5wxoPH58gkdglWoXzw201u0K1hB9aEEGm3249vsnMuM WnmWOC89SMRM5ZeqHqQK1oMuplVIacKwABNQNvf+3JhINKSha8jUUJoD75NULcur1rvTpkm3ECCh 03Yj7jgcieytWg+Gp8SMLj0slUc9welOXant3wNolQ2WcJBttwpTlTevvinjDRj3JHTb+mLO1u1R UCvb6MkGEzTmC79iB0NKgHxG+FrG+y1I29P41B/ygKGmG2PR08DmMqrEV35L49RhBYgqQQpFSRuW wDfPCklzKpO21Ng3sMCEJKGRlQjmFrV+/j1yTJcr1qWqR4d6DpgQjEXlCoUkqopQdKV7HBaFWCRo hR6lPHvUYCFKtPNJKqMZSzLWh70yAgA3eMTsV0E8jg8yV6fIYCU+D1DIvL0jw3pSVmiJA5r0+H5d 8wdZvjuO7PHHejzTbUrG5F8fRCtFOnEltuLdRuPHNONaI49/qtuxxHPuX3Zl0y1SrfvWCh2oAK0A 65ttHITAHUB1+YXInoULet9atRyiEbBQI5V6E9aU8cyojhlz+DX0QllGruyuDUsSzDYkUHjsKdME yeiykj50pETStANwK9+uVgtmOfQoC3kJZ1bdSaA08MhkFFu8OxaZQWy8SQ1SoBIyBk4s8hOzcndi ag7UPTwwwDUld0hBPFqoKfDtTb55kxKVOASqWKj7Ro69DXJFKeadd+lCFYgIpPH323pmJliSdmYG yJmFu6rLF0FeUfTc+2UwmQaLCUUg1S2rSShPA0CkjcfMd8zIG2PJhnme0VhaXLA8ORt5HH+XXj9x zO00uYRLdB+XodSg5W/ACFJC7chuD0yeaUTu2QiQyha7eI6Zq886Ds9OLC9twa7U2/jlMZt5jbla g77Cm2C7RIKLse2w75bGO6AW4mU9fDY+FcspBNqy8j1J2/zOG2oxNomI0Wp7bg+GCltVovfEpCpE QO/t/bgKCEWiEruRQdzlMoo46cGBShFCBtt2zFnFl1WrJNHURntSoHY5SQDzbKDZW5UMlCVj+33C kjrlJIZCjurRSickum9NmHamVyFII4W5Lc0Ppkcf5uuRtIkh1LKeDCprSmJ3ZtXActWMVBBDLX2y g2C2wqt1qXalSHFWpQg7ZLmpxkKLO7bKxKdFHT6MiQGyIAadSAKGhp222OQAbYlSbgaCtD037gY0 2BY8bjkQtAe3bIhkJAqB6kV+IdcNtgbpXYkHtk4lVhIqKGnicNBKm7N33Hj1wEMg0Sh2A3HX3wxN FKn6cVOXLt0965OhzZcReY21y6/BUn2OeiSi8hE9EdBcLyBR2hlrsQT237ZXKLIhmOl+a1miFjrq LLbuvBZ2FR0p+8H7VPvzCnp6NwaJY+oRWp+TTa2n1rRX9aHgWe0NCWXryhbrt4dcjDU2amwE+9Qs vNVzAiSXLNcrEnBJASpU1rxmHTbehphnpweWyeHuZLZa/pepQhorhFkI/u3+0KCtGHf6MxjilDmE XRXtYC4npaSq8h4lWDBlIYfEAf4HKpakQ+sVH8fi3IxzJ3G5/Qr3Gmy26NPduvIAxxunViRxHYdO +anVaiEsfBCxx9D06kuw0/qkKHJjq1ja3uI14hH+Fw1alTQnxGYfBsKd8d7iXoQu+SrcCI1IrLGT uyMKsy70NetM3eEkjd4nPDhlTDNevYv0kyJITCa+genXYjxzPhHZEOSStcuZy6UorFVG/UdcspuE bCKDpLGGHwsOori1Lbieinx/gMkExjaBapJpuOoxJczHFoCjEnt1+jFSLNOaU0NTQCgJ9x2whjLG Qa6ohQrLQirfs+GLj2QsVZEYmvJT09qnFssFeVUry2oNyDgUSKEuo0ZQwG/UdiBt0ycdkmQKlGXi iZgORYVA2qfAHxyR3a6RUVWVQ4q7CtB05D2yJCOIoZpWRqMKNXYAfZ8OnjkqWmp2FG3qadK7V6Yh QtYA7EbHCqHkiQvuPFTvsR7/ACxTa8RVkDrXwYGp/wA9sbW1RGCTUjAI2IriVTKGH1IzQ0BA36UP Wnyyu2DVeLFRGaqPi/swpcGbihAX0k6bbivUnIGLlwzXsU+05VkWKZTVmXc1rQ+BBzByTq405QxX um6awkTxwXClwCQrDfrtnOarT9Y97b4V7hNJWilENvPGZkuRz5Fdh3HE1oDmfpYyhAzBojzddkAJ pK9ZtGt4Y/TY+n/dlgTUHxYD8M2mk1AyX3tE48lCxfm1QCFWqtX5+GX5A0kbq9xJ+5ZSKjoPevau U1RQEOtqY/iAIj269QTkeIS97bHIQjrVCor49/7MjNrnK3XAGxoaV+ML9ojDBqQSLX7VK9TXbLwy C1UVCeI+E/ScNppv1Gj3pVRuV+jscjIW2wNL4LwgAOTQ9zlUsYJ82UgpXUojYsaUJ6HcE9stgLaS El1lDeWTKigybbHYBlNQaeBy/EeEsDFQimW4QyoGhYEiWNgAajff2wT22crDHi3CupJUliKV+VB0 3zHlEEudGZEeTTEcgQae3XMKQo05AIIt3RqdRSn04QaLEqNxTlUmi1A265m4xs4s50XRV6dRkizB tFxCtPA5ApCMSIlAep8MIkGuUS4Ag79O9MJSviIrt8xkSqNiYge9ASPwyBa5glfIFdeu52FPDKZg LjsKAqtQfAjw6Zhzi5QXkUiIVifVoTQmn0j3yqRs7prdUg4L8JJDN86dcoksrKIdghAO+21f40yH NiAskRHAp17k9cFso7KD8gDt9NPffBJsCHk4sR8NGYfCR/TIkN0dkPKvDvVR0I3yIl3t0d3UcCpB ApVW+n2wFNhZKDWlBXtTpTBbbFvkyCoJr09sC1akwViTxoTua4GQ2U2HXYV9umSDMKZqD12yVslO SQdQN++TZAKLMCQw606YDuzpbzFa0FfDIJp5dEfjK+BIpSmemF4uB3VlcEKrdKde+RIbQeiOt7oo QktHibo3X78qlHuQQy3ybq99DctGLj1IVAMNkQSZCTuIj+ycw9TiBHL4tWQMn1ry7Z63bG8soxba kAGViKByNykq9K+5zFx5jjNHeLWPJiulaRK0jPalYdYtHYS2EtF9QA/7r9/bM2eQVv8ASeqzknsV /Ko+t6ZCUlFVuIF+ArKP2SOxzDMAfRk37vMM6/jj8R3IzUdQuxb231xd3HqxqT8asdjWnQ7/AE5z OrxjHmqPLo9D2dEThY59VCIRTwlH4+uhLPsBsepFO4p2wkWK6uZMmJscmVW2o2N1YyiEhZIYgYnb qD0ZK+zDbwzaaSfEHmdfglCVnqWE3sKzSSSzf71BmDAgUNdwa+ObQT7nHGyCiU8gGDMpO7dwfnkl JRLHgoK9Pl44QxCGldZK+NaHC5OOK0Iy1r0r7VwW5IC+Na1pQjuDhaZ7brAnx1rQfL6MIYTKvGjI KGpp7b4Wgm2+aipI2G309K4EKLxpQAn4Qa0JINV98LIFSnmlJIp8B2JXqAeu+SAUKX1YIi8WLt9l XO/GvjhtPEvNsoiKAlQx5GnUkbmmNotQlUyUVX4spABNan6cIZRNdFMMIzUD4K18evX6MKF7gyRR rG1N92Y74FaYug4kVrWh23piqkfVEXI1JrWor0PTbFUTZwcpTSWhHY/ZOCRUpnwJQIB6ZUg1BrQ9 v8zkGN0vI9RAVNW/mHYjw9vbFClGzrKA6qJAe/2WxIsNkfTv0TizVIYvUgJpIRzhbqCN6DNXqJXL hkOXV3GnjY4hyVLpGaSKSMgy8hWOnTif45hQn6jGQ/iFFskKs+TMdKv4Li3WKYFZ4l5Kp7KB4dB7 5XlxSgdtwXVTG9hZcNazNLE0ZZZAGdgwIHzb54IwniAlyLCrCXxWRgXkFJXcchvtWtD70zawziY8 3FmKKlNIiOjAVZabHvhlGxTcMYMbVoV+HlGK71FTU7kZjEb7tBKpUAk0oabjJEsaQsjOCXBqAKDw qcyIhgh2YtWo4yU79D3ydUoXqw5cG2UA8W/hkZXVhtgVKSgjJpUHYjwxvdvjGwg68GBWvsN8sZcN OkczU57cdqHxwXSDitQkHDYCpPb8MbtOwFJY0sVvPOsxCCQh0djQMSAtB7inTLJRMgKYYZiF2iDJ EUV2aikgqw8coETbmnJHhu1JkaM1Dco+/wAya1BwyjGfPaTAGUOW8WubbnalOg7ZiHCYOVGcZ8mp m5Dfof6VzMwkU4moju1CeBBIqu39mWSFteORjz5JlGKKCN6+GU05NohHAAoOnXEBEiucV+Y8euDk U8w3GN6dT0OSa5DoiEI+Henjlc0wBVgrcQabD7/xyklbF05HAAPCtAd6VrXMbJFnXmsDKsbVbuKJ 2PvmPINnVfGVYruHFdwTQDKTsktFF5AKfiruK7e1MCQqiQCg47g7k9d/DKytL2EPE8u561226ZCt 0AlCzx9WU8lHR+h3xboFDuwZAoptsq+Nci3RFG1shotAQ1Nq03GQogtg3UEcctqMe2EhnS0lAOdS CxwMwsMnRureJ+7AyAU+R8PltkgzpriWOwrTCVulB+SncbVr9+MS2DdQYgkkfD1IyTMKdR179cDK kr83aDE/rXcEKQSRAS1R1KSRGoASm5avWv353emzVQJt4WMz8GEuCjlCRyB3p0HyzPDbaui0X4d1 PQZEto8kVaXMkDK6EkKdmGxUjpTwyEhaCLehaJ5nS5t0fnwv1YCXkarKvuPHNblwUfJxzAg7Jvfa VFrKpeRA2eqQfZZSCajpUivKlMrhkMNjvEtRUbKCe5u3S64WurwlfrG443CFSEkoD1PGhyOWXCNh xR+5sxke5DazcldSmQMZFhonxAEmgoRt3365zIzSyEyL12jwCOMV1Q0Vw1w9V5Sp9shQfUUDqQRk rEjfMfaHIlARHd9ybCGtqsUbCaMlmSQCh+KhNad8zcEjH6S6nOIyJ4ggLj1kiMMy8mBqk3t4HNpi omxt3utzbRo79yCiBNaClTuD3zKcBrmEHE145JnGNqaRIX5UB33GRJc/FXVuYALTt49MAZSWrXlt tQCuSDVk5KgiLGprxNafPvQ4XHMlTdFAJJ/WPnhayEPJRpiP2l2YfPfemFHRcFBAXbagBP3nFFrR Ewc+n8Zoar/MOv8ADFNoK4gmX1fRZlWToQa0NOn0ZYCyct47R+i+xTZ+RoSNuh+eJCKWM6OKquwJ Br9oE9a/LFVhZ6j4StDQHsTXahw0lxIAJAoSK/T4YqqLKGQFx3rxbbenfBSFT6sZYiY2p3I6Hbt9 OC1tegt/gdtvUFKeFDTASyjEnl0XSSMCPTkJK9CD1yNN8BtuNmoLqRSSi0cfaTs3uMVng+XemVpN bzK7MvxftIfxynKSNw5GkwgnhKvHLArho2IQ/sVrTb781+TISeGVe92mPR+HvH5dEdDarcWzTQuz XiSKVCt1Han3ZqsmaWHIYz+g/i0ZDuO6mbadcW89kpQCOeZWPEFQw40G9aHEy9F3bpcsCJ13JDcu EuDG/JWYU9YAA7kfbQbjwqNstxdpDlIXG/xXf97bLT2LGyMtjM0CxhisoFVD9PAknM3JRqcd4lwa 3opc7C6LFfhkAPFe1fHLo56q1lAgUi7Giopk5Bz1U9j0H6sjOVmhVNBDVy9JAS1Ub7PjtkoR2Ykq MjclNCNq17jbtloYoRAwOwUDqRWu3f51y20hW5LTi1CBuD3yKQFNpBuj9egPYjIzG1hycM+9ByEg b1rucANudGKgjmo6ValR4nqMlTCwGiwY8DXbv1xAphlF7qbwAsCwDBTtXx9q5Lipx+CypenEhrQi tSoLVAJ60+dcPFa8BjzWOTX92Rw6FO4J8K/qxq/eyjk4efJR9SJjVG4t2qCAaH3x4T13DYJxJ2NF cC4Px047bjpkAB0bCT/FyXxrQg0+X098lxWw4aKIhP7PYA7dPuxKYm0QrAEDse48emRplauR8AIH I9iO9TgCkrol2HiNhXqcTzQOSLgKitRWuwyEkSB5Bs9BUGhO30ZRJsBaLFaUNK7HKJb82QWlhUjq Ntz0oMokGwKkQEbEqOXMUUdKb9aZjy3ZHdXMEZiowCv126EjK7YiRtTuI41UGtCu2/sPfACmJUlZ lXgRQUO37JwFsq1N4yqgCo22Fem/TIS72yJQ8pKln6N322GRvZvgLQkkjb+J3qNseJvEGhIGANaH b6KYlNUqeoACAdiOv+fTIUilM9BTYnpgLNTqSOlMkGTqhV+H/ZH8MU81BmIBAwlmAoOOXTY+GNsx sp7c+PfHqz6L/NGrxQT/AKP+ppNBLVlkABKyfErENsQRQVzt9NjJHFe759LbkxP/AAzqOqWs17Zx xmKJmPPmA0gAq3FaUqO++Zh1EYEAssfERY5BJLO4MdPDsKbEZfOLkwkCE3TT2niE9oKsR8UQ3NB1 p4jKDOtiz4q5qcCzxSgxKwY78BXcDc08cJohSR1Tyy8ySROZeVHFCX6E0H4HxOUSw3s1GCd6emo6 pqWl3zIyzXQalzWlViUkAr0AbrmDrJDHhmB0CcUAMgvla6aK4klkITkoqZCN9vmPnnMQFDyp7OMg AEfoNpObtJ0kjEKgj1qHp03p+OWQB52HG1eUCNEG2RuY05h4gkpB5KgqkoI/vEI70zO0/Oqo/e89 mJq72+7yLG5rqnNAecbN0bqKH9ebWMXEMil8J5PSnE71y1goXJFTvuO47e2SbsPNfFRIwW6kHbIH d2EaHNpviUkkBO/T54aazNSVWZm5fCwI+/JtUpIxWDBd6AV2+j+uLhlY/Kq8T2qKjwwqDSHmm9Ji XjruBU7DfvXCAzpa5pAZoojIXNWSu/gf8xhYjmuhVbhYrgxskikgdqU29tjjy2U7bKMsDGYSQyej UAzwv2PUnbJAraGu3jajFeUZHwMAQ1P44QEhDBypD15/DxBHv4++GmQCrHIjAKDxfYLXY7b4obYA kcjQnoade/04qscNHQmrKepHX6MUqsCyAq8f72Njs1dx44CgoqRo5Uo1Vbv7e+RTEmJ2QsYMcv71 eSdMXKMuIbbFFGNGFVIFKcSDvXrkJM8OStiFVCikOrFW6Mff3zHlMjnydrDSxnEGBohVqlBxNCev gD4HMPOPiHOwyJFSFS/HJWt9RntJBPE1CDUjsfbNXqYxnHhly6HuTPAJCmQNJpeoJ9YiLQ6k3Q12 r8x1Ga7LjngHAfpLrPDlE/0URpupWTyPbX8CrcvRWmIPxEfZO2JEhAcJvH91teXCRvEpi1lcWjiS 0IkicktG7bEEbcRluGV7b04MiDzU/SikiEzBlFKggUZR3HhmyGTlTimJBpDm5YstWqRtTvQb5n44 BoyBTnulof2h1IYCo+WZAi0FAfW2C8QaNXeo2Phk+FDlvGd2UGnFSPE7dafRh4U271TsSag7BgPv xIb8ZDYlDCh2odiN8i2HEeYUp3/d0IqO3vXviA2CXVatsUm2PxdfEeOQMuIMjkES2yMzliAp70wA ABRkUZWIovLmOjbf0ySgWpsVIHT6fb2yG/JsoVZUzQU4/ZO/8OmEDv5ou+XJYBUAncAGoOWW1Sx2 NlhHBiUFUNaqeu/9mSq2AmY7L4pV7VIU/Y2qKU6ZAxbo5AiYyjGo6exyJJHNsAB5c1VOBr2oRQeP jkmJ2RAoDStQcipG9qgAqKfd74oKLhVSQW29wcgWJNcl4oxAJoB0OUyNM+QUZABIQOnXxzGkW6HJ TG42+7KZSbqXoVA+FuT0qBWlAOta+OUEpIVYJQzcWJKncV3yEgiQVC9QVkBCGo8cjXcxpRdK0NQw GwrgIbBJTMLhd2pTtkCabAbQrClRIKEnY+2A78m6JQ01tKPsioAr45Wab45Ah9yOlCNqeGNt4bEj AFScC8Kqlabd9gcDArJKL8Na71OFkFMNQVH05JlSg5A32FPHHcNgCHZmqKnp0xAbKdz36Dl1ritP PZdXvJwzXLmSZhtIwHLYUpX5dc9LGMDk+fGBtUs9Z1PS4nSxuVVbuMGdU+OgNRQhh8LgeGRnijM+ ocmUSQNtkMsilAtNwACckQ3Y9hSa6Lq0mn3aSU5RgjllOXGJBskLD0a0Oj+ZNNWLaK6j+KOeIgOj Ani3j75rJcWKXk4xsFheq215Y+YITq9uvCSSN5aUCTKGAZ9vh+Lq2Z2Mgw9JcmJuOz0yUJB6b0Z4 4VYKkYCIagqtaD/KoB0zntdkHhSH84158+jkafCTkjy/HeksyqIZWblG5qvOg6VoFYDNNI7PSRO4 6hOtDiazjq/FEpxlCblW/ZkofxplwjRr5/rdfrJcfL4fqR95LLDbmKSNWiYHiybhW7MAfs+/bNji ifg6rYnY7sMvjNyJ5A/HXmRSvjm0xmw4+XHwnbktD8UHQnqadN8sawLQzK1TXqTvkm0bFfUFgKVo B9+RpyeOubmjLE8hUEfRkg0yydy62HJWIFCOxpvha8hV0RQNvCu/3U/DA0laVIPaigg0+7CqBurJ XRhUsGYciD9mgp0OSBZxlTUqPBHH6RYxxkGnXb3xG6QQferWksbISGLlviZz0J+WJWcaanuIVR25 rxUlfHenQ0qcQGFKMkgmQoCK/D9k7/EOW+GqZDZKJomtSPUHwsSKGu9fHLQbbBvyRMahlDchyr8J p+vIsCoXTShXqDQA8QOxPhhDMVS+wuTJGpkHE/ZKnfemMgxkER6qxrQmprUU/E4FjEnk0s0lBVy+ 9eR60xITEWrxzK0dCAem/tkCGVFcsZjlDgHgdv7crk5uGYltJEzPClVpt1Jp0p0OYmSVjd3Om08o G4mx3IdixK8W+KnUdCP7cwpSIP43dkAKVYZUaitt+sZjZICQscvuYyBC5JhGfgJ5A1U9MpGaMwMc +Xf3NE8R+oI6W7aUKWJ5j9vvQeNMjHSnFLbeB+1xJDZl2g6rFcRta3Unq+kawyNsCANvpFMxMglj IlH026vUYuoQ+pXqNMyREp2IrWu5/XmboySWk4vTZUGmD77kj9rx+ebqEK5ODkaKrJHxPzFP45aN nGISq4SRG4AU6mh/XloLGkOlwTU7KvxKCPY07fLJUghGRTCTZqBacWXtvvyyJDMNyOVPFiOgAI8K bZAxc7DkFUsM2w5Hr9AwANkwK2R0fo/VhIDSRmIpXtlG910pxpizbbKvQHqK09hkAT1baCHmaNFq Rt0G2RlloWW7Hj4uSCnQsK9BXdsyoANGWZBpapBYKdg3Q9MJDGJ7ubmG9VFB1+nsMWYktD7+BNNx 1riBTHIeLY81OVJGHKEj1FJJVzQMdtqgbZKJHVooxXwTcn3UxzAVaNvu3p+vCY17m+OS+fNEclVq sSNtx1+4YALCDKjui13AqKkdD3yDYVVNuu4PfpgKgnqiAzFNzt2+nIFNC1QOSKE7Ht8spmGwRUnN OW23WmYcy5EQpkGoFOvT5ZjSLaEXbr6jRfZUUIalOVOlTtlJLCWyiYXRObGi8iAPl06ZMStlxKpm UkVFFIoRWtCPnkaY0tJQbqOSV6HbFkFORlPXxIpXfIUziCt5IzAmhIG+2wr2plcotgUpHdIwpFQu /LuBTYZUQ2RAS+cLyJ6V3+dcXKgsMb8A3UHp9GNhnxNK3Fhv0wpItcrqeuw8cUEOkClqqKimKxKF lAP9MkW2Kka13HXtiGa3iK9q9afThpNsB0a60q2uJP0pafW7aReIpXmhH7Q3GejZYzI9JovCyHel w2qRuDUjuadq5cgbBWUkqSN27170yLaqoQtVrUdvA+4yJSj9L1K5065E1uzClOSgkA0PQ0yucBIU UmIkGdX9tb+a9MhuYomFx9hmLARpxHJyzGp2G9FFc1wn4EqPJqgCDSPsJprfTf0bdXHryxKhtZjV fUj5/ASPFQCu/hmn7Zx3wzA2Et/L9hdl2bO8leSjeXHqP6rj97y5gggBkr9r6O+asAcx+B3vQY4U KHJNYpgLmH1OInIBABrHJXt92Rs8Xn97hzj6TXL7QjrqCNolexkdkU/HbyH4lP8ALm10sr2i6jKR E3kG/Qjqk1/awgF46ojH44WHQjrTNlA97jSnW4QAtipUjp75cGqWQFzwCnIbEjamFiJrAjBiGH+f zyTIyXKO1NwaE4sCVyqBGV7nw61OKHKW2ANVY0+7/axVQmZY2ruQ5pQbnbCE0tM0KKzAhV2J+nbD S0UM/KaZHjb9xQclGxJB6/2ZLkz5DzdNbP8Aat6QlXJP+UPYe+ILIT790OsVtIk6shRpj9knYsD9 oeGGysvJfIsdoFIWgAAZgKsd6DHmw5tzj11C8VYb7t15ClNsRso2QTxm3k4bVIqVHh02yY3ZXauG LISnFuI25eNNq5FCF9EkMypxLAmRV6V8V8clabalZii8xxcAdvxwpHPZGLDEYgUYlh+weor+sZC0 AkLfTNfEeOAuREgo2Al0EbGgbYDKpFtGLqvmhkVTWh4/CwHUDtmDlo7h3+jlIDhl8EO8JX41rQ7f LKDi+Tn8fRQC1YFeqmvga5iSjPFLiH7CmXDMUUTHV9zsR3/rgyYY5RxR2l3fqabMNjyVYTJuDlOm nOJo8mnPEHcI22lZWqeoINfGntmZljjlGxdHb3OvMTdFGRTv1O5Pf5ZVhxmBpqmAQqeowpQ7V3Gb aBsOuzYkRaSt1ND7fTlhDgZIU3cQ+qWA2atCTSvGnT5YxNNJCWzW4HwsPjXrTx70ywFkChi8ls/N BzQ9V7gHbbJc0cNIszRyqGqadQOn35Gm2BPRQ5DgeS1I7Mdq1rUY05RNhH2xh9DlMayFqK1DQZTO 72YXaKY1Wh6gb7fjmMObLoouvL4X3phMAebKMiNwh2AAWmwNdqGmXgONOdndSI+Ek9T0+dckkSpY AajelKUHStPniy5rGBpsKHpQe5whhKXRzCgr1G1e2AhMJlf6EcyBZBQj9tdmHsD74RIhBjfLZWSJ lA5nnx/aIow+eG+5brmqozJQk8l8cBFshIhFxfZFemVFuBVlqEIAG+9D1HywJrdsN2Ox8P6ZVMbN 8CtNe5FaVpmuySLeG+StxULQgdD3OY0mQFKtvGoapIDdN67/AEjxyopkWkildiEFWG4UbAE77YbU kALI0V56Smn82+++T4ttkHYbN3MPoOKEshFFbp0wwNrCVhRdeBFWrXfkvvlcgZcm2JXNbuIhIvxA 9CNj75Tx70U2oySsIh3Pfft4YmLZAboCqhiwFKmh+ZytyqcaOnLmAENOFNyOta4suRpRNTX8Riza NK0HTJAMg7mwO24r3wmK00eMi02UiuQul5IaRSjEHemMbbQbU9uXtSuW2yeaSVr8/wCGelB4eQ3W A0BHUE1p9OFiqoSSCNq06mgG9N/bIlN7WiHQJK8fNJODFQ8Z5IaGlVO1QcgDs2RNhsDqcWYDLPIu qvFO+n+p6byn1bUnpzC8XX/ZL+rMTVYhIWRY6sJCiCGZanNDLb2gkVkmijJZqca0c7bU7ivvnJ6r NPHlyRifSa8+Y8+rttDphMCRG4KWxLZ7x8w0gBVS3Qk78l8D2pmLGQA26O5kZc+iaWOmPOnoxyJV UqIpVYFXB7MK+OCQ3oH59HFy5+Hcg+8JlfWmpQW6G89Iuv8AdzxNQMvTc/xzaaKJ6j4j9IdFqsuM k8N/1ZD7khu731ZtmJJ2NRRj8+zfrzbiO27gAdyhUcNjRgDtWtflkkkOZaAP49jkgxUy3KpB336e 2FWqkcVFS3U08ScU81wIPzH0b1xTwrWLKvw1qSeI7fPChc8ayIyv3BHy74FBQktqiw+nuQiglR+1 v2OSBZcW9pcbi3SYKhdQjU5A9zucspmASmV3cGJoqLzjk35AgH22yADGEbBWTQ7jkNj28MILG1Eh gVdwJFU1QkfEvbCqwwqCziu7cjTY9PxxtNtjlsJeLAmrUG+/8cV9zUluY6ujfD0NBuThBW1JZoah SwWnQHrXDSab4o8fFxy4/tdevfAkk2h45GjYKTShqGwlvjDbdGoTIRWnLIFgBR2VYiKca032HhlM g5+OQlsvueJZVkJVmFC3TftmOYb8Qdvpchrgl8EOks8bGKT40/Zf298pySjIenn3fqcyIIO/zcLa RkMkdSV3FBWtPHIaWOxEuRY6idbjmqQSxSqVrxkG3E96ZHPojA3Hk42PVxnt1V1qu3X9eRqMxvtJ Er6cleJkCfPqKYiPh7OORxIi2kqCvbp/GuZXCJC+rgzkYnvCKUALStfD5YIggpMhIeTa1X9WZALg 5IAhWSQiinp37mmFwpRpu5RWGw+LoPAbdsYlrISxlYc1f5ivXJpBQ0dEJA5bn7HyFfwyaxKvKjLG rstARUlt6jsadhkQ5EZoi2e0ELQzbSHZStRyrsKHKpiV2EjZGusygQ8a0X4X6A0/VmJCMbMw330W B+SMQNx1HuMtrdgRSiWb4mfqKfZywBonIFR9MB3Zep+0D27ZJYkfBzdSKdR069MaUSpSJNCSK12B 7Yp4ert+JJoQo3rTIkshAFERVP8AAnrXFnXerIy0oTQgdcWB83CNgfh+zUEr2P39MldtZFbr7acy FkAKFSQVYUO3hgIZDIjFDhtjUnYDKyzjO1Qinhv4ZRkjYcuBU2UAH5fdmJmif4XIiXI5qK/ZGwru c15tspF2lSGLb7EAHb7sqkwmtmjYCqf3vdQegGEJifkg25Mffqcy4xADJcJHIKk1HcHpkZAdOaKW lBWq7+IyNm2VtpM6KASTH045ROALOmpEEi8gQTuad9u2U2YswUumU9B1B3BwgW5MSogHff2+/ByL au4MQWapNQAfHHZNrGQqor374hkCsZtvl0OTZBS67dzkCyWliPceGNJpT+Gtfw/HCy3eaydCT360 z0sPEyU2U8mAHfp174WBG7YPSh39sVVYiR/qjp7e2RLbFXBIGQbQmOg/Vxq9q9wSsCPzmcdQiirH 8Mry/SaYZOT0CG8DRFpm5TXSGVyRtVz8KgHsB0zitblMss41XDs7/RYiMUS0kCerCnFZGVgHU/C2 1ag9QfYjvlJAuqcwzNE8k4sktz++5TRSo4RJFNSqMKEOOppgkQd/x8XCyk8tiPxyTLV0ghsEtCzT QoKW8x3NTWoNB49c3WgAEBRsPOakmUzIij3MNeKRWkBUqYyAj/skV8c2jWC0WKMpbY8QCT4g4KbA qTTqELN0A326imEBhSk6yRGpFAQCPkRhBTVrFelDXrhZ0qIwYr27U98CFQU2rSn7Q/hiwKxlFRxY 16KpNAT44ULLgS+kU5lJOoevfwOKYlJGhH1gGVW4k1LJRgTllt8Ttsm0j2yh0j/3SBQnehYbdcgG sxPMto6ulRIsnYnvU+2FgVB04EsCTXYg77V/rhVYSgPEb12ZCPA/wwqvcAng1EYCoB64FcGkEZQA GppUbVNNz+GFUDe6W/qFowTG24IB2PfCJOTiyx6qdvK8YAO9Nq4kpOKyqssTnmvwtXcHocFpEZR2 KpEGBp9/jkCW7hBCNWKaMesorQjY9a/0yoyB2bI4yDxBTu+MqNsQ1a08MwjPwz+N3oMYGWIP4CHi LtVJPtrtTxHiMxdXjo8UfpP2NuLIaqXMK4ka3FF+Jdwy/wBM2GCBlEXzddqc8YlpooLleYID1+0O uWeJLFseTj5MMMw4oGpLo2miPGUc0B+2O3zyM8MMm8ebUM88e0+XejlVWo8bVB326bfxyqcf5wb4 zB3B2VY6g9NulfD55ASMfMMJ4wfeiYyTuKHLYz4g4OXEYG4opOPH8afPJtF2tcEEH78kC0Tjar8L xhSOSnti4pCCaAiOnqcyDTnQ1oTXfxpkgWJCW3amNi4IrUeJ++mWx3QDujNOkeSRKcXcMFVW6gLu OuV5BQb4lEek7ySwNEBLH8cQ2JoTUL7g5VxgASvZvHcQqxySqUPKRyVZpIyBWtR09q5XIA3yHcyA I5IczAyclqENSVp3yzhpHEC2zNx+GpB2UGhwsOAFRqwIKnYfCSfuwp4ejbMjIQTQ9dtzti1GJCGa XjL6dGFfskjYk9hhrZAkrKvwswIWn2lbvXIlmDSKXhxHE1J3+jI7tvECNlwKgAE9cLG6VEAC+IO1 PCmFidhsq0ViHJ4sBRGHYe/iMWuu5f8AVr1y0wVTGvHlIrb77bKfDImcRsoJtdyZAS3StCxFPlkZ RB2cmEiN15YMNuo2H05h5Ybiht39zmQktVgCDSpWtanbfNdljvu5AV0ZJISleDLQ8e2/epzHIorv amzkAAsRMNiR/L23ywAE+S0pHrQdPHvlxNKF9CQKbnvkLVY1VNOhBNRkSkNFC3hyp45EsgaWDrQm hrRT0rTrlBlTbS+Wz9WINX496HttldrHJRS8RMr8WFCemT5uSJLXG1KUp/nXIkbs4lrivE13J6U6 D549WVqDqKeI/jkqbAVMihFO2RLJSk5Vr3PXFkFKgry/zpkvNmwGSM02p4Z6OC8XSFYMDxPQHc+w ybUSQ4DluPpOKQL3VEBJrTb9dcBZxVRv9GRbAjtMh+sXMVsDx+sOsZbwFanp40yjUZOCEpfzQSoh xSA7y9GcxehGiCUNCQIfUCjYfDTftnCDiPqPO/7f0vSxjR6V5NycAsa8uKj40ApVa70+Ve2QMuiR e7I9Di+tcAAI7xVIQsKqygb5WSSa/idbqpcHnFq/kkWyihmVka3BWVSCQ5B+FgQO46HN52XIcNcp Oo1sfXxDeJ5eSRSjiXVehqxTqD7HNuHESy6kVQamrV7++2TDdFQklJ4BDUDqPxyQDKl/q0+Cvwpt v0+YxpFLpVVV5CnDoQO1cQhSRmBBI2pvvvTphpBKJlEuxQ1GwYdad8AY0pyO3ClAwU0Neqjxr23x QFKPmOSO5eIghT+1SnQ4WRQ0UQ9RxHzjZSODV2I9sky4laWvqqbyLcV+NfskMKfEBkQz6elCi0kt 3eVQZUY1AA6b/CKDwyd2iRtUZ+cgLI229a0FepxammViPUHwkV3BHQd98UqlxCsyqwA5Uq29DWnj vvgCxlSHglAXhUqV7HpkikhMbeYV4s3iB8sgQwIQ9/bQybqoV6dR0wW5WmnR8kuZStNqE/jjbsQA QirYlnCkAivEk5CRYjGQU2ljWREUNwK/ZCnwzAOUwlv1c/whOGy25tvVjqP7wAAnpXISInY6N2GZ x80uMTkgEEOpqrdwcox5J4zR3iXMnUhYWqzbrIKEfaXrU9ds3caMdnnsorJ6uRVGspFblHsR4e/t lfjROxbZ6aUTxQ2KIhmIbhKtK/jkPAA3iw/N2TGQVxGobnEeJHUdjjxdC1mNG47IhGqaEUbeuUSj u3CW1olISDyFaHr/AJ/RlVEFJkJBW23PiAKjxy6M3Ey4q5N1NCD1PUZaHDmGlFNq/CTsfc5JxShQ srSM7sWhHQjYeFckwIQV8oUyF3DM5HxDai07++WQYFB2tyyyBomKOooVbele+SlHvZwkntnOyE+o rC4qAXlqaFhsPprmHlx8Qrp5OTGVFVu2uGf0lHFtzzXpxPYk0pXK4CIF9G2zdIWEJEXqCSeo6nc7 gfM5dIk8mNAFt5Sj8qfCOx9vDxwgbNRLRCuqqN2JO5771x5MgN1BW+MgDi67kkbEYSo3WvVq8Wo5 r13+/AGMoFq3Mix1kpzrvQ4yHcyh3FMHhrxKknYGqn275RizWSO5lkw1uFnwgstf3n2gCdqUpt4Z kBotbBdiaf8AdvySlOgNW70Ne2SMaCLRqE8KkgGtOvbIUniVEkYEkGinqD065EhsiVQupoGpx2p4 fRkeHubOKufJsRhTRdh/Kex9sqlI8urkwHXo1WjcuAYIasD0PzzX565crcuPJE/VnleRwAgQhmUU JUEdBms4q2ZcQCtLpYMXqqfjXd1rQf2YwyENfi70UAhUkh/hIFQw7nwzIl5NtKhRDsG6/tV6/RlV oWMhBoTv/L7ZK0NEKRU/5jCSkKUqgnf6CMrkLboSK61nC0jc9Psk/ceuUSjSZxvcL7i0AHJKnY0p 2/XgtceRASxrQ0/HrhDkxKiQBXl17HC2hSahNAaDxxZhRaoB8PbAAzUnodqb7YSzCnQV98LJgjHi SrCh756K8coTQcjyU712ByQkwlG0MUkiZu4PXxGWWC08JiqxyKSfHoT8siQ2wlaqNhWnvkW1kPki BZ/Mtir/ABFZOSxUryqKdegpWu+a7tT/ABefuUSqQI73oWpWTQz8A/NmHIR9Su9eo7qc40S2Jd/h yWFUaJ9deOOBSLxUDqTupHjXMUEk7c2P5ngBJ+lPbezAsxEhlSWAfFCFqUcCtV70wEE7932OBPJ6 rNUeqElvEvrZZiSsyrwZz0268l+jpnS6KUZ4o+X3ur1WKWLIR0KSzxcGcPUvUUc+JzZW46Q6g4qy 0qK0/rlsQ3RKEiDbrWtd6Hr8smUg2rAno2x8O/TAtrmEpNB1Aqf1UIwotEoqsNgBWnw/1yLArnDR snwllbYn+OBWpIyGFQQAasOpPXriFQV2bhbkektEoKMKmpOxByQZxApZbOTchGKqQw5h9gVp1Hvh LGkVNZK11zDlmK/FFuQQNsALMTPDyQwka0LVd1hc0VlI5A/y7+2JFtsZcXvUSpk5Vb1ORLhtxQdQ u2TDVkO65eDIxK0D/aB/EEHxwsFT02UKYwKA02/lFDQZFFrXt47giSI0kXqvjjdM4SrmvHpyhRKS H2APSowE0kRPRz/CxjHxD9k5Hibxh2sqUkayca9T496Y23YyQr2sDKvT4m2offKZydhjKOWPiio1 Ph2HtmDnAlu5eIGIpD+qUc0aq9SBvmv4uEuWYghpqSsHj+F/wNPHM3DlEhRcaYMVssIlj5j4ZVND 41HzzY45cO3R12oiJDzVLaXmeDijg0PvlWXTb2Fw6yxwy5hU9NTUspIJ2+WWwJDjakCRXLGyVIPJ eh8RkzRcOOQg0USiK42+YPhlfJtM7REbspowqD1OVSFtsDW6p6a1Z1O/h2ygRILkcYOxadyT8I5H 7qVy2E2nLgsWHKSrce1OvY1/2svBt1mSFHd0qhoeKryJO4BpTvX5YRzaSlt7bK0ojoVip8Tbk1p1 yyMmshJS7RyIrA8FWhkrQg+Ir08MyBuEcinmkT3V7IysykIoZ0bfkOgptv8APtmFn4cYtysdzKYL dhojHEauPsR79OxPyzEng9QlLl1b4T2oc0Hc8liqRV5G2IPQ5l4yDy5MckTHmoM0nILvzG247Hxy 2g0ktVbh0q/RQNgPffAUUu582CE/FSlDtv8APINoFOIZFYHv9k+Bwc02aVrZo+IEi17sy9TXfbK5 g9ERkFdZaFuO6mu4pX22wiPXqgykdltxaC6jCCV4mBqsidR9HyGWQlwtUhbrW0tU+KE8gtSrUHEc m+ILkiT1YgqyySiQrxHU7nI02xI+KqCeXy/ap3yLYFdSeFWJKb7eByonfbm2gbb8nBth7dfbfbK5 R4p/BsieGO3erKGZZI1NC3GgIqWIPQZrtTQkD3OTA7WuikS3i58mEwehi7Ee/vmHkiZS25NnNEyS vMFNu4p+0tdwPA5TXDzYiIHNBSxOrFvTKggmh3Ap4HDxbN0aLccUq0aMhuwU7HfDxWiZHVdPE5fc UdRUnt9+EFqBFIcnajbd9/DLaZrCp4nvXenXbKyCzBQvH4qmu+3WmAt4KMtbk1Ebk0oaHqRlMool Dq1c24Zee1BsH8T4UwMoTrZASo3fp38cNuTEqLpv12/HDTMFQkBAAPU4C2BRYfF7jrhBpkGqb9DX G0pLqHlO+SN2ijdzFvMhFXUU22H2h7jO9jnF7vCwzd6VJoF04lEbqLiOgS1c8GkB6+mx+HkP5Tvl pzBlKZHmEM1siuYZ+UE6gBoZlKsDkuLqOTKOQFDXGnMW/dMOZ3BHcdMnGfetiXLm3Z2l7NPHZqlJ GGzMaA0H68ZSA3Z8RAeueQ/J0GmyW+ovUztGvqmUDmjkE0VB9kKR365zuv7Q4oyABoe/l708J6lH ao3p6hOqrzq9Y35bk9znMxNiubvsAuAKjZ/pRNRtGiZFoSyVJ3NPiRqfZrXKQADbZk8MwkCyCbVE unSC2Yx3kjhBLT4omr0cdCppl0TxEVt+OTro4OEXLeP3+5bqulSNNUp+8ZQJqEcOVfEfhXN3glCu KxCY5+brjOX0/VDp3hI7q/t4YZrN0BuYQPUdTyFWrQVPgMz4EzIkD6WPhiI3G7DryZZZCK0AFK9K 1OZ8A1hbC9eJ2PHcZIhIKJRkNWYcQx2p+yaCtciqokLGRfi2O3sT9GC2NoqKLbcUNfsk9aDeuRJQ 5uasQy1qaGteo9vlgSs9QsWrQLSm5+I74rSjcOsRB3o1FBArufH2yQSIkqMYt5rn0pN248uVKihw sxEgW5Z3huJYV5cE25Gh2r2+/BzbZQ2Eu9TuJYGC8wGdAVY9QCehK5IMREj3ISe3pRK/aBLAHj0P bwyYKONViu0ZOhFNietPniQ1EKhe5rQEOOxOwIGBXRuTIkgXgx3O21emJCFedlaXlUA9jTvlXk5e OFQElFyoHHqRuDSmRc8RFbLQKnr8QH2fHbG0CA6oqzdlc8hQGgA8NsryCwzxyIKJnRqFq9iG79e4 zVZ4Ecjs7TDO+aW1KSdarWoGa4mj5OfzCtbsrsK7HqffLceTe3FyxICNQGYEAmvancjxHfNpptRx Ouz4uFZ9UOz9COhHTNjGY5OpzYydwvj7qa8u3tgkO5pxZBR4uausbV28e2RtkfUrJGCQR8L+PYn3 wGQaeCQOyvuBxp8X8p75CXLZuxmzu0DIAKrsdya9D9GVWeRc2o1YcRyHIde5wUAysrQSNt+4398n EtWXEJLl5qdjv2PQimXXbrMmIxaubeG7UM4KuoojA0I+7CDTQYpUImgmMjRc4owROR3U7HY/jTLb sMQlsoEN0WtXZYKH03qVp7GnbLRuN0A0dkxtGhuleSwLQPCKvG5qGr0p4HbKZAjaW7fGV8l4uHmU rMHDK1Au1K+57HAIgcmZkTzWtb15cCGK9aHeniab4eJhbSu4j5Fdh18flvhIVt1UryUBhQEU6198 g3bUrokhSmzECp3rUnKZSAZUeqKhtqAFKh6VLHpUnKjOzR5LXVR5OHIkpUbBqUp2AIrl4js1CXMI mPmzMtGUhAfUGw3/AJfcUrhpgTa+CNoIlWvMrvy61rhJssQuJqd9yB08MaW21oyEL1/tyBb4FUSR iu46bkeGUkUbcuJsLiBXl0p0yg5SDw87bRAc1w240JqPsnvXHLwzFFEIGPLk23FXIJ5V7jufpzAj YDkLoW9KaOagI3PEbHw3ymUeIEJO+yONxbXKMjAozdD/ABzEMSGIiYoWSOVCUFDU7CvWnhXAC3bE KZlYgg0HanvmVCIItokKWHg+1aV6jxyYiQoKmyOG2rTwyNtgUKmtaV9qZEhtBWmMgA0py6fLvlRb oytsTFRQ9B0qdsgUmK54wUDdNvDpkUxlWyEdWBrTb+mJbwVjoGpXY9BgJCQULLGVodiCemMZNoKn U9K5O9mTMrS5tdQggvYG5RqSqyspDr2IYdfvzp8gMLBeDjiJlSXeZdGt7qJIx8PrGrSBQQETc09z 2yeHMY7nkGcIGUgBzSibyrp90kKG5klC/wC67o+opoOgkA5p9G2XR1RBPf5ORLRzAs0gJfyzjkv0 t4NRNrFItQjAOee/whqjbbrTDPtMwgZGPFXd3NEcVmuRUNN8g63b6wltexmS1U8xMm6HjuQx+0vt gPamHJjuB9R6dW0YpDnyZ+biNXEqAsOKlg60o243269voysw24fu/QxPOwG7q60qeb1XuPij/Y4g h2G3FW7Vr0OaSfZGQy9J9J7+Y97m4tbwxII3UIblJp3m06BLWSEkXAm2DK4pTkfs9OmTGhx6f6/V xcjHmCPLqPmiWfJkFXt5om1lljmmuLcBpWNJIakioPJCD4dxXLMXZ2MxBEjv+OS5M8iBE8gvOpR3 MZuiwglj+Ce2lNOTH59QfwyOr0U7qO4XDniBwyYZr1/b288zQMHlkH7wA1FRsKZtdDglGAEmrUZI zOzHmlMvFgKN4HNkBTjq1stK7fZH+fXAVKLTksdV3JPf/PpkFRdqz8/8habHcVpkZBjaJe7jAUuN gan2IyFLSyW7hKFy9KbFj2PvjwsghLlnQesJOI6svY7+3jkh3M4xvk29xFKjrSjEfDTqNt/7MaQB SjYWhihSY86Ak16ddqEYSW2c7JR7Krj7C1PhsaeFci0GwgpYkR3YiiSfaUCm9Nq5IFnZI2UeaIDz 3p8O+3UA/wAcmwopfceosoqCnUlj/LkxyZxAK6C5owUn92exwc2WXCYprBFGylgwY96nb5UyBLRa nOkoZhTaoFK9PnkSQ5OK68lhJJBI36A9iMgXOxDouIIPw7b0O3hkLcmuiLt1XgWcE7VAPUH+OUyn vTaMW1ooMqoTxFPbMXNIgM8cd0smjkpVgFLfsjNNO3aQkOjrdyDTt45LHJhlij4WYtRVox6EZmac k9HX5gOpRijjHyJoOhHbNjikTzddmh3Ni0hn6OUkO6kdj7ZkCRDqpyB5jdahcOYZl4zAEgDo48VP 8MMhtYXDOjwluaRUAqKEb1O33Zr8mo4ebuIYAeS+C9UmhFPfDDVWwyaEcwrSTDqpDKenjvlhmCiG Mgb81jOFIFad+m3vkTMcmyESRvzadywHAb9q5Mc90SC5gaE1+KnzpXwyyJaMgBDgTtt07dO2WW6/ Jj6qV1EG5tUUZaU9hStMmC4xCXNp6tMil+ED7NXt2GWcezClPUrSS0gU2zekGfi0ddy3z7j9WGEu I7sjtyUR9W+rlPVZZJtpQa8WkIB6neo6dcO9sxJSs7ddMnWR+RdwVYse/h4GmGR4woAV5b+0dq+m /Ej4iNqD/VyHCWVq4JVfVhIKMAwJHUdsB32KQUVAjScFJMZJ5KNqE/R3zGykR3q22JvZM/VgVD6f Mn4qu3cDptvTNf4UzK9my+9DvHHKSVpy+1TNjCwN3FkReyy3gaO5aSpUuCCpNRXxy2R2YgdUxWnp bU8T865X1Z1sg5EYSchWvSg798sBYUrQpxBDbEmp3ymcnIhGl0kYoGAJ7VG1cgCXIiQGxv1+EjoK ZiZ4mtt3KgQuVSxUDapp1oPpJzEllNX1bAFwjZ2AFWNNqH+GQjnoUkjq6hJodu3yI2xvbvSqwQBz uaFmoR3IzHmVJpXltJY6nlyA6Adv15Qd0RmCgnBDbmpp1OGMqbSLCmwJ3AJHY9KZkRm18LllIYBt 1I39vbJFeFzRh/ij6/y4CkGuam4YUDbnpv2plRbo+Sk6NsVFQdh75WW6JbikFGQ7EnIJlFooNypN QdzhKQUO6NUnr45AtoIUTy40p164AzUuHxUrk9mdse8uebJ9MDRvIxiZaAbECv8AMD2+Wd/mwCTx 04XyZ7pGt2+rWqRR8VuFDcIKj7BG/E+Ptmn1OE47NWDzRiPDIE9C1cW81s7RlSHpyVKbNXoQTlWO cZgEmx393kXbwyCQPDz6hZLOHMDhzFPFQxlhSh8DXrmWImIIIuLjzxxmbG001fVbq4hgmWXk6hhN HGAgcbjka+2YWLRYoEgx5na+bRIHiq0IZy1uJXPCIswZyftDpxYVBG+4IzLBkJEDf37fI9WJhckA YLuZ3UcYhcLQliKSEfZZSKjMkcmcpi7ASya8ktrp4ZF4MKBipI6bLUmteuTEdmUQDuE+0tZoXQFe Ezqz+ttwlA3Ct4HKpNOSQb1aIXKxmABbh1PJGNNgpJ+/ADw7lxyejD9Q05fWMiNy5UJG3gOlOuZU ZbKChWiRVBB2XY0/DJgpVYQWYxncjda+56YCqK4EgCmwBHvt/t5FFou2VTEQD8eRkxKncorxcSBy U7nt9OISClTTyQNxZvhPTbangRk6tlSYwyxzx8T7EVpTfKyKQDSlcrSQKTxqKKy0whvjvyas72SO TidmPSu48PiBwFulgBFpmksU0fKVB8O7DcCo6EfSMi4k4mJQTWtpSUAszTMC/I9zU9u2Stnxy2Pc g515NwoCdw1a08RTxycSgx6hZNHyqjbMvQ+wyQLBRfS3ALCjCn7J8PHDxNkZ3sUbBA0cS0+Ll1JO 9P7MxZZt93cfkIyhsqiScMqj4qbCo32yRILiDAYFWFukgLR/7IHsTvkCab4b+9tIRx3G/c+JHhlc pOVCFhcqspIc1Zdx/TKiA2gkc1RHIHIVoe2Y+UcNshUlGajE0FD2zT6i3Jx7IOPjy+HY9CO2U45W W+d1umNoRJt17V/jm300nV6iKaFVeg79/fNhAU6fPLota1kRS43477fLBlycMSWOnEZ0CpfW4ZY/ SuUJUbhhsVPiD2zAxdqC/Vs5WbsmxcCuuLZZ4hRvUB+y47+zeBy/PijnjcS16bUSwS4ZoMpIjgHr 3+RzXRiQadvxCQVIuZFF2pvTxGZMAejVOuqMi4FAG69KfTmRHlu48rB2X+l8YIHStPpywAtcsgpV ShorClB0PjlgDh5D1CyWM0NKjwI7UywOPLJexUk+Jyu/hSlNzvk3HI3XJEiAoVHFyCQFrVTWowFj SBubK8lU2yyK8alWjqCCCBUb5ZGYG7Eg8kvmtJQhZw8js6g8TUVI8PGuWCS0gJYPSZjxYK4NQ9RQ 1IBY/RlgNpGzcAtUiJeU+q6cCOvfx98iQbZAI3TrhXha1JDSREjxHA9CDlc472yCYRSBGUyD4AAG cbcQP2tsx5gnk3g2KKZcGSFmVuacauVFKAmm/jmGCDKuRSTtugdQd7ZVuIE5gsKqm5AYGtM2GMXs XFkqWjq0MZEvPjsSBTcdsMmWPmmEZHHrTvvlMm2IDXOMjw7YCSzEQ0GROm6nt4HIbltrqWrdrjk3 qMpUElSlfsnoDhnEVQYQu7PJVdgxPIbnrmCZCHpLmxF7haOo32608NvDKJgS3DcNkRDMXcEsFep3 oKH55izx17lpVmaJ3IlUxy/zU+ED5d8jjuO43QBspSxyxOvMVQ7K67jfLRw5BttJkCmURDxhWbnt VWGYRaZbFAXiNE1KViO1etK4A3wNjzUFaKiAUoeqnY+GG2ZBUpoU4c4mJ68gfn2y2OQ9Vjz3Qyu0 bb19u2WxlaTG1VrmNiqybb9fnkSmMCOSxoqVblyUdKdBXKJN0StIJUChNNq0yNs1wUiprvTrgYkq U8I5UXp2PicbZxkh3jqtOnWp64G0FQ4mvHv4UxbL6pTqnk1WJlsiAN2EigmP5Mu7Ifwzvceq6F5G UZQ5hjQmubG5Dg8ZYmqGU13HgRmVQkE7EM/8v+b5NUhlikAd4lDvCw5AitOadGU+PE5qdTogCCNj yv8AX0PxZYRvRPuTG4htrwViBimWnKNzsfk3b/ZZHGZYvq9Ue8fq/V8lmTP3hWja5sYrmEkcrhFK ClSSOy0rvk4SjPcMpWaJQqXF1NEBF8LxovqkHnVeR+Lj4fzCmW0EENXSNPA4HGKVivK2GyOoFfUi Pue2INIil8NrGl36F8rKp7N1oehr4ZMnbZmZABGRySWCgM4uYW+xIa8k47bDBVuLkmCiYZRM5uGk CiIVUdeTAcqe1BU1yrIa272pJNRuvVZ2Zgw/ZNAu3StB45dCNMglDVZvgJqx+Q2y4Mle1Cndttzv 7DAVRyoqxk12NdjkLQQrRU9uRryFegA3wFiXCJVduQ5KBUr2rvkUkoS7tVnj41PLs3+3khKkgoAR 3FrQt9nptllgp5os3aTRpG4BLEA+Ip3HvlZjTZAdVRUC7msinYMoHIb98i3AtiaSN1WNjwc/2Ux5 oMdlCW7jkkMXEiX7PPp/nTJUgYjEcQ5KTF6hZKq61BbsR4YVFEbKjkdGAYCm/fCC0mO/cujrCjEf Ghrs2xHbqMPNiSrxSI0dNio/bpuK+OYebFbvuz9XsIlersjUO4zE4zF208cZBEJJE3x0oTsSOvtl sMlhwsmno7BcYx1A9gcJl3MRHvWkMRTofE9cpmO5nGTRKioG/vlWTJumMaQspHOtaA9B+vNfliJG zyciJoUpBTz9z0zGhi4ZNkpikysEUsOQpm3wgU63MSmKkOAa1qaDMmOTucHLj70TGylCj7qTue+C cgebjDGY8ktvLQq1VqUPWmwGaPU6aiSHc6bU2KPNDwSTQH4TVT1U9D88s08pwNxLLUQhkFSCMolw qlQOQ+0P2h/XNntlojaTrBeHY/SuSJB1FTk4462LM5trCJghLmnelMt4HEyailZ4GXrWm9T8vHEB q/MCXJaInqNqgnepA2OTaMmVC38k1rbn0SZZeVCz/EQOvTbLIAE7uNahHcFqFhu32WAAHTo2+xyR iyBV1YkAjYU2bt4du+RKStkdo0IjIHLua7EeONIUL+CZ1k+rtxkZPgoaUcUNRt4ZKBHVBSxInuUE Uzss67Dn0JFdqe9ctutxyQFCfS7iENJERy6PENx8PzyQyA82VKNtDIOEsDUdmo8X8o70J6/LDI97 IFNrKWSdiqKvpAmsh+CpG42bxzGnAdebaJkDbkjra4Mkcik0jBqV+WQOPcHqxlO1KWGFJeUlHBQx lKkEo25FK/jTLok01qkMEMCrHEKQU+Dfp7YCSUg0rR8UBDHitPh+QyuTkgAi13qIGIAJXqKCvXI0 We3JosORB2PYYLZcAVQVoaMQe1N61zFzZJiqDfjxhcxNNx18PbK8u4bYBdFIgVi0fLlsjnsR3zWT 2OzdSrDA8zcFoC3cn2yUs1jdFUrJM0avFOvqRqaHxU+zZSRe4UxvcK3ptIAVYywkgiNtumVy296L r3rEimhcmE1UbvG21D/k4mQI3UkHmrloriIpKtDsWUihB65SdkC4nZL7yxeECQD92TRSOw69slGT fjyXshkuuLc6Bj0JyfCyMG/Tt7nZRwkpUAUxshbIQVxHImzrQd+vXCZt8KPJdBOU+zWh6jtkbZSh aKQJIQYjRhvwPQ5AhrNjm2Up7fMZG0WscChIoFO+2G2QQ8qLQt9geGC2yJKF4fFXenWn9vhhtutC xXE0LB4nI3238M7gxB5ujBWXdnouqcjPbGGd/t3EJ6nuSh2PvjCU4cjYacmAE2DTH5ND1bQZ11Cx YXENuS3qxfFxU9RInUKRscyhljlHDLa3HMJQ57M20bzLYX1qZ46B0UGaIgGSKnXb9pffNedPKEq/ hciWQTF/xo2Vo5I4LmEFLlZKNFEOJJJ+FkU+I8MsAaASNkZBaaS0/Ij6tKqH0Z/sNyqDWRTt3+nI kliZSULq2lt0WOWH7QYVUVT4tw8RH2SThBteLuQOoLb+iBczNIyiiSmtPs/Yr8z1ycfJhJAo8tU5 o/CtEdl3O/YZIkdGmlUpFJF8KkxqtSForEgE8SpryO3XKiSDaUnv0rVo/ii6hh3G1PvzIiUhAovF iKV33B+WWJRtsoC+7du/9cgVCNeIlQOoNR7ZBbbWNgo7dd/DElC8SFVWis1WAoANhXrv2HfIlFIL 429QuvpFT8JFaFTWnXJpVbZo5IiCCwNQIzvQnqRX5YliUvvbJ4Tzj/ui1PpyYNtsJKtpdemnFwSA a7Hv45Exbp8rR8kCyiqGo6r2HjkGmM62S2ZG5IxWhBIr3pTqRkw3AjhIH48lwUFOEoLCnUePti0k 9y1Yih4/aXY1rvxO+Flx264ilEqtGa12A/mA/AnESCiFoq14q1SBxfou4ofA5XPdvwkg7oqSMnbj 8I+imYWSI6u/w5T0UVKhutOu2YgIDlmyFWO6BHE1r4H8MPjDk1Twnm20q7E7eHyyg5gx8MrGZWj5 02PbptkDkuNo4aNIZjQkdj45jA0280TAFbenz+ZzPwgEODlkQUyt4lC7bHv71zJ4KcU5LKrwSML3 JO4GVyAB2QCZBZN6iygg7eI/jmBm4+PybsfDw0ea71+XwOajwyQmTsWvw63ChJEA1R0/z2phxxot nHYV1iQBSBvXqMz4YwRbh5cpBpW4VNT16k+OXgnq4ZI/h+SqBMqsISA/ID4ulDsf15IV1cfILCL5 AKqlmNOrn9rxOQLjxFlDtKhchqhugHjhot/hhC3fGShQ/vBuqHue9QMlAkLPGOYSl+MgoEZ2ib40 NQTtXMgOOrW11EaRt8JH2a+GCUWQKKIqd90NcglY0rIUQgspNWJBqAPl3xpVtxBDdModEkjBJL78 gem1MYyIRSlwvIqsjLcxqaAEAOBSh39hhsHyXdsWltMWaIKrn4QSN1qKt8jgMyOfJsiL96nJpZam 44ggjqGUjwpt8sY5geTIwIXXMV0qrMo5Sx0D/wAxU71I8Rk4kNaHsDb3V5G85b14h+7av2qdm+/J ysDbkxTIMqtxYcVbct4ZBm7ktePMUHc5Ehsh3WvEqhSSeAXw+dK5XIH3uRCQ9zUjciRyLdwe2UQJ HRySAQuStPl+BwmQPRIiQrEgqAcx82zZBexuBbxRFv3DEsi7ZrKjxE9W7ZUgoGqQad6V2Hv7YMgC ouPhOeKkA1rRuhIyg7MTsqzWqxyCZCVA7DalBkRPakRlexXNcc3AYcSejgbb9srIUQpWAUikgqtK A07++QY+5DTSqqlGAaLv7D6MQ2Rj80puLeNiJIa/6pH0ZYJOTEnqpQh1mUAGm9BjI7MzVI9kikTj MKgfZyriagSOSXSWTwnlyDKSaEV/HJOTHIJNKXUgg0IwWki1f1BJsRU9ajbC18NNSgKpIG42I7U/ syCY7qJlVkWoLOa8/wCzDTPhoqfrR9OJp0p3pSlcaZcJSvkn+ffO8dKSujKKwG9O/wB2BTaNRKNz Q8Xp9rah9j7ZE7seLohV8uaTLdm6hSa0vB8am3dVTkPtFQyt/wAD0yQyzqjRDRPGBuDSffoiU2kU hkZ3Qgo60UV2BZQCy9e2Vie9NfFunC2MkNuix1nSP7RADFWB3qp+0hB7HbIXZa+JjeuajqemyNZy tztZFDodytDuOLH9WXQiDu3Y4iW/VD2jQX88cYYm3hq0k8hISrDpQeDYMhMR5teXbZFC4NmH9VxO 6VDAghakUopO59umVcPHyFNJQmoFTZLc8mRuFEFartUHie9R1y6Ed6QGOi+V24sApFQp3402zI4G dKkJVzy6kHr44lCKjUjjTau49x2yJSEUj/vGFQwWgDeJPXIKUUKUDED/ACx/HAWCjOBTaoJG3h0x C0hZJAWoTxYCjHxpuMNMgrxoWjWvhtXx6bHFips6BWRqsEPHfY74WQibQskcLKWQ0r+yetO2EFyJ RO1rbaeSH4f919/bDVteWIu0RKEeMlSNt6da+NKZFhE7qBiZWWhpWtRTbCGZNq0MThfn9rltWmAl FWWjD6q8Ym2BqE6kN7UyMjTdiviopjaGKSL94ORpxZehOYuSfC7SOHi9y94lCEVJU03/AGh/tZjZ amO4uTiuBHVA3UDfbSvbbxzDkXZY5Dkl1XRqgn3zGkacnYohJa02HIbA5FqlFe0p4/5J7HfKzlpq ONpQHblXfYAY1bXI0jbWBgw7DwObDTghwcxtNYo25AH7+2bDanXEkFXZBWgFaZSQyEtrUljUsRSh A65TwAlJnQWvbUbkNj1p3+jB4VHZfF2b9Gta79yPfLY4mo5QFjUBoDSh7Zk440HHzZbVI5lFPU2o QK9t8t4XBlYKKWWFweJ704+B6ZExQJle0ZeOldxtXwxY33IFmJJU/bXqB7YRs5MJcQ81itTau46H DIWzCjdQ+p+8U0kAoTU9sYTrYteTDe4SuQtzodnXcMRt12FO+XinG36q1tcj19gwZkAYM3wbeHgc Eo7JtGlg8YdSRXffr45WlQDvG5ddmBJJOwINNhTthq1RMMkbn4R6b7Fk2qRWld8BCq7Wcc1GA4Op 5GnU+xyHFShCzG8iu4tw0JI9UH7VfAVxEI0a2LdxnvRsXrGaRTGotgA0cobdieo49qZCthv6lO93 yQeo6c00cb2nppIGq8jHqv8AWuZMJ1zaSSpi4vYCFvEQc6cWIPD3owOGgeShGempZex7BhUZC2cD RauehTl8Y/lp37UyuEa9zk5Jj4oT0mWNWBo9fiCk7e9DkxIEkIAoCjzVoWlVlRvjLn92yitdq75V mA4SeQ6uRhkboogAEgCvif6ZrRfL8FzSqKDSpG1a0yJxg7otXjFdi1OWx+XvmLPmyCugSg6h+nPs PoGUElKOiMnEK7cqdH8RlEmo0plU5EJ9Iyu2zoqooZSoJr3wFgVG5gmVKp8QbZx7YAzhIHmlRd6l eVHB/wA9sm5NBTDhyKmjdj3+nCzqkZA3KCj/AGq7GmQIaZCjshpZJrckN8amtOnTwrgi3RAk0iRz JyTY9OPfJndJJjzUJE9Nqmqt0KeByJNNgNr1dGPx0AI6dcQWJFclGaFiCUP3dsJDOMh1QVZefGn0 Yt9CkIBuM7t50Ki7mnXxwMkQjOhHIVSv2e9MipCcaaryxOY5VjC19PmaAsN6VOQPNx8uw8k6T1YL T12QQzxsJZYFI4k02kQg9GHUZHmXFuyrRT/WIzdWQ/ct8XpqQGR61+z79DjVc2J22KG1Gazu9PZJ lBqVDWzqPhda9uu9MMQQVsx3DFbYw2dkfTdFSRZF9MglqsRv4dslIGUuXcgyvmlLJqNxI0sIaQIT 6m9dhvTxzJFBOyGmvpHPArxRakR9hX2yQitIGY8nLMCSxJYmm5yYZhGW8QCcjX3+WQJWkZB0HwVp svy+WQKCFZfhSoFe7f6o9sDAotQVoanfY7jw7ZFipTsKjagIIIxpkEG7BiQD0oxG1QOn8cklE2od XXiSFAJZOta+GAoFHmqXCo5QnZW3J7gjoCMATFCSK0XxMKg9CMLkXY2QpJDcl3INSB74QWyUAV6S vQLHTfqP45JxjCkZHEG41AIA3H45ElqtUk5BC6H4ejKdxTuRkWcTexQdjGVuTDX4D9k/P6OmGcrD lRxEJw0HEUAo9divfNdkAkNncYZmOx5KYkljqCd/HMKVhzeEFZJIHHx1DH7jlMjtuyEa5IK5t4yp 49fD3yokEU3wmUAQVJHSmYsjTk81VJGI3FfHvlU5Wd2uUVWDj6gBPuD4+2W4Z7hxsl0m9qgehOwr Svvm1x0XWZTSZRCgIO9O/wA8yYy6Fw5DfZ1FILE9OhHbAQOqN1dCrr8XUbVywDvcWR4fpXld+lR2 7jLIxcbJlUJE3Kht6fL8cmGk5CUJ9n4WBoDXlvvU03NBk2PEo3TyFohFsQxDJ0IB70yUfNC8GVI0 WpLgbt4nfrjstKf1twa8jHIdyD88lwsF4dxJyYActuQpQ/dkSNmcDRV2QMKgUJ6jKgXOBsWtoB2r 4jxFcBDIIe8gSRFJBLneo7jJY5UWjNAJPNbSRbj7J6+G3jXvmTGVuLyVLW5aI1L1FADUVI3rtjKN oukfbzJJII2Iqy0ptuK9srIpla+S3WKYyS1aFjQBVP7tq7EU7HADYVGWxYBjwKuC3wnqN/auVyDM UipauoPEM46jKoiipQssls0DTwMeMdRMtDyXbuDl0Qboo4kPptxB6MrxPWEEtTpTvt88tnEosJgU V6hxzjffid1oemVWrhEqLt1H2T17U6nIZJGtnKwAHmoyLINxTl40GYcskgObnCEO5Bh+agwOrhN5 D3b22zPgT/FtfJwskAR6d65q0aBlVlqDU0O+1NvwyOShd8mzDIy94VRFwXryruDXMXLwAjo5sJEj vVBs5A+Ja7NShP0ZhiMhzbCihGAAQwbkNwO3scqBEiQdmNkIy2HrIVCcHQD4/EDscxMo4TSnbdEO gIJA+Lw7HMcoBQ7O0b0oCPD2yDaBYXw3EZcopqw3I7jAWMoGrRayrsCPp74GrhKA1PR2uf39sxEg HxCuSBb8Ofh2kx91mR60o4qDXY4bdgKKPt5hzCsTxK1qPHItE4bI2W29SGo3U718MWmM6KW/VWib bbuCMNuTx2vLBl4SpSlaNjsWIFclGSGSNBT4h1GDh3ZiQJQhmZT3oOx7jGy3cNr6xcfV28Ppxtjv ySlxTpWvhneujXRSCu+xwEJEkSDVf5vH5ZFFoqxYev6fIVNHodxVDX9WAhjM3FksSXLRpHIPRcBi sZUq0QLVXiV+0uV7OEaQVwiW90j3DtbSymn1uEkDkdwWX7DA/RkhuGQNhQvpL31xLdcZkiFRMtFM lfh8D2x2qg1TI5BKJvQlYlI+JJJr1U9NiuWhiENc+W9WtYxdQ3A+IluFCpHXYdQdsmMgOxSJgpBK sgkKy/C1TyPYnvXLbbAqpAaCgqG3+jIkpR8EFEWm6+B/z98gStqzW3w81+F/E9xXBa25TIR1oV7H oQP64oIVkaRqMtUbfkvUfdgayKQ9y8ykq9OJrRdyDTwrhFMgorJHO1d1YfZB6ip/sxIpNI60BJPI 0UGgr3PbAWsqrhFlCGtTUgj28cDIA1bU8VQVGynqKe1P1YG2M696VyQPG24IWtetK4bcqB4uSxJP ioooeh28MSWYwCXVF2060+NaHYA9iO2+G3EzaeUD5I4ulCy9OnTaoyLQIlfDDGarwoR8SMDtX55R lJHJ2ukkCKkiGbYH9odfnmETu7MRWTxGVQFQcv5q5VlumeOXCdygXTj8J3bsxzGOzlg2pnkgP4H+ uY8yy5qLwLIVYEDs3h88qkLFshOtlN4GR2CsGWtAyH4SMxydt2QnYbSFuqDLIwvdx55K5pjYyEAq fHYfrzLxSI2cbLESTNGFDStDtmbjnbgTx04g0JFSu2ZwgJCi4kspiVyzBBUmgy4QdfkyEla2qwLQ Dc9V3qKjqGIrTDwNEjfNBXc8z1Cj4HAZQTTlv0FMnEMSgxczoqxlWiC/AK/Sa7/PEhQvRmcBwSsj EfaqAa/OmFVWW5aSExLIQSR8cZFSBT+OIG9qSVUxCZnINQSNjs1aHp8iMbpC1JJ43+IUANN6CtPb CQChMLaSOUEoeLfyHqMx5inLxGnOVZ2C9tm8BkXIiQhpI2IoxJB+yu1QfDEFMo2FAojqwYVTb6Mt BcOYpBT2LxksoqK15DvTtlwnbVVe5Tj5I/xHivKpI8addumEsU2tLndkYfGQCEbYMe2/v2yqUWVo uWD14zLE1ZIh/dkDYE7r8zkAaNFKGubqWOFHtXEqmoCuR6oFOlB3GSjGzuzKnpsz3MDyTrxmRQs6 0oroTQFv45KYo0GCpZ2tpbtLGjMBUcoz2OMpEoCZIrEdKEnb5ZWUhdNURtSu3QfLfKYG5OwkKgou VaMOp5BhUEdNxXMXUAxNuRilxBDLCoUBQETevEUpXKzlmfWd2QgBsFO2Lo/puKod/lXoc2fEJRsO EYGMqKLADigO4NK5i6jTcW7k4cyOsNONzyCOFZNgp7981JzTx7ORPIA3JbPbzJG5DF/5TTrtTEz4 wZAVSYysJhDbekvEHruadMwpz4jbAytV9M8dh9OQKLQlzbqxq2zDcEZG26E6QTK8ZFaAmhBB32yJ DeCCjIJlkU8iOXSuLTKNNmaW3YuBVOpOBeES2UZxZ3lSaRzHo46V8DiCzjxQ8wlstjNak7Eg71HT 51yTkxyiSLs7skBe1NwcQWnJjRclukg2G345KmkTpLp7Vgxp1/D6ciQ5MZqXqlX4OaDuPHphDLhs WFG4t1lBINGpsDktizhOkD9XuuXp0H3dvlg4XI4480NLAwrxFV61Gd0C84ChmU13ySQq206q/Fz0 /HAQpRg4xyRzjoDxb5OCMjzYAs3niuWWznhdPTHCW2jJ4tWgDR8qd/fKARu4QPO25JLVJVR0ASR9 raRd0JG5HZhUYN1FlJdRtmDusDF7dmLKijkAT29ssBayd90PD5fkljPoyiK8iFRCwI+/2Yd8PiD4 KZtwaiIy2n38DwXK1Cu24I6ihwmPUII6hKL+whCSCgZ2oyuRvvSv35MSbIkpclrwoCRxptXsclbb aJjVANupH2vntgKFQIpQgmoApgRaHVGL0I4sPs+O/TCyVCjtKCrcT0eP5DFhdIa4CTR+ix4ODs3z xCQoXEDVG+60JPQkDpkgWQRViGmZZUqhRaNH1rvkTsxlsmJWoFPkP7ci1hdJwCn27j3xSLQl7DzB Cxk/Du3Wp6Cgwhsxyo3aUujKeS1EqijdsLnRyKsBVzxYEmh39/fIkU2yPENk9tY4EDQhSVUbV75r Yakymb2pysukjwbOl9aDi4BZBXmBtmaakHVYYmE66KpMNxSaPZm/zpmDOFHd3WPJstc0X4q0H09c oyWG2IvkoT26MBw3b398xp10bYTI5oBlK1HbocxpbuTbYjNKjbwrjwlhKS3iOZI+TAfLMfKLQJbK luoDBK/0y/TkHm4+e+aZwwRMoO1R1p88yqiHBM5dFaS3kVSyN8P8uSljIFhMcwOxaiZmC8dqfar7 +GZekzE7FxtVjBQ89W+E1o3UD9ebIF08o0UGLaP1AqMVA3YdNqk706jJWWNIySxDKQGU1pxXc1PX qcFsaQUlu60DivA9d9lG305OwwX3CO6tKgo5FFI3rXav44Ao5rLW0kiflJJzDGh2pQkEVwTLYDYp MmhXmaChHSp+18NO/wB+QEmPCp+nJ6Ppz/GCNpKAdMnfcgxKGlH1aROTszdQ4FACcPNnFWSS4knB FODfEVJ2IplZApnEni8lcwuxq2xAIP8AmMptyiLcsNARsFpufHfJW1cIPJYygVCii+A6E4QWqdkb IWazDt8NDWm/+Vlok1clS0gnguvSNIi2xZyCACpp198ZEEIpfbQ6hNFNPE/Box8D7AM46gtUfRjI xBoo3Q8j3lxcsj2yW17Ew4zAgkSkVAbbow2yYAA52FtNdMdJbd5pIhEk7FHjB3VujA/dXKMg3oHk 2x3CFvdKjvIxFITFdIAsV0PsSEfYqR0PzyyOTh36NZCJt7t4mjtZ0YTgUY0qvwjc1PbAY3uOTKJR xPMVBqCK+w3pmNKIHk5mOZ5IZ04gRqNlH2fprmPmIk5OOPC5VoDTv0OGOHbZl4m7gp5HiaGlNu48 MmYAAbdWIkbXR1jPFlIB2Pffxy4jiHNgDRtGQM0fIrUF1K1BofY/RmBm04kW4TsI61+qlD6wEkrg hiw33zXZcZie5TI9F0dtcWqBnbnGR8Q8PcHKJkSZ8YkiFHJeSbqRUfLKSGPvaEQK8W398aTxIOe2 AbgdwVPEnIkN0Zpe8TxmpILdT037YAHIEgVeO7Up6co2Ph44GBx72FklmyyCSPxrT8MjTIZLFFWS YcfTkFV8DhBYGPUNSWIB9aDeu/HuB4HJc1GXoVVZCoXnUDvXFgRbR9OQFVbdetR+GG7TuEvmsXDA tudzUbmmNORHKFJISTT364WRk36B9Wn8fp64bXi2SeaMqfhO3iP1Z24LqELIgetdm6V7ZJUK6EMK injkwgqsV0URoyKjqT4fLEhiWd+XdTnu9JSCNVna24pPH9msZJoVJ75jZI0XEyRANpikrNyjahWM /AWHxr/ktX27jIUwrqh5IEt2eZKuB1Tc79SRhO+zWZWpKY7iJZ7YlJUPw9zTutMBFI96C1Uw3MPG VeEgIpv3G5P05ONhMdkhkNE4k1AJC1yxtCHCVIAFQev0ZJlao8TBeSCtN6YFEmglVPH7Q6+OKtIi uASKH/PbCgktug3psw/a/pixBQcgSVahqVFFIHcH9eFmDSjIrJ8JqdtydzXFmDaKtoWQcgTxapH9 v04liZIxf3iEV4N4+O+Ra+RVOh3U17/2Yqsbr88VUZ7WKSrUIlHRu1eu+EFlGZCAlspopA4A5jfi Oh+7Hm5WPPSK0+9Z5Akla9NxQAV/HMfLhB5c3YY85+CaM7xVUgH9RzD8Qj3uX4MJhYkUFedv8Dn7 adjU4/mQdiw8ExVVUSKagim2+RzQAFphPdDSowNR47ZgTHVy4kIeSNW3Ozdh4nKuFlxUtEZQfF2/ XhO3NiZWuCx0+Ib9c10ru1sqaxqx2Pfb5ZkY6KJFNLILwCnqP45mxFh12TYomWnAqvw9j9OTkaFA tY35odIQydSpU/aOw28clCO3dSPEpt4GMbsaEqaBk7jrXMzHmIFloyYxJCpHLVXMY3FASPfMzFlE g4GXHwomRKryAoQNiexGStpS+5ugjkOBRhvvtSlTtlgiwkh4b2IjkhrDU9KihpQZIxKAFS0kZgzE B/5WGxplcg20mcJVowGrQGiVruBlRZBRm9ZplSLeFBVwR8VB2HtkxVb814VOQRlaPvGwr7gnJMaQ rM9vQOS6U+BgclVpCLtroFQCeRB+103ymcG6M0UKsAA1RQg12+eQKxFNMK7MNq9e/thawBZDnhVg CPme9T4YgpkB0XC2Lp8Sgk7AH+uS4mkilSNJoIxFGw9EkO0TpzLKTuN9sEgJb9WMSgb1br629zCp jjai70NQo+GoHhlsKqiglGK0N3EXgcQXVAHam9R4qdj0pka4efJIK+2nf1Pq9xGq8zTmm6EmvwkH ocSOoTaLa3t7iFY7heRjFACakHoQaZCyDsyDQtpYGdQS0VB6agfZoKEV8MrkYzpshIwtRYkyAAEc uhIP6/HB4YAst4zEmg5IhQ71bv2x4+tbM/vVEjpvQkjr9PyyE5kjYhlGgapVj4bV65jjPtTOWPew iY4hVRSiMetMjkldkHdjdJ8uk2vp8oSA7LtyJYGua8zJ2LV4pvdclnP6XpzKG7UHQjKpR7mXiDoo GxkiNYSCgoOJ6geFcrIbRkB5qTOpLKNpB9oZAxbAFrEEUIFcgkIaa0RlbjtX2xptjMpcbORXJFKd h4AZFyPEFIiH1Iqh907qcDXKirS2iSoGX7Q328MlTCMyHLG0YHb2yNUpNrucMrcG+11yVooha8BN Svfv8sTFIksWOmzbnrU4i0kqL2qkgjY+PjkmYmh/Sf1KcT86e+GmziFJPeKEJFaqPDO1i6vmgza3 Drypx5bqKZO0EhQlt5F+1uO5pXJAotCvE5b4DQ5JFpr5Y1ptLv8AjKD6cv7t1NRsTWp/1chkhxBh khxB6Cptrx0aJhIf9+LvWo7HMXlzcIkjZDhpkkKOtFG6E9wf2seaCELNBHHMJYGLuGHJqUHj7eOG +9IS29cHcnYg7026Ur9OSilKJeXL2qa/IZY2BUii+FjQEMKbjp7+2KCVRVUihFGI74sVB4XLFgKN 1HhTFmJLYwCKOOLVqR1wqfJCXlwYQAy8+Rom9MlEWkC1NyGSNqgswrxruB9GNKFv2m4ORXsex7ff ikjqEXxCwDY/Neu2BiOaJiQcAOhPTpXfAxLbN+ya7dD/AFxVRl5KVIFa9R2OKQLXxMCdj02oRigh WMfLfr7+5wIU3sgXV1CtQ7r0IORJb8OUgqqrHMCoNWFQwOxrmFkw9Q7zBqFogeM7b+GYvCQXLMwV VGLE16jbkchuWBFLGVSxU/RXI8IOyOI0pmFq8sIxqcgUZo3C9MrzY5EIjkFqSIxAFN++YfhXszM6 Rlpp7SJ038c2GHRgw3dfm1whJGizkifpXfr2p74nCYFA1EcgVDACpPc7b4TAc2viQxiYEljy49um 58chGNKTavBbyqpDfCtOh61+WZeOBpx55AGo1c04xmnc9xX2ywyI5DZqBEuZ3UNTBt7UyswSMbSO e48AP5sysXqLiZBRphk+qOCBbwrFRvgk+05U9jXbNjHF3tBKD9e7iDUldT1pU9TlnCCt0i9M1II+ 9QxNeux/ocpyY26EhW7JortJhbq5PpOwDsNvlmIY1bNNOLBSVFErQbUO22U0yEq9yHvIVeL1YxR6 /GvbbvhhKjRZyiCLCXMhI4gVXclWr1y62pDRxsjGSOp/mU75I7ptMYLxG2I3A+ycqljZCZCMU1HX c/FT57ZWjY79WxRTTt+unTAQyjMVuvBkRSyE0FCxG539sI3YTAtWllUx8FIbkOp/ZJxAaiEEOZRk oSG3PKvUbgjpk1IUjDal/wB5VGG4kXb5ig7nJiRY8LcLlibSf4g391M3j2DHCR1CEdZ3qRf6Fehl n3UK1WBA/wAqnxCmVzgTvHkziUdyH+6mHpgfESdhvTocoIvmGwGuTQV2FJVDdwy16ZGgOR+bZZUZ rdAvJBStakbH8MolqZAt8MQWRIykCtadT7+OVnLxWa2bxGqCuEDqGUnkNqZXPGRz6pE0dZJCzUYE mlGHb6Mx52GMimc0DyBGhcxyR0oo2/sPTBjyAcxYaKR1ld+sOEnwzqaHwanUjIziBy5MJRpEPGCK jvlJCAUFcWoapZa06MO2QIb4TpCPbMDWtR40/XkDFuE0PLDItStcgQ2RkFiLzHxDftgCSaVPq4O3 b3w0x40JN6kTHY+2A7N0aK+G6iccX7nqcNolAjkp3Fswq8RrX9QwGKYT6FSgnlqVIIbrTFnKIRgU Pv3yQ3aSaaaJaCu+9MaUSWel8VO2LLi2YpNcrLx5bGvxA/hnbAOEEwEAdU4/ENqUO2RtrJXRafza nRG+0aEjDxMDJt/KhZyrg+o/xI604k9gcfFR4iL0zRLaW0ZJY1+thmEvLtxPEbdaUyMpm9mMp0fJ GafHNp5WK3XnDEfhXpQE1+mmRlvzaskgTaftFBPACq1ViG2O+YtmJRzYvqfpQSSRMOS707dD165k x33SNkmubhGbip22AGWAMohSWM15AVFPxySkomONaEVIrsf7cDEqUySgHiQSOgPQ4QkU3E3Z6ivY 4EENSwoyjuQe38cVBS27sEkmjZzRYidvH2P05ZGVNgkpTgcgxHT5CmAMgoqoLLTfsD1Pzwsk1gPw 8ach/NXIlpMVaOLknj3BHfAxta9acWAG+7dsU0sJI6iqnag3G/hhQ0VlEg40KnofDAzFUjIhVq0q p79sBayqPDWjr26kDIEtuIrktF4EggFu9N8plPd2GKG1hsxUFAdwN8x5m93MgeiGWMklh49DmLG7 cqUtlxjUb0rXpmRjxguPPJS3kwI22HbLxDZxZZGpE5Pvt02yBgxGZYYhyoPvyiWMHlzbBkTSxT92 RuGG/wA8yYnZ1OpB4rRiKGB5Dc9jiRYaIy4TYWTW9SaV37dsqnjc3FqO9RFqCDzG/j/TKDChZ6OQ Z3yV763EVxDEOhUuGruw6dO1DmbGQIcSY3tQlf025MaKKVA675Ou5xZHdjnmyX1ltIY+YRgZGb9n kSRuB3AGZeljVkrM2l1npgoodSCdl99uuWzyMwAh9R0/iAVUM36gPHJQmiUQUqhtmmkqGEcitXju NvHL5SoNcY2n9rIyIKsSNuAG4qpqK5iSDkUnzzy+kDGaVoSDmNwi2A2U0uy/7uQU5fCwXYEHCYMo mlCd7ZpeENfUX7SnwHXfDEGt0zropemSeQpQ9BTrkrYFzR8wgPw025HDbGqV45WTaUlWFKGnXvkT G0o1SGWhpTtlJFNkSC6rpSgOxoSOvyOEC0HZcAXkAOwJ2p0r13+eKAL2akSshVhWmwPzxB2RVLvT EhJcCgoBTvQUrkgaYU1HbxJ8MvxRMPiBFaeBPt7jDxIItbdW0qI0M0nr2xFYnPxPF4MPbJA9RzYr IrlVKLOjKGoBIPiRj06jAY9zMSTi0mVoaBQU3ANNxvmNkx2WcJELWcqSoAHX3zCnO9i50cdbuAQt 4Hp7kZEY5xFhPEDsuSKhJUdK/dgGaXXky4QrwOA/Jh8jleWBq+hSnNnMGVQ4AruDmKQ0yCO9FTR1 FD09qHG2q2lMkZpT92BsvhkSmgVZSriq7g4CGJ2WmBSajpgpPEsa2Qinb+ORMWQmUM1uoPTfIcLa JqTJx+XhgpmCoSKrjiRX9eJDOJpLxZgVZQQN616jI05PiKf1mWF6HpTcYOTLgBVVktpjyHwORs3j kubCpRRKKAAPxGNNZLuNCTUfLCi2qL1rjSbefs1B7ds7cBxLVrW/lt3AB5Rd1xMbQd2XaU4nt1kg esb/AAPCffv9GY8tmiSapJPEkauoPMgKK9Kblsg1kW6W2UzCdRxenxMO+3TCwE9qUUZmUhkAYk7+ 3bEsSB0ajme3fnHXge9dq18MBFrbH/Mt2oJ419RzViO9fHLccWcBaRwMXlLU3J2+nvlhbUyt4/nk S1kq5QFffxwMVKRSGp0qDv44WQXKgIAJpTfFiVGWV0koELcDRqdaEdcWQDriJWBHQbUbrseu2IUG knuImjYkg8RtTxywNwNrLdBzFQaMd6Cuw64lJTGMgEFm61p7fPIlgQiVKL0BHenY++RYFZKoao7+ H9cKg0sLMp4kfD+OKatWjI4q3WorX3GBiVeGJaDiQSfwyJKOZRalgrJSqDc+FRtkCBzZwMhstdlQ EKRsKqDtUZSRxO0h6RstEiGnxAMB02yBiW0TFrXVCOlPfxyuWK+TIZa5qLFC3Eg8R1HbL4xpx8mS 3RxVp3pky45mue2AFe9K5AlF7tLEC4DbDoDka7llIhMYojGgbqDiQ0ymJbFWAoAR18RhcUxo0rqq tUHr44CjcLZuKrVhXEgHm2RyEckNfTrNPAxBWSOIpIT9nalCKd6ZGHQdW8nYnoWpWgZRKPirQg1p UGgrlsbcQ82N61BJyYtUKhHKhpVDv2zLwlsG4QVhqbKGidOSn7JFaqMtnjWkDeSu5PB2Yf78OxqR XJwiAzJ2QiN6sqcVJKHd69djlhFBhxWUzhqrof5TUg9MoLYUasoDfDVQxJKiu3yyshCpIAWqTVOo p27dRgCFqxorhgtDSjNWpIp3xW0UzW7hCvUChU9TtlYBCZV0WcG9UbVXrU9ajtkrYc1SSkpLSEFh uVbbYbAA4hiNlkc7xKqMoMYJPLv8sSLTwo6JopgTzCdSBuansBlRFJBPJU9GT0yIyKruCR1HfI3v u2AbbLjCoZlLEV+yK7nfEFlICt1dbcEFUFJEpXsN98bazEIWaYxNxKEg/YYdP898sAtihnVuayo5 FKho+tff2yYPRiYtLM8RcMoe3bdoj18emNX72KO0y1h9NpreVlhb/dQNVr/sq5TmyUQCN2zHjsFE RMJoiS3ptX7Q3HsRXK54t+WzOOTbnuqIGVAHIZv5gKV98pJjGVAN8LIsrkJDcu/t44JRjLbqz5e5 eAshp0J6EeOYc4GGxbRLqiobqZJOTGpGxr0pkDiDE0U8t7hXRSDselMxyGgxV1ZDscixIcI+PxLk qW1yuK77HtgpBDbAH55EhQVN49sFMgULJGCKZGm0FCSREV75Gm4SQ9ePy6ZFtU3iikFCtD74pEiF IW3B6bU7Y0z47Cpz9MfLscIDGraaVWH2qHthURpR5Tc+PE/zV7UxpnsweVADsarnbB11qXRT8+mF bR2k6rJZTVRvgbZl/jkZwtiRb0ezuIrmCN1+yy9+vTMQinDmCGpUK7dB1ofDG2CnLwkG/UCg7A0w BKhcIsSlQQQN+XavthCsV1P97yYdjQH+uXxbYoG1iYOO9SaNTrkiztNY1Aof7f15BqKsFWgHjuMC FOeEOv09fDCGQKw0ERINaYrSknMtUU4Den8a4UmnTNQE1r4g+2KEHOvJP9YgEHf6APfJBIUIrdl5 Mo2/l+jqMSWwSVo4wevYdPeuJUqn2GIA6du9OlRgQuZgx5EjfYN0FfA4opqgKhe+wHj88UKgBVaL uQd6dfmcC80ZCVZASRUjqMiWPVuRXTf8OgyFt8O5CS1qQfsjZRX/AD74toJDogx28CMSE8aoY3YE 77jcb5GkHKrw2yn4a1qPvOAsJZCrLCy1I3HY4Cw4w6UKylen8D3yqcbbccwCsiiPMDvkMcunVtyi xaYAqyADYgVI+WW262QpbVSnXc9u2CSRK9iroGFv6qbg9VPamI3T1ooeWU89up616YQmWPqtPB6g jxHsa4SGAkQuSGNYApQemBTiBtQdqY2bU10QGqwo9uJODAPRFYr0J/mHhlsLBTEsZutGu4v91UVP 92L8Rp2zLjlB6tvCgFt5HajUCd1G5+/LuJjwnqioLaKKMLHuSK1+eVykSsRSIEAQfEoLHr3yFptZ DHMJCxHwD/MUxJUopSF2/XkENvEf2TUHcDw2xQ0qkDkh3GxxSiEux0YbjbbImLARpVKrI3UE9vDx 64LpVN4uJYcdh1H9MIKXICtPTNQTup8cSqPtrsAlSfnlc4MoSpFSelJEUkqrfsuvbf6MrGxZHcW0 puLchXPqxjZXGx67Bh45KgUGwqsqS/DIAKeOxByIsLzQN5bSRjkByp+0Bv8ATlsJAsTCkNxiYMxJ VyDxI6k+/tktwxItfGr26cgWjLNUrsY3XofpxO7Aik0hVRHWOvE0p1zB1NkV1czARzX71p0GIjcQ Sd14qkQBs2VPUf5/PKZgx5t+OQK5SRuNmH3ZETEtpckmJHJXjdT9oAkAEg9xkhhNEXz6sJSRdtce mCBQKa0FPHMPNiMSkVJHrM42PTx7ZjI4QiUn2G+ENZirVVqUA8cJLBaxYHx9sCQ3UEe/hgRSjKu9 cg2RKFkAAPfA2hDSRintgIbRJRK/F8Q6Drgpna0uU/ylp3wpq1B6MtRQMe39MNMxshJkYEg4Q3RK 3nL9jkeNKY0E0ObE3cj4SKDv887MOoaMDMKgbeOG2NqLW0qnkVNAeo6dMNptPvLXmN7aQWVyf9Hd vhc/sn+mVZMd7hryY7DNkuFdAAQRTMYhxCKWMlT7j/awKlWqOULKG+J1/u6bfPJxZBJ4Joo43il3 YglPA12Nae2WkMyFK3FuJiEPLqQGFCPmMTaUTKvw7LQ9KDIhACpA9Uo3U9BiUEOeJqtx77EdsbW1 JYApPdO6n+GG1tYY6ghByoKlT4Y2lTkJoaj4iK/ThVCmNiN9zWlB+OFK+3QELQUIqaj7sSpVXtnq GUUY7GnQk4LSJLOKlByJJUbsR3xSosjKxpRiT37++FKop3223qV8DgRS+Pkx32Xt/HFiUXEoG4+n bb/byBYkqshb016le565GmyEkNInKhUdNqe+IbSdleO1+FWBoT44ktBmiDEoBYJUkb5G2Nro44z8 QHyGAp4iEQq0oKAjvkSgFZJByrwHxHtlcpEN0N+ag8LHddyBX5jMaVS3HNyoS4di3G7Ej4eIFdsv xysOPmx9yJAR0FOtNxllOKDTcbyITVSR/DBTYOWy54Y5DyUjoRTwxXjNUVL0uNBSo7nJWx4V8hdo SoHxFaDxqcRVseEtIrLAokIBUbt1398Tz2Ze8KdxaNMjem/pvUUYb7jqO3XCJb7s4y4eR2SPU9OU cmWi1qWHj3y/HMtsqO4SoRMq1p8INeIzItrtWt1V1o9QxJoTkSgrnQq5oBQ9DgRa4LXbiR4VxW2w rUBPj9IORVcUJ4lftfrrjatCLntQhwN6DpjdLbg0kQB2JB3Hjt1+jBzVFxlJF671p9GROzFzW7qR 4kbEe+EFbXG3oSGbjMrU49dx3r0xtbVIppkl+Pc16/1GAxBSJVyRrXCtGznj2KgmlPpyvhos+Kwp vA/IShRIxBoR9++EHoghejqwIIKkblSe3yyBDOJtRmsUc/uwBUgsD0rkhPvQcfcsiu5reP0WQFQf hO1RU9cJgJG2F06OdITx5loZPiJ2DA+ABNMMoCXMcmMSQjLe4ilFNyfAjISiQUxntRRUYFCBQDoB 8spJvm3gVyVkRa7inuPE5iyxDn0bOItmFGFabjsNiPcYYylD8bKTbaeqrA/a3qCB+ByGXIJCjsWc Y0jIbpHAB2Pcdswp4yN00qpIRXfbK1IV45ttjiwMVaOWvf6MDAxXEg74UUsdgdjgZAIaVKioHywE NkShmJHXcd8i2hTd67U3xZAKL7DrsdsNMwhWQ8tqAjC2grTQ1WTqten8cAT7mvTHX8O1PDCm2ITo OO4rTowzsg6m0XokNvNqMEE4Iim+GtaEGm1MjM7MZFn0WiaXEpRLdaHqSOVfnXMbiLinIUl1nyXa zkzWv7lzX4Ruvtk45SGyGfvS201HUdNZYNRjb6up9NJh2A8aZIxB5NsoCW4ZHBqcZQMpDKw2INRv 75SYuMYkJRqb87lSOp2p8/15ZHkmKXXMNVJH2uxPbbJgs1OGAkqxJD77g9qZIlFo+2NAEmoa0AcD Y/0OVlBRLW616U8MjaLUqlalhTfCqkalgB3OLIBqaBvTJRqEftDsflhBQh3YyLxb4Zh3HQ/L3whK HZgG40ox2Ip3rklVY4+tDWuw298BKq6g/BQGgoCo8AMCHTRLwoaHuDjaQUEwcOVc7N38MLYt4kGo NPBh123ocVVoG26UkI38KHtgLEhGiNmjUpsRuflkCxBHVdGzJVW+JciS2eH1WEBWDAbd8WV2ERAV KEUr7e2JceQVwGApTbt7ZFi38K9QKe2BkAV6cTQ+A64CtEKnEnfv3GVSb4IeSMAkg8TTYjNbluJu LnY9xRWRyBmK/ZlG3scycWUTHm1zxmPuVDQcQq8W/a9/ozKiT1cacAqI4I39wa5ItBjSwo4bkuw7 jCGyO7ccvIgMK8cSEkUukV+J4Hft/bgChC3V0Yo+B+I/tjt7UyyEbWSCXVWUjgfmrbjbw75b4bVw rprqK7XiR+8FKsOnTw+eIjSNwlTxOp4mm2wbtTLQztQaMitAR4HJApItuO434S/Q3Y4mPcw8irFu NOQ27OMglUVQenTxGRW1xSlDXfpt3wWrRU8iQSpHfG1WoaU5DkpO58MU2qrCaco969u4xtSrwSqx CuNx1rgIYkIm308TPxVgpY8U5DbpXc4DOmJKHLBZWifcglefjT3ySKaAooBqy9fkcLLmiYrkBFXs v2fHbK5RZiSrwVySDxr1Yd8r5Mti2LaeJPUNWjY0HzGAyBTE0adLEkqjkKHqCMRKmZjagtisg4zs oWnw1GxPhkzkrkGkxpYsMsIHpfvESvwLs/Xt45Zd82opjG6SICjcvE9KH38DlGSFt2LLWysjkH4u mYm4O7mVYsKokHJFINe3tkjjIFg82njBNVu6ST0d2NFPVx0yIxxyChzTxEc2/T5boaLtU5i5Mhjs ebkRorikkRDhvhP2qb0ygSBG/NnQKKDANQ7NlTClWOQilTXAxIVxLviw4Wmau42xSAo+qw2OC2fC pycXXbFkNkJPGy0I+319ji3RNocvJ0IqMWyg3UkcuO/jihSKA1Y9fxxZ2t4j/Y+GFNsctLNp2Kp9 oihX+udeTTpyUfP5X1aCE3cAFYqOsan4gQew75EZQdmHGGYaLqH16wSd0Mcg+GRD4r1zHmKLj5I0 UeEU1qvX9WQJYBRutLgnQxyoBUE1A7e+RGSuTZGww+8hutKu2WNQbZmNRTp/ZTfMmJEg5FiQ82wy yqk6AOO9PEdeuPk08lrwtLuAduv04QVtckRRVFOu9PDtjaCiYEB6DbpTtkSpXkyIQKco6/aHUH3w IUmRRWg77jsfDClDhKt026D6cWYbcN8QBpWu/fCEFC3SlUDCrUNDTxOSChCk1b4uvY0FTTxOFJRM IoSAK+H9fxwFiUSFqBT7x498CGiCKq33+2KqMkak8DsKEA9sKQVERpGWVxXwp03xZ3a5IGHF1Nfn 2wEraNg3QEA7dRXrkCwI3WzJUFlPXtgbsZI2KmKjxoTiyIRKADcde+BpKLidWXjShGRLWQ1IoXbt 0GRLbDduNRUU6dxkbZkK9Bw5LvT7XjleQkC0YxvSi3F9x37d8xTuNnLFhCSIC1dq9zmPAb9zkcWy 9ZCaK+9Oh7jNhCbiTgFdB4Cp7Ze4eQKycXBJ264tdkKFzAwjZoz8XWniDtko+bcMlpXHqU0ZWOZW VlrU98uOMHkytF3EtrNbB3WqnqRvTw2yuIILKtt0nuLXjWSJqqd8yIy6FiYqEU5EgVxTft0OTMWt FypRKndT9mnjlYK0hfbqMkla8Ckfww2rUbPE3xDkvhid2JCJWI8ecew8Oorkb70FtGLup2FPtKci QlVVUOx6n8MgWcSDzXNaFa06Heo33/jiJplAhckZVhxqSdiMk12vESSbqOMg6g7YLpKoFkj4krVG 6AdCR4Y82DRgjkjqB8f7Qxuk2sCNGKE08B4/RkkLWiB+JKg9eI/hjbJGWdutzcFGBSOnw/s1326+ OVZJcItinAsFVZPV2QfZpsAadcwzl3FMgSEsIIJ+e2ZNN4k2Iwag74LWW7XoBXNTxPVSfbtkuJxz FEQxKfiFBMPtU2rQ/jjKTEc14CkkNsfbMYzErHVzIgxHkuWElqAjjSor7ZjHNKHJtMRIbtqwNQRV W6965eI8Y4o7FqJ4TR5LRC0Q4xEemBsh2p7LkMk4y+sVJnAEfTyVFc9T08PDMWeCg3CdtspABWoq a0Pc5XXQsrbE8nRhuO+VSFMhEKq3CncHfI0gwXi4+HwPhijgcZQRvuPDAvCosyljxbfsv8MLMBol 6fEMVAaZUZfsgV6gDFIJCm8JFADtjSRJYYgDXx3xZW16Henw+G+K8THNEujFfw+pRXVhv4+2ddMb OrmNmfwySNOQByt2QOknYNWhX+OYrhlc0Ch/UT4WOze/zxtHEu5qo/eVp7YCFCr6oK0U1Xoe2UyD bFAXlmkgqq1bcNXfqe2Sx5GUopE1pDA7oFCEntWmZFksSVyqtSAaePvigtmhFOPj+rFXIClew8Oo xVtyKbE7VGKoZ6/PClEwwxFFZug75WS3BDXMQDE9KnbJgsTuhyQa8jsPx+eSYFATR9WB+ydxTuPl kwWYK+ElRSQEAV3Pf6cCCEWSR9nuK79DgYKtQyAknwp0B8cCod1Y/ZO/c9xhSp8RzPLt4d/H9eKb VYYmSQMooDuw7YCpNooRorEqKVO/9mQJY22YAwJB3Hh0OBkJ1sVIRrWh6dxizMmwjL9npgW7RFvU 79hgLWRSu3UDqO+QKYhuMcTXtkTs2AkuLlW5D7J7e2Yk8hif6LkRgJDzQ7KC1UPeq08DmMb4tnKB FbrRXn8Xwt4+NcvEIzG/NolKuXJaI2B36fry3HAhjKQKIgBJ6/h75kuFkO6I4fD8PXqRhagVMOVq rdO5wsuHql2o2XqEyp8Xihy6EmUZd6DFvNxLQOQRuU7nJcQ6t/D3IB5irk7o9dx2y0BrWmRW+0O5 J+nDSq8FxxHB90r3yMoq1cLEOQRt9qqe2CJPVTSFWYhyjDp3ywxYWrncVpt1+WQZL4SRsGoBvv3w FSqUDgMuzd8iwOy+Nxz4uCD29vlhIQEXE5HHfkD0yoxbBMhVKb1A69cAUkLGi3DCpPcDrX3yYLFW jkV1MbjanXtkSGJDbQektRuMINsSuPpuKMK02BPb7sHJQVptmiIlDEmvUD7I7GuHitbUiSw9RXNU NE8Bv/XGmStLcXssbM8i/BQemK/F922ViERyTalBc8nCHZjsa7ZKUUg0mNqkTVZj1G3ffwymVsjL uVngCHgRUBQWrQ7+1MEZXuxJtZHAUblGa96fPJSIIosNwVT00IDNVT28Mx54STYLfDUUKpwRhsd6 YK33H6m29tmuAAqNu58Ms8PrHYoGTpJtHKMWPhsKVGYeYSPNvjXRoVJqdj32yYxmK8TfNiAvVfDv kY4oy8j9iSSG3iUpUGp7gZiyBBotsZIRlKttUf25DZvBaEpqORIHfAQmm1nZQVrt1GAhTG2zKjGh JFO+NLw0vFwABQ1XpQ4KY8C71Qx+E0PvgRw0vWQ8iDsw6+GFiQ6sZP0/Riu6pvT8K4oUrfQ9Pni5 NGCzCqkbEDpnTmZdSchCOsree0rGzF4RujMasB4HIyNsJEFGGQFajcZFrpQ5E8uXcbYUtLK0RI5H 4v8APrgItkCh57tVViSQT+18sRFlaV3EvqVJ8anxywBVNCduxHRvDCqIPEb+2w7+2BCstuWiDKNt gAN+vjkbZUslsQrcqkGnzBxEk0seNGQKo+Ib198bSA2ycU4/IGuBmhpnZgFZSDXb7u+TAayhOJB2 3rvv7ZNFqToDQGvXcDCqxVBIQjbboK4ptExo0addjvT5HtgQ04qCQeh37UGKqasrKOpFAVbpt4Yr S3kpr413PbFVeLkoNN6V/rkULvVZXBp/sTgIZc1UAkc0PWvKPIFmD0KohEnxbKw2rjbCUabMYr4H wwKCqRkDYbHtlUwejfCuq8E0JI2wjzYyA6NqSdwdsBDASpVRFKCuQMR1XjPRTMSo4P7J2yk4gC3e KTHzUriNak/ecFVsiE7UYzsQa0r1yeMsphXgG9R92ZAcfILVytCOOzYWhR2JAZPh6k++FnEkNSwB kNPiHt13+WINNsZA81JEjoKD4gOvh864bbxso3NhbXIPqCjgfbGxycZkIISW60W8gq0f7yMeHX6R mRHKCwMUAWKmhBDA7g5axVo7mNhwbYnv75ExYEr7u3LHmNqbmmRhKkT3U0npIPh4AgD2O2ExYgoj gCOQ6HemQZ2qxDiQRUU/DAVKJMaSL0FetK/qyN0xpTKSxH4dwRup6/Rh2Ko2zuUkrT4XX9k96ZGU aY2rXETMoaE0fbptXxyA8033LJY3UA9HbqexPvkgm18chI4noPtCvQ4CEKoj/epJsyqfiA2qO9aY LYlFQ+kC3EsACaBtqjIFCjeaUJkL2x9G52Pgp+Y6YY5K5pBQ31S5gjcTqzM1BG0IqC1aUYZLiB5J NdFywxM6qDzYj42purDYg0FMbKCU5itXNpHsvqDbkD2HYjMU5BxUyESQ4Qr0Io3jkrY2QvVCu21C PnkTRUla0XwbH3IOSEkLCvh8qYTRZxkQVlFP2TXBTeJNFANuvthIEhRUXHcNAUoAfoOVHHIcm0ZA XEAEEjY9vHMece7m2gqbEfs1275WJ9JcmwBTc+pSux7ZUcO/p3DbGVKTIR1H04GwFYRtthMGQK0b 5XSbb6YCFbB32wGKuEjAeIPjgpaVY5t61oe9d8SGJirct/f8Mi10nEYhSUoooaAkZ0hdCiDx4+w/ VgQhHoCQKEnt2PjhSpl6kHfft/t4UrJGFCcVQEzbNzHsvuckEoGJQ8g5Eotdz4UyZZIsQxqn86kb GmRtFtxwH7K7/jgJVEWVw4kCMpUCodaUofHIZI7M4lFTsixmo/d9SfDfKoEk+baQhktwzLINgDVS O/zycp1siMV06itPppTGJTJAXCAdNzv92WBrJQjAbnxG2WMFFwaD8a9xirccbAmn0H5YVVkkoQHG 46E7jAimygJqnXqa7b4ptQkhklb4VoQN6ePTG2QKGIYCpBp+0D74U0qxsQg6kL0yJQQiF4SAU2Yd xv8AhgY7hUEbLv4ZEptVCV+IVJ6fPIllGXRUQ1qCKHAxIVBH/YcCiS9VFKU+eAptvgATx6ZG2Le4 oMBLKmqg7dj2yFiqKSDdhbInNeP7XbARexRdGwhTAUJJ8T8sGPHwtxycQV4BQ1+7L2iSJHh/tYtZ aEacxHXc77/dhtC02w5mh6dxt8sNswQoSxsCCCfDG3JgVPeteoOFm4syrimgUHeWFpc1LLRj+2Nj lkZkMTFj2oaZNbHkN17OMyseQFx8kOoat7tVCq71WlGqOmGUO5rjLvRDQRuo991Ne2QEkmIbjfgy qxO+1PlgItQUUsfL4kNGHb2yFs1WEjlxYUbwORKRSJMJatGBA2BIqQf9rIiSTFTuLWhBWo32YdB7 5OMmojvbju5ITSYepEagSL1+7CYg8mG4R6SQTJUEkU6/wyoghkhpFaIll+JPbtkgbVH28Q+rrOsn U0p0ysnekEoqOyEjclcio+JdqA5XLJw80AWrEOhKMNlFCa03PTIfVuEhrlsD95GO60lT6VqMV7Ld 2rhon+Iw9N++XDLEiikck1sZklj5HlHIBQodt69PfMfKCD5JiiWSSlPtdxXr0ysSCnzcqN0pTj2y RKKWP1PSmTigqTe42PTJgJWhEJqNhhIPRPH3rWSh61U98I3CRKjs4KCTyNPDMLNKUTtycyNELFHL br4HLYSE4780SBiduSlIlG6b9sx5gDm3wlawqR/XMcS32bg4iq5ZQkN+ag0ospA26HIEGIbQQVgG Rtk4jx3GClaoO2Iim3UNN8FLbRFOm1cHCtu9XtTBwlij/wBKK0nI0Zamnf6Ns6TgefpMLW6BaNKm vXxGQIYlVmWlWWgbfjsaVwKg5gGkRXHGRN0brQ9MkEgoZmmWoI5Dx9sKaUJwfSPAkt+rCErYLVnj Ln4XoAcTJUTGHjBVu+xY9KZE7qiIbRqA1GxHLY5CU6ZRjaqYW5N8AB4jixocpllGzbGK4ElAJNj0 p2JA7ZGR6hmGuJHTamUyJ4mwVSySNiN60HSgzLiWkhL7piCNq1PGo7nLg1lDmMnkV+ivXbJWxUBC QxU1YMeQU9qeB64bQrJCtKjr3UncnG0LzCGqKCpwWqwxFTtWvYYbVRkiDUIJU9KjG0gqTq1avU8e mKQVpjYHbbvgZhWjjJcBdj/H2wFSjEWQIAw38Mg1GlVEHQ9aYCUW2Yu3j+rAkFcoYbHAnmuH6sBW 1yde2AoDRBrlMm6JWANyoNsq5Mm1Bp03ycSWJXtGHFO/jlwLSRSn6ZBPtkrZ3YVUBG1elMLUVQpu DStBscUL+IKUIrXbG1WmEMPD5nG2cZEIWW2Uk7EEGopsDkw2iakYWoTTYePTJJ41J4yPnhpIyKDp yWjDkrDcHpTBRDaJApFf6UEcGIVVgWK9xTMnHmvm4+XFXJDwyGNyv7B6A9jlkhbVE0i+Al3H2huD 88rumRC+FmVzGag+NcEggFGxUkH7z7XZh3plZ2Z2rxCaHoeQPbImiy4qV6xOOPRnOy1yG4TsUKbW VFqTyVjxau9O29MtEgWsxIUlTg5WBjG4AoD9kjsMlfewq0VbSuQUkQLORQ/ytkJBINNmJlPJRT+Z e3zGC1pOrSUo0cZKuzLyBHcdcx8kbYxNFEn0i6hn3U/EDtsd98olYBoM7FrLrivxAUjJ+13JOOI3 seayWxO6qKNsR+vfJTiOqIqqwLKQRUN1NMgctBIjuiBA4YKp5kipDdfoynivdnSp6ZO3fvhEqY0t +rBlJAp/NXLPEooMUHPA6bdsyMc7YkKC7ZYoFrhT7+mC14SFpj+Kp3H45GUQebOMyOS0xmtVO46g 5VLCBuG6Ge9itJJoDsR3yqQ4hRbxtuFsiODWvIe2VSw8O4bITB5qfGp65UL6ty1krXEEptSMZHbE gMxJaVPbqMFMraAOEKWqHavQ4eEFFtSA8h3rk4RYSkt4d6f0+eWeF1YcbGbDVrxJEYEmhFUO1R3H TN/KAdYYhnen1dVkKlFcAp407g5iSaCmSn4lDigboT0+/KyVAQ176KOG5UNfmDjAksiFF+HpCjD4 +hPT+uSTSiqcyV4+nJT7ROxoe3jhVEwQKBxkUq6n4T2YdcqnOuTZGKv+7Y0YbjKZykBs2CIXIpjq V3XcnIjKJCjzRwUdm3JPTeuQ8NlxLZIKp8VGWvT3ymGQgszRQdp9aiaSO5kEgd2MJA3C+BzIyVIX HpzQNua+W4WIkUr0NPbpscyIx4g0ylRQ7SRyqSfhbp/t5YBTG7QkgUVWntyB61yYYtBSAAKGnfvS nTFBVFReO3elPHFDYXZuTU4jatd8BSN2uIIr1PcjCxKxk2G3XtjaqLRBRUGtBv442m1ixkmvfpxG JLISRMEAFadR1yBKDJHIikhetO+VksWjBWvHHj708KwGho3fCxXNSvt2xULAdxToeuBkd1QUFB4d MiUBdQdGG2Y87botKo5H3FaHw+jKiya3pQ9P6ZOKlwJrvv4ZkhqK9CrdflXvtiFpsKVp3HhhDEqg FevSuFrc5FB2HgMUxXR1pvv74LUr1QdSMhxMqdxQ7EDff7sIkVQ1xZhlJT7stjNIl3pdNEVJFKe3 bLgbZgocoK12qdqe3hgMW6OTvQF9pqMrSR0U9x4/Rk4ZCNixyYwRYQKh4hQk+APv75ed2gbc1YOj Gh+14nIUkhcX9FQSSQTSg61xq2IKZWs6MoDb7bHKZRpmCDzVXRQO1PbbACnhpdBNWq1BHQN19qUw SiyjLoVO6tHpzi+JfDuMlGfexlCuSls4owIZPsnoRTJMEZbTg/DMBsNpR/HK5DuRyVooBHxdRyir 07fQciT0U7rprmRVrBD6sQJqu5kFe+/YYBHvLFGCRWbjyD0AIPUfLKQNr5MrcVIXb4WPYdMjxd/J kAr28oDAVo+4JpsdspyRPwZhFpLyYFhRu5GVIVGi+EMGp/L9OC1bEi/Ar7EjY/1yQB6KpXK/CSNw eo9vbJRkQoFpdIqndDSu9DmVDJ0LLgWBqGhw22cNhcGHTpXJgtMoFxFR4frwEWER57h3FTsfvyMY ABsOQgqTxstSNx3ynJjIshyMeSMmpki4qUarHqPDMTiLkRURUbHvjTNa2RLIKTL3yQTbQG2+SFKX fD364QEErSCSN6ZkY4NRLdF8e39uZHCKauI2xHRfVWQCWL1YiV5nfYdzmzm4knoGkQFYV+qP6lsd wj9q+53zCnLvaDujGkNTGydd1XxA98hShDtbAVFOXKh4kUI332yXEypTCyQu8YBCkDifGnh88dip WJLdj4fTDmhFDsa0r8J6Vxlw97IAq1pcXkrlGhClabNt8NfEdxlGWMYi7ZxJRxiCnfqOqnvmDKZL cCqIEKEgU7EHxGV7qWpAEiAI67HLAd0c1HmWUqRsagfPJ5MdbhQVjRggqwqD1GOOe6TyQ9xUhkI+ Hbgw3I+g9czoCmmRS4oyM/J+Zr9oD+GXBqLYLKoqOuwYU+eK2vijDuoTdieh2xJpWzGUZwabbA9j jaCqqEoxDgMR+1Xr0ORKQ6O358grUI75GU65shG3G1l5EbEdmwDLFTjKkYJKklDTqfDJ8QYUW0ij anQmo+j2yEiUgBU9IoxHKncA98iJ2piqK23EruOuAjqi6XCvUeGA77FI23alAJHv2wQsbFZUhypB C1qD0/Wcstg5SeZHhgW1UD8MjJIXkA7HpXKpkMwvT+zKSGbT0Hv4HDFKmRv88vidmLYIHX6MbZUq VBArhEmJivUj6MlbWYuYDqPuwhiQvU0HTEoC5aEGm3fKid2bdNqg7dMbK7KU5KoWJ4gCo99uhy3G GMklbVqTgSqHjO1UFak98yPD22SB3KkRt5lMq0K1ISoowHyO+RNhtBCySOhrT4cN2zBIQlzZK/xK PiyUZEJlES5JXJC4O4oRt8qZeJW0EEFdHMVorjbtXEhSLRUJUVeM9OoyJazsqrdle3Xb4hUZEwZx KxJxHzJozMf2N6YkWyV4rtpYwJaGh2K+3f8AsyJh3JBpEl4pVo5HPoT0OQ3DLY81rxsgr9roD7jC JW1mNKttd+mTTcHZkPTbqcEo2xRsXpuS8DFZP2h7ZUbHNBRCTKkqLIdh0bpvlco2DSQe9XneJgoV qgk1HbMbHCQBZmQtYQBVQNqjcdR9+ERvfqy4m0lI6k8eg77YJQ7kq8VwhFDXkOgysghTFsqWchyC tKhh2Phk+LZC1WdPhLfDTDJaUJokY8kPxEfY/pjE97aChHJruKEYbIDaAtDE5ITtJC4ybnw8MAkR zYGCqgqKg706ZfCqoNUrvdosyn9YOQMyCzEAQsb0W2pxOCUonYtkRMeaxkoB3B2BGVSh3NsZKbAd spIbQVBq1wC2bVaYdlpazU65YCxKwv3HftmRAtZC6vft4ZdxCmHCUL5Uit50YED1j0NdvlTMvKad dNPfTl0/94u0bDoOgPfplViWyKK83c00QkKrwBpTcGmQoA0z4SQo8J2ZngPMCh9MncfLJ2BzY0iL S7ScFJQRKp3r1FP1ZVkiRuGcTaLjik3EhDgbq9KGoOxOYmTIKsbNgCqh3oR8VaA+IzFMmZDlQciD vXsetfbEraoQKAdd8QWLT0b4SppT7W1MNbXaQh2RaMAQW7nJRkbZIVY5ApRnPUEMOu2ZMqPqAQC1 IoI32PY5ZikUTiEDJGyVDE067daZlA240gQh+aM9K047HJIVlVd2Ckr0NMFqj29FYKgABqdPHsd8 pF22GqUOSuqRKByrUvTJ8t2HPZfbjc06j9RyGTkzxndMYY1K1ABJ2zVt5K9oIgKFR4g5ITPewQTQ RlywFD7HLI5ZAIIC0Wqcad8n40mJiGvSKkht1J2PhkjOxfVjTTCjGo69MBmT1TQUjWlDselR0y8S BaSFJhVj7ZJIWqTy9u+KCEQKE/Pv88jJQqOpBoaVG9cx47tttVr0G/tjwpdsRtsMIG62tKb/ADy3 ogFaU3qR1ygnduDgKbDFVTnt+vJxDAheGBoev+fTJ8TAxXg098PGx4FRVJFfuGVGSabXJgsSoXgV oijNx57An9WXY2BSX6qqO0UqhomOxHUfLMgnqGQKjLYBXDI5RifhB6Hw364ibNYZ7mE8ZlJ71709 j3w8IPJINK0dzG+9BxrSvbxyJBDMSalto5ASdmNNxgEqZkWl9zalaq3TsfHLoztolEhCiSS3YBt1 7NllWg7r5n50YHiNuRxAYbhbIZI2KO6sSSDxPj4kYgM7VYvSUfun4npxJ2O2ApRCzKaq49OTqGrU V/XkKVUa9uAFUUYdGr4fxyPAEglUDmnJTQneh6YGJVklkBBFUp9k+ORIRSMg1NdknpuKEnrXKzj7 kEI2KOEqzw0bkKKCTSuVyJ6sVSOWQqQykMPtKdzt3HiMhOAZAq6SKRuNuoFDmNONFtiVpVT8cRHJ egPTJxIqpKbG62GWRR8aUFfi9q4zgAaSDxC0QY2kHIbinU5ESpipSw8SvLod6jtiTbOJQtxGQd6b n7WRiW6JQxqpp0/rhNFtCpFA8qOwp8PbxyJnWyCQHJx7kj+uAyKaXeo1KHc5PxWPhrGox2yEpWzi KWVK7DAJENlAtMykGuxOS4gvCQpFQa06eGRoHkzBWEZDkztRlqDhiUFRZvi3+WWidI4V3PamHxF4 UJ5ctgXHCbgSdo+hanQjNzkLp5so+tO3K3uR6bHZHI2OYhjXqDKPcUFJHcQFkqQpPwkjauWggpJp QSe4gk5UIp0IyRAIa7R66mkrKVUc6fEw2IBHcHfKvCpkJIyOWWnIElCMwsmLdyAQQqtxLLwNa1/z OYdU2Dluvt7ivwNVj3JwkMJQRJINANj3wAsKQ8julQwotCQRucyIxsbMkNG0UcpalCwqzH22HXLZ xlIe5SuZfir9PyyAukIeRnNCjD4hsKVB+RzMiBW7WSRyWSgSKI22Lb/2ZMbMSbQ8lqSacVHEEkjY /wC3khNgQ3GxUUb+5PUdwf6YkfNQV6gc9nHAn4gfDxFciSkUtJHMshoananbCwtuORVdmJoSPgHj XBIJiUTHflBUqVb9oU6ZiywWdi28fe6TUJHjpyCA9QetOuAaeijjWR3BcmgUBTWrGmSOABHGuSeV jUAcQd/auE4o8mIkUS/MfE4BUjemY1DoztDsCAab+GTNXutqYArv1PWu4xtBU3UL0HXp9OXwlYay KU0BLdN/bJotVFeuNoXV3p2wcIW11KbU69chIMwWyPavjkRFlxLqUIFMmGNtemDscqyCm2JbaJSa KSDSoPb78qBpnamduvb7ss4kKiAUG2RtVYKtKHr+vCGJbAO3higtlR9/TDbFTuWRY+TjkKjoK0zI xNckFNGgo1BWtRQ1BB3y4FCHYAg13qa0Pb5YaSDSFeOhYMOQYUFf2ckClCyW0kQDoQdtyOlfcZMS BZgt291Q8SPo7b4JQZRlSMYCQL8HNSaN2oPHfK+TbzCXXlkBXbY5dCbTKFJcfUhJqP3R7HcjL+bC +9Yy7813B8MNsSKVE67CjdR47YCkFELcV2kXlWo5daHKzHuZq3xrGvpn1VpufA/LIdd1KpyAi5KQ HA+JDgQqrMOFXFOXRhuPpGClXcVcLyo6g1Vh1qMFopE2l3JAfi+NSdqfPIyiCgp0rCVVYDi3WNun +YzHrox5KiMGoGqrgUYDbKJwo30bIybCqGJ6gdMrJtscS5Th+y24yUau0FfauUPEj5r4/LBkHcvN WnKyRfuzSgoFPWn04Ad90ckEQQKEVHv2yZh3MxJDSIoFVFR4ZSQW+Mm1nHF0jWiH7RPbKyGVKbpw agbkMnEsgbdXr+FcjJmFj0rt9OVW2BpWJYCmSEqSYuZQTTofDJXaAaUqFTuMETRZncOZh3ywTB5s DEjkhpVruprTbCIDmFEkOVYHcZExIbAQ7envkaZWt8vWxaPmG48eq1Ff9YHtm/yF0UynV0RIlJKr IGFCOh8K+GURFcuTO7WxXTpxiuE+Edm67+/fDwjmEEoiW0DOrhvgfoo7E+3hkRNTFDS6efrCqh5E 7hh3A6jJCeyCGhcS2zAN9gnYHqOxxlASDKJoo+Of1EBU7V+nMDLpqOzkwki4lB3BqCOvcVzDIopk Vdg6xkg14io9x4ZKFE01WkuqamZbdkgfhOv7B2qO9M2eDT8J33DEy7kHbm5Kp6gMydanoO599syJ V7mO6bB2VQXqRTkT7fRmKYgnZlaFRwFaIghf91g9t65eR1arVXceieY+R98jW6b2WxxhAOT81IrT rTBxEnkkgALGhDVK7UJqD4ZK2FLDUKFIqoO/0YWNu2+1Qde/SmFCwoGJFd9qYEttzKmpLV/mNfbB QW3RRoSeSnbuagbYlVT0wDsPowWhEwQ1+In4B19zlOSdbDmkBXlckBR9kigA65jxj1ZlQZtzQbDx 8cMolIIWAEUYUoevhTK7vZkXMob2J6ZOEiGJ3UgpUiu2ZFgtRFKnRNxsTtld7sujRFTUDLIlgQuo PHCVC6gr+rK4mmwi29/mf11wg7rS4DpXIzZRVgg3PfvmOzUmTww2ltFoaH78BVUK+A36YQhvgQAa fIA5ISRTRU1BGT4tmNNSRCQcSTTvlmOVMJBJ/q8lu7LGxeNj8StvQnwzM4rYhcy8fiptXuO+AFaU 2BIqTRq9B0ptioKm0bA8lNRX4lxtmhri2V9xtToBtlkTSCVAXDwNxapXtkjC08dIvksyAghh/n1y qqbRMEIS4tl6g1PhlsZNcopa0EsTVXt+x7e2XWCwFhtFR2JB+Idj2OJNLwqrRfzCle4wWjipoQzV rG3zA9sFjqybZ5k/vVO474AAeSCrIQYuatvX7ANT92AhjasiuqiTjQdQaU+eRLISRkBWQVX7XdP6 ZWdlITaKd/q6IvFypABFanKeAXbG0QQJKOPhkTb+w5GtvJbpcrFY6EEMdicolhN7Nomqg0FRuRsR +rKqLK1RFSRfcGtPD6cQWJsLqbhXPIdieowgLbTxLQ0FK4SUJbNEwY9sSQW6ElAVV/fpQ5VKLeCr RRq1XJA/yTlZZWo9Scl0ZhViVXf46UPfwyshJNcls0MayUVq++RZxkaUmjbcDqMWdqRZq4bTQU5D uQcIIQpOtTtliLUTWvth4ikU74a/wx4opoofS5baRVMcjQSqf7wAdD/MO+b2YLpSjruW6iWNXJkA qGfwJ36DtkIgKCjbRUurRw4LOg+Gm9CPA5VM8JDKK+2llhBSQggGoB6g/ThlukKizMZCy7hTtTbY jIkLVqlzBFMQQvKoFamtchGZHNmILIbT0PsbKT9nsMhPIJDm2RFI63JQnl4Vp4DMDLIE7MiNlaeS UxgwgcuxPSvhtksUYnm1pJdraNI3qwhLhv7t9xU+4+ebPGJDkbDGVKlmrgAli8a7EdaVwZSPixBR pjFKr8O9B8h2zGEz1ZKc1sJCGU8XG5NMvhKubXKKHdJY6r/NvTrU5MEFgbDQHI9aOall+W2KtsrJ Sh513B8a+GINqQ4lBGtVKk7/AD+eDqp5KtvBHICZDsTQAbZDJMjksY2sltGj6DmrdGGMMoKmJDcl vwSgNWTdo/D3xGS1IUkrQEjvvkyxXFjtSnWuBVa3MxI2qo3APbK8lMgiG5ByAakdD2FcxbFMgN0O XIBDCnh9OWCBtBIpykU26dsokN2xxoG8MQUUukQsKkbjqcnCdMSFECRdmOwy8EFhSuIRx5VOU8bO lqqajl3NCcnbGl/Gh2wgWm6aUMegPucBl3s6XjchiPnkaIXm2XXft4D2yBikNA7/AK8rtnTlYFqj qOmAStkY0qeoNuQ3HfG14Wy/wgrUg9ssxkXuwlAuYIWqD9GWcJ6NdtMxA6dOvjhgLWSDv45eAkiA JX7XjTMvHIHYtZ2QX1w/YkUkjqD1yZg2CjyXqFNXiNQOqnqMF97Exa9Pk3JdvGuFjuFKSLcg9a9c IK3aAuoDU9atvl0ZMSh6SRmqbb9vbxyWxXkrQTCTkHYhidg3T5ZCUabIyVmtonoD8Jp1GViZDbwA oS408g8j9DjLoZGBiQoH6zHsV5qO4yWxYFfDeQBgsi0I+jAYlhSYRzWE42cb/stlRBCVZbCJG9RF HIbqfDAZFS3dostq1fgmG6gfZJGCJosS1bWBlto57d6yD7aMKHkOorhlOjRSCrwXKeoFdODKfiFK H5EeGRMUomSRVnLxE77kHociBtuhXiuEYfaoa7r75CUUg0rAA13oR1p1yBW1VOcZDfaHenXMeUL5 NglfNEH05BUH5EbYg0ghSHqKxWQcl6BsmQCNmNrJYSdxmOdm2JQk0PLpscjbdE0pIQiFWB5Hoe1M Bbea0b17YCWbfEr2+ZGRLILXGwIPTIsw1Gpd6ct8Uk01LblDST7xgUTvkpzD0yRGRIhHcb/dhCAb 5oQh6/D265MWyNdVA1rh4k032r26VxpkgbbTbpAZ7Y8vTFaAVLfR1zoZTHIuktOkEV1Y/EfTnjFG Q7GuUnYsW7eOWKSOZWo67OpqA49vfGVEUm0wngScCSP4W7kbHbMcTMTRbgOJCrE6vxcdNwRltg8k 8KvHK6txrzqfpGQMbSDSOSPmRU0HWua/IOEtgkifTUuK7N0r7ZjlFuJRAyqPH78uhAlixzUmDTio oyEio3+g5uMQoNUyiNLAX1AVHxkAkE19tvDK83QoiUaxZdiC221P6Zj0JBndLlZZF22bcVI6H5ZE gxKLt0cbupDAVWoI7GnfDknVV1QAh3tmqXVqvUFVHgMtjkvboxMVN2LGjUUgUUDp75MCmBNtLUVF a+NcKEVAsbMTT4qCh9+mUZCQ2RV3bg1KgV6ZTGNhJK2aMPI6oN+PxEdz2wwNAE97EtzQx+iV4gFR sw2+/BCZ4mRjspS2pQxgAfF1Pv4ZbDLdtZijli9NPc9cwpTstoCk6v8AR44LSozQclPfftlkJ0WJ CFYFGANKd8mKkjcN0JA33yJFMgV5P7LHc9KZFLYjcgigr45MSYldWQHsQvbCIhXKnJzQfIZOwEU3 2AOx7nESWlwYqT8sjIWkbNkDjXpXIg0khSI+OncdMZDZMSvVeX098qIbBJDuJKAH92O1ATlW7kRr 3r4GUhu1OlTXbJxYZA3JKsa0V9/Ab49dkRjfNbBcs4O6sBtUdf8AMZaRKHPZiYxPJVE1RTqR/XLo ZAebVPERyUJ5pGQ+ivMhijxt8JI7kE5lxgBzcclASRQyBREG5EcTy+Ig/P38ctvvQDSGjkeKT958 DjblT/iQwmPc3CVphFIsnsadP6ZUQkhe0YI9+2ILVKNISdABRgNxkwUc0G8I5Env3ydpGyi9tXcD l79MIklfG00YAG6/ynIkAswSETHcIykN8FdtxUZDhZ8bckbUqAAKUDLuD88IKCAUFNbB3oQrV2r2 rkxNgY0oSWSKoYLxcdCMmJsSEfLJK0EYQ0Oy8srA3Y06G5eMhJgCp6HExvkpCMCNTnaShHO5HVWp 45H3sV1wjzAPMPTl6fCBQ078q4x25LahFM0ZKSior0OEhkiopCq1CA1qORyshC9ZiDQnevcb4kIR kVyQtVq4H2hXeniMqMLKQVV5AyRun2fHGEOYLK0SrinxbCnXqMqlj7k26o4jccafDlUoFIUpYAwq u2UkU2RkgZoCOo+eILkRKhTiThq2y1xYkHAYFILXfp7ZAhm0F3r0wUytt4m48upPfIEIEkNISOo+ imEMqUHpvQ0r1yYJ6LXepFPprg97MFbxFMNJtOLKCISCWDZFqjDsQfCncE5uMk6G7owLQd5ZxWs7 KsZLSkGNwaDr3GSxz4hakFGcHRVZqE127giuN2wVPTkQ+vGKodmj32+WVmj6S3RNbhbJMkgACmp6 UPfGOMjqzM1a2UtUsCqr/N2+7IZZVyRE2i0AcBh32VhmJI2GzkVc0jDFt+PhlUIWaRxWl016HRmq QQQKA9vHNlDDwmujDj2Sm8dTMSo+21W32r7ZkwFBhIqoQE+oDxUUHU132yN9EUmdv6quGcdqBhXp mHloig2br/RHEOOo3J/z8cgchukUvMdVqOnUkZWJ77pcEIFCBvuD33wmXcqBmiINR8RG9PwzMjKw 0kUsUEjl37164ShEwO32WUCuxcdvnlMwObMCleeN5Igyijp09wcqxyAlXQpkFWAqyB+jgcWJ9srm CDSjdRYNIwUU+0C/TYGuWgcItnMdEaI1LEnelKeA/tzEMtkU3K1F6ZEJQUlwwrQD+mEMqUjOaFWP XoT2yVIpTcBh1FR3ycNighYrfH1pWoGTIKKXNVXA6joNsim1VQxpvkbW1VKb7D6cUOIUUp1GEIbC qw8T4YlIWbqaH78sj6gxls5lqAVPvlcjTMbqfenTJAmkEL1367d6ZA2GwU08hAqN1/aB2oPfIcTY IIUQws37o79q9MuhLoeSzJC2SM8iSKEDcgV6Zk4oR5hrlkNUVlFVKoOI67CmT8Kz6t0HLQ2crHnx fYno47+2MtPEjZhHOb3VAX49Qyjp3GRiJRZyMJKNxbvLVlNdgKHalB+yRl0Mg5FqliI5ICR3AKTj 4h+0RRh88vruYBqFpI2BQ1U9h/DBIWzBTGKYOgpSvfKSGRFrLlC4BWle/wAhhBaapBmJjQEkDx8a ZO0ucKvXc+IxCV6xIx2O4A2ORtSVRIARxYU8D1xtFtfVpYmqtae24P0YkgsoyU2DFuRQA033pi2C Sx41PwkEVr03XELs0LcqOvOnv0+jDxIMFwWNwAwqP5cILXIUqwOiScegYfAe2Ai2BTGMtwrTIKoS WsTlSwqCQD4kHJcSFCWB4W/cuZIV968a9sQb5pRMCpLFRiB1IrschI0tLFeS3moG2JoK5KrCEzt3 VwSdmJqfDKpAhaV2hAHh4eGImlsLWg8OgyqUm0EKi1IpQbZSQmmngVx75UYsoypA3FkamgNRvXIc m+M0EUdKgg7e2WRm3c3Bj/ZlhoopcrKDuKjKpwTbbOtPhPIDoO4yvhVCyAVJA3JwcLYCh3BpTuOu NNgKkWPTBSW/h/DG0q0izR3FYmMLN9pR9k++dAKIdGLCY29wk8ASf+9HZ+n0Zh5ImMrHJviLFrmi 2YUBjp8adGHuuQjn33ZHEOY5roUdI+pMfQN1p7HDOZ4vP7FoUuJhV/VLcXoAops3vXInNtwso4rN r4ryI05qGRj8VfnlEt2yWIo4TRRwhoQOBJBBrse2TxY+Lq42QkHdTivBKWWSiHfauxGW5MHDy3YR laVpZ/vyCSEqaMPnmWcmyBHdSurUD4h9obE5KErWQUoqVAf4hSnywkMbTS2eoXlV+9f65h5Ic6bA USOJHw716D55RIHqtrwpoSaBdgcrW2loQV79skQQbRak6mhVh7Ed8sgUFBlSnarKa08cyebXyRMc iSUV9hQH4euUSgRuGYkjBsOXUfwzHpmFjM1SAux3anTfJiO3NIC1LZjKGpTcGnYgZZLL6aClFEAL 1rmEVClKTTCFQcq9xkwEhDyKabdcIoMlIOwBqK06ZPmpcp49NjWorhpiVVmJCmm3vjTBUjkB6jfp kSFVQBStenQDIJdv1798kCtL19+uCRSA5lr8+xxjKt1lFrjxNO2GcuJYxppl+LKg2EuCe2SO+6Aa U3Z1ACgEknbxyFtsQhpHYrVFAatGA6jLIVe/JlS7kaDmN6bE9cycZ39JaZxWtx6fjmVG+rTIABTM YKEdzvxbpt0ydtKnEsqVo1JOpU/Zb6cJ3UK4dWbcFG7g/wBmUmBb4z2altop0CvRSp+Fh138DhhK kT3S240+7tqOvxodwV6j5gZkCQLXa2C4HLY0J7dsEotkSjlevT5UytMotgIw40p7dsBtrpaYUJJp t0r4Y2yEQ2I1ANNj3wElkIhVUjocWBiq8RTrQnfAjdRkiHGu3t44bSKUOKDoaHClY7UU0APv0/Xk kArApc12STx7H548k3a7gG+Fx/t+OEFrIVo5njQI527MOhxItgrseQ5LuAdxkEuhYyLSMceNaqcB 2WldYYxtxDbdPCuQJKqNxaOePp0oBShPTJxn3rVroWjaYBqgpXx41+eSN0qZKQ1F2FV+Kp7+2Yxm 2cLoh6e1fh7ZGQvkgKo5Fx0KEb+NcxySC2AivN3FGqoPKnYdRhEzbJsMwHFhyyUoxKKWtAr0I2FD Ve+VShTITQk2nhRzag8TkNw3RyWg5rd03G69QckJtgIKGZqb0ybOljitCTviYBIKxiDt2ykhkFEo KUB3PTAztbT4qYaKb2TaNCIgJAHiG3I9R9ObCeQg7Ov4QVOa2ZFVqVTfg3iMsjmEtuqIQoujkY/a JrmNkF9N3J4QOXJVjmIYlaVpQ17j3ykT2orLGEHNz5b/AEeAwS25uRCqVoirRjs3c++WXswPNE21 y0VUb4kbqpyqyDYasmMSCrLZlxzgPJT2/aGbDDqwRvsXXyxEFqCGZTxIPE9a5ZklGrTAEIl7dChQ mnMduopmNHIbvuZEJTLbvGxX36jM6MrFtJ2RFrKYlCk8lbqSOhyvJj4mQlSIifjJxH2Sep2+nKss LjfVQd0YJCQVNK5icHVlajzUELUhuxploiathbUgBBKsS21dt8AFMgpSqfUHLqe3t45ZjNjZhIbu 9DgxIPy9xkhKwgilS0kKyCI1oa9fxyrLHa2USrqKTFfDIEem269m/rAYkAcW7DKjYURVeVR75UtL HQnrkgUWh5FodsIQoMqV6ciOmG2QWlQRTiBXvkgVpDvEydctBRbVSB3xMV2XV6mnTBSFVJGBA61O QISEQtDT9WQSu4Hqh+jJDzQVjE7nFK6Nw23UnpkDFkCskah98oJb4hwkBAPLpuRhtHDSnHIrv9NR XDEspxoKNwB6lRVWPfscvjtv0RHksLyE8G3IyURZHDzQaA35OK1G5oe+ZOOxza5b8lpjNaUBH+fT MiMu9x5w7neo9KNTbo3h88lTVTalwRUc1pt44lANL1em1N+6sMiQ2CVrwwpShwIMVCW0tpalgtT7 UIphEiERKGNhJHXg9adBkuO22Jcrvz4yDif2T/XFkVZWJ2rtgIRVORNiORJrtXIqvVDXG02uL8ep 2GKGhKp6bjvjwsCVCVqKHC/Ca0PX8MkAwtRej040qdyOxyQS0pIqT44VVULOyrSpP2TkVtsq0ezf SD0xBQQ3C8kRYD4kI6e2Mt2NKrxNGVdSfTO4I60yN2lERXCnZu/iKED55ExWldQVO4+Cvb+3I80K hhVlLIPi8f4HK5TMSO5nEAjzUqTLUsKDtkzkj1ZCEujazlT7ZTOG1xZjfY81dLpSPCvcZjnJR3Ze EURG6NuKV7npXBYYkELpPUZKI3E12YgHBuoI6tlAQD1PiMmJkIt0i814ncdiMiQCyBpabeJlpTtT BwrxlLLrTHFSm38qE9cFkOTHKClrI67lSD3rkhNu2UiCe9PDKuVtvNYTQ+wyyEr5okO5r4fE1p/H LOCLGymEbsARSgPVe33Zl5onm4eIg8+a9JVVDGw5wH9k9jmBONG+jk1fvUHBDfCdu2E5ZHm2ACnG Q03FCPvyuVc0gLWJK0PfpjxJppPhPXY4YlJVuVTvvjIsKVre4kiNVP0ZBhOAKZQ30bLuo5HrkhMu NLEQiQ0TL4dskJtRiUO9oHB6MDup7jMuOoDAxWrp8LjlUjxPvkpakgo4A0luyHgwEkW9KfaB+nAc 4lyNSSIkOCNQFRUbitdxXxwiXesg2InBFa13GJkOjXRXywysnHbYDjTrtlYyC900g41csVYfFT4Q eoOWyoUQyo1RVFXnxVvCvhiTQ2YHmrCKp4hiFHevf55VxdSlEsoBrt0o23XKTLamwKBtA0wlDcad QO+AToUzJV1oMrQXP0whghpCK5JIQ5P44swspvU4pbcBgCw28MkJMaUGQjam2XwOzAqW60pv4jJc K3aqje9T1+YyE4rEoqLiRXse3hlEjTYAql1WvjlZlTMQtTJr07Y8VqY0sSh28P15bEliQvcg0Yjf uMomN2yBNIaRNy3TtT2yAbwWuNKAbE7V9skEEtODIBxA2ycZIqnMDVVZR065OJPNhXNYyPXLuOR3 QKGzgfhP4e+XHKRR2phwA7Of4VLUqAKmnXMjHMSFhxpxMdi0AhqFofEYSSwABcFAFDXj4Ht9OFBD jUAAmop9rAWcS0rHv1GAs6X0/twMaNrB6UvapHf6cNEJjNoxfL2xtnxBoKB1O4wsDIKik/RiQoIa ki51IP0YgoKl9VfvTbbJcTGlURIooBt3ORsrsp/V0bt8X83TAZ0tBDyxshq23j7jLAbQpepQ/D17 HJUqsbku1X3BFKj2yHBXJNth2iNaih2r7HGrQQuhnaMNVqCmygVB9sBihVVoJW2BVj4bjBuFRMBk RqxkMp2b39zglXVCPicfaUbdGTuMpyQsMomi2whk2B4k9K5i8LeJUg5rdkJPQYidNsTajykUdMrk RLm2gLkuCvse2RICOFFwXYf4XwxnTXPF1CsCOdIyajp3FfA5OrFtXvXtMi0Mo4kd+2V2yET0czt9 tDUkUqcUAd6h9eV5GSVOKp+374CWzwqGy6WOORfho2AoiaSy4sk3NCh7Dtg4i5MJoGW2dQSdx442 2iYKHoa5bxbJTAfuzQ7keOW4c5jYluC0ZMfFuObqqSSDQHsemGXCQaLKN9VgG/6sxm1viCa03yNJ t3EjqNsNUtu44VtsAU6bjAaQuA71yKrlJHTrhQUTFdldsDVLGrxXJ9XZvh8O2G2uUNkWlyDtkraT BTmUE1jNSevjkSGcT3qCXjxtQgNUd+uIkQzOIFGRzROtQ1P8g9vll3FxHzaDAhW+H7utciSwpTkj ViGp8Q7jDAqg2DLWn0nM4UWk81MtKQVjPw9d+h8cJA6qEyP92O3TNfPm3xaJam2BLlO2BS07DJUw Qrbk/qyVMlhU1HbAlYVNemBk2WUgbbYgKseOrE9FplkSQWJohQZQDuKVzJhIFqkC5QAcmQxBREZp v1U9MxcgBDdDmvb4tj1HT5ZiyDkArVPiKZGmRbovKtMtjOmBjax3FaePTIkWyCm+/TAAyBW8Cdya V23xLK3cApqeowhSbaodqEj28MsjR2LAtig6ireOXRiQWs7thFO3T3y8QDAyLXFlFB0OTjYYyAk0 sRUkxioO9PA5bduMRTtmNenthQseHl8Sn4hvTG1tYCDQMOJ98abRK15ag6bdjgpLahVB4qK9du+A oQrTH1OABLk9MtprtUVJuvp1HzGRsJXciNuBBB3xQqCRDgpkCVxZKbAmuBfU0GbmAQAvcD+uAsap VoCKZQd2wbLTGrHcV9suGzA7oO5tuv7slepK+GWRKLQptowCyN1ydpBainpVHGx/DExSQqRr6blu POPqtDuD9OxyJ3QVonjaQll9Mk14kUGHhVMYGVITxchmNQoFRtkCLLEo22kDLyJCv4ZCQ3VWbi2x FD2Yfxyqds4IeRpUJRjVeoU7jMXJd10crGARamURxRTxY78T0yqmfEQtljYLQoQfcZACizEgVCtO m9O+Tpkqx3HByQNm3bfvkaQY2rrqArxf4lJ2qOn04ksPB7lUspPJDQ9l7YCgDvXKzUPMCvj1BwLX c1SIgePbtgXdY4elDuB08cCRSGkVT1G/hgZi1D6v8daYU8SrcQUbZuVejda5YCyhJDGOgYNUYDLd stUWJSgbv3ywRsIMt2ihXeuAxpINtVr23wAq7jTAtuAwWq7YdcihsAkfPCQpdT2+nArYqCBXCq5Z HqBXbAxICpHKwA7f0w2xMVVYxNuOtOmNMTKliVVgp2ZcDIohJDv+1vi1GKODAqGA2PjlsXGIpDMt W26A/iMzBKg09VF6+rQVNRuR45ZAimQijo9kVDTpmDPcswsao2yDNrl4dckGJCm3Onh45MEMaKip K1oevXCZDuZCJc7UFQSa9QcMAJGkSsOIqoI6HKyKNMwVjjaoGIStoWUg9D18cNKpOVYkjdh+rJXS iLSHkvTcdcyYTackaKtGwG/Y9cqyRplA2uZgGovXqPpzHkG+LTSDuNx3yHCytSWU/tfQRkuBKwnk aE/DXDw0m3LtUZLhsIteC3Tr7ZWY0ytxrQ7b+GNJtoGpPZvHDwrawdaHvl0D3sJDuXksBQH5HJmx yYCiu24g9PbLsctt2qQ3XoKfry1rLnQHcdRvhtr5LQv3jpgZc1rgEUcYbY0olOP2N6bnf9WFbb+i hGLMHZYqqZeQG46fThtjwlWD0+Eile/bICCTNxlQdetaGuSAYWpcAxLQ127jJE96grwktKueQPbI 7MuJWCioUCn9uQtS10Jp47ZUCzXcdstBayHEDrTCgIS6t1DK4Xbo4A6/PJwl0SRSEltgzEdG6ge2 WAqJKMcxjbgw+E4TG2SMWNWAPUHxyu0FUhR4mqgJJ26ilO2E7sbV45mjp6qcQf2juPnXARbFGJIr CoNRlUosxJZK8lQAdhsMwsw3crFVLQFdSHPxD7J7ZGMTTKUgDs2LiWMAMPUXpxbfbAeSiIKhKqMe SjjXqD2yDbEkKLow6j6cDYCFpFfliyBbWRlOxIxpSLV47xx1+imRIYGCoLpGORpHA2HDdTv4ZFSF rb9d8VW7U6n5YoQ55Kadh2yym9fyJWlKr7jAfNjTQoFIAI8BkxLZLXXG0tFd8iVtsJvvgtbcF6Gn yxW14Uk1IrXrgRbYG+w3wotxGBbWnfcdsKVtTilsM3KvjihUjd45Oa706Y2xIBCqz+sQQKPvUVpX FiBwqsBB7dOuRYSRquuyp0p92WAtBHUrJQm7H7HfMmJOw6tPVSIAKA7A9PAYQTRbBS+MSArXc1Jo PDIzIZK7jvlFMQVI8aV7+GSVY5r74qtEb9h9+FbbMO1a4FtYVRfsn5jrlhJI3Yir2WuD3HTIM1Ev 12PvkqTSnxIbCRYSC7ga16A7bZKHcxkVWNfChpt45kUOrj2uKGm3WtaZXLG2RyLSCD09zXIcAbBJ bIm1R1yIiaZCakFB/hkwAdkk0vWNgcfDNrxheIyeuE4iQjxAFwiDd6EdB2zHMDHmGfGCpspruNxk 4w2UyWlaCpApjwbKJrlCkj/MZZAC2Mi1QBv5TkhQPct2O9VBFNxt2y4SaJR7mx1FMsaS5qAmuBIK i/c9u2LYtA7jFBDZj5Cvh+OG2I2UXQqajpXGURIUWUZGJsK0fpkHkKg4BZHmmYF+TmjRwFqSAdly W7WqcAF4jYZVEG7LYSKoNsNqYyBKBTS+OAG7WQ2bbfemIFMV4pTCFcRtTJIWkfScCeiHvIFKcx9p N1PyyyEmJCV3ce/qAUU9fbL4FIK61nMexJKnbBKNpRglDFWU0p22yFMaRkbtT+YHtkSELjGFYNFs R1j7H+3I8QOyaI3XLIr1A2I2IOxGQlAdWQkejRG2+4OV+GRyZiYcEau3xDwyqUGwTU3jqaoOXivc ZVKLbGSiTtSmw7ZHhbbWlRU9em2SlFRIrCtMhTYC0VwUyBcSe+3yyNJXpccaVFfHImLExV0lRhUb DIUwIb5DwxpCjufmOoy4xIbWjyB8PbIlWqk7nAlcAT0yRQ3xYCpHXIoteEqo26YGNruNKAjfFFru i0HbFWqmvuOmFVrdcQkKR6dMLJrfrTAlup6/qxV1T0NaDFVUEgA/tDAwVY3qaj6cBYkI6BvhK0qT k4lx5heyVp/k5aDTUtJoCRvTfDE2pFNAs7cqUA998JFJtf8AFxFN65EhAK5Y1C9PixAUlsAAUIBI GEhFtcgw2pUdseFNOKcl36Htg5KVCWAcfgFGB2yccm+6KUGX4qts3fAa6MwSoFQdjsf44slvc16+ 2WCjzYm+jQJFf14eFSrR8P2ticRKmJjaq5oB3B75Lj7mIgtA7HKzkLYILGA7HDHIjgaKVNRloj1C iXQrlXw75YAwMu9se4wsSe5sjqfowGKiSxozXb6cgYMhNsIDXbJCK8Ztox9+2R4Gzja4GnjXGtlv dsDj8h2xiKRLdsUO4yYkxIbYfD7jJtRFKDmo7YswtFCa4pVKdMCLcVqN9mPX6MKFNo5BuoBXsDkt kgrRzB+JQCNwVySPgvHNnAbY/aAyNilIVX6bZjzNM4rQNq9umSgxm3WnyxtFN1OA2ybBFaZKMmJi 2RTc5NiCpzqDC9dxTDHmpS9uJrGe26+4OW+bFDCHiSYz8J6o3Y5O+9N0rwxdOW3yNciSpKOhicH4 D1yBKFdW/eBWPxnuO+U8IPqDbxkDhLpCKgnqdq4TGxTEGi5Sa+K+IwobJYbg5GVsokNMa9R9I65A 4+5kJUpOq7Mpr4g5QRTkRLliVwaGjDehyBZWpMCDQ5EkNgWlcFMgWiD4YpWcWJ2FfHIGmVrQSCNi MBUrvrD16/Dg4UUFagJ8MtBtLbVr8W+QlCkBriK+2RTbaLviglEgAgYGtxUAbde2BbXLFtXqfDJU gyXcFoBSm+NItY0DDYY0kTWmE98WXEpvHQAjc98UgrfTruO2Bla0rTbvirgBT3xVctK07Y0gqwUD 764GNoqB6A8T88ILTIKq8m2J2yXNgaC6gHw9ssFBrO7SdSMmWCoBQbfTkQWVLhuBvih3Fa9Nz3xt K1lUEdK9eI64UqmxHXIoWMux264EoWSJlPXJBKFdFG56/wAclbMKbIe+IS4KaZPi6MeFUWn7Q3yB HckLlNW4MKjemEILviFdumAbpWkiu469xkuS1fJsGh3G2WRNMCGwy1oDlsZBgYldsdsm1cmwABQd BirqeGKt0rgS3xHf78K20VwUy4lpVe3+dcaUSLggGDhZ8TiKe+MQxlRUXUV2ybEFTIocIZr1PjjS FSlcCFwptX78UELeIJIpsO+Kglb8IkBY8a1FTkaNUzJXEbnASxAWJ1OQBo7s5DbZfx2yUgxBb4/c ciLSXBckxXbd8kCghriNx1Bw2hQa1WtVAI6FT7ZPiY0oNp9W/dvxqKEMK5LjSrw2ESpxcmSu/gK/ RkTNVX6pFGOSltu1a48SKXlV2alSNwchHbZnLfdQ9Fi1Ry41qammT4mNFv02UALuK7qf65HnzTy5 NlqHcbdsQshTZPXx7ZCfF0ZRoc2tupwHzbB5OMYPTrkJQBGzMSpzxL+ya7bg9a5jmLMTU2Sm1N8i 2ArChxJZBaqNWoyEqZW5kU1bofDILbfFePHavjgQ2UGTZ27iQcIKu49cFLasijAWBKoFpkWFrgu+ EBBOysFA3OTayWqANgpNrm3Jbw7YqsIX78aTZd6SGvvjwrxqTW4FT2/jgpmJqbwg9eowMhJSKkde 2LO2wK0JGNIKsBXIsCvjJVvn1woO6I9WgAUb4bauFcXG3j3w2jhVF338cmGshcRT+mSQ4E06YE0u A35ewxIW3VrUkbjYHChv5n7sVWCRWcxg1YbnbGtrV0kfIewwJQ8kO/SuSTak0J3oBiytSMdRXvXp 2xTbqDv9+G0U4ChFfs4Uqi16A8h4YdmBC0qWY0pT8cDIKZFDQ5KKSu4g0NKEZbw3uw4qb6Za1FeO 3vhYELgK4q2B7YrbfHbFWqVxUu496Yq0QK4raw7V/DFJUzvtTFQFMxnDbO16p0xtiSuKGvvjabXL TuMVboabdsCrHA60rTscKA2x2UbUHTbtkALTdKTgcsrm2QKooHyyIKC2BTLgwK76MFrS6ntjYWnU qOlcMSghojbb6ckwaoCR49sUgr1XFV1K42kLQlDXrkBszJaYb4bRSwq29P8AMYDY3DIEcipsgdq9 x0OTjO2Mo04inbGRpERbqA/LIyDZErgNttjgA7krGBByqQbAWuXj+GUlsp3wMACOnfocSEWQsMe9 RU/ryBDISWNSpqPo+WRplajT4sNJtFUwMlw6V74EOCV3xW16Ke+AsSVXAxcDQ1whC8NUU7ZYC1kU 2AMaW26UOCltog9caTba9MVO6/YjpijkoyKQK0rXvkSGyJtRKBvngZ2tKk7Ab+GKVRRQUwFiWwpx RbY5KajAhUiNW3+eEMZKoB5UBybBedsNsVwqcKrulR2woa7EHevfpirQ+xUb0BArjdlS1xJHIGh2 r4YCEgr1YtUUocUU03QgjCFUiKGoySrGRSB79cCbUXiH3/jhZWtQ02PyGGltxA7dR2wJWEN1HTCt tlARt1whFtbjLYlBC9SKZYCwMVwG+EFiQvWhw2wIpcBhYuOKuoD7YqC7f6cUrGI2r44opacVtSNa YlNuUeIxVUWlOmK0v4/fittFT4bYraxlI3w2ya5VJ26ZXxWaTW1rHIQVpsT92WBC40YZExUSpw2+ WVEbti4GuKKXFslezGnK6rXkPpyFbsiFzMCKg/wwhDXz+7LQWshw64UUuFcBKQFwwMnHpiqm368K VrGmRJSAsKfFyHhuMiI72y4tqaLEgEZIz2tAhvTXfftgMgfgzAI+K7anscVaK1NR1PXIyHUJB6FY 6ivhlMw2QktPhkQWVLSStK1pgKrSwYb/AIYE0t4rhtUQF3yBZ2qcQB74GNtgd/Hpiq6mBi3TfrgV 1BhVdxB3H3ZJja6m1fvwsW1rShxQWyvhhQ0BhIUFtdtsjSbXgbbfdgVSeIdQN/bAWYK0Ritab98C bXBR3xpFuCiu2ClJbZAcCgrACpBHbFKutCK5MNZboOW/bCvRU59umFjTsKtMKjFQ0Bt7HtgpNuVg ABSh8MLEhs7fEPpGCqSN1wPKmFDTKKVGEIU+FPl3wqsde43HbAzUXAG564QkKTU2phS2COmSAYu/ VhAK27jkgtt07fdkkNio6ZEGlItetS2WgtZGyoKjJNdNbYrTY23wrTjTFCwjucVWMKjFVvGgr92K hoHx6ZG23hVQgptkrYWuVaYlS0afSMUU0wrtivJZxINQMiIBlbVP9rJBVvEo3LqD2w81VKCv6srK Wgh3pgO6bp3CvcfL/bx4V4mwnY/fkrDHdviPD6caCkld8/vwgMbb4jrjS2uCimApBb4jGk2S1xA2 GICkrGGEoipMK1J+7wyBDaHAg7HuNsjaaaC7e+GOyyNtVqem3c48a8FN8WPT6MTxFQQGipXc98ar e0g2pscpmQ2RC01yvibKW13odhiQxa4g4Va4ZPZbRQB+/tlDY6jYobqaYqvUddsDEuoRihum2Krl qMIYlevXfJBgXGp6dsSEh1TSvjidl5tgVwsW6VxVsA0wEJBdTI0m1NqhsDMNE4q1U4EqiU479cWJ WkUOBLS1B69MKleta1oThQVVRsWPXsMIYFp5CANsJKgLg2wPY9MNoIdWuFDqV7VGKWqMOhwUkENV I6bHw7YErlbkKdD4HCCwIpv2O2SQFKUHt0xDJQJJHTfJUlZxJ6jLIxQZNcD1yYigyb3+nJEItvfw yuqTbdMkQrqZApbC7e+HakL+VQBQCgoad8lGTExbKmm3fJFAcDvTESYyjTVN6Uw2ilrHsckimgK7 jAh1KbYVaKfdkSGyMl6Vpgisxa6m4PbvkujBa/enXrgtIWhj9OG7SYuNe2FCw8ga9j2yBtmAC2HB 6D6euImpgXNGG3XZu2TBa9w4GVajqMaDLYuEh7gH55AgpoNl2P2QAPbBwnqVsLlPIeBHX3wDY0pC 6hywFhTt8bXhXL02GR4mXC0elcKXCu+EIktc0FT2xJpjEbqJ+zX3yo7uQBu0DvX8MiyXr32375MN cmqdSajtT3yIPVJ7lvI70r8sj4jLgdXbickDtRQedhaOpBGUZBu2xLbR/DUZUytRZPi2ywSQWqHL BRRbeGkIlVByhsJXMK7DFFtAD/bxVeBT3GNItcwwMWqb1xW2wBTFSuG2TDAt42imqDEhNuFcVK/F DYG2KWth/TBa00d8BSFjIciyBbC0GFFruP0Y0treFD44KW13CpoMNLbdGUU6DFHNooa+x6Y0m3Ff iAZtuuGkArwrdz8PicNItokA9a4q2DhBQQ3vXJMabC8unXBSbWtEV67+4wGKRJ3IkcSd+xxBWlNy xqOlOuTAUKTfRko0VLgNsuEaYEuKjrlgLAradsKAVwWmQkLZAtgYlILqb1yBDK298rJLIAOFRiDS kLq1FPDtkzZGzDk7hX2x8PZHHu3TbLI8ms81jKCKdsPJQtUUFPxwpIXUrixIXADFXFRkSGUZNdNs AZENMAev3jCUBaVPQio9uuRopsNen4H6DkgUEup26Hwx4gmlpIHUZVM7tkRYXLxpVXofA5AZKSYW 4kjqN/wywZLYeG1UHvtlgLAxdtTCit1w6e+CQ2ZBcp333HcZE2tBeBtkwwLjsa4CyjyWmu9OpyPJ m5K0NeowxYzCnIeVAPHfIyNsoRpaVqPcnISLMLRQNvkCWdWuBHyOETQYtl8n4gYeGtLLvXIGQLLh K00PfHmrWC+9LdcjwptYVrkwiyt44Egt0/28NFbRCjKSzK+ntii3Bd6kbYra+gp+rAxtun34aRbW xxpQXccFJtumIQd3AeOSRyb41wgIJcBihsDFV1MBSGsCXU32xpNrWBIpgpQ2OlDiq7jtjSLapirY U9QMaUlzCtPDwwqG/SJApjwo4lrIa9d+2NMgWjzPX7sV2caKN13xXmtDfFimlRSK0whgQqjYg0yb Fc7qFqMJLEBCl1NdjTIU3VTRX6QcCbWFPw6ZOEqKJbhsCo2zJtpdTJA2xIW0yTBum2LK1wX7sBSC 3xyqTMO4jKiyDXGlcANMubumTiWBDanxGTEmBj3Nld/bJsbaYYWK2m+KW6DFV1MWLgMKt8cDO1pF MUArT9xysytsAa5eIyviPVnwjou+EivWmEkSDEAgqbgHoMgAWywt4bdMKthAQMkMYQZtEUG4wcNF eKw1XjtTLOOmPDaolSN+owxNsZCl4XJIbXbACghugxKhwXFNuMYPzw0jiW+kAD3wcKeNZSlDTKpx tsBWMAT0yumdrWGCmVtUxATbVPbCi3U642xbpjat0wrS0rgpbaApkgUN09sKq6rlLYSvAwMW6bVp hVvFiXEYUNV9saVcMFK2MKuC79MQFJdSh2748l5t03whiW8KhwwK4jBSbdTGlt1MBS1QYEtg7Yoc BX5YVXioxQ0AQa9cKrgPDChZx8cjTK26CmFFrWGApCm49tu2BkHKThUou3Usla9MsgLDTM7tTbKQ epwy2WKDYgHbKwW8NK7D5HtiSkhtiKCmKA0rb7/TlmOVFE42F5UncZefJq97XE1ywFrkGwlcbUBd xNMrlJkA0a5WSzAa/A5Bk4k99xgpK2mFDYPbJgsCF4rlgayGiMkxWkHCm2l27bYpXVxRTqnFaXds UU4iuBVNgeuVyjTbGSyhyBBZhqmQIZW41wq6mEhbXV32GWcQ5tdLSKn5ZC+JlyaIJNaZHcjZOwVE G/z75ZAsJrq+1DkjJiIt9Ppwp5tgVw82PJeFxkaQN3MtOmVglmQGqZaGsqdKbU2yJDMG2itO2RIZ AqbAAbjfAQyBWU36ZGk2tYHBKKQXBWA748C8TYBpkeFlbt6YFawobH3/ADxpV3HDSLVwtMrZWuoc CHUwq3SmKHUxpDVMKHccaW1wHbFS3TDSHDrXAlvuBTbFWwO+FDqYodTFW+O2FDuORIZW0Vp8sFJt bxwJtco7YUFfTCGLfHDS27jjS2sYYKSHBcUuK98VWlanwwJU2FDiyCIs26r+GTgWrKFWRQfl3GTI YxKCliodsgdm6MlMI2/jkWdtjb+OTtDRGRITa4Kw6HJiwxIC4OD1yfitfhrwB2w8Vopsrtt2yspU ycJNsgGuuBQ7phpSXUoNsSGNuC+OSjFEpL6UGWANdt4WC3b5YVcRim1vGu4xS6h+jFV2Ku3xV1K4 FW8SMjTISbAxAUm3EAjfr44SAgEhay4DFkJLaZWQzBbA3qcOMUiZtvjtTJgABhdltAoGQiRFlIEr itSD2w3e6OTZG9cmGLslSFRTTBKNqC0+Q4WdrMnVMS4ioxKBssG1ciGax/HAWQU+JJyvi3ZU2FPX qOn0ZMDqglUAoP4ZYxtTYbnKJNgLXHI8Kbdx3xpNt8cbV3E4oRAXvlabdQ4UNjFDdMaQ1Sv8cNK1 Q4aRa4YFdTFW1/DCgt8fDGltsAHbw740i3cQBWu/hgplbdMUONcVd2wod8sUt1FMBULab7ZFkuA9 sNIbAPTChsYUOOKVmBLVPDAlsEd8KtEb/qxpbXejyX3w8KOKl0UXAgnY9sMQxlK1VyDv3yZYBDyg EdemRIbIlYygqCB92JAZAqRU98jTMFaRk4xvkgybBoN+mWjH3MTNojKTAhmJBsch0wbrsv5sMSim qjvjSu6YQguHWhycWMnUPbJGKLXAbdMItiWzsNskN2Ja5GtMlTF1RgpDhirRr3xV1QRXwxTbhTFb bocVtwGKXYq4jAUBqmBk7rhYtEfjg4WXEtoSd8qA3psJX06ZcGolwAHzyJoMguCnocAjSSXHLAGF rC1OmFBLRkbrXphpCm1ww7YaW3JcCu/fExW1cMCKg5CmVrWBPTrkZBkCpkGtMrIbLb4nfbLAGu2t wQDgvommyaYTJQFOhJypsXAePXFW6HAl1MFLbqYKSr0pkUW4AYqV3HDTEl1N8NIt3EYq7iMCtBQM KtgA4Fb4jGltUFADTfCxLuPf78NLa6g+jGkLSgA64KZAtccCupirqDDSuKg4kKC1xGCk22MaUrqY aRbqYFcQMUrKCuKVwUYaY22Yx1xpba9OmCk2uSg2HTJBiV+2SYtNviqiy4lkC2EHb7sIVoovfGk8 Swxj6MQF4lpjyYB6LxNcKZPivmxquTfEZWYtgLiqgZIQQZLaKcJxoE3FQB1yBgy4mlA74Yx2Ykrw oyYQXU7YWFt4OFNtHCxa4j78VcVBBGBW6UAGKHU2p2xVoAYqvAwUtu4jFWuOKbdTCqnICKMOnfCE FcCCoOCltvjgS7iMWVtODx+HriCgtxENuRQ+GEjdF7NsjE7HDaFpi2HxHG1pRYFWp1pkkLm2AB74 q18DfCfoxVSaCh2O3bDxK0FdehwqvExGzffgMVtUSRH+eQMWVqhAwLaHkmANF3yQijiXRurjwPhk ZQpmJLuAyohmC2EwUm2+AxpNu4DBS27iMCbVqfhkFdQYobwodTFW+1MKGqYFaOKtAknGlXDFV4xQ 2B92FVwG22KHdMVaPiMVaI8MCWqYq3hV1MFLbRGKbduMKG61wJaOBLuOFSWwaGhwsV/bCh1fHFWi N9saTbgfH78ILEhs9MULCB0xS1QjCm2q+OWc2LqfdkaTbfHDS2tZcKgreOCrZ20w7ZOOzGW6meuT YNVqcBTa4bdcCQV3yx5Lzbp775HjFrwlqmTYNYFaIxVvbvilo1HyxQup3wK0R/tYVbGKrsCupgVY zUPthAQ0QhBqcUqR5LJx7HofbJoVlau2RISvwK0RUUB+nFKmC4bffJIX8gDudv1YKW3V5CvTFVqo vqDfcdsJ5KGpFPLxGIQplCMNq0ScVa64q4rXFVgUqRhVfK5I2wAKpqoPXCSqqqjYgdMilWHTIlmG 9sjTJ1BgpbdTAQm3UFcCbVaZVSuphIRbdMaW2qYFbG+GltsjFC0jFLj12xQ3T78UtjFC4HFW8KG+ uFDqGuBXHFWtj88UtU8cVdTFXYq6mKtkY0trdxgZNj8cUOYVGFQ2p298IQW8KHYoto1xSGwfuxQ1 SuKuwq1T2wgLbqZJDeFWiMUNEYsrWlcIW1NxhtebXAY2tNgbYqW6Yoboe+RMbZCbqYQxLqDFC0jC rVMVbr2OKW6eGBFN0xVrfCrYB+nFXHbAqkzDcHDSFtKHcVGSVV+Eipp88glrjH1FMO6Fgk+KnTDS rhVfcHAlUH2a/fgVYyVY+HU5K0Lh9kE7YEt8N8bVaXUmg69MaQ4MB13PvilTdar0364Qq0KCKnY9 8KFwAHXAq112qOuEKsOKu402wKqIKYpXkffgS3vgpNtj5YEt0wJdQ/25Gk2q0yuk26mNIt1MaW3U xpbcFxVdQ0w0i2qDBSrStMUt08cNIt1KYEtgYobxVcKfLChvtihqm2KWiPoxVvYihxVqmNLbhil1 MUN0GNK6mNLbuONLbXHFNt8cVbocLF1NsKGqYVdxwLbqYq6mKtlcIVbTbCriMKGqYVdTFXUGK2sZ cBS1x2xCS7jTJWhvjvihopuDhtC7jtgSpsN8KFoqMVb413GBWymFLgD3xVeBgW2uOKl3GmFDTio9 8VUinY/fhVx6EfSMVd0361640ruCk1rtirTKK7dO2FW1DA+3cYFXgdaVoTgVV4jbwwJW8a12rTth QsctXbYDCArR+IVp8Q6Yq1UGle2NK2WA2HTGlWlQR/HFWiCFGKtEHbbrirVO1Ke+KuCHFVyimKr9 vDrgS3TFWwMC2uptkWbqDBsldkAFLdMVdTEq6mBWx0xVvp8sUNEdxirqbY0lqmFBdjStjbAlvY4q 2QaYq7pih2xwocR27Yq7FLsVdTGlt2BNOwsV3HFbdih22KW6UwJbB7HCgrWNN6ZMBiWtiKjGktVO Kt9sCtVw0ruuKupirRGIK07JIdih1MVWkYpaGKuKk98QUt0wod2xVxxVTYb4ULSMVcKjFV6mvXBS tkb4q2o2xKW6ZEMmiDkmLRpTChTNcKtGnXFWqd8KuC7UG3tiq7gaDBat8e+Ktqd/bwxKr1odx18M CrTyPtTFVpqa1wquRUpXAVcVXr3xtVMqKbbnCrSDenjhKtsrdMFq0VA71xV3DG1cBTFXUxV3Tpir vlgVeDiq7tXFW96VwUE2qdsqplbeKuoMVdTGltumBbdirqYq6mFXUGBWsKtimKupgVwxV1MVcBiq 4YodxGK24bYVcRgVrFLsUt1wsW8UOxVsYq3TCFto0pv0xVYUHUGhyQQ6vjsfwxpNupgS1thQ7bGl tvFLvngpVuSQ4nChwIwJcaVxQ1TfFLdNsCuoMKu2IxQtJphVaaHCq2gxVugxVqlMVXin39MCrqYp bwJaphQ0QCN8VUyBkkNYq6gxV22KtgeBxVuo74q4rTfFWwRXrgVup6Yqt3rvvirZQdumNqtIHbfC rVMVbNPDbArRphVwAPXFWwB9k/firiv3Yq0QMVapirqDFV4AwK3x8MVbxVV4ZBLfHBSupgpLiMQF bAxpXcR4Y0ruIrgpXFa4VaocaVsAHGlb4jAttcfDCrqHwxpXUONIaofDGkt0ONIbAONK3xxVrica W3ccFJt1AO2KuoMaV1BirqYVbphQ4jFWq4rTiPDFadSvbG1p3E4UNFa9MKu4+2KXccCu4jFWuOKt 8cVa44UNcfbFWwuKt0GBba45JXcRgVpkBxBVr0xhQ7gMVdwxVrh7YVbVcCVwXFW+IyKbdwwra1k2 whCnwySu4e2BXcPbFXcPbCruGKu4e2BW+JGKu4juMVb44q7jTamKGuOKWuG+Kt8MUNcMUu4Yq3wx Q1w26Ypa4UxVvjirgntirfp+2KHcMVbC4Fdw36Yqq0yKXYq7FW6YE27fwxVvFXEYrbVDim3CuKHU xVsDFbbxQ1irRGKuFcVbpirsVbxV2KuxVrGldil1MVdireKGsVdTFNt4odirsVaphtXUwq7FXYFd TFXYq0R7Yq10wq7FDqYq3TFWqYq7FXYq6mKtEYVdTFXU9sVXYEuGKtk4qsNcKFtDhV3E+GKu4nFX UPhirqHFW6eIxVumBXU26Yq1vTpirdfEYq0Vr0xVwFO2FXb+GBXU70+Ywq3QeGBWiPuxV1DhVric VdxPhirYBwK3TFW6Yq1TFXYqrUGBWuIxV3EYq6mKt0xpXUxpXUxpWqYq3TGldTGldTFXUxpXUxV1 BirVBirdBirqYq6mKupirqYq6mKupirqY0rqYq6mNK6mNK6mNK6mNK1TGlbpirqYq6mKuoMVdQYq 6gxV1MVdQYq1xGKt8R4Yq7iMVdQYq6gxV3EeGKu4jwxV3EeGKtcR4Yq7iPDFXcR4Yq3xHhiruI8M Va4jwxV3EYq7iMVdxGKu4jFXcRiruIxV3EYq7iMVdxGKu4jFXcRiruIxV3EYq7iMVdxGKu4jFXcR iruIxV3EYq7iMVdxGKu4jFXcRiruIxV3EYq3irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVd irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdi rsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdir sVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirs VdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsV dirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVd irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdi rsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdir sVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirs VdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsV dirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVd irsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdi rsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdir sVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirs VdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsVdirsV dirsVdirsVdirsVdirsVdirsVdirsVdirsVf/9kNZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqDTw8 IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyNSAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50 cyAzIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gDS9Gb250IDw8IC9GMSA0MSAwIFIgL0YyIDQ1IDAgUiAvRjQgMTMgMCBSIC9GNSAxNCAw IFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1OCAwIFIgL0dTMiAxNSAwIFIgPj4gDS9Db2xvclNw YWNlIDw8IC9DczYgMzIgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCAxMjI1 MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYxX23IbNxL9gvkHPJJb4RiXwW3f FNnOOltWsjFTfrD8MCZH0iRDUuGQVvyh+z97uoG5UPLDlqokdQN9O33QwPxVKNGKQopQaWGjFSv6 59hkza74KPaFLKWyJOMvNlVljLyPRGylLT+ui1dvlVBifVfE0gqJH/prtSmDi5XQvpTYvt4Vr657 Jza9kKUynn5rzb+t6Df74tVPH5S474sVgrLBBqmsn4pPi/hKS7lUrvQLs/y8/rlYWV0qJw1CrV9n A00GC+2W6z+KN+viP/9nNEMgWBVLjU3GlPgXtc8UlfeCRRlZNJpFhb9Z3PB2Gf2g6OYKG2JWAMkL WU+KeQLOi2f5bIoHNjCBU1CwyykGTkIjUnbp2KXR2UfFPowdXFYs+iFno5IipHXjUgmVnosWVnl7 UjhdpXXF0V1IovKjSNtDGX01KLq5gvK/gOiFwtgBRCWfKbSJlyYzULqMk3KkCVJnmExQg4JEa9nC qWoumjigkhVUz2itifmDbxZyjdSlvBhKz4FVmAkDGElyWovRbMpoSnhzUUKsKi4hlMHaQUGik4Hd 5bhZNEAvRcsKmZaDpRyDVbMKSErlVlTutOwH0zAXB9ejwsuEXuXclNg8701xV1RBgfUYAa6MSqGU ysfSmVFR+QA20oRwYOwgxTI6ss8ycpOSVhFMJYJaQZ6tCVnC3oBdxo2rmmnLZK9YjIkDunJ5d7CG XNMx61hRWY4FfpHzCNZCsjLFqoIbRDKXaRzkdWRmaTtScpOEWaM8l5EUGo3wgdcjuIaiQ0zOCdws bhizaMy0jszwF9YS5OFSJDvTVa4kpiGrK5MrsZ7dS0wu8kZuBsAvG5J6FEoLVJCv5tk3KBDCRvLg S68j52NJxBgOZhApA4vuqWmdLgm2JnYOInnnUTkqkBcGOFkHN4M6eZ9B7ctow7Sek1Wlc1o8y50O TxVAURp7UMHRblLAg4vJJFG4coYDhuAGMefnp2UwHfAZIoSexLG3WUHF8zqMkYhOTsm5Q1eyuEnQ ElbDekoNWNFofZY6NycSd9Rwh+5GBRKSnibeTBGJfRCNT1zFHKpiBiiJyCDirJk4rQNvrwbqDhIu VJ12J0UOT9HQbGNfKiif4C8VwQNuiJULU7yqvMiGRuIsGxxLzQcJSE7ilE5SzKKDB96+VBg6zlVW GDfxJ0ocrkQ3IitEm9kXmJ2DApPCxmyvJV9sxlhOSYZ8aToWfWKPqYYMfRoV0aeCvOProyKyQ3Rp rkg97FbDgOsYDsm5RlRDUshU9I6hI25lMTVHu2kZXFOp0Mok0TGy0pi8O2qO7Qyte74AR2sMp2ry bSUwr9SgINHzqQx4Pg0SDa4qb/Zm3oQL0nbgsZVVGVQ6CY6uNEmIVVm2Eo4TzUxlJxH3pDQcICmI U9xVK8F2Zb6jSI3oJpMXCltqoNaNKUHhqzhXTCauVFF/RzGFrRiRFwrcYcaquSKNQxJ5+AcwHHe/ tPy+zCJVimykn6/HEHgUo2lDfBKD5e1ZAaRNqgH2nsc77jWSNN0FGeV5D2i6WIXTIHmcxdwWQE7v qaQgf3iT8YF07A9XcJVIxY8++jxQg7hhfzbxZFiP3CQvnoVKzxyiE2msVfzMSTLuZEXPInTUpwco fXtQLKcHccOpymjHdenpm4Qi47YYJIxpmRjKMk1pR00IuATjAAs860qNsFBgOWKmaIy5gcqUoo3s SCfqQ1Ep7oh3hl+kKo2owLc2iYrORprwDNA08DeMrx1XM/r0ULAmiRQbT6bocjBv/aDokiJdR5Jf kgOgdH1cwpva7fA/V+YNA17xgzQrrMIwxpMKxdH7YxQjZ0Hhk4LIHikarNP44Q8Yl55MSaTdnp/U 4zqwz/OGRghepVql46lNfrRK6QamdWzvcKMQe0yyN5aZGJRjUapB2nBpSrlp2abpR+j7SaRPQd6d ZB2ZB2wsuUnWTqVkMZdiq2kdD6J0ok2qRFpuqQ/DVwGVBhhVpXIlnvoIt96yuXJmQn3eFGrTX4Wi b1IpAn2Hob0r+ufYZM2u+Cj2BZ08SzLBYOlqiLyPRGwdttAXrwGsknOl717i2mioHIiMAAYPDzK7 K35cF6/eaqHE+q4gakr80F9T0fNTiUCfMgpv6vUOadIPOV0RAeFvvUGS66fi0+L6l/fvf795d321 xHPXL9bvfrkRN2/WH3/57d8flp/XP2PfCjerw5tw/bpYXN28HpbF+6ubq5/evH9zs16u/ygqQ+eQ 0kj/0Ts40MdGoCsY7UAi369UUjoLdvLqrXpZktX0WRmEw3CAp5A8KbAPv7Xm33YqDz2Gv0+Lw7b+ 9t+lwkn2i16825+a43KlwmLfnETbiy9132zFYS9ODw1WV1zs+h8wnG/89bgkViwOp8Pm0ImvzbFv YVOJ28W7X79Wt8tSXD2OtovHrt3UJ+zoRdf+2bDvp8Ox2z61W/zXfKEiV5hNAHSO66fF7eLjx4+3 S1Hvt6LZ1W0nmn39pUOKKb9ZUrNMD+J+SPBJ1CfxcL5vxLE+NX0JGzZt6mP3TagYZf/DmGd7El+a Tb1rxKbDBmyEMRWEbM/dVuwPtIGSRfvpxQFGcZqUkkDY/tyf6pYiAMpj/dhucyYOmZweSvHm74f6 3K9eUghZE4KHO1F/RZnskCPX22320PR904unuhePubpm1p5tuzkRLAfxUD8+NntRD4HPwA6F2lJ8 OAHHQb+d+tP29Rhd7JunsaEuNdShA1gDblQ7h7skzjM+ZBCbXbtv9qdyiDM7Zp8W/zo8NQizxAPV L34Qu2bzUO/bfpcpctOcwJA/xdV2XuNQd9+LdbI81vu+S9nfLm6ulpgIYbG+Xf4AJO4bZHwUT+3p YUYONP/cN1TP47H9ClJc4uwzzkBqMrru6r7vKGyq2+Ipsli9Puyo2b8dzqd2f4/41+9e/3a7nMya v0/NfpvJ2rV3HJWileL3/d3heDrvEb/7lkGYDMdCxJchqfpP5CTu0ExAuz/Vndg2fXu/F8dz18zL A2V39ba5OCC4ErlPvNqfNxuUcnfu/sl2NBLp6xDXicQJ5IHGR2S/XZ0OK/wRj/Wx3rb3Ozo++8PX hHe7zydhzuLnEcHF6fATd3vueqoJJ/Chnc+Y7bi0FV++cQnt/jSQa3veDDQdAcqTrFxi3C3EO5ph I62JSN23VDS5yoVnKgtMlpHO0/l+qL82IDAO0OOh71s6h+0sHtZnvOB9lxmmM/g98LfnI2gyZjdN oJLSeIOb67p34vqDeHkffLi+AdA/Y/L/IYx4EkqK9+LTZym2hcYb+n98V8ty20gS/AL9Qx/tDamN xhtz00oejzcsh8fUhGPD6wMIghRsEOAQgGjd9hM37B/arOpGo0HSujCEVj/qkZWVBS1HUjoiDRwk oVTp+F1fLKgnun2DDwTo2VDotnFwlQNRu7p9InhRK7D+99QzuCB0uF4UeYMQOUCiEO3qvGngPSpi 94Au0kkb3Xuiw12+QzECtMW+WqLAKERAxxi6vHgQNjaLQ9V1Rbt14NYh8jiUf0PEUToOGZ3arim+ xXt8FLWCXOzzK2sQI5NwPb7+yAYBJ3h0O4KwqOgkLrd2nQ+QFOxgxcja5l/bvX2o2u5Q5nlTlKPR J7CgF4em6p9cWBU5cRQ7Zrm+RG9Z1lX3YIJn6tOhG6dS2T2iP3Mar5u/RJ0/8QXTQdstqVWMdjZg L4TSlvuybTta4GNAqwFeQJo1nYBnvp8DXhB5FnjPM4acEVQYQkvHqSaaeyroqZ8lL1a2sDlsu3lL 6oaqL8+13YMNkVhXgEpF+keXKhVnahXDuq2njlm3B9rg/y8QTyhkalp9j1JxAII2PALuBfoxbqVG pDP3vSh3I5XRwqZul3k9wzPESn+1xKkf8bJtyp9S3KEm6NGCBMQIsL4FXJErbKSM13nxjS49gXG1 dYCyq0vuIYaVpwiQLdzT1nnRt/uJSg8PTzqsROFEk07t56av9NW2PKr5ruoH0yw62L0fH2p6UB81 /I1unF1ZTrwoN/LSUH/VVzj+WI5x+mtxLW5LYLyfIsDBxv9vy3XZoGg+qy/CQHh8rsAWp5m3274s oI/6CjKP+syiqh+rXPyRb0Aun/0vpF8/nNFYZ8kBHW3/WBUkGWwcG+jOdq2/1lNPsz7mdS3AOftJ CSO9VF5vFx9YemjyctO8d+9nrqXQ/bpDznhLM2JFQGFZpd8YDYcwNHxrEXhEu8uhqnsx7AQrmo4y 8g0+1hbg5QoKWzMqkIPyhVD/DheqkqgPz7M5ZrP1HKqq1/VDFFoygggpFL59tXnoHf9NaemQ40K0 IJfgy+axGqMwKQqtOH2epLYsRXmaMgMimMDMHGACR5ySNtXvUKMr2vJ7BTu5ekm8zSayY/nD1ukS qZqJfjXg2+0O9lJLnWtSLQlvEO3y74H3WlmcN0+ONp6OTDJlToJMX4iWHpMIG+V+oi3KPWAjjeRF vthgi4pDBWAW7ZRW9pw6Qk4zwZOoWwIdpWk1lEbojJt5ymqG7RLZNTrX3nwpHgDvzuaTnp5Jw6qB H3WtjV9BFUtxW00VNLlA1d6hoPN91XZsmkkQI828+8qCjXv9BHm2wi2kUeMcply5Ynpcw0QImzYt AK3bDM0dFdcaZ8chCT3ETE+UW8JtufpNnEOlkkLjKdR4UlIpBdlHcKJtaJe07XbI6ytEqPj22wx+ ESR7luntLoK1nxokrcHtqOCuYqkSFZ0BLj+gAzXZP862RqdQHCZn4X9Z8ZQ177dHM1/ARvnyxNVE GVd5wz0PFDJUQepEIOT/TYPePALQBKmfnkZgVTK3XSJxGlbmAhDppYlCoIJkHoUZw5KUXwI8VGQn 9TKvKc1fHfV/3Qp+jM+VP3GHw+N8G3EfQEkl1TH6R+Eyl0JTmD/Mgys+vbzywxdaTlCbbeuBInPp 1tR0GoIPCdrAmANJv8nJdo2qYfGgdXu+WlWTY4xuM8s40Rvltakr6xq/onlLnkN68BzSn0m/LoAB s0Vdg7uOsx9FcXSSfQSaD7jODoYZ2RXtJTDgpSqbY4AEOzFQTlmB8jpWkty9cuv+VAprAKQ9Vwuj gmQQwQK3NcNSSyWXtrnpnScuHKoVBtrp6OgSs7yRJS0OFb25CSlrVt0rzb2TpeTBjJ6l+L3aDPYd Rc22KohB2sOEB5sDoQ/pTES/bKac9zEpB1ZezZregdX3L5NApi+Mi1QIQydO9bmTU0/fcT1A8gLg hb4iM1fwUQsLMveayV5AI6BJbMnqM9Elb8b+1WF+ojG1+Fb2nW73ueh2ZVGt8ZoZMru+csZIrW1R NmPouo7yAdWQd10LidiXK8MdK6dFuNv/Y+JK49yuRSZJfN474lWTXvdQ7dwB8RwtzewACZF6WU7C uitZwuVjAMGLT6SUIYAhM9BgQPENO4fpjgKp0GibCz+VQSSiIJFhJlScSB+tI0bkM7EvL1DH4iDG TX4gfR+zoMoiGY+f50ZB2g7WjpSyk6AniY7xiyP0G/HrSPj724+vrxdicfPH3dvbS3F3/fHlVYTE 3799L978e/FWYIcdStmOMAslgDjaYT6fsSPMMmvHi7u3N39cv35HD/739t3rjyYiHhoNDEtBSB4G XxucWKABkZ9BGMkgAHrDAJfp4By9hyAGESbYJFYyi8P4Ob8JA5ZINvsco4f48fvQT2X6XlevWBgd /5M0d91aDEB6lHuesDDvPDRt3W5IvpSNA0V0dy7oyg4pjKfpuwaWLsW6+s7r23ZZ0cw02pWvlvNJ 4lpsh7rH2LdiMZYX7vjE5eGaYvSmlpm2r+R7sXb8hDIeOp5zzYHlJEpynkJdxWYb0yUuLOphRe49 trDOWknT5ejAsHmgyrONuxt21ADoUFeCllAVjg+nLqDlahVafs8h9Epxu3h3Kd4s7vDz4ePiUvx1 d4/fT++u33MA/1kPZd+iTUjDIrr1fdKtL4uTUynzmRt9BU6axjI7nhpkwI5xhhPu8LZu67o9dBzY dvkVnYFmN4ym3P7Mgw7famv22ppAhWekZVm0G2hcihAyRRSi81ZhuEHjISlj40NzICJb1u2Oxi8G UsMZacoDpspOk+mVeWvWhxsKdcvZgOzsOda2HrZtb3HNr3RPDWG91OrVvElbwGnFiKSeBqKmdSBp omnvxTyQ19QOhz118nEMI/94nu0xX8HuqmYq1UMWntRhLRsUW4mhl8Az7JxnWFMgMuQx+1VNmbRv U3Y6OTKZB7rQxPoMwagUPCziCL9QQVsQ3Iy3YxF4IFhlT/p+IpWhpj+dvSqG7IoC4Qcg1kwRc4Lo PdzpB0g9k6dKIukn2OPHMoVux0qK8SNJeEWlCa1kZEmKlVSGsV5JZBq69/heJFOw3HTKV2BpP3VX fAg7Xzn3+IEvPb4nkJ6vV0IZ0D3GZloBx9Lr0woilQG3fhDLOIl4BdbHoaC9cZDxSiYV3Rz6MvbY wgi2RjFWQpmmwWxPJsMwMPcgkn7ky9Bjc3A8Qox9JCPRT4Ht/TTDCtpPOjN5WqEOlCGESECs+JSP JkCn0GKjhA1UHjUnrIRUHhxC9CGP9qCNsIE2zPYelaYy8UPnHpVkMiUL7T0q0Z3MuQe7QwV7okTG ESd5hIa1WUVIYObPVhQCrxzfVYjzZDNCmSq+BxAMPdgTkqXJbGUMswppKMPrIYgg0PdkkpARpMAe X4OAZ37mZFTB1JAChqwHnIpjNNcX639cvLrpYnGzQIvlgYGShz+xa3Hz/sIX/wLRfRWK0XsQyhN3 4vMXT6wuXr1Z+GLTXQD6GBYIAhFHcXsBS6XyUrtC+gIXUNUmMaz2nb0KgFYMqWnv3xdwHO6nVFeJ CJD4TFF5Z3AtoiL9JCAEElIwEq6yOQoBzZCY6WqLaHs1YpbAbYWywr14HCoLc864QG9r38aNXiiz gKveA2SzyK7QVmgXVCcplMCLOVrmGGodnD0d0t905M+jQ8cUQ2kiisEIGMRuKkE6GREKyCLRGDml oTgm8vN9VOQcoDb/yPbRrjmfmasTqmDiIbBv+guGsyuRjLyzz9NjR7u2zoq92+HKY/a0d5+8Rpf/ n/1q25HjuKFfMP8wj04Ad7q6+voYOwmSFyPA7B8IykMylABJtpC/D1ldxUsVZ9Sy4GCNGSwge8+y SRaLdXhYmaHzFVmE3p+4YtrlojhEjK918lPS4SozcJ0Lp+daFkTZ1OGS8xnbKupraVwN/dwtcVEf OgODES5d5TmFq83Ac65mz15MQYrzNhw5r8zAc8VjrGTlDDb8fozRTUmHq8wwHG5XazoLO1czcgk1 UqbmgGNhdZGhC2F2U6IEqg8xgYjaglhfhSsjmcetM6Sx63pN121KKZx1hS9jJG7EiLt++aMZ9zuj 0JiYp9mMe1xBAyG0eW03JEFBPCHBlFKbgeu8VRdYw2VOE2yb/HDJuTUDFhjKE7UMMT8O9F0q3FEu jDTxKVplBsq5fFicYxfundrKoolerWtS3ORoygqUa9FXOUtMY4rBV1zsWyMmfCqk/U4fTXxjf5Po QtmyDDfUXL5IVDT95ieUolkzcH0HpLjNuGqkIiMsDJsEUjhrBsZVds6qs9WhMxbQD5eekzUD11Xs clKLfd+OxsW3swQ3foqWaSCbgeN7IGFHnrYsRjy1XBBUjNum+YXjJ/a0ZuA5Dyg1qQfnAeXtDSnO CEvxJoEUzpqB55xVvafzt30WNuHS4LFm4LnCtW8kiSBlaVYGQdqUSgJpiFozcJzzFOdi8jxWSLOh FBsnyZJSEg3lw3J3jnNedsqHgpSz1H6yurJm4LniveneJkXssOpwTQJJKVozcJ3LUpbL265piPTD ViVpE0jhrBl4znnjI2lkEdkBcUKngrcItv++qTUpJRluPwQ3XF4DZHnklbNFyqNuU6JwvJnuZmPa SlE0TNucRUNtAgrhaGqd3UnVWXBx9sxUbya+2nPOyJpBWmCH9FbYOQ2mNDLwtSf9E3Aczomc8D2E 3UaPlDY4hVImYJwWF7i5UOXRediblmZVPyZk3ZsWJ/JC8lQhOnAKY0324n4/4I4wlhqzyT7fQcUu ozr5xcm4hc3khm25txPnJoj1mrOxZtA4Rt5dlfpRwLCY6rOIa0OnQNYMHNd4sxu9ANlnGSk6so2W msSagUI4qYnmlXVeEFoH/XDJuTUDz1V5XgrJj1Iyb8Kh8x9eTn/623AO55d/nRY62Hru8Qe790zL 7JSsw4xS+gVO2N24rlCPD+nf6fzxzbtTf355Q/98Pn33j3/+Mp5/evvp8/sP//nDy79Pf33BP3w+ n0JABbWumkUq5Hq6UC51CgGpaES2CwFJJy6RsqAo8/n9L28/nDHap5/fvXt7pWDfI32FfiW2GKdt PL/8ZTfNiaAT/KGEF2S8ZUjdsQwzJjOjvEmKd0zvjFQO9UX++7X8nY5Pf6++T3VsS3P58SdE53Wk AixEB6sOOeMKMKdVoE93UQFwIhIaRxWlApQPIohR+9gBqMNSkWcUv2uS0jHSI0DSDyTa+PQ0fgbn 9/2Da+UgHb5AG9Ytej4rAMjpEGcbRQPKYnd6rQGootLZ+OI4kYiFGJTNQsSwphE3pmdC088C1kc6 H1ee1Mq0+w3ZaEv8UgFoMWbtEFGQ0eurAHAiWwDqsNc2j8bCqQGN6aAvkIvCAH6S1GDJpKlSU0e3 SoLl7GqjA/djAZBUuI4WOFLpL99WlXqq44ZEOieZFXp9XzS502Ra8FHN+vfsNX9xrV3sRcJZk5V3 dovzYZvThI59KpIFgOMUA/s7/h1viZoAXS5JjlQA1EGvTha1hcfGOLbRa+yRZLbb4+C7y/ufP7x5 e/77+4+fzn8m8g1dv2KmyMthQ8VaePn8/t31v2VKoKiYyAlG6yYcZOSJOnQkzZY1By4uWOx+mpUK IWQZlaQgVbNQfRRi3WS+rgImuj4+q5jZJd6MjyUtpiMJ+YmRa4PcOohGtB85iUXAPa1FoMlwT38Z 6fhLKsKCh0sFxxbuSbWSxol0dEZY2Q7UXX24gexCFXXZrjQUQnvhqIQoIYHEoCBE6JHEKvlLnmdS qBUQpllJ76Tnk2ON9Mkxf5V7pAU4dCmsg/ARShldJJcCS7zSoGsR1uNyHR6y63pp2RbhpuKGaRFp qgHf8+Yi3DA4RLbVtBnSISk+QkJaMWknDUkFaGS1jZcvSwHYRcOkg5c7N0jqCzlE6R2F5P6SYnCf tsjeuXc0mZhiu43xRpNbBL7Q9q1NaXuLgPs0LKJt5LFYBLznUyHahhu/QkAuSb0xi2gbfmMVAtIP ysYiIF1EbzbpihqB1I096nxlUyFkgwtM4mN58xYhG6yYzblC4A4v8MnLizImGoG73ME3UV6vsrEI fIFfcmcofik2FgGXcSwCX+Cg1qZwkEXgLk+JzdeMw1vsJrfVjn5RB5n5lYlFQOaFYjuLUJ9SzGio zCLahmNVCMhAUzYW0TZ88goBlyQtom2EEi0CLpFaxNrkzqgQcMj2mHB4cuqTUx+JUy9PVn2y6m/D qlm7ph5TYrj2dCsjX2Z79ajkeivpW9XfLgbN8tAuGM4S0i4q7TLTLjxNy7eLk/O87j1K/8FrhC+M kdBtYTN+QjfEySB9Fy21tUjcujmWh0uvsgXWbpsm/eBcBK9bPyaF4ImpXvJVeSiClDaQ4KVVFFLa ic/ALdciXAtu1BYpVcY97s7GdvetHHlzR97uEQ44wCVHOOkQtx3hyANce4SzD3H/lyfIgTl0ZJ4d motH5uuR7efIxC9IYeMaAUMJhQAsAndJQmzKSYUkLAL3iERsSuUNk2hE6TxlYxEQMlZ0YxGlO5WN RUCIXyipQpTGVbRlEWtTiMwiwLNKmRhAqXI5eYXADTrUiLJR5GcRcCnTItpGCNIi4NKqRaxNHkwV AoaMi41FPP3x/+Fm1tNPBn8y+JPBnwz+ZPBvZnDmDEb4tTtbJp4dOYwqMKR/p/PHN++wtnjOgJ03 Ebbz1tBN26JfVFkx0GYNQTOiQvZrnOhIOyFmNwrJeyU28rIXuwq+7wpORnT2aDKyCKgcxblFVGep rC0C3jkMAO7BLKJegjm8RsA5vHfy2uZyCmf6ufz40wNX6vIK+7Z9X499R89u/opunmhqRa1rJpyq SaGwBmdlyKqqiDyWR2X8Kx1Y3AiSx78Sgjb4vW5mU94DpqWL06DvqEK0gpXMLQLeWQyg1I5K3CI6 G7GxiFJEKhuLQHPOq3vy2sZ088NW6tnNr/+OXls3h6ZU4VfVKja1it9cq4tsXjJRSvcKz5fWVDNG eD4jaLONm6lZeQWC5M1L5mgV/W5DF1MeNqXgKlGLgJd6haiyyJitEJDjqdQtovMRG4uoa1I2FoHm pFf37LWNbenHrdWzpX8X1/Rs6a9q6aLphe/LJiBygXdEnjalpWUm4I4xDKueluxHkLwSKj82+t2V sE2U/s8MrwrRy5CEtIgeXjLgLALu8Syi8xEbi6hVxxRFI+AUxTt7bWOXwset1bOlfxfX9Gzpr2np vQ4f37wzYiKzOrcyS4fSpkqC4N+wA9V0KFFkxhU/CsnNLfOrin63uY8kahH1UlVIi4A5THu8PHpn ul5zFgOAe1yLgFsAi4BTEu/ktY1t7Uet1OXZzq//ko608+NW52KmRZkoeRMQluf1TmZM1uIKGbrQ b1qksB9B8lIoM6+KnlpYQB4q09LFaTD7pUXUmqFSsgjZ9N0y6nlqAVDHkBQtorMRG4uohUbZWASa c17dk9c2dvl71Eq9ysa9wb0Pe0lH2vm3rk5oyhN+VX1iU5/4zfW5SDsKR5eWFa4v7ejOqzxV2LfU rLS+ILmJxU8VPbOvl1IqrUrJImCSLClZRI+fVsFIrLXbxs2kbRFwj2YRcA9rEXCO7529trH8+7i1 epXNe4uBH/eajrT0I9fnIopcmLroeBEArP553pRzKCR0WzCzjf0IkjW5zKQq+s7BZR+8m5JFwCRZ nFsE3LQtAukgw7CatC0C7tEssq8kYRuq42sEmpNe3bPXNoaDH7hWr7J5b3DwA1/TkZZ+5PpcTjFS I1H7BZQCM1rFgWYJafWhiwMaxbB0/bqxyVWZ9PjflZDKTerHGFdU/ZvxvXRTauTYDbvzCkGbgNml +cLhKkT76bttsn52BJro+2n7btr31HFJjiIVe1KHHWhyOb/vX1xrF/mgGdvwVl2vFoDkdkjNouIo QFskp9cagCpqOh7fFJtMuFMF5SRiKfHGqFnnsN/u1sUKMV72E/IVbNjcY3KN7ZWtCLk2yB5+IRkw 4+Vue3yLgBvfItBEVy0xjfjoZm2TEb8eCCxLNNdZKiQIva1BJ9QWramrW7OMqRwLEpHznVq7N2YA UNlIUS1ysPBHLlClVwp/+1Cq8EPfLTSekMv6YK4ZFeE07JQxdGvStYLk+Pmra+NnryuCfbogcb52 87qLy5ylAUAFKxYWIIvYTdQ/6HVJBvp3aKJevTwam8vph5fTQnNhPff4s3RIURsmh0b/Y7+KduTW begXzD/4cfMQ17It23pNE6B5KdLMAn3JyyK7RTe1Nmhmb4r+fSlbEg8ljeMAF+lezCDAInNMUiRF HZLu+SpT3dpC4z59fjrcvH04PT8+3T0/fn2q/vL19Fy9eXX75UDjwtQM1WtF7G5I/e3h5v2H70P1 9Wn+r/v+7pbsjb0mS+Ow/J2mxZ6iRA89NpaIxMFd0UWbQZ9B1mXDIe0kgGntfHG2V9TfQv4jAjuN oj7ai3VV9T1JquVpNGax6jhzqRhGKGOT0KJG1DVlJJ7cDrXphiISIyBu7foy4NPQ9vWghxISJ4Cg VALW/u9ObtoyEnoyWV/KIwfCNKJaupLCbxoSp8WmK93lohnpl+7qEKqaJd+UjcV7RiiHvUKtcEuA DDS/jHh2uGlAfDVwAL5gBLDUFKch1maOhIGGnj6DYfcslHCC2B8UdS7DZY6ILRW+AECCy14Atvwy BIIy/DokYvkmQEYiKBNfUIJYvnWQkYjlWiFkHDVWj0dIxvHp0KNMgqwySj5oAdjl9ZpJiCSI3Xzz MXL/ZEBEAHaTFeI9hLcpZBCxm8zhawKYI4hIxBa5RCJ2k10yiUAuArCb/IMySx6AgCRiNziKJfyd AEtJxDKfs0yCWO4CwGUSsUvvaLpB8JREUIZ5SiJ27VHIbNk3JrARYy0wnkRQJmY+QYCDQEYiUsaX QYLYAnXuav1X3rzy5iXw5vHKnFfm/B2Y08+gS0HB+JpaOudRcS7O05GP1/kIno/p+Sifjfv5SpCv DelikS0e2WaSVXe+3uQP6fzjKz9qROJFRUTVRhk0Q1XfaQSaupPUlSOdqYfO4OMrIESxWuPDKiLt qPDRCGRZeVnLPQ78td49nxzqAxBfQjGAWGU5EvMQazNHQoK3l62t57Hnme16rnue/R762KKfLdra Q3s76HMPDe+h8z1tYUdz2dOi9rS6HzfMH68re5p3QALZpogVLz88dInYDS5giRAjcgEidosvQGZN OdCFAGBYE4yCiA1My1wgfsPYCIwjEct8zoyTIDCiAitJRMoEZpKI5R4EMhKBsRrYSyK2yHkSARmg OInYMi8CABKxIiSALIUiiEgZ33USxAq69TIJUhoqfg37xon4ytFXjr5y9JWjrxz9Exx9PDS16saK /rbt8ldXp89PdIdTrRqS1A5bWYhimgy+kTD9k8ykVOA2+OXvRtMu16zc5m0A4vc8TXe9pjA5eR3k c3foovpxRHcSxIKD0XiCQLmA2xKxxUAkYouhSQRKHGQkYgvhl2JPZaj9Ve7f8c9/fRG50lmu9C/J 1fGlFW7+ui79iq7l/HPlTJOOEbNKp+upFTN0nPR4TAozG888S2eHyS9YYcR3dp7ZkrM3CzqIxjGe DqCUi0uSCA6k0fEEscVQJBLHGBg28Tf6wqFJBEYd8EUiNotyLsadyshivsw8XQv5hV/QtZB3F3LY oriPhLJlbg9FyZ0FuD0gQ61VK/IVyp8Rv0lx90xO3yrlKMoNxicbHJWILbouEUgLzD4SsRweNH6J oD8sIxG4JpCRiM0inUuxZzKinC84V9eS/kNc07Wkf6qkwyTPfB/mfx4U4mIYO00oaegJUz2aFjtl tMOIXwXZTnL6VkkXHW26AZtXguAKxK5LBJsXByMRWwovQdAfTAEisN6AjERsISml2FMZUdIXnKtr Sf8hrula0j9V0kseTp+fxDDhWT2WchwdQplyb6JIoTOEE7i/BRuA+MKG3iVP3lwO9zgpEXilfGSC 2BiIDMu3W3rdfSPadoLYYqASsaXQE8QWklGIOZORi+Hl5eh4Ld+XejV7yvf/mRed5UX/krwcRTcI HcNP+tANwvoWe0iYtQExtcERJFphxK983NGSs5eiZTC2DDJFSRXbo0RgiYA2J5F1QeiaHttlgtgY RnRR/EZfOAiJwLICMhKxWZRzMe5URjLsZebpBZbsOZ69zAvaU8iXmpsjlyGwsi9VZvdQiMXe5LtI tM35CiXPiC9ftpOcvjJuwSWfVnBJIlY4GVySCDacfE7hs4Zaq1a4LRFbDE0ithRsgthC+IXYMxnB uhecqxdZvGe494KvaU9JX3J+jusEziwd5nVu+3HK5z7jYwCEvBhH7GnRDiN+AudeBCev3Bu2vU13 JGKFg8GwRGzRZYmsMqNpRWOWiC2GJREnQ8nVosEniM0inYuxpzKCey84Vy+qaM9w7gVfz55SvuT8 HA9vbg9jrc04VQ39G2sn31GhUX8ZydeRmsetLVTW6fPT4ebj19+eH75VH9tXt19IplWNql4r0qpu 3x5u7n+7m0/Pd5//tX7tjPj6/sP3/k/fB/ft3S191oN2psmPWutusd8p8nPZEJra6JYiIO/rcewi Mmcyy0PIg1ItNalO0+2MY91Pg9kRlVr9Jpd+GFObhkTYMGldvW5bOrc38buPd2VPd5yrhI4cNF3d kQI19ZYartPr6BK+PRz+cfj3ga6bQpx0Te5XXUuhqo7ONUNNWSOZv1dsaFR1s7R8Y8jEFIE5BVjC nz2ngE29m1PApse6mvqbu4CBUta1ywW4/1JkTqCt1ESjgG62yoryNFT3D6fnx6e758evTy5npOxq 0eWaLCzpvLu///ZwOlWfbt58euXzui9Vefa99yH7NAd3pluzH0RohBmoFjhrHphTYE/ms6xlt5cc ez6vA1FSO/aVovlroiS5xN68vXu+y0otjvdK14MxLloqMVFq5RuJtEWKjdJIbaqtG62Q2rzMfPgn YE3da6HX0DM0Um+VEXoNhdh2Qq+rlTao52WkniI+QT1liASN1FtlUE+ZkV6rEnp93XSoF2SCnqNq fg2OdBsiKH4wgYaVaethRIIvIUGLbPfu/52wrReqQ9sroYOlqJUjaHt09BSxtjaUidcNgUsdKPcO evm9F98HKrX+/PdBCZbIv7sCHM9/H5u6aU38TndO2cHv7nmL3BCtaxElIzETY0+LkxGItLPkZqRn 1AnbU1srhbfDCFsytVqYExG0s9ieeuIVUS8TtS/ItLNN3CPrJWrlCNqmGmp7tG2oQdGQALYjEi1F JNZ5LhMt5wicH/VcTRpxfnx7EaH776RHqxZaahtaXke0BK8fZMhagkxjaoleTictTfSWOqG3ykg9 Q+OGQj3iu7GT560yQk/R/XRSL7Ciy13Tp4jLZqDlWWilyGp5vfG1doCVqbf2kzC9FgoYAqUcicTt CxxM+wIH277A0RJr5Ui07Z9hkILHr/Hxh+/w+DWSx1l9Tz5nv3vyOv99Jb+z36nPmkGk3dMp5AYQ nwnQ8ogmkzKjieWVqlfSx9NWQkc9RsJprBUQP/uDlrS8nra2r1Kjj3phPwHbrJUjq5ZbT6v/VAel VD1NZE9ThvTyRBIkHyVKXhwPazdwJjenE/9aE8TCMMQyErHZwDRnyLkE/cj9rckoMlOCgD8gIxH0 WdXdurwmiM1O3/QnlylOZVMvfV4R9JknN4mgjHuawmeP2Oz0bX9ymXwiNHU7oUxA2B+cGiWCPoc5 MkVsdno+RcpJ04jyDwj6w9OoRFAmzKcpYrPT8aztCbaR01ai5WTcLqGq7WlVIjbTmrPJ1EZSRBmJ LAQsbchvwuKcTbcko6kliXkmRZyMu0Pha4LYzPKcTcpOhuaFQeQuQZyMricx36WIzSzP2dRNMkNf C4/Fb5tpzNlk7mSmepBxJ4jNtOZsgncDRFe3chpNEJtp4cy+Z9JnGamF8/meqZ7tSK05TFjbA7xE bKrEMyCKGJqIxU0kCMpEpkgQK+Z5L5Mg23sBnyU9xLPifB+RyKQJgmdFmQSxhR2gsEskp/NZsCVE JHajBJGbhJdJEFvYJAobSXI6nhV3jYjEbp0g2/tILhM2lGNps0nOx9PiFhMQnnkSZHPTyWXi7lPY mJLT8ay4HUWEFwaJcCWijETs5r6Uy4QNqrCtJR7m65LYsYI7ArCZTr4YBWYxKJMgNtNipkM7cpma M8RmWk6mrbtGysila84QZnCUkYjNLLtuMdZmHFEmWeDmDOGugzISsZllJ0NXoaQdN72K2BPEZgvj 8r4SzGa2XU+e6kkLGd+lUUYiNtPiWQNl1skCZSRiM618xVznIvwuMpMvpMnSyPMZykjEFldNuQ7K /SfsURKxhSXyeHhze6BBfuzaqqF/7r/UVkmuW1huMrq6tYeb9x++99X9w+n58enu+fHr06vbL7Qc jt00Vq9V3SraEm/fHm7u7u+/PZxO1aebj+2nV07o3f84L6PeBGEgjn+Cfod71CVgoRbK67a4ZA9L Fk32sOzBGDAmBTfFbB9//wNE1k7jFhOwx5W7/u7aOxYCNQa//aoadMttxdO8UApi5DPuu1wUJ5UU rkbDA+MosZ7kytLuGLeepPSsXwbEp5LWMmJCEqmcEq5x3Fx1s2DmlrjcOAZ4d8tNOdxuL2HrvOqw Qaoy5WBTKkwiM0TSSawnuRKth+SXEDnWz2LjnYptRrwx8Ml5idz9sl56JGI05MmgjedvAZzePzKo 1+ndUyjzxgxW4AhOGn1qOILSs2w9SelZPochxvGo4e6/84d39fXp47p1hDbMn16nz40jgT6kjuAa rD4QPziu5bPQUh1Kbf6cO06rx5UJvW0gwwwMurWjCjfVgqtWG0ig0agoMg2nWet3p9N3fu4sK4ob 8QHsGxKSzDQmjbMz4D+w0kpK8UIVnJaR5jHuUMInQ9bo8RCqjQo9Yj2aPklMHuYRrfciRmkmJXHu RKRQD5TitMe+Mzxp3ryVISiZ4Jqgh5zfPQnFr8BUDHku/EXc0L1gVje23WO0GVN9etoOu2BMZkhW WhQig08cEr4302JD2NPKaMPhAFUpOZ9X4nU026xDikJajLMoTEeHqsqt3VRryr+W5bvNaVvQknbb Q53vxii0ZhTU26AdU92oh+O3xSNH8Vl8CzAAQ7GKJA1lbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmoN PDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI1IDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0NvbnRl bnRzIDYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUg ODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgXSANL0ZvbnQgPDwgL0YxIDQxIDAgUiAvRjIgNDUgMCBSIC9GNCAxMyAwIFIgL0Y1IDE0 IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDU4IDAgUiAvR1MyIDE1IDAgUiA+PiANL0NvbG9y U3BhY2UgPDwgL0NzNiAzMiAwIFIgPj4gDT4+IA1lbmRvYmoNNiAwIG9iag08PCAvTGVuZ3RoIDUz NDUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV9ty3LgR/YL5BzyOUiuaAAiA eFR82XJSlp14tvbB6weKQ0mMOaR2yJHKf5lPyukGwOGMpEoeUi5LOgTQfbr7dIP8cyVFK1a5KAsl jDfikv7YN/HJbvW76Fd5lktDGL+xqci8530EsZW2/HWzevNBCik2tyufGZHjH/0uy6yw0gvlshy7 N7vVm7ejFfUo8kxqRz+V4p9GjHW/evPrVynuxtUlfPKBGkw2T6tva/9G5fmFtJlb64vvm7+tCp+p kg6Lzbu4X9H+tXIXm3+t3m9W//gfnWlKQakzVzqhdWbAd7fAhXOCkPGMtCJkS5VQTXtt4RLuFtiU PuAzZE3CC7/WiVMW9eqednvNniWKwLxKzb6Vd8FaKdmaVuG85/PaRGsFIxd5ljbgkle9DKwLtUBG F2FvxFYVgk+yV1sycmpGvNeoIuFugYnzMh/nWJuUL3OKXelP9i9y0IWsOEkPylyFpHg947LIZM7b rSwWSHtOwoylC2HTSUWijlb5b46qoFqkpeBAlse/Y+wBWMXWilA+5rEkWS9Z+6IIrIvcJAwkTcmW gr+INOrJbiLOebEgXqWRR84EOLqcoouLRabSqXKBos0Zu5zzlEu7YHOkWq9uV4XhXcpCFhLkC6Sx nDGGAZKLLrcQYQQ+85bOBghGeY41WLRBdEYUNsvLMgJstOgIm9YwMZJ2C0ImpFkVlrY6pE6TUaWp C2h3zrWCTsiONgRMHpxom1BNxLmV4yrCgN61RPvNACNCurCVsCqz0pW0agoOssSgRD48NBwRky9K Pa+CD4LAyRyyILaG7agikDfIKraqQgfyNJhoRmLUkCE6GhN7knYqhKFiWiKpeFBFDOMGVTXIiON5 W6KjjMy01gnVK4PIUNaIMUFNwSdJcRGRXR5qCUvIVwucLGSRshbtzjk19Ec5r0aGMrOYGad8qQ1M wbOLniBjuxnjtPW8P6iysJo8FdomFFipBIsy00gVHHmM44Tm6gVMwdKqxxFPiSyhMZiVXidUcxIp MXE1EEJiNLR6SpdKYEkXMl1qu4TBI3c0n47YQ1UWkldBgBgeNqYjoHplFfrIz6tIrJJRjgngblO8 NeDoFm7y0IJnmGiU7gSXkISla7xMjozPpDmyMCWEMbMwjpsOBwucTyjRiHh2a2ymlHmGYYtED4xO kUdxGDZKiARqUKyAShJdwuhz48NZF+qt0dGwbHW8vyzzCtLQReIVGt27EIPkwUiDAkhp9sOjmGCY ATQ1OsKW5ezpDQfvLPE2d5YSRbqJqKakljJBVETaEBo6GYgkTla1DvUqHDu1wFTocPnySRrCC6uY Lf5o1kBqPMORxwhQe0/DI8BjzU+k2JE4PVQbpG1JmzSQiggBiqAg6oyESoTNfAMmvXDhrOUue4ZD wrt5/zkGQ+i9S0yAXeEXOO13ORbUczz7w35nnmFcLNrIBQ7zy/ownlE9SMmRWl1CNdlWxi1WjS55 ZqIy0S+h0oS9Lgz6XPvACxORRjDuGriht86Yz2WuaTI4qNvwDPKcfUevUz7hjrHnyQhTAN4HvaAj HCRgZUI1mZJKz6vUNnTQiVMfNFAddSQ9MIbGUYS4CSRCxWWownsdBAInVqqE4ATaLMy8ymOHPGIA R4AZkjMdhjRM0Q045nIf44ZN5+WcBNCjRIclKEbZpE7wkgWrT7GUseot591ZugeBebCgRrhCYcch /jiEgfLjSMZZvK2YeTFkme5poxmRUw9ZMCGkA10eccc43BP0xTDnjob7SSKpniUanGNxdFE5z++M ETvMzJJb0esjwlsPd3TEJF68/eBk6JSCXvklv2NHVJMTH/qAV/EOE+cEuh/I2dBjinq0pLlpk4I6 wvQGRMLQbNnnYeLjVa4MFQwAR3PcxzMuw30MJOn7JiL6UApbCSq6JDwtWsOVMGZmH1Fgn8+Y2HNH auZuc66ZC3GGWFSQAXPXVCjIAG0MO07qlNxl4qkQf/6fPlRpC30D6tziJ7GkL0HtqWzppLT0ZiYu tUe34dxt+LxVzz9vUSH0E8RcSgQpIV584cIA/pHZ51+xbz9/+vTb9ce3VxdQhFtvPn6+FtfvN79/ /uffv/JXLY4UFkq8xF1iMXXwbbu+un6XNolPV9dXv77/9P56Qx+5bz7IQOrlD1yKoFQlhYKWw7UF a9/Wt+3dYV9N7dBnYnPf7C+kA5Xmdkh//SKm42PRjqIS23ac2r6+ZI75kt23NVkSN8301DS9qIee 7cfTW1H1+H+Yhh081nx88xc6dOj7phsz8dvY9nfPj8V1sR2aMZ1a98OEuKquEU9N14ntoRHTQGTF ruoPVRfNXFJqaH8MU/RNs222WXr8YdgfKSVPHLT4+OWxENuGgq2SmRhhtd0meuNIWSE2P/rhqRct rT5Wfd0cA6S476uRCN40MLlvHxHWbTQx7JI7S+4uF4mB5xf8DbeowkNV/2im16q2sHEWyQv2jtTa fuG97g7IFAU00zuLuxdDj/xXPwU8L6IdWDMeTbxmgmI3jJN4GB4OXbV/XQEdVX/X1PdV3447SG3W nZ2GQnzT30lBx1Mfv15d0CvNehN+XX0Rf6w/9tO+uvzaTo24muu6CWTYi7jaLoJcxEPev6SaTEM9 dH9ciG/F9yy4pyzdkKy3zXx+/dh0wwPVEjI6jE1K1l033ECCnHcQavZH/fTNJJ4WLVWJe0oOWUdR Dzcd6PK56hWa3EVPVT9x0ULmxPDY7NkzLCyOzcaYxMUlbHhmgJNcpFDWuhsOW/Tfx35R/YESOU6/ iBfSDMVDTu1dfxL68XBD7h72LR7D29Ow/zGeBE0h40k73R/PYPtjNTUp+EXEzcjxEun0sKrvKdyF FiiOsyiz16nX+/YmaHtZzalqu1TC26HrhifSxEO1r+721cN9FsasiWNWXCp6udA0+cJ0VzTdgy7x 4kFe8b0Irxf5+gs7Oc7o5dhcXA0vinpXPYzHiXTeg2HqnWXidBO0Nd7H4bQcrUKhPS+kzEnxICma Zf9XNx3JMxaQ6/yM3AW4SwQnDe7z9S9ko+pf35YSfYdC09hYTp5xqrqOpv19NVGVIMBl19QTrWEv dHscSOe6pt5YZGPNGZuVRYoOusDd0ewfG07NtrmtDt00+0rkKGBQCo5w8jZk7RY9dT66l2lLPt7h ErpEUPUP3A6QHDfJC9Ul88fTqBBzTncewtvR1EbwNz+Ds/+S3NMAQn8PPSWwfWynn/NYXtZ9O4hx OLkzfvJFSQm/bUNOX1IfbqJT7T0PL5JJbq/E2O4eIKx5zot/i2qu1/jQ1C0mJwbI/mdqxXfXX0O5 9hwSeUy1et0hzLac83iDAYztdKhOrld67XnBRN21Dc3XPw/N/ucZhePxyOXFlLxkNWXi5LVgbOid KM214YB6oxSY2+0Urmpub3rveuU6CBdsTE96/IAAwnw9t70wg8trP2FE7/7De9U1t20r0V/g/4BH ecaiRYqkJL+lqZP0TtO4V+7kzm36QJGQxIQfCkFadn/l/Un37IIASFlO05dOZhzLAhbYxdmz50ji Vuo64vwEnTiYYcVTX+sZ0dOkoU9QzH64guw95S4cwaTBoDtYWZI/XlEjaTal0LL62uXN1IhcjjaS kSwD+0dAAUgxTE9kIQXKm5PuORkbnvvmfZ6aOqh6ywRDN8lADXSYlU6pBBvtCfJ4QVsqnfy9Tj6c w749Tx4vbHRejvgEcqqsxt/Hy2kQIq2sPiqr7SnOKO3/3In1nX81Wi2C2WxusMdNdCVe3woPJsBl F8Ig0eGjje/rTV5IANxcJRlMOkBLCfkIKY+nUTU3llYE0DMklVEU9aQMAw/m26SVJVA3+qIvAUu9 xCjgNtlJaofzQ5gA5xLQgqBjDXZm/T55oFFkIWn3dVWOJj0nTuUDpFq+dTD5hqJiW2OmBCStJ97V Rzko+NgDjcV11iTHDbE8UsU0NijLupSSSQTlVAw48lBjFS3eQm04OJtBbuftRqYJ6OtEyb/Md2ag nZ1YuhPImK6WgYh9b7kKFxp0r7IsJzhwYft8AQEAoiQXAxZBRFymLmVP1CeezzR6jdYvUb6UngpC fwcwVV25IUxtteQbPByG4ecO6CMH8ZdjoxdPwRnlNVkfc6VwO0zhqn5INLK5U8fXNNPfmAF8ULmh WEsjVqHxLT/uAaJDkVRVTxK6tONn5hhO/YIFbRNRVa3suBrrSjvDirzsyV5rewMJ4sj+15KZcJ9o BSRfIrzsxnxj+/WIRf8Ta3q8fjINxwF7OORHz2wRrt/YWyxQ4EEFZxQMVdMkUWR8V/K93QHqOJPM /G3dp8UylAXz9Hmok9sRbWxtrkdCMKiHaEZkuT6D2KnqG/+lq0GntwX6oDsc6qYV33kBnP9h+GCk BykST0Vz/JNsNfefPZk0H0GZsaFk2jXQWVweyD9wsPlkC8yCbcBFg5fmF+7pDn8GrXAcrZlspw32 pjIbzMQaV1a93DsnXPHcaeJIxbI3JQF8jFq5H59nytdnjXcj36dUB94pAQHcObOZ4ALtqMecytt2 4BqRWYGMrA3rVTJpaHjWSuVm+Ew2NMbeJTypkUFpFKlEKtN6OyUySZRZTd+UYBsO07TsHImN0IAk JEo8c2qbT+vsgiK/OH2OiRYL9YFScTO0Fjs9OBOaH0AwzgRsD0a3uvQ9c7d7knJ65QFKAW1Xd0Wm uZu27TA9HTdM5CNgCRlElFqxkNh0eZEZHVV26d4sJblO6CEkQmbTjQDFmkEoD1dClegrs9iVHs8H esuUoXmaojJjUekMkUEFC7hDfegKrU2BmOeRbH04ItwDDRZRSE1edG3KnCKBgoyD+IaehxrudA01 P0ean80sCyGkAt/nUfBLD6Ifpcp3FQW1dH4yDN4MlSTk1Z4EE92tqHd5CtI2eMykE00U1Op7M03w +WQCOdfKfEKe50S7Zr29o4KYzfaUW7K0ECMAx7pPXYlP4NPpXdGpT5cD55pUrnDU6x10f/WFTRZx GHteVkZpSjJnyPz2OGOSNqgZuVTuK9KF3Awsm3j337MBRjp54getpnsDef4uveqokhctAUr50Aeg FNkVbKBX+760w9bWg9qlh1sr0W0/vv/vYMQJScxc5GoPrDsuvU3SPa/Ee6mcFCm99lHLg5MR5cwF y95zA5+9QFUfKYTpPPswWU1KWd2wAKoSk19IjW6zGH8Xa69HF+p3i2Q0tHs5URGhbp6IjV13jh0m IMTqdKDIvleERWdFmGy7A3PUBzdI4SjX2peuAS3xcj9q9JrB/ZA05F75DTIE24A+krKudqq1hcly M9Tsm4Lmf86r7pEmYNvkm67vvtdd45ZYietYfE+Oj5i7Pz5NKuLBbd0hG5Dcv6V7j3dJf4gHq9UX fjYRPH8q8biMe6MGNm33rrQIIexWseQ6fcHFpwixmhARBF7oBTO2od+p901/ESJUW+OFdXTEHagD ip3VUrGKscroedABFdu9m/pRh/9t/ertT04bfKbR/nv0h/vLAzNH4rYegDhyf1QG7kEQHAQMYD9O W9WGE9Oh0THvJdklEhJaRrslEQ1pGr2ctNv6acJHnhsjOvlPl1dDFSxH0qvIHdlvGg1Deiu8b1Pw Ly2pOfwZsEJGeXFC9v2UxvUKNyJbmvnjvMfwoPsk1oWhKNv2aBvbtbhhJcDY7eV0zYodBnPjcDA4 MNW3dXPUDQ268sv10lqUXYeQ1QBZJPczo3ROD9PT7vS4D6RjtMU9nmzJlSmbzK6eX0cr5js3ice9 Kit9GxjWjtUGSzn3MjgyPyCJGnrEYLbkm2hoDxnD0fobwGsjW+JLGD650/kMMc1pOgT0C1Ta5Ac9 O0aNf2W/OcPatpdwTFlqG5CQU3SatT9w8AamxJoETPBC1dQgKE8yYH0qiMksycBRLRSGNjmyJKBW GqiUarOFI7yyeala92HSou0wMc/BpaqJAug9vnayeRqDe1fUGwDb5Ci3OZjFLWFRfCbmaGSZWbqR shJN56A4IcEstkVyLCAs8PhEC0oiQxyJzNq9GsrZCc++lHwLqkQSlYxlr4GeBLYhgjya1dT66gqn pgmxfE4FfkjQSr2v09eyDpGZg254BCUiLPqu7CooypZENaty6mLJoLm9v6Bp6OPpqosg8D0M08US tC7mYeTNYbmWoReLRl5sL36F3FotYoGfYYSf8WKpt0Urb7USi8jHMBb+PPYiMZ1jd6T3feUVAVbE iBUtRRCvaAnkFb7/KKqL69cqFq/XiOnPF/QzCPhnJNavf8Gc/hcU3mfhe6E4ilC8F7//MRPZxfXb dSB26i/OX+PeZuV8FXuhXRlH3vIfueg3j6X7hXHAx/7D9/rmsXSvH+6hlgKtlpZeGC3x7Pi39OYr FDxYzL1FHAdiMZ/BCIVYVl48vwFBhCU7fhzRam+5E69/rsnj/EbAhPK5a6gjL6fzkDUFhPzsJrp9 c3s5DaLZ0gsmrEtfZVlDPoDaDpWYhbGYe7NVHGlHFYdig+64nK78MJ5A1+lPYbjAje1n2gzYfwXw c4FLLcNARKuIkB5Q4vovJdcVlsKP6DP+x6KQcDbtP/6t0s/wXkfhz4bg9Rm83+q5NV+A4s1n1Hfx XEedIxbvnC95J25fXkTgrMA3nwvzfQzwxSv3ff+54ODo4Jm3jCLuaUcC2BYEC28ufNqD0vgLBPU1 GgEKQh8Bgf4PgpW3XC7nIvADbzUL5y+jYODQJnc1s7x6rsgX/mzBipwmyk+392+03hqI+k+Th7g+ wIeyBRyqeG0NP2pruAric86w+UJk/dYy+4FoOANZF/WBviHjpHJrAynK2AXyfMW8b/Jaa7NEKaCS 9qoub4mWzUCeED+T/uKYvLWU6T6pclUqnhJwEW56j5wE3NsRl1U3ZsroNAKdxr5tDzfX18fj8TIK SYXnst16dbO73rdl4eGMhsp7Pd7c14DLN+3X9Cqetg3noRTrY66ULv79pe8DLZNEfRHQJEYviyQv 2WM1Sa4GooBKwfu+YFxCFe2krpOTlJVpY9YC+G7bVWlv2XhCJRBiTyAGqhGFMgXN5KGon1g0QPjh iu2fWhjf9Cu+XaV07+WHh7gvVW8nQ40+7FyuiAhDsHUUP0POm3znwSWxTAhXiOZkgqzS5KC6oeBm mxAadaplrqYvz1DQrxf/F2AADruIIg1lbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDI1IDAgUiANL1Jlc291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBS IA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9S b3RhdGUgMCANPj4gDWVuZG9iag04IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSAN L0ZvbnQgPDwgL0YxIDQxIDAgUiAvRjIgNDUgMCBSIC9GNCAxMyAwIFIgL0Y1IDE0IDAgUiAvRjYg MTYgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNTggMCBSIC9HUzIgMTUgMCBSID4+IA0vQ29s b3JTcGFjZSA8PCAvQ3M2IDMyIDAgUiA+PiANPj4gDWVuZG9iag05IDAgb2JqDTw8IC9MZW5ndGgg OTkwNzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImMV9ty1EgS/QL9Qz22N2xR 98ujBzMTng0Mu4ggYhkehKzGmlFL0FLbw99PZlaVpMY8bBBBO7MqbydPZZW+FYJ1rODMa8lMMOwK /zi2SXMoPrCh4CUXBmX4hU26DIH2oQhbccsvVfHiV8EEq/ZFKA3j8A9/jVSlt0Ez6UoO26tD8eLl ZFkzMV4K5fB/Kel/w6ZmKF789k6wL1NxBUHJoIFUqqfi4y68kJxfCFu6nbr4VP1eXBlZCssVhKpu koFEg530F9Wfxauq+M//GU0hCEaEUsImpUr4E2rfKLRzjEQeSFSSRAG/SWxoOw8uK/qtwviQFIDk mSxXxTYB69gP+TTFAxkoTykIsEspekpCQqTk0pJLJZMPTT6UyS41iS7nrERU+LiubCxBy61owCpt jwordVwXFN36KAq3iLjdl8HprOi3Csz/DKJnCmUyiIL/oJAqnJtsQOkTTsKixnOZYFJeZAWKxpCF FXorqpBRSQqsZ7GWyPzsm4RUI3YpLfrSUWDhN0IGI0pWSraYrRmtCTdnJQStqQRfemOyAkXLPblL cZOoAL0YLSl4XPYGc/RGbCpAKZarsdx12WVTvxWz60XheERPW7smts27KfaF9gJYDyPAlkEIKEW7 UFq1KLTzwEacEBYYm6VQBov2SYbcOMdVCCYiQQ1Dz0b5JMFeD7uUXVYl0ZbIrkkMkQNS27TbG4Wu 8Zj1pNCGYgG/0HkA1oJkeIylvc0imvM4DtI6ZGZwO6RkVwlmjXBURlRIaITztB6Aa1C0D9E5gpvE hjALSq3rkBn8gjUH8lApnJxJnSoJcchKrVIlxpF7DpMLvaGbDPh5Q2KPfGkAFchX0uzLCghhAnpw pZOB8jEowhj2KouYgYHuiXUdLwmyRnZmEb3TqFwUkBcMcLT2dgN19L6B2pXB+HU9JStKayX7IXc8 PNoDRXHsgQocHVYFeLAhmkQKa6sooPc2iyk/ty4D0wE+hYSQq7j0NimweFoHY0hERqfo3EJXkthE aBGrvB5TA6xwtP6QOjUnIHdEvkMPiwIS4g4n3kYRkH0gKhe5CnNIhwRQFCGDAGdNhXUd8HYiUzdL cKHKuDsqUniMBs1W5rkC8/HuXOEdwA2itn6Np8uzbHAkbrKBYynpIAGSq7imExWb6MADZ54rFB5n nRTKrvwJHA5XpBuSFUST2OeJnVkBk8KEZC85XWxKGUqJ+3RpWhJdZI/SOUMXR0VwsSBn6frQSHYQ bZwrXObdIg+4nuDglGuAalDyiYrOEnTIrSTG5ki7LgPXRCxUqyhaQpYrlXYHSbGtwnVHF+BiDcNJ r74NB8y1yAoUHZ1KD8+nLOHg0mmzU9smnJG2Bx4brksv4kmweKVxREwn2XBwHGmmtFlFuCe5ogBR gZyirhoObBfqJ4rYiH41eaYwpQTU+iUlUDgdtorVxJYiyJ8o1rCaEHmmgDtMGbFVxHGIIg1/DwyH u58bel8mESuFbLjbrgfvaRRD03J8FL2h7UkBSKtYA9g7Gu9wr6Ek8S5IKG97gNPFCDgNnMZZSG0B yPE9FRXoD95kdCAt+YMrWEdS0aMPPw9EFhvyZyJP8nqgJjn2Q6j4zEE6ocYYQc+cKMOdLPBZBB11 8QGK3x4Yy8osNpQqD2ZZ5w6/STAy3BZZgjHNI0NJxiltsQkeLsGQYQHPUosFFgzMF8wEjjGbqYwp mkCOZKQ+KLSgjjir6EUq4ojydGujKPBsxAlPAK0DvyF8zbKa0MeHglFRxNjwZAo2BXPGZUUfFfE6 4vSSzIDi9XEOb2y3hb+pMqcIcE0P0qQwAoYxPKmgOHx/LGKgLDB8VCDZA0YD6zh+6APGxidTFHG3 oyf1sg7Yp3mDIwRepVLE4ylVerRybjPTerK3cKMge1S0V4aY6IUlkYssNVSaEHZdNnH6IfpuFfFT kHZHWQbiARlzapIxaylJTKUYva7DgyieaBUr4YZa6nz+KsDSAEahRarEYR/BrTNkLqxaUd82Bdv0 rRD4TcqZx+8waO8V/nFsk+ZQfGBDgSfPoIwwGLwaAu1DEbbmLfjFqwBWTrnidy9ybTEUFogMARQ8 PNBsX/xSFS9+lUywal8gNTn8w1+l4VDA+fX4KSPgTV0dIE38h06vkIDgr2ogyeqp+Lh7+eb16/d3 ty+vL+C563bV7Zs7dveq+vDmv/9+d/Gp+h32XcHNauFNWN0Uu+u7m7zMXl/fXf/26vWru+qi+hOy ETEb7J2DQoSU9L/JkU2A+x1LCBJOBXr7dmqHpr1kTy1r//7aHjsU79kwMhD24/FQg4zOz5P4PM5z 3w5t89fExiNrH9uBjY/tsR/r+6nE/dW/oLTqoWW3764vADu/q+LP9Vt2vMA+78bT3B5ZN2Gobrzv mrrvv7PpBOIVFU4+HrsJEppH1jxAONbNE5vmej5Nl+w0dcMXWBr7ie2z08NqOkP4N18htXfjKS03 LbsfD3U3XEKg5oHVE5vnmX20n1YzKDun2Nb91dwdWjYf631U7buGHcahm8cjRq+He3ZXL/nuvnTj xD66Twy9xEQh0vGx7foesSwZggJFXiWUIiEkESJRA1nxdTzO5OP27aNl3cCa8XBoKS27a7q6Z0M7 P43Hv3Lk58SC3tVf2kM7zGwa9/NTnYtCzKcZEkK/CGg3bADfQ5rfL+Ax53YxWcpg46wbiBgbk7kb AVDMds3SxSwB4Ke2p19cx3asdmd9Oc/xEpM8jNMMlADwhwkBae9XW6Qbm2N6OoNBCWcXEG9xhkzp 203K0BpgE5WWbCe2AvTt1M3AlG7t+amfgWmrfcQDVPf1AtbNiSiBSfX1BO1rnxZeAGXmB+AslsTG PW1KgRO2mRA7AhlZzeBY3Y/HiT3Ujy2SCRHAo4BpXy2nrB3qz32LHrtjOg3Iyvrr1x7OFPZmKtmH VNqS0FPsf9Of7sl2apMtcALaEqFph8cuB+JIrd2RhkGpBDxuOM6CDe9240C546F6aL+zzy3QoWX1 Y931mGLJ0PgqWW/mSZwUAAbbd7kHTzANoJCZkPqcW3nfAhwRvrUXN6//lyHdNnTTT3Q9tXAKj9Nq djwNA/YLOfnLu5tLQO0n4+KxPnYb3tQDtQ/2s/dD93eZrZGuOdwwPg1bqgIeNXvovjzgeGub05LW CKMOGgQ5TN+nuT1gChs72Lm4xHPQwUHGYzBFTFpg0rN8N+f4DMp1lvyB3J/b/Ql0XQ8jGOPjavXy 7YUw8E7aXa5e3t+8JTbdvnz99nwK/nFRstthXo7bhORc5ub9GdTTw3jq19U9Ht2R5fmM8D21/zBe bbuRIzf0C/wPevQAY0W3qlI9DpxJdh92M4kX2AC7+9Dulm1lurobLbU9/YXJZ+WwLiqWJA8WWOxY bBbJYpGHh48D9dxv7YTEFoh3x+2FisrWcYb/6FCSt9gIyKCNlVRmt98eD0/98+VszeQxsPs0xa6T Py5hbGYOHXt52mxdXdCc18QfiSMp7Qp6nF75zIHlctq5wF23nsLU2l229KzHlYFPj5Zn9zT9Tsf+ MH6k/kKpdt825rR3QIkx9ae79Dd6nWu26/b9q3t8h3ab3evGDv8YlLvfSsPeUriofdziPKHUvv/a Zff9sD3aMg6v8nM3PmxDAlCt4c+tK+rN4XC8WL82JdPj0xP0o8dCGph2IoZp6NI3dCtT1PZNP179 PaRPrnv0v/xNeI6U3WFBwX3mGPbQjZeTLaN/uCoDfBIM3e97iuWh33Up2UqB7McDuguj3pXr0xr9 wQ+/frirmtseeXsbsn9/ifX41o8v2QOQqgf0fKERVbppfd4AP0Z0xDQiJ6C4xXCDNtCBKuEygt+M nkxttmP/uqHGJMNhwCyA0g5DN+wp7fz1/tufbMbtrf4XGnAWP526S2bjDtVw6Cb/DrE2+wgPmA4X oM9dP9GB21k0jEUSRwxFue0GUAq0QEAGXA5RoSESFkO4dIcT+vaA9g3oYtEBJBdHLmP2eAWFTHDq 7QUj6LIHLu5dQc6ZU/gDLRP+pBiGnNOwsrWV9KstlJK2uLUudFP9ZWPZdjDm4B11czmAn9JdEY7r Qm8oqbYE1jDxN0QaJyaMqfMMkn7e7HluqLNOOPDY76lLHpF1ast5UUzpd0zJMor4Cs/njcER9MVL t3ntaTjRKOA0choMrvgWXI1V3aIE2PKR7CV491DEuC+u60wfSHfvwt/YrOUcF7Bz2oz/BO4FuHyC PkjKfv+REk1cx1ZBBj4Q2lW6dlW3nz7AQnnLOvQYwMf2AH6LXfDlHpj4A9Lh8H261eNmwNJgo8OD YWuyrzV0I8aBY0qW24WbbYavZOHtxZGfa7ZFce+O7qr9mIN4IDnjJQ6+A1rMDS+J4TVGCswmjyP8 oKQJMcymIAMbovsdTxa67OChpPkE/ecy2CBXB95jKI23wRXSneOlu9B8w1QGyyFHuOk6tqUayD5/ O+0n9n4O/PrB4hw9GExGeP/Wd6yF443pla/dmARjs+OvQ/3HAONop7qFzdBWzkGg1uT0MTjFLc/J YfJ2GazuLLwrnhIN5goTKWa0yKalZ82XpCEMWIZB8paFDHc79sK/vExT9q/d8/Q31lH9B3GGUwfT osEQuhuPd/YrZi3WxMd5Zf/U7fpN9mW/uSIWWqoi0GMr6o39GRMqYLvBHS2TzR4efuAHUm5S6Iah outRoOmRYNqmiub+0SbAb6DbF8wU19rTHL/zlt6Z5n/3+PfjMFy64XuD+9McPGfIP5y6bQ/aiyFL psCf+Da5PfeP9BiPWEsBKxh9E/KS+oTv+02yxOKGL9M8Z85ovh0f7cayA8u2kx0oYkfd1LGW5mLC Ohy20Go2XzsiYuO4t1VObYxHmlZL4gXD6NCl3w9jyCyd6r6N3WEAJ6SDE7TAAIjFBOCHDjTkkVpw R0QPBPIahwKqii0vx71rNpqVr5u9J3I2zE//CptGnv3sx008OCUEOTj73tudiaxS1of+GcuVXVj2 3fNme40nre2da0WaGlu3PIaesmQAePAlxosgk8eYnulKOGjL2ycM6EO7rFszzfQGv99aKHYAbAES UxIg+/uHEIhnrnFJwWPl2Sc88XXqXRBgYhuc5gCsDL26Xwns0dPFXYhnCGP3GE8ZPMrleBkyc9yh Dgd2eJzGCXXXyQ5ATNDt1w6Eg5U9Ofg8vrCX5MnDfDu+da8Bkz+6qF/shnvAc4xUP30kg7cnKlCa 1XGi+wau3iXilsbf3h8P2/1lcFPq3cblzU78NbIFP29she86zJOrXSZAOMOcxQ5FpXE690MXWcnL 8c111Hjc4Y16+3Sff7kh72U2bA83VZvLTLVFLtpMVHUOUlZpzMLs3N083fwT4KZ0lRW5LiT+39bu VFljPGudyQIQLMrMQIKNoGwyWdKGVWb7m7Kp80qRRILtSSuRuZI4BT+ybqxE57JoMwl7qhQkEWVe C5HJpsgldLkEulXNT4k2F0pxy1LmkFpJlTfIpVRVrnXJddoyL1Rip6Xh33Bfus3LgntXhcoLyU8h 3hx3ZJYV7lVVDfOucK+itXevZa4bkihkw8bjc6igWxSSSwTyLa1OpXMtKkh0XjSVlTR5gxdRUhBh IQnquWoRodS5aqz3EncuVaYUclhanUIgv1Bp85a+8cK1wrvLOm/IjxYIAVcSMq8KupLGzMQLqQa2 G80FIdgW721vKHPRWAEujwJQdYF/yYaCM/yiqgpHKXYF6ygEVTYoDPoWzmYh87LVUSA1vNYinpBt iytSoAp3rPCoiL8S0Wl8Ze9UIj2qbZgJXK2tmY8GxE+wbxBApblP3KNtmE9cQ7F7Sjy/EHQtBCep zgudN7WKuQrNMQkE0txqq4GCQVGJlorCllBR5iWKW6ATpSu8os1rCJTKS9cZ/lUFBWgDK0tt+5J0 dGurvsJvtYaZClXragrXwHUEaly4+vVVJlDjwlXHrJv3N09EcBAJPoAMuG3a9IAJtJ2ZjMeDocwZ DCyBoW5t2DFhc8s2gLmaWTMeupxhzBJ1kP2mZQ8WdSbJIiQKYHbQrLqjJwVgoC1FkUARAzlkAO3M JfOQrLtUzTDj8SCq1lYr5ox78RUELfIGGw2TLAIgdzM1w4wvTDEwrtAdOpHM3XHjHrPxU6OyOyQZ MGsnSzTkNMziDLutwDwv3kH+cIpJUstpQF7NrBr36WZDZDFWFu7sy6VqZtVUCWagknkUJlSN1xHv zCxfqUxnHpINIKi5g2bVuA+JjT9fFkyS2knr0quZVVM+mRoUpkrqks1Wn7ooWQTAX8qrsZdammJj 2j86k8zdWeOpmlk15SRs4i85wMKdNZ6qmTVT/i6cPCzoRDgFlCkcQC8CYIkKambVuHspzkyWXCVI mrzQLXsXJlmExMo+qJlVd67sIytYoUa+6rhkHhIr8qBm1oxjQhRSMVayxruCBKRCN6sB2PGTqplV 427+KQRS1nUiWZA6JpkHYN35g577McQUHjEJ89ElQcMsztD8B/2RCV1cEsgo0aVc15m5chHODpro DU3gZgENmFJzcrqkq5XIa0ncE9ms5yTXRWS9pWrmu8zX09o1KozYhOZUeOGfvM3UzJptT6q/R7MX 3qztVM2smQr8HEROSy4I3olh1XIlnMRVqmXW7KJV6FZ44JoERAIx/ZQEJ2/rNU+wO1My0UzcH1qC h7g/LBaKuR8ymyqZ983ENaRGidZcMHdEdlMls2ImCELfLtabhSOymyqZpRm/Cqha4F8rmG9JC0ew O1MyK2b8boVOqWudrSxbRPgtpkyCuWdylCqZpV2367CVbbHDoZIIGSaEXziGn5mSWZrFHCNMnG+C 0/fcCxlNdMy7NlDytUWR5XoJTblcNycL5CRRMSs2/HYYV1R7Yv4dD0xGg4pZseGuwtZcv5RGwcxL zEfQMUsr2CWFJo0iL3V8XYl/6krE12WCuV/ykyqZpdkWUxrLSGSNviaiYOEoFmNgqGZpxocLyNAl t4IBoNomlkkUzGzyYgxKZmnW5w0QYpEpJGH6nnthyXc65l0bxKSU5AJQNFY20+fMZ6wap2GWBnwR 1biNZhbn30E/WvQaZsWEvwXxiobXYRTMnLBUeB2zYsUlHN3vUuGfcfqeO2FF53SmN5sW2FArYLpC VBEQVwQNMFSvuKUSTHXMilkN9ISg0HlTq4jwK4IWpSfWHJOjVMks7fpRImn6ijIOihVBjXJc9RxH VDhlVuw6gaBZq1W0ywRu9JGgqOpUkByJRuPQDafMiiOVS+xMgiaTBWgNlg92K1riw3WkEUwwD8Wx Bq5koplgtyxKIIiCpMTWUv+f8WrZseS2oV9w/+Eu7UVuSio9qrZGHMCLAFn0KtuBvTCgWXgM5/dz SL1IiX0zGKC6m0OdQz1IHjYLxCksUEt1yusWellcUjdyFlTaq5jYOH9yQZm4LmlAevF7dhjbAhSr tKzsTKbWFQO5iT6yOBeVhVRtttiFBO1exUSC+oYiiZQnySvL4PeYBzCPveNn7a7digXuEd9JrwES MlzKgiIe62BC609lWQNgOu1WhsaX4HXGiPfREq4PT5FSMdXZrU5qwrIFwJOadismePO50fBupywQ wnVYaEOWtKwBMJ12KyZU3ctMyL5qt8xVAP/p4/H3f/qne3789jieGF5uGjnxPZ50ZfHEBJAS+rx3 /vlRHvgN+6O/PX/j89uXr1j58YU+/3388MvXP3/94+uvfz5/+fdf4ceP3x8/f2BRxuyBxMNkhDiB RIscxK2DjIgx8MyIfQVUThS0mBzvBjFT+8T8GTN2HPm9UTujajWfRKDaQIdPq6ul4VDB4UzuOIkS MTuBkzCxtQtqOChRaF88lJ0XP9qEn0d9RS3mFLCbOvEOC/Ser5YAjYNO7l7qnSF+9JZTPPQU8ysf 1YKehBKeIu4my0lyCAI8Qxwj/kYD5nAdMgEXm8KNqno2y5FR6gMCuLyyjHDRPI6LejMeA6d0m8tm Z21VOiGxj1jLGc96CSXrjFmAzPNtIKKyt1IvCh6DxJQwMHJsEMhIT1w/1cZLRNsfhLBgj2fuUy83 BFzxXZ8+tdmEy4YkiaqOnZkJ5uli4H3Vy/dU0JRLTylMcv7O8xojXgXBkyG9DlS4GKl0B3H3M2Bk FLQxhCdy48InxrO99b52vPWxNr7CzQeCiTBgYIsJ0cpXPLNhQanlYXErBhC2nW6VRHtarWQMrd3K OyiRj3uGrnQMrt2KCbWnNokJXCUpELseMLbyKiZQOyRRI/aqsZDJ425exUSqpySrzV5/VjZx4N2t vIMShWsvZSudOPDuVkyorQa2M5CWlU6ceHcrFtQop2iqPJJYBRZ66JKGjZ9bovIqJnStwmNQ6Qaj ck/LQs5UNee6V3kHNFtAX7Rb+iqFXd2KCUUKJsl2sraXlYuRpVMRKBAotbw1ySK60t6nhOWOFjlT aadiNrwqx2YzMzpgt4wOuLGz1NNuRVgGdu+lb7rrxsbY2q1YUHtbzi9/vWdjAa7dypsGf0K+J7Pj V6ktDKvDGouQ/s2rjIZpKAkkdvw/0mJalmCYSnuV0a7fipTjfvkjmLKlr+LhSLuVT/QOBz6z3lBA K52KfGT5DrVJpz4KJsquZAuuNkNKt/JOheHtpHeqbBh2clAtXuU71N2NBoOeLAwrE+FqpyJh7lMO tOnwr3rRq2qkSSgnaViZiUg7FQt3FZ/9JIQcXanELYjG/bmMTa/7va4dhp18XkP3Kt+hj9thCMPK NK+hO5UJQ2NqnKc+ZXY7CmhSDHO3RTRPvTsVS62TSs9SrW/6faPiU9deRSBBPpyy/hi6f1o2NpG1 QlWbUGyZI0QrAHKoWOlEveluxYIyppHuMywbXYtcuhUTis6Rhh/07FY7t1FnZWNs5VVMoG1EguWg cWeMSCsXIyun8nbU+nz4WqlE653IBk6f2S5+P+YUt3IxtPYqbEHrlEjG9IfKnE95Zhsbix/tVr5v kGyjn7CsbIyt3cobJDGSfjqkjlVCeXa3YkJVtplK2/i5swEbqg0qgr4XfdFiv335+vDZvxyV8fC6 It0wxjDcERXOu40R/kI9pmkL/0EH52+kJU1INAFUQ0IKkQXl1FULdD/pZdSrwJdyHpCaPk+U0+FC kpcGqKOcBcqJVuehZxMagmPddPqAyw4jXLJcuNcsLbg0R5NZfGXe+4lOfCPP0oHKFiJbcOYkyBCD u6pPYvIE6XYd2ge11ieJg0TxqfqgkZHY8u51cD3GFiGOT7ZcV5IhCwtECFpHgu8Z2IJK4GLiYepO vHVU4zuQEsFVcTs40dCuk5Cvl/fyjAeMvz1u9xYwUJ2vlJ2A8RnXSpsYMDlggKM9BPRCXtSexAjY J9Qa55QFD4y30DfuE+6ID7BPnz65F0lMqnLRS0M/Yp/86yQVhHKJ58AWBEPqjppRdo3pkrfpM5zV E1iecH3seOKYhvCNLnz20PGsSXAKaJSQWzxaIxcMrtWrGEBIodsHoUa2pOp/j6TauIlKe5VpGLg9 OT9N1pWIYLUTwd4vl7KE6Sk+TsJIeow5Iatgus8WnmLX64rJ1gtKl47dIn1WfgbHOOfl3bwpTX3d tMwSp2AYevUqFtJe5dBSTnkCOxlhL27lXb3sMRkVFNl4pVsFtPIzm3Yr312MHZWFPgLsbIStvcrb qj5KtlHnEW9UdX6lb2QS6UQKnc+/OaiP/Pzj18dvol8gI1k+TstsGK2sk7i9L7unNMPehypuDUcv Kyby3pyA6WQN3NgZWnuVd0hjknvX+KZl5Wc67VYE+FzYwWcP3bvqSqfAq1sRUH2OnXSzHe8NulvQ ERXZ+ncPh8nlomISoWJCocm+vyuBZkFvdzxkrcEwlXYqJjTKUghSUuwiQ1iapNjomU67FQE+ohR6 ZVUw0OzJZJOJVr2gOwDHeXb1PGv5OsmFEOpUXQhh5uVhxpBG8CYdJAwauIWjvIoFjcEJvY/F0XEH W3V1y1RdKz1XS+1VLOyu3wxFh1Ny0WTjpqLdignVpeA4lFUcnuhud7ICGvRMprzKO5GJJnX1Tozb mwdr6dDmMsNbommNWS4rFjLqFvJ0rjMUbrdMhbvFw2zarSioBt7FsiGf+6HtdKzKtMom/YT6HqKC Ol6eNfTQ3ZsQ74YtIEW2uBULGpnGGzlf6QxPW+SvbIyt3YoJ1WTzlP5zXtgMbVzY6JmseXEFKQZM Qks9s7Lsg0j3adVKo1Yi7VMUTAfu80wvjNaEg3QNei6aPp+Ew/R6XRkzjSBrY48YnvZxqg9LvVXs ATGbdismePfZRrNpWNkYW3kVE6hbeuM2pj4MZVT2hEu3TJ8lHmbX6yT9XNePbU6U+4xZsY8bP7IZ kNhr8yomdDt/Mazu42u3dME3cIRlCYjp9boi2Lq88wkaPZ1ygG0Pazd0mbrHw2TKaz7QGWLGppVC n5audzcuznHtVUykmrHC0CrMhN7IgP3TxwNXcRy4sQP/6Hf3pPrsPfUaGpdCPp8f5UFplp/4ojrS Nz6/ffn6+OEf//rPjx+/P34GzpP+kTFArTm0SYwNuCU694Dsyqh8GXd6JFJyAY3F3WQ5MYuSAZKR xOw0hIOnpkyjnUtsQVxJoYSLD3cuioGf3zTgXRxBoeCIqX5mRy82s+XiZtnjhSU7bjnZ0cMPbEHV vcgClcKLcn75gzZJN+bYgp6JFMiuVkZh8XQ7vlkOiJxMAowfYMgJPQSb8tRLbrac3CgzGubBJSlk uiMPi+8B9pCF5eQClk+kjWf2eLH4zgFjwsnHFR2aHI4rkCaoR4qEwAbzeb9cuuQhTxz8dkDMChzE erkkcdDaAu1r4uAUHO8ivPLN++rPYsaMA096F3hxx0k41I6ZC6nqbvigMePq2IKhgq7U17YqLeOc 8UTwS3bUShgYhcHT8ThqN7lR3fwOxq3jbqNXt768ZM4ZPBsUc+TA9aQXdLY3D8GVw1iLNw9uHyS8 SIL7TIulpwVUSkLg2JG76qlpYA5hdSsmOJ5aQuyoJd7bOTcMHqU22S5rQEzfvSp0glasg0uug8tM 5gqM+DBcUcUX0eCppBDkVo2M75a5SiPXeJaFxQSfxaMdUMDNnJey7AVm+nTLGiQH0BeO+zDAb+5n Yi9b9RqGcR8LcGPTbkVYBnaM3M6lZS2Nw2WyrfzEtrgVgTSwR5Udx23UXeSbN0OUbNqrmNB7AUe2 U9i49Ou0uBhZOZW3jaAX+b0zQPY6XSNWcubq60Y12KBHi3nTdBaYir24FROqd6uqd8z+FVFP/Vt+ ZtNuxcRuLUy0Qqs5cuOb9XcLgOm0WzHBew8lQRM/6bzoUOfSijU/symv8gl0tcwWXhdthsElkJtT MXHaGQkpsIuDLiASJMFlsbdDk17FRGqnPdto55+tdkQ0pcjKz3R6obgjAd41zATvFr8+UmFZQ2I6 vbCY4F0g7ZIJOjj6ZrmokQrLGhLT6YVFLBzgLeWFYZdj3SL5dURcKFo5mZvbseHvTinIdqmHiSST AaR3kGVKbU17FQGEShiYLGaWNBldzsf7ExXZLUP9rfTcNrRX+R/71bYjR1JEv2D+oR4XJKfzfnk0 hkUggVbqkfZhxQMYD2I1bSTGeH+fyEtkRFZVt7s8Pe4Zb8uS7Tlz6kRmxp0hpI3z6NqEGqNatVbE R1oWh1+nYUjto21/FERWDoDmSnsdafuC5JWJS7X2Ti/X5+YlcvgAxRxKdbcspeB/OVDp4MuZvCM0 24/C1dqMtmdIF+/j/drA39yyMFfmwpGWxaXIMyhTsjB9DKG6XB0QWTkR99OMtmfiyy0Ell7tB4T2 kjqoE7Cwn62NrP2qNC44PXdXVp42zjNkZr4Yw8Wo1go4D7zVq9yffZuwZ4w9Q8j6YpmCUSc/I6OM Ms36wNof3cqgXiQ9ILSn1R2MgLn1bGsk7WlRY8qNQuueEy6YAZmZKsojq64nryCAoLXVN+yM3qVR 58ge2VZNhowqzfhI25+0keIT0mS1sFa0R9r+6HKL497KttucSuPmwn4JhpG2X9OG2UIOoyT8yo1T cucoYY0aOITMT1Tsjx/u2YdkrqUZnQiBw/ZB+3e3N6+/95Oabu9ugoCxJ0wS/sB/YUGy4E8dXCqD XfCQ6bf7GwhgAyTorbr87aaHdx9uXuXODirvbr770w+f/HT7/uHj/d//8Zvbn2/+cAvfOO8yO06y NNf8iYYtLOqcLgZWFDtpWII8iEKOS4j6Ep/EqZFVx5BXMItFWEULRUVXhgqffHEZxEnMKpVaKOWS ul4S/JujP18yu3oyHuZcyMfJQzn3Bt7+4B1lud73P04arwW/9E7lOylbKArGgGThMDB86ADqEsqW GQ6jEvjOgz0YjyBx8EqwCdoFBdyb10Ofr5sGFQPtMEA/RgoMLRrmoMWt3fqtNbwgVGxd2glsoenw rb+D8HiTL/wqe1HCZXJvgMibbn+fXwOC55iXlc1vZCenFYy6OVUV+DT3dEQgDm9ev33w09vdtJDY vf0rPPOf4dw/Q/mKevplstNfpp/gunHSEKXT3+T0z5vXf9zp6V8PJ1nbEUvmvhM4qyH5TD8V5VO4 pGiTgzVAMRYiWXGMl3y1U77bHY1fZfMKAZ3e5eULHuWwI0ti/ufT+/9On+z08X8fPry/f8iuA4oE Acg7b60qbs3U/Kvb35b/2+ZhaCHwJ4vZGEWItmSNCq7sCHVzgSItpK0LAAxvUCWRc884sC3JUvBm OqUorZ9/bqCatDpwkyCndOImO+LLHpeRIJJSHOnKQbSAPMlYR9pn1sOu6QZlQKCorCL9wgtsz5T4 01Vj/ekYIqOZPa/sJxrt37H7d2unvNop1hbuveMhE1J+Jogx2O7KqBElFCE9XDIHc1hDYJLXZTId VY7GSyxnZwbh2yxLH+cjSDtGECLo1GaQfiZZ5Wu0LA9Q6lZZrH6ZlISKNdwtmdTuj6YyUm/rUxii DpFuvgHsViuU+mZ5FjCzi2ek3krCgjU+DiL1XjvuPMxl5r1cqMzwmC77yMO66kKZQaDFaRitPXSn IA0vCdx9PUjzbmh90w6+A/koB3w8mtwXoBigQzDE1FWK1KUJDahXWUPyDWrefImt3OXhxfMTwG9n j7JE6jPdLbD9oISPudRuZYMuwt52ifSrARbYdfcDUr/7XDRYAYvdEA2+xBE7Lz4gAYsQWouPA66f 3WM/3L7eLMsF7WYGEKlRzk0iMn+zu8LyaigmDFkqtbzDSMO02z0yYrsp9nJLpL1cETJpbgyRKv3Y E23Moc+n+uZYDLLO/zBBJxdappTcsb40sXwUJUKyA9IO5zwWzVHmaORBNc2tsH67L4CBw5MYA7xS PFfhDgmBesgFgGe8GzBZ00zDemsQqO6DtckndhoAYgzsNAxop+kyaLw/0ALgp6F7B61mpjJSb67N 7G0QqMZ3s6UTNsy2c8L0aqE4uLylep1bIOyBMM/y5XL35vbND9Pb+3+///AxT6UHB+O84khn8uOp 7AxVJmNc4WhnSTHvGgkGcvAwvGNZTXUoce61LXG/Z0gonr2/yfpQ41aRJJIPBXHl0h72wGgV5ywR 9hXaWiBGQ2ePBYHIKIPdEoH1zGuOMB2IS23XENKBk6kUVxGICeUGxJWhkCNQfkzlKCGDWkX6CQFJ OU+WCJxLQvxlBGJMpTWEKSNCZzYwFJlVhG6BCOmAv30YzoMI6cCd7QpAb4qM7uI8D6t1hEy3jwhY UhChG8CcXGbKJUKmEDlFmfyJXy0R+griK6Q1hL1F+2oF8a0t0FfQnKIakJp/GYHa48wqQsqEtEix UDl0WEV61nYEbOoGpOWPJ2jSm9dv5j/TSaEkhWBXkf4q7Zv5z/3+/RxLBPJM8bPPflZQkr3jVlcQ WCpCYt/Mf9awsyhuFRDp4oAo8LTl/mRIiwL6iiFNGaNyBTEiSp42S6CfF7NcQZ3VfkAgBnj16D+3 GqRg2klqQPo7Yb2jt2VIjH6otktE56GHl+gFAGc0dugG6GcYTHLTcLk9t5TZD0idCL99jm8D4jYO jAXGPwmnlpStHAh7HZ+EUyrYRkosU/D5KbVYbufE4J6IkwvvOqcNbcCJUJoqJ0jbkcoJepDpQLBp E6N1iS0MAKBAXBlXxgti4CIUjOY51RCWm0yGENS5cr41zu7ZnejKOZVT185DHAtDb+Z4WTlBuBA6 Ukdb6+OgQ4hN/llztHAxbuZoYcJLphj4V2+lGKGteaacslsBYpwpnCis60BdyIxVgwwhKHPlXJrT o5AAjOXLUTC6tLAh8eiqwKOz8/kXyS/jUBPBF6Sxsb0gTY346tSvCEGZ58XZfQ1rbIskBFfRNY42 Zth5k3DWDDtvEtbYQYcQ1LkAh919A4e94ZVzGocSdQuHEv5cnBarbLJsscomS8wL0iFkiw5ap+J7 +MxLTq/hv2oKdesNFGr6V85L4DzrCLxSOGV3I4WC/8HfWpe/3fTw7kMhGj3/tFbEioA81HyrQq+s I9IqIiAqjcMeKZcj3BWSkSS0HxASunK+Jqc7fhMHQ++lUno120LpRfEiHCuMcZs5VigVnjXHCavD Zo4TWqahzjhhFHq9VqeK8ALZdRhCOlfO8+F81qenxMYz4WzNi9pJrdDaF44SOqmO3BdExUGmA6jy 5QyqKh3A4vQEjF2BZFAzUr1xRbKOFsrTnDIiBi+UrB8B1K227spX0g3zDkPaZ09Nof5KCPbpc3Ok 8NoMHCmiVU/BgaQNNnEOIMmHK+fXxjklNo7GGGayFMHUgmCENKEjVSfpONNBhGK1IjwvTufw/Dov h9eE0zmstJyTQlV3QUE/GGGcGfxQEe5PLoMINoEtHOpHWzjU1q6cb4XDh4hT4vBQOPP4eSmcs+b6 7hJl5SglqlQAG1JzZxn3KnBfgCjVoEJIU7lSrpTLUShlN1Ao868cXvG3cKhznIuD5cgKrT0vRxXg RY03KURIpiJOWB02c5zQMl05zRVOGBW5KyrAPUoyhKDMYc75o+d5cHjm+GQmPitZEaKd+KxkhQ9+ yFJCUOdxnF4MCcCS+iSU3VESbVeE4Jb2pRznQ0G8rBwnvIsduS+Is2nQQYS2T0Jwi70ARycRbOIc QJIPV85Tc07xxWVjY4VzSjwvOZQ75+ZQvm/h9NpyXgqVwg0UqqiX4FA32cKhrnTlfCucy8bhcY6l ESZTvHBGDUONh2HPDDKEoMxhTs9SAjDXnzFld5REZZAQLKdXznaOUXYY+YKw0g8jXxA6hUGHENS5 cnisbuH0vHihFKo6Gyi8eNUApCKIAXiuIvhlHOojWzjUjy7BgX6iw2aOE1qmi3HA/1Jt5ngho7ly HsW5lN9rvjv4Nw75XhFeN0iHENR5HIfyghDMr0twqLacUjODUDEMNTNCoyHkviAGKjfXIQR1DnN6 CScAG8FXp2AT3Q0YtuM561ycak2HNGNZNg7cDwi1+hrPUng9+msNiVYBcsf8XLH9gNB3L4Sjkwh2 yEJAkg9XTkOiiMHNODLZA5xWNQFJcRjTG8KqL9NBhOs8PUdKPXAgi/RBCl5LKTW7Vkbuh8fQevY6 KHOQAmmmh5YCiLH+STjQcs0w6/+f/TLJbiTXoehW/gp4SADs1qE95Ei1/+lHsAOotFymLTlCpRj5 5M3rp7CCaMgEvF92vHFhKi4mmNyPnNJsmEAE3cYaUQ1R5QjpOafzu46cjRVHztijHTnzK47UzqOd Ue4LijSNBUW63JrTu+U+Tp84K45Mrt9zLod7orH5MUm+bqN5W1Q7uBYAwU0xQnrM6XzXkcMqTj/0 p6MbkJDWx3ZVnK8bXtvnyPJlUza8ayEOg4pRoMWcytsp44AvOq1Q3sBpDXLJGY32qA5ak8itOkwC 4Is6l8M90as6FmIhEWt3cTxi0iDXQqzNU46QnvN0R51oIb0yjupIdxGnd6njOn1iCAE4rDIuq4q0 O+9LO8FYLtXrRMD7AzitZTBx5HXLaEQPL8kRIjn3HG9cmFoYE0zu5R0ykObhTsbbeGgHDbn5naIJ SLs5YDzNCy2YGPZRnAkhTYozKT3XuXxq8dDO/ibJOngHx/H4BTc528/8I6d2Ov6JU6MrQPdLSWlE pbyjYylqhwkEf2gnGRdpcpLB7J7iRGPTtNYwwR0Mnrx22kOYEIRDOzxVcVphmXgPL++QoTDVFZMQ 81s4aHya6xNNsv4HTuvcTELu56e07kbUBFA5QiTnJw4vDI4mB0xG9/IO7x23ivXpQwWzcR4LyNTn LBANUh3gM6JiBlEx76NYk0OYHD68iT50Ll+yAJOBmItjo28OxgGqgilNMZ3omNM5nf2dyP8np7c6 lOfzHA0UIgXWic6554w6FaW1wb+VYNBRURJAU8iGQapDgHpKDDI6LnpTGuMYWqx4dHposeJpGqKD jIGEZHyIxfGxKcGnDqoRYtBryCB9XG99ZfvU7QHHEsYkuwFqUEw0gmbSdp7xOEIkuO57fwpL1t18 WCfV2h6Jv0+nNll2bOli27+vHz3gAG2z/OuzdWbdl/8UlmH7xsbuPki3tqfZJli9MbbbBFsu0CBX 9YQ1aSbtpjCeQIgk15vLn8JsdIU5H24+bSP199r9tF3JGhg521Pzf+ZN4jxXX7415OIgNQe2760F KSL3P/U8nfRka2L27amtQVuzUwrt0yrpFgCPIqDixBhvnmgj1SHcHK6WEjOAMyGUFwk84xCLErxr jich1UHa/jA+BliayyDALvyLg/xYvn6NwEfO80sDPt62PDQTH+MgNYn8CJpAzZFnFiK5kHL9EplR SDef1Um11hwuxeTuOFw7/KI2ByJMf1cl1fGZphwhLuDpLDjciLxfdgI3kfAUh88fhWWHBzKkpzhc IbCqJL4QwhMUbqOZvuGkupI8wckh3nF46DtXnFRXG3aipUGqwwWtYwaI9Wr2ZYM7diK3ZDDgvnca p/FCRqkpJhFB11QjqjZVjJCe877O5XBPdDrv7vAlw/m7TtmG2QnW6224EbVVqxwhlMOhHb71pLTs gMH4ygrftgKsKmiA8KBOuTIyQY/twrrdMxtQd1oVI6THnM7ezjiFAvpZ3k/ppwsMxaxPVwU/rs7j N8nvOXrl6d+hLI7tO5S9sX/vMrGE9Gn0do66RQrpV9GPHECc7rzZeMLpzpsNIU05QnrODo762xcc 9R2eztccKdQVRwr+UU47q2qzbGdVbZa9LiRHyEpO/3Rpvvef+W9n9PC3VmRaLygy9E/nFZxDn8CX UC6//VEIt1LtfpVwEPd3cnF00Zm07sfE5Xmxk+TyYX+KhFaC/pmIBJ3ObzrjxS85/ZC9qjI614oy GuAuDhlEv+yQcS4e2vGGIC473oDNU5/xBl1/67U7VaJb4chRRHJO5zjOv77Tr5yNgzirdVEnKRmA UBxnILtBroW4NMUM0FO+b0hXGaA3pycYl4JsdDdS/Ysr2XLAuCB7ykyw/0GZwgx6bv2sP+W3rJ/2 HUXarz1bkfkqpM/pRzvWBMDJsSaRe4bDRRspa4dJDvF03s35ytn49Iz1SrYmYm0IaCzGQWpOhnST 04mc1Up0XXzd0fX1WEf3hK87qrU8UpGu+5fS3wMa9Di9h0r0+9QxnfQhsOLIPFpxZKydzn/F0UvE V87hveOsz8+rOA+t9csebeVTJblcAMXcXmdZ9yq4FpCsm1KEtJRTOZX9FCnZBUUq/3R0x19xZHI8 yuntiAxA0O2oAt3U9JDqRGIq8YYgLjvegM2n016FN+iSfhUV6DcqMUJ6zH3n8afnGI6unJDxf3pX IhMT/U/vSmRCDFOVCuk5P3NGMxTQW+pTlMunktyuhPRb2ncdH2IhwVbHm+DTINdCPOUppxO5fQrp t9gdHMgmUtYOkxzi6Tzb+cq72PdsfOB85Tz/7UjtPNqRel9xRm95rCKtcEGRjrqHI9NkxZGpdDr/ FWffc/i5Q7LCbEowHt201ARe9nCKEdJj7jujSgX0Wj+wcvlUkjYopLfT01l30NG08kVDNkwrXzSQ 45QjpOecjj6rK86oixdVpOssKLp51QMoTbAfwEc1we85MkdWHJlHezg8TyAuO96Azbs5/P6tW3aC sQlP50fOXu+91rvnn2mq90p035AcIT3nZ47UhZBeX3s40lu+0jOjcSlOPTPxoBFyLQS5c+scIT3n vjNauIA+CH5d6UP0MrE+jm+tRzn10yDmG4vUOnCdiIz6ep6tCTC/r49IIsfkj3rPlf0zEfm9F3Eg m0hTFTLJIZ5OI8mk6G8cm+mO07omk5ymNb0R1X1VTic65/mOtTA5XEVwV+l/lnPu5s/ayHX6MgBu vp0ec1fhMoNppDBBCk9xeOTitOszAe+XHW9cmIqLCSb3I6c0GyYQQbexRlRDVDlCes7p/K4jZ2PF kTP2aEfO/IojtfNoZ5T7giJNY0GRLrfm9G65j9Mnzoojk+v3nMvhnmhsfkySr9to3hbVDq4FQHBT jJAeczrfdeSwitMP/enoBiSk9bFdFefrhtf2ObJ82ZQN71qIw6BiFGgxp/J2yjjgi04rlDdwWoNc ckajPaqD1iRyqw6TAPiizuVwT/SqjoVYSMTaXRyPmDTItRBr85QjpOc83VEnWkivjKM60l3E6V3q uE6fGEIADquMy6oi7c770k4wlkv1OhHw/gBOaxlMHHndMhrRw0tyhEjOPccbF6YWxgSTe3mHDKR5 uJPxNh7aQUNufqdoAtJuDhhP80ILJoZ9FGdCSJPiTErPdS6fWjy0s79Jsg7ewXE8fsFNzvYz/8ip nY5/4tToCtD9UlIaUSnv6FiK2mECwR/aScZFmpxkMLunONHYNK01THAHgyevnfYQJgTh0A5PVZxW WCbew8s7ZChMdcUkxPwWDhqf5vpEk6z/gdM6N5OQ+/kprbsRNQFUjhDJ+YnDC4OjyQGT0b28w3vH rWJ9+lDBbJzHAjL1OQtEg1QH+IyomEFUzPso1uQQJocPb6IPncuXLMBkIObi2Oibg3GAqmBKU0wn OuZ0Tmd/J/L/yemtDuX5PEcDhUiBdaJz7jmjTkVpbfBvJRh0VJQE0BSyYZDqEKCeEoOMjovelMY4 hhYrHp0eWqx4moboIGMgIRkfYnF8bErwqYNqhBj0GjJIH9dbX9k+dXvAsYQxyW6AGhQTjaCZtJ1n PI4QCa773p/CknU3H9ZJtbZH4u/TqU2WHVu62Pbv/7NfNbnSg0bwBLlD1lkgwGDsc8wRIs3qvWxy fynYTVPV2B5PfhTlx5tP39RruquLpgw/ZwQ70G6Wh9qcU+7L7x1b46ZYv7t3RKM2NtsXTF6M7TVR o8KcOvJDDCWTRdpLoTMAgszycnnvmC9hx0Keh2obIuva+7Q9yRrQ82ys6x/XLajmC7L53qVQOiJ5 4qZbS0QI3n/ERxHN7F1Zc2Pt3eQl97LMrZogGhVj/RTFtMeUUgZGGyIxadpi6mnZ03QguHneNzLW b9w07SFzDi0mJyASM6WtsToG024uHYk1Nt7ETJVWFhljHblcNy3W8fY76YrkUjoimVLuiQwgecAZ CPLGZRURK5bmZailiET9fTH1KC7hIqaenbpRW0ws0fQliMTkNZk8QMI87QpVk62mXf+tynk318P2 1z//pZscRnQQkiSoPj2FQM7ok1syA30+33/6w/bfUiuFarjbv1nq9X6gy+yKT1xQTYvGXW0Mw602 1hHKjJ1SHbjajtRm/NqMQ1e2BokTtdwY+OxKTAOS/cycgFBmqfaGt5MrNMRkuojp/b4eLb/S8nry 21OoW9g4xCdj3pb4ekyLQSTJp8E/lpMbv66k3834vtkoRXDyvhQFvWxmyk+QBvwwEGL5dpsIkc19 /6E/gLj3HaDUVyFdj9ej4WcNrye9XQ02I0/zuckfh3+Y7DHLx1nX0Po5je3eIxeYHfgxgPf6EVPr Gj99Z4jQfv+7TfDfOIH3Gt6WBllFkFRkf+OSSnXabwl5Pfv537Sf9fTLYaxJ/LaTcu3SOz0u0Zf3 vE6AHgLbY+HnkOafvej9Qxfyv+tqYp4IuhIaKKMDgS5B/43XiL5qFEFaKfX+l75rHhk/yvi6Gngt 0B+6x/FWoB6iYFmdIXIEvhj4T7ro2404KKA6gOYnZbAxKCZIcHN9QtqtgghKCUdaGaBnRbwrazac gCCzVHvT41W9tAOc6CKEbnmPkLdCXk69+nO/tp4MOTi0j6euCvVwrcH4fP+A3Y/9J2na8edjtQOQ Qc/ZZ2GwNaglT1D99vJmQQRlhJaFQNju0NkCPhVmRIg+QLUWO5S0Rg5lMl3E0H4+Ot7peOf0jQPN PLFSBBOuq+pfBpqy5ouJ/6RLO/qGgiKqA2h+Ukb3iqvJXtWHX0lmXW1iiU0CqSYIWa+RSRDkuY7B Lvzv9n/nqqGWieYuQfOkiMSwq2aXczSIxtzPWCtAGpsR3o8aJrj99EscRlwRZJWO30ZNVBJkdtEP H0CSQPmg4UYA/XZgmow7EYK8Uou8YG+MnYDznEdop69HwY8K3nqpMOBJB0lFkpvLakhNbvEjTemk TjoznUIxp1SQH6McVBKEuX8+MyCvCkNQrQjyQNIchgYVQWbhQJc0YwqCcKarGN2tf50q/3n93/qp zMvv6UwpEt06mTtpRXxeDKJz94WfSgHWhsd4P2w8xQ3ISxkGXRHklZ7ZD7iWILqOdwsiKKMDAXTc gHpvS4ZQB5BVKrEboJIilOcq5IzyI+KJiLeeKgR42jHbioS6bCQ1ItrIF9P+SRY990xCkRLSH+0h VORMGmwMqgnSpcFCqKCUsDFKAD0rUqWd7dcHiGZuxdibpDf2Jk50FaPdfjtg/99K3rq8r5+xYOae WSmHLYY83W+nKxuX15gv5v6TNO30o2IH/GpvfUBOhNGN4VKC6DLeK2ighMb6fnVpKhaIwdyvCEFe qcUOhVoNMZkuYk5ZPzKeyng18VP971qPRgzOh9iW7iUrsiwzk2gxP1jVHqY/hzwfJ74doFh9RS9h +zkXQJKlUJgCIfO8DAUbQnlzUmXayedaAnhXVr2E6kJooIy4YyGwNbUyUjVYYxhUaUjPrNXee9Tk 0dwvEJPpIqa3+3qEvBfycuornRL6/P7CsUGre3g9SqvQ0lXbE/XnkOXjzNv0UjCnyegQXFyDOVRA fCpDyYZ0mtrze8fSNFbbkb7uZVZChJ3TCQO0rL/9EgdRGkJ5pdZ7jwoLl1KA85xHnDB+VLxQ8c7l dwLk8aDYEaWoK+rnJs4GkYh7fydF9CLHnws58zhcQEJJpmBHKHPXpN/tuJoguo6cqdVjTkcG3LIi 0S+DLA2hzFKNnAnVOsKZrmLOeD9aXmt56/LZ5RzZ5UGrI8nNRQ1EVvXH0pDnG5/vB029YDz5moqR aRrLNYSyyjknd6JK8ltXsTexAMLnWJ8FUCTN9sPXEcos1cidejEFOM95xBnnR8Gjgrf+LhTY4TvN jmCudVV062QvXtrKFy4PZdQFoIyeeSgDRJVBSVUGmbsy3Ye4miDQBishg3I6MmAZFMlLMZw6Qpml GjtTr9YRznQVc8b70fJay1uXj87nxbh8p9URieEDuZ2wZBCN+cLlpQC7An80xANwuICUMJZsCGWW rtmnuJog9eWjH2XbIVPinoUA9yxIlXaeDaWO9MytGPmUtEY+xWnOI7TT16PirYq3bi8M2O07y46A ZVvlt7bt0dSYL9y+k+1uwB8POftcUhAIoyUhDDLL7rFDcTVBoA1WQgbldMZgCmFA/BoHTg3pmbUa O1Sv1hHOdB1z5P1oea3lndu3KWa377QU8fXJkMyF0NfWi7mQ9dPwhdtLATYFKNEsgA4XkBjWoWRD KLN0zT7F1XakryOjMjLsnE4YcNOKxJwGYRpCmaUanArFFOA85xEnnB8dL3W8m/pYvx7LzFMfJzdP pmCL+TGrfIgDIjH3U98KkDIoqTrE6jfzAORkK3aEEqeQ7WaZYoIEN8+L3SyjglDinoUB9yyId2U1 bgCEMks1bJb0hr0yaU4DtNPXI+KtiJcDH91ST40y+D0Z3bPxbqtCPXNzZqTHXA88idy5DhszOV9X ckFFIIsWPAqlm/eVLGN3v6e7gvJhWhmpCqwxDJooMu7ce49a42KqNcRkuog55f3IeCrjB4tf09xJ /OIuRUT1doX5bqtCveqsgZHezIeJR4FmBXqho0MWXZiT0aYhRgkhAQSZYQXtimeqyaUP2mAlyyCc zhjgmCviUxk4KQLxpJrsl8/JVGsIrfsUc+T9aHmt5Z3bh/pWYK83Uy3IFsHHcXYpzgaRiHufbx2T I5AGev5BAEgoyRQEgszSLyzKFNuB4vwSrUdR+8JHm9XaaBZI9MsgiCLIKpXIn1pf7E+c6SpGO309 Kt6oeOfyjQS5fKepv0FT1yQ3l9UgGnPv8cS1eQDtip54HC79LT2jIBDklX0jVzK1BIEuY4PMiA+z MMgu5zgg02Q/fUCQWaqRK/Wp0N9YdRXBs/Wo+FnFW2eX2WVvBylFJrd4c/sL9VhN9vqlZ+ALf5cC 7AQoqScfRwpImseSiiCzdE3OxMV2QFexM7EIwuhYHy0DKSENsiiCzFKN3QnVFOFMVzFnvB8lr5S8 9XkhwT4PooqAKFb5vAyIxHzh9GCrjoCSev75qCmSF3vbA4LM0EY9iasJAm3GFpkTH21hgKYVqbfb ZCh1AHmlFnuU9MYu1Zddh2izr0fIeyFv3X47ucm4PU+0ILXLYOzBry5NhZGW5yu3hzDqCMfzr+mA 1D5m+3wAgsyQplkSF9sBXcUexSIIo7P6KgIQv8aBkSKQTqqxR6GaIpzpOubI+1HySslbtxcS7PYg 2hCa8rbK14tespcxbeYLtwdbNQSU1OPPR00RKKElFdHMrI1aElcTBNrwSsggnA4MqGkgIY7CKILM Uo1tCtUaQusuY055P1pea3nn+b64VAJ7vplrQSSGPT+7Es2VrMfce347SuQLdLiaCxAJIJgOKclq aeYYVuNUptgOFBezfp5tg8wILWv92eV1GZBpMYQ6gLxSi3yqdUY+xXmuQrCdj4w3Ml5OfHapnoy4 Tadc2CY3r1NFapmgr6IdCVWAWWSTRaFWWwMBLcvHcW/ttPS/6JgKJlcWTteRSmGNoSF5LgbRzN6V NVtdqJp+BnXdy6yECMLpyAA9AwklGU5A9GOt1d571Fy3gKs1xGS6ijnj/Wh5reXl4KPARuL3QJ1L MlFZVdw00JSIj0a/f7yIa/vAUcHJ7TdCnLQO+KQepodREf1Qsy7tg2dqyUcRumAlSyDXADTcCGi/ /adfrDkAQVap9N6jFo/GfgnhTFcx2uvrUfFGxRubD7NLcWabJ0ryO7ucI5v8dqBWBiTHNyZPkug7 5njkNR0j0S/mdAFBZsiiNsQbIIiuI2MyEginIwOIAGSasuEEBJmlGhkTVVOEM13FnPF+tLzW8tbk /8Z+tSRLjtvAE/gOvoAZIiXqc446w9TqaeP7L8wSmEqAFCW5Pa6YntCqu/JRSCBBgIA4sVaua0pe dHz1qa7SUQnmus0rb9EOSJnrn9LsAHRgOQKhXSqDdqS5BKEy/FKLIB5VDjDiHYizbZlEaFe4dIsi FxBtqXXmyOtHx2Mdr1p9qtvem1avnRJEzqje/lljBg3gxI1mL/Wjm4GuKCl9XVFAIAOrDggtDyPf ZGlHZAMS3OTxJuNLLYL4xJDhwSfVs0G8m+0QugO0K1y6PUlsuj0pO60jzOYj5KWQl21ePFgrvy0j vZSvOtd7O93jzI02T2fRDKraJ2MGdhVQhztAq5I63Zw0kyC7LPxQKyDuHLD7nX4DkqjjaPwhAruZ SrcmUgHRhlpnDnx+JKwlvOju3eKGdC1XI4C3kuQzbOZdGuqGqAGcuNHdxbxuACREuetCAtItGP5Q bEBgGSHrpkQ2IPjuZb788GmfKg9UzER8MI1SIbQsbLotkS0jxlLjzKHfj5ZtLa96fHZC9Xh1z4Fo R+WryQ2TLxyVMzd6PL1FR6A20gCUDzsQ/FKUIxDapTJoSJprQ5Qy+5dGhM0jFXJ2gBHvQIi2QRCh XeFSTcq0GkG0pdYZRPt6dLzU8arZjy4us272xilBopuCnty7wc1Rz/bZyp1mr2TJzeCg9GFOI70Z rAjQLmXJzcikQJD8mepORgFxqKanAkRiNxqPiNByjy0QrYhkQLSh1pkDrx8Zj2Vs3vf03/TJGNKl 7rcnK8wu+ZqQmOxvtzlMro+JMSRfuq1ThMX1yWN89VPZObvyuzkhWDckTpOhXFwc+oISSJgX4wQR WvZjL9rcYiMi34Uwuqmztkc3zGMDER/fFbYaS4hkdunaKO0IDD5mQFJApGR/m/jBdUe1G2REci43 Q0NfkgER068ntb9jaht9IT+rIbiErwcFftQEvOvSGzmGtHfNZhMTM6cPIezvISdk8JMOGRODYiSS I9wZidDyLvAtNiK8liI59aQGNaKLR2OrsUTtwmfWgVIaiEMw8u5IRf82AmSym7Jdsilk4sazTXqG DIiYfj25/S1z2+gLefjNJb7WJX7UBfLIkpDOBz1D72euV0J2IgS4E8qWoPh2YBzngg4IrYoCb6PB GH1BNW6T/atUaj3Kbp70TLiCdG5aopGESJmT96Had2K95ioTopYmwwVEbL+ebHwpG43iSyO/H7ZP fb/kOX9bD4wHcBLhyjKaP/qpzJwW342QY8rGXBAKwgh3FwCUV+Dbl91i6+E1ycuYEi4jfknp8f9U 65lCSv43wyfZHc3ukCH9eyY3S3FYCjZBYPv1JPb3S2yjJWDYGV2IcRs/MOLrjUtvE7q7yVc/lZ2z nrCbS+vXMJqJR5Afg/iwJfRgEStXunKhK5e8MIUc4LbmCGAHzF2FfcDTEQLpenFyNwR+Slcj9OhG /HfoldNwiJZFNWEb+pINiJx6PTn5ak4alYj+wHhRZdoFW2WcfPZqLexcjMZCkBQJZvjZAN1GSUgE MZMQCO12XTmOtbkIyFfUd79xuwBHiIj0rrDVWIKUGAYZGRHGIeLW+VUVpk75IZonQxCxvQR7mYmI 7deTj6/l49Wqwfwey0O3HhTTUcHhreXzaMycVmBd9HWGMW5oRiC5p+0+EClvwV1l9Cne1TI3ed5i yDsQ5sUMckTK7L2N35/Y1pvR3iAjknOwGRqnsSADIqZfT0q+mZJGFaZinj8epA/SoLLWBXVUc1hK g5ukNVgrp1V4J+TRxd4XjEAQIXwgUl6Cr995i61H9wQbBoTSyODNnkagZH+b8MF1R7QbZDuQM7nZ GUJfcAERy68nsb9fYhsdYXE+9iju9aC4D+o/zTHTp9t6N8+CGCunDQHmGfDkhm40AafBftJ8++84 hIIOCM1S2ztURHghRW1KifiPEF02GluNJSiZVqhlskoCQCDQlkhJ/zanxij1sGv0AUSjMHqdWAJi +fVk41vZaE7FWBX26WNfaikKBnEi9aBs7dzaTDnwYBvRkziQvA0kt+LQ6+a6O3qEiFvvCluNJTiP jUWHDAT3gCJkpOK3I197mKt3nxtsVRLeRkkMmLSN7dR/cm3F9q3d9MnI/z8jJ5Woa2pt1J2YZwvB 3tGuzdNKLCnhLTNBBEPNr2pjsfUwy7hlDJAIui1FAFLyv5UwjA3LF2MjgtjusJVJeBslwxQKtg8i SnZxKNQGwhX1ycn3ctKsRVtV62Hlwfz+eJeTfF2cJ6X4bWmAxWDblCByFW+sIdWCQzvkF52OEHp0 L/4r9nq9ol0+CSElfS5KDAgL8cnItzLSKMJkdbTzOj6tSm4HiqWzNHJagt8U12I23XAdcqtou2Lx oSBASvq30oBkg5vmUicgcPsOW5GQ9z0V77DTZ/pjb5KQzZ0vyIDIqW9XzZPYPyGxjYZgintVX3o3 z6OxTmR0vR9OWsRJQ/iqvAZaj2/JJjdD24FxnI2SRErq95GM0Y1xNlERYVSXXGU27A3Fs0bT8qx9 zozTWMgMROhfTzK+k4zmQGyqaD0stBxJGmS86Dqlz41mRSmeVN43VSE2TZO5WILI9asEGF3svY0O AC4W7YCfqtUIPboR/Q12egxkt8sXJKY/LgUXENbek46vpKNRe6aO1qNKg+1POcn4MqcNdzHlWVTj SfFVfJMbOrPpEmAsIgmV3J2sgEpZgVZjhs+3CKmDFaRz0xKL8IEU5O9KkXVDhsW2MCJw+g4ZELj4 vqXhHXb6DIR2+YRMaeUsuADIodeT1N8sqY1OUIdbV35G/OLCGA1huzucNIPvKjy6IfQ7thJJ4XQD mj99wil6gAsFRPNtPu2WtFQ1IuLJHevnuVBAENpun4Emr0fLW1peTqByi9UzyGstgE8m0+RxXAtl vVzPoBSGfQzCAKEwecZIjEvweqKoEfrwD248jC4jKRo/DWYOy+Eol1SARJAHuARDdOkIEen0aKgF 2BBlu3lG5fNR8lrJ5q1fnI+9fnLqwa5u7/iI8hoz263ndyHF6Tfbi8s77gfQbU2x19V6XD30AZWe rdPxHeDLWPYZxlYiutN9cua1mwBounmE086fo8dfLPLmxTK9cj24uEQm1+v2+nlFxqN+e9JL81Kn 6k22Q1VuLC7yX5cbDUshyQY5d74gE2Ry3RzMd2n02uMXNkF+TN+gRoLQTvuM7jZ/0/CvLtfn/GIu lyA6lo9verz3wS291wC+2ZoWHP/8bTCOC/Kjwk1NNgYjQO/iPBkBPv+Oxo4gWgDaAUI77TPR9X00 XH8Nn9Xr51PGBpOf4Lo4m/x0aWAy6agAsVLkx7tlWIyPguhYhUzHmq7TOJ4+K7QP13MlwQsS0lEi 3RKK6IDAMFxQo4RyFIi21DqT2r0t0v9Vk79c9M36zwRdah1DTH+YU7v6l3dT6lH//mNbb0+z2y1u SH9nfBlQ0WTTFvFh0vEphIaDx6CYBTZkgkwuxKJ1J2yYvHZJAO1AWoqWuUB6U00EaFaolOA5NCW4 ttM6glhfj4xXMjavbXr75qnYCoqNspqB8A2PWCunY1G906bge2+G+YyYrefX1pA7D/rukzoFDxgi EfJhfOBkhOmxRvrs0UfGvoh/Q5Tl9hko8nqUvKHk5YrJ7TTfYCVdfcvzV2qCLbfOk3v/KytSahTd aLLHQiuQ3fH3hoVlMspkxEzo8IinsgPUQADDJh4xd5SpRnh7uKMx+g1Rtptn1Gb36HilY/POzy6k ncKWphQrll38lkH6R32DE9bG6X3HUT4ssxuWyZQPEVnl2BtY93SyRopOsCG6D4wudLg3OhTtDUPD b/KIL7BC5iNEHsf3Zqmf5yJyQWi7fQZavB4NTzVs3nMdmppnOL5k4PN8LY17X8jTvuXZFrnGOCtB +JvPmDx1DB8P2xFCQfDYCqaf3+j6PprvPk4Nxh9BxKM4LMZj+U0rrRP6mf/bhX01KZiLaHtg3SXx Tfn7xnT8K29J3QHYN2oku3Czxug8n43sgJ6Levty1X2AEtUIOhDeNh27vG203D6jJ+NHxTMVL3dB FlvVKjMQ3NLbQYpHrJU7u6Ai5HuBbl2/IOglgxtG7DTSAY4QcUv3EsF0L+ldnPHm2sdA+6SfByDs QeITLNGDI2TucHv4ylIBQWi7fUa/zY+W11pednk8D+UdPrrn+IZnbN+/7vL/VTfAxsDc0cka4QuK jYWqAKEqZTDKIx1dX7KJR8wc+I8QybfqUCZ6QWi7feZg83p0bOh4uQvqwpRSRUERCa6Ls3lseMba ubUPkhLvm143h8XGje7AbgS3jhD2J1Q++xOQ4CaP+2MD0j7pEIGg98AnWNJS1Yg8lHpS0AoIQtvt M/qWPVpea3m5H9LRaqjJgE8flS6gFsp6STdfv0rjggFKNhFBfsw7CXog3v2H/WpZjuW2oV8w/zBL exGmm28u47Kzy0paZXvLd+Fye5Fble8P+AABNNmaGVm60chTrrqWjg4PQDSIR8Tx7MVls/rJ1bnn iGD0sJs2dXJyAPByX0+0H/EgVYSUjzmzPv2nIvLB7n5xjuBpKSvkrIriqXG2uKKuvqbjjLWB3BwR 6jjHr44qCJ6DyAbuTvmdt3bucEVI5JjDR95PePWLuxl/ALsi1YAFKpPczYgiVa7azcgg1Wp8cWP1 ft2Lw/deMV4BFrUkvdsmiEX2qSxXhJmrDqEQOTBDauR40+PXr0iXPqbwvviI48txvFhLaezYZ+8s w/EUcfbV9YpaSib7C6bK3AB89Di9U89Dp2YIbau4PVCXQYR1PXkb5hC/XgMwddCh/ukoSEMVoNSh QkRXrwgpH3OofD2C+GIQL25k/FHWZ0r1vCFLUtbgulBPEUfqXLWRkUlsjnzls0lcGwsDXMN7MQmP CL5KXgcqxuoA3EavabdEEIscwBeOCLdXfOpKPFIjUmPHezoPQEVI+5jDMuwRyYuRvLiO1RSmwYZl eQNA0jrhwoBQ6zlOezE38U2CT1IVocC8tv1R/8XbNQR8X3UQy027MXNJxAAR/A7NpS7UHZgiNVB8 veEBKAjTPuSw7/mI5OVIXhxuqCftC/esuOOp43HniuHmljY4FC0qKzuAt8Hr6ioKLcFxbyrAxw3u cEVI5pjDZ/BPePVLi6J4Arvy2QAo9inyWYZRpMpViyI9TOpsNLkgQk/8dW+OHn3GeBkAP6LccBgJ GxvvGIiQuepSEyL7E6BGjrdjfv3ajkn5kDPdyx6BPAjkxWpKhXifv7Mcb6cYZ19fr6imZLI/YqrN Rk5XuFTQx8MlYoZQ68OdhiLTENH60CNidQeof5i9teIR+3YUphGh5MFqxG+P9Qm1X+LQDPGI48tx vLQwiqdZHys4E+TC6FTQomcxjtS5ZmFkraU1SbGRIkL7Qq0PEGtnhVszpLrF6kHDeD1gBUreh7vE b4gImasu9XqE9icAFajWycX1K0LKx5zJcvYI5FEgL22LTY5NNzTMNMCq6I5eweDUpW2RhQXXBwoL IRiW1zVA6r94N0RgrVi8OAc2Vyf8qQhb3oTPFSGdYw59gk96+UtThEhLWRtn9RNPjQibnfmTNzqy rtKAl2sHfxYvjiOsGzR5Pu4Y2ZDG50y3GxGqJ61FMT8RIe1jDtWzNwrJR7v80+mn51OC9m3gE8F/ 4N15zX6bAAbdAqLww/N2+uEfX778+u3b+b/2x+ffTjofD2enEpw8P/9Mf/b5z788w7d33tWEhR/h xuXTL0ZFSAMXtHIQNW2gJNvz31YVbDj/59fsdKP4BH8reRNDZmjYZH3jrNGpZdGds0Y4ooVMPubK 4Ww/Rl3tR7gQjEUugQA0FYhIhAoAb9ilBZsZ/LTYs4teJWsKAEEGXUIM+Agv2cWofCq/e6XBHxIx qy43Y2fWBN4ZjmgHVT8wGbNCqQcArqWDL4hRi7fd34xA9YhOIJAu5QYgl4pxq9WyZiQqt1bEqOBz fQILTiJGpYCnYjKs0hkLkx6kJA2TBjLD6bz2gQUXmYcM0fk6eeIMql5TK+NBV+dyUO65OngDYBu+ 6bLqEsD8BfMcC5mXVhZSVNEple9PKhqiFPJL6io6Qu7Dc/VrzvLylOKqkstIrs/lVMsA8hcircIa BAJ3Wiwf68MK70yMPD5BbFfeqDsCSRANO+UggXxNpWDhqQX2reAVQbTZ59ynaOv3s8cU4MObKJKZ zjb5Mb0jfHCdMxPc9dUpqVN7wI529FLSmjlBxdXP304HFp+m5rMxydqmyvgIR6Rr740VacnaJkr9 OaNL4/u2yjr3onGwtadtM2WsFCs8pKod1BKsQIZqghyms/eo2G8H+zebiK8Gtr/Ebz8pVYQsssDx r0a0KgURWaIowrzm1eCbXKq9MK+tSlHcbaiLHSCfpXD1Z0fbZtoGYmqtKLFj0UVEQ6jM1IFsbkfb puLQKBMvzaygjwgW9L39Yk3StqkUVLIQBDJ2C+RYVYbQ0X6xJlibEEJpbDuZetCH8viwTg+NPjd/ svXdua33HTLWWpNLCRvGpOnVhjZDsCCPLhb78uDGzO2l/KJVDeykxe7tF21J25jS/iDvzdC/rAD2 1oq2YG1ToRol3uTHto/aOEoO5sVFcHmZadfoUtucjBR4iiF7+8WcPLjNxA18Vsfa9mRcGeyXbJe0 jSEkZeHpr1NEq2Tm01ERl7RtKlXKBAeGqQopZGxvnlUJbmwvrUMbtbyy2k8HNvy9D2M72VZuJW2b Sq/K8oFsMgx2pA+Dg/1iTdI2Qki8z5WzSTNGPzVXOpmk5T4FjUW4OZlQA/RLcbnOGT1C+6VNy4Pb i+NvD+VuIB7NN+nc79k3GYT6JE1Tcp+taR6XOm2UkrRtKoVD+QtjOvS1mFfVHhTOQWTvUnFAHtxm 5voOgJ7PtgIoUKUIkNt7l8oILGnbVBwXDNhal6OVA+4QnUD2DhRzkrZNxXF76ZvJZJ+p4zw91tGB bI6tPZkGY2GyYnrbMzaG0GJUFxqqp7PlCZHZytXryZ62TcVxD4MPYJ1A+mYWgB2tQPYOFHOStk3F kUNLHtQmEzgymMviO9o2lcJ9EbsqnRoRPCXEsc9PpLq5voyO62lDaIYiZeLsXSoOyIP8djiO6AB9 h09aGN0Z0oa60aHynQRrI2WcqnKapDLDoU7LGxrqOFKH3MF4MSVZ20w6wGwjlBvQxtfRUhHmpG2i 0l7xHEGPpSXQ/en59Pd/+vN6fv56CpAgcHKB/+BH4846ld0olq/p8vrzvJ1ymQSSWrUu/7rzty9/ nH74+V///vH5t9Mvz0BwUJDgT/GcT5ny931+yYxby44CwQRzR0jLSudBWCb4PnNzuHa0bSpVEQcC aREI5GKIKzM3ItIcrCBmheUCUsI7CNxSaiAvhQuskTkgCWgQG9g4c1iM11DGc9ewyi1l4O5IVLo0 Ug+auZEOAOyK0ZZWj2dGRMPdfBAccKqubd6UkXwEoJD7agm8gj/NEFCLkR/aA8xyOzMi7JCD1x+m CLkHcwh4MUPIPzxloYM5gTiYXsIBB3VGhJQDJL6dIuRPhC6RZgi7ezvFEOIsyQod8gcRig8MfFBg ZwhZTzDb+ClCt8BTI0LW8dSIdOvwQryZAHRPeBxumSKk25HuMdRqE8IU6dnekVFnRHoe9FMjQqdy VNIMYbdopyYIZJGTp0akvvyMgA1rpggpE9JyJTio8n6KwJhvvUCwhMD0tKTJ7zNVtNwQFvV6aADY GQ8/mSlCcWiHBoCigL6MSN828NAeoD0KLU8QnGn7oQHAIbNb7nMgITis9i87QehUy5ApgrZaxk4Q nOb7W6UlryNtycPKMfzeF0WsSBSZXqP67or1cIL0kGPhh/8Zy4H+3Xbdri6cAPo8M+tcltfWAhFZ vWkHPzenZv+tHMhO46/m4BwBA4xFTvChI5UT8prXSsfGEK5zxIG00fFdOKVQ3UjJia7fgVKL5O2c GNw7cXJxvZUDDdym9+C0fjDnwN8WXTjBYJxjMh2pHKhLXKYDXpsH48G4IocOc5HpPDgfiYMrLX7T 1pvYN20djekQgjofi/P04Tx6cK7l1HXzVs6qbPJ3z4ExPcabOXmBuWdKXtL0rRSjtDU3cMr+A4hx pnBgk4P9D5G6NAUnZDqAKg/GZ2P0ROu/Y7Z+KgJVkQ5gMbo7BnWDDmBTuVvG05UqXo5qFn6S47ct ZK7SELYKEoIr5afiXHP3kcPC/OBcx6GXeQuHHvg9c6jC3sLpdfovTaEmfAOFWvl9ctxa5w8cP53y i+/I7wWxSY6xhKDO/XD6JyUAE+NBuR8KVTVCsDq+hvP0ZkoPzrVf7GNn2GsoV5Sbj1YhrTLG3cyx al3Dh+bA/3W4meOUXtJ352AXdsqsmGG1C1eEd3PSIYR07pFz+e4f7Xt9P87TaVErVBD4V+vyrzt/ +/JHYZq4P4txy0jW98rG/lwEgC/BKw0VQr4N1K0efC0sI59dB0jn/8mgitUBLHwTRr0xTbyh/MQn 3gBsJ2QIQZ1jTi/5BGDj+O4UarqEYPN+a85S3vbvAol2fQ+OTirYxDmAJB8enDvgrMYWJLqaq1Fp qFeI/F6Q/OK5DiGo0xCWGzdwWI69NYfexS0cel9vzaGacAunl5a3pVCxvIFCNfcaTssvVt9bfk3q OzWS4/o+cqgfPTjfi1O/qYUv6cU3rQjPDdIhBHWOOfjdn94wE++H806v/c9SFhhAM2BDKpSk1v57 ZaSkdyKIdJEH5UG5bwp/r1dT+LN/cHjBv57DG8dH4jyx6uj+x365ZDeOw1B0K7UCHP4/6/AeMtL+ xw2RAgE6dlqMrUhKNOrK7XueZIoASHCGjsh1JFYytX5Zc+Tf/KSU7B2hVKPmHvshGrN8EpFqHdGh 32F1ErOj/i1XWaYQ4ZQjOEfdhXL/0LEML2zR/5PHMrzUBdflEOEKZEKVvIfTmioDas0/rvAVDS+z PhQSVFm/OF9CYyNTIdHmf+I6KMiS86LTrrCCJKf3cgyuisvSQZJDvJytnTXfYt+98cBZs5+3q53P Tqv3IYfaxpuV1ghHlNZPd3HaLBly2txa4dzelnQ52zpb7LJgC7DeFgVL2phGpkKCtl0ME4rZ3ml1 yoCq/aQKt0Em1E5/i+OV7Y5zuArZdcc5Ay6FLocJ5VzOzzq8V0ectuVPqnDPGVC4db3LoaLhlkxF 872WzFNkxOFptIfjwZk47HgwKq90bm9LYhLAKj3sBFDJXs5Lzve+19dOrUIPVqeuCiuR1cw5TChn e4crgwlV2B6O7HY2xq6TWQiJyVSIXxzqZEwo5zWnNXEGNAp+XOExyoTG8R4Onv5Nv34KktNPHPqe 8y3CdN+zErkvOIcJ52zsmAzRdXWDJId4OQtJkKK/cxR2t/M7SnX7EIkx+ygRtOnmBBLrwiYOzkjb Hc+RGO8fOrcvLQ86dNWFxCb91CkdAYmJXUdYiOgsIocJ5VzO8RzeGyMO78R3O7zrRxyunvlkkAsx tnZDBz40MBXgvOlimFAMkVbvAwp3jQGFu9yYQ91yjUNrkyAnL9emArnEHENExpBDA2fE4cF1PKcu T4bkk1yeCvpVphgmFHM5Z3DGKucvOt9oYq8qFq95M9G6ji0PDq+dRKZCrHEyhgHFXMoj5Xaot9lB 4S0+5lCp/H6HWuSIw632oI5VkJwedZAEYy/nTztGh0Kirb0lgFWxkakQnXOXw4RyNnfEfmZCdXFU h3sLO9SjjuvQvGBizGEVvqkyoQvvmZ0AyobOCWC8f+jcVlnvc5amgUQ7L5vGQuTw4hwmnPPM8aBD 18SQ2KRP7zgwqR/uDryKh3YsON1/UwvBut0cA971B1oDMeyjaAghdYqGlPZzcGhnf+cobf6Co3H8 Gt05CrTNT53awxR2o66FFSA7IacsRKRczmNHuSgdJCb4QzsJdHSdk8BmvYkTQaXuWIPE7mDg3FXd OQSJM+HQDlay9f2ZB5n35qF1JseBC11lIQkx/wnHgk99hVpIym/sLDMASci0y8oQWIiYJSKHCec8 c/DAoF3nGMhWn97Bk8e9onx6rDi829gCsqNp7LAaiFTHYTXIGCIi5u8oCnIInaNBJ/eCgwfrkIuj ol8cHxqoio+xiyEiYy7ncs7gzOcDA7YwLjC80mVuVzUpJE6S5HPxMKHkpZY/CnIp3D2sklbwrFA/ /aRo8MoWJRlz98ozqQ6Omm7cEOHW/dyhsTUvkIJgu3ms8D1iIzUoGtOCekLzj16aSQuuo/+joGjz 3cOIVAvfKGSIpS214xGSHH0j08OXZEJHjbsXkMH1JIavFBKkNFvtlImWbn9Pjx4uyHKi+5Qsc+t5 tj4rZ9M9i0m1boUpJU7q+Lcxcfl7evh+WiR8frJMrLeB+i5az6ntZtIIWfO7RLzXzRuv3ZWQWG8b mcT71aSeLPeg9gZMOLneyz4KM87fPY1IteZ3wt8VjLxzInGpgenhSzJZroGfXqAFt+vtR2EWf4nB CanN8qwZNGd+IfzoqUop1c/qIajQyMSvWHMm+c4xe/l0QTg3BNpCOLG1Lyxi8+mfNZOpOMHgbzXY CerrEKCgLxTsNI4+PjZBXCCD/7GlvyJIPjVSc6JtOT2oOfzGTFqu01SFFuaC6h61gOrMrzMH4B4y GKjqT5+fGhuZHr4hk5r06fEy2KS8vJCB4OPdw4hUa8yZv6UedjzoYC/nzQ5WmvfDTgBlw2oHSy26 QrTz3WatpDoxzZsce5OrVUhE5jxzsH+ZtIkzt+9RZW7wZgMFu3N233BS9Bs5OcRhB48H9ZL7bsfO px79xMH/hys1O9HSOqdsG6kOzmwZ08A8Dy7jMv5/Dz3diyLnco7i3Hg6ia+6TCfxVZeZJpKY0NMu 53Le4eAe1X7Y0eByOL2Dt4+Uhh0zX0NPrODtK5hRxYJxdsAp1zok1lt5f11IvQvO10wR0wClXMZv M9pGa3/Tbv1VAneRBqgZnc6QZ5eGaKzcOb/NCP1BzeG/+uO3K7JMWYi4CjKhK+Wvctb89s+OWObL WedwZY44XOBndrjDjjitT/9phYfwgMKj/JyO1/X8QcdPD0GFRqZCXO6PsUwo5zxO+6QMaGNcyirl doy34b7GhPrj5eztrPle+2/ldysr2s3ROqQDa/2w40DreGgH/2visOPBqPzjDk1hD1bTDqtTuBI5 zTmHCeec0fn/33607/VzTp21Nt1btEIzmZMCuNQKowO05wMY7AV9FVBufdZHsWxfYA1wzp4G96YG qMU9MOov5rNtLP+SZ9uItu9imFDOc6c1dwY0In5c4fHKhMb0ux1VqnjqSHJ6C8dkiC5LB0kO8XJO 4GjrCkm+7tUEBvsVkamQueJlDhPKWYjYGwOO2GPvdrguRhyur3c73BNGnNZa3qtwsxxQuOeucZb9 Jfr7sr8e9HceJM/7+2eH59Hl/JRTv6nDLxm6b1qJ3Bucw4Rynjv03W9v3InncTaq9lcVhQfQGbiY i5JBt7+rkbO5CyHSQi7lUs6tyHpdrciyvxzZ8Nc7cnAcybmJ7ujBGToi15FYydT6Zc2Rf/OTUrJ3 hFKNmnvsh2jM8klEqnVEh36H1UnMjvq3XGWZQoRTjuAcdRfK/UPHMrywRf9PHsvwUhdcl0OEK5AJ VfIeTmuqDKg1/7jCVzS8zPpQSFBl/eJ8CY2NTIVEm/+J66AgS86LTrvCCpKc3ssxuCouSwdJDvFy tnbWfIt998YDZ81+3q52Pjut3occahtvVlojHFFaP93FabNkyGlza4Vze1vS5WzrbLHLgi3AelsU LGljGpkKCdp2MUwoZnun1SkDqvaTKtwGmVA7/S2OV7Y7zuEqZNcd5wy4FLocJpRzOT/r8F4dcdqW P6nCPWdA4db1LoeKhlsyFc33WjJPkRGHp9Eejgdn4rDjwai80rm9LYlJAKv0sBNAJXs5Lznf+15f O7UKPViduiqsRFYz5zChnO0drgwmVGF7OLLb2Ri7TmYhJCZTIX5xqJMxoZzXnNbEGdAo+HGFxygT Gsd7OHj6N/36KUhOP3Hoe863CNN9z0rkvuAcJpyzsWMyRNfVDZIc4uUsJEGK/s5R2N3O7yjV7UMk xuyjRNCmmxNIrAubODgjbXc8R2K8f+jcvrQ86NBVFxKb9FOndAQkJnYdYSGis4gcJpRzOcdzeG+M OLwT3+3wrh9xuHrmk0EuxNjaDR340MBUgPOmi2FCMURavQ8o3DUGFO5yYw51yzUOrU2CnLxcmwrk EnMMERlDDg2cEYcH1/GcujwZkk9yeSroV5limFDM5ZzBGaucv+h8o4m9qli85s1E6zq2PDi8dhKZ CrHGyRgGFHMpj5Tbod5mB4W3+JhDpfL7HWqRIw632oM6VkFyetRBEoy9nD/tGB0Kibb2lgBWxUam QnTOXQ4TytncEfuZCdXFUR3uLexQjzquQ/OCiTGHVfimyoQuvGd2AigbOieA8f6hc1tlvc9ZmgYS 7bxsGguRw4tzmHDOM8eDDl0TQ2KTPr3jwKR+uDvwKh7aseB0/00tBOt2cwx41x9oDcT/2K+WZMlx G3iCuYPXXihIij+d4x3BEbWq543vH2FIIIgE9auO8Xzarc3rrgwQmUgRIJn/mhA/5VxNiJ9q/eti 6NBe0hDjfPgVYjwdv8GbGDf5eTmN4RnmaBqZEbYBOAk1S0MgyxNzHONiwRhCQk5/65g6+RJNTJ3m xf8hMWVy1VxrCJn/ggg6d525hxASQ/5bx1Anz8neeQhLKRxG/UwxcYrZdBYhuSy/RMw8pWo7dJ6q S39wTDsDCMmL7LLtEGgInCWQRxHNcxZDFwYfTUyYltn/9DF08xhDXKrHIZHeNvMGLFFO40jdIAjH ROoGTCMIpPl1Qty05Gxi/ORr/B0xdLHOyxbjSmoxKXeAQ1IpJo0gmOaJeWJ+hpj1fhCmecO0wehJ t+i44ky5aiZE9s2jiGRuvfzaoFjzQMZIb3gNkXm6C/FTcvMWUkMYJK8Ix9BRY44bQXR0n8fIsbUa 5KY8m/PYkY7SEU5UQuiJLCLnn4hWpCfmo/+1QWVeBjJBOIoU5WUq21jq1yNClpI68j4UqYhcNQYB mJhvYiQp16nWNarfMinK99/vI3JA2o1ulxnz8n2WuZYlGC5FOOprw5yDmzr9DqG03+9DfR4y7Jkx I78GWIv3a9b+MumIRK1aCr3r1o3X30qEzGnuyBv0cSaLtHdQV6CIZuZ32WvDQkwDmyActWqiunLA NychsXbgfShSkfYM3Anoifvz9rVhM1US6IT0oXGtQI9ZBdFHrxxUK3/WNGWXO/JWiZznjZrLkpAd EM2bs2whOrF92rBCw8dyrch7i8mBag00CViOAJLoIoQmTZSPT0OQDAr0z7zNVwJqqh3hPGXueSzA eVSxIj1v9NKF87Q2lKFqAMesctYEtIcCJXRc+spaOvI+VKgIZ9rRY+JQlyYoTDmVgUwQjvqxmPVb +h+OSZPP84cxX7/R0VTrP+hv9PQ3U/P/51//7nMQ+sU6CRbQ6TZ7HJ4ukn0I9CZ7/fO39b+FmDwd BevfxHyZtlmJxhfqg2U2hG2EQs/KUJXO0qGqiGbWL0X7vqaBbUOoGLfIXm4rW4GgSUsWBS7R4RYH JLmMmgDRzMz22qLqtsfU8oaYTCcxZrY8Xt57eb7z27Ozj7lxEx9s87bElSkWg8iMO9/4ezp+X/Xp qL9lFH7yoRqinfehKVoLncwRH3wNeCPgQ/n4MynCH/elz02sfQM09WkIHjqPh1cenu70fnuge07M x0N+v/mHnT1muRzyErre9fAStv1+42/nQmtuGVxy8I0jaBx3MpT+xBH4J+6/OwdvmUGraNGc7Dpc YYGm/eaQr+dj/jQfk/qe25CS0F9pfrli6/X59IaHN3V5Scgbxab53Vc8eQrsXwt69VZKQX7oWmLe B7JSXRBNv/O9oon1wSLvJSUbX1BXMUeyHytPrfw62/jtKcdbGPd9FyWAn5w3r88DgPvgg11/ZYu8 N7sCBcSERnjtin4W5WKEonMdPpQ6IIq0rUUAVsyIm8qSUJICmpjJXltQSTBM5TdmOQyA691j4aWF pxtdOknvqvuNLYgem22Vp6vq4k1H9qPrfrNf+SItryIEURuU8soY/TLKxi9POXfxW6kNogmL3hTQ upDTgLhYjDGKyMtT2HAwcXUwmEymkxj4po+Xn3h5M+SbBtj6oEoQ3ehtET1k8Kes+GDbX9nSmh8E KCImdMYrV+RLIRl/KXrxlWjW0U2yhjY0mIwRHbxgUQM0y1mEuv9/WvrdSPV0UQ/m8gC7SBCOwd2e ppTMJafH3O+tRgAGmwnNDSY7V3+7agkV0bxc88u4qVyM0LPCDYcfmCCKsGRWgCULMs9psEUQzcxs MAS22nAEYJ7jCKn163Hx1sW7QcoKcMOrSkEoZ5GG3xZR4zm85/Q6aLujzNkX06iMvI1xahIjKPy6 cVS6GKx2CiNKFyRmcyoooIlZgt7RQGcDMM1xhHyl/50hf7PSb4cpb5Pvw50kSJiW2dxGCXGpGkS2 2wfDlAnQGKWUFtPdq0iqZaAURDNz1TgIkI0RWYcfS20QTXsFWDQjFBuNpA5oXubCMaBcgkCes5Aj 0Y+RJ0beDVQWgJtet7ggnlbJTWxbtAOkjA+2/JUr0vkqQZHiB0YBjmzRz6JkjHRbdKFaIIr0qwg/ VswI2ZozKlJAEjcuGE5cGAwnzHIcIYV+urN+XQ9vB7yj48ubva6SBOEY6D9H16dorzgS88Fuv/JF Oh4pBXFLGCgFOTBGvguSMSLL8FOpCyJpJ8AtU5zLgAS/GF8U0czMhoNJ2RpiMp3EHOp+rDy18nTn 0/2I+jkHPzkvj9C10QioFTuvRbx1TXuVvndZLvd9y0aTRe5gW6czwLmyy0aAIjnXgU+QnjZFcYWb H5m2324qi1w/TWmoBotl8rWeBREqfwl+MESQlli4XltQXEqv61sRk+gkplf69Vh4ZeHpPqfHSw59 z35ra4Eq6X+a5wtrkFXrY/S9y3K5z236b+1uIKSXSDV91AEXy0AoiIiUiqH/DRdPBFn3ZVaqBTwC dwK03vbT1TAYIohmZabXFjUXQ9QAzHMccaD3cfDAwbt5vvHrNAd9DRB9Ek86QzYIR9xOctAolzY8 F7jPtaMU8SUaPkV6YvWjXeSQqyRYpJOocaGePTtWK0hwdXBEkJ6YuWASAZkgmOgs5kD14+Khi7fz PE0pBZznoEoQauUi44JX6WPI5vlkovfWkt4fWl0yATDPI5kgmpP7Gm9zysO/ZRVOIiyf1ezosfoG xGyPN0U0L3PBLFKqBmCe44gjxY971r3bSc4KYJarxgbobpY1YVpme6+SOu7nuSqVzldC6XN1RREx QRkF6YnVlTZ4kKsk40pfhvWznj07OiBIqsXoUaQnZi6cREomCCY6izlQ/bh46OLtPA+TI3U4z1WV IByDLegpUTSIxHwwz5kApwAeD1vTaz91oPiRUBDNyzXjVEIuRugtI0evrQ8FYcUbPxa8AWRrzkaQ IpK3UcFU4rpgKmGa4wip8+tx8NLB27nOAmCuq8QGqMS2xi1TnG0/Ssz9XFelMgHwlOB+R0ZG1ANh VKQn5u8GEwm5NkBdGapDPUfss/cD4pYw6BGkJRYunEhKJggmOo/ZqX5cPHTxbq63nYtzXVU1xNEz IJqrnitTLOay1Tvgg7nOBDgElJJ7HvqpA8EvA6EgmpdrxqmEXBvS18FYMiZsivYCsOIGhBQHUwTR vMylcwmoGoB5jiMOFD8eHnp4t9sDnRM1424P1FWzIWwxb7PK+TAgHHO/2xsB+AKUbEOgEZPt7xQt nyKaNvpkP5ShYsRPOVf7oYwHLAgr3gRgwRvgprKYCQCI5mUu/VBcmH4nk+YwQOr8egy8NPB0o1dS MncB68pC+zMajYqIyLbKU6/lhEiPudjoanHXaj9KnUIoAx8j6kGdnFsOfZIv95ErY89+H30SZffz ggjVvwSPegAZv9tri/K+GLKGmEwnMYeyHxMPTLzY7VLwKuL7amSbvc2y6Fqz+ME4LuZit7d7GQyB dnczDTan2XjTEHCiNSEgmlnHQLvOGTa+4Kk3ulJtEE1HCsQGRVwsgyZB5BYqbK8tKsRk2BpiMp3H 7HU/Xp57eTfpPVHjnIddLcgagVOeejlkg3DE/YxvFetAMF3F7Y9dJYgvceg8QTQxl6sDynBtQJlc lcuBrJPqmxwtlamxVEGCq0aMIpqUiWA6tbJwOmGmsxgp9Ovx8NLDuwnfRHwPqpEQZfIausOVZZDJ MffzHbS2/jeNxd0uEvQ314ytJ4jm5c8GE8lwMaK+6Eq1QBRpyaIgTSmFAZnnZDQpopmZDSYSjBX+ jXmOI3BrPS5eu3g71XnvfhtCFcXIPFVnbus+TMvsDSI98MFsZwIYBMoojY8dJUjM9rKniCbmomEu IdeMeXAuqQdN0J4eCxakeDsoFdHETIazSckEwUxnMUeyHx+Pfbyd8Szie6ccKVGorHKpDgjHfDDl Va1MA6WU3tc2UyRVe8tTRDOrNzKPkI0R9UZXqg2iSYsWBVq0IHSrjUZSBzQvc+F84tpwQkGesxAp 9usx8t7I20nvCYpm0qMmRtw0ezPX3TLFuZhJz3k+mvTYaNtA2Le/ZFOEysj2fqWIJlZn2kBCrhnz 4IRSD5qgI3q1QBC3hEGQIJJYyHBCKZkgmOk8Zi/78fHYx9tJzyK+d8qB0uzwbZWjC178L/vVkiw5 bgOvMhcwQ6T4kc5RZ3CtWhvff2GWQBAJUpTkNzM17git+lU2hQQSH4KhcZSCuTHpxVseBkLJrS/a CMJKSCsywpZRGx5HyEaIaINfsgzsU+cBBC2IdWpoAiKWiQ1HlLAVRFkanDn0+9FyrOXVvJ+S8cni vFduEUJncN4Hk5xXCJ+5nvellWQsqN7ah4DqLUZYCOk/RsSws6uaU4prB7JAgW9m/k40KA5hwEQf TViXBpnVnieAmCUqmFIlMJhSaGd0RJL5iHgq4qja02RiLlL3qUx+Dexl66yZrMNCtjn+uKtWPrKZ bbUAFCunpV7CKeY3iRgIV7OmAOYqkl1YnS1IClEhbHkyaQ1aF8VGVyB/91JfigjkU+9BjRkQm7zy SRC+/5jtvZ9aoldsBVGWRmeO/H60HGs5HPNC8HFi61xHSnSUvsr3UuMmnTip/HJngK/lclPKWGy0 +nvy+g0hCF/RqEq56hQTXYeiinwpAvACgOFaFSz9mhY9GAQRm8RDdbOurka1AYKWRmc40tej4ImC F+Pd5ovHRRzv1SP+HUwIDoe7NzGtCJCNO8Nd9RS9XfpWZ3OIuGlRXSWIWEZZaPwgGyH8HQwkJQH5 1HtQRQBknoPySRCxTGwwkICNEbQ0OnPk96PlWMvL4U5ObJ3rSFkLvX41m2VqHaVgrsc7eMvDALWx jTK2UYGbkRGxKrrwKEImQkQX+VIkYH9afgyXfodFD0tBxCox4XhCsQlBS6MzRz4/GvYaXo14Z9bZ qhEvPjFCZ2Cm22zGI8Anbgx56hscAthJ1PIoCyMsg3SbSMWWfbR/6MGEbIQ4kyzfxPwlikA+1ZCr B85MYVGINYteOisgdokLxxLFhmMJ7IyOSDYfIS+FvBzv5MHW+a0ZxUv6ajKz1ds8n7kx3sVZHgVt 6yOh1RpQF1ZAbFLicDAhDyFVFPlQ4mdnenJbU2L32NcYlTeCsNVChGMJhSYEDY3OHHj8yKflu5jq 02p8LsdNhW+1IOWMDPEpL3E+IMAnbkx1Mo+NjxpQm2MDMTKtfB1ykzHCljlkHEbIRgh/91JffvjQ p84DiRkQ69SABEQsExuOI2EriLI0OHPo96PlWMur2V6cgNkudV4RdJS+SsYn2zhKZ27MdvGW5wFq Y5UL/NvZtWlGRsSq6MLDCJl2BHSpX4IExR8VsG3Cpd8u6OEgiFglJhhQaswQgpZGZzjW16PhqYZX Qz6asC445MEnRoJJDjf1yZsl4C5frNwZ8qq39iFw0PJsDpFZLVICiF2UZR9CiouQ8hlMJaUAOdTT VwUACVNUHgkilmd+8/EIEjJG0NDozIHXj4zHMg5ne37x5k0tujlXLF1V+a/8pfv8B9W7M8FnQuez LZoS+S8b6ke/OjOnFa/sE+GSVzFkDCbHohgFccuqGAWphm1uPhLmBpcg9Nkc87a4zsqyzQ80P0DI w3eHbcqSKJfmWSkniLehUZeRlv+t4me2O6rdYWuzS2x+bdkYIduvJ7W/Y2oHY6Hcqs6ZjG8HDX40 BKJxMV+yLmuzqAcYmTmdCndiLusCMArCETKjIG01fb95NLYd1ko0fhGh4HfwTokrSEv+VuEz1R3R bpAJkuIfautTXIyQ5deT2N8vseePwNLc8AiU0NhH6f+yKmdksg73mXrm+g0oM4jjq4T76wDo+HeM S0PPiNik+N9KgRhsQxT3hf7V6rQdJLbsdxArI5NJa8DdDZA2IW/lNkt9Heg1EyPsHzyUVFIZIduv JxF/fyIGb1GbR9a8f2rntdDr7jnosPL2LB/96sxcvEYvAs7WF58aPkJqgOKBRKzT/+0iR2w7rJDy 8BLVGLH5X2dxdAHS8r8l+Ep2R7FbZJz7msbdUprXho0Qtv16svqbZXVw//Jmk+dUCOXBAy8g3Btk 1eGhRh/96szcWsnzEPZR7VKE/FKIdZTP/tHVPN46x9VrziWnFilC9OQXCcrol/AqMM1RrXbCziod IeLQneCv2cVjRsQuCUZcfm25GKFTrycd30rHoP14KGCwZAzV170lW470qLZz2n9M8JlrKO/+G0en 8AnCAQpfK8Lnf9rNa0hVf9M3R5XWStkm7X4ieetDHRnhKFjZ886SU9YHdUkQQgpZqwerIGT79STj O8l4jTbhcv3SxbbBnoFqk7bSany11utQm7lYhNt27/PL2wUyMsKzjH0QpK2Bu8rgKfapzw1tV7IA 8G+3rGpnE6TN3Vt5/Ylsux3rFZcgJQH7VwtcP5tCyPLrycfX8jHoP2fm9Ak/7wXZua1vpaNu43en M4leGdrKaf/diDjbT841jIyUCKsPEnNbAd+ud41tfY3UhwTLhIi36jFWgY78rYIvVLckuyYToORx txNty8UIWX49af3d0jqYBj4vB7Wxt4PGPuj9zBI/Y9bmgAhRVs6GQTUvATsTVq8Czn9F5Ku/g3cN HSNiVrS9QyWIlCOpLVJy/EcINg1im7LESua/9k0KlGSAA2FtBWnp3+pUDHs3iEYfgDTywWFiBSDL rycb38rGaBeGRyyvHflLG9RlzOu3IP1LVNu59RIVyvIEkUWnAvwC8CbNsxqs7OYRQk69O2xTlth1 fqVgwIzwkBYJGGn59aY33uH6984dtjYFb6Uj75Vim5+jMdd8I/U8eow++fi78zHsQt1P22HPsfk6 PupjY9yXJ13YU7K3kglBOKc/1UZj22GWS5FJfBXg/UUkYKRlf4MsEhm/tyQyQTiyG2RtBt5KRpdc Q/ZBSEbnQyM1I/IofRLypYQMu7DfutlY33N8Zfcv1X6hHzfhV5URLDg9nwihMrx8enRPGrHC7CJb j4g/d4K/4j56TrFVuQcWY21qmBiRBnyS8YVkDFpPd9F21GhsvS7LzQOzb8XTxvuWsBrTiZahQlJD rAyUrR/kYKSlf4MCQraaNYVGJUbY7TtsTTreNzW8JheXxR1dRsS1rq6pD0bo1Hfb5cnqn8/q8SjQ bb3Blzb/q+/ciiSbvTsbDiej4MvqArQdFQmpjbHS7xgXpSMimvh9IGIGFp8wJkAkaddUOhW6OstN BpbpJvucWaJvNGaE2F9PJr6QidHqq/tnO2yxEog1k91FTc7MCQVrm3Dcc/WkqGJNcup1C4ioQrkX FcTLHkFdqNYI2xRC370OJKgOQHwMcF390KNsKdo2fkKq7ZMz0DOPkpdKDmte1e92VOEcyKeM930h ZQnjqtqi6YKTou/4soerR1kE4CLgBq4iiJMdIKIoaFNm5MKkDGCwhEwmraEJn5GG/N0psu1IXDSZ IOz0HTJG2MX3LQ3vsIvPjIhdmdwuv+yi5mKAK+tJ6u+V1MEk6MPtO78gdjUuBkU4ng4nw+C7CvNM JAymZA5n8qnUsvjEp8QDLihGkG/3qVpCqXqExKMaCyk1ChAitsdn8L55tLzW8nLzoyqGa1DKmgC7 mHm1g15o++Wk8tUtq+cYC8NIFYbXg8y4OovLQI+ID7Ce1OgYydHY5EuySoAUDrgEAQpS8lBdYkPi 0hFC0tEcT/PaCLAjkOPhGcjno+S1ksOq92b2akXtF7t+vPNHIq8ys1e9fOdMDHa37U2IFcCxBux9 tx53j/jAnV6si+MVkJuxnTMSW4vgpPPGB4duMiCmh0dk2/lr9Pg/i3xYWGpWbgeFK0gyM47XaLyL R/P2U1W12Wpnde13diaZaXHqzIf8/ASGcP/MHW++7zGMJm9iWlVmCMHMzGaZcDe2zqyzRYC/UbkJ JgSn+IOZ56B87M/kWl+SOkP052fu2PmZP/+Ez5Afm3vJq/w4M4VF5Wcys1Xp6ACy0uSHDCF/Hh26 EPsjuc9jVGfQQz4zre7SzvWZG+78Ax6/RPkpt5gPed4tuYH/lbfVfMv+59+4H0yr8fniAjv5G+tU IRycScYFFVdGfFLNPEUzL+oIOfM/Hrnjzfc9fslzVS1PzeLdXRX8jRzRVk438XIUVv98a69e7TwF Ucvhj7a1m1NaBwQ+qRAZET7yCe8EvmR7ZC63vDN+iU38OyKWT86wIq9HyRtKXm7issRrMY+rvHwF z4p2OT+p+59skl32oNEaBJ9Nt5QRj+RUcQAfH/qR1ucOZOoReTXJKivR7wjYHp6BBfjR8UrHYc2X Jwe0pjVhmuFNwL9pZYJnSj2hbZzWOx+Vi6W8i6B9BJl8Ki4k57Dvwcke4UmQM20Z2eB3NG7iusFQ 0BsJjX8LD/nCVoT5CKHL8S3vSBU5IWJ7fIa1eD0anmo4rHMMDfaZ7qVbX2AHdd/IM67yYku4Fo+C yG+5xuiqq+HXi+0IqYLUy5aw0dOJvgvGe6/8IYQ8SvOqPP4v+9WyYklyQ7+g/uEux4tJZ8YzY2vj AW8GQzV4Ybww9hTY1N0YM/59nwiFQlI+bt5qGzM0RUNRdVqp0PNIor+HllOJg7P223H7alMwhWg5 cM+S/M327ye246+ZJXsGEN7YI92EJ3tMjJex0Q3Qe5HdHw94QEK0R5iBeLZp32m2ieZzGb0Zf0bx URRPa50XjtFse6rsgJuKt4uUiFgtz9yC6kHei/SxyYjwBHEJ/Ep80xADHCFkluYSwjSXIGMrz1y2 iYaBtknGgyDCQWQTaxILjpB15urhfVJHgBAh5HMZPZs/Y3kdy0uW5/GwreGjOudvRMby/jXLf4gN drlTRu4R2aSeicrWGWWR9s7O633mVL73COVbMZTxnhDRfS5zcHl9xvEkjpe3oDQmb7zcUIK4aY6r GTYiY/U8dQ/Kkzzf9LnJCPvN98Ngo2HWETL4aVwvg58G4qa8cP1Yh7RN2kVGOvcMm1iTDtUeoUGp NwUdAUJE97mMrrLPWF7H8vI+FEN3S00HFny0NYF7YdsvqHw9lVLhBYouEULezZzszw9kmVZezx4e m2Sn1q4tZ6RHb0zTrl2M3AHs3NuL3Ec6SIRIXs5ljub0fxWRX5jvl3uELkvLkEcsyl/td4snePVr Js6eG8TMPSIT57zrhEH4OzyatTntbz3atcGEiJJzGb3yfoOuX95mugE2JNWBefKLvc1ExGp56jaT B3lP0ccfI/9Vx41+J0wzwDzNxW2uiSGl3mdaZkQ9RwaxIjHgCKHI6XVPu08Iq34goufiZxwfx/GS S2Xt2FbvUYXzVyKzZdcnuFSeHB0szNwBbnqOlOw0bNQRsr9WZcrsArP1Rhmk3Yu65PapU0HasYAM PSEicZ0Q0XwuI/T1GcSHQby8yKQpecMUPu/IXKbg+Vygr0TG6nnqIpMneTjqk4+Q4TYv7HAjJbMJ 7xHuSn1EEKaOCHjjlrI5IkRKDOAOZ0S/12wamnSk9gjFTs90HQBCRPe5jKqwz0heRvLyHKMSlsVG VXkHVvRxNCbsEBk952Vv9iZ9SehNipARmK8df2r+du8Yge2Ly+a46R4rk0wMGOl5YJOGomHAIUKB 0ueNDkBDVI5PZVQ+PyN5HcnL5UZm0pa4j8idvzpfd55Ybj4yBnekJbSyAfQYfI5XWdGco7aGAL1u aIMJETXnMnoH/wZdvzoUTQts6LMDCTsOb/v0jYhYLU8dikLgvDzpS5QRafGv6jnV9BXTNJAmv9oL R4TYAOMhI/IcmdQVyfsHAEVOr6Da/YaI5nOZw7vsM5AngbxkUyHibf0e1Xj/Ssls+fUJNpUnRxML N/chxo2/S55K+R4Zo++pyIhFIjUMkPlhB+0+dypMe0QmH7OR9p75iXU/kpEd4jOOj+N4dTCq1uSt OE8h24MxYq03M0vJWD3PHIxqtPQhaS5SRuReoJsiTy4GY9YRQmapO6dj+s5RBGX90SZpDxmR58gk 5qPx/gEgBNUnuXGfENF8LnNwnH0G8iyQV9diV6e2G1lmOhCmNZ51wc6oq2tRhYXPBwmLID0sXzcA 1fztvg0kwt5kvovIYDT2EKKON2MzIUPPAxlJwTfq/NUWYcrScuMRf/JXe0TtzrrlvVvVVOnAY+7Q bfFwHVHToKvX647dCg/aWbzbI8InfUQpOxkR3ecywmf/o5D80px/ffnNl5df/xBvy+3L2wvQFeU3 4x9+LTcfE+oRR10MaJQ69b/cX7774Y/p5n715R8vv/uCFMcUqS7xa/SU4eCnnKoLflrAXXeDlNyc innyczZIgpn+BKl63neaqV43H94PlRMS0ZezD0r5EQLn06FF6jX+bp3m1d2+R3PncPvnT313q9tT 13NXwHhqRWCLASICnA8RtsaqJWMgNIcwPsOIC+n2/YJVMXZjWA0CEOIKcwsKRpu73Oq/mrewEtlE FEylqvtLACHNMxCseNnVsoKOKbg0ZN5FBkVVcjV9q+fBzELNtkqM2Cpjqf1QEQ8nGKnqsHEGbYMA sRXBeFAQpdfnFq3n3lIIfVcdTsG8xiE4RMjEtx12N5q6I/yahE4hOUbtiSC7999MBPpr11F75i2F kIWmYLCclFQjmqc5toiiSFfrYq6T9ACgT953Sh5Vy+F7yxqNOo/fzIsK6Z6LlQyw4jStnstlWJ4W 194SPRUhX0LRQReAY9yBYfCRRHsmTSVYlwghc+ecNm4Twva+6rSMAskoirXJY5/xYSBVZyUu0Jhf 2uCohizgEsTAz9wMGz0tMxpcMSOqcmw06wDOJ3/IGFdzGW/eGxJqeYkVCnHk/NCel/53SO4Y6FbC l7owkXc+bR7q8dIy3RogviwmJoI4Dgn1ML+uwrEDhjnAoo86IQppn9n8oTGNMP/NJS7ZZKTyejJx 3OV3XwPmnZHdM0u51LRML8dDGYqClHVqC4KU9XmZWNPvDfEb57wuEVHdnx++7pHBMqYee5WwXq6R /1/FXrfVR6sI/VzwiCuNae7S4Ms6rXPjr7pqrhbppvWv3rdqHs7y3YNgssptSpkgbg26wxYsqTF3 pPXlIZJytB0OLKbU6bl4QSh/1h2JqpgkQLdI6envA8lLPEHEouG+L5unKkDe400boA7Q230dT7SO o/agu27j+G29hYitbcWRGwq2cY98YRv/vi5fkP7ry3e//8PP6fbjX/71959/erSdh4Df60bo09Su zhBQ77XGM4rB63g7dA8hxBQuInutxK0Oog7G4LZPbXscSJ6WJeq4rTiDnDMIDpiwat1dD1UcHEhx qW5ghyGWsKruj1SVuZ+3gmDjc+XQpOpLQurq5h/AFj1V4Jh6UoSEgi9KVfKx9b9GwDUzLTtWT++e o6w4tCAmenILVpPmDrQULwi0IUMrrrHksOyRg0MGZRDbi0PPHhl6cEW5Oei3IrgLlaVkBjL0jK8E wUUCdlT2bDTT1plnSkEvekaQJu9LX9/XxR8hpZZmPtBzHMnX3/7YMpVwICW0Syi5544Rl5ud6Lg5 OtiZwNltPClkpomBuM2pNGQJLFPVdIBESqCw5XZ51hS54AbSSAjY7Hpw17SRqkhNJI66hQI30245 ECyXtI7V9MMhi7DmlPogGRiSglTcjaaKaLtFhi3SMuT+kGH3WeTVBKC7xkLDMwHIxPqNW40b6qkt wuF4UxnSbzHSdaMiXQo6IbEWSbAJAeaRQKVJSXWzUf+VMlRCBjKsrD2C2tOIaB4JGdgIpNLUgz3s Fhm2SMv4LCVyV8h4X8l0zz4kM+IYIxaCqOOYwrTMOo4h+fa9shkyJa/a5qFHyyxz2MiUxfg1EImr yHDGPiIz/AKLzH6w/30Aa7XKKwmZKgyA2XxfKsq0WpGZFiuZavgID6tJJIDzneAKRAUQpWTIW4NK HcxiLSNibv8MIoGtre/Q3w8crsS6PCOAlTLj/5DDAtprcR1AnFypMguW6+qNFqlbazYyjLgpzdF8 Vam9GERrnl1+8FYbBMi4u/379qe2J3lcaLc/z7e/vWA/ndaIAqh7citjQbC0r3SFLLVgsMVYqTrX OvDegFKnIT7LLfAaIUUVybXPFSKKfSwtqXNjDJjaDcTOuJqXB0BfLBk8sK7N3dn7Hv20LgPhFNU9 twUlbKUq8q4QdIULXfc6U3BpostrR4hL5ENLSrA2YcML2qaKzN5axIi8fy7jpmDVoGpCORZhaxyO oWKsIYRklrialxjpal6NWyLkUjZBZNUcDo1wyKSKBSHN7PqbwZZkrG7AY6O15nMZDvO1zCsKM2NJ xE8cIpVSXVtLl1QqDSQcipliawFoTzhc6wpar502KAVJaITmScJpUcvzAMmTJwCTAmv4AYB1wTc/ MDpm0LhG/LQUdDNY0LvWcvWcrNwkCE6XAHZIYNylNItDmMJyiMhXWOUT/k8hHkzrjD3Yq0pdPwwy 1wE4nKhr1ay9qsdCjbxEayAgFGK4ej60GB8hy7IaxYLw21hKgrVPEPYBUWp3GwoOzOOPECTaZYpO rZZikNzaPNVME5dHnIppMQioElFRX+Ha9W4xCOdvvF5XiLqHHiDDi7rOr+UQGdEY9SUIV+WI6kCw yCSqnl7cO4CrvR0dCH49OtDi9WdsV0dVFiv798TeFRIwWvnBMxncuiV+WIba6aMyldRskFBeNH4g k+p47AjJIGRGjyCih5BW5ccinCHULZiLZPLqBkIyuaxajQBLW2deD6JPNGXJgr6da/kpsgAtz7o5 FUDqtZWMiOJ5icTciVhTPyYISUnVrs1Ia9DSuYpY3OphhPS8KtYjJro3xNXFW7FeGxna1wHs7RGE 9S5z7p79h/xyyXFdyYHoCu4eetwDQymlUpnr8BIa8Mjuyds/0JT4iaBsw1W49S7w0BMDDhwx/2RQ fKUcex7LFaU4585auGg+s1Yuf+nEiBMuy4mpSxoqBB1pX7vYGjHWnqkfh9LkaVLublrkeTeg+Jwx H1cs8u6oe7HVW+3Y7fwop9EmzRlUTZwRg7Q3T8TII9rvFRj5ajsRW0nrciXmE/mTonTJ3i3FsaxL zCY5fyFGdnFvg/o+mjj77aj/8t1RPUzR0SbJybSvrtCMbDRSPLIYydVeh2il6LxHq2k0Vfbv5MZk RPLWMidkkVfaElO1UBIjN2YsiVnEreah5KCnkhjx6aUkRo5w3hIjB18GM3VoZiRmUr9PjBxiZ0Q+ 6ltallTOMaVlyUdj9BNzVNfE7DkjM3uGojN1BafjdRu3o2qupRtUxcf2dOfrnvp7YuCXnFkv65Tu fJWNX9Kdl6/akhA5rdoSsly2dTsx64rn/YASy7qmSKBOacEV2g5pM0dKAmF+XimaTG7JCloyo0iW zMJYgZGjKv3EjGXljEeKjR+WjeNMtZ7iTPYMEUeVSO5hBqP8CHPkl6g+4SCBSPkYZ2YpqdKR4kO9 Z6KKhn+N6i9MnReu/sLUSsUf/732c5hg1jrYXkPwocVHbY2tSBjuV4q2J7dDW/fWD76HFHz3E8z1 aQaPNG9rmV6spF76NLPrE2Xt9Y2iDcft0NqeN+ExScF3v8OE5yXFOsgfZ5ZLq1ta655X8i6qwueh Hv+RFI/znpHasdXEaDvxjvHWrvc5XVhV6NojjAnlMk6t3zSN9HRU4SeozQ4/QY/yibg+tZR5JDSZ miK4yXRlmtupEXXFI+tYt8TILnF+UoHTnA71SAqG8g7XwkS65DiaZDmOKlIs1jml70meVknpW5U7 lQEwXgbAePkA42UIjBc07XAfSdH5UIlLlEfalTvKpzSp8zZOytRSXSYFkXW0W6LKRsVb/5MFAGAO AIQZCRDmI0CYHQFhbgSEWRhb0CMpPn0zR4hi3oijHBaLicNhgVCfBsBsGgAze0G41wvCLSMIc4wg zHiCMN8JwuwrCHOvIMwEgzAPDEKdNAAz0gDMjoMwN87EYeJBmPMHYcafiaPLAGHNCgjrVUBYg4Oz JcXO1hsnRDn6Jo9xRYuGZ+HtF54FKfa8I4yPY03cS0Wf0i2NZY/Z20E85mgjwXjzCcb6Wkw5BJtf tKeIssh7WyjKvvYqs+2cyESZe+NsTIqlSIrkoy3ikesbRffwdkQq23YazRWPjRlZ+m1y2xpnXxGm NWVxUjTM9dB6SaWnNXnmKFh3UqykYSjMZtT5jaL7czs+G3OqhKEgsE/GKq4MPabOFVeUbfTThFWJ eto28QMzl3ZRtg7lnhTzDDGWz6ZdWh8v/vvG3I4obTuP5IrH/czsc+5yNRs7H1GOVGjKPSnml16s Amt/VnTttyPSumfVNJorHvs7THjDbzHhMX+cCV/8LSb89beY6By+xUQvEeezl+0tnbwqfIcQBwri qOI92gvEr3B0g3GBohuM5xRhIEQ/GC81Ws9IEqrwe/IWkQRrEWk+riCwdrmcODAYFKWQcNST5Ant CmdEjuOKxuFkP6Q0rCnZq0IZEGsN4Xk+UDxumbZTquexXFEKJUIKZGmn+ewKlzEwXnyYqUsaKgQd 6Yqi2qVAjcGF15Q7lVnsBhSfM+bjipdr6QC6JyEr8xJ7GuU02jSSPSDGTAYxZl7AqO1IxGF4sC5X Yj5hpCiKOSmKY3aMGPNjwVxh67qUQ+lJyPmZcofTw766QjOy0UjxyNOlr/Y63GaKNlpNo6kCr0qI mVVCzPASY46XGLPNxJhvJsbMNzHmvokxC0+MeXgw3ggQY50AMdpNAPF2ghBrSYixniQxR2OTmKOz SczRDuFMXcHpeJuF2+F9Fm6QN2vEWLdGjLV8xFjPR4z1jcRo40iItZuEWJOamHXF835AiWVdUyRQ p7TgCm1HkbqRkoAo67a8UTSZyIWu06WNwcmMIlkyW+Sg5zUxclSln5ixrJzxSLHxF7kM63yKM9V6 ijPZM0QcVSK5S5xpP0SUn+Vonaj6LJu+SkKkfIwzs5RU6Ujxod4zUUUXuVNL4TovTJ0XrvPC1Epl Hv+jylOYYNY6qKST4EOLY9oamw5RjjzyUtndzHHqoq1tY4dDCr77Ceb6NINHmrfO6dVK6qVPM/s7 UdZe3yi7c9S1ydPc8ybcJCn47neYcLekmEv+cSacfax1zyt5F1Xh84gughSP856JLoYU66JeMnqq 86X3OV1YVejaI4wJ1uXFnY8eNJ5O9KDx4KIHDcWjfCKulBCY8ZG0w0SKKFLA60mZ5pZyDxSPrGPd EiO7xPlJBU5zOtQjKRhK02WEiXTJcTTJchxVpFisc0rfkzytktK3KncqA2C8DIDx8gHGyxAYL2ji NjdnXNH5UIlLlEfalTvKZ5PSsI2TMrVUl0lBZB3tlqiyUfHW/2QBAJgDAGFGAoT5CBBmR0CYGwFh FsYW9EiKT9/MEaKYN+Ioh8Vi4nBYINSnATCbBsDMXhDu9YJwywjCHCMIM54gzHeCMPsKwtwrCDPB IMwDg1AnDcCMNACz4yDMjTNxmHgQ5vxBmPFn4ugyQFizAsJ6FRDW4OBsSbGz9cYJUY6+yWNc0aLh WXj7hWdBij3vCOPjWBP3UtGndEtj2WP2dhCPOdpIMN58grG+FlMOweYX7SmiLPLeFoqyr73KbDsn MlHm3jgbk2IpkiL5aIt45PpG0T28HZHKtp1Gc8VjY0aWfpvctsbZV4RpTVmcFA1zPbReUulpTZ45 CtadFCtpGAqzGXV+o+j+3I7PxpwqYSgI7JOxiitDj6lzxRVlG/00YVWinrZN/MDMpV2UrUO5J8U8 Q4zls2mX1seL/74xtyNK284jueJxPzP7nLtczcbOR5QjFZpyT4r5pRerwNqfFV377Yi07lk1jeaK x/4OE97wW0x4zC8w119SCcRRyq84Tfkd87/++s9/hZRurKRPTeB9471lhe+D7xKufT5vvhF49fme Q0FWPL/xyDqwD5TFXfHMLzOd1lR/oaCuuw0xG/SsYHSyXK7AzMFbukt0JXvU7I+fFdtV8uFnRY+L lH3nSuE4L5Vp2Xg+LxTZb7FQtK4XyizeOW3YkyCJdPTkr6D4vssOzjWdHxSvqPFVnDoUuxkxuF8e CJYRsQK/g6TYXcZuhbIeb+UeT+JJiFO4/fvHHur3ksLvJaA9KcjBSzoo83z8rpYU/mw6/bky8OdK 16dC+rVy/Kmo/3GP8cn0fMk7fbZgf94WfraqXzG8X7HNn+33H24IPrQnX2txPjdKn5utzw3b56bv Y9/4ufX83L7KMU9pKZIrSmFCjmZOS5EzLryUOjQ9ghDTVXmUKpvMpyJf9I2XIpZlTLwU+WKMngk1 NUTsSTwRpc58tqTY2ZIRsijiBVZebhTxIMRRbGkmsstlZmK9rFNlQnZ5Seutl0bXQx5FlZOpjR+F KP507FFImG3FZc2KLwhDuYLI+pRuh7bmJ0iKPTjyf/aYaUb24Ot0aWMkpkgpKMyQa3RmEr/RT8xY Vk6IocR8yGta9pU4U62cfhdddY7jiqVRcqgWZzmOAWGuT6b1cSh1XpJp7eK1kOuz8jyYKx5Z69Xt UJZST2OpYjXtCwQMtFVcmq9VXGFqZYPggseA5e6SRxVY6whFmbVtKQgU8xShhIP6FhOeahFf2NVl bWszpm0tFGXantDgGEPhOO+YcJ7/h8zz/uAsfprBuUPx+/PTjN9mEP5mfpbw9wzFU853GKQ3KJaS v8Mg3ZNiVe/HGSm0PZ343jNN69/CaJ67J2Vdyt/CHOnwnoS29n8ysufUdANF2Xp9yxz5tu1Z1nPy kW9NobxNcVzZ46UasbdZpfwWo+61XvrkBeuoR6agplEYEyQHlVQZRRlzquSmUH3d+7Jl4/pKcd4z koPqyrVdvppW3R1zBKaQIyBG7Qch5ln2Zk5sIrmYGOr6K/xQoizQLtxhkOSzeZyEaUvujBSP62Pd foUb00CPJDwHKj3ZPFPILhJjdpEYs53EmO0kxsxqTIcEnQ45aoY8zpzdsxi/0ZMiU3dB7XQIiKoj 3QiShN8H+3sVuEcA4k0CGO80wHirAcb7FTDesIDxLkeXxX1PrMKbJ4Tx7onDaAvGjPZgYKyPA+KN HBBvBoOJbjCYaCnBeE8JxhtTMN6ZgvH2Foz3t2CWy9LSstZqeQZMlTqdkFWSSFqWKKVkptnjZ2b0 vCzZ9/+xXy05jiNX8AR9B629IJh/5tr72dQRDGhV8sb3Bxxkvi8lTYk1NXCXixiguxUTfC8z3zea v1bFshR2nF5c8gBpyftaUGzVcRCJ0GzQBeGgA6izi1bpUzNGUDQgJ1dZAEqzLcQAVPlkRdz0KS/x EcBldnV+qMrxf3dVDiTn5jgo89QdBxFP9rjymw6Hf6UYnJGEUkzOCBpmz46DBFiq42T0Vm2uN4Oo L4yG6lo7xmSotrUDmItr7YLIFFmHWY7OTEW55p2dHt00EkTtFMyuYicf7PR5sZMPSOuLs8MIT741 K7Ar1WjHLJC2KPLuEJrfxhvN0HVDWfpDZPgfudGwbey9McK2X+PwqWl/wH45epHsD0DK1otknxFE 7TznyO50iCN72iEOr3u/JUWW6SMU2ckPcUQjHOKI1jjEEe1ziCMa6ghHNd0RjmpDQURjHuKIVhVE NO9BTj/M6D0cZGDyt3yYg65Ty2FOmmpuhzkZI7sf5kCBxXByDrzhX4vX24blVHesbUoQ8u4Qtk3T zmQQTZuHyJqbbraZfFVEv/uI83Zn/ebONPw9OiXNZKkxmr93v0fdjjPTRmBqmRH+ijYNMOa5202D ELOxGCuMDCtvzo562jYfOY8i6ntdsUxzovXpIRK3oXT9JWuXaYWK6HfbPgckpGL2OQLMWmjMKDLM vDlDytoWTDmSRdg9Laqmf9Oi+hBJLEd55QUWq1t5CdG92QwUAdgybd/GCm3fxgpt8YZDW7xw3hyL nZGGkFNbhPyTqpAZKCriEbJO1+3uonE6omAkzvbTyiSZyAZhuyy3xAarLbHCok0YrNmEwdLPMIby M4whIIXB+lEYpEKFwCJUCCxlhcFKVhiIak+WkaayOCcI8+yugl4RgmUgNNFdBTEO9iq501otjHlq 2XrJeGQbFXyxNHuVjAec7VXwRe+LZ8wpeUaIxTNCjja2BqHY5or86tZKm2Kx180FdVgsoyJJ3Unw yiFaBtb3OVsGXjm5+0JMmPRAUWREJldbFEC4dKgoYKYVTVaP8IXUFSNqeZTSdcOKL0GDUMHlgBJM tpjNiajg8wxR1B0nYBQEy0mIbXRNAV/1sOw4PblFVBA5T0IGlGi7L+zMOdv2m8atvR1GqI3Cztxc F09bGNQMwpHaKD6dPEByTHbywFDs2us9cu+MEbY85tV1Q1a94n0NhGbaCwwkZQp24prz0sRNmwQz CwIDbKOMbgHCgj46CCV3QQan1OaMKEI7hSCyQR3iyE6VsAEuY8tqpRKntirI4NS1oeluKIi184wj O+YP5Ny/j8biqzkad0U4f76aw9msDK6Zr2VwPSvCLecIR9ubItSSj3C03RuEpt6XczBoFxfxVTPN 5W/hjD737pCSwt/C2drhuwNqWb4zZe2pLgOBtCU/5Wz9tq5dlnvy1m8JMX3b2GFktedmxCqzQvhL nLG95mmZeWBt84gQnWnGDAHoQcFNRiA9uklOiJmvqy5Lzc5XY+c5Bz0oFzvb8dVcxuvQRkCI2QgM Z6wfhkI7yyrmsCaaLUZcvf2SfcixyNAKvOuChM9i3wFzc9uZQdgu+7r+km1sGLo54N5QWNyaR4hZ Fw2H1kXDobXTcGjtNBxaVuU4BhjHMRu1JbGd6LdnLH59cQiOzsBYpwVQq8PT1ZDQ8Jdu9/sBWI2g FBYJymGloRyWGsphvaIcFizKYZUzrmV1j9yCxZOaYfVkzQwJZjlDgymHdJxSWMgphcWgcEQNCkck pXJYUyqHhalyWJkqh+WtcljfKidNqbprlUx9RjkZc9pRCpqIuxaQEDynUvFbTl/8tfDuzV+rYlkK O04vLnmAtOR9LSi26jiIRGg26IJw0AHU2UWr9KkZIygakJOrLACl2RZiAKp8siJu+pSX+AjgMrs6 P1Tl+L+7KgeSc3MclHnqjoOIJ3tc+U2Hw79SDM5IQikmZwQNs2fHQQIs1XEyeqs215tB1BdGQ3Wt HWMyVNvaAczFtXZBZIqswyxHZ6aiXPPOTo9uGgmidgpmV7GTD3b6vNjJB6T1xdlhhCffmhXYlWq0 YxZIWxR5dwjNb+ONZui6oSz9ITL8j9xo2Db23hhh269x+NS0P2C/HL1I9gcgZetFss8Ionaec2R3 OsSRPe0Qh9e935Iiy/QRiuzkhziiEQ5xRGsc4oj2OcQRDXWEo5ruCEe1oSCiMQ9xRKsKIpr3IKcf ZvQeDjIw+Vs+zEHXqeUwJ001t8OcjJHdD3OgwGL4DTlvuls1aEFssjddgeg7M7EbKrLaidjQDZZq 53Hr+LvYTcogtO80iKeU7WJHzjEm/mHAYdxshOqOdzv50CKpF7PtGUANx7pbWOhMZjPSUxpkDuVV ZwLQzV70RVuMPrUC665v1hqDqOFxwOtdQMyWpQH5nDM1HGYa7SbWMdSdsxUZqeYzwuzfLke2Ldnk iCL8+ppHjKhlPZPPttuLtjXVRo7cZ80+QYc3iNA57pKWkfEdXuCy/veff/37TPJvmORb8N7++ceZ 7r+weWCrx58xbn+WXVKfs+Qss0+W2X1qnSV3TpgfkfrnhPl4wmB6zKs10Wp5mdpiB0xOeKgVGRJ1 Reap9n5hMbkiAQmzOkTE20DIjAJ1CmX9KCABx9287zFgvPtxnt7dgco8NaMvPULaEUiJzSJqeEi1 60u+DEIqMKNJ1LLdo9PvnOuD3/xccJT6tMQiD3bbnnDO2T0h29Vn/sCTsdpaPuApTK0HGwmDzLG6 gArywNuT0WK+Dam4dx3IVmu5THHR+942pMzZvYB+xydVhE9KQVSADY9nurpkoCR/JYXkOPz83u7+ AuypprrzxMiw62bKme3fJ9vNNPm5GX6OkbOwzjFyjpEz288x8vVjRCaCKCKZGqK/cp9qWb2xtlG1 w3JRrsEiV80o0qY5JYd45zRHOH1EEUqC6YkUGdpuNdXDcjGqzRi/R8jdi944sHxbA4BuI62A2mX1 +azpyqexbJWA6VpDF2TLSJm42xE8iSKgAB1B0qZMqZddlO6REZOri9yaZDdnaUVGjfBWMJLitiFp u4mkiUFiXSgrWnEnMN7uET3TfZpqwEcwX/Ovp2ZknybD2zIvO2+MDJYfBv+vKWs755mmv1manh39 f10eZ0f/JqVydvSzo3+DNH3S0WuaQh/b/io1cIY6T6ms74K/2yaWSsGm7+STdHSRLCUhZKpx340d 1RoNkjI7jvc+WrqAopCA5ODcCUKiBM5KG4ZIDon7Rwg5w5Ey/n0xUhFALou9qzFNYuwVZ2pYlOIL vgwyPtMKoItKzex/qxrTWGS8d988Ifs2zTaQd4eUGD7p6cmMMv5ropQaD7YBW6XJi8kZDYnOaBA+ I5aC1i9GrZaKXApPkJFl1zvs5ixpLn6UZJqt/aHv68ZJ8z55BzK+cqPgTPXvkupmtv3g9D6HyFlZ 5xA5h8iZ6ucQ+Xx6S+MfWuhmhoPeC6+XV03FUrDmaa5OCNUI/bqaFrEkZhRZpjo7QbVzvk2LJ2NN qKIGgbQQ7CHgMqVozFmE9SgfSxG1PBTb1UR7u7ENtjyBAiG/7ksRUZ4v+OK46nMrQipTYq2I2h0n vJowdfy95RWQkrogn/emlsP8bEEZ1cZv0KcY6u4MK7LVm2HRSeV95aSoiV6SSyhF5uBXFEXUMp/U slZLtxdtawbSK9zl0j5vuebqHHe5zMj4zg2VM/e/Xe7b6XLm+zljzjo7Z8xvOGPOjP92GX/mtt2M WNeJTsp9qiVfjE7KUItp6FLSSXmeau8Xo11zQHKsXhDdNhC2o0idQhkaM2bWt9b7n42WvExtuRj1 CKB3RayGlZMbhLWieiREDQ/JeX3Jl0FIqWZ0h1ouohXxO+f64De/IhylPi2xyDvetpedc3Yvy3b1 9T/wZKy2lg94ClPrwcbHIHOsLs6CPPJmWCEV94ID2SpM8mHc7LYhqflM0+/4TIrwmShcCmiidSqv uzR/JVnkOPzQ3u7+Auyp7B0Vm3BOmJxZ/Y2yWhXJz87vc2CcpfW1pfVEhPzsMvtwjJwZ/n0y/Cfn sll3+BFE5cioEE0lY0B0nigYFp4FSjQ2l3sZUjA6pE1zWj9iSbt3/qezw59qnLOV5s6pyFBxa/r0 sFyMPpOx9wihQ7zojUMsr2IQUnocdAXUsApNDvv2mDbq8roKoI5edSWAiMzPeEJkWy5b1P7Lfpns NpIcYfgJ9A462gcncl+OM4APvhlmv4ExOhiUDYzt95/IJZZkFSWWmhLJ7sIAmuZfX0ZusaUrYbrr NaXfrDzCoIJujiUsVWWOrr5KGV18rKzwKfbLoBWI2ZYKr2m+6tfJQfrlXzY/rxqVU7fqs2WdT2ZD pVPzy2N38cdycfH62J19ryN7kH1CkJ17h+wBd1F12d39sdx9d2zREEWnTKn1oj+rYN4IN+HrDjTY bs/BEOBVMz0QqabQ8yx4GP8sHlFkhp9VCarLZOZk8rdqyso6HRQtJwZLZbz/Itx+8m0vsOahuBDO KH2/L4sdvzbFOTstnm2Pc7pkNmE5JX/5bELp4zgexhuUIuj0t3iTBgfBFKnQvzYl5CBLv1CCNVeY Kbp2XXg4TWgRRqdDqxHQWI1QcDVJleCaY0WfJsdaU7rzvSy018kSOu0lPsWeOJTF/C+NcvrUX1Hp 4w7vxOHu33fs3/wu2T19ryB7hF09ws48SvZou6Su7L7+UL7+03s19UG+rjyn5wCv0OTqvB68QWtL ylEoFnZZT9CXWk3SqkKjclLarSoZXki6NKWonOKaUgKs37XZrcp+ReAxuIelQnNDmfKxQFrrWN+o V1nH8fvYvluxvFdWYEZnBtJMgOBNQ4qBxVhSjk1JzkkzqJAZcRBBGsGVwHd4WMJvcN1c/ZMVcMoy mTAQ3x0pcEuOlMpklaHm49G9sgKMjf0wIUoi2CleFTPZGUpnAuxN2EFlaYfXQ8dL66nBVZLcFim4 LXGVYezbBs8nQ99520jgNAfQ4MAhCNA94eyiH39//637WKj3AREGtS6X+FwH2PqxOgpMVmy9U6ds wXMztpDSz1YEySsLEH+5E2ilqAiRKK105dgWWo9aWBnC0kqCuCiTla5IJsBR5InpymxH63BipyqV AboKEVoBK892KMIzYZAxQXomMCM+0QzPhGbkTK6UyQwqbCarVOM8wf9Du4UCeagEUnq2KI3hA0Ql Q7ab7dA9kB2+hxEX03V2Be0czvS5dXfFGHBAiO6A99w9vyvHBVMdGfabalqzygJroIj557+AD8Xm ouDnPtUAA4cLeBfaeFKOrAwTYpoVBRxKmxFBzfJSYcuU8HMr51ZFKLk9UFr8QFi1tNg9sA5P7XNo n+F4QysFfXT/wKPpcx/NnwPFXw+l6UCHUG+Aow9W7H3eRsAm3WUmMDnV0qbndOXh7JzMR/XER6qI ymVLyrEpNjlpB5WlHVCsmewMZZ3B3EcMRiPcrk1xqhw013kGFB3SpQwkqQTB2zwJUr9Yz1A6k62T dlChi0AzILjWZ3Hl6MpxOnhn7XQVZAYLEJy7T1NB7EplIlx2kJ5FChWykYGF8w2BS52Ijp6YamuZ p8QEiq5tjGirUKHEJBqtkZjIDiWm2pqbk+6sCZzeIDpjkauhdMtpEnM0JKZo5W1utFPb+zTZYWXY gfDOocglCyWYdDOG1iyU0zV/PnN4+vXbExxsgpwH/8G/8rOPCdw6gSvUfj5B4f/2+vSnvx1++fbL 35//8Z///++33//87V9Pf/0GJajkDMmymJpXDdxXLUHWwvjpHEihgmMteHqOqwo88EpoSoCnVC1T UIRjmZilwqNwrqUCKd70uTKEqVtV4GTKJLCZAsfiVxUy4+AYSl5VoirtyEmBy/AttTMDbhI7A1Ge zKqCCwShtEy6EHpWqgo8TVpfvFTYLiq8YniZFbeq8B5QYTtQDlrCo+WgwGYCZLc1gQ4UBbpeB2XH rCs88xjEwhJhM7gByDiteq0pOBUqF1gWlzlGLRUxCpwrlVWFzwJHLZX+YJGj8KlJCj01rYNHYnBr irCMCjmKh2pg06pCEUtKb1q6UlZ+X2KVTn2MOf1Na/Wm9XFrCp3LGHPym08AZ11RoBfyRow5/Q3t JbzlxKxLJULTrxOPWfyGp850gLHm3VmBtGasvFChDDfgUaSgYfTKpQBNiPMiataEsViMcWhlYgiT 0h+yInsIZWQh6KO8tpNCB4X5jg+XlP4CE7l1VallR+ToFaWXvOOiGB1rS1+rRiie4uZ1UhwWlh8V 6WGxEcF+8/oMtrbbGHwXXZ/BJ9g2ZjT+10bwhbEJwbfV9Zmec9cZ7NaC0hnPOGlPSmdqXynMDMGr ktI2oheITUSA7ncHduBOAQyfcho9JU5ByDY4LIeRHfkBkMNdrWZH3kfqE/IM4qHyVSS7jiQF7Sop vUH1MU9mWEn2vpkE7X/czMAZlPTwTFbDMTYgWflk7hBpTyRQQm9H4VPA3/1V5byRNlhAGztyE4R9 jhV03dsy6FQJ2pgkvaoL3x+R958dP8ZQ8cATpI5wHCA1hHjoXKNQIRv3gxy+YCp+AvIgfEeuMRZK sHywFhU8K8emeDc/fFFhO7dgeO9bGDrCHXkPwajcgHBwX4tBD+X2ET2U20eOBrTDyhY7ODsn2vNr XjKcsHdGlOkNCBf7HblX5P49b2fWmMOTVsalZ/hrbfsbnv/7z3830tnTsT0zdgXsO628SZRhZ2Vk RlBMmRs8ttzX8NIop9nS66SwpZ35SoZufhND3vfQDCa4LQilya9HIDSj28xAIHp/z0yBdALJaSMD ijVZphpQnEWmJaihiCTJdoTCdnbmfph37/QS37gPZnNc9GIKpxI6Y5QthpRjU0yezJCAVj5OcFYh YeSmqwOHJulkZqbvtgnViFUmcpcyK5iwDdS6eKKg3T7XSxunw9TvCAXHfT7DFZYVrNTXZoLK4QTR 45yvi3hV0rzxAH4cduanYy7xjTdcDCM5qNLDxintEgrdSLH5xEhXhJ8iwgFxMSLj6rqMzAWXMzKn XJehnLtE8BqyCnm6hibIuxRGUMD0vwHhMrSF4Wq2Mz8KI7uH933wjCNL53kA5NohfrhRQnmbyaY0 Jek0rrM1el04NiFrM5lhBc3szM7cE0OxvAHhjPBTI5z7tzBcQ67FYGYqygdkiiFBJjhZrlBhM00p WnmXtjKgWJN3pl8FKM7KIjEEcaPCDCto5izzCd5zH4yMnFic7Jq8StnLrsmrmKIMURbQyPcgnABZ wTz6WczhTYpfWazga+2jTIipKdl1JqgYMinHpgRfJjuo0COUEXzKfjniVUlpYoIyJezMpzOX3MUN HWMFucCPTxEOmWszHOZbGE4q12YoD25AOJt+OcIlZAvDpWhnfhTmhk74JuKpaalEVMEZ2cVE5a2T NlhAG2cRDk1WMMLvnTm8SXEOZAVz6c5sZ5zxz7LNS8rrSMqxKbakyQ4raGdnpK9uYTgyHpmhBLQB kWmseyHlQnTCq+TCDyFcRbYwXI1uwBStvEtbGVCsyTdjjAq2bGYMOMyOfAi51XW3CAfF2SRDfCgi UQg7rKCd72JEOLCCYXULhlPKBUkyKZOTTJLwqSSZJLNyOUsjLKCRswjna1Yw7d+CwdJ5mDQswqfU tZg+m03lhPKiCThOChf4XrGCymG6roUQlYazPz69TI2CPrl3MewREK9Kmst9UKaEnSHG6LkT9JD3 7BkG+yEPOW3uyrsiGwO2wwrb+WzGqZPHhoNXbT6H9F055VyZdtUVeTpshpWTVnqJWGXcfBFWuRA/ hTHKxnk9RvnsNjNQ/uadaxV1+Q6kJxmtwpS66m+ZAtkEK8PEjnwFwp6wAWGHujbDDr6F4UC5NsPB vYWhHLEB4Zy2AeHUeAuGy8s2BsvU1zGHu1sR93dB6dzdEFr1RMKxCTaayQwqbGZnPs6gs7KCTr8z Iv+wgFnslogJvZsbzZvXynpu545NMS5KM0LpZnbkp0PIv7cgFCY/PEPpcSMz0uzdMlHpWDYzQeXw eMjhrlbzgIi2vf8qrR/zRhmTUTg2QesyGUGFjHw2wt7LgzAK7pfBTMIKZqR7Zag4sIAl5h4RepUK ZbxuH5ox0P/NezfKZ3cHDGYLA482N6WLrsikw3ZYYTvnGK1O+lmtoi4PjKSigplKLyjJhbtmsop+ uilQcrQ3Y5KauxcQSs63QaLKozIyY0z4VObwDvUH++WS47qOA9AVvD28cQ8ESdR3HVlCAxmle9L7 B5oWRZFyVerGVUnFefHkAnXuCS1b4kd2HuqRYGa+hYONN0wZiARS/pHTahwSH7nftBrXiaqVKo4Q jvN+TjA+T6McklDDrh0wrkz9D0mw/iEOdno3Kd5EX56jYOeFab5HkmLctWNNnGcVJLm4V3dSNalM uYWk2vwWDvZ6F1eOhfADp9dvJNXz+Wn1uxPVB1QcJjrOTxycG4KfnGJcem3FpjIp2fhyxYFqXIRG XOZO60MYhByfnI6jiMR5NycZV+PkJBOc/9Q53WR5KNgJayNgQ3cgD0AKlDKFESJhDudwnu9gCSly eskJdT7PmFiNSIIx0XGuOZKoTLgefqLgQ11oio2uO8GmQcgJHnSnGGSUXogmBN24UIngdONCJYap kQ4ymhIEHDlyc3It3UmxDEJOykkPI0xG015KC5hUQY9iSKobgALlEkagmfTJhxekiASmqe/cWLFu 9TAmZC1L8via00SLll1KWSeXzxY5QJ8xPzxfx22j87mh6ose5Afp0rIeh7uX9M0CJZfCIBe1Qgo0 k35rGM8XIpHpFnNuzGbXGJS4etpC6Hf9stqvZww4zrJq7Nd1YQl7Mm2/xXTLg1Ac374aBZpJvwuO 9QiRyNZDX7XFpFxiY9q62J9GhC3vsR/50Bxr47QiIuQEIKeWtveDJFNq20ePnQ6gOQU7HjkxCCEH wrJqTJnUNnaQbGg0+UIpJgWgz+izgbhsGuYVtEUjwSCDUKQQR6AJUBxZshCJG12mj4gspLJ6FhOy NjnFmmTrFQdLE9bDxZneqv1N/x/xaOsYQqAeyg0KVh7M840KJiAV0Ls7WNFi2uxg8YH8EAdLZSib HTAeHqBgbfV+qxKMs49xYptfPnew0zvXHFv4G2cbBiEn+ylMB8HUXv1uNrB+p7rNiIb61CEcwg4F Tp+6zp4+X3DKSQxJyxLfVTntajWH8o5KDXBNoWkWLwkA0zxLRE/FEkZI9vt28GLj0mYHv0HNL+/g naluVfAClt0OlXbnQxJLv3Au90T6W11JJYYAjnEoT1HkzAnho/tchw9VxjEm61NF4OcZuf/q+D1H zTX8DcdM2D/hGAn5s0uXYjJa0DspcgWUH/E98jPHYwvWF9ZqYhByaSTAfPFlInGe4ci7b3HGJzyU PymclRsUSe57OXxCZXzkEyrjo2QDxxGyJQ4/XQrt9TV/dKRgH45q0xsUafaHsldl/yfvdZzTE54G fm1RFSSCkcCa4PKopjPpVRCJq/MwJ5HpaedmgZVI/5mIRDqc33TGzm9yxjl7aYeL2RZllMTfVzA1 E2x2MBFD2LNTsZxA3uog8a7oUoMEPDutQHWiyqHEUUTiHM5+nD/u6S1nYx/O5rygZopfJZLjjK9u kEsjrkxhBuAo3zekqgzQa9PdhVNDNrvZobdtYAnijUsypcyEC7bDXpdWhOPSs87tdzZO844i/LvH O9JhhXCnvrcTTYkrxfbvfF8lmJrnF494juPhvJ1zy9n44ohxJkdTKW3AWMgMKEj1ZRWEiDqnrEhC 3KzovLqvo2vB7Y6uKfd1Rs39qPA2FBPLtA0N6L1UQRhw+d+gSBva4kg3O5x/iqOnhz+fwSsHWR+e F1DuneKnJxWUr53iaiPZ5r6dbdAjcGmgWDeFEcJhDudw9uSMXN6gSEV4a0Vq/xZHesi9HK5M1YTI TnUD6AKn2xUTCdNItSZA3uog8a4cDm0FEvC6SXSgdlSFEcJhrjoPOD37cHTmpAp6agoml6CnpmBS TjpFBXCQnyhSAIVwHX2Uc/rSkluWEL6tfdeJKTdSgJxoUiyDXBqJoU5xmIxLqCh8lf11JZia8+RE 42o8nIc7t+zFEw/GJ8oN53itSMrc25E03+JIUbm3M+rgBkWq6a8r0kK2ONKKDuef4jzxEH6phDG0 LEYyEZyeYpIJHnQMARzjqiKpKYQzfO/O6UtLaqAQrqWHs90BF/7WY142waZBLo34mqc4QjjO4eiz usWRzHhlZxSgDYouY3QKRy3kQ3iXWvgtRbrIFke60ROcak2AvNVB4l15muNM9HWz4/DAHMq3lGdt d8twJOCzTvFOVKFQcYRwnB85Kh2EcFo9w5GSckORzMaVrIsk/lfNukgWA6XoIAI4yFVF6rUQLvvP cLh1nibGTXht3cuhp/lcV1ZQQ8BlItLgqWNFU+K0XR9AMha//eWv8zQo2NW+q5+9ghJMzXO7j8bV eDjDcXaeBAPWPX/F4XkoYE2bp3IiejCQOEIkzqMdMKvLBuCttlxT6K3AANTprYjoryNhhKxG6Y+K Nw7mjfAGYnqI44xP83qcCQU2O9j+5je3Jtn6A4WKjDVxKl3L37oESgghPcSh/IYiJ2GDIgfq3o4c 8C2OJMq9HUnuLc6oERsUqWkbFCmNz3CkvWxzuE39nnPa3YpkvovGFjqGOKrnAS4N+OSmMEwkzOF8 3+HDKoQP/eGo+iOAq9gzFRdpmuvDW7DGBxnnLo04SDqMIhTmUN5OGed7izLS5B/vjPK40elldrdO MjbVzU40Jb6ectrVal5QsZ7mr9rmseCMc4XBpQFr6xSEyQjyaEVOr/yIs2C/DlcSIVyR9uqM5iCA W8welXErVaTfbl/acTj/ze/uTCiwA4erhcNLG0zlgoguOhJHiMS55lizmmetSba+sJKriW5qvUgy xF07xaQw7RSSkvzTnGzm6QVBLeU5SjKld0ZxnIsPdU5/sOw81CPBzHwLBxtvmDIQCaT8I6fVOCQ+ cr9pNa4TVStVHCEc5/2cYHyeRjkkoYZdO2BcmfofkmD9Qxzs9G5SvIm+PEfBzgvTfI8kxbhrx5o4 zypIcnGv7qRqUplyC0m1+S0c7PUurhwL4QdOr99Iqufz0+p3J6oPqDhMdJyfODg3BD85xbj02opN ZVKy8eWKA9W4CI24zJ3WhzAIOT45HUcRifNuTjKuxslJJjj/qXO6yfJQsBPWRsCG7kAegBQoZQoj RMIczuE838ESUuT0khPqfJ4xsRqRBGOi41xzJFGZcD38RMGHutAUG113gk2DkBM86E4xyCi9EE0I unGhEsHpxoVKDFMjHWQ0JQg4cuTm5Fq6k2IZhJyUkx5GmIymvZQWMKmCHsWQVDcABcoljEAz6ZMP L0gRCUxT37mxYt3qYUzIWpbk8TWniRYtu5SyTi6fLXKAPmN+eL6O20bnc0PVFz3ID9KlZT0Ody/p mwVKLoVBLmqFFGgm/dYwni9EItMt5tyYza4xKHH1tIXQ7/pltV/PGHCcZdXYr+vCEvZk2n6L6ZYH oTi+fTUKNJN+FxzrESKRrYe+aotJucTGtHWxP40IW95jP/KhOdbGaUVEyAlATi1t7wdJptS2jx47 HUBzCnY8cmIQQg6EZdWYMqlt7CDZ0GjyhVJMCkCf0WcDcdk0zCtoi0aCQQahSCGOQBOgOLJkIRI3 ukwfEVlIZfUsJmRtcoo1ydYrDpYmrIeLM71V+5v+P+LR1jGEABUP2/YI/8WPtmjl7//9+7+jxsnp XH1D9fYJKxtUXRhxss8ajKN5/tdfywSa8UnO+/ZvpOfxq6hPkky2QT9wVCw56UL4XHMNG0RFlk3q n2F6WiP4MuB7zeBf9hdUa1Kv3FeA71yjXxFZNxX6QVRketpZlXopCFzq/89+FSQ5jBuxF+QPeQFL EiVKeof/4NP4/9dw3ASBpkVLSba2dhPdZlDNBhoiYVI7dWrqvI/by0te9nd+eRExvdpdfLDP8Yqa wqr/lx7fNv4BnV3561oB1stfSpBy9C66wlliDhP3BjHgR4HobxffvpMg9nWf/6gvIDe8vYnYu1sD Qx63i2cu9nd7uRls+aq0pOOg/9z/7fZu23zd8CjNt6x5Kxef932lID8OKdcOBljz23eImPDnnx2F f+YuvOLiKTn1rqv7jMX3Z72VOp4CTLHere8v+rf5ojkC7EDmyBp+P6Xdv3Cv50W6e+EjvbwGxnFx CO7R/92V7z+6lf9blxT3TsBKmgBFHwLoQQXqkwQvm9XvYjA9/8inzW3iFxMfvd3O9uWle7C3gaQw zaMT9Ylg/1/Y7d9swatURQBZ13/6M/jFGH4WchmSwran5kPRBCjicQY/RyYylCSnUcPkNw/YnvJ6 rUlaEe3Uq+FV7zby1Mjutkc416vrwSYHUn8766r8MzRMDqk/X+fb/ps35fDrsSoAfODJ++YMvo1y GYJfXv1aNAGKOHIRMId5nz0wrYtTRIR9jUsTykbThNJOvRp+z9vHMx9Po9406J6nKiDc4Vg1hWXa GqG26sKe/+YMTr+KAAInKPSbN/w2ZDMkZhf8V863wD0WE4zNEA1fNcoQ9unX8Dv8785/mqtjSIu/ TnBHAbEaTdEhPxhGh6Dmwh4zAvVYN/H7sOkeLkAcm11eAHa1iZ/OTTIZMoY5tr+BtAB6OHCh57wV WJLPJyLsa1yaBjaYpoF26tWUYR+3iScmnkaqadDtTpkFSXvYB3elz8gQ50aozZK3u2pd5sUdVUN+ nHf0yRDV/v3gUDw8pqWFUcQTSdveDAiEnU2DXtY0Gd6I69Spqd/rj3Plrzf/WaiW/fI63FNAtjAm TdC0hmnzCLbdeaaW/mKN28W/p81t4jeQXwiju9EIwr42sgSC4zIE6x5uJTygokYAJ67AkNzVRRD0 BZcEgnAB0U69mmPVt49HPp4Fa9GgW75ucACZeXRX1QMEo1za8n1jcPZFgwH5BTq7y40gR87wW5HM EDrDlTQBkvhpoIAzExn3pXEKCDsbmwSUDaf5pI06JZj26g77/zbyNOiXsMTd7XpVZYjVaK7HrHd2 CGoubPtv1pTjT8YKxMnd/AQ5MoafhlyGYJ1+LJoARR8C8gNlXj2Qh3eKiLCvcWlCkQuIdurVHKm+ fTz2sbfnY/5z/70XpTDNY1lql+E1jP4HsNT8yCp7ov589Pm653FHz9Gybe4KaYi1m8dVRVQkhW1P DWVBpPO6Nvc+JTMkhWHCXRQL6QIk6cwmIBuf1gYZ591Jqoh0NrbnuyoOHO4liHbq1WDcx23lFSu7 O38MwzrWPfxiblNWRWKYh3f+11X2Wv356PN153sCo1zm6JwYw7RrO0WmdWkoCyKdbernG5tjy2YI 1j1kpdpgmj4V6NBA4tj4YoD0Na7nu2jclAqAdDkuOBJ8m3ho4mnSG78mfdVYEWrEqjGkZXEIai4k PW1BFugPh518HjEi4xYdZUWkczWmppGyGYJ1mk/Gp5o+FejQQOaYGmMKIp2NTfOpslVEO/VqjnTf Xva9PM36Iazb6LK+yqq39j3sA1LkvYoPp6bPpazncUMkfAYA2imSHxQNZUGkc8QFEJmkZIZgmaaU umCSPgQ4F4CkbW98KYh0NjbJqUpWANfnsOJQ821jx8azvC8SNO+rzPq84A7Hqi2M7mzWSS7EPY1B HNCYcvjFGCIwhpQwhp2rMTWQlO2NiDV1pbhQNB0qoAuGbGEbl8aXgkhnY5OIIltFtFOv5kD37eUX L8/iPq1h2pLGPWVVxGr0PKYs2F32a8153BcCCQX362ERUM8WgPyimlvGgtTGGFpyypEZsoYhbT6n nAsmSWc2BTozkHFfGl8KIp2NjTlls0lMaZvDAkz6uE08NfE0602BZD1VVoQqsSpf8ubVIag5D/uq tWaB/HLYwVdCILCFhLAFffHxJJ6UywAaw4X0AIo+BSxhiXuDxGl0kioinY1N06myVUQ79WqOdN9G dow8jXnbvxrzVVZFYh7B3eHTFPwtH6fgQshbew0D+oCjz0NFJNc3lAWRzjazBpSyGYJ1GlBqgmn6 VMCR8f+8TY0pBZG+xiXxVKkAaJ/jiiPFt4vHLp6+Ytcw5l8xfcXm37XkCEuNvnxSmObRIai58Io1 An3rVMr62MpBs20Nsq4NowHSN83RfynHZUgK2578l3ImmCId2fh1ZCDDFBtbClI7g01eXzaaPFG1 z3FFGfVxm3hqYnfDT/m6tlcJr4Ote7S9sSofsH12CGr6G14IKLb9MjHfGFdHSQTOkLL1qny+a8a0 870OPwzoc+6ltUHGeXeCiLQf7/mu2qfNsQHRTr2aI923kR0jv8T8Pqcq4sWblAgFwj2OVTHMw+QQ DPNl16NdzQNc5+SgTfnOODtviNAJUAKhdOZBueA5NkPoDVeqDabpU4EedSDTujhNRNjZ2Ox7Dcvs 2IBwXb/mSPftZd/L08SfwjJtLvF1XxtiNXokx5CWxSGouZD4NrfmAp1AClAEkXHzQUWEnW1qSSol ewNTiGMTVOqBCeLEoOfEROaYGleAsHMcm5yyyTSntFGvBrM+bh9PfTzNe9OgeU+dQKizrEp72IdV kVpzIe+pFnnAL4PTr8cMSBwdYwXY176dJpRyGUJn2gFVkR5q4x/Cuo0NsqToJBFhZ2PThOLWAMJ1 /RrZY7eRZ0aeRX3ZwBr1lFWQXDNEd5VPWxbsAJyDC0lv/TUQyFiOvxwrImnbG0og7GxDS0Ip2S9Q Vz3cfPTgreiAv04MIN9258kJIsLGRiYRJWRAtFOv5kD2bWTPyLOsNw0S9SITSJWJNWuYNo+UkvOg F6klDYSwnH13yAzZsh1LwwiEnWlMySPHZgiNaQZUSXKmjZ8TExnS1rgCBH3BJflUZpN8knX9Gkz7 uJ284ORp0qesbtKkd1vakCUs0YdDvuLNq0Osz5WopzOIg4/Dj2aKjPvSEAKhcDpT4kio3v9jkcaT OmB6PunpAJE4jU4QEXY2Ns0nsgHRTr2aI923jYc2nsa8idCcp1Ag3N9YFUN+2DgEw1xIeqpFGJAS Z18PGRA6AUog7ExvkEbKZgi94Uq1wTR9KuDQRGLz1iHCzsamCUU2IFzXrznSfXvZ9/I07afgbvVu VxvyW6HHMTdc/D3MKi7kvB0iTQQeK5x/CiDCfWGE6hM6TxN+lUskKdkbmMK84TdZh1M9GBbcY9im 1CBp2JwaIuxqTJpPNpfmk3bq1fA73i5+d7G705c8QX6Y5HOTTGUMaY8ZSWGa8QoyJA+7m2tlUQzz MClgXb5u9jJQaf/i0EI451eStlNknPeC5F9eh7DzMEVvjLABwbqHrFQTTNOnAs5MZNyi00SEnY3t +a5K+RMoGxDt1Ks50n172feyu/FJ8Cvi9SFdKVWorZrCMm2NUKv5GvTvny1RW37ahDKG34yQs1aB aV2a4wiEfelM+alzXIbQGa5UE0wRRy4COHEFos+HCrCrMT3fRdvAwV6CSJ9eCUZ93CZ+N/Es5vPP Qf5Rezk+KjJkyGdxlFRPe9iHVWPeulyKeXqCGPg89GinyByTO11E2Jm+IIj0CxiCdRpNaoJp+lRA E4jk31eniQg7G5tGE9mAaKdezZHu28u+l6cxbyJeH9L1ksWNXlZlZIhzI9SGuRDzVIs8IGU5/rSm AvCBxxEI+9IZ5JFyGUJnuFJNMEWtAJm4AFs2x2WmIOxrXJpR5CqI69SpOVR9+3js40nY57oxadY7 TZAwJo36FOZRb/QoOE/6cngkCdxxep97d5wMoQc4ckTYOW38RbZ3DdmArNlDvLywUhwwSXVe8K9h 2lpkSO5mJwj6gkuyqcwm2eQ69Wr4LW8nz508S/ki4tUK94zUaYuWsMS90Wk15yEvYksUfJ58MlYA NuAcEkFffDwJJ8dlCI3hSvXAFH0I4DGvwLj7cCLCvsYl4SRcQLRTr+ZI9e3jsY9nIZ+fAvPqUl5F GWI1kuox5DeEAqi4kPPWXqOAhDj5eqKAxAl3QJw6IOxsI2s6kQ0I1mk6GZ9q+lTAmYnExScmEXY2 Ns0nsgHRTr2aI923l30vT7PeRGjWc58DUaG2agprI9MqLkQ9tSIQ6Ew5/1RQgWlCBQ4jEPalLwgk 5TKEvnClWmCKOHARgHnrv/Pmw4EIuxqTBpTGjCHaqVeDWR+3iycunsX8GLbJX+Ypyf7P6xd3dR/+ xX6VJMmNI8EX9B/6AwMjCBIA35FvmDwVL/P/w6AYCHoEFhItzaRJMl6kKi8wFo/dTGGTAMkYavKg hJtAXfIsTiJ+0gsfEEgGLdyGZAAI4e9kY5IUkE21BSABSHC6MQGBZNImGxO0MSIl9d607H647HPZ Tfv045aMD2l988fMmqNJxv69xikpONJ6Dsn9pDJsbMS8pR6wnF99VXKucp/FZQX7gawhKJWbWRdX qGRktUEZAQSSXb6+hpQBofY4exMmLTmN9LQ3thGy8F1hu5LEfkSzrJI5AD7594UACKTU/lbes64R zgaUAcmRPAQtrlTGCIl+PYH9/QLb6Ql5soZgthiPdlJWd6sD2DQG7fGVteoQy3Iu5yErOJ1OyJJc E07z0iBUAsk+niqBQPJJ8ZA2IEhLIh2MgoQakcUjsV1JAnnzZgVVEgmh4DeEpva38j/rGmTtRpcA ciix6ildjJDk1xPZ3zCyna6Q999c33ujvls9IK8rwZt5sXKPPt/cH4SiEbGHUEmXgtCYAW/i5pVC IJAbwkkvWx7DVqiKAbeVJGtvhjcvespjRqbZFawwUsTl3SR8xNd7VWVIxOGkdBHCsl9PPD4Wj04F euPsNwOrcT7kNf84D5QFTC57S0dp/uirEnNZgAMur8avsVDICHuYTQBQpsCn011jezNL8jEmiANi l+1vcZ4JpNT/lu6zshHORpQByZE8JK3LVmhjhGS/nsD+foHttIS870SbDgl3bCB5y1cnlzwoRHPL X31Vcq56AouLczrAvFx6MvKlkG8ZzVOsOOnKg6488tbs3PeVc/yqtkv4z9ud8o2R2fMllMVk1eCs AmDLgN8jyoXJbA4kE1ukbXGlNkbo1euJxUdi0am83A+Et1xV0gRdVeemg+os5Nysw6TApbajtp2M iMYpVAJhr6GSEUg+e9uIMiCzZvjMtZOCFkI0vStsV5KYzLz/Cc+AwA+it46wqC3xygUnh0RGSPY2 62QGQrJfT0Q+GJFXrw7zDKbhtjcKqlV0PF8xEpWYyyqsC7+OcJ7xSiMjTpkAoMyBUV7kK+RqGZm8 YcHhE1htUKsbkDJ2b2X2t2f7mK8DuoDkABxyfPCFLkYcn4BPOD4Tjk75pR0+fldSNNHPeQde9LZZ FxtfoMFskfqWFnNZfyMue7M6W6hkhF1kI4AUOfDpdNfY3soSviaYJon4Rd1kAErtb+U86xqhbEDZ CeQ4HnKW2RW6GCHJryesv1tYO+1gM3Z1Z2XvjcpuVX9a8cN2INaSkVrOZT9gBfA5mGXyyue01Qel 8QRCKPRlAFLB7ogmIEhI4htkMgEtRJaNxHYlialMx9MWCioZyY6A2xCa2t/qUQxUDydB3wAxNHur IgskcBE/sfhALLqrMB8I5+LB16zgJG/fAqm3Yy1n6CTFrsMXiFy/GcknQDJrTe6itbKdLYCMelfY ruSw6flIUQ4zwkkACjJSqterXn+Jq6+dAWVVBN6KRl4sIZsvUvsdaM207d2jTzj+z+G4qEFZTXun 4g7xonfkY+OiKi9rsFTJ1iIQQFwZmX9Gjcb2Zoxzhgn/gHCXBQeMlPrf4EW4xgcXXAPitmFlZQje ise1ULVmDqd1KXhm5DxHn2B8Ihjd8tOFtDeLLYsWg7pc2+uCvCi/D9PCWFhVZ8oIJeHAyVEdM5AD /cRTC4FFY+7faa9PKcg9h8CcYh6L2mLkLMAnHJ8JR6cAF7N6vZdzKdXlBqQ4L0sxl/X3SXY1puPN pme+lb+TvnBASQZK7W9BAXQtJsSSJkbY6ntdZTzeYxyOKIfJMEcnEimLky2UMUKvPl00T1h/Oqyd dqAKe1e1b+2qpAPxxtnlqj9cdINP0quxvZMkB+FwLgPexM0rLoEUyt8tHlfj16i8AgKvblWV4dAZ ykMNommofb/xwRc0M0LqX08wPhOM7i6sy2hvllp2xZt5sQeQ/hQ1aWU1XhTfJ4kBNk2ryi1CKANr DrxZnS0cZCSnFwuCAUxcjUiTBtwf0A6TM3CKxRBZzbpshSpGUH5POD4Sjk756UraW8XGslfjPAmP Zg6bqtCyIC/Kr9YYzDLpUxfI6Q6RAi5PMwugwS1Bkls5xYlJ6S4j0+wUAUAK5e+Kk/1Alk33MUZg 9IgyIGTie5DEEf1sNRBIPidJSHdnqYyRwJvwE9bfK6ydflD7W5c/I0vSuyh9/RZx0RA+S7E3y+xO bBfIkuzgEQAC+RUs4IwCAn1kE0uSVNUIkUdJ5mIsGCAEsq/eECevh8shLm9XUcpiMQuR1hlwqSrn Ti2U9XK/iYIY9EMmBggTw4vGamzapeRa0UKyDX/h9IF3jLhEQbGNkTvSJDgIhOPAJrEgGNBCiDq5 IEoCCIHs/hvE82Hynslu1m/Grk7NnHq9q/s7fwV+tZwj76WomP7fj2f53P0GdGOD/rpg2wUEnVzs p3g2PQNyNpatBg2qRtDsNjN7q+xkBLL7b86V53/EyK/meze9VMfcG+kLZDbrHGWbtak+VgmcKd/v qXzioe7yrYiyQ5HBgvuyg2AqKLon42QLZYTMaQqoz2az2E2dnIR8qfYBkgg5xfSfyJ7zRzp/k1p+ M9sUZGpl5Eshk1tEJvlorLwvzk+OrsVmT8mQWZlNyJfwdUp/sdL7JDrm+styErLNq5STEek+5GRE yOm+ScjqdYR+DZsxAH1aCa2qfJ+ux+hVeNKwcpsMRwWQFB2fJMiGoGwkRPialUlfvbEbT8TLHiJM pzI6rYBCGArEzbbwjhEIJhPENiEMZURK6r0JZvJRyf5ZUn4597v1zwqcSU0o/SGmf/9lTVji3//5 93HiXoc3Na4lSP8IkN6QaI24dVX+AYHged50l1TKCEktMM4F5bNRBn3/KpVbE2dfIH6KyhwgEEqK JN3kmKRbSuq9YVdfD4s3LHaTNhVjDMVdUNyU1fbD3+CJlnK5ENVXrU9Fa9U2DwR3z48dIgPTHCbh ERsAD4FAHa8OTjWYFkCL5PuQs8yucJ8QSO6/YUJeD5H3RN6emLhOOX/BXJ3j/BV21/LovMj6H7mO QlLtVfBgZo2Q4e8Dm7egmGFE7uZsEV5lA8DBCUAbWYTYgaYaQfLgXoP3hEB2/w1uuofHOx67OR/T pbQVpUnFijOXEdqjv8RXeKPlXOY8P8VoieknOSYkQocc+sNZ/LCzAupuQJjsBtYsjrNHuyMtkg4y cqojg1gQDGghNCPfhyAXY+E+Iafo/hPm4/XweMtjN+e1g2K3wSqTz7nNbFPo1EBFUz/js3ipz69R 0QLknG00/UACT7sWAlp4/BImB/KUXutBPqW/zMogQsigddkKowmBnP4bMfz/TOdvlwiZlro1tton f1UjA6vzj4yaujGgndRINmGs6mAQhkrWL7cmp+da1RdAUgWgL2HOwXVCILn/Rq7ND4kXJN6eiSi4 qnNmIBrLa9fxiXihhQxdidCH8cG9ux4ouZ0klT7yuXM0gSZCZol2kjHRTpI30fIc1qNB2iSHBSNo Q2QTS4IFNbKZyXHuYO6CAUIgu/9GTuuHy3sub9s8JkSZxa1M56/wpmz8A23+nzQEvigQP5hZIxik fNGAGUbATOmOsEj650ptZBGix/pbCMVcNinpPSGQ3X/TusweHts83t6KsjiPcj2LCkhyM3o5ccQb LWfoVoRKHnHyGF027XfuEKIjwdAaQY/K1S96FCPBbMusr5zskLBJuUgI+g/bxJIkVSWSZ6VcFSQB ByJEd9+oJHuovKXy7mIUdpZbTf49OWlLk7gQymJJaS8H1TbzAnVcIxn5UqOTtTMSzORjNvzq9CQ7 tfTTcAJAHU9TFg4jWwh59/7rPJEUSYRAdv9Na3b/HCW/mPO3q4TMS90gW000f9VYLgba6o8MnLo3 wMwawcDplx06CNwLWxT2ZEDOdmnygQgx3Tdq7/0jnb+70GQRFJ0qAylf3ab2VjxRQkYONKjjZn3W XN29f7TmUPLfmGwC6ZKdrT4pxCtYgNbMCPSRTSwJFrQQYk7OPeE/jz0WffEEk/Hh8YbHu3YqNo8i e1sJzh+dT8r2et9MhcKzftGaM8A1n7d3MfVgZInIizVfD2LMMCLnnvJGGCS8c0GlDtuDwLH2FoLU QRuC74RAdv8NmtfD4jWLdzeZqkqqU/RzRpbU6IMaOXij5YzcZEIlr+jy6Fs27Te3Bm/stiqzWgjV pWwEhMlOsJh55uxhm/CKLUCNA4E+soklSapqhMgTU10xQAhk99/IHHu4vOfy9iqjLBa7DRI9A86s YVEm1Mg5ffqZr1YneVDIZYoRJuZHJyBmMHvHiDNuXfWJQx5LkyQHjHAc2CQWBANaCBEljxxJACGQ 3X+DeD5M3jN5u9+cY6ls3a32zh91N56B/WZ8DtYdCzbWCObgWF/l7uSmRZpDgFw4hMEEQEr3idzB /zzHb69Emf1F58yANXHWWzSe/Jf9MktyXMeh6ApqD7UCBOdhHV5CR+SXqn96/xENkQIBSnKmmWWn ZZd+6j3fPAQHgRdgH+WmdyLfSSogsm8hhW/3964b3/dZkw6gISgqxn1tkGuS1YIUnq+uiSLxCvaU eniyGMsTqArHvs7svczOs7x+ll/aKTvxOov3Mp1GMbN22BsMladsN5nd2fbtFT0t+PvRovYUrn30 sOGTIUXWPloRU8sCZAWx69nqivjr8TFtFc4f9iTefVU49nVGNhHnOX5+jl8+GuXlrNfVQOyaYgzg qbTVMUT0MW56MHJxoTopX6Sk8GOhuoMBl0y3qD2FnhN072dF+oD0JrkVuRreGv3meepa2IVo5j2F fYmquNx5VTj2dWbvUXae4fYMv3wg1nCiq+EmZhEUqJivZP5mUV8+EOlQ6L1Ah8K/6VC+W/C45NLO SFEQbV+8FSTnuvVURb7WeMX1N0e5RvDhv+G2v+wWZDL2Prh1Shqz/i26ZHm/rU2yclThc6OQF+Hz loMdfwkvWxrbF53tFeadbRUyDypCvEpSOPJ1hq3rTgdyrK2XvMIV4r9oKfiBQi4fyGKUkoExQQpz NW9KMjh2zn873w1c8J7il/6GFTwlY4pCcbZKwDdpLoqF4PaF7GwR8FZp3ykbZBF4HhqzVXgi7FXm zmZXocCk8C4DnqvZVSIkHbpRWyXBMhUN2gg8Bjsv63YVXnECpXK3GlJ45zRqq1jMltSN2io8Oyl8 OpgxyV5RaIUZImbMvvJ1nHY8NIiXswkTFQS7J7RNkdBOImrwal9pEzWl7SDiLYhxV2nfoSm0gxZm I2SsGrYbs1XaINxLyHsCb5LGbBXcvupGxbxUHVaqC8wKngme444iInswOkhfaIpGt7JXGDy3vCds 424VPuFl0EbgMZgJqwQghU9iGbQWxK6XmXcUvNUhykEbAWdWRs68VTCRlXVi0FbA917qTrc9M1mh Z177kjsKj1oyQihLNoq5SEmwXIR6e3h5dAV3layivMk4OCbdKVgvfOdZOwrWC5OkZ/H5kWNiVrrs OqV9hqUwxFhKnyhA7WNiBzSLwcd2G/50itdxGfjPM8slGWRQqWnYGgQFNFEMcfld/x6T70Kw0kJU obrLIKIxPexDmOpko4wpHfMjmGp4o4wFYx+A1No6iDjQ6r4MPsGUKYrR9D1Ttk2pTNatpPxhQUa5 RuQYT+LtiZpDHlQKXQ5VReYih+FcpDgn81hmzDvo2Uq+QHWJfYFKGcdhheIci7kcbkWs8BcbY+jL n8xtTH2ejjIekn9tJDs7igSIxr4xc/mlSgOI/+L1nP/1v//3n//+ohdSipB0rWgWTys1ZeoUnyl7 qkPKJZR31a4yLwpfWiVS9KvJFoEin8TPEfytmkD5808SzScaQGbzSgB7fBtBpeItCeocmkANyLeI 0LeCDqLtn4gOgrFdFFYozMn8LMNZMcZQcr07wx4xwjSneVmE/H0A4YbpFupkjsV4XUtispXxEFRo ylQUl/tWmRWKczL/EtNMgRGylhM5kTshN2Td0S/KluEX5QjDD9OjMglWH/QGJIGL+rBIBh/sLnP5 lMpgnfsiEjNUgDM43xfgqshCznFY4TivyHy993ud8zGYwUS0qSo+FSSAS/R7Kr9tF6L9pggPA/hy N4Es4luECaYoUcWCRLDeNmUqinG+C0MK+ycr5MPPYFqZYoSK3X0RfpDyIHrY3p/Rqt+4A2vM0xgL q+9gwbn0VsgNm/7789XWFcXomsQJjIlNmYqidezisEJxRhjOrTGGcvQZDN+9EaZd4SGE7GQAYVe6 D3MRGvvt9Uhbhr2dUoy9nVLsFm+XcW5nWrUaQLjknci1o/v6S96SEe/F3PvuHZFRKhcl2cpk0O13 JXI2qyhVEeZFCFvgiQwiN5zuGpGf8WRekZGWczsjreu9mVaxBhCue/dCqkUm8Ek4ZPkpbVaEIIFD /DCSwQe7y1zEjiRVi31VJrFJnEr+5IlSsrvHlME6h8rHz36j90BketcD5oYs46vE/5YNWYYUXHeT WKE4j2fYsVgh53sG0wonI1R+d5DoQxFy2VRUkFwkYSpCtFkGaQoF+QRpD0kxaHmQPonRynaMA2vM ybwMc8s3fXaOrZlb7sW3rtf3kMUvRpBmO3dnmp0OMc2WD8tQZRtBWn18LeRyiNUcOSVC18hEjRlu ZCODStC2C8MKhbnO8I1hhW7eKzPNmBghezuRinhVhaV7M5gt7rfo3gy4FLogpLQgJ/JmCF2jAYRv 41EZdr0RRrpnvSrswnRX7uXCW6bVqAGEK92PIxl8sMNMBuvcGzOXw63oVZl6ATM4b7sLWBV5kTkO KxTnOsPZysrKLY+EsBnc4l8GLL4YpX9ZCImVqSh+YSgOKxTnOsN+ygr58jOYVrYYoeL344iDHPvz 86Cz/wuGvqcHlUL3Pasi84LjkCLjXGe06q+VA4vvjpOpioVV+2DBufTmiAFt+8TBRPThaYwGE/o1 a/yvfQijwOYOURBUvj8SsTTpbuOoROuvMsUJUAmmc4JFEY4i4rBCca4zWHpc57aopGB2mctN1HOY W3b2vRN6KiMyaIDhRLwvwvdmB3FYF2cE/78gDpuwJkxFcN50UVihG0oKu8EIw65yb4bdcoRppkun Y8HaLE+nCvKMOQorq37oBoRL2gDClfFnmXo2DozuMqcK8oQ5DCsU5mS+y7TMuCGRT+SHDOdnGIsV claMq+9GDw4rEilTUaxxXRxWKM7J/IvM5Ukr4ls4wrTL/KII2/YAwu5/VMaDzv4bTI7xZN6WMToU RqVqBgGsik2ZiqJz7uKQwnE+YyjHWKFcfWWmWQILZCxHRNi3WSH/PyrDz1BW6Dl7VEbB8sZkIaj8 BsilSGrNVLOoytQpS+ClzY0ZvO48Z1eJyE6/PtirFu1Pp/C4d2ISBNdVY1RSMIdmIvTFBoWc0mGR ACmHFaO1fxCj+qYRFeP00xgszS53DP43xH+CcWCi7xgHLru/YqplYWOQqOEpzrcowlNFHFYoznsx FnTqKiQqTpmXZ7A30R1iwJv0HAR7Dts15qgE75/GKPB9V4RKTPrITMgQUtf3oJJVfDpz+etIWKK1 XzHKupdnsJY70zEJdHg2slQBRJSnDCtVYFFENeEwJMgwVxEVUodEMOn1mfkku1qLitPmCoMVFRvR WbGK6nF5VCxKZZw3XRxWOM47MfM56Y7x4G1+MIO1MeSiOLsgPtDvCmAz3AVhhYOczMm8AjMXZOzJ isZXEJuyzKZVI4XEkXple3VI4cj1un8UzaWwmo0UMoWvmXndGryynf1qiMY0ZdrdCSs8W79KGbla /UfRgl7PRgoVBFJanVsj87IVBNu1AAqSi02ZxD5KnKnbGJVUXiIpS1xqNj6KFG1ezVUVonBB+NdY LK41W/P/Rd+UaXeNpHBzs1qADFz7OlzS/Fd8jYieFf+q2+9pb3KhLP3hJrKMW7vjOlfOppuLlUpd iqZU1/mjYkxsyrS7Ri078c3sMmp9YdT1aB3lm6cpRM3riaDxiMUrDRXrbVMmscIaqVfqA6stoAkc t74HP4pmnF/NRUql5hUFMGE+NayWuaTRfJ1SE6bdJbKyPD83C5CBTVxydm555n2giYS4zFUEYuzs L6kixie5nCrUNWPZ1vM+cApXv73D1LdNqYGCCm2uXtEuryYjhSMrQ+foIJg5Nm5R+2W2qhD1OZMy fX20VVegnOreLCSfmjKJjdRAU7e1GkgukpQWOMZl0RbmW9VNtQgFmVeD+eXmJML8DjU/DMQQmzLt LpCVGHfmlmGDoyM0eNniaipSKnV/Bm3E+mEm49nGk7kvk7B6qDzKoFLbkYBeHV0RvMzT8rv+PSbf hWClhagCmnGyo4hGK7MPYdDAfRhmDJptfAiDFu/SMGPB2AcgDntNM4o40Oq+DDZDWPZmxej/s18u yW7rOBheQe/hjnvA4vuxDi+hq85I6Unvv6ohkiAAWbKlE+f4EU2S+M8nEARBAMTzzMUNpTEFhoYc 6pT5iwRuZYsovXCexCcTLYeC0jmKHGoKz0UyQ7mIdk7mzzL768KF9SWqDNiZqDJgMyNLpOBqJ7OP oRM7xpSUTuYAA++aWA4zAV4G740U744iUSXrPpihZ2tOKpvIn61dmYQSCuZJq4R8sfowXFXKeCq2 d6pYrAto+SR+jqCzGgJmyl9JjIowACwr7wRQNR9fYFP4SAJnhCHgqPEtIsqRz6vk5GPQq2idsEIK mjmZn2UoK44xmFyfzlCNOMKMSvO2CNb3Awgfje5TJ/NaTDCtJWbXmKCijkOZquKLHIpJQTsn8zcx oygQgqXlRE7kQciOrHv1i3LN0IvyCEMP01dlsloc6A4kK5/MyyJFhehWmctNqijn/R1LxGADLsoH 2YCbwhs52SGF7Lwjc3/vj4rzazAHE9HlpoRckah8xt9T/e2EifEbLfwxgC73ELBEfIuw0VYl6VSR pFxwQ5mqYn0QZlCh+kkK1uFnMKNNEYLN7rEIPUjpI3zYPp4xWm7cK2ft0xinFufglPf5o5Adm/79 +Brnq2JNS+KsrE1DmapiTBJ2SEE7RxjKrWMM5ugzGLp7R5hxhQ8hWE4OIFSVHsNcmEb1dtvSNUO1 HVOMajum2J7azu3sZ0a3OoBQyzuRrdDdP8k9GfFZzKPv3isyWpeqZNeYosz43YhS7MJKU1jxQoRK 4IkcRHZEd4nwYzyZd2R4ydnP8NL12czoWAcQ6nuPQlqJzCpkViHrT15mmQkUyMQPI0WF6FaZC9sR p1qzb8rENglL8Z+0UM5uNUxFOe9B+frZM/oMhKd3CzANZAVeJeEfPpAVlaMXN4kUtPPnGapYpGDl ewYzGich2H5XkBRiFUrdVNIq+4TCVIXkCjcyFDRyAxkPSfZRf5A+iTHaCcYrZ+3JvA2z50yfnWNL Zs+9+Nb1+h7S68URZJSdhzOjnB5iRll+WQY72xFk9Mf3Qi4v4c0rp0QUg0wykOGWDzKgROOEGVLQ zDZDN4YUvHnvzIzCRAiWtxNpSNBN6NObhWzx/7DpzSqfozCCyjByIh+G4DU6gNBtfFWGqt4RhlfP dlWoCuNdeVQVvmZGjzqAUKf7caSoEN1hpijn/Qczl5fz6F2ZdgGL8sGJC9gUfpHJDiloZ5uhbCVl US1fCaFisKd+WeXgxcjrl1MxkzJVJXQG7ZCCdrYZqqekYF1+BjPaFiHY/H4c8aokGb+gTAm/weB5 BqVzFOfZFJ4XZAcVbmebMVpeK68cvDtOpilOLcYHp7zPH45YZZxMHEjEEJ/GGGWj9NnA3+6PMFq5 IhCtoi6PRxK0JiM2DkpyYZOplQCUaEUl6AqrKMwOKWhnm4HW40W1BSVHu8pcdlHPYfbs7HsReirD MugAQ4n4WITuzQrioS/OCPy7Ih6GsCFMVfDBCiuk4A1FharBEYaqyqMZqpZHmFF0MTpOOVd4dJrA Y0xWSFnMQzsQamkHEOqMP8u02HhljcicJvAIkxlS0MzJfJcZmbEjkU/khwrOzzAOOuSsWN/ejUF5 6EioTFVx1gs7pKCdk/kbmcuTPKJbeIQZl/lNESrbBxCq/q/KBGVK+AZTUjqZj2WsiZXRuRWDqJxO Q5mqYkoRdlAhO7cYzDFSMFffmRklgQQsLK+IUN0mBev/qzL0DCUFn7OvymjV35gkRF0+ALlUSS+Z ViyaMgmlG+5jbioqGFFzVpUE7PSvL6pVXfslFPruk5isohfdGJQc7UszSclmA0LJ+WWRqHKJC8aY 8IcYLYdGUKw3T2OgNfsiGPg7pr+C8cqmIBivfPG/xbSSBYNBxoGnVr6usJrK7JCCdj6Lccpk0SFB 8dq+PQOziRGIVcHm5yAwczgxmIMSQ3gao1WQUxEoKZtXZmJRMYu5B5Si09OZy29bghZtwoLRzr89 A73cW8FkZeKzkd4FANEBM6x2ga6wbkJmUOBmNhEds0CSsvn9mTmSoteC4o3dYKCjwiA6K05jP66P iq40xgcr7JBCdj6JmeNkBBNUcOUPM9AbY6mKdx0JEX83AIZhYYQUMnIyJ/MOzNyQYSarGl1BGMoK Fa1mKWayJJXrq4MKWW7X/atqPsfFaqhgUbjPzH4bFbQT5deoZO1QptWdkEKrSS+55Vbqv6oWzXI1 VLAhoDL63BKZ3dYqOjECaJV9GsrE9lHtTGJj2FLJRVS6XRw2vqqUXFms1RSkwCH431RL3Bi25n+l MJRp1UdUaLhZOMANt7kOXJr/F14jbGaF/zXj97S2OFP6fHhlmdtt03FbqxQr1iKlUZeqaS0mf1Cs TUOZVn00fBK/Wp1bbS+M5o8xib95hoLU7E9SBkLMXmmguOCGMjEPmyWptAfWcGAIZLe9B7+qZn1Y rIVKo2aPorJxjhp0y1LTaL5OeQjTqouk9OfnlQPcsE09Z+eRZ94HFJGY+lpVQMbN9SU3xIbM3WlC 8xnatpn3AUv4dvYeUt8NpRmKOo61pGJ8WSyGClnWFuPoVbSzbdiiCX21piB1m8kFTx/Kqq9QyW1v TuWQhzKxjTRDk9haM8SdRGUYTqk77dR8q8RSXajI7A3kl5+TCPI7tvywKsU0lGnVQVJSWlmbm40e Q2jhsqXFUqg06vEMlBEXDjMFYtsCpOuW4U9IKKh+Ov/zv//8d1RCdqtkHFkI4tyQsaDOH4WirOb1 dFypr3/DegbuAvwJzWD+M7T1IhSq5MWeDZy7Ewv2IsruLCl4s3pZZQpZppOCZpTDYrWqQNZZW3rq 9C9B8z5xn7rCC7tWOhWuQBRyNNwnppDlttpXpXJNMSpRXRGWNpix38sZy12x3M78/pSlIrfM4pU8 79/Me7KRK6PCbaf+yoLtwUbVEQUqhXsOi5R2xHsDQ9uBSskfkPPPif/02e4+Jpx38HC/6O0qdt5e s8P2NsN7zhnDGzHcTHUcXjLMbjDOrFb56+RfZvbSzM0yf71iG3zGt0ywfQ6l4oWNbVmGliUPC9MP lsEfzcD7Uby/+HCY3CGzdjxA2ugqVuqCjYvh+jzU9zhUqAPtVqY4/4nFAOdtGqY3Rz4xt/NHynRl 57eHPnoqXD8e+ixOK3bh0JjCHwv4IcUAHbpenu8YFXooyQcWtzweL/SawsVuvbiWzIrXZxjXw3jZ Svn+qGsu8Iyn/EYlKBfFS/BKwI1AvnM/tQ79ZYovSq2x4GDgenEZCnf89s0h1zHCFE9ckXuKivFF bgYFMtxc+KpQkn52gZtZJ6gMPSogL7b1zdTC1KUh8TqTUBmz1fgK/sdmoYxOcb+a3goM3jFqjaRg c6Ill62RR4aOhlZrytpTlMKAPl17wMOAismyEpBClttqvBTQaqhwS1vMmt9nLLdjea+sNh946pNX qFCi94/AlRC4gN/sSPxbgcH7Ty6QgmEYK96KC50MLdYUq5xZHFXbHveIb7itz3eMindRBgUFMlzX YiWKot0FbmWdoIM8Y3g7hnfLvAb/5QhBLqHSGHYD56eClrMXMjuy/VZc8NKTE6RgGHDJm4Ghc6HF mqLh6bFMHooCusT3XB0Qe0Yl5rKICypkOYwnKdahtjlWmYSlDYYd6RnKHaG8U+S7Dzzxyc+uAKMd VpD6UVaG382xkR1Zfysu/e6zuJCCURgr3goLHQwtVhXwPBvRx0EpVgy0XaHCy2LUBbKyRVD4P3Tr 9ypqy5Ffq1mESlI2iwsYo/JGTNKYavczq9tn4WUr4v0aiYsCPDq9XJAUClPbMguvWKwp+N1FfNlj gB5drc83jIopYREUVNAursVKAK2FAje0gaz5fIZxPYz3CmlzgSc8pTcqQQUn7vKVgBuBfOd+mpTE PW3KJOI2L8YjyR2/fXPIdQwwxRNX5J6i4qyRm0GBDDcXaERjfnaBm1knktIxLw7u9wLyYlu/W0th zvaiSTOfUHEK5nGR8FaJ2bRb2VVLb4UFbxia44q1ZbEkKmtxoYOh1ZqC3/GjoiCgT9ce8CCg4oKs A6SQ5bYarwO0Girc0haz5vcZy+1YbmY+XI2cYIyBv//PfhUlWajqwBW8PbwVUAIKuo6zh/ka9/97 0RC7g3j0507VrfJr6vSEdKchEZJ2+v4MTC6M3Ho14pfW4Hlrs3w9+TVbmSPeXIkqItnSkBpGRfy4 NIyKHLrnJZl5YLh2QBd92upYz5m92LuMDRLyZPQAORIL188eNC7WbEU40VVMR/XrYtfFy9NeDnUK 5mmpL1KoUgQvW12Fl63N8/W8W4IVXU6UZZbMpp8OwM/REAJBXqmZX6nMJYiu+9BKoWNFJwFccQXG mBpTFEFe4frZo2I2VBXgPP2InuLXw56Ht7NdFNBsh8YKQKOukWft7ynLk9kOpToF+EshPY/uAhIt 4QEcaeFJHUHMtAPwpKmN1XC1ws3VKlI+no0jihyJhYtnEgaLIpzoKqZW+nkt/Grh3Vgvr9xlyGas Q5XepBY3RJ0Ysup45No0j6Y6nNH+b9v9yEZAmpeGUBHkhTE6f5hLbne67mPqgwdym+wIgAU7MLvZ T40niiCvcGEiEVUFOE8/oqP49bDr4d1Urwow1UljBY6DrUuyC7NFtIzboU5C6wwgvtrxZIoi8EAZ gRyJYYqMIMO1AzCFlqF81dOyc72KDGluPFHkcE24aCYRmSKc6Cqmq/p1sePi7WQvTeYDT3ZSpYjE cAeWO9yYDaIx96NduodnAH0n9o6HggNQE5QOCGQvY7BDiZkESM4vulG2OtbD9e78k5viYoEYvBEE BHmFi2aSFEYzifP0I7CRr4FfDLwd6qKAhjo0VgAadU105bViEI25n+pQqv1/7nZmVERNAKMiR2LZ OJpHzLUDcKWpjvWc2dHVQEKwngA5EgsXzyOQKcKJrmI6ql8Xuy7eTvXgzG2dNCmyRXD7eTcHe1mX iAfzXJJz//PnYW93dNIBxMle6oAgr1TLA4m5BNF1PJGEjhWdBHC9FUjD3FiiCPIKF00kUFWA8/Qj eopfD3se3p3zXP6O3rxLs/P2bVBjSFQuBizmpXrEPHiYls/kPJtHlSCwgTRUILl5SQ2hIsibs90o QyVIckP5a1957IEI4op3/jJdUraAH80rjxDkFS5sVC0MG2Xy9CO00M9r4XcLL896ufDP8VCwrSw5 ynWfRSqCk62rohuHYBCt5MtZ14pYbLMtcxks2fgCRG2Y3TAsXat0754ZwxarB6dtUXq2QJGQJyMI SLt3P3uU99mQKcKZrmJ6sl8f+z5+OfNKsIlYT8qZkk+4rApuCnMjVIr5cubr1YzU1usbUeby7YrG GyDqBFpREWSGN/VGZ9gEgTdYCRtU01kBigYS7XQ4AOQVrp89KIyT4VKE8lyF9ES/Rl4YeTvpy/Vn msykZ02CSAzN9bS4ZciMHDEPJr00EQ0E7ippf+4qRaoNaLxob1qxFNd8AJlpB7wbo94QdB0cqHK4 XCEfXJ59g5SrpNEDBImFjOeTFMbziTNdxRyb+Zr43cTbIS8i1pNyfkfw4d5XFWSIYyNUinkw5KFW 58C56+ENEHVCuxAIMu+7x6OJyQSBNVgIF1TSSQC5ACTNC0siBJmFjYcT2CpiMl3EdHW/Vl5aeTfo t1ZJPOeNKkH2EB7zhWS2SA25n/I1PSaCaau9/01bCVJovLn2EYLEUjFGlOGKnOdj1m1sRlBLz/Uq MiRzvSNEEysZjSgiU4QzXcX0Zb8+9ny8G/VVxHpSzpQsVFaVmnxohErM/agntXUYEKW2/tFkCmS3 jMH0IRBNzNbUaWTIBIE1WAkXVBJqVgWoGYhfzM2YEGQWNppPPGQE4EQXIVrt5zXygZG3c35yU1zM oGdVgpTnwmiu7ym68ogwiOR5NOq50/aJcO5/zcZIDOYySggSw5k6kZgrch4eUfCgCjrTswWKhLAY QUCQWMh4RIFMEc50FdOT/frY9/F21IuI9aScKfmEy6rgciNTSnkw6KFVhwEItfXhDBD1AY2oCDLD GR1HzCYInMFKmKCazgq0ZPweZzsagCCvcPF4ApcinOkqpqf6dfLKydtJ790c7JUeouS3RPBUH9yQ F4NozIM5Ly1E44B7SpofPaW/1QR0nSJIGyf9JtdhxEw74MtG6BdZ16H+KofLFfri4BQaJEd7MwaC xELG02krjGcT5+lHYB9fB785eHXOy2M3lQOaoxuHUFfuRzaXfkrm+lJjfrEouCnMDGjEl2Ney6np V5RMhOWFlEuT5tK2y9ggIU8VyVMyCDL7cbG2GDZBYrEg1p3SlWyCaDpKPhQcNRMSvZF0AMgrXD97 0JzGo7aVEMpzFaLFfl4j7428HO1IvylYT7qZkVXKqtJRcytTYr6c+vqtILH1k2a2xjdGeSqZ21AR ZJWto0+eYRLksAUL4YDK4Xo3+jJjpsn8HqP52BGCrBHXzmUJzYEQhBNdxfDReh28cvButMuBXQ2h StL7SWnBIdMkL8AQRx7teuwfjHZJz93PHkivcxcpUr6nTacpgsxSMk8kZhNE1/FEYhNE00kBTCAk zQtrIgSZhY1nEtgqYjJdxHR1v15ee3k34KuI9SSdr1XHQT9WldJTo1NqeTDfIVbHAVvjG2N8Y4L2 oiLIClt0FjGTPGlgC94mcECfUC0/Vbv9zG4Zg5EDBEmFiMaTsVoQznQV05H8Wni28GbCb/LnxBMe kiBhC6EBP7kpLgxoxP2Arz1DA8B0kbQ7mSIATNC+YqMkcVHrp//bFw2TCZLdkPSRpSvZApF0VHwo KM8vHxrEL+YWTAgyCxvNJCmORxInugjBZr5G3ht5O9tFw3pSzozHGT9WlTvdmBudUsv9cIdYHQRN 47MtvrFAuhCI5tSto7nEPALAFCxE/aqmpefq5XcM3sgBgqzCxHOJnRaEM13F9DS/BjYG3g326Moz xAx2aFJEYmiQB2du8vr/B3NdknPvswXS6dxBioTQdpkiyCwF8zxiNkFi2QjdJl3JFoimo+BDQa2Y fo+znZBAkFe4eBpJbTyOONNVjFb7eZ184OTtYN8krCfZTAiRsqIknFqRz+7rpFOHAO+KbzzyVC03 oCLIKrvGM4mZBIEjWKnFqxqUunF7N4dkfqdhNlqAIKOw8EDikyAIZ7qK4TP1+tf3726gy1FdDaNq UmRwQ+ab+bS4MEw80vXAPxjpkp6bnk2QJuf+USRHe50DgsxSMg8iZhNE1/EgYhNEU09BNUGRaRsk njURgszCxqMIbBUxmS5iurpfL6+9vBzr5Xs1F1m53NPmeV8a3bYyL4cLwU1jYcylAZIoH91Uni+6 6PeU5uvRN/mFcJ5mwzgVv5NhBJLGaBiBHIknn6sxD7iAyLK47ewSTeay/3m8QEThzwlbTSY4l2M0 zgHJuTE35y77j6leuZ54ds/V7qxwjUvLpYhk/rzb+l/b1otxUD+rJdD7qQqwnc3JtpgNSS4UcVMu f0fz3jpivsyDJzXX+wJRKpLKXiRDCaQ9S3/dOBZbu+ekPD7nxssdQBUwV5GG/IeCcvk6THzFqsgv Lma0t4po6s+7HX+1HXfvrFycSealZdxWb7Xf6uW0rvo95Xny2jIHo93g/UZOhPp7CNEIANIegKe+ cJTqOW1LvU1RvUD8uPBNiZB2736M8K209VGp90xAqvv/Ox4jxAREcn/ezfibzbh4BXo3DRt9ecwu Y6W3XdTptPrqy9GNwz6wmjQ378Cbgkv2ecwNnyK1QFXAFdsD8NcHnbG1e0LqU+fwiJGQzYOMkJb/ h4uvZE8ce0QGpG7jninHpWFTRHJ/3l39j+3qxYe4Xk3moqSok1cGPTv4y4+7ig41fvRwmic34dmX ARv5MlSRX4OEpO+j9qXTvJhOws0TKoVk7kKCmNlPFsjsP4ohIC7magZyNamHQM+T2m/JobcCyCpu 0XPWMCkiUZ93L/5kLy4ar44DU6nkYuttV+GGg86zeb52niUgc8FYhx0xAolLQ9h4YI+f2hBzQ7UB z0+fXtZQMBDdXZiiSK8jzoY/KPYJWbsnQuZ9bsgUiUtz2N/9+Jf34+IiXL++8l1bcc0wAuSjjXL1 y3p8DW2am3vwfcn6dWdGRbRC1QCkOQR/ft4ttnYPilzRcIvQ32m07zkgLfePqV2Znjl2xwWkbuO+ ak5jwzWbL93n3dX/2K5ezIJQ5uB2zc5umed6FTdtDY0SsnW+d9MQd8T7XWOT5usweFByIcghNJSK 5NxoyP1j9NdNY7H1fESOJw2qApL11ZNMUS31D8fMee8E8mZDxJzko9lVIFn7992If3sjPlddN7o4 ooHWTgP1miy6MW0f5XLRGf2O2Dzf2q7T6MFNy2goy3MhGcYKJDcvyRACQd5cN/sf9qssuXIcB56g 7+ALDEOkSFE6h4/QMf4qz8fM/SOGEggmQFLLc7m8tX6q4qUhEDsSwnIODJ7iwEgp1GhdbOl2WvmT 8BjI4MYqKoxUFfnSDfi5r1eeqlNCb/ngqrcIYd3Pdz4+LB87Z2g+FsRASu/ZoBZfZu/wv3OGaj2X zlBQmHyLgMEUIBMYn7RqAsNW9hAQGI29Kk1seb5xlL+M8HjlCACp379Kl1oqduU1IBjvF8L4tmMN igvrnFIzVU+NO8fsndVvktWdgdC627Y/NzuQfJaIcDf3xP5A+NgIa+y1WysUc+VxBmKsIhBj921x qwm/8mUm/AKCRJ08VUdfF+nkpuqpFaEQOh+qMDOCa/ZOxgckY48Qdzg7K2t7rVCE9jJt74H97vvA wADLBKxUkiBg53dLcw9BS9TjrwPAmiuOn73cu8RYK1bInDIVq5cYQefdifjDidjpOd09r90OY/Ug /OXo5Zarm/Cw5d4a2HIFlEC2CFv9orBh0KElhBLdRmAxSwyVe4zkTLIiGMBhaxFp0hXnTx+HxcUa nX96aVmcegkISf1eld/JuJyMfuvpJnrt9VlRjs6zJgyj7M66Fw8674ODKzGdb6xuW7lLvwen55pE 9NsvnTgmYPaKswukZO38JZ2MFxXAvDmEYtocq8w8+SrIjMT4OWX+T8zEHsusOui122XZkUSlp83K 6MwY42Ej7vdd+2JConOqixlBKjn/CATsbBEZGio3wmQBBmN9pje/aRNrggU9hIL3smmabP0aIUX3 BZnft/ufEcvd0tdV/NordPbFG7/4DRmNnxZV+nUzHJQ+i8JYZ8LiVWgYQSlwL5dAwM4GQGAK5MKs skAI5Up787oh06xbG0iuDaGJ3+c49RCYdMX9K+/DakaQA4xfl66hqXqNENlBd0o+LCU7bdg63HYd I0l2cOrB/c486MOPjTEPJMLkiBpTFMYq75BiCzCOgOA9sok1yVC1CAXvZdMUqtnHCHTvy3BMPr5e v2csT9kXVbFYQSj0DKS2dLMyoUW4Fw4qX00lSRQRmGa2ld3sjYtMkGkT95Bsg2AHxbuCpOFgc66U w9IiGQJGchqKRVkPnu8AFCWav3FcKu8JQYL3ZSTHucN4GMbdevdm9JqttXyqnez8FYKr9RxWfPuk N2F6kgsuA1jvV/Zbs24uT1WeTcwC8vNMAlbAB1eZTAjU7MtIdvMjnd+rrqpYU7lH//SvNNVT1f/3 36qVSpvUrXQkYo0fJyWTdk8ISmZI7oxKhox5VOaCOZ9gMQZN+tMw8jDaop4RMTSm2Vimy9s30bhZ AfxJat/y2DqUhiifT3pmG6SJHZloFu+UzPb6sYh04rrMFXM+wWSRnGBCmscyOZPx1qnkpK7yUSaj AUhLlR1S9KoQu2hXW5k0uZ0qVmUiIWkJuuVEzxWZK/Z8hs3PIvjORDmf5mo+Tevk1Fleb1ddCa1M au5hVjLWzE5X1LqqteerLY9JXLHl4+19FkenpEEVfc5A+mq26lCFiNZyyC5YFAQ+qVnA1n4pBCzv Dbzr4nzW7kiLpIOMlOfIILkMyIAeQpF72RT5earcJ4RVH4hwPJ7vOJ7G8ZRRg4zX1durcP4KMjXH vsCo8WQhceDnGWDi1+ROZLxFyu1zJTAwCEL5fXlC6EOrSZ0IUgPg9AEVheuEQPO+jLwg7yAeBHG3 2vl+QFNaE4axENtfQDLhklcHZLSew2pnUawUPpDQPEDsPGYjonOSgQtDW4TMetmwyQJ7FYicTdoh aZN0kRG8RzaVUVQs6CEYTnzGyQgQAt37MhyT5zuWl2K5W/taneA2oDLVWdXrhcao/crP6hGYxFi9 DgwQHJpv2oBiBWfvxMUzzYv8bv1/maVFGSGL4rhUVm8I9OzLiCT8WPdPmYQsTT0le5OUv2oRwZ5l 57tllNuFgOMRIlvjmJJgL2T1kvIoZtjpaTjXIpgqvKtgJiNF9b4Ihto7BeRrub5bW0wD6tklRlUG onHzJKmDENFaLt1leJC5ijz8GEFnbt07zWa2QfVci7BZL6pXV0x2bzSLd/qigBRboFwkRL5HNrEm WNAis7FTxflkADYEqvdluofQHcrdUJ7OVIzjuoZ7dc5fQaaesheuswfmQZM9YWWLtFdrGxgsm9ob YZB0T69IkU3e2YhSixC3kRNKOk8IdO/LdK6hO4rdKJ4daKIxmYLmhgIwGW+Z8tNHRURruXKeZfsF fVf3HyPsdabvYhbCzBoR04kPCOUeIdEM06xPCvJHmiQcJKDMnWIR68H7PYR2pDgolP+EQPe+jKyw O5JnkTw7zWBmQ2YyEEwYl50uqBplpc1iGw2BeRNRfkJ+if3IjxdgMnbh7XR04WUzpXZpOCM5dmWL snpY2UPIu5e/cIiIIBGAtByItPv5tyLy1Xw/YxCqKmWfducnPqooBcb8OYF4ZNO0cwFWtgg2zZWe q92BRco/zS07c4HfbxHB9bDo4PyGCNW7Moo232E8DOPZqagas5qdGUgqfVQkBiJay5VTUTzIvEne ooz85iQQo2jF5HDyxjnexWxTkSoWYF8AwXtkE2uCBT2EgicYqIoAIUX3gYzc13csz2N5OurLkqiL uFfo/BFklJork/6hgdBkT1jZImBXV+JSeyMsku6FqXqtyp3IeItgJ/NEkt4TAt37MphjdxzP4nh6 LaI1mQRjtjOybjSv9g1ktJ5L9yKe5BUn71FG2G++KYIZnVVm9RDqTXnlECavnNGMgbPFNkGKLUCf A8F7ZBNrkqFqEQqeJAsyAiFq3fsyssruWJ7H8vRmpCoWPAeFngFndCfUv8v62a96RaHksSNJFSM5 KG9dgWIJZ88Kso4qZqPKW2mS9J+RnINiEiuCAT2EdzIfW9J9QpDdfRlk8o7jWRxPuQ0WUj2ze3Od v9qnOxfYzSM7sJ1WMLNFsAOvzVSeTMksYc72W5INaTAhULIvI2n4D3T99F6UDbB1hDWzm+QcTQoC 0336hiep1nHpWsTYZt4kz1FG0N5v6DfR7rr9167jfSddkdbANf6Nd8gW1oKXewiFTDJP6TkhRfeB TO8iu2PYxvB0gmL41lXb1jV/A4l6ol6Yn3iwdC2mcQa40ZusiVy3SFl1l+ICiyCVDZAbQy/WNnci SC3C9mD6wHdCoHlfRjKGO4pHUTy9DLklmetiqDMymCEyradvMOellktXIZYIr0N5djKCi4CuhnSH DLMyqoeQ4fKSIUxeMnIqsU2QYgsQBCB4j2wqc0gEqkUwmXhpywgQAt37Mr0L7I7lfixPr0JSJ9gM ipqAsBg31CZwJzRGnV6GCAwfC5I+MZID89b1J5Zv9o6RsP5v5XdhfUMaRIA81aTNGwIt+zIiBT/U +VMGIctSzse6TSRfaBHBlWXP+ynInULA8fCQTXFMRXgbZOWgOZoGdloZnrUIhgmvJ9jICHTvy2CY vVM4vpLjW1XNc0rLYv2anKRjTU7a44m3+Kfo5qR3rciCjC5V4PqmS39z49hFxlSr04bwVz1k2LoI iDdxWUedG5Mly9xFJhP8pme0aTBahbBMMFMcFVJeL1/1kGxPQpaksY+c68Hr/FWLSC8IgafOzHbp ItH4jUviqxZJGVi8+qpF8FWqrGXsIrB5LcfYRUreCwI9jMDTkIhoD4DeyYy2jzQf4aEMwMtGgpW0 CNTGNFBjF0ERpCfi0kWgmRG4sBgbxi6CBDMCJ1hPiyTZaVZftUj5yif24GIXgRf8VYsMxtlRfdUg eUAQsrS/odUn4hV9F0mtM9M3zkw+dpHSaD6NM9cB1jGy3V7lmw4yphPFy49qwE5mXqz8posMNkoP Okgw1o+IQ/M7HUtRBrIFyhecD7wikGwb10cHiSZOXtZ0B5kTZ5plb9jFBKu6xQ1mnINoMQHkbnfW uKAmgkszYnRysnSQkgOeUM6bYZkrZIlq0nWQkGhVkLO4g0wmOSt3QweJJixqM5WiTrRoBf1Yr0ZG nJ/zh+8rQ5X8qEyqEppLX1Umz5PHZZYlKMKRUjf4LBM8EJIZvVV6MqL0XJeh2fSgTNI8T8vDMrRi H5VJDTHZPyJDs/tRmdTEo/9DMoubHpYZTRzmd5WJ6UqgbTdblkmThwES8dOs1ACBGkKIGjwqk2bu bG+ZbylD5ePTRrSyfAiQVQg1QFjN15B5/+76ejJ85nK389ZBu/P2gh4grOf7yTx/OYu+rgw64xEZ dNhPlwlmiuPDMun2COHby0xpXkwPy6RLzM2fILMdQQnx48YPEwf16Q5lhE6ncYhSj0CynlvmlvlE mdJfAsl9+q1lyswUSJ69P16m7FOB5L38x2SeN8wudJRl/jda4xZbkF8bYtW1B4DfuiV+vARK9rIE 6v4HSmB8XZbADPx2ElhClyWwyX6WxBDtk2SQztgJnPLXhgxBMVGBsJ5b5qfIoBOAcDvdMu8v8/zl LLpl3lPmSod9/anQykTjnX1YJho3uC8tM6d7wT8sM6c9Ov1gmee/0mU1xqf0r3Pbv+Hpf3//RzCI 5f/sl8l52zAQRltJBfiwL3WoB5+U/q8ZAhj8gGTFpEyalMxjXp6HFDEbaG+Iw42rkGu3U5T4I+F3 UCJRzo2kRI70P4nIBxaY/mEZsLOWwb9JujRsRYX03wxh8M04zk84x8yXeQ7OXEWXHSMkZRmTEifp eBOHCZ71yOlrlwl6wHZOVCkTo1T9XbkkCrhmEKUawjBBGwXhdryHg3EFwmNvbQeXThC+ua7tGBHk +NvpkLTfxKGEMPbGkU6fzpOOTyaTZEv+0OlG28g1Ex/8EIcJ4sDh81ri4Nz3cJDPSxzUxdoOanmJ g56wxEGPWuKg163toIcvcTAuvnYuMyNxZWDwcGXMmTx9nFd0vv7t65zGKznbZf1xHOdDJtaU5Zh6 iIuNXDNxNg1xmKBzgHAHOp3T2c+Zk6v3DuridNZz0FeXOOjPr+xEoZNd7EQhqU+v51x+9Gmn87yz NMssVrRJoXI06k+/tNEY12YIA8JhtndQ8CDcOLZyLpkZZW+s8oUKmSLR20pcnkbCIyMIFcNAELk8 7SNbOoVhQIEg0tYOro4gfAXdwzEiyDg4RiTtD+1oEY29caTTP+bMeZ+jf8PnnDn5s28+3ztzavD7 9c4dyPkyMqKwCeSaiYlx6HZMEOexg966toN5cO/w78IM49+FGcZfA3FAePaczqs5X5/74/xBnO2d 7epiX+e+J6D/PONcVos019EhDR0xCTM2xCS0V0MYEA7z2EETB+FhcDpbOnPO4rkz/T0OCn6Jg8Zx VAcNeomDRr+Ww+0HA6y2n/v5RWrine3R3Ll3opDB7+YkoXx8wkk2nc7hnJKqie6eqU/VAvqMRxgm CPM/h1MDhFPslZ2+Iyhn+mq3Umhru3K/ZKaM7/tGR2qkbzqt13Wk9sxdnDZTOlJn0+pO2wE6UneJ wzpGBDl+QyOS9s87LRONiMoPmVhIn9EtTkcQ5wiOFtHYG0c6/SscJZIfd1otVIiHdqSIfpwGSsjo t3B0EimN+yplujIbOUqrvr6IaDN0+kq6OiVizFDviPMfh+aMHeqdiPX+dJ50pA6ZGFccJZSKjVwz kTINZ8EEcR47ONOVHeThQqfm8+pOq8ElTqvlyyxrmdM60CKndbLVndbFFzltGhzY4Y1jiYPN5fc5 e5/Xb3G2q+X/OVIUQ3ru4SmpRkqUGM1NlEL6Jx3B6Tsm/xU67+ns68w5r+Pn2PGdvrPMd/oOdVQH k2m+00+4n3IuGzzNipDSYscKF9WbOyHYTHwqt1jKCrpDMblmElwY4oBwnO85OAsQPtN3d1CFcLia P3O8LSTZckujZ5jUyDUTPzaFChDleQO9sP0Jt9SDGZiO7U94yO5iXDKirzk65fAKuXYEgWtB6kSr peuT4J7QX2k1JcFHlzyFdek0/N17OUoPrYaIMeltnMtw9rA4PyYyZgzHrtcSHYW2PPRy4/+UWO9r DtWBUdnfgeDvXsUJwoRh4SHikt7N8cLJYVQTCSru5jjhtR8cJ6J1mzi0BDgzOFakoF7eMSKGNNQT jfwYh0otpK95K2SKQ80jzul87kg5zAMiWttf5fTzoLc4yybS7RSadiSjB0JzQbEzrSYdQODysI+2 0tQ42HGGMFsa0vY7HwHt4tqGFMr73pDCRHdAQyWhU7/xE3BKfW7U0yRiJX/UnAKVdAnXhQFBnO84 NJLVUNhEvIm/wqHxb/3gBBG8/RWOFz6MOeZFTOobTh2uREJkJ7e9Sroh3cUBQZzvOE6EFG8cqcLb OJfhS8PKl4lKuuvFEFvRchkULUi6jDMp0if/dkJZvrBSb5ZgfzuCvzqd4zhSSB2yI42tTjn1Qoqj jB/iMOnjnM7pfOZQ/zFJKDd0KSImDO1HCm1t10xA7pO1kRaYm9ZHZtqrm4cV0lpb59Rx8IkThQ6p H0946TqdSDEx9tOykTZ5TBAqlonqnauOTSDF0WnYOBrhyTx9RS+Mmj5I28mIOKMaKZGs9C3SSOp+ 094IBJHL/veRmdXm5mlMijW9kxPTGWGvJeBpF2dy/fQlQeq6efcCXeCyQU9vZIXzoV/3iYRoG7l+ +niQuovfhu4Dl4tFeZgP/uZhTIo1/Xza0dNwzyEyTVFc0z55R5B6j7l7AQTmG9VHZlGq/prYCFvT K9EOpaZroRUyxWrJKW8rueIl2+0SoF5c2/NBOC49M6T6RpoKMQ7PYsLW9Eb0dtZnKwVVLeVtI9cH 71gIR7p/gz5ycKa9k3RTbCeidfVphbA1/Z0MKjvBuOGNCinONAY1FbsqP60Cyidd0oYSKBXF01Qt is7fsZDiGDn9CqrjVBKECRWBVF84gRpOPVdNzUdPb0hVS2n7NxNnTSMlklWINJISCW/dSBdZ29pE iVlz+zQmxTqdidC3M2mxQ2NLqyM7lCVamSeclHL1TF/BmOwoaftsraQ4hrpdH6eSIc58h6o6+qUO RY4+LXaoX4S42KF+5dUmDnVLpxc71FGN3chJ2i92jAgyrupQl3Mpk6jYobHAoCjWxyEMCMIUQiMk pcUOjfeyMJ7OyzklfWj3K/cETp8C+ixEGBAOcwxn/eo6nlOmDqqdpw7KnacX4oCUOJdZ1um8qoPK WOKgwt7doRtOMIsdR43RvbxDtzLrFzueblBxByff24hYE+u9Md/2KunulojTkRrndE5nR6fVV0dq nb6003pmR2rvPbxz+XakNlE7Uifzpo5K5VJW9z+jhE6qkWsmarjtAXCU03h7Awk720DWv6GB9jXb QA98OQNDaLaBSfZehgzqT79BaqE8dsprJtINm2hHOM7pvIuDSgDhcjq6czncG53Ob3fmVNjxu8K9 E4TVarEThJb60E6k+4Jd7ESao/6NnUu3KyTaEOJwtyrk2m0PJdJI+GlKJMqukZTIkf4nEfnAqtI/ LAN21jL4N0mXhv2nkP7rIAy+Dsf5CeeYmTHPwZmr6LJjhDShkRIn6XgThwme9cjpq5QJqn07J6qU iVGq/q5cEgVcM4hSDWGYoGGCcOPdw8FgAuEBt7aD6yUI31HXdowIcvztdEjab+JQQhh740inT+dJ xyeTSbIlf+h0o23kmokPfojDBHHg8HktcXDuezjI5yUO6mJtB7W8xEFPWOKgRy1x0OvWdtDDlzgY F187l5mRuDIweLgy5kyePs4rOl//9nVO45Wc7bL+OI7zIRNrynJMPcTFRq6ZOJuGOEzQOUC4A53O 6eznzMnVewd1cTrrOeirSxz051d2otDJLnaikNSn13MuP/q003neWZplFivapFA5GvWnX9pojGsz hAHhMNs7KHgQbhxbOZfMjLI3VvlChUyR6G0lLk8j4ZERhIphIIhcnvaRLZ3CMKBAEGlrB1dHEL6C 7uEYEWQcHCOS9od2tIjG3jjS6R9z5rzP0b/hc86c/Nk3n++dOTX4/XrnDuR8GRlR2ARyzcTEOHQ7 Jojz2EFvXdvBPLh3+HdhhvHvwgzjr4E4IDx7TufVnK/P/XH+IM72znZ1sa9z3xPQf55xLqtFmuvo kIaOmIQZG2IS2qshDAiHeeygiYPwMDidLZ05Z/Hcmf4eBwW/xEHjOKqDBr3EQaNfy+H2gwFW28/9 /CI18c72aO7cO1HI4HdzklA+PuEkm07ncE5J1UR3z9SnagF9xiMME4T5n8OpAcIp9spO3xGUM321 Wym0tV25XzJTxvd9oyM10jed1us6UnvmLk6bKR2ps2l1p+0AHam7xGEdI4Icv6ERSfvnnZaJRkTl h0wspM/oFqcjiHMER4to7I0jnf4VjhLJjzutFirEQztSRD9OAyVk9Fs4OomUxn2VMl2Zf+xXS3Lk Og48wbvDrGfB4P9zjjrCRNSqajZz/4iBBIIA9CnJ7XbbbWvj6MpO4ZMEk+QHcZx3cn8B4oNy+o6I fQpICGq/c5wXHDhnotrvgMScL84vcqwvMxIScpxxrg7kMSPWNrUWhHCcfQ6v6W/m8By+kdPn+bdz xh58C2fs5dsp1ts4w4HexBlO9ts5w8XfxBmnwRfm0I3jLRy+ufw8zmev10/hfNxefsWxBhk2k4e3 5gaCUWoNiyiIyExfgSMdk75i5704n8s5s15ff8a+Pkc6y3mOdKivyuGT6TxHnnB/inP7gGzRlNbe zIkmVffNOaXEGckNX7EwFfCGIuQxIyUVFYcRivM+Dq8FI7Sm353Du5A5tJu3ODki0iK+0iBHaAN5 zEjWptABjvLrDPbC8QlZ6hdj8Ok4PqFD9lMYtxkCNTUHFw+Rh0A4cN+QvsHVMskhWCPwlXfTENzF 8CAmxkl99704ziurASSE9m04N7X2zKL5mBA9MRS7P0t8NT7SoTcb/yYSc+4z1A+Mjj0Vwt/9LZxi QlEXHkBS85/GySZZdVQDUlz9NE4y2WfFSabG9CEcuASkoDjRtOL+ek4wtTS1n+DIr1XtVETkno/G tqr2PMe5ONsca9V5AIj38Udx5HkgWTRlEyLuFB7uSMErBM4FR5zpaiIADozJ7uNK0+PwHUeF+UiG jfLOB4BP9XczrHE5S4Y1oaYvyHDN+CZv/AAk57YZfTUBiZZEnUegI2LgRBhGOM57OHAkO7WxAcmh /ggOHP8xK04xJccfwckmFz1j2dTm3sHphysgpRJntr2OiENaxGGE47yHk0xpdcGxrnwbzk0pzaz5 MdER8bxQsR1cLouDC5LH48yatvE7GRfpwQrebBl7CoS/ujhfh2ON9WXm2BA7B1cdEeS4kFUcQmSc i3NxtjjgP6EZl5RLARKKsh9rfIzCTBhZD+tARmAyrfuM+ewWyRAZ1iY4/TjY4FTjS5PHExfdTyeg hFrlaTmQcfKEYlzFEzWn1DmxMYIc39SNYyB0Mk8qZhPcJMi4kwGSghsIRoo2j0ga6febUREjHBnv f/cZiz4sshGCrKmmZKY14nstABnu4oQ8NotkpF83VwWIwHiDniqKJuUir/uAlBoH8thMz0i/iy9D y8D4sMBkueRFMkKQNbUPd/Sm3jmATKcoP9M2amSkv2NWBXBgelHdZ6xaJ5+JAyHWVBLcodz0LIzG ttpZdprbjjy4yPG6ZKA/XEd+Rigu5CytV+RhI1aVixBiTRVBdTHPrFZcZ7kcB/LYqRERirSuQEYu KYyabJpiJ1Nj6tkQIdb0nS1u5pSQVEWIIGc6Bj1sdoetdQDmyePYwAA1pGQ4VZHiZx0RQU6wUxew jxsOCCGwCaw74BQwnL6uHszHTxXCroWxfc5IimEgGCk6jqQRjMRVD0RE9rGbKGAxLLMRgqw/ybn9 AzdN8FX4C/vDgrr1X//7z3/Zy3hPjG6GBoS4YFwhT5y/stVUJ4GxI+7//mc6xwrkct7PfxNmPLUO 3XPFNBPCs8spO/K2dYBD0CanZwMwX2RJCIj8smMCUnMLUToiwmKqOx9MYst3REXa4UhbuIQ8EnJ3 6vHdJRxuOb7rCe9PNQc9i989xKt578Rhg/Q+6MhDIeRoJxZpILS0ZzXRrcgXCzfHiHf+7CotNRPP WdU+PqFG6H3OEOR2yXgk477D95vIdGbXvO3w6/lfjPcyyquBp2sGJ6SryPiYEWtqRs8BX0nqVIN/ hbCDRLrTLrCnDPQ+D1ymv//hGTyh4pn8o2aqh+KS8uIaKnIRQqzbta5/3boCA3cmvLrsdPfG7Ul3 99Hu/o2PCxA3fnIEHefdVz66+rMpMUJXb0r5q1dvcZ4sWpQ1yaaxAtk0IfSIYWE6IiJjtju/ffiF snoM7THe+oT52Tre9qaeXm3jzree8YFE0wq9LPErthgd59TUv1KGnpesDCOkDKd8oYxYG86GSDQl hUWDNaN8lA0RzBZskUINZMR5weF1+L79784YjfC4Nq4naiD80qCvPIyRV8g4No5nDBNIjXmIaa/x EBPCJxWlXL8Bqeu7UpSzIbL1LpUyUE3LCmTTiDjTnBZmIEI8zCYcga/qHZBxthnbNV86but46KxY wnNrxgcCxSXto2uEWoGpl6GcS2rHIvJQ2k3ppJqy9tf7RxaPGrOilFGWSoiNbtFOR0TLWMNdOMmo dCAy0h4H7ok2Ldbvfap8vf4PvRU+qPr8HmUR4qAF5+Tou2py0PdYjHPKW19pQ7uNwknE5bxI2ZEt bcbqyGyI0HdyvaQMWNOqAiUDIb4FJcxARGRHjzCygJGsAyrOJmOz5kvHPR2PvLWX8Nya8YHwjNNX xZQcFUJfnZj6V8r0/S+UYYSU4ZQvlBFrw9lmBNqJbnES9hZFTapprEA2TUiKeSFMR0RkzCZcikUf iIy0x+E1vbQ8o+WR47tsatOzP8oaCHIe6isLBT9Wcc7M/kttyANYG0ZIG0r5UhuxOpwNkWxy8Yv1 kjJgTbJprEA2jUgypamDjxERGbOxU/XmhFPJONsMXs9Lx2MdDx0fS3huzfhAknFRG0Q0viiAOjkx 9K+Eoe3PwhDCwlDKl8KIpeFsiMBjyKdFfzbQNZGyTYg04KHTQEacFxxehu/b/6GxzsPy3JqngcBz ouix95BFPStp5k5MGMaXCvME00YbE8yATW6RsCMjMLUsBZbJSGD87qa+HBpgRav8smFCbM0LUToi 4mIu4QWUin7LMJuErXovCbckfDHqDQ6O4qG7QtcPfKgmUyO5BCKQb1g8foXP1McqzqthXyQQm1ek hLdJjiKcREoKi5SEcOTs6WXRN73Khgh9d1MtsgxY07oCbpoRa9NCGEI4Mma7z9/ZFFU2Qvi7fc5W 3ZeW+1ruzr43Fa5IxUPq4PuumfeammtEkPMQX/EDRcd5OfsUDrfSkze82FxQdyiqCEZ4OjClVItK r4XeFmgCKtkMgLIu9tXSDcqKuGXKD/+T6gKx0amKGKHIlA1Xq/k6ensKREba4/CKXkoeK3no+ViE 9HwulBAutH/VH6qPVZxTns/VkiesHYBTMsJKUEpCODKun/QpmQ0R1mbZoqxpXYHc7IS4nFVNjHBk zCZ9irMRwt/tc7bqvrTc1/LI8101OVTl+VwW3biQI7Zkf60+VnFOeT4mkL7AKbsLiM3FiG9BpWSE I2PXwqlksvkmSF8Jp+rZREUb+bllRlLMC1kI4ciYTTiVyEaIjLTH2aj7UnJXySPP70UIzxeFEsKF 0lfZ1KZMY3COPV9U2z1BpOwOoLYaIdE1lZIRjszadFdS2RBhbZYtyprk1sYKuGlGcvELYQjhyJhN +JQwG0L4u30O9Xu7tDyl5aHnZ2OhPOH5aq4RScZFbRLR+KIADHPG8oU0ZAtrE6BwjCRTmj53GOHI LE33JZlsBuirm+qYNcCKtvKTBoTA48qnhSqEsHKYTRoVZyNERtrjbNV9Kbmn5KHlYxHS8rlQQsaQ 00cBoul7P/VywvG5WHIEzkj7X240RKQQmJIRiiylIU+S2RBhaeSXrALWtK6AmyYExE7aORlh7TCb dCnORgh/t8/ZqvvScl/LQ8f30ERUji/nGhHkyB1pTUra8olzwvLnnSRdYWwtsgAugRA5G5SQtaK4 NtH7p7uSSDX/BnkqHc66O1kP90vpnYnBLRDvvCqIEY6M2aRLYWvSpWSkPQ4v5yXjgYxHE++TqTHJ iffZwKVJPXJgkxUnywLE6nOyxzn1roUDtHn1GkNEKDHCSST7vEhJCEcOJarFUslmgL6S70MpAla0 zs8iMFJSWMhCCEfGbGK1RDZCZKQ9zlbdl5J7Su7OfTIxjgF+zjVkeMfoOhHhIe8fBeN9lAAxXgz9 ep+tFwaKrlEJwwjJEE3K21K9VRgp8pTvubk0VAH3zIi1SdXEyHL57jMrwxLIbITISHucrbovLfe1 3B18TjAV8VyVLlPKQvEruJMFvygUOS8Nf762iWr71U5ZQHNqr3UgmFqa2o6McFxWpl/1VC5EWBn+ UoqAFXHLvQDuuAPwrYuqIkY4Lua6z6xqubWnQGSkPQ51e7t0PNTxyOzhKEra7GVRiMDzpSbh7a6Z 5Jw0e4zyf/arJFmW2wZeRWtHmFEcajpHn8G9+rXx/RfmazCZAFmTLLtDCtXuvWwWEkgQSfKW2VMW mEE/+ginkSHBMGTGiDAyhYEd6SYIgu+0QWkRJKc+A4pAxE+TyYkIIwubNiiyAdGRjtbs5f1oeazl pdlLEluXun5icKOXr/ziprg0iUoxN8ye2cISSFkcgNJUADpwHIEwLpWBJWkuQagMv9QiSEZtAqri CiRvbFMhjCtc2qTIVRAT6WDNbtaPjvs6Xpi9n908JW32JilBZI0y+8kNftYAVlybfZkfZQZmoj6j byYKCGTg1AFh5LDyXP7YkWIDkt9lCa3Cl1oEyYklI4PJLatvkGk2lzyFMLKwKYMq1SmDMpGO1rCh j5Z3tLwy+5LE1qWuKXWi8tXofIpNorLm2uxVtsUSegcgYwWgA8aRCONK/5RJGS5BqAy/1CJIRjsJ YNgLMLp5tQZBhHGFS5mU4gKiIx2t2cv60XFfxyuzTy7Mxut1ToJ8lihnjznUooGy4IbTS3DtBKTD 3OtxEiS/pAIugjJgRBAZ9Wp3IhsQfPcyX/7w6Zz6DFgykBxxtI5JBJHBpt2JbEB0pKM1e3k/Wh5r een0ksRmCMouB6DzRFZxSAbBmhtGz2RhB5SmTH9Nof4/jPALjCIQhNW6wI00lSDUhV9qCSQhVlwS YMEVGBZzPVYI4oJL+5NyGQF0oIMlqPX1iHgh4pXHe5eiNyavcxJkcOOoXX5Y3bRE7fIS5ZbNUxXY QD/0CKeR4O2Fjwgia11gRLoHguA7bU1aBMmpz4AiEInRmgARRhY2bU1kA6IjHa3Zy/vR8ljLw40/ 5z8zQYguBHl5yCYOefZXfXcpK36pb3IK42IQrDnZ+aWiHH+dkeun6oJIuDRMJgcgeaDntaEEwsjz GK0yhk2Q3I8BhzK+pAjISRctGWT3isEg2Yl8KwwQRha292dVWOda3aYQHeloDep9PVre0vJw508u +lST2LrUNSV3Or7Kg7WMBkExJ3u/HCEqWznoVHMmN0ZvpAFCIcBIBIHRQHUYGjJBKA2/pAolpb0E KAKQIfkmJSAIDLL3Z1UKlgyIjnS8pk/7UfJIySvH96sbvdeOz6zKPUZWqGH0i5uicfy65objS3zt CPoAkfnnWBHx02QcgQgjS83apTSbnIVrdoZoXUqJgLNXF/3JwBQNJPm1EQYIIwubdimpTrmUiXSw ptb7erS8peWV45ckti51TclE8dXs5sm4Rl1zw/GZbTEFfX58LEDlQETKJiMRBpYGap/SZPL+oTR8 x1CF8trSJUsCumQgY5oaWYAwsJApn1J7A4iOdLRG77JHySslLx1/csuqHV9lVYDJDX42wzg6n6JB JModxy/xtSOQEfOPcBqZ5tBQAmFkqVm/fjSbIPhOuxRFQE57GVAGQUY3r0sjDBBGFjblUooNiI50 tGYv70fLYy0vHV+S2LrUNSV3Or5KLswGQC3Xhq+SLZ5AQjgAlQFCHcBIhIGpDExJkwlCZfSXEKGm 1CagKgYwjL4RBQjigku7FLmA6EhHa/azfoTcFfLS7mP+YdF2X5Mq/8sCPYjepWhv/Fhzw+1lgLQb 6MNDZr+mQAAqgJEIAqdc59gYlCYTJLh1xMmMLykBUtI1SwbBxSE1yLCYa7JCEBls2qA+xWl/0oEO lrCbj5DXQl4aveSwdZlrRm5yfDW4cbROj1puOH1NtphBN/rUhQhUIB8QhpXuaXtSVAJQF35ICUpC Pb9WAEjwwWREhIGFTNsTyYDoSEdr9tJ+ZNyV8crlh9VNS9Quz6wEKCvUFA6LW4xV1CU3XF7CayfQ h4bMPeeJSIz2qCHCyFKydifN9kFyqmkarTspDUpOpuZPBrpmAOPqG1lGeyesZNqcpDjlTibSwZpa 7uuR8o6Uh9veuzU/VuaQHy1r+Hyaf8y3pjksmeAz+2F1MaS65tfnq2HO8xkmN/ulIDrO6c4HQQ4b 10KZ8qUMyE+44PxkKYnEOTWUQBjZB5jUHTYi8t1PyWM+xX9ECGkxIuwhItS7wzYTqciZ8w4/Bmjk BMLaROCKdPxvsyqVTUaVUtlk2R7HZBpMRGK/np58tSeHs1hGu0zVtjNVe5MXsnusGRndkkZtEXXN ySz24993Wc5rxViBcTAPLoW0++CuMnoVMup7E90QZ1MykSlMjSxA2v69TeaQ/E6111xtU9R1yXAB kdivpyNf7Mj50yfkx92M813mSRcnSRKRu2H+aFgXfWEtYe68fM5KznWMS0MIBBWWFAi0m+DbG95i 2+42KbeiKpNG5jEaPyPS8r91+SC7o9kdMiKlk59IY1obNiAS+/U09q/X2ANLyOf7vNbp3name8cA ytU9RBeCXCBsmFNLQHwWnbsWvSk6317W2VACyefKvBpKIoxMhe+wEfmjs2OxbXevlJeQkVMQVkKB gbT8b7NqXaR3VOkHEZXispj+AkHs19OTr/bk6r2anwfBx/33ar1WEIGt8Hlh49y5IyvKckuqH/Pe tLp1ld5075fuJdS+g+6/jXD/6t8v9SWkRACy9xIrwqjaipOr2uDtrO0OW9uEt1HSD6lh+0HUe9Wo Le9V8L+enny1J4ezWI48qlLuID88CzSwY0Y/oHImzOkkQhmJr3MlY/EtwyhORq2YAxBqvkxr04cz Nmol3+3tOry8OoTmc3NHlwscpasAdi9ugURaduX2iuuOajfIiHB4kpvmqSH7IGagn9b+5Vp74Ao4 3MVktn7A2SR6JW47sxvXYG4S1auObeFOzbgqaUogsEckQaTdTV8fHottexsFbx9WRgR1lA4QaNnf elEcJ3PhFEQUSiGa3hKR0K+nH1/rx+HBnKOMsU7TtjNNexOHd8nkZi9Z2TinM9hPPR4HpMwazYax AnFODSEQxhWp3mZfQBlyQRm9inu13XN4drBkIuPgG1mAtPvyvSv5dbV3uNqmCFeYfMMFRGK/no58 sSP7U5gynJeNbkljobfTtDNx+ZshzPWrX02U0wm8rjd55/1i+IiU8gofy203wLc3u8W2vS2Scw4f q9SqAZnC1ChbkI7/raovXDcVu+Tq+vr+RBqGlg2IxH49bf2rtfXgRC4PDnVvyL2erfXhOk+1cSvg Ghvn1A/47sG9iC8avjo+iHm/hNXewphoj5SrucFwAuC1pE+AG9en7mLGOOQXofYQZnSv/t//6mIL eAcNuetL88L7ILtv3Kcj/++OHEyhfXdu6tN+5ngBqfdwDGH7fD0Zwj8iL02WztAj5WZusLQYeQti HmdKAzyOdIFA+D4ZGuOncj3CnG7Uf4eeSZ89mKJbBt+QAZFVf3THPy35XS05GEMzUNvuzCE6kf69 2szlyRR+V2CL2abTZT6Ss7wK4NJETYC07O89KfPdZFxMYURY2CVX25G3UREHCkPLgfKzZpqnRmkg Qv/9Df/37cfraALtMG27A1dKqZfvOOfvz2fyZAS/KQyxaVjN9hJENmGvQY4avdkWRLDBGAkZULke YU436r9Dz6SB1MAimnCNaW3IgHAIn458qyMHQ2jnadsbOQRPbp2lEr5uMYTtWJ4MIZZS4HwNGeyb kwjrEV3qs5d5doAk/tbQHEfTS0Gk47aa7YOk1ZoMEXSTkcAPnfYQpnSn/Dv8zBoII/MomPO7rWUD IqteT0u+2ZKDMewL7qcOwYjkS+4Yzay2k3kyh9/V2GK27zzbRXVdMpB5jI0IQFr+txKGteV3hS2t AuzVNVfbgrfREcdKDS2nys+SuCyN1ECE/vub/m/ckMMbqZ2nbXfmED25Yf0kngY3hPO5PJnCnrIk yy5UAO38b4Wx2LbbYGywWl5Folvm1UhApOV/K1lqZRkJ9mqhENR2h61twdvoWM4VFVvOlZ81YfKN 1kCE//V05IsdOZrDZqK2vamrSMiDFZo5PJrM4zn8sjawf8H0gRDdMJRbUFOQzkmXKIjmQ04SSefU IyGkujt8nBoFBKmxT9aoCXq0vKHl4RlkS9RnEAiIeBfGg2nopfqHCbUu9oohiAQP69wkIIh3q08l 9/M7paRq4yP5XlN4HuLrAlsEBd7r/Pma1iv/qCp/vvpPHHZttqce2SM3XfXBZGJceKu51ibvvOd1 +JdByuWv9weVYo/Ua+2tybOl6IxYHJFyfvfuUPl7RPlTjjQMbf2CMPbxGvVAeHS80PHQU61fbuqN Qr8EMuQRwljKVz0C3/14KkMNIZo7nCASPIVY6TaF5BqSP/VUxNfJy0ON9g9GnSoQP01NOUAYWXJ4 K1djpkB0pKM19Kv/lSp/vvoPd1kJ5xc3xSX/sMzpt396N6f5t3//Kwe/aLBf/8N+levakRvRL9A/ KLQdNJpbk0wNO3Q0ipzZhhUY007G/w8Xl9pIdvd9mhlAEC4EvPd0UDy1NFl1agvGyAQ7ItLp3Brx Ro0xgTCzzX0JwBIrbw2JW/CHLjpg8fAqpobICI4tZTMgR7QqJkaYuXkTRe/ZiaIrpisbzPendy1f quVTmzRhM97JNtkR6dKD0lFROWBLCsFD18qA2I5tN1GVpiGyEBwDIjBlrGrMAuHII20K+HGkt4bA nAlmyM8cRvatjsiryHVChHnubFqMP/3A+T9eMbN5Z9QVs5vb1egw+xaCvmMz0nj0JAYqk4OKvSFi 5nR3sgYwTQw+j/vbKoNvXwvDYI8yVEScS0M6iDBzi0E+ZI4UEcl0ZQNTNqkp96ur8v3lf3nL8maC U2vYqNxW6g5PsY3mue1ks8u8Ob34EfBr975XNApHxFY9ANa8HZDenlXTWLivlcgeZsi+Icx9bcPb 6ruOT3W8uvPjKjbd3cX97mfIQnHc3fZv2fv4s/UlT0Q4ImLtowI0bF0SnYkMiHNjBK/N9NW4QCMi bo3YOjn7hhD1jQ3vqu8q3lfx5qbvVj/bBGI0q17eEVb9dIpsBp6H+z64BMR6L5sAIZw3LA85iv2S A10h7VF+rZhLSW28HaHl4ycRE1mJCPiBI8L+akzEJEs1I614XyuTccdQgYYQ962NvGTvWj7V8lLZ 6JsulI3ab3F3xf0Wg5gQHj7XykZX9VTfAoXS/HW+dQLyBOYEcaH1JveZrKt6qm+BZZi/DipRZJKl mpFWqtfu0I2N+KbvWr72Hm8VDk+nsX+ve3weHrFUPI8K50OjcO5aoq+MiJyFr/VWZDI+q4gaIlWH jLohzHNtI1T4D5r9074onsDcQxE5tpSNlDXCRvO8tC/y2+xCSu6jbnzj3/bm+NUXTPaBYzui1XuO sGoBqPzc6K1FhDyyTDPSCiflqMy+IoL70ma5nb3ruK7jQzflNjze3cX9bmeUplZy66mbsrri14uN mRGcetNn4089Izz0XikJBkQ25J4nByPsbfhqXKAZoVsjuhBn3xCivrER6uFdxdsqPu2L4kGi5Ilb PHC9aMix7SbKkcM2A88r+yIPFJyO6vEgwhqyqay4BX+osFZIC0toqo5JTSX60pCQjEmmiAj781n3 IS7VjFBnwhmuKtAQ4r6xWexm71re1PJpX+x0UtmwjkEkgJRy69cwh/W4L6oK4rfg5zZ+nW+dgDyB OcGGhC3mNCSYd7V1deTn2+/OPNc2/B1+3PzvlYS6nLpPrntpXvxf6Gb57v1u5XjpyH0HkS/jRpPw UCB2DpuRPpnmNy1SmxHqKjirRJyIMPe1DXW136wm31v2j5vZ3L+4WyHi4LDew9hG87yymQmXXbLI zc+NL7O9Xg9ZBBXUjGBQX9VbLZh8vX7bgxk2CrbqAcj83OgNI2o8MqIZsVHrPpV8Q5j62ma1Br3L uCzjQzflNjze3MXt7mekdlWy5mEv+1gXmL8aRzgj06q6KAkPGM6k25B7yl4g7M3peccFGhEs0VfV gzj7hhD1jc20Br2reFHFx72M3yNKp/6SGLCb2/UShiYDy0tbWYtfqnb5dBoiVZ/P+sFzmDNCLQDl U4WknrJbDnxzRDYyIJEeAuyrxYM8skojgiNRbhEy+4YQ942Nvl7vOt7V8XEbo1xm6YKI2bwz6zcw VelPagiZwyiN35Cf1VAk97aXYE+3YnkohKTn0OeC4vREfg5zhbT0XvrmNyarufyrSvLdJf8gHeS9 lO/0onvmGyXxqBw+NGLmniCa94jIGfPKi9OpyIg4OURI3s1dQVRoRuw49GT6DWHqaxuhkt9lvC/j 417IT3JunIjsWwhRCRi20Twv7YXssksmuXe636YHcBcqmOxL++ZcGhYatqIAcFQQwN5aRMgjyzQj rXBSeMrsG8LcdzY0q991fKjjQ3unsTBe3cX17kfIQlK80N0/1ATmj8ZlHREhp14qiE5EBsSpISK9 Dd+MA5oRujPUg2T2DSHqGxvuXO8q3lfxcS/k54gCjDt5R/a8HQmVSztFNgPPS5shuaSRJjdPRDBv 1Hxms8YqZb5C2puUCq9hQuJBOv7g29NiIiuKQL5vRNhfjYmYZKlmpBVPigNZgYYQ942NvmTvWj7V 8nFDbLdY6Bq+6YSkLakNcQJ48FyrGl3TU30J3kDHb/Ot04+nL6dXEYg95C5Bh5qe6ktgEeZv02Mi JlmoGUmvX6AbG/FB36V86S3eahueTGPvXvf3/Pla7Dyqmw+NwbljiRBnhOfga30Vu5Ozeg1siFQc MuqGMM+1jdDfP2j25WalGD6Xn6n8TLZ97QSxGyOVSPJbzEk+gQwxQHp73PajAfCWfLndB1zRUgK3 uy2kapLdUYFjs7sVLA6yDE7SOJO3CD4FjQ1bClHyOMjSyLo55+C8FzrRuQA+gkJAlpUczLHtpjwH 5+FL1KrFLR6Vxzv4C2ptoUYhKcRt1vp+KmWI0B5bNM0Gqu/BlwUPrsYMrziAdYRI27d2zsOjh5o6 2+8Mxcw2Nm1HaSvu2IJvCGQIdYlFLx71VMknQDzlfoVWZmgntthA48pe1pl4bM5bOqI4ZTPkVRQo IwlamMmCxyZTb3OESLOtPHgzKGYbSxWiyMtGyKtcDVds69WIpZpgA/n5o5468hYKjwUVH41ETPst TsH3Sq2BRr/ttYHTNhDjFsR6Nt7c3tLCEVrjLI3QtTsecx0VvBxOR+nSc/+cn0EqpfFCSGjeGsBg dK6Y4Tllo9/T9MA6gA9j8l1caaNTEbfXww91froB3tWx8lWptdW5YKIn3yNatAC/+RAukKtwwPt4 8Fz46reeiuoKZfQKmToQ2jDNGGH1juf6F1xQQ6P1pb2KVjY3N0S4Ryri5mywOhVTrxq1yblxYtVm b5VcmxVycH2owMurTLImcwsWyJX/4m0wOxfc0CZ8HZSOGuPc3hFB5TL7L96Gg+eSHPpUlkOARseM 9Cc8B1SdKatzSQS9McaHqYQ25GzwXn0po/NhurVuuZp30OKiWZ66jKe4H86dPN8Ed5+BcJsOly6m a5+cAhkjqu602XlB3obwPKhnBLaCFJYBVHf64LkkR4RVgN/KVxLA6L9yK6tzSdTLJOQEMjEyOFNh N6tTMMHb8EGWlwbvQqogQuOaeAQyRlQD0AfPlTtYeQ7FvRBGiJAwmiKqT0CbiTsoyFFjzaoLHlWw S3eVXJudS6rWOIS3DrDFJOjQhDXfGI/sJCK1kdrGrvFYGc5aERHQcdaogGSug9kpyKGpxDYAoM9m qTpnHYoI69DJf/Wmzc47SbsQuXATnFu6q7NMm5VZBv1IcZM4pqIs5DJMNZ0u2VxHVFWBPngu3aEW p+ISwjZjAJ28Kgz+ThMVyXo6OAv9kadrOW12Lqn6hjAjYouAdhazKAvbMDKGVAPQB8+VO1pIMPLV ilKuf1BBjiFVBa7NziU5bzvtba72n/IiC08R8HkZQHWnzc7bVYrWpMVy1ZcJXq6mAKo7PIgNZEFO e9rN5jbwNPLB7FxS9cWMpspqCUTkOoDqTpudTL7YJ8v2ZxVCG2YsQ98rZAygutNm55IcbaZlVSBF mUQxe+cAirvB7Lwlx2nPp2YE3SlyVBsLKnKHmohsTPstyGdECpDx4Lkij/Bppd6i6pJMnf3Xz6LN zhVTKxhLULooJCYZ6WJ2dl+dKatzSV0ug2LuABEPniqvtDkXJPje2A8hxKv9AO2fv3yCGlhwtsM/ +NOFzzaBQDSxlT7DnPxyftqhXmCzGWvrz/D5l3/999Mf/vK3v3/+8u9f/vfzP/75xy//+fTXL2CY UwKTbHwxhFWwGLoDtscylOhlEMJy5jAwifwSwT7Hp1ZIF2WEYFeDWV8VL09NBEjuHB7uS1DIZNIB 9oxnVgjGggi7ho02xSXCrhDhDGBaH3aJ0OCnUzNC6oROzQifivCx/RJh7wnaX14iXA08xdVgmxHh b44Ie0eE6wPCKLklwlXNoACOJfIKD9cHEY4HeWaEeKB5HSocBChzBnq5oJuEfY2QI0KYF6RsjEuE Pg0hlBTxzAiJVDo1IxyPg+eclwgniqdmhLYfPMWLJCG0/UFThNVxhQhmROg6xQA+jiVC+xBIhz2v AObFMysEvxYdmgA8c9R2ukK4Ev3QCIisu2eSFIyUsZHkoQnAkUueZ8SU8SwP0ZQkACcMeV4gOJfo myyQPofoY88An+l3RnjqN5amLyMccHtkDOBL5SQJQcVA/caW8a56ki2ywcretkCooNhZ+SsIpMkz 6tALBMUYzZAFUjRvEsNpBuiS0ASeEaEpC3gI7XsqxPrUD/62Nu3Vf9QG+lJvv9+pTX/EaxuUNiCS dt9t4hEJaTaxrmfM0xHgyTn8Lja4KX3IBpjTkT9sg0vgx2wM9Cnzu9i0vvxRG7sl538nmzJKPmrj trinl23+z365JTeu80B4BWcPWQGL98s6vIRTlSfPefn3X/XDgsAm5TgxM1IsO3qZqvR8bt2ABkhv XNtJyUaYXFxVmKGAbW2qAJc7CV5KhggKu2wOYtcE1xCdG+l/2hpipa1F2EARn30wY/3zugzPJ+SC zCfkgsw5+EARn30xp93d0X4ZdMYIgw57dSZQh7hhJigfwtMzkY4OcZiJytm8U2Y6CpHiHW+JlHJ0 +BOFT1QpdDZVEJeDOIjvEOidKkgLPh2BDKyCROkLEpiIVZDBugFxutMl9osb3bXrD3S0llvXuUAR m4N5XQZ1PMKgHV6dQaqNMAjHZ2YwnUYYDLmDWYMJhjcFWUfpy+lYlfOk+NKvtVDE52C2ZNAXUKS/ DmZ95rS7OzqYNZl7Omz/qXDNJOWtGWaSstrumsnKFj/MZKVTfFpGJnNWJoduMrPSTviiTMzdhG99 bjPFl50y/OxF6VC6Z2elfYfwwTsUn8+YvX73+xiXU1cbtK3lrjSo8XuXKojJLQKtVQXp0IcQp3+0 MqTQv9ZO/4a3//373wTaaBc/nV4DCxfzpFzADtwrkoyJ7H2nwJhv4X2irA9dDkOB09YM5hQUmXdr MziJQpET7dqMU0n3z+5UsXETxqpM37tndLAH80DmsnFTNOnSfTHKJpuqcu4UfGfu5/Zq3M/XCl+f +5mi0qTF1UQR70cw6I0RBj22NoNcGGGQLyMM8m6EQW6uzWCwXDNSU1R/xnTVykpb9/CBIuPvYPbE fP1Nb9cGfLZntqv512BG84cnT1Ah8i5MJ4b6NxOl2IWLKHA5mIP5nGkr9X6mrfg1mNOPXm2/TJur 9zNtPj8vQ5Ot+GGGkjLJJs6ZSWmaQ5OZ/HebvK2LKHDZG/P1U93zbl6J2aIGc3Zv7Z5VVEnhrd2z isrRdz5QxOfvGPQ6FMmMRzCYBFBkonyXSSG2e03SKvvUbjakJFdan6rUc16jzOfFhzBOJZ07xqli 464Zq7LzC0YH+2PMPfez93f4PeZ2/Zx2U9HXzD1deM3Ujl+dqSk1xNS0W52pKT7E1GlwMAezMcPp Et0C4rHLysXIqGRxTOkVKWijgnaLEp+N+VrvExSN67oHCoyehUG6QJGUOph2GkCRqfJdhovMq1i4 WK0KxVflPCk+x84Hivi8OoNvMcLgmx5M2+8jDHJjX8yp6R5EvcQ4ol76CVEPBVdzKX0Y/h9lfXs1 UWRCPYLJyhY/zGSlU3wYU5SJ+RtM8eVgXpJp+7mluJ9ZabuXq6xXpIKkn9uaYme52nuTKKhXKHB6 FgY9D0Wy47sMv8WknGHGqZihnCclpNT5iIIshSJZ/ggGsw6KzMy1GewmUGTHeSRzmjQfy4Lir8rK uVOwY3GPOZV0PzM/UoqNix5j7U+n4He/jbEqO79gdLC/gjGqxH5vt8qkvGtGqxxLxxilc9yCsUWV 0u/kWlnjNmKM7Z6dFOfKt5kTUqCjpuyYlSZfbKYsigvFeknyKacaBc58tXck3Oz0p1PgdDBrMfiq IwxqaGWmqekxRnpjHeZS914577qOpumJFj9DQApI1bfX4qq/Uuarc9V72kHs4lqswHttBqk4wiBd 12HaDQazRfYVVppXzUbn9mPgWvK9RBFfmWJNvnTXYgWzbr+M7B0jDPYXvOdsuopmof1gsIEiNs/D 4PWAkdd8MOsxa4fCqzLtWGmpRbTRidSFbtCIgoQOND362bPMv/eJctZ380CU1ulgfpLBhx9hUGYH cx+DmBphEHf7ZWTMjTAYl8/MeJVKGWYoYLM5mM2Z9lvwdMKmGZXTqSrnSTGldN8divg8D4MeBCO9 vFcGeYhfSa7ulcGsxK9k5i6Z013UDzC2qFJCx2jqEPdLGGO7r0qKc+UGMycHKdaZNjlmpUmgxgcK fPbAZGV9N51I8TE+PZMUnTc6JqlQ7MOYqILuv0VUyeSHMUFFGzsmqOzDJgzN4eA6xquSzNMztCmk smB0yU/DcI7RppBlgnGOsdLmIXxEgc9PMFp3GU6Kpac5GFZoKzHdJmVpK3H2gYz2/Tw1yob8IXO6 i/qM0crEbl8nxeWwZ8bQplBcy5ASjNk1QzPWdJ1KSnT5VzA0z333TUlJ0b8Mw12ol9A0Dmbl3Cli HZR3gZSoYrLtWPlQyeXSzO8YR7P2p1Pwu2dhgkolLxht0saMV867SSlahjx/DVaY8cF2PqK0Pn/D 0FpkQ8cEZbz7ZYyjA0iZGO38zIRYBUZCSp2NKK3NwRzMczCWTr2pK3mnYobCjM+xiw1RWp9bjMTP ZToZOtO6LnyNot2zGSuX34WC0GwVBBnuWhQ4c9C/T1o0y6uJIuNAFAzMa0bTJjEhMYTupllhJLl+ 6RClGc6x0HH08krqWkZKSaEq7JR9qk69IivOfENVaIx5A6Snj1nl7CbNa7u42EU5T0wptt1tRalO p0nTutvaSbE2VYXvwFSf9u95i5a76RRx5dMB37MxaXElUepJIyY6q/j2zEKKC64q5w/vEMp8Grm6 AzjL+eh90qwP7YmtKkJd7ikqG2177iXF5yqcm5tko16Zj4f1BqCIsVM5lfmWaINLi2tNgjCXG6JN IzNUEtdaUFHHqpw/usVZEJ/rq7e+KUip0ZQ0lxcSqFK5jOh/navK+cOrQ2Gna+/WOdpYrxatW1xN FKagREVtcoOhoPMTEqkK2ptmhZFLw1jq4cKFNguR0oYfgrLJlwnx2c1IDrkqzMRweSzqV6r9P41C BZD8FwzVrc8HMytFOVeGGUoja/bMOE3HK3eDoYlEVXJhjPYzk2KqCjOJkrf1mRXyKSVswlBu5jjK kHOOZZihZE95mKGEjmYThgI62GHGquz8RkyxcZihOOMj5l0MvXHaGy5KNsJk2hJEYYZWrdamCnC5 k6A4LmWMoHGRzUHsmuAaonHMO3mtIVbaWoQNFPHZBzPWP18zpxW79WcZnlBIBplQSAaZdPCBIj4H 85wMOmOEQYe9OkOHjuSGmaB8CE/P0FnJx2GGTrQ275SZTnykeJfbE9+s4NzY2FRBXA7iIL5DoHeq IC24U+L0CYMUrIKE6QsSmIlVkNH6MCL2axvds+sPdLSWW9e5QBGbg3ldBlU8wqAZXp1Bpo0wiM9n ZjCdRhgMuYNZgwmGNwVZR+nL6ViV86T40q+1UMTnYP6WOX1KoTOgSIcdzMEczAhzT3/tIxXGmKS8 NcNMUlbbXTNZ2eKHmax0ik/LyGTOyuTQTWZW2glflIm5m/Ctz22m+LJThp+9KB1K9+ystO8QPniH 4vMZs9fvfh/jcupqg7a13JUGNX7vUgUxuUWgtaogHfoQ4jRJNtoFND0wCxebpFzAttsrkoFJGec7 BcZ8sfeJsj50iQsFTlszmEhQZLKtzeDMCUXOrmszTiXdP7tTxcZNGKsyfe+e0cEezAOZSztTCOnS fTFKIZuqcu4UfGfu5/Zq3M/XCl+f+5lC0aTF1UQR70cw6I0RBj22NoNcGGGQLyMM8m6EQW6uzWCw XDNSU1R/xnTVykpb9/CBIoPuYPbEfP1Nb9cGfLZntqv512BG84cnT1Ah8tZLZ4P6NxOl2IWLKHA5 mIP5nGkr9X6mrfg1mNOPXm2/TJur9zNtPj8vQ5Ot+GGGkjLJJs6ZSWmaQ5OZ/HebvK2LKHDZG/P1 U93zbl6J2aIGc3Zv7Z5VVEnhrd2zisrRdz5QxOfvGPQ6FMmMRzCYBFBkonyXSSG2e03SKvvUbjak JFdan6rUc16jzOfFhzBOJZ07xqli464Zq7LzC0YH+2PMPfez93f4PeZ2/Zx2U9HXzD1deM3Ujl+d qSk1xNS0W52pKT7E1GlwMAezMcPpEt0C4rHLysXIqPR/9qslx5EdB55g7jDrWQipv3QOH+EBXrlm M/cHRk6KCjI/Tru7un6dGwMVFUlSFBkiHdYUjXBBWxMnvyjxbph8XWdSsl51DxAY+i4cqAsQVqmT I18DIPyq/CqHiiyYVKlYnYk1DOQ2I6EkZQcI2/npHNzFKxzc6cmR/f4KB7rxtTgX0T2QepZxSD33 E6QeCLz5nDfFf0vrpTdG+IX6DE4xroaXOcVMOX0apxqbyi9waqgn50dyZD9LFvUzIbJ7qco0whXE /Sxriiyzt6tQFNQrEFj6Lhz0PBDWjl/lUBaz8ZY43qQC5DYjMWdlhxFoKRDW8s/g4K0Dwm/me3Mw mwDhGeczOZcZC6kuWHSrhNwUghmLesybPOk3cwupLi16jLA3heC7v43jTPFhwZmi+ys41tSk53Zn bC5fmjOZkqriWDOV9Cc4rppa9Uw+GWf9H+JYp87eEO/rL3MuUAHFmrWjI0JfXGlalBaIC6zks04J BJbJ2xUK1y29KQSWTs57cXCrr3BQQ+/METX9God7430497oPxgevOrq9nmjxGwCoAFe99EVVv0K6 d6r60GYQt/BFCGy/Nweq+AoH6vo+HDnB4G3heYUQkWoydJOXAV98X4ywXX7FhL4oX4Tgrfu6HJ47 XuFgfkGei1UVTYC8MJgBwma+DwfpAYfTfHLej/PeovBTOfJZkayFtLWN1Ef10DAChY7t9dBvz1L/ rjPLu6DeA0akpZPzkRxc/CsclNnJeY4DmXqFA7n7uhx+5l7h4Ln8zpxgcq0vc5rAFnty/jhH3gW9 Tpg0k/FTHshtRmyt6t6BsJ3vw0EPgsO9/FU50EN8xbr6VTl4K/EVv7lLzuUp1gdwXDW1RsWZWof4 v4RjnbrVhnhfdzhdORrivJXK0RGhQMIOENj5CpxiXFCvU0NCSt+ek03bNxQnm1jdp3GSiZO+i2Sy LZ/GiSa5pDjRlBD/CKe9w9ErTjA122/PaZNCrgvOVMu34ZCOtUmh8AtGOkaI1EPYYQR2PoIzTUrD G+LaaU4OIW0qsWqScm0q8e4TOVPQ76k1LpZNzuUp1iPOZGxS83pDfIlfmWPbpFC95DQkWvulOe2N tapTG5J8+Ss47T0P6k4bklP4MRzqwmlJmp+DjtwUwqajCT42JJmUnXxWNpFS7818xXPUsTeF4Lvv wokm17LgTDb/YU4wPvgZqRM/8nQbhBAnRKfsMCLt/A6njUUuKk40Nvi/jOPbAlJnzuRD58Q0AKLE nJUZRqSZk3NyvgfHta03q5L3JhUgxAklKdlgRNrZ47D83F8n23Zar8TXmjZ7imfl/l2sEE2JQMgQ NSOwTEJ/nbFkl94Y4eeAETyYa87UJomZkmJUQRNClOz10MGIeJxTbevoPSVjLGtIzXEgZKmEPCxp hEecHtAAhGGaANvpUzGl+BkLk1s4uyO3mVOrk7MtI8PSZcamSU3tDXEuD4QisMOO/LtP0RyNQtgq bQcUs7V54YmRsWmk3HaVIHeWhvjoB3LbjBBI30ZWEcAy70fXGXMhyo1tIMy6x5SMS07uvQ0JZQA3 ESQZ0khfD0cAQNiwNyXXHlKb4PLC1www5x5QmzQKkWqmWosmTWkgt60QO8B21t6l3Ry51Norae8J ia1SqYzaf70fyG3TOxCytLYtLSeXhrfk/MIbI8QCkkxrkx1OE7owU1KrAhk0IUS5N4xrPVyp0DqQ mtrQIZo2hTpTQvGdUmIZCHFSvB+r9Wur/TeBtALI4YDT6jaUD+Zc/jWZWsq/22/rjCY3bRD93z// HdIjmgEJuOdIpMR6YzMr2P2jqWmAFX+PRrj+p7mzrYLbb9PV+28kd6mJcQ4qVNvE3A/kBlkTZcwI qrYLpEBgmY58nbFc4sLbjLSHboosP/3LhrksQyJA+B8HFkCsVgYkEJglV9eZVeYaRad3RFna4Sg5 OBN5kMj9ku8bGvRmWb/rAuelzrZVTiFDEPdrflCHdvUtpAM3CbAMPXNRjPD1PpuX5XHEXiTP1wFn 3dM3BaT0i+KlTB2e1rRhep8zEnI503iUxt165zfft7GopG2NX3fAsr6XZh6q/NojDSLj2wG0WTix 7LB88bO2FKKl6LE0faAQfmgRHmfx2LkImMNhs5x6DKDK0www53Je6ne71KYD1JU53X9ZDHgAxyC9 O/AhgsVCcFvZ+e2Zj0d1BAGER2p2CeSlUUU+JuNLpIFjkode7jxAsJfofUZaJm9yw8Hesb/hrDl8 3mfHvr89l5e92u8LIvbMdaEzgq22fwSVUVaeKvxHieHtEokBslhsH+cFNwNnhLRMR6++C00lnFpu CSFnOaokdQBW9hjI/w89+m5hceViXFzXESNjxBpfuVY+TiHjwTiuLXIgEwyX3GKoXUbwRrHL9QvJ p76qfMIbIVs7KdKAmJYRyEMTYk21OjFA2DJ7k0IAb4xIS3uc7bjPXO7l8khUKQZZ+ih0RtqqEpWG rgA+SSt8Gai1UbUsITeVurszmUwZ+OMWQuicYiSUPcpIGZmC1YdhgA1zCFdICeLsgDSzzfBmmuLi 5n4vIV/s6IeyOhlf9IONmDpia+NaWfG2tJVWT69k5ylZfZQYbjI2JxGb0sIlI1uZ4auR3gjh7+Rl IQ0c0yoClQZGXPUqMUBg2Y7Vixsf3jqiLO1wNuM+c7mfywNZ7TGI0hdRMYJC7x9lk1OQAH/zROE/ SkzvfxECEE7D8PgoL7gZOJuRdpZgF09gP58ISZ2YApBHZiSGpLPCAAyTM4iUyHcHpJltBq7yzOJR Fo+k3qYWm653xMQIcW7qq8nmBUKc44p/mBhufAQBhPPALh9nBlcDb4SkxnaLy0IaOCZ5aIpAHpqQ aHJVL55AYJm8CXnqp5PyJC3tcXCnZy6fyeWR1FMMsvQRJyPR2KAUIhiX5d98kCfq/lFeuP2RF0aQ he7xcVpwMXBGSFt/nBprm6XJ84DIzu6IEF/kqAOwssdA+n/o0Q81da6Rt80qYqTtD1lXuzN+Uhsk l9oTlUX2ZXrhkftrFC6AKdqFQ0bYMB9Zplc64/TSdxf1Zc8BR7TyLw/MyFTSIimMwC75khIwfDEg De1QtmI+07idxt2Cj20Qym0gaufLPH7M+2k0JbBKzEDz1zuXv6Ht9Lay8rDglXnRvcJhNGlKwppE cvQLj4wMw8nxtEddr3zNAH90kafD+SmetXd5XkamKS5ywsgwTL6uMylUnWxGpKE9zkbUZxY3s7hb 7cm45NTC2/tLRMUIcW7iK+wj2s7Demdz1D5vaHLRUMmEomIYAKeBHQJB4CXzkNe7XvkixJpqQ78r fUAZkTzyHIA1LhYNTMGqiICwXfZ1nVkeSvEGQNrZZuAuzxw+zuGhtlMEQtsRYwcQY/+mr6O3lZVn tB2Rsgqse156ZISTAI+MDMN0c0KVpK8cVVYWp5PxrL2jt4HYlFQ8QIZh8iVVCc4YkYb2OBtRn1nc zOKRtosNl5sJUfE0RRzRgn0Hva3sPKXt5ECqgHwq7k0v+mkArnrlEAjs0pmlLklfNOPxd0KXujsR 0ToAeeIOxJAWSWEEdskXdEm46oC0s83YiPjM4WYOj7S9RwBtFzF2ADHyN6ktIkojBudQ20WkXQXU SzH3vOguIMFW5RHIMIyskAgpXzOArCxOJ+OR5yXv8ryMpOwWOWFkGCZfQpWEtDAiDe1x+KiXM4sH WTzU9mQmm6W2i6gYicYGLQrBuKwAMvOMtIvMsAisep6tDSCaXPXrAgR2kRgWIemLEP7uok6MHFBE GwEgBTPQViUXFzlhBHkjX0KW4KoD0s42YyviM4dbOTyUdopASDti7MAobP7EN1t6judjHCs7AmUN gD/ueCSFEeSAPQLphmVSugRJXzOApIjPcHyKZ+1dnpcQZ2rUGglkZI18SU2CM0akoT3ORtRnFjez eKjszvgpKGVHVIwQR3bgZGLU0s6cJ6R97h6pAeKdmDseEXQASYA7RmB1irzNsAQJTwQ4MxV+gvXp ZDzyvLN/a4K3GnDWqYCAwC75EppEBxOaJO1sM3CRZwIfJPCozl00JURZ5y6ZNhKplaW1VrYyqIZM +jXsdp7aTtszWZ3arAj5P/tVlCw5igNPsHeYExDGYGOfo+5QX+37/y7PQmQK47JnX2xFTIy/uisf KKUUSgNkqNEImMe5IVQEcUOKtlGGSxDdx289FkEyOiTAGhQgTaERRRHEFS50iqgKwHH6K3oZPxr2 NDw97YtbllDP7c/OlA9pNEkqgrOtu4Ibx2gQXfPhtB8H7NCXJcdNRhcgKsPihmHtSvX3hGGJf9i2 XluUngtWZBgmkxCQtnfvfZX3yZApwpHO1vTSfnTs6/jhzCvBTxLbIXOm5ERl15iP9dgkKms+nPly OaNsywWOKLPDTDxCQPKFMK1mFIEgMrQpdzrDJgi0wU7IoDmhaM0ARSvi3eqjyQkIIgvbe181xqkx GkE40tkarff1aHlLy0u/z9egyfo9pyXIkKl1JPddfs2fHs9IiXPL73ncdls4moBGY2SIyijTBgSB IU2xJeYKHId9ChqUhI70LIEifp5NQkAQWMjYp0CmCEc6W9NL+9Gxr+Ol30sS2yFzflTwCd93+cXN YWkSlWJu+D2yVT8ApU4/tAGiSmAUFUFkaKOOxGyCQBvshAya0yEDKhpI9MY3CUFkYWOPAltBTKST Nd28Hy3Ptbzye59cmiP7vUlLEFnDfj+7IY/Yn0OcO35fRgm2YGZrNwEzW4qoEJg/RRB4XPXzLLZk uHYgP82iNkv3QYOSEBcs9LNbVt8gczLXPUIQWMjIp0pp5FMm0tka9PPR8UrHK78vSWyHzJmSE5Vd k/MxNInKmmu/p2yLH3SmH5RAVAkdRSCILO0jjzJsgkAb7IQMmlMvAx10RSaXVmsPQBBZ2MijiE0R jnS2ppf3o+W5lpd+H12eus2ogKwE2Zewt4ccbDFIWXLD7CU8eQJ/OsQBeLAEyW+qUW+FMmpANLBW TCbFXIHjvMy+HzZK6EjP9QoyunWyrglEAysZmxTIFOFIZ2t6aT869nW8NHtJYjME5XwrwHlqVmGI BtE1N7weyaoXQBqd/JoDgGFSu9AxVEQDszJqRkwmCJTBToigKaFmzQA1AxkWc0UmRCMrG9sTeYwA HOhkiVb7eoS8IeSlzXsXgzc+z1kJMrhpMkY/rG5eAiMlzi2n50HbDeE4/hqNkdHb2x8QDczKFENi rsBx2KGgQUnoSM8SKBKC9QIgCCxk7FAgU4Qjna3ppf3o2Nfx7MynId/Q/kpjyMyx7NwP75gHfzX3 lrLmDzblFKaFAV3x4cCXgnL4NWmqe9EF+SFc8/8mk4IiwS1pLUiaZoMgcpqCFcawCRLyav0q604W QXKqJdcMxlzXaBDvVh9NTkAQWdje+6olP5e0uo0QjnS2Rut9PVre0vLU7JVAktgOqTNlPeh1V56r ZTKIFvPh7JdvB2VbvnGmO75RxjcqyDAC0ajaPfoGGiZBoAt2QgLN58gPAeT3EH2TjyIaVZnk7Kzr 2IgtCEc6X3PM+dHwqOGFyfvVTd4bk0dOemeRNfB0v+R/2OTrihsmL+HZBFgEGXmeJEX8PDfTpggi S8lsTMwmX7/VjWuwxmREkK9tLVkzQM2ERG/MkhBEFjY2JqmOjMlEOllT6309Wt7S8srkSxLbIXWm 5ERlV3Jpjk2isuaGySNbNQTujm+08lQzD6MiiCrdY4NiJnnpQBc8WCCBPqy4YN+UK7+nOJt8gCCq MJFBmVMhCEc6W8Pn69HwXMMrk5/dshqTp5wUmd3gE3v65HwMDEiUOyZfwrMJsAgy8hqOkTnp11Fm CwgiS8n8xGE2QXQfGxOLIDn1MigiVGRyabUOAASRhY2MidgU4Uhna3p5P1qea3lp8pLEdkidKetB r7uiG1OjndRy7fGUrPoBS+MbYXwjgswiEESFLOpGzCQIZOGdqgDysfxUrfwcJnMHJUSDKhHbE0st CEc6W9NP+ZGwkfDK4UPGF+PwNSUFZAn5uXcxmGu9rrhh8DIzbAA8RTLuJIoCKgIGDUJJ4JjLnBpP YjJBRrdO+iHWnSyBpFQrrhmMLgyxQYbFXIYJ0cjKxp60F8eWxIFOlqCZj5DXQl56u+SwHTJnxnrG 667BTVNq8pRabph7TVaNoBl8lsU3EsgUAkFMaR37EvEIAFGwEfVrNi09Vy+/Rz+adIAgqjCxL7HS gnCkszW9nB8BGwEvjH1Y3bwEY+zIqSBlDYx8yH9gY68Lbhi7ROfhZw1k1HmEFAnB3uyAILJUzIbE bDuSU43zZA3JaLDnhIo1g1oyAdNqJp8QBBYy9iMpjgzJRDpZU8t9PVLekfLU2ycXlpzVmJ8meUx+ tgb3s3NccnwZ+zG/Wta65AeJbvI5z3F2yYtQNszHg1/ir1nktRAu01IRiTYPs2EEElJsGBWpgf2o 7nSDC4hsC7PPd9SwKzDGpSBziieIqPQ+YJuJpFpGl0JotFRE61B1gbT8b7MqlgMGjWI5YJOLq20u EIn9ehryvYacDmH5kpV52jrz1Ju52Y1z/rKNk1vixF/EuubDFB7n/tjj8pEmSiDT4BtKRdpzcFcb XqU5Hbsz5/Wm5grM49zIokjbv3dX8jvV3iBru0KXJEOmiIR+PS35Zks+P3TG/JRL+mnfv7adGQNS boV517Cai0SJc+eh87Ho/SpMhPpb69MEgLRH4Osn3mJb75SU+1AViZE0Bb7sENLSv039Snat2DUT kNLE/9THBDEBkdivp6f/qJ6ePAZ9FgszvXVmujP35fU3hpzJfk9owly8By8KztGXmBo+QfKVKa02 gwIcztG354WxrXtCyqPH2KcgqELF57os/9usWpe9aSTQDyICpbByYyuisV9PM77TjKs3aRjc6EP/ Tar3ByBqIvxo4TB3bsPEWC5DdTOuR1mQVRpzfKk0L57mvXP7CaR3rOMzBQ8eKKBI57lVRKG6xLKp rOLhqOoOVSv/22joh2i5fgB6jxqZ5T2q9K+nGd9pxunw6SxDEs3bu2GZu5OFiwhks3E+Tp8loGTB WJyKGNW7oBUYFYHiy7w2XfhAVqWSXb3Tpi+qAwK3uXmS9XoG5YDowYW6irT85O/Edke1O2xtd4XN +9Sw7YiZ5ae1/7jWntyIy2VGTGaji8tx5OGUeglIbsqvpD9tmIsL8XXNejlhRkXUHjUHIO1p+v7w WGzrnhW59nFlvqlC9AfScr/NqjDN5XqpCv0gEnmh69VmEIn9evrxtX6cfZnT6EJKdZi24zD15k1f oLNLXt4pNszHEUSrcDCaBmeCNI4NpSIhRZNERQ6H4K40vAo5mcbUdwZKBjINnm2oAofuvU3aKvid Yq/JAEiCwjX7lksRifx6GvK9hpyMYHQh/iyccshpT6Cdpt7EhazEWnf9OcT5NIOdqR/z/6KhzC+A 2TBWQAtUQiCIKzq9b3IBwWESxREbEhwRPvKMbSYSpJv3yxCkAzKPcyOvIi3/2yigbNeq3eFqmytc cRobLkUk9uvp7D+ws31X0HcH3R4yn7f3IL3VV7nr7QBrbJyPX2Y8f/R6VF82ejsSgC5H0aVgLyhI 84iU+7nB9DOgjyb+DNy5Qh2vZ4ikGahQPQQ53aj/f3t9oQe4i855IBqucPbQfRryf2/IyRTaedq6 M6fBqjN03qztXH6Ywt9JjMsXEj0i5ZJusLiwxAUwrzRSQV9JqBCIdrQGUn4Vqocgozv136FH0p+e Tin/dWrYFJFVvz/2T0/+Tk9OJvH4ItCtx7kDcni7NnE+TuJXJbaYaTo+7qI5ygOiLxyIokhL/+6K 2Tyv6m/06ZqpbcjbaIjnnqePys8K71OjsiLC/vXj/i/txets9uwUbd1J0zJw9R7cbBVqh/Hj6H1L FGDzsJqDJYgcv6MC+eqQJnMkgOjZQiTNALodEW7UdfXX7MgZ+WhcUU241nVsBksRHr+nH9/oR38A 7ShtvWmr0WPmleconrX6Ym0m8sP8/U7f+tytavYQyfxtsBQm0ld+7x0/SJCBJaamPEW0mRoG5Crb EUE6N4q/w46UkY49AUK2zLEhU0RW/f68P/2424+T+bOjtHXHrUQHMOaoyXwR24k8H8AjY0bSaJ6Z hKAg0QV6ap49hBWWIycYH8KYV5cnxy9z0kis3RER8d57pNm3bIpoR6/X/D7vf4eWZ3e/5hRvvYOu tUQ3rJJ5yB/G9eMwfDj6R8Yxj3n8iycJSGlFHfcqBPI8ABDGQJsJg+qkC6hOkeCWtBoFgDTkbxIF dQU3L9YhgGhdd8jaBryNisXDKba4+M+auMyN0ooI/+vpx9f6cTqCdpq27sQpMuahGpsZPJvKDzP4 XW3UjARjewr5JqI3DlsQ58QlCsJ8mpNE4pyOyDjGejqm5tQrgtjna3h+Hi2vtTw9+7ZE+vxo/Ap4 N/6X/WpJktzWgSd4d/DaEU+hH/U5x5zBs3Jv3v0Xj1VgIhOiWFKP7Z4JR226ojOgBAgSQCK1aqFK 1O8yKKdu36KENeTPMLqLe0eGbh/mEvl5DYVAIz1DB1LS5xMe9AyzRnA+a5zrtB/yZAiv5pVNueK/ LSm/3PGbL2zuppkbx0dVsOe9FF9xLkWel90VppRjc/c8ErWfA5C6dYdgmDXicvRW7R2PIxHp+aLQ POkP8F8j2qHmbk7j4fSGkLtto8L+ncfXeWy++dAyP05qikjfTRvax/OjCkDjLU3VOoERnfWG1zb9 PAQbDdGQfIxlueC5Y3Mvnq+P+RuTP2w5w1u+uG2df/tvnr65W/7vD90yh71Lw6A8+Zt52NXXic3a pTnEk5F1mYPN0i3rGGwsms/a3InnZ8TMGTWkbshVK3VQEKmDYe7GVV79MOWa2hTAJ1oG2Vk/rMF9 bgRjCiGe2fQpPCnz/tpED/EZmzvhfHnIcjlDN09DuJy8SvVBCgx9l1K4nQowlsPtGNFHQPotPrLa Jpf3EB+ZhmhIbpLTdsFzx+ZOPD8j5m+y0arCOyjxamTgG5pElpeyqXY4dmmfg6Qk8hcl5b1O7TG5 lUfA7QOI+rOYdC5g3NaIJe/7k2nelkMGDHHuFza6AL5zeZ3Ly5WBKu/4is9eOr6izXGJuLEyfEZY 8v4gIxnmEVFhiTxwmaozczyORKTnS/ruTm5P0nREdL2jsOXpDSF324Zy+J3Hqzw23zw2EBbnkHeq 2N0LUsSb7i20iTwv33ztEqsS+wEQnjvL5HFUXe6BniFldXliyxCWIiD5OOOO94OYaMUIUOhE6O8Z kzNpqmrEkqdLp2YgrZH7lQ1f2TuX17lsvv340ql05KEXwNYNDaFCOITaLz8IKfO3zTExRLh+/tAg lFFcTletZd+OJ5aQQg6AlHtASGG/w2ZbI5ao70+mddoPCXgicsdNG7nPdyavM3mpcjiYjr37rL/j q7buuaFyPjML667FvnJEdBbe661gGuZd4zFAZYeGbAhp2jYqyf+Vh2++riJPQhkcWmgBlm7bB5U0 YhJZbm2PbOJQUbqeAmGZ/1DdSeE/MG0FS7esY9x4aIUIwhGB0J/FBCZGcIZY8lSPagaeCLnbNqeb 2juX7Vxe9lW25OMrPnvp5SuxOXbaG32VLr2U2aULgPKv7k9uvUZ8CN7KDCOiVQlAJ0kcufXtSZpq hDOQPYmnN4TcbRtVE+88vs7j1fYoxQl9vHbrgmXDkKXrh1UnkNhEnjvbowyYMizDegqEm4NtF2uX 5iWEdYZYWLLxFEw3Hu1R8UAakx4RCP1ZTN6RJFU1wh5VRnrIgCHkbtucbGrvXL7I5dX2WOhE6VDY FCBlYTU1aqEK6mp7lMRgnWBiiJTE/OgglFFcTudI6tZ9C9+lbu/DFlYQWedC1IY4zwsbXsK/9vhX eiI8zdglzzopvqoR0dJa+XM/ynwpwOsWoqXxUpjIXCj0KnyiRDwpap6uRthWyrCSOIGQu23DtvY3 peRXO/zlplb1L7arAkz507iX0SSy3NnUxCEUi66CQFidVsFzPkUKdVcjCOt7qNcHphU8d32C8osH 0pj0iIaoP8RkTBpTjYxrlH4hAYY49Qubs6XoncpmKi/7Klvy8Q2fvXN8xcl97LTXe9qnOkJ1fRJm jVQb7ElmOHH0OLAqATAHDtAbrhODm2k6IkiT9ig9vSHkbtucbEXvPDbyeLmnsTahO0tNEcie+7iU uUlkubWlWfyq4nUNNISnhor30pcwa8SbAdaIJ6R7xdjtCW8nnEYDkuMBoC+LBzyapSOCIalbhZ7e EHK3bfR9vfP4Oo+X25mHWWmZAgzdPA2NCjjm6PcwjIYFsslUvyF/hvFozh0Yu357rZxDmMqugRvi ufMhCnpGeYbY6b7/h7uIJMkAXkvT5Gw8/6WM/GpnvxQQ+iq1Sk97Jz5qK4ob+uEzU6buCmzfR0Sn zJ2aOx5HItLzRWl50heYpRoZj2NPD28Iqds2qprfaXyZxstNUQvz0DsL0HcprUHA0CSy3NoU6RCa SVdRQ/5yJ5BW9MC0OfXdNGESIya3kggwL4jQn8UEJkZwhljyVH1qBgxx7pc2nNfvXF7n8rLV+5A4 PuKzh46PaBNobnX6zzSE6vYkv0dE1dWdvBxPIxHp8dJy8Ha4O4moRjiT0ZH09IaQu23DPvbO41Ue LzdFliZEMHt7Qfo9T6IpzBvaRJ5buyJdYsTpLgoE58ZOMXTjMAa1foZYbeqSY5hsOfk484L3g5ho hQhY50To7xmTM2mqasSSp2JBM5DWyN220Vf2zuV1Li93RnvF1Dny0AuwdVvYGSuAA6j97oOI0nVH ZRWQkpYfHYIyhsvZgOTQ0w49Gs4rIYUMACm3gJCcyAM4RTY8Huxbev4nIhfctJHLfCfyMpGX+oZD 6di3z3o7vmpLnhsK5zNzsO5YDLNGOAfv9VV0p2kMS6EBKjk0ZENI07ZRMf6vPPzjda3Pd7Vu8+Pv Pj7vetiW/FiH35Z9KTrkiPyZkdRt+dtlX7txSgHZuqHfn8ic38/eQPbtEcOw7l2ax4Bs3bI8bHJ9 puWJZD2UC0yROacwfPUosCE1kOJ9Wbt92U4RP1dG+j0dELNJ3bjEr/Kz2Jfgq0by5Y12rqkb+/0U Gbtltvz03Twsp4h/5TmsEffud1Ejfgq/0xrB2XM7eHy4b8kv+kOQ/DvOhbxlk9M5LD/Nxi66ZdP3 4xPZ9708crt6Q8xmGMYDjyFrt32xCS6Z8eaLG8cQb15Up82L4EMQoWmZbN26WG1PXV+QbZ2KzTQT MZthXgIPEfJc24zdkKew+spVkVLwNXbjOgYeIuDJXW0fAk9uoKVHgCd3x52d5UMQ5WnZZAkwraEm c43PsEn95ojZpDEFHiKFx3sfeR76IylPtlnSqDyCgIcds/Bkm3UZA08+4boFHiLgWfMMSIEn524L 58o2ex/OJQh4lqdqiTz9kA48/TQeeICQp5+3wLPm9zMEHs4G2Cy5n60Hm3GLMROBL0wU8qR873Pg ySW4x5iJgAc9nTy5dvp4F1M3DfEuiIAnv94pnisP/THexdjNczwXEfBksbfEc41ZEMa7yK93jeci Qp6WjddO1q9pC33jsVdurEqzyf9pLQtSeGRygyeL7n5Vnod6H5PyCEKea5vMOI/q6yHnpzn4yt+n IfAQIU/LBq3XZYN38OyqT+zpRtOvqw4CR5zmy0zWMA/NJE/JEG+ewv0caID4pBWkTOxf1gaK5ptg LoIrq1/Hpk9DsDFJ17KxW82NcwmX+gT0aZCFCFj+eZvcWtf1ILfHbQl1Y4iWnwnej4CA556NtQP1 Ze2AvtBEyEMEPPdssDQUX97m3Jc3R+dxJI+MPrbdPCCG2HYN0fZtS8NHQMBzz8bGCX1hnNAXhhB5 iIAH4408GG/kwVAkDxHwcKkCD8YteTCkyUMEPBj/5MH4Jw9EA3mIgAdyhDyQI+SBrKENZA1tIIbo iwh8QWaRBzJLeUycKQ8Q8ED2Kc+2xbuAWCQPEfBAhpIHMpQ8EK/kIQIeyGLncVnsPC6mnUeQwuMy nTyQ6eSBuCcPEfDcs7H1g76wftAXlhavZUfIg3XIe4KvQ94TfIkiD5HSW27a2JpHX1jz6AvLIXmI gOeejW2v9IXtlb6w8voscIQ8bRufKX+jTd+PMim3RUenWexbOrAAIYshPrc/aVPm/xfafPskk+uo T9m4HvspNq5XT23s3l33+sW77vXXojyGQD5/nQlqi/GithgvKtLXE0eEpmXiW463DN+WvGX4tuSN hjxEyHNtg1ZIX2iF9IUGSh4i4EFrJg9aM3nQ0H27dUR5WjZ5hE1rGDl58M2wsZFjiI4u8hApPD4C yYMR6Dw+OJ1HEPBgJDuPj2TyYJCThwh4IBHIA4lAHggL8hABDySL8phkUR4TOsoDhDwmocgDCUUe SDHaQIqpjQk4+iICX5CG5IE0JA8EJXmIgAdSlTyQquSBwCUPEfBAOpMH0pk8ENzkIQIeSHnyQMqT BwsAeYiQp2XjteMritegryheg77YeC0LUnh8ZSIPVibn8UXLeQQhz7UNVkH35asgfWGBJA8R8rRs 0Hp9w/UO7huud/D8Ub+uOggccZovM1nDPDSTPCVDvHkK93OgAeKTVpAysX+qzbeXVq5pHHFt9Avb FIUpSFGqpzYib/VSoXf9IZCFCFj+eRvfBrxufKvwuvGtwovNtxNBwHPPxtqB+rJ2QF9oIuQhAp57 Ntbm3Je3OfflzdF5HPFt0tuub6Xedn0r9Wbt260g4LlnY+OEvjBO6AtDiDxEwIPxRh6MN/JgKJKH CHgwbsmDcUseDGnyEAEPxj95MP7JA9FAHiLggRwhD+QIeSBraANZQxuIIfoiAl+QWeSBzFIeE2fK AwQ8kH3Ks23xLiAWyUMEPJCh5IEMJQ/EK3mIgAey2HlcFjuPi2nnEaTwuEwnD2Q6eSDu/89+texG kuPAL+h/qPMcEinlSzrvfS/+hAF88sxl/h9YOkUygulyl6rb23ZNJwYwpgNRQUlkkkHoADGdPk5b PxDL1g/EsqXFv2VHoGPrkPcEX4e8J/gSBR0g2ls6OW3NQyxb8xDLlkPoADGdPk7bXhHLtlfEspXX Z4Ej0Hmf4zPlAznjmGlSlpVHZ2PUshxUDIFKQ3xu38nR+f8LOU/7Vbd9MoJlSLtrUyrbehVplRDz fkTa1xS/0yOSh3Wuoc+/RfxXPk/fIh6dvMQR8Vu4Q2p3Z2SU3pnCr64ho8wx9hJA9DylDmmZeQ5e QYp8F4l7CyHaJfAre1VCrHo9umfnGqK38Cy/Rew1nv/4cgV730f2/Y/19if/KxvQ7YbY01g/qon3 DIyPGk49g7BnoPYM5o8yAT2Go8O49BigLiPVY8h6jF2PQewxmn2Gtcf43jbQPUa8x9D3LAY9C0bP otKz8PQsTj0LWM8i91FLY8+C2rHo0jjXniCcMm7cE4RT8sI6hGhv6eLY8PZYwqnTHGKVoe6jETpA oHObA1OCWONSD7HGbeNZ4AjHeo/jM+XDOBsPxkaRaUmTUhh5nIMKEKg0xOf2nRyd/7+Q8/TlTvRY nGNWe6rjczn8nRpi3/JncNAPgWjv/RSOzJZIaTvaA1Nkgi2xhyXxRMvJUUQmc4lv2NbFn+G0aTKK 08xhnDSEpxJ0gJjOT3GKuADxaJEzire6ztGpLUhNlae2Ijz9WWdHQqwezu5GQqzdjVAs8zDQUYR0 bnOevo1DmraL/JXv/PXvcvnnz7+/wX3xb5sjasgL/JiopWUOiNxpWtkNAjFlP8Mz3J8qkR+8oiTv Pi/sKxUhf0o6hkCnj7P7ZYqlfpliqcsmHUOgo/6ddNS/k466ftIxBDq6T5CO7hOko1sI6RgCHd1v SEf3G9LRrYh0DIGO7luko/sW6ejeRhzd24ij2x7FMgSxdI8kHd0jg86+fQadhkBH99qgU0rMRZHu F3NhCHTKsK4xF1LRa8xFHdYl3ssQ6NRhmcO9itT8FO4lyJLDvRxxHUFm8eCsI/U8hnsJMtUadAyB Th8n1xRiSYWXcHdBcvy+HDEdcdVlkjwX7i+C5GXh/mIIOppHw4myLCDzVcS60vOulOb1EG1HSLuP s58anbnIdzgDedmRfLiZIqTTx0m5hljyHeYcYsl3mHLQUYR0wNEJeA8Hk7STM46ZJ3tZw6xvnFqW g44h0OnnuGO5i+PO51/Pccd7F8eM85ek+FpyD8W3mw/n+NZ2F8e3vw/n+FZ7F0e+XfGhn8VZpddO P8CpeT45/zLOffXTJo7MojUMnB3gucUqhkDl/83BF6hzXZBc7Eve57oi7A/wtQOBzi0O+yxEU8dC 0cz5QAmIRevhqPOiWObpEEu9IOkYgp6pLlOQOU3sMhUht0r9GQh0bnPUPVMsdc8USz036QBRHXPz pKNuHjq2A0CHENPR7QI6tl2Qju4kpAPEdHTbIR3ddkhHdyTSAWI6un0FnX37Cjr7zhZ0DIHOvg2S jm6DpKNbJXF0qwycHOcyIRZLt1zS0S2XdKRqazwzENOR6h1jLqRqx5gLYaeYCyCmI9U7xXvJ/+WY CzEwc7wXENNJw7zGe2VxcjEXUr1bvBcQ6NzmSIWXmK8krjrmSyq8hg7kiOusUr0JHaBxyrhxTxBO ycHbEKK9pYsjFT5njiWcOs0hluyJSwo6QKBzmyNfyloOscalHmKN28bTwBGO9R7Hp8qHcTYejY0i 85JmpTDyOAcVIFBpiE/uOznqAE7Og3COOe2pjc/lkP8hzL7lI+tXcNAPgWjv/RSOzJZIycM610em yARbYg9L4omWk6OITOYS33AUr5d+itOmyShOM4dx0hCeStABYjo/xSniAsSjRc4o3uo6R6e2IDVV ntqK8PRnnR0JsXo4uxsJsXY3QrHMw0BHEdK5zXn6Bp/FrOZ9GvIC5yW/S8scEDn9tLLvA2LKHu0Z Pk+VyPldUZIXnhd2kIqQEyUdQ6DTx9mdMcVSZ0yx1E+TjiHQUadOOurUSUf9PekYAh3dHEhHNwfS 0X2DdAyBjm4ypKObDOno/kM6hkBHNyvS0c2KdHRDI45uaMTRvY5iGYJYujGSjm6MQWffM4NOQ6Cj G2zQKSXmQvde0jEEOmVY15gLqeg15qIO6xLvZQh06rDM4V5Fan4K9xJkyeFejriOILO4bdaReh7D vQSZag06hkCnj5NrCrGkwku4uyA5fl+OmI70lzJJngv3F0HysnB/MQS9y6PhRFlWjfkqYl3peVdK 83qItiOk3cfZT40eXOQ7nIG87Eg+3EwR0unjpFxDLPkOcw6x5DtMOegoQjrg6Ky7h4OZ2ckZx8wz vKxhqjdOLctBxxDo9HPcm9zFcY/zr+e4t72LYxb5S1J8AbmH4nvMh3N8P7uL43veh3N8g72LI9+u OM7P4qzSa6cf4NQ8/+acJ3ikKlvVZN5mdyn6O5qLVbaqOM30V5FTS2a3A8T8BnQO0WXi/hHAlFe2 bYo0G6CGQsXIvNAxDdmGUvVMJjSm4O2uInomCibesNbgORrSjhTfgDwOvYH9jt/SlMrxcUs9vO22 Trr32CnFiW7TIdYr8nKNY37TOU9wkzg1sSyXQNoJ3JHTuyFtbxF/SXPpVG9A2u/kTJfX/57+89/e Ytj5//z591kWj1kW45Cm7SJ/BX/9u7Rkfr3m9Pagd1TpWZuPWJtnyzrL4gdaljvXTXbdDT7sVS0N 836G5shfkXFYSvFfMadtES+kA0Tee6xBJ0b/bsvCscapPekqP9ocaU8aD9+uM9U5XMcQt55y+LWk Cxlxv841RI/6La2SnNQMamofDoTsOyOOPrAgdZrD441DGbfDAxui64w/uSOk3M74HFi5rOH+DWmv ZIlA0qdhzjGh+J2dCYidyV4bCJRxJsnPXEJOkDnLiSHICU5kGThqH+9h0dJyjNYQWiOo+3XVFbrf WWG/eYWdjfQs89+gzM9GelbY5zRSexdfLzbx11Nz0+aK7Tbmb9EA3d0f7vJCOkDmYSw56MTo322k oJrJt5pik2/FCJMPFq7T0oXDG+L7E25c4pzg1QQkXZZoWfBl6fBUzEJ8/K7UkHXeMdr7XkOwjNox sVxCqS2X1zhWUbSA0nPbQ9qXh4fE7yyfQOyUVolAoIynHAf59yGaIY0Vu19XMVD3O8viAcvibFln bX7V2jxb1lkW/S2rTOLJm/t89YxyhpKGXF8fCmtmGdaVPRseHE5zG7YaGpTroGXVYZnZjx+jf69l uZzbZPlxXpZLtMl2DNjkIo+yhKBpWEYOyoiaYopmNhnKbJPbM/gygWDJnmWc8oWNtCGwxKbiC5Of xxYmPN37nKfAsmiycKw5pAWvZrcHYrdHWuz2SF0z+887K81rKB0g7Xehz/RlkPrMmctflcuzOZwF dTaHM5fXc+nnbh7kL/roES3LQwTD59ruXN5yXAe/Goc5rZe4DHH07641oJrtsjzBdr3X66wQ3EP6 w+NwhriHhPyYYqu7hriH9GBuaz03ZGvpvdQfCjIVWG/OKb+7KZVjIhSALow2MqFLAMVqS8AVjlcd b41WQXC1YJmrBdJOwPYc3tuS+RaBG7evDLUJpP0uLjs9JUJ95iyLxyyLs2WdtflVa/N2y+psU2cB PGQBkIuFrzQXK4ZyC6vSJneago/bxmEp5cIrVxrm/WxYy0wHiLzxWINOjL63KT6AGlCh5XW7sAF9 pyEdDt+uM9U5XMcQM5ivh19LurBRtutcQ/So39IqCYEH/ysI2eAnjj6wIHWaw+ONQxm3wwMbYrbY ntwRUsaaAJYuMX5bW2I4De9xnvY3H+cSXhJZsJc0BC85DXOOdh7R3iLttm1apuUYrSGmHU1UT41w mZ918ah18cXa03su6mxav2Nx3mpanY3qrIDHrAAaMHYDN8LeluDfLMu+3HmD4cWNz8/tDcg8jCUH nRhdfRRAM56WZxjP91qSlQ3sKH6L67Tnx+ENcaePG5fYh9lEg6S2nmyt2/rDUzEL8fG7UkOm2Q23 972GYEGyY2L5gVJbfq5xrIpoQaIk2EPaN4KHxO8sn0DslFZ9QKCMpxwH+fchmiGNFW1UT4lwlZ9l 8aBl8cWa03su6mxZv2Ft3mpZnW3qLICHLABMlzKJIy7usCRuyWJIX5ODJa0M6/qqCRdqjwwXug1b DU3JdYCMwyxnIp1D9OahShpyTRcynULLy3Jh0/leQ7JjYHct8hBLCJqGZeSgjKjxpDOYFYUyLDR2 VTX1CGam/vAwTEL/xs/MHFuFYqlArLeIrxkUTVcfv5utPmmrwzLn73KeAsvOLUvEmkNCkRd7SSD2 kkixvaQp222fd1aa11CGQNrvgonqqhE2UWddPGpdfLH29I6LOpvWb1mct5pWZ6M6K+AxK8AHzDSm ocgZ1llc1iJh/8d71e3G0dvQJ5h3mEvnwpPRaKQZXTZNUgQtPhTw4utF04vAdVqn0bq1Xfv1e0j9 USPZCVqgCLDxcqlzKIkiDxe3QCWjKtl50uy+kGxbIegMNjtrtkSfHEiGcWraNpJ4WkFP26XygcSc F4GTfTLXIZwXChcFTjHMs8lrQ+QL/pJoC19eRpMGo9WBMFgksJq5eP4U2YJ7MpTDBkh88tKijYsW va2V5RW2/D4zWz7M/5EtZ8fPseVzwy92dQcLJ2fJgGjocWk1T9u+CS5KgXm2kktYwrofc0lDiO+/ 57ITPZZ8ZCVrexZz3FhOkAxdslFYwlX/n8l+nPvt82OTW0WBkIaw6mp4dxreflxQUk5fBwyru3bj jH/40416wTy40mhHRdZBupz8MI+n6+Hi9+e758u/3z2/OX3DK7eb2sZLNIIZZ3J6P1w83n85P3y9 uaef3340AR7Nx5p1dLgvbJTcPtrxHbl8OAHEGSoVzmh87jrUuHVeJ5wW9r9QYUUs3MAMCuLu6EhX tUKTbbAgn7gyrRQ0KhMeFH5xbEHTQNk3lCqGDW7aVQWjLf0k1qygxIalBYfmdoFiVtwKGRxyUrEF ePRuQrxk2JElVhgsbgApMevJcUqsFhskB8vgZDCTpXtEpiAT2ILfZpyC0owufbYpoOIXHItdkDlq iTwzFf5Fw3PlULbJ4GztsjKaiFZYcIUKHUjTvTP3ivY8o55og42Ek0Iybaqy0FMGF/43+y7OV+CA QxsrVynq266yKO6p2Nm0Wt4FPTLeBfa5WrZwPpSIZ0o6uQft8P4sncVCB0sGM20ruVA34ocJHe9w 2FZZvh1pSUesccs7bRMZR5sji50sHc4MvPBQcfFUa3GZKqQerpnyt1y3TN/QEZHcFk95noxaY4qD s+QIJblBvdASF7lQp2v7DmZ6sYYtc+SucJn96CVflJ1CQircx7zIB9U+sWzJj6OhJ7aDm+++VqgO vf7g/SafOd5FGwDRHdy8gCrgVMhWeUxtcUgGCDTOoJaf2Wo3L7CbMpPOFu+Bl6TvnToUPdrwUjTM XdbFazwip3qWN94UuANGAK69fAcn18XWUiolElfv8r6yT7Yc4yH2wzrfZTtW4RUPFA9VXFdDz9i1 G2Fv/I5FPcfrpcoxY92uX6jw6+S06loQmNq6ERH/YaHPdC2UePi5obSW3GJQlrZdGo4hMn21zHeR U69qLRkakPiqUMu3XjDMJH18Dzb1JhTH3ah+V8QopPRhUXRJwdWxEPVhlRdUEplb5bzxJXU7cDSk Ot9Gw2TVMi+Qj0Doa2pff9Dbi+UQDnPVXv416CISWtlwJKuwg5sXUAsnkthIkhtH+ZEg9pTJDXfF tKcncMSN5yxkTCtsioX+77HHVJBuvguOrkp9NimFjmjKliw4Gn5mq918BzvLr1aQmUnvqsvG76l2 812oWDiEpdV2yZLpmgBkoShb6YAjf0hRFXnXCsdsQe+M5fUYEtPVbr6Aoz85u1UaFBpSm8piJ8w0 0UIPXKjJJgDuAvVC3wPvCNxkkXR1ANw8azf/c1oZ8Rlbqd6GjsFrNwLX/Io7srscXRbi+RYaOgZn 9SAuoYOkuSmKc2olfbbkc6qBoypMwj94bRDwPDxSM7y/wdx69CDduLPSrmYFN1fn2E4PB5jIXrv5 HlRn7IiSHGpsWbpsrK4rLxLXAFg640t+Sc04EzW7sByYmScNPeHhIgRIb5zghqDDCR48PI8mM8mE zN0ZlNASXVVXDjDMfnTzPaQ4KomRK45THUuqxy0/s9UL/WvgGF2MCVC9CU9RCgnLMSSmq928AG8W 5v7YGx8TjvSpA6jogpukK1BxfhWTaDubxgAwhlHx7AUQ6aSb74LHWxBjbjv4plVJwbUBMF3t5rtQ jl92FmjZECVlTq5iOJIzlVzlW1jKf2cqRZktWc6mN5Itx2D48dXLxNMS0Pysm+9JRjfMwH13Gt5+ tKMaT18HiyKAhTP+0Z9mpHl32ajeIFn1hlHx5AdK223EJ+oCfZrx4fo8XM7TjGJ3uh4urp5vHx6u 7/z45vRtuKTG4xyVidmipJ/eDxefzue7py+Pt3fnh/HT+fH+y/nmkXxRZY1xzI8/7Uh1AAMbX9uu AjvzLMzz+cL/+/vj7T+/34xP6wiM57v7fzx8fkNQH06I0xmKk7YMeYBkpDjDmRgMYWtQtMjABYLK rKg5LtR4kIPCaOiUMI+hVmyoDNKyYzsYfLXD0y8dR6DEQbMsSTOlsMSZMoOkuW9FjHE0C+IlxVuG I7NCfup9zCOKIbQ4s7C8NVAiapEi3QDfKifEq8EUZyohb6Ag580JyYm2jVYgZamBr+HSlbScAd4a 1G2KWFiCIjKbmqyROspsqO9WSh2zWSS+EooFTYhvoxxxgYl9X8CEfi1QYpMVKLHJGuvQSUszFPHG d1UsqRaUfadiYCxajyiNSF/uXNKy8P+lnhkozSVWL37m4nLjCxWXW6Urv9gZQsrQy9vxQYcv0zqs 87l/C2xMX4ryZsGEwMhN4mfLjBQLFWOflDOVRfLEylQv8y1VflHIXfPCG0OpMdBYBu9mU5UhuzTx sbCq1vkeWX6+raUhiwZCrp1InaKM2Bo5loFyPrkwvMjF0FX5IGhoRrdWQEEKl0NMFeb4PV/fsSYx UUIJXr4Ds00zGEXATeVKhnRYB9Co5aWTL98zbK5/raVURLQuvQuqAzXPUpWP7wLHwlpOsym1K4QH Pc/WUFAOwTB5tcz3qPDgaaSQRbwt62G2NaBw4RqO8fCQWnv5F7CDT67+uWW0ltJEUIqoxJU600TE AaSFuax0wN1UlZm2P0WP8r1GjVTSyQuYDJzaHByDtGr7noak1701Jbo6FmI+rPKlzQmq2ApFS216 bDSk4t5Gw2SVl38NufTql7u35i7UYWeu2su/Bl1kQCsMjmQVdnDzXajAJgRFKzEijCWZtnT5JVt0 8z3seNqxIffES7KsLAB67DEdpJvvQKO7UWsVQI0uypasKhp6JqvdRO4V8CyxWtG1cT/s0fGTqt18 Fyo+e2Fp9VuyZLomAFksyl464DOPaULDteIwWxa05D1W1BmjobQcg+QA6oVe0M3TtqtKeeJ43drX orDQ8CZUZBMSt4LazffAs6xthS4avjJdOu6mtRv1UzfZtdbMSSHnY8mWNoBEx+C1G4HrSStVQUWx nU8uNf1iafV4cnk5IKaP6/I1tdAL5Pqu5UZarZ8tZWSogKMAqr28sGTsNDW8Mkbg+FYnby25ZEMT DovTep3vcaUJJR9aO7PAMuvqOJqAmK12893xZ5s0OqLdSaH3x6E4ORRLQ8+qv3bzHejkkZ9/nLSO 38vkhRpJTV9YjsEwdViWy1oDq3gIk5bjSFd8clGrUCNR7eQFUJkE02yYCnZvWoQEcLq7qg1aBHBc 6PPIKNjiVIkWQGfXm02P7IwsnfxrMGKkhTYkrSssNRUD106+C7ROO1Wl3OTLqtaSVlXgSXb0oBLd wr9IqNYiVMbRzXeh4llmoZUPrrVk+dgGwHS1m++ArzMaWKXu0/1nUZkNSdK29ExWeZU8KuIZme1M JZ6zBbLNrj0ufiO1l+8i8dMSXOF7nggaJgC/Ow1vPy6jGk9fh3lETXHjJX/Oo1qwRXokVJE2hWp7 8gNEGToNPpeFP834cH3GytP1cPHp/Hhzf755HD/98cm+OX0Dsg3IFtmOmGb8oz/NuCoklAnqzs2W oS+hMmfFSFfPtw8P13d+JJRLdDe82/ES9dGimp/eE9X57unL4+3d+WEE7f0X0JKvwVRpHBPhTzuG WqdD4uhVEC1M9Pni7nwznoH0dDM+2fHXP/zml89vCOnDCXvFY6Zd7vggJXb1218Gerjj8/hnqh+j hlgY/zKPf2XVveBkLETM7mx86ysWJcv3bDE7NL7iK0FXNzjsYrkaAjJeug7ICsiU1hZvcKGbx9Fj PF2S4XsxYJpTrNOvhn8Narwd6UpXNAtncKv44/4mWvzwpxHXBsVt6Dv+hxOuwrEffYVrcDneNx0C joPOgON7+7srNf7tYVj2yY7bjp9w2lAWgFr+I2BKBpsUDLYKZIKxgRmQNDOGmGMMNAWkEcgF6QS2 RXJ5QdnXHM7PgUqbALlm5ghpKB/kVXASNoEkNEugw0CRD6LBGoGWgprtphYWFvCohyYyt8x0PWAM Kvjkp2cmJ+aAU60CMB2V5xdlK6SkFmem5ykklijA0yJSmtODppBAXoAAAwBw3wyWDWVuZHN0cmVh bQ1lbmRvYmoNMTAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI1IDAgUiANL1Jlc291 cmNlcyAxMSAwIFIgDS9Db250ZW50cyAxMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0g DS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExIDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDQxIDAgUiAvRjIgNDUg MCBSIC9GNCAxMyAwIFIgL0Y1IDE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDU4IDAgUiA+ PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAzMiAwIFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwg L0xlbmd0aCA1NDE4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrFfbctvIEf0C /sM8UikLxmAwt0f5tlFStjcxU/tg5wEEQQlrEOASoLT6+5zumQEhy1XJQ0pVFA9npvt09+ke4I+V FK1Y5cKVhdBei2v6cmriL4fVb6Jf5VkuNWH8x6Yy8573EcRW2vJms3r9QQopNvuVz7TI8Uf/nctK I70obJZj9+awev12NKIeRZ5JZemzKPhTi7HuV69/+SLF3bi6hk8+UIPJ5nH1de1fF3l+JU1m1+rq 35u/rUqfFY4Oi827uL+g/evCX21+X73frP7xPzpTlAKnMuusUCrT4HtY4NJaQUh7RqogZFyRUE17 TWkT7hZYOx/wD8johBd+jRXPWdSre9rtFXuWKALzcop9F94Ga06yNVWE857PKx2tlYxs5OlMwI5X vQysy2KBtCrD3ohNUQo+yV6NY2SLGfFeXZQJdwtMnJf5+BErnfKln2Pr/LP9ixx0IStW0g8uL0JS vJqxKzOZ83YjywVSnpMwY2lD2HSyIFFHq/ydoyqpFmkpOJDu8j3GHoAp2FoZysc8liTrJWtfloF1 meuEgaR2bCn4i0ihnuwm4pwXS+LltLxwJsDR5RRdXCyzIp1yCxRtztjmnKdcmgWbC9V6tV+VmncV BrKQIF8ijW7GGAZILrrcQIQR+MwbOhsgGOU51mDRBNFpUZosdy4CbDToCJPWMDGSdktCOqS5KA1t tUidIqOFoi6g3TnXCjohO0oT0HlwokxCNRHnVo6rCAN6VxLtNwOMCGnDVsKFy5x1tKpLDtJhUCIf HhqOiMmXTs2r4IMgcDKHLIitZjtFGchrZBVbi1IF8jSYaEZi1JAhOhoT+yztVAhNxTREsuBBFTGM a1RVIyOW561DR2mZKaUSqlcakaGsEWOC6pJPkuIiIrs81BKWkK8SOFnKMmUt2p1zqumLm1cjQ5kZ zIznfKkNdMmzi35Bxg4zxmnjeX9QZWkUeSqVSSiwKhIsXaaQKjjyGMcJzdULmIKlVY8jnhLpoDGY lV4lVHMSKTFxNRBCYhS0+pwulcCQLmS61A4Jg0duaT5dsIeqDCRfBAFieJiYjoDqlSnQR35eRWIL GeWYAO62grcGHN3CTR5a8AdMNJx9hh0kYegad8mR9pnUFxbaQRgzC2256XCwxPmEEo2IZ7faZEWh X2DYItEDo1PkRRyajRIigWoUKyBHoksYfa59OGtDvRU6GpaNiveXYV5BGqpMvEKjextikDwYaVAA FYr98CgmGGYATY2OsGE5e3rCwTNLvM2toUSRbiKqKalOJoiKSBNCQycDkcTJqlKhXqVlpwaYCh0u Xz5JQ3hhFbPFX8xqSI1nOPIYAWrvaXgEeKn5Myl2JE4P1QZpG9ImDaQyQoAyKIg6IyGHsJlvwKQX Lpwx3GUvcEh4N+//EYMh9N4lJsC29Auc9tscC8VLPPvDfqtfYFwsSssFDvPL+DCeUT1IyZJabUI1 2S60Xaxq5XhmojLRLyGnw14bBn2ufOCFiUgjGHcN3NBTZ8znMtc0GSzUrXkGec6+pccpn3DH2PNk hCkA74Ne0BEWEjAyoZpMyULNq9Q2dNCK5z5ooFrqSPpBaxpHEeImkAgVl2ERnusgEDgxskgITqDN Us+rPHbIIwZwBJghOdNhSMMU3YBjNvcxbti0Xs5JAD1KdFiCYgqT1AlesmT1FSxlrHrDebeG7kFg HiyoEa5Q2LGIPw5hoPwyknEWTyt6XgxZpntaK0bk1EMWTAjpQJdH3DEO9wS9Mcy5o+H+LJFUT4cG 51gsXVTW8zNjxBYz03ErenVBeOrhjo6YxIunH5wMnVLSI7/kZ+yIanLiQx/wKp5h4pxA9wNZE3qs oB51NDdNUlBHmJ6ASBiKLfs8THw8yrlQwQBwNMd9PGMX7mMgSe83EdGLUthKsKBLwtOi0VwJrWf2 EQX2+YyJPXekYu4m55rZEGeIpQgyYO6KCgUZoI1hx0qVkrtMPBXij//TiyptoXdAlRt8Ekt6E1Se ypZOSkNPZuJaeXQbzu3D623x8vUWFUI/4bZxEkFKiBdvuDCAPzL78i327eePH//16fbtzRUUYdeb 28+fxKf3m98+//PvX/itFkdKAyVe4y4xmDp4t13ffHqXNomPN59ufnn/8f2nDb3kvv4gA6mfv+BS BI50fU1vi7i2yFo7in1Tje22a8R+OImmOnVPotoNx6k5jWIaRHs4ds012c+XPL6uD00/idtfH0wm 3sBCLfpmehxO38XYnB7auhlFdbqSFoE1HMzmLzg0ThVcZeLD+TTdN6fDkLa8Erdfbq7oflpvwr+b XwXYVWI8t3woGYHj+r7q2/HAjImB2DXHbnhiRm0vqp7osj/80pyOp3ZsRNM/tNHb0PPWahTtJBKD P85pGdT7YXZ3Pt6dqh1+g2VwJoflHGvV72BjFOfxOvpcV9u2a6cnIv/QnJ7E3TDsspnQu9lJPYlD C9NTO/SU6P2568TuXHXXSFL9nVxcXxJH3kay2bXfG5SIDlRtl4nPfTOHUI0whT3D/nJwQrb6tq46 5jocm+ARuK+mczqJLNf3SMjlXNce2qnZYeF4HE5I1gPcUR3EYzvdi/0cx2PVdYtz5OVQ9dVdwzme hqEbxbf1fRLDDrzraTiN366yy6k3Z3joB9LEi2go6R1lZNiL7/3w2M1pWTe7u4bjmk7nkWvPciCV xSKEmg3HuTwx/pE0U50mIkn8xmE/LZiRQK/nojGtXfPQdMMxiIxZJaL7WcUoWrNrdjM/RCR+j8yI x6IY4xEKGMWWAu/GYfaFnc3uXAdZUGinqh3b/k5Uj3M/9c04huTNgwjNWdBNp6g5w6gpaNSsP5+n bhi+i+cTYtnKi8H0dX07ob4Q4rYB52kOcZyIAkQ3bKm9G3E/PFJElwr+pH3HoTtzGBAdcnSAMPsa 9RLb9u6SovNhi+yitnXXcjFa1ktTPbTd07crtBa7hi9EQJOVXu9wbeAa0TzD4rzJxA2Ni775c4IA muOrZTO1Y4dcjj8ZY4to03RA+iF8FGIcDuiM6bxFF2zRj+NCsbcIqzpB+033ShyWCvhvU3BdDz3S CXLo423D0SHBwWWcMHg0qbZj0iyS8+WxHcd6OIjbvh8egoSp+ZFPHHma5XNMQaBGKNe2EWHkYvwN 57t73pwqfAnmZ8GHvrmMi1vsqRDdnIP1Bjv2La3dDfhoxzTGnuCNnXIkNJG77sIQXUcjKoSajIq/ Do9osNOVx82/foXFlpVQLSbSgEzN8SG1I/cHBwN94nOqvjc0fJ5mik+40JCnlEgohCltT8g6qeVA Y2+kO67dt4g7Vm8mm4pX32MY1pd5+UpUR5yJbRpHA92YxOZyUxGf/zBebbltK0l0BbOHBuaHAkRa FB+igosBFEl2kmt7AtO5AeLkgxJbEiM+BLJp2V5CljA/2dPcDc2pbr70cDI/lik1q6urzzl1qkTv kacNcMo5EsYXciFUNFjSMVqdyVR6VRYFWwYpk+wFffatgmJdpy6LuiQBiUW6ltt1EFnwZSfvJFPS 2OktlcSjJH1QFXfg2CCwLjKdnron7eg8uQbcR9jtZ8ssBmyzvCNeEeqLwrSSDVFXkXOSdyA6KdO6 jgBtrvpeXRFJpTBLgojgfl+DQnXWBguJVMg2t+YHKbIykS3nu6JlV7WveD7ssErk2koXVVdu7MWR 6rrS/MFGw8A5ngmfacLGemOPrN9A6q9LZ5nDMk4Ll019dmrO/Okt1n5AoO/4xmF7Zg7YDXv4NmDh Pyw5+SEuXLTNEB0eWffIiFpwzGNzpLYcw/T6Z/wsxbYQsTa1jjMyaBR1yNWa1WOMV6WpdWpTa5mN q5Uvuo7N4PMNjwY4HI1ahul68oCTNMwBBuYvN0kUqjZjq0AjKsoYgUimc77k0SM4RpcYRqhoEkAb 6AW9Wtj1uTzG1eWyV/J0HaGxEmfZKocG0jXO79+xLz8JXzW5oTPmGKWvug2tpq2SANqa0zsFQUc0 2Hr/9gZ1LKAQwChevvtZLDewV1mKVhKGkdK9+JkkyYEktd2uPQv4OX8CvwSe2M3bCcVZUMcideJp 4zrOHOBTinfyglwK6TvE4Yq6Se1dta/aO/8K/Q8Rh4OBBYVE10WdF5ynrAZrULRuV6vrJAG/y7Pv 0mNKL5ZLryybSJPTUTeRKxwmFbOvmn9e7qgtLZ4bb4sM4pVOa6ivYFIQ8ixUb543TaopcRig58jq o/gg+D3V0qW73SoCbhXxAYOGh74ohVijSfTZFSYEUnP5EgpA7Ke80C3hg5UlfwzyqFWXrCwaa4Wq hoEIWjWlslQPeguadXNhssRkn1Ne96dVVqYhp4KEtE310qO8yCyX7R1Boa85xIFsOd7BdBJR3mTD Ffcr8lkWRMVp2Vc9V/Q7zzrLaVknjagqslKxqpxBsWWXlA0anZInp7F5NjYaOEc2T7sJSO7Z1XMR HRDWMUZD0z5HWMUics3rnEsrpleLu6SNjhW9eMZrMH4N6mX2DT4u4ZZz6S3QwHHvsu73ygOQVc7i bP0MNzj/eHndby75OiiLIE05yEHVr19m8xIpY5+vmp/tNlHQ3NcEfmuXxRGu8RIdcskbWpn9rlzU 6zfK3yu9kGnfzqcUHj0e93pXiUa9/Fr1vCwnSIK2PAp5DFO7bhBME0W92o8q05ZCUc4wWvyGppU1 CyC6VK19lINOTU01ZYnwHSBd+Qs1dlAtVYKfrye3/UNomqNDaFbPv4SmOW6hqT3N/Ouvvb68kFUJ o8Rb3n3VCK0070msnQOndgMhD3hMXeRHGMODdGHpGcMhOp2CJfx4SFatbRASjdWagxbS6RvVPSry nMCuAeQv4MeOYJctWtkR8CdniVLDzGDy2utL+u3ttyKq/R93f+gjtXPXzd7GJRdZJjZV+qtSP4SA 4xrOuGMN5OMvATAatPf/ixvHFgNMa3AknuPg79g2WbFM631H8DE2EEjbkpqQpA3J4KyUKRnWpsRp MrAHnmG7Y4uNXEBoaCm7dWKsaJMHbbKoDTJ/jKo6VjJpnvE7bWx7hPRMTynv5O5jTzddCQ2Ygzoi ag81qOfcj7XvFBmscIOO6fvZHRXCMuzBuLJD0kHBrEGNH7RpHBSFvMj31N4q/z2TtpfdZaWo3a1e heigvCPrD9rs5guytBwPScy4fkNOH/2xADa/oKu1TXZ262Oh48ElatU+twGGXV9NrZ2F2YwWDm0Z kWY3ssEEvhlf8bRolso8HEpDZQRY7Mlkze8vEWBkjw1TU6fDk2FpwAqmoZag9z3TNA27bmY9GF5b Wx6GV8ccVJFxIUPX8w7ijmXc8/eAV/xJDzDztHv1MekhrKkhkO2N8SynUd3HqMcmpUBZRLSs9aAE 82MFnNNLeDjEBJ3nTA5nbo9yonOY4yHWHp+juo021iM6S96e57Y5DqBpe3Cpt4qB7BCi1RHQ+opY 9eWO3fLfyfvBIKD5nUmR+e943KndJ39y9b6nI29jqCnv6k9itouD56s6vZJ0BS7y/e7RlW++Rn17 aHiMau5azLIdw7MY5WB4o18T3zEx29jMHlnoTlCJV2mv4FLR6w5IlSnCeabk2Q7pP6ALGZmD0Qmd HsxvdGKCGHjAEp6gz6dhmcAiMkHllEMCRkbpx97IuIhlj93DS97v94rURpiFRhLFFynfFxcfypSs /UVIfwfuYJxGkbELV332oYSZlLZfIedc0IchZWfjK3iKGNrG3sHpp2/Yf2cRZ0dY0uePlUr93WfT LEGP6LPJLo/izjbyoh+s5tBvDTYN8h2XoSSE+uxPg91kWY0SbDbNwIylrANUQfpSpSgFo5zwhc2m cVaGBXaWcnC+Strd5ZRZA8eFSeOLvAzyZ9U6ZXs/WwD7G+vplouBV7vsmcOxZvSIz1JLBpResoMN YmBSEBtI9ff8/g2NqbEda8jHr72/+6/ePB34+C7YLA9Wgv0R0ocecbHS07WEkx4VmFh2kHBDPIl/ 9RmMutofI+rv4OCoakBkFFkxAla50yD4hrUgRFHKJz0CS42MXOoR2hq5rfjz4NZ1tjUhBNvzBYDP m4gjzVgWsVFkzai2zIzvuws4a3x3sf2+vCiyldgHNQmNjUjifyLU61vXDBy1h7oN1lFWnOyO86Ty l9fOgiheG+XfgPNbf3YuDNx9uihCA1f0SpxxG+d+UwOFz2D16v/P5ifatWF3LeqUnOwkNdMjMfOG JGye1dHMITy3PW40c0gT5KlkmpZUTHxUgjmETxq5rvO6YGpfYG4T9PYVrEgJuyH9t/mqBA+tNiJc AnxsyssT1enSZ5vFMftLVQTAIL1wG6PIokIwTiNLtQJCWxYFFy/Iha1+5vQjS4PlRm+vYxPEIlqj 5J97lot38CuGgwTWuzhOpDAYieJntFpbi8j+b5CDQIej+HiEFwn1l1Knj0677Oy2q6nI0xeGse4/ 6xgzC6QFkx4LShCU8k+7s1qx3JQLGPzoRI0nOyjTVq7iaYMwWQxZilSFrkQKcbDN/kcuim2W7PDN Alr1gqNuOKYX7JCW4kXQ5lBbg31KmoEm5Einyo39mfEnRKcDPGZqMaOeLbd9KXGqOCgRrM/2tQ/A +wytHhlQ1VoLOSB+QgOxD2RhQHg9aZ9NgywSTCRBGuETapyKfbTc8lgYbI6scoZxrsDHTbsIjeI1 qwYvSn1ICT2VisCBzJQwVrl02wr2gKi+0Ox0GeUIjvq/II81DwEYJFEPXN2bw2QmJNzQ9Df59x+b HEBLm6peB4ssF7wQmPcioeqXlikLwQMAMkB7ZVCTXF1wHEtioBxghFx/0kNkCH31YxOtW8SteaIy JOjO81WwyYFWpP7CKZs+bVdUEJAphGXTLcCekxMDAx08E7kWQU41NNgEOdY3jraHY4F9CjQdNii3 g7AfMbgiYGe/NV/93OTUG1rgyPttNwyjmkBbkIH5SxQV3YRwh30SNiuDWPdFsNzqsLEvHR6kZY7A dHJi6qRc5T9BdEXcjrtPV3lQiP8xXS05CINA9ATcga1JXRmN7t2aaNh2g5V+4ihNCeldPK0Phk+X lJLOTHm/xb8RRhOz7JWfZ/yqNIv0/VUTuUZms3zTEBATc012DtaGF0L0Mku72wytG9cJgWWQULZX hTQTQK0RzflILQFeCjlpeiKLORzlsp28R3HU5Db6cg1A4L5/YLZGAuGFMXF/vInTB16YbYvP6cav JTvgOaaJGnXPnfaZXCAqRT/OF/kRBwQnmO+0Jt49nuDQ6yYvSSjxEH8BBgA6JkELDWVuZHN0cmVh bQ1lbmRvYmoNMTMgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJz dENoYXIgMzIgDS9MYXN0Q2hhciAxNTkgDS9XaWR0aHMgWyAyNzggMzg5IDQ0NCA1NTYgNTU2IDk0 NCA2NjcgMjc4IDI3OCAyNzggNTU2IDYwMCAyNzggMzMzIDI3OCAyNzggNTU2IA01NTYgNTU2IDU1 NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDYwMCA2MDAgNjAwIDUwMCA4MDAgDTY2 NyA1NTYgNjExIDY2NyA1MDAgNDQ0IDcyMiA2NjcgMjIyIDMzMyA2MTEgNDQ0IDg4OSA2NjcgNzIy IDUwMCANNzIyIDU1NiA1MDAgNTAwIDY2NyA2MTEgOTQ0IDYxMSA2MTEgNTAwIDI3OCAyNzggMjc4 IDYwMCA1MDAgMjIyIA01MDAgNTU2IDQ0NCA1NTYgNTAwIDMzMyA1NTYgNTU2IDIyMiAyMjIgNTAw IDIyMiA4MzMgNTU2IDU1NiA1NTYgDTU1NiAzMzMgMzg5IDMzMyA1NTYgNDQ0IDc3OCA0NDQgNDQ0 IDQ0NCAyNzggMjIyIDI3OCA2MDAgMjc4IDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiBdIA0vRW5jb2RpbmcgL01hY1JvbWFu RW5jb2RpbmcgDS9CYXNlRm9udCAvSEJLSERFK0ZydXRpZ2VyLUxpZ2h0SXRhbGljIA0vRm9udERl c2NyaXB0b3IgMTcgMCBSIA0+PiANZW5kb2JqDTE0IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1 YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTM4IA0vV2lkdGhzIFsgMjc4 IDM4OSA1MDAgNTU2IDU1NiAxMDAwIDcyMiAyNzggMzMzIDMzMyA1NTYgNjAwIDI3OCAzODkgMjc4 IDI3OCANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNjAw IDYwMCA2MDAgNTAwIA04MDAgNzIyIDYxMSA2MTEgNzIyIDU1NiA1MDAgNzIyIDcyMiAyNzggMzg5 IDY2NyA1MDAgOTQ0IDcyMiA3NzggDTU1NiA3NzggNjExIDU1NiA1NTYgNzIyIDY2NyAxMDAwIDY2 NyA2NjcgNTU2IDM4OSAyNzggMzg5IDYwMCA1MDAgDTI3OCA1NTYgNjExIDQ0NCA2MTEgNTU2IDM4 OSA2MTEgNjExIDI3OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMSANNjExIDYxMSAzODkgNDQ0IDM4 OSA2MTEgNTU2IDg4OSA1NTYgNTU2IDUwMCAzMzMgMjIyIDMzMyA2MDAgMjc4IA0wIDAgMCAwIDAg MCAwIDAgMCAwIDU1NiBdIA0vRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgDS9CYXNlRm9udCAv SEJLSE1MK0ZydXRpZ2VyLUJvbGRJdGFsaWMgDS9Gb250RGVzY3JpcHRvciAxOSAwIFIgDT4+IA1l bmRvYmoNMTUgMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSB0cnVlIA0vU00gMC4wMiAN L1RSMiAvRGVmYXVsdCANPj4gDWVuZG9iag0xNiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0 eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDExOSANL1dpZHRocyBbIDI3OCAz ODkgNTU2IDU1NiA1NTYgMTAwMCA3MjIgMjc4IDMzMyAzMzMgNTU2IDYwMCAyNzggMzMzIDI3OCAy NzggDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDYwMCA2 MDAgNjAwIDUwMCANODAwIDcyMiA2MTEgNjExIDcyMiA1NTYgNTAwIDcyMiA3MjIgMjc4IDM4OSA2 NjcgNTAwIDk0NCA3MjIgNzc4IA01NTYgNzc4IDYxMSA1MDAgNTU2IDcyMiA2NjcgMTAwMCA2Njcg NjY3IDU1NiAzMzMgMjc4IDMzMyA2MDAgNTAwIA0yNzggNTU2IDYxMSA0NDQgNjExIDU1NiAzODkg NjExIDYxMSAyNzggMjc4IDU1NiAyNzggODg5IDYxMSA2MTEgDTYxMSA2MTEgMzg5IDM4OSAzODkg NjExIDUwMCA4MzMgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSEJM RUVNK0ZydXRpZ2VyLVJvbWFuIA0vRm9udERlc2NyaXB0b3IgMjEgMCBSIA0+PiANZW5kb2JqDTE3 IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgNzUwIA0vQ2FwSGVpZ2h0 IDY5OCANL0Rlc2NlbnQgLTIxMCANL0ZsYWdzIDk2IA0vRm9udEJCb3ggWyAtMTQzIC0yNTAgMTAz MSA5MTcgXSANL0ZvbnROYW1lIC9IQktIREUrRnJ1dGlnZXItTGlnaHRJdGFsaWMgDS9JdGFsaWNB bmdsZSAtMTIgDS9TdGVtViA2OSANL1hIZWlnaHQgNTEwIA0vU3RlbUggNTQgDS9DaGFyU2V0ICgv RC91L2EvbC9oeXBoZW4vcy90L2Mvay9jb2xvbi9UL3Ivbi9pL28vZS9nL0YvcGVyaW9kL3NwYWNl L29uZS94L20vcC9mL3RcDXdvL0kvUy9BL1AvaC92L2ZvdXIvc2l4L2QvdGhyZWUvTC93L0UvSC9a L3VkaWVyZXNpcy9kaWVyZXNpcy9uaW5lL2VpZ2h0L1wNQi9NL1IveS9jb21tYS9iL1UvRy9wYXJl bmxlZnQvcGFyZW5yaWdodC96ZXJvL2ovZml2ZS9OL0MvVykNL0ZvbnRGaWxlMyAxOCAwIFIgDT4+ IA1lbmRvYmoNMTggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0MTAxIC9T dWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIlsVWlUFFcWruqiXoM0jXRZHenGrgpiZHNjUwaJ QDDCkSMuOHGJSwsNosguy6gBJ5jgIIkLbmCMzgSJk6NBc5ITRVHQTLlTMIBnHJAZxi3GNbPcai6Z M492lj9zuqvOue/d+/r73vfd2yzjpmNYlvVLSpiblDg75O3CjcXZWY7CSSnZWWuLk4vtOdnpI/v+ mpXVzG4VBp3mZzDjePxoqGEoiIePvOGcj+JnijcxOpbde/ytvPzywpFSOTA9SJ4WPWNGKH1HT3W9 I+T4jLw1DnlReVGxY0ORnJybnleYn1doL3ZkTJbl+JwceeFIbZG80FHkKCyhq//BI2cXyXa5uNCe 4dhgL1wv52XKKdm5ecXl+Y5JSQ5aGD9HtudmTMmjmbS+aOOaouyMbHthtqNo8v/lxLD0w3iwjJeO 8SGMr47xd2cm6ZhpDBPOMTMYJoZhEryZRXrmfYb5E8O8Sa+JcWP0TBxTzuxmjjPn6a0Esvnsbd0Y Xaaum1vJXePQLcKt3u0JH8Kv4nfw3xMbiSJp5ADp0Yv6dfp2/WP3cPcy9888pnjUe9wbtWjUSU/W s9qzx8AZUg0fGj71muBV4fU7Y4Sx0njLW/Le5H3U+8Foy+j00btGH8Qoo+vrrC5lO65xcNdZLeIY jEALfXIsaDiN5rOos31L7MAUgDu4WyAfDBAPNphu+3chpF7jKlAWYQxEgIU+ORYwZID5XdDZVpKv kWlEd3S3YD4aMB5t6CpEC+SymZDCZaJFvELAG3L5aGKUoUJlT8Nh7jRUiLCH7FN53ENofs0A2/KM azEbmH5yaGAktUrR7ilsmwqayrXBRhF9zssgQe4g3Ifx4LP0HyhhbgTex/E2dYf4shs6Ierl4aC4 CQnYiTNDyp722oxHSpzMH2pKTZAIO4RmyDLfJDDROY9/hwhxuARNX7wLvo95Y42i9SuslqZytWYt lhxUeOwjUAUO/vddDx+AzvI88Toa5s0tKVhp25bAn/jmWmOntfOCfQ4SDEdzZJyE8zCKp5DhlAI1 ikkT1WpVeAHh8EC8Tvr60mchH7IIR8VkNNRnSptS+aKrF6suW8EXgrsgVM28Etsg1eqFtd/vG7z+ 2ALe41vkxalbi5fZPkjij1386kCv9VZvTmSk/yp/KYlQVhCpaKEqu0M7xMFlSuokRPJ/JfsVPoD8 qBXwYWQ4Ynj95mQe7hP8WBHh71ooX0umDYe6MKoKOCjd6SpHFX8q1p89W9di/Uv36hlIQmehuHDp oU+ypPeS+bLzF7Z2WkGGcY8gEvTTb6Hnhg0fVOVKrVDAw3cjvzfMjQgFfQqsVrJPmBQVVFV4IozR LjrDReHJkdVpBxZZcRNyWIk5aD2DPhAL416CniqpixlA/YwVeUuXSNsJ+B76AYIg0NreuqnshIT7 h9vEsG3zuh5aHnbfGQSmJXlW2OzgEJuxqk1jSuBgm6lZ/VyFcrVMFf4G9WfFmFnn7v8IEy98uVNq zX+UE2wJi0yLsgnr7movxBvd62dGIbfmrSJp+W+Xn2mz3L11tse2q02UkU1Br5SWdy6sl7brhbo3 ioPnBlhQfJYKJngN2BtgeZhyPvq4jYrjP/gJMN89tQjrwBDyrT9FohQ0UtqUvGnAxfuckPT1MVE4 V/JN+3uXrLAJOKiEHLCuAB+MxXETUE8tq/vjdNDfPdN0vlWqJej7ixAMwkBr2pKGw9kS7NfaxHu7 riROsUxJmBmBzPKbt+91PvnB5moQeDxgankWCPMDnwmqkATjtDfF/7aLcOT14d3/C41QSl2Sqmgm lbU7JU7bCjUiXiVQqZn44TU/eYg9hIqQyoOTnMRUvpOgH+0LWlijQKMC26mHo9RSVXj0hRkSiaDS tvf8M1j67K0z97ms+qDuTudzC1jR/TC62dBEfjnMiuBJhBdd7WtjURe8FA1SOAEfrVfsIsLae+r7 YcgGOKb9Sgqj8GZVKNozJetLU49KyUx1RjujREE9tiCtLs6K2zAB47AaF0AQesCcnhMH9zRJe67w lekbKyKsOFEGFvxgJfXQFFilXK7Kb5UoYdrFvdTWt6mtP3SaxEECQc/n4lQsQQHHYqaE3iQ6VYQs AntgArVhLazF0A5MlXA0MSqU91EFahW2WdvMNZthiOylY+ArcgmO8lBP9tHgIGmFWh6Ou4InxPgx veJ+V02TVsI1mVXSBf08nWq0MbDuVfKn5AANBinjkxUK/FqBzxT2jso5Fzini40JiXWzrViKyTgd 38MlYEIRfg78habdjVI3AI9byRYqUQxZhtv4yuL08gQrBkwAHgLADm/Qxlxx/WZl7mXpldoUytVS ttlppvA7SOcIFCdJxH6+g0AwFXcOScarPDrJDbhKAyPm0vE4r5Rtgg0u8BBIk96mtGoUp4kua250 mR4xwvYUgXFOE59IjNrimoGUEifXa2p2gpDfbL5OYKyTo+MFXvuJ4y8Tzd8VoZVGHa8OlYnQPDx2 eAjHaEN8yIg5R87QhgboaG5yBglLmugpwmoYS7fpOVuGh/j+V5UpRNiJZhpvJ7iF7lKDKpRquwKf U6lzqNTVVOpu0tdTFoKeAfbXpViCgfhPUSU3oZ1/SqhPrF0QDBP9m9Asoadrer4STVun0pvqdN1U H7n0m81pDdIV3E9BJ8ORraeqmhfs9a3Vg27nYAcQ+pf3s9PIVdswjLSlii9IV3vBTHRDsn6ylEBB uezMgpcK81VOa3DGiEeWLd4734reyM9HPwn/xXeVh0V1XXGW3ueAOknmZTCd18zTNCr5jEYxooF8 qBUiArJF4gYVGMFBsMUFBikIOMNmhMEZWcI6aIyKgCyiJpXKqCwdRUfcrVslVWyqrRp63vSObc8b 09Z+X7/+ed+797xzzzm/5c2B8hw6WUGdpsZPXxlRsz9emb6EZDaZ0x9wwILHNXiHh0BaXgXjFY/+ cPj6iRM5aUeV4mVtsn7nYaHUdRgvCmrE6QsZucSAAtuBS5GD88SK5vTblBrn2zhai2yh8mBmin01 oc6bF8+hYznP0IGnXVVnjUf4IRghS5hlVE+ygjZR1xAF/emf/FCGvB+hFHjvU0qFnZ/fEDpEzXz+ t9komT4edxi2B/psTtiZ9hdO5A4Do45hohZcFTMqfDOPoX2OxSpcBDrAJEIxRRhxTfEQYkUI2KWM kCVcqRog9iXMNhxqYOzZ9isEK2eO64JkM8wyy6qtUGjJs7LfCIFQKd/dqW9rUIxG9FOXsIiMrHVK XTCpben9qo+72KEKSN+RVZzFl2i2lGzk6Bv04xT63tzz4Td5Vnf19J6zR5FcWf+CtOKNRakSC1PS avimvEPCHqA3KuTwI1BW3VOaGopN3MTsqEnUnVux+lAvLxUzEfzMkKGRHfsWkJhOwE7bdvkShipf KAgbqFPnrc9bJznHGA9XNJeaJPiJ5p9Xt0V+z8H8b8EXNdJ12R+p29zo5NWJoqR57pMPtwV6U/cw ZKEJnilX7wMZgmnwBi/V55jxS5oGWYeD/oR1wg6kv/KNoeVxHF05mY6ngdRliL6GgtZpMO7ljRaS m5ywLYF7P+Dm9/CTG6MwubNvW179fyXdYYXac1oTlu+eI+0Aeh97cjEj5PBCjnrPQFJ9h47pfhde wyL9/jftp9ocRdJp8tcX/RJvVbJ3V+vuIxK2iT55JAf3fpgJE4a7/GdS8hGdRpnZiefvKcV2wXIz BJidOywwZHEVUiFPXnpIf6hJAZKwK2gB502lH9D59O0H/jD2TkdNxUFl2QDJVMVkhnCzgk4//mLn FyVVfIVZPlJ76e5j7nbrsnk5xdt2ZPPSiaZ0IdoMq8y5FbIBQcKOXEZn81iIJiBjqsyEsoyxndyq rbt5lTtYoy0u49nXq3sIG7t7y5aSzRwdm0LJ7Aw+dwWOPbMtioALUlyKGbzNgldXnFnWYoVb+9lb OhokTx3o0fVxoGp7BAHt/DV4Tth3y4/t7igzSUKYPLVWnZ8kKWbYW3d+9UmzL0f9ZtHpdA51GXgP xl/o3dt9HOumTcSENqxdRKegdlc0r+RH4CZO1iB4wusjx7FobkGUo+z0OOs90YYKarFDzsJiK3Lq IHMKSgk47TkFLuDCnW1JCEsqTNOt5yNoCxlkzqDiGFsMh1sV3y0++YHSpyBmw7owzOcaXEPsOmhb MGhg5l3ZfkibMcL+RYwIToIB37Ke4Aap6AMWMFvnkqvibprSb5vh2E7HCWPE/RAjGMSpdrNbiUq7 OSqKy8nZWZbLZ0aSQpOpoJH785d3LlfzGMvX1vRKLJF52xogXgNVojzkOK5yGqpBRauRsKkG2qAf 0sl0htbReBy974RIsvQHodkuCk264wh8aNsu3kR4WyyM2Bt40wIb+qEUISdu6IFK8rC+B9yecwN7 Yz9NyN+gS+Ej6R7yf1/1wgFibDN0NChGPj0z2yc81n+9spi5UvRZ5yIuQLUpeDVikg3X1+m/Kj2E fS5OLUjK3ySRvpoDmvbjYgLdUEDAbW8f+oz/3R/DIWP7y/6EBKuj1Eoxclld6Q+RNxWm4QRJHRh3 RlQ+teL/TqKcsjfeR1/p/1e0H37w1s/uUw/8YXKlk+h8pTVPDh6D+Ns16cnRgGl03EI6kb7lFXVx GL1fRDqCQvBzJMlaoNbK3tpKE+WDzG9RyEuYAFNf/CUOFtzHoF7AhD+kkk+Ck6KSxOuq9fVl+0qa MKnCBG2sNkFygIbJ2WhwuozoHj98ePFc6h4uspOSVXutvf27f6EwahCH6znVW1jrfo/zzEnQE9bz Yf0RIM+4uvodulq++jwpzczUp3NL1qxdmSx+K/DfBShKLtiQ/wuJdMXLClgHgbO6ZtfINSe+1vZw T0aPgYRH5xhbcV8xdLGmu70rN6NZaeojtXGxxhjuo4nxU3jqATFl1FXx8bwtobFx1Y3rlNKJGM3L 7PwARX8RDvBUJjuKPEVrlE4K0rb6rFEs61QN7asv212Pzp7kbc0szOAS0xs7m43NhhbeDGUEJjh4 5MdME/CLNpGX1KnWyM5YocjCHhcOOmCxkhYQ6rY5nDpTFy44qb2/Rd9oaOZ7oQVnNpI2El2yNkGt mHZh+UPL2VZzqxJJNLBga1FqUbKoNF/qG3e1SNBEWYWlGudzwkJXYTvG9Wdojn0pYiJSWEqCmQt2 A7mGsv0At0msqLbnbHpUW3ePq6LaanFPCXMS919noA6Bjac3Ok6vwjcLGKpzLBJwEeSwocgHzvFC jWu8Bx4IhZQRmoIegY6HRlBDPvFlqDeN9IJItHcwBr2kVI/MqOq0faiRhQu/ZtuEXEwRJV1rD8a4 y4VgvOoluzHWh6gyklRruKys0opcnl2QFUXY3Nz6hqJGztrW3tvEI7aFZ3dl3SMzwITUYmJ7uoVn SBnXmZq7xA/NG8ye+5+lFHw/R36KluZU2kIraXQlZFQycNDw3GgXdo155aEEDuwaNdr/XummNC0u 1/5jnJvZ3TpW6HlTCJH/U4ABAChe0F4NZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag08PCANL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDc1MCANL0NhcEhlaWdodCA2OTggDS9EZXNjZW50 IC0yMTAgDS9GbGFncyAyNjIyNDAgDS9Gb250QkJveCBbIC0xNjggLTI1MCAxMDg3IDkzNSBdIA0v Rm9udE5hbWUgL0hCS0hNTCtGcnV0aWdlci1Cb2xkSXRhbGljIA0vSXRhbGljQW5nbGUgLTEyIA0v U3RlbVYgMTQwIA0vWEhlaWdodCA1MTUgDS9TdGVtSCA5OCANL0NoYXJTZXQgKC9DL28vbi9mL2kv Zy91L3IvZS9kL3NwYWNlL1QvbC9zL3YvQS90L20vYS9jL0kvUy9QL04vdy9rL0QvcC9PL0cvRi9z aXgvV1wNL29uZS90d28vQi9oL00veS9hZGllcmVzaXMvZGllcmVzaXMpDS9Gb250RmlsZTMgMjAg MCBSIA0+PiANZW5kb2JqDTIwIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg MzA1MiAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJbFVrUBRXFu6ZoS/ycIRpGmUmTvei Iqg8YlBBRRQxokEQRIXgqggIowjUzDCgIhg06wMVA1FQcUWDjxUUjbr4CIaXsj4CmCilpQY0Rsyu rCYTPT0eUrW3WfffVk/11Om+373nfN/5TisYOyWjUCh0EWGfRMyLHPuxMcdsSEs1+oZlZaTMMSdl GJLl156STiG52RU6K6UPnN1xKu5698O7KSzsGAINri0fDF6nYZQKxZ4TM7Oy1xoNaelm0TvZR/ww OChoHL0HBwzcA8UZKVkrUsUFa03m1DUmcU5mcpYxO8uYZE5N8RPFGRkZYqyMNYmxqaZUo4U+/V86 osEkJolmY1JK6pok42oxa6UYacjMMq/NTvWNSKXAGbPFpMwU/yy6kuJNOStMhhRDktGQavL7fyUx CnoxGgUzlGE8VcxoBTOGYfxUTKCCCWKYMIYJJ0wkyyxgmU8ZZhPD3GSYMZQnxo6xZwKYDcy/FQGK UsXPylHKeOUFZYdKq4pRnVH9bhdll2d3kw1jd7BvSRSptB9un21fbf/Uvn/QlkE/OYx12O/wi+M0 xwrHt04jncxO9U6/Odn6I9X0V2WxReUqwAX+UME8aREPbs/Qqb+OBZHAWFsUixzBAvRl1cWglApA qZA8wEslrQYlj9U7CTj9DGvAB6ZpYZjYis5zI3PM0fpd6MrWXm45dk137XJ6JBIswfHoivZCDtqz 0jKiLrRCmZXClJknNC2ghTgQuZdwpJCHj16AA/iDw6x76JS8qsiUJmwjfSdvdQOrO3fu8/wzAud2 +leW8z6QFl6xUId7kMGdaBG4lziibQT46cEO/srPyvAPXpzd2Nhe+/jB9cMrFuvVJVUWCAQltIJL ca4mybaQu8/1SOHS93wJqcdWFjMIXscjPPiTZxDIQgP5CgNlEpCTSfAnapESAEutMB2UGmkciCNp yq+r3CGRWMF8AJZ0GdpCyoWd9lz6o4qOjh4tcKPOoUKPyaSx352/SLjXXR0bw5AZ+9kEIZG8loz8 N4RLb7y1NSJ4Wm64EEdPKKQUbwel4ZSmE7y4Ti7ANtEWxHOd1VEzvpylw2L0xcmYgzGv0RPSGpt2 77sqHAYta0pOzJuvwyGhVkpdEChkArsa83JqBHWJrJpRVu0qVQ2uSD38FQKanvmowDh/dMSlwlyC QajkoZDA74+hCCbCX3ByC3oJuJKoMZPydp0WTqtWnJROqE66U05uwXUWCshhULK4gZyB6SxsJV/R qJ8n6hJaBdVTCUso5B491bbK9hF/PCx4b4gOd+MU/BDLMAOG+0JSx4N9leeFh5Iri3XEjEoWvEkK zmM3r7cUr9ahU8hzYCH4LXjAtLvt+elNAm3Y//ZrJVxSVbqDF4HRsjxeRA2WKovUBc5U3ZPvpnJn aKIehOsEN6mL3Ula+rtY0BLoHIhwmBx6E/CRwRsIHu8vZreRJVIxi+uJ3CvyGdW2dFW1u4xSSTUU BV79NSxEvLfFMIKk/xhFoY90jMVZRN32Xj4FFU8SZZOstH3KIxmzPDBUCA9KoZ2q0uLk39CFsunw pu7RXX1X9wVQAdFC1ChQYox+CxXi9ZUQPxTGYxwGev350XP4UzfEwCSBGhUOUlYNspgLZDHXwEH+ EYEAEH6EEAjDWaXIC+hI0PuPqAH7ulK160lba3544NTkaUICtd37DKlJvHrlDBtsU/gjsZFlUTrU ouYTHC1gFBQdQo12+hxDRHTskeqF+jR0Ys03O9e368AXtDcgVIBFWLQZ7LRt7YcarjbmW87raXZS D924W2pTddNjIYEap7+HlRXiJPqfQI7I/VFHhTpdDJPQ0yI1g0jFku7CIC4exrrDDGoH2C41U6pL +5tZmEngicz0KMJVYDHlfhvZSoXA+QTzByKLHIm0qr4JTzaXwriHvZZzfZoqcINNoOYWw1N3YEn5 y6uwtFMLg8ecHRkdszE3Vs855oksV17d2Lr/uu5yS/7i/OL8LRuEJQQ1GFuA08Z9t/iFwHneu1R7 7ZKwk3ClmPgP/ikwe2/rL5MgS8bHo3UGw8E6QY3H6BjrtuYe0pyns4DaVTJJJdSue9MSv0zQ4Tx0 wuEYgR5PxoNHfX3JofPC/jfsuvQVRat0/jnt7S/bXr09c7po3VGBOt/q30u3AlPuwF55UpWtiJ+L 37BXkuKr5+hw5iQMRT+B24p2zaNA/aChpuWcnuaWVxDKgivZdbSsvqweBJvLMHyGD/mOE/Oi6eJx MUh85qy/862ey7t/EYb9S0+5AvdeGNynqKE07QA3lXQIMviys7vPfq2FoZNuI4ch6IJ+GIi+r2aC d3NrxYFv9ZVvWHPCog1xOv/40/8UDvby3x+ta/hR13IiI65w+8ZthZSLx7QDJvTBCGtBhaZRms29 6JSt85M0gQVnUtXHojNpqqh8dk+3b//Wz8sFzuXkK5ZbXpqz5osMHQYsw0E4NFsYQSw+rJVOQjRa wdEKP/T6WwO7NBdAhI0Qwj3fjdG88bs7n93Rwfy71AxTa4XH0tDS2i+qS/Z5IE84x/zpLNfVtDq2 drYOp/iiP62EbfIE13u3626comqiw2qLN3rqYuIPHl4kSEOk4bzPMmTFaGPjjfsXgHt543RitF4t 0mqmXEgaEEQKpYpcrJLLaYZy9n7lqacvdH//W+by1E3pm9OFBNwij5Ym2MWW1uw5/7X214ibXnou PiY+y7CSfrxuwVkWtWRgdEnluUDAjfboJZwIEwe+H3S+KKVyeQnnXfUL78zQJ8fBbQBDPd9kgcJc KMtV/IfRso1tqgrjOMs8lzvdmtCzstmb9ZbBsKJoDBINJtssH9aRUUZ4mWyNbmODLG5uWbsVV3XS zXZzODZGuBHLnMVJA+0srwmRzdYEFHECiZpgohiFSXCLEkKeU57GeE4LGuMXc3M+nJd7znP+5/n9 zxljFzL58DzpLIwLN3oYxwk8JuGTEIYB6CZolXAdruNcXGOr/l4x4eV/crNML7Qi4U31QInYX9DF 5dUzC+jBzrcYTo2JQT+hgUuBDyFjRomEnI3NO2t6m9VNuJvc670cCMK8G//ti8PbZN9J7dPTxivl XxavLm22NZn6pfO9FR/bFWqrqGzdLO5yatEuEVwg9Xn8nX63fF/pVCRC6ND/F5rmp6W23ZeaWvZO EsyT+j2+treaZYEVhyqDEwXvgjkTjv1qKG6NXbwR4/b7fXCDbUUVZi9WP2dlBnwe8/lXikW/PAVL YQ0sgHwoh8JlV1HleOL6Tqi+3a3BVREnlER4Oprpd07cZuAR0SXn4BQ/Empf/cEX7nMKlF3jhrwS dPafMbespn1jg4hNv/+ieEz1d/jdvnaZ2uEHVAyrtqMZH1jj+mz6+hRkz5w/4qgwpVlaPLoDZJRF srBn7qnyCXjIj4HTP91UAqN9vv0cokOQR3Z7Xt3VpdDSteWbNzjFSuYDswRzJb/T7/J3yMKm5uC3 uYxvwBzhKjA7GzRoji17q5VFmFWLOSoawNrzrLHO8dqLVY2jY42mV8zEdSbeE1dgPmQdB6MKerQe /Mp4YnLf8aPRN9+YEDGmLOvKnP4mGGk0xlYaZqVGtBJvfU/DVqPlwvYZE60Mju8ZCqo0GrxNeruc PqfS0jl6+P3BA4OaegY6/nGGMCzHJQ7XIrJMSnth3Un2nFsf5yK/wGaZZuBJuxE1UtzV9PQTSm1L 6NTRkYk9E+ok+EU+b8JB0vvyzvoGI+0r+rriDxO1nJ06FIkK97Z5txAOzTvvDX00fFjmr9gClAWH +mkWpm2wfKF4B8QFgIUSHcOXkjpOUBXTESwQnAxArrmTmSCHX1XTd+fxm8q4EB6XaC1UMhM/81DS JCiEY2KGAokOYXUyj8/QyvIIPirh+lRtm6hx7ritJXLcGdWJwsxpvquZZJRYHS3urUqbZ3jYo7YU EW847IsoQKa+vXxChVvsOsFHJKxLUj5LDaOEQ83ugKw/Aiqq8DsvKh2jMShJNHHrQElqR5mAxAOB 10H+V5MO1IFZcOi6tYRdwyoNnJoEoeFbI8m72vx0o0ODHZrMG++MJP/UsuYeBPNDu7J1LJabqDf8 JcAAz/pnRA1lbmRzdHJlYW0NZW5kb2JqDTIxIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0 b3IgDS9Bc2NlbnQgNzUwIA0vQ2FwSGVpZ2h0IDY5OCANL0Rlc2NlbnQgLTIxMCANL0ZsYWdzIDMy IA0vRm9udEJCb3ggWyAtMTY5IC0yNTAgMTAwMCA5MzUgXSANL0ZvbnROYW1lIC9IQkxFRU0rRnJ1 dGlnZXItUm9tYW4gDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgOTQgDS9YSGVpZ2h0IDUxMCANL1N0 ZW1IIDc2IA0vQ2hhclNldCAoL0kvUC92L3NpeC9zcGFjZS9UL2Uvcy90L2wvYS9iL1MvQS9DL2kv bi9EL00vWi9OL1Ivby91L3Ivdy9jL20vcGFyZW5sZWZ0XA0vcC9mb3VyL2svcGFyZW5yaWdodC9W L0wpDS9Gb250RmlsZTMgMjIgMCBSIA0+PiANZW5kb2JqDTIyIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggMjIzNiAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJdFV7 VNR2Gk1mSOILVidkqhOYjEAV0eHRWVYo+EBRUZACPouwFXF4LI+BARlsLRZX3VIWu0rrkxXZdusD H3VtrQoqWyu2Vs8i1gMK+OgU3bHU0FX4Mv2me/Y3qH+05+xJTnJ+Sb6b+917v4SmPFQUTdPauFkJ c+YsnDzXuqY0N9tsNaZYCjIK3XckRaSVcR6KzygtTsMtP637KYqB9b+BE2PO+wzv0FAqmn7/g9mW orXW3OycUkNg5iRDWGRExBRyjAwdOv7WELPasspsWLS2pNRcUGKYX5hpsRZZrBml5tXBBkNMfr4h xV1bYkgxl5itZeTqcxqG3BJDhqHUmrHaXJBhzTNYsgwJuYWW0rVFZmOcmRTGzDNkFK4OsZAnSX3J mlUluatzM6y55pLgX7VC0WSjhtOUQFEvUJQfRQXQVBBFGVVUGEWZVNRUioqiqFkqai5FLaCoBIZa xFABRB3Kg+KoaKqYOkK/QKfQf6Pv0o9Vw1Xxqk2qC2pBXaz+s7pZfc9jmcdRD2DmMH9g9jBH2WHs XLaKtXPjuALuMPfDMHFYPhZ6ufepzrdt9BVZDdfRIESBTwxMhnAdhHdCUCf46sPYMJRiUI8zdBj9 DQbcRx/9syKIltW7nG8LXehzAydjuA7Dp2PQdPTV97K9IN0APczQQfQsCAgFUnRpXxmYepSRPdU2 zd4nUCTz3dAHmwQsYvk+KFRGMjWsy+Uhg8neY1LS0Z/Fo650JhJucl6X1vfAiR5I7lnToDnvgB0D fB/vrZQ4YwW+b7s1dvsKEYsXYiomo+kExsIy4Pu+hQAYM/Mhiskr1qanSVXvMKCruQyjQCueOllZ fkx6xaURZmbOnhq5qvvqzTNf3b51fOYCvReUEZqxPfDIQWjucCbynTu0T9h2iGXgIduO5ESz2ORM ZPxYSHIlCHiI5Q0gwSPGa71dOWkvOKhpGeDb+FClwxkt8G0Nry6tXSJiLoaiP+ahFSaiHxR/cmVL Q4u0qY8py4mreFXEF3EE0BABYYMwDMLPNVcUfyYRKtV2Za+dvi0rwwbUt7WwioXXwQ88oQLyMBK8 MVPCVaxsEmA4S7pVT8apGDclAmdKfizxdl+ZM9FGfyerv9PKzsSJrNe7BG/QRttltV2r+NjxlDJI riqLq2FEUJnS7+64V1a+lPm0Xq3M8vlKfw0Hb7j6mR9YeEPpZ2pc/QQII1l+J+a5OtGidDJk5SYK PsiVKe0wmmDYZXhEMOxPMdoJRpurnQFvNwe+ztVaxeGXSiuDPuxQJhrt8Cd3k/DHATXEK4PCXfar B3mmkGn5C6VAdqJLLcjQSBhowPNzCAETjjyL/hLGs16k+LIdcoaK33IrJMPlS2zL4ep5h6RB3MwA y+JYOLTm5Lrd+TvG1XDduy5fuquDKBzXgHqSaLd037MPmjIT4hZlTJF+RxQa8tD6oebMACwd4Dv5 QCXCGSPwnXUrFtemi6iZNB9HS1gALScxVBcZlZey/JX6Xbn6ymBm3emmN5tFMADXCpMkeB1b8kGn ++Zq/YXz+zfYzg3lXxm001BOZq1cKyuDUGB3HTJBARFwRrU9zu2WZqvTny9yTnImCn4svw+LXYNM FYt5yiCDHizs+TmRgTFEtqfBaFRs6katYrO71Cz8rNQxvS6zCf7D4X9ddQyZmY74r2H+NbnsfIfm tAyVDr4CaEUvNB7/or5FdDT+3iTVZBVXZ4lBaMhEb4nfjOrOFaC6d/bMoQZ9DcsnzrdzVburPrqo g2wOpKTrOGHBIpslTQ+NeEDgP5qRmhy8ctmBf/aCpvacvr6+ql70cr9U0XRAuU3T5YDPZL6Zj+vS 9rJ88/UazvzhxfT7IgRfAR8ilO9s8MTAl5bnpBVKVXDZyCqCq1KIqslAZoI4/rUndx829/3444mg kCrJa9n6DoJqq9ccl4eGK1R5hwzX9qLU98wihvqjB4bghAH0hOAjp7b89R/SxjtMeWFmZZ6Inqny /b5Wx5ODxzauOya5VYHp18CvgyaS1MlqJQ84obx0dt5C8aXotn5JoViIWAyjcToGTDGQz9rLt1EF 8+98Ur/zmB5vwjHh6rbjHQ/E7tPx06ShIVO22UA3oLk3MNHB//uB1qFsM7J8qAxFwihq/PiBoZC7 n9lpo7sc6i6tA3azUI67GRBZrIePoRLKGPRmMQMzGWWRkXs6uhts9AOHmuA5NxjJkPoSkJSv4zs0 txywxr17+/DNtwjY++zD447vO3ZHJ+jxC7LkfrHs4kCddge16dOLZ+Xo24qSDiaJM5cXJWVLVSyf dsPEeT3HJW7tcfCdbn5vsfwpGN10b1Dfs/nvyThSh3UOuMCBb1IPjo2dl5Ns0ZPqpO5QzmvIFreU 12X1aagVnpkAxgHymZoAIf7gduapQXpZS4zol1uNQaGpE1GFamIN+Zkkl0EqgXlGgkSmuwuzBAcc rmHTDpzL6f1VYMKS081WN/3A62Ecn6YIuPX/hMZAeku4NqeHwPJt7sbWEWPA+/OuO3v2Vm2s09/h 3rW9ucUiLlliXjqEmHSLCGJ4HrUjMnjKfOfHe4TSk82bm8T7354FWoKpWFzwWPfpp/VNDRcqKvbp +cDaHobv3J6V/d5r4oTo5eMl9Ifi2mDd4qVrVxYt3fFBln4Ik+2gwcuhhsfKNgFFCGSNBQyOQG4G cHiOe/FSet/BA7Vb9+m7uA1vlm0oFFdmN7ZK0Agi93SoUmzPPCpX9hMII7ptwtErwg36yL8UX4SR Oqgz4gUOfVsjYWz7v45e3O8e4riX7/9P7MCS/6UTKBEKTftRJFzwoxakH1S+KP4xAZUvcj9MWFXY vnv/mcT6nQVYHD0FFUc/HO6Cq8C9whE/TwI16LMJT/gt8McKpEHkhxXrb2a232IQLieQC9RvAdLP yCac8F30hwOwNv8u8ccBJMBXD6xIp/+Omf69Yjrb9xUTv07+8286O5IgB0yQ8zrXS+4f30V+tIgC BBgAxHni2A1lbmRzdHJlYW0NZW5kb2JqDTIzIDAgb2JqDTw8IA0vUyAvRCANPj4gDWVuZG9iag0y NCAwIG9iag08PCANL051bXMgWyAwIDIzIDAgUiBdIA0+PiANZW5kb2JqDTI1IDAgb2JqDTw8IA0v VHlwZSAvUGFnZXMgDS9LaWRzIFsgMzAgMCBSIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAgUiBdIA0v Q291bnQgNSANPj4gDWVuZG9iag0yNiAwIG9iag08PCANL0NyZWF0aW9uRGF0ZSAoRDoyMDAzMDkw MjEwMDUxNiswMicwMCcpDS9Nb2REYXRlIChEOjIwMDMwOTAyMTAwNTE2KzAyJzAwJykNL1Byb2R1 Y2VyIChBY3JvYmF0IERpc3RpbGxlciA1LjAuNSBmXDM3NHIgTWFjaW50b3NoKQ0+PiANZW5kb2Jq DTI3IDAgb2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5ndGggNjUyID4+ IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlk JyBieXRlcz0nNjUxJz8+PHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5 LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8x LjAvJz48cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29t L3BkZi8xLjMvJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpD cmVhdGlvbkRhdGU9JzIwMDMtMDktMDJUMDg6MDU6MTZaJyBwZGY6TW9kRGF0ZT0nMjAwMy0wOS0w MlQwODowNToxNlonIHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIgNS4wLjUgZi5yIE1h Y2ludG9zaCcvPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvJyB4bWxuczp4YXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8n IHhhcDpDcmVhdGVEYXRlPScyMDAzLTA5LTAyVDA4OjA1OjE2WicgeGFwOk1vZGlmeURhdGU9JzIw MDMtMDktMDJUMDg6MDU6MTZaJyB4YXA6TWV0YWRhdGFEYXRlPScyMDAzLTA5LTAyVDA4OjA1OjE2 WicvPgo8L3JkZjpSREY+PD94cGFja2V0IGVuZD0ncic/PgplbmRzdHJlYW0NZW5kb2JqDXhyZWYN MCAyOCANMDAwMDAwMDAwMCA2NTUzNSBmIA0wMDAwMTI4Mjk3IDAwMDAwIG4gDTAwMDAxMjg0NDgg MDAwMDAgbiANMDAwMDEyODYyNiAwMDAwMCBuIA0wMDAwMTQwOTUzIDAwMDAwIG4gDTAwMDAxNDEx MDQgMDAwMDAgbiANMDAwMDE0MTI4MiAwMDAwMCBuIA0wMDAwMTQ2NzAxIDAwMDAwIG4gDTAwMDAx NDY4NTIgMDAwMDAgbiANMDAwMDE0NzA0MSAwMDAwMCBuIA0wMDAwMjQ2MTkyIDAwMDAwIG4gDTAw MDAyNDYzNDYgMDAwMDAgbiANMDAwMDI0NjUxMyAwMDAwMCBuIA0wMDAwMjUyMDA2IDAwMDAwIG4g DTAwMDAyNTI2NTIgMDAwMDAgbiANMDAwMDI1MzI1NyAwMDAwMCBuIA0wMDAwMjUzMzM0IDAwMDAw IG4gDTAwMDAyNTM4NzYgMDAwMDAgbiANMDAwMDI1NDM0MyAwMDAwMCBuIA0wMDAwMjU4NTM2IDAw MDAwIG4gDTAwMDAyNTg5MTAgMDAwMDAgbiANMDAwMDI2MjA1NCAwMDAwMCBuIA0wMDAwMjYyNDA1 IDAwMDAwIG4gDTAwMDAyNjQ3MzMgMDAwMDAgbiANMDAwMDI2NDc2NCAwMDAwMCBuIA0wMDAwMjY0 ODA4IDAwMDAwIG4gDTAwMDAyNjQ4OTkgMDAwMDAgbiANMDAwMDI2NTA1MSAwMDAwMCBuIA10cmFp bGVyDTw8DS9TaXplIDI4DS9JRFs8ZWE5MTEyMzFjZTJhMDI3NzYyZGI5ZTZjY2ZhZTY4ZmQ+PGU4 NzViM2Y3YjkzMzA4Y2RjY2FhZTAyY2Y3NjUwODdmPl0NPj4Nc3RhcnR4cmVmDTE3Mw0lJUVPRg0= ------_=_NextPart_001_01C37830.C84B0AC4-- From owner-v6ops@ops.ietf.org Thu Sep 11 08:44:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20344 for ; Thu, 11 Sep 2003 08:44:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xQfc-00091d-Sl for v6ops-data@psg.com; Thu, 11 Sep 2003 12:35:32 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19xQf7-0008yI-Cl for v6ops@ops.ietf.org; Thu, 11 Sep 2003 12:35:01 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 709662A373 for ; Thu, 11 Sep 2003 14:35:00 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 4964A2A371 for ; Thu, 11 Sep 2003 14:35:00 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 340F2250FD; Thu, 11 Sep 2003 08:35:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 31412250FB for ; Thu, 11 Sep 2003 14:35:00 +0200 (CEST) Date: Thu, 11 Sep 2003 14:35:00 +0200 (CEST) From: Mauro Tortonesi To: v6ops@ops.ietf.org Subject: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk what happened to draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt? why isn't the ipv4-mapped problem addressed in draft-shin-v6ops-application-transition-01.txt? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Thu Sep 11 09:50:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22720 for ; Thu, 11 Sep 2003 09:50:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xRjr-000Ew0-8D for v6ops-data@psg.com; Thu, 11 Sep 2003 13:43:59 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19xRjK-000Es8-Ka for v6ops@ops.ietf.org; Thu, 11 Sep 2003 13:43:26 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h8BDhLR24446; Thu, 11 Sep 2003 15:43:22 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h8BDfXHN090888; Thu, 11 Sep 2003 15:41:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309111341.h8BDfXHN090888@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-reply-to: Your message of Thu, 11 Sep 2003 14:35:00 +0200. Date: Thu, 11 Sep 2003 15:41:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: what happened to draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt? => they don't get a consensus and their authors are a bit late to refresh them (or they had not enough time, or they lost interest). why isn't the ipv4-mapped problem addressed in draft-shin-v6ops-application-transition-01.txt? => this is different: IPv4-mapped IPv6 addresses on the wire have far more opponents than IPv4-mapped IPv6 addresses in the API. For instance I am against the first and strongly in favor of the second, i.e., I dislike SIIT and our local credo is "IPv6 is not a new protocol, IPv6 is a new version of the Internet Protocol". Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Sep 11 13:57:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03200 for ; Thu, 11 Sep 2003 13:57:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xVZB-0009iR-SC for v6ops-data@psg.com; Thu, 11 Sep 2003 17:49:13 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19xVYf-0009eW-RX for v6ops@ops.ietf.org; Thu, 11 Sep 2003 17:48:41 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8BHmGA21032; Thu, 11 Sep 2003 10:48:16 -0700 X-mProtect: <200309111748> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCENKUo; Thu, 11 Sep 2003 10:48:15 PDT Message-ID: <3F60B5CB.6040900@iprg.nokia.com> Date: Thu, 11 Sep 2003 10:50:03 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: Mauro Tortonesi , v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt References: <200309111341.h8BDfXHN090888@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: >=> this is different: IPv4-mapped IPv6 addresses on the wire have far >more opponents than IPv4-mapped IPv6 addresses in the API. > I have never seen the "IPv4-mapped IPv6 addresses on the wire" argument raised in relation to ISATAP, but since ISATAP addresses also embed an IPv4 address in the interface identifier I assume that some may see this as a concern. For the record, if the site is not concerned about exposing L2 addresses to the outside it can certainly deploy ISATAP such that nodes use ISATAP addresses as the IPv6 source address in packets they send (e.g., by configuring the ISATAP router(s) to send RAs with the L and A bits set in prefix options so that nodes will naturally autoconfigure ISATAP addresses). But, this is not the only option; indeed, there are at least two ways in which sites can be configured such that nodes configure non-ISATAP addresses and use them as the IPv6 source addresses in packets they send: 1) A site can configure its ISATAP router(s) to send RAs with the M/O bits set (or, to not send RAs at all) so that nodes naturally invoke stateful address autoconfiguration (RFC 2462, section 5.5). Each ISATAP node receives a non-ISATAP IPv6 address delegation (V6) from the router/server for use as the IPv6 source address in packets it sends. The ISATAP router records a route mapping V6 to the node's link-local ISATAP address (LL) for each address it delegates so that return traffic is tunnled to the correct L2 address. No ISATAP addresses are sent over the wire. 2) A site can configure its ISATAP router(s) to send RAs with the L bit not set and the A bit set in prefix options so that nodes naturally invoke stateless address autoconfiguration (RFC 2462, section 5.5). Each ISATAP node autoconfigures a non-ISATAP IPv6 address (V6) and assigns it to a loopback interface. The node will additionally send an RA back to the ISATAP router with a prefix option containing V6 and with the L and A bits not set. The ISATAP router records a route mapping V6->LL so that return traffic is tunnled to the correct L2 address. Again, no ISATAP addresses are sent over the wire. There are other options for assigning non-ISATAP addresses to nodes in an ISATAP site (e.g., manual configuration). But, it should be clear that sites not wishing to expose their L2 addresses to the outside when using ISATAP have several options at their disposal. For more information, please refer to the latest ISATAP draft at: http://isatap.com Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Sep 11 16:31:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12655 for ; Thu, 11 Sep 2003 16:31:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xXts-000Mnq-68 for v6ops-data@psg.com; Thu, 11 Sep 2003 20:18:44 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.22) id 19xXsw-000Mji-OA for v6ops@ops.ietf.org; Thu, 11 Sep 2003 20:17:46 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id D3A808C; Fri, 12 Sep 2003 05:17:45 +0900 (JST) To: mtortonesi@ing.unife.it Cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: Your message of "Thu, 11 Sep 2003 14:35:00 +0200 (CEST)" References: X-Mailer: Cue version 0.6 (030716-1832/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20030911201745.D3A808C@coconut.itojun.org> Date: Fri, 12 Sep 2003 05:17:45 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > what happened to draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and > draft-itojun-v6ops-v4mapped-harmful-01.txt? we'll update those document eventually. we're too busy with random things, but our opinion has not changed yet (so we need to submit a new veresion). itojun From owner-v6ops@ops.ietf.org Thu Sep 11 17:41:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14740 for ; Thu, 11 Sep 2003 17:41:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xZ6T-0003PZ-NI for v6ops-data@psg.com; Thu, 11 Sep 2003 21:35:49 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19xZ5x-0003Ms-Pt for v6ops@ops.ietf.org; Thu, 11 Sep 2003 21:35:17 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19xZ5w-0005Rd-Ny for v6ops@ops.ietf.org; Thu, 11 Sep 2003 14:35:16 -0700 Message-ID: <007a01c3787c$26ca8430$e79e4104@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502582091@nl0006exch001u.nl.lucent.com> From: "Glen Zorn" To: "'Wijnen, Bert \(Bert\)'" , Cc: Subject: RE: Potential MIB work? Date: Thu, 11 Sep 2003 08:48:01 -0700 X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] owner-radiusext@ops.ietf.org writes: >> From draft-ietf-v6ops-ipv4survey-ops-02.txt: > > 7.3.20 RADIUS MIB (RFC 2618) > > The problems have not been addressed and a new MIB should be > defined. > > > 7.3.21 RADIUS Authentication Server MIB (RFC 2619) > > The problems have not been addressed and a new MIB should be > defined. > > There is more detail in the survey document itself. > > So if a RADIUSEXT WG is formed, do we want to at least evaluate these? Seems reasonable, although I think that the technical changes needed are pretty minimal, with the busywork factor high ;-( > > Thanks, > Bert ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire From owner-v6ops@ops.ietf.org Fri Sep 12 04:25:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13006 for ; Fri, 12 Sep 2003 04:25:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xj5V-000JUF-PG for v6ops-data@psg.com; Fri, 12 Sep 2003 08:15:29 +0000 Received: from [193.81.246.11] (helo=eins.siemens.at) by psg.com with esmtp (Exim 4.22) id 19xj4z-000JRU-T4 for v6ops@ops.ietf.org; Fri, 12 Sep 2003 08:14:58 +0000 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h8C8EucJ006090 for ; Fri, 12 Sep 2003 10:14:56 +0200 Received: from zagh102a.zag.siemens.hr (nets109x.sie.siemens.at [158.226.134.96]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h8C8Epmv005919 for ; Fri, 12 Sep 2003 10:14:56 +0200 (MET DST) Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Sep 2003 10:11:58 +0200 Message-ID: From: Bilajbegovic Damir To: v6ops@ops.ietf.org Subject: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Date: Fri, 12 Sep 2003 10:11:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Case: local network connected to the public IP network If I understood right, in normally network translation (local IPv4 to public IPv4), there must be only one NAT (simplest solution) at the border of network. (NAT-PT and all necessarily ALG) If there is translation between IPv4 intranet and IPv6 public network can then be more than NAT-PT? (all intranet is IPv4, and all public is IPv6) If you know the answer or you can direct me to some document I would be grateful. Damir Bilajbegovic P.S: In translation IPv4/IPv6 there is always translation, and nor IPv4 user, nor IPv6 server do not see directly each other, they see IPv4 address which NAT gives to server, and IPv6 server sees IPv6 address of user by which NAT represents user. Every packet will go directly to specific NAT (the one who knows translation parameters of connection). So, I do not see any problem in translation. I'm I wrong. From owner-v6ops@ops.ietf.org Fri Sep 12 04:37:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13148 for ; Fri, 12 Sep 2003 04:37:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xjOl-000Kgb-KS for v6ops-data@psg.com; Fri, 12 Sep 2003 08:35:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19xjOh-000Kg4-6Z for v6ops@ops.ietf.org; Fri, 12 Sep 2003 08:35:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8C8Y7X23355; Fri, 12 Sep 2003 11:34:07 +0300 Date: Fri, 12 Sep 2003 11:34:07 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Mauro Tortonesi , Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <200309111341.h8BDfXHN090888@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 11 Sep 2003, Francis Dupont wrote: > why isn't the ipv4-mapped problem addressed in > draft-shin-v6ops-application-transition-01.txt? > > => this is different: IPv4-mapped IPv6 addresses on the wire have far > more opponents than IPv4-mapped IPv6 addresses in the API. > For instance I am against the first and strongly in favor of the second, > i.e., I dislike SIIT and our local credo is "IPv6 is not a new protocol, > IPv6 is a new version of the Internet Protocol". Francis, could you clarify how your local credo translates to how you'd like to, for example, port applications to IPv6? We're in the process of updating draft-shin-v6ops-application-transition-02.txt, and it seems like there are about half a dozen (at least) ways to create IPv6 applications. The different scenarios are quite complex. Most of it seems to come from the different ways how the mapped addresses could be used. Could you try to clarify? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 12 05:41:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14336 for ; Fri, 12 Sep 2003 05:41:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xkJy-000OaO-Np for v6ops-data@psg.com; Fri, 12 Sep 2003 09:34:30 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19xkJS-000OXb-LA for v6ops@ops.ietf.org; Fri, 12 Sep 2003 09:33:58 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 821F62A3B1; Fri, 12 Sep 2003 11:33:56 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 5BEF32A319; Fri, 12 Sep 2003 11:33:56 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 5953515A73; Fri, 12 Sep 2003 05:33:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 56B2515A71; Fri, 12 Sep 2003 11:33:56 +0200 (CEST) Date: Fri, 12 Sep 2003 11:33:56 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <200309111341.h8BDfXHN090888@givry.rennes.enst-bretagne.fr> Message-ID: References: <200309111341.h8BDfXHN090888@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 11 Sep 2003, Francis Dupont wrote: > In your previous mail you wrote: > > why isn't the ipv4-mapped problem addressed in > draft-shin-v6ops-application-transition-01.txt? > > => this is different: IPv4-mapped IPv6 addresses on the wire have far > more opponents than IPv4-mapped IPv6 addresses in the API. > For instance I am against the first and strongly in favor of the second, > i.e., I dislike SIIT and our local credo is "IPv6 is not a new protocol, > IPv6 is a new version of the Internet Protocol". instead, i think that i have far more arguments against usage of ipv4-mapped addresses on the api than on the wire (nowadays many unix oses have a very useful configuration option for dropping ipv6 packets with ipv4-mapped addresses). first of all, they are a __nightmare__ for portability. and i think that this is such a valid argument by itself that we should deprecate ipv4-mapped addresses on the api immediately. then my credo as a developer is "ipv6 is a brand new protocol", because AF_INET6 sockets have many options that are not applicable to ipv4 connections, and writing applications that make use of the ipv4-mapped catch-all approach will be a great problem for developers (that will find themselves writing __a lot__ of checks/workarounds for special cases and will become crazy during the testing/debugging process). moreover, i think that the ipv4-mapped catch-all approach in the development of ipv6-enabled apps may eventually become an obstacle for widespread adoption of production quality ipv6-enabled software (since it makes more difficult the use of the advanced ipv6 capabilities) and may lead the life of ipv4 to be longer than what all of us expect or desire. so, i think that treating an ipv4 connection as an ipv6 connection to a ipv4-mapped endpoint is not only a bad development preactice but also semantically wrong. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Fri Sep 12 07:19:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16602 for ; Fri, 12 Sep 2003 07:19:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xlqr-0005FP-Mk for v6ops-data@psg.com; Fri, 12 Sep 2003 11:12:33 +0000 Received: from [212.201.44.27] (helo=merkur.iu-bremen.de) by psg.com with esmtp (Exim 4.22) id 19xlq5-0005DS-J7 for v6ops@ops.ietf.org; Fri, 12 Sep 2003 11:11:45 +0000 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 93027556C3; Fri, 12 Sep 2003 13:11:44 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id E0F3448D71; Fri, 12 Sep 2003 13:11:43 +0200 (CEST) Received: by james (Postfix, from userid 1000) id AC14A8516; Fri, 12 Sep 2003 13:11:42 +0200 (CEST) Date: Fri, 12 Sep 2003 13:11:42 +0200 From: Juergen Schoenwaelder To: Mauro Tortonesi Cc: Francis Dupont , v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Message-ID: <20030912111142.GA710@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Mauro Tortonesi , Francis Dupont , v6ops@ops.ietf.org References: <200309111341.h8BDfXHN090888@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Status: No, hits=-9.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Sep 12, 2003 at 11:33:56AM +0200, Mauro Tortonesi wrote: > > instead, i think that i have far more arguments against usage of > ipv4-mapped addresses on the api than on the wire (nowadays many unix oses > have a very useful configuration option for dropping ipv6 packets with > ipv4-mapped addresses). > > first of all, they are a __nightmare__ for portability. and i think that > this is such a valid argument by itself that we should deprecate > ipv4-mapped addresses on the api immediately. > > then my credo as a developer is "ipv6 is a brand new protocol", because > AF_INET6 sockets have many options that are not applicable to ipv4 > connections, and writing applications that make use of the ipv4-mapped > catch-all approach will be a great problem for developers (that will find > themselves writing __a lot__ of checks/workarounds for special cases and > will become crazy during the testing/debugging process). > > moreover, i think that the ipv4-mapped catch-all approach in the > development of ipv6-enabled apps may eventually become an obstacle for > widespread adoption of production quality ipv6-enabled software (since it > makes more difficult the use of the advanced ipv6 capabilities) and may > lead the life of ipv4 to be longer than what all of us expect or desire. > > so, i think that treating an ipv4 connection as an ipv6 connection to a > ipv4-mapped endpoint is not only a bad development preactice but also > semantically wrong. Ack - I fully agree with your view of the situation. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From owner-v6ops@ops.ietf.org Fri Sep 12 07:22:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16687 for ; Fri, 12 Sep 2003 07:22:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xlz1-0005nQ-Cw for v6ops-data@psg.com; Fri, 12 Sep 2003 11:20:59 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.22) id 19xlyW-0005l4-08 for v6ops@ops.ietf.org; Fri, 12 Sep 2003 11:20:28 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8CBJPxS057882; Fri, 12 Sep 2003 13:19:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 12 Sep 2003 13:19:08 +0200 Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: v6ops@ops.ietf.org To: Mauro Tortonesi From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, sep 12, 2003, at 11:33 Europe/Amsterdam, Mauro Tortonesi wrote: > then my credo as a developer is "ipv6 is a brand new protocol", because > AF_INET6 sockets have many options that are not applicable to ipv4 > connections, and writing applications that make use of the ipv4-mapped > catch-all approach will be a great problem for developers (that will > find > themselves writing __a lot__ of checks/workarounds for special cases > and > will become crazy during the testing/debugging process). So what's the alternative? Ripping mapped addresses out of current implementations doesn't make sense for many reasons. The only question is whether you should/want to use them. If you want to do stuff with IPv6 that you can't do with IPv4, you'll have to do a lot of checking regardless of how you do it. If you feel using the IPv6 socket API for IPv6 and the IPv4 socket API for IPv4 makes more sense, then by all means, do it that way. But for simple applications I think it's a huge plus to be able to talk to the network in a unified way without having to spend time and effort on making the IPv4/IPv6 distinction. Obviously this means you can't do any IPv6-specific stuff. > moreover, i think that the ipv4-mapped catch-all approach in the > development of ipv6-enabled apps may eventually become an obstacle for > widespread adoption of production quality ipv6-enabled software (since > it > makes more difficult the use of the advanced ipv6 capabilities) I don't agree. Just tell the stack you don't want to talk IPv4. Also, in the document I read it seems half or more of the trouble comes from mixing IPv4 and IPv6 calls. So don't do that. I'm sure that from the vantage point of someone who writes large and complex applications things look different, but as someone who only writes simple stuff, I really appreciate having the mapping approach available. From owner-v6ops@ops.ietf.org Fri Sep 12 07:51:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17267 for ; Fri, 12 Sep 2003 07:51:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xmQ7-000850-Od for v6ops-data@psg.com; Fri, 12 Sep 2003 11:48:59 +0000 Received: from [212.201.44.27] (helo=merkur.iu-bremen.de) by psg.com with esmtp (Exim 4.22) id 19xmPb-00083d-6O for v6ops@ops.ietf.org; Fri, 12 Sep 2003 11:48:27 +0000 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 6036855B18; Fri, 12 Sep 2003 13:48:26 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id AD7DB181EC; Fri, 12 Sep 2003 13:48:25 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 318368516; Fri, 12 Sep 2003 13:48:23 +0200 (CEST) Date: Fri, 12 Sep 2003 13:48:22 +0200 From: Juergen Schoenwaelder To: Iljitsch van Beijnum Cc: Mauro Tortonesi , v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Message-ID: <20030912114822.GB710@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Iljitsch van Beijnum , Mauro Tortonesi , v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Sep 12, 2003 at 01:19:08PM +0200, Iljitsch van Beijnum wrote: > But for simple applications I think it's a huge plus to be able to talk > to the network in a unified way without having to spend time and effort > on making the IPv4/IPv6 distinction. I do not know where you make the distinction between a simple application and a complex one. My experience is that the behaviour of mapped addresses seems to be different from box to box and the real pain I had was _portability_ and not the complexity of the application. And this portability pain was in my case much bigger than writing proper code that can handle IPv4/IPv6 addresses natively. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From owner-v6ops@ops.ietf.org Fri Sep 12 07:57:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17454 for ; Fri, 12 Sep 2003 07:57:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xmWc-0008kQ-5g for v6ops-data@psg.com; Fri, 12 Sep 2003 11:55:42 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19xmW6-0008fA-GW for v6ops@ops.ietf.org; Fri, 12 Sep 2003 11:55:10 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h8CBt6R07995; Fri, 12 Sep 2003 13:55:06 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h8CBrBHN094225; Fri, 12 Sep 2003 13:53:12 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309121153.h8CBrBHN094225@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Fred Templin cc: Mauro Tortonesi , v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-reply-to: Your message of Thu, 11 Sep 2003 10:50:03 PDT. <3F60B5CB.6040900@iprg.nokia.com> Date: Fri, 12 Sep 2003 13:53:11 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: Francis Dupont wrote: >=> this is different: IPv4-mapped IPv6 addresses on the wire have far >more opponents than IPv4-mapped IPv6 addresses in the API. I have never seen the "IPv4-mapped IPv6 addresses on the wire" argument raised in relation to ISATAP, => ISATAP doesn't use them and the issue is *only* for IPv4-mapped IPv6 addresses, not any other IPv6 addresses with embedded IPv4. but since ISATAP addresses also embed an IPv4 address in the interface identifier I assume that some may see this as a concern. => your assumption is wrong. Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Fri Sep 12 07:59:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17556 for ; Fri, 12 Sep 2003 07:59:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xmYv-0008za-GN for v6ops-data@psg.com; Fri, 12 Sep 2003 11:58:05 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 19xmYh-0008y6-5V for v6ops@ops.ietf.org; Fri, 12 Sep 2003 11:57:51 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 736D18033; Fri, 12 Sep 2003 13:57:10 +0200 (CEST) From: "Jeroen Massar" To: "'AS15180'" , "'200.202.112.0/20'" , "'200.202.112.0/20'" , "'200.202.112.0/20'" , "'AS7570'" , "'AS7570'" , "'192.231.212.5/32'" , "'AS786'" , "'AS1853'" , "'AS1853'" , "'AS8447'" , "'AS8447'" , "'AS9264'" , "'AS9264'" Cc: <6bone@mailman.isi.edu>, , Subject: Awareness of breaking RFC3056 with 6to4 more specifics Date: Fri, 12 Sep 2003 13:57:06 +0200 Organization: Unfix Message-ID: <003101c37924$fd930480$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.4 required=5.0 tests=PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hi, Are the ones in the To line aware that you are breaking RFC3056 by announcing 6to4 more specifics? RFC3056 Section 5.2 point 3: 8<------------ 6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing table by elements of the IPv4 routing table. Therefore, a 6to4 site which also has a native IPv6 connection MUST NOT advertise its 2002::/48 routing prefix on that connection, and all native IPv6 network operators MUST filter out and discard any 2002:: routing prefix advertisements longer than /16. - ------------>8 Currently you are announcing, to the rest of the world: http://www.sixxs.net/tools/grh/lg/?find=3D2002::/16 2002:8c6d:106::/48 8447 1853 786 5623 6939 11537 9264 2002:8c6d:106::/48 12779 3549 6939 11537 9264 2002:8c6d:106::/48 6939 11537 9264 2002:c058:6301::/48 8447 1853 786 2002:c0e7:d405::/48 8447 1853 6680 1103 11537 7570 2002:c0e7:d405::/48 1103 11537 7570 2002:c0e7:d405::/48 12779 3549 6939 11537 7570 2002:c0e7:d405::/48 6939 11537 7570 2002:c8a2::/33 8447 1853 6680 1103 11537 6939 6939 15180 2002:c8a2::/33 12337 12337 12337 6939 6939 15180 2002:c8a2::/33 1103 11537 6939 6939 15180 2002:c8a2::/33 12779 3549 6939 6939 15180 2002:c8a2::/33 6939 6939 15180 2002:c8c6:4000::/34 8447 1853 6680 1103 11537 6939 6939 15180 2002:c8c6:4000::/34 12337 12337 12337 6939 6939 15180 2002:c8c6:4000::/34 1103 11537 6939 6939 15180 2002:c8c6:4000::/34 12779 3549 6939 6939 15180 2002:c8c6:4000::/34 6939 6939 15180 2002:c8ca:7000::/36 8447 1853 6680 1103 11537 6939 6939 15180 2002:c8ca:7000::/36 1103 11537 6939 6939 15180 2002:c8ca:7000::/36 12779 3549 6939 6939 15180 2002:c8ca:7000::/36 6939 6939 15180 Summing them up: 2002:8c6d:106::/48 140.109.1.6/32 AS9264 2002:c058:6301::/48 192.88.99.1/32 AS786 2002:c0e7:d405::/48 192.231.212.5/32 AS7570 2002:c8a2::/33 200.162.0.0/17 AS15180 2002:c8c6:4000::/34 200.198.64.0/18 AS15180 2002:c8ca:7000::/36 200.202.112.0/20 AS15180 NOTEZ BIEN: % Not assigned. Free in Brazilian block: 200.198.64.0/18 Is LACNIC the RIR or is NIC.BR the one? Seeing that a complete IPv4 /9 has been carved up to them and LACNIC doesn't handle anything else? 192.88.99.1/32 is *THE* anycast address, it is *NOT* routable.... And you don't own it either, please read RFC3068 and stop that foolish announcement. In whois.ripe.net this network is documented: route: 192.88.99.0/24 descr: RFC3068-ECIX origin: AS9033 mnt-by: ECIX-MNT mnt-routes: RFC3068-MNT changed: czmok@gatel.de 20030711 source: RIPE remarks: See RFC 3068 remarks: "An Anycast Prefix for 6to4 Relay Routers" remarks: Christian Huitema remarks: June 2001 Feel free to notify your "upstreams" that they should be filtering anything more specific in 2002::/16 and should probably not be announcing cross-RIR prefixes unaggregated. Please read: IPv6 Filter Recommendations by Gert D=F6ring http://www.space.net/~gert/RIPE/ipv6-filters.html Minimal IPv6 Peering by Robert Kie=DFling=20 http://ip6.de.easynet.net/ipv6-minimum-peering.txt Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2G0kSmqKFIzPnwjEQJi4wCgkfxKSBKl/zzvPBGyFTQp3Bjx9CIAoJAO caSxGRfOBcF0VQ1G15QvNjaP =3DkO2/ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Sep 12 08:15:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18597 for ; Fri, 12 Sep 2003 08:15:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xmmk-000ADl-32 for v6ops-data@psg.com; Fri, 12 Sep 2003 12:12:22 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19xmmE-000ACG-5o for v6ops@ops.ietf.org; Fri, 12 Sep 2003 12:11:50 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 6DFE42A3E6; Fri, 12 Sep 2003 14:11:49 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 6252D2A3E4; Fri, 12 Sep 2003 14:11:49 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 4514415A6D; Fri, 12 Sep 2003 08:11:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 4272915A6C; Fri, 12 Sep 2003 14:11:49 +0200 (CEST) Date: Fri, 12 Sep 2003 14:11:49 +0200 (CEST) From: Mauro Tortonesi To: Iljitsch van Beijnum Cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Iljitsch van Beijnum wrote: > On vrijdag, sep 12, 2003, at 11:33 Europe/Amsterdam, Mauro Tortonesi > wrote: > > > then my credo as a developer is "ipv6 is a brand new protocol", because > > AF_INET6 sockets have many options that are not applicable to ipv4 > > connections, and writing applications that make use of the ipv4-mapped > > catch-all approach will be a great problem for developers (that will > > find > > themselves writing __a lot__ of checks/workarounds for special cases > > and > > will become crazy during the testing/debugging process). > > So what's the alternative? Ripping mapped addresses out of current > implementations doesn't make sense for many reasons. sure, but we could deprecate usage of ipv4-mapped addresses. > The only question is whether you should/want to use them. If you want > to do stuff with IPv6 that you can't do with IPv4, you'll have to do a > lot of checking regardless of how you do it. yes, but they're always less than the checks you would do if you were also supporting ipv4-mapped addresses. > If you feel using the IPv6 socket API for IPv6 and the IPv4 socket API > for IPv4 makes more sense, then by all means, do it that way. But for > simple applications I think it's a huge plus to be able to talk to the > network in a unified way without having to spend time and effort on > making the IPv4/IPv6 distinction. Obviously this means you can't do any > IPv6-specific stuff. this could be a plus only for for very simple apps where the developers don't care for portability or robustness. > > moreover, i think that the ipv4-mapped catch-all approach in the > > development of ipv6-enabled apps may eventually become an obstacle for > > widespread adoption of production quality ipv6-enabled software (since > > it > > makes more difficult the use of the advanced ipv6 capabilities) > > I don't agree. Just tell the stack you don't want to talk IPv4. not all the stacks support IPv6_V6ONLY, yet. > Also, in the document I read it seems half or more of the trouble comes > from mixing IPv4 and IPv6 calls. So don't do that. actually, this is not true. in fact, half or more of the trouble comes from the fact that nearly every stack has a different bind(2) behaviour. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Fri Sep 12 08:49:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19331 for ; Fri, 12 Sep 2003 08:49:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xnHq-000Clc-P1 for v6ops-data@psg.com; Fri, 12 Sep 2003 12:44:30 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19xnG3-000Cel-Ch for v6ops@ops.ietf.org; Fri, 12 Sep 2003 12:42:39 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 87A5E2A3E6; Fri, 12 Sep 2003 14:42:38 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 1C2252A3E4; Fri, 12 Sep 2003 14:42:38 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 150D515A6D; Fri, 12 Sep 2003 08:42:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 126B715A6C; Fri, 12 Sep 2003 14:42:38 +0200 (CEST) Date: Fri, 12 Sep 2003 14:42:38 +0200 (CEST) From: Mauro Tortonesi To: Juergen Schoenwaelder Cc: Iljitsch van Beijnum , v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <20030912114822.GB710@iu-bremen.de> Message-ID: References: <20030912114822.GB710@iu-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Juergen Schoenwaelder wrote: > On Fri, Sep 12, 2003 at 01:19:08PM +0200, Iljitsch van Beijnum wrote: > > > But for simple applications I think it's a huge plus to be able to talk > > to the network in a unified way without having to spend time and effort > > on making the IPv4/IPv6 distinction. > > I do not know where you make the distinction between a simple > application and a complex one. My experience is that the behaviour > of mapped addresses seems to be different from box to box and the > real pain I had was _portability_ and not the complexity of the > application. And this portability pain was in my case much bigger > than writing proper code that can handle IPv4/IPv6 addresses > natively. yes. please take a look at my oftpd ipv6 port: http://cvs.deepspace6.net/view/oftpd/ especially src/ftp_listener.c and src/af_portability.c. i think that at the moment this is the only way to properly handle ipv4_mapped addresses (and, in general, both ipv6 and ipv4 connectivity) on both systems with IPv6_V6ONLY support and systems with no IPv6_V6ONLY support. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Fri Sep 12 09:16:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19897 for ; Fri, 12 Sep 2003 09:16:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xnk1-000Eyf-OS for v6ops-data@psg.com; Fri, 12 Sep 2003 13:13:37 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19xnjW-000EvW-1R for v6ops@ops.ietf.org; Fri, 12 Sep 2003 13:13:06 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h8CDCuR14357; Fri, 12 Sep 2003 15:12:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h8CDB1HN094900; Fri, 12 Sep 2003 15:11:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309121311.h8CDB1HN094900@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Mauro Tortonesi , v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-reply-to: Your message of Fri, 12 Sep 2003 11:34:07 +0300. Date: Fri, 12 Sep 2003 15:11:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_10,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: Francis, could you clarify how your local credo translates to how you'd like to, for example, port applications to IPv6? => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(), gethostbyaddr() by getnameinfo(), etc. I use one socket at the server side because I consider there is only one IP, in the API it becomes IPv6 with IPv4 space injected (in the math meaning) into the IPv6 space as IPv4-mapped IPv6 addresses. We're in the process of updating draft-shin-v6ops-application-transition-02.txt, and it seems like there are about half a dozen (at least) ways to create IPv6 applications. => there are two ways: - consider that the two stacks are disjoined: the code is duplicated, there is a version for IPv6 and a version for IPv4. - consider that there is only one IP and use only the IPv6 representation of any IP address. The different scenarios are quite complex. Most of it seems to come from the different ways how the mapped addresses could be used. => in fact the issue is more to use or not to use them. Could you try to clarify? => there is a zillion of messages about this in the archives... Thanks Francis.Dupont@enst-bretagne.fr PS: a new idea: list a "to be v6fied application of the month" in order to get IPv6 support in all common applications... I propose to begin with OpenSSL which has no IPv6 support mainly because we didn't shout down enough louder to get it (:-). From owner-v6ops@ops.ietf.org Fri Sep 12 09:23:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20905 for ; Fri, 12 Sep 2003 09:23:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xnsD-000Fer-5R for v6ops-data@psg.com; Fri, 12 Sep 2003 13:22:05 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19xns9-000Fdq-SZ for v6ops@ops.ietf.org; Fri, 12 Sep 2003 13:22:02 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h8CDLvR15385; Fri, 12 Sep 2003 15:21:57 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h8CDK3HN095008; Fri, 12 Sep 2003 15:20:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309121320.h8CDK3HN095008@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-reply-to: Your message of Fri, 12 Sep 2003 11:33:56 +0200. Date: Fri, 12 Sep 2003 15:20:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_10,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => this is different: IPv4-mapped IPv6 addresses on the wire have far > more opponents than IPv4-mapped IPv6 addresses in the API. > For instance I am against the first and strongly in favor of the second, > i.e., I dislike SIIT and our local credo is "IPv6 is not a new protocol, > IPv6 is a new version of the Internet Protocol". instead, i think that i have far more arguments against usage of ipv4-mapped addresses on the api than on the wire (nowadays many unix oses have a very useful configuration option for dropping ipv6 packets with ipv4-mapped addresses). ... => we obviously disagree nearly as much as possible. So don't expect to reach any consensus about the two mentioned drafts... Regards Francis.Dupont@enst-bretagne.fr PS: I do *not* want to reopen the discussion about IPv4-mapped IPv6 draft. From owner-v6ops@ops.ietf.org Fri Sep 12 09:32:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21350 for ; Fri, 12 Sep 2003 09:32:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xo0h-000GSH-Q6 for v6ops-data@psg.com; Fri, 12 Sep 2003 13:30:51 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19xo0C-000GQO-4N for v6ops@ops.ietf.org; Fri, 12 Sep 2003 13:30:20 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 396B22A3ED; Fri, 12 Sep 2003 15:30:19 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 2E6132A3E8; Fri, 12 Sep 2003 15:30:19 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 36DF615A6D; Fri, 12 Sep 2003 09:30:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 33EA015A6C; Fri, 12 Sep 2003 15:30:19 +0200 (CEST) Date: Fri, 12 Sep 2003 15:30:19 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <200309121311.h8CDB1HN094900@givry.rennes.enst-bretagne.fr> Message-ID: References: <200309121311.h8CDB1HN094900@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Francis Dupont wrote: > PS: a new idea: list a "to be v6fied application of the month" in order > to get IPv6 support in all common applications... I propose to begin > with OpenSSL which has no IPv6 support mainly because we didn't shout > down enough louder to get it (:-). if you are looking for a list of IPv6-enabled apps, you can start here: http://www.deepspace6.net/docs/ipv6_status_page_apps.html -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Fri Sep 12 09:45:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21954 for ; Fri, 12 Sep 2003 09:45:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xoE2-000Hou-Hg for v6ops-data@psg.com; Fri, 12 Sep 2003 13:44:38 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19xoDq-000Ho1-KK for v6ops@ops.ietf.org; Fri, 12 Sep 2003 13:44:26 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h8CDiKR18032; Fri, 12 Sep 2003 15:44:21 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h8CDgQHN095312; Fri, 12 Sep 2003 15:42:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309121342.h8CDgQHN095312@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-reply-to: Your message of Fri, 12 Sep 2003 15:30:19 +0200. Date: Fri, 12 Sep 2003 15:42:26 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_10,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: On Fri, 12 Sep 2003, Francis Dupont wrote: > PS: a new idea: list a "to be v6fied application of the month" in order > to get IPv6 support in all common applications... I propose to begin > with OpenSSL which has no IPv6 support mainly because we didn't shout > down enough louder to get it (:-). if you are looking for a list of IPv6-enabled apps, you can start here: http://www.deepspace6.net/docs/ipv6_status_page_apps.html => no, what I am looking for is a list of not yet IPv6-enabled apps, i.e., apps which are not in your list, which have no IPv6 support but we'd like to see in your list. Regards Francis.Dupont@enst-bretagne.fr PS: I've transfered the idea to the users@ipv6.org list. From owner-v6ops@ops.ietf.org Fri Sep 12 10:29:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26121 for ; Fri, 12 Sep 2003 10:29:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xoqn-000LOY-Ef for v6ops-data@psg.com; Fri, 12 Sep 2003 14:24:41 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 19xop9-000LFP-Gl for v6ops@ops.ietf.org; Fri, 12 Sep 2003 14:22:59 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 96AF08033; Fri, 12 Sep 2003 16:22:24 +0200 (CEST) From: "Jeroen Massar" To: "'Duncan Rogerson'" Cc: <6bone@mailman.isi.edu>, , Subject: RE: [6bone] Awareness of breaking RFC3056 with 6to4 more specifics Date: Fri, 12 Sep 2003 16:22:23 +0200 Organization: Unfix Message-ID: <005301c37939$497384b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <1063375492.30895.44.camel@dixon.fizzypop.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Duncan Rogerson [mailto:d.rogerson@ukerna.ac.uk] wrote: > Jeroen, >=20 > > Are the ones in the To line aware that you are breaking RFC3056 > > by announcing 6to4 more specifics? >=20 > Thanks for bringing this to our (AS786) attention. We are=20 > aware of the RFCs, however were not aware this route was leaking. > Hopefully it is fixed now. It is indeed gone out of the tables collected by GRT. So is another anomaly I reported in private to which was carrying a private ASN in it's ASPath. And so is the one carried from ACO.Net. Thank you all for the quick responses and fixes. Only 5 prefixes to go sourced from 3 ASN's. > (btw, I don't know if it was intended, or if it was a=20 > non-native English speaker problem, but fyi, the tone of your message = was pretty=20 > offensive) That was certainly _not_ my intention. Raising awareness in these kind of 'problems', which are not really destructive, goes much better when you don't offend someone and does solve the problems. The reason for CC'ing the several lists is thus also for raising awareness, not for laughing at people in the To: line. I should have bcc'd them. This is a bigger issue as apparently many ISP's don't filter this prefix, which they should according to the RFC. Excuses if I offended anyone unintended. If you can followup in private which wordings you think where offensive I can alter them next time as indeed I am not a native english speaker, though I do try to do my best. Greets, Jeroen ps: cut off everybody except the ml's and bcc'd them now. Which I should have done in the first place actually... -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2HWnymqKFIzPnwjEQKHqACfUihmEs+SuDBXGjfa3hphxb6AhIsAn0MI TooZRIrc6QR3GCOpyxT3o7+A =3DGtFq -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Sep 12 11:55:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29203 for ; Fri, 12 Sep 2003 11:55:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xqCa-0002nM-45 for v6ops-data@psg.com; Fri, 12 Sep 2003 15:51:16 +0000 Received: from [216.4.122.6] (helo=snappydsl.net) by psg.com with esmtp (Exim 4.22) id 19xqBo-0002ik-El for v6ops@ops.ietf.org; Fri, 12 Sep 2003 15:50:28 +0000 Received: from [192.168.1.5] [64.244.108.147] by snappydsl.net with ESMTP (SMTPD32-8.01) id AB43AE0074; Fri, 12 Sep 2003 11:50:27 -0400 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.6 Date: Fri, 12 Sep 2003 11:50:27 -0400 Subject: [OT] Spam From: Eric Moore To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=0.6 required=5.0 tests=SMTPD_IN_RCVD,USER_AGENT_MACOE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Trying to figure out a better way to combat spam. It seems to be getting worse by the hour even with all the "black lists" and filters. Does IPv6 offer an iron-clad solution? If one set up a mail server that accepts incoming connections only from other IPv6 addresses using a p2p session, would this completely eliminate the issue of forged mail headers (presuming, of course, the other IPv6 mail server wasn't an 'open relay')? Can an MTA discern which IP to use from the MX record in DNS? Any other suggestions? Tnx. EM. From owner-v6ops@ops.ietf.org Fri Sep 12 12:09:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00471 for ; Fri, 12 Sep 2003 12:09:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xqTV-0004X3-Vh for v6ops-data@psg.com; Fri, 12 Sep 2003 16:08:45 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 19xqTQ-0004WS-9x for v6ops@ops.ietf.org; Fri, 12 Sep 2003 16:08:40 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4B5748033; Fri, 12 Sep 2003 18:08:04 +0200 (CEST) From: "Jeroen Massar" To: "'Eric Moore'" , Subject: RE: [OT] Spam Date: Fri, 12 Sep 2003 18:08:04 +0200 Organization: Unfix Message-ID: <007a01c37948$0c869a60$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Eric Moore wrote: > Trying to figure out a better way to combat spam. It seems=20 > to be getting worse by the hour even with all the "black lists" and=20 > filters. Does IPv6 offer an iron-clad solution? There is no difference in IPv6 versus IPv4 in that field. If you want to 'solve' "spam" one should not be using SMTP or be using a SMTP extension which can identify senders. IPSEC + IPv6 could avoid spoofing at least though. > If one set up a mail server that accepts incoming connections=20 > only from other IPv6 addresses using a p2p session, would this=20 > completely eliminate the issue of forged mail headers (presuming, of = course, the=20 > other IPv6 mail server wasn't an 'open relay')? Indeed you have to trust the other side, one could employ SMTP + TLS and require that the certificate matches. > Can an MTA discern which IP to use from the MX record in DNS? >=20 > Any other suggestions? Tnx. EM. As you marked it already OT, ask these questions in: http://www.ripe.net/ripe/wg/anti-spam/ http://www.irtf.org/charters/asrg.html Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2HvZCmqKFIzPnwjEQL5eQCfQ8oGAQ1kHxcTmLAYDCKOXsedBJ4An06I s/Ql0ykhXXf/4dJv0vVQyexb =3Dlhth -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Sep 12 13:28:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05891 for ; Fri, 12 Sep 2003 13:28:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xrcg-000AlE-Bu for v6ops-data@psg.com; Fri, 12 Sep 2003 17:22:18 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.22) id 19xrcZ-000Aik-1j for v6ops@ops.ietf.org; Fri, 12 Sep 2003 17:22:11 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8CHL9xS061939; Fri, 12 Sep 2003 19:21:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 12 Sep 2003 19:20:52 +0200 Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: v6ops@ops.ietf.org To: Mauro Tortonesi From: Iljitsch van Beijnum In-Reply-To: Message-Id: <75F4F53D-E545-11D7-A80C-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, sep 12, 2003, at 14:11 Europe/Amsterdam, Mauro Tortonesi wrote: >> So what's the alternative? Ripping mapped addresses out of current >> implementations doesn't make sense for many reasons. > sure, but we could deprecate usage of ipv4-mapped addresses. First of all, how does this make a difference in the world? Second: you don't make the case for "harmful", only for "of little use". There is no need to go through all kinds of trouble to warn people something is hard to use. >> If you feel using the IPv6 socket API for IPv6 and the IPv4 socket API >> for IPv4 makes more sense, then by all means, do it that way. But for >> simple applications I think it's a huge plus to be able to talk to the >> network in a unified way without having to spend time and effort on >> making the IPv4/IPv6 distinction. Obviously this means you can't do >> any >> IPv6-specific stuff. > this could be a plus only for for very simple apps where the developers > don't care for portability or robustness. If you want to be able to write portable applications, why don't you talk to the OS builders? From owner-v6ops@ops.ietf.org Fri Sep 12 13:43:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06504 for ; Fri, 12 Sep 2003 13:43:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xrvK-000Chj-5p for v6ops-data@psg.com; Fri, 12 Sep 2003 17:41:34 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19xrun-000CdT-OI for v6ops@ops.ietf.org; Fri, 12 Sep 2003 17:41:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8CHdja28239; Fri, 12 Sep 2003 20:39:46 +0300 Date: Fri, 12 Sep 2003 20:39:45 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Mauro Tortonesi , Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <200309121311.h8CDB1HN094900@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Francis Dupont wrote: > In your previous mail you wrote: > > Francis, could you clarify how your local credo translates to how you'd > like to, for example, port applications to IPv6? > > => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(), > gethostbyaddr() by getnameinfo(), etc. I use one socket at the > server side because I consider there is only one IP, in the API it > becomes IPv6 with IPv4 space injected (in the math meaning) into > the IPv6 space as IPv4-mapped IPv6 addresses. What about client apps -- do you set up AI_MAPPED flag when doing getaddrinfo? When you log into a dual-stack system with SSH using IPv4, would you prefer the application would print that you connected from an IPv4 address, instead of the mapped address? How about programs which make lookups based on your address (e.g. sendmail doing RBL-like checks) -- should all the applications convert the mapped addresses to IPv4 addresses? Should there be a function for it? Or should the kernel lie to the apps about it? There are other very difficult problems with mapped addresses, I've seen.. > We're in the process of updating > draft-shin-v6ops-application-transition-02.txt, and it seems like there > are about half a dozen (at least) ways to create IPv6 applications. > > => there are two ways: > - consider that the two stacks are disjoined: the code is duplicated, > there is a version for IPv6 and a version for IPv4. > - consider that there is only one IP and use only the IPv6 representation > of any IP address. I don't know whether you're talking about different ways to build dual-stack implementation, or how to build dual-stack applications. If the latter, your two ways seem to be wrong. There does not need to be any code duplication at all, using getaddrinfo loops. > The > different scenarios are quite complex. Most of it seems to come from the > different ways how the mapped addresses could be used. > > => in fact the issue is more to use or not to use them. That's correct yes, but the details of "to use them" are also a bit hairy. > Could you try to clarify? > > => there is a zillion of messages about this in the archives... .. with nothing properly written up, I guess.. :-( -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 12 16:39:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14752 for ; Fri, 12 Sep 2003 16:39:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xuYO-000Egm-GK for v6ops-data@psg.com; Fri, 12 Sep 2003 20:30:04 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 19xuYH-000Efg-1S for v6ops@ops.ietf.org; Fri, 12 Sep 2003 20:29:57 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 669A48034; Fri, 12 Sep 2003 22:29:21 +0200 (CEST) From: "Jeroen Massar" To: "'Antonio Querubin'" Cc: <6bone@mailman.isi.edu>, , Subject: RE: Awareness of breaking RFC3056 with 6to4 more specifics Date: Fri, 12 Sep 2003 22:29:18 +0200 Organization: Unfix Message-ID: <00d401c3796c$8b83ded0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Antonio Querubin [mailto:tony@lava.net] wrote: [cut off long list of people, except ml's] > On Fri, 12 Sep 2003, Jeroen Massar wrote: > > > 2002:c058:6301::/48 192.88.99.1/32 AS786 > > > 192.88.99.1/32 is *THE* anycast address, it is *NOT* routable.... > > And you don't own it either, please read RFC3068 and stop that > > foolish announcement. In whois.ripe.net this network is documented: > > Whoa there! Just because a block is anycast doesn't mean it's NOT > routable. It just means there may be multiple destinations > and multiple routes to those destinations. Otherwise what use is it? It's for making 2002::/16 reachable, not for making the IPv4 version reachable over IPv6 ;) > The RFC has specific information on restrictions for announcement if you > do want to provide the service to those outside your AS. If you where announcing 192.88.99.1/32 you would be right, though announcing a /32 is really dubieus :) They _where_ (it got fixed directly) announcing 2002:c058:6301::/48 which really doesn't make any sense. Or are you implying that anyone can just announce a block out of 192.88.99.0/24 and use it for 6to4? Announcements of 192.88.99.0/24 should also be backed up by the relevant entry in the RIPE (or ARIN/LACNIC/APNIC) databases. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2IsnSmqKFIzPnwjEQIaIgCcDM4CuLIELIht+9Gw0wsayAwXtGEAnAsQ V7X2DfgVLhXsw1MVlMgFuiIa =jun7 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Fri Sep 12 16:48:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15074 for ; Fri, 12 Sep 2003 16:48:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xums-000HLj-AN for v6ops-data@psg.com; Fri, 12 Sep 2003 20:45:02 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.22) id 19xumL-000HG1-Sq for v6ops@ops.ietf.org; Fri, 12 Sep 2003 20:44:29 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 54D089915; Fri, 12 Sep 2003 16:44:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 12 Sep 2003 16:44:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Date: Fri, 12 Sep 2003 16:44:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA021@tayexc13.americas.cpqcorp.net> Thread-Topic: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Thread-Index: AcN5J6m9MZ0L+OZOQYqdZFgqj0/PcgARgRRg From: "Bound, Jim" To: "Mauro Tortonesi" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 12 Sep 2003 20:44:29.0218 (UTC) FILETIME=[A96A3820:01C3796E] X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable We cannot deprecate usage of IPv4 Mapped Addresses for the API (not speaking of the wire) they are deployed and part of RFC 3493 and IEEE standard, and the API is widely deployed on all product platforms that require APIs. There are many uses for IPv4 Mapped Addresses and this has been documented in the Netscape Mozilla code base and now in many code bases. An application may want to treat all addresses as IPv6 including IPv4 and how to do this is documented in RFC 3493. The product and most research implementors will not deprecate IPv4 Mapped addresses because they have an important use in the industry and for specific customers and research. This has all been discussed before and in the spirit of not raising this to insanity mail list responses I will not respond further on this topic this week or maybe even next week unless I hear something new and I did not. Unless the Chairs specifically ask me to respond. Please do try to limit your messages on this mail list to 10-15 per week. Thank You. /jim > -----Original Message----- > From: Mauro Tortonesi [mailto:mtortonesi@ing.unife.it]=20 > Sent: Friday, September 12, 2003 8:12 AM > To: Iljitsch van Beijnum > Cc: v6ops@ops.ietf.org > Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt=20 > and draft-itojun-v6ops-v4mapped-harmful-01.txt=20 >=20 >=20 > On Fri, 12 Sep 2003, Iljitsch van Beijnum wrote: >=20 > > On vrijdag, sep 12, 2003, at 11:33 Europe/Amsterdam, Mauro Tortonesi > > wrote: > > > > > then my credo as a developer is "ipv6 is a brand new protocol",=20 > > > because AF_INET6 sockets have many options that are not=20 > applicable=20 > > > to ipv4 connections, and writing applications that make=20 > use of the=20 > > > ipv4-mapped catch-all approach will be a great problem for=20 > > > developers (that will find themselves writing __a lot__ of=20 > > > checks/workarounds for special cases and > > > will become crazy during the testing/debugging process). > > > > So what's the alternative? Ripping mapped addresses out of current=20 > > implementations doesn't make sense for many reasons. >=20 > sure, but we could deprecate usage of ipv4-mapped addresses. >=20 >=20 > > The only question is whether you should/want to use them.=20 > If you want=20 > > to do stuff with IPv6 that you can't do with IPv4, you'll=20 > have to do a=20 > > lot of checking regardless of how you do it. >=20 > yes, but they're always less than the checks you would do if=20 > you were also supporting ipv4-mapped addresses. >=20 >=20 > > If you feel using the IPv6 socket API for IPv6 and the IPv4=20 > socket API=20 > > for IPv4 makes more sense, then by all means, do it that=20 > way. But for=20 > > simple applications I think it's a huge plus to be able to=20 > talk to the=20 > > network in a unified way without having to spend time and effort on=20 > > making the IPv4/IPv6 distinction. Obviously this means you can't do=20 > > any IPv6-specific stuff. >=20 > this could be a plus only for for very simple apps where the=20 > developers don't care for portability or robustness. >=20 >=20 > > > moreover, i think that the ipv4-mapped catch-all approach in the=20 > > > development of ipv6-enabled apps may eventually become an=20 > obstacle=20 > > > for widespread adoption of production quality=20 > ipv6-enabled software=20 > > > (since it makes more difficult the use of the advanced ipv6=20 > > > capabilities) > > > > I don't agree. Just tell the stack you don't want to talk IPv4. >=20 > not all the stacks support IPv6_V6ONLY, yet. >=20 >=20 > > Also, in the document I read it seems half or more of the trouble=20 > > comes from mixing IPv4 and IPv6 calls. So don't do that. >=20 > actually, this is not true. in fact, half or more of the=20 > trouble comes from the fact that nearly every stack has a=20 > different bind(2) behaviour. >=20 >=20 > --=20 > Aequam memento rebus in arduis servare mentem... >=20 > Mauro Tortonesi mtortonesi@ing.unife.it > mauro@deepspace6.net > mauro@ferrara.linux.it > Deep Space 6 - IPv6 with Linux http://www.deepspace6.net > Ferrara Linux User Group http://www.ferrara.linux.it >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Fri Sep 12 17:52:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18493 for ; Fri, 12 Sep 2003 17:52:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xvlO-0002oF-QL for v6ops-data@psg.com; Fri, 12 Sep 2003 21:47:34 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.22) id 19xvki-0002e7-Ta for v6ops@ops.ietf.org; Fri, 12 Sep 2003 21:46:53 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 469228C; Sat, 13 Sep 2003 06:46:51 +0900 (JST) To: Francis.Dupont@enst-bretagne.fr Cc: pekkas@netcore.fi, mtortonesi@ing.unife.it, v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: Your message of "Fri, 12 Sep 2003 15:11:01 +0200" <200309121311.h8CDB1HN094900@givry.rennes.enst-bretagne.fr> References: <200309121311.h8CDB1HN094900@givry.rennes.enst-bretagne.fr> X-Mailer: Cue version 0.6 (030716-1832/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20030912214651.469228C@coconut.itojun.org> Date: Sat, 13 Sep 2003 06:46:51 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(), > gethostbyaddr() by getnameinfo(), etc. I use one socket at the > server side because I consider there is only one IP, in the API it > becomes IPv6 with IPv4 space injected (in the math meaning) into > the IPv6 space as IPv4-mapped IPv6 addresses. could you tell me why you don't use getaddrinfo(AI_PASSIVE) and obey the result? by doing so your application will be totally address family independent (no AF_INET6 hardcoded) and will be future-proven (will work with SCTP, DCCP or even IPv8 :-). itojun From owner-v6ops@ops.ietf.org Fri Sep 12 18:46:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21077 for ; Fri, 12 Sep 2003 18:46:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xwar-000CGW-E9 for v6ops-data@psg.com; Fri, 12 Sep 2003 22:40:45 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.22) id 19xwaL-000C98-Db for v6ops@ops.ietf.org; Fri, 12 Sep 2003 22:40:13 +0000 Received: (qmail 22332 invoked by uid 1007); 12 Sep 2003 22:40:12 -0000 Date: Sat, 13 Sep 2003 00:40:12 +0200 From: Gert Doering To: Antonio Querubin Cc: Jeroen Massar , "'AS15180'" , "'200.202.112.0/20'" , "'200.202.112.0/20'" , "'200.202.112.0/20'" , "'AS7570'" , "'AS7570'" , "'192.231.212.5/32'" , "'AS786'" , "'AS1853'" , "'AS1853'" , "'AS8447'" , "'AS8447'" , "'AS9264'" , "'AS9264'" , 6bone@mailman.isi.edu, users@ipv6.org, v6ops@ops.ietf.org Subject: Re: [6bone] Re: Awareness of breaking RFC3056 with 6to4 more specifics Message-ID: <20030913004012.F67740@Space.Net> References: <003101c37924$fd930480$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from tony@lava.net on Fri, Sep 12, 2003 at 10:15:06AM -1000 X-NCC-RegID: de.space X-Spam-Status: No, hits=-5.0 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Sep 12, 2003 at 10:15:06AM -1000, Antonio Querubin wrote: > On Fri, 12 Sep 2003, Jeroen Massar wrote: > > > 2002:c058:6301::/48 192.88.99.1/32 AS786 > > > 192.88.99.1/32 is *THE* anycast address, it is *NOT* routable.... > > And you don't own it either, please read RFC3068 and stop that > > foolish announcement. In whois.ripe.net this network is documented: > > Whoa there! Just because a block is anycast doesn't mean it's NOT > routable. Please the section of the RFC about "announcing more specifics of 2002::/16". The anycast IP address is IPv4 and MUST NOT be visible as 6to4 prefix (and besides that it doesn't make any sense). Of course it's appreciated to announce it *in the IPv4 BGP table*. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56833 (55575) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Fri Sep 12 18:57:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21383 for ; Fri, 12 Sep 2003 18:57:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xwm5-000EIp-1d for v6ops-data@psg.com; Fri, 12 Sep 2003 22:52:21 +0000 Received: from [200.153.64.2] (helo=mail.internetbrasil.net) by psg.com with smtp (Exim 4.22) id 19xwlY-000EDu-Ur for v6ops@ops.ietf.org; Fri, 12 Sep 2003 22:51:49 +0000 Received: (qmail 11032 invoked by uid 89); 12 Sep 2003 22:49:38 -0000 Received: from unknown (HELO ipv6brspw2k) (robson.oliveira@ipv6dobrasil.com.br@200.148.119.131) by 0 with SMTP; 12 Sep 2003 22:49:38 -0000 From: "Robson Oliveira" To: "Mauro Tortonesi" Cc: Subject: RE: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt Date: Fri, 12 Sep 2003 19:51:10 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA021@tayexc13.americas.cpqcorp.net> Importance: Normal X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_30,IN_REP_TO,MSGID_GOOD_EXCHANGE,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mauro, If does not have transistion, does not have ipv6 ;-| Some tasks is hard and to send some messages to IETF too. --robson -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Bound, Jim Sent: Friday, September 12, 2003 5:44 PM To: Mauro Tortonesi; Iljitsch van Beijnum Cc: v6ops@ops.ietf.org Subject: RE: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt We cannot deprecate usage of IPv4 Mapped Addresses for the API (not speaking of the wire) they are deployed and part of RFC 3493 and IEEE standard, and the API is widely deployed on all product platforms that require APIs. There are many uses for IPv4 Mapped Addresses and this has been documented in the Netscape Mozilla code base and now in many code bases. An application may want to treat all addresses as IPv6 including IPv4 and how to do this is documented in RFC 3493. The product and most research implementors will not deprecate IPv4 Mapped addresses because they have an important use in the industry and for specific customers and research. This has all been discussed before and in the spirit of not raising this to insanity mail list responses I will not respond further on this topic this week or maybe even next week unless I hear something new and I did not. Unless the Chairs specifically ask me to respond. Please do try to limit your messages on this mail list to 10-15 per week. Thank You. /jim > -----Original Message----- > From: Mauro Tortonesi [mailto:mtortonesi@ing.unife.it] > Sent: Friday, September 12, 2003 8:12 AM > To: Iljitsch van Beijnum > Cc: v6ops@ops.ietf.org > Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt > and draft-itojun-v6ops-v4mapped-harmful-01.txt > > > On Fri, 12 Sep 2003, Iljitsch van Beijnum wrote: > > > On vrijdag, sep 12, 2003, at 11:33 Europe/Amsterdam, Mauro Tortonesi > > wrote: > > > > > then my credo as a developer is "ipv6 is a brand new protocol", > > > because AF_INET6 sockets have many options that are not > applicable > > > to ipv4 connections, and writing applications that make > use of the > > > ipv4-mapped catch-all approach will be a great problem for > > > developers (that will find themselves writing __a lot__ of > > > checks/workarounds for special cases and > > > will become crazy during the testing/debugging process). > > > > So what's the alternative? Ripping mapped addresses out of current > > implementations doesn't make sense for many reasons. > > sure, but we could deprecate usage of ipv4-mapped addresses. > > > > The only question is whether you should/want to use them. > If you want > > to do stuff with IPv6 that you can't do with IPv4, you'll > have to do a > > lot of checking regardless of how you do it. > > yes, but they're always less than the checks you would do if > you were also supporting ipv4-mapped addresses. > > > > If you feel using the IPv6 socket API for IPv6 and the IPv4 > socket API > > for IPv4 makes more sense, then by all means, do it that > way. But for > > simple applications I think it's a huge plus to be able to > talk to the > > network in a unified way without having to spend time and effort on > > making the IPv4/IPv6 distinction. Obviously this means you can't do > > any IPv6-specific stuff. > > this could be a plus only for for very simple apps where the > developers don't care for portability or robustness. > > > > > moreover, i think that the ipv4-mapped catch-all approach in the > > > development of ipv6-enabled apps may eventually become an > obstacle > > > for widespread adoption of production quality > ipv6-enabled software > > > (since it makes more difficult the use of the advanced ipv6 > > > capabilities) > > > > I don't agree. Just tell the stack you don't want to talk IPv4. > > not all the stacks support IPv6_V6ONLY, yet. > > > > Also, in the document I read it seems half or more of the trouble > > comes from mixing IPv4 and IPv6 calls. So don't do that. > > actually, this is not true. in fact, half or more of the > trouble comes from the fact that nearly every stack has a > different bind(2) behaviour. > > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mtortonesi@ing.unife.it > mauro@deepspace6.net > mauro@ferrara.linux.it > Deep Space 6 - IPv6 with Linux http://www.deepspace6.net > Ferrara Linux User Group http://www.ferrara.linux.it > > > From owner-v6ops@ops.ietf.org Sat Sep 13 12:46:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22591 for ; Sat, 13 Sep 2003 12:46:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yDOG-000Of1-6q for v6ops-data@psg.com; Sat, 13 Sep 2003 16:36:52 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19yDNk-000OYm-66 for v6ops@ops.ietf.org; Sat, 13 Sep 2003 16:36:20 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h8DGaEP27509; Sat, 13 Sep 2003 18:36:14 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h8DGYCHN001020; Sat, 13 Sep 2003 18:34:12 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309131634.h8DGYCHN001020@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Mauro Tortonesi , v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-reply-to: Your message of Fri, 12 Sep 2003 20:39:45 +0300. Date: Sat, 13 Sep 2003 18:34:12 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_01,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: On Fri, 12 Sep 2003, Francis Dupont wrote: > In your previous mail you wrote: > > Francis, could you clarify how your local credo translates to how you'd > like to, for example, port applications to IPv6? > > => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(), > gethostbyaddr() by getnameinfo(), etc. I use one socket at the > server side because I consider there is only one IP, in the API it > becomes IPv6 with IPv4 space injected (in the math meaning) into > the IPv6 space as IPv4-mapped IPv6 addresses. What about client apps -- do you set up AI_MAPPED flag when doing getaddrinfo? => AI_MAPPED? I believe you mean AI_V4MAPPED, it doesn't really matter for a client, i.e., you can use AF_UNSPEC or AI_V4MAPPED|AI_ALL. The important flag is AI_ADDRCONFIG (we have some IPv6 only boxes here). I still don't want to reopen this endless discussion, so I don't answer to the rest of the message in the list. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sat Sep 13 12:48:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22641 for ; Sat, 13 Sep 2003 12:48:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yDWR-0000Ap-Vz for v6ops-data@psg.com; Sat, 13 Sep 2003 16:45:19 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.22) id 19yDVv-00004C-W9 for v6ops@ops.ietf.org; Sat, 13 Sep 2003 16:44:48 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h8DGihP27747; Sat, 13 Sep 2003 18:44:43 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h8DGgfHN001180; Sat, 13 Sep 2003 18:42:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200309131642.h8DGgfHN001180@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@itojun.org (Jun-ichiro itojun Hagino) cc: pekkas@netcore.fi, mtortonesi@ing.unife.it, v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-reply-to: Your message of Sat, 13 Sep 2003 06:46:51 +0900. <20030912214651.469228C@coconut.itojun.org> Date: Sat, 13 Sep 2003 18:42:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(), > gethostbyaddr() by getnameinfo(), etc. I use one socket at the > server side because I consider there is only one IP, in the API it > becomes IPv6 with IPv4 space injected (in the math meaning) into > the IPv6 space as IPv4-mapped IPv6 addresses. could you tell me why you don't use getaddrinfo(AI_PASSIVE) and obey the result? by doing so your application will be totally address family independent (no AF_INET6 hardcoded) and will be future-proven (will work with SCTP, DCCP or even IPv8 :-). => you already know the answer: because I'd like to listen on only a socket. And this is address family independent (getaddrinfo is not defined for AF_ISO for instance) and transport protocol independent (it works with SCTP). This is my last message about this topic. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sun Sep 14 04:54:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24581 for ; Sun, 14 Sep 2003 04:54:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ySU2-0006Qr-01 for v6ops-data@psg.com; Sun, 14 Sep 2003 08:43:50 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 19ySTv-0006Pj-UN for v6ops@ops.ietf.org; Sun, 14 Sep 2003 08:43:44 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id CB7DE8034; Sun, 14 Sep 2003 10:43:10 +0200 (CEST) From: "Jeroen Massar" To: "'Antonio Querubin'" Cc: <6bone@mailman.isi.edu>, , Subject: RE: Awareness of breaking RFC3056 with 6to4 more specifics Date: Sun, 14 Sep 2003 10:43:12 +0200 Organization: Unfix Message-ID: <002001c37a9c$3bbe4d00$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Antonio Querubin wrote: > On Fri, 12 Sep 2003, Jeroen Massar wrote: > > > Antonio Querubin [mailto:tony@lava.net] wrote: > > > > [cut off long list of people, except ml's] > > > > > On Fri, 12 Sep 2003, Jeroen Massar wrote: > > > > > > > 2002:c058:6301::/48 192.88.99.1/32 AS786 > > > > > > > 192.88.99.1/32 is *THE* anycast address, it is *NOT* routable.... > > > > And you don't own it either, please read RFC3068 and stop that > > > > foolish announcement. In whois.ripe.net this network is documented: > > > > > > Whoa there! Just because a block is anycast doesn't mean it's NOT > > > routable. It just means there may be multiple destinations > > > and multiple routes to those destinations. Otherwise what use is it? > > > > It's for making 2002::/16 reachable, not for making the IPv4 version > > reachable over IPv6 ;) > > Oops. I thought you were advocating that 192.88.99.0 should never be > announced. Sorry for the misunderstanding :) Au contraire mon ami :) I would rather see more and more ISP's deploy anycast capable 6to4 relays. They should then at least put the route into their IGP so that clients employing 6to4 have a fast way out. It would also mean that the ISP itself has some IPv6 deployment and could be looking into native connectivity to the rest of the world, both being a good thing. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2QqHymqKFIzPnwjEQI4BgCeJqWbLHPX1IcaXUeL5qVP/MeCZlEAn2O3 26bfTL2i4mt5w8HSTx+ImodK =I0+Z -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Sep 14 04:54:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24597 for ; Sun, 14 Sep 2003 04:54:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ySSO-00066u-Rc for v6ops-data@psg.com; Sun, 14 Sep 2003 08:42:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19ySSI-00065X-E3 for v6ops@ops.ietf.org; Sun, 14 Sep 2003 08:42:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8E8eVY18671; Sun, 14 Sep 2003 11:40:31 +0300 Date: Sun, 14 Sep 2003 11:40:30 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Mauro Tortonesi , Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <200309131634.h8DGYCHN001020@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 13 Sep 2003, Francis Dupont wrote: > In your previous mail you wrote: > On Fri, 12 Sep 2003, Francis Dupont wrote: > > In your previous mail you wrote: > > > > Francis, could you clarify how your local credo translates to how you'd > > like to, for example, port applications to IPv6? > > > > => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(), > > gethostbyaddr() by getnameinfo(), etc. I use one socket at the > > server side because I consider there is only one IP, in the API it > > becomes IPv6 with IPv4 space injected (in the math meaning) into > > the IPv6 space as IPv4-mapped IPv6 addresses. > > What about client apps -- do you set up AI_MAPPED flag when doing > getaddrinfo? > > => AI_MAPPED? I believe you mean AI_V4MAPPED, it doesn't really matter > for a client, i.e., you can use AF_UNSPEC or AI_V4MAPPED|AI_ALL. > The important flag is AI_ADDRCONFIG (we have some IPv6 only boxes here). AI_ADDRCONFIG could be useful, I guess, if it was properly defined and implemented. > I still don't want to reopen this endless discussion, so I don't answer > to the rest of the message in the list. Well, then don't open the "mapped addresses or not" discussion, but I at least would like to hear how the applications which previously assumed IPv4 addresses and do things with them (consider sendmail and RBL+) see the mapped addresses.. and how you propose to fix (or document) that. The discussion will have to be had anyway. As it stands the application transition document is *NOT* going to revisit the "deprecate" vs "not-deprecate" the mapped addresses discussion. However, it aims to give guindance how to implement the application transition with or without mapped addresses (as the app writer sees best) the best way possible (the best way with mapped addresses is still unclear, I think!). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 15 04:52:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18129 for ; Mon, 15 Sep 2003 04:52:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yow2-000Nmu-7w for v6ops-data@psg.com; Mon, 15 Sep 2003 08:42:14 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19youc-000NS5-TP for v6ops@ops.ietf.org; Mon, 15 Sep 2003 08:40:47 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id CB4BB29536; Mon, 15 Sep 2003 10:40:43 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 65E7C29265; Mon, 15 Sep 2003 10:40:43 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 73E7223B86; Mon, 15 Sep 2003 04:40:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 6A58D23B82; Mon, 15 Sep 2003 10:40:43 +0200 (CEST) Date: Mon, 15 Sep 2003 10:40:43 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <200309121342.h8CDgQHN095312@givry.rennes.enst-bretagne.fr> Message-ID: References: <200309121342.h8CDgQHN095312@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Francis Dupont wrote: > => no, what I am looking for is a list of not yet IPv6-enabled apps, > i.e., apps which are not in your list, which have no IPv6 support > but we'd like to see in your list. i had understood correctly what you were looking. however, i think that a list of already IPv6-enabled apps could be of some help in the compilation of your list of not IPv6-enabled apps. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Mon Sep 15 04:55:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18232 for ; Mon, 15 Sep 2003 04:55:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yp5d-000Pow-1c for v6ops-data@psg.com; Mon, 15 Sep 2003 08:52:09 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19yp5K-000PkD-GF for v6ops@ops.ietf.org; Mon, 15 Sep 2003 08:51:50 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 50A2E2A334; Mon, 15 Sep 2003 10:51:49 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 181112A03E; Mon, 15 Sep 2003 10:51:49 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 2838822EED; Mon, 15 Sep 2003 04:51:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 25759224F2; Mon, 15 Sep 2003 10:51:49 +0200 (CEST) Date: Mon, 15 Sep 2003 10:51:49 +0200 (CEST) From: Mauro Tortonesi To: Iljitsch van Beijnum Cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <75F4F53D-E545-11D7-A80C-00039388672E@muada.com> Message-ID: References: <75F4F53D-E545-11D7-A80C-00039388672E@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Iljitsch van Beijnum wrote: > On vrijdag, sep 12, 2003, at 14:11 Europe/Amsterdam, Mauro Tortonesi > wrote: > > >> So what's the alternative? Ripping mapped addresses out of current > >> implementations doesn't make sense for many reasons. > > > sure, but we could deprecate usage of ipv4-mapped addresses. > > First of all, how does this make a difference in the world? believe it or not, there are plenty of developers out there who are trying to port apps to ipv6 in the correct way. this could be a very important message for them. > Second: you don't make the case for "harmful", only for "of little > use". There is no need to go through all kinds of trouble to warn > people something is hard to use. __complete__ breaking of portability and decuplicated code complexity are very harmful, IMVHO. especially if you're trying to push the early adoption of ipv6 by the vendors. > >> If you feel using the IPv6 socket API for IPv6 and the IPv4 socket API > >> for IPv4 makes more sense, then by all means, do it that way. But for > >> simple applications I think it's a huge plus to be able to talk to the > >> network in a unified way without having to spend time and effort on > >> making the IPv4/IPv6 distinction. Obviously this means you can't do > >> any > >> IPv6-specific stuff. > > > this could be a plus only for for very simple apps where the developers > > don't care for portability or robustness. > > If you want to be able to write portable applications, why don't you > talk to the OS builders? because this is not an os builders' fault. it's the IETF specification of IPv4-mapped addresses which is ambiguous. this said, i cannot but strongly recommend the adoption of (at least one of) the solutions proposed by draft-cmetz-v6ops-v4mapped-api-harmful-00.txt, section 2 and 3. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Mon Sep 15 05:04:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18552 for ; Mon, 15 Sep 2003 05:04:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ypG2-0002BI-RT for v6ops-data@psg.com; Mon, 15 Sep 2003 09:02:54 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19ypFW-00025r-Om for v6ops@ops.ietf.org; Mon, 15 Sep 2003 09:02:22 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id C8A182A334; Mon, 15 Sep 2003 11:02:21 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id A00812429F; Mon, 15 Sep 2003 11:02:21 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id A49486761; Mon, 15 Sep 2003 05:02:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id A1F3B430; Mon, 15 Sep 2003 11:02:21 +0200 (CEST) Date: Mon, 15 Sep 2003 11:02:21 +0200 (CEST) From: Mauro Tortonesi To: "Bound, Jim" Cc: v6ops@ops.ietf.org Subject: RE: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA021@tayexc13.americas.cpqcorp.net> Message-ID: References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA021@tayexc13.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Bound, Jim wrote: > This has all been discussed before and in the spirit of not raising this > to insanity mail list responses I will not respond further on this topic > this week or maybe even next week unless I hear something new and I did > not. Unless the Chairs specifically ask me to respond. you are free to do what you want. > Please do try to limit your messages on this mail list to 10-15 per > week. Thank You. i am afraid you are not in the condition to ask me or any other person to stop posting on this list. you are not my employer, you are not one of the chairs and you are not even my father or my mother. and i am not jim fleming, after all. i am only trying to give my contribute to the discussion on this list by reporting my experience as an ipv6-enabled app developer and by supporting itojun's and craig metz's point of view. so what makes you think you have the right to shut me up? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Mon Sep 15 05:05:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18592 for ; Mon, 15 Sep 2003 05:05:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ypHK-0002T2-Uv for v6ops-data@psg.com; Mon, 15 Sep 2003 09:04:14 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19ypH1-0002Ol-DY for v6ops@ops.ietf.org; Mon, 15 Sep 2003 09:03:55 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 841D82A334; Mon, 15 Sep 2003 11:03:54 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 20C0F61B8; Mon, 15 Sep 2003 11:03:54 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 20B6A6761; Mon, 15 Sep 2003 05:03:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 1F9A9430; Mon, 15 Sep 2003 11:03:54 +0200 (CEST) Date: Mon, 15 Sep 2003 11:03:54 +0200 (CEST) From: Mauro Tortonesi To: Robson Oliveira Cc: v6ops@ops.ietf.org Subject: RE: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Robson Oliveira wrote: > Mauro, > > If does not have transistion, does not have ipv6 ;-| believe it or not, this is clear to me. > Some tasks is hard and to send some messages to IETF too. i am afraid i don't understand what you want to say here. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Mon Sep 15 05:29:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19660 for ; Mon, 15 Sep 2003 05:29:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ypdx-0007Od-Se for v6ops-data@psg.com; Mon, 15 Sep 2003 09:27:37 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19ypdB-0007EE-RZ for v6ops@ops.ietf.org; Mon, 15 Sep 2003 09:26:50 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id CF6C42953B; Mon, 15 Sep 2003 11:26:48 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id BC37261B8; Mon, 15 Sep 2003 11:26:48 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id B12356761; Mon, 15 Sep 2003 05:26:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id AE5DC430; Mon, 15 Sep 2003 11:26:48 +0200 (CEST) Date: Mon, 15 Sep 2003 11:26:48 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <200309131642.h8DGgfHN001180@givry.rennes.enst-bretagne.fr> Message-ID: References: <200309131642.h8DGgfHN001180@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 13 Sep 2003, Francis Dupont wrote: > In your previous mail you wrote: > > could you tell me why you don't use getaddrinfo(AI_PASSIVE) and obey > the result? by doing so your application will be totally address > family independent (no AF_INET6 hardcoded) and will be future-proven > (will work with SCTP, DCCP or even IPv8 :-). > > => you already know the answer: because I'd like to listen on only a socket. > And this is address family independent (getaddrinfo is not defined for > AF_ISO for instance) and transport protocol independent (it works with > SCTP). i don't think that your approach is really address family independent. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Mon Sep 15 05:57:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20773 for ; Mon, 15 Sep 2003 05:57:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yq2D-000CPU-VD for v6ops-data@psg.com; Mon, 15 Sep 2003 09:52:41 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19yq1h-000CHy-Ll for v6ops@ops.ietf.org; Mon, 15 Sep 2003 09:52:09 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 8B2692A332; Mon, 15 Sep 2003 11:52:08 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id CD8B72953C; Mon, 15 Sep 2003 11:52:06 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id D3EE1676C; Mon, 15 Sep 2003 05:52:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id D110D676A; Mon, 15 Sep 2003 11:52:06 +0200 (CEST) Date: Mon, 15 Sep 2003 11:52:06 +0200 (CEST) From: Mauro Tortonesi To: Pekka Savola Cc: v6ops@ops.ietf.org, YOSHIFUJI Hideaki Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 14 Sep 2003, Pekka Savola wrote: > On Sat, 13 Sep 2003, Francis Dupont wrote: > > In your previous mail you wrote: > > On Fri, 12 Sep 2003, Francis Dupont wrote: > > > In your previous mail you wrote: > > > > > > Francis, could you clarify how your local credo translates to how you'd > > > like to, for example, port applications to IPv6? > > > > > > => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(), > > > gethostbyaddr() by getnameinfo(), etc. I use one socket at the > > > server side because I consider there is only one IP, in the API it > > > becomes IPv6 with IPv4 space injected (in the math meaning) into > > > the IPv6 space as IPv4-mapped IPv6 addresses. > > > > What about client apps -- do you set up AI_MAPPED flag when doing > > getaddrinfo? > > > > => AI_MAPPED? I believe you mean AI_V4MAPPED, it doesn't really matter > > for a client, i.e., you can use AF_UNSPEC or AI_V4MAPPED|AI_ALL. > > The important flag is AI_ADDRCONFIG (we have some IPv6 only boxes here). > > AI_ADDRCONFIG could be useful, I guess, if it was properly defined and > implemented. this is a very interesting topic, IMHO. to support AI_ADDRCONFIG, USAGI project's libinet6 simply checks if the system supports ipv4 or ipv6 by trying to create an AF_INET or AF_INET6 datagram socket. this is wrong, IMVHO, as the resolver should test for ipv4 or ipv6 connectivity (e.g. by looking at the routing table) and not for ipv4 or ipv6 support in the stack. i don't know what's kame behaviour, but from what i've seen in: http://orange.kame.net/dev/cvsweb.cgi/kame/kame/lib/libinet6/Attic/getaddrinfo.c?rev=1.2 it seems the KAME project's libinet6 does not support AI_ADDRCONFIG. itojun, am i wrong? BTW: i have included in cc YOSHIFUJI Hideaki, which is one of the core developers of the USAGI project, as i think that this discussion could be of some interest for him. > > I still don't want to reopen this endless discussion, so I don't answer > > to the rest of the message in the list. > > Well, then don't open the "mapped addresses or not" discussion, but I at > least would like to hear how the applications which previously assumed > IPv4 addresses and do things with them (consider sendmail and RBL+) see > the mapped addresses.. and how you propose to fix (or document) that. > > The discussion will have to be had anyway. As it stands the application > transition document is *NOT* going to revisit the "deprecate" vs > "not-deprecate" the mapped addresses discussion. However, it aims to give > guindance how to implement the application transition with or without > mapped addresses (as the app writer sees best) the best way possible (the > best way with mapped addresses is still unclear, I think!). i am very interested in producing a specification for a "best practice" approach to handle ipv4-mapped addresses. maybe it would be nice to include it in draft-shin. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Mon Sep 15 06:12:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21238 for ; Mon, 15 Sep 2003 06:12:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yqK3-000GCY-P6 for v6ops-data@psg.com; Mon, 15 Sep 2003 10:11:07 +0000 Received: from [203.178.139.94] (helo=yue.hongo.wide.ad.jp) by psg.com with esmtp (Exim 4.22) id 19yqJI-000G2C-88 for v6ops@ops.ietf.org; Mon, 15 Sep 2003 10:10:20 +0000 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.4) with ESMTP id h8FAAtfW023558; Mon, 15 Sep 2003 19:10:55 +0900 Date: Mon, 15 Sep 2003 19:10:54 +0900 (JST) Message-Id: <20030915.191054.38544617.yoshfuji@linux-ipv6.org> To: mtortonesi@ing.unife.it Cc: pekkas@netcore.fi, v6ops@ops.ietf.org, yoshfuji@linux-ipv6.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello. In article (at Mon, 15 Sep 2003 11:52:06 +0200 (CEST)), Mauro Tortonesi says: > to support AI_ADDRCONFIG, USAGI project's libinet6 simply checks if the > system supports ipv4 or ipv6 by trying to create an AF_INET or AF_INET6 > datagram socket. this is wrong, IMVHO, as the resolver should test for > ipv4 or ipv6 connectivity (e.g. by looking at the routing table) and not > for ipv4 or ipv6 support in the stack. We never look into routing table, but addresses. Well, the method to check non-link-local addresses are available may be wrong. I evetually chenge it to try to explore whole addresses on the node using rtnetlink ("routing socket" in BSD term). > i don't know what's kame behaviour, but from what i've seen in: > > http://orange.kame.net/dev/cvsweb.cgi/kame/kame/lib/libinet6/Attic/getaddrinfo.c?rev=1.2 > > it seems the KAME project's libinet6 does not support AI_ADDRCONFIG. > itojun, am i wrong? KAME supports AI_ADDRCONFIG (and USAGI's idea is from KAME's here). http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/libinet6/getaddrinfo.c BTW, I'm not against IPv4-mapped addresses. :-) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-v6ops@ops.ietf.org Mon Sep 15 06:27:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21531 for ; Mon, 15 Sep 2003 06:27:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yqZI-000JIJ-Qi for v6ops-data@psg.com; Mon, 15 Sep 2003 10:26:52 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19yqZD-000JHK-4s for v6ops@ops.ietf.org; Mon, 15 Sep 2003 10:26:47 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 3BD692A45D; Mon, 15 Sep 2003 12:26:46 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id 2FE7E25D1F; Mon, 15 Sep 2003 12:26:46 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 2AF68676A; Mon, 15 Sep 2003 06:26:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 283BC6761; Mon, 15 Sep 2003 12:26:46 +0200 (CEST) Date: Mon, 15 Sep 2003 12:26:46 +0200 (CEST) From: Mauro Tortonesi To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: pekkas@netcore.fi, v6ops@ops.ietf.org Subject: Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt In-Reply-To: <20030915.191054.38544617.yoshfuji@linux-ipv6.org> Message-ID: References: <20030915.191054.38544617.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 15 Sep 2003, YOSHIFUJI Hideaki / [iso-2022-jp] =B5=C8=C6=A3=B1=D1= =CC=C0 wrote: > Hello. > > In article (at M= on, 15 Sep 2003 11:52:06 +0200 (CEST)), Mauro Tortonesi says: > > > to support AI_ADDRCONFIG, USAGI project's libinet6 simply checks if the > > system supports ipv4 or ipv6 by trying to create an AF_INET or AF_INET6 > > datagram socket. this is wrong, IMVHO, as the resolver should test for > > ipv4 or ipv6 connectivity (e.g. by looking at the routing table) and no= t > > for ipv4 or ipv6 support in the stack. > > We never look into routing table, but addresses. > Well, the method to check non-link-local addresses are > available may be wrong. > I evetually chenge it to try to explore whole addresses > on the node using rtnetlink ("routing socket" in BSD term). why don't you check the routing table? > > i don't know what's kame behaviour, but from what i've seen in: > > > > http://orange.kame.net/dev/cvsweb.cgi/kame/kame/lib/libinet6/Attic/geta= ddrinfo.c?rev=3D1.2 > > > > it seems the KAME project's libinet6 does not support AI_ADDRCONFIG. > > itojun, am i wrong? > > KAME supports AI_ADDRCONFIG (and USAGI's idea is from KAME's here). > http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/libinet6/getaddrinfo= =2Ec thanks, it seems that i was looking in the wrong place. > BTW, I'm not against IPv4-mapped addresses. :-) tu quoque, brute... ;-) --=20 Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Mon Sep 15 06:32:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21669 for ; Mon, 15 Sep 2003 06:32:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yqdv-000KIL-Th for v6ops-data@psg.com; Mon, 15 Sep 2003 10:31:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19yqcB-000Js7-Ch for v6ops@ops.ietf.org; Mon, 15 Sep 2003 10:29:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8FASlk28679 for ; Mon, 15 Sep 2003 13:28:48 +0300 Date: Mon, 15 Sep 2003 13:28:47 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Mapped address discussion [RE: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA021@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, Excuse me for trying to keep the discussion from getting out of hand.. Please keep in mind that we should not re-open the old "deprecate mapped addresses or not" -discussion here _especially_ unless we have some significant new information, or specific proposals. Otherwise, it's likely that the mailing list would just be swamped for a couple of weeks, nothing would get written up, everybody who preferred one solution would still prefer that, and everybody else who would want otherwise would be equally unmoved -- and no one would be wiser as the end result. For example, discussion on how to make the mapped addresses work well is OK, but please change the subject title accordingly. This subject title sound be discontinued for now. Writing as WG co-chair, Pekka > This has all been discussed before and > in the spirit of not raising this to insanity mail list responses I will > not respond further on this topic this week or maybe even next week > unless I hear something new and I did not. Unless the Chairs > specifically ask me to respond. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 15 14:40:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18356 for ; Mon, 15 Sep 2003 14:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yy8r-0008aD-6i for v6ops-data@psg.com; Mon, 15 Sep 2003 18:32:05 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19yy7x-0008O8-LR for v6ops@ops.ietf.org; Mon, 15 Sep 2003 18:31:09 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8FIUqn03972; Mon, 15 Sep 2003 11:30:52 -0700 X-mProtect: <200309151830> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMfIHTm; Mon, 15 Sep 2003 11:30:51 PDT Message-ID: <3F6605DE.5070708@iprg.nokia.com> Date: Mon, 15 Sep 2003 11:33:02 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bilajbegovic Damir CC: v6ops@ops.ietf.org Subject: Re: Numbers of NAT-s in IPv4/IPv6 Network? One or more? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is an interesting question, and I'm certainly no expert on the subject. But, in theory, couldn't there be more than one NAT if, e.g., the (multiple) NAT boxes communicated out-of-band to keep a consistent view of the aggregate state information? (Then, you get into questions as to whether the multiple NATs are there for something simple like load balancing/fault tolerance, or for something more complex like site multi-homing.) I guess I don't have anything conclusive for you on this, but just to note that the "must" in your statement: "there must be only one NAT" may be a bit too strong. Fred ftemplin@iprg.nokia.com Bilajbegovic Damir wrote: >Case: local network connected to the public IP network > >If I understood right, in normally network translation (local IPv4 to public >IPv4), there must be only one NAT (simplest solution) at the border of >network. (NAT-PT and all necessarily ALG) > >If there is translation between IPv4 intranet and IPv6 public network can >then be more than NAT-PT? (all intranet is IPv4, and all public is IPv6) > >If you know the answer or you can direct me to some document I would be >grateful. > Damir Bilajbegovic > >P.S: In translation IPv4/IPv6 there is always translation, and nor IPv4 >user, nor IPv6 server do not see directly each other, they see IPv4 address >which NAT gives to server, and IPv6 server sees IPv6 address of user by >which NAT represents user. Every packet will go directly to specific NAT >(the one who knows translation parameters of connection). So, I do not see >any problem in translation. I'm I wrong. > > > > > From owner-v6ops@ops.ietf.org Mon Sep 15 15:41:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22691 for ; Mon, 15 Sep 2003 15:41:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yz7r-000LML-F4 for v6ops-data@psg.com; Mon, 15 Sep 2003 19:35:07 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.22) id 19yz7K-000LGU-LW for v6ops@ops.ietf.org; Mon, 15 Sep 2003 19:34:34 +0000 Received: (qmail 24166 invoked by uid 1007); 15 Sep 2003 19:34:33 -0000 Date: Mon, 15 Sep 2003 21:34:33 +0200 From: Gert Doering To: Fred Templin Cc: Bilajbegovic Damir , v6ops@ops.ietf.org Subject: Re: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Message-ID: <20030915213433.G67740@Space.Net> References: <3F6605DE.5070708@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F6605DE.5070708@iprg.nokia.com>; from ftemplin@iprg.nokia.com on Mon, Sep 15, 2003 at 11:33:02AM -0700 X-NCC-RegID: de.space X-Spam-Status: No, hits=-5.0 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, Sep 15, 2003 at 11:33:02AM -0700, Fred Templin wrote: > This is an interesting question, and I'm certainly no expert on > the subject. But, in theory, couldn't there be more than one NAT > if, e.g., the (multiple) NAT boxes communicated out-of-band > to keep a consistent view of the aggregate state information? It is possible, and it's actually being done in practice. Some firewall boxes can do this in a high-availability active/active configuration (for example). > (Then, you get into questions as to whether the multiple NATs > are there for something simple like load balancing/fault tolerance, > or for something more complex like site multi-homing.) marketed as load balancing / fault tolerance. Besides the case of multiple NATs working "parallel", I have also seen cases where multiple NATs where daisy-chained (wireless network being NATted to the fixed in-house network, which in turn was NATted to one outside IP). Ugly, but real. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56833 (55575) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Mon Sep 15 20:13:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03771 for ; Mon, 15 Sep 2003 20:13:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19z3LY-000LMW-RU for v6ops-data@psg.com; Tue, 16 Sep 2003 00:05:32 +0000 Received: from [66.218.78.101] (helo=web40404.mail.yahoo.com) by psg.com with smtp (Exim 4.22) id 19z3L1-000LAX-IB for v6ops@ops.ietf.org; Tue, 16 Sep 2003 00:04:59 +0000 Message-ID: <20030916000458.41299.qmail@web40404.mail.yahoo.com> Received: from [66.224.113.194] by web40404.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 17:04:58 PDT Date: Mon, 15 Sep 2003 17:04:58 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Numbers of NAT-s in IPv4/IPv6 Network? One or more? To: Fred Templin , Bilajbegovic Damir Cc: v6ops@ops.ietf.org In-Reply-To: <3F6605DE.5070708@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Please see my comments in-line. cheers, suresh --- Fred Templin wrote: > This is an interesting question, and I'm certainly no expert on > the subject. But, in theory, couldn't there be more than one NAT > if, e.g., the (multiple) NAT boxes communicated out-of-band > to keep a consistent view of the aggregate state information? > (Then, you get into questions as to whether the multiple NATs > are there for something simple like load balancing/fault tolerance, > or for something more complex like site multi-homing.) > You might want to take a look at draft-park-scalable-multi-natpt--00.txt that proposes to do precisely that. > I guess I don't have anything conclusive for you on this, but just > to note that the "must" in your statement: "there must be only > one NAT" may be a bit too strong. I think so, as well. > > Fred > ftemplin@iprg.nokia.com > > Bilajbegovic Damir wrote: > > >Case: local network connected to the public IP network > > > >If I understood right, in normally network translation (local IPv4 to public > >IPv4), there must be only one NAT (simplest solution) at the border of > >network. (NAT-PT and all necessarily ALG) > > > >If there is translation between IPv4 intranet and IPv6 public network can > >then be more than NAT-PT? (all intranet is IPv4, and all public is IPv6) > > > >If you know the answer or you can direct me to some document I would be > >grateful. > > Damir Bilajbegovic > > > >P.S: In translation IPv4/IPv6 there is always translation, and nor IPv4 > >user, nor IPv6 server do not see directly each other, they see IPv4 address > >which NAT gives to server, and IPv6 server sees IPv6 address of user by > >which NAT represents user. Every packet will go directly to specific NAT > >(the one who knows translation parameters of connection). So, I do not see > >any problem in translation. I'm I wrong. > > > > > > > > > > > > > ===== From owner-v6ops@ops.ietf.org Mon Sep 15 22:38:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07560 for ; Mon, 15 Sep 2003 22:38:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19z5bv-000Mkc-0Z for v6ops-data@psg.com; Tue, 16 Sep 2003 02:30:35 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.22) id 19z5bO-000McH-VM for v6ops@ops.ietf.org; Tue, 16 Sep 2003 02:30:03 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HLA00916C9UH4@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 16 Sep 2003 11:29:54 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLA00L1EC9ONL@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 16 Sep 2003 11:29:48 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HLA00FDTC9NY5@mmp2.samsung.com> for v6ops@ops.ietf.org; Tue, 16 Sep 2003 11:29:48 +0900 (KST) Date: Tue, 16 Sep 2003 11:29:53 +0900 From: Soohong Daniel Park Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? In-reply-to: <20030916000458.41299.qmail@web40404.mail.yahoo.com> To: "'Pyda Srisuresh'" , "'Fred Templin'" , "'Bilajbegovic Damir'" Cc: v6ops@ops.ietf.org Message-id: <001e01c37bfa$693de3d0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_tdCu7Yc/uBQMzf7B2YhT/Q)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_30_40,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_tdCu7Yc/uBQMzf7B2YhT/Q) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT sorry for being late in responding to this subject... please refer to the below easy link. > You might want to take a look at > draft-park-scalable-multi-natpt--00.txt that > proposes to do precisely that. http://www.ietf.org/internet-drafts/draft-park-scalable-multi-natpt-00.t xt Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics --Boundary_(ID_tdCu7Yc/uBQMzf7B2YhT/Q) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT 메시지

sorry for being late in responding to this subject...
please refer to the below easy link.

> You might want to take a look at
> draft-park-scalable-multi-natpt--00.txt that
> proposes to do precisely that.

http://www.ietf.org/internet-drafts/draft-park-scalable-multi-natpt-00.txt


Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

--Boundary_(ID_tdCu7Yc/uBQMzf7B2YhT/Q)-- From owner-v6ops@ops.ietf.org Tue Sep 16 02:46:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26994 for ; Tue, 16 Sep 2003 02:46:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19z9Sa-00090x-ON for v6ops-data@psg.com; Tue, 16 Sep 2003 06:37:12 +0000 Received: from [138.190.3.49] (helo=sbe3778.swissptt.ch) by psg.com with esmtp (Exim 4.22) id 19z9S4-0008uj-Lx for v6ops@ops.ietf.org; Tue, 16 Sep 2003 06:36:40 +0000 Received: from sbe2172.corproot.net (138.190.70.54) by sbe3777.swissptt.ch (MX V5.3 AnHp) with SMTP; Tue, 16 Sep 2003 08:36:38 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxsmtp02.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Sep 2003 08:36:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Date: Tue, 16 Sep 2003 08:36:36 +0200 Message-ID: <595362761E89B640A907F5112F8B89B80179BFD1@sxmbx03.corproot.net> Thread-Topic: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Thread-Index: AcN7wyoHKUHg8PKoRri2MJtBVhS9uQAWOW5w From: To: , CC: , X-OriginalArrivalTime: 16 Sep 2003 06:36:37.0109 (UTC) FILETIME=[E0ED6A50:01C37C1C] X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > (Then, you get into questions as to whether the multiple NATs are=20 > > there for something simple like load balancing/fault=20 > tolerance, or for=20 > > something more complex like site multi-homing.) >=20 > marketed as load balancing / fault tolerance. >=20 > Besides the case of multiple NATs working "parallel", I have=20 > also seen cases where multiple NATs where daisy-chained=20 > (wireless network being NATted to the fixed in-house network,=20 > which in turn was NATted to one outside IP). Ugly, but real. Dual NATs are also widely used in the home. If somebody buys first a DSL/Cable modem/router (first NAT) and then adds a WLAN router (second NAT) and doesn't change the default configuration then there are already 2 NATs. I guess that a lot of home users don't have the knowledge to change default configurations and therefore have such a configuration. Andreas From owner-v6ops@ops.ietf.org Tue Sep 16 03:39:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28060 for ; Tue, 16 Sep 2003 03:39:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zANd-000KzV-1l for v6ops-data@psg.com; Tue, 16 Sep 2003 07:36:09 +0000 Received: from [193.81.246.11] (helo=eins.siemens.at) by psg.com with esmtp (Exim 4.22) id 19zAN7-000KuM-2U for v6ops@ops.ietf.org; Tue, 16 Sep 2003 07:35:37 +0000 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h8G7ZWcJ031703; Tue, 16 Sep 2003 09:35:32 +0200 Received: from zagh102a.zag.siemens.hr (nets109x.sie.siemens.at [158.226.134.96]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h8G7ZSmv026981; Tue, 16 Sep 2003 09:35:31 +0200 (MET DST) Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Sep 2003 09:32:28 +0200 Message-ID: From: Bilajbegovic Damir To: Pyda Srisuresh Cc: v6ops@ops.ietf.org, Fred Templin Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Date: Tue, 16 Sep 2003 09:32:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk There must be more than one NAT-PT (for my optimal case.) Network is IMS (IMS is ipv6 only but there is some considering about supporting IPv4 elements) +---------------+ Public +-------+ | |-----Internet IPv6 | IPv4 | 1) |IPv6 IMS core | | User |---NAT-PT---| Network | 3) |equipm.| | |--NAT-PT--- Internet IPv4 +-------+ ________| | +-------+ / +---------------+ | IPv6 | / | | | User |_/ 2) NAT-PT \ |equipm.| | \ +-------+ | \ +-------------+ +-------------+ | IPv4 | | IPv6 | | Application | | Application | | Servers | | Servers | +-------------+ +-------------+ \ / \ / \ / They could also be on public internet As you can se from the picture there are three groups of NAT-PT (every group has number 1, 2 and 3). In every group NAT-PT should be redundant and with some load balancing (in worst case it could be only one). But I am more concerned about having more places of putting such NAT-PT. How will interact different groups of NAT-PT, 1) NAT-PT will serve IPv4 users 2) NAT-PT old application servers 3) NAT-PT for users on the public internet I know that it can be solved when we put only one NAT-PT in network, but it won't be such nice solution. This scenario is not only restricted to IMS. There could be networks like this in many solutions. All network which have more than one way to go to public internet, and there is difference in IP protocols between networks. Eg. Private corporate network is attached to the internet via two network links, each from different ISP. Just to make question clear. Damir Bilajbegovic --- Fred Templin wrote: > This is an interesting question, and I'm certainly no expert on > the subject. But, in theory, couldn't there be more than one NAT > if, e.g., the (multiple) NAT boxes communicated out-of-band > to keep a consistent view of the aggregate state information? > (Then, you get into questions as to whether the multiple NATs > are there for something simple like load balancing/fault tolerance, > or for something more complex like site multi-homing.) > You might want to take a look at draft-park-scalable-multi-natpt--00.txt that proposes to do precisely that. > I guess I don't have anything conclusive for you on this, but just > to note that the "must" in your statement: "there must be only > one NAT" may be a bit too strong. I think so, as well. > Bilajbegovic Damir wrote: > >Case: local network connected to the public IP network > >If I understood right, in normally network translation (local IPv4 to public > >IPv4), there must be only one NAT (simplest solution) at the border of > >network. (NAT-PT and all necessarily ALG) > >If there is translation between IPv4 intranet and IPv6 public network can > >then be more than NAT-PT? (all intranet is IPv4, and all public is IPv6) > >If you know the answer or you can direct me to some document I would be > >grateful. > > Damir Bilajbegovic > >P.S: In translation IPv4/IPv6 there is always translation, and nor IPv4 > >user, nor IPv6 server do not see directly each other, they see IPv4 address > >which NAT gives to server, and IPv6 server sees IPv6 address of user by > >which NAT represents user. Every packet will go directly to specific NAT > >(the one who knows translation parameters of connection). So, I do not > > see any problem in translation. I'm I wrong. From owner-v6ops@ops.ietf.org Tue Sep 16 04:25:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29052 for ; Tue, 16 Sep 2003 04:25:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zB2Z-0003Wy-Gl for v6ops-data@psg.com; Tue, 16 Sep 2003 08:18:27 +0000 Received: from [193.81.246.11] (helo=eins.siemens.at) by psg.com with esmtp (Exim 4.22) id 19zB23-0003Pj-As for v6ops@ops.ietf.org; Tue, 16 Sep 2003 08:17:55 +0000 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h8G8HncJ007534; Tue, 16 Sep 2003 10:17:49 +0200 Received: from zagh102a.zag.siemens.hr (nets109x.sie.siemens.at [158.226.134.96]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h8G8H2mv000745; Tue, 16 Sep 2003 10:17:26 +0200 (MET DST) Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Sep 2003 10:14:03 +0200 Message-ID: From: Bilajbegovic Damir To: Pyda Srisuresh Cc: v6ops@ops.ietf.org, Fred Templin Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Date: Tue, 16 Sep 2003 10:13:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C37C2A.7AA88140" X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C37C2A.7AA88140 Content-Type: text/plain ----------------------------------------------- I say that picture did not appear as I think it would be do here it is again in GIF format. There must be more than one NAT-PT (for my optimal case.) Network is IMS (IMS is ipv6 only but there is some considering about supporting IPv4 elements) +---------------+ Public +-------+ | |-----Internet IPv6 | IPv4 | 1) |IPv6 IMS core | | User |---NAT-PT---| Network | 3) |equipm.| | |--NAT-PT--- Internet IPv4 +-------+ ________| | +-------+ / +---------------+ | IPv6 | / | | | User |_/ 2) NAT-PT \ |equipm.| | \ +-------+ | \ +-------------+ +-------------+ | IPv4 | | IPv6 | | Application | | Application | | Servers | | Servers | +-------------+ +-------------+ \ / \ / \ / They could also be on public internet As you can se from the picture there are three groups of NAT-PT (every group has number 1, 2 and 3). In every group NAT-PT should be redundant and with some load balancing (in worst case it could be only one). But I am more concerned about having more places of putting such NAT-PT. How will interact different groups of NAT-PT, 1) NAT-PT will serve IPv4 users 2) NAT-PT old application servers 3) NAT-PT for users on the public internet I know that it can be solved when we put only one NAT-PT in network, but it won't be such nice solution. This scenario is not only restricted to IMS. There could be networks like this in many solutions. All network which have more than one way to go to public internet, and there is difference in IP protocols between networks. Eg. Private corporate network is attached to the internet via two network links, each from different ISP. Just to make question clear. Damir Bilajbegovic --- Fred Templin wrote: > This is an interesting question, and I'm certainly no expert on > the subject. But, in theory, couldn't there be more than one NAT > if, e.g., the (multiple) NAT boxes communicated out-of-band > to keep a consistent view of the aggregate state information? > (Then, you get into questions as to whether the multiple NATs > are there for something simple like load balancing/fault tolerance, > or for something more complex like site multi-homing.) > You might want to take a look at draft-park-scalable-multi-natpt--00.txt that proposes to do precisely that. > I guess I don't have anything conclusive for you on this, but just > to note that the "must" in your statement: "there must be only > one NAT" may be a bit too strong. I think so, as well. > Bilajbegovic Damir wrote: > >Case: local network connected to the public IP network > >If I understood right, in normally network translation (local IPv4 to public > >IPv4), there must be only one NAT (simplest solution) at the border of > >network. (NAT-PT and all necessarily ALG) > >If there is translation between IPv4 intranet and IPv6 public network can > >then be more than NAT-PT? (all intranet is IPv4, and all public is IPv6) > >If you know the answer or you can direct me to some document I would be > >grateful. > > Damir Bilajbegovic > >P.S: In translation IPv4/IPv6 there is always translation, and nor IPv4 > >user, nor IPv6 server do not see directly each other, they see IPv4 address > >which NAT gives to server, and IPv6 server sees IPv6 address of user by > >which NAT represents user. Every packet will go directly to specific NAT > >(the one who knows translation parameters of connection). So, I do not > > see any problem in translation. I'm I wrong. ------_=_NextPart_000_01C37C2A.7AA88140 Content-Type: image/gif; name="network.GIF" Content-Disposition: attachment; filename="network.GIF" Content-Transfer-Encoding: base64 R0lGODlhygHuAfcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/ MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/ mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/ /5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///ywAAAAAygHuAQAI/wAfCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jT ql3Ltq3bt3Djyp1Lt67du3jzcgWwlu9KAID9HgQ8WLBAw3oTa0RslvFJv44PI4ysuDJGymIxj4T8 gHBnzp4HCg5cMLBmy6hNQzb9mXRrz6oPs479erXr2LRzs67NuzftlJw7i5YteThBw6NRK194+mtz kK6FF09uvLr05dgTPu+63SPi1cWvi/8X3z174vJa0S8OTVx1aNy7X5ufT7++/fv48+vfz7+///8A BiigSOoReFWBB5b0W026sTeZg04hCF2CakkYkWYWKvTcd+ENZlWGHYHok4hRkcjQaHzBFl9r7aXo 4nEqRjdZaZKRZmNVDcZIWI626ejibSuW2BeMNu7Go2zRIRccY9SxB1t4wZ1Io3RNygiViRlhqZOW TXE5Y3VRimbklFSO2dB370Fp3VNeVtSmTW8mFedxdE5nHJNkhqmmdmQOR914ETJIYVpz8lakbUT+ iCiQ70EoJqOloVnogChNWpSllGaq6aacdurpp6CGKuqopJZq6lkYzmbllxBZ6iRwiSr/eqKjhu6o IqAtYXpqh3zeyRx6mCIHa5969tlri9PpquGuwzJX548sCgdspcZuZpCw0tqaokNKfsbrg42i6C2S Eil7anPYRrlkudTWaRKevl7Xo7N+ykurvHuOmy+3zLZLL7l2InkvqwpWayCxaeL7rbsKM+xww5IO 7GG/75758LYG/1vwwwczjOefmGFL5Zokg5yxxRRvrJ2qaF4r8bXvmvlYrNGKGSll8EEb5M0o9qzk yyenzJG5y7KkK9E/IS300kw37fTTUEct9dRUV211piFrS5KFhxL3KK3xLUiRll1DF+ekMio9F4Yk f5Thk9Zti7OdGFvEJdwwZ2nt1mCO/8p2suHaDDTHF6o73t8iX3T3kj6SC6m3T66qt7+4bvq3tHnb O9HPjeeGeY15ht0h54r2mPhGcisM78jJPjthzEFTejmiAv954WWf17wwkbE/dDfmntOIcZM3h3Q0 4ZrOPqVjBb7tte2XI3+7d+1lDhrr2AdMPd+ji3oao5wLzK7dtrL4eGGSTj50+fIBDPqj4kM++PRb v+q9oB8OafTV/Pfv//8ADKAAB0jAAhoQaiJK4KDQ0p2yOWln8esN6iAYk5yhS2UyURvlUFW47tVr biOr29CK5jbfuU5DhUqf4G5VM/bdiIRU0eBOyoM3EVYuXrubnAtXlCRZPdB0UvKVA/9vOMK+lalh 5FmXDXu3FBluiWaeq5sNfUa8uLGscSSE2+rE9bw9bSddXsxhEWunJui563ohWyAHW5U7K6WKQ69T ncuSdEYyEhFhVZSg8S5WL32RR4hEdCIG12jCcZkRhm1bjBHz6DEcGvFYgFpiCnn2NWTlqHbsk16X 9Met8jnwXm6cn+/cAy3dGalr4IPfyspms+LtDWWwHB+OOHlAxQFNcrXMpS53ycte+vKX/hOkGDdZ IWAOUyXCfCUDjXlHZKqxMcA8Uq3AB8RpYnEqyYQTM5OZzT0W05jcfGZZupk8/M3ym8zUDzlnss50 uvOdQiGlPOdJz3rOE574zKc+98n/z34aMJyoeyI6fwlQ9eGknRXcpjlxJ1BCRfOU1PQNRDs3Uefl 5EjSxGhF7WjBamo0onrkZUEVxxOEwsSkARqpm3qCUpe09D8qHRtLaelPoLy0pjjNqU53ytOe+vSn QA3qft6ore+JspmQxMpNj+nOCzoyc/SLalaWitR0OpVuWkNQ87gTz5xelXVVOmpVmSikoFC1U1+l I8Skyi+umtWrsfzYI9vKRq9Q9aycImopW6nKuvp1L13FaUw1Bti3CvWwiE2sYhfL2MY69rHnQuFe vRlLmqStcKX8Idh6iMtm5VN53AuiNvfVSQ+CDoRozOA+QRu2RvmxskkdbSJXVsbY/4VJmHhN6b8k CSb1fPUmq+OXFA9Hs+wNVqFZdN9vtipa4E7MhFJ00BvJOrPP7nZ5z2UrVGVL3dYhMXqz3Z91fzWv SrbvrwSDk+ha5Umt6c6VfVUtPo8b3ou2JbeQza/USKnf/vr3vwAOsIAtq0iDugW/6SXoQg/MJqvC V37gaeGLzEfY+zYYuWGEXNxgRLdAygXBsRVpcZNzyDAuUZOEJGY0+fg++5nYw3EBcYJFnCjztjeV tclkfVOsYl9+sZCb+3BZa9pZ3g34yEhOspKXzGTKyhcuMm5uLunr0HPqksrLtPIBM3pFj25UmgzO 35UXbGExT5nMbIkybAuIZR5js//JUFYqnOdM5zrb+c54zrOemaxmWWrXzP/t85+lLOcACxq9QE4P gD+KRUZ7OaJchjQFwVXUR1MUpI7m6Jc3Gmi3+nmqAj50ohEtzvyKmq6DjuGeV83qVrv61bCOtaxn TetRr+dQv3UyqW2JY8kOsr9tAiMKKxbkEp5wxroGtpNB494TG/vTAXUdKj3r32CfsIpok+mzAxbW bBt62Qmj4q9RPUbl5muS345jJNc97jUbWK6kVXe13caySM2x3YS+DETtbeTQdrqw0C51rQdO8IIb /OAIT7jC7yjW1yrQwLbmN3u3u1KI6/d72rZbx1LNVIoHvNzzXhZ4biXd+J4X09L/JTl4I06nkbvc YykP3HJjjixEKlvkrYzw6URmOFzxvIshdncfDQl0dmc4d8S6U7FQzNjpHn3nHJNZI7WXxmKvcpFz NW2NI/NzJHrc1MmVo9b/mKdz19Hr3ZVeHntudKMPd8NUt/nFr45r81rTZ5gE2MwXBcqM37vu8QNz Rfe6d8f1Pd22xitzE0+UU/MvbQ3/0A8XTvnKW/7ymM98ZUC0I5v63U3OPmioGRp58X68rqX/y+hJ em/5mS9GK4xgxU+feNdmFfaul/3nb87rRXYdZLZjKO1HyXYX99zFFgd7tIOHw+U+ePYcv53zj818 k+9+7qzP3rfenjGLDh+WJ4Z3/9vTnt2Qk0+z53U4jie963xjFu/pj7msdH995W9l8YrWvP73z//+ +///5Vdo3zdk/3Z/9adl5pd/A3gli7ZpKCdpD3hpjeaAotRRmgaBE4iBlgZEYMZ7Chh9BJiAoGZ1 HyiCAgiCDAiAKriCLNiCLviCMBiDLeh42SeD1BYWNAhrOUiCNniDdtWDuUIWO6iDYzGEsWaE7geE xOYcStiETviEUBiFUjiFeYGETEeF8qZqWGh6gLaFPpiCXqh6XRiG1aWFZCiGb3aGaBiCatiGbviG cBiHcjiHQXcpdMiFR2GFmqdmeriHcnKHLvWHgIiHQ9GH+4dghqh/+JWIg9iIjv/4iJAYibemY3/B PA3ENbhliV9XYUqWOmOVbB23Y0lIiKFYgyGyWi33M4bHdZz1PMHXeVe3Jq01N5Pna5TIYSzUeSVn chTUQ4Y0i7GnYyD1Tt2CPWxXdmL3XV7zXCWWdTkXb32DNy4Td9IYXMGHMNpzbsV4fKjoe3QEQmdn Ms5YY7yiVpXTbeDIfdZTW2NHds3FSBIER2VyG914dC0XW9hWYumYSMcYjuCHdlinYe14OpC0dj6H jFtEjLDXawzXiiu0d5t1T/EXkehHd+41R93iHl9TTekHRc0WLuX1SYGDWIyYhVtYZB+WepK4kizZ ki75kjAZkzI5k2RoTzZ5kzj/mZM6uZM82ZM++ZNAGZRCOZREWZRGeZRICZQ0uZRM2ZRO+ZSkUpLc lYYXZh9SiWZgGCj3cZUENoZNVB9JGZZiOZY/WSJkeZY4CZYCgoSOx5VfqE4ChxRuuUH9wZZsCJV4 mZd6KXq65ZVKMZdlCFO2pHdUBCEayV8ax2uVhnHbRh+AeVLC93sLs42lGIB+R5Ac1pjz8Zgv8Ta3 tYnu+HDC546FYZLZwZmBOJj4Io/ZdY0HGFXhQ49egprK5B/OM1ysiZGYyYPQx3wkZprYQZumV5ZE Z1ryxCo+WZkFuY7aF21WuZakx5EwBprtB5seIm7b85x9mZjGqHbItoDveJ3U/wl9jgmd51cjH8mK NDeaY3NFFIeSr6kcwrmGVKmV2gkgdpmVe/lT8+lMXamZX7mVZtVlWTNDWJl8qyQ5jmKYoHiahTh1 45lQ/5mdicY83wmgDhpY7fiJqclODQpDFmqZH7ocZ5U40zZTE3qKsKlzPNRvIcWb5lGiUKR0Kulv EoqhkgWLxlUysmiKm/mgPRp39pWiIFdZjHSNrsmdaqmh6yaOfOmhwJlUR8qjysmJGWpY27dWQwql OCqlRYd2r+ijMTqggCeLNVqbkBml6JORiBlpNdqfXYofbUaeTAGnFGqbB8qedSqn5smld7qnAnp+ KLmIZ5OnYppBEmKnKqqkWP8imkoap/4JqfFJbiioGN7HoaNYnSznnE/2pwV2qJQ6pjWoKoSpM5yF MxN2Sa9XOq93RJ7aoa9KWxnId6xaJK6qqamhb76opW43K8uYjau5PDqnppEaq7TlcOU4dN4ljZtK onp6kF60XlnUpsKDdDtqbUTKqXR1nMTliY4UelYanM8aoi12dtOaXqkDR6pIrG/5rLvFddU6RaMT eYpapAFHrp8jmcipruzIr0+lrWkqqaGDXcFKXGTnW3wqqBu5sPOqo6C0mA90j2QEH3wFsJ05ouiT YxE7dBboWrhqGfWKb6T4qfa5pPhpqI8KqPsJVCFrowGLZC2LphfbiX3aqUf/FrMbd6PGmocJe7LZ SrI9Vp7babP2+pc9K5g/K6houbTc+qNDq7OLWrJC67N+GrVB67RUS7QWa7SBmrVQO2A4i7HFurJk +zRh64hn24hpe59IW7VgW7Nfu3pe+7KGxrR2e7dJqbWI17Z6u2hwS7dv+7SAW7ZSsbaAaLiEe3mI K3RKuLiZ2oOOG66NO7VSGLly54SWW4eTi7WVS7lRmLkXCoSgK6JNOLoRKoOmS34z6LlQmLpXGIOu K4qoy7pPGLtVyoK2i6mry7mfS7uY67ulC7ybK6pTmLu5m7jIu4SoSzsguSqHqZFuBoP6CKzzSr2Z 0bifGTRdV2WQazi5mXS3/xuXuNtGBktpu1mEm1tDz3KYoQsWxxs1LHpZQdef74tAzeedpHu93cts mUWRzzdOyWuGAayfA1zA7mrAcsm19Pa6RhNcEie5jiVj3wuqY9u+1FW/YcazDMy47Sq7HozBZWYU EbOKL3qB8HN70/SLtgqSGuOLWiSdusufCWwsv8liY/fCyfqLwtOPCUaZ6wKhvIe3Qjl+6VotJmrE G1mN7AuN71lHIqSgfqvBDlPENkyavdqazCiK1ugnCzrBjwVi8FLD33vENuyvySqOVQehw5PD4dtT EjyNHNuLHctpFjixF/mwEHhyrOrBJCmIvIt9M3ylCByGINy7g3y1hyzFif/sx4scyI2syI9sh5EM yZPMpJVsyZfseZm8yZzcyZ78f6dWyE1HwIQbyskrxEJ8yqRctqY8wK38ybAcy9yLyKysq2I1mwXs qKPErnmpy6UlsHgpms+rMzH8uHrpqMJCPLjsyiSbzH20zAGMzNJmR1abuNIMSBvcrPvpmcN4OGd6 usEMzGJ7zN7xzXQqy+g8zkAazewlx6WZzdq8lzREOPCqvMg7z/xowUBrzSsav8anWZd6z+/HjVkX pilbymw1pWzcqLmc0N8apMWsz+GMaMNa0BA9qeRMfC3DrXUsNjBay1WpyiGdziQtzprMzgelVQ1t 0hINzlAJzQcdqiBdWs2CG3gQa6reFc8ZvcvWqidcpHTlWqkvTT+lw6xyY8bvI9RPic/W2qMT9lTw mb/bTNQG671VTbAf28vtvKob22JdtowVuNJSy88jXdJmfdZondb/88oiPdYIXdYri8p429a0TLZs LdBwrdZ6vdd83dd+/deAHdiCPdiEXdiGfdiIbRcBAQA7 ------_=_NextPart_000_01C37C2A.7AA88140-- From owner-v6ops@ops.ietf.org Tue Sep 16 05:20:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29909 for ; Tue, 16 Sep 2003 05:20:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zBqU-000DTa-Tv for v6ops-data@psg.com; Tue, 16 Sep 2003 09:10:02 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 19zBpv-000DO4-Hu for v6ops@ops.ietf.org; Tue, 16 Sep 2003 09:09:30 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8G99IB21430 for ; Tue, 16 Sep 2003 12:09:22 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Sep 2003 12:09:10 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 12:09:10 +0300 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 12:09:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Date: Tue, 16 Sep 2003 12:09:08 +0300 Message-ID: <2D3EB51EAED985419D54AB340A9D01950F536B@esebe024.ntc.nokia.com> Thread-Topic: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Thread-Index: AcN7wyoHKUHg8PKoRri2MJtBVhS9uQAWOW5wAAV5NEA= From: To: , , Cc: , X-OriginalArrivalTime: 16 Sep 2003 09:09:09.0399 (UTC) FILETIME=[301E0A70:01C37C32] X-Spam-Status: No, hits=-0.1 required=5.0 tests=BAYES_30,NO_REAL_NAME,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, there also seems to be cases where the ISP nats the internet access and = the home user has multiple computers behind a NAT. In this case it is = not only an accident, but done in purpose. Though, it as ugly if it is = done on purpose or not. Cheers, Jonne. > -----Original Message----- > From: ext [mailto:Andreas.Schmid1@swisscom.com] > Sent: 16 September, 2003 09:37 > To: gert@space.net; ftemplin@iprg.nokia.com > Cc: damir.bilajbegovic@siemens.com; v6ops@ops.ietf.org > Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? >=20 >=20 > > > (Then, you get into questions as to whether the multiple NATs are=20 > > > there for something simple like load balancing/fault=20 > > tolerance, or for=20 > > > something more complex like site multi-homing.) > >=20 > > marketed as load balancing / fault tolerance. > >=20 > > Besides the case of multiple NATs working "parallel", I have=20 > > also seen cases where multiple NATs where daisy-chained=20 > > (wireless network being NATted to the fixed in-house network,=20 > > which in turn was NATted to one outside IP). Ugly, but real. >=20 > Dual NATs are also widely used in the home. If somebody buys first a > DSL/Cable modem/router (first NAT) and then adds a WLAN router (second > NAT) and doesn't change the default configuration then there=20 > are already > 2 NATs. I guess that a lot of home users don't have the knowledge to > change default configurations and therefore have such a configuration. >=20 > Andreas >=20 >=20 From owner-v6ops@ops.ietf.org Tue Sep 16 06:58:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02479 for ; Tue, 16 Sep 2003 06:58:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zDOc-0006pQ-4E for v6ops-data@psg.com; Tue, 16 Sep 2003 10:49:22 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 19zDO5-0006ic-UA for v6ops@ops.ietf.org; Tue, 16 Sep 2003 10:48:50 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GAmjB11059 for ; Tue, 16 Sep 2003 13:48:48 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Sep 2003 13:48:39 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 16 Sep 2003 13:48:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Date: Tue, 16 Sep 2003 13:48:38 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDEAE@esebe005.ntc.nokia.com> Thread-Topic: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Thread-Index: AcN8LNeKRXFJTvUSR5WbdmV+plQQLgAEB7kw From: To: , Cc: , X-OriginalArrivalTime: 16 Sep 2003 10:48:38.0678 (UTC) FILETIME=[1615BB60:01C37C40] X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Damir! [commenting from the 3GPP IMS point of view...] Your picture looks a bit peculiar to me, because this kind of "general" = usage of NAT-PT has not been discussed, not especially in the 3GPP. I = don't understand the usage of NAT-PT between the UE and the IMS (1); the = correct solution here is to support IPv6 in the UE (that is accessing = the (Rel5 or Rel6) IMS network). And what are those IPv4 application = servers (2) that need to be contacted from the IMS? In 3GPP Analysis document (IMS scenario 1), we talk about a special = case: using a translator and SIP ALG to communicate with a small number = of legacy IPv4 SIP equipment. The translator can be based on NAT-PT, put = the point is that pure NAT-PT is not sufficient and we don't use NAT-PT = as a general / generic solution for IPv4 interworking. NAT-PT = applicability document is also being written by a design team, I suppose = they will publish their first draft by Minneapolis meeting. Best Regards, -Juha W.- -----Original Message----- From: ext Bilajbegovic Damir [mailto:damir.bilajbegovic@siemens.com] Sent: 16 September, 2003 11:14 To: Pyda Srisuresh Cc: v6ops@ops.ietf.org; Fred Templin Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? ----------------------------------------------- I say that picture did not appear as I think it would be do here it is = again in GIF format. There must be more than one NAT-PT (for my optimal case.) Network is IMS (IMS is ipv6 only but there is some considering about supporting IPv4 elements) +---------------+ Public =20 +-------+ | |-----Internet IPv6 | IPv4 | 1) |IPv6 IMS core | | User |---NAT-PT---| Network | 3) |equipm.| | |--NAT-PT--- Internet IPv4 =20 +-------+ ________| | +-------+ / +---------------+=20 | IPv6 | / | | | User |_/ 2) NAT-PT \ |equipm.| | \ +-------+ | \ +-------------+ +-------------+=20 | IPv4 | | IPv6 | | Application | | Application | | Servers | | Servers | +-------------+ +-------------+ \ / \ / \ / They could also be on public internet As you can se from the picture there are three groups of NAT-PT (every = group has number 1, 2 and 3). In every group NAT-PT should be redundant and = with some load balancing (in worst case it could be only one).=20 But I am more concerned about having more places of putting such NAT-PT. How will interact different groups of NAT-PT,=20 1) NAT-PT will serve IPv4 users=20 2) NAT-PT old application servers=20 3) NAT-PT for users on the public internet I know that it can be solved when we put only one NAT-PT in network, but = it won't be such nice solution. =20 This scenario is not only restricted to IMS. There could be networks = like this in many solutions. All network which have more than one way to go = to public internet, and there is difference in IP protocols between = networks. Eg. Private corporate network is attached to the internet via two = network links, each from different ISP. =20 Just to make question clear.=20 Damir Bilajbegovic --- Fred Templin wrote: > This is an interesting question, and I'm certainly no expert on > the subject. But, in theory, couldn't there be more than one NAT > if, e.g., the (multiple) NAT boxes communicated out-of-band > to keep a consistent view of the aggregate state information? > (Then, you get into questions as to whether the multiple NATs > are there for something simple like load balancing/fault tolerance, > or for something more complex like site multi-homing.) >=20 You might want to take a look at draft-park-scalable-multi-natpt--00.txt that proposes to do precisely that. > I guess I don't have anything conclusive for you on this, but just > to note that the "must" in your statement: "there must be only > one NAT" may be a bit too strong. I think so, as well. > Bilajbegovic Damir wrote: > >Case: local network connected to the public IP network > >If I understood right, in normally network translation (local IPv4 to public > >IPv4), there must be only one NAT (simplest solution) at the border = of > >network. (NAT-PT and all necessarily ALG) > >If there is translation between IPv4 intranet and IPv6 public network = can > >then be more than NAT-PT? (all intranet is IPv4, and all public is = IPv6) > >If you know the answer or you can direct me to some document I would = be > >grateful. > > Damir Bilajbegovic > >P.S: In translation IPv4/IPv6 there is always translation, and nor = IPv4 > >user, nor IPv6 server do not see directly each other, they see IPv4 address > >which NAT gives to server, and IPv6 server sees IPv6 address of user = by > >which NAT represents user. Every packet will go directly to specific = NAT > >(the one who knows translation parameters of connection). So, I do = not=20 > > see any problem in translation. I'm I wrong. From owner-v6ops@ops.ietf.org Tue Sep 16 08:34:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09429 for ; Tue, 16 Sep 2003 08:34:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zEvc-0001MI-Jy for v6ops-data@psg.com; Tue, 16 Sep 2003 12:27:32 +0000 Received: from [193.81.246.11] (helo=eins.siemens.at) by psg.com with esmtp (Exim 4.22) id 19zEv6-0001EF-E9 for v6ops@ops.ietf.org; Tue, 16 Sep 2003 12:27:00 +0000 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h8GCQkcJ026448; Tue, 16 Sep 2003 14:26:46 +0200 Received: from zagh102a.zag.siemens.hr (nets109x.sie.siemens.at [158.226.134.96]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h8GCQfmv022842; Tue, 16 Sep 2003 14:26:43 +0200 (MET DST) Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Sep 2003 14:23:40 +0200 Message-ID: From: Bilajbegovic Damir To: juha.wiljakka@nokia.com, Bilajbegovic Damir , srisuresh@yahoo.com Cc: v6ops@ops.ietf.org, ftemplin@iprg.nokia.com Subject: RE: Numbers of NAT-s in IPv4/IPv6 Network? One or more? Date: Tue, 16 Sep 2003 14:23:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.8 required=5.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Yes I understand you. IPv6 UE should be used in all cases. All standards say so, and it is according to your documents. But there are already developed IPv4 UE (test purposes only, but in the future there will be IPv4 UE with some application for IMS, or some GGSN wont support IPv6 so PDP should be IPv4). Here in siemens, those IPv4 users we do not won't to forget. So we need to have protocol translator between IMS and UE. As I wrote NAT-PT, I do not think only for NAT-PT but also SIP-ALG and DNS-ALG (all translators that are needed.) IMS should support UE that are acting according Rel5 and 6, but the network will be still aware of old users. Same thing is going to be with old Application servers. Again they are connected via NAT-PT, SIP-ALG and DNS-ALG, and so on. Although, I can't agree with you when you say "small numbers of legacy IPv4 SIP equipment", they won't be so few of them (especially in beginning). Have I cleared my question? Damir Bilajbegovic ---------------------------------------------------------------------- Hi, Damir! [commenting from the 3GPP IMS point of view...] Your picture looks a bit peculiar to me, because this kind of "general" usage of NAT-PT has not been discussed, not especially in the 3GPP. I don't understand the usage of NAT-PT between the UE and the IMS (1); the correct solution here is to support IPv6 in the UE (that is accessing the (Rel5 or Rel6) IMS network). And what are those IPv4 application servers (2) that need to be contacted from the IMS? In 3GPP Analysis document (IMS scenario 1), we talk about a special case: using a translator and SIP ALG to communicate with a small number of legacy IPv4 SIP equipment. The translator can be based on NAT-PT, put the point is that pure NAT-PT is not sufficient and we don't use NAT-PT as a general / generic solution for IPv4 interworking. NAT-PT applicability document is also being written by a design team, I suppose they will publish their first draft by Minneapolis meeting. Best Regards, -Juha W.- -----Original Message----- From: ext Bilajbegovic Damir [mailto:damir.bilajbegovic@siemens.com] Sent: 16 September, 2003 11:14 ----------------------------------------------- I say that picture did not appear as I think it would be do here it is again in GIF format. There must be more than one NAT-PT (for my optimal case.) Network is IMS (IMS is ipv6 only but there is some considering about supporting IPv4 elements) +---------------+ Public +-------+ | |-----Internet IPv6 | IPv4 | 1) |IPv6 IMS core | | User |---NAT-PT---| Network | 3) |equipm.| | |--NAT-PT--- Internet IPv4 +-------+ ________| | +-------+ / +---------------+ | IPv6 | / | | | User |_/ 2) NAT-PT \ |equipm.| | \ +-------+ | \ +-------------+ +-------------+ | IPv4 | | IPv6 | | Application | | Application | | Servers | | Servers | +-------------+ +-------------+ \ / \ / \ / They could also be on public internet As you can se from the picture there are three groups of NAT-PT (every group has number 1, 2 and 3). In every group NAT-PT should be redundant and with some load balancing (in worst case it could be only one). But I am more concerned about having more places of putting such NAT-PT. How will interact different groups of NAT-PT, 1) NAT-PT will serve IPv4 users 2) NAT-PT old application servers 3) NAT-PT for users on the public internet I know that it can be solved when we put only one NAT-PT in network, but it won't be such nice solution. This scenario is not only restricted to IMS. There could be networks like this in many solutions. All network which have more than one way to go to public internet, and there is difference in IP protocols between networks. Eg. Private corporate network is attached to the internet via two network links, each from different ISP. Just to make question clear. Damir Bilajbegovic > >Case: local network connected to the public IP network > >If I understood right, in normally network translation (local IPv4 to public > >IPv4), there must be only one NAT (simplest solution) at the border of > >network. (NAT-PT and all necessarily ALG) > >If there is translation between IPv4 intranet and IPv6 public network can > >then be more than NAT-PT? (all intranet is IPv4, and all public is IPv6) > >If you know the answer or you can direct me to some document I would be > >grateful. > > > >P.S: In translation IPv4/IPv6 there is always translation, and nor IPv4 > >user, nor IPv6 server do not see directly each other, they see IPv4 address > >which NAT gives to server, and IPv6 server sees IPv6 address of user by > >which NAT represents user. Every packet will go directly to specific NAT > >(the one who knows translation parameters of connection). So, I do not > > see any problem in translation. I'm I wrong. From owner-v6ops@ops.ietf.org Tue Sep 16 08:54:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10256 for ; Tue, 16 Sep 2003 08:54:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zFJM-0006ok-GA for v6ops-data@psg.com; Tue, 16 Sep 2003 12:52:04 +0000 Received: from [66.111.4.26] (helo=mail.messagingengine.com) by psg.com with esmtp (Exim 4.22) id 19zFIr-0006jG-8Q for v6ops@ops.ietf.org; Tue, 16 Sep 2003 12:51:33 +0000 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 28F2E1D7200 for ; Tue, 16 Sep 2003 08:51:32 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Tue, 16 Sep 2003 08:51:32 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id 3CC85786A6; Tue, 16 Sep 2003 08:51:31 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Tue, 16 Sep 2003 18:21:31 +0530 X-Epoch: 1063716692 X-Sasl-enc: SmldiO0C1G/d68esqoLSMg Subject: Comments on draft-ietf-ngtrans-isatap-15.txt Message-Id: <20030916125131.3CC85786A6@smtp.us2.messagingengine.com> X-Spam-Status: No, hits=0.1 required=5.0 tests=RCVD_IN_ORBS version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, Two factors compelled me to send comments on this list - there is no official list for discussing ISATAP, and there are enough folks out here who are interested in ISATAP. This mail consists of technical comments (some of which, I believe, would be of interest during deployment of ISATAP), and editorial comments. If the WG chairs feel that this thread is inappropriate for the list, they may indicate so. In that case, I would request that replies should be sent only to me. Regards, CP P.S: This is the third time I am sending this email. Somehow the first two tries (about 8 hrs ago) have not made it. Technical comments: ------------------- 1) What is the reason for removal of Section 4.3, draft 14 (Link Layer Address Option) from the new draft? I can't seem to find any section that specifies how link-layer address are encoded in ND messages or any explicit mention that link layer address option should not be used within the ND messages. I might be missing something obvious in this one as I have yet to read RFC2491. 2) Section 4.3 (draft 15). 1st paragraph. ISATAP interfaces recognize an IPv6 node's required addresses ^^^^^^^^^ What does the word "recognize" imply? 3) Definition of "underlying link" is ambiguous. The phrase "supports IPv4 (for ISATAP)" has multiple connotations. I have two suggestions. Replace the term underlying link (the term "underlying" is too generic) to ISATAP link. In addition, modify the definition to "ISATAP link refers to the underlying unicast IPv4 network over which IPv6 is tunneled." 4) PRL refresh should be done under three conditions - a) expiry of PrlRefreshInterval, b) through a manual trigger (out of scope of the draft), and c) existing routers are determined to be unreachable, and new routers have to be discovered. There is no text corresponding to point c). We should add text that says something like - "If all the routers in the PRL are unreachable, attempts to refresh the PRL should be made at regular intervals of PrlNoRtrRefreshInterval ". Since the PrlRefreshInterval is of 1hr, PrlNoRtrRefreshInterval should have a value much lesser than PrlRefreshInterval. 5) Section 6.3.4.2. Why is the timer formula TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) and not, TIMER(i) = MAX((MIN_LIFETIME), MinRouterSolicitInterval) ? 6) Section 7. Second paragraph. I do not understand the line "Sending implementations map the "All_DHCP_Relay_Agents_and_Servers" multicast address to a link-layer (IPv4) address by selecting V4ADDR(i) for some PRL(i)." What is the mechanism for selecting PLR(i)? Random? If so, can we state that. It is explicitly mentioned that in an ISATAP site the DHCPv6 server has to be collocated in all the PRL routers when stateful autoconfiguration is used. However, no justification is given. My guess is that this decision was taken because no suitable method for locating DHCPv6 servers could be agreed upon. Is that correct? 7) The document is built on the premise that mechanisms for Multicast emulation are not available. Shouldn't there be a section that specifies ISATAP deployment in networks supporting Multicast emulation? 8) Section 6.2. 1st paragraph. "Duplicate Address Detection ([RFC2462], section 5.4) is not required" ^^^^^^^^^^^^^ Bit confusing, in terms of the level of requirement. Is this a MUST NOT, or a SHOULD NOT. I think it is the former. 6. Appendix D. 2nd paragraph "But, allowing this functionality prevents ISATAP nodes from perform effective ingress filtering for IPv6 source addresses in packets they receive. Instead, the nodes must trust that: 1) site border routers are performing ingress filtering, and 2) malicious nodes are effectively denied access to the link." I am unable to see how the ISATAP routers (node, as per the above terminology) be hindered from performing ingress filtering. As I understand, ISATAP hosts will never communicate with non-default routers, and they will use prefixes advertised only by the ISATAP routers. (Maybe I am not able to visualize the same network). My network view is +---+ +-------------+ |Ho-|----------+---------------| PRL router | |st | | +-------------+ +---+ | | | +-----+-----+ |non-def rtr| +-----+-----+ ____|_______ / \ | Stub IPv6 | | n/w | \____________/ Editorial comments: ------------------- 1) Modify the 2nd sentence in Abstract section (to make it better sounding) to: "ISATAP treats the site's IPv4 infrastructure as a NBMA link layer with no requirement for IPv4 multicast." 2) 2nd Para, Section 1. This paragraph is supposed to introduce the reader to the main objectives of the document. With that in mind, the paragraph should be rephrased to: "The main objectives of this document are - 1) specify operational detail for automatic tunneling IPv6 over IPv4 using ISATAP, 2) specify the format of the interface identifier format using an embedded IPv4 address, 3) describe the operation of IPv6 Neighbor Discovery, and 4) discuss deployment, and security considerations." 3) Add a definition of LinkMTU. "The MTU of the link." 4) Section 6.3.1. First paragraph. ISATAP nodes should be ISATAP hosts. 5) Appendix D. 2nd paragraph. s/node/router/ The paragraph was confusing initially as it used nodes instead of routers. Btw, this new section contains another inconsistency - ISATAP link instead of underlying link. I am not complaining though. ;-) 6) Since one of the main aims of the document is to specify deployment considerations (see section 1), I feel we should make Appendix D as a section in the document. From owner-v6ops@ops.ietf.org Tue Sep 16 10:02:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13525 for ; Tue, 16 Sep 2003 10:02:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zGHI-000K0r-LA for v6ops-data@psg.com; Tue, 16 Sep 2003 13:54:00 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 19zGGm-000JvH-GR for v6ops@ops.ietf.org; Tue, 16 Sep 2003 13:53:28 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 688662A495; Tue, 16 Sep 2003 15:53:27 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id F35742A438; Tue, 16 Sep 2003 15:53:24 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id 1C0786E8E; Tue, 16 Sep 2003 09:53:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id 197A46E7B; Tue, 16 Sep 2003 15:53:25 +0200 (CEST) Date: Tue, 16 Sep 2003 15:53:25 +0200 (CEST) From: Mauro Tortonesi To: v6ops@ops.ietf.org Cc: Wim.Biemolt@sec.nl, Alain.Durand@sun.com Subject: old draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk where can i find the following draft? An overview of the Introduction of IPv6 in the Internet formerly known as: draft-ietf-ngtrans-introduction-to-ipv6-transition and then: draft-durand-ngtrans-introduction-to-ipv6-transition -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Tue Sep 16 15:25:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04622 for ; Tue, 16 Sep 2003 15:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zLJl-000B4s-OT for v6ops-data@psg.com; Tue, 16 Sep 2003 19:16:53 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.22) id 19zLJg-000B3j-GF for v6ops@ops.ietf.org; Tue, 16 Sep 2003 19:16:48 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA25905; Tue, 16 Sep 2003 20:16:44 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id UAA10439; Tue, 16 Sep 2003 20:16:34 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h8GJGiT04995; Tue, 16 Sep 2003 20:16:44 +0100 Date: Tue, 16 Sep 2003 20:16:44 +0100 From: Tim Chown To: Mauro Tortonesi Cc: v6ops@ops.ietf.org, Wim.Biemolt@sec.nl, Alain.Durand@sun.com Subject: Re: old draft Message-ID: <20030916191644.GC4918@login.ecs.soton.ac.uk> Mail-Followup-To: Mauro Tortonesi , v6ops@ops.ietf.org, Wim.Biemolt@sec.nl, Alain.Durand@sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-7.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk www.watersprings.org has all old drafts. On Tue, Sep 16, 2003 at 03:53:25PM +0200, Mauro Tortonesi wrote: > > where can i find the following draft? > > An overview of the Introduction of IPv6 in the Internet > > formerly known as: > draft-ietf-ngtrans-introduction-to-ipv6-transition > and then: > draft-durand-ngtrans-introduction-to-ipv6-transition > > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mtortonesi@ing.unife.it > mauro@deepspace6.net > mauro@ferrara.linux.it > Deep Space 6 - IPv6 with Linux http://www.deepspace6.net > Ferrara Linux User Group http://www.ferrara.linux.it > > From owner-v6ops@ops.ietf.org Tue Sep 16 16:38:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10883 for ; Tue, 16 Sep 2003 16:38:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zMU3-0001eA-Km for v6ops-data@psg.com; Tue, 16 Sep 2003 20:31:35 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19zMSe-0001Ke-0X for v6ops@ops.ietf.org; Tue, 16 Sep 2003 20:30:08 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8GKU4D03257; Tue, 16 Sep 2003 13:30:04 -0700 X-mProtect: <200309162030> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZPUPD0; Tue, 16 Sep 2003 13:30:02 PDT Message-ID: <3F677353.7080508@iprg.nokia.com> Date: Tue, 16 Sep 2003 13:32:19 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chirayu Patel CC: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-ngtrans-isatap-15.txt References: <20030916125131.3CC85786A6@smtp.us2.messagingengine.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Chirayu, Thanks for the comments; responses are inline below: Fred ftemplin@iprg.nokia.com Chirayu Patel wrote: >Hello folks, > >Two factors compelled me to send comments on this list - there is no >official list for discussing ISATAP, and there are enough folks out here >who are interested in ISATAP. > >This mail consists of technical comments (some of which, I believe, would >be of interest during deployment of ISATAP), and editorial comments. > >If the WG chairs feel that this thread is inappropriate for the list, >they may indicate so. In that case, I would request that replies should >be sent only to me. > >Regards, >CP >P.S: This is the third time I am sending this email. Somehow the first >two tries (about 8 hrs ago) have not made it. > >Technical comments: >------------------- > >1) What is the reason for removal of Section 4.3, draft 14 (Link Layer >Address Option) from the new draft? I can't seem to find any section that >specifies how link-layer address are encoded in ND messages or any >explicit mention that link layer address option should not be used within >the ND messages. > Link layer address options are not used for ISATAP, but perhaps we should mention this somewhere in the draft. The correct place would seem to be section 6 (Neighbor Discovery). >I might be missing something obvious in this one as I have yet to read >RFC2491. > The RFC 2491 reference is non-normative and historical. ISATAP is implemented independently of RFC 2491. >2) Section 4.3 (draft 15). 1st paragraph. >ISATAP interfaces recognize an IPv6 node's required addresses > ^^^^^^^^^ >What does the word "recognize" imply? > This sentence continues with a normative reference to ([RFC3513, section 2.8), and that section begins as: + 2.8 A Node's Required Addresses + + A host is required to recognize the following addresses as + identifying itself: So, the word "recognize" implies the same thing that it implies in the normative text in RFC 3513. >3) Definition of "underlying link" is ambiguous. The phrase "supports >IPv4 (for ISATAP)" has multiple connotations. I have two suggestions. >Replace the term underlying link (the term "underlying" is too generic) >to ISATAP link. In addition, modify the definition to "ISATAP link refers >to the underlying unicast IPv4 network over which IPv6 is tunneled." > We can consider bringing "ISATAP link" back into the terminology section, but your proposed definition does not capture the fact that more than one underlying link may belong to the same ISATAP link. We've been down this path before; in drafts -12 and earlier we defined the following terms: + underlying link: + a link layer that supports IPv4 (for ISATAP), and MAY also + support IPv6 natively. + + ISATAP link: + one or more underlying links used for tunneling. The IPv4 + network layer addresses of the underlying links are used as + link-layer addresses on the ISATAP link. + + ISATAP interface: + a node's attachment to an ISATAP link. So, if you want "ISATAP link" brought back into the terminology section let's work from the above definitions and refine them as needs-be. Suggestions? >4) PRL refresh should be done under three conditions - a) expiry of >PrlRefreshInterval, b) through a manual trigger (out of scope of the >draft), and c) existing routers are determined to be unreachable, and new >routers have to be discovered. > >There is no text corresponding to point c). We should add text that says >something like - "If all the routers in the PRL are unreachable, attempts >to refresh the PRL should be made at regular intervals of >PrlNoRtrRefreshInterval ". Since the PrlRefreshInterval is of 1hr, >PrlNoRtrRefreshInterval should have a value much lesser than >PrlRefreshInterval. > Points a) and b) sound fine, but we tend to disagree on point c). Some ISATAP sites may by design have no routers in the PRL at all. For other sites, PRL membership changes would most likely be a rare occurrence and coordinated so as to avoid service disruptions. In either case, introducing a finer-grained PRL refresh interval would only lead to traffic scaling issues. >5) Section 6.3.4.2. Why is the timer formula >TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) and not, >TIMER(i) = MAX((MIN_LIFETIME), MinRouterSolicitInterval) ? > We want nodes to solicit fresh RAs *before* any lifetimes expire, and (0.5 * MIN_LIFETIME) seems a reasonable way to assure this. >6) Section 7. Second paragraph. I do not understand the line "Sending >implementations map the "All_DHCP_Relay_Agents_and_Servers" multicast >address to a link-layer (IPv4) address by selecting V4ADDR(i) for some >PRL(i)." What is the mechanism for selecting PLR(i)? Random? If so, can >we state that. > Well, in section 6.3.4.1 we have the sentence: "The manner of selecting PRL(i)'s for solicitation is up to the implementation.", and we imply the same behavior here. We can consider adding a sentence such as the following to section 7: + The manner of selecting a PRL(i) is up to the implementation. >It is explicitly mentioned that in an ISATAP site the DHCPv6 server has >to be collocated in all the PRL routers when stateful autoconfiguration >is used. However, no justification is given. My guess is that this >decision was taken because no suitable method for locating DHCPv6 servers >could be agreed upon. Is that correct? > No; we agree that the simplest scenario is for the DHCPv6 server(s) to be co-located on the PRL router(s). ISATAP is intended as a simple mechanism. >7) The document is built on the premise that mechanisms for Multicast >emulation are not available. Shouldn't there be a section that specifies >ISATAP deployment in networks supporting Multicast emulation? > Section 4.3 says that multicast emulation is out of scope meaning that it would be specified in another document, i.e., we believe nothing more needs to be said in the ISATAP draft. >8) Section 6.2. 1st paragraph. > >"Duplicate Address Detection ([RFC2462], section 5.4) is not required" > ^^^^^^^^^^^^^ > Bit confusing, > in terms of the > level of > requirement. Is > this a MUST NOT, > or a SHOULD NOT. > I think it is > the former. > "not required", as in: "OPTIONAL, but out of scope for this document". >6. Appendix D. 2nd paragraph > > "But, allowing this functionality > prevents ISATAP nodes from perform effective ingress filtering for > IPv6 source addresses in packets they receive. Instead, the nodes > must trust that: 1) site border routers are performing ingress > filtering, and 2) malicious nodes are effectively denied access to > the link." > >I am unable to see how the ISATAP routers (node, as per the above >terminology) be hindered from performing ingress filtering. As I >understand, ISATAP hosts will never communicate with non-default routers, >and they will use prefixes advertised only by the ISATAP routers. (Maybe >I am not able to visualize the same network). My network view is > > >+---+ +-------------+ >|Ho-|----------+---------------| PRL router | >|st | | +-------------+ >+---+ | > | > | > +-----+-----+ > |non-def rtr| > +-----+-----+ > ____|_______ > / \ > | Stub IPv6 | > | n/w | > \____________/ > > Your network view is correct, but ISATAP hosts may communicate with non-default routers. Hosts may receive a redirect with a non-default router as the target, or may otherwise discover a route for a more specific prefix than "default" that has a non-default router as the next hop. >Editorial comments: >------------------- > >1) Modify the 2nd sentence in Abstract section (to make it better >sounding) to: > >"ISATAP treats the site's IPv4 infrastructure as a NBMA link layer with >no requirement for IPv4 multicast." > Have rec'd other comments to the effect that "...no requirement for IPv4 multicast" opened an undesireable can of worms. We can consider inserting the term "NBMA" as in: + ISATAP treats the site's IPv4 unicast infrastructure as a NBMA + link layer for IPv6. But, this seems like a very minor change. >2) 2nd Para, Section 1. > >This paragraph is supposed to introduce the reader to the main objectives >of the document. With that in mind, the paragraph should be rephrased to: > >"The main objectives of this document are - 1) specify operational detail >for automatic tunneling IPv6 over IPv4 using ISATAP, 2) specify the >format of the interface identifier format using an embedded IPv4 address, >3) describe the operation of IPv6 Neighbor Discovery, and 4) discuss >deployment, and security considerations." > Agree with your suggested re-word. >3) Add a definition of LinkMTU. "The MTU of the link." > The first mention of LinkMTU references ([RFC2461, section 6.3.2), and we expect the reader to visit that normative text, so we see this as a low-priority item. If you really think LinkMTU belongs in the terminology section, we can consider adding it as: + LinkMTU: + same as defined in ([RFC2461], section 6.3.2) >4) Section 6.3.1. First paragraph. > >ISATAP nodes should be ISATAP hosts. > The first sentence of (RFC2461, section 5) says: "This section describes a conceptual model of one possible data structure organization that hosts (and to some extent routers) will maintain...", so we really do mean to say nodes (i.e., hosts AND routers) here. To make things clearer, however, we can consider the following re-write for the first sentence of 6.3.1: + ISATAP hosts (and to some extent routers) use the conceptual + data structures specified in ([RFC2461], section 5.1). > 5) Appendix D. 2nd paragraph. s/node/router/ The paragraph was confusing >initially as it used nodes instead of routers. > Well, you were able to draw the network diagram correctly above, so you clearly derived the correct meaning. Your point is taken, but this seems a rather minor detail. >Btw, this new section contains another inconsistency - ISATAP link >instead of underlying link. I am not complaining though. ;-) > See above. >6) Since one of the main aims of the document is to specify deployment >considerations (see section 1), I feel we should make Appendix D as a >section in the document. > Do you mean appendix C, perhaps? Tend to disagree, because there is no normative text in that section, and to our understanding non-normative text belongs as an appendix. From owner-v6ops@ops.ietf.org Wed Sep 17 08:08:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07890 for ; Wed, 17 Sep 2003 08:08:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zawD-0001cQ-6a for v6ops-data@psg.com; Wed, 17 Sep 2003 11:57:37 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.22) id 19zavW-0001Uy-HD for v6ops@ops.ietf.org; Wed, 17 Sep 2003 11:56:54 +0000 Received: from fakat.com ([131.115.157.178]) by lord.fakat.com (8.12.9/8.12.8) with ESMTP id h8HBtRnS015485; Wed, 17 Sep 2003 13:55:28 +0200 (CEST) (envelope-from jasko@fakat.com) Message-ID: <3F684BB0.6000403@fakat.com> Date: Wed, 17 Sep 2003 13:55:28 +0200 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bilajbegovic Damir CC: juha.wiljakka@nokia.com, srisuresh@yahoo.com, v6ops@ops.ietf.org, ftemplin@iprg.nokia.com Subject: Re: Numbers of NAT-s in IPv4/IPv6 Network? One or more? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > future there will be IPv4 UE with some application for IMS, or some GGSN no ims application should be ipv4-only, as ims per definition is ipv6-only. jasminko From owner-v6ops@ops.ietf.org Wed Sep 17 09:52:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11424 for ; Wed, 17 Sep 2003 09:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zcex-000OOj-Tc for v6ops-data@psg.com; Wed, 17 Sep 2003 13:47:55 +0000 Received: from [66.111.4.26] (helo=mail.messagingengine.com) by psg.com with esmtp (Exim 4.22) id 19zcet-000OO1-SO for v6ops@ops.ietf.org; Wed, 17 Sep 2003 13:47:51 +0000 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 70C3D1DCEEC; Wed, 17 Sep 2003 09:47:50 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Wed, 17 Sep 2003 09:47:50 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id 6EFFB709B2; Wed, 17 Sep 2003 09:47:49 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Wed, 17 Sep 2003 19:17:49 +0530 X-Epoch: 1063806470 X-Sasl-enc: zaC1qxbFx/wAkb84kxkhnw Cc: ftemplin@iprg.nokia.com Subject: RE: Comments on draft-ietf-ngtrans-isatap-15.txt Message-Id: <20030917134749.6EFFB709B2@smtp.us2.messagingengine.com> X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Fred, Thanks for the detailed reply. Please see comments below. CP >>1) What is the reason for removal of Section 4.3, draft 14 (Link Layer=20 >>Address Option) from the new draft? I can't seem to find any section=20 >>that specifies how link-layer address are encoded in ND messages or=20 >>any explicit mention that link layer address option should not be used=20 >>within the ND messages. >> > >Link layer address options are not used for ISATAP, but perhaps we=20 >should mention this somewhere in the draft. The correct place would=20 >seem to be section 6 (Neighbor Discovery). Agreed. The text in section 3.8 RFC 2893 seems appropriate The only confusing part is that RFC 2893 assumes that tunnel end points do NOT have link-layer addresses. However it also mentions that SLLA, and TLLA options *SHOULD* (instead of MUST) not be filled. I can't think of any reasons behind the *SHOULD*. In case there is a legitimate reason, then the format of the link-layer address must be specified.=20 >>2) Section 4.3 (draft 15). 1st paragraph. >>ISATAP interfaces recognize an IPv6 node's required addresses >> ^^^^^^^^^ >>What does the word "recognize" imply? >> > >This sentence continues with a normative reference to ([RFC3513,=20 >section 2.8), and that section begins as: > >+ 2.8 A Node's Required Addresses >+ >+ A host is required to recognize the following addresses as >+ identifying itself: > >So, the word "recognize" implies the same thing that it implies in the=20 >normative text in RFC 3513. The wording is a bit different, hence the confusion. It is not the interface that recognizes but the host (or the IPv6 layer on the host). The correct wording should be "A node is required to recognize an IPv6 node's required addresses (RFC[3513], section 2.8). No need to mention "certain multicast/anycast addresses". Right? Or, am I missing something? >We can consider bringing "ISATAP link" back into the terminology=20 >section, but your proposed definition does not capture the fact that=20 >more than one underlying link may belong to the same ISATAP link. > >We've been down this path before; in drafts -12 and earlier we defined=20 >the following terms: > >+ underlying link: >+ a link layer that supports IPv4 (for ISATAP), and MAY also >+ support IPv6 natively. >+ >+ ISATAP link: >+ one or more underlying links used for tunneling. The IPv4 >+ network layer addresses of the underlying links are used as >+ link-layer addresses on the ISATAP link. >+ >+ ISATAP interface: >+ a node's attachment to an ISATAP link. > >So, if you want "ISATAP link" brought back into the terminology section=20 >let's work from the above definitions and refine them as needs-be.=20 >Suggestions? Hmm....I did not think about this one. Maybe the definition can be improved. I'd rather not open my mouth until I get some confirmation from you that my understanding is correct. Assume the following stack in an ISATAP node. +-----------------------------+ | IPv6 | | | +-----------------------------+ | ISATAP i/f | | | +-----------------------------+ | IPv4 | | | +-----------------------------+ | +----------+ +-----------+| | | Phy i/f 1| |Phy i/f 2 || | +----------+ +-----------+| +-----------------------------+ In this diagram, based on the above definitions, 1) Number of underlying links will be 2. Assume two IP addresses one for each underlying link - IPv4A, and IPv4B. 2) Number of ISATAP links will be 1. 3) Number of ISATAP i/d's will be 2 - 0000:5EFE:, and 0000:5EFE: 4) Number of IPv6 link-local addresses will be 2. 5) Number of IPv6 addresses for n prefix's received from the routers in PRL will be 2*n. Is my interpretation accurate?=20 >>4) PRL refresh should be done under three conditions - a) expiry of=20 >>PrlRefreshInterval, b) through a manual trigger (out of scope of the=20 >>draft), and c) existing routers are determined to be unreachable, and=20 >>new routers have to be discovered. >> >>There is no text corresponding to point c). We should add text that=20 >>says something like - "If all the routers in the PRL are unreachable,=20 >>attempts to refresh the PRL should be made at regular intervals of=20 >>PrlNoRtrRefreshInterval ". Since the PrlRefreshInterval is of 1hr,=20 >>PrlNoRtrRefreshInterval should have a value much lesser than=20 >>PrlRefreshInterval. >> > >Points a) and b) sound fine, but we tend to disagree on point c). Some=20 >ISATAP sites may by design have no routers in the PRL at all. For other=20 >sites, PRL membership changes would most likely be a rare occurrence=20 >and coordinated so as to avoid service disruptions. In either case,=20 >introducing a finer-grained PRL refresh interval would only lead to=20 >traffic scaling issues. You are right. Some sites may have no routers. For those sites, the PRL should be empty. Incase the PRL is not empty there should be a more sophisticated mechanism, like router discovery maybe. That said; I am actually not able to make up my mind on the level of detail we should go into. Some of the things that are bothering me are: 1) The PRL mechanism is out of scope. It could be a "push" or a "pull" mechanism or both "push and pull". (Push =3D when a server can push changes to the client. For example, DHCP. Pull =3D when a client queries and gets the data from the server. For example, DNS.) 2) PRL refresh by the client is needed only for "pull" mechanisms. Some pull mechanisms have built in refresh. For example TTL in DNS.=20 3) PrlRefreshInterval seems to cover all types of mechanisms "Push", "Pull", and both "Push and Pull". Its use should be restricted in cases where there is no inbuilt timer.=20 =20 Hence, I propose that we=20 1. Specify the cases where PrlRefreshInterval will be useful. 2. Specify the mechanism for discovering the PRL when no routers are available. Incase you do agree then I can mail some sample text. >>5) Section 6.3.4.2. Why is the timer formula >>TIMER(i) =3D MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) and=20 >>not, >>TIMER(i) =3D MAX((MIN_LIFETIME), MinRouterSolicitInterval) ? >> > >We want nodes to solicit fresh RAs *before* any lifetimes expire, and=20 >(0.5 * MIN_LIFETIME) seems a reasonable way to assure this. Got it! RFC 2461 uses periodic RA's from routers to propagate information proactively vis-=E0-vis periodic RS from the host for new information. The periodic RA's are however sent to multicast address. It means that that periodic RA's cannot be sent out by an ISATAP router. Just curious, have you guys considered an approach wherein a router would remember all the hosts from which it has received RS in the past, and would unicast periodic RA=92s to all of them. >>6) Section 7. Second paragraph. I do not understand the line "Sending=20 >>implementations map the "All_DHCP_Relay_Agents_and_Servers" multicast=20 >>address to a link-layer (IPv4) address by selecting V4ADDR(i) for some=20 >>PRL(i)." What is the mechanism for selecting PLR(i)? Random? If so,=20 >>can we state that. >> > >Well, in section 6.3.4.1 we have the sentence: "The manner of selecting=20 >PRL(i)'s for solicitation is up to the implementation.", and we imply=20 >the same behavior here. We can consider adding a sentence such as the=20 >following to section 7: > >+ The manner of selecting a PRL(i) is up to the implementation. Agreed. >>It is explicitly mentioned that in an ISATAP site the DHCPv6 server=20 >>has to be collocated in all the PRL routers when stateful=20 >>autoconfiguration is used. However, no justification is given. My=20 >>guess is that this decision was taken because no suitable method for=20 >>locating DHCPv6 servers could be agreed upon. Is that correct? > > >No; we agree that the simplest scenario is for the DHCPv6 server(s) to=20 >be co-located on the PRL router(s). ISATAP is intended as a simple=20 >mechanism. Got it. >>7) The document is built on the premise that mechanisms for Multicast=20 >>emulation are not available. Shouldn't there be a section that=20 >>specifies ISATAP deployment in networks supporting Multicast=20 >>emulation? >> > >Section 4.3 says that multicast emulation is out of scope meaning that=20 >it would be specified in another document, i.e., we believe nothing=20 >more needs to be said in the ISATAP draft. Agreed. >>8) Section 6.2. 1st paragraph. >> >>"Duplicate Address Detection ([RFC2462], section 5.4) is not required" >> ^^^^^^^^^^^^^ >> Bit confusing, >> in terms of the >> level of >> requirement. Is >> this a MUST NOT, >> or a SHOULD NOT. >> I think it is >> the former. >> > >"not required", as in: "OPTIONAL, but out of scope for this document". Ok. >>6. Appendix D. 2nd paragraph >> >> "But, allowing this functionality >> prevents ISATAP nodes from perform effective ingress filtering for >> IPv6 source addresses in packets they receive. Instead, the nodes >> must trust that: 1) site border routers are performing ingress >> filtering, and 2) malicious nodes are effectively denied access to >> the link." >> >>I am unable to see how the ISATAP routers (node, as per the above >>terminology) be hindered from performing ingress filtering. As I=20 >>understand, ISATAP hosts will never communicate with non-default=20 >>routers, and they will use prefixes advertised only by the ISATAP=20 >>routers. (Maybe I am not able to visualize the same network). My=20 >>network view is >> >> >>+---+ +-------------+ >>|Ho-|----------+---------------| PRL router | >>|st | | +-------------+ >>+---+ | >> | >> | >> +-----+-----+ >> |non-def rtr| >> +-----+-----+ >> ____|_______ >> / \ >> | Stub IPv6 | >> | n/w | >> \____________/ >> >> > >Your network view is correct, but ISATAP hosts may >communicate with non-default routers. Hosts may receive >a redirect with a non-default router as the target, or may otherwise=20 >discover a route for a more specific prefix than "default" that has a=20 >non-default router as the next hop. More comments on this one below. >Have rec'd other comments to the effect that "...no requirement for=20 >IPv4 multicast" opened an undesireable can of worms. We can consider=20 >inserting the term "NBMA" as in: > >+ ISATAP treats the site's IPv4 unicast infrastructure as a NBMA >+ link layer for IPv6. Ok. >>3) Add a definition of LinkMTU. "The MTU of the link." > >The first mention of LinkMTU references ([RFC2461, section 6.3.2), and=20 >we expect the reader to visit that normative text, so we see this as a=20 >low-priority item. If you really think LinkMTU belongs in the=20 >terminology section, we can consider adding it as: > >+ LinkMTU: >+ same as defined in ([RFC2461], section 6.3.2) My preference is not to repeat definitions from normative references. However, the definition section should mention all the used terms, and provide a reference. IMHO, it improves the readability of the document. >>4) Section 6.3.1. First paragraph. >> >>ISATAP nodes should be ISATAP hosts. >> > >The first sentence of (RFC2461, section 5) says: "This section=20 >describes a conceptual model of one possible data structure=20 >organization that hosts (and to some extent routers) will maintain...",=20 >so we really do mean to say nodes (i.e., hosts AND routers) here. To=20 >make things clearer, however, we can consider the following re-write=20 >for the first sentence of 6.3.1: > >+ ISATAP hosts (and to some extent routers) use the conceptual >+ data structures specified in ([RFC2461], section 5.1). Ok >> 5) Appendix D. 2nd paragraph. s/node/router/ The paragraph was=20 >>confusing initially as it used nodes instead of routers. >> > >Well, you were able to draw the network diagram correctly above, so you=20 >clearly derived the correct meaning. Your point is taken, but this=20 >seems a rather minor detail. I strictly follow the definition of "node" (2461 terminology), and interpret text containing "nodes" in the context of both hosts and routers. This section confused me. My vote is to modify it.=20 I have few more doubts in this section: =3D=3D> "the ability for ISATAP nodes to send IPv6 packets with non-ISATAP source addresses (e.g., RFC 3401 privacy addresses)," What does this imply? ISATAP hosts can send out IPv6-in-IPv4 messages using RFC 3041 src address (instead of ISATAP addresses)? =3D=3D> "But, allowing this functionality prevents ISATAP nodes from perform effective ingress filtering for IPv6 source addresses in packets they receive." The functionality being referred in the above sentence is "flexibility to have more routers than those in the PRL". What prevents these non-default nodes (routers) from doing effective ingress filtering? Like other routers, they too can be configured with the same prefixes. Also s/from perform/from performing/ >>6) Since one of the main aims of the document is to specify deployment=20 >>considerations (see section 1), I feel we should make Appendix D as a=20 >>section in the document. >> > >Do you mean appendix C, perhaps? Tend to disagree, >because there is no normative text in that section, and to our=20 >understanding non-normative text belongs as an appendix. Ok. On the topic of address selection, I am sure that it has been discussed in the past. Policy table modifications do not seem to be straightforward. Do you think it would be useful to mention whatever outcome there has been in the past on address selection? You have reached the end! :-) From owner-v6ops@ops.ietf.org Wed Sep 17 14:53:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23540 for ; Wed, 17 Sep 2003 14:53:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zhIC-000Au6-AA for v6ops-data@psg.com; Wed, 17 Sep 2003 18:44:44 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19zhHg-000Aov-Lu for v6ops@ops.ietf.org; Wed, 17 Sep 2003 18:44:12 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8HIi7U31943; Wed, 17 Sep 2003 11:44:07 -0700 X-mProtect: <200309171844> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJWtcf1; Wed, 17 Sep 2003 11:43:04 PDT Message-ID: <3F68ABC8.3050100@iprg.nokia.com> Date: Wed, 17 Sep 2003 11:45:28 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chirayu Patel CC: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-ngtrans-isatap-15.txt References: <20030917134749.6EFFB709B2@smtp.us2.messagingengine.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit CP, Responses are inline below: Fred ftemplin@iprg.nokia.com Chirayu Patel wrote: >Hi Fred, > >Thanks for the detailed reply. Please see comments below. > >CP > > > >>>1) What is the reason for removal of Section 4.3, draft 14 (Link Layer >>>Address Option) from the new draft? I can't seem to find any section >>>that specifies how link-layer address are encoded in ND messages or >>>any explicit mention that link layer address option should not be used >>>within the ND messages. >>> >>> >>> >>Link layer address options are not used for ISATAP, but perhaps we >>should mention this somewhere in the draft. The correct place would >>seem to be section 6 (Neighbor Discovery). >> >> > >Agreed. > >The text in section 3.8 RFC 2893 seems appropriate > Or something similar, perhaps. >The only confusing part is that RFC 2893 assumes that tunnel end points >do NOT have link-layer addresses. However it also mentions that SLLA, and >TLLA options *SHOULD* (instead of MUST) not be filled. I can't think of >any reasons behind the *SHOULD*. In case there is a legitimate reason, >then the format of the link-layer address must be specified. > Then, this seems like an issue for RFC 2893/MECH(bis). >>>2) Section 4.3 (draft 15). 1st paragraph. >>>ISATAP interfaces recognize an IPv6 node's required addresses >>> ^^^^^^^^^ >>>What does the word "recognize" imply? >>> >>> >>> >>This sentence continues with a normative reference to ([RFC3513, >>section 2.8), and that section begins as: >> >>+ 2.8 A Node's Required Addresses >>+ >>+ A host is required to recognize the following addresses as >>+ identifying itself: >> >>So, the word "recognize" implies the same thing that it implies in the >>normative text in RFC 3513. >> >> > >The wording is a bit different, hence the confusion. It is not the >interface that recognizes but the host (or the IPv6 layer on the host). >The correct wording should be "A node is required to recognize an IPv6 >node's required addresses (RFC[3513], section 2.8). No need to mention >"certain multicast/anycast addresses". Right? Or, am I missing something? > OK. >>We can consider bringing "ISATAP link" back into the terminology >>section, but your proposed definition does not capture the fact that >>more than one underlying link may belong to the same ISATAP link. >> >>We've been down this path before; in drafts -12 and earlier we defined >>the following terms: >> >>+ underlying link: >>+ a link layer that supports IPv4 (for ISATAP), and MAY also >>+ support IPv6 natively. >>+ >>+ ISATAP link: >>+ one or more underlying links used for tunneling. The IPv4 >>+ network layer addresses of the underlying links are used as >>+ link-layer addresses on the ISATAP link. >>+ >>+ ISATAP interface: >>+ a node's attachment to an ISATAP link. >> >>So, if you want "ISATAP link" brought back into the terminology section >>let's work from the above definitions and refine them as needs-be. >>Suggestions? >> >> > >Hmm....I did not think about this one. Maybe the definition can be >improved. I'd rather not open my mouth until I get some confirmation from >you that my understanding is correct. > >Assume the following stack in an ISATAP node. > >+-----------------------------+ >| IPv6 | >| | >+-----------------------------+ >| ISATAP i/f | >| | >+-----------------------------+ >| IPv4 | >| | >+-----------------------------+ >| +----------+ +-----------+| >| | Phy i/f 1| |Phy i/f 2 || >| +----------+ +-----------+| >+-----------------------------+ > >In this diagram, based on the above definitions, > >1) Number of underlying links will be 2. Assume two IP addresses one for >each underlying link - IPv4A, and IPv4B. >2) Number of ISATAP links will be 1. >3) Number of ISATAP i/d's will be 2 - 0000:5EFE:, and >0000:5EFE: >4) Number of IPv6 link-local addresses will be 2. >5) Number of IPv6 addresses for n prefix's received from the routers in >PRL will be 2*n. > >Is my interpretation accurate? > This needs to be broken out into a seperate discussion thread which may indeed be out of scope for v6ops. Let's take this off-list in private e-mail. >>>4) PRL refresh should be done under three conditions - a) expiry of >>>PrlRefreshInterval, b) through a manual trigger (out of scope of the >>>draft), and c) existing routers are determined to be unreachable, and >>>new routers have to be discovered. >>> >>>There is no text corresponding to point c). We should add text that >>>says something like - "If all the routers in the PRL are unreachable, >>>attempts to refresh the PRL should be made at regular intervals of >>>PrlNoRtrRefreshInterval ". Since the PrlRefreshInterval is of 1hr, >>>PrlNoRtrRefreshInterval should have a value much lesser than >>>PrlRefreshInterval. >>> >>> >>> >>Points a) and b) sound fine, but we tend to disagree on point c). Some >>ISATAP sites may by design have no routers in the PRL at all. For other >>sites, PRL membership changes would most likely be a rare occurrence >>and coordinated so as to avoid service disruptions. In either case, >>introducing a finer-grained PRL refresh interval would only lead to >>traffic scaling issues. >> >> > >You are right. Some sites may have no routers. For those sites, the PRL >should be empty. Incase the PRL is not empty there should be a more >sophisticated mechanism, like router discovery maybe. > >That said; I am actually not able to make up my mind on the level of >detail we should go into. Some of the things that are bothering me are: > >1) The PRL mechanism is out of scope. It could be a "push" or a "pull" >mechanism or both "push and pull". (Push = when a server can push changes >to the client. For example, DHCP. Pull = when a client queries and gets >the data from the server. For example, DNS.) > >2) PRL refresh by the client is needed only for "pull" mechanisms. Some >pull mechanisms have built in refresh. For example TTL in DNS. > >3) PrlRefreshInterval seems to cover all types of mechanisms "Push", >"Pull", and both "Push and Pull". Its use should be restricted in cases >where there is no inbuilt timer. > >Hence, I propose that we > >1. Specify the cases where PrlRefreshInterval will be useful. 2. Specify >the mechanism for discovering the PRL when no routers are available. > >Incase you do agree then I can mail some sample text. > Certainly send the sample text (off-list preferred), but we don't yet agree that there is any issue with the current specification. >>>5) Section 6.3.4.2. Why is the timer formula >>>TIMER(i) = MAX((0.5 * MIN_LIFETIME), MinRouterSolicitInterval) and >>>not, >>>TIMER(i) = MAX((MIN_LIFETIME), MinRouterSolicitInterval) ? >>> >>> >>> >>We want nodes to solicit fresh RAs *before* any lifetimes expire, and >>(0.5 * MIN_LIFETIME) seems a reasonable way to assure this. >> >> > >Got it! > >RFC 2461 uses periodic RA's from routers to propagate information >proactively vis-`-vis periodic RS from the host for new information. The >periodic RA's are however sent to multicast address. It means that that >periodic RA's cannot be sent out by an ISATAP router. > No; it means that periodic RA's sent to All-Nodes multicast will not be received by all ISATAP nodes unless a multicast emulation mechanism is used, which is out of scope for the isatap draft. >Just curious, have >you guys considered an approach wherein a router would remember all the >hosts from which it has received RS in the past, and would unicast >periodic RAs to all of them. > This is one possible example of a multicast emulation mechanism (i.e, out of scope for the isatap draft). >>>6) Section 7. Second paragraph. I do not understand the line "Sending >>>implementations map the "All_DHCP_Relay_Agents_and_Servers" multicast >>>address to a link-layer (IPv4) address by selecting V4ADDR(i) for some >>>PRL(i)." What is the mechanism for selecting PLR(i)? Random? If so, >>>can we state that. >>> >>> >>> >>Well, in section 6.3.4.1 we have the sentence: "The manner of selecting >>PRL(i)'s for solicitation is up to the implementation.", and we imply >>the same behavior here. We can consider adding a sentence such as the >>following to section 7: >> >>+ The manner of selecting a PRL(i) is up to the implementation. >> >> > >Agreed. > > > > >>>It is explicitly mentioned that in an ISATAP site the DHCPv6 server >>>has to be collocated in all the PRL routers when stateful >>>autoconfiguration is used. However, no justification is given. My >>>guess is that this decision was taken because no suitable method for >>>locating DHCPv6 servers could be agreed upon. Is that correct? >>> >>> >>No; we agree that the simplest scenario is for the DHCPv6 server(s) to >>be co-located on the PRL router(s). ISATAP is intended as a simple >>mechanism. >> >> > >Got it. > > > >>>7) The document is built on the premise that mechanisms for Multicast >>>emulation are not available. Shouldn't there be a section that >>>specifies ISATAP deployment in networks supporting Multicast >>>emulation? >>> >>> >>> >>Section 4.3 says that multicast emulation is out of scope meaning that >>it would be specified in another document, i.e., we believe nothing >>more needs to be said in the ISATAP draft. >> >> > >Agreed. > > > >>>8) Section 6.2. 1st paragraph. >>> >>>"Duplicate Address Detection ([RFC2462], section 5.4) is not required" >>> ^^^^^^^^^^^^^ >>> Bit confusing, >>> in terms of the >>> level of >>> requirement. Is >>> this a MUST NOT, >>> or a SHOULD NOT. >>> I think it is >>> the former. >>> >>> >>> >>"not required", as in: "OPTIONAL, but out of scope for this document". >> >> > >Ok. > > > >>>6. Appendix D. 2nd paragraph >>> >>> "But, allowing this functionality >>> prevents ISATAP nodes from perform effective ingress filtering for >>> IPv6 source addresses in packets they receive. Instead, the nodes >>> must trust that: 1) site border routers are performing ingress >>> filtering, and 2) malicious nodes are effectively denied access to >>> the link." >>> >>>I am unable to see how the ISATAP routers (node, as per the above >>>terminology) be hindered from performing ingress filtering. As I >>>understand, ISATAP hosts will never communicate with non-default >>>routers, and they will use prefixes advertised only by the ISATAP >>>routers. (Maybe I am not able to visualize the same network). My >>>network view is >>> >>> >>>+---+ +-------------+ >>>|Ho-|----------+---------------| PRL router | >>>|st | | +-------------+ >>>+---+ | >>> | >>> | >>> +-----+-----+ >>> |non-def rtr| >>> +-----+-----+ >>> ____|_______ >>> / \ >>> | Stub IPv6 | >>> | n/w | >>> \____________/ >>> >>> >>> >>> >>Your network view is correct, but ISATAP hosts may >>communicate with non-default routers. Hosts may receive >>a redirect with a non-default router as the target, or may otherwise >>discover a route for a more specific prefix than "default" that has a >>non-default router as the next hop. >> >> > >More comments on this one below. > > > >>Have rec'd other comments to the effect that "...no requirement for >>IPv4 multicast" opened an undesireable can of worms. We can consider >>inserting the term "NBMA" as in: >> >>+ ISATAP treats the site's IPv4 unicast infrastructure as a NBMA >>+ link layer for IPv6. >> >> > >Ok. > > > >>>3) Add a definition of LinkMTU. "The MTU of the link." >>> >>> >>The first mention of LinkMTU references ([RFC2461, section 6.3.2), and >>we expect the reader to visit that normative text, so we see this as a >>low-priority item. If you really think LinkMTU belongs in the >>terminology section, we can consider adding it as: >> >>+ LinkMTU: >>+ same as defined in ([RFC2461], section 6.3.2) >> >> > >My preference is not to repeat definitions from normative references. >However, the definition section should mention all the used terms, and >provide a reference. IMHO, it improves the readability of the document. > OK. >>>4) Section 6.3.1. First paragraph. >>> >>>ISATAP nodes should be ISATAP hosts. >>> >>> >>> >>The first sentence of (RFC2461, section 5) says: "This section >>describes a conceptual model of one possible data structure >>organization that hosts (and to some extent routers) will maintain...", >>so we really do mean to say nodes (i.e., hosts AND routers) here. To >>make things clearer, however, we can consider the following re-write >>for the first sentence of 6.3.1: >> >>+ ISATAP hosts (and to some extent routers) use the conceptual >>+ data structures specified in ([RFC2461], section 5.1). >> >> > >Ok > > > >>>5) Appendix D. 2nd paragraph. s/node/router/ The paragraph was >>>confusing initially as it used nodes instead of routers. >>> >>> >>> >>Well, you were able to draw the network diagram correctly above, so you >>clearly derived the correct meaning. Your point is taken, but this >>seems a rather minor detail. >> >> > >I strictly follow the definition of "node" (2461 terminology), and >interpret text containing "nodes" in the context of both hosts and >routers. This section confused me. My vote is to modify it. > OK. >I have few more doubts in this section: > >==> "the ability for ISATAP nodes to send IPv6 packets with non-ISATAP >source addresses (e.g., RFC 3401 privacy addresses)," > >What does this imply? ISATAP hosts can send out IPv6-in-IPv4 messages >using RFC 3041 src address (instead of ISATAP addresses)? > Given proper configuration, yes. >==> "But, allowing this functionality prevents ISATAP nodes from perform >effective ingress filtering for IPv6 source addresses in packets they >receive." > >The functionality being referred in the above sentence is "flexibility to >have more routers than those in the PRL". What prevents these non-default >nodes (routers) from doing effective ingress filtering? Like other >routers, they too can be configured with the same prefixes. > Suppose non-PRL router A sends packets to ISATAP host B with an IPv6 source address prefix that is not on-link with the ISATAP link and not otherwise known to B, e.g., via a routing table entry. B has no basis for trusting A at the IP level, so B has no way of performing ingress filtering to determine whether A (or some node for which A is the router) is using a spoofed IPv6 source address. Thus, the trust basis must be at the link level if we are to allow non-PRL routers. >Also s/from perform/from performing/ > OK. >>>6) Since one of the main aims of the document is to specify deployment >>>considerations (see section 1), I feel we should make Appendix D as a >>>section in the document. >>> >>> >>> >>Do you mean appendix C, perhaps? Tend to disagree, >>because there is no normative text in that section, and to our >>understanding non-normative text belongs as an appendix. >> >> > >Ok. > >On the topic of address selection, I am sure that it has been discussed >in the past. Policy table modifications do not seem to be >straightforward. Do you think it would be useful to mention whatever >outcome there has been in the past on address selection? > Address selection considerations are the same as for any IPv6 link, modulo further discussion on the definition of ISATAP link. From owner-v6ops@ops.ietf.org Thu Sep 18 04:54:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02678 for ; Thu, 18 Sep 2003 04:54:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zuQU-0003ET-Lf for v6ops-data@psg.com; Thu, 18 Sep 2003 08:46:10 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19zuPy-00036P-V5 for v6ops@ops.ietf.org; Thu, 18 Sep 2003 08:45:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8I8ibx16344 for ; Thu, 18 Sep 2003 11:44:37 +0300 Date: Thu, 18 Sep 2003 11:44:37 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-05: miscellaneous non-critical issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The second set of comments. All of these seem rather straightforward, and there should relatively easy fixes to the problems. semi-substantial: ----------------- 2.1 Dual Stack The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider the 3GPP GPRS core network, dual stack implementation in the GGSN enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack and public (global) IP addresses can often access both IPv4 and IPv6 services without additional translators in the network. ==> I fail to see why public (global) IP addresses are a requirement here? Can't one with a private address also access IPv4 services, possibly with some difficulties, yes, but still in principle.. A translator can be defined as an intermediate component between a native IPv4 node and a native IPv6 node to enable direct communication between them without requiring any modifications to the end nodes. ==> "native" in the above seem unnecessary? ==> I'm not sure if "without requiring any modifications" is a strict goal here, for protocol translator to be valid. Suggest rewording to something like: A translator can be defined as an intermediate component between an IPv4(-only) node and an IPv6(-only) node to enable direct communication between them without requiring to enable dual-stack connectivity in either, with minimal, if any, modifications to the end nodes. 2.4 DNS Guidelines for IPv4/IPv6 Transition ==> this is referred often from the GPRS transition scenarios and from the IMS scenario. However, it is may not be entirely apparent how exactly that applies there -- i.e., how we recommend the DNS services be deployed (or how we recommend they NOT be deployed) in the different 3GPP scenarios. That is, are there any 3GPP-specific (or -related) guidelines to the DNS deployment to add either here or under the GPRS/IMS sections, in addition to the generic guidelines of [DNStrans] ? 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes. It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate PDP context depending on the type of application it has started or depending on the address of the peer host it needs to communicate with. If IPv6 PDP contexts are available and "IPv6 in IPv4" tunneling is needed, it is recommended to activate an IPv6 PDP context and perform tunneling in the network. This case is described in more detail in section 3.2. ==> the last sentence sounds a bit funny, consider rewording to something like: If IPv6 PDP contexts are available, it is recommended to activate the IPv6 PDP context instead of just enabling an IPv4 PDP context and performing IPv6-in-IPv4 tunneling in the UE. This case is described in more detail in section 3.2. .. which is IMO clearer about the non-need for tunneling at the UE. The simpler fix could have been to just add "instead" after "tunneling in the network", but IMO that would not have been as good. As a general guideline, IPv6 communication (native or tunneled from the UE) is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. ==> I think this is in conflict with the text already written earlier in this section. I suggest: As a general guideline, native IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. ... When analyzing a dual stack UE behavior, an application running on a UE can identify whether the endpoint required is an IPv4 or IPv6 capable node by examining the address to discover what address family it falls into. Alternatively, if a user supplies a name to be resolved, the DNS may contain records sufficient to identify which protocol should be used to initiate the connection with the endpoint. Since the UE is capable of native communication with both protocols, one of the main concerns of an operator is the correct address space and routing management. The operator must maintain address spaces for both protocols. Public IPv4 addresses are often a scarce resource for the operator and typically it is not possible for a UE to have a globally unique IPv4 address continuously allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive and difficult to maintain. ==> I was a bit confused when I read this (long) paragraph. It didn't strike clearly to me what is the purpose or the intent of this paragraph. Perhaps this should be considered and reworded so that the goal of the paragraph is clearer. network to the correct translator, there has to be an IPv4 address allocated for the duration of the session from the user traffic translator. The allocation of this address from the user traffic ==> s/allocated/allocated at least/ (this would allow more or less permanent allocation of IPv4 addresses, with less need for dynamicity) server addresses. The authors note that the general IPv6 DNS discovery problem is being solved by the IETF dnsop Working Group. ==> It is unclear whether (and to what extent) that will be "solved", so I'd just replace "solved by" with "discussed at" so we're very close to the mark. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Sep 18 04:54:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02694 for ; Thu, 18 Sep 2003 04:54:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zuN5-0002Xy-El for v6ops-data@psg.com; Thu, 18 Sep 2003 08:42:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19zuMY-0002Pi-8H for v6ops@ops.ietf.org; Thu, 18 Sep 2003 08:42:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8I8f4M16315 for ; Thu, 18 Sep 2003 11:41:04 +0300 Date: Thu, 18 Sep 2003 11:41:04 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-05: editorial issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I've looked into 3gpp-analysis-05; I'll be sending some comments in separate mails. editorial --------- OTA Over The Air ==> s/The/the/? ==> one should probably expand this a bit, because a reader not intimate with 3GPP doesn't know what OTA refers to ("configuration protocol named OTA?", "interface named OTA?", "generic reference to something done over the air?") 1.3 Terminology ==> as SHOULD/MUST use was added, in section 2.4, one should also add the terminology blurb on what those mean and refer to RFC2026. This chapter briefly introduces some transition mechanisms specified by the IETF. The applicability of different transition mechanisms to 3GPP networks is discussed in chapters 3 and 4. DNS recommendations related to IPv4/IPv6 transition are briefly summarized in section 2.4. The IPv4/IPv6 transition methods can be divided to: - dual IPv4/IPv6 stack - tunneling - protocol translators ==> consider rewording to something like? : This chapter briefly introduces some transition mechanisms and guidelines specified by the IETF. The applicability of different transition mechanisms to 3GPP networks is discussed in chapters 3 and 4. The IPv4/IPv6 transition methods and guidelines relevant to this document can be divided to: - dual IPv4/IPv6 stack - tunneling - protocol translators - DNS recommendations (just trying to move the DNS stuff under the same format as the rest of them..) The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider the 3GPP GPRS core network, dual stack implementation in the GGSN ==> spell out GGSN here, as used for the first time However, the UE may attach to a 3GPP network, in which the Serving GPRS Support Node (SGSN), the GGSN and the Home Location Register ==> s/GGSN/GGSN,/ In initial IPv6 deployment, where a small number of IPv6 in IPv4 ==> s/IPv6 in IPv4/IPv6-in-IPv4/ (or some other consistent style) tunneling of IPv4 in IPv6 will be required from the GGSN to ==> s/tunneling of IPv4 in IPv6/IPv4-in-IPv6 tunneling/ ? Regarding the GGSN-to-v4NODE communication, typically the transport network between the GGSN and external networks will support only IPv4 in the early stages and migrate to dual stack, since these networks are already deployed. Therefore it is not envisaged that tunneling of IPv4 in IPv6 will be required from the GGSN to external IPv4 networks either. In the longer run, 3GPP operators may need to phase out IPv4 UEs and the IPv4 transport network. This would leave only IPv6 UEs. Therefore, overall, the transition scenario involving an IPv4 UE communicating with an IPv4 peer through an IPv6 network is not considered very likely in 3GPP networks. ==> I'd recommend starting a new paragraph at "Therefore,"; it seems like a conclusion to this section, and could stand on its own as separate as well. mail and web-browsing. These applications will, of course, be supported in the IPv6 Internet of the future. However, the legacy ==> s/IPv6 Internet of the future/future IPv6 Internet/ As control (or signaling) and user (or data) traffic are separated in SIP, and thus, the IMS, the translation of the IMS traffic has to be done on two levels - Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] on the one hand (Mm-interface), and on the actual user data traffic level on the other (Mb-interface). ==> reword "hand" ? ("interface") ? Internet. Here both the UEs and the IMS islands are IPv6-only. However, the IPv6 islands are not native IPv6 connected. ==> s/are not native IPv6 connected/connected natively with IPv6/ ? ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. OTA or manual configuration can also be possible. IMS subscriber authentication ==> s/can also be/is also/ 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt 8. Intellectual Property Statement 9. Copyright ==> these sections could be after the Editor's contact information section, but that isn't really set in stone. [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.: Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. ==> this ref is not used anymore so it can be removed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Sep 18 05:19:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03181 for ; Thu, 18 Sep 2003 05:19:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zusL-000C9w-Pt for v6ops-data@psg.com; Thu, 18 Sep 2003 09:14:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19zurq-000BxD-7K for v6ops@ops.ietf.org; Thu, 18 Sep 2003 09:14:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8I9DPf16593 for ; Thu, 18 Sep 2003 12:13:25 +0300 Date: Thu, 18 Sep 2003 12:13:24 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is the previously-opened "Automatic tunneling inside 3GPP operator's network" case again. substantial ----------- The issues I'm still not very confortable with: [note: sending the second one first, because the first requires some editing yet..] 2) tunneling inside the 3GPP operator's network, in particular, the last two paragraphs of section 3.2.1: Even a dynamic tunneling mechanism or an IGP/EGP routing protocol based tunneling mechanism can be considered if other methods are not suitable. Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they may provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms. On the other hand, IGP/EGP based mechanisms can provide redundancy. ==> at least, remove "IGP/EGP" (it's enough to say a routing protocol), and rewrite the last paragraph like: Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they may provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms, such as routing protocols run over IPv6 links. .. because "router redundancy mechanisms" is too vague, and IGP/EGP based mechanisms are routing protocols themselves and already included in that context. I'm not sure if these two edits would fix all my concerns with the document, but with these two, it would be much better already. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 19 12:16:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09456 for ; Fri, 19 Sep 2003 12:16:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0EXB-000BJ4-Jo for v6ops-data@psg.com; Fri, 19 Sep 2003 06:14:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A0EX9-000BIC-7L for v6ops@ops.ietf.org; Fri, 19 Sep 2003 06:14:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8J6DMM28409 for ; Fri, 19 Sep 2003 09:13:22 +0300 Date: Fri, 19 Sep 2003 09:13:21 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-05: security considerations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, As has already been raised as an issue, the security considerations section seems pretty weak at the moment, to be refined when we have a better grasp on which mechanisms and techniques to recommend. Assuming we'd end up with something like I've proposed in the previous messages, I've written a bit of text to replace the current security considerations section. ===== Security Considerations There are some generic security considerations when moving to dual-stack IPv4/IPv6 deployment which are not analyzed at length here. Two examples of these are ensuring that the access controls and firewalls have similar (or known) security properties with both IPv4 and IPv6, and that enabling IPv6 does not jeopardize the access to the IPv4 services (e.g., in the form of misbehavior towards DNS AAAA record lookups or operationally worse quality IP transit services). This memo recommends the use of a relatively small number of techniques, which all of them have their own security considerations, including: - native upstream access or configured tunneling by the 3GPP network operator, - use of IPv4 and IPv6 routing protocols to ensure redundancy, - use of locally-deployed specific-purpose protocol relays and application proxies to reach IPv4(-only) nodes from IPv6-only UEs, and - a specific, yet-undefined, mechanism for SIP signalling and media translation, These (except for the last one, naturally) have relatively well-known security considerations, which are also discussed in the specific documents. However, in particular one should note that a proper configuration of locally-deployed relays and proxies is very important, so that the outsiders will not have access to them, to be used for abuse, laundering attacks, or circumventing access controls. In particular, this memo does not recommend any of the following techniques which each have a number of security issues, not further analyzed here: - NAT-PT or any other generic translation mechanism, - automatic tunneling mechanisms, or - the use of IPv6 transition mechanisms at the UEs. ===== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 19 12:16:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09460 for ; Fri, 19 Sep 2003 12:16:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0JwQ-000OUL-UK for v6ops-data@psg.com; Fri, 19 Sep 2003 12:00:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A0JwJ-000OSg-Io for v6ops@ops.ietf.org; Fri, 19 Sep 2003 12:00:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8JBxeM06549; Fri, 19 Sep 2003 14:59:41 +0300 Date: Fri, 19 Sep 2003 14:59:40 +0300 (EEST) From: Pekka Savola To: BAUDOT Alain FTRD/DMI/CAE cc: v6ops@ops.ietf.org, MARTIQUET Nicolas FTRD/DMR/ISS Subject: Re: 3gpp-analisys-05 : UE Connecting to a Node in an IPv4 Network through IMS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Sep 2003, BAUDOT Alain FTRD/DMI/CAE wrote: > The section 4.1 is stating "There will probably be few legacy IPv4 nodes > in the Internet that will communicate with the IMS UEs" This is a rather > strong assumption, and I guess it is difficult today to have clear idea > on how much probable it is. My comment is just that the reader may be > confused by this statement assuming that it is most probable while it is > not. I kind of agree, it may be difficult to estimate it. Perhaps making the statement more vague could help, e.g. change: There will probably be few legacy IPv4 nodes in the Internet that will communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed. [...] to something like: The first priority is to upgrade the legacy IPv4 nodes to dual-stack, eliminating this particular problem in that specific deployment. Still, it is difficult to estimate how many non-upgradeable legacy IPv4 nodes need to communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed. [...] > So, maybe this section would only state that the identified > solution based on NAT-PT may apply within the scope of few simultaneous > cases, and that other more scalable solutions are relevant to the SIP > WG. If you read the draft so that it identifies a solution building on NAT-PT, the draft likely needs to be clarified slightly. The way I read it says that a new SIP-specific translation mechanism needs to be specified, which could e.g. re-use limited subsets of NAT-PT. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 19 12:16:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09427 for ; Fri, 19 Sep 2003 12:15:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0EU1-000AVw-3U for v6ops-data@psg.com; Fri, 19 Sep 2003 06:11:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A0ETu-000AUN-Cr for v6ops@ops.ietf.org; Fri, 19 Sep 2003 06:11:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8J6A0n28385 for ; Fri, 19 Sep 2003 09:10:01 +0300 Date: Fri, 19 Sep 2003 09:10:00 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is the still-open issue "Use of NAT-PT in IPv6 UE -> IPv4 node" discussion. We hope to be able to WG LC and finish the document very soon. Hopefully the WG LC could be initiated after the next revision, before Minneapolis. But we'll see how it turns out. First, a couple of points of discussion: - If UE is IPv6-only, and you hook up an IPv4 (or dual-stack) laptop to the UE, would you be able to use IPv4 through the UE (using separate PDP context)? - Is there something why this would be undesirable (double billing with two PDP contexts?) What I'm trying to grasp at is this: if someone deploys IPv6-only UE's, for specific purposes only (e.g. making calls, browsing the web), can we expect that the user of the device does not require geneirc purpose Internet connectivity (e.g. being able to connect to IPv4 address X, protocol Y, port Z)? substantial ----------- The issues I'm still not very confortable with: 1) NAT-PT use and the recommendations. I don't think it's good practice to deploy IPv6-only UE's before there are no longer services which cannot be proxied or otherwise translated one by one. There are significant amount of dangers associated with general-purpose translation, and NAT-PT is not likely to diminish those. What I'd would like to see in the document: - rather strong recommendation to avoid deploying IPv6-only UE's until the usage (and IPv6) environments have evolved so that generic translation is no longer needed, and - subsequently, greatly reducing the amount of text wrt NAT-PT. The former should/could include like: * reasoning why IPv6-only deployments are/are not valid (this really seems to depend a lot on how specific purpose devices those can be assumed to be) * recommendation to avoid IPv6-only deployments until such time that generic translation is no longer needed * some description why "specific translation" (or proxying) is more desirable than overall translation The latter should/could be reduced become the NAT-PT applicability team is already struggling with this effort (there will be a draft soon). Below is the text I wrote which would seem to be better for now (presupposes that NAT-PT applicability would shun NAT-PT, obviously..). ===== -- in short, I've edited the 3.4 section extensively from scratch, moved the bulk of previous 3.4 section to appendix A with some rewording here and there (until it's known how to deal with it) -- 3.4 IPv6 UE Connecting to an IPv4 Node The deployment of generic-purpose IPv6(-only) UEs is not recommended until the IPv6 deployment has become so prevalent that direct communication with IPv4(-only) nodes will no longer be necessary. Specific-purpose UEs, capable of doing only specific kinds of tasks, are a slightly different thing: it may be possible to make assumptions on the nodes and communication protocols they need to use. Then it may be possible to deploy specialized IPv6(-only) equipment because it's known that they do not need to reach an IPv4(-only) nodes except using very specific applications and methods -- and in that case, it is possible to use specific translation and proxying techniques, not generic translation. Thus there are three main ways for IPv6(-only) nodes to communicate with IPv4(-only) nodes (excluding avoiding such communication in the first place): 1) the use of generic-purpose translator (e.g. NAT-PT [2766]) in the local network (not recommended), 2) the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 TCP relay configured for a couple of ports only [TRT]) or application proxies (e.g., HTTP proxy, SMTP relay) in the local network, or 3) the use of specific-purpose mechanisms (as described above in 2) in the foreign network; these are indistinguishable from the IPv6-enabled services from the IPv6 UE's perspective, and is not discussed further here. The use of generic-purpose translators (such as NAT-PT) is not recommended [NATPTappl]; appendix A lists some 3GPP-specific issues related to the use of translators. For many applications, application proxies can be appropriate (e.g. HTTP proxies, SMTP relays, etc.). Such application proxies will not be transparent to the UE. Hence, a flexible mechanism with minimal manual intervention should be used to configure these proxies on IPv6 UEs. Within the 3GPP architecture, application proxies can be placed on the GGSN external interface (Gi), or inside the service network; see section 5 for more about UE configuration mechanisms. Section 4.1 [reword the last sentence to:] The problems related to NAT-PT are documented in appendix A. Normative References [Add TRT (the TCP/UDP relay RFC)] Appendix A - On the Use of Generic Translators in the 3GPP Networks This appendix lists mainly 3GPP-specific arguments about generic translators, even though the use of generic translators is discouraged. The section may be removed in future versions of the memo. Due to the significant lack of IPv4 addresses in some domains, port multiplexing is likely to be a necessary feature for translators (i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the GGSN external (Gi) interface, typically separate from the GGSN. NA(P)T-PT can be installed, for example, on the edge of the operator's network and the public Internet. NA(P)T-PT will intercept DNS requests and other applications that include IP addresses in their payloads, translate the IP header (and payload for some applications if necessary) and forward packets through its IPv4 interface. NA(P)T-PT introduces limitations that are expected to be magnified within the 3GPP architecture. Some of these limitations are listed below (notice that some of them are also relevant for IPv4 NAT). We note here that [v4v6trans] analyzes the issues when translating between IPv4 and IPv6. 1. NA(P)T-PT is a single point of failure for all ongoing connections. 2. There are additional forwarding delays due to further processing, when compared to normal IP forwarding. 3. There are problems with source address selection due to the inclusion of a DNS ALG on the same node [NATPT-DNS]. 4. NA(P)T-PT does not work (without application level gateways) for applications that embed IP addresses in their payload. 5. NA(P)T-PT breaks DNSSEC. 6. NA(P)T-PT does not scale very well in large networks. 3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface would raise concerns on the overall network reliability. In addition, IPv6 users are expected to use delay-sensitive applications provided by IMS. Hence, there is a need to minimize forwarding delays within the IP backbone. Furthermore, due to the unprecedented number of connections handled by the default routers (GGSN) in 3GPP networks, a network design that forces traffic to go through a single node at the edge of the network (typical NA(P)T-PT configuration) is not likely to scale. Translation mechanisms should allow for multiple translators, for load sharing and redundancy purposes. To minimize the problems associated with NA(P)T-PT, the following actions may be needed: 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 to IPv4" case). 2. Ensure (if possible) that NA(P)T-PT does not become a single point of failure. 3. Allow for load sharing between different translators. That is, it should be possible for different connections to go through different translators. Note that load sharing alone does not prevent NA(P)T-PT from becoming a single point of failure. From owner-v6ops@ops.ietf.org Fri Sep 19 12:16:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09431 for ; Fri, 19 Sep 2003 12:16:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0NJU-000FJQ-D7 for v6ops-data@psg.com; Fri, 19 Sep 2003 15:36:52 +0000 Received: from [192.167.215.12] (helo=ing.unife.it) by psg.com with esmtp (Exim 4.22) id 1A0NJO-000FIO-UP for v6ops@ops.ietf.org; Fri, 19 Sep 2003 15:36:47 +0000 Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 1CFD52A59F; Fri, 19 Sep 2003 17:36:46 +0200 (CEST) Received: from giskard.ing.unife.it (giskard.ing [172.24.3.125]) by ing.unife.it (Postfix) with ESMTP id AFA002A549; Fri, 19 Sep 2003 17:36:45 +0200 (CEST) Received: by giskard.ing.unife.it (Postfix, from userid 501) id B7A17960B; Fri, 19 Sep 2003 11:36:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by giskard.ing.unife.it (Postfix) with ESMTP id B4E476E47; Fri, 19 Sep 2003 17:36:45 +0200 (CEST) Date: Fri, 19 Sep 2003 17:36:45 +0200 (CEST) From: Mauro Tortonesi To: v6ops@ops.ietf.org Cc: itojun@iijlab.net Subject: IPV6_V6ONLY Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_01,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk do you know of any OS that sets the IPV6_V6ONLY socket option on by default? IIRC a few months ago itojun said this was the behaviour of openbsd. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mtortonesi@ing.unife.it mauro@deepspace6.net mauro@ferrara.linux.it Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it From owner-v6ops@ops.ietf.org Fri Sep 19 12:26:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10714 for ; Fri, 19 Sep 2003 12:26:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0AMk-000Ae9-GH for v6ops-data@psg.com; Fri, 19 Sep 2003 01:47:22 +0000 Received: from [66.111.4.26] (helo=mail.messagingengine.com) by psg.com with esmtp (Exim 4.22) id 1A0AM5-000AUS-NP for v6ops@ops.ietf.org; Fri, 19 Sep 2003 01:46:41 +0000 Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 374481E6153 for ; Thu, 18 Sep 2003 21:44:03 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Thu, 18 Sep 2003 21:44:03 -0400 X-Epoch: 1063935843 X-Sasl-enc: FR9htD64wr0g60luMHTpMA Received: from moon (unknown [202.142.102.54]) by mail.messagingengine.com (Postfix) with ESMTP id 9B8A31E601B for ; Thu, 18 Sep 2003 21:43:59 -0400 (EDT) From: "Chirayu Patel" To: Subject: test (please ignore) Date: Fri, 19 Sep 2003 07:17:32 +0530 Message-ID: <001d01c37e50$02df54e0$010aa8c0@chirayu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=1.9 required=5.0 tests=BAYES_60,RCVD_IN_NJABL version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From owner-v6ops@ops.ietf.org Fri Sep 19 13:15:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10723 for ; Fri, 19 Sep 2003 12:26:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0G9D-000EcT-KQ for v6ops-data@psg.com; Fri, 19 Sep 2003 07:57:47 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A0G8h-000EQS-KP for v6ops@ops.ietf.org; Fri, 19 Sep 2003 07:57:15 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8J7vDt06325 for ; Fri, 19 Sep 2003 10:57:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Sep 2003 10:57:13 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 19 Sep 2003 10:57:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05 / new comments in the issue tracker Date: Fri, 19 Sep 2003 10:57:13 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDECC@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: security considerations Thread-Index: AcN+djC8feYD/YyMTQSX4gCDX38ZewADDj9g From: To: Cc: X-OriginalArrivalTime: 19 Sep 2003 07:57:13.0766 (UTC) FILETIME=[A309F460:01C37E83] X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Pekka! Many thanks for your comments (again)! I have now updated issues 11, 9 = and 2, and created one new issue (number 12). Our issue tracker can be found here: http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-analysis/ (currently, there are 5 open issues) Next steps: I aim to reply to Pekka's comments / comment suggested text = early next week and compose revision -06 during next week (if feasible). Cheers, -Juha W.- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 19 September, 2003 09:13 To: v6ops@ops.ietf.org Subject: 3gpp-analysis-05: security considerations Hi, As has already been raised as an issue, the security considerations=20 section seems pretty weak at the moment, to be refined when we have a=20 better grasp on which mechanisms and techniques to recommend. Assuming we'd end up with something like I've proposed in the previous=20 messages, I've written a bit of text to replace the current security=20 considerations section. =3D=3D=3D=3D=3D Security Considerations There are some generic security considerations when moving to dual-stack IPv4/IPv6 deployment which are not analyzed at length here. Two = examples of these are ensuring that the access controls and firewalls have = similar (or known) security properties with both IPv4 and IPv6, and that = enabling IPv6 does not jeopardize the access to the IPv4 services (e.g., in the form of misbehavior towards DNS AAAA record lookups or operationally = worse quality IP transit services). This memo recommends the use of a relatively small number of techniques, which all of them have their own security considerations, including: - native upstream access or configured tunneling by the 3GPP network=20 operator, - use of IPv4 and IPv6 routing protocols to ensure redundancy, - use of locally-deployed specific-purpose protocol relays and=20 application proxies to reach IPv4(-only) nodes from IPv6-only UEs, and - a specific, yet-undefined, mechanism for SIP signalling and media=20 translation, These (except for the last one, naturally) have relatively well-known security considerations, which are also discussed in the specific documents. However, in particular one should note that a proper configuration of locally-deployed relays and proxies is very important, = so that the outsiders will not have access to them, to be used for abuse, laundering attacks, or circumventing access controls. In particular, this memo does not recommend any of the following=20 techniques which each have a number of security issues, not further=20 analyzed here: - NAT-PT or any other generic translation mechanism, - automatic tunneling mechanisms, or - the use of IPv6 transition mechanisms at the UEs. =3D=3D=3D=3D=3D --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 19 13:15:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10733 for ; Fri, 19 Sep 2003 12:26:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0HBv-000CPO-St for v6ops-data@psg.com; Fri, 19 Sep 2003 09:04:39 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.22) id 1A0HAt-000C1F-Uo for v6ops@ops.ietf.org; Fri, 19 Sep 2003 09:03:36 +0000 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 19 Sep 2003 11:03:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37E8C.E2C242E4" Subject: 3gpp-analisys-05 : UE Connecting to a Node in an IPv4 Network through IMS Date: Fri, 19 Sep 2003 11:03:26 +0200 Message-ID: Thread-Topic: 3gpp-analisys-05 : UE Connecting to a Node in an IPv4 Network through IMS Thread-Index: AcN+jOJxk+HU7LCXTZ2n6m4VkiXaUQ== From: "BAUDOT Alain FTRD/DMI/CAE" To: Cc: "MARTIQUET Nicolas FTRD/DMR/ISS" X-OriginalArrivalTime: 19 Sep 2003 09:03:29.0375 (UTC) FILETIME=[E4AFBEF0:01C37E8C] X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_FONT_COLOR_BLUE,HTML_FONT_COLOR_RED version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C37E8C.E2C242E4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The section 4.1 is stating "There will probably be few legacy IPv4 nodes = in the Internet that will communicate with the IMS UEs" This is a rather strong assumption, and I guess it is difficult today to = have clear idea on how much probable it is. My comment is just that the reader may be confused by this statement = assuming that it is most probable while it is not. So, maybe this section would only state that the identified solution = based on NAT-PT may apply within the scope of few simultaneous cases, = and that other more scalable solutions are relevant to the SIP WG. Regards,=20 Alain. ---------------------------------------------------------------- Alain Baudot France Telecom R&D FTR&D/DMI/SIR/IPI e-mail : alain.baudot@francetelecom.com 42, rue des Coutures Tel : +33 2 31 75 94 27 B.P. 6243 Fax : +33 2 31 75 56 26 14066 CAEN Cedex 4 ---------------------------------------------------------------- ------_=_NextPart_001_01C37E8C.E2C242E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 3gpp-analisys-05 : UE Connecting to a Node in an IPv4 Network = through IMS

Hi,

The section 4.1 is stating "There = will probably be few legacy IPv4 nodes in the Internet that will = communicate with the IMS UEs"

This is a rather strong assumption, and = I guess it is difficult today to have clear idea on how much probable it = is.
My comment is just that the reader may = be confused by this statement assuming that it is most probable while it = is not.
So, maybe this section would only = state that the identified solution based on NAT-PT may apply within the = scope of few simultaneous cases, and that other more scalable solutions = are relevant to the SIP WG.

Regards,
Alain.
----------------------------------------------------------= ------
Alain Baudot
France = Telecom R&D
FTR&D/DMI/SIR/IPI      &= nbsp; e-mail : alain.baudot@francetelecom.com
42, rue des = Coutures     Tel : +33  2 31 75 94 27
B.P. = 6243           &nb= sp;    Fax : +33  2 31 75 56 26
14066 CAEN Cedex 4
----------------------------------------------------------= ------


------_=_NextPart_001_01C37E8C.E2C242E4-- From owner-v6ops@ops.ietf.org Sat Sep 20 01:34:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12344 for ; Sat, 20 Sep 2003 01:33:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0aAn-000570-PA for v6ops-data@psg.com; Sat, 20 Sep 2003 05:20:45 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.22) id 1A0aAj-000559-0n for v6ops@ops.ietf.org; Sat, 20 Sep 2003 05:20:41 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id F1D2699; Sat, 20 Sep 2003 14:20:38 +0900 (JST) To: mtortonesi@ing.unife.it Cc: v6ops@ops.ietf.org Subject: Re: IPV6_V6ONLY In-Reply-To: Your message of "Fri, 19 Sep 2003 17:36:45 +0200 (CEST)" References: X-Mailer: Cue version 0.6 (030716-1832/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20030920052038.F1D2699@coconut.itojun.org> Date: Sat, 20 Sep 2003 14:20:38 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > do you know of any OS that sets the IPV6_V6ONLY socket option on by > default? and WinXP uses separate TCP code (IIRC) so effectively behavior is the same as IPV6_V6ONLY = 1. itojun From owner-v6ops@ops.ietf.org Sat Sep 20 02:20:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12345 for ; Sat, 20 Sep 2003 01:33:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0aAX-00050P-Om for v6ops-data@psg.com; Sat, 20 Sep 2003 05:20:29 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.22) id 1A0a9b-0004ij-I5 for v6ops@ops.ietf.org; Sat, 20 Sep 2003 05:19:31 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id AF96E91; Sat, 20 Sep 2003 14:19:30 +0900 (JST) To: mtortonesi@ing.unife.it Cc: v6ops@ops.ietf.org Subject: Re: IPV6_V6ONLY In-Reply-To: Your message of "Fri, 19 Sep 2003 17:36:45 +0200 (CEST)" References: X-Mailer: Cue version 0.6 (030716-1832/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20030920051930.AF96E91@coconut.itojun.org> Date: Sat, 20 Sep 2003 14:19:30 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > do you know of any OS that sets the IPV6_V6ONLY socket option on by > default? netbsd, freebsd (version >= 5), openbsd itojun From owner-v6ops@ops.ietf.org Mon Sep 22 05:07:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06542 for ; Mon, 22 Sep 2003 05:07:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1MNG-000DMA-2l for v6ops-data@psg.com; Mon, 22 Sep 2003 08:48:50 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A1MMc-000DKL-5T for v6ops@ops.ietf.org; Mon, 22 Sep 2003 08:48:10 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8M8m6607169 for ; Mon, 22 Sep 2003 11:48:06 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 11:48:05 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 11:47:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: editorial issues Date: Mon, 22 Sep 2003 11:47:58 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDED6@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: editorial issues Thread-Index: AcN9wrwIvDFl5v+vREKC0HriZZex5gDHlCRg From: To: Cc: X-OriginalArrivalTime: 22 Sep 2003 08:47:59.0291 (UTC) FILETIME=[398D70B0:01C380E6] X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Pekka! Some comments (JW) on the editorial issues: -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 18 September, 2003 11:41 I've looked into 3gpp-analysis-05; I'll be sending some comments in=20 separate mails. editorial --------- OTA Over The Air=20 =3D=3D> s/The/the/? =3D=3D> one should probably expand this a bit, because a reader not = intimate with 3GPP doesn't know what OTA refers to ("configuration protocol named OTA?", "interface named OTA?", "generic reference to something done over = the air?") JW: My solution proposal: I just write "over the air" in the text and = do not use=20 that abbreviation at all. This abbreviation is not anyhow relevant from = this document point of view. Usual meaning for OTA is to send some = configuration information using SMS. 1.3 Terminology =3D=3D> as SHOULD/MUST use was added, in section 2.4, one should also = add the terminology blurb on what those mean and refer to RFC2026. JW: Another alternative is to write this text in 2.4 with lower case = (question:=20 Informational docs do not use capitalized keywords, but how is it in BCP = docs?) If that text will stay here in capital letters, I can add terminology = part. This chapter briefly introduces some transition mechanisms specified by the IETF. The applicability of different transition mechanisms to 3GPP networks is discussed in chapters 3 and 4. DNS recommendations related to IPv4/IPv6 transition are briefly summarized in section 2.4. The IPv4/IPv6 transition methods can be divided to: - dual IPv4/IPv6 stack - tunneling - protocol translators =3D=3D> consider rewording to something like? : This chapter briefly introduces some transition mechanisms and = guidelines specified by the IETF. The applicability of different transition mechanisms to 3GPP networks is discussed in chapters 3 and 4. The IPv4/IPv6 transition methods and guidelines relevant to this document can be divided to: - dual IPv4/IPv6 stack - tunneling - protocol translators - DNS recommendations (just trying to move the DNS stuff under the same format as the rest of them..) JW: Fine for me. The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider the 3GPP GPRS core network, dual stack implementation in the GGSN =3D=3D> spell out GGSN here, as used for the first time JW: Will do. However, the UE may attach to a 3GPP network, in which the Serving GPRS Support Node (SGSN), the GGSN and the Home Location Register =3D=3D> s/GGSN/GGSN,/ JW: ok. In initial IPv6 deployment, where a small number of IPv6 in IPv4 =3D=3D> s/IPv6 in IPv4/IPv6-in-IPv4/ (or some other consistent style) JW: ok. tunneling of IPv4 in IPv6 will be required from the GGSN to=20 =3D=3D> s/tunneling of IPv4 in IPv6/IPv4-in-IPv6 tunneling/ ? JW: ok. Regarding the GGSN-to-v4NODE communication, typically the transport network between the GGSN and external networks will support only IPv4 in the early stages and migrate to dual stack, since these networks are already deployed. Therefore it is not envisaged that tunneling of IPv4 in IPv6 will be required from the GGSN to external IPv4 networks either. In the longer run, 3GPP operators may need to phase out IPv4 UEs and the IPv4 transport network. This would leave only IPv6 UEs. Therefore, overall, the transition scenario involving an IPv4 UE communicating with an IPv4 peer through an IPv6 network is not considered very likely in 3GPP networks. =3D=3D> I'd recommend starting a new paragraph at "Therefore,"; it seems = like a conclusion to this section, and could stand on its own as separate as = well. JW: Sounds rational. mail and web-browsing. These applications will, of course, be=20 supported in the IPv6 Internet of the future. However, the legacy =3D=3D> s/IPv6 Internet of the future/future IPv6 Internet/ JW: ok. As control (or signaling) and user (or data) traffic are separated =20 in SIP, and thus, the IMS, the translation of the IMS traffic has to be done on two levels - Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] on the one hand (Mm-interface), and on the actual user data traffic level on the other (Mb-interface). =3D=3D> reword "hand" ? ("interface") ? JW: Well, maybe writing interface changes the idea a little bit, how = about: " ...the translation of the IMS traffic has to be done at two levels: 1) Session Initiation Protocol (SIP) [RFC3261], and Session Description Protocol (SDP) [RFC2327] [RFC3266] (Mm-interface), and 2) the user data traffic (Mb-interface)." Internet. Here both the UEs and the IMS islands are IPv6-only. =20 However, the IPv6 islands are not native IPv6 connected.=20 =3D=3D> s/are not native IPv6 connected/connected natively with IPv6/ ? JW: yep. ([DHCPv6-SL] or [RFC3315] and [RFC3319]) can be used. OTA or manual configuration can also be possible. IMS subscriber authentication =3D=3D> s/can also be/is also/ JW: ok. 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt 8. Intellectual Property Statement 9. Copyright =3D=3D> these sections could be after the Editor's contact information = section, but that isn't really set in stone. JW: Looking at v6ops and other wg drafts, there seems not to be a common practice.. Until you can show me a clear rule, I will keep the = order as it is now - and let RFC editor make the needed changes. :-) [RFC2283] Bates, T., Chandra, R., Katz, D., Rekhter, Y.:=20 Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. =20 =3D=3D> this ref is not used anymore so it can be removed. JW: True, will remove. Thanks, -Juha- From owner-v6ops@ops.ietf.org Mon Sep 22 07:24:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10080 for ; Mon, 22 Sep 2003 07:24:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1Oeb-000NOr-Q6 for v6ops-data@psg.com; Mon, 22 Sep 2003 11:14:53 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A1Oe5-000NO7-R9 for v6ops@ops.ietf.org; Mon, 22 Sep 2003 11:14:22 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8MBEKt05073 for ; Mon, 22 Sep 2003 14:14:20 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 14:14:20 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 14:14:20 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 14:14:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Mon, 22 Sep 2003 14:14:19 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F0190787A@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: miscellaneous non-critical issues Thread-Index: AcN9yb/0xSct47/8QDWy4q0vDApJDgDHNGlg From: To: Cc: X-OriginalArrivalTime: 22 Sep 2003 11:14:19.0876 (UTC) FILETIME=[AB306240:01C380FA] X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, comments (JW) below: -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 18 September, 2003 11:45 The second set of comments. All of these seem rather straightforward, = and=20 there should relatively easy fixes to the problems. semi-substantial: ----------------- 2.1 Dual Stack The dual IPv4/IPv6 stack is specified in [RFC2893]. If we consider the 3GPP GPRS core network, dual stack implementation in the GGSN enables support for IPv4 and IPv6 PDP contexts. UEs with dual stack and public (global) IP addresses can often access both IPv4 and IPv6 services without additional translators in the network. =3D=3D> I fail to see why public (global) IP addresses are a requirement = here?=20 Can't one with a private address also access IPv4 services, possibly = with some difficulties, yes, but still in principle.. JW: Maybe public/global addresses need not be mentioned here. I just wrote it because the ideal case would be to have public/global = addresses. I could add a sentence clarifying that if UEs need to be contacted (e.g. = thinking peer-to-peer services), public/global addresses would be needed = / preferred. A translator can be defined as an intermediate component between a native IPv4 node and a native IPv6 node to enable direct communication between them without requiring any modifications to the end nodes. =3D=3D> "native" in the above seem unnecessary? JW: Can be removed. =3D=3D> I'm not sure if "without requiring any modifications" is a = strict goal here, for protocol translator to be valid. Suggest rewording to = something like: A translator can be defined as an intermediate component between an IPv4(-only) node and an IPv6(-only) node to enable direct communication between them without requiring to enable dual-stack connectivity in either, with minimal, if any, modifications to the end nodes. JW: Sounds good. 2.4 DNS Guidelines for IPv4/IPv6 Transition =3D=3D> this is referred often from the GPRS transition scenarios and = from the IMS scenario. However, it is may not be entirely apparent how exactly = that applies there -- i.e., how we recommend the DNS services be deployed (or = how we recommend they NOT be deployed) in the different 3GPP scenarios. That is, are there any 3GPP-specific (or -related) guidelines to the DNS deployment to add either here or under the GPRS/IMS sections, in = addition to the generic guidelines of [DNStrans] ? JW: I will think about it and return, if I can find some specific = requirements. 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes. It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an IPv4 PDP context when communicating with an IPv4 peer node. If the 3GPP network supports both IPv4 and IPv6 PDP contexts, the UE activates the appropriate PDP context depending on the type of application it has started or depending on the address of the peer host it needs to communicate with. If IPv6 PDP contexts are available and "IPv6 in IPv4" tunneling is needed, it is recommended to activate an IPv6 PDP context and perform tunneling in the network. This case is described in more detail in section 3.2. =3D=3D> the last sentence sounds a bit funny, consider rewording to = something like: If IPv6 PDP contexts are available, it is recommended to activate the IPv6 PDP context = instead of just enabling an IPv4 PDP context and performing IPv6-in-IPv4 = tunneling in the UE. This case is described in more detail in section 3.2. JW: This sounds rational. As a general guideline, IPv6 communication (native or tunneled from the UE) is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. =3D=3D> I think this is in conflict with the text already written = earlier in this section. I suggest: As a general guideline, native IPv6 communication is preferred to IPv4 communication going through IPv4 NATs to the same dual stack peer node. JW: I don't have any complaints. ... When analyzing a dual stack UE behavior, an application running on a UE can identify whether the endpoint required is an IPv4 or IPv6 capable node by examining the address to discover what address family it falls into. Alternatively, if a user supplies a name to be resolved, the DNS may contain records sufficient to identify which protocol should be used to initiate the connection with the endpoint. Since the UE is capable of native communication with both protocols, one of the main concerns of an operator is the correct address space and routing management. The operator must maintain address spaces for both protocols. Public IPv4 addresses are often a scarce resource for the operator and typically it is not possible for a UE to have a globally unique IPv4 address continuously allocated for its use. Use of private IPv4 addresses means use of NATs when communicating with a peer node outside the operator's network. In large networks, NAT systems can become very complex, expensive and difficult to maintain. =3D=3D> I was a bit confused when I read this (long) paragraph. It = didn't strike clearly to me what is the purpose or the intent of this = paragraph.=20 Perhaps this should be considered and reworded so that the goal of the paragraph is clearer. JW: Yes...this is quite long and not so clear paragraph; I will shorten = it and make some rewording. network to the correct translator, there has to be an IPv4 address allocated for the duration of the session from the user traffic translator. The allocation of this address from the user traffic =3D=3D> s/allocated/allocated at least/ (this would allow more or less=20 permanent allocation of IPv4 addresses, with less need for dynamicity) JW: Yep. server addresses. The authors note that the general IPv6 DNS =20 discovery problem is being solved by the IETF dnsop Working Group. =3D=3D> It is unclear whether (and to what extent) that will be = "solved", so I'd just replace "solved by" with "discussed at" so we're very close to the mark. :-) JW: Well...finding a solution might be a long process. I could use = "discussed at" or "...dnsop is working on the DNS disc..." Cheers, -Juha- From owner-v6ops@ops.ietf.org Mon Sep 22 07:36:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10547 for ; Mon, 22 Sep 2003 07:36:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1Ow2-000OZU-Qh for v6ops-data@psg.com; Mon, 22 Sep 2003 11:32:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A1OvW-000OYL-SS for v6ops@ops.ietf.org; Mon, 22 Sep 2003 11:32:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8MBVJH23903; Mon, 22 Sep 2003 14:31:19 +0300 Date: Mon, 22 Sep 2003 14:31:19 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: editorial issues In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CDED6@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 22 Sep 2003 juha.wiljakka@nokia.com wrote: > Some comments (JW) on the editorial issues: Just replying to a few remaining issues. > OTA Over The Air > > ==> s/The/the/? > ==> one should probably expand this a bit, because a reader not intimate > with 3GPP doesn't know what OTA refers to ("configuration protocol named > OTA?", "interface named OTA?", "generic reference to something done over the > air?") > > JW: My solution proposal: I just write "over the air" in the text and do not use > that abbreviation at all. This abbreviation is not anyhow relevant from this > document point of view. Usual meaning for OTA is to send some configuration > information using SMS. Agreed, just removing the abbreviation etc. might be best as it really isn't so important piece of the specification. > 1.3 Terminology > > ==> as SHOULD/MUST use was added, in section 2.4, one should also add the > terminology blurb on what those mean and refer to RFC2026. > > JW: Another alternative is to write this text in 2.4 with lower case (question: > Informational docs do not use capitalized keywords, but how is it in BCP docs?) > If that text will stay here in capital letters, I can add terminology part. BCP could have upper caps (as well as specific kinds of informational documents). The problem here is that you're quoting directly what it says in the DNStrans document. So, changing it in this document might not be appropriate. So, I think there may be three ways around this issue: - define RFC2026 keywords, - just convert the uppercases to lowercases, or - in section 2.4, state it more clearly that the recommendations have been copied verbatim from DNStrans (which might imply that DNStrans is the authorative source here, not the uppercases in this document) > As control (or signaling) and user (or data) traffic are separated > in SIP, and thus, the IMS, the translation of the IMS traffic has > to be done on two levels - Session Initiation Protocol (SIP) > [RFC3261], and Session Description Protocol (SDP) [RFC2327] > [RFC3266] on the one hand (Mm-interface), and on the actual user > data traffic level on the other (Mb-interface). > > ==> reword "hand" ? ("interface") ? > > JW: Well, maybe writing interface changes the idea a little bit, how about: > > " ...the translation of the IMS traffic has > to be done at two levels: 1) Session Initiation Protocol (SIP) > [RFC3261], and Session Description Protocol (SDP) [RFC2327] > [RFC3266] (Mm-interface), and 2) the user > data traffic (Mb-interface)." sounds good. > 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt > 8. Intellectual Property Statement > 9. Copyright > > ==> these sections could be after the Editor's contact information section, > but that isn't really set in stone. > > JW: Looking at v6ops and other wg drafts, there seems not to be a > common practice.. Until you can show me a clear rule, I will keep the order > as it is now - and let RFC editor make the needed changes. :-) There is no strict rule of this, but ID-nits lists these in that order (and in most cases, that's what seems to make the most sense to me, because those are sections that will be either removed at publication or stay the same across all I-Ds): http://www.ietf.org/ID-nits.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 22 08:16:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11810 for ; Mon, 22 Sep 2003 08:16:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1PXn-0001lZ-EG for v6ops-data@psg.com; Mon, 22 Sep 2003 12:11:55 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A1PXj-0001lF-8J for v6ops@ops.ietf.org; Mon, 22 Sep 2003 12:11:51 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8MCBn619308 for ; Mon, 22 Sep 2003 15:11:50 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 15:11:49 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 15:11:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Date: Mon, 22 Sep 2003 15:02:19 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F0190787F@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Thread-Index: AcN9xil2w6eWi3lAQ6Cb1Rrfh6idgwDOsfkw From: To: , X-OriginalArrivalTime: 22 Sep 2003 12:11:49.0823 (UTC) FILETIME=[B38484F0:01C38102] X-Spam-Status: No, hits=1.1 required=5.0 tests=BAYES_30,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi! I don't personally have big problems with that suggested text. If the = other people on the list do not object the text change, we could move forward with = this issue. Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 18 September, 2003 12:13 To: v6ops@ops.ietf.org Subject: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Hi, This is the previously-opened "Automatic tunneling inside 3GPP = operator's=20 network" case again. substantial ----------- The issues I'm still not very confortable with: [note: sending the second one first, because the first requires some=20 editing yet..] 2) tunneling inside the 3GPP operator's network, in particular, the last = two paragraphs of section 3.2.1: Even a dynamic tunneling mechanism or an IGP/EGP routing protocol based tunneling mechanism can be considered if other methods are not suitable. Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they may provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms. On the other hand, IGP/EGP based mechanisms can provide redundancy. =3D=3D> at least, remove "IGP/EGP" (it's enough to say a routing = protocol), and rewrite the last paragraph like: Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they may provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms, such as routing protocols run over = IPv6=20 links. .. because "router redundancy mechanisms" is too vague, and IGP/EGP = based mechanisms are routing protocols themselves and already included in that = context. I'm not sure if these two edits would fix all my concerns with the=20 document, but with these two, it would be much better already. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 22 10:02:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15139 for ; Mon, 22 Sep 2003 10:02:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1R9c-0009SD-OY for v6ops-data@psg.com; Mon, 22 Sep 2003 13:55:04 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A1R9V-0009QV-97 for v6ops@ops.ietf.org; Mon, 22 Sep 2003 13:54:57 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8MDst627890 for ; Mon, 22 Sep 2003 16:54:55 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 16:54:55 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 16:54:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node Date: Mon, 22 Sep 2003 16:54:54 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDEDD@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node Thread-Index: AcN+disGmueVpR8gSju11x6UDE7ElQCk+NCg From: To: , X-OriginalArrivalTime: 22 Sep 2003 13:54:55.0265 (UTC) FILETIME=[1A541110:01C38111] X-Spam-Status: No, hits=2.0 required=5.0 tests=NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi! Comments below (JW): -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 19 September, 2003 09:10 We hope to be able to WG LC and finish the document very soon. = Hopefully the WG LC could be initiated after the next revision, before = Minneapolis. But we'll see how it turns out. JW: Yep, let's see; that would be a good schedule. First, a couple of points of discussion: - If UE is IPv6-only, and you hook up an IPv4 (or dual-stack) laptop to = the UE, would you be able to use IPv4 through the UE (using separate PDP = context)? - Is there something why this would be undesirable (double billing with = two PDP contexts?) JW: Hmm...that depends on the fact whether IPv4 dial-up is supported in the UE, i.e. that means PPP(v4) support and it must be possible to set up a PDP context for PC dial-up... If we strictly talk about IPv6- only UE, maybe that is not possible, but it depends on the = implementation. What I'm trying to grasp at is this: if someone deploys IPv6-only UE's, for specific purposes only (e.g. making calls, browsing the web), can we expect that the user of the device does not require geneirc purpose Internet connectivity (e.g. being able to connect to IPv4 address X,=20 protocol Y, port Z)? JW: Well...it seems that some level of IPv4 connectivity will be needed = for=20 quite a long time (even though I personally hope that the transition=20 to IPv6 would happen more rapidly). Anyway, making prognoses is always difficult. =20 substantial ----------- The issues I'm still not very confortable with: 1) NAT-PT use and the recommendations. I don't think it's good = practice to deploy IPv6-only UE's before there are no longer services which cannot = be proxied or otherwise translated one by one. There are significant = amount of dangers associated with general-purpose translation, and NAT-PT is not likely to diminish those. What I'd would like to see in the document: - rather strong recommendation to avoid deploying IPv6-only UE's until = the usage (and IPv6) environments have evolved so that generic translation = is no longer needed, and JW: I think that a general recommendation for dual stack UEs in the near future is a rational one. At least that seems to be the natural=20 step after IPv4-only UEs. But we should also encourage manufacturers=20 to make dual stack UEs instead of v4-only UEs! :-) - subsequently, greatly reducing the amount of text wrt NAT-PT. The former should/could include like: * reasoning why IPv6-only deployments are/are not valid (this really=20 seems to depend a lot on how specific purpose devices those can be = assumed=20 to be)=20 * recommendation to avoid IPv6-only deployments until such time that=20 generic translation is no longer needed * some description why "specific translation" (or proxying) is more=20 desirable than overall translation The latter should/could be reduced become the NAT-PT applicability team = is=20 already struggling with this effort (there will be a draft soon). Below is the text I wrote which would seem to be better for now=20 (presupposes that NAT-PT applicability would shun NAT-PT, obviously..). =3D=3D=3D=3D=3D -- in short, I've edited the 3.4 section extensively from scratch, moved = the bulk of previous 3.4 section to appendix A with some rewording here=20 and there (until it's known how to deal with it) -- 3.4 IPv6 UE Connecting to an IPv4 Node=20 The deployment of generic-purpose IPv6(-only) UEs is not recommended = until the IPv6 deployment has become so prevalent that direct communication = with IPv4(-only) nodes will no longer be necessary. Specific-purpose UEs, capable of doing only specific kinds of tasks, are = a slightly different thing: it may be possible to make assumptions on the nodes and communication protocols they need to use. Then it may be possible to deploy specialized IPv6(-only) equipment because it's known that they do not need to reach an IPv4(-only) nodes except using very specific applications and methods -- and in that case, it is possible to use specific translation and proxying techniques, not generic translation. Thus there are three main ways for IPv6(-only) nodes to communicate with IPv4(-only) nodes (excluding avoiding such communication in the first=20 place): 1) the use of generic-purpose translator (e.g. NAT-PT [2766]) in the=20 local network (not recommended), 2) the use of specific-purpose protocol relays (e.g., IPv6<->IPv4=20 TCP relay configured for a couple of ports only [TRT]) or application=20 proxies (e.g., HTTP proxy, SMTP relay) in the local network, or JW: How much do we have real life / implementation experience on TRT? 3) the use of specific-purpose mechanisms (as described above in 2) in=20 the foreign network; these are indistinguishable from the IPv6-enabled=20 services from the IPv6 UE's perspective, and is not discussed further=20 here. The use of generic-purpose translators (such as NAT-PT) is not = recommended=20 [NATPTappl]; appendix A lists some 3GPP-specific issues related to the = use=20 of translators. JW: In my opinion, NATPTappl will have an important task explaining why = you=20 don't want to encourage people using NAT-PT as a generic transition mechanism. I haven't fully understood the big picture. With = dual stack (and IPv4) we usually have to use v4-NATs anyway. Just a question: = if I say that the evilness of NA(P)T is X, how evil would you then say NA(P)T-PT = is (compared to X)? For many applications, application proxies can be appropriate (e.g. HTTP proxies, SMTP relays, etc.). Such application proxies will not be transparent to the UE. Hence, a flexible mechanism with minimal manual intervention should be used to configure these proxies on IPv6 UEs. = Within the 3GPP architecture, application proxies can be placed on the GGSN external interface (Gi), or inside the service network; see section 5 = for=20 more about UE configuration mechanisms. Section 4.1 [reword the last sentence to:] The problems related to NAT-PT are documented in appendix A. Normative References [Add TRT (the TCP/UDP relay RFC)] Appendix A - On the Use of Generic Translators in the 3GPP Networks This appendix lists mainly 3GPP-specific arguments about generic=20 translators, even though the use of generic translators is=20 discouraged. The section may be removed in future versions of the=20 memo. Due to the significant lack of IPv4 addresses in some domains, port multiplexing is likely to be a necessary feature for translators (i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the GGSN external (Gi) interface, typically separate from the GGSN. NA(P)T-PT can be installed, for example, on the edge of the operator's network and the public Internet. NA(P)T-PT will intercept DNS requests and other applications that include IP addresses in their payloads, translate the IP header (and payload for some applications if necessary) and forward packets through its IPv4 interface. NA(P)T-PT introduces limitations that are expected to be magnified within the 3GPP architecture. Some of these limitations are listed below (notice that some of them are also relevant for IPv4 NAT). We note here that [v4v6trans] analyzes the issues when translating between IPv4 and IPv6. 1. NA(P)T-PT is a single point of failure for all ongoing connections. 2. There are additional forwarding delays due to further processing, when compared to normal IP forwarding. 3. There are problems with source address selection due to the inclusion of a DNS ALG on the same node [NATPT-DNS]. 4. NA(P)T-PT does not work (without application level gateways) for applications that embed IP addresses in their payload. 5. NA(P)T-PT breaks DNSSEC. 6. NA(P)T-PT does not scale very well in large networks. 3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface would raise concerns on the overall network reliability. In addition, IPv6 users are expected to use delay-sensitive applications provided by IMS. Hence, there is a need to minimize forwarding delays within the IP backbone. Furthermore, due to the unprecedented number of connections handled by the default routers (GGSN) in 3GPP networks, a network design that forces traffic to go through a single node at the edge of the network (typical NA(P)T-PT configuration) is not likely to scale. Translation mechanisms should allow for multiple translators, for load sharing and redundancy purposes. To minimize the problems associated with NA(P)T-PT, the following actions may be needed: 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 to IPv4" case). 2. Ensure (if possible) that NA(P)T-PT does not become a single point of failure. 3. Allow for load sharing between different translators. That is, it should be possible for different connections to go through different translators. Note that load sharing alone does not prevent NA(P)T-PT from becoming a single point of failure. JW: The idea of having this text in an Appendix is ok for me. BR, -Juha- From owner-v6ops@ops.ietf.org Mon Sep 22 10:03:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15218 for ; Mon, 22 Sep 2003 10:03:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1RH4-000A3x-SB for v6ops-data@psg.com; Mon, 22 Sep 2003 14:02:46 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A1RGZ-000A1d-6f for v6ops@ops.ietf.org; Mon, 22 Sep 2003 14:02:15 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8ME2Dt11118 for ; Mon, 22 Sep 2003 17:02:13 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Sep 2003 17:02:12 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 22 Sep 2003 17:02:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: editorial issues Date: Mon, 22 Sep 2003 17:00:07 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F01907886@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: editorial issues Thread-Index: AcOA/Q15wsasnQQiQ4KavJv+RqcJbAAFCUAw From: To: Cc: X-OriginalArrivalTime: 22 Sep 2003 14:02:12.0657 (UTC) FILETIME=[1F08CA10:01C38112] X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi again! -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 22 September, 2003 14:31 > JW: Another alternative is to write this text in 2.4 with lower case = (question:=20 > Informational docs do not use capitalized keywords, but how is it in = BCP docs?) > If that text will stay here in capital letters, I can add terminology = part. BCP could have upper caps (as well as specific kinds of informational=20 documents). The problem here is that you're quoting directly what it = says=20 in the DNStrans document. So, changing it in this document might not be = appropriate. So, I think there may be three ways around this issue: - define RFC2026 keywords, - just convert the uppercases to lowercases, or - in section 2.4, state it more clearly that the recommendations have=20 been copied verbatim from DNStrans (which might imply that DNStrans is = the=20 authorative source here, not the uppercases in this document) JW: Hmm, I might select the third alternative... > 7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt > 8. Intellectual Property Statement > 9. Copyright >=20 > =3D=3D> these sections could be after the Editor's contact information = section, > but that isn't really set in stone. >=20 > JW: Looking at v6ops and other wg drafts, there seems not to be a > common practice.. Until you can show me a clear rule, I will keep the = order > as it is now - and let RFC editor make the needed changes. :-) There is no strict rule of this, but ID-nits lists these in that order=20 (and in most cases, that's what seems to make the most sense to me,=20 because those are sections that will be either removed at publication or = stay the same across all I-Ds): http://www.ietf.org/ID-nits.html JW: Fine, I will use ID-nits as the reference and make the section = order=20 based on it. BR, -Juha W.- From owner-v6ops@ops.ietf.org Mon Sep 22 10:33:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17823 for ; Mon, 22 Sep 2003 10:33:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1Ri6-000CB0-Lb for v6ops-data@psg.com; Mon, 22 Sep 2003 14:30:42 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A1Rhy-000CAS-9T for v6ops@ops.ietf.org; Mon, 22 Sep 2003 14:30:34 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8MEUV31009820; Mon, 22 Sep 2003 16:30:32 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 22 Sep 2003 16:32:47 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F037682FB@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'juha.wiljakka@nokia.com'" , pekkas@netcore.fi, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Date: Mon, 22 Sep 2003 16:30:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_20,MSG_ID_ADDED_BY_MTA_3,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk I have some comments: 1) Why change "IGP/EGP" to "routing protocols"? It's clear enough with IGP/EGP 2) Proposed rewrite of second parag. "Routing protocols over IPv6 links" We've already discussed this thoroughly and there was no agreement that this would be an appropriate choice to solve the redundancy problem. This would mean recommending that an operator runs an IPv4 routing protocol and in addition an IPv6 routing protocol inside each tunnel. /Karim > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: den 22 september 2003 14:02 > To: pekkas@netcore.fi; v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > operator's network > > > > Hi! > > I don't personally have big problems with that suggested > text. If the other people > on the list do not object the text change, we could move > forward with this issue. > > Cheers, > -Juha- > > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 18 September, 2003 12:13 > To: v6ops@ops.ietf.org > Subject: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's > network > > > Hi, > > This is the previously-opened "Automatic tunneling inside > 3GPP operator's > network" case again. > > substantial > ----------- > > The issues I'm still not very confortable with: > > [note: sending the second one first, because the first requires some > editing yet..] > > 2) tunneling inside the 3GPP operator's network, in > particular, the last two > paragraphs of section 3.2.1: > > Even a dynamic tunneling mechanism or an IGP/EGP routing protocol > based tunneling mechanism can be considered if other methods are > not suitable. > > Connection redundancy should also be noted as an important > requirement in 3GPP networks. Static tunnels on their own don't > provide a routing recovery solution for all scenarios > where an IPv6 > route goes down. However, they may provide an adequate solution > depending on the design of the network and in presence of other > router redundancy mechanisms. On the other hand, IGP/EGP based > mechanisms can provide redundancy. > > ==> at least, remove "IGP/EGP" (it's enough to say a routing > protocol), and > rewrite the last paragraph like: > > Connection redundancy should also be noted as an important > requirement in 3GPP networks. Static tunnels on their own don't > provide a routing recovery solution for all scenarios > where an IPv6 > route goes down. However, they may provide an adequate solution > depending on the design of the network and in presence of other > router redundancy mechanisms, such as routing protocols > run over IPv6 > links. > > .. because "router redundancy mechanisms" is too vague, and > IGP/EGP based > mechanisms are routing protocols themselves and already > included in that > context. > > I'm not sure if these two edits would fix all my concerns with the > document, but with these two, it would be much better already. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-v6ops@ops.ietf.org Mon Sep 22 10:45:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18527 for ; Mon, 22 Sep 2003 10:45:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1Ruh-000DMU-5q for v6ops-data@psg.com; Mon, 22 Sep 2003 14:43:43 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A1RuZ-000DLi-40 for v6ops@ops.ietf.org; Mon, 22 Sep 2003 14:43:35 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8MEhW31014104; Mon, 22 Sep 2003 16:43:32 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 22 Sep 2003 16:45:48 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F037682FC@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'juha.wiljakka@nokia.com'" , pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Mon, 22 Sep 2003 16:43:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=BAYES_30,MSG_ID_ADDED_BY_MTA_3,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > 2.1 Dual Stack > > The dual IPv4/IPv6 stack is specified in [RFC2893]. If > we consider > the 3GPP GPRS core network, dual stack implementation in the GGSN > enables support for IPv4 and IPv6 PDP contexts. UEs with > dual stack > and public (global) IP addresses can often access both IPv4 and > IPv6 services without additional translators in the network. > > ==> I fail to see why public (global) IP addresses are a > requirement here? > Can't one with a private address also access IPv4 services, > possibly with > some difficulties, yes, but still in principle.. > > JW: Maybe public/global addresses need not be mentioned here. I just > wrote it because the ideal case would be to have > public/global addresses. > I could add a sentence clarifying that if UEs need to be > contacted (e.g. > thinking peer-to-peer services), public/global addresses > would be needed / > preferred. The meaning I infer is that if the v4 address is not public and you need to talk v4 hosts outside your private domain then you go through one or more NATs. NAT is considered an "additional translator" above. > As a general guideline, IPv6 communication (native or > tunneled from > the UE) is preferred to IPv4 communication going through > IPv4 NATs > to the same dual stack peer node. > > ==> I think this is in conflict with the text already > written earlier in > this section. I suggest: > > As a general guideline, native IPv6 communication > is preferred to IPv4 communication going through IPv4 NATs > to the same dual stack peer node. > > JW: I don't have any complaints. This changes the meaning of the text so I don't agree. It is meant to say that using IPv6 is preferred (to IPv4 through NATs), be it native connectivity or tunneled. /Karim From owner-v6ops@ops.ietf.org Mon Sep 22 11:14:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19857 for ; Mon, 22 Sep 2003 11:14:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1SHU-000FdV-UI for v6ops-data@psg.com; Mon, 22 Sep 2003 15:07:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A1SGw-000Fah-Dn for v6ops@ops.ietf.org; Mon, 22 Sep 2003 15:06:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8MF5dD26736; Mon, 22 Sep 2003 18:05:39 +0300 Date: Mon, 22 Sep 2003 18:05:39 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: "'juha.wiljakka@nokia.com'" , Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F037682FB@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 22 Sep 2003, Karim El-Malki (HF/EAB) wrote: > 1) Why change "IGP/EGP" to "routing protocols"? > It's clear enough with IGP/EGP Note it was "IGP/EGP routing protocols" AFAIR. Routing protocols are all either IGP or EGP. There is no need to spell out the difference. > 2) Proposed rewrite of second parag. > "Routing protocols over IPv6 links" > We've already discussed this thoroughly > and there was no agreement that this > would be an appropriate choice to > solve the redundancy problem. One could also characterize this that there was no agreement that this is needed for redundancy. > This would > mean recommending that an operator runs > an IPv4 routing protocol and in addition > an IPv6 routing protocol inside each tunnel. Which is operationally Just Fine! :-) > > -----Original Message----- > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > > Sent: den 22 september 2003 14:02 > > To: pekkas@netcore.fi; v6ops@ops.ietf.org > > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > > operator's network > > > > > > > > Hi! > > > > I don't personally have big problems with that suggested > > text. If the other people > > on the list do not object the text change, we could move > > forward with this issue. > > > > Cheers, > > -Juha- > > > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 18 September, 2003 12:13 > > To: v6ops@ops.ietf.org > > Subject: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's > > network > > > > > > Hi, > > > > This is the previously-opened "Automatic tunneling inside > > 3GPP operator's > > network" case again. > > > > substantial > > ----------- > > > > The issues I'm still not very confortable with: > > > > [note: sending the second one first, because the first requires some > > editing yet..] > > > > 2) tunneling inside the 3GPP operator's network, in > > particular, the last two > > paragraphs of section 3.2.1: > > > > Even a dynamic tunneling mechanism or an IGP/EGP routing protocol > > based tunneling mechanism can be considered if other methods are > > not suitable. > > > > Connection redundancy should also be noted as an important > > requirement in 3GPP networks. Static tunnels on their own don't > > provide a routing recovery solution for all scenarios > > where an IPv6 > > route goes down. However, they may provide an adequate solution > > depending on the design of the network and in presence of other > > router redundancy mechanisms. On the other hand, IGP/EGP based > > mechanisms can provide redundancy. > > > > ==> at least, remove "IGP/EGP" (it's enough to say a routing > > protocol), and > > rewrite the last paragraph like: > > > > Connection redundancy should also be noted as an important > > requirement in 3GPP networks. Static tunnels on their own don't > > provide a routing recovery solution for all scenarios > > where an IPv6 > > route goes down. However, they may provide an adequate solution > > depending on the design of the network and in presence of other > > router redundancy mechanisms, such as routing protocols > > run over IPv6 > > links. > > > > .. because "router redundancy mechanisms" is too vague, and > > IGP/EGP based > > mechanisms are routing protocols themselves and already > > included in that > > context. > > > > I'm not sure if these two edits would fix all my concerns with the > > document, but with these two, it would be much better already. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 22 11:38:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20971 for ; Mon, 22 Sep 2003 11:38:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1SjQ-000IMQ-0H for v6ops-data@psg.com; Mon, 22 Sep 2003 15:36:08 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A1SYQ-000HHu-Jx for v6ops@ops.ietf.org; Mon, 22 Sep 2003 15:24:46 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8MFOi31024791; Mon, 22 Sep 2003 17:24:44 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 22 Sep 2003 17:27:00 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F037682FE@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'juha.wiljakka@nokia.com'" , pekkas@netcore.fi, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node Date: Mon, 22 Sep 2003 17:24:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=BAYES_30,MSG_ID_ADDED_BY_MTA_3,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > First, a couple of points of discussion: > > - If UE is IPv6-only, and you hook up an IPv4 (or > dual-stack) laptop to > the UE, would you be able to use IPv4 through the UE (using > separate PDP > context)? > - Is there something why this would be undesirable (double > billing with > two PDP contexts?) > > JW: Hmm...that depends on the fact whether IPv4 dial-up is supported > in the UE, i.e. that means PPP(v4) support and it must be possible to > set up a PDP context for PC dial-up... If we strictly talk > about IPv6- > only UE, maybe that is not possible, but it depends on the > implementation. I'd say that if the UE is really IPv6-only (i.e. only IPv6 PDP Contexts are supported) then you can't simply hook up an IPv4-only laptop. That's unless something special happens in the UE that enables it to take in IPv4 packets and throw out IPv6 packets... > > What I'm trying to grasp at is this: if someone deploys > IPv6-only UE's, > for specific purposes only (e.g. making calls, browsing the > web), can we > expect that the user of the device does not require geneirc purpose > Internet connectivity (e.g. being able to connect to IPv4 address X, > protocol Y, port Z)? > > JW: Well...it seems that some level of IPv4 connectivity > will be needed for > quite a long time (even though I personally hope that the transition > to IPv6 would happen more rapidly). Anyway, making prognoses > is always > difficult. Agreed, and that's up to the complete solution chosen by the operator. If one really wanted it would be possible to get access to the required IPv4 services from an IPv6-only UE through app. proxies for example. > 3.4 IPv6 UE Connecting to an IPv4 Node > > The deployment of generic-purpose IPv6(-only) UEs is not > recommended until > the IPv6 deployment has become so prevalent that direct > communication with > IPv4(-only) nodes will no longer be necessary. > > Specific-purpose UEs, capable of doing only specific kinds > of tasks, are a > slightly different thing: it may be possible to make > assumptions on the > nodes and communication protocols they need to use. Then it may be > possible to deploy specialized IPv6(-only) equipment because > it's known > that they do not need to reach an IPv4(-only) nodes except using very > specific applications and methods -- and in that case, it is > possible to > use specific translation and proxying techniques, not generic > translation. Pekka, as Juha menitoned, you are drawing a line between generic-purpose IPv6 UEs and specific purpose IPv6 UEs assuming this is a feasible way of labelling UE products. Not sure we can make such a distinction at this point. It may be that all UEs will be in fact "specific purpose" in some way, so I don't see a gain in making this distinction. We could however point out the fact that IPv4 will remain useful for a long time, so in general dual-stack is the way to go if you don't know any better. I think this is a bit different from what is said above. /Karim From owner-v6ops@ops.ietf.org Mon Sep 22 11:59:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22191 for ; Mon, 22 Sep 2003 11:59:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1T38-000KD1-39 for v6ops-data@psg.com; Mon, 22 Sep 2003 15:56:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A1T2c-000K96-3m for v6ops@ops.ietf.org; Mon, 22 Sep 2003 15:55:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8MFssc27253; Mon, 22 Sep 2003 18:54:54 +0300 Date: Mon, 22 Sep 2003 18:54:54 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: "'juha.wiljakka@nokia.com'" , Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F037682FC@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 22 Sep 2003, Karim El-Malki (HF/EAB) wrote: > > 2.1 Dual Stack > > The dual IPv4/IPv6 stack is specified in [RFC2893]. If > > we consider > > the 3GPP GPRS core network, dual stack implementation in the GGSN > > enables support for IPv4 and IPv6 PDP contexts. UEs with > > dual stack > > and public (global) IP addresses can often access both IPv4 and > > IPv6 services without additional translators in the network. > > > > ==> I fail to see why public (global) IP addresses are a > > requirement here? > > Can't one with a private address also access IPv4 services, > > possibly with > > some difficulties, yes, but still in principle.. > > > > JW: Maybe public/global addresses need not be mentioned here. I just > > wrote it because the ideal case would be to have > > public/global addresses. > > I could add a sentence clarifying that if UEs need to be > > contacted (e.g. > > thinking peer-to-peer services), public/global addresses > > would be needed / > > preferred. > > The meaning I infer is that if the v4 address is not public and you need > to talk v4 hosts outside your private domain then you go through one or > more NATs. NAT is considered an "additional translator" above. Right.. I didn't think of NAT as an additional translator. In any case, a clarification will be needed. > > As a general guideline, IPv6 communication (native or > > tunneled from > > the UE) is preferred to IPv4 communication going through > > IPv4 NATs > > to the same dual stack peer node. > > > > ==> I think this is in conflict with the text already > > written earlier in > > this section. I suggest: > > > > As a general guideline, native IPv6 communication > > is preferred to IPv4 communication going through IPv4 NATs > > to the same dual stack peer node. > > > > JW: I don't have any complaints. > > This changes the meaning of the text so I don't agree. > It is meant to say that using IPv6 is preferred (to IPv4 > through NATs), be it native connectivity or tunneled. Yep, that's intentional. However, the only change of substance here is that the "tunneled IPv6 from the UE" has been pretty much killed from the document already. So, I think my text is better. One could of course just say "As a general guideline, IPv6 communication ....", i.e., kill "native" by making it a bit more general while not pointing out the not-so-relevant details. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 22 16:07:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07345 for ; Mon, 22 Sep 2003 16:07:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1Wwp-000DRE-9k for v6ops-data@psg.com; Mon, 22 Sep 2003 20:06:15 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A1WwJ-000DOb-4E for v6ops@ops.ietf.org; Mon, 22 Sep 2003 20:05:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8MK4eL31797; Mon, 22 Sep 2003 23:04:41 +0300 Date: Mon, 22 Sep 2003 23:04:40 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CDEDD@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Comments to a couple of remaining points only.. On Mon, 22 Sep 2003 juha.wiljakka@nokia.com wrote: > JW: I think that a general recommendation for dual stack UEs in the > near future is a rational one. At least that seems to be the natural > step after IPv4-only UEs. But we should also encourage manufacturers > to make dual stack UEs instead of v4-only UEs! :-) Right. > 2) the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 > TCP relay configured for a couple of ports only [TRT]) or application > proxies (e.g., HTTP proxy, SMTP relay) in the local network, or > > JW: How much do we have real life / implementation experience on TRT? It's implemented at least by *BSD and Linux; keywords: faithd, pTRTd, (totd -- not really needed in this context): http://www.freebsd.org/cgi/man.cgi?query=faith http://v6web.litech.org/ptrtd/ http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html We've used it extensively on BSD for many years; it has been used at IETFs (though not for this specific purpose) some time ago repeatedly, etc. This is certainly not the only way to do it though. Realistically, the real life experience may be a bit lacking (I haven't heard of much bad news) -- or it could be that it just plain Works :-) Definitely something worth exploring a bit more, I think. > 3) the use of specific-purpose mechanisms (as described above in 2) in > the foreign network; these are indistinguishable from the IPv6-enabled > services from the IPv6 UE's perspective, and is not discussed further > here. > > The use of generic-purpose translators (such as NAT-PT) is not recommended > [NATPTappl]; appendix A lists some 3GPP-specific issues related to the use > of translators. > > JW: In my opinion, NATPTappl will have an important task explaining why you > don't want to encourage people using NAT-PT as a generic > transition mechanism. Right.. > I haven't fully understood the big picture. With dual > stack (and IPv4) we usually have to use v4-NATs anyway. But those are an *IPv4* problem. IPv6 is supposed to be better ;-) > Just a question: if I say > that the evilness of NA(P)T is X, how evil would you then say NA(P)T-PT is (compared > to X)? A good question. My view on this: if we transfer the evils of NA(P)T to NA(P)T-PT and, moreover, advocate its use, we've actually done a *lot* more evil than just bearing with current evils, i.e. those we know of NAT. That is, we'd be propagating the evils of NAT into IPv6. That seems short-sighted, even though it could be seen as one way to move to IPv6-only networks fast. IMHO, it's much, much better to insist on "untainted" IPv6. Else we'll be back in square 1 before too long.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 22 16:23:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08635 for ; Mon, 22 Sep 2003 16:23:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1WZz-000BRy-Db for v6ops-data@psg.com; Mon, 22 Sep 2003 19:42:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A1WZS-000BQ0-Oc for v6ops@ops.ietf.org; Mon, 22 Sep 2003 19:42:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8MJf3n31408; Mon, 22 Sep 2003 22:41:03 +0300 Date: Mon, 22 Sep 2003 22:41:03 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: "'juha.wiljakka@nokia.com'" , Subject: RE: 3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F037682FE@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 22 Sep 2003, Karim El-Malki (HF/EAB) wrote: [...] > > 3.4 IPv6 UE Connecting to an IPv4 Node > > > > The deployment of generic-purpose IPv6(-only) UEs is not > > recommended until > > the IPv6 deployment has become so prevalent that direct > > communication with > > IPv4(-only) nodes will no longer be necessary. > > > > Specific-purpose UEs, capable of doing only specific kinds > > of tasks, are a > > slightly different thing: it may be possible to make > > assumptions on the > > nodes and communication protocols they need to use. Then it may be > > possible to deploy specialized IPv6(-only) equipment because > > it's known > > that they do not need to reach an IPv4(-only) nodes except using very > > specific applications and methods -- and in that case, it is > > possible to > > use specific translation and proxying techniques, not generic > > translation. > > Pekka, as Juha menitoned, you are drawing a line between generic-purpose > IPv6 UEs and specific purpose IPv6 UEs assuming this is a feasible way of > labelling UE products. Not sure we can make such a distinction at this point. Right .. but I see no usable labeling mechanism. > It may be that all UEs will be in fact "specific purpose" in some way, so > I don't see a gain in making this distinction. But if they're generic purpose in some other ways, they're generic purpose overall, leading to certain recommendations. I certainly see that labeling products like this is not easy, but that seems to be about the only way to describe the distinction of how to perform access from ipv6-only systems to ipv4. > We could however point out > the fact that IPv4 will remain useful for a long time, so in general > dual-stack is the way to go if you don't know any better. I think this > is a bit different from what is said above. Depending on what kind of text this would result in, this might also be OK. I don't quickly see how that would be singinificantly less of a rat-hole... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Sep 24 09:34:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13603 for ; Wed, 24 Sep 2003 09:34:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A29a1-0007dS-At for v6ops-data@psg.com; Wed, 24 Sep 2003 13:21:17 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A29Z7-0007Z7-Ap for v6ops@ops.ietf.org; Wed, 24 Sep 2003 13:20:21 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8ODKEt16165 for ; Wed, 24 Sep 2003 16:20:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 16:20:14 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 16:20:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Date: Wed, 24 Sep 2003 16:17:33 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F019078BB@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Thread-Index: AcOBGv7oYiCvBNorTKKOH+HjOKhIDQBgm4ww From: To: , Cc: X-OriginalArrivalTime: 24 Sep 2003 13:20:14.0245 (UTC) FILETIME=[96C51D50:01C3829E] X-Spam-Status: No, hits=-0.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Karim (and Pekka)! Just asking your final comments and preferences considering these two = points raised up by Karim. Karim, can you make text suggestion(s) for = 3.2.1, if you feel those are needed!? (I'm currently editing revision -06, and I hope I can publish it on = Thursday/Friday this week). Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 22 September, 2003 18:06 To: Karim El-Malki (HF/EAB) Cc: Wiljakka Juha (NMP/Tampere); v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network On Mon, 22 Sep 2003, Karim El-Malki (HF/EAB) wrote: > 1) Why change "IGP/EGP" to "routing protocols"? > It's clear enough with IGP/EGP Note it was "IGP/EGP routing protocols" AFAIR. Routing protocols are all either IGP or EGP. There is no need to spell=20 out the difference. > 2) Proposed rewrite of second parag. > "Routing protocols over IPv6 links" > We've already discussed this thoroughly > and there was no agreement that this > would be an appropriate choice to > solve the redundancy problem.=20 One could also characterize this that there was no agreement that this = is=20 needed for redundancy. > This would > mean recommending that an operator runs > an IPv4 routing protocol and in addition > an IPv6 routing protocol inside each tunnel. Which is operationally Just Fine! :-) > > -----Original Message----- > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > > Sent: den 22 september 2003 14:02 > > To: pekkas@netcore.fi; v6ops@ops.ietf.org > > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > > operator's network > >=20 > >=20 > >=20 > > Hi! > >=20 > > I don't personally have big problems with that suggested=20 > > text. If the other people > > on the list do not object the text change, we could move=20 > > forward with this issue. > >=20 > > Cheers, > > -Juha- > >=20 > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 18 September, 2003 12:13 > > To: v6ops@ops.ietf.org > > Subject: 3gpp-analysis-05: Automatic tunneling inside 3GPP = operator's > > network > >=20 > >=20 > > Hi, > >=20 > > This is the previously-opened "Automatic tunneling inside=20 > > 3GPP operator's=20 > > network" case again. > >=20 > > substantial > > ----------- > >=20 > > The issues I'm still not very confortable with: > >=20 > > [note: sending the second one first, because the first requires = some=20 > > editing yet..] > >=20 > > 2) tunneling inside the 3GPP operator's network, in=20 > > particular, the last two > > paragraphs of section 3.2.1: > >=20 > > Even a dynamic tunneling mechanism or an IGP/EGP routing = protocol > > based tunneling mechanism can be considered if other methods = are > > not suitable. > >=20 > > Connection redundancy should also be noted as an important > > requirement in 3GPP networks. Static tunnels on their own don't > > provide a routing recovery solution for all scenarios=20 > > where an IPv6 > > route goes down. However, they may provide an adequate solution > > depending on the design of the network and in presence of other > > router redundancy mechanisms. On the other hand, IGP/EGP based > > mechanisms can provide redundancy. > >=20 > > =3D=3D> at least, remove "IGP/EGP" (it's enough to say a routing=20 > > protocol), and > > rewrite the last paragraph like: > >=20 > > Connection redundancy should also be noted as an important > > requirement in 3GPP networks. Static tunnels on their own don't > > provide a routing recovery solution for all scenarios=20 > > where an IPv6 > > route goes down. However, they may provide an adequate solution > > depending on the design of the network and in presence of other > > router redundancy mechanisms, such as routing protocols=20 > > run over IPv6=20 > > links. > >=20 > > .. because "router redundancy mechanisms" is too vague, and=20 > > IGP/EGP based > > mechanisms are routing protocols themselves and already=20 > > included in that=20 > > context. > >=20 > > I'm not sure if these two edits would fix all my concerns with the=20 > > document, but with these two, it would be much better already. > >=20 > > --=20 > > Pekka Savola "You each name yourselves king, yet = the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of = Kings > >=20 > >=20 > >=20 >=20 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Sep 24 11:13:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21366 for ; Wed, 24 Sep 2003 11:13:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2BFV-000Ezb-Jx for v6ops-data@psg.com; Wed, 24 Sep 2003 15:08:13 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A2BEj-000Ewn-UN for v6ops@ops.ietf.org; Wed, 24 Sep 2003 15:07:26 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OF7O606518 for ; Wed, 24 Sep 2003 18:07:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 18:07:23 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 18:07:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Wed, 24 Sep 2003 18:07:23 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDEF4@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: miscellaneous non-critical issues Thread-Index: AcOBId7UBWGaehprTt+X4pAJ0URV8gBh/SkQ From: To: , Cc: X-OriginalArrivalTime: 24 Sep 2003 15:07:23.0584 (UTC) FILETIME=[8EF46400:01C382AD] X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Karim and Pekka! I think we are pretty close resolving also this issue... Minor comments = (JW) below: -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 22 September, 2003 18:55 > > =3D=3D> I fail to see why public (global) IP addresses are a=20 > > requirement here?=20 > > Can't one with a private address also access IPv4 services,=20 > > possibly with > > some difficulties, yes, but still in principle.. > >=20 > > JW: Maybe public/global addresses need not be mentioned here. I = just > > wrote it because the ideal case would be to have=20 > > public/global addresses. > > I could add a sentence clarifying that if UEs need to be=20 > > contacted (e.g.=20 > > thinking peer-to-peer services), public/global addresses=20 > > would be needed / > > preferred. >=20 > The meaning I infer is that if the v4 address is not public and you = need > to talk v4 hosts outside your private domain then you go through one = or > more NATs. NAT is considered an "additional translator" above. Right.. I didn't think of NAT as an additional translator. In any case, = a=20 clarification will be needed. JW: That is a good point, because NAT *is* a translator (NAT-PT is not = the=20 only evil translator :), I will modify text according to this comment = and also=20 mention the peer-to-peer / node reachability case I already commented=20 above. > > =3D=3D> I think this is in conflict with the text already=20 > > written earlier in > > this section. I suggest: > >=20 > > As a general guideline, native IPv6 communication > > is preferred to IPv4 communication going through IPv4 NATs > > to the same dual stack peer node. > >=20 > > JW: I don't have any complaints. >=20 > This changes the meaning of the text so I don't agree. > It is meant to say that using IPv6 is preferred (to IPv4 > through NATs), be it native connectivity or tunneled. Yep, that's intentional. However, the only change of substance here is=20 that the "tunneled IPv6 from the UE" has been pretty much killed from = the=20 document already. So, I think my text is better. One could of course just say "As a = general=20 guideline, IPv6 communication ....", i.e., kill "native" by making it a=20 bit more general while not pointing out the not-so-relevant details. JW:=20 =3D> can we agree on Pekka's suggestion and just remove "native" from Pekka's text? Cheers, -Juha- From owner-v6ops@ops.ietf.org Wed Sep 24 11:14:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21394 for ; Wed, 24 Sep 2003 11:14:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2BJz-000FHo-Li for v6ops-data@psg.com; Wed, 24 Sep 2003 15:12:51 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A2BJU-000FF2-9q for v6ops@ops.ietf.org; Wed, 24 Sep 2003 15:12:20 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OFCJ611707 for ; Wed, 24 Sep 2003 18:12:19 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Sep 2003 18:12:18 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 18:12:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Wed, 24 Sep 2003 18:12:17 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDEF4@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: miscellaneous non-critical issues Thread-Index: AcOBId7UBWGaehprTt+X4pAJ0URV8gBh/SkQ From: To: , Cc: X-OriginalArrivalTime: 24 Sep 2003 15:12:17.0805 (UTC) FILETIME=[3E52F3D0:01C382AE] X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Karim and Pekka! I think we are pretty close resolving also this issue... Minor comments = (JW) below: -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 22 September, 2003 18:55 > > =3D=3D> I fail to see why public (global) IP addresses are a=20 > > requirement here?=20 > > Can't one with a private address also access IPv4 services,=20 > > possibly with > > some difficulties, yes, but still in principle.. > >=20 > > JW: Maybe public/global addresses need not be mentioned here. I = just > > wrote it because the ideal case would be to have=20 > > public/global addresses. > > I could add a sentence clarifying that if UEs need to be=20 > > contacted (e.g.=20 > > thinking peer-to-peer services), public/global addresses=20 > > would be needed / > > preferred. >=20 > The meaning I infer is that if the v4 address is not public and you = need > to talk v4 hosts outside your private domain then you go through one = or > more NATs. NAT is considered an "additional translator" above. Right.. I didn't think of NAT as an additional translator. In any case, = a=20 clarification will be needed. JW: That is a good point, because NAT *is* a translator (NAT-PT is not = the=20 only evil translator :), I will modify text according to this comment = and also=20 mention the peer-to-peer / node reachability case I already commented=20 above. > > =3D=3D> I think this is in conflict with the text already=20 > > written earlier in > > this section. I suggest: > >=20 > > As a general guideline, native IPv6 communication > > is preferred to IPv4 communication going through IPv4 NATs > > to the same dual stack peer node. > >=20 > > JW: I don't have any complaints. >=20 > This changes the meaning of the text so I don't agree. > It is meant to say that using IPv6 is preferred (to IPv4 > through NATs), be it native connectivity or tunneled. Yep, that's intentional. However, the only change of substance here is=20 that the "tunneled IPv6 from the UE" has been pretty much killed from = the=20 document already. So, I think my text is better. One could of course just say "As a = general=20 guideline, IPv6 communication ....", i.e., kill "native" by making it a=20 bit more general while not pointing out the not-so-relevant details. JW:=20 =3D> can we agree on Pekka's suggestion and just remove "native" from Pekka's text? Cheers, -Juha- From owner-v6ops@ops.ietf.org Thu Sep 25 12:01:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02257 for ; Thu, 25 Sep 2003 12:01:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2YMP-00079T-A7 for v6ops-data@psg.com; Thu, 25 Sep 2003 15:48:53 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A2YLs-0006zA-S4 for v6ops@ops.ietf.org; Thu, 25 Sep 2003 15:48:21 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8PFmJt19187 for ; Thu, 25 Sep 2003 18:48:19 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Sep 2003 18:48:18 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 25 Sep 2003 18:48:18 +0300 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 25 Sep 2003 18:48:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Preparing for Minneapolis Date: Thu, 25 Sep 2003 18:48:17 +0300 Message-ID: <2D3EB51EAED985419D54AB340A9D019549AC9B@esebe024.ntc.nokia.com> Thread-Topic: Preparing for Minneapolis Thread-Index: AcODfG+wAd/clZSuQHGYriTm7R4gQA== From: To: Cc: , X-OriginalArrivalTime: 25 Sep 2003 15:48:18.0072 (UTC) FILETIME=[705B4980:01C3837C] X-Spam-Status: No, hits=1.1 required=5.0 tests=NO_REAL_NAME version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello v6ops WG, we are starting to put together the agenda for the Minneapolis IETF = meeting. We have to get the agenda done relatively soon to get the right = time allocated for our meeting. To be enable to do the right estimate for our f-2-f time in Minneapolis, = we would ask the people wishing to present something in Minneapolis to = get in touch with us quite soon. Our current time estimate is one 2,5 = hour slot. It would be good to know if this estimate is correct. Cheers, Jonne. -------- Jonne Soininen Nokia Tel. +358 40 527 4634 Email: jonne.soininen@nokia.com=20 From owner-v6ops@ops.ietf.org Fri Sep 26 10:26:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08273 for ; Fri, 26 Sep 2003 10:26:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2tRO-000H88-5v for v6ops-data@psg.com; Fri, 26 Sep 2003 14:19:26 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A2tQs-000H3z-OV for v6ops@ops.ietf.org; Fri, 26 Sep 2003 14:18:54 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8QEIq31029409; Fri, 26 Sep 2003 16:18:52 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 26 Sep 2003 16:21:24 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F040A7626@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: juha.wiljakka@nokia.com, pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Fri, 26 Sep 2003 16:18:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=BAYES_30,MSG_ID_ADDED_BY_MTA_3,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > ==> I think this is in conflict with the text already > > > written earlier in > > > this section. I suggest: > > > > > > As a general guideline, native IPv6 communication > > > is preferred to IPv4 communication going through IPv4 NATs > > > to the same dual stack peer node. > > > > > > JW: I don't have any complaints. > > > > This changes the meaning of the text so I don't agree. > > It is meant to say that using IPv6 is preferred (to IPv4 > > through NATs), be it native connectivity or tunneled. > > Yep, that's intentional. However, the only change of > substance here is > that the "tunneled IPv6 from the UE" has been pretty much > killed from the > document already. > > So, I think my text is better. One could of course just say > "As a general > guideline, IPv6 communication ....", i.e., kill "native" by > making it a > bit more general while not pointing out the not-so-relevant details. > > JW: > => can we agree on Pekka's suggestion and just remove > "native" from Pekka's text? Pekka's understanding was that we killed the "tunneled IPv6 part". I don't think that is what has been done in the document, since now it just specifies better when tunneling may be useful. Since we do talk about a case where tunnelling can be useful we should keep the sentence as is so that it mentions native and tunneled. It was written on purpose not to make it sound like it was only "native" that we were talking about by explicitly writing native or tunneled. /Karim From owner-v6ops@ops.ietf.org Fri Sep 26 11:08:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09988 for ; Fri, 26 Sep 2003 11:08:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2u9Z-000KvA-B4 for v6ops-data@psg.com; Fri, 26 Sep 2003 15:05:05 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A2u8f-000Kq5-74 for v6ops@ops.ietf.org; Fri, 26 Sep 2003 15:04:09 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8QF4331010690; Fri, 26 Sep 2003 17:04:07 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 26 Sep 2003 17:06:35 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F0376830C@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'juha.wiljakka@nokia.com'" , pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Date: Fri, 26 Sep 2003 17:03:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=BAYES_30,MSG_ID_ADDED_BY_MTA_3,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Sorry for the late reply, I'm not reading email often this week (nor the next). I don't think major changes are needed to 3.2.1. We could add the "routing protocol over tunnel" (suggested by Pekka) to the last paragraph: Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they may provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms. On the other hand, redundancy can be obtained by running IGP/EGP based tunneling mechanisms or by running an IPv6 routing protocol over the manually configured tunnels described previously. /Karim > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: den 24 september 2003 15:18 > To: pekkas@netcore.fi; Karim El-Malki (HF/EAB) > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > operator's network > > > Hi, Karim (and Pekka)! > > Just asking your final comments and preferences considering > these two points raised up by Karim. Karim, can you make > text suggestion(s) for 3.2.1, if you feel those are needed!? > > (I'm currently editing revision -06, and I hope I can > publish it on Thursday/Friday this week). > > Cheers, > -Juha- > > > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 22 September, 2003 18:06 > To: Karim El-Malki (HF/EAB) > Cc: Wiljakka Juha (NMP/Tampere); v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > operator's network > > > On Mon, 22 Sep 2003, Karim El-Malki (HF/EAB) wrote: > > 1) Why change "IGP/EGP" to "routing protocols"? > > It's clear enough with IGP/EGP > > Note it was "IGP/EGP routing protocols" AFAIR. > > Routing protocols are all either IGP or EGP. There is no > need to spell > out the difference. > > > 2) Proposed rewrite of second parag. > > "Routing protocols over IPv6 links" > > We've already discussed this thoroughly > > and there was no agreement that this > > would be an appropriate choice to > > solve the redundancy problem. > > One could also characterize this that there was no agreement > that this is > needed for redundancy. > > > This would > > mean recommending that an operator runs > > an IPv4 routing protocol and in addition > > an IPv6 routing protocol inside each tunnel. > > Which is operationally Just Fine! :-) > > > > -----Original Message----- > > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > > > Sent: den 22 september 2003 14:02 > > > To: pekkas@netcore.fi; v6ops@ops.ietf.org > > > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > > > operator's network > > > > > > > > > > > > Hi! > > > > > > I don't personally have big problems with that suggested > > > text. If the other people > > > on the list do not object the text change, we could move > > > forward with this issue. > > > > > > Cheers, > > > -Juha- > > > > > > -----Original Message----- > > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: 18 September, 2003 12:13 > > > To: v6ops@ops.ietf.org > > > Subject: 3gpp-analysis-05: Automatic tunneling inside > 3GPP operator's > > > network > > > > > > > > > Hi, > > > > > > This is the previously-opened "Automatic tunneling inside > > > 3GPP operator's > > > network" case again. > > > > > > substantial > > > ----------- > > > > > > The issues I'm still not very confortable with: > > > > > > [note: sending the second one first, because the first > requires some > > > editing yet..] > > > > > > 2) tunneling inside the 3GPP operator's network, in > > > particular, the last two > > > paragraphs of section 3.2.1: > > > > > > Even a dynamic tunneling mechanism or an IGP/EGP > routing protocol > > > based tunneling mechanism can be considered if > other methods are > > > not suitable. > > > > > > Connection redundancy should also be noted as an important > > > requirement in 3GPP networks. Static tunnels on > their own don't > > > provide a routing recovery solution for all scenarios > > > where an IPv6 > > > route goes down. However, they may provide an > adequate solution > > > depending on the design of the network and in > presence of other > > > router redundancy mechanisms. On the other hand, > IGP/EGP based > > > mechanisms can provide redundancy. > > > > > > ==> at least, remove "IGP/EGP" (it's enough to say a routing > > > protocol), and > > > rewrite the last paragraph like: > > > > > > Connection redundancy should also be noted as an important > > > requirement in 3GPP networks. Static tunnels on > their own don't > > > provide a routing recovery solution for all scenarios > > > where an IPv6 > > > route goes down. However, they may provide an > adequate solution > > > depending on the design of the network and in > presence of other > > > router redundancy mechanisms, such as routing protocols > > > run over IPv6 > > > links. > > > > > > .. because "router redundancy mechanisms" is too vague, and > > > IGP/EGP based > > > mechanisms are routing protocols themselves and already > > > included in that > > > context. > > > > > > I'm not sure if these two edits would fix all my > concerns with the > > > document, but with these two, it would be much better already. > > > > > > -- > > > Pekka Savola "You each name yourselves > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A > Clash of Kings > > > > > > > > > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Fri Sep 26 14:21:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16697 for ; Fri, 26 Sep 2003 14:21:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2x4T-000BO9-IG for v6ops-data@psg.com; Fri, 26 Sep 2003 18:12:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A2x4K-000BNe-Br for v6ops@ops.ietf.org; Fri, 26 Sep 2003 18:11:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8QIAgq32590; Fri, 26 Sep 2003 21:10:42 +0300 Date: Fri, 26 Sep 2003 21:10:41 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: juha.wiljakka@nokia.com, Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F040A7626@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 26 Sep 2003, Karim El-Malki (HF/EAB) wrote: > > JW: > > => can we agree on Pekka's suggestion and just remove > > "native" from Pekka's text? > > Pekka's understanding was that we killed the "tunneled IPv6 part". > I don't think that is what has been done in the document, since now it just > specifies better when tunneling may be useful. Since we do talk about > a case where tunnelling can be useful we should keep the sentence as is > so that it mentions native and tunneled. It was written on purpose not > to make it sound like it was only "native" that we were talking about > by explicitly writing native or tunneled. I'm not sure how you read that we're recommending tunneling (excerpt below *). That certainly isn't the intent. Perhaps it needs to be reworded to be more explicit. My point of removing "native or tunneled" is that because there should not be any (or close to any) tunneled connectivity (from the UE) in the first place, pointing it out here is irrelevant. *) However, the UE may attach to a 3GPP network, in which the Serving GPRS Support Node (SGSN), the GGSN and the Home Location Register (HLR) support IPv4 PDP contexts, but may not support IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6(- only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism. This might happen in very early phases of IPv6 deployment. To generally solve this problem (IPv6 not available in the 3GPP network), this document strongly recommends the 3GPP operators to deploy basic IPv6 support in their GPRS networks, which can in most cases be handled by making software upgrades in the network elements. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Sep 26 14:32:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17146 for ; Fri, 26 Sep 2003 14:32:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2xMZ-000DAD-Tx for v6ops-data@psg.com; Fri, 26 Sep 2003 18:30:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A2xMQ-000D9W-4H for v6ops@ops.ietf.org; Fri, 26 Sep 2003 18:30:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8QITRP00446; Fri, 26 Sep 2003 21:29:27 +0300 Date: Fri, 26 Sep 2003 21:29:27 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: "'juha.wiljakka@nokia.com'" , Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F0376830C@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 26 Sep 2003, Karim El-Malki (HF/EAB) wrote: > Sorry for the late reply, I'm not reading email often this week > (nor the next). I don't think major changes are needed to 3.2.1. > We could add the "routing protocol over tunnel" (suggested by Pekka) > to the last paragraph: > > Connection redundancy should also be noted as an important > requirement in 3GPP networks. Static tunnels on their own don't > provide a routing recovery solution for all scenarios where an IPv6 > route goes down. However, they may provide an adequate solution > depending on the design of the network and in presence of other > router redundancy mechanisms. On the other hand, redundancy can > be obtained by running IGP/EGP based tunneling mechanisms or by > running an IPv6 routing protocol over the manually configured > tunnels described previously. I don't think this is OK. First of all, this overlaps with ISP work. From the ISP work, we can say for certainty that manual IPv6 tunnels and running an IPv6 routing protocol over them will be considered as good practice. After all, tunnel is just a link layer; you run IPv6 routing protocols over your native infrastructure -- there is zero difference here. I don't think there have been sufficient reasoning presented to say anything of IGP/EGP based mechanisms running over IPv4 networks in this context. As it is, I don't want to see any specific "marketing" here for IGP/EGP based mechanisms. We'll have to properly analyze it first. There have been no arguments which require it in this context, so the work should be done with ISP scenarios. Therefore, I'd really prefer to keep the current text to the basics, like: Connection redundancy should also be noted as an important requirement in 3GPP networks. Running an IPv6 routing protocol over static tunnels, as one would run IPv6 routing protocols over native infrastructure, provides a well-known routing recovery solution. and reword: Even a dynamic tunneling mechanism or an IGP/EGP routing protocol based tunneling mechanism can be considered if other methods are not suitable. to something like: Even a dynamic tunneling mechanism or a routing protocol based tunneling mechanism could be considered if other methods are not suitable. Whether this is really needed is to be analyzed at ISP scenarios/solutions work. When we get to the Last Call, I will plan to (in any case, whatever the outcome) list a few particularly controversial points to try to get more WG feedback on what it thinks the good approach here. However, it's (IMHO) better to be minimalistic from the start and expand if really necessary, as we should keep things simple (if not simpler). > > -----Original Message----- > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > > Sent: den 24 september 2003 15:18 > > To: pekkas@netcore.fi; Karim El-Malki (HF/EAB) > > Cc: v6ops@ops.ietf.org > > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > > operator's network > > > > > > Hi, Karim (and Pekka)! > > > > Just asking your final comments and preferences considering > > these two points raised up by Karim. Karim, can you make > > text suggestion(s) for 3.2.1, if you feel those are needed!? > > > > (I'm currently editing revision -06, and I hope I can > > publish it on Thursday/Friday this week). > > > > Cheers, > > -Juha- > > > > > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 22 September, 2003 18:06 > > To: Karim El-Malki (HF/EAB) > > Cc: Wiljakka Juha (NMP/Tampere); v6ops@ops.ietf.org > > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > > operator's network > > > > > > On Mon, 22 Sep 2003, Karim El-Malki (HF/EAB) wrote: > > > 1) Why change "IGP/EGP" to "routing protocols"? > > > It's clear enough with IGP/EGP > > > > Note it was "IGP/EGP routing protocols" AFAIR. > > > > Routing protocols are all either IGP or EGP. There is no > > need to spell > > out the difference. > > > > > 2) Proposed rewrite of second parag. > > > "Routing protocols over IPv6 links" > > > We've already discussed this thoroughly > > > and there was no agreement that this > > > would be an appropriate choice to > > > solve the redundancy problem. > > > > One could also characterize this that there was no agreement > > that this is > > needed for redundancy. > > > > > This would > > > mean recommending that an operator runs > > > an IPv4 routing protocol and in addition > > > an IPv6 routing protocol inside each tunnel. > > > > Which is operationally Just Fine! :-) > > > > > > -----Original Message----- > > > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > > > > Sent: den 22 september 2003 14:02 > > > > To: pekkas@netcore.fi; v6ops@ops.ietf.org > > > > Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP > > > > operator's network > > > > > > > > > > > > > > > > Hi! > > > > > > > > I don't personally have big problems with that suggested > > > > text. If the other people > > > > on the list do not object the text change, we could move > > > > forward with this issue. > > > > > > > > Cheers, > > > > -Juha- > > > > > > > > -----Original Message----- > > > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > > > Sent: 18 September, 2003 12:13 > > > > To: v6ops@ops.ietf.org > > > > Subject: 3gpp-analysis-05: Automatic tunneling inside > > 3GPP operator's > > > > network > > > > > > > > > > > > Hi, > > > > > > > > This is the previously-opened "Automatic tunneling inside > > > > 3GPP operator's > > > > network" case again. > > > > > > > > substantial > > > > ----------- > > > > > > > > The issues I'm still not very confortable with: > > > > > > > > [note: sending the second one first, because the first > > requires some > > > > editing yet..] > > > > > > > > 2) tunneling inside the 3GPP operator's network, in > > > > particular, the last two > > > > paragraphs of section 3.2.1: > > > > > > > > Even a dynamic tunneling mechanism or an IGP/EGP > > routing protocol > > > > based tunneling mechanism can be considered if > > other methods are > > > > not suitable. > > > > > > > > Connection redundancy should also be noted as an important > > > > requirement in 3GPP networks. Static tunnels on > > their own don't > > > > provide a routing recovery solution for all scenarios > > > > where an IPv6 > > > > route goes down. However, they may provide an > > adequate solution > > > > depending on the design of the network and in > > presence of other > > > > router redundancy mechanisms. On the other hand, > > IGP/EGP based > > > > mechanisms can provide redundancy. > > > > > > > > ==> at least, remove "IGP/EGP" (it's enough to say a routing > > > > protocol), and > > > > rewrite the last paragraph like: > > > > > > > > Connection redundancy should also be noted as an important > > > > requirement in 3GPP networks. Static tunnels on > > their own don't > > > > provide a routing recovery solution for all scenarios > > > > where an IPv6 > > > > route goes down. However, they may provide an > > adequate solution > > > > depending on the design of the network and in > > presence of other > > > > router redundancy mechanisms, such as routing protocols > > > > run over IPv6 > > > > links. > > > > > > > > .. because "router redundancy mechanisms" is too vague, and > > > > IGP/EGP based > > > > mechanisms are routing protocols themselves and already > > > > included in that > > > > context. > > > > > > > > I'm not sure if these two edits would fix all my > > concerns with the > > > > document, but with these two, it would be much better already. > > > > > > > > -- > > > > Pekka Savola "You each name yourselves > > king, yet the > > > > Netcore Oy kingdom bleeds." > > > > Systems. Networks. Security. -- George R.R. Martin: A > > Clash of Kings > > > > > > > > > > > > > > > > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Sep 28 01:37:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26106 for ; Sun, 28 Sep 2003 01:37:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3TyU-000C6m-DR for v6ops-data@psg.com; Sun, 28 Sep 2003 05:20:02 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A3Txq-000C3s-8U for v6ops@ops.ietf.org; Sun, 28 Sep 2003 05:19:22 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 28 Sep 2003 01:19:20 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D69@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , "Karim El-Malki (HF/EAB)" Cc: juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Sun, 28 Sep 2003 01:19:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Comments below. > *) > However, the UE may attach to a 3GPP network, in which > the Serving > GPRS Support Node (SGSN), the GGSN and the Home Location Register > (HLR) support IPv4 PDP contexts, but may not support IPv6 PDP > contexts. If the 3GPP network does not support IPv6 PDP contexts, > and an application on the UE needs to communicate with an IPv6(- > only) node, the UE may activate an IPv4 PDP context and > encapsulate > IPv6 packets in IPv4 packets using a tunneling mechanism. This > might happen in very early phases of IPv6 deployment. => Please remove this sentence. This is an opinion and does not apply to the roaming case where the home operator has deployed IPv6 but the visited operator didn't. To > generally > solve this problem (IPv6 not available in the 3GPP network), this > document strongly recommends the 3GPP operators to deploy basic > IPv6 support in their GPRS networks, => This does not apply to the roaming case, so it doesn't solve the problem stated above. which can in most cases be > handled by making software upgrades in the network elements. => Please remove this sentence, it's not clear whether this opinion (most cases) is based on "most products" or "most deployments". In any case, many products actually need some HW upgrade depending on how you define "IPv6 support". There is no need to add this to a draft. Hesham From owner-v6ops@ops.ietf.org Sun Sep 28 02:51:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09786 for ; Sun, 28 Sep 2003 02:51:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3VIB-000GfT-8G for v6ops-data@psg.com; Sun, 28 Sep 2003 06:44:27 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A3VHX-000GeW-Iq for v6ops@ops.ietf.org; Sun, 28 Sep 2003 06:43:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8S6ggQ31592; Sun, 28 Sep 2003 09:42:42 +0300 Date: Sun, 28 Sep 2003 09:42:41 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "Karim El-Malki (HF/EAB)" , , Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D69@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hesham, Do you have an alternate wording suggestion in mind which would keep the essence of the original text (including "don't tunnel from UE")? This doesn't and is unacceptable to me.. On Sun, 28 Sep 2003, Soliman Hesham wrote: > > *) > > However, the UE may attach to a 3GPP network, in which > > the Serving > > GPRS Support Node (SGSN), the GGSN and the Home Location Register > > (HLR) support IPv4 PDP contexts, but may not support IPv6 PDP > > contexts. If the 3GPP network does not support IPv6 PDP contexts, > > and an application on the UE needs to communicate with an IPv6(- > > only) node, the UE may activate an IPv4 PDP context and > > encapsulate > > IPv6 packets in IPv4 packets using a tunneling mechanism. > > This > > might happen in very early phases of IPv6 deployment. > > => Please remove this sentence. This is an opinion and does not > apply to the roaming case where the home operator has deployed > IPv6 but the visited operator didn't. > > To > > generally > > solve this problem (IPv6 not available in the 3GPP network), this > > document strongly recommends the 3GPP operators to deploy basic > > IPv6 support in their GPRS networks, > > => This does not apply to the roaming case, so it doesn't solve > the problem stated above. These are two quotes are intentional. IPv6 support will work when the visited networks also have upgraded to this minimal IPv6 support. That's also expected to happen during the early phases of transition. If the operator doesn't care about IPv6 users at all, the users can just stay out of those networks. We discussed previously several other options, such as trying to open the IPv6 PDP context to an operator (if there are many) which in fact supports IPv6. This would be useful in the case that 3G + IPv6 gains market momentum as there are typically multiple networks in a region one could roam to. I'm not sure how many of those ended up in the document. The bottom line is that as we deploy dual stack UE's, when IPv6 isn't supported in the visited network, one can just use IPv4 if all the tricks fail. No tunneling needed at the UE. Further, tunneling at the UE is counter-productive, as it doesn't give the *visited networks* _any_ incentive to deploy IPv6 in the first price, which is the number one priority. > which can in most cases be > > handled by making software upgrades in the network elements. > > => Please remove this sentence, it's not clear whether this opinion > (most cases) is based on "most products" or "most deployments". > In any case, many products actually need some HW upgrade depending > on how you define "IPv6 support". There is no need to add this > to a draft. > > Hesham > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Sep 28 04:44:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11713 for ; Sun, 28 Sep 2003 04:44:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3X1u-000MOi-IH for v6ops-data@psg.com; Sun, 28 Sep 2003 08:35:46 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A3X1m-000MOJ-Gy for v6ops@ops.ietf.org; Sun, 28 Sep 2003 08:35:38 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 28 Sep 2003 04:35:38 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D6A@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: "Karim El-Malki (HF/EAB)" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Sun, 28 Sep 2003 04:35:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Do you have an alternate wording suggestion in mind which > would keep the > essence of the original text (including "don't tunnel from > UE")? This > doesn't and is unacceptable to me.. => I didn't ask to have "don't tunnel from the UE" in the text. I was commenting on the new text. I don't think the draft should include opinions on how easy it is to upgrade to V6 and whether that involves SW or HW upgrades. It's not useful. My other comment is on the roaming case. Specific answer below. > > On Sun, 28 Sep 2003, Soliman Hesham wrote: > > > *) > > > However, the UE may attach to a 3GPP network, in which > > > the Serving > > > GPRS Support Node (SGSN), the GGSN and the Home > Location Register > > > (HLR) support IPv4 PDP contexts, but may not > support IPv6 PDP > > > contexts. If the 3GPP network does not support IPv6 > PDP contexts, > > > and an application on the UE needs to communicate > with an IPv6(- > > > only) node, the UE may activate an IPv4 PDP context and > > > encapsulate > > > IPv6 packets in IPv4 packets using a tunneling mechanism. > > > > This > > > might happen in very early phases of IPv6 deployment. > > > > => Please remove this sentence. This is an opinion and does not > > apply to the roaming case where the home operator has deployed > > IPv6 but the visited operator didn't. > > > > To > > > generally > > > solve this problem (IPv6 not available in the 3GPP > network), this > > > document strongly recommends the 3GPP operators to > deploy basic > > > IPv6 support in their GPRS networks, > > > > => This does not apply to the roaming case, so it doesn't solve > > the problem stated above. > > These are two quotes are intentional. IPv6 support will > work when the > visited networks also have upgraded to this minimal IPv6 > support. => (drifting from the original comment but I'll answer this as a side issue). Supporting PDP type V6 is not a minimal support because it implies that the network behind the SGSN supports v6, i.e. GGSN, DNS ...etc. That's > also expected to happen during the early phases of > transition. If the > operator doesn't care about IPv6 users at all, the users can > just stay out > of those networks. => The point is: Your operator cares about v6 and wants to offer you the services that IPv6 enables while you're roaming. It is not relevant how the visited operator feels about v6. So to work around this, you need to use something to enable you to tunnel to a router in the home network. IMO ISATAP fits nicely in this model. But the point is, requiring an operator to support v6 will not necessarily eliminate tunneling when the UE roams to another network (whose managers don't want to support v6 and will implement v6ops recommendations). > > We discussed previously several other options, such as > trying to open the > IPv6 PDP context to an operator (if there are many) which in > fact supports > IPv6. This would be useful in the case that 3G + IPv6 gains market > momentum as there are typically multiple networks in a > region one could > roam to. I'm not sure how many of those ended up in the document. > > The bottom line is that as we deploy dual stack UE's, when IPv6 isn't > supported in the visited network, one can just use IPv4 if > all the tricks > fail. => So , "other tricks" do not include tunneling? Why not? No tunneling needed at the UE. Further, tunneling at > the UE is > counter-productive, as it doesn't give the *visited networks* _any_ > incentive to deploy IPv6 in the first price, which is the number one > priority. => But in this case the visited network doesn't care about v6. I'm not sure how eliminating the use of V6 through a tunnel will give the visited network an incentive to deploy v6. Hesham From owner-v6ops@ops.ietf.org Mon Sep 29 05:22:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01762 for ; Mon, 29 Sep 2003 05:22:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3u0O-000E8N-Vt for v6ops-data@psg.com; Mon, 29 Sep 2003 09:07:44 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 1A3tzp-000E7j-HO for v6ops@ops.ietf.org; Mon, 29 Sep 2003 09:07:09 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id DA9D0803E; Mon, 29 Sep 2003 11:06:35 +0200 (CEST) From: "Jeroen Massar" To: , <6bone@ISI.EDU> Cc: Subject: Unallocated 2001:248::/32 announced by AS 7675 ? Date: Mon, 29 Sep 2003 11:06:37 +0200 Organization: Unfix Message-ID: <00b901c38668$fd8a35c0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Status: No, hits=-3.2 required=5.0 tests=BAYES_30,PGP_SIGNATURE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- inet6num: 2001:0200::/23 netname: APNIC-AP-ALLOCATED-PORTABLES1 descr: Asia Pacific Network Information Center, Pty. Ltd. descr: Regional Internet Registry for the Asia-Pacific Region This block is *NOT* allocated unless APNIC registry is out of sync: 2001:248::/32 3257 2497 2500 7660 9264 2012 7675 IGP 2001:248::/32 4589 2497 2500 7660 9264 2012 7675 IGP 2001:248::/32 15516 3257 2497 2500 7660 9264 2012 7675 IGP 2001:248::/32 25396 1752 6939 6939 9264 2012 7675 IGP 2001:248::/32 8954 4555 5609 9264 2012 7675 IGP 2001:248::/32 12337 3320 5609 9264 2012 7675 IGP 2001:248::/32 > 6939 6939 9264 2012 7675 IGP 2001:248::/32 12779 6175 6435 9264 2012 7675 IGP 2001:248::/32 12902 12859 8954 4555 5609 9264 2012 7675 IGP 2001:248::/32 25358 6175 6435 9264 2012 7675 IGP 2001:248::/32 8758 9044 513 9264 9264 2012 7675 IGP 2001:248::/32 12859 8954 4555 5609 9264 2012 7675 IGP 2001:248::/32 1888 1103 3425 293 6435 9264 2012 7675 IGP 2001:248::/32 8447 6830 4555 5609 9264 2012 7675 IGP 2001:248::/32 12634 3265 3549 6939 6939 9264 2012 7675 IGP 2001:248::/32 12871 8954 4555 5609 9264 2012 7675 IGP 2001:248::/32 1103 3425 293 6435 9264 2012 7675 whois -h whois.nic.ad.jp AS7675 reveals no useful informations though: Autonomous System Information: [ASESC$B>pJsESC(B] a. [ASESC$BHV9fESC(B] 7675 b. [ASESC$BL>ESC(B] ZEBRA f. [ESC$BAH?%L>ESC(B] (unknown) g. [Organization] Digital Magic Labs, Inc. m. [ESC$B1?MQ@UG$; Mon, 29 Sep 2003 05:46:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3uXe-000GPK-Pw for v6ops-data@psg.com; Mon, 29 Sep 2003 09:42:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A3uX8-000GLd-I9 for v6ops@ops.ietf.org; Mon, 29 Sep 2003 09:41:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8T9eIs17806; Mon, 29 Sep 2003 12:40:18 +0300 Date: Mon, 29 Sep 2003 12:40:18 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "Karim El-Malki (HF/EAB)" , , Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D6A@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 28 Sep 2003, Soliman Hesham wrote: > > Do you have an alternate wording suggestion in mind which > > would keep the > > essence of the original text (including "don't tunnel from > > UE")? This > > doesn't and is unacceptable to me.. > > => I didn't ask to have "don't tunnel from the UE" > in the text. I was commenting on the new text. > I don't think the draft should include opinions on how > easy it is to upgrade to V6 and whether that involves > SW or HW upgrades. It's not useful. It seems very useful to me, although the wording may not be optimal. If upgrading to v6 is relatively easy, we can recommend upgrading to IPv6. > > These are two quotes are intentional. IPv6 support will > > work when the > > visited networks also have upgraded to this minimal IPv6 > > support. > > => (drifting from the original comment but I'll answer > this as a side issue). Supporting PDP type V6 is not a > minimal support because it implies that the network behind > the SGSN supports v6, i.e. GGSN, DNS ...etc. When your network infrastructure includes hundreds of boxes, enabling v6 support in about 3 of them could be seen as very minimal. Note: I think it might be useful to try to describe in the document what constitutes a bare miminal IPv6 support.. just spell it out. DNS certainly is *not* required. > That's > > also expected to happen during the early phases of > > transition. If the > > operator doesn't care about IPv6 users at all, the users can > > just stay out > > of those networks. > > => The point is: Your operator cares about v6 and wants > to offer you the services that IPv6 enables Right so far.. > while you're > roaming. If your SP wants to enable services while you're roaming, your SP needs to convince those networks it has roaming agreements with to enable v6? > It is not relevant how the visited operator feels > about v6. I fear this is very relevant. Your home operator can't really offer what it can't provide. So, it should not *guarantee* you IPv6 services while you roam, as simple as that.. > So to work around this, you need to use something > to enable you to tunnel to a router in the home network. > IMO ISATAP fits nicely in this model. That's a detail at this point, but this is certainly at odds with the ISATAP security model. > But the point is, > requiring an operator to support v6 will not necessarily > eliminate tunneling when the UE roams to another network > (whose managers don't want to support v6 and will implement > v6ops recommendations). So, don't use v6 in those networks then? > > We discussed previously several other options, such as > > trying to open the > > IPv6 PDP context to an operator (if there are many) which in > > fact supports > > IPv6. This would be useful in the case that 3G + IPv6 gains market > > momentum as there are typically multiple networks in a > > region one could > > roam to. I'm not sure how many of those ended up in the document. > > > > The bottom line is that as we deploy dual stack UE's, when IPv6 isn't > > supported in the visited network, one can just use IPv4 if > > all the tricks > > fail. > > => So , "other tricks" do not include tunneling? Why not? That'd de-facto require implementation of a number of transition mechanisms in UE's, with caveats those entail, making it much more complex. > No tunneling needed at the UE. Further, tunneling at > > the UE is > > counter-productive, as it doesn't give the *visited networks* _any_ > > incentive to deploy IPv6 in the first price, which is the number one > > priority. > > => But in this case the visited network doesn't care about > v6. I'm not sure how eliminating the use of V6 through > a tunnel will give the visited network an incentive to > deploy v6. For example, if the customers select a different operator when they roam because the one they tried first doesn't support v6 ("v4-only operator loses customers and thus money"), I guess the operator which didn't support v6 would start to see some benefit in deploying v6 if the number of users warrants that. There could also be some PR gains/losses involved here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Sep 29 06:04:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02757 for ; Mon, 29 Sep 2003 06:04:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3uqh-000Huo-7q for v6ops-data@psg.com; Mon, 29 Sep 2003 10:01:47 +0000 Received: from [193.6.222.240] (helo=mignon.ki.iif.hu) by psg.com with esmtp (Exim 4.22) id 1A3uqA-000Htu-UI for v6ops@ops.ietf.org; Mon, 29 Sep 2003 10:01:15 +0000 Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id EB93E6F0F; Mon, 29 Sep 2003 12:01:13 +0200 (CEST) Received: from mignon.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14249-04-5; Mon, 29 Sep 2003 12:01:13 +0200 (CEST) Received: by mignon.ki.iif.hu (Postfix, from userid 1003) id 60A8D6E98; Mon, 29 Sep 2003 12:01:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id 5E8A76E96; Mon, 29 Sep 2003 12:01:13 +0200 (CEST) Date: Mon, 29 Sep 2003 12:01:13 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Jeroen Massar Cc: v6ops@ops.ietf.org, 6bone@ISI.EDU, bence@darmol.elte.hu Subject: Re: Unallocated 2001:248::/32 announced by AS 7675 ? In-Reply-To: <00b901c38668$fd8a35c0$210d640a@unfix.org> Message-ID: <20030929115840.F14054@mignon.ki.iif.hu> References: <00b901c38668$fd8a35c0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dear All, Forwarded your e-mail to Lajos Vonderviszt, who is the technical leader of ELTENET (AS2012). Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Mon, 29 Sep 2003, Jeroen Massar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > inet6num: 2001:0200::/23 > netname: APNIC-AP-ALLOCATED-PORTABLES1 > descr: Asia Pacific Network Information Center, Pty. Ltd. > descr: Regional Internet Registry for the Asia-Pacific Region > > This block is *NOT* allocated unless APNIC registry is out of sync: > > 2001:248::/32 3257 2497 2500 7660 9264 2012 7675 IGP > 2001:248::/32 4589 2497 2500 7660 9264 2012 7675 IGP > 2001:248::/32 15516 3257 2497 2500 7660 9264 2012 7675 IGP > 2001:248::/32 25396 1752 6939 6939 9264 2012 7675 IGP > 2001:248::/32 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 12337 3320 5609 9264 2012 7675 IGP > 2001:248::/32 > 6939 6939 9264 2012 7675 IGP > 2001:248::/32 12779 6175 6435 9264 2012 7675 IGP > 2001:248::/32 12902 12859 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 25358 6175 6435 9264 2012 7675 IGP > 2001:248::/32 8758 9044 513 9264 9264 2012 7675 IGP > 2001:248::/32 12859 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 1888 1103 3425 293 6435 9264 2012 7675 IGP > 2001:248::/32 8447 6830 4555 5609 9264 2012 7675 IGP > 2001:248::/32 12634 3265 3549 6939 6939 9264 2012 7675 IGP > 2001:248::/32 12871 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 1103 3425 293 6435 9264 2012 7675 > > whois -h whois.nic.ad.jp AS7675 reveals no useful informations though: > > Autonomous System Information: [ASESC$B>pJsESC(B] > a. [ASESC$BHV9fESC(B] 7675 > b. [ASESC$BL>ESC(B] ZEBRA > f. [ESC$BAH?%L>ESC(B] (unknown) > g. [Organization] Digital Magic Labs, Inc. > m. [ESC$B1?MQ@UG$ n. [ESC$B5;=QO"MmC4Ev o. [AS-IN] from AS4691 100 accept ANY > o. [AS-IN] from AS4682 100 accept ANY > o. [AS-IN] from AS7527 100 accept AS7527 > p. [AS-OUT] to AS4691 announce AS7675 > p. [AS-OUT] to AS4682 announce AS7675 > p. [AS-OUT] to AS7527 announce AS7675 > y. [ESC$BDLCN%"%I%l%9ESC(B] > [ESC$B3dEvG/7nF|ESC(B] 1998/04/27 > [ESC$BJV5QG/7nF|ESC(B] > [ESC$B:G=*99?7ESC(B] 1999/06/10 13:50:55 (JST) > ip-alloc@nic.ad.jp > > Anyone having a working contact for this? > > Sole "Upstream" is as2012 which is odd as that is hungary > which is kinda a far away land from japan. > > aut-num: AS2012 > as-name: UNSPECIFIED > descr: ELTENET > descr: Eotvos Lorand University of Sciences > descr: Budapest, Hungary > descr: HU > > First admin/tech contact (LV166-RIPE) doesn't have an email > address, second one cc'd. > > Greets, > Jeroen > > -----BEGIN PGP SIGNATURE----- > Version: Unfix PGP for Outlook Alpha 13 Int. > Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ > > iQA+AwUBP3f2HSmqKFIzPnwjEQKqcACfVudDSrYX0IpqciSXeDCsy5LykQwAliH/ > 6Ebw4ECX4VHi7W7+E/UOVj4= > =R9lS > -----END PGP SIGNATURE----- > > > From owner-v6ops@ops.ietf.org Mon Sep 29 06:10:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02927 for ; Mon, 29 Sep 2003 06:10:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3uxd-000IUi-9j for v6ops-data@psg.com; Mon, 29 Sep 2003 10:08:57 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 1A3uwz-000IRf-0A for v6ops@ops.ietf.org; Mon, 29 Sep 2003 10:08:17 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8BF11803E; Mon, 29 Sep 2003 12:07:44 +0200 (CEST) From: "Jeroen Massar" To: "'Mohacsi Janos'" Cc: , <6bone@ISI.EDU>, Subject: RE: Unallocated 2001:248::/32 announced by AS 7675 ? Date: Mon, 29 Sep 2003 12:07:47 +0200 Organization: Unfix Message-ID: <010c01c38671$88f7bf30$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20030929115840.F14054@mignon.ki.iif.hu> Importance: Normal X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Mohacsi Janos [mailto:mohacsi@niif.hu] wrote: > Dear All, > Forwarded your e-mail to Lajos Vonderviszt, who is the technical > leader of ELTENET (AS2012). Who is the one without the email address in the RIPE registry: person: Lajos Vonderviszt address: Eotvos Lorand University of Sciences address: Center of Information Technologies address: Muzeum krt. 4/C address: H-1088 Budapest address: Hungary phone: +36 1 2670820 ext. 2842 phone: +36 30 561312 fax-no: +36 1 2668576 nic-hdl: LV166-RIPE changed: gaga@caesar.elte.hu 19971002 source: RIPE If he could update that it would have saved a forward and searching google etc for his email address. Greets, Jeroen > On Mon, 29 Sep 2003, Jeroen Massar wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > inet6num: 2001:0200::/23 > > netname: APNIC-AP-ALLOCATED-PORTABLES1 > > descr: Asia Pacific Network Information Center, Pty. Ltd. > > descr: Regional Internet Registry for the Asia-Pacific Region > > > > This block is *NOT* allocated unless APNIC registry is out of sync: > > > > 2001:248::/32 3257 2497 2500 7660 9264 2012 7675 IGP > > 2001:248::/32 4589 2497 2500 7660 9264 2012 7675 IGP > > 2001:248::/32 15516 3257 2497 2500 7660 9264 2012 7675 IGP > > 2001:248::/32 25396 1752 6939 6939 9264 2012 7675 IGP > > 2001:248::/32 8954 4555 5609 9264 2012 7675 IGP > > 2001:248::/32 12337 3320 5609 9264 2012 7675 IGP > > 2001:248::/32 > 6939 6939 9264 2012 7675 IGP > > 2001:248::/32 12779 6175 6435 9264 2012 7675 IGP > > 2001:248::/32 12902 12859 8954 4555 5609 9264 2012 7675 IGP > > 2001:248::/32 25358 6175 6435 9264 2012 7675 IGP > > 2001:248::/32 8758 9044 513 9264 9264 2012 7675 IGP > > 2001:248::/32 12859 8954 4555 5609 9264 2012 7675 IGP > > 2001:248::/32 1888 1103 3425 293 6435 9264 2012 7675 IGP > > 2001:248::/32 8447 6830 4555 5609 9264 2012 7675 IGP > > 2001:248::/32 12634 3265 3549 6939 6939 9264 2012 7675 IGP > > 2001:248::/32 12871 8954 4555 5609 9264 2012 7675 IGP > > 2001:248::/32 1103 3425 293 6435 9264 2012 7675 > > > > whois -h whois.nic.ad.jp AS7675 reveals no useful > informations though: > > > > Autonomous System Information: [ASESC$B>pJsESC(B] > > a. [ASESC$BHV9fESC(B] 7675 > > b. [ASESC$BL>ESC(B] ZEBRA > > f. [ESC$BAH?%L>ESC(B] (unknown) > > g. [Organization] Digital Magic Labs, Inc. > > m. [ESC$B1?MQ@UG$ > n. [ESC$B5;=QO"MmC4Ev > o. [AS-IN] from AS4691 100 accept ANY > > o. [AS-IN] from AS4682 100 accept ANY > > o. [AS-IN] from AS7527 100 accept AS7527 > > p. [AS-OUT] to AS4691 announce AS7675 > > p. [AS-OUT] to AS4682 announce AS7675 > > p. [AS-OUT] to AS7527 announce AS7675 > > y. [ESC$BDLCN%"%I%l%9ESC(B] > > [ESC$B3dEvG/7nF|ESC(B] 1998/04/27 > > [ESC$BJV5QG/7nF|ESC(B] > > [ESC$B:G=*99?7ESC(B] 1999/06/10 13:50:55 (JST) > > ip-alloc@nic.ad.jp > > > > Anyone having a working contact for this? > > > > Sole "Upstream" is as2012 which is odd as that is hungary > > which is kinda a far away land from japan. > > > > aut-num: AS2012 > > as-name: UNSPECIFIED > > descr: ELTENET > > descr: Eotvos Lorand University of Sciences > > descr: Budapest, Hungary > > descr: HU > > > > First admin/tech contact (LV166-RIPE) doesn't have an email > > address, second one cc'd. > > > > Greets, > > Jeroen > > > > -----BEGIN PGP SIGNATURE----- > > Version: Unfix PGP for Outlook Alpha 13 Int. > > Comment: Jeroen Massar / jeroen@unfix.org / > http://unfix.org/~jeroen/ > > > > > iQA+AwUBP3f2HSmqKFIzPnwjEQKqcACfVudDSrYX0IpqciSXeDCsy5LykQwAliH/ > > 6Ebw4ECX4VHi7W7+E/UOVj4= > > =R9lS > > -----END PGP SIGNATURE----- > > > > > > > -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP3gEaymqKFIzPnwjEQIb0gCglAu5jg1IUy/5JDanOCJFnm/1vIEAn21E LqFSsWfyzAdhlhHdhdFckUkX =KCPf -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Mon Sep 29 11:06:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19973 for ; Mon, 29 Sep 2003 11:06:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3zVW-000Exy-Ed for v6ops-data@psg.com; Mon, 29 Sep 2003 15:00:14 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A3zSg-000Ehd-AX for v6ops@ops.ietf.org; Mon, 29 Sep 2003 14:57:18 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19377; Mon, 29 Sep 2003 10:57:10 -0400 (EDT) Message-Id: <200309291457.KAA19377@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-06.txt Date: Mon, 29 Sep 2003 10:57:09 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@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 IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-06.txt Pages : 21 Date : 2003-9-29 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-v6ops-3gpp-analysis-06.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-v6ops-3gpp-analysis-06.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: <2003-9-29110852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110852.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Sep 29 11:53:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24935 for ; Mon, 29 Sep 2003 11:53:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A40Hj-000Kle-5J for v6ops-data@psg.com; Mon, 29 Sep 2003 15:50:03 +0000 Received: from [193.180.251.49] (helo=albatross-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A40HB-000Kiu-MN for v6ops@ops.ietf.org; Mon, 29 Sep 2003 15:49:29 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8TFnRAv023595; Mon, 29 Sep 2003 17:49:27 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 29 Sep 2003 17:52:12 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F03768311@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Mon, 29 Sep 2003 17:49:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_20,MSG_ID_ADDED_BY_MTA_3 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Fri, 26 Sep 2003, Karim El-Malki (HF/EAB) wrote: > > > JW: > > > => can we agree on Pekka's suggestion and just remove > > > "native" from Pekka's text? > > > > Pekka's understanding was that we killed the "tunneled IPv6 part". > > I don't think that is what has been done in the document, > since now it just > > specifies better when tunneling may be useful. Since we do > talk about > > a case where tunnelling can be useful we should keep the > sentence as is > > so that it mentions native and tunneled. It was written on > purpose not > > to make it sound like it was only "native" that we were > talking about > > by explicitly writing native or tunneled. > > I'm not sure how you read that we're recommending tunneling > (excerpt below > *). That certainly isn't the intent. Perhaps it needs to > be reworded to > be more explicit. It simply says "If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism." > My point of removing "native or tunneled" is that because > there should not > be any (or close to any) tunneled connectivity (from the UE) > in the first > place, pointing it out here is irrelevant. What leads you to this conclusion? Do you have practical experience that leads you to this view? I have practical experience of this tunneled service in real mobile networks that proves the opposite of what you are saying. I can see that you are expressing a strong opinion but I have not read and cannot see a reason for it from what I know about IPv6 in mobile networks. There is always a starting point for the introduction of IPv6 and we must consider this case. /Karim From owner-v6ops@ops.ietf.org Mon Sep 29 12:08:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26425 for ; Mon, 29 Sep 2003 12:08:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A40Tp-000M5N-6U for v6ops-data@psg.com; Mon, 29 Sep 2003 16:02:33 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A40TI-000M4D-OY for v6ops@ops.ietf.org; Mon, 29 Sep 2003 16:02:00 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8TG1w31011722; Mon, 29 Sep 2003 18:01:58 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 29 Sep 2003 18:04:43 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F03768312@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: "'juha.wiljakka@nokia.com'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network Date: Mon, 29 Sep 2003 18:01:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,MSG_ID_ADDED_BY_MTA_3 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Connection redundancy should also be noted as an important > > requirement in 3GPP networks. Static tunnels on their > own don't > > provide a routing recovery solution for all scenarios > where an IPv6 > > route goes down. However, they may provide an adequate > solution > > depending on the design of the network and in presence > of other > > router redundancy mechanisms. On the other hand, redundancy can > > be obtained by running IGP/EGP based tunneling mechanisms or by > > running an IPv6 routing protocol over the manually configured > > tunnels described previously. > > I don't think this is OK. First of all, this overlaps with > ISP work. > From the ISP work, we can say for certainty that manual IPv6 > tunnels and > running an IPv6 routing protocol over them will be considered as good > practice. After all, tunnel is just a link layer; you run > IPv6 routing > protocols over your native infrastructure -- there is zero difference > here. I don't think there have been sufficient reasoning > presented to say > anything of IGP/EGP based mechanisms running over IPv4 > networks in this > context. First, it is available in some products so there is a reason. You are proposing that we run multiple routing protocol instances, one for IPv4 and one for IPv6 inside the tunnels. The alternative is obviously to integrate this info in one routing protocol. I am no routing expert, but what's so strange with this? I'm not against the former but I can't see how the latter can be a worse solution. > > As it is, I don't want to see any specific "marketing" here > for IGP/EGP > based mechanisms. Did you really intend to say that I am doing "marketing"? If so I think you are mistaken, I have no interest in any of those drafts. Rather it is quite obvious you don't approve of them. Should I understand from this that the routing WGs and IETF in general does not want any such mechanisms to be used or is it your personal opinion? > We'll have to properly analyze it first. > There have > been no arguments which require it in this context, so the > work should be > done with ISP scenarios. Therefore, I'd really prefer to > keep the current > text to the basics, like: > > Connection redundancy should also be noted as an important > requirement in 3GPP networks. Running an IPv6 routing protocol > over static tunnels, as one would run IPv6 routing protocols over > native infrastructure, provides a well-known routing > recovery solution. Are you really saying that we have more experience in running IPv6 routing protocols over static tunnels than e.g. BGP-based tunneling? It's the first time I hear this... > > and reword: > > Even a dynamic tunneling mechanism or an IGP/EGP routing protocol > based tunneling mechanism can be considered if other methods are > not suitable. > > to something like: > > Even a dynamic tunneling mechanism or a routing protocol > based tunneling mechanism could be considered if other > methods are > not suitable. Whether this is really needed is to be > analyzed at ISP > scenarios/solutions work. ...while running an IPv6 routing protocol inside a tunnel is OK anyway independently of the ISP work? Doesn't make sense. > > > When we get to the Last Call, I will plan to (in any case, > whatever the outcome) list a few particularly controversial > points to try > to get more WG feedback on what it thinks the good approach here. > However, it's (IMHO) better to be minimalistic from the > start and expand > if really necessary, as we should keep things simple (if not > simpler). > I appreciate the intention to keep things simple and get WG feedback, but if we keep on removing details and adding opinions regarding IPv6 deployment in mobile nets then the document will not be useful to 3gpp operators and manufacturers any more. /Karim From owner-v6ops@ops.ietf.org Mon Sep 29 13:29:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29845 for ; Mon, 29 Sep 2003 13:29:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A41jc-0004MW-Dp for v6ops-data@psg.com; Mon, 29 Sep 2003 17:22:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A41h1-00043K-DB for v6ops@ops.ietf.org; Mon, 29 Sep 2003 17:20:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8THJDa24309 for ; Mon, 29 Sep 2003 20:19:13 +0300 Date: Mon, 29 Sep 2003 20:19:13 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WG Last Call: 3GPP Analysis Document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello everybody, This is a WG Last Call for comments on sending the 3GPP Analysis document to the IESG for considetation as BCP RFC: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt Please review the document carefully, and send your feedback to the list. In particular, there has been a lot of discussion (without necessarily leading into a clear consensus) at least on the following: - whether to recommend the UE's to implement tunneling-based transition mechanism(s), - whether the strong recommendation to deploy at least a minimal amount of IPv6 support to enable IPv6 support in the visited ("roaming") networks is sufficient, - what to say about the general use of NAT-PT or other generic translation mechanisms (note, there is a dependency on the soon-to-be-published NAT-PT applicability statement work here), - whether to discourage the IPv6-only UE deployment until the transition has progressed further (related to the need of generic translators, above), - whether the 3GPP networks are special (compared to the ISP) and whether we should recommend (or list) BGP/IGP -based tunneling mechanisms (on top of IPv4 infrastructure) in the 3GPP operator's network - what kind of transition mechanism is needed for the IMS scenario, and whether tasking an another WG (e.g. a SIP WG) to specify it is a good idea. It would be especially useful to keep these issues in mind when reviewing the document and providing feedback. Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. The last call will end in about 2 weeks, on 14th October. Pekka, Jonne & Bob ---------- Forwarded message ---------- Date: Mon, 29 Sep 2003 10:57:09 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-06.txt Pages : 21 Date : 2003-9-29 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt From owner-v6ops@ops.ietf.org Mon Sep 29 15:46:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07016 for ; Mon, 29 Sep 2003 15:46:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A43r1-000Gsv-Bj for v6ops-data@psg.com; Mon, 29 Sep 2003 19:38:43 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A43qU-000GrB-Mr for v6ops@ops.ietf.org; Mon, 29 Sep 2003 19:38:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06529; Mon, 29 Sep 2003 15:38:02 -0400 (EDT) Message-Id: <200309291938.PAA06529@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-02.txt Date: Mon, 29 Sep 2003 15:38:02 -0400 X-Spam-Status: No, hits=2.9 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME, RCVD_IN_OSIRUSOFT_COM,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@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 IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-apps-02.txt Pages : 54 Date : 2003-9-29 The transition from an all IPv4 network to an all IPv6 network requires several interim steps, being one of them the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards - Full, Draft, and Proposed - and Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-v6ops-ipv4survey-apps-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-v6ops-ipv4survey-apps-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: <2003-9-29153009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-apps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29153009.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Sep 29 19:16:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17011 for ; Mon, 29 Sep 2003 19:16:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A474W-0006th-0N for v6ops-data@psg.com; Mon, 29 Sep 2003 23:04:52 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A473k-0006pX-PX for v6ops@ops.ietf.org; Mon, 29 Sep 2003 23:04:04 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8TN3oP31411; Mon, 29 Sep 2003 16:03:50 -0700 X-mProtect: <200309292303> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpKj2aa; Mon, 29 Sep 2003 16:03:49 PDT Message-ID: <3F78BAF8.1000205@iprg.nokia.com> Date: Mon, 29 Sep 2003 16:06:32 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Soliman Hesham , "Karim El-Malki (HF/EAB)" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-05: miscellaneous non-critical issues References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: >>So to work around this, you need to use something >>to enable you to tunnel to a router in the home network. >>IMO ISATAP fits nicely in this model. >> >> > >That's a detail at this point, but this is certainly at odds with the >ISATAP security model. > As the lead ISATAP author, I must ask what you see as the problem with the ISATAP security model in this context? Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Sep 30 03:59:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11426 for ; Tue, 30 Sep 2003 03:59:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4FHn-000Ia8-LO for v6ops-data@psg.com; Tue, 30 Sep 2003 07:51:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A4FH8-000IV9-Jx for v6ops@ops.ietf.org; Tue, 30 Sep 2003 07:50:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8U7mji02714; Tue, 30 Sep 2003 10:48:45 +0300 Date: Tue, 30 Sep 2003 10:48:45 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: Soliman Hesham , "Karim El-Malki (HF/EAB)" , , Subject: ISATAP security model wrt. 3GPP networks [Re: 3gpp-analysis-05: miscellaneous non-critical issues] In-Reply-To: <3F78BAF8.1000205@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Let's try not to get sidetracked too much on ISATAP.. On Mon, 29 Sep 2003, Fred Templin wrote: > >>So to work around this, you need to use something > >>to enable you to tunnel to a router in the home network. > >>IMO ISATAP fits nicely in this model. > > > >That's a detail at this point, but this is certainly at odds with the > >ISATAP security model. > > As the lead ISATAP author, I must ask what you see as > the problem with the ISATAP security model in this > context? The ISATAP spec employs automatic tunneling within a site, trusting the other nodes in the site (that alone is pretty serious, but it gets worse). When you have access to an ISATAP link, you can do pretty much everything on that link (especially due to the current, flexibility tradeoffs -- see Appendix D on the spec). That may be more-or-less fine under a single administrative domain, where such trust relations may (or may not) be assumed, but in this particular case, the ISATAP link would consist of the 3GPP operator and all the ISATAP-using UE's. Every UE is basically untrusted by the others (and by the 3GPP operator, but that's not so relevant here). Thus, I fail to see how something like ISATAP could be even be considered for use in this scenario. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Sep 30 09:44:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21005 for ; Tue, 30 Sep 2003 09:44:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4Kj8-000ERw-59 for v6ops-data@psg.com; Tue, 30 Sep 2003 13:39:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A4Kib-000EQZ-Fh for v6ops@ops.ietf.org; Tue, 30 Sep 2003 13:39:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8UDc3007773; Tue, 30 Sep 2003 16:38:03 +0300 Date: Tue, 30 Sep 2003 16:38:02 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: juha.wiljakka@nokia.com, Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F03768311@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 29 Sep 2003, Karim El-Malki (HF/EAB) wrote: > It simply says "If the 3GPP network does not support IPv6 PDP contexts, > and an application on the UE needs to communicate with an IPv6(-only) > node, the UE may activate an IPv4 PDP context and encapsulate > IPv6 packets in IPv4 packets using a tunneling mechanism." Ok, let's see whether this needs handling on the current revision. Maybe it needs further discouragement, or options how the UE could tackle the problem of no IPv6 support in the first network it tries. > > My point of removing "native or tunneled" is that because > > there should not > > be any (or close to any) tunneled connectivity (from the UE) > > in the first > > place, pointing it out here is irrelevant. > > What leads you to this conclusion? Do you have practical experience > that leads you to this view? I have practical experience of this > tunneled service in real mobile networks that proves the opposite of what > you are saying. I can see that you are expressing a strong opinion but I > have not read and cannot see a reason for it from what I know about > IPv6 in mobile networks. I don't have a lot of experience in 3GPP networks (obviously), but discussing these issues with some folks who have (e.g. from Nokia), there seem to be a huge distinction on what you're saying and what others are saying. > There is always a starting point for the > introduction of IPv6 and we must consider this case. Introduction of IPv6 works fine in the operator's own network. It works fine if the user is satisfied with only v4 when he goes abroad and the roaming partner doesn't support v6, etc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Sep 30 09:45:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21032 for ; Tue, 30 Sep 2003 09:45:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4Kdc-000EA8-G5 for v6ops-data@psg.com; Tue, 30 Sep 2003 13:34:00 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A4Kbv-000E47-5o for v6ops@ops.ietf.org; Tue, 30 Sep 2003 13:32:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h8UDVAq07730; Tue, 30 Sep 2003 16:31:10 +0300 Date: Tue, 30 Sep 2003 16:31:09 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: "'juha.wiljakka@nokia.com'" , Subject: RE: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F03768312@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 29 Sep 2003, Karim El-Malki (HF/EAB) wrote: > > I don't think this is OK. First of all, this overlaps with > > ISP work. > > From the ISP work, we can say for certainty that manual IPv6 > > tunnels and > > running an IPv6 routing protocol over them will be considered as good > > practice. After all, tunnel is just a link layer; you run > > IPv6 routing > > protocols over your native infrastructure -- there is zero difference > > here. I don't think there have been sufficient reasoning > > presented to say > > anything of IGP/EGP based mechanisms running over IPv4 > > networks in this > > context. > > First, it is available in some products so there is a reason. "someone implements it so it must be needed" is not a tenet I subscribe to.. nor do many others who work at the operations community. More often than not, vendors are more than happy to provide more-or-less fringe features, for example, as a means to try to differentiate from the others, to gain a market share. > You are proposing that we run multiple routing protocol instances, one > for IPv4 and one for IPv6 inside the tunnels. The alternative is > obviously to integrate this info in one routing protocol. [...] Right. Although I would rephrase this: I am proposing that the systems either: 1) run multiple routing protocol, one for IPv4 and one for IPv6 (basically, different combinations of OSPFv2|IS-IS and OSPFv3|IS-IS, excluding RIPv2 and RIPng), or 2) run a single routing protocol which includes both IPv4 and IPv6 over the infrastructure supporting both (basically, IS-IS) As you see, I decidedly avoid talking about "tunnels" in 1). If it's IPv6, it's IPv6.. the IPv6 infrastructure need to be handled in a routing protocol (and you can't handle it in an IPv4 routing protocol, because the IPv6 infrastructure is more than just tunnels). And as you see, I'm not against running a single routing protocol either (IS-IS is the only option, basically), as long as the infrastructure you run it over supports both IPv4 and IPv6. This wording seems to give an entirely different outcome as yours.. > I am no > routing expert, but what's so strange with this? I'm not against the > former but I can't see how the latter can be a worse solution. Some _dual-stack_ backbones have gone into a single protocol (IS-IS) to handle both IPv4 and IPv6. That's fine.. but you're using this argument to advocate an IPv4 routing protocol building and maintaining IPv6-over-IPv4 tunnel infrastructure, which is really unbearable. > > As it is, I don't want to see any specific "marketing" here > > for IGP/EGP > > based mechanisms. > > Did you really intend to say that I am doing "marketing"? I'm not sure what to intend. What I see is that a set of mechanisms are strongly pushed in a scenario I don't see they fit very well, or are useful at all. > If so I think you are mistaken, I have no interest in any of > those drafts. Rather it is quite obvious you don't approve of > them. True. :-) > Should I understand from this that the routing WGs and > IETF in general does not want any such mechanisms to be used > or is it your personal opinion? I cannot speak for routing WGs or IETF in general. However, a routing WG has asked v6ops for opinion whether they should go forward with specifying e.g. BGP tunneling; they would not want to do it unless there was support from v6ops that it's needed and useful. We, as v6ops chairs, gave pushback to that idea, deferring to look at the ISP scenarios/solutions work first. > > We'll have to properly analyze it first. > > There have > > been no arguments which require it in this context, so the > > work should be > > done with ISP scenarios. Therefore, I'd really prefer to > > keep the current > > text to the basics, like: > > > > Connection redundancy should also be noted as an important > > requirement in 3GPP networks. Running an IPv6 routing protocol > > over static tunnels, as one would run IPv6 routing protocols over > > native infrastructure, provides a well-known routing > > recovery solution. > > Are you really saying that we have more experience in running IPv6 > routing protocols over static tunnels than e.g. BGP-based tunneling? > It's the first time I hear this... Yes, I'm saying this, and I can guarantee that it's very accurate. Welcome to the operational reality! Take a deep breath, the air smells so much cleaner this side of the (vendor, operator) fence ;-). > > and reword: > > > > Even a dynamic tunneling mechanism or an IGP/EGP routing protocol > > based tunneling mechanism can be considered if other methods are > > not suitable. > > > > to something like: > > > > Even a dynamic tunneling mechanism or a routing protocol > > based tunneling mechanism could be considered if other > > methods are > > not suitable. Whether this is really needed is to be > > analyzed at ISP > > scenarios/solutions work. > > ...while running an IPv6 routing protocol inside a tunnel is OK > anyway independently of the ISP work? Doesn't make sense. It makes perfect sense if one knows what are the basic elements we use in the configured tunnels and a basic routing protocol on top of it: 1) TRANS-MECH(v2): configured tunnels (whether IP or GRE) 2) IPv6 routing protocol without any frills: IS-IS, OSPFv3, RIPng Nothing new needed. BGP-tunneling and similar, on the other hand, are quite far from finished, generally approved, or used. They are not basic building blocks. Those expand heavily on the existing basic building blocks. So, it still remains a question whether they will be needed, and if so, in which specific scenarios (e.g., in certain MPLS networks only, not for IPv6-over-IPv4 tunneling, ...). > I appreciate the intention to keep things simple and get WG feedback, > but if we keep on removing details Well, I guess opinions differ on this; for one person, it may be an important detail, for the other, irrelevant or even dangerous recommendation to do something that there seems to be little justification to do otherwise. > and adding opinions regarding > IPv6 deployment in mobile nets then the document will not be > useful to 3gpp operators and manufacturers any more. The goal here is to document what 3GPP operators *need*, not what they *think they need*, or even, *what their vendors think the operators need*. There is a vast distinction between these... and especially our AD has been very keen to stick to the first. If there are operators or users out there, let them come forward and talk to us. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Sep 30 13:05:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02154 for ; Tue, 30 Sep 2003 13:05:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4NoC-0002UY-PS for v6ops-data@psg.com; Tue, 30 Sep 2003 16:57:08 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A4Nng-0002Ti-Bm for v6ops@ops.ietf.org; Tue, 30 Sep 2003 16:56:36 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8UGuIH10998; Tue, 30 Sep 2003 09:56:18 -0700 X-mProtect: <200309301656> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6J5xYc; Tue, 30 Sep 2003 09:56:17 PDT Message-ID: <3F79B657.9010802@iprg.nokia.com> Date: Tue, 30 Sep 2003 09:59:03 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Soliman Hesham , "Karim El-Malki (HF/EAB)" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: Re: ISATAP security model wrt. 3GPP networks [Re: 3gpp-analysis-05: miscellaneous non-critical issues] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: >Let's try not to get sidetracked too much on ISATAP.. > Not my intention, but see my brief comments below: >On Mon, 29 Sep 2003, Fred Templin wrote: > > >>>>So to work around this, you need to use something >>>>to enable you to tunnel to a router in the home network. >>>>IMO ISATAP fits nicely in this model. >>>> >>>> >>>That's a detail at this point, but this is certainly at odds with the >>>ISATAP security model. >>> >>> >>As the lead ISATAP author, I must ask what you see as >>the problem with the ISATAP security model in this >>context? >> >> > >The ISATAP spec employs automatic tunneling within a site, trusting the >other nodes in the site (that alone is pretty serious, but it gets worse). >When you have access to an ISATAP link, you can do pretty much everything >on that link (especially due to the current, flexibility tradeoffs -- see >Appendix D on the spec). > The RPF checks for ingress filtering in draft -15 are a bit too loose (hence appendix D) while those in earlier draft versions were a bit too restrictive. This will be corrected in draft -16 (due out soon), and appendix D will be removed. >That may be more-or-less fine under a single administrative domain, where >such trust relations may (or may not) be assumed, but in this particular >case, the ISATAP link would consist of the 3GPP operator and all the >ISATAP-using UE's. Every UE is basically untrusted by the others (and by >the 3GPP operator, but that's not so relevant here). > Not quite true; in the 3GPP environment we have link-layer authentication mechanisms associated with the IPv4 PDP context and ingress filtering to prevent IPv4 source address spoofing. Since the ISATAP RPF checks for ingress filtering build on the link-layer (IPv4) mechanisms, the IPv4 PDP context provides a trust basis. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Sep 30 15:42:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11516 for ; Tue, 30 Sep 2003 15:42:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4QHb-000Csc-C6 for v6ops-data@psg.com; Tue, 30 Sep 2003 19:35:39 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.22) id 1A4QH5-000CpV-D8 for v6ops@ops.ietf.org; Tue, 30 Sep 2003 19:35:07 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h8UJZ6kv003355 for ; Tue, 30 Sep 2003 13:35:07 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HM10068XL2H01@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 30 Sep 2003 13:35:06 -0600 (MDT) Received: from sun.com ([129.146.11.160]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HM100E2RL2GZS@mail.sun.net> for v6ops@ops.ietf.org; Tue, 30 Sep 2003 13:35:05 -0600 (MDT) Date: Tue, 30 Sep 2003 12:35:04 -0700 From: Alain Durand Subject: Re: WG Last Call: 3GPP Analysis Document To: Pekka Savola , v6ops@ops.ietf.org Message-id: <3F79DAE8.5010205@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,REFERENCES, USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Here are some high level comments on the document. 1- backbone tunneling issue. The document talks at lenght about tunneling in the backbone. This is in fact just about creating an overlay topology, with wither static or dynamic tunnels. A number of technics, like Cisco 6PE (v6 over MPLS) exits. But there is nothing specific to 3GPP there, this apply to any backbone network. 2- No transition mechanism on the UE (no tunelling, no translation on the UE) This is one of the main recommendation. The philosophy here is to say, those are new devices and new networks, so we can put the burden of transition on the network itself to make the devices simpler/more reliable. I think this tradeoff is right but should be discussed more clearly in the document. 3- Dual stack vs IPv6-only UE This is the other key recommendation. The tradeoffs should be discussed more: - v6only device: easier to build/manage. Require all services to be v6 ready. If the supported "legacy" services are limited to web/mail, they can be easily proxied, if not, the situation is more complex. - dual stack: require management of 2 networks (v4&v6) The philosophy is that "legacy" applications keep using v4 for the foreseeable future and new applications requiring end-to-end connectivity (peer2peer & friends) will use v6 This second scenario is somehow what we see hapening on the "classic" non 3GPP internet. In that scenario, if someone want to participate in the new applications requiring end to end, they upgrade as transparently as they can to v6. This is what we are seeing with Microsoft three degree. So, IMHO recommending dual stack UE for now sound reasonable but in these tradeoffs should be discussed more clearly. Again, there seems to be little here that is 3GPP specific. 3- Seamless connectivity with IPv4 legacy node. For 'traditional' applications, if we recommend the dual stack approach, this is not needed. The point that is really specific to 3GPP is that 3GPP chose to mandate that the IMS is IPv6 only. Trying to achieve seamless connectivity between v6-only nodes and legacy v4 nodes for those applications requiring end-to-end IP connectivity seems to me a non starter. If this was possible to make this work and scale, there will be no need for IPv6, period. The analysis document is making the point that: "It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed." However, this claim is not substanciated. If it is the case that such communications are only required in limited environments, why not recommending that those environments upgrade to v6? If it is not the case, and actually the number of devices/communications requiring translation is very large, I'm affraid that recommending to develop the suggested SIP ALG/NAT will create a lot of complexity, and I do not really see how introducing IPv6 did anything good at all. So, IMHO, the scenario IMS v6 only to v4 SIP should not be solved. - Alain.