From jgs@juniper.net Wed Jun 6 13:31:52 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DDF21F8778 for ; Wed, 6 Jun 2012 13:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COWaZYim1oWS for ; Wed, 6 Jun 2012 13:31:51 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id E636B21F8776 for ; Wed, 6 Jun 2012 13:31:49 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT8++LRfcfcDlp9DpHQFdJNViPVbmstQU@postini.com; Wed, 06 Jun 2012 13:31:50 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Wed, 6 Jun 2012 13:29:10 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jun 2012 16:29:09 -0400 Message-ID: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> To: MIME-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: rtg-dir@ietf.org, draft-ietf-trill-rbridge-bfd.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:31:53 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-trill-rbridge-bfd-05.txt with attention given to = -06 as well. Reviewer: John Scudder=20 Review Date: June 6, 2012=20 IETF LC End Date: June 6, 2012=20 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be = resolved before publication. Comments: None. Major Issues: No major issues found (although see minor issue 5 below). Minor Issues: 1. It is not clear why demand mode was explicitly excluded. TRILL would = actually seem to be a reasonable fit for demand mode. 2. "there will be only a single TRILL BFD Control session between two RBridges over a given interface visible to TRILL." I was not able to unambiguously parse this clause. I suggest rewriting = it, possibly with reference to a pair of RBridges RB1 and RB2 and their = interfaces RB1_Int1 and RB2_Int1. Or something like that. 3. "the entire TRILL BFD Echo protocol specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is RECOMMENDED that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back." The "RECOMMENDED" above seems like an abuse of RFC 2119 terminology. As = a reminder, RECOMMENDED is a synonym for SHOULD which in turn basically = means "MUST unless you have a good reason". So the RECOMMENDED = contradicts "left to the discretion", and furthermore it's kind of = pointless to normatively-in-all-caps issue what amounts to very general = advice. One heuristic I sometimes use: can I write a conformance test = for the text in question? If not, it is very likely not really = normative.=20 Changing to a lower-case "recommended" would fix this. 4. In two places text like the following appears: Is the M-bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Echo is beyond the scope of this document. If multi-destination doesn't make sense in the context of TRILL, it is = fine to exclude it by enforcing that the M-bit be zero. However, I = normally parse "beyond the scope of this document" to mean something = like "we may do it in the future but haven't worked it out yet". By = forcing the M-bit to be zero, you're placing multi-destination *in* = scope, inasmuch as you are actively forbidding it from being supported.=20= Presumably the sentence about "beyond the scope" was meant to justify = this decision. Perhaps the comment about "scope" should be dropped and a = different justifying sentence used. (Or the sentence omitted = altogether.) 5. Presumably the Security Area reviewer may raise this, but the = Security Considerations section seems to be misused. My understanding = (confirmed by referring to RFC 3552 Section 5) is that the Security = Considerations section is intended to be an analysis of issues that = arise from the operation of the protocol defined in the rest of the = document, including but not limited to the security features of that = protocol.=20 This document's Security Considerations section instead specifies how = authentication is to be done, though it doesn't provide an analysis of = it or of any broader issues. I presume the section should be retitled = (e.g., to "Authentication") and a proper Security Considerations section = added. (This would probably be a "major issue" if I were the Security Area = reviewer, but I'm not.) Nits: 1. "The BFD (Bi-directional Forwarding Detection [RFC5880]) protocol = provides a low-overhead, short- duration detection of failures" The use of the term "short-duration" seems broken, to the extent that I = don't know what you really mean. Maybe you mean that failures are = expected to be detected quickly? In any case, I suggest you rewrite = this, maybe with more words, to say what you mean. 2. " This document describes a TRILL encapsulation for BFD packets for networks that do not use IP addressing or for ones where it is not desireable." You misspelled "desirable". But also, what is the referent of "it"? Use = of IP addressing? As written, I parse that clause as "networks that use = IP addressing but in an undesirable way" which is probably not what you = meant. I'd actually suggest just dropping the "or" clause. 3. "When running BFD over TRILL both Single Hop as well as in Multi Hop sessions are supported." This should either be "... both single-hop and multihop ..." or "When = running BFD over TRILL single-hop as well as multihop sessions ...". Also, are the capitalizations really needed? As far as I know neither = term is proper. I have flagged other capitalization errors where = noticed, below. 4. "BFD over TRILL supports the Echo function, however this can be used for only Single hop sessions." Should be "this can only be used for single-hop sessions." 5. "For Multi Hop sessions the Hop count check can be disabled if the MH flag is one." Should be "For multihop sessions the hop count check..." 6. "Note that TRILL BFD provides OAM facilities for the TRILL Data = plane" Should be "TRILL data plane" (or less likely, "TRILL Data Plane" if it's = really proper). 7. "TRILL BFD Echo frames SHOULD be sent on a link only if the following=09= points are met." (Draft -06) Should be "following conditions". 8. "TRILL BFD frames over one hop for such purposes SHOULD be sent with priority 7." Suggest "frame priority 7" for clarity. 9. "although work is being done in the Area [MultiBFD]." Should be "in this area" (or "in the area"). 10. "Consistent with TRILL's goal of being able to operate with = minimum configuration, the default for BFD authentication between neighbor RBridges is based on that state of IS-IS shared secret authentication for Hello between those RBridges. However, if such BFD authentication is configured then its configuration is independent of that for IS-IS security." a. Should be "... based on the state of IS-IS ..." b. Suggest adding "as detailed below" to make it be: "based on the state = of IS-IS shared secret authentication for Hello between those RBridges, = as detailed below." c. It seems what you are really trying to say is that the default = authentication for BFD is inherited from the IS-IS authentication = configuration as given below, but that the default can be overridden. = The way you have said it is pretty hard to understand. Suggest rewording = it more as stated here. 11. " HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ), IS-IS-shared-key )" Is it common to use the pipe character for concatenation? I'm not = familiar with it for such, and found it confusing. 12. " Echo frames to be returned by that neighbor SHOULD be = authenticated and such authenticate SHOULD use different keying material from other types of authentication." Should be: "... and such authentication SHOULD ..." 13. "IANA is request" Should be: "IANA is requested" From d3e3e3@gmail.com Mon Jun 11 13:48:37 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F8111E8083 for ; Mon, 11 Jun 2012 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7bqjE1taWUx for ; Mon, 11 Jun 2012 13:48:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89121F8505 for ; Mon, 11 Jun 2012 13:48:36 -0700 (PDT) Received: by yhq56 with SMTP id 56so3442564yhq.31 for ; Mon, 11 Jun 2012 13:48:35 -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=rk+Kuvy/vcbc33Ho1yahNWJi9b+4x7dmkD+cWoGKHwI=; b=0hSxOnyRpppURX6lJI8tPs8JNzgQmX7cu0nxeAOB+12PUkYwOHFCq66mt/P6PUyOQG TL9ftcoHYliCpKtkad4eoOBAA1KdPkyfh3FPdEoiYSsWbzHDm5yu4WTLfVP052czlINU ROFGgiBfm2TLdGOp4VAvMmomBhGZafOnNinuBlsio7J8xjoPMnxqjVplJkabFDvsv5aL 8u+SsAdz9YMfxfL3FhQMpYJq09sl5r48iwCIbQfCD2REyZGLbF9MD0jhckOb6NW5j1e6 MJxfyv7m2B5LhivVDEN9OhJq8OZSxmd8q8zW/gDBF06t3eEm5dLoPLqOZfKR2ODH55xR g5bw== Received: by 10.50.236.97 with SMTP id ut1mr7080423igc.50.1339447715023; Mon, 11 Jun 2012 13:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Mon, 11 Jun 2012 13:48:14 -0700 (PDT) In-Reply-To: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> References: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> From: Donald Eastlake Date: Mon, 11 Jun 2012 16:48:14 -0400 Message-ID: To: "John G. Scudder" Content-Type: text/plain; charset=ISO-8859-1 Cc: Vishwas Manral , rtg-dir@ietf.org, draft-ietf-trill-rbridge-bfd.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 20:48:37 -0000 Hi John, Thanks for your thorough review. See below: On Wed, Jun 6, 2012 at 4:29 PM, John G. Scudder wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review > is to provide assistance to the Routing ADs. For more information > about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-trill-rbridge-bfd-05.txt with attention given > to -06 as well. > Reviewer: John Scudder > Review Date: June 6, 2012 > IETF LC End Date: June 6, 2012 > Intended Status: Proposed Standard > > Summary: > > I have some minor concerns about this document that I think should > be resolved before publication. > > > Comments: > > None. > > > Major Issues: > > No major issues found (although see minor issue 5 below). > > > Minor Issues: > > 1. It is not clear why demand mode was explicitly excluded. TRILL > would actually seem to be a reasonable fit for demand mode. Demand modes generally assumes some other way of testing connectivity. While you can do that with IS-IS Hellos, they are (modulo deliberate jitter to avoid synchonrization) limited to no more often than once a second. However, if BFD Echo is supported, it would be reasonable to test with BFD Echo and then use Demand mode BFD with that. [RF5880] also suggests that Demand mode may be useful if there are a very large number of stations attached to a multi-access link to avoid an N**2 effect getting too large. So I'm thinking that you are correct and the use of Demand should be allowed. > 2. "there will be only a single TRILL BFD > Control session between two RBridges over a given interface visible > to TRILL." > > I was not able to unambiguously parse this clause. I suggest > rewriting it, possibly with reference to a pair of RBridges RB1 and > RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something like > that. Peraps it should say something closer to "There will be no more than one TRILL BFD Control session from any RBridge RB1 to RBridge RB2 for each RB1 TRILL port." > 3. "the entire TRILL BFD Echo protocol specific > data area is considered opaque and left to the discretion of the > originating RBridge. Nevertheless, it is RECOMMENDED that this > data include information by which the originating RBridge can > authenticate the returned BFD Echo frame and confirm the neighbor > that echoed the frame back." > > The "RECOMMENDED" above seems like an abuse of RFC 2119 > terminology. As a reminder, RECOMMENDED is a synonym for SHOULD > which in turn basically means "MUST unless you have a good > reason". So the RECOMMENDED contradicts "left to the discretion", > and furthermore it's kind of pointless to normatively-in-all-caps > issue what amounts to very general advice. One heuristic I sometimes > use: can I write a conformance test for the text in question? If > not, it is very likely not really normative. > > Changing to a lower-case "recommended" would fix this. I agree that in this case the "RECOMMENDED"s should be lower cased. > 4. In two places text like the following appears: > > Is the M-bit in the TRILL Header non-zero? If so, discard the > frame. TRILL support of multi-destination BFD Echo is beyond the > scope of this document. > > If multi-destination doesn't make sense in the context of TRILL, it > is fine to exclude it by enforcing that the M-bit be zero. However, > I normally parse "beyond the scope of this document" to mean > something like "we may do it in the future but haven't worked it out > yet". By forcing the M-bit to be zero, you're placing > multi-destination *in* scope, inasmuch as you are actively > forbidding it from being supported. > > Presumably the sentence about "beyond the scope" was meant to > justify this decision. Perhaps the comment about "scope" should be > dropped and a different justifying sentence used. (Or the sentence > omitted altogether.) Multi-destination makes sense for TRILL. It is just not yet standardized, as far as I know, for BFD. Perhaps the "beyond the scope" verbage should be removed and a note added somewhere such as "(Multi-destination BFD is a work in progress [...].)" > 5. Presumably the Security Area reviewer may raise this, but the > Security Considerations section seems to be misused. My > understanding (confirmed by referring to RFC 3552 Section 5) is that > the Security Considerations section is intended to be an analysis of > issues that arise from the operation of the protocol defined in the > rest of the document, including but not limited to the security > features of that protocol. > > This document's Security Considerations section instead specifies > how authentication is to be done, though it doesn't provide an > analysis of it or of any broader issues. I presume the section > should be retitled (e.g., to "Authentication") and a proper Security > Considerations section added. > > (This would probably be a "major issue" if I were the Security Area > reviewer, but I'm not.) As far as I can tell (and I'm a member of the Security Directorate), the Security Area considers this a non-issue. However, I've got no problem with moving this material to a new "Default Authentication" section or the like. > Nits: > > 1. "The BFD (Bi-directional Forwarding Detection [RFC5880]) protocol > provides a low-overhead, short- duration detection of failures" > > The use of the term "short-duration" seems broken, to the extent > that I don't know what you really mean. Maybe you mean that failures > are expected to be detected quickly? In any case, I suggest you > rewrite this, maybe with more words, to say what you mean. How about: "The BFD (Bi-directional Forwarding Detection [RFC5880]) protocol provides a low-overhead method for the rapid detection of connectivity failures" > 2. " This document describes a TRILL encapsulation for BFD packets > for networks that do not use IP addressing or for ones where it > is not desireable." > > You misspelled "desirable". But also, what is the referent of "it"? > Use of IP addressing? As written, I parse that clause as "networks > that use IP addressing but in an undesirable way" which is probably > not what you meant. I'd actually suggest just dropping the "or" > clause. I'm fine with just dropping the "or" clause. How about "This document describes a TRILL encapsulation for BFD packets for networks that do not use IP addressing and forward based on the TRILL Header." > 3. "When running BFD over TRILL both Single Hop as well as in Multi > Hop sessions are supported." > > This should either be "... both single-hop and multihop ..." or > "When running BFD over TRILL single-hop as well as multihop sessions > ...". > > Also, are the capitalizations really needed? As far as I know > neither term is proper. I have flagged other capitalization errors > where noticed, below. I think going with "both single-hop and multihop" would be best. > 4. "BFD over TRILL supports the Echo function, however this > can be used for only Single hop sessions." > > Should be "this can only be used for single-hop sessions." OK. > 5. "For Multi Hop > sessions the Hop count check can be disabled if the MH flag is > one." > > Should be "For multihop sessions the hop count check..." OK. Perhaps, "For multihop sessions the hop count check can be disabled by setting the MH flag to one." > 6. "Note that TRILL BFD provides OAM facilities for the TRILL Data > plane" > > Should be "TRILL data plane" (or less likely, "TRILL Data Plane" if > it's really proper). OK. I think lower case is better. > 7. "TRILL BFD Echo frames SHOULD be sent on a link only if the > following points are met." (Draft -06) > > Should be "following conditions". OK. > 8. "TRILL BFD frames over one hop for such > purposes SHOULD be sent with priority 7." > > Suggest "frame priority 7" for clarity. I think that is a good suggestion. > 9. "although work is being done in the Area [MultiBFD]." > > Should be "in this area" (or "in the area"). OK. I think "this area" is best. > 10. "Consistent with TRILL's goal of being able to operate with > minimum configuration, the default for BFD authentication > between neighbor RBridges is based on that state of IS-IS > shared secret authentication for Hello between those > RBridges. However, if such BFD authentication is configured > then its configuration is independent of that for IS-IS > security." > > a. Should be "... based on the state of IS-IS ..." OK. > b. Suggest adding "as detailed below" to make it be: "based on the > state of IS-IS shared secret authentication for Hello between those > RBridges, as detailed below." OK. > c. It seems what you are really trying to say is that the default > authentication for BFD is inherited from the IS-IS authentication > configuration as given below, but that the default can be > overridden. The way you have said it is pretty hard to > understand. Suggest rewording it more as stated here. OK. How about: The BFD authentication keys between neighbor RBridges by default are derived from the IS-IS shared secret authentication keys for Hellos between those RBridges as detailed below. This is consistent with TRILL's goal of being able to operate with minimum configuration. However, such BFD authentication keys MAY be configured to some other value. > 11. " HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ), > IS-IS-shared-key )" > > Is it common to use the pipe character for concatenation? I'm not > familiar with it for such, and found it confusing. Yes, vertical bar is a standard character to indicate byte string concatenation. I have no problem, in the two instances, with adding "where "|" indicates concatenation" or the like to the text. > 12. " Echo frames to be returned by that neighbor SHOULD be > authenticated and such authenticate SHOULD use different keying > material from other types of authentication." > > Should be: "... and such authentication SHOULD ..." OK. > 13. "IANA is request" > > Should be: "IANA is requested" OK. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From jgs@juniper.net Mon Jun 11 14:04:30 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBBA21F8582 for ; Mon, 11 Jun 2012 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW2stALdkryc for ; Mon, 11 Jun 2012 14:04:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2021F8573 for ; Mon, 11 Jun 2012 14:04:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT9ZdWIWOc6cP/GxIV9pdTDJiHOhKT05X@postini.com; Mon, 11 Jun 2012 14:04:29 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 11 Jun 2012 14:02:46 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: "John G. Scudder" In-Reply-To: Date: Mon, 11 Jun 2012 17:02:45 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> To: Donald Eastlake X-Mailer: Apple Mail (2.1278) Cc: Vishwas Manral , "rtg-dir@ietf.org" , "draft-ietf-trill-rbridge-bfd.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:04:30 -0000 Hi Donald, Comments below only where I had something to say other than "OK". You = can take that as read otherwise. On Jun 11, 2012, at 4:48 PM, Donald Eastlake wrote: ... >> Minor Issues: ... >> 4. In two places text like the following appears: >>=20 >> Is the M-bit in the TRILL Header non-zero? If so, discard the >> frame. TRILL support of multi-destination BFD Echo is beyond the >> scope of this document. >>=20 >> If multi-destination doesn't make sense in the context of TRILL, it >> is fine to exclude it by enforcing that the M-bit be zero. However, >> I normally parse "beyond the scope of this document" to mean >> something like "we may do it in the future but haven't worked it out >> yet". By forcing the M-bit to be zero, you're placing >> multi-destination *in* scope, inasmuch as you are actively >> forbidding it from being supported. >>=20 >> Presumably the sentence about "beyond the scope" was meant to >> justify this decision. Perhaps the comment about "scope" should be >> dropped and a different justifying sentence used. (Or the sentence >> omitted altogether.) >=20 > Multi-destination makes sense for TRILL. It is just not yet > standardized, as far as I know, for BFD. Perhaps the "beyond the > scope" verbage should be removed and a note added somewhere such as > "(Multi-destination BFD is a work in progress [...].)" By requiring the M-bit to be zero you effectively preclude the later = introduction of multi-destination, do you not? >> 5. Presumably the Security Area reviewer may raise this, but the >> Security Considerations section seems to be misused. My >> understanding (confirmed by referring to RFC 3552 Section 5) is that >> the Security Considerations section is intended to be an analysis of >> issues that arise from the operation of the protocol defined in the >> rest of the document, including but not limited to the security >> features of that protocol. >>=20 >> This document's Security Considerations section instead specifies >> how authentication is to be done, though it doesn't provide an >> analysis of it or of any broader issues. I presume the section >> should be retitled (e.g., to "Authentication") and a proper Security >> Considerations section added. >>=20 >> (This would probably be a "major issue" if I were the Security Area >> reviewer, but I'm not.) >=20 > As far as I can tell (and I'm a member of the Security Directorate), > the Security Area considers this a non-issue. However, I've got no > problem with moving this material to a new "Default Authentication" > section or the like. OK. (As an aside, if the Security Directorate considers this a non-issue, = maybe it's time to revise RFC 3552? I say this as an occasional author = of Security Considerations sections and not with regard to your draft.) --John= From alvaro.retana@hp.com Mon Jun 11 18:09:38 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFE411E8098 for ; Mon, 11 Jun 2012 18:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pryrqBZM7fJL for ; Mon, 11 Jun 2012 18:09:35 -0700 (PDT) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by ietfa.amsl.com (Postfix) with ESMTP id 190C411E8099 for ; Mon, 11 Jun 2012 18:09:35 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 85D873803B; Tue, 12 Jun 2012 01:09:30 +0000 (UTC) Received: from G2W1813G.americas.hpqcorp.net (16.238.8.212) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 12 Jun 2012 01:06:48 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.116]) by G2W1813G.americas.hpqcorp.net ([fe80::2d8c:5671:edf9:26b0%12]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 01:06:48 +0000 From: "Retana, Alvaro" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-pim-pop-count-06 Thread-Index: Ac1IN6Ah8d96yCm2RZaa2cAMART8yg== Date: Tue, 12 Jun 2012 01:06:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.16] Content-Type: multipart/alternative; boundary="_000_C03AAF38AD209F4BB02BC0A34B774CE70518A7G2W2446americashp_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-pim-pop-count.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-pim-pop-count-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:09:38 -0000 --_000_C03AAF38AD209F4BB02BC0A34B774CE70518A7G2W2446americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-pim-pop-count-06 Reviewer: Alvaro Retana Review Date: June 11, 2012 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resol= ved before publication. Comments: In general, I found the draft to be well written, the intent, functionality= and operation easy to follow. Major Issues: No major issues found. Minor Issues: 1. Section 2. The first paragraph is a little confusing: it goes fr= om sending Join/Prune messages, to how a router indicates support for the d= raft in a Hello message, back to when to send the Join/Prune messages, back= to the format of the Hello option... It would be nice to order the thoughts/process in the respective sections: = Section 2 covers the Hello Option and 3 the Join Attribute. Note that Sec= tion 3 already includes the needed text so there's no need to put it here a= s well. 2. The text explaining the Hello Option sounds contradictory to me. = The OptionLength is specified as 0, and the text reads: "In order to allow = future updates of this specification that may include an option value, impl= ementations of this document MUST accept and process this option also if th= e length is non-zero. Implementations of this specification MUST accept an= d process the option ignoring any option value that may be included." If the OptionLength is 0, then no value field should exist. Presumably if = future extensions would want to include a value, then they wouldn't want it= to be ignored (as the second MUST mandates now). 3. Section 3...There are no IANA considerations as to how to assign t= he Flags. The same applies to the Option bits later in the text. 4. P Flag. If I understand correctly, the P Flag is set by a router= when all its downstream neighbors support the draft...which seems to resul= t in a hop-by-hop indication of the support. Let's assume routers A, B, C = and D in a line...if C supports the spec, then B should set the P flag towa= rds A...but if D doesn't have support, C will still use the Hello Option to= indicate it's support, *and* not set the P flag towards B. In this case,= A assumes that the "entire sub-tree" is accounting capable, but only A, B = and C are. Should the value received from the downstream be kept if not se= t? Did I miss something? 5. Transit Oif-List Count. It defines a transit branch as one that h= as "no members...". This definition contradicts the fact that a link may b= e both a transit link and a stub link, from section 1.2. 6. Transit Oif-List Count. The value is not just the number or oifs = (as mentioned in the first sentence), but the additive value of all transit= branches on the tree (as in the next to last sentence), right? If so, it = should be clarified. 7. Stub Oif-List Count. Same comment as above about the additive val= ue. 8. Section 4...on the last paragraph. Should the "should not" on the= last sentence be "SHOULD NOT"? Nits: 1. Section 3...the first field in the Flags is described as "Unalloc/= Reserved", but then it's explained as "Unallocated Flags". The same appl= ies to the Option bits later in the text. Thanks! Alvaro. --_000_C03AAF38AD209F4BB02BC0A34B774CE70518A7G2W2446americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected as the Routing Directorate reviewer fo= r this draft. The Routing Directorate seeks to review all routing or routin= g-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review i= s to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see http://www.ietf.org/iesg/directorate/routin= g.html

Although these comments are primarily for the use of the Ro= uting ADs, it would be helpful if you could consider them along with any ot= her IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. 

Document: draft-ietf-pim-pop-count-06
Reviewer: Alvaro=
 Retana 
Review Date: June 11, 2012
Intended Status: Experimental&nbs=
p;            &=
nbsp;            &nb=
sp;     

Summary:

I have some minor concerns about this document that I think= should be resolved before publication.

Comments:

In general, I found the draft to be well written, the inten= t, functionality and operation easy to follow.

Major Issues:

No major issues found.

Minor Issues:<= /p>

1.     &= nbsp; Section 2.   The first paragraph is a lit= tle confusing: it goes from sending Join/Prune messages, to how a router in= dicates support for the draft in a Hello message, back to when to send the = Join/Prune messages, back to the format of the Hello option…

 

It would be nice to order the thoughts/proces= s in the respective sections:  Section 2 covers the Hello Option and 3= the Join Attribute.  Note that Section 3 already includes the needed = text so there’s no need to put it here as well.

 

=
2.    &nb=
sp;  The text explaining t=
he Hello Option sounds contradictory to me.  The OptionLength is speci=
fied as 0, and the text reads: “In order to allow future updates of t=
his specification that may include an option value, implementations of this=
 document MUST accept and process this option also if the length is non-zer=
o.  Implementations of this specification MUST accept and process the =
option ignoring any option value that may be included.”
 
If the OptionLength is 0, then=
 no value field should exist.  Presumably if future extensions would w=
ant to include a value, then they wouldn’t want it to be ignored (as =
the second MUST mandates now).

 

3.     &= nbsp; Section 3…There are no IANA considerations as= to how to assign the Flags.  The same applies to the Option bits late= r in the text.

 

4.     &= nbsp; P Flag.   If I understand correctly, the = P Flag is set by a router when all its downstream neighbors support the dra= ft…which seems to result in a hop-by-hop indication of the support. &= nbsp;Let’s assume routers A, B, C and D in a line…if C supports the spec, then B should set the P flag towards A…but if D= doesn’t have support, C will still use the Hello Option to indicate = it’s support, *and* not set the P flag towards B.   = In this case, A assumes that the “entire sub-tree” is accountin= g capable, but only A, B and C are.  Should the value received from the= downstream be kept if not set?   Did I miss something?

 

5.     &= nbsp; Transit Oif-List Count.  It defines a transit = branch as one that has “no members…”.  This definiti= on contradicts the fact that a link may be both a transit link and a stub l= ink, from section 1.2.

 

6.     &= nbsp; Transit Oif-List Count.  The value is not just= the number or oifs (as mentioned in the first sentence), but the additive = value of all transit branches on the tree (as in the next to last sentence)= , right?  If so, it should be clarified.

 

7.     &= nbsp; Stub Oif-List Count.  Same comment as above ab= out the additive value.

 

8.     &= nbsp; Section 4…on the last paragraph.  Should= the “should not” on the last sentence be “SHOULD NOTR= 21;?

 

 

Nits:

 

1.     &= nbsp; Section 3…the first field in the Flags is des= cribed as “Unalloc/Reserved”, but then it’s explained as = “Unallocated Flags”.    The same applies to the = Option bits later in the text.

 

 

Thanks!

 

Alvaro.

 

--_000_C03AAF38AD209F4BB02BC0A34B774CE70518A7G2W2446americashp_-- From eric.gray@ericsson.com Mon Jun 11 18:16:13 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5C11E809A for ; Mon, 11 Jun 2012 18:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGR5zCdHP-xE for ; Mon, 11 Jun 2012 18:16:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C774911E8098 for ; Mon, 11 Jun 2012 18:16:12 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5C1G8jl004852; Mon, 11 Jun 2012 20:16:09 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 11 Jun 2012 21:16:02 -0400 From: Eric Gray To: Donald Eastlake Date: Mon, 11 Jun 2012 21:15:59 -0400 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt Thread-Index: Ac1IFdKVzff8TbB0RnS+o73kJAZYgwAH49KQ Message-ID: References: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Vishwas Manral , "rtg-dir@ietf.org" , "John G. Scudder" , "draft-ietf-trill-rbridge-bfd.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:16:13 -0000 Donald, I may regret weighing in on this, but I strongly agree with John's comment on the Security Considerations section below. The Security Considerations section needs an introduction=20 that - at the very least - explains why the section only=20 addresses authentication. In fact, the section only talks about what authentication is to be used, without providing and indication of why. I personally doubt that the Security Directorate feels -=20 as you say - that this is not significant. The section should describe the security concerns associated with the protocol and/or encapsulations associated with this draft - either directly, or by reference. At the moment the section does not do this, even by giving a pointer to someplace else where some analysis has already=20 been done. And this is not difficult to fix. Minimally, the authors can point to Security Considerations in RFC 5881 (which, in turn, points to RFC 5880). RFC 5880, provides a very good analysis, IMO, and it makes=20 sense for this analysis to be re-used by reference in this draft. -- Eric -----Original Message----- From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf = Of John G. Scudder Sent: Monday, June 11, 2012 5:03 PM To: Donald Eastlake Cc: Vishwas Manral; rtg-dir@ietf.org; draft-ietf-trill-rbridge-bfd.all@tool= s.ietf.org; rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt Hi Donald, Comments below only where I had something to say other than "OK". You can t= ake that as read otherwise. On Jun 11, 2012, at 4:48 PM, Donald Eastlake wrote: ... >> Minor Issues: ... >> 4. In two places text like the following appears: >>=20 >> Is the M-bit in the TRILL Header non-zero? If so, discard the >> frame. TRILL support of multi-destination BFD Echo is beyond the >> scope of this document. >>=20 >> If multi-destination doesn't make sense in the context of TRILL, it >> is fine to exclude it by enforcing that the M-bit be zero. However, >> I normally parse "beyond the scope of this document" to mean >> something like "we may do it in the future but haven't worked it out >> yet". By forcing the M-bit to be zero, you're placing >> multi-destination *in* scope, inasmuch as you are actively >> forbidding it from being supported. >>=20 >> Presumably the sentence about "beyond the scope" was meant to >> justify this decision. Perhaps the comment about "scope" should be >> dropped and a different justifying sentence used. (Or the sentence >> omitted altogether.) >=20 > Multi-destination makes sense for TRILL. It is just not yet > standardized, as far as I know, for BFD. Perhaps the "beyond the > scope" verbage should be removed and a note added somewhere such as > "(Multi-destination BFD is a work in progress [...].)" By requiring the M-bit to be zero you effectively preclude the later introd= uction of multi-destination, do you not? >> 5. Presumably the Security Area reviewer may raise this, but the >> Security Considerations section seems to be misused. My >> understanding (confirmed by referring to RFC 3552 Section 5) is that >> the Security Considerations section is intended to be an analysis of >> issues that arise from the operation of the protocol defined in the >> rest of the document, including but not limited to the security >> features of that protocol. >>=20 >> This document's Security Considerations section instead specifies >> how authentication is to be done, though it doesn't provide an >> analysis of it or of any broader issues. I presume the section >> should be retitled (e.g., to "Authentication") and a proper Security >> Considerations section added. >>=20 >> (This would probably be a "major issue" if I were the Security Area >> reviewer, but I'm not.) >=20 > As far as I can tell (and I'm a member of the Security Directorate), > the Security Area considers this a non-issue. However, I've got no > problem with moving this material to a new "Default Authentication" > section or the like. OK. (As an aside, if the Security Directorate considers this a non-issue, maybe= it's time to revise RFC 3552? I say this as an occasional author of Securi= ty Considerations sections and not with regard to your draft.) --John= From d3e3e3@gmail.com Mon Jun 11 18:46:05 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0DF21F84DF for ; Mon, 11 Jun 2012 18:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD7hPQXXUsG1 for ; Mon, 11 Jun 2012 18:46:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7A421F84D8 for ; Mon, 11 Jun 2012 18:46:04 -0700 (PDT) Received: by yhq56 with SMTP id 56so3612505yhq.31 for ; Mon, 11 Jun 2012 18:46:04 -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:content-transfer-encoding; bh=SpxSC7a/kJnBaol5N2MRygVpQ3YO5mALVxlFAZI9XDE=; b=FFzUTEjOLlQ40JskiveKs3akDPMk8m78kioGbDeaOUlJiAMUtoVk+EDAJ7+HMARGfi iH/63VxqZ7uGqhAuPoW9gnaMuYd1QkvZTMShRgEz70bnq5Ap72ucORsAbxIRuiVAYSvc Yu7vpO2+qckljCKTnKhBQQItZqJLbsu/qxD4q1+qeAYGQspBxQke8mIBsfprBKmw7V1q UV//B5YCOTDJLCTf7tBc9LgaqTs/QVbdGtqGf03VTlgehwHnW3HOM0hkvVReMomXzfFQ ybU48f1DXdOD9ZjS2fS7Yoam+AkzvJf4ISvogki0eyG0TIuwNaaAuTSejd9yZztInPth xYUA== Received: by 10.50.194.200 with SMTP id hy8mr7353421igc.58.1339465563797; Mon, 11 Jun 2012 18:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Mon, 11 Jun 2012 18:45:43 -0700 (PDT) In-Reply-To: References: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> From: Donald Eastlake Date: Mon, 11 Jun 2012 21:45:43 -0400 Message-ID: To: Eric Gray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Vishwas Manral , "rtg-dir@ietf.org" , "John G. Scudder" , "draft-ietf-trill-rbridge-bfd.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:46:05 -0000 Hi Eri, Thanks for your comments. I agree that at least a reference to RFC 5881 should be added and probably some additional material on security considerations. I think you misunderstood my response to John Scudder where perhaps I did not express myself clearly enough. I was just trying to say that, as far as I can tell, the Security Directorate would not be concerned that the material currently in the Security Considerations is in that Section. I did not mean my comment to apply to any possible omission from the Security Considerations section. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Jun 11, 2012 at 9:15 PM, Eric Gray wrote: > Donald, > > I may regret weighing in on this, but I strongly agree with > John's comment on the Security Considerations section below. > > The Security Considerations section needs an introduction > that - at the very least - explains why the section only > addresses authentication. =A0In fact, the section only talks > about what authentication is to be used, without providing > and indication of why. > > I personally doubt that the Security Directorate feels - > as you say - that this is not significant. =A0The section > should describe the security concerns associated with the > protocol and/or encapsulations associated with this draft > - either directly, or by reference. > > At the moment the section does not do this, even by giving > a pointer to someplace else where some analysis has already > been done. > > And this is not difficult to fix. =A0Minimally, the authors > can point to Security Considerations in RFC 5881 (which, > in turn, points to RFC 5880). > > RFC 5880, provides a very good analysis, IMO, and it makes > sense for this analysis to be re-used by reference in this > draft. > > -- > Eric > > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behal= f Of John G. Scudder > Sent: Monday, June 11, 2012 5:03 PM > To: Donald Eastlake > Cc: Vishwas Manral; rtg-dir@ietf.org; draft-ietf-trill-rbridge-bfd.all@to= ols.ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt > > Hi Donald, > > Comments below only where I had something to say other than "OK". You can= take that as read otherwise. > > On Jun 11, 2012, at 4:48 PM, Donald Eastlake wrote: > ... >>> Minor Issues: > ... >>> 4. In two places text like the following appears: >>> >>> =A0Is the M-bit in the TRILL Header non-zero? If so, discard the >>> =A0frame. =A0TRILL support of multi-destination BFD Echo is beyond the >>> =A0scope of this document. >>> >>> If multi-destination doesn't make sense in the context of TRILL, it >>> is fine to exclude it by enforcing that the M-bit be zero. However, >>> I normally parse "beyond the scope of this document" to mean >>> something like "we may do it in the future but haven't worked it out >>> yet". By forcing the M-bit to be zero, you're placing >>> multi-destination *in* scope, inasmuch as you are actively >>> forbidding it from being supported. >>> >>> Presumably the sentence about "beyond the scope" was meant to >>> justify this decision. Perhaps the comment about "scope" should be >>> dropped and a different justifying sentence used. (Or the sentence >>> omitted altogether.) >> >> Multi-destination makes sense for TRILL. It is just not yet >> standardized, as far as I know, for BFD. Perhaps the "beyond the >> scope" verbage should be removed and a note added somewhere such as >> "(Multi-destination BFD is a work in progress [...].)" > > By requiring the M-bit to be zero you effectively preclude the later intr= oduction of multi-destination, do you not? > >>> 5. Presumably the Security Area reviewer may raise this, but the >>> Security Considerations section seems to be misused. My >>> understanding (confirmed by referring to RFC 3552 Section 5) is that >>> the Security Considerations section is intended to be an analysis of >>> issues that arise from the operation of the protocol defined in the >>> rest of the document, including but not limited to the security >>> features of that protocol. >>> >>> This document's Security Considerations section instead specifies >>> how authentication is to be done, though it doesn't provide an >>> analysis of it or of any broader issues. I presume the section >>> should be retitled (e.g., to "Authentication") and a proper Security >>> Considerations section added. >>> >>> (This would probably be a "major issue" if I were the Security Area >>> reviewer, but I'm not.) >> >> As far as I can tell (and I'm a member of the Security Directorate), >> the Security Area considers this a non-issue. However, I've got no >> problem with moving this material to a new "Default Authentication" >> section or the like. > > OK. > > (As an aside, if the Security Directorate considers this a non-issue, may= be it's time to revise RFC 3552? I say this as an occasional author of Secu= rity Considerations sections and not with regard to your draft.) > > --John From gih@apnic.net Mon Jun 11 21:28:12 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4976911E8098 for ; Mon, 11 Jun 2012 21:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwaFcL97NM9V for ; Mon, 11 Jun 2012 21:28:11 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id ED9E511E8087 for ; Mon, 11 Jun 2012 21:28:09 -0700 (PDT) Received: from [IPv6:2001:388:1000:110:d5ed:b61f:1b9f:bb49] (unknown [IPv6:2001:388:1000:110:d5ed:b61f:1b9f:bb49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 22A60B683D; Tue, 12 Jun 2012 14:28:08 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Jun 2012 14:28:07 +1000 Message-Id: To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: rtg-dir@ietf.org, draft-idr-rfc4893bis.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-idr-rfc4893bis-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 04:28:12 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-idr-rfc4893bis-06.txt Reviewer: Geoff Huston Review Date: 12 June 2012 IETF LC End Date: mnot known Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The draft provides a small number of updates to RFC4893, fixing up some residual grammatical errors, clarifying, or altering some of the normative text, and providing a new section on error handling. The document is clear, and easily understood. Major Issues: none found Minor Issues: 1. Ambiguity in the specification The last sentence of the final paragraph of section 3 states "This AS number [referring to AS_TRANS] is also placed in the "My Autonomous System" field of the OPEN message originated by a NEW BGP speaker, if the speaker does not have a (globally unique) 2-octet AS number." is this "if" an instance of "if and only if"? Or not? i.e. if the local BGP speaker is within AS 10 (say) and it is 4-octet capable, then does the preceding text require that the BGP speaker MUST use the value "10" as "My Autonomous System" number, or MAY use the number 10 (or, alternatively MAY use the number 23456), or MUST NOT use the number 10 at all? While this is not a major issue, some additional clarification appears to be appropriate here. 2. MAY, SHALL, or SHOULD? Section 4.1 states: "A BGP speaker that supports 4-octet Autonomous System numbers SHALL advertise this to its peers using the BGP Capability Advertisements." (RFC 4893 used SHOULD) Yet Section 7 (Transition) states: "To simplify transition, this document assumes that an Autonomous System could start using a 4-octet AS number only after all the BGP speakers within that Autonomous System have been upgraded to support 4-octet AS numbers." I observe that during an upgrade of routers within an AS it may be the case that the network administrator would like to upgrade the capability of all BGP speakers within the AS to support 4-octet AS numbers and then and only then have the BGP speakers announce this support to their peers. i.e. having the capability to operate in NEW mode need not necessarily imply a mandatory (SHALL) announcement to the peers of a BGP speaker. Or was this the intended effect of this change from SHOULD to SHALL in the document? 3. missing use of normative language The last sentence of section 4.2.1 states "However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it)." The "could be used instead" implies to this reviewer that there are other solutions, yet the document is only proposing a single approach. So it is my understanding from the remainder of the text of this document that the intent here is that: "AS_TRANS MUST be used when the NEW speaker does not have a 2-octet AS number (even if a multiple Autonomous System would use it)." 4. Error Handling Section 4 provides a specification for error handling of update in BGP. It would be helpful to note here that this section provides an UPDATE to RFC 4271 with respect to the error conditions noted here and their handling. Nits: none found thanks, Geoff Huston From gih@apnic.net Mon Jun 11 21:43:15 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C5D11E8095 for ; Mon, 11 Jun 2012 21:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.265 X-Spam-Level: X-Spam-Status: No, score=-101.265 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqPKpmNxGBi5 for ; Mon, 11 Jun 2012 21:43:14 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A905F11E8087 for ; Mon, 11 Jun 2012 21:43:13 -0700 (PDT) Received: from [202.158.221.120] (unknown [202.158.221.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A0C97B683D; Tue, 12 Jun 2012 14:43:12 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 12 Jun 2012 14:43:11 +1000 Message-Id: <71002B69-8E77-4392-82C3-D6AA5EA16FAE@apnic.net> To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: rtg-dir@ietf.org, draft-ietf-idr-rfc4893bis.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-idr-rfc4893bis-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 04:43:15 -0000 (resent with correct draft author address added) Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-idr-rfc4893bis-06.txt Reviewer: Geoff Huston Review Date: 12 June 2012 IETF LC End Date: mnot known Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The draft provides a small number of updates to RFC4893, fixing up some residual grammatical errors, clarifying, or altering some of the normative text, and providing a new section on error handling. The document is clear, and easily understood. Major Issues: none found Minor Issues: 1. Ambiguity in the specification The last sentence of the final paragraph of section 3 states "This AS number [referring to AS_TRANS] is also placed in the "My Autonomous System" field of the OPEN message originated by a NEW BGP speaker, if the speaker does not have a (globally unique) 2-octet AS number." is this "if" an instance of "if and only if"? Or not? i.e. if the local BGP speaker is within AS 10 (say) and it is 4-octet capable, then does the preceding text require that the BGP speaker MUST use the value "10" as "My Autonomous System" number, or MAY use the number 10 (or, alternatively MAY use the number 23456), or MUST NOT use the number 10 at all? While this is not a major issue, some additional clarification appears to be appropriate here. 2. MAY, SHALL, or SHOULD? Section 4.1 states: "A BGP speaker that supports 4-octet Autonomous System numbers SHALL advertise this to its peers using the BGP Capability Advertisements." (RFC 4893 used SHOULD) Yet Section 7 (Transition) states: "To simplify transition, this document assumes that an Autonomous System could start using a 4-octet AS number only after all the BGP speakers within that Autonomous System have been upgraded to support 4-octet AS numbers." I observe that during an upgrade of routers within an AS it may be the case that the network administrator would like to upgrade the capability of all BGP speakers within the AS to support 4-octet AS numbers and then and only then have the BGP speakers announce this support to their peers. i.e. having the capability to operate in NEW mode need not necessarily imply a mandatory (SHALL) announcement to the peers of a BGP speaker. Or was this the intended effect of this change from SHOULD to SHALL in the document? 3. missing use of normative language The last sentence of section 4.2.1 states "However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it)." The "could be used instead" implies to this reviewer that there are other solutions, yet the document is only proposing a single approach. So it is my understanding from the remainder of the text of this document that the intent here is that: "AS_TRANS MUST be used when the NEW speaker does not have a 2-octet AS number (even if a multiple Autonomous System would use it)." 4. Error Handling Section 4 provides a specification for error handling of update in BGP. It would be helpful to note here that this section provides an UPDATE to RFC 4271 with respect to the error conditions noted here and their handling. Nits: none found thanks, Geoff Huston From dimitri.papadimitriou@alcatel-lucent.com Tue Jun 12 02:51:06 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8D521F861E for ; Tue, 12 Jun 2012 02:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7dPFH3sNl2v for ; Tue, 12 Jun 2012 02:51:06 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id AD86421F85DF for ; Tue, 12 Jun 2012 02:51:05 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5C9j04V005714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Jun 2012 11:51:03 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 12 Jun 2012 11:50:25 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "rtg-ads@tools.ietf.org" Date: Tue, 12 Jun 2012 11:49:28 +0200 Thread-Topic: RtgDir review: draft-ietf-pim-ecmp-03.txt Thread-Index: Ac1Ifpbys7JqbJGuSfi/vgm6vxOs3g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "rtg-dir@ietf.org" , "draft-ietf-pim-ecmp-03.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-pim-ecmp-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:51:06 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-pim-ecmp-03.txt Reviewer: Dimitri Papadimitriou Review Date: June 12, 2012 IETF LC End Date: date-if-known Intended Status: copy-from-I-D Summary: I have significant concerns about this document and recommend that the = Routing ADs discuss these issues further with the authors. Comments: In terms of readability, the introduction shall be a separate section fr= om the protocol operation overview and applicability. Major Issues: Section 2.1: From the statement "a PIM ECMP Redirect message is sent by an upstream router to notify downstream routers to redirect PIM Joins to the new RPF neighbor via a different interface. . When the downstream routers receive this message, they SHOULD trigger PIM Joins toward the new RPF neighbor specified in the packet."=20 Comment: How the upstream neighbor (preferred upstream router) determine= s the alternate neighbor ? How the proposed algorithm ensures an upstream neighbor will ever be det= ermined if the selection rules aren't consistent or known among PIM routers= . The document specifies the conditions under which ECMP redirect has to be= sent not the selection criteria leading to that decision. The alternative = would be to specify tie breaking rules (not just the information) such that= at least the downstream neighbor can determine the best among the non-desi= red upstream neighbors. This also contradicts the statement that pruning is= to be used to process incoming " Receiving ECMP Redirect" message. Note: If the assumption made by the document is that all PIM routers kno= w each other preferences/metrics why to propose this mechanism at first pla= ce ? Section 3.2: a preference-based process indicates (at least partially) s= equential process, whereas the middle paragraphs of that section reads as i= f the Join messages would be used as a preference discovery process. Not co= nvinced that a preference/metric discovery wouldn't be better included in t= he Hello exchanges.=20 Section 3.3: how the proposed approach behaves in case upstream neighbor= changes its preference rules ? Minor Issues: Section 2: "This usually leads to inefficient or ineffective use of netw= ork resources." any reference to make this statement quantitative ? =20 Section 3.5 s/3.5. Packet Format/Message and Option Format Coding of preference and metrics type/value shall be specified. =20 Thanks, -dimitri. ----- Homepage: From stbryant@cisco.com Tue Jun 12 03:36:08 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240BD21F85DF for ; Tue, 12 Jun 2012 03:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Ahb-YnvduC for ; Tue, 12 Jun 2012 03:36:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDD621F858D for ; Tue, 12 Jun 2012 03:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4938; q=dns/txt; s=iport; t=1339497366; x=1340706966; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uSHh4pqKNQoNuDvsSjLezBL9d2xW1gs8FaeU3a4RGWk=; b=dui//U64TIfMiQ3YkKgnhQS99WlD99880PDeRp2j6yosH3WkxkXznrHx Lx7OLX1DFbGgRfnp75Dvm+A9f3CMDSZ4Hsh7UsjYfoYmWvZ8kVZlExtzx WLS3oTHs/Gvf0uLtVuT+B/uiyIrYiDCmGBybGD7NyZV/A3pGnNRmoQbm6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALUa10+Q/khR/2dsb2JhbABFtT6BB4IYAQEBBBIBAiNAARALFAQJFg8JAwIBAgFFEwEHAQEFEgeHaQuZG4NHEJwTiyMnhWoDlR+OFYEEYoJhgVc X-IronPort-AV: E=Sophos;i="4.75,757,1330905600"; d="scan'208";a="139529755" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2012 10:36:04 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5CAa31P020727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 10:36:04 GMT Received: from dhcp-bdlk10-data-vlan300-64-103-106-111.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q5CAa2p3005040; Tue, 12 Jun 2012 11:36:03 +0100 (BST) Message-ID: <4FD71B92.5080308@cisco.com> Date: Tue, 12 Jun 2012 11:36:02 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: draft-ietf-idr-rfc4893bis.all@tools.ietf.org References: <71002B69-8E77-4392-82C3-D6AA5EA16FAE@apnic.net> In-Reply-To: <71002B69-8E77-4392-82C3-D6AA5EA16FAE@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Geoff Huston , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-idr-rfc4893bis-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 10:36:08 -0000 Authors Please can you respond to each of Geoff's points indicating whether you accept the change or not (if not please explain why). The edits look relatively straight forward, so we can use editor's notes if you wish, although a quick respin is cleaner. Thanks Stewart On 12/06/2012 05:43, Geoff Huston wrote: > (resent with correct draft author address added) > > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-idr-rfc4893bis-06.txt > Reviewer: Geoff Huston > Review Date: 12 June 2012 > IETF LC End Date: mnot known > Intended Status: Standards Track > > Summary: > > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > The draft provides a small number of updates to RFC4893, fixing up some > residual grammatical errors, clarifying, or altering some of the > normative text, and providing a new section on error handling. > > The document is clear, and easily understood. > > Major Issues: > > none found > > Minor Issues: > > 1. Ambiguity in the specification > > The last sentence of the final paragraph of section 3 states > > "This AS number [referring to AS_TRANS] is also placed in the "My > Autonomous System" field of the OPEN message originated by a NEW BGP > speaker, if the speaker does not have a (globally unique) 2-octet AS > number." > > is this "if" an instance of "if and only if"? Or not? > > i.e. if the local BGP speaker is within AS 10 (say) and it is 4-octet > capable, then does the preceding text require that the BGP speaker > MUST use the value "10" as "My Autonomous System" number, or > MAY use the number 10 (or, alternatively MAY use the number 23456), > or MUST NOT use the number 10 at all? > > While this is not a major issue, some additional clarification appears > to be appropriate here. > > 2. MAY, SHALL, or SHOULD? > > Section 4.1 states: > > "A BGP speaker that supports 4-octet Autonomous System numbers SHALL > advertise this to its peers using the BGP Capability Advertisements." > > (RFC 4893 used SHOULD) > > Yet Section 7 (Transition) states: > > "To simplify transition, this document assumes that an Autonomous > System could start using a 4-octet AS number only after all the BGP > speakers within that Autonomous System have been upgraded to support > 4-octet AS numbers." > > I observe that during an upgrade of routers within an AS it may be > the case that the network administrator would like to upgrade the > capability of all BGP speakers within the AS to support 4-octet AS > numbers and then and only then have the BGP speakers announce this > support to their peers. i.e. having the capability to operate in NEW > mode need not necessarily imply a mandatory (SHALL) announcement to > the peers of a BGP speaker. Or was this the intended effect of this > change from SHOULD to SHALL in the document? > > > 3. missing use of normative language > > The last sentence of section 4.2.1 states > > "However, this document does not assume that an Autonomous System with > NEW speakers has to have a globally unique 2-octet AS number -- > AS_TRANS could be used instead (even if a multiple Autonomous System > would use it)." > > The "could be used instead" implies to this reviewer that there are > other solutions, yet the document is only proposing a single > approach. So it is my understanding from the remainder of the text of > this document that the intent here is that: > > "AS_TRANS MUST be used when the NEW speaker does not have a 2-octet > AS number (even if a multiple Autonomous System would use it)." > > 4. Error Handling > > Section 4 provides a specification for error handling of update in > BGP. It would be helpful to note here that this section provides an > UPDATE to RFC 4271 with respect to the error conditions noted here > and their handling. > > > Nits: > > none found > > thanks, > > Geoff Huston > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jgs@juniper.net Tue Jun 12 08:44:33 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A4D21F86AB for ; Tue, 12 Jun 2012 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXhusrcieFgP for ; Tue, 12 Jun 2012 08:44:33 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3736821F851A for ; Tue, 12 Jun 2012 08:44:25 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT9dj2LXnZ1zV2CMCECUYZ6trNMhtUg8e@postini.com; Tue, 12 Jun 2012 08:44:32 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012 08:43:16 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: "John G. Scudder" In-Reply-To: Date: Tue, 12 Jun 2012 11:43:14 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <507532A7-4BAD-4263-9F66-D9A036CC5BAF@juniper.net> References: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> To: Donald Eastlake X-Mailer: Apple Mail (2.1278) Cc: Vishwas Manral , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-trill-rbridge-bfd.all@tools.ietf.org" , Eric Gray Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:44:34 -0000 On Jun 11, 2012, at 9:45 PM, Donald Eastlake wrote: > I think you misunderstood my response to John Scudder where perhaps I > did not express myself clearly enough. I was just trying to say that, > as far as I can tell, the Security Directorate would not be concerned > that the material currently in the Security Considerations is in that > Section. I did not mean my comment to apply to any possible omission > from the Security Considerations section. Thanks for the clarification. I had also not understood that (as might = have been evident from my followup comment).=20 --John= From jgs@juniper.net Tue Jun 12 08:57:53 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2336821F8568 for ; Tue, 12 Jun 2012 08:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaV2ZfPgVJB6 for ; Tue, 12 Jun 2012 08:57:52 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A18FE21F84E6 for ; Tue, 12 Jun 2012 08:57:44 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT9dm+FS7FX5i0YHgLoyXSKQv3oIcJmr0@postini.com; Tue, 12 Jun 2012 08:57:52 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 12 Jun 2012 08:57:20 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="iso-8859-1" From: "John G. Scudder" In-Reply-To: Date: Tue, 12 Jun 2012 11:57:19 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2DE5D224-6D64-41D5-A504-684C339127AE@juniper.net> References: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> To: Donald Eastlake X-Mailer: Apple Mail (2.1278) Cc: Vishwas Manral , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-trill-rbridge-bfd.all@tools.ietf.org" , Eric Gray Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:57:53 -0000 After some offline discussion I will withdraw my gripe about M-bit = processing.=20 BTW one more nit: In one place you refer to 'M-bit' and in another, 'M bit'. Please make = this consistent. Thanks. --John= From d3e3e3@gmail.com Tue Jun 12 09:02:51 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583A121F850D for ; Tue, 12 Jun 2012 09:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hppxu6D7LcDn for ; Tue, 12 Jun 2012 09:02:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA69A21F8504 for ; Tue, 12 Jun 2012 09:02:50 -0700 (PDT) Received: by yenq13 with SMTP id q13so4166268yen.31 for ; Tue, 12 Jun 2012 09:02:50 -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:content-transfer-encoding; bh=GA0dIuf3Zz0WrsjnWCZ6QE6o+w4ghg0W+2FzlGWYmws=; b=DT0hY2YnIYYZ0mmFay/3hQnMu7cv34vqHg+SmR060DGL9E4Y5Um6AAI+reGM/7wVBd GVZ81fMIAH3WCsPt+UAR9aaFOp1mn21L7qc6EjML7jfI1gWQWf1kkpAdDK3f7TN4qRmY nklO63wF6nke8m586lILVPowaBJgJ9I/RnA3E1G9e5XnCRGj0vdmSSn3fxOFzMUxyM07 eepsUSD7IqXHBB0LQovLqDRueYay5GhLZc9jeUUFISLl+0kNbeIkiiwS9faeTZgTgmt4 D45fgjHAUjRTnImE7HoHUn9VxdlGrTmXBjpvXQHuvOUa5WiiCIMZIEeDi+dcIFNwPW3r ptmA== Received: by 10.50.213.106 with SMTP id nr10mr8666492igc.58.1339516970215; Tue, 12 Jun 2012 09:02:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Tue, 12 Jun 2012 09:02:30 -0700 (PDT) In-Reply-To: <2DE5D224-6D64-41D5-A504-684C339127AE@juniper.net> References: <6DB11511-5B76-49B3-824B-193824728011@juniper.net> <2DE5D224-6D64-41D5-A504-684C339127AE@juniper.net> From: Donald Eastlake Date: Tue, 12 Jun 2012 12:02:30 -0400 Message-ID: To: "John G. Scudder" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Vishwas Manral , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-trill-rbridge-bfd.all@tools.ietf.org" , Eric Gray Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 16:02:51 -0000 Hi John, On Tue, Jun 12, 2012 at 11:57 AM, John G. Scudder wrote: > After some offline discussion I will withdraw my gripe about M-bit proces= sing. > > BTW one more nit: > > In one place you refer to 'M-bit' and in another, 'M bit'. Please make th= is consistent. Thanks. OK. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > --John From enkechen@cisco.com Tue Jun 12 16:34:10 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC14A11E807F for ; Tue, 12 Jun 2012 16:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2PVp+UNw2-z for ; Tue, 12 Jun 2012 16:34:09 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D142E11E8072 for ; Tue, 12 Jun 2012 16:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5194; q=dns/txt; s=iport; t=1339544049; x=1340753649; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ju+DVTYgJpwh6JGONPcXjv456vN5K+XvHOKNL3qhsrw=; b=KW8iQpTxP9APkL/gs4g4/LWq7PgtzKWamE7PYir5iVv66qU2AA4+mSYz cvW+FXQ+Ifu1rnfbjo3khEdO4M6w7bL2899D+cmesdk0xsy6ET4kAuEu7 zPeAYzaFebn6WA/50l+mgOYIokmp89RyGlyhlxNACqmADZKlp+2PDpwbR Y=; X-IronPort-AV: E=Sophos;i="4.75,761,1330905600"; d="scan'208";a="45581041" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 12 Jun 2012 23:34:09 +0000 Received: from dhcp-171-71-139-24.cisco.com (dhcp-171-71-139-24.cisco.com [171.71.139.24]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5CNY88h012323; Tue, 12 Jun 2012 23:34:09 GMT Message-ID: <4FD7D23C.9050606@cisco.com> Date: Tue, 12 Jun 2012 16:35:24 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Geoff Huston References: <71002B69-8E77-4392-82C3-D6AA5EA16FAE@apnic.net> In-Reply-To: <71002B69-8E77-4392-82C3-D6AA5EA16FAE@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Enke Chen , draft-ietf-idr-rfc4893bis.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-idr-rfc4893bis-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 23:34:11 -0000 Hi, Geoff: Thanks for your review. Please see my replies below. On 6/11/12 9:43 PM, Geoff Huston wrote: > (resent with correct draft author address added) > > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-idr-rfc4893bis-06.txt > Reviewer: Geoff Huston > Review Date: 12 June 2012 > IETF LC End Date: mnot known > Intended Status: Standards Track > > Summary: > > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > The draft provides a small number of updates to RFC4893, fixing up some > residual grammatical errors, clarifying, or altering some of the > normative text, and providing a new section on error handling. > > The document is clear, and easily understood. > > Major Issues: > > none found > > Minor Issues: > > 1. Ambiguity in the specification > > The last sentence of the final paragraph of section 3 states > > "This AS number [referring to AS_TRANS] is also placed in the "My > Autonomous System" field of the OPEN message originated by a NEW BGP > speaker, if the speaker does not have a (globally unique) 2-octet AS > number." > > is this "if" an instance of "if and only if"? Or not? > > i.e. if the local BGP speaker is within AS 10 (say) and it is 4-octet > capable, then does the preceding text require that the BGP speaker > MUST use the value "10" as "My Autonomous System" number, or > MAY use the number 10 (or, alternatively MAY use the number 23456), > or MUST NOT use the number 10 at all? > > While this is not a major issue, some additional clarification appears > to be appropriate here. It is "if and only if". Would it be better if we change "if the speaker ..." to "in the case that the speaker..."? > > 2. MAY, SHALL, or SHOULD? > > Section 4.1 states: > > "A BGP speaker that supports 4-octet Autonomous System numbers SHALL > advertise this to its peers using the BGP Capability Advertisements." > > (RFC 4893 used SHOULD) > > Yet Section 7 (Transition) states: > > "To simplify transition, this document assumes that an Autonomous > System could start using a 4-octet AS number only after all the BGP > speakers within that Autonomous System have been upgraded to support > 4-octet AS numbers." > > I observe that during an upgrade of routers within an AS it may be > the case that the network administrator would like to upgrade the > capability of all BGP speakers within the AS to support 4-octet AS > numbers and then and only then have the BGP speakers announce this > support to their peers. i.e. having the capability to operate in NEW > mode need not necessarily imply a mandatory (SHALL) announcement to > the peers of a BGP speaker. Or was this the intended effect of this > change from SHOULD to SHALL in the document? The change from "SHOULD" to "SHALL" was to address a comment/observation that this capability is different from other bgp capabilities in that this capability is needed universally and should be enabled with just software upgrade. So it is more about the "default" vs "non-default" behavior. With that said, I am not sure whether we should revert back to "SHOULD". Please advise. > > > 3. missing use of normative language > > The last sentence of section 4.2.1 states > > "However, this document does not assume that an Autonomous System with > NEW speakers has to have a globally unique 2-octet AS number -- > AS_TRANS could be used instead (even if a multiple Autonomous System > would use it)." > > The "could be used instead" implies to this reviewer that there are > other solutions, yet the document is only proposing a single > approach. So it is my understanding from the remainder of the text of > this document that the intent here is that: > > "AS_TRANS MUST be used when the NEW speaker does not have a 2-octet > AS number (even if a multiple Autonomous System would use it)." Will revise as suggested. > > 4. Error Handling > > Section 4 provides a specification for error handling of update in > BGP. It would be helpful to note here that this section provides an > UPDATE to RFC 4271 with respect to the error conditions noted here > and their handling. Will do. > > > Nits: > > none found > > thanks, > > Geoff Huston Thanks again. -- Enke > From gih@apnic.net Tue Jun 12 17:44:53 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB69E11E809C for ; Tue, 12 Jun 2012 17:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsGuTGpNKKcd for ; Tue, 12 Jun 2012 17:44:52 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 7484521F8755 for ; Tue, 12 Jun 2012 17:44:43 -0700 (PDT) Received: from [IPv6:2001:388:1000:110:3097:97e2:6eb6:cf7f] (unknown [IPv6:2001:388:1000:110:3097:97e2:6eb6:cf7f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id AA4FBB684D; Wed, 13 Jun 2012 10:44:41 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Geoff Huston In-Reply-To: <4FD7D23C.9050606@cisco.com> Date: Wed, 13 Jun 2012 10:44:39 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <60DA541E-D147-4AFC-9617-633EFBEAE7A6@apnic.net> References: <71002B69-8E77-4392-82C3-D6AA5EA16FAE@apnic.net> <4FD7D23C.9050606@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.1278) Cc: rtg-dir@ietf.org, draft-ietf-idr-rfc4893bis.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-idr-rfc4893bis-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 00:44:54 -0000 On 13/06/2012, at 9:35 AM, Enke Chen wrote: > Hi, Geoff: >=20 > Thanks for your review. Please see my replies below. >=20 > On 6/11/12 9:43 PM, Geoff Huston wrote: >> (resent with correct draft author address added) >>=20 >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. >> The Routing Directorate seeks to review all routing or = routing-related >> drafts as they pass through IETF last call and IESG review, and >> sometimes on special request. The purpose of the review is to provide >> assistance to the Routing ADs. For more information about the Routing >> Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it >> would be helpful if you could consider them along with any other IETF >> Last Call comments that you receive, and strive to resolve them = through >> discussion or by updating the draft. >>=20 >> Document: draft-idr-rfc4893bis-06.txt >> Reviewer: Geoff Huston >> Review Date: 12 June 2012 >> IETF LC End Date: mnot known >> Intended Status: Standards Track >>=20 >> Summary: >>=20 >> I have some minor concerns about this document that I think should be >> resolved before publication. >>=20 >> Comments: >>=20 >> The draft provides a small number of updates to RFC4893, fixing up = some >> residual grammatical errors, clarifying, or altering some of the >> normative text, and providing a new section on error handling. >>=20 >> The document is clear, and easily understood. >>=20 >> Major Issues: >>=20 >> none found >>=20 >> Minor Issues: >>=20 >> 1. Ambiguity in the specification >>=20 >> The last sentence of the final paragraph of section 3 states >>=20 >> "This AS number [referring to AS_TRANS] is also placed in the "My >> Autonomous System" field of the OPEN message originated by a NEW = BGP >> speaker, if the speaker does not have a (globally unique) 2-octet = AS >> number." >>=20 >> is this "if" an instance of "if and only if"? Or not? >>=20 >> i.e. if the local BGP speaker is within AS 10 (say) and it is = 4-octet >> capable, then does the preceding text require that the BGP speaker >> MUST use the value "10" as "My Autonomous System" number, or >> MAY use the number 10 (or, alternatively MAY use the number 23456), >> or MUST NOT use the number 10 at all? >>=20 >> While this is not a major issue, some additional clarification = appears >> to be appropriate here. >=20 > It is "if and only if". >=20 > Would it be better if we change "if the speaker ..." to "in the case = that the speaker..."? no - because you also need to clarify the other case (namely that the = speaker has a 2-octet AS number) Might I suggest that you consider the following" "This AS number is also placed in the "My Autonomous System" field of = the OPEN message originated by a NEW BGP speaker, if and only if the = speaker does not have a 2-octet AS number." 1) this covers all cases with explicit specification of what to do 2) it also encompasses those cases when the local speaker is using a = private (non-globally unique) 2-octet AS number >=20 >>=20 >> 2. MAY, SHALL, or SHOULD? >>=20 >> Section 4.1 states: >>=20 >> "A BGP speaker that supports 4-octet Autonomous System numbers = SHALL >> advertise this to its peers using the BGP Capability = Advertisements." >>=20 >> (RFC 4893 used SHOULD) >>=20 >> Yet Section 7 (Transition) states: >>=20 >> "To simplify transition, this document assumes that an Autonomous >> System could start using a 4-octet AS number only after all the BGP >> speakers within that Autonomous System have been upgraded to = support >> 4-octet AS numbers." >>=20 >> I observe that during an upgrade of routers within an AS it may be >> the case that the network administrator would like to upgrade the >> capability of all BGP speakers within the AS to support 4-octet AS >> numbers and then and only then have the BGP speakers announce this >> support to their peers. i.e. having the capability to operate in = NEW >> mode need not necessarily imply a mandatory (SHALL) announcement to >> the peers of a BGP speaker. Or was this the intended effect of this >> change from SHOULD to SHALL in the document? >=20 > The change from "SHOULD" to "SHALL" was to address a = comment/observation that this capability is different from other bgp = capabilities in that this capability is needed universally and should be = enabled with just software upgrade. So it is more about the "default" = vs "non-default" behavior. >=20 > With that said, I am not sure whether we should revert back to = "SHOULD". Please advise. My observation was that it appears to implicitly suggest that the = capability should be announced at the time that the router is 4-octet = capable, yet the section 7 transition advice appears to contradict this, = in so far as it seems to suggest waiting to all routers arre 4-octet = capable. I think you can leave the SHALL in section 4.1 if you add additional = text in section 7.=20 YOu may wish to consider the following test in Section 7: "Where an Autonomous System is using a 2-octet AS number, then the BGP = speakers within that Autonomous SYSTEM MAY be upgraded to support = 4-octet AS numbers on a piecemeal basis. There is no requirement for a = coordinated upgrade of this 4-octet AS capability in this case. However, = if an Autonomous System wishes to use a 4-octet AS number as its own AS = number, then this document assumes that an Autonomous System can use a = 4-octet AS number only after all the BGP speakers within that Autonomous = System have been upgraded to support 4-octet AS Numbers." >=20 >>=20 >>=20 >> 3. missing use of normative language >>=20 >> The last sentence of section 4.2.1 states >>=20 >> "However, this document does not assume that an Autonomous System = with >> NEW speakers has to have a globally unique 2-octet AS number -- >> AS_TRANS could be used instead (even if a multiple Autonomous = System >> would use it)." >>=20 >> The "could be used instead" implies to this reviewer that there are >> other solutions, yet the document is only proposing a single >> approach. So it is my understanding from the remainder of the text = of >> this document that the intent here is that: >>=20 >> "AS_TRANS MUST be used when the NEW speaker does not have a 2-octet >> AS number (even if a multiple Autonomous System would use it)." >=20 > Will revise as suggested. >=20 >>=20 >> 4. Error Handling >>=20 >> Section 4 provides a specification for error handling of update in >> BGP. It would be helpful to note here that this section provides an >> UPDATE to RFC 4271 with respect to the error conditions noted here >> and their handling. >=20 > Will do. >=20 many thanks, Geoff From Alexander.Vainshtein@ecitele.com Wed Jun 13 22:24:09 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A291721F8655 for ; Wed, 13 Jun 2012 22:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH8gBCF9oNLq for ; Wed, 13 Jun 2012 22:24:08 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id E751C21F863F for ; Wed, 13 Jun 2012 22:24:03 -0700 (PDT) Received: from [85.158.143.99:49354] by server-2.bemta-4.messagelabs.com id A4/22-17938-17579DF4; Thu, 14 Jun 2012 05:24:01 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1339651440!27308562!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 5946 invoked from network); 14 Jun 2012 05:24:01 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-9.tower-216.messagelabs.com with SMTP; 14 Jun 2012 05:24:01 -0000 X-AuditID: a8571403-b7f1c6d000001c72-63-4fd97564791b Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id 86.7A.07282.46579DF4; Thu, 14 Jun 2012 07:23:48 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.141]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 14 Jun 2012 07:23:59 +0200 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Thread-Index: Ac1H2kX1gC60l/TZR4iLrX+73/oeQg== Date: Thu, 14 Jun 2012 05:23:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2WTf0gTYRjHe3e3eS1Prrm51xF0vGRg6ZiYsMpZRPSDiEVJUQT2unvdDrfb 2M3RKsToP4tKKcQlpGRmZgX9gKAfoJagZCr2x7QSSStSLEglo7LuPDKj++v73vfzfJ/n7p5j KFOPwcaIUoSEJexHBiNtBEts2ULZoNsxfC/f2dR7DTg/1NXSzvrWd0mbqR2Njd90O6YHpgx7 dIcqQD6WpGAERwgvENnjQnvCYhR7YogXBRfKQXzIjz0kQKSIC+FQiEgCKjDy/135CiZKPJE8 QUGUvC60c5872+nMW5+dgwoKfaLMk+wAFv18gMgy9hJeuaOOLAlHblG+i7V39aGL9qNzU6OG CvBlVSVYykBuHayZqkzSdBrsG75tqARGxsS9BHCupkqvHa4C2NY/S6uUgXPBOzfeGFRt5vLg 2V99SSpEcXEA317vVgyGSeU2wR9NBzVmK5z8eUqnaTtsqK2er6W5DFj3+cK8ZrndcGSkilI1 UKb42t06z1OcFQ6NXdZp03Gw8VEvpWkL/Dg6p9f0Snj3/qhe47Ng/cMvBk2vhU0NE5SWvxx2 1Y7RGp8O25oT9HlgiS9qEV9UHl9UHl9UXg/oFgBLwqLgD0XlYocj1048YoT4id0TDNwBylI0 HzBTD8D0OXs74BiAktkHTxNukx5H5VigHaQzOmRhWyODblNKcVCI+bDsKwqX+YncDiBDITP7 nlc8VsCxYyQc/GM5lZdVRdmWeYLqt4wU5Toc/xyQlb29t8Bt4rzKgpUSEiLhP6UrGAZB9pba cXmYeMnREtEf+WvrmKVq52Sl8zWVYeUQDsiiV/O7QQbz6PSzBDDRUlAiNivbqUKcCvnKpIWc cWBVnjWVva66ycrCLSSMK+E6JTyzJ6GGKz/AgmWrAMVF/ivygSe7fpl9J/dPHP402VlaHhsq 3U69Ht+2a2MN8rXdQB1zx/tqbNVnM1fKAxuY9Xj6Oa5unmn5hAfNVOqaxynWtMREedfaZ5Yt 6Wi1xdXp/d736mPDmeil2f4TAyUbC9ObZi5tTw2m3czgX9hnUjryG0bYwqt15VmZzDCiZR/O WUOFZfwbvwW+d+ADAAA= Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 05:24:09 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The= Routing Directorate seeks to review all routing or routing-related drafts a= s they pass through IETF last call and IESG review. The purpose of the revie= w is to provide assistance to the Routing ADs. For more information about th= e Routing Directorate, please see http://www.ietf.org/iesg/directorate/routi= ng.html Although these comments are primarily for the use of the Routing ADs, it wou= ld be helpful if you could consider them along with any other IETF Last Call= comments that you receive, and strive to resolve them through discussion or= by updating the draft. Document: draft-ietf-pwe3-cbit-negotiation-03.txt Reviewer: Alexander ("Sasha") Vainshtein Review Date: 13.06.12 IETF LC End date: 15.06.12 Intended Status: Standards Track SUMMARY: I think that the document is generally in good shape and almost ready for pu= blication. However, I have some minor technical concerns as well as some editorial ones= which, IMHO, should be resolved before publication. MAJOR ISSUES: None MINOR ISSUES: Technical: The actual C-bit negotiation protocol (extension of what has been defined i= n RFC 4447) is presented in the document 3 (three) times: - In Section 3, items i) to iii) and the paragraph immediately following t= hese items. This text uses the IETF capitalized requirement level terms (MUS= T) and hence looks like the normative definition of the protocol - In the same Section, items 1 to 5. This text refers to an (IMHO not ver= y informative) Figure 1 but does not contain the IETF capitalized requiremen= t level terms. - In Appendix A. This Appendix contains a block diagram of the C-bit negoti= ation procedure that follows/illustrates the text in items 1) - 7) of Sectio= n 3. The difference between the presumably normative definition and two others= is that the first one explicitly states: "Local PE MUST send a label withd= raw message to remote PE if it has previously sent a label mapping, and wait= until receiving a label release from the remote PE". (Note: "Local PE" in the document is the PE that has changed configuration= of CW usage (in this case, from NOT PREFERRED to PREFERRED.) The two other fragments do not mention waiting for the label release messag= e from the remote PE, i.e. are not fully consistent with the normative one. My interpretation of the LDP procedures as per RFC 5036 is that an LSR that= sends a label withdraw message MUST wait for the acknowledging label rel= ease message from the peer, i.e. the presumed normative definition is correc= t. And in any case I think that all the all the descriptions of the protocol= (texts, block diagrams etc.) must be fully consistent. I also suggest to clarify whether sending the label release message by the l= ocal PE above should wait for the label release message from the remote PE i= f label withdraw message has been sent. I expect that, upon receiving the l= abel withdraw message from the local PE, the remote one, in addition to ackn= owledging it with a label release message would also immediately send its ow= n label withdraw message to the local PE which would then, in its turn, send= label release message back. Editorial: 1. With regard to multi-segment PWs, the draft says that "the (label) reque= st message MUST be processed in ordered mode". It is not clear to me whether= this refers to ordered label distribution mode of LDP as defined in RFC 503= 6, or to something else. At the same time, the procedure defined in the draf= t is compliant with the common PW label distribution procedures as defined i= n RFC 6073, so I suggest to consider referencing RFC 6073 (there is no such= reference in the draft) instead of using a potentially misleading term. I a= lso wonder if this draft should not be considered as updating RFC 6073 in ad= dition to updating RFC 4447. 2. As mentioned above, there are two text fragments defining the new C-bit= negotiation procedure in the draft. I suggest to consider merging them into= a single text that consistently uses the IETF capitalized terms for require= ment levels while avoiding such vague terms as "could" (e.g., " PE2 could w= ait for PE1 label binding before sending its label binding with C-bit set")= . Having a single text fragment that defines the procedure would also reduce= the potential for inconsistencies. 3. The text, as written, does not clearly distinguish between the PW contro= l word (as a field in the packet) and the PW control word *use* in a PW inst= ance. In most cases this is not a problem, since the draft is all about the= CW use. However, there are several cases when this may result in misinterpr= etation, e.g. (the next two items are copy and paste quotes from the draft): - When the peer PE successfully processed the label withdraw and label r= elease, and removed the remote label binding, it MUST reset its local contro= l word with the configured one... - When Local PE changes its control word from PREFERRED to NOT PREFERRED... (Please note also that *preferred* PW control word is defined in RFC 4385, b= ut the meaning is completely different from one implied here). I suggest to consider clarifying that these (and possibly some other) fragme= nts refer to the PW CW usage and not to format or content of the CW. There i= s clearly more than one way to do that. IMHO and FWIW the most unambiguous o= ne would be to define the relevant state variables of the PW end points (con= figured, transmitted and received C-bit) and to use them in the definition o= f the procedure, but this is definitely for the authors to decide. Nits: None found by the IETF draft checker. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From andrew.g.malis@verizon.com Wed Jun 13 22:57:17 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD97321F864A for ; Wed, 13 Jun 2012 22:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZou6xaZ6HZ6 for ; Wed, 13 Jun 2012 22:57:17 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id CFB5621F8648 for ; Wed, 13 Jun 2012 22:57:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 14 Jun 2012 05:57:16 +0000 From: "Malis, Andrew G \(Andy\)" X-IronPort-AV: E=Sophos;i="4.75,768,1330905600"; d="scan'208";a="282214925" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 14 Jun 2012 05:57:16 +0000 Received: from fhdp1lumxc7v22.us.one.verizon.com ([166.68.59.158]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Thu, 14 Jun 2012 01:57:15 -0400 To: Alexander Vainshtein , "rtg-ads@tools.ietf.org" Date: Thu, 14 Jun 2012 01:57:15 -0400 Thread-Topic: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Thread-Index: Ac1J8owhmAJaY9F5R8WyDyxfnI2qUg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 13 Jun 2012 22:59:55 -0700 Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "Malis, Andrew G \(Andy\)" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 05:57:18 -0000 Sasha, Many thanks. We'll wait until the end of IETF last call and then take action as directed by the ADs, who may have review comments of their own, as well as the rest of the IESG. Cheers, Andy On 6/14/2012 14:23 , "Alexander Vainshtein" wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pwe3-cbit-negotiation-03.txt Reviewer: Alexander ("Sasha") Vainshtein Review Date: 13.06.12 IETF LC End date: 15.06.12 Intended Status: Standards Track SUMMARY: I think that the document is generally in good shape and almost ready for publication.=20 However, I have some minor technical concerns as well as some editorial ones which, IMHO, should be resolved before publication. MAJOR ISSUES: None MINOR ISSUES: Technical: The actual C-bit negotiation protocol (extension of what has been defined in RFC 4447) is presented in the document 3 (three) times: - In Section 3, items i) to iii) and the paragraph immediately following these items. This text uses the IETF capitalized requirement level terms (MUST) and hence looks like the normative definition of the protocol - In the same Section, items 1 to 5. This text refers to an (IMHO not very informative) Figure 1 but does not contain the IETF capitalized requirement level terms. - In Appendix A. This Appendix contains a block diagram of the C-bit negotiation procedure that follows/illustrates the text in items 1) - 7) of Section 3. The difference between the presumably normative definition and two others is that the first one explicitly states: "Local PE MUST send a label withdraw message to remote PE if it has previously sent a label mapping, and wait until receiving a label release from the remote PE". (Note: "Local PE" in the document is the PE that has changed configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.) The two other fragments do not mention waiting for the label release message from the remote PE, i.e. are not fully consistent with the normative one. My interpretation of the LDP procedures as per RFC 5036 is that an LSR that sends a label withdraw message MUST wait for the acknowledging label release message from the peer, i.e. the presumed normative definition is correct. And in any case I think that all the all the descriptions of the protocol (texts, block diagrams etc.) must be fully consistent. I also suggest to clarify whether sending the label release message by the local PE above should wait for the label release message from the remote PE if label withdraw message has been sent. I expect that, upon receiving the label withdraw message from the local PE, the remote one, in addition to acknowledging it with a label release message would also immediately send its own label withdraw message to the local PE which would then, in its turn, send label release message back. Editorial: 1. With regard to multi-segment PWs, the draft says that "the (label) request message MUST be processed in ordered mode". It is not clear to me whether this refers to ordered label distribution mode of LDP as defined in RFC 5036, or to something else. At the same time, the procedure defined in the draft is compliant with the common PW label distribution procedures as defined in RFC 6073, so I suggest to consider referencing RFC 6073 (there is no such reference in the draft) instead of using a potentially misleading term. I also wonder if this draft should not be considered as updating RFC 6073 in addition to updating RFC 4447. 2. As mentioned above, there are two text fragments defining the new C-bit negotiation procedure in the draft. I suggest to consider merging them into a single text that consistently uses the IETF capitalized terms for requirement levels while avoiding such vague terms as "could" (e.g., " PE2 could wait for PE1 label binding before sending its label binding with C-bit set"). Having a single text fragment that defines the procedure would also reduce the potential for inconsistencies. 3. The text, as written, does not clearly distinguish between the PW control word (as a field in the packet) and the PW control word *use* in a PW instance. In most cases this is not a problem, since the draft is all about the CW use. However, there are several cases when this may result in misinterpretation, e.g. (the next two items are copy and paste quotes from the draft): - When the peer PE successfully processed the label withdraw and label release, and removed the remote label binding, it MUST reset its local control word with the configured one... - When Local PE changes its control word from PREFERRED to NOT PREFERRED... (Please note also that *preferred* PW control word is defined in RFC 4385, but the meaning is completely different from one implied here). I suggest to consider clarifying that these (and possibly some other) fragments refer to the PW CW usage and not to format or content of the CW. There is clearly more than one way to do that. IMHO and FWIW the most unambiguous one would be to define the relevant state variables of the PW end points (configured, transmitted and received C-bit) and to use them in the definition of the procedure, but this is definitely for the authors to decide. Nits: None found by the IETF draft checker. =20 Regards, Sasha This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. From lizhong.jin@zte.com.cn Thu Jun 14 02:48:13 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735F321F86A8 for ; Thu, 14 Jun 2012 02:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J0cx+tHWeYL for ; Thu, 14 Jun 2012 02:48:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id BE10021F86A7 for ; Thu, 14 Jun 2012 02:48:10 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 51496712910399; Thu, 14 Jun 2012 17:47:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 52926.3572189594; Thu, 14 Jun 2012 17:48:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q5E9lxMV095277; Thu, 14 Jun 2012 17:47:59 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Alexander Vainshtein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 14 Jun 2012 17:47:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-14 17:48:02 Content-Type: multipart/mixed; boundary="=_mixed 0035D43548257A1D_=" X-MAIL: mse02.zte.com.cn q5E9lxMV095277 X-Mailman-Approved-At: Thu, 14 Jun 2012 02:55:10 -0700 Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 09:48:13 -0000 --=_mixed 0035D43548257A1D_= Content-Type: multipart/alternative; boundary="=_alternative 0035D43648257A1D_=" --=_alternative 0035D43648257A1D_= Content-Type: text/plain; charset="US-ASCII" Hi Sasha, Thank you very much for the valuable comments. Please see my reply inline below. I also attached the modified version for your check and reference. Regards Lizhong Alexander Vainshtein wrote 2012/06/14 13:23:59: > Hello, > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-pwe3-cbit-negotiation-03.txt > Reviewer: Alexander ("Sasha") Vainshtein > Review Date: 13.06.12 > IETF LC End date: 15.06.12 > Intended Status: Standards Track > > > SUMMARY: > > I think that the document is generally in good shape and almost > ready for publication. > However, I have some minor technical concerns as well as some > editorial ones which, IMHO, should be resolved before publication. > > MAJOR ISSUES: None > > MINOR ISSUES: > > Technical: > > The actual C-bit negotiation protocol (extension of what has been > defined in RFC 4447) is presented in the document 3 (three) times: > > - In Section 3, items i) to iii) and the paragraph immediately > following these items. This text uses the IETF capitalized > requirement level terms (MUST) and hence looks like the normative > definition of the protocol > > - In the same Section, items 1 to 5. This text refers to an (IMHO > not very informative) Figure 1 but does not contain the IETF > capitalized requirement level terms. > > - In Appendix A. This Appendix contains a block diagram of the C- > bit negotiation procedure that follows/illustrates the text in items > 1) - 7) of Section 3. > > The difference between the presumably normative definition and two > others is that the first one explicitly states: "Local PE MUST send > a label withdraw message to remote PE if it has previously sent a > label mapping, and wait until receiving a label release from the remote PE". > (Note: "Local PE" in the document is the PE that has changed > configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.) > > The two other fragments do not mention waiting for the label > release message from the remote PE, i.e. are not fully consistent > with the normative one. > > My interpretation of the LDP procedures as per RFC 5036 is that an > LSR that sends a label withdraw message MUST wait for the > acknowledging label release message from the peer, i.e. the > presumed normative definition is correct. And in any case I think > that all the all the descriptions of the protocol (texts, block > diagrams etc.) must be fully consistent. [Lizhong] agree, and we will change the second and third text fragment to reflect this. > > I also suggest to clarify whether sending the label release message > by the local PE above should wait for the label release message from > the remote PE if label withdraw message has been sent. I expect > that, upon receiving the label withdraw message from the local PE, > the remote one, in addition to acknowledging it with a label release > message would also immediately send its own label withdraw message > to the local PE which would then, in its turn, send label release > message back. [Lizhong] the remote one will not send label withdraw after acknowledging with label release, because "liberal label retention" mode is applied. The sending label release message by local PE is not necessary to wait for the release from remote. Will clarify this in the draft. > > Editorial: > > 1. With regard to multi-segment PWs, the draft says that "the > (label) request message MUST be processed in ordered mode". It is > not clear to me whether this refers to ordered label distribution > mode of LDP as defined in RFC 5036, or to something else. At the > same time, the procedure defined in the draft is compliant with the > common PW label distribution procedures as defined in RFC 6073, so I > suggest to consider referencing RFC 6073 (there is no such reference > in the draft) instead of using a potentially misleading term. I also > wonder if this draft should not be considered as updating RFC 6073 > in addition to updating RFC 4447. [Lizhong] yes, ordered mode follows ordered label distribution mode in RFC5036. And I agree, referencing RFC6073 would be more clear. And yes, the draft is also updating RFC6073. > > 2. As mentioned above, there are two text fragments defining the > new C-bit negotiation procedure in the draft. I suggest to consider > merging them into a single text that consistently uses the IETF > capitalized terms for requirement levels while avoiding such vague > terms as "could" (e.g., " PE2 could wait for PE1 label binding > before sending its label binding with C-bit set"). Having a single > text fragment that defines the procedure would also reduce the > potential for inconsistencies. [Lizhong] the first text fragment defines the requirement, and the second gives an usecase according to the first text. What if we move the use case to another sub-section, so as to make it more clear? > > 3. The text, as written, does not clearly distinguish between the > PW control word (as a field in the packet) and the PW control word > *use* in a PW instance. In most cases this is not a problem, since > the draft is all about the CW use. However, there are several cases > when this may result in misinterpretation, e.g. (the next two items > are copy and paste quotes from the draft): > > - When the peer PE successfully processed the label withdraw and > label release, and removed the remote label binding, it MUST reset > its local control word with the configured one... > > - When Local PE changes its control word from PREFERRED to NOT PREFERRED... > > (Please note also that *preferred* PW control word is defined in RFC > 4385, but the meaning is completely different from one implied here). > > I suggest to consider clarifying that these (and possibly some > other) fragments refer to the PW CW usage and not to format or > content of the CW. There is clearly more than one way to do that. > IMHO and FWIW the most unambiguous one would be to define the > relevant state variables of the PW end points (configured, > transmitted and received C-bit) and to use them in the definition of > the procedure, but this is definitely for the authors to decide. [Lizhong] we will change the "control word" to "use of control word" in the draft, and make it clear. > > Nits: None found by the IETF draft checker. > > Regards, > Sasha > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to > ECI Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and > all copies thereof. > > --=_alternative 0035D43648257A1D_= Content-Type: text/html; charset="US-ASCII"
Hi Sasha,
Thank you very much for the valuable comments. Please see my reply inline below.
I also attached the modified version for your check and reference.

Regards
Lizhong

 

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote 2012/06/14 13:23:59:

> Hello,
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review. The purpose of the review is to provide assistance to the
> Routing ADs. For more information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any
> other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
> Document:   draft-ietf-pwe3-cbit-negotiation-03.txt
> Reviewer:   Alexander ("Sasha") Vainshtein
> Review Date:   13.06.12
> IETF LC End date:  15.06.12
> Intended Status:  Standards Track
>
>
> SUMMARY:
>
> I think that the document is generally in good shape and almost
> ready for publication.
> However, I have some minor technical concerns as well as some
> editorial ones which, IMHO, should be resolved before publication.
>
> MAJOR ISSUES:  None
>
> MINOR ISSUES:
>
> Technical:
>
>  The actual C-bit negotiation protocol (extension of what has been
> defined in RFC 4447) is presented in the document 3 (three) times:
>
>  -  In Section 3, items i) to iii) and the paragraph immediately
> following these items. This text uses the IETF capitalized
> requirement level terms (MUST) and hence looks like the normative
> definition of the protocol
>
>  -   In the same Section, items 1 to 5. This text refers to an (IMHO
> not very informative) Figure 1 but does not contain the IETF
> capitalized requirement level terms.
>
>  - In Appendix A. This Appendix contains a block diagram of the C-
> bit negotiation procedure that follows/illustrates the text in items
> 1) - 7) of Section 3.
>
>   The difference between the presumably normative definition and two
> others is that the first one explicitly states:  "Local PE MUST send
> a label withdraw message to remote PE if it has previously sent a
> label mapping, and wait until receiving a label release from the remote PE".  
>  (Note: "Local PE" in the document is the PE that has changed
> configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.)
>
>  The two other fragments do not mention waiting for the label
> release message from the remote PE, i.e. are not fully consistent
> with the normative one.
>
>  My interpretation of the LDP procedures as per RFC 5036 is that an
> LSR that sends a label withdraw message MUST wait for the
> acknowledging    label release message from the peer, i.e. the
> presumed normative definition is correct. And in any case I think
> that all the all the descriptions of the protocol (texts, block
> diagrams etc.) must be fully consistent.
[Lizhong] agree, and we will change the second and third text fragment to reflect this.

>
> I also suggest to clarify whether sending the label release message
> by the local PE above should wait for the label release message from
> the remote PE if label withdraw message has been sent.  I expect
> that, upon receiving the label withdraw message from the local PE,
> the remote one, in addition to acknowledging it with a label release
> message would also immediately send its own label withdraw message
> to the local PE which would then, in its turn, send label release
> message back.
[Lizhong] the remote one will not send label withdraw after acknowledging with label release, because "liberal label retention" mode is applied. The sending label release message by local PE is not necessary to wait for the release from remote. Will clarify this in the draft.

>
> Editorial:
>
>  1. With regard to multi-segment PWs, the draft says that "the
> (label) request message MUST be processed in ordered mode". It is
> not clear to me whether this refers to ordered label distribution
> mode of LDP as defined in RFC 5036, or to something else. At the
> same time, the procedure defined in the draft is compliant with the
> common PW label distribution procedures as defined in RFC 6073, so I
> suggest to consider referencing RFC 6073 (there is no such reference
> in the draft) instead of using a potentially misleading term. I also
> wonder if this draft should not be considered as updating RFC 6073
> in addition to updating RFC 4447.
[Lizhong] yes, ordered mode follows ordered label distribution mode in RFC5036. And I agree, referencing RFC6073 would be more clear. And yes, the draft is also updating RFC6073.

>
>  2. As mentioned above, there are two text fragments defining the
> new C-bit negotiation procedure in the draft. I suggest to consider
> merging them into a single text that consistently uses the IETF
> capitalized terms for requirement levels while avoiding such vague
> terms as "could"  (e.g., " PE2 could wait for PE1 label  binding
> before sending its label binding with C-bit set"). Having a single
> text fragment that defines the procedure would also reduce the
> potential for inconsistencies.
[Lizhong] the first text fragment defines the requirement, and the second gives an usecase according to the first text. What if we move the use case to another sub-section, so as to make it more clear?

>
>  3. The text, as written, does not clearly distinguish between the
> PW control word (as a field in the packet) and the PW control word
> *use* in a PW instance. In most cases this is not a problem, since
> the draft is all about the CW use. However, there are several cases
> when this may result in misinterpretation, e.g. (the next two items
> are copy and paste quotes from the draft):
>
>  -    When the peer PE successfully processed the label withdraw and
> label release, and removed the remote label binding, it MUST reset
> its local control word with the configured one...
>
>  - When Local PE changes its control word from PREFERRED to NOT PREFERRED...
>
> (Please note also that *preferred* PW control word is defined in RFC
> 4385, but the meaning is completely different from one implied here).
>
> I suggest to consider clarifying that these (and possibly some
> other) fragments refer to the PW CW usage and not to format or
> content of the CW. There is clearly more than one way to do that.
> IMHO and FWIW the most unambiguous one would be to define the
> relevant state variables of the PW end points (configured,
> transmitted and received C-bit) and to use them in the definition of
> the procedure, but this is definitely for the authors to decide.
[Lizhong] we will change the "control word" to "use of control word" in the draft, and make it clear.

>
> Nits:  None found by the IETF draft checker.
>  
> Regards,
>      Sasha
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to
> ECI Telecom. If you have received this transmission in error, please
> inform us by e-mail, phone or fax, and then delete the original and
> all copies thereof.
>
>
--=_alternative 0035D43648257A1D_=-- --=_mixed 0035D43548257A1D_= Content-Type: application/octet-stream; name="draft-ietf-pwe3-cbit-negotiation-03.doc" Content-Disposition: attachment; filename="draft-ietf-pwe3-cbit-negotiation-03.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAawAAAAAAAAAA EAAAbQAAAAEAAAD+////AAAAAGoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAf4AJBAAA8FK/AAAAAAAAEAAAAAAACAAAUUoAAA4AYmpiaubm5uYAAAAAAAAAAAAAAAAAAAAA AAAECBYAOH4AAISMAQCEjAEAUUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAFAGAAAAAAAAUAYAAJkT AAAAAAAAmRMAAAAAAACZEwAAAAAAAJkTAAAAAAAAmRMAABQAAAAAAAAAAAAAAP////8AAAAArRMA AAAAAACtEwAAAAAAAK0TAAAAAAAArRMAAFwAAAAJFAAAdAAAAK0TAAAAAAAAax4AALwBAAB9FAAA AAAAAH0UAAAAAAAAfRQAAAAAAAB9FAAAAAAAAH0UAAAAAAAAWBUAAAAAAABYFQAAAAAAAFgVAAAA AAAAxh0AAAIAAADIHQAAAAAAAMgdAAAAAAAAyB0AAAAAAADIHQAAAAAAAMgdAAAAAAAAyB0AACQA AAAnIAAAogIAAMkiAABWAAAA7B0AABUAAAAAAAAAAAAAAAAAAAAAAAAAmRMAAAAAAABYFQAAAAAA AAAAAAAAAAAAAAAAAAAAAABYFQAAAAAAAFgVAAAAAAAAWBUAAAAAAABYFQAAAAAAAOwdAAAAAAAA AAAAAAAAAACZEwAAAAAAAJkTAAAAAAAAfRQAAAAAAAAAAAAAAAAAAH0UAADbAAAAAR4AAC4AAADS HAAAAAAAANIcAAAAAAAA0hwAAAAAAABYFQAAxgEAAJkTAAAAAAAAfRQAAAAAAACZEwAAAAAAAH0U AAAAAAAAxh0AAAAAAAAAAAAAAAAAANIcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWBUAAAAAAADGHQAAAAAAAAAAAAAAAAAA0hwAAAAAAAAAAAAA AAAAANIcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0hwAAAAAAAB9FAAAAAAAAP////8AAAAAMPNecBJK zQEAAAAAAAAAAK0TAAAAAAAAHhcAAEoFAADSHAAAAAAAAAAAAAAAAAAAsh0AABQAAAAvHgAAPAAA AGseAAAAAAAA0hwAAAAAAAAfIwAAAAAAAGgcAABqAAAAHyMAAAAAAADSHAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAB8jAAAAAAAAAAAAAAAAAACZEwAAAAAAANIcAADgAAAAWBUAAAAAAABYFQAAAAAAANIc AAAAAAAAWBUAAAAAAABYFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWBUA AAAAAABYFQAAAAAAAFgVAAAAAAAA7B0AAAAAAADsHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA0hwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgVAAAA AAAAWBUAAAAAAABYFQAAAAAAAGseAAAAAAAAWBUAAAAAAABYFQAAAAAAAFgVAAAAAAAAWBUAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAB8jAAAAAAAAWBUAAAAAAABY FQAAAAAAAFgVAAAAAAAAWBUAAAAAAABYFQAAAAAAAFgVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYFQAAAAAAAFgVAAAAAAAAWBUA AAAAAABQBgAADwwAAF8SAAA6AQAABQASAQAACQQECAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NDU5l dHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGl6aG9uZyBK aW4gKGVkLiksIFpURQ1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFJheW1vbmQgS2V5IChlZC4pLCBIdWF3ZWkNVXBkYXRlczogNDQ0NyA2MDczKGlmIGFwcHJv dmVkKSAgICAgICAgICAgICAgICAgU2ltb24gRGVsb3JkLCBBbGNhdGVsLUx1Y2VudA1DYXRlZ29y eTogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgIFRob21hcyBOYWRlYXUs IEp1bmlwZXINRXhwaXJlczogT2N0b2JlciAxMywgMjAxMiAgICAgICAgICAgICAgICBWaXNod2Fz IE1hbnJhbCwgSGV3bGV0dC1QYWNrYXJkIA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNhbWkgQm91dHJvcywgQ2lzY28NICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlc2hhZCBSYWhtYW4sIENpc2Nv DQ0NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEFwcmlsIDEzLCAyMDEyDQ0NICAgICAgICAgIFBzZXVkb3dpcmUgQ29udHJvbCBXb3JkIE5l Z290aWF0aW9uIE1lY2hhbmlzbSBVcGRhdGUNICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1w d2UzLWNiaXQtbmVnb3RpYXRpb24tMDMNDQ1BYnN0cmFjdA0NICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgdGhlIHByb2JsZW0gb2YgY29udHJvbCB3b3JkIG5lZ290aWF0aW9uIA0gICBtZWNoYW5p c20gc3BlY2lmaWVkIGluIFtSRkM0NDQ3XS4gIEJhc2VkIG9uIHRoZSBwcm9ibGVtIGFuYWx5c2lz LCBhIA0gICBtZXNzYWdlIGV4Y2hhbmdpbmcgbWVjaGFuaXNtIGlzIGludHJvZHVjZWQgdG8gc29s dmUgdGhpcyBjb250cm9sIHdvcmQgDSAgIG5lZ290aWF0aW9uIGlzc3VlLiAgVGhpcyBkb2N1bWVu dCBpcyB0byB1cGRhdGUgW1JGQzQ0NDddIGNvbnRyb2wgd29yZCANICAgbmVnb3RpYXRpb24gbWVj aGFuaXNtLg0NDVN0YXR1cyBvZiB0aGlzIE1lbW8gDQ0gICBUaGlzIEludGVybmV0LURyYWZ0IGlz IHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgDSAgIHByb3Zp c2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuIA0gDSAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIA0gICBUYXNrIEZvcmNl IChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IA0g ICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJ bnRlcm5ldC0gDSAgIERyYWZ0cy4gDSANICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIA0gICBhbmQgbWF5IGJlIHVw ZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSAN ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyBy ZWZlcmVuY2UgDSAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr IGluIHByb2dyZXNzLiIgDSANICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMg Y2FuIGJlIGFjY2Vzc2VkIGF0IA0gICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3Ry YWN0cy50eHQuIA0gDSAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rv cmllcyBjYW4gYmUgYWNjZXNzZWQgYXQgDSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0 bWwuIA0gDSAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwgMTMsIDIw MTIuDQ1Db3B5cmlnaHQgTm90aWNlIA0gICAgDSAgIENvcHlyaWdodCAoYykgMjAxMSBJRVRGIFRy dXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZSANICAgZG9jdW1lbnQgYXV0aG9y cy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuIA0gICAgDSAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVj dCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNICAgUHJvdmlzaW9ucyBSZWxh dGluZyB0byBJRVRGIERvY3VtZW50cyAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvDSAgIGxpY2Vu c2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuIA0gICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksIGFzIHRo ZXkgZGVzY3JpYmUgeW91ciByaWdodHMNICAgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Qg dG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyANICAgZXh0cmFjdGVkIGZyb20gdGhp cyBkb2N1bWVudCBtdXN0IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IA0gICBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSANICAgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcyBkZXNjcmliZWQgaW4gdGhl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQ0NVGFibGUgb2YgQ29udGVudHMNDSAgIDEuIEludHJv ZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMw0gICAyLiBQcm9ibGVtIFN0YXRlbWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDMNICAgMy4gQ29udHJvbCB3b3JkIHJlLW5lZ290aWF0aW9uIGJ5 IGxhYmVsIHJlcXVlc3QgbWVzc2FnZSAuIC4gLiAuIC4gLiA0DSAgIDQuIEJhY2t3YXJkIENvbXBh dGliaWxpdHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNg0gICA1 LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDYNICAgNi4gSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2DSAgIDcuIEFja25vd2xlZGdlbWVudHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNg0gICA4LiBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDYNICAgOC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA2DSAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNw0gICBBcHBlbmRpeCBBLiBVcGRhdGVk IEMtYml0IEhhbmRsaW5nIFByb2NlZHVyZXMgRGlhZ3JhbSAuIC4gLiAuIC4gLiAuIDgNDQ1Db252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgDSAgICANICAgVGhlIGtleSB3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCANICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMgDSAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gW1JGQzIxMTldLiANDQ0NMS4gSW50cm9kdWN0aW9uDQ0gICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyB0aGUgcHJvYmxlbSBvZiBjb250cm9sIHdvcmQgbmVnb3RpYXRpb24gDSAgIG1lY2hhbmlz bSBzcGVjaWZpZWQgaW4gW1JGQzQ0NDddLiAgQmFzZWQgb24gdGhlIHByb2JsZW0gYW5hbHlzaXMs IGEgDSAgIG1lc3NhZ2UgZXhjaGFuZ2luZyBtZWNoYW5pc20gaXMgaW50cm9kdWNlZCB0byBzb2x2 ZSB0aGlzIG5lZ290aWF0aW9uIA0gICBpc3N1ZS4gVGhlIGNvbnRyb2wgd29yZCBuZWdvdGlhdGlv biBtZWNoYW5pc20gaW4gdGhpcyBkb2N1bWVudCBpcyB0byANICAgdXBkYXRlIFtSRkM0NDQ3XSBz ZWN0aW9uIDYuMiAiUFcgVHlwZXMgZm9yIFdoaWNoIHRoZSBDb250cm9sIFdvcmQgaXMgDSAgIE5P VCBNYW5kYXRvcnkiLg0NMi4gUHJvYmxlbSBTdGF0ZW1lbnQNDSAgIFtSRkM0NDQ3XSBzZWN0aW9u IDYgZGVzY3JpYmVzIHRoZSBjb250cm9sIHdvcmQgbmVnb3RpYXRpb24gbWVjaGFuaXNtLiANICAg RWFjaCBQVyBlbmRwb2ludCBoYXMgdGhlIGNhcGFiaWxpdHkgb2YgYmVpbmcgY29uZmlndXJhYmxl IHdpdGggYSANICAgcGFyYW1ldGVyIHRoYXQgc3BlY2lmaWVzIHdoZXRoZXIgdGhlIHVzZSBvZiB0 aGUgY29udHJvbCB3b3JkIGlzIA0gICBQUkVGRVJSRUQgb3IgTk9UIFBSRUZFUlJFRC4gIFdoaWxl IGluIHNvbWUgY2FzZSBvZiBjb250cm9sIHdvcmQgDSAgIG5lZ290aWF0aW9uLCBQRSB3aWxsIGFk dmVydGlzZSBDLWJpdD0wIGluIGxhYmVsIG1hcHBpbmcgbWVzc2FnZSB3aXRoIA0gICBpdHMgbG9j YWxseSBjb25maWd1cmVkIHVzZSBvZiBjb250cm9sIHdvcmQgYXMgUFJFRkVSUkVELiAgVGhpcyBr aW5kIG9mIGJlaGF2aW9yIA0gICB3aWxsIGNhdXNlIHNvbWUgcHJvYmxlbSB3aGVuIHBlZXIgUEUg Y2hhbmdlcyBpdHMgY29udHJvbCB3b3JkIGZyb20gDSAgIE5PVCBQUkVGRVJSRUQgdG8gUFJFRkVS UkVELg0NICAgVGhpcyBmb2xsb3dpbmcgY2FzZSB3aWxsIGRlc2NyaWJlIHRoZSBuZWdvdGlhdGlv biBwcm9ibGVtIGluIGRldGFpbDoNDSAgICAgICAgICAgICArLS0tLS0tLSsgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tKw0gICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgUFcgICAgICAg ICB8ICAgICAgIHwNICAgICAgICAgICAgIHwgIFBFMSAgfD09PT09PT09PT09PT09PT09PT09fCAg UEUyICB8DSAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAgICAg fA0gICAgICAgICAgICAgKy0tLS0tLS0rICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsNICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxDQ0gICAgICAgMS4gSW5pdGlhbGx5LCB0 aGUgdXNlIG9mIGNvbnRyb2wgd29yZCBvbiBQRTEgaXMgY29uZmlndXJlZCB0byBQUkVGRVJSRUQs IA0gICAgICAgICAgYW5kIG9uIFBFMiB0byBOT1QgUFJFRkVSUkVELg0NICAgICAgIDIuIFRoZSBu ZWdvdGlhdGlvbiByZXN1bHQgZm9yIHRoZSB1c2Ugb2YgY29udHJvbCB3b3JkIGZvciB0aGlzIFBX IGlzIA0gICAgICAgICAgIm5vdCBzdXBwb3J0ZWQiLCBhbmQgUEUxIHNlbmQgbGFiZWwgbWFwcGlu ZyB3aXRoIEMtYml0PTAgDSAgICAgICAgICBmaW5hbGx5Lg0NICAgICAgIDMuIFBFMiB0aGVuIGNo YW5nZXMgaXRzIHVzZSBvZiBjb250cm9sIHdvcmQgY29uZmlndXJhdGlvbiB0byBQUkVGRVJSRUQu DQ0gICAgICAgNC4gUEUyIHdpbGwgdGhlbiBzZW5kIGxhYmVsIHdpdGhkcmF3IG1lc3NhZ2UgdG8g UEUxLg0NICAgICAgIDUuIEFjY29yZGluZyB0byB0aGUgY29udHJvbCB3b3JkIG5lZ290aWF0aW9u IG1lY2hhbmlzbSwgdGhlIA0gICAgICAgICAgcmVjZWl2ZWQgbGFiZWwgbWFwcGluZyBvbiBQRTIg ZnJvbSBQRTEgaW5kaWNhdGVzIEMtYml0PTAsIA0gICAgICAgICAgdGhlcmVmb3JlIFBFMiB3aWxs IHN0aWxsIHNlbmQgbGFiZWwgbWFwcGluZyB3aXRoIEMtYml0PTAuDQ0gICBUaGUgbmVnb3RpYXRp b24gcmVzdWx0IGZvciB0aGUgdXNlIG9mIFBXIGNvbnRyb2wgd29yZCBpcyBzdGlsbCAibm90IA0g ICBzdXBwb3J0ZWQiLCBldmVuIHRob3VnaCB0aGUgdXNlIG9mIGNvbnRyb2wgd29yZCBjb25maWd1 cmF0aW9uIG9uIGJvdGggUEUxIA0gICBhbmQgUEUyIGlzIHNldCB0byBQUkVGRVJSRUQuDQ0NMy4g Q29udHJvbCB3b3JkIHJlLW5lZ290aWF0aW9uIGJ5IGxhYmVsIHJlcXVlc3QgbWVzc2FnZQ0NICAg SW4gb3JkZXIgdG8gc29sdmUgdGhpcyBwcm9ibGVtLCB0aGUgY29udHJvbCB3b3JkIHJlLW5lZ290 aWF0aW9uIGlzIA0gICBvcGVyYXRlZCBieSBhZGRpbmcgbGFiZWwgcmVxdWVzdCBtZXNzYWdlLiAg VGhlIGNvbnRyb2wgd29yZCANICAgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGNhbiBzdGlsbCBmb2xs b3cgdGhlIHByb2NlZHVyZSBkZXNjcmliZWQgaW4gDSAgIFtSRkM0NDQ3XSBzZWN0aW9uIDYuDQ0g ICBXaGVuIExvY2FsIFBFIGNoYW5nZXMgaXRzIHVzZSBvZiBjb250cm9sIHdvcmQgZnJvbSBOT1Qg UFJFRkVSUkVEIHRvIA0gICBQUkVGRVJSRUQgYW5kIG9ubHkgaWYgaXQgYWxyZWFkeSByZWNlaXZl ZCB0aGUgcmVtb3RlIGxhYmVsIG1hcHBpbmcgDSAgIG1lc3NhZ2Ugd2l0aCBDLWJpdD0wLCBhZGRp dGlvbmFsIHByb2NlZHVyZSB3aWxsIGJlIGFkZGVkIGFzIGZvbGxvdzoNDSAgICAgICAgIC1pLiBM b2NhbCBQRSBNVVNUIHNlbmQgYSBsYWJlbCB3aXRoZHJhdyBtZXNzYWdlIHRvIHJlbW90ZSBQRSBp ZiANICAgICAgICAgICAgIGl0IGhhcyBwcmV2aW91c2x5IHNlbnQgYSBsYWJlbCBtYXBwaW5nLCBh bmQgbGFiZWwgcmVsZWFzZSBtZXNzYWdlIHRvIHJlbW90ZSBQRSwgYW5kIHdhaXQgdW50aWwgDSAg ICAgICAgICAgICByZWNlaXZpbmcgYSBsYWJlbCByZWxlYXNlIGZyb20gdGhlIHJlbW90ZSBQRS4g DUFuZCBpdCBNVVNUIA0gICAgICAgICAgICAgYWxzbyBzZW5kIGEgbGFiZWwgcmVsZWFzZSBtZXNz YWdlIHRvIHRoZSByZW1vdGUgUEUuDQ0gICAgICAgIC1paS4gTG9jYWwgUEUgTVVTVCBzZW5kIGEg bGFiZWwgcmVxdWVzdCBtZXNzYWdlIHRvIHJlbW90ZSBQRSwgDSAgICAgICAgICAgICBhbmQgd2Fp dCB1bnRpbCByZWNlaXZpbmcgYSBsYWJlbCBtYXBwaW5nIG1lc3NhZ2UgY29udGFpbmluZyANICAg ICAgICAgICAgIHRoZSByZW1vdGUgUEUgbG9jYWxseSBjb25maWd1cmVkIHByZWZlcmVuY2UgZm9y IHVzZSBvZiBjb250cm9sIHdvcmQgc2V0dGluZy4NDSAgICAgICAtaWlpLiBBZnRlciByZWNlaXZp bmcgcmVtb3RlIFBFIGxhYmVsIG1hcHBpbmcgd2l0aCBDLWJpdGNvbnRyb2wgd29yZCANICAgICAg ICAgICAgIHNldHRpbmcsIExvY2FsIFBFIE1VU1QgZm9sbG93IHByb2NlZHVyZXMgZGVmaW5lZCBp biANICAgICAgICAgICAgIFtSRkM0NDQ3XSBzZWN0aW9uIDYgd2hlbiBzZW5kaW5nIGl0cyBsYWJl bCBtYXBwaW5nIG1lc3NhZ2UuDQ0gICBXaGVuIHRoZSBwZWVyIHJlbW90ZSBQRSBzdWNjZXNzZnVs bHkgcHJvY2Vzc2VkIHRoZSBsYWJlbCB3aXRoZHJhdyBhbmQgbGFiZWwgDSAgIHJlbGVhc2UsIGFu ZCByZW1vdmVkIHRoZSByZW1vdGUgbGFiZWwgYmluZGluZywgaXQgTVVTVCByZXNldCBpdHMgdXNl IG9mDSAgIGxvY2FsIGNvbnRyb2wgd29yZCB3aXRoIHRoZSBsb2NhbGx5IGNvbmZpZ3VyZWQgb25l cHJlZmVyZW5jZSwgYW5kIHNlbmQgbGFiZWwgbWFwcGluZyBhcyANICAgYSByZXNwb25zZSBvZiBs YWJlbCByZXF1ZXN0IHdpdGggbG9jYWxseSBjb25maWd1cmVkIHByZWZlcmVuY2UgZm9yIHVzZSBv ZiBjb250cm9sIHdvcmQgDSAgIHBhcmFtZXRlci4NDSAgIE5vdGU6IHRoZSBGRUMgZWxlbWVudCBp biBsYWJlbCByZXF1ZXN0IG1lc3NhZ2Ugc2hvdWxkIGJlIHRoZSBQRSdzIA0gICBsb2NhbCBGRUMg ZWxlbWVudC4gIE9ubHkgaWYgRkVDIGVsZW1lbnQgaW4gbGFiZWwgcmVxdWVzdCBtZXNzYWdlIA0g ICBjb3VsZCBiaW5kIHRvZ2V0aGVyIHdpdGggcGVlciBQRSdzIGxvY2FsIEZFQyBlbGVtZW50LCB0 aGUgcGVlciBQRSANICAgc2VuZHMgbGFiZWwgbWFwcGluZyB3aXRoIGl0cyBib3VuZCBsb2NhbCBG RUMgZWxlbWVudCBhbmQgbGFiZWwgYXMgYSANICAgcmVzcG9uc2UuICBUaGUgbGFiZWwgcmVxdWVz dCBtZXNzYWdlIGZvcm1hdCBhbmQgcHJvY2VkdXJlIGlzIA0gICBkZXNjcmliZWQgaW4gW1JGQzUw MzZdLg0NICAgVGhlIG11bHRpLXNlZ21lbnQgUFcgY2FzZSBmb3IgVC1QRSBpcyBzYW1lLiwgUy1Q RSBTSE9VTEQgYXNzdW1lIGFuIGluaXRpYWwgcGFzc2l2ZSByb2xlIGFzIGRlZmluZWQgaW4gW1JG QzYwNzNdLiANYW5kIHRoZSByZXF1ZXN0IG1lc3NhZ2UgDSAgIE1VU1QgYmUgcHJvY2Vzc2VkIGlu IG9yZGVyZWQgbW9kZS4gIFdoZW4gUy1QRSByZWNlaXZlcyBhIGxhYmVsIA0gICByZXF1ZXN0IG1l c3NhZ2UgZnJvbSBhIHJlbW90ZSBwZWVyUEUsIGl0IE1VU1QgYWR2ZXJ0aXNlIHRoZSByZXF1ZXN0 IA0gICBtZXNzYWdlIHRvIHRoZSBvdGhlciByZW1vdGUgUEUuICBUaGlzIGlzIG5lY2Vzc2FyeSBz aW5jZSBTLVBFIGRvZXMgDSAgIG5vdCBoYXZlIGZ1bGwgaW5mb3JtYXRpb24gb2YgaW50ZXJmYWNl IHBhcmFtZXRlciBmaWVsZCBpbiB0aGUgRkVDIA0gICBhZHZlcnRpc2VtZW50LiAgV2hlbiBTLVBF IHJlY2VpdmVzIGEgbGFiZWwgcmVsZWFzZSBtZXNzYWdlIGZyb20gDSAgIHJlbW90ZSBwZWVyUEUs IGl0IE1VU1Qgc2VuZCBhIGNvcnJlc3BvbmRpbmcgbGFiZWwgcmVsZWFzZSB0byB0aGUgb3RoZXIg DSAgIHJlbW90ZSBQRSB3aGVyZSBpdCBoYXMgcmVjZWl2ZWQgbGFiZWwgbWFwcGluZy4NDSAgIEFz IGxvY2FsIFQtUEUgd2lsbCBzZW5kIGxhYmVsIHdpdGhkcmF3IGJlZm9yZSBzZW5kaW5nIGxhYmVs IHJlcXVlc3QgDSAgIHRvIHJlbW90ZSBwZWVyLCB0aGUgUy1QRSBNVVNUIHNlbmQgdGhlIGxhYmVs IHdpdGhkcmF3IHVwc3RyZWFtIGJlZm9yZSANICAgaXQgYWR2ZXJ0aXNlcyB0aGUgbGFiZWwgcmVx dWVzdC4gIFdoZW4gUy1QRSByZWNlaXZlcyB0aGUgbGFiZWwgDSAgIHdpdGhkcmF3LCBpdCBzaG91 bGQgcHJvY2VzcyB0aGlzIG1lc3NhZ2UgdG8gc2VuZCBhIGxhYmVsIHJlbGVhc2UgYXMgYSANICAg cmVzcG9uc2UgYW5kIGEgbGFiZWwgd2l0aGRyYXcgdG8gdXBzdHJlYW0gUy1QRS9ULVBFLCB0aGVu IHByb2Nlc3MgdGhlIA0gICBuZXh0IExEUCBtZXNzYWdlLCBlLmcuIHRoZSBsYWJlbCByZXF1ZXN0 IG1lc3NhZ2UuDQ0gICBXaGVuIExvY2FsIFBFIGNoYW5nZXMgaXRzIHRoZSB1c2Ugb2YgY29udHJv bCB3b3JkIGZyb20gUFJFRkVSUkVEIHRvIE5PVCANICAgUFJFRkVSUkVELCBMb2NhbCBQRSB3b3Vs ZCBiZSBhYmxlIHRvIHJlLW5lZ290aWF0ZSB0aGUgQ29udHJvbCBXb3JkIHRvIA0gICBiZSBOT1Qg UFJFRkVSUkVEIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFtSRkM0NDQ3XSwg YW5kIA0gICBubyBsYWJlbCByZXF1ZXN0IG1lc3NhZ2UgdG8gcGVlciBQRSB3aWxsIGJlIG5lZWRl ZC4gIEluIHRoYXQgY2FzZSwgDSAgIExvY2FsIFBFIHdpbGwgYWx3YXlzIHNlbmQgbmV3IGxhYmVs IG1hcHBpbmcgd2l0aCBDLWJpdCByZWZsZWN0aW5nIHRoZSANICAgTG9jYWxseSBjb25maWd1cmVk IHByZWZlcmVuY2UgZm9yIHVzZSBvZiBDb250cm9sIFdvcmQgY29uZmlndXJhdGlvbi4NDSAgIFRo ZSBkaWFncmFtIGluIEFwcGVuZGl4IEEgaW4gdGhpcyBkb2N1bWVudCB1cGRhdGVzIHRoZSBjb250 cm9sIHdvcmQgDSAgIG5lZ290aWF0aW9uIGRpYWdyYW0gaW4gW1JGQzQ0NDddIEFwcGVuZGl4IEEu DQ0NMy4xLiBDb250cm9sIHdvcmQgcmUtbmVnb3RpYXRpb24gdXNlIGNhc2UNICAgVGhlIHByb2Nl ZHVyZSBvZiBQRTEgYW5kIFBFMiBmb3IgdGhlIHVzZSBjYXNlIGluIGZpZ3VyZSAxIHNob3VsZCBi ZSBhcyANICAgZm9sbG93czoNDSAgICAgICAxLiBQRTIgY2hhbmdlcyBsb2NhbGx5IGNvbmZpZ3Vy ZWQgcHJlZmVyZW5jZSBmb3IgdXNlIG9mIGNvbnRyb2wgd29yZCB0byBQUkVGRVJSRUQuDQ0gICAg ICAgMi4gUEUyIHdpbGwgdGhlbiBzZW5kIGxhYmVsIHdpdGhkcmF3IGFuZCByZWxlYXNlIG1lc3Nh Z2VzIHRvIFBFMSwgYW5kIHdhaXQgdW50aWwgcmVjZWl2aW5nIGxhYmVsIHJlbGVhc2UgZnJvbSBQ RTEuDQ0gICAgICAgMy4gUEUxIHdpbGwgc2VuZCBsYWJlbCByZWxlYXNlIGluIHJlcGx5IHRvIGxh YmVsIHdpdGhkcmF3IG1lc3NhZ2UgDSAgICAgICAgICBmcm9tIFBFMi4gIEFmdGVyIHRoYXQgYW5k IHByb2Nlc3NpbmcgdGhlIGxhYmVsIHJlbGVhc2UgZnJvbSANICAgICAgICAgIFBFMiwgaXQgd291 bGQgcmVzZXQgbG9jYWwgdGhlIHVzZSBvZiBjb250cm9sIHdvcmQgdG8gdGhlIGxvY2FsbHkgY29u ZmlndXJlZCBvbmVwcmVmZXJlbmNlIGFzIFBSRUZFUlJFRC4NDSAgICAgICA0LiBVcG9uIHJlY2Vp cHQgb2YgTGFiZWwgcmVsZWFzZSBtZXNzYWdlIGZyb20gUEUxLCBQRTIgd291bGQgDSAgICAgICAg ICByZXNldCBsb2NhbCB1c2Ugb2YgY29udHJvbCB3b3JkIHRvIHRoZSBsb2NhbGx5IGNvbmZpZ3Vy ZWQgb25lcHJlZmVyZW5jZSBhcyBQUkVGRVJSRUQsIGFuZCBNVVNUIHNlbmQgDSAgICAgICAgICBs YWJlbCByZXF1ZXN0IG1lc3NhZ2UgdG8gUEUxLCBhbmQgd2FpdCB1bnRpbCByZWNlaXZpbmcgYSBs YWJlbCBtYXBwaW5nIG1lc3NhZ2UuDQ0gICAgICAgNS4gUEUxIE1VU1QgbXVzdCBzZW5kIGxhYmVs IG1hcHBpbmcgbWVzc2FnZSB3aXRoIEMtYml0PTEgYWdhaW4gdG8gUEUyIA0gICAgICAgICAgYXMg cmVzcG9uc2Ugb2YgbGFiZWwgcmVxdWVzdC4NDSAgICAgICA2LiBQRTIgcmVjZWl2ZXMgdGhlIGxh YmVsIG1hcHBpbmcgZnJvbSBQRTEgYW5kIGdldHMgdGhlIHJlbW90ZSANICAgICAgICAgIGxhYmVs IGJpbmRpbmcgaW5mb3JtYXRpb24uICBQRTIgY291bGQgc2hvdWxkIHdhaXQgZm9yIFBFMSBsYWJl bCANICAgICAgICAgIGJpbmRpbmcgYmVmb3JlIHNlbmRpbmcgaXRzIGxhYmVsIGJpbmRpbmcgd2l0 aCBDLWJpdCBzZXQuDQ0gICAgICAgNy4gUEUyIHdpbGwgc2VuZCBsYWJlbCBtYXBwaW5nIHRvIFBF MSB3aXRoIEMtYml0PTEsIGFuZCBmb2xsb3cgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFtSRkM0NDQ3 XSBzZWN0aW9uIDYuDQ0gICBJdCBpcyB0byBiZSBub3RlZCB0aGF0IHRoZSBhYm92ZSBhc3N1bWUg dGhhdCBQRTEgaXMgY29uZmlndXJlZCB0byANICAgc3VwcG9ydCBwcmVmZXIgdGhlIGNvbnRyb2wg d29yZENXLCBob3dldmVyIGluIHN0ZXAgNSBpZiBQRTEgZG9lc24ndCBwcmVmZXIgb3Igc3VwcG9y dCBjb250cm9sIHdvcmRDVywgUEUxIHdvdWxkIA0gICBzZW5kIHRoZSBsYWJlbCBtYXBwaW5nIG1l c3NhZ2Ugd2l0aCBDLWJpdD0wLCB0aGlzIHdvdWxkIHJlc3VsdCBpbiBQRTIgDSAgIGluIHN0ZXAg NyBzZW5kaW5nIGEgbGFiZWwgbWFwcGluZyB3aXRoIEMtYml0PTAgYXMgcGVyIFtSRkM0NDQ3XSBz ZWN0aW9uIDYuIENXIA0gICBuZWdvdGlhdGlvbiBwcm9jZWR1cmUuDQ0gICBCeSBzZW5kaW5nIGxh YmVsIHJlcXVlc3QgbWVzc2FnZSwgUEUyIHdpbGwgZ2V0IHRoZSBsb2NhbGx5IGNvbmZpZ3VyZWQg cHJlZmVyZW5jZSBmb3IgdXNlIG9mIGNvbnRyb2wgd29yZENXIA0gICBwYXJhbWV0ZXIgb2YgcGVl ciBQRTEgaW4gdGhlIHJlY2VpdmVkIGxhYmVsIG1hcHBpbmcgbWVzc2FnZS4gIEJ5IA0gICB1c2lu ZyB0aGUgbmV3IENXIHBhcmFtZXRlckMtYml0IGZyb20gbGFiZWwgbWFwcGluZyBtZXNzYWdlIHJl Y2VpdmVkIGZyb20gDSAgIHBlZXIgUEUxIGFuZCBsb2NhbGx5IGNvbmZpZ3VyZWQgcHJlZmVyZW5j ZSBmb3IgdXNlIG9mIGNvbnRyb2wgd29yZENXLCBQRTIgc2hvdWxkIGRldGVybWluZSB0aGUgdXNl IG9mIFBXIGNvbnRyb2wgd29yZENXIA0gICBwYXJhbWV0ZXIgYWNjb3JkaW5nIHRvIFtSRkM0NDQ3 XSBzZWN0aW9uIDYuDQ0gICBUaGUgZGlhZ3JhbSBpbiBBcHBlbmRpeCBBIGluIHRoaXMgZG9jdW1l bnQgdXBkYXRlcyB0aGUgY29udHJvbCB3b3JkIA0gICBuZWdvdGlhdGlvbiBkaWFncmFtIGluIFtS RkM0NDQ3XSBBcHBlbmRpeCBBLg0NNC4gQmFja3dhcmQgQ29tcGF0aWJpbGl0eQ0NICAgU2luY2Ug Y29udHJvbCB3b3JkIHJlLW5lZ290aWF0aW9uIGlzIG9wZXJhdGVkIGJ5IGFkZGluZyBsYWJlbCBy ZXF1ZXN0IA0gICBtZXNzYWdlLCBhbmQgc3RpbGwgZm9sbG93cyB0aGUgcHJvY2VkdXJlIGRlc2Ny aWJlZCBpbiBbUkZDNDQ0N10gDSAgIHNlY3Rpb24gNiwgaXQgaXMgZnVsbHkgY29tcGF0aWJsZSB3 aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gIFRoZSANICAgcmVtb3RlIFBFIChQRTEgaW4g ZmlndXJlIDEpIHdoaWNoIGFscmVhZHkgaW1wbGVtZW50IGxhYmVsIHJlcXVlc3QgDSAgIG1lc3Nh Z2UgY291bGQgYmUgY29tcGF0aWJsZSB3aXRoIHRoZSBQRSAoUEUyIGluIGZpZ3VyZSAxKSBmb2xs b3dpbmcgDSAgIHRoZSBtZWNoYW5pc20gb2YgdGhpcyBkb2N1bWVudC4NDTUuIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zDQ0gICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGludHJvZHVjZSBhbnkgYWRk aXRpb25hbCBzZWN1cml0eSBjb25zdHJhaW50cy4NDTYuIElBTkEgQ29uc2lkZXJhdGlvbnMNDSAg IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgcmVxdWlyZSBJQU5BIGFzc2lnbm1lbnQuDQ03LiBBY2tu b3dsZWRnZW1lbnRzDQ0gICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIFN0ZXdhcnQg QnJ5YW50LCBBbmRyZXcgTWFsaXMsIE5pY2sgDSAgIERlbCBSZWdubywgTHVjYSBNYXJ0aW5pLCBW ZW5rYXRlc2FuIE1haGFsaW5nYW0sIEFsZXhhbmRlciBWYWluc2h0ZWluLCANICAgQWRyaWFuIEZh cnJlbCBhbmQgU3Bpa2UgQ3VydGlzIGZvciB0aGVpciBkaXNjdXNzaW9uIGFuZCBjb21tZW50cy4N DTguIFJlZmVyZW5jZXMNDTguMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMNDSAgIFtSRkMyMTE5XSAg ICBCcmFkbmVyLCBTLiwgS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSANICAg ICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscywgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2gg MTk5Nw0NICAgW1JGQzQ0NDddICAgIE1hcnRpbmksIEwuLCBhbmQgYWwsIFBzZXVkb3dpcmUgU2V0 dXAgYW5kIE1haW50ZW5hbmNlDSAgICAgICAgICAgICAgICBVc2luZyB0aGUgTGFiZWwgRGlzdHJp YnV0aW9uIFByb3RvY29sIChMRFApLCBSRkMgNDQ0NywNICAgICAgICAgICAgICAgIEFwcmlsIDIw MDYNDSAgIFtSRkM1MDM2XSAgICBBbmRlcnNzb24sIEwuLCBNaW5laSwgSS4sIGFuZCBUaG9tYXMg Qi4sIA0gICAgICAgICAgICAgICAgTERQIFNwZWNpZmljYXRpb24sIFJGQyA1MDM2LCBPY3RvYmVy IDIwMDcNDQ0NQXV0aG9ycycgQWRkcmVzc2VzDQ0gICBMaXpob25nIEppbiAoZWRpdG9yKQ0gICBa VEUgQ29ycG9yYXRpb24NICAgODg5LCBCaWJvIFJvYWQNICAgU2hhbmdoYWksIDIwMTIwMywgQ2hp bmENICAgRW1haWw6IGxpemhvbmcuamluQHp0ZS5jb20uY24NDSAgIFJheW1vbmQgS2V5IChlZGl0 b3IpDSAgIEh1YXdlaQ0gICBFbWFpbDogcmF5bW9uZC5rZXlAaWVlZS5vcmcNDSAgIFNpbW9uIERl bG9yZA0gICBBbGNhdGVsLUx1Y2VudA0gICBFbWFpbDogc2ltb24uZGVsb3JkQGdtYWlsLmNvbQ0N ICAgVGhvbWFzIE5hZGVhdQ0gICBKdW5pcGVyDSAgIEVtYWlsOiB0bmFkZWF1QGp1bmlwZXIubmV0 DQ0gICBWaXNod2FzIE1hbnJhbCANICAgSGV3bGV0dC1QYWNrYXJkIENvLiANICAgMTkxMTEgUHJ1 bmVyaWRnZSBBdmUsIEJsZGcgNDQsIA0gICBDdXBlcnRpbm8sIENBIDk1MDE0LTA2OTENICAgRW1h aWw6IHZpc2h3YXMubWFucmFsQGhwLmNvbQ0NICAgU2FtaSBCb3V0cm9zDSAgIENpc2NvIFN5c3Rl bXMsIEluYy4NICAgMzc1MCBDaXNjbyBXYXkNICAgU2FuIEpvc2UsIENhbGlmb3JuaWEgOTUxMzQN ICAgVVNBDSAgIEVtYWlsOiBzYm91dHJvc0BjaXNjby5jb20NDSAgIFJlc2hhZCBSYWhtYW4NICAg Q2lzY28gU3lzdGVtcywgSW5jLg0gICAyMDAwIElubm92YXRpb24gRHJpdmUNICAgT3R0YXdhLCBP bnRhcmlvIEsySyAzRTgNICAgQ0FOQURBDSAgIEVtYWlsOiBycmFobWFuQGNpc2NvLmNvbQ0NDQ1B cHBlbmRpeCBBLiBVcGRhdGVkIEMtYml0IEhhbmRsaW5nIFByb2NlZHVyZXMgRGlhZ3JhbQ0NICAg IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDSAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0gICAgfCAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0t LS0tLS0tLS0tLQ0gICAgfCAgICAgICAgICAgICAgICAgICAgWSAgIHwgUmVjZWl2ZWQgTGFiZWwg fCAgICAgICBODSAgICB8ICAgICAgICAgICAgICAgICAtLS0tLS0tfCAgTWFwcGluZyBNc2c/ICB8 LS0tLS0tLS0tLS0tLS0NICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAtLS0tLS0tLS0tLS0t LS0tLS0gICAgICAgICAgICAgfA0gICAgfCAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DSAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNICAgIHwgICAgICAgICAgLS0tLS0tLSAgICAg IC0tLS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgfA0gICAgfCAgICAgICAgICB8IEM9MCB8 ICAgICAgfCBDPTEgfCAgICAgICAgICAgICAgICAgICAgICAgICB8DSAgICB8ICAgICAgICAgIC0t LS0tLS0gICAgICAtLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgIHwNICAgIHwgICAgICAg ICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0gICAgfCAg ICAgICAgICAgICB8ICAgIC0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgICAgICB8DSAg ICB8ICAgICAgICAgICAgIHwgICAgfCBDb250cm9sIFdvcmQgfCAgICAgTiAgICAgICAgICAgICAg IHwNICAgIHwgICAgICAgICAgICAgfCAgICB8ICAgIENhcGFibGU/ICB8LS0tLS0tLS0tLS0gICAg ICAgICAgfA0gICAgfCAgICAgICAgICAgICB8ICAgIC0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAg fCAgICAgICAgICB8DSAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgWSB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgIHwNICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgfA0gICAgfCAgICAgICAgICAgICB8ICAgLS0tLS0tLS0tLS0t LS0tLSAgICAgICAgICAgfCAgICAgICAgICB8DSAgICB8ICAgICAgICAgICAgIHwgICB8IENvbnRy b2wgV29yZCB8ICBOICAgICAgICB8ICAgICAgICAgIHwNICAgIHwgICAgICAgICAgICAgfCAgIHwg IFByZWZlcnJlZD8gIHwtLS0tICAgICAgIHwgICAgICAgICAgfA0gICAgfCAgICAgICAgICAgICB8 ICAgLS0tLS0tLS0tLS0tLS0tLSAgIHwgICAgICAgfCAgICAgICAgICB8DSAgICB8ICAgICAgICAg ICAgIHwgICAgICAgICAgWSB8ICAgICAgICAgfCAgICAgICB8ICAgICAgICAgIHwNICAgIHwgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLSAgIHwgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgfA0gICAg fCAgfCBDb250cm9sIFdvcmQgICAgICB8ICAgfCAgICAgICAgIHwgICAgICAgfCAgIC0tLS0tLS0t LS0tLS0tLS0NICAgIHwgIHwgY2hhbmdlIFByZWZlcnJlZCAgfCAgIHwgICAgICAgICB8ICAgICAg IHwgICB8IENvbnRyb2wgV29yZCB8DSAgICB8ICB8IHRvIG5vdC1QcmVmZXJyZWQ/IHwgICB8ICAg ICAgICAgfCAgICAgICB8ICAgfCAgUHJlZmVycmVkPyAgfA0gICAgfCAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tICAgfCAgICAgICAgIHwgICAgICAgfCAgIC0tLS0tLS0tLS0tLS0tLS0NICAgIHwgICAg IFkgfCAgICAgfCBOICAgICAgICAgIHwgICAgICAgICB8ICAgICAgIHwgICAgIE4gfCAgICAgWSB8 DSAgICB8ICAgICAgIHwgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICB8ICAgICAg IHwgICAgICAgfA0gICAgfCAgICAgICB8ICAgU2VuZCAgICAgICAgIFNlbmQgICAgICBTZW5kICAg IFNlbmQgICAgU2VuZCAgICBTZW5kDSAgICB8ICAgICAgIHwgICAgQz0wICAgICAgICAgIEM9MSAg ICAgICBDPTAgICAgIEM9MCAgICAgQz0wICAgICBDPTENICAgIHwgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8DSAgICB8ICAtLS0tLS0t LS0tLS0tLS0tLS0tICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0gICAgfCAgfCBTZW5kIHdpdGhkcmF3ICAgfCAgICAgICAgICAgIHwgSWYgcmVjZWl2ZSB0aGUg c2FtZSBhcyBzZW50LCAgIHwNICAgIHwgIHwgaWYgYWxyZWFkeSBzZW50IHwgICAgICAgICAgICB8 IFBXIHNldHVwIGlzIGNvbXBsZXRlLiBJZiBub3Q6ICB8DSAgICB8ICB8IGxhYmVsIG1hcHBpbmcs ICAgfCAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NfCAgIHwg YW5kIHJlbGVhc2UgbWVzc2FnZXwNICAgIHwgIC0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAg ICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8DSAgICB8ICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tDSAgICB8ICAtLS0t LS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgICB8ICAgICBSZWNlaXZlICAgICB8IHwgUmVjZWl2 ZSB8DSAgICB8ICB8IFNlbmQgUmVjZWl2aW5nIGxhYmVsICAgICAgfCAgICAgICAgICAgICAgfCAg ICAgICBDPTEgICAgICAgfCB8ICAgQz0wICAgfA0gICAgfCAgfCByZWxlYXNlIG1lc3NhZ2UgfCAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLQ0gICAgfCAgLS0tLS0t LS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwNICAg IHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFdhaXQgZm9yIHRoZSAgICAg ICAgU2VuZA0gICAgfCAgLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgbmV4dCBt ZXNzYWdlICAgICBXcm9uZyBDLWJpdA0gICAgfCAgfCBTZW5kIGxhYmVsICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNICAgIHwgIHwgcmVxdWVzdCBtZXNzYWdl IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VuZCBMYWJlbA0gICAgfCAgLS0t LS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXBwaW5nIE1l c3NhZ2UNICAgIHwgICAgICAgICAgIHwNICAgIC0tLS0tLS0tLS0tLS0NDQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAgAAKMIAACnCAAAqxkAALIZAADAGQAAwxkAANkbAADgGwAAYhwA AGkcAAD8HAAAAx0AAFseAABiHgAAZR4AAKAeAACnHgAA3R4AAOQeAAAtIAAANCAAAGYhAAB3IQAA fyEAAPnp+dn52fnJ+cn5ufmpk/mp+X35bfldTQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB4BCIEESAEABWhAdAaHFmg/RSQAbkgECG8oAXRIBAgAHgEIgQRIAQAFaCt0BocWaBtfPwBuSAQI bygBdEgECAAeAQiBBEgBAAVoOXQGhxZovCS3AG5IBAhvKAF0SAQIACsACIEVaLR8nQAWaLR8nQAX aAhp3QBjSAEAZGgAAAAAZGgAAAAAZGg5dAaHKwAIgRVotHydABZotHydABdoawu+AGNIAQBkaAAA AABkaAAAAABkaDh0BoceAQiBBEgBAAVoOHQGhxZoawu+AG5IBAhvKAF0SAQIAB4BCIEESAEABWg3 dAaHFmhrC74AbkgECG8oAXRIBAgAHgEIgQRIAQAFaDZ0BocWaGsLvgBuSAQIbygBdEgECAAeAQiB BEgBAAVoNXQGhxZoawu+AG5IBAhvKAF0SAQIAB4BCIEESAEABWjacwaHFmhyKnMAbkgECG8oAXRI BAgADBVotHydABZotHydABgACAAAAQgAAAIIAAADCAAATAgAAJUIAADiCAAAKwkAAHUJAAC+CQAA BwoAAAgKAAAJCgAAUgoAAFMKAABUCgAAkwoAAMkKAADKCgAAywoAANQKAADVCgAAGQsAAGELAACr CwAA9QsAAA8MAAAQDAAAEQwAACYMAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZI9PiQAAHSYMAAAnDAAAcQwAAJYMAACYDAAA3gwAACMNAABnDQAAcw0AAHUNAAC/ DQAACA4AAEsOAACKDgAAjA4AAMcOAAD3DgAA+Q4AAD4PAABjDwAAZQ8AAJsPAACcDwAArg8AALMP AAD3DwAAIxAAACgQAABpEAAArBAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA AAAAAAQPAGdkj0+JAAAdrBAAAPUQAAA+EQAAgxEAAM0RAAATEgAAXBIAAF0SAABeEgAAcBIAAHES AAC6EgAAAxMAAEwTAACVEwAA3hMAACcUAABwFAAAuRQAAAIVAABLFQAAlBUAAJUVAACWFQAAuRUA AL4VAAAGFgAATxYAAI0WAACOFgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2SPT4kAAB2OFgAAjxYAAJAWAACgFgAAoRYAAOUWAAAtFwAAdhcAAL8XAAAIGAAAGxgA ABwYAAAxGAAAMhgAAHwYAADBGAAABRkAAEkZAACSGQAA5hkAAC0aAABMGgAATRoAAJUaAACWGgAA yhoAAP4aAAAyGwAAZhsAAJobAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAA AAAEDwBnZI9PiQAAHZobAAC/GwAAwBsAABEcAAA4HAAAORwAAIYcAADKHAAA3RwAAN4cAAAtHQAA Lh0AAGodAABrHQAArx0AAPQdAAA4HgAAOR4AAIEeAADPHgAA7x4AAPAeAADxHgAAKR8AACofAABx HwAAsR8AAPcfAAAPIAAAECAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQPAGdkj0+JAAAdECAAAFggAACfIAAA5iAAAOcgAAAxIQAAniEAANohAADnIQAAKCIAACkiAABw IgAAuiIAABQjAAAVIwAAYiMAAKQjAADtIwAA7iMAAD4kAACJJAAA5SQAAEAlAABOJQAATyUAAJUl AADaJQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADqAAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABA8AZ2ROGgEACw8AZ2QbXz8Ab8YHAQEALXQGh2QmAQAEDwBnZBtfPwAA BA8AZ2SPT4kAABp/IQAAjSEAAI4hAADZIQAA2iEAACciAAAoIgAA1SIAAN0iAADoIgAA/iIAAAoj AAASIwAATyMAAFAjAABUIwAAdiMAAPojAADw4NnJs6fZl9mK2XTZZFQ+2QAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKwAIgRVotHydABZotHydABdoThoBAGNIAQBkaAAAAABkaAAA AABkaER0BoceAQiBBEgBAAVoRXQGhxZoThoBAG5IBAhvKAF0SAQIAB4BCIEESAEABWhEdAaHFmhO GgEAbkgECG8oAXRIBAgAKwAIgRVotHydABZotHydABdojDuYAGNIAQBkaAAAAABkaAAAAABkaEF0 BocZAQiBBEgBAAVoQ3QGhxVoThoBABZoThoBAB4BCIEESAEABWhBdAaHFmiMO5gAbkgECG8oAXRI BAgAFxVotHydABZotHydAG5IBAhvKAF0SAQIKwAIgRVotHydABZotHydABdoG18/AGNIAQBkaAAA AABkaAAAAABkaC10BocfAQiBBEgBAAVoLXQGhxVotHydABZoG18/ABdoG18/AAwVaLR8nQAWaLR8 nQAAHgEIgQRIAQAFaEB0BocWaIw7mABuSAQIbygBdEgECAAeAQiBBEgBAAVoLnQGhxZoG18/AG5I BAhvKAF0SAQIEfojAAD/IwAABSQAAAYkAACCJAAAiCQAAIkkAACMJAAAkiQAAKgkAACwJAAAuyQA AL4kAADIJAAAHCUAACclAAArJQAAMiUAAD4lAADp2czFtanFk8WDxW2DxWBQQMUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHgEIgQRIAQAFaEl0BocWaFZwUwBuSAQIbygBdEgECAAe AQiBBEgBAAVoSnQGhxZoVnBTAG5IBAhvKAF0SAQIABkBCIEESAEABWhKdAaHFWhOGgEAFmhWcFMA KwAIgRVotHydABZotHydABdoBGS4AGNIAQBkaAAAAABkaAAAAABkaEd0BoceAQiBBEgBAAVoR3QG hxZoBGS4AG5IBAhvKAF0SAQIACsACIEVaLR8nQAWaLR8nQAXaARkuABjSAEAZGgAAAAAZGgAAAAA ZGhGdAaHFxVotHydABZotHydAG5IBAhvKAF0SAQIHgEIgQRIAQAFaEZ0BocWaARkuABuSAQIbygB dEgECAAMFWi0fJ0AFmi0fJ0AABkBCIEESAEABWgxdAaHFWi0fJ0AFmj5DXsAHgEIgQRIAQAFaDF0 BocWaPkNewBuSAQIbygBdEgECAArAAiBFWi0fJ0AFmi0fJ0AF2j5DXsAY0gBAGRoAAAAAGRoAAAA AGRoMXQGhwASPiUAAEwlAADyJgAA8yYAAPQmAAD1JgAA+iYAAB8nAAA5JwAAOicAAHonAAC3JwAA uycAAL0nAAC5KAAAvSgAAOni0rzi0qubi3XiX0/iOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKwAIgRVotHydABZotHydABdoU3cgAGNIAQBkaAAAAABkaAAAAABkaEt0BoceAQiB BEgBAAVoS3QGhxZoU1kEAG5IBAhvKAF0SAQIACsACIEVaLR8nQAWaLR8nQAXaFNZBABjSAEAZGgA AAAAZGgAAAAAZGhLdAaHKwAIgRVotHydABZotHydABdocipzAGNIAQBkaAAAAABkaAAAAABkaNlz BocfAQiBBEgBAAVo2XMGhxVotHydABZocipzABdocipzAB4BCIEESAEABWjZcwaHFmhyKnMAbkgE CG8oAXRIBAgAIQEIgQRIAQAFaNlzBocVaHIqcwAWaHIqcwBuSAQIdEgECCsACIEVaLR8nQAWaLR8 nQAXaHIqcwBjSAEAZGgAAAAAZGgAAAAAZGjYcwaHHgEIgQRIAQAFaNhzBocWaHIqcwBuSAQIbygB dEgECAAMFWi0fJ0AFmi0fJ0AACsACIEVaLR8nQAWaLR8nQAXaFZwUwBjSAEAZGgAAAAAZGgAAAAA ZGhKdAaHAA/aJQAAICYAAGgmAACpJgAAxCYAAMUmAAA6JwAAUycAAJYnAADeJwAAJSgAAGsoAACv KAAA+igAACwpAAAtKQAAdSkAAL8pAAACKgAATCoAAJYqAADLKgAAzCoAABgrAABiKwAAqisAAPEr AAA7LAAAgywAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQPAGdkcipzAAAEDwBn ZI9PiQAAHL0oAAC/KAAABikAAA0pAAAQKQAAEikAABMpAAAdKQAAIykAACopAADLKgAAzCoAAOUq AADpKgAA8yoAAPQqAAA+LAAAPywAAEMsAABRLAAAWywAAGYsAABzLAAAgSwAAIIsAADw6dnJ2cnZ udnpremXh3rpc+ljVWPpP+kAACsACIEVaLR8nQAWaLR8nQAXaP4tPQBjSAEAZGgAAAAAZGgAAAAA ZGhRdAaHGwEIgQRIAQAFaFF0BocWaP4tPQBuSAQIdEgECB4BCIEESAEABWhRdAaHFmj+LT0AbkgE CG8oAXRIBAgADBVotHydABZo/i09AAAZAQiBBEgBAAVoUHQGhxVotHydABZo5F4EAB4BCIEESAEA BWhQdAaHFmjkXgQAbkgECG8oAXRIBAgAKwAIgRVotHydABZotHydABdo5F4EAGNIAQBkaAAAAABk aAAAAABkaFB0BocXFWi0fJ0AFmi0fJ0AbkgECG8oAXRIBAgeAQiBBEgBAAVoTXQGhxZonSvvAG5I BAhvKAF0SAQIAB4BCIEESAEABWhNdAaHFmgCY+sAbkgECG8oAXRIBAgAHgEIgQRIAQAFaEx0BocW aAJj6wBuSAQIbygBdEgECAAMFWi0fJ0AFmi0fJ0AAB4BCIEESAEABWhLdAaHFmhTdyAAbkgECG8o AXRIBAgYgiwAAIMsAACELAAA+ywAAPwsAAD9LAAA/iwAAAAtAAACLQAAHy0AACctAAAoLQAAUC0A AFQtAACpLQAAsy0AAL4tAAC/LQAAIi4AAD0uAADw4M6soPCT4JPgoIx8jG5eUYxBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4BCIEESAEABWgjdAaHFmi2f7EAbkgECG8oAXRIBAgAGQEI gQRIAQAFaFJ0BocVaLR8nQAWaMR2QwAeAQiBBEgBAAVoUnQGhxZoxHZDAG5IBAhvKAF0SAQIABsB CIEESAEABWhSdAaHFmjEdkMAbkgECHRIBAgeAQiBBEgBAAVoUnQGhxZo+nh6AG5IBAhvKAF0SAQI AAwVaLR8nQAWaLR8nQAAGQEIgQRIAQAFaDJ0BocVaLR8nQAWaMtwdQAXFWjLcHUAFmjLcHUAbkgE CG8oAXRIBAhCAAiBAQiBBEgBAARIAQAFaDJ0BocFaDJ0BocVaLR8nQAWaMtwdQAXaHEOrABjSAEA ZGgAAAAAZGgAAAAAZGgydAaHACMBCIEESAEABEgBAAVoMnQGhwVoMnQGhxVotHydABZoy3B1AB4B CIEESAEABWgydAaHFmjLcHUAbkgECG8oAXRIBAgAHgEIgQRIAQAFaDJ0BocWaLR8nQBuSAQIbygB dEgECBODLAAAhCwAAMwsAAD8LAAA/SwAAP4sAAAoLQAAcy0AAH8tAACALQAA2i0AANstAABVLgAA Vi4AAKAuAADnLgAAWS8AAFovAACfLwAADjAAAGgwAABpMAAAtzAAAN8wAADgMAAAJzEAAHIxAAC1 MQAAtjEAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQPAGdky3B1AAAEDwBnZI9P iQAAHD0uAABTLgAABS8AAAsvAAAVLwAAFi8AACovAAAyLwAAPS8AAEAvAABKLwAATi8AAFcvAACv LwAAtS8AALsvAAC8LwAA0C8AANgvAADjLwAA5i8AAPAvAAD0LwAA/S8AADQwAADw6dPDtunD6dPD ppnpg3Nm6XPpg3NWSekAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQEIgQRIAQAFaFt0BocVaLR8nQAW aFFzUAAeAQiBBEgBAAVoW3QGhxZoUXNQAG5IBAhvKAF0SAQIABkBCIEESAEABWhZdAaHFWi0fJ0A FmgaJzEAHgEIgQRIAQAFaFl0BocWaBonMQBuSAQIbygBdEgECAArAAiBFWi0fJ0AFmi0fJ0AF2ga JzEAY0gBAGRoAAAAAGRoAAAAAGRoWXQGhxkBCIEESAEABWhbdAaHFWi0fJ0AFmhBeTAAHgEIgQRI AQAFaFp0BocWaEF5MABuSAQIbygBdEgECAAZAQiBBEgBAAVoV3QGhxVotHydABZo63nAAB4BCIEE SAEABWhXdAaHFmjrecAAbkgECG8oAXRIBAgAKwAIgRVotHydABZotHydABdo63nAAGNIAQBkaAAA AABkaAAAAABkaFd0BocMFWi0fJ0AFmi0fJ0AAB4BCIEESAEABWgkdAaHFmi2f7EAbkgECG8oAXRI BAgYNDAAAD8wAABmMAAAdzAAAHwwAACAMAAAgTAAAFExAABXMQAAXTEAAF4xAADvMQAA9TEAABEy AAAlMgAAJjIAACcyAABxMgAAeTIAAH8yAADw49zGtqnck4N23INsdtxg3Eo8AAAAAAAAAAAAAAAA AAAAAAAAAAAAGwEIgQRIAQAFaGJ0BocWaBM89ABuSAQIdEgECCsACIEVaLR8nQAWaLR8nQAXaBM8 9ABjSAEAZGgAAAAAZGgAAAAAZGhidAaHFxVotHydABZotHydAG5IBAhvKAF0SAQIEwEIgQRIAQAF aGB0BocWaM1KbQAZAQiBBEgBAAVoYHQGhxVotHydABZozUptAB4BCIEESAEABWhgdAaHFmjNSm0A bkgECG8oAXRIBAgAKwAIgRVotHydABZotHydABdozUptAGNIAQBkaAAAAABkaAAAAABkaGB0BocZ AQiBBEgBAAVoJnQGhxVotHydABZotn+xAB4BCIEESAEABWgmdAaHFmi2f7EAbkgECG8oAXRIBAgA KwAIgRVotHydABZotHydABdotn+xAGNIAQBkaAAAAABkaAAAAABkaCZ0BocMFWi0fJ0AFmi0fJ0A ABkBCIEESAEABWgwdAaHFWi0fJ0AFmjEMO4AHgEIgQRIAQAFaDB0BocWaMQw7gBuSAQIbygBdEgE CBO2MQAAJzIAACgyAABuMgAA4jIAACwzAAB+MwAAmDMAAJkzAAAINAAATTQAAJo0AAAWNQAARTUA AEY1AACONQAAvjUAAL81AADZNQAA2jUAACQ2AABoNgAAsjYAAPg2AABANwAAYzcAAGQ3AAB/NwAA gDcAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQPAGdkj0+JAAAEDwBnZM1KbQAA HH8yAACQMgAAkjIAALUyAAC7MgAAvzIAAMcyAADTMgAA1TIAAG8zAAB6MwAAlzMAAM4zAADWMwAA 4jMAAAQ0AAAGNAAACzQAABU0AABeNAAAajQAAG80AAC9NAAA3zQAAPDa08Xw0/Da07Wf04/Tj3nT edNjU9NDAAAAAAAAAAAAAAAAAAAAHgEIgQRIAQAFaGZ0BocWaOthRABuSAQIbygBdEgECAAeAQiB BEgBAAVoZnQGhxZol1GUAG5IBAhvKAF0SAQIACsACIEVaLR8nQAWaLR8nQAXaJdRlABjSAEAZGgA AAAAZGgAAAAAZGhmdAaHKwAIgRVotHydABZotHydABdoFHE0AGNIAQBkaAAAAABkaAAAAABkaGV0 BoceAQiBBEgBAAVoZXQGhxZoFHE0AG5IBAhvKAF0SAQIACsACIEVaLR8nQAWaLR8nQAXaI96PwBj SAEAZGgAAAAAZGgAAAAAZGhkdAaHHgEIgQRIAQAFaGR0BocWaI96PwBuSAQIbygBdEgECAAbAQiB BEgBAAVoYnQGhxZoEzz0AG5IBAh0SAQIDBVotHydABZotHydAAArAAiBFWi0fJ0AFmi0fJ0AF2gT PPQAY0gBAGRoAAAAAGRoAAAAAGRoYnQGhx4BCIEESAEABWhidAaHFmgTPPQAbkgECG8oAXRIBAgX 3zQAAOE0AAD8NAAAAzUAAAY1AAASNQAAFDUAABk1AAAjNQAARjUAAL41AAC/NQAA0ToAANI6AACs PQAArT0AALhGAAC8RgAAzkYAAM9GAAABRwAAAkcAAAhHAAALRwAAFEcAAOni0uLSvOK84qSY4pji mOKA4nDiYFBwUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4BCIEESAEABWgq dAaHFmi2f7EAbkgECG8oAXRIBAgAHgEIgQRIAQAFaCp0BocWaLR8nQBuSAQIbygBdEgECAAeAQiB BEgBAAVoaHQGhxZoWF8eAG5IBAhvKAF0SAQIAC8ACIEVaLR8nQAWaLR8nQAXaLZ/sQBjSAEAZGgA AAAAZGgAAAAAZGgqdAaHZ0ghABcVaLR8nQAWaLR8nQBuSAQIbygBdEgECC8ACIEVaLR8nQAWaLR8 nQAXaMtwdQBjSAEAY0gBAGRoAAAAAGRoMnQGh2RoMnQGhysACIEVaLR8nQAWaLR8nQAXaIRdNABj SAEAZGgAAAAAZGgAAAAAZGhmdAaHHgEIgQRIAQAFaGZ0BocWaIRdNABuSAQIbygBdEgECAAMFWi0 fJ0AFmi0fJ0AACsACIEVaLR8nQAWaLR8nQAXaOthRABjSAEAZGgAAAAAZGgAAAAAZGhmdAaHABiA NwAAyTcAAMo3AADhNwAA4jcAABU4AAAWOAAAKjgAACs4AAByOAAAvDgAAAE5AAACOQAAEDkAABE5 AAArOQAALDkAAHA5AACxOQAAsjkAAPg5AAA/OgAAWjoAAFs6AACVOgAAzzoAANA6AADROgAA0joA AOU6AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZI9PiQAAHeU6 AADmOgAA/joAABE7AAAjOwAAPjsAAF87AABgOwAAeDsAAII7AAChOwAAojsAALI7AADEOwAA5TsA AOY7AAD3OwAAAjwAACA8AAAhPAAANDwAAEw8AABvPAAAizwAAKs8AACsPAAAvDwAANM8AADlPAAA Az0AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkj0+JAAAdAz0A AAo9AAAnPQAAKD0AADk9AABQPQAAaT0AAIQ9AACOPQAAqj0AAKs9AACsPQAArT0AAOM9AADkPQAA DD4AADQ+AABkPgAAnD4AANo+AAAYPwAAVj8AAJQ/AADSPwAAEEAAAE5AAACMQAAAykAAAAhBAABG QQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2SPT4kAAB1GQQAA hEEAAMJBAAAAQgAAPkIAAHxCAAC6QgAA+EIAADZDAAB0QwAAukMAAABEAABGRAAAjEQAAM9EAAAS RQAAVkUAAJpFAADdRQAAJkYAAG9GAAC4RgAAAkcAAB1HAABgRwAAqEcAAPBHAABCSAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAAAAA8PAGdktn+xAG/GBwEBACp0BodkJgERhJUBYISVAQAEDwBnZI9PiQAAGxRHAAAb RwAAHEcAAB1HAAD5RwAA/kcAAAdIAAAISAAAUEoAAFFKAADw4NTNt6eazZMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAwVaLR8nQAWaGwh3QAAGQEIgQRIAQAFaCl0BocVaLR8nQAWaLZ/sQAeAQiBBEgBAAVoKXQG hxZotn+xAG5IBAhvKAF0SAQIACsACIEVaLR8nQAWaLR8nQAXaLZ/sQBjSAEAZGgAAAAAZGgAAAAA ZGgpdAaHDBVotHydABZotHydAAAXFWi0fJ0AFmi2f7EAbkgECG8oAXRIBAgeAQiBBEgBAAVoKnQG hxZotn+xAG5IBAhvKAF0SAQIAB4BCIEESAEABWhndAaHFmhYXx4AbkgECG8oAXRIBAgJQkgAAIpI AADNSAAAEUkAAFlJAACcSQAA40kAACxKAAA+SgAAUEoAAFFKAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA8AZ2SPT4kAAAo2ADGQOAEy UAIAOnCPT4kAH7CCLiCwxkEhsG4EIrCIBSOQoAUkkKAFJbAAABewUwMYsOADDJCpAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqBBMAEgABAAsBDwAHAAMA BAADAAAABAAIAAAAmAAAAJ4AAACeAAAAngAAAJ4AAACeAAAAngAAAJ4AAACeAAAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYC AAB2AgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAPgIAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAKgAAAA2BgAANgYAABYAAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAALgAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAABoAQAASAEAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAsAMA ADYGAAAyBgAAGAAAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAA cAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA6AEAACAEAAAw BAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAE AABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQA AEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAA QAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABA BAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAE AABQBAAAYAQAAHAEAACABAAAkAQAADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAgAAAAT0oD AFBKBABRSgMAX0gBBG1ICQRuSAQIc0gJBHRIBAgAAAAASgAAYPH/AgBKAAwQAABsId0AAAACAGNr h2UAAAsAAAADJAMxJABhJAMAIABDShUAS0gCAF9IAQRhShYAbUgJBG5IBAhzSAkEdEgECAAAAAAA AAAAAAAAAAAAAAAAACQAQSDy/6EAJAAMDQAAAAAAABAABgDYnqSLtWs9hFdbU08AAAAAQgBpAPP/ swBCAAwdAAAAAAAAMAYEAG5mGpBoiDxoAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAAC AAsAAAAgAGsg9P/BACAAAA0AAAAAAAAwBgMA4GUXUmiIAAACAAwAAAAAAEgAWmABAPIASAAMDBAA tHydADAGAwCvfodlLGcAAAsADwADJAAxJAFhJAAAHABLSAAAT0oFAFBKBABRSgUAXkoAAGFKFQB0 SAkERAD+L6IAAQFEAAwADwC0fJ0AMAYIAK9+h2UsZyAAQwBoAGEAcgAAABwAS0gAAE9KBQBQSgQA UUoFAF5KAABhShUAdEgJBC4AmQABABIBLgAMDRIAcipzADAGBQB5YuhsRmiHZSxnAAACABEACABD ShIAYUoSADQA/i+iACEBNAAMAREAcipzADAGCgB5YuhsRmiHZSxnIABDAGgAYQByAAAACABDShIA YUoSAFBLAwQUAAYACAAAACEAgoq8E/oAAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctq wzAQRfeF/oPQtthyuiil2M6iSXd9LNIPGOSxLWqPhDQJyd937LhQuggtdCMQYs6Ze1Wuj+OgDhiT 81TpVV5ohWR946ir9PvuKbvXKjFQA4MnrPQJk17X11fl7hQwKZmmVOmeOTwYk2yPI6TcByR5aX0c geUaOxPAfkCH5rYo7oz1xEic8cTQdfkqC0TXoHqDyC8wisewoPD7+QwkgJgLWKvHM2FaotIQwuAs sEQwB2p+6DPfts5i4+1+FGk+gxfYzQQzv1xg9T/qL+cGW9gPrLZH6eJcf8Qh/S3bUmsuk3P+1LuQ Lhgul7e0Yea/rT8BAAD//wMAUEsDBBQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJl bHOEj89qwzAMh++FvYPRfVHSwxgldi+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nh lOcgFpqqBsPiQz/LaOF2Pb9/gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk 0ckQ0kpF2zRiJH+nkXFf1x+YnhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGo L+NTvZCoZarUHtC1uPnW/QEAAP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0aGVt ZS90aGVtZS90aGVtZU1hbmFnZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpBx6DS n9vX5eODN87fFNWbSw1ZLJwHDYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9I9WQ ha213SDWtSvVIe8s3V65JGo9i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAhAMcc bRScBgAAURsAABYAAAB0aGVtZS90aGVtZS90aGVtZTEueG1s7FlNbxtFGL4j8R9Ge29jJ3YaR3Wq 2LEbaNNGsVvU43g93p16dmc1M07qG2qPSEiIgnqgEuLCAQGVWgkkyq9JKSpF6l/gnZnd9U68Jkkb QQX1IfHOPu/3x7wzvnjpTsTQPhGS8rjpVc9XPERinw9pHDS9G/3uuTUPSYXjIWY8Jk1vSqR3aeP9 9y7idRWSiCCgj+U6bnqhUsn60pL0YRnL8zwhMbwbcRFhBY8iWBoKfAB8I7a0XKmsLkWYxh6KcQRs r49G1Cfo2c+/vPjmgbeRce8wEBErqRd8JnqaN3FIDHY4rmqEnMo2E2gfs6YHgob8oE/uKA8xLBW8 aHoV8/GWNi4u4fWUiKkFtAW6rvmkdCnBcLxsZIpgkAutdmuNC1s5fwNgah7X6XTanWrOzwCw74Ol Vpciz1p3rdrKeBZA9us873alXqm5+AL/lTmdG61Wq95IdbFMDch+rc3h1yqrtc1lB29AFl+fw9da m+32qoM3IItfncN3LzRWay7egEJG4/EcWge0202555ARZ9ul8DWAr1VS+AwF2ZBnlxYx4rFalGsR vs1FFwAayLCiMVLThIywD2ncxtFAUKwF4HWCC2/ski/nlrQsJH1BE9X0PkwwlMSM36un3796+hgd 3n1yePenw3v3Du/+aBk5VNs4DopUL7/97M+HH6M/Hn/98v4X5XhZxP/2wyfPfv28HAjlM1Pn+ZeP fn/y6PmDT198d78EvinwoAjv04hIdI0coD0egWHGK67mZCBOR9EPMS1SbMaBxDHWUkr4d1TooK9N MUuj4+jRIq4HbwpoH2XAy5PbjsK9UEwULZF8JYwc4A7nrMVFqReuaFkFN/cncVAuXEyKuD2M98tk t3HsxLczSaBvZmnpGN4OiaPmLsOxwgGJiUL6HR8TUmLdLUodv+5QX3DJRwrdoqiFaalL+nTgZNOM aJtGEJdpmc0Qb8c3OzdRi7Myq7fIvouEqsCsRPk+YY4bL+OJwlEZyz6OWNHhV7EKy5TsTYVfxHWk gkgHhHHUGRIpy2iuC7C3EPQrGDpWadh32DRykULRcRnPq5jzInKLj9shjpIybI/GYRH7gRxDimK0 y1UZfIe7FaKfIQ44Xhjum5Q44T6+G9yggaPSLEH0m4nQsYRW7XTgiMZ/144ZhX5sc+Ds2jE0wOdf PSzJrLe1EW/CnlRWCdtH2u8i3NGm2+ZiSN/+nruFJ/EugTSf33jetdx3Ldf7z7fcRfV80kY7663Q dvXcYIdiMyJHCyfkEWWsp6aMXJVmSJawTwy7sKjpzPGQ5CemJISvaV93cIHAhgYJrj6iKuyFOIEB u+ppJoFMWQcSJVzCwc4sl/LWeBjSlT0W1vWBwfYDidUOH9rlFb2cnQtyNma3CczhMxO0ohmcVNjK hZQpmP06wqpaqRNLqxrVTKtzpOUmQwznTYPF3JswgCAYW8DLq3BA16LhYIIZGWq/2703C4uJwlmG SIZ4SNIYabvnY1Q1QcpyxdwEQO6UxEgf8o7xWkFaQ7N9A2knCVJRXG2BuCx6bxKlLINnUdJ1e6Qc WVwsThajg6bXqC/XPeTjpOmN4EwLX6MEoi71zIdZADdDvhI27Y8tZlPls2g2MsPcIqjCNYX1+5zB Th9IhFRbWIY2NcyrNAVYrCVZ/Zfr4NazMsBm+mtosbIGyfCvaQF+dENLRiPiq2KwCyvad/YxbaV8 oojohcMDNGATsYch/DpVwZ4hlXA1YTqCfoB7NO1t88ptzmnRFW+vDM6uY5aEOG23ukSzSrZwU8e5 DuapoB7YVqq7Me70ppiSPyNTimn8PzNF7ydwU7Ay1BHw4R5XYKTrtelxoUIOXSgJqd8VMDiY3gHZ Anex8BqSCm6TzX9B9vV/W3OWhylrOPCpPRogQWE/UqEgZBfaksm+Y5hV073LsmQpI5NRBXVlYtUe kH3C+roHruq93UMhpLrpJmkbMLij+ec+pxU0CPSQU6w3p4fke6+tgX968rHFDEa5fdgMNJn/cxVL dlVLb8izvbdoiH4xG7NqWVWAsMJW0EjL/jVVOOVWazvWnMXL9Uw5iOK8xbCYD0QJ3Pcg/Qf2Pyp8 Rkwa6w21z/egtyL4oUEzg7SBrD5nBw+kG6RdHMDgZBdtMmlW1rXp6KS9lm3WZzzp5nKPOFtrdpJ4 n9LZ+XDminNq8SydnXrY8bVdW+hqiOzREoWlUXaQMYExv2kVf3Xig9sQ6C24358wJU0ywW9KAsPo 2TN1AMVvJRrSjb8AAAD//wMAUEsDBBQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhl bWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4Tk NQ02PyRR7O0NriwILodhvplpu5edyRNjMt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0V Z5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCuOKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZllCa /7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAjm6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYACAAAACEA goq8E/oAAAAcAgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQA BgAIAAAAIQCl1qfnwAAAADYBAAALAAAAAAAAAAAAAAAAACsBAABfcmVscy8ucmVsc1BLAQItABQA BgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAAABQCAAB0aGVtZS90aGVtZS90aGVtZU1h bmFnZXIueG1sUEsBAi0AFAAGAAgAAAAhAMccbRScBgAAURsAABYAAAAAAAAAAAAAAAAA0QIAAHRo ZW1lL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEADdGQn7YAAAAbAQAAJwAAAAAAAAAA AAAAAAChCQAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAF AAUAXQEAAJwKAAAAADw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFs b25lPSJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9y bWF0cy5vcmcvZHJhd2luZ21sLzIwMDYvbWFpbiIgYmcxPSJsdDEiIHR4MT0iZGsxIiBiZzI9Imx0 MiIgdHgyPSJkazIiIGFjY2VudDE9ImFjY2VudDEiIGFjY2VudDI9ImFjY2VudDIiIGFjY2VudDM9 ImFjY2VudDMiIGFjY2VudDQ9ImFjY2VudDQiIGFjY2VudDU9ImFjY2VudDUiIGFjY2VudDY9ImFj Y2VudDYiIGhsaW5rPSJobGluayIgZm9sSGxpbms9ImZvbEhsaW5rIi8+AAAAAFFCAAASAAB+AAAF AP////8ACAAAfyEAAPojAAA+JQAAvSgAAIIsAAA9LgAANDAAAH8yAADfNAAAFEcAAFFKAAAmAAAA LQAAAC4AAAAvAAAAMQAAADIAAAA0AAAANQAAADcAAAA4AAAAPQAAAAAIAAAmDAAArBAAAI4WAACa GwAAECAAANolAACDLAAAtjEAAIA3AADlOgAAAz0AAEZBAABCSAAAUUoAACcAAAAoAAAAKQAAACoA AAArAAAALAAAADAAAAAzAAAANgAAADkAAAA6AAAAOwAAADwAAAA+AAAADwAA8DgAAAAAAAbwGAAA AAIIAAACAAAAAQAAAAEAAAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALwkgAA ABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEA AAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAAAAAADUAAAA8AAAAjgAAAJQAAADLAAAA 0QAAAFQBAABbAQAAXAEAAGIBAADyAQAA+AEAAPkBAAD/AQAAXgIAAGgCAADjBQAA7AUAAPEYAADy GAAAZTAAAGowAAB5MAAAfjAAAI4wAACYMAAAmTAAAKMwAACvMAAAuTAAAMYwAADMMAAAPDEAAEMx AADXMQAA4TEAAGsyAAB0MgAAejIAAH8yAADpMgAA8DIAABkzAAAdMwAAezMAAIEzAACrMwAAsTMA ACQ0AAArNAAALDQAADI0AABVNAAAXzQAACs1AAAxNQAAMjUAADg1AADENgAAxzYAAC89AAAzPQAA OT0AAD09AABBPQAART0AAEk9AABNPQAAUT0AAFU9AACGPQAAiT0AAI49AACRPQAAU0IAAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAGwAHABsABwAbAAcAGwAHABsABwAbAAcAGwAHAAAAAAClAgAAyAIAABwDAAAlAwAAZAMAAGsD AACuAwAAuQMAAPgDAAADBAAAdAQAAH4EAADhBAAAFgUAACYFAAArBQAAagUAAHEFAADCBQAAxQUA AAsGAAAPBgAATgYAAFYGAAD6BwAAAggAAK8IAADzCAAAQQkAAEQJAACGCQAAjwkAANAJAADSCQAA FgoAAB4KAABSDgAAWg4AAOgOAADxDgAAMA8AADcPAAB5DwAAfg8AAMIPAADIDwAAxBAAAM0QAABM EQAAVxEAAJURAACYEQAA6REAAO0RAAALEwAAERMAABsUAAAeFAAAkRQAAJQUAADUFAAA2xQAALkV AADBFQAA/hUAAAcWAACEFgAAjRYAANIWAADVFgAAdBcAAHwXAAC0FwAAvxcAAPoXAAAOGAAAohgA AKkYAAA+GQAAQBkAAKsZAAC0GQAAMRoAADUaAABEGgAASBoAAH0aAACAGgAAxxoAAMoaAAAcGwAA IRsAALEbAADsGwAAKhwAADIcAABBHAAASBwAAJIcAACZHAAA6BwAAOkcAACYHQAAnR0AAN0dAADi HQAAIx4AACgeAABrHgAAcx4AAKweAAC1HgAAAR8AAAcfAACZHwAAoB8AAOEfAADoHwAAKCAAACsg AABuIAAAeyAAALIgAAC4IAAA/SAAAAMhAAB4IQAAeiEAAMIhAADEIQAABSIAAA0iAABPIgAAVyIA AJkiAACdIgAAZSMAAGcjAACtIwAAryMAAD4kAACCJAAAzyQAANokAAB2JQAAfSUAAKomAACuJgAA qScAAK4nAAAYKAAAHSgAAMEoAADDKAAAMSkAADYpAAB8KQAAgykAAHkqAAB/KgAA5SoAAOkqAAAv KwAAMSsAABUsAAAXLAAAUCwAAFUsAACdLAAAoSwAACMtAAAsLQAAJy4AAC4uAABrLgAAci4AALUu AAC7LgAA+y4AAAIvAABDLwAARi8AAGwwAABwMAAAvzAAAAAxAABrMgAAkzIAALk2AADDNgAADDkA ACw5AABjOgAAZzoAAJI6AACeOgAAeDsAAHw7AAC+OwAAwjsAAAQ8AAAIPAAANTwAAEE8AAAqPgAA Lj4AAHM+AAB3PgAAvD4AAMA+AACsPwAAwj8AAPQ/AAD4PwAARkAAAEpAAAAVQQAAK0EAAF1BAABh QQAAoEEAAKRBAADnQQAA/UEAAFNCAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAAAAAAnAcAALYHAACQDgAApA4AAM8WAADxFgAAQB0AAFIdAAC/LQAA 3S0AANIyAADpMgAA8D8AAEZAAADnQQAAUEIAAFNCAAAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcAMgAAAAQAAAAIAAAA5QAAAAAAAAApAAAAThoBAFNZBADkXgQA7nUIAFhfHgBTdyAA P0UkAEF5MAAaJzEAhF00ABRxNAACejgA/i09ABtfPwCPej8AxHZDAOthRAD6b08AUXNQAFZwUwBs UmcA8n1pAM1KbQByKnMAy3B1APp4egD5DXsAj0+JAJdRlACMO5gAtHydAHEOrAD+Na8Atn+xALwk twAEZLgAmDG9AGsLvgDrecAAzgbHAGwh3QAIad0Aql7mAAJj6wDEMO4AnSvvAMc+8QATPPQAXQL2 AOZH/AAAAAAAUUIAAFNCAAAAAAAAAQAAAP9AAYABAIIaAACCGgAAAKimCQEAAQCCGgAAAAAAAIIa AAAAAAAAAhAAAAAAAAAAUUIAAJAAABAAQAAA//8CAAAABwBVAG4AawBuAG8AdwBuAAsATABpAHoA aABvAG4AZwAgAEoAaQBuAP//AgAIAAAAAAAAAAAAAAAAAAAAAAAAAAEA//8CAAAAAAAAAP//AAAC AP//AAAAAP//AAACAP//AAAAAAcAAABHHpABAAACAgYDBQQFAgME/yoA4EF4AMAJAAAAAAAAAP8B AAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1HpABAgAFBQECAQcGAgUHAAAA AAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzLpABAAACCwYEAgICAgIE/yoA4EN4 AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAANy6QAQAAAg8FAgICBAMCBP8CAOH/rABACQAA AAAAAACfAQAAAAAAAEMAYQBsAGkAYgByAGkAAAA7DpABhgMCAQYAAwEBAQEBAwAAAAAAjygWAAAA AAAAAAEABAAAAAAAi1tTTwAAUwBpAG0AUwB1AG4AAABPMZABAAgCBwQJAgIFAgQEAwAAAAAAAAAA AAAAAAAAAAEAAAAAAAAAQwBvAHUAcgBpAGUAcgAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAAEEe kAEAAAIEBQMFBAYDAgTvAgCg6yAAQgAAAAAAAAAAnwEAAAAAAABDAGEAbQBiAHIAaQBhACAATQBh AHQAaAAAACAABABxiIgYAACkAQAAaAEAAAAAbXQGh210BocAAAAAAgAFAAAA5QkAAGw4AAAJACEA AAAEAAOQeAAAAOUJAABsOAAACQAhAAAAeAAAAAAAAAAhAwAAAAAAAAMAPwAbACEAJQApACwALgA6 ADsAPgA/AF0AfQCiAKgAsAC3AMcCyQIVIBYgGSAdICYgMCAyIDMgOiADITYiATACMAMwCTALMA0w DzARMBUwFzAeMDb+Ov4+/kD+RP5a/lz+Xv4B/wL/Bf8H/wn/DP8O/xr/G/8f/z3/QP9c/13/Xv/g /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAkACgAWwB7AKMApQC3ABggHCAIMAowDDAOMBAwFDAWMB0wWf5b /l3+BP8I/w7/O/9b/+H/5f8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABuBKAFtACcAIKAMgAAAAAAAAAAAAAAAAAAADBCAAAwQgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAEy g1EAAAAAAAD8/QEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIS1gAAAAACfD/DwEIJFAAAKgDAACj AAAA////f////3////9/////f////3////9/tHydAAAEAAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAA IQQAAAAAAAAAAAAAAAAAAAAAAAAQHAAABgAAAAAAAAAAAHgAAAB4AAAAAAAAAAAAAACgBQAA//8S AAAAAAAAAAAAAAAAAAAACwBMAGkAegBoAG8AbgBnACAASgBpAG4ACwBMAGkAegBoAG8AbgBnACAA SgBpAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlP aBCrkQgAKyez2TAAAAAkAQAADQAAAAEAAABwAAAABAAAAHgAAAAHAAAAjAAAAAgAAACgAAAACQAA ALQAAAASAAAAwAAAAAoAAADgAAAADAAAAOwAAAANAAAA+AAAAA4AAAAEAQAADwAAAAwBAAAQAAAA FAEAABMAAAAcAQAAAgAAAKgDAAAeAAAADAAAAExpemhvbmcgSmluAB4AAAAMAAAATm9ybWFsLmRv dG0AHgAAAAwAAABMaXpob25nIEppbgAeAAAABAAAADIAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZp Y2UgV29yZAAAAEAAAAAAXtCyAAAAAEAAAAAANl9dEkrNAUAAAAAANl9dEkrNAQMAAAAJAAAAAwAA AOUJAAADAAAAbDgAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss +a4wAAAArAAAAAoAAAABAAAAWAAAAA8AAABgAAAABQAAAGwAAAAGAAAAdAAAABEAAAB8AAAAFwAA AIQAAAALAAAAjAAAABAAAACUAAAAEwAAAJwAAAAWAAAApAAAAAIAAACoAwAAHgAAAAQAAAAAAAAA AwAAAHgAAAADAAAAIQAAAAMAAAAwQgAAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAA ABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4 AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAP7///9BAAAAQgAAAEMAAABEAAAARQAAAEYA AABHAAAA/v///0kAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAA AFUAAABWAAAAVwAAAFgAAABZAAAA/v///1sAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAAD+//// YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAP7////9////bAAAAP7////+/////v////////// //////////////////////////////////////////////////////////////////////////// ////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA IMV0cBJKzQFuAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAB8jAAAAAAAAVwBvAHIAZABE AG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOH4A AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFoAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAD+//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARiMAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQg OTctMjAwMyDOxLW1AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA= --=_mixed 0035D43548257A1D_=-- From Alexander.Vainshtein@ecitele.com Thu Jun 14 08:23:30 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8A21F8705 for ; Thu, 14 Jun 2012 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pWdXBByGWsR for ; Thu, 14 Jun 2012 08:23:24 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA4021F86F4 for ; Thu, 14 Jun 2012 08:23:20 -0700 (PDT) Received: from [193.109.254.147:26313] by server-2.bemta-14.messagelabs.com id 74/F5-27740-3E10ADF4; Thu, 14 Jun 2012 15:23:15 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1339687394!7354736!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 25502 invoked from network); 14 Jun 2012 15:23:14 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-5.tower-27.messagelabs.com with SMTP; 14 Jun 2012 15:23:14 -0000 X-AuditID: a8571402-b7fb26d000001b21-60-4fd9fe477d7b Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 76.67.06945.74EF9DF4; Thu, 14 Jun 2012 17:07:51 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.141]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Thu, 14 Jun 2012 17:23:14 +0200 From: Alexander Vainshtein To: Lizhong Jin Thread-Topic: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Thread-Index: Ac1H2kX1gC60l/TZR4iLrX+73/oeQgCJ7UKAAA9kDFA= Date: Thu, 14 Jun 2012 15:23:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020831C9FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTf0gTYRjHe+/O7TTPrmnzdYSNo9+mzX6uaFLqzIG21aLAIL22t+1ou63d Ci2KkVHk+kMJBGeQhpmWFUlQloUZRUW5RKFpP4h+sNKsyH7YH0l3XZoQ3V/f93k+7/N93vd9 jsRVtUoNyfF+5ONZF6OII+LAJE362tE+sy7ardY3hk8D/e2KUaCPHq8h9HUtb5SrifyGhh9Y /peeYUV+y40RwoIXBcAqluc9ftaPtHYk2AyMxcftZm1ljJazG5hMRut1sTbkRrzfwLBeL+Lt TFac9p9vlYhxvBbxNo+d4x0GxmQ1p+v1S1ekZzJZG52coEXpbpZzad1IEFgH0ooRqXneXnIe d1aGq4D320tQeiBYrQiAaAeoACQJ6SWw65KxAsSKUg0fPb+gqABxpIruBfDp+8OEvDgFYPXZ EUKiFLQBtp59ppB0Ej0X9gy8UUoQTocBfBvs/51IpHPgjcYqQoZy4dDPckzWK2FtoF0hORP0 LBhsS5TCFF0Ie+rv/DGrBvBJT5tSYmJpK6weiZUYIHb3/X7L7zI4nQz7X5/A5K5p2NAexmU9 Db57NRoj61R4oLlXKfMeePFhJZC9psJ7Na8JmUmBN5siRCVQhyaUDU3YEpqwRY4vgHXXPitk nQYb6wfxMf2g4xU2MV4HlGcAzNtgyi2wWKzZOt2iDGOOaaOxwJiRYy5sBeI8NW1Owq6A8r7M TkCTgImnyI6IWRXD7hbK3J0ghcSYadTXSf1mVcI2j73MyQrOYt8uFxI6ASRxJomyjPSZVZSd LduDfJ6xlFG82ypcM9nmkR7fX7xYp/v/gkmmtm7IMqtohzieOxDyIt9YnekkyUDqs2Q/1Ycc qHQ75/L/TWNkrNRGvNiGGogMJXhZt8A55Px9kEa2B29HAHn18t0IUBG8h0eaZEopobSEOnfx 49UGQLJ4/ETqhWQWLw7teJ0B0QITLeY9jEgW4k80ntIEwLqb77tPWwPHjhbnh056vQl792df nPNxaHNbYk3RkUOp3Mtzy8Km4cefnu9cE7i65dbOt8Pdg0MfLpROORjSu7YUDFqjwQF3S7tp VnNjrjshJ3XmuoXbipT76Iwi4/eme+TsTSrDzBLdT0dJtK/rx9a8wpq8wvV52HX38rSO1hnq r80MITjZzPm4T2B/AY+nmkMuBAAA Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:23:31 -0000 --_000_F9336571731ADE42A5397FC831CEAA020831C9FRIDWPPMB001ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Lizhong hi, Lots of thanks for a prompt response. Please see some answers inline below (brown italics). I will read the new version and provide additional comments later, hope this= is OK. Regards, Sasha From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, June 14, 2012 12:48 PM To: Alexander Vainshtein Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tools.ietf.= org; rtg-dir@ietf.org Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Hi Sasha, Thank you very much for the valuable comments. Please see my reply inline be= low. I also attached the modified version for your check and reference. Regards Lizhong Alexander Vainshtein > wrote 2012/06/14 13:23:59: > Hello, > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, please se= e > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-pwe3-cbit-negotiation-03.txt > Reviewer: Alexander ("Sasha") Vainshtein > Review Date: 13.06.12 > IETF LC End date: 15.06.12 > Intended Status: Standards Track > > > SUMMARY: > > I think that the document is generally in good shape and almost > ready for publication. > However, I have some minor technical concerns as well as some > editorial ones which, IMHO, should be resolved before publication. > > MAJOR ISSUES: None > > MINOR ISSUES: > > Technical: > > The actual C-bit negotiation protocol (extension of what has been > defined in RFC 4447) is presented in the document 3 (three) times: > > - In Section 3, items i) to iii) and the paragraph immediately > following these items. This text uses the IETF capitalized > requirement level terms (MUST) and hence looks like the normative > definition of the protocol > > - In the same Section, items 1 to 5. This text refers to an (IMHO > not very informative) Figure 1 but does not contain the IETF > capitalized requirement level terms. > > - In Appendix A. This Appendix contains a block diagram of the C- > bit negotiation procedure that follows/illustrates the text in items > 1) - 7) of Section 3. > > The difference between the presumably normative definition and two > others is that the first one explicitly states: "Local PE MUST send > a label withdraw message to remote PE if it has previously sent a > label mapping, and wait until receiving a label release from the remote PE= ". > (Note: "Local PE" in the document is the PE that has changed > configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.) > > The two other fragments do not mention waiting for the label > release message from the remote PE, i.e. are not fully consistent > with the normative one. > > My interpretation of the LDP procedures as per RFC 5036 is that an > LSR that sends a label withdraw message MUST wait for the > acknowledging label release message from the peer, i.e. the > presumed normative definition is correct. And in any case I think > that all the all the descriptions of the protocol (texts, block > diagrams etc.) must be fully consistent. [Lizhong] agree, and we will change the second and third text fragment to re= flect this. [[[Sasha]]] OK. > > I also suggest to clarify whether sending the label release message > by the local PE above should wait for the label release message from > the remote PE if label withdraw message has been sent. I expect > that, upon receiving the label withdraw message from the local PE, > the remote one, in addition to acknowledging it with a label release > message would also immediately send its own label withdraw message > to the local PE which would then, in its turn, send label release > message back. [Lizhong] the remote one will not send label withdraw after acknowledging wi= th label release, because "liberal label retention" mode is applied. The sending label release message by local PE is not necessary to wait for t= he release from remote. Will clarify this in the draft. [[[Sasha]]] I am not sure liberal label retention really applies here - IMHO= it just says that unused label advertisements received by an NE are retaine= d. And it seems that RFC 447 is not very clear on procedures for tearing dow= n a PW. But as long as you clarify this point, it is not really important fo= r this draft. > > Editorial: > > 1. With regard to multi-segment PWs, the draft says that "the > (label) request message MUST be processed in ordered mode". It is > not clear to me whether this refers to ordered label distribution > mode of LDP as defined in RFC 5036, or to something else. At the > same time, the procedure defined in the draft is compliant with the > common PW label distribution procedures as defined in RFC 6073, so I > suggest to consider referencing RFC 6073 (there is no such reference > in the draft) instead of using a potentially misleading term. I also > wonder if this draft should not be considered as updating RFC 6073 > in addition to updating RFC 4447. [Lizhong] yes, ordered mode follows ordered label distribution mode in RFC50= 36. And I agree, referencing RFC6073 would be more clear. And yes, the draft= is also updating RFC6073. [[[Sasha]]] I am not sure ordered label distribution in 5036 really applies= here, because my reading of 5036 suggests that it is used (or not used) per= LSR. I suspect that this may be the reason for the authors of 6073 not to= mention it but explicitly define the process instead. But, as I have said,= the procedure you've specified looks OK. > > 2. As mentioned above, there are two text fragments defining the > new C-bit negotiation procedure in the draft. I suggest to consider > merging them into a single text that consistently uses the IETF > capitalized terms for requirement levels while avoiding such vague > terms as "could" (e.g., " PE2 could wait for PE1 label binding > before sending its label binding with C-bit set"). Having a single > text fragment that defines the procedure would also reduce the > potential for inconsistencies. [Lizhong] the first text fragment defines the requirement, and the second gi= ves an usecase according to the first text. What if we move the use case to= another sub-section, so as to make it more clear? [[[Sasha]]] I wonder if the second fragment really adds much to the first on= e (which defines the procedure). But as long as (1) it is clearly specified= what is the normative specification and what is the use case, and (b) the u= se case is fully consistent with the normative specification, it is OK. > > 3. The text, as written, does not clearly distinguish between the > PW control word (as a field in the packet) and the PW control word > *use* in a PW instance. In most cases this is not a problem, since > the draft is all about the CW use. However, there are several cases > when this may result in misinterpretation, e.g. (the next two items > are copy and paste quotes from the draft): > > - When the peer PE successfully processed the label withdraw and > label release, and removed the remote label binding, it MUST reset > its local control word with the configured one... > > - When Local PE changes its control word from PREFERRED to NOT PREFERRED.= .. > > (Please note also that *preferred* PW control word is defined in RFC > 4385, but the meaning is completely different from one implied here). > > I suggest to consider clarifying that these (and possibly some > other) fragments refer to the PW CW usage and not to format or > content of the CW. There is clearly more than one way to do that. > IMHO and FWIW the most unambiguous one would be to define the > relevant state variables of the PW end points (configured, > transmitted and received C-bit) and to use them in the definition of > the procedure, but this is definitely for the authors to decide. [Lizhong] we will change the "control word" to "use of control word" in the= draft, and make it clear. [[[Sasha]]] Sounds OK. > > Nits: None found by the IETF draft checker. > > Regards, > Sasha > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to > ECI Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and > all copies thereof. > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020831C9FRIDWPPMB001ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Lizhong hi= ,

Lots of thanks for a prompt= response.

 

Please see some answers inl= ine below (brown italics).

 

I will read the new version= and provide additional comments later, hope this is OK.

 

Regards,<= /p>

     Sa= sha

 

From: Lizhong Jin= [mailto:lizhong.jin@zte.com.cn]
Sent: Thursday, June 14, 2012 12:48 PM
To: Alexander Vainshtein
Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tool= s.ietf.org; rtg-dir@ietf.org
Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

 


Hi Sasha,
Thank you very much for the valuable comments. Please see my reply= inline below.
I also attached the modified version for your check and reference.=

Regards
Lizhong

 

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&g= t; wrote 2012/06/14 13:23:59:

> Hello,
> I have been selected as the Routing Directorate reviewer for this <= /tt>
> draft. The Routing Directorate seeks to review all routing or =
> routing-related drafts as they pass through IETF last call and IESG=
> review. The purpose of the review is to provide assistance to the <= /tt>
> Routing ADs. For more information about the Routing Directorate, pl= ease see
> http:= //www.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any=
> other IETF Last Call comments that you receive, and strive to =
> resolve them through discussion or by updating the draft.
>
> Document:   draft-ietf-pwe3-cbit-negotiation-03.txt
> Reviewer:   Alexander ("Sasha") Vainshtein
> Review Date:   13.06.12
> IETF LC End date:  15.06.12
> Intended Status:  Standards Track
>
>
> SUMMARY:
>
> I think that the document is generally in good shape and almost
> ready for publication.
> However, I have some minor technical concerns as well as some =
> editorial ones which, IMHO, should be resolved before publication.<= /tt>
>
> MAJOR ISSUES:  None
>
> MINOR ISSUES:
>
> Technical:
>
>  The actual C-bit negotiation protocol (extension of what has= been
> defined in RFC 4447) is presented in the document 3 (three) times:<= /tt>
>
>  -  In Section 3, items i) to iii) and the paragraph imme= diately
> following these items. This text uses the IETF capitalized > requirement level terms (MUST) and hence looks like the normative <= /tt>
> definition of the protocol
>
>  -   In the same Section, items 1 to 5. This text refers= to an (IMHO
> not very informative) Figure 1 but does not contain the IETF <= br> > capitalized requirement level terms.
>
>  - In Appendix A. This Appendix contains a block diagram of th= e C-
> bit negotiation procedure that follows/illustrates the text in item= s
> 1) - 7) of Section 3.
>
>   The difference between the presumably normative definition a= nd two
> others is that the first one explicitly states:  "Local P= E MUST send
> a label withdraw message to remote PE if it has previously sent a <= /tt>
> label mapping, and wait until receiving a label release from the re= mote PE".  
>  (Note: "Local PE" in the document is the PE that ha= s changed
> configuration of CW usage (in this case, from NOT PREFERRED to PREF= ERRED.)
>
>  The two other fragments do not mention waiting for the label=
> release message from the remote PE, i.e. are not fully consistent <= /tt>
> with the normative one.
>
>  My interpretation of the LDP procedures as per RFC 5036 is th= at an
> LSR that sends a label withdraw message MUST wait for the
> acknowledging    label release message from the peer, i.e= . the
> presumed normative definition is correct. And in any case I think <= /tt>
> that all the all the descriptions of the protocol (texts, block
> diagrams etc.) must be fully consistent.
[Lizhong] agree, and we will change the= second and third text fragment to reflect this.

[[[Sasha]]] OK.



>
> I also suggest to clarify whether sending the label release message=
> by the local PE above should wait for the label release message fro= m
> the remote PE if label withdraw message has been sent.  I expe= ct
> that, upon receiving the label withdraw message from the local PE,=
> the remote one, in addition to acknowledging it with a label releas= e
> message would also immediately send its own label withdraw message=
> to the local PE which would then, in its turn, send label release <= /tt>
> message back.
[Lizhong] the remote one will not send= label withdraw after acknowledging with label release, because "libera= l label retention" mode is applied.

The sending labe= l release message by local PE is not necessary to wait for the release from= remote. Will clarify this in the draft.
[[[Sasha]]] I am not sure liberal l= abel retention really applies here – IMHO it just says that unused lab= el advertisements received by an NE are retained. And it seems that RFC 447 is not very clear on procedures for tearing down a PW. B= ut as long as you clarify this point, it is not really important for this dr= aft.


>
> Editorial:
>
>  1. With regard to multi-segment PWs, the draft says that &quo= t;the
> (label) request message MUST be processed in ordered mode". It= is
> not clear to me whether this refers to ordered label distribution <= /tt>
> mode of LDP as defined in RFC 5036, or to something else. At the
> same time, the procedure defined in the draft is compliant with the=
> common PW label distribution procedures as defined in RFC 6073, so= I
> suggest to consider referencing RFC 6073 (there is no such referenc= e
> in the draft) instead of using a potentially misleading term. I als= o
> wonder if this draft should not be considered as updating RFC 6073=
> in addition to updating RFC 4447.
[Lizhong] yes, ordered mode follows ord= ered label distribution mode in RFC5036. And I agree, referencing RFC6073 wo= uld be more clear. And yes, the draft is also updating RFC6073.

[[[Sasha]]] I am not sure ordered label dist= ribution in 5036 really applies here, because my reading of 5036 suggests th= at it is used (or not used) per LSR.  I suspect that this may be the reason for the authors of 6073 not to mention it but explic= itly define the process instead. But, as I have said, the procedure you̵= 7;ve specified looks OK.



>
>  2. As mentioned above, there are two text fragments defining= the
> new C-bit negotiation procedure in the draft. I suggest to consider=
> merging them into a single text that consistently uses the IETF
> capitalized terms for requirement levels while avoiding such vague=
> terms as "could"  (e.g., " PE2 could wait for P= E1 label  binding
> before sending its label binding with C-bit set"). Having a si= ngle
> text fragment that defines the procedure would also reduce the
> potential for inconsistencies.
[Lizhong] the first text fragment defin= es the requirement, and the second gives an usecase according to the first t= ext. What if we move the use case to another sub-section, so as to make it m= ore clear?

[[[Sasha]]] I wonder if the second fragment= really adds much to the first one (which defines the procedure). But as lon= g as (1) it is clearly specified what is the normative specification and what is the use case, and (b) the use case is fully consi= stent with the normative specification, it is OK.  



>
>  3. The text, as written, does not clearly distinguish between= the
> PW control word (as a field in the packet) and the PW control word=
> *use* in a PW instance. In most cases this is not a problem, since=
> the draft is all about the CW use. However, there are several cases=
> when this may result in misinterpretation, e.g. (the next two items=
> are copy and paste quotes from the draft):
>
>  -    When the peer PE successfully processed the la= bel withdraw and
> label release, and removed the remote label binding, it MUST reset=
> its local control word with the configured one...
>
>  - When Local PE changes its control word from PREFERRED to NO= T PREFERRED...
>
> (Please note also that *preferred* PW control word is defined in RF= C
> 4385, but the meaning is completely different from one implied here= ).
>
> I suggest to consider clarifying that these (and possibly some
> other) fragments refer to the PW CW usage and not to format or
> content of the CW. There is clearly more than one way to do that. <= /tt>
> IMHO and FWIW the most unambiguous one would be to define the =
> relevant state variables of the PW end points (configured, > transmitted and received C-bit) and to use them in the definition o= f
> the procedure, but this is definitely for the authors to decide.
[Lizhong] we will change the "cont= rol word" to "use of control word" in the draft, and make it= clear.

[[[Sasha]]] Sounds OK.=



>
> Nits:  None found by the IETF draft checker.
>  
> Regards,
>      Sasha
> This e-mail message is intended for the recipient only and contains=
> information which is CONFIDENTIAL and which may be proprietary to <= /tt>
> ECI Telecom. If you have received this transmission in error, pleas= e
> inform us by e-mail, phone or fax, and then delete the original and=
> all copies thereof.
>
>

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020831C9FRIDWPPMB001ecite_-- From Alexander.Vainshtein@ecitele.com Thu Jun 14 08:41:23 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2474F21F86FE for ; Thu, 14 Jun 2012 08:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcSk23UjQzsO for ; Thu, 14 Jun 2012 08:41:17 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 233C521F8704 for ; Thu, 14 Jun 2012 08:41:15 -0700 (PDT) Received: from [85.158.138.51:52527] by server-8.bemta-3.messagelabs.com id 0F/4E-06157-9160ADF4; Thu, 14 Jun 2012 15:41:13 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1339688472!19597324!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 25505 invoked from network); 14 Jun 2012 15:41:12 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-3.tower-174.messagelabs.com with SMTP; 14 Jun 2012 15:41:12 -0000 X-AuditID: a8571406-b7f656d0000010a7-ea-4fda0616652a Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id A6.0C.04263.6160ADF4; Thu, 14 Jun 2012 17:41:10 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.141]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 14 Jun 2012 17:41:11 +0200 From: Alexander Vainshtein To: Lizhong Jin Thread-Topic: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Thread-Index: Ac1H2kX1gC60l/TZR4iLrX+73/oeQgCJ7UKAAA9kDFAAALktkA== Date: Thu, 14 Jun 2012 15:41:11 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020831F7FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfUgTYRzuvTu3S704L83XFXFcBNZSJxYsaBZlYVBMTLIitHN7246229gt c/21LMLsSyuorEhBzS8mCtGXWln2IYmBWmv0BWUfq6DvNOjjbpcmRPfX8/6e5/c8v/fudyTO VGp1pCB6kUfkHZwmmogGk3Qp0zQhs6G8P81Y338GGHvKfwLjy5PHCWN1y7B2CZFdWzuKZX8e +KTJbukaIXLwDX6wiBdFl5f3ItaKJIuJy/EIxbzFx7GC1cSlc6zbwVuQE4leE8e73Ui0cpnR 7D/PIlkmiCwSLS6rINpM3Mo15hSjccHClHQuM88uSCxKcfKCg3UiSeJtiJUryvCidVMAt99v uIm7L5/FShrK2oAfdO7BysFkEtLzYVvzbq2Kp8G7j1s15SCaZOhBAN+2+zH1UAfgvc5ApEND m2B78yONguPpZDgQHtYqIpzuB/DV3lCEmEovg131lYQqyoLvfuzEVLwUvrzxKlIn6Nnw8tmD MiZJil4NWw+vV8OOArjjyaWID5BH+tbbEunF6UQYen76z9g0rO3ox1WcAF8/+xml4pmwtHFQ q+pdcN/7+gim6Dh4+/hzQtUkwasNQaICJFRNsK2a0FI1oUWtz4PVlz5qVKyH9TVv8DF858oz bGK9GmibANzsEawOd7FUZDAsSEUWwYscKNXicrYDeYsa8uM154G/IrUb0CTgYqnz14NmJoov lnzObpBEYlwCFYeHzMyUIpfVZ+cle6FnqwNJ3QCSOBdP5Yw8MDOUlfdtRx7XGLVcfqGVuC7G 4lI+ubcww2D4/4FLpFpzM80MbZOXcgtCbuQZ85lBkhykbFFyfJwH2VDJZsHh/Utj5GRljFh5 jAOKhpLcvFMSbCrfC/Rkx96eICAvnrsVBAwhukSkS6T8ipRWpPat4rhbGCTK159KVShsrLyq 4z5hOQKTI+b0BZUI+dcZp3R+cIw5iG6dupIfyN9fM5qVlpoR15sFtoT7vn/I7X66+MLSXXot VTzUO4sQBg59TdonbewxLD/Jxpww2E49yijLCwYsxjMPS5Mz5/iGCzYdGUoomv5l7Yi+jrn2 YsWOdXpnYWneg5JtZe8DZbPRr1WlTaHGgfCPbT0FMRmjRwNi84FhjpDsfPpc3CPxvwFgY0Lu JAQAAA== Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:41:23 -0000 --_000_F9336571731ADE42A5397FC831CEAA020831F7FRIDWPPMB001ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Lizhong, hi again! I have read the updated draft, and it looks OK. There just an additional min= or comment on the text that deals with to MS-PWs. The draft says "When S-PE receives a label request message from a remote PE,= it MUST advertise the request message to the other remote PE." The intentio= n is clear, but I suggest to consider changing it to something like "When an= S-PE receives a label request message from one of its adjacent PEs (be it S= -PE or another T-PE), it MUST send a matching label request message it is ot= her adjacent PE (again, it may be an S-PE or a T-PE)". This modification, if= it suits you, would serve two purposes: - It would clarify that an S-PE relays Label Request messages from= one of its neighbors to the other one, and does not care (indeed, it does n= ot usually know) whether these neighbors are T-PEs or S-PEs - It avoids the term "advertise" which, IMHO, does not apply to wha= t label request messages do. Regards, Sasha From: Alexander Vainshtein Sent: Thursday, June 14, 2012 6:23 PM To: 'Lizhong Jin' Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tools.ietf.= org; rtg-dir@ietf.org Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Lizhong hi, Lots of thanks for a prompt response. Please see some answers inline below (brown italics). I will read the new version and provide additional comments later, hope this= is OK. Regards, Sasha From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, June 14, 2012 12:48 PM To: Alexander Vainshtein Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tools.ietf.= org; rtg-dir@ietf.org Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Hi Sasha, Thank you very much for the valuable comments. Please see my reply inline be= low. I also attached the modified version for your check and reference. Regards Lizhong Alexander Vainshtein > wrote 2012/06/14 13:23:59: > Hello, > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, please se= e > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-pwe3-cbit-negotiation-03.txt > Reviewer: Alexander ("Sasha") Vainshtein > Review Date: 13.06.12 > IETF LC End date: 15.06.12 > Intended Status: Standards Track > > > SUMMARY: > > I think that the document is generally in good shape and almost > ready for publication. > However, I have some minor technical concerns as well as some > editorial ones which, IMHO, should be resolved before publication. > > MAJOR ISSUES: None > > MINOR ISSUES: > > Technical: > > The actual C-bit negotiation protocol (extension of what has been > defined in RFC 4447) is presented in the document 3 (three) times: > > - In Section 3, items i) to iii) and the paragraph immediately > following these items. This text uses the IETF capitalized > requirement level terms (MUST) and hence looks like the normative > definition of the protocol > > - In the same Section, items 1 to 5. This text refers to an (IMHO > not very informative) Figure 1 but does not contain the IETF > capitalized requirement level terms. > > - In Appendix A. This Appendix contains a block diagram of the C- > bit negotiation procedure that follows/illustrates the text in items > 1) - 7) of Section 3. > > The difference between the presumably normative definition and two > others is that the first one explicitly states: "Local PE MUST send > a label withdraw message to remote PE if it has previously sent a > label mapping, and wait until receiving a label release from the remote PE= ". > (Note: "Local PE" in the document is the PE that has changed > configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.) > > The two other fragments do not mention waiting for the label > release message from the remote PE, i.e. are not fully consistent > with the normative one. > > My interpretation of the LDP procedures as per RFC 5036 is that an > LSR that sends a label withdraw message MUST wait for the > acknowledging label release message from the peer, i.e. the > presumed normative definition is correct. And in any case I think > that all the all the descriptions of the protocol (texts, block > diagrams etc.) must be fully consistent. [Lizhong] agree, and we will change the second and third text fragment to re= flect this. [[[Sasha]]] OK. > > I also suggest to clarify whether sending the label release message > by the local PE above should wait for the label release message from > the remote PE if label withdraw message has been sent. I expect > that, upon receiving the label withdraw message from the local PE, > the remote one, in addition to acknowledging it with a label release > message would also immediately send its own label withdraw message > to the local PE which would then, in its turn, send label release > message back. [Lizhong] the remote one will not send label withdraw after acknowledging wi= th label release, because "liberal label retention" mode is applied. The sending label release message by local PE is not necessary to wait for t= he release from remote. Will clarify this in the draft. [[[Sasha]]] I am not sure liberal label retention really applies here - IMHO= it just says that unused label advertisements received by an NE are retaine= d. And it seems that RFC 447 is not very clear on procedures for tearing dow= n a PW. But as long as you clarify this point, it is not really important fo= r this draft. > > Editorial: > > 1. With regard to multi-segment PWs, the draft says that "the > (label) request message MUST be processed in ordered mode". It is > not clear to me whether this refers to ordered label distribution > mode of LDP as defined in RFC 5036, or to something else. At the > same time, the procedure defined in the draft is compliant with the > common PW label distribution procedures as defined in RFC 6073, so I > suggest to consider referencing RFC 6073 (there is no such reference > in the draft) instead of using a potentially misleading term. I also > wonder if this draft should not be considered as updating RFC 6073 > in addition to updating RFC 4447. [Lizhong] yes, ordered mode follows ordered label distribution mode in RFC50= 36. And I agree, referencing RFC6073 would be more clear. And yes, the draft= is also updating RFC6073. [[[Sasha]]] I am not sure ordered label distribution in 5036 really applies= here, because my reading of 5036 suggests that it is used (or not used) per= LSR. I suspect that this may be the reason for the authors of 6073 not to= mention it but explicitly define the process instead. But, as I have said,= the procedure you've specified looks OK. > > 2. As mentioned above, there are two text fragments defining the > new C-bit negotiation procedure in the draft. I suggest to consider > merging them into a single text that consistently uses the IETF > capitalized terms for requirement levels while avoiding such vague > terms as "could" (e.g., " PE2 could wait for PE1 label binding > before sending its label binding with C-bit set"). Having a single > text fragment that defines the procedure would also reduce the > potential for inconsistencies. [Lizhong] the first text fragment defines the requirement, and the second gi= ves an usecase according to the first text. What if we move the use case to= another sub-section, so as to make it more clear? [[[Sasha]]] I wonder if the second fragment really adds much to the first on= e (which defines the procedure). But as long as (1) it is clearly specified= what is the normative specification and what is the use case, and (b) the u= se case is fully consistent with the normative specification, it is OK. > > 3. The text, as written, does not clearly distinguish between the > PW control word (as a field in the packet) and the PW control word > *use* in a PW instance. In most cases this is not a problem, since > the draft is all about the CW use. However, there are several cases > when this may result in misinterpretation, e.g. (the next two items > are copy and paste quotes from the draft): > > - When the peer PE successfully processed the label withdraw and > label release, and removed the remote label binding, it MUST reset > its local control word with the configured one... > > - When Local PE changes its control word from PREFERRED to NOT PREFERRED.= .. > > (Please note also that *preferred* PW control word is defined in RFC > 4385, but the meaning is completely different from one implied here). > > I suggest to consider clarifying that these (and possibly some > other) fragments refer to the PW CW usage and not to format or > content of the CW. There is clearly more than one way to do that. > IMHO and FWIW the most unambiguous one would be to define the > relevant state variables of the PW end points (configured, > transmitted and received C-bit) and to use them in the definition of > the procedure, but this is definitely for the authors to decide. [Lizhong] we will change the "control word" to "use of control word" in the= draft, and make it clear. [[[Sasha]]] Sounds OK. > > Nits: None found by the IETF draft checker. > > Regards, > Sasha > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to > ECI Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and > all copies thereof. > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020831F7FRIDWPPMB001ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Lizhong, hi again!

 

I have read the updated dra= ft, and it looks OK. There just an additional minor comment on the text that= deals with  to MS-PWs.

 

The draft says “When S-PE receives a label request message from a remote PE, it MUST advertise the request message to the other remote PE.” Th= e intention is clear, but I suggest to consider changing it to something lik= e “When an S-PE receives a label request message from one of its adjacent PEs (be it S-PE or another T-PE), it MUST send a matching l= abel request message it is other adjacent PE (again, it may be an S-PE or a= T-PE)”. This modification, if it suits you, would serve two purposes:=

-   = ;       It would clarify that an S-PE relays Label Request messages from one o= f its neighbors to the other one, and does not care (indeed, it does not usually know) whether these neighbors are T-PEs or S-PEs

-   = ;       It avoids the term “advertise” which, IMHO, does not apply= to what label request messages do.

 

Regards,<= /p>

     Sa= sha

 

From: Alexander V= ainshtein
Sent: Thursday, June 14, 2012 6:23 PM
To: 'Lizhong Jin'
Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tool= s.ietf.org; rtg-dir@ietf.org
Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

 

Lizhong hi= ,

Lots of thanks for a prompt= response.

 

Please see some answers inl= ine below (brown italics).

 

I will read the new version= and provide additional comments later, hope this is OK.

 

Regards,<= /p>

     Sa= sha

 

From: Lizhong Jin= [mailto:lizhong.jin@zte.com.cn]
Sent: Thursday, June 14, 2012 12:48 PM
To: Alexander Vainshtein
Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tool= s.ietf.org; rtg-dir@ietf.org
Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

 


Hi Sasha,
Thank you very much for the valuable comments. Please see my reply= inline below.
I also attached the modified version for your check and reference.=

Regards
Lizhong

 

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&g= t; wrote 2012/06/14 13:23:59:

> Hello,
> I have been selected as the Routing Directorate reviewer for this <= /tt>
> draft. The Routing Directorate seeks to review all routing or =
> routing-related drafts as they pass through IETF last call and IESG=
> review. The purpose of the review is to provide assistance to the <= /tt>
> Routing ADs. For more information about the Routing Directorate, pl= ease see
> http:= //www.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any=
> other IETF Last Call comments that you receive, and strive to =
> resolve them through discussion or by updating the draft.
>
> Document:   draft-ietf-pwe3-cbit-negotiation-03.txt
> Reviewer:   Alexander ("Sasha") Vainshtein
> Review Date:   13.06.12
> IETF LC End date:  15.06.12
> Intended Status:  Standards Track
>
>
> SUMMARY:
>
> I think that the document is generally in good shape and almost
> ready for publication.
> However, I have some minor technical concerns as well as some =
> editorial ones which, IMHO, should be resolved before publication.<= /tt>
>
> MAJOR ISSUES:  None
>
> MINOR ISSUES:
>
> Technical:
>
>  The actual C-bit negotiation protocol (extension of what has= been
> defined in RFC 4447) is presented in the document 3 (three) times:<= /tt>
>
>  -  In Section 3, items i) to iii) and the paragraph imme= diately
> following these items. This text uses the IETF capitalized > requirement level terms (MUST) and hence looks like the normative <= /tt>
> definition of the protocol
>
>  -   In the same Section, items 1 to 5. This text refers= to an (IMHO
> not very informative) Figure 1 but does not contain the IETF <= br> > capitalized requirement level terms.
>
>  - In Appendix A. This Appendix contains a block diagram of th= e C-
> bit negotiation procedure that follows/illustrates the text in item= s
> 1) - 7) of Section 3.
>
>   The difference between the presumably normative definition a= nd two
> others is that the first one explicitly states:  "Local P= E MUST send
> a label withdraw message to remote PE if it has previously sent a <= /tt>
> label mapping, and wait until receiving a label release from the re= mote PE".  
>  (Note: "Local PE" in the document is the PE that ha= s changed
> configuration of CW usage (in this case, from NOT PREFERRED to PREF= ERRED.)
>
>  The two other fragments do not mention waiting for the label=
> release message from the remote PE, i.e. are not fully consistent <= /tt>
> with the normative one.
>
>  My interpretation of the LDP procedures as per RFC 5036 is th= at an
> LSR that sends a label withdraw message MUST wait for the
> acknowledging    label release message from the peer, i.e= . the
> presumed normative definition is correct. And in any case I think <= /tt>
> that all the all the descriptions of the protocol (texts, block
> diagrams etc.) must be fully consistent.
[Lizhong] agree, and we will change the= second and third text fragment to reflect this.

[[[Sasha]]] OK.



>
> I also suggest to clarify whether sending the label release message=
> by the local PE above should wait for the label release message fro= m
> the remote PE if label withdraw message has been sent.  I expe= ct
> that, upon receiving the label withdraw message from the local PE,=
> the remote one, in addition to acknowledging it with a label releas= e
> message would also immediately send its own label withdraw message=
> to the local PE which would then, in its turn, send label release <= /tt>
> message back.
[Lizhong] the remote one will not send= label withdraw after acknowledging with label release, because "libera= l label retention" mode is applied.

The sending labe= l release message by local PE is not necessary to wait for the release from= remote. Will clarify this in the draft.
[[[Sasha]]] I am not sure liberal l= abel retention really applies here – IMHO it just says that unused lab= el advertisements received by an NE are retained. And it seems that RFC 447 is not very clear on procedures for tearing down a PW. B= ut as long as you clarify this point, it is not really important for this dr= aft.


>
> Editorial:
>
>  1. With regard to multi-segment PWs, the draft says that &quo= t;the
> (label) request message MUST be processed in ordered mode". It= is
> not clear to me whether this refers to ordered label distribution <= /tt>
> mode of LDP as defined in RFC 5036, or to something else. At the
> same time, the procedure defined in the draft is compliant with the=
> common PW label distribution procedures as defined in RFC 6073, so= I
> suggest to consider referencing RFC 6073 (there is no such referenc= e
> in the draft) instead of using a potentially misleading term. I als= o
> wonder if this draft should not be considered as updating RFC 6073=
> in addition to updating RFC 4447.
[Lizhong] yes, ordered mode follows ord= ered label distribution mode in RFC5036. And I agree, referencing RFC6073 wo= uld be more clear. And yes, the draft is also updating RFC6073.

[[[Sasha]]] I am not sure ordered label dist= ribution in 5036 really applies here, because my reading of 5036 suggests th= at it is used (or not used) per LSR.  I suspect that this may be the reason for the authors of 6073 not to mention it but explic= itly define the process instead. But, as I have said, the procedure you̵= 7;ve specified looks OK.



>
>  2. As mentioned above, there are two text fragments defining= the
> new C-bit negotiation procedure in the draft. I suggest to consider=
> merging them into a single text that consistently uses the IETF
> capitalized terms for requirement levels while avoiding such vague=
> terms as "could"  (e.g., " PE2 could wait for P= E1 label  binding
> before sending its label binding with C-bit set"). Having a si= ngle
> text fragment that defines the procedure would also reduce the
> potential for inconsistencies.
[Lizhong] the first text fragment defin= es the requirement, and the second gives an usecase according to the first t= ext. What if we move the use case to another sub-section, so as to make it m= ore clear?

[[[Sasha]]] I wonder if the second fragment= really adds much to the first one (which defines the procedure). But as lon= g as (1) it is clearly specified what is the normative specification and what is the use case, and (b) the use case is fully consi= stent with the normative specification, it is OK.  



>
>  3. The text, as written, does not clearly distinguish between= the
> PW control word (as a field in the packet) and the PW control word=
> *use* in a PW instance. In most cases this is not a problem, since=
> the draft is all about the CW use. However, there are several cases=
> when this may result in misinterpretation, e.g. (the next two items=
> are copy and paste quotes from the draft):
>
>  -    When the peer PE successfully processed the la= bel withdraw and
> label release, and removed the remote label binding, it MUST reset=
> its local control word with the configured one...
>
>  - When Local PE changes its control word from PREFERRED to NO= T PREFERRED...
>
> (Please note also that *preferred* PW control word is defined in RF= C
> 4385, but the meaning is completely different from one implied here= ).
>
> I suggest to consider clarifying that these (and possibly some
> other) fragments refer to the PW CW usage and not to format or
> content of the CW. There is clearly more than one way to do that. <= /tt>
> IMHO and FWIW the most unambiguous one would be to define the =
> relevant state variables of the PW end points (configured, > transmitted and received C-bit) and to use them in the definition o= f
> the procedure, but this is definitely for the authors to decide.
[Lizhong] we will change the "cont= rol word" to "use of control word" in the draft, and make it= clear.

[[[Sasha]]] Sounds OK.=



>
> Nits:  None found by the IETF draft checker.
>  
> Regards,
>      Sasha
> This e-mail message is intended for the recipient only and contains=
> information which is CONFIDENTIAL and which may be proprietary to <= /tt>
> ECI Telecom. If you have received this transmission in error, pleas= e
> inform us by e-mail, phone or fax, and then delete the original and=
> all copies thereof.
>
>

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA020831F7FRIDWPPMB001ecite_-- From Alexander.Vainshtein@ecitele.com Thu Jun 14 12:16:45 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F78A21F877F for ; Thu, 14 Jun 2012 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q473iidDh3Zl for ; Thu, 14 Jun 2012 12:16:43 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2D421F877E for ; Thu, 14 Jun 2012 12:16:42 -0700 (PDT) Received: from [85.158.139.83:57174] by server-11.bemta-5.messagelabs.com id 88/B5-20400-7983ADF4; Thu, 14 Jun 2012 19:16:39 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1339701397!16481403!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 26331 invoked from network); 14 Jun 2012 19:16:38 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-8.tower-182.messagelabs.com with SMTP; 14 Jun 2012 19:16:38 -0000 X-AuditID: a8571403-b7f1c6d000001c72-70-4fda3889ba53 Received: from FRIDWPPCH001.ecitele.com (fridwppch001.ecitele.com [10.1.16.52]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id 11.DA.07282.9883ADF4; Thu, 14 Jun 2012 21:16:25 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.141]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 14 Jun 2012 21:16:36 +0200 From: Alexander Vainshtein To: Lizhong Jin Thread-Topic: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Thread-Index: Ac1H2kX1gC60l/TZR4iLrX+73/oeQgCJ7UKAAA9kDFAAALktkAAHxU39 Date: Thu, 14 Jun 2012 19:16:36 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02083285FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTaUwTQRR2utt2QdYslcLQeDQLxoOAJV7VUOIdNEEMGM8furRju7HdNt1C xB+mUYNaNMoPTSAqmCACogiJQhQvDBFRLiGEVEUNoFJiPIrxiKKzLCKJcX59875vvvfezBuK 0JxR6yhe8CC3wNlZVSgZCibp4o8a/WmGj191xtK2i8DY6BsBxjdnCkhjceWAejmZUlLyTZEy 3BlUpVTe/kpuJLZ7QRInCE4P50F6CxLNJnajm8/mzDmsnreY2ERW77JzZuRAgsfEci4XEixs cqj+n5WEZbygR4LZaeEFq4ldl5EWbzQuWhqfyCZvsvGiHsU7ON6udyBR5KxIjyNS8YJl1xXC VvQ9xnWrRLH3fku5wgsefQY+EEJBZiHsbDlHyjgStvdWqXwglNIwXQAOPRhRypsLAPafequU VCrGBGsuPVdJOIKZAzsDA2pJRDBtAL7N848SU5lV8HZpPimLVsN3Pw8qZLwWdtReH9WQzCz4 sqsdayiKZlJh/o+1crKnAFYfy1VLmhBmA/R96yMkDHB5X5orR30IJgr6+4sUctkMLKlvI2Ss hYN9I0oZz4QdH16O6Z3w2vXAaMs0Ew4fFvSPtRwN75X1kCdBZOEE28IJRwonHJHjBvi+tYiQ cRwsPT80hufD6uEWMDFeDNQVAO528xa7K1vMNBgWJCAz70F2lGB2OmoAHqiyLRFEHRg+kdAA GAqwYXS70p+mUXLZYo6jAURTClZLvzLg0JRMpyXHxom2ne4sOxIbAKQINoIun4E52sLl7ENu 5x9qDb7cfEI32eyUXt+zc4HB8P8NG0VXpSenaRgrns89CLmQ+4/PNIpiIf1xCU4R7kZWtHc3 b/f8pRVUiFRGGC6jW9LQootziLxV5ptBHFWf19gDqBu1TT1AQwpOAemiaBX+PRpGktqyhHG3 AIjC7U+l/ZJRGJ7acZ8ATqHAKea29Egp8C8ap3ResPlOem9Gfe/hun2LY7zo2bKtuoJFJ+8G VWf3n7q8fqA1kPupcdKRFx2EdvrCDOQL1lkTX9/8VJH0I/rdSrG6MdUYd/PApfpg1zbVwUex tuWztQeuBg9lpn7eEbN5CKJVneWD3hWxhaT2V7Oydvjx8XP96PSSu6V9ZU19qU1Z3YORT1hS tHGJ8wi3yP0GVTsQ6y8EAAA= Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 19:16:45 -0000 --_000_F9336571731ADE42A5397FC831CEAA02083285FRIDWPPMB001ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Lizhong hi (again), After re-reading 4447 I have come to conclusion that a Label Withdraw messag= e sent by one of the PEs to its peer would be responded with/acked by a Lab= el Release message, but it will not trigger a Label Withdraw message from th= e peer PE. This is based on the text that says that PW labels, once advertis= ed, are withdrawn in just three cases: 1. When the local PW endpoint is deleted from the PE configuration 2. When the local PW endpoint is administratively disabled by the user 3. When the local AC goes DOWN (only if the PW Status is not supported). Actually the draft adds one more case to this list. Regards, Sasha ________________________________ From: Alexander Vainshtein Sent: Thursday, June 14, 2012 5:41 PM To: Lizhong Jin Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tools.ietf.= org; rtg-dir@ietf.org Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Lizhong, hi again! I have read the updated draft, and it looks OK. There just an additional min= or comment on the text that deals with to MS-PWs. The draft says =93When S-PE receives a label request message from a remote P= E, it MUST advertise the request message to the other remote PE.=94 The inte= ntion is clear, but I suggest to consider changing it to something like =93W= hen an S-PE receives a label request message from one of its adjacent PEs (b= e it S-PE or another T-PE), it MUST send a matching label request message it= is other adjacent PE (again, it may be an S-PE or a T-PE)=94. This modifica= tion, if it suits you, would serve two purposes: - It would clarify that an S-PE relays Label Request messages from= one of its neighbors to the other one, and does not care (indeed, it does n= ot usually know) whether these neighbors are T-PEs or S-PEs - It avoids the term =93advertise=94 which, IMHO, does not apply to= what label request messages do. Regards, Sasha From: Alexander Vainshtein Sent: Thursday, June 14, 2012 6:23 PM To: 'Lizhong Jin' Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tools.ietf.= org; rtg-dir@ietf.org Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Lizhong hi, Lots of thanks for a prompt response. Please see some answers inline below (brown italics). I will read the new version and provide additional comments later, hope this= is OK. Regards, Sasha From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Thursday, June 14, 2012 12:48 PM To: Alexander Vainshtein Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tools.ietf.= org; rtg-dir@ietf.org Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt Hi Sasha, Thank you very much for the valuable comments. Please see my reply inline be= low. I also attached the modified version for your check and reference. Regards Lizhong Alexander Vainshtein > wrote 2012/06/14 13:23:59: > Hello, > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, please se= e > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-pwe3-cbit-negotiation-03.txt > Reviewer: Alexander ("Sasha") Vainshtein > Review Date: 13.06.12 > IETF LC End date: 15.06.12 > Intended Status: Standards Track > > > SUMMARY: > > I think that the document is generally in good shape and almost > ready for publication. > However, I have some minor technical concerns as well as some > editorial ones which, IMHO, should be resolved before publication. > > MAJOR ISSUES: None > > MINOR ISSUES: > > Technical: > > The actual C-bit negotiation protocol (extension of what has been > defined in RFC 4447) is presented in the document 3 (three) times: > > - In Section 3, items i) to iii) and the paragraph immediately > following these items. This text uses the IETF capitalized > requirement level terms (MUST) and hence looks like the normative > definition of the protocol > > - In the same Section, items 1 to 5. This text refers to an (IMHO > not very informative) Figure 1 but does not contain the IETF > capitalized requirement level terms. > > - In Appendix A. This Appendix contains a block diagram of the C- > bit negotiation procedure that follows/illustrates the text in items > 1) - 7) of Section 3. > > The difference between the presumably normative definition and two > others is that the first one explicitly states: "Local PE MUST send > a label withdraw message to remote PE if it has previously sent a > label mapping, and wait until receiving a label release from the remote PE= ". > (Note: "Local PE" in the document is the PE that has changed > configuration of CW usage (in this case, from NOT PREFERRED to PREFERRED.) > > The two other fragments do not mention waiting for the label > release message from the remote PE, i.e. are not fully consistent > with the normative one. > > My interpretation of the LDP procedures as per RFC 5036 is that an > LSR that sends a label withdraw message MUST wait for the > acknowledging label release message from the peer, i.e. the > presumed normative definition is correct. And in any case I think > that all the all the descriptions of the protocol (texts, block > diagrams etc.) must be fully consistent. [Lizhong] agree, and we will change the second and third text fragment to re= flect this. [[[Sasha]]] OK. > > I also suggest to clarify whether sending the label release message > by the local PE above should wait for the label release message from > the remote PE if label withdraw message has been sent. I expect > that, upon receiving the label withdraw message from the local PE, > the remote one, in addition to acknowledging it with a label release > message would also immediately send its own label withdraw message > to the local PE which would then, in its turn, send label release > message back. [Lizhong] the remote one will not send label withdraw after acknowledging wi= th label release, because "liberal label retention" mode is applied. The sending label release message by local PE is not necessary to wait for t= he release from remote. Will clarify this in the draft. [[[Sasha]]] I am not sure liberal label retention really applies here =96 IM= HO it just says that unused label advertisements received by an NE are retai= ned. And it seems that RFC 447 is not very clear on procedures for tearing d= own a PW. But as long as you clarify this point, it is not really important= for this draft. > > Editorial: > > 1. With regard to multi-segment PWs, the draft says that "the > (label) request message MUST be processed in ordered mode". It is > not clear to me whether this refers to ordered label distribution > mode of LDP as defined in RFC 5036, or to something else. At the > same time, the procedure defined in the draft is compliant with the > common PW label distribution procedures as defined in RFC 6073, so I > suggest to consider referencing RFC 6073 (there is no such reference > in the draft) instead of using a potentially misleading term. I also > wonder if this draft should not be considered as updating RFC 6073 > in addition to updating RFC 4447. [Lizhong] yes, ordered mode follows ordered label distribution mode in RFC50= 36. And I agree, referencing RFC6073 would be more clear. And yes, the draft= is also updating RFC6073. [[[Sasha]]] I am not sure ordered label distribution in 5036 really applies= here, because my reading of 5036 suggests that it is used (or not used) per= LSR. I suspect that this may be the reason for the authors of 6073 not to= mention it but explicitly define the process instead. But, as I have said,= the procedure you=92ve specified looks OK. > > 2. As mentioned above, there are two text fragments defining the > new C-bit negotiation procedure in the draft. I suggest to consider > merging them into a single text that consistently uses the IETF > capitalized terms for requirement levels while avoiding such vague > terms as "could" (e.g., " PE2 could wait for PE1 label binding > before sending its label binding with C-bit set"). Having a single > text fragment that defines the procedure would also reduce the > potential for inconsistencies. [Lizhong] the first text fragment defines the requirement, and the second gi= ves an usecase according to the first text. What if we move the use case to= another sub-section, so as to make it more clear? [[[Sasha]]] I wonder if the second fragment really adds much to the first on= e (which defines the procedure). But as long as (1) it is clearly specified= what is the normative specification and what is the use case, and (b) the u= se case is fully consistent with the normative specification, it is OK. > > 3. The text, as written, does not clearly distinguish between the > PW control word (as a field in the packet) and the PW control word > *use* in a PW instance. In most cases this is not a problem, since > the draft is all about the CW use. However, there are several cases > when this may result in misinterpretation, e.g. (the next two items > are copy and paste quotes from the draft): > > - When the peer PE successfully processed the label withdraw and > label release, and removed the remote label binding, it MUST reset > its local control word with the configured one... > > - When Local PE changes its control word from PREFERRED to NOT PREFERRED.= .. > > (Please note also that *preferred* PW control word is defined in RFC > 4385, but the meaning is completely different from one implied here). > > I suggest to consider clarifying that these (and possibly some > other) fragments refer to the PW CW usage and not to format or > content of the CW. There is clearly more than one way to do that. > IMHO and FWIW the most unambiguous one would be to define the > relevant state variables of the PW end points (configured, > transmitted and received C-bit) and to use them in the definition of > the procedure, but this is definitely for the authors to decide. [Lizhong] we will change the "control word" to "use of control word" in the= draft, and make it clear. [[[Sasha]]] Sounds OK. > > Nits: None found by the IETF draft checker. > > Regards, > Sasha > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to > ECI Telecom. If you have received this transmission in error, please > inform us by e-mail, phone or fax, and then delete the original and > all copies thereof. > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA02083285FRIDWPPMB001ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Lizhong hi (again),

After re-reading 4447 I have come to conclusion that a Label Withdraw mes= sage sent by one of the PEs to its peer would be responded with/= acked by  a Label Release message, but it will not trigge= r a Label Withdraw message from the peer PE. This is based on the text that says that PW labels, once advertise= d, are withdrawn in just three cases:

  1. When the local PW endpoint is deleted from the PE configuration
  2. When the  local PW endpoint is administratively disabled by= the user
  3. When the local AC goes DOWN (only if the PW Status is not= supported).

 

Actually the draft adds one more case to this list.

 

Regards,

     Sasha

From: Alexander Va= inshtein
Sent: Thursday, June 14, 2012 5:41 PM
To: Lizhong Jin
Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tool= s.ietf.org; rtg-dir@ietf.org
Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

Lizhong, hi again!

 

I have read the updated draft, and it looks= OK. There just an additional minor comment on the text that deals with &nbs= p;to MS-PWs.

 

The draft says =93When S-PE receiv= es a label request message from a remote PE, it MUST advertise= the request message to the other remote PE.=94 The intention is clear, but I suggest to consider changing= it to something like =93When an S-PE receives a label request message from= one of its adjacent PEs (be it S-PE or another T-PE), it MUST send a matching label request message it is other= adjacent PE (again, it may be an S-PE or a T-PE)=94. This modification, if= it suits you, would serve two purposes:

-   =        It would clarify that= an S-PE relays Label Request messages from one of its neighbors to the othe= r one, and does not care (indeed, it does not usually know) whether these neighbors are T-PEs or S-PEs=

-   =        It avoids the term = =93advertise=94 which, IMHO, does not apply to what label request messages d= o.

 

Regards,

     Sasha

 

From: Alexander Vainshtein
Sent: Thursday, June 14, 2012 6:23 PM
To: 'Lizhong Jin'
Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tool= s.ietf.org; rtg-dir@ietf.org
Subject: RE: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

 

Lizhong hi,

Lots of thanks for a prompt response.=

 

Please see some answers inline below (brown italics).

 

I will read the new version and provide addi= tional comments later, hope this is OK.

 

Regards,

     Sasha

 

From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Thursday, June 14, 2012 12:48 PM
To: Alexander Vainshtein
Cc: draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org; rtg-ads@tool= s.ietf.org; rtg-dir@ietf.org
Subject: Re: RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt

 


Hi Sasha,=
Thank you= very much for the valuable comments. Please see my reply inline below.
I also at= tached the modified version for your check and reference.

Regards
Lizhong

 

Alexander Vainshtein <Alexander.Vainshtein@= ecitele.com> wrote 2012/06/14 13:23:59:

> Hello,
> I have been selected as the Routing Directorate reviewer for this <= /tt>
> draft. The Routing Directorate seeks to review all routing or =
> routing-related drafts as they pass through IETF last call and IESG=
> review. The purpose of the review is to provide assistance to the <= /tt>
> Routing ADs. For more information about the Routing Directorate, pl= ease see
> http://www.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any=
> other IETF Last Call comments that you receive, and strive to =
> resolve them through discussion or by updating the draft.
>
> Document:   draft-ietf-pwe3-cbit-negotiation-03.txt
> Reviewer:   Alexander ("Sasha") Vainshtein
> Review Date:   13.06.12
> IETF LC End date:  15.06.12
> Intended Status:  Standards Track
>
>
> SUMMARY:
>
> I think that the document is generally in good shape and almost
> ready for publication.
> However, I have some minor technical concerns as well as some =
> editorial ones which, IMHO, should be resolved before publication.<= /tt>
>
> MAJOR ISSUES:  None
>
> MINOR ISSUES:
>
> Technical:
>
>  The actual C-bit negotiation protocol (extension of what has= been
> defined in RFC 4447) is presented in the document 3 (three) times:<= /tt>
>
>  -  In Section 3, items i) to iii) and the paragraph imme= diately
> following these items. This text uses the IETF capitalized > requirement level terms (MUST) and hence looks like the normative <= /tt>
> definition of the protocol
>
>  -   In the same Section, items 1 to 5. This text refers= to an (IMHO
> not very informative) Figure 1 but does not contain the IETF <= br> > capitalized requirement level terms.
>
>  - In Appendix A. This Appendix contains a block diagram of th= e C-
> bit negotiation procedure that follows/illustrates the text in item= s
> 1) - 7) of Section 3.
>
>   The difference between the presumably normative definition a= nd two
> others is that the first one explicitly states:  "Local P= E MUST send
> a label withdraw message to remote PE if it has previously sent a <= /tt>
> label mapping, and wait until receiving a label release from the re= mote PE".  
>  (Note: "Local PE" in the document is the PE that ha= s changed
> configuration of CW usage (in this case, from NOT PREFERRED to PREF= ERRED.)
>
>  The two other fragments do not mention waiting for the label=
> release message from the remote PE, i.e. are not fully consistent <= /tt>
> with the normative one.
>
>  My interpretation of the LDP procedures as per RFC 5036 is th= at an
> LSR that sends a label withdraw message MUST wait for the
> acknowledging    label release message from the peer, i.e= . the
> presumed normative definition is correct. And in any case I think <= /tt>
> that all the all the descriptions of the protocol (texts, block
> diagrams etc.) must be fully consistent.
[Lizhong] agree, and we will change the= second and third text fragment to reflect this.

[[[Sasha]]] OK.



>
> I also suggest to clarify whether sending the label release message=
> by the local PE above should wait for the label release message fro= m
> the remote PE if label withdraw message has been sent.  I expe= ct
> that, upon receiving the label withdraw message from the local PE,=
> the remote one, in addition to acknowledging it with a label releas= e
> message would also immediately send its own label withdraw message=
> to the local PE which would then, in its turn, send label release <= /tt>
> message back.
[Lizhong] the remote one will not send l= abel withdraw after acknowledging with label release, because "liberal= label retention" mode is applied.

The sending label= release message by local PE is not necessary to wait for the release from r= emote. Will clarify this in the draft.
[[[Sasha]]]
>
> Editorial:
>
>  1. With regard to multi-segment PWs, the draft says that &quo= t;the
> (label) request message MUST be processed in ordered mode". It= is
> not clear to me whether this refers to ordered label distribution <= /tt>
> mode of LDP as defined in RFC 5036, or to something else. At the
> same time, the procedure defined in the draft is compliant with the=
> common PW label distribution procedures as defined in RFC 6073, so= I
> suggest to consider referencing RFC 6073 (there is no such referenc= e
> in the draft) instead of using a potentially misleading term. I als= o
> wonder if this draft should not be considered as updating RFC 6073=
> in addition to updating RFC 4447.
[Lizhong] yes, ordered mode follows orde= red label distribution mode in RFC5036. And I agree, referencing RFC6073 wou= ld be more clear. And yes, the draft is also updating RFC6073.

[[[Sasha]]] I am not sure ordered label distribution in 5036= really applies here, because my reading of 5036 suggests that it is used (o= r not used) per LSR.  I suspect that this may be the reason for the authors of 6073 not to mention it but e= xplicitly define the process instead. But, as I have said, the procedure you= =92ve specified looks OK.



>
>  2. As mentioned above, there are two text fragments defining= the
> new C-bit negotiation procedure in the draft. I suggest to consider=
> merging them into a single text that consistently uses the IETF
> capitalized terms for requirement levels while avoiding such vague=
> terms as "could"  (e.g., " PE2 could wait for P= E1 label  binding
> before sending its label binding with C-bit set"). Having a si= ngle
> text fragment that defines the procedure would also reduce the
> potential for inconsistencies.
[Lizhong] the first text fragment define= s the requirement, and the second gives an usecase according to the first te= xt. What if we move the use case to another sub-section, so as to make it mo= re clear?

[[[Sasha]]] I wonder if the second fragment really adds much= to the first one (which defines the procedure). But as long as (1) it is cl= early specified what is the normative specification and what is the use case, and (b) the use case is fully consi= stent with the normative specification, it is OK.  



>
>  3. The text, as written, does not clearly distinguish between= the
> PW control word (as a field in the packet) and the PW control word=
> *use* in a PW instance. In most cases this is not a problem, since=
> the draft is all about the CW use. However, there are several cases=
> when this may result in misinterpretation, e.g. (the next two items=
> are copy and paste quotes from the draft):
>
>  -    When the peer PE successfully processed the la= bel withdraw and
> label release, and removed the remote label binding, it MUST reset=
> its local control word with the configured one...
>
>  - When Local PE changes its control word from PREFERRED to NO= T PREFERRED...
>
> (Please note also that *preferred* PW control word is defined in RF= C
> 4385, but the meaning is completely different from one implied here= ).
>
> I suggest to consider clarifying that these (and possibly some
> other) fragments refer to the PW CW usage and not to format or
> content of the CW. There is clearly more than one way to do that. <= /tt>
> IMHO and FWIW the most unambiguous one would be to define the =
> relevant state variables of the PW end points (configured, > transmitted and received C-bit) and to use them in the definition o= f
> the procedure, but this is definitely for the authors to decide.
[Lizhong] we will change the "contr= ol word" to "use of control word" in the draft, and make it c= lear.

[[[Sasha]]] Sounds OK.



>
> Nits:  None found by the IETF draft checker.
>  
> Regards,
>      Sasha
> This e-mail message is intended for the recipient only and contains=
> information which is CONFIDENTIAL and which may be proprietary to <= /tt>
> ECI Telecom. If you have received this transmission in error, pleas= e
> inform us by e-mail, phone or fax, and then delete the original and=
> all copies thereof.
>
>

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA02083285FRIDWPPMB001ecite_-- From lizhong.jin@zte.com.cn Thu Jun 14 20:42:22 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421AF11E80B6 for ; Thu, 14 Jun 2012 20:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.962 X-Spam-Level: X-Spam-Status: No, score=-100.962 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh7VFwhMigbn for ; Thu, 14 Jun 2012 20:42:20 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E33C421F84B4 for ; Thu, 14 Jun 2012 20:42:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620712910399; Fri, 15 Jun 2012 11:39:33 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 29378.3572189594; Fri, 15 Jun 2012 11:42:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q5F3gBao034493; Fri, 15 Jun 2012 11:42:11 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Alexander Vainshtein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Fri, 15 Jun 2012 11:41:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-15 11:42:12, Serialize complete at 2012-06-15 11:42:12 Content-Type: multipart/alternative; boundary="=_alternative 0014561548257A1E_=" X-MAIL: mse02.zte.com.cn q5F3gBao034493 X-Mailman-Approved-At: Fri, 15 Jun 2012 02:18:07 -0700 Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 03:42:22 -0000 This is a multipart message in MIME format. --=_alternative 0014561548257A1E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ IHdyb3RlIDIwMTIvMDYvMTQgDQoyMzo0MToxMToNCg0KPiBMaXpob25nLCBoaSBhZ2FpbiENCj4g DQo+IEkgaGF2ZSByZWFkIHRoZSB1cGRhdGVkIGRyYWZ0LCBhbmQgaXQgbG9va3MgT0suIFRoZXJl IGp1c3QgYW4gDQo+IGFkZGl0aW9uYWwgbWlub3IgY29tbWVudCBvbiB0aGUgdGV4dCB0aGF0IGRl YWxzIHdpdGggIHRvIE1TLVBXcy4NCj4gDQo+IFRoZSBkcmFmdCBzYXlzIKGwV2hlbiBTLVBFIHJl Y2VpdmVzIGEgbGFiZWwgcmVxdWVzdCBtZXNzYWdlIGZyb20gYSANCj4gcmVtb3RlIFBFLCBpdCBN VVNUIGFkdmVydGlzZSB0aGUgcmVxdWVzdCBtZXNzYWdlIHRvIHRoZSBvdGhlciByZW1vdGUgUEUu DQo+IKGxIFRoZSBpbnRlbnRpb24gaXMgY2xlYXIsIGJ1dCBJIHN1Z2dlc3QgdG8gY29uc2lkZXIg Y2hhbmdpbmcgaXQgdG8gDQo+IHNvbWV0aGluZyBsaWtlIKGwV2hlbiBhbiBTLVBFIHJlY2VpdmVz IGEgbGFiZWwgcmVxdWVzdCBtZXNzYWdlIGZyb20gDQo+IG9uZSBvZiBpdHMgYWRqYWNlbnQgUEVz IChiZSBpdCBTLVBFIG9yIGFub3RoZXIgVC1QRSksIGl0IE1VU1Qgc2VuZCBhDQo+IG1hdGNoaW5n IGxhYmVsIHJlcXVlc3QgbWVzc2FnZSBpdCBpcyBvdGhlciBhZGphY2VudCBQRSAoYWdhaW4sIGl0 IA0KPiBtYXkgYmUgYW4gUy1QRSBvciBhIFQtUEUpobEuIFRoaXMgbW9kaWZpY2F0aW9uLCBpZiBp dCBzdWl0cyB5b3UsIA0KPiB3b3VsZCBzZXJ2ZSB0d28gcHVycG9zZXM6DQo+IC0gICAgICAgICAg SXQgd291bGQgY2xhcmlmeSB0aGF0IGFuIFMtUEUgcmVsYXlzIExhYmVsIFJlcXVlc3QgDQo+IG1l c3NhZ2VzIGZyb20gb25lIG9mIGl0cyBuZWlnaGJvcnMgdG8gdGhlIG90aGVyIG9uZSwgYW5kIGRv ZXMgbm90IA0KPiBjYXJlIChpbmRlZWQsIGl0IGRvZXMgbm90IHVzdWFsbHkga25vdykgd2hldGhl ciB0aGVzZSBuZWlnaGJvcnMgYXJlIA0KPiBULVBFcyBvciBTLVBFcw0KPiAtICAgICAgICAgIEl0 IGF2b2lkcyB0aGUgdGVybSChsGFkdmVydGlzZaGxIHdoaWNoLCBJTUhPLCBkb2VzIG5vdCANCj4g YXBwbHkgdG8gd2hhdCBsYWJlbCByZXF1ZXN0IG1lc3NhZ2VzIGRvLg0KW0xpemhvbmddIE9LLCBh Y2NlcHQuIFRoYW5rIHlvdS4NCg0KTGl6aG9uZw0KDQoNCg0KPiANCj4gUmVnYXJkcywNCj4gICAg ICBTYXNoYQ0KPiANCj4gRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gDQo+IFNlbnQ6IFRodXJz ZGF5LCBKdW5lIDE0LCAyMDEyIDY6MjMgUE0NCj4gVG86ICdMaXpob25nIEppbicNCj4gQ2M6IGRy YWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLmFsbEB0b29scy5pZXRmLm9yZzsgcnRnLQ0K PiBhZHNAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFJ0 Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLTAzLnR4dA0KPiAN Cj4gTGl6aG9uZyBoaSwNCj4gTG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IHJlc3BvbnNlLg0K PiANCj4gUGxlYXNlIHNlZSBzb21lIGFuc3dlcnMgaW5saW5lIGJlbG93IChicm93biBpdGFsaWNz KS4NCj4gDQo+IEkgd2lsbCByZWFkIHRoZSBuZXcgdmVyc2lvbiBhbmQgcHJvdmlkZSBhZGRpdGlv bmFsIGNvbW1lbnRzIGxhdGVyLCANCj4gaG9wZSB0aGlzIGlzIE9LLg0KPiANCj4gUmVnYXJkcywN Cj4gICAgICBTYXNoYQ0KPiANCj4gRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmpp bkB6dGUuY29tLmNuXSANCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMTQsIDIwMTIgMTI6NDggUE0N Cj4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQo+IENjOiBkcmFmdC1pZXRmLXB3ZTMtY2JpdC1u ZWdvdGlhdGlvbi5hbGxAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy0NCj4gYWRzQHRvb2xzLmlldGYub3Jn OyBydGctZGlyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1p ZXRmLXB3ZTMtY2JpdC1uZWdvdGlhdGlvbi0wMy50eHQNCj4gDQo+IA0KPiBIaSBTYXNoYSwgDQo+ IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSB2YWx1YWJsZSBjb21tZW50cy4gUGxlYXNlIHNl ZSBteSByZXBseSANCj4gaW5saW5lIGJlbG93LiANCj4gSSBhbHNvIGF0dGFjaGVkIHRoZSBtb2Rp ZmllZCB2ZXJzaW9uIGZvciB5b3VyIGNoZWNrIGFuZCByZWZlcmVuY2UuIA0KPiANCj4gUmVnYXJk cyANCj4gTGl6aG9uZyANCj4gDQo+IA0KPiANCj4gQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhh bmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiB3cm90ZSANCj4gMjAxMi8wNi8xNCAxMzoyMzo1 OToNCj4gDQo+ID4gSGVsbG8sDQo+ID4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgDQo+ID4gZHJhZnQuIFRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciANCj4gPiByb3V0aW5n LXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJ RVNHIA0KPiA+IHJldmlldy4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRl IGFzc2lzdGFuY2UgdG8gdGhlIA0KPiA+IFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgDQpwbGVhc2Ugc2VlIA0KPiA+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCj4gPiANCj4gPiBB bHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBS b3V0aW5nIA0KPiA+IEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lk ZXIgdGhlbSBhbG9uZyB3aXRoIGFueSANCj4gPiBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50 cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIA0KPiA+IHJlc29sdmUgdGhlbSB0aHJv dWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KPiA+IA0KPiA+IERvY3Vt ZW50OiAgIGRyYWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLTAzLnR4dA0KPiA+IFJldmll d2VyOiAgIEFsZXhhbmRlciAoIlNhc2hhIikgVmFpbnNodGVpbg0KPiA+IFJldmlldyBEYXRlOiAg IDEzLjA2LjEyDQo+ID4gSUVURiBMQyBFbmQgZGF0ZTogIDE1LjA2LjEyDQo+ID4gSW50ZW5kZWQg U3RhdHVzOiAgU3RhbmRhcmRzIFRyYWNrIA0KPiA+IA0KPiA+IA0KPiA+IFNVTU1BUlk6DQo+ID4g DQo+ID4gSSB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBpcyBnZW5lcmFsbHkgaW4gZ29vZCBzaGFw ZSBhbmQgYWxtb3N0IA0KPiA+IHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gDQo+ID4gSG93ZXZlciwg SSBoYXZlIHNvbWUgbWlub3IgdGVjaG5pY2FsIGNvbmNlcm5zIGFzIHdlbGwgYXMgc29tZSANCj4g PiBlZGl0b3JpYWwgb25lcyB3aGljaCwgSU1ITywgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBw dWJsaWNhdGlvbi4NCj4gPiANCj4gPiBNQUpPUiBJU1NVRVM6ICBOb25lDQo+ID4gDQo+ID4gTUlO T1IgSVNTVUVTOg0KPiA+IA0KPiA+IFRlY2huaWNhbDoNCj4gPiANCj4gPiAgVGhlIGFjdHVhbCBD LWJpdCBuZWdvdGlhdGlvbiBwcm90b2NvbCAoZXh0ZW5zaW9uIG9mIHdoYXQgaGFzIGJlZW4gDQo+ ID4gZGVmaW5lZCBpbiBSRkMgNDQ0NykgaXMgcHJlc2VudGVkIGluIHRoZSBkb2N1bWVudCAzICh0 aHJlZSkgdGltZXM6DQo+ID4gDQo+ID4gIC0gIEluIFNlY3Rpb24gMywgaXRlbXMgaSkgdG8gaWlp KSBhbmQgdGhlIHBhcmFncmFwaCBpbW1lZGlhdGVseSANCj4gPiBmb2xsb3dpbmcgdGhlc2UgaXRl bXMuIFRoaXMgdGV4dCB1c2VzIHRoZSBJRVRGIGNhcGl0YWxpemVkIA0KPiA+IHJlcXVpcmVtZW50 IGxldmVsIHRlcm1zIChNVVNUKSBhbmQgaGVuY2UgbG9va3MgbGlrZSB0aGUgbm9ybWF0aXZlIA0K PiA+IGRlZmluaXRpb24gb2YgdGhlIHByb3RvY29sDQo+ID4gDQo+ID4gIC0gICBJbiB0aGUgc2Ft ZSBTZWN0aW9uLCBpdGVtcyAxIHRvIDUuIFRoaXMgdGV4dCByZWZlcnMgdG8gYW4gKElNSE8NCj4g PiBub3QgdmVyeSBpbmZvcm1hdGl2ZSkgRmlndXJlIDEgYnV0IGRvZXMgbm90IGNvbnRhaW4gdGhl IElFVEYgDQo+ID4gY2FwaXRhbGl6ZWQgcmVxdWlyZW1lbnQgbGV2ZWwgdGVybXMuIA0KPiA+IA0K PiA+ICAtIEluIEFwcGVuZGl4IEEuIFRoaXMgQXBwZW5kaXggY29udGFpbnMgYSBibG9jayBkaWFn cmFtIG9mIHRoZSBDLQ0KPiA+IGJpdCBuZWdvdGlhdGlvbiBwcm9jZWR1cmUgdGhhdCBmb2xsb3dz L2lsbHVzdHJhdGVzIHRoZSB0ZXh0IGluIGl0ZW1zDQo+ID4gMSkgLSA3KSBvZiBTZWN0aW9uIDMu DQo+ID4gDQo+ID4gICBUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBwcmVzdW1hYmx5IG5vcm1h dGl2ZSBkZWZpbml0aW9uIGFuZCB0d28NCj4gPiBvdGhlcnMgaXMgdGhhdCB0aGUgZmlyc3Qgb25l IGV4cGxpY2l0bHkgc3RhdGVzOiAgIkxvY2FsIFBFIE1VU1Qgc2VuZA0KPiA+IGEgbGFiZWwgd2l0 aGRyYXcgbWVzc2FnZSB0byByZW1vdGUgUEUgaWYgaXQgaGFzIHByZXZpb3VzbHkgc2VudCBhIA0K PiA+IGxhYmVsIG1hcHBpbmcsIGFuZCB3YWl0IHVudGlsIHJlY2VpdmluZyBhIGxhYmVsIHJlbGVh c2UgZnJvbSB0aGUgDQo+IHJlbW90ZSBQRSIuIA0KPiA+ICAoTm90ZTogIkxvY2FsIFBFIiBpbiB0 aGUgZG9jdW1lbnQgaXMgdGhlIFBFIHRoYXQgaGFzIGNoYW5nZWQgDQo+ID4gY29uZmlndXJhdGlv biBvZiBDVyB1c2FnZSAoaW4gdGhpcyBjYXNlLCBmcm9tIE5PVCBQUkVGRVJSRUQgdG8gDQpQUkVG RVJSRUQuKQ0KPiA+IA0KPiA+ICBUaGUgdHdvIG90aGVyIGZyYWdtZW50cyBkbyBub3QgbWVudGlv biB3YWl0aW5nIGZvciB0aGUgbGFiZWwgDQo+ID4gcmVsZWFzZSBtZXNzYWdlIGZyb20gdGhlIHJl bW90ZSBQRSwgaS5lLiBhcmUgbm90IGZ1bGx5IGNvbnNpc3RlbnQgDQo+ID4gd2l0aCB0aGUgbm9y bWF0aXZlIG9uZS4NCj4gPiANCj4gPiAgTXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIExEUCBwcm9j ZWR1cmVzIGFzIHBlciBSRkMgNTAzNiBpcyB0aGF0IGFuIA0KPiA+IExTUiB0aGF0IHNlbmRzIGEg bGFiZWwgd2l0aGRyYXcgbWVzc2FnZSBNVVNUIHdhaXQgZm9yIHRoZSANCj4gPiBhY2tub3dsZWRn aW5nICAgIGxhYmVsIHJlbGVhc2UgbWVzc2FnZSBmcm9tIHRoZSBwZWVyLCBpLmUuIHRoZSANCj4g PiBwcmVzdW1lZCBub3JtYXRpdmUgZGVmaW5pdGlvbiBpcyBjb3JyZWN0LiBBbmQgaW4gYW55IGNh c2UgSSB0aGluayANCj4gPiB0aGF0IGFsbCB0aGUgYWxsIHRoZSBkZXNjcmlwdGlvbnMgb2YgdGhl IHByb3RvY29sICh0ZXh0cywgYmxvY2sgDQo+ID4gZGlhZ3JhbXMgZXRjLikgbXVzdCBiZSBmdWxs eSBjb25zaXN0ZW50LiANCj4gW0xpemhvbmddIGFncmVlLCBhbmQgd2Ugd2lsbCBjaGFuZ2UgdGhl IHNlY29uZCBhbmQgdGhpcmQgdGV4dCANCj4gZnJhZ21lbnQgdG8gcmVmbGVjdCB0aGlzLiANCj4g W1tbU2FzaGFdXV0gT0suIA0KPiANCj4gDQo+ID4gDQo+ID4gSSBhbHNvIHN1Z2dlc3QgdG8gY2xh cmlmeSB3aGV0aGVyIHNlbmRpbmcgdGhlIGxhYmVsIHJlbGVhc2UgbWVzc2FnZSANCj4gPiBieSB0 aGUgbG9jYWwgUEUgYWJvdmUgc2hvdWxkIHdhaXQgZm9yIHRoZSBsYWJlbCByZWxlYXNlIG1lc3Nh Z2UgZnJvbQ0KPiA+IHRoZSByZW1vdGUgUEUgaWYgbGFiZWwgd2l0aGRyYXcgbWVzc2FnZSBoYXMg YmVlbiBzZW50LiAgSSBleHBlY3QgDQo+ID4gdGhhdCwgdXBvbiByZWNlaXZpbmcgdGhlIGxhYmVs IHdpdGhkcmF3IG1lc3NhZ2UgZnJvbSB0aGUgbG9jYWwgUEUsIA0KPiA+IHRoZSByZW1vdGUgb25l LCBpbiBhZGRpdGlvbiB0byBhY2tub3dsZWRnaW5nIGl0IHdpdGggYSBsYWJlbCByZWxlYXNlDQo+ ID4gbWVzc2FnZSB3b3VsZCBhbHNvIGltbWVkaWF0ZWx5IHNlbmQgaXRzIG93biBsYWJlbCB3aXRo ZHJhdyBtZXNzYWdlIA0KPiA+IHRvIHRoZSBsb2NhbCBQRSB3aGljaCB3b3VsZCB0aGVuLCBpbiBp dHMgdHVybiwgc2VuZCBsYWJlbCByZWxlYXNlIA0KPiA+IG1lc3NhZ2UgYmFjay4gDQo+IFtMaXpo b25nXSB0aGUgcmVtb3RlIG9uZSB3aWxsIG5vdCBzZW5kIGxhYmVsIHdpdGhkcmF3IGFmdGVyIA0K PiBhY2tub3dsZWRnaW5nIHdpdGggbGFiZWwgcmVsZWFzZSwgYmVjYXVzZSAibGliZXJhbCBsYWJl bCByZXRlbnRpb24iIA0KPiBtb2RlIGlzIGFwcGxpZWQuIA0KPiBUaGUgc2VuZGluZyBsYWJlbCBy ZWxlYXNlIG1lc3NhZ2UgYnkgbG9jYWwgUEUgaXMgbm90IG5lY2Vzc2FyeSB0byANCj4gd2FpdCBm b3IgdGhlIHJlbGVhc2UgZnJvbSByZW1vdGUuIFdpbGwgY2xhcmlmeSB0aGlzIGluIHRoZSBkcmFm dC4gDQo+IFtbW1Nhc2hhXV1dIEkgYW0gbm90IHN1cmUgbGliZXJhbCBsYWJlbCByZXRlbnRpb24g cmVhbGx5IGFwcGxpZXMgDQo+IGhlcmUgqEMgSU1ITyBpdCBqdXN0IHNheXMgdGhhdCB1bnVzZWQg bGFiZWwgYWR2ZXJ0aXNlbWVudHMgcmVjZWl2ZWQgDQo+IGJ5IGFuIE5FIGFyZSByZXRhaW5lZC4g QW5kIGl0IHNlZW1zIHRoYXQgUkZDIDQ0NyBpcyBub3QgdmVyeSBjbGVhciANCj4gb24gcHJvY2Vk dXJlcyBmb3IgdGVhcmluZyBkb3duIGEgUFcuIEJ1dCBhcyBsb25nIGFzIHlvdSBjbGFyaWZ5IHRo aXMNCj4gcG9pbnQsIGl0IGlzIG5vdCByZWFsbHkgaW1wb3J0YW50IGZvciB0aGlzIGRyYWZ0Lg0K PiANCj4gPiANCj4gPiBFZGl0b3JpYWw6DQo+ID4gDQo+ID4gIDEuIFdpdGggcmVnYXJkIHRvIG11 bHRpLXNlZ21lbnQgUFdzLCB0aGUgZHJhZnQgc2F5cyB0aGF0ICJ0aGUgDQo+ID4gKGxhYmVsKSBy ZXF1ZXN0IG1lc3NhZ2UgTVVTVCBiZSBwcm9jZXNzZWQgaW4gb3JkZXJlZCBtb2RlIi4gSXQgaXMg DQo+ID4gbm90IGNsZWFyIHRvIG1lIHdoZXRoZXIgdGhpcyByZWZlcnMgdG8gb3JkZXJlZCBsYWJl bCBkaXN0cmlidXRpb24gDQo+ID4gbW9kZSBvZiBMRFAgYXMgZGVmaW5lZCBpbiBSRkMgNTAzNiwg b3IgdG8gc29tZXRoaW5nIGVsc2UuIEF0IHRoZSANCj4gPiBzYW1lIHRpbWUsIHRoZSBwcm9jZWR1 cmUgZGVmaW5lZCBpbiB0aGUgZHJhZnQgaXMgY29tcGxpYW50IHdpdGggdGhlIA0KPiA+IGNvbW1v biBQVyBsYWJlbCBkaXN0cmlidXRpb24gcHJvY2VkdXJlcyBhcyBkZWZpbmVkIGluIFJGQyA2MDcz LCBzbyBJDQo+ID4gc3VnZ2VzdCB0byBjb25zaWRlciByZWZlcmVuY2luZyBSRkMgNjA3MyAodGhl cmUgaXMgbm8gc3VjaCByZWZlcmVuY2UNCj4gPiBpbiB0aGUgZHJhZnQpIGluc3RlYWQgb2YgdXNp bmcgYSBwb3RlbnRpYWxseSBtaXNsZWFkaW5nIHRlcm0uIEkgYWxzbw0KPiA+IHdvbmRlciBpZiB0 aGlzIGRyYWZ0IHNob3VsZCBub3QgYmUgY29uc2lkZXJlZCBhcyB1cGRhdGluZyBSRkMgNjA3MyAN Cj4gPiBpbiBhZGRpdGlvbiB0byB1cGRhdGluZyBSRkMgNDQ0Ny4gDQo+IFtMaXpob25nXSB5ZXMs IG9yZGVyZWQgbW9kZSBmb2xsb3dzIG9yZGVyZWQgbGFiZWwgZGlzdHJpYnV0aW9uIG1vZGUgDQo+ IGluIFJGQzUwMzYuIEFuZCBJIGFncmVlLCByZWZlcmVuY2luZyBSRkM2MDczIHdvdWxkIGJlIG1v cmUgY2xlYXIuIA0KPiBBbmQgeWVzLCB0aGUgZHJhZnQgaXMgYWxzbyB1cGRhdGluZyBSRkM2MDcz LiANCj4gW1tbU2FzaGFdXV0gSSBhbSBub3Qgc3VyZSBvcmRlcmVkIGxhYmVsIGRpc3RyaWJ1dGlv biBpbiA1MDM2IHJlYWxseSANCj4gYXBwbGllcyBoZXJlLCBiZWNhdXNlIG15IHJlYWRpbmcgb2Yg NTAzNiBzdWdnZXN0cyB0aGF0IGl0IGlzIHVzZWQgDQo+IChvciBub3QgdXNlZCkgcGVyIExTUi4g IEkgc3VzcGVjdCB0aGF0IHRoaXMgbWF5IGJlIHRoZSByZWFzb24gZm9yIA0KPiB0aGUgYXV0aG9y cyBvZiA2MDczIG5vdCB0byBtZW50aW9uIGl0IGJ1dCBleHBsaWNpdGx5IGRlZmluZSB0aGUgDQo+ IHByb2Nlc3MgaW5zdGVhZC4gQnV0LCBhcyBJIGhhdmUgc2FpZCwgdGhlIHByb2NlZHVyZSB5b3Wh r3ZlIHNwZWNpZmllZCANCmxvb2tzIE9LLg0KPiANCj4gDQo+ID4gDQo+ID4gIDIuIEFzIG1lbnRp b25lZCBhYm92ZSwgdGhlcmUgYXJlIHR3byB0ZXh0IGZyYWdtZW50cyBkZWZpbmluZyB0aGUgDQo+ ID4gbmV3IEMtYml0IG5lZ290aWF0aW9uIHByb2NlZHVyZSBpbiB0aGUgZHJhZnQuIEkgc3VnZ2Vz dCB0byBjb25zaWRlciANCj4gPiBtZXJnaW5nIHRoZW0gaW50byBhIHNpbmdsZSB0ZXh0IHRoYXQg Y29uc2lzdGVudGx5IHVzZXMgdGhlIElFVEYgDQo+ID4gY2FwaXRhbGl6ZWQgdGVybXMgZm9yIHJl cXVpcmVtZW50IGxldmVscyB3aGlsZSBhdm9pZGluZyBzdWNoIHZhZ3VlIA0KPiA+IHRlcm1zIGFz ICJjb3VsZCIgIChlLmcuLCAiIFBFMiBjb3VsZCB3YWl0IGZvciBQRTEgbGFiZWwgIGJpbmRpbmcg DQo+ID4gYmVmb3JlIHNlbmRpbmcgaXRzIGxhYmVsIGJpbmRpbmcgd2l0aCBDLWJpdCBzZXQiKS4g SGF2aW5nIGEgc2luZ2xlIA0KPiA+IHRleHQgZnJhZ21lbnQgdGhhdCBkZWZpbmVzIHRoZSBwcm9j ZWR1cmUgd291bGQgYWxzbyByZWR1Y2UgdGhlIA0KPiA+IHBvdGVudGlhbCBmb3IgaW5jb25zaXN0 ZW5jaWVzLiANCj4gW0xpemhvbmddIHRoZSBmaXJzdCB0ZXh0IGZyYWdtZW50IGRlZmluZXMgdGhl IHJlcXVpcmVtZW50LCBhbmQgdGhlIA0KPiBzZWNvbmQgZ2l2ZXMgYW4gdXNlY2FzZSBhY2NvcmRp bmcgdG8gdGhlIGZpcnN0IHRleHQuIFdoYXQgaWYgd2UgbW92ZQ0KPiB0aGUgdXNlIGNhc2UgdG8g YW5vdGhlciBzdWItc2VjdGlvbiwgc28gYXMgdG8gbWFrZSBpdCBtb3JlIGNsZWFyPyANCj4gW1tb U2FzaGFdXV0gSSB3b25kZXIgaWYgdGhlIHNlY29uZCBmcmFnbWVudCByZWFsbHkgYWRkcyBtdWNo IHRvIHRoZSANCj4gZmlyc3Qgb25lICh3aGljaCBkZWZpbmVzIHRoZSBwcm9jZWR1cmUpLiBCdXQg YXMgbG9uZyBhcyAoMSkgaXQgaXMgDQo+IGNsZWFybHkgc3BlY2lmaWVkIHdoYXQgaXMgdGhlIG5v cm1hdGl2ZSBzcGVjaWZpY2F0aW9uIGFuZCB3aGF0IGlzIA0KPiB0aGUgdXNlIGNhc2UsIGFuZCAo YikgdGhlIHVzZSBjYXNlIGlzIGZ1bGx5IGNvbnNpc3RlbnQgd2l0aCB0aGUgDQo+IG5vcm1hdGl2 ZSBzcGVjaWZpY2F0aW9uLCBpdCBpcyBPSy4gDQo+IA0KPiANCj4gPiANCj4gPiAgMy4gVGhlIHRl eHQsIGFzIHdyaXR0ZW4sIGRvZXMgbm90IGNsZWFybHkgZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGUg DQo+ID4gUFcgY29udHJvbCB3b3JkIChhcyBhIGZpZWxkIGluIHRoZSBwYWNrZXQpIGFuZCB0aGUg UFcgY29udHJvbCB3b3JkIA0KPiA+ICp1c2UqIGluIGEgUFcgaW5zdGFuY2UuIEluIG1vc3QgY2Fz ZXMgdGhpcyBpcyBub3QgYSBwcm9ibGVtLCBzaW5jZSANCj4gPiB0aGUgZHJhZnQgaXMgYWxsIGFi b3V0IHRoZSBDVyB1c2UuIEhvd2V2ZXIsIHRoZXJlIGFyZSBzZXZlcmFsIGNhc2VzIA0KPiA+IHdo ZW4gdGhpcyBtYXkgcmVzdWx0IGluIG1pc2ludGVycHJldGF0aW9uLCBlLmcuICh0aGUgbmV4dCB0 d28gaXRlbXMgDQo+ID4gYXJlIGNvcHkgYW5kIHBhc3RlIHF1b3RlcyBmcm9tIHRoZSBkcmFmdCk6 DQo+ID4gDQo+ID4gIC0gICAgV2hlbiB0aGUgcGVlciBQRSBzdWNjZXNzZnVsbHkgcHJvY2Vzc2Vk IHRoZSBsYWJlbCB3aXRoZHJhdyBhbmQNCj4gPiBsYWJlbCByZWxlYXNlLCBhbmQgcmVtb3ZlZCB0 aGUgcmVtb3RlIGxhYmVsIGJpbmRpbmcsIGl0IE1VU1QgcmVzZXQgDQo+ID4gaXRzIGxvY2FsIGNv bnRyb2wgd29yZCB3aXRoIHRoZSBjb25maWd1cmVkIG9uZS4uLiANCj4gPiANCj4gPiAgLSBXaGVu IExvY2FsIFBFIGNoYW5nZXMgaXRzIGNvbnRyb2wgd29yZCBmcm9tIFBSRUZFUlJFRCB0byBOT1Qg DQpQUkVGRVJSRUQuLi4NCj4gPiANCj4gPiAoUGxlYXNlIG5vdGUgYWxzbyB0aGF0ICpwcmVmZXJy ZWQqIFBXIGNvbnRyb2wgd29yZCBpcyBkZWZpbmVkIGluIFJGQw0KPiA+IDQzODUsIGJ1dCB0aGUg bWVhbmluZyBpcyBjb21wbGV0ZWx5IGRpZmZlcmVudCBmcm9tIG9uZSBpbXBsaWVkIGhlcmUpLg0K PiA+IA0KPiA+IEkgc3VnZ2VzdCB0byBjb25zaWRlciBjbGFyaWZ5aW5nIHRoYXQgdGhlc2UgKGFu ZCBwb3NzaWJseSBzb21lIA0KPiA+IG90aGVyKSBmcmFnbWVudHMgcmVmZXIgdG8gdGhlIFBXIENX IHVzYWdlIGFuZCBub3QgdG8gZm9ybWF0IG9yIA0KPiA+IGNvbnRlbnQgb2YgdGhlIENXLiBUaGVy ZSBpcyBjbGVhcmx5IG1vcmUgdGhhbiBvbmUgd2F5IHRvIGRvIHRoYXQuIA0KPiA+IElNSE8gYW5k IEZXSVcgdGhlIG1vc3QgdW5hbWJpZ3VvdXMgb25lIHdvdWxkIGJlIHRvIGRlZmluZSB0aGUgDQo+ ID4gcmVsZXZhbnQgc3RhdGUgdmFyaWFibGVzIG9mIHRoZSBQVyBlbmQgcG9pbnRzIChjb25maWd1 cmVkLCANCj4gPiB0cmFuc21pdHRlZCBhbmQgcmVjZWl2ZWQgQy1iaXQpIGFuZCB0byB1c2UgdGhl bSBpbiB0aGUgZGVmaW5pdGlvbiBvZg0KPiA+IHRoZSBwcm9jZWR1cmUsIGJ1dCB0aGlzIGlzIGRl ZmluaXRlbHkgZm9yIHRoZSBhdXRob3JzIHRvIGRlY2lkZS4gDQo+IFtMaXpob25nXSB3ZSB3aWxs IGNoYW5nZSB0aGUgImNvbnRyb2wgd29yZCIgdG8gInVzZSBvZiBjb250cm9sIHdvcmQiDQo+IGlu IHRoZSBkcmFmdCwgYW5kIG1ha2UgaXQgY2xlYXIuIA0KPiBbW1tTYXNoYV1dXSBTb3VuZHMgT0su DQo+IA0KPiANCj4gPiANCj4gPiBOaXRzOiAgTm9uZSBmb3VuZCBieSB0aGUgSUVURiBkcmFmdCBj aGVja2VyLg0KPiA+IA0KPiA+IFJlZ2FyZHMsDQo+ID4gICAgICBTYXNoYQ0KPiA+IFRoaXMgZS1t YWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFp bnMgDQo+ID4gaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkg YmUgcHJvcHJpZXRhcnkgdG8gDQo+ID4gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UNCj4gPiBpbmZvcm0gdXMgYnkgZS1t YWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIA0KPiA+ IGFsbCBjb3BpZXMgdGhlcmVvZi4NCj4gPiANCj4gPiANCj4gVGhpcyBlLW1haWwgbWVzc2FnZSBp cyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyANCj4gaW5mb3Jt YXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkg dG8gDQo+IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlDQo+IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwg YW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgDQo+IGFsbCBjb3BpZXMgdGhlcmVvZi4g DQo= --=_alternative 0014561548257A1E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDtBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSZndDsNCndyb3RlIDIwMTIvMDYvMTQgMjM6NDE6 MTE6PGJyPg0KPGJyPg0KJmd0OyBMaXpob25nLCBoaSBhZ2FpbiE8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mZ3Q7IEkgaGF2ZSByZWFkIHRoZSB1cGRhdGVkIGRyYWZ0LCBhbmQgaXQgbG9va3MgT0su DQpUaGVyZSBqdXN0IGFuIDxicj4NCiZndDsgYWRkaXRpb25hbCBtaW5vciBjb21tZW50IG9uIHRo ZSB0ZXh0IHRoYXQgZGVhbHMgd2l0aCAmbmJzcDt0byBNUy1QV3MuPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+Jmd0OyBUaGUgZHJhZnQgc2F5cyChsFdoZW4gUy1QRSByZWNlaXZlcyBhIGxhYmVsDQpy ZXF1ZXN0IG1lc3NhZ2UgZnJvbSBhIDxicj4NCiZndDsgcmVtb3RlIFBFLCBpdCBNVVNUIGFkdmVy dGlzZSB0aGUgcmVxdWVzdCBtZXNzYWdlIHRvIHRoZSBvdGhlciByZW1vdGUNClBFLjxicj4NCiZn dDsgobEgVGhlIGludGVudGlvbiBpcyBjbGVhciwgYnV0IEkgc3VnZ2VzdCB0byBjb25zaWRlciBj aGFuZ2luZyBpdA0KdG8gPGJyPg0KJmd0OyBzb21ldGhpbmcgbGlrZSChsFdoZW4gYW4gUy1QRSBy ZWNlaXZlcyBhIGxhYmVsIHJlcXVlc3QgbWVzc2FnZSBmcm9tDQo8YnI+DQomZ3Q7IG9uZSBvZiBp dHMgYWRqYWNlbnQgUEVzIChiZSBpdCBTLVBFIG9yIGFub3RoZXIgVC1QRSksIGl0IE1VU1Qgc2Vu ZA0KYTxicj4NCiZndDsgbWF0Y2hpbmcgbGFiZWwgcmVxdWVzdCBtZXNzYWdlIGl0IGlzIG90aGVy IGFkamFjZW50IFBFIChhZ2FpbiwgaXQNCjxicj4NCiZndDsgbWF5IGJlIGFuIFMtUEUgb3IgYSBU LVBFKaGxLiBUaGlzIG1vZGlmaWNhdGlvbiwgaWYgaXQgc3VpdHMgeW91LA0KPGJyPg0KJmd0OyB3 b3VsZCBzZXJ2ZSB0d28gcHVycG9zZXM6PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD4mZ3Q7IC0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0l0IHdvdWxkDQpjbGFy aWZ5IHRoYXQgYW4gUy1QRSByZWxheXMgTGFiZWwgUmVxdWVzdCA8YnI+DQomZ3Q7IG1lc3NhZ2Vz IGZyb20gb25lIG9mIGl0cyBuZWlnaGJvcnMgdG8gdGhlIG90aGVyIG9uZSwgYW5kIGRvZXMgbm90 DQo8YnI+DQomZ3Q7IGNhcmUgKGluZGVlZCwgaXQgZG9lcyBub3QgdXN1YWxseSBrbm93KSB3aGV0 aGVyIHRoZXNlIG5laWdoYm9ycyBhcmUNCjxicj4NCiZndDsgVC1QRXMgb3IgUy1QRXM8L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgLSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SXQgYXZvaWRzDQp0aGUgdGVybSChsGFkdmVydGlzZaGxIHdoaWNoLCBJTUhP LCBkb2VzIG5vdCA8YnI+DQomZ3Q7IGFwcGx5IHRvIHdoYXQgbGFiZWwgcmVxdWVzdCBtZXNzYWdl cyBkby48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PltMaXpob25nXSBPSywgYWNj ZXB0LiBUaGFuayB5b3UuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5M aXpob25nPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBSZWdh cmRzLDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1Nhc2hhPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNw OzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBGcm9tOiBBbGV4YW5kZXIg VmFpbnNodGVpbiA8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE0LCAyMDEyIDY6MjMg UE08YnI+DQomZ3Q7IFRvOiAnTGl6aG9uZyBKaW4nPGJyPg0KJmd0OyBDYzogZHJhZnQtaWV0Zi1w d2UzLWNiaXQtbmVnb3RpYXRpb24uYWxsQHRvb2xzLmlldGYub3JnOyBydGctPGJyPg0KJmd0OyBh ZHNAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJF OiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXB3ZTMtY2JpdC1uZWdvdGlhdGlvbi0wMy50eHQ8 L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IExpemhvbmcgaGksPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IExvdHMgb2YgdGhhbmtzIGZvciBhIHByb21wdCByZXNwb25z ZS48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFBsZWFzZSBzZWUgc29tZSBhbnN3ZXJzIGlu bGluZSBiZWxvdyAoYnJvd24gaXRhbGljcykuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBJ IHdpbGwgcmVhZCB0aGUgbmV3IHZlcnNpb24gYW5kIHByb3ZpZGUgYWRkaXRpb25hbA0KY29tbWVu dHMgbGF0ZXIsIDxicj4NCiZndDsgaG9wZSB0aGlzIGlzIE9LLjwvdHQ+PC9mb250Pg0KPGJyPjxm b250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PiZndDsgUmVnYXJkcyw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtTYXNoYTwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgRnJv bTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmppbkB6dGUuY29tLmNuXQ0KPGJyPg0KJmd0 OyBTZW50OiBUaHVyc2RheSwgSnVuZSAxNCwgMjAxMiAxMjo0OCBQTTxicj4NCiZndDsgVG86IEFs ZXhhbmRlciBWYWluc2h0ZWluPGJyPg0KJmd0OyBDYzogZHJhZnQtaWV0Zi1wd2UzLWNiaXQtbmVn b3RpYXRpb24uYWxsQHRvb2xzLmlldGYub3JnOyBydGctPGJyPg0KJmd0OyBhZHNAdG9vbHMuaWV0 Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBSdGdEaXIgcmV2 aWV3OiBkcmFmdC1pZXRmLXB3ZTMtY2JpdC1uZWdvdGlhdGlvbi0wMy50eHQ8L3R0PjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgSGkgU2FzaGEsIDxicj4NCiZndDsgVGhhbmsgeW91 IHZlcnkgbXVjaCBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlcGx5 DQo8YnI+DQomZ3Q7IGlubGluZSBiZWxvdy4gPGJyPg0KJmd0OyBJIGFsc28gYXR0YWNoZWQgdGhl IG1vZGlmaWVkIHZlcnNpb24gZm9yIHlvdXIgY2hlY2sgYW5kIHJlZmVyZW5jZS4NCjxicj4NCiZn dDsgPGJyPg0KJmd0OyBSZWdhcmRzIDxicj4NCiZndDsgTGl6aG9uZyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgJm5ic3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbGV4YW5kZXIgVmFpbnNodGVpbiAm bHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7IHdyb3RlDQo8YnI+DQomZ3Q7 IDIwMTIvMDYvMTQgMTM6MjM6NTk6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgSGVsbG8sPGJy Pg0KJmd0OyAmZ3Q7IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9y YXRlIHJldmlld2VyIGZvcg0KdGhpcyA8YnI+DQomZ3Q7ICZndDsgZHJhZnQuIFRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvcg0KPGJyPg0KJmd0OyAm Z3Q7IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0 IGNhbGwgYW5kDQpJRVNHIDxicj4NCiZndDsgJmd0OyByZXZpZXcuIFRoZSBwdXJwb3NlIG9mIHRo ZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7 IFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJl Y3RvcmF0ZSwNCnBsZWFzZSBzZWUgPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWw8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIFJvdXRpbmcNCjxicj4NCiZndDsgJmd0OyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYg eW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aA0KYW55IDxicj4NCiZndDsgJmd0OyBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvDQo8YnI+DQomZ3Q7ICZndDsgcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBi eSB1cGRhdGluZyB0aGUgZHJhZnQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBEb2N1 bWVudDogJm5ic3A7IGRyYWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLTAzLnR4dDxicj4N CiZndDsgJmd0OyBSZXZpZXdlcjogJm5ic3A7IEFsZXhhbmRlciAoJnF1b3Q7U2FzaGEmcXVvdDsp IFZhaW5zaHRlaW48YnI+DQomZ3Q7ICZndDsgUmV2aWV3IERhdGU6ICZuYnNwOyAxMy4wNi4xMjxi cj4NCiZndDsgJmd0OyBJRVRGIExDIEVuZCBkYXRlOiAmbmJzcDsxNS4wNi4xMjxicj4NCiZndDsg Jmd0OyBJbnRlbmRlZCBTdGF0dXM6ICZuYnNwO1N0YW5kYXJkcyBUcmFjayA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTVU1NQVJZOjxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgSSB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBpcyBnZW5lcmFsbHkg aW4gZ29vZCBzaGFwZSBhbmQgYWxtb3N0DQo8YnI+DQomZ3Q7ICZndDsgcmVhZHkgZm9yIHB1Ymxp Y2F0aW9uLiA8YnI+DQomZ3Q7ICZndDsgSG93ZXZlciwgSSBoYXZlIHNvbWUgbWlub3IgdGVjaG5p Y2FsIGNvbmNlcm5zIGFzIHdlbGwgYXMgc29tZQ0KPGJyPg0KJmd0OyAmZ3Q7IGVkaXRvcmlhbCBv bmVzIHdoaWNoLCBJTUhPLCBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLjxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTUFKT1IgSVNTVUVTOiAmbmJzcDtOb25lPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBNSU5PUiBJU1NVRVM6PGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBUZWNobmljYWw6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmbmJzcDtUaGUgYWN0dWFsIEMtYml0IG5lZ290aWF0aW9uIHByb3RvY29sIChleHRlbnNpb24g b2Ygd2hhdA0KaGFzIGJlZW4gPGJyPg0KJmd0OyAmZ3Q7IGRlZmluZWQgaW4gUkZDIDQ0NDcpIGlz IHByZXNlbnRlZCBpbiB0aGUgZG9jdW1lbnQgMyAodGhyZWUpIHRpbWVzOjxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7LSAmbmJzcDtJbiBTZWN0aW9uIDMsIGl0ZW1zIGkpIHRv IGlpaSkgYW5kIHRoZSBwYXJhZ3JhcGgNCmltbWVkaWF0ZWx5IDxicj4NCiZndDsgJmd0OyBmb2xs b3dpbmcgdGhlc2UgaXRlbXMuIFRoaXMgdGV4dCB1c2VzIHRoZSBJRVRGIGNhcGl0YWxpemVkIDxi cj4NCiZndDsgJmd0OyByZXF1aXJlbWVudCBsZXZlbCB0ZXJtcyAoTVVTVCkgYW5kIGhlbmNlIGxv b2tzIGxpa2UgdGhlIG5vcm1hdGl2ZQ0KPGJyPg0KJmd0OyAmZ3Q7IGRlZmluaXRpb24gb2YgdGhl IHByb3RvY29sPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDstICZuYnNwOyBJ biB0aGUgc2FtZSBTZWN0aW9uLCBpdGVtcyAxIHRvIDUuIFRoaXMgdGV4dCByZWZlcnMNCnRvIGFu IChJTUhPPGJyPg0KJmd0OyAmZ3Q7IG5vdCB2ZXJ5IGluZm9ybWF0aXZlKSBGaWd1cmUgMSBidXQg ZG9lcyBub3QgY29udGFpbiB0aGUgSUVURg0KPGJyPg0KJmd0OyAmZ3Q7IGNhcGl0YWxpemVkIHJl cXVpcmVtZW50IGxldmVsIHRlcm1zLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOy0gSW4gQXBwZW5kaXggQS4gVGhpcyBBcHBlbmRpeCBjb250YWlucyBhIGJsb2NrIGRpYWdy YW0NCm9mIHRoZSBDLTxicj4NCiZndDsgJmd0OyBiaXQgbmVnb3RpYXRpb24gcHJvY2VkdXJlIHRo YXQgZm9sbG93cy9pbGx1c3RyYXRlcyB0aGUgdGV4dCBpbg0KaXRlbXM8YnI+DQomZ3Q7ICZndDsg MSkgLSA3KSBvZiBTZWN0aW9uIDMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJz cDsgVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgcHJlc3VtYWJseSBub3JtYXRpdmUgZGVmaW5p dGlvbg0KYW5kIHR3bzxicj4NCiZndDsgJmd0OyBvdGhlcnMgaXMgdGhhdCB0aGUgZmlyc3Qgb25l IGV4cGxpY2l0bHkgc3RhdGVzOiAmbmJzcDsmcXVvdDtMb2NhbA0KUEUgTVVTVCBzZW5kPGJyPg0K Jmd0OyAmZ3Q7IGEgbGFiZWwgd2l0aGRyYXcgbWVzc2FnZSB0byByZW1vdGUgUEUgaWYgaXQgaGFz IHByZXZpb3VzbHkgc2VudA0KYSA8YnI+DQomZ3Q7ICZndDsgbGFiZWwgbWFwcGluZywgYW5kIHdh aXQgdW50aWwgcmVjZWl2aW5nIGEgbGFiZWwgcmVsZWFzZSBmcm9tDQp0aGUgPGJyPg0KJmd0OyBy ZW1vdGUgUEUmcXVvdDsuICZuYnNwOzxicj4NCiZndDsgJmd0OyAmbmJzcDsoTm90ZTogJnF1b3Q7 TG9jYWwgUEUmcXVvdDsgaW4gdGhlIGRvY3VtZW50IGlzIHRoZSBQRSB0aGF0DQpoYXMgY2hhbmdl ZCA8YnI+DQomZ3Q7ICZndDsgY29uZmlndXJhdGlvbiBvZiBDVyB1c2FnZSAoaW4gdGhpcyBjYXNl LCBmcm9tIE5PVCBQUkVGRVJSRUQgdG8NClBSRUZFUlJFRC4pPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmbmJzcDtUaGUgdHdvIG90aGVyIGZyYWdtZW50cyBkbyBub3QgbWVudGlvbiB3 YWl0aW5nIGZvciB0aGUNCmxhYmVsIDxicj4NCiZndDsgJmd0OyByZWxlYXNlIG1lc3NhZ2UgZnJv bSB0aGUgcmVtb3RlIFBFLCBpLmUuIGFyZSBub3QgZnVsbHkgY29uc2lzdGVudA0KPGJyPg0KJmd0 OyAmZ3Q7IHdpdGggdGhlIG5vcm1hdGl2ZSBvbmUuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmbmJzcDtNeSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgTERQIHByb2NlZHVyZXMgYXMgcGVy IFJGQyA1MDM2DQppcyB0aGF0IGFuIDxicj4NCiZndDsgJmd0OyBMU1IgdGhhdCBzZW5kcyBhIGxh YmVsIHdpdGhkcmF3IG1lc3NhZ2UgTVVTVCB3YWl0IGZvciB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGFj a25vd2xlZGdpbmcgJm5ic3A7ICZuYnNwO2xhYmVsIHJlbGVhc2UgbWVzc2FnZSBmcm9tIHRoZSBw ZWVyLA0KaS5lLiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IHByZXN1bWVkIG5vcm1hdGl2ZSBkZWZpbml0 aW9uIGlzIGNvcnJlY3QuIEFuZCBpbiBhbnkgY2FzZSBJIHRoaW5rDQo8YnI+DQomZ3Q7ICZndDsg dGhhdCBhbGwgdGhlIGFsbCB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSBwcm90b2NvbCAodGV4dHMs IGJsb2NrDQo8YnI+DQomZ3Q7ICZndDsgZGlhZ3JhbXMgZXRjLikgbXVzdCBiZSBmdWxseSBjb25z aXN0ZW50LiA8YnI+DQomZ3Q7IFtMaXpob25nXSBhZ3JlZSwgYW5kIHdlIHdpbGwgY2hhbmdlIHRo ZSBzZWNvbmQgYW5kIHRoaXJkIHRleHQgPGJyPg0KJmd0OyBmcmFnbWVudCB0byByZWZsZWN0IHRo aXMuIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBbW1tTYXNoYV1dXSBP Sy4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGFsc28gc3VnZ2VzdCB0byBjbGFyaWZ5IHdo ZXRoZXIgc2VuZGluZyB0aGUgbGFiZWwgcmVsZWFzZSBtZXNzYWdlDQo8YnI+DQomZ3Q7ICZndDsg YnkgdGhlIGxvY2FsIFBFIGFib3ZlIHNob3VsZCB3YWl0IGZvciB0aGUgbGFiZWwgcmVsZWFzZSBt ZXNzYWdlDQpmcm9tPGJyPg0KJmd0OyAmZ3Q7IHRoZSByZW1vdGUgUEUgaWYgbGFiZWwgd2l0aGRy YXcgbWVzc2FnZSBoYXMgYmVlbiBzZW50LiAmbmJzcDtJDQpleHBlY3QgPGJyPg0KJmd0OyAmZ3Q7 IHRoYXQsIHVwb24gcmVjZWl2aW5nIHRoZSBsYWJlbCB3aXRoZHJhdyBtZXNzYWdlIGZyb20gdGhl IGxvY2FsDQpQRSwgPGJyPg0KJmd0OyAmZ3Q7IHRoZSByZW1vdGUgb25lLCBpbiBhZGRpdGlvbiB0 byBhY2tub3dsZWRnaW5nIGl0IHdpdGggYSBsYWJlbA0KcmVsZWFzZTxicj4NCiZndDsgJmd0OyBt ZXNzYWdlIHdvdWxkIGFsc28gaW1tZWRpYXRlbHkgc2VuZCBpdHMgb3duIGxhYmVsIHdpdGhkcmF3 IG1lc3NhZ2UNCjxicj4NCiZndDsgJmd0OyB0byB0aGUgbG9jYWwgUEUgd2hpY2ggd291bGQgdGhl biwgaW4gaXRzIHR1cm4sIHNlbmQgbGFiZWwgcmVsZWFzZQ0KPGJyPg0KJmd0OyAmZ3Q7IG1lc3Nh Z2UgYmFjay4gPGJyPg0KJmd0OyBbTGl6aG9uZ10gdGhlIHJlbW90ZSBvbmUgd2lsbCBub3Qgc2Vu ZCBsYWJlbCB3aXRoZHJhdyBhZnRlciA8YnI+DQomZ3Q7IGFja25vd2xlZGdpbmcgd2l0aCBsYWJl bCByZWxlYXNlLCBiZWNhdXNlICZxdW90O2xpYmVyYWwgbGFiZWwgcmV0ZW50aW9uJnF1b3Q7DQo8 YnI+DQomZ3Q7IG1vZGUgaXMgYXBwbGllZC4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mZ3Q7IFRoZSBzZW5kaW5nIGxhYmVsIHJlbGVhc2UgbWVzc2FnZSBieSBsb2NhbCBQRQ0K aXMgbm90IG5lY2Vzc2FyeSB0byA8YnI+DQomZ3Q7IHdhaXQgZm9yIHRoZSByZWxlYXNlIGZyb20g cmVtb3RlLiBXaWxsIGNsYXJpZnkgdGhpcyBpbiB0aGUgZHJhZnQuDQo8YnI+DQomZ3Q7IFtbW1Nh c2hhXV1dIEkgYW0gbm90IHN1cmUgbGliZXJhbCBsYWJlbCByZXRlbnRpb24gcmVhbGx5IGFwcGxp ZXMgPGJyPg0KJmd0OyBoZXJlIKhDIElNSE8gaXQganVzdCBzYXlzIHRoYXQgdW51c2VkIGxhYmVs IGFkdmVydGlzZW1lbnRzIHJlY2VpdmVkDQo8YnI+DQomZ3Q7IGJ5IGFuIE5FIGFyZSByZXRhaW5l ZC4gQW5kIGl0IHNlZW1zIHRoYXQgUkZDIDQ0NyBpcyBub3QgdmVyeSBjbGVhcg0KPGJyPg0KJmd0 OyBvbiBwcm9jZWR1cmVzIGZvciB0ZWFyaW5nIGRvd24gYSBQVy4gQnV0IGFzIGxvbmcgYXMgeW91 IGNsYXJpZnkgdGhpczxicj4NCiZndDsgcG9pbnQsIGl0IGlzIG5vdCByZWFsbHkgaW1wb3J0YW50 IGZvciB0aGlzIGRyYWZ0LjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEVkaXRvcmlhbDo8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzEuIFdpdGggcmVnYXJkIHRvIG11bHRpLXNlZ21lbnQgUFdz LCB0aGUgZHJhZnQgc2F5cyB0aGF0DQomcXVvdDt0aGUgPGJyPg0KJmd0OyAmZ3Q7IChsYWJlbCkg cmVxdWVzdCBtZXNzYWdlIE1VU1QgYmUgcHJvY2Vzc2VkIGluIG9yZGVyZWQgbW9kZSZxdW90Oy4N Ckl0IGlzIDxicj4NCiZndDsgJmd0OyBub3QgY2xlYXIgdG8gbWUgd2hldGhlciB0aGlzIHJlZmVy cyB0byBvcmRlcmVkIGxhYmVsIGRpc3RyaWJ1dGlvbg0KPGJyPg0KJmd0OyAmZ3Q7IG1vZGUgb2Yg TERQIGFzIGRlZmluZWQgaW4gUkZDIDUwMzYsIG9yIHRvIHNvbWV0aGluZyBlbHNlLiBBdA0KdGhl IDxicj4NCiZndDsgJmd0OyBzYW1lIHRpbWUsIHRoZSBwcm9jZWR1cmUgZGVmaW5lZCBpbiB0aGUg ZHJhZnQgaXMgY29tcGxpYW50IHdpdGgNCnRoZSA8YnI+DQomZ3Q7ICZndDsgY29tbW9uIFBXIGxh YmVsIGRpc3RyaWJ1dGlvbiBwcm9jZWR1cmVzIGFzIGRlZmluZWQgaW4gUkZDIDYwNzMsDQpzbyBJ PGJyPg0KJmd0OyAmZ3Q7IHN1Z2dlc3QgdG8gY29uc2lkZXIgcmVmZXJlbmNpbmcgUkZDIDYwNzMg KHRoZXJlIGlzIG5vIHN1Y2ggcmVmZXJlbmNlPGJyPg0KJmd0OyAmZ3Q7IGluIHRoZSBkcmFmdCkg aW5zdGVhZCBvZiB1c2luZyBhIHBvdGVudGlhbGx5IG1pc2xlYWRpbmcgdGVybS4NCkkgYWxzbzxi cj4NCiZndDsgJmd0OyB3b25kZXIgaWYgdGhpcyBkcmFmdCBzaG91bGQgbm90IGJlIGNvbnNpZGVy ZWQgYXMgdXBkYXRpbmcgUkZDDQo2MDczIDxicj4NCiZndDsgJmd0OyBpbiBhZGRpdGlvbiB0byB1 cGRhdGluZyBSRkMgNDQ0Ny4gPGJyPg0KJmd0OyBbTGl6aG9uZ10geWVzLCBvcmRlcmVkIG1vZGUg Zm9sbG93cyBvcmRlcmVkIGxhYmVsIGRpc3RyaWJ1dGlvbiBtb2RlDQo8YnI+DQomZ3Q7IGluIFJG QzUwMzYuIEFuZCBJIGFncmVlLCByZWZlcmVuY2luZyBSRkM2MDczIHdvdWxkIGJlIG1vcmUgY2xl YXIuDQo8YnI+DQomZ3Q7IEFuZCB5ZXMsIHRoZSBkcmFmdCBpcyBhbHNvIHVwZGF0aW5nIFJGQzYw NzMuIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBbW1tTYXNoYV1dXSBJ IGFtIG5vdCBzdXJlIG9yZGVyZWQgbGFiZWwgZGlzdHJpYnV0aW9uDQppbiA1MDM2IHJlYWxseSA8 YnI+DQomZ3Q7IGFwcGxpZXMgaGVyZSwgYmVjYXVzZSBteSByZWFkaW5nIG9mIDUwMzYgc3VnZ2Vz dHMgdGhhdCBpdCBpcyB1c2VkDQo8YnI+DQomZ3Q7IChvciBub3QgdXNlZCkgcGVyIExTUi4gJm5i c3A7SSBzdXNwZWN0IHRoYXQgdGhpcyBtYXkgYmUgdGhlIHJlYXNvbg0KZm9yIDxicj4NCiZndDsg dGhlIGF1dGhvcnMgb2YgNjA3MyBub3QgdG8gbWVudGlvbiBpdCBidXQgZXhwbGljaXRseSBkZWZp bmUgdGhlIDxicj4NCiZndDsgcHJvY2VzcyBpbnN0ZWFkLiBCdXQsIGFzIEkgaGF2ZSBzYWlkLCB0 aGUgcHJvY2VkdXJlIHlvdaGvdmUgc3BlY2lmaWVkDQpsb29rcyBPSy48L3R0PjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOzIuIEFzIG1lbnRpb25lZCBhYm92ZSwgdGhlcmUgYXJlIHR3byB0ZXh0 IGZyYWdtZW50cyBkZWZpbmluZw0KdGhlIDxicj4NCiZndDsgJmd0OyBuZXcgQy1iaXQgbmVnb3Rp YXRpb24gcHJvY2VkdXJlIGluIHRoZSBkcmFmdC4gSSBzdWdnZXN0IHRvIGNvbnNpZGVyDQo8YnI+ DQomZ3Q7ICZndDsgbWVyZ2luZyB0aGVtIGludG8gYSBzaW5nbGUgdGV4dCB0aGF0IGNvbnNpc3Rl bnRseSB1c2VzIHRoZSBJRVRGDQo8YnI+DQomZ3Q7ICZndDsgY2FwaXRhbGl6ZWQgdGVybXMgZm9y IHJlcXVpcmVtZW50IGxldmVscyB3aGlsZSBhdm9pZGluZyBzdWNoDQp2YWd1ZSA8YnI+DQomZ3Q7 ICZndDsgdGVybXMgYXMgJnF1b3Q7Y291bGQmcXVvdDsgJm5ic3A7KGUuZy4sICZxdW90OyBQRTIg Y291bGQgd2FpdA0KZm9yIFBFMSBsYWJlbCAmbmJzcDtiaW5kaW5nIDxicj4NCiZndDsgJmd0OyBi ZWZvcmUgc2VuZGluZyBpdHMgbGFiZWwgYmluZGluZyB3aXRoIEMtYml0IHNldCZxdW90OykuIEhh dmluZw0KYSBzaW5nbGUgPGJyPg0KJmd0OyAmZ3Q7IHRleHQgZnJhZ21lbnQgdGhhdCBkZWZpbmVz IHRoZSBwcm9jZWR1cmUgd291bGQgYWxzbyByZWR1Y2UgdGhlDQo8YnI+DQomZ3Q7ICZndDsgcG90 ZW50aWFsIGZvciBpbmNvbnNpc3RlbmNpZXMuIDxicj4NCiZndDsgW0xpemhvbmddIHRoZSBmaXJz dCB0ZXh0IGZyYWdtZW50IGRlZmluZXMgdGhlIHJlcXVpcmVtZW50LCBhbmQgdGhlDQo8YnI+DQom Z3Q7IHNlY29uZCBnaXZlcyBhbiB1c2VjYXNlIGFjY29yZGluZyB0byB0aGUgZmlyc3QgdGV4dC4g V2hhdCBpZiB3ZSBtb3ZlPGJyPg0KJmd0OyB0aGUgdXNlIGNhc2UgdG8gYW5vdGhlciBzdWItc2Vj dGlvbiwgc28gYXMgdG8gbWFrZSBpdCBtb3JlIGNsZWFyPw0KPC90dD48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD4mZ3Q7IFtbW1Nhc2hhXV1dIEkgd29uZGVyIGlmIHRoZSBzZWNvbmQgZnJh Z21lbnQgcmVhbGx5DQphZGRzIG11Y2ggdG8gdGhlIDxicj4NCiZndDsgZmlyc3Qgb25lICh3aGlj aCBkZWZpbmVzIHRoZSBwcm9jZWR1cmUpLiBCdXQgYXMgbG9uZyBhcyAoMSkgaXQgaXMNCjxicj4N CiZndDsgY2xlYXJseSBzcGVjaWZpZWQgd2hhdCBpcyB0aGUgbm9ybWF0aXZlIHNwZWNpZmljYXRp b24gYW5kIHdoYXQgaXMNCjxicj4NCiZndDsgdGhlIHVzZSBjYXNlLCBhbmQgKGIpIHRoZSB1c2Ug Y2FzZSBpcyBmdWxseSBjb25zaXN0ZW50IHdpdGggdGhlIDxicj4NCiZndDsgbm9ybWF0aXZlIHNw ZWNpZmljYXRpb24sIGl0IGlzIE9LLiAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTI+PHR0PiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOzMuIFRoZSB0ZXh0LCBhcyB3cml0dGVuLCBkb2VzIG5vdCBjbGVhcmx5IGRpc3Rpbmd1aXNo IGJldHdlZW4NCnRoZSA8YnI+DQomZ3Q7ICZndDsgUFcgY29udHJvbCB3b3JkIChhcyBhIGZpZWxk IGluIHRoZSBwYWNrZXQpIGFuZCB0aGUgUFcgY29udHJvbA0Kd29yZCA8YnI+DQomZ3Q7ICZndDsg KnVzZSogaW4gYSBQVyBpbnN0YW5jZS4gSW4gbW9zdCBjYXNlcyB0aGlzIGlzIG5vdCBhIHByb2Js ZW0sDQpzaW5jZSA8YnI+DQomZ3Q7ICZndDsgdGhlIGRyYWZ0IGlzIGFsbCBhYm91dCB0aGUgQ1cg dXNlLiBIb3dldmVyLCB0aGVyZSBhcmUgc2V2ZXJhbA0KY2FzZXMgPGJyPg0KJmd0OyAmZ3Q7IHdo ZW4gdGhpcyBtYXkgcmVzdWx0IGluIG1pc2ludGVycHJldGF0aW9uLCBlLmcuICh0aGUgbmV4dCB0 d28NCml0ZW1zIDxicj4NCiZndDsgJmd0OyBhcmUgY29weSBhbmQgcGFzdGUgcXVvdGVzIGZyb20g dGhlIGRyYWZ0KTo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOy0gJm5ic3A7 ICZuYnNwO1doZW4gdGhlIHBlZXIgUEUgc3VjY2Vzc2Z1bGx5IHByb2Nlc3NlZA0KdGhlIGxhYmVs IHdpdGhkcmF3IGFuZDxicj4NCiZndDsgJmd0OyBsYWJlbCByZWxlYXNlLCBhbmQgcmVtb3ZlZCB0 aGUgcmVtb3RlIGxhYmVsIGJpbmRpbmcsIGl0IE1VU1QNCnJlc2V0IDxicj4NCiZndDsgJmd0OyBp dHMgbG9jYWwgY29udHJvbCB3b3JkIHdpdGggdGhlIGNvbmZpZ3VyZWQgb25lLi4uIDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7LSBXaGVuIExvY2FsIFBFIGNoYW5nZXMgaXRz IGNvbnRyb2wgd29yZCBmcm9tIFBSRUZFUlJFRA0KdG8gTk9UIFBSRUZFUlJFRC4uLjxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgKFBsZWFzZSBub3RlIGFsc28gdGhhdCAqcHJlZmVycmVk KiBQVyBjb250cm9sIHdvcmQgaXMgZGVmaW5lZA0KaW4gUkZDPGJyPg0KJmd0OyAmZ3Q7IDQzODUs IGJ1dCB0aGUgbWVhbmluZyBpcyBjb21wbGV0ZWx5IGRpZmZlcmVudCBmcm9tIG9uZSBpbXBsaWVk DQpoZXJlKS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgc3VnZ2VzdCB0byBjb25z aWRlciBjbGFyaWZ5aW5nIHRoYXQgdGhlc2UgKGFuZCBwb3NzaWJseSBzb21lDQo8YnI+DQomZ3Q7 ICZndDsgb3RoZXIpIGZyYWdtZW50cyByZWZlciB0byB0aGUgUFcgQ1cgdXNhZ2UgYW5kIG5vdCB0 byBmb3JtYXQgb3INCjxicj4NCiZndDsgJmd0OyBjb250ZW50IG9mIHRoZSBDVy4gVGhlcmUgaXMg Y2xlYXJseSBtb3JlIHRoYW4gb25lIHdheSB0byBkbyB0aGF0Lg0KPGJyPg0KJmd0OyAmZ3Q7IElN SE8gYW5kIEZXSVcgdGhlIG1vc3QgdW5hbWJpZ3VvdXMgb25lIHdvdWxkIGJlIHRvIGRlZmluZSB0 aGUNCjxicj4NCiZndDsgJmd0OyByZWxldmFudCBzdGF0ZSB2YXJpYWJsZXMgb2YgdGhlIFBXIGVu ZCBwb2ludHMgKGNvbmZpZ3VyZWQsIDxicj4NCiZndDsgJmd0OyB0cmFuc21pdHRlZCBhbmQgcmVj ZWl2ZWQgQy1iaXQpIGFuZCB0byB1c2UgdGhlbSBpbiB0aGUgZGVmaW5pdGlvbg0Kb2Y8YnI+DQom Z3Q7ICZndDsgdGhlIHByb2NlZHVyZSwgYnV0IHRoaXMgaXMgZGVmaW5pdGVseSBmb3IgdGhlIGF1 dGhvcnMgdG8gZGVjaWRlLg0KPGJyPg0KJmd0OyBbTGl6aG9uZ10gd2Ugd2lsbCBjaGFuZ2UgdGhl ICZxdW90O2NvbnRyb2wgd29yZCZxdW90OyB0byAmcXVvdDt1c2UNCm9mIGNvbnRyb2wgd29yZCZx dW90Ozxicj4NCiZndDsgaW4gdGhlIGRyYWZ0LCBhbmQgbWFrZSBpdCBjbGVhci4gPC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFtbW1Nhc2hhXV1dIFNvdW5kcyBPSy48L3R0 PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5pdHM6ICZuYnNwO05vbmUgZm91bmQgYnkgdGhlIElFVEYg ZHJhZnQgY2hlY2tlci48YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IFJlZ2Fy ZHMsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2FzaGE8YnI+DQomZ3Q7ICZn dDsgVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5 IGFuZCBjb250YWlucw0KPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJ REVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5DQp0byA8YnI+DQomZ3Q7ICZndDsg RUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy cm9yLA0KcGxlYXNlPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbA0KYW5kIDxicj4NCiZndDsgJmd0OyBh bGwgY29waWVzIHRoZXJlb2YuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBp bnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudA0Kb25seSBhbmQgY29udGFpbnMgPGJyPg0KJmd0OyBp bmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmll dGFyeSB0bw0KPGJyPg0KJmd0OyBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZTxicj4NCiZndDsgaW5mb3JtIHVzIGJ5IGUt bWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZA0KPGJy Pg0KJmd0OyBhbGwgY29waWVzIHRoZXJlb2YuIDwvdHQ+PC9mb250Pg0K --=_alternative 0014561548257A1E_=-- From lizhong.jin@zte.com.cn Thu Jun 14 20:50:24 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A8A11E80BE for ; Thu, 14 Jun 2012 20:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.523 X-Spam-Level: X-Spam-Status: No, score=-100.523 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC7q8fN1VByD for ; Thu, 14 Jun 2012 20:50:22 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9E511E80B6 for ; Thu, 14 Jun 2012 20:50:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620712910399; Fri, 15 Jun 2012 11:47:46 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 29378.3572189594; Fri, 15 Jun 2012 11:49:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q5F3o4ad043749; Fri, 15 Jun 2012 11:50:05 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Alexander Vainshtein MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Fri, 15 Jun 2012 11:49:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-06-15 11:50:06, Serialize complete at 2012-06-15 11:50:06 Content-Type: multipart/alternative; boundary="=_alternative 00150F2248257A1E_=" X-MAIL: mse02.zte.com.cn q5F3o4ad043749 X-Mailman-Approved-At: Fri, 15 Jun 2012 02:18:07 -0700 Cc: "draft-ietf-pwe3-cbit-negotiation.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pwe3-cbit-negotiation-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 03:50:24 -0000 This is a multipart message in MIME format. --=_alternative 00150F2248257A1E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2FzaGEsDQpZZXMsIGFuZCB0aGlzIGRyYWZ0IHVzZSBhIGxhYmVsIHJlbGVhc2UgcmVjZWl2 ZWQgdG8gcmVsZWFzZSB0aGUgUFcgbGFiZWxzLiANCldlIHdpbGwgdXBsb2FkIHRoZSByZXZpc2Vk IHZlcnNpb24gYWZ0ZXIgdGhlIGVuZCBvZiBsYXN0IGNhbGwuIFRoYW5rIHlvdSANCmZvciB0aGUg dmFsdWFibGUgY29tbWVudHMuDQoNClJlZ2FyZHMNCkxpemhvbmcNCiANCg0KQWxleGFuZGVyIFZh aW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiB3cm90ZSAyMDEyLzA2 LzE1IA0KMDM6MTY6MzY6DQoNCj4gTGl6aG9uZyBoaSAoYWdhaW4pLA0KPiBBZnRlciByZS1yZWFk aW5nIDQ0NDcgSSBoYXZlIGNvbWUgdG8gY29uY2x1c2lvbiB0aGF0IGEgTGFiZWwgDQo+IFdpdGhk cmF3IG1lc3NhZ2Ugc2VudCBieSBvbmUgb2YgdGhlIFBFcyB0byBpdHMgcGVlciB3b3VsZCBiZSAN Cj4gcmVzcG9uZGVkIHdpdGgvYWNrZWQgYnkgIGEgTGFiZWwgUmVsZWFzZSBtZXNzYWdlLCBidXQg aXQgd2lsbCBub3QgDQo+IHRyaWdnZXIgYSBMYWJlbCBXaXRoZHJhdyBtZXNzYWdlIGZyb20gdGhl IHBlZXIgUEUuIFRoaXMgaXMgYmFzZWQgb24gDQo+IHRoZSB0ZXh0IHRoYXQgc2F5cyB0aGF0IFBX IGxhYmVscywgb25jZSBhZHZlcnRpc2VkLCBhcmUgd2l0aGRyYXduIGluDQo+IGp1c3QgdGhyZWUg Y2FzZXM6DQo+IDEuIFdoZW4gdGhlIGxvY2FsIFBXIGVuZHBvaW50IGlzIGRlbGV0ZWQgZnJvbSB0 aGUgUEUgY29uZmlndXJhdGlvbiANCj4gMi4gV2hlbiB0aGUgIGxvY2FsIFBXIGVuZHBvaW50IGlz IGFkbWluaXN0cmF0aXZlbHkgZGlzYWJsZWQgYnkgdGhlIHVzZXIgDQo+IDMuIFdoZW4gdGhlIGxv Y2FsIEFDIGdvZXMgRE9XTiAob25seSBpZiB0aGUgUFcgU3RhdHVzIGlzIG5vdCBzdXBwb3J0ZWQp Lg0KPiANCj4gQWN0dWFsbHkgdGhlIGRyYWZ0IGFkZHMgb25lIG1vcmUgY2FzZSB0byB0aGlzIGxp c3QuIA0KPiANCj4gUmVnYXJkcywNCj4gICAgICBTYXNoYQ0KPiANCj4gRnJvbTogQWxleGFuZGVy IFZhaW5zaHRlaW4NCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMTQsIDIwMTIgNTo0MSBQTQ0KPiBU bzogTGl6aG9uZyBKaW4NCj4gQ2M6IGRyYWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLmFs bEB0b29scy5pZXRmLm9yZzsgcnRnLQ0KPiBhZHNAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcHdlMy1jYml0 LW5lZ290aWF0aW9uLTAzLnR4dA0KDQo+IExpemhvbmcsIGhpIGFnYWluIQ0KPiANCj4gSSBoYXZl IHJlYWQgdGhlIHVwZGF0ZWQgZHJhZnQsIGFuZCBpdCBsb29rcyBPSy4gVGhlcmUganVzdCBhbiAN Cj4gYWRkaXRpb25hbCBtaW5vciBjb21tZW50IG9uIHRoZSB0ZXh0IHRoYXQgZGVhbHMgd2l0aCAg dG8gTVMtUFdzLg0KPiANCj4gVGhlIGRyYWZ0IHNheXMgobBXaGVuIFMtUEUgcmVjZWl2ZXMgYSBs YWJlbCByZXF1ZXN0IG1lc3NhZ2UgZnJvbSBhIA0KPiByZW1vdGUgUEUsIGl0IE1VU1QgYWR2ZXJ0 aXNlIHRoZSByZXF1ZXN0IG1lc3NhZ2UgdG8gdGhlIG90aGVyIHJlbW90ZSBQRS4NCj4gobEgVGhl IGludGVudGlvbiBpcyBjbGVhciwgYnV0IEkgc3VnZ2VzdCB0byBjb25zaWRlciBjaGFuZ2luZyBp dCB0byANCj4gc29tZXRoaW5nIGxpa2UgobBXaGVuIGFuIFMtUEUgcmVjZWl2ZXMgYSBsYWJlbCBy ZXF1ZXN0IG1lc3NhZ2UgZnJvbSANCj4gb25lIG9mIGl0cyBhZGphY2VudCBQRXMgKGJlIGl0IFMt UEUgb3IgYW5vdGhlciBULVBFKSwgaXQgTVVTVCBzZW5kIGENCj4gbWF0Y2hpbmcgbGFiZWwgcmVx dWVzdCBtZXNzYWdlIGl0IGlzIG90aGVyIGFkamFjZW50IFBFIChhZ2FpbiwgaXQgDQo+IG1heSBi ZSBhbiBTLVBFIG9yIGEgVC1QRSmhsS4gVGhpcyBtb2RpZmljYXRpb24sIGlmIGl0IHN1aXRzIHlv dSwgDQo+IHdvdWxkIHNlcnZlIHR3byBwdXJwb3NlczoNCj4gLSAgICAgICAgICBJdCB3b3VsZCBj bGFyaWZ5IHRoYXQgYW4gUy1QRSByZWxheXMgTGFiZWwgUmVxdWVzdCANCj4gbWVzc2FnZXMgZnJv bSBvbmUgb2YgaXRzIG5laWdoYm9ycyB0byB0aGUgb3RoZXIgb25lLCBhbmQgZG9lcyBub3QgDQo+ IGNhcmUgKGluZGVlZCwgaXQgZG9lcyBub3QgdXN1YWxseSBrbm93KSB3aGV0aGVyIHRoZXNlIG5l aWdoYm9ycyBhcmUgDQo+IFQtUEVzIG9yIFMtUEVzDQo+IC0gICAgICAgICAgSXQgYXZvaWRzIHRo ZSB0ZXJtIKGwYWR2ZXJ0aXNlobEgd2hpY2gsIElNSE8sIGRvZXMgbm90IA0KPiBhcHBseSB0byB3 aGF0IGxhYmVsIHJlcXVlc3QgbWVzc2FnZXMgZG8uDQo+IA0KPiBSZWdhcmRzLA0KPiAgICAgIFNh c2hhDQo+IA0KPiBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiANCj4gU2VudDogVGh1cnNkYXks IEp1bmUgMTQsIDIwMTIgNjoyMyBQTQ0KPiBUbzogJ0xpemhvbmcgSmluJw0KPiBDYzogZHJhZnQt aWV0Zi1wd2UzLWNiaXQtbmVnb3RpYXRpb24uYWxsQHRvb2xzLmlldGYub3JnOyBydGctDQo+IGFk c0B0b29scy5pZXRmLm9yZzsgcnRnLWRpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUnRnRGly IHJldmlldzogZHJhZnQtaWV0Zi1wd2UzLWNiaXQtbmVnb3RpYXRpb24tMDMudHh0DQo+IA0KPiBM aXpob25nIGhpLA0KPiBMb3RzIG9mIHRoYW5rcyBmb3IgYSBwcm9tcHQgcmVzcG9uc2UuDQo+IA0K PiBQbGVhc2Ugc2VlIHNvbWUgYW5zd2VycyBpbmxpbmUgYmVsb3cgKGJyb3duIGl0YWxpY3MpLg0K PiANCj4gSSB3aWxsIHJlYWQgdGhlIG5ldyB2ZXJzaW9uIGFuZCBwcm92aWRlIGFkZGl0aW9uYWwg Y29tbWVudHMgbGF0ZXIsIA0KPiBob3BlIHRoaXMgaXMgT0suDQo+IA0KPiBSZWdhcmRzLA0KPiAg ICAgIFNhc2hhDQo+IA0KPiBGcm9tOiBMaXpob25nIEppbiBbbWFpbHRvOmxpemhvbmcuamluQHp0 ZS5jb20uY25dIA0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAxNCwgMjAxMiAxMjo0OCBQTQ0KPiBU bzogQWxleGFuZGVyIFZhaW5zaHRlaW4NCj4gQ2M6IGRyYWZ0LWlldGYtcHdlMy1jYml0LW5lZ290 aWF0aW9uLmFsbEB0b29scy5pZXRmLm9yZzsgcnRnLQ0KPiBhZHNAdG9vbHMuaWV0Zi5vcmc7IHJ0 Zy1kaXJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYt cHdlMy1jYml0LW5lZ290aWF0aW9uLTAzLnR4dA0KPiANCj4gDQo+IEhpIFNhc2hhLCANCj4gVGhh bmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15 IHJlcGx5IA0KPiBpbmxpbmUgYmVsb3cuIA0KPiBJIGFsc28gYXR0YWNoZWQgdGhlIG1vZGlmaWVk IHZlcnNpb24gZm9yIHlvdXIgY2hlY2sgYW5kIHJlZmVyZW5jZS4gDQo+IA0KPiBSZWdhcmRzIA0K PiBMaXpob25nIA0KPiANCj4gDQo+IA0KPiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVy LlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+IHdyb3RlIA0KPiAyMDEyLzA2LzE0IDEzOjIzOjU5Og0K PiANCj4gPiBIZWxsbywNCj4gPiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBE aXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyANCj4gPiBkcmFmdC4gVGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIA0KPiA+IHJvdXRpbmctcmVs YXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cg DQo+ID4gcmV2aWV3LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNz aXN0YW5jZSB0byB0aGUgDQo+ID4gUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCANCnBsZWFzZSBzZWUgDQo+ID4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlL3JvdXRpbmcuaHRtbA0KPiA+IA0KPiA+IEFsdGhv dWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRp bmcgDQo+ID4gQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0 aGVtIGFsb25nIHdpdGggYW55IA0KPiA+IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRo YXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gDQo+ID4gcmVzb2x2ZSB0aGVtIHRocm91Z2gg ZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ID4gDQo+ID4gRG9jdW1lbnQ6 ICAgZHJhZnQtaWV0Zi1wd2UzLWNiaXQtbmVnb3RpYXRpb24tMDMudHh0DQo+ID4gUmV2aWV3ZXI6 ICAgQWxleGFuZGVyICgiU2FzaGEiKSBWYWluc2h0ZWluDQo+ID4gUmV2aWV3IERhdGU6ICAgMTMu MDYuMTINCj4gPiBJRVRGIExDIEVuZCBkYXRlOiAgMTUuMDYuMTINCj4gPiBJbnRlbmRlZCBTdGF0 dXM6ICBTdGFuZGFyZHMgVHJhY2sgDQo+ID4gDQo+ID4gDQo+ID4gU1VNTUFSWToNCj4gPiANCj4g PiBJIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IGlzIGdlbmVyYWxseSBpbiBnb29kIHNoYXBlIGFu ZCBhbG1vc3QgDQo+ID4gcmVhZHkgZm9yIHB1YmxpY2F0aW9uLiANCj4gPiBIb3dldmVyLCBJIGhh dmUgc29tZSBtaW5vciB0ZWNobmljYWwgY29uY2VybnMgYXMgd2VsbCBhcyBzb21lIA0KPiA+IGVk aXRvcmlhbCBvbmVzIHdoaWNoLCBJTUhPLCBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1Ymxp Y2F0aW9uLg0KPiA+IA0KPiA+IE1BSk9SIElTU1VFUzogIE5vbmUNCj4gPiANCj4gPiBNSU5PUiBJ U1NVRVM6DQo+ID4gDQo+ID4gVGVjaG5pY2FsOg0KPiA+IA0KPiA+ICBUaGUgYWN0dWFsIEMtYml0 IG5lZ290aWF0aW9uIHByb3RvY29sIChleHRlbnNpb24gb2Ygd2hhdCBoYXMgYmVlbiANCj4gPiBk ZWZpbmVkIGluIFJGQyA0NDQ3KSBpcyBwcmVzZW50ZWQgaW4gdGhlIGRvY3VtZW50IDMgKHRocmVl KSB0aW1lczoNCj4gPiANCj4gPiAgLSAgSW4gU2VjdGlvbiAzLCBpdGVtcyBpKSB0byBpaWkpIGFu ZCB0aGUgcGFyYWdyYXBoIGltbWVkaWF0ZWx5IA0KPiA+IGZvbGxvd2luZyB0aGVzZSBpdGVtcy4g VGhpcyB0ZXh0IHVzZXMgdGhlIElFVEYgY2FwaXRhbGl6ZWQgDQo+ID4gcmVxdWlyZW1lbnQgbGV2 ZWwgdGVybXMgKE1VU1QpIGFuZCBoZW5jZSBsb29rcyBsaWtlIHRoZSBub3JtYXRpdmUgDQo+ID4g ZGVmaW5pdGlvbiBvZiB0aGUgcHJvdG9jb2wNCj4gPiANCj4gPiAgLSAgIEluIHRoZSBzYW1lIFNl Y3Rpb24sIGl0ZW1zIDEgdG8gNS4gVGhpcyB0ZXh0IHJlZmVycyB0byBhbiAoSU1ITw0KPiA+IG5v dCB2ZXJ5IGluZm9ybWF0aXZlKSBGaWd1cmUgMSBidXQgZG9lcyBub3QgY29udGFpbiB0aGUgSUVU RiANCj4gPiBjYXBpdGFsaXplZCByZXF1aXJlbWVudCBsZXZlbCB0ZXJtcy4gDQo+ID4gDQo+ID4g IC0gSW4gQXBwZW5kaXggQS4gVGhpcyBBcHBlbmRpeCBjb250YWlucyBhIGJsb2NrIGRpYWdyYW0g b2YgdGhlIEMtDQo+ID4gYml0IG5lZ290aWF0aW9uIHByb2NlZHVyZSB0aGF0IGZvbGxvd3MvaWxs dXN0cmF0ZXMgdGhlIHRleHQgaW4gaXRlbXMNCj4gPiAxKSAtIDcpIG9mIFNlY3Rpb24gMy4NCj4g PiANCj4gPiAgIFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHByZXN1bWFibHkgbm9ybWF0aXZl IGRlZmluaXRpb24gYW5kIHR3bw0KPiA+IG90aGVycyBpcyB0aGF0IHRoZSBmaXJzdCBvbmUgZXhw bGljaXRseSBzdGF0ZXM6ICAiTG9jYWwgUEUgTVVTVCBzZW5kDQo+ID4gYSBsYWJlbCB3aXRoZHJh dyBtZXNzYWdlIHRvIHJlbW90ZSBQRSBpZiBpdCBoYXMgcHJldmlvdXNseSBzZW50IGEgDQo+ID4g bGFiZWwgbWFwcGluZywgYW5kIHdhaXQgdW50aWwgcmVjZWl2aW5nIGEgbGFiZWwgcmVsZWFzZSBm cm9tIHRoZSANCj4gcmVtb3RlIFBFIi4gDQo+ID4gIChOb3RlOiAiTG9jYWwgUEUiIGluIHRoZSBk b2N1bWVudCBpcyB0aGUgUEUgdGhhdCBoYXMgY2hhbmdlZCANCj4gPiBjb25maWd1cmF0aW9uIG9m IENXIHVzYWdlIChpbiB0aGlzIGNhc2UsIGZyb20gTk9UIFBSRUZFUlJFRCB0byANClBSRUZFUlJF RC4pDQo+ID4gDQo+ID4gIFRoZSB0d28gb3RoZXIgZnJhZ21lbnRzIGRvIG5vdCBtZW50aW9uIHdh aXRpbmcgZm9yIHRoZSBsYWJlbCANCj4gPiByZWxlYXNlIG1lc3NhZ2UgZnJvbSB0aGUgcmVtb3Rl IFBFLCBpLmUuIGFyZSBub3QgZnVsbHkgY29uc2lzdGVudCANCj4gPiB3aXRoIHRoZSBub3JtYXRp dmUgb25lLg0KPiA+IA0KPiA+ICBNeSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgTERQIHByb2NlZHVy ZXMgYXMgcGVyIFJGQyA1MDM2IGlzIHRoYXQgYW4gDQo+ID4gTFNSIHRoYXQgc2VuZHMgYSBsYWJl bCB3aXRoZHJhdyBtZXNzYWdlIE1VU1Qgd2FpdCBmb3IgdGhlIA0KPiA+IGFja25vd2xlZGdpbmcg ICAgbGFiZWwgcmVsZWFzZSBtZXNzYWdlIGZyb20gdGhlIHBlZXIsIGkuZS4gdGhlIA0KPiA+IHBy ZXN1bWVkIG5vcm1hdGl2ZSBkZWZpbml0aW9uIGlzIGNvcnJlY3QuIEFuZCBpbiBhbnkgY2FzZSBJ IHRoaW5rIA0KPiA+IHRoYXQgYWxsIHRoZSBhbGwgdGhlIGRlc2NyaXB0aW9ucyBvZiB0aGUgcHJv dG9jb2wgKHRleHRzLCBibG9jayANCj4gPiBkaWFncmFtcyBldGMuKSBtdXN0IGJlIGZ1bGx5IGNv bnNpc3RlbnQuIA0KPiBbTGl6aG9uZ10gYWdyZWUsIGFuZCB3ZSB3aWxsIGNoYW5nZSB0aGUgc2Vj b25kIGFuZCB0aGlyZCB0ZXh0IA0KPiBmcmFnbWVudCB0byByZWZsZWN0IHRoaXMuIA0KPiBbW1tT YXNoYV1dXSBPSy4gDQo+IA0KPiANCj4gPiANCj4gPiBJIGFsc28gc3VnZ2VzdCB0byBjbGFyaWZ5 IHdoZXRoZXIgc2VuZGluZyB0aGUgbGFiZWwgcmVsZWFzZSBtZXNzYWdlIA0KPiA+IGJ5IHRoZSBs b2NhbCBQRSBhYm92ZSBzaG91bGQgd2FpdCBmb3IgdGhlIGxhYmVsIHJlbGVhc2UgbWVzc2FnZSBm cm9tDQo+ID4gdGhlIHJlbW90ZSBQRSBpZiBsYWJlbCB3aXRoZHJhdyBtZXNzYWdlIGhhcyBiZWVu IHNlbnQuICBJIGV4cGVjdCANCj4gPiB0aGF0LCB1cG9uIHJlY2VpdmluZyB0aGUgbGFiZWwgd2l0 aGRyYXcgbWVzc2FnZSBmcm9tIHRoZSBsb2NhbCBQRSwgDQo+ID4gdGhlIHJlbW90ZSBvbmUsIGlu IGFkZGl0aW9uIHRvIGFja25vd2xlZGdpbmcgaXQgd2l0aCBhIGxhYmVsIHJlbGVhc2UNCj4gPiBt ZXNzYWdlIHdvdWxkIGFsc28gaW1tZWRpYXRlbHkgc2VuZCBpdHMgb3duIGxhYmVsIHdpdGhkcmF3 IG1lc3NhZ2UgDQo+ID4gdG8gdGhlIGxvY2FsIFBFIHdoaWNoIHdvdWxkIHRoZW4sIGluIGl0cyB0 dXJuLCBzZW5kIGxhYmVsIHJlbGVhc2UgDQo+ID4gbWVzc2FnZSBiYWNrLiANCj4gW0xpemhvbmdd IHRoZSByZW1vdGUgb25lIHdpbGwgbm90IHNlbmQgbGFiZWwgd2l0aGRyYXcgYWZ0ZXIgDQo+IGFj a25vd2xlZGdpbmcgd2l0aCBsYWJlbCByZWxlYXNlLCBiZWNhdXNlICJsaWJlcmFsIGxhYmVsIHJl dGVudGlvbiIgDQo+IG1vZGUgaXMgYXBwbGllZC4gDQo+IFRoZSBzZW5kaW5nIGxhYmVsIHJlbGVh c2UgbWVzc2FnZSBieSBsb2NhbCBQRSBpcyBub3QgbmVjZXNzYXJ5IHRvIA0KPiB3YWl0IGZvciB0 aGUgcmVsZWFzZSBmcm9tIHJlbW90ZS4gV2lsbCBjbGFyaWZ5IHRoaXMgaW4gdGhlIGRyYWZ0LiAN Cj4gW1tbU2FzaGFdXV0gSSBhbSBub3Qgc3VyZSBsaWJlcmFsIGxhYmVsIHJldGVudGlvbiByZWFs bHkgYXBwbGllcyANCj4gaGVyZSCoQyBJTUhPIGl0IGp1c3Qgc2F5cyB0aGF0IHVudXNlZCBsYWJl bCBhZHZlcnRpc2VtZW50cyByZWNlaXZlZCANCj4gYnkgYW4gTkUgYXJlIHJldGFpbmVkLiBBbmQg aXQgc2VlbXMgdGhhdCBSRkMgNDQ3IGlzIG5vdCB2ZXJ5IGNsZWFyIA0KPiBvbiBwcm9jZWR1cmVz IGZvciB0ZWFyaW5nIGRvd24gYSBQVy4gQnV0IGFzIGxvbmcgYXMgeW91IGNsYXJpZnkgdGhpcw0K PiBwb2ludCwgaXQgaXMgbm90IHJlYWxseSBpbXBvcnRhbnQgZm9yIHRoaXMgZHJhZnQuDQo+IA0K PiA+IA0KPiA+IEVkaXRvcmlhbDoNCj4gPiANCj4gPiAgMS4gV2l0aCByZWdhcmQgdG8gbXVsdGkt c2VnbWVudCBQV3MsIHRoZSBkcmFmdCBzYXlzIHRoYXQgInRoZSANCj4gPiAobGFiZWwpIHJlcXVl c3QgbWVzc2FnZSBNVVNUIGJlIHByb2Nlc3NlZCBpbiBvcmRlcmVkIG1vZGUiLiBJdCBpcyANCj4g PiBub3QgY2xlYXIgdG8gbWUgd2hldGhlciB0aGlzIHJlZmVycyB0byBvcmRlcmVkIGxhYmVsIGRp c3RyaWJ1dGlvbiANCj4gPiBtb2RlIG9mIExEUCBhcyBkZWZpbmVkIGluIFJGQyA1MDM2LCBvciB0 byBzb21ldGhpbmcgZWxzZS4gQXQgdGhlIA0KPiA+IHNhbWUgdGltZSwgdGhlIHByb2NlZHVyZSBk ZWZpbmVkIGluIHRoZSBkcmFmdCBpcyBjb21wbGlhbnQgd2l0aCB0aGUgDQo+ID4gY29tbW9uIFBX IGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm9jZWR1cmVzIGFzIGRlZmluZWQgaW4gUkZDIDYwNzMsIHNv IEkNCj4gPiBzdWdnZXN0IHRvIGNvbnNpZGVyIHJlZmVyZW5jaW5nIFJGQyA2MDczICh0aGVyZSBp cyBubyBzdWNoIHJlZmVyZW5jZQ0KPiA+IGluIHRoZSBkcmFmdCkgaW5zdGVhZCBvZiB1c2luZyBh IHBvdGVudGlhbGx5IG1pc2xlYWRpbmcgdGVybS4gSSBhbHNvDQo+ID4gd29uZGVyIGlmIHRoaXMg ZHJhZnQgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGFzIHVwZGF0aW5nIFJGQyA2MDczIA0KPiA+ IGluIGFkZGl0aW9uIHRvIHVwZGF0aW5nIFJGQyA0NDQ3LiANCj4gW0xpemhvbmddIHllcywgb3Jk ZXJlZCBtb2RlIGZvbGxvd3Mgb3JkZXJlZCBsYWJlbCBkaXN0cmlidXRpb24gbW9kZSANCj4gaW4g UkZDNTAzNi4gQW5kIEkgYWdyZWUsIHJlZmVyZW5jaW5nIFJGQzYwNzMgd291bGQgYmUgbW9yZSBj bGVhci4gDQo+IEFuZCB5ZXMsIHRoZSBkcmFmdCBpcyBhbHNvIHVwZGF0aW5nIFJGQzYwNzMuIA0K PiBbW1tTYXNoYV1dXSBJIGFtIG5vdCBzdXJlIG9yZGVyZWQgbGFiZWwgZGlzdHJpYnV0aW9uIGlu IDUwMzYgcmVhbGx5IA0KPiBhcHBsaWVzIGhlcmUsIGJlY2F1c2UgbXkgcmVhZGluZyBvZiA1MDM2 IHN1Z2dlc3RzIHRoYXQgaXQgaXMgdXNlZCANCj4gKG9yIG5vdCB1c2VkKSBwZXIgTFNSLiAgSSBz dXNwZWN0IHRoYXQgdGhpcyBtYXkgYmUgdGhlIHJlYXNvbiBmb3IgDQo+IHRoZSBhdXRob3JzIG9m IDYwNzMgbm90IHRvIG1lbnRpb24gaXQgYnV0IGV4cGxpY2l0bHkgZGVmaW5lIHRoZSANCj4gcHJv Y2VzcyBpbnN0ZWFkLiBCdXQsIGFzIEkgaGF2ZSBzYWlkLCB0aGUgcHJvY2VkdXJlIHlvdaGvdmUg c3BlY2lmaWVkIA0KbG9va3MgT0suDQo+IA0KPiANCj4gPiANCj4gPiAgMi4gQXMgbWVudGlvbmVk IGFib3ZlLCB0aGVyZSBhcmUgdHdvIHRleHQgZnJhZ21lbnRzIGRlZmluaW5nIHRoZSANCj4gPiBu ZXcgQy1iaXQgbmVnb3RpYXRpb24gcHJvY2VkdXJlIGluIHRoZSBkcmFmdC4gSSBzdWdnZXN0IHRv IGNvbnNpZGVyIA0KPiA+IG1lcmdpbmcgdGhlbSBpbnRvIGEgc2luZ2xlIHRleHQgdGhhdCBjb25z aXN0ZW50bHkgdXNlcyB0aGUgSUVURiANCj4gPiBjYXBpdGFsaXplZCB0ZXJtcyBmb3IgcmVxdWly ZW1lbnQgbGV2ZWxzIHdoaWxlIGF2b2lkaW5nIHN1Y2ggdmFndWUgDQo+ID4gdGVybXMgYXMgImNv dWxkIiAgKGUuZy4sICIgUEUyIGNvdWxkIHdhaXQgZm9yIFBFMSBsYWJlbCAgYmluZGluZyANCj4g PiBiZWZvcmUgc2VuZGluZyBpdHMgbGFiZWwgYmluZGluZyB3aXRoIEMtYml0IHNldCIpLiBIYXZp bmcgYSBzaW5nbGUgDQo+ID4gdGV4dCBmcmFnbWVudCB0aGF0IGRlZmluZXMgdGhlIHByb2NlZHVy ZSB3b3VsZCBhbHNvIHJlZHVjZSB0aGUgDQo+ID4gcG90ZW50aWFsIGZvciBpbmNvbnNpc3RlbmNp ZXMuIA0KPiBbTGl6aG9uZ10gdGhlIGZpcnN0IHRleHQgZnJhZ21lbnQgZGVmaW5lcyB0aGUgcmVx dWlyZW1lbnQsIGFuZCB0aGUgDQo+IHNlY29uZCBnaXZlcyBhbiB1c2VjYXNlIGFjY29yZGluZyB0 byB0aGUgZmlyc3QgdGV4dC4gV2hhdCBpZiB3ZSBtb3ZlDQo+IHRoZSB1c2UgY2FzZSB0byBhbm90 aGVyIHN1Yi1zZWN0aW9uLCBzbyBhcyB0byBtYWtlIGl0IG1vcmUgY2xlYXI/IA0KPiBbW1tTYXNo YV1dXSBJIHdvbmRlciBpZiB0aGUgc2Vjb25kIGZyYWdtZW50IHJlYWxseSBhZGRzIG11Y2ggdG8g dGhlIA0KPiBmaXJzdCBvbmUgKHdoaWNoIGRlZmluZXMgdGhlIHByb2NlZHVyZSkuIEJ1dCBhcyBs b25nIGFzICgxKSBpdCBpcyANCj4gY2xlYXJseSBzcGVjaWZpZWQgd2hhdCBpcyB0aGUgbm9ybWF0 aXZlIHNwZWNpZmljYXRpb24gYW5kIHdoYXQgaXMgDQo+IHRoZSB1c2UgY2FzZSwgYW5kIChiKSB0 aGUgdXNlIGNhc2UgaXMgZnVsbHkgY29uc2lzdGVudCB3aXRoIHRoZSANCj4gbm9ybWF0aXZlIHNw ZWNpZmljYXRpb24sIGl0IGlzIE9LLiANCj4gDQo+IA0KPiA+IA0KPiA+ICAzLiBUaGUgdGV4dCwg YXMgd3JpdHRlbiwgZG9lcyBub3QgY2xlYXJseSBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSANCj4g PiBQVyBjb250cm9sIHdvcmQgKGFzIGEgZmllbGQgaW4gdGhlIHBhY2tldCkgYW5kIHRoZSBQVyBj b250cm9sIHdvcmQgDQo+ID4gKnVzZSogaW4gYSBQVyBpbnN0YW5jZS4gSW4gbW9zdCBjYXNlcyB0 aGlzIGlzIG5vdCBhIHByb2JsZW0sIHNpbmNlIA0KPiA+IHRoZSBkcmFmdCBpcyBhbGwgYWJvdXQg dGhlIENXIHVzZS4gSG93ZXZlciwgdGhlcmUgYXJlIHNldmVyYWwgY2FzZXMgDQo+ID4gd2hlbiB0 aGlzIG1heSByZXN1bHQgaW4gbWlzaW50ZXJwcmV0YXRpb24sIGUuZy4gKHRoZSBuZXh0IHR3byBp dGVtcyANCj4gPiBhcmUgY29weSBhbmQgcGFzdGUgcXVvdGVzIGZyb20gdGhlIGRyYWZ0KToNCj4g PiANCj4gPiAgLSAgICBXaGVuIHRoZSBwZWVyIFBFIHN1Y2Nlc3NmdWxseSBwcm9jZXNzZWQgdGhl IGxhYmVsIHdpdGhkcmF3IGFuZA0KPiA+IGxhYmVsIHJlbGVhc2UsIGFuZCByZW1vdmVkIHRoZSBy ZW1vdGUgbGFiZWwgYmluZGluZywgaXQgTVVTVCByZXNldCANCj4gPiBpdHMgbG9jYWwgY29udHJv bCB3b3JkIHdpdGggdGhlIGNvbmZpZ3VyZWQgb25lLi4uIA0KPiA+IA0KPiA+ICAtIFdoZW4gTG9j YWwgUEUgY2hhbmdlcyBpdHMgY29udHJvbCB3b3JkIGZyb20gUFJFRkVSUkVEIHRvIE5PVCANClBS RUZFUlJFRC4uLg0KPiA+IA0KPiA+IChQbGVhc2Ugbm90ZSBhbHNvIHRoYXQgKnByZWZlcnJlZCog UFcgY29udHJvbCB3b3JkIGlzIGRlZmluZWQgaW4gUkZDDQo+ID4gNDM4NSwgYnV0IHRoZSBtZWFu aW5nIGlzIGNvbXBsZXRlbHkgZGlmZmVyZW50IGZyb20gb25lIGltcGxpZWQgaGVyZSkuDQo+ID4g DQo+ID4gSSBzdWdnZXN0IHRvIGNvbnNpZGVyIGNsYXJpZnlpbmcgdGhhdCB0aGVzZSAoYW5kIHBv c3NpYmx5IHNvbWUgDQo+ID4gb3RoZXIpIGZyYWdtZW50cyByZWZlciB0byB0aGUgUFcgQ1cgdXNh Z2UgYW5kIG5vdCB0byBmb3JtYXQgb3IgDQo+ID4gY29udGVudCBvZiB0aGUgQ1cuIFRoZXJlIGlz IGNsZWFybHkgbW9yZSB0aGFuIG9uZSB3YXkgdG8gZG8gdGhhdC4gDQo+ID4gSU1ITyBhbmQgRldJ VyB0aGUgbW9zdCB1bmFtYmlndW91cyBvbmUgd291bGQgYmUgdG8gZGVmaW5lIHRoZSANCj4gPiBy ZWxldmFudCBzdGF0ZSB2YXJpYWJsZXMgb2YgdGhlIFBXIGVuZCBwb2ludHMgKGNvbmZpZ3VyZWQs IA0KPiA+IHRyYW5zbWl0dGVkIGFuZCByZWNlaXZlZCBDLWJpdCkgYW5kIHRvIHVzZSB0aGVtIGlu IHRoZSBkZWZpbml0aW9uIG9mDQo+ID4gdGhlIHByb2NlZHVyZSwgYnV0IHRoaXMgaXMgZGVmaW5p dGVseSBmb3IgdGhlIGF1dGhvcnMgdG8gZGVjaWRlLiANCj4gW0xpemhvbmddIHdlIHdpbGwgY2hh bmdlIHRoZSAiY29udHJvbCB3b3JkIiB0byAidXNlIG9mIGNvbnRyb2wgd29yZCINCj4gaW4gdGhl IGRyYWZ0LCBhbmQgbWFrZSBpdCBjbGVhci4gDQo+IFtbW1Nhc2hhXV1dIFNvdW5kcyBPSy4NCj4g DQo+IA0KPiA+IA0KPiA+IE5pdHM6ICBOb25lIGZvdW5kIGJ5IHRoZSBJRVRGIGRyYWZ0IGNoZWNr ZXIuDQo+ID4gDQo+ID4gUmVnYXJkcywNCj4gPiAgICAgIFNhc2hhDQo+ID4gVGhpcyBlLW1haWwg bWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyAN Cj4gPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBw cm9wcmlldGFyeSB0byANCj4gPiBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZQ0KPiA+IGluZm9ybSB1cyBieSBlLW1haWws IHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgDQo+ID4gYWxs IGNvcGllcyB0aGVyZW9mLg0KPiA+IA0KPiA+IA0KPiBUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGlu dGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIA0KPiBpbmZvcm1hdGlv biB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byAN Cj4gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBwbGVhc2UNCj4gaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQg dGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCANCj4gYWxsIGNvcGllcyB0aGVyZW9mLiANCg== --=_alternative 00150F2248257A1E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNhc2hhLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WWVzLCBhbmQgdGhpcyBkcmFmdCB1c2Ug YSBsYWJlbCByZWxlYXNlDQpyZWNlaXZlZCB0byByZWxlYXNlIHRoZSBQVyBsYWJlbHMuIFdlIHdp bGwgdXBsb2FkIHRoZSByZXZpc2VkIHZlcnNpb24gYWZ0ZXINCnRoZSBlbmQgb2YgbGFzdCBjYWxs LiBUaGFuayB5b3UgZm9yIHRoZSB2YWx1YWJsZSBjb21tZW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpemhvbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5B bGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20m Z3Q7DQp3cm90ZSAyMDEyLzA2LzE1IDAzOjE2OjM2Ojxicj4NCjxicj4NCiZndDsgTGl6aG9uZyBo aSAoYWdhaW4pLDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBBZnRlciBy ZS1yZWFkaW5nIDQ0NDcgSSBoYXZlIGNvbWUgdG8gY29uY2x1c2lvbg0KdGhhdCBhIExhYmVsIDxi cj4NCiZndDsgV2l0aGRyYXcgbWVzc2FnZSBzZW50IGJ5IG9uZSBvZiB0aGUgUEVzIHRvIGl0cyBw ZWVyIHdvdWxkIGJlIDxicj4NCiZndDsgcmVzcG9uZGVkIHdpdGgvYWNrZWQgYnkgJm5ic3A7YSBM YWJlbCBSZWxlYXNlIG1lc3NhZ2UsIGJ1dCBpdCB3aWxsDQpub3QgPGJyPg0KJmd0OyB0cmlnZ2Vy IGEgTGFiZWwgV2l0aGRyYXcgbWVzc2FnZSBmcm9tIHRoZSBwZWVyIFBFLiBUaGlzIGlzIGJhc2Vk IG9uDQo8YnI+DQomZ3Q7IHRoZSB0ZXh0IHRoYXQgc2F5cyB0aGF0IFBXIGxhYmVscywgb25jZSBh ZHZlcnRpc2VkLCBhcmUgd2l0aGRyYXduDQppbjxicj4NCiZndDsganVzdCB0aHJlZSBjYXNlczo8 L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgMS4gV2hlbiB0aGUgbG9jYWwg UFcgZW5kcG9pbnQgaXMgZGVsZXRlZCBmcm9tDQp0aGUgUEUgY29uZmlndXJhdGlvbiA8L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgMi4gV2hlbiB0aGUgJm5ic3A7bG9jYWwg UFcgZW5kcG9pbnQgaXMgYWRtaW5pc3RyYXRpdmVseQ0KZGlzYWJsZWQgYnkgdGhlIHVzZXIgPC90 dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDMuIFdoZW4gdGhlIGxvY2FsIEFD IGdvZXMgRE9XTiAob25seSBpZiB0aGUgUFcNClN0YXR1cyBpcyBub3Qgc3VwcG9ydGVkKS48L3R0 PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IEFjdHVhbGx5IHRoZSBkcmFmdCBhZGRzIG9uZSBtb3Jl IGNhc2UgdG8gdGhpcw0KbGlzdC4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4m Z3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBSZWdhcmRz LDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO1Nhc2hhPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZn dDsgRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW48YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBK dW5lIDE0LCAyMDEyIDU6NDEgUE08YnI+DQomZ3Q7IFRvOiBMaXpob25nIEppbjxicj4NCiZndDsg Q2M6IGRyYWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLmFsbEB0b29scy5pZXRmLm9yZzsg cnRnLTxicj4NCiZndDsgYWRzQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGlldGYub3JnPGJyPg0K Jmd0OyBTdWJqZWN0OiBSRTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wd2UzLWNiaXQtbmVn b3RpYXRpb24tMDMudHh0PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4m Z3Q7IExpemhvbmcsIGhpIGFnYWluITwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgSSBoYXZl IHJlYWQgdGhlIHVwZGF0ZWQgZHJhZnQsIGFuZCBpdCBsb29rcyBPSy4NClRoZXJlIGp1c3QgYW4g PGJyPg0KJmd0OyBhZGRpdGlvbmFsIG1pbm9yIGNvbW1lbnQgb24gdGhlIHRleHQgdGhhdCBkZWFs cyB3aXRoICZuYnNwO3RvIE1TLVBXcy48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0 PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFRoZSBk cmFmdCBzYXlzIKGwV2hlbiBTLVBFIHJlY2VpdmVzIGEgbGFiZWwNCnJlcXVlc3QgbWVzc2FnZSBm cm9tIGEgPGJyPg0KJmd0OyByZW1vdGUgUEUsIGl0IE1VU1QgYWR2ZXJ0aXNlIHRoZSByZXF1ZXN0 IG1lc3NhZ2UgdG8gdGhlIG90aGVyIHJlbW90ZQ0KUEUuPGJyPg0KJmd0OyChsSBUaGUgaW50ZW50 aW9uIGlzIGNsZWFyLCBidXQgSSBzdWdnZXN0IHRvIGNvbnNpZGVyIGNoYW5naW5nIGl0DQp0byA8 YnI+DQomZ3Q7IHNvbWV0aGluZyBsaWtlIKGwV2hlbiBhbiBTLVBFIHJlY2VpdmVzIGEgbGFiZWwg cmVxdWVzdCBtZXNzYWdlIGZyb20NCjxicj4NCiZndDsgb25lIG9mIGl0cyBhZGphY2VudCBQRXMg KGJlIGl0IFMtUEUgb3IgYW5vdGhlciBULVBFKSwgaXQgTVVTVCBzZW5kDQphPGJyPg0KJmd0OyBt YXRjaGluZyBsYWJlbCByZXF1ZXN0IG1lc3NhZ2UgaXQgaXMgb3RoZXIgYWRqYWNlbnQgUEUgKGFn YWluLCBpdA0KPGJyPg0KJmd0OyBtYXkgYmUgYW4gUy1QRSBvciBhIFQtUEUpobEuIFRoaXMgbW9k aWZpY2F0aW9uLCBpZiBpdCBzdWl0cyB5b3UsDQo8YnI+DQomZ3Q7IHdvdWxkIHNlcnZlIHR3byBw dXJwb3Nlczo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgLSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SXQgd291bGQNCmNsYXJpZnkgdGhhdCBhbiBTLVBF IHJlbGF5cyBMYWJlbCBSZXF1ZXN0IDxicj4NCiZndDsgbWVzc2FnZXMgZnJvbSBvbmUgb2YgaXRz IG5laWdoYm9ycyB0byB0aGUgb3RoZXIgb25lLCBhbmQgZG9lcyBub3QNCjxicj4NCiZndDsgY2Fy ZSAoaW5kZWVkLCBpdCBkb2VzIG5vdCB1c3VhbGx5IGtub3cpIHdoZXRoZXIgdGhlc2UgbmVpZ2hi b3JzIGFyZQ0KPGJyPg0KJmd0OyBULVBFcyBvciBTLVBFczwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+Jmd0OyAtICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJdCBh dm9pZHMNCnRoZSB0ZXJtIKGwYWR2ZXJ0aXNlobEgd2hpY2gsIElNSE8sIGRvZXMgbm90IDxicj4N CiZndDsgYXBwbHkgdG8gd2hhdCBsYWJlbCByZXF1ZXN0IG1lc3NhZ2VzIGRvLjwvdHQ+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgUmVnYXJkcyw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTYXNoYTwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0 PiZndDsgRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gPGJyPg0KJmd0OyBTZW50OiBUaHVyc2Rh eSwgSnVuZSAxNCwgMjAxMiA2OjIzIFBNPGJyPg0KJmd0OyBUbzogJ0xpemhvbmcgSmluJzxicj4N CiZndDsgQ2M6IGRyYWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLmFsbEB0b29scy5pZXRm Lm9yZzsgcnRnLTxicj4NCiZndDsgYWRzQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGlldGYub3Jn PGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wd2UzLWNi aXQtbmVnb3RpYXRpb24tMDMudHh0PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4m Z3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBMaXpob25n IGhpLDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBMb3RzIG9mIHRoYW5r cyBmb3IgYSBwcm9tcHQgcmVzcG9uc2UuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBQbGVh c2Ugc2VlIHNvbWUgYW5zd2VycyBpbmxpbmUgYmVsb3cgKGJyb3duIGl0YWxpY3MpLjwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiZndDsgSSB3aWxsIHJlYWQgdGhlIG5ldyB2ZXJzaW9uIGFuZCBwcm92 aWRlIGFkZGl0aW9uYWwNCmNvbW1lbnRzIGxhdGVyLCA8YnI+DQomZ3Q7IGhvcGUgdGhpcyBpcyBP Sy48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFJlZ2FyZHMsPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2FzaGE8L3R0PjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD4mZ3Q7IEZyb206IExpemhvbmcgSmluIFttYWlsdG86bGl6aG9uZy5qaW5A enRlLmNvbS5jbl0NCjxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIEp1bmUgMTQsIDIwMTIgMTI6 NDggUE08YnI+DQomZ3Q7IFRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjxicj4NCiZndDsgQ2M6IGRy YWZ0LWlldGYtcHdlMy1jYml0LW5lZ290aWF0aW9uLmFsbEB0b29scy5pZXRmLm9yZzsgcnRnLTxi cj4NCiZndDsgYWRzQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGlldGYub3JnPGJyPg0KJmd0OyBT dWJqZWN0OiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wd2UzLWNiaXQtbmVnb3RpYXRp b24tMDMudHh0PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IEhpIFNhc2hh LCA8YnI+DQomZ3Q7IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSB2YWx1YWJsZSBjb21tZW50 cy4gUGxlYXNlIHNlZSBteSByZXBseQ0KPGJyPg0KJmd0OyBpbmxpbmUgYmVsb3cuIDxicj4NCiZn dDsgSSBhbHNvIGF0dGFjaGVkIHRoZSBtb2RpZmllZCB2ZXJzaW9uIGZvciB5b3VyIGNoZWNrIGFu ZCByZWZlcmVuY2UuDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyA8YnI+DQomZ3Q7IExp emhvbmcgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg QWxleGFuZGVyIFZhaW5zaHRlaW4gJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t Jmd0OyB3cm90ZQ0KPGJyPg0KJmd0OyAyMDEyLzA2LzE0IDEzOjIzOjU5Ojxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IEhlbGxvLDxicj4NCiZndDsgJmd0OyBJIGhhdmUgYmVlbiBzZWxlY3RlZCBh cyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCnRoaXMgPGJyPg0KJmd0OyAm Z3Q7IGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJv dXRpbmcgb3INCjxicj4NCiZndDsgJmd0OyByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZA0KSUVTRyA8YnI+DQomZ3Q7ICZndDsgcmV2 aWV3LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0 bw0KdGhlIDxicj4NCiZndDsgJmd0OyBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsDQpwbGVhc2Ugc2VlIDxicj4NCiZndDsgJmd0 OyBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGluZy5odG1sPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJp bWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nDQo8YnI+DQomZ3Q7ICZndDsgQURzLCBp dCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGgN CmFueSA8YnI+DQomZ3Q7ICZndDsgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5 b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0bw0KPGJyPg0KJmd0OyAmZ3Q7IHJlc29sdmUgdGhlbSB0 aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgRG9jdW1lbnQ6ICZuYnNwOyBkcmFmdC1pZXRmLXB3ZTMtY2JpdC1u ZWdvdGlhdGlvbi0wMy50eHQ8YnI+DQomZ3Q7ICZndDsgUmV2aWV3ZXI6ICZuYnNwOyBBbGV4YW5k ZXIgKCZxdW90O1Nhc2hhJnF1b3Q7KSBWYWluc2h0ZWluPGJyPg0KJmd0OyAmZ3Q7IFJldmlldyBE YXRlOiAmbmJzcDsgMTMuMDYuMTI8YnI+DQomZ3Q7ICZndDsgSUVURiBMQyBFbmQgZGF0ZTogJm5i c3A7MTUuMDYuMTI8YnI+DQomZ3Q7ICZndDsgSW50ZW5kZWQgU3RhdHVzOiAmbmJzcDtTdGFuZGFy ZHMgVHJhY2sgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg U1VNTUFSWTo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCB0aGUg ZG9jdW1lbnQgaXMgZ2VuZXJhbGx5IGluIGdvb2Qgc2hhcGUgYW5kIGFsbW9zdA0KPGJyPg0KJmd0 OyAmZ3Q7IHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gPGJyPg0KJmd0OyAmZ3Q7IEhvd2V2ZXIsIEkg aGF2ZSBzb21lIG1pbm9yIHRlY2huaWNhbCBjb25jZXJucyBhcyB3ZWxsIGFzIHNvbWUNCjxicj4N CiZndDsgJmd0OyBlZGl0b3JpYWwgb25lcyB3aGljaCwgSU1ITywgc2hvdWxkIGJlIHJlc29sdmVk IGJlZm9yZSBwdWJsaWNhdGlvbi48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE1BSk9S IElTU1VFUzogJm5ic3A7Tm9uZTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTUlOT1Ig SVNTVUVTOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGVjaG5pY2FsOjxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7VGhlIGFjdHVhbCBDLWJpdCBuZWdvdGlhdGlv biBwcm90b2NvbCAoZXh0ZW5zaW9uIG9mIHdoYXQNCmhhcyBiZWVuIDxicj4NCiZndDsgJmd0OyBk ZWZpbmVkIGluIFJGQyA0NDQ3KSBpcyBwcmVzZW50ZWQgaW4gdGhlIGRvY3VtZW50IDMgKHRocmVl KSB0aW1lczo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOy0gJm5ic3A7SW4g U2VjdGlvbiAzLCBpdGVtcyBpKSB0byBpaWkpIGFuZCB0aGUgcGFyYWdyYXBoDQppbW1lZGlhdGVs eSA8YnI+DQomZ3Q7ICZndDsgZm9sbG93aW5nIHRoZXNlIGl0ZW1zLiBUaGlzIHRleHQgdXNlcyB0 aGUgSUVURiBjYXBpdGFsaXplZCA8YnI+DQomZ3Q7ICZndDsgcmVxdWlyZW1lbnQgbGV2ZWwgdGVy bXMgKE1VU1QpIGFuZCBoZW5jZSBsb29rcyBsaWtlIHRoZSBub3JtYXRpdmUNCjxicj4NCiZndDsg Jmd0OyBkZWZpbml0aW9uIG9mIHRoZSBwcm90b2NvbDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7LSAmbmJzcDsgSW4gdGhlIHNhbWUgU2VjdGlvbiwgaXRlbXMgMSB0byA1LiBU aGlzIHRleHQgcmVmZXJzDQp0byBhbiAoSU1ITzxicj4NCiZndDsgJmd0OyBub3QgdmVyeSBpbmZv cm1hdGl2ZSkgRmlndXJlIDEgYnV0IGRvZXMgbm90IGNvbnRhaW4gdGhlIElFVEYNCjxicj4NCiZn dDsgJmd0OyBjYXBpdGFsaXplZCByZXF1aXJlbWVudCBsZXZlbCB0ZXJtcy4gPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDstIEluIEFwcGVuZGl4IEEuIFRoaXMgQXBwZW5kaXgg Y29udGFpbnMgYSBibG9jayBkaWFncmFtDQpvZiB0aGUgQy08YnI+DQomZ3Q7ICZndDsgYml0IG5l Z290aWF0aW9uIHByb2NlZHVyZSB0aGF0IGZvbGxvd3MvaWxsdXN0cmF0ZXMgdGhlIHRleHQgaW4N Cml0ZW1zPGJyPg0KJmd0OyAmZ3Q7IDEpIC0gNykgb2YgU2VjdGlvbiAzLjxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHByZXN1 bWFibHkgbm9ybWF0aXZlIGRlZmluaXRpb24NCmFuZCB0d288YnI+DQomZ3Q7ICZndDsgb3RoZXJz IGlzIHRoYXQgdGhlIGZpcnN0IG9uZSBleHBsaWNpdGx5IHN0YXRlczogJm5ic3A7JnF1b3Q7TG9j YWwNClBFIE1VU1Qgc2VuZDxicj4NCiZndDsgJmd0OyBhIGxhYmVsIHdpdGhkcmF3IG1lc3NhZ2Ug dG8gcmVtb3RlIFBFIGlmIGl0IGhhcyBwcmV2aW91c2x5IHNlbnQNCmEgPGJyPg0KJmd0OyAmZ3Q7 IGxhYmVsIG1hcHBpbmcsIGFuZCB3YWl0IHVudGlsIHJlY2VpdmluZyBhIGxhYmVsIHJlbGVhc2Ug ZnJvbQ0KdGhlIDxicj4NCiZndDsgcmVtb3RlIFBFJnF1b3Q7LiAmbmJzcDs8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7KE5vdGU6ICZxdW90O0xvY2FsIFBFJnF1b3Q7IGluIHRoZSBkb2N1bWVudCBpcyB0 aGUgUEUgdGhhdA0KaGFzIGNoYW5nZWQgPGJyPg0KJmd0OyAmZ3Q7IGNvbmZpZ3VyYXRpb24gb2Yg Q1cgdXNhZ2UgKGluIHRoaXMgY2FzZSwgZnJvbSBOT1QgUFJFRkVSUkVEIHRvDQpQUkVGRVJSRUQu KTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7VGhlIHR3byBvdGhlciBmcmFn bWVudHMgZG8gbm90IG1lbnRpb24gd2FpdGluZyBmb3IgdGhlDQpsYWJlbCA8YnI+DQomZ3Q7ICZn dDsgcmVsZWFzZSBtZXNzYWdlIGZyb20gdGhlIHJlbW90ZSBQRSwgaS5lLiBhcmUgbm90IGZ1bGx5 IGNvbnNpc3RlbnQNCjxicj4NCiZndDsgJmd0OyB3aXRoIHRoZSBub3JtYXRpdmUgb25lLjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7TXkgaW50ZXJwcmV0YXRpb24gb2YgdGhl IExEUCBwcm9jZWR1cmVzIGFzIHBlciBSRkMgNTAzNg0KaXMgdGhhdCBhbiA8YnI+DQomZ3Q7ICZn dDsgTFNSIHRoYXQgc2VuZHMgYSBsYWJlbCB3aXRoZHJhdyBtZXNzYWdlIE1VU1Qgd2FpdCBmb3Ig dGhlIDxicj4NCiZndDsgJmd0OyBhY2tub3dsZWRnaW5nICZuYnNwOyAmbmJzcDtsYWJlbCByZWxl YXNlIG1lc3NhZ2UgZnJvbSB0aGUgcGVlciwNCmkuZS4gdGhlIDxicj4NCiZndDsgJmd0OyBwcmVz dW1lZCBub3JtYXRpdmUgZGVmaW5pdGlvbiBpcyBjb3JyZWN0LiBBbmQgaW4gYW55IGNhc2UgSSB0 aGluaw0KPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgYWxsIHRoZSBhbGwgdGhlIGRlc2NyaXB0aW9ucyBv ZiB0aGUgcHJvdG9jb2wgKHRleHRzLCBibG9jaw0KPGJyPg0KJmd0OyAmZ3Q7IGRpYWdyYW1zIGV0 Yy4pIG11c3QgYmUgZnVsbHkgY29uc2lzdGVudC4gPGJyPg0KJmd0OyBbTGl6aG9uZ10gYWdyZWUs IGFuZCB3ZSB3aWxsIGNoYW5nZSB0aGUgc2Vjb25kIGFuZCB0aGlyZCB0ZXh0IDxicj4NCiZndDsg ZnJhZ21lbnQgdG8gcmVmbGVjdCB0aGlzLiA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PiZndDsgW1tbU2FzaGFdXV0gT0suIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBhbHNv IHN1Z2dlc3QgdG8gY2xhcmlmeSB3aGV0aGVyIHNlbmRpbmcgdGhlIGxhYmVsIHJlbGVhc2UgbWVz c2FnZQ0KPGJyPg0KJmd0OyAmZ3Q7IGJ5IHRoZSBsb2NhbCBQRSBhYm92ZSBzaG91bGQgd2FpdCBm b3IgdGhlIGxhYmVsIHJlbGVhc2UgbWVzc2FnZQ0KZnJvbTxicj4NCiZndDsgJmd0OyB0aGUgcmVt b3RlIFBFIGlmIGxhYmVsIHdpdGhkcmF3IG1lc3NhZ2UgaGFzIGJlZW4gc2VudC4gJm5ic3A7SQ0K ZXhwZWN0IDxicj4NCiZndDsgJmd0OyB0aGF0LCB1cG9uIHJlY2VpdmluZyB0aGUgbGFiZWwgd2l0 aGRyYXcgbWVzc2FnZSBmcm9tIHRoZSBsb2NhbA0KUEUsIDxicj4NCiZndDsgJmd0OyB0aGUgcmVt b3RlIG9uZSwgaW4gYWRkaXRpb24gdG8gYWNrbm93bGVkZ2luZyBpdCB3aXRoIGEgbGFiZWwNCnJl bGVhc2U8YnI+DQomZ3Q7ICZndDsgbWVzc2FnZSB3b3VsZCBhbHNvIGltbWVkaWF0ZWx5IHNlbmQg aXRzIG93biBsYWJlbCB3aXRoZHJhdyBtZXNzYWdlDQo8YnI+DQomZ3Q7ICZndDsgdG8gdGhlIGxv Y2FsIFBFIHdoaWNoIHdvdWxkIHRoZW4sIGluIGl0cyB0dXJuLCBzZW5kIGxhYmVsIHJlbGVhc2UN Cjxicj4NCiZndDsgJmd0OyBtZXNzYWdlIGJhY2suIDxicj4NCiZndDsgW0xpemhvbmddIHRoZSBy ZW1vdGUgb25lIHdpbGwgbm90IHNlbmQgbGFiZWwgd2l0aGRyYXcgYWZ0ZXIgPGJyPg0KJmd0OyBh Y2tub3dsZWRnaW5nIHdpdGggbGFiZWwgcmVsZWFzZSwgYmVjYXVzZSAmcXVvdDtsaWJlcmFsIGxh YmVsIHJldGVudGlvbiZxdW90Ow0KPGJyPg0KJmd0OyBtb2RlIGlzIGFwcGxpZWQuIDwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBUaGUgc2VuZGluZyBsYWJlbCByZWxlYXNl IG1lc3NhZ2UgYnkgbG9jYWwgUEUNCmlzIG5vdCBuZWNlc3NhcnkgdG8gPGJyPg0KJmd0OyB3YWl0 IGZvciB0aGUgcmVsZWFzZSBmcm9tIHJlbW90ZS4gV2lsbCBjbGFyaWZ5IHRoaXMgaW4gdGhlIGRy YWZ0Lg0KPGJyPg0KJmd0OyBbW1tTYXNoYV1dXSBJIGFtIG5vdCBzdXJlIGxpYmVyYWwgbGFiZWwg cmV0ZW50aW9uIHJlYWxseSBhcHBsaWVzIDxicj4NCiZndDsgaGVyZSCoQyBJTUhPIGl0IGp1c3Qg c2F5cyB0aGF0IHVudXNlZCBsYWJlbCBhZHZlcnRpc2VtZW50cyByZWNlaXZlZA0KPGJyPg0KJmd0 OyBieSBhbiBORSBhcmUgcmV0YWluZWQuIEFuZCBpdCBzZWVtcyB0aGF0IFJGQyA0NDcgaXMgbm90 IHZlcnkgY2xlYXINCjxicj4NCiZndDsgb24gcHJvY2VkdXJlcyBmb3IgdGVhcmluZyBkb3duIGEg UFcuIEJ1dCBhcyBsb25nIGFzIHlvdSBjbGFyaWZ5IHRoaXM8YnI+DQomZ3Q7IHBvaW50LCBpdCBp cyBub3QgcmVhbGx5IGltcG9ydGFudCBmb3IgdGhpcyBkcmFmdC48L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBFZGl0 b3JpYWw6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsxLiBXaXRoIHJlZ2Fy ZCB0byBtdWx0aS1zZWdtZW50IFBXcywgdGhlIGRyYWZ0IHNheXMgdGhhdA0KJnF1b3Q7dGhlIDxi cj4NCiZndDsgJmd0OyAobGFiZWwpIHJlcXVlc3QgbWVzc2FnZSBNVVNUIGJlIHByb2Nlc3NlZCBp biBvcmRlcmVkIG1vZGUmcXVvdDsuDQpJdCBpcyA8YnI+DQomZ3Q7ICZndDsgbm90IGNsZWFyIHRv IG1lIHdoZXRoZXIgdGhpcyByZWZlcnMgdG8gb3JkZXJlZCBsYWJlbCBkaXN0cmlidXRpb24NCjxi cj4NCiZndDsgJmd0OyBtb2RlIG9mIExEUCBhcyBkZWZpbmVkIGluIFJGQyA1MDM2LCBvciB0byBz b21ldGhpbmcgZWxzZS4gQXQNCnRoZSA8YnI+DQomZ3Q7ICZndDsgc2FtZSB0aW1lLCB0aGUgcHJv Y2VkdXJlIGRlZmluZWQgaW4gdGhlIGRyYWZ0IGlzIGNvbXBsaWFudCB3aXRoDQp0aGUgPGJyPg0K Jmd0OyAmZ3Q7IGNvbW1vbiBQVyBsYWJlbCBkaXN0cmlidXRpb24gcHJvY2VkdXJlcyBhcyBkZWZp bmVkIGluIFJGQyA2MDczLA0Kc28gSTxicj4NCiZndDsgJmd0OyBzdWdnZXN0IHRvIGNvbnNpZGVy IHJlZmVyZW5jaW5nIFJGQyA2MDczICh0aGVyZSBpcyBubyBzdWNoIHJlZmVyZW5jZTxicj4NCiZn dDsgJmd0OyBpbiB0aGUgZHJhZnQpIGluc3RlYWQgb2YgdXNpbmcgYSBwb3RlbnRpYWxseSBtaXNs ZWFkaW5nIHRlcm0uDQpJIGFsc288YnI+DQomZ3Q7ICZndDsgd29uZGVyIGlmIHRoaXMgZHJhZnQg c2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGFzIHVwZGF0aW5nIFJGQw0KNjA3MyA8YnI+DQomZ3Q7 ICZndDsgaW4gYWRkaXRpb24gdG8gdXBkYXRpbmcgUkZDIDQ0NDcuIDxicj4NCiZndDsgW0xpemhv bmddIHllcywgb3JkZXJlZCBtb2RlIGZvbGxvd3Mgb3JkZXJlZCBsYWJlbCBkaXN0cmlidXRpb24g bW9kZQ0KPGJyPg0KJmd0OyBpbiBSRkM1MDM2LiBBbmQgSSBhZ3JlZSwgcmVmZXJlbmNpbmcgUkZD NjA3MyB3b3VsZCBiZSBtb3JlIGNsZWFyLg0KPGJyPg0KJmd0OyBBbmQgeWVzLCB0aGUgZHJhZnQg aXMgYWxzbyB1cGRhdGluZyBSRkM2MDczLiA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PiZndDsgW1tbU2FzaGFdXV0gSSBhbSBub3Qgc3VyZSBvcmRlcmVkIGxhYmVsIGRpc3RyaWJ1 dGlvbg0KaW4gNTAzNiByZWFsbHkgPGJyPg0KJmd0OyBhcHBsaWVzIGhlcmUsIGJlY2F1c2UgbXkg cmVhZGluZyBvZiA1MDM2IHN1Z2dlc3RzIHRoYXQgaXQgaXMgdXNlZA0KPGJyPg0KJmd0OyAob3Ig bm90IHVzZWQpIHBlciBMU1IuICZuYnNwO0kgc3VzcGVjdCB0aGF0IHRoaXMgbWF5IGJlIHRoZSBy ZWFzb24NCmZvciA8YnI+DQomZ3Q7IHRoZSBhdXRob3JzIG9mIDYwNzMgbm90IHRvIG1lbnRpb24g aXQgYnV0IGV4cGxpY2l0bHkgZGVmaW5lIHRoZSA8YnI+DQomZ3Q7IHByb2Nlc3MgaW5zdGVhZC4g QnV0LCBhcyBJIGhhdmUgc2FpZCwgdGhlIHByb2NlZHVyZSB5b3Whr3ZlIHNwZWNpZmllZA0KbG9v a3MgT0suPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsyLiBBcyBtZW50aW9uZWQgYWJv dmUsIHRoZXJlIGFyZSB0d28gdGV4dCBmcmFnbWVudHMgZGVmaW5pbmcNCnRoZSA8YnI+DQomZ3Q7 ICZndDsgbmV3IEMtYml0IG5lZ290aWF0aW9uIHByb2NlZHVyZSBpbiB0aGUgZHJhZnQuIEkgc3Vn Z2VzdCB0byBjb25zaWRlcg0KPGJyPg0KJmd0OyAmZ3Q7IG1lcmdpbmcgdGhlbSBpbnRvIGEgc2lu Z2xlIHRleHQgdGhhdCBjb25zaXN0ZW50bHkgdXNlcyB0aGUgSUVURg0KPGJyPg0KJmd0OyAmZ3Q7 IGNhcGl0YWxpemVkIHRlcm1zIGZvciByZXF1aXJlbWVudCBsZXZlbHMgd2hpbGUgYXZvaWRpbmcg c3VjaA0KdmFndWUgPGJyPg0KJmd0OyAmZ3Q7IHRlcm1zIGFzICZxdW90O2NvdWxkJnF1b3Q7ICZu YnNwOyhlLmcuLCAmcXVvdDsgUEUyIGNvdWxkIHdhaXQNCmZvciBQRTEgbGFiZWwgJm5ic3A7Ymlu ZGluZyA8YnI+DQomZ3Q7ICZndDsgYmVmb3JlIHNlbmRpbmcgaXRzIGxhYmVsIGJpbmRpbmcgd2l0 aCBDLWJpdCBzZXQmcXVvdDspLiBIYXZpbmcNCmEgc2luZ2xlIDxicj4NCiZndDsgJmd0OyB0ZXh0 IGZyYWdtZW50IHRoYXQgZGVmaW5lcyB0aGUgcHJvY2VkdXJlIHdvdWxkIGFsc28gcmVkdWNlIHRo ZQ0KPGJyPg0KJmd0OyAmZ3Q7IHBvdGVudGlhbCBmb3IgaW5jb25zaXN0ZW5jaWVzLiA8YnI+DQom Z3Q7IFtMaXpob25nXSB0aGUgZmlyc3QgdGV4dCBmcmFnbWVudCBkZWZpbmVzIHRoZSByZXF1aXJl bWVudCwgYW5kIHRoZQ0KPGJyPg0KJmd0OyBzZWNvbmQgZ2l2ZXMgYW4gdXNlY2FzZSBhY2NvcmRp bmcgdG8gdGhlIGZpcnN0IHRleHQuIFdoYXQgaWYgd2UgbW92ZTxicj4NCiZndDsgdGhlIHVzZSBj YXNlIHRvIGFub3RoZXIgc3ViLXNlY3Rpb24sIHNvIGFzIHRvIG1ha2UgaXQgbW9yZSBjbGVhcj8N CjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBbW1tTYXNoYV1dXSBJIHdv bmRlciBpZiB0aGUgc2Vjb25kIGZyYWdtZW50IHJlYWxseQ0KYWRkcyBtdWNoIHRvIHRoZSA8YnI+ DQomZ3Q7IGZpcnN0IG9uZSAod2hpY2ggZGVmaW5lcyB0aGUgcHJvY2VkdXJlKS4gQnV0IGFzIGxv bmcgYXMgKDEpIGl0IGlzDQo8YnI+DQomZ3Q7IGNsZWFybHkgc3BlY2lmaWVkIHdoYXQgaXMgdGhl IG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9uIGFuZCB3aGF0IGlzDQo8YnI+DQomZ3Q7IHRoZSB1c2Ug Y2FzZSwgYW5kIChiKSB0aGUgdXNlIGNhc2UgaXMgZnVsbHkgY29uc2lzdGVudCB3aXRoIHRoZSA8 YnI+DQomZ3Q7IG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9uLCBpdCBpcyBPSy4gJm5ic3A7PC90dD48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDszLiBUaGUgdGV4dCwgYXMgd3JpdHRlbiwgZG9lcyBu b3QgY2xlYXJseSBkaXN0aW5ndWlzaCBiZXR3ZWVuDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7IFBXIGNv bnRyb2wgd29yZCAoYXMgYSBmaWVsZCBpbiB0aGUgcGFja2V0KSBhbmQgdGhlIFBXIGNvbnRyb2wN CndvcmQgPGJyPg0KJmd0OyAmZ3Q7ICp1c2UqIGluIGEgUFcgaW5zdGFuY2UuIEluIG1vc3QgY2Fz ZXMgdGhpcyBpcyBub3QgYSBwcm9ibGVtLA0Kc2luY2UgPGJyPg0KJmd0OyAmZ3Q7IHRoZSBkcmFm dCBpcyBhbGwgYWJvdXQgdGhlIENXIHVzZS4gSG93ZXZlciwgdGhlcmUgYXJlIHNldmVyYWwNCmNh c2VzIDxicj4NCiZndDsgJmd0OyB3aGVuIHRoaXMgbWF5IHJlc3VsdCBpbiBtaXNpbnRlcnByZXRh dGlvbiwgZS5nLiAodGhlIG5leHQgdHdvDQppdGVtcyA8YnI+DQomZ3Q7ICZndDsgYXJlIGNvcHkg YW5kIHBhc3RlIHF1b3RlcyBmcm9tIHRoZSBkcmFmdCk6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmbmJzcDstICZuYnNwOyAmbmJzcDtXaGVuIHRoZSBwZWVyIFBFIHN1Y2Nlc3NmdWxs eSBwcm9jZXNzZWQNCnRoZSBsYWJlbCB3aXRoZHJhdyBhbmQ8YnI+DQomZ3Q7ICZndDsgbGFiZWwg cmVsZWFzZSwgYW5kIHJlbW92ZWQgdGhlIHJlbW90ZSBsYWJlbCBiaW5kaW5nLCBpdCBNVVNUDQpy ZXNldCA8YnI+DQomZ3Q7ICZndDsgaXRzIGxvY2FsIGNvbnRyb2wgd29yZCB3aXRoIHRoZSBjb25m aWd1cmVkIG9uZS4uLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOy0gV2hl biBMb2NhbCBQRSBjaGFuZ2VzIGl0cyBjb250cm9sIHdvcmQgZnJvbSBQUkVGRVJSRUQNCnRvIE5P VCBQUkVGRVJSRUQuLi48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IChQbGVhc2Ugbm90 ZSBhbHNvIHRoYXQgKnByZWZlcnJlZCogUFcgY29udHJvbCB3b3JkIGlzIGRlZmluZWQNCmluIFJG Qzxicj4NCiZndDsgJmd0OyA0Mzg1LCBidXQgdGhlIG1lYW5pbmcgaXMgY29tcGxldGVseSBkaWZm ZXJlbnQgZnJvbSBvbmUgaW1wbGllZA0KaGVyZSkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBJIHN1Z2dlc3QgdG8gY29uc2lkZXIgY2xhcmlmeWluZyB0aGF0IHRoZXNlIChhbmQgcG9z c2libHkgc29tZQ0KPGJyPg0KJmd0OyAmZ3Q7IG90aGVyKSBmcmFnbWVudHMgcmVmZXIgdG8gdGhl IFBXIENXIHVzYWdlIGFuZCBub3QgdG8gZm9ybWF0IG9yDQo8YnI+DQomZ3Q7ICZndDsgY29udGVu dCBvZiB0aGUgQ1cuIFRoZXJlIGlzIGNsZWFybHkgbW9yZSB0aGFuIG9uZSB3YXkgdG8gZG8gdGhh dC4NCjxicj4NCiZndDsgJmd0OyBJTUhPIGFuZCBGV0lXIHRoZSBtb3N0IHVuYW1iaWd1b3VzIG9u ZSB3b3VsZCBiZSB0byBkZWZpbmUgdGhlDQo8YnI+DQomZ3Q7ICZndDsgcmVsZXZhbnQgc3RhdGUg dmFyaWFibGVzIG9mIHRoZSBQVyBlbmQgcG9pbnRzIChjb25maWd1cmVkLCA8YnI+DQomZ3Q7ICZn dDsgdHJhbnNtaXR0ZWQgYW5kIHJlY2VpdmVkIEMtYml0KSBhbmQgdG8gdXNlIHRoZW0gaW4gdGhl IGRlZmluaXRpb24NCm9mPGJyPg0KJmd0OyAmZ3Q7IHRoZSBwcm9jZWR1cmUsIGJ1dCB0aGlzIGlz IGRlZmluaXRlbHkgZm9yIHRoZSBhdXRob3JzIHRvIGRlY2lkZS4NCjxicj4NCiZndDsgW0xpemhv bmddIHdlIHdpbGwgY2hhbmdlIHRoZSAmcXVvdDtjb250cm9sIHdvcmQmcXVvdDsgdG8gJnF1b3Q7 dXNlDQpvZiBjb250cm9sIHdvcmQmcXVvdDs8YnI+DQomZ3Q7IGluIHRoZSBkcmFmdCwgYW5kIG1h a2UgaXQgY2xlYXIuIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBbW1tT YXNoYV1dXSBTb3VuZHMgT0suPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOaXRzOiAmbmJzcDtO b25lIGZvdW5kIGJ5IHRoZSBJRVRGIGRyYWZ0IGNoZWNrZXIuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw Ozxicj4NCiZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO1Nhc2hhPGJyPg0KJmd0OyAmZ3Q7IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQg Zm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMNCjxicj4NCiZndDsgJmd0OyBpbmZv cm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFy eQ0KdG8gPGJyPg0KJmd0OyAmZ3Q7IEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwNCnBsZWFzZTxicj4NCiZndDsgJmd0OyBpbmZvcm0g dXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwN CmFuZCA8YnI+DQomZ3Q7ICZndDsgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFRo aXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQNCm9ubHkgYW5k IGNvbnRhaW5zIDxicj4NCiZndDsgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFu ZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8NCjxicj4NCiZndDsgRUNJIFRlbGVjb20uIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2U8YnI+ DQomZ3Q7IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQNCjxicj4NCiZndDsgYWxsIGNvcGllcyB0aGVyZW9mLiA8L3R0Pjwv Zm9udD4NCg== --=_alternative 00150F2248257A1E_=-- From enkechen@cisco.com Wed Jun 20 17:19:43 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8611E80A5 for ; Wed, 20 Jun 2012 17:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzN+tvyzGMMC for ; Wed, 20 Jun 2012 17:19:42 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC2B11E8079 for ; Wed, 20 Jun 2012 17:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=7083; q=dns/txt; s=iport; t=1340237982; x=1341447582; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=eP1MEt+Pupi84EhNcHFgegTFzpxvZfQfnQudptYkRoc=; b=E5fPJ4NCnQ77uW/3KG6tNxvru/7EAK6CMtYGEH2sfp18eoe6N+sKyXzx e1AS9tuQvkD6VaZcezsO3bDFptpvZ09jAjEfMMBjiE+pUdrfQEwS+rkM/ UkEbGew8cTffu8+i+EI0uE6SIWWBd1526GFT4PjaoIqZUc/AWc1DcsvYG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKxn4k+rRDoH/2dsb2JhbABFtViBB4IYAQEBBBIBJUABEAsOBgQJFg8JAwIBAgFFBg0BBwEBBRIHh2gMmWKgMYsuJ4V0A4hGjGSOG4Fmgn+BOA X-IronPort-AV: E=Sophos;i="4.77,447,1336348800"; d="scan'208";a="49575021" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 21 Jun 2012 00:19:42 +0000 Received: from dhcp-171-71-139-24.cisco.com (dhcp-171-71-139-24.cisco.com [171.71.139.24]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5L0Jgug003297; Thu, 21 Jun 2012 00:19:42 GMT Message-ID: <4FE268F2.9020904@cisco.com> Date: Wed, 20 Jun 2012 17:21:06 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Geoff Huston References: <71002B69-8E77-4392-82C3-D6AA5EA16FAE@apnic.net> <4FD7D23C.9050606@cisco.com> <60DA541E-D147-4AFC-9617-633EFBEAE7A6@apnic.net> In-Reply-To: <60DA541E-D147-4AFC-9617-633EFBEAE7A6@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-rfc4893bis.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-idr-rfc4893bis-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 00:19:43 -0000 Geoff, Will make the changes as you suggested. Thanks. -- Enke On 6/12/12 5:44 PM, Geoff Huston wrote: > On 13/06/2012, at 9:35 AM, Enke Chen wrote: > >> Hi, Geoff: >> >> Thanks for your review. Please see my replies below. >> >> On 6/11/12 9:43 PM, Geoff Huston wrote: >>> (resent with correct draft author address added) >>> >>> >>> Hello, >>> >>> I have been selected as the Routing Directorate reviewer for this draft. >>> The Routing Directorate seeks to review all routing or routing-related >>> drafts as they pass through IETF last call and IESG review, and >>> sometimes on special request. The purpose of the review is to provide >>> assistance to the Routing ADs. For more information about the Routing >>> Directorate, please see http://www.ietf.org/iesg/directorate/routing.html >>> >>> Although these comments are primarily for the use of the Routing ADs, it >>> would be helpful if you could consider them along with any other IETF >>> Last Call comments that you receive, and strive to resolve them through >>> discussion or by updating the draft. >>> >>> Document: draft-idr-rfc4893bis-06.txt >>> Reviewer: Geoff Huston >>> Review Date: 12 June 2012 >>> IETF LC End Date: mnot known >>> Intended Status: Standards Track >>> >>> Summary: >>> >>> I have some minor concerns about this document that I think should be >>> resolved before publication. >>> >>> Comments: >>> >>> The draft provides a small number of updates to RFC4893, fixing up some >>> residual grammatical errors, clarifying, or altering some of the >>> normative text, and providing a new section on error handling. >>> >>> The document is clear, and easily understood. >>> >>> Major Issues: >>> >>> none found >>> >>> Minor Issues: >>> >>> 1. Ambiguity in the specification >>> >>> The last sentence of the final paragraph of section 3 states >>> >>> "This AS number [referring to AS_TRANS] is also placed in the "My >>> Autonomous System" field of the OPEN message originated by a NEW BGP >>> speaker, if the speaker does not have a (globally unique) 2-octet AS >>> number." >>> >>> is this "if" an instance of "if and only if"? Or not? >>> >>> i.e. if the local BGP speaker is within AS 10 (say) and it is 4-octet >>> capable, then does the preceding text require that the BGP speaker >>> MUST use the value "10" as "My Autonomous System" number, or >>> MAY use the number 10 (or, alternatively MAY use the number 23456), >>> or MUST NOT use the number 10 at all? >>> >>> While this is not a major issue, some additional clarification appears >>> to be appropriate here. >> It is "if and only if". >> >> Would it be better if we change "if the speaker ..." to "in the case that the speaker..."? > no - because you also need to clarify the other case (namely that the speaker has a 2-octet AS number) > > Might I suggest that you consider the following" > > "This AS number is also placed in the "My Autonomous System" field of the OPEN message originated by a NEW BGP speaker, if and only if the speaker does not have a 2-octet AS number." > > 1) this covers all cases with explicit specification of what to do > 2) it also encompasses those cases when the local speaker is using a private (non-globally unique) 2-octet AS number > > >>> 2. MAY, SHALL, or SHOULD? >>> >>> Section 4.1 states: >>> >>> "A BGP speaker that supports 4-octet Autonomous System numbers SHALL >>> advertise this to its peers using the BGP Capability Advertisements." >>> >>> (RFC 4893 used SHOULD) >>> >>> Yet Section 7 (Transition) states: >>> >>> "To simplify transition, this document assumes that an Autonomous >>> System could start using a 4-octet AS number only after all the BGP >>> speakers within that Autonomous System have been upgraded to support >>> 4-octet AS numbers." >>> >>> I observe that during an upgrade of routers within an AS it may be >>> the case that the network administrator would like to upgrade the >>> capability of all BGP speakers within the AS to support 4-octet AS >>> numbers and then and only then have the BGP speakers announce this >>> support to their peers. i.e. having the capability to operate in NEW >>> mode need not necessarily imply a mandatory (SHALL) announcement to >>> the peers of a BGP speaker. Or was this the intended effect of this >>> change from SHOULD to SHALL in the document? >> The change from "SHOULD" to "SHALL" was to address a comment/observation that this capability is different from other bgp capabilities in that this capability is needed universally and should be enabled with just software upgrade. So it is more about the "default" vs "non-default" behavior. >> >> With that said, I am not sure whether we should revert back to "SHOULD". Please advise. > My observation was that it appears to implicitly suggest that the capability should be announced at the time that the router is 4-octet capable, yet the section 7 transition advice appears to contradict this, in so far as it seems to suggest waiting to all routers arre 4-octet capable. > > I think you can leave the SHALL in section 4.1 if you add additional text in section 7. > > YOu may wish to consider the following test in Section 7: > > "Where an Autonomous System is using a 2-octet AS number, then the BGP speakers within that Autonomous SYSTEM MAY be upgraded to support 4-octet AS numbers on a piecemeal basis. There is no requirement for a coordinated upgrade of this 4-octet AS capability in this case. However, if an Autonomous System wishes to use a 4-octet AS number as its own AS number, then this document assumes that an Autonomous System can use a 4-octet AS number only after all the BGP speakers within that Autonomous System have been upgraded to support 4-octet AS Numbers." > > > >>> >>> 3. missing use of normative language >>> >>> The last sentence of section 4.2.1 states >>> >>> "However, this document does not assume that an Autonomous System with >>> NEW speakers has to have a globally unique 2-octet AS number -- >>> AS_TRANS could be used instead (even if a multiple Autonomous System >>> would use it)." >>> >>> The "could be used instead" implies to this reviewer that there are >>> other solutions, yet the document is only proposing a single >>> approach. So it is my understanding from the remainder of the text of >>> this document that the intent here is that: >>> >>> "AS_TRANS MUST be used when the NEW speaker does not have a 2-octet >>> AS number (even if a multiple Autonomous System would use it)." >> Will revise as suggested. >> >>> 4. Error Handling >>> >>> Section 4 provides a specification for error handling of update in >>> BGP. It would be helpful to note here that this section provides an >>> UPDATE to RFC 4271 with respect to the error conditions noted here >>> and their handling. >> Will do. >> > many thanks, > > Geoff > > From david.sinicrope@ericsson.com Wed Jun 20 23:53:32 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2FE21F85C3 for ; Wed, 20 Jun 2012 23:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.432 X-Spam-Level: X-Spam-Status: No, score=-105.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6kLAGXg9I2f for ; Wed, 20 Jun 2012 23:53:32 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7ED21F85A8 for ; Wed, 20 Jun 2012 23:53:32 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q5L6rU02021587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jun 2012 01:53:31 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.57]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 21 Jun 2012 02:53:30 -0400 From: David Sinicrope To: "rtg-ads@tools.ietf.org" Date: Thu, 21 Jun 2012 02:53:27 -0400 Thread-Topic: RtgDir review: draft-ietf-6man-lineid-05.txt Thread-Index: Ac1PepDdeA0DWQMlS8iC6lNGJup47w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-6man-lineid-05.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-6man-lineid-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 06:53:33 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-6man-lineid-05.txt Reviewer: David Sinicrope Review Date: 14 June 2012 IETF LC End Date: 18 June 2012 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resol= ved before publication. Comments: * Overall the draft is nearly ready for publication, but there are a few= things that, if clarified, would help the reader in understanding the draf= t. I am happy to discuss the comments with the draft editors. Major Issues: * No major issues found. Minor Issues: 1. Section 1.1 Terminology & all related sections: Throughout several se= ctions of the document the term "subscriber" is used. It is not defined in = the Terminology. It seems this is often used synonimously with End-device = which is defined. This is particularly true of section 2. Applicability St= atement. Please define "subscriber" or substitute a defined term (e.g., "e= nd device") for "subscriber" throughout the document. 2. Section 1.1 Terminology & all related sections: Throughout several se= ctions of the document the term "host" is used. While "host" is defined in = the Terminology, it seems this is often used synonimously with End-device w= here it would be better to use the latter term. This is particularly true = of section 2. Applicability Statement paras 3 and 5. Please substitute "en= d device" for "host" throughout the document where this is applicable. 3. Section 2. Applicability Statement: This section focuses on the limita= tions of the draft, but it should elaborate more on the applicability and u= sefulness of the draft to support stateless auto configuration. 4. Section 2. Applicability Statement, para 3, last 2 sentences: These st= atements make it appear that all broadband networks rely on the [end device= ] MAC address and that it is not recommended that this draft be used for ne= tworks that require the [end device] MAC address, leading the reader to the= possible conclusion that this draft has little use. In practice some broa= dband networks use the [end device] MAC address, but not all making the dra= ft far more applicable than indicated. Please qualify the penultimate sent= ence of paragraph 3 "=85 currently used in <"some" or "many"> Broadband net= works=85" 5. Section 2 Applicability Statement: The document would benefit from a b= rief flow diagram showing the Router Solicitation & Router Advertisement fl= ows between the nodes shown in Figure 1. 6. Section 4 Basic Operation, last sentence: The last sentence is not cl= ear as to why a packet with a hop limit not set to 255 is discarded. Pleas= e briefly elaborate (e.g., "=85 because they appear to be more than a singl= e hop away.") 7. Section 5.1 On receiving a Router Solicitation: Add a figure showing t= he construction of a tunneled Router Solicitation. Add "See Figure X" with= in the paragraph to reference the figure. 8. Section 5.2.1 Identifying tunneled Router Advertisements: It is unclea= r, at least initially, what is meant by "All BBF Access Nodes". Please cla= rify its use as done in section 6.2, noting that it is a well known, link-l= ocal scoped multicast address. 9. Section 5.3 On detecting a subscriber circuit coming up, para 1, "When= the access node=85": I believe what is meant by "When the access node dete= cts that a subscriber circuit has come up=85" is really "Each time the acce= ss node detects that a subscriber circuit has come up=85". "When the=85" c= ould be misinterpreted as meaning "the first time". Please change "When th= e" to "Each time" in this sentence. 10. Section 6.1 On receiving a Tunneled Router Solicitation=85: It is not = clear how the edge router recognizes a tunneled RS. Please briefly elaborat= e on how this datagram is identified by the edge router. 11. Section 6.1 On receiving a Tunneled Router Solicitation=85, "The link-= layer destination address of the tunneled RA MUST=85" There are two state= ments in this paragraph that start with this clause that seem to be contrad= ictory. Please reconcile and clarify. 12. Section 6.3 Sending periodic unsolicited Router Advertisements=85: Thi= s section would benefit from a forward reference to section 8 Garbage colle= ction of unused prefixes to help the reader understand when and how the pre= fixes are eventually removed or cleared. 13. Section 7 Line Identification Destination Option (LIO): Change "=85no = alignment requirement." to "=85 no byte alignment requirement." 14. Section 7.1 Encoding of Line ID, para 3: It is not clear why compatibi= lity with DHCP is needed as these are two independent protocols. The secti= on notes the derivation of the option from DHCP. It seems to be implied th= at compatibility is kept to allow the same processing to be used. If this = is the case it should be stated. If it is not the case, the rationale woul= d help the reader understand better why compatibility must be kept and the = relation to the install base which would seem to need a software upgrade to= support this draft. Nits: 1. Section 2 Applicability Statement, para 3: This paragraph should be br= oken into two paragraphs as the latter sentences explain limitations and re= commendations of the draft itself while the earlier sentences explain opera= tion of Router Solicitation and Advertisement. 2. Section 5.1 On receiving a Router Solicitation: Clarify the use of "t= he unspecified address", with a reference or context. (e.g., "the unspecifi= ed address defined in RFC=85" 3. General: inconsistent use of capitalization on "Edge Router"/"edge rou= ter"/"Edge router"