From nobody Thu Oct 1 01:07:55 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8F11B2BA3; Thu, 1 Oct 2015 01:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI6chrSqPcsT; Thu, 1 Oct 2015 01:07:49 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B601B2BA0; Thu, 1 Oct 2015 01:07:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 260F4BF51EF97; Thu, 1 Oct 2015 08:07:46 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t9187kO8002488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Oct 2015 10:07:47 +0200 Received: from [135.224.213.224] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 1 Oct 2015 10:07:46 +0200 Message-ID: <560CE9D1.7020406@alcatel-lucent.com> Date: Thu, 1 Oct 2015 10:07:45 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: BESS , Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: [Pals] IPR disclosure notification on spbm-evpn X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:07:51 -0000 Former L2VPN WG participants, it was brought to my attention that you were possibly not aware of IPR existing against draft-...-spbm-evpn at the times you supported the document (Adoption: 10/2013; WGLC: 10/2014) even if it had been disclosed prior to adoption (05/2013). This could be due to a lack of an explicit notification towards the WG about this IPR disclosure. So please have a look at the IPR disclosure [1] and express your opinion if any. Thank you Martin (as shepherd) --- [1] https://datatracker.ietf.org/ipr/2085/ From nobody Thu Oct 1 02:32:31 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB701A049A; Thu, 1 Oct 2015 02:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3vuiqziowZ5; Thu, 1 Oct 2015 02:32:27 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD07C1A0AF1; Thu, 1 Oct 2015 02:32:27 -0700 (PDT) Received: from [192.168.1.10] (unknown [112.205.86.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 28C2318013DA; Thu, 1 Oct 2015 11:32:23 +0200 (CEST) To: Martin Vigoureux , BESS , pals@ietf.org References: <560CE9D1.7020406@alcatel-lucent.com> From: Loa Andersson Message-ID: <560CFD9D.4030208@pi.nu> Date: Thu, 1 Oct 2015 17:32:13 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <560CE9D1.7020406@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pals] [bess] IPR disclosure notification on spbm-evpn X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:32:29 -0000 Martin, I remember checking back when we were doing the wglc, I had no concerns, I can't see that that would have changed. /Loa PS It would be good to have a table explaining what the different IPR disclosures actully means. On 2015-10-01 16:07, Martin Vigoureux wrote: > Former L2VPN WG participants, > > it was brought to my attention that you were possibly not aware of IPR > existing against draft-...-spbm-evpn at the times you supported the > document (Adoption: 10/2013; WGLC: 10/2014) even if it had been > disclosed prior to adoption (05/2013). > > This could be due to a lack of an explicit notification towards the WG > about this IPR disclosure. > > So please have a look at the IPR disclosure [1] and express your opinion > if any. > > Thank you > > Martin (as shepherd) > > --- > [1] https://datatracker.ietf.org/ipr/2085/ > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Oct 1 06:43:00 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0851A0389; Thu, 1 Oct 2015 06:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5_IvQNxXaL7; Thu, 1 Oct 2015 06:42:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E09761A0161; Thu, 1 Oct 2015 06:42:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001134257.12685.1930.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 06:42:57 -0700 Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, pals@ietf.org Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 13:42:59 -0000 Barry Leiba has entered the following ballot position for draft-ietf-pwe3-iccp-stp-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a small thing, but please give some consideration to this: A 2119 "SHOULD" defines something that implementations need to do unless they have a good reason not to, and fully understand the issues and the consequences of not doing it. In general, I believe that means that specifications, when they use "SHOULD", need to include enough information for readers to understand why it's a "SHOULD" and to evaluate the consequences. That seems missing from many of the SHOULDs here, and I'd like to see you go through the document, find the ones that aren't making it clear enough, and beef them up just a little. An example where this is done right is in Section 4.2.3: While a PE has sent out a synchronization request for a particular PE node, it SHOULD silently ignore all TLVs from that node, that are received prior to the synchronization response and which carry the same type of information being requested. This saves the system from the burden of updating state that will ultimately be overwritten by the synchronization response. Note that TLVs pertaining to other systems should continue to be processed normally. THe second sentence explains why, and gives me some idea of what to consider when I'm writing my implementation. Thank you. There are others that get it right as well. A particularly weak one is in Section 4.2.1: A PE SHOULD follow the following order when advertising its STP state upon initial application connection setup: What's the significance of that order, from an interoperability, performance, or security perspective? What happens if, because of how my implementation is written, it's easier for me to do them in a different order and I decide to do so, not knowing what the consequences are? From nobody Thu Oct 1 15:29:47 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDED51A8AC4; Thu, 1 Oct 2015 15:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlLhW76UmWxB; Thu, 1 Oct 2015 15:29:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEFF1A8ABA; Thu, 1 Oct 2015 15:29:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151001222944.11678.98932.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 15:29:44 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-ms-pw-protection-03.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 22:29:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : S-PE Protection for MPLS and MPLS-TP Static Multi-Segment Pseudowires Authors : Andrew G. Malis Loa Andersson Huub van Helvoort Jongyoon Shin Lei Wang Alessandro D'Alessandro Filename : draft-ietf-pals-ms-pw-protection-03.txt Pages : 9 Date : 2015-10-01 Abstract: In MPLS and MPLS-TP environments, statically provisioned Single- Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the switching PEs (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-ms-pw-protection-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-ms-pw-protection-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 1 18:21:45 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC45C1A902B; Thu, 1 Oct 2015 18:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5y3iokkDgS7; Thu, 1 Oct 2015 18:21:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1B51A873B; Thu, 1 Oct 2015 18:21:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151002012140.32394.56280.idtracker@ietfa.amsl.com> Date: Thu, 01 Oct 2015 18:21:40 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] Last Call: (S-PE Protection for MPLS and MPLS-TP Static Multi-Segment Pseudowires) to Proposed Standard X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 01:21:42 -0000 The IESG has received a request from the Pseudowire And LDP-enabled Services WG (pals) to consider the following document: - 'S-PE Protection for MPLS and MPLS-TP Static Multi-Segment Pseudowires' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In MPLS and MPLS-TP environments, statically provisioned Single- Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the switching PEs (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 2 08:41:04 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBC91B2C3A for ; Fri, 2 Oct 2015 08:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.403 X-Spam-Level: X-Spam-Status: No, score=-13.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st6B-Qg-kglx for ; Fri, 2 Oct 2015 08:40:59 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BD51B2C38 for ; Fri, 2 Oct 2015 08:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22486; q=dns/txt; s=iport; t=1443800459; x=1445010059; h=reply-to:from:to:subject:cc:message-id:date:mime-version; bh=+K0B2H7cuVVO/r8G2LOBNKnf1TC3OMzcCaK3/o1xQ94=; b=TlJ2N11J2c8JkO1CgboALD6eO7l0I+QfiJWuJ+SoFleiUTQXERRzoPJI eNS8xJeOQQ8cvZZZfM0+avtkg8UU8kerJDCfxhPe+Q6JTOhFpGhQ14Prc K3TS583p5MzT+V0rq9RmeYn62fDu0/5DGQ0G52UXl9SP1uHPajuWA14RS 8=; X-IronPort-AV: E=Sophos;i="5.17,623,1437436800"; d="scan'208,217";a="611977914" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 02 Oct 2015 15:40:57 +0000 Received: from [10.55.98.185] (ams-stbryant-8818.cisco.com [10.55.98.185]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t92FeuRv010498; Fri, 2 Oct 2015 15:40:56 GMT From: Stewart Bryant To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" , "pals@ietf.org" Message-ID: <560EA591.4080100@cisco.com> Date: Fri, 2 Oct 2015 16:41:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040803060106090203020206" Archived-At: Cc: "pals-chairs@tools.ietf.org" Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:41:02 -0000 This is a multi-part message in MIME format. --------------040803060106090203020206 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I am sorry that this is a long email, but I wanted to collect the facts together in one place and set out the complete scene to the PALS WG. The critical concern is contained in the following email fragment from Lizhong: ======= In RFC4447 and 4447bis, it clearly said: Using the PWid FEC, each of the two pseudowire endpoints independently initiates the setup of a unidirectional LSP. An outgoing LSP and an incoming LSP are bound together into a single pseudowire if they have the same PW ID and PW type. The behavior is a correct description for LDP-DU mode which PW applies. And that is also the behavior most vendors implement. Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says: A PE that receives a PW label mapping message with an E-Tree Sub-TLV from its peer PE, after saving the VLAN information for the PW, MUST process it as follows: ..... 3) If the P bit is set { If the PE is a leaf-only node itself, a label release message with a status code "Leaf to Leaf PW released" is sent to the peer PE and exit the process; Else the PE SHOULD set the Optimized-Mode to TRUE. } That means, if PE1 receiving a label mapping from PE2 with P bit set, PE1 will send label release. Then PE2 will never send label mapping again to PE1 even when PE1 changes from leaf-only node to root-leaf node. For LDP-DU mode, PE2 will not send label mapping again when receiving PE1's label mapping. Then the PW will not be setup successfully. Then only way is to configure the same PW on PE2 again. The correct behavior is, label release message should not be sent. For PW signaling, the unacceptable of any Interface Parameter will not lead to any label release, but just simply let the PW down in forwarding plane. ======== Andy looked at this from the point of view of the MEF and notes in private conversation: ========= In the E-tree service as defined by MEF, you can have one or more roots and one or more leafs. In a single E-tree service (think of a multipoint PW with some of the CEs configured as roots as some as leafs), all leafs and roots receive frames sent by the roots. All roots receive frames sent by the leafs. However, leafs may not receive any frames sent by other leafs. The draft, as written, doesn't bring up an underlying pt-to-pt PWs to carry frames for the service between PEs that only have leafs attached. Since the leafs can't sent frames to each other, that is an economical use of PWs in the network. Lizhong's point is that this makes it impossible to add a new root to an existing PE in an E-tree that previously only had leafs. I agree that would be a problem if there was a requirement to modify an existing E-tree service. However, this draft has no other mechanisms to explicitly support E-tree modification, nor is such modification a requirement of the underlying MEF specification. BTW, since this work was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet Services Definitions Phase 3", August, 2014, and that reference should be updated in the draft. My opinion is that the draft as it stands is technically correct if you don't need the ability to reconfigure an existing E-tree service dynamically. ========== Now whilst I can support the idea that dynamic reconfiguration of E-tree is not needed, I have a concern. My understanding the text in question is that it is saying that if A is configured as leaf only, and B which is also configured as leaf only attempts to configure a PW between them, then A rejects the PW setup. That sounds very reasonable to me, since there is a misconfig. If A did not do the reject, then B would forever be consuming resource waiting for A and B would have no idea of the misconfig. That accords with Andy's view above. However I was worried what would happen if A was misconfigured as leaf only and the configuration was corrected to root-leaf. What would in my view be difficult to accept was the need to take a human, or NMS action at B to recover the situation. However provided that A closed the LDP session with B and re-instate it B would then send the mapping message again. Thus the system is recoverable without needing to visit B which is in my mind a fundamental requirement since A could have got into the wrong mode as a result of an error. The problem I see is if A has a bunch of other PWs with B they will get torn down in order for A to have the config error fixed. However if that is a problem you need two LDP sessions between A and B, one for L2VPN and one for regular PWs. My inclination is that the draft is basically correct, and that whilst Lizhong is correct that the PW will not come up without some action, reconfiguring the PW on B is not the only action that will cause the PW to come up. So this comes down to a WG decision in terms of which is the least unacceptable behaviour - A having to re-cycle the LDP session, or B wasting resources. I think I prefer the behaviour proposed in the draft. A way forward is to leave the logic as written in the draft, but to add text describing the basis for excluding dynamic re-configuration as a normal operational mode and to note the actions that need to be taken when re-configuration is forced for some reason. Whilst we were pondering what do with the text the chairs and AD received another proposal from the authors: ====== In general, FEC PWid(0x80) is used in VPLS with manual provisioning, while Generalized PWid (0x81) is used with auto-discovery. As discussed in Section 5.2, VLAN mapping parameters can be provisioned without a signaling protocol, Optimized Mode can also be a parameter to be provisioned. The approach we’ve taken in the current draft-ietf-l2vpn-vpls-pe-etree-09 does allow this. Quite a few service providers may prefer to control all these E-Tree connectivity by themselves. When E-Tree signaling protocol for PWid FEC is considered, the following options are also feasible: a)Disable Optimized mode for FEC PWid(0x80), thus root/leaf role change in the E-Tree topology will not have any influence on the PW. b)Add another appendix into the document for the full support of Optimized mode with FEC PWid(0x80). The idea is: the PE sends a label mapping firstly and then send a label request to its peer PEs (so that they will reply with a label mapping respectively). Since Optimized mode is an optional piece in the document, I would regard option a) as a simple tradeoff (as I am aware, E-VPN does not support Optimized mode for E-Tree either. ======== Thus we have three proposals on the table: 1) Leave the design as it is, but add text to describe the constraint and what happens if you have to change mode and what to do about it. 2) Exclude optimization in the FEC PWid(0x80) case 3) Add an appendix describing support for the FEC PWid(0x80) case. My inclination would be to go with option (1) but I seek the views of the WG, and of course any corrections in my analysis. - Stewart --------------040803060106090203020206 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I am sorry that this is a long email, but I wanted to collect the
facts together in one place and set out the complete scene to
the PALS WG.

The critical concern is contained in the following email fragment
from Lizhong:

=======

In RFC4447 and 4447bis, it clearly said:

Using the PWid FEC, each of the two pseudowire endpoints
   independently initiates the setup of a unidirectional LSP.   An
   outgoing LSP and an incoming LSP are bound together into a single
   pseudowire if they have the same PW ID  and PW type.
The behavior is a correct description for LDP-DU mode which PW applies.
And that is also the behavior most vendors implement.
 
Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:
 A PE that receives a PW label mapping message with an E-Tree Sub-TLV
   from its peer PE, after saving the VLAN information for the PW, MUST
   process it as follows:
.....
3) If the P bit is set
 
      {
 
          If the PE is a leaf-only node itself, a label release message
      with a status code "Leaf to Leaf PW released" is sent to the peer
      PE and exit the process;
 
          Else the PE SHOULD set the Optimized-Mode to TRUE.
 
      }
That means, if PE1 receiving a label mapping from PE2 with P bit set, 
PE1 will send label release. Then PE2 will never send label mapping
again to PE1 even when PE1 changes from leaf-only node to root-leaf node. For LDP-DU
mode, PE2 will not send label mapping again when receiving PE1's label mapping.
Then the PW will not be setup successfully. Then only way is to configure the 
same PW on PE2 again.
The correct behavior is, label release message should not be sent.
For PW signaling, the unacceptable of any Interface Parameter will not lead to any 
label release, but just simply let the PW down in forwarding plane.
 
========

Andy looked at this from the point of view of the MEF and notes in
private conversation:

=========
In the E-tree service as defined by MEF, you can have one or more roots
and one or more leafs.

In a single E-tree service (think of a multipoint PW with some of the CEs
configured as roots as some as leafs), all leafs and roots receive frames
sent by the roots. All roots receive frames sent by the leafs. However,
leafs may not receive any frames sent by other leafs.

The draft, as written, doesn't bring up an underlying pt-to-pt PWs to
carry frames for the service between PEs that only have leafs attached.
Since the leafs can't sent frames to each other, that is an economical
use of PWs in the network.

Lizhong's point is that this makes it impossible to add a new root to
an existing PE in an E-tree that previously only had leafs.

I agree that would be a problem if there was a requirement to modify
an existing E-tree service. However, this draft has no other mechanisms
to explicitly support E-tree modification, nor is such modification a
requirement of the underlying MEF specification. BTW, since this work
was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet
Services Definitions Phase 3", August, 2014, and that reference should
be updated in the draft.

My opinion is that the draft as it stands is technically correct if you
don't need the ability to reconfigure an existing E-tree service dynamically.

==========

Now whilst I can support the idea that dynamic reconfiguration of
E-tree is not needed, I have a concern.

My understanding the text in question is that it is saying that if
A is configured as leaf only, and B which is also configured as
leaf only attempts to configure a PW between them, then A rejects
the PW setup.

That sounds very reasonable to me, since there is a misconfig.

If A did not do the reject, then B would forever be consuming
resource waiting for A and B would have no idea of the
misconfig. That accords with Andy's view above.

However I was worried what would happen if A was misconfigured
as leaf only and the configuration was corrected to root-leaf.
What would in my view be difficult to accept was the need to
take a human, or NMS action at B to recover the situation.
However provided that A closed the LDP session with B
and re-instate it B would then send the mapping message again.
Thus the system is recoverable without needing to visit B which
is in my mind a fundamental requirement since A could have
got into the wrong mode as a result of an error.

The problem I see is if A has a bunch of other PWs with B
they will get torn down in order for A to have the config error
fixed. However if that is a problem you need two LDP sessions
between A and B, one for L2VPN and one for regular PWs.

My inclination is that the draft is basically correct, and that whilst
Lizhong is correct that the PW will not come up without some
action, reconfiguring the PW on B is not the only action
that will cause the PW to come up.

So this comes down to a WG decision in terms of which is the
least unacceptable behaviour - A having to re-cycle the LDP
session, or B wasting resources. I think I prefer the behaviour
proposed in the draft.

A way forward is to leave the logic as written in the draft, but to
add text describing the basis for excluding dynamic re-configuration
as a normal operational mode and to note the actions that need
to be taken when re-configuration is forced for some reason.

Whilst we were pondering what do with the text the chairs
and AD received another proposal from the authors:

======

In general, FEC PWid(0x80) is used in VPLS with manual provisioning,
while Generalized PWid (0x81) is used with auto-discovery.

As discussed in Section 5.2, VLAN mapping parameters can be provisioned
without a signaling protocol, Optimized Mode can also be a parameter
to be provisioned.

The approach we’ve taken in the current draft-ietf-l2vpn-vpls-pe-etree-09
does allow this. Quite a few service providers may prefer to control
all these E-Tree connectivity by themselves.

When E-Tree signaling protocol for PWid FEC is considered, the following
options are also feasible:

a)       Disable Optimized mode for FEC PWid(0x80), thus root/leaf role
change in the E-Tree topology will not have any influence on the PW.

b)       Add another appendix into the document for the full support of
Optimized mode with FEC PWid(0x80).

The idea is: the PE sends a label mapping firstly and then send a label
request to its peer PEs (so that they will reply with a label mapping
respectively).

Since Optimized mode is an optional piece in the document, I would
regard option a) as a simple tradeoff (as I am aware, E-VPN does not
support Optimized mode for E-Tree either.

========


Thus we have three proposals on the table:

1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

My inclination would be to go with option (1) but I seek the views of
the WG, and of course any corrections in my analysis.

- Stewart

--------------040803060106090203020206-- From nobody Fri Oct 2 11:51:23 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8331B3148 for ; Fri, 2 Oct 2015 11:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muQx_ROEonvc for ; Fri, 2 Oct 2015 11:51:20 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE94D1B3144 for ; Fri, 2 Oct 2015 11:51:19 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-0f-560e7285ae20 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F9.DC.32596.5827E065; Fri, 2 Oct 2015 14:03:18 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 14:51:18 -0400 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: PALS IETF 94 Slot Requests - Yokohama Thread-Index: AdD9Q1Iu1ZEYv0JeSDKKdZlJig3YOQ== Date: Fri, 2 Oct 2015 18:51:17 +0000 Message-ID: <354A8111-2B9C-40EB-9121-FCEF403C51E2@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_354A81112B9C40EB9121FCEF403C51E2ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPiG5bEV+YwZVr/BZr/q1jcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoNJC1gLvttV/Lk9k6mBcZJtFyMnh4SAicTPaV2MELaYxIV7 69m6GLk4hASOMkpMbNgI5SxjlLj/eiErSBUbUMe6jXtYQGwRAWWJXeengHULC+hJbNh3CCpu LLH11RJGCFtPYv7RR2wgNouAisTS2VOYQGxeAXuJqfevgtUzAm3+fmoNWJxZQFzi1pP5TBAX CUgs2XOeGcIWlXj5+B8rRE2yxOzTD1kh5ghKnJz5hGUCo+AsJO2zkJTNQlI2i5EDKK4psX6X PkSJosSU7ofsELaGROucuVC2tcTfZY/ZkNUsYORYxchRWpxalptuZLCJERj4xyTYdHcw7nlp eYhRgINRiYd3QQlvmBBrYllxZe4hRmkOFiVx3v1L7ocKCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYAwKrfy4e8L3l+7hO24umPNYwS0o+Pm6bpuTya99ZLeyiliZPip68bzwc3X31kNR/0RX 1aVEx2ztWP5kb/W91k6umylJPZrXyq9vrg6ytu1ZOfXI4nV7NjxaYnk8ZBHbo06fnQ8evXsj d7M2/uPCQ+8Z/IXe35z9OHP6T+2S9tWuj5vD7jauqnmoxFKckWioxVxUnAgAbzy/+F0CAAA= Archived-At: Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 18:51:21 -0000 --_000_354A81112B9C40EB9121FCEF403C51E2ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KSXQncyB0aGF0IHRpbWUgYWdhaW4uDQpJZiB5b3UgbmVlZCBhIHByZXNlbnRhdGlv biBzbG90IGZvciB0aGUgSUVURiA5NCBQQUxTIHNlc3Npb24sIHBsZWFzZSByZXBseSB0byB0aGlz IGVtYWlsIChzdWJqZWN0IGludGFjdCkgY29tcGxldGluZyB0aGUgZm9ybSBiZWxvdy4NClBsZWFz ZSB1c2UgdGhpcyBmb3JtIGFuZCBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCB3aXRoIHRoZSBz dWJqZWN0IGludGFjdC4gIChOb3QgZG9pbmcgc28gcHJvYmFibHkgbWVhbnMgeW91ciByZXF1ZXN0 IHdpbGwgbm90IHRyaWdnZXIgdGhlIGZpbHRlciBJIHVzZSB0byBpZGVudGlmeSBQQUxTIHNsb3Qg cmVxdWVzdHMgYW5kIGJlIGxvc3QgaW4gbXkgZW1haWwsIG5ldmVyIHRvIGJlIGZvdW5kLiA6LSkN Cg0KRm9ybToNCjEuIHRvcGljIChlLmcuLCBNUExTIGFuZCBFdGhlcm5ldCBPQU0gSW50ZXJ3b3Jr aW5nKToNCjIuIFVSTCB0byB5b3VyIGRyYWZ0IG9uIERhdGF0cmFja2VyIOKAkyB5b3Ugb25seSBu ZWVkIHRvIHByb3ZpZGUgdGhlIGZpbGUgbmFtZSB0byB0aGUgZXhhbXBsZSBVUkwgKGUuZy4sIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wd2UzLW1wbHMtZXRoLW9h bS1pd2svKToNCjMuIGJyaWVmIHN0YXRlbWVudCBvZiBvYmplY3RpdmVzIGFuZCBpc3N1ZXMgdG8g YmUgZGlzY3Vzc2VkIGFuZCByZXNvbHZlZCB2aWEgdGhlIHByZXNlbnRhdGlvbiBkdXJpbmcgdGhl IG1lZXRpbmcgIChlLmcuLCBuZWVkIHRvIGFkZHJlc3Mgc2VjdXJpdHkgaXNzdWVzIGFuZCBnZXQg ZGlyZWN0aW9uIGZyb20gdGhlIFdHKToNCjQuIHJlcXVlc3RlZCBkdXJhdGlvbiAobm9ybS9kZWZh dWx0IGlzIDEwIG1pbik6DQo1LiBzcGVha2VyIEdpdmVuLW5hbWUgRkFNSUxZLU5BTUUgKGUuZy4s IERhdmUgU0lOSUNST1BFKToNCg0KVGhhbmtzIQ0KRGF2ZQ0K --_000_354A81112B9C40EB9121FCEF403C51E2ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9D07C96A7ADB5B419AA94C78169AEEC3@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsiPg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9z b2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIv UkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQ+SGkgQWxsLDxvOnA+PC9vOnA+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0J3MgdGhhdCB0aW1lIGFnYWluLiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHlvdSBuZWVkIGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIHRoZSBJ RVRGIDk0IFBBTFMgc2Vzc2lvbiwgcGxlYXNlJm5ic3A7PGI+cmVwbHkgdG8gdGhpcyBlbWFpbCZu YnNwOzwvYj4oc3ViamVjdCBpbnRhY3QpIGNvbXBsZXRpbmcgdGhlIGZvcm0gYmVsb3cuICZuYnNw OyZuYnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2 Pg0KPC9zcGFuPjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHht bG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0i dXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3 dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHU+UGxlYXNlPC91PjwvaT4mbmJzcDs8L2I+dXNlIHRoaXMg Zm9ybSBhbmQmbmJzcDs8Yj48aT48dT5wbGVhc2U8L3U+PC9pPjwvYj4mbmJzcDtyZXBseSB0byB0 aGlzIGVtYWlsIHdpdGggdGhlIHN1YmplY3QgaW50YWN0LiAmbmJzcDsoTm90IGRvaW5nIHNvIHBy b2JhYmx5IG1lYW5zIHlvdXIgcmVxdWVzdCB3aWxsIG5vdCB0cmlnZ2VyIHRoZSBmaWx0ZXImbmJz cDtJIHVzZSB0byBpZGVudGlmeSBQQUxTIHNsb3QgcmVxdWVzdHMgYW5kIGJlIGxvc3QNCiBpbiBt eSBlbWFpbCwgbmV2ZXIgdG8gYmUgZm91bmQuIDotKTwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9zcGFuPjwvZGl2Pg0KPC9zcGFuPjwvc3Bhbj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJn YmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDExLjI1cHQ7Ij5G b3JtOjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0K PC9zcGFuPg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1 NSwgMjU1LCAwKTsiPjEuIHRvcGljIChlLmcuLCZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1 NSwgMCk7Ij5NUExTIGFuZCBFdGhlcm5ldCBPQU0gSW50ZXJ3b3JraW5nKTo8L3NwYW4+PC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIg c3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4NCjxkaXYg eG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVD LWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OiAxMS4yNXB0OyI+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBVUkwgdG8geW91ciBkcmFmdCBvbiBEYXRhdHJh Y2tlciDigJMmbmJzcDt5b3Ugb25seSBuZWVkIHRvIHByb3ZpZGUgdGhlIGZpbGUgbmFtZSB0byB0 aGUgZXhhbXBsZSBVUkwgKGUuZy4sJm5ic3A7PGEgcmVsPSJub2ZvbGxvdyIgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXB3ZTMtbXBscy1ldGgtb2FtLWl3 ay8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wd2UzLW1wbHMt ZXRoLW9hbS1pd2svPC9hPik6DQogJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBicmllZiBzdGF0ZW1lbnQgb2Ygb2JqZWN0aXZlcyBh bmQgaXNzdWVzIHRvIGJlIGRpc2N1c3NlZCBhbmQgcmVzb2x2ZWQgdmlhIHRoZSBwcmVzZW50YXRp b24gZHVyaW5nIHRoZSBtZWV0aW5nICZuYnNwOyhlLmcuLCBuZWVkIHRvIGFkZHJlc3Mgc2VjdXJp dHkgaXNzdWVzIGFuZCBnZXQgZGlyZWN0aW9uIGZyb20gdGhlIFdHKTogJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiByZXF1ZXN0ZWQg ZHVyYXRpb24gKG5vcm0vZGVmYXVsdCBpcyAxMCBtaW4pOiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUuIHNwZWFrZXIgR2l2ZW4tbmFt ZSBGQU1JTFktTkFNRSAoZS5nLiwgRGF2ZSBTSU5JQ1JPUEUpOiAmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MhPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQt Y29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5EYXZlPC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwv c3Bhbj4NCjxkaXY+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_354A81112B9C40EB9121FCEF403C51E2ericssoncom_-- From nobody Sun Oct 4 08:43:02 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8B11B29D4 for ; Sun, 4 Oct 2015 08:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy1nicIdr0CF for ; Sun, 4 Oct 2015 08:42:55 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E173D1B29D3 for ; Sun, 4 Oct 2015 08:42:54 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so84608396wic.1 for ; Sun, 04 Oct 2015 08:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CvMFuo/AmOjSiRsMvlRVqBt4y6LyfXEXHRsVeI13fYE=; b=pejxsvtWf5BrMCCNJD4Db/44pCMPsU3aHbqrd9t/qiB1jY/5pdHEoTKZmqdkAKaSEm wZDTqzbSybXJQp4CWgRLMRyzR+KkI9gndxwdMM+PGQjIrD6Pe5FTzT/j5w4fwLKGx3Si 4qs345cO5znoIxr+WooDbedG/EP4pNV8hjicY23ZKkrOEQ55hUhg1Y/qLvBHRXQFWNFp MnFh3IkAspUa7HjIshOzif+3BSugm6JZw8o7FOdRpU7XEm7sijRcKQ9EHqFU1pXSXZeU yzcgfC+CZEgaiP6MjsidXKLL87QQxVCavrxl6NbllY46EWotuAFMER2FxcGMbYhg3OS4 eWWA== MIME-Version: 1.0 X-Received: by 10.180.10.170 with SMTP id j10mr7551940wib.77.1443973373439; Sun, 04 Oct 2015 08:42:53 -0700 (PDT) Received: by 10.194.236.164 with HTTP; Sun, 4 Oct 2015 08:42:53 -0700 (PDT) Date: Sun, 4 Oct 2015 23:42:53 +0800 Message-ID: From: Lizhong Jin To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" , "pals@ietf.org" , "Stewart Bryant (stbryant)" , pals-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c2660afd3b630521493f2d Archived-At: Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 15:42:59 -0000 --001a11c2660afd3b630521493f2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stewart, Thanks for the comment. This is a long email. You give us three options: 1) Leave the design as it is, but add text to describe the constraint and what happens if you have to change mode and what to do about it. 2) Exclude optimization in the FEC PWid(0x80) case 3) Add an appendix describing support for the FEC PWid(0x80) case. Then I prefer option 1. Because option2 is not reasonable, and the solution in option3 provided by the author is not the best one. I would like to provide opition4 for WG to consider: 4) Add description to support for the FEC PWid(0x80) case, in appendix or text I don't care. The solution is: label release message should not be sent in section 6.1. For PW signaling, the unacceptable of any Interface Parameter will not lead to any label release, but just simply let the PW down in forwarding plane. Regards Lizhong > ---------- Forwarded message ---------- > From: Stewart Bryant > To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" < > draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org>, "pals@ietf.org" < > pals@ietf.org> > Cc: "pals-chairs@tools.ietf.org" > Date: Fri, 2 Oct 2015 16:41:05 +0100 > Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward > I am sorry that this is a long email, but I wanted to collect the > facts together in one place and set out the complete scene to > the PALS WG. > > The critical concern is contained in the following email fragment > from Lizhong: > > =3D=3D=3D=3D=3D=3D=3D > > In RFC4447 and 4447bis, it clearly said: > > Using the PWid FEC, each of the two pseudowire endpoints > > independently initiates the setup of a unidirectional LSP. An > > outgoing LSP and an incoming LSP are bound together into a single > > pseudowire if they have the same PW ID and PW type. > > The behavior is a correct description for LDP-DU mode which PW applies. > > And that is also the behavior most vendors implement. > > > > Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says: > > A PE that receives a PW label mapping message with an E-Tree Sub-TLV > > from its peer PE, after saving the VLAN information for the PW, MUST > > process it as follows: > > ..... > > 3) If the P bit is set > > > > { > > > > If the PE is a leaf-only node itself, a label release message > > with a status code "Leaf to Leaf PW released" is sent to the peer > > PE and exit the process; > > > > Else the PE SHOULD set the Optimized-Mode to TRUE. > > > > } > > That means, if PE1 receiving a label mapping from PE2 with P bit set, > > PE1 will send label release. Then PE2 will never send label mapping > > again to PE1 even when PE1 changes from leaf-only node to root-leaf node.= For LDP-DU > > mode, PE2 will not send label mapping again when receiving PE1's label ma= pping. > > Then the PW will not be setup successfully. Then only way is to configure= the > > same PW on PE2 again. > > The correct behavior is, label release message should not be sent. > > For PW signaling, the unacceptable of any Interface Parameter will not le= ad to any > > label release, but just simply let the PW down in forwarding plane. > > > > =3D=3D=3D=3D=3D=3D=3D=3D > > Andy looked at this from the point of view of the MEF and notes in > private conversation: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > In the E-tree service as defined by MEF, you can have one or more roots > and one or more leafs. > > In a single E-tree service (think of a multipoint PW with some of the CEs > configured as roots as some as leafs), all leafs and roots receive frames > sent by the roots. All roots receive frames sent by the leafs. However, > leafs may not receive any frames sent by other leafs. > > The draft, as written, doesn't bring up an underlying pt-to-pt PWs to > carry frames for the service between PEs that only have leafs attached. > Since the leafs can't sent frames to each other, that is an economical > use of PWs in the network. > > Lizhong's point is that this makes it impossible to add a new root to > an existing PE in an E-tree that previously only had leafs. > > I agree that would be a problem if there was a requirement to modify > an existing E-tree service. However, this draft has no other mechanisms > to explicitly support E-tree modification, nor is such modification a > requirement of the underlying MEF specification. BTW, since this work > was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet > Services Definitions Phase 3", August, 2014, and that reference should > be updated in the draft. > > My opinion is that the draft as it stands is technically correct if you > don't need the ability to reconfigure an existing E-tree service > dynamically. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Now whilst I can support the idea that dynamic reconfiguration of > E-tree is not needed, I have a concern. > > My understanding the text in question is that it is saying that if > A is configured as leaf only, and B which is also configured as > leaf only attempts to configure a PW between them, then A rejects > the PW setup. > > That sounds very reasonable to me, since there is a misconfig. > > If A did not do the reject, then B would forever be consuming > resource waiting for A and B would have no idea of the > misconfig. That accords with Andy's view above. > > However I was worried what would happen if A was misconfigured > as leaf only and the configuration was corrected to root-leaf. > What would in my view be difficult to accept was the need to > take a human, or NMS action at B to recover the situation. > However provided that A closed the LDP session with B > and re-instate it B would then send the mapping message again. > Thus the system is recoverable without needing to visit B which > is in my mind a fundamental requirement since A could have > got into the wrong mode as a result of an error. > > The problem I see is if A has a bunch of other PWs with B > they will get torn down in order for A to have the config error > fixed. However if that is a problem you need two LDP sessions > between A and B, one for L2VPN and one for regular PWs. > > My inclination is that the draft is basically correct, and that whilst > Lizhong is correct that the PW will not come up without some > action, reconfiguring the PW on B is not the only action > that will cause the PW to come up. > > So this comes down to a WG decision in terms of which is the > least unacceptable behaviour - A having to re-cycle the LDP > session, or B wasting resources. I think I prefer the behaviour > proposed in the draft. > > A way forward is to leave the logic as written in the draft, but to > add text describing the basis for excluding dynamic re-configuration > as a normal operational mode and to note the actions that need > to be taken when re-configuration is forced for some reason. > > Whilst we were pondering what do with the text the chairs > and AD received another proposal from the authors: > > =3D=3D=3D=3D=3D=3D > > In general, FEC PWid(0x80) is used in VPLS with manual provisioning, > while Generalized PWid (0x81) is used with auto-discovery. > > As discussed in Section 5.2, VLAN mapping parameters can be provisioned > without a signaling protocol, Optimized Mode can also be a parameter > to be provisioned. > > The approach we=E2=80=99ve taken in the current draft-ietf-l2vpn-vpls-pe-= etree-09 > does allow this. Quite a few service providers may prefer to control > all these E-Tree connectivity by themselves. > > When E-Tree signaling protocol for PWid FEC is considered, the following > options are also feasible: > > a) Disable Optimized mode for FEC PWid(0x80), thus root/leaf role > change in the E-Tree topology will not have any influence on the PW. > > b) Add another appendix into the document for the full support of > Optimized mode with FEC PWid(0x80). > > The idea is: the PE sends a label mapping firstly and then send a label > request to its peer PEs (so that they will reply with a label mapping > respectively). > > Since Optimized mode is an optional piece in the document, I would > regard option a) as a simple tradeoff (as I am aware, E-VPN does not > support Optimized mode for E-Tree either. > > =3D=3D=3D=3D=3D=3D=3D=3D > > > Thus we have three proposals on the table: > > 1) Leave the design as it is, but add text to describe the constraint and > what happens if you have to change mode and what to do about it. > > 2) Exclude optimization in the FEC PWid(0x80) case > > 3) Add an appendix describing support for the FEC PWid(0x80) case. > > My inclination would be to go with option (1) but I seek the views of > the WG, and of course any corrections in my analysis. > > - Stewart > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > --001a11c2660afd3b630521493f2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stewart,
Thanks for the comment. This is a long email.
<= div>You give us three options:

1) Leave the design as it is, but add text to describe th= e constraint and
what happens if you have to change mode and what to do = about it.

2) Exclude optimization in the=C2=A0FEC PWid(0x80) case

3) Add an appendix describing support for = the=C2=A0FEC PWid(0= x80) case.

=C2=A0T= hen I prefer option 1. Because option2 is not reasonable, and the solution = in option3 provided by the author is not the best one.

=
I would like to provide opition4 for WG to consider:
4)=C2= =A0Add description to support for the=C2=A0FEC PWid(0x80) case, in append= ix or text I don't care. The solution is:
label release message should not be sent in section 6.1.
For PW signaling, the unacceptable of any Interface Parameter will not l=
ead to any
<= pre style=3D"margin-left:21pt">label release, but just simply let the PW down = in forwarding plane.
Reg= ards
Lizhong


=
---------- Forwarded message ----------
From:=C2=A0Stewart Bryant &l= t;stbryant@cisco.com>
To:= =C2=A0"draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" <draft-ietf-l2vpn-vpls-p= e-etree@tools.ietf.org>, "pals= @ietf.org" <pals@ietf.org&= gt;
Cc:=C2=A0"pals-ch= airs@tools.ietf.org" <pals-chairs@tools.ietf.org>
Date:=C2=A0Fri, 2 Oct 2015 16:41= :05 +0100
Subject:=C2=A0[Pals] draft-ietf-l2vpn-vpls-pe-etree - possible= ways forward
=20 =20 =20
I am sorry that this is a long email, but I wanted to collect the
facts together in one place and set out the complete scene to
the PALS WG.

The critical concern is contained in the following email fragment
from Lizhong:

=3D=3D=3D=3D=3D=3D=3D

In RFC4447 an= d 4447bis, it clearly said:

Using the PWid FEC, each of the two pseudowire endpoints
=C2=A0=C2=A0 independently initiates the setup of a unidirectional LSP.=
=C2=A0=C2=A0 An
=C2=A0=C2=A0 outgoing LSP and an incoming LSP are bound together into a=
 single
=C2=A0=C2=A0 pseudowire if they have the same PW ID =C2=A0and PW type.<=
/span>
The behavior is a correct description for LDP-DU mode which PW applies.=

And that is also the behavior most vendors implement.
=C2=A0
Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:=

 A PE that receives a PW label mapping message with an E-Tree Sub-TLV
=C2=A0=C2=A0 from its peer PE, after saving the VLAN information for th=
e PW, MUST
=C2=A0=C2=A0 process it as follows:
.....
3) If the P bit is set
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the PE is a l=
eaf-only node itself, a label release message
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with a status code "Leaf to Leaf PW=
 released" is sent to the peer
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PE and exit the process;
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Else the PE SHOU=
LD set the Optimized-Mode to TRUE.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
That means, if PE1 receiving a label mapping from PE2 with P bit set, <=
/span>
PE1 will send label release. Then PE2 will never send label mapping
again to PE1 even when PE1 changes from leaf-only node to root-leaf=
 node. For LDP-DU<=
/pre>
    
mode, PE2 will not send label mapping agai=
n when receiving PE1's label mapping.

    
Then the PW will not be setup successfully=
. Then only way is to configure the 

    
same PW on PE2 again.

    
The correct behavior is, label release mes=
sage should not be sent.<=
/span>

    
For PW signaling, the unacceptable of any =
Interface Parameter will not lead to any 

    
label release, but just simply let the PW =
down in forwarding plane.=


    
=C2=A0

    =3D=3D=3D=3D=3D=3D=3D=3D

    

    Andy looked at this from the point of view of the MEF and notes in

    private conversation:

    

    
=3D=3D=3D=3D=3D=3D=3D=3D=3D

    

    
In the E-tree service as defined by MEF, you can have one or
      more roots 

      and one or more leafs.

    


    

    
In a single E-tree service (think of a multipoint PW with some
      of the CEs 

      configured as roots as some as leafs), all leafs and roots receive
      frames 

      sent by the roots. All roots receive frames sent by the leafs.
      However, 

      leafs may not receive any frames sent by other leafs.

    


    

    
The draft, as written, doesn't bring up an underlying pt-to-pt
      PWs to 

      carry frames for the service between PEs that only have leafs
      attached. 

      Since the leafs can't sent frames to each other, that is an
      economical 

      use of PWs in the network.

    


    

    
Lizhong's point is that this makes it impossible to add a new
      root to 

      an existing PE in an E-tree that previously only had leafs.

    


    

    
I agree that would be a problem if there was a requirement to
      modify 

      an existing E-tree service. However, this draft has no other
      mechanisms 

      to explicitly support E-tree modification, nor is such
      modification a 

      requirement of the underlying MEF specification. BTW, since this
      work 

      was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Etherne=
t
      

      Services Definitions Phase 3", August, 2014, and that reference
      should 

      be updated in the draft.

      

    

    My opinion is that the draft as it stands is technically correct if
    you 

    don't need the ability to reconfigure an existing E-tree service
    dynamically.

    

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    

    Now whilst I can support the idea that dynamic reconfiguration of

    E-tree is not needed, I have a concern.

    

    My understanding the text in question is that it is saying that if 

    A is configured as leaf only, and B which is also configured as

    leaf only attempts to configure a PW between them, then A rejects 

    the PW setup.

    

    That sounds very reasonable to me, since there is a misconfig.

    

    If A did not do the reject, then B would forever be consuming

    resource waiting for A and B would have no idea of the

    misconfig. That accords with Andy's view above.

    

    However I was worried what would happen if A was misconfigured

    as leaf only and the configuration was corrected to root-leaf.

    What would in my view be difficult to accept was the need to

    take a human, or NMS action at B to recover the situation.

    However provided that A closed the LDP session with B 

    and re-instate it B would then send the mapping message again.

    Thus the system is recoverable without needing to visit B which

    is in my mind a fundamental requirement since A could have

    got into the wrong mode as a result of an error.

    

    The problem I see is if A has a bunch of other PWs with B

    they will get torn down in order for A to have the config error

    fixed. However if that is a problem you need two LDP sessions

    between A and B, one for L2VPN and one for regular PWs.

    

    My inclination is that the draft is basically correct, and that
    whilst

    Lizhong is correct that the PW will not come up without some

    action, reconfiguring the PW on B is not the only action

    that will cause the PW to come up. 

    

    So this comes down to a WG decision in terms of which is the

    least unacceptable behaviour - A having to re-cycle the LDP

    session, or B wasting resources. I think I prefer the behaviour

    proposed in the draft.

    

    A way forward is to leave the logic as written in the draft, but to
    

    add text describing the basis for excluding dynamic re-configuration
    as a normal operational mode and to note the actions that need 

    to be taken when re-configuration is forced for some reason.

    

    Whilst we were pondering what do with the text the chairs

    and AD received another proposal from the authors:

    

    =3D=3D=3D=3D=3D=3D

    

    In general, FEC
      PWid(0x80) is used in VPLS with manual provisioning, 

      while Generalized PWid (0x81) is used with auto-discovery.

    

    As discussed in
      Section 5.2, VLAN mapping parameters can be provisioned 

      without a signaling protocol, Optimized Mode can also be a
      parameter 

      to be provisioned.

    

    The approach we=E2=80=
=99ve
      taken in the current
    draft-ietf-l2vpn=
-vpls-pe-etree-09
      

      does allow this. Quite a few service providers may prefer to
      control

      all these E-Tree connectivity by themselves.

    
    When E-Tree signaling
      protocol for PWid FEC is considered,
    the following 
      options are also
    feasible:=


    

    a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
        Disable Optimized mode for FEC PWid(0x80), thus
      root/leaf role 

      change in the E-Tree topology will not have any influence on the
      PW.

    

    b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
        Add another appendix into the document for the full
      support of 

      Optimized mode with FEC PWid(0x80).

    

    The idea is: the PE
      sends a label mapping firstly and then send a label 

      request to its peer PEs (so that they will reply with a label
      mapping 

      respectively).

    
    Since Optimized mode
      is an optional piece in the document, I would 

      regard option a) as a simple tradeoff (as I am aware, E-VPN does
      not 

      support Optimized mode for E-Tree either.

      

      =3D=3D=3D=3D=3D=3D=3D=3D

      

      

      Thus we have three proposals on the table:

      

      1) Leave the design as it is, but add text to describe the
      constraint and

      what happens if you have to change mode and what to do about it.

      

      2) Exclude optimization in the FEC PWid(0=
x80) case

        

        3) Add an appendix describing support for the FEC
            PWid(0x80) case.

            

          My inclination would be to go with option
      (1) but I seek the views of

      the WG, and of course any corrections in my analysis.

      

      - Stewart

_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals


--001a11c2660afd3b630521493f2d-- From nobody Sun Oct 4 11:20:38 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73601B2DC9 for ; Sun, 4 Oct 2015 11:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPP_HtMh3gQd for ; Sun, 4 Oct 2015 11:20:30 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBD11B2CCD for ; Sun, 4 Oct 2015 11:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28761; q=dns/txt; s=iport; t=1443982798; x=1445192398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vYqz865aiHdd1j4K6gcqbQOok6bfJ4mAC+/fRnwiS90=; b=HXMhzonGJXjvCLKBnt6jtYO2E002JMwWgJgt76NKdDokAUxjCOiJfs50 ZIoXAZHuPMGfjF/Q5zqXQN9iFuRul1+yYZ/S0uHUWd2THiYj+ycqrtrX7 s0Xwx7tDtQsLAi1sAZGU9D/u2sgB2sWhOqh5gZiUqm/M/OVvpz+KaWbOw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIAgAebRFW/4QNJK1eglpNVG6+CQENgVoXAQmFeQKBGjgUAQEBAQEBAYEKhCQBAQEEAQEBawsQAgEIDgMDAQIhBwchBgsUCQgCBA4FG4d+AxINwi4NhQwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzghCCboJQgVoRAUAMAQQHBoMSgRQFhzeLEoMzAYgFgx6Bc5Qah0kfAQFCghEFGIFUcYs/BgMXgSkBAQE X-IronPort-AV: E=Sophos; i="5.17,634,1437436800"; d="scan'208,217"; a="34470508" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 04 Oct 2015 18:19:57 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t94IJvME004589 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 4 Oct 2015 18:19:57 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 4 Oct 2015 13:19:56 -0500 Received: from xhc-rcd-x11.cisco.com (173.37.183.85) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sun, 4 Oct 2015 13:19:56 -0500 Received: from xmb-rcd-x04.cisco.com ([169.254.8.230]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0248.002; Sun, 4 Oct 2015 13:19:56 -0500 From: "Stewart Bryant (stbryant)" To: Lizhong Jin Thread-Topic: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward Thread-Index: AQHQ/rtcsgJiXHG75kmyAL2X9A1jGp5bpROI Date: Sun, 4 Oct 2015 18:19:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C82D9E6A790C4CAD82B9CCFFE2B66A9Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: "pals@ietf.org" , "pals-chairs@tools.ietf.org" , "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 18:20:35 -0000 --_000_C82D9E6A790C4CAD82B9CCFFE2B66A9Cciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 4 Oct 2015, at 16:43, Lizhong Jin > wrote: Hi Stewart, Thanks for the comment. This is a long email. You give us three options: 1) Leave the design as it is, but add text to describe the constraint and what happens if you have to change mode and what to do about it. 2) Exclude optimization in the FEC PWid(0x80) case 3) Add an appendix describing support for the FEC PWid(0x80) case. Then I prefer option 1. Because option2 is not reasonable, and the solutio= n in option3 provided by the author is not the best one. I would like to provide opition4 for WG to consider: 4) Add description to support for the FEC PWid(0x80) case, in appendix or t= ext I don't care. The solution is: label release message should not be sent in section 6.1. For PW signaling, the unacceptable of any Interface Parameter will not lead= to any label release, but just simply let the PW down in forwarding plane. Listing Doesn't that waste labels, which may be a problem in some systems, and crea= te a vulnerability since someone may send a packet with that label which wo= uld be processed and sent out of the person egress. -Stewart Regards Lizhong ---------- Forwarded message ---------- From: Stewart Bryant > To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" >, "pals@ietf.org" > Cc: "pals-chairs@tools.ietf.org" > Date: Fri, 2 Oct 2015 16:41:05 +0100 Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward I am sorry that this is a long email, but I wanted to collect the facts together in one place and set out the complete scene to the PALS WG. The critical concern is contained in the following email fragment from Lizhong: =3D=3D=3D=3D=3D=3D=3D In RFC4447 and 4447bis, it clearly said: Using the PWid FEC, each of the two pseudowire endpoints independently initiates the setup of a unidirectional LSP. An outgoing LSP and an incoming LSP are bound together into a single pseudowire if they have the same PW ID and PW type. The behavior is a correct description for LDP-DU mode which PW applies. And that is also the behavior most vendors implement. Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says: A PE that receives a PW label mapping message with an E-Tree Sub-TLV from its peer PE, after saving the VLAN information for the PW, MUST process it as follows: ..... 3) If the P bit is set { If the PE is a leaf-only node itself, a label release message with a status code "Leaf to Leaf PW released" is sent to the peer PE and exit the process; Else the PE SHOULD set the Optimized-Mode to TRUE. } That means, if PE1 receiving a label mapping from PE2 with P bit set, PE1 will send label release. Then PE2 will never send label mapping again to PE1 even when PE1 changes from leaf-only node to root-leaf node. F= or LDP-DU mode, PE2 will not send label mapping again when receiving PE1's label mapp= ing. Then the PW will not be setup successfully. Then only way is to configure t= he same PW on PE2 again. The correct behavior is, label release message should not be sent. For PW signaling, the unacceptable of any Interface Parameter will not lead= to any label release, but just simply let the PW down in forwarding plane. =3D=3D=3D=3D=3D=3D=3D=3D Andy looked at this from the point of view of the MEF and notes in private conversation: =3D=3D=3D=3D=3D=3D=3D=3D=3D In the E-tree service as defined by MEF, you can have one or more roots and one or more leafs. In a single E-tree service (think of a multipoint PW with some of the CEs configured as roots as some as leafs), all leafs and roots receive frames sent by the roots. All roots receive frames sent by the leafs. However, leafs may not receive any frames sent by other leafs. The draft, as written, doesn't bring up an underlying pt-to-pt PWs to carry frames for the service between PEs that only have leafs attached. Since the leafs can't sent frames to each other, that is an economical use of PWs in the network. Lizhong's point is that this makes it impossible to add a new root to an existing PE in an E-tree that previously only had leafs. I agree that would be a problem if there was a requirement to modify an existing E-tree service. However, this draft has no other mechanisms to explicitly support E-tree modification, nor is such modification a requirement of the underlying MEF specification. BTW, since this work was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet Services Definitions Phase 3", August, 2014, and that reference should be updated in the draft. My opinion is that the draft as it stands is technically correct if you don't need the ability to reconfigure an existing E-tree service dynamicall= y. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Now whilst I can support the idea that dynamic reconfiguration of E-tree is not needed, I have a concern. My understanding the text in question is that it is saying that if A is configured as leaf only, and B which is also configured as leaf only attempts to configure a PW between them, then A rejects the PW setup. That sounds very reasonable to me, since there is a misconfig. If A did not do the reject, then B would forever be consuming resource waiting for A and B would have no idea of the misconfig. That accords with Andy's view above. However I was worried what would happen if A was misconfigured as leaf only and the configuration was corrected to root-leaf. What would in my view be difficult to accept was the need to take a human, or NMS action at B to recover the situation. However provided that A closed the LDP session with B and re-instate it B would then send the mapping message again. Thus the system is recoverable without needing to visit B which is in my mind a fundamental requirement since A could have got into the wrong mode as a result of an error. The problem I see is if A has a bunch of other PWs with B they will get torn down in order for A to have the config error fixed. However if that is a problem you need two LDP sessions between A and B, one for L2VPN and one for regular PWs. My inclination is that the draft is basically correct, and that whilst Lizhong is correct that the PW will not come up without some action, reconfiguring the PW on B is not the only action that will cause the PW to come up. So this comes down to a WG decision in terms of which is the least unacceptable behaviour - A having to re-cycle the LDP session, or B wasting resources. I think I prefer the behaviour proposed in the draft. A way forward is to leave the logic as written in the draft, but to add text describing the basis for excluding dynamic re-configuration as a normal operational mode and to note the actions that need to be taken when re-configuration is forced for some reason. Whilst we were pondering what do with the text the chairs and AD received another proposal from the authors: =3D=3D=3D=3D=3D=3D In general, FEC PWid(0x80) is used in VPLS with manual provisioning, while Generalized PWid (0x81) is used with auto-discovery. As discussed in Section 5.2, VLAN mapping parameters can be provisioned without a signaling protocol, Optimized Mode can also be a parameter to be provisioned. The approach we=92ve taken in the current draft-ietf-l2vpn-vpls-pe-etree-09 does allow this. Quite a few service providers may prefer to control all these E-Tree connectivity by themselves. When E-Tree signaling protocol for PWid FEC is considered, the following options are also feasible: a) Disable Optimized mode for FEC PWid(0x80), thus root/leaf role change in the E-Tree topology will not have any influence on the PW. b) Add another appendix into the document for the full support of Optimized mode with FEC PWid(0x80). The idea is: the PE sends a label mapping firstly and then send a label request to its peer PEs (so that they will reply with a label mapping respectively). Since Optimized mode is an optional piece in the document, I would regard option a) as a simple tradeoff (as I am aware, E-VPN does not support Optimized mode for E-Tree either. =3D=3D=3D=3D=3D=3D=3D=3D Thus we have three proposals on the table: 1) Leave the design as it is, but add text to describe the constraint and what happens if you have to change mode and what to do about it. 2) Exclude optimization in the FEC PWid(0x80) case 3) Add an appendix describing support for the FEC PWid(0x80) case. My inclination would be to go with option (1) but I seek the views of the WG, and of course any corrections in my analysis. - Stewart _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals --_000_C82D9E6A790C4CAD82B9CCFFE2B66A9Cciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable




On 4 Oct 2015, at 16:43, Lizhong Jin <lizho.jin@gmail.com> wrote:

Hi Stewart,
Thanks for the comment. This is a long email.
You give us three options:

1) Leave the design as it is, but add text to describe the constraint and what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x= 80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

 Then I prefer option 1. Because option2 is not reasonable, and t= he solution in option3 provided by the author is not the best one.

I would like to provide opition4 for WG to consider:
4) Add description to support for the <= /span>FEC PWid(0x80) case, in appendix or text I don't care. The solution is:=
<= span lang=3D"EN-US" style=3D"font-size:10.5pt"> 
label release message should not be sent in se=
ction 6.1.
For PW signaling, the unacceptable of any Inte=
rface Parameter will not lead to any 
label release, but just simply let the PW down=
 in forwarding plane.
Listing

Doesn't that waste labels, which may be a problem in some systems, and= create a vulnerability since someone may send a packet with that label whi= ch would be processed and sent out of the person egress.

-Stewart

Regards
Lizhong



---------- Forwarded message ----------
From: Stewart Bryant <stbryan= t@cisco.com>
To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" <draft-ietf-l2vpn-vpl= s-pe-etree@tools.ietf.org>, "p= als@ietf.org" <pals@ietf.org>
Cc: "pals-chairs@to= ols.ietf.org" <pa= ls-chairs@tools.ietf.org>
Date: Fri, 2 Oct 2015 16:41:05 +0100
Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward=
I am sorry that this is a long em= ail, but I wanted to collect the
facts together in one place and set out the complete scene to
the PALS WG.

The critical concern is contained in the following email fragment
from Lizhong:

=3D=3D=3D=3D=3D=3D=3D

In RFC4447 and 4447= bis, it clearly said:

=
Using the PWid FEC, each of the two pseudowire endpoints
=
   independently initiates the setup of a unidirectional LSP.&nbs=
p;  An
=
   outgoing LSP and an incoming LSP are bound together into a sin=
gle
=
   pseudowire if they have the same PW ID  and PW type.
=
The behavior is a correct description for LDP-DU mode which PW applies.
=
And that is also the behavior most vendors implement.
=
 
=
Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:
=
 A PE that receives a PW label mapping message with an E-Tree Sub-TLV
=
   from its peer PE, after saving the VLAN information for the PW=
, MUST
=
   process it as follows:
=
.....
=
3) If the P bit is set
=
 
=
      {
=
 
=
          If the PE is a leaf-=
only node itself, a label release message
=
      with a status code "Leaf to Leaf PW rel=
eased" is sent to the peer
=
      PE and exit the process;
=
 
=
          Else the PE SHOULD s=
et the Optimized-Mode to TRUE.
=
 
=
      }
=
That means, if PE1 receiving a label mapping from PE2 with P bit set, 
=
PE1 will send label release. Then PE2 will never send label mapping<=
/pre>

=
again to PE1 even when PE1 changes from leaf-only node to root-leaf nod=
e. For LDP-DU

mode, PE2 will not send label mapping again wh=
en receiving PE1's label mapping.


Then the PW will not be setup successfully. Th=
en only way is to configure the 


same PW on PE2 again.


The correct behavior is, label release message=
 should not be sent.


For PW signaling, the unacceptable of any Inte=
rface Parameter will not lead to any 


label release, but just simply let the PW down=
 in forwarding plane.


=
 

=3D=3D=3D=3D=3D=3D=3D=3D



Andy looked at this from the point of view of the MEF and notes in

private conversation:




=3D=3D=3D=3D=3D=3D=3D=3D=3D




In the E-tree service as defined by MEF, you can have one or more root=
s 

and one or more leafs.







In a single E-tree service (think of a multipoint PW with some of the =
CEs 

configured as roots as some as leafs), all leafs and roots receive frames <=
br>
sent by the roots. All roots receive frames sent by the leafs. However, 
leafs may not receive any frames sent by other leafs.







The draft, as written, doesn't bring up an underlying pt-to-pt PWs to =


carry frames for the service between PEs that only have leafs attached. 
Since the leafs can't sent frames to each other, that is an economical 

use of PWs in the network.







Lizhong's point is that this makes it impossible to add a new root to =


an existing PE in an E-tree that previously only had leafs.







I agree that would be a problem if there was a requirement to modify <=
br>
an existing E-tree service. However, this draft has no other mechanisms 
to explicitly support E-tree modification, nor is such modification a 

requirement of the underlying MEF specification. BTW, since this work 

was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet 

Services Definitions Phase 3", August, 2014, and that reference should=
 

be updated in the draft.





My opinion is that the draft as it stands is technically correct if you 
don't need the ability to reconfigure an existing E-tree service dynamicall=
y.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



Now whilst I can support the idea that dynamic reconfiguration of

E-tree is not needed, I have a concern.



My understanding the text in question is that it is saying that if 

A is configured as leaf only, and B which is also configured as

leaf only attempts to configure a PW between them, then A rejects 

the PW setup.



That sounds very reasonable to me, since there is a misconfig.



If A did not do the reject, then B would forever be consuming

resource waiting for A and B would have no idea of the

misconfig. That accords with Andy's view above.



However I was worried what would happen if A was misconfigured

as leaf only and the configuration was corrected to root-leaf.

What would in my view be difficult to accept was the need to

take a human, or NMS action at B to recover the situation.

However provided that A closed the LDP session with B 

and re-instate it B would then send the mapping message again.

Thus the system is recoverable without needing to visit B which

is in my mind a fundamental requirement since A could have

got into the wrong mode as a result of an error.



The problem I see is if A has a bunch of other PWs with B

they will get torn down in order for A to have the config error

fixed. However if that is a problem you need two LDP sessions

between A and B, one for L2VPN and one for regular PWs.



My inclination is that the draft is basically correct, and that whilst

Lizhong is correct that the PW will not come up without some

action, reconfiguring the PW on B is not the only action

that will cause the PW to come up. 



So this comes down to a WG decision in terms of which is the

least unacceptable behaviour - A having to re-cycle the LDP

session, or B wasting resources. I think I prefer the behaviour

proposed in the draft.



A way forward is to leave the logic as written in the draft, but to 

add text describing the basis for excluding dynamic re-configuration

as a normal operational mode and to note the actions that need 

to be taken when re-configuration is forced for some reason.



Whilst we were pondering what do with the text the chairs

and AD received another proposal from the authors:



=3D=3D=3D=3D=3D=3D



In general, FEC PWid(0x80) =
is used in VPLS with manual provisioning,


while Generalized PW=
id (0x81) is used with auto-discovery.



As discussed in Section 5.2=
, VLAN mapping parameters can be provisioned


without a signaling protocol, Optimized Mode can also be a parameter 

to be provisioned.



The approach we=92ve taken =
in the current
draft-ietf-l2vpn-vpl=
s-pe-etree-09


does allow this. Quite a few service providers may prefer to control

all these E-Tree connectivity by themselves.



When E-Tree signaling proto=
col for PWid FEC is considered,
the following 

options are also fea=
sible:



a)      
Disabl=
e Optimized mode for FEC PWid(0x80), thus root/leaf role


change in the E-Tree topology will not have any influence on the PW.=




b)      
Add an=
other appendix into the document for the full support of


Optimized mode with FEC PWid(0x80).



The idea is: the PE sends a=
 label mapping firstly and then send a label


request to its peer PEs (so that they will reply with a label mapping 

respectively).



Since Optimized mode is an =
optional piece in the document, I would


regard option a) as a simple tradeoff (as I am aware, E-VPN does not 

support Optimized mode for E-Tree either.



=3D=3D=3D=3D=3D=3D=3D=3D





Thus we have three proposals on the table:



1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.



2) Exclude optimization in the FEC PWid(0x80) c=
ase



3) Add an appendix describing support for the FEC PWid(0x80) case.



My inclination would be to go with option (1) but I se=
ek the views of

the WG, and of course any corrections in my analysis.



- Stewart

_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals


--_000_C82D9E6A790C4CAD82B9CCFFE2B66A9Cciscocom_-- From nobody Sun Oct 4 22:04:44 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610BF1B4446 for ; Sun, 4 Oct 2015 22:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyc1_nIvi4ss for ; Sun, 4 Oct 2015 22:04:39 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE0F1A8A55 for ; Sun, 4 Oct 2015 22:04:38 -0700 (PDT) Received: by wicge5 with SMTP id ge5so102876476wic.0 for ; Sun, 04 Oct 2015 22:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rPNbLaNTaYNV/538d4YTY6JmxttFQW7G4sdQze4HRLA=; b=loTKYL++u33Z8egtqn7bqFzQK0v1scoDEy51Ur09EoN2lCs035I/MkNAfStoSqKNOo wy7DWm0bxi1GVz+5IfHz4LJsMcKPq0627cju8b/6fLk42rzLFF6dDFu2AB860Rcq44XX cVsgNOz3u67/EoyDIloPRB5yvA6c040y76BdTW84uEno/PHwyMmswHZ4fjpGgjQ9bAhL /hV2jJfiP5yCAXxX26/+BrZL0Zy7yXgj360ctdCUr1VOsj4XgWTuzj0hwA3VzXfd9eXU IUQaK7NUFIY/qBU6sY//f4YtJGG39ElLkx9kmEyNnNCuef+gqvqxHSczn/S5cBQSMfCj n52w== MIME-Version: 1.0 X-Received: by 10.194.104.137 with SMTP id ge9mr27455676wjb.57.1444021477368; Sun, 04 Oct 2015 22:04:37 -0700 (PDT) Received: by 10.194.236.164 with HTTP; Sun, 4 Oct 2015 22:04:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Oct 2015 13:04:37 +0800 Message-ID: From: Lizhong Jin To: "Stewart Bryant (stbryant)" Content-Type: multipart/alternative; boundary=089e010d838834ecc4052154739e Archived-At: Cc: "pals@ietf.org" , "pals-chairs@tools.ietf.org" , "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 05:04:43 -0000 --089e010d838834ecc4052154739e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stewart, For DU mode, if FEC is created, then label should be allocated. For the vulnerability you mentioned, if I understand your question correctly, the PW label will not be programmed into hardware, but only kept in control plane. So the packet will not be wrongly processed. The MTU interface Sub-TLV defined in RFC4447 section 6.4 said: If this parameter does not match in both directions of a specific PW, that PW MUST NOT be enabled. The mechanism I proposed is what have been done for MTU interface sub-TLV. Regards Lizhong On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) < stbryant@cisco.com> wrote: > > > > > On 4 Oct 2015, at 16:43, Lizhong Jin wrote: > > Hi Stewart, > Thanks for the comment. This is a long email. > You give us three options: > > 1) Leave the design as it is, but add text to describe the constraint and > what happens if you have to change mode and what to do about it. > > 2) Exclude optimization in the FEC PWid(0x80) case > > 3) Add an appendix describing support for the FEC PWid(0x80) case. > > Then I prefer option 1. Because option2 is not reasonable, and the > solution in option3 provided by the author is not the best one. > > I would like to provide opition4 for WG to consider: > 4) Add description to support for the FEC PWid(0x80) case, in appendix or > text I don't care. The solution is: > > label release message should not be sent in section 6.1. > > For PW signaling, the unacceptable of any Interface Parameter will not le= ad to any > > label release, but just simply let the PW down in forwarding plane. > > Listing > > Doesn't that waste labels, which may be a problem in some systems, and > create a vulnerability since someone may send a packet with that label > which would be processed and sent out of the person egress. > > -Stewart > > Regards > Lizhong > > > >> ---------- Forwarded message ---------- >> From: Stewart Bryant >> To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" < >> draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org>, "pals@ietf.org" < >> pals@ietf.org> >> Cc: "pals-chairs@tools.ietf.org" >> Date: Fri, 2 Oct 2015 16:41:05 +0100 >> Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward >> I am sorry that this is a long email, but I wanted to collect the >> facts together in one place and set out the complete scene to >> the PALS WG. >> >> The critical concern is contained in the following email fragment >> from Lizhong: >> >> =3D=3D=3D=3D=3D=3D=3D >> >> In RFC4447 and 4447bis, it clearly said: >> >> Using the PWid FEC, each of the two pseudowire endpoints >> >> independently initiates the setup of a unidirectional LSP. An >> >> outgoing LSP and an incoming LSP are bound together into a single >> >> pseudowire if they have the same PW ID and PW type. >> >> The behavior is a correct description for LDP-DU mode which PW applies. >> >> And that is also the behavior most vendors implement. >> >> >> >> Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says: >> >> A PE that receives a PW label mapping message with an E-Tree Sub-TLV >> >> from its peer PE, after saving the VLAN information for the PW, MUST >> >> process it as follows: >> >> ..... >> >> 3) If the P bit is set >> >> >> >> { >> >> >> >> If the PE is a leaf-only node itself, a label release message >> >> with a status code "Leaf to Leaf PW released" is sent to the peer >> >> PE and exit the process; >> >> >> >> Else the PE SHOULD set the Optimized-Mode to TRUE. >> >> >> >> } >> >> That means, if PE1 receiving a label mapping from PE2 with P bit set, >> >> PE1 will send label release. Then PE2 will never send label mapping >> >> again to PE1 even when PE1 changes from leaf-only node to root-leaf node= . For LDP-DU >> >> mode, PE2 will not send label mapping again when receiving PE1's label m= apping. >> >> Then the PW will not be setup successfully. Then only way is to configur= e the >> >> same PW on PE2 again. >> >> The correct behavior is, label release message should not be sent. >> >> For PW signaling, the unacceptable of any Interface Parameter will not l= ead to any >> >> label release, but just simply let the PW down in forwarding plane. >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D >> >> Andy looked at this from the point of view of the MEF and notes in >> private conversation: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> In the E-tree service as defined by MEF, you can have one or more roots >> and one or more leafs. >> >> In a single E-tree service (think of a multipoint PW with some of the CE= s >> configured as roots as some as leafs), all leafs and roots receive frame= s >> sent by the roots. All roots receive frames sent by the leafs. However, >> leafs may not receive any frames sent by other leafs. >> >> The draft, as written, doesn't bring up an underlying pt-to-pt PWs to >> carry frames for the service between PEs that only have leafs attached. >> Since the leafs can't sent frames to each other, that is an economical >> use of PWs in the network. >> >> Lizhong's point is that this makes it impossible to add a new root to >> an existing PE in an E-tree that previously only had leafs. >> >> I agree that would be a problem if there was a requirement to modify >> an existing E-tree service. However, this draft has no other mechanisms >> to explicitly support E-tree modification, nor is such modification a >> requirement of the underlying MEF specification. BTW, since this work >> was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet >> Services Definitions Phase 3", August, 2014, and that reference should >> be updated in the draft. >> >> My opinion is that the draft as it stands is technically correct if you >> don't need the ability to reconfigure an existing E-tree service >> dynamically. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Now whilst I can support the idea that dynamic reconfiguration of >> E-tree is not needed, I have a concern. >> >> My understanding the text in question is that it is saying that if >> A is configured as leaf only, and B which is also configured as >> leaf only attempts to configure a PW between them, then A rejects >> the PW setup. >> >> That sounds very reasonable to me, since there is a misconfig. >> >> If A did not do the reject, then B would forever be consuming >> resource waiting for A and B would have no idea of the >> misconfig. That accords with Andy's view above. >> >> However I was worried what would happen if A was misconfigured >> as leaf only and the configuration was corrected to root-leaf. >> What would in my view be difficult to accept was the need to >> take a human, or NMS action at B to recover the situation. >> However provided that A closed the LDP session with B >> and re-instate it B would then send the mapping message again. >> Thus the system is recoverable without needing to visit B which >> is in my mind a fundamental requirement since A could have >> got into the wrong mode as a result of an error. >> >> The problem I see is if A has a bunch of other PWs with B >> they will get torn down in order for A to have the config error >> fixed. However if that is a problem you need two LDP sessions >> between A and B, one for L2VPN and one for regular PWs. >> >> My inclination is that the draft is basically correct, and that whilst >> Lizhong is correct that the PW will not come up without some >> action, reconfiguring the PW on B is not the only action >> that will cause the PW to come up. >> >> So this comes down to a WG decision in terms of which is the >> least unacceptable behaviour - A having to re-cycle the LDP >> session, or B wasting resources. I think I prefer the behaviour >> proposed in the draft. >> >> A way forward is to leave the logic as written in the draft, but to >> add text describing the basis for excluding dynamic re-configuration >> as a normal operational mode and to note the actions that need >> to be taken when re-configuration is forced for some reason. >> >> Whilst we were pondering what do with the text the chairs >> and AD received another proposal from the authors: >> >> =3D=3D=3D=3D=3D=3D >> >> In general, FEC PWid(0x80) is used in VPLS with manual provisioning, >> while Generalized PWid (0x81) is used with auto-discovery. >> >> As discussed in Section 5.2, VLAN mapping parameters can be provisioned >> without a signaling protocol, Optimized Mode can also be a parameter >> to be provisioned. >> >> The approach we=E2=80=99ve taken in the current draft-ietf-l2vpn-vpls-pe= -etree-09 >> >> does allow this. Quite a few service providers may prefer to control >> all these E-Tree connectivity by themselves. >> >> When E-Tree signaling protocol for PWid FEC is considered, the following >> options are also feasible: >> >> a) Disable Optimized mode for FEC PWid(0x80), thus root/leaf role >> change in the E-Tree topology will not have any influence on the PW. >> >> b) Add another appendix into the document for the full support of >> Optimized mode with FEC PWid(0x80). >> >> The idea is: the PE sends a label mapping firstly and then send a label >> request to its peer PEs (so that they will reply with a label mapping >> respectively). >> >> Since Optimized mode is an optional piece in the document, I would >> regard option a) as a simple tradeoff (as I am aware, E-VPN does not >> support Optimized mode for E-Tree either. >> >> =3D=3D=3D=3D=3D=3D=3D=3D >> >> >> Thus we have three proposals on the table: >> >> 1) Leave the design as it is, but add text to describe the constraint an= d >> what happens if you have to change mode and what to do about it. >> >> 2) Exclude optimization in the FEC PWid(0x80) case >> >> 3) Add an appendix describing support for the FEC PWid(0x80) case. >> >> My inclination would be to go with option (1) but I seek the views of >> the WG, and of course any corrections in my analysis. >> >> - Stewart >> >> >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals >> >> > --089e010d838834ecc4052154739e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stewart,
For DU mode, if FEC is created, then label= should be allocated. For the vulnerability you mentioned, if I understand = your question correctly, the PW label will not be programmed into hardware,= but only kept in control plane. So the packet will not be wrongly processe= d.
The MTU interface Sub-TLV defined in RFC4447 section 6.4 said:= 
If this parameter does not match
       in both directions of a specific PW, that PW MUST NOT be enabled.
The mechanism I proposed is what have been done for MTU interface s=
ub-TLV.

Regards
Lizhong

On Mon, Oct 5, 2015 at 2:19 AM=
, Stewart Bryant (stbryant) <stbryant@cisco.com> wrote:
=






















On 4 Oct 2015, at 16:43, Lizhong Jin <lizho.jin@gmail.com> wrote:
















Hi Stewart,


Thanks for the comment. This is a long email.


You give us three options:




1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.



2) Exclude optimization in the=C2=A0FEC PWid(0x=
80) case



3) Add an appendix describing support for the=C2=A0FEC PWid(0x80) case.









=C2=A0Then I prefer option 1. Because option2 is not reasonable, and t=
he solution in option3 provided by the author is not the best one.







I would like to provide opition4 for WG to consider:


4)=C2=A0Add description to support for the=C2=A0<=
/span>FEC
 PWid(0x80) case, in appendix or text I don't care. The solution is:


<=
span lang=3D"EN-US" style=3D"font-size:10.5pt">

label release message should not be sent in se=
ction 6.1.


For PW signaling, the unacceptable of any Inte=
rface Parameter will not lead to any 


label release, but just simply let the PW down=
 in forwarding plane.














Listing







Doesn't that waste labels, which may be a problem in some systems,=
 and create a vulnerability since someone may send a packet with that label=
 which would be processed and sent out of the person egress.







-Stewart














Regards


Lizhong















---------- Forwarded message ----------

From:=C2=A0Stewart Bryant <stbryant@cisco.com>

To:=C2=A0"draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org&qu=
ot; <draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org>, &quo=
t;pals@ietf.org"=
;
 <pals@ietf.org&g=
t;

Cc:=C2=A0"pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>

Date:=C2=A0Fri, 2 Oct 2015 16:41:05 +0100

Subject:=C2=A0[Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward=



I am sorry that this is a long em=
ail, but I wanted to collect the


facts together in one place and set out the complete scene to 

the PALS WG.



The critical concern is contained in the following email fragment

from Lizhong:



=3D=3D=3D=3D=3D=3D=3D




In RFC4447 and 4447=
bis, it clearly said:




=
Using the PWid FEC, each of the two pseudowire endpoints


=
=C2=A0=C2=A0 independently initiates the setup of a unidirectional LSP.=C2=
=A0=C2=A0 An


=
=C2=A0=C2=A0 outgoing LSP and an incoming LSP are bound together into a sin=
gle


=
=C2=A0=C2=A0 pseudowire if they have the same PW ID =C2=A0and PW type.


=
The behavior is a correct description for LDP-DU mode which PW applies.


=
And that is also the behavior most vendors implement.


=
=C2=A0


=
Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:


=
 A PE that receives a PW label mapping message with an E-Tree Sub-TLV


=
=C2=A0=C2=A0 from its peer PE, after saving the VLAN information for the PW=
, MUST


=
=C2=A0=C2=A0 process it as follows:


=
.....


=
3) If the P bit is set


=
=C2=A0


=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {


=
=C2=A0


=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the PE is a leaf-=
only node itself, a label release message


=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with a status code "Leaf to Leaf PW rel=
eased" is sent to the peer


=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PE and exit the process;


=
=C2=A0


=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Else the PE SHOULD s=
et the Optimized-Mode to TRUE.


=
=C2=A0


=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }


=
That means, if PE1 receiving a label mapping from PE2 with P bit set, 


=
PE1 will send label release. Then PE2 will never send label mapping<=
/pre>

=
again to PE1 even when PE1 changes from leaf-only node to root-leaf nod=
e. For LDP-DU

mode, PE2 will not send label mapping again wh=
en receiving PE1's label mapping.


Then the PW will not be setup successfully. Th=
en only way is to configure the 


same PW on PE2 again.


The correct behavior is, label release message=
 should not be sent.


For PW signaling, the unacceptable of any Inte=
rface Parameter will not lead to any 


label release, but just simply let the PW down=
 in forwarding plane.


=
=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D



Andy looked at this from the point of view of the MEF and notes in

private conversation:




=3D=3D=3D=3D=3D=3D=3D=3D=3D




In the E-tree service as defined by MEF, you can have one or more root=
s 

and one or more leafs.







In a single E-tree service (think of a multipoint PW with some of the =
CEs 

configured as roots as some as leafs), all leafs and roots receive frames <=
br>
sent by the roots. All roots receive frames sent by the leafs. However, 
leafs may not receive any frames sent by other leafs.







The draft, as written, doesn't bring up an underlying pt-to-pt PWs=
 to 

carry frames for the service between PEs that only have leafs attached. 
Since the leafs can't sent frames to each other, that is an economical =


use of PWs in the network.







Lizhong's point is that this makes it impossible to add a new root=
 to 

an existing PE in an E-tree that previously only had leafs.







I agree that would be a problem if there was a requirement to modify <=
br>
an existing E-tree service. However, this draft has no other mechanisms 
to explicitly support E-tree modification, nor is such modification a 

requirement of the underlying MEF specification. BTW, since this work 

was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet 

Services Definitions Phase 3", August, 2014, and that reference should=
 

be updated in the draft.





My opinion is that the draft as it stands is technically correct if you 
don't need the ability to reconfigure an existing E-tree service dynami=
cally.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



Now whilst I can support the idea that dynamic reconfiguration of

E-tree is not needed, I have a concern.



My understanding the text in question is that it is saying that if 

A is configured as leaf only, and B which is also configured as

leaf only attempts to configure a PW between them, then A rejects 

the PW setup.



That sounds very reasonable to me, since there is a misconfig.



If A did not do the reject, then B would forever be consuming

resource waiting for A and B would have no idea of the

misconfig. That accords with Andy's view above.



However I was worried what would happen if A was misconfigured

as leaf only and the configuration was corrected to root-leaf.

What would in my view be difficult to accept was the need to

take a human, or NMS action at B to recover the situation.

However provided that A closed the LDP session with B 

and re-instate it B would then send the mapping message again.

Thus the system is recoverable without needing to visit B which

is in my mind a fundamental requirement since A could have

got into the wrong mode as a result of an error.



The problem I see is if A has a bunch of other PWs with B

they will get torn down in order for A to have the config error

fixed. However if that is a problem you need two LDP sessions

between A and B, one for L2VPN and one for regular PWs.



My inclination is that the draft is basically correct, and that whilst

Lizhong is correct that the PW will not come up without some

action, reconfiguring the PW on B is not the only action

that will cause the PW to come up. 



So this comes down to a WG decision in terms of which is the

least unacceptable behaviour - A having to re-cycle the LDP

session, or B wasting resources. I think I prefer the behaviour

proposed in the draft.



A way forward is to leave the logic as written in the draft, but to 

add text describing the basis for excluding dynamic re-configuration

as a normal operational mode and to note the actions that need 

to be taken when re-configuration is forced for some reason.



Whilst we were pondering what do with the text the chairs

and AD received another proposal from the authors:



=3D=3D=3D=3D=3D=3D



In general, FEC PWid(0x80) =
is used in VPLS with manual provisioning,


while Generalized PW=
id (0x81) is used with auto-discovery.



As discussed in Section 5.2=
, VLAN mapping parameters can be provisioned


without a signaling protocol, Optimized Mode can also be a parameter 

to be provisioned.



The approach we=E2=80=99ve =
taken in the current
draft-ietf-l2vpn-vpl=
s-pe-etree-09


does allow this. Quite a few service providers may prefer to control

all these E-Tree connectivity by themselves.



When E-Tree signaling proto=
col for PWid FEC is considered,
the following 

options are also fea=
sible:



a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Disabl=
e Optimized mode for FEC PWid(0x80), thus root/leaf role


change in the E-Tree topology will not have any influence on the PW.=




b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Add an=
other appendix into the document for the full support of


Optimized mode with FEC PWid(0x80).



The idea is: the PE sends a=
 label mapping firstly and then send a label


request to its peer PEs (so that they will reply with a label mapping 

respectively).



Since Optimized mode is an =
optional piece in the document, I would


regard option a) as a simple tradeoff (as I am aware, E-VPN does not 

support Optimized mode for E-Tree either.



=3D=3D=3D=3D=3D=3D=3D=3D





Thus we have three proposals on the table:



1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.



2) Exclude optimization in the FEC PWid(0x80) c=
ase



3) Add an appendix describing support for the FEC PWid(0x80) case.



My inclination would be to go with option (1) but I se=
ek the views of

the WG, and of course any corrections in my analysis.



- Stewart







_______________________________________________

Pals mailing list

Pals@ietf.org

https://www.ietf.org/mailman/listinfo/pals

--089e010d838834ecc4052154739e-- From nobody Mon Oct 5 07:16:11 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF1B1ACE1C; Mon, 5 Oct 2015 07:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLfPEZkL3VpI; Mon, 5 Oct 2015 07:16:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F341ACE20; Mon, 5 Oct 2015 07:16:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151005141609.26904.27411.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 07:16:09 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-mac-wd-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 14:16:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : MAC Address Withdrawal over Static Pseudowire Authors : Siva Sivabalan Sami Boutros Himanshu Shah Sam Aldrin Mannan Venkatesan Filename : draft-ietf-pals-mpls-tp-mac-wd-02.txt Pages : 10 Date : 2015-10-05 Abstract: This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-mac-wd-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-mac-wd-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 5 10:13:55 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585A01B29DB; Mon, 5 Oct 2015 10:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLGpjlKiujRA; Mon, 5 Oct 2015 10:13:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4AC1AD0C6; Mon, 5 Oct 2015 10:13:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151005171351.7394.69802.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 10:13:51 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] Last Call: (MAC Address Withdrawal over Static Pseudowire) to Proposed Standard X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 17:13:52 -0000 The IESG has received a request from the Pseudowire And LDP-enabled Services WG (pals) to consider the following document: - 'MAC Address Withdrawal over Static Pseudowire' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Oct 5 10:36:11 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C93B1B2A58; Mon, 5 Oct 2015 10:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaYXE81FW_YK; Mon, 5 Oct 2015 10:36:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 510D71B2A51; Mon, 5 Oct 2015 10:36:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151005173608.24293.79256.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 10:36:08 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-congcons-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 17:36:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : Pseudowire Congestion Considerations Authors : Yaakov (Jonathan) Stein David L. Black Bob Briscoe Filename : draft-ietf-pals-congcons-01.txt Pages : 24 Date : 2015-10-04 Abstract: Pseudowires (PWs) have become a common mechanism for tunneling traffic, and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. It is thus worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as TDM PWs) we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater than this bound, and typically much lower. Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. We propose employing a transport circuit breaker to shut down a TDM PW that persistently fails to comply with acceptable TDM service criteria. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-congcons/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-congcons-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-congcons-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 5 12:41:43 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28041B4F51; Mon, 5 Oct 2015 12:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-Gu0XexEQ1W; Mon, 5 Oct 2015 12:41:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9624A1B4F4C; Mon, 5 Oct 2015 12:41:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151005194140.15637.65416.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 12:41:40 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] Last Call: (Pseudowire Redundancy on S-PE) to Proposed Standard X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 19:41:41 -0000 The IESG has received a request from the Pseudowire And LDP-enabled Services WG (pals) to consider the following document: - 'Pseudowire Redundancy on S-PE' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-10-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which the pseudowire redundancy is provided on the Switching-PE (S-PE). Operations of the S-PEs which provide PW redundancy are specified in this document. Signaling of the preferential forwarding status as defined in RFC 6870 is reused. This document does not require any change to the T-PEs of MS-PW. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1911/ From nobody Mon Oct 5 16:38:10 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909071B30D5; Mon, 5 Oct 2015 16:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs0zdhLdR1Ve; Mon, 5 Oct 2015 16:38:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA73A1B30B3; Mon, 5 Oct 2015 16:37:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151005233756.24983.58366.idtracker@ietfa.amsl.com> Date: Mon, 05 Oct 2015 16:37:56 -0700 Archived-At: Cc: pals chair , pals mailing list , RFC Editor Subject: [Pals] Protocol Action: 'Using A Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator' to Proposed Standard (draft-ietf-pals-vccv-for-gal-06.txt) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 23:38:07 -0000 The IESG has approved the following document: - 'Using A Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator' (draft-ietf-pals-vccv-for-gal-06.txt) as Proposed Standard This document is the product of the Pseudowire And LDP-enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-vccv-for-gal/ Technical Summary This document specifies a new Virtual Circuit Connectivity Verification (VCCV) (RFC5085) control channel type for use with pseudowires (PW) carried over an MPLS network. This new channel type uses the Generic Associated Channel Label (GAL) (RFC5586) to distinguish VCCV packets from packets carrying user data. Although the use of the GAL on PWs in MPLS-TP is defined in RFC6423, this draft specifies the necessary extensions to VCCV to support the GAL on PWs setup and maintained using targeted LDP (tLDP). Working Group Summary Nothing unusual in the progress of the document. Document Quality There are multiple implementations of the GAL for MPLS-TP LSPs and PWs. Many implementations of the LDP extensions for negotiating the use of the existing VCCV control channel on a targeted LDP signalled PW are also known to exist. The document has also been widely reviewed by the original authors of and contributors to VCCV (RFC5085). Personnel The Document Shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com) The Responsible Area Director is Deborah Brungard (db3546@att.com) From nobody Wed Oct 7 19:55:35 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88C1A1AC2; Wed, 7 Oct 2015 19:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpN1jo-ub4Qc; Wed, 7 Oct 2015 19:55:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EA51A19E3; Wed, 7 Oct 2015 19:55:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYM49147; Thu, 08 Oct 2015 02:55:26 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 8 Oct 2015 03:55:25 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Thu, 8 Oct 2015 10:55:15 +0800 From: "Dongjie (Jimmy)" To: "Hejia (Jia)" , "rtg-ads@tools.ietf.org" Thread-Topic: [Pals] RtgDir review: draft-ietf-pals-redundancy-spe-02.txt Thread-Index: AdD7YVzkrOA/z5R9SdCD48fK3tIpwwGErvJw Date: Thu, 8 Oct 2015 02:55:15 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927743B4842@nkgeml512-mbx.china.huawei.com> References: <735916399E11684EAF4EB4FB376B719551BC215F@szxema507-mbs.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B719551BC215F@szxema507-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927743B4842nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-redundancy-spe.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] RtgDir review: draft-ietf-pals-redundancy-spe-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 02:55:32 -0000 --_000_76CD132C3ADEF848BD84D028D243C927743B4842nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmlhLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4NCg0K V2Ugd2lsbCBjb3JyZWN0IHRoZSB0eXBvIGluIG5leHQgdXBkYXRlLg0KDQpCZXN0IHJlZ2FyZHMs DQpKaWUNCg0KRnJvbTogUGFscyBbbWFpbHRvOnBhbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEhlamlhIChKaWEpDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAzMCwgMjAxNSA1 OjI3IFBNDQpUbzogcnRnLWFkc0B0b29scy5pZXRmLm9yZw0KQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtcGFscy1yZWR1bmRhbmN5LXNwZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IHBhbHNA aWV0Zi5vcmcNClN1YmplY3Q6IFtQYWxzXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXBhbHMt cmVkdW5kYW5jeS1zcGUtMDIudHh0DQoNCkhlbGxvLA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBh cyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJv dXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmct cmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElF U0cgcmV2aWV3LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0 YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBS b3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJl IHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhl bHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVU RiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNv bHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCg0K RG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFscy1yZWR1bmRhbmN5LXNwZS0wMi50eHQNClJldmlld2Vy OiBKaWEgSGUNClJldmlldyBEYXRlOiAzMCBTZXB0ZW1iZXIgMjAxNQ0KSUVURiBMQyBFbmQgRGF0 ZTogID8NCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNClMgU3VtbWFyeToNCkkg aGF2ZSBubyBtYWpvciBjb25jZXJuIGFib3V0IHRoaXMgZG9jdW1lbnQgdG8gZ28gZm9yIHB1Ymxp Y2F0aW9uLiBCdXQgYSBtaW5vciBjb21tZW50IGJlbG93IGlzIGJldHRlciB0byBiZSBjb25zaWRl cmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLg0KDQoNCkNvbW1lbnRzOg0KVGhpcyBkb2N1bWVudCBp cyBjbGVhcmx5IHdyaXR0ZW4gYW5kIGVhc3kgdG8gdW5kZXJzdGFuZC4NCg0KDQpNYWpvciBJc3N1 ZXM6DQpObyBtYWpvciBpc3N1ZXMgZm91bmQuDQoNCk1pbm9yIElzc3VlczoNClNlY3Rpb24gMy4x IDogT3BlcmF0aW9ucyBvZiBTY2VuYXJpbyAxDQpGaXJzdCBwYXJhZ3JhcGggIlQtUEUyIGFuZCBU LVBFMyB3b3VsZCBhZHZlcnRpc2UgQWN0aXZlIGFuZCBTdGFuZGJ5IHByZWZlcmVudGlhbCBzdGF0 dXMgYml0IHRvIFMtUEUxIHJlc3BlY3RpdmVseSwuLi4uIg0KU2Vjb25kIHBhcmFncmFwaCAiVC1Q RTMgdGhlbiBhZHZlcnRpc2VzIEFjdGl2ZSBQcmVmZXJlbnRpYWwgU3RhdHVzIHRvIFMtUEUxLCAi DQoNCkkgZ3Vlc3MgaXQgaXMgdHlwby4gU2hvdWxkIGJlICJQcmVmZXJlbnRpYWwgRm9yd2FyZGlu ZyBzdGF0dXMiIGluc3RlYWQgb2YgInByZWZlcmVudGlhbCBzdGF0dXMiLCBpc24ndCBpdD8NCg0K DQoNCg0KQi5SLg0KSmlhDQoNCg0KDQo= --_000_76CD132C3ADEF848BD84D028D243C927743B4842nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj5IaSBKaWEsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5XZSB3aWxsIGNvcnJlY3Qg dGhlIHR5cG8gaW4gbmV4dCB1cGRhdGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6IzFGNDk3RCI+SmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGFscyBbbWFpbHRv OnBhbHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SGVqaWEgKEppYSk8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTUgNToyNyBQTTxi cj4NCjxiPlRvOjwvYj4gcnRnLWFkc0B0b29scy5pZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gcnRn LWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3BlLmFsbEB0b29scy5p ZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUGFsc10gUnRnRGly IHJldmlldzogZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3BlLTAyLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMx RjQ5N0QiPkhlbGxvLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5J IGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBm b3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFs bCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2gg SUVURiBsYXN0DQogY2FsbCBhbmQgSUVTRyByZXZpZXcuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZp ZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUNCjxh IGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdE aXIiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8 L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkFsdGhvdWdoIHRo ZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURz LCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdp dGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsDQog YW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0 aW5nIHRoZSBkcmFmdC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5E b2N1bWVudDogZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3BlLTAyLnR4dA0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlJldmlld2VyOiBKaWEgSGUNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5SZXZpZXcgRGF0ZTog MzAgU2VwdGVtYmVyIDIwMTUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj5JRVRGIExDIEVuZCBEYXRlOiZuYnNwOyA/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlM8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj5TdW1tYXJ5OiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIG5vIG1ham9yIGNvbmNlcm4gYWJvdXQgdGhpcyBkb2N1 bWVudCB0byBnbyBmb3IgcHVibGljYXRpb24uIEJ1dCBhIG1pbm9yIGNvbW1lbnQgYmVsb3cgaXMg YmV0dGVyIHRvIGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8gcHVibGljYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+VGhpcyBkb2N1bWVudCBpcyBjbGVhcmx5IHdyaXR0ZW4g YW5kIGVhc3kgdG8gdW5kZXJzdGFuZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPk1ham9yIElzc3VlczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj5ObyBtYWpvciBpc3N1ZXMgZm91bmQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOiMxRjQ5N0QiPk1pbm9yIElzc3VlczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDMuMSA6IE9wZXJhdGlvbnMgb2YgU2NlbmFyaW8g MQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkZpcnN0IHBh cmFncmFwaCAmcXVvdDtULVBFMiBhbmQgVC1QRTMgd291bGQgYWR2ZXJ0aXNlIEFjdGl2ZSBhbmQg U3RhbmRieSBwcmVmZXJlbnRpYWwgc3RhdHVzIGJpdCB0byBTLVBFMSByZXNwZWN0aXZlbHksLi4u LiZxdW90Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlNl Y29uZCBwYXJhZ3JhcGggJnF1b3Q7VC1QRTMgdGhlbiBhZHZlcnRpc2VzIEFjdGl2ZSBQcmVmZXJl bnRpYWwgU3RhdHVzIHRvIFMtUEUxLCAmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgaXQgaXMgdHlwby4gU2hvdWxkIGJlICZxdW90O1ByZWZlcmVu dGlhbCBGb3J3YXJkaW5nIHN0YXR1cyZxdW90OyBpbnN0ZWFkIG9mICZxdW90O3ByZWZlcmVudGlh bCBzdGF0dXMmcXVvdDssIGlzbid0IGl0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Qi5SLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5KaWE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_76CD132C3ADEF848BD84D028D243C927743B4842nkgeml512mbxchi_-- From nobody Thu Oct 8 19:44:35 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD901B2B58; Thu, 8 Oct 2015 19:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ7vKBlMqtnI; Thu, 8 Oct 2015 19:44:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8DD1A8740; Thu, 8 Oct 2015 19:44:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYO00729; Fri, 09 Oct 2015 02:44:23 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 9 Oct 2015 03:44:23 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Fri, 9 Oct 2015 10:44:16 +0800 From: Mingui Zhang To: Barry Leiba , The IESG Thread-Topic: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) Thread-Index: AQHQ/E9N7xP/rpWzhUWdCnixCwkCPJ5hXQRg Date: Fri, 9 Oct 2015 02:44:16 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E78720B693@nkgeml512-mbx.china.huawei.com> References: <20151001134257.12685.1930.idtracker@ietfa.amsl.com> In-Reply-To: <20151001134257.12685.1930.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pals-chairs@ietf.org" , "agmalis@gmail.com" , "pals@ietf.org" Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 02:44:27 -0000 Hi Barry, Thanks for the comments. Please see the in-lines below. > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Thursday, October 01, 2015 9:43 PM > To: The IESG > Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org > Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04= : (with > COMMENT) >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-pwe3-iccp-stp-04: No Objection >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This is a small thing, but please give some consideration to this: >=20 > A 2119 "SHOULD" defines something that implementations need to do unless > they have a good reason not to, and fully understand the issues and the > consequences of not doing it. In general, I believe that means that > specifications, when they use "SHOULD", need to include enough informatio= n > for readers to understand why it's a "SHOULD" and to evaluate the > consequences. That seems missing from many of the SHOULDs here, and I'd > like to see you go through the document, find the ones that aren't making= it > clear enough, and beef them up just a little. [MZ] Authors has gone through the document. Now the ones that aren't cleare= d have been cleared. >=20 > An example where this is done right is in Section 4.2.3: >=20 > While a PE has sent out a synchronization request for a particular PE > node, it SHOULD silently ignore all TLVs from that node, that are > received prior to the synchronization response and which carry the > same type of information being requested. This saves the system from > the burden of updating state that will ultimately be overwritten by > the synchronization response. Note that TLVs pertaining to other > systems should continue to be processed normally. >=20 > THe second sentence explains why, and gives me some idea of what to consi= der > when I'm writing my implementation. Thank you. There are others that ge= t > it right as well. >=20 > A particularly weak one is in Section 4.2.1: >=20 > A PE SHOULD follow the following order when advertising its STP state > upon initial application connection setup: >=20 > What's the significance of that order, from an interoperability, performa= nce, or > security perspective? What happens if, because of how my implementation = is > written, it's easier for me to do them in a different order and I decide = to do so, > not knowing what the consequences are? [MZ] It is for a performance reason. The following sentences will be added. The update of the information contained in the State TLVs depends on that i= n the configuration TLVs. By sending the TLVs in the above order, the two p= eers may begin to update STP state as early as possible in the middle of ex= changing these TLVs. Thanks, Mingui From nobody Thu Oct 8 19:55:07 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71231B2C12; Thu, 8 Oct 2015 19:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPrWpfXmQOFN; Thu, 8 Oct 2015 19:55:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445D51B2BFE; Thu, 8 Oct 2015 19:54:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCH05902; Fri, 09 Oct 2015 02:54:57 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 9 Oct 2015 03:54:55 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Fri, 9 Oct 2015 10:54:49 +0800 From: Mingui Zhang To: Stephen Farrell , The IESG Thread-Topic: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) Thread-Index: AQHQ+4GIdsqNDDNnGk+fsAP6zkUDl55hP+8Q Date: Fri, 9 Oct 2015 02:54:48 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> In-Reply-To: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pals-chairs@ietf.org" , "agmalis@gmail.com" , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 02:55:04 -0000 Hi Stephen, 802.1q uses hmac-md5. This still holds in the latest version of 802.1q. I agree that sha256 could be used to enhance the security. However, I think= that kind of enhancement is out the scope of this document and should be d= iscussed in 802.1q. Thanks, Mingui > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Wednesday, September 30, 2015 9:10 PM > To: The IESG > Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org > Subject: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-st= p-04: > (with COMMENT) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-pwe3-iccp-stp-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what if= 802.1q > is fixed/improved e.g. to use sha256? >=20 >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Fri Oct 9 02:03:35 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAEB1ACEB8; Fri, 9 Oct 2015 02:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdxomCxu0pDt; Fri, 9 Oct 2015 02:03:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0291A8A74; Fri, 9 Oct 2015 02:03:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151009090333.29575.92112.idtracker@ietfa.amsl.com> Date: Fri, 09 Oct 2015 02:03:33 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pwe3-iccp-stp-05.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 09:03:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : Spanning Tree Protocol (STP) Application of Inter-Chassis Communication Protocol (ICCP) Authors : Mingui Zhang Huafeng Wen Jie Hu Filename : draft-ietf-pwe3-iccp-stp-05.txt Pages : 24 Date : 2015-10-09 Abstract: Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism which is used to support high network availability. In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multi-homed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pwe3-iccp-stp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pwe3-iccp-stp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 9 03:09:18 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D061A8A17; Fri, 9 Oct 2015 03:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7fMOhR74K22; Fri, 9 Oct 2015 03:09:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA44B1A8A27; Fri, 9 Oct 2015 03:09:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE52DBE53; Fri, 9 Oct 2015 11:09:14 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIjPyYf38amU; Fri, 9 Oct 2015 11:09:14 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80C0CBE51; Fri, 9 Oct 2015 11:09:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444385354; bh=Gm6D+bH+m9uwTcB0In1EANOdW9xED5ScCZE4hwl57iU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=sy45bRubz+zf3LLMGgd+bdNvG52ExTA5fquEALJxWIZSY3MOPV1drHQUvlv+2HKP1 EFCfT4FSmCD+b1ouvSxiP90kkPazo5+a0ogOZrC0BtGMNhdWHQZoOGISYG/HCydxsT eVij65lyititGf4Y7J1VtTUXC5DAl1DXnTnpOaeE= To: Mingui Zhang , The IESG References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56179249.6040108@cs.tcd.ie> Date: Fri, 9 Oct 2015 11:09:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "pals-chairs@ietf.org" , "agmalis@gmail.com" , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 10:09:17 -0000 On 09/10/15 03:54, Mingui Zhang wrote: > Hi Stephen, > > 802.1q uses hmac-md5. This still holds in the latest version of > 802.1q. > > I agree that sha256 could be used to enhance the security. However, I > think that kind of enhancement is out the scope of this document and > should be discussed in 802.1q. Of course. But if they do that, and make a change what is the impact here is my question. (I didn't re-read the doc, but was this one where it assumes a certainly length or something?) S > > Thanks, Mingui > >> -----Original Message----- From: Pals >> [mailto:pals-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: >> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: >> pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org Subject: >> [Pals] Stephen Farrell's No Objection on >> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-pwe3-iccp-stp-04: No Objection >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ >> >> >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what if 802.1q >> is fixed/improved e.g. to use sha256? >> >> >> _______________________________________________ Pals mailing list >> Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals From nobody Fri Oct 9 05:03:14 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0D1B393E for ; Fri, 9 Oct 2015 05:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0biZx7DRq2Yt for ; Fri, 9 Oct 2015 05:03:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781E21B393B for ; Fri, 9 Oct 2015 05:03:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCI12691; Fri, 09 Oct 2015 12:03:03 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 9 Oct 2015 13:03:00 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.235]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Fri, 9 Oct 2015 20:02:48 +0800 From: Jiangyuanlong To: Lizhong Jin , "Stewart Bryant (stbryant)" Thread-Topic: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward Thread-Index: AQHQ/rtUxWK2nsKj1kiG82sRb2nctZ5bHvaAgAC0IYCABzn3cA== Date: Fri, 9 Oct 2015 12:02:47 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pals@ietf.org" , "pals-chairs@tools.ietf.org" , "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 12:03:12 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22szxema506mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBoYWQgc29tZSBkaXNjdXNzaW9ucyBvbiB0aGlzIG1lY2hhbmlzbSB3aGVu IHRoZSBkb2N1bWVudCB3YXMgc3RpbGwgYW4gaW5kaXZpZHVhbCBkcmFmdCAoaW4gZmFjdCwgd2hl biBpdCB3YXMgYmVpbmcgdXBkYXRlZCB0byBkcmFmdC1qaWFuZy1sMnZwbi12cGxzLXBlLWV0cmVl LTAzKS4NCkp1c3QgbGlrZSBTdGV3YXJ0LCBzb21lIHNlcnZpY2UgcHJvdmlkZXJzIHdlcmUgYWxz byBjb25jZXJuZWQgdGhhdCB0aGlzIG1lY2hhbmlzbSBtYXkgcmVzdWx0IGluIGEgZ3JlYXQgd2Fz dGUgb2YgcGxhdGZvcm0gbGFiZWxzLiBGb3IgZXhhbXBsZSwgaW4gYSBuZXR3b3JrIHdpdGggb25l IHJvb3QgUEUgYW5kIDEwMDAgbGVhZiBQRXMsIG9ubHkgMTAwMSBQVyBsYWJlbHMgYXJlIG5lZWRl ZCBmb3IgdGhlIGFwcHJvYWNoIGluIHRoZSBkb2N1bWVudDsgYnV0IHdlIHdpbGwgbmVlZCAxMDAw Kjk5OS8yPTQ5OTUwMCBQVyBsYWJlbHMgaW4gYWxsIGZvciB0aGUgcHJvcG9zZWQgbWVjaGFuaXNt IChzaW5jZSBsZWFmIHRvIGxlYWYgUFdzIGFyZSBzdGlsbCBhbGxvY2F0ZWQpLiBUaGF0IGlzIHRo ZSBtYWluIHJlYXNvbiB3ZSBhZG9wdGVkIHRoZSBjdXJyZW50IGFwcHJvYWNoLg0KVGhlcmVmb3Jl LCBJIHdpbGwgcmVnYXJkIG9wdGlvbiAxKSBhcyB0aGUgZmF2b3JpdGUgd2F5IGZvcndhcmQ6DQox KSBMZWF2ZSB0aGUgZGVzaWduIGFzIGl0IGlzLCBidXQgYWRkIHRleHQgdG8gZGVzY3JpYmUgdGhl IGNvbnN0cmFpbnQgYW5kDQp3aGF0IGhhcHBlbnMgaWYgeW91IGhhdmUgdG8gY2hhbmdlIG1vZGUg YW5kIHdoYXQgdG8gZG8gYWJvdXQgaXQuDQoNCkkgd2lsbCBiZSBnbGFkIHRvIHNlZSBtb3JlIGlu cHV0cyB0byB0aGlzIHRvcGljLg0KDQpUaGFua3MsDQpZdWFubG9uZw0KDQoNCg0KRnJvbTogTGl6 aG9uZyBKaW4gW21haWx0bzpsaXpoby5qaW5AZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBPY3Rv YmVyIDA1LCAyMDE1IDE6MDUgUE0NClRvOiBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQpDYzog ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlQHRvb2xzLmlldGYub3JnOyBwYWxzQGlldGYu b3JnOyBwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtQYWxzXSBkcmFm dC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWUgLSBwb3NzaWJsZSB3YXlzIGZvcndhcmQNCg0KSGkg U3Rld2FydCwNCkZvciBEVSBtb2RlLCBpZiBGRUMgaXMgY3JlYXRlZCwgdGhlbiBsYWJlbCBzaG91 bGQgYmUgYWxsb2NhdGVkLiBGb3IgdGhlIHZ1bG5lcmFiaWxpdHkgeW91IG1lbnRpb25lZCwgaWYg SSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24gY29ycmVjdGx5LCB0aGUgUFcgbGFiZWwgd2lsbCBu b3QgYmUgcHJvZ3JhbW1lZCBpbnRvIGhhcmR3YXJlLCBidXQgb25seSBrZXB0IGluIGNvbnRyb2wg cGxhbmUuIFNvIHRoZSBwYWNrZXQgd2lsbCBub3QgYmUgd3JvbmdseSBwcm9jZXNzZWQuDQpUaGUg TVRVIGludGVyZmFjZSBTdWItVExWIGRlZmluZWQgaW4gUkZDNDQ0NyBzZWN0aW9uIDYuNCBzYWlk Og0KDQpJZiB0aGlzIHBhcmFtZXRlciBkb2VzIG5vdCBtYXRjaA0KDQogICAgICAgaW4gYm90aCBk aXJlY3Rpb25zIG9mIGEgc3BlY2lmaWMgUFcsIHRoYXQgUFcgTVVTVCBOT1QgYmUgZW5hYmxlZC4N ClRoZSBtZWNoYW5pc20gSSBwcm9wb3NlZCBpcyB3aGF0IGhhdmUgYmVlbiBkb25lIGZvciBNVFUg aW50ZXJmYWNlIHN1Yi1UTFYuDQoNClJlZ2FyZHMNCkxpemhvbmcNCg0KT24gTW9uLCBPY3QgNSwg MjAxNSBhdCAyOjE5IEFNLCBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpIDxzdGJyeWFudEBjaXNj by5jb208bWFpbHRvOnN0YnJ5YW50QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gNCBPY3Qg MjAxNSwgYXQgMTY6NDMsIExpemhvbmcgSmluIDxsaXpoby5qaW5AZ21haWwuY29tPG1haWx0bzps aXpoby5qaW5AZ21haWwuY29tPj4gd3JvdGU6DQpIaSBTdGV3YXJ0LA0KVGhhbmtzIGZvciB0aGUg Y29tbWVudC4gVGhpcyBpcyBhIGxvbmcgZW1haWwuDQpZb3UgZ2l2ZSB1cyB0aHJlZSBvcHRpb25z Og0KDQoxKSBMZWF2ZSB0aGUgZGVzaWduIGFzIGl0IGlzLCBidXQgYWRkIHRleHQgdG8gZGVzY3Jp YmUgdGhlIGNvbnN0cmFpbnQgYW5kDQp3aGF0IGhhcHBlbnMgaWYgeW91IGhhdmUgdG8gY2hhbmdl IG1vZGUgYW5kIHdoYXQgdG8gZG8gYWJvdXQgaXQuDQoNCjIpIEV4Y2x1ZGUgb3B0aW1pemF0aW9u IGluIHRoZSBGRUMgUFdpZCgweDgwKSBjYXNlDQoNCjMpIEFkZCBhbiBhcHBlbmRpeCBkZXNjcmli aW5nIHN1cHBvcnQgZm9yIHRoZSBGRUMgUFdpZCgweDgwKSBjYXNlLg0KDQogVGhlbiBJIHByZWZl ciBvcHRpb24gMS4gQmVjYXVzZSBvcHRpb24yIGlzIG5vdCByZWFzb25hYmxlLCBhbmQgdGhlIHNv bHV0aW9uIGluIG9wdGlvbjMgcHJvdmlkZWQgYnkgdGhlIGF1dGhvciBpcyBub3QgdGhlIGJlc3Qg b25lLg0KDQpJIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBvcGl0aW9uNCBmb3IgV0cgdG8gY29uc2lk ZXI6DQo0KSBBZGQgZGVzY3JpcHRpb24gdG8gc3VwcG9ydCBmb3IgdGhlIEZFQyBQV2lkKDB4ODAp IGNhc2UsIGluIGFwcGVuZGl4IG9yIHRleHQgSSBkb24ndCBjYXJlLiBUaGUgc29sdXRpb24gaXM6 DQoNCmxhYmVsIHJlbGVhc2UgbWVzc2FnZSBzaG91bGQgbm90IGJlIHNlbnQgaW4gc2VjdGlvbiA2 LjEuDQoNCkZvciBQVyBzaWduYWxpbmcsIHRoZSB1bmFjY2VwdGFibGUgb2YgYW55IEludGVyZmFj ZSBQYXJhbWV0ZXIgd2lsbCBub3QgbGVhZCB0byBhbnkNCg0KbGFiZWwgcmVsZWFzZSwgYnV0IGp1 c3Qgc2ltcGx5IGxldCB0aGUgUFcgZG93biBpbiBmb3J3YXJkaW5nIHBsYW5lLg0KTGlzdGluZw0K DQpEb2Vzbid0IHRoYXQgd2FzdGUgbGFiZWxzLCB3aGljaCBtYXkgYmUgYSBwcm9ibGVtIGluIHNv bWUgc3lzdGVtcywgYW5kIGNyZWF0ZSBhIHZ1bG5lcmFiaWxpdHkgc2luY2Ugc29tZW9uZSBtYXkg c2VuZCBhIHBhY2tldCB3aXRoIHRoYXQgbGFiZWwgd2hpY2ggd291bGQgYmUgcHJvY2Vzc2VkIGFu ZCBzZW50IG91dCBvZiB0aGUgcGVyc29uIGVncmVzcy4NCg0KLVN0ZXdhcnQNCg0KDQpSZWdhcmRz DQpMaXpob25nDQoNCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0N CkZyb206IFN0ZXdhcnQgQnJ5YW50IDxzdGJyeWFudEBjaXNjby5jb208bWFpbHRvOnN0YnJ5YW50 QGNpc2NvLmNvbT4+DQpUbzogImRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZUB0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlQHRvb2xzLmlldGYu b3JnPiIgPGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZUB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlQHRvb2xzLmlldGYub3JnPj4sICJwYWxz QGlldGYub3JnPG1haWx0bzpwYWxzQGlldGYub3JnPiIgPHBhbHNAaWV0Zi5vcmc8bWFpbHRvOnBh bHNAaWV0Zi5vcmc+Pg0KQ2M6ICJwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86cGFs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+IiA8cGFscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPj4NCkRhdGU6IEZyaSwgMiBPY3QgMjAxNSAx Njo0MTowNSArMDEwMA0KU3ViamVjdDogW1BhbHNdIGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1l dHJlZSAtIHBvc3NpYmxlIHdheXMgZm9yd2FyZA0KSSBhbSBzb3JyeSB0aGF0IHRoaXMgaXMgYSBs b25nIGVtYWlsLCBidXQgSSB3YW50ZWQgdG8gY29sbGVjdCB0aGUNCmZhY3RzIHRvZ2V0aGVyIGlu IG9uZSBwbGFjZSBhbmQgc2V0IG91dCB0aGUgY29tcGxldGUgc2NlbmUgdG8NCnRoZSBQQUxTIFdH Lg0KDQpUaGUgY3JpdGljYWwgY29uY2VybiBpcyBjb250YWluZWQgaW4gdGhlIGZvbGxvd2luZyBl bWFpbCBmcmFnbWVudA0KZnJvbSBMaXpob25nOg0KDQo9PT09PT09DQpJbiBSRkM0NDQ3IGFuZCA0 NDQ3YmlzLCBpdCBjbGVhcmx5IHNhaWQ6DQoNClVzaW5nIHRoZSBQV2lkIEZFQywgZWFjaCBvZiB0 aGUgdHdvIHBzZXVkb3dpcmUgZW5kcG9pbnRzDQoNCiAgIGluZGVwZW5kZW50bHkgaW5pdGlhdGVz IHRoZSBzZXR1cCBvZiBhIHVuaWRpcmVjdGlvbmFsIExTUC4gICBBbg0KDQogICBvdXRnb2luZyBM U1AgYW5kIGFuIGluY29taW5nIExTUCBhcmUgYm91bmQgdG9nZXRoZXIgaW50byBhIHNpbmdsZQ0K DQogICBwc2V1ZG93aXJlIGlmIHRoZXkgaGF2ZSB0aGUgc2FtZSBQVyBJRCAgYW5kIFBXIHR5cGUu DQoNClRoZSBiZWhhdmlvciBpcyBhIGNvcnJlY3QgZGVzY3JpcHRpb24gZm9yIExEUC1EVSBtb2Rl IHdoaWNoIFBXIGFwcGxpZXMuDQoNCkFuZCB0aGF0IGlzIGFsc28gdGhlIGJlaGF2aW9yIG1vc3Qg dmVuZG9ycyBpbXBsZW1lbnQuDQoNCg0KDQpUaGVuIGluIGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1w ZS1ldHJlZS0wOSwgaXQgc2F5czoNCg0KIEEgUEUgdGhhdCByZWNlaXZlcyBhIFBXIGxhYmVsIG1h cHBpbmcgbWVzc2FnZSB3aXRoIGFuIEUtVHJlZSBTdWItVExWDQoNCiAgIGZyb20gaXRzIHBlZXIg UEUsIGFmdGVyIHNhdmluZyB0aGUgVkxBTiBpbmZvcm1hdGlvbiBmb3IgdGhlIFBXLCBNVVNUDQoN CiAgIHByb2Nlc3MgaXQgYXMgZm9sbG93czoNCg0KLi4uLi4NCg0KMykgSWYgdGhlIFAgYml0IGlz IHNldA0KDQoNCg0KICAgICAgew0KDQoNCg0KICAgICAgICAgIElmIHRoZSBQRSBpcyBhIGxlYWYt b25seSBub2RlIGl0c2VsZiwgYSBsYWJlbCByZWxlYXNlIG1lc3NhZ2UNCg0KICAgICAgd2l0aCBh IHN0YXR1cyBjb2RlICJMZWFmIHRvIExlYWYgUFcgcmVsZWFzZWQiIGlzIHNlbnQgdG8gdGhlIHBl ZXINCg0KICAgICAgUEUgYW5kIGV4aXQgdGhlIHByb2Nlc3M7DQoNCg0KDQogICAgICAgICAgRWxz ZSB0aGUgUEUgU0hPVUxEIHNldCB0aGUgT3B0aW1pemVkLU1vZGUgdG8gVFJVRS4NCg0KDQoNCiAg ICAgIH0NCg0KVGhhdCBtZWFucywgaWYgUEUxIHJlY2VpdmluZyBhIGxhYmVsIG1hcHBpbmcgZnJv bSBQRTIgd2l0aCBQIGJpdCBzZXQsDQoNClBFMSB3aWxsIHNlbmQgbGFiZWwgcmVsZWFzZS4gVGhl biBQRTIgd2lsbCBuZXZlciBzZW5kIGxhYmVsIG1hcHBpbmcNCg0KYWdhaW4gdG8gUEUxIGV2ZW4g d2hlbiBQRTEgY2hhbmdlcyBmcm9tIGxlYWYtb25seSBub2RlIHRvIHJvb3QtbGVhZiBub2RlLiBG b3IgTERQLURVDQoNCm1vZGUsIFBFMiB3aWxsIG5vdCBzZW5kIGxhYmVsIG1hcHBpbmcgYWdhaW4g d2hlbiByZWNlaXZpbmcgUEUxJ3MgbGFiZWwgbWFwcGluZy4NCg0KVGhlbiB0aGUgUFcgd2lsbCBu b3QgYmUgc2V0dXAgc3VjY2Vzc2Z1bGx5LiBUaGVuIG9ubHkgd2F5IGlzIHRvIGNvbmZpZ3VyZSB0 aGUNCg0Kc2FtZSBQVyBvbiBQRTIgYWdhaW4uDQoNClRoZSBjb3JyZWN0IGJlaGF2aW9yIGlzLCBs YWJlbCByZWxlYXNlIG1lc3NhZ2Ugc2hvdWxkIG5vdCBiZSBzZW50Lg0KDQpGb3IgUFcgc2lnbmFs aW5nLCB0aGUgdW5hY2NlcHRhYmxlIG9mIGFueSBJbnRlcmZhY2UgUGFyYW1ldGVyIHdpbGwgbm90 IGxlYWQgdG8gYW55DQoNCmxhYmVsIHJlbGVhc2UsIGJ1dCBqdXN0IHNpbXBseSBsZXQgdGhlIFBX IGRvd24gaW4gZm9yd2FyZGluZyBwbGFuZS4NCg0KDQo9PT09PT09PQ0KDQpBbmR5IGxvb2tlZCBh dCB0aGlzIGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIE1FRiBhbmQgbm90ZXMgaW4NCnBy aXZhdGUgY29udmVyc2F0aW9uOg0KPT09PT09PT09DQpJbiB0aGUgRS10cmVlIHNlcnZpY2UgYXMg ZGVmaW5lZCBieSBNRUYsIHlvdSBjYW4gaGF2ZSBvbmUgb3IgbW9yZSByb290cw0KYW5kIG9uZSBv ciBtb3JlIGxlYWZzLg0KDQpJbiBhIHNpbmdsZSBFLXRyZWUgc2VydmljZSAodGhpbmsgb2YgYSBt dWx0aXBvaW50IFBXIHdpdGggc29tZSBvZiB0aGUgQ0VzDQpjb25maWd1cmVkIGFzIHJvb3RzIGFz IHNvbWUgYXMgbGVhZnMpLCBhbGwgbGVhZnMgYW5kIHJvb3RzIHJlY2VpdmUgZnJhbWVzDQpzZW50 IGJ5IHRoZSByb290cy4gQWxsIHJvb3RzIHJlY2VpdmUgZnJhbWVzIHNlbnQgYnkgdGhlIGxlYWZz LiBIb3dldmVyLA0KbGVhZnMgbWF5IG5vdCByZWNlaXZlIGFueSBmcmFtZXMgc2VudCBieSBvdGhl ciBsZWFmcy4NCg0KVGhlIGRyYWZ0LCBhcyB3cml0dGVuLCBkb2Vzbid0IGJyaW5nIHVwIGFuIHVu ZGVybHlpbmcgcHQtdG8tcHQgUFdzIHRvDQpjYXJyeSBmcmFtZXMgZm9yIHRoZSBzZXJ2aWNlIGJl dHdlZW4gUEVzIHRoYXQgb25seSBoYXZlIGxlYWZzIGF0dGFjaGVkLg0KU2luY2UgdGhlIGxlYWZz IGNhbid0IHNlbnQgZnJhbWVzIHRvIGVhY2ggb3RoZXIsIHRoYXQgaXMgYW4gZWNvbm9taWNhbA0K dXNlIG9mIFBXcyBpbiB0aGUgbmV0d29yay4NCg0KTGl6aG9uZydzIHBvaW50IGlzIHRoYXQgdGhp cyBtYWtlcyBpdCBpbXBvc3NpYmxlIHRvIGFkZCBhIG5ldyByb290IHRvDQphbiBleGlzdGluZyBQ RSBpbiBhbiBFLXRyZWUgdGhhdCBwcmV2aW91c2x5IG9ubHkgaGFkIGxlYWZzLg0KDQpJIGFncmVl IHRoYXQgd291bGQgYmUgYSBwcm9ibGVtIGlmIHRoZXJlIHdhcyBhIHJlcXVpcmVtZW50IHRvIG1v ZGlmeQ0KYW4gZXhpc3RpbmcgRS10cmVlIHNlcnZpY2UuIEhvd2V2ZXIsIHRoaXMgZHJhZnQgaGFz IG5vIG90aGVyIG1lY2hhbmlzbXMNCnRvIGV4cGxpY2l0bHkgc3VwcG9ydCBFLXRyZWUgbW9kaWZp Y2F0aW9uLCBub3IgaXMgc3VjaCBtb2RpZmljYXRpb24gYQ0KcmVxdWlyZW1lbnQgb2YgdGhlIHVu ZGVybHlpbmcgTUVGIHNwZWNpZmljYXRpb24uIEJUVywgc2luY2UgdGhpcyB3b3JrDQp3YXMgc3Rh cnRlZCwgdGhlIE1FRiByZXBsYWNlZCBNRUYgNi4xIHdpdGggTUVGIDYuMiwgIkVWQyBFdGhlcm5l dA0KU2VydmljZXMgRGVmaW5pdGlvbnMgUGhhc2UgMyIsIEF1Z3VzdCwgMjAxNCwgYW5kIHRoYXQg cmVmZXJlbmNlIHNob3VsZA0KYmUgdXBkYXRlZCBpbiB0aGUgZHJhZnQuDQpNeSBvcGluaW9uIGlz IHRoYXQgdGhlIGRyYWZ0IGFzIGl0IHN0YW5kcyBpcyB0ZWNobmljYWxseSBjb3JyZWN0IGlmIHlv dQ0KZG9uJ3QgbmVlZCB0aGUgYWJpbGl0eSB0byByZWNvbmZpZ3VyZSBhbiBleGlzdGluZyBFLXRy ZWUgc2VydmljZSBkeW5hbWljYWxseS4NCg0KPT09PT09PT09PQ0KDQpOb3cgd2hpbHN0IEkgY2Fu IHN1cHBvcnQgdGhlIGlkZWEgdGhhdCBkeW5hbWljIHJlY29uZmlndXJhdGlvbiBvZg0KRS10cmVl IGlzIG5vdCBuZWVkZWQsIEkgaGF2ZSBhIGNvbmNlcm4uDQoNCk15IHVuZGVyc3RhbmRpbmcgdGhl IHRleHQgaW4gcXVlc3Rpb24gaXMgdGhhdCBpdCBpcyBzYXlpbmcgdGhhdCBpZg0KQSBpcyBjb25m aWd1cmVkIGFzIGxlYWYgb25seSwgYW5kIEIgd2hpY2ggaXMgYWxzbyBjb25maWd1cmVkIGFzDQps ZWFmIG9ubHkgYXR0ZW1wdHMgdG8gY29uZmlndXJlIGEgUFcgYmV0d2VlbiB0aGVtLCB0aGVuIEEg cmVqZWN0cw0KdGhlIFBXIHNldHVwLg0KDQpUaGF0IHNvdW5kcyB2ZXJ5IHJlYXNvbmFibGUgdG8g bWUsIHNpbmNlIHRoZXJlIGlzIGEgbWlzY29uZmlnLg0KDQpJZiBBIGRpZCBub3QgZG8gdGhlIHJl amVjdCwgdGhlbiBCIHdvdWxkIGZvcmV2ZXIgYmUgY29uc3VtaW5nDQpyZXNvdXJjZSB3YWl0aW5n IGZvciBBIGFuZCBCIHdvdWxkIGhhdmUgbm8gaWRlYSBvZiB0aGUNCm1pc2NvbmZpZy4gVGhhdCBh Y2NvcmRzIHdpdGggQW5keSdzIHZpZXcgYWJvdmUuDQoNCkhvd2V2ZXIgSSB3YXMgd29ycmllZCB3 aGF0IHdvdWxkIGhhcHBlbiBpZiBBIHdhcyBtaXNjb25maWd1cmVkDQphcyBsZWFmIG9ubHkgYW5k IHRoZSBjb25maWd1cmF0aW9uIHdhcyBjb3JyZWN0ZWQgdG8gcm9vdC1sZWFmLg0KV2hhdCB3b3Vs ZCBpbiBteSB2aWV3IGJlIGRpZmZpY3VsdCB0byBhY2NlcHQgd2FzIHRoZSBuZWVkIHRvDQp0YWtl IGEgaHVtYW4sIG9yIE5NUyBhY3Rpb24gYXQgQiB0byByZWNvdmVyIHRoZSBzaXR1YXRpb24uDQpI b3dldmVyIHByb3ZpZGVkIHRoYXQgQSBjbG9zZWQgdGhlIExEUCBzZXNzaW9uIHdpdGggQg0KYW5k IHJlLWluc3RhdGUgaXQgQiB3b3VsZCB0aGVuIHNlbmQgdGhlIG1hcHBpbmcgbWVzc2FnZSBhZ2Fp bi4NClRodXMgdGhlIHN5c3RlbSBpcyByZWNvdmVyYWJsZSB3aXRob3V0IG5lZWRpbmcgdG8gdmlz aXQgQiB3aGljaA0KaXMgaW4gbXkgbWluZCBhIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50IHNpbmNl IEEgY291bGQgaGF2ZQ0KZ290IGludG8gdGhlIHdyb25nIG1vZGUgYXMgYSByZXN1bHQgb2YgYW4g ZXJyb3IuDQoNClRoZSBwcm9ibGVtIEkgc2VlIGlzIGlmIEEgaGFzIGEgYnVuY2ggb2Ygb3RoZXIg UFdzIHdpdGggQg0KdGhleSB3aWxsIGdldCB0b3JuIGRvd24gaW4gb3JkZXIgZm9yIEEgdG8gaGF2 ZSB0aGUgY29uZmlnIGVycm9yDQpmaXhlZC4gSG93ZXZlciBpZiB0aGF0IGlzIGEgcHJvYmxlbSB5 b3UgbmVlZCB0d28gTERQIHNlc3Npb25zDQpiZXR3ZWVuIEEgYW5kIEIsIG9uZSBmb3IgTDJWUE4g YW5kIG9uZSBmb3IgcmVndWxhciBQV3MuDQoNCk15IGluY2xpbmF0aW9uIGlzIHRoYXQgdGhlIGRy YWZ0IGlzIGJhc2ljYWxseSBjb3JyZWN0LCBhbmQgdGhhdCB3aGlsc3QNCkxpemhvbmcgaXMgY29y cmVjdCB0aGF0IHRoZSBQVyB3aWxsIG5vdCBjb21lIHVwIHdpdGhvdXQgc29tZQ0KYWN0aW9uLCBy ZWNvbmZpZ3VyaW5nIHRoZSBQVyBvbiBCIGlzIG5vdCB0aGUgb25seSBhY3Rpb24NCnRoYXQgd2ls bCBjYXVzZSB0aGUgUFcgdG8gY29tZSB1cC4NCg0KU28gdGhpcyBjb21lcyBkb3duIHRvIGEgV0cg ZGVjaXNpb24gaW4gdGVybXMgb2Ygd2hpY2ggaXMgdGhlDQpsZWFzdCB1bmFjY2VwdGFibGUgYmVo YXZpb3VyIC0gQSBoYXZpbmcgdG8gcmUtY3ljbGUgdGhlIExEUA0Kc2Vzc2lvbiwgb3IgQiB3YXN0 aW5nIHJlc291cmNlcy4gSSB0aGluayBJIHByZWZlciB0aGUgYmVoYXZpb3VyDQpwcm9wb3NlZCBp biB0aGUgZHJhZnQuDQoNCkEgd2F5IGZvcndhcmQgaXMgdG8gbGVhdmUgdGhlIGxvZ2ljIGFzIHdy aXR0ZW4gaW4gdGhlIGRyYWZ0LCBidXQgdG8NCmFkZCB0ZXh0IGRlc2NyaWJpbmcgdGhlIGJhc2lz IGZvciBleGNsdWRpbmcgZHluYW1pYyByZS1jb25maWd1cmF0aW9uDQphcyBhIG5vcm1hbCBvcGVy YXRpb25hbCBtb2RlIGFuZCB0byBub3RlIHRoZSBhY3Rpb25zIHRoYXQgbmVlZA0KdG8gYmUgdGFr ZW4gd2hlbiByZS1jb25maWd1cmF0aW9uIGlzIGZvcmNlZCBmb3Igc29tZSByZWFzb24uDQoNCldo aWxzdCB3ZSB3ZXJlIHBvbmRlcmluZyB3aGF0IGRvIHdpdGggdGhlIHRleHQgdGhlIGNoYWlycw0K YW5kIEFEIHJlY2VpdmVkIGFub3RoZXIgcHJvcG9zYWwgZnJvbSB0aGUgYXV0aG9yczoNCg0KPT09 PT09DQoNCkluIGdlbmVyYWwsIEZFQyBQV2lkKDB4ODApIGlzIHVzZWQgaW4gVlBMUyB3aXRoIG1h bnVhbCBwcm92aXNpb25pbmcsDQp3aGlsZSBHZW5lcmFsaXplZCBQV2lkICgweDgxKSBpcyB1c2Vk IHdpdGggYXV0by1kaXNjb3ZlcnkuDQoNCkFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDUuMiwgVkxB TiBtYXBwaW5nIHBhcmFtZXRlcnMgY2FuIGJlIHByb3Zpc2lvbmVkDQp3aXRob3V0IGEgc2lnbmFs aW5nIHByb3RvY29sLCBPcHRpbWl6ZWQgTW9kZSBjYW4gYWxzbyBiZSBhIHBhcmFtZXRlcg0KdG8g YmUgcHJvdmlzaW9uZWQuDQoNClRoZSBhcHByb2FjaCB3ZeKAmXZlIHRha2VuIGluIHRoZSBjdXJy ZW50IGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZS0wOQ0KZG9lcyBhbGxvdyB0aGlzLiBR dWl0ZSBhIGZldyBzZXJ2aWNlIHByb3ZpZGVycyBtYXkgcHJlZmVyIHRvIGNvbnRyb2wNCmFsbCB0 aGVzZSBFLVRyZWUgY29ubmVjdGl2aXR5IGJ5IHRoZW1zZWx2ZXMuDQoNCldoZW4gRS1UcmVlIHNp Z25hbGluZyBwcm90b2NvbCBmb3IgUFdpZCBGRUMgaXMgY29uc2lkZXJlZCwgdGhlIGZvbGxvd2lu Zw0Kb3B0aW9ucyBhcmUgYWxzbyBmZWFzaWJsZToNCg0KYSkgICAgICAgRGlzYWJsZSBPcHRpbWl6 ZWQgbW9kZSBmb3IgRkVDIFBXaWQoMHg4MCksIHRodXMgcm9vdC9sZWFmIHJvbGUNCmNoYW5nZSBp biB0aGUgRS1UcmVlIHRvcG9sb2d5IHdpbGwgbm90IGhhdmUgYW55IGluZmx1ZW5jZSBvbiB0aGUg UFcuDQoNCmIpICAgICAgIEFkZCBhbm90aGVyIGFwcGVuZGl4IGludG8gdGhlIGRvY3VtZW50IGZv ciB0aGUgZnVsbCBzdXBwb3J0IG9mDQpPcHRpbWl6ZWQgbW9kZSB3aXRoIEZFQyBQV2lkKDB4ODAp Lg0KDQpUaGUgaWRlYSBpczogdGhlIFBFIHNlbmRzIGEgbGFiZWwgbWFwcGluZyBmaXJzdGx5IGFu ZCB0aGVuIHNlbmQgYSBsYWJlbA0KcmVxdWVzdCB0byBpdHMgcGVlciBQRXMgKHNvIHRoYXQgdGhl eSB3aWxsIHJlcGx5IHdpdGggYSBsYWJlbCBtYXBwaW5nDQpyZXNwZWN0aXZlbHkpLg0KDQpTaW5j ZSBPcHRpbWl6ZWQgbW9kZSBpcyBhbiBvcHRpb25hbCBwaWVjZSBpbiB0aGUgZG9jdW1lbnQsIEkg d291bGQNCnJlZ2FyZCBvcHRpb24gYSkgYXMgYSBzaW1wbGUgdHJhZGVvZmYgKGFzIEkgYW0gYXdh cmUsIEUtVlBOIGRvZXMgbm90DQpzdXBwb3J0IE9wdGltaXplZCBtb2RlIGZvciBFLVRyZWUgZWl0 aGVyLg0KDQo9PT09PT09PQ0KDQoNClRodXMgd2UgaGF2ZSB0aHJlZSBwcm9wb3NhbHMgb24gdGhl IHRhYmxlOg0KDQoxKSBMZWF2ZSB0aGUgZGVzaWduIGFzIGl0IGlzLCBidXQgYWRkIHRleHQgdG8g ZGVzY3JpYmUgdGhlIGNvbnN0cmFpbnQgYW5kDQp3aGF0IGhhcHBlbnMgaWYgeW91IGhhdmUgdG8g Y2hhbmdlIG1vZGUgYW5kIHdoYXQgdG8gZG8gYWJvdXQgaXQuDQoNCjIpIEV4Y2x1ZGUgb3B0aW1p emF0aW9uIGluIHRoZSBGRUMgUFdpZCgweDgwKSBjYXNlDQoNCjMpIEFkZCBhbiBhcHBlbmRpeCBk ZXNjcmliaW5nIHN1cHBvcnQgZm9yIHRoZSBGRUMgUFdpZCgweDgwKSBjYXNlLg0KDQpNeSBpbmNs aW5hdGlvbiB3b3VsZCBiZSB0byBnbyB3aXRoIG9wdGlvbiAoMSkgYnV0IEkgc2VlayB0aGUgdmll d3Mgb2YNCnRoZSBXRywgYW5kIG9mIGNvdXJzZSBhbnkgY29ycmVjdGlvbnMgaW4gbXkgYW5hbHlz aXMuDQoNCi0gU3Rld2FydA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUGFscyBtYWlsaW5nIGxpc3QNClBhbHNAaWV0Zi5vcmc8bWFpbHRvOlBhbHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BhbHMNCg0K DQo= --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22szxema506mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDEwMkNELjc2ODlEMjMwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpUYXJnZXRTY3JlZW5TaXpl PjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5n cz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERv Y3VtZW50Pg0KPHc6Wm9vbT4xMjA8L3c6Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6 U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3 OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1M SW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50 PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRl eHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFG Lz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1l QXNpYW4+WkgtQ048L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5Y LU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRv Tm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0 UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4NCjx3OkRv bnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25JblR4Yngv Pg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hlZENvbEJhbGFuY2UvPg0KPHc6VXNl RkVMYXlvdXQvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0 SW50ZXJuZXRFeHBsb3JlcjQ8L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFByPg0KPG06bWF0aEZv bnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxt OmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0K PG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIw Ii8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9 IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1 bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRl PSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERl ZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1h bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIxMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExp c3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gTGlzdCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNl IFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2Ui Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Iklu dGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFk aW5nIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0N Ci8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2T Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtYWx0Oj8/wqg/PzsN Cgltc28tZm9udC1jaGFyc2V0OjEzNDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0K CW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTozIDY4MDQ2MDI4 OCAyMiAwIDI2MjE0NSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1hbHQ6IkNhbGlz dG8gTVQiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpy b21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTE2 MTA2MTE5ODUgMTEwNzMwNDY4MyAwIDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWFs dDoiQ2VudHVyeSBHb3RoaWMiOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6LTUyMDA5MjkyOSAxMDczNzg2MTExIDkgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTsN Cgltc28tZm9udC1hbHQ6Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/PzsNCgltc28tZm9u dC1jaGFyc2V0OjEzNDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250 LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTozIDY4MDQ2MDI4OCAyMiAwIDI2 MjE0NSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6LTUyMDA4MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0 eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglt c28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0 LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpz aW5nbGU7fQ0KcHJlDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3Jw aGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5N c29BY2V0YXRlDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsN Cglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OuWui+S9kzt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgs IGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5 bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJbXNvLWNoYXItaW5k ZW50LWNvdW50OjIuMDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk65a6L 5L2TO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byP IENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1sb2NrZWQ6eWVzOw0KCW1zby1zdHls ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cgltc28tYmlkaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk65a6L5L2TOw0KCW1zby1oYW5zaS1mb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZvbnQta2VybmluZzow cHQ7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6 5om55rOo5qGG5paH5pysOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTo5LjBwdDsNCgltc28tYmlkaS1m b250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1hc2NpaS1mb250LWZh bWlseTrlrovkvZM7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk65a6L5L2TOw0KCW1z by1mb250LWtlcm5pbmc6MHB0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhp ZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjVwdDsNCgltc28tYmlkaS1mb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNi4w cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6 5pmu6YCa6KGo5qC8Ow0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1j b2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBj bTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mb250LWtlcm5pbmc6MS4w cHQ7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6MjEuMHB0Ij4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1i aWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlk aS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2UgaGFkIHNvbWUgZGlzY3Vzc2lvbnMgb24gdGhpcyBtZWNoYW5pc20gd2hlbiB0aGUNCiBkb2N1 bWVudCB3YXMgc3RpbGwgYW4gaW5kaXZpZHVhbCBkcmFmdCAoaW4gZmFjdCwgd2hlbiBpdCB3YXMg YmVpbmcgdXBkYXRlZCB0byBkcmFmdC1qaWFuZy1sMnZwbi12cGxzLXBlLWV0cmVlLTAzKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5KdXN0IGxpa2UgU3Rld2FydCwgc29tZSBz ZXJ2aWNlIHByb3ZpZGVycyB3ZXJlIGFsc28NCiBjb25jZXJuZWQgdGhhdCB0aGlzIG1lY2hhbmlz bSBtYXkgcmVzdWx0IGluIGEgZ3JlYXQgd2FzdGUgb2YgcGxhdGZvcm0gbGFiZWxzLiBGb3IgZXhh bXBsZSwgaW4gYSBuZXR3b3JrIHdpdGggb25lIHJvb3QgUEUgYW5kIDEwMDAgbGVhZiBQRXMsIG9u bHkgMTAwMSBQVyBsYWJlbHMgYXJlIG5lZWRlZCBmb3IgdGhlIGFwcHJvYWNoIGluIHRoZSBkb2N1 bWVudDsgYnV0IHdlIHdpbGwgbmVlZCAxMDAwKjk5OS8yPTQ5OTUwMCBQVyBsYWJlbHMgaW4gYWxs DQogZm9yIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20gKHNpbmNlIGxlYWYgdG8gbGVhZiBQV3MgYXJl IHN0aWxsIGFsbG9jYXRlZCkuIFRoYXQgaXMgdGhlIG1haW4gcmVhc29uIHdlIGFkb3B0ZWQgdGhl IGN1cnJlbnQgYXBwcm9hY2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRp LWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmVmb3JlLCBJIHdpbGwgcmVnYXJk IG9wdGlvbiAxKSBhcyB0aGUgZmF2b3JpdGUNCiB3YXkgZm9yd2FyZDogPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDs7Y29sb3I6IzFGNDk3RCI+MSkgTGVhdmUgdGhlIGRlc2lnbiBhcyBpdCBpcywgYnV0IGFk ZCB0ZXh0IHRvIGRlc2NyaWJlDQogdGhlIGNvbnN0cmFpbnQgYW5kPGJyPg0Kd2hhdCBoYXBwZW5z IGlmIHlvdSBoYXZlIHRvIGNoYW5nZSBtb2RlIGFuZCB3aGF0IHRvIGRvIGFib3V0IGl0Ljwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxiciBzdHlsZT0i bXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFbaWYgIXN1cHBvcnRMaW5lQnJl YWtOZXdMaW5lXT48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4N CjwhW2VuZGlmXT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9 kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3aWxsIGJlIGds YWQgdG8gc2VlIG1vcmUgaW5wdXRzIHRvIHRoaXMgdG9waWMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1i aWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlk aS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDttc28tcGFn aW5hdGlvbjpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPll1YW5sb25nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBo O21zby1wYWdpbmF0aW9uOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 O2NvbG9yOmJsYWNrO21zby1uby1wcm9vZjp5ZXMiPjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hh cmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFbaWYgIXN1cHBvcnRMaW5lQnJlYWtOZXdMaW5lXT48YnIg c3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2VuZGlmXT48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tbm8t cHJvb2Y6eWVzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0 OjEuNzVnZCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTGl6 aG9uZw0KIEppbiBbbWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb21dIDxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIE9jdG9iZXIgMDUsIDIwMTUgMTowNSBQTTxicj4NCjxiPlRvOjwvYj4gU3Rld2Fy dCBCcnlhbnQgKHN0YnJ5YW50KTxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1sMnZwbi12cGxz LXBlLWV0cmVlQHRvb2xzLmlldGYub3JnOyBwYWxzQGlldGYub3JnOyBwYWxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1BhbHNdIGRyYWZ0LWlldGYtbDJ2 cG4tdnBscy1wZS1ldHJlZSAtIHBvc3NpYmxlIHdheXMgZm9yd2FyZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIx LjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxzcGFu IGxhbmc9IkVOLVVTIj5IaSBTdGV3YXJ0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1h cmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciBEVSBtb2RlLCBpZiBGRUMg aXMgY3JlYXRlZCwgdGhlbiBsYWJlbCBzaG91bGQgYmUgYWxsb2NhdGVkLiBGb3IgdGhlIHZ1bG5l cmFiaWxpdHkgeW91IG1lbnRpb25lZCwgaWYgSSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24gY29y cmVjdGx5LCB0aGUgUFcgbGFiZWwgd2lsbCBub3QNCiBiZSBwcm9ncmFtbWVkIGludG8gaGFyZHdh cmUsIGJ1dCBvbmx5IGtlcHQgaW4gY29udHJvbCBwbGFuZS4gU28gdGhlIHBhY2tldCB3aWxsIG5v dCBiZSB3cm9uZ2x5IHByb2Nlc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBNVFUgaW50ZXJm YWNlIFN1Yi1UTFYgZGVmaW5lZCBpbiBSRkM0NDQ3IHNlY3Rpb24gNi40IHNhaWQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEu MHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5JZiB0aGlzIHBhcmFtZXRlciBkb2VzIG5v dCBtYXRjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5pbiBi b3RoIGRpcmVjdGlvbnMgb2YgYSBzcGVjaWZpYyBQVywgdGhhdCBQVyBNVVNUIE5PVCBiZSBlbmFi bGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIG1lY2hhbmlzbSBJIHByb3Bvc2VkIGlzIHdoYXQgaGF2ZSBi ZWVuIGRvbmUgZm9yIE1UVSBpbnRlcmZhY2Ugc3ViLVRMVi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43 NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4w cHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+TGl6aG9u ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1s ZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgT2N0IDUsIDIwMTUgYXQgMjox OSBBTSwgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0YnJ5 YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0YnJ5YW50QGNpc2NvLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLW1hcmdpbi10b3AtYWx0 OjBjbTttc28tcGFyYS1tYXJnaW4tcmlnaHQ6MGNtO21zby1wYXJhLW1hcmdpbi1ib3R0b206MTIu MHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjIx LjBwdDttc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21zby1wYXJhLW1hcmdpbi1yaWdodDowY207bXNv LXBhcmEtbWFyZ2luLWJvdHRvbToxMi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj4N CjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpPbiA0IE9jdCAyMDE1LCBhdCAxNjo0MywgTGl6aG9u ZyBKaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpsaXpoby5qaW5AZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bGl6aG8uamluQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2lu LWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgU3Rld2FydCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuIFRoaXMgaXMgYSBsb25nIGVtYWlsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3Bh biBsYW5nPSJFTi1VUyI+WW91IGdpdmUgdXMgdGhyZWUgb3B0aW9uczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48YnI+DQoxKSBMZWF2ZSB0aGUgZGVzaWduIGFz IGl0IGlzLCBidXQgYWRkIHRleHQgdG8gZGVzY3JpYmUgdGhlIGNvbnN0cmFpbnQgYW5kPGJyPg0K d2hhdCBoYXBwZW5zIGlmIHlvdSBoYXZlIHRvIGNoYW5nZSBtb2RlIGFuZCB3aGF0IHRvIGRvIGFi b3V0IGl0Ljxicj4NCjxicj4NCjIpIEV4Y2x1ZGUgb3B0aW1pemF0aW9uIGluIHRoZSZuYnNwO0ZF QyBQV2lkKDB4ODApIGNhc2U8YnI+DQo8YnI+DQozKSBBZGQgYW4gYXBwZW5kaXggZGVzY3JpYmlu ZyBzdXBwb3J0IGZvciB0aGUmbmJzcDtGRUMgUFdpZCgweDgwKSBjYXNlLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4t bGVmdDoxLjc1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwO1RoZW4gSSBwcmVmZXIgb3B0aW9uIDEuIEJlY2F1c2Ugb3B0aW9uMiBpcyBub3QgcmVh c29uYWJsZSwgYW5kIHRoZSBzb2x1dGlvbiBpbiBvcHRpb24zIHByb3ZpZGVkIGJ5IHRoZSBhdXRo b3IgaXMgbm90IHRoZSBiZXN0IG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBs YW5nPSJFTi1VUyI+SSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgb3BpdGlvbjQgZm9yIFdHIHRvIGNv bnNpZGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6 MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+NCkmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5BZGQgZGVzY3JpcHRpb24gdG8gc3VwcG9ydCBm b3IgdGhlJm5ic3A7RkVDIFBXaWQoMHg4MCkgY2FzZSwgaW4gYXBwZW5kaXggb3IgdGV4dCBJIGRv bid0IGNhcmUuIFRoZSBzb2x1dGlvbiBpczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmxhYmVsIHJlbGVhc2UgbWVzc2FnZSBzaG91 bGQgbm90IGJlIHNlbnQgaW4gc2VjdGlvbiA2LjEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDtt c28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkZvciBQVyBzaWduYWxpbmcsIHRoZSB1bmFjY2VwdGFibGUg b2YgYW55IEludGVyZmFjZSBQYXJhbWV0ZXIgd2lsbCBub3QgbGVhZCB0byBhbnkgPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmxhYmVsIHJlbGVhc2UsIGJ1 dCBqdXN0IHNpbXBseSBsZXQgdGhlIFBXIGRvd24gaW4gZm9yd2FyZGluZyBwbGFuZS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1s ZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxpc3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6 MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+RG9lc24ndCB0aGF0IHdhc3RlIGxhYmVscywgd2hp Y2ggbWF5IGJlIGEgcHJvYmxlbSBpbiBzb21lIHN5c3RlbXMsIGFuZCBjcmVhdGUgYSB2dWxuZXJh YmlsaXR5IHNpbmNlIHNvbWVvbmUgbWF5IHNlbmQgYSBwYWNrZXQgd2l0aCB0aGF0IGxhYmVsIHdo aWNoIHdvdWxkIGJlIHByb2Nlc3NlZA0KIGFuZCBzZW50IG91dCBvZiB0aGUgcGVyc29uIGVncmVz cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVn ZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tU3Rld2FydDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsi Pg0KPCFbaWYgIXN1cHBvcnRMaW5lQnJlYWtOZXdMaW5lXT48YnIgc3R5bGU9Im1zby1zcGVjaWFs LWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48 c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNv LXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+TGl6aG9uZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFy YS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQgI0ND Q0NDQyAuNzVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2Q7bXNvLW91dGxpbmUtbGV2ZWw6MSI+ DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAt LS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnN0YnJ5YW50QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0YnJ5YW50QGNpc2NvLmNv bTwvYT4mZ3Q7PGJyPg0KVG86Jm5ic3A7JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt bDJ2cG4tdnBscy1wZS1ldHJlZUB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0 LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZUB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWVAdG9vbHMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWVAdG9vbHMu aWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86cGFsc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnBhbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86cGFsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhbHNAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCkNjOiZuYnNwOyZxdW90OzxhIGhyZWY9Im1haWx0bzpwYWxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cGFscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6Jm5i c3A7RnJpLCAyIE9jdCAyMDE1IDE2OjQxOjA1ICYjNDM7MDEwMDxicj4NClN1YmplY3Q6Jm5ic3A7 W1BhbHNdIGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZSAtIHBvc3NpYmxlIHdheXMgZm9y d2FyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNw YW4gbGFuZz0iRU4tVVMiPkkgYW0gc29ycnkgdGhhdCB0aGlzIGlzIGEgbG9uZyBlbWFpbCwgYnV0 IEkgd2FudGVkIHRvIGNvbGxlY3QgdGhlDQo8YnI+DQpmYWN0cyB0b2dldGhlciBpbiBvbmUgcGxh Y2UgYW5kIHNldCBvdXQgdGhlIGNvbXBsZXRlIHNjZW5lIHRvIDxicj4NCnRoZSBQQUxTIFdHLjxi cj4NCjxicj4NClRoZSBjcml0aWNhbCBjb25jZXJuIGlzIGNvbnRhaW5lZCBpbiB0aGUgZm9sbG93 aW5nIGVtYWlsIGZyYWdtZW50PGJyPg0KZnJvbSBMaXpob25nOjxicj4NCjxicj4NCj09PT09PT08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjQyLjBwdDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+ SW4gUkZDNDQ0NyBhbmQgNDQ0N2JpcywgaXQgY2xlYXJseSBzYWlkOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1h cmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPlVzaW5nIHRoZSBQV2lkIEZFQywgZWFjaCBvZiB0aGUgdHdvIHBzZXVk b3dpcmUgZW5kcG9pbnRzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4t bGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW5kZXBlbmRlbnRseSBpbml0aWF0ZXMgdGhlIHNldHVw IG9mIGEgdW5pZGlyZWN0aW9uYWwgTFNQLiZuYnNwOyZuYnNwOyBBbjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG91dGdvaW5n IExTUCBhbmQgYW4gaW5jb21pbmcgTFNQIGFyZSBib3VuZCB0b2dldGhlciBpbnRvIGEgc2luZ2xl PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgcHNldWRvd2lyZSBpZiB0aGV5IGhhdmUgdGhlIHNhbWUgUFcgSUQgJm5ic3A7YW5k IFBXIHR5cGUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoz LjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrIj5UaGUgYmVoYXZpb3IgaXMgYSBjb3JyZWN0IGRlc2NyaXB0aW9uIGZvciBMRFAtRFUgbW9k ZSB3aGljaCBQVyBhcHBsaWVzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFy Z2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+QW5kIHRoYXQgaXMgYWxzbyB0aGUgYmVoYXZpb3IgbW9zdCB2ZW5kb3Jz IGltcGxlbWVudC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0 OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxl ZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjpibGFjayI+VGhlbiBpbiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMyMjIyMjIiPmRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZS0wOSwg aXQgc2F5czo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMu NWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPiBBIFBFIHRoYXQgcmVjZWl2ZXMgYSBQVyBsYWJlbCBtYXBwaW5nIG1lc3NhZ2Ugd2l0aCBh biBFLVRyZWUgU3ViLVRMVjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2lu LWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZyb20gaXRzIHBlZXIgUEUsIGFmdGVyIHNhdmluZyB0 aGUgVkxBTiBpbmZvcm1hdGlvbiBmb3IgdGhlIFBXLCBNVVNUPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQy LjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcHJvY2VzcyBpdCBh cyBmb2xsb3dzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6 My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+Li4uLi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0 OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPjMpIElmIHRoZSBQIGJpdCBpcyBzZXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21z by1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7 bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2Qi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElm IHRoZSBQRSBpcyBhIGxlYWYtb25seSBub2RlIGl0c2VsZiwgYSBsYWJlbCByZWxlYXNlIG1lc3Nh Z2U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoIGEgc3RhdHVzIGNvZGUgJnF1b3Q7TGVh ZiB0byBMZWFmIFBXIHJlbGVhc2VkJnF1b3Q7IGlzIHNlbnQgdG8gdGhlIHBlZXI8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBQRSBhbmQgZXhpdCB0aGUgcHJvY2Vzczs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVsc2UgdGhlIFBFIFNIT1VMRCBz ZXQgdGhlIE9wdGltaXplZC1Nb2RlIHRvIFRSVUUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDtt c28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0 O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5U aGF0IG1lYW5zLCBpZiBQRTEgcmVjZWl2aW5nIGEgbGFiZWwgbWFwcGluZyBmcm9tIFBFMiB3aXRo IFAgYml0IHNldCwgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVm dDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrIj5QRTEgd2lsbCBzZW5kIGxhYmVsIHJlbGVhc2UuIFRoZW4gUEUyIHdpbGwgbmV2ZXIg c2VuZCBsYWJlbCBtYXBwaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJn aW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOmJsYWNrIj5hZ2FpbiB0byBQRTEgZXZlbiB3aGVuIFBFMSBjaGFuZ2VzIGZyb20gPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5s ZWFmLW9ubHkgbm9kZSB0byByb290LWxlYWYgbm9kZS4gRm9yIExEUC1EVTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5tb2RlLCBQRTIgd2lsbCBub3Qgc2Vu ZCBsYWJlbCBtYXBwaW5nIGFnYWluIHdoZW4gcmVjZWl2aW5nIFBFMSdzIGxhYmVsIG1hcHBpbmcu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZW4gdGhl IFBXIHdpbGwgbm90IGJlIHNldHVwIHN1Y2Nlc3NmdWxseS4gVGhlbiBvbmx5IHdheSBpcyB0byBj b25maWd1cmUgdGhlIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxl ZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5zYW1lIFBXIG9uIFBFMiBhZ2Fpbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+VGhlIGNvcnJlY3QgYmVoYXZpb3IgaXMsIGxhYmVsIHJlbGVhc2Ug bWVzc2FnZSBzaG91bGQgbm90IGJlIHNlbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28t cGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkZvciBQVyBzaWduYWxpbmcsIHRoZSB1bmFjY2VwdGFibGUgb2Yg YW55IEludGVyZmFjZSBQYXJhbWV0ZXIgd2lsbCBub3QgbGVhZCB0byBhbnkgPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmxhYmVsIHJlbGVhc2UsIGJ1dCBq dXN0IHNpbXBseSBsZXQgdGhlIFBXIGRvd24gaW4gZm9yd2FyZGluZyBwbGFuZS48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjIxLjBwdDttc28tbWFyZ2luLXRvcC1hbHQ6 MGNtO21zby1wYXJhLW1hcmdpbi1yaWdodDowY207bXNvLXBhcmEtbWFyZ2luLWJvdHRvbToxMi4w cHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj49PT09 PT09PTxicj4NCjxicj4NCkFuZHkgbG9va2VkIGF0IHRoaXMgZnJvbSB0aGUgcG9pbnQgb2Ygdmll dyBvZiB0aGUgTUVGIGFuZCBub3RlcyBpbjxicj4NCnByaXZhdGUgY29udmVyc2F0aW9uOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0i RU4tVVMiPj09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFy Z2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlIEUtdHJlZSBzZXJ2aWNl IGFzIGRlZmluZWQgYnkgTUVGLCB5b3UgY2FuIGhhdmUgb25lIG9yIG1vcmUgcm9vdHMNCjxicj4N CmFuZCBvbmUgb3IgbW9yZSBsZWFmcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBs YW5nPSJFTi1VUyI+SW4gYSBzaW5nbGUgRS10cmVlIHNlcnZpY2UgKHRoaW5rIG9mIGEgbXVsdGlw b2ludCBQVyB3aXRoIHNvbWUgb2YgdGhlIENFcw0KPGJyPg0KY29uZmlndXJlZCBhcyByb290cyBh cyBzb21lIGFzIGxlYWZzKSwgYWxsIGxlYWZzIGFuZCByb290cyByZWNlaXZlIGZyYW1lcyA8YnI+ DQpzZW50IGJ5IHRoZSByb290cy4gQWxsIHJvb3RzIHJlY2VpdmUgZnJhbWVzIHNlbnQgYnkgdGhl IGxlYWZzLiBIb3dldmVyLCA8YnI+DQpsZWFmcyBtYXkgbm90IHJlY2VpdmUgYW55IGZyYW1lcyBz ZW50IGJ5IG90aGVyIGxlYWZzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEt bWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGUgZHJhZnQsIGFzIHdyaXR0ZW4sIGRvZXNuJ3QgYnJpbmcgdXAgYW4gdW5kZXJs eWluZyBwdC10by1wdCBQV3MgdG8NCjxicj4NCmNhcnJ5IGZyYW1lcyBmb3IgdGhlIHNlcnZpY2Ug YmV0d2VlbiBQRXMgdGhhdCBvbmx5IGhhdmUgbGVhZnMgYXR0YWNoZWQuIDxicj4NClNpbmNlIHRo ZSBsZWFmcyBjYW4ndCBzZW50IGZyYW1lcyB0byBlYWNoIG90aGVyLCB0aGF0IGlzIGFuIGVjb25v bWljYWwgPGJyPg0KdXNlIG9mIFBXcyBpbiB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6 MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+TGl6aG9uZydzIHBvaW50IGlzIHRoYXQgdGhpcyBt YWtlcyBpdCBpbXBvc3NpYmxlIHRvIGFkZCBhIG5ldyByb290IHRvDQo8YnI+DQphbiBleGlzdGlu ZyBQRSBpbiBhbiBFLXRyZWUgdGhhdCBwcmV2aW91c2x5IG9ubHkgaGFkIGxlYWZzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLW1h cmdpbi10b3AtYWx0OjBjbTttc28tcGFyYS1tYXJnaW4tcmlnaHQ6MGNtO21zby1wYXJhLW1hcmdp bi1ib3R0b206MTIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+SSBhZ3JlZSB0aGF0IHdvdWxkIGJlIGEgcHJvYmxlbSBpZiB0aGVyZSB3YXMgYSBy ZXF1aXJlbWVudCB0byBtb2RpZnkNCjxicj4NCmFuIGV4aXN0aW5nIEUtdHJlZSBzZXJ2aWNlLiBI b3dldmVyLCB0aGlzIGRyYWZ0IGhhcyBubyBvdGhlciBtZWNoYW5pc21zIDxicj4NCnRvIGV4cGxp Y2l0bHkgc3VwcG9ydCBFLXRyZWUgbW9kaWZpY2F0aW9uLCBub3IgaXMgc3VjaCBtb2RpZmljYXRp b24gYSA8YnI+DQpyZXF1aXJlbWVudCBvZiB0aGUgdW5kZXJseWluZyBNRUYgc3BlY2lmaWNhdGlv bi4gQlRXLCBzaW5jZSB0aGlzIHdvcmsgPGJyPg0Kd2FzIHN0YXJ0ZWQsIHRoZSBNRUYgcmVwbGFj ZWQgTUVGIDYuMSB3aXRoIE1FRiA2LjIsICZxdW90O0VWQyBFdGhlcm5ldCA8YnI+DQpTZXJ2aWNl cyBEZWZpbml0aW9ucyBQaGFzZSAzJnF1b3Q7LCBBdWd1c3QsIDIwMTQsIGFuZCB0aGF0IHJlZmVy ZW5jZSBzaG91bGQgPGJyPg0KYmUgdXBkYXRlZCBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1s ZWZ0OjIxLjBwdDttc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21zby1wYXJhLW1hcmdpbi1yaWdodDow Y207bXNvLXBhcmEtbWFyZ2luLWJvdHRvbToxMi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43 NWdkIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5NeSBvcGluaW9uIGlzIHRoYXQgdGhlIGRyYWZ0IGFz IGl0IHN0YW5kcyBpcyB0ZWNobmljYWxseSBjb3JyZWN0IGlmIHlvdQ0KPGJyPg0KZG9uJ3QgbmVl ZCB0aGUgYWJpbGl0eSB0byByZWNvbmZpZ3VyZSBhbiBleGlzdGluZyBFLXRyZWUgc2VydmljZSBk eW5hbWljYWxseS48YnI+DQo8YnI+DQo9PT09PT09PT09PGJyPg0KPGJyPg0KTm93IHdoaWxzdCBJ IGNhbiBzdXBwb3J0IHRoZSBpZGVhIHRoYXQgZHluYW1pYyByZWNvbmZpZ3VyYXRpb24gb2Y8YnI+ DQpFLXRyZWUgaXMgbm90IG5lZWRlZCwgSSBoYXZlIGEgY29uY2Vybi48YnI+DQo8YnI+DQpNeSB1 bmRlcnN0YW5kaW5nIHRoZSB0ZXh0IGluIHF1ZXN0aW9uIGlzIHRoYXQgaXQgaXMgc2F5aW5nIHRo YXQgaWYgPGJyPg0KQSBpcyBjb25maWd1cmVkIGFzIGxlYWYgb25seSwgYW5kIEIgd2hpY2ggaXMg YWxzbyBjb25maWd1cmVkIGFzPGJyPg0KbGVhZiBvbmx5IGF0dGVtcHRzIHRvIGNvbmZpZ3VyZSBh IFBXIGJldHdlZW4gdGhlbSwgdGhlbiBBIHJlamVjdHMgPGJyPg0KdGhlIFBXIHNldHVwLjxicj4N Cjxicj4NClRoYXQgc291bmRzIHZlcnkgcmVhc29uYWJsZSB0byBtZSwgc2luY2UgdGhlcmUgaXMg YSBtaXNjb25maWcuPGJyPg0KPGJyPg0KSWYgQSBkaWQgbm90IGRvIHRoZSByZWplY3QsIHRoZW4g QiB3b3VsZCBmb3JldmVyIGJlIGNvbnN1bWluZzxicj4NCnJlc291cmNlIHdhaXRpbmcgZm9yIEEg YW5kIEIgd291bGQgaGF2ZSBubyBpZGVhIG9mIHRoZTxicj4NCm1pc2NvbmZpZy4gVGhhdCBhY2Nv cmRzIHdpdGggQW5keSdzIHZpZXcgYWJvdmUuPGJyPg0KPGJyPg0KSG93ZXZlciBJIHdhcyB3b3Jy aWVkIHdoYXQgd291bGQgaGFwcGVuIGlmIEEgd2FzIG1pc2NvbmZpZ3VyZWQ8YnI+DQphcyBsZWFm IG9ubHkgYW5kIHRoZSBjb25maWd1cmF0aW9uIHdhcyBjb3JyZWN0ZWQgdG8gcm9vdC1sZWFmLjxi cj4NCldoYXQgd291bGQgaW4gbXkgdmlldyBiZSBkaWZmaWN1bHQgdG8gYWNjZXB0IHdhcyB0aGUg bmVlZCB0bzxicj4NCnRha2UgYSBodW1hbiwgb3IgTk1TIGFjdGlvbiBhdCBCIHRvIHJlY292ZXIg dGhlIHNpdHVhdGlvbi48YnI+DQpIb3dldmVyIHByb3ZpZGVkIHRoYXQgQSBjbG9zZWQgdGhlIExE UCBzZXNzaW9uIHdpdGggQiA8YnI+DQphbmQgcmUtaW5zdGF0ZSBpdCBCIHdvdWxkIHRoZW4gc2Vu ZCB0aGUgbWFwcGluZyBtZXNzYWdlIGFnYWluLjxicj4NClRodXMgdGhlIHN5c3RlbSBpcyByZWNv dmVyYWJsZSB3aXRob3V0IG5lZWRpbmcgdG8gdmlzaXQgQiB3aGljaDxicj4NCmlzIGluIG15IG1p bmQgYSBmdW5kYW1lbnRhbCByZXF1aXJlbWVudCBzaW5jZSBBIGNvdWxkIGhhdmU8YnI+DQpnb3Qg aW50byB0aGUgd3JvbmcgbW9kZSBhcyBhIHJlc3VsdCBvZiBhbiBlcnJvci48YnI+DQo8YnI+DQpU aGUgcHJvYmxlbSBJIHNlZSBpcyBpZiBBIGhhcyBhIGJ1bmNoIG9mIG90aGVyIFBXcyB3aXRoIEI8 YnI+DQp0aGV5IHdpbGwgZ2V0IHRvcm4gZG93biBpbiBvcmRlciBmb3IgQSB0byBoYXZlIHRoZSBj b25maWcgZXJyb3I8YnI+DQpmaXhlZC4gSG93ZXZlciBpZiB0aGF0IGlzIGEgcHJvYmxlbSB5b3Ug bmVlZCB0d28gTERQIHNlc3Npb25zPGJyPg0KYmV0d2VlbiBBIGFuZCBCLCBvbmUgZm9yIEwyVlBO IGFuZCBvbmUgZm9yIHJlZ3VsYXIgUFdzLjxicj4NCjxicj4NCk15IGluY2xpbmF0aW9uIGlzIHRo YXQgdGhlIGRyYWZ0IGlzIGJhc2ljYWxseSBjb3JyZWN0LCBhbmQgdGhhdCB3aGlsc3Q8YnI+DQpM aXpob25nIGlzIGNvcnJlY3QgdGhhdCB0aGUgUFcgd2lsbCBub3QgY29tZSB1cCB3aXRob3V0IHNv bWU8YnI+DQphY3Rpb24sIHJlY29uZmlndXJpbmcgdGhlIFBXIG9uIEIgaXMgbm90IHRoZSBvbmx5 IGFjdGlvbjxicj4NCnRoYXQgd2lsbCBjYXVzZSB0aGUgUFcgdG8gY29tZSB1cC4gPGJyPg0KPGJy Pg0KU28gdGhpcyBjb21lcyBkb3duIHRvIGEgV0cgZGVjaXNpb24gaW4gdGVybXMgb2Ygd2hpY2gg aXMgdGhlPGJyPg0KbGVhc3QgdW5hY2NlcHRhYmxlIGJlaGF2aW91ciAtIEEgaGF2aW5nIHRvIHJl LWN5Y2xlIHRoZSBMRFA8YnI+DQpzZXNzaW9uLCBvciBCIHdhc3RpbmcgcmVzb3VyY2VzLiBJIHRo aW5rIEkgcHJlZmVyIHRoZSBiZWhhdmlvdXI8YnI+DQpwcm9wb3NlZCBpbiB0aGUgZHJhZnQuPGJy Pg0KPGJyPg0KQSB3YXkgZm9yd2FyZCBpcyB0byBsZWF2ZSB0aGUgbG9naWMgYXMgd3JpdHRlbiBp biB0aGUgZHJhZnQsIGJ1dCB0byA8YnI+DQphZGQgdGV4dCBkZXNjcmliaW5nIHRoZSBiYXNpcyBm b3IgZXhjbHVkaW5nIGR5bmFtaWMgcmUtY29uZmlndXJhdGlvbjxicj4NCmFzIGEgbm9ybWFsIG9w ZXJhdGlvbmFsIG1vZGUgYW5kIHRvIG5vdGUgdGhlIGFjdGlvbnMgdGhhdCBuZWVkIDxicj4NCnRv IGJlIHRha2VuIHdoZW4gcmUtY29uZmlndXJhdGlvbiBpcyBmb3JjZWQgZm9yIHNvbWUgcmVhc29u Ljxicj4NCjxicj4NCldoaWxzdCB3ZSB3ZXJlIHBvbmRlcmluZyB3aGF0IGRvIHdpdGggdGhlIHRl eHQgdGhlIGNoYWlyczxicj4NCmFuZCBBRCByZWNlaXZlZCBhbm90aGVyIHByb3Bvc2FsIGZyb20g dGhlIGF1dGhvcnM6PGJyPg0KPGJyPg0KPT09PT09PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SW4gZ2VuZXJhbCwgRkVDIFBXaWQo MHg4MCkgaXMgdXNlZCBpbiBWUExTIHdpdGggbWFudWFsIHByb3Zpc2lvbmluZywNCjxicj4NCndo aWxlIEdlbmVyYWxpemVkIFBXaWQgKDB4ODEpIGlzIHVzZWQgd2l0aCBhdXRvLWRpc2NvdmVyeS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPkFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDUu MiwgVkxBTiBtYXBwaW5nIHBhcmFtZXRlcnMgY2FuIGJlIHByb3Zpc2lvbmVkDQo8YnI+DQp3aXRo b3V0IGEgc2lnbmFsaW5nIHByb3RvY29sLCBPcHRpbWl6ZWQgTW9kZSBjYW4gYWxzbyBiZSBhIHBh cmFtZXRlciA8YnI+DQp0byBiZSBwcm92aXNpb25lZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQiPlRoZSBhcHByb2FjaCB3ZeKAmXZlIHRha2VuIGluIHRoZSBjdXJyZW50IGRyYWZ0LWll dGYtbDJ2cG4tdnBscy1wZS1ldHJlZS0wOQ0KPGJyPg0KZG9lcyBhbGxvdyB0aGlzLiBRdWl0ZSBh IGZldyBzZXJ2aWNlIHByb3ZpZGVycyBtYXkgcHJlZmVyIHRvIGNvbnRyb2w8YnI+DQphbGwgdGhl c2UgRS1UcmVlIGNvbm5lY3Rpdml0eSBieSB0aGVtc2VsdmVzLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+V2hlbiBFLVRyZWUgc2lnbmFsaW5nIHByb3RvY29sIGZvciBQV2lkIEZFQyBp cyBjb25zaWRlcmVkLCB0aGUgZm9sbG93aW5nDQo8YnI+DQpvcHRpb25zIGFyZSBhbHNvIGZlYXNp YmxlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+YSk8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdCI+RGlzYWJsZSBPcHRpbWl6ZWQgbW9kZSBmb3IgRkVDIFBXaWQoMHg4MCksIHRodXMgcm9v dC9sZWFmIHJvbGUNCjxicj4NCmNoYW5nZSBpbiB0aGUgRS1UcmVlIHRvcG9sb2d5IHdpbGwgbm90 IGhhdmUgYW55IGluZmx1ZW5jZSBvbiB0aGUgUFcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0Ij5iKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5BZGQgYW5vdGhlciBhcHBlbmRpeCBpbnRv IHRoZSBkb2N1bWVudCBmb3IgdGhlIGZ1bGwgc3VwcG9ydCBvZg0KPGJyPg0KT3B0aW1pemVkIG1v ZGUgd2l0aCBGRUMgUFdpZCgweDgwKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxi cj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlRo ZSBpZGVhIGlzOiB0aGUgUEUgc2VuZHMgYSBsYWJlbCBtYXBwaW5nIGZpcnN0bHkgYW5kIHRoZW4g c2VuZCBhIGxhYmVsDQo8YnI+DQpyZXF1ZXN0IHRvIGl0cyBwZWVyIFBFcyAoc28gdGhhdCB0aGV5 IHdpbGwgcmVwbHkgd2l0aCBhIGxhYmVsIG1hcHBpbmcgPGJyPg0KcmVzcGVjdGl2ZWx5KS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlNpbmNlIE9wdGltaXplZCBtb2RlIGlzIGFuIG9w dGlvbmFsIHBpZWNlIGluIHRoZSBkb2N1bWVudCwgSSB3b3VsZA0KPGJyPg0KcmVnYXJkIG9wdGlv biBhKSBhcyBhIHNpbXBsZSB0cmFkZW9mZiAoYXMgSSBhbSBhd2FyZSwgRS1WUE4gZG9lcyBub3Qg PGJyPg0Kc3VwcG9ydCBPcHRpbWl6ZWQgbW9kZSBmb3IgRS1UcmVlIGVpdGhlci48YnI+DQo8YnI+ DQo9PT09PT09PTxicj4NCjxicj4NCjxicj4NClRodXMgd2UgaGF2ZSB0aHJlZSBwcm9wb3NhbHMg b24gdGhlIHRhYmxlOjxicj4NCjxicj4NCjEpIExlYXZlIHRoZSBkZXNpZ24gYXMgaXQgaXMsIGJ1 dCBhZGQgdGV4dCB0byBkZXNjcmliZSB0aGUgY29uc3RyYWludCBhbmQ8YnI+DQp3aGF0IGhhcHBl bnMgaWYgeW91IGhhdmUgdG8gY2hhbmdlIG1vZGUgYW5kIHdoYXQgdG8gZG8gYWJvdXQgaXQuPGJy Pg0KPGJyPg0KMikgRXhjbHVkZSBvcHRpbWl6YXRpb24gaW4gdGhlIEZFQyBQV2lkKDB4ODApIGNh c2U8YnI+DQo8YnI+DQozKSBBZGQgYW4gYXBwZW5kaXggZGVzY3JpYmluZyBzdXBwb3J0IGZvciB0 aGUgRkVDIFBXaWQoMHg4MCkgY2FzZS48YnI+DQo8YnI+DQpNeSBpbmNsaW5hdGlvbiB3b3VsZCBi ZSB0byBnbyB3aXRoIG9wdGlvbiAoMSkgYnV0IEkgc2VlayB0aGUgdmlld3Mgb2Y8YnI+DQp0aGUg V0csIGFuZCBvZiBjb3Vyc2UgYW55IGNvcnJlY3Rpb25zIGluIG15IGFuYWx5c2lzLjxicj4NCjxi cj4NCi0gU3Rld2FydDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0 OjIxLjBwdDttc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21zby1wYXJhLW1hcmdpbi1yaWdodDowY207 bXNvLXBhcmEtbWFyZ2luLWJvdHRvbToxMi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdk Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NClBhbHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOlBhbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5QYWxzQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFscyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFs czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2lu LWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22szxema506mbschi_-- From nobody Fri Oct 9 05:34:55 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0240E1B3B6D for ; Fri, 9 Oct 2015 05:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zHztm_40xxE for ; Fri, 9 Oct 2015 05:34:45 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B9F1B3B68 for ; Fri, 9 Oct 2015 05:34:44 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so66146838wic.1 for ; Fri, 09 Oct 2015 05:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=RJTNDi/l52sM2tfOXkVfIyarn4WKx5JGiupa51FsVb0=; b=Bau65MFqK0AH1Kyrt+VW6uxNOu3rTfvDPPV5v6osbGRRFbUUcDWhgRdrD+okSgRsiM hJ94frLDWfk1EvHTlRatK7RmY2H2IPAaJsozMWL3epInTYuaf8kTB6tfbGPTMziINlVw kNfsMqZr8zu26pCiWlOoBkLfOkuIuAEseX2f0S/hFXba0E/4yRbO8dbeWCrbTuAstfOe 55rx3n+DymW2z3CFv/nk2jsOV6/0JgEJ8SEwxfR4IWk6b1V2oBTaekW36YXLG7cAiqUC P9ES1rXBuU0Izvb0HT09ur/STQq4ot8isdISeqrxob0l0/PmljZ/J4869DF9ON1+D8lf g0eQ== X-Received: by 10.194.184.20 with SMTP id eq20mr14326808wjc.22.1444394082922; Fri, 09 Oct 2015 05:34:42 -0700 (PDT) Received: from [64.103.106.105] (dhcp-bdlk10-data-vlan300-64-103-106-105.cisco.com. [64.103.106.105]) by smtp.gmail.com with ESMTPSA id x9sm1853535wjf.44.2015.10.09.05.34.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 05:34:41 -0700 (PDT) To: Jiangyuanlong , Lizhong Jin , "Stewart Bryant (stbryant)" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22@szxema506-mbs.china.huawei.com> From: Stewart Bryant Message-ID: <5617B468.2020100@gmail.com> Date: Fri, 9 Oct 2015 13:34:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22@szxema506-mbs.china.huawei.com> Content-Type: multipart/alternative; boundary="------------010206030601090505020109" Archived-At: Cc: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 12:34:54 -0000 This is a multi-part message in MIME format. --------------010206030601090505020109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit From my perspective, and with due regard as to where we are, option one is the one that I would prefer to move things along. That would not preclude us introducing another RFC at a later date if there are further operational considerations or alternatives that there is a consensus to support. Do we have consensus to move forward with option 1? Stewart On 09/10/2015 13:02, Jiangyuanlong wrote: > > Hi all, > > We had some discussions on this mechanism when the document was still > an individual draft (in fact, when it was being updated to > draft-jiang-l2vpn-vpls-pe-etree-03). > > Just like Stewart, some service providers were also concerned that > this mechanism may result in a great waste of platform labels. For > example, in a network with one root PE and 1000 leaf PEs, only 1001 PW > labels are needed for the approach in the document; but we will need > 1000*999/2=499500 PW labels in all for the proposed mechanism (since > leaf to leaf PWs are still allocated). That is the main reason we > adopted the current approach. > > Therefore, I will regard option 1) as the favorite way forward: > > 1) Leave the design as it is, but add text to describe the constraint and > what happens if you have to change mode and what to do about it. > > I will be glad to see more inputs to this topic. > > Thanks, > > Yuanlong > > > > *From:*Lizhong Jin [mailto:lizho.jin@gmail.com] > *Sent:* Monday, October 05, 2015 1:05 PM > *To:* Stewart Bryant (stbryant) > *Cc:* draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org; pals@ietf.org; > pals-chairs@tools.ietf.org > *Subject:* Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways > forward > > Hi Stewart, > > For DU mode, if FEC is created, then label should be allocated. For > the vulnerability you mentioned, if I understand your question > correctly, the PW label will not be programmed into hardware, but only > kept in control plane. So the packet will not be wrongly processed. > > The MTU interface Sub-TLV defined in RFC4447 section 6.4 said: > > If this parameter does not match > in both directions of a specific PW, that PW MUST NOT be enabled. > > The mechanism I proposed is what have been done for MTU interface sub-TLV. > > Regards > > Lizhong > > On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) > > wrote: > > > On 4 Oct 2015, at 16:43, Lizhong Jin > wrote: > > Hi Stewart, > > Thanks for the comment. This is a long email. > > You give us three options: > > > 1) Leave the design as it is, but add text to describe the > constraint and > what happens if you have to change mode and what to do about it. > > 2) Exclude optimization in the FEC PWid(0x80) case > > 3) Add an appendix describing support for the FEC PWid(0x80) case. > > Then I prefer option 1. Because option2 is not reasonable, and > the solution in option3 provided by the author is not the best one. > > I would like to provide opition4 for WG to consider: > > 4) Add description to support for the FEC PWid(0x80) case, in > appendix or text I don't care. The solution is: > > label release message should not be sent in section 6.1. > > For PW signaling, the unacceptable of any Interface Parameter will > not lead to any > > label release, but just simply let the PW down in forwarding plane. > > Listing > > Doesn't that waste labels, which may be a problem in some systems, and > create a vulnerability since someone may send a packet with that label > which would be processed and sent out of the person egress. > > -Stewart > > > > Regards > > Lizhong > > > ---------- Forwarded message ---------- > From: Stewart Bryant > > To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org > " > >, > "pals@ietf.org " > > Cc: "pals-chairs@tools.ietf.org > " > > Date: Fri, 2 Oct 2015 16:41:05 +0100 > Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward > > I am sorry that this is a long email, but I wanted to collect the > facts together in one place and set out the complete scene to > the PALS WG. > > The critical concern is contained in the following email fragment > from Lizhong: > > ======= > > In RFC4447 and 4447bis, it clearly said: > > Using the PWid FEC, each of the two pseudowire endpoints > > independently initiates the setup of a unidirectional LSP. An > > outgoing LSP and an incoming LSP are bound together into a single > > pseudowire if they have the same PW ID and PW type. > > The behavior is a correct description for LDP-DU mode which PW > applies. > > And that is also the behavior most vendors implement. > > Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says: > > A PE that receives a PW label mapping message with an E-Tree Sub-TLV > > from its peer PE, after saving the VLAN information for the PW, > MUST > > process it as follows: > > ..... > > 3) If the P bit is set > > { > > If the PE is a leaf-only node itself, a label release > message > > with a status code "Leaf to Leaf PW released" is sent to the > peer > > PE and exit the process; > > Else the PE SHOULD set the Optimized-Mode to TRUE. > > } > > That means, if PE1 receiving a label mapping from PE2 with P bit set, > > PE1 will send label release. Then PE2 will never send label mapping > > again to PE1 even when PE1 changes from leaf-only node to > root-leaf node. For LDP-DU > > mode, PE2 will not send label mapping again when receiving PE1's > label mapping. > > Then the PW will not be setup successfully. Then only way is to > configure the > > same PW on PE2 again. > > The correct behavior is, label release message should not be sent. > > For PW signaling, the unacceptable of any Interface Parameter will > not lead to any > > label release, but just simply let the PW down in forwarding plane. > > ======== > > Andy looked at this from the point of view of the MEF and notes in > private conversation: > > ========= > > In the E-tree service as defined by MEF, you can have one or more > roots > and one or more leafs. > > In a single E-tree service (think of a multipoint PW with some of > the CEs > configured as roots as some as leafs), all leafs and roots receive > frames > sent by the roots. All roots receive frames sent by the leafs. > However, > leafs may not receive any frames sent by other leafs. > > The draft, as written, doesn't bring up an underlying pt-to-pt PWs to > carry frames for the service between PEs that only have leafs > attached. > Since the leafs can't sent frames to each other, that is an > economical > use of PWs in the network. > > Lizhong's point is that this makes it impossible to add a new root to > an existing PE in an E-tree that previously only had leafs. > > I agree that would be a problem if there was a requirement to modify > an existing E-tree service. However, this draft has no other > mechanisms > to explicitly support E-tree modification, nor is such modification a > requirement of the underlying MEF specification. BTW, since this work > was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet > Services Definitions Phase 3", August, 2014, and that reference > should > be updated in the draft. > > My opinion is that the draft as it stands is technically correct > if you > don't need the ability to reconfigure an existing E-tree service > dynamically. > > ========== > > Now whilst I can support the idea that dynamic reconfiguration of > E-tree is not needed, I have a concern. > > My understanding the text in question is that it is saying that if > A is configured as leaf only, and B which is also configured as > leaf only attempts to configure a PW between them, then A rejects > the PW setup. > > That sounds very reasonable to me, since there is a misconfig. > > If A did not do the reject, then B would forever be consuming > resource waiting for A and B would have no idea of the > misconfig. That accords with Andy's view above. > > However I was worried what would happen if A was misconfigured > as leaf only and the configuration was corrected to root-leaf. > What would in my view be difficult to accept was the need to > take a human, or NMS action at B to recover the situation. > However provided that A closed the LDP session with B > and re-instate it B would then send the mapping message again. > Thus the system is recoverable without needing to visit B which > is in my mind a fundamental requirement since A could have > got into the wrong mode as a result of an error. > > The problem I see is if A has a bunch of other PWs with B > they will get torn down in order for A to have the config error > fixed. However if that is a problem you need two LDP sessions > between A and B, one for L2VPN and one for regular PWs. > > My inclination is that the draft is basically correct, and that whilst > Lizhong is correct that the PW will not come up without some > action, reconfiguring the PW on B is not the only action > that will cause the PW to come up. > > So this comes down to a WG decision in terms of which is the > least unacceptable behaviour - A having to re-cycle the LDP > session, or B wasting resources. I think I prefer the behaviour > proposed in the draft. > > A way forward is to leave the logic as written in the draft, but to > add text describing the basis for excluding dynamic re-configuration > as a normal operational mode and to note the actions that need > to be taken when re-configuration is forced for some reason. > > Whilst we were pondering what do with the text the chairs > and AD received another proposal from the authors: > > ====== > > In general, FEC PWid(0x80) is used in VPLS with manual provisioning, > while Generalized PWid (0x81) is used with auto-discovery. > > As discussed in Section 5.2, VLAN mapping parameters can be > provisioned > without a signaling protocol, Optimized Mode can also be a parameter > to be provisioned. > > The approach we’ve taken in the current > draft-ietf-l2vpn-vpls-pe-etree-09 > does allow this. Quite a few service providers may prefer to control > all these E-Tree connectivity by themselves. > > When E-Tree signaling protocol for PWid FEC is considered, the > following > options are also feasible: > > a)Disable Optimized mode for FEC PWid(0x80), thus root/leaf role > change in the E-Tree topology will not have any influence on the PW. > > b)Add another appendix into the document for the full support of > Optimized mode with FEC PWid(0x80). > > The idea is: the PE sends a label mapping firstly and then send a > label > request to its peer PEs (so that they will reply with a label mapping > respectively). > > Since Optimized mode is an optional piece in the document, I would > regard option a) as a simple tradeoff (as I am aware, E-VPN does not > support Optimized mode for E-Tree either. > > ======== > > > Thus we have three proposals on the table: > > 1) Leave the design as it is, but add text to describe the > constraint and > what happens if you have to change mode and what to do about it. > > 2) Exclude optimization in the FEC PWid(0x80) case > > 3) Add an appendix describing support for the FEC PWid(0x80) case. > > My inclination would be to go with option (1) but I seek the views of > the WG, and of course any corrections in my analysis. > > - Stewart > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --------------010206030601090505020109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

From my perspective, and with due regard as to where we are,  option one
is the one that I would prefer to move things along.

That would not preclude us introducing another RFC at a later date if
there are further operational considerations or alternatives that there
is a consensus to support.

Do we have consensus to move forward with option 1?

Stewart



On 09/10/2015 13:02, Jiangyuanlong wrote:

Hi all,

 

We had some discussions on this mechanism when the document was still an individual draft (in fact, when it was being updated to draft-jiang-l2vpn-vpls-pe-etree-03).

Just like Stewart, some service providers were also concerned that this mechanism may result in a great waste of platform labels. For example, in a network with one root PE and 1000 leaf PEs, only 1001 PW labels are needed for the approach in the document; but we will need 1000*999/2=499500 PW labels in all for the proposed mechanism (since leaf to leaf PWs are still allocated). That is the main reason we adopted the current approach.

Therefore, I will regard option 1) as the favorite way forward:

1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

I will be glad to see more inputs to this topic.

 

Thanks,

Yuanlong



 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Monday, October 05, 2015 1:05 PM
To: Stewart Bryant (stbryant)
Cc: draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org; pals@ietf.org; pals-chairs@tools.ietf.org
Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

 

Hi Stewart,

For DU mode, if FEC is created, then label should be allocated. For the vulnerability you mentioned, if I understand your question correctly, the PW label will not be programmed into hardware, but only kept in control plane. So the packet will not be wrongly processed.

The MTU interface Sub-TLV defined in RFC4447 section 6.4 said:

If this parameter does not match
       in both directions of a specific PW, that PW MUST NOT be enabled.

The mechanism I proposed is what have been done for MTU interface sub-TLV.

 

Regards

Lizhong

 

On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) <stbryant@cisco.com> wrote:

 

 


On 4 Oct 2015, at 16:43, Lizhong Jin <lizho.jin@gmail.com> wrote:

Hi Stewart,

Thanks for the comment. This is a long email.

You give us three options:


1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

 

 Then I prefer option 1. Because option2 is not reasonable, and the solution in option3 provided by the author is not the best one.

 

I would like to provide opition4 for WG to consider:

4) Add description to support for the FEC PWid(0x80) case, in appendix or text I don't care. The solution is:

label release message should not be sent in section 6.1.
For PW signaling, the unacceptable of any Interface Parameter will not lead to any 
label release, but just simply let the PW down in forwarding plane.

Listing

 

Doesn't that waste labels, which may be a problem in some systems, and create a vulnerability since someone may send a packet with that label which would be processed and sent out of the person egress.

 

-Stewart



Regards

Lizhong

 

 


---------- Forwarded message ----------
From: Stewart Bryant <stbryant@cisco.com>
To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" <draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org>, "pals@ietf.org" <pals@ietf.org>
Cc: "pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>
Date: Fri, 2 Oct 2015 16:41:05 +0100
Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

I am sorry that this is a long email, but I wanted to collect the
facts together in one place and set out the complete scene to
the PALS WG.

The critical concern is contained in the following email fragment
from Lizhong:

=======

In RFC4447 and 4447bis, it clearly said:

Using the PWid FEC, each of the two pseudowire endpoints
   independently initiates the setup of a unidirectional LSP.   An
   outgoing LSP and an incoming LSP are bound together into a single
   pseudowire if they have the same PW ID  and PW type.
The behavior is a correct description for LDP-DU mode which PW applies.
And that is also the behavior most vendors implement.
 
Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:
 A PE that receives a PW label mapping message with an E-Tree Sub-TLV
   from its peer PE, after saving the VLAN information for the PW, MUST
   process it as follows:
.....
3) If the P bit is set
 
      {
 
          If the PE is a leaf-only node itself, a label release message
      with a status code "Leaf to Leaf PW released" is sent to the peer
      PE and exit the process;
 
          Else the PE SHOULD set the Optimized-Mode to TRUE.
 
      }
That means, if PE1 receiving a label mapping from PE2 with P bit set, 
PE1 will send label release. Then PE2 will never send label mapping
again to PE1 even when PE1 changes from leaf-only node to root-leaf node. For LDP-DU
mode, PE2 will not send label mapping again when receiving PE1's label mapping.
Then the PW will not be setup successfully. Then only way is to configure the 
same PW on PE2 again.
The correct behavior is, label release message should not be sent.
For PW signaling, the unacceptable of any Interface Parameter will not lead to any 
label release, but just simply let the PW down in forwarding plane.
 

========

Andy looked at this from the point of view of the MEF and notes in
private conversation:

=========

In the E-tree service as defined by MEF, you can have one or more roots
and one or more leafs.

 

In a single E-tree service (think of a multipoint PW with some of the CEs
configured as roots as some as leafs), all leafs and roots receive frames
sent by the roots. All roots receive frames sent by the leafs. However,
leafs may not receive any frames sent by other leafs.

 

The draft, as written, doesn't bring up an underlying pt-to-pt PWs to
carry frames for the service between PEs that only have leafs attached.
Since the leafs can't sent frames to each other, that is an economical
use of PWs in the network.

 

Lizhong's point is that this makes it impossible to add a new root to
an existing PE in an E-tree that previously only had leafs.

 

I agree that would be a problem if there was a requirement to modify
an existing E-tree service. However, this draft has no other mechanisms
to explicitly support E-tree modification, nor is such modification a
requirement of the underlying MEF specification. BTW, since this work
was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet
Services Definitions Phase 3", August, 2014, and that reference should
be updated in the draft.

My opinion is that the draft as it stands is technically correct if you
don't need the ability to reconfigure an existing E-tree service dynamically.

==========

Now whilst I can support the idea that dynamic reconfiguration of
E-tree is not needed, I have a concern.

My understanding the text in question is that it is saying that if
A is configured as leaf only, and B which is also configured as
leaf only attempts to configure a PW between them, then A rejects
the PW setup.

That sounds very reasonable to me, since there is a misconfig.

If A did not do the reject, then B would forever be consuming
resource waiting for A and B would have no idea of the
misconfig. That accords with Andy's view above.

However I was worried what would happen if A was misconfigured
as leaf only and the configuration was corrected to root-leaf.
What would in my view be difficult to accept was the need to
take a human, or NMS action at B to recover the situation.
However provided that A closed the LDP session with B
and re-instate it B would then send the mapping message again.
Thus the system is recoverable without needing to visit B which
is in my mind a fundamental requirement since A could have
got into the wrong mode as a result of an error.

The problem I see is if A has a bunch of other PWs with B
they will get torn down in order for A to have the config error
fixed. However if that is a problem you need two LDP sessions
between A and B, one for L2VPN and one for regular PWs.

My inclination is that the draft is basically correct, and that whilst
Lizhong is correct that the PW will not come up without some
action, reconfiguring the PW on B is not the only action
that will cause the PW to come up.

So this comes down to a WG decision in terms of which is the
least unacceptable behaviour - A having to re-cycle the LDP
session, or B wasting resources. I think I prefer the behaviour
proposed in the draft.

A way forward is to leave the logic as written in the draft, but to
add text describing the basis for excluding dynamic re-configuration
as a normal operational mode and to note the actions that need
to be taken when re-configuration is forced for some reason.

Whilst we were pondering what do with the text the chairs
and AD received another proposal from the authors:

======

In general, FEC PWid(0x80) is used in VPLS with manual provisioning,
while Generalized PWid (0x81) is used with auto-discovery.

As discussed in Section 5.2, VLAN mapping parameters can be provisioned
without a signaling protocol, Optimized Mode can also be a parameter
to be provisioned.

The approach we’ve taken in the current draft-ietf-l2vpn-vpls-pe-etree-09
does allow this. Quite a few service providers may prefer to control
all these E-Tree connectivity by themselves.

When E-Tree signaling protocol for PWid FEC is considered, the following
options are also feasible:

a)       Disable Optimized mode for FEC PWid(0x80), thus root/leaf role
change in the E-Tree topology will not have any influence on the PW.

b)       Add another appendix into the document for the full support of
Optimized mode with FEC PWid(0x80).

The idea is: the PE sends a label mapping firstly and then send a label
request to its peer PEs (so that they will reply with a label mapping
respectively).

Since Optimized mode is an optional piece in the document, I would
regard option a) as a simple tradeoff (as I am aware, E-VPN does not
support Optimized mode for E-Tree either.

========


Thus we have three proposals on the table:

1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

My inclination would be to go with option (1) but I seek the views of
the WG, and of course any corrections in my analysis.

- Stewart


_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

 

 



_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

--------------010206030601090505020109-- From nobody Fri Oct 9 07:47:47 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0EF1B4201; Fri, 9 Oct 2015 07:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE9XGdUsBpZ4; Fri, 9 Oct 2015 07:47:41 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900BA1B4203; Fri, 9 Oct 2015 07:47:41 -0700 (PDT) Received: by vkao3 with SMTP id o3so52638688vka.2; Fri, 09 Oct 2015 07:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=O3SLF27EucIU9HCpd1DxTeE7PoQ9/byGZf6fkP//zg0=; b=GArhRp6R5+m3KU5WOs2q4AEhByQhQHznElzAWZyq3s4DnVhOKXcEIsI0To/s19bSEu dRQuKyvHNmpwab5hCqKmIPZuogruJj6f+gnnbDZJdiPb/dqenOA0hkysjWxEB2D8ECXy G9dMu9SmND7TLurbbMNcBJWhl3AETrghLcWtN2DvqtqKehxajNWc+Ulpaf9rmniP59Pw Qf9VQIqY+28896dbpL8nXntoAisRsxi2x+CE4vSBz2qUGq/TbJy0zbvLQCbdXJOeqZJ4 2Nv6v3wtGlOvPuHCoyWrZ8XGUDdl5iQjVXmcguP6BIzXmU6rQFR7GxLaUpRbJ0YZJ4hX fTUQ== MIME-Version: 1.0 X-Received: by 10.31.168.79 with SMTP id r76mr9006357vke.102.1444402060744; Fri, 09 Oct 2015 07:47:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Fri, 9 Oct 2015 07:47:40 -0700 (PDT) In-Reply-To: <4552F0907735844E9204A62BBDD325E78720B693@nkgeml512-mbx.china.huawei.com> References: <20151001134257.12685.1930.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B693@nkgeml512-mbx.china.huawei.com> Date: Fri, 9 Oct 2015 07:47:40 -0700 X-Google-Sender-Auth: BzeT3BOBkiEOFegdAE86YrzHltc Message-ID: From: Barry Leiba To: Mingui Zhang Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "pals-chairs@ietf.org" , "agmalis@gmail.com" , The IESG , "pals@ietf.org" Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 14:47:43 -0000 Thanks, Mingui, for your response, and for considering my comments! Barry On Thu, Oct 8, 2015 at 7:44 PM, Mingui Zhang wrote: > Hi Barry, > > Thanks for the comments. Please see the in-lines below. > > >> -----Original Message----- >> From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Barry Leiba >> Sent: Thursday, October 01, 2015 9:43 PM >> To: The IESG >> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org >> Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pwe3-iccp-stp-04: (with >> COMMENT) >> >> Barry Leiba has entered the following ballot position for >> draft-ietf-pwe3-iccp-stp-04: No Objection >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This is a small thing, but please give some consideration to this: >> >> A 2119 "SHOULD" defines something that implementations need to do unless >> they have a good reason not to, and fully understand the issues and the >> consequences of not doing it. In general, I believe that means that >> specifications, when they use "SHOULD", need to include enough information >> for readers to understand why it's a "SHOULD" and to evaluate the >> consequences. That seems missing from many of the SHOULDs here, and I'd >> like to see you go through the document, find the ones that aren't making it >> clear enough, and beef them up just a little. > > [MZ] Authors has gone through the document. Now the ones that aren't cleared have been cleared. > >> >> An example where this is done right is in Section 4.2.3: >> >> While a PE has sent out a synchronization request for a particular PE >> node, it SHOULD silently ignore all TLVs from that node, that are >> received prior to the synchronization response and which carry the >> same type of information being requested. This saves the system from >> the burden of updating state that will ultimately be overwritten by >> the synchronization response. Note that TLVs pertaining to other >> systems should continue to be processed normally. >> >> THe second sentence explains why, and gives me some idea of what to consider >> when I'm writing my implementation. Thank you. There are others that get >> it right as well. >> >> A particularly weak one is in Section 4.2.1: >> >> A PE SHOULD follow the following order when advertising its STP state >> upon initial application connection setup: >> >> What's the significance of that order, from an interoperability, performance, or >> security perspective? What happens if, because of how my implementation is >> written, it's easier for me to do them in a different order and I decide to do so, >> not knowing what the consequences are? > > [MZ] It is for a performance reason. The following sentences will be added. > > The update of the information contained in the State TLVs depends on that in the configuration TLVs. By sending the TLVs in the above order, the two peers may begin to update STP state as early as possible in the middle of exchanging these TLVs. > > Thanks, > Mingui > From nobody Fri Oct 9 18:32:14 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA81B5230; Fri, 9 Oct 2015 18:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6oGJK2CKQ4V; Fri, 9 Oct 2015 18:32:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305B31B522A; Fri, 9 Oct 2015 18:32:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCJ02149; Sat, 10 Oct 2015 01:32:05 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 10 Oct 2015 02:32:04 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Sat, 10 Oct 2015 09:32:00 +0800 From: Mingui Zhang To: Stephen Farrell , The IESG Thread-Topic: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) Thread-Index: AQHQ+4GIdsqNDDNnGk+fsAP6zkUDl55hP+8QgAE4CYCAAYJw4A== Date: Sat, 10 Oct 2015 01:32:00 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> In-Reply-To: <56179249.6040108@cs.tcd.ie> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pals-chairs@ietf.org" , "agmalis@gmail.com" , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 01:32:09 -0000 SGkgU3RlcGhlbiwNCg0KWWVzLCBpdCBhc3N1bWVzIGEgY2VydGFpbmx5IGxlbmd0aC4gDQpJIHRo aW5rIHRoaXMgaXNzdWUgaXMgc2ltaWxhciBhcyB0aGUgRVVJLTY0IGlzc3VlOiBjdXJyZW50bHks IHRoZSBkb2N1bWVudCBhc3N1bWVzIGEgdHJhZGl0aW9uYWwgNDgtYml0IE1BQyBhZGRyZXNzZXMg YXJlIHVzZWQsIHdoaWNoIGlzIGluIGNvbnNpc3RlbmNlIHdpdGggUkZDIDcyNzUuIA0KDQpXaGVu IEkgY29tcGFyZWQgODAyLjFxLTIwMDUgYW5kIDgwMi4xcS0yMDE0LiBJIGZvdW5kIGFsbCByZWZl cmVuY2VzIHJlbGF0ZWQgdG8gODAyLjFxIGluIHRoZSBkb2N1bWVudCBhcmUgbm90IGNoYW5nZWQu IElmIHN1Y2gga2luZCBvZiBjaGFuZ2VzIGRvIGhhcHBlbiBpbiB0aGUgZnV0dXJlLCB0aGV5IGNv dWxkIGJlIGFuZCBzaG91bGQgYmUgaGFuZGxlZCBpbiB0aGUgbmV4dCBwcm90b2NvbCB2ZXJzaW9u IG9mIHRoZSBTVFAtSUNDUCBhcHBsaWNhdGlvbiwgSSB0aGluay4NCg0KRG9lcyBpdCBtYWtlIHNl bnNlPw0KDQpUaGFua3MsDQpNaW5ndWkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll XQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDksIDIwMTUgNjowOSBQTQ0KPiBUbzogTWluZ3Vp IFpoYW5nOyBUaGUgSUVTRw0KPiBDYzogcGFscy1jaGFpcnNAaWV0Zi5vcmc7IGFnbWFsaXNAZ21h aWwuY29tOyBwYWxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUGFsc10gU3RlcGhlbiBGYXJy ZWxsJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtcHdlMy1pY2NwLXN0cC0wNDoNCj4gKHdp dGggQ09NTUVOVCkNCj4gDQo+IA0KPiANCj4gT24gMDkvMTAvMTUgMDM6NTQsIE1pbmd1aSBaaGFu ZyB3cm90ZToNCj4gPiBIaSBTdGVwaGVuLA0KPiA+DQo+ID4gODAyLjFxIHVzZXMgaG1hYy1tZDUu IFRoaXMgc3RpbGwgaG9sZHMgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mDQo+ID4gODAyLjFxLg0K PiA+DQo+ID4gSSBhZ3JlZSB0aGF0IHNoYTI1NiBjb3VsZCBiZSB1c2VkIHRvIGVuaGFuY2UgdGhl IHNlY3VyaXR5LiBIb3dldmVyLCBJDQo+ID4gdGhpbmsgdGhhdCBraW5kIG9mIGVuaGFuY2VtZW50 IGlzIG91dCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBhbmQNCj4gPiBzaG91bGQgYmUgZGlz Y3Vzc2VkIGluIDgwMi4xcS4NCj4gDQo+IE9mIGNvdXJzZS4gQnV0IGlmIHRoZXkgZG8gdGhhdCwg YW5kIG1ha2UgYSBjaGFuZ2Ugd2hhdCBpcyB0aGUgaW1wYWN0IGhlcmUgaXMgbXkNCj4gcXVlc3Rp b24uIChJIGRpZG4ndCByZS1yZWFkIHRoZSBkb2MsIGJ1dCB3YXMgdGhpcyBvbmUgd2hlcmUgaXQg YXNzdW1lcyBhDQo+IGNlcnRhaW5seSBsZW5ndGggb3Igc29tZXRoaW5nPykNCj4gDQo+IFMNCj4g DQo+ID4NCj4gPiBUaGFua3MsIE1pbmd1aQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIEZyb206IFBhbHMgW21haWx0bzpwYWxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4+IE9u IEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwgU2VudDoNCj4gPj4gV2VkbmVzZGF5LCBTZXB0ZW1i ZXIgMzAsIDIwMTUgOToxMCBQTSBUbzogVGhlIElFU0cgQ2M6DQo+ID4+IHBhbHMtY2hhaXJzQGll dGYub3JnOyBhZ21hbGlzQGdtYWlsLmNvbTsgcGFsc0BpZXRmLm9yZyBTdWJqZWN0Og0KPiA+PiBb UGFsc10gU3RlcGhlbiBGYXJyZWxsJ3MgTm8gT2JqZWN0aW9uIG9uDQo+ID4+IGRyYWZ0LWlldGYt cHdlMy1pY2NwLXN0cC0wNDogKHdpdGggQ09NTUVOVCkNCj4gPj4NCj4gPj4gU3RlcGhlbiBGYXJy ZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+PiBk cmFmdC1pZXRmLXB3ZTMtaWNjcC1zdHAtMDQ6IE5vIE9iamVjdGlvbg0KPiA+Pg0KPiA+PiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGwNCj4gPj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+ID4+IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSByZWZlciB0bw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwgZm9y IG1vcmUNCj4gPj4gaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZA0KPiA+PiBoZXJlOiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXB3ZTMtaWNjcC1zdHAvDQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ID4+DQo+ID4+DQo+IENPTU1FTlQ6 DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+IC0g My4zLjU6IGlzIHRoYXQgYSBoYXJkLWNvZGVkIHNoYTEgb3IgbWQ1PyBpZiBzbywgd2h5IGlzIHRo YXQgb2s/IHdoYXQgaWYgODAyLjFxDQo+ID4+IGlzIGZpeGVkL2ltcHJvdmVkIGUuZy4gdG8gdXNl IHNoYTI1Nj8NCj4gPj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gUGFscyBtYWlsaW5nIGxpc3QNCj4gPj4gUGFsc0BpZXRmLm9yZyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BhbHMNCg== From nobody Thu Oct 15 18:26:54 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E78C1ACF03; Thu, 15 Oct 2015 18:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIXLHUH5VFvJ; Thu, 15 Oct 2015 18:26:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1537F1ACF18; Thu, 15 Oct 2015 18:26:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYW23474; Fri, 16 Oct 2015 01:26:44 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Oct 2015 02:26:42 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Fri, 16 Oct 2015 09:26:40 +0800 From: Mingui Zhang To: Stephen Farrell , The IESG Thread-Topic: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) Thread-Index: AQHQ+4GIdsqNDDNnGk+fsAP6zkUDl55hP+8QgAE4CYCAAYJw4IAJb6kA Date: Fri, 16 Oct 2015 01:26:39 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pals-chairs@ietf.org" , "agmalis@gmail.com" , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 01:26:50 -0000 Hi Stephen, We haven't heard from you. Could you confirm whether the explanation is acc= eptable? Thanks, Mingui > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Mingui Zhang > Sent: Saturday, October 10, 2015 9:32 AM > To: Stephen Farrell; The IESG > Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org > Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-icc= p-stp-04: > (with COMMENT) >=20 > Hi Stephen, >=20 > Yes, it assumes a certainly length. > I think this issue is similar as the EUI-64 issue: currently, the documen= t > assumes a traditional 48-bit MAC addresses are used, which is in consiste= nce > with RFC 7275. >=20 > When I compared 802.1q-2005 and 802.1q-2014. I found all references relat= ed > to 802.1q in the document are not changed. If such kind of changes do hap= pen > in the future, they could be and should be handled in the next protocol v= ersion > of the STP-ICCP application, I think. >=20 > Does it make sense? >=20 > Thanks, > Mingui >=20 > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > Sent: Friday, October 09, 2015 6:09 PM > > To: Mingui Zhang; The IESG > > Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org > > Subject: Re: [Pals] Stephen Farrell's No Objection on > draft-ietf-pwe3-iccp-stp-04: > > (with COMMENT) > > > > > > > > On 09/10/15 03:54, Mingui Zhang wrote: > > > Hi Stephen, > > > > > > 802.1q uses hmac-md5. This still holds in the latest version of > > > 802.1q. > > > > > > I agree that sha256 could be used to enhance the security. However, > > > I think that kind of enhancement is out the scope of this document > > > and should be discussed in 802.1q. > > > > Of course. But if they do that, and make a change what is the impact > > here is my question. (I didn't re-read the doc, but was this one where > > it assumes a certainly length or something?) > > > > S > > > > > > > > Thanks, Mingui > > > > > >> -----Original Message----- From: Pals > > >> [mailto:pals-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: > > >> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: > > >> pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org Subject: > > >> [Pals] Stephen Farrell's No Objection on > > >> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) > > >> > > >> Stephen Farrell has entered the following ballot position for > > >> draft-ietf-pwe3-iccp-stp-04: No Objection > > >> > > >> When responding, please keep the subject line intact and reply to > > >> all email addresses included in the To and CC lines. (Feel free to > > >> cut this introductory paragraph, however.) > > >> > > >> > > >> Please refer to > > >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more > > >> information about IESG DISCUSS and COMMENT positions. > > >> > > >> > > >> The document, along with other ballot positions, can be found > > >> here: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ > > >> > > >> > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> > > COMMENT: > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> > > >> > > >> > > - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what > > if 802.1q > > >> is fixed/improved e.g. to use sha256? > > >> > > >> > > >> _______________________________________________ Pals mailing list > > >> Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Fri Oct 16 02:15:39 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E7A1B346B; Fri, 16 Oct 2015 02:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UhxfqfuE0RZ; Fri, 16 Oct 2015 02:15:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBE31B345A; Fri, 16 Oct 2015 02:15:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016091536.28373.47957.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 02:15:36 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-vpls-pim-snooping-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 09:15:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) Authors : Olivier Dornon Jayant Kotalwar Venu Hemige Ray Qiu Jeffrey Zhang Filename : draft-ietf-pals-vpls-pim-snooping-01.txt Pages : 40 Date : 2015-10-16 Abstract: This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via Protocol Independent Multicast (PIM) snooping and proxying. With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, Provider Edges (PEs) do not flood PIM Join/Prune messages but only generate their own and send out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Equipment (CE) devices and useful to reduce PIM control traffic in a VPLS domain. The document also describes PIM relay, which can be viewed as light- weight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports but not flooded to avoid triggering PIM Join suppression on CE devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-vpls-pim-snooping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-vpls-pim-snooping-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-vpls-pim-snooping-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 16 14:31:07 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEEA1A1B49; Fri, 16 Oct 2015 14:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeiC8k07LSeP; Fri, 16 Oct 2015 14:31:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6EC71A1B3E; Fri, 16 Oct 2015 14:31:01 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9GLV0i6007247 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 16 Oct 2015 16:31:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: General Area Review Team , "ietf@ietf.org" , pals@ietf.org, draft-ietf-pals-redundance-spe.all@ietf.org From: Robert Sparks Message-ID: <56216C90.4060606@nostrum.com> Date: Fri, 16 Oct 2015 16:30:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pals] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 21:31:03 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-pals-redundancy-spe-02 Reviewer: Robert Sparks Review Date: 16 Oct 2015 IETF LC End Date: 19 Oct 2015 IESG Telechat date: 22 Oct 2015 Summary: Almost ready for publication as PS but with issues that need to be discussed/addressed This document is hard to read. It is more acronym-laden than it needs to be. ----- There is a process issue that the IESG should pay attention to. The shepherd writeup says this: "There is one IPR declaration (1911) raised in November 2012 against an early version of the draft. There was no discussion in the WG related to this." That happens sometimes, but it's much better to have a real indication that the group considered the disclosure and explicitly decided not to change directions. ----- The last sentence of the 2nd paragraph (declaring multi-homing on both sides of an S-PE out of scope) should be moved earlier in the document. The introduction and perhaps even the abstract can be clearer about what _is_ in scope. It needs to be clearer where the normative description of behavior is. I think you're intending it to be the first part of section 3. I have not worked through the references enough to ensure that it is complete. The third paragraph starts off "In general, ...". Are there any specific cases where the requirements that follow do not hold? If so, there needs to be more description. If not, please delete "In general,". Are sections 3.1 and 3.2 supposed to be only examples? Would the specification of the protocol be complete if they were deleted? If not, something needs to be moved up into the main part of section 3. For instance, is the SHOULD at the end of 3.1 a requirement placed by this document, or is it restating a requirement from somewhere else? Similarly, please inspect the SHOULD in the second paragraph of 3.2. I also suggest moving 3.1 and 3.2 into their own section, clearly labeling them as examples. Is it worth more explanation in the document why you've added the MUST NOT in the first paragraph of section 3? The security considerations section only points off to other documents. Most of those just point to each other. Chasing it back, there's some meat in the security considerations section of 4447, and some in 5085, but it's a real chase to find what's relevant. Please consider calling out what an implementer needs to consider explicitly here. From nobody Sat Oct 17 01:52:55 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDFF1A90DE; Sat, 17 Oct 2015 01:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLNiUMdUe2r7; Sat, 17 Oct 2015 01:52:47 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC181A90D9; Sat, 17 Oct 2015 01:52:47 -0700 (PDT) Received: by wijp11 with SMTP id p11so38395171wij.0; Sat, 17 Oct 2015 01:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s+nZq3ag9EJl37RtwjdzKljGTcfwEAeii50aKp0H/1s=; b=Tb6tAXQSu/ERGAd3VpMsvCIar/L16l3AjdFYnG3ov+R6NCFgmmF4LPTRMUV8woYWUa Fns0Jaq9eHfAUrzm5hdybt47Llhydc5yw+u1bM0AKhWq90r4le1ycqnsdTFY+iyengC7 px6sjyLkgMprWSC7vqbZY1unRgNphkDLNd39XADcmec/xvumqxha6Z8B7fyz80NXhmvB ZxnayWBUsaes5HOXsuud5IS6Xbh45xl5yRluYvedBbh+zDO/cKhbFzRD7pMtAOvgjpeS tm8O6ujUbB9g9mKERMpejShgXMMmupSFZrXBex4xqz96CqkDjrUlkHbfz6/znAUjhX0Y DP6g== X-Received: by 10.194.143.43 with SMTP id sb11mr24028729wjb.120.1445071966147; Sat, 17 Oct 2015 01:52:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.212 with HTTP; Sat, 17 Oct 2015 01:52:26 -0700 (PDT) In-Reply-To: <56216C90.4060606@nostrum.com> References: <56216C90.4060606@nostrum.com> From: "Andrew G. Malis" Date: Sat, 17 Oct 2015 10:52:26 +0200 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=089e0112c50c379ac60522490985 Archived-At: Cc: draft-ietf-pals-redundancy-spe.all@ietf.org, General Area Review Team , "ietf@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 08:52:50 -0000 --089e0112c50c379ac60522490985 Content-Type: text/plain; charset=UTF-8 Robert, Thanks for your review of the draft. As PALS WG co-chair, I would like to address one point in your review: There is a process issue that the IESG should pay attention to. The > shepherd writeup says this: "There is one IPR declaration (1911) raised in > November 2012 against an early version of the draft. There was no > discussion in the WG related to this." That happens sometimes, but it's > much better to have a real indication that the group considered the > disclosure and explicitly decided not to change directions. The IPR declaration is against the original individual draft, draft-dong-pwe3-redundancy-spe. The IPR declaration was from a company that was not represented as an author on the draft, and offered free licencing with reciprocity. At the time, no concerns were raised by either the authors or from anyone in the WG in response to the declaration. This, IMHO, is normal operating procedure when IPR declarations are made, especially by non-author entities and early in the process. The usual concern is when declarations come in late in the process, especially from an author company. Neither was the case here, it was still an individual draft. And of course, the declaration was clear for all to see during both WG adoption and WG LC polls. Thanks, Andy On Fri, Oct 16, 2015 at 11:30 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-pals-redundancy-spe-02 > Reviewer: Robert Sparks > Review Date: 16 Oct 2015 > IETF LC End Date: 19 Oct 2015 > IESG Telechat date: 22 Oct 2015 > > Summary: Almost ready for publication as PS but with issues that need to > be discussed/addressed > > This document is hard to read. It is more acronym-laden than it > needs to be. > > ----- > There is a process issue that the IESG should pay attention to. > The shepherd writeup says this: > > "There is one IPR declaration (1911) raised in November 2012 against > an early version of the draft. There was no discussion in the WG > related to this." > > That happens sometimes, but it's much better to have a real indication > that the group considered the disclosure and explicitly decided not to > change directions. > ----- > > The last sentence of the 2nd paragraph (declaring multi-homing on both > sides of an S-PE out of scope) should be moved earlier in the document. > The introduction and perhaps even the abstract can be clearer about > what _is_ in scope. > > It needs to be clearer where the normative description of behavior is. > I think you're intending it to be the first part of section 3. I have > not worked through the references enough to ensure that it is complete. > > The third paragraph starts off "In general, ...". Are there any > specific cases where the requirements that follow do not hold? If so, > there needs to be more description. If not, please delete "In general,". > > Are sections 3.1 and 3.2 supposed to be only examples? Would the > specification of the protocol be complete if they were deleted? If not, > something needs to be moved up into the main part of section 3. > For instance, is the SHOULD at the end of 3.1 a requirement placed by > this document, or is it restating a requirement from somewhere else? > Similarly, please inspect the SHOULD in the second paragraph of 3.2. > > I also suggest moving 3.1 and 3.2 into their own section, clearly > labeling them as examples. > > Is it worth more explanation in the document why you've added the > MUST NOT in the first paragraph of section 3? > > The security considerations section only points off to other documents. > Most of those just point to each other. Chasing it back, there's some > meat in the security considerations section of 4447, and some in 5085, > but it's a real chase to find what's relevant. Please consider calling > out what an implementer needs to consider explicitly here. > > --089e0112c50c379ac60522490985 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

Than= ks for your review of the draft.

As PALS WG co-chair, I would like to address= one point in your review:

There is a= process issue that the IESG should pay attention to. The shepherd writeup = says this: "There is one IPR declaration (1911) raised in November 201= 2 against an early version of the draft. There was no discussion in the WG = related to this." That happens sometimes, but it's much better to = have a real indication that the group considered the disclosure and explici= tly decided not to change directions.

The I= PR declaration is against the original individual draft,=C2=A0draft-dong-pw= e3-redundancy-spe. The IPR declaration was from a company that was not repr= esented as an author on the draft, and offered free licencing with reciproc= ity. At the time, no concerns were raised by either the authors or from any= one in the WG in response to the declaration. This, IMHO, is normal operati= ng procedure when IPR declarations are made, especially by non-author entit= ies and early in the process. The usual concern is when declarations come i= n late in the process, especially from an author company. Neither was the c= ase here, it was still an individual draft. And of course, the declaration = was clear for all to see during both WG adoption and WG LC polls.

Thanks,
Andy


On Fri, O= ct 16, 2015 at 11:30 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
I am the assigned Gen-ART rev= iewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/= wiki/GenArtfaq>.

Document: draft-ietf-pals-redundancy-spe-02
Reviewer: Robert Sparks
Review Date: 16 Oct 2015
IETF LC End Date: 19 Oct 2015
IESG Telechat date: 22 Oct 2015

Summary: Almost ready for publication as PS but with issues that need to be= discussed/addressed

This document is hard to read. It is more acronym-laden than it
needs to be.

-----
There is a process issue that the IESG should pay attention to.
The shepherd writeup says this:

=C2=A0 "There is one IPR declaration (1911) raised in November 2012 ag= ainst
=C2=A0 =C2=A0an early version of the draft.=C2=A0 There was no discussion i= n the WG
=C2=A0 =C2=A0related to this."

That happens sometimes, but it's much better to have a real indication<= br> that the group considered the disclosure and explicitly decided not to
change directions.
-----

The last sentence of the 2nd paragraph (declaring multi-homing on both
sides of an S-PE out of scope) should be moved earlier in the document.
The introduction and perhaps even the abstract can be clearer about
what _is_ in scope.

It needs to be clearer where the normative description of behavior is.
I think you're intending it to be the first part of section 3. I have not worked through the references enough to ensure that it is complete.

The third paragraph starts off "In general, ...". Are there any specific cases where the requirements that follow do not hold? If so,
there needs to be more description. If not, please delete "In general,= ".

Are sections 3.1 and 3.2 supposed to be only examples? Would the
specification of the protocol be complete if they were deleted? If not,
something needs to be moved up into the main part of section 3.
For instance, is the SHOULD at the end of 3.1 a requirement placed by
this document, or is it restating a requirement from somewhere else?
Similarly, please inspect the SHOULD in the second paragraph of 3.2.

I also suggest moving 3.1 and 3.2 into their own section, clearly
labeling them as examples.

Is it worth more explanation in the document why you've added the
MUST NOT in the first paragraph of section 3?

The security considerations section only points off to other documents.
Most of those just point to each other. Chasing it back, there's some meat in the security considerations section of 4447, and some in 5085,
but it's a real chase to find what's relevant.=C2=A0 Please conside= r calling
out what an implementer needs to consider explicitly here.


--089e0112c50c379ac60522490985-- From nobody Sat Oct 17 09:12:23 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7111B29B5; Sat, 17 Oct 2015 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNgcKogeQdq4; Sat, 17 Oct 2015 09:12:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7701F1B29B1; Sat, 17 Oct 2015 09:12:16 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9HG9D7G027368; Sat, 17 Oct 2015 12:12:15 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 1xkgyp583r-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Oct 2015 12:12:14 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9HGCDLR004807; Sat, 17 Oct 2015 12:12:13 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9HGC4lR004763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Oct 2015 12:12:07 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sat, 17 Oct 2015 16:11:49 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.90]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0248.002; Sat, 17 Oct 2015 12:11:49 -0400 From: "BRUNGARD, DEBORAH A" To: "Andrew G. Malis" , Robert Sparks Thread-Topic: Gen-art LC review: draft-ietf-pals-redundancy-spe-02 Thread-Index: AQHRCFoB1F2sibcDrECvNq2HgCJ5Op5vpKQAgAAwBPA= Date: Sat, 17 Oct 2015 16:11:48 +0000 Message-ID: References: <56216C90.4060606@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.191.252] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C8527548C0MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-17_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510170293 Archived-At: Cc: "draft-ietf-pals-redundancy-spe.all@ietf.org" , General Area Review Team , "ietf@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 16:12:19 -0000 --_000_F64C10EAA68C8044B33656FA214632C8527548C0MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBBcyBBbmR5IGV4cGxhaW5lZCwg aW4gdGhlIFJvdXRpbmcgQXJlYSwgdGhlcmUgYXJlIG11bHRpcGxlIHBvaW50cyBpbiB0aGUgcHJv Y2VzcyB3aGVyZSBmb2xrcyBhcmUgbWFkZSBhd2FyZS9yZW1pbmRlZCBvZiBJUFIgYW5kIHdlIGZv bGxvdyBSRkM2NzAyIHN1Z2dlc3Rpb25zLiBBbmQgZm9yIGZvbGtzIG5vdCBwYXJ0aWNpcGF0aW5n IGFjdGl2ZWx5IGluIHRoZSBXb3JraW5nIEdyb3VwLCB0aGV5IHN0aWxsIGhhdmUgdGhlIG9wcG9y dHVuaXR5IGF0IElFVEYgTGFzdCBDYWxsICh3aGljaCBoYXMgYSBwb2ludGVyIHRvIElQUikgdG8g ZGlzY3Vzcy9leHByZXNzIGNvbmNlcm4uDQoNCklmIHlvdSB3b3VsZCBsaWtlIHRvIGRpc2N1c3Mv cmVjb21tZW5kIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBJRVRGIHRvIGZvbGxv dyBvbiBJUFIsIGl0IHdvdWxkIGJlIGdvb2QgdG8gY2hhbmdlIHRoZSBzdWJqZWN0IGxpbmUgYXMg SSBkb27igJl0IHRoaW5rIHRoZSBjdXJyZW50IHN1YmplY3QgbGluZSBpcyBtdWNoIG9mIGFuIGF0 dGVudGlvbi1ncmFiYmVy4pi6DQoNCknigJlsbCBsZXQgdGhlIGF1dGhvcnMgYW5zd2VyIHlvdXIg cXVlc3Rpb25zIG9uIHRoZSBkcmFmdCBpdHNlbGYuDQoNCkFnYWluLCB0aGFua3MgZm9yIHlvdXIg Y2FyZWZ1bCByZXZpZXctDQpEZWJvcmFoDQoNCg0KRnJvbTogQW5kcmV3IEcuIE1hbGlzIFttYWls dG86YWdtYWxpc0BnbWFpbC5jb21dDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciAxNywgMjAxNSA0 OjUyIEFNDQpUbzogUm9iZXJ0IFNwYXJrcw0KQ2M6IEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbTsg aWV0ZkBpZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3kt c3BlLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEdlbi1hcnQgTEMgcmV2aWV3OiBkcmFmdC1p ZXRmLXBhbHMtcmVkdW5kYW5jeS1zcGUtMDINCg0KUm9iZXJ0LA0KDQpUaGFua3MgZm9yIHlvdXIg cmV2aWV3IG9mIHRoZSBkcmFmdC4NCg0KQXMgUEFMUyBXRyBjby1jaGFpciwgSSB3b3VsZCBsaWtl IHRvIGFkZHJlc3Mgb25lIHBvaW50IGluIHlvdXIgcmV2aWV3Og0KDQpUaGVyZSBpcyBhIHByb2Nl c3MgaXNzdWUgdGhhdCB0aGUgSUVTRyBzaG91bGQgcGF5IGF0dGVudGlvbiB0by4gVGhlIHNoZXBo ZXJkIHdyaXRldXAgc2F5cyB0aGlzOiAiVGhlcmUgaXMgb25lIElQUiBkZWNsYXJhdGlvbiAoMTkx MSkgcmFpc2VkIGluIE5vdmVtYmVyIDIwMTIgYWdhaW5zdCBhbiBlYXJseSB2ZXJzaW9uIG9mIHRo ZSBkcmFmdC4gVGhlcmUgd2FzIG5vIGRpc2N1c3Npb24gaW4gdGhlIFdHIHJlbGF0ZWQgdG8gdGhp cy4iIFRoYXQgaGFwcGVucyBzb21ldGltZXMsIGJ1dCBpdCdzIG11Y2ggYmV0dGVyIHRvIGhhdmUg YSByZWFsIGluZGljYXRpb24gdGhhdCB0aGUgZ3JvdXAgY29uc2lkZXJlZCB0aGUgZGlzY2xvc3Vy ZSBhbmQgZXhwbGljaXRseSBkZWNpZGVkIG5vdCB0byBjaGFuZ2UgZGlyZWN0aW9ucy4NCg0KVGhl IElQUiBkZWNsYXJhdGlvbiBpcyBhZ2FpbnN0IHRoZSBvcmlnaW5hbCBpbmRpdmlkdWFsIGRyYWZ0 LCBkcmFmdC1kb25nLXB3ZTMtcmVkdW5kYW5jeS1zcGUuIFRoZSBJUFIgZGVjbGFyYXRpb24gd2Fz IGZyb20gYSBjb21wYW55IHRoYXQgd2FzIG5vdCByZXByZXNlbnRlZCBhcyBhbiBhdXRob3Igb24g dGhlIGRyYWZ0LCBhbmQgb2ZmZXJlZCBmcmVlIGxpY2VuY2luZyB3aXRoIHJlY2lwcm9jaXR5LiBB dCB0aGUgdGltZSwgbm8gY29uY2VybnMgd2VyZSByYWlzZWQgYnkgZWl0aGVyIHRoZSBhdXRob3Jz IG9yIGZyb20gYW55b25lIGluIHRoZSBXRyBpbiByZXNwb25zZSB0byB0aGUgZGVjbGFyYXRpb24u IFRoaXMsIElNSE8sIGlzIG5vcm1hbCBvcGVyYXRpbmcgcHJvY2VkdXJlIHdoZW4gSVBSIGRlY2xh cmF0aW9ucyBhcmUgbWFkZSwgZXNwZWNpYWxseSBieSBub24tYXV0aG9yIGVudGl0aWVzIGFuZCBl YXJseSBpbiB0aGUgcHJvY2Vzcy4gVGhlIHVzdWFsIGNvbmNlcm4gaXMgd2hlbiBkZWNsYXJhdGlv bnMgY29tZSBpbiBsYXRlIGluIHRoZSBwcm9jZXNzLCBlc3BlY2lhbGx5IGZyb20gYW4gYXV0aG9y IGNvbXBhbnkuIE5laXRoZXIgd2FzIHRoZSBjYXNlIGhlcmUsIGl0IHdhcyBzdGlsbCBhbiBpbmRp dmlkdWFsIGRyYWZ0LiBBbmQgb2YgY291cnNlLCB0aGUgZGVjbGFyYXRpb24gd2FzIGNsZWFyIGZv ciBhbGwgdG8gc2VlIGR1cmluZyBib3RoIFdHIGFkb3B0aW9uIGFuZCBXRyBMQyBwb2xscy4NCg0K VGhhbmtzLA0KQW5keQ0KDQoNCk9uIEZyaSwgT2N0IDE2LCAyMDE1IGF0IDExOjMwIFBNLCBSb2Jl cnQgU3BhcmtzIDxyanNwYXJrc0Bub3N0cnVtLmNvbTxtYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5j b20+PiB3cm90ZToNCkkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMg ZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWENClJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFs bCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQNCmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVU RiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQpsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2Vl IHRoZSBGQVEgYXQNCg0KPGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMv d2lraS9HZW5BcnRmYXE+Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3kt c3BlLTAyDQpSZXZpZXdlcjogUm9iZXJ0IFNwYXJrcw0KUmV2aWV3IERhdGU6IDE2IE9jdCAyMDE1 DQpJRVRGIExDIEVuZCBEYXRlOiAxOSBPY3QgMjAxNQ0KSUVTRyBUZWxlY2hhdCBkYXRlOiAyMiBP Y3QgMjAxNQ0KDQpTdW1tYXJ5OiBBbG1vc3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIFBTIGJ1 dCB3aXRoIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgZGlzY3Vzc2VkL2FkZHJlc3NlZA0KDQpUaGlz IGRvY3VtZW50IGlzIGhhcmQgdG8gcmVhZC4gSXQgaXMgbW9yZSBhY3JvbnltLWxhZGVuIHRoYW4g aXQNCm5lZWRzIHRvIGJlLg0KDQotLS0tLQ0KVGhlcmUgaXMgYSBwcm9jZXNzIGlzc3VlIHRoYXQg dGhlIElFU0cgc2hvdWxkIHBheSBhdHRlbnRpb24gdG8uDQpUaGUgc2hlcGhlcmQgd3JpdGV1cCBz YXlzIHRoaXM6DQoNCiAgIlRoZXJlIGlzIG9uZSBJUFIgZGVjbGFyYXRpb24gKDE5MTEpIHJhaXNl ZCBpbiBOb3ZlbWJlciAyMDEyIGFnYWluc3QNCiAgIGFuIGVhcmx5IHZlcnNpb24gb2YgdGhlIGRy YWZ0LiAgVGhlcmUgd2FzIG5vIGRpc2N1c3Npb24gaW4gdGhlIFdHDQogICByZWxhdGVkIHRvIHRo aXMuIg0KDQpUaGF0IGhhcHBlbnMgc29tZXRpbWVzLCBidXQgaXQncyBtdWNoIGJldHRlciB0byBo YXZlIGEgcmVhbCBpbmRpY2F0aW9uDQp0aGF0IHRoZSBncm91cCBjb25zaWRlcmVkIHRoZSBkaXNj bG9zdXJlIGFuZCBleHBsaWNpdGx5IGRlY2lkZWQgbm90IHRvDQpjaGFuZ2UgZGlyZWN0aW9ucy4N Ci0tLS0tDQoNClRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSAybmQgcGFyYWdyYXBoIChkZWNsYXJp bmcgbXVsdGktaG9taW5nIG9uIGJvdGgNCnNpZGVzIG9mIGFuIFMtUEUgb3V0IG9mIHNjb3BlKSBz aG91bGQgYmUgbW92ZWQgZWFybGllciBpbiB0aGUgZG9jdW1lbnQuDQpUaGUgaW50cm9kdWN0aW9u IGFuZCBwZXJoYXBzIGV2ZW4gdGhlIGFic3RyYWN0IGNhbiBiZSBjbGVhcmVyIGFib3V0DQp3aGF0 IF9pc18gaW4gc2NvcGUuDQoNCkl0IG5lZWRzIHRvIGJlIGNsZWFyZXIgd2hlcmUgdGhlIG5vcm1h dGl2ZSBkZXNjcmlwdGlvbiBvZiBiZWhhdmlvciBpcy4NCkkgdGhpbmsgeW91J3JlIGludGVuZGlu ZyBpdCB0byBiZSB0aGUgZmlyc3QgcGFydCBvZiBzZWN0aW9uIDMuIEkgaGF2ZQ0Kbm90IHdvcmtl ZCB0aHJvdWdoIHRoZSByZWZlcmVuY2VzIGVub3VnaCB0byBlbnN1cmUgdGhhdCBpdCBpcyBjb21w bGV0ZS4NCg0KVGhlIHRoaXJkIHBhcmFncmFwaCBzdGFydHMgb2ZmICJJbiBnZW5lcmFsLCAuLi4i LiBBcmUgdGhlcmUgYW55DQpzcGVjaWZpYyBjYXNlcyB3aGVyZSB0aGUgcmVxdWlyZW1lbnRzIHRo YXQgZm9sbG93IGRvIG5vdCBob2xkPyBJZiBzbywNCnRoZXJlIG5lZWRzIHRvIGJlIG1vcmUgZGVz Y3JpcHRpb24uIElmIG5vdCwgcGxlYXNlIGRlbGV0ZSAiSW4gZ2VuZXJhbCwiLg0KDQpBcmUgc2Vj dGlvbnMgMy4xIGFuZCAzLjIgc3VwcG9zZWQgdG8gYmUgb25seSBleGFtcGxlcz8gV291bGQgdGhl DQpzcGVjaWZpY2F0aW9uIG9mIHRoZSBwcm90b2NvbCBiZSBjb21wbGV0ZSBpZiB0aGV5IHdlcmUg ZGVsZXRlZD8gSWYgbm90LA0Kc29tZXRoaW5nIG5lZWRzIHRvIGJlIG1vdmVkIHVwIGludG8gdGhl IG1haW4gcGFydCBvZiBzZWN0aW9uIDMuDQpGb3IgaW5zdGFuY2UsIGlzIHRoZSBTSE9VTEQgYXQg dGhlIGVuZCBvZiAzLjEgYSByZXF1aXJlbWVudCBwbGFjZWQgYnkNCnRoaXMgZG9jdW1lbnQsIG9y IGlzIGl0IHJlc3RhdGluZyBhIHJlcXVpcmVtZW50IGZyb20gc29tZXdoZXJlIGVsc2U/DQpTaW1p bGFybHksIHBsZWFzZSBpbnNwZWN0IHRoZSBTSE9VTEQgaW4gdGhlIHNlY29uZCBwYXJhZ3JhcGgg b2YgMy4yLg0KDQpJIGFsc28gc3VnZ2VzdCBtb3ZpbmcgMy4xIGFuZCAzLjIgaW50byB0aGVpciBv d24gc2VjdGlvbiwgY2xlYXJseQ0KbGFiZWxpbmcgdGhlbSBhcyBleGFtcGxlcy4NCg0KSXMgaXQg d29ydGggbW9yZSBleHBsYW5hdGlvbiBpbiB0aGUgZG9jdW1lbnQgd2h5IHlvdSd2ZSBhZGRlZCB0 aGUNCk1VU1QgTk9UIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAzPw0KDQpUaGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvbmx5IHBvaW50cyBvZmYgdG8gb3RoZXIg ZG9jdW1lbnRzLg0KTW9zdCBvZiB0aG9zZSBqdXN0IHBvaW50IHRvIGVhY2ggb3RoZXIuIENoYXNp bmcgaXQgYmFjaywgdGhlcmUncyBzb21lDQptZWF0IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uIG9mIDQ0NDcsIGFuZCBzb21lIGluIDUwODUsDQpidXQgaXQncyBhIHJlYWwg Y2hhc2UgdG8gZmluZCB3aGF0J3MgcmVsZXZhbnQuICBQbGVhc2UgY29uc2lkZXIgY2FsbGluZw0K b3V0IHdoYXQgYW4gaW1wbGVtZW50ZXIgbmVlZHMgdG8gY29uc2lkZXIgZXhwbGljaXRseSBoZXJl Lg0KDQo= --_000_F64C10EAA68C8044B33656FA214632C8527548C0MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcu IEFzIEFuZHkgZXhwbGFpbmVkLCBpbiB0aGUgUm91dGluZyBBcmVhLCB0aGVyZSBhcmUgbXVsdGlw bGUgcG9pbnRzIGluIHRoZSBwcm9jZXNzIHdoZXJlIGZvbGtzIGFyZSBtYWRlIGF3YXJlL3JlbWlu ZGVkIG9mIElQUiBhbmQgd2UgZm9sbG93DQogUkZDNjcwMiBzdWdnZXN0aW9ucy4gQW5kIGZvciBm b2xrcyBub3QgcGFydGljaXBhdGluZyBhY3RpdmVseSBpbiB0aGUgV29ya2luZyBHcm91cCwgdGhl eSBzdGlsbCBoYXZlIHRoZSBvcHBvcnR1bml0eSBhdCBJRVRGIExhc3QgQ2FsbCAod2hpY2ggaGFz IGEgcG9pbnRlciB0byBJUFIpIHRvIGRpc2N1c3MvZXhwcmVzcyBjb25jZXJuLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SWYgeW91IHdvdWxkIGxpa2UgdG8gZGlzY3Vzcy9yZWNvbW1lbmQgYWRkaXRpb25hbCBjb25zaWRl cmF0aW9ucyBmb3IgdGhlIElFVEYgdG8gZm9sbG93IG9uIElQUiwgaXQgd291bGQgYmUgZ29vZCB0 byBjaGFuZ2UgdGhlIHN1YmplY3QgbGluZSBhcyBJIGRvbuKAmXQgdGhpbmsNCiB0aGUgY3VycmVu dCBzdWJqZWN0IGxpbmUgaXMgbXVjaCBvZiBhbiBhdHRlbnRpb24tZ3JhYmJlcjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFG NDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5J4oCZbGwgbGV0IHRoZSBhdXRob3JzIGFuc3dlciB5b3VyIHF1ZXN0aW9ucyBv biB0aGUgZHJhZnQgaXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdhaW4sIHRoYW5rcyBmb3IgeW91ciBjYXJl ZnVsIHJldmlldy08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVib3JhaDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBPY3RvYmVyIDE3LCAyMDE1IDQ6NTIgQU08 YnI+DQo8Yj5Ubzo8L2I+IFJvYmVydCBTcGFya3M8YnI+DQo8Yj5DYzo8L2I+IEdlbmVyYWwgQXJl YSBSZXZpZXcgVGVhbTsgaWV0ZkBpZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1w YWxzLXJlZHVuZGFuY3ktc3BlLmFsbEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog R2VuLWFydCBMQyByZXZpZXc6IGRyYWZ0LWlldGYtcGFscy1yZWR1bmRhbmN5LXNwZS0wMjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvYmVydCw8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHlvdXIgcmV2 aWV3IG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgUEFMUyBXRyBjby1jaGFpciwgSSB3b3VsZCBsaWtlIHRvIGFkZHJl c3Mgb25lIHBvaW50IGluIHlvdXIgcmV2aWV3OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGEg cHJvY2VzcyBpc3N1ZSB0aGF0IHRoZSBJRVNHIHNob3VsZCBwYXkgYXR0ZW50aW9uIHRvLiBUaGUg c2hlcGhlcmQgd3JpdGV1cCBzYXlzIHRoaXM6ICZxdW90O1RoZXJlIGlzIG9uZSBJUFIgZGVjbGFy YXRpb24gKDE5MTEpIHJhaXNlZCBpbiBOb3ZlbWJlciAyMDEyIGFnYWluc3QgYW4gZWFybHkgdmVy c2lvbiBvZiB0aGUgZHJhZnQuIFRoZXJlIHdhcyBubyBkaXNjdXNzaW9uIGluIHRoZSBXRyByZWxh dGVkDQogdG8gdGhpcy4mcXVvdDsgVGhhdCBoYXBwZW5zIHNvbWV0aW1lcywgYnV0IGl0J3MgbXVj aCBiZXR0ZXIgdG8gaGF2ZSBhIHJlYWwgaW5kaWNhdGlvbiB0aGF0IHRoZSBncm91cCBjb25zaWRl cmVkIHRoZSBkaXNjbG9zdXJlIGFuZCBleHBsaWNpdGx5IGRlY2lkZWQgbm90IHRvIGNoYW5nZSBk aXJlY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIElQUiBkZWNsYXJhdGlvbiBpcyBhZ2FpbnN0IHRoZSBvcmlnaW5h bCBpbmRpdmlkdWFsIGRyYWZ0LCZuYnNwO2RyYWZ0LWRvbmctcHdlMy1yZWR1bmRhbmN5LXNwZS4g VGhlIElQUiBkZWNsYXJhdGlvbiB3YXMgZnJvbSBhIGNvbXBhbnkgdGhhdCB3YXMgbm90IHJlcHJl c2VudGVkIGFzIGFuIGF1dGhvciBvbiB0aGUgZHJhZnQsIGFuZCBvZmZlcmVkIGZyZWUgbGljZW5j aW5nIHdpdGggcmVjaXByb2NpdHkuIEF0IHRoZQ0KIHRpbWUsIG5vIGNvbmNlcm5zIHdlcmUgcmFp c2VkIGJ5IGVpdGhlciB0aGUgYXV0aG9ycyBvciBmcm9tIGFueW9uZSBpbiB0aGUgV0cgaW4gcmVz cG9uc2UgdG8gdGhlIGRlY2xhcmF0aW9uLiBUaGlzLCBJTUhPLCBpcyBub3JtYWwgb3BlcmF0aW5n IHByb2NlZHVyZSB3aGVuIElQUiBkZWNsYXJhdGlvbnMgYXJlIG1hZGUsIGVzcGVjaWFsbHkgYnkg bm9uLWF1dGhvciBlbnRpdGllcyBhbmQgZWFybHkgaW4gdGhlIHByb2Nlc3MuIFRoZSB1c3VhbCBj b25jZXJuDQogaXMgd2hlbiBkZWNsYXJhdGlvbnMgY29tZSBpbiBsYXRlIGluIHRoZSBwcm9jZXNz LCBlc3BlY2lhbGx5IGZyb20gYW4gYXV0aG9yIGNvbXBhbnkuIE5laXRoZXIgd2FzIHRoZSBjYXNl IGhlcmUsIGl0IHdhcyBzdGlsbCBhbiBpbmRpdmlkdWFsIGRyYWZ0LiBBbmQgb2YgY291cnNlLCB0 aGUgZGVjbGFyYXRpb24gd2FzIGNsZWFyIGZvciBhbGwgdG8gc2VlIGR1cmluZyBib3RoIFdHIGFk b3B0aW9uIGFuZCBXRyBMQyBwb2xscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy aSwgT2N0IDE2LCAyMDE1IGF0IDExOjMwIFBNLCBSb2JlcnQgU3BhcmtzICZsdDs8YSBocmVmPSJt YWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5yanNwYXJrc0Bub3N0 cnVtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJU IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhPGJyPg0KUmV2aWV3IFRl YW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZDxi cj4NCmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4mbmJzcDsgUGxlYXNlIHRyZWF0IHRo ZXNlIGNvbW1lbnRzIGp1c3Q8YnI+DQpsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMu PGJyPg0KPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdDxi cj4NCjxicj4NCiZsdDs8YSBocmVmPSJodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9hcmVhL2dl bi90cmFjL3dpa2kvR2VuQXJ0ZmFxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3dpa2kudG9vbHMu aWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcTwvYT4mZ3Q7Ljxicj4NCjxicj4N CkRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbHMtcmVkdW5kYW5jeS1zcGUtMDI8YnI+DQpSZXZpZXdl cjogUm9iZXJ0IFNwYXJrczxicj4NClJldmlldyBEYXRlOiAxNiBPY3QgMjAxNTxicj4NCklFVEYg TEMgRW5kIERhdGU6IDE5IE9jdCAyMDE1PGJyPg0KSUVTRyBUZWxlY2hhdCBkYXRlOiAyMiBPY3Qg MjAxNTxicj4NCjxicj4NClN1bW1hcnk6IEFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMg UFMgYnV0IHdpdGggaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBkaXNjdXNzZWQvYWRkcmVzc2VkPGJy Pg0KPGJyPg0KVGhpcyBkb2N1bWVudCBpcyBoYXJkIHRvIHJlYWQuIEl0IGlzIG1vcmUgYWNyb255 bS1sYWRlbiB0aGFuIGl0PGJyPg0KbmVlZHMgdG8gYmUuPGJyPg0KPGJyPg0KLS0tLS08YnI+DQpU aGVyZSBpcyBhIHByb2Nlc3MgaXNzdWUgdGhhdCB0aGUgSUVTRyBzaG91bGQgcGF5IGF0dGVudGlv biB0by48YnI+DQpUaGUgc2hlcGhlcmQgd3JpdGV1cCBzYXlzIHRoaXM6PGJyPg0KPGJyPg0KJm5i c3A7ICZxdW90O1RoZXJlIGlzIG9uZSBJUFIgZGVjbGFyYXRpb24gKDE5MTEpIHJhaXNlZCBpbiBO b3ZlbWJlciAyMDEyIGFnYWluc3Q8YnI+DQombmJzcDsgJm5ic3A7YW4gZWFybHkgdmVyc2lvbiBv ZiB0aGUgZHJhZnQuJm5ic3A7IFRoZXJlIHdhcyBubyBkaXNjdXNzaW9uIGluIHRoZSBXRzxicj4N CiZuYnNwOyAmbmJzcDtyZWxhdGVkIHRvIHRoaXMuJnF1b3Q7PGJyPg0KPGJyPg0KVGhhdCBoYXBw ZW5zIHNvbWV0aW1lcywgYnV0IGl0J3MgbXVjaCBiZXR0ZXIgdG8gaGF2ZSBhIHJlYWwgaW5kaWNh dGlvbjxicj4NCnRoYXQgdGhlIGdyb3VwIGNvbnNpZGVyZWQgdGhlIGRpc2Nsb3N1cmUgYW5kIGV4 cGxpY2l0bHkgZGVjaWRlZCBub3QgdG88YnI+DQpjaGFuZ2UgZGlyZWN0aW9ucy48YnI+DQotLS0t LTxicj4NCjxicj4NClRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSAybmQgcGFyYWdyYXBoIChkZWNs YXJpbmcgbXVsdGktaG9taW5nIG9uIGJvdGg8YnI+DQpzaWRlcyBvZiBhbiBTLVBFIG91dCBvZiBz Y29wZSkgc2hvdWxkIGJlIG1vdmVkIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50Ljxicj4NClRoZSBp bnRyb2R1Y3Rpb24gYW5kIHBlcmhhcHMgZXZlbiB0aGUgYWJzdHJhY3QgY2FuIGJlIGNsZWFyZXIg YWJvdXQ8YnI+DQp3aGF0IF9pc18gaW4gc2NvcGUuPGJyPg0KPGJyPg0KSXQgbmVlZHMgdG8gYmUg Y2xlYXJlciB3aGVyZSB0aGUgbm9ybWF0aXZlIGRlc2NyaXB0aW9uIG9mIGJlaGF2aW9yIGlzLjxi cj4NCkkgdGhpbmsgeW91J3JlIGludGVuZGluZyBpdCB0byBiZSB0aGUgZmlyc3QgcGFydCBvZiBz ZWN0aW9uIDMuIEkgaGF2ZTxicj4NCm5vdCB3b3JrZWQgdGhyb3VnaCB0aGUgcmVmZXJlbmNlcyBl bm91Z2ggdG8gZW5zdXJlIHRoYXQgaXQgaXMgY29tcGxldGUuPGJyPg0KPGJyPg0KVGhlIHRoaXJk IHBhcmFncmFwaCBzdGFydHMgb2ZmICZxdW90O0luIGdlbmVyYWwsIC4uLiZxdW90Oy4gQXJlIHRo ZXJlIGFueTxicj4NCnNwZWNpZmljIGNhc2VzIHdoZXJlIHRoZSByZXF1aXJlbWVudHMgdGhhdCBm b2xsb3cgZG8gbm90IGhvbGQ/IElmIHNvLDxicj4NCnRoZXJlIG5lZWRzIHRvIGJlIG1vcmUgZGVz Y3JpcHRpb24uIElmIG5vdCwgcGxlYXNlIGRlbGV0ZSAmcXVvdDtJbiBnZW5lcmFsLCZxdW90Oy48 YnI+DQo8YnI+DQpBcmUgc2VjdGlvbnMgMy4xIGFuZCAzLjIgc3VwcG9zZWQgdG8gYmUgb25seSBl eGFtcGxlcz8gV291bGQgdGhlPGJyPg0Kc3BlY2lmaWNhdGlvbiBvZiB0aGUgcHJvdG9jb2wgYmUg Y29tcGxldGUgaWYgdGhleSB3ZXJlIGRlbGV0ZWQ/IElmIG5vdCw8YnI+DQpzb21ldGhpbmcgbmVl ZHMgdG8gYmUgbW92ZWQgdXAgaW50byB0aGUgbWFpbiBwYXJ0IG9mIHNlY3Rpb24gMy48YnI+DQpG b3IgaW5zdGFuY2UsIGlzIHRoZSBTSE9VTEQgYXQgdGhlIGVuZCBvZiAzLjEgYSByZXF1aXJlbWVu dCBwbGFjZWQgYnk8YnI+DQp0aGlzIGRvY3VtZW50LCBvciBpcyBpdCByZXN0YXRpbmcgYSByZXF1 aXJlbWVudCBmcm9tIHNvbWV3aGVyZSBlbHNlPzxicj4NClNpbWlsYXJseSwgcGxlYXNlIGluc3Bl Y3QgdGhlIFNIT1VMRCBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiAzLjIuPGJyPg0KPGJyPg0K SSBhbHNvIHN1Z2dlc3QgbW92aW5nIDMuMSBhbmQgMy4yIGludG8gdGhlaXIgb3duIHNlY3Rpb24s IGNsZWFybHk8YnI+DQpsYWJlbGluZyB0aGVtIGFzIGV4YW1wbGVzLjxicj4NCjxicj4NCklzIGl0 IHdvcnRoIG1vcmUgZXhwbGFuYXRpb24gaW4gdGhlIGRvY3VtZW50IHdoeSB5b3UndmUgYWRkZWQg dGhlPGJyPg0KTVVTVCBOT1QgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDM/PGJy Pg0KPGJyPg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gb25seSBwb2ludHMg b2ZmIHRvIG90aGVyIGRvY3VtZW50cy48YnI+DQpNb3N0IG9mIHRob3NlIGp1c3QgcG9pbnQgdG8g ZWFjaCBvdGhlci4gQ2hhc2luZyBpdCBiYWNrLCB0aGVyZSdzIHNvbWU8YnI+DQptZWF0IGluIHRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIDQ0NDcsIGFuZCBzb21lIGluIDUw ODUsPGJyPg0KYnV0IGl0J3MgYSByZWFsIGNoYXNlIHRvIGZpbmQgd2hhdCdzIHJlbGV2YW50LiZu YnNwOyBQbGVhc2UgY29uc2lkZXIgY2FsbGluZzxicj4NCm91dCB3aGF0IGFuIGltcGxlbWVudGVy IG5lZWRzIHRvIGNvbnNpZGVyIGV4cGxpY2l0bHkgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C8527548C0MISOUT7MSGUSRDE_-- From nobody Mon Oct 19 00:12:50 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6231A1B61; Mon, 19 Oct 2015 00:12:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019071248.20218.18663.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 00:12:48 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-dual-homing-coordination-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 07:12:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection Authors : Weiqiang Cheng Lei Wang Han Li Kai Liu Shahram Davari Jie Dong Alessandro D'Alessandro Filename : draft-ietf-pals-mpls-tp-dual-homing-coordination-01.txt Pages : 13 Date : 2015-10-19 Abstract: In some scenarios, the MPLS Transport Profile (MPLS-TP) Pseudowires (PWs) are provisioned through either static configuration or management plane, where a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of Attachment Circuit (AC), the failure of Provider Edge (PE) and also the failure in the Packet Switched Network (PSN). The framework and scenarios for dual-homing pseudowire (PW) local protection are described in [draft-ietf-pals- mpls-tp-dual-homing-protection]. This document proposes a dual- homing coordination mechanism for MPLS-TP PWs, which is used for state exchange and coordination between the dual-homing PEs for dual- homing PW local protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-coordination/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-dual-homing-coordination-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-dual-homing-coordination-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 00:13:05 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FBA1A21C1; Mon, 19 Oct 2015 00:12:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019071257.11733.32037.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 00:12:57 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-dual-homing-protection-01.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 07:12:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : Dual-Homing Protection for MPLS and MPLS-TP Pseudowires Authors : Weiqiang Cheng Lei Wang Han Li Kai Liu Shahram Davari Jie Dong Alessandro D'Alessandro Filename : draft-ietf-pals-mpls-tp-dual-homing-protection-01.txt Pages : 11 Date : 2015-10-19 Abstract: This document describes a framework and several scenarios for pseudowire (PW) dual-homing local protection. A Dual-Node Interconnection (DNI) PW is provisioned between the dual-homing Provider Edge (PE) nodes for carrying traffic when failure occurs in the Attachment Circuit (AC) or PW side. In order for the dual-homing PE nodes to determine the forwarding state of AC, PW and the DNI PW, necessary state exchange and coordination between the dual-homing PEs are needed. The PW dual-homing local protection mechanism is complementary to the existing PW protection mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-dual-homing-protection-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-dual-homing-protection-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 11:22:04 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AB71B2B65; Mon, 19 Oct 2015 11:22:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019182200.4130.21008.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 11:22:00 -0700 Archived-At: Cc: pals-chairs@ietf.org, draft-ietf-pals-ms-pw-protection.all@ietf.org, draft-ietf-pals-ms-pw-protection@ietf.org, pals@ietf.org, stbryant@cisco.com Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:22:00 -0000 Barry Leiba has entered the following ballot position for draft-ietf-pals-ms-pw-protection-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just total nit-level stuff here: unexpanded abbreviations that should be expanded. Note to responsible AD: "OAM" should certainly be flagged in the RFC Editor's abbreviation list as not requiring expansion, and it's not so flagged. -- Introduction -- PE, MPLS-TP, L2TP -- Section 2 -- CE, AC (in fig 1) -- Appendix A -- SDH, OTN, G-ACh From nobody Mon Oct 19 11:30:46 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EABBE1ACD95; Mon, 19 Oct 2015 11:30:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019183044.16657.40713.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 11:30:44 -0700 Archived-At: Cc: pals-chairs@ietf.org, draft-ietf-pals-ms-pw-protection@ietf.org, pals@ietf.org, stbryant@cisco.com Subject: [Pals] Alvaro Retana's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:30:45 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-pals-ms-pw-protection-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate all the background given, it makes the text very clear. I have one question: Is it that easy? The substantive part of this document is "the PW status signaling defined in RFC 6478 MUST be used…in place of LDP-based status signaling". Do all the parts of Sections 6 and 7 of RFC 6870 just translate to the alternate signaling? For example (this is the first thing that I found, nothing special about it), 6.2 (RFC6870) says that "a common Group ID in the PWid FEC element or a PW Grouping ID TLV in the Generalized PWid FEC element, as defined in [2], MAY be used to signal PWs in groups in order to minimize the number of LDP status messages that MUST be sent." I found the Status TLV in RFC6478, but not these other ones — I may of course be missing the references.. I have other minor comments: 1. Just a nit.. It's interesting how (in the Introduction) when presenting the optional mechanism the text says that it "MUST be identically provisioned in the PE endpoints". However, then talking about the MTI mechanism (in Section 3. (Operational Considerations)), the text "just" says that "operational care must be taken so that the endpoint T-PEs are identically provisioned". [To be fair, the same "low key" text is later included in the Appendix referring to the optional mechanism.] The text itself is not a big deal to me..it just caught my attention the difference in treatment when for either mechanism to work both endpoints must be provisioned the same say. 2. Section 1. (Introduction) Please expand PSN and put a reference in for "PSN tunnel protection", or at least make it clear that the protection you're referring to is what was described above (at least that's my guess). 3. Section 2: s/in the place of LDP-based/in place of LDP-based From nobody Mon Oct 19 11:48:21 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A771B2BAE; Mon, 19 Oct 2015 11:48:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019184817.13135.13069.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 11:48:17 -0700 Archived-At: Cc: pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org, agmalis@gmail.com, draft-ietf-pals-mpls-tp-mac-wd@ietf.org, pals@ietf.org Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pals-mpls-tp-mac-wd-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 18:48:17 -0000 Barry Leiba has entered the following ballot position for draft-ietf-pals-mpls-tp-mac-wd-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just total nit-level stuff here, mostly unexpanded abbreviations that should be expanded. Note to responsible AD: While "MAC", by itself, still needs to be expanded (because of multiple possible meanings), "MAC address", as a unit, probably qualifies for flagging in the RFC Editor's abbreviation list as not requiring expansion. -- Abstract -- PW, VPLS, H-VPLS (Because the abstract has to stand alone.) -- Introduction -- PBB. It would also help to have a forward pointer to Section 2, though I honestly don't know how to do that without having it look silly. -- Section 2 -- For MPLS, "Multiprotocol" (one word, no capital "P") is the preferred spelling. For PW, "Pseudowire" (no capital "W") is the preferred spelling. -- Section 3 -- H-VPLS -- Section 4.2 -- A MAC withdraw message with 'R' bit set MUST be processed by resetting the send and receive sequence number first. I suggest making it "the send-and-receive sequence number" (with hyphens), so no one thinks there are two sequence numbers (and gets confused by it not being "numbers"). From nobody Mon Oct 19 12:02:48 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA6F1B2BAD; Mon, 19 Oct 2015 12:02:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019190245.23780.10531.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 12:02:45 -0700 Archived-At: Cc: draft-ietf-pals-redundancy-spe.all@ietf.org, matthew.bocci@alcatel-lucent.com, pals-chairs@ietf.org, draft-ietf-pals-redundancy-spe@ietf.org, pals@ietf.org Subject: [Pals] Barry Leiba's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:02:45 -0000 Barry Leiba has entered the following ballot position for draft-ietf-pals-redundancy-spe-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just total nit-level stuff here: unexpanded abbreviations that should be expanded. -- Abstract -- PE, T-PE (Because the abstract has to stand alone.) -- Section 2.1 -- CE -- Section 3.1 -- AC -- Section 4 -- CC, VCCV From nobody Mon Oct 19 13:04:24 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CF71A9080; Mon, 19 Oct 2015 13:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QF6DmcrlUdH; Mon, 19 Oct 2015 13:04:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A54D1A9073; Mon, 19 Oct 2015 13:04:01 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id C1D6E207D5605; Mon, 19 Oct 2015 20:03:54 +0000 (GMT) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t9JK3u4s030641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Oct 2015 20:03:57 GMT Received: from igoyret-c1.alcatel-lucent.com (vpn-9-153.vpn.alcatel-lucent.com [135.224.9.153]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id t9JK3sgH010715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Oct 2015 13:03:55 -0700 Message-Id: <201510192003.t9JK3sgH010715@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Oct 2015 13:03:48 -0700 To: l2tpext@ietf.org From: Ignacio Goyret In-Reply-To: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> References: <201510191639.t9JGdXLG004819@cliff.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Archived-At: Cc: rtg-bfd@ietf.org, pals@ietf.org Subject: [Pals] WGLC for draft-ietf-l2tpext-sbfd-discriminator X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:04:05 -0000 Sent again to include WGs that should also be in the loop. -Ignacio At 09:39 10/19/2015, Ignacio Goyret wrote: >Hi group, > >This email starts a two-week Working-Group Last-Call (WGLC) for >draft-ietf-l2tpext-sbfd-discriminator-00 >http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ > >Please send comments to the list and state whether or not you support >progressing this document (in the later case, please also state the >reasons). Silence is not indication of support. > >This poll runs until ** November 3rd, 2015 **. > >We are also polling for knowledge of any IPR that applies to this >draft, to ensure that IPR has been disclosed in compliance with >IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > >* If you are listed as a document author or contributor *, please >respond only if you are aware of any changes to IPR from your >response during the poll for adoption, at http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html > >If you are *not* listed as an author or contributor, then please >explicitly respond only if you are aware of any IPR that has not >yet been disclosed in conformance with IETF rules. > >Thank you, > >Carlos and Ignacio >L2tpext co-chairs > >_______________________________________________ >L2tpext mailing list >L2tpext@ietf.org >https://www.ietf.org/mailman/listinfo/l2tpext From nobody Mon Oct 19 13:22:08 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF11A92B3; Mon, 19 Oct 2015 13:21:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019202150.5112.33326.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 13:21:50 -0700 Archived-At: Cc: pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org, agmalis@gmail.com, draft-ietf-pals-mpls-tp-mac-wd@ietf.org, pals@ietf.org Subject: [Pals] Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:21:50 -0000 Alia Atlas has entered the following ballot position for draft-ietf-pals-mpls-tp-mac-wd-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I expect that this is a very simple and quick Discuss to deal with. 1) In Sec 4.1, it first says "The retransmission MUST be ceased anytime when ACK is received or after three retries." which is fine but then - "For instance, 1 second retransmission with three retries in absence of ACK response is suggested in this document. However, incremental backoff with higher number of retries is also feasible and may be worth consideration to address the scale issues. This document does not mandate a strict guideline since there are no interoperability implications." CLEARLY, using MUST is more than a gentle suggestion - but is exactly mandating a strict guideline. Please fix either the MUST or the remaining text. From nobody Mon Oct 19 13:54:59 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7E1ACDD9; Mon, 19 Oct 2015 13:54:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019205439.24192.12632.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 13:54:39 -0700 Archived-At: Cc: pals-chairs@ietf.org, agmalis@gmail.com, draft-ietf-pals-mpls-tp-mac-wd@ietf.org, pals@ietf.org Subject: [Pals] Alvaro Retana's No Objection on draft-ietf-pals-mpls-tp-mac-wd-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:54:40 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-pals-mpls-tp-mac-wd-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some comments that, while non-blocking, I would like to see addressed before publication. 1. Section 3. (MAC Withdraw OAM Message) I don't understand why "when sequence number wraps, all MAC addresses are flushed". Presumably, the wrap in the sequence number would be the result of a new MAC List TLV, so why would all the addresses be flushed and not just the ones on the list? What am I missing? 2. Section 4.1. (Operation of Sender) "…if a need to send a new MAC withdraw message with updated sequence number arises then retransmission of the older unacknowledged withdraw message MUST be suspended and retransmit time for the new sequence number MUST be initiated." That sounds fine to me, but I have a related question. Should the contents of the withdraw message include both the un-ack'ed list as well as the new addresses? It is not clear from the text above. I ask this in light of the text in Section 3 that reads: "The receipt of same or lower sequence number message is responded with ACK but does not cause removal of MAC addresses." IOW, if the un-ack'ed list is not included in the new message then those addresses may not be withdrawn. 3. Also in 4.1. "The 'R' reset bit is set in the first MAC withdraw…" I'm assuming the Sequence Number with the R-bit set will always be 1, is that true? Does the text mean that there will in fact be a MAC List TLV if the R-bit is set? Later in Section 4.2 it says that a message "…with 'R' bit set…MAC withdraw message processing is performed as described above." All this seems problematic due to the text ("above") that says: "If the sequence number in the received message is smaller than or equal to the value in the register, the MAC TLV(s) is/are not processed." IOW, of the R-bit is set (assuming Sew Number = 1), then the Seq Number will be smaller than whatever was received before and the MAC TLV will not be processed. The logic doesn't seem to work for me.. 4. Security Considerations. I traced all the way back to RFC4385, where it hints at the ability of an attacker to disrupt the PW by misusing the associated channel..but couldn't find an authoritative reference to whether spoofing or changing the messages in flight is an issue. I'm worried about the ability of someone to, for example, inject/modify the MAC List, or simply change the R-bit setting. I may just be paranoid, so please point me in the right direction. From nobody Mon Oct 19 14:21:11 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6D61B2CCA for ; Mon, 19 Oct 2015 14:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFPZLA3Tnjgd for ; Mon, 19 Oct 2015 14:20:53 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928FF1B2CCC for ; Mon, 19 Oct 2015 14:20:53 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-c6-5624fe310a49 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 46.49.32596.13EF4265; Mon, 19 Oct 2015 16:29:06 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 17:20:51 -0400 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: [Pals] PALS IETF 94 Slot Requests - Yokohama Thread-Index: AQHQ/xB5A8vWE7QZfEOujCPi3lHk7J5zaY7Q Date: Mon, 19 Oct 2015 21:20:51 +0000 Message-ID: <871EB8879748FA458598F0461906289322DCD4C4@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_871EB8879748FA458598F0461906289322DCD4C4eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPgq7RP5Uwg+17eCzW/FvH5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAU/Z7MUPNzCWDHtXy9TA+PPhYxdjJwcEgImEide3mODsMUk LtxbD2RzcQgJHGWUmLW4hRnCWc4oMXPhH7AqNqCOdRv3sIDYIgLKErvOTwGbJCxgKTHr8VOo uJXE7J0vgeIcQLaRxPJpJiAmi4CqRO8STZAKXgFfiZ6lc5hBbCEBfYmJ53YzgZRwChhI9D+2 BQkzAp3z/dQaJhCbWUBc4taT+UwQZwpILNlznhnCFpV4+fgfK4StJDFp6TlWiPp8iad/m1kg VglKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1O LctNNzLYxAiMlGMSbLo7GPe8tDzEKMDBqMTDu8BPJUyINbGsuDL3EKM0B4uSOO/+JfdDhQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTAWnim2lvdRceDe8uBRwRHhrtzJ/ZPddIp/SH91MzDc rnlYrX5DsZ5nylmXOLPKpirzrL7jglWH31z87XBDxLzhg8cOfbMznME73la8mD7n2fdNf/da VZ+UcZ51z/7YVfHleXZzPPfsyrsg8zj8yYF1X0LSxOT063wv7Ai99H1S1v0NPHPc3uxUYinO SDTUYi4qTgQAMEdjKHUCAAA= Archived-At: Subject: Re: [Pals] PALS IETF 94 Slot Requests - Yokohama X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 21:20:57 -0000 --_000_871EB8879748FA458598F0461906289322DCD4C4eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder... If you need a slot please follow the instructions below. Thanks! Dave From: Pals > on behalf = of David Sinicrope > Date: Friday, October 2, 2015 at 2:51 PM To: "pals@ietf.org" > Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama Hi All, It's that time again. If you need a presentation slot for the IETF 94 PALS session, please reply = to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests and be lost in my email, never to be fou= nd. :-) Form: 1. topic (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker - you only need to provide the file nam= e to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3= -mpls-eth-oam-iwk/): 3. brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting (e.g., need to address security issu= es and get direction from the WG): 4. requested duration (norm/default is 10 min): 5. speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave From: Patrice Brissette (pbrisset) [mailto:pbrisset@cisco.com] Sent: Sunday, October 04, 2015 21:52 To: David Sinicrope Subject: Re: [Pals] PALS IETF 94 Slot Requests - Yokohama Hi David, I'll like to have a slot regarding L2VPN Yang. Regards, Patrice [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.= png?ct=3D1406640631632] Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before y= ou print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: Pals > on behalf = of David Sinicrope > Date: Friday, October 2, 2015 at 2:51 PM To: "pals@ietf.org" > Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama Hi All, It's that time again. If you need a presentation slot for the IETF 94 PALS session, please reply = to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests and be lost in my email, never to be fou= nd. :-) Form: 1. topic (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker - you only need to provide the file nam= e to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3= -mpls-eth-oam-iwk/): 3. brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting (e.g., need to address security issu= es and get direction from the WG): 4. requested duration (norm/default is 10 min): 5. speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave --_000_871EB8879748FA458598F0461906289322DCD4C4eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reminder…<= /span>

If you need a slot please f= ollow the instructions below.

Thanks!

Dave

 

From: Pals <pals-bounces@ietf.org> on behalf of David Sinicrope <<= a href=3D"mailto:david.sinicrope@ericsson.com">david.sinicrope@ericsson.com= >
Date: Friday, October 2, 2015 at 2:51 PM
To: "pals@ietf.org" &= lt;pals@ietf.org>
Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama

 

Hi All,

It's that time again. =

If you need a presentation slot for th= e IETF 94 PALS session, please reply to this email (subjec= t intact) completing the form below.   

Please use this f= orm and please reply to this email with the subject intact.  (Not doing so probably means your req= uest will not trigger the filter I use to identify PALS slot requests = and be lost in my email, never to be found. :-)

 

Form:

1. topic (e.g., MPLS and Ethernet OAM Interworking):=

2. URL to your draft on Datatracker &#= 8211; you only need to provide the file name to the example URL (e.g.,=  http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/<= /a>):  

3. brief statement of objectives and i= ssues to be discussed and resolved via the presentation during the meeting =  (e.g., need to address security issues and get direction from the WG):  

4. requested duration (norm/default is= 10 min):  

5. speaker Given-name FAMILY-NAME (e.g= ., Dave SINICROPE):  

 

Thanks!

Dave

 <= /p>

 <= /p>

From: Patrice = Brissette (pbrisset) [mailto:pbrisset@cisco.com]
Sent: Sunday, October 04, 2015 21:52
To: David Sinicrope
Subject: Re: [Pals] PALS IETF 94 Slot Requests - Yokohama=

 

Hi David,=

 

I’ll like to have a s= lot regarding L2VPN Yang.

 

 

Regards,<= /p>

 

Patrice

   

Patrice Brissette
TECHNICAL LEADER.ENGINEERING

pbrisset@cisco.com
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes = Cisco Canada CIE
Canada
Cisco.com

 

Think before you print.

This email may contain confidential and privileg= ed material for the sole use of the intended recipient. Any review, use, di= stribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the re= cipient), please contact the sender by reply email and delete all copies of= this message.

Please click here for Company Registratio= n Information.


 

From: Pals <pals-bounces@ietf.org> on behalf of David Sinicrope <<= a href=3D"mailto:david.sinicrope@ericsson.com">david.sinicrope@ericsson.com= >
Date: Friday, October 2, 2015 at 2:51 PM
To: "pals@ietf.org" &= lt;pals@ietf.org>
Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama

 

Hi All,

It's that time again. =

If you need a presentation slot for th= e IETF 94 PALS session, please reply to this email (subjec= t intact) completing the form below.   

Please use this f= orm and please reply to this email with the subject intact.  (Not doing so probably means your req= uest will not trigger the filter I use to identify PALS slot requests = and be lost in my email, never to be found. :-)

 

Form:

1. topic (e.g., MPLS and Ethernet OAM Interworking):=

--_000_871EB8879748FA458598F0461906289322DCD4C4eusaamb103erics_-- From nobody Mon Oct 19 15:29:45 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 996DA1B2BA2; Mon, 19 Oct 2015 15:29:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019222942.27008.68490.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 15:29:42 -0700 Archived-At: Cc: pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org, agmalis@gmail.com, draft-ietf-pals-mpls-tp-mac-wd@ietf.org, pals@ietf.org Subject: [Pals] Ben Campbell's No Objection on draft-ietf-pals-mpls-tp-mac-wd-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:29:42 -0000 Ben Campbell has entered the following ballot position for draft-ietf-pals-mpls-tp-mac-wd-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a few editorial comments: - Please expand PW, H-VPLS and PBB-VPLS on first mention. (The abbreviation list is helpful, but it's still good to expand them in place on first mention.) - section 1, first paragraph: s/withdrawl/withdrawal - section 3: "A single bit (called A-bit) is set to indicate if a MAC withdraw message is for ACK" I don't understand what this means, and I don't find any further explanation of the A-Bit. Do you mean to say that the MAC withdraw message requires an ACK? Isn't that always true? If the A-bit is already defined elsewhere, a citation would be helpful. - Paragraph starting with "Only half of the sequence number space is used. " It seems odd to find that between the descriptions of the A and R bits. Does it relate to the A-Bit, or does it stand alone? (I gather the latter.) - There's an empty "Informative References" section. From nobody Mon Oct 19 15:48:09 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF11AD365; Mon, 19 Oct 2015 15:48:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019224808.30921.87349.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 15:48:08 -0700 Archived-At: Cc: matthew.bocci@alcatel-lucent.com, draft-ietf-pals-redundancy-spe@ietf.org, linda.dunbar@huawei.com, pals-chairs@ietf.org, pals@ietf.org, draft-ietf-pals-redundancy-spe.all@ietf.org Subject: [Pals] Benoit Claise's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:48:08 -0000 Benoit Claise has entered the following ballot position for draft-ietf-pals-redundancy-spe-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection regarding the publication of the document. However, based on Linda Dunbar's OPS DIR review, and the Jimmy's answer, a new revision is needed with the agreed changed (see the OPS DIR list for the details) From nobody Mon Oct 19 16:02:07 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B309C1B2E6F; Mon, 19 Oct 2015 16:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019230202.6198.16810.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 16:02:02 -0700 Archived-At: Cc: draft-ietf-pals-redundancy-spe.all@ietf.org, matthew.bocci@alcatel-lucent.com, pals-chairs@ietf.org, draft-ietf-pals-redundancy-spe@ietf.org, pals@ietf.org Subject: [Pals] Ben Campbell's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 23:02:02 -0000 Ben Campbell has entered the following ballot position for draft-ietf-pals-redundancy-spe-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just some very minor nits: - section 1, 2nd paragraph: s/provide/providing - section 3 and subsections: Several occurrences of "Active Preferential Forwarding status bit" need a leading "the". From nobody Mon Oct 19 19:34:23 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21631AD375; Mon, 19 Oct 2015 19:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cjsx1NAz2kab; Mon, 19 Oct 2015 19:34:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5DA1AD373; Mon, 19 Oct 2015 19:34:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCT51997; Tue, 20 Oct 2015 02:34:14 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 20 Oct 2015 03:34:10 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Tue, 20 Oct 2015 10:34:04 +0800 From: "Dongjie (Jimmy)" To: Robert Sparks , General Area Review Team , "pals@ietf.org" , "draft-ietf-pals-redundancy-spe.all@ietf.org" Thread-Topic: Gen-art LC review: draft-ietf-pals-redundancy-spe-02 Thread-Index: AQHRCFoBAjbu6kcumUySNbKvi0Guup5yhQ/w Date: Tue, 20 Oct 2015 02:34:03 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927743BD6AC@nkgeml512-mbx.china.huawei.com> References: <56216C90.4060606@nostrum.com> In-Reply-To: <56216C90.4060606@nostrum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 02:34:19 -0000 SGkgUm9iZXJ0LCANCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMu IFBsZWFzZSBzZWUgbXkgcmVwbGllcyBpbmxpbmU6DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogaWV0ZiBbbWFpbHRvOmlldGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFJvYmVydCBTcGFya3MNCj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMTcsIDIwMTUg NTozMSBBTQ0KPiBUbzogR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtOyBpZXRmQGlldGYub3JnOyBw YWxzQGlldGYub3JnOw0KPiBkcmFmdC1pZXRmLXBhbHMtcmVkdW5kYW5jZS1zcGUuYWxsQGlldGYu b3JnDQo+IFN1YmplY3Q6IEdlbi1hcnQgTEMgcmV2aWV3OiBkcmFmdC1pZXRmLXBhbHMtcmVkdW5k YW5jeS1zcGUtMDINCj4gDQo+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWEgUmV2aWV3DQo+IFRlYW0gKEdlbi1BUlQpIHJl dmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRyBmb3Ig dGhlDQo+IElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBGb3IgbW9yZSBpbmZvcm1hdGlv biwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQo+IA0KPiA8aHR0cDovL3dpa2kudG9vbHMuaWV0Zi5v cmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQo+IA0KPiBEb2N1bWVudDogZHJhZnQt aWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3BlLTAyDQo+IFJldmlld2VyOiBSb2JlcnQgU3BhcmtzDQo+ IFJldmlldyBEYXRlOiAxNiBPY3QgMjAxNQ0KPiBJRVRGIExDIEVuZCBEYXRlOiAxOSBPY3QgMjAx NQ0KPiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIyIE9jdCAyMDE1DQo+IA0KPiBTdW1tYXJ5OiBBbG1v c3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIFBTIGJ1dCB3aXRoIGlzc3VlcyB0aGF0IG5lZWQg dG8gYmUNCj4gZGlzY3Vzc2VkL2FkZHJlc3NlZA0KPiANCj4gVGhpcyBkb2N1bWVudCBpcyBoYXJk IHRvIHJlYWQuIEl0IGlzIG1vcmUgYWNyb255bS1sYWRlbiB0aGFuIGl0IG5lZWRzIHRvIGJlLg0K DQpXZSB3aWxsIGV4cGFuZCB0aGUgYWNyb255bXMgb24gZmlyc3QgdXNlIGluIG5leHQgcmV2aXNp b24uDQoNCj4gLS0tLS0NCj4gVGhlcmUgaXMgYSBwcm9jZXNzIGlzc3VlIHRoYXQgdGhlIElFU0cg c2hvdWxkIHBheSBhdHRlbnRpb24gdG8uDQo+IFRoZSBzaGVwaGVyZCB3cml0ZXVwIHNheXMgdGhp czoNCj4gDQo+ICAgICJUaGVyZSBpcyBvbmUgSVBSIGRlY2xhcmF0aW9uICgxOTExKSByYWlzZWQg aW4gTm92ZW1iZXIgMjAxMiBhZ2FpbnN0DQo+ICAgICBhbiBlYXJseSB2ZXJzaW9uIG9mIHRoZSBk cmFmdC4gIFRoZXJlIHdhcyBubyBkaXNjdXNzaW9uIGluIHRoZSBXRw0KPiAgICAgcmVsYXRlZCB0 byB0aGlzLiINCj4gDQo+IFRoYXQgaGFwcGVucyBzb21ldGltZXMsIGJ1dCBpdCdzIG11Y2ggYmV0 dGVyIHRvIGhhdmUgYSByZWFsIGluZGljYXRpb24gdGhhdCB0aGUNCj4gZ3JvdXAgY29uc2lkZXJl ZCB0aGUgZGlzY2xvc3VyZSBhbmQgZXhwbGljaXRseSBkZWNpZGVkIG5vdCB0byBjaGFuZ2UgZGly ZWN0aW9ucy4NCj4gLS0tLS0NCg0KSSBob3BlIEFuZHkgYW5kIERlYm9yYWggaGF2ZSBzb2x2ZWQg eW91ciBjb25jZXJuIG9uIHRoaXMuDQoNCj4gVGhlIGxhc3Qgc2VudGVuY2Ugb2YgdGhlIDJuZCBw YXJhZ3JhcGggKGRlY2xhcmluZyBtdWx0aS1ob21pbmcgb24gYm90aCBzaWRlcyBvZg0KPiBhbiBT LVBFIG91dCBvZiBzY29wZSkgc2hvdWxkIGJlIG1vdmVkIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50 Lg0KPiBUaGUgaW50cm9kdWN0aW9uIGFuZCBwZXJoYXBzIGV2ZW4gdGhlIGFic3RyYWN0IGNhbiBi ZSBjbGVhcmVyIGFib3V0IHdoYXQgX2lzXw0KPiBpbiBzY29wZS4NCg0KQWdyZWVkLCB3aWxsIG1v dmUgaXQgdG8gdGhlIGludHJvZHVjdGlvbiBvZiB0aGUgZG9jdW1lbnQuDQoNCj4gSXQgbmVlZHMg dG8gYmUgY2xlYXJlciB3aGVyZSB0aGUgbm9ybWF0aXZlIGRlc2NyaXB0aW9uIG9mIGJlaGF2aW9y IGlzLg0KPiBJIHRoaW5rIHlvdSdyZSBpbnRlbmRpbmcgaXQgdG8gYmUgdGhlIGZpcnN0IHBhcnQg b2Ygc2VjdGlvbiAzLiBJIGhhdmUgbm90IHdvcmtlZA0KPiB0aHJvdWdoIHRoZSByZWZlcmVuY2Vz IGVub3VnaCB0byBlbnN1cmUgdGhhdCBpdCBpcyBjb21wbGV0ZS4NCg0KWWVzLCB0aGUgZmlyc3Qg cGFydCBvZiBzZWN0aW9uIDMgZGVmaW5lcyB0aGUgb3BlcmF0aW9uIG9mIFMtUEUuDQoNCj4gVGhl IHRoaXJkIHBhcmFncmFwaCBzdGFydHMgb2ZmICJJbiBnZW5lcmFsLCAuLi4iLiBBcmUgdGhlcmUg YW55IHNwZWNpZmljIGNhc2VzDQo+IHdoZXJlIHRoZSByZXF1aXJlbWVudHMgdGhhdCBmb2xsb3cg ZG8gbm90IGhvbGQ/IElmIHNvLCB0aGVyZSBuZWVkcyB0byBiZSBtb3JlDQo+IGRlc2NyaXB0aW9u LiBJZiBub3QsIHBsZWFzZSBkZWxldGUgIkluIGdlbmVyYWwsIi4NCg0KV2Ugd2lsbCByZW1vdmUg ImluIGdlbmVyYWwiIGluIG5leHQgcmV2aXNpb24uDQoNCj4gQXJlIHNlY3Rpb25zIDMuMSBhbmQg My4yIHN1cHBvc2VkIHRvIGJlIG9ubHkgZXhhbXBsZXM/IFdvdWxkIHRoZSBzcGVjaWZpY2F0aW9u DQo+IG9mIHRoZSBwcm90b2NvbCBiZSBjb21wbGV0ZSBpZiB0aGV5IHdlcmUgZGVsZXRlZD8gSWYg bm90LCBzb21ldGhpbmcgbmVlZHMgdG8gYmUNCj4gbW92ZWQgdXAgaW50byB0aGUgbWFpbiBwYXJ0 IG9mIHNlY3Rpb24gMy4NCj4gRm9yIGluc3RhbmNlLCBpcyB0aGUgU0hPVUxEIGF0IHRoZSBlbmQg b2YgMy4xIGEgcmVxdWlyZW1lbnQgcGxhY2VkIGJ5IHRoaXMNCj4gZG9jdW1lbnQsIG9yIGlzIGl0 IHJlc3RhdGluZyBhIHJlcXVpcmVtZW50IGZyb20gc29tZXdoZXJlIGVsc2U/DQo+IFNpbWlsYXJs eSwgcGxlYXNlIGluc3BlY3QgdGhlIFNIT1VMRCBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiAz LjIuDQo+IA0KPiBJIGFsc28gc3VnZ2VzdCBtb3ZpbmcgMy4xIGFuZCAzLjIgaW50byB0aGVpciBv d24gc2VjdGlvbiwgY2xlYXJseSBsYWJlbGluZyB0aGVtDQo+IGFzIGV4YW1wbGVzLg0KDQpHb29k IHF1ZXN0aW9uLiBUaGUgbGFzdCBzZW50ZW5jZSBvZiBzZWN0aW9uIDMuMSBhbmQgMy4yIGNhbiBi ZSBtb3ZlZCB1cCBpbnRvIHRoZSBtYWluIHBhcnQuDQoNClNpbmNlIHNlY3Rpb24gMy4xIGFuZCAz LjIgc3BlY2lmaWVzIHRoZSB0eXBpY2FsIHNjZW5hcmlvcywgbXkgZmVlbGluZyBpcyB0aGV5IGFy ZSBtb3JlIHRoYW4gZXhhbXBsZXMuIE1heSBiZSBiZXR0ZXIgdG8ga2VlcCB0aGVtIGluIHNlY3Rp b24gMz8NCg0KPiANCj4gSXMgaXQgd29ydGggbW9yZSBleHBsYW5hdGlvbiBpbiB0aGUgZG9jdW1l bnQgd2h5IHlvdSd2ZSBhZGRlZCB0aGUgTVVTVCBOT1QNCj4gaW4gdGhlIGZpcnN0IHBhcmFncmFw aCBvZiBzZWN0aW9uIDM/DQoNCkJlY2F1c2UgaWYgUy1QRSBCeXBhc3MgTW9kZSBpcyB1c2VkLCB0 aGUgUy1QRSB3aWxsIG5vdCByZWNlaXZlIHRoZSBQVyBzdGF0dXMgbWVzc2FnZSBvcmlnaW5hdGVk IGJ5IFQtUEVzLiBXZSB3aWxsIGFkZCBzb21lIGV4cGxhbmF0aW9uIGFib3V0IHRoaXMuDQoNCj4g DQo+IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9ubHkgcG9pbnRzIG9mZiB0 byBvdGhlciBkb2N1bWVudHMuDQo+IE1vc3Qgb2YgdGhvc2UganVzdCBwb2ludCB0byBlYWNoIG90 aGVyLiBDaGFzaW5nIGl0IGJhY2ssIHRoZXJlJ3Mgc29tZSBtZWF0IGluIHRoZQ0KPiBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIDQ0NDcsIGFuZCBzb21lIGluIDUwODUsIGJ1dCBp dCdzIGEgcmVhbCBjaGFzZQ0KPiB0byBmaW5kIHdoYXQncyByZWxldmFudC4gIFBsZWFzZSBjb25z aWRlciBjYWxsaW5nIG91dCB3aGF0IGFuIGltcGxlbWVudGVyDQo+IG5lZWRzIHRvIGNvbnNpZGVy IGV4cGxpY2l0bHkgaGVyZS4NCg0KU2luY2UgdGhpcyBkb2N1bWVudCBpcyBtYWlubHkgYWJvdXQg cmV1c2luZyB0aGUgcmVkdW5kYW5jeSBtZWNoYW5pc21zIG9mIFJGQzY4NzAgb24gdGhlIFMtUEUg bm9kZXMsIHdlIHRoaW5rIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiB0aGVzZSByZWZl cmVuY2VkIGRvY3VtZW50cyBjb3VsZCBzdWZmaWNlLg0KQW5kIGZvciBhbiBpbXBsZW1lbnRlciBJ TU8gdGhlcmUgaXMgbm90aGluZyBuZXcgdG8gYmUgY29uc2lkZXJlZC4NCg0KQmVzdCByZWdhcmRz LA0KSmllDQoNCg== From nobody Mon Oct 19 19:39:28 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2C1B29A2; Mon, 19 Oct 2015 19:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY-azREEblAM; Mon, 19 Oct 2015 19:39:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C411AD36E; Mon, 19 Oct 2015 19:39:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA01161; Tue, 20 Oct 2015 02:39:21 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 20 Oct 2015 03:39:20 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Tue, 20 Oct 2015 10:39:17 +0800 From: "Dongjie (Jimmy)" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) Thread-Index: AQHRCqDA6YFQrfBqBUSuJrtJOl4oCZ5zqlBA Date: Tue, 20 Oct 2015 02:39:16 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927743BD6C6@nkgeml512-mbx.china.huawei.com> References: <20151019190245.23780.10531.idtracker@ietfa.amsl.com> In-Reply-To: <20151019190245.23780.10531.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-pals-redundancy-spe.all@ietf.org" , "matthew.bocci@alcatel-lucent.com" , "pals-chairs@ietf.org" , "draft-ietf-pals-redundancy-spe@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 02:39:26 -0000 SGkgQmFycnksIA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBpbiBhIG5ldyByZXZpc2lvbiB3 ZSB3aWxsIGV4cGFuZCB0aGUgYWNyb255bXMgb24gZmlyc3QgdXNlLg0KDQpCZXN0IHJlZ2FyZHMs DQpKaWUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCYXJyeSBMZWli YSBbbWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDIwLCAyMDE1IDM6MDMgQU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBkcmFmdC1pZXRmLXBh bHMtcmVkdW5kYW5jeS1zcGVAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtcGFscy1yZWR1bmRhbmN5 LXNwZS5hbGxAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQGlldGYub3JnOw0KPiBtYXR0aGV3LmJvY2Np QGFsY2F0ZWwtbHVjZW50LmNvbTsgcGFsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBCYXJyeSBMZWli YSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXBhbHMtcmVkdW5kYW5jeS1zcGUtMDI6ICh3 aXRoDQo+IENPTU1FTlQpDQo+IA0KPiBCYXJyeSBMZWliYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3Bl LTAyOiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBp bnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXBhbHMtcmVkdW5kYW5jeS1zcGUvDQo+IA0KPiAN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g SnVzdCB0b3RhbCBuaXQtbGV2ZWwgc3R1ZmYgaGVyZTogdW5leHBhbmRlZCBhYmJyZXZpYXRpb25z IHRoYXQgc2hvdWxkIGJlDQo+IGV4cGFuZGVkLg0KPiANCj4gLS0gQWJzdHJhY3QgLS0NCj4gUEUs IFQtUEUNCj4gKEJlY2F1c2UgdGhlIGFic3RyYWN0IGhhcyB0byBzdGFuZCBhbG9uZS4pDQo+IA0K PiAtLSBTZWN0aW9uIDIuMSAtLQ0KPiBDRQ0KPiANCj4gLS0gU2VjdGlvbiAzLjEgLS0NCj4gQUMN Cj4gDQo+IC0tIFNlY3Rpb24gNCAtLQ0KPiBDQywgVkNDVg0KPiANCg0K From nobody Mon Oct 19 19:47:06 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC581ADEB6; Mon, 19 Oct 2015 19:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND6usPC4GqMX; Mon, 19 Oct 2015 19:46:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4C021B29CC; Mon, 19 Oct 2015 19:46:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCT52772; Tue, 20 Oct 2015 02:46:56 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 20 Oct 2015 03:46:55 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Tue, 20 Oct 2015 10:46:43 +0800 From: "Dongjie (Jimmy)" To: Benoit Claise , The IESG Thread-Topic: Benoit Claise's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) Thread-Index: AQHRCsA/ZSUQ9kDjc0yfpSdgwYwtEp5zrQHA Date: Tue, 20 Oct 2015 02:46:42 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927743BD731@nkgeml512-mbx.china.huawei.com> References: <20151019224808.30921.87349.idtracker@ietfa.amsl.com> In-Reply-To: <20151019224808.30921.87349.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "matthew.bocci@alcatel-lucent.com" , "draft-ietf-pals-redundancy-spe@ietf.org" , Linda Dunbar , "pals-chairs@ietf.org" , "pals@ietf.org" , "draft-ietf-pals-redundancy-spe.all@ietf.org" Subject: Re: [Pals] Benoit Claise's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 02:47:01 -0000 SGkgQmVub2l0LA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIHllcyB3ZSB3aWxsIHBvc3Qg YSBuZXcgcmV2aXNpb24gdG8gaW5jb3Jwb3JhdGUgYWxsIHRoZSBhZ3JlZWQgY2hhbmdlcy4NCg0K QmVzdCByZWdhcmRzLA0KSmllDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQmVub2l0IENsYWlzZSBbbWFpbHRvOmJjbGFpc2VAY2lzY28uY29tXQ0KPiBTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDIwLCAyMDE1IDY6NDggQU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBkcmFm dC1pZXRmLXBhbHMtcmVkdW5kYW5jeS1zcGVAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtcGFscy1y ZWR1bmRhbmN5LXNwZS5hbGxAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQGlldGYub3JnOw0KPiBtYXR0 aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbTsgcGFsc0BpZXRmLm9yZzsgTGluZGEgRHVuYmFy DQo+IFN1YmplY3Q6IEJlbm9pdCBDbGFpc2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1w YWxzLXJlZHVuZGFuY3ktc3BlLTAyOg0KPiAod2l0aCBDT01NRU5UKQ0KPiANCj4gQmVub2l0IENs YWlzZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJh ZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3BlLTAyOiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4g cmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5 IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5l cy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dl dmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXBh bHMtcmVkdW5kYW5jeS1zcGUvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVO VDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gTm8gb2JqZWN0aW9uIHJlZ2FyZGluZyB0aGUgcHVi bGljYXRpb24gb2YgdGhlIGRvY3VtZW50Lg0KPiBIb3dldmVyLCBiYXNlZCBvbiBMaW5kYSBEdW5i YXIncyBPUFMgRElSIHJldmlldywgYW5kIHRoZSBKaW1teSdzIGFuc3dlciwgYQ0KPiBuZXcgcmV2 aXNpb24gaXMgbmVlZGVkIHdpdGggdGhlIGFncmVlZCBjaGFuZ2VkIChzZWUgdGhlIE9QUyBESVIg bGlzdCBmb3IgdGhlDQo+IGRldGFpbHMpDQo+IA0KDQo= From nobody Mon Oct 19 20:01:29 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3EF1B29FC; Mon, 19 Oct 2015 20:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RTttAd1YtYu; Mon, 19 Oct 2015 20:01:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED991B29F6; Mon, 19 Oct 2015 20:01:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCT53873; Tue, 20 Oct 2015 03:01:20 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 20 Oct 2015 04:01:19 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 20 Oct 2015 11:01:14 +0800 From: "Dongjie (Jimmy)" To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) Thread-Index: AQHRCsIyFfmOMWBCs0mpSyyhLGr1/J5zrZDQ Date: Tue, 20 Oct 2015 03:01:12 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927743BD75A@nkgeml512-mbx.china.huawei.com> References: <20151019230202.6198.16810.idtracker@ietfa.amsl.com> In-Reply-To: <20151019230202.6198.16810.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-pals-redundancy-spe.all@ietf.org" , "matthew.bocci@alcatel-lucent.com" , "pals-chairs@ietf.org" , "draft-ietf-pals-redundancy-spe@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Ben Campbell's No Objection on draft-ietf-pals-redundancy-spe-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 03:01:25 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIHdpbGwgZml4IHRoZSBuaXRzIGlu IGEgbmV3IHJldmlzaW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5j b21dDQo+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjAsIDIwMTUgNzowMiBBTQ0KPiBUbzogVGhl IElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtcGFscy1yZWR1bmRhbmN5LXNwZUBpZXRmLm9yZzsNCj4g ZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3BlLmFsbEBpZXRmLm9yZzsgcGFscy1jaGFpcnNA aWV0Zi5vcmc7DQo+IG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tOyBwYWxzQGlldGYu b3JnDQo+IFN1YmplY3Q6IEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LXBhbHMtcmVkdW5kYW5jeS1zcGUtMDI6DQo+ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBCZW4gQ2Ft cGJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRy YWZ0LWlldGYtcGFscy1yZWR1bmRhbmN5LXNwZS0wMjogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93 ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1w YWxzLXJlZHVuZGFuY3ktc3BlLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1F TlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEp1c3Qgc29tZSB2ZXJ5IG1pbm9yIG5pdHM6DQo+ IA0KPiAtIHNlY3Rpb24gMSwgMm5kIHBhcmFncmFwaDoNCj4gDQo+IHMvcHJvdmlkZS9wcm92aWRp bmcNCj4gDQo+IC0gc2VjdGlvbiAzIGFuZCBzdWJzZWN0aW9uczoNCj4gDQo+IFNldmVyYWwgb2Nj dXJyZW5jZXMgb2YgIkFjdGl2ZSBQcmVmZXJlbnRpYWwgRm9yd2FyZGluZyBzdGF0dXMgYml0IiBu ZWVkIGENCj4gbGVhZGluZyAidGhlIi4NCj4gDQoNCg== From nobody Mon Oct 19 20:09:53 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2E31B2A38; Mon, 19 Oct 2015 20:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3ZtoXto2xtn; Mon, 19 Oct 2015 20:09:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ACA1B2A37; Mon, 19 Oct 2015 20:09:47 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9K39gMm075892 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 19 Oct 2015 22:09:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: "Dongjie (Jimmy)" , General Area Review Team , "pals@ietf.org" , "draft-ietf-pals-redundancy-spe.all@ietf.org" References: <56216C90.4060606@nostrum.com> <76CD132C3ADEF848BD84D028D243C927743BD6AC@nkgeml512-mbx.china.huawei.com> From: Robert Sparks Message-ID: <5625B071.6040303@nostrum.com> Date: Mon, 19 Oct 2015 22:09:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <76CD132C3ADEF848BD84D028D243C927743BD6AC@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pals] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 03:09:50 -0000 On 10/19/15 9:34 PM, Dongjie (Jimmy) wrote: > Hi Robert, > > Thanks a lot for your review and comments. Please see my replies inline: > >> -----Original Message----- >> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Robert Sparks >> Sent: Saturday, October 17, 2015 5:31 AM >> To: General Area Review Team; ietf@ietf.org; pals@ietf.org; >> draft-ietf-pals-redundance-spe.all@ietf.org >> Subject: Gen-art LC review: draft-ietf-pals-redundancy-spe-02 >> >> I am the assigned Gen-ART reviewer for this draft. The General Area Review >> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the >> IETF Chair. Please treat these comments just like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-pals-redundancy-spe-02 >> Reviewer: Robert Sparks >> Review Date: 16 Oct 2015 >> IETF LC End Date: 19 Oct 2015 >> IESG Telechat date: 22 Oct 2015 >> >> Summary: Almost ready for publication as PS but with issues that need to be >> discussed/addressed >> >> This document is hard to read. It is more acronym-laden than it needs to be. > We will expand the acronyms on first use in next revision. That won't change how hard this is to read. Expanding the acronyms on first use won't make the prose later in the document any different. The use of acronyms for the elements involved in almost all of the prose is unnecessary. The words for them are short enough. > >> ----- >> There is a process issue that the IESG should pay attention to. >> The shepherd writeup says this: >> >> "There is one IPR declaration (1911) raised in November 2012 against >> an early version of the draft. There was no discussion in the WG >> related to this." >> >> That happens sometimes, but it's much better to have a real indication that the >> group considered the disclosure and explicitly decided not to change directions. >> ----- > I hope Andy and Deborah have solved your concern on this. > >> The last sentence of the 2nd paragraph (declaring multi-homing on both sides of >> an S-PE out of scope) should be moved earlier in the document. >> The introduction and perhaps even the abstract can be clearer about what _is_ >> in scope. > Agreed, will move it to the introduction of the document. Thanks. > >> It needs to be clearer where the normative description of behavior is. >> I think you're intending it to be the first part of section 3. I have not worked >> through the references enough to ensure that it is complete. > Yes, the first part of section 3 defines the operation of S-PE. > >> The third paragraph starts off "In general, ...". Are there any specific cases >> where the requirements that follow do not hold? If so, there needs to be more >> description. If not, please delete "In general,". > We will remove "in general" in next revision. > >> Are sections 3.1 and 3.2 supposed to be only examples? Would the specification >> of the protocol be complete if they were deleted? If not, something needs to be >> moved up into the main part of section 3. >> For instance, is the SHOULD at the end of 3.1 a requirement placed by this >> document, or is it restating a requirement from somewhere else? >> Similarly, please inspect the SHOULD in the second paragraph of 3.2. >> >> I also suggest moving 3.1 and 3.2 into their own section, clearly labeling them >> as examples. > Good question. The last sentence of section 3.1 and 3.2 can be moved up into the main part. > > Since section 3.1 and 3.2 specifies the typical scenarios, my feeling is they are more than examples. May be better to keep them in section 3? No, I don't think so. If they can't be removed, then there is some part of this addition to the protocol suite that you are specifying by example, rather then specifying the behavior explicitly. That usually means you're under-specifying, and hoping people will infer (guess) the right thing to do in the unspecified cases. You will end up with better interoperability by being explicit. > >> Is it worth more explanation in the document why you've added the MUST NOT >> in the first paragraph of section 3? > Because if S-PE Bypass Mode is used, the S-PE will not receive the PW status message originated by T-PEs. We will add some explanation about this. Thanks again. > >> The security considerations section only points off to other documents. >> Most of those just point to each other. Chasing it back, there's some meat in the >> security considerations section of 4447, and some in 5085, but it's a real chase >> to find what's relevant. Please consider calling out what an implementer >> needs to consider explicitly here. > Since this document is mainly about reusing the redundancy mechanisms of RFC6870 on the S-PE nodes, we think the security considerations of these referenced documents could suffice. That misses the point - whatever is important in those considerations for what this document is talking about is buried. Why didn't you just copy the security considerations section of 6870 into this document? (I'm not suggesting you do that - your use of "mainly" above says that wouldn't be enough. _Why_ it's not enough is worth capturing in this document.) Isn't there something to new to say here about failure cases? You essentially have some new actors that (if they were to misbehave, or if someone could pretend to be them) could _cause_ at least the S-PE to believe there was a failure. Is that already discussed somewhere? > And for an implementer IMO there is nothing new to be considered. > > Best regards, > Jie > From nobody Mon Oct 19 22:10:52 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FE91A912B; Mon, 19 Oct 2015 22:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPcZ6tWd6mQI; Mon, 19 Oct 2015 22:10:45 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088281A90F6; Mon, 19 Oct 2015 22:10:42 -0700 (PDT) Received: by wijp11 with SMTP id p11so28953985wij.0; Mon, 19 Oct 2015 22:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6oPA53YIWsWO/A8sXDngtHCubEjgI4scYN+kBGPNlWI=; b=NT4zXTeMdsnCo+wEYv+a/K0T2c0Js6VVcM1EqNGNITqTouAjZETp9XzRxEUag9pBa4 QfO1UwLnlLj7k1H7OYChJC71B6l7Q0poBwRrmoUyOmEHRaLrjMw7vtTImRRyWCg2btlm eSYAwKusy5nNnFTIDR3Dl9RWUxeWYb4sO2eFTD0n1OGaZNx1CDHyg/mYXA+lXzX92bxY 4CO7MMXMXxCPwmXhCq3uz9uN+digYb/0JNGdgl5VeL55/reVoTxBXy4oyv0Uo6iqotwQ yqQ0V5GHDg59QQ1GnoaFANwCjM5GWTLQVtGewknCDq9YvLowAyTAR4HklqH1AwK4j4g1 X5zg== X-Received: by 10.194.143.43 with SMTP id sb11mr1535868wjb.120.1445317840559; Mon, 19 Oct 2015 22:10:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.212 with HTTP; Mon, 19 Oct 2015 22:10:21 -0700 (PDT) In-Reply-To: <20151019182200.4130.21008.idtracker@ietfa.amsl.com> References: <20151019182200.4130.21008.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Tue, 20 Oct 2015 06:10:21 +0100 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=089e0112c50c7965260522824863 Archived-At: Cc: pals-chairs@ietf.org, The IESG , "pals@ietf.org" , draft-ietf-pals-ms-pw-protection.all@ietf.org, draft-ietf-pals-ms-pw-protection@ietf.org, Stewart Bryant Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 05:10:47 -0000 --089e0112c50c7965260522824863 Content-Type: text/plain; charset=UTF-8 Barry, Thanks for your comments, and that leads to a question. All of the abbreviations that you cite are included in https://www.rfc-editor.org/materials/abbrev.expansion.txt (well, it has two expansions for AC, so there's a good case for expanding it here as well). So when do you need to expand commonly used acronyms, and when not? I'm happy to add the expansions (I'll be doing a rev anyway as a result of some other comments), but I'm curious if there's a general opinion in the IESG on the topic. Thanks, Andy On Mon, Oct 19, 2015 at 7:22 PM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-pals-ms-pw-protection-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Just total nit-level stuff here: unexpanded abbreviations that should be > expanded. Note to responsible AD: "OAM" should certainly be flagged in > the RFC Editor's abbreviation list as not requiring expansion, and it's > not so flagged. > > -- Introduction -- > PE, MPLS-TP, L2TP > > -- Section 2 -- > CE, AC (in fig 1) > > -- Appendix A -- > SDH, OTN, G-ACh > > > --089e0112c50c7965260522824863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry,

Thanks for your comments, and th= at leads to a question. All of the abbreviations that you cite are included= in=C2=A0https://www.rfc-editor.org/materials/abbrev.expansion.txt (well, it= has two expansions for AC, so there's a good case for expanding it her= e as well). So when do you need to expand commonly used acronyms, and when = not?=C2=A0 I'm happy to add the expansions (I'll be doing a rev any= way as a result of some other comments), but I'm curious if there's= a general opinion in the IESG on the topic.

Thank= s,
Andy

On Mon, Oct 19, 2015 at 7:22 PM, Barry Leiba = <barryleiba= @computer.org> wrote:
Barry= Leiba has entered the following ballot position for
draft-ietf-pals-ms-pw-protection-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/d= raft-ietf-pals-ms-pw-protection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just total nit-level stuff here: unexpanded abbreviations that should be expanded.=C2=A0 Note to responsible AD: "OAM" should certainly be= flagged in
the RFC Editor's abbreviation list as not requiring expansion, and it&#= 39;s
not so flagged.

-- Introduction --
PE, MPLS-TP, L2TP

-- Section 2 --
CE, AC (in fig 1)

-- Appendix A --
SDH, OTN, G-ACh



--089e0112c50c7965260522824863-- From nobody Mon Oct 19 22:26:36 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FFA1A9055; Mon, 19 Oct 2015 22:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs7nOLklVVZ1; Mon, 19 Oct 2015 22:26:29 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAB81A8F3B; Mon, 19 Oct 2015 22:26:29 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so28108370wic.1; Mon, 19 Oct 2015 22:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SBs9mjDP9B8YfUbBSPtOGjC0i4d3ABd8BPyRP3K5L8s=; b=BwlBJGBZM0rikBefXUNFPcjeFH8mBx5jeTEj00pgiz4GDIJ2eZMpkXFZiZqbWoCjYD kKKXWErYufoVZM7aKxyIrR9QFMPMbuy1uhxI/YqCz2uuYygBkeRmSkOaqZVmPty+4kxj ctC4dyZWimPR42ZcXcDaAPOsjlP2emu2u2X3MSfLT2Fj9SjKeLKlAgq98JGvs+wDQ2hb kAUkibq8o9VbCzN4l87tDAsqYcVQLnOJK7I+FfMp2DmhUKn3KnMfAfDXxC4YRLfqbImX PIV4eTPY7xbiU2LjXTnWryJ5Vx5sqVJ4nof0g8qDqNGhaZZeLU29QWWxZ4QRBUUKFZxp t0Pg== X-Received: by 10.180.221.193 with SMTP id qg1mr24182465wic.87.1445318787610; Mon, 19 Oct 2015 22:26:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.212 with HTTP; Mon, 19 Oct 2015 22:26:08 -0700 (PDT) In-Reply-To: <20151019183044.16657.40713.idtracker@ietfa.amsl.com> References: <20151019183044.16657.40713.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Tue, 20 Oct 2015 06:26:08 +0100 Message-ID: To: Alvaro Retana Content-Type: multipart/alternative; boundary=001a1135e5e6ec3f120522828056 Archived-At: Cc: Stewart Bryant , pals-chairs@ietf.org, The IESG , "pals@ietf.org" , draft-ietf-pals-ms-pw-protection@ietf.org Subject: Re: [Pals] Alvaro Retana's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 05:26:31 -0000 --001a1135e5e6ec3f120522828056 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alvaro, Thanks for your comments. To answer your question: First of all, is it that easy? The answer is yes, there is at least one working and deployed implementation of which I'm aware. You are correct, there are optional parts of 6870 that use non-status signaling, but if you just use the status signaling-based procedures in 6870, all is fine. I can make this more explicit if you like, please let me know. On minor comment 1, we didn't mean to be "low key" about provisioning, we can make that "must" a "MUST" if you like. Minor comments 2 and 3 - will do. Cheers, Andy On Mon, Oct 19, 2015 at 7:30 PM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-pals-ms-pw-protection-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I appreciate all the background given, it makes the text very clear. > > I have one question: Is it that easy? The substantive part of this > document is "the PW status signaling defined in RFC 6478 MUST be used=E2= =80=A6in > place of LDP-based status signaling". Do all the parts of Sections 6 and > 7 of RFC 6870 just translate to the alternate signaling? For example > (this is the first thing that I found, nothing special about it), 6.2 > (RFC6870) says that "a common Group ID in the PWid FEC element or a PW > Grouping ID TLV in the Generalized PWid FEC element, as defined in [2], > MAY be used to signal PWs in groups in order to minimize the number of > LDP status messages that MUST be sent." I found the Status TLV in > RFC6478, but not these other ones =E2=80=94 I may of course be missing th= e > references.. > > > I have other minor comments: > > 1. Just a nit.. It's interesting how (in the Introduction) when > presenting the optional mechanism the text says that it "MUST be > identically provisioned in the PE endpoints". However, then talking > about the MTI mechanism (in Section 3. (Operational Considerations)), the > text "just" says that "operational care must be taken so that the > endpoint T-PEs are identically provisioned". [To be fair, the same "low > key" text is later included in the Appendix referring to the optional > mechanism.] The text itself is not a big deal to me..it just caught my > attention the difference in treatment when for either mechanism to work > both endpoints must be provisioned the same say. > > 2. Section 1. (Introduction) Please expand PSN and put a reference in > for "PSN tunnel protection", or at least make it clear that the > protection you're referring to is what was described above (at least > that's my guess). > > 3. Section 2: s/in the place of LDP-based/in place of LDP-based > > > --001a1135e5e6ec3f120522828056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alvaro,

Thanks for your comments. To an= swer your question:

First of all, is it that easy?= The answer is yes, there is at least one working and deployed implementati= on of which I'm aware. You are correct, there are optional parts of 687= 0 that use non-status signaling, but if you just use the status signaling-b= ased procedures in 6870, all is fine. I can make this more explicit if you = like, please let me know.

On minor comment 1, we d= idn't mean to be "low key" about provisioning, we can make th= at "must" a "MUST" if you like.

Minor comments 2 and 3 - will do.

Cheers,
<= div>Andy


On Mon, Oct 19, 2015 at 7:30 PM, Alvaro Retana <aretana= @cisco.com> wrote:
Alvaro R= etana has entered the following ballot position for
draft-ietf-pals-ms-pw-protection-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/d= raft-ietf-pals-ms-pw-protection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I appreciate all the background given, it makes the text very clear.

I have one question:=C2=A0 Is it that easy?=C2=A0 The substantive part of t= his
document is "the PW status signaling defined in RFC 6478 MUST be used= =E2=80=A6in
place of LDP-based status signaling".=C2=A0 Do all the parts of Sectio= ns 6 and
7 of RFC 6870 just translate to the alternate signaling?=C2=A0 For example<= br> (this is the first thing that I found, nothing special about it), 6.2
(RFC6870) says that "a common Group ID in the PWid FEC element or a PW=
Grouping ID TLV in the Generalized PWid FEC element, as defined in [2],
MAY be used to signal PWs in groups in order to minimize the number of
LDP status messages that MUST be sent."=C2=A0 I found the Status TLV i= n
RFC6478, but not these other ones =E2=80=94 I may of course be missing the<= br> references..


I have other minor comments:

1.=C2=A0 Just a nit..=C2=A0 It's interesting how (in the Introduction) = when
presenting the optional mechanism the text says that it "MUST be
identically provisioned in the PE endpoints".=C2=A0 However, then talk= ing
about the MTI mechanism (in Section 3. (Operational Considerations)), the text "just" says that "operational care must be taken so tha= t the
endpoint T-PEs are identically provisioned".=C2=A0 [To be fair, the sa= me "low
key" text is later included in the Appendix referring to the optional<= br> mechanism.]=C2=A0 The text itself is not a big deal to me..it just caught m= y
attention the difference in treatment when for either mechanism to work
both endpoints must be provisioned the same say.

2. Section 1. (Introduction)=C2=A0 Please expand PSN and put a reference in=
for "PSN tunnel protection", or at least make it clear that the protection you're referring to is what was described above (at least that's my guess).

3. Section 2:=C2=A0 s/in the place of LDP-based/in place of LDP-based



--001a1135e5e6ec3f120522828056-- From nobody Tue Oct 20 01:06:08 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06031B2C3E; Tue, 20 Oct 2015 01:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-N9fwb8TIfv; Tue, 20 Oct 2015 01:06:03 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2075F1B2C06; Tue, 20 Oct 2015 01:05:33 -0700 (PDT) Received: by vkfw189 with SMTP id w189so5423447vkf.2; Tue, 20 Oct 2015 01:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7P0T5qQSNbNx6PTgh3dk9YgUCnvHW0LaAttvVLDHeH4=; b=nxTtbqWzQZtZ67vLaxs0TlqFuin5VcZ//XkCQ7PvGTQoakyGFG7pUWkUQAzYPvLXgr zky5AcCMa5DryFR9Vx3ZgrfA8W9jAKBU+m5vpxvs5Frzu6FZ3fJoi/a0W6rdenKcH/L8 ASDK5fYLONPOB7PYZ8r+WsUH6E2eHuEBGpNdJe/pG6cDbuIBZMUdZwxv4qX/kvaDuf8V HnGuL42Zn6PtjQRwTeRhMS46aPZrZWwLsH3WbIvfXcwKfLRJAgZhETqlDyH6/f3svU20 tzSgAmhUXkKQqpwnu2FakFs27Z4wUvddpBwv2t0sV6gWz/JY+Lv4KlgKZeXnh8WM/r+6 fZjg== MIME-Version: 1.0 X-Received: by 10.31.170.80 with SMTP id t77mr1121799vke.156.1445328332240; Tue, 20 Oct 2015 01:05:32 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Tue, 20 Oct 2015 01:05:32 -0700 (PDT) In-Reply-To: References: <20151019182200.4130.21008.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 04:05:32 -0400 X-Google-Sender-Auth: GOkcZWPqBJNjVl2JDQrcixXM674 Message-ID: From: Barry Leiba To: "Andrew G. Malis" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: pals-chairs@ietf.org, The IESG , "pals@ietf.org" , draft-ietf-pals-ms-pw-protection.all@ietf.org, draft-ietf-pals-ms-pw-protection@ietf.org, Stewart Bryant Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 08:06:04 -0000 > Thanks for your comments, and that leads to a question. All of the > abbreviations that you cite are included in > https://www.rfc-editor.org/materials/abbrev.expansion.txt Right; that's where I checked whether they were approved as not needing expansions. > when do you need to expand commonly used acronyms, and when not? As the above URL says: "Some abbreviations are so well known that expansion is probably unnecessary. The RFC Editor exercises editorial judgment about whether a particular use of one of the "well-known" abbreviations requires expansion. (For example, strict adherence to the expansion requirement can lead to impossibly ugly titles.) In the following list of abbreviations, those that are usually (but not necessarily) treated as "well known" are marked with asterisks. However, since there are so many different abbreviations and there is a range of knowledge among RFC readers, we tend to expand abbreviations in case of doubt." In my review, I only called out ones that do not have asterisks. "MPLS", "LDP", and some others *do* have asterisks, and don't need to be expanded. Barry From nobody Tue Oct 20 01:44:23 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBDF1B2E5B; Tue, 20 Oct 2015 01:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN74v8LShBWa; Tue, 20 Oct 2015 01:44:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FDB1B2E5A; Tue, 20 Oct 2015 01:44:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA35783; Tue, 20 Oct 2015 08:44:14 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 20 Oct 2015 09:44:14 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Tue, 20 Oct 2015 16:44:10 +0800 From: "Dongjie (Jimmy)" To: Robert Sparks , General Area Review Team , "draft-ietf-pals-redundancy-spe.all@ietf.org" , "pals@ietf.org" Thread-Topic: Gen-art LC review: draft-ietf-pals-redundancy-spe-02 Thread-Index: AQHRCFoBAjbu6kcumUySNbKvi0Guup5yhQ/wgACtoYCAAL/uUA== Date: Tue, 20 Oct 2015 08:44:10 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927743BD958@nkgeml512-mbx.china.huawei.com> References: <56216C90.4060606@nostrum.com> <76CD132C3ADEF848BD84D028D243C927743BD6AC@nkgeml512-mbx.china.huawei.com> <5625B071.6040303@nostrum.com> In-Reply-To: <5625B071.6040303@nostrum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 08:44:20 -0000 SGkgUm9iZXJ0LCANCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBwbGVhc2Ugc2VlIG15IHJl cGxpZXMgaW5saW5lOg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJv YmVydCBTcGFya3MgW21haWx0bzpyanNwYXJrc0Bub3N0cnVtLmNvbV0NCj4gU2VudDogVHVlc2Rh eSwgT2N0b2JlciAyMCwgMjAxNSAxMToxMCBBTQ0KPiBUbzogRG9uZ2ppZSAoSmltbXkpOyBHZW5l cmFsIEFyZWEgUmV2aWV3IFRlYW07IHBhbHNAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtcGFscy1y ZWR1bmRhbmN5LXNwZS5hbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEdlbi1hcnQgTEMgcmV2 aWV3OiBkcmFmdC1pZXRmLXBhbHMtcmVkdW5kYW5jeS1zcGUtMDINCj4gDQo+IA0KPiANCj4gT24g MTAvMTkvMTUgOTozNCBQTSwgRG9uZ2ppZSAoSmltbXkpIHdyb3RlOg0KPiA+IEhpIFJvYmVydCwN Cj4gPg0KPiA+IFRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVh c2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lOg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+IEZyb206IGlldGYgW21haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBSb2JlcnQgU3BhcmtzDQo+ID4+IFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDE3 LCAyMDE1IDU6MzEgQU0NCj4gPj4gVG86IEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbTsgaWV0ZkBp ZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzsNCj4gPj4gZHJhZnQtaWV0Zi1wYWxzLXJlZHVuZGFuY2Ut c3BlLmFsbEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBHZW4tYXJ0IExDIHJldmlldzogZHJhZnQt aWV0Zi1wYWxzLXJlZHVuZGFuY3ktc3BlLTAyDQo+ID4+DQo+ID4+IEkgYW0gdGhlIGFzc2lnbmVk IEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWENCj4gPj4g UmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieQ0KPiA+PiB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJl YXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlcg0KPiBsYXN0IGNhbGwgY29tbWVu dHMuDQo+ID4+DQo+ID4+IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEg YXQNCj4gPj4NCj4gPj4gPGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMv d2lraS9HZW5BcnRmYXE+Lg0KPiA+Pg0KPiA+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1wYWxzLXJl ZHVuZGFuY3ktc3BlLTAyDQo+ID4+IFJldmlld2VyOiBSb2JlcnQgU3BhcmtzDQo+ID4+IFJldmll dyBEYXRlOiAxNiBPY3QgMjAxNQ0KPiA+PiBJRVRGIExDIEVuZCBEYXRlOiAxOSBPY3QgMjAxNQ0K PiA+PiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIyIE9jdCAyMDE1DQo+ID4+DQo+ID4+IFN1bW1hcnk6 IEFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgUFMgYnV0IHdpdGggaXNzdWVzIHRoYXQg bmVlZA0KPiA+PiB0byBiZSBkaXNjdXNzZWQvYWRkcmVzc2VkDQo+ID4+DQo+ID4+IFRoaXMgZG9j dW1lbnQgaXMgaGFyZCB0byByZWFkLiBJdCBpcyBtb3JlIGFjcm9ueW0tbGFkZW4gdGhhbiBpdCBu ZWVkcyB0byBiZS4NCj4gPiBXZSB3aWxsIGV4cGFuZCB0aGUgYWNyb255bXMgb24gZmlyc3QgdXNl IGluIG5leHQgcmV2aXNpb24uDQo+IFRoYXQgd29uJ3QgY2hhbmdlIGhvdyBoYXJkIHRoaXMgaXMg dG8gcmVhZC4NCj4gDQo+IEV4cGFuZGluZyB0aGUgYWNyb255bXMgb24gZmlyc3QgdXNlIHdvbid0 IG1ha2UgdGhlIHByb3NlIGxhdGVyIGluIHRoZQ0KPiBkb2N1bWVudCBhbnkgZGlmZmVyZW50Lg0K PiBUaGUgdXNlIG9mIGFjcm9ueW1zIGZvciB0aGUgZWxlbWVudHMgaW52b2x2ZWQgaW4gYWxtb3N0 IGFsbCBvZiB0aGUgcHJvc2UgaXMNCj4gdW5uZWNlc3NhcnkuIFRoZSB3b3JkcyBmb3IgdGhlbSBh cmUgc2hvcnQgZW5vdWdoLg0KDQpTb3JyeSBmb3IgbWFraW5nIHRoaXMgZG9jdW1lbnQgaGFyZCB0 byByZWFkLCBjb3VsZCB5b3UgcHJvdmlkZSBzb21lIGFkdmljZXMgb24gaG93IHRvIGltcHJvdmUg dGhlIHJlYWRhYmlsaXR5PyANCg0KPiA+DQo+ID4+IC0tLS0tDQo+ID4+IFRoZXJlIGlzIGEgcHJv Y2VzcyBpc3N1ZSB0aGF0IHRoZSBJRVNHIHNob3VsZCBwYXkgYXR0ZW50aW9uIHRvLg0KPiA+PiBU aGUgc2hlcGhlcmQgd3JpdGV1cCBzYXlzIHRoaXM6DQo+ID4+DQo+ID4+ICAgICAiVGhlcmUgaXMg b25lIElQUiBkZWNsYXJhdGlvbiAoMTkxMSkgcmFpc2VkIGluIE5vdmVtYmVyIDIwMTIgYWdhaW5z dA0KPiA+PiAgICAgIGFuIGVhcmx5IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiAgVGhlcmUgd2FzIG5v IGRpc2N1c3Npb24gaW4gdGhlIFdHDQo+ID4+ICAgICAgcmVsYXRlZCB0byB0aGlzLiINCj4gPj4N Cj4gPj4gVGhhdCBoYXBwZW5zIHNvbWV0aW1lcywgYnV0IGl0J3MgbXVjaCBiZXR0ZXIgdG8gaGF2 ZSBhIHJlYWwNCj4gPj4gaW5kaWNhdGlvbiB0aGF0IHRoZSBncm91cCBjb25zaWRlcmVkIHRoZSBk aXNjbG9zdXJlIGFuZCBleHBsaWNpdGx5IGRlY2lkZWQgbm90DQo+IHRvIGNoYW5nZSBkaXJlY3Rp b25zLg0KPiA+PiAtLS0tLQ0KPiA+IEkgaG9wZSBBbmR5IGFuZCBEZWJvcmFoIGhhdmUgc29sdmVk IHlvdXIgY29uY2VybiBvbiB0aGlzLg0KPiA+DQo+ID4+IFRoZSBsYXN0IHNlbnRlbmNlIG9mIHRo ZSAybmQgcGFyYWdyYXBoIChkZWNsYXJpbmcgbXVsdGktaG9taW5nIG9uDQo+ID4+IGJvdGggc2lk ZXMgb2YgYW4gUy1QRSBvdXQgb2Ygc2NvcGUpIHNob3VsZCBiZSBtb3ZlZCBlYXJsaWVyIGluIHRo ZSBkb2N1bWVudC4NCj4gPj4gVGhlIGludHJvZHVjdGlvbiBhbmQgcGVyaGFwcyBldmVuIHRoZSBh YnN0cmFjdCBjYW4gYmUgY2xlYXJlciBhYm91dA0KPiA+PiB3aGF0IF9pc18gaW4gc2NvcGUuDQo+ ID4gQWdyZWVkLCB3aWxsIG1vdmUgaXQgdG8gdGhlIGludHJvZHVjdGlvbiBvZiB0aGUgZG9jdW1l bnQuDQo+IFRoYW5rcy4NCj4gPg0KPiA+PiBJdCBuZWVkcyB0byBiZSBjbGVhcmVyIHdoZXJlIHRo ZSBub3JtYXRpdmUgZGVzY3JpcHRpb24gb2YgYmVoYXZpb3IgaXMuDQo+ID4+IEkgdGhpbmsgeW91 J3JlIGludGVuZGluZyBpdCB0byBiZSB0aGUgZmlyc3QgcGFydCBvZiBzZWN0aW9uIDMuIEkgaGF2 ZQ0KPiA+PiBub3Qgd29ya2VkIHRocm91Z2ggdGhlIHJlZmVyZW5jZXMgZW5vdWdoIHRvIGVuc3Vy ZSB0aGF0IGl0IGlzIGNvbXBsZXRlLg0KPiA+IFllcywgdGhlIGZpcnN0IHBhcnQgb2Ygc2VjdGlv biAzIGRlZmluZXMgdGhlIG9wZXJhdGlvbiBvZiBTLVBFLg0KPiA+DQo+ID4+IFRoZSB0aGlyZCBw YXJhZ3JhcGggc3RhcnRzIG9mZiAiSW4gZ2VuZXJhbCwgLi4uIi4gQXJlIHRoZXJlIGFueQ0KPiA+ PiBzcGVjaWZpYyBjYXNlcyB3aGVyZSB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgZm9sbG93IGRvIG5v dCBob2xkPyBJZiBzbywNCj4gPj4gdGhlcmUgbmVlZHMgdG8gYmUgbW9yZSBkZXNjcmlwdGlvbi4g SWYgbm90LCBwbGVhc2UgZGVsZXRlICJJbiBnZW5lcmFsLCIuDQo+ID4gV2Ugd2lsbCByZW1vdmUg ImluIGdlbmVyYWwiIGluIG5leHQgcmV2aXNpb24uDQo+ID4NCj4gPj4gQXJlIHNlY3Rpb25zIDMu MSBhbmQgMy4yIHN1cHBvc2VkIHRvIGJlIG9ubHkgZXhhbXBsZXM/IFdvdWxkIHRoZQ0KPiA+PiBz cGVjaWZpY2F0aW9uIG9mIHRoZSBwcm90b2NvbCBiZSBjb21wbGV0ZSBpZiB0aGV5IHdlcmUgZGVs ZXRlZD8gSWYNCj4gPj4gbm90LCBzb21ldGhpbmcgbmVlZHMgdG8gYmUgbW92ZWQgdXAgaW50byB0 aGUgbWFpbiBwYXJ0IG9mIHNlY3Rpb24gMy4NCj4gPj4gRm9yIGluc3RhbmNlLCBpcyB0aGUgU0hP VUxEIGF0IHRoZSBlbmQgb2YgMy4xIGEgcmVxdWlyZW1lbnQgcGxhY2VkIGJ5DQo+ID4+IHRoaXMg ZG9jdW1lbnQsIG9yIGlzIGl0IHJlc3RhdGluZyBhIHJlcXVpcmVtZW50IGZyb20gc29tZXdoZXJl IGVsc2U/DQo+ID4+IFNpbWlsYXJseSwgcGxlYXNlIGluc3BlY3QgdGhlIFNIT1VMRCBpbiB0aGUg c2Vjb25kIHBhcmFncmFwaCBvZiAzLjIuDQo+ID4+DQo+ID4+IEkgYWxzbyBzdWdnZXN0IG1vdmlu ZyAzLjEgYW5kIDMuMiBpbnRvIHRoZWlyIG93biBzZWN0aW9uLCBjbGVhcmx5DQo+ID4+IGxhYmVs aW5nIHRoZW0gYXMgZXhhbXBsZXMuDQo+ID4gR29vZCBxdWVzdGlvbi4gVGhlIGxhc3Qgc2VudGVu Y2Ugb2Ygc2VjdGlvbiAzLjEgYW5kIDMuMiBjYW4gYmUgbW92ZWQgdXAgaW50bw0KPiB0aGUgbWFp biBwYXJ0Lg0KPiA+DQo+ID4gU2luY2Ugc2VjdGlvbiAzLjEgYW5kIDMuMiBzcGVjaWZpZXMgdGhl IHR5cGljYWwgc2NlbmFyaW9zLCBteSBmZWVsaW5nIGlzIHRoZXkgYXJlDQo+IG1vcmUgdGhhbiBl eGFtcGxlcy4gTWF5IGJlIGJldHRlciB0byBrZWVwIHRoZW0gaW4gc2VjdGlvbiAzPw0KPiBObywg SSBkb24ndCB0aGluayBzby4NCj4gDQo+IElmIHRoZXkgY2FuJ3QgYmUgcmVtb3ZlZCwgdGhlbiB0 aGVyZSBpcyBzb21lIHBhcnQgb2YgdGhpcyBhZGRpdGlvbiB0byB0aGUNCj4gcHJvdG9jb2wgc3Vp dGUgdGhhdCB5b3UgYXJlIHNwZWNpZnlpbmcgYnkgZXhhbXBsZSwgcmF0aGVyIHRoZW4gc3BlY2lm eWluZyB0aGUNCj4gYmVoYXZpb3IgZXhwbGljaXRseS4gVGhhdCB1c3VhbGx5IG1lYW5zIHlvdSdy ZSB1bmRlci1zcGVjaWZ5aW5nLCBhbmQgaG9waW5nDQo+IHBlb3BsZSB3aWxsIGluZmVyIChndWVz cykgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGluIHRoZSB1bnNwZWNpZmllZCBjYXNlcy4gWW91IHdp bGwNCj4gZW5kIHVwIHdpdGggYmV0dGVyIGludGVyb3BlcmFiaWxpdHkgYnkgYmVpbmcgZXhwbGlj aXQuDQoNCkkgZ290IHlvdXIgcG9pbnQsIGFuZCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBub3Qg dW5kZXItc3BlY2lmeWluZy4gVGh1cyB3ZSBjYW4gbW92ZSBzZWN0aW9uIDMuMSBhbmQgMy4yIHRv IHRoZWlyIG93biBzZWN0aW9uLg0KDQo+ID4+IElzIGl0IHdvcnRoIG1vcmUgZXhwbGFuYXRpb24g aW4gdGhlIGRvY3VtZW50IHdoeSB5b3UndmUgYWRkZWQgdGhlDQo+ID4+IE1VU1QgTk9UIGluIHRo ZSBmaXJzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAzPw0KPiA+IEJlY2F1c2UgaWYgUy1QRSBCeXBh c3MgTW9kZSBpcyB1c2VkLCB0aGUgUy1QRSB3aWxsIG5vdCByZWNlaXZlIHRoZSBQVyBzdGF0dXMN Cj4gbWVzc2FnZSBvcmlnaW5hdGVkIGJ5IFQtUEVzLiBXZSB3aWxsIGFkZCBzb21lIGV4cGxhbmF0 aW9uIGFib3V0IHRoaXMuDQo+IFRoYW5rcyBhZ2Fpbi4NCj4gPg0KPiA+PiBUaGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvbmx5IHBvaW50cyBvZmYgdG8gb3RoZXIgZG9jdW1lbnRz Lg0KPiA+PiBNb3N0IG9mIHRob3NlIGp1c3QgcG9pbnQgdG8gZWFjaCBvdGhlci4gQ2hhc2luZyBp dCBiYWNrLCB0aGVyZSdzIHNvbWUNCj4gPj4gbWVhdCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiBvZiA0NDQ3LCBhbmQgc29tZSBpbg0KPiA+PiA1MDg1LCBidXQgaXQncyBh IHJlYWwgY2hhc2UgdG8gZmluZCB3aGF0J3MgcmVsZXZhbnQuICBQbGVhc2UgY29uc2lkZXINCj4g Pj4gY2FsbGluZyBvdXQgd2hhdCBhbiBpbXBsZW1lbnRlciBuZWVkcyB0byBjb25zaWRlciBleHBs aWNpdGx5IGhlcmUuDQo+ID4gU2luY2UgdGhpcyBkb2N1bWVudCBpcyBtYWlubHkgYWJvdXQgcmV1 c2luZyB0aGUgcmVkdW5kYW5jeSBtZWNoYW5pc21zIG9mDQo+IFJGQzY4NzAgb24gdGhlIFMtUEUg bm9kZXMsIHdlIHRoaW5rIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiB0aGVzZQ0KPiBy ZWZlcmVuY2VkIGRvY3VtZW50cyBjb3VsZCBzdWZmaWNlLg0KPiBUaGF0IG1pc3NlcyB0aGUgcG9p bnQgLSB3aGF0ZXZlciBpcyBpbXBvcnRhbnQgaW4gdGhvc2UgY29uc2lkZXJhdGlvbnMgZm9yIHdo YXQNCj4gdGhpcyBkb2N1bWVudCBpcyB0YWxraW5nIGFib3V0IGlzIGJ1cmllZC4NCj4gV2h5IGRp ZG4ndCB5b3UganVzdCBjb3B5IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9m IDY4NzAgaW50byB0aGlzDQo+IGRvY3VtZW50PyAoSSdtIG5vdCBzdWdnZXN0aW5nIHlvdSBkbyB0 aGF0IC0geW91ciB1c2Ugb2YgIm1haW5seSIgYWJvdmUgc2F5cw0KPiB0aGF0IHdvdWxkbid0IGJl IGVub3VnaC4gX1doeV8gaXQncyBub3QgZW5vdWdoIGlzIHdvcnRoIGNhcHR1cmluZyBpbiB0aGlz DQo+IGRvY3VtZW50LikNCj4gDQo+IElzbid0IHRoZXJlIHNvbWV0aGluZyB0byBuZXcgdG8gc2F5 IGhlcmUgYWJvdXQgZmFpbHVyZSBjYXNlcz8gWW91IGVzc2VudGlhbGx5DQo+IGhhdmUgc29tZSBu ZXcgYWN0b3JzIHRoYXQgKGlmIHRoZXkgd2VyZSB0byBtaXNiZWhhdmUsIG9yIGlmIHNvbWVvbmUg Y291bGQNCj4gcHJldGVuZCB0byBiZSB0aGVtKSBjb3VsZCBfY2F1c2VfIGF0IGxlYXN0IHRoZSBT LVBFIHRvIGJlbGlldmUgdGhlcmUgd2FzIGENCj4gZmFpbHVyZS4gSXMgdGhhdCBhbHJlYWR5IGRp c2N1c3NlZCBzb21ld2hlcmU/DQoNCkknbSB0aGlua2luZyBhYm91dCB3aGV0aGVyIHRoZSBuZXcg cHJvY2VkdXJlcyBvbiBTLVBFIHdvdWxkIGludHJvZHVjZSBhbnkgbmV3IGF0dGFjayB2ZWN0b3Jz LiANCg0KV2hhdCBhYm91dCB3ZSBzYXkgc29tZXRoaW5nIGxpa2U6ICJTaW5jZSBQVyByZWR1bmRh bmN5IGlzIHByb3ZpZGVkIG9uIHRoZSBTLVBFIG5vZGVzLCBpdCBpcyBpbXBvcnRhbnQgdGhhdCB0 aGUgc2VjdXJpdHkgbWVjaGFuaXNtcyBhcyBkZWZpbmVkIGluIFtSRkMgNDQ0N10sIFtSRkMgNjA3 M10gYW5kIFtSRkMgNjQ3OF0gYXJlIGltcGxlbWVudGVkIHRvIGVuc3VyZSB0aGF0IHRoZSBTLVBF IG5vZGVzIGFuZCB0aGUgbWVzc2FnZXMgcmVjZWl2ZWQgYnkgdGhlIFMtUEUgbm9kZXMgYXJlIG5v dCBjb21wcm9taXNlZC4iDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQo+ID4gQW5kIGZvciBhbiBp bXBsZW1lbnRlciBJTU8gdGhlcmUgaXMgbm90aGluZyBuZXcgdG8gYmUgY29uc2lkZXJlZC4NCj4g Pg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBKaWUNCj4gPg0KDQo= From nobody Tue Oct 20 06:05:38 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291DB1A0404; Tue, 20 Oct 2015 06:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htXw1YI9wwxm; Tue, 20 Oct 2015 06:05:30 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF711A039D; Tue, 20 Oct 2015 06:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2782; q=dns/txt; s=iport; t=1445346329; x=1446555929; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=idWXPi1U4X8gndIMwXMQG9+ldHnLO5+vV7YexIV8+WA=; b=TRilUl2xATGoJkXepEWQl6MibnUzMqynTSDI9Z/9fSfEF3Rslyusntqu 8BmSAAaWCOVlBjaxi4wa6/QWXVj9jIIX/Q3sjLXcl/HFJ3imr9L76NWhV e+KtWi5wzhBHsxSt7708/JWPf+mzt9o0kZBN63vPIHfnO+4+8HyRvE6xw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQBLOyZW/4kNJK1egmlNgUMGuXiEL4Fahh4CgUA5EwEBAQEBAQGBCoQuAQEEeRACAQgEOwchERQRAgQOBYgbAxK/AQ2EfgEBAQEBAQEDAQEBAQEBAQEBAQEYhncBhH2CUII9B4QuBY1LhQ+DSgGLKIF2gViEP44+h0sBIwI+gkSBP3KEYYEGAQEB X-IronPort-AV: E=Sophos;i="5.17,707,1437436800"; d="scan'208,217";a="199801739" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP; 20 Oct 2015 13:05:28 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9KD5Shr028989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2015 13:05:28 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 20 Oct 2015 08:05:10 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Tue, 20 Oct 2015 08:05:10 -0500 From: "Alvaro Retana (aretana)" To: "Andrew G. Malis" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) Thread-Index: AQHRCpw+a3w8tn6GdU++/+V+GdctB550Lj4AgAA9QQA= Date: Tue, 20 Oct 2015 13:05:10 +0000 Message-ID: References: <20151019183044.16657.40713.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D24BB1D3DF7C7aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Stewart Bryant \(stbryant\)" , "pals-chairs@ietf.org" , The IESG , "pals@ietf.org" , "draft-ietf-pals-ms-pw-protection@ietf.org" Subject: Re: [Pals] Alvaro Retana's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 13:05:34 -0000 --_000_D24BB1D3DF7C7aretanaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 10/20/15, 1:26 AM, "Andrew G. Malis" > wrote: Andy: Hi! First of all, is it that easy? The answer is yes, there is at least one wor= king and deployed implementation of which I'm aware. You are correct, there= are optional parts of 6870 that use non-status signaling, but if you just = use the status signaling-based procedures in 6870, all is fine. I can make = this more explicit if you like, please let me know. I see..the subtlety is that you're specifically calling out just the status= signaling. Being more explicit would have helped me - I'll leave any chan= ge up to you. Thanks! Alvaro. --_000_D24BB1D3DF7C7aretanaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <623F39485E34A74DA8A67B954A563A0C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 10/20/15, 1:26 AM, "Andrew G. Malis" <agmalis@gmail.com> wrote:

Andy:

Hi!

First of all, is it that easy? The answer is yes, there is at least one wor= king and deployed implementation of which I'm aware. You are correct, there= are optional parts of 6870 that use non-status signaling, but if you just = use the status signaling-based procedures in 6870, all is fine. I can make this more explicit if you like, please le= t me know.

I see..the subtlety is that you're specifically calling out just the s= tatus signaling.  Being more explicit would have helped me — I'l= l leave any change up to you.

Thanks!

Alvaro.
--_000_D24BB1D3DF7C7aretanaciscocom_-- From nobody Tue Oct 20 08:06:20 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4191A9081; Tue, 20 Oct 2015 08:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BloCAoKUW3Ua; Tue, 20 Oct 2015 08:06:17 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BF41B344E; Tue, 20 Oct 2015 07:59:12 -0700 (PDT) Received: by oiev17 with SMTP id v17so11343241oie.2; Tue, 20 Oct 2015 07:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=biHodQnKXqo0SscL0fQVrsH2vcl/GJcGsE6An8Ljg7s=; b=BtdwQgF70StbLq4GQtUo8bNH3KPHSqWbrgX207nj2Z2LT8pkTj9WmzWAGwmqaPqsOp FrlBsO2fTuQIzuFYdKvCSMwnkQY/2DJIPz6fTLa6Skly/WA5/WCroR2sXawfwIOFaCau +2dNmJXDopz8CAnDRDgektC1bRf/5KKp7cGT1f5v7V5YjtgI36BDfe/FseKY1ry5oaH/ aQKnxCdRRQPS4HKjf9lgewIF2GA25TtWFng/X95ExAlCXPzq6Jyps0uBZTkaO/hnxRWD CEkrQFYdZhmg/+bZ/k1mRXcm+IejQ3Brrj9Hlba2KUqigx5GlM7txnd/VVMAAHquumOC IF4Q== X-Received: by 10.202.62.139 with SMTP id l133mr2195108oia.0.1445353152242; Tue, 20 Oct 2015 07:59:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.101.209 with HTTP; Tue, 20 Oct 2015 07:58:57 -0700 (PDT) In-Reply-To: References: <20151019182200.4130.21008.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Tue, 20 Oct 2015 10:58:57 -0400 Message-ID: To: The IESG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Stewart Bryant , pals-chairs@ietf.org, draft-ietf-pals-ms-pw-protection.all@ietf.org, draft-ietf-pals-ms-pw-protection@ietf.org, "pals@ietf.org" Subject: Re: [Pals] Barry Leiba's No Objection on draft-ietf-pals-ms-pw-protection-03: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 15:06:18 -0000 I endorse a policy of spelling out acronyms on the first occurrence in the body text a document if there is any doubt as to whether or not that should be done. Even if someone went to the faintly ridiculous length of spelling out IETF and IP and TCP once, when they first occurred in the body text of a document, what harm would it do? It seems to me that, although the RFC Editor has a list which informs their RFC editing, the effective rule is approximately that the authors of a draft make an initial determination but they later have to spell out the first occurrence of any acronym when asked to do so by any of the WG Chair, Shepherd, Directorates, ADs, or other reviewers. I think that works out fine. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Oct 20, 2015 at 4:05 AM, Barry Leiba wrote: >> Thanks for your comments, and that leads to a question. All of the >> abbreviations that you cite are included in >> https://www.rfc-editor.org/materials/abbrev.expansion.txt > > Right; that's where I checked whether they were approved as not > needing expansions. > >> when do you need to expand commonly used acronyms, and when not? > > As the above URL says: > "Some abbreviations are so well known that expansion is probably > unnecessary. The RFC Editor exercises editorial judgment about whether > a particular use of one of the "well-known" abbreviations requires > expansion. (For example, strict adherence to the expansion requirement > can lead to impossibly ugly titles.) In the following list of > abbreviations, those that are usually (but not necessarily) treated as > "well known" are marked with asterisks. However, since there are so > many different abbreviations and there is a range of knowledge among > RFC readers, we tend to expand abbreviations in case of doubt." > > In my review, I only called out ones that do not have asterisks. > "MPLS", "LDP", and some others *do* have asterisks, and don't need to > be expanded. > > Barry > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Tue Oct 20 09:09:44 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEBE1AD367; Tue, 20 Oct 2015 09:09:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151020160941.21459.62257.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 09:09:41 -0700 Archived-At: Cc: pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org, agmalis@gmail.com, draft-ietf-pals-mpls-tp-mac-wd@ietf.org, pals@ietf.org Subject: [Pals] Stephen Farrell's No Objection on draft-ietf-pals-mpls-tp-mac-wd-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 16:09:41 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-pals-mpls-tp-mac-wd-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The secdir review [1] raised a few points that deserve a response I think, did I miss the response? [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06097.html - Where in the referenced RFCs in the security considerations is the DoS potential of MAC address withdrawal covered? From nobody Wed Oct 21 08:53:13 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8651AD16B for ; Wed, 21 Oct 2015 08:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la39t2ViuhD2 for ; Wed, 21 Oct 2015 08:53:06 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06ADB1AD0CC for ; Wed, 21 Oct 2015 08:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=99807; q=dns/txt; s=iport; t=1445442785; x=1446652385; h=reply-to:subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=WKqWefQOKUkVYXfq/ZoOXXF3AtgCE8kDsbNnV+b+p3k=; b=bOqB1Gz342MG1zJIjt1IlDVeRfPkZJYvA/7UQSiQnqsZjesBjyKaKSqz IFr5gFwW30kZvBKFcNpuVUk0B9aAzH+WV+KNEaMNW3a94j4OHoWmAZ5dX kS8APu444pMC4fCHrrsWllecx4HKWem+TBkBBtBc3lq9itJ0WhJxm55C0 0=; X-IronPort-AV: E=Sophos;i="5.17,712,1437436800"; d="scan'208,217";a="630428217" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 21 Oct 2015 15:53:03 +0000 Received: from [10.55.98.188] (ams-stbryant-88111.cisco.com [10.55.98.188]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9LFr2lT021990; Wed, 21 Oct 2015 15:53:02 GMT References: <3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22@szxema506-mbs.china.huawei.com> <5617B468.2020100@gmail.com> To: Stewart Bryant , Jiangyuanlong , Lizhong Jin From: Stewart Bryant Message-ID: <5627B4DB.3050205@cisco.com> Date: Wed, 21 Oct 2015 16:52:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5617B468.2020100@gmail.com> Content-Type: multipart/alternative; boundary="------------030708080606050804080701" Archived-At: Cc: Stewart Bryant , "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 15:53:12 -0000 This is a multi-part message in MIME format. --------------030708080606050804080701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I have heard nothing back from the group, and so I assume that this is an acceptable way forward. Please will the authors make the necessary updates to the text. Regards Stewart On 09/10/2015 13:34, Stewart Bryant wrote: > > From my perspective, and with due regard as to where we are, option one > is the one that I would prefer to move things along. > > That would not preclude us introducing another RFC at a later date if > there are further operational considerations or alternatives that there > is a consensus to support. > > Do we have consensus to move forward with option 1? > > Stewart > > > > On 09/10/2015 13:02, Jiangyuanlong wrote: >> >> Hi all, >> >> We had some discussions on this mechanism when the document was still >> an individual draft (in fact, when it was being updated to >> draft-jiang-l2vpn-vpls-pe-etree-03). >> >> Just like Stewart, some service providers were also concerned that >> this mechanism may result in a great waste of platform labels. For >> example, in a network with one root PE and 1000 leaf PEs, only 1001 >> PW labels are needed for the approach in the document; but we will >> need 1000*999/2=499500 PW labels in all for the proposed mechanism >> (since leaf to leaf PWs are still allocated). That is the main reason >> we adopted the current approach. >> >> Therefore, I will regard option 1) as the favorite way forward: >> >> 1) Leave the design as it is, but add text to describe the constraint and >> what happens if you have to change mode and what to do about it. >> >> I will be glad to see more inputs to this topic. >> >> Thanks, >> >> Yuanlong >> >> >> >> *From:*Lizhong Jin [mailto:lizho.jin@gmail.com] >> *Sent:* Monday, October 05, 2015 1:05 PM >> *To:* Stewart Bryant (stbryant) >> *Cc:* draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org; pals@ietf.org; >> pals-chairs@tools.ietf.org >> *Subject:* Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways >> forward >> >> Hi Stewart, >> >> For DU mode, if FEC is created, then label should be allocated. For >> the vulnerability you mentioned, if I understand your question >> correctly, the PW label will not be programmed into hardware, but >> only kept in control plane. So the packet will not be wrongly processed. >> >> The MTU interface Sub-TLV defined in RFC4447 section 6.4 said: >> >> If this parameter does not match >> in both directions of a specific PW, that PW MUST NOT be enabled. >> >> The mechanism I proposed is what have been done for MTU interface >> sub-TLV. >> >> Regards >> >> Lizhong >> >> On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) >> wrote: >> >> >> On 4 Oct 2015, at 16:43, Lizhong Jin wrote: >> >> Hi Stewart, >> >> Thanks for the comment. This is a long email. >> >> You give us three options: >> >> >> 1) Leave the design as it is, but add text to describe the >> constraint and >> what happens if you have to change mode and what to do about it. >> >> 2) Exclude optimization in the FEC PWid(0x80) case >> >> 3) Add an appendix describing support for the FEC PWid(0x80) case. >> >> Then I prefer option 1. Because option2 is not reasonable, and >> the solution in option3 provided by the author is not the best one. >> >> I would like to provide opition4 for WG to consider: >> >> 4) Add description to support for the FEC PWid(0x80) case, in >> appendix or text I don't care. The solution is: >> >> label release message should not be sent in section 6.1. >> >> For PW signaling, the unacceptable of any Interface Parameter >> will not lead to any >> >> label release, but just simply let the PW down in forwarding plane. >> >> Listing >> >> Doesn't that waste labels, which may be a problem in some systems, >> and create a vulnerability since someone may send a packet with that >> label which would be processed and sent out of the person egress. >> >> -Stewart >> >> >> >> Regards >> >> Lizhong >> >> >> ---------- Forwarded message ---------- >> From: Stewart Bryant >> To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org >> " >> > >, >> "pals@ietf.org " > > >> Cc: "pals-chairs@tools.ietf.org >> " > > >> Date: Fri, 2 Oct 2015 16:41:05 +0100 >> Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways >> forward >> >> I am sorry that this is a long email, but I wanted to collect the >> facts together in one place and set out the complete scene to >> the PALS WG. >> >> The critical concern is contained in the following email fragment >> from Lizhong: >> >> ======= >> >> In RFC4447 and 4447bis, it clearly said: >> >> Using the PWid FEC, each of the two pseudowire endpoints >> >> independently initiates the setup of a unidirectional LSP. An >> >> outgoing LSP and an incoming LSP are bound together into a single >> >> pseudowire if they have the same PW ID and PW type. >> >> The behavior is a correct description for LDP-DU mode which PW >> applies. >> >> And that is also the behavior most vendors implement. >> >> Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says: >> >> A PE that receives a PW label mapping message with an E-Tree Sub-TLV >> >> from its peer PE, after saving the VLAN information for the >> PW, MUST >> >> process it as follows: >> >> ..... >> >> 3) If the P bit is set >> >> { >> >> If the PE is a leaf-only node itself, a label release >> message >> >> with a status code "Leaf to Leaf PW released" is sent to >> the peer >> >> PE and exit the process; >> >> Else the PE SHOULD set the Optimized-Mode to TRUE. >> >> } >> >> That means, if PE1 receiving a label mapping from PE2 with P bit >> set, >> >> PE1 will send label release. Then PE2 will never send label mapping >> >> again to PE1 even when PE1 changes from leaf-only node to >> root-leaf node. For LDP-DU >> >> mode, PE2 will not send label mapping again when receiving PE1's >> label mapping. >> >> Then the PW will not be setup successfully. Then only way is to >> configure the >> >> same PW on PE2 again. >> >> The correct behavior is, label release message should not be sent. >> >> For PW signaling, the unacceptable of any Interface Parameter >> will not lead to any >> >> label release, but just simply let the PW down in forwarding plane. >> >> ======== >> >> Andy looked at this from the point of view of the MEF and notes in >> private conversation: >> >> ========= >> >> In the E-tree service as defined by MEF, you can have one or more >> roots >> and one or more leafs. >> >> In a single E-tree service (think of a multipoint PW with some of >> the CEs >> configured as roots as some as leafs), all leafs and roots >> receive frames >> sent by the roots. All roots receive frames sent by the leafs. >> However, >> leafs may not receive any frames sent by other leafs. >> >> The draft, as written, doesn't bring up an underlying pt-to-pt >> PWs to >> carry frames for the service between PEs that only have leafs >> attached. >> Since the leafs can't sent frames to each other, that is an >> economical >> use of PWs in the network. >> >> Lizhong's point is that this makes it impossible to add a new >> root to >> an existing PE in an E-tree that previously only had leafs. >> >> I agree that would be a problem if there was a requirement to modify >> an existing E-tree service. However, this draft has no other >> mechanisms >> to explicitly support E-tree modification, nor is such >> modification a >> requirement of the underlying MEF specification. BTW, since this >> work >> was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet >> Services Definitions Phase 3", August, 2014, and that reference >> should >> be updated in the draft. >> >> My opinion is that the draft as it stands is technically correct >> if you >> don't need the ability to reconfigure an existing E-tree service >> dynamically. >> >> ========== >> >> Now whilst I can support the idea that dynamic reconfiguration of >> E-tree is not needed, I have a concern. >> >> My understanding the text in question is that it is saying that if >> A is configured as leaf only, and B which is also configured as >> leaf only attempts to configure a PW between them, then A rejects >> the PW setup. >> >> That sounds very reasonable to me, since there is a misconfig. >> >> If A did not do the reject, then B would forever be consuming >> resource waiting for A and B would have no idea of the >> misconfig. That accords with Andy's view above. >> >> However I was worried what would happen if A was misconfigured >> as leaf only and the configuration was corrected to root-leaf. >> What would in my view be difficult to accept was the need to >> take a human, or NMS action at B to recover the situation. >> However provided that A closed the LDP session with B >> and re-instate it B would then send the mapping message again. >> Thus the system is recoverable without needing to visit B which >> is in my mind a fundamental requirement since A could have >> got into the wrong mode as a result of an error. >> >> The problem I see is if A has a bunch of other PWs with B >> they will get torn down in order for A to have the config error >> fixed. However if that is a problem you need two LDP sessions >> between A and B, one for L2VPN and one for regular PWs. >> >> My inclination is that the draft is basically correct, and that >> whilst >> Lizhong is correct that the PW will not come up without some >> action, reconfiguring the PW on B is not the only action >> that will cause the PW to come up. >> >> So this comes down to a WG decision in terms of which is the >> least unacceptable behaviour - A having to re-cycle the LDP >> session, or B wasting resources. I think I prefer the behaviour >> proposed in the draft. >> >> A way forward is to leave the logic as written in the draft, but to >> add text describing the basis for excluding dynamic re-configuration >> as a normal operational mode and to note the actions that need >> to be taken when re-configuration is forced for some reason. >> >> Whilst we were pondering what do with the text the chairs >> and AD received another proposal from the authors: >> >> ====== >> >> In general, FEC PWid(0x80) is used in VPLS with manual provisioning, >> while Generalized PWid (0x81) is used with auto-discovery. >> >> As discussed in Section 5.2, VLAN mapping parameters can be >> provisioned >> without a signaling protocol, Optimized Mode can also be a parameter >> to be provisioned. >> >> The approach we’ve taken in the current >> draft-ietf-l2vpn-vpls-pe-etree-09 >> does allow this. Quite a few service providers may prefer to control >> all these E-Tree connectivity by themselves. >> >> When E-Tree signaling protocol for PWid FEC is considered, the >> following >> options are also feasible: >> >> a)Disable Optimized mode for FEC PWid(0x80), thus root/leaf role >> change in the E-Tree topology will not have any influence on the PW. >> >> b)Add another appendix into the document for the full support of >> Optimized mode with FEC PWid(0x80). >> >> The idea is: the PE sends a label mapping firstly and then send a >> label >> request to its peer PEs (so that they will reply with a label >> mapping >> respectively). >> >> Since Optimized mode is an optional piece in the document, I would >> regard option a) as a simple tradeoff (as I am aware, E-VPN does not >> support Optimized mode for E-Tree either. >> >> ======== >> >> >> Thus we have three proposals on the table: >> >> 1) Leave the design as it is, but add text to describe the >> constraint and >> what happens if you have to change mode and what to do about it. >> >> 2) Exclude optimization in the FEC PWid(0x80) case >> >> 3) Add an appendix describing support for the FEC PWid(0x80) case. >> >> My inclination would be to go with option (1) but I seek the views of >> the WG, and of course any corrections in my analysis. >> >> - Stewart >> >> >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals >> >> >> >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------030708080606050804080701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I have heard nothing back from the group, and so I assume that this
is an acceptable way forward.

Please will the authors make the necessary updates to the text.

Regards

Stewart


On 09/10/2015 13:34, Stewart Bryant wrote:

From my perspective, and with due regard as to where we are,  option one
is the one that I would prefer to move things along.

That would not preclude us introducing another RFC at a later date if
there are further operational considerations or alternatives that there
is a consensus to support.

Do we have consensus to move forward with option 1?

Stewart



On 09/10/2015 13:02, Jiangyuanlong wrote:

Hi all,

 

We had some discussions on this mechanism when the document was still an individual draft (in fact, when it was being updated to draft-jiang-l2vpn-vpls-pe-etree-03).

Just like Stewart, some service providers were also concerned that this mechanism may result in a great waste of platform labels. For example, in a network with one root PE and 1000 leaf PEs, only 1001 PW labels are needed for the approach in the document; but we will need 1000*999/2=499500 PW labels in all for the proposed mechanism (since leaf to leaf PWs are still allocated). That is the main reason we adopted the current approach.

Therefore, I will regard option 1) as the favorite way forward:

1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

I will be glad to see more inputs to this topic.

 

Thanks,

Yuanlong



 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: Monday, October 05, 2015 1:05 PM
To: Stewart Bryant (stbryant)
Cc: draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org; pals@ietf.org; pals-chairs@tools.ietf.org
Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

 

Hi Stewart,

For DU mode, if FEC is created, then label should be allocated. For the vulnerability you mentioned, if I understand your question correctly, the PW label will not be programmed into hardware, but only kept in control plane. So the packet will not be wrongly processed.

The MTU interface Sub-TLV defined in RFC4447 section 6.4 said:

If this parameter does not match
       in both directions of a specific PW, that PW MUST NOT be enabled.

The mechanism I proposed is what have been done for MTU interface sub-TLV.

 

Regards

Lizhong

 

On Mon, Oct 5, 2015 at 2:19 AM, Stewart Bryant (stbryant) <stbryant@cisco.com> wrote:

 

 


On 4 Oct 2015, at 16:43, Lizhong Jin <lizho.jin@gmail.com> wrote:

Hi Stewart,

Thanks for the comment. This is a long email.

You give us three options:


1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

 

 Then I prefer option 1. Because option2 is not reasonable, and the solution in option3 provided by the author is not the best one.

 

I would like to provide opition4 for WG to consider:

4) Add description to support for the FEC PWid(0x80) case, in appendix or text I don't care. The solution is:

label release message should not be sent in section 6.1.
For PW signaling, the unacceptable of any Interface Parameter will not lead to any 
label release, but just simply let the PW down in forwarding plane.

Listing

 

Doesn't that waste labels, which may be a problem in some systems, and create a vulnerability since someone may send a packet with that label which would be processed and sent out of the person egress.

 

-Stewart



Regards

Lizhong

 

 


---------- Forwarded message ----------
From: Stewart Bryant <stbryant@cisco.com>
To: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" <draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org>, "pals@ietf.org" <pals@ietf.org>
Cc: "pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>
Date: Fri, 2 Oct 2015 16:41:05 +0100
Subject: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward

I am sorry that this is a long email, but I wanted to collect the
facts together in one place and set out the complete scene to
the PALS WG.

The critical concern is contained in the following email fragment
from Lizhong:

=======

In RFC4447 and 4447bis, it clearly said:

Using the PWid FEC, each of the two pseudowire endpoints
   independently initiates the setup of a unidirectional LSP.   An
   outgoing LSP and an incoming LSP are bound together into a single
   pseudowire if they have the same PW ID  and PW type.
The behavior is a correct description for LDP-DU mode which PW applies.
And that is also the behavior most vendors implement.
 
Then in draft-ietf-l2vpn-vpls-pe-etree-09, it says:
 A PE that receives a PW label mapping message with an E-Tree Sub-TLV
   from its peer PE, after saving the VLAN information for the PW, MUST
   process it as follows:
.....
3) If the P bit is set
 
      {
 
          If the PE is a leaf-only node itself, a label release message
      with a status code "Leaf to Leaf PW released" is sent to the peer
      PE and exit the process;
 
          Else the PE SHOULD set the Optimized-Mode to TRUE.
 
      }
That means, if PE1 receiving a label mapping from PE2 with P bit set, 
PE1 will send label release. Then PE2 will never send label mapping
again to PE1 even when PE1 changes from leaf-only node to root-leaf node. For LDP-DU
mode, PE2 will not send label mapping again when receiving PE1's label mapping.
Then the PW will not be setup successfully. Then only way is to configure the 
same PW on PE2 again.
The correct behavior is, label release message should not be sent.
For PW signaling, the unacceptable of any Interface Parameter will not lead to any 
label release, but just simply let the PW down in forwarding plane.
 

========

Andy looked at this from the point of view of the MEF and notes in
private conversation:

=========

In the E-tree service as defined by MEF, you can have one or more roots
and one or more leafs.

 

In a single E-tree service (think of a multipoint PW with some of the CEs
configured as roots as some as leafs), all leafs and roots receive frames
sent by the roots. All roots receive frames sent by the leafs. However,
leafs may not receive any frames sent by other leafs.

 

The draft, as written, doesn't bring up an underlying pt-to-pt PWs to
carry frames for the service between PEs that only have leafs attached.
Since the leafs can't sent frames to each other, that is an economical
use of PWs in the network.

 

Lizhong's point is that this makes it impossible to add a new root to
an existing PE in an E-tree that previously only had leafs.

 

I agree that would be a problem if there was a requirement to modify
an existing E-tree service. However, this draft has no other mechanisms
to explicitly support E-tree modification, nor is such modification a
requirement of the underlying MEF specification. BTW, since this work
was started, the MEF replaced MEF 6.1 with MEF 6.2, "EVC Ethernet
Services Definitions Phase 3", August, 2014, and that reference should
be updated in the draft.

My opinion is that the draft as it stands is technically correct if you
don't need the ability to reconfigure an existing E-tree service dynamically.

==========

Now whilst I can support the idea that dynamic reconfiguration of
E-tree is not needed, I have a concern.

My understanding the text in question is that it is saying that if
A is configured as leaf only, and B which is also configured as
leaf only attempts to configure a PW between them, then A rejects
the PW setup.

That sounds very reasonable to me, since there is a misconfig.

If A did not do the reject, then B would forever be consuming
resource waiting for A and B would have no idea of the
misconfig. That accords with Andy's view above.

However I was worried what would happen if A was misconfigured
as leaf only and the configuration was corrected to root-leaf.
What would in my view be difficult to accept was the need to
take a human, or NMS action at B to recover the situation.
However provided that A closed the LDP session with B
and re-instate it B would then send the mapping message again.
Thus the system is recoverable without needing to visit B which
is in my mind a fundamental requirement since A could have
got into the wrong mode as a result of an error.

The problem I see is if A has a bunch of other PWs with B
they will get torn down in order for A to have the config error
fixed. However if that is a problem you need two LDP sessions
between A and B, one for L2VPN and one for regular PWs.

My inclination is that the draft is basically correct, and that whilst
Lizhong is correct that the PW will not come up without some
action, reconfiguring the PW on B is not the only action
that will cause the PW to come up.

So this comes down to a WG decision in terms of which is the
least unacceptable behaviour - A having to re-cycle the LDP
session, or B wasting resources. I think I prefer the behaviour
proposed in the draft.

A way forward is to leave the logic as written in the draft, but to
add text describing the basis for excluding dynamic re-configuration
as a normal operational mode and to note the actions that need
to be taken when re-configuration is forced for some reason.

Whilst we were pondering what do with the text the chairs
and AD received another proposal from the authors:

======

In general, FEC PWid(0x80) is used in VPLS with manual provisioning,
while Generalized PWid (0x81) is used with auto-discovery.

As discussed in Section 5.2, VLAN mapping parameters can be provisioned
without a signaling protocol, Optimized Mode can also be a parameter
to be provisioned.

The approach we’ve taken in the current draft-ietf-l2vpn-vpls-pe-etree-09
does allow this. Quite a few service providers may prefer to control
all these E-Tree connectivity by themselves.

When E-Tree signaling protocol for PWid FEC is considered, the following
options are also feasible:

a)       Disable Optimized mode for FEC PWid(0x80), thus root/leaf role
change in the E-Tree topology will not have any influence on the PW.

b)       Add another appendix into the document for the full support of
Optimized mode with FEC PWid(0x80).

The idea is: the PE sends a label mapping firstly and then send a label
request to its peer PEs (so that they will reply with a label mapping
respectively).

Since Optimized mode is an optional piece in the document, I would
regard option a) as a simple tradeoff (as I am aware, E-VPN does not
support Optimized mode for E-Tree either.

========


Thus we have three proposals on the table:

1) Leave the design as it is, but add text to describe the constraint and
what happens if you have to change mode and what to do about it.

2) Exclude optimization in the FEC PWid(0x80) case

3) Add an appendix describing support for the FEC PWid(0x80) case.

My inclination would be to go with option (1) but I seek the views of
the WG, and of course any corrections in my analysis.

- Stewart


_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

 

 



_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals




-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------030708080606050804080701-- From nobody Wed Oct 21 11:04:44 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 217711B2C1F; Wed, 21 Oct 2015 11:04:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021180442.2484.35778.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 11:04:42 -0700 Archived-At: Cc: pals-chairs@ietf.org, draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org, agmalis@gmail.com, draft-ietf-pals-mpls-tp-mac-wd@ietf.org, pals@ietf.org Subject: [Pals] Kathleen Moriarty's No Objection on draft-ietf-pals-mpls-tp-mac-wd-02: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 18:04:43 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-pals-mpls-tp-mac-wd-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-mac-wd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also agree with the SecDir review (Stephen already provided a link) and would like to see the security considerations specific to this draft added. From nobody Thu Oct 22 03:16:09 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78301B3655; Thu, 22 Oct 2015 03:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODNlrR7U27AS; Thu, 22 Oct 2015 03:16:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA581B363E; Thu, 22 Oct 2015 03:16:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F03B22CC6C; Thu, 22 Oct 2015 13:15:58 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_faCHU5objt; Thu, 22 Oct 2015 13:15:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id A3F662CC6B; Thu, 22 Oct 2015 13:15:56 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7D9522E8-2195-4AFC-82D7-5AA28BDDB140"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Jari Arkko In-Reply-To: Date: Thu, 22 Oct 2015 11:15:55 +0100 Message-Id: References: <56216C90.4060606@nostrum.com> To: "Andrew G. Malis" , Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-pals-redundancy-spe.all@ietf.org, General Area Review Team , "ietf@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 10:16:04 -0000 --Apple-Mail=_7D9522E8-2195-4AFC-82D7-5AA28BDDB140 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Robert: Many thanks for your detailed review. I will send some technical = comments on this topic but wanted to answer you and Andrew on the IPR issue separately: Robert wrote: > That happens sometimes, but it's much better to have a real indication > that the group considered the disclosure and explicitly decided not to > change directions. Andrew wrote: > The IPR declaration is against the original individual draft, = draft-dong-pwe3-redundancy-spe. The IPR declaration was from a company = that was not represented as an author on the draft, and offered free = licencing with reciprocity. OK. Interesting background information. > At the time, no concerns were raised by either the authors or from = anyone in the WG in response to the declaration. This, IMHO, is normal = operating procedure when IPR declarations are made, especially by = non-author entities and early in the process. The usual concern is when = declarations come in late in the process, especially from an author = company. Neither was the case here, it was still an individual draft. = And of course, the declaration was clear for all to see during both WG = adoption and WG LC polls. I think this is the key. The standing practice at the IETF is that IPR = gets declared, timely, and the information is used by the participants = when they decide things like whether they support document adoption = (among many other factors). I find that there is often no explicit = discussion but those that care take the information into account, in = careful and competent manner and through consultation with their = colleagues back home etc. So, it appears that the right thing happened here, and your answer above = is the right one for Robert=92s question. However, I have one question, as I started digging=85 First, this is one = of those many cases where an individual draft has an IPR declaration and = the later adoption into a WG draft doesn=92t lead to a new declaration. = Our tools usually track this correctly, as long as the replaced-by = information is correctly updated. (WG chairs: please check that this = happens when you adopt documents.) But in this case I noticed that = http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows 1 = IPR whereas = https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02 does not. = But https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 does. = What gives? Robert, do you know if the tools version does not track = through replaced-by? Getting such information properly displayed in all = cases might be important, as many people use the tools server to view = drafts. In any case, my question is, I think, not relevant to the question of = whether the group properly considered *this* case, because at the time = that the document was adopted, it was an individual draft and therefore = likely correctly displayed in all tools. The date of IPR declaration was = Nov 2012, and the first WG document on this (in PWE3) appeared in = December 2012. Jari >=20 > Thanks, > Andy >=20 >=20 > On Fri, Oct 16, 2015 at 11:30 PM, Robert Sparks = wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-pals-redundancy-spe-02 > Reviewer: Robert Sparks > Review Date: 16 Oct 2015 > IETF LC End Date: 19 Oct 2015 > IESG Telechat date: 22 Oct 2015 >=20 > Summary: Almost ready for publication as PS but with issues that need = to be discussed/addressed >=20 > This document is hard to read. It is more acronym-laden than it > needs to be. >=20 > ----- > There is a process issue that the IESG should pay attention to. > The shepherd writeup says this: >=20 > "There is one IPR declaration (1911) raised in November 2012 against > an early version of the draft. There was no discussion in the WG > related to this." >=20 > ----- >=20 > The last sentence of the 2nd paragraph (declaring multi-homing on both > sides of an S-PE out of scope) should be moved earlier in the = document. > The introduction and perhaps even the abstract can be clearer about > what _is_ in scope. >=20 > It needs to be clearer where the normative description of behavior is. > I think you're intending it to be the first part of section 3. I have > not worked through the references enough to ensure that it is = complete. >=20 > The third paragraph starts off "In general, ...". Are there any > specific cases where the requirements that follow do not hold? If so, > there needs to be more description. If not, please delete "In = general,". >=20 > Are sections 3.1 and 3.2 supposed to be only examples? Would the > specification of the protocol be complete if they were deleted? If = not, > something needs to be moved up into the main part of section 3. > For instance, is the SHOULD at the end of 3.1 a requirement placed by > this document, or is it restating a requirement from somewhere else? > Similarly, please inspect the SHOULD in the second paragraph of 3.2. >=20 > I also suggest moving 3.1 and 3.2 into their own section, clearly > labeling them as examples. >=20 > Is it worth more explanation in the document why you've added the > MUST NOT in the first paragraph of section 3? >=20 > The security considerations section only points off to other = documents. > Most of those just point to each other. Chasing it back, there's some > meat in the security considerations section of 4447, and some in 5085, > but it's a real chase to find what's relevant. Please consider = calling > out what an implementer needs to consider explicitly here. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_7D9522E8-2195-4AFC-82D7-5AA28BDDB140 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWKLdbAAoJEM80gCTQU46qmhAP/2JWCXWVmPAjt3mNAHUgaiHd yKRV7TCT2Tjm284UFoTbT6mA0r9n2dLL3J+DfMFZlQt3pfJHe1QJuCR7dYmNJqDW 6UdCodwXQJIuPitfzt2UUEiJMKBIATAwh2qEwinWeGIZadCI9PmoqSg8Sz9OtgPM vwAmj5xI1Q8Jkcqgh7bg3Adn3WOqQ86fou8sa31wtk5yoqAdXnT1FcBhVBjWW15Y NEUueIoLxwso4gIC/q9f29u5NbQflnSBwZixSthJl/nY9pjKZpw/3h271bxIz3NH HkQkKBNbgSfwPDaVspoktmug34HETH4RyPqmJeI6lLHLvMwW/a8bqi2tRcvM/A/W V48XwDoCS9Jk5ZpZPNp4ge0ndu1amkuFyM1wfV072dFA4eU4SrMcK2XcW0UPcQ4T 0QqO+d0S29Td96JTwBK0CCeU+u+fF50VQXMTpX03xiNxSDejEdr4Eo9wHXFkqVH6 S9JC2vSrokiYHvRcw+f07BDad17h9jukiBC3+AJz6fPahlodlFH+KULgb2XZr9Bp 3qBvrE7VqYbrxJUASozJivx1AmgNA63JLjIz+P+WEeJI4pNX13EFxosaDbMhrjSU nA5Hpfj1OIcHqphsWoc0ZDuneqGvulqfJ7qtfSgVh0zJ9Uc9kE+KZvVKYuOK00fN fcRC6Ze3l3Q9IJuzRXLW =32pH -----END PGP SIGNATURE----- --Apple-Mail=_7D9522E8-2195-4AFC-82D7-5AA28BDDB140-- From nobody Thu Oct 22 05:34:45 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8471B3671; Thu, 22 Oct 2015 05:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwwX0OkhIJkC; Thu, 22 Oct 2015 05:34:41 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id BC5161B366E; Thu, 22 Oct 2015 05:34:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0492D2CEA1; Thu, 22 Oct 2015 15:34:34 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI9oMCrWa1ct; Thu, 22 Oct 2015 15:34:33 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id E9B632CCD0; Thu, 22 Oct 2015 15:34:32 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CA03D7B3-A042-4788-AC82-B1A6954BECDB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Jari Arkko In-Reply-To: <5625B071.6040303@nostrum.com> Date: Thu, 22 Oct 2015 13:34:31 +0100 Message-Id: <09F4862E-884F-475F-BAC9-68CB31EE724D@piuha.net> References: <56216C90.4060606@nostrum.com> <76CD132C3ADEF848BD84D028D243C927743BD6AC@nkgeml512-mbx.china.huawei.com> <5625B071.6040303@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-pals-redundancy-spe.all@ietf.org" , "Dongjie \(Jimmy\)" , General Area Review Team , "pals@ietf.org" Subject: Re: [Pals] [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 12:34:43 -0000 --Apple-Mail=_CA03D7B3-A042-4788-AC82-B1A6954BECDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Robert, Jimmy, Thanks for the review & discussion. =46rom my perspective some of the things that Robert raises are very = valid questions. The particular item that I=92m perhaps most interested in is = the text in Section 3.2, which seems like explaining what happens in an = example, but it also uses normative language and keywords to say what various = entities should do. Yet, the example is just one example. Is there a need to lift = the keyword statements out of this paragraph and generalise them to make sure that the specification is about the general case and not about the example? Alternatively, maybe I misunderstood the purpose of the keyword statements. (I also agree with Robert that the document is fairly hard to read. This = isn=92t the first document in the IETF to be like that, and I didn=92t feel that = this issue is discuss-worthy.) Jari --Apple-Mail=_CA03D7B3-A042-4788-AC82-B1A6954BECDB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWKNfXAAoJEM80gCTQU46qAcUP/RfThZr4kGaE3c9Xuw4ZXEbC 38xIYxGz74cq6Oz2Pd7iMNVWekhQmJCycv3iiRsXLiP2kgVburOkHtv1a4ygS69e P5KSCfXGNG9VIFdmxvhgCC+AtnqvbT5F0PDdmlz94INbHVAuBCI826bB7njxoMp6 AL7//4yMwKiftNtqL7BMedtHAm0ncS3E/ZxVPaAnDqj6Fny8Ia9RK1vXAXgO0JO3 YD4trdjxbWwQ6SV9hxWT7BRkiSLUv2gaIdnpD3/6YRxrO/Vle00ngDZPkDFuUZLQ FJcLbF/cNzJkUkCWXsoGmE6Afy4cNW204CN0tW8QHrYzRkXvfWh4ye5d0vJYWOZn 8y1FaTAIqZ/yVcR6RsPAeDPS3gXctnNxle1x4rXvQ5acz946Rig+p3sCGzZwIk4I nztXAZIGscXSTFCSYJMxCb853ceeKNnwsXwjevgsLGENbuE5Nwhr0T3KnRIFb/Y4 4R3a1oLN/6Kz5d8JjNcv9fwRXlaKwNF2REGI7SRc7eIy4MidyEetEzEWSHvWPYBv nV0eoMSK1/fiRW4a1WLkufNcnjFvDeuJmAvzr6N30PAL0iWURCrQCLEClVpKbDeW l2kLKlC0hX+SYjFMH6Yof2Hyj2gbTsnLIvsIqLXBbSEvhljecPumf+xGZvxW94z5 RSnrpcKjNezaCydrUb6j =GOSQ -----END PGP SIGNATURE----- --Apple-Mail=_CA03D7B3-A042-4788-AC82-B1A6954BECDB-- From nobody Thu Oct 22 05:36:48 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 328AC1A8A54; Thu, 22 Oct 2015 05:36:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151022123645.30987.14154.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 05:36:45 -0700 Archived-At: Cc: matthew.bocci@alcatel-lucent.com, draft-ietf-pals-redundancy-spe@ietf.org, pals-chairs@ietf.org, pals@ietf.org, draft-ietf-pals-redundancy-spe.all@ietf.org, rjsparks@nostrum.com Subject: [Pals] Jari Arkko's Discuss on draft-ietf-pals-redundancy-spe-02: (with DISCUSS and COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 12:36:45 -0000 Jari Arkko has entered the following ballot position for draft-ietf-pals-redundancy-spe-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- >From my perspective some of the things that Robert raises in the Gen-ART review are very valid questions. I'm raising one of those items in this Discuss. The particular item that I’m interested in is the text in Section 3.2, which seems like explaining what happens in an example, but it also uses normative language and keywords to say what various entities should do. Yet, the example is just one example. Is there a need to lift the keyword statements out of this paragraph and generalise them to make sure that the specification is about the general case and not about the example? Alternatively, maybe I misunderstood the purpose of the keyword statements. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I also agree with Robert that the document is fairly hard to read. This isn’t the first document in the IETF to be like that, and I didn’t feel that this issue is discuss-worthy.) From nobody Thu Oct 22 07:47:13 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B0C1A88B3; Thu, 22 Oct 2015 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMDFAdR-QnL4; Thu, 22 Oct 2015 07:47:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0491A88A6; Thu, 22 Oct 2015 07:47:10 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9MEl5Sv049613 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 22 Oct 2015 09:47:05 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: Jari Arkko , "Andrew G. Malis" References: <56216C90.4060606@nostrum.com> From: Robert Sparks Message-ID: <5628F6E3.4010302@nostrum.com> Date: Thu, 22 Oct 2015 09:46:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-pals-redundancy-spe.all@ietf.org, General Area Review Team , "ietf@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:47:11 -0000 On 10/22/15 5:15 AM, Jari Arkko wrote: > But in this case I noticed that > http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows > 1 IPR whereas > https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02 does > not. But https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 > does. What gives? Robert, do you know if the tools version does not > track through replaced-by? Getting such information properly displayed > in all cases might be important, as many people use the tools server > to view drafts. Yes, the tools servers don't currently follow replaces the same way the datatracker does. Henrik is aware of it, and is working to make them say the same thing. RjS From nobody Thu Oct 22 07:53:21 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498421A0366; Thu, 22 Oct 2015 07:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkKbOtORe4x1; Thu, 22 Oct 2015 07:53:17 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 01B1C1A0143; Thu, 22 Oct 2015 07:53:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 546B02CCD0; Thu, 22 Oct 2015 17:53:16 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgp_mJ4oIl-0; Thu, 22 Oct 2015 17:53:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 690F82CC6B; Thu, 22 Oct 2015 17:53:15 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BA4E53B2-0D3D-4239-9875-B9913E264718"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Jari Arkko In-Reply-To: <5628F6E3.4010302@nostrum.com> Date: Thu, 22 Oct 2015 15:53:15 +0100 Message-Id: <45FEBAE8-314E-40D5-8D73-2EBB483C8550@piuha.net> References: <56216C90.4060606@nostrum.com> <5628F6E3.4010302@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-pals-redundancy-spe.all@ietf.org, General Area Review Team , "Andrew G. Malis" , "ietf@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:53:18 -0000 --Apple-Mail=_BA4E53B2-0D3D-4239-9875-B9913E264718 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Yes, the tools servers don't currently follow replaces the same way = the datatracker does. > Henrik is aware of it, and is working to make them say the same thing. Cool, thanks! Jari --Apple-Mail=_BA4E53B2-0D3D-4239-9875-B9913E264718 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWKPhbAAoJEM80gCTQU46qneMQAKoLlRR4Z0Qbgot6Cr1dtpON SVmQunbbYN7ThR9VunTUSLPb99igNOLgf2ZIqTmiC+DgmwjX42/fkRBEgF5ogdy0 U49gl+2kjRmX+aHyH5kUQR/CvpDps6GhX0Put3G4nQ1ZbhdEBVYAWxriL+b/wD6V UYYH9OzouT+Ylr6bwG/Mu1G2KB5TYxzf3qZ5nY+os5rhihKwY9bW/ZPRmdP3TFea Cnj+qdkZjFQZ/yNrQcqzJdLJsJbR1hpiA5+pY/AVLw3Iax+Cdk+57FqH9qZdZXU2 V8n5wnCILU/d2wSKLPUqAAHs+Ro5FtLLWQu+gB7SV+RSy+qVbHUmvmAiVod8I0NF APdAPW/OfvEBc3G3VnptTqoCGR2Zh8k75hTvR8hFlycR5x61F2U79ObAsLDqXRd7 bDzt8sAaF06pPz/8XsWm026VodsFxdIXJW6q08MeOox4OOIkw0bttlmLwn4IeQAR IgQvhrE/7pk7LsD1jXBbNPPBvJH53JYUmXJykZkjzOhOc6auTuXXOttvyThhyvQA I0PKbyfmNp24oifm5K765WkBi/KweEIBsHD+v4UMPYRBBDdZdDBWr0AdsnvzlgvH jh2xB8JH5zL0EzKTLY9H01u1e2PaOVoRpWr5mi7iX632LEof5XpPdU1chaUbb8Oh SfIyxSjwEs1IJx8pC/0h =qqqU -----END PGP SIGNATURE----- --Apple-Mail=_BA4E53B2-0D3D-4239-9875-B9913E264718-- From nobody Thu Oct 22 12:17:13 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F31F1A89ED; Thu, 22 Oct 2015 12:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqHMIIasFNeh; Thu, 22 Oct 2015 12:17:09 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981821A8AD1; Thu, 22 Oct 2015 12:17:09 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9MJG2tM021396; Thu, 22 Oct 2015 15:17:08 -0400 Received: from vawvcgsie2k1301.ciena.com (lin1-118-36-35.ciena.com [63.118.36.35]) by mx0a-00103a01.pphosted.com with ESMTP id 1xpyf4smct-2 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2015 15:17:08 -0400 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 15:17:06 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by MDWVEXCHHT02.ciena.com (10.4.156.176) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 22 Oct 2015 15:17:06 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 22 Oct 2015 15:17:05 -0400 From: "Shah, Himanshu" To: Alia Atlas , The IESG Date: Thu, 22 Oct 2015 15:17:04 -0400 Thread-Topic: Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) Thread-Index: AdEKq+nvKlsg2HNHQWOSUzkdyOqsDgCT/WyQ Message-ID: <40746B2300A8FC4AB04EE722A593182B9C378022@ONWVEXCHMB04.ciena.com> References: <20151019202150.5112.33326.idtracker@ietfa.amsl.com> In-Reply-To: <20151019202150.5112.33326.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-21896.002 X-TM-AS-Result: No--3.267300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-22_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510220321 Archived-At: Cc: "pals-chairs@ietf.org" , "draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org" , "agmalis@gmail.com" , "draft-ietf-pals-mpls-tp-mac-wd@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 19:17:11 -0000 U29ycnkgSSBtaXNzZWQgdGhpcyBlbWFpbCBlYXJsaWVyLi4gRGVib3JhaCByZW1pbmRlZCBtZS4N Cg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KWW91IHJhaXNlIGdvb2QgcG9pbnQgYW5kIHdl IGhhdmUgYWdvbml6ZWQgb3ZlciB0aGlzIGJlZm9yZS4NCkkgd2lsbCB0ZWxsIHlvdSB3aHkgd2Ug ZGlkIG5vdCBjaG9vc2UgIk1VU1QiIGFuZCB5b3UgY2FuIHRoZW4gcHJvdmlkZSBmdXJ0aGVyIGd1 aWRhbmNlLg0KDQpBcyB0aGUgdGltZSBwYXNzZXMsIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBvZiB0 aGUgTUFDIHdpdGhkcmF3IGhhcyBkaW1pbmlzaGluZyByZXR1cm4NCmFuZCBtYXkgYmUgZXZlbiBo YXJtZnVsLiBUaGUgdHJhZmZpYyBpbiBub2RlcyBwcmVzZW50IGluIG5ldyBwYXRoIGhhdmUgYWxy ZWFkeSBzdGFydGVkDQpidWlsZGluZyBNQUMgZGF0YWJhc2UuIElmIE1BQyBmbHVzaCBhcnJpdmVz IHdheSBsYXRlciAoYWZ0ZXIgZXhwb25lbnRpYWwgYmFja29mZiksIHRoZSBuZXcNCmRhdGFiYXNl IHdvdWxkIGdldCBmbHVzaGVkIHJlc3VsdGluZyBpbiBhbm90aGVyIGJyb2FkY2FzdCAoZHVlIHRv IHVua25vd24gRE1BQykuDQoNCg0KU28gZ29pbmcgYmFjayB0byB0aGUgb3JpZ2luYWwgdGV4dCBh bmQgeW91ciBjb21tZW50Og0KT3JpZ2luYWwgdGV4dDogIlRoZSByZXRyYW5zbWlzc2lvbiBNVVNU IGJlIGNlYXNlZCBhbnl0aW1lIHdoZW4gQUNLIGlzIHJlY2VpdmVkIG9yIGFmdGVyIHRocmVlIHJl dHJpZXMuIg0KDQpIZXJlIE1VU1QgYXBwbGllcyB0byAtDQotIHdoZW4gQUNLIGlzIHJlY2VpdmVk DQotIHdoZW4gMyByZXRyaWVzIGFyZSBkb25lDQoNClRoZSBpbnRlcnZhbHMgYmV0d2VlbiBlYWNo IHJldHJpZXMgYXJlIC0NCi0gc3VnZ2VzdGVkIGFzIDEgc2Vjb25kDQotIGJ1dCBpbmNyZW1lbnRh bCBiYWNrb2ZmIGlzIGFsc28gYSBjb25zaWRlcmF0aW9uLiANCiAgIFRoaXMgdGV4dCBpcyBmcm9t IG91ciBleHBlcmllbmNlIG9uIHRoZSBpbXBsZW1lbnRhdGlvbi4gRm9yIGV4YW1wbGUgaWYgeW91 IGhhdmUgMTAwMCBQV3MgdGhhdCBmYWlsb3ZlciB0byBiYWNrdXAgUFdzDQogICBEdWUgdG8gcHJp bWFyeS9iYWNrdXAgTFNQIGdvaW5nIGRvd24sIHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIHdvdWxk IGJvdGggYmVjb21lIGJ1c3kgcHJvY2Vzc2luZyBsYXJnZSBudW1iZXIgb2YgV0QNCiAgIFNpZ25h bHMuIEEgbGl0dGxlIHBhY2luZyBtYXkgaGVscC4gSG93ZXZlciwgbG9uZ2VyIGJhY2tvZmYgKGFz IGRpc2N1c3NlZCBhYm92ZSkgcGVyaW9kIGlzIG5vdCBnb29kIGVpdGhlci4NCiAgIEluIGVpdGhl ciBjYXNlLCB0aGVyZSBpcyBubyBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlIC0gc28gdGhlIHRvcGlj IGlzIG5vdCBkaXNjdXNzZWQgZnVydGhlci4uDQoNCg0KSG9wZSB0aGlzIGNsZWFycyB1cCwgYXQg bGVhc3QgdGhlIHRoaW5raW5nIGJlaGluZCBpdC4NClBsZWFzZSBkbyBwcm92aWRlIGd1aWRhbmNl Li4uDQoNCg0KVGhhbmtzLA0KSGltYW5zaHUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQWxpYSBBdGxhcyBbbWFpbHRvOmFrYXRsYXNAZ21haWwuY29tXSANClNlbnQ6IE1v bmRheSwgT2N0b2JlciAxOSwgMjAxNSA0OjIyIFBNDQpUbzogVGhlIElFU0cNCkNjOiBkcmFmdC1p ZXRmLXBhbHMtbXBscy10cC1tYWMtd2RAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRw LW1hYy13ZC5hbGxAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQGlldGYub3JnOyBhZ21hbGlzQGdtYWls LmNvbTsgcGFsc0BpZXRmLm9yZw0KU3ViamVjdDogQWxpYSBBdGxhcycgRGlzY3VzcyBvbiBkcmFm dC1pZXRmLXBhbHMtbXBscy10cC1tYWMtd2QtMDI6ICh3aXRoIERJU0NVU1MpDQoNCkFsaWEgQXRs YXMgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1p ZXRmLXBhbHMtbXBscy10cC1tYWMtd2QtMDI6IERpc2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtbWFjLXdkLw0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSSBleHBlY3QgdGhhdCB0aGlzIGlzIGEg dmVyeSBzaW1wbGUgYW5kIHF1aWNrIERpc2N1c3MgdG8gZGVhbCB3aXRoLg0KDQoxKSBJbiBTZWMg NC4xLCBpdCBmaXJzdCBzYXlzICJUaGUgcmV0cmFuc21pc3Npb24gTVVTVCBiZQ0KICAgY2Vhc2Vk IGFueXRpbWUgd2hlbiBBQ0sgaXMgcmVjZWl2ZWQgb3IgYWZ0ZXIgdGhyZWUgcmV0cmllcy4iIHdo aWNoIGlzIGZpbmUgYnV0IHRoZW4gLSAiRm9yIGluc3RhbmNlLCAxIHNlY29uZCANCiAgIHJldHJh bnNtaXNzaW9uIHdpdGggdGhyZWUgcmV0cmllcyBpbiBhYnNlbmNlIG9mIEFDSyByZXNwb25zZSBp cyANCiAgIHN1Z2dlc3RlZCBpbiB0aGlzIGRvY3VtZW50LiAgSG93ZXZlciwgaW5jcmVtZW50YWwg YmFja29mZiB3aXRoIGhpZ2hlcg0KICAgbnVtYmVyIG9mIHJldHJpZXMgaXMgYWxzbyBmZWFzaWJs ZSBhbmQgbWF5IGJlIHdvcnRoIGNvbnNpZGVyYXRpb24gdG8gDQogICBhZGRyZXNzIHRoZSBzY2Fs ZSBpc3N1ZXMuICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1hbmRhdGUgYSBzdHJpY3QgDQogICBn dWlkZWxpbmUgc2luY2UgdGhlcmUgYXJlIG5vIGludGVyb3BlcmFiaWxpdHkgaW1wbGljYXRpb25z LiINCg0KQ0xFQVJMWSwgdXNpbmcgTVVTVCBpcyBtb3JlIHRoYW4gYSBnZW50bGUgc3VnZ2VzdGlv biAtIGJ1dCBpcyBleGFjdGx5IG1hbmRhdGluZyBhIHN0cmljdCBndWlkZWxpbmUuDQoNClBsZWFz ZSBmaXggZWl0aGVyIHRoZSBNVVNUIG9yIHRoZSByZW1haW5pbmcgdGV4dC4NCg0KDQoNCg0K From nobody Thu Oct 22 14:04:41 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51611B41A6 for ; Thu, 22 Oct 2015 14:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7_QviPUlj0E for ; Thu, 22 Oct 2015 14:04:37 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FDF1B41A3 for ; Thu, 22 Oct 2015 14:04:36 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-ec-5628e29a03eb Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 21.30.26730.A92E8265; Thu, 22 Oct 2015 15:20:27 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Thu, 22 Oct 2015 17:04:34 -0400 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: [Pals] PALS IETF 94 Slot Requests - Yokohama Thread-Index: AQHQ/xB5A8vWE7QZfEOujCPi3lHk7J5zaY7QgASy0YA= Date: Thu, 22 Oct 2015 21:04:34 +0000 Message-ID: References: <871EB8879748FA458598F0461906289322DCD4C4@eusaamb103.ericsson.se> In-Reply-To: <871EB8879748FA458598F0461906289322DCD4C4@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_D24EC6D81A65C3davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPuO7sRxphBo8iLNb8W8fkwOixZMlP pgDGKC6blNSczLLUIn27BK6M31ebWAu6LzFWvDmT1cB4eCdjFyMnh4SAicSNY9eYIWwxiQv3 1rN1MXJxCAkcZZQ4eXMJE0hCSGA5o8TUVREgNhtQw7qNe1hAbBEBZYld56eADRIWsJRY1TmB HSJuJTF750tGGLtp2S82EJtFQFXicOcCsF5eoPjfx/sZIeYXSyzctBCsl1PAT6Kj4yzYXkag g76fWgNmMwuIS9x6Mp8J4lABiSV7zkMdLSrx8vE/VhBbVEBP4tOJjywQcSWJj7/ns0P0xkvc mreNFWKvoMTJmU9YJjCKzkIydhaSsllIyiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2ljiy 6AGKmgWMHKsYOUqLU8ty040MNzECI+uYBJvjDsYFnywPMQpwMCrx8CbMUg8TYk0sK67MPcQo wcGsJMLb/1QjTIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvvBn3Q4UE0hNLUrNTUwtSi2CyTByc Ug2MihEzLvHNUU54fjxO59Eax8bbh3wcFRcUSDwMVGj8PI2J3d23y5shxDawdU7Woo+zVuyZ U+oxbd7RZ+euHHtbcyj2o/jZKzyrF54S1tT3F/3fM29p4mvTjb7bVi09POe+CY/Jtj0PznEe T3z7/gSDYFDc81ojz0DHL0dzFvMyCp53ebPrnVzFfCWW4oxEQy3mouJEAI5dELOoAgAA Archived-At: Subject: Re: [Pals] PALS IETF 94 Slot Requests - Yokohama X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 21:04:40 -0000 --_000_D24EC6D81A65C3davidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, The PALS agenda is posted at the link below. https://www.ietf.org/proceedings/94/agenda/agenda-94-pals If you requested a slot and I haven=92t allocated one, my apologies, please= complete the form below and send it in reply to this email. Those that have slots allocated, please send me your slides as soon as you = complete them. I will need your slides no later than Saturday 31 October 2015 23:59:59 Yok= ohama time. If I don=92t have your slides by that time, you risk losing your slot. Thanks! Dave From: David A Sinicrope > Date: Monday, October 19, 2015 at 5:20 PM To: "pals@ietf.org" > Subject: RE: [Pals] PALS IETF 94 Slot Requests - Yokohama Reminder=85 If you need a slot please follow the instructions below. Thanks! Dave From: Pals > on behalf = of David Sinicrope > Date: Friday, October 2, 2015 at 2:51 PM To: "pals@ietf.org" > Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama Hi All, It's that time again. If you need a presentation slot for the IETF 94 PALS session, please reply = to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests and be lost in my email, never to be fou= nd. :-) Form: 1. topic (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker =96 you only need to provide the file n= ame to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pw= e3-mpls-eth-oam-iwk/): 3. brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting (e.g., need to address security issu= es and get direction from the WG): 4. requested duration (norm/default is 10 min): 5. speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave From: Patrice Brissette (pbrisset) [mailto:pbrisset@cisco.com] Sent: Sunday, October 04, 2015 21:52 To: David Sinicrope Subject: Re: [Pals] PALS IETF 94 Slot Requests - Yokohama Hi David, I=92ll like to have a slot regarding L2VPN Yang. Regards, Patrice [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.= png?ct=3D1406640631632] Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before y= ou print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: Pals > on behalf = of David Sinicrope > Date: Friday, October 2, 2015 at 2:51 PM To: "pals@ietf.org" > Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama Hi All, It's that time again. If you need a presentation slot for the IETF 94 PALS session, please reply = to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests and be lost in my email, never to be fou= nd. :-) Form: 1. topic (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker =96 you only need to provide the file n= ame to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pw= e3-mpls-eth-oam-iwk/): 3. brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting (e.g., need to address security issu= es and get direction from the WG): 4. requested duration (norm/default is 10 min): 5. speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave --_000_D24EC6D81A65C3davidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0A9BE4C8F8D85F46BAA48AEB0AE1FBD4@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi All,


The PALS agenda is posted at the = link below.

 

If y= ou requested a slot and I haven=92t allocated one, my apologies, please com= plete the form below and send it in reply to this email.<= /p>

 

Thos= e that have slots allocated, please send me your slides as soon as you comp= lete them.

I= will need your slides no later than Saturday 31 October 2015 23:59= :59 Yokohama time.

 

If I= don=92t have your slides by that time, you risk losing your slot.

Than= ks!

Dave=


From: David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Monday, October 19, 2015 at 5= :20 PM
To: "pals@ietf.org" <pals@i= etf.org>
Subject: RE: [Pals] PALS IETF 94 Sl= ot Requests - Yokohama

Reminder=85

If you need a slot please follow the instruc= tions below.

Thanks!

Dave

 

From: Pals <pals-bou= nces@ietf.org> on behalf of David Sinicrope <david.sinicrope@ericsson.com>
Date: Friday, October 2, 2015 at 2:51 PM
To: "pals@ietf.org" &= lt;pals@ietf.org>
Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama

 

Hi All,

It's that time again. =

If you need a presentation slot for th= e IETF 94 PALS session, please reply to this email (subjec= t intact) completing the form below.   

Please use this f= orm and please reply to this email with the subject intact.  (Not doing so probably means your req= uest will not trigger the filter I use to identify PALS slot requests = and be lost in my email, never to be found. :-)

 

Form:

1. topic (e.g., MPLS and Ethernet OAM Interworking):

2. URL to your draft on Datatracker = =96 you only need to provide the file name to the example URL (e.g.,&n= bsp;http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/):  

3. brief statement of objectives and i= ssues to be discussed and resolved via the presentation during the meeting =  (e.g., need to address security issues and get direction from the WG):  

4. requested duration (norm/default is= 10 min):  

5. speaker Given-name FAMILY-NAME (e.g= ., Dave SINICROPE):  

 

Thanks!

Dave

 

 

From: Patrice Brissette (pbrisset) [mailto:pbrisset@cisco.com]
Sent: Sunday, October 04, 2015 21:52
To: David Sinicrope
Subject: Re: [Pals] PALS IETF 94 Slot Requests - Yokohama=

 

Hi David,

 

I=92ll like to have a slot regarding L2VPN Y= ang.

 

 

Regards,

 

Patrice<= /o:p>

   

Patrice Brissette
TECHNICAL LEADER.ENGINEERING

pbrisset@cisco.com
Phone: +1 613 2= 54 3336

Cisco Systems Canada Co. / Les Systemes Cisco = Canada CIE
Canada
Cisco.com

 

Think b= efore you print.

This email may contain confidential and privileged mat= erial for the sole use of the intended recipient. Any review, use, distribu= tion or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receiv= e for the recipient), please contact the sender by reply email and delete a= ll copies of this message.

Please click here for Company Registratio= n Information.


 

From: Pals <pals-bou= nces@ietf.org> on behalf of David Sinicrope <david.sinicrope@ericsson.com>
Date: Friday, October 2, 2015 at 2:51 PM
To: "pals@ietf.org" &= lt;pals@ietf.org>
Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama

 

Hi All,

It's that time again. =

If you need a presentation slot for th= e IETF 94 PALS session, please reply to this email (subjec= t intact) completing the form below.   

Please use this f= orm and please reply to this email with the subject intact.  (Not doing so probably means your req= uest will not trigger the filter I use to identify PALS slot requests = and be lost in my email, never to be found. :-)

 

Form:

1. topic (e.g., MPLS and Ethernet OAM Interworking):

 --_000_D24EC6D81A65C3davidsinicropeericssoncom_-- From nobody Thu Oct 22 14:34:10 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8147A1B4274; Thu, 22 Oct 2015 14:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNKwnBeiRsG6; Thu, 22 Oct 2015 14:34:03 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E291B426B; Thu, 22 Oct 2015 14:34:02 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9MLVVcb013003; Thu, 22 Oct 2015 17:33:59 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 1xkjjd34ym-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Oct 2015 17:33:58 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 22 Oct 2015 17:33:58 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Thu, 22 Oct 2015 17:33:57 -0400 From: "Shah, Himanshu" To: Alia Atlas , The IESG Date: Thu, 22 Oct 2015 17:33:56 -0400 Thread-Topic: Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) Thread-Index: AdEKq+nvKlsg2HNHQWOSUzkdyOqsDgCT/WyQAAUiL1A= Message-ID: <40746B2300A8FC4AB04EE722A593182B9C378111@ONWVEXCHMB04.ciena.com> References: <20151019202150.5112.33326.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-21896.003 X-TM-AS-Result: No--7.873600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-22_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510220362 Archived-At: Cc: "pals-chairs@ietf.org" , "draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org" , "agmalis@gmail.com" , "draft-ietf-pals-mpls-tp-mac-wd@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 21:34:05 -0000 SGkgQWxpYXMgLQ0KSSBtaXNzZWQgdGhlIGNydXggb2YgeW91ciBjb21tZW50Lg0KRGVib3JhaCBw b2ludGVkIG91dCB0aGUgZGlzY3JlcGFuY3kuDQoNClNvIEkgYWdyZWUgd2l0aCB5b3VyIGNvbW1l bnQuDQpMZXQgbWUgZml4IHRoZSB0ZXh0IGFuZCByZWR1Y2UgdGhlIHNjb3BlIG9mIE1VU1QgdG8g QUNLIG9ubHkuDQoNClNvIHRoZSByZXZpc2VkIHRleHQgd291bGQgYmUgLQ0KDQpJbiBTZWMgNC4x LA0KDQpPcmlnaW5hbCBUZXh0OiANCiJUaGUgcmV0cmFuc21pc3Npb24gTVVTVCBiZSBjZWFzZWQg YW55dGltZSB3aGVuIEFDSyBpcyByZWNlaXZlZCBvciBhZnRlciB0aHJlZSByZXRyaWVzLiINCg0K UmV2aXNlZCBUZXh0Og0KIlRoZSByZXRyYW5zbWlzc2lvbiBNVVNUIGJlIGNlYXNlZCBhbnl0aW1l IHdoZW4gQUNLIGlzIHJlY2VpdmVkLiINCg0KVGhlIHJlc3Qgb2YgdGhlIHRleHQgY2FuIHJlbWFp biBzYW1lLg0KDQpEb2VzIHRoaXMgY2hhbmdlIGFkZHJlc3MgeW91ciBjb25jZXJuPw0KDQpUaGFu a3MsDQpIaW1hbnNodQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaGFo LCBIaW1hbnNodSANClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDE1IDM6MTcgUE0NClRv OiAnQWxpYSBBdGxhcyc7IFRoZSBJRVNHDQpDYzogZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtbWFj LXdkQGlldGYub3JnOyBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1tYWMtd2QuYWxsQGlldGYub3Jn OyBwYWxzLWNoYWlyc0BpZXRmLm9yZzsgYWdtYWxpc0BnbWFpbC5jb207IHBhbHNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBBbGlhIEF0bGFzJyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcGFscy1tcGxz LXRwLW1hYy13ZC0wMjogKHdpdGggRElTQ1VTUykNCg0KU29ycnkgSSBtaXNzZWQgdGhpcyBlbWFp bCBlYXJsaWVyLi4gRGVib3JhaCByZW1pbmRlZCBtZS4NCg0KVGhhbmtzIGZvciB5b3VyIHJldmll dy4NCg0KWW91IHJhaXNlIGdvb2QgcG9pbnQgYW5kIHdlIGhhdmUgYWdvbml6ZWQgb3ZlciB0aGlz IGJlZm9yZS4NCkkgd2lsbCB0ZWxsIHlvdSB3aHkgd2UgZGlkIG5vdCBjaG9vc2UgIk1VU1QiIGFu ZCB5b3UgY2FuIHRoZW4gcHJvdmlkZSBmdXJ0aGVyIGd1aWRhbmNlLg0KDQpBcyB0aGUgdGltZSBw YXNzZXMsIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBvZiB0aGUgTUFDIHdpdGhkcmF3IGhhcyBkaW1p bmlzaGluZyByZXR1cm4gYW5kIG1heSBiZSBldmVuIGhhcm1mdWwuIFRoZSB0cmFmZmljIGluIG5v ZGVzIHByZXNlbnQgaW4gbmV3IHBhdGggaGF2ZSBhbHJlYWR5IHN0YXJ0ZWQgYnVpbGRpbmcgTUFD IGRhdGFiYXNlLiBJZiBNQUMgZmx1c2ggYXJyaXZlcyB3YXkgbGF0ZXIgKGFmdGVyIGV4cG9uZW50 aWFsIGJhY2tvZmYpLCB0aGUgbmV3IGRhdGFiYXNlIHdvdWxkIGdldCBmbHVzaGVkIHJlc3VsdGlu ZyBpbiBhbm90aGVyIGJyb2FkY2FzdCAoZHVlIHRvIHVua25vd24gRE1BQykuDQoNCg0KU28gZ29p bmcgYmFjayB0byB0aGUgb3JpZ2luYWwgdGV4dCBhbmQgeW91ciBjb21tZW50Og0KT3JpZ2luYWwg dGV4dDogIlRoZSByZXRyYW5zbWlzc2lvbiBNVVNUIGJlIGNlYXNlZCBhbnl0aW1lIHdoZW4gQUNL IGlzIHJlY2VpdmVkIG9yIGFmdGVyIHRocmVlIHJldHJpZXMuIg0KDQpIZXJlIE1VU1QgYXBwbGll cyB0byAtDQotIHdoZW4gQUNLIGlzIHJlY2VpdmVkDQotIHdoZW4gMyByZXRyaWVzIGFyZSBkb25l DQoNClRoZSBpbnRlcnZhbHMgYmV0d2VlbiBlYWNoIHJldHJpZXMgYXJlIC0NCi0gc3VnZ2VzdGVk IGFzIDEgc2Vjb25kDQotIGJ1dCBpbmNyZW1lbnRhbCBiYWNrb2ZmIGlzIGFsc28gYSBjb25zaWRl cmF0aW9uLiANCiAgIFRoaXMgdGV4dCBpcyBmcm9tIG91ciBleHBlcmllbmNlIG9uIHRoZSBpbXBs ZW1lbnRhdGlvbi4gRm9yIGV4YW1wbGUgaWYgeW91IGhhdmUgMTAwMCBQV3MgdGhhdCBmYWlsb3Zl ciB0byBiYWNrdXAgUFdzDQogICBEdWUgdG8gcHJpbWFyeS9iYWNrdXAgTFNQIGdvaW5nIGRvd24s IHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIHdvdWxkIGJvdGggYmVjb21lIGJ1c3kgcHJvY2Vzc2lu ZyBsYXJnZSBudW1iZXIgb2YgV0QNCiAgIFNpZ25hbHMuIEEgbGl0dGxlIHBhY2luZyBtYXkgaGVs cC4gSG93ZXZlciwgbG9uZ2VyIGJhY2tvZmYgKGFzIGRpc2N1c3NlZCBhYm92ZSkgcGVyaW9kIGlz IG5vdCBnb29kIGVpdGhlci4NCiAgIEluIGVpdGhlciBjYXNlLCB0aGVyZSBpcyBubyBpbnRlcm9w ZXJhYmlsaXR5IGlzc3VlIC0gc28gdGhlIHRvcGljIGlzIG5vdCBkaXNjdXNzZWQgZnVydGhlci4u DQoNCg0KSG9wZSB0aGlzIGNsZWFycyB1cCwgYXQgbGVhc3QgdGhlIHRoaW5raW5nIGJlaGluZCBp dC4NClBsZWFzZSBkbyBwcm92aWRlIGd1aWRhbmNlLi4uDQoNCg0KVGhhbmtzLA0KSGltYW5zaHUN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxpYSBBdGxhcyBbbWFpbHRv OmFrYXRsYXNAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IDQ6MjIg UE0NClRvOiBUaGUgSUVTRw0KQ2M6IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLW1hYy13ZEBpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtbWFjLXdkLmFsbEBpZXRmLm9yZzsgcGFscy1j aGFpcnNAaWV0Zi5vcmc7IGFnbWFsaXNAZ21haWwuY29tOyBwYWxzQGlldGYub3JnDQpTdWJqZWN0 OiBBbGlhIEF0bGFzJyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLW1hYy13ZC0w MjogKHdpdGggRElTQ1VTUykNCg0KQWxpYSBBdGxhcyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLW1hYy13ZC0wMjog RGlzY3Vzcw0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBU byBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXBhbHMtbXBs cy10cC1tYWMtd2QvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpJIGV4cGVjdCB0aGF0IHRoaXMgaXMgYSB2ZXJ5IHNpbXBsZSBhbmQgcXVpY2sgRGlzY3Vz cyB0byBkZWFsIHdpdGguDQoNCjEpIEluIFNlYyA0LjEsIGl0IGZpcnN0IHNheXMgIlRoZSByZXRy YW5zbWlzc2lvbiBNVVNUIGJlDQogICBjZWFzZWQgYW55dGltZSB3aGVuIEFDSyBpcyByZWNlaXZl ZCBvciBhZnRlciB0aHJlZSByZXRyaWVzLiIgd2hpY2ggaXMgZmluZSBidXQgdGhlbiAtICJGb3Ig aW5zdGFuY2UsIDEgc2Vjb25kIA0KICAgcmV0cmFuc21pc3Npb24gd2l0aCB0aHJlZSByZXRyaWVz IGluIGFic2VuY2Ugb2YgQUNLIHJlc3BvbnNlIGlzIA0KICAgc3VnZ2VzdGVkIGluIHRoaXMgZG9j dW1lbnQuICBIb3dldmVyLCBpbmNyZW1lbnRhbCBiYWNrb2ZmIHdpdGggaGlnaGVyDQogICBudW1i ZXIgb2YgcmV0cmllcyBpcyBhbHNvIGZlYXNpYmxlIGFuZCBtYXkgYmUgd29ydGggY29uc2lkZXJh dGlvbiB0byANCiAgIGFkZHJlc3MgdGhlIHNjYWxlIGlzc3Vlcy4gIFRoaXMgZG9jdW1lbnQgZG9l cyBub3QgbWFuZGF0ZSBhIHN0cmljdCANCiAgIGd1aWRlbGluZSBzaW5jZSB0aGVyZSBhcmUgbm8g aW50ZXJvcGVyYWJpbGl0eSBpbXBsaWNhdGlvbnMuIg0KDQpDTEVBUkxZLCB1c2luZyBNVVNUIGlz IG1vcmUgdGhhbiBhIGdlbnRsZSBzdWdnZXN0aW9uIC0gYnV0IGlzIGV4YWN0bHkgbWFuZGF0aW5n IGEgc3RyaWN0IGd1aWRlbGluZS4NCg0KUGxlYXNlIGZpeCBlaXRoZXIgdGhlIE1VU1Qgb3IgdGhl IHJlbWFpbmluZyB0ZXh0Lg0KDQoNCg0KDQo= From nobody Thu Oct 22 15:26:47 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA011B2E53; Thu, 22 Oct 2015 15:26:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151022222644.20171.31884.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 15:26:44 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-ms-pw-protection-04.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 22:26:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services Working Group of the IETF. Title : S-PE Protection for MPLS and MPLS-TP Static Multi-Segment Pseudowires Authors : Andrew G. Malis Loa Andersson Huub van Helvoort Jongyoon Shin Lei Wang Alessandro D'Alessandro Filename : draft-ietf-pals-ms-pw-protection-04.txt Pages : 9 Date : 2015-10-22 Abstract: In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS- PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-ms-pw-protection-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-ms-pw-protection-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 23 00:46:34 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374961B2F21; Fri, 23 Oct 2015 00:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDaQKwMDv0EI; Fri, 23 Oct 2015 00:46:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1979F1B2F1C; Fri, 23 Oct 2015 00:46:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCX81196; Fri, 23 Oct 2015 07:46:27 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 23 Oct 2015 08:46:26 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Fri, 23 Oct 2015 15:46:17 +0800 From: "Dongjie (Jimmy)" To: Jari Arkko , Robert Sparks Thread-Topic: [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 Thread-Index: AQHRCFoBAjbu6kcumUySNbKvi0Guup5yhQ/wgACtoYCAA8J/gIABxbDg Date: Fri, 23 Oct 2015 07:46:16 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927743C1921@nkgeml512-mbx.china.huawei.com> References: <56216C90.4060606@nostrum.com> <76CD132C3ADEF848BD84D028D243C927743BD6AC@nkgeml512-mbx.china.huawei.com> <5625B071.6040303@nostrum.com> <09F4862E-884F-475F-BAC9-68CB31EE724D@piuha.net> In-Reply-To: <09F4862E-884F-475F-BAC9-68CB31EE724D@piuha.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-pals-redundancy-spe.all@ietf.org" , General Area Review Team , "pals@ietf.org" Subject: Re: [Pals] [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 07:46:31 -0000 Hi Jari,=20 Thanks a lot for your review and comments. As said in my reply to Robert, we will separate the specification and the e= xamples. Also we would try to improve its readability. Best regards, Jie > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, October 22, 2015 8:35 PM > To: Robert Sparks > Cc: Dongjie (Jimmy); General Area Review Team; pals@ietf.org; > draft-ietf-pals-redundancy-spe.all@ietf.org > Subject: Re: [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-= 02 >=20 > Robert, Jimmy, >=20 > Thanks for the review & discussion. >=20 > From my perspective some of the things that Robert raises are very valid > questions. The particular item that I'm perhaps most interested in is the= text in > Section 3.2, which seems like explaining what happens in an example, but = it also > uses normative language and keywords to say what various entities should = do. > Yet, the example is just one example. Is there a need to lift the keyword > statements out of this paragraph and generalise them to make sure that th= e > specification is about the general case and not about the example? Altern= atively, > maybe I misunderstood the purpose of the keyword statements. >=20 > (I also agree with Robert that the document is fairly hard to read. This = isn't the > first document in the IETF to be like that, and I didn't feel that this i= ssue is > discuss-worthy.) >=20 > Jari From nobody Fri Oct 23 02:50:30 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784D01B342B; Fri, 23 Oct 2015 02:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L_jvyFBJizi; Fri, 23 Oct 2015 02:50:26 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A841B342A; Fri, 23 Oct 2015 02:50:25 -0700 (PDT) Received: by wijp11 with SMTP id p11so69378046wij.0; Fri, 23 Oct 2015 02:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=JPSG3b8ffWqnOAwnye0jCrvRkAE0Ml+HThoMgwHyVvs=; b=Y1KUlieXDR+GCm75NO6w6Vr49Pw0iWqak4BUFlmbqviFKEa5zxdW0kmpoGa0xOD44x XH37TKJP59rTL20C4Kof932Kwlg0WDve3QswE/fkTYnMiVZYyh6FHreGFYv37WTMR68d jK5ZlX+1bCTZ3y+zw907cme5RodimwGbjookX6RFRdulcD+zWFi3lsA81Hgh10Ibz1TO +9L2KdDmAc4hOi+RvanLPR2449cBKQ/sGhpxNZ9I3Wso76qpXPC0OhZr4vUEZFm7n9v9 lRV4GlRjpIjPUZLML33kkcLbjz7tMdBkrnAUAtiN9zSgNpiCnaSyzDz2nt2rtlryomZD YnmQ== X-Received: by 10.194.62.15 with SMTP id u15mr3915741wjr.18.1445593824444; Fri, 23 Oct 2015 02:50:24 -0700 (PDT) Received: from [10.55.98.188] ([173.38.220.33]) by smtp.gmail.com with ESMTPSA id z2sm2368017wij.1.2015.10.23.02.50.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2015 02:50:23 -0700 (PDT) To: "Shah, Himanshu" , Alia Atlas , The IESG References: <20151019202150.5112.33326.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182B9C378111@ONWVEXCHMB04.ciena.com> From: Stewart Bryant Message-ID: <562A02DD.10209@gmail.com> Date: Fri, 23 Oct 2015 10:50:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <40746B2300A8FC4AB04EE722A593182B9C378111@ONWVEXCHMB04.ciena.com> Content-Type: multipart/alternative; boundary="------------040209030604030305030703" Archived-At: Cc: "pals-chairs@ietf.org" , "draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org" , "agmalis@gmail.com" , "draft-ietf-pals-mpls-tp-mac-wd@ietf.org" , "pals@ietf.org" Subject: Re: [Pals] Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 09:50:28 -0000 This is a multi-part message in MIME format. --------------040209030604030305030703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In part Alia's concern is a Lynn Truss problem https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves Let's see if we can report this to cover the intent of the authors whilst addressing Alia's concern, and at the same time making sure we don't introduce a congestion concern. Original text: The retransmission MUST be ceased anytime when ACK is received or after three retries. This avoids unended retransmissions in the absence of acknowledgements. Since retransmission time interval and the maximum number of retries is local configuration of the sender node, it is up to the implementers to pick a discipline. For instance, 1 second retransmission with three retries in absence of ACK response is suggested in this document. However, incremental backoff with higher number of retries is also feasible and may be worth consideration to address the scale issues. This document does not mandate a strict guideline since there are no interoperability implications. However, implementers must consider the decaying value of delayed MAC withdraw signaling against possible relearning due to bidirectional traffic or MAC age timeout. How about we say: The retransmission MUST be ceased when an ACK is received. In order to avoid continuous retransmissions in the absence of acknowledgements a method of suppressing retransmission in the absence of an acknowledgement MUST be implemented. A simple and well used approach is to cease retransmission after a small number of transmissions. A one second retransmission with two retries in absence of an ACK response is RECOMMENDED. However both the interval and the number of retries are a local matter which present no interworking issues and thus the operator MAY configure different values. Alternatively an increasing backoff delay with a larger number of retries MAY be implemented to improve scaling issues. Whilst that are no interworking issues with any of these methods the implementer must be mindful of not introducing network congestion and must take into account the decaying value of delayed MAC withdraw signaling against possible relearning due to bidirectional traffic or MAC age timeout. - Stewart --------------040209030604030305030703 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
In part Alia's concern is a Lynn Truss problem 

https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves


Let's see if we can report this to cover the intent of the authors
whilst addressing Alia's concern, and at the same time making
sure we don't introduce a congestion concern.

Original text:

   The retransmission MUST be
   ceased anytime when ACK is received or after three retries.  This
   avoids unended retransmissions in the absence of acknowledgements.
   Since retransmission time interval and the maximum number of retries
   is local configuration of the sender node, it is up to the 
   implementers to pick a discipline.  For instance, 1 second 
   retransmission with three retries in absence of ACK response is 
   suggested in this document.  However, incremental backoff with higher
   number of retries is also feasible and may be worth consideration to 
   address the scale issues.  This document does not mandate a strict 
   guideline since there are no interoperability implications.  However,
   implementers must consider the decaying value of delayed MAC withdraw
   signaling against possible relearning due to bidirectional traffic or
   MAC age timeout.


How about we say:


   The retransmission MUST be ceased when an ACK is received. In order
   to avoid continuous retransmissions in the absence of acknowledgements
   a method of suppressing retransmission in the absence of an acknowledgement
   MUST be implemented. A simple and well used approach is to cease 
   retransmission after a small number of transmissions. A one second 
   retransmission with two retries in absence of an ACK response is 
   RECOMMENDED. However both the interval and the number of retries are
   a local matter which present no interworking issues and thus the operator
   MAY configure different values. Alternatively an increasing backoff delay  
   with a larger number of retries MAY be implemented to 
   improve scaling issues. Whilst that are no interworking issues with
   any of these methods the implementer must be mindful of not introducing 
   network congestion and must take into account the decaying value of 
   delayed MAC withdraw signaling against possible relearning due to 
   bidirectional traffic or MAC age timeout.

- Stewart
--------------040209030604030305030703-- From nobody Fri Oct 23 11:29:40 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4951A8968; Fri, 23 Oct 2015 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgl7QCFO9xox; Fri, 23 Oct 2015 11:29:34 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DC51A8967; Fri, 23 Oct 2015 11:29:34 -0700 (PDT) Received: by obcqt19 with SMTP id qt19so100043078obc.3; Fri, 23 Oct 2015 11:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QXQ3AjBP4bD2izv6ksZ6o9e8KO2BAIkmOnIsczXOhgs=; b=SqAobJfDOLmSoR8ZCAII2XEtkjq6gt4oFbobJsBns1YeaBmrWZ80kpYF7Qx51bOERW ExkICcYfDm04+LGZ0ghYz3ruuFxPgGxajHhGb8DJfcHrBzhkA6mDTh3gZ04xEzLpQGZx DY00EZM02YGzkjNW8I5dTZsXHeuGLvFiQACbFhCiDWZX6syiLAFPZ/Wp06tpaahOARYR pE+FYU96QIN9sLoUyp3uwDFcK16wB8MXh9wUNO9GBqBW29l/I9FxWgagyM/9Bi7WGh/L GGvEbp4SAi2R7qlGndDfzImtaw/XkPPdVRgY2839pLvsbaQz9hqf1Qgkwhrom6knXmsC n0yw== MIME-Version: 1.0 X-Received: by 10.60.173.42 with SMTP id bh10mr12233862oec.58.1445624973455; Fri, 23 Oct 2015 11:29:33 -0700 (PDT) Received: by 10.60.6.132 with HTTP; Fri, 23 Oct 2015 11:29:33 -0700 (PDT) In-Reply-To: <562A02DD.10209@gmail.com> References: <20151019202150.5112.33326.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182B9C378111@ONWVEXCHMB04.ciena.com> <562A02DD.10209@gmail.com> Date: Fri, 23 Oct 2015 14:29:33 -0400 Message-ID: From: Alia Atlas To: Stewart Bryant Content-Type: multipart/alternative; boundary=047d7bd6bf1c0579f50522c9cb51 Archived-At: Cc: "agmalis@gmail.com" , "Shah, Himanshu" , "draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org" , "pals-chairs@ietf.org" , The IESG , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-mac-wd@ietf.org" Subject: Re: [Pals] Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 18:29:36 -0000 --047d7bd6bf1c0579f50522c9cb51 Content-Type: text/plain; charset=UTF-8 Stewart, Your text is great. Thanks, Alia On Fri, Oct 23, 2015 at 5:50 AM, Stewart Bryant wrote: > In part Alia's concern is a Lynn Truss problem > https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves > > > Let's see if we can report this to cover the intent of the authors > whilst addressing Alia's concern, and at the same time making > sure we don't introduce a congestion concern. > > Original text: > > The retransmission MUST be > ceased anytime when ACK is received or after three retries. This > avoids unended retransmissions in the absence of acknowledgements. > Since retransmission time interval and the maximum number of retries > is local configuration of the sender node, it is up to the > implementers to pick a discipline. For instance, 1 second > retransmission with three retries in absence of ACK response is > suggested in this document. However, incremental backoff with higher > number of retries is also feasible and may be worth consideration to > address the scale issues. This document does not mandate a strict > guideline since there are no interoperability implications. However, > implementers must consider the decaying value of delayed MAC withdraw > signaling against possible relearning due to bidirectional traffic or > MAC age timeout. > > > How about we say: > > > The retransmission MUST be ceased when an ACK is received. In order > to avoid continuous retransmissions in the absence of acknowledgements > a method of suppressing retransmission in the absence of an acknowledgement > MUST be implemented. A simple and well used approach is to cease > retransmission after a small number of transmissions. A one second > retransmission with two retries in absence of an ACK response is > RECOMMENDED. However both the interval and the number of retries are > a local matter which present no interworking issues and thus the operator > MAY configure different values. Alternatively an increasing backoff delay > with a larger number of retries MAY be implemented to > improve scaling issues. Whilst that are no interworking issues with > any of these methods the implementer must be mindful of not introducing > network congestion and must take into account the decaying value of > delayed MAC withdraw signaling against possible relearning due to > bidirectional traffic or MAC age timeout. > > - Stewart > > --047d7bd6bf1c0579f50522c9cb51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart,

Your text is great.=C2=A0

Thanks,
Alia

On Fri, Oct 23, 2015 at 5:50 AM, Stew= art Bryant <stewart.bryant@gmail.com> wrote:
=20 =20 =20
=20 
In part Alia's concern is a Lynn Truss problem=20

https://en.wikipedia.org/wiki/Eats,_Shoots_%26_Leaves


Let's see if we can report this to cover the intent of the authors
whilst addressing Alia's concern, and at the same time making
sure we don't introduce a congestion concern.

Original text:

   The retransmission MUST be
   ceased anytime when ACK is received or after three retries.  This
   avoids unended retransmissions in the absence of acknowledgements.
   Since retransmission time interval and the maximum number of retries
   is local configuration of the sender node, it is up to the=20
   implementers to pick a discipline.  For instance, 1 second=20
   retransmission with three retries in absence of ACK response is=20
   suggested in this document.  However, incremental backoff with higher
   number of retries is also feasible and may be worth consideration to=20
   address the scale issues.  This document does not mandate a strict=20
   guideline since there are no interoperability implications.  However,
   implementers must consider the decaying value of delayed MAC withdraw
   signaling against possible relearning due to bidirectional traffic or
   MAC age timeout.


How about we say:


   The retransmission MUST be ceased when an ACK is received. In order
   to avoid continuous retransmissions in the absence of acknowledgements
   a method of suppressing retransmission in the absence of an acknowledgem=
ent
   MUST be implemented. A simple and well used approach is to cease=20
   retransmission after a small number of transmissions. A one second=20
   retransmission with two retries in absence of an ACK response is=20
   RECOMMENDED. However both the interval and the number of retries are
   a local matter which present no interworking issues and thus the operato=
r
   MAY configure different values. Alternatively an increasing backoff dela=
y =20
   with a larger number of retries MAY be implemented to=20
   improve scaling issues. Whilst that are no interworking issues with
   any of these methods the implementer must be mindful of not introducing=
=20
   network congestion and must take into account the decaying value of=20
   delayed MAC withdraw signaling against possible relearning due to=20
   bidirectional traffic or MAC age timeout.

- Stewart

--047d7bd6bf1c0579f50522c9cb51-- From nobody Fri Oct 23 11:32:17 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9B01A8974; Fri, 23 Oct 2015 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBND6qLhh9XU; Fri, 23 Oct 2015 11:32:14 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A3C1A8935; Fri, 23 Oct 2015 11:32:14 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9NIW9om001515; Fri, 23 Oct 2015 14:32:11 -0400 Received: from vawvcgsie2k1302.ciena.com (lin1-118-36-36.ciena.com [63.118.36.36]) by mx0b-00103a01.pphosted.com with ESMTP id 1xqhychqgx-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Oct 2015 14:32:11 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 23 Oct 2015 14:32:10 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 23 Oct 2015 14:32:10 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Fri, 23 Oct 2015 14:32:10 -0400 From: "Shah, Himanshu" To: Alia Atlas , Stewart Bryant Date: Fri, 23 Oct 2015 14:32:09 -0400 Thread-Topic: Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) Thread-Index: AdENwNPqD4xFhCLTTWWrlTfmAXEfxAAAEBmw Message-ID: <40746B2300A8FC4AB04EE722A593182B9C3784A6@ONWVEXCHMB04.ciena.com> References: <20151019202150.5112.33326.idtracker@ietfa.amsl.com> <40746B2300A8FC4AB04EE722A593182B9C378111@ONWVEXCHMB04.ciena.com> <562A02DD.10209@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-21898.002 x-tm-as-result: No--47.691900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182B9C3784A6ONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-23_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510230308 Archived-At: Cc: "agmalis@gmail.com" , "draft-ietf-pals-mpls-tp-mac-wd.all@ietf.org" , "pals-chairs@ietf.org" , The IESG , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-mac-wd@ietf.org" Subject: Re: [Pals] Alia Atlas' Discuss on draft-ietf-pals-mpls-tp-mac-wd-02: (with DISCUSS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 18:32:16 -0000 --_000_40746B2300A8FC4AB04EE722A593182B9C3784A6ONWVEXCHMB04cie_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSBhcyB3ZWxsLg0KSSB3aWxsIGluY29ycG9yYXRlIHRoZSBjaGFuZ2VzLg0KDQpUaGFu a3MsDQpIaW1hbnNodQ0KDQpGcm9tOiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5j b21dDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjMsIDIwMTUgMjozMCBQTQ0KVG86IFN0ZXdhcnQg QnJ5YW50DQpDYzogU2hhaCwgSGltYW5zaHU7IFRoZSBJRVNHOyBkcmFmdC1pZXRmLXBhbHMtbXBs cy10cC1tYWMtd2RAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLW1hYy13ZC5hbGxA aWV0Zi5vcmc7IHBhbHMtY2hhaXJzQGlldGYub3JnOyBhZ21hbGlzQGdtYWlsLmNvbTsgcGFsc0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IEFsaWEgQXRsYXMnIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1w YWxzLW1wbHMtdHAtbWFjLXdkLTAyOiAod2l0aCBESVNDVVNTKQ0KDQpTdGV3YXJ0LA0KDQpZb3Vy IHRleHQgaXMgZ3JlYXQuDQoNClRoYW5rcywNCkFsaWENCg0KT24gRnJpLCBPY3QgMjMsIDIwMTUg YXQgNTo1MCBBTSwgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTxtYWls dG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkluIHBhcnQgQWxpYSdzIGNv bmNlcm4gaXMgYSBMeW5uIFRydXNzIHByb2JsZW0NCg0KDQoNCmh0dHBzOi8vZW4ud2lraXBlZGlh Lm9yZy93aWtpL0VhdHMsX1Nob290c18lMjZfTGVhdmVzDQoNCg0KDQoNCg0KTGV0J3Mgc2VlIGlm IHdlIGNhbiByZXBvcnQgdGhpcyB0byBjb3ZlciB0aGUgaW50ZW50IG9mIHRoZSBhdXRob3JzDQoN CndoaWxzdCBhZGRyZXNzaW5nIEFsaWEncyBjb25jZXJuLCBhbmQgYXQgdGhlIHNhbWUgdGltZSBt YWtpbmcNCg0Kc3VyZSB3ZSBkb24ndCBpbnRyb2R1Y2UgYSBjb25nZXN0aW9uIGNvbmNlcm4uDQoN Cg0KDQpPcmlnaW5hbCB0ZXh0Og0KDQoNCg0KICAgVGhlIHJldHJhbnNtaXNzaW9uIE1VU1QgYmUN Cg0KICAgY2Vhc2VkIGFueXRpbWUgd2hlbiBBQ0sgaXMgcmVjZWl2ZWQgb3IgYWZ0ZXIgdGhyZWUg cmV0cmllcy4gIFRoaXMNCg0KICAgYXZvaWRzIHVuZW5kZWQgcmV0cmFuc21pc3Npb25zIGluIHRo ZSBhYnNlbmNlIG9mIGFja25vd2xlZGdlbWVudHMuDQoNCiAgIFNpbmNlIHJldHJhbnNtaXNzaW9u IHRpbWUgaW50ZXJ2YWwgYW5kIHRoZSBtYXhpbXVtIG51bWJlciBvZiByZXRyaWVzDQoNCiAgIGlz IGxvY2FsIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHNlbmRlciBub2RlLCBpdCBpcyB1cCB0byB0aGUN Cg0KICAgaW1wbGVtZW50ZXJzIHRvIHBpY2sgYSBkaXNjaXBsaW5lLiAgRm9yIGluc3RhbmNlLCAx IHNlY29uZA0KDQogICByZXRyYW5zbWlzc2lvbiB3aXRoIHRocmVlIHJldHJpZXMgaW4gYWJzZW5j ZSBvZiBBQ0sgcmVzcG9uc2UgaXMNCg0KICAgc3VnZ2VzdGVkIGluIHRoaXMgZG9jdW1lbnQuICBI b3dldmVyLCBpbmNyZW1lbnRhbCBiYWNrb2ZmIHdpdGggaGlnaGVyDQoNCiAgIG51bWJlciBvZiBy ZXRyaWVzIGlzIGFsc28gZmVhc2libGUgYW5kIG1heSBiZSB3b3J0aCBjb25zaWRlcmF0aW9uIHRv DQoNCiAgIGFkZHJlc3MgdGhlIHNjYWxlIGlzc3Vlcy4gIFRoaXMgZG9jdW1lbnQgZG9lcyBub3Qg bWFuZGF0ZSBhIHN0cmljdA0KDQogICBndWlkZWxpbmUgc2luY2UgdGhlcmUgYXJlIG5vIGludGVy b3BlcmFiaWxpdHkgaW1wbGljYXRpb25zLiAgSG93ZXZlciwNCg0KICAgaW1wbGVtZW50ZXJzIG11 c3QgY29uc2lkZXIgdGhlIGRlY2F5aW5nIHZhbHVlIG9mIGRlbGF5ZWQgTUFDIHdpdGhkcmF3DQoN CiAgIHNpZ25hbGluZyBhZ2FpbnN0IHBvc3NpYmxlIHJlbGVhcm5pbmcgZHVlIHRvIGJpZGlyZWN0 aW9uYWwgdHJhZmZpYyBvcg0KDQogICBNQUMgYWdlIHRpbWVvdXQuDQoNCg0KDQoNCg0KSG93IGFi b3V0IHdlIHNheToNCg0KDQoNCg0KDQogICBUaGUgcmV0cmFuc21pc3Npb24gTVVTVCBiZSBjZWFz ZWQgd2hlbiBhbiBBQ0sgaXMgcmVjZWl2ZWQuIEluIG9yZGVyDQoNCiAgIHRvIGF2b2lkIGNvbnRp bnVvdXMgcmV0cmFuc21pc3Npb25zIGluIHRoZSBhYnNlbmNlIG9mIGFja25vd2xlZGdlbWVudHMN Cg0KICAgYSBtZXRob2Qgb2Ygc3VwcHJlc3NpbmcgcmV0cmFuc21pc3Npb24gaW4gdGhlIGFic2Vu Y2Ugb2YgYW4gYWNrbm93bGVkZ2VtZW50DQoNCiAgIE1VU1QgYmUgaW1wbGVtZW50ZWQuIEEgc2lt cGxlIGFuZCB3ZWxsIHVzZWQgYXBwcm9hY2ggaXMgdG8gY2Vhc2UNCg0KICAgcmV0cmFuc21pc3Np b24gYWZ0ZXIgYSBzbWFsbCBudW1iZXIgb2YgdHJhbnNtaXNzaW9ucy4gQSBvbmUgc2Vjb25kDQoN CiAgIHJldHJhbnNtaXNzaW9uIHdpdGggdHdvIHJldHJpZXMgaW4gYWJzZW5jZSBvZiBhbiBBQ0sg cmVzcG9uc2UgaXMNCg0KICAgUkVDT01NRU5ERUQuIEhvd2V2ZXIgYm90aCB0aGUgaW50ZXJ2YWwg YW5kIHRoZSBudW1iZXIgb2YgcmV0cmllcyBhcmUNCg0KICAgYSBsb2NhbCBtYXR0ZXIgd2hpY2gg cHJlc2VudCBubyBpbnRlcndvcmtpbmcgaXNzdWVzIGFuZCB0aHVzIHRoZSBvcGVyYXRvcg0KDQog ICBNQVkgY29uZmlndXJlIGRpZmZlcmVudCB2YWx1ZXMuIEFsdGVybmF0aXZlbHkgYW4gaW5jcmVh c2luZyBiYWNrb2ZmIGRlbGF5DQoNCiAgIHdpdGggYSBsYXJnZXIgbnVtYmVyIG9mIHJldHJpZXMg TUFZIGJlIGltcGxlbWVudGVkIHRvDQoNCiAgIGltcHJvdmUgc2NhbGluZyBpc3N1ZXMuIFdoaWxz dCB0aGF0IGFyZSBubyBpbnRlcndvcmtpbmcgaXNzdWVzIHdpdGgNCg0KICAgYW55IG9mIHRoZXNl IG1ldGhvZHMgdGhlIGltcGxlbWVudGVyIG11c3QgYmUgbWluZGZ1bCBvZiBub3QgaW50cm9kdWNp bmcNCg0KICAgbmV0d29yayBjb25nZXN0aW9uIGFuZCBtdXN0IHRha2UgaW50byBhY2NvdW50IHRo ZSBkZWNheWluZyB2YWx1ZSBvZg0KDQogICBkZWxheWVkIE1BQyB3aXRoZHJhdyBzaWduYWxpbmcg YWdhaW5zdCBwb3NzaWJsZSByZWxlYXJuaW5nIGR1ZSB0bw0KDQogICBiaWRpcmVjdGlvbmFsIHRy YWZmaWMgb3IgTUFDIGFnZSB0aW1lb3V0Lg0KDQoNCg0KLSBTdGV3YXJ0DQoNCg== --_000_40746B2300A8FC4AB04EE722A593182B9C3784A6ONWVEXCHMB04cie_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnN0YW50aWE7 DQoJcGFub3NlLTE6MiAzIDYgMiA1IDMgNiAzIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDb25zdGFudGlhIiwic2VyaWYiOw0KCWNvbG9yOmJsdWU7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6aXRhbGljO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xh c3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ29uc3RhbnRpYSIsInNlcmlmIjtjb2xvcjpibHVlJz5J IGFncmVlIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvbnN0YW50 aWEiLCJzZXJpZiI7Y29sb3I6Ymx1ZSc+SSB3aWxsIGluY29ycG9yYXRlIHRoZSBjaGFuZ2VzLjxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb25zdGFudGlhIiwic2VyaWYiO2NvbG9y OmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsdWUnPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjpibHVlJz5IaW1hbnNodTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD b25zdGFudGlhIiwic2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWlsLmNvbV0gPGJyPjxiPlNlbnQ6PC9i PiBGcmlkYXksIE9jdG9iZXIgMjMsIDIwMTUgMjozMCBQTTxicj48Yj5Ubzo8L2I+IFN0ZXdhcnQg QnJ5YW50PGJyPjxiPkNjOjwvYj4gU2hhaCwgSGltYW5zaHU7IFRoZSBJRVNHOyBkcmFmdC1pZXRm LXBhbHMtbXBscy10cC1tYWMtd2RAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLW1h Yy13ZC5hbGxAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQGlldGYub3JnOyBhZ21hbGlzQGdtYWlsLmNv bTsgcGFsc0BpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IEFsaWEgQXRsYXMnIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtbWFjLXdkLTAyOiAod2l0aCBESVNDVVNTKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U3Rld2FydCw8bzpwPjwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5Zb3VyIHRleHQgaXMgZ3JlYXQuJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPkFsaWE8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5P biBGcmksIE9jdCAyMywgMjAxNSBhdCA1OjUwIEFNLCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PHBy ZT5JbiBwYXJ0IEFsaWEncyBjb25jZXJuIGlzIGEgTHlubiBUcnVzcyBwcm9ibGVtIDxvOnA+PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRWF0cyxfU2hvb3RzXyUyNl9MZWF2ZXMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9FYXRzLF9TaG9vdHNfJTI2X0xl YXZlczwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5MZXQncyBzZWUgaWYgd2UgY2FuIHJlcG9ydCB0 aGlzIHRvIGNvdmVyIHRoZSBpbnRlbnQgb2YgdGhlIGF1dGhvcnM8bzpwPjwvbzpwPjwvcHJlPjxw cmU+d2hpbHN0IGFkZHJlc3NpbmcgQWxpYSdzIGNvbmNlcm4sIGFuZCBhdCB0aGUgc2FtZSB0aW1l IG1ha2luZzxvOnA+PC9vOnA+PC9wcmU+PHByZT5zdXJlIHdlIGRvbid0IGludHJvZHVjZSBhIGNv bmdlc3Rpb24gY29uY2Vybi48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT48cHJlPk9yaWdpbmFsIHRleHQ6PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+PHByZT7CoMKgIFRoZSByZXRyYW5zbWlzc2lvbiBNVVNUIGJlPG86cD48L286 cD48L3ByZT48cHJlPsKgwqAgY2Vhc2VkIGFueXRpbWUgd2hlbiBBQ0sgaXMgcmVjZWl2ZWQgb3Ig YWZ0ZXIgdGhyZWUgcmV0cmllcy7CoCBUaGlzPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgYXZv aWRzIHVuZW5kZWQgcmV0cmFuc21pc3Npb25zIGluIHRoZSBhYnNlbmNlIG9mIGFja25vd2xlZGdl bWVudHMuPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgU2luY2UgcmV0cmFuc21pc3Npb24gdGlt ZSBpbnRlcnZhbCBhbmQgdGhlIG1heGltdW0gbnVtYmVyIG9mIHJldHJpZXM8bzpwPjwvbzpwPjwv cHJlPjxwcmU+wqDCoCBpcyBsb2NhbCBjb25maWd1cmF0aW9uIG9mIHRoZSBzZW5kZXIgbm9kZSwg aXQgaXMgdXAgdG8gdGhlIDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqBpbXBsZW1lbnRlcnMg dG8gcGljayBhIGRpc2NpcGxpbmUuwqAgRm9yIGluc3RhbmNlLCAxIHNlY29uZCA8bzpwPjwvbzpw PjwvcHJlPjxwcmU+wqDCoMKgcmV0cmFuc21pc3Npb24gd2l0aCB0aHJlZSByZXRyaWVzIGluIGFi c2VuY2Ugb2YgQUNLIHJlc3BvbnNlIGlzIDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqBzdWdn ZXN0ZWQgaW4gdGhpcyBkb2N1bWVudC7CoCBIb3dldmVyLCBpbmNyZW1lbnRhbCBiYWNrb2ZmIHdp dGggaGlnaGVyPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgbnVtYmVyIG9mIHJldHJpZXMgaXMg YWxzbyBmZWFzaWJsZSBhbmQgbWF5IGJlIHdvcnRoIGNvbnNpZGVyYXRpb24gdG8gPG86cD48L286 cD48L3ByZT48cHJlPsKgwqDCoGFkZHJlc3MgdGhlIHNjYWxlIGlzc3Vlcy7CoCBUaGlzIGRvY3Vt ZW50IGRvZXMgbm90IG1hbmRhdGUgYSBzdHJpY3QgPG86cD48L286cD48L3ByZT48cHJlPsKgwqDC oGd1aWRlbGluZSBzaW5jZSB0aGVyZSBhcmUgbm8gaW50ZXJvcGVyYWJpbGl0eSBpbXBsaWNhdGlv bnMuwqAgSG93ZXZlciw8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBpbXBsZW1lbnRlcnMgbXVz dCBjb25zaWRlciB0aGUgZGVjYXlpbmcgdmFsdWUgb2YgZGVsYXllZCBNQUMgd2l0aGRyYXc8bzpw PjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBzaWduYWxpbmcgYWdhaW5zdCBwb3NzaWJsZSByZWxlYXJu aW5nIGR1ZSB0byBiaWRpcmVjdGlvbmFsIHRyYWZmaWMgb3I8bzpwPjwvbzpwPjwvcHJlPjxwcmU+ wqDCoCBNQUMgYWdlIHRpbWVvdXQuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+SG93IGFib3V0IHdlIHNh eTo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT7CoMKgIFRoZSByZXRyYW5zbWlzc2lvbiBNVVNUIGJlIGNl YXNlZCB3aGVuIGFuIEFDSyBpcyByZWNlaXZlZC4gSW4gb3JkZXI8bzpwPjwvbzpwPjwvcHJlPjxw cmU+wqDCoCB0byBhdm9pZCBjb250aW51b3VzIHJldHJhbnNtaXNzaW9ucyBpbiB0aGUgYWJzZW5j ZSBvZiBhY2tub3dsZWRnZW1lbnRzPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgYSBtZXRob2Qg b2Ygc3VwcHJlc3NpbmcgcmV0cmFuc21pc3Npb24gaW4gdGhlIGFic2VuY2Ugb2YgYW4gYWNrbm93 bGVkZ2VtZW50PG86cD48L286cD48L3ByZT48cHJlPsKgwqAgTVVTVCBiZSBpbXBsZW1lbnRlZC4g QSBzaW1wbGUgYW5kIHdlbGwgdXNlZCBhcHByb2FjaCBpcyB0byBjZWFzZSA8bzpwPjwvbzpwPjwv cHJlPjxwcmU+wqDCoMKgcmV0cmFuc21pc3Npb24gYWZ0ZXIgYSBzbWFsbCBudW1iZXIgb2YgdHJh bnNtaXNzaW9ucy4gQSBvbmUgc2Vjb25kIDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqByZXRy YW5zbWlzc2lvbiB3aXRoIHR3byByZXRyaWVzIGluIGFic2VuY2Ugb2YgYW4gQUNLIHJlc3BvbnNl IGlzIDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqBSRUNPTU1FTkRFRC4gSG93ZXZlciBib3Ro IHRoZSBpbnRlcnZhbCBhbmQgdGhlIG51bWJlciBvZiByZXRyaWVzIGFyZTxvOnA+PC9vOnA+PC9w cmU+PHByZT7CoMKgIGEgbG9jYWwgbWF0dGVyIHdoaWNoIHByZXNlbnQgbm8gaW50ZXJ3b3JraW5n IGlzc3VlcyBhbmQgdGh1cyB0aGUgb3BlcmF0b3I8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBN QVkgY29uZmlndXJlIGRpZmZlcmVudCB2YWx1ZXMuIEFsdGVybmF0aXZlbHkgYW4gaW5jcmVhc2lu ZyBiYWNrb2ZmIGRlbGF5wqAgPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoHdpdGggYSBsYXJn ZXIgbnVtYmVyIG9mIHJldHJpZXMgTUFZIGJlIGltcGxlbWVudGVkIHRvIDxvOnA+PC9vOnA+PC9w cmU+PHByZT7CoMKgwqBpbXByb3ZlIHNjYWxpbmcgaXNzdWVzLiBXaGlsc3QgdGhhdCBhcmUgbm8g aW50ZXJ3b3JraW5nIGlzc3VlcyB3aXRoPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgYW55IG9m IHRoZXNlIG1ldGhvZHMgdGhlIGltcGxlbWVudGVyIG11c3QgYmUgbWluZGZ1bCBvZiBub3QgaW50 cm9kdWNpbmcgPG86cD48L286cD48L3ByZT48cHJlPsKgwqDCoG5ldHdvcmsgY29uZ2VzdGlvbiBh bmQgbXVzdCB0YWtlIGludG8gYWNjb3VudCB0aGUgZGVjYXlpbmcgdmFsdWUgb2YgPG86cD48L286 cD48L3ByZT48cHJlPsKgwqDCoGRlbGF5ZWQgTUFDIHdpdGhkcmF3IHNpZ25hbGluZyBhZ2FpbnN0 IHBvc3NpYmxlIHJlbGVhcm5pbmcgZHVlIHRvIDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgwqBi aWRpcmVjdGlvbmFsIHRyYWZmaWMgb3IgTUFDIGFnZSB0aW1lb3V0LjxvOnA+PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+LSBTdGV3YXJ0PG86cD48L286cD48L3By ZT48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_40746B2300A8FC4AB04EE722A593182B9C3784A6ONWVEXCHMB04cie_-- From nobody Sat Oct 24 09:29:01 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52C51A1A58 for ; Sat, 24 Oct 2015 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqBlKPH0OaFj for ; Sat, 24 Oct 2015 09:28:57 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4179B1A1A4B for ; Sat, 24 Oct 2015 09:28:57 -0700 (PDT) Received: by wicll6 with SMTP id ll6so65634687wic.1 for ; Sat, 24 Oct 2015 09:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=3fhl/odhfDVAOEoXaWKg7OIxpFdO4VTIxeJaHt9igzw=; b=nfrCzcaApACvaFLt80C5777h8jfIc2gh7vO7h3637Gmlufznt4dgu8huDghmPUNi9v qZ8XpD9W8BQITJwz3qmhWbF0N1VZbYQf+kiUhFnv/1Ke+1tAAu35zuA+Rln3Wyt8rkpo a/aYQ+Ybw4NoI0+9Fcv6J47/3JfHc53lkbleDdW7T7wTX41VjNxew+SbhVjynsbysOOg zLUPaGxk6tHWhHNT9AJPz9Jmz2xfDFjKFz97tFKX8Eoh0GTQsYwaN3U8dFuF845mW0ke 5jZPNdnDhnD7HGPcMJV10esUopguJc48BOOjm4m6+GfAUz11T8m7DPzb/ybZps8r2yLE yqNQ== X-Received: by 10.180.91.7 with SMTP id ca7mr11329827wib.12.1445704135829; Sat, 24 Oct 2015 09:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.9.212 with HTTP; Sat, 24 Oct 2015 09:28:36 -0700 (PDT) From: "Andrew G. Malis" Date: Sat, 24 Oct 2015 12:28:36 -0400 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7e10776ce30522dc3908 Archived-At: Cc: David Sinicrope , Stewart Bryant Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama (and update on WG drafts) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 16:28:59 -0000 --f46d043c7e10776ce30522dc3908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, As David noted below, we have a draft PALS agenda, see below for the link. There=E2=80=99s still plenty of room in the schedule, so if you would like = any time on the agenda, see the instructions below for requesting a slot. If you do have a slot, please be sure to get your slides to Dave by October 31 so that he can get them uploaded to the meetings material page prior to the meeting. Also, if you have a WG draft in progress and won=E2=80=99t be making a presentation, please send me a short update on where it stands that I can include in the WG status slides. Thanks much, Andy ---------- Forwarded message ---------- From: David Sinicrope Date: Thu, Oct 22, 2015 at 5:04 PM Subject: Re: [Pals] PALS IETF 94 Slot Requests - Yokohama To: "pals@ietf.org" Hi All, The PALS agenda is posted at the link below. https://www.ietf.org/proceedings/94/agenda/agenda-94-pals If you requested a slot and I haven=E2=80=99t allocated one, my apologies, = please complete the form below and send it in reply to this email. Those that have slots allocated, please send me your slides as soon as you complete them. *I will need your slides no later than Saturday 31 October 2015 23:59:59 Yokohama time.* If I don=E2=80=99t have your slides by that time, you risk losing your slot= . Thanks! Dave *From: *Pals on behalf of David Sinicrope < david.sinicrope@ericsson.com> *Date: *Friday, October 2, 2015 at 2:51 PM *To: *"pals@ietf.org" *Subject: *[Pals] PALS IETF 94 Slot Requests - Yokohama Hi All, It's that time again. If you need a presentation slot for the IETF 94 PALS session, please *reply to this email *(subject intact) completing the form below. *Please *use this form and *please* reply to this email with the subject intact. (Not doing so probably means your request will not trigger the filter I use to identify PALS slot requests and be lost in my email, never to be found. :-) Form: 1. topic (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker =E2=80=93 you only need to provide the = file name to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/): 3. brief statement of objectives and issues to be discussed and resolved via the presentation during the meeting (e.g., need to address security issues and get direction from the WG): 4. requested duration (norm/default is 10 min): 5. speaker Given-name FAMILY-NAME (e.g., Dave SINICROPE): Thanks! Dave --f46d043c7e10776ce30522dc3908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

As David noted below, w= e have a draft PALS agenda, see below for the link. There=E2=80=99s still p= lenty of room in the schedule, so if you would like any time on the agenda,= see the instructions below for requesting a slot.=C2=A0

If you do have a slot, please be sure to get your slides to Dave by = October 31 so that he can get them uploaded to the meetings material page p= rior to the meeting.

Also, if you have a WG draft = in progress and won=E2=80=99t be making a presentation, please send me a sh= ort update on where it stands that I can include in the WG status slides.

Thanks much,
Andy

---------- Forwarded message ----------
From: David Sinicrope <david.sinicrope@ericsson.com= >
Date: Thu, Oct 22, 2015 at 5:04 PM
Subject: Re: [Pals] PA= LS IETF 94 Slot Requests - Yokohama
To: "pals@ietf.org" <pals@ie= tf.org>


Hi All,


The PALS agenda is posted at the link belo= w.

=C2=A0

If you= requested a slot and I haven=E2=80=99t allocated one, my apologies, please= complete the form below and send it in reply to this email.<= /font>

=C2=A0

Those = that have slots allocated, please send me your slides as soon as you comple= te them.

I w= ill need your slides no later than=C2=A0Saturday 31 October 2015 23:59:5= 9 Yokohama time.

=C2=A0

If I d= on=E2=80=99t have your slides by that time, you risk losing your slot.

Thanks= !

Dave


From: Pa= ls <pals-boun= ces@ietf.org> on behalf of David Sinicrope <david.sinicrope@ericsson.com>

Date: Friday, October 2, 2015 at 2:51 PM
To: "pals@ie= tf.org" <pal= s@ietf.org>
Subject: [Pals] PALS IETF 94 Slot Requests - Yokohama<= /span>

=C2=A0

Hi All,

It's that time again= .=C2=A0

If you need a presentati= on slot for the IETF 94 PALS session, please=C2=A0reply to this email=C2= =A0(subject intact) completing the form below. =C2=A0=C2=A0

Please=C2=A0use this form and=C2=A0please=C2=A0reply to this email with the subject intact. =C2=A0(Not doing so probably means your req= uest will not trigger the filter=C2=A0I use to identify PALS slot requests = and be lost in my email, never to be found. :-)

=C2=A0

Form:

1. topic (e.g.,=C2=A0MPLS and Ethernet OAM In= terworking):

2. URL to your draft on = Datatracker =E2=80=93=C2=A0you only need to provide the file name to the ex= ample URL (e.g.,=C2=A0http://datatracker.ietf.org/doc/= draft-ietf-pwe3-mpls-eth-oam-iwk/): =C2=A0

3. brief statement of ob= jectives and issues to be discussed and resolved via the presentation durin= g the meeting =C2=A0(e.g., need to address security issues and get direction from the WG): =C2=A0

4. requested duration (n= orm/default is 10 min): =C2=A0

5. speaker Given-name FA= MILY-NAME (e.g., Dave SINICROPE): =C2=A0

=C2=A0

Thanks!

Dave


<= /div>
--f46d043c7e10776ce30522dc3908-- From nobody Mon Oct 26 09:43:44 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2AF1B4FA3; Mon, 26 Oct 2015 09:43:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151026164340.19662.27228.idtracker@ietfa.amsl.com> Date: Mon, 26 Oct 2015 09:43:40 -0700 Archived-At: Cc: pals chair , pals mailing list , RFC Editor Subject: [Pals] Protocol Action: 'S-PE Protection for MPLS and MPLS-TP Static Multi-Segment Pseudowires' to Proposed Standard (draft-ietf-pals-ms-pw-protection-04.txt) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 16:43:41 -0000 The IESG has approved the following document: - 'S-PE Protection for MPLS and MPLS-TP Static Multi-Segment Pseudowires' (draft-ietf-pals-ms-pw-protection-04.txt) as Proposed Standard This document is the product of the Pseudowire And LDP-enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-ms-pw-protection/ Technical Summary In MPLS and MPLS-TP environments, statically provisioned Single- Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the switching PEs (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. Working Group Summary The was nothing of note in the WG process. Document Quality A number of operators and vendors have expressed interest in this draft. Personnel Stewart Bryant is the Document Shepherd. Deborah Brungard is the Responsible Area Director. From nobody Tue Oct 27 08:02:36 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260D71A8F38; Tue, 27 Oct 2015 08:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFX2VvR7EiSA; Tue, 27 Oct 2015 08:02:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22001A8F36; Tue, 27 Oct 2015 08:02:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88E70BE5B; Tue, 27 Oct 2015 15:02:29 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zzt2iWXyVD5; Tue, 27 Oct 2015 15:02:29 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ACDABBE54; Tue, 27 Oct 2015 15:02:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445958149; bh=Z6nj0KbYKyOb26ezU83HtdpltBLeR066FxzSpKZ5IP0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qNmfMlUosPPt2MVGLsw5Q3UrFDNnwRVi9fkBUBZ6huCfWDVSwyfurwgIhjHi9Wb74 ydqq9VNz+JjODSFGbALJf4HF2GI05Cw3Kc3vHCPvGaoM46HYO1EH5Ziw72DiYkZP8o vowF3kcwAIv61sucB74WeR8rRgNn2EIp4MsgZWvM= To: Mingui Zhang , The IESG References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <562F9204.5000303@cs.tcd.ie> Date: Tue, 27 Oct 2015 15:02:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "pals-chairs@ietf.org" , "agmalis@gmail.com" , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 15:02:35 -0000 Hi, Sorry for the very slow response. On 16/10/15 02:26, Mingui Zhang wrote: > Hi Stephen, > > We haven't heard from you. Could you confirm whether the explanation is acceptable? I guess its acceptable, but maybe brittle, if the IEEE folks revise their stuff to use a different hash function. From their point of view that's a much smaller change than changing the size of MAC addresses. I'd say best would be if we did not have a fixed length, but rather said the length depends on the hash function being used. (I forget if that means you'd need a length field or algorithm identifier in your protocol.) S. > > Thanks, > Mingui > >> -----Original Message----- >> From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Mingui Zhang >> Sent: Saturday, October 10, 2015 9:32 AM >> To: Stephen Farrell; The IESG >> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org >> Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: >> (with COMMENT) >> >> Hi Stephen, >> >> Yes, it assumes a certainly length. >> I think this issue is similar as the EUI-64 issue: currently, the document >> assumes a traditional 48-bit MAC addresses are used, which is in consistence >> with RFC 7275. >> >> When I compared 802.1q-2005 and 802.1q-2014. I found all references related >> to 802.1q in the document are not changed. If such kind of changes do happen >> in the future, they could be and should be handled in the next protocol version >> of the STP-ICCP application, I think. >> >> Does it make sense? >> >> Thanks, >> Mingui >> >>> -----Original Message----- >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sent: Friday, October 09, 2015 6:09 PM >>> To: Mingui Zhang; The IESG >>> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org >>> Subject: Re: [Pals] Stephen Farrell's No Objection on >> draft-ietf-pwe3-iccp-stp-04: >>> (with COMMENT) >>> >>> >>> >>> On 09/10/15 03:54, Mingui Zhang wrote: >>>> Hi Stephen, >>>> >>>> 802.1q uses hmac-md5. This still holds in the latest version of >>>> 802.1q. >>>> >>>> I agree that sha256 could be used to enhance the security. However, >>>> I think that kind of enhancement is out the scope of this document >>>> and should be discussed in 802.1q. >>> >>> Of course. But if they do that, and make a change what is the impact >>> here is my question. (I didn't re-read the doc, but was this one where >>> it assumes a certainly length or something?) >>> >>> S >>> >>>> >>>> Thanks, Mingui >>>> >>>>> -----Original Message----- From: Pals >>>>> [mailto:pals-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: >>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: >>>>> pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org Subject: >>>>> [Pals] Stephen Farrell's No Objection on >>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) >>>>> >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-pwe3-iccp-stp-04: No Objection >>>>> >>>>> When responding, please keep the subject line intact and reply to >>>>> all email addresses included in the To and CC lines. (Feel free to >>>>> cut this introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >>>>> information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found >>>>> here: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>> COMMENT: >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>>>> >>>>> >>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what >>> if 802.1q >>>>> is fixed/improved e.g. to use sha256? >>>>> >>>>> >>>>> _______________________________________________ Pals mailing list >>>>> Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals > From nobody Tue Oct 27 08:42:24 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363C61A90DB; Tue, 27 Oct 2015 08:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4Gf7GMyiQOC; Tue, 27 Oct 2015 08:42:17 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3986B1A90D5; Tue, 27 Oct 2015 08:42:17 -0700 (PDT) Received: by wicll6 with SMTP id ll6so166391356wic.1; Tue, 27 Oct 2015 08:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZVtNCeoaTKW/DrxBnsUKYy0RfEz71H/AkaWItYyQgp0=; b=RtEMj1UwwzmdnEaasEQgI4e2hViV6GC37Q/38+N5S8VDjeLGHYtWd22yD70euqIeUH zVjSgz1RcGMmnswMCO1O5f4asEFxVHIwbR7oltVodnBNH2bb5ZiFTmN0m6y0so5AbccW wD8RQdhQRY2s7M3wLVplA/AIflQqg7KSrSNG5G7d+kgOahfV/DehA/tkvJMQtzTkQ6gY LyHREvSEXtV5Ncq0DX7IxLHc3/Qc+nkJnmYj3qiKk+MkrBVooh54vYBc+qjiAb7H8REH SYzX41cHAtGSrjHxz5vJqKKh+Szk0TtTgnSF0ifDHraz6UpELj1sk+oBRoFMEM4fC61m I2dg== X-Received: by 10.180.92.162 with SMTP id cn2mr26712578wib.87.1445960535755; Tue, 27 Oct 2015 08:42:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.195.10 with HTTP; Tue, 27 Oct 2015 08:41:56 -0700 (PDT) In-Reply-To: <562F9204.5000303@cs.tcd.ie> References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> <562F9204.5000303@cs.tcd.ie> From: "Andrew G. Malis" Date: Tue, 27 Oct 2015 11:41:56 -0400 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d043be0fc17d0e1052317ecdc Archived-At: Cc: Mingui Zhang , "pals-chairs@ietf.org" , The IESG , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 15:42:20 -0000 --f46d043be0fc17d0e1052317ecdc Content-Type: text/plain; charset=UTF-8 Stephen, As WG co-chair, I view this as a low-probability event that can be fixed by a revision to the RFC if it becomes necessary. Thanks, Andy On Tue, Oct 27, 2015 at 11:02 AM, Stephen Farrell wrote: > > Hi, > > Sorry for the very slow response. > > On 16/10/15 02:26, Mingui Zhang wrote: > > Hi Stephen, > > > > We haven't heard from you. Could you confirm whether the explanation is > acceptable? > > I guess its acceptable, but maybe brittle, if the IEEE folks > revise their stuff to use a different hash function. From their > point of view that's a much smaller change than changing the > size of MAC addresses. I'd say best would be if we did not > have a fixed length, but rather said the length depends on > the hash function being used. (I forget if that means you'd > need a length field or algorithm identifier in your protocol.) > > S. > > > > > > > Thanks, > > Mingui > > > >> -----Original Message----- > >> From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Mingui Zhang > >> Sent: Saturday, October 10, 2015 9:32 AM > >> To: Stephen Farrell; The IESG > >> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org > >> Subject: Re: [Pals] Stephen Farrell's No Objection on > draft-ietf-pwe3-iccp-stp-04: > >> (with COMMENT) > >> > >> Hi Stephen, > >> > >> Yes, it assumes a certainly length. > >> I think this issue is similar as the EUI-64 issue: currently, the > document > >> assumes a traditional 48-bit MAC addresses are used, which is in > consistence > >> with RFC 7275. > >> > >> When I compared 802.1q-2005 and 802.1q-2014. I found all references > related > >> to 802.1q in the document are not changed. If such kind of changes do > happen > >> in the future, they could be and should be handled in the next protocol > version > >> of the STP-ICCP application, I think. > >> > >> Does it make sense? > >> > >> Thanks, > >> Mingui > >> > >>> -----Original Message----- > >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >>> Sent: Friday, October 09, 2015 6:09 PM > >>> To: Mingui Zhang; The IESG > >>> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org > >>> Subject: Re: [Pals] Stephen Farrell's No Objection on > >> draft-ietf-pwe3-iccp-stp-04: > >>> (with COMMENT) > >>> > >>> > >>> > >>> On 09/10/15 03:54, Mingui Zhang wrote: > >>>> Hi Stephen, > >>>> > >>>> 802.1q uses hmac-md5. This still holds in the latest version of > >>>> 802.1q. > >>>> > >>>> I agree that sha256 could be used to enhance the security. However, > >>>> I think that kind of enhancement is out the scope of this document > >>>> and should be discussed in 802.1q. > >>> > >>> Of course. But if they do that, and make a change what is the impact > >>> here is my question. (I didn't re-read the doc, but was this one where > >>> it assumes a certainly length or something?) > >>> > >>> S > >>> > >>>> > >>>> Thanks, Mingui > >>>> > >>>>> -----Original Message----- From: Pals > >>>>> [mailto:pals-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: > >>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: > >>>>> pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org Subject: > >>>>> [Pals] Stephen Farrell's No Objection on > >>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) > >>>>> > >>>>> Stephen Farrell has entered the following ballot position for > >>>>> draft-ietf-pwe3-iccp-stp-04: No Objection > >>>>> > >>>>> When responding, please keep the subject line intact and reply to > >>>>> all email addresses included in the To and CC lines. (Feel free to > >>>>> cut this introductory paragraph, however.) > >>>>> > >>>>> > >>>>> Please refer to > >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more > >>>>> information about IESG DISCUSS and COMMENT positions. > >>>>> > >>>>> > >>>>> The document, along with other ballot positions, can be found > >>>>> here: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>> COMMENT: > >>>>> ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>>>> > >>>>> > >>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what > >>> if 802.1q > >>>>> is fixed/improved e.g. to use sha256? > >>>>> > >>>>> > >>>>> _______________________________________________ Pals mailing list > >>>>> Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals > >> _______________________________________________ > >> Pals mailing list > >> Pals@ietf.org > >> https://www.ietf.org/mailman/listinfo/pals > > > --f46d043be0fc17d0e1052317ecdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephen,

As WG co-chair, I view this as= a low-probability event that can be fixed by a revision to the RFC if it b= ecomes necessary.

Thanks,
Andy

On Tue, Oct 27,= 2015 at 11:02 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie&= gt; wrote:

Hi,

Sorry for the very slow response.

On 16/10/15 02:26, Mingui Zhang wrote:
> Hi Stephen,
>
> We haven't heard from you. Could you confi= rm whether the explanation is acceptable?

I guess its acceptable, but maybe brittle, if the IEEE folks
revise their stuff to use a different hash function. From their
point of view that's a much smaller change than changing the
size of MAC addresses. I'd say best would be if we did not
have a fixed length, but rather said the length depends on
the hash function being used. (I forget if that means you'd
need a length field or algorithm identifier in your protocol.)

S.



>
> Thanks,
> Mingui
>
>> -----Original Message-----
>> From: Pals [mailto:pals-b= ounces@ietf.org] On Behalf Of Mingui Zhang
>> Sent: Saturday, October 10, 2015 9:32 AM
>> To: Stephen Farrell; The IESG
>> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org
>> Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ie= tf-pwe3-iccp-stp-04:
>> (with COMMENT)
>>
>> Hi Stephen,
>>
>> Yes, it assumes a certainly length.
>> I think this issue is similar as the EUI-64 issue: currently, the = document
>> assumes a traditional 48-bit MAC addresses are used, which is in c= onsistence
>> with RFC 7275.
>>
>> When I compared 802.1q-2005 and 802.1q-2014. I found all reference= s related
>> to 802.1q in the document are not changed. If such kind of changes= do happen
>> in the future, they could be and should be handled in the next pro= tocol version
>> of the STP-ICCP application, I think.
>>
>> Does it make sense?
>>
>> Thanks,
>> Mingui
>>
>>> -----Original Message-----
>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>>> Sent: Friday, October 09, 2015 6:09 PM
>>> To: Mingui Zhang; The IESG
>>> Cc: pals-chairs@ietf.o= rg; agmalis@gmail.com; pals@ietf.org
>>> Subject: Re: [Pals] Stephen Farrell's No Objection on
>> draft-ietf-pwe3-iccp-stp-04:
>>> (with COMMENT)
>>>
>>>
>>>
>>> On 09/10/15 03:54, Mingui Zhang wrote:
>>>> Hi Stephen,
>>>>
>>>> 802.1q uses hmac-md5. This still holds in the latest versi= on of
>>>> 802.1q.
>>>>
>>>> I agree that sha256 could be used to enhance the security.= However,
>>>> I think that kind of enhancement is out the scope of this = document
>>>> and should be discussed in 802.1q.
>>>
>>> Of course. But if they do that, and make a change what is the = impact
>>> here is my question. (I didn't re-read the doc, but was th= is one where
>>> it assumes a certainly length or something?)
>>>
>>> S
>>>
>>>>
>>>> Thanks, Mingui
>>>>
>>>>> -----Original Message----- From: Pals
>>>>> [mailto:pals-= bounces@ietf.org] On Behalf Of Stephen Farrell Sent:
>>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc:=
>>>>> pals-chairs@ie= tf.org; agmalis@gmail.com; pals@ietf.org Subject:
>>>>> [Pals] Stephen Farrell's No Objection on
>>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT)
>>>>>
>>>>> Stephen Farrell has entered the following ballot posit= ion for
>>>>> draft-ietf-pwe3-iccp-stp-04: No Objection
>>>>>
>>>>> When responding, please keep the subject line intact a= nd reply to
>>>>> all email addresses included in the To and CC lines. (= Feel free to
>>>>> cut this introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to
>>>>> https://www.ietf.org/i= esg/statement/discuss-criteria.html for more
>>>>> information about IESG DISCUSS and COMMENT positions.<= br> >>>>>
>>>>>
>>>>> The document, along with other ballot positions, can b= e found
>>>>> here: https://datatra= cker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------= -------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>> COMMENT:
>>>>> ------------------------------------------------------= -------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>>>>
>>>>>
>>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that = ok? what
>>> if 802.1q
>>>>> is fixed/improved e.g. to use sha256?
>>>>>
>>>>>
>>>>> _______________________________________________ Pals m= ailing list
>>>>> Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals
>> _______________________________________________
>> Pals mailing list
>> Pals@ietf.org
>> https://www.ietf.org/mailman/listinfo/pals >

--f46d043be0fc17d0e1052317ecdc-- From nobody Tue Oct 27 09:23:21 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09A1A92E7 for ; Tue, 27 Oct 2015 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg8LSslPHY1t for ; Tue, 27 Oct 2015 09:23:16 -0700 (PDT) Received: from nm26-vm6.access.bullet.mail.gq1.yahoo.com (nm26-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939561A92FD for ; Tue, 27 Oct 2015 09:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1445962990; bh=ef7mTHriBtqVPbcBKaFZj5JkRl1Q5psbixnkaLB9CcM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=a91xxRDsSdyd4J7cNiUEXMlxXLH4Y9Kb58Oizds0iJMClTbPkdN0rLRjfS0oH0MGBrLXSrt0rjNg1gJvEb9mb5DIPboFLudw2svFvJRn9Wb7qujZr/HczMPTHgfmBYQvlDgCKu71J2/cFgtjHAjVSLBjGQy09n9+iYs5fmn8C+Bzqf1XxQxXuQzE2JWBeDYu3vPqovDaaPkVKrS7xg70apFzhkfWHtR14bWPyGu+lEnxYSeJsl9eiFwM0ugkB6RlD/+Ixhwss2X82ijI1bPddelFL4q4ulA4fpzOytEaG1Ui59DucupkwXBCfJxE24ljDE83Vev0nE0X84Z1jKFm4Q== Received: from [216.39.60.170] by nm26.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:23:10 -0000 Received: from [67.195.22.113] by tm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:23:10 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:23:10 -0000 X-Yahoo-Newman-Id: 899170.43629.bm@smtp115.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: K7y4GRAVM1nUKafw13MjZKwoRvMUwsdb93EX0LXLAo6TFrj mIF7rmUtSnqTIFtvMRjdJOctcpO_lT.ZRauiR3OFp2UkLN5_OfRVpOtdvftv w8O_MWjTX4izwIGjm9sf8HS3nEtKw7lPDcht4Q8pH6kKH.Ebh.J_jv2iHOsS 4eHqdax76SYrJe4yfKoaFLTsMLH4N1rOQKeFFOwqba0hDbgMH7l0Dg62C2iG WFWbftjxNOIS.JSmQkmBUR.A_9K7QlezTYFMYIDAbD1x2KqD_sZiwGjuLxRx 9G7kOhcwYUe4Nvd.3jvDvielw2XAdpo_u1hgVquM.5e78ZKlUAd41KVa03rS MqS26TK4_aRfPfVVTfXU1arOgQmVqCdM9e6JsM5PQBqpyPhgybkblRIJhfHF CRGzApvoGjHUjCsM0LO1KI.kmQL8Po9L_70c79LS2Q6f76jRwmGJLiigPiCJ 305_39a_HVQxI8IbF3e_Zj1b1qI5s8OcLQ0xxGaXVXJaXooxCLYMEEqDVUhY 9gZY.SY8UB8fkcZ2SxHlFoXqfO9VN8nIc9doCZpCp8Hrg91yk_W5yj_w- X-Yahoo-SMTP: AR5_vwuswBBBxttajAdmA6MrHv2fOmL0PL2m9ko1TKipiHmVNQ-- To: "Andrew G. Malis" , Stephen Farrell References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> <562F9204.5000303@cs.tcd.ie> From: Mick Seaman Message-ID: <562FA4EC.3060501@sbcglobal.net> Date: Tue, 27 Oct 2015 09:23:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050305050100000103050304" Archived-At: Cc: Mingui Zhang , "pals-chairs@ietf.org" , The IESG , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 16:23:19 -0000 This is a multi-part message in MIME format. --------------050305050100000103050304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I (personal opinion) agree with Andy with regard to has function change probability. The use of HMAC-MD5 in 802.1Q is as a hash/digest of data to confirm (to an acceptable level of probability that the input data that two parties hold is the same, without any view as to the presence of malicious parties - security is handled quite separately from this). To be honest in retrospect we might just as well have used a CRC: security functions aren't magic dust. It's a common misconception that a hashing function that has desirable security properties (an attacker don't know how to change hash if data is changed, doesn't know how to change data to match a different hash value) necessarily has better hash properties in the sense it distributes the results of input data more evenly over the set of output hash data values. I have no reason to suppose that SHA-256 would be 'better'/significantly different in terms of the use of HMAC-MD5 in 802.1Q-2014. Mick Seaman On 10/27/2015 8:41 AM, Andrew G. Malis wrote: > Stephen, > > As WG co-chair, I view this as a low-probability event that can be > fixed by a revision to the RFC if it becomes necessary. > > Thanks, > Andy > > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Farrell > > wrote: > > > Hi, > > Sorry for the very slow response. > > On 16/10/15 02:26, Mingui Zhang wrote: > > Hi Stephen, > > > > We haven't heard from you. Could you confirm whether the explanation is acceptable? > > I guess its acceptable, but maybe brittle, if the IEEE folks > revise their stuff to use a different hash function. From their > point of view that's a much smaller change than changing the > size of MAC addresses. I'd say best would be if we did not > have a fixed length, but rather said the length depends on > the hash function being used. (I forget if that means you'd > need a length field or algorithm identifier in your protocol.) > > S. > > > > > > > Thanks, > > Mingui > > > >> -----Original Message----- > >> From: Pals [mailto:pals-bounces@ietf.org > ] On Behalf Of Mingui Zhang > >> Sent: Saturday, October 10, 2015 9:32 AM > >> To: Stephen Farrell; The IESG > >> Cc: pals-chairs@ietf.org ; > agmalis@gmail.com ; pals@ietf.org > > >> Subject: Re: [Pals] Stephen Farrell's No Objection on > draft-ietf-pwe3-iccp-stp-04: > >> (with COMMENT) > >> > >> Hi Stephen, > >> > >> Yes, it assumes a certainly length. > >> I think this issue is similar as the EUI-64 issue: currently, > the document > >> assumes a traditional 48-bit MAC addresses are used, which is > in consistence > >> with RFC 7275. > >> > >> When I compared 802.1q-2005 and 802.1q-2014. I found all > references related > >> to 802.1q in the document are not changed. If such kind of > changes do happen > >> in the future, they could be and should be handled in the next > protocol version > >> of the STP-ICCP application, I think. > >> > >> Does it make sense? > >> > >> Thanks, > >> Mingui > >> > >>> -----Original Message----- > >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie > ] > >>> Sent: Friday, October 09, 2015 6:09 PM > >>> To: Mingui Zhang; The IESG > >>> Cc: pals-chairs@ietf.org ; > agmalis@gmail.com ; pals@ietf.org > > >>> Subject: Re: [Pals] Stephen Farrell's No Objection on > >> draft-ietf-pwe3-iccp-stp-04: > >>> (with COMMENT) > >>> > >>> > >>> > >>> On 09/10/15 03:54, Mingui Zhang wrote: > >>>> Hi Stephen, > >>>> > >>>> 802.1q uses hmac-md5. This still holds in the latest version of > >>>> 802.1q. > >>>> > >>>> I agree that sha256 could be used to enhance the security. > However, > >>>> I think that kind of enhancement is out the scope of this > document > >>>> and should be discussed in 802.1q. > >>> > >>> Of course. But if they do that, and make a change what is the > impact > >>> here is my question. (I didn't re-read the doc, but was this > one where > >>> it assumes a certainly length or something?) > >>> > >>> S > >>> > >>>> > >>>> Thanks, Mingui > >>>> > >>>>> -----Original Message----- From: Pals > >>>>> [mailto:pals-bounces@ietf.org > ] On Behalf Of Stephen Farrell Sent: > >>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: > >>>>> pals-chairs@ietf.org ; > agmalis@gmail.com ; pals@ietf.org > Subject: > >>>>> [Pals] Stephen Farrell's No Objection on > >>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) > >>>>> > >>>>> Stephen Farrell has entered the following ballot position for > >>>>> draft-ietf-pwe3-iccp-stp-04: No Objection > >>>>> > >>>>> When responding, please keep the subject line intact and > reply to > >>>>> all email addresses included in the To and CC lines. (Feel > free to > >>>>> cut this introductory paragraph, however.) > >>>>> > >>>>> > >>>>> Please refer to > >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html > for more > >>>>> information about IESG DISCUSS and COMMENT positions. > >>>>> > >>>>> > >>>>> The document, along with other ballot positions, can be found > >>>>> here: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ > >>>>> > >>>>> > >>>>> > >>>>> > ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>> COMMENT: > >>>>> > ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>>>> > >>>>> > >>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that > ok? what > >>> if 802.1q > >>>>> is fixed/improved e.g. to use sha256? > >>>>> > >>>>> > >>>>> _______________________________________________ Pals mailing > list > >>>>> Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > >> _______________________________________________ > >> Pals mailing list > >> Pals@ietf.org > >> https://www.ietf.org/mailman/listinfo/pals > > > > > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --------------050305050100000103050304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I (personal opinion) agree with Andy with regard to has function change probability. The use of HMAC-MD5 in 802.1Q is as a hash/digest of data to confirm (to an acceptable level of probability that the input data that two parties hold is the same, without any view as to the presence of malicious parties - security is handled quite separately from this). To be honest in retrospect we might just as well have used a CRC: security functions aren't magic dust. It's a common misconception that a hashing function that has desirable security properties (an attacker don't know how to change hash if data is changed, doesn't know how to change data to match a different hash value) necessarily has better hash properties in the sense it distributes the results of input data more evenly over the set of output hash data values. I have no reason to suppose that SHA-256 would be 'better'/significantly different in terms of the use of HMAC-MD5 in 802.1Q-2014.

Mick Seaman

On 10/27/2015 8:41 AM, Andrew G. Malis wrote:
Stephen,

As WG co-chair, I view this as a low-probability event that can be fixed by a revision to the RFC if it becomes necessary.

Thanks,
Andy

On Tue, Oct 27, 2015 at 11:02 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi,

Sorry for the very slow response.

On 16/10/15 02:26, Mingui Zhang wrote:
> Hi Stephen,
>
> We haven't heard from you. Could you confirm whether the explanation is acceptable?

I guess its acceptable, but maybe brittle, if the IEEE folks
revise their stuff to use a different hash function. From their
point of view that's a much smaller change than changing the
size of MAC addresses. I'd say best would be if we did not
have a fixed length, but rather said the length depends on
the hash function being used. (I forget if that means you'd
need a length field or algorithm identifier in your protocol.)

S.



>
> Thanks,
> Mingui
>
>> -----Original Message-----
>> From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Mingui Zhang
>> Sent: Saturday, October 10, 2015 9:32 AM
>> To: Stephen Farrell; The IESG
>> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org
>> Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04:
>> (with COMMENT)
>>
>> Hi Stephen,
>>
>> Yes, it assumes a certainly length.
>> I think this issue is similar as the EUI-64 issue: currently, the document
>> assumes a traditional 48-bit MAC addresses are used, which is in consistence
>> with RFC 7275.
>>
>> When I compared 802.1q-2005 and 802.1q-2014. I found all references related
>> to 802.1q in the document are not changed. If such kind of changes do happen
>> in the future, they could be and should be handled in the next protocol version
>> of the STP-ICCP application, I think.
>>
>> Does it make sense?
>>
>> Thanks,
>> Mingui
>>
>>> -----Original Message-----
>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>>> Sent: Friday, October 09, 2015 6:09 PM
>>> To: Mingui Zhang; The IESG
>>> Cc: pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org
>>> Subject: Re: [Pals] Stephen Farrell's No Objection on
>> draft-ietf-pwe3-iccp-stp-04:
>>> (with COMMENT)
>>>
>>>
>>>
>>> On 09/10/15 03:54, Mingui Zhang wrote:
>>>> Hi Stephen,
>>>>
>>>> 802.1q uses hmac-md5. This still holds in the latest version of
>>>> 802.1q.
>>>>
>>>> I agree that sha256 could be used to enhance the security. However,
>>>> I think that kind of enhancement is out the scope of this document
>>>> and should be discussed in 802.1q.
>>>
>>> Of course. But if they do that, and make a change what is the impact
>>> here is my question. (I didn't re-read the doc, but was this one where
>>> it assumes a certainly length or something?)
>>>
>>> S
>>>
>>>>
>>>> Thanks, Mingui
>>>>
>>>>> -----Original Message----- From: Pals
>>>>> [mailto:pals-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:
>>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc:
>>>>> pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org Subject:
>>>>> [Pals] Stephen Farrell's No Objection on
>>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT)
>>>>>
>>>>> Stephen Farrell has entered the following ballot position for
>>>>> draft-ietf-pwe3-iccp-stp-04: No Objection
>>>>>
>>>>> When responding, please keep the subject line intact and reply to
>>>>> all email addresses included in the To and CC lines. (Feel free to
>>>>> cut this introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to
>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>>>>> information about IESG DISCUSS and COMMENT positions.
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found
>>>>> here: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>> COMMENT:
>>>>> -------------------------------------------------------------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>>>>
>>>>>
>>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what
>>> if 802.1q
>>>>> is fixed/improved e.g. to use sha256?
>>>>>
>>>>>
>>>>> _______________________________________________ Pals mailing list
>>>>> Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals
>> _______________________________________________
>> Pals mailing list
>> Pals@ietf.org
>> https://www.ietf.org/mailman/listinfo/pals
>



_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

--------------050305050100000103050304-- From nobody Tue Oct 27 09:29:48 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A531AC3AD; Tue, 27 Oct 2015 09:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzXsHK9g25lz; Tue, 27 Oct 2015 09:29:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B7F1A911A; Tue, 27 Oct 2015 09:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E4A7BE7B; Tue, 27 Oct 2015 16:29:39 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkjgIWBCk2Oe; Tue, 27 Oct 2015 16:29:39 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 83501BE77; Tue, 27 Oct 2015 16:29:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445963379; bh=eZk2L+rp7/DXQlgW9M05RRhBbyCoKjasI7e775Xd/Lg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dfTbpNCpDC2vX3Nu+efaX4KoS5MF4tW0uR+Tht5PEW4l8LgAbcspB/8GK37QBcEVs AUNMautThKScdoCadhwHIvX2rgjHKSLBSPQ89xJRkH4lTSpne3MYYMkZFmYYLpKObt bncxvVsTXTf1rmr2QlRWKRwuF3t/dhCANUODAke8= To: Mick Seaman , "Andrew G. Malis" References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> <562F9204.5000303@cs.tcd.ie> <562FA4EC.3060501@sbcglobal.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <562FA672.2060501@cs.tcd.ie> Date: Tue, 27 Oct 2015 16:29:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562FA4EC.3060501@sbcglobal.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Mingui Zhang , "pals-chairs@ietf.org" , The IESG , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 16:29:44 -0000 Just to be clear, my (non blocking) comment wasn't about security but just about use of a fixed width field when the underlying IEEE spec could change to use of a different sized value. S. On 27/10/15 16:23, Mick Seaman wrote: > I (personal opinion) agree with Andy with regard to has function change > probability. The use of HMAC-MD5 in 802.1Q is as a hash/digest of data > to confirm (to an acceptable level of probability that the input data > that two parties hold is the same, without any view as to the presence > of malicious parties - security is handled quite separately from this). > To be honest in retrospect we might just as well have used a CRC: > security functions aren't magic dust. It's a common misconception that a > hashing function that has desirable security properties (an attacker > don't know how to change hash if data is changed, doesn't know how to > change data to match a different hash value) necessarily has better > hash properties in the sense it distributes the results of input data > more evenly over the set of output hash data values. I have no reason to > suppose that SHA-256 would be 'better'/significantly different in terms > of the use of HMAC-MD5 in 802.1Q-2014. > > Mick Seaman > > On 10/27/2015 8:41 AM, Andrew G. Malis wrote: >> Stephen, >> >> As WG co-chair, I view this as a low-probability event that can be >> fixed by a revision to the RFC if it becomes necessary. >> >> Thanks, >> Andy >> >> On Tue, Oct 27, 2015 at 11:02 AM, Stephen Farrell >> > wrote: >> >> >> Hi, >> >> Sorry for the very slow response. >> >> On 16/10/15 02:26, Mingui Zhang wrote: >> > Hi Stephen, >> > >> > We haven't heard from you. Could you confirm whether the >> explanation is acceptable? >> >> I guess its acceptable, but maybe brittle, if the IEEE folks >> revise their stuff to use a different hash function. From their >> point of view that's a much smaller change than changing the >> size of MAC addresses. I'd say best would be if we did not >> have a fixed length, but rather said the length depends on >> the hash function being used. (I forget if that means you'd >> need a length field or algorithm identifier in your protocol.) >> >> S. >> >> >> >> > >> > Thanks, >> > Mingui >> > >> >> -----Original Message----- >> >> From: Pals [mailto:pals-bounces@ietf.org >> ] On Behalf Of Mingui Zhang >> >> Sent: Saturday, October 10, 2015 9:32 AM >> >> To: Stephen Farrell; The IESG >> >> Cc: pals-chairs@ietf.org ; >> agmalis@gmail.com ; pals@ietf.org >> >> >> Subject: Re: [Pals] Stephen Farrell's No Objection on >> draft-ietf-pwe3-iccp-stp-04: >> >> (with COMMENT) >> >> >> >> Hi Stephen, >> >> >> >> Yes, it assumes a certainly length. >> >> I think this issue is similar as the EUI-64 issue: currently, >> the document >> >> assumes a traditional 48-bit MAC addresses are used, which is >> in consistence >> >> with RFC 7275. >> >> >> >> When I compared 802.1q-2005 and 802.1q-2014. I found all >> references related >> >> to 802.1q in the document are not changed. If such kind of >> changes do happen >> >> in the future, they could be and should be handled in the next >> protocol version >> >> of the STP-ICCP application, I think. >> >> >> >> Does it make sense? >> >> >> >> Thanks, >> >> Mingui >> >> >> >>> -----Original Message----- >> >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie >> ] >> >>> Sent: Friday, October 09, 2015 6:09 PM >> >>> To: Mingui Zhang; The IESG >> >>> Cc: pals-chairs@ietf.org ; >> agmalis@gmail.com ; pals@ietf.org >> >> >>> Subject: Re: [Pals] Stephen Farrell's No Objection on >> >> draft-ietf-pwe3-iccp-stp-04: >> >>> (with COMMENT) >> >>> >> >>> >> >>> >> >>> On 09/10/15 03:54, Mingui Zhang wrote: >> >>>> Hi Stephen, >> >>>> >> >>>> 802.1q uses hmac-md5. This still holds in the latest version of >> >>>> 802.1q. >> >>>> >> >>>> I agree that sha256 could be used to enhance the security. >> However, >> >>>> I think that kind of enhancement is out the scope of this >> document >> >>>> and should be discussed in 802.1q. >> >>> >> >>> Of course. But if they do that, and make a change what is the >> impact >> >>> here is my question. (I didn't re-read the doc, but was this >> one where >> >>> it assumes a certainly length or something?) >> >>> >> >>> S >> >>> >> >>>> >> >>>> Thanks, Mingui >> >>>> >> >>>>> -----Original Message----- From: Pals >> >>>>> [mailto:pals-bounces@ietf.org >> ] On Behalf Of Stephen Farrell Sent: >> >>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: >> >>>>> pals-chairs@ietf.org ; >> agmalis@gmail.com ; pals@ietf.org >> Subject: >> >>>>> [Pals] Stephen Farrell's No Objection on >> >>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) >> >>>>> >> >>>>> Stephen Farrell has entered the following ballot position for >> >>>>> draft-ietf-pwe3-iccp-stp-04: No Objection >> >>>>> >> >>>>> When responding, please keep the subject line intact and >> reply to >> >>>>> all email addresses included in the To and CC lines. (Feel >> free to >> >>>>> cut this introductory paragraph, however.) >> >>>>> >> >>>>> >> >>>>> Please refer to >> >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more >> >>>>> information about IESG DISCUSS and COMMENT positions. >> >>>>> >> >>>>> >> >>>>> The document, along with other ballot positions, can be found >> >>>>> here: >> https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>> COMMENT: >> >>>>> >> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that >> ok? what >> >>> if 802.1q >> >>>>> is fixed/improved e.g. to use sha256? >> >>>>> >> >>>>> >> >>>>> _______________________________________________ Pals mailing >> list >> >>>>> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals >> >> _______________________________________________ >> >> Pals mailing list >> >> Pals@ietf.org >> >> https://www.ietf.org/mailman/listinfo/pals >> > >> >> >> >> >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals > > From nobody Tue Oct 27 09:45:49 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C901AC3FC for ; Tue, 27 Oct 2015 09:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgQu8LD1VedE for ; Tue, 27 Oct 2015 09:45:45 -0700 (PDT) Received: from nm18-vm3.access.bullet.mail.gq1.yahoo.com (nm18-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.76]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3491AC3FE for ; Tue, 27 Oct 2015 09:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1445964342; bh=yjKiMJGHKMYqzZV0oSqxvhef/aIjX7NzvkjcdLwv+jg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=qZa0vrM8x0EuMYgvaM2pId+DJrjoj6VR0b5diDD0fIa/IEOGTaAmKzfyuRLz/OVQTvQoYzJnaKEY+DY/pLQcKb6T86qzUWNREvJxUJ/hoREJ4dydcgOVbas3myPMJM2tPcwfsMCw8jW63oQiCpJI2HDGi+BW66cwZYOKL0IoiXMqQQnmsiLxLNO+j1mzEP8V1TmI3K/1MC4pN16nTZgRZ3ZhX0URD730Z5xZqYPhh2eJ+AmqkIqicrS4FPFBj5VYy15TOp9TpgZFY8jyz4BLin77kDiqr7a8HgQVfaDNoMmEOH2ekLJ3H0mnzp1BScma6xKWFTD/MX9FKlPJlXmI9g== Received: from [216.39.60.166] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:45:42 -0000 Received: from [67.195.22.116] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:45:42 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:45:42 -0000 X-Yahoo-Newman-Id: 311299.39427.bm@smtp111.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 7RRh2LkVM1kctYbAYrBikyT8uI6Iv8c3DR.Wgi_hzG6hTP6 YTsu9GEp74RtEW1akqf6I3SR50uxxExvnSScDjx2lUo4mvHhJ83ueoKhqzgg lJTyuHYCgBzgZRAvxjaI__k4b5s3HnDdhU3hlFGTKdc6IWdUXReoZXQjQjzV YQlr2SgblZTwDAwe1jdbtaQprJXY04mlryt0YEU_Vnh48LHRaBcsb5urJVss 9MZatcWDS1EaB6xLAe7UNKOBUKCLGlNE2SCQydHAv277Lt6ShlXRQMxumSgh s6MQq.tSZPFEQDnAcWj907eARc7oi9f68EmjNcpFH1XezOYACsAorFTgtn6T 3D.0P.Eo4hlERHKGodbVn23_2274NuY5PwYQxHUmH5DKOUtJ_A2C9CdnHMFl 1bqhYxzsRUBkEZKB3AoPCeQW89luZh1WxrCIJtxYq4xVLm2o8UaWL3xSBmDJ 4ioWasCdFrUEQtNQACMTvqjNl5JQFeoNyru.fcb0.X8DfyvyxffAzgANFXOk 6O29kTPbWZzdVQY0a6mK3opCHronNuuACdG386LSXoY9y5rf_ckYBlO8- X-Yahoo-SMTP: AR5_vwuswBBBxttajAdmA6MrHv2fOmL0PL2m9ko1TKipiHmVNQ-- To: Stephen Farrell , "Andrew G. Malis" References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> <562F9204.5000303@cs.tcd.ie> <562FA4EC.3060501@sbcglobal.net> <562FA672.2060501@cs.tcd.ie> From: Mick Seaman Message-ID: <562FAA35.50705@sbcglobal.net> Date: Tue, 27 Oct 2015 09:45:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562FA672.2060501@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Mingui Zhang , "pals-chairs@ietf.org" , The IESG , "pals@ietf.org" Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 16:45:47 -0000 Stephen, Understood re your comment. I think the length change itself is a small probability, since the 16 octets currently used are not oversized with respect to the other fields that accompany it (so no pressure to make it smaller), while I see no push to lower collision probability-we are already in overkill territory - in 802.1Q this hash is protecting against configuration mistakes not against the chance of two random data sets being the same. Mick On 10/27/2015 9:29 AM, Stephen Farrell wrote: > Just to be clear, my (non blocking) comment wasn't about > security but just about use of a fixed width field when > the underlying IEEE spec could change to use of a different > sized value. > > S. > > On 27/10/15 16:23, Mick Seaman wrote: >> I (personal opinion) agree with Andy with regard to has function change >> probability. The use of HMAC-MD5 in 802.1Q is as a hash/digest of data >> to confirm (to an acceptable level of probability that the input data >> that two parties hold is the same, without any view as to the presence >> of malicious parties - security is handled quite separately from this). >> To be honest in retrospect we might just as well have used a CRC: >> security functions aren't magic dust. It's a common misconception that a >> hashing function that has desirable security properties (an attacker >> don't know how to change hash if data is changed, doesn't know how to >> change data to match a different hash value) necessarily has better >> hash properties in the sense it distributes the results of input data >> more evenly over the set of output hash data values. I have no reason to >> suppose that SHA-256 would be 'better'/significantly different in terms >> of the use of HMAC-MD5 in 802.1Q-2014. >> >> Mick Seaman >> >> On 10/27/2015 8:41 AM, Andrew G. Malis wrote: >>> Stephen, >>> >>> As WG co-chair, I view this as a low-probability event that can be >>> fixed by a revision to the RFC if it becomes necessary. >>> >>> Thanks, >>> Andy >>> >>> On Tue, Oct 27, 2015 at 11:02 AM, Stephen Farrell >>> > wrote: >>> >>> >>> Hi, >>> >>> Sorry for the very slow response. >>> >>> On 16/10/15 02:26, Mingui Zhang wrote: >>> > Hi Stephen, >>> > >>> > We haven't heard from you. Could you confirm whether the >>> explanation is acceptable? >>> >>> I guess its acceptable, but maybe brittle, if the IEEE folks >>> revise their stuff to use a different hash function. From their >>> point of view that's a much smaller change than changing the >>> size of MAC addresses. I'd say best would be if we did not >>> have a fixed length, but rather said the length depends on >>> the hash function being used. (I forget if that means you'd >>> need a length field or algorithm identifier in your protocol.) >>> >>> S. >>> >>> >>> >>> > >>> > Thanks, >>> > Mingui >>> > >>> >> -----Original Message----- >>> >> From: Pals [mailto:pals-bounces@ietf.org >>> ] On Behalf Of Mingui Zhang >>> >> Sent: Saturday, October 10, 2015 9:32 AM >>> >> To: Stephen Farrell; The IESG >>> >> Cc: pals-chairs@ietf.org ; >>> agmalis@gmail.com ; pals@ietf.org >>> >>> >> Subject: Re: [Pals] Stephen Farrell's No Objection on >>> draft-ietf-pwe3-iccp-stp-04: >>> >> (with COMMENT) >>> >> >>> >> Hi Stephen, >>> >> >>> >> Yes, it assumes a certainly length. >>> >> I think this issue is similar as the EUI-64 issue: currently, >>> the document >>> >> assumes a traditional 48-bit MAC addresses are used, which is >>> in consistence >>> >> with RFC 7275. >>> >> >>> >> When I compared 802.1q-2005 and 802.1q-2014. I found all >>> references related >>> >> to 802.1q in the document are not changed. If such kind of >>> changes do happen >>> >> in the future, they could be and should be handled in the next >>> protocol version >>> >> of the STP-ICCP application, I think. >>> >> >>> >> Does it make sense? >>> >> >>> >> Thanks, >>> >> Mingui >>> >> >>> >>> -----Original Message----- >>> >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie >>> ] >>> >>> Sent: Friday, October 09, 2015 6:09 PM >>> >>> To: Mingui Zhang; The IESG >>> >>> Cc: pals-chairs@ietf.org ; >>> agmalis@gmail.com ; pals@ietf.org >>> >>> >>> Subject: Re: [Pals] Stephen Farrell's No Objection on >>> >> draft-ietf-pwe3-iccp-stp-04: >>> >>> (with COMMENT) >>> >>> >>> >>> >>> >>> >>> >>> On 09/10/15 03:54, Mingui Zhang wrote: >>> >>>> Hi Stephen, >>> >>>> >>> >>>> 802.1q uses hmac-md5. This still holds in the latest version of >>> >>>> 802.1q. >>> >>>> >>> >>>> I agree that sha256 could be used to enhance the security. >>> However, >>> >>>> I think that kind of enhancement is out the scope of this >>> document >>> >>>> and should be discussed in 802.1q. >>> >>> >>> >>> Of course. But if they do that, and make a change what is the >>> impact >>> >>> here is my question. (I didn't re-read the doc, but was this >>> one where >>> >>> it assumes a certainly length or something?) >>> >>> >>> >>> S >>> >>> >>> >>>> >>> >>>> Thanks, Mingui >>> >>>> >>> >>>>> -----Original Message----- From: Pals >>> >>>>> [mailto:pals-bounces@ietf.org >>> ] On Behalf Of Stephen Farrell Sent: >>> >>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: >>> >>>>> pals-chairs@ietf.org ; >>> agmalis@gmail.com ; pals@ietf.org >>> Subject: >>> >>>>> [Pals] Stephen Farrell's No Objection on >>> >>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) >>> >>>>> >>> >>>>> Stephen Farrell has entered the following ballot position for >>> >>>>> draft-ietf-pwe3-iccp-stp-04: No Objection >>> >>>>> >>> >>>>> When responding, please keep the subject line intact and >>> reply to >>> >>>>> all email addresses included in the To and CC lines. (Feel >>> free to >>> >>>>> cut this introductory paragraph, however.) >>> >>>>> >>> >>>>> >>> >>>>> Please refer to >>> >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more >>> >>>>> information about IESG DISCUSS and COMMENT positions. >>> >>>>> >>> >>>>> >>> >>>>> The document, along with other ballot positions, can be found >>> >>>>> here: >>> https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> ------------------------------------------------------------------- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>> COMMENT: >>> >>>>> >>> ------------------------------------------------------------------- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that >>> ok? what >>> >>> if 802.1q >>> >>>>> is fixed/improved e.g. to use sha256? >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ Pals mailing >>> list >>> >>>>> Pals@ietf.org >>> https://www.ietf.org/mailman/listinfo/pals >>> >> _______________________________________________ >>> >> Pals mailing list >>> >> Pals@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/pals >>> > >>> >>> >>> >>> >>> _______________________________________________ >>> Pals mailing list >>> Pals@ietf.org >>> https://www.ietf.org/mailman/listinfo/pals >> From nobody Tue Oct 27 23:10:47 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBF61B4C35 for ; Tue, 27 Oct 2015 23:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CnRbwSw_Aaq for ; Tue, 27 Oct 2015 23:10:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DED61AC82C for ; Tue, 27 Oct 2015 23:10:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZL17910; Wed, 28 Oct 2015 06:10:32 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 28 Oct 2015 06:10:28 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.235]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Wed, 28 Oct 2015 14:09:41 +0800 From: Jiangyuanlong To: "stbryant@cisco.com" , Stewart Bryant , Lizhong Jin Thread-Topic: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward Thread-Index: AQHRDBidgl4b3ranBEC3rX5ENygXY56AUOLg Date: Wed, 28 Oct 2015 06:09:41 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B68283796@szxema506-mbs.china.huawei.com> References: <3B0A1BED22CAD649A1B3E97BE5DDD68B6827BD22@szxema506-mbs.china.huawei.com> <5617B468.2020100@gmail.com> <5627B4DB.3050205@cisco.com> In-Reply-To: <5627B4DB.3050205@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B68283796szxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-l2vpn-vpls-pe-etree@tools.ietf.org" , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-ietf-l2vpn-vpls-pe-etree - possible ways forward X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 06:10:46 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B68283796szxema506mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3Rld2FydCBhbmQgYWxsLA0KDQpXZSB3b3VsZCBsaWtlIHRvIHVwZGF0ZSB0aGUgZHJhZnQgd2l0 aCB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCjEuICAgICAgIFVwZGF0ZSB0aGUgcmVmZXJlbmNl ICDigJxbTUVGNi4xXeKAnSB0byDigJxbTUVGNi4yXeKAnSwgYW5kIHJlcGxhY2Ug4oCcICAgW01F RjYuMV0gIE1ldHJvIEV0aGVybmV0IEZvcnVtLCAiRXRoZXJuZXQgU2VydmljZXMgRGVmaW5pdGlv bnMgLVBoYXNlIDIiLCBUZWNobmljYWwgU3BlY2lmaWNhdGlvbiBNRUYgNi4xLCBBcHJpbCAyMDA4 LuKAnSB3aXRoIOKAnFtNRUY2LjJdIE1ldHJvIEV0aGVybmV0IEZvcnVtLCAiRVZDIEV0aGVybmV0 IFNlcnZpY2VzIERlZmluaXRpb25zIFBoYXNlIDMiLCBUZWNobmljYWwgU3BlY2lmaWNhdGlvbiBN RUYgNi4yLCBBdWd1c3QgMjAxNC7igJ0NCg0KDQoyLiAgICAgICBBZGQgdGhlIGZvbGxvd2luZyB0 ZXh0cyB0byB0aGUgZW5kIG9mIFNlY3Rpb24gNi4xOiAg4oCcV2hlbiBWUExTIGlzIHNldCB1cCB1 c2luZyBQV2lkIEZFQyBFbGVtZW50IChzZWUgQXBwZW5kaXggQSBvZiBbUkZDNDc2Ml0pLCBpdHMg RS1UcmVlIHNpZ25hbGluZyBpcyBzaW1pbGFyIHRvIHRoZSBhYm92ZSBwcm9jZXNzLiBEeW5hbWlj IHJlLWNvbmZpZ3VyYXRpb24gb2YgRS1UcmVlIHNob3VsZCBiZSBhdm9pZGVkIGZvciB0aGlzIGNh c2UsIGhvd2V2ZXIsIHdoZW4gcmUtY29uZmlndXJhdGlvbiBvZiBFLVRyZWUgaXMgZm9yY2VkIG9u IGEgUEUgZm9yIHNvbWUgcmVhc29uIChlLmcuLCBhIGNvbmZpZ3VyYXRpb24gZXJyb3IpLCB0aGUg UEUgbWF5IGNsb3NlIHRoZSBMRFAgc2Vzc2lvbiB3aXRoIGl0cyBwZWVyIFBFcyBmb3IgdGhpcyBW UExTIGluc3RhbmNlLCBhbmQgcmUtaW5zdGFsbCBpdHMgUFcgbGFiZWxzLCBzbyB0aGF0IGl0cyBw ZWVyIFBFcyBjYW4gc2VuZCBvdXQgdGhlIExEUCBsYWJlbCBtYXBwaW5nIG1lc3NhZ2UgYWdhaW4u 4oCdDQpBIG5ldyB2ZXJzaW9uIHdpbGwgYmUgc3VibWl0dGVkIG9uY2UgdGhlIElFVEYgc2l0ZSBp cyByZW9wZW5lZC4NCkFueSBvdGhlciBvcGluaW9ucz8NCg0KVGhhbmtzLA0KWXVhbmxvbmcNCg0K DQpGcm9tOiBTdGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0YnJ5YW50QGNpc2NvLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAyMSwgMjAxNSAxMTo1MyBQTQ0KVG86IFN0ZXdhcnQgQnJ5YW50 OyBKaWFuZ3l1YW5sb25nOyBMaXpob25nIEppbg0KQ2M6IHBhbHNAaWV0Zi5vcmc7IHBhbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWVAdG9vbHMu aWV0Zi5vcmc7IFN0ZXdhcnQgQnJ5YW50DQpTdWJqZWN0OiBSZTogW1BhbHNdIGRyYWZ0LWlldGYt bDJ2cG4tdnBscy1wZS1ldHJlZSAtIHBvc3NpYmxlIHdheXMgZm9yd2FyZA0KDQpJIGhhdmUgaGVh cmQgbm90aGluZyBiYWNrIGZyb20gdGhlIGdyb3VwLCBhbmQgc28gSSBhc3N1bWUgdGhhdCB0aGlz DQppcyBhbiBhY2NlcHRhYmxlIHdheSBmb3J3YXJkLg0KDQpQbGVhc2Ugd2lsbCB0aGUgYXV0aG9y cyBtYWtlIHRoZSBuZWNlc3NhcnkgdXBkYXRlcyB0byB0aGUgdGV4dC4NCg0KUmVnYXJkcw0KDQpT dGV3YXJ0DQoNCg0KT24gMDkvMTAvMjAxNSAxMzozNCwgU3Rld2FydCBCcnlhbnQgd3JvdGU6DQoN CkZyb20gbXkgcGVyc3BlY3RpdmUsIGFuZCB3aXRoIGR1ZSByZWdhcmQgYXMgdG8gd2hlcmUgd2Ug YXJlLCAgb3B0aW9uIG9uZQ0KaXMgdGhlIG9uZSB0aGF0IEkgd291bGQgcHJlZmVyIHRvIG1vdmUg dGhpbmdzIGFsb25nLg0KDQpUaGF0IHdvdWxkIG5vdCBwcmVjbHVkZSB1cyBpbnRyb2R1Y2luZyBh bm90aGVyIFJGQyBhdCBhIGxhdGVyIGRhdGUgaWYNCnRoZXJlIGFyZSBmdXJ0aGVyIG9wZXJhdGlv bmFsIGNvbnNpZGVyYXRpb25zIG9yIGFsdGVybmF0aXZlcyB0aGF0IHRoZXJlDQppcyBhIGNvbnNl bnN1cyB0byBzdXBwb3J0Lg0KDQpEbyB3ZSBoYXZlIGNvbnNlbnN1cyB0byBtb3ZlIGZvcndhcmQg d2l0aCBvcHRpb24gMT8NCg0KU3Rld2FydA0KDQoNCg0KT24gMDkvMTAvMjAxNSAxMzowMiwgSmlh bmd5dWFubG9uZyB3cm90ZToNCkhpIGFsbCwNCg0KV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbnMgb24g dGhpcyBtZWNoYW5pc20gd2hlbiB0aGUgZG9jdW1lbnQgd2FzIHN0aWxsIGFuIGluZGl2aWR1YWwg ZHJhZnQgKGluIGZhY3QsIHdoZW4gaXQgd2FzIGJlaW5nIHVwZGF0ZWQgdG8gZHJhZnQtamlhbmct bDJ2cG4tdnBscy1wZS1ldHJlZS0wMykuDQpKdXN0IGxpa2UgU3Rld2FydCwgc29tZSBzZXJ2aWNl IHByb3ZpZGVycyB3ZXJlIGFsc28gY29uY2VybmVkIHRoYXQgdGhpcyBtZWNoYW5pc20gbWF5IHJl c3VsdCBpbiBhIGdyZWF0IHdhc3RlIG9mIHBsYXRmb3JtIGxhYmVscy4gRm9yIGV4YW1wbGUsIGlu IGEgbmV0d29yayB3aXRoIG9uZSByb290IFBFIGFuZCAxMDAwIGxlYWYgUEVzLCBvbmx5IDEwMDEg UFcgbGFiZWxzIGFyZSBuZWVkZWQgZm9yIHRoZSBhcHByb2FjaCBpbiB0aGUgZG9jdW1lbnQ7IGJ1 dCB3ZSB3aWxsIG5lZWQgMTAwMCo5OTkvMj00OTk1MDAgUFcgbGFiZWxzIGluIGFsbCBmb3IgdGhl IHByb3Bvc2VkIG1lY2hhbmlzbSAoc2luY2UgbGVhZiB0byBsZWFmIFBXcyBhcmUgc3RpbGwgYWxs b2NhdGVkKS4gVGhhdCBpcyB0aGUgbWFpbiByZWFzb24gd2UgYWRvcHRlZCB0aGUgY3VycmVudCBh cHByb2FjaC4NClRoZXJlZm9yZSwgSSB3aWxsIHJlZ2FyZCBvcHRpb24gMSkgYXMgdGhlIGZhdm9y aXRlIHdheSBmb3J3YXJkOg0KMSkgTGVhdmUgdGhlIGRlc2lnbiBhcyBpdCBpcywgYnV0IGFkZCB0 ZXh0IHRvIGRlc2NyaWJlIHRoZSBjb25zdHJhaW50IGFuZA0Kd2hhdCBoYXBwZW5zIGlmIHlvdSBo YXZlIHRvIGNoYW5nZSBtb2RlIGFuZCB3aGF0IHRvIGRvIGFib3V0IGl0Lg0KDQpJIHdpbGwgYmUg Z2xhZCB0byBzZWUgbW9yZSBpbnB1dHMgdG8gdGhpcyB0b3BpYy4NCg0KVGhhbmtzLA0KWXVhbmxv bmcNCg0KDQoNCkZyb206IExpemhvbmcgSmluIFttYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbV0N ClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwNSwgMjAxNSAxOjA1IFBNDQpUbzogU3Rld2FydCBCcnlh bnQgKHN0YnJ5YW50KQ0KQ2M6IGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZUB0b29scy5p ZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlQHRvb2xzLmlldGYu b3JnPjsgcGFsc0BpZXRmLm9yZzxtYWlsdG86cGFsc0BpZXRmLm9yZz47IHBhbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnPG1haWx0bzpwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbUGFsc10gZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlIC0gcG9zc2libGUgd2F5 cyBmb3J3YXJkDQoNCkhpIFN0ZXdhcnQsDQpGb3IgRFUgbW9kZSwgaWYgRkVDIGlzIGNyZWF0ZWQs IHRoZW4gbGFiZWwgc2hvdWxkIGJlIGFsbG9jYXRlZC4gRm9yIHRoZSB2dWxuZXJhYmlsaXR5IHlv dSBtZW50aW9uZWQsIGlmIEkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uIGNvcnJlY3RseSwgdGhl IFBXIGxhYmVsIHdpbGwgbm90IGJlIHByb2dyYW1tZWQgaW50byBoYXJkd2FyZSwgYnV0IG9ubHkg a2VwdCBpbiBjb250cm9sIHBsYW5lLiBTbyB0aGUgcGFja2V0IHdpbGwgbm90IGJlIHdyb25nbHkg cHJvY2Vzc2VkLg0KVGhlIE1UVSBpbnRlcmZhY2UgU3ViLVRMViBkZWZpbmVkIGluIFJGQzQ0NDcg c2VjdGlvbiA2LjQgc2FpZDoNCg0KSWYgdGhpcyBwYXJhbWV0ZXIgZG9lcyBub3QgbWF0Y2gNCg0K ICAgICAgIGluIGJvdGggZGlyZWN0aW9ucyBvZiBhIHNwZWNpZmljIFBXLCB0aGF0IFBXIE1VU1Qg Tk9UIGJlIGVuYWJsZWQuDQpUaGUgbWVjaGFuaXNtIEkgcHJvcG9zZWQgaXMgd2hhdCBoYXZlIGJl ZW4gZG9uZSBmb3IgTVRVIGludGVyZmFjZSBzdWItVExWLg0KDQpSZWdhcmRzDQpMaXpob25nDQoN Ck9uIE1vbiwgT2N0IDUsIDIwMTUgYXQgMjoxOSBBTSwgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50 KSA8c3RicnlhbnRAY2lzY28uY29tPG1haWx0bzpzdGJyeWFudEBjaXNjby5jb20+PiB3cm90ZToN Cg0KDQoNCk9uIDQgT2N0IDIwMTUsIGF0IDE2OjQzLCBMaXpob25nIEppbiA8bGl6aG8uamluQGdt YWlsLmNvbTxtYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgU3Rld2FydCwN ClRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuIFRoaXMgaXMgYSBsb25nIGVtYWlsLg0KWW91IGdpdmUg dXMgdGhyZWUgb3B0aW9uczoNCg0KMSkgTGVhdmUgdGhlIGRlc2lnbiBhcyBpdCBpcywgYnV0IGFk ZCB0ZXh0IHRvIGRlc2NyaWJlIHRoZSBjb25zdHJhaW50IGFuZA0Kd2hhdCBoYXBwZW5zIGlmIHlv dSBoYXZlIHRvIGNoYW5nZSBtb2RlIGFuZCB3aGF0IHRvIGRvIGFib3V0IGl0Lg0KDQoyKSBFeGNs dWRlIG9wdGltaXphdGlvbiBpbiB0aGUgRkVDIFBXaWQoMHg4MCkgY2FzZQ0KDQozKSBBZGQgYW4g YXBwZW5kaXggZGVzY3JpYmluZyBzdXBwb3J0IGZvciB0aGUgRkVDIFBXaWQoMHg4MCkgY2FzZS4N Cg0KIFRoZW4gSSBwcmVmZXIgb3B0aW9uIDEuIEJlY2F1c2Ugb3B0aW9uMiBpcyBub3QgcmVhc29u YWJsZSwgYW5kIHRoZSBzb2x1dGlvbiBpbiBvcHRpb24zIHByb3ZpZGVkIGJ5IHRoZSBhdXRob3Ig aXMgbm90IHRoZSBiZXN0IG9uZS4NCg0KSSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgb3BpdGlvbjQg Zm9yIFdHIHRvIGNvbnNpZGVyOg0KNCkgQWRkIGRlc2NyaXB0aW9uIHRvIHN1cHBvcnQgZm9yIHRo ZSBGRUMgUFdpZCgweDgwKSBjYXNlLCBpbiBhcHBlbmRpeCBvciB0ZXh0IEkgZG9uJ3QgY2FyZS4g VGhlIHNvbHV0aW9uIGlzOg0KDQpsYWJlbCByZWxlYXNlIG1lc3NhZ2Ugc2hvdWxkIG5vdCBiZSBz ZW50IGluIHNlY3Rpb24gNi4xLg0KDQpGb3IgUFcgc2lnbmFsaW5nLCB0aGUgdW5hY2NlcHRhYmxl IG9mIGFueSBJbnRlcmZhY2UgUGFyYW1ldGVyIHdpbGwgbm90IGxlYWQgdG8gYW55DQoNCmxhYmVs IHJlbGVhc2UsIGJ1dCBqdXN0IHNpbXBseSBsZXQgdGhlIFBXIGRvd24gaW4gZm9yd2FyZGluZyBw bGFuZS4NCkxpc3RpbmcNCg0KRG9lc24ndCB0aGF0IHdhc3RlIGxhYmVscywgd2hpY2ggbWF5IGJl IGEgcHJvYmxlbSBpbiBzb21lIHN5c3RlbXMsIGFuZCBjcmVhdGUgYSB2dWxuZXJhYmlsaXR5IHNp bmNlIHNvbWVvbmUgbWF5IHNlbmQgYSBwYWNrZXQgd2l0aCB0aGF0IGxhYmVsIHdoaWNoIHdvdWxk IGJlIHByb2Nlc3NlZCBhbmQgc2VudCBvdXQgb2YgdGhlIHBlcnNvbiBlZ3Jlc3MuDQoNCi1TdGV3 YXJ0DQoNCg0KUmVnYXJkcw0KTGl6aG9uZw0KDQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tDQpGcm9tOiBTdGV3YXJ0IEJyeWFudCA8c3RicnlhbnRAY2lzY28uY29t PG1haWx0bzpzdGJyeWFudEBjaXNjby5jb20+Pg0KVG86ICJkcmFmdC1pZXRmLWwydnBuLXZwbHMt cGUtZXRyZWVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1l dHJlZUB0b29scy5pZXRmLm9yZz4iIDxkcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWVAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZUB0b29scy5p ZXRmLm9yZz4+LCAicGFsc0BpZXRmLm9yZzxtYWlsdG86cGFsc0BpZXRmLm9yZz4iIDxwYWxzQGll dGYub3JnPG1haWx0bzpwYWxzQGlldGYub3JnPj4NCkNjOiAicGFscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8bWFpbHRvOnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiIgPHBhbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnPG1haWx0bzpwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4+DQpEYXRlOiBG cmksIDIgT2N0IDIwMTUgMTY6NDE6MDUgKzAxMDANClN1YmplY3Q6IFtQYWxzXSBkcmFmdC1pZXRm LWwydnBuLXZwbHMtcGUtZXRyZWUgLSBwb3NzaWJsZSB3YXlzIGZvcndhcmQNCkkgYW0gc29ycnkg dGhhdCB0aGlzIGlzIGEgbG9uZyBlbWFpbCwgYnV0IEkgd2FudGVkIHRvIGNvbGxlY3QgdGhlDQpm YWN0cyB0b2dldGhlciBpbiBvbmUgcGxhY2UgYW5kIHNldCBvdXQgdGhlIGNvbXBsZXRlIHNjZW5l IHRvDQp0aGUgUEFMUyBXRy4NCg0KVGhlIGNyaXRpY2FsIGNvbmNlcm4gaXMgY29udGFpbmVkIGlu IHRoZSBmb2xsb3dpbmcgZW1haWwgZnJhZ21lbnQNCmZyb20gTGl6aG9uZzoNCg0KPT09PT09PQ0K SW4gUkZDNDQ0NyBhbmQgNDQ0N2JpcywgaXQgY2xlYXJseSBzYWlkOg0KDQpVc2luZyB0aGUgUFdp ZCBGRUMsIGVhY2ggb2YgdGhlIHR3byBwc2V1ZG93aXJlIGVuZHBvaW50cw0KDQogICBpbmRlcGVu ZGVudGx5IGluaXRpYXRlcyB0aGUgc2V0dXAgb2YgYSB1bmlkaXJlY3Rpb25hbCBMU1AuICAgQW4N Cg0KICAgb3V0Z29pbmcgTFNQIGFuZCBhbiBpbmNvbWluZyBMU1AgYXJlIGJvdW5kIHRvZ2V0aGVy IGludG8gYSBzaW5nbGUNCg0KICAgcHNldWRvd2lyZSBpZiB0aGV5IGhhdmUgdGhlIHNhbWUgUFcg SUQgIGFuZCBQVyB0eXBlLg0KDQpUaGUgYmVoYXZpb3IgaXMgYSBjb3JyZWN0IGRlc2NyaXB0aW9u IGZvciBMRFAtRFUgbW9kZSB3aGljaCBQVyBhcHBsaWVzLg0KDQpBbmQgdGhhdCBpcyBhbHNvIHRo ZSBiZWhhdmlvciBtb3N0IHZlbmRvcnMgaW1wbGVtZW50Lg0KDQoNCg0KVGhlbiBpbiBkcmFmdC1p ZXRmLWwydnBuLXZwbHMtcGUtZXRyZWUtMDksIGl0IHNheXM6DQoNCiBBIFBFIHRoYXQgcmVjZWl2 ZXMgYSBQVyBsYWJlbCBtYXBwaW5nIG1lc3NhZ2Ugd2l0aCBhbiBFLVRyZWUgU3ViLVRMVg0KDQog ICBmcm9tIGl0cyBwZWVyIFBFLCBhZnRlciBzYXZpbmcgdGhlIFZMQU4gaW5mb3JtYXRpb24gZm9y IHRoZSBQVywgTVVTVA0KDQogICBwcm9jZXNzIGl0IGFzIGZvbGxvd3M6DQoNCi4uLi4uDQoNCjMp IElmIHRoZSBQIGJpdCBpcyBzZXQNCg0KDQoNCiAgICAgIHsNCg0KDQoNCiAgICAgICAgICBJZiB0 aGUgUEUgaXMgYSBsZWFmLW9ubHkgbm9kZSBpdHNlbGYsIGEgbGFiZWwgcmVsZWFzZSBtZXNzYWdl DQoNCiAgICAgIHdpdGggYSBzdGF0dXMgY29kZSAiTGVhZiB0byBMZWFmIFBXIHJlbGVhc2VkIiBp cyBzZW50IHRvIHRoZSBwZWVyDQoNCiAgICAgIFBFIGFuZCBleGl0IHRoZSBwcm9jZXNzOw0KDQoN Cg0KICAgICAgICAgIEVsc2UgdGhlIFBFIFNIT1VMRCBzZXQgdGhlIE9wdGltaXplZC1Nb2RlIHRv IFRSVUUuDQoNCg0KDQogICAgICB9DQoNClRoYXQgbWVhbnMsIGlmIFBFMSByZWNlaXZpbmcgYSBs YWJlbCBtYXBwaW5nIGZyb20gUEUyIHdpdGggUCBiaXQgc2V0LA0KDQpQRTEgd2lsbCBzZW5kIGxh YmVsIHJlbGVhc2UuIFRoZW4gUEUyIHdpbGwgbmV2ZXIgc2VuZCBsYWJlbCBtYXBwaW5nDQoNCmFn YWluIHRvIFBFMSBldmVuIHdoZW4gUEUxIGNoYW5nZXMgZnJvbSBsZWFmLW9ubHkgbm9kZSB0byBy b290LWxlYWYgbm9kZS4gRm9yIExEUC1EVQ0KDQptb2RlLCBQRTIgd2lsbCBub3Qgc2VuZCBsYWJl bCBtYXBwaW5nIGFnYWluIHdoZW4gcmVjZWl2aW5nIFBFMSdzIGxhYmVsIG1hcHBpbmcuDQoNClRo ZW4gdGhlIFBXIHdpbGwgbm90IGJlIHNldHVwIHN1Y2Nlc3NmdWxseS4gVGhlbiBvbmx5IHdheSBp cyB0byBjb25maWd1cmUgdGhlDQoNCnNhbWUgUFcgb24gUEUyIGFnYWluLg0KDQpUaGUgY29ycmVj dCBiZWhhdmlvciBpcywgbGFiZWwgcmVsZWFzZSBtZXNzYWdlIHNob3VsZCBub3QgYmUgc2VudC4N Cg0KRm9yIFBXIHNpZ25hbGluZywgdGhlIHVuYWNjZXB0YWJsZSBvZiBhbnkgSW50ZXJmYWNlIFBh cmFtZXRlciB3aWxsIG5vdCBsZWFkIHRvIGFueQ0KDQpsYWJlbCByZWxlYXNlLCBidXQganVzdCBz aW1wbHkgbGV0IHRoZSBQVyBkb3duIGluIGZvcndhcmRpbmcgcGxhbmUuDQoNCg0KPT09PT09PT0N Cg0KQW5keSBsb29rZWQgYXQgdGhpcyBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBNRUYg YW5kIG5vdGVzIGluDQpwcml2YXRlIGNvbnZlcnNhdGlvbjoNCj09PT09PT09PQ0KSW4gdGhlIEUt dHJlZSBzZXJ2aWNlIGFzIGRlZmluZWQgYnkgTUVGLCB5b3UgY2FuIGhhdmUgb25lIG9yIG1vcmUg cm9vdHMNCmFuZCBvbmUgb3IgbW9yZSBsZWFmcy4NCg0KSW4gYSBzaW5nbGUgRS10cmVlIHNlcnZp Y2UgKHRoaW5rIG9mIGEgbXVsdGlwb2ludCBQVyB3aXRoIHNvbWUgb2YgdGhlIENFcw0KY29uZmln dXJlZCBhcyByb290cyBhcyBzb21lIGFzIGxlYWZzKSwgYWxsIGxlYWZzIGFuZCByb290cyByZWNl aXZlIGZyYW1lcw0Kc2VudCBieSB0aGUgcm9vdHMuIEFsbCByb290cyByZWNlaXZlIGZyYW1lcyBz ZW50IGJ5IHRoZSBsZWFmcy4gSG93ZXZlciwNCmxlYWZzIG1heSBub3QgcmVjZWl2ZSBhbnkgZnJh bWVzIHNlbnQgYnkgb3RoZXIgbGVhZnMuDQoNClRoZSBkcmFmdCwgYXMgd3JpdHRlbiwgZG9lc24n dCBicmluZyB1cCBhbiB1bmRlcmx5aW5nIHB0LXRvLXB0IFBXcyB0bw0KY2FycnkgZnJhbWVzIGZv ciB0aGUgc2VydmljZSBiZXR3ZWVuIFBFcyB0aGF0IG9ubHkgaGF2ZSBsZWFmcyBhdHRhY2hlZC4N ClNpbmNlIHRoZSBsZWFmcyBjYW4ndCBzZW50IGZyYW1lcyB0byBlYWNoIG90aGVyLCB0aGF0IGlz IGFuIGVjb25vbWljYWwNCnVzZSBvZiBQV3MgaW4gdGhlIG5ldHdvcmsuDQoNCkxpemhvbmcncyBw b2ludCBpcyB0aGF0IHRoaXMgbWFrZXMgaXQgaW1wb3NzaWJsZSB0byBhZGQgYSBuZXcgcm9vdCB0 bw0KYW4gZXhpc3RpbmcgUEUgaW4gYW4gRS10cmVlIHRoYXQgcHJldmlvdXNseSBvbmx5IGhhZCBs ZWFmcy4NCg0KSSBhZ3JlZSB0aGF0IHdvdWxkIGJlIGEgcHJvYmxlbSBpZiB0aGVyZSB3YXMgYSBy ZXF1aXJlbWVudCB0byBtb2RpZnkNCmFuIGV4aXN0aW5nIEUtdHJlZSBzZXJ2aWNlLiBIb3dldmVy LCB0aGlzIGRyYWZ0IGhhcyBubyBvdGhlciBtZWNoYW5pc21zDQp0byBleHBsaWNpdGx5IHN1cHBv cnQgRS10cmVlIG1vZGlmaWNhdGlvbiwgbm9yIGlzIHN1Y2ggbW9kaWZpY2F0aW9uIGENCnJlcXVp cmVtZW50IG9mIHRoZSB1bmRlcmx5aW5nIE1FRiBzcGVjaWZpY2F0aW9uLiBCVFcsIHNpbmNlIHRo aXMgd29yaw0Kd2FzIHN0YXJ0ZWQsIHRoZSBNRUYgcmVwbGFjZWQgTUVGIDYuMSB3aXRoIE1FRiA2 LjIsICJFVkMgRXRoZXJuZXQNClNlcnZpY2VzIERlZmluaXRpb25zIFBoYXNlIDMiLCBBdWd1c3Qs IDIwMTQsIGFuZCB0aGF0IHJlZmVyZW5jZSBzaG91bGQNCmJlIHVwZGF0ZWQgaW4gdGhlIGRyYWZ0 Lg0KTXkgb3BpbmlvbiBpcyB0aGF0IHRoZSBkcmFmdCBhcyBpdCBzdGFuZHMgaXMgdGVjaG5pY2Fs bHkgY29ycmVjdCBpZiB5b3UNCmRvbid0IG5lZWQgdGhlIGFiaWxpdHkgdG8gcmVjb25maWd1cmUg YW4gZXhpc3RpbmcgRS10cmVlIHNlcnZpY2UgZHluYW1pY2FsbHkuDQoNCj09PT09PT09PT0NCg0K Tm93IHdoaWxzdCBJIGNhbiBzdXBwb3J0IHRoZSBpZGVhIHRoYXQgZHluYW1pYyByZWNvbmZpZ3Vy YXRpb24gb2YNCkUtdHJlZSBpcyBub3QgbmVlZGVkLCBJIGhhdmUgYSBjb25jZXJuLg0KDQpNeSB1 bmRlcnN0YW5kaW5nIHRoZSB0ZXh0IGluIHF1ZXN0aW9uIGlzIHRoYXQgaXQgaXMgc2F5aW5nIHRo YXQgaWYNCkEgaXMgY29uZmlndXJlZCBhcyBsZWFmIG9ubHksIGFuZCBCIHdoaWNoIGlzIGFsc28g Y29uZmlndXJlZCBhcw0KbGVhZiBvbmx5IGF0dGVtcHRzIHRvIGNvbmZpZ3VyZSBhIFBXIGJldHdl ZW4gdGhlbSwgdGhlbiBBIHJlamVjdHMNCnRoZSBQVyBzZXR1cC4NCg0KVGhhdCBzb3VuZHMgdmVy eSByZWFzb25hYmxlIHRvIG1lLCBzaW5jZSB0aGVyZSBpcyBhIG1pc2NvbmZpZy4NCg0KSWYgQSBk aWQgbm90IGRvIHRoZSByZWplY3QsIHRoZW4gQiB3b3VsZCBmb3JldmVyIGJlIGNvbnN1bWluZw0K cmVzb3VyY2Ugd2FpdGluZyBmb3IgQSBhbmQgQiB3b3VsZCBoYXZlIG5vIGlkZWEgb2YgdGhlDQpt aXNjb25maWcuIFRoYXQgYWNjb3JkcyB3aXRoIEFuZHkncyB2aWV3IGFib3ZlLg0KDQpIb3dldmVy IEkgd2FzIHdvcnJpZWQgd2hhdCB3b3VsZCBoYXBwZW4gaWYgQSB3YXMgbWlzY29uZmlndXJlZA0K YXMgbGVhZiBvbmx5IGFuZCB0aGUgY29uZmlndXJhdGlvbiB3YXMgY29ycmVjdGVkIHRvIHJvb3Qt bGVhZi4NCldoYXQgd291bGQgaW4gbXkgdmlldyBiZSBkaWZmaWN1bHQgdG8gYWNjZXB0IHdhcyB0 aGUgbmVlZCB0bw0KdGFrZSBhIGh1bWFuLCBvciBOTVMgYWN0aW9uIGF0IEIgdG8gcmVjb3ZlciB0 aGUgc2l0dWF0aW9uLg0KSG93ZXZlciBwcm92aWRlZCB0aGF0IEEgY2xvc2VkIHRoZSBMRFAgc2Vz c2lvbiB3aXRoIEINCmFuZCByZS1pbnN0YXRlIGl0IEIgd291bGQgdGhlbiBzZW5kIHRoZSBtYXBw aW5nIG1lc3NhZ2UgYWdhaW4uDQpUaHVzIHRoZSBzeXN0ZW0gaXMgcmVjb3ZlcmFibGUgd2l0aG91 dCBuZWVkaW5nIHRvIHZpc2l0IEIgd2hpY2gNCmlzIGluIG15IG1pbmQgYSBmdW5kYW1lbnRhbCBy ZXF1aXJlbWVudCBzaW5jZSBBIGNvdWxkIGhhdmUNCmdvdCBpbnRvIHRoZSB3cm9uZyBtb2RlIGFz IGEgcmVzdWx0IG9mIGFuIGVycm9yLg0KDQpUaGUgcHJvYmxlbSBJIHNlZSBpcyBpZiBBIGhhcyBh IGJ1bmNoIG9mIG90aGVyIFBXcyB3aXRoIEINCnRoZXkgd2lsbCBnZXQgdG9ybiBkb3duIGluIG9y ZGVyIGZvciBBIHRvIGhhdmUgdGhlIGNvbmZpZyBlcnJvcg0KZml4ZWQuIEhvd2V2ZXIgaWYgdGhh dCBpcyBhIHByb2JsZW0geW91IG5lZWQgdHdvIExEUCBzZXNzaW9ucw0KYmV0d2VlbiBBIGFuZCBC LCBvbmUgZm9yIEwyVlBOIGFuZCBvbmUgZm9yIHJlZ3VsYXIgUFdzLg0KDQpNeSBpbmNsaW5hdGlv biBpcyB0aGF0IHRoZSBkcmFmdCBpcyBiYXNpY2FsbHkgY29ycmVjdCwgYW5kIHRoYXQgd2hpbHN0 DQpMaXpob25nIGlzIGNvcnJlY3QgdGhhdCB0aGUgUFcgd2lsbCBub3QgY29tZSB1cCB3aXRob3V0 IHNvbWUNCmFjdGlvbiwgcmVjb25maWd1cmluZyB0aGUgUFcgb24gQiBpcyBub3QgdGhlIG9ubHkg YWN0aW9uDQp0aGF0IHdpbGwgY2F1c2UgdGhlIFBXIHRvIGNvbWUgdXAuDQoNClNvIHRoaXMgY29t ZXMgZG93biB0byBhIFdHIGRlY2lzaW9uIGluIHRlcm1zIG9mIHdoaWNoIGlzIHRoZQ0KbGVhc3Qg dW5hY2NlcHRhYmxlIGJlaGF2aW91ciAtIEEgaGF2aW5nIHRvIHJlLWN5Y2xlIHRoZSBMRFANCnNl c3Npb24sIG9yIEIgd2FzdGluZyByZXNvdXJjZXMuIEkgdGhpbmsgSSBwcmVmZXIgdGhlIGJlaGF2 aW91cg0KcHJvcG9zZWQgaW4gdGhlIGRyYWZ0Lg0KDQpBIHdheSBmb3J3YXJkIGlzIHRvIGxlYXZl IHRoZSBsb2dpYyBhcyB3cml0dGVuIGluIHRoZSBkcmFmdCwgYnV0IHRvDQphZGQgdGV4dCBkZXNj cmliaW5nIHRoZSBiYXNpcyBmb3IgZXhjbHVkaW5nIGR5bmFtaWMgcmUtY29uZmlndXJhdGlvbg0K YXMgYSBub3JtYWwgb3BlcmF0aW9uYWwgbW9kZSBhbmQgdG8gbm90ZSB0aGUgYWN0aW9ucyB0aGF0 IG5lZWQNCnRvIGJlIHRha2VuIHdoZW4gcmUtY29uZmlndXJhdGlvbiBpcyBmb3JjZWQgZm9yIHNv bWUgcmVhc29uLg0KDQpXaGlsc3Qgd2Ugd2VyZSBwb25kZXJpbmcgd2hhdCBkbyB3aXRoIHRoZSB0 ZXh0IHRoZSBjaGFpcnMNCmFuZCBBRCByZWNlaXZlZCBhbm90aGVyIHByb3Bvc2FsIGZyb20gdGhl IGF1dGhvcnM6DQoNCj09PT09PQ0KDQpJbiBnZW5lcmFsLCBGRUMgUFdpZCgweDgwKSBpcyB1c2Vk IGluIFZQTFMgd2l0aCBtYW51YWwgcHJvdmlzaW9uaW5nLA0Kd2hpbGUgR2VuZXJhbGl6ZWQgUFdp ZCAoMHg4MSkgaXMgdXNlZCB3aXRoIGF1dG8tZGlzY292ZXJ5Lg0KDQpBcyBkaXNjdXNzZWQgaW4g U2VjdGlvbiA1LjIsIFZMQU4gbWFwcGluZyBwYXJhbWV0ZXJzIGNhbiBiZSBwcm92aXNpb25lZA0K d2l0aG91dCBhIHNpZ25hbGluZyBwcm90b2NvbCwgT3B0aW1pemVkIE1vZGUgY2FuIGFsc28gYmUg YSBwYXJhbWV0ZXINCnRvIGJlIHByb3Zpc2lvbmVkLg0KDQpUaGUgYXBwcm9hY2ggd2XigJl2ZSB0 YWtlbiBpbiB0aGUgY3VycmVudCBkcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWUtMDkNCmRv ZXMgYWxsb3cgdGhpcy4gUXVpdGUgYSBmZXcgc2VydmljZSBwcm92aWRlcnMgbWF5IHByZWZlciB0 byBjb250cm9sDQphbGwgdGhlc2UgRS1UcmVlIGNvbm5lY3Rpdml0eSBieSB0aGVtc2VsdmVzLg0K DQpXaGVuIEUtVHJlZSBzaWduYWxpbmcgcHJvdG9jb2wgZm9yIFBXaWQgRkVDIGlzIGNvbnNpZGVy ZWQsIHRoZSBmb2xsb3dpbmcNCm9wdGlvbnMgYXJlIGFsc28gZmVhc2libGU6DQoNCmEpICAgICAg IERpc2FibGUgT3B0aW1pemVkIG1vZGUgZm9yIEZFQyBQV2lkKDB4ODApLCB0aHVzIHJvb3QvbGVh ZiByb2xlDQpjaGFuZ2UgaW4gdGhlIEUtVHJlZSB0b3BvbG9neSB3aWxsIG5vdCBoYXZlIGFueSBp bmZsdWVuY2Ugb24gdGhlIFBXLg0KDQpiKSAgICAgICBBZGQgYW5vdGhlciBhcHBlbmRpeCBpbnRv IHRoZSBkb2N1bWVudCBmb3IgdGhlIGZ1bGwgc3VwcG9ydCBvZg0KT3B0aW1pemVkIG1vZGUgd2l0 aCBGRUMgUFdpZCgweDgwKS4NCg0KVGhlIGlkZWEgaXM6IHRoZSBQRSBzZW5kcyBhIGxhYmVsIG1h cHBpbmcgZmlyc3RseSBhbmQgdGhlbiBzZW5kIGEgbGFiZWwNCnJlcXVlc3QgdG8gaXRzIHBlZXIg UEVzIChzbyB0aGF0IHRoZXkgd2lsbCByZXBseSB3aXRoIGEgbGFiZWwgbWFwcGluZw0KcmVzcGVj dGl2ZWx5KS4NCg0KU2luY2UgT3B0aW1pemVkIG1vZGUgaXMgYW4gb3B0aW9uYWwgcGllY2UgaW4g dGhlIGRvY3VtZW50LCBJIHdvdWxkDQpyZWdhcmQgb3B0aW9uIGEpIGFzIGEgc2ltcGxlIHRyYWRl b2ZmIChhcyBJIGFtIGF3YXJlLCBFLVZQTiBkb2VzIG5vdA0Kc3VwcG9ydCBPcHRpbWl6ZWQgbW9k ZSBmb3IgRS1UcmVlIGVpdGhlci4NCg0KPT09PT09PT0NCg0KDQpUaHVzIHdlIGhhdmUgdGhyZWUg cHJvcG9zYWxzIG9uIHRoZSB0YWJsZToNCg0KMSkgTGVhdmUgdGhlIGRlc2lnbiBhcyBpdCBpcywg YnV0IGFkZCB0ZXh0IHRvIGRlc2NyaWJlIHRoZSBjb25zdHJhaW50IGFuZA0Kd2hhdCBoYXBwZW5z IGlmIHlvdSBoYXZlIHRvIGNoYW5nZSBtb2RlIGFuZCB3aGF0IHRvIGRvIGFib3V0IGl0Lg0KDQoy KSBFeGNsdWRlIG9wdGltaXphdGlvbiBpbiB0aGUgRkVDIFBXaWQoMHg4MCkgY2FzZQ0KDQozKSBB ZGQgYW4gYXBwZW5kaXggZGVzY3JpYmluZyBzdXBwb3J0IGZvciB0aGUgRkVDIFBXaWQoMHg4MCkg Y2FzZS4NCg0KTXkgaW5jbGluYXRpb24gd291bGQgYmUgdG8gZ28gd2l0aCBvcHRpb24gKDEpIGJ1 dCBJIHNlZWsgdGhlIHZpZXdzIG9mDQp0aGUgV0csIGFuZCBvZiBjb3Vyc2UgYW55IGNvcnJlY3Rp b25zIGluIG15IGFuYWx5c2lzLg0KDQotIFN0ZXdhcnQNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClBhbHMgbWFpbGluZyBsaXN0DQpQYWxzQGlldGYu b3JnPG1haWx0bzpQYWxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wYWxzDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpQYWxzIG1haWxpbmcgbGlzdA0KDQpQYWxzQGlldGYub3JnPG1h aWx0bzpQYWxzQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3BhbHMNCg0KDQoNCg0KDQotLQ0KDQpGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9u IGdvIHRvOg0KDQoNCg0KaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2lu ZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sDQoNCg0K --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B68283796szxema506mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDExMThBLjQ4RjZBREUwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpUYXJnZXRTY3JlZW5TaXpl PjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5n cz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERv Y3VtZW50Pg0KPHc6Wm9vbT4xMjA8L3c6Wm9vbT4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6 U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3 OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1M SW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50 PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRl eHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFG Lz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1l QXNpYW4+WkgtQ048L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5Y LU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRv Tm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0 UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4NCjx3OkRv bnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25JblR4Yngv Pg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hlZENvbEJhbGFuY2UvPg0KPHc6VXNl RkVMYXlvdXQvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0 SW50ZXJuZXRFeHBsb3JlcjQ8L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFByPg0KPG06bWF0aEZv bnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxt OmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0K PG06ZGlzcERlZi8+DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIw Ii8+DQo8bTpkZWZKYyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9 IjE0NDAiLz4NCjxtOmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1 bmRPdnIiLz4NCjwvbTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRl PSJmYWxzZSIgRGVmVW5oaWRlV2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERl ZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1h bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIE5hbWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIxMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExp c3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gTGlzdCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNl IFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i Q29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBH cmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBH cmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjE5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2Ui Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Iklu dGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjMzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFk aW5nIi8+DQo8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0N Ci8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2T Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtYWx0OlNpbVN1bjsN Cgltc28tZm9udC1jaGFyc2V0OjEzNDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0K CW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTozIDY4MDQ2MDI4 OCAyMiAwIDI2MjE0NSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjE7 DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtZm9ybWF0Om90aGVy Ow0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTowIDAgMCAw IDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZv bnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNp Z25hdHVyZTotNTIwMDkyOTI5IDEwNzM3ODYxMTEgOSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1z by1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28t Zm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA4MTY2NSAtMTA3 MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovk vZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtY2hhcnNldDox MzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2YXJp YWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAyNjIxNDUgMDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4gXDtjb2xvclw6XCMxRjQ5 N0QiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDow Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1zby1mb250LWZvcm1hdDpvdGhl cjsNCgltc28tZm9udC1waXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25hdHVyZTowIDAgMCAwIDAg MDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0 OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseTrlrovkvZM7 DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt bm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwcmUNCgl7bXNvLXN0eWxlLW5v c2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZTo5 LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk65a6L5L2T Ow0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCgltc28tY2hhci1p bmRlbnQtY291bnQ6Mi4wOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZhbWlseTrl rovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tl ZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tZm9udC1rZXJuaW5nOjBwdDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsN Cgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJbXNvLWFuc2ktZm9udC1zaXplOjku MHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJ bXNvLWFzY2lpLWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTrl rovkvZM7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28tYmlkaS1mb250LWZh bWlseTrlrovkvZM7DQoJbXNvLWZvbnQta2VybmluZzowcHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTAuNXB0Ow0KCW1zby1iaWRp LWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTrlrovkvZM7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC41 cHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OuWui+S9kzsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1k ZWZhdWx0LXByb3BzOnllczsNCglmb250LXNpemU6MTAuMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYXNjaWktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1mb250LWtlcm5pbmc6MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM2LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNi4w cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6MjcxMDYwNTczOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxMTc3MDkwMzE2IC0yMDc0MzIwNjQyIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTkwMDU1ODIwOTsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTkyOTc4NDQ4NiAxODU1NjMwNjMyIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6LTU0LjBwdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+ LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHls ZS1uYW1lOuaZrumAmuihqOagvDsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10 c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50 OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowY20gNS40cHQgMGNtIDUuNHB0Ow0KCW1zby1wYXJhLW1h cmdpbjowY207DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0 aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0i dGFiLWludGVydmFsOjIxLjBwdCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kztt c28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFG NDk3RCI+U3Rld2FydCBhbmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28t YmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHdvdWxkIGxpa2Ug dG8gdXBkYXRlIHRoZSBkcmFmdCB3aXRoIHRoZSBmb2xsb3dpbmcNCiBjaGFuZ2VzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWNoYXItaW5kZW50LWNvdW50OjA7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250 LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVwZGF0ZSB0aGUgcmVmZXJlbmNlDQo8c3BhbiBzdHlsZT0i bXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7PC9zcGFuPuKAnFtNRUY2LjFd4oCdIHRvIOKAnFtNRUY2 LjJd4oCdLCBhbmQgcmVwbGFjZSDigJw8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+W01FRjYuMV08c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+ Jm5ic3A7IDwvc3Bhbj5NZXRybyBFdGhlcm5ldCBGb3J1bSwgJnF1b3Q7RXRoZXJuZXQgU2Vydmlj ZXMgRGVmaW5pdGlvbnMgLVBoYXNlIDImcXVvdDssIFRlY2huaWNhbCBTcGVjaWZpY2F0aW9uIE1F RiA2LjEsIEFwcmlsIDIwMDgu4oCdIHdpdGgg4oCcW01FRjYuMl0gTWV0cm8gRXRoZXJuZXQgRm9y dW0sICZxdW90O0VWQyBFdGhlcm5ldCBTZXJ2aWNlcyBEZWZpbml0aW9ucyBQaGFzZSAzJnF1b3Q7 LCBUZWNobmljYWwNCiBTcGVjaWZpY2F0aW9uIE1FRiA2LjIsIEF1Z3VzdCAyMDE0LuKAnTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWNoYXItaW5kZW50LWNvdW50OjA7bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovk vZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkFkZCB0aGUgZm9sbG93aW5nIHRleHRzIHRvIHRoZSBlbmQgb2YgU2VjdGlvbg0K IDYuMTo8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7IDwvc3Bhbj7igJxXaGVu IFZQTFMgaXMgc2V0IHVwIHVzaW5nIFBXaWQgRkVDIEVsZW1lbnQgKHNlZSBBcHBlbmRpeCBBIG9m IFtSRkM0NzYyXSksIGl0cyBFLVRyZWUgc2lnbmFsaW5nIGlzIHNpbWlsYXIgdG8gdGhlIGFib3Zl IHByb2Nlc3MuIER5bmFtaWMgcmUtY29uZmlndXJhdGlvbiBvZiBFLVRyZWUgc2hvdWxkIGJlIGF2 b2lkZWQgZm9yIHRoaXMgY2FzZSwgaG93ZXZlciwgd2hlbiByZS1jb25maWd1cmF0aW9uDQogb2Yg RS1UcmVlIGlzIGZvcmNlZCBvbiBhIFBFIGZvciBzb21lIHJlYXNvbiAoZS5nLiwgYSBjb25maWd1 cmF0aW9uIGVycm9yKSwgdGhlIFBFIG1heSBjbG9zZSB0aGUgTERQIHNlc3Npb24gd2l0aCBpdHMg cGVlciBQRXMgZm9yIHRoaXMgVlBMUyBpbnN0YW5jZSwgYW5kIHJlLWluc3RhbGwgaXRzIFBXIGxh YmVscywgc28gdGhhdCBpdHMgcGVlciBQRXMgY2FuIHNlbmQgb3V0IHRoZSBMRFAgbGFiZWwgbWFw cGluZyBtZXNzYWdlIGFnYWluLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28t YmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkEgbmV3IHZlcnNpb24gd2lsbCBiZSBzdWJtaXR0ZWQgb25jZSB0aGUgSUVURiBzaXRlDQogaXMg cmVvcGVuZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW55IG90aGVyIG9w aW5pb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFz dC1mb250LWZhbWlseTrlrovkvZM7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OuWui+S9kzttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDs7Y29sb3I6IzFGNDk3RCI+WXVhbmxvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTpp bnRlci1pZGVvZ3JhcGg7bXNvLXBhZ2luYXRpb246bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk65a6L5L2TO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mb250LWtlcm5pbmc6MS4wcHQ7bXNvLW5v LXByb29mOnllcyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TO21z by1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBw dDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPg0KIFN0 ZXdhcnQgQnJ5YW50IFttYWlsdG86c3RicnlhbnRAY2lzY28uY29tXSA8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAyMDE1IDExOjUzIFBNPGJyPg0KPGI+VG86PC9iPiBT dGV3YXJ0IEJyeWFudDsgSmlhbmd5dWFubG9uZzsgTGl6aG9uZyBKaW48YnI+DQo8Yj5DYzo8L2I+ IHBhbHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWwy dnBuLXZwbHMtcGUtZXRyZWVAdG9vbHMuaWV0Zi5vcmc7IFN0ZXdhcnQgQnJ5YW50PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbUGFsc10gZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlIC0g cG9zc2libGUgd2F5cyBmb3J3YXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBh cmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1V UyI+SSBoYXZlIGhlYXJkIG5vdGhpbmcgYmFjayBmcm9tIHRoZSBncm91cCwgYW5kIHNvIEkgYXNz dW1lIHRoYXQgdGhpczxicj4NCmlzIGFuIGFjY2VwdGFibGUgd2F5IGZvcndhcmQuPGJyPg0KPGJy Pg0KUGxlYXNlIHdpbGwgdGhlIGF1dGhvcnMgbWFrZSB0aGUgbmVjZXNzYXJ5IHVwZGF0ZXMgdG8g dGhlIHRleHQuPGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCjxicj4NClN0ZXdhcnQ8YnI+DQo8YnI+ DQo8YnI+DQpPbiAwOS8xMC8yMDE1IDEzOjM0LCBTdGV3YXJ0IEJyeWFudCB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3Bh biBsYW5nPSJFTi1VUyI+PGJyPg0KRnJvbSBteSBwZXJzcGVjdGl2ZSwgYW5kIHdpdGggZHVlIHJl Z2FyZCBhcyB0byB3aGVyZSB3ZSBhcmUsJm5ic3A7IG9wdGlvbiBvbmU8YnI+DQppcyB0aGUgb25l IHRoYXQgSSB3b3VsZCBwcmVmZXIgdG8gbW92ZSB0aGluZ3MgYWxvbmcuPGJyPg0KPGJyPg0KVGhh dCB3b3VsZCBub3QgcHJlY2x1ZGUgdXMgaW50cm9kdWNpbmcgYW5vdGhlciBSRkMgYXQgYSBsYXRl ciBkYXRlIGlmPGJyPg0KdGhlcmUgYXJlIGZ1cnRoZXIgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlv bnMgb3IgYWx0ZXJuYXRpdmVzIHRoYXQgdGhlcmU8YnI+DQppcyBhIGNvbnNlbnN1cyB0byBzdXBw b3J0Ljxicj4NCjxicj4NCkRvIHdlIGhhdmUgY29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCB3aXRo IG9wdGlvbiAxPzxicj4NCjxicj4NClN0ZXdhcnQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAw OS8xMC8yMDE1IDEzOjAyLCBKaWFuZ3l1YW5sb25nIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEu MHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuIFw7Y29sb3JcOlwjMUY0OTdEJnF1b3Q7Ij5I aSBhbGwsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1h cmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuIFw7Y29sb3JcOlwjMUY0OTdEJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdk Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9u dC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4g XDtjb2xvclw6XCMxRjQ5N0QmcXVvdDsiPldlIGhhZCBzb21lIGRpc2N1c3Npb25zIG9uIHRoaXMg bWVjaGFuaXNtIHdoZW4gdGhlIGRvY3VtZW50DQogd2FzIHN0aWxsIGFuIGluZGl2aWR1YWwgZHJh ZnQgKGluIGZhY3QsIHdoZW4gaXQgd2FzIGJlaW5nIHVwZGF0ZWQgdG8gZHJhZnQtamlhbmctbDJ2 cG4tdnBscy1wZS1ldHJlZS0wMykuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEu MHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuIFw7Y29sb3JcOlwjMUY0OTdEJnF1b3Q7Ij5K dXN0IGxpa2UgU3Rld2FydCwgc29tZSBzZXJ2aWNlIHByb3ZpZGVycyB3ZXJlIGFsc28gY29uY2Vy bmVkDQogdGhhdCB0aGlzIG1lY2hhbmlzbSBtYXkgcmVzdWx0IGluIGEgZ3JlYXQgd2FzdGUgb2Yg cGxhdGZvcm0gbGFiZWxzLiBGb3IgZXhhbXBsZSwgaW4gYSBuZXR3b3JrIHdpdGggb25lIHJvb3Qg UEUgYW5kIDEwMDAgbGVhZiBQRXMsIG9ubHkgMTAwMSBQVyBsYWJlbHMgYXJlIG5lZWRlZCBmb3Ig dGhlIGFwcHJvYWNoIGluIHRoZSBkb2N1bWVudDsgYnV0IHdlIHdpbGwgbmVlZCAxMDAwKjk5OS8y PTQ5OTUwMCBQVyBsYWJlbHMgaW4gYWxsIGZvciB0aGUgcHJvcG9zZWQNCiBtZWNoYW5pc20gKHNp bmNlIGxlYWYgdG8gbGVhZiBQV3MgYXJlIHN0aWxsIGFsbG9jYXRlZCkuIFRoYXQgaXMgdGhlIG1h aW4gcmVhc29uIHdlIGFkb3B0ZWQgdGhlIGN1cnJlbnQgYXBwcm9hY2guPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6 ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuIFw7Y29s b3JcOlwjMUY0OTdEJnF1b3Q7Ij5UaGVyZWZvcmUsIEkgd2lsbCByZWdhcmQgb3B0aW9uIDEpIGFz IHRoZSBmYXZvcml0ZSB3YXkNCiBmb3J3YXJkOiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDttc28t YmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4gXDtjb2xvclw6XCMxRjQ5N0Qm cXVvdDsiPjEpIExlYXZlIHRoZSBkZXNpZ24gYXMgaXQgaXMsIGJ1dCBhZGQgdGV4dCB0byBkZXNj cmliZQ0KIHRoZSBjb25zdHJhaW50IGFuZDxicj4NCndoYXQgaGFwcGVucyBpZiB5b3UgaGF2ZSB0 byBjaGFuZ2UgbW9kZSBhbmQgd2hhdCB0byBkbyBhYm91dCBpdC48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNo YXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2lmICFzdXBwb3J0TGluZUJyZWFrTmV3TGluZV0+PGJy IHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8IVtlbmRpZl0+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0 OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O21zby1i aWRpLWZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuIFw7Y29sb3JcOlwjMUY0OTdEJnF1b3Q7Ij5JIHdpbGwgYmUgZ2xhZCB0byBzZWUgbW9y ZSBpbnB1dHMgdG8gdGhpcyB0b3BpYy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoy MS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4gXDtjb2xvclw6XCMxRjQ5N0QmcXVvdDsi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1t YXJnaW4tbGVmdDoxLjc1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiBcO2NvbG9yXDpcIzFGNDk3RCZxdW90OyI+VGhhbmtzLDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1 Z2Q7dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7bXNvLXBh Z2luYXRpb246bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4gXDtjb2xvclw6XCMxRjQ5N0QmcXVvdDsiPll1YW5sb25nPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVn ZDt0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDttc28tcGFn aW5hdGlvbjpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2lmICFzdXBw b3J0TGluZUJyZWFrTmV3TGluZV0+PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGlu ZS1icmVhayI+DQo8IVtlbmRpZl0+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEu MHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuIFw7Y29sb3JcOlwjMUY0OTdEJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2Q7bXNvLW91dGxpbmUtbGV2 ZWw6MSI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMaXpo b25nIEppbiBbPGEgaHJlZj0ibWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb20iPm1haWx0bzpsaXpo by5qaW5AZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIg MDUsIDIwMTUgMTowNSBQTTxicj4NCjxiPlRvOjwvYj4gU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50 KTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbDJ2cG4tdnBscy1w ZS1ldHJlZUB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlQHRv b2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpwYWxzQGlldGYub3JnIj5wYWxzQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIj4N CnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1BhbHNdIGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZSAtIHBvc3NpYmxlIHdheXMgZm9y d2FyZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVT Ij5IaSBTdGV3YXJ0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMu NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIERVIG1vZGUsIGlmIEZFQyBpcyBjcmVhdGVkLCB0 aGVuIGxhYmVsIHNob3VsZCBiZSBhbGxvY2F0ZWQuIEZvciB0aGUgdnVsbmVyYWJpbGl0eSB5b3Ug bWVudGlvbmVkLCBpZiBJIHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbiBjb3JyZWN0bHksIHRoZSBQ VyBsYWJlbCB3aWxsIG5vdA0KIGJlIHByb2dyYW1tZWQgaW50byBoYXJkd2FyZSwgYnV0IG9ubHkg a2VwdCBpbiBjb250cm9sIHBsYW5lLiBTbyB0aGUgcGFja2V0IHdpbGwgbm90IGJlIHdyb25nbHkg cHJvY2Vzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxl ZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgTVRVIGludGVyZmFjZSBTdWItVExWIGRl ZmluZWQgaW4gUkZDNDQ0NyBzZWN0aW9uIDYuNCBzYWlkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1t YXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5JZiB0aGlzIHBhcmFtZXRlciBkb2VzIG5vdCBtYXRjaDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo0 Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+aW4gYm90aCBkaXJlY3Rpb25z IG9mIGEgc3BlY2lmaWMgUFcsIHRoYXQgUFcgTVVTVCBOT1QgYmUgZW5hYmxlZC48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxl ZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgbWVjaGFuaXNtIEkgcHJvcG9zZWQgaXMg d2hhdCBoYXZlIGJlZW4gZG9uZSBmb3IgTVRVIGludGVyZmFjZSBzdWItVExWLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdp bi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVT Ij5MaXpob25nPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2Qi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1t YXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgT2N0IDUsIDIwMTUg YXQgMjoxOSBBTSwgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnN0YnJ5YW50QGNpc2NvLmNvbSI+c3RicnlhbnRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206MTIuMHB0O21hcmdpbi1sZWZ0OjQyLjBwdDttc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21zby1w YXJhLW1hcmdpbi1yaWdodDowY207bXNvLXBhcmEtbWFyZ2luLWJvdHRvbToxMi4wcHQ7bXNvLXBh cmEtbWFyZ2luLWxlZnQ6My41Z2QiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjQyLjBwdDttc28tbWFy Z2luLXRvcC1hbHQ6MGNtO21zby1wYXJhLW1hcmdpbi1yaWdodDowY207bXNvLXBhcmEtbWFyZ2lu LWJvdHRvbToxMi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPg0KPHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCk9uIDQgT2N0IDIwMTUsIGF0IDE2OjQzLCBMaXpob25nIEppbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmxpemhvLmppbkBnbWFpbC5jb20iPmxpemhvLmppbkBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1V UyI+SGkgU3Rld2FydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdp bi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciB0aGUgY29tbWVudC4g VGhpcyBpcyBhIGxvbmcgZW1haWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFy YS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSBnaXZlIHVzIHRocmVl IG9wdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVm dDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij48YnI+ DQoxKSBMZWF2ZSB0aGUgZGVzaWduIGFzIGl0IGlzLCBidXQgYWRkIHRleHQgdG8gZGVzY3JpYmUg dGhlIGNvbnN0cmFpbnQgYW5kPGJyPg0Kd2hhdCBoYXBwZW5zIGlmIHlvdSBoYXZlIHRvIGNoYW5n ZSBtb2RlIGFuZCB3aGF0IHRvIGRvIGFib3V0IGl0Ljxicj4NCjxicj4NCjIpIEV4Y2x1ZGUgb3B0 aW1pemF0aW9uIGluIHRoZSZuYnNwO0ZFQyBQV2lkKDB4ODApIGNhc2U8YnI+DQo8YnI+DQozKSBB ZGQgYW4gYXBwZW5kaXggZGVzY3JpYmluZyBzdXBwb3J0IGZvciB0aGUmbmJzcDtGRUMgUFdpZCgw eDgwKSBjYXNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41 Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDtUaGVuIEkgcHJlZmVyIG9wdGlvbiAxLiBCZWNh dXNlIG9wdGlvbjIgaXMgbm90IHJlYXNvbmFibGUsIGFuZCB0aGUgc29sdXRpb24gaW4gb3B0aW9u MyBwcm92aWRlZCBieSB0aGUgYXV0aG9yIGlzIG5vdCB0aGUgYmVzdCBvbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2lu LWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBv cGl0aW9uNCBmb3IgV0cgdG8gY29uc2lkZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDtt c28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjQpJm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+QWRkIGRlc2Ny aXB0aW9uIHRvIHN1cHBvcnQgZm9yIHRoZSZuYnNwO0ZFQyBQV2lkKDB4ODApIGNhc2UsIGluIGFw cGVuZGl4IG9yIHRleHQgSSBkb24ndCBjYXJlLiBUaGUgc29sdXRpb24gaXM6PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6NS4yNWdkIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bGFiZWwgcmVsZWFzZSBtZXNz YWdlIHNob3VsZCBub3QgYmUgc2VudCBpbiBzZWN0aW9uIDYuMS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBQVyBzaWduYWxpbmcsIHRoZSB1bmFjY2VwdGFibGUgb2Yg YW55IEludGVyZmFjZSBQYXJhbWV0ZXIgd2lsbCBub3QgbGVhZCB0byBhbnkgPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5sYWJlbCByZWxlYXNlLCBidXQganVzdCBzaW1wbHkg bGV0IHRoZSBQVyBkb3duIGluIGZvcndhcmRpbmcgcGxhbmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNw YW4gbGFuZz0iRU4tVVMiPkxpc3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkRvZXNuJ3QgdGhhdCB3YXN0ZSBsYWJlbHMsIHdoaWNoIG1heSBiZSBhIHByb2Js ZW0gaW4gc29tZSBzeXN0ZW1zLCBhbmQgY3JlYXRlIGEgdnVsbmVyYWJpbGl0eSBzaW5jZSBzb21l b25lIG1heSBzZW5kIGEgcGFja2V0IHdpdGggdGhhdCBsYWJlbCB3aGljaCB3b3VsZCBiZSBwcm9j ZXNzZWQNCiBhbmQgc2VudCBvdXQgb2YgdGhlIHBlcnNvbiBlZ3Jlc3MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2Qi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LVN0ZXdhcnQ8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21z by1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyIHN0eWxlPSJt c28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8IVtpZiAhc3VwcG9ydExpbmVCcmVh a05ld0xpbmVdPjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0K PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBw dDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48 c3BhbiBsYW5nPSJFTi1VUyI+TGl6aG9uZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNv LXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtt c28tYm9yZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkO21zby1vdXRsaW5lLWxl dmVsOjEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1l c3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206Jm5ic3A7U3Rld2FydCBCcnlhbnQgJmx0OzxhIGhy ZWY9Im1haWx0bzpzdGJyeWFudEBjaXNjby5jb20iPnN0YnJ5YW50QGNpc2NvLmNvbTwvYT4mZ3Q7 PGJyPg0KVG86Jm5ic3A7JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbDJ2cG4tdnBs cy1wZS1ldHJlZUB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtbDJ2 cG4tdnBscy1wZS1ldHJlZUB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWVAdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5kcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWVAdG9vbHMuaWV0Zi5vcmc8 L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86cGFsc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnBhbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGFsc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhbHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNjOiZu YnNwOyZxdW90OzxhIGhyZWY9Im1haWx0bzpwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cGFscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6Jm5ic3A7RnJpLCAy IE9jdCAyMDE1IDE2OjQxOjA1ICYjNDM7MDEwMDxicj4NClN1YmplY3Q6Jm5ic3A7W1BhbHNdIGRy YWZ0LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZSAtIHBvc3NpYmxlIHdheXMgZm9yd2FyZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJF Ti1VUyI+SSBhbSBzb3JyeSB0aGF0IHRoaXMgaXMgYSBsb25nIGVtYWlsLCBidXQgSSB3YW50ZWQg dG8gY29sbGVjdCB0aGUNCjxicj4NCmZhY3RzIHRvZ2V0aGVyIGluIG9uZSBwbGFjZSBhbmQgc2V0 IG91dCB0aGUgY29tcGxldGUgc2NlbmUgdG8gPGJyPg0KdGhlIFBBTFMgV0cuPGJyPg0KPGJyPg0K VGhlIGNyaXRpY2FsIGNvbmNlcm4gaXMgY29udGFpbmVkIGluIHRoZSBmb2xsb3dpbmcgZW1haWwg ZnJhZ21lbnQ8YnI+DQpmcm9tIExpemhvbmc6PGJyPg0KPGJyPg0KPT09PT09PTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NjMu MHB0O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1wYXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SW4gUkZDNDQ0 NyBhbmQgNDQ0N2JpcywgaXQgY2xlYXJseSBzYWlkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0 OjUuMjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Vc2lu ZyB0aGUgUFdpZCBGRUMsIGVhY2ggb2YgdGhlIHR3byBwc2V1ZG93aXJlIGVuZHBvaW50czwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6NS4yNWdkIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBpbmRlcGVu ZGVudGx5IGluaXRpYXRlcyB0aGUgc2V0dXAgb2YgYSB1bmlkaXJlY3Rpb25hbCBMU1AuJm5ic3A7 Jm5ic3A7IEFuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1 LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7 Jm5ic3A7IG91dGdvaW5nIExTUCBhbmQgYW4gaW5jb21pbmcgTFNQIGFyZSBib3VuZCB0b2dldGhl ciBpbnRvIGEgc2luZ2xlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4t bGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jm5ic3A7Jm5ic3A7IHBzZXVkb3dpcmUgaWYgdGhleSBoYXZlIHRoZSBzYW1lIFBXIElEICZuYnNw O2FuZCBQVyB0eXBlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxl ZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRo ZSBiZWhhdmlvciBpcyBhIGNvcnJlY3QgZGVzY3JpcHRpb24gZm9yIExEUC1EVSBtb2RlIHdoaWNo IFBXIGFwcGxpZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVm dDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QW5k IHRoYXQgaXMgYWxzbyB0aGUgYmVoYXZpb3IgbW9zdCB2ZW5kb3JzIGltcGxlbWVudC48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGVuIGluIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ZHJhZnQtaWV0Zi1sMnZwbi12 cGxzLXBlLWV0cmVlLTA5LCBpdCBzYXlzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBh cmEtbWFyZ2luLWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiBBIFBFIHRoYXQgcmVjZWl2ZXMgYSBQVyBsYWJlbCBtYXBwaW5nIG1lc3NhZ2Ug d2l0aCBhbiBFLVRyZWUgU3ViLVRMVjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBhcmEt bWFyZ2luLWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOyZuYnNwOyBmcm9tIGl0cyBwZWVyIFBFLCBhZnRlciBzYXZpbmcgdGhlIFZM QU4gaW5mb3JtYXRpb24gZm9yIHRoZSBQVywgTVVTVDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7 bXNvLXBhcmEtbWFyZ2luLWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBwcm9jZXNzIGl0IGFzIGZvbGxvd3M6PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Li4uLi48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4zKSBJZiB0aGUgUCBiaXQgaXMgc2V0PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIFBFIGlzIGEgbGVhZi1vbmx5IG5v ZGUgaXRzZWxmLCBhIGxhYmVsIHJlbGVhc2UgbWVzc2FnZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4w cHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoIGEg c3RhdHVzIGNvZGUgJnF1b3Q7TGVhZiB0byBMZWFmIFBXIHJlbGVhc2VkJnF1b3Q7IGlzIHNlbnQg dG8gdGhlIHBlZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NjMuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0 OjUuMjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUEUgYW5kIGV4aXQgdGhlIHByb2Nlc3M7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVsc2UgdGhlIFBFIFNIT1VMRCBzZXQgdGhlIE9wdGlt aXplZC1Nb2RlIHRvIFRSVUUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJn aW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDo1 LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NjMuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5UaGF0IG1lYW5zLCBpZiBQRTEgcmVjZWl2aW5nIGEgbGFiZWwgbWFwcGluZyBm cm9tIFBFMiB3aXRoIFAgYml0IHNldCwgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFy YS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+UEUxIHdpbGwgc2VuZCBsYWJlbCByZWxlYXNlLiBUaGVuIFBFMiB3aWxsIG5ldmVy IHNlbmQgbGFiZWwgbWFwcGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBhcmEtbWFy Z2luLWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPmFnYWluIHRvIFBFMSBldmVuIHdoZW4gUEUxIGNoYW5nZXMgZnJvbSA8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmxlYWYtb25seSBub2RlIHRvIHJvb3Qt bGVhZiBub2RlLiBGb3IgTERQLURVPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1t YXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5tb2RlLCBQRTIgd2lsbCBub3Qgc2VuZCBsYWJlbCBtYXBwaW5nIGFnYWluIHdoZW4gcmVjZWl2 aW5nIFBFMSdzIGxhYmVsIG1hcHBpbmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFy YS1tYXJnaW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5UaGVuIHRoZSBQVyB3aWxsIG5vdCBiZSBzZXR1cCBzdWNjZXNzZnVsbHkuIFRoZW4gb25s eSB3YXkgaXMgdG8gY29uZmlndXJlIHRoZSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NjMuMHB0O21zby1w YXJhLW1hcmdpbi1sZWZ0OjUuMjVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPnNhbWUgUFcgb24gUEUyIGFnYWluLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNv LXBhcmEtbWFyZ2luLWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhlIGNvcnJlY3QgYmVoYXZpb3IgaXMsIGxhYmVsIHJlbGVhc2UgbWVzc2FnZSBz aG91bGQgbm90IGJlIHNlbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYzLjBwdDttc28tcGFyYS1tYXJn aW4tbGVmdDo1LjI1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G b3IgUFcgc2lnbmFsaW5nLCB0aGUgdW5hY2NlcHRhYmxlIG9mIGFueSBJbnRlcmZhY2UgUGFyYW1l dGVyIHdpbGwgbm90IGxlYWQgdG8gYW55IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBh cmEtbWFyZ2luLWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+bGFiZWwgcmVsZWFzZSwgYnV0IGp1c3Qgc2ltcGx5IGxldCB0aGUgUFcgZG93biBpbiBm b3J3YXJkaW5nIHBsYW5lLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2My4wcHQ7bXNvLXBhcmEtbWFyZ2lu LWxlZnQ6NS4yNWdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjQyLjBwdDttc28t bWFyZ2luLXRvcC1hbHQ6MGNtO21zby1wYXJhLW1hcmdpbi1yaWdodDowY207bXNvLXBhcmEtbWFy Z2luLWJvdHRvbToxMi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiPj09PT09PT09PGJyPg0KPGJyPg0KQW5keSBsb29rZWQgYXQgdGhpcyBmcm9tIHRo ZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBNRUYgYW5kIG5vdGVzIGluPGJyPg0KcHJpdmF0ZSBjb252 ZXJzYXRpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2Qi PjxzcGFuIGxhbmc9IkVOLVVTIj49PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0 O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlIEUt dHJlZSBzZXJ2aWNlIGFzIGRlZmluZWQgYnkgTUVGLCB5b3UgY2FuIGhhdmUgb25lIG9yIG1vcmUg cm9vdHMNCjxicj4NCmFuZCBvbmUgb3IgbW9yZSBsZWFmcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 NDIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVn ZCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGEgc2luZ2xlIEUtdHJlZSBzZXJ2aWNlICh0aGluayBv ZiBhIG11bHRpcG9pbnQgUFcgd2l0aCBzb21lIG9mIHRoZSBDRXMNCjxicj4NCmNvbmZpZ3VyZWQg YXMgcm9vdHMgYXMgc29tZSBhcyBsZWFmcyksIGFsbCBsZWFmcyBhbmQgcm9vdHMgcmVjZWl2ZSBm cmFtZXMgPGJyPg0Kc2VudCBieSB0aGUgcm9vdHMuIEFsbCByb290cyByZWNlaXZlIGZyYW1lcyBz ZW50IGJ5IHRoZSBsZWFmcy4gSG93ZXZlciwgPGJyPg0KbGVhZnMgbWF5IG5vdCByZWNlaXZlIGFu eSBmcmFtZXMgc2VudCBieSBvdGhlciBsZWFmcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0 O21zby1wYXJhLW1hcmdpbi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjQyLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDozLjVnZCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRoZSBkcmFmdCwgYXMgd3JpdHRlbiwgZG9lc24ndCBicmluZyB1cCBh biB1bmRlcmx5aW5nIHB0LXRvLXB0IFBXcyB0bw0KPGJyPg0KY2FycnkgZnJhbWVzIGZvciB0aGUg c2VydmljZSBiZXR3ZWVuIFBFcyB0aGF0IG9ubHkgaGF2ZSBsZWFmcyBhdHRhY2hlZC4gPGJyPg0K U2luY2UgdGhlIGxlYWZzIGNhbid0IHNlbnQgZnJhbWVzIHRvIGVhY2ggb3RoZXIsIHRoYXQgaXMg YW4gZWNvbm9taWNhbCA8YnI+DQp1c2Ugb2YgUFdzIGluIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDIuMHB0O21zby1wYXJhLW1hcmdp bi1sZWZ0OjMuNWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+TGl6aG9uZydzIHBvaW50IGlzIHRoYXQg dGhpcyBtYWtlcyBpdCBpbXBvc3NpYmxlIHRvIGFkZCBhIG5ldyByb290IHRvDQo8YnI+DQphbiBl eGlzdGluZyBQRSBpbiBhbiBFLXRyZWUgdGhhdCBwcmV2aW91c2x5IG9ubHkgaGFkIGxlYWZzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjQyLjBwdDtt c28tbWFyZ2luLXRvcC1hbHQ6MGNtO21zby1wYXJhLW1hcmdpbi1yaWdodDowY207bXNvLXBhcmEt bWFyZ2luLWJvdHRvbToxMi4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPg0KPHNwYW4g bGFuZz0iRU4tVVMiPkkgYWdyZWUgdGhhdCB3b3VsZCBiZSBhIHByb2JsZW0gaWYgdGhlcmUgd2Fz IGEgcmVxdWlyZW1lbnQgdG8gbW9kaWZ5DQo8YnI+DQphbiBleGlzdGluZyBFLXRyZWUgc2Vydmlj ZS4gSG93ZXZlciwgdGhpcyBkcmFmdCBoYXMgbm8gb3RoZXIgbWVjaGFuaXNtcyA8YnI+DQp0byBl eHBsaWNpdGx5IHN1cHBvcnQgRS10cmVlIG1vZGlmaWNhdGlvbiwgbm9yIGlzIHN1Y2ggbW9kaWZp Y2F0aW9uIGEgPGJyPg0KcmVxdWlyZW1lbnQgb2YgdGhlIHVuZGVybHlpbmcgTUVGIHNwZWNpZmlj YXRpb24uIEJUVywgc2luY2UgdGhpcyB3b3JrIDxicj4NCndhcyBzdGFydGVkLCB0aGUgTUVGIHJl cGxhY2VkIE1FRiA2LjEgd2l0aCBNRUYgNi4yLCAmcXVvdDtFVkMgRXRoZXJuZXQgPGJyPg0KU2Vy dmljZXMgRGVmaW5pdGlvbnMgUGhhc2UgMyZxdW90OywgQXVndXN0LCAyMDE0LCBhbmQgdGhhdCBy ZWZlcmVuY2Ugc2hvdWxkIDxicj4NCmJlIHVwZGF0ZWQgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJn aW4tbGVmdDo0Mi4wcHQ7bXNvLW1hcmdpbi10b3AtYWx0OjBjbTttc28tcGFyYS1tYXJnaW4tcmln aHQ6MGNtO21zby1wYXJhLW1hcmdpbi1ib3R0b206MTIuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0 OjMuNWdkIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5NeSBvcGluaW9uIGlzIHRoYXQgdGhlIGRyYWZ0 IGFzIGl0IHN0YW5kcyBpcyB0ZWNobmljYWxseSBjb3JyZWN0IGlmIHlvdQ0KPGJyPg0KZG9uJ3Qg bmVlZCB0aGUgYWJpbGl0eSB0byByZWNvbmZpZ3VyZSBhbiBleGlzdGluZyBFLXRyZWUgc2Vydmlj ZSBkeW5hbWljYWxseS48YnI+DQo8YnI+DQo9PT09PT09PT09PGJyPg0KPGJyPg0KTm93IHdoaWxz dCBJIGNhbiBzdXBwb3J0IHRoZSBpZGVhIHRoYXQgZHluYW1pYyByZWNvbmZpZ3VyYXRpb24gb2Y8 YnI+DQpFLXRyZWUgaXMgbm90IG5lZWRlZCwgSSBoYXZlIGEgY29uY2Vybi48YnI+DQo8YnI+DQpN eSB1bmRlcnN0YW5kaW5nIHRoZSB0ZXh0IGluIHF1ZXN0aW9uIGlzIHRoYXQgaXQgaXMgc2F5aW5n IHRoYXQgaWYgPGJyPg0KQSBpcyBjb25maWd1cmVkIGFzIGxlYWYgb25seSwgYW5kIEIgd2hpY2gg aXMgYWxzbyBjb25maWd1cmVkIGFzPGJyPg0KbGVhZiBvbmx5IGF0dGVtcHRzIHRvIGNvbmZpZ3Vy ZSBhIFBXIGJldHdlZW4gdGhlbSwgdGhlbiBBIHJlamVjdHMgPGJyPg0KdGhlIFBXIHNldHVwLjxi cj4NCjxicj4NClRoYXQgc291bmRzIHZlcnkgcmVhc29uYWJsZSB0byBtZSwgc2luY2UgdGhlcmUg aXMgYSBtaXNjb25maWcuPGJyPg0KPGJyPg0KSWYgQSBkaWQgbm90IGRvIHRoZSByZWplY3QsIHRo ZW4gQiB3b3VsZCBmb3JldmVyIGJlIGNvbnN1bWluZzxicj4NCnJlc291cmNlIHdhaXRpbmcgZm9y IEEgYW5kIEIgd291bGQgaGF2ZSBubyBpZGVhIG9mIHRoZTxicj4NCm1pc2NvbmZpZy4gVGhhdCBh Y2NvcmRzIHdpdGggQW5keSdzIHZpZXcgYWJvdmUuPGJyPg0KPGJyPg0KSG93ZXZlciBJIHdhcyB3 b3JyaWVkIHdoYXQgd291bGQgaGFwcGVuIGlmIEEgd2FzIG1pc2NvbmZpZ3VyZWQ8YnI+DQphcyBs ZWFmIG9ubHkgYW5kIHRoZSBjb25maWd1cmF0aW9uIHdhcyBjb3JyZWN0ZWQgdG8gcm9vdC1sZWFm Ljxicj4NCldoYXQgd291bGQgaW4gbXkgdmlldyBiZSBkaWZmaWN1bHQgdG8gYWNjZXB0IHdhcyB0 aGUgbmVlZCB0bzxicj4NCnRha2UgYSBodW1hbiwgb3IgTk1TIGFjdGlvbiBhdCBCIHRvIHJlY292 ZXIgdGhlIHNpdHVhdGlvbi48YnI+DQpIb3dldmVyIHByb3ZpZGVkIHRoYXQgQSBjbG9zZWQgdGhl IExEUCBzZXNzaW9uIHdpdGggQiA8YnI+DQphbmQgcmUtaW5zdGF0ZSBpdCBCIHdvdWxkIHRoZW4g c2VuZCB0aGUgbWFwcGluZyBtZXNzYWdlIGFnYWluLjxicj4NClRodXMgdGhlIHN5c3RlbSBpcyBy ZWNvdmVyYWJsZSB3aXRob3V0IG5lZWRpbmcgdG8gdmlzaXQgQiB3aGljaDxicj4NCmlzIGluIG15 IG1pbmQgYSBmdW5kYW1lbnRhbCByZXF1aXJlbWVudCBzaW5jZSBBIGNvdWxkIGhhdmU8YnI+DQpn b3QgaW50byB0aGUgd3JvbmcgbW9kZSBhcyBhIHJlc3VsdCBvZiBhbiBlcnJvci48YnI+DQo8YnI+ DQpUaGUgcHJvYmxlbSBJIHNlZSBpcyBpZiBBIGhhcyBhIGJ1bmNoIG9mIG90aGVyIFBXcyB3aXRo IEI8YnI+DQp0aGV5IHdpbGwgZ2V0IHRvcm4gZG93biBpbiBvcmRlciBmb3IgQSB0byBoYXZlIHRo ZSBjb25maWcgZXJyb3I8YnI+DQpmaXhlZC4gSG93ZXZlciBpZiB0aGF0IGlzIGEgcHJvYmxlbSB5 b3UgbmVlZCB0d28gTERQIHNlc3Npb25zPGJyPg0KYmV0d2VlbiBBIGFuZCBCLCBvbmUgZm9yIEwy VlBOIGFuZCBvbmUgZm9yIHJlZ3VsYXIgUFdzLjxicj4NCjxicj4NCk15IGluY2xpbmF0aW9uIGlz IHRoYXQgdGhlIGRyYWZ0IGlzIGJhc2ljYWxseSBjb3JyZWN0LCBhbmQgdGhhdCB3aGlsc3Q8YnI+ DQpMaXpob25nIGlzIGNvcnJlY3QgdGhhdCB0aGUgUFcgd2lsbCBub3QgY29tZSB1cCB3aXRob3V0 IHNvbWU8YnI+DQphY3Rpb24sIHJlY29uZmlndXJpbmcgdGhlIFBXIG9uIEIgaXMgbm90IHRoZSBv bmx5IGFjdGlvbjxicj4NCnRoYXQgd2lsbCBjYXVzZSB0aGUgUFcgdG8gY29tZSB1cC4gPGJyPg0K PGJyPg0KU28gdGhpcyBjb21lcyBkb3duIHRvIGEgV0cgZGVjaXNpb24gaW4gdGVybXMgb2Ygd2hp Y2ggaXMgdGhlPGJyPg0KbGVhc3QgdW5hY2NlcHRhYmxlIGJlaGF2aW91ciAtIEEgaGF2aW5nIHRv IHJlLWN5Y2xlIHRoZSBMRFA8YnI+DQpzZXNzaW9uLCBvciBCIHdhc3RpbmcgcmVzb3VyY2VzLiBJ IHRoaW5rIEkgcHJlZmVyIHRoZSBiZWhhdmlvdXI8YnI+DQpwcm9wb3NlZCBpbiB0aGUgZHJhZnQu PGJyPg0KPGJyPg0KQSB3YXkgZm9yd2FyZCBpcyB0byBsZWF2ZSB0aGUgbG9naWMgYXMgd3JpdHRl biBpbiB0aGUgZHJhZnQsIGJ1dCB0byA8YnI+DQphZGQgdGV4dCBkZXNjcmliaW5nIHRoZSBiYXNp cyBmb3IgZXhjbHVkaW5nIGR5bmFtaWMgcmUtY29uZmlndXJhdGlvbjxicj4NCmFzIGEgbm9ybWFs IG9wZXJhdGlvbmFsIG1vZGUgYW5kIHRvIG5vdGUgdGhlIGFjdGlvbnMgdGhhdCBuZWVkIDxicj4N CnRvIGJlIHRha2VuIHdoZW4gcmUtY29uZmlndXJhdGlvbiBpcyBmb3JjZWQgZm9yIHNvbWUgcmVh c29uLjxicj4NCjxicj4NCldoaWxzdCB3ZSB3ZXJlIHBvbmRlcmluZyB3aGF0IGRvIHdpdGggdGhl IHRleHQgdGhlIGNoYWlyczxicj4NCmFuZCBBRCByZWNlaXZlZCBhbm90aGVyIHByb3Bvc2FsIGZy b20gdGhlIGF1dGhvcnM6PGJyPg0KPGJyPg0KPT09PT09PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SW4gZ2VuZXJhbCwgRkVDIFBX aWQoMHg4MCkgaXMgdXNlZCBpbiBWUExTIHdpdGggbWFudWFsIHByb3Zpc2lvbmluZywNCjxicj4N CndoaWxlIEdlbmVyYWxpemVkIFBXaWQgKDB4ODEpIGlzIHVzZWQgd2l0aCBhdXRvLWRpc2NvdmVy eS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPkFzIGRpc2N1c3NlZCBpbiBTZWN0aW9u IDUuMiwgVkxBTiBtYXBwaW5nIHBhcmFtZXRlcnMgY2FuIGJlIHByb3Zpc2lvbmVkDQo8YnI+DQp3 aXRob3V0IGEgc2lnbmFsaW5nIHByb3RvY29sLCBPcHRpbWl6ZWQgTW9kZSBjYW4gYWxzbyBiZSBh IHBhcmFtZXRlciA8YnI+DQp0byBiZSBwcm92aXNpb25lZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQiPlRoZSBhcHByb2FjaCB3ZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdCI+4oCZPHNwYW4gbGFuZz0iRU4tVVMiPnZlIHRha2VuIGluIHRoZSBjdXJyZW50IGRyYWZ0 LWlldGYtbDJ2cG4tdnBscy1wZS1ldHJlZS0wOQ0KPGJyPg0KZG9lcyBhbGxvdyB0aGlzLiBRdWl0 ZSBhIGZldyBzZXJ2aWNlIHByb3ZpZGVycyBtYXkgcHJlZmVyIHRvIGNvbnRyb2w8YnI+DQphbGwg dGhlc2UgRS1UcmVlIGNvbm5lY3Rpdml0eSBieSB0aGVtc2VsdmVzLjwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQiPldoZW4gRS1UcmVlIHNpZ25hbGluZyBwcm90b2NvbCBmb3Ig UFdpZCBGRUMgaXMgY29uc2lkZXJlZCwgdGhlIGZvbGxvd2luZw0KPGJyPg0Kb3B0aW9ucyBhcmUg YWxzbyBmZWFzaWJsZTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPmEpPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPkRpc2FibGUgT3B0aW1pemVkIG1vZGUgZm9yIEZFQyBQV2lkKDB4ODAp LCB0aHVzIHJvb3QvbGVhZiByb2xlDQo8YnI+DQpjaGFuZ2UgaW4gdGhlIEUtVHJlZSB0b3BvbG9n eSB3aWxsIG5vdCBoYXZlIGFueSBpbmZsdWVuY2Ugb24gdGhlIFBXLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdCI+Yik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+QWRkIGFub3RoZXIgYXBw ZW5kaXggaW50byB0aGUgZG9jdW1lbnQgZm9yIHRoZSBmdWxsIHN1cHBvcnQgb2YNCjxicj4NCk9w dGltaXplZCBtb2RlIHdpdGggRkVDIFBXaWQoMHg4MCkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0Ij5UaGUgaWRlYSBpczogdGhlIFBFIHNlbmRzIGEgbGFiZWwgbWFwcGluZyBmaXJzdGx5 IGFuZCB0aGVuIHNlbmQgYSBsYWJlbA0KPGJyPg0KcmVxdWVzdCB0byBpdHMgcGVlciBQRXMgKHNv IHRoYXQgdGhleSB3aWxsIHJlcGx5IHdpdGggYSBsYWJlbCBtYXBwaW5nIDxicj4NCnJlc3BlY3Rp dmVseSkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5TaW5jZSBPcHRpbWl6ZWQgbW9k ZSBpcyBhbiBvcHRpb25hbCBwaWVjZSBpbiB0aGUgZG9jdW1lbnQsIEkgd291bGQNCjxicj4NCnJl Z2FyZCBvcHRpb24gYSkgYXMgYSBzaW1wbGUgdHJhZGVvZmYgKGFzIEkgYW0gYXdhcmUsIEUtVlBO IGRvZXMgbm90IDxicj4NCnN1cHBvcnQgT3B0aW1pemVkIG1vZGUgZm9yIEUtVHJlZSBlaXRoZXIu PGJyPg0KPGJyPg0KPT09PT09PT08YnI+DQo8YnI+DQo8YnI+DQpUaHVzIHdlIGhhdmUgdGhyZWUg cHJvcG9zYWxzIG9uIHRoZSB0YWJsZTo8YnI+DQo8YnI+DQoxKSBMZWF2ZSB0aGUgZGVzaWduIGFz IGl0IGlzLCBidXQgYWRkIHRleHQgdG8gZGVzY3JpYmUgdGhlIGNvbnN0cmFpbnQgYW5kPGJyPg0K d2hhdCBoYXBwZW5zIGlmIHlvdSBoYXZlIHRvIGNoYW5nZSBtb2RlIGFuZCB3aGF0IHRvIGRvIGFi b3V0IGl0Ljxicj4NCjxicj4NCjIpIEV4Y2x1ZGUgb3B0aW1pemF0aW9uIGluIHRoZSBGRUMgUFdp ZCgweDgwKSBjYXNlPGJyPg0KPGJyPg0KMykgQWRkIGFuIGFwcGVuZGl4IGRlc2NyaWJpbmcgc3Vw cG9ydCBmb3IgdGhlIEZFQyBQV2lkKDB4ODApIGNhc2UuPGJyPg0KPGJyPg0KTXkgaW5jbGluYXRp b24gd291bGQgYmUgdG8gZ28gd2l0aCBvcHRpb24gKDEpIGJ1dCBJIHNlZWsgdGhlIHZpZXdzIG9m PGJyPg0KdGhlIFdHLCBhbmQgb2YgY291cnNlIGFueSBjb3JyZWN0aW9ucyBpbiBteSBhbmFseXNp cy48YnI+DQo8YnI+DQotIFN0ZXdhcnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDtt YXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLW1hcmdpbi10b3AtYWx0OjBjbTttc28tcGFyYS1tYXJnaW4t cmlnaHQ6MGNtO21zby1wYXJhLW1hcmdpbi1ib3R0b206MTIuMHB0O21zby1wYXJhLW1hcmdpbi1s ZWZ0OjMuNWdkIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClBhbHMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlBhbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5QYWxzQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGFscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGFsczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4wcHQ7bXNvLXBh cmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo0Mi4w cHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6My41Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFy Z2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyIHN0eWxlPSJtc28t c3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8IVtpZiAhc3VwcG9ydExpbmVCcmVha05l d0xpbmVdPjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFb ZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjIx LjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdp bi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBhbHMgbWFpbGluZyBsaXN0PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBh cmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRv OlBhbHNAaWV0Zi5vcmciPlBhbHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43 NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYWxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3BhbHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1s ZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoyMS4wcHQ7bXNvLXBhcmEtbWFyZ2luLWxlZnQ6MS43NWdkIj48c3BhbiBsYW5nPSJFTi1VUyI+ PGJyPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8IVtp ZiAhc3VwcG9ydExpbmVCcmVha05ld0xpbmVdPjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFj dGVyOmxpbmUtYnJlYWsiPg0KPCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxz cGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoxLjc1Z2QiPjxzcGFuIGxh bmc9IkVOLVVTIj5Gb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJh LW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1h cmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly93d3cu Y2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCI+ aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9p bmRleC5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjEuNzVnZCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B68283796szxema506mbschi_-- From nobody Wed Oct 28 10:05:43 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2514E1A92F0; Wed, 28 Oct 2015 10:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWxXSaWoMBOZ; Wed, 28 Oct 2015 10:05:40 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADE81ABD3A; Wed, 28 Oct 2015 10:02:23 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9SGsaOH045732; Wed, 28 Oct 2015 13:02:22 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 1xr4s52xbs-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2015 13:02:21 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9SH2JOZ022599; Wed, 28 Oct 2015 13:02:20 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9SH29O3022318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Oct 2015 13:02:17 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 28 Oct 2015 17:02:01 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.90]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0248.002; Wed, 28 Oct 2015 13:02:00 -0400 From: "BRUNGARD, DEBORAH A" To: "draft-ietf-pals-rfc4447bis@ietf.org" Thread-Topic: AD comments on draft-ietf-pals-rfc4447bis Thread-Index: AdERolsz6AK0Dz+3RfaIVsSTan2TvA== Date: Wed, 28 Oct 2015 17:01:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.14.128] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C852763A06MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510280280 Archived-At: Cc: "pals-chairs@ietf.org" , "pals@ietf.org" Subject: [Pals] AD comments on draft-ietf-pals-rfc4447bis X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 17:05:42 -0000 --_000_F64C10EAA68C8044B33656FA214632C852763A06MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In preparing this document for IESG review as it is proposed for Internet S= tandard status, it will need a section on how it meets the RFC6410 criteria= for Internet Standard. I've discussed with the authors and they will updat= e it. Once it is updated, it will go for a 4-week Last Call (instead of the= typical 2-week). Thanks, Deborah --_000_F64C10EAA68C8044B33656FA214632C852763A06MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
In preparing this document for IESG review as it is proposed for Inter= net Standard status, it will need a section on how it meets the RFC6410 cri= teria for Internet Standard. I’ve discussed with the authors and they= will update it. Once it is updated, it will go for a 4-week Last Call (instead of the typical 2-week).
 
Thanks,
Deborah
 
 
 --_000_F64C10EAA68C8044B33656FA214632C852763A06MISOUT7MSGUSRDE_-- From nobody Thu Oct 29 02:28:30 2015 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CEA1B2BAE; Thu, 29 Oct 2015 02:28:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151029092826.28925.87191.idtracker@ietfa.amsl.com> Date: Thu, 29 Oct 2015 02:28:26 -0700 Archived-At: Cc: db3546@att.com, agmalis@gmail.com, pals-chairs@ietf.org, The IESG , pals@ietf.org, draft-ietf-pwe3-iccp-stp@ietf.org, rfc-editor@rfc-editor.org Subject: [Pals] Protocol Action: 'Spanning Tree Protocol (STP) Application of Inter-Chassis Communication Protocol (ICCP)' to Proposed Standard (draft-ietf-pwe3-iccp-stp-05.txt) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 09:28:26 -0000 The IESG has approved the following document: - 'Spanning Tree Protocol (STP) Application of Inter-Chassis Communication Protocol (ICCP)' (draft-ietf-pwe3-iccp-stp-05.txt) as Proposed Standard This document is the product of the Pseudowire And LDP-enabled Services Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp-stp/ Technical Summary Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism which achieves high availability. In this document, the PEs in a Redundancy Group (RG) running ICCP are used to offer multi-homed connectivity to Spanning Tree Protocol (STP) networks. The ICCP TLVs for the STP application are defined, therefore PEs from the RG can make use of these TLVs to synchronize the state and configuration data of the STP network. The operation logic of the application and the usage of these ICCP TLVs are specified. Working Group Summary As a result of WG last call, a number of improvements were made to the draft from revision -01 to -02, largely based on review comments from Alexander (Sasha) Vainshtein. Because of the changes, the WG was given a chance to re-review revision -02, and no further WG comments were received. So the WG certainly has rough consensus. Document Quality There is at least one implementation in progress the last time that this was polled. See the previous comment about Sasha Vainshtein's review and subsequent changes. Personnel Andy Malis is the Document Shepherd Deborah Brungard is the Responsible Area Director From nobody Fri Oct 30 14:53:22 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7795D1ACD38 for ; Fri, 30 Oct 2015 14:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUX6HBbzeTPO for ; Fri, 30 Oct 2015 14:52:53 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702A01ACD33 for ; Fri, 30 Oct 2015 14:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21809; q=dns/txt; s=iport; t=1446241972; x=1447451572; h=reply-to:cc:from:subject:to:message-id:date:mime-version; bh=0AQKBfCsl/6sVf/hGGHRCj+bhcEHzYFf3/a5GCM9/8o=; b=RpFj6xpFzz4FTD2wF0cJTbpmYcPpWLef7WEfAfBvJvxds4QKs8R6eiWr vrnGwoFOoDw/+uspudlFZA7TPsesMXCk1PGjghmEGRNxPbouzAoiVG2cA tDJeS+ndt47DMh/7g9l6o2HOMuFyslbW45IkMDI6PN0RyyMeZG1f/ti3d U=; X-IronPort-AV: E=Sophos;i="5.20,220,1444694400"; d="scan'208,217";a="607883547" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 Oct 2015 21:52:50 +0000 Received: from [10.55.98.184] (ams-stbryant-8817.cisco.com [10.55.98.184]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9ULqnMM030254; Fri, 30 Oct 2015 21:52:50 GMT From: Stewart Bryant To: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org Message-ID: <5633E6B1.7040105@cisco.com> Date: Fri, 30 Oct 2015 21:52:49 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000205060605040906040102" Archived-At: Cc: Stewart Bryant , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: [Pals] WGC comments on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 21:52:57 -0000 This is a multi-part message in MIME format. --------------000205060605040906040102 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Authors This is mainly editorial, but there are a few items such as the comparison text that will need to be clarified before this goes for further review. Experience shows that if they are not fixed now they will surface again further down the line. Thanks Stewart ================== LDP Extensions for Pseudowire Binding to LSP Tunnels draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt Abstract Many transport services require that user traffic, in the forms of SB> s/forms/form/ Pseudowires (PW), to be delivered on a single co-routed bidirectional SB> s/to be/be/ LSP or two LSPs that share the same routes. In addition, the user traffic may traverse through multiple transport networks. This document defines an optional extension to LDP that enables the binding between PWs and the underlying LSPs. ======== 3. Theory of Operation During PW setup, the PEs may select desired forwarding tunnels/LSPs, SB> s/may select/may choose to select/ and inform the remote T-PE/S-PEs about the desired reverse tunnels/ LSPs. ============ As defined in (Section 7.2.1, [RFC6073]), each PE may be generally categorized into active and passive roles: d/generally/ Otherwise you need to qualify the term "generally" ========== 4. PSN Binding Operation for SS-PW On receive, if the S-bit is set, other than following the processing SB> s/other/as well as/ procedure defined in Section 5.3.3 of [RFC4447], the receiving PE (i.e. PE2) needs to determine whether to accept the indicated tunnel/LSP in PSN Tunnel Sub-TLV. If the receiving PE (PE2) is also an active PE, and may have initiated the PSN binding requests to the other PE (PE1), if the received PSN tunnel/LSP is the same as it has been sent in the Label Mapping message by PE2, then the signaling has converged on a mutually agreed Tunnel/LSP. The binding operation is completed. Otherwise, the receiving PE (PE2) MUST compare its own Node ID against the received Source Node ID. If it is numerically lower, the SB> You need to describe (hopefully by reference) the conversion of the SB> address to an unsigned integer, otherwise the text above is ambiguous. SB> I am sure that I have some text that I wrote with Dan Frost on this SB> but I cannot remember which RFC it was in. PE (PE2) will reply a Label Mapping message to complete the PW setup SB> s/will reply/will reply with/ and confirm the binding request. The PSN Tunnel Binding TLV in the message MUST contain the same Source and Destination IDs/Numbers as Chen, et al. Expires March 4, 2016 [Page 9] Internet-Draft Explicit PW to LSP Tunnels Binding September 2015 in the received binding request, in the appropriate order. On the other hand, if the receiving PE (PE2) has a Node ID that is numerically higher than the Source Node ID carried in the PSN Tunnel Binding TLV, it MUST reply a Label Release message with status code s/reply/reply with/ set to "Reject to use the suggested tunnel/LSPs" and the received PSN Tunnel Binding TLV, and the PW will not be established. SB> The text of the reject message is not good English. SB> I suggest : "Reject - unable to use the suggested tunnel/LSPs" To support co-routed binding, the receiving PE can select the appropriated PSN tunnel/LSP for the reverse direction of the PW, so long as the forwarding and reverse PSNs share the same route. SB> What do you mean by route? I think that you need to be more precise. Initially, a PE (PE1) sends a Label Mapping message to the remote PE (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared, and the appropriate Source and Destination IDs/Numbers. In case of unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the Source IDs/Numbers, the Destination IDs/Numbers are set to zero and left for PE2 to fill when responding the Label Mapping message. SB> s/fill/fill in/ or perhaps /complete/ On receive, since PE2 is also an active PE, and may have initiated the PSN binding requests to the other PE (PE1), if the received PSN tunnel/LSP has the same route as the one that has been sent in the Label Mapping message to PE1, then the signaling has converged. The binding operation is completed. Otherwise, it needs to compare its own Node ID against the received SB> who is "it"? Source Node ID. If it is numerically lower, SB> Again the definition of "numerically lower" needs to be provided. PE2 needs to find/ establish a tunnel/LSP that meets the co-routed constraint, and reply SB> s/reply/reply with/ a Label Mapping message with a PSN Binding TLV that contains the Source and Destination IDs/Numbers in the appropriate order. SB> What does "appropriate order" mean? On the other hand, if the receiving PE (PE2) has a Node ID that is numerically higher than the Source Node ID carried in the PSN Tunnel Binding TLV, it MUST reply a Label Release message with status code SB> s/reply/reply with/ set to "Reject to use the suggested tunnel/LSPs" and the received PSN Tunnel Binding TLV. In both strict and co-routed bindings, if T-bit is set, the LSP Number field MUST be set to zero. Otherwise, the field MUST contain the actual LSP number for the related PSN LSP. After a PW established, the operators may choose to move the PWs from the current tunnel/LSPs to other tunnel/LSPs. Or, the underlying PSN tunnel is broken due to network failure. In this scenario, a new Label Mapping message MUST be sent to update the changes. Note that when T-bit is set, the working LSP broken will not trigger to update the changes if there are protection LSPs. SB> I think that should be written as: After a PW is established, the operators may choose to move the PWs from the current tunnel/LSPs to other tunnel/LSPs. Also the underlying PSN tunnel may break due to a network failure. When either of these scenarios occur, a new Label Mapping message MUST be sent to notify the remote PW of the changes. Note that when the T-bit is set, the working LSP broken will not provide this update if there are protection LSPs in place. The message may carry a new PSN Tunnel Binding TLV, which contains the new Source and Destination Numbers/IDs. The procedure for handling of the new Chen, et al. Expires March 4, 2016 [Page 10] Internet-Draft Explicit PW to LSP Tunnels Binding September 2015 message is identical to the procedure already described in this section. SB> NOTE I changed the previous sentence - but for got to keep the original text. However, if the new Label Binding message does not contain the PSN Tunnel Binding TLV, it declares the removal of any co-routed/strict constraints. The PEs may not map the PW to the underlying PSN on purpose, the current independent PW to PSN binding will be used. SB> I do not understand the text from "However" to "used" Further, as an implementation option, the PEs should not remove the SB> I think that should be "PEs may choose not to" traffic from an operational PW, until the completion of the underlying PSN tunnel/LSP changes. ================ If the Label Mapping message is for forward direction, and S-PE1 accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the tunnel/LSP information for reverse-direction processing later on. If the PSN binding request is not acceptable, S-PE1 MUST reply a Label s/reply/reply with/ Release Message to the upstream PE (T-PE1) with Status Code set to "Reject to use the suggested tunnel/LSPs". SB> Please see earlier comment Chen, et al. Expires March 4, 2016 [Page 11] Internet-Draft Explicit PW to LSP Tunnels Binding September 2015 Otherwise, S-PE1 relays the Label Mapping message to the next S-PE (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the information of the new PSN tunnel/LSPs selected by S-PE1. S-PE2 and subsequent S-PEs will repeat the same operation until the Label Mapping message reaches to the remote T-PE (that is, T-PE2). If T-PE2 agrees with the requested tunnel/LSPs, it will reply a Label SB> what does "agrees with" mean? Mapping message to initiate to the binding process on the reverse direction. The Label Mapping message contains the received PSN Tunnel Binding TLV for confirmation purposes. When its upstream S-PE (S-PE2) receives the Label Mapping message, the S-PE relays the Label Mapping message to its upstream adjacent S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in the PSN Tunnel sub-TLV. The same procedure will be applied on subsequent S-PEs, until the message reaches to T-PE1 to complete the PSN binding setup. During the binding process, if any PE does not agree to the requested tunnel/LSPs, it can send a Label Release Message to its upstream adjacent PE with Status Code set to "Reject to use the suggested tunnel/LSPs". For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit, reset the S-bit and indicates the suggested tunnel/LSP in PSN Tunnel sub-TLV to the next-hop S-PE (S-PE1). During the MS-PW setup, the PEs have the option to ignore the SB> s/to/of/ suggested tunnel/LSP, and select another tunnel/LSP for the segment SB> s/and/and to/ PW between itself and its upstream PE on reverse direction only if SB> s/on/in/ SB> below s/forwarding/forward/ the tunnel/LSP is co-routed with the forwarding one. Otherwise, the procedure is the same as the strict binding. The tunnel/LSPs may change after a MS-PW being established. When a tunnel/LSP has changed, the PE that detects the change SHOULD select an alternative tunnel/LSP for temporary use while negotiating with other PEs following the procedure described in this section. 6. Security Considerations The ability to control which LSP to carry traffic from a PW can be a SB> s/which LSP/which LSP is used/ --------------000205060605040906040102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Authors

This is mainly editorial, but there are a few items such as the 
comparison text that will need to be clarified before this
goes for further review. Experience shows that if they are not
fixed now they will surface again further down the line.

Thanks

Stewart


==================

 LDP Extensions for Pseudowire Binding to LSP Tunnels
            draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt

Abstract

   Many transport services require that user traffic, in the forms of
SB> s/forms/form/
   Pseudowires (PW), to be delivered on a single co-routed bidirectional
SB> s/to be/be/
   LSP or two LSPs that share the same routes.  In addition, the user
   traffic may traverse through multiple transport networks.

   This document defines an optional extension to LDP that enables the
   binding between PWs and the underlying LSPs.


========


3.  Theory of Operation

   During PW setup, the PEs may select desired forwarding tunnels/LSPs,
SB> s/may select/may choose to select/
   and inform the remote T-PE/S-PEs about the desired reverse tunnels/
   LSPs.

============

   As defined in (Section 7.2.1, [RFC6073]), each PE may be generally
   categorized into active and passive roles:

d/generally/

Otherwise you need to qualify the term "generally"

==========
 4.  PSN Binding Operation for SS-PW

 

   On receive, if the S-bit is set, other than following the processing

SB> s/other/as well as/

    procedure defined in Section 5.3.3 of [RFC4447], the receiving PE
   (i.e.  PE2) needs to determine whether to accept the indicated
   tunnel/LSP in PSN Tunnel Sub-TLV.

   If the receiving PE (PE2) is also an active PE, and may have
   initiated the PSN binding requests to the other PE (PE1), if the
   received PSN tunnel/LSP is the same as it has been sent in the Label
   Mapping message by PE2, then the signaling has converged on a
   mutually agreed Tunnel/LSP.  The binding operation is completed.

   Otherwise, the receiving PE (PE2) MUST compare its own Node ID
   against the received Source Node ID.  If it is numerically lower, the

SB> You need to describe (hopefully by reference) the conversion of the
SB> address to an unsigned integer, otherwise the text above is ambiguous.
SB> I am sure that I have some text that I wrote with Dan Frost on this
SB> but I cannot remember which RFC it was in.


 
   PE (PE2) will reply a Label Mapping message to complete the PW setup
SB> s/will reply/will reply with/
   and confirm the binding request.  The PSN Tunnel Binding TLV in the
   message MUST contain the same Source and Destination IDs/Numbers as



Chen, et al.              Expires March 4, 2016                 [Page 9]

Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015


   in the received binding request, in the appropriate order.  On the
   other hand, if the receiving PE (PE2) has a Node ID that is
   numerically higher than the Source Node ID carried in the PSN Tunnel
   Binding TLV, it MUST reply a Label Release message with status code

s/reply/reply with/

   set to "Reject to use the suggested tunnel/LSPs" and the received PSN
   Tunnel Binding TLV, and the PW will not be established.

SB> The text of the reject message is not good English.
SB> I suggest : "Reject - unable to use the suggested tunnel/LSPs"

   To support co-routed binding, the receiving PE can select the
   appropriated PSN tunnel/LSP for the reverse direction of the PW, so
   long as the forwarding and reverse PSNs share the same route.

SB> What do you mean by route? I think that you need to be more precise.


    Initially, a PE (PE1) sends a Label Mapping message to the remote PE
   (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared,
   and the appropriate Source and Destination IDs/Numbers.  In case of
   unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the
   Source IDs/Numbers, the Destination IDs/Numbers are set to zero and
   left for PE2 to fill when responding the Label Mapping message.

SB> s/fill/fill in/ or perhaps /complete/


 On receive, since PE2 is also an active PE, and may have initiated
   the PSN binding requests to the other PE (PE1), if the received PSN
   tunnel/LSP has the same route as the one that has been sent in the
   Label Mapping message to PE1, then the signaling has converged.  The
   binding operation is completed.

   Otherwise, it needs to compare its own Node ID against the received
SB> who is "it"?

   Source Node ID.  If it is numerically lower, 

SB> Again the definition of "numerically lower" needs to be provided.

   PE2 needs to find/
   establish a tunnel/LSP that meets the co-routed constraint, and reply

SB> s/reply/reply with/

   a Label Mapping message with a PSN Binding TLV that contains the
   Source and Destination IDs/Numbers in the appropriate order. 
SB> What does "appropriate order" mean?

   On the
   other hand, if the receiving PE (PE2) has a Node ID that is
   numerically higher than the Source Node ID carried in the PSN Tunnel
   Binding TLV, it MUST reply a Label Release message with status code

SB> s/reply/reply with/

   set to "Reject to use the suggested tunnel/LSPs" and the received PSN
   Tunnel Binding TLV.

   In both strict and co-routed bindings, if T-bit is set, the LSP
   Number field MUST be set to zero.  Otherwise, the field MUST contain
   the actual LSP number for the related PSN LSP.

   After a PW established, the operators may choose to move the PWs from
   the current tunnel/LSPs to other tunnel/LSPs.  Or, the underlying PSN
   tunnel is broken due to network failure.  In this scenario, a new
   Label Mapping message MUST be sent to update the changes.  Note that
   when T-bit is set, the working LSP broken will not trigger to update
   the changes if there are protection LSPs.

SB> I think that should be written as:

   After a PW is established, the operators may choose to move the PWs from
   the current tunnel/LSPs to other tunnel/LSPs. Also  the underlying PSN
   tunnel may  break due to a network failure.  When either of  these scenarios occur, a new
   Label Mapping message MUST be sent to notify the remote PW of the changes.  Note that
   when the T-bit is set, the working LSP broken will not provide this update
   if there are protection LSPs in place.

   The message may carry a new PSN Tunnel Binding TLV, which contains
   the new Source and Destination Numbers/IDs.  The procedure for handling of the new



Chen, et al.              Expires March 4, 2016                [Page 10]

Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015


   message is identical to the procedure already described in this
   section.

SB> NOTE I changed the previous sentence - but for got to keep the original text.


   However, if the new Label Binding message does not contain the PSN
   Tunnel Binding TLV, it declares the removal of any co-routed/strict
   constraints.  The PEs may not map the PW to the underlying PSN on
   purpose, the current independent PW to PSN binding will be used.

SB> I do not understand the text from "However" to "used"



   Further, as an implementation option, the PEs should not remove the

SB> I think that should be "PEs may choose not to"

   traffic from an operational PW, until the completion of the
   underlying PSN tunnel/LSP changes.

================

   If the Label Mapping message is for forward direction, and S-PE1
   accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the
   tunnel/LSP information for reverse-direction processing later on.  If
   the PSN binding request is not acceptable, S-PE1 MUST reply a Label
s/reply/reply with/

   Release Message to the upstream PE (T-PE1) with Status Code set to
   "Reject to use the suggested tunnel/LSPs".


SB> Please see earlier comment

 Chen, et al.              Expires March 4, 2016                [Page 11]

Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015


   Otherwise, S-PE1 relays the Label Mapping message to the next S-PE
   (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the
   information of the new PSN tunnel/LSPs selected by S-PE1.  S-PE2 and
   subsequent S-PEs will repeat the same operation until the Label
   Mapping message reaches to the remote T-PE (that is, T-PE2).

   If T-PE2 agrees with the requested tunnel/LSPs, it will reply a Label

SB> what does "agrees with" mean?

    Mapping message to initiate to the binding process on the reverse
   direction.  The Label Mapping message contains the received PSN
   Tunnel Binding TLV for confirmation purposes.

   When its upstream S-PE (S-PE2) receives the Label Mapping message,
   the S-PE relays the Label Mapping message to its upstream adjacent
   S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in
   the PSN Tunnel sub-TLV.  The same procedure will be applied on
   subsequent S-PEs, until the message reaches to T-PE1 to complete the
   PSN binding setup.

   During the binding process, if any PE does not agree to the requested
   tunnel/LSPs, it can send a Label Release Message to its upstream
   adjacent PE with Status Code set to "Reject to use the suggested
   tunnel/LSPs".

   For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit,
   reset the S-bit and indicates the suggested tunnel/LSP in PSN Tunnel
   sub-TLV to the next-hop S-PE (S-PE1).

   During the MS-PW setup, the PEs have the option to ignore the
SB> s/to/of/
   suggested tunnel/LSP, and select another tunnel/LSP for the segment

SB> s/and/and to/
   PW between itself and its upstream PE on reverse direction only if
SB> s/on/in/
SB> below s/forwarding/forward/


   the tunnel/LSP is co-routed with the forwarding one.  Otherwise, the
   procedure is the same as the strict binding.

   The tunnel/LSPs may change after a MS-PW being established.  When a
   tunnel/LSP has changed, the PE that detects the change SHOULD select
   an alternative tunnel/LSP for temporary use while negotiating with
   other PEs following the procedure described in this section.

6.  Security Considerations

   The ability to control which LSP to carry traffic from a PW can be a

SB> s/which LSP/which LSP is used/

<end>
--------------000205060605040906040102-- From nobody Fri Oct 30 18:08:10 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDEB1ACDFB for ; Fri, 30 Oct 2015 18:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGDQbRVTxXeT for ; Fri, 30 Oct 2015 18:08:04 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EDC1ACDF3 for ; Fri, 30 Oct 2015 18:08:03 -0700 (PDT) Received: by wmec75 with SMTP id c75so23720020wme.1 for ; Fri, 30 Oct 2015 18:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=meZcvExVLvTqtD3prDaM0IBm2kOx+Nlw9I4tifmsd0o=; b=wsMACqahVoyPOescp5mgVoR0yxuTMOpO+o8+KBhza+GNxkwQniibYvMYBCgtiOUjBn qgvtC3cyvZAdVZLusVVQCsYQ/0vUI/zbdmYDABR7VaqtnE3VI53PJH3kgxd6V5unOikM 54P+wuE555aOW4qDIbS8TIyZp4NVyMix5TQcx8nHU69UQQKP55SMHMWi9v7m5P2G6Z0M oTQJz08i62Lc3tI/USNDFg4m3sEb/CIzjKx65Pt/fMfxF75/y7HJ9biM5WKwzNVn1dZB j00rsmZ/3Yj5pPDvlN7GTXuSr9zvE8j0WFRzzQod1Kp4FYjHuOth06hjgzvy9029YF2n 28oQ== X-Received: by 10.28.18.21 with SMTP id 21mr1080235wms.34.1446253682447; Fri, 30 Oct 2015 18:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.195.10 with HTTP; Fri, 30 Oct 2015 18:07:42 -0700 (PDT) In-Reply-To: <5633E6B1.7040105@cisco.com> References: <5633E6B1.7040105@cisco.com> From: "Andrew G. Malis" Date: Sat, 31 Oct 2015 10:07:42 +0900 Message-ID: To: Stewart Bryant Content-Type: multipart/alternative; boundary=001a1146e610ff5b1b05235c2ca2 Archived-At: Cc: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org, Stewart Bryant , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] WGC comments on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 01:08:08 -0000 --001a1146e610ff5b1b05235c2ca2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, Just in case you=E2=80=99re confused because you didn=E2=80=99t yet see a W= G LC for this draft, Stewart jumped the gun a little bit with his review (but that=E2=80= =99s OK!). The draft will be going into WG LC following the IETF meeting. Cheers, Andy On Sat, Oct 31, 2015 at 6:52 AM, Stewart Bryant wrote: > Authors > > This is mainly editorial, but there are a few items such as the > comparison text that will need to be clarified before this > goes for further review. Experience shows that if they are not > fixed now they will surface again further down the line. > > Thanks > > Stewart > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > LDP Extensions for Pseudowire Binding to LSP Tunnels > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt > > Abstract > > Many transport services require that user traffic, in the forms of > SB> s/forms/form/ > Pseudowires (PW), to be delivered on a single co-routed bidirectional > SB> s/to be/be/ > LSP or two LSPs that share the same routes. In addition, the user > traffic may traverse through multiple transport networks. > > This document defines an optional extension to LDP that enables the > binding between PWs and the underlying LSPs. > > > =3D=3D=3D=3D=3D=3D=3D=3D > > > 3. Theory of Operation > > During PW setup, the PEs may select desired forwarding tunnels/LSPs, > SB> s/may select/may choose to select/ > and inform the remote T-PE/S-PEs about the desired reverse tunnels/ > LSPs. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > As defined in (Section 7.2.1, [RFC6073]), each PE may be generally > categorized into active and passive roles: > > d/generally/ > > Otherwise you need to qualify the term "generally" > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 4. PSN Binding Operation for SS-PW > > > > On receive, if the S-bit is set, other than following the processing > > SB> s/other/as well as/ > > procedure defined in Section 5.3.3 of [RFC4447], the receiving PE > (i.e. PE2) needs to determine whether to accept the indicated > tunnel/LSP in PSN Tunnel Sub-TLV. > > If the receiving PE (PE2) is also an active PE, and may have > initiated the PSN binding requests to the other PE (PE1), if the > received PSN tunnel/LSP is the same as it has been sent in the Label > Mapping message by PE2, then the signaling has converged on a > mutually agreed Tunnel/LSP. The binding operation is completed. > > Otherwise, the receiving PE (PE2) MUST compare its own Node ID > against the received Source Node ID. If it is numerically lower, the > > SB> You need to describe (hopefully by reference) the conversion of the > SB> address to an unsigned integer, otherwise the text above is ambiguous= . > SB> I am sure that I have some text that I wrote with Dan Frost on this > SB> but I cannot remember which RFC it was in. > > > > PE (PE2) will reply a Label Mapping message to complete the PW setup > SB> s/will reply/will reply with/ > and confirm the binding request. The PSN Tunnel Binding TLV in the > message MUST contain the same Source and Destination IDs/Numbers as > > > > Chen, et al. Expires March 4, 2016 [Page 9] > =0C > Internet-Draft Explicit PW to LSP Tunnels Binding September 2015 > > > in the received binding request, in the appropriate order. On the > other hand, if the receiving PE (PE2) has a Node ID that is > numerically higher than the Source Node ID carried in the PSN Tunnel > Binding TLV, it MUST reply a Label Release message with status code > > s/reply/reply with/ > > set to "Reject to use the suggested tunnel/LSPs" and the received PSN > Tunnel Binding TLV, and the PW will not be established. > > SB> The text of the reject message is not good English. > SB> I suggest : "Reject - unable to use the suggested tunnel/LSPs" > > To support co-routed binding, the receiving PE can select the > appropriated PSN tunnel/LSP for the reverse direction of the PW, so > long as the forwarding and reverse PSNs share the same route. > > SB> What do you mean by route? I think that you need to be more precise. > > > Initially, a PE (PE1) sends a Label Mapping message to the remote PE > (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared, > and the appropriate Source and Destination IDs/Numbers. In case of > unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the > Source IDs/Numbers, the Destination IDs/Numbers are set to zero and > left for PE2 to fill when responding the Label Mapping message. > > SB> s/fill/fill in/ or perhaps /complete/ > > > On receive, since PE2 is also an active PE, and may have initiated > the PSN binding requests to the other PE (PE1), if the received PSN > tunnel/LSP has the same route as the one that has been sent in the > Label Mapping message to PE1, then the signaling has converged. The > binding operation is completed. > > Otherwise, it needs to compare its own Node ID against the received > SB> who is "it"? > > Source Node ID. If it is numerically lower, > > SB> Again the definition of "numerically lower" needs to be provided. > > PE2 needs to find/ > establish a tunnel/LSP that meets the co-routed constraint, and reply > > SB> s/reply/reply with/ > > a Label Mapping message with a PSN Binding TLV that contains the > Source and Destination IDs/Numbers in the appropriate order. > SB> What does "appropriate order" mean? > > On the > other hand, if the receiving PE (PE2) has a Node ID that is > numerically higher than the Source Node ID carried in the PSN Tunnel > Binding TLV, it MUST reply a Label Release message with status code > > SB> s/reply/reply with/ > > set to "Reject to use the suggested tunnel/LSPs" and the received PSN > Tunnel Binding TLV. > > In both strict and co-routed bindings, if T-bit is set, the LSP > Number field MUST be set to zero. Otherwise, the field MUST contain > the actual LSP number for the related PSN LSP. > > After a PW established, the operators may choose to move the PWs from > the current tunnel/LSPs to other tunnel/LSPs. Or, the underlying PSN > tunnel is broken due to network failure. In this scenario, a new > Label Mapping message MUST be sent to update the changes. Note that > when T-bit is set, the working LSP broken will not trigger to update > the changes if there are protection LSPs. > > SB> I think that should be written as: > > After a PW is established, the operators may choose to move the PWs fr= om > the current tunnel/LSPs to other tunnel/LSPs. Also the underlying PSN > tunnel may break due to a network failure. When either of these sce= narios occur, a new > Label Mapping message MUST be sent to notify the remote PW of the chan= ges. Note that > when the T-bit is set, the working LSP broken will not provide this up= date > if there are protection LSPs in place. > > The message may carry a new PSN Tunnel Binding TLV, which contains > the new Source and Destination Numbers/IDs. The procedure for handlin= g of the new > > > > Chen, et al. Expires March 4, 2016 [Page 10] > =0C > Internet-Draft Explicit PW to LSP Tunnels Binding September 2015 > > > message is identical to the procedure already described in this > section. > > SB> NOTE I changed the previous sentence - but for got to keep the origin= al text. > > > However, if the new Label Binding message does not contain the PSN > Tunnel Binding TLV, it declares the removal of any co-routed/strict > constraints. The PEs may not map the PW to the underlying PSN on > purpose, the current independent PW to PSN binding will be used. > > SB> I do not understand the text from "However" to "used" > > > > Further, as an implementation option, the PEs should not remove the > > SB> I think that should be "PEs may choose not to" > > traffic from an operational PW, until the completion of the > underlying PSN tunnel/LSP changes. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > If the Label Mapping message is for forward direction, and S-PE1 > accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the > tunnel/LSP information for reverse-direction processing later on. If > the PSN binding request is not acceptable, S-PE1 MUST reply a Label > s/reply/reply with/ > > Release Message to the upstream PE (T-PE1) with Status Code set to > "Reject to use the suggested tunnel/LSPs". > > > SB> Please see earlier comment > > Chen, et al. Expires March 4, 2016 [Page 11] > =0C > Internet-Draft Explicit PW to LSP Tunnels Binding September 2015 > > > Otherwise, S-PE1 relays the Label Mapping message to the next S-PE > (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the > information of the new PSN tunnel/LSPs selected by S-PE1. S-PE2 and > subsequent S-PEs will repeat the same operation until the Label > Mapping message reaches to the remote T-PE (that is, T-PE2). > > If T-PE2 agrees with the requested tunnel/LSPs, it will reply a Label > > SB> what does "agrees with" mean? > > Mapping message to initiate to the binding process on the reverse > direction. The Label Mapping message contains the received PSN > Tunnel Binding TLV for confirmation purposes. > > When its upstream S-PE (S-PE2) receives the Label Mapping message, > the S-PE relays the Label Mapping message to its upstream adjacent > S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in > the PSN Tunnel sub-TLV. The same procedure will be applied on > subsequent S-PEs, until the message reaches to T-PE1 to complete the > PSN binding setup. > > During the binding process, if any PE does not agree to the requested > tunnel/LSPs, it can send a Label Release Message to its upstream > adjacent PE with Status Code set to "Reject to use the suggested > tunnel/LSPs". > > For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit, > reset the S-bit and indicates the suggested tunnel/LSP in PSN Tunnel > sub-TLV to the next-hop S-PE (S-PE1). > > During the MS-PW setup, the PEs have the option to ignore the > SB> s/to/of/ > suggested tunnel/LSP, and select another tunnel/LSP for the segment > > SB> s/and/and to/ > PW between itself and its upstream PE on reverse direction only if > SB> s/on/in/ > SB> below s/forwarding/forward/ > > > the tunnel/LSP is co-routed with the forwarding one. Otherwise, the > procedure is the same as the strict binding. > > The tunnel/LSPs may change after a MS-PW being established. When a > tunnel/LSP has changed, the PE that detects the change SHOULD select > an alternative tunnel/LSP for temporary use while negotiating with > other PEs following the procedure described in this section. > > 6. Security Considerations > > The ability to control which LSP to carry traffic from a PW can be a > > SB> s/which LSP/which LSP is used/ > > > > --001a1146e610ff5b1b05235c2ca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Just in case you=E2=80=99re confus= ed because you didn=E2=80=99t yet see a WG LC for this draft, Stewart jumpe= d the gun a little bit with his review (but that=E2=80=99s OK!). The draft = will be going into WG LC following the IETF meeting.

Cheers,
Andy

On Sat, Oct 31, 2015 at 6:52 AM, Stewart Bryant <stbr= yant@cisco.com> wrote:
=20 =20 =20
=20 
Authors

This is mainly editorial, but there are a few items such as the=20
comparison text that will need to be clarified before this
goes for further review. Experience shows that if they are not
fixed now they will surface again further down the line.

Thanks

Stewart


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0LDP Extensions for Pseudowire Binding to LSP Tunnels
            draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt

Abstract

   Many transport services require that user traffic, in the forms of
SB> s/forms/form/
  =C2=A0Pseudowires (PW), to be delivered on a single co-routed bidirection=
al
SB> s/to be/be/
  =C2=A0LSP or two LSPs that share the same routes.  In addition, the user
   traffic may traverse through multiple transport networks.

   This document defines an optional extension to LDP that enables the
   binding between PWs and the underlying LSPs.


=3D=3D=3D=3D=3D=3D=3D=3D


3.  Theory of Operation

   During PW setup, the PEs may select desired forwarding tunnels/LSPs,
SB> s/may select/may choose to select/
  =C2=A0and inform the remote T-PE/S-PEs about the desired reverse tunnels/
   LSPs.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   As defined in (Section 7.2.1, [RFC6073]), each PE may be generally
   categorized into active and passive roles:

d/generally/

Otherwise you need to qualify the term "generally"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A04.  PSN Binding Operation for SS-PW

=20

   On receive, if the S-bit is set, other than following the processing

SB> s/other/as well as/

   =C2=A0procedure defined in Section 5.3.3 of [RFC4447], the receiving PE
   (i.e.  PE2) needs to determine whether to accept the indicated
   tunnel/LSP in PSN Tunnel Sub-TLV.

   If the receiving PE (PE2) is also an active PE, and may have
   initiated the PSN binding requests to the other PE (PE1), if the
   received PSN tunnel/LSP is the same as it has been sent in the Label
   Mapping message by PE2, then the signaling has converged on a
   mutually agreed Tunnel/LSP.  The binding operation is completed.

   Otherwise, the receiving PE (PE2) MUST compare its own Node ID
   against the received Source Node ID.  If it is numerically lower, the

SB> You need to describe (hopefully by reference) the conversion of the
SB> address to an unsigned integer, otherwise the text above is ambiguou=
s.
SB> I am sure that I have some text that I wrote with Dan Frost on this
SB> but I cannot remember which RFC it was in.


=C2=A0
  =C2=A0PE (PE2) will reply a Label Mapping message to complete the PW setu=
p
SB> s/will reply/will reply with/
  =C2=A0and confirm the binding request.  The PSN Tunnel Binding TLV in the
   message MUST contain the same Source and Destination IDs/Numbers as



Chen, et al.              Expires March 4, 2016                 [Page 9]
=0C
Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015


   in the received binding request, in the appropriate order.  On the
   other hand, if the receiving PE (PE2) has a Node ID that is
   numerically higher than the Source Node ID carried in the PSN Tunnel
   Binding TLV, it MUST reply a Label Release message with status code

s/reply/reply with/

  =C2=A0set to "Reject to use the suggested tunnel/LSPs" and the =
received PSN
   Tunnel Binding TLV, and the PW will not be established.

SB> The text of the reject message is not good English.
SB> I suggest : "Reject - unable to use the suggested tunnel/LSPs&q=
uot;

  =C2=A0To support co-routed binding, the receiving PE can select the
   appropriated PSN tunnel/LSP for the reverse direction of the PW, so
   long as the forwarding and reverse PSNs share the same route.

SB> What do you mean by route? I think that you need to be more precise.


   =C2=A0Initially, a PE (PE1) sends a Label Mapping message to the remote =
PE
   (PE2) with the PSN Tunnel Binding TLV, with C-bit set, S-bit cleared,
   and the appropriate Source and Destination IDs/Numbers.  In case of
   unidirectional LSPs, the PSN Tunnel Binding TLV may only contain the
   Source IDs/Numbers, the Destination IDs/Numbers are set to zero and
   left for PE2 to fill when responding the Label Mapping message.

SB> s/fill/fill in/ or perhaps /complete/


=C2=A0On receive, since PE2 is also an active PE, and may have initiated
   the PSN binding requests to the other PE (PE1), if the received PSN
   tunnel/LSP has the same route as the one that has been sent in the
   Label Mapping message to PE1, then the signaling has converged.  The
   binding operation is completed.

   Otherwise, it needs to compare its own Node ID against the received
SB> who is "it"?

  =C2=A0Source Node ID.  If it is numerically lower,=20

SB> Again the definition of "numerically lower" needs to be pr=
ovided.

   PE2 needs to find/
   establish a tunnel/LSP that meets the co-routed constraint, and reply

SB> s/reply/reply with/

  =C2=A0a Label Mapping message with a PSN Binding TLV that contains the
   Source and Destination IDs/Numbers in the appropriate order.=20
SB> What does "appropriate order" mean?

   On the
   other hand, if the receiving PE (PE2) has a Node ID that is
   numerically higher than the Source Node ID carried in the PSN Tunnel
   Binding TLV, it MUST reply a Label Release message with status code

SB> s/reply/reply with/

  =C2=A0set to "Reject to use the suggested tunnel/LSPs" and the =
received PSN
   Tunnel Binding TLV.

   In both strict and co-routed bindings, if T-bit is set, the LSP
   Number field MUST be set to zero.  Otherwise, the field MUST contain
   the actual LSP number for the related PSN LSP.

   After a PW established, the operators may choose to move the PWs from
  =C2=A0the current tunnel/LSPs to other tunnel/LSPs.  Or, the underlying P=
SN
   tunnel is broken due to network failure.  In this scenario, a new
   Label Mapping message MUST be sent to update the changes.  Note that
   when T-bit is set, the working LSP broken will not trigger to update
   the changes if there are protection LSPs.

SB> I think that should be written as:

   After a PW is established, the operators may choose to move the PWs from
  =C2=A0the current tunnel/LSPs to other tunnel/LSPs. Also  the underlying =
PSN
   tunnel may  break due to a network failure.  When either of  these scena=
rios occur, a new
   Label Mapping message MUST be sent to notify the remote PW of the change=
s.  Note that
   when the T-bit is set, the working LSP broken will not provide this upda=
te
   if there are protection LSPs in place.

   The message may carry a new PSN Tunnel Binding TLV, which contains
   the new Source and Destination Numbers/IDs.  The procedure for handling =
of the new



Chen, et al.              Expires March 4, 2016                [Page 10]
=0C
Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015


   message is identical to the procedure already described in this
   section.

SB> NOTE I changed the previous sentence - but for got to keep the origi=
nal text.


  =C2=A0However, if the new Label Binding message does not contain the PSN
   Tunnel Binding TLV, it declares the removal of any co-routed/strict
   constraints.  The PEs may not map the PW to the underlying PSN on
   purpose, the current independent PW to PSN binding will be used.

SB> I do not understand the text from "However" to "used&=
quot;



  =C2=A0Further, as an implementation option, the PEs should not remove the

SB> I think that should be "PEs may choose not to"

  =C2=A0traffic from an operational PW, until the completion of the
   underlying PSN tunnel/LSP changes.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   If the Label Mapping message is for forward direction, and S-PE1
   accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the
   tunnel/LSP information for reverse-direction processing later on.  If
   the PSN binding request is not acceptable, S-PE1 MUST reply a Label
s/reply/reply with/

  =C2=A0Release Message to the upstream PE (T-PE1) with Status Code set to
   "Reject to use the suggested tunnel/LSPs".


SB> Please see earlier comment

=C2=A0Chen, et al.              Expires March 4, 2016                [Page =
11]
=0C
Internet-Draft     Explicit PW to LSP Tunnels Binding     September 2015


   Otherwise, S-PE1 relays the Label Mapping message to the next S-PE
   (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the
   information of the new PSN tunnel/LSPs selected by S-PE1.  S-PE2 and
   subsequent S-PEs will repeat the same operation until the Label
   Mapping message reaches to the remote T-PE (that is, T-PE2).

   If T-PE2 agrees with the requested tunnel/LSPs, it will reply a Label

SB> what does "agrees with" mean?

   =C2=A0Mapping message to initiate to the binding process on the reverse
   direction.  The Label Mapping message contains the received PSN
   Tunnel Binding TLV for confirmation purposes.

   When its upstream S-PE (S-PE2) receives the Label Mapping message,
   the S-PE relays the Label Mapping message to its upstream adjacent
   S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in
   the PSN Tunnel sub-TLV.  The same procedure will be applied on
   subsequent S-PEs, until the message reaches to T-PE1 to complete the
   PSN binding setup.

   During the binding process, if any PE does not agree to the requested
   tunnel/LSPs, it can send a Label Release Message to its upstream
   adjacent PE with Status Code set to "Reject to use the suggested
   tunnel/LSPs".

   For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit,
   reset the S-bit and indicates the suggested tunnel/LSP in PSN Tunnel
   sub-TLV to the next-hop S-PE (S-PE1).

   During the MS-PW setup, the PEs have the option to ignore the
SB> s/to/of/
  =C2=A0suggested tunnel/LSP, and select another tunnel/LSP for the segment

SB> s/and/and to/
  =C2=A0PW between itself and its upstream PE on reverse direction only if
SB> s/on/in/
SB> below s/forwarding/forward/


  =C2=A0the tunnel/LSP is co-routed with the forwarding one.  Otherwise, th=
e
   procedure is the same as the strict binding.

   The tunnel/LSPs may change after a MS-PW being established.  When a
   tunnel/LSP has changed, the PE that detects the change SHOULD select
   an alternative tunnel/LSP for temporary use while negotiating with
   other PEs following the procedure described in this section.

6.  Security Considerations

   The ability to control which LSP to carry traffic from a PW can be a

SB> s/which LSP/which LSP is used/

<end>

--001a1146e610ff5b1b05235c2ca2-- From nobody Fri Oct 30 18:17:53 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86741ACE46 for ; Fri, 30 Oct 2015 18:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ChK3sIN2TpM for ; Fri, 30 Oct 2015 18:17:50 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14E11ACE3F for ; Fri, 30 Oct 2015 18:17:49 -0700 (PDT) Received: by wmec75 with SMTP id c75so23791622wme.1 for ; Fri, 30 Oct 2015 18:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=okOjzCedVIKFDkceJsDx/9eeWPUnyM1rTnOb83s00eM=; b=TdKkv0OuUp1tg0xxmsgQrbNZPPmDs7RnK8BoNEIH5xSaD/SnvvItC+sEjTxqZEJMYC JGkamImOKV6ilCzVpte7VR4GNAvxZThGiIQxoa/P4lJ3+t2HEUCK+zNzsS9rSaUWRke+ i3YGfkZfpVi+qp3KdT06rrOotVxu56Gp9sEbevhygS2vquBYiZr+C8kTC+GBPxu4UXiU cOm7FibeiwsdPxgtsm2NSwqNzmBKLNu3fPYvo18rNH1EfQgnfhaCjbME+8KlaZ9VthNv 7s6NWGo/Z5uym0wX5o1ioVW9LANhwXpAZSbagRJqfGTHk+InCyLGB044SuvdtH4hmXRR lnxA== X-Received: by 10.28.12.78 with SMTP id 75mr939975wmm.85.1446254268229; Fri, 30 Oct 2015 18:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.195.10 with HTTP; Fri, 30 Oct 2015 18:17:28 -0700 (PDT) From: "Andrew G. Malis" Date: Sat, 31 Oct 2015 10:17:28 +0900 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=001a114449f2e9ae5205235c4f33 Archived-At: Subject: [Pals] Regarding the PALS meeting in Yokohama X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 01:17:52 -0000 --001a114449f2e9ae5205235c4f33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stewart will be unable to join us in Yokohama for the IETF meeting. Dave Sinicrope, our WG Secretary, will be co-chairing the meeting with me. Scott Mansfield has graciously volunteered to take the minutes in Dave=E2= =80=99s place. Thanks, Scott! The agenda is still very light, there is currently just one presentation following the chair=E2=80=99s WG status slides. Patrice, you=E2=80=99ll hav= e all of the time that you need! Please get your slides to Dave ASAP, if you haven=E2=80= =99t already done so. See you all soon in Yokohama! Cheers, Andy --001a114449f2e9ae5205235c4f33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart will be unable to join us in Yokohama for the IETF= meeting.

Dave Sinicrope, our WG Secretary, will be co-c= hairing the meeting with me. Scott Mansfield has graciously volunteered to = take the minutes in Dave=E2=80=99s place. Thanks, Scott!

The agenda is still very light, there is currently just one presenta= tion following the chair=E2=80=99s WG status slides. Patrice, you=E2=80=99l= l have all of the time that you need! Please get your slides to Dave ASAP, = if you haven=E2=80=99t already done so.

See you al= l soon in Yokohama!

Cheers,
Andy

--001a114449f2e9ae5205235c4f33-- From nobody Sat Oct 31 00:57:40 2015 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB331A0364 for ; Sat, 31 Oct 2015 00:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1tOoVAnQ6oy for ; Sat, 31 Oct 2015 00:57:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1D71A034C for ; Sat, 31 Oct 2015 00:57:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZP28593; Sat, 31 Oct 2015 07:57:34 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 31 Oct 2015 07:57:33 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.229]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Sat, 31 Oct 2015 15:57:27 +0800 From: Mach Chen To: "stbryant@cisco.com" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org" Thread-Topic: WGC comments on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt Thread-Index: AQHRE11i2ToUBVAmWkW6HqUqHB1zop6FMllwgAAAJrA= Date: Sat, 31 Oct 2015 07:57:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Stewart Bryant , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] WGC comments on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-04.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 07:57:40 -0000 SGkgU3Rld2FydCwNCg0KVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IQ0KDQpQbGVhc2Ug c2VlIHNvbWUgcmVwbGllcyBpbmxpbmUsIGVhc3kgcGFydHMgc25pcGVkLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpNYWNoDQoNCj4gDQo+IA0KPiAgICBJZiB0aGUgcmVjZWl2aW5nIFBFIChQRTIpIGlzIGFs c28gYW4gYWN0aXZlIFBFLCBhbmQgbWF5IGhhdmUNCj4gICAgaW5pdGlhdGVkIHRoZSBQU04gYmlu ZGluZyByZXF1ZXN0cyB0byB0aGUgb3RoZXIgUEUgKFBFMSksIGlmIHRoZQ0KPiAgICByZWNlaXZl ZCBQU04gdHVubmVsL0xTUCBpcyB0aGUgc2FtZSBhcyBpdCBoYXMgYmVlbiBzZW50IGluIHRoZSBM YWJlbA0KPiAgICBNYXBwaW5nIG1lc3NhZ2UgYnkgUEUyLCB0aGVuIHRoZSBzaWduYWxpbmcgaGFz IGNvbnZlcmdlZCBvbiBhDQo+ICAgIG11dHVhbGx5IGFncmVlZCBUdW5uZWwvTFNQLiAgVGhlIGJp bmRpbmcgb3BlcmF0aW9uIGlzIGNvbXBsZXRlZC4NCj4gDQo+ICAgIE90aGVyd2lzZSwgdGhlIHJl Y2VpdmluZyBQRSAoUEUyKSBNVVNUIGNvbXBhcmUgaXRzIG93biBOb2RlIElEDQo+ICAgIGFnYWlu c3QgdGhlIHJlY2VpdmVkIFNvdXJjZSBOb2RlIElELiAgSWYgaXQgaXMgbnVtZXJpY2FsbHkgbG93 ZXIsIHRoZQ0KPiANCj4gU0I+IFlvdSBuZWVkIHRvIGRlc2NyaWJlIChob3BlZnVsbHkgYnkgcmVm ZXJlbmNlKSB0aGUgY29udmVyc2lvbiBvZiB0aGUNCj4gU0I+IGFkZHJlc3MgdG8gYW4gdW5zaWdu ZWQgaW50ZWdlciwgb3RoZXJ3aXNlIHRoZSB0ZXh0IGFib3ZlIGlzIGFtYmlndW91cy4NCj4gU0I+ IEkgYW0gc3VyZSB0aGF0IEkgaGF2ZSBzb21lIHRleHQgdGhhdCBJIHdyb3RlIHdpdGggRGFuIEZy b3N0IG9uIHRoaXMNCj4gU0I+IGJ1dCBJIGNhbm5vdCByZW1lbWJlciB3aGljaCBSRkMgaXQgd2Fz IGluLg0KDQpJIGZvdW5kIHRoZSBmb2xsb3dpbmcgaW4gcmZjNjA3MzoNCiAgIlRoZSBkZXRlcm1p bmF0aW9uIG9mIHdoaWNoIFQtUEUgYXNzdW1lcyB0aGUgYWN0aXZlIHJvbGUgU0hPVUxEIGJlDQog ICBkb25lIGFzIGZvbGxvd3M6DQoNCiAgIFRoZSBTQUlJIGFuZCBUQUlJIGFyZSBjb21wYXJlZCBh cyB1bnNpZ25lZCBpbnRlZ2VyczsgaWYgdGhlIFNBSUkgaXMNCiAgIGxhcmdlciwgdGhlbiB0aGUg VC1QRSBhc3N1bWVzIHRoZSBhY3RpdmUgcm9sZS4iDQoNCkFuYWxvZyB0byBhYm92ZSwgSSBjaGFu Z2UgdGhlIHRlc3QgYXMgZm9sbG93cywgaG93IGRvIHlvdSB0aGluaz8NCiJPdGhlcndpc2UsIHRo ZSByZWNlaXZpbmcgUEUgKFBFMikgTVVTVCBjb21wYXJlIGl0cyBvd24gTm9kZSBJRCBhZ2FpbnN0 IHRoZSByZWNlaXZlZCBTb3VyY2UgTm9kZSBJRCBhcyB1bnNpZ25lZCBpbnRlZ2Vycy4gSWYgdGhl IHJlY2VpdmVkIFNvdXJjZSBOb2RlIElEIGlzIGxhcmdlciwgLi4uIg0KDQoNCj4gDQo+IMKgT24g cmVjZWl2ZSwgc2luY2UgUEUyIGlzIGFsc28gYW4gYWN0aXZlIFBFLCBhbmQgbWF5IGhhdmUgaW5p dGlhdGVkDQo+ICAgIHRoZSBQU04gYmluZGluZyByZXF1ZXN0cyB0byB0aGUgb3RoZXIgUEUgKFBF MSksIGlmIHRoZSByZWNlaXZlZCBQU04NCj4gICAgdHVubmVsL0xTUCBoYXMgdGhlIHNhbWUgcm91 dGUgYXMgdGhlIG9uZSB0aGF0IGhhcyBiZWVuIHNlbnQgaW4gdGhlDQo+ICAgIExhYmVsIE1hcHBp bmcgbWVzc2FnZSB0byBQRTEsIHRoZW4gdGhlIHNpZ25hbGluZyBoYXMgY29udmVyZ2VkLiAgVGhl DQo+ICAgIGJpbmRpbmcgb3BlcmF0aW9uIGlzIGNvbXBsZXRlZC4NCj4gDQo+ICAgIE90aGVyd2lz ZSwgaXQgbmVlZHMgdG8gY29tcGFyZSBpdHMgb3duIE5vZGUgSUQgYWdhaW5zdCB0aGUgcmVjZWl2 ZWQNCj4gU0I+IHdobyBpcyAiaXQiPw0KDQpJdCBpcyBQRTIgLCBhbmQgd2lsbCB1c2UgIlBFMiIg aW5zdGVhZC4NCg0KPiANCj4gICDCoFNvdXJjZSBOb2RlIElELiAgSWYgaXQgaXMgbnVtZXJpY2Fs bHkgbG93ZXIsDQo+IA0KPiANCj4gICDCoGEgTGFiZWwgTWFwcGluZyBtZXNzYWdlIHdpdGggYSBQ U04gQmluZGluZyBUTFYgdGhhdCBjb250YWlucyB0aGUNCj4gICAgU291cmNlIGFuZCBEZXN0aW5h dGlvbiBJRHMvTnVtYmVycyBpbiB0aGUgYXBwcm9wcmlhdGUgb3JkZXIuDQo+IFNCPiBXaGF0IGRv ZXMgImFwcHJvcHJpYXRlIG9yZGVyIiBtZWFuPw0KDQpIb3cgYWJvdXQgdGhpczoNCg0KImEgTGFi ZWwgTWFwcGluZyBtZXNzYWdlIHdpdGggYSBQU04gQmluZGluZyBUTFYgdGhhdCBjb250YWlucyB0 aGUgU291cmNlIGFuZCBEZXN0aW5hdGlvbiBJRHMvTnVtYmVycyBpbiB0aGUgYXBwcm9wcmlhdGUg b3JkZXIgKHdoZXJlIHRoZSBzb3VyY2UgaXMgUEUyIGFuZCBQRTEgYmVjb21lcyB0aGUgZGVzdGlu YXRpb24pLiINCiANCj4gDQo+ICAgwqBIb3dldmVyLCBpZiB0aGUgbmV3IExhYmVsIEJpbmRpbmcg bWVzc2FnZSBkb2VzIG5vdCBjb250YWluIHRoZSBQU04NCj4gICAgVHVubmVsIEJpbmRpbmcgVExW LCBpdCBkZWNsYXJlcyB0aGUgcmVtb3ZhbCBvZiBhbnkgY28tcm91dGVkL3N0cmljdA0KPiAgICBj b25zdHJhaW50cy4gIFRoZSBQRXMgbWF5IG5vdCBtYXAgdGhlIFBXIHRvIHRoZSB1bmRlcmx5aW5n IFBTTiBvbg0KPiAgICBwdXJwb3NlLCB0aGUgY3VycmVudCBpbmRlcGVuZGVudCBQVyB0byBQU04g YmluZGluZyB3aWxsIGJlIHVzZWQuDQo+IA0KPiBTQj4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUg dGV4dCBmcm9tICJIb3dldmVyIiB0byAidXNlZCINCg0KVGhlIHR1bm5lbCBiaW5kaW5nIHVwZGF0 ZSBpbmNsdWRlcyB0d28gb3B0aW9uczoNCg0KMS4JY2hhbmdlIGZyb20gdHVubmVsIEEgdG8gdHVu bmVsIEIsIG9yIA0KMi4JcmVtb3ZlIHRoZSBwcmV2aW91c2x5IGV4cGxpY2l0IHR1bm5lbCAoZS5n LiwgdHVubmVsIEEpIGJpbmRpbmcgYW5kIHJldmVydCB0byB0aGUgc3RhdHVzIHdoZW4gc3VjaCBl eHBsaWNpdCBiaW5kaW5nIGRvZXMgbm90IHVzZWQsICBpdCBsZXRzIHRoZSBQRXMgdG8gZGV0ZXJt aW5lIHdoaWNoIHR1bm5lbCB3aWxsIGJlIHVzZWQsIGp1c3QgYXMgdGhlIGltcGxlbWVudGF0aW9u IHdpdGhvdXQgdGhpcyBkb2N1bWVudDsgIA0KDQpUaGUgYWJvdmUgcGFyYWdyYXBoIGlzIHRhbGtp bmcgYWJvdXQgb3B0aW9uIDIuDQoNCkkgcmVhZCBpdCBhZ2FpbiBhbmQgZm91bmQgdGhhdCDigJxU aGUgUEVzIG1heSBub3QgbWFwIHRoZSBQVyB0byB0aGUgdW5kZXJseWluZyBQU04gb24gcHVycG9z ZeKAnSBpcyByZWR1bmRhbnQgYW5kIGNvbmZ1c2luZy4gU28gSSByZW1vdmUgaXQsIGhvdyBhYm91 dCB0aGUgZm9sbG93aW5nIHRleHQ/DQoiSG93ZXZlciwgaWYgdGhlIG5ldyBMYWJlbCBNYXBwaW5n IG1lc3NhZ2UgZG9lcyBub3QgY29udGFpbiB0aGUgUFNOIFR1bm5lbCBCaW5kaW5nIFRMViwgaXQg ZGVjbGFyZXMgdGhlIHJlbW92YWwgb2YgYW55IGNvLXJvdXRlZC9zdHJpY3QgY29uc3RyYWludHMu IFRoZSBjdXJyZW50IGluZGVwZW5kZW50IFBXIHRvIFBTTiBiaW5kaW5nIHdpbGwgYmUgdXNlZC4i DQoNCj4gICAgT3RoZXJ3aXNlLCBTLVBFMSByZWxheXMgdGhlIExhYmVsIE1hcHBpbmcgbWVzc2Fn ZSB0byB0aGUgbmV4dCBTLVBFDQo+ICAgICh0aGF0IGlzLCBTLVBFMiksIHdpdGggdGhlIFBTTiBU dW5uZWwgc3ViLVRMViBjYXJyeWluZyB0aGUNCj4gICAgaW5mb3JtYXRpb24gb2YgdGhlIG5ldyBQ U04gdHVubmVsL0xTUHMgc2VsZWN0ZWQgYnkgUy1QRTEuICBTLVBFMiBhbmQNCj4gICAgc3Vic2Vx dWVudCBTLVBFcyB3aWxsIHJlcGVhdCB0aGUgc2FtZSBvcGVyYXRpb24gdW50aWwgdGhlIExhYmVs DQo+ICAgIE1hcHBpbmcgbWVzc2FnZSByZWFjaGVzIHRvIHRoZSByZW1vdGUgVC1QRSAodGhhdCBp cywgVC1QRTIpLg0KPiANCj4gICAgSWYgVC1QRTIgYWdyZWVzIHdpdGggdGhlIHJlcXVlc3RlZCB0 dW5uZWwvTFNQcywgaXQgd2lsbCByZXBseSBhIExhYmVsDQo+IA0KPiBTQj4gd2hhdCBkb2VzICJh Z3JlZXMgd2l0aCIgbWVhbj8NCg0KSG93IGFib3V0ICJhY2NlcHRzIj8NCg0K