From mavs-bounces@ietf.org Wed Nov 02 04:46:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXFCn-0007BR-Pu; Wed, 02 Nov 2005 04:46:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXFCl-0007AS-SY for MAVS@megatron.ietf.org; Wed, 02 Nov 2005 04:46:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23656 for ; Wed, 2 Nov 2005 04:46:30 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXFRK-0008UG-Hy for MAVS@ietf.org; Wed, 02 Nov 2005 05:01:54 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 10:46:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Mavs] FW: MAVS / multi-provider QoS for VPNs Date: Wed, 2 Nov 2005 10:46:44 +0100 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A080BAAA2@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [Mavs] FW: MAVS / multi-provider QoS for VPNs Thread-Index: AcXbFaeJhpf3ctpdS6eTmyHh7ujswwEfKHBA From: "JACQUENET Christian RD-TCH-REN" To: , , "Martin Halstead" X-OriginalArrivalTime: 02 Nov 2005 09:46:44.0871 (UTC) FILETIME=[55DD4170:01C5DF92] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable Cc: MAVS@ietf.org X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org Dear all, Like Dimitri, I plan to attend the first session only. Cheers, Christian.=20 -----Message d'origine----- De : mavs-bounces@ietf.org [mailto:mavs-bounces@ietf.org] De la part de = dimitri papadimitriou Envoy=E9 : jeudi 27 octobre 2005 18:43 =C0 : Martin Halstead Cc : MAVS@ietf.org Objet : Re: [Mavs] FW: MAVS / multi-provider QoS for VPNs martin i plan to attend during the first session (at least) - as the ops area = meeting is split into two sessions: 1740-1840 Afternoon Session III Salon 1 APP calsify Calendaring and Scheduling Standards Salon C INT mipshop MIPv6 Signaling and Handoff Optimization WG Oak INT ntp Network Time Protocol WG Salon 2/3 OPS opsarea Operations & Management Open Area Salon F RTG rpsec Routing Protocols Security Requirements WG Cypress SEC smime S/MIME Mail Security WG 1850-1950 Afternoon Session IV Salon A/B APP xmlpatch XML-Patch-Ops BOF Salon D/E INT netlmm Network-based Localized Mobility Management Oak INT ntp Network Time Protocol WG Salon 2/3 OPS opsarea Operations & Management Open Area Salon C RTG bfd Bidirectional Forwarding Detection WG Cypress SEC ltans Long-Term Archive and Notary Services WG Salon 1 SEC syslog Security Issues in Network Event Logging WG Salon F TSV pmtud Path MTU Discovery WG Martin Halstead wrote: > All >=20 > Hi - there should be a discussion on the Monday afternoon Ops open=20 > area meeting regarding MAVS. Could you let me know if any of you plan=20 > to attend? Would be good to give feedback on the need for a MAVS WG. >=20 > Regards >=20 > Martin Halstead, >=20 > 1st Floor, Thames Tower, 37-45 Station Road, Reading, Berkshire, RG1 > 1LX. Tel: +44 (0)118 933 7118; Mob: +44 (0)7919 52 4490; Fax: +44 > (0)118 933 7101; Email: mhalstead@nexagent.com=20 > ; www.nexagent.com=20 > >=20 > -----Original Message----- From: Jim Guichard (jguichar)=20 > [mailto:jguichar@cisco.com] Sent: 27 October 2005 17:19 To: David=20 > Kessens; Ross Callon; David Meyer Cc: bwijnen@lucent.com;=20 > rbonica@juniper.net; rick@rhwilder.net; Philip Jacobs (phjacobs);=20 > Bruce Davie (bdavie); Martin Halstead Subject: RE: MAVS /=20 > multi-provider QoS for VPNs >=20 >=20 > Hi David, >=20 > Martin Halstead [copied] from Nexagent has agreed to provide an=20 > overview of the MAVS proposal. Can you confirm that this slot is still = > available ? Best regards, >=20 > Jim Guichard CCIE# 2069 Principal Engineer - MPLS Technologies >=20 > ITD Boxborough DD: 978-936-1586 Cell: 857-205-2383 >=20 >=20 >=20 >=20 >> -----Original Message----- From: David Kessens=20 >> [mailto:david.kessens@nokia.com] Sent: Tuesday, October 18, 2005 >> 10:21 AM To: Ross Callon; David Meyer Cc: bwijnen@lucent.com;=20 >> rbonica@juniper.net; rick@rhwilder.net; Jim Guichard (jguichar);=20 >> Philip Jacobs (phjacobs); Bruce Davie (bdavie) Subject: Re: MAVS /=20 >> multi-provider QoS for VPNs >>=20 >>=20 >> Ross, Dave, >>=20 >> We are planning to have some attention to the MAV topic during our=20 >> open area meeting. >>=20 >> In addition, we have seen a lot of talk about the IPsphere initiative = >> in various fora and I understand that some of the people CC'ed on=20 >> this mail are involved with either initiative or both. >>=20 >> I was wondering whether it is possible that any of you could help us=20 >> with a brief talk on what IPsphere is all about, and an additional=20 >> longer talk on the MAV proposal (it is intended that we will have=20 >> some discussion on the MAV proposal while IPsphere is more of an=20 >> informational nature) >>=20 >> David Kessens --- >>=20 >=20 >=20 > _______________________________________________ Mavs mailing list=20 > Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs >=20 > . >=20 _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs From mavs-bounces@ietf.org Mon Nov 07 06:34:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ5Gb-0007ap-0m; Mon, 07 Nov 2005 06:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZ5GZ-0007a1-7t for MAVS@megatron.ietf.org; Mon, 07 Nov 2005 06:34:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03903 for ; Mon, 7 Nov 2005 06:33:57 -0500 (EST) From: matthew.ford@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZ5W9-0000mA-9S for mavs@ietf.org; Mon, 07 Nov 2005 06:50:30 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:34:07 +0000 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Nov 2005 11:34:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2005 11:34:14 -0000 Message-ID: <4E28CEA517A795438B120F62D182A8C9020DE5B2@I2KM11-UKBR.domain1.systemhost.net> Thread-Topic: Comments on the requirements draft Thread-Index: AcXjjy55lfCE9Fj6TU2uft6PzDxerQ== To: X-OriginalArrivalTime: 07 Nov 2005 11:34:07.0695 (UTC) FILETIME=[2A26EDF0:01C5E38F] X-Spam-Score: 0.3 (/) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 Content-Transfer-Encoding: quoted-printable Subject: [Mavs] Comments on the requirements draft X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org Hi folks, Detailed comments below. High level observations are: - I'm not completely comfortable with the terminology used in this draft, but that may mainly be because I don't feel I understand it very well which is a problem with the exposition, rather than the terminology per se. - The requirements as currently defined seem too general to be really useful. I wonder if there isn't a need to be clearer about specific requirements. This is likely to lead to more disagreements perhaps, but hopefully these can be ironed out and useful progress will result. - I'm not sure I agree with Dimitri that, "the document introduces the notion of VPN integrator (refer to as MNE operator) atop of ISPs". I think the document *allows* for that, but it also clearly alludes to the idea that a single service provider is engaged with service provision to a cusomter and acts as MNE operator for the purposes of delivering that service. To improve the document, I think the roles of the various entities and how they interact and are composed of/subsume each other needs to be spelled out much more clearly. In addition, it might help to specify what we consider the 'default' or 'typical' arrangement will be to help readers trying to get to grips with the terminology for the first time. Good luck with the mini-BoF this this afternoon - I'll try to join via audiocast/jabber. Cheers, Mat OK, here goes, all my comments are prefixed with '=3D=3D>', I've elided portions of the document that I have no comments on. Requirements for Multi Autonomous System VPN services =3D=3D> I tend to think this should be Multi-Provider, not Multi-AS. Multi-AS is a subset of Multi-Provider as I see it. Abstract This document complements [RFC4031] and defines requirements that are specific to the provisioning of VPN services =3D=3D> insert 'across multiple service providers' , potentially at the scale of the Internet. These requirements are independent of underlying technologies or the number of Autonomous Systems such VPNs may span. In addition, it lists the requirements of the different entities that are involved in the administration of these Autonomous Systems and may therefore be involved in the provisioning processes of the VPN service offerings.=20 =3D=3D> OK, so who owns the requirements referred to in the first two sentences? Maybe just delete 'In addition,'. 1. Introduction This document summarizes a list of requirements =3D=3D> I don't think this reads well. Delete 'a list of'. specified by all parties involved in the delivery of VPN services that span multiple Autonomous Systems on behalf of their end customers. Such parties include, but are not limited to, Enterprise IT departments, Network Service Providers (NSP), Systems Integrators (SI), Network Integrators (NI) and Virtual Network Operators (VNO). Section 3 specifies the roles of these parties, while section 4 details examples of each operator type and how these operators interact to deliver VPN services. Section 6 lists the requirements of the parties involved in the delivery of multi-AS specific VPN services. =3D=3D> What about Section 5? 3. Definitions Multi Network Environment (MNE): Two or more Autonomous Systems that interconnect VPN service endpoints (sites) of a common subscriber =3D=3D> I'm not very comfortable with the MNE terminology - = inter-provider environment, or inter-domain environment seems less confusing to me. I also think the 'common subscriber' is confusing and should be removed - how about, 'Two or more Autonomous Systems that interconnect service endpoints (sites) of one or more VPNs' VPN Peering Location (VPL): A physical location where two or more NSP VPN service domains are interconnected. An NSP or SP may operate the VPL. =3D=3D> I think this sentence should be extended to acknowledge the likelihood that a neutral 3rd-party or a consortium of SPs may operate the VPL. Customer: A customer is a single organization, corporation, or enterprise that administratively controls a set of sites. The customer for the purposes of this document has their VPN services delivered via a MNE. Examples of customers include Multi National Corporations and Small to Medium Enterprises. =3D=3D> I don't think these examples are helpful as they seem to include = any organisational entity. I'd delete the final sentence of this definition. Service Provider (SP): A SP is an operator who delivers some aspect of a VPN service to a customer. =3D=3D> If an SP is delivering 'some aspect of' a VPN service (i.e. not = the whole end-to-end service), then they shouldn't be delivering it to a customer, rather they should be delivering it to another SP, so let's delete 'to a customer'. Also a small nit, 'A SP' doesn't read very well - better to write 'An SP' in my opinion. Agent: An Agent is a set of SPs and/or NSPs =3D=3D> You can delete 'and/or NSPs' as NSPs are a subset of SPs. designated by a customer who have the authorization to manage a customer's VPN service offering. The management relationship the Agent has with the customer could be business (contractual) and/or operational. =3D=3D> I don't buy the idea that customers want relationships with = multiple SPs in order to derive VPN service. I think if we're talking about customer requirements for MAVS then 'single point-of-contact' is pretty high up the list. I'd also argue that it actually isn't scalable for a customer to have a contractual relationship with multiple SPs in order to derive service. The contractual management relationship mandates that the Agent will be responsible for fulfilling the customer's requirements for the enforcement of a set of policies within a MNE. This Policy Agent =3D=3D> Are we defining 'Policy Agent' or 'Agent'? I think there is a = need for more clarity here about what is 'agent', 'policy agent', 'ops agent' and how are they related to, or composed of, each other. function could, in addition include an operational management capability that allows them to operationally agree or coordinate policies across the parties involved in delivering the end-to-end service via a MNE. =3D=3D> Indeed, I would expect this to be the default case. This additional operational (Ops) agent function may be distributed or centralized. Where the Ops Agent is a NSP, the NSP Ops Agent may communicate between all relevant NSP Ops Agents to agree upon the enforcement of consistent policies for VPN service provisioning purposes. In this case, the function of the Ops Agent is distributed across multiple SPs. Alternatively, the customer or policy agent may define their routing requirements and outsource their MNE service policy to an Ops Agent, such as a NSP, SI, VNO, CO or MO, who will centrally coordinate the enforcement of policies related to the provisioning of a VPN service. In contrast to the distributed Ops Agent, the centralized Ops Agent may not require end-to-end agreement of service policy across all parties that supply services to his MNE. =3D=3D> How does the centralized agent deliver on an SLA in the absence = of end-to-end agreement? In addition, it is of importance to introduce the notion of Policy Repository. The Policy Repository may be co-located with the Ops Agent or exist as separate entities. =3D=3D> s/as separate entities/as a separate entity Policy Agent (PA): The authority/authorities responsible for fulfilling the customer's requirements for the enforcement of a set of policies within a MNE. Typically a PA will exist per SP, and are assumed=20 =3D=3D> s/are/is to communicate between all relevant PA parties to agree upon the enforcement of consistent policies for VPN service provisioning purposes. The customer may be responsible for specifying their MNE service policy. Alternatively, the customer may define their routing requirements and outsource their MNE service policy to a customer agent such as a Service Provider, Systems Integrator, Cable Operator, Mobile Operator or Virtual Network Operator who in this case would be one of the possible PA involved in the enforcement of policies related to the provisioning of a VPN service. Policy Agents are usually driven by Policy Managers (here referred to as a policy orchestrator (PO)); in addition to this it is of importance to introduce the notion of Policy repository; they may be co-located with the PO or be separate entities. =3D=3D> There is some overlap and confusion between the Policy Agent definition and the Agent definition - probably just a consequence of unfinished editing. This needs to be tidied up. I think the Policy Agent text is reasonably clear, but the 'Agent' text above needs work. Policy Orchestrator (PO): The authority responsible for the physical and logical integration of the MNE. In addition, the PO is responsible for the operation and multi party business process definitions on behalf of the PA. =3D=3D> In the PA definition above it is stated that PA is driven by PO, = so I don't think PO operating 'on behalf of' PA makes sense. Also, I think 'multi-party business process definition' is a bit unwieldy and unclear - this should be reworded and perhaps expanded upon to make the concept clearer. Perhaps, 'PO is responsible for the management of multi-party business processes, negotiations and fulfillment to allow the PA, and by implication the multi-provider VPN, to function.' The PA may directly fulfill the multi-provider VPN service by performing the integration of the multi providers =3D=3D> s/multi providers/multi-provider VPN environment themselves - in this case the PA would also be the PO. Alternatively, the PA may outsource the physical and logical fulfillment as well as interconnect processes of the multi-provider VPN service to a third party 'trading club'. The 'trading club' operator would then be the PO on behalf of the PA. 4. Multi Network Environment Reference Model Figure 1 shows a generic reference model for a Multi Network Environment. It shows the relationships that exist between the various parties involved in the establishment of VPN services that span multiple provider networks.=20 |<------------Multi Network Environment---------->| | | | Users | | | | | Customer | | | | | Agent | | | | | | Policy Agent | | | | | | | +---------------Ops Agent(s) --------------+ | | | | | | | | | | NSP1 VPL1 NSP2 | | | | ^ ^ ^ | | | 1..n 1..n 1..n 1..n 1..n | | V V V V V | |Site1 <---> PSN1<--->(VPL1)<---> PSN2 <---> Site2| Figure 1 - MNE Reference Model =3D=3D> The Policy Agent seems to be adrift in this diagram - need for further clarification of relationships I think. I'd be happy to attempt to redraw this, but I don't feel I have a clear enough understanding from the text yet. The following section details examples of the coordination of the various parties in the enforcement of a set of policies including, but not necessarily limited to addressing, routing, QoS and security for the provisioning of an inter-domain VPN service that will comply with a customers service requirements. =3D=3D> s/customers/customer's 4.1. Distributed Agent Multi Network Environment. In this model, the MNE consists of a community of SPs and/or NSPs that use and operate the network resources of a MNE facility to deploy and exploit a VPN service offering. =3D=3D> Let's not start talking about 'a MNE facility' - better to just = say '... that use and operate network resources to deploy and exploit a VPN service offering.' The Customer will define their routing requirements and let the SP and/or NSP enforce the corresponding policy that addresses such requirements. An Ops Agent will exist per SP and/or NSP, all of which will agree upon the enforcement of consistent policies. =3D=3D> As I read this it is still very unclear to me what the role of = the Ops Agent is, and how it relates to the Policy Agent and how these functions are expected to interact. With reference to Figure 1, the Policy Agent is a single NSP (either NSP1 or NSP2). Ops Agents then consist of SP1 and SP2, both of which share the management of VPL1. =3D=3D> This is still unclear - SP1 and SP2 don't appear in Figure 1, perhaps you mean NSP1 and NSP2. Figure 1 also implies Ops Agents exist at Site1 and Site2. I'm happy to attempt re-working Figure 1, but I need better understanding first. 4.2.1. Enterprise IT Department as the Centralized Agent The Agent could be an Enterprise IT department who holds the Commercial Agent =3D=3D> I think more rigorous use of terminology is necessary - what is 'Commercial' Agent?, 'Centralized' Agent? - using variable terminology loosely is confusing relationship with the customer. In addition, the IT department is responsible for the enforcement of the customer's network policy by acting as the Ops Agent. The IT department manages the VPLs and processes involved in interconnecting the VPL to the NSP VPN domains. NSP1 and NSP2 independently provide VPN services via their PSNs to the Ops Agent who is responsible for integrating each NSPs VPN service offering. 4.2.2. Integration Service Provider as the Centralized Agent In this model, the Commercial Agent =3D=3D> Again, what is 'Commercial Agent'? could be an Enterprise IT department. The IT department outsource their customer's network policy to an Ops Agent who is a SP such as a SI, NI, VNO or NSP. The Ops Agent will manage the VPL and associated VPN services interconnects, as well as coordinate end-to-end VPN services delivered by SP1 and SP2's PSN networks. =3D=3D> I don't really see how this is different to 4.1 except with different actors given different names. 5. Problem Statement No single network can deliver VPN services that provide optimal price and performance for all customers or all customer locations, if such locations are connected through domains administered by different entities. =3D=3D> Not sure I follow this - it is precisely by connecting locations through domains administered by different entities that the problem is addressed. So maybe delete everything after 'customer locations'? For regulatory, resiliency and other reasons, customers may demand that multiple NSP networks are used to deliver their VPN services. =3D=3D> I'm not sure about this. I don't think customers have any of = these requirements. Customers may have requirements for VPNs that are very difficult and/or expensive for a single operator to deliver, hence the need to make it simpler for multiple providers to interconnect in a standardised fashion. This document defines common requirements for implementing and operating an MNE. =3D=3D> Common to whom? 6. Customer Agent MNE Requirements 6.1. Capital Scaling Requirement In an MNE, there might be one or more VPLs. At each VPL there may be one or more interconnected NSPs, or a single operator that uses the VPL for connectivity between their own Autonomous Systems. Traditionally, the interconnection of two NSPs, the so called bilateral interconnect, has resulted in the deployment of network element resources that are either dedicated to those two NSPs, or leased from the owner of the peering point. Where there is a need for a SP to interconnect with multiple other NSPs, a scaling cost-efficiency could result if interconnected network elements could be shared across all SPs. This multilateral approach to network interconnects would have increasing benefit as the number of interconnected SPs at a VPL increased. Interconnected network elements in a MNE must therefore be shared multilaterally. =3D=3D> Can you be more specific about what 'interconnected network elements' you are referring to here? Is this something more than a common L2 fabric? 6.2. Operational Scaling Requirement Cost of operations is of great concern to a NSP, whether or not VPN services span their own Autonomous Systems or those of partners. Compared to the capital cost of MNE interconnection =3D=3D> I think you mean NSP interconnection? , operational cost easily dominates. In an MNE, some, and perhaps all SPs, might play a part in an individual customer solution. Within a customer solution, sites, physical and logical connectivity, SPs, interconnects and service policy might be variously moved, added, changed or deleted (MACD) at any time. =3D=3D> I don't personally like the 'MACD' terminology. Can't we just = talk about service elements being altered, added, relocated or removed? Collectively we can refer to 'change management' or 'change control'? =20 6.3.1. VPN Topology Requirement Although VPN networks offer the possibility for any customer site to communicate with any other customer site, in certain situations this is not desirable. There are many possible reasons why a customer might want to restrict communication amongst sites so that their end-to-end service becomes segmented. For instance, it may be that security is a concern or it may be that company sites or divisions must only use connectivity they have paid for. Furthermore, the traffic flows associated with specific applications may require a partial topology specifically sized to accommodate the aggregate traffic flows.=20 The segmentation might need to exist on a geographical basis, region-by-region, country-by country, or on a corporate basis, division-by-division or site-by-site. Segmentation might even exist within customer sites. However, today, there are no standards for or agreement of how VPN topologies are constructed amongst network operators . =3D=3D> Re Christian's comment, I think there might be a = misunderstanding here. There is certainly no need for standardisation of a set of possible VPN topologies as they are design considerations for the VPN service provider. However, I can see a requirement for having standard VPN topology construction methods and VPN membership mechanisms to address the issues identified. FWIW I think the sentence reads OK as it is. Consequently, network operators use different methods for establishing the logical topology of a VPN and use different schemas to define VPN membership. For instance, one network operator might use standard community values to establish layer-2 topology whilst another might use extended community values. Yet another network operator might use a combination of both. Alternatively, network operators might segment VPNs using layer-3 routing techniques. In fact, some network operators might combine layer-2 and layer-3 segmentation techniques. Additionally, each network operator will implement a schema for VPN membership that is proprietary, with membership values that are likely to overlap and conflict with other network operator values. VPN membership schemas tend to be difficult to modify due to the 'hard coding' of the schema in each network operator's OSS and BSS. Conflicting VPN membership schemas and different methods for establishing logical topology make it very difficult for the MNE operator to establish an end-to-end VPN topology. Moreover, an inventory of this topology consisting of elements such as the network elements/interfaces and the set of paths that traffic may take through the network should be made available. These elements will most likely constitute a partial topological view of the network but would be sufficient for the purpose of QOS polcoy =3D=3D> s/polcoy/policy definition. There is therefore, a requirement to be able to establish an end-to-end VPN topology, including network elements and interfaces throughout an MNE. =3D=3D> I tend to think that this requirement and some of the others = need to be further refined and specified in more detail in order to be useful. For example, the requirement as defined above actually includes requirements for standardised VPN membership schemas, standardised VPN topology construction mechanisms, etc. I think it would be useful to spell these out as distinct requirements. It would also aid the reader if there was a table showing the heirarchy and organisation of all the requirements e.g.: Service Provider VPN Policy Control VPN Topology VPN Membership Schema VPN Topology Definition Mechanism End-to-end QoS Policy etc. 6.3.2. End-to-end QoS Policy Requirement =3D=3D> This section introduces multiple requirements, so I think they should be called out clearly in separate subsections. Currently, there are no standards for or agreement of service definitions amongst network SPs. [RFC3644] defines QoS policy as being dependent upon three types of information; The topology of the network devices under management (e.g. Diffserv), the particular type of QoS methodology used and the business rules and requirements for specifying service(s) delivered by the network. These information types vary across SP/NSP and customer domains. Consequently, network operators deploy a different number of classes of service (COS) and specify service definitions in proprietary ways. Fixed mappings of classes of service between any two network operators will result in compromised service across the two. This is in part because fixed mappings cannot utilize the full service envelope available from the interconnected network operators (a network operator with three classes of service can only utilize 3/5ths of the service envelope of a network operator with five classes of service). In part, it is also because a fixed mapping may be adequate for some customers, but not for others. This is because QoS policy is often applied in different ways for each application in each customer. Sometimes application of a QoS policy can vary within a single customer. Indeed, as depicted in RFC3644, the definition of QoS policy is dependent on three types of information: 1) the topology of the network devices under management, 2) the particular type of QoS methodology used and 3) the business rules and requirements for specifying service(s) delivered by the network. =3D=3D> This sentence should be deleted as it is repetition of the = second sentence in the paragraph. When three or more network operators are used to provide connectivity between customer sites, two or more interconnects is =3D=3D> s/is/are required and, therefore, a multiple, compounding service compromise exists. =3D=3D> I would say, '... and, therefore, the potential for compromised service is compounded.' In an MNE of many network operators and many interconnects, it is clear that numerous and compounding compromises in service will take place and end-to-end QoS policy enforcement may be hard to achieve. There is a requirement, therefore, for a relationship to exist between network operator classes of service that may vary from one customer to another, and that can also utilize the full service envelope of all network operators within an MNE. =3D=3D> Isn't it sufficient to say that there is a requirement for a default, standardised set of Classes of Service to be supported by all members of an MNE? In addition, for some customers who have implemented a QoS policy amongst some or all of their business locations, it may be desirable for the customer that an MNE does not modify that policy in any way. Sometimes this need is characterized as QoS transparency, where the transparency in question refers to the passing of the enterprise QoS policy, unmodified, from ingress to egress of a telecommunications service. [RFC4031] describes this requirement as a 'Carrier's Carrier' model where one SP is the customer of another L3VPN SP. Such an SP should be able to resell VPN service to their VPN customers independently of the DSCP mapping solution employed by the 'Carrier's Carrier' SP. There is a requirement, therefore, for enterprise QoS policy transparency throughout an MNE. 6.7. Third Party Interconnect Requirement Some operators, although they have a need to be able to provide end-to end service in a solution involving multiple SPs, may be unable to operate or have no desire to operate an MNE. In order that an MNE can be established for it and its SP partners, the operator wants a third party to provide interconnect services to the group. It may be that the third party is another SP, a systems integrator, a network integrator or another type of service provider. To achieve end-to-end service, it is critical that the third party interconnect service provider is able to control and coordinate global service policy throughout the MNE on behalf the group. =3D=3D> s/behalf the/behalf of the There is, therefore, a requirement for the interconnect equipment and procedures to be controllable by a third party interconnect services provider. END _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs From mavs-bounces@ietf.org Mon Nov 07 18:02:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZG0x-0001uE-Kl; Mon, 07 Nov 2005 18:02:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZG0v-0001tN-QD for MAVS@megatron.ietf.org; Mon, 07 Nov 2005 18:02:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15609 for ; Mon, 7 Nov 2005 18:02:31 -0500 (EST) Received: from hostedexchange.hostedservice.com ([217.28.130.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZGGb-0003ob-EE for mavs@ietf.org; Mon, 07 Nov 2005 18:19:10 -0500 Received: from THHS2EXBE2X.hostedservice2.net ([192.168.33.20]) by hostedexchange.hostedservice.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 23:02:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Mavs] Comments on the requirements draft Date: Mon, 7 Nov 2005 23:02:27 -0000 Message-ID: Thread-Topic: Comments on the requirements draft thread-index: AcXjjy55lfCE9Fj6TU2uft6PzDxerQAXgChg From: "Martin Halstead" To: , X-OriginalArrivalTime: 07 Nov 2005 23:02:27.0787 (UTC) FILETIME=[52ECD9B0:01C5E3EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org Matthew Thanks for the comments. Response in line with the first part of you = list. Martin -----Original Message----- From: mavs-bounces@ietf.org [mailto:mavs-bounces@ietf.org]On Behalf Of matthew.ford@bt.com Sent: 07 November 2005 11:34 To: mavs@ietf.org Subject: [Mavs] Comments on the requirements draft Hi folks, Detailed comments below. High level observations are: - I'm not completely comfortable with the terminology used in this draft, but that may mainly be because I don't feel I understand it very well which is a problem with the exposition, rather than the terminology per se. - The requirements as currently defined seem too general to be really useful. I wonder if there isn't a need to be clearer about specific requirements. This is likely to lead to more disagreements perhaps, but hopefully these can be ironed out and useful progress will result. MH - Could you be more specific about what you mean by 'need to be = clearer':-) Do you mean=20 that the draft could do with more technical content, more examples, more = detailed explanations for=20 each requirement or something else? - I'm not sure I agree with Dimitri that, "the document introduces the notion of VPN integrator (refer to as MNE operator) atop of ISPs". I think the document *allows* for that, but it also clearly alludes to the idea that a single service provider is engaged with service provision to a cusomter and acts as MNE operator for the purposes of delivering that service. To improve the document, I think the roles of the various entities and how they interact and are composed of/subsume each other needs to be spelled out much more clearly. In addition, it might help to specify what we consider the 'default' or 'typical' arrangement will be to help readers trying to get to grips with the terminology for the first time. MH - Agreed, although this is a tricky thing to get right as it depends = on which side of the fence you sit on. The role of a SI, VNO, NI in relation to a = customer via their 'dedicated' MNE can be substantially different to the role of a = NSP to a customer and a 'shared' MNE. Not sure if it is possible to have a default as to me both roles are = valid. Anyway, will try to=20 update the text with something simpler. Good luck with the mini-BoF this this afternoon - I'll try to join via audiocast/jabber. MH - Thanks. Rest of your comments to be incorporated... Martin Cheers, Mat OK, here goes, all my comments are prefixed with '=3D=3D>', I've elided portions of the document that I have no comments on. Requirements for Multi Autonomous System VPN services =3D=3D> I tend to think this should be Multi-Provider, not Multi-AS. Multi-AS is a subset of Multi-Provider as I see it. Abstract This document complements [RFC4031] and defines requirements that are specific to the provisioning of VPN services =3D=3D> insert 'across multiple service providers' , potentially at the scale of the Internet. These requirements are independent of underlying technologies or the number of Autonomous Systems such VPNs may span. In addition, it lists the requirements of the different entities that are involved in the administration of these Autonomous Systems and may therefore be involved in the provisioning processes of the VPN service offerings.=20 =3D=3D> OK, so who owns the requirements referred to in the first two sentences? Maybe just delete 'In addition,'. 1. Introduction This document summarizes a list of requirements =3D=3D> I don't think this reads well. Delete 'a list of'. specified by all parties involved in the delivery of VPN services that span multiple Autonomous Systems on behalf of their end customers. Such parties include, but are not limited to, Enterprise IT departments, Network Service Providers (NSP), Systems Integrators (SI), Network Integrators (NI) and Virtual Network Operators (VNO). Section 3 specifies the roles of these parties, while section 4 details examples of each operator type and how these operators interact to deliver VPN services. Section 6 lists the requirements of the parties involved in the delivery of multi-AS specific VPN services. =3D=3D> What about Section 5? 3. Definitions Multi Network Environment (MNE): Two or more Autonomous Systems that interconnect VPN service endpoints (sites) of a common subscriber =3D=3D> I'm not very comfortable with the MNE terminology - = inter-provider environment, or inter-domain environment seems less confusing to me. I also think the 'common subscriber' is confusing and should be removed - how about, 'Two or more Autonomous Systems that interconnect service endpoints (sites) of one or more VPNs' VPN Peering Location (VPL): A physical location where two or more NSP VPN service domains are interconnected. An NSP or SP may operate the VPL. =3D=3D> I think this sentence should be extended to acknowledge the likelihood that a neutral 3rd-party or a consortium of SPs may operate the VPL. Customer: A customer is a single organization, corporation, or enterprise that administratively controls a set of sites. The customer for the purposes of this document has their VPN services delivered via a MNE. Examples of customers include Multi National Corporations and Small to Medium Enterprises. =3D=3D> I don't think these examples are helpful as they seem to include = any organisational entity. I'd delete the final sentence of this definition. Service Provider (SP): A SP is an operator who delivers some aspect of a VPN service to a customer. =3D=3D> If an SP is delivering 'some aspect of' a VPN service (i.e. not = the whole end-to-end service), then they shouldn't be delivering it to a customer, rather they should be delivering it to another SP, so let's delete 'to a customer'. Also a small nit, 'A SP' doesn't read very well - better to write 'An SP' in my opinion. Agent: An Agent is a set of SPs and/or NSPs =3D=3D> You can delete 'and/or NSPs' as NSPs are a subset of SPs. designated by a customer who have the authorization to manage a customer's VPN service offering. The management relationship the Agent has with the customer could be business (contractual) and/or operational. =3D=3D> I don't buy the idea that customers want relationships with = multiple SPs in order to derive VPN service. I think if we're talking about customer requirements for MAVS then 'single point-of-contact' is pretty high up the list. I'd also argue that it actually isn't scalable for a customer to have a contractual relationship with multiple SPs in order to derive service. The contractual management relationship mandates that the Agent will be responsible for fulfilling the customer's requirements for the enforcement of a set of policies within a MNE. This Policy Agent =3D=3D> Are we defining 'Policy Agent' or 'Agent'? I think there is a = need for more clarity here about what is 'agent', 'policy agent', 'ops agent' and how are they related to, or composed of, each other. function could, in addition include an operational management capability that allows them to operationally agree or coordinate policies across the parties involved in delivering the end-to-end service via a MNE. =3D=3D> Indeed, I would expect this to be the default case. This additional operational (Ops) agent function may be distributed or centralized. Where the Ops Agent is a NSP, the NSP Ops Agent may communicate between all relevant NSP Ops Agents to agree upon the enforcement of consistent policies for VPN service provisioning purposes. In this case, the function of the Ops Agent is distributed across multiple SPs. Alternatively, the customer or policy agent may define their routing requirements and outsource their MNE service policy to an Ops Agent, such as a NSP, SI, VNO, CO or MO, who will centrally coordinate the enforcement of policies related to the provisioning of a VPN service. In contrast to the distributed Ops Agent, the centralized Ops Agent may not require end-to-end agreement of service policy across all parties that supply services to his MNE. =3D=3D> How does the centralized agent deliver on an SLA in the absence = of end-to-end agreement? In addition, it is of importance to introduce the notion of Policy Repository. The Policy Repository may be co-located with the Ops Agent or exist as separate entities. =3D=3D> s/as separate entities/as a separate entity Policy Agent (PA): The authority/authorities responsible for fulfilling the customer's requirements for the enforcement of a set of policies within a MNE. Typically a PA will exist per SP, and are assumed=20 =3D=3D> s/are/is to communicate between all relevant PA parties to agree upon the enforcement of consistent policies for VPN service provisioning purposes. The customer may be responsible for specifying their MNE service policy. Alternatively, the customer may define their routing requirements and outsource their MNE service policy to a customer agent such as a Service Provider, Systems Integrator, Cable Operator, Mobile Operator or Virtual Network Operator who in this case would be one of the possible PA involved in the enforcement of policies related to the provisioning of a VPN service. Policy Agents are usually driven by Policy Managers (here referred to as a policy orchestrator (PO)); in addition to this it is of importance to introduce the notion of Policy repository; they may be co-located with the PO or be separate entities. =3D=3D> There is some overlap and confusion between the Policy Agent definition and the Agent definition - probably just a consequence of unfinished editing. This needs to be tidied up. I think the Policy Agent text is reasonably clear, but the 'Agent' text above needs work. Policy Orchestrator (PO): The authority responsible for the physical and logical integration of the MNE. In addition, the PO is responsible for the operation and multi party business process definitions on behalf of the PA. =3D=3D> In the PA definition above it is stated that PA is driven by PO, = so I don't think PO operating 'on behalf of' PA makes sense. Also, I think 'multi-party business process definition' is a bit unwieldy and unclear - this should be reworded and perhaps expanded upon to make the concept clearer. Perhaps, 'PO is responsible for the management of multi-party business processes, negotiations and fulfillment to allow the PA, and by implication the multi-provider VPN, to function.' The PA may directly fulfill the multi-provider VPN service by performing the integration of the multi providers =3D=3D> s/multi providers/multi-provider VPN environment themselves - in this case the PA would also be the PO. Alternatively, the PA may outsource the physical and logical fulfillment as well as interconnect processes of the multi-provider VPN service to a third party 'trading club'. The 'trading club' operator would then be the PO on behalf of the PA. 4. Multi Network Environment Reference Model Figure 1 shows a generic reference model for a Multi Network Environment. It shows the relationships that exist between the various parties involved in the establishment of VPN services that span multiple provider networks.=20 |<------------Multi Network Environment---------->| | | | Users | | | | | Customer | | | | | Agent | | | | | | Policy Agent | | | | | | | +---------------Ops Agent(s) --------------+ | | | | | | | | | | NSP1 VPL1 NSP2 | | | | ^ ^ ^ | | | 1..n 1..n 1..n 1..n 1..n | | V V V V V | |Site1 <---> PSN1<--->(VPL1)<---> PSN2 <---> Site2| Figure 1 - MNE Reference Model =3D=3D> The Policy Agent seems to be adrift in this diagram - need for further clarification of relationships I think. I'd be happy to attempt to redraw this, but I don't feel I have a clear enough understanding from the text yet. The following section details examples of the coordination of the various parties in the enforcement of a set of policies including, but not necessarily limited to addressing, routing, QoS and security for the provisioning of an inter-domain VPN service that will comply with a customers service requirements. =3D=3D> s/customers/customer's 4.1. Distributed Agent Multi Network Environment. In this model, the MNE consists of a community of SPs and/or NSPs that use and operate the network resources of a MNE facility to deploy and exploit a VPN service offering. =3D=3D> Let's not start talking about 'a MNE facility' - better to just = say '... that use and operate network resources to deploy and exploit a VPN service offering.' The Customer will define their routing requirements and let the SP and/or NSP enforce the corresponding policy that addresses such requirements. An Ops Agent will exist per SP and/or NSP, all of which will agree upon the enforcement of consistent policies. =3D=3D> As I read this it is still very unclear to me what the role of = the Ops Agent is, and how it relates to the Policy Agent and how these functions are expected to interact. With reference to Figure 1, the Policy Agent is a single NSP (either NSP1 or NSP2). Ops Agents then consist of SP1 and SP2, both of which share the management of VPL1. =3D=3D> This is still unclear - SP1 and SP2 don't appear in Figure 1, perhaps you mean NSP1 and NSP2. Figure 1 also implies Ops Agents exist at Site1 and Site2. I'm happy to attempt re-working Figure 1, but I need better understanding first. 4.2.1. Enterprise IT Department as the Centralized Agent The Agent could be an Enterprise IT department who holds the Commercial Agent =3D=3D> I think more rigorous use of terminology is necessary - what is 'Commercial' Agent?, 'Centralized' Agent? - using variable terminology loosely is confusing relationship with the customer. In addition, the IT department is responsible for the enforcement of the customer's network policy by acting as the Ops Agent. The IT department manages the VPLs and processes involved in interconnecting the VPL to the NSP VPN domains. NSP1 and NSP2 independently provide VPN services via their PSNs to the Ops Agent who is responsible for integrating each NSPs VPN service offering. 4.2.2. Integration Service Provider as the Centralized Agent In this model, the Commercial Agent =3D=3D> Again, what is 'Commercial Agent'? could be an Enterprise IT department. The IT department outsource their customer's network policy to an Ops Agent who is a SP such as a SI, NI, VNO or NSP. The Ops Agent will manage the VPL and associated VPN services interconnects, as well as coordinate end-to-end VPN services delivered by SP1 and SP2's PSN networks. =3D=3D> I don't really see how this is different to 4.1 except with different actors given different names. 5. Problem Statement No single network can deliver VPN services that provide optimal price and performance for all customers or all customer locations, if such locations are connected through domains administered by different entities. =3D=3D> Not sure I follow this - it is precisely by connecting locations through domains administered by different entities that the problem is addressed. So maybe delete everything after 'customer locations'? For regulatory, resiliency and other reasons, customers may demand that multiple NSP networks are used to deliver their VPN services. =3D=3D> I'm not sure about this. I don't think customers have any of = these requirements. Customers may have requirements for VPNs that are very difficult and/or expensive for a single operator to deliver, hence the need to make it simpler for multiple providers to interconnect in a standardised fashion. This document defines common requirements for implementing and operating an MNE. =3D=3D> Common to whom? 6. Customer Agent MNE Requirements 6.1. Capital Scaling Requirement In an MNE, there might be one or more VPLs. At each VPL there may be one or more interconnected NSPs, or a single operator that uses the VPL for connectivity between their own Autonomous Systems. Traditionally, the interconnection of two NSPs, the so called bilateral interconnect, has resulted in the deployment of network element resources that are either dedicated to those two NSPs, or leased from the owner of the peering point. Where there is a need for a SP to interconnect with multiple other NSPs, a scaling cost-efficiency could result if interconnected network elements could be shared across all SPs. This multilateral approach to network interconnects would have increasing benefit as the number of interconnected SPs at a VPL increased. Interconnected network elements in a MNE must therefore be shared multilaterally. =3D=3D> Can you be more specific about what 'interconnected network elements' you are referring to here? Is this something more than a common L2 fabric? 6.2. Operational Scaling Requirement Cost of operations is of great concern to a NSP, whether or not VPN services span their own Autonomous Systems or those of partners. Compared to the capital cost of MNE interconnection =3D=3D> I think you mean NSP interconnection? , operational cost easily dominates. In an MNE, some, and perhaps all SPs, might play a part in an individual customer solution. Within a customer solution, sites, physical and logical connectivity, SPs, interconnects and service policy might be variously moved, added, changed or deleted (MACD) at any time. =3D=3D> I don't personally like the 'MACD' terminology. Can't we just = talk about service elements being altered, added, relocated or removed? Collectively we can refer to 'change management' or 'change control'? =20 6.3.1. VPN Topology Requirement Although VPN networks offer the possibility for any customer site to communicate with any other customer site, in certain situations this is not desirable. There are many possible reasons why a customer might want to restrict communication amongst sites so that their end-to-end service becomes segmented. For instance, it may be that security is a concern or it may be that company sites or divisions must only use connectivity they have paid for. Furthermore, the traffic flows associated with specific applications may require a partial topology specifically sized to accommodate the aggregate traffic flows.=20 The segmentation might need to exist on a geographical basis, region-by-region, country-by country, or on a corporate basis, division-by-division or site-by-site. Segmentation might even exist within customer sites. However, today, there are no standards for or agreement of how VPN topologies are constructed amongst network operators . =3D=3D> Re Christian's comment, I think there might be a = misunderstanding here. There is certainly no need for standardisation of a set of possible VPN topologies as they are design considerations for the VPN service provider. However, I can see a requirement for having standard VPN topology construction methods and VPN membership mechanisms to address the issues identified. FWIW I think the sentence reads OK as it is. Consequently, network operators use different methods for establishing the logical topology of a VPN and use different schemas to define VPN membership. For instance, one network operator might use standard community values to establish layer-2 topology whilst another might use extended community values. Yet another network operator might use a combination of both. Alternatively, network operators might segment VPNs using layer-3 routing techniques. In fact, some network operators might combine layer-2 and layer-3 segmentation techniques. Additionally, each network operator will implement a schema for VPN membership that is proprietary, with membership values that are likely to overlap and conflict with other network operator values. VPN membership schemas tend to be difficult to modify due to the 'hard coding' of the schema in each network operator's OSS and BSS. Conflicting VPN membership schemas and different methods for establishing logical topology make it very difficult for the MNE operator to establish an end-to-end VPN topology. Moreover, an inventory of this topology consisting of elements such as the network elements/interfaces and the set of paths that traffic may take through the network should be made available. These elements will most likely constitute a partial topological view of the network but would be sufficient for the purpose of QOS polcoy =3D=3D> s/polcoy/policy definition. There is therefore, a requirement to be able to establish an end-to-end VPN topology, including network elements and interfaces throughout an MNE. =3D=3D> I tend to think that this requirement and some of the others = need to be further refined and specified in more detail in order to be useful. For example, the requirement as defined above actually includes requirements for standardised VPN membership schemas, standardised VPN topology construction mechanisms, etc. I think it would be useful to spell these out as distinct requirements. It would also aid the reader if there was a table showing the heirarchy and organisation of all the requirements e.g.: Service Provider VPN Policy Control VPN Topology VPN Membership Schema VPN Topology Definition Mechanism End-to-end QoS Policy etc. 6.3.2. End-to-end QoS Policy Requirement =3D=3D> This section introduces multiple requirements, so I think they should be called out clearly in separate subsections. Currently, there are no standards for or agreement of service definitions amongst network SPs. [RFC3644] defines QoS policy as being dependent upon three types of information; The topology of the network devices under management (e.g. Diffserv), the particular type of QoS methodology used and the business rules and requirements for specifying service(s) delivered by the network. These information types vary across SP/NSP and customer domains. Consequently, network operators deploy a different number of classes of service (COS) and specify service definitions in proprietary ways. Fixed mappings of classes of service between any two network operators will result in compromised service across the two. This is in part because fixed mappings cannot utilize the full service envelope available from the interconnected network operators (a network operator with three classes of service can only utilize 3/5ths of the service envelope of a network operator with five classes of service). In part, it is also because a fixed mapping may be adequate for some customers, but not for others. This is because QoS policy is often applied in different ways for each application in each customer. Sometimes application of a QoS policy can vary within a single customer. Indeed, as depicted in RFC3644, the definition of QoS policy is dependent on three types of information: 1) the topology of the network devices under management, 2) the particular type of QoS methodology used and 3) the business rules and requirements for specifying service(s) delivered by the network. =3D=3D> This sentence should be deleted as it is repetition of the = second sentence in the paragraph. When three or more network operators are used to provide connectivity between customer sites, two or more interconnects is =3D=3D> s/is/are required and, therefore, a multiple, compounding service compromise exists. =3D=3D> I would say, '... and, therefore, the potential for compromised service is compounded.' In an MNE of many network operators and many interconnects, it is clear that numerous and compounding compromises in service will take place and end-to-end QoS policy enforcement may be hard to achieve. There is a requirement, therefore, for a relationship to exist between network operator classes of service that may vary from one customer to another, and that can also utilize the full service envelope of all network operators within an MNE. =3D=3D> Isn't it sufficient to say that there is a requirement for a default, standardised set of Classes of Service to be supported by all members of an MNE? In addition, for some customers who have implemented a QoS policy amongst some or all of their business locations, it may be desirable for the customer that an MNE does not modify that policy in any way. Sometimes this need is characterized as QoS transparency, where the transparency in question refers to the passing of the enterprise QoS policy, unmodified, from ingress to egress of a telecommunications service. [RFC4031] describes this requirement as a 'Carrier's Carrier' model where one SP is the customer of another L3VPN SP. Such an SP should be able to resell VPN service to their VPN customers independently of the DSCP mapping solution employed by the 'Carrier's Carrier' SP. There is a requirement, therefore, for enterprise QoS policy transparency throughout an MNE. 6.7. Third Party Interconnect Requirement Some operators, although they have a need to be able to provide end-to end service in a solution involving multiple SPs, may be unable to operate or have no desire to operate an MNE. In order that an MNE can be established for it and its SP partners, the operator wants a third party to provide interconnect services to the group. It may be that the third party is another SP, a systems integrator, a network integrator or another type of service provider. To achieve end-to-end service, it is critical that the third party interconnect service provider is able to control and coordinate global service policy throughout the MNE on behalf the group. =3D=3D> s/behalf the/behalf of the There is, therefore, a requirement for the interconnect equipment and procedures to be controllable by a third party interconnect services provider. END _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs From mavs-bounces@ietf.org Tue Nov 08 04:13:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZPXg-0004xI-TX; Tue, 08 Nov 2005 04:13:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZPXe-0004vt-4o for MAVS@megatron.ietf.org; Tue, 08 Nov 2005 04:13:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23131 for ; Tue, 8 Nov 2005 04:12:54 -0500 (EST) From: matthew.ford@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZPnQ-0005Jh-JU for mavs@ietf.org; Tue, 08 Nov 2005 04:29:40 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 09:13:12 +0000 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Nov 2005 09:13:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Mavs] Comments on the requirements draft Date: Tue, 8 Nov 2005 09:13:18 -0000 Message-ID: <4E28CEA517A795438B120F62D182A8C902183EA1@I2KM11-UKBR.domain1.systemhost.net> Thread-Topic: [Mavs] Comments on the requirements draft Thread-Index: AcXjjy55lfCE9Fj6TU2uft6PzDxerQAXgChgABUV08A= To: , X-OriginalArrivalTime: 08 Nov 2005 09:13:11.0792 (UTC) FILETIME=[A4744700:01C5E444] X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org Martin, > - The requirements as currently defined seem too general to be really > useful. I wonder if there isn't a need to be clearer about specific > requirements. This is likely to lead to more disagreements=20 > perhaps, but > hopefully these can be ironed out and useful progress will result. >=20 > MH - Could you be more specific about what you mean by 'need=20 > to be clearer':-) Do you mean=20 > that the draft could do with more technical content, more=20 > examples, more detailed explanations for=20 > each requirement or something else? Yes, all of the above :) Although thinking about this some more now, I think what I'm missing is the piece that says, given requirement X, these are the pieces of the puzzle that are missing, and these are the pieces of the puzzle that need alteration, and that's probably not appropriate for this document anyway. > - I'm not sure I agree with Dimitri that, "the document=20 > introduces the > notion of VPN integrator (refer to as MNE operator) atop of ISPs". I > think the document *allows* for that, but it also clearly=20 > alludes to the > idea that a single service provider is engaged with service=20 > provision to > a cusomter and acts as MNE operator for the purposes of=20 > delivering that > service. To improve the document, I think the roles of the various > entities and how they interact and are composed of/subsume each other > needs to be spelled out much more clearly. In addition, it=20 > might help to > specify what we consider the 'default' or 'typical'=20 > arrangement will be > to help readers trying to get to grips with the terminology for the > first time. >=20 > MH - Agreed, although this is a tricky thing to get right as=20 > it depends on which > side of the fence you sit on. The role of a SI, VNO, NI in=20 > relation to a customer via > their 'dedicated' MNE can be substantially different to the=20 > role of a NSP to a customer and a 'shared' MNE. > Not sure if it is possible to have a default as to me both=20 > roles are valid. Anyway, will try to=20 > update the text with something simpler. Yes, understood. Perhaps what is required is a couple of diagrams that illustrate possible configurations. This would help to clarify the terminology definitions as well. > Good luck with the mini-BoF this this afternoon - I'll try to join via > audiocast/jabber. After I wrote that I realised that 1800 Vancouver is 0200 UK, so decided to give it a miss! I'll check the audiocast archive later. =20 > MH - Thanks. Rest of your comments to be incorporated... Thanks, Mat _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs From mavs-bounces@ietf.org Thu Nov 17 13:13:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcoFw-0003je-Hb; Thu, 17 Nov 2005 13:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcoED-0002q0-Nd for MAVS@megatron.ietf.org; Thu, 17 Nov 2005 13:11:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11292 for ; Thu, 17 Nov 2005 13:10:47 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcoVs-0003Ov-Gh for MAVS@ietf.org; Thu, 17 Nov 2005 13:29:38 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2005 10:11:10 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAHIAhsM029369 for ; Thu, 17 Nov 2005 10:11:08 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 13:11:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5EBA2.47D96C1F" Date: Thu, 17 Nov 2005 13:11:06 -0500 Message-ID: <9A3A6AC97A8CF44DACD99DC00BEC235A0DDA2A@xmb-rtp-203.amer.cisco.com> X-MS-Has-Attach: yes Thread-Topic: Latest mavs requirements draft for review Thread-Index: AcXrokdeG5LEu0jqRd6N8o6gSVfFow== From: "Jim Guichard \(jguichar\)" To: X-OriginalArrivalTime: 17 Nov 2005 18:11:07.0298 (UTC) FILETIME=[47DF6820:01C5EBA2] X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b46f883d051ec9bb02ad32011a213d1 X-Mailman-Approved-At: Thu, 17 Nov 2005 13:13:07 -0500 Cc: Subject: [Mavs] Latest mavs requirements draft for review X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EBA2.47D96C1F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C5EBA2.47D96C1F" ------_=_NextPart_002_01C5EBA2.47D96C1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see the attached and provide comment .. regards, =20 Jim Guichard CCIE# 2069 Principal Engineer - MPLS Technologies "A rich person is not one who has the most, but is one who needs the least" =20 =20 ------_=_NextPart_002_01C5EBA2.47D96C1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please = see the=20 attached and provide comment .. regards,
 

Jim Guichard CCIE# 2069
Principal = Engineer - MPLS=20 Technologies


"A rich = person is not=20 one who has the most, but is one who needs the least"

 

 
------_=_NextPart_002_01C5EBA2.47D96C1F-- ------_=_NextPart_001_01C5EBA2.47D96C1F Content-Type: text/plain; name="draft-halstead-guichard-mavs-requirements-00-v3.txt" Content-Transfer-Encoding: base64 Content-Description: draft-halstead-guichard-mavs-requirements-00-v3.txt Content-Disposition: attachment; filename="draft-halstead-guichard-mavs-requirements-00-v3.txt" Content-Transfer-Encoding: base64 ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1hcnRpbiBIYWxzdGVhZCANCiAgICAgSUVURiBJbnRlcm5ldCBEcmFmdCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV4YWdlbnQgTHRkIA0KICAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEppbSBHdWljaGFyZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zLCBJbmMuIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgIEV4cGlyZXM6IE1heSAyMDA2ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciAxNywgMjAwNSANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICANCiAgICAgICANCiAgICAgICAgICAgICAg ICAgICBkcmFmdC1IYWxzdGVhZC1HdWljaGFyZC1NQVZTLVJlcXVpcmVtZW50cy0wMCANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICBS ZXF1aXJlbWVudHMgZm9yIE11bHRpIEF1dG9ub21vdXMgU3lzdGVtIFZQTiBzZXJ2aWNlcyANCg0K DQogICAgIFN0YXR1cyBvZiB0aGlzIE1lbW8gDQoNCiAgICAgICAgVGhpcyBtZW1vIHByb3ZpZGVz IGluZm9ybWF0aW9uIGZvciB0aGUgSW50ZXJuZXQgY29tbXVuaXR5LiBJdCBkb2VzIA0KICAgICAg ICBub3Qgc3BlY2lmeSBhbiBJbnRlcm5ldCBzdGFuZGFyZCBvZiBhbnkga2luZC4gRGlzdHJpYnV0 aW9uIG9mIHRoaXMgDQogICAgICAgIG1lbW8gaXMgdW5saW1pdGVkLiANCg0KICAgICBDb3B5cmln aHQgTm90aWNlIA0KDQogICAgICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkg KDIwMDUpLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQoNCiAgICAgQWJzdHJhY3QgDQoNCiAgICAg VGhpcyBkb2N1bWVudCBjb21wbGVtZW50cyBbUkZDNDAzMV0gYW5kIGRlZmluZXMgcmVxdWlyZW1l bnRzIHRoYXQgYXJlIA0KICAgICBzcGVjaWZpYyB0byB0aGUgcHJvdmlzaW9uaW5nIG9mIFZQTiBz ZXJ2aWNlcywgcG90ZW50aWFsbHkgYXQgdGhlIHNjYWxlIA0KICAgICBvZiB0aGUgSW50ZXJuZXQu IFRoZXNlIHJlcXVpcmVtZW50cyBhcmUgaW5kZXBlbmRlbnQgb2YgdW5kZXJseWluZyANCiAgICAg dGVjaG5vbG9naWVzIG9yIHRoZSBudW1iZXIgb2YgQXV0b25vbW91cyBTeXN0ZW1zIHN1Y2ggVlBO cyBtYXkgc3Bhbi4gSW4gDQogICAgIGFkZGl0aW9uLCBpdCBsaXN0cyB0aGUgcmVxdWlyZW1lbnRz IG9mIHRoZSBkaWZmZXJlbnQgZW50aXRpZXMgdGhhdCBhcmUgDQogICAgIGludm9sdmVkIGluIHRo ZSBhZG1pbmlzdHJhdGlvbiBvZiB0aGVzZSBBdXRvbm9tb3VzIFN5c3RlbXMgYW5kIG1heSANCiAg ICAgdGhlcmVmb3JlIGJlIGludm9sdmVkIGluIHRoZSBwcm92aXNpb25pbmcgcHJvY2Vzc2VzIG9m IHRoZSBWUE4gc2VydmljZSANCiAgICAgb2ZmZXJpbmdzLiAgDQoNCiAgICAgQ29udmVudGlvbnMg dXNlZCBpbiB0aGlzIGRvY3VtZW50ICANCg0KICAgICAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0KICAgICAgICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05B TCIgaW4gdGhpcyANCiAgICAgICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRl c2NyaWJlZCBpbiBSRkMtMjExOS4gIA0KDQogICAgIFRhYmxlIG9mIENvbnRlbnRzIA0KDQogICAg ICAgICANCiAgICAgICAgMS4gSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMiANCiAgICAgICAgMi4gQ29udHJpYnV0aW5nIEF1dGhv cnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgICAgICAg My4gRGVmaW5pdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMyANCiAgICAgIA0KICAgICAgDQogICAgICANCiAgICAgSGFsc3RlYWQgICAgICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA2ICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0g DQogICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgIEludGVybmV0LURyYWZ0IGRyYWZ0 LWhhbHN0ZWFkLWd1aWNoYXJkLU1BVlMtcmVxdWlyZW1lbnRzICAgTm92ZW1iZXIgMjAwNSANCiAg ICAgICAgIA0KDQogICAgICAgIDQuIE11bHRpIE5ldHdvcmsgRW52aXJvbm1lbnQgUmVmZXJlbmNl IE1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICAgICAgICAgIDQuMS4gRGlzdHJpYnV0 ZWQgQWdlbnQgTXVsdGkgTmV0d29yayBFbnZpcm9ubWVudC4uLi4uLi4uLi4uLi4uLjYgDQogICAg ICAgICAgIDQuMi4gQ2VudHJhbGl6ZWQgQWdlbnQgTXVsdGkgTmV0d29yayBFbnZpcm9ubWVudC4u Li4uLi4uLi4uLi4uLjcgDQogICAgICAgICAgICAgIDQuMi4xLiBFbnRlcnByaXNlIElUIERlcGFy dG1lbnQgYXMgdGhlIENlbnRyYWxpemVkIEFnZW50Li4uLjcgDQogICAgICAgICAgICAgIDQuMi4y LiBJbnRlZ3JhdGlvbiBTZXJ2aWNlIFByb3ZpZGVyIGFzIHRoZSBDZW50cmFsaXplZCBBZ2VudDcg DQogICAgICAgIDUuIFByb2JsZW0gU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgICAgIDYuIEN1c3RvbWVyIEFnZW50IE1ORSBSZXF1 aXJlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICAgICAgIDYu MS4gQ2FwaXRhbCBTY2FsaW5nIFJlcXVpcmVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjggDQogICAgICAgICAgIDYuMi4gT3BlcmF0aW9uYWwgU2NhbGluZyBSZXF1aXJlbWVudC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICAgICAgICAgIDYuMi4xLiBTZXJ2aWNl IEluZGVwZW5kZW5jZSBSZXF1aXJlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICAgICAg ICAgICAgIDYuMi4yLiBNaW5pbWl6ZSBOZXR3b3JrIEludGVncmF0aW9uIFJlcXVpcmVtZW50Li4u Li4uLi4uLi4uLjkgDQogICAgICAgICAgICBXaGF0J3MgdGhlICJ0cmFuc2l0aXZpdHkiIHByb2Js ZW0/IFRoZSBpbXBhY3Qgb2YgYSBiaWxhdGVyYWwgDQogICAgICAgICAgIGFncmVlbWVudCAoaW50 ZXJjb25uZWN0IGRlc2lnbikgb24gb3RoZXIgYWdyZWVtZW50cz8uLi4uLi5FcnJvciEgDQogICAg ICAgICAgIEJvb2ttYXJrIG5vdCBkZWZpbmVkLiANCiAgICAgICAgICAgNi4zLiBTZXJ2aWNlIFBy b3ZpZGVyIFZQTiBQb2xpY3kgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgICAg ICAgICAgICAgNi4zLjEuIFZQTiBUb3BvbG9neSBSZXF1aXJlbWVudC4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uOSANCiAgICAgICAgICAgICAgNi4zLjIuIEVuZC10by1lbmQgUW9TIFBvbGlj eSBSZXF1aXJlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4xMCANCiAgICAgICAgICAgICAgNi4zLjMu IE9wdGltYWwgSW50ZXJjb25uZWN0IFNlbGVjdGlvbiBSZXF1aXJlbWVudC4uLi4uLi4uLi4xMSAN CiAgICAgICAgICAgICAgNi4zLjQuIEVuZC10by1lbmQgVW5pY2FzdCBSb3V0aW5nIFBvbGljeSBS ZXF1aXJlbWVudC4uLi4uLi4xMSANCiAgICAgICAgICAgICAgNi4zLjUuIEVuZC10by1FbmQgTXVs dGljYXN0IFJvdXRpbmcgUmVxdWlyZW1lbnQuLi4uLi4uLi4uLi4xMiANCiAgICAgICAgICAgICAg Ni4zLjYuIEhvbW9nZW5vdXMgTWVhc3VyZW1lbnQgUmVxdWlyZW1lbnQuLi4uLi4uLi4uLi4uLi4u Li4xMiANCiAgICAgICAgICAgNi40LiBSZW1vdGUgU2VydmljZSBJbnRlcmNvbm5lY3QgUmVxdWly ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4xMiANCiAgICAgICAgICAgNi41LiBSZWR1bmRhbnQgSW50 ZXJjb25uZWN0IFJlcXVpcmVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyANCiAgICAgICAg ICAgNi42LiBTZWN1cml0eSBSZXF1aXJlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4xMyANCiAgICAgICAgICAgNi43LiBUaGlyZCBQYXJ0eSBJbnRlcmNvbm5lY3QgUmVx dWlyZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyANCiAgICAgICAgNy4gQ29uY2x1c2lvbnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNCANCiAg ICAgICAgOC4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xNCANCiAgICAgICAgOS4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNCANCiAgICAgICAgICAgOS4xLiBO b3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x NCANCiAgICAgICAgICAgOS4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xNCANCiAgICAgICAgQXV0aG9yJ3MgQWRkcmVzc2VzLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNCANCiAgICAgICAgSW50 ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xNCANCiAgICAgICAgRGlzY2xhaW1lciBvZiBWYWxpZGl0eS4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgICAgICAgQ29weXJpZ2h0IFN0YXRlbWVu dC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNSANCiAgICAg ICAgQWNrbm93bGVkZ21lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4xNSANCiAgICAgICAgIA0KDQogICAgIDEuIEludHJvZHVjdGlvbiANCg0KICAg ICAgICBUaGlzIGRvY3VtZW50IHN1bW1hcml6ZXMgYSBsaXN0IG9mIHJlcXVpcmVtZW50cyBzcGVj aWZpZWQgYnkgYWxsIA0KICAgICAgICBwYXJ0aWVzIGludm9sdmVkIGluIHRoZSBkZWxpdmVyeSBv ZiBWUE4gc2VydmljZXMgdGhhdCBzcGFuIG11bHRpcGxlIA0KICAgICAgICBBdXRvbm9tb3VzIFN5 c3RlbXMgb24gYmVoYWxmIG9mIHRoZWlyIGVuZCBjdXN0b21lcnMuIFN1Y2ggcGFydGllcyANCiAg ICAgICAgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bywgRW50ZXJwcmlzZSBJVCBkZXBh cnRtZW50cywgTmV0d29yayANCiAgICAgICAgU2VydmljZSBQcm92aWRlcnMgKE5TUCksIFN5c3Rl bXMgSW50ZWdyYXRvcnMgKFNJKSwgTmV0d29yayANCiAgICAgICAgSW50ZWdyYXRvcnMgKE5JKSBh bmQgVmlydHVhbCBOZXR3b3JrIE9wZXJhdG9ycyAoVk5PKS4gU2VjdGlvbiAzIA0KICAgICAgICBz cGVjaWZpZXMgdGhlIHJvbGVzIG9mIHRoZXNlIHBhcnRpZXMsIHdoaWxlIHNlY3Rpb24gNCBkZXRh aWxzIA0KICAgICAgICBleGFtcGxlcyBvZiBlYWNoIG9wZXJhdG9yIHR5cGUgYW5kIGhvdyB0aGVz ZSBvcGVyYXRvcnMgaW50ZXJhY3QgdG8gDQogICAgICANCiAgICAgIA0KICAgICBIYWxzdGVhZCAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDYgICAgICAgICAgICAgICAgICBbUGFn ZSAyXSANCiAgICAgICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICBJbnRlcm5ldC1E cmFmdCBkcmFmdC1oYWxzdGVhZC1ndWljaGFyZC1NQVZTLXJlcXVpcmVtZW50cyAgIE5vdmVtYmVy IDIwMDUgDQogICAgICAgICANCg0KICAgICAgICBkZWxpdmVyIFZQTiBzZXJ2aWNlcy4gU2VjdGlv biA2IGxpc3RzIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIHBhcnRpZXMgDQogICAgICAgIGludm9s dmVkIGluIHRoZSBkZWxpdmVyeSBvZiBtdWx0aS1BUyBzcGVjaWZpYyBWUE4gc2VydmljZXMuICAg ICAgICANCg0KICAgICAyLiBDb250cmlidXRpbmcgQXV0aG9ycyANCg0KICAgICAgICBUaGlzIGRv Y3VtZW50IGlzIHRoZSBjb21iaW5lZCBlZmZvcnQgb2YgdGhlIHR3byBjby1lZGl0b3JzIGFuZCB0 aGUgDQogICAgICAgIGZvbGxvd2luZyBjb250cmlidXRpbmcgYXV0aG9yczogDQoNCiAgICAgICAg Q2hyaXN0aWFuIEphY3F1ZW5ldCANCg0KICAgICAgICBEaW1pdHJpIFBhcGFkaW1pdHJpb3UgDQoN CiAgICAgICAgSmFtZXMgSHVtcGhyaXMgDQoNCiAgICAgICAgQ29saW4gU2ltcHNvbiANCg0KICAg ICAzLiBEZWZpbml0aW9ucyANCg0KICAgICAgICBJbiBvcmRlciB0byBjbGFyaWZ5IHRoZSByZXF1 aXJlbWVudHMgbGlzdGVkIGluIHRoaXMgZG9jdW1lbnQsIGl0IGlzIA0KICAgICAgICBuZWNlc3Nh cnkgdG8gZGVmaW5lIHRoZSBwYXJ0aWVzIHRoYXQgY29udHJpYnV0ZSB0b3dhcmRzIGRlbGl2ZXJp bmcgDQogICAgICAgIHRoZSBtdWx0aSBwcm92aWRlciBWUE4gc2VydmljZS4gU29tZSBvZiB0aGUg dGVybWlub2xvZ3kgdXNlZCBpbiB0aGlzIA0KICAgICAgICBkb2N1bWVudCBpcyB0YWtlbiBmcm9t IFtQUFZQTi1URVJNXSBhbmQgW1JGQzQwMzFdLiAgQWRkaXRpb25hbCANCiAgICAgICAgdGVybWlu b2xvZ3kgc3BlY2lmaWMgdG8gbXVsdGkgcHJvdmlkZXIgVlBOIHNlcnZpY2VzIGlzIGRlZmluZWQg YXMgDQogICAgICAgIGZvbGxvd3M6IA0KDQogICAgIE11bHRpIE5ldHdvcmsgRW52aXJvbm1lbnQg KE1ORSk6IFR3byBvciBtb3JlIEF1dG9ub21vdXMgU3lzdGVtcyB0aGF0IA0KICAgICAgIGludGVy Y29ubmVjdCBWUE4gc2VydmljZSBlbmRwb2ludHMgKHNpdGVzKSBvZiBhIGNvbW1vbiBzdWJzY3Jp YmVyIA0KDQogICAgIFZQTiBQZWVyaW5nIExvY2F0aW9uIChWUEwpOiBBIHBoeXNpY2FsIGxvY2F0 aW9uIHdoZXJlIHR3byBvciBtb3JlIE5TUCANCiAgICAgICBWUE4gc2VydmljZSBkb21haW5zIGFy ZSBpbnRlcmNvbm5lY3RlZC4gQW4gTlNQIG9yIFNQIG1heSBvcGVyYXRlIHRoZSANCiAgICAgICBW UEwuIEV4YW1wbGVzIG9mIFZQTHMgaW5jbHVkZSBhIG5ldHdvcmsgb3BlcmF0b3IgaG90ZWwsIFNQ IGNlbnRyYWwgDQogICAgICAgb2ZmaWNlLCBhIGNvbGxvY2F0aW9uIGZhY2lsaXR5IG9yIGFueSBi dWlsZGluZyBjb21tb24gdG8gdHdvIG9yIG1vcmUgDQogICAgICAgU1BzLiAgDQoNCiAgICAgQ3Vz dG9tZXI6IEEgY3VzdG9tZXIgaXMgYSBzaW5nbGUgb3JnYW5pemF0aW9uLCBjb3Jwb3JhdGlvbiwg b3IgDQogICAgICAgZW50ZXJwcmlzZSB0aGF0IGFkbWluaXN0cmF0aXZlbHkgY29udHJvbHMgYSBz ZXQgb2Ygc2l0ZXMuIFRoZSANCiAgICAgICBjdXN0b21lciBmb3IgdGhlIHB1cnBvc2VzIG9mIHRo aXMgZG9jdW1lbnQgaGFzIHRoZWlyIFZQTiBzZXJ2aWNlcyANCiAgICAgICBkZWxpdmVyZWQgdmlh IGEgTU5FLiBFeGFtcGxlcyBvZiBjdXN0b21lcnMgaW5jbHVkZSBNdWx0aSBOYXRpb25hbCANCiAg ICAgICBDb3Jwb3JhdGlvbnMgYW5kIFNtYWxsIHRvIE1lZGl1bSBFbnRlcnByaXNlcy4gDQoNCiAg ICAgU2VydmljZSBQcm92aWRlciAoU1ApOiBBIFNQIGlzIGFuIG9wZXJhdG9yIHdobyBkZWxpdmVy cyBzb21lIGFzcGVjdCBvZiBhIA0KICAgICAgIFZQTiBzZXJ2aWNlIHRvIGEgY3VzdG9tZXIuIElu IGRlbGl2ZXJpbmcgdGhlIFZQTiBzZXJ2aWNlLCB0aGUgU1AgbWF5IA0KICAgICAgIG9yIG1heSBu b3Qgb3duIG5ldHdvcmtpbmcgZm9vdHByaW50LiBFeGFtcGxlcyBvZiBTUHMgaW5jbHVkZSBOZXR3 b3JrIA0KICAgICAgIFNlcnZpY2UgUHJvdmlkZXJzIChOU1ApLCBTeXN0ZW1zIEludGVncmF0b3Jz IChTSSksIE5ldHdvcmsgSW50ZWdyYXRvciANCiAgICAgICAoTkkpLCBDYWJsZSBPcGVyYXRvciAo Q08pLCBNb2JpbGUgT3BlcmF0b3IgKE1PKSBhbmQgVmlydHVhbCBOZXR3b3JrIA0KICAgICAgIE9w ZXJhdG9ycyAoVk5PKS4gDQoNCiAgICAgIA0KICAgICAgDQogICAgIEhhbHN0ZWFkICAgICAgICAg ICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwNiAgICAgICAgICAgICAgICAgIFtQYWdlIDNdIA0K ICAgICAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgIEludGVybmV0LURyYWZ0IGRy YWZ0LWhhbHN0ZWFkLWd1aWNoYXJkLU1BVlMtcmVxdWlyZW1lbnRzICAgTm92ZW1iZXIgMjAwNSAN CiAgICAgICAgIA0KDQogICAgIE5ldHdvcmsgU2VydmljZSBQcm92aWRlciAoTlNQKTogQSBOU1Ag aXMgZGVmaW5lZCBhcyBhbnkgb3BlcmF0b3IgdGhhdCANCiAgICAgICB1dGlsaXplcyB0aGVpciBw cml2YXRlIG5ldHdvcmsgZm9vdHByaW50IGZvciB0aGUgZGVsaXZlcnkgb2YgVlBOIA0KICAgICAg IHNlcnZpY2VzLiBOU1BzIHR5cGljYWxseSBvcGVyYXRlIG9uZSBvciBtb3JlIFBhY2tldCBTd2l0 Y2hlZCBOZXR3b3JrcyANCiAgICAgICAoUFNOcykuIEV4YW1wbGVzIGluY2x1ZGUgVHJhbnNwb3J0 IFNlcnZpY2UgUHJvdmlkZXJzLCBTeXN0ZW1zIA0KICAgICAgIEludGVncmF0b3JzLCBDYWJsZSBP cGVyYXRvcnMsIGFuZCBNb2JpbGUgT3BlcmF0b3JzLiANCg0KICAgICBBZ2VudDogQW4gQWdlbnQg aXMgYSBzZXQgb2YgU1BzIGFuZC9vciBOU1BzIGRlc2lnbmF0ZWQgYnkgYSBjdXN0b21lciB3aG8g DQogICAgICAgaGF2ZSB0aGUgYXV0aG9yaXphdGlvbiB0byBtYW5hZ2UgYSBjdXN0b21lcidzIFZQ TiBzZXJ2aWNlIG9mZmVyaW5nLiANCiAgICAgICBUaGUgbWFuYWdlbWVudCByZWxhdGlvbnNoaXAg dGhlIEFnZW50IGhhcyB3aXRoIHRoZSBjdXN0b21lciBjb3VsZCBiZSANCiAgICAgICBidXNpbmVz cyAoY29udHJhY3R1YWwpIGFuZC9vciBvcGVyYXRpb25hbC4gVGhlIGNvbnRyYWN0dWFsIG1hbmFn ZW1lbnQgDQogICAgICAgcmVsYXRpb25zaGlwIG1hbmRhdGVzIHRoYXQgdGhlIEFnZW50IHdpbGwg YmUgcmVzcG9uc2libGUgZm9yIA0KICAgICAgIGZ1bGZpbGxpbmcgdGhlIGN1c3RvbWVyknMgcmVx dWlyZW1lbnRzIGZvciB0aGUgZW5mb3JjZW1lbnQgb2YgYSBzZXQgDQogICAgICAgb2YgcG9saWNp ZXMgd2l0aGluIGEgTU5FLiBUaGlzIFBvbGljeSBBZ2VudCBmdW5jdGlvbiBjb3VsZCwgaW4gDQog ICAgICAgYWRkaXRpb24gaW5jbHVkZSBhbiBvcGVyYXRpb25hbCBtYW5hZ2VtZW50IGNhcGFiaWxp dHkgdGhhdCBhbGxvd3MgDQogICAgICAgdGhlbSB0byBvcGVyYXRpb25hbGx5IGFncmVlIG9yIGNv b3JkaW5hdGUgcG9saWNpZXMgYWNyb3NzIHRoZSBwYXJ0aWVzIA0KICAgICAgIGludm9sdmVkIGlu IGRlbGl2ZXJpbmcgdGhlIGVuZC10by1lbmQgc2VydmljZSB2aWEgYSBNTkUuIFRoaXMgDQogICAg ICAgYWRkaXRpb25hbCBvcGVyYXRpb25hbCAoT3BzKSBhZ2VudCBmdW5jdGlvbiBtYXkgYmUgZGlz dHJpYnV0ZWQgb3IgDQogICAgICAgY2VudHJhbGl6ZWQuIFdoZXJlIHRoZSBPcHMgQWdlbnQgaXMg YSBOU1AsIHRoZSBOU1AgT3BzIEFnZW50IG1heSANCiAgICAgICBjb21tdW5pY2F0ZSBiZXR3ZWVu IGFsbCByZWxldmFudCBOU1AgT3BzIEFnZW50cyB0byBhZ3JlZSB1cG9uIHRoZSANCiAgICAgICBl bmZvcmNlbWVudCBvZiBjb25zaXN0ZW50IHBvbGljaWVzIGZvciBWUE4gc2VydmljZSBwcm92aXNp b25pbmcgDQogICAgICAgcHVycG9zZXMuIEluIHRoaXMgY2FzZSwgdGhlIGZ1bmN0aW9uIG9mIHRo ZSBPcHMgQWdlbnQgaXMgZGlzdHJpYnV0ZWQgDQogICAgICAgYWNyb3NzIG11bHRpcGxlIFNQcy4g QWx0ZXJuYXRpdmVseSwgdGhlIGN1c3RvbWVyIG9yIHBvbGljeSBhZ2VudCBtYXkgDQogICAgICAg ZGVmaW5lIHRoZWlyIHJvdXRpbmcgcmVxdWlyZW1lbnRzIGFuZCBvdXRzb3VyY2UgdGhlaXIgTU5F IHNlcnZpY2UgDQogICAgICAgcG9saWN5IHRvIGFuIE9wcyBBZ2VudCwgc3VjaCBhcyBhIE5TUCwg U0ksIFZOTywgQ08gb3IgTU8sIHdobyB3aWxsIA0KICAgICAgIGNlbnRyYWxseSBjb29yZGluYXRl IHRoZSBlbmZvcmNlbWVudCBvZiBwb2xpY2llcyByZWxhdGVkIHRvIHRoZSANCiAgICAgICBwcm92 aXNpb25pbmcgb2YgYSBWUE4gc2VydmljZS4gSW4gY29udHJhc3QgdG8gdGhlIGRpc3RyaWJ1dGVk IE9wcyANCiAgICAgICBBZ2VudCwgdGhlIGNlbnRyYWxpemVkIE9wcyBBZ2VudCBtYXkgbm90IHJl cXVpcmUgZW5kLXRvLWVuZCBhZ3JlZW1lbnQgDQogICAgICAgb2Ygc2VydmljZSBwb2xpY3kgYWNy b3NzIGFsbCBwYXJ0aWVzIHRoYXQgc3VwcGx5IHNlcnZpY2VzIHRvIGhpcyBNTkUuIA0KICAgICAg IEluIGFkZGl0aW9uLCBpdCBpcyBvZiBpbXBvcnRhbmNlIHRvIGludHJvZHVjZSB0aGUgbm90aW9u IG9mIFBvbGljeSANCiAgICAgICBSZXBvc2l0b3J5LiBUaGUgUG9saWN5IFJlcG9zaXRvcnkgbWF5 IGJlIGNvLWxvY2F0ZWQgd2l0aCB0aGUgT3BzIA0KICAgICAgIEFnZW50IG9yIGV4aXN0IGFzIHNl cGFyYXRlIGVudGl0aWVzLiAgDQoNCiAgICAgUG9saWN5IEFnZW50IChQQSk6IFRoZSBhdXRob3Jp dHkvYXV0aG9yaXRpZXMgcmVzcG9uc2libGUgZm9yIGZ1bGZpbGxpbmcgDQogICAgICAgdGhlIGN1 c3RvbWVyknMgcmVxdWlyZW1lbnRzIGZvciB0aGUgZW5mb3JjZW1lbnQgb2YgYSBzZXQgb2YgcG9s aWNpZXMgDQogICAgICAgd2l0aGluIGEgTU5FLiBUeXBpY2FsbHkgYSBQQSB3aWxsIGV4aXN0IHBl ciBTUCwgYW5kIGFyZSBhc3N1bWVkIHRvIA0KICAgICAgIGNvbW11bmljYXRlIGJldHdlZW4gYWxs IHJlbGV2YW50IFBBIHBhcnRpZXMgdG8gYWdyZWUgdXBvbiB0aGUgDQogICAgICAgZW5mb3JjZW1l bnQgb2YgY29uc2lzdGVudCBwb2xpY2llcyBmb3IgVlBOIHNlcnZpY2UgcHJvdmlzaW9uaW5nIA0K ICAgICAgIHB1cnBvc2VzLiBUaGUgY3VzdG9tZXIgbWF5IGJlIHJlc3BvbnNpYmxlIGZvciBzcGVj aWZ5aW5nIHRoZWlyIE1ORSANCiAgICAgICBzZXJ2aWNlIHBvbGljeS4gQWx0ZXJuYXRpdmVseSwg dGhlIGN1c3RvbWVyIG1heSBkZWZpbmUgdGhlaXIgcm91dGluZyANCiAgICAgICByZXF1aXJlbWVu dHMgYW5kIG91dHNvdXJjZSB0aGVpciBNTkUgc2VydmljZSBwb2xpY3kgdG8gYSBjdXN0b21lciAN CiAgICAgICBhZ2VudCBzdWNoIGFzIGEgU2VydmljZSBQcm92aWRlciwgU3lzdGVtcyBJbnRlZ3Jh dG9yLCBDYWJsZSBPcGVyYXRvciwgDQogICAgICAgTW9iaWxlIE9wZXJhdG9yIG9yIFZpcnR1YWwg TmV0d29yayBPcGVyYXRvciB3aG8gaW4gdGhpcyBjYXNlIHdvdWxkIGJlIA0KICAgICAgIG9uZSBv ZiB0aGUgcG9zc2libGUgUEEgaW52b2x2ZWQgaW4gdGhlIGVuZm9yY2VtZW50IG9mIHBvbGljaWVz IA0KICAgICAgIHJlbGF0ZWQgdG8gdGhlIHByb3Zpc2lvbmluZyBvZiBhIFZQTiBzZXJ2aWNlLiBQ b2xpY3kgQWdlbnRzIGFyZSANCiAgICAgICB1c3VhbGx5IGRyaXZlbiBieSBQb2xpY3kgTWFuYWdl cnMgKGhlcmUgcmVmZXJyZWQgdG8gYXMgYSBwb2xpY3kgDQogICAgICAgb3JjaGVzdHJhdG9yIChQ TykpOyBpbiBhZGRpdGlvbiB0byB0aGlzIGl0IGlzIG9mIGltcG9ydGFuY2UgdG8gDQoNCiAgICAg IA0KICAgICAgDQogICAgIEhhbHN0ZWFkICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNywg MjAwNiAgICAgICAgICAgICAgICAgIFtQYWdlIDRdIA0KICAgICAgICAgDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQogICAgIEludGVybmV0LURyYWZ0IGRyYWZ0LWhhbHN0ZWFkLWd1aWNoYXJkLU1B VlMtcmVxdWlyZW1lbnRzICAgTm92ZW1iZXIgMjAwNSANCiAgICAgICAgIA0KDQogICAgICAgaW50 cm9kdWNlIHRoZSBub3Rpb24gb2YgUG9saWN5IHJlcG9zaXRvcnk7IHRoZXkgbWF5IGJlIGNvLWxv Y2F0ZWQgDQogICAgICAgd2l0aCB0aGUgUE8gb3IgYmUgc2VwYXJhdGUgZW50aXRpZXMuICANCg0K ICAgICBQb2xpY3kgT3JjaGVzdHJhdG9yIChQTyk6IFRoZSBhdXRob3JpdHkgcmVzcG9uc2libGUg Zm9yIHRoZSBwaHlzaWNhbCBhbmQgDQogICAgICAgbG9naWNhbCBpbnRlZ3JhdGlvbiBvZiB0aGUg TU5FLiBJbiBhZGRpdGlvbiwgdGhlIFBPIGlzIHJlc3BvbnNpYmxlIA0KICAgICAgIGZvciB0aGUg b3BlcmF0aW9uIGFuZCBtdWx0aSBwYXJ0eSBidXNpbmVzcyBwcm9jZXNzIGRlZmluaXRpb25zIG9u IA0KICAgICAgIGJlaGFsZiBvZiB0aGUgUEEuIFRoZSBQQSBtYXkgZGlyZWN0bHkgZnVsZmlsbCB0 aGUgbXVsdGktcHJvdmlkZXIgVlBOIA0KICAgICAgIHNlcnZpY2UgYnkgcGVyZm9ybWluZyB0aGUg aW50ZWdyYXRpb24gb2YgdGhlIG11bHRpIHByb3ZpZGVycyBWUE4gDQogICAgICAgZW52aXJvbm1l bnQgdGhlbXNlbHZlcyAtIGluIHRoaXMgY2FzZSB0aGUgUEEgd291bGQgYWxzbyBiZSB0aGUgUE8u IA0KICAgICAgIEFsdGVybmF0aXZlbHksIHRoZSBQQSBtYXkgb3V0c291cmNlIHRoZSBwaHlzaWNh bCBhbmQgbG9naWNhbCANCiAgICAgICBmdWxmaWxsbWVudCBhcyB3ZWxsIGFzIGludGVyY29ubmVj dCBwcm9jZXNzZXMgb2YgdGhlIG11bHRpLXByb3ZpZGVyIA0KICAgICAgIFZQTiBzZXJ2aWNlIHRv IGEgdGhpcmQgcGFydHkgkXRyYWRpbmcgY2x1YpIuIFRoZSCRdHJhZGluZyBjbHVikiANCiAgICAg ICBvcGVyYXRvciB3b3VsZCB0aGVuIGJlIHRoZSBQTyBvbiBiZWhhbGYgb2YgdGhlIFBBLiAgDQoN Cg0KICAgICAgDQogICAgICANCiAgICAgSGFsc3RlYWQgICAgICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDE3LCAyMDA2ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0gDQogICAgICAgICANCg0KDQog ICAgIEludGVybmV0LURyYWZ0IGRyYWZ0LWhhbHN0ZWFkLWd1aWNoYXJkLU1BVlMtcmVxdWlyZW1l bnRzICAgTm92ZW1iZXIgMjAwNSANCiAgICAgICAgIA0KDQogICAgIDQuIE11bHRpIE5ldHdvcmsg RW52aXJvbm1lbnQgUmVmZXJlbmNlIE1vZGVsIA0KDQogICAgICAgIEZpZ3VyZSAxIHNob3dzIGEg Z2VuZXJpYyByZWZlcmVuY2UgbW9kZWwgZm9yIGEgTXVsdGkgTmV0d29yayANCiAgICAgICAgRW52 aXJvbm1lbnQuIEl0IHNob3dzIHRoZSByZWxhdGlvbnNoaXBzIHRoYXQgZXhpc3QgYmV0d2VlbiB0 aGUgDQogICAgICAgIHZhcmlvdXMgcGFydGllcyBpbnZvbHZlZCBpbiB0aGUgZXN0YWJsaXNobWVu dCBvZiBWUE4gc2VydmljZXMgdGhhdCANCiAgICAgICAgc3BhbiBtdWx0aXBsZSBwcm92aWRlciBu ZXR3b3Jrcy4gIA0KICAgICAgICAgDQogICAgICAgIHw8LS0tLS0tLS0tLS0tTXVsdGkgTmV0d29y ayBFbnZpcm9ubWVudC0tLS0tLS0tLS0+fCANCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgIFVzZXJzICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgIEN1c3RvbWVyICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgQWdlbnQgICAgICAgICAgICAgICAgICAgICAgfCAN CiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICAgICB8ICAgICAgIFBvbGljeSBBZ2VudCAgIHwgICB8ICAgICAgICAgICAgICAg ICAgICAgIHwgDQogICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCANCiAgICAgICAgfCAgKy0tLS0tLS0tLS0tLS0tLU9wcyBBZ2VudChzKSAt LS0tLS0tLS0tLS0tLSsgICB8IA0KICAgICAgICB8ICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgIHwgICAgICAgICAgIHwgIHwgDQogICAgICAgIHwgIHwgICAgICAgICBOU1AxICAgICAg IFZQTDEgICAgICAgTlNQMiAgICAgICAgfCAgfCANCiAgICAgICAgfCAgfCAgICAgICAgICBeICAg ICAgICAgIF4gICAgICAgICBeICAgICAgICAgICB8ICB8IA0KICAgICAgICB8IDEuLm4gICAgICAg MS4ubiAgICAgIDEuLm4gICAgICAgMS4ubiAgICAgICAxLi5uIHwgDQogICAgICAgIHwgIFYgICAg ICAgICAgViAgICAgICAgICBWICAgICAgICAgViAgICAgICAgICAgViAgfCANCiAgICAgICAgfFNp dGUxIDwtLS0+IFBTTjE8LS0tPihWUEwxKTwtLS0+IFBTTjIgPC0tLT4gU2l0ZTJ8IA0KICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMSAtDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtIE1ORSBSZWZlcmVuY2UgTW9kZWwgDQogICAgICAgICAN CiAgICAgICAgVGhlIGZvbGxvd2luZyBzZWN0aW9uIGRldGFpbHMgZXhhbXBsZXMgb2YgdGhlIGNv b3JkaW5hdGlvbiBvZiB0aGUgDQogICAgICAgIHZhcmlvdXMgcGFydGllcyBpbiB0aGUgZW5mb3Jj ZW1lbnQgb2YgYSBzZXQgb2YgcG9saWNpZXMgaW5jbHVkaW5nLCANCiAgICAgICAgYnV0IG5vdCBu ZWNlc3NhcmlseSBsaW1pdGVkIHRvIGFkZHJlc3NpbmcsIHJvdXRpbmcsIFFvUyBhbmQgc2VjdXJp dHkgDQogICAgICAgIGZvciB0aGUgcHJvdmlzaW9uaW5nIG9mIGFuIGludGVyLWRvbWFpbiBWUE4g c2VydmljZSB0aGF0IHdpbGwgY29tcGx5IA0KICAgICAgICB3aXRoIGEgY3VzdG9tZXJzIHNlcnZp Y2UgcmVxdWlyZW1lbnRzLiANCiAgICAgICAgIA0KICAgICA0LjEuIERpc3RyaWJ1dGVkIEFnZW50 IE11bHRpIE5ldHdvcmsgRW52aXJvbm1lbnQuIA0KDQogICAgICAgIEluIHRoaXMgbW9kZWwsIHRo ZSBNTkUgY29uc2lzdHMgb2YgYSBjb21tdW5pdHkgb2YgU1BzIGFuZC9vciBOU1BzIA0KICAgICAg ICB0aGF0IHVzZSBhbmQgb3BlcmF0ZSB0aGUgbmV0d29yayByZXNvdXJjZXMgb2YgYSBNTkUgZmFj aWxpdHkgdG8gDQogICAgICAgIGRlcGxveSBhbmQgZXhwbG9pdCBhIFZQTiBzZXJ2aWNlIG9mZmVy aW5nLiBUaGUgQ3VzdG9tZXIgd2lsbCBkZWZpbmUgDQogICAgICAgIHRoZWlyIHJvdXRpbmcgcmVx dWlyZW1lbnRzIGFuZCBsZXQgdGhlIFNQIGFuZC9vciBOU1AgZW5mb3JjZSB0aGUgDQogICAgICAg IGNvcnJlc3BvbmRpbmcgcG9saWN5IHRoYXQgYWRkcmVzc2VzIHN1Y2ggcmVxdWlyZW1lbnRzLiBB biBPcHMgQWdlbnQgDQogICAgICAgIHdpbGwgZXhpc3QgcGVyIFNQIGFuZC9vciBOU1AsIGFsbCBv ZiB3aGljaCB3aWxsIGFncmVlIHVwb24gdGhlIA0KICAgICAgICBlbmZvcmNlbWVudCBvZiBjb25z aXN0ZW50IHBvbGljaWVzLiANCiAgICAgICAgIA0KICAgICAgICBXaXRoIHJlZmVyZW5jZSB0byBG aWd1cmUgMSwgdGhlIFBvbGljeSBBZ2VudCBpcyBhIHNpbmdsZSBOU1AgKGVpdGhlciANCiAgICAg ICAgTlNQMSBvciBOU1AyKS4gT3BzIEFnZW50cyB0aGVuIGNvbnNpc3Qgb2YgU1AxIGFuZCBTUDIs IGJvdGggb2Ygd2hpY2ggDQogICAgICAgIHNoYXJlIHRoZSBtYW5hZ2VtZW50IG9mIFZQTDEuIA0K ICAgICAgICAgDQogICAgICANCiAgICAgIA0KICAgICBIYWxzdGVhZCAgICAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgMTcsIDIwMDYgICAgICAgICAgICAgICAgICBbUGFnZSA2XSANCiAgICAgICAg IA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICBJbnRlcm5ldC1EcmFmdCBkcmFmdC1oYWxz dGVhZC1ndWljaGFyZC1NQVZTLXJlcXVpcmVtZW50cyAgIE5vdmVtYmVyIDIwMDUgDQogICAgICAg ICANCg0KICAgICA0LjIuIENlbnRyYWxpemVkIEFnZW50IE11bHRpIE5ldHdvcmsgRW52aXJvbm1l bnQgDQoNCiAgICAgICAgVGhlIGZvbGxvd2luZyBhcmUgZXhhbXBsZXMgb2YgYW4gQWdlbnQgY2Vu dHJhbGx5IGNvb3JkaW5hdGluZyANCiAgICAgICAgc2VydmljZXMgYWNyb3NzIGEgTU5FLiBUaGVz ZSBNTkUgZW52aXJvbm1lbnRzIGFyZSBkZWRpY2F0ZWQgdG8gdGhlIA0KICAgICAgICBjb21tZXJj aWFsIHB1cnBvc2VzIG9mIGEgc2luZ2xlIEFnZW50IGluIGZ1bGZpbGxpbmcgYSBWUE4gc2Vydmlj ZSBvbiANCiAgICAgICAgYmVoYWxmIG9mIHRoZWlyIGN1c3RvbWVyKHMpLiAgIA0KDQogICAgICAg NC4yLjEuIEVudGVycHJpc2UgSVQgRGVwYXJ0bWVudCBhcyB0aGUgQ2VudHJhbGl6ZWQgQWdlbnQg DQoNCiAgICAgICAgVGhlIEFnZW50IGNvdWxkIGJlIGFuIEVudGVycHJpc2UgSVQgZGVwYXJ0bWVu dCB3aG8gaG9sZHMgdGhlIA0KICAgICAgICBDb21tZXJjaWFsIEFnZW50IHJlbGF0aW9uc2hpcCB3 aXRoIHRoZSBjdXN0b21lci4gSW4gYWRkaXRpb24sIHRoZSBJVCANCiAgICAgICAgZGVwYXJ0bWVu dCBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGVuZm9yY2VtZW50IG9mIHRoZSBjdXN0b21lcpJzIA0K ICAgICAgICBuZXR3b3JrIHBvbGljeSBieSBhY3RpbmcgYXMgdGhlIE9wcyBBZ2VudC4gVGhlIElU IGRlcGFydG1lbnQgbWFuYWdlcyANCiAgICAgICAgdGhlIFZQTHMgYW5kIHByb2Nlc3NlcyBpbnZv bHZlZCBpbiBpbnRlcmNvbm5lY3RpbmcgdGhlIFZQTCB0byB0aGUgTlNQIA0KICAgICAgICBWUE4g ZG9tYWlucy4gTlNQMSBhbmQgTlNQMiBpbmRlcGVuZGVudGx5IHByb3ZpZGUgVlBOIHNlcnZpY2Vz IHZpYSANCiAgICAgICAgdGhlaXIgUFNOcyB0byB0aGUgT3BzIEFnZW50IHdobyBpcyByZXNwb25z aWJsZSBmb3IgaW50ZWdyYXRpbmcgZWFjaCANCiAgICAgICAgTlNQcyBWUE4gc2VydmljZSBvZmZl cmluZy4gIA0KDQogICAgICAgNC4yLjIuIEludGVncmF0aW9uIFNlcnZpY2UgUHJvdmlkZXIgYXMg dGhlIENlbnRyYWxpemVkIEFnZW50IA0KDQogICAgICAgIEluIHRoaXMgbW9kZWwsIHRoZSBDb21t ZXJjaWFsIEFnZW50IGNvdWxkIGJlIGFuIEVudGVycHJpc2UgSVQgDQogICAgICAgIGRlcGFydG1l bnQuIFRoZSBJVCBkZXBhcnRtZW50IG91dHNvdXJjZSB0aGVpciBjdXN0b21lcpJzIG5ldHdvcmsg DQogICAgICAgIHBvbGljeSB0byBhbiBPcHMgQWdlbnQgd2hvIGlzIGEgU1Agc3VjaCBhcyBhIFNJ LCBOSSwgVk5PIG9yIE5TUC4gVGhlIA0KICAgICAgICBPcHMgQWdlbnQgd2lsbCBtYW5hZ2UgdGhl IFZQTCBhbmQgYXNzb2NpYXRlZCBWUE4gc2VydmljZXMgDQogICAgICAgIGludGVyY29ubmVjdHMs IGFzIHdlbGwgYXMgY29vcmRpbmF0ZSBlbmQtdG8tZW5kIFZQTiBzZXJ2aWNlcyANCiAgICAgICAg ZGVsaXZlcmVkIGJ5IFNQMSBhbmQgU1AyknMgUFNOIG5ldHdvcmtzLiANCg0KICAgICA1LiBQcm9i bGVtIFN0YXRlbWVudCANCg0KICAgICAgICBObyBzaW5nbGUgbmV0d29yayBjYW4gZGVsaXZlciBW UE4gc2VydmljZXMgdGhhdCBwcm92aWRlIG9wdGltYWwgcHJpY2UgDQogICAgICAgIGFuZCBwZXJm b3JtYW5jZSBmb3IgYWxsIGN1c3RvbWVycyBvciBhbGwgY3VzdG9tZXIgbG9jYXRpb25zLCBpZiBz dWNoIA0KICAgICAgICBsb2NhdGlvbnMgYXJlIGNvbm5lY3RlZCB0aHJvdWdoIGRvbWFpbnMgYWRt aW5pc3RlcmVkIGJ5IGRpZmZlcmVudCANCiAgICAgICAgZW50aXRpZXMuIEZvciByZWd1bGF0b3J5 LCByZXNpbGllbmN5IGFuZCBvdGhlciByZWFzb25zLCBjdXN0b21lcnMgbWF5IA0KICAgICAgICBk ZW1hbmQgdGhhdCBtdWx0aXBsZSBOU1AgbmV0d29ya3MgYXJlIHVzZWQgdG8gZGVsaXZlciB0aGVp ciBWUE4gDQogICAgICAgIHNlcnZpY2VzLiBBcyBhIHJlc3VsdCwgYWdlbnRzIGFjdGluZyBhcyB0 aGUgUEEgaGF2ZSBzdGFydGVkIHRvIA0KICAgICAgICBpbnRlcmNvbm5lY3QgbXVsdGlwbGUgc2Vy dmljZSBwcm92aWRlciBuZXR3b3JrcyB2aWEgYSBQTyB0byBtZWV0IA0KICAgICAgICB0aGVpciBj dXN0b21lcnOSIFZQTiBuZWVkcy4gRm9yIGEgUEGScyBjdXN0b21lcnMsIGVuZC10by1lbmQgc2Vy dmljZSANCiAgICAgICAgZGVsaXZlcnkgaXMgcGFyYW1vdW50LiBDb250cm9sbGFibGUsIHByZWRp Y3RhYmxlIGFuZCByZWxpYWJsZSBWUE4gDQogICAgICAgIHNlcnZpY2UgbXVzdCBiZSBkZWxpdmVy ZWQgcmVnYXJkbGVzcyBvZiB0aGUgTU5FLiAgIA0KDQogICAgICAgIFRoZSBjaGFsbGVuZ2UgZm9y IHRoZSBBZ2VudCBpbiBjb250cm9sbGluZyCRZ2xvYmFskiBzZXJ2aWNlIHBvbGljeSBpbiANCiAg ICAgICAgYW4gTU5FIGVudmlyb25tZW50IGlzIHRoZSBsYWNrIG9mIGhvbW9nZW5vdXMgcG9saWN5 IGFtb25nc3QgTlNQIA0KICAgICAgICBuZXR3b3JrcyBhbmQgdGhlIGRpZmZpY3VsdHkgU1BzIGhh dmUgaW4gYWRhcHRpbmcgdGhlaXIgc2luZ2xlIE5TUCBWUE4gDQogICAgICAgIHNlcnZpY2UgZG9t YWlucyB0byB0aGUgUEEgb3duZWQgVlBOIHNlcnZpY2UgcG9saWN5LiAgIA0KDQogICAgICAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyBjb21tb24gcmVxdWlyZW1lbnRzIGZvciBpbXBsZW1lbnRpbmcg YW5kIA0KICAgICAgICBvcGVyYXRpbmcgYW4gTU5FLiANCiAgICAgIA0KICAgICAgDQogICAgIEhh bHN0ZWFkICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNywgMjAwNiAgICAgICAgICAgICAg ICAgIFtQYWdlIDddIA0KICAgICAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgIElu dGVybmV0LURyYWZ0IGRyYWZ0LWhhbHN0ZWFkLWd1aWNoYXJkLU1BVlMtcmVxdWlyZW1lbnRzICAg Tm92ZW1iZXIgMjAwNSANCiAgICAgICAgIA0KDQogICAgIDYuIEN1c3RvbWVyIEFnZW50IE1ORSBS ZXF1aXJlbWVudHMgDQoNCiAgICAgNi4xLiBDYXBpdGFsIFNjYWxpbmcgUmVxdWlyZW1lbnQgDQoN CiAgICAgICAgSW4gYW4gTU5FLCB0aGVyZSBtaWdodCBiZSBvbmUgb3IgbW9yZSBWUExzLiBBdCBl YWNoIFZQTCB0aGVyZSBtYXkgYmUgDQogICAgICAgIG9uZSBvciBtb3JlIGludGVyY29ubmVjdGVk IE5TUHMsIG9yIGEgc2luZ2xlIG9wZXJhdG9yIHRoYXQgdXNlcyB0aGUgDQogICAgICAgIFZQTCBm b3IgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhlaXIgb3duIEF1dG9ub21vdXMgU3lzdGVtcy4gDQog ICAgICAgIFRyYWRpdGlvbmFsbHksIHRoZSBpbnRlcmNvbm5lY3Rpb24gb2YgdHdvIE5TUHMsIHRo ZSBzbyBjYWxsZWQgDQogICAgICAgIGJpbGF0ZXJhbCBpbnRlcmNvbm5lY3QsIGhhcyByZXN1bHRl ZCBpbiB0aGUgZGVwbG95bWVudCBvZiBuZXR3b3JrIA0KICAgICAgICBlbGVtZW50IHJlc291cmNl cyB0aGF0IGFyZSBlaXRoZXIgZGVkaWNhdGVkIHRvIHRob3NlIHR3byBOU1BzLCBvciANCiAgICAg ICAgbGVhc2VkIGZyb20gdGhlIG93bmVyIG9mIHRoZSBwZWVyaW5nIHBvaW50LiBXaGVyZSB0aGVy ZSBpcyBhIG5lZWQgZm9yIA0KICAgICAgICBhIFNQIHRvIGludGVyY29ubmVjdCB3aXRoIG11bHRp cGxlIG90aGVyIE5TUHMsIGEgc2NhbGluZyBjb3N0LQ0KICAgICAgICBlZmZpY2llbmN5IGNvdWxk IHJlc3VsdCBpZiBpbnRlcmNvbm5lY3RlZCBuZXR3b3JrIGVsZW1lbnRzIGNvdWxkIGJlIA0KICAg ICAgICBzaGFyZWQgYWNyb3NzIGFsbCBTUHMuIFRoaXMgbXVsdGlsYXRlcmFsIGFwcHJvYWNoIHRv IG5ldHdvcmsgDQogICAgICAgIGludGVyY29ubmVjdHMgd291bGQgaGF2ZSBpbmNyZWFzaW5nIGJl bmVmaXQgYXMgdGhlIG51bWJlciBvZiANCiAgICAgICAgaW50ZXJjb25uZWN0ZWQgU1BzIGF0IGEg VlBMIGluY3JlYXNlZC4gSW50ZXJjb25uZWN0ZWQgbmV0d29yayANCiAgICAgICAgZWxlbWVudHMg aW4gYSBNTkUgbXVzdCB0aGVyZWZvcmUgYmUgc2hhcmVkIG11bHRpbGF0ZXJhbGx5LiAgIA0KDQog ICAgIDYuMi4gT3BlcmF0aW9uYWwgU2NhbGluZyBSZXF1aXJlbWVudCANCg0KICAgICAgICBDb3N0 IG9mIG9wZXJhdGlvbnMgaXMgb2YgZ3JlYXQgY29uY2VybiB0byBhIE5TUCwgd2hldGhlciBvciBu b3QgVlBOIA0KICAgICAgICBzZXJ2aWNlcyBzcGFuIHRoZWlyIG93biBBdXRvbm9tb3VzIFN5c3Rl bXMgb3IgdGhvc2Ugb2YgcGFydG5lcnMuIA0KICAgICAgICBDb21wYXJlZCB0byB0aGUgY2FwaXRh bCBjb3N0IG9mIE1ORSBpbnRlcmNvbm5lY3Rpb24sIG9wZXJhdGlvbmFsIGNvc3QgDQogICAgICAg IGVhc2lseSBkb21pbmF0ZXMuIEluIGFuIE1ORSwgc29tZSwgYW5kIHBlcmhhcHMgYWxsIFNQcywg bWlnaHQgcGxheSBhIA0KICAgICAgICBwYXJ0IGluIGFuIGluZGl2aWR1YWwgY3VzdG9tZXIgc29s dXRpb24uIFdpdGhpbiBhIGN1c3RvbWVyIHNvbHV0aW9uLCANCiAgICAgICAgc2l0ZXMsIHBoeXNp Y2FsIGFuZCBsb2dpY2FsIGNvbm5lY3Rpdml0eSwgU1BzLCBpbnRlcmNvbm5lY3RzIGFuZCANCiAg ICAgICAgc2VydmljZSBwb2xpY3kgbWlnaHQgYmUgdmFyaW91c2x5IG1vdmVkLCBhZGRlZCwgY2hh bmdlZCBvciBkZWxldGVkIA0KICAgICAgICAoTUFDRCkgYXQgYW55IHRpbWUuIEluIGZhY3QsIGRp ZmZlcmVudCBjb21wb25lbnRzIG9mIHRoZSBzb2x1dGlvbiANCiAgICAgICAgd2lsbCwgYXQgdGlt ZXMsIHVuZGVyZ28gTUFDRCBjb25jdXJyZW50bHkuIFNlcnZpY2UgTUFDRCBsaWZlY3ljbGUgaXMg DQogICAgICAgIHBhcnQgb2YgYW55IGN1c3RvbWVyIHNvbHV0aW9uIGFuZCB3aWxsIGhhcHBlbiBh cyBuZWVkZWQgdGhyb3VnaG91dCANCiAgICAgICAgdGhlIHNlcnZpY2UgbGlmZS4gQXMgYW4gTU5F IGV2b2x2ZXMsIHdpdGggaW5jcmVhc2luZyBTUHMsIA0KICAgICAgICBpbnRlcmNvbm5lY3RzIGFu ZCBjdXN0b21lcnMsIHRoZSBhbW91bnQgb2Ygc2VydmljZSBNQUNEIHdpbGwgaW5jcmVhc2UgDQog ICAgICAgIGFuZCBwbGFjZSBhIGNvbnRpbnVhbCBhbmQgaW5jcmVhc2luZyBidXJkZW4gb24gc2Vy dmljZSBhZG1pbmlzdHJhdG9ycyANCiAgICAgICAgdGhyb3VnaG91dCB0aGUgTU5FIHVubGVzcyBh IHNjYWxhYmxlIGFwcHJvYWNoIGlzIHRha2VuLiBTb21lIG9mIHRoZSANCiAgICAgICAgbW9yZSBp bXBvcnRhbnQgb3BlcmF0aW9uYWwgc2NhbGluZyBjb25zaWRlcmF0aW9ucyBmb2xsb3cuIA0KDQog ICAgICAgNi4yLjEuIFNlcnZpY2UgSW5kZXBlbmRlbmNlIFJlcXVpcmVtZW50IA0KDQogICAgICAg IEluIGFuIE1ORSwgaXQgaXMgaW5ldml0YWJsZSB0aGF0IGRlcGVuZGVuY2llcyB3aWxsIGV4aXN0 IGJldHdlZW4gdGhlIA0KICAgICAgICBzZXJ2aWNlcyBvZiBpbmRpdmlkdWFsIFNQcy4gRm9yIGV4 YW1wbGUsIGEgbGFjayBvZiBmb3JldGhvdWdodCBieSB0aGUgDQogICAgICAgIE9wcyBhZ2VudCBi eSBpbXBsZW1lbnRpbmcgYSCRdGlnaHRseS1jb3VwbGVkkiBpbnRlcmNvbm5lY3QgDQogICAgICAg IGVudmlyb25tZW50IHdvdWxkIHJlc3VsdCBpbiBzaW5nbGUgTlNQIGNoYW5nZXMgdG8gdG9wb2xv Z3ksIA0KICAgICAgICBiYW5kd2lkdGgsIHJvdXRpbmcsIFFvUyBldGMgcmVxdWlyaW5nIGFsbCBv dGhlciBTUHMgdG8gbW9kaWZ5IHRoZWlyIA0KICAgICAgICBkZWZpbml0aW9ucyBvZiBleGlzdGlu ZyBzZXJ2aWNlcy4gU2VydmljZSBkZXBlbmRlbmNpZXMgYW1vbmdzdCBTUHMgaW4gDQogICAgICAg IGEgTU5FIG11c3QgdGhlcmVmb3JlIGJlIG1pbmltaXplZC4gDQoNCg0KICAgICAgDQogICAgICAN CiAgICAgSGFsc3RlYWQgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA2ICAgICAg ICAgICAgICAgICAgW1BhZ2UgOF0gDQogICAgICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN CiAgICAgSW50ZXJuZXQtRHJhZnQgZHJhZnQtaGFsc3RlYWQtZ3VpY2hhcmQtTUFWUy1yZXF1aXJl bWVudHMgICBOb3ZlbWJlciAyMDA1IA0KICAgICAgICAgDQoNCiAgICAgICA2LjIuMi4gTWluaW1p emUgTmV0d29yayBJbnRlZ3JhdGlvbiBSZXF1aXJlbWVudCANCg0KICAgICAgICBDdXJyZW50bHkg dGhlcmUgaXMgbm8gY29tbW9uIGFncmVlbWVudCBmb3IgaG93IFNQcyBpbXBsZW1lbnQgdGhlIA0K ICAgICAgICBpbnRlcmNvbm5lY3Rpb24gb2YgdGhlaXIgVlBOIG5ldHdvcmtzLiBUaGlzIG1lYW5z IHRoYXQgZWFjaCBpbnN0YW5jZSANCiAgICAgICAgb2YgaW50ZXJjb25uZWN0IGJ5IFNQIHBhaXJz IHdpbGwgYmUgYSB1bmlxdWUgcHJvamVjdCB3aXRoIGRpZmZlcmVudCANCiAgICAgICAgZGVzaWdu IGdvYWxzIGFuZCBjb21wcm9taXNlcy4gRWFjaCB1bmlxdWUgcHJvamVjdCB3aWxsIHRha2UgDQog ICAgICAgIGNvbnNpZGVyYWJsZSB0aW1lIGFuZCBjb25zdW1lIGhpZ2hseSBza2lsbGVkIHJlc291 cmNlcyBpbiBib3RoIA0KICAgICAgICBvcmdhbml6YXRpb25zLiBBcyB0aGUgbnVtYmVyIG9mIGlu dGVyY29ubmVjdHMgaW5jcmVhc2VzLCBzbyB0aGUgbG9hZCANCiAgICAgICAgb24gdGhlIG9yZ2Fu aXphdGlvbnMgd2lsbCBpbmNyZWFzZS4gSW4gYW4gTU5FLCB0aGUgcmVxdWlyZWQgbnVtYmVyIG9m IA0KICAgICAgICB1bmlxdWUgaW50ZXJjb25uZWN0aW9uIHByb2plY3RzIGNvdWxkIHJhcGlkbHkg YmVjb21lIHVudGVuYWJsZS4gDQogICAgICAgIFVuaXF1ZSBuZXR3b3JrIGludGVncmF0aW9uIHBy b2plY3RzIGFtb25nc3QgTlNQIHBhaXJzIG11c3QgdGhlcmVmb3JlIA0KICAgICAgICBiZSBtaW5p bWl6ZWQuICANCg0KICAgICA2LjMuIFNlcnZpY2UgUHJvdmlkZXIgVlBOIFBvbGljeSBDb250cm9s IA0KDQogICAgICAgICANCiAgICAgICA2LjMuMS4gVlBOIFRvcG9sb2d5IFJlcXVpcmVtZW50IA0K DQogICAgICAgIEFsdGhvdWdoIFZQTiBuZXR3b3JrcyBvZmZlciB0aGUgcG9zc2liaWxpdHkgZm9y IGFueSBjdXN0b21lciBzaXRlIHRvIA0KICAgICAgICBjb21tdW5pY2F0ZSB3aXRoIGFueSBvdGhl ciBjdXN0b21lciBzaXRlLCBpbiBjZXJ0YWluIHNpdHVhdGlvbnMgdGhpcyANCiAgICAgICAgaXMg bm90IGRlc2lyYWJsZS4gVGhlcmUgYXJlIG1hbnkgcG9zc2libGUgcmVhc29ucyB3aHkgYSBjdXN0 b21lciANCiAgICAgICAgbWlnaHQgd2FudCB0byByZXN0cmljdCBjb21tdW5pY2F0aW9uIGFtb25n c3Qgc2l0ZXMgc28gdGhhdCB0aGVpciBlbmQtDQogICAgICAgIHRvLWVuZCBzZXJ2aWNlIGJlY29t ZXMgc2VnbWVudGVkLiBGb3IgaW5zdGFuY2UsIGl0IG1heSBiZSB0aGF0IA0KICAgICAgICBzZWN1 cml0eSBpcyBhIGNvbmNlcm4gb3IgaXQgbWF5IGJlIHRoYXQgY29tcGFueSBzaXRlcyBvciBkaXZp c2lvbnMgDQogICAgICAgIG11c3Qgb25seSB1c2UgY29ubmVjdGl2aXR5IHRoZXkgaGF2ZSBwYWlk IGZvci4gRnVydGhlcm1vcmUsIHRoZSANCiAgICAgICAgdHJhZmZpYyBmbG93cyBhc3NvY2lhdGVk IHdpdGggc3BlY2lmaWMgYXBwbGljYXRpb25zIG1heSByZXF1aXJlIGEgDQogICAgICAgIHBhcnRp YWwgdG9wb2xvZ3kgc3BlY2lmaWNhbGx5IHNpemVkIHRvIGFjY29tbW9kYXRlIHRoZSBhZ2dyZWdh dGUgDQogICAgICAgIHRyYWZmaWMgZmxvd3MuICANCg0KICAgICAgICBUaGUgc2VnbWVudGF0aW9u IG1pZ2h0IG5lZWQgdG8gZXhpc3Qgb24gYSBnZW9ncmFwaGljYWwgYmFzaXMsIHJlZ2lvbi0NCiAg ICAgICAgYnktcmVnaW9uLCBjb3VudHJ5LWJ5IGNvdW50cnksIG9yIG9uIGEgY29ycG9yYXRlIGJh c2lzLCBkaXZpc2lvbi1ieS0NCiAgICAgICAgZGl2aXNpb24gb3Igc2l0ZS1ieS1zaXRlLiBTZWdt ZW50YXRpb24gbWlnaHQgZXZlbiBleGlzdCB3aXRoaW4gDQogICAgICAgIGN1c3RvbWVyIHNpdGVz LiBIb3dldmVyLCB0b2RheSwgdGhlcmUgYXJlIG5vIHN0YW5kYXJkcyBmb3Igb3IgDQogICAgICAg IGFncmVlbWVudCBvZiBob3cgVlBOIHRvcG9sb2dpZXMgYXJlIGNvbnN0cnVjdGVkIGFtb25nc3Qg bmV0d29yayANCiAgICAgICAgb3BlcmF0b3JzLiBDb25zZXF1ZW50bHksIG5ldHdvcmsgb3BlcmF0 b3JzIHVzZSBkaWZmZXJlbnQgbWV0aG9kcyBmb3IgDQogICAgICAgIGVzdGFibGlzaGluZyB0aGUg bG9naWNhbCB0b3BvbG9neSBvZiBhIFZQTiBhbmQgdXNlIGRpZmZlcmVudCBzY2hlbWFzIA0KICAg ICAgICB0byBkZWZpbmUgVlBOIG1lbWJlcnNoaXAuIEZvciBpbnN0YW5jZSwgb25lIG5ldHdvcmsg b3BlcmF0b3IgbWlnaHQgDQogICAgICAgIHVzZSBzdGFuZGFyZCBjb21tdW5pdHkgdmFsdWVzIHRv IGVzdGFibGlzaCBsYXllci0yIHRvcG9sb2d5IHdoaWxzdCANCiAgICAgICAgYW5vdGhlciBtaWdo dCB1c2UgZXh0ZW5kZWQgY29tbXVuaXR5IHZhbHVlcy4gWWV0IGFub3RoZXIgbmV0d29yayANCiAg ICAgICAgb3BlcmF0b3IgbWlnaHQgdXNlIGEgY29tYmluYXRpb24gb2YgYm90aC4gQWx0ZXJuYXRp dmVseSwgbmV0d29yayANCiAgICAgICAgb3BlcmF0b3JzIG1pZ2h0IHNlZ21lbnQgVlBOcyB1c2lu ZyBsYXllci0zIHJvdXRpbmcgdGVjaG5pcXVlcy4gSW4gDQogICAgICAgIGZhY3QsIHNvbWUgbmV0 d29yayBvcGVyYXRvcnMgbWlnaHQgY29tYmluZSBsYXllci0yIGFuZCBsYXllci0zIA0KICAgICAg ICBzZWdtZW50YXRpb24gdGVjaG5pcXVlcy4gQWRkaXRpb25hbGx5LCBlYWNoIG5ldHdvcmsgb3Bl cmF0b3Igd2lsbCANCiAgICAgICAgaW1wbGVtZW50IGEgc2NoZW1hIGZvciBWUE4gbWVtYmVyc2hp cCB0aGF0IGlzIHByb3ByaWV0YXJ5LCB3aXRoIA0KICAgICAgICBtZW1iZXJzaGlwIHZhbHVlcyB0 aGF0IGFyZSBsaWtlbHkgdG8gb3ZlcmxhcCBhbmQgY29uZmxpY3Qgd2l0aCBvdGhlciANCiAgICAg ICAgbmV0d29yayBvcGVyYXRvciB2YWx1ZXMuIFZQTiBtZW1iZXJzaGlwIHNjaGVtYXMgdGVuZCB0 byBiZSBkaWZmaWN1bHQgDQogICAgICAgIHRvIG1vZGlmeSBkdWUgdG8gdGhlIJFoYXJkIGNvZGlu Z5Igb2YgdGhlIHNjaGVtYSBpbiBlYWNoIG5ldHdvcmsgDQogICAgICANCiAgICAgIA0KICAgICBI YWxzdGVhZCAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTcsIDIwMDYgICAgICAgICAgICAg ICAgICBbUGFnZSA5XSANCiAgICAgICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICBJ bnRlcm5ldC1EcmFmdCBkcmFmdC1oYWxzdGVhZC1ndWljaGFyZC1NQVZTLXJlcXVpcmVtZW50cyAg IE5vdmVtYmVyIDIwMDUgDQogICAgICAgICANCg0KICAgICAgICBvcGVyYXRvcpJzIE9TUyBhbmQg QlNTLiBDb25mbGljdGluZyBWUE4gbWVtYmVyc2hpcCBzY2hlbWFzIGFuZCANCiAgICAgICAgZGlm ZmVyZW50IG1ldGhvZHMgZm9yIGVzdGFibGlzaGluZyBsb2dpY2FsIHRvcG9sb2d5IG1ha2UgaXQg dmVyeSANCiAgICAgICAgZGlmZmljdWx0IGZvciB0aGUgTU5FIG9wZXJhdG9yIHRvIGVzdGFibGlz aCBhbiBlbmQtdG8tZW5kIFZQTiANCiAgICAgICAgdG9wb2xvZ3kuIE1vcmVvdmVyLCBhbiBpbnZl bnRvcnkgb2YgdGhpcyB0b3BvbG9neSBjb25zaXN0aW5nIG9mIA0KICAgICAgICBlbGVtZW50cyBz dWNoIGFzIHRoZSBuZXR3b3JrIGVsZW1lbnRzL2ludGVyZmFjZXMgYW5kIHRoZSBzZXQgb2YgcGF0 aHMgDQogICAgICAgIHRoYXQgdHJhZmZpYyBtYXkgdGFrZSB0aHJvdWdoIHRoZSBuZXR3b3JrIHNo b3VsZCBiZSBtYWRlIGF2YWlsYWJsZS4gDQogICAgICAgIFRoZXNlIGVsZW1lbnRzIHdpbGwgbW9z dCBsaWtlbHkgY29uc3RpdHV0ZSBhIHBhcnRpYWwgdG9wb2xvZ2ljYWwgdmlldyANCiAgICAgICAg b2YgdGhlIG5ldHdvcmsgYnV0IHdvdWxkIGJlIHN1ZmZpY2llbnQgZm9yIHRoZSBwdXJwb3NlIG9m IFFPUyBwb2xpY3kgDQogICAgICAgIGRlZmluaXRpb24uIFRoZXJlIGlzIHRoZXJlZm9yZSwgYSBy ZXF1aXJlbWVudCB0byBiZSBhYmxlIHRvIGVzdGFibGlzaCANCiAgICAgICAgYW4gZW5kLXRvLWVu ZCBWUE4gdG9wb2xvZ3ksIGluY2x1ZGluZyBuZXR3b3JrIGVsZW1lbnRzIGFuZCBpbnRlcmZhY2Vz IA0KICAgICAgICB0aHJvdWdob3V0IGFuIE1ORS4gIA0KDQogICAgICAgNi4zLjIuIEVuZC10by1l bmQgUW9TIFBvbGljeSBSZXF1aXJlbWVudCANCg0KICAgICAgICBDdXJyZW50bHksIHRoZXJlIGFy ZSBubyBzdGFuZGFyZHMgZm9yIG9yIGFncmVlbWVudCBvZiBzZXJ2aWNlIA0KICAgICAgICBkZWZp bml0aW9ucyBhbW9uZ3N0IG5ldHdvcmsgU1BzLiBbUkZDMzY0NF0gZGVmaW5lcyBRb1MgcG9saWN5 IGFzIA0KICAgICAgICBiZWluZyBkZXBlbmRlbnQgdXBvbiB0aHJlZSB0eXBlcyBvZiBpbmZvcm1h dGlvbjsgVGhlIHRvcG9sb2d5IG9mIHRoZSANCiAgICAgICAgbmV0d29yayBkZXZpY2VzIHVuZGVy IG1hbmFnZW1lbnQgKGUuZy4gRGlmZnNlcnYpLCB0aGUgcGFydGljdWxhciB0eXBlIA0KICAgICAg ICBvZiBRb1MgbWV0aG9kb2xvZ3kgdXNlZCBhbmQgdGhlIGJ1c2luZXNzIHJ1bGVzIGFuZCByZXF1 aXJlbWVudHMgZm9yIA0KICAgICAgICBzcGVjaWZ5aW5nIHNlcnZpY2UocykgZGVsaXZlcmVkIGJ5 IHRoZSBuZXR3b3JrLiBUaGVzZSBpbmZvcm1hdGlvbiANCiAgICAgICAgdHlwZXMgdmFyeSBhY3Jv c3MgU1AvTlNQIGFuZCBjdXN0b21lciBkb21haW5zLiBDb25zZXF1ZW50bHksIG5ldHdvcmsgDQog ICAgICAgIG9wZXJhdG9ycyBkZXBsb3kgYSBkaWZmZXJlbnQgbnVtYmVyIG9mIGNsYXNzZXMgb2Yg c2VydmljZSAoQ09TKSBhbmQgDQogICAgICAgIHNwZWNpZnkgc2VydmljZSBkZWZpbml0aW9ucyBp biBwcm9wcmlldGFyeSB3YXlzLiBGaXhlZCBtYXBwaW5ncyBvZiANCiAgICAgICAgY2xhc3NlcyBv ZiBzZXJ2aWNlIGJldHdlZW4gYW55IHR3byBuZXR3b3JrIG9wZXJhdG9ycyB3aWxsIHJlc3VsdCBp biANCiAgICAgICAgY29tcHJvbWlzZWQgc2VydmljZSBhY3Jvc3MgdGhlIHR3by4gVGhpcyBpcyBp biBwYXJ0IGJlY2F1c2UgZml4ZWQgDQogICAgICAgIG1hcHBpbmdzIGNhbm5vdCB1dGlsaXplIHRo ZSBmdWxsIHNlcnZpY2UgZW52ZWxvcGUgYXZhaWxhYmxlIGZyb20gdGhlIA0KICAgICAgICBpbnRl cmNvbm5lY3RlZCBuZXR3b3JrIG9wZXJhdG9ycyAoYSBuZXR3b3JrIG9wZXJhdG9yIHdpdGggdGhy ZWUgDQogICAgICAgIGNsYXNzZXMgb2Ygc2VydmljZSBjYW4gb25seSB1dGlsaXplIDMvNXRocyBv ZiB0aGUgc2VydmljZSBlbnZlbG9wZSBvZiANCiAgICAgICAgYSBuZXR3b3JrIG9wZXJhdG9yIHdp dGggZml2ZSBjbGFzc2VzIG9mIHNlcnZpY2UpLiBJbiBwYXJ0LCBpdCBpcyBhbHNvIA0KICAgICAg ICBiZWNhdXNlIGEgZml4ZWQgbWFwcGluZyBtYXkgYmUgYWRlcXVhdGUgZm9yIHNvbWUgY3VzdG9t ZXJzLCBidXQgbm90IA0KICAgICAgICBmb3Igb3RoZXJzLiBUaGlzIGlzIGJlY2F1c2UgUW9TIHBv bGljeSBpcyBvZnRlbiBhcHBsaWVkIGluIGRpZmZlcmVudCANCiAgICAgICAgd2F5cyBmb3IgZWFj aCBhcHBsaWNhdGlvbiBpbiBlYWNoIGN1c3RvbWVyLiBTb21ldGltZXMgYXBwbGljYXRpb24gb2Yg DQogICAgICAgIGEgUW9TIHBvbGljeSBjYW4gdmFyeSB3aXRoaW4gYSBzaW5nbGUgY3VzdG9tZXIu IEluZGVlZCwgYXMgZGVwaWN0ZWQgDQogICAgICAgIGluIFJGQzM2NDQsIHRoZSBkZWZpbml0aW9u IG9mIFFvUyBwb2xpY3kgaXMgZGVwZW5kZW50IG9uIHRocmVlIHR5cGVzIA0KICAgICAgICBvZiBp bmZvcm1hdGlvbjogMSkgdGhlIHRvcG9sb2d5IG9mIHRoZSBuZXR3b3JrIGRldmljZXMgdW5kZXIg DQogICAgICAgIG1hbmFnZW1lbnQsIDIpIHRoZSBwYXJ0aWN1bGFyIHR5cGUgb2YgUW9TIG1ldGhv ZG9sb2d5IHVzZWQgYW5kIDMpIHRoZSANCiAgICAgICAgYnVzaW5lc3MgcnVsZXMgYW5kIHJlcXVp cmVtZW50cyBmb3Igc3BlY2lmeWluZyBzZXJ2aWNlKHMpIGRlbGl2ZXJlZCANCiAgICAgICAgYnkg dGhlIG5ldHdvcmsuIA0KDQogICAgICAgIFdoZW4gdGhyZWUgb3IgbW9yZSBuZXR3b3JrIG9wZXJh dG9ycyBhcmUgdXNlZCB0byBwcm92aWRlIGNvbm5lY3Rpdml0eSANCiAgICAgICAgYmV0d2VlbiBj dXN0b21lciBzaXRlcywgdHdvIG9yIG1vcmUgaW50ZXJjb25uZWN0cyBpcyByZXF1aXJlZCBhbmQs IA0KICAgICAgICB0aGVyZWZvcmUsIGEgbXVsdGlwbGUsIGNvbXBvdW5kaW5nIHNlcnZpY2UgY29t cHJvbWlzZSBleGlzdHMuIEluIGFuIA0KICAgICAgICBNTkUgb2YgbWFueSBuZXR3b3JrIG9wZXJh dG9ycyBhbmQgbWFueSBpbnRlcmNvbm5lY3RzLCBpdCBpcyBjbGVhciANCiAgICAgICAgdGhhdCBu dW1lcm91cyBhbmQgY29tcG91bmRpbmcgY29tcHJvbWlzZXMgaW4gc2VydmljZSB3aWxsIHRha2Ug cGxhY2UgDQogICAgICAgIGFuZCBlbmQtdG8tZW5kIFFvUyBwb2xpY3kgZW5mb3JjZW1lbnQgbWF5 IGJlIGhhcmQgdG8gYWNoaWV2ZS4gVGhlcmUgDQogICAgICAgIGlzIGEgcmVxdWlyZW1lbnQsIHRo ZXJlZm9yZSwgZm9yIGEgcmVsYXRpb25zaGlwIHRvIGV4aXN0IGJldHdlZW4gDQogICAgICAgIG5l dHdvcmsgb3BlcmF0b3IgY2xhc3NlcyBvZiBzZXJ2aWNlIHRoYXQgbWF5IHZhcnkgZnJvbSBvbmUg Y3VzdG9tZXIgDQogICAgICANCiAgICAgIA0KICAgICBIYWxzdGVhZCAgICAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgMTcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDEwXSANCiAgICAgICAg IA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICBJbnRlcm5ldC1EcmFmdCBkcmFmdC1oYWxz dGVhZC1ndWljaGFyZC1NQVZTLXJlcXVpcmVtZW50cyAgIE5vdmVtYmVyIDIwMDUgDQogICAgICAg ICANCg0KICAgICAgICB0byBhbm90aGVyLCBhbmQgdGhhdCBjYW4gYWxzbyB1dGlsaXplIHRoZSBm dWxsIHNlcnZpY2UgZW52ZWxvcGUgb2YgDQogICAgICAgIGFsbCBuZXR3b3JrIG9wZXJhdG9ycyB3 aXRoaW4gYW4gTU5FLiBJbiBhZGRpdGlvbiwgZm9yIHNvbWUgY3VzdG9tZXJzIA0KICAgICAgICB3 aG8gaGF2ZSBpbXBsZW1lbnRlZCBhIFFvUyBwb2xpY3kgYW1vbmdzdCBzb21lIG9yIGFsbCBvZiB0 aGVpciANCiAgICAgICAgYnVzaW5lc3MgbG9jYXRpb25zLCBpdCBtYXkgYmUgZGVzaXJhYmxlIGZv ciB0aGUgY3VzdG9tZXIgdGhhdCBhbiBNTkUgDQogICAgICAgIGRvZXMgbm90IG1vZGlmeSB0aGF0 IHBvbGljeSBpbiBhbnkgd2F5LiBTb21ldGltZXMgdGhpcyBuZWVkIGlzIA0KICAgICAgICBjaGFy YWN0ZXJpemVkIGFzIFFvUyB0cmFuc3BhcmVuY3ksIHdoZXJlIHRoZSB0cmFuc3BhcmVuY3kgaW4g cXVlc3Rpb24gDQogICAgICAgIHJlZmVycyB0byB0aGUgcGFzc2luZyBvZiB0aGUgZW50ZXJwcmlz ZSBRb1MgcG9saWN5LCB1bm1vZGlmaWVkLCBmcm9tIA0KICAgICAgICBpbmdyZXNzIHRvIGVncmVz cyBvZiBhIHRlbGVjb21tdW5pY2F0aW9ucyBzZXJ2aWNlLiBbUkZDNDAzMV0gDQogICAgICAgIGRl c2NyaWJlcyB0aGlzIHJlcXVpcmVtZW50IGFzIGEgkUNhcnJpZXKScyBDYXJyaWVykiBtb2RlbCB3 aGVyZSBvbmUgDQogICAgICAgIFNQIGlzIHRoZSBjdXN0b21lciBvZiBhbm90aGVyIEwzVlBOIFNQ LiBTdWNoIGFuIFNQIHNob3VsZCBiZSBhYmxlIHRvIA0KICAgICAgICByZXNlbGwgVlBOIHNlcnZp Y2UgdG8gdGhlaXIgVlBOIGN1c3RvbWVycyBpbmRlcGVuZGVudGx5IG9mIHRoZSBEU0NQIA0KICAg ICAgICBtYXBwaW5nIHNvbHV0aW9uIGVtcGxveWVkIGJ5IHRoZSCRQ2FycmllcpJzIENhcnJpZXKS IFNQLiBUaGVyZSBpcyBhIA0KICAgICAgICByZXF1aXJlbWVudCwgdGhlcmVmb3JlLCBmb3IgZW50 ZXJwcmlzZSBRb1MgcG9saWN5IHRyYW5zcGFyZW5jeSANCiAgICAgICAgdGhyb3VnaG91dCBhbiBN TkUuIA0KDQogICAgICAgNi4zLjMuICBPcHRpbWFsIEludGVyY29ubmVjdCBTZWxlY3Rpb24gUmVx dWlyZW1lbnQgDQoNCiAgICAgICAgU1AgbXVsdGktaG9taW5nIGlzIHRoZSBzY2VuYXJpbyBpbiB3 aGljaCBhbiBTUCBuZWVkcyB0byBpbnRlcmNvbm5lY3QgDQogICAgICAgIGF0IHR3byBvciBtb3Jl IFZQTHMuIEJ5IGVuc3VyaW5nIHRoYXQgdHJhZmZpYyBwYXNzZXMgYmV0d2VlbiBuZXR3b3JrcyAN CiAgICAgICAgYXQgcHJlLWRldGVybWluZWQgVlBMcywgdGhlIGRlc2lyZWQgZW5kLXRvLWVuZCBz ZXJ2aWNlIHBvbGljeSBjYW4gYmUgDQogICAgICAgIGVzdGFibGlzaGVkIGFuZCByZXRhaW5lZCBm b3IgYW55IGN1c3RvbWVyIHNpdGVzIGFuZCBTUCBuZXR3b3JrcyBjYW4gDQogICAgICAgIGJlIHV0 aWxpemVkIG1vcmUgZWZmaWNpZW50bHkuIEFzIGFuIGV4YW1wbGUsIGNvbnNpZGVyIGEgY3VzdG9t ZXIgc2l0ZSANCiAgICAgICAgaW4gdGhlIG1pZGRsZSBvZiB0aGUgVVNBLiBJdCBpcyBjb25uZWN0 ZWQgdG8gYSBTUCB0aGF0IGlzIA0KICAgICAgICBpbnRlcmNvbm5lY3RlZCBpbiBib3RoIE5ldyBZ b3JrIGFuZCBMb3MgQW5nZWxlcy4gVHJhZmZpYyBtdXN0IGJlIHNlbnQgDQogICAgICAgIHRvIFRv a3lvIHZpYSB0aGUgTEEgaW50ZXJjb25uZWN0IGFuZCBub3QgdmlhIE5ldyBZb3JrIGluIG9yZGVy IHRvIA0KICAgICAgICBtaW5pbWl6ZSBsYXRlbmN5LiBGcm9tIGEgbmV0d29yayB1dGlsaXphdGlv biBwZXJzcGVjdGl2ZSwgcm91dGluZyANCiAgICAgICAgVG9reW8tYm91bmQgdHJhZmZpYyB2aWEg TmV3IFlvcmsgaW5jdXJzIGFuIGluZWZmaWNpZW50LCByZXNvdXJjZS0NCiAgICAgICAgY29uc3Vt aW5nIHJvdW5kIHRyaXAgdHJhdmVyc2FsIG9mIHRoZSBVU0EuIFNpbWlsYXJseSwgdGhlIHNhbWUg c2l0ZSANCiAgICAgICAgbWlnaHQgYWxzbyBzZW5kIHRyYWZmaWMgdG8gTG9uZG9uLiBUaGUgb3B0 aW1hbCByb3V0ZSBmb3IgdGhpcyB0cmFmZmljIA0KICAgICAgICB3aWxsIGJlIHZpYSBOZXcgWW9y ayByYXRoZXIgdGhhbiBMQS4gRm9yIG11bHRpIGhvbWVkIFNQcywgdGhlcmUgaXMgDQogICAgICAg IHRoZXJlZm9yZSwgYSByZXF1aXJlbWVudCBmb3IgaW50ZXJjb25uZWN0cyB0byBiZSBvcHRpbWFs bHkgc2VsZWN0YWJsZSANCiAgICAgICAgZm9yIGVhY2ggc291cmNlLWRlc3RpbmF0aW9uIHNpdGUg cGFpciB3aXRoaW4gYW4gTU5FLiANCg0KICAgICAgIDYuMy40LiBFbmQtdG8tZW5kIFVuaWNhc3Qg Um91dGluZyBQb2xpY3kgUmVxdWlyZW1lbnQgDQoNCiAgICAgICAgVG9kYXkgdGhlcmUgYXJlIG5v IHN0YW5kYXJkcyBmb3IsIG9yIGFncmVlbWVudCBvZiwgaG93IFZQTiByb3V0aW5nIA0KICAgICAg ICBwb2xpY3kgYmFzZWQgb24gdGhlIHBvbGljaW5nIG9mIHRoZSBhZG1pc3Npb24gYW5kIGRpc3Ry aWJ1dGlvbiBvZiANCiAgICAgICAgcm91dGluZyBpbmZvcm1hdGlvbiAoY2xhc3NpZmljYXRpb24g YW5kIGZpbHRlcmluZyBvZiByb3V0aW5nIA0KICAgICAgICBpbmZvcm1hdGlvbikgaXMgaW1wbGVt ZW50ZWQgYW1vbmdzdCBTUHMuIENvbnNlcXVlbnRseSwgU1BzIGltcGxlbWVudCANCiAgICAgICAg cm91dGluZyBwb2xpY3kgd2l0aGluIGEgZGVmaW5lZCBjdXN0b21lciB0b3BvbG9neSBpbiBkaWZm ZXJlbnQgd2F5cy4gDQogICAgICAgIENvbmZsaWN0aW5nIHJvdXRpbmcgcG9saWNpZXMgYW1vbmdz dCBuZXR3b3JrIG9wZXJhdG9ycyBtYWtlIGl0IHZlcnkgDQogICAgICAgIGRpZmZpY3VsdCB0byBl c3RhYmxpc2ggYW4gZW5kLXRvLWVuZCB1bmljYXN0IHJvdXRpbmcgcG9saWN5IA0KICAgICAgICB0 aHJvdWdob3V0IGFuIE1ORS4gVGhlcmUgaXMsIHRoZXJlZm9yZSwgYSByZXF1aXJlbWVudCB0byBi ZSBhYmxlIHRvIA0KICAgICAgICBlc3RhYmxpc2ggYSBjb25zaXN0ZW50IElHUCBhbmQgQkdQLWJh c2VkIHVuaWNhc3Qgcm91dGluZyBwb2xpY3kgDQogICAgICAgIHRocm91Z2hvdXQgYW4gTU5FLiAN Cg0KDQogICAgICANCiAgICAgIA0KICAgICBIYWxzdGVhZCAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXkgMTcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDExXSANCiAgICAgICAgIA0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICBJbnRlcm5ldC1EcmFmdCBkcmFmdC1oYWxzdGVhZC1n dWljaGFyZC1NQVZTLXJlcXVpcmVtZW50cyAgIE5vdmVtYmVyIDIwMDUgDQogICAgICAgICANCg0K ICAgICAgIDYuMy41LiBFbmQtdG8tRW5kIE11bHRpY2FzdCBSb3V0aW5nIFJlcXVpcmVtZW50IA0K DQogICAgICAgIE11bHRpY2FzdCBoYXMgZm9yIHNvbWUgdGltZSwgYmVlbiB1c2VkIGJ5IGFwcGxp Y2F0aW9ucyB3aXRoaW4gbG9jYWwgDQogICAgICAgIGFyZWEgbmV0d29ya3MsIGJ1dCBhbG1vc3Qg bmV2ZXIgYWNyb3NzIHdpZGUgYXJlYSBuZXR3b3Jrcy4gVGhhdCBpcyANCiAgICAgICAgc3RhcnRp bmcgdG8gY2hhbmdlIGFuZCwgYXMgYSByZXN1bHQsIHNvbWUgU1BzIGhhdmUgYmVndW4gdG8gZW5h YmxlIA0KICAgICAgICBtdWx0aWNhc3QgYXQga2V5IG5vZGVzIGluIHRoZWlyIG5ldHdvcmtzLiBU b2RheSBob3dldmVyLCB0aGVyZSBhcmUgbm8gDQogICAgICAgIHN0YW5kYXJkcyBmb3IsIG9yIGFn cmVlbWVudCBvZiwgbXVsdGljYXN0IGRlcGxveW1lbnQgcG9saWN5IGFtb25nc3QgDQogICAgICAg IFNQcy4gQXMgYSByZXN1bHQsIFNQcyBpbXBsZW1lbnQgbXVsdGljYXN0IHVzaW5nIHZhcmlvdXMg ZGlmZmVyZW50LCANCiAgICAgICAgbm9uLWNvbXBhdGlibGUsIG1ldGhvZHMgYW5kIHByb3RvY29s cyBmb3IgZXN0YWJsaXNoaW5nIG11bHRpY2FzdCANCiAgICAgICAgdG9wb2xvZ2llcy4gRGVzcGl0 ZSB0aGVzZSBkaWZmZXJlbmNlcywgTU5FIG9wZXJhdG9ycyBtdXN0IHByb3ZpZGUgDQogICAgICAg IG11bHRpY2FzdCBzZXJ2aWNlIG9uIGFuIGVuZC10by1lbmQgYmFzaXMgaW4gYW4gTU5FLiBUaGVy ZSBpcyANCiAgICAgICAgdGhlcmVmb3JlLCBhIHJlcXVpcmVtZW50IHRvIGJlIGFibGUgdG8gZXN0 YWJsaXNoIGFuIGVuZCB0by1lbmQgDQogICAgICAgIG11bHRpY2FzdCByb3V0aW5nIHBvbGljeSB0 aHJvdWdob3V0IGFuIE1ORS4gIA0KDQogICAgICAgNi4zLjYuIEhvbW9nZW5vdXMgTWVhc3VyZW1l bnQgUmVxdWlyZW1lbnQgDQoNCiAgICAgICAgQ3VycmVudGx5LCB0aGVyZSBhcmUgbm8gc3RhbmRh cmRzIGZvciwgb3IgYWdyZWVtZW50IG9mLCBtZWFzdXJlbWVudCANCiAgICAgICAgbWV0aG9kcyBh bW9uZ3N0IFNQcy4gU1BzIGRlZmluZSBtZWFzdXJlbWVudHMgZGlmZmVyZW50bHkgYW5kIG1lYXN1 cmUgDQogICAgICAgIGRpZmZlcmVudCB0aGluZ3MuIEluIGEgTU5FIGVudmlyb25tZW50LCBtZWFz dXJlbWVudCBtZXRob2RvbG9neSANCiAgICAgICAgZGlmZmVyZW5jZXMsIHBhcnRpY3VsYXJseSBk aWZmZXJlbmNlcyBpbiB0aGUgc3RhdGlzdGljYWwgbmF0dXJlIG9mIA0KICAgICAgICB0aGUgbWVh c3VyZW1lbnRzLCBtYWtlIGl0IGltcG9zc2libGUgdG8gY29tYmluZSBuZXR3b3JrIG9wZXJhdG9y IA0KICAgICAgICBtZWFzdXJlbWVudCByZXBvcnRzIHNvIHRoYXQgdGhlIG92ZXJhbGwgcXVhbGl0 eSBvZiB0aGUgVlBOIHNlcnZpY2UgDQogICAgICAgIGNhbiBiZSBxdWFsaWZpZWQuIEluIGZhY3Qs IGFzIFNQIHJlcG9ydHMgY2FuIGJlIHNvIGRpZmZlcmVudCwgaXQgaXMgDQogICAgICAgIGFsc28g dGVkaW91cyBhbmQgdGltZSBjb25zdW1pbmcgdG8gYW5hbHl6ZSB3aGV0aGVyIGFuIGluZGl2aWR1 YWwgU1AgDQogICAgICAgIGhhcyBtZXQgdGhlaXIgcGVyZm9ybWFuY2UgdGFyZ2V0cy4gV2hlbiBl bmQtdG8tZW5kIHNlcnZpY2UgZmFpbHMsIGl0IA0KICAgICAgICBpcyB2ZXJ5IGRpZmZpY3VsdCB0 byBhbmFseXplIFNQIG1lYXN1cmVtZW50IGRhdGEgdG8gZGV0ZWN0IGFuZCANCiAgICAgICAgaXNv bGF0ZSBmYXVsdHMgYW1vbmdzdCBTUHMuIEluIGFuIE1ORSwgd2hlcmUgdGhlIE9wcyBhZ2VudChz KSBhcmUgDQogICAgICAgIHJlc3BvbnNpYmxlIGZvciBlbmQtdG8tZW5kIHNlcnZpY2UsIHRoaXMg bWF5IGJlIHVudGVuYWJsZS4gSW4gDQogICAgICAgIGFkZGl0aW9uLCB3aGlsc3Qgd2luZG93cyBm b3Igc2NoZWR1bGVkIGFuZCB1bnNjaGVkdWxlZCBtYWludGVuYW5jZSANCiAgICAgICAgd2lsbCBy ZW1haW4gZGlmZmljdWx0IGZvciB0aGUgT3BzIGFnZW50KHMpIHRvIGNvbnRyb2wgb3IgY29vcmRp bmF0ZSwgDQogICAgICAgIGFueSBtZWFzdXJlbWVudCBtZXRob2RvbG9neSBtdXN0IHRha2UgdGhl c2Ugd2luZG93cyBpbnRvIGFjY291bnQgaW4gDQogICAgICAgIGFueSBwZXJmb3JtYW5jZSBhc3Nl c3NtZW50cyBvZiB0aGUgUW9TIHBvbGljeSB0aGF0IGFyZSBtYWRlLiBUaGVyZSANCiAgICAgICAg aXMsIHRoZXJlZm9yZSwgYSByZXF1aXJlbWVudCBmb3Igc3RhdGlzdGljYWxseSBob21vZ2Vub3Vz IG1lYXN1cmVtZW50IA0KICAgICAgICB0aHJvdWdob3V0IGFuIE1ORSBhcyB3ZWxsIGFzIHRoZSBh YmlsaXR5IHRvIHBsYWNlIG1lYXN1cmVtZW50IA0KICAgICAgICBpbnN0cnVtZW50YXRpb24vc291 cmNlcyBhdCBpbnRlcmNvbm5lY3RzIHRvIGFpZCBmYXVsdCBkZXRlY3Rpb24gYW5kIA0KICAgICAg ICBpc29sYXRpb24uIA0KDQogICAgIDYuNC4gUmVtb3RlIFNlcnZpY2UgSW50ZXJjb25uZWN0IFJl cXVpcmVtZW50IA0KDQogICAgICAgIEluIGFuIE1ORSwgYWdlbnQocykgd2lsbCBpbmNvcnBvcmF0 ZSBOU1BzIGFjY29yZGluZyB0byB0aGUgbmVlZHMgb2YgDQogICAgICAgIHRoZSBjdXN0b21lci4g U29tZSBvZiB0aGVzZSBOU1BzIG1heSBiZSBjb2xsb2NhdGVkIGF0IHRoZSBzYW1lIFZQTDsgDQog ICAgICAgIG90aGVycyBtYXkgbm90LiBGb3IgdGhvc2UgdGhhdCBhcmUgY29sbG9jYXRlZCBhdCB0 aGUgc2FtZSBWUEwsIA0KICAgICAgICBpbnRlcmNvbm5lY3Rpb24gb2YgVlBOIHNlcnZpY2VzIGNh biBoYXBwZW4gbG9jYWxseS4gSG93ZXZlciwgaW4gdGhlIA0KICAgICAgICBleGFtcGxlIG9mIGFu IGVuZC10by1lbmQgY2hhaW4gb2YgdGhyZWUgVlBOIHNlcnZpY2VzIGFuZCB0d28gDQogICAgICAg IGludGVyY29ubmVjdHMsIGxvY2FsIFZQTiBpbnRlcmNvbm5lY3Rpb24gd2lsbCBoYXBwZW4gdHdp Y2U6IG9uY2UgYXQgDQogICAgICAgIHRoZSBmaXJzdCBWUEwgKGZpcnN0IHRvIHNlY29uZCBTUCkg YW5kIG9uY2UgYXQgdGhlIHNlY29uZCAoc2Vjb25kIHRvIA0KICAgICAgICB0aGlyZCBTUCkuIEhv d2V2ZXIsIGluIHNvbWUgc2l0dWF0aW9ucywgTU5FIG9wZXJhdG9ycyBtYXkgY2hvb3NlIG5vdCAN CiAgICAgIA0KICAgICAgDQogICAgIEhhbHN0ZWFkICAgICAgICAgICAgICAgICBFeHBpcmVzIE1h eSAxNywgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdIA0KICAgICAgICAgDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQogICAgIEludGVybmV0LURyYWZ0IGRyYWZ0LWhhbHN0ZWFkLWd1aWNo YXJkLU1BVlMtcmVxdWlyZW1lbnRzICAgTm92ZW1iZXIgMjAwNSANCiAgICAgICAgIA0KDQogICAg ICAgIHRvIHVzZSB0aGUgVlBOIHNlcnZpY2Ugb2YgdGhlIHNlY29uZCAobWlkZGxlKSBTUC4gSW5z dGVhZCwgdGhleSBtYXkgDQogICAgICAgIHdpc2ggdG8gaW50ZXJjb25uZWN0IHRoZSBWUE4gc2Vy dmljZXMgb2YgdGhlIGZpcnN0IGFuZCB0aGlyZCBuZXR3b3JrIA0KICAgICAgICBvcGVyYXRvcnMg cmVtb3RlbHkuIFRoZXJlIGlzLCB0aGVyZWZvcmUsIGEgcmVxdWlyZW1lbnQgdG8gYmUgYWJsZSB0 byANCiAgICAgICAgcmVtb3RlbHkgaW50ZXJjb25uZWN0IHNlcnZpY2VzIG9mIG5vbi1jb2xsb2Nh dGVkIFNQcyBpbiBhbiBNTkUuICANCg0KICAgICA2LjUuIFJlZHVuZGFudCBJbnRlcmNvbm5lY3Qg UmVxdWlyZW1lbnQgDQoNCiAgICAgICAgUGFydCBvZiB0aGUgZW5kLXRvLWVuZCBzZXJ2aWNlIG9m ZmVyaW5nIHByb3ZpZGVkIGJ5IG9uZSBvciBtb3JlIE9wcyANCiAgICAgICAgYWdlbnRzIGludm9s dmVzIHRoZSBwcm92aXNpb24gb2YgYXBwcm9wcmlhdGUgbGV2ZWxzIG9mIHJlZHVuZGFuY3kgZm9y IA0KICAgICAgICB0aGVpciBwYXJ0aWN1bGFyIE1ORSB1c2UgY2FzZS4gSW4gc29tZSBWUExzLCB3 aGVyZSBidXNpbmVzcyANCiAgICAgICAganVzdGlmaWNhdGlvbnMgZXhpc3QsIHRoZSBPcHMgYWdl bnQgbWF5IGNob29zZSB0byBlbmhhbmNlIA0KICAgICAgICBpbnRlcmNvbm5lY3QgcmVsaWFiaWxp dHkgYnkgaW1wbGVtZW50aW5nIGEgcmVkdW5kYW50IGludGVyY29ubmVjdCANCiAgICAgICAgY29t cGxleC4gVGhlIHJlc3VsdGluZyBpbnRlcmNvbm5lY3RzIG1pZ2h0IGV4aXN0IGluIHRoZSBzYW1l IGJ1aWxkaW5nIA0KICAgICAgICBvciBpbiBkaWZmZXJlbnQgYnVpbGRpbmdzIHdpdGhpbiBhIGNp dHkgb3IgaW4gZGlmZmVyZW50IGJ1aWxkaW5ncyBpbiANCiAgICAgICAgZGlmZmVyZW50IGNpdGll cy4gVGhpcyBpcyBpbiBhZGRpdGlvbiB0byB0aGUgT3B0aW1hbCBJbnRlcmNvbm5lY3QgDQogICAg ICAgIFNlbGVjdGlvbiBSZXF1aXJlbWVudCBpbiB0aGF0IGEgY3VzdG9tZXIgc2VydmljZSB3aWxs IGJlIGRlc2lnbmVkIHRvIA0KICAgICAgICB0cmF2ZXJzZSBlYWNoIHJlZHVuZGFudCBpbnRlcmNv bm5lY3QsIHJhdGhlciB0aGFuIGEgc3BlY2lmaWMsIG9wdGltYWwgDQogICAgICAgIGludGVyY29u bmVjdC4gVGhlcmUgaXMgdGhlcmVmb3JlIGEgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBjdXN0b21l ciANCiAgICAgICAgc2VydmljZXMgYWNyb3NzIHJlZHVuZGFudCBpbnRlcmNvbm5lY3RzLiAgDQoN CiAgICAgNi42LiBTZWN1cml0eSBSZXF1aXJlbWVudCANCg0KICAgICAgICBTZWN1cml0eSBpcyBh IHJlcXVpcmVtZW50IG9mIGFueSBidXNpbmVzcywgYnV0IHRoZSByZXF1aXJlbWVudCANCiAgICAg ICAgYmVjb21lcyBtb3JlIGltcG9ydGFudCB3aGVyZSB0aGF0IGJ1c2luZXNzIGNvbGxhYm9yYXRl cyB3aXRoIG90aGVycyANCiAgICAgICAgdG8gcHJvdmlkZSBhIHNlcnZpY2UuIFBvdGVudGlhbCB0 aHJlYXRzIG1pZ2h0IGVtYW5hdGUgZnJvbSBhIG51bWJlciANCiAgICAgICAgb2Ygc291cmNlcywg Zm9yIGluc3RhbmNlLCBvdGhlciBTUHMsIFZQTHMgYW5kIGN1c3RvbWVycy4gQ2xlYXJseSwgdGhl IA0KICAgICAgICB2dWxuZXJhYmlsaXR5IG9mIGEgY3VzdG9tZXIgc2VydmljZSB0byB0aHJlYXRz IGZyb20gdGhlc2Ugc291cmNlcyBpcyANCiAgICAgICAgb2YgcGFyYW1vdW50IGltcG9ydGFuY2Uu IE9mIGVxdWFsIGltcG9ydGFuY2UsIGlzIHRoZSB2dWxuZXJhYmlsaXR5IG9mIA0KICAgICAgICBh IE5TUCBiYWNrYm9uZSB0byB0aHJlYXRzIGZyb20gdGhlc2Ugc291cmNlcy4gQW4gYXR0YWNrIG9u IGEgTlNQIA0KICAgICAgICBiYWNrYm9uZSBjb3VsZCBkZXRyaW1lbnRhbGx5IGFmZmVjdCBudW1l cm91cyBjdXN0b21lcnMsIGluY2x1ZGluZyANCiAgICAgICAgdGhvc2UgYXR0YWNoZWQgdG8gb3Ro ZXIgU1BzLiBUaGVyZSBpcyBhIHJlcXVpcmVtZW50LCB0aGVyZWZvcmUsIHRvIA0KICAgICAgICBz ZWN1cmUgTlNQIGJhY2tib25lcyBhbmQgY3VzdG9tZXIgc2VydmljZXMgaW4gYW4gTU5FLiANCg0K ICAgICAgDQogICAgIDYuNy4gVGhpcmQgUGFydHkgSW50ZXJjb25uZWN0IFJlcXVpcmVtZW50IA0K DQogICAgICAgIFNvbWUgb3BlcmF0b3JzLCBhbHRob3VnaCB0aGV5IGhhdmUgYSBuZWVkIHRvIGJl IGFibGUgdG8gcHJvdmlkZSBlbmQtDQogICAgICAgIHRvIGVuZCBzZXJ2aWNlIGluIGEgc29sdXRp b24gaW52b2x2aW5nIG11bHRpcGxlIFNQcywgbWF5IGJlIHVuYWJsZSB0byANCiAgICAgICAgb3Bl cmF0ZSBvciBoYXZlIG5vIGRlc2lyZSB0byBvcGVyYXRlIGFuIE1ORS4gSW4gb3JkZXIgdGhhdCBh biBNTkUgY2FuIA0KICAgICAgICBiZSBlc3RhYmxpc2hlZCBmb3IgaXQgYW5kIGl0cyBTUCBwYXJ0 bmVycywgdGhlIG9wZXJhdG9yIHdhbnRzIGEgdGhpcmQgDQogICAgICAgIHBhcnR5IHRvIHByb3Zp ZGUgaW50ZXJjb25uZWN0IHNlcnZpY2VzIHRvIHRoZSBncm91cC4gSXQgbWF5IGJlIHRoYXQgDQog ICAgICAgIHRoZSB0aGlyZCBwYXJ0eSBpcyBhbm90aGVyIFNQLCBhIHN5c3RlbXMgaW50ZWdyYXRv ciwgYSBuZXR3b3JrIA0KICAgICAgICBpbnRlZ3JhdG9yIG9yIGFub3RoZXIgdHlwZSBvZiBzZXJ2 aWNlIHByb3ZpZGVyLiBUbyBhY2hpZXZlIGVuZC10by1lbmQgDQogICAgICAgIHNlcnZpY2UsIGl0 IGlzIGNyaXRpY2FsIHRoYXQgdGhlIHRoaXJkIHBhcnR5IGludGVyY29ubmVjdCBzZXJ2aWNlIA0K ICAgICAgICBwcm92aWRlciBpcyBhYmxlIHRvIGNvbnRyb2wgYW5kIGNvb3JkaW5hdGUgZ2xvYmFs IHNlcnZpY2UgcG9saWN5IA0KICAgICAgICB0aHJvdWdob3V0IHRoZSBNTkUgb24gYmVoYWxmIHRo ZSBncm91cC4gVGhlcmUgaXMsIHRoZXJlZm9yZSwgYSANCg0KICAgICAgDQogICAgICANCiAgICAg SGFsc3RlYWQgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA2ICAgICAgICAgICAg ICAgICBbUGFnZSAxM10gDQogICAgICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICAg SW50ZXJuZXQtRHJhZnQgZHJhZnQtaGFsc3RlYWQtZ3VpY2hhcmQtTUFWUy1yZXF1aXJlbWVudHMg ICBOb3ZlbWJlciAyMDA1IA0KICAgICAgICAgDQoNCiAgICAgICAgcmVxdWlyZW1lbnQgZm9yIHRo ZSBpbnRlcmNvbm5lY3QgZXF1aXBtZW50IGFuZCBwcm9jZWR1cmVzIHRvIGJlIA0KICAgICAgICBj b250cm9sbGFibGUgYnkgYSB0aGlyZCBwYXJ0eSBpbnRlcmNvbm5lY3Qgc2VydmljZXMgcHJvdmlk ZXIuIA0KDQogICAgIDcuIENvbmNsdXNpb25zIA0KDQogICAgICAgICAgDQoNCiAgICAgOC4gQWNr bm93bGVkZ21lbnRzIA0KDQogICAgIDkuICBSZWZlcmVuY2VzIA0KDQogICAgICAgICAgDQoNCiAg ICAgOS4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyANCg0KICAgICAgICAgIA0KDQogICAgIDkuMi4g SW5mb3JtYXRpdmUgUmVmZXJlbmNlcyANCg0KICAgICAgICAgIA0KDQogICAgIEF1dGhvcidzIEFk ZHJlc3NlcyAgDQoNCiAgICAgICAgSmltIEd1aWNoYXJkIA0KICAgICAgICBDaXNjbyBTeXN0ZW1z LCBJbmMgDQogICAgICAgIDMwMCBCZWF2ZXIgQnJvb2sgUmQgDQogICAgICAgIEJveGJvcm91Z2gg DQogICAgICAgIE1BICAgDQogICAgICAgIEVtYWlsOiBqZ3VpY2hhckBjaXNjby5jb20gDQogICAg ICAgICANCiAgICAgICAgTWFydGluIEhhbHN0ZWFkIA0KICAgICAgICBOZXhhZ2VudCBMdGQgDQog ICAgICAgIFRoYW1lcyBUb3dlciANCiAgICAgICAgMzctNDUgU3RhdGlvbiBSb2FkIA0KICAgICAg ICBSZWFkaW5nIA0KICAgICAgICBCZXJrc2hpcmUgDQogICAgICAgIFVLIA0KICAgICAgICBSRzEg MUxYIA0KICAgICAgICBFbWFpbDogbWhhbHN0ZWFkQG5leGFnZW50IA0KICAgICAgICAgDQoNCiAg ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudCANCg0KICAgICAgICBUaGUgSUVURiB0 YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueSAN CiAgICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhh dCBtaWdodCBiZSBjbGFpbWVkIHRvIA0KICAgICAgICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRh dGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluIA0KICAgICAgICB0aGlz IGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCBy aWdodHMgDQogICAgICANCiAgICAgIA0KICAgICBIYWxzdGVhZCAgICAgICAgICAgICAgICAgRXhw aXJlcyBNYXkgMTcsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDE0XSANCiAgICAgICAgIA0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICBJbnRlcm5ldC1EcmFmdCBkcmFmdC1oYWxzdGVh ZC1ndWljaGFyZC1NQVZTLXJlcXVpcmVtZW50cyAgIE5vdmVtYmVyIDIwMDUgDQogICAgICAgICAN Cg0KICAgICAgICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCBy ZXByZXNlbnQgdGhhdCBpdCBoYXMgDQogICAgICAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9y dCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbiANCiAgICAgICAgb24g dGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNh biBiZSANCiAgICAgICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuIA0KDQogICAgICAgIENv cGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQg YW55IA0KICAgICAgICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxl LCBvciB0aGUgcmVzdWx0IG9mIGFuIA0KICAgICAgICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEg Z2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YgDQogICAgICAgIHN1 Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIA0K ICAgICAgICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxp bmUgSVBSIHJlcG9zaXRvcnkgYXQgDQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiAN Cg0KICAgICAgICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5n IHRvIGl0cyBhdHRlbnRpb24gYW55IA0KICAgICAgICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBh dGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5IA0KICAgICAgICByaWdodHMg dGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1l bnQgDQogICAgICAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRp b24gdG8gdGhlIElFVEYgYXQgDQogICAgICAgIGlldGYtaXByQGlldGYub3JnIA0KDQogICAgIERp c2NsYWltZXIgb2YgVmFsaWRpdHkgDQoNCiAgICAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuIA0KICAgICAgICAi QVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hF IFJFUFJFU0VOVFMgDQogICAgICAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElO VEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCANCiAgICAgICAgRU5HSU5FRVJJTkcgVEFT SyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCANCiAg ICAgICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUg VVNFIE9GIFRIRSANCiAgICAgICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdF IEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgDQogICAgICAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hB TlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiANCg0KICAgICBD b3B5cmlnaHQgU3RhdGVtZW50IA0KDQogICAgICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0 IFNvY2lldHkgKDIwMDUpLiANCg0KICAgICAgICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g dGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyANCiAgICAgICAgY29udGFpbmVk IGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMg DQogICAgICAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLiANCg0KICAgICBBY2tub3dsZWRnbWVu dCANCg0KICAgICAgICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJy ZW50bHkgcHJvdmlkZWQgYnkgdGhlIA0KICAgICAgICBJbnRlcm5ldCBTb2NpZXR5LiANCg0KICAg ICAgICAgDQoNCg0KDQoNCg0KICAgICAgDQogICAgICANCiAgICAgSGFsc3RlYWQgICAgICAgICAg ICAgICAgIEV4cGlyZXMgTWF5IDE3LCAyMDA2ICAgICAgICAgICAgICAgICBbUGFnZSAxNV0gDQog ICAgICAgICANCg0KDQoNCg0KDQoNCg== ------_=_NextPart_001_01C5EBA2.47D96C1F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs ------_=_NextPart_001_01C5EBA2.47D96C1F-- From mavs-bounces@ietf.org Thu Nov 17 16:08:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqzO-0004cP-92; Thu, 17 Nov 2005 16:08:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcqzM-0004by-7L for MAVS@megatron.ietf.org; Thu, 17 Nov 2005 16:08:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23607 for ; Thu, 17 Nov 2005 16:07:38 -0500 (EST) From: matthew.ford@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcrH2-0001oG-Ni for mavs@ietf.org; Thu, 17 Nov 2005 16:26:30 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 21:08:00 +0000 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Nov 2005 21:08:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Mavs] Latest mavs requirements draft for review Date: Thu, 17 Nov 2005 21:08:07 -0000 Message-ID: <4E28CEA517A795438B120F62D182A8C9025D4F27@I2KM11-UKBR.domain1.systemhost.net> Thread-Topic: [Mavs] Latest mavs requirements draft for review Thread-Index: AcXrokdeG5LEu0jqRd6N8o6gSVfFowAGHb/Q To: X-OriginalArrivalTime: 17 Nov 2005 21:08:00.0212 (UTC) FILETIME=[FDA99140:01C5EBBA] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: mavs@ietf.org X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org Hi Jim, > -----Original Message----- > From: mavs-bounces@ietf.org [mailto:mavs-bounces@ietf.org] On=20 > Behalf Of Jim Guichard (jguichar) > Sent: 17 November 2005 18:11 > To: MAVS@ietf.org > Subject: [Mavs] Latest mavs requirements draft for review >=20 > Please see the attached and provide comment .. regards, To save reading through the entire document again, would you please provide some detail regarding how this rev differs from the last one? I didn't find this in the document itself. Thanks, Mat _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs From mavs-bounces@ietf.org Thu Nov 17 19:16:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctvP-0002Ai-Qn; Thu, 17 Nov 2005 19:16:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecr1B-0005cq-AR for MAVS@megatron.ietf.org; Thu, 17 Nov 2005 16:10:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24061 for ; Thu, 17 Nov 2005 16:09:31 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcrIq-0001ya-Nj for mavs@ietf.org; Thu, 17 Nov 2005 16:28:22 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2005 13:09:48 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAHL9c6g015780; Thu, 17 Nov 2005 13:09:46 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 16:09:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: [Mavs] Latest mavs requirements draft for review Date: Thu, 17 Nov 2005 16:09:20 -0500 Message-ID: <9A3A6AC97A8CF44DACD99DC00BEC235A0DDAAE@xmb-rtp-203.amer.cisco.com> Thread-Topic: [Mavs] Latest mavs requirements draft for review Thread-Index: AcXrokdeG5LEu0jqRd6N8o6gSVfFowAGHb/QAAAYwzA= From: "Jim Guichard \(jguichar\)" To: X-OriginalArrivalTime: 17 Nov 2005 21:09:21.0106 (UTC) FILETIME=[2DE10320:01C5EBBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 17 Nov 2005 19:16:19 -0500 Cc: mavs@ietf.org X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org Only a couple of cosmetic changes plus I put it into .txt format rather than .doc Jim Guichard CCIE# 2069 Principal Engineer - MPLS Technologies "A rich person is not one who has the most, but is one who needs the least" =20 =20 > -----Original Message----- > From: matthew.ford@bt.com [mailto:matthew.ford@bt.com]=20 > Sent: Thursday, November 17, 2005 4:08 PM > To: Jim Guichard (jguichar) > Cc: mavs@ietf.org > Subject: RE: [Mavs] Latest mavs requirements draft for review >=20 > Hi Jim, >=20 > > -----Original Message----- > > From: mavs-bounces@ietf.org [mailto:mavs-bounces@ietf.org]=20 > On Behalf=20 > > Of Jim Guichard (jguichar) > > Sent: 17 November 2005 18:11 > > To: MAVS@ietf.org > > Subject: [Mavs] Latest mavs requirements draft for review > >=20 > > Please see the attached and provide comment .. regards, >=20 > To save reading through the entire document again, would you=20 > please provide some detail regarding how this rev differs=20 > from the last one? I didn't find this in the document itself. >=20 > Thanks, > Mat >=20 _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs From mavs-bounces@ietf.org Thu Nov 24 04:25:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfDML-0004nE-J7; Thu, 24 Nov 2005 04:25:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef3Kb-0003FR-Uc for MAVS@megatron.ietf.org; Wed, 23 Nov 2005 17:43:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10535 for ; Wed, 23 Nov 2005 17:42:32 -0500 (EST) Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef3dX-0001B4-6g for mavs@ietf.org; Wed, 23 Nov 2005 18:02:48 -0500 Received: from IBM9FDB04D90E9 (87-196-2-61.net.novis.pt [87.196.2.61]) by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id jANMhHFe006107; Wed, 23 Nov 2005 22:43:18 GMT From: "Edmundo Monteiro" To: Date: Wed, 23 Nov 2005 22:42:33 -0000 Organization: University of Coimbra Message-ID: <00e501c5f07f$35d93f70$df00020a@IBM9FDB04D90E9> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXwfzBy7iAmilq8RdqbX0hEEfR55Q== X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=1.022, required 3, BAYES_00 -2.60, BLANK_LINES_70_80 1.80, MISSING_SUBJECT 1.82) X-FCTUC-DEI-SIC-MailScanner-From: edmundo@dei.uc.pt X-Spam-Score: 0.9 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 24 Nov 2005 04:25:40 -0500 Cc: mavs@ietf.org Subject: [Mavs] (no subject) X-BeenThere: mavs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiprovider End-to-end VPN Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mavs-bounces@ietf.org Errors-To: mavs-bounces@ietf.org Subscribe mavs edmundo@dei.uc.pt _______________________________________________ Mavs mailing list Mavs@ietf.org https://www1.ietf.org/mailman/listinfo/mavs