From nobody Tue Jul 1 10:07:49 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2A1B2875 for ; Tue, 1 Jul 2014 10:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOy9UM8vHb0p for ; Tue, 1 Jul 2014 10:07:37 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 125911B2881 for ; Tue, 1 Jul 2014 10:07:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.236; From: "Susan Hares" To: , References: In-Reply-To: Date: Tue, 1 Jul 2014 13:07:34 -0400 Message-ID: <007801cf954e$f459d770$dd0d8650$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01CF952D.6D4B92D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHBgUmHYHShme0nYIe8MTweC4lI4punmELQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/_rdE_DZbrI_iD-SyTrSBWvQ4kDk Cc: 'Jonathan Hardwick' , adrian@olddog.co.uk, draft-ietf-sidr-cps@tools.ietf.org, db3546@att.com, ''Alia Atlas'' Subject: Re: [RTG-DIR] Routing Directorate review- draft-ietf-sidr-cps X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 17:07:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0079_01CF952D.6D4B92D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephen, Derrick, Karen: This is a routing directorate review which as three parts: a) status, b) technical review, and c) editorial review. Status: Ready for publication Technical Review: This Certification form covers all necessary items for a CPS who is part of RPKI. Editorial review: This document is well-written and readable for any network administrator or Security administrator. Tiny nit: p. 16, 3.2.2 second paragraph Old: Certificate that is used, accurately reflects New: Certificate this is used accurately reflects. Definitions nit: p. 26 OCSP and SCVP. Here, it may be nice to spell out OCSP And SCVP. I believe you mean: OCSP (Online Certificate Status Protocol), SCVP (Server-Based Certificate Validation Protocol). If these are incorrect expansions of OCSP and SCVP, you really need to put in expansions of the abbreviations. Sue Hares From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Thursday, June 19, 2014 5:09 PM To: shares@ndzh.com Cc: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); 'Alia Atlas' (akatlas@gmail.com); adrian@olddog.co.uk Subject: Routing Directorate review- draft-ietf-sidr-cps Hi Sue, Can you do this review by July 1st? Thanks, Deborah ------=_NextPart_000_0079_01CF952D.6D4B92D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen, Derrick, Karen:  

 

This is a routing directorate review which as three parts:  a) = status, b) technical review, and c) editorial review. =

 

Status: Ready for publication

Technical Review: This Certification form covers all necessary items = for a

CPS who is part of RPKI.

 

Editorial review:

This document is well-written and readable for any network = administrator or

Security administrator.

 

Tiny nit: p. 16, 3.2.2 second paragraph

 

Old: Certificate that is used, accurately = reflects

New: Certificate this is used accurately reflects. =

 

Definitions nit: p. 26 OCSP and SCVP.

 

Here, it may be nice to spell out OCSP And SCVP. I believe you mean: =

 

OCSP (Online Certificate Status Protocol),

SCVP (Server-Based Certificate Validation = Protocol).

 

If these are incorrect expansions of OCSP and SCVP, you really need = to put in expansions of the abbreviations.

 

Sue Hares

From:= = BRUNGARD, DEBORAH A [mailto:db3546@att.com]
Sent: Thursday, = June 19, 2014 5:09 PM
To: shares@ndzh.com
Cc: = Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com); 'Alia Atlas' = (akatlas@gmail.com); adrian@olddog.co.uk
Subject: Routing = Directorate review- = draft-ietf-sidr-cps

 

Hi = Sue,

Can you do = this review by July 1st?

Thanks,

Deborah

 =

 =

------=_NextPart_000_0079_01CF952D.6D4B92D0-- From nobody Tue Jul 1 12:05:01 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F83B1A0414 for ; Tue, 1 Jul 2014 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltt2XTpS5fNz for ; Tue, 1 Jul 2014 11:52:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2C01B2854 for ; Tue, 1 Jul 2014 11:52:52 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54570) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X23Am-000LUo-Q2; Tue, 01 Jul 2014 14:52:56 -0400 Message-ID: <53B30379.2090200@bbn.com> Date: Tue, 01 Jul 2014 14:52:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Susan Hares , rtg-dir@ietf.org, draft-ietf-sidr-cps@tools.ietf.org References: <007801cf954e$f459d770$dd0d8650$@ndzh.com> In-Reply-To: <007801cf954e$f459d770$dd0d8650$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/J8oK1stXxnj5rzll-Q2PofXFvFE X-Mailman-Approved-At: Tue, 01 Jul 2014 12:04:57 -0700 Cc: karen Seo , Steve Kent , db3546@att.com, ''Alia Atlas'' , 'Jonathan Hardwick' , adrian@olddog.co.uk Subject: Re: [RTG-DIR] Routing Directorate review- draft-ietf-sidr-cps X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:52:58 -0000 Sue, Thanks for the review. I'll ask Karen to make the edits you suggest. Sorry about not having defined OCSP and SCVP before use. Steve From nobody Tue Jul 1 12:50:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2601B2869 for ; Tue, 1 Jul 2014 12:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX49TVofkwXw for ; Tue, 1 Jul 2014 12:50:18 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4941B27FB for ; Tue, 1 Jul 2014 12:50:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.236; From: "Susan Hares" To: "'Stephen Kent'" , , References: <007801cf954e$f459d770$dd0d8650$@ndzh.com> <53B30379.2090200@bbn.com> In-Reply-To: <53B30379.2090200@bbn.com> Date: Tue, 1 Jul 2014 15:50:15 -0400 Message-ID: <011101cf9565$ae7432c0$0b5c9840$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHBgUmHYHShme0nYIe8MTweC4lI4gHdoaMCAaK5QCGbi8W2IA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/dK8UYdSEypkGxpKRCTpMCfsAIOM Cc: 'Jonathan Hardwick' , 'karen Seo' , adrian@olddog.co.uk, db3546@att.com, ''Alia Atlas'' Subject: Re: [RTG-DIR] Routing Directorate review- draft-ietf-sidr-cps X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 19:50:19 -0000 Steve: The document was well-written which makes it a pleasure to read. Thank you for doing such a great job! Sue -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, July 01, 2014 2:53 PM To: Susan Hares; rtg-dir@ietf.org; draft-ietf-sidr-cps@tools.ietf.org Cc: karen Seo; Steve Kent; db3546@att.com; ''Alia Atlas''; 'Jonathan Hardwick'; adrian@olddog.co.uk Subject: Re: [RTG-DIR] Routing Directorate review- draft-ietf-sidr-cps Sue, Thanks for the review. I'll ask Karen to make the edits you suggest. Sorry about not having defined OCSP and SCVP before use. Steve From nobody Fri Jul 4 01:22:32 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8A1B2B83; Thu, 3 Jul 2014 17:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.57 X-Spam-Level: X-Spam-Status: No, score=-101.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISTFv925PTj4; Thu, 3 Jul 2014 17:52:59 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239461B2B5B; Thu, 3 Jul 2014 17:52:58 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 4 Jul 2014 09:52:53 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Fri, 4 Jul 2014 09:52:51 +0900 From: Jeong Ryoo To: Lou Berger , "rtg-ads@tools.ietf.org" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+ Date: Fri, 4 Jul 2014 00:52:50 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> In-Reply-To: <53A5ABED.9080408@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: SmVvbmcgUnlvbw== x-originating-ip: [129.254.28.48] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/5UwcYj_geRTgZCYqHRX3StuZcjo X-Mailman-Approved-At: Fri, 04 Jul 2014 01:22:28 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 00:53:06 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBMb3UsDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cy4NCg0K VGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBoYXZlIGRpc2N1c3NlZCB5b3VyIGNvbW1lbnRzLCBh bmQgYXJlIHByb3Bvc2luZyBvdXIgcmVzb2x1dGlvbnMgdG8geW91ciBjb21tZW50cy4gUGxlYXNl LCBsZXQgdXMga25vdyBpZiB0aGUgcHJvcG9zYWwgaXMgYXBwcm9wcmlhdGUgdG8gYWRkcmVzcyB5 b3VyIGNvbW1lbnRzIGFuZCBjb25jZXJucy4NCg0KQmVzdCByZWdhcmRzLA0KDQpBdXRob3JzIG9m IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzIGRyYWZ0DQoNCioqKioqKiBCZWdpbm5p bmcgb2YgQ29tbWVudCBSZXNvbHV0aW9uICoqKioqKg0KDQotIERvY3VtZW50J3MgdXNhZ2Ugb2Yg ImNvbW1pdHRlZCIgdnMgImFsbG9jYXRlZCIgcmVzb3VyY2VzOg0KDQpJbiBzZWN0aW9uIDEgdGhl IGRvY3VtZW50IGludHJvZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZQ0KZGlzdGluY3Rpb24gYmV0 d2VlbiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBiYXNlZCBvbiB3aGVuDQpyZXNvdXJj ZXMgYXJlICJjb21taXR0ZWQiLiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBwYXN0DQpkZWZpbml0aW9u LiBSRkM0NDI3IGFuZCA2MzcyIG1ha2UgdGhlIGRpc3RpbmN0aW9uIHRoYXQgcHJvdGVjdGlvbg0K YW5kIHJlc3RvcmF0aW9uIGRpZmZlciBiYXNlZCBvbiB3aGVuIHJlc291cmNlcyBhcmUgKmFsbG9j YXRlZCogbm90DQoqY29tbWl0dGVkKi4gVG8gcXVvdGUgUkZDIDQ0Mjc6DQoNClRoZSBkaXN0aW5j dGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIG1hZGUgYmFzZWQNCm9u IHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uIGRvbmUgZHVyaW5nIHRoZSByZWNvdmVyeSBMU1Avc3Bh bg0KZXN0YWJsaXNobWVudC4gVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gZGlmZmVyZW50IHR5cGVz IG9mDQpyZXN0b3JhdGlvbiBpcyBtYWRlIGJhc2VkIG9uIHRoZSBsZXZlbCBvZiByb3V0ZSBjb21w dXRhdGlvbiwNCnNpZ25hbGluZywgYW5kIHJlc291cmNlIGFsbG9jYXRpb24gZHVyaW5nIHRoZSBy ZXN0b3JhdGlvbg0KTFNQL3NwYW4gZXN0YWJsaXNobWVudC4NCg0KVGhpcyBkaWZmZXJlbmNlIGFs c28gbGVhZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZQ0KZG9jdW1lbnQgYXMg d2VsbCBhcyBhbWJpZ3VpdHkgaW4gdGhlIHRleHQsIGkuZS4gY29uZnVzaW9uIGJ5IHRoZQ0KcmVh ZGVyLiBUaGUgdGVybSAiY29tbWl0dGVkIiBpcyBub3QgdGlnaHRseSBkZWZpbmVkIGluIHRoaXMN CmRvY3VtZW50IChvciBlYXJsaWVyIHdvcmspIGFuZCBpcyB1c2VkIGRpZmZlcmVudGx5IHRoYW4g aG93DQoiYWxsb2NhdGVkIiBoYXMgYmVlbiB1c2VkLiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJl IGZvdW5kIGluDQpTZWN0aW9uIDMuMSB3aGljaCBzdGF0ZXM6DQoNCkhvd2V2ZXIsIHRoZSBjb21t aXRtZW50IG9mIHRoZSByZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGUNCnNoYXJlZCBzZWdtZW50 cywgd2lsbCBvbmx5IGJlIGZpbmFsaXplZCB3aGVuIHRoZSBwcm90ZWN0aW9uDQpwYXRoIGlzIGFj dHVhbGx5IGFjdGl2YXRlZC4gVGhlcmVmb3JlLCBmb3IgdGhlIHB1cmlzdHMgLQ0KcmVnYXJkaW5n IHRoZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVyZSBiZXR3ZWVuDQpwcm90ZWN0aW9u IGFuZCByZXN0b3JhdGlvbi4NCg0KQm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1hdGljLiBJbiB0 aGUgZmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG8NCmNvdmVyIGEgInByb3RlY3Rpb24gc3dpdGNo IiB3b3VsZCAiY29ubmVjdCIgdGhlIHByb3RlY3Rpb24gcGF0aA0KYnV0IG5vdCB0aGUgZWFybGll ciAiYWxsb2NhdGlvbiIgb2YgcmVzb3VyY2VzLiAoUXVvdGVkIHRlcm1zIGFyZQ0KdXNlZCBpbiBl YXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFzZWQgb24gdGhlIG5ldw0K ZGlzdGluY3Rpb24gb2YgcHJvdGVjdGlvbiB2cy4gcmVzdG9yYXRpb24gYW5kIGlzIHVubmVjZXNz YXJ5IHdpdGgNCnRoZSBleGlzdGluZyBkaXN0aW5jdGlvbi4NCg0KVGhpcyBpc3N1ZSBleGlzdHMg aW4gbXVsdGlwbGUgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB3aGVyZQ0KImNvbW1pdHRlZCIgaXMg dXNlZCBhbmQgSSdkIHJlY29tbWVuZCB0aGF0IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkDQp3aXRo IHRlcm1pbm9sb2d5IHVzZWQgaW4gdGhlIHJlZmVyZW5jZWQgUkZDcywgaS5lLiwgImFsbG9jYXRp b24iLA0KImNvbm5lY3Rpb24iLCAiY3Jvc3MtY29ubmVjdCIsICJwcm90ZWN0aW9uIHN3aXRjaChv dmVyKSIsIC4uLg0KDQpOb3RlIEknbSAqbm90KiBoaWdobGlnaHRpbmcgYWxsIGNhc2VzIHdoZXJl IHRoZXJlIGFyZSBwcm9ibGVtcyBpbiB0aGUNCmRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1 ZS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNlcyBpbiB0aGUNCmRvY3VtZW50IHdoZXJlIEkg dGhpbmsgaXQncyBwb3NzaWJsZSB0aGF0IG9uY2UgdGhpcyB0ZXJtaW5vbG9neQ0KYW1iaWd1aXR5 IGlzIGNvcnJlY3RlZCB0aGF0IEknbGwgaGF2ZSBvdGhlciBzdWJzdGFudGl2ZSBjb21tZW50cy4N Cg0KW0F1dGhvcnNdIEFmdGVyIHJldmlld2luZyBSRkNzIDQ0MjcsIDYzNzIsIDM5NDUsIDQ0MjYs IGFuZCA0NDI4LCB3ZSBjb25jbHVkZWQgdGhhdCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90 ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBzaG91bGQgYmUgYWxpZ25lZCB3aXRoIHRoZSBleGl0aW5n IGRvY3VtZW50cyBub3JtYXRpdmVseSByZWZlcmVuY2VkIGJ5IHRoaXMgZG9jdW1lbnQuIEFjY29y ZGluZ2x5LCB0aGUgZm9sbG93aW5nIDE2IG1vZGlmaWNhdGlvbnMgd2lsbCBiZSBkb25lIGluIHJl dmlzaW9uOg0KDQooMSkgU2VjdGlvbiAxLCB0aGUgdGhpcmQgcGFyYWdyYXBoDQpPTEQ6DQpBcyBw b2ludGVkIG91dA0KaW4gW1JGQzYzNzJdIGFuZCBbUkZDNDQyOF0sIGFwcGx5aW5nIDErMSBsaW5l YXIgcHJvdGVjdGlvbiByZXF1aXJlcw0KdGhhdCByZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCBmb3Ig dXNlIGJ5IGJvdGggdGhlIHdvcmtpbmcgYW5kDQpwcm90ZWN0aW9uIHBhdGhzLiBBcHBseWluZyAx OjEgcHJvdGVjdGlvbiByZXF1aXJlcyB0aGF0IHRoZSBzYW1lDQpyZXNvdXJjZXMgYXJlIGNvbW1p dHRlZCwgYnV0IGFsbG93cyB0aGUgcmVzb3VyY2VzIG9mIHRoZSBwcm90ZWN0aW9uDQpwYXRoIHRv IGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUgZXh0cmEgdHJhZmZpYy4NCk5FVzoNCkFzIHBv aW50ZWQgb3V0DQppbiBbUkZDNjM3Ml0gYW5kIFtSRkM0NDI4XSwgYXBwbHlpbmcgMSsxIHByb3Rl Y3Rpb24gcmVxdWlyZXMNCnRoYXQgcmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQgZm9yIHVzZSBieSBi b3RoIHRoZSB3b3JraW5nIGFuZA0KcHJvdGVjdGlvbiBwYXRocy4gQXBwbHlpbmcgMToxIHByb3Rl Y3Rpb24gcmVxdWlyZXMgdGhhdCB0aGUgc2FtZQ0KcmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQsIGJ1 dCBhbGxvd3MgdGhlIHJlc291cmNlcyBvZiB0aGUgcHJvdGVjdGlvbg0KcGF0aCB0byBiZSB1dGls aXplZCBmb3IgcHJlLWVtcHRpYmxlIGV4dHJhIHRyYWZmaWMuDQoNCigyKSBUaGUgd2hvbGUgdGV4 dCBpbiBTZWN0aW9uIDMuMSB3aWxsIGJlIHJlcGxhY2VkIHdpdGg6DQpbUkZDNjM3Ml0sIGJhc2Vk IHVwb24gdGhlIGRlZmluaXRpb25zIGluIFtSRkM0NDI3XSwgZGlmZmVyZW50aWF0ZXMgYmV0d2Vl biAicHJvdGVjdGlvbiIgYW5kICJyZXN0b3JhdGlvbiIgZGVwZW5kZW50IHVwb24gdGhlIGR5bmFt aXNtIG9mIHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uLiBUaGUgc2FtZSBkaXN0aW5jdGlvbiBpcyB1 c2VkIGluIFtSRkMzOTQ1XSwgW1JGQzQ0MjZdLCBhbmQgW1JGQzQ0MjhdLiBUaGlzIGRvY3VtZW50 IGFsc28gdXNlcyB0aGUgc2FtZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJl c3RvcmF0aW9uIGFzIHN0YXRlZCBpbiBbUkZDNjM3Ml0uDQoNCigzKSBJbiBwYWdlIDYsDQpPTEQ6 DQpUaGUgdXNlIG9mIHByZWVtcHRpb24gaW4gdGhlIG5ldHdvcmsgaXMgdHlwaWNhbGx5IGEgYnVz aW5lc3Mgb3INCnBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90ZWN0aW9uIHJlc291 cmNlcyBhcmUgY29udGVuZGVkLA0KcHJpb3JpdHkgY2FuIGJlIGFwcGxpZWQgdG8gZGV0ZXJtaW5l IHRvIHdoaWNoIHBhcnRpZXMgdGhlIHByb3RlY3Rpb24NCnJlc291cmNlcyBhcmUgY29tbWl0dGVk Lg0KTkVXOg0KVGhlIHVzZSBvZiBwcmVlbXB0aW9uIGluIHRoZSBuZXR3b3JrIGlzIHR5cGljYWxs eSBhIGJ1c2luZXNzIG9yDQpwb2xpY3kgZGVjaXNpb24gc3VjaCB0aGF0IHdoZW4gcHJvdGVjdGlv biByZXNvdXJjZXMgYXJlIGNvbnRlbmRlZCwNCnByaW9yaXR5IGNhbiBiZSBhcHBsaWVkIHRvIGRl dGVybWluZSB3aGljaCBwYXJ0aWVzIHV0aWxpemUgdGhlIHByb3RlY3Rpb24NCnJlc291cmNlcy4N Cg0KKDQpIFBhZ2UgNywgdGhlIGZpcnN0IHBhcmFncmFwaDoNCk9MRDoNCnRoZSByZXNvdXJjZXMg Zm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGNvbW1pdHRlZCwNCk5FVw0KdGhlIHJl c291cmNlcyBmb3IgdGhlIHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkgZGVkaWNhdGVkLA0KDQpP TEQ6DQpyZXNvdXJjZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdvdWxkIG5vdCBiZSBjb21taXR0ZWQg dW50aWwg4oCmDQpORVc6DQpyZXNvdXJjZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdvdWxkIG5vdCBi ZSB1dGlsaXplZCB1bnRpbCDigKYNCg0KKDUpIEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHBh Z2UgNywNCk9MRDoNCiJIYXJkIFByZWVtcHRpb24iIHJlcXVpcmVzIHRoZSBwcm9ncmFtbWluZyBv ZiBzZWxlY3RvcnMgYXQgdGhlIGluZ3Jlc3Mgb2YgZWFjaCBzaGFyZWQgc2VnbWVudCB0byBzcGVj aWZ5IHdoaWNoIGJhY2t1cCBwYXRoIGhhcyB0aGUgaGlnaGVzdCBwcmlvcml0eSB3aGVuIGNvbW1p dHRpbmcgcHJvdGVjdGlvbiByZXNvdXJjZXMsIHRoZSBvdGhlcnMgYmVpbmcgcHJlZW1wdGVkLg0K TkVXDQoiSGFyZCBQcmVlbXB0aW9uIiByZXF1aXJlcyB0aGUgcHJvZ3JhbW1pbmcgb2Ygc2VsZWN0 b3JzIGF0IHRoZSBpbmdyZXNzIG9mIGVhY2ggc2hhcmVkIHNlZ21lbnQgdG8gc3BlY2lmeSB0aGUg cHJpb3JpdGllcyBvZiBiYWNrdXAgcGF0aHMsIHNvIHRoYXQgdHJhZmZpYyBvZiBsb3dlciBwcmlv cml0eSBwYXRocyBjYW4gYmUgcHJlZW1wdGVkLg0KDQooNikgVGhlIGZpcnN0IHBhcmFncmFwaCBv ZiBTZWN0aW9uIDQuMToNCk9MRDoNCuKApiBhbmQgY29tbWl0IHRoZSBhc3NvY2lhdGVkIHJlc291 cmNlcy4gVGhlIGNvbW1pdG1lbnQgb2YgcmVzb3VyY2VzDQppcyBkZXBlbmRlbnQgdXBvbiDigKYN Ck5FVzoNCuKApiBhbmQgY29vcmRpbmF0ZSB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIGFzc29jaWF0 ZWQgc2hhcmVkIHJlc291cmNlcy4NClRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRp b24gaXMgZGVwZW5kZW50IHVwb24g4oCmDQoNCig3KSBUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiBT ZWN0aW9uIDQuMToNCk9MRDoNCldoZW4gdGhlIHJlc2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hh cmVkIHNlZ21lbnRzIGFyZSBjb21taXR0ZWQgdG8gYQ0KcGFydGljdWxhciBwcm90ZWN0aW9uIHBh dGgsIHRoZXJlIG1heSBub3QgYmUgc3VmZmljaWVudCByZXNvdXJjZXMNCmF2YWlsYWJsZSBmb3Ig YW4gYWRkaXRpb25hbCBwcm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQNCmlm IGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVj dGlvbg0Kc3dpdGNoLCB0aGUgY29tbWl0bWVudCBvZiB0aGUgcmVzb3VyY2VzIG1heSBmYWlsLiBJ biBvcmRlciB0bw0Kb3B0aW1pemUgdGhlIG9wZXJhdGlvbiBvZiB0aGUgY29tbWl0bWVudCBhbmQg cHJlcGFyaW5nIGZvciBjYXNlcyBvZg0KbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0 aGUgY29tbWl0bWVudCBvZiB0aGUgc2hhcmVkDQpyZXNvdXJjZXMgYXJlIGJlIGNvb3JkaW5hdGVk IGJldHdlZW4gdGhlIGRpZmZlcmVudCB3b3JraW5nIHBhdGhzIGluDQp0aGUgU01QIG5ldHdvcmsu DQpORVc6DQpXaGVuIHRoZSByZXNlcnZlZCByZXNvdXJjZXMgb2YgdGhlIHNoYXJlZCBzZWdtZW50 cyBhcmUgdXRpbGl6ZWQgYnkgYQ0KcGFydGljdWxhciBwcm90ZWN0aW9uIHBhdGgsIHRoZXJlIG1h eSBub3QgYmUgc3VmZmljaWVudCByZXNvdXJjZXMNCmF2YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25h bCBwcm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQNCmlmIGFub3RoZXIgd29y a2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVjdGlvbg0Kc3dpdGNo LCB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIG1heSBmYWlsLiBUaGUgZGlm ZmVyZW50IHdvcmtpbmcgcGF0aHMgaW4NCnRoZSBTTVAgbmV0d29yayBhcmUgaW52b2x2ZWQgaW4g dGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbi4NCi4NCg0KKDgpIFNlY3Rpb24g NS4xLA0KT0xEOg0K4oCmIGFuZCBjb21taXQgdGhlIGFzc29jaWF0ZWQgcmVzb3VyY2VzLg0KTkVX DQrigKYgYW5kIGNvb3JkaW5hdGUgdGhlIHV0aWxpemF0aW9uIG9mIHRoZSBhc3NvY2lhdGVkIHNo YXJlZCByZXNvdXJjZXMuDQoNCig5KSBJbiBTZWN0aW9uIDUuMSwNCk9MRDoNCkluIHRoZSBjYXNl IG9mIG11bHRpcGxlIHdvcmtpbmcgcGF0aHMgZmFpbGluZywgdGhlIGNvbW1pdG1lbnQgb2YgdGhl DQpzaGFyZWQgcmVzb3VyY2VzIFNIQUxMIGJlIGNvb3JkaW5hdGVkIGJldHdlZW4gdGhlIGRpZmZl cmVudCB3b3JraW5nDQpwYXRocyBpbiB0aGUgU01QIG5ldHdvcmsuDQpORVc6DQpJbiB0aGUgY2Fz ZSBvZiBtdWx0aXBsZSB3b3JraW5nIHBhdGhzIGZhaWxpbmcsIHRoZSBzaGFyZWQgcmVzb3VyY2Ug dXRpbGl6YXRpb24NCmNvb3JkaW5hdGlvbiBTSEFMTCBiZSBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQg d29ya2luZw0KcGF0aHMgaW4gdGhlIFNNUCBuZXR3b3JrLg0KDQooMTApIFNlY3Rpb24gNS4xLjEu DQpPTEQ6DQrigKYgYmVjYXVzZSB0aGV5IGFscmVhZHkgaGF2ZSBiZWVuIGNvbW1pdHRlZCB0byB0 aGUgcHJvdGVjdGlvbiBvZiwgZm9yIGV4YW1wbGUsIGEgaGlnaGVyIHByaW9yaXR5IHdvcmtpbmcg cGF0aC4NCk5FVzoNCuKApiBiZWNhdXNlIHRoZXkgYWxyZWFkeSBoYXZlIGJlZW4gdXRpbGl6ZWQg Zm9yIHRoZSBwcm90ZWN0aW9uIG9mLCBmb3IgZXhhbXBsZSwgYSBoaWdoZXIgcHJpb3JpdHkgd29y a2luZyBwYXRoLg0KDQooMTEpIFNlY3Rpb24gNS4yLCB0aGUgc2Vjb25kIGJ1bGxldCBpdGVtOg0K T0xEOg0KUmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgU0hBTEwgYmUgY29tbWl0dGVk IHRvIHRoZQ0KcHJvdGVjdGlvbiBwYXRoIOKApg0KTkVXOg0KUmVzb3VyY2VzIG9mIHRoZSBzaGFy ZWQgc2VnbWVudHMgU0hBTEwgYmUgdXRpbGl6ZWQgYnkgdGhlDQpwcm90ZWN0aW9uIHBhdGgg4oCm DQoNCigxMikgU2VjdGlvbiA1LjIsIHRoZSB0aGlyZCBidWxsZXQgaXRlbToNCk9MRDoNCklmIG11 bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3RpbmcN CmFsbG9jYXRpb24gb2YgdGhlIHNoYXJlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxE IGJlDQpjb21taXR0ZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBiYXNpcy4NCk5FVzoN CklmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVl c3RpbmcNCnRoZSBzaGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2VzIFNIT1VMRCBiZQ0KYXNz aWduZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBiYXNpcy4NCg0KKDEzKSBTZWN0aW9u IDUuMiwgdGhlIGZvdXJ0aCBidWxsZXQgaXRlbToNCk9MRDoNCklmIHRoZSBwcm90ZWN0aW9uIHJl c291cmNlcyBhcmUgY29tbWl0dGVkIHRvIGEgcHJvdGVjdGlvbiBwYXRoLA0Kd2hvc2Ugd29ya2lu ZyBwYXRoIGhhcyBhIGxvd2VyIHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yDQp0aGUg aGlnaGVyIHByaW9yaXR5IHBhdGggU0hBTEwgYmUgY29tbWl0dGVkIHRvIHRoZSBoaWdoZXIgcHJp b3JpdHkNCnBhdGguDQpORVc6DQpJZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIHV0aWxp emVkIGJ5IGEgcHJvdGVjdGlvbiBwYXRoLA0Kd2hvc2Ugd29ya2luZyBwYXRoIGhhcyBhIGxvd2Vy IHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yDQp0aGUgaGlnaGVyIHByaW9yaXR5IHBh dGggU0hBTEwgYmUgYXNzaWduZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eQ0KcGF0aC4NCg0KDQoo MTQpIFNlY3Rpb24gNS4yLiB0aGUgc2V2ZW50aCBidWxsZXQgaXRlbQ0KT0xEOg0KT25jZSByZXNv dXJjZXMgb2Ygc2hhcmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkgY29tbWl0dGVk DQp0byBhIHByb3RlY3Rpb24gcGF0aCwg4oCmDQpORVc6DQpPbmNlIHJlc291cmNlcyBvZiBzaGFy ZWQgc2VnbWVudHMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSB1dGlsaXplZA0KYnkgYSBwcm90ZWN0 aW9uIHBhdGgsIOKApg0KDQooMTUpIFNlY3Rpb24gNS4zLCB0aGUgZmlyc3QgcGFyYWdyYXBoLA0K T0xEOg0K4oCmIHJlcXVlc3QgdGhlIGNvbW1pdG1lbnQgb2YgcHJvdGVjdGlvbiByZXNvdXJjZXMu IElmIHRoZSBuZWNlc3NhcnkNCnNoYXJlZCByZXNvdXJjZXMgYXJlIHVuYXZhaWxhYmxlIHRvIGJl IGNvbW1pdHRlZCB0byB0aGUgcHJvdGVjdGlvbg0KcGF0aCwgdGhlIGVuZHBvaW50cyDigKYNCg0K TkVXOg0K4oCmIHJlcXVlc3QgdGhlIGNvb3JkaW5hdGlvbiBvZiB0aGUgc2hhcmVkIHJlc291cmNl IHV0aWxpemF0aW9uLiBJZiB0aGUgbmVjZXNzYXJ5DQpzaGFyZWQgcmVzb3VyY2VzIGFyZSB1bmF2 YWlsYWJsZSwgdGhlIGVuZHBvaW50cyDigKYNCg0KKDE2KSBTZWN0aW9uIDUuMywgdGhlIHNlY29u ZCBwYXJhZ3JhcGgsDQpPTEQ6DQpTaW1pbGFybHksIGlmIHByZWVtcHRpb24gaXMgc3VwcG9ydGVk IGFuZCB0aGUgcmVzb3VyY2VzIGN1cnJlbnRseQ0KY29tbWl0dGVkIGZvciBhIHBhcnRpY3VsYXIg d29ya2luZyBwYXRoIGFyZSDigKYNCk5FVzoNClNpbWlsYXJseSwgaWYgcHJlZW1wdGlvbiBpcyBz dXBwb3J0ZWQgYW5kIHRoZSByZXNvdXJjZXMgY3VycmVudGx5DQp1dGlsaXplZCBieSBhIHBhcnRp Y3VsYXIgd29ya2luZyBwYXRoIGFyZSDigKYNCg0KDQotIFNlY3Rpb24gMiwgMXN0IHBhcmFncmFw aCwgbGFzdCBzZW50ZW5jZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkgZGVmaW5lcw0KdGhlIHNjb3Bl L3B1cnBvc2Ugb2YgdGhlIGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlv bnMNCnRvIHByb3RvY29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNm eSB0aGUNCnJlcXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNoLCBJ J2QgcmVwZWF0IHRoaXMgaW4NCnRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJv bm91bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yDQozKS4NCg0KW0F1dGhvcnNdIFdlIGNhbiBh ZGQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDE6DQrigJxU aGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGNsYXJpZnkgdGhlIGluc3RydWN0aW9ucyB0byBw cm90b2NvbCBkZXNpZ25lcnMgcHJvZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhlIHJl cXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQu4oCdDQoNCg0KLSBHZW5lcmFsIGNv bW1lbnQ6IGZhdGUtc2hhcmluZyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQpwcm90 ZWN0aW9uOiBIb3cgaXMgY28tcm91dGluZyBwcmVzZXJ2ZWQgZm9yIHRoZSByZXZlcnNlIHBhdGgg aW4gU01QPw0KSSdkIGFzc3VtZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGNvb3JkaW5hdGlvbiBw cm90b2NvbCB3b3VsZCBiZQ0KcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhl IHJldmVyc2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCmNhc2UsIGJ1dCBkb24ndCBzZWUgdGhpcyBp biB0aGUgZG9jdW1lbnQuDQoNCltBdXRob3JzXSBGYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVk IGJ5IHRoaXMgZG9jdW1lbnQuIEV2ZW4gaW4gdGhlIFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcsIHN1Y2ggYXMgUkZDIDYzNzggKFBTQykgYW5kIFJGQyA3MjcxIChQU0MgaW4gQVBTIG1v ZGUpLCBmYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVkIGFzIHVuaWRpcmVjdGlvbmFsIHN3aXRj aGluZyBpcyBhbGxvd2VkLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGltcG9zZSBhbnkgcmVzdHJp Y3Rpb24gb24gY28tcm91dGluZywgZWl0aGVyLg0KDQoNCi0gSW4gc2VjdGlvbiA0IGFuZCA1LjIg eW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRlZmluaW5nDQpwcmVlbXB0aW9uIHRlcm1p bm9sb2d5IGFuZCBiZWhhdmlvci4gSSB0aGluayA2MzcyIGlzIHRoZSByaWdodA0KcmVmZXJlbmNl IGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBjb250ZXh0IG9mIHN1cnZpdmFiaWxpdHkg YW5kDQppbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFuZS4NCg0KW0F1dGhvcnNdIE9uZSBjb25j ZXJuIGlzIHRoYXQgUkZDIDYzNzIgZGVzY3JpYmVzIGJvdGggc29mdCBhbmQgaGFyZCBwcmVlbXB0 aW9ucyBpbiB0aGUgY29udGV4dCBvZiBleHRyYSB0cmFmZmljLCB3aGljaCBpcyBub3QgZXhhY3Rs eSB0aGUgY2FzZSBmb3IgU01QLg0KDQoNCi0gSW4gc2VjdGlvbiA0LjIgeW91IHNheSAiVGhlcmVm b3JlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGJlDQpjYXJyaWVkIG91dCB1bmRlciB0aGUg Y29udHJvbCBvZiBhIGR5bmFtaWMgY29udHJvbCBwbGFuZSBzaW1pbGFyIHRvDQpHTVBMUyBbUkZD Mzk0NV0uIiBwZXJoYXBzIHlvdSBtZWFuICJiYXNlZCBvbiBHTVBMUyI/IElmIHNvLCBncmVhdCwN CnBsZWFzZSBtYWtlIHRoZSBjb3JyZWN0aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBv ZiB3aGljaA0KY29udHJvbCBwcm90b2NvbCBpcyB1c2VkIGZvciBNUExTLVRQIGlzIHdheSBiZXlv bmQgdGhlIHNjb3BlIG9mIHRoaXMNCmRvY3VtZW50Lg0KDQpbQXV0aG9yc10gWWVzLCB3ZSB3aWxs IG1ha2UgdGhlIGNvcnJlY3Rpb24uDQoNCg0KLSBTZWN0aW9uIDUuMSwgcGFyYWdyYXBoIDEuIFdo eSBhcmUgeW91IHVzaW5nICJTSE9VTEQgTk9UIiBoZXJlPyBJZg0KcmVmZXJyaW5nIHRvIHNvbHV0 aW9ucyBjb25mb3JtYW50IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGVzZSBhcmUNCmluZm9y bWF0aXZlIHN0YXRlbWVudHMsICJhbmQgYSBub24tY29udHJvbCBwbGFuZSBiYXNlZCBTTVAgc3dp dGNob3Zlcg0KbWVjaGFuaXNtIGlzIHVzZWQsIHRoZSBjb250cm9sIHBsYW5lIFNIQUxMIE5PVCAu Li4iLiBJZiByZWZlcnJpbmcgdG8NCmFuIG9wZXJhdG9yJ3MvdXNlcidzIGNob2ljZSBvZiBwcm90 ZWN0aW9uIG1lY2hhbmlzbSwgSSB0aGluayB0aGUgbW9zdA0KeW91IGNhbiBzYXkgaXMgTUFZLg0K DQpbQXV0aG9yc10gVGhlIGZpcnN0IGNhc2UgaXMgdGhlIG9uZSB3ZSBhcmUgYWltaW5nIGF0LiBX ZSB3aWxsIHVzZSBTSEFMTCBOT1QuDQoNCg0KLSBTZWN0aW9uIDUuMi4gIlRpZS1icmVha2luZyBy dWxlcyBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNNUA0KZG9tYWluLiIgQXMgdGhp cyBpcyBhIHJlcXVpcmVtZW50LCB3aGF0IHlvdSBtZWFuIGJ5ICJ0aWUtYnJlYWtpbmcNCnJ1bGVz IiBzaG91bGQgYmUgZGVmaW5lZCBkaXJlY3RseSBvciBieSByZWZlcmVuY2UuDQoNCltBdXRob3Jz XSBUaGUgc2VudGVuY2UgY2FuIGJlIHJld3JpdHRlbiBhczoNCk9MRDoNClRpZS1icmVha2luZyBy dWxlcyBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNNUCBkb21haW4uDQpORVc6DQpJ biBvcmRlciB0byBjb3ZlciB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0 IHNlcnZlZCBwcmluY2lwbGUgY2Fubm90IHJlc29sdmUgdGhlIGNvbnRlbnRpb24gYW1vbmcgbXVs dGlwbGUgZXF1YWwgcHJpb3JpdHkgcmVxdWVzdHMsIGkuZS4sIHdoZW4gdGhlIHJlcXVlc3RzIG9j Y3VyIHNpbXVsdGFuZW91c2x5LCwgdGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQg aW4gc2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCg0KDQoNCi0gU2VjdGlvbiA1LjMuIFJGQzYzNzIg dGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3RpZmljYXRpb24NCmxldmVyYWdl cyB0aGUgc3RhbmRhcmQgTVBMUy1UUCBPQU0gbWVjaGFuaXNtcywgaXMgdGhlcmUgYW55IHJlYXNv biB0bw0KZG8gbW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2MzcyPw0KDQpbQXV0aG9yc10gV2UgY2Fu IGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGF0IHRoZSBlbmQ6DQrigJxBcyBkZXNjcmliZWQg aW4gW1JGQzYzNzJdLCB0aGUgZXZlbnQgb2YgcHJlZW1wdGlvbiBtYXkgYmUgZGV0ZWN0ZWQgYnkg T0FNIGFuZCByZXBvcnRlZCBhcyBhIGZhdWx0IG9yIGEgZGVncmFkYXRpb24gb2YgdHJhZmZpYyBk ZWxpdmVyeS7igJ0NCg0KLSBTZWN0aW9uIDUuNy4gVGhlcmUgbWF5IGJlIGNvb3JkaW5hdGlvbiBy ZXF1aXJlZCBvbiBzb2Z0LXByZWVtcHRpb24gYXMNCndlbGwgKGRlcGVuZGluZyBvbiB0aGUgY3Jv c3MtY29ubmVjdHMgZXN0YWJsaXNoZWQgZHVyaW5nIExTUA0KZXN0YWJsaXNobWVudCkgc28gY29v cmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBiZSBzdXBwb3J0ZWQNCmluZGVwZW5kZW50IG9mIHBy ZWVtcHRpb24gbW9kZS4NCg0KW0F1dGhvcnNdIFllcywgd2Ugd2lsbCBjaGFuZ2UgdGhlIHNlY29u ZCBwYXJhZ3JhcGggZnJvbSDigJxTTVAgaW4gaGFyZC1wcmVlbXB0aW9uIG1vZGUgU0hPVUxEIOKA puKAnSB0byDigJxTTVAgU0hPVUxEIOKApuKAnSBhbmQgbW92ZSB0aGUgY2hhbmdlZCBwYXJhZ3Jh cGggYWJvdmUgdGhlIGZpcnN0IHBhcmFncmFwaC4NCg0KDQpOaXRzOg0KDQotIEFic3RyYWN0OiBJ IGRvbid0IHJlY2FsbCB0aGUgdGVybSAiZXhlY3V0aXZlIGFjdGlvbiIgYmVpbmcgdXNlZCBpbiBh bnkNCmVhcmxpZXIgcmVsYXRlZC9yZWZlcmVuY2VkIFJGQ3MuIFJhdGhlciB0aGFuIGludHJvZHVj ZSBhIG5ldyAoYW5kDQp1bmRlZmluZWQpIHRlcm0sIHBlcmhhcHMgeW91IGNhbiB1c2UgYW4gZXhp c3Rpbmcgb25lLCBlLmcuLA0KInByb3RlY3Rpb24gc3dpdGNoIj8NCg0KW0F1dGhvcnNdIFllcywg dGhlIHRlcm0gd2lsbCBiZSBjaGFuZ2VkIGFzIHlvdSBzdWdnZXN0ZWQuDQoNCg0KLSBTZWN0aW9u IDEsIHBhcmFncmFwaCAxLiBEbyB3ZSByZWFsbHkgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2YN Ck1QTFMtVFAgdG8gZGViYXRlPyBJIHN1Z2dlc3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9y aXRlIE1QTFMtVFANCmRvY3VtZW50KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50 ZW5jZXMuDQoNClRoZSBsYXN0IHNlbnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0aXZlIHN0YXRl bWVudC4gV2hldGhlciBpdCBpcw0KY3JpdGljYWwgb3Igbm8gaXMgdW5uZWNlc3NhcnkuIFlvdSBj YW4ganVzdCBzYXkgc29tZXRoaW5nIGxpa2UgNjM3Mg0KcHJvdmlkZXMgYSBzdXJ2aXZhYmlsaXR5 IGZyYW1ld29yayBmb3IgTVBMUy1UUCBhbmQgaXMgdGhlIGZvdW5kYXRpb24NCmZvciB0aGlzIGRv Y3VtZW50Lg0KDQpbQXV0aG9yc10gVGhlIHByb3Bvc2VkIHRleHQgZm9yIHRoZSBwYXJhZ3JhcGgg MSBpczoNCuKAnFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBpcyBkZXNjcmli ZWQgaW4gW1JGQzU5MjFdLA0KYW5kIFtSRkM2MzcyXSBwcm92aWRlcyBhIHN1cnZpdmFiaWxpdHkg ZnJhbWV3b3JrIGZvciBNUExTLVRQDQphbmQgaXMgdGhlIGZvdW5kYXRpb24gZm9yIHRoaXMgZG9j dW1lbnQu4oCdDQoNCg0KLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAzLiBJc24ndCB0aGUgcmlnaHQg cmVmZXJlbmNlIDQ0Mjcgbm90IDQ0Mjg/DQpBbHNvIGRyb3AgdGhlIHdvcmQgbGluZWFyLCBhcyBp dCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZpZXIgYW5kDQo0NDI3LzQ0MjggZG9uJ3QgdXNlIGl0 Lg0KDQpbQXV0aG9yc10gT0suDQoNCg0KDQotIFNlY3Rpb25zIDMgKGFuZCB0byBhIGxlc3NlciBk ZWdyZWUgc2VjdGlvbiAyKSBhcmUgcmVhbGx5IGludHJvZHVjdG9yeQ0KdGV4dC4gSSdtIHVuc3Vy ZSBhcyB0byB3aHkgdGhleSBhcmVuJ3QgcGFydCBvZiBzZWN0aW9uIDEuDQoNCltBdXRob3JzXSBT ZWN0aW9uIDMgd2FzIGludGVuZGVkIHRvIHByZXNlbnQgYSByZWZlcmVuY2UgbW9kZWwgZm9yIFNN UC4gU29tZSB0ZXh0IG9mIFNlY3Rpb24gMiBpcyByZXBlYXRlZCBpbiBTZWN0aW9uIDEgYXMgeW91 IHN1Z2dlc3RlZCBlYXJsaWVyLg0KDQoNCg0KLSBTZWN0aW9uIDMuMiBzaG91bGQgaGF2ZSBhIHJl ZmVyZW5jZSBmb3IgImV4aXN0aW5nIGNvbnRyb2wgcGxhbmUNCnNvbHV0aW9ucyBmb3IgU01QIHdp dGhpbiBNUExTIi4NCg0KW0F1dGhvcnNdIFtSRkM0MjA2XSB3aWxsIGJlIGFkZGVkIGFzIGEgcmVm ZXJlbmNlDQoNCi0gU2VjdGlvbiAzLjIgYWdhaW4gdXNlcyB0aGUgImV4ZWN1dGl2ZSBhY3Rpb24i IHRlcm0uDQoNCltBdXRob3JzXSBPSywgdGhlIHRlcm0gd2lsbCBiZSBjaGFuZ2VkLg0KDQoNCi0g U2VjdGlvbiA0LjEuIFlvdSBzYXkgInR3byBvcGVyYXRpb25zIHNpbXVsdGFuZW91c2x5Ii4gRG8g eW91IHJlYWxseQ0KbWVhbiAic2ltdWx0YW5lb3VzbHkiIG9yIG1lcmVseSB0aGF0IHRoZXkgbXVz dCBib3RoIG9jY3VyIGZvcg0KcHJvdGVjdGlvbiB0byBiZSBwcm92aWRlZD8gKFNhbWUgY29tbWVu dCBpbiBzZWN0aW9uIDUuMS4NCg0KW0F1dGhvcnNdIEJvdGggYWN0aW9ucyBzaG91bGQgb2NjdXIg YXQgdGhlIHNhbWUgdGltZSwgb3IgYXMgY2xvc2VseSBhcyBwb3NzaWJsZSB0byBwcm92aWRlIGZh c3QgcHJvdGVjdGlvbi4NCg0KDQotIFNlY3Rpb24gNS4yLiBJIHN1Z2dlc3QgbnVtYmVyaW5nIHRo ZSBjdXJyZW50bHkgYnVsbGV0dGVkIHJlcXVpcmVtZW50cw0KbGlzdC4NCg0KW0F1dGhvcnNdIE9L LCB3ZSB3aWxsIHVzZSBudW1iZXJzLg0KDQoNCi0gU2VjdGlvbiA1LjI6IEZpcnN0IHBhcmFncmFw aCBhbmQgZm9ydGggYnVsbGV0IGxhc3Qgc2VudGVuY2UuIFRoZXNlDQpib3RoIGJhc2ljYWxseSBj b3ZlciB0aGUgc2FtZSB0b3BpYyAocHJlZW1wdGlvbikgYW5kIGFjdHVhbGx5IHNheQ0Kc2xpZ2h0 bHkgZGlmZmVyZW50IHRoaW5ncy4gSSBzdWdnZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZQ0KcmVx dWlyZW1lbnQgdG8gZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBmdWxsIGNvdmVyYWdlIG9mIHRoZSB0 b3BpYy4NCg0KW0F1dGhvcnNdIFRoZSBmaXJzdCBwYXJhZ3JhcGggaXMgZm9yIHNvZnQtcHJlZW1w dGlvbiwgd2hpbGUgdGhlIGZvdXJ0aCBidWxsZXQgYmVsb25ncyB0byB0aGUgcmVxdWlyZW1lbnRz IG9mIGhhcmQtcHJlZW1wdGlvbi4NCg0KLSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRo aXMgcmVsYXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3QNCnRoZSB0b3BpY3MgcmVsYXRlZCB0 byB0aW1pbmcgYmUgY29uc29saWRhdGVkPw0KDQpbQXV0aG9yc10gWWVzLCByZXEgNSBjYW4gYmUg bW92ZWQgdG8gU2VjdGlvbiA1LjUuDQoNCg0KLSBTZWN0aW9uIDUuMjogcmVxdWlyZW1lbnQgNiBz ZWVtcyB0byBiZSBhIHN1YnNldCBvZiA3LCBzbyBpdCBzaG91bGQgYmUNCmRyb3BwZWQuDQoNCltB dXRob3JzXSBZZXMsIGl0IHdpbGwgYmUgZGVsZXRlZC4NCg0KLSBTZWN0aW9uIDUuMiwgcmVxdWly ZW1lbnQgOC4gSXNuJ3QgdGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCmp1c3QgdGhp cyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/DQoNCltBdXRob3JzXSBS ZXEuIDkgd2lsbCBiZSBkZWxldGVkIGFzIGl0IHNlZW1zIHRvIHJlcXVpcmUgY29udHJvbCBwbGFu ZSBzdXBwb3J0cy4NCg0KDQotIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsDQoNCltBdXRob3JzXSBP Sy4NCg0KDQotIHNlY3Rpb24gNS40OiAiIFdoZW4gdGhlIHdvcmtpbmcgcGF0aCBkZXRlY3RzLi4i IGRldGVjdGlvbiBpcyBieSB0aGUNCm5vZGUgbm90IHRoZSBwYXRoLg0KDQpbQXV0aG9yc10gWWVz LiBXZSB3aWxsIHNpbXBseSBzYXkgdGhhdCDigJxXaGVuIHRoZSBjb25kaXRpb24gdGhhdCB0cmln Z2VyZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIGNsZWFyZWQsIOKApuKAnQ0KDQotIFNl Y3Rpb24gNS40LCBsYXN0IHNlbnRlbmNlLiBUaGlzIGlzIG9ubHkgdGhlIDJuZCB0aW1lIHlvdSBp bXBseSB0aGF0DQp0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBhIG5ldyBwcm90 b2NvbC4gSSB0aGluayB0aGlzDQpwb2ludCBpcyBjdXJyZW50bHkgdG9vIHN1YnRsZSBpbiB0aGUg ZG9jdW1lbnQuIChUaGlzIHBvaW50IHdhcyBhbHNvDQptYWRlIGFzIGEgbWlub3IgY29tbWVudC4p DQoNCltBdXRob3JzXSBBcyBpbiBvdGhlciBwcm90ZWN0aW9uIHN3aXRjaGluZyB0ZWNobm9sb2dp ZXMsIHR3byBtb2RlcyBvZiBvcGVyYXRpb25zIChyZXZlcnRpdmUgYW5kIG5vbi1yZXZlcnRpdmUp IGFyZSByZXF1aXJlZC4NCg0KDQotIHNlY3Rpb24gNS42LiBSRkMgNjM3MiBzaG91bGQgYmUgcmVm ZXJlbmNlZA0KW0F1dGhvcnNdIFdlIHdpbGwgYWRkIOKAnGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3 Ml3igJ0gdG8gdGhlIGVuZHMgb2YgdHdvIHBhcmFncmFwaHMgZm9yIFdUUiB0aW1lciBhbmQgaG9s ZC1vZmYgdGltZXIuDQoNCioqKioqIEVuZCBvZiBDb21tZW50IHJlc29sdXRpb24gKioqKioNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K67O064K4IOyCrOuejCA6 ICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4NCuuztOuCuCDrgqDsp5wgOiAyMDE0LTA2 LTIyIDAxOjAwOjQ4ICggKzA5OjAwICkNCuuwm+uKlCDsgqzrnowgOiBydGctYWRzQHRvb2xzLmll dGYub3JnIDxydGctYWRzQHRvb2xzLmlldGYub3JnPg0K7LC47KGwIDogcnRnLWRpckBpZXRmLm9y ZyA8cnRnLWRpckBpZXRmLm9yZz4sIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFs bEB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRv b2xzLmlldGYub3JnPiwgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz4NCuygnOuqqSA6IFtt cGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50 eHQNCg0KDQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMNCmRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0 ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3INCnJvdXRpbmctcmVsYXRlZCBkcmFmdHMg YXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cNCnJldmlldywgYW5k IHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcg aXMNCnRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IHRoZQ0KUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRo b3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0 aW5nIEFEcywgaXQNCndvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0g YWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURg0KTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJl Y2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gNCmRpc2N1c3Npb24gb3Ig YnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMtMDYudHh0DQpSZXZpZXdlcjogTG91IEJlcmdlcg0KUmV2aWV3IERhdGU6IEp1 bmUgMjEgMjAxNA0KSUVURiBMQyBFbmQgRGF0ZTogMjAxNC0wNi0yMw0KSW50ZW5kZWQgU3RhdHVz OiBJbmZvcm1hdGlvbmFsDQoNClN1bW1hcnk6DQpJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBh Ym91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluaw0Kc2hvdWxkIChtdXN0LCBhY3R1YWxseSkg YmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KDQpDb21tZW50czoNCg0KSSB0aGluayB0 aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCwgb3RoZXIgdGhhbiBhIGNvdXBsZSBvZg0K dGVybWlub2xvZ3kgcmVsYXRlZCBpc3N1ZXMsIGVhc2lseSB1bmRlcnN0b29kLiBUaGUgZG9jdW1l bnQgZG9lcw0KaGF2ZSBhIG51bWJlciBvZiB0ZXJtaW5vbG9neSBhbmQgdGVjaG5pY2FsIGlzc3Vl cyB3aGljaCBzaG91bGQgYmUNCnJlYWRpbHkgcmVzb2x2ZWQgcHJpb3IgdG8gcHVibGljYXRpb24u DQoNCk1ham9yIElzc3VlczoNCg0KTWFqb3IgaXNzdWVzIGFyZSB0aGUgdHlwZSBvZiBjb25jZXJu cyB0aGF0IHdpbGwgcmVzdWx0IGluIHRoZQ0KZG9jdW1lbnQgYmVpbmcgYmxvY2tlZCB1bnRpbCB0 aGV5IGFyZSByZXNvbHZlZC4gVGhlIFJvdXRpbmcgQURzIHdpbGwNCmJlY29tZSBpbnZvbHZlZC4g UGxlYXNlIGluY2x1ZGUgYWxsIG9mIHRoZSBtYWpvciBpc3N1ZXMgeW91IGhhdmUNCmZvdW5kLiBH aXZlIGFzIG11Y2ggY29udGV4dCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSAoZS5nLiwgc2VjdGlv bg0KbnVtYmVycywgcGFyYWdyYXBoIGNvdW50cykuIElmIHlvdSBmaW5kIG5vIG1ham9yIGlzc3Vl cywgcGxlYXNlDQp3cml0ZTogIk5vIG1ham9yIGlzc3VlcyBmb3VuZC4iDQoNCi0gTm8gbWFqb3Ig aXNzdWVzIGZvdW5kLiBJbiBwYXJ0aWN1bGFyLCBJIGV4cGVjdCBhbGwgaXNzdWVzIGNhbiBiZQ0K cmVzb2x2ZWQgd2l0aG91dCBBRCBpbnRlcnZlbnRpb24uIFNvbWUgb2YgdGhlIG1pbm9yIGlzc3Vl cywgaWYgbm90DQpyZXNvbHZlZCB3aWxsIGJlIGVzY2FsYXRlZCB0byB0aGUgQUQvbWFqb3IgaXNz dWUgY2F0ZWdvcnkuDQoNCk1pbm9yIElzc3VlczoNCg0KTWlub3IgaXNzdWVzIGFyZSBjb25jZXJu cyBhYm91dCBjbGFyaXR5IG9yIHRlY2huaWNhbCBhY2N1cmFjeSB0aGF0DQpzaG91bGQgYmUgZGlz Y3Vzc2VkIGFuZCByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24sIGJ1dCB3aGljaCB3b3VsZA0K bm9ybWFsbHkgYmUgcmVzb2x2ZWQgYmV0d2VlbiB0aGUgYXV0aG9ycyBhbmQgdGhlIHJldmlld2Vy cy4gUGxlYXNlDQppbmNsdWRlIGFsbCBvZiB0aGUgbWlub3IgaXNzdWVzIHlvdSBoYXZlIGZvdW5k LiBHaXZlIGFzIG11Y2ggY29udGV4dA0KaW5mb3JtYXRpb24gYXMgcG9zc2libGUgKGUuZy4sIHNl Y3Rpb24gbnVtYmVycywgcGFyYWdyYXBoIGNvdW50cykuDQpJZiB5b3UgZmluZCBubyBtaW5vciBp c3N1ZXMsIHBsZWFzZSB3cml0ZTogIk5vIG1pbm9yIGlzc3VlcyBmb3VuZC4iDQoNCi0gRG9jdW1l bnQncyB1c2FnZSBvZiAiY29tbWl0dGVkIiB2cyAiYWxsb2NhdGVkIiByZXNvdXJjZXM6DQoNCklu IHNlY3Rpb24gMSB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgbm90aW9uIHRoYXQgdGhlDQpk aXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIGJhc2VkIG9u IHdoZW4NCnJlc291cmNlcyBhcmUgImNvbW1pdHRlZCIuIFRoaXMgZGlmZmVyZW5jZSBmcm9tIHBh c3QNCmRlZmluaXRpb24uIFJGQzQ0MjcgYW5kIDYzNzIgbWFrZSB0aGUgZGlzdGluY3Rpb24gdGhh dCBwcm90ZWN0aW9uDQphbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3Vy Y2VzIGFyZSAqYWxsb2NhdGVkKiBub3QNCipjb21taXR0ZWQqLiBUbyBxdW90ZSBSRkMgNDQyNzoN Cg0KVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gaXMg bWFkZSBiYXNlZA0Kb24gdGhlIHJlc291cmNlIGFsbG9jYXRpb24gZG9uZSBkdXJpbmcgdGhlIHJl Y292ZXJ5IExTUC9zcGFuDQplc3RhYmxpc2htZW50LiBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBk aWZmZXJlbnQgdHlwZXMgb2YNCnJlc3RvcmF0aW9uIGlzIG1hZGUgYmFzZWQgb24gdGhlIGxldmVs IG9mIHJvdXRlIGNvbXB1dGF0aW9uLA0Kc2lnbmFsaW5nLCBhbmQgcmVzb3VyY2UgYWxsb2NhdGlv biBkdXJpbmcgdGhlIHJlc3RvcmF0aW9uDQpMU1Avc3BhbiBlc3RhYmxpc2htZW50Lg0KDQpUaGlz IGRpZmZlcmVuY2UgYWxzbyBsZWFkcyB0byBjb21lIGNvbmZ1c2VkIHN0YXRlbWVudHMgaW4gdGhl DQpkb2N1bWVudCBhcyB3ZWxsIGFzIGFtYmlndWl0eSBpbiB0aGUgdGV4dCwgaS5lLiBjb25mdXNp b24gYnkgdGhlDQpyZWFkZXIuIFRoZSB0ZXJtICJjb21taXR0ZWQiIGlzIG5vdCB0aWdodGx5IGRl ZmluZWQgaW4gdGhpcw0KZG9jdW1lbnQgKG9yIGVhcmxpZXIgd29yaykgYW5kIGlzIHVzZWQgZGlm ZmVyZW50bHkgdGhhbiBob3cNCiJhbGxvY2F0ZWQiIGhhcyBiZWVuIHVzZWQuIEFuIGV4YW1wbGUg b2YgdGhpcyBjYW4gYmUgZm91bmQgaW4NClNlY3Rpb24gMy4xIHdoaWNoIHN0YXRlczoNCg0KSG93 ZXZlciwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcywgYXQgbGVhc3QgZm9yIHRoZQ0K c2hhcmVkIHNlZ21lbnRzLCB3aWxsIG9ubHkgYmUgZmluYWxpemVkIHdoZW4gdGhlIHByb3RlY3Rp b24NCnBhdGggaXMgYWN0dWFsbHkgYWN0aXZhdGVkLiBUaGVyZWZvcmUsIGZvciB0aGUgcHVyaXN0 cyAtDQpyZWdhcmRpbmcgdGhlIHRlcm1pbm9sb2d5IC0gU01QIGxpZXMgc29tZXdoZXJlIGJldHdl ZW4NCnByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uLg0KDQpCb3RoIHNlbnRlbmNlcyBhcmUgcHJv YmxlbWF0aWMuIEluIHRoZSBmaXJzdCwgY29tbWl0bWVudCBzZWVtcyB0bw0KY292ZXIgYSAicHJv dGVjdGlvbiBzd2l0Y2giIHdvdWxkICJjb25uZWN0IiB0aGUgcHJvdGVjdGlvbiBwYXRoDQpidXQg bm90IHRoZSBlYXJsaWVyICJhbGxvY2F0aW9uIiBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMg YXJlDQp1c2VkIGluIGVhcmxpZXIgUkZDcy4pIFRoZSBzZWNvbmQgY29uY2x1c2lvbiBpcyBiYXNl ZCBvbiB0aGUgbmV3DQpkaXN0aW5jdGlvbiBvZiBwcm90ZWN0aW9uIHZzLiByZXN0b3JhdGlvbiBh bmQgaXMgdW5uZWNlc3Nhcnkgd2l0aA0KdGhlIGV4aXN0aW5nIGRpc3RpbmN0aW9uLg0KDQpUaGlz IGlzc3VlIGV4aXN0cyBpbiBtdWx0aXBsZSBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlDQoi Y29tbWl0dGVkIiBpcyB1c2VkIGFuZCBJJ2QgcmVjb21tZW5kIHRoYXQgZWFjaCBzaG91bGQgYmUg cmVwbGFjZWQNCndpdGggdGVybWlub2xvZ3kgdXNlZCBpbiB0aGUgcmVmZXJlbmNlZCBSRkNzLCBp LmUuLCAiYWxsb2NhdGlvbiIsDQoiY29ubmVjdGlvbiIsICJjcm9zcy1jb25uZWN0IiwgInByb3Rl Y3Rpb24gc3dpdGNoKG92ZXIpIiwgLi4uDQoNCk5vdGUgSSdtICpub3QqIGhpZ2hsaWdodGluZyBh bGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2JsZW1zIGluIHRoZQ0KZG9jdW1lbnQgcmVsYXRl ZCB0byB0aGlzIGlzc3VlLiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcGxhY2VzIGluIHRoZQ0KZG9j dW1lbnQgd2hlcmUgSSB0aGluayBpdCdzIHBvc3NpYmxlIHRoYXQgb25jZSB0aGlzIHRlcm1pbm9s b2d5DQphbWJpZ3VpdHkgaXMgY29ycmVjdGVkIHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1YnN0YW50 aXZlIGNvbW1lbnRzLg0KDQotIFNlY3Rpb24gMiwgMXN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5j ZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkgZGVmaW5lcw0KdGhlIHNjb3BlL3B1cnBvc2Ugb2YgdGhl IGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlvbnMNCnRvIHByb3RvY29s IGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0aGUNCnJlcXVpcmVt ZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNoLCBJJ2QgcmVwZWF0IHRoaXMg aW4NCnRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJvbm91bmNlZCBwbGFjZSBp biBzZWN0aW9uIDEgKG9yDQozKS4NCg0KLSBHZW5lcmFsIGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBm b3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQpwcm90ZWN0aW9uOiBIb3cgaXMgY28tcm91 dGluZyBwcmVzZXJ2ZWQgZm9yIHRoZSByZXZlcnNlIHBhdGggaW4gU01QPw0KSSdkIGFzc3VtZWQg dGhlIHByb3RlY3Rpb24gc3dpdGNoIGNvb3JkaW5hdGlvbiBwcm90b2NvbCB3b3VsZCBiZQ0KcmVx dWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVyc2UgTFNQIGluIHRoZSBj by1yb3V0ZWQNCmNhc2UsIGJ1dCBkb24ndCBzZWUgdGhpcyBpbiB0aGUgZG9jdW1lbnQuDQoNCi0g SW4gc2VjdGlvbiA0IGFuZCA1LjIgeW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRlZmlu aW5nDQpwcmVlbXB0aW9uIHRlcm1pbm9sb2d5IGFuZCBiZWhhdmlvci4gSSB0aGluayA2MzcyIGlz IHRoZSByaWdodA0KcmVmZXJlbmNlIGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBjb250 ZXh0IG9mIHN1cnZpdmFiaWxpdHkgYW5kDQppbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFuZS4N Cg0KLSBJbiBzZWN0aW9uIDQuMiB5b3Ugc2F5ICJUaGVyZWZvcmUsIGl0IGlzIHN1Z2dlc3RlZCB0 aGF0IHRoaXMgYmUNCmNhcnJpZWQgb3V0IHVuZGVyIHRoZSBjb250cm9sIG9mIGEgZHluYW1pYyBj b250cm9sIHBsYW5lIHNpbWlsYXIgdG8NCkdNUExTIFtSRkMzOTQ1XS4iIHBlcmhhcHMgeW91IG1l YW4gImJhc2VkIG9uIEdNUExTIj8gSWYgc28sIGdyZWF0LA0KcGxlYXNlIG1ha2UgdGhlIGNvcnJl Y3Rpb24uIElmIG5vdCwgSSB0aGluayB0aGUgZGViYXRlIG9mIHdoaWNoDQpjb250cm9sIHByb3Rv Y29sIGlzIHVzZWQgZm9yIE1QTFMtVFAgaXMgd2F5IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcw0K ZG9jdW1lbnQuDQoNCi0gU2VjdGlvbiA1LjEsIHBhcmFncmFwaCAxLiBXaHkgYXJlIHlvdSB1c2lu ZyAiU0hPVUxEIE5PVCIgaGVyZT8gSWYNCnJlZmVycmluZyB0byBzb2x1dGlvbnMgY29uZm9ybWFu dCB3aXRoIHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlc2UgYXJlDQppbmZvcm1hdGl2ZSBzdGF0ZW1l bnRzLCAiYW5kIGEgbm9uLWNvbnRyb2wgcGxhbmUgYmFzZWQgU01QIHN3aXRjaG92ZXINCm1lY2hh bmlzbSBpcyB1c2VkLCB0aGUgY29udHJvbCBwbGFuZSBTSEFMTCBOT1QgLi4uIi4gSWYgcmVmZXJy aW5nIHRvDQphbiBvcGVyYXRvcidzL3VzZXIncyBjaG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNoYW5p c20sIEkgdGhpbmsgdGhlIG1vc3QNCnlvdSBjYW4gc2F5IGlzIE1BWS4NCg0KLSBTZWN0aW9uIDUu Mi4gIlRpZS1icmVha2luZyBydWxlcyBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNN UA0KZG9tYWluLiIgQXMgdGhpcyBpcyBhIHJlcXVpcmVtZW50LCB3aGF0IHlvdSBtZWFuIGJ5ICJ0 aWUtYnJlYWtpbmcNCnJ1bGVzIiBzaG91bGQgYmUgZGVmaW5lZCBkaXJlY3RseSBvciBieSByZWZl cmVuY2UuDQoNCi0gU2VjdGlvbiA1LjMuIFJGQzYzNzIgdGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUg cHJlZW1wdGlvbiBub3RpZmljYXRpb24NCmxldmVyYWdlcyB0aGUgc3RhbmRhcmQgTVBMUy1UUCBP QU0gbWVjaGFuaXNtcywgaXMgdGhlcmUgYW55IHJlYXNvbiB0bw0KZG8gbW9yZSAvIG5vdCBqdXN0 IGZvbGxvdyA2MzcyPw0KDQotIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9u IHJlcXVpcmVkIG9uIHNvZnQtcHJlZW1wdGlvbiBhcw0Kd2VsbCAoZGVwZW5kaW5nIG9uIHRoZSBj cm9zcy1jb25uZWN0cyBlc3RhYmxpc2hlZCBkdXJpbmcgTFNQDQplc3RhYmxpc2htZW50KSBzbyBj b29yZGluYXRlZCBzd2l0Y2hpbmcgc2hvdWxkIGJlIHN1cHBvcnRlZA0KaW5kZXBlbmRlbnQgb2Yg cHJlZW1wdGlvbiBtb2RlLg0KDQpOaXRzOg0KDQotIEFic3RyYWN0OiBJIGRvbid0IHJlY2FsbCB0 aGUgdGVybSAiZXhlY3V0aXZlIGFjdGlvbiIgYmVpbmcgdXNlZCBpbiBhbnkNCmVhcmxpZXIgcmVs YXRlZC9yZWZlcmVuY2VkIFJGQ3MuIFJhdGhlciB0aGFuIGludHJvZHVjZSBhIG5ldyAoYW5kDQp1 bmRlZmluZWQpIHRlcm0sIHBlcmhhcHMgeW91IGNhbiB1c2UgYW4gZXhpc3Rpbmcgb25lLCBlLmcu LA0KInByb3RlY3Rpb24gc3dpdGNoIj8NCg0KLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAxLiBEbyB3 ZSByZWFsbHkgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2YNCk1QTFMtVFAgdG8gZGViYXRlPyBJ IHN1Z2dlc3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9yaXRlIE1QTFMtVFANCmRvY3VtZW50 KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMuDQoNClRoZSBsYXN0IHNl bnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0aXZlIHN0YXRlbWVudC4gV2hldGhlciBpdCBpcw0K Y3JpdGljYWwgb3Igbm8gaXMgdW5uZWNlc3NhcnkuIFlvdSBjYW4ganVzdCBzYXkgc29tZXRoaW5n IGxpa2UgNjM3Mg0KcHJvdmlkZXMgYSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1U UCBhbmQgaXMgdGhlIGZvdW5kYXRpb24NCmZvciB0aGlzIGRvY3VtZW50Lg0KDQotIFNlY3Rpb24g MSwgcGFyYWdyYXBoIDMuIElzbid0IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBub3QgNDQyOD8N CkFsc28gZHJvcCB0aGUgd29yZCBsaW5lYXIsIGFzIGl0IGlzIGFuIHVubmVjZXNzYXJ5IHF1YWxp ZmllciBhbmQNCjQ0MjcvNDQyOCBkb24ndCB1c2UgaXQuDQoNCi0gU2VjdGlvbnMgMyAoYW5kIHRv IGEgbGVzc2VyIGRlZ3JlZSBzZWN0aW9uIDIpIGFyZSByZWFsbHkgaW50cm9kdWN0b3J5DQp0ZXh0 LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0aGV5IGFyZW4ndCBwYXJ0IG9mIHNlY3Rpb24gMS4NCg0K LSBTZWN0aW9uIDMuMiBzaG91bGQgaGF2ZSBhIHJlZmVyZW5jZSBmb3IgImV4aXN0aW5nIGNvbnRy b2wgcGxhbmUNCnNvbHV0aW9ucyBmb3IgU01QIHdpdGhpbiBNUExTIi4NCg0KLSBTZWN0aW9uIDMu MiBhZ2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZlIGFjdGlvbiIgdGVybS4NCg0KLSBTZWN0aW9uIDQu MS4gWW91IHNheSAidHdvIG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3UgcmVhbGx5 DQptZWFuICJzaW11bHRhbmVvdXNseSIgb3IgbWVyZWx5IHRoYXQgdGhleSBtdXN0IGJvdGggb2Nj dXIgZm9yDQpwcm90ZWN0aW9uIHRvIGJlIHByb3ZpZGVkPyAoU2FtZSBjb21tZW50IGluIHNlY3Rp b24gNS4xLg0KDQotIFNlY3Rpb24gNS4yLiBJIHN1Z2dlc3QgbnVtYmVyaW5nIHRoZSBjdXJyZW50 bHkgYnVsbGV0dGVkIHJlcXVpcmVtZW50cw0KbGlzdC4NCg0KLSBTZWN0aW9uIDUuMjogRmlyc3Qg cGFyYWdyYXBoIGFuZCBmb3J0aCBidWxsZXQgbGFzdCBzZW50ZW5jZS4gVGhlc2UNCmJvdGggYmFz aWNhbGx5IGNvdmVyIHRoZSBzYW1lIHRvcGljIChwcmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkgc2F5 DQpzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzLiBJIHN1Z2dlc3QgY29tYmluZSBpbnRvIGEgc2lu Z2xlDQpyZXF1aXJlbWVudCB0byBlbnN1cmUgY29uc2lzdGVuY3kgYW5kIGZ1bGwgY292ZXJhZ2Ug b2YgdGhlIHRvcGljLg0KDQotIFNlY3Rpb24gNS4yLCByZXEgNS4gSG93IGRvZXMgdGhpcyByZWxh dGUgdG8gc2VjdGlvbiA1LjU/IFNob3VsZG4ndA0KdGhlIHRvcGljcyByZWxhdGVkIHRvIHRpbWlu ZyBiZSBjb25zb2xpZGF0ZWQ/DQoNCi0gU2VjdGlvbiA1LjI6IHJlcXVpcmVtZW50IDYgc2VlbXMg dG8gYmUgYSBzdWJzZXQgb2YgNywgc28gaXQgc2hvdWxkIGJlDQpkcm9wcGVkLg0KDQotIFNlY3Rp b24gNS4yLCByZXF1aXJlbWVudCA4LiBJc24ndCB0aGlzIGEgc3Vic2V0IG9mIDk/IFdoeSBjYWxs IG91dA0KanVzdCB0aGlzIG9uZSB0cmFmZmljIHRyZWF0bWVudCAoc3ViKSByZXF1aXJlbWVudD8N Cg0KLSBTZWN0aW9uIDUuMy4gcy9NQVkvd2lsbA0KDQotIHNlY3Rpb24gNS40OiAiIFdoZW4gdGhl IHdvcmtpbmcgcGF0aCBkZXRlY3RzLi4iIGRldGVjdGlvbiBpcyBieSB0aGUNCm5vZGUgbm90IHRo ZSBwYXRoLg0KDQotIFNlY3Rpb24gNS40LCBsYXN0IHNlbnRlbmNlLiBUaGlzIGlzIG9ubHkgdGhl IDJuZCB0aW1lIHlvdSBpbXBseSB0aGF0DQp0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50 cyBvbiBhIG5ldyBwcm90b2NvbC4gSSB0aGluayB0aGlzDQpwb2ludCBpcyBjdXJyZW50bHkgdG9v IHN1YnRsZSBpbiB0aGUgZG9jdW1lbnQuIChUaGlzIHBvaW50IHdhcyBhbHNvDQptYWRlIGFzIGEg bWlub3IgY29tbWVudC4pDQoNCi0gc2VjdGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBiZSByZWZl cmVuY2VkDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIw cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPkRlYXIgTG91LDwvZm9udD48L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciB2YWx1YWJsZSBj b21tZW50cy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+VGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBoYXZlIGRpc2N1c3NlZCB5b3VyIGNv bW1lbnRzLCBhbmQgYXJlIHByb3Bvc2luZyBvdXIgcmVzb2x1dGlvbnMgdG8geW91ciBjb21tZW50 cy4gUGxlYXNlLCBsZXQgdXMga25vdyBpZiB0aGUgcHJvcG9zYWwgaXMgYXBwcm9wcmlhdGUgdG8g YWRkcmVzcyB5b3VyIGNvbW1lbnRzIGFuZCBjb25jZXJucy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QmVzdCByZWdhcmRzLDwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj5BdXRob3Jz IG9mIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzIGRyYWZ0PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj4qKioqKiogQmVnaW5uaW5nIG9mIENvbW1lbnQgUmVzb2x1 dGlvbiAqKioqKio8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gRG9jdW1l bnQncyB1c2FnZSBvZiAmcXVvdDtjb21taXR0ZWQmcXVvdDsgdnMgJnF1b3Q7YWxsb2NhdGVkJnF1 b3Q7IHJlc291cmNlczo8YnI+DQo8YnI+DQpJbiBzZWN0aW9uIDEgdGhlIGRvY3VtZW50IGludHJv ZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZTxicj4NCmRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVj dGlvbiBhbmQgcmVzdG9yYXRpb24gaXMgYmFzZWQgb24gd2hlbjxicj4NCnJlc291cmNlcyBhcmUg JnF1b3Q7Y29tbWl0dGVkJnF1b3Q7LiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBwYXN0PGJyPg0KZGVm aW5pdGlvbi4gUkZDNDQyNyBhbmQgNjM3MiBtYWtlIHRoZSBkaXN0aW5jdGlvbiB0aGF0IHByb3Rl Y3Rpb248YnI+DQphbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3VyY2Vz IGFyZSAqYWxsb2NhdGVkKiBub3Q8YnI+DQoqY29tbWl0dGVkKi4gVG8gcXVvdGUgUkZDIDQ0Mjc6 PGJyPg0KPGJyPg0KVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9y YXRpb24gaXMgbWFkZSBiYXNlZDxicj4NCm9uIHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uIGRvbmUg ZHVyaW5nIHRoZSByZWNvdmVyeSBMU1Avc3Bhbjxicj4NCmVzdGFibGlzaG1lbnQuIFRoZSBkaXN0 aW5jdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZjxicj4NCnJlc3RvcmF0aW9uIGlzIG1h ZGUgYmFzZWQgb24gdGhlIGxldmVsIG9mIHJvdXRlIGNvbXB1dGF0aW9uLDxicj4NCnNpZ25hbGlu ZywgYW5kIHJlc291cmNlIGFsbG9jYXRpb24gZHVyaW5nIHRoZSByZXN0b3JhdGlvbjxicj4NCkxT UC9zcGFuIGVzdGFibGlzaG1lbnQuPGJyPg0KPGJyPg0KVGhpcyBkaWZmZXJlbmNlIGFsc28gbGVh ZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZTxicj4NCmRvY3VtZW50IGFzIHdl bGwgYXMgYW1iaWd1aXR5IGluIHRoZSB0ZXh0LCBpLmUuIGNvbmZ1c2lvbiBieSB0aGU8YnI+DQpy ZWFkZXIuIFRoZSB0ZXJtICZxdW90O2NvbW1pdHRlZCZxdW90OyBpcyBub3QgdGlnaHRseSBkZWZp bmVkIGluIHRoaXM8YnI+DQpkb2N1bWVudCAob3IgZWFybGllciB3b3JrKSBhbmQgaXMgdXNlZCBk aWZmZXJlbnRseSB0aGFuIGhvdzxicj4NCiZxdW90O2FsbG9jYXRlZCZxdW90OyBoYXMgYmVlbiB1 c2VkLiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJlIGZvdW5kIGluPGJyPg0KU2VjdGlvbiAzLjEg d2hpY2ggc3RhdGVzOjxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSBjb21taXRtZW50IG9mIHRoZSBy ZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGU8YnI+DQpzaGFyZWQgc2VnbWVudHMsIHdpbGwgb25s eSBiZSBmaW5hbGl6ZWQgd2hlbiB0aGUgcHJvdGVjdGlvbjxicj4NCnBhdGggaXMgYWN0dWFsbHkg YWN0aXZhdGVkLiBUaGVyZWZvcmUsIGZvciB0aGUgcHVyaXN0cyAtPGJyPg0KcmVnYXJkaW5nIHRo ZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVyZSBiZXR3ZWVuPGJyPg0KcHJvdGVjdGlv biBhbmQgcmVzdG9yYXRpb24uPGJyPg0KPGJyPg0KQm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1h dGljLiBJbiB0aGUgZmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG88YnI+DQpjb3ZlciBhICZxdW90 O3Byb3RlY3Rpb24gc3dpdGNoJnF1b3Q7IHdvdWxkICZxdW90O2Nvbm5lY3QmcXVvdDsgdGhlIHBy b3RlY3Rpb24gcGF0aDxicj4NCmJ1dCBub3QgdGhlIGVhcmxpZXIgJnF1b3Q7YWxsb2NhdGlvbiZx dW90OyBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMgYXJlPGJyPg0KdXNlZCBpbiBlYXJsaWVy IFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFzZWQgb24gdGhlIG5ldzxicj4NCmRp c3RpbmN0aW9uIG9mIHByb3RlY3Rpb24gdnMuIHJlc3RvcmF0aW9uIGFuZCBpcyB1bm5lY2Vzc2Fy eSB3aXRoPGJyPg0KdGhlIGV4aXN0aW5nIGRpc3RpbmN0aW9uLjxicj4NCjxicj4NClRoaXMgaXNz dWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQgd2hlcmU8YnI+DQom cXVvdDtjb21taXR0ZWQmcXVvdDsgaXMgdXNlZCBhbmQgSSdkIHJlY29tbWVuZCB0aGF0IGVhY2gg c2hvdWxkIGJlIHJlcGxhY2VkPGJyPg0Kd2l0aCB0ZXJtaW5vbG9neSB1c2VkIGluIHRoZSByZWZl cmVuY2VkIFJGQ3MsIGkuZS4sICZxdW90O2FsbG9jYXRpb24mcXVvdDssPGJyPg0KJnF1b3Q7Y29u bmVjdGlvbiZxdW90OywgJnF1b3Q7Y3Jvc3MtY29ubmVjdCZxdW90OywgJnF1b3Q7cHJvdGVjdGlv biBzd2l0Y2gob3ZlcikmcXVvdDssIC4uLjxicj4NCjxicj4NCk5vdGUgSSdtICpub3QqIGhpZ2hs aWdodGluZyBhbGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2JsZW1zIGluIHRoZTxicj4NCmRv Y3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNl cyBpbiB0aGU8YnI+DQpkb2N1bWVudCB3aGVyZSBJIHRoaW5rIGl0J3MgcG9zc2libGUgdGhhdCBv bmNlIHRoaXMgdGVybWlub2xvZ3k8YnI+DQphbWJpZ3VpdHkgaXMgY29ycmVjdGVkIHRoYXQgSSds bCBoYXZlIG90aGVyIHN1YnN0YW50aXZlIGNvbW1lbnRzLjwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9S OiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5bQXV0aG9yc10gQWZ0ZXIgcmV2aWV3 aW5nIFJGQ3MgNDQyNywgNjM3MiwgMzk0NSwgNDQyNiwgYW5kIDQ0MjgsIHdlIGNvbmNsdWRlZCB0 aGF0IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIHNo b3VsZCBiZSBhbGlnbmVkIHdpdGggdGhlIGV4aXRpbmcgZG9jdW1lbnRzIG5vcm1hdGl2ZWx5IHJl ZmVyZW5jZWQNCiBieSB0aGlzIGRvY3VtZW50LiBBY2NvcmRpbmdseSwgdGhlIGZvbGxvd2luZyAx NiBtb2RpZmljYXRpb25zIHdpbGwgYmUgZG9uZSBpbiByZXZpc2lvbjo8L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+KDEpIFNlY3Rpb24gMSwg dGhlIHRoaXJkIHBhcmFncmFwaDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5BcyBwb2ludGVkIG91dDwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPmluIFtSRkM2MzcyXSBhbmQgW1JGQzQ0MjhdLCBhcHBseWluZyAxJiM0MzsxIGxpbmVh ciBwcm90ZWN0aW9uIHJlcXVpcmVzPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhhdCByZXNvdXJjZXMgYXJlIGNvbW1pdHRl ZCBmb3IgdXNlIGJ5IGJvdGggdGhlIHdvcmtpbmcgYW5kPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJvdGVjdGlvbiBwYXRo cy4gQXBwbHlpbmcgMToxIHByb3RlY3Rpb24gcmVxdWlyZXMgdGhhdCB0aGUgc2FtZTwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnJlc291cmNlcyBhcmUgY29tbWl0dGVkLCBidXQgYWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhl IHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj5wYXRoIHRvIGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUg ZXh0cmEgdHJhZmZpYy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QXMgcG9pbnRlZCBvdXQ8L2ZvbnQ+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVw LWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SV Ij5pbiBbUkZDNjM3Ml0gYW5kIFtSRkM0NDI4XSwgYXBwbHlpbmcgMSYjNDM7MSBwcm90ZWN0aW9u IHJlcXVpcmVzPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i V09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBu b3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+dGhhdCByZXNvdXJjZXMgYXJlIGFsbG9jYXRlZCBmb3IgdXNlIGJ5 IGJvdGggdGhlIHdvcmtpbmcgYW5kPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJvdGVjdGlvbiBwYXRocy4gQXBwbHlpbmcg MToxIHByb3RlY3Rpb24gcmVxdWlyZXMgdGhhdCB0aGUgc2FtZTwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnJlc291cmNlcyBh cmUgYWxsb2NhdGVkLCBidXQgYWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhlIHByb3RlY3Rpb248 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5wYXRoIHRvIGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUgZXh0cmEgdHJhZmZp Yy48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+KDIpIFRoZSB3aG9sZSB0ZXh0IGluIFNlY3Rpb24gMy4xIHdpbGwgYmUgcmVwbGFjZWQgd2l0 aDoNCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPltSRkM2MzcyXSwgYmFzZWQgdXBvbiB0aGUgZGVmaW5pdGlvbnMgaW4gW1JG QzQ0MjddLCBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuICZxdW90O3Byb3RlY3Rpb24mcXVvdDsgYW5k ICZxdW90O3Jlc3RvcmF0aW9uJnF1b3Q7IGRlcGVuZGVudCB1cG9uIHRoZSBkeW5hbWlzbSBvZiB0 aGUgcmVzb3VyY2UgYWxsb2NhdGlvbi4gVGhlIHNhbWUgZGlzdGluY3Rpb24gaXMgdXNlZCBpbiBb UkZDMzk0NV0sDQogW1JGQzQ0MjZdLCBhbmQgW1JGQzQ0MjhdLiBUaGlzIGRvY3VtZW50IGFsc28g dXNlcyB0aGUgc2FtZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0 aW9uIGFzIHN0YXRlZCBpbiBbUkZDNjM3Ml0uPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigzKSBJbiBwYWdlIDYsPC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPlRoZSB1c2Ugb2YgcHJlZW1wdGlvbiBpbiB0aGUgbmV0d29yayBpcyB0eXBpY2FsbHkg YSBidXNpbmVzcyBvcjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdI VDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPnBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90 ZWN0aW9uIHJlc291cmNlcyBhcmUgY29udGVuZGVkLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Q09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnByaW9yaXR5IGNhbiBiZSBh cHBsaWVkIHRvIGRldGVybWluZSB0byB3aGljaCBwYXJ0aWVzIHRoZSBwcm90ZWN0aW9uPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+cmVzb3VyY2VzIGFyZSBjb21taXR0ZWQuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoZSB1c2Ug b2YgcHJlZW1wdGlvbiBpbiB0aGUgbmV0d29yayBpcyB0eXBpY2FsbHkgYSBidXNpbmVzcyBvcjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPnBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90ZWN0aW9uIHJlc291cmNl cyBhcmUgY29udGVuZGVkLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPnByaW9yaXR5IGNhbiBiZSBhcHBsaWVkIHRvIGRldGVy bWluZSB3aGljaCBwYXJ0aWVzIHV0aWxpemUgdGhlIHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5yZXNvdXJj ZXMuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPig0KSBQYWdlIDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6PC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnRoZSByZXNvdXJjZXMgZm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGNvbW1pdHRl ZCw8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5ORVc8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj50aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBw YXRoIGFyZSBmdWxseSBkZWRpY2F0ZWQsPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5yZXNvdXJjZXMgbWF5IGJlIHBs YW5uZWQgYnV0IHdvdWxkIG5vdCBiZSBjb21taXR0ZWQgdW50aWwg4oCmDQo8L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6 PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+cmVzb3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBub3QgYmUgdXRpbGl6 ZWQgdW50aWwg4oCmDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+KDUpIEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHBhZ2UgNywNCjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj4mcXVvdDtIYXJkIFByZWVtcHRpb24mcXVvdDsgcmVxdWlyZXMg dGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUgaW5ncmVzcyBvZiBlYWNoIHNoYXJl ZCBzZWdtZW50IHRvIHNwZWNpZnkgd2hpY2ggYmFja3VwIHBhdGggaGFzIHRoZSBoaWdoZXN0IHBy aW9yaXR5IHdoZW4gY29tbWl0dGluZyBwcm90ZWN0aW9uIHJlc291cmNlcywgdGhlIG90aGVycyBi ZWluZw0KIHByZWVtcHRlZC48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4mcXVvdDtIYXJkIFByZWVtcHRp b24mcXVvdDsgcmVxdWlyZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUgaW5n cmVzcyBvZiBlYWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkgdGhlIHByaW9yaXRpZXMgb2Yg YmFja3VwIHBhdGhzLCBzbyB0aGF0IHRyYWZmaWMgb2YgbG93ZXIgcHJpb3JpdHkgcGF0aHMgY2Fu IGJlIHByZWVtcHRlZC4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj4oNikgVGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMTo8 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5PTEQ6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIGFuZCBjb21taXQgdGhlIGFzc29jaWF0ZWQgcmVzb3Vy Y2VzLiBUaGUgY29tbWl0bWVudCBvZiByZXNvdXJjZXM8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5pcyBkZXBlbmRlbnQgdXBv biDigKY8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjog bm9uZSIgYWxpZ249ImxlZnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIGFuZCA8L2ZvbnQ+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg Q09MT1I6IGJsdWU7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZm9udC1rZXJuaW5n OiAwcHQiPmNvb3JkaW5hdGUgdGhlIHV0aWxpemF0aW9uIG9mDQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhl IGFzc29jaWF0ZWQgc2hhcmVkIHJlc291cmNlcy4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBs ZWZ0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBtc28tbGF5b3V0 LWdyaWQtYWxpZ246IG5vbmUiIGFsaWduPSJsZWZ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlRoZSA8L2ZvbnQ+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z LXNlcmlmJzsgQ09MT1I6IGJsdWU7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZm9u dC1rZXJuaW5nOiAwcHQiPnJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuunkeyd gCDqs6DrlJUiPmlzIGRlcGVuZGVudCB1cG9uIOKApjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg TElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBi bHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4oNykgVGhlIHNlY29uZCBwYXJhZ3JhcGgg b2YgU2VjdGlvbiA0LjE6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJ R0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20g MHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09M T1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPldoZW4gdGhlIHJlc2VydmVkIHJl c291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSBjb21taXR0ZWQgdG8gYTwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVyZSBtYXkgbm90IGJlIHN1ZmZpY2llbnQg cmVzb3VyY2VzPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i V09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBu b3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+YXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rpb24g cGF0aC4gVGhpcyB0aGVuIGltcGxpZXMgdGhhdDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20g MHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09M T1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPmlmIGFub3RoZXIgd29ya2luZyBw YXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVjdGlvbjwvZm9udD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnN3aXRj aCwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcyBtYXkgZmFpbC4gSW4gb3JkZXIgdG88 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5vcHRpbWl6ZSB0aGUgb3BlcmF0aW9uIG9mIHRoZSBjb21taXRtZW50IGFuZCBwcmVw YXJpbmcgZm9yIGNhc2VzIG9mPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+bXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5n LCB0aGUgY29tbWl0bWVudCBvZiB0aGUgc2hhcmVkPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cmVzb3VyY2VzIGFyZSBiZSBj b29yZGluYXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZyBwYXRocyBpbjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PnRoZSBTTVAgbmV0d29yay48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+V2hlbiB0aGUgcmVzZXJ2ZWQg cmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJlIHV0aWxpemVkIGJ5IGE8L2ZvbnQ+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVw LWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SV Ij5wYXJ0aWN1bGFyIHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50 IHJlc291cmNlczwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPmF2YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25hbCBwcm90ZWN0aW9u IHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQ8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5pZiBhbm90aGVyIHdvcmtpbmcg cGF0aCBvZiB0aGUgU01QIGRvbWFpbiB0cmlnZ2VycyBhIHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5zd2l0 Y2gsIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24gbWF5IGZhaWwuIFRoZSBk aWZmZXJlbnQgd29ya2luZyBwYXRocyBpbjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0 OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6 IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnRoZSBTTVAgbmV0d29yayBhcmUgaW52 b2x2ZWQgaW4gdGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbi48c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOw0KPC9zcGFuPg0KPD94bWw6bmFtZXNwYWNlIHBy ZWZpeCA9ICJvIiBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2Ui IC8+DQo8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPi48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgVEVYVC1BTElHTjogbGVmdDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgbXNvLWxheW91dC1ncmlk LWFsaWduOiBub25lIiBhbGlnbj0ibGVmdCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+KDgpIFNlY3Rpb24gNS4xLDwvZm9udD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxs OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9M RDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj7igKYgYW5kIGNvbW1pdCB0aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+TkVXPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWw7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgYWxpZ249 ImxlZnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFj ZT0i66eR7J2AIOqzoOuUlSI+4oCmIGFuZCA8L2ZvbnQ+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsdWU7 IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPmNvb3Jk aW5hdGUgdGhlIHV0aWxpemF0aW9uIG9mDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhlIGFzc29jaWF0ZWQg c2hhcmVkIHJlc291cmNlcy4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj4oOSkgSW4gU2VjdGlvbiA1LjEsPC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPkluIHRoZSBjYXNlIG9mIG11bHRpcGxlIHdvcmtpbmcgcGF0aHMgZmFpbGluZywgdGhlIGNv bW1pdG1lbnQgb2YgdGhlPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJ R0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+c2hhcmVkIHJlc291cmNlcyBTSEFMTCBiZSBjb29yZGlu YXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZzwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnBhdGhzIGluIHRoZSBT TVAgbmV0d29yay48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6 IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBm YWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjog Ymx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+SW4gdGhlIGNhc2Ugb2YgbXVsdGlwbGUg d29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgc2hhcmVkIHJlc291cmNlIHV0aWxpemF0aW9uPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzog a2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+Y29vcmRpbmF0aW9uIFNIQUxMIGJlIGJldHdlZW4gdGhlIGRpZmZlcmVudCB3b3JraW5n DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5wYXRocyBpbiB0aGUgU01QIG5ldHdvcmsuPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20g MHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09M T1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigxMCkgU2VjdGlvbiA1LjEuMS48 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5PTEQ6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIGJlY2F1c2UgdGhleSBhbHJlYWR5IGhhdmUgYmVlbiBj b21taXR0ZWQgdG8gdGhlIHByb3RlY3Rpb24gb2YsIGZvciBleGFtcGxlLCBhIGhpZ2hlciBwcmlv cml0eSB3b3JraW5nIHBhdGguPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Q09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPuKApiBiZWNhdXNlIHRoZXkg YWxyZWFkeSBoYXZlIGJlZW4gdXRpbGl6ZWQgZm9yIHRoZSBwcm90ZWN0aW9uIG9mLCBmb3IgZXhh bXBsZSwgYSBoaWdoZXIgcHJpb3JpdHkgd29ya2luZyBwYXRoLjwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNP TE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4oMTEpIFNlY3Rpb24gNS4yLCB0 aGUgc2Vjb25kIGJ1bGxldCBpdGVtOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBM SU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJs dWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5SZXNvdXJjZXMgb2Yg dGhlIHNoYXJlZCBzZWdtZW50cyBTSEFMTCBiZSBjb21taXR0ZWQgdG8gdGhlPC9mb250Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJv dGVjdGlvbiBwYXRoIOKApjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsOyB0YWItc3RvcHM6IDg3LjZwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5ORVc6PHNwYW4gc3R5 bGU9Im1zby10YWItY291bnQ6IDEiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjog Ymx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+UmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQg c2VnbWVudHMgU0hBTEwgYmUgdXRpbGl6ZWQgYnkgdGhlPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+cHJvdGVjdGlvbiBwYXRo IOKApiA8L2ZvbnQ+DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj4oMTIpIFNlY3Rpb24gNS4yLCB0aGUgdGhpcmQgYnVsbGV0IGl0ZW06PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1h bGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ T0xEOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPklmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3Jp dHkgYXJlIHJlcXVlc3Rpbmc8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5hbGxvY2F0aW9uIG9mIHRoZSBzaGFyZWQgcmVzb3Vy Y2VzLCB0aGUgcmVzb3VyY2VzIFNIT1VMRCBiZQ0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+Y29tbWl0dGVkIG9uIGEgZmly c3QgY29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xP UjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPklmIG11bHRp cGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3Rpbmc8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg 65SVIj50aGUgc2hhcmVkIHJlc291cmNlcywgdGhlIHJlc291cmNlcyBTSE9VTEQgYmUNCjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPmFzc2lnbmVkIG9uIGEgZmlyc3QgY29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMuPC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1h bGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigxMykgU2Vj dGlvbiA1LjIsIHRoZSBmb3VydGggYnVsbGV0IGl0ZW06PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+T0xEOjwvZm9udD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxs OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPklm IHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgY29tbWl0dGVkIHRvIGEgcHJvdGVjdGlvbiBw YXRoLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9Iuun keydgCDqs6DrlJUiPndob3NlIHdvcmtpbmcgcGF0aCBoYXMgYSBsb3dlciBwcmlvcml0eSwgcmVz b3VyY2VzIHJlcXVpcmVkIGZvcjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnRoZSBoaWdoZXIgcHJpb3JpdHkgcGF0aCBTSEFM TCBiZSBjb21taXR0ZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eTwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPnBhdGguPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+TkVXOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPklmIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgdXRpbGl6ZWQg YnkgYSBwcm90ZWN0aW9uIHBhdGgsPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+d2hvc2Ugd29ya2luZyBwYXRoIGhhcyBhIGxv d2VyIHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yPC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dGhlIGhpZ2hlciBw cmlvcml0eSBwYXRoIFNIQUxMIGJlIGFzc2lnbmVkIHRvIHRoZSBoaWdoZXIgcHJpb3JpdHk8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg 65SVIj5wYXRoLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+KDE0KSBTZWN0aW9uIDUuMi4gdGhlIHNldmVudGggYnVsbGV0IGl0ZW08L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5PTEQ6 PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+T25jZSByZXNvdXJjZXMgb2Ygc2hhcmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBzdWNj ZXNzZnVsbHkgY29tbWl0dGVkPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dG8gYSBwcm90ZWN0aW9uIHBhdGgsIOKApjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPk5FVzo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5PbmNlIHJlc291cmNlcyBvZiBzaGFyZWQgc2VnbWVudHMgaGF2ZSBi ZWVuIHN1Y2Nlc3NmdWxseSB1dGlsaXplZDwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0 OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6 IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPmJ5IGEgcHJvdGVjdGlvbiBwYXRoLCDi gKY8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+KDE1KSBTZWN0aW9uIDUuMywgdGhlIGZpcnN0IHBhcmFncmFwaCw8L2ZvbnQ+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFS R0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5PTEQ6PC9m b250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzog a2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+4oCmIHJlcXVlc3QgdGhlIGNvbW1pdG1lbnQgb2YgcHJvdGVjdGlvbiByZXNvdXJjZXMu IElmIHRoZSBuZWNlc3Nhcnk8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5zaGFyZWQgcmVzb3VyY2VzIGFyZSB1bmF2YWlsYWJs ZSB0byBiZSBjb21taXR0ZWQgdG8gdGhlIHByb3RlY3Rpb248L2ZvbnQ+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5wYXRoLCB0aGUgZW5k cG9pbnRzIOKApjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5ORVc6PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJ R0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCmIHJlcXVlc3QgdGhlIGNvb3JkaW5hdGlvbiBvZiB0 aGUgc2hhcmVkIHJlc291cmNlIHV0aWxpemF0aW9uLiBJZiB0aGUgbmVjZXNzYXJ5PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1h bGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ c2hhcmVkIHJlc291cmNlcyBhcmUgdW5hdmFpbGFibGUsIHRoZSBlbmRwb2ludHMg4oCmPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPigxNikg U2VjdGlvbiA1LjMsIHRoZSBzZWNvbmQgcGFyYWdyYXBoLDwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFs bDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5T aW1pbGFybHksIGlmIHByZWVtcHRpb24gaXMgc3VwcG9ydGVkIGFuZCB0aGUgcmVzb3VyY2VzIGN1 cnJlbnRseTwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPmNvbW1pdHRlZCBmb3IgYSBwYXJ0aWN1bGFyIHdvcmtpbmcgcGF0aCBh cmUg4oCmPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+TkVXOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5F LUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi Pjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPlNpbWlsYXJseSwgaWYgcHJlZW1wdGlvbiBpcyBz dXBwb3J0ZWQgYW5kIHRoZSByZXNvdXJjZXMgY3VycmVudGx5PC9mb250Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+dXRpbGl6ZWQgYnkg YSBwYXJ0aWN1bGFyIHdvcmtpbmcgcGF0aCBhcmUg4oCmPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0 OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1I RUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+LSBTZWN0aW9uIDIsIDFzdCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2UuIFRoaXMgc2Vu dGVuY2UgcmVhbGx5IGRlZmluZXM8YnI+DQp0aGUgc2NvcGUvcHVycG9zZSBvZiB0aGUgZG9jdW1l bnQsIGkuZS4sICZxdW90O2NsYXJpZmllcyB0aGUgaW5zdHJ1Y3Rpb25zPGJyPg0KdG8gcHJvdG9j b2wgZGVzaWduZXJzIHByb2R1Y2luZyBzb2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZTxicj4NCnJl cXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuJnF1b3Q7IEFzIHN1Y2gsIEknZCBy ZXBlYXQgdGhpcyBpbjxicj4NCnRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJv bm91bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yPGJyPg0KMykuPGJyIHN0eWxlPSJtc28tc3Bl Y2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFy YWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJ TkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1 ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFdlIGNhbiBhZGQgdGhlIGZv bGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDE6PC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCcVGhp cyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBjbGFyaWZ5IHRoZSBpbnN0cnVjdGlvbnMgdG8gcHJv dG9jb2wgZGVzaWduZXJzIHByb2R1Y2luZyBzb2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZSByZXF1 aXJlbWVudHMgc2V0IG91dCBpbiB0aGlzIGRvY3VtZW50LuKAnTwvZm9udD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46 IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNt IDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZv bnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBHZW5lcmFsIGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBm b3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQPGJyPg0KcHJvdGVjdGlvbjogSG93IGlzIGNv LXJvdXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD88YnI+DQpJJ2Qg YXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2ggY29vcmRpbmF0aW9uIHByb3RvY29sIHdvdWxk IGJlPGJyPg0KcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVyc2Ug TFNQIGluIHRoZSBjby1yb3V0ZWQ8YnI+DQpjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhl IGRvY3VtZW50LjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4N CjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUi PltBdXRob3JzXSBGYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVkIGJ5IHRoaXMgZG9jdW1lbnQu IEV2ZW4gaW4gdGhlIFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIHN1Y2ggYXMgUkZD IDYzNzggKFBTQykgYW5kIFJGQyA3MjcxIChQU0MgaW4gQVBTIG1vZGUpLCBmYXRlLXNoYXJpbmcg aXMgbm90IHJlcXVpcmVkIGFzIHVuaWRpcmVjdGlvbmFsDQogc3dpdGNoaW5nIGlzIGFsbG93ZWQu IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW1wb3NlIGFueSByZXN0cmljdGlvbiBvbiBjby1yb3V0 aW5nLCBlaXRoZXIuDQo8L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlH SFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi Pi0gSW4gc2VjdGlvbiA0IGFuZCA1LjIgeW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRl ZmluaW5nPGJyPg0KcHJlZW1wdGlvbiB0ZXJtaW5vbG9neSBhbmQgYmVoYXZpb3IuIEkgdGhpbmsg NjM3MiBpcyB0aGUgcmlnaHQ8YnI+DQpyZWZlcmVuY2UgaGVyZSBhcyBpdCBkZWZpbmVzIGJvdGgg aW4gdGhlIGNvbnRleHQgb2Ygc3Vydml2YWJpbGl0eSBhbmQ8YnI+DQppbiBkZXBlbmRlbnQgb2Yg Y29udHJvbCBwbGFuZS48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVh ayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBi bHVlIj5bQXV0aG9yc10gT25lIGNvbmNlcm4gaXMgdGhhdCBSRkMgNjM3MiBkZXNjcmliZXMgYm90 aCBzb2Z0IGFuZCBoYXJkIHByZWVtcHRpb25zIGluIHRoZSBjb250ZXh0IG9mIGV4dHJhIHRyYWZm aWMsIHdoaWNoIGlzIG5vdCBleGFjdGx5IHRoZSBjYXNlIGZvciBTTVAuPC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIEluIHNlY3Rpb24gNC4yIHlvdSBzYXkgJnF1 b3Q7VGhlcmVmb3JlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGJlPGJyPg0KY2FycmllZCBv dXQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgc2ltaWxhciB0 bzxicj4NCkdNUExTIFtSRkMzOTQ1XS4mcXVvdDsgcGVyaGFwcyB5b3UgbWVhbiAmcXVvdDtiYXNl ZCBvbiBHTVBMUyZxdW90Oz8gSWYgc28sIGdyZWF0LDxicj4NCnBsZWFzZSBtYWtlIHRoZSBjb3Jy ZWN0aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBvZiB3aGljaDxicj4NCmNvbnRyb2wg cHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBpcyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0 aGlzPGJyPg0KZG9jdW1lbnQuPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUt YnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0K PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+W0F1dGhvcnNdIFllcywgd2Ugd2lsbCBtYWtlIHRoZSBjb3JyZWN0aW9uLjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUuMSwgcGFy YWdyYXBoIDEuIFdoeSBhcmUgeW91IHVzaW5nICZxdW90O1NIT1VMRCBOT1QmcXVvdDsgaGVyZT8g SWY8YnI+DQpyZWZlcnJpbmcgdG8gc29sdXRpb25zIGNvbmZvcm1hbnQgd2l0aCB0aGlzIGRvY3Vt ZW50LCB0aGVuIHRoZXNlIGFyZTxicj4NCmluZm9ybWF0aXZlIHN0YXRlbWVudHMsICZxdW90O2Fu ZCBhIG5vbi1jb250cm9sIHBsYW5lIGJhc2VkIFNNUCBzd2l0Y2hvdmVyPGJyPg0KbWVjaGFuaXNt IGlzIHVzZWQsIHRoZSBjb250cm9sIHBsYW5lIFNIQUxMIE5PVCAuLi4mcXVvdDsuIElmIHJlZmVy cmluZyB0bzxicj4NCmFuIG9wZXJhdG9yJ3MvdXNlcidzIGNob2ljZSBvZiBwcm90ZWN0aW9uIG1l Y2hhbmlzbSwgSSB0aGluayB0aGUgbW9zdDxicj4NCnlvdSBjYW4gc2F5IGlzIE1BWS48YnIgc3R5 bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1z cGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5bQXV0aG9yc10gVGhlIGZp cnN0IGNhc2UgaXMgdGhlIG9uZSB3ZSBhcmUgYWltaW5nIGF0LiBXZSB3aWxsIHVzZSBTSEFMTCBO T1QuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24g NS4yLiAmcXVvdDtUaWUtYnJlYWtpbmcgcnVsZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBv ZiBhbiBTTVA8YnI+DQpkb21haW4uJnF1b3Q7IEFzIHRoaXMgaXMgYSByZXF1aXJlbWVudCwgd2hh dCB5b3UgbWVhbiBieSAmcXVvdDt0aWUtYnJlYWtpbmc8YnI+DQpydWxlcyZxdW90OyBzaG91bGQg YmUgZGVmaW5lZCBkaXJlY3RseSBvciBieSByZWZlcmVuY2UuPGJyIHN0eWxlPSJtc28tc3BlY2lh bC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0 ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUt SEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+ PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFRoZSBzZW50ZW5jZSBjYW4gYmUg cmV3cml0dGVuIGFzOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdI VDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250 IGZhY2U9IuunkeydgCDqs6DrlJUiPk9MRDo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9S OiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5UaWUtYnJlYWtpbmcgcnVsZXMgU0hB TEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9tYWluLjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPk5FVzo8L2Zv bnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8Zm9u dCBmYWNlPSLrp5HsnYAg6rOg65SVIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBi bHVlOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+SW4gb3JkZXIgdG8gY292ZXIgdGhlJm5i c3A7c2l0dWF0aW9uIHdoZXJlJm5ic3A7dGhlIGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIHByaW5j aXBsZSBjYW5ub3QgcmVzb2x2ZSB0aGUgY29udGVudGlvbiBhbW9uZyBtdWx0aXBsZSBlcXVhbCBw cmlvcml0eSByZXF1ZXN0cywgaS5lLiwgd2hlbiB0aGUgcmVxdWVzdHMgb2NjdXINCiBzaW11bHRh bmVvdXNseSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+LCB0 aWUtYnJlYWtpbmcgcnVsZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9t YWluLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBr ZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gU2VjdGlvbiA1LjMuIFJG QzYzNzIgdGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3RpZmljYXRpb248YnI+ DQpsZXZlcmFnZXMgdGhlIHN0YW5kYXJkIE1QTFMtVFAgT0FNIG1lY2hhbmlzbXMsIGlzIHRoZXJl IGFueSByZWFzb24gdG88YnI+DQpkbyBtb3JlIC8gbm90IGp1c3QgZm9sbG93IDYzNzI/PGJyIHN0 eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28t c3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNt IDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFdlIGNh biBhZGQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBhdCB0aGUgZW5kOg0KPC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+4oCcQXMg ZGVzY3JpYmVkIGluIFtSRkM2MzcyXSwgdGhlIGV2ZW50IG9mIHByZWVtcHRpb24gbWF5IGJlIGRl dGVjdGVkIGJ5IE9BTSBhbmQgcmVwb3J0ZWQgYXMgYSBmYXVsdCBvciBhIGRlZ3JhZGF0aW9uIG9m IHRyYWZmaWMgZGVsaXZlcnku4oCdPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBM SU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9u IHJlcXVpcmVkIG9uIHNvZnQtcHJlZW1wdGlvbiBhczxicj4NCndlbGwgKGRlcGVuZGluZyBvbiB0 aGUgY3Jvc3MtY29ubmVjdHMgZXN0YWJsaXNoZWQgZHVyaW5nIExTUDxicj4NCmVzdGFibGlzaG1l bnQpIHNvIGNvb3JkaW5hdGVkIHN3aXRjaGluZyBzaG91bGQgYmUgc3VwcG9ydGVkPGJyPg0KaW5k ZXBlbmRlbnQgb2YgcHJlZW1wdGlvbiBtb2RlLjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFj dGVyOiBsaW5lLWJyZWFrIj4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5l LWJyZWFrIj4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPltBdXRob3JzXSBZZXMsIHdlIHdpbGwgY2hhbmdlIHRoZSBzZWNv bmQgcGFyYWdyYXBoIGZyb20g4oCcU01QIGluIGhhcmQtcHJlZW1wdGlvbiBtb2RlIFNIT1VMRCDi gKbigJ0gdG8g4oCcU01QIFNIT1VMRCDigKbigJ0gYW5kIG1vdmUgdGhlIGNoYW5nZWQgcGFyYWdy YXBoIGFib3ZlIHRoZSBmaXJzdCBwYXJhZ3JhcGguPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBM SU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNl PSLrp5HsnYAg6rOg65SVIj5OaXRzOjxicj4NCjxicj4NCi0gQWJzdHJhY3Q6IEkgZG9uJ3QgcmVj YWxsIHRoZSB0ZXJtICZxdW90O2V4ZWN1dGl2ZSBhY3Rpb24mcXVvdDsgYmVpbmcgdXNlZCBpbiBh bnk8YnI+DQplYXJsaWVyIHJlbGF0ZWQvcmVmZXJlbmNlZCBSRkNzLiBSYXRoZXIgdGhhbiBpbnRy b2R1Y2UgYSBuZXcgKGFuZDxicj4NCnVuZGVmaW5lZCkgdGVybSwgcGVyaGFwcyB5b3UgY2FuIHVz ZSBhbiBleGlzdGluZyBvbmUsIGUuZy4sPGJyPg0KJnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2gmcXVv dDs/PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0 eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1B UkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhv cnNdIFllcywgdGhlIHRlcm0gd2lsbCBiZSBjaGFuZ2VkIGFzIHlvdSBzdWdnZXN0ZWQuPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gMSwgcGFyYWdy YXBoIDEuIERvIHdlIHJlYWxseSBuZWVkIGFub3RoZXIgZGVmaW5pdGlvbiBvZjxicj4NCk1QTFMt VFAgdG8gZGViYXRlPyBJIHN1Z2dlc3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9yaXRlIE1Q TFMtVFA8YnI+DQpkb2N1bWVudChzKSBhbmQgZHJvcHBpbmcgdGhlIGZpcnN0IGZvdXIgc2VudGVu Y2VzLjxicj4NCjxicj4NClRoZSBsYXN0IHNlbnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0aXZl IHN0YXRlbWVudC4gV2hldGhlciBpdCBpczxicj4NCmNyaXRpY2FsIG9yIG5vIGlzIHVubmVjZXNz YXJ5LiBZb3UgY2FuIGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtlIDYzNzI8YnI+DQpwcm92aWRlcyBh IHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGZvciBNUExTLVRQIGFuZCBpcyB0aGUgZm91bmRhdGlv bjxicj4NCmZvciB0aGlzIGRvY3VtZW50LjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVy OiBsaW5lLWJyZWFrIj4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJy ZWFrIj4NCjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldP UkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9y bWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9 IuunkeydgCDqs6DrlJUiPltBdXRob3JzXSBUaGUgcHJvcG9zZWQgdGV4dCBmb3IgdGhlIHBhcmFn cmFwaCAxIGlzOjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDog bm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZh Y2U9IuunkeydgCDqs6DrlJUiPuKAnFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQ KSBpcyBkZXNjcmliZWQgaW4gW1JGQzU5MjFdLA0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+YW5kIFtSRkM2MzcyXSBwcm92 aWRlcyBhIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGZvciBNUExTLVRQDQo8L2ZvbnQ+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5hbmQg aXMgdGhlIGZvdW5kYXRpb24gZm9yIHRoaXMgZG9jdW1lbnQu4oCdPC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAw Y20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElzbid0 IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBub3QgNDQyOD88YnI+DQpBbHNvIGRyb3AgdGhlIHdv cmQgbGluZWFyLCBhcyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZpZXIgYW5kPGJyPg0KNDQy Ny80NDI4IGRvbid0IHVzZSBpdC48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGlu ZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+ DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5bQXV0aG9yc10gT0suPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhF SUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+LSBTZWN0aW9ucyAzIChhbmQgdG8gYSBsZXNzZXIgZGVncmVlIHNlY3Rpb24gMikgYXJlIHJl YWxseSBpbnRyb2R1Y3Rvcnk8YnI+DQp0ZXh0LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0aGV5IGFy ZW4ndCBwYXJ0IG9mIHNlY3Rpb24gMS48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3Rlcjog bGluZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVh ayI+DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj5bQXV0aG9yc10gU2VjdGlvbiAzIHdhcyBpbnRlbmRlZCB0byBwcmVzZW50 IGEgcmVmZXJlbmNlIG1vZGVsIGZvciBTTVAuIFNvbWUgdGV4dCBvZiBTZWN0aW9uIDIgaXMgcmVw ZWF0ZWQgaW4gU2VjdGlvbiAxIGFzIHlvdSBzdWdnZXN0ZWQgZWFybGllci4NCjwvZm9udD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxs OyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lO OiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gU2VjdGlvbiAzLjIgc2hvdWxkIGhhdmUgYSByZWZl cmVuY2UgZm9yICZxdW90O2V4aXN0aW5nIGNvbnRyb2wgcGxhbmU8YnI+DQpzb2x1dGlvbnMgZm9y IFNNUCB3aXRoaW4gTVBMUyZxdW90Oy48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3Rlcjog bGluZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVh ayI+DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLr p5HsnYAg6rOg65SVIj5bQXV0aG9yc10gW1JGQzQyMDZdIHdpbGwgYmUgYWRkZWQgYXMgYSByZWZl cmVuY2U8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JE LUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1h bCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+ LSBTZWN0aW9uIDMuMiBhZ2FpbiB1c2VzIHRoZSAmcXVvdDtleGVjdXRpdmUgYWN0aW9uJnF1b3Q7 IHRlcm0uPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJy IHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7 IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1 dGhvcnNdIE9LLCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lO OiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxm b250IGZhY2U9IuunkeydgCDqs6DrlJUiPi0gU2VjdGlvbiA0LjEuIFlvdSBzYXkgJnF1b3Q7dHdv IG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkmcXVvdDsuIERvIHlvdSByZWFsbHk8YnI+DQptZWFu ICZxdW90O3NpbXVsdGFuZW91c2x5JnF1b3Q7IG9yIG1lcmVseSB0aGF0IHRoZXkgbXVzdCBib3Ro IG9jY3VyIGZvcjxicj4NCnByb3RlY3Rpb24gdG8gYmUgcHJvdmlkZWQ/IChTYW1lIGNvbW1lbnQg aW4gc2VjdGlvbiA1LjEuPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJl YWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9m b250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzog a2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqz oOuUlSI+W0F1dGhvcnNdIEJvdGggYWN0aW9ucyBzaG91bGQgb2NjdXIgYXQgdGhlIHNhbWUgdGlt ZSwgb3IgYXMgY2xvc2VseSBhcyBwb3NzaWJsZSB0byBwcm92aWRlIGZhc3QgcHJvdGVjdGlvbi4N CjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJF QUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4N CiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVw LWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUu Mi4gSSBzdWdnZXN0IG51bWJlcmluZyB0aGUgY3VycmVudGx5IGJ1bGxldHRlZCByZXF1aXJlbWVu dHM8YnI+DQpsaXN0LjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFr Ij4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwvZm9u dD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPltBdXRob3JzXSBPSywgd2Ugd2lsbCB1c2UgbnVtYmVycy4NCjwvZm9udD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJH SU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20g MGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUuMjogRmlyc3QgcGFyYWdyYXBo IGFuZCBmb3J0aCBidWxsZXQgbGFzdCBzZW50ZW5jZS4gVGhlc2U8YnI+DQpib3RoIGJhc2ljYWxs eSBjb3ZlciB0aGUgc2FtZSB0b3BpYyAocHJlZW1wdGlvbikgYW5kIGFjdHVhbGx5IHNheTxicj4N CnNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3MuIEkgc3VnZ2VzdCBjb21iaW5lIGludG8gYSBzaW5n bGU8YnI+DQpyZXF1aXJlbWVudCB0byBlbnN1cmUgY29uc2lzdGVuY3kgYW5kIGZ1bGwgY292ZXJh Z2Ugb2YgdGhlIHRvcGljLjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJy ZWFrIj4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwv Zm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6 IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPltBdXRob3JzXSBUaGUgZmlyc3QgcGFyYWdyYXBoIGlzIGZvciBzb2Z0LXByZWVtcHRp b24sIHdoaWxlIHRoZSBmb3VydGggYnVsbGV0IGJlbG9uZ3MgdG8gdGhlIHJlcXVpcmVtZW50cyBv ZiBoYXJkLXByZWVtcHRpb24uDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElO RS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQgZmFjZT0i 66eR7J2AIOqzoOuUlSI+LSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRoaXMgcmVsYXRl IHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3Q8YnI+DQp0aGUgdG9waWNzIHJlbGF0ZWQgdG8gdGlt aW5nIGJlIGNvbnNvbGlkYXRlZD88YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGlu ZS1icmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+ DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJS RUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5Hs nYAg6rOg65SVIj5bQXV0aG9yc10gWWVzLCByZXEgNSBjYW4gYmUgbW92ZWQgdG8gU2VjdGlvbiA1 LjUuPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1C UkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwi Pg0KJm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtl ZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24g NS4yOiByZXF1aXJlbWVudCA2IHNlZW1zIHRvIGJlIGEgc3Vic2V0IG9mIDcsIHNvIGl0IHNob3Vs ZCBiZTxicj4NCmRyb3BwZWQuPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUt YnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0K PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2A IOqzoOuUlSI+W0F1dGhvcnNdIFllcywgaXQgd2lsbCBiZSBkZWxldGVkLjwvZm9udD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBN QVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4tIFNlY3Rpb24gNS4yLCByZXF1 aXJlbWVudCA4LiBJc24ndCB0aGlzIGEgc3Vic2V0IG9mIDk/IFdoeSBjYWxsIG91dDxicj4NCmp1 c3QgdGhpcyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/PGJyIHN0eWxl PSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3Bl Y2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJD T0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIFJlcS4gOSB3 aWxsIGJlIGRlbGV0ZWQgYXMgaXQgc2VlbXMgdG8gcmVxdWlyZSBjb250cm9sIHBsYW5lIHN1cHBv cnRzLjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQt QlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFs Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Zm9udCBmYWNlPSLrp5HsnYAg6rOg 65SVIj4tIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFy YWN0ZXI6IGxpbmUtYnJlYWsiPg0KPGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxp bmUtYnJlYWsiPg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+W0F1dGhvcnNdIE9LLjwvZm9udD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAtYWxsOyBNQVJHSU46IDBj bSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+LSBzZWN0aW9uIDUuNDogJnF1b3Q7IFdoZW4gdGhlIHdvcmtp bmcgcGF0aCBkZXRlY3RzLi4mcXVvdDsgZGV0ZWN0aW9uIGlzIGJ5IHRoZTxicj4NCm5vZGUgbm90 IHRoZSBwYXRoLjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4N CjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOiBsaW5lLWJyZWFrIj4NCjwvZm9udD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IldPUkQtQlJFQUs6IGtlZXAt YWxsOyBNQVJHSU46IDBjbSAwY20gMHB0OyBMSU5FLUhFSUdIVDogbm9ybWFsIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6IGJsdWUiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PltBdXRob3JzXSBZZXMuIFdlIHdpbGwgc2ltcGx5IHNheSB0aGF0IOKAnFdoZW4gdGhlIGNvbmRp dGlvbiB0aGF0IHRyaWdnZXJlZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgY2xlYXJlZCwg 4oCm4oCdPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09S RC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3Jt YWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi Pi0gU2VjdGlvbiA1LjQsIGxhc3Qgc2VudGVuY2UuIFRoaXMgaXMgb25seSB0aGUgMm5kIHRpbWUg eW91IGltcGx5IHRoYXQ8YnI+DQp0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBh IG5ldyBwcm90b2NvbC4gSSB0aGluayB0aGlzPGJyPg0KcG9pbnQgaXMgY3VycmVudGx5IHRvbyBz dWJ0bGUgaW4gdGhlIGRvY3VtZW50LiAoVGhpcyBwb2ludCB3YXMgYWxzbzxicj4NCm1hZGUgYXMg YSBtaW5vciBjb21tZW50Lik8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1i cmVhayI+DQo8YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjogbGluZS1icmVhayI+DQo8 L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJXT1JELUJSRUFL OiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5vcm1hbCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiBibHVlIj48Zm9udCBmYWNlPSLrp5HsnYAg 6rOg65SVIj5bQXV0aG9yc10gQXMgaW4gb3RoZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGVjaG5v bG9naWVzLCB0d28gbW9kZXMgb2Ygb3BlcmF0aW9ucyAocmV2ZXJ0aXZlIGFuZCBub24tcmV2ZXJ0 aXZlKSBhcmUgcmVxdWlyZWQuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJXT1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElO RS1IRUlHSFQ6IG5vcm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iV09SRC1CUkVBSzoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hU OiBub3JtYWwiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxmb250IGZhY2U9IuunkeydgCDq s6DrlJUiPi0gc2VjdGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkPC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVBSzoga2Vl cC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogYmx1ZSI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuU lSI+W0F1dGhvcnNdIFdlIHdpbGwgYWRkIOKAnGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3Ml3igJ0g dG8gdGhlIGVuZHMgb2YgdHdvIHBhcmFncmFwaHMgZm9yIFdUUiB0aW1lciBhbmQgaG9sZC1vZmYg dGltZXIuDQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJX T1JELUJSRUFLOiBrZWVwLWFsbDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgTElORS1IRUlHSFQ6IG5v cm1hbCI+DQombmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iV09SRC1CUkVB Szoga2VlcC1hbGw7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJR0hUOiBub3JtYWwiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPioqKioqIEVuZCBv ZiBDb21tZW50IHJlc29sdXRpb24gKioqKio8L2ZvbnQ+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElO RS1IRUlHSFQ6IDIwcHQiPjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iTWFpbFNpZ25TZW50 IiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iT1JHTUFJ TF9DT05URU5UIiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPg0KPGhyIHRhYmluZGV4PSItMSI+ DQo8Yj7rs7Trgrgg7IKs656MIDogPC9iPiZxdW90O0xvdSBCZXJnZXImcXVvdDsgJmx0O2xiZXJn ZXJAbGFibi5uZXQmZ3Q7PGJyPg0KPGI+67O064K4IOuCoOynnCA6IDwvYj4yMDE0LTA2LTIyIDAx OjAwOjQ4ICggJiM0MzswOTowMCApPGJyPg0KPGI+67Cb64qUIOyCrOuejCA6IDwvYj5ydGctYWRz QHRvb2xzLmlldGYub3JnICZsdDtydGctYWRzQHRvb2xzLmlldGYub3JnJmd0Ozxicj4NCjxiPuyw uOyhsCA6IDwvYj5ydGctZGlyQGlldGYub3JnICZsdDtydGctZGlyQGlldGYub3JnJmd0OywgZHJh ZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnICZsdDtkcmFm dC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmcmZ3Q7LCBtcGxz QGlldGYub3JnICZsdDttcGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPuygnOuqqSA6IDwvYj5bbXBs c10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYudHh0 PGJyPg0KPGJyPg0KPGJyPg0KSGVsbG8sPGJyPg0KPGJyPg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQg YXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXM8YnI+DQpkcmFmdC4g VGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yPGJy Pg0Kcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3Qg Y2FsbCBhbmQgSUVTRzxicj4NCnJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVl c3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXM8YnI+DQp0byBwcm92aWRlIGFzc2lzdGFu Y2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGU8YnI+ DQpSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlPGJyPg0KaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcjxicj4NCjxicj4NCkFsdGhvdWdoIHRo ZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURz LCBpdDxicj4NCndvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgSUVURjxicj4NCkxhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSBy ZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoPGJyPg0KZGlzY3Vzc2lv biBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KRG9jdW1lbnQ6IGRyYWZ0LWll dGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dDxicj4NClJldmlld2VyOiBMb3UgQmVyZ2Vy PGJyPg0KUmV2aWV3IERhdGU6IEp1bmUgMjEgMjAxNDxicj4NCklFVEYgTEMgRW5kIERhdGU6IDIw MTQtMDYtMjM8YnI+DQpJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWw8YnI+DQo8YnI+DQpT dW1tYXJ5Ojxicj4NCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1l bnQgdGhhdCBJIHRoaW5rPGJyPg0Kc2hvdWxkIChtdXN0LCBhY3R1YWxseSkgYmUgcmVzb2x2ZWQg YmVmb3JlIHB1YmxpY2F0aW9uLjxicj4NCjxicj4NCkNvbW1lbnRzOjxicj4NCjxicj4NCkkgdGhp bmsgdGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQsIG90aGVyIHRoYW4gYSBjb3VwbGUg b2Y8YnI+DQp0ZXJtaW5vbG9neSByZWxhdGVkIGlzc3VlcywgZWFzaWx5IHVuZGVyc3Rvb2QuIFRo ZSBkb2N1bWVudCBkb2VzPGJyPg0KaGF2ZSBhIG51bWJlciBvZiB0ZXJtaW5vbG9neSBhbmQgdGVj aG5pY2FsIGlzc3VlcyB3aGljaCBzaG91bGQgYmU8YnI+DQpyZWFkaWx5IHJlc29sdmVkIHByaW9y IHRvIHB1YmxpY2F0aW9uLjxicj4NCjxicj4NCk1ham9yIElzc3Vlczo8YnI+DQo8YnI+DQpNYWpv ciBpc3N1ZXMgYXJlIHRoZSB0eXBlIG9mIGNvbmNlcm5zIHRoYXQgd2lsbCByZXN1bHQgaW4gdGhl PGJyPg0KZG9jdW1lbnQgYmVpbmcgYmxvY2tlZCB1bnRpbCB0aGV5IGFyZSByZXNvbHZlZC4gVGhl IFJvdXRpbmcgQURzIHdpbGw8YnI+DQpiZWNvbWUgaW52b2x2ZWQuIFBsZWFzZSBpbmNsdWRlIGFs bCBvZiB0aGUgbWFqb3IgaXNzdWVzIHlvdSBoYXZlPGJyPg0KZm91bmQuIEdpdmUgYXMgbXVjaCBj b250ZXh0IGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIChlLmcuLCBzZWN0aW9uPGJyPg0KbnVtYmVy cywgcGFyYWdyYXBoIGNvdW50cykuIElmIHlvdSBmaW5kIG5vIG1ham9yIGlzc3VlcywgcGxlYXNl PGJyPg0Kd3JpdGU6ICZxdW90O05vIG1ham9yIGlzc3VlcyBmb3VuZC4mcXVvdDs8YnI+DQo8YnI+ DQotIE5vIG1ham9yIGlzc3VlcyBmb3VuZC4gSW4gcGFydGljdWxhciwgSSBleHBlY3QgYWxsIGlz c3VlcyBjYW4gYmU8YnI+DQpyZXNvbHZlZCB3aXRob3V0IEFEIGludGVydmVudGlvbi4gU29tZSBv ZiB0aGUgbWlub3IgaXNzdWVzLCBpZiBub3Q8YnI+DQpyZXNvbHZlZCB3aWxsIGJlIGVzY2FsYXRl ZCB0byB0aGUgQUQvbWFqb3IgaXNzdWUgY2F0ZWdvcnkuPGJyPg0KPGJyPg0KTWlub3IgSXNzdWVz Ojxicj4NCjxicj4NCk1pbm9yIGlzc3VlcyBhcmUgY29uY2VybnMgYWJvdXQgY2xhcml0eSBvciB0 ZWNobmljYWwgYWNjdXJhY3kgdGhhdDxicj4NCnNob3VsZCBiZSBkaXNjdXNzZWQgYW5kIHJlc29s dmVkIGJlZm9yZSBwdWJsaWNhdGlvbiwgYnV0IHdoaWNoIHdvdWxkPGJyPg0Kbm9ybWFsbHkgYmUg cmVzb2x2ZWQgYmV0d2VlbiB0aGUgYXV0aG9ycyBhbmQgdGhlIHJldmlld2Vycy4gUGxlYXNlPGJy Pg0KaW5jbHVkZSBhbGwgb2YgdGhlIG1pbm9yIGlzc3VlcyB5b3UgaGF2ZSBmb3VuZC4gR2l2ZSBh cyBtdWNoIGNvbnRleHQ8YnI+DQppbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSAoZS5nLiwgc2VjdGlv biBudW1iZXJzLCBwYXJhZ3JhcGggY291bnRzKS48YnI+DQpJZiB5b3UgZmluZCBubyBtaW5vciBp c3N1ZXMsIHBsZWFzZSB3cml0ZTogJnF1b3Q7Tm8gbWlub3IgaXNzdWVzIGZvdW5kLiZxdW90Ozxi cj4NCjxicj4NCi0gRG9jdW1lbnQncyB1c2FnZSBvZiAmcXVvdDtjb21taXR0ZWQmcXVvdDsgdnMg JnF1b3Q7YWxsb2NhdGVkJnF1b3Q7IHJlc291cmNlczo8YnI+DQo8YnI+DQpJbiBzZWN0aW9uIDEg dGhlIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZTxicj4NCmRpc3RpbmN0 aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gaXMgYmFzZWQgb24gd2hlbjxi cj4NCnJlc291cmNlcyBhcmUgJnF1b3Q7Y29tbWl0dGVkJnF1b3Q7LiBUaGlzIGRpZmZlcmVuY2Ug ZnJvbSBwYXN0PGJyPg0KZGVmaW5pdGlvbi4gUkZDNDQyNyBhbmQgNjM3MiBtYWtlIHRoZSBkaXN0 aW5jdGlvbiB0aGF0IHByb3RlY3Rpb248YnI+DQphbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2Vk IG9uIHdoZW4gcmVzb3VyY2VzIGFyZSAqYWxsb2NhdGVkKiBub3Q8YnI+DQoqY29tbWl0dGVkKi4g VG8gcXVvdGUgUkZDIDQ0Mjc6PGJyPg0KPGJyPg0KVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJv dGVjdGlvbiBhbmQgcmVzdG9yYXRpb24gaXMgbWFkZSBiYXNlZDxicj4NCm9uIHRoZSByZXNvdXJj ZSBhbGxvY2F0aW9uIGRvbmUgZHVyaW5nIHRoZSByZWNvdmVyeSBMU1Avc3Bhbjxicj4NCmVzdGFi bGlzaG1lbnQuIFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZjxicj4N CnJlc3RvcmF0aW9uIGlzIG1hZGUgYmFzZWQgb24gdGhlIGxldmVsIG9mIHJvdXRlIGNvbXB1dGF0 aW9uLDxicj4NCnNpZ25hbGluZywgYW5kIHJlc291cmNlIGFsbG9jYXRpb24gZHVyaW5nIHRoZSBy ZXN0b3JhdGlvbjxicj4NCkxTUC9zcGFuIGVzdGFibGlzaG1lbnQuPGJyPg0KPGJyPg0KVGhpcyBk aWZmZXJlbmNlIGFsc28gbGVhZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZTxi cj4NCmRvY3VtZW50IGFzIHdlbGwgYXMgYW1iaWd1aXR5IGluIHRoZSB0ZXh0LCBpLmUuIGNvbmZ1 c2lvbiBieSB0aGU8YnI+DQpyZWFkZXIuIFRoZSB0ZXJtICZxdW90O2NvbW1pdHRlZCZxdW90OyBp cyBub3QgdGlnaHRseSBkZWZpbmVkIGluIHRoaXM8YnI+DQpkb2N1bWVudCAob3IgZWFybGllciB3 b3JrKSBhbmQgaXMgdXNlZCBkaWZmZXJlbnRseSB0aGFuIGhvdzxicj4NCiZxdW90O2FsbG9jYXRl ZCZxdW90OyBoYXMgYmVlbiB1c2VkLiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJlIGZvdW5kIGlu PGJyPg0KU2VjdGlvbiAzLjEgd2hpY2ggc3RhdGVzOjxicj4NCjxicj4NCkhvd2V2ZXIsIHRoZSBj b21taXRtZW50IG9mIHRoZSByZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGU8YnI+DQpzaGFyZWQg c2VnbWVudHMsIHdpbGwgb25seSBiZSBmaW5hbGl6ZWQgd2hlbiB0aGUgcHJvdGVjdGlvbjxicj4N CnBhdGggaXMgYWN0dWFsbHkgYWN0aXZhdGVkLiBUaGVyZWZvcmUsIGZvciB0aGUgcHVyaXN0cyAt PGJyPg0KcmVnYXJkaW5nIHRoZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVyZSBiZXR3 ZWVuPGJyPg0KcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRpb24uPGJyPg0KPGJyPg0KQm90aCBzZW50 ZW5jZXMgYXJlIHByb2JsZW1hdGljLiBJbiB0aGUgZmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG88 YnI+DQpjb3ZlciBhICZxdW90O3Byb3RlY3Rpb24gc3dpdGNoJnF1b3Q7IHdvdWxkICZxdW90O2Nv bm5lY3QmcXVvdDsgdGhlIHByb3RlY3Rpb24gcGF0aDxicj4NCmJ1dCBub3QgdGhlIGVhcmxpZXIg JnF1b3Q7YWxsb2NhdGlvbiZxdW90OyBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMgYXJlPGJy Pg0KdXNlZCBpbiBlYXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFzZWQg b24gdGhlIG5ldzxicj4NCmRpc3RpbmN0aW9uIG9mIHByb3RlY3Rpb24gdnMuIHJlc3RvcmF0aW9u IGFuZCBpcyB1bm5lY2Vzc2FyeSB3aXRoPGJyPg0KdGhlIGV4aXN0aW5nIGRpc3RpbmN0aW9uLjxi cj4NCjxicj4NClRoaXMgaXNzdWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgZG9j dW1lbnQgd2hlcmU8YnI+DQomcXVvdDtjb21taXR0ZWQmcXVvdDsgaXMgdXNlZCBhbmQgSSdkIHJl Y29tbWVuZCB0aGF0IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkPGJyPg0Kd2l0aCB0ZXJtaW5vbG9n eSB1c2VkIGluIHRoZSByZWZlcmVuY2VkIFJGQ3MsIGkuZS4sICZxdW90O2FsbG9jYXRpb24mcXVv dDssPGJyPg0KJnF1b3Q7Y29ubmVjdGlvbiZxdW90OywgJnF1b3Q7Y3Jvc3MtY29ubmVjdCZxdW90 OywgJnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2gob3ZlcikmcXVvdDssIC4uLjxicj4NCjxicj4NCk5v dGUgSSdtICpub3QqIGhpZ2hsaWdodGluZyBhbGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2Js ZW1zIGluIHRoZTxicj4NCmRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4gVGhlcmUgYXJl IGEgY291cGxlIG9mIHBsYWNlcyBpbiB0aGU8YnI+DQpkb2N1bWVudCB3aGVyZSBJIHRoaW5rIGl0 J3MgcG9zc2libGUgdGhhdCBvbmNlIHRoaXMgdGVybWlub2xvZ3k8YnI+DQphbWJpZ3VpdHkgaXMg Y29ycmVjdGVkIHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1YnN0YW50aXZlIGNvbW1lbnRzLjxicj4N Cjxicj4NCi0gU2VjdGlvbiAyLCAxc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLiBUaGlzIHNl bnRlbmNlIHJlYWxseSBkZWZpbmVzPGJyPg0KdGhlIHNjb3BlL3B1cnBvc2Ugb2YgdGhlIGRvY3Vt ZW50LCBpLmUuLCAmcXVvdDtjbGFyaWZpZXMgdGhlIGluc3RydWN0aW9uczxicj4NCnRvIHByb3Rv Y29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0aGU8YnI+DQpy ZXF1aXJlbWVudHMgc2V0IG91dCBpbiB0aGlzIGRvY3VtZW50LiZxdW90OyBBcyBzdWNoLCBJJ2Qg cmVwZWF0IHRoaXMgaW48YnI+DQp0aGUgYWJzdHJhY3QgYW5kIG1vdmUgaXQgdG8gYSBtb3JlIHBy b25vdW5jZWQgcGxhY2UgaW4gc2VjdGlvbiAxIChvcjxicj4NCjMpLjxicj4NCjxicj4NCi0gR2Vu ZXJhbCBjb21tZW50OiBmYXRlLXNoYXJpbmcgZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExT UDxicj4NCnByb3RlY3Rpb246IEhvdyBpcyBjby1yb3V0aW5nIHByZXNlcnZlZCBmb3IgdGhlIHJl dmVyc2UgcGF0aCBpbiBTTVA/PGJyPg0KSSdkIGFzc3VtZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNo IGNvb3JkaW5hdGlvbiBwcm90b2NvbCB3b3VsZCBiZTxicj4NCnJlcXVpcmVkIHRvIHRyaWdnZXIg YSBzd2l0Y2hvdmVyIG9mIHRoZSByZXZlcnNlIExTUCBpbiB0aGUgY28tcm91dGVkPGJyPg0KY2Fz ZSwgYnV0IGRvbid0IHNlZSB0aGlzIGluIHRoZSBkb2N1bWVudC48YnI+DQo8YnI+DQotIEluIHNl Y3Rpb24gNCBhbmQgNS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBhcyBkZWZpbmluZzxi cj4NCnByZWVtcHRpb24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMg dGhlIHJpZ2h0PGJyPg0KcmVmZXJlbmNlIGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBj b250ZXh0IG9mIHN1cnZpdmFiaWxpdHkgYW5kPGJyPg0KaW4gZGVwZW5kZW50IG9mIGNvbnRyb2wg cGxhbmUuPGJyPg0KPGJyPg0KLSBJbiBzZWN0aW9uIDQuMiB5b3Ugc2F5ICZxdW90O1RoZXJlZm9y ZSwgaXQgaXMgc3VnZ2VzdGVkIHRoYXQgdGhpcyBiZTxicj4NCmNhcnJpZWQgb3V0IHVuZGVyIHRo ZSBjb250cm9sIG9mIGEgZHluYW1pYyBjb250cm9sIHBsYW5lIHNpbWlsYXIgdG88YnI+DQpHTVBM UyBbUkZDMzk0NV0uJnF1b3Q7IHBlcmhhcHMgeW91IG1lYW4gJnF1b3Q7YmFzZWQgb24gR01QTFMm cXVvdDs/IElmIHNvLCBncmVhdCw8YnI+DQpwbGVhc2UgbWFrZSB0aGUgY29ycmVjdGlvbi4gSWYg bm90LCBJIHRoaW5rIHRoZSBkZWJhdGUgb2Ygd2hpY2g8YnI+DQpjb250cm9sIHByb3RvY29sIGlz IHVzZWQgZm9yIE1QTFMtVFAgaXMgd2F5IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpczxicj4NCmRv Y3VtZW50Ljxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjEsIHBhcmFncmFwaCAxLiBXaHkgYXJlIHlv dSB1c2luZyAmcXVvdDtTSE9VTEQgTk9UJnF1b3Q7IGhlcmU/IElmPGJyPg0KcmVmZXJyaW5nIHRv IHNvbHV0aW9ucyBjb25mb3JtYW50IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGVzZSBhcmU8 YnI+DQppbmZvcm1hdGl2ZSBzdGF0ZW1lbnRzLCAmcXVvdDthbmQgYSBub24tY29udHJvbCBwbGFu ZSBiYXNlZCBTTVAgc3dpdGNob3Zlcjxicj4NCm1lY2hhbmlzbSBpcyB1c2VkLCB0aGUgY29udHJv bCBwbGFuZSBTSEFMTCBOT1QgLi4uJnF1b3Q7LiBJZiByZWZlcnJpbmcgdG88YnI+DQphbiBvcGVy YXRvcidzL3VzZXIncyBjaG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNoYW5pc20sIEkgdGhpbmsgdGhl IG1vc3Q8YnI+DQp5b3UgY2FuIHNheSBpcyBNQVkuPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuMi4g JnF1b3Q7VGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4g U01QPGJyPg0KZG9tYWluLiZxdW90OyBBcyB0aGlzIGlzIGEgcmVxdWlyZW1lbnQsIHdoYXQgeW91 IG1lYW4gYnkgJnF1b3Q7dGllLWJyZWFraW5nPGJyPg0KcnVsZXMmcXVvdDsgc2hvdWxkIGJlIGRl ZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNlLjxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjMu IFJGQzYzNzIgdGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3RpZmljYXRpb248 YnI+DQpsZXZlcmFnZXMgdGhlIHN0YW5kYXJkIE1QTFMtVFAgT0FNIG1lY2hhbmlzbXMsIGlzIHRo ZXJlIGFueSByZWFzb24gdG88YnI+DQpkbyBtb3JlIC8gbm90IGp1c3QgZm9sbG93IDYzNzI/PGJy Pg0KPGJyPg0KLSBTZWN0aW9uIDUuNy4gVGhlcmUgbWF5IGJlIGNvb3JkaW5hdGlvbiByZXF1aXJl ZCBvbiBzb2Z0LXByZWVtcHRpb24gYXM8YnI+DQp3ZWxsIChkZXBlbmRpbmcgb24gdGhlIGNyb3Nz LWNvbm5lY3RzIGVzdGFibGlzaGVkIGR1cmluZyBMU1A8YnI+DQplc3RhYmxpc2htZW50KSBzbyBj b29yZGluYXRlZCBzd2l0Y2hpbmcgc2hvdWxkIGJlIHN1cHBvcnRlZDxicj4NCmluZGVwZW5kZW50 IG9mIHByZWVtcHRpb24gbW9kZS48YnI+DQo8YnI+DQpOaXRzOjxicj4NCjxicj4NCi0gQWJzdHJh Y3Q6IEkgZG9uJ3QgcmVjYWxsIHRoZSB0ZXJtICZxdW90O2V4ZWN1dGl2ZSBhY3Rpb24mcXVvdDsg YmVpbmcgdXNlZCBpbiBhbnk8YnI+DQplYXJsaWVyIHJlbGF0ZWQvcmVmZXJlbmNlZCBSRkNzLiBS YXRoZXIgdGhhbiBpbnRyb2R1Y2UgYSBuZXcgKGFuZDxicj4NCnVuZGVmaW5lZCkgdGVybSwgcGVy aGFwcyB5b3UgY2FuIHVzZSBhbiBleGlzdGluZyBvbmUsIGUuZy4sPGJyPg0KJnF1b3Q7cHJvdGVj dGlvbiBzd2l0Y2gmcXVvdDs/PGJyPg0KPGJyPg0KLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAxLiBE byB3ZSByZWFsbHkgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2Y8YnI+DQpNUExTLVRQIHRvIGRl YmF0ZT8gSSBzdWdnZXN0IGp1c3QgcmVmZXJlbmNpbmcgeW91ciBmYXZvcml0ZSBNUExTLVRQPGJy Pg0KZG9jdW1lbnQocykgYW5kIGRyb3BwaW5nIHRoZSBmaXJzdCBmb3VyIHNlbnRlbmNlcy48YnI+ DQo8YnI+DQpUaGUgbGFzdCBzZW50ZW5jZSBhbHNvIG1ha2VzIGEgc3ViamVjdGl2ZSBzdGF0ZW1l bnQuIFdoZXRoZXIgaXQgaXM8YnI+DQpjcml0aWNhbCBvciBubyBpcyB1bm5lY2Vzc2FyeS4gWW91 IGNhbiBqdXN0IHNheSBzb21ldGhpbmcgbGlrZSA2MzcyPGJyPg0KcHJvdmlkZXMgYSBzdXJ2aXZh YmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1UUCBhbmQgaXMgdGhlIGZvdW5kYXRpb248YnI+DQpm b3IgdGhpcyBkb2N1bWVudC48YnI+DQo8YnI+DQotIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElz bid0IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBub3QgNDQyOD88YnI+DQpBbHNvIGRyb3AgdGhl IHdvcmQgbGluZWFyLCBhcyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZpZXIgYW5kPGJyPg0K NDQyNy80NDI4IGRvbid0IHVzZSBpdC48YnI+DQo8YnI+DQotIFNlY3Rpb25zIDMgKGFuZCB0byBh IGxlc3NlciBkZWdyZWUgc2VjdGlvbiAyKSBhcmUgcmVhbGx5IGludHJvZHVjdG9yeTxicj4NCnRl eHQuIEknbSB1bnN1cmUgYXMgdG8gd2h5IHRoZXkgYXJlbid0IHBhcnQgb2Ygc2VjdGlvbiAxLjxi cj4NCjxicj4NCi0gU2VjdGlvbiAzLjIgc2hvdWxkIGhhdmUgYSByZWZlcmVuY2UgZm9yICZxdW90 O2V4aXN0aW5nIGNvbnRyb2wgcGxhbmU8YnI+DQpzb2x1dGlvbnMgZm9yIFNNUCB3aXRoaW4gTVBM UyZxdW90Oy48YnI+DQo8YnI+DQotIFNlY3Rpb24gMy4yIGFnYWluIHVzZXMgdGhlICZxdW90O2V4 ZWN1dGl2ZSBhY3Rpb24mcXVvdDsgdGVybS48YnI+DQo8YnI+DQotIFNlY3Rpb24gNC4xLiBZb3Ug c2F5ICZxdW90O3R3byBvcGVyYXRpb25zIHNpbXVsdGFuZW91c2x5JnF1b3Q7LiBEbyB5b3UgcmVh bGx5PGJyPg0KbWVhbiAmcXVvdDtzaW11bHRhbmVvdXNseSZxdW90OyBvciBtZXJlbHkgdGhhdCB0 aGV5IG11c3QgYm90aCBvY2N1ciBmb3I8YnI+DQpwcm90ZWN0aW9uIHRvIGJlIHByb3ZpZGVkPyAo U2FtZSBjb21tZW50IGluIHNlY3Rpb24gNS4xLjxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjIuIEkg c3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0ZWQgcmVxdWlyZW1lbnRzPGJy Pg0KbGlzdC48YnI+DQo8YnI+DQotIFNlY3Rpb24gNS4yOiBGaXJzdCBwYXJhZ3JhcGggYW5kIGZv cnRoIGJ1bGxldCBsYXN0IHNlbnRlbmNlLiBUaGVzZTxicj4NCmJvdGggYmFzaWNhbGx5IGNvdmVy IHRoZSBzYW1lIHRvcGljIChwcmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkgc2F5PGJyPg0Kc2xpZ2h0 bHkgZGlmZmVyZW50IHRoaW5ncy4gSSBzdWdnZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZTxicj4N CnJlcXVpcmVtZW50IHRvIGVuc3VyZSBjb25zaXN0ZW5jeSBhbmQgZnVsbCBjb3ZlcmFnZSBvZiB0 aGUgdG9waWMuPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRoaXMg cmVsYXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3Q8YnI+DQp0aGUgdG9waWNzIHJlbGF0ZWQg dG8gdGltaW5nIGJlIGNvbnNvbGlkYXRlZD88YnI+DQo8YnI+DQotIFNlY3Rpb24gNS4yOiByZXF1 aXJlbWVudCA2IHNlZW1zIHRvIGJlIGEgc3Vic2V0IG9mIDcsIHNvIGl0IHNob3VsZCBiZTxicj4N CmRyb3BwZWQuPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1lbnQgOC4gSXNuJ3Qg dGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQ8YnI+DQpqdXN0IHRoaXMgb25lIHRyYWZm aWMgdHJlYXRtZW50IChzdWIpIHJlcXVpcmVtZW50Pzxicj4NCjxicj4NCi0gU2VjdGlvbiA1LjMu IHMvTUFZL3dpbGw8YnI+DQo8YnI+DQotIHNlY3Rpb24gNS40OiAmcXVvdDsgV2hlbiB0aGUgd29y a2luZyBwYXRoIGRldGVjdHMuLiZxdW90OyBkZXRlY3Rpb24gaXMgYnkgdGhlPGJyPg0Kbm9kZSBu b3QgdGhlIHBhdGguPGJyPg0KPGJyPg0KLSBTZWN0aW9uIDUuNCwgbGFzdCBzZW50ZW5jZS4gVGhp cyBpcyBvbmx5IHRoZSAybmQgdGltZSB5b3UgaW1wbHkgdGhhdDxicj4NCnRoZSBkb2N1bWVudCBj b3ZlcnMgcmVxdWlyZW1lbnRzIG9uIGEgbmV3IHByb3RvY29sLiBJIHRoaW5rIHRoaXM8YnI+DQpw b2ludCBpcyBjdXJyZW50bHkgdG9vIHN1YnRsZSBpbiB0aGUgZG9jdW1lbnQuIChUaGlzIHBvaW50 IHdhcyBhbHNvPGJyPg0KbWFkZSBhcyBhIG1pbm9yIGNvbW1lbnQuKTxicj4NCjxicj4NCi0gc2Vj dGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxz IG1haWxpbmcgbGlzdDxicj4NCm1wbHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28748144SMTP2etriinfo_-- From nobody Sat Jul 5 08:26:46 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565431A0B05 for ; Sat, 5 Jul 2014 08:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hzpRO0GMxxN for ; Sat, 5 Jul 2014 08:26:30 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 4CA111A0B06 for ; Sat, 5 Jul 2014 08:26:27 -0700 (PDT) Received: (qmail 14178 invoked by uid 0); 5 Jul 2014 15:26:24 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 5 Jul 2014 15:26:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id NlSC1o00G2SSUrH01lSFpz; Sat, 05 Jul 2014 15:26:23 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=zqHLjNqbk_wA:10 a=HFCU6gKsb0MA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=OL2PBTLkfaxC3BG2_xIA:9 a=oCPxG4c3oC-NghgG:21 a=qpmMj8mtTLQwsh6o:21 a=QEXdDO2ut3YA:10 a=3463uW3UAAAA:8 a=fO5YdYd42CcL8vAdCKQA:9 a=dfi9gUwGQP4ljbUr:21 a=3XlLnZWhqq-_Rh3e:21 a=zcfGFlIuNhHJS6MY:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=L7g7tM0swGBUz9W39Tl1NMjgAHCo/TLXjzVUv9NZQ3A=; b=AJGpMRbGz/BeQibLUKeFKDRmzonnWUZTXWy41w0q2h781NN3vncDiCIbXPknzejy+c+ROULoMfY5EeXkjrVY3OeCMr9tEGVYcuRjcqNXMUywdDXnE0SlVauDNp2XhQsf; Received: from box313.bluehost.com ([69.89.31.113]:46310 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X3Rqv-0007Fu-34; Sat, 05 Jul 2014 09:26:13 -0600 Message-ID: <53B8190E.6080505@labn.net> Date: Sat, 05 Jul 2014 11:26:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeong Ryoo , "rtg-ads@tools.ietf.org" References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------020809060909070305050609" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/iM7sXaTMBr4yrX1tu7-qRsEmGhE Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 15:26:33 -0000 This is a multi-part message in MIME format. --------------020809060909070305050609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Jeong/Authors, Thank you for the response. Most of the changes look good. I still have a few questions and open comments. Please see below. Lou On 7/3/2014 8:52 PM, Jeong Ryoo wrote: > Dear Lou, > > > > Thanks a lot for your valuable comments. > > > > The authors of this draft have discussed your comments, and are > proposing our resolutions to your comments. Please, let us know if the > proposal is appropriate to address your comments and concerns. > > > > Best regards, > > > > Authors of draft-ietf-mpls-smp-requirements draft > > > > ****** Beginning of Comment Resolution ****** > > > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > ... > > > > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we > concluded that the distinction between protection and restoration > should be aligned with the exiting documents normatively referenced by > this document. Accordingly, the following 16 modifications will be > done in revision: > ... (deleted changes looked fine.) > > > > > > (4) Page 7, the first paragraph: > > OLD: > > the resources for the protection path are fully committed, > > NEW > > the resources for the protection path are fully dedicated, > > > Dedicated is also an ambiguous term, how about: OLD the resources for the protection path are fully committed, the protection path in the case of SMP consists of segments that are dedicated to the protection of the related working path and also NEW the resources for the protection path are fully allocated, the protection path in the case of SMP consists of segments that are allocated to the protection of the related working path and also > OLD: > > resources may be planned but would not be committed until … > > NEW: > > resources may be planned but would not be utilized until … > How about: OLD resources may be planned but would not be committed until requested NEW resources may be allocated but would not be utilized until requested ... > > > (7) The second paragraph of Section 4.1: > > OLD: > > When the reserved resources of the shared segments are committed to a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the commitment of the resources may fail. In order to > > optimize the operation of the commitment and preparing for cases of > > multiple working paths failing, the commitment of the shared > > resources are be coordinated between the different working paths in > > the SMP network. > > NEW: > > When the reserved resources of the shared segments are utilized by a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the resource utilization coordination may fail. The different > working paths in > > the SMP network are involved in the resource utilization coordination. > > . > This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.) ... > > > > > > (12) Section 5.2, the third bullet item: > > OLD: > > If multiple protection paths of equal priority are requesting > > allocation of the shared resources, the resources SHOULD be > > committed on a first come first served basis. > > NEW: > > If multiple protection paths of equal priority are requesting > > the shared resources, the resources SHOULD be > > assigned on a first come first served basis. > why use a new term "assigned" vs the previous term "utilized"? If there is no distinction being made the same term should be used (either term is fine, but choose one). If there is a distinction, it should be made explicit (i.e., explained). > > > (13) Section 5.2, the fourth bullet item: > > OLD: > > If the protection resources are committed to a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be committed to the higher priority > > path. > > NEW: > > If the protection resources are utilized by a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be assigned to the higher priority > > path. > > > > > same comment. ... > > > > > - Section 2, 1st paragraph, last sentence. This sentence really defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > [Authors] We can add the following paragraph at the end of Section 1: > > “This document is intended to clarify the instructions to protocol > designers producing solutions that satisfy the requirements set out in > this document.†> > > > How about being even more explicit (in both the abstract and section 1): This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane. > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > [Authors] Fate-sharing is not required by this document. Even in the > PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271 > (PSC in APS mode), fate-sharing is not required as unidirectional > switching is allowed. This document does not impose any restriction on > co-routing, either. > > > Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic. Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG. (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".) > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > [Authors] One concern is that RFC 6372 describes both soft and hard > preemptions in the context of extra traffic, which is not exactly the > case for SMP. > Then 6372 should be referenced and the difference should be described. Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies. 6372 is after all titled "MPLS-TP Survivability Framework"... > > > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > [Authors] Yes, we will make the correction. > okay > > > > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > [Authors] The first case is the one we are aiming at. We will use > SHALL NOT. > > > > okay. > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > [Authors] The sentence can be rewritten as: > > OLD: > > Tie-breaking rules SHALL be defined in scope of an SMP domain. > > NEW: > > In order to cover the situation where the first come first served > principle cannot resolve the contention among multiple equal priority > requests, i.e., when the requests occur simultaneously,, tie-breaking > rules SHALL be defined in scope of an SMP domain. > > > > > good enough (i.e., states that the definition of tie-breaking is FFS.) > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > [Authors] We can add the following sentence at the end: > > “As described in [RFC6372], the event of preemption may be detected by > OAM and reported as a fault or a degradation of traffic delivery.†> okay. > > > - Section 5.7. There may be coordination required on soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > [Authors] Yes, we will change the second paragraph from “SMP in > hard-preemption mode SHOULD …†to “SMP SHOULD …†and move the changed > paragraph above the first paragraph. > > > > > Nits: > > - Abstract: I don't recall the term "executive action" being used in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > [Authors] Yes, the term will be changed as you suggested. > > > > great. > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > [Authors] The proposed text for the paragraph 1 is: > > “The MPLS Transport Profile (MPLS-TP) is described in [RFC5921], > > and [RFC6372] provides a survivability framework for MPLS-TP > > and is the foundation for this document.†> > > okay. > > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > [Authors] OK. > > > > > > > - Sections 3 (and to a lesser degree section 2) are really introductory > text. I'm unsure as to why they aren't part of section 1. > > [Authors] Section 3 was intended to present a reference model for SMP. > Some text of Section 2 is repeated in Section 1 as you suggested earlier. > > > We're in the domain of style, so is your call. > > > > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > [Authors] [RFC4206] will be added as a reference > > > - Section 3.2 again uses the "executive action" term. > > [Authors] OK, the term will be changed. > > > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > [Authors] Both actions should occur at the same time, or as closely as > possible to provide fast protection. > > > What text change is planned? > > - Section 5.2. I suggest numbering the currently bulletted requirements > list. > > [Authors] OK, we will use numbers. > > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > [Authors] The first paragraph is for soft-preemption, while the fourth > bullet belongs to the requirements of hard-preemption. > Do you plan a text change? (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.) > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > [Authors] Yes, req 5 can be moved to Section 5.5. > > > okay. > > - Section 5.2: requirement 6 seems to be a subset of 7, so it should be > dropped. > > [Authors] Yes, it will be deleted. > > great. > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > [Authors] Req. 9 will be deleted as it seems to require control plane > supports. > > > > - Section 5.3. s/MAY/will > > [Authors] OK. > > > > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > [Authors] Yes. We will simply say that “When the condition that > triggered the protection switching is cleared, …†> > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > [Authors] As in other protection switching technologies, two modes of > operations (revertive and non-revertive) are required. > > > > > - section 5.6. RFC 6372 should be referenced > > [Authors] We will add “as described in [RFC6372]†to the ends of two > paragraphs for WTR timer and hold-off timer. > > > Okay. > ***** End of Comment resolution ***** > ... --------------020809060909070305050609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Jeong/Authors,
    Thank you for the response.  Most of the changes look good.  I still have a few questions and open comments.  Please see below.

Lou

On 7/3/2014 8:52 PM, Jeong Ryoo wrote:
Dear Lou,

 

Thanks a lot for your valuable comments.

 

The authors of this draft have discussed your comments, and are proposing our resolutions to your comments. Please, let us know if the proposal is appropriate to address your comments and concerns.

 

Best regards,

 

Authors of draft-ietf-mpls-smp-requirements draft

 

****** Beginning of Comment Resolution ******

 

- Document's usage of "committed" vs "allocated" resources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:


...

 

[Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we concluded that the distinction between protection and restoration should be aligned with the exiting documents normatively referenced by this document. Accordingly, the following 16 modifications will be done in revision:

... (deleted changes looked fine.)

 

 

(4) Page 7, the first paragraph:

OLD:

the resources for the protection path are fully committed,

NEW

the resources for the protection path are fully dedicated,

 

Dedicated is also an ambiguous term, how about:
OLD
   the resources for the protection path are fully committed, the
   protection path in the case of SMP consists of segments that are
   dedicated to the protection of the related working path and also
NEW
   the resources for the protection path are fully allocated, the
   protection path in the case of SMP consists of segments that are
   allocated to the protection of the related working path and also


OLD:

resources may be planned but would not be committed until …

NEW:

resources may be planned but would not be utilized until …

How about:
OLD
   resources may be planned but would not be committed until requested
NEW

   resources may be allocated but would not be utilized until requested

...
 

(7) The second paragraph of Section 4.1:

OLD:

When the reserved resources of the shared segments are committed to a

particular protection path, there may not be sufficient resources

available for an additional protection path. This then implies that

if another working path of the SMP domain triggers a protection

switch, the commitment of the resources may fail. In order to

optimize the operation of the commitment and preparing for cases of

multiple working paths failing, the commitment of the shared

resources are be coordinated between the different working paths in

the SMP network.

NEW:

When the reserved resources of the shared segments are utilized by a

particular protection path, there may not be sufficient resources

available for an additional protection path. This then implies that

if another working path of the SMP domain triggers a protection

switch, the resource utilization coordination may fail. The different working paths in

the SMP network are involved in the resource utilization coordination. 

.


This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.)

...

 

  

(12) Section 5.2, the third bullet item:

OLD:

If multiple protection paths of equal priority are requesting

allocation of the shared resources, the resources SHOULD be

committed on a first come first served basis.

NEW:

If multiple protection paths of equal priority are requesting

the shared resources, the resources SHOULD be

assigned on a first come first served basis.


why use a new term "assigned" vs the previous term "utilized"?  If there is no distinction being made the same term should be used (either term is fine, but choose one). If there is a distinction, it should be made explicit (i.e., explained).

 

(13) Section 5.2, the fourth bullet item:

OLD:

If the protection resources are committed to a protection path,

whose working path has a lower priority, resources required for

the higher priority path SHALL be committed to the higher priority

path.

NEW:

If the protection resources are utilized by a protection path,

whose working path has a lower priority, resources required for

the higher priority path SHALL be assigned to the higher priority

path.

 

 

same comment.

...
 

 

- Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions
to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this in
the abstract and move it to a more pronounced place in section 1 (or
3).

[Authors] We can add the following paragraph at the end of Section 1:

“This document is intended to clarify the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.â€

 



How about being even more explicit (in both the abstract and section 1):
   This document provides requirements  for  any
   mechanism that would be used to implement SMP for MPLS-TP data paths,
   in networks that delegate protection switch coordination to the data
   plane.

- General comment: fate-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

[Authors] Fate-sharing is not required by this document. Even in the PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in APS mode), fate-sharing is not required as unidirectional switching is allowed. This document does not impose any restriction on co-routing, either.

 


Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic.  Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG.  (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".)


- In section 4 and 5.2 you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

[Authors] One concern is that RFC 6372 describes both soft and hard preemptions in the context of extra traffic, which is not exactly the case for SMP.


Then 6372 should be referenced and the difference should be described.  Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies.  6372 is after all titled "MPLS-TP Survivability Framework"...

 


- In section 4.2 you say "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

[Authors] Yes, we will make the correction.

okay

 


- Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover
mechanism is used, the control plane SHALL NOT ...". If referring to
an operator's/user's choice of protection mechanism, I think the most
you can say is MAY.

[Authors] The first case is the one we are aiming at. We will use SHALL NOT.

 


okay.

- Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP
domain." As this is a requirement, what you mean by "tie-breaking
rules" should be defined directly or by reference.

[Authors] The sentence can be rewritten as:

OLD:

Tie-breaking rules SHALL be defined in scope of an SMP domain.

NEW:

In order to cover the situation where the first come first served principle cannot resolve the contention among multiple equal priority requests, i.e., when the requests occur simultaneously,, tie-breaking rules SHALL be defined in scope of an SMP domain.

 

 


good enough (i.e., states that the definition of tie-breaking is FFS.)


- Section 5.3. RFC6372 takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

[Authors] We can add the following sentence at the end:

“As described in [RFC6372], the event of preemption may be detected by OAM and reported as a fault or a degradation of traffic delivery.â€Â 


okay.


- Section 5.7. There may be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

[Authors] Yes, we will change the second paragraph from “SMP in hard-preemption mode SHOULD …†to “SMP SHOULD …†and move the changed paragraph above the first paragraph.

 


Nits:

- Abstract: I don't recall the term "executive action" being used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

[Authors] Yes, the term will be changed as you suggested.

 


great.

- Section 1, paragraph 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

[Authors] The proposed text for the paragraph 1 is:

“The MPLS Transport Profile (MPLS-TP) is described in [RFC5921],

and [RFC6372] provides a survivability framework for MPLS-TP

and is the foundation for this document.â€

 

okay.


- Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

[Authors] OK.

 

 


- Sections 3 (and to a lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

[Authors] Section 3 was intended to present a reference model for SMP. Some text of Section 2 is repeated in Section 1 as you suggested earlier.

 

We're in the domain of style, so is your call.

 


- Section 3.2 should have a reference for "existing control plane
solutions for SMP within MPLS".

[Authors] [RFC4206] will be added as a reference


- Section 3.2 again uses the "executive action" term.

[Authors] OK, the term will be changed.

 


- Section 4.1. You say "two operations simultaneously". Do you really
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

[Authors] Both actions should occur at the same time, or as closely as possible to provide fast protection.

 

What text change is planned?


- Section 5.2. I suggest numbering the currently bulletted requirements
list.

[Authors] OK, we will use numbers.

 


- Section 5.2: First paragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

[Authors] The first paragraph is for soft-preemption, while the fourth bullet belongs to the requirements of hard-preemption.


Do you plan a text change?  (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.)


- Section 5.2, req 5. How does this relate to section 5.5? Shouldn't
the topics related to timing be consolidated?

[Authors] Yes, req 5 can be moved to Section 5.5.

 

okay.


- Section 5.2: requirement 6 seems to be a subset of 7, so it should be
dropped.

[Authors] Yes, it will be deleted.


great.

- Section 5.2, requirement 8. Isn't this a subset of 9? Why call out
just this one traffic treatment (sub) requirement?

[Authors] Req. 9 will be deleted as it seems to require control plane supports.



- Section 5.3. s/MAY/will

[Authors] OK.

 


- section 5.4: " When the working path detects.." detection is by the
node not the path.

[Authors] Yes. We will simply say that “When the condition that triggered the protection switching is cleared, …â€


- Section 5.4, last sentence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

[Authors] As in other protection switching technologies, two modes of operations (revertive and non-revertive) are required.

 


- section 5.6. RFC 6372 should be referenced

[Authors] We will add “as described in [RFC6372]†to the ends of two paragraphs for WTR timer and hold-off timer.

 

Okay.

***** End of Comment resolution *****

...

--------------020809060909070305050609-- From nobody Sat Jul 5 15:33:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B327D1B27F9; Sat, 5 Jul 2014 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Navhswq0g-ZE; Sat, 5 Jul 2014 12:49:13 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7224B1B27F7; Sat, 5 Jul 2014 12:49:12 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so2772477wgg.8 for ; Sat, 05 Jul 2014 12:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d2OPxjwHtG2nCvWcyHhr+qTWIP46UyzAk5W3F89ES4k=; b=LQisED0lEZhVVg5BMcsRjEv50lP4htBUSx7dk/xlfThlWEeopUaCGTFmn3ARlHoTCz AlV0NfIStfYlitNII437yKIj1+sg5UVYxGNCuCCmjqWqEcoFIN2sTK9o5bMj72lgtVfb FqjH39583r8HrFLzKSX4cDk0QE1MPPtubfWIc3NEeyeYea/vAGPQNm6bMoVNIU/yS3bM LjR5kxiAc4/rIOxEW/ZmjC5TeyPcWpPnFPQVnN2vVFLJ6yuXc6FN1qaHp+faRwmHIfD/ mhbxQAZamqJsCAXf1uo85iVEKqyO22KpOxZLhwBs/pBhYIw5KRosAwmvxUanzh0tCHC5 rc6A== MIME-Version: 1.0 X-Received: by 10.180.86.7 with SMTP id l7mr12607785wiz.55.1404589750937; Sat, 05 Jul 2014 12:49:10 -0700 (PDT) Received: by 10.194.191.163 with HTTP; Sat, 5 Jul 2014 12:49:10 -0700 (PDT) Received: by 10.194.191.163 with HTTP; Sat, 5 Jul 2014 12:49:10 -0700 (PDT) In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> Date: Sat, 5 Jul 2014 22:49:10 +0300 Message-ID: From: Yaacov Weingarten To: Jeong Ryoo Content-Type: multipart/alternative; boundary=f46d04428e02290ddc04fd778926 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/VoTJ4ywJUKU9_oU3mVc0ohgaX34 X-Mailman-Approved-At: Sat, 05 Jul 2014 15:33:09 -0700 Cc: "mpls@ietf.org" , Lou Berger , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:49:18 -0000 --f46d04428e02290ddc04fd778926 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lou, hi I would like to address two of your comments, in your follow-up message, since I am the source of the change in terminology. Regarding the two occurences of "assigned" in place of "utilized" - when I read the proposed changes,as discussed amongst the authors, I felt that in those two instances the use of "utilized" could lead to some ambiguity. If we state that "resources SHOULD be utilized on a first come first served basis" this could be interpreted (IMO) as referring to the packet level, rather than utilized by a specific path, such that packets from different paths could be interspersed along the shared segments. Therefore,I suggested that or this context it would be better to use a word that meant that the first-come first served basis was at the level of assigning (or allocating) the resources rather than utilizing them. Hope this clarifies this point. I am certain that I speak for the other authors in saying that I am open to other suggestions. BR, yaacov On Jul 4, 2014 3:53 AM, "Jeong Ryoo" wrote: > Dear Lou, > > > > Thanks a lot for your valuable comments. > > > > The authors of this draft have discussed your comments, and are proposing > our resolutions to your comments. Please, let us know if the proposal is > appropriate to address your comments and concerns. > > > > Best regards, > > > > Authors of draft-ietf-mpls-smp-requirements draft > > > > ****** Beginning of Comment Resolution ****** > > > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > > > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, we > concluded that the distinction between protection and restoration should = be > aligned with the exiting documents normatively referenced by this documen= t. > Accordingly, the following 16 modifications will be done in revision: > > > > (1) Section 1, the third paragraph > > OLD: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 linear protection requires > > that resources are committed for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are committed, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > NEW: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 protection requires > > that resources are allocated for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are allocated, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > > > (2) The whole text in Section 3.1 will be replaced with: > > [RFC6372], based upon the definitions in [RFC4427], differentiates betwee= n > "protection" and "restoration" dependent upon the dynamism of the resourc= e > allocation. The same distinction is used in [RFC3945], [RFC4426], and > [RFC4428]. This document also uses the same distinction between protectio= n > and restoration as stated in [RFC6372]. > > > > (3) In page 6, > > OLD: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine to which parties the protection > > resources are committed. > > NEW: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine which parties utilize the protection > > resources. > > > > (4) Page 7, the first paragraph: > > OLD: > > the resources for the protection path are fully committed, > > NEW > > the resources for the protection path are fully dedicated, > > > > OLD: > > resources may be planned but would not be committed until =E2=80=A6 > > NEW: > > resources may be planned but would not be utilized until =E2=80=A6 > > > > (5) In the second paragraph in page 7, > > OLD: > > "Hard Preemption" requires the programming of selectors at the ingress of > each shared segment to specify which backup path has the highest priority > when committing protection resources, the others being preempted. > > NEW > > "Hard Preemption" requires the programming of selectors at the ingress of > each shared segment to specify the priorities of backup paths, so that > traffic of lower priority paths can be preempted. > > > > (6) The first paragraph of Section 4.1: > > OLD: > > =E2=80=A6 and commit the associated resources. The commitment of resource= s > > is dependent upon =E2=80=A6 > > NEW: > > =E2=80=A6 and coordinate the utilization of the associated shared resourc= es. > > The resource utilization coordination is dependent upon =E2=80=A6 > > > > (7) The second paragraph of Section 4.1: > > OLD: > > When the reserved resources of the shared segments are committed to a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the commitment of the resources may fail. In order to > > optimize the operation of the commitment and preparing for cases of > > multiple working paths failing, the commitment of the shared > > resources are be coordinated between the different working paths in > > the SMP network. > > NEW: > > When the reserved resources of the shared segments are utilized by a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the resource utilization coordination may fail. The different > working paths in > > the SMP network are involved in the resource utilization coordination. > > . > > > > (8) Section 5.1, > > OLD: > > =E2=80=A6 and commit the associated resources. > > NEW > > =E2=80=A6 and coordinate the utilization of the associated shared resourc= es. > > > > (9) In Section 5.1, > > OLD: > > In the case of multiple working paths failing, the commitment of the > > shared resources SHALL be coordinated between the different working > > paths in the SMP network. > > NEW: > > In the case of multiple working paths failing, the shared resource > utilization > > coordination SHALL be between the different working > > paths in the SMP network. > > > > (10) Section 5.1.1. > > OLD: > > =E2=80=A6 because they already have been committed to the protection of, = for > example, a higher priority working path. > > NEW: > > =E2=80=A6 because they already have been utilized for the protection of, = for > example, a higher priority working path. > > > > (11) Section 5.2, the second bullet item: > > OLD: > > Resources of the shared segments SHALL be committed to the > > protection path =E2=80=A6 > > NEW: > > Resources of the shared segments SHALL be utilized by the > > protection path =E2=80=A6 > > > > (12) Section 5.2, the third bullet item: > > OLD: > > If multiple protection paths of equal priority are requesting > > allocation of the shared resources, the resources SHOULD be > > committed on a first come first served basis. > > NEW: > > If multiple protection paths of equal priority are requesting > > the shared resources, the resources SHOULD be > > assigned on a first come first served basis. > > > > (13) Section 5.2, the fourth bullet item: > > OLD: > > If the protection resources are committed to a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be committed to the higher priority > > path. > > NEW: > > If the protection resources are utilized by a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be assigned to the higher priority > > path. > > > > > > (14) Section 5.2. the seventh bullet item > > OLD: > > Once resources of shared segments have been successfully committed > > to a protection path, =E2=80=A6 > > NEW: > > Once resources of shared segments have been successfully utilized > > by a protection path, =E2=80=A6 > > > > (15) Section 5.3, the first paragraph, > > OLD: > > =E2=80=A6 request the commitment of protection resources. If the necessar= y > > shared resources are unavailable to be committed to the protection > > path, the endpoints =E2=80=A6 > > > > NEW: > > =E2=80=A6 request the coordination of the shared resource utilization. If= the > necessary > > shared resources are unavailable, the endpoints =E2=80=A6 > > > > (16) Section 5.3, the second paragraph, > > OLD: > > Similarly, if preemption is supported and the resources currently > > committed for a particular working path are =E2=80=A6 > > NEW: > > Similarly, if preemption is supported and the resources currently > > utilized by a particular working path are =E2=80=A6 > > > > > > - Section 2, 1st paragraph, last sentence. This sentence really defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > [Authors] We can add the following paragraph at the end of Section 1: > > =E2=80=9CThis document is intended to clarify the instructions to protoco= l > designers producing solutions that satisfy the requirements set out in th= is > document.=E2=80=9D > > > > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > [Authors] Fate-sharing is not required by this document. Even in the PSC > linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in > APS mode), fate-sharing is not required as unidirectional switching is > allowed. This document does not impose any restriction on co-routing, > either. > > > > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > [Authors] One concern is that RFC 6372 describes both soft and hard > preemptions in the context of extra traffic, which is not exactly the cas= e > for SMP. > > > > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > [Authors] Yes, we will make the correction. > > > > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > [Authors] The first case is the one we are aiming at. We will use SHALL > NOT. > > > > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > [Authors] The sentence can be rewritten as: > > OLD: > > Tie-breaking rules SHALL be defined in scope of an SMP domain. > > NEW: > > In order to cover the situation where the first come first served > principle cannot resolve the contention among multiple equal priority > requests, i.e., when the requests occur simultaneously,, tie-breaking > rules SHALL be defined in scope of an SMP domain. > > > > > > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > [Authors] We can add the following sentence at the end: > > =E2=80=9CAs described in [RFC6372], the event of preemption may be detect= ed by OAM > and reported as a fault or a degradation of traffic delivery.=E2=80=9D > > > - Section 5.7. There may be coordination required on soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > [Authors] Yes, we will change the second paragraph from =E2=80=9CSMP in > hard-preemption mode SHOULD =E2=80=A6=E2=80=9D to =E2=80=9CSMP SHOULD =E2= =80=A6=E2=80=9D and move the changed > paragraph above the first paragraph. > > > > > Nits: > > - Abstract: I don't recall the term "executive action" being used in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > [Authors] Yes, the term will be changed as you suggested. > > > > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > [Authors] The proposed text for the paragraph 1 is: > > =E2=80=9CThe MPLS Transport Profile (MPLS-TP) is described in [RFC5921], > > and [RFC6372] provides a survivability framework for MPLS-TP > > and is the foundation for this document.=E2=80=9D > > > > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > [Authors] OK. > > > > > > > - Sections 3 (and to a lesser degree section 2) are really introductory > text. I'm unsure as to why they aren't part of section 1. > > [Authors] Section 3 was intended to present a reference model for SMP. > Some text of Section 2 is repeated in Section 1 as you suggested earlier. > > > > > > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > [Authors] [RFC4206] will be added as a reference > > > - Section 3.2 again uses the "executive action" term. > > [Authors] OK, the term will be changed. > > > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > [Authors] Both actions should occur at the same time, or as closely as > possible to provide fast protection. > > > > > - Section 5.2. I suggest numbering the currently bulletted requirements > list. > > [Authors] OK, we will use numbers. > > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > [Authors] The first paragraph is for soft-preemption, while the fourth > bullet belongs to the requirements of hard-preemption. > > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > [Authors] Yes, req 5 can be moved to Section 5.5. > > > > > - Section 5.2: requirement 6 seems to be a subset of 7, so it should be > dropped. > > [Authors] Yes, it will be deleted. > > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > [Authors] Req. 9 will be deleted as it seems to require control plane > supports. > > > > - Section 5.3. s/MAY/will > > [Authors] OK. > > > > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > [Authors] Yes. We will simply say that =E2=80=9CWhen the condition that > triggered the protection switching is cleared, =E2=80=A6=E2=80=9D > > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > [Authors] As in other protection switching technologies, two modes of > operations (revertive and non-revertive) are required. > > > > > - section 5.6. RFC 6372 should be referenced > > [Authors] We will add =E2=80=9Cas described in [RFC6372]=E2=80=9D to the = ends of two > paragraphs for WTR timer and hold-off timer. > > > > ***** End of Comment resolution ***** > > > > > > ------------------------------ > *=EB=B3=B4=EB=82=B8 =EC=82=AC=EB=9E=8C : *"Lou Berger" > *=EB=B3=B4=EB=82=B8 =EB=82=A0=EC=A7=9C : *2014-06-22 01:00:48 ( +09:00 ) > *=EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C : *rtg-ads@tools.ietf.org > *=EC=B0=B8=EC=A1=B0 : *rtg-dir@ietf.org , > draft-ietf-mpls-smp-requirements.all@tools.ietf.org < > draft-ietf-mpls-smp-requirements.all@tools.ietf.org>, mpls@ietf.org < > mpls@ietf.org> > *=EC=A0=9C=EB=AA=A9 : *[mpls] RtgDir review: draft-ietf-mpls-smp-requirem= ents-06.txt > > > 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > 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-mpls-smp-requirements-06.txt > Reviewer: Lou Berger > Review Date: June 21 2014 > IETF LC End Date: 2014-06-23 > Intended Status: Informational > > Summary: > I have some minor concerns about this document that I think > should (must, actually) be resolved before publication. > > Comments: > > I think the document is well written and, other than a couple of > terminology related issues, easily understood. The document does > have a number of terminology and technical issues which should be > readily resolved prior to publication. > > Major Issues: > > Major issues are the type of concerns that will result in the > document being blocked until they are resolved. The Routing ADs will > become involved. Please include all of the major issues you have > found. Give as much context information as possible (e.g., section > numbers, paragraph counts). If you find no major issues, please > write: "No major issues found." > > - No major issues found. In particular, I expect all issues can be > resolved without AD intervention. Some of the minor issues, if not > resolved will be escalated to the AD/major issue category. > > Minor Issues: > > Minor issues are concerns about clarity or technical accuracy that > should be discussed and resolved before publication, but which would > normally be resolved between the authors and the reviewers. Please > include all of the minor issues you have found. Give as much context > information as possible (e.g., section numbers, paragraph counts). > If you find no minor issues, please write: "No minor issues found." > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > - Section 2, 1st paragraph, last sentence. This sentence really defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > - Section 5.7. There may be coordination required on soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > Nits: > > - Abstract: I don't recall the term "executive action" being used in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > - Sections 3 (and to a lesser degree section 2) are really introductory > text. I'm unsure as to why they aren't part of section 1. > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > - Section 3.2 again uses the "executive action" term. > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > - Section 5.2. I suggest numbering the currently bulletted requirements > list. > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > - Section 5.2: requirement 6 seems to be a subset of 7, so it should be > dropped. > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > - Section 5.3. s/MAY/will > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > - section 5.6. RFC 6372 should be referenced > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --f46d04428e02290ddc04fd778926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Lou, hi
I would like to address two of your comments, in your follow-up message, s= ince I am the source of the change in terminology.

Regarding the two occurences of "assigned" in place of "u= tilized" - when I read the proposed changes,as discussed amongst the a= uthors, I felt that in those two instances the use of "utilized" = could lead to some ambiguity.

If we state that "resources SHOULD be utilized on a first come firs= t served basis" this could be interpreted (IMO) as referring to the pa= cket level, rather than=C2=A0 utilized by a specific path, such that packet= s from different paths could be interspersed along the shared segments. The= refore,I suggested that or this context it would be better to use a word th= at meant that the first-come first served basis was at the level of assigni= ng (or allocating) the resources rather than utilizing them.

Hope this clarifies this point. I am certain that I speak for the other = authors in=C2=A0 saying that I am open to other suggestions.

BR,
yaacov

On Jul 4, 2014 3:53 AM, "Jeong Ryoo" &= lt;ryoo@etri.re.kr> wrote:
<= font face=3D"=EB=A7=91=EC=9D=80 =EA=B3=A0=EB=94=95">Dear Lou,=

=C2=A0

Thanks a lot for your valuable comments.<= /p>

=C2=A0

The authors of this draft have discussed your comments,= and are proposing our resolutions to your comments. Please, let us know if= the proposal is appropriate to address your comments and concerns.<= /span>

=C2=A0

Best regards,

=C2=A0

Authors of draft-ietf-mpls-smp-requirements draft

=C2=A0

*= ***** Beginning of Comment Resolution ******

=C2=A0

-= Document's usage of "committed" vs "allocated" res= ources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:

The distinction between protection and restoration is made based
on the resource allocation done during the recovery LSP/span
establishment. The distinction between different types of
restoration is made based on the level of route computation,
signaling, and resource allocation during the restoration
LSP/span establishment.

This difference also leads to come confused statements in the
document as well as ambiguity in the text, i.e. confusion by the
reader. The term "committed" is not tightly defined in this
document (or earlier work) and is used differently than how
"allocated" has been used. An example of this can be found in
Section 3.1 which states:

However, the commitment of the resources, at least for the
shared segments, will only be finalized when the protection
path is actually activated. Therefore, for the purists -
regarding the terminology - SMP lies somewhere between
protection and restoration.

Both sentences are problematic. In the first, commitment seems to
cover a "protection switch" would "connect" the protect= ion path
but not the earlier "allocation" of resources. (Quoted terms are<= br> used in earlier RFCs.) The second conclusion is based on the new
distinction of protection vs. restoration and is unnecessary with
the existing distinction.

This issue exists in multiple places in the document where
"committed" is used and I'd recommend that each should be rep= laced
with terminology used in the referenced RFCs, i.e., "allocation",=
"connection", "cross-connect", "protection switch(= over)", ...

Note I'm *not* highlighting all cases where there are problems in the document related to this issue. There are a couple of places in the
document where I think it's possible that once this terminology
ambiguity is corrected that I'll have other substantive comments.

=C2=A0

[Authors] After reviewing RFCs 4427, 6372, 3945, 4426, = and 4428, we concluded that the distinction between protection and restorat= ion should be aligned with the exiting documents normatively referenced by this document. Accordingly, the following 16 modifications will be done= in revision:

=C2=A0

(1) Section 1, the third paragraph

OLD:

As pointed out

in [RFC6372] and [RFC4428], applying 1+1 linear protect= ion requires

that resources are committed for use by both the workin= g and

protection paths. Applying 1:1 protection requires that= the same

resources are committed, but allows the resources of th= e protection

path to be utilized for pre-emptible extra traffic.

NEW:

As pointed out

in [RFC6372] and [RFC4428], applying 1+1 protection req= uires

that resources are allocated for use by both the workin= g and

protection paths. Applying 1:1 protection requires that= the same

resources are allocated, but allows the resources of th= e protection

path to be utilized for pre-emptible extra traffic.

=C2=A0

(2) The whole text in Section 3.1 will be replaced with= :

[RFC6372], based upon the definitions in [RFC4427], dif= ferentiates between "protection" and "restoration" depe= ndent upon the dynamism of the resource allocation. The same distinction is= used in [RFC3945], [RFC4426], and [RFC4428]. This document also uses the same distinction bet= ween protection and restoration as stated in [RFC6372].

=C2=A0

(3) In page 6,

OLD:

The use of preemption in the network is typically a bus= iness or

policy decision such that when protection resources are= contended,

priority can be applied to determine to which parties t= he protection

resources are committed.

NEW:

The use of preemption in the network is typically a bus= iness or

policy decision such that when protection resources are= contended,

priority can be applied to determine which parties util= ize the protection

resources.

=C2=A0

(4) Page 7, the first paragraph:

OLD:

the resources for the protection path are fully committ= ed,

NEW

the resources for the protection path are fully dedicat= ed,

=C2=A0

OLD:

resources may be planned but would not be committed unt= il =E2=80=A6

NEW:

resources may be planned but would not be utilized unti= l =E2=80=A6

=C2=A0

(5) In the second paragraph in page 7,

OLD:

"Hard Preemption" requires the programming of= selectors at the ingress of each shared segment to specify which backup pa= th has the highest priority when committing protection resources, the other= s being preempted.

NEW

"Hard Preemption" requires the programming of= selectors at the ingress of each shared segment to specify the priorities = of backup paths, so that traffic of lower priority paths can be preempted.

=C2=A0

(6) The first paragraph of Section 4.1:

OLD:

=E2=80=A6 and commit the associated resources. The comm= itment of resources

is dependent upon =E2=80=A6

NEW:

=E2=80=A6 and coordinat= e the utilization of the associated shared resources.

The resource utilization= coordination is dependent upon =E2=80=A6

=C2=A0

(7) The second paragraph of Section 4.1:<= /p>

OLD:

When the reserved resources of the shared segments are = committed to a

particular protection path, there may not be sufficient= resources

available for an additional protection path. This then = implies that

if another working path of the SMP domain triggers a pr= otection

switch, the commitment of the resources may fail. In or= der to

optimize the operation of the commitment and preparing = for cases of

multiple working paths failing, the commitment of the s= hared

resources are be coordinated between the different work= ing paths in

the SMP network.

NEW:

When the reserved resources of the shared segments are = utilized by a

particular protection path, there may not be sufficient= resources

available for an additional protection path. This then = implies that

if another working path of the SMP domain triggers a pr= otection

switch, the resource utilization coordination may fail.= The different working paths in

the SMP network are involved in the resource utilizatio= n coordination.=C2=A0

.

=C2=A0

(8) Section 5.1,

OLD:

=E2=80=A6 and commit the associated resources.

NEW

=E2=80=A6 and coordinat= e the utilization of the associated shared resources.

=C2=A0

(9) In Section 5.1,

OLD:

In the case of multiple working paths failing, the comm= itment of the

shared resources SHALL be coordinated between the diffe= rent working

paths in the SMP network.

NEW:

In the case of multiple working paths failing, the shar= ed resource utilization

coordination SHALL be between the different working

paths in the SMP network.

=C2=A0

(10) Section 5.1.1.

OLD:

=E2=80=A6 because they already have been committed to t= he protection of, for example, a higher priority working path.

NEW:

=E2=80=A6 because they already have been utilized for t= he protection of, for example, a higher priority working path.

=C2=A0

(11) Section 5.2, the second bullet item:=

OLD:

Resources of the shared segments SHALL be committed to = the

protection path =E2=80=A6

NEW:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

Resources of the shared segments SHALL be utilized by t= he

protection path =E2=80=A6

=C2=A0

(12) Section 5.2, the third bullet item:<= /p>

OLD:

If multiple protection paths of equal priority are requ= esting

allocation of the shared resources, the resources SHOUL= D be

committed on a first come first served basis.

NEW:

If multiple protection paths of equal priority are requ= esting

the shared resources, the resources SHOULD be

assigned on a first come first served basis.

=C2=A0

(13) Section 5.2, the fourth bullet item:=

OLD:

If the protection resources are committed to a protecti= on path,

whose working path has a lower priority, resources requ= ired for

the higher priority path SHALL be committed to the high= er priority

path.

NEW:

If the protection resources are utilized by a protectio= n path,

whose working path has a lower priority, resources requ= ired for

the higher priority path SHALL be assigned to the highe= r priority

path.

=C2=A0

=C2=A0

(14) Section 5.2. the seventh bullet item=

OLD:

Once resources of shared segments have been successfull= y committed

to a protection path, =E2=80=A6

NEW:

Once resources of shared segments have been successfull= y utilized

by a protection path, =E2=80=A6

=C2=A0

(15) Section 5.3, the first paragraph,

OLD:

=E2=80=A6 request the commitment of protection resource= s. If the necessary

shared resources are unavailable to be committed to the= protection

path, the endpoints =E2=80=A6

=C2=A0

NEW:

=E2=80=A6 request the coordination of the shared resour= ce utilization. If the necessary

shared resources are unavailable, the endpoints =E2=80= =A6

=C2=A0

(16) Section 5.3, the second paragraph,

OLD:

Similarly, if preemption is supported and the resources= currently

committed for a particular working path are =E2=80=A6

NEW:

Similarly, if preemption is supported and the resources= currently

utilized by a particular working path are =E2=80=A6

=C2=A0

=C2=A0

-= Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this i= n
the abstract and move it to a more pronounced place in section 1 (or
3).

[Authors] We can add the following paragraph at the end= of Section 1:

=E2=80=9CThis document is intended to clarify the instr= uctions to protocol designers producing solutions that satisfy the requirem= ents set out in this document.=E2=80=9D

=C2=A0


- General comment: fat= e-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

[Authors] Fate-sharing is not required by this document= . Even in the PSC linear protection switching, such as RFC 6378 (PSC) and R= FC 7271 (PSC in APS mode), fate-sharing is not required as unidirectional switching is allowed. This document does not impose any restriction on co-= routing, either.

=C2=A0


- In section 4 and 5.2= you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

[Authors] One concern is that RFC 6372 describes both s= oft and hard preemptions in the context of extra traffic, which is not exac= tly the case for SMP.

=C2=A0


- In section 4.2 you s= ay "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, = great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

[Authors] Yes, we will make the correction.

=C2=A0


- Section 5.1, paragra= ph 1. Why are you using "SHOULD NOT" here? If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover<= br> mechanism is used, the control plane SHALL NOT ...". If referring to an operator's/user's choice of protection mechanism, I think the mo= st
you can say is MAY.

[Authors] The first case is the one we are aiming at. W= e will use SHALL NOT.

=C2=A0


- Section 5.2. "T= ie-breaking rules SHALL be defined in scope of an SMP
domain." As this is a requirement, what you mean by "tie-breaking=
rules" should be defined directly or by reference.

[Authors] The sentence can be rewritten as:

OLD:

Tie-breaking rules SHALL be defined in scope of an SMP = domain.

NEW:

In order to cover the=C2=A0situation where=C2=A0the fir= st come first served principle cannot resolve the contention among multiple= equal priority requests, i.e., when the requests occur simultaneously,, tie-brea= king rules SHALL be defined in scope of an SMP domain.

=C2=A0

=C2=A0


- Section 5.3. RFC6372= takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

[Authors] We can add the following sentence at the end:

=E2=80=9CAs described in [RFC6372], the event of preemp= tion may be detected by OAM and reported as a fault or a degradation of tra= ffic delivery.=E2=80=9D=C2=A0


- Section 5.7. There m= ay be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

[Authors] Yes, we will change the second paragraph from= =E2=80=9CSMP in hard-preemption mode SHOULD =E2=80=A6=E2=80=9D to =E2=80= =9CSMP SHOULD =E2=80=A6=E2=80=9D and move the changed paragraph above the f= irst paragraph.

=C2=A0


Nits:

- Abstract: I don't recall the term "executive action" being = used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

[Authors] Yes, the term will be changed as you suggeste= d.

=C2=A0


- Section 1, paragraph= 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

[Authors] The proposed text for the paragraph 1 is:

=E2=80=9CThe MPLS Transport Profile (MPLS-TP) is descri= bed in [RFC5921],

and [RFC6372] provides a survivability framework for MP= LS-TP

and is the foundation for this document.=E2=80=9D

=C2=A0


- Section 1, paragraph= 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

[Authors] OK.

=C2=A0

=C2=A0


- Sections 3 (and to a= lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

[Authors] Section 3 was intended to present a reference= model for SMP. Some text of Section 2 is repeated in Section 1 as you sugg= ested earlier.

=C2=A0

=C2=A0


- Section 3.2 should h= ave a reference for "existing control plane
solutions for SMP within MPLS".

[Authors] [RFC4206] will be added as a reference=


- Section 3.2 again us= es the "executive action" term.

[Authors] OK, the term will be changed.

=C2=A0


- Section 4.1. You say= "two operations simultaneously". Do you really
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

[Authors] Both actions should occur at the same time, o= r as closely as possible to provide fast protection.

=C2=A0


- Section 5.2. I sugge= st numbering the currently bulletted requirements
list.

[Authors] OK, we will use numbers.

=C2=A0


- Section 5.2: First p= aragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

[Authors] The first paragraph is for soft-preemption, w= hile the fourth bullet belongs to the requirements of hard-preemption.


- Section 5.2, req 5. = How does this relate to section 5.5? Shouldn't
the topics related to timing be consolidated?

[Authors] Yes, req 5 can be moved to Section 5.5.

=C2=A0


- Section 5.2: require= ment 6 seems to be a subset of 7, so it should be
dropped.

[Authors] Yes, it will be deleted.


- Section 5.2, require= ment 8. Isn't this a subset of 9? Why call out
just this one traffic treatment (sub) requirement?

[Authors] Req. 9 will be deleted as it seems to require= control plane supports.



- Section 5.3. s/MAY/w= ill

[Authors] OK.

=C2=A0


- section 5.4: " = When the working path detects.." detection is by the
node not the path.

[Authors] Yes. We will simply say that =E2=80=9CWhen th= e condition that triggered the protection switching is cleared, =E2=80=A6= =E2=80=9D


- Section 5.4, last se= ntence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

[Authors] As in other protection switching technologies= , two modes of operations (revertive and non-revertive) are required.

=C2=A0


- section 5.6. RFC 637= 2 should be referenced

[Authors] We will add =E2=80=9Cas described in [RFC6372= ]=E2=80=9D to the ends of two paragraphs for WTR timer and hold-off timer.

=C2=A0

*= **** End of Comment resolution *****

=C2=A0
=C2=A0



=EB=B3=B4=EB=82=B8 =EC=82=AC=EB=9E=8C : "Lou Berger" <<= a href=3D"mailto:lberger@labn.net" target=3D"_blank">lberger@labn.net&g= t;
=EB=B3=B4=EB=82=B8 =EB=82=A0=EC=A7=9C : 2014-06-22 01:00:48 ( +09:00= )
=EB=B0=9B=EB=8A=94 =EC=82=AC=EB=9E=8C : rtg-ads@tools.ietf.org <rtg-ads@tools.ietf.org&= gt;
=EC=B0=B8=EC=A1=B0 : rtg-dir@ietf.org <rtg-dir@ietf.org>, draft-ietf-mpls-smp-req= uirements.all@tools.ietf.org <draft-ietf-mpls-smp-requ= irements.all@tools.ietf.org>, mpls@ietf.org <mpls@ietf.org>
=EC=A0=9C=EB=AA=A9 : [mpls] RtgDir review: draft-ietf-mpls-smp-requi= rements-06.txt


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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

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-mpls-smp-requirements-06.txt
Reviewer: Lou Berger
Review Date: June 21 2014
IETF LC End Date: 2014-06-23
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think
should (must, actually) be resolved before publication.

Comments:

I think the document is well written and, other than a couple of
terminology related issues, easily understood. The document does
have a number of terminology and technical issues which should be
readily resolved prior to publication.

Major Issues:

Major issues are the type of concerns that will result in the
document being blocked until they are resolved. The Routing ADs will
become involved. Please include all of the major issues you have
found. Give as much context information as possible (e.g., section
numbers, paragraph counts). If you find no major issues, please
write: "No major issues found."

- No major issues found. In particular, I expect all issues can be
resolved without AD intervention. Some of the minor issues, if not
resolved will be escalated to the AD/major issue category.

Minor Issues:

Minor issues are concerns about clarity or technical accuracy that
should be discussed and resolved before publication, but which would
normally be resolved between the authors and the reviewers. Please
include all of the minor issues you have found. Give as much context
information as possible (e.g., section numbers, paragraph counts).
If you find no minor issues, please write: "No minor issues found.&quo= t;

- Document's usage of "committed" vs "allocated" re= sources:

In section 1 the document introduces the notion that the
distinction between protection and restoration is based on when
resources are "committed". This difference from past
definition. RFC4427 and 6372 make the distinction that protection
and restoration differ based on when resources are *allocated* not
*committed*. To quote RFC 4427:

The distinction between protection and restoration is made based
on the resource allocation done during the recovery LSP/span
establishment. The distinction between different types of
restoration is made based on the level of route computation,
signaling, and resource allocation during the restoration
LSP/span establishment.

This difference also leads to come confused statements in the
document as well as ambiguity in the text, i.e. confusion by the
reader. The term "committed" is not tightly defined in this
document (or earlier work) and is used differently than how
"allocated" has been used. An example of this can be found in
Section 3.1 which states:

However, the commitment of the resources, at least for the
shared segments, will only be finalized when the protection
path is actually activated. Therefore, for the purists -
regarding the terminology - SMP lies somewhere between
protection and restoration.

Both sentences are problematic. In the first, commitment seems to
cover a "protection switch" would "connect" the protect= ion path
but not the earlier "allocation" of resources. (Quoted terms are<= br> used in earlier RFCs.) The second conclusion is based on the new
distinction of protection vs. restoration and is unnecessary with
the existing distinction.

This issue exists in multiple places in the document where
"committed" is used and I'd recommend that each should be rep= laced
with terminology used in the referenced RFCs, i.e., "allocation",=
"connection", "cross-connect", "protection switch(= over)", ...

Note I'm *not* highlighting all cases where there are problems in the document related to this issue. There are a couple of places in the
document where I think it's possible that once this terminology
ambiguity is corrected that I'll have other substantive comments.

- Section 2, 1st paragraph, last sentence. This sentence really defines
the scope/purpose of the document, i.e., "clarifies the instructions to protocol designers producing solutions that satisfy the
requirements set out in this document." As such, I'd repeat this i= n
the abstract and move it to a more pronounced place in section 1 (or
3).

- General comment: fate-sharing for co-routed bidirectional LSP
protection: How is co-routing preserved for the reverse path in SMP?
I'd assumed the protection switch coordination protocol would be
required to trigger a switchover of the reverse LSP in the co-routed
case, but don't see this in the document.

- In section 4 and 5.2 you reference 5712 and 3209 as defining
preemption terminology and behavior. I think 6372 is the right
reference here as it defines both in the context of survivability and
in dependent of control plane.

- In section 4.2 you say "Therefore, it is suggested that this be
carried out under the control of a dynamic control plane similar to
GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, = great,
please make the correction. If not, I think the debate of which
control protocol is used for MPLS-TP is way beyond the scope of this
document.

- Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? = If
referring to solutions conformant with this document, then these are
informative statements, "and a non-control plane based SMP switchover<= br> mechanism is used, the control plane SHALL NOT ...". If referring to an operator's/user's choice of protection mechanism, I think the mo= st
you can say is MAY.

- Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP=
domain." As this is a requirement, what you mean by "tie-breaking=
rules" should be defined directly or by reference.

- Section 5.3. RFC6372 takes an approach where preemption notification
leverages the standard MPLS-TP OAM mechanisms, is there any reason to
do more / not just follow 6372?

- Section 5.7. There may be coordination required on soft-preemption as
well (depending on the cross-connects established during LSP
establishment) so coordinated switching should be supported
independent of preemption mode.

Nits:

- Abstract: I don't recall the term "executive action" being = used in any
earlier related/referenced RFCs. Rather than introduce a new (and
undefined) term, perhaps you can use an existing one, e.g.,
"protection switch"?

- Section 1, paragraph 1. Do we really need another definition of
MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP
document(s) and dropping the first four sentences.

The last sentence also makes a subjective statement. Whether it is
critical or no is unnecessary. You can just say something like 6372
provides a survivability framework for MPLS-TP and is the foundation
for this document.

- Section 1, paragraph 3. Isn't the right reference 4427 not 4428?
Also drop the word linear, as it is an unnecessary qualifier and
4427/4428 don't use it.

- Sections 3 (and to a lesser degree section 2) are really introductory
text. I'm unsure as to why they aren't part of section 1.

- Section 3.2 should have a reference for "existing control plane
solutions for SMP within MPLS".

- Section 3.2 again uses the "executive action" term.

- Section 4.1. You say "two operations simultaneously". Do you re= ally
mean "simultaneously" or merely that they must both occur for
protection to be provided? (Same comment in section 5.1.

- Section 5.2. I suggest numbering the currently bulletted requirements
list.

- Section 5.2: First paragraph and forth bullet last sentence. These
both basically cover the same topic (preemption) and actually say
slightly different things. I suggest combine into a single
requirement to ensure consistency and full coverage of the topic.

- Section 5.2, req 5. How does this relate to section 5.5? Shouldn't the topics related to timing be consolidated?

- Section 5.2: requirement 6 seems to be a subset of 7, so it should be
dropped.

- Section 5.2, requirement 8. Isn't this a subset of 9? Why call out just this one traffic treatment (sub) requirement?

- Section 5.3. s/MAY/will

- section 5.4: " When the working path detects.." detection is by= the
node not the path.

- Section 5.4, last sentence. This is only the 2nd time you imply that
the document covers requirements on a new protocol. I think this
point is currently too subtle in the document. (This point was also
made as a minor comment.)

- section 5.6. RFC 6372 should be referenced


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--f46d04428e02290ddc04fd778926-- From nobody Mon Jul 7 12:59:20 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997831B28B5 for ; Mon, 7 Jul 2014 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqyNCPC8JNKx for ; Mon, 7 Jul 2014 12:56:52 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id 277D71B28A8 for ; Mon, 7 Jul 2014 12:56:52 -0700 (PDT) Received: from [65.190.6.125] ([65.190.6.125:49128] helo=[10.0.1.6]) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 79/B8-20336-28BFAB35; Mon, 07 Jul 2014 19:56:51 +0000 From: Acee Lindem Content-Type: multipart/alternative; boundary="Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70" Date: Mon, 7 Jul 2014 15:56:49 -0400 Message-Id: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> To: Ladislav Lhotka , netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/rwYH_9L0g9-6_FZRQEwjjwG6UNk X-Mailman-Approved-At: Mon, 07 Jul 2014 12:59:19 -0700 Cc: rtg-dir@ietf.org Subject: [RTG-DIR] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:56:53 -0000 --Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir =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-ietf-netmod-routing-cfg-15 Reviewer: Acee Lindem Review Date: July 8th, 2014 IETF LC End Date: TBD=20 Intended Status: Proposed Standard=20 Summary: There some issues with the model in the document that need to = be addressed prior to publication of this draft.=20 Fundamental Question: Going forward, how will this YANG data model = relate to the I2RS RIB information model proposed in = draft-ietf-i2rs-rib-info-model-03.txt?=20 Major Issues: =20 Section 4 & 5.4: These sections appear to restrict a routing = protocol instance to exactly one RIB for each address family that the = routing protocol instance supports. RFC 4915, et al, support a single = routing protocol instance which may populate multiple RIBs per address = family.=20 Section 7: What are the backup next-hops? I guess these are = IP-FRR next-hops that are installed by the same source protocol as the = primaries? If so, do you have to restrict the forwarding paradigm to not = use any backup next-hops as long as primary next-hops are accessible? = This would imply that forwarding plane would need to do a fast rehash of = the primaries and only use after all primaries are expired. There are = other lower overhead forwarding paradigms in use.=20 Missing: There is no concept of administrative distance (Cisco, et = al) or route preference (gated and Juniper). In my opinion, this is very = important since it determine which route is active when the same route = is available from multiple protocols.=20 =20 Missing: How does one get the best route for a given protocol = (which is not necessarily the active route)? Should each protocol have a = local RIB as part of its model? I notice that this is not included in = the RIP example in Appendix C. Would that need to be part of the run = state for the protocol?=20 Minor issues:=20 Section 9: Should there be checking to assure the router = advertisement mtu does not exceed the ipv6 MTU from RFC 7277?=20 Questions: I guess the list routing protocol instances is independent in = routing-protocols is independent of definition of the routing protocol = itself? Or, would it be expected that the YANG model for the routing = protocol itself would be here? If the former, wouldn=92t this = configuration be better grouped with the routing protocol themselves?=20 In section 9, the placement of the router advertisement = configuration seems rather arbitrary and I would have expected it to be = grouped with the other interface configuration in RFC 7277. I guess = placement here is the consensus of the netmod WG.=20 Thanks, Acee=20 =20= --Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
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://trac.= tools.ietf.org/area/rtg/trac/wiki/RtgDir
 
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-netmod-routing-cfg-15
Reviewer: Acee = Lindem
Review = Date: July 8th, 2014
IETF LC End Date: TBD 
Intended Status: Proposed = Standard 

Summary: There some issues with the model in the document that = need to be addressed prior to publication of this draft. 

Fundamental Question: = Going forward, how will this YANG data model relate to the I2RS RIB = information model proposed in = draft-ietf-i2rs-rib-info-model-03.txt? 

Major Issues: =  

       Section 4 & 5.4:  These = sections appear to restrict a routing protocol instance to exactly one = RIB for each address family that the routing protocol instance supports. = RFC 4915, et al, support a single routing protocol instance which may = populate multiple RIBs per address family. 

      =  Section 7: What are the backup next-hops? I guess these are IP-FRR = next-hops that are installed by the same source protocol as the = primaries? If so, do you have to restrict the forwarding paradigm to not = use any backup next-hops as long as primary next-hops are accessible? = This would imply that forwarding plane would need to do a fast rehash of = the primaries and only use after all primaries are expired. There are = other lower overhead forwarding paradigms in use. 

      = Missing: There is no concept of administrative distance (Cisco, et al) = or route preference (gated and Juniper). In my opinion, this is very = important since it determine which route is active when the same route = is available from multiple protocols. 
      =                
      = Missing: How does one get the best route for a given protocol (which is = not necessarily the active route)? Should each protocol have a local RIB = as part of its model? I notice that this is not included in the RIP = example in Appendix C. Would that need to be part of the run state for = the protocol? 

Minor issues: 

     Section 9: Should there be = checking to assure the router advertisement mtu does not exceed the ipv6 = MTU from RFC 7277? 


Questions:
        I guess the list routing = protocol instances is independent in routing-protocols is independent of = definition of the routing protocol itself? Or, would it be expected that = the YANG model for the routing protocol itself would be here? If the = former, wouldn=92t this configuration be better grouped with the routing = protocol themselves? 

       In section 9, the placement = of the router advertisement configuration seems rather arbitrary and I = would have expected it to be grouped with the other interface = configuration in RFC 7277. I guess placement here is the consensus of = the netmod WG. 


Thanks,
Acee 

                 =   
= --Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70-- From nobody Tue Jul 8 03:56:28 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908DD1B27F6; Tue, 8 Jul 2014 03:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4e4Zh7yCDdb; Tue, 8 Jul 2014 03:35:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B02C1B2A65; Tue, 8 Jul 2014 03:35:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E0BF75407DB; Tue, 8 Jul 2014 12:34:58 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXTxkEk-bV1B; Tue, 8 Jul 2014 12:34:54 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9DE5F540138; Tue, 8 Jul 2014 12:34:53 +0200 (CEST) From: Ladislav Lhotka To: Acee Lindem , netmod@ietf.org In-Reply-To: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> References: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 08 Jul 2014 12:34:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/RSn20AQgZlymUcgikpgqy6kNACQ X-Mailman-Approved-At: Tue, 08 Jul 2014 03:56:26 -0700 Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 10:35:04 -0000 Hi Acee, thank you for the review, my comments are inline. Acee Lindem writes: > Hello, >=20=20 > I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see h= ttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20=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 discussi= on or by updating the draft. >=20=20 > Document: draft-ietf-netmod-routing-cfg-15 > Reviewer: Acee Lindem > Review Date: July 8th, 2014 > IETF LC End Date: TBD=20 > Intended Status: Proposed Standard=20 > > Summary: There some issues with the model in the document that need to be= addressed prior to publication of this draft.=20 > > Fundamental Question: Going forward, how will this YANG data model > relate to the I2RS RIB information model proposed in > draft-ietf-i2rs-rib-info-model-03.txt? After IETF 87, the relevant parts of two models were compared, and this resulted in several changes and additions in the NETMOD model. Since then, the I2RS model underwent some changes but the only parameter that needs to be included in the NETMOD model is route-preference. Other parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be added later via augmentation. On the other hand, one of the results of the alignment with I2RS RIB info model, was the addition of the "id" key to every single route. In the discussion with I2RS folks, I raised objections against this unique "id" because it could mean considerable bookkeeping for a RIB containing ~200K routes, but we eventually agreed to add it to the NETMOD model. Later, several people repeated my concerns, and I think this "id" should be removed from the NETMOD model.=20=20=20 =20 > > Major Issues:=20=20 > > Section 4 & 5.4: These sections appear to restrict a routing > protocol instance to exactly one RIB for each address family > that the routing protocol instance supports. RFC 4915, et al, > support a single routing protocol instance which may populate > multiple RIBs per address family. This issue was brought up in a recent discussion with people working on data models for OSPF and ISIS, and the rough consensus is that this restriction should be lifted. By default, routes from a routing protocol instance will be installed in all connected RIBs of the corresponding address family (subject to operator-defined route filters), but data models for particular protocols can state other rules how connected RIBs are populated, e.g. using MT-ID.=20=20=20=20 =20 > > Section 7: What are the backup next-hops? I guess these are > IP-FRR next-hops that are installed by the same source protocol > as the primaries? If so, do you have to restrict the forwarding > paradigm to not use any backup next-hops as long as primary > next-hops are accessible? This would imply that forwarding > plane would need to do a fast rehash of the primaries and only > use after all primaries are expired. There are other lower > overhead forwarding paradigms in use. In this case we only followed suit of the I2RS RIB info model, see sections 2.4.2 and 7.2.4 (protection lists) in draft-ietf-i2rs-rib-info-model-03. > > Missing: There is no concept of administrative distance (Cisco, > et al) or route preference (gated and Juniper). In my opinion, > this is very important since it determine which route is active > when the same route is available from multiple protocols. Yes, route-preference will be added, see above. =20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 > Missing: How does one get the best route for a given protocol > (which is not necessarily the active route)? Should each > protocol have a local RIB as part of its model? I notice that > this is not included in the RIP example in Appendix C. Would > that need to be part of the run state for the protocol? Yes, data models for each routing protocol should include necessary protocol-internal data structures as state data - for example BGP RIB or link-state database. =20 > > Minor issues:=20 > > Section 9: Should there be checking to assure the router > advertisement mtu does not exceed the ipv6 MTU from RFC 7277? Yes, the description of the "link-mtu" leaf should mention this constraint. It cannot be done using the "must" statement though because the "ip:mtu" leaf is optional and the ietf-ip module defines no default for it (the default depends on interface type). =20 > > > Questions: > I guess the list routing protocol instances is independent in > routing-protocols is independent of definition of the routing > protocol itself? Or, would it be expected that the YANG model > for the routing protocol itself would be here? If the former, > wouldn=E2=80=99t this configuration be better grouped with the ro= uting > protocol themselves? I am not sure I understand the question but data models for individual routing protocols will be defined in separate YANG modules and will augment the "routing-protocol" list, both in configuration and state data. So, configuration parameters for a routing protocol will eventually appear under "routing-protocol" but will be defined separately. =20 > > In section 9, the placement of the router advertisement > configuration seems rather arbitrary and I would have expected > it to be grouped with the other interface configuration in RFC > 7277. I guess placement here is the consensus of the netmod WG. The advertisements should be sent only by routers, so I think it is appropriate to have it as a part of router interfaces' config and state data. Quite often (even at IETF meetings) we can see misconfigured hosts sending these advertisements. Thanks, Lada > > > Thanks, > Acee=20 > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 8 03:56:48 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE31B2800 for ; Tue, 8 Jul 2014 03:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juON_sV_a_Vq for ; Tue, 8 Jul 2014 03:56:35 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id A58151B2853 for ; Tue, 8 Jul 2014 03:56:31 -0700 (PDT) Received: (qmail 30992 invoked by uid 0); 8 Jul 2014 10:56:26 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 8 Jul 2014 10:56:26 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id PmwK1o00N2SSUrH01mwN9f; Tue, 08 Jul 2014 04:56:25 -0600 X-Authority-Analysis: v=2.1 cv=EJKVjTpC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=zqHLjNqbk_wA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=7xPyp7LSBkGDkgT6ofoA:9 a=3rl6ZFYCiICjTTEz:21 a=DJTLcd-5B76n8cFT:21 a=QEXdDO2ut3YA:10 a=33rK67OTR_gA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QRBioTGF407aBSfevLLg+Qv45Zy/+6tNFYt6HIMCJiU=; b=d7DyaLADFY2OPWMjLtvRkjXnVtKfiycMAE3/MwM/UtN9qQYV1jwFcd5+o6zZe1xH4ay+5L+L3h1lRh6pmYnM/EkZAxbrgYSALhEJiz1MkGLZmKAY4Vc4uhXyO//UfnTq; Received: from box313.bluehost.com ([69.89.31.113]:51191 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X4T4O-0001eO-2y; Tue, 08 Jul 2014 04:56:20 -0600 Message-ID: <53BBCE48.7060008@labn.net> Date: Tue, 08 Jul 2014 06:56:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yaacov Weingarten , Jeong Ryoo References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/wOJIschXBz9NhUk18ZdyxuWAV6U Cc: "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 10:56:38 -0000 Yaacov, Sounds reasonable, but I'll need to see the new wording to be sure. Thanks, Lou On 7/5/2014 3:49 PM, Yaacov Weingarten wrote: > > Lou, hi > I would like to address two of your comments, in your follow-up > message, since I am the source of the change in terminology. > > Regarding the two occurences of "assigned" in place of "utilized" - > when I read the proposed changes,as discussed amongst the authors, I > felt that in those two instances the use of "utilized" could lead to > some ambiguity. > > If we state that "resources SHOULD be utilized on a first come first > served basis" this could be interpreted (IMO) as referring to the > packet level, rather than utilized by a specific path, such that > packets from different paths could be interspersed along the shared > segments. Therefore,I suggested that or this context it would be > better to use a word that meant that the first-come first served basis > was at the level of assigning (or allocating) the resources rather > than utilizing them. > > Hope this clarifies this point. I am certain that I speak for the > other authors in saying that I am open to other suggestions. > > BR, > yaacov > > On Jul 4, 2014 3:53 AM, "Jeong Ryoo" > wrote: > > Dear Lou, > > > > Thanks a lot for your valuable comments. > > > > The authors of this draft have discussed your comments, and are > proposing our resolutions to your comments. Please, let us know if > the proposal is appropriate to address your comments and concerns. > > > > Best regards, > > > > Authors of draft-ietf-mpls-smp-requirements draft > > > > ****** Beginning of Comment Resolution ****** > > > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > > > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, > we concluded that the distinction between protection and > restoration should be aligned with the exiting documents > normatively referenced by this document. Accordingly, the > following 16 modifications will be done in revision: > > > > (1) Section 1, the third paragraph > > OLD: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 linear protection requires > > that resources are committed for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are committed, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > NEW: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 protection requires > > that resources are allocated for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are allocated, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > > > (2) The whole text in Section 3.1 will be replaced with: > > [RFC6372], based upon the definitions in [RFC4427], differentiates > between "protection" and "restoration" dependent upon the dynamism > of the resource allocation. The same distinction is used in > [RFC3945], [RFC4426], and [RFC4428]. This document also uses the > same distinction between protection and restoration as stated in > [RFC6372]. > > > > (3) In page 6, > > OLD: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine to which parties the protection > > resources are committed. > > NEW: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine which parties utilize the > protection > > resources. > > > > (4) Page 7, the first paragraph: > > OLD: > > the resources for the protection path are fully committed, > > NEW > > the resources for the protection path are fully dedicated, > > > > OLD: > > resources may be planned but would not be committed until … > > NEW: > > resources may be planned but would not be utilized until … > > > > (5) In the second paragraph in page 7, > > OLD: > > "Hard Preemption" requires the programming of selectors at the > ingress of each shared segment to specify which backup path has > the highest priority when committing protection resources, the > others being preempted. > > NEW > > "Hard Preemption" requires the programming of selectors at the > ingress of each shared segment to specify the priorities of backup > paths, so that traffic of lower priority paths can be preempted. > > > > (6) The first paragraph of Section 4.1: > > OLD: > > … and commit the associated resources. The commitment of resources > > is dependent upon … > > NEW: > > … and coordinate the utilization of the associated shared resources. > > The resource utilization coordination is dependent upon … > > > > (7) The second paragraph of Section 4.1: > > OLD: > > When the reserved resources of the shared segments are committed to a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the commitment of the resources may fail. In order to > > optimize the operation of the commitment and preparing for cases of > > multiple working paths failing, the commitment of the shared > > resources are be coordinated between the different working paths in > > the SMP network. > > NEW: > > When the reserved resources of the shared segments are utilized by a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the resource utilization coordination may fail. The > different working paths in > > the SMP network are involved in the resource utilization > coordination. > > . > > > > (8) Section 5.1, > > OLD: > > … and commit the associated resources. > > NEW > > … and coordinate the utilization of the associated shared resources. > > > > (9) In Section 5.1, > > OLD: > > In the case of multiple working paths failing, the commitment of the > > shared resources SHALL be coordinated between the different working > > paths in the SMP network. > > NEW: > > In the case of multiple working paths failing, the shared resource > utilization > > coordination SHALL be between the different working > > paths in the SMP network. > > > > (10) Section 5.1.1. > > OLD: > > … because they already have been committed to the protection of, > for example, a higher priority working path. > > NEW: > > … because they already have been utilized for the protection of, > for example, a higher priority working path. > > > > (11) Section 5.2, the second bullet item: > > OLD: > > Resources of the shared segments SHALL be committed to the > > protection path … > > NEW: > > Resources of the shared segments SHALL be utilized by the > > protection path … > > > > (12) Section 5.2, the third bullet item: > > OLD: > > If multiple protection paths of equal priority are requesting > > allocation of the shared resources, the resources SHOULD be > > committed on a first come first served basis. > > NEW: > > If multiple protection paths of equal priority are requesting > > the shared resources, the resources SHOULD be > > assigned on a first come first served basis. > > > > (13) Section 5.2, the fourth bullet item: > > OLD: > > If the protection resources are committed to a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be committed to the higher priority > > path. > > NEW: > > If the protection resources are utilized by a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be assigned to the higher priority > > path. > > > > > > (14) Section 5.2. the seventh bullet item > > OLD: > > Once resources of shared segments have been successfully committed > > to a protection path, … > > NEW: > > Once resources of shared segments have been successfully utilized > > by a protection path, … > > > > (15) Section 5.3, the first paragraph, > > OLD: > > … request the commitment of protection resources. If the necessary > > shared resources are unavailable to be committed to the protection > > path, the endpoints … > > > > NEW: > > … request the coordination of the shared resource utilization. If > the necessary > > shared resources are unavailable, the endpoints … > > > > (16) Section 5.3, the second paragraph, > > OLD: > > Similarly, if preemption is supported and the resources currently > > committed for a particular working path are … > > NEW: > > Similarly, if preemption is supported and the resources currently > > utilized by a particular working path are … > > > > > > - Section 2, 1st paragraph, last sentence. This sentence really > defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > [Authors] We can add the following paragraph at the end of Section 1: > > “This document is intended to clarify the instructions to protocol > designers producing solutions that satisfy the requirements set > out in this document.†> > > > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > [Authors] Fate-sharing is not required by this document. Even in > the PSC linear protection switching, such as RFC 6378 (PSC) and > RFC 7271 (PSC in APS mode), fate-sharing is not required as > unidirectional switching is allowed. This document does not impose > any restriction on co-routing, either. > > > > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > [Authors] One concern is that RFC 6372 describes both soft and > hard preemptions in the context of extra traffic, which is not > exactly the case for SMP. > > > > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > [Authors] Yes, we will make the correction. > > > > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > [Authors] The first case is the one we are aiming at. We will use > SHALL NOT. > > > > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > [Authors] The sentence can be rewritten as: > > OLD: > > Tie-breaking rules SHALL be defined in scope of an SMP domain. > > NEW: > > In order to cover the situation where the first come first served > principle cannot resolve the contention among multiple equal > priority requests, i.e., when the requests occur simultaneously,, > tie-breaking rules SHALL be defined in scope of an SMP domain. > > > > > > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > [Authors] We can add the following sentence at the end: > > “As described in [RFC6372], the event of preemption may be > detected by OAM and reported as a fault or a degradation of > traffic delivery.†> > > - Section 5.7. There may be coordination required on > soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > [Authors] Yes, we will change the second paragraph from “SMP in > hard-preemption mode SHOULD …†to “SMP SHOULD …†and move the > changed paragraph above the first paragraph. > > > > > Nits: > > - Abstract: I don't recall the term "executive action" being used > in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > [Authors] Yes, the term will be changed as you suggested. > > > > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > [Authors] The proposed text for the paragraph 1 is: > > “The MPLS Transport Profile (MPLS-TP) is described in [RFC5921], > > and [RFC6372] provides a survivability framework for MPLS-TP > > and is the foundation for this document.†> > > > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > [Authors] OK. > > > > > > > - Sections 3 (and to a lesser degree section 2) are really > introductory > text. I'm unsure as to why they aren't part of section 1. > > [Authors] Section 3 was intended to present a reference model for > SMP. Some text of Section 2 is repeated in Section 1 as you > suggested earlier. > > > > > > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > [Authors] [RFC4206] will be added as a reference > > > - Section 3.2 again uses the "executive action" term. > > [Authors] OK, the term will be changed. > > > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > [Authors] Both actions should occur at the same time, or as > closely as possible to provide fast protection. > > > > > - Section 5.2. I suggest numbering the currently bulletted > requirements > list. > > [Authors] OK, we will use numbers. > > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > [Authors] The first paragraph is for soft-preemption, while the > fourth bullet belongs to the requirements of hard-preemption. > > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > [Authors] Yes, req 5 can be moved to Section 5.5. > > > > > - Section 5.2: requirement 6 seems to be a subset of 7, so it > should be > dropped. > > [Authors] Yes, it will be deleted. > > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > [Authors] Req. 9 will be deleted as it seems to require control > plane supports. > > > > - Section 5.3. s/MAY/will > > [Authors] OK. > > > > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > [Authors] Yes. We will simply say that “When the condition that > triggered the protection switching is cleared, …†> > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > [Authors] As in other protection switching technologies, two modes > of operations (revertive and non-revertive) are required. > > > > > - section 5.6. RFC 6372 should be referenced > > [Authors] We will add “as described in [RFC6372]†to the ends of > two paragraphs for WTR timer and hold-off timer. > > > > ***** End of Comment resolution ***** > > > > > > > ------------------------------------------------------------------------ > *보낸 사람 : *"Lou Berger" > > *보낸 날짜 : *2014-06-22 01:00:48 ( +09:00 ) > *받는 사람 : *rtg-ads@tools.ietf.org > > > *참조 : *rtg-dir@ietf.org > >, > draft-ietf-mpls-smp-requirements.all@tools.ietf.org > > >, > mpls@ietf.org > > *제목 : *[mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt > > > 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > 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-mpls-smp-requirements-06.txt > Reviewer: Lou Berger > Review Date: June 21 2014 > IETF LC End Date: 2014-06-23 > Intended Status: Informational > > Summary: > I have some minor concerns about this document that I think > should (must, actually) be resolved before publication. > > Comments: > > I think the document is well written and, other than a couple of > terminology related issues, easily understood. The document does > have a number of terminology and technical issues which should be > readily resolved prior to publication. > > Major Issues: > > Major issues are the type of concerns that will result in the > document being blocked until they are resolved. The Routing ADs will > become involved. Please include all of the major issues you have > found. Give as much context information as possible (e.g., section > numbers, paragraph counts). If you find no major issues, please > write: "No major issues found." > > - No major issues found. In particular, I expect all issues can be > resolved without AD intervention. Some of the minor issues, if not > resolved will be escalated to the AD/major issue category. > > Minor Issues: > > Minor issues are concerns about clarity or technical accuracy that > should be discussed and resolved before publication, but which would > normally be resolved between the authors and the reviewers. Please > include all of the minor issues you have found. Give as much context > information as possible (e.g., section numbers, paragraph counts). > If you find no minor issues, please write: "No minor issues found." > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > - Section 2, 1st paragraph, last sentence. This sentence really > defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > - Section 5.7. There may be coordination required on > soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > Nits: > > - Abstract: I don't recall the term "executive action" being used > in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > - Sections 3 (and to a lesser degree section 2) are really > introductory > text. I'm unsure as to why they aren't part of section 1. > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > - Section 3.2 again uses the "executive action" term. > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > - Section 5.2. I suggest numbering the currently bulletted > requirements > list. > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > - Section 5.2: requirement 6 seems to be a subset of 7, so it > should be > dropped. > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > - Section 5.3. s/MAY/will > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > - section 5.6. RFC 6372 should be referenced > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Jul 8 14:07:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA51A007A for ; Tue, 8 Jul 2014 14:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnJr00DCPAWH for ; Tue, 8 Jul 2014 14:02:06 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7FD1A0068 for ; Tue, 8 Jul 2014 14:02:05 -0700 (PDT) Received: from [65.190.6.125] ([65.190.6.125:34131] helo=[10.0.1.6]) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 72/B9-20336-C4C5CB35; Tue, 08 Jul 2014 21:02:05 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Acee Lindem In-Reply-To: Date: Tue, 8 Jul 2014 17:02:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1878.6) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Q2eBtTSbqYiAB9aXk_gJOjdkTmE X-Mailman-Approved-At: Tue, 08 Jul 2014 14:07:44 -0700 Cc: rtg-dir@ietf.org, netmod@ietf.org Subject: Re: [RTG-DIR] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 21:02:08 -0000 Hi Lada,=20 Thanks for your responses. It seems that you will publish a new revision = that covers most of my comments. I will await that update and review. = With respect to only supporting the forwarding model where none of the = backup paths are used until all the primaries are unavailable, I will = discuss the with a few more people and get back to you.=20 Thanks, Acee=20 On Jul 8, 2014, at 6:34 AM, Ladislav Lhotka wrote: > Hi Acee, >=20 > thank you for the review, my comments are inline. >=20 > Acee Lindem writes: >=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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>=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-ietf-netmod-routing-cfg-15 >> Reviewer: Acee Lindem >> Review Date: July 8th, 2014 >> IETF LC End Date: TBD=20 >> Intended Status: Proposed Standard=20 >>=20 >> Summary: There some issues with the model in the document that need = to be addressed prior to publication of this draft.=20 >>=20 >> Fundamental Question: Going forward, how will this YANG data model >> relate to the I2RS RIB information model proposed in >> draft-ietf-i2rs-rib-info-model-03.txt? >=20 > After IETF 87, the relevant parts of two models were compared, and = this > resulted in several changes and additions in the NETMOD model. Since > then, the I2RS model underwent some changes but the only parameter = that > needs to be included in the NETMOD model is route-preference. Other > parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be added > later via augmentation. >=20 > On the other hand, one of the results of the alignment with I2RS RIB > info model, was the addition of the "id" key to every single route. In > the discussion with I2RS folks, I raised objections against this = unique > "id" because it could mean considerable bookkeeping for a RIB = containing > ~200K routes, but we eventually agreed to add it to the NETMOD > model. Later, several people repeated my concerns, and I think this = "id" > should be removed from the NETMOD model. =20 >=20 >>=20 >> Major Issues: =20 >>=20 >> Section 4 & 5.4: These sections appear to restrict a routing >> protocol instance to exactly one RIB for each address family >> that the routing protocol instance supports. RFC 4915, et al, >> support a single routing protocol instance which may populate >> multiple RIBs per address family. >=20 > This issue was brought up in a recent discussion with people working = on > data models for OSPF and ISIS, and the rough consensus is that this > restriction should be lifted. By default, routes from a routing = protocol > instance will be installed in all connected RIBs of the corresponding > address family (subject to operator-defined route filters), but data > models for particular protocols can state other rules how connected = RIBs > are populated, e.g. using MT-ID. =20 >=20 >>=20 >> Section 7: What are the backup next-hops? I guess these are >> IP-FRR next-hops that are installed by the same source protocol >> as the primaries? If so, do you have to restrict the forwarding >> paradigm to not use any backup next-hops as long as primary >> next-hops are accessible? This would imply that forwarding >> plane would need to do a fast rehash of the primaries and only >> use after all primaries are expired. There are other lower >> overhead forwarding paradigms in use. >=20 > In this case we only followed suit of the I2RS RIB info model, see > sections 2.4.2 and 7.2.4 (protection lists) in > draft-ietf-i2rs-rib-info-model-03. >=20 >>=20 >> Missing: There is no concept of administrative distance (Cisco, >> et al) or route preference (gated and Juniper). In my opinion, >> this is very important since it determine which route is active >> when the same route is available from multiple protocols. >=20 > Yes, route-preference will be added, see above. >=20 >>=20 >> Missing: How does one get the best route for a given protocol >> (which is not necessarily the active route)? Should each >> protocol have a local RIB as part of its model? I notice that >> this is not included in the RIP example in Appendix C. Would >> that need to be part of the run state for the protocol? >=20 > Yes, data models for each routing protocol should include necessary > protocol-internal data structures as state data - for example BGP RIB = or > link-state database. >=20 >>=20 >> Minor issues:=20 >>=20 >> Section 9: Should there be checking to assure the router >> advertisement mtu does not exceed the ipv6 MTU from RFC 7277? >=20 >=20 > Yes, the description of the "link-mtu" leaf should mention this > constraint. It cannot be done using the "must" statement though = because > the "ip:mtu" leaf is optional and the ietf-ip module defines no = default > for it (the default depends on interface type). >=20 >>=20 >>=20 >> Questions: >> I guess the list routing protocol instances is independent in >> routing-protocols is independent of definition of the routing >> protocol itself? Or, would it be expected that the YANG model >> for the routing protocol itself would be here? If the former, >> wouldn=92t this configuration be better grouped with the = routing >> protocol themselves? >=20 > I am not sure I understand the question but data models for individual > routing protocols will be defined in separate YANG modules and will > augment the "routing-protocol" list, both in configuration and state > data. So, configuration parameters for a routing protocol will > eventually appear under "routing-protocol" but will be defined > separately. >=20 >>=20 >> In section 9, the placement of the router advertisement >> configuration seems rather arbitrary and I would have expected >> it to be grouped with the other interface configuration in RFC >> 7277. I guess placement here is the consensus of the netmod WG. >=20 > The advertisements should be sent only by routers, so I think it is > appropriate to have it as a part of router interfaces' config and = state > data. Quite often (even at IETF meetings) we can see misconfigured = hosts > sending these advertisements. >=20 > Thanks, Lada >=20 >>=20 >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Thu Jul 10 04:55:50 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AA11B2888; Thu, 10 Jul 2014 04:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.488 X-Spam-Level: ** X-Spam-Status: No, score=2.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6tCXQP3UoOP; Thu, 10 Jul 2014 04:55:44 -0700 (PDT) Received: from newdragon.webhostserver.biz (unknown [69.25.137.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B2D1A03F6; Thu, 10 Jul 2014 04:55:44 -0700 (PDT) Received: from localhost ([::1]:34147 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X5Cwv-0005kd-5Q; Thu, 10 Jul 2014 15:55:41 +0400 Message-ID: <53BE7F3B.9010005@labn.net> Date: Thu, 10 Jul 2014 07:55:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?66WY7KCV64+Z?= References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/oDAvmTD_U0LKVWH_eXb5p0ASyaQ Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] =?utf-8?b?7ZqM7IugOiAgW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRy?= =?utf-8?q?aft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lberger@labn.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:55:47 -0000 Jeong-dong, Thank you for the response, see below. On 7/10/2014 2:55 AM, ë¥˜ì •ë™ wrote: > > Thank you, Lou > > Please, see the lines starting with [JR] for my responses to your comments. > > I removed the parts that we have already agreed on. I also erased your comments that are minor editorial and will be reflected in the next version as you suggested. The two “assigned†related comments are not covered here as they are being discussed with Yaacov. > > Best regards, > > Jeong-dong > > ****** > > (4) Page 7, the first paragraph: > OLD: > the resources for the protection path are fully committed, > NEW > the resources for the protection path are fully dedicated, > > Dedicated is also an ambiguous term, how about: > OLD > the resources for the protection path are fully committed, the > protection path in the case of SMP consists of segments that are > dedicated to the protection of the related working path and also > NEW > the resources for the protection path are fully allocated, the > protection path in the case of SMP consists of segments that are > allocated to the protection of the related working path and also > > [JR] This paragraph describes the difference between linear protection and shared mesh protection from the perspective of protection resource sharing. In linear protection switching, the resources are not shared but dedicated to the protection path. SMP has shared resources in some segments. I think the word, “dedicated†is general enough to be used without any further definition. RFC 6372 also uses “dedicated“, and this document follows the same use as in RFC 6372 I think the (new) first usage of dedicated in paragraph is fine, it's the second I have a real issue with. I suggested changing both to avoid the term altogether. The way "dedicated" is used in the second sentence is in the context of SMP, while RFC6372 uses "dedicated" the context of "Dedicated Protection" which is contrasted with "Shared Protection". How about: NEW the resources for the protection path are fully dedicated, the protection path in the case of SMP consists of segments that are used for protection of the related working path and also > > > (7) The second paragraph of Section 4.1: > OLD: > When the reserved resources of the shared segments are committed to a > particular protection path, there may not be sufficient resources > available for an additional protection path. This then implies that > if another working path of the SMP domain triggers a protection > switch, the commitment of the resources may fail. In order to > optimize the operation of the commitment and preparing for cases of > multiple working paths failing, the commitment of the shared > resources are be coordinated between the different working paths in > the SMP network. > NEW: > When the reserved resources of the shared segments are utilized by a > particular protection path, there may not be sufficient resources > available for an additional protection path. This then implies that > if another working path of the SMP domain triggers a protection > switch, the resource utilization coordination may fail. The different working paths in > the SMP network are involved in the resource utilization coordination. > > > This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.) > > [JR] As described in an earlier part of this section, SMP protection consists of two operations: traffic switchover and resource utilization coordination. The sentences are about the resource utilization coordination, and “resource utilization†seems to be more accurate. Is "resource utilization coordination" done via some form of inter-node coordination? If yes, then I think my comment holds. If no, then I think you should elabotate on how the "coordination" in this case differes from how you use "coordination" elsewhere in the document. Either way, I think we've discussed this enough, i.e., I won't push this point further. > > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > [Authors] Fate-sharing is not required by this document. Even in the PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in APS mode), fate-sharing is not required as unidirectional switching is allowed. This document does not impose any restriction on co-routing, either. > > > Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic. Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG. (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".) > > [JR] O.K. I guess that mandating bidirectional switching does not mean that unidirectional switching is prohibited. What we can do is that, after changing the title of Section 5.4. from “Revertive protection switching†to “Reversion and Fate-sharingâ€, one paragraph with the following sentence will be added: “Bidirectional protection switching SHOULD be supported in SMP.†The topics are essentially orthognal, i.e., supporting one without the other is completly reasonable. If you don't want to add a dedicated section, then Sections 5.7, 5.3 and perhaps even 5.5 are better choices. > > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > [Authors] One concern is that RFC 6372 describes both soft and hard preemptions in the context of extra traffic, which is not exactly the case for SMP. > > Then 6372 should be referenced and the difference should be described. Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies. 6372 is after all titled "MPLS-TP Survivability Framework"... > > [JR] O.K. 6372 will be referenced and we can add the following sentence as the third sentence in the paragraph: “The traffic of lower priority paths in this document can be viewed as the extra traffic being preempted in [RFC6372].†great. > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > [Authors] Both actions should occur at the same time, or as closely as possible to provide fast protection. > > What text change is planned? > > [JR] We can erase “simultaneously†and add the sentence (“Both operations should occur at the same time, or as closely as possible to provide fast protection.â€) as the second sentence of the paragraph. WFM. > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > [Authors] The first paragraph is for soft-preemption, while the fourth bullet belongs to the requirements of hard-preemption. > > Do you plan a text change? (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.) > > [JR] OK. We can make them clear. How about the following arrangement? > > 5.2. Multiple triggers > > If more than one working path is triggering a protection switch such > that a protection segment is oversubscribed, there are two different > actions that the SMP network can choose – soft preemption and hard > preemption. > > 5.2.1. Soft-preemption > > For networks that support multiplexing packets over the shared segments, the requirement is: > > O All of the protection paths MAY be allowed to share the resources > of the shared segments > > 5.2.2 Hard-preemption > > There are networks that require the exclusive use of the protection > resources when a protection segment is oversubscribed. > Traffic of lower priority paths is completely blocked. > These include networks that support the requirements in [RFC5654], > and in particular support requirement 58. For such networks, > the following requirements apply: > > O ... > > O ... > I think this will work. Thanks, Lou ... From nobody Thu Jul 10 05:10:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5E1A0495 for ; Thu, 10 Jul 2014 05:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr1zLQWnzMm5 for ; Thu, 10 Jul 2014 05:10:05 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 6C3C11A03FF for ; Thu, 10 Jul 2014 05:10:05 -0700 (PDT) Received: (qmail 30856 invoked by uid 0); 10 Jul 2014 12:10:02 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 10 Jul 2014 12:10:02 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Qi9j1o00R2SSUrH01i9mc2; Thu, 10 Jul 2014 12:10:00 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=ZSdzdHkL1-cA:10 a=-ANFxW_a3iwA:10 a=HFCU6gKsb0MA:10 a=jPJDawAOAc8A:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=qfHHtKHh6Xq5kuXZ0osA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=cDA9wQrF4DmXfdB8lmw4lXnuWKKV0Y1MAcVk3mc5TGU=; b=hkhlwa3ggFuDuQL+sQUlOzyx+7dls1UeJ6lRFFRh1CI5DilZnvsEKwmO+ows1fiKciJCsUrigYefAvm8vb6JLaEv22KFzt6vVltksk0R8tVaPAMD4AB7XHaprI7pWF3I; Received: from box313.bluehost.com ([69.89.31.113]:54573 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X5DAW-0003p5-RO; Thu, 10 Jul 2014 06:09:45 -0600 Message-ID: <53BE8285.6000106@labn.net> Date: Thu, 10 Jul 2014 08:09:41 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?66WY7KCV64+Z?= References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/4k1XecrAmlZsBgQhRX8S-OEImf4 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] =?utf-8?b?7ZqM7IugOiAgW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRy?= =?utf-8?q?aft-ietf-mpls-smp-requirements-06=2Etxt_=28resend=29?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:10:07 -0000 [Got some odd bounces on my 1st attempt to send this...] Jeong-dong, Thank you for the response, see below. On 7/10/2014 2:55 AM, 류ì •ë™ wrote: > > Thank you, Lou > > Please, see the lines starting with [JR] for my responses to your comments. > > I removed the parts that we have already agreed on. I also erased your comments that are minor editorial and will be reflected in the next version as you suggested. The two “assigned†related comments are not covered here as they are being discussed with Yaacov. > > Best regards, > > Jeong-dong > > ****** > > (4) Page 7, the first paragraph: > OLD: > the resources for the protection path are fully committed, > NEW > the resources for the protection path are fully dedicated, > > Dedicated is also an ambiguous term, how about: > OLD > the resources for the protection path are fully committed, the > protection path in the case of SMP consists of segments that are > dedicated to the protection of the related working path and also > NEW > the resources for the protection path are fully allocated, the > protection path in the case of SMP consists of segments that are > allocated to the protection of the related working path and also > > [JR] This paragraph describes the difference between linear protection and shared mesh protection from the perspective of protection resource sharing. In linear protection switching, the resources are not shared but dedicated to the protection path. SMP has shared resources in some segments. I think the word, “dedicated†is general enough to be used without any further definition. RFC 6372 also uses “dedicated“, and this document follows the same use as in RFC 6372 I think the (new) first usage of dedicated in paragraph is fine, it's the second I have a real issue with. I suggested changing both to avoid the term altogether. The way "dedicated" is used in the second sentence is in the context of SMP, while RFC6372 uses "dedicated" the context of "Dedicated Protection" which is contrasted with "Shared Protection". How about: NEW the resources for the protection path are fully dedicated, the protection path in the case of SMP consists of segments that are used for protection of the related working path and also > > > (7) The second paragraph of Section 4.1: > OLD: > When the reserved resources of the shared segments are committed to a > particular protection path, there may not be sufficient resources > available for an additional protection path. This then implies that > if another working path of the SMP domain triggers a protection > switch, the commitment of the resources may fail. In order to > optimize the operation of the commitment and preparing for cases of > multiple working paths failing, the commitment of the shared > resources are be coordinated between the different working paths in > the SMP network. > NEW: > When the reserved resources of the shared segments are utilized by a > particular protection path, there may not be sufficient resources > available for an additional protection path. This then implies that > if another working path of the SMP domain triggers a protection > switch, the resource utilization coordination may fail. The different working paths in > the SMP network are involved in the resource utilization coordination. > > > This is fine, but I wonder why you are using "resource utilization" vs "protection switch"? (this is actually a bit of a general comment -- I the latter is an existing applicable term that would help readers how this document fits in to the technology space.) > > [JR] As described in an earlier part of this section, SMP protection consists of two operations: traffic switchover and resource utilization coordination. The sentences are about the resource utilization coordination, and “resource utilization†seems to be more accurate. Is "resource utilization coordination" done via some form of inter-node coordination? If yes, then I think my comment holds. If no, then I think you should elabotate on how the "coordination" in this case differes from how you use "coordination" elsewhere in the document. Either way, I think we've discussed this enough, i.e., I won't push this point further. > > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > [Authors] Fate-sharing is not required by this document. Even in the PSC linear protection switching, such as RFC 6378 (PSC) and RFC 7271 (PSC in APS mode), fate-sharing is not required as unidirectional switching is allowed. This document does not impose any restriction on co-routing, either. > > > Both RFC4427 and 6372 mention this (Bi-directional recovery switching in the former). I think this document really needs to mention something on the topic. Given the 6372 a "MAY" level requirement is probably sufficient, but this should be confirmed with the WG. (I personally would like SHOULD as this seems to better match 6372's text "operator often requires...".) > > [JR] O.K. I guess that mandating bidirectional switching does not mean that unidirectional switching is prohibited. What we can do is that, after changing the title of Section 5.4. from “Revertive protection switching†to “Reversion and Fate-sharingâ€Â, one paragraph with the following sentence will be added: “Bidirectional protection switching SHOULD be supported in SMP.†The topics are essentially orthognal, i.e., supporting one without the other is completly reasonable. If you don't want to add a dedicated section, then Sections 5.7, 5.3 and perhaps even 5.5 are better choices. > > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > [Authors] One concern is that RFC 6372 describes both soft and hard preemptions in the context of extra traffic, which is not exactly the case for SMP. > > Then 6372 should be referenced and the difference should be described. Otherwise readers are likely to think you just used the wrong reference and that 6372's text applies. 6372 is after all titled "MPLS-TP Survivability Framework"... > > [JR] O.K. 6372 will be referenced and we can add the following sentence as the third sentence in the paragraph: “The traffic of lower priority paths in this document can be viewed as the extra traffic being preempted in [RFC6372].†great. > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > [Authors] Both actions should occur at the same time, or as closely as possible to provide fast protection. > > What text change is planned? > > [JR] We can erase “simultaneously†and add the sentence (“Both operations should occur at the same time, or as closely as possible to provide fast protection.â€Â) as the second sentence of the paragraph. WFM. > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > [Authors] The first paragraph is for soft-preemption, while the fourth bullet belongs to the requirements of hard-preemption. > > Do you plan a text change? (the 1st paragraph should be a list item and soft-preemption is mentioned as a parenthetical , and the forth doesn't mention its scope as hard preemption.) > > [JR] OK. We can make them clear. How about the following arrangement? > > 5.2. Multiple triggers > > If more than one working path is triggering a protection switch such > that a protection segment is oversubscribed, there are two different > actions that the SMP network can choose – soft preemption and hard > preemption. > > 5.2.1. Soft-preemption > > For networks that support multiplexing packets over the shared segments, the requirement is: > > O All of the protection paths MAY be allowed to share the resources > of the shared segments > > 5.2.2 Hard-preemption > > There are networks that require the exclusive use of the protection > resources when a protection segment is oversubscribed. > Traffic of lower priority paths is completely blocked. > These include networks that support the requirements in [RFC5654], > and in particular support requirement 58. For such networks, > the following requirements apply: > > O ... > > O ... > I think this will work. Thanks, Lou ... From nobody Thu Jul 10 08:50:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3899B1A035C; Wed, 9 Jul 2014 23:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meox6gttRAD5; Wed, 9 Jul 2014 23:55:11 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4EA1A0359; Wed, 9 Jul 2014 23:55:10 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 Jul 2014 15:55:07 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 10 Jul 2014 15:55:04 +0900 From: =?utf-8?B?66WY7KCV64+Z?= To: Lou Berger , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+gAHv9wCAB+MbNg== Date: Thu, 10 Jul 2014 06:55:03 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> In-Reply-To: <53B8190E.6080505@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.4.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/kf3wDrWXZuD6w1QsHnG0e9r6Xzs X-Mailman-Approved-At: Thu, 10 Jul 2014 08:49:44 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] =?utf-8?b?7ZqM7IugOiAgW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRy?= =?utf-8?q?aft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 06:55:14 -0000 DQpUaGFuayB5b3UsIExvdQ0KDQpQbGVhc2UsIHNlZSB0aGUgbGluZXMgc3RhcnRpbmcgd2l0aCBb SlJdIGZvciBteSByZXNwb25zZXMgdG8geW91ciBjb21tZW50cy4gDQoNCkkgcmVtb3ZlZCB0aGUg cGFydHMgdGhhdCB3ZSBoYXZlIGFscmVhZHkgYWdyZWVkIG9uLiBJIGFsc28gZXJhc2VkIHlvdXIg Y29tbWVudHMgdGhhdCBhcmUgbWlub3IgZWRpdG9yaWFsIGFuZCB3aWxsIGJlIHJlZmxlY3RlZCBp biB0aGUgbmV4dCB2ZXJzaW9uIGFzIHlvdSBzdWdnZXN0ZWQuIFRoZSB0d28g4oCcYXNzaWduZWTi gJ0gcmVsYXRlZCBjb21tZW50cyBhcmUgbm90IGNvdmVyZWQgaGVyZSBhcyB0aGV5IGFyZSBiZWlu ZyBkaXNjdXNzZWQgd2l0aCBZYWFjb3YuIA0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcN Cg0KKioqKioqIA0KICANCig0KSBQYWdlIDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQpPTEQ6DQp0 aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBjb21taXR0ZWQs DQpORVcNCnRoZSByZXNvdXJjZXMgZm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGRl ZGljYXRlZCwNCiAgDQpEZWRpY2F0ZWQgaXMgYWxzbyBhbiBhbWJpZ3VvdXMgdGVybSwgaG93IGFi b3V0Og0KT0xEDQogICB0aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBm dWxseSBjb21taXR0ZWQsIHRoZQ0KICAgcHJvdGVjdGlvbiBwYXRoIGluIHRoZSBjYXNlIG9mIFNN UCBjb25zaXN0cyBvZiBzZWdtZW50cyB0aGF0IGFyZQ0KICAgZGVkaWNhdGVkIHRvIHRoZSBwcm90 ZWN0aW9uIG9mIHRoZSByZWxhdGVkIHdvcmtpbmcgcGF0aCBhbmQgYWxzbw0KTkVXDQogICB0aGUg cmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBhbGxvY2F0ZWQsIHRo ZQ0KICAgcHJvdGVjdGlvbiBwYXRoIGluIHRoZSBjYXNlIG9mIFNNUCBjb25zaXN0cyBvZiBzZWdt ZW50cyB0aGF0IGFyZQ0KICAgYWxsb2NhdGVkIHRvIHRoZSBwcm90ZWN0aW9uIG9mIHRoZSByZWxh dGVkIHdvcmtpbmcgcGF0aCBhbmQgYWxzbw0KDQpbSlJdIFRoaXMgcGFyYWdyYXBoIGRlc2NyaWJl cyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGxpbmVhciBwcm90ZWN0aW9uIGFuZCBzaGFyZWQgbWVz aCBwcm90ZWN0aW9uIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHByb3RlY3Rpb24gcmVzb3VyY2Ug c2hhcmluZy4gSW4gbGluZWFyIHByb3RlY3Rpb24gc3dpdGNoaW5nLCB0aGUgcmVzb3VyY2VzIGFy ZSBub3Qgc2hhcmVkIGJ1dCBkZWRpY2F0ZWQgdG8gdGhlIHByb3RlY3Rpb24gcGF0aC4gU01QIGhh cyBzaGFyZWQgcmVzb3VyY2VzIGluIHNvbWUgc2VnbWVudHMuIEkgdGhpbmsgdGhlIHdvcmQsIOKA nGRlZGljYXRlZOKAnSBpcyBnZW5lcmFsIGVub3VnaCB0byBiZSB1c2VkIHdpdGhvdXQgYW55IGZ1 cnRoZXIgZGVmaW5pdGlvbi4gUkZDIDYzNzIgYWxzbyB1c2VzIOKAnGRlZGljYXRlZOKAnCwgYW5k IHRoaXMgZG9jdW1lbnQgZm9sbG93cyB0aGUgc2FtZSB1c2UgYXMgaW4gUkZDIDYzNzINCg0KKDcp IFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4xOg0KT0xEOg0KV2hlbiB0aGUgcmVz ZXJ2ZWQgcmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJlIGNvbW1pdHRlZCB0byBh DQpwYXJ0aWN1bGFyIHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50 IHJlc291cmNlcw0KYXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rpb24gcGF0aC4g VGhpcyB0aGVuIGltcGxpZXMgdGhhdA0KaWYgYW5vdGhlciB3b3JraW5nIHBhdGggb2YgdGhlIFNN UCBkb21haW4gdHJpZ2dlcnMgYSBwcm90ZWN0aW9uDQpzd2l0Y2gsIHRoZSBjb21taXRtZW50IG9m IHRoZSByZXNvdXJjZXMgbWF5IGZhaWwuIEluIG9yZGVyIHRvDQpvcHRpbWl6ZSB0aGUgb3BlcmF0 aW9uIG9mIHRoZSBjb21taXRtZW50IGFuZCBwcmVwYXJpbmcgZm9yIGNhc2VzIG9mDQptdWx0aXBs ZSB3b3JraW5nIHBhdGhzIGZhaWxpbmcsIHRoZSBjb21taXRtZW50IG9mIHRoZSBzaGFyZWQNCnJl c291cmNlcyBhcmUgYmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0aGUgZGlmZmVyZW50IHdvcmtpbmcg cGF0aHMgaW4NCnRoZSBTTVAgbmV0d29yay4NCk5FVzoNCldoZW4gdGhlIHJlc2VydmVkIHJlc291 cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSB1dGlsaXplZCBieSBhDQpwYXJ0aWN1bGFy IHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50IHJlc291cmNlcw0K YXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rpb24gcGF0aC4gVGhpcyB0aGVuIGlt cGxpZXMgdGhhdA0KaWYgYW5vdGhlciB3b3JraW5nIHBhdGggb2YgdGhlIFNNUCBkb21haW4gdHJp Z2dlcnMgYSBwcm90ZWN0aW9uDQpzd2l0Y2gsIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29y ZGluYXRpb24gbWF5IGZhaWwuIFRoZSBkaWZmZXJlbnQgd29ya2luZyBwYXRocyBpbg0KdGhlIFNN UCBuZXR3b3JrIGFyZSBpbnZvbHZlZCBpbiB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRp bmF0aW9uLiAgDQoNCg0KVGhpcyBpcyBmaW5lLCBidXQgSSB3b25kZXIgd2h5IHlvdSBhcmUgdXNp bmcgInJlc291cmNlIHV0aWxpemF0aW9uIiB2cyAicHJvdGVjdGlvbiBzd2l0Y2giPyAodGhpcyBp cyBhY3R1YWxseSBhIGJpdCBvZiBhIGdlbmVyYWwgY29tbWVudCAtLSBJIHRoZSBsYXR0ZXIgaXMg YW4gZXhpc3RpbmcgYXBwbGljYWJsZSB0ZXJtIHRoYXQgd291bGQgaGVscCByZWFkZXJzIGhvdyB0 aGlzIGRvY3VtZW50IGZpdHMgaW4gdG8gdGhlIHRlY2hub2xvZ3kgc3BhY2UuKQ0KDQpbSlJdIEFz IGRlc2NyaWJlZCBpbiBhbiBlYXJsaWVyIHBhcnQgb2YgdGhpcyBzZWN0aW9uLCBTTVAgcHJvdGVj dGlvbiBjb25zaXN0cyBvZiB0d28gb3BlcmF0aW9uczogdHJhZmZpYyBzd2l0Y2hvdmVyIGFuZCBy ZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24uIFRoZSBzZW50ZW5jZXMgYXJlIGFib3V0 IHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24sIGFuZCDigJxyZXNvdXJjZSB1 dGlsaXphdGlvbuKAnSBzZWVtcyB0byBiZSBtb3JlIGFjY3VyYXRlLiANCg0KDQotIEdlbmVyYWwg Y29tbWVudDogZmF0ZS1zaGFyaW5nIGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCnBy b3RlY3Rpb246IEhvdyBpcyBjby1yb3V0aW5nIHByZXNlcnZlZCBmb3IgdGhlIHJldmVyc2UgcGF0 aCBpbiBTTVA/DQpJJ2QgYXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2ggY29vcmRpbmF0aW9u IHByb3RvY29sIHdvdWxkIGJlDQpyZXF1aXJlZCB0byB0cmlnZ2VyIGEgc3dpdGNob3ZlciBvZiB0 aGUgcmV2ZXJzZSBMU1AgaW4gdGhlIGNvLXJvdXRlZA0KY2FzZSwgYnV0IGRvbid0IHNlZSB0aGlz IGluIHRoZSBkb2N1bWVudC4NCltBdXRob3JzXSBGYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVk IGJ5IHRoaXMgZG9jdW1lbnQuIEV2ZW4gaW4gdGhlIFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBzd2l0 Y2hpbmcsIHN1Y2ggYXMgUkZDIDYzNzggKFBTQykgYW5kIFJGQyA3MjcxIChQU0MgaW4gQVBTIG1v ZGUpLCBmYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVkIGFzIHVuaWRpcmVjdGlvbmFsIHN3aXRj aGluZyBpcyBhbGxvd2VkLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGltcG9zZSBhbnkgcmVzdHJp Y3Rpb24gb24gY28tcm91dGluZywgZWl0aGVyLiANCiAgDQoNCkJvdGggUkZDNDQyNyBhbmQgNjM3 MiBtZW50aW9uIHRoaXMgKEJpLWRpcmVjdGlvbmFsIHJlY292ZXJ5IHN3aXRjaGluZyBpbiB0aGUg Zm9ybWVyKS4gSSB0aGluayB0aGlzIGRvY3VtZW50IHJlYWxseSBuZWVkcyB0byBtZW50aW9uIHNv bWV0aGluZyBvbiB0aGUgdG9waWMuICBHaXZlbiB0aGUgNjM3MiBhICJNQVkiIGxldmVsIHJlcXVp cmVtZW50IGlzIHByb2JhYmx5IHN1ZmZpY2llbnQsIGJ1dCB0aGlzIHNob3VsZCBiZSBjb25maXJt ZWQgd2l0aCB0aGUgV0cuICAoSSBwZXJzb25hbGx5IHdvdWxkIGxpa2UgU0hPVUxEIGFzIHRoaXMg c2VlbXMgdG8gYmV0dGVyIG1hdGNoIDYzNzIncyB0ZXh0ICJvcGVyYXRvciBvZnRlbiByZXF1aXJl cy4uLiIuKQ0KDQpbSlJdIE8uSy4gSSBndWVzcyB0aGF0IG1hbmRhdGluZyBiaWRpcmVjdGlvbmFs IHN3aXRjaGluZyBkb2VzIG5vdCBtZWFuIHRoYXQgdW5pZGlyZWN0aW9uYWwgc3dpdGNoaW5nIGlz IHByb2hpYml0ZWQuIFdoYXQgd2UgY2FuIGRvIGlzIHRoYXQsIGFmdGVyIGNoYW5naW5nIHRoZSB0 aXRsZSBvZiBTZWN0aW9uIDUuNC4gZnJvbSDigJxSZXZlcnRpdmUgcHJvdGVjdGlvbiBzd2l0Y2hp bmfigJ0gdG8g4oCcUmV2ZXJzaW9uIGFuZCBGYXRlLXNoYXJpbmfigJ0sIG9uZSBwYXJhZ3JhcGgg d2l0aCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHdpbGwgYmUgYWRkZWQ6IOKAnEJpZGlyZWN0aW9u YWwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgU0hPVUxEIGJlIHN1cHBvcnRlZCBpbiBTTVAu4oCdICAg ICANCg0KDQotIEluIHNlY3Rpb24gNCBhbmQgNS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIw OSBhcyBkZWZpbmluZw0KcHJlZW1wdGlvbiB0ZXJtaW5vbG9neSBhbmQgYmVoYXZpb3IuIEkgdGhp bmsgNjM3MiBpcyB0aGUgcmlnaHQNCnJlZmVyZW5jZSBoZXJlIGFzIGl0IGRlZmluZXMgYm90aCBp biB0aGUgY29udGV4dCBvZiBzdXJ2aXZhYmlsaXR5IGFuZA0KaW4gZGVwZW5kZW50IG9mIGNvbnRy b2wgcGxhbmUuDQpbQXV0aG9yc10gT25lIGNvbmNlcm4gaXMgdGhhdCBSRkMgNjM3MiBkZXNjcmli ZXMgYm90aCBzb2Z0IGFuZCBoYXJkIHByZWVtcHRpb25zIGluIHRoZSBjb250ZXh0IG9mIGV4dHJh IHRyYWZmaWMsIHdoaWNoIGlzIG5vdCBleGFjdGx5IHRoZSBjYXNlIGZvciBTTVAuDQoNClRoZW4g NjM3MiBzaG91bGQgYmUgcmVmZXJlbmNlZCBhbmQgdGhlIGRpZmZlcmVuY2Ugc2hvdWxkIGJlIGRl c2NyaWJlZC4gIE90aGVyd2lzZSByZWFkZXJzIGFyZSBsaWtlbHkgdG8gdGhpbmsgeW91IGp1c3Qg dXNlZCB0aGUgd3JvbmcgcmVmZXJlbmNlIGFuZCB0aGF0IDYzNzIncyB0ZXh0IGFwcGxpZXMuICA2 MzcyIGlzIGFmdGVyIGFsbCB0aXRsZWQgIk1QTFMtVFAgU3Vydml2YWJpbGl0eSBGcmFtZXdvcmsi Li4uDQoNCltKUl0gTy5LLiA2MzcyIHdpbGwgYmUgcmVmZXJlbmNlZCBhbmQgd2UgY2FuIGFkZCB0 aGUgZm9sbG93aW5nIHNlbnRlbmNlIGFzIHRoZSB0aGlyZCBzZW50ZW5jZSBpbiB0aGUgcGFyYWdy YXBoOiDigJxUaGUgdHJhZmZpYyBvZiBsb3dlciBwcmlvcml0eSBwYXRocyBpbiB0aGlzIGRvY3Vt ZW50IGNhbiBiZSB2aWV3ZWQgYXMgdGhlIGV4dHJhIHRyYWZmaWMgYmVpbmcgcHJlZW1wdGVkIGlu IFtSRkM2MzcyXS7igJ0gIA0KDQoNCi0gU2VjdGlvbiA0LjEuIFlvdSBzYXkgInR3byBvcGVyYXRp b25zIHNpbXVsdGFuZW91c2x5Ii4gRG8geW91IHJlYWxseQ0KbWVhbiAic2ltdWx0YW5lb3VzbHki IG9yIG1lcmVseSB0aGF0IHRoZXkgbXVzdCBib3RoIG9jY3VyIGZvcg0KcHJvdGVjdGlvbiB0byBi ZSBwcm92aWRlZD8gKFNhbWUgY29tbWVudCBpbiBzZWN0aW9uIDUuMS4NCltBdXRob3JzXSBCb3Ro IGFjdGlvbnMgc2hvdWxkIG9jY3VyIGF0IHRoZSBzYW1lIHRpbWUsIG9yIGFzIGNsb3NlbHkgYXMg cG9zc2libGUgdG8gcHJvdmlkZSBmYXN0IHByb3RlY3Rpb24uIA0KICANCldoYXQgdGV4dCBjaGFu Z2UgaXMgcGxhbm5lZD8gDQoNCltKUl0gV2UgY2FuIGVyYXNlIOKAnHNpbXVsdGFuZW91c2x54oCd IGFuZCBhZGQgdGhlIHNlbnRlbmNlICjigJxCb3RoIG9wZXJhdGlvbnMgc2hvdWxkIG9jY3VyIGF0 IHRoZSBzYW1lIHRpbWUsIG9yIGFzIGNsb3NlbHkgYXMgcG9zc2libGUgdG8gcHJvdmlkZSBmYXN0 IHByb3RlY3Rpb24u4oCdKSBhcyB0aGUgc2Vjb25kIHNlbnRlbmNlIG9mIHRoZSBwYXJhZ3JhcGgu DQoNCg0KDQotIFNlY3Rpb24gNS4yOiBGaXJzdCBwYXJhZ3JhcGggYW5kIGZvcnRoIGJ1bGxldCBs YXN0IHNlbnRlbmNlLiBUaGVzZQ0KYm90aCBiYXNpY2FsbHkgY292ZXIgdGhlIHNhbWUgdG9waWMg KHByZWVtcHRpb24pIGFuZCBhY3R1YWxseSBzYXkNCnNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3Mu IEkgc3VnZ2VzdCBjb21iaW5lIGludG8gYSBzaW5nbGUNCnJlcXVpcmVtZW50IHRvIGVuc3VyZSBj b25zaXN0ZW5jeSBhbmQgZnVsbCBjb3ZlcmFnZSBvZiB0aGUgdG9waWMuDQpbQXV0aG9yc10gVGhl IGZpcnN0IHBhcmFncmFwaCBpcyBmb3Igc29mdC1wcmVlbXB0aW9uLCB3aGlsZSB0aGUgZm91cnRo IGJ1bGxldCBiZWxvbmdzIHRvIHRoZSByZXF1aXJlbWVudHMgb2YgaGFyZC1wcmVlbXB0aW9uLg0K DQpEbyB5b3UgcGxhbiBhIHRleHQgY2hhbmdlPyAgKHRoZSAxc3QgcGFyYWdyYXBoIHNob3VsZCBi ZSBhIGxpc3QgaXRlbSBhbmQgc29mdC1wcmVlbXB0aW9uIGlzIG1lbnRpb25lZCBhcyBhIHBhcmVu dGhldGljYWwgLCBhbmQgdGhlIGZvcnRoIGRvZXNuJ3QgbWVudGlvbiBpdHMgc2NvcGUgYXMgaGFy ZCBwcmVlbXB0aW9uLikNCg0KW0pSXSBPSy4gV2UgY2FuIG1ha2UgdGhlbSBjbGVhci4gSG93IGFi b3V0IHRoZSBmb2xsb3dpbmcgYXJyYW5nZW1lbnQ/IA0KIA0KNS4yLiBNdWx0aXBsZSB0cmlnZ2Vy cw0KDQpJZiBtb3JlIHRoYW4gb25lIHdvcmtpbmcgcGF0aCBpcyB0cmlnZ2VyaW5nIGEgcHJvdGVj dGlvbiBzd2l0Y2ggc3VjaA0KdGhhdCBhIHByb3RlY3Rpb24gc2VnbWVudCBpcyBvdmVyc3Vic2Ny aWJlZCwgdGhlcmUgYXJlIHR3byBkaWZmZXJlbnQNCmFjdGlvbnMgdGhhdCB0aGUgU01QIG5ldHdv cmsgY2FuIGNob29zZSDigJMgc29mdCBwcmVlbXB0aW9uIGFuZCBoYXJkIA0KcHJlZW1wdGlvbi4N Cg0KNS4yLjEuIFNvZnQtcHJlZW1wdGlvbg0KDQpGb3IgbmV0d29ya3MgdGhhdCBzdXBwb3J0IG11 bHRpcGxleGluZyBwYWNrZXRzIG92ZXIgdGhlIHNoYXJlZCBzZWdtZW50cywgdGhlIHJlcXVpcmVt ZW50IGlzOg0KDQpPIEFsbCBvZiB0aGUgcHJvdGVjdGlvbiBwYXRocyBNQVkgYmUgYWxsb3dlZCB0 byBzaGFyZSB0aGUgcmVzb3VyY2VzDQpvZiB0aGUgc2hhcmVkIHNlZ21lbnRzDQoNCjUuMi4yIEhh cmQtcHJlZW1wdGlvbg0KDQpUaGVyZSBhcmUgbmV0d29ya3MgdGhhdCByZXF1aXJlIHRoZSBleGNs dXNpdmUgdXNlIG9mIHRoZSBwcm90ZWN0aW9uDQpyZXNvdXJjZXMgd2hlbiBhIHByb3RlY3Rpb24g c2VnbWVudCBpcyBvdmVyc3Vic2NyaWJlZC4gDQpUcmFmZmljIG9mIGxvd2VyIHByaW9yaXR5IHBh dGhzIGlzIGNvbXBsZXRlbHkgYmxvY2tlZC4NClRoZXNlIGluY2x1ZGUgbmV0d29ya3MgdGhhdCBz dXBwb3J0IHRoZSByZXF1aXJlbWVudHMgaW4gW1JGQzU2NTRdLCANCmFuZCBpbiBwYXJ0aWN1bGFy IHN1cHBvcnQgcmVxdWlyZW1lbnQgNTguIEZvciBzdWNoIG5ldHdvcmtzLCANCnRoZSBmb2xsb3dp bmcgcmVxdWlyZW1lbnRzIGFwcGx5Og0KDQpPIC4uLg0KDQpPIC4uLg0KDQoNCioqKioqDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuuztOuCuCDsgqzr now6IExvdSBCZXJnZXIgW2xiZXJnZXJAbGFibi5uZXRdDQrrs7Trgrgg64Kg7KecOiAyMDE064WE IDfsm5QgNuydvCDsnbzsmpTsnbwg7Jik7KCEIDEyOjI2DQrrsJvripQg7IKs656MOiDrpZjsoJXr j5k7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCuywuOyhsDogcnRnLWRpckBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnOyBtcGxzQGll dGYub3JnDQrsoJzrqqk6IFJlOiBbUlRHLURJUl0gW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0 LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KDQpKZW9uZy9BdXRob3JzLA0KICAg IFRoYW5rIHlvdSBmb3IgdGhlIHJlc3BvbnNlLiAgTW9zdCBvZiB0aGUgY2hhbmdlcyBsb29rIGdv b2QuICBJIHN0aWxsIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGFuZCBvcGVuIGNvbW1lbnRzLiAgUGxl YXNlIHNlZSBiZWxvdy4NCg0KTG91DQoNCk9uIDcvMy8yMDE0IDg6NTIgUE0sIEplb25nIFJ5b28g d3JvdGU6DQpEZWFyIExvdSwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHZhbHVhYmxlIGNvbW1l bnRzLg0KDQpUaGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0IGhhdmUgZGlzY3Vzc2VkIHlvdXIgY29t bWVudHMsIGFuZCBhcmUgcHJvcG9zaW5nIG91ciByZXNvbHV0aW9ucyB0byB5b3VyIGNvbW1lbnRz LiBQbGVhc2UsIGxldCB1cyBrbm93IGlmIHRoZSBwcm9wb3NhbCBpcyBhcHByb3ByaWF0ZSB0byBh ZGRyZXNzIHlvdXIgY29tbWVudHMgYW5kIGNvbmNlcm5zLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkF1 dGhvcnMgb2YgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMgZHJhZnQNCg0KKioqKioq IEJlZ2lubmluZyBvZiBDb21tZW50IFJlc29sdXRpb24gKioqKioqDQoNCi0gRG9jdW1lbnQncyB1 c2FnZSBvZiAiY29tbWl0dGVkIiB2cyAiYWxsb2NhdGVkIiByZXNvdXJjZXM6DQoNCkluIHNlY3Rp b24gMSB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgbm90aW9uIHRoYXQgdGhlDQpkaXN0aW5j dGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIGJhc2VkIG9uIHdoZW4N CnJlc291cmNlcyBhcmUgImNvbW1pdHRlZCIuIFRoaXMgZGlmZmVyZW5jZSBmcm9tIHBhc3QNCmRl ZmluaXRpb24uIFJGQzQ0MjcgYW5kIDYzNzIgbWFrZSB0aGUgZGlzdGluY3Rpb24gdGhhdCBwcm90 ZWN0aW9uDQphbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3VyY2VzIGFy ZSAqYWxsb2NhdGVkKiBub3QNCipjb21taXR0ZWQqLiBUbyBxdW90ZSBSRkMgNDQyNzoNCg0KDQou Li4NCg0KW0F1dGhvcnNdIEFmdGVyIHJldmlld2luZyBSRkNzIDQ0MjcsIDYzNzIsIDM5NDUsIDQ0 MjYsIGFuZCA0NDI4LCB3ZSBjb25jbHVkZWQgdGhhdCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBw cm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBzaG91bGQgYmUgYWxpZ25lZCB3aXRoIHRoZSBleGl0 aW5nIGRvY3VtZW50cyBub3JtYXRpdmVseSByZWZlcmVuY2VkIGJ5IHRoaXMgZG9jdW1lbnQuIEFj Y29yZGluZ2x5LCB0aGUgZm9sbG93aW5nIDE2IG1vZGlmaWNhdGlvbnMgd2lsbCBiZSBkb25lIGlu IHJldmlzaW9uOg0KLi4uIChkZWxldGVkIGNoYW5nZXMgbG9va2VkIGZpbmUuKQ0KDQoNCig0KSBQ YWdlIDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQpPTEQ6DQp0aGUgcmVzb3VyY2VzIGZvciB0aGUg cHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBjb21taXR0ZWQsDQpORVcNCnRoZSByZXNvdXJjZXMg Zm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGRlZGljYXRlZCwNCg0KRGVkaWNhdGVk IGlzIGFsc28gYW4gYW1iaWd1b3VzIHRlcm0sIGhvdyBhYm91dDoNCk9MRA0KICAgdGhlIHJlc291 cmNlcyBmb3IgdGhlIHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkgY29tbWl0dGVkLCB0aGUNCiAg IHByb3RlY3Rpb24gcGF0aCBpbiB0aGUgY2FzZSBvZiBTTVAgY29uc2lzdHMgb2Ygc2VnbWVudHMg dGhhdCBhcmUNCiAgIGRlZGljYXRlZCB0byB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgcmVsYXRlZCB3 b3JraW5nIHBhdGggYW5kIGFsc28NCk5FVw0KICAgdGhlIHJlc291cmNlcyBmb3IgdGhlIHByb3Rl Y3Rpb24gcGF0aCBhcmUgZnVsbHkgYWxsb2NhdGVkLCB0aGUNCiAgIHByb3RlY3Rpb24gcGF0aCBp biB0aGUgY2FzZSBvZiBTTVAgY29uc2lzdHMgb2Ygc2VnbWVudHMgdGhhdCBhcmUNCiAgIGFsbG9j YXRlZCB0byB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgcmVsYXRlZCB3b3JraW5nIHBhdGggYW5kIGFs c28NCg0KDQpPTEQ6DQpyZXNvdXJjZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdvdWxkIG5vdCBiZSBj b21taXR0ZWQgdW50aWwg4oCmDQpORVc6DQpyZXNvdXJjZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdv dWxkIG5vdCBiZSB1dGlsaXplZCB1bnRpbCDigKYNCkhvdyBhYm91dDoNCk9MRA0KICAgcmVzb3Vy Y2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBub3QgYmUgY29tbWl0dGVkIHVudGlsIHJlcXVl c3RlZA0KTkVXDQoNCiAgIHJlc291cmNlcyBtYXkgYmUgYWxsb2NhdGVkIGJ1dCB3b3VsZCBub3Qg YmUgdXRpbGl6ZWQgdW50aWwgcmVxdWVzdGVkDQoNCi4uLg0KDQooNykgVGhlIHNlY29uZCBwYXJh Z3JhcGggb2YgU2VjdGlvbiA0LjE6DQpPTEQ6DQpXaGVuIHRoZSByZXNlcnZlZCByZXNvdXJjZXMg b2YgdGhlIHNoYXJlZCBzZWdtZW50cyBhcmUgY29tbWl0dGVkIHRvIGENCnBhcnRpY3VsYXIgcHJv dGVjdGlvbiBwYXRoLCB0aGVyZSBtYXkgbm90IGJlIHN1ZmZpY2llbnQgcmVzb3VyY2VzDQphdmFp bGFibGUgZm9yIGFuIGFkZGl0aW9uYWwgcHJvdGVjdGlvbiBwYXRoLiBUaGlzIHRoZW4gaW1wbGll cyB0aGF0DQppZiBhbm90aGVyIHdvcmtpbmcgcGF0aCBvZiB0aGUgU01QIGRvbWFpbiB0cmlnZ2Vy cyBhIHByb3RlY3Rpb24NCnN3aXRjaCwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcyBt YXkgZmFpbC4gSW4gb3JkZXIgdG8NCm9wdGltaXplIHRoZSBvcGVyYXRpb24gb2YgdGhlIGNvbW1p dG1lbnQgYW5kIHByZXBhcmluZyBmb3IgY2FzZXMgb2YNCm11bHRpcGxlIHdvcmtpbmcgcGF0aHMg ZmFpbGluZywgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHNoYXJlZA0KcmVzb3VyY2VzIGFyZSBiZSBj b29yZGluYXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZyBwYXRocyBpbg0KdGhlIFNN UCBuZXR3b3JrLg0KTkVXOg0KV2hlbiB0aGUgcmVzZXJ2ZWQgcmVzb3VyY2VzIG9mIHRoZSBzaGFy ZWQgc2VnbWVudHMgYXJlIHV0aWxpemVkIGJ5IGENCnBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRo LCB0aGVyZSBtYXkgbm90IGJlIHN1ZmZpY2llbnQgcmVzb3VyY2VzDQphdmFpbGFibGUgZm9yIGFu IGFkZGl0aW9uYWwgcHJvdGVjdGlvbiBwYXRoLiBUaGlzIHRoZW4gaW1wbGllcyB0aGF0DQppZiBh bm90aGVyIHdvcmtpbmcgcGF0aCBvZiB0aGUgU01QIGRvbWFpbiB0cmlnZ2VycyBhIHByb3RlY3Rp b24NCnN3aXRjaCwgdGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiBtYXkgZmFp bC4gVGhlIGRpZmZlcmVudCB3b3JraW5nIHBhdGhzIGluDQp0aGUgU01QIG5ldHdvcmsgYXJlIGlu dm9sdmVkIGluIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24uDQouDQoNClRo aXMgaXMgZmluZSwgYnV0IEkgd29uZGVyIHdoeSB5b3UgYXJlIHVzaW5nICJyZXNvdXJjZSB1dGls aXphdGlvbiIgdnMgInByb3RlY3Rpb24gc3dpdGNoIj8gKHRoaXMgaXMgYWN0dWFsbHkgYSBiaXQg b2YgYSBnZW5lcmFsIGNvbW1lbnQgLS0gSSB0aGUgbGF0dGVyIGlzIGFuIGV4aXN0aW5nIGFwcGxp Y2FibGUgdGVybSB0aGF0IHdvdWxkIGhlbHAgcmVhZGVycyBob3cgdGhpcyBkb2N1bWVudCBmaXRz IGluIHRvIHRoZSB0ZWNobm9sb2d5IHNwYWNlLikNCg0KLi4uDQoNCg0KKDEyKSBTZWN0aW9uIDUu MiwgdGhlIHRoaXJkIGJ1bGxldCBpdGVtOg0KT0xEOg0KSWYgbXVsdGlwbGUgcHJvdGVjdGlvbiBw YXRocyBvZiBlcXVhbCBwcmlvcml0eSBhcmUgcmVxdWVzdGluZw0KYWxsb2NhdGlvbiBvZiB0aGUg c2hhcmVkIHJlc291cmNlcywgdGhlIHJlc291cmNlcyBTSE9VTEQgYmUNCmNvbW1pdHRlZCBvbiBh IGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzLg0KTkVXOg0KSWYgbXVsdGlwbGUgcHJvdGVj dGlvbiBwYXRocyBvZiBlcXVhbCBwcmlvcml0eSBhcmUgcmVxdWVzdGluZw0KdGhlIHNoYXJlZCBy ZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxEIGJlDQphc3NpZ25lZCBvbiBhIGZpcnN0IGNv bWUgZmlyc3Qgc2VydmVkIGJhc2lzLg0KDQp3aHkgdXNlIGEgbmV3IHRlcm0gImFzc2lnbmVkIiB2 cyB0aGUgcHJldmlvdXMgdGVybSAidXRpbGl6ZWQiPyAgSWYgdGhlcmUgaXMgbm8gZGlzdGluY3Rp b24gYmVpbmcgbWFkZSB0aGUgc2FtZSB0ZXJtIHNob3VsZCBiZSB1c2VkIChlaXRoZXIgdGVybSBp cyBmaW5lLCBidXQgY2hvb3NlIG9uZSkuIElmIHRoZXJlIGlzIGEgZGlzdGluY3Rpb24sIGl0IHNo b3VsZCBiZSBtYWRlIGV4cGxpY2l0IChpLmUuLCBleHBsYWluZWQpLg0KDQoNCigxMykgU2VjdGlv biA1LjIsIHRoZSBmb3VydGggYnVsbGV0IGl0ZW06DQpPTEQ6DQpJZiB0aGUgcHJvdGVjdGlvbiBy ZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCB0byBhIHByb3RlY3Rpb24gcGF0aCwNCndob3NlIHdvcmtp bmcgcGF0aCBoYXMgYSBsb3dlciBwcmlvcml0eSwgcmVzb3VyY2VzIHJlcXVpcmVkIGZvcg0KdGhl IGhpZ2hlciBwcmlvcml0eSBwYXRoIFNIQUxMIGJlIGNvbW1pdHRlZCB0byB0aGUgaGlnaGVyIHBy aW9yaXR5DQpwYXRoLg0KTkVXOg0KSWYgdGhlIHByb3RlY3Rpb24gcmVzb3VyY2VzIGFyZSB1dGls aXplZCBieSBhIHByb3RlY3Rpb24gcGF0aCwNCndob3NlIHdvcmtpbmcgcGF0aCBoYXMgYSBsb3dl ciBwcmlvcml0eSwgcmVzb3VyY2VzIHJlcXVpcmVkIGZvcg0KdGhlIGhpZ2hlciBwcmlvcml0eSBw YXRoIFNIQUxMIGJlIGFzc2lnbmVkIHRvIHRoZSBoaWdoZXIgcHJpb3JpdHkNCnBhdGguDQoNCg0K c2FtZSBjb21tZW50Lg0KDQouLi4NCg0KDQotIFNlY3Rpb24gMiwgMXN0IHBhcmFncmFwaCwgbGFz dCBzZW50ZW5jZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkgZGVmaW5lcw0KdGhlIHNjb3BlL3B1cnBv c2Ugb2YgdGhlIGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlvbnMNCnRv IHByb3RvY29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0aGUN CnJlcXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNoLCBJJ2QgcmVw ZWF0IHRoaXMgaW4NCnRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJvbm91bmNl ZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yDQozKS4NCg0KW0F1dGhvcnNdIFdlIGNhbiBhZGQgdGhl IGZvbGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDE6DQrigJxUaGlzIGRv Y3VtZW50IGlzIGludGVuZGVkIHRvIGNsYXJpZnkgdGhlIGluc3RydWN0aW9ucyB0byBwcm90b2Nv bCBkZXNpZ25lcnMgcHJvZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhlIHJlcXVpcmVt ZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQu4oCdDQoNCg0KDQpIb3cgYWJvdXQgYmVpbmcg ZXZlbiBtb3JlIGV4cGxpY2l0IChpbiBib3RoIHRoZSBhYnN0cmFjdCBhbmQgc2VjdGlvbiAxKToN CiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgcmVxdWlyZW1lbnRzICBmb3IgIGFueQ0KICAgbWVj aGFuaXNtIHRoYXQgd291bGQgYmUgdXNlZCB0byBpbXBsZW1lbnQgU01QIGZvciBNUExTLVRQIGRh dGEgcGF0aHMsDQogICBpbiBuZXR3b3JrcyB0aGF0IGRlbGVnYXRlIHByb3RlY3Rpb24gc3dpdGNo IGNvb3JkaW5hdGlvbiB0byB0aGUgZGF0YQ0KICAgcGxhbmUuDQoNCi0gR2VuZXJhbCBjb21tZW50 OiBmYXRlLXNoYXJpbmcgZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUA0KcHJvdGVjdGlv bjogSG93IGlzIGNvLXJvdXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNN UD8NCkknZCBhc3N1bWVkIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCBjb29yZGluYXRpb24gcHJvdG9j b2wgd291bGQgYmUNCnJlcXVpcmVkIHRvIHRyaWdnZXIgYSBzd2l0Y2hvdmVyIG9mIHRoZSByZXZl cnNlIExTUCBpbiB0aGUgY28tcm91dGVkDQpjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhl IGRvY3VtZW50Lg0KDQpbQXV0aG9yc10gRmF0ZS1zaGFyaW5nIGlzIG5vdCByZXF1aXJlZCBieSB0 aGlzIGRvY3VtZW50LiBFdmVuIGluIHRoZSBQU0MgbGluZWFyIHByb3RlY3Rpb24gc3dpdGNoaW5n LCBzdWNoIGFzIFJGQyA2Mzc4IChQU0MpIGFuZCBSRkMgNzI3MSAoUFNDIGluIEFQUyBtb2RlKSwg ZmF0ZS1zaGFyaW5nIGlzIG5vdCByZXF1aXJlZCBhcyB1bmlkaXJlY3Rpb25hbCBzd2l0Y2hpbmcg aXMgYWxsb3dlZC4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbXBvc2UgYW55IHJlc3RyaWN0aW9u IG9uIGNvLXJvdXRpbmcsIGVpdGhlci4NCg0KDQpCb3RoIFJGQzQ0MjcgYW5kIDYzNzIgbWVudGlv biB0aGlzIChCaS1kaXJlY3Rpb25hbCByZWNvdmVyeSBzd2l0Y2hpbmcgaW4gdGhlIGZvcm1lciku IEkgdGhpbmsgdGhpcyBkb2N1bWVudCByZWFsbHkgbmVlZHMgdG8gbWVudGlvbiBzb21ldGhpbmcg b24gdGhlIHRvcGljLiAgR2l2ZW4gdGhlIDYzNzIgYSAiTUFZIiBsZXZlbCByZXF1aXJlbWVudCBp cyBwcm9iYWJseSBzdWZmaWNpZW50LCBidXQgdGhpcyBzaG91bGQgYmUgY29uZmlybWVkIHdpdGgg dGhlIFdHLiAgKEkgcGVyc29uYWxseSB3b3VsZCBsaWtlIFNIT1VMRCBhcyB0aGlzIHNlZW1zIHRv IGJldHRlciBtYXRjaCA2MzcyJ3MgdGV4dCAib3BlcmF0b3Igb2Z0ZW4gcmVxdWlyZXMuLi4iLikN Cg0KDQotIEluIHNlY3Rpb24gNCBhbmQgNS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBh cyBkZWZpbmluZw0KcHJlZW1wdGlvbiB0ZXJtaW5vbG9neSBhbmQgYmVoYXZpb3IuIEkgdGhpbmsg NjM3MiBpcyB0aGUgcmlnaHQNCnJlZmVyZW5jZSBoZXJlIGFzIGl0IGRlZmluZXMgYm90aCBpbiB0 aGUgY29udGV4dCBvZiBzdXJ2aXZhYmlsaXR5IGFuZA0KaW4gZGVwZW5kZW50IG9mIGNvbnRyb2wg cGxhbmUuDQoNCltBdXRob3JzXSBPbmUgY29uY2VybiBpcyB0aGF0IFJGQyA2MzcyIGRlc2NyaWJl cyBib3RoIHNvZnQgYW5kIGhhcmQgcHJlZW1wdGlvbnMgaW4gdGhlIGNvbnRleHQgb2YgZXh0cmEg dHJhZmZpYywgd2hpY2ggaXMgbm90IGV4YWN0bHkgdGhlIGNhc2UgZm9yIFNNUC4NCg0KVGhlbiA2 MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkIGFuZCB0aGUgZGlmZmVyZW5jZSBzaG91bGQgYmUgZGVz Y3JpYmVkLiAgT3RoZXJ3aXNlIHJlYWRlcnMgYXJlIGxpa2VseSB0byB0aGluayB5b3UganVzdCB1 c2VkIHRoZSB3cm9uZyByZWZlcmVuY2UgYW5kIHRoYXQgNjM3MidzIHRleHQgYXBwbGllcy4gIDYz NzIgaXMgYWZ0ZXIgYWxsIHRpdGxlZCAiTVBMUy1UUCBTdXJ2aXZhYmlsaXR5IEZyYW1ld29yayIu Li4NCg0KDQoNCi0gSW4gc2VjdGlvbiA0LjIgeW91IHNheSAiVGhlcmVmb3JlLCBpdCBpcyBzdWdn ZXN0ZWQgdGhhdCB0aGlzIGJlDQpjYXJyaWVkIG91dCB1bmRlciB0aGUgY29udHJvbCBvZiBhIGR5 bmFtaWMgY29udHJvbCBwbGFuZSBzaW1pbGFyIHRvDQpHTVBMUyBbUkZDMzk0NV0uIiBwZXJoYXBz IHlvdSBtZWFuICJiYXNlZCBvbiBHTVBMUyI/IElmIHNvLCBncmVhdCwNCnBsZWFzZSBtYWtlIHRo ZSBjb3JyZWN0aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBvZiB3aGljaA0KY29udHJv bCBwcm90b2NvbCBpcyB1c2VkIGZvciBNUExTLVRQIGlzIHdheSBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMNCmRvY3VtZW50Lg0KDQpbQXV0aG9yc10gWWVzLCB3ZSB3aWxsIG1ha2UgdGhlIGNvcnJl Y3Rpb24uDQpva2F5DQoNCg0KLSBTZWN0aW9uIDUuMSwgcGFyYWdyYXBoIDEuIFdoeSBhcmUgeW91 IHVzaW5nICJTSE9VTEQgTk9UIiBoZXJlPyBJZg0KcmVmZXJyaW5nIHRvIHNvbHV0aW9ucyBjb25m b3JtYW50IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGVzZSBhcmUNCmluZm9ybWF0aXZlIHN0 YXRlbWVudHMsICJhbmQgYSBub24tY29udHJvbCBwbGFuZSBiYXNlZCBTTVAgc3dpdGNob3Zlcg0K bWVjaGFuaXNtIGlzIHVzZWQsIHRoZSBjb250cm9sIHBsYW5lIFNIQUxMIE5PVCAuLi4iLiBJZiBy ZWZlcnJpbmcgdG8NCmFuIG9wZXJhdG9yJ3MvdXNlcidzIGNob2ljZSBvZiBwcm90ZWN0aW9uIG1l Y2hhbmlzbSwgSSB0aGluayB0aGUgbW9zdA0KeW91IGNhbiBzYXkgaXMgTUFZLg0KDQpbQXV0aG9y c10gVGhlIGZpcnN0IGNhc2UgaXMgdGhlIG9uZSB3ZSBhcmUgYWltaW5nIGF0LiBXZSB3aWxsIHVz ZSBTSEFMTCBOT1QuDQoNCg0Kb2theS4NCi0gU2VjdGlvbiA1LjIuICJUaWUtYnJlYWtpbmcgcnVs ZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVANCmRvbWFpbi4iIEFzIHRoaXMg aXMgYSByZXF1aXJlbWVudCwgd2hhdCB5b3UgbWVhbiBieSAidGllLWJyZWFraW5nDQpydWxlcyIg c2hvdWxkIGJlIGRlZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNlLg0KDQpbQXV0aG9yc10g VGhlIHNlbnRlbmNlIGNhbiBiZSByZXdyaXR0ZW4gYXM6DQpPTEQ6DQpUaWUtYnJlYWtpbmcgcnVs ZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9tYWluLg0KTkVXOg0KSW4g b3JkZXIgdG8gY292ZXIgdGhlIHNpdHVhdGlvbiB3aGVyZSB0aGUgZmlyc3QgY29tZSBmaXJzdCBz ZXJ2ZWQgcHJpbmNpcGxlIGNhbm5vdCByZXNvbHZlIHRoZSBjb250ZW50aW9uIGFtb25nIG11bHRp cGxlIGVxdWFsIHByaW9yaXR5IHJlcXVlc3RzLCBpLmUuLCB3aGVuIHRoZSByZXF1ZXN0cyBvY2N1 ciBzaW11bHRhbmVvdXNseSwsIHRpZS1icmVha2luZyBydWxlcyBTSEFMTCBiZSBkZWZpbmVkIGlu IHNjb3BlIG9mIGFuIFNNUCBkb21haW4uDQoNCg0KDQpnb29kIGVub3VnaCAoaS5lLiwgc3RhdGVz IHRoYXQgdGhlIGRlZmluaXRpb24gb2YgdGllLWJyZWFraW5nIGlzIEZGUy4pDQoNCg0KLSBTZWN0 aW9uIDUuMy4gUkZDNjM3MiB0YWtlcyBhbiBhcHByb2FjaCB3aGVyZSBwcmVlbXB0aW9uIG5vdGlm aWNhdGlvbg0KbGV2ZXJhZ2VzIHRoZSBzdGFuZGFyZCBNUExTLVRQIE9BTSBtZWNoYW5pc21zLCBp cyB0aGVyZSBhbnkgcmVhc29uIHRvDQpkbyBtb3JlIC8gbm90IGp1c3QgZm9sbG93IDYzNzI/DQoN CltBdXRob3JzXSBXZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgYXQgdGhlIGVuZDoN CuKAnEFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3Ml0sIHRoZSBldmVudCBvZiBwcmVlbXB0aW9uIG1h eSBiZSBkZXRlY3RlZCBieSBPQU0gYW5kIHJlcG9ydGVkIGFzIGEgZmF1bHQgb3IgYSBkZWdyYWRh dGlvbiBvZiB0cmFmZmljIGRlbGl2ZXJ5LuKAnQ0KDQpva2F5Lg0KDQotIFNlY3Rpb24gNS43LiBU aGVyZSBtYXkgYmUgY29vcmRpbmF0aW9uIHJlcXVpcmVkIG9uIHNvZnQtcHJlZW1wdGlvbiBhcw0K d2VsbCAoZGVwZW5kaW5nIG9uIHRoZSBjcm9zcy1jb25uZWN0cyBlc3RhYmxpc2hlZCBkdXJpbmcg TFNQDQplc3RhYmxpc2htZW50KSBzbyBjb29yZGluYXRlZCBzd2l0Y2hpbmcgc2hvdWxkIGJlIHN1 cHBvcnRlZA0KaW5kZXBlbmRlbnQgb2YgcHJlZW1wdGlvbiBtb2RlLg0KDQpbQXV0aG9yc10gWWVz LCB3ZSB3aWxsIGNoYW5nZSB0aGUgc2Vjb25kIHBhcmFncmFwaCBmcm9tIOKAnFNNUCBpbiBoYXJk LXByZWVtcHRpb24gbW9kZSBTSE9VTEQg4oCm4oCdIHRvIOKAnFNNUCBTSE9VTEQg4oCm4oCdIGFu ZCBtb3ZlIHRoZSBjaGFuZ2VkIHBhcmFncmFwaCBhYm92ZSB0aGUgZmlyc3QgcGFyYWdyYXBoLg0K DQoNCk5pdHM6DQoNCi0gQWJzdHJhY3Q6IEkgZG9uJ3QgcmVjYWxsIHRoZSB0ZXJtICJleGVjdXRp dmUgYWN0aW9uIiBiZWluZyB1c2VkIGluIGFueQ0KZWFybGllciByZWxhdGVkL3JlZmVyZW5jZWQg UkZDcy4gUmF0aGVyIHRoYW4gaW50cm9kdWNlIGEgbmV3IChhbmQNCnVuZGVmaW5lZCkgdGVybSwg cGVyaGFwcyB5b3UgY2FuIHVzZSBhbiBleGlzdGluZyBvbmUsIGUuZy4sDQoicHJvdGVjdGlvbiBz d2l0Y2giPw0KDQpbQXV0aG9yc10gWWVzLCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQgYXMgeW91 IHN1Z2dlc3RlZC4NCg0KDQpncmVhdC4NCi0gU2VjdGlvbiAxLCBwYXJhZ3JhcGggMS4gRG8gd2Ug cmVhbGx5IG5lZWQgYW5vdGhlciBkZWZpbml0aW9uIG9mDQpNUExTLVRQIHRvIGRlYmF0ZT8gSSBz dWdnZXN0IGp1c3QgcmVmZXJlbmNpbmcgeW91ciBmYXZvcml0ZSBNUExTLVRQDQpkb2N1bWVudChz KSBhbmQgZHJvcHBpbmcgdGhlIGZpcnN0IGZvdXIgc2VudGVuY2VzLg0KDQpUaGUgbGFzdCBzZW50 ZW5jZSBhbHNvIG1ha2VzIGEgc3ViamVjdGl2ZSBzdGF0ZW1lbnQuIFdoZXRoZXIgaXQgaXMNCmNy aXRpY2FsIG9yIG5vIGlzIHVubmVjZXNzYXJ5LiBZb3UgY2FuIGp1c3Qgc2F5IHNvbWV0aGluZyBs aWtlIDYzNzINCnByb3ZpZGVzIGEgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgZm9yIE1QTFMtVFAg YW5kIGlzIHRoZSBmb3VuZGF0aW9uDQpmb3IgdGhpcyBkb2N1bWVudC4NCg0KW0F1dGhvcnNdIFRo ZSBwcm9wb3NlZCB0ZXh0IGZvciB0aGUgcGFyYWdyYXBoIDEgaXM6DQrigJxUaGUgTVBMUyBUcmFu c3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgaXMgZGVzY3JpYmVkIGluIFtSRkM1OTIxXSwNCmFuZCBb UkZDNjM3Ml0gcHJvdmlkZXMgYSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1UUA0K YW5kIGlzIHRoZSBmb3VuZGF0aW9uIGZvciB0aGlzIGRvY3VtZW50LuKAnQ0KDQpva2F5Lg0KDQot IFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElzbid0IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBu b3QgNDQyOD8NCkFsc28gZHJvcCB0aGUgd29yZCBsaW5lYXIsIGFzIGl0IGlzIGFuIHVubmVjZXNz YXJ5IHF1YWxpZmllciBhbmQNCjQ0MjcvNDQyOCBkb24ndCB1c2UgaXQuDQoNCltBdXRob3JzXSBP Sy4NCg0KDQoNCi0gU2VjdGlvbnMgMyAoYW5kIHRvIGEgbGVzc2VyIGRlZ3JlZSBzZWN0aW9uIDIp IGFyZSByZWFsbHkgaW50cm9kdWN0b3J5DQp0ZXh0LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0aGV5 IGFyZW4ndCBwYXJ0IG9mIHNlY3Rpb24gMS4NCg0KW0F1dGhvcnNdIFNlY3Rpb24gMyB3YXMgaW50 ZW5kZWQgdG8gcHJlc2VudCBhIHJlZmVyZW5jZSBtb2RlbCBmb3IgU01QLiBTb21lIHRleHQgb2Yg U2VjdGlvbiAyIGlzIHJlcGVhdGVkIGluIFNlY3Rpb24gMSBhcyB5b3Ugc3VnZ2VzdGVkIGVhcmxp ZXIuDQoNCldlJ3JlIGluIHRoZSBkb21haW4gb2Ygc3R5bGUsIHNvIGlzIHlvdXIgY2FsbC4NCg0K DQotIFNlY3Rpb24gMy4yIHNob3VsZCBoYXZlIGEgcmVmZXJlbmNlIGZvciAiZXhpc3RpbmcgY29u dHJvbCBwbGFuZQ0Kc29sdXRpb25zIGZvciBTTVAgd2l0aGluIE1QTFMiLg0KDQpbQXV0aG9yc10g W1JGQzQyMDZdIHdpbGwgYmUgYWRkZWQgYXMgYSByZWZlcmVuY2UNCg0KLSBTZWN0aW9uIDMuMiBh Z2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZlIGFjdGlvbiIgdGVybS4NCg0KW0F1dGhvcnNdIE9LLCB0 aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQuDQoNCg0KLSBTZWN0aW9uIDQuMS4gWW91IHNheSAidHdv IG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3UgcmVhbGx5DQptZWFuICJzaW11bHRh bmVvdXNseSIgb3IgbWVyZWx5IHRoYXQgdGhleSBtdXN0IGJvdGggb2NjdXIgZm9yDQpwcm90ZWN0 aW9uIHRvIGJlIHByb3ZpZGVkPyAoU2FtZSBjb21tZW50IGluIHNlY3Rpb24gNS4xLg0KDQpbQXV0 aG9yc10gQm90aCBhY3Rpb25zIHNob3VsZCBvY2N1ciBhdCB0aGUgc2FtZSB0aW1lLCBvciBhcyBj bG9zZWx5IGFzIHBvc3NpYmxlIHRvIHByb3ZpZGUgZmFzdCBwcm90ZWN0aW9uLg0KDQpXaGF0IHRl eHQgY2hhbmdlIGlzIHBsYW5uZWQ/DQoNCg0KLSBTZWN0aW9uIDUuMi4gSSBzdWdnZXN0IG51bWJl cmluZyB0aGUgY3VycmVudGx5IGJ1bGxldHRlZCByZXF1aXJlbWVudHMNCmxpc3QuDQoNCltBdXRo b3JzXSBPSywgd2Ugd2lsbCB1c2UgbnVtYmVycy4NCg0KDQotIFNlY3Rpb24gNS4yOiBGaXJzdCBw YXJhZ3JhcGggYW5kIGZvcnRoIGJ1bGxldCBsYXN0IHNlbnRlbmNlLiBUaGVzZQ0KYm90aCBiYXNp Y2FsbHkgY292ZXIgdGhlIHNhbWUgdG9waWMgKHByZWVtcHRpb24pIGFuZCBhY3R1YWxseSBzYXkN CnNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3MuIEkgc3VnZ2VzdCBjb21iaW5lIGludG8gYSBzaW5n bGUNCnJlcXVpcmVtZW50IHRvIGVuc3VyZSBjb25zaXN0ZW5jeSBhbmQgZnVsbCBjb3ZlcmFnZSBv ZiB0aGUgdG9waWMuDQoNCltBdXRob3JzXSBUaGUgZmlyc3QgcGFyYWdyYXBoIGlzIGZvciBzb2Z0 LXByZWVtcHRpb24sIHdoaWxlIHRoZSBmb3VydGggYnVsbGV0IGJlbG9uZ3MgdG8gdGhlIHJlcXVp cmVtZW50cyBvZiBoYXJkLXByZWVtcHRpb24uDQoNCkRvIHlvdSBwbGFuIGEgdGV4dCBjaGFuZ2U/ ICAodGhlIDFzdCBwYXJhZ3JhcGggc2hvdWxkIGJlIGEgbGlzdCBpdGVtIGFuZCBzb2Z0LXByZWVt cHRpb24gaXMgbWVudGlvbmVkIGFzIGEgcGFyZW50aGV0aWNhbCAsIGFuZCB0aGUgZm9ydGggZG9l c24ndCBtZW50aW9uIGl0cyBzY29wZSBhcyBoYXJkIHByZWVtcHRpb24uKQ0KDQoNCi0gU2VjdGlv biA1LjIsIHJlcSA1LiBIb3cgZG9lcyB0aGlzIHJlbGF0ZSB0byBzZWN0aW9uIDUuNT8gU2hvdWxk bid0DQp0aGUgdG9waWNzIHJlbGF0ZWQgdG8gdGltaW5nIGJlIGNvbnNvbGlkYXRlZD8NCg0KW0F1 dGhvcnNdIFllcywgcmVxIDUgY2FuIGJlIG1vdmVkIHRvIFNlY3Rpb24gNS41Lg0KDQpva2F5Lg0K DQoNCi0gU2VjdGlvbiA1LjI6IHJlcXVpcmVtZW50IDYgc2VlbXMgdG8gYmUgYSBzdWJzZXQgb2Yg Nywgc28gaXQgc2hvdWxkIGJlDQpkcm9wcGVkLg0KDQpbQXV0aG9yc10gWWVzLCBpdCB3aWxsIGJl IGRlbGV0ZWQuDQoNCmdyZWF0Lg0KLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1lbnQgOC4gSXNuJ3Qg dGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCmp1c3QgdGhpcyBvbmUgdHJhZmZpYyB0 cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/DQoNCltBdXRob3JzXSBSZXEuIDkgd2lsbCBiZSBk ZWxldGVkIGFzIGl0IHNlZW1zIHRvIHJlcXVpcmUgY29udHJvbCBwbGFuZSBzdXBwb3J0cy4NCg0K DQotIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsDQoNCltBdXRob3JzXSBPSy4NCg0KDQotIHNlY3Rp b24gNS40OiAiIFdoZW4gdGhlIHdvcmtpbmcgcGF0aCBkZXRlY3RzLi4iIGRldGVjdGlvbiBpcyBi eSB0aGUNCm5vZGUgbm90IHRoZSBwYXRoLg0KDQpbQXV0aG9yc10gWWVzLiBXZSB3aWxsIHNpbXBs eSBzYXkgdGhhdCDigJxXaGVuIHRoZSBjb25kaXRpb24gdGhhdCB0cmlnZ2VyZWQgdGhlIHByb3Rl Y3Rpb24gc3dpdGNoaW5nIGlzIGNsZWFyZWQsIOKApuKAnQ0KDQotIFNlY3Rpb24gNS40LCBsYXN0 IHNlbnRlbmNlLiBUaGlzIGlzIG9ubHkgdGhlIDJuZCB0aW1lIHlvdSBpbXBseSB0aGF0DQp0aGUg ZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBhIG5ldyBwcm90b2NvbC4gSSB0aGluayB0 aGlzDQpwb2ludCBpcyBjdXJyZW50bHkgdG9vIHN1YnRsZSBpbiB0aGUgZG9jdW1lbnQuIChUaGlz IHBvaW50IHdhcyBhbHNvDQptYWRlIGFzIGEgbWlub3IgY29tbWVudC4pDQoNCltBdXRob3JzXSBB cyBpbiBvdGhlciBwcm90ZWN0aW9uIHN3aXRjaGluZyB0ZWNobm9sb2dpZXMsIHR3byBtb2RlcyBv ZiBvcGVyYXRpb25zIChyZXZlcnRpdmUgYW5kIG5vbi1yZXZlcnRpdmUpIGFyZSByZXF1aXJlZC4N Cg0KDQotIHNlY3Rpb24gNS42LiBSRkMgNjM3MiBzaG91bGQgYmUgcmVmZXJlbmNlZA0KW0F1dGhv cnNdIFdlIHdpbGwgYWRkIOKAnGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3Ml3igJ0gdG8gdGhlIGVu ZHMgb2YgdHdvIHBhcmFncmFwaHMgZm9yIFdUUiB0aW1lciBhbmQgaG9sZC1vZmYgdGltZXIuDQoN Ck9rYXkuDQoNCioqKioqIEVuZCBvZiBDb21tZW50IHJlc29sdXRpb24gKioqKioNCi4uLg0KDQo= From nobody Thu Jul 10 08:50:09 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF671B27A9; Thu, 10 Jul 2014 00:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.402 X-Spam-Level: X-Spam-Status: No, score=-95.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtBhzXMiPrNX; Thu, 10 Jul 2014 00:52:10 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5641B27A8; Thu, 10 Jul 2014 00:52:09 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 Jul 2014 16:52:06 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 10 Jul 2014 16:52:03 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger , Yaacov Weingarten Thread-Topic: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+gAI5dwCABCIRAIADfBBe Date: Thu, 10 Jul 2014 07:52:02 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749725@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> , <53BBCE48.7060008@labn.net> In-Reply-To: <53BBCE48.7060008@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.4.85] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/TbsGuu_LfUN_2Ymr6af7Hiddjqo X-Mailman-Approved-At: Thu, 10 Jul 2014 08:49:47 -0700 Cc: "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogIFttcGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFm?= =?euc-kr?q?t-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 07:52:13 -0000 TG91IGFuZCBZYWFjb3YsDQoNCkhlcmUgaXMgbXkgc3VnZ2VzdGlvbiBvbiB0aG9zZSB0d28gYnVs bGV0IGl0ZW0gdGV4dHMgcmVsYXRlZCB0byAiYXNzaWduZWQiLg0KDQpBcyBpbiBteSBlYXJsaWVy IGVtYWlsIHRvIExvdSdzIGZvbGxvd3VwIGNvbW1lbnRzLCANCndlIGNhbiBtYWtlIHR3byBzdWIg c2VjdGlvbnMgdW5kZXIgdGhpcyBTZWN0aW9uIDUuMi4gDQphbmQgdGl0bGUgdGhlbSBhcyAiNS4y LjEgU29mdCBwcmVlbXB0aW9uIiBhbmQgIjUuMi4yIEhhcmQgcHJlZW1wdGlvbiIuIA0KVGhvc2Ug dHdvIGJ1bGxldCBpdGVtcyB3aXRoICJhc3NpZ25lZCIgd2lsbCBiZSBwbGFjZWQgdW5kZXIgNS4y LjIgSGFyZCBwcmVlbXB0aW9uLg0KDQpJbiBhZGRpdGlvbiB0byB0aGlzLCB3ZSBjYW4gY2xhcmlm eSBmdXJ0aGVyLCBzbyB0aGF0ICJ1dGlsaXplZCIgaXMgbm90IGJlaW5nIG1pc3VzZWQuDQpOZXcg dGV4dHMgZm9yIHRob3NlIHR3byBidWxsZXQgaXRlbXMgYXJlOg0KDQpvIElmIG11bHRpcGxlIHBy b3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3RpbmcNCiAgIHRoZSBz aGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2VzIFNIQUxMIGJlDQogICB1dGlsaXplZCBvbiBh IGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzLiANCiAgIFRyYWZmaWMgb2YgdGhlIHByb3Rl Y3Rpb24gcGF0aHMgdGhhdCByZXF1ZXN0IHRoZSBzaGFyZWQgcmVzb3VyY2UgbGF0ZSANCiAgIFNI QUxMIGJlIGJsb2NrZWQgb3IgTUFZIHVzZSBhdmFpbGFibGUgcmVzb3VyY2Ugd2l0aG91dCBpbnRl cnJ1cHRpbmcgDQogICB0cmFmZmljIG9mIHByaW9yIHByb3RlY3Rpb24gcGF0aHMgdGhhdCBhcmUg dXRpbGl6aW5nIHRoZSBzaGFyZWQgcmVzb3VyY2UuDQogICBJbiBvcmRlciB0byBjb3ZlciB0aGUg c2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBwcmluY2lwbGUgDQog ICBjYW5ub3QgcmVzb2x2ZSB0aGUgY29udGVudGlvbiBhbW9uZyBtdWx0aXBsZSBlcXVhbCBwcmlv cml0eSByZXF1ZXN0cywgDQogICBpLmUuLCB3aGVuIHRoZSByZXF1ZXN0cyBvY2N1ciBzaW11bHRh bmVvdXNseSwgdGllLWJyZWFraW5nIHJ1bGVzIA0KICAgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29w ZSBvZiBhbiBTTVAgZG9tYWluLg0KDQpvIElmIGEgaGlnaGVyIHByaW9yaXR5IHBhdGggcmVxdWly ZXMgdGhlIHByb3RlY3Rpb24gcmVzb3VyY2VzIHRoYXQgYXJlDQogICBiZWluZyB1dGlsaXplZCBi eSBhIGxvd2VyIHByaW9yaXR5IHBhdGgsIHRoZSByZXNvdXJjZXMgU0hBTEwgYmUNCiAgIHV0aWxp emVkIGJ5IHRoZSBoaWdoZXIgcHJpb3JpdHkgcGF0aC4gICANCiAgIFRyYWZmaWMgd2l0aCB0aGUg bG93ZXIgcHJpb3JpdHkgU0hBTEwgYmUgYmxvY2tlZCBvciBNQVkgdXNlIGF2YWlsYWJsZSByZXNv dXJjZXMgDQogICB3aXRob3V0IGludGVycnVwdGluZyB0cmFmZmljIG9mIHRoZSBoaWdoZXIgcHJp b3JpdHkgcGF0aC4NCg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrq4s70gu+e29zogTG91IEJlcmdl ciBbbGJlcmdlckBsYWJuLm5ldF0NCrq4s70gs6/CpTogMjAxNLPiIDe/+SA4wM8gyK2/5MDPIL/A yMQgNzo1Ng0Kud60wiC757b3OiBZYWFjb3YgV2VpbmdhcnRlbjsgt/nBpLW/DQrC/MG2OiBtcGxz QGlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0 Zi5vcmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmcNCsGmuPE6IFJl OiBbUlRHLURJUl0gW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVx dWlyZW1lbnRzLTA2LnR4dA0KDQpZYWFjb3YsDQogICAgU291bmRzIHJlYXNvbmFibGUsIGJ1dCBJ J2xsIG5lZWQgdG8gc2VlIHRoZSBuZXcgd29yZGluZyB0byBiZSBzdXJlLg0KDQpUaGFua3MsDQpM b3UNCk9uIDcvNS8yMDE0IDM6NDkgUE0sIFlhYWNvdiBXZWluZ2FydGVuIHdyb3RlOg0KPg0KPiBM b3UsIGhpDQo+IEkgd291bGQgbGlrZSB0byBhZGRyZXNzIHR3byBvZiB5b3VyIGNvbW1lbnRzLCBp biB5b3VyIGZvbGxvdy11cA0KPiBtZXNzYWdlLCBzaW5jZSBJIGFtIHRoZSBzb3VyY2Ugb2YgdGhl IGNoYW5nZSBpbiB0ZXJtaW5vbG9neS4NCj4NCj4gUmVnYXJkaW5nIHRoZSB0d28gb2NjdXJlbmNl cyBvZiAiYXNzaWduZWQiIGluIHBsYWNlIG9mICJ1dGlsaXplZCIgLQ0KPiB3aGVuIEkgcmVhZCB0 aGUgcHJvcG9zZWQgY2hhbmdlcyxhcyBkaXNjdXNzZWQgYW1vbmdzdCB0aGUgYXV0aG9ycywgSQ0K PiBmZWx0IHRoYXQgaW4gdGhvc2UgdHdvIGluc3RhbmNlcyB0aGUgdXNlIG9mICJ1dGlsaXplZCIg Y291bGQgbGVhZCB0bw0KPiBzb21lIGFtYmlndWl0eS4NCj4NCj4gSWYgd2Ugc3RhdGUgdGhhdCAi cmVzb3VyY2VzIFNIT1VMRCBiZSB1dGlsaXplZCBvbiBhIGZpcnN0IGNvbWUgZmlyc3QNCj4gc2Vy dmVkIGJhc2lzIiB0aGlzIGNvdWxkIGJlIGludGVycHJldGVkIChJTU8pIGFzIHJlZmVycmluZyB0 byB0aGUNCj4gcGFja2V0IGxldmVsLCByYXRoZXIgdGhhbiAgdXRpbGl6ZWQgYnkgYSBzcGVjaWZp YyBwYXRoLCBzdWNoIHRoYXQNCj4gcGFja2V0cyBmcm9tIGRpZmZlcmVudCBwYXRocyBjb3VsZCBi ZSBpbnRlcnNwZXJzZWQgYWxvbmcgdGhlIHNoYXJlZA0KPiBzZWdtZW50cy4gVGhlcmVmb3JlLEkg c3VnZ2VzdGVkIHRoYXQgb3IgdGhpcyBjb250ZXh0IGl0IHdvdWxkIGJlDQo+IGJldHRlciB0byB1 c2UgYSB3b3JkIHRoYXQgbWVhbnQgdGhhdCB0aGUgZmlyc3QtY29tZSBmaXJzdCBzZXJ2ZWQgYmFz aXMNCj4gd2FzIGF0IHRoZSBsZXZlbCBvZiBhc3NpZ25pbmcgKG9yIGFsbG9jYXRpbmcpIHRoZSBy ZXNvdXJjZXMgcmF0aGVyDQo+IHRoYW4gdXRpbGl6aW5nIHRoZW0uDQo+DQo+IEhvcGUgdGhpcyBj bGFyaWZpZXMgdGhpcyBwb2ludC4gSSBhbSBjZXJ0YWluIHRoYXQgSSBzcGVhayBmb3IgdGhlDQo+ IG90aGVyIGF1dGhvcnMgaW4gIHNheWluZyB0aGF0IEkgYW0gb3BlbiB0byBvdGhlciBzdWdnZXN0 aW9ucy4NCj4NCj4gQlIsDQo+IHlhYWNvdg0KPg0KPiBPbiBKdWwgNCwgMjAxNCAzOjUzIEFNLCAi SmVvbmcgUnlvbyIgPHJ5b29AZXRyaS5yZS5rcg0KPiA8bWFpbHRvOnJ5b29AZXRyaS5yZS5rcj4+ IHdyb3RlOg0KPg0KPiAgICAgRGVhciBMb3UsDQo+DQo+DQo+DQo+ICAgICBUaGFua3MgYSBsb3Qg Zm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMuDQo+DQo+DQo+DQo+ICAgICBUaGUgYXV0aG9ycyBv ZiB0aGlzIGRyYWZ0IGhhdmUgZGlzY3Vzc2VkIHlvdXIgY29tbWVudHMsIGFuZCBhcmUNCj4gICAg IHByb3Bvc2luZyBvdXIgcmVzb2x1dGlvbnMgdG8geW91ciBjb21tZW50cy4gUGxlYXNlLCBsZXQg dXMga25vdyBpZg0KPiAgICAgdGhlIHByb3Bvc2FsIGlzIGFwcHJvcHJpYXRlIHRvIGFkZHJlc3Mg eW91ciBjb21tZW50cyBhbmQgY29uY2VybnMuDQo+DQo+DQo+DQo+ICAgICBCZXN0IHJlZ2FyZHMs DQo+DQo+DQo+DQo+ICAgICBBdXRob3JzIG9mIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1l bnRzIGRyYWZ0DQo+DQo+DQo+DQo+ICAgICAqKioqKiogQmVnaW5uaW5nIG9mIENvbW1lbnQgUmVz b2x1dGlvbiAqKioqKioNCj4NCj4NCj4NCj4gICAgIC0gRG9jdW1lbnQncyB1c2FnZSBvZiAiY29t bWl0dGVkIiB2cyAiYWxsb2NhdGVkIiByZXNvdXJjZXM6DQo+DQo+ICAgICBJbiBzZWN0aW9uIDEg dGhlIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZQ0KPiAgICAgZGlzdGlu Y3Rpb24gYmV0d2VlbiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBiYXNlZCBvbiB3aGVu DQo+ICAgICByZXNvdXJjZXMgYXJlICJjb21taXR0ZWQiLiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBw YXN0DQo+ICAgICBkZWZpbml0aW9uLiBSRkM0NDI3IGFuZCA2MzcyIG1ha2UgdGhlIGRpc3RpbmN0 aW9uIHRoYXQgcHJvdGVjdGlvbg0KPiAgICAgYW5kIHJlc3RvcmF0aW9uIGRpZmZlciBiYXNlZCBv biB3aGVuIHJlc291cmNlcyBhcmUgKmFsbG9jYXRlZCogbm90DQo+ICAgICAqY29tbWl0dGVkKi4g VG8gcXVvdGUgUkZDIDQ0Mjc6DQo+DQo+ICAgICBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90 ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBtYWRlIGJhc2VkDQo+ICAgICBvbiB0aGUgcmVzb3Vy Y2UgYWxsb2NhdGlvbiBkb25lIGR1cmluZyB0aGUgcmVjb3ZlcnkgTFNQL3NwYW4NCj4gICAgIGVz dGFibGlzaG1lbnQuIFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZg0K PiAgICAgcmVzdG9yYXRpb24gaXMgbWFkZSBiYXNlZCBvbiB0aGUgbGV2ZWwgb2Ygcm91dGUgY29t cHV0YXRpb24sDQo+ICAgICBzaWduYWxpbmcsIGFuZCByZXNvdXJjZSBhbGxvY2F0aW9uIGR1cmlu ZyB0aGUgcmVzdG9yYXRpb24NCj4gICAgIExTUC9zcGFuIGVzdGFibGlzaG1lbnQuDQo+DQo+ICAg ICBUaGlzIGRpZmZlcmVuY2UgYWxzbyBsZWFkcyB0byBjb21lIGNvbmZ1c2VkIHN0YXRlbWVudHMg aW4gdGhlDQo+ICAgICBkb2N1bWVudCBhcyB3ZWxsIGFzIGFtYmlndWl0eSBpbiB0aGUgdGV4dCwg aS5lLiBjb25mdXNpb24gYnkgdGhlDQo+ICAgICByZWFkZXIuIFRoZSB0ZXJtICJjb21taXR0ZWQi IGlzIG5vdCB0aWdodGx5IGRlZmluZWQgaW4gdGhpcw0KPiAgICAgZG9jdW1lbnQgKG9yIGVhcmxp ZXIgd29yaykgYW5kIGlzIHVzZWQgZGlmZmVyZW50bHkgdGhhbiBob3cNCj4gICAgICJhbGxvY2F0 ZWQiIGhhcyBiZWVuIHVzZWQuIEFuIGV4YW1wbGUgb2YgdGhpcyBjYW4gYmUgZm91bmQgaW4NCj4g ICAgIFNlY3Rpb24gMy4xIHdoaWNoIHN0YXRlczoNCj4NCj4gICAgIEhvd2V2ZXIsIHRoZSBjb21t aXRtZW50IG9mIHRoZSByZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGUNCj4gICAgIHNoYXJlZCBz ZWdtZW50cywgd2lsbCBvbmx5IGJlIGZpbmFsaXplZCB3aGVuIHRoZSBwcm90ZWN0aW9uDQo+ICAg ICBwYXRoIGlzIGFjdHVhbGx5IGFjdGl2YXRlZC4gVGhlcmVmb3JlLCBmb3IgdGhlIHB1cmlzdHMg LQ0KPiAgICAgcmVnYXJkaW5nIHRoZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVyZSBi ZXR3ZWVuDQo+ICAgICBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbi4NCj4NCj4gICAgIEJvdGgg c2VudGVuY2VzIGFyZSBwcm9ibGVtYXRpYy4gSW4gdGhlIGZpcnN0LCBjb21taXRtZW50IHNlZW1z IHRvDQo+ICAgICBjb3ZlciBhICJwcm90ZWN0aW9uIHN3aXRjaCIgd291bGQgImNvbm5lY3QiIHRo ZSBwcm90ZWN0aW9uIHBhdGgNCj4gICAgIGJ1dCBub3QgdGhlIGVhcmxpZXIgImFsbG9jYXRpb24i IG9mIHJlc291cmNlcy4gKFF1b3RlZCB0ZXJtcyBhcmUNCj4gICAgIHVzZWQgaW4gZWFybGllciBS RkNzLikgVGhlIHNlY29uZCBjb25jbHVzaW9uIGlzIGJhc2VkIG9uIHRoZSBuZXcNCj4gICAgIGRp c3RpbmN0aW9uIG9mIHByb3RlY3Rpb24gdnMuIHJlc3RvcmF0aW9uIGFuZCBpcyB1bm5lY2Vzc2Fy eSB3aXRoDQo+ICAgICB0aGUgZXhpc3RpbmcgZGlzdGluY3Rpb24uDQo+DQo+ICAgICBUaGlzIGlz c3VlIGV4aXN0cyBpbiBtdWx0aXBsZSBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlDQo+ICAg ICAiY29tbWl0dGVkIiBpcyB1c2VkIGFuZCBJJ2QgcmVjb21tZW5kIHRoYXQgZWFjaCBzaG91bGQg YmUgcmVwbGFjZWQNCj4gICAgIHdpdGggdGVybWlub2xvZ3kgdXNlZCBpbiB0aGUgcmVmZXJlbmNl ZCBSRkNzLCBpLmUuLCAiYWxsb2NhdGlvbiIsDQo+ICAgICAiY29ubmVjdGlvbiIsICJjcm9zcy1j b25uZWN0IiwgInByb3RlY3Rpb24gc3dpdGNoKG92ZXIpIiwgLi4uDQo+DQo+ICAgICBOb3RlIEkn bSAqbm90KiBoaWdobGlnaHRpbmcgYWxsIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBwcm9ibGVtcyBp biB0aGUNCj4gICAgIGRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4gVGhlcmUgYXJlIGEg Y291cGxlIG9mIHBsYWNlcyBpbiB0aGUNCj4gICAgIGRvY3VtZW50IHdoZXJlIEkgdGhpbmsgaXQn cyBwb3NzaWJsZSB0aGF0IG9uY2UgdGhpcyB0ZXJtaW5vbG9neQ0KPiAgICAgYW1iaWd1aXR5IGlz IGNvcnJlY3RlZCB0aGF0IEknbGwgaGF2ZSBvdGhlciBzdWJzdGFudGl2ZSBjb21tZW50cy4NCj4N Cj4NCj4NCj4gICAgIFtBdXRob3JzXSBBZnRlciByZXZpZXdpbmcgUkZDcyA0NDI3LCA2MzcyLCAz OTQ1LCA0NDI2LCBhbmQgNDQyOCwNCj4gICAgIHdlIGNvbmNsdWRlZCB0aGF0IHRoZSBkaXN0aW5j dGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kDQo+ICAgICByZXN0b3JhdGlvbiBzaG91bGQgYmUg YWxpZ25lZCB3aXRoIHRoZSBleGl0aW5nIGRvY3VtZW50cw0KPiAgICAgbm9ybWF0aXZlbHkgcmVm ZXJlbmNlZCBieSB0aGlzIGRvY3VtZW50LiBBY2NvcmRpbmdseSwgdGhlDQo+ICAgICBmb2xsb3dp bmcgMTYgbW9kaWZpY2F0aW9ucyB3aWxsIGJlIGRvbmUgaW4gcmV2aXNpb246DQo+DQo+DQo+DQo+ ICAgICAoMSkgU2VjdGlvbiAxLCB0aGUgdGhpcmQgcGFyYWdyYXBoDQo+DQo+ICAgICBPTEQ6DQo+ DQo+ICAgICBBcyBwb2ludGVkIG91dA0KPg0KPiAgICAgaW4gW1JGQzYzNzJdIGFuZCBbUkZDNDQy OF0sIGFwcGx5aW5nIDErMSBsaW5lYXIgcHJvdGVjdGlvbiByZXF1aXJlcw0KPg0KPiAgICAgdGhh dCByZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCBmb3IgdXNlIGJ5IGJvdGggdGhlIHdvcmtpbmcgYW5k DQo+DQo+ICAgICBwcm90ZWN0aW9uIHBhdGhzLiBBcHBseWluZyAxOjEgcHJvdGVjdGlvbiByZXF1 aXJlcyB0aGF0IHRoZSBzYW1lDQo+DQo+ICAgICByZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCwgYnV0 IGFsbG93cyB0aGUgcmVzb3VyY2VzIG9mIHRoZSBwcm90ZWN0aW9uDQo+DQo+ICAgICBwYXRoIHRv IGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUgZXh0cmEgdHJhZmZpYy4NCj4NCj4gICAgIE5F VzoNCj4NCj4gICAgIEFzIHBvaW50ZWQgb3V0DQo+DQo+ICAgICBpbiBbUkZDNjM3Ml0gYW5kIFtS RkM0NDI4XSwgYXBwbHlpbmcgMSsxIHByb3RlY3Rpb24gcmVxdWlyZXMNCj4NCj4gICAgIHRoYXQg cmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQgZm9yIHVzZSBieSBib3RoIHRoZSB3b3JraW5nIGFuZA0K Pg0KPiAgICAgcHJvdGVjdGlvbiBwYXRocy4gQXBwbHlpbmcgMToxIHByb3RlY3Rpb24gcmVxdWly ZXMgdGhhdCB0aGUgc2FtZQ0KPg0KPiAgICAgcmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQsIGJ1dCBh bGxvd3MgdGhlIHJlc291cmNlcyBvZiB0aGUgcHJvdGVjdGlvbg0KPg0KPiAgICAgcGF0aCB0byBi ZSB1dGlsaXplZCBmb3IgcHJlLWVtcHRpYmxlIGV4dHJhIHRyYWZmaWMuDQo+DQo+DQo+DQo+ICAg ICAoMikgVGhlIHdob2xlIHRleHQgaW4gU2VjdGlvbiAzLjEgd2lsbCBiZSByZXBsYWNlZCB3aXRo Og0KPg0KPiAgICAgW1JGQzYzNzJdLCBiYXNlZCB1cG9uIHRoZSBkZWZpbml0aW9ucyBpbiBbUkZD NDQyN10sIGRpZmZlcmVudGlhdGVzDQo+ICAgICBiZXR3ZWVuICJwcm90ZWN0aW9uIiBhbmQgInJl c3RvcmF0aW9uIiBkZXBlbmRlbnQgdXBvbiB0aGUgZHluYW1pc20NCj4gICAgIG9mIHRoZSByZXNv dXJjZSBhbGxvY2F0aW9uLiBUaGUgc2FtZSBkaXN0aW5jdGlvbiBpcyB1c2VkIGluDQo+ICAgICBb UkZDMzk0NV0sIFtSRkM0NDI2XSwgYW5kIFtSRkM0NDI4XS4gVGhpcyBkb2N1bWVudCBhbHNvIHVz ZXMgdGhlDQo+ICAgICBzYW1lIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVz dG9yYXRpb24gYXMgc3RhdGVkIGluDQo+ICAgICBbUkZDNjM3Ml0uDQo+DQo+DQo+DQo+ICAgICAo MykgSW4gcGFnZSA2LA0KPg0KPiAgICAgT0xEOg0KPg0KPiAgICAgVGhlIHVzZSBvZiBwcmVlbXB0 aW9uIGluIHRoZSBuZXR3b3JrIGlzIHR5cGljYWxseSBhIGJ1c2luZXNzIG9yDQo+DQo+ICAgICBw b2xpY3kgZGVjaXNpb24gc3VjaCB0aGF0IHdoZW4gcHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIGNv bnRlbmRlZCwNCj4NCj4gICAgIHByaW9yaXR5IGNhbiBiZSBhcHBsaWVkIHRvIGRldGVybWluZSB0 byB3aGljaCBwYXJ0aWVzIHRoZSBwcm90ZWN0aW9uDQo+DQo+ICAgICByZXNvdXJjZXMgYXJlIGNv bW1pdHRlZC4NCj4NCj4gICAgIE5FVzoNCj4NCj4gICAgIFRoZSB1c2Ugb2YgcHJlZW1wdGlvbiBp biB0aGUgbmV0d29yayBpcyB0eXBpY2FsbHkgYSBidXNpbmVzcyBvcg0KPg0KPiAgICAgcG9saWN5 IGRlY2lzaW9uIHN1Y2ggdGhhdCB3aGVuIHByb3RlY3Rpb24gcmVzb3VyY2VzIGFyZSBjb250ZW5k ZWQsDQo+DQo+ICAgICBwcmlvcml0eSBjYW4gYmUgYXBwbGllZCB0byBkZXRlcm1pbmUgd2hpY2gg cGFydGllcyB1dGlsaXplIHRoZQ0KPiAgICAgcHJvdGVjdGlvbg0KPg0KPiAgICAgcmVzb3VyY2Vz Lg0KPg0KPg0KPg0KPiAgICAgKDQpIFBhZ2UgNywgdGhlIGZpcnN0IHBhcmFncmFwaDoNCj4NCj4g ICAgIE9MRDoNCj4NCj4gICAgIHRoZSByZXNvdXJjZXMgZm9yIHRoZSBwcm90ZWN0aW9uIHBhdGgg YXJlIGZ1bGx5IGNvbW1pdHRlZCwNCj4NCj4gICAgIE5FVw0KPg0KPiAgICAgdGhlIHJlc291cmNl cyBmb3IgdGhlIHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkgZGVkaWNhdGVkLA0KPg0KPg0KPg0K PiAgICAgT0xEOg0KPg0KPiAgICAgcmVzb3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBu b3QgYmUgY29tbWl0dGVkIHVudGlsIKGmDQo+DQo+ICAgICBORVc6DQo+DQo+ICAgICByZXNvdXJj ZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdvdWxkIG5vdCBiZSB1dGlsaXplZCB1bnRpbCChpg0KPg0K Pg0KPg0KPiAgICAgKDUpIEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHBhZ2UgNywNCj4NCj4g ICAgIE9MRDoNCj4NCj4gICAgICJIYXJkIFByZWVtcHRpb24iIHJlcXVpcmVzIHRoZSBwcm9ncmFt bWluZyBvZiBzZWxlY3RvcnMgYXQgdGhlDQo+ICAgICBpbmdyZXNzIG9mIGVhY2ggc2hhcmVkIHNl Z21lbnQgdG8gc3BlY2lmeSB3aGljaCBiYWNrdXAgcGF0aCBoYXMNCj4gICAgIHRoZSBoaWdoZXN0 IHByaW9yaXR5IHdoZW4gY29tbWl0dGluZyBwcm90ZWN0aW9uIHJlc291cmNlcywgdGhlDQo+ICAg ICBvdGhlcnMgYmVpbmcgcHJlZW1wdGVkLg0KPg0KPiAgICAgTkVXDQo+DQo+ICAgICAiSGFyZCBQ cmVlbXB0aW9uIiByZXF1aXJlcyB0aGUgcHJvZ3JhbW1pbmcgb2Ygc2VsZWN0b3JzIGF0IHRoZQ0K PiAgICAgaW5ncmVzcyBvZiBlYWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkgdGhlIHByaW9y aXRpZXMgb2YgYmFja3VwDQo+ICAgICBwYXRocywgc28gdGhhdCB0cmFmZmljIG9mIGxvd2VyIHBy aW9yaXR5IHBhdGhzIGNhbiBiZSBwcmVlbXB0ZWQuDQo+DQo+DQo+DQo+ICAgICAoNikgVGhlIGZp cnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMToNCj4NCj4gICAgIE9MRDoNCj4NCj4gICAgIKGm IGFuZCBjb21taXQgdGhlIGFzc29jaWF0ZWQgcmVzb3VyY2VzLiBUaGUgY29tbWl0bWVudCBvZiBy ZXNvdXJjZXMNCj4NCj4gICAgIGlzIGRlcGVuZGVudCB1cG9uIKGmDQo+DQo+ICAgICBORVc6DQo+ DQo+ICAgICChpiBhbmQgY29vcmRpbmF0ZSB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIGFzc29jaWF0 ZWQgc2hhcmVkIHJlc291cmNlcy4NCj4NCj4gICAgIFRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBj b29yZGluYXRpb24gaXMgZGVwZW5kZW50IHVwb24goaYNCj4NCj4NCj4NCj4gICAgICg3KSBUaGUg c2Vjb25kIHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMToNCj4NCj4gICAgIE9MRDoNCj4NCj4gICAg IFdoZW4gdGhlIHJlc2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSBj b21taXR0ZWQgdG8gYQ0KPg0KPiAgICAgcGFydGljdWxhciBwcm90ZWN0aW9uIHBhdGgsIHRoZXJl IG1heSBub3QgYmUgc3VmZmljaWVudCByZXNvdXJjZXMNCj4NCj4gICAgIGF2YWlsYWJsZSBmb3Ig YW4gYWRkaXRpb25hbCBwcm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQNCj4N Cj4gICAgIGlmIGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJz IGEgcHJvdGVjdGlvbg0KPg0KPiAgICAgc3dpdGNoLCB0aGUgY29tbWl0bWVudCBvZiB0aGUgcmVz b3VyY2VzIG1heSBmYWlsLiBJbiBvcmRlciB0bw0KPg0KPiAgICAgb3B0aW1pemUgdGhlIG9wZXJh dGlvbiBvZiB0aGUgY29tbWl0bWVudCBhbmQgcHJlcGFyaW5nIGZvciBjYXNlcyBvZg0KPg0KPiAg ICAgbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgY29tbWl0bWVudCBvZiB0aGUg c2hhcmVkDQo+DQo+ICAgICByZXNvdXJjZXMgYXJlIGJlIGNvb3JkaW5hdGVkIGJldHdlZW4gdGhl IGRpZmZlcmVudCB3b3JraW5nIHBhdGhzIGluDQo+DQo+ICAgICB0aGUgU01QIG5ldHdvcmsuDQo+ DQo+ICAgICBORVc6DQo+DQo+ICAgICBXaGVuIHRoZSByZXNlcnZlZCByZXNvdXJjZXMgb2YgdGhl IHNoYXJlZCBzZWdtZW50cyBhcmUgdXRpbGl6ZWQgYnkgYQ0KPg0KPiAgICAgcGFydGljdWxhciBw cm90ZWN0aW9uIHBhdGgsIHRoZXJlIG1heSBub3QgYmUgc3VmZmljaWVudCByZXNvdXJjZXMNCj4N Cj4gICAgIGF2YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25hbCBwcm90ZWN0aW9uIHBhdGguIFRoaXMg dGhlbiBpbXBsaWVzIHRoYXQNCj4NCj4gICAgIGlmIGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRo ZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVjdGlvbg0KPg0KPiAgICAgc3dpdGNoLCB0aGUg cmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIG1heSBmYWlsLiBUaGUNCj4gICAgIGRp ZmZlcmVudCB3b3JraW5nIHBhdGhzIGluDQo+DQo+ICAgICB0aGUgU01QIG5ldHdvcmsgYXJlIGlu dm9sdmVkIGluIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbg0KPiAgICAgY29vcmRpbmF0aW9uLg0K Pg0KPiAgICAgLg0KPg0KPg0KPg0KPiAgICAgKDgpIFNlY3Rpb24gNS4xLA0KPg0KPiAgICAgT0xE Og0KPg0KPiAgICAgoaYgYW5kIGNvbW1pdCB0aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMuDQo+DQo+ ICAgICBORVcNCj4NCj4gICAgIKGmIGFuZCBjb29yZGluYXRlIHRoZSB1dGlsaXphdGlvbiBvZiB0 aGUgYXNzb2NpYXRlZCBzaGFyZWQgcmVzb3VyY2VzLg0KPg0KPg0KPg0KPiAgICAgKDkpIEluIFNl Y3Rpb24gNS4xLA0KPg0KPiAgICAgT0xEOg0KPg0KPiAgICAgSW4gdGhlIGNhc2Ugb2YgbXVsdGlw bGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgY29tbWl0bWVudCBvZiB0aGUNCj4NCj4gICAg IHNoYXJlZCByZXNvdXJjZXMgU0hBTEwgYmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0aGUgZGlmZmVy ZW50IHdvcmtpbmcNCj4NCj4gICAgIHBhdGhzIGluIHRoZSBTTVAgbmV0d29yay4NCj4NCj4gICAg IE5FVzoNCj4NCj4gICAgIEluIHRoZSBjYXNlIG9mIG11bHRpcGxlIHdvcmtpbmcgcGF0aHMgZmFp bGluZywgdGhlIHNoYXJlZCByZXNvdXJjZQ0KPiAgICAgdXRpbGl6YXRpb24NCj4NCj4gICAgIGNv b3JkaW5hdGlvbiBTSEFMTCBiZSBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZw0KPg0KPiAg ICAgcGF0aHMgaW4gdGhlIFNNUCBuZXR3b3JrLg0KPg0KPg0KPg0KPiAgICAgKDEwKSBTZWN0aW9u IDUuMS4xLg0KPg0KPiAgICAgT0xEOg0KPg0KPiAgICAgoaYgYmVjYXVzZSB0aGV5IGFscmVhZHkg aGF2ZSBiZWVuIGNvbW1pdHRlZCB0byB0aGUgcHJvdGVjdGlvbiBvZiwNCj4gICAgIGZvciBleGFt cGxlLCBhIGhpZ2hlciBwcmlvcml0eSB3b3JraW5nIHBhdGguDQo+DQo+ICAgICBORVc6DQo+DQo+ ICAgICChpiBiZWNhdXNlIHRoZXkgYWxyZWFkeSBoYXZlIGJlZW4gdXRpbGl6ZWQgZm9yIHRoZSBw cm90ZWN0aW9uIG9mLA0KPiAgICAgZm9yIGV4YW1wbGUsIGEgaGlnaGVyIHByaW9yaXR5IHdvcmtp bmcgcGF0aC4NCj4NCj4NCj4NCj4gICAgICgxMSkgU2VjdGlvbiA1LjIsIHRoZSBzZWNvbmQgYnVs bGV0IGl0ZW06DQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICBSZXNvdXJjZXMgb2YgdGhlIHNoYXJl ZCBzZWdtZW50cyBTSEFMTCBiZSBjb21taXR0ZWQgdG8gdGhlDQo+DQo+ICAgICBwcm90ZWN0aW9u IHBhdGggoaYNCj4NCj4gICAgIE5FVzoNCj4NCj4gICAgIFJlc291cmNlcyBvZiB0aGUgc2hhcmVk IHNlZ21lbnRzIFNIQUxMIGJlIHV0aWxpemVkIGJ5IHRoZQ0KPg0KPiAgICAgcHJvdGVjdGlvbiBw YXRoIKGmDQo+DQo+DQo+DQo+ICAgICAoMTIpIFNlY3Rpb24gNS4yLCB0aGUgdGhpcmQgYnVsbGV0 IGl0ZW06DQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICBJZiBtdWx0aXBsZSBwcm90ZWN0aW9uIHBh dGhzIG9mIGVxdWFsIHByaW9yaXR5IGFyZSByZXF1ZXN0aW5nDQo+DQo+ICAgICBhbGxvY2F0aW9u IG9mIHRoZSBzaGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2VzIFNIT1VMRCBiZQ0KPg0KPiAg ICAgY29tbWl0dGVkIG9uIGEgZmlyc3QgY29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMuDQo+DQo+ICAg ICBORVc6DQo+DQo+ICAgICBJZiBtdWx0aXBsZSBwcm90ZWN0aW9uIHBhdGhzIG9mIGVxdWFsIHBy aW9yaXR5IGFyZSByZXF1ZXN0aW5nDQo+DQo+ICAgICB0aGUgc2hhcmVkIHJlc291cmNlcywgdGhl IHJlc291cmNlcyBTSE9VTEQgYmUNCj4NCj4gICAgIGFzc2lnbmVkIG9uIGEgZmlyc3QgY29tZSBm aXJzdCBzZXJ2ZWQgYmFzaXMuDQo+DQo+DQo+DQo+ICAgICAoMTMpIFNlY3Rpb24gNS4yLCB0aGUg Zm91cnRoIGJ1bGxldCBpdGVtOg0KPg0KPiAgICAgT0xEOg0KPg0KPiAgICAgSWYgdGhlIHByb3Rl Y3Rpb24gcmVzb3VyY2VzIGFyZSBjb21taXR0ZWQgdG8gYSBwcm90ZWN0aW9uIHBhdGgsDQo+DQo+ ICAgICB3aG9zZSB3b3JraW5nIHBhdGggaGFzIGEgbG93ZXIgcHJpb3JpdHksIHJlc291cmNlcyBy ZXF1aXJlZCBmb3INCj4NCj4gICAgIHRoZSBoaWdoZXIgcHJpb3JpdHkgcGF0aCBTSEFMTCBiZSBj b21taXR0ZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eQ0KPg0KPiAgICAgcGF0aC4NCj4NCj4gICAg IE5FVzoNCj4NCj4gICAgIElmIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgdXRpbGl6ZWQg YnkgYSBwcm90ZWN0aW9uIHBhdGgsDQo+DQo+ICAgICB3aG9zZSB3b3JraW5nIHBhdGggaGFzIGEg bG93ZXIgcHJpb3JpdHksIHJlc291cmNlcyByZXF1aXJlZCBmb3INCj4NCj4gICAgIHRoZSBoaWdo ZXIgcHJpb3JpdHkgcGF0aCBTSEFMTCBiZSBhc3NpZ25lZCB0byB0aGUgaGlnaGVyIHByaW9yaXR5 DQo+DQo+ICAgICBwYXRoLg0KPg0KPg0KPg0KPg0KPg0KPiAgICAgKDE0KSBTZWN0aW9uIDUuMi4g dGhlIHNldmVudGggYnVsbGV0IGl0ZW0NCj4NCj4gICAgIE9MRDoNCj4NCj4gICAgIE9uY2UgcmVz b3VyY2VzIG9mIHNoYXJlZCBzZWdtZW50cyBoYXZlIGJlZW4gc3VjY2Vzc2Z1bGx5IGNvbW1pdHRl ZA0KPg0KPiAgICAgdG8gYSBwcm90ZWN0aW9uIHBhdGgsIKGmDQo+DQo+ICAgICBORVc6DQo+DQo+ ICAgICBPbmNlIHJlc291cmNlcyBvZiBzaGFyZWQgc2VnbWVudHMgaGF2ZSBiZWVuIHN1Y2Nlc3Nm dWxseSB1dGlsaXplZA0KPg0KPiAgICAgYnkgYSBwcm90ZWN0aW9uIHBhdGgsIKGmDQo+DQo+DQo+ DQo+ICAgICAoMTUpIFNlY3Rpb24gNS4zLCB0aGUgZmlyc3QgcGFyYWdyYXBoLA0KPg0KPiAgICAg T0xEOg0KPg0KPiAgICAgoaYgcmVxdWVzdCB0aGUgY29tbWl0bWVudCBvZiBwcm90ZWN0aW9uIHJl c291cmNlcy4gSWYgdGhlIG5lY2Vzc2FyeQ0KPg0KPiAgICAgc2hhcmVkIHJlc291cmNlcyBhcmUg dW5hdmFpbGFibGUgdG8gYmUgY29tbWl0dGVkIHRvIHRoZSBwcm90ZWN0aW9uDQo+DQo+ICAgICBw YXRoLCB0aGUgZW5kcG9pbnRzIKGmDQo+DQo+DQo+DQo+ICAgICBORVc6DQo+DQo+ICAgICChpiBy ZXF1ZXN0IHRoZSBjb29yZGluYXRpb24gb2YgdGhlIHNoYXJlZCByZXNvdXJjZSB1dGlsaXphdGlv bi4gSWYNCj4gICAgIHRoZSBuZWNlc3NhcnkNCj4NCj4gICAgIHNoYXJlZCByZXNvdXJjZXMgYXJl IHVuYXZhaWxhYmxlLCB0aGUgZW5kcG9pbnRzIKGmDQo+DQo+DQo+DQo+ICAgICAoMTYpIFNlY3Rp b24gNS4zLCB0aGUgc2Vjb25kIHBhcmFncmFwaCwNCj4NCj4gICAgIE9MRDoNCj4NCj4gICAgIFNp bWlsYXJseSwgaWYgcHJlZW1wdGlvbiBpcyBzdXBwb3J0ZWQgYW5kIHRoZSByZXNvdXJjZXMgY3Vy cmVudGx5DQo+DQo+ICAgICBjb21taXR0ZWQgZm9yIGEgcGFydGljdWxhciB3b3JraW5nIHBhdGgg YXJlIKGmDQo+DQo+ICAgICBORVc6DQo+DQo+ICAgICBTaW1pbGFybHksIGlmIHByZWVtcHRpb24g aXMgc3VwcG9ydGVkIGFuZCB0aGUgcmVzb3VyY2VzIGN1cnJlbnRseQ0KPg0KPiAgICAgdXRpbGl6 ZWQgYnkgYSBwYXJ0aWN1bGFyIHdvcmtpbmcgcGF0aCBhcmUgoaYNCj4NCj4NCj4NCj4NCj4NCj4g ICAgIC0gU2VjdGlvbiAyLCAxc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLiBUaGlzIHNlbnRl bmNlIHJlYWxseQ0KPiAgICAgZGVmaW5lcw0KPiAgICAgdGhlIHNjb3BlL3B1cnBvc2Ugb2YgdGhl IGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlvbnMNCj4gICAgIHRvIHBy b3RvY29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0aGUNCj4g ICAgIHJlcXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNoLCBJJ2Qg cmVwZWF0IHRoaXMgaW4NCj4gICAgIHRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUg cHJvbm91bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yDQo+ICAgICAzKS4NCj4NCj4gICAgIFtB dXRob3JzXSBXZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGF0IHRoZSBlbmQgb2Yg U2VjdGlvbiAxOg0KPg0KPiAgICAgobBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGNsYXJp ZnkgdGhlIGluc3RydWN0aW9ucyB0byBwcm90b2NvbA0KPiAgICAgZGVzaWduZXJzIHByb2R1Y2lu ZyBzb2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgc2V0DQo+ICAgICBvdXQg aW4gdGhpcyBkb2N1bWVudC6hsQ0KPg0KPg0KPg0KPg0KPiAgICAgLSBHZW5lcmFsIGNvbW1lbnQ6 IGZhdGUtc2hhcmluZyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQo+ICAgICBwcm90 ZWN0aW9uOiBIb3cgaXMgY28tcm91dGluZyBwcmVzZXJ2ZWQgZm9yIHRoZSByZXZlcnNlIHBhdGgg aW4gU01QPw0KPiAgICAgSSdkIGFzc3VtZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGNvb3JkaW5h dGlvbiBwcm90b2NvbCB3b3VsZCBiZQ0KPiAgICAgcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRj aG92ZXIgb2YgdGhlIHJldmVyc2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCj4gICAgIGNhc2UsIGJ1 dCBkb24ndCBzZWUgdGhpcyBpbiB0aGUgZG9jdW1lbnQuDQo+DQo+ICAgICBbQXV0aG9yc10gRmF0 ZS1zaGFyaW5nIGlzIG5vdCByZXF1aXJlZCBieSB0aGlzIGRvY3VtZW50LiBFdmVuIGluDQo+ICAg ICB0aGUgUFNDIGxpbmVhciBwcm90ZWN0aW9uIHN3aXRjaGluZywgc3VjaCBhcyBSRkMgNjM3OCAo UFNDKSBhbmQNCj4gICAgIFJGQyA3MjcxIChQU0MgaW4gQVBTIG1vZGUpLCBmYXRlLXNoYXJpbmcg aXMgbm90IHJlcXVpcmVkIGFzDQo+ICAgICB1bmlkaXJlY3Rpb25hbCBzd2l0Y2hpbmcgaXMgYWxs b3dlZC4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbXBvc2UNCj4gICAgIGFueSByZXN0cmljdGlv biBvbiBjby1yb3V0aW5nLCBlaXRoZXIuDQo+DQo+DQo+DQo+DQo+ICAgICAtIEluIHNlY3Rpb24g NCBhbmQgNS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBhcyBkZWZpbmluZw0KPiAgICAg cHJlZW1wdGlvbiB0ZXJtaW5vbG9neSBhbmQgYmVoYXZpb3IuIEkgdGhpbmsgNjM3MiBpcyB0aGUg cmlnaHQNCj4gICAgIHJlZmVyZW5jZSBoZXJlIGFzIGl0IGRlZmluZXMgYm90aCBpbiB0aGUgY29u dGV4dCBvZiBzdXJ2aXZhYmlsaXR5IGFuZA0KPiAgICAgaW4gZGVwZW5kZW50IG9mIGNvbnRyb2wg cGxhbmUuDQo+DQo+ICAgICBbQXV0aG9yc10gT25lIGNvbmNlcm4gaXMgdGhhdCBSRkMgNjM3MiBk ZXNjcmliZXMgYm90aCBzb2Z0IGFuZA0KPiAgICAgaGFyZCBwcmVlbXB0aW9ucyBpbiB0aGUgY29u dGV4dCBvZiBleHRyYSB0cmFmZmljLCB3aGljaCBpcyBub3QNCj4gICAgIGV4YWN0bHkgdGhlIGNh c2UgZm9yIFNNUC4NCj4NCj4NCj4NCj4NCj4gICAgIC0gSW4gc2VjdGlvbiA0LjIgeW91IHNheSAi VGhlcmVmb3JlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGJlDQo+ICAgICBjYXJyaWVkIG91 dCB1bmRlciB0aGUgY29udHJvbCBvZiBhIGR5bmFtaWMgY29udHJvbCBwbGFuZSBzaW1pbGFyIHRv DQo+ICAgICBHTVBMUyBbUkZDMzk0NV0uIiBwZXJoYXBzIHlvdSBtZWFuICJiYXNlZCBvbiBHTVBM UyI/IElmIHNvLCBncmVhdCwNCj4gICAgIHBsZWFzZSBtYWtlIHRoZSBjb3JyZWN0aW9uLiBJZiBu b3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBvZiB3aGljaA0KPiAgICAgY29udHJvbCBwcm90b2NvbCBp cyB1c2VkIGZvciBNUExTLVRQIGlzIHdheSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMNCj4gICAg IGRvY3VtZW50Lg0KPg0KPiAgICAgW0F1dGhvcnNdIFllcywgd2Ugd2lsbCBtYWtlIHRoZSBjb3Jy ZWN0aW9uLg0KPg0KPg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMSwgcGFyYWdyYXBoIDEuIFdo eSBhcmUgeW91IHVzaW5nICJTSE9VTEQgTk9UIiBoZXJlPyBJZg0KPiAgICAgcmVmZXJyaW5nIHRv IHNvbHV0aW9ucyBjb25mb3JtYW50IHdpdGggdGhpcyBkb2N1bWVudCwgdGhlbiB0aGVzZSBhcmUN Cj4gICAgIGluZm9ybWF0aXZlIHN0YXRlbWVudHMsICJhbmQgYSBub24tY29udHJvbCBwbGFuZSBi YXNlZCBTTVAgc3dpdGNob3Zlcg0KPiAgICAgbWVjaGFuaXNtIGlzIHVzZWQsIHRoZSBjb250cm9s IHBsYW5lIFNIQUxMIE5PVCAuLi4iLiBJZiByZWZlcnJpbmcgdG8NCj4gICAgIGFuIG9wZXJhdG9y J3MvdXNlcidzIGNob2ljZSBvZiBwcm90ZWN0aW9uIG1lY2hhbmlzbSwgSSB0aGluayB0aGUgbW9z dA0KPiAgICAgeW91IGNhbiBzYXkgaXMgTUFZLg0KPg0KPiAgICAgW0F1dGhvcnNdIFRoZSBmaXJz dCBjYXNlIGlzIHRoZSBvbmUgd2UgYXJlIGFpbWluZyBhdC4gV2Ugd2lsbCB1c2UNCj4gICAgIFNI QUxMIE5PVC4NCj4NCj4NCj4NCj4NCj4gICAgIC0gU2VjdGlvbiA1LjIuICJUaWUtYnJlYWtpbmcg cnVsZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVANCj4gICAgIGRvbWFpbi4i IEFzIHRoaXMgaXMgYSByZXF1aXJlbWVudCwgd2hhdCB5b3UgbWVhbiBieSAidGllLWJyZWFraW5n DQo+ICAgICBydWxlcyIgc2hvdWxkIGJlIGRlZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNl Lg0KPg0KPiAgICAgW0F1dGhvcnNdIFRoZSBzZW50ZW5jZSBjYW4gYmUgcmV3cml0dGVuIGFzOg0K Pg0KPiAgICAgT0xEOg0KPg0KPiAgICAgVGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmlu ZWQgaW4gc2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCj4NCj4gICAgIE5FVzoNCj4NCj4gICAgIElu IG9yZGVyIHRvIGNvdmVyIHRoZSBzaXR1YXRpb24gd2hlcmUgdGhlIGZpcnN0IGNvbWUgZmlyc3Qg c2VydmVkDQo+ICAgICBwcmluY2lwbGUgY2Fubm90IHJlc29sdmUgdGhlIGNvbnRlbnRpb24gYW1v bmcgbXVsdGlwbGUgZXF1YWwNCj4gICAgIHByaW9yaXR5IHJlcXVlc3RzLCBpLmUuLCB3aGVuIHRo ZSByZXF1ZXN0cyBvY2N1ciBzaW11bHRhbmVvdXNseSwsDQo+ICAgICB0aWUtYnJlYWtpbmcgcnVs ZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9tYWluLg0KPg0KPg0KPg0K Pg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMy4gUkZDNjM3MiB0YWtlcyBhbiBhcHByb2FjaCB3 aGVyZSBwcmVlbXB0aW9uIG5vdGlmaWNhdGlvbg0KPiAgICAgbGV2ZXJhZ2VzIHRoZSBzdGFuZGFy ZCBNUExTLVRQIE9BTSBtZWNoYW5pc21zLCBpcyB0aGVyZSBhbnkgcmVhc29uIHRvDQo+ICAgICBk byBtb3JlIC8gbm90IGp1c3QgZm9sbG93IDYzNzI/DQo+DQo+ICAgICBbQXV0aG9yc10gV2UgY2Fu IGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGF0IHRoZSBlbmQ6DQo+DQo+ICAgICChsEFzIGRl c2NyaWJlZCBpbiBbUkZDNjM3Ml0sIHRoZSBldmVudCBvZiBwcmVlbXB0aW9uIG1heSBiZQ0KPiAg ICAgZGV0ZWN0ZWQgYnkgT0FNIGFuZCByZXBvcnRlZCBhcyBhIGZhdWx0IG9yIGEgZGVncmFkYXRp b24gb2YNCj4gICAgIHRyYWZmaWMgZGVsaXZlcnkuobENCj4NCj4NCj4gICAgIC0gU2VjdGlvbiA1 LjcuIFRoZXJlIG1heSBiZSBjb29yZGluYXRpb24gcmVxdWlyZWQgb24NCj4gICAgIHNvZnQtcHJl ZW1wdGlvbiBhcw0KPiAgICAgd2VsbCAoZGVwZW5kaW5nIG9uIHRoZSBjcm9zcy1jb25uZWN0cyBl c3RhYmxpc2hlZCBkdXJpbmcgTFNQDQo+ICAgICBlc3RhYmxpc2htZW50KSBzbyBjb29yZGluYXRl ZCBzd2l0Y2hpbmcgc2hvdWxkIGJlIHN1cHBvcnRlZA0KPiAgICAgaW5kZXBlbmRlbnQgb2YgcHJl ZW1wdGlvbiBtb2RlLg0KPg0KPiAgICAgW0F1dGhvcnNdIFllcywgd2Ugd2lsbCBjaGFuZ2UgdGhl IHNlY29uZCBwYXJhZ3JhcGggZnJvbSChsFNNUCBpbg0KPiAgICAgaGFyZC1wcmVlbXB0aW9uIG1v ZGUgU0hPVUxEIKGmobEgdG8gobBTTVAgU0hPVUxEIKGmobEgYW5kIG1vdmUgdGhlDQo+ICAgICBj aGFuZ2VkIHBhcmFncmFwaCBhYm92ZSB0aGUgZmlyc3QgcGFyYWdyYXBoLg0KPg0KPg0KPg0KPg0K PiAgICAgTml0czoNCj4NCj4gICAgIC0gQWJzdHJhY3Q6IEkgZG9uJ3QgcmVjYWxsIHRoZSB0ZXJt ICJleGVjdXRpdmUgYWN0aW9uIiBiZWluZyB1c2VkDQo+ICAgICBpbiBhbnkNCj4gICAgIGVhcmxp ZXIgcmVsYXRlZC9yZWZlcmVuY2VkIFJGQ3MuIFJhdGhlciB0aGFuIGludHJvZHVjZSBhIG5ldyAo YW5kDQo+ICAgICB1bmRlZmluZWQpIHRlcm0sIHBlcmhhcHMgeW91IGNhbiB1c2UgYW4gZXhpc3Rp bmcgb25lLCBlLmcuLA0KPiAgICAgInByb3RlY3Rpb24gc3dpdGNoIj8NCj4NCj4gICAgIFtBdXRo b3JzXSBZZXMsIHRoZSB0ZXJtIHdpbGwgYmUgY2hhbmdlZCBhcyB5b3Ugc3VnZ2VzdGVkLg0KPg0K Pg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAxLiBEbyB3ZSByZWFsbHkgbmVl ZCBhbm90aGVyIGRlZmluaXRpb24gb2YNCj4gICAgIE1QTFMtVFAgdG8gZGViYXRlPyBJIHN1Z2dl c3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9yaXRlIE1QTFMtVFANCj4gICAgIGRvY3VtZW50 KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMuDQo+DQo+ICAgICBUaGUg bGFzdCBzZW50ZW5jZSBhbHNvIG1ha2VzIGEgc3ViamVjdGl2ZSBzdGF0ZW1lbnQuIFdoZXRoZXIg aXQgaXMNCj4gICAgIGNyaXRpY2FsIG9yIG5vIGlzIHVubmVjZXNzYXJ5LiBZb3UgY2FuIGp1c3Qg c2F5IHNvbWV0aGluZyBsaWtlIDYzNzINCj4gICAgIHByb3ZpZGVzIGEgc3Vydml2YWJpbGl0eSBm cmFtZXdvcmsgZm9yIE1QTFMtVFAgYW5kIGlzIHRoZSBmb3VuZGF0aW9uDQo+ICAgICBmb3IgdGhp cyBkb2N1bWVudC4NCj4NCj4gICAgIFtBdXRob3JzXSBUaGUgcHJvcG9zZWQgdGV4dCBmb3IgdGhl IHBhcmFncmFwaCAxIGlzOg0KPg0KPiAgICAgobBUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAo TVBMUy1UUCkgaXMgZGVzY3JpYmVkIGluIFtSRkM1OTIxXSwNCj4NCj4gICAgIGFuZCBbUkZDNjM3 Ml0gcHJvdmlkZXMgYSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1UUA0KPg0KPiAg ICAgYW5kIGlzIHRoZSBmb3VuZGF0aW9uIGZvciB0aGlzIGRvY3VtZW50LqGxDQo+DQo+DQo+DQo+ DQo+ICAgICAtIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElzbid0IHRoZSByaWdodCByZWZlcmVu Y2UgNDQyNyBub3QgNDQyOD8NCj4gICAgIEFsc28gZHJvcCB0aGUgd29yZCBsaW5lYXIsIGFzIGl0 IGlzIGFuIHVubmVjZXNzYXJ5IHF1YWxpZmllciBhbmQNCj4gICAgIDQ0MjcvNDQyOCBkb24ndCB1 c2UgaXQuDQo+DQo+ICAgICBbQXV0aG9yc10gT0suDQo+DQo+DQo+DQo+DQo+DQo+DQo+ICAgICAt IFNlY3Rpb25zIDMgKGFuZCB0byBhIGxlc3NlciBkZWdyZWUgc2VjdGlvbiAyKSBhcmUgcmVhbGx5 DQo+ICAgICBpbnRyb2R1Y3RvcnkNCj4gICAgIHRleHQuIEknbSB1bnN1cmUgYXMgdG8gd2h5IHRo ZXkgYXJlbid0IHBhcnQgb2Ygc2VjdGlvbiAxLg0KPg0KPiAgICAgW0F1dGhvcnNdIFNlY3Rpb24g MyB3YXMgaW50ZW5kZWQgdG8gcHJlc2VudCBhIHJlZmVyZW5jZSBtb2RlbCBmb3INCj4gICAgIFNN UC4gU29tZSB0ZXh0IG9mIFNlY3Rpb24gMiBpcyByZXBlYXRlZCBpbiBTZWN0aW9uIDEgYXMgeW91 DQo+ICAgICBzdWdnZXN0ZWQgZWFybGllci4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gICAgIC0gU2Vj dGlvbiAzLjIgc2hvdWxkIGhhdmUgYSByZWZlcmVuY2UgZm9yICJleGlzdGluZyBjb250cm9sIHBs YW5lDQo+ICAgICBzb2x1dGlvbnMgZm9yIFNNUCB3aXRoaW4gTVBMUyIuDQo+DQo+ICAgICBbQXV0 aG9yc10gW1JGQzQyMDZdIHdpbGwgYmUgYWRkZWQgYXMgYSByZWZlcmVuY2UNCj4NCj4NCj4gICAg IC0gU2VjdGlvbiAzLjIgYWdhaW4gdXNlcyB0aGUgImV4ZWN1dGl2ZSBhY3Rpb24iIHRlcm0uDQo+ DQo+ICAgICBbQXV0aG9yc10gT0ssIHRoZSB0ZXJtIHdpbGwgYmUgY2hhbmdlZC4NCj4NCj4NCj4N Cj4NCj4gICAgIC0gU2VjdGlvbiA0LjEuIFlvdSBzYXkgInR3byBvcGVyYXRpb25zIHNpbXVsdGFu ZW91c2x5Ii4gRG8geW91IHJlYWxseQ0KPiAgICAgbWVhbiAic2ltdWx0YW5lb3VzbHkiIG9yIG1l cmVseSB0aGF0IHRoZXkgbXVzdCBib3RoIG9jY3VyIGZvcg0KPiAgICAgcHJvdGVjdGlvbiB0byBi ZSBwcm92aWRlZD8gKFNhbWUgY29tbWVudCBpbiBzZWN0aW9uIDUuMS4NCj4NCj4gICAgIFtBdXRo b3JzXSBCb3RoIGFjdGlvbnMgc2hvdWxkIG9jY3VyIGF0IHRoZSBzYW1lIHRpbWUsIG9yIGFzDQo+ ICAgICBjbG9zZWx5IGFzIHBvc3NpYmxlIHRvIHByb3ZpZGUgZmFzdCBwcm90ZWN0aW9uLg0KPg0K Pg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMi4gSSBzdWdnZXN0IG51bWJlcmluZyB0aGUgY3Vy cmVudGx5IGJ1bGxldHRlZA0KPiAgICAgcmVxdWlyZW1lbnRzDQo+ICAgICBsaXN0Lg0KPg0KPiAg ICAgW0F1dGhvcnNdIE9LLCB3ZSB3aWxsIHVzZSBudW1iZXJzLg0KPg0KPg0KPg0KPg0KPiAgICAg LSBTZWN0aW9uIDUuMjogRmlyc3QgcGFyYWdyYXBoIGFuZCBmb3J0aCBidWxsZXQgbGFzdCBzZW50 ZW5jZS4gVGhlc2UNCj4gICAgIGJvdGggYmFzaWNhbGx5IGNvdmVyIHRoZSBzYW1lIHRvcGljIChw cmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkgc2F5DQo+ICAgICBzbGlnaHRseSBkaWZmZXJlbnQgdGhp bmdzLiBJIHN1Z2dlc3QgY29tYmluZSBpbnRvIGEgc2luZ2xlDQo+ICAgICByZXF1aXJlbWVudCB0 byBlbnN1cmUgY29uc2lzdGVuY3kgYW5kIGZ1bGwgY292ZXJhZ2Ugb2YgdGhlIHRvcGljLg0KPg0K PiAgICAgW0F1dGhvcnNdIFRoZSBmaXJzdCBwYXJhZ3JhcGggaXMgZm9yIHNvZnQtcHJlZW1wdGlv biwgd2hpbGUgdGhlDQo+ICAgICBmb3VydGggYnVsbGV0IGJlbG9uZ3MgdG8gdGhlIHJlcXVpcmVt ZW50cyBvZiBoYXJkLXByZWVtcHRpb24uDQo+DQo+DQo+ICAgICAtIFNlY3Rpb24gNS4yLCByZXEg NS4gSG93IGRvZXMgdGhpcyByZWxhdGUgdG8gc2VjdGlvbiA1LjU/IFNob3VsZG4ndA0KPiAgICAg dGhlIHRvcGljcyByZWxhdGVkIHRvIHRpbWluZyBiZSBjb25zb2xpZGF0ZWQ/DQo+DQo+ICAgICBb QXV0aG9yc10gWWVzLCByZXEgNSBjYW4gYmUgbW92ZWQgdG8gU2VjdGlvbiA1LjUuDQo+DQo+DQo+ DQo+DQo+ICAgICAtIFNlY3Rpb24gNS4yOiByZXF1aXJlbWVudCA2IHNlZW1zIHRvIGJlIGEgc3Vi c2V0IG9mIDcsIHNvIGl0DQo+ICAgICBzaG91bGQgYmUNCj4gICAgIGRyb3BwZWQuDQo+DQo+ICAg ICBbQXV0aG9yc10gWWVzLCBpdCB3aWxsIGJlIGRlbGV0ZWQuDQo+DQo+DQo+ICAgICAtIFNlY3Rp b24gNS4yLCByZXF1aXJlbWVudCA4LiBJc24ndCB0aGlzIGEgc3Vic2V0IG9mIDk/IFdoeSBjYWxs IG91dA0KPiAgICAganVzdCB0aGlzIG9uZSB0cmFmZmljIHRyZWF0bWVudCAoc3ViKSByZXF1aXJl bWVudD8NCj4NCj4gICAgIFtBdXRob3JzXSBSZXEuIDkgd2lsbCBiZSBkZWxldGVkIGFzIGl0IHNl ZW1zIHRvIHJlcXVpcmUgY29udHJvbA0KPiAgICAgcGxhbmUgc3VwcG9ydHMuDQo+DQo+DQo+DQo+ ICAgICAtIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsDQo+DQo+ICAgICBbQXV0aG9yc10gT0suDQo+ DQo+DQo+DQo+DQo+ICAgICAtIHNlY3Rpb24gNS40OiAiIFdoZW4gdGhlIHdvcmtpbmcgcGF0aCBk ZXRlY3RzLi4iIGRldGVjdGlvbiBpcyBieSB0aGUNCj4gICAgIG5vZGUgbm90IHRoZSBwYXRoLg0K Pg0KPiAgICAgW0F1dGhvcnNdIFllcy4gV2Ugd2lsbCBzaW1wbHkgc2F5IHRoYXQgobBXaGVuIHRo ZSBjb25kaXRpb24gdGhhdA0KPiAgICAgdHJpZ2dlcmVkIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGlu ZyBpcyBjbGVhcmVkLCChpqGxDQo+DQo+DQo+ICAgICAtIFNlY3Rpb24gNS40LCBsYXN0IHNlbnRl bmNlLiBUaGlzIGlzIG9ubHkgdGhlIDJuZCB0aW1lIHlvdSBpbXBseSB0aGF0DQo+ICAgICB0aGUg ZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBhIG5ldyBwcm90b2NvbC4gSSB0aGluayB0 aGlzDQo+ICAgICBwb2ludCBpcyBjdXJyZW50bHkgdG9vIHN1YnRsZSBpbiB0aGUgZG9jdW1lbnQu IChUaGlzIHBvaW50IHdhcyBhbHNvDQo+ICAgICBtYWRlIGFzIGEgbWlub3IgY29tbWVudC4pDQo+ DQo+ICAgICBbQXV0aG9yc10gQXMgaW4gb3RoZXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGVjaG5v bG9naWVzLCB0d28gbW9kZXMNCj4gICAgIG9mIG9wZXJhdGlvbnMgKHJldmVydGl2ZSBhbmQgbm9u LXJldmVydGl2ZSkgYXJlIHJlcXVpcmVkLg0KPg0KPg0KPg0KPg0KPiAgICAgLSBzZWN0aW9uIDUu Ni4gUkZDIDYzNzIgc2hvdWxkIGJlIHJlZmVyZW5jZWQNCj4NCj4gICAgIFtBdXRob3JzXSBXZSB3 aWxsIGFkZCChsGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3Ml2hsSB0byB0aGUgZW5kcyBvZg0KPiAg ICAgdHdvIHBhcmFncmFwaHMgZm9yIFdUUiB0aW1lciBhbmQgaG9sZC1vZmYgdGltZXIuDQo+DQo+ DQo+DQo+ICAgICAqKioqKiBFbmQgb2YgQ29tbWVudCByZXNvbHV0aW9uICoqKioqDQo+DQo+DQo+ DQo+DQo+DQo+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICq6uLO9ILvntvcgOiAqIkxv dSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0DQo+ICAgICA8bWFpbHRvOmxiZXJnZXJAbGFibi5u ZXQ+Pg0KPiAgICAgKrq4s70gs6/CpSA6ICoyMDE0LTA2LTIyIDAxOjAwOjQ4ICggKzA5OjAwICkN Cj4gICAgICq53rTCILvntvcgOiAqcnRnLWFkc0B0b29scy5pZXRmLm9yZw0KPiAgICAgPG1haWx0 bzpydGctYWRzQHRvb2xzLmlldGYub3JnPiA8cnRnLWFkc0B0b29scy5pZXRmLm9yZw0KPiAgICAg PG1haWx0bzpydGctYWRzQHRvb2xzLmlldGYub3JnPj4NCj4gICAgICrC/MG2IDogKnJ0Zy1kaXJA aWV0Zi5vcmcgPG1haWx0bzpydGctZGlyQGlldGYub3JnPg0KPiAgICAgPHJ0Zy1kaXJAaWV0Zi5v cmcgPG1haWx0bzpydGctZGlyQGlldGYub3JnPj4sDQo+ICAgICBkcmFmdC1pZXRmLW1wbHMtc21w LXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86ZHJhZnQtaWV0 Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnPg0KPiAgICAgPGRyYWZ0 LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZw0KPiAgICAgPG1h aWx0bzpkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmc+ PiwNCj4gICAgIG1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3JnPiA8bXBsc0BpZXRm Lm9yZw0KPiAgICAgPG1haWx0bzptcGxzQGlldGYub3JnPj4NCj4gICAgICrBprjxIDogKlttcGxz XSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50eHQN Cj4NCj4NCj4gICAgIEhlbGxvLA0KPg0KPiAgICAgSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMNCj4gICAgIGRyYWZ0LiBUaGUg Um91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3INCj4gICAg IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNh bGwgYW5kIElFU0cNCj4gICAgIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVl c3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMNCj4gICAgIHRvIHByb3ZpZGUgYXNzaXN0 YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uDQo+ICAgICBhYm91 dCB0aGUNCj4gICAgIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUNCj4gICAgIGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4NCj4gICAg IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IFJvdXRpbmcNCj4gICAgIEFEcywgaXQNCj4gICAgIHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNv dWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURg0KPiAgICAgTGFzdCBD YWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVt DQo+ICAgICB0aHJvdWdoDQo+ICAgICBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFm dC4NCj4NCj4gICAgIERvY3VtZW50OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0w Ni50eHQNCj4gICAgIFJldmlld2VyOiBMb3UgQmVyZ2VyDQo+ICAgICBSZXZpZXcgRGF0ZTogSnVu ZSAyMSAyMDE0DQo+ICAgICBJRVRGIExDIEVuZCBEYXRlOiAyMDE0LTA2LTIzDQo+ICAgICBJbnRl bmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWwNCj4NCj4gICAgIFN1bW1hcnk6DQo+ICAgICBJIGhh dmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluaw0K PiAgICAgc2hvdWxkIChtdXN0LCBhY3R1YWxseSkgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0 aW9uLg0KPg0KPiAgICAgQ29tbWVudHM6DQo+DQo+ICAgICBJIHRoaW5rIHRoZSBkb2N1bWVudCBp cyB3ZWxsIHdyaXR0ZW4gYW5kLCBvdGhlciB0aGFuIGEgY291cGxlIG9mDQo+ICAgICB0ZXJtaW5v bG9neSByZWxhdGVkIGlzc3VlcywgZWFzaWx5IHVuZGVyc3Rvb2QuIFRoZSBkb2N1bWVudCBkb2Vz DQo+ICAgICBoYXZlIGEgbnVtYmVyIG9mIHRlcm1pbm9sb2d5IGFuZCB0ZWNobmljYWwgaXNzdWVz IHdoaWNoIHNob3VsZCBiZQ0KPiAgICAgcmVhZGlseSByZXNvbHZlZCBwcmlvciB0byBwdWJsaWNh dGlvbi4NCj4NCj4gICAgIE1ham9yIElzc3VlczoNCj4NCj4gICAgIE1ham9yIGlzc3VlcyBhcmUg dGhlIHR5cGUgb2YgY29uY2VybnMgdGhhdCB3aWxsIHJlc3VsdCBpbiB0aGUNCj4gICAgIGRvY3Vt ZW50IGJlaW5nIGJsb2NrZWQgdW50aWwgdGhleSBhcmUgcmVzb2x2ZWQuIFRoZSBSb3V0aW5nIEFE cyB3aWxsDQo+ICAgICBiZWNvbWUgaW52b2x2ZWQuIFBsZWFzZSBpbmNsdWRlIGFsbCBvZiB0aGUg bWFqb3IgaXNzdWVzIHlvdSBoYXZlDQo+ICAgICBmb3VuZC4gR2l2ZSBhcyBtdWNoIGNvbnRleHQg aW5mb3JtYXRpb24gYXMgcG9zc2libGUgKGUuZy4sIHNlY3Rpb24NCj4gICAgIG51bWJlcnMsIHBh cmFncmFwaCBjb3VudHMpLiBJZiB5b3UgZmluZCBubyBtYWpvciBpc3N1ZXMsIHBsZWFzZQ0KPiAg ICAgd3JpdGU6ICJObyBtYWpvciBpc3N1ZXMgZm91bmQuIg0KPg0KPiAgICAgLSBObyBtYWpvciBp c3N1ZXMgZm91bmQuIEluIHBhcnRpY3VsYXIsIEkgZXhwZWN0IGFsbCBpc3N1ZXMgY2FuIGJlDQo+ ICAgICByZXNvbHZlZCB3aXRob3V0IEFEIGludGVydmVudGlvbi4gU29tZSBvZiB0aGUgbWlub3Ig aXNzdWVzLCBpZiBub3QNCj4gICAgIHJlc29sdmVkIHdpbGwgYmUgZXNjYWxhdGVkIHRvIHRoZSBB RC9tYWpvciBpc3N1ZSBjYXRlZ29yeS4NCj4NCj4gICAgIE1pbm9yIElzc3VlczoNCj4NCj4gICAg IE1pbm9yIGlzc3VlcyBhcmUgY29uY2VybnMgYWJvdXQgY2xhcml0eSBvciB0ZWNobmljYWwgYWNj dXJhY3kgdGhhdA0KPiAgICAgc2hvdWxkIGJlIGRpc2N1c3NlZCBhbmQgcmVzb2x2ZWQgYmVmb3Jl IHB1YmxpY2F0aW9uLCBidXQgd2hpY2ggd291bGQNCj4gICAgIG5vcm1hbGx5IGJlIHJlc29sdmVk IGJldHdlZW4gdGhlIGF1dGhvcnMgYW5kIHRoZSByZXZpZXdlcnMuIFBsZWFzZQ0KPiAgICAgaW5j bHVkZSBhbGwgb2YgdGhlIG1pbm9yIGlzc3VlcyB5b3UgaGF2ZSBmb3VuZC4gR2l2ZSBhcyBtdWNo IGNvbnRleHQNCj4gICAgIGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIChlLmcuLCBzZWN0aW9uIG51 bWJlcnMsIHBhcmFncmFwaCBjb3VudHMpLg0KPiAgICAgSWYgeW91IGZpbmQgbm8gbWlub3IgaXNz dWVzLCBwbGVhc2Ugd3JpdGU6ICJObyBtaW5vciBpc3N1ZXMgZm91bmQuIg0KPg0KPiAgICAgLSBE b2N1bWVudCdzIHVzYWdlIG9mICJjb21taXR0ZWQiIHZzICJhbGxvY2F0ZWQiIHJlc291cmNlczoN Cj4NCj4gICAgIEluIHNlY3Rpb24gMSB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgbm90aW9u IHRoYXQgdGhlDQo+ICAgICBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3Rv cmF0aW9uIGlzIGJhc2VkIG9uIHdoZW4NCj4gICAgIHJlc291cmNlcyBhcmUgImNvbW1pdHRlZCIu IFRoaXMgZGlmZmVyZW5jZSBmcm9tIHBhc3QNCj4gICAgIGRlZmluaXRpb24uIFJGQzQ0MjcgYW5k IDYzNzIgbWFrZSB0aGUgZGlzdGluY3Rpb24gdGhhdCBwcm90ZWN0aW9uDQo+ICAgICBhbmQgcmVz dG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3VyY2VzIGFyZSAqYWxsb2NhdGVkKiBu b3QNCj4gICAgICpjb21taXR0ZWQqLiBUbyBxdW90ZSBSRkMgNDQyNzoNCj4NCj4gICAgIFRoZSBk aXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIG1hZGUgYmFz ZWQNCj4gICAgIG9uIHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uIGRvbmUgZHVyaW5nIHRoZSByZWNv dmVyeSBMU1Avc3Bhbg0KPiAgICAgZXN0YWJsaXNobWVudC4gVGhlIGRpc3RpbmN0aW9uIGJldHdl ZW4gZGlmZmVyZW50IHR5cGVzIG9mDQo+ICAgICByZXN0b3JhdGlvbiBpcyBtYWRlIGJhc2VkIG9u IHRoZSBsZXZlbCBvZiByb3V0ZSBjb21wdXRhdGlvbiwNCj4gICAgIHNpZ25hbGluZywgYW5kIHJl c291cmNlIGFsbG9jYXRpb24gZHVyaW5nIHRoZSByZXN0b3JhdGlvbg0KPiAgICAgTFNQL3NwYW4g ZXN0YWJsaXNobWVudC4NCj4NCj4gICAgIFRoaXMgZGlmZmVyZW5jZSBhbHNvIGxlYWRzIHRvIGNv bWUgY29uZnVzZWQgc3RhdGVtZW50cyBpbiB0aGUNCj4gICAgIGRvY3VtZW50IGFzIHdlbGwgYXMg YW1iaWd1aXR5IGluIHRoZSB0ZXh0LCBpLmUuIGNvbmZ1c2lvbiBieSB0aGUNCj4gICAgIHJlYWRl ci4gVGhlIHRlcm0gImNvbW1pdHRlZCIgaXMgbm90IHRpZ2h0bHkgZGVmaW5lZCBpbiB0aGlzDQo+ ICAgICBkb2N1bWVudCAob3IgZWFybGllciB3b3JrKSBhbmQgaXMgdXNlZCBkaWZmZXJlbnRseSB0 aGFuIGhvdw0KPiAgICAgImFsbG9jYXRlZCIgaGFzIGJlZW4gdXNlZC4gQW4gZXhhbXBsZSBvZiB0 aGlzIGNhbiBiZSBmb3VuZCBpbg0KPiAgICAgU2VjdGlvbiAzLjEgd2hpY2ggc3RhdGVzOg0KPg0K PiAgICAgSG93ZXZlciwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcywgYXQgbGVhc3Qg Zm9yIHRoZQ0KPiAgICAgc2hhcmVkIHNlZ21lbnRzLCB3aWxsIG9ubHkgYmUgZmluYWxpemVkIHdo ZW4gdGhlIHByb3RlY3Rpb24NCj4gICAgIHBhdGggaXMgYWN0dWFsbHkgYWN0aXZhdGVkLiBUaGVy ZWZvcmUsIGZvciB0aGUgcHVyaXN0cyAtDQo+ICAgICByZWdhcmRpbmcgdGhlIHRlcm1pbm9sb2d5 IC0gU01QIGxpZXMgc29tZXdoZXJlIGJldHdlZW4NCj4gICAgIHByb3RlY3Rpb24gYW5kIHJlc3Rv cmF0aW9uLg0KPg0KPiAgICAgQm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1hdGljLiBJbiB0aGUg Zmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG8NCj4gICAgIGNvdmVyIGEgInByb3RlY3Rpb24gc3dp dGNoIiB3b3VsZCAiY29ubmVjdCIgdGhlIHByb3RlY3Rpb24gcGF0aA0KPiAgICAgYnV0IG5vdCB0 aGUgZWFybGllciAiYWxsb2NhdGlvbiIgb2YgcmVzb3VyY2VzLiAoUXVvdGVkIHRlcm1zIGFyZQ0K PiAgICAgdXNlZCBpbiBlYXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFz ZWQgb24gdGhlIG5ldw0KPiAgICAgZGlzdGluY3Rpb24gb2YgcHJvdGVjdGlvbiB2cy4gcmVzdG9y YXRpb24gYW5kIGlzIHVubmVjZXNzYXJ5IHdpdGgNCj4gICAgIHRoZSBleGlzdGluZyBkaXN0aW5j dGlvbi4NCj4NCj4gICAgIFRoaXMgaXNzdWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0 aGUgZG9jdW1lbnQgd2hlcmUNCj4gICAgICJjb21taXR0ZWQiIGlzIHVzZWQgYW5kIEknZCByZWNv bW1lbmQgdGhhdCBlYWNoIHNob3VsZCBiZSByZXBsYWNlZA0KPiAgICAgd2l0aCB0ZXJtaW5vbG9n eSB1c2VkIGluIHRoZSByZWZlcmVuY2VkIFJGQ3MsIGkuZS4sICJhbGxvY2F0aW9uIiwNCj4gICAg ICJjb25uZWN0aW9uIiwgImNyb3NzLWNvbm5lY3QiLCAicHJvdGVjdGlvbiBzd2l0Y2gob3Zlciki LCAuLi4NCj4NCj4gICAgIE5vdGUgSSdtICpub3QqIGhpZ2hsaWdodGluZyBhbGwgY2FzZXMgd2hl cmUgdGhlcmUgYXJlIHByb2JsZW1zIGluIHRoZQ0KPiAgICAgZG9jdW1lbnQgcmVsYXRlZCB0byB0 aGlzIGlzc3VlLiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcGxhY2VzIGluIHRoZQ0KPiAgICAgZG9j dW1lbnQgd2hlcmUgSSB0aGluayBpdCdzIHBvc3NpYmxlIHRoYXQgb25jZSB0aGlzIHRlcm1pbm9s b2d5DQo+ICAgICBhbWJpZ3VpdHkgaXMgY29ycmVjdGVkIHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1 YnN0YW50aXZlIGNvbW1lbnRzLg0KPg0KPiAgICAgLSBTZWN0aW9uIDIsIDFzdCBwYXJhZ3JhcGgs IGxhc3Qgc2VudGVuY2UuIFRoaXMgc2VudGVuY2UgcmVhbGx5DQo+ICAgICBkZWZpbmVzDQo+ICAg ICB0aGUgc2NvcGUvcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQsIGkuZS4sICJjbGFyaWZpZXMgdGhl IGluc3RydWN0aW9ucw0KPiAgICAgdG8gcHJvdG9jb2wgZGVzaWduZXJzIHByb2R1Y2luZyBzb2x1 dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZQ0KPiAgICAgcmVxdWlyZW1lbnRzIHNldCBvdXQgaW4gdGhp cyBkb2N1bWVudC4iIEFzIHN1Y2gsIEknZCByZXBlYXQgdGhpcyBpbg0KPiAgICAgdGhlIGFic3Ry YWN0IGFuZCBtb3ZlIGl0IHRvIGEgbW9yZSBwcm9ub3VuY2VkIHBsYWNlIGluIHNlY3Rpb24gMSAo b3INCj4gICAgIDMpLg0KPg0KPiAgICAgLSBHZW5lcmFsIGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBm b3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQo+ICAgICBwcm90ZWN0aW9uOiBIb3cgaXMg Y28tcm91dGluZyBwcmVzZXJ2ZWQgZm9yIHRoZSByZXZlcnNlIHBhdGggaW4gU01QPw0KPiAgICAg SSdkIGFzc3VtZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGNvb3JkaW5hdGlvbiBwcm90b2NvbCB3 b3VsZCBiZQ0KPiAgICAgcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJl dmVyc2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCj4gICAgIGNhc2UsIGJ1dCBkb24ndCBzZWUgdGhp cyBpbiB0aGUgZG9jdW1lbnQuDQo+DQo+ICAgICAtIEluIHNlY3Rpb24gNCBhbmQgNS4yIHlvdSBy ZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBhcyBkZWZpbmluZw0KPiAgICAgcHJlZW1wdGlvbiB0ZXJt aW5vbG9neSBhbmQgYmVoYXZpb3IuIEkgdGhpbmsgNjM3MiBpcyB0aGUgcmlnaHQNCj4gICAgIHJl ZmVyZW5jZSBoZXJlIGFzIGl0IGRlZmluZXMgYm90aCBpbiB0aGUgY29udGV4dCBvZiBzdXJ2aXZh YmlsaXR5IGFuZA0KPiAgICAgaW4gZGVwZW5kZW50IG9mIGNvbnRyb2wgcGxhbmUuDQo+DQo+ICAg ICAtIEluIHNlY3Rpb24gNC4yIHlvdSBzYXkgIlRoZXJlZm9yZSwgaXQgaXMgc3VnZ2VzdGVkIHRo YXQgdGhpcyBiZQ0KPiAgICAgY2FycmllZCBvdXQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBkeW5h bWljIGNvbnRyb2wgcGxhbmUgc2ltaWxhciB0bw0KPiAgICAgR01QTFMgW1JGQzM5NDVdLiIgcGVy aGFwcyB5b3UgbWVhbiAiYmFzZWQgb24gR01QTFMiPyBJZiBzbywgZ3JlYXQsDQo+ICAgICBwbGVh c2UgbWFrZSB0aGUgY29ycmVjdGlvbi4gSWYgbm90LCBJIHRoaW5rIHRoZSBkZWJhdGUgb2Ygd2hp Y2gNCj4gICAgIGNvbnRyb2wgcHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBpcyB3YXkgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGlzDQo+ICAgICBkb2N1bWVudC4NCj4NCj4gICAgIC0gU2VjdGlv biA1LjEsIHBhcmFncmFwaCAxLiBXaHkgYXJlIHlvdSB1c2luZyAiU0hPVUxEIE5PVCIgaGVyZT8g SWYNCj4gICAgIHJlZmVycmluZyB0byBzb2x1dGlvbnMgY29uZm9ybWFudCB3aXRoIHRoaXMgZG9j dW1lbnQsIHRoZW4gdGhlc2UgYXJlDQo+ICAgICBpbmZvcm1hdGl2ZSBzdGF0ZW1lbnRzLCAiYW5k IGEgbm9uLWNvbnRyb2wgcGxhbmUgYmFzZWQgU01QIHN3aXRjaG92ZXINCj4gICAgIG1lY2hhbmlz bSBpcyB1c2VkLCB0aGUgY29udHJvbCBwbGFuZSBTSEFMTCBOT1QgLi4uIi4gSWYgcmVmZXJyaW5n IHRvDQo+ICAgICBhbiBvcGVyYXRvcidzL3VzZXIncyBjaG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNo YW5pc20sIEkgdGhpbmsgdGhlIG1vc3QNCj4gICAgIHlvdSBjYW4gc2F5IGlzIE1BWS4NCj4NCj4g ICAgIC0gU2VjdGlvbiA1LjIuICJUaWUtYnJlYWtpbmcgcnVsZXMgU0hBTEwgYmUgZGVmaW5lZCBp biBzY29wZSBvZiBhbiBTTVANCj4gICAgIGRvbWFpbi4iIEFzIHRoaXMgaXMgYSByZXF1aXJlbWVu dCwgd2hhdCB5b3UgbWVhbiBieSAidGllLWJyZWFraW5nDQo+ICAgICBydWxlcyIgc2hvdWxkIGJl IGRlZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNlLg0KPg0KPiAgICAgLSBTZWN0aW9uIDUu My4gUkZDNjM3MiB0YWtlcyBhbiBhcHByb2FjaCB3aGVyZSBwcmVlbXB0aW9uIG5vdGlmaWNhdGlv bg0KPiAgICAgbGV2ZXJhZ2VzIHRoZSBzdGFuZGFyZCBNUExTLVRQIE9BTSBtZWNoYW5pc21zLCBp cyB0aGVyZSBhbnkgcmVhc29uIHRvDQo+ICAgICBkbyBtb3JlIC8gbm90IGp1c3QgZm9sbG93IDYz NzI/DQo+DQo+ICAgICAtIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9uIHJl cXVpcmVkIG9uDQo+ICAgICBzb2Z0LXByZWVtcHRpb24gYXMNCj4gICAgIHdlbGwgKGRlcGVuZGlu ZyBvbiB0aGUgY3Jvc3MtY29ubmVjdHMgZXN0YWJsaXNoZWQgZHVyaW5nIExTUA0KPiAgICAgZXN0 YWJsaXNobWVudCkgc28gY29vcmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBiZSBzdXBwb3J0ZWQN Cj4gICAgIGluZGVwZW5kZW50IG9mIHByZWVtcHRpb24gbW9kZS4NCj4NCj4gICAgIE5pdHM6DQo+ DQo+ICAgICAtIEFic3RyYWN0OiBJIGRvbid0IHJlY2FsbCB0aGUgdGVybSAiZXhlY3V0aXZlIGFj dGlvbiIgYmVpbmcgdXNlZA0KPiAgICAgaW4gYW55DQo+ICAgICBlYXJsaWVyIHJlbGF0ZWQvcmVm ZXJlbmNlZCBSRkNzLiBSYXRoZXIgdGhhbiBpbnRyb2R1Y2UgYSBuZXcgKGFuZA0KPiAgICAgdW5k ZWZpbmVkKSB0ZXJtLCBwZXJoYXBzIHlvdSBjYW4gdXNlIGFuIGV4aXN0aW5nIG9uZSwgZS5nLiwN Cj4gICAgICJwcm90ZWN0aW9uIHN3aXRjaCI/DQo+DQo+ICAgICAtIFNlY3Rpb24gMSwgcGFyYWdy YXBoIDEuIERvIHdlIHJlYWxseSBuZWVkIGFub3RoZXIgZGVmaW5pdGlvbiBvZg0KPiAgICAgTVBM Uy1UUCB0byBkZWJhdGU/IEkgc3VnZ2VzdCBqdXN0IHJlZmVyZW5jaW5nIHlvdXIgZmF2b3JpdGUg TVBMUy1UUA0KPiAgICAgZG9jdW1lbnQocykgYW5kIGRyb3BwaW5nIHRoZSBmaXJzdCBmb3VyIHNl bnRlbmNlcy4NCj4NCj4gICAgIFRoZSBsYXN0IHNlbnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0 aXZlIHN0YXRlbWVudC4gV2hldGhlciBpdCBpcw0KPiAgICAgY3JpdGljYWwgb3Igbm8gaXMgdW5u ZWNlc3NhcnkuIFlvdSBjYW4ganVzdCBzYXkgc29tZXRoaW5nIGxpa2UgNjM3Mg0KPiAgICAgcHJv dmlkZXMgYSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1UUCBhbmQgaXMgdGhlIGZv dW5kYXRpb24NCj4gICAgIGZvciB0aGlzIGRvY3VtZW50Lg0KPg0KPiAgICAgLSBTZWN0aW9uIDEs IHBhcmFncmFwaCAzLiBJc24ndCB0aGUgcmlnaHQgcmVmZXJlbmNlIDQ0Mjcgbm90IDQ0Mjg/DQo+ ICAgICBBbHNvIGRyb3AgdGhlIHdvcmQgbGluZWFyLCBhcyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBx dWFsaWZpZXIgYW5kDQo+ICAgICA0NDI3LzQ0MjggZG9uJ3QgdXNlIGl0Lg0KPg0KPiAgICAgLSBT ZWN0aW9ucyAzIChhbmQgdG8gYSBsZXNzZXIgZGVncmVlIHNlY3Rpb24gMikgYXJlIHJlYWxseQ0K PiAgICAgaW50cm9kdWN0b3J5DQo+ICAgICB0ZXh0LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0aGV5 IGFyZW4ndCBwYXJ0IG9mIHNlY3Rpb24gMS4NCj4NCj4gICAgIC0gU2VjdGlvbiAzLjIgc2hvdWxk IGhhdmUgYSByZWZlcmVuY2UgZm9yICJleGlzdGluZyBjb250cm9sIHBsYW5lDQo+ICAgICBzb2x1 dGlvbnMgZm9yIFNNUCB3aXRoaW4gTVBMUyIuDQo+DQo+ICAgICAtIFNlY3Rpb24gMy4yIGFnYWlu IHVzZXMgdGhlICJleGVjdXRpdmUgYWN0aW9uIiB0ZXJtLg0KPg0KPiAgICAgLSBTZWN0aW9uIDQu MS4gWW91IHNheSAidHdvIG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3UgcmVhbGx5 DQo+ICAgICBtZWFuICJzaW11bHRhbmVvdXNseSIgb3IgbWVyZWx5IHRoYXQgdGhleSBtdXN0IGJv dGggb2NjdXIgZm9yDQo+ICAgICBwcm90ZWN0aW9uIHRvIGJlIHByb3ZpZGVkPyAoU2FtZSBjb21t ZW50IGluIHNlY3Rpb24gNS4xLg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMi4gSSBzdWdnZXN0IG51 bWJlcmluZyB0aGUgY3VycmVudGx5IGJ1bGxldHRlZA0KPiAgICAgcmVxdWlyZW1lbnRzDQo+ICAg ICBsaXN0Lg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMjogRmlyc3QgcGFyYWdyYXBoIGFuZCBmb3J0 aCBidWxsZXQgbGFzdCBzZW50ZW5jZS4gVGhlc2UNCj4gICAgIGJvdGggYmFzaWNhbGx5IGNvdmVy IHRoZSBzYW1lIHRvcGljIChwcmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkgc2F5DQo+ICAgICBzbGln aHRseSBkaWZmZXJlbnQgdGhpbmdzLiBJIHN1Z2dlc3QgY29tYmluZSBpbnRvIGEgc2luZ2xlDQo+ ICAgICByZXF1aXJlbWVudCB0byBlbnN1cmUgY29uc2lzdGVuY3kgYW5kIGZ1bGwgY292ZXJhZ2Ug b2YgdGhlIHRvcGljLg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRo aXMgcmVsYXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3QNCj4gICAgIHRoZSB0b3BpY3MgcmVs YXRlZCB0byB0aW1pbmcgYmUgY29uc29saWRhdGVkPw0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMjog cmVxdWlyZW1lbnQgNiBzZWVtcyB0byBiZSBhIHN1YnNldCBvZiA3LCBzbyBpdA0KPiAgICAgc2hv dWxkIGJlDQo+ICAgICBkcm9wcGVkLg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1l bnQgOC4gSXNuJ3QgdGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCj4gICAgIGp1c3Qg dGhpcyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/DQo+DQo+ICAgICAt IFNlY3Rpb24gNS4zLiBzL01BWS93aWxsDQo+DQo+ICAgICAtIHNlY3Rpb24gNS40OiAiIFdoZW4g dGhlIHdvcmtpbmcgcGF0aCBkZXRlY3RzLi4iIGRldGVjdGlvbiBpcyBieSB0aGUNCj4gICAgIG5v ZGUgbm90IHRoZSBwYXRoLg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuNCwgbGFzdCBzZW50ZW5jZS4g VGhpcyBpcyBvbmx5IHRoZSAybmQgdGltZSB5b3UgaW1wbHkgdGhhdA0KPiAgICAgdGhlIGRvY3Vt ZW50IGNvdmVycyByZXF1aXJlbWVudHMgb24gYSBuZXcgcHJvdG9jb2wuIEkgdGhpbmsgdGhpcw0K PiAgICAgcG9pbnQgaXMgY3VycmVudGx5IHRvbyBzdWJ0bGUgaW4gdGhlIGRvY3VtZW50LiAoVGhp cyBwb2ludCB3YXMgYWxzbw0KPiAgICAgbWFkZSBhcyBhIG1pbm9yIGNvbW1lbnQuKQ0KPg0KPiAg ICAgLSBzZWN0aW9uIDUuNi4gUkZDIDYzNzIgc2hvdWxkIGJlIHJlZmVyZW5jZWQNCj4NCj4NCj4g ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAg ICBtcGxzIG1haWxpbmcgbGlzdA0KPiAgICAgbXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+DQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4NCj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ICAgICBtcGxzIG1haWxpbmcgbGlzdA0KPiAgICAgbXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+DQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCj4NCg0K From nobody Thu Jul 10 08:50:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A9A1B28FA; Thu, 10 Jul 2014 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWuYOdLMt2ZP; Thu, 10 Jul 2014 06:43:39 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C81F1B28F1; Thu, 10 Jul 2014 06:43:38 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 Jul 2014 22:43:35 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 10 Jul 2014 22:43:32 +0900 From: =?utf-8?B?66WY7KCV64+Z?= To: "lberger@labn.net" Thread-Topic: =?utf-8?B?7ZqM7IugOiBbUlRHLURJUl0gW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0?= =?utf-8?Q?-ietf-mpls-smp-requirements-06.txt?= Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+gAHv9wCAB+MbNv//vcGAgACuW7U= Date: Thu, 10 Jul 2014 13:43:31 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749804@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info>, <53BE7F3B.9010005@labn.net> In-Reply-To: <53BE7F3B.9010005@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/vl1QTYE72XJWDqcMrqRRorGtYk0 X-Mailman-Approved-At: Thu, 10 Jul 2014 08:49:47 -0700 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] =?utf-8?b?7ZqM7IugOiDtmozsi6A6ICBbbXBsc10gUnRnRGlyIHJl?= =?utf-8?q?view=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:43:42 -0000 TG91LA0KDQpUaGFuayB5b3UgZm9yIGFncmVlaW5nIG9uIG1vc3Qgb2YgdGhlIHN1Z2dlc3Rpb25z Lg0KUGxlYXNlLCBzZWUgdGhlIGxpbmVzIHN0YXJ0aW5nIHdpdGggW0pSMl0gYmVsb3cuDQoNCkJl c3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCuuztOuCuCDsgqzrnow6IExvdSBCZXJnZXIgW2xiZXJnZXJAbGFibi5u ZXRdDQrrs7Trgrgg64Kg7KecOiAyMDE064WEIDfsm5QgMTDsnbwg66qp7JqU7J28IOyYpO2bhCA4 OjU1DQrrsJvripQg7IKs656MOiDrpZjsoJXrj5kNCuywuOyhsDogcnRnLWFkc0B0b29scy5pZXRm Lm9yZzsgcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMu YWxsQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnDQrsoJzrqqk6IFJlOiDtmozsi6A6IFtS VEctRElSXSBbbXBsc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJl bWVudHMtMDYudHh0DQoNCkplb25nLWRvbmcsDQpUaGFuayB5b3UgZm9yIHRoZSByZXNwb25zZSwg c2VlIGJlbG93Lg0KDQpPbiA3LzEwLzIwMTQgMjo1NSBBTSwg66WY7KCV64+ZIHdyb3RlOg0KPg0K PiBUaGFuayB5b3UsIExvdQ0KPg0KPiBQbGVhc2UsIHNlZSB0aGUgbGluZXMgc3RhcnRpbmcgd2l0 aCBbSlJdIGZvciBteSByZXNwb25zZXMgdG8geW91cg0KY29tbWVudHMuDQo+DQo+IEkgcmVtb3Zl ZCB0aGUgcGFydHMgdGhhdCB3ZSBoYXZlIGFscmVhZHkgYWdyZWVkIG9uLiBJIGFsc28gZXJhc2Vk IHlvdXINCmNvbW1lbnRzIHRoYXQgYXJlIG1pbm9yIGVkaXRvcmlhbCBhbmQgd2lsbCBiZSByZWZs ZWN0ZWQgaW4gdGhlIG5leHQNCnZlcnNpb24gYXMgeW91IHN1Z2dlc3RlZC4gVGhlIHR3byDigJxh c3NpZ25lZOKAnSByZWxhdGVkIGNvbW1lbnRzIGFyZSBub3QNCmNvdmVyZWQgaGVyZSBhcyB0aGV5 IGFyZSBiZWluZyBkaXNjdXNzZWQgd2l0aCBZYWFjb3YuDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4N Cj4gSmVvbmctZG9uZw0KPg0KPiAqKioqKioNCj4NCj4gKDQpIFBhZ2UgNywgdGhlIGZpcnN0IHBh cmFncmFwaDoNCj4gT0xEOg0KPiB0aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRo IGFyZSBmdWxseSBjb21taXR0ZWQsDQo+IE5FVw0KPiB0aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJv dGVjdGlvbiBwYXRoIGFyZSBmdWxseSBkZWRpY2F0ZWQsDQo+DQo+IERlZGljYXRlZCBpcyBhbHNv IGFuIGFtYmlndW91cyB0ZXJtLCBob3cgYWJvdXQ6DQo+IE9MRA0KPiAgICB0aGUgcmVzb3VyY2Vz IGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBjb21taXR0ZWQsIHRoZQ0KPiAgICBw cm90ZWN0aW9uIHBhdGggaW4gdGhlIGNhc2Ugb2YgU01QIGNvbnNpc3RzIG9mIHNlZ21lbnRzIHRo YXQgYXJlDQo+ICAgIGRlZGljYXRlZCB0byB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgcmVsYXRlZCB3 b3JraW5nIHBhdGggYW5kIGFsc28NCj4gTkVXDQo+ICAgIHRoZSByZXNvdXJjZXMgZm9yIHRoZSBw cm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGFsbG9jYXRlZCwgdGhlDQo+ICAgIHByb3RlY3Rpb24g cGF0aCBpbiB0aGUgY2FzZSBvZiBTTVAgY29uc2lzdHMgb2Ygc2VnbWVudHMgdGhhdCBhcmUNCj4g ICAgYWxsb2NhdGVkIHRvIHRoZSBwcm90ZWN0aW9uIG9mIHRoZSByZWxhdGVkIHdvcmtpbmcgcGF0 aCBhbmQgYWxzbw0KPg0KPiBbSlJdIFRoaXMgcGFyYWdyYXBoIGRlc2NyaWJlcyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIGxpbmVhciBwcm90ZWN0aW9uDQphbmQgc2hhcmVkIG1lc2ggcHJvdGVjdGlv biBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBwcm90ZWN0aW9uIHJlc291cmNlDQpzaGFyaW5nLiBJ biBsaW5lYXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIHRoZSByZXNvdXJjZXMgYXJlIG5vdCBzaGFy ZWQNCmJ1dCBkZWRpY2F0ZWQgdG8gdGhlIHByb3RlY3Rpb24gcGF0aC4gU01QIGhhcyBzaGFyZWQg cmVzb3VyY2VzIGluIHNvbWUNCnNlZ21lbnRzLiBJIHRoaW5rIHRoZSB3b3JkLCDigJxkZWRpY2F0 ZWTigJ0gaXMgZ2VuZXJhbCBlbm91Z2ggdG8gYmUgdXNlZA0Kd2l0aG91dCBhbnkgZnVydGhlciBk ZWZpbml0aW9uLiBSRkMgNjM3MiBhbHNvIHVzZXMg4oCcZGVkaWNhdGVk4oCcLCBhbmQgdGhpcw0K ZG9jdW1lbnQgZm9sbG93cyB0aGUgc2FtZSB1c2UgYXMgaW4gUkZDIDYzNzINCg0KSSB0aGluayB0 aGUgKG5ldykgZmlyc3QgdXNhZ2Ugb2YgZGVkaWNhdGVkIGluIHBhcmFncmFwaCBpcyBmaW5lLCBp dCdzDQp0aGUgc2Vjb25kIEkgaGF2ZSBhIHJlYWwgaXNzdWUgd2l0aC4gIEkgc3VnZ2VzdGVkIGNo YW5naW5nIGJvdGggdG8gYXZvaWQNCnRoZSB0ZXJtIGFsdG9nZXRoZXIuICBUaGUgd2F5ICJkZWRp Y2F0ZWQiIGlzIHVzZWQgaW4gdGhlIHNlY29uZCBzZW50ZW5jZQ0KaXMgaW4gdGhlIGNvbnRleHQg b2YgU01QLCB3aGlsZSBSRkM2MzcyIHVzZXMgImRlZGljYXRlZCIgIHRoZSBjb250ZXh0IG9mDQoi RGVkaWNhdGVkIFByb3RlY3Rpb24iIHdoaWNoIGlzIGNvbnRyYXN0ZWQgd2l0aCAiU2hhcmVkIFBy b3RlY3Rpb24iLg0KSG93IGFib3V0Og0KDQoNCk5FVw0KICAgdGhlIHJlc291cmNlcyBmb3IgdGhl IHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkgZGVkaWNhdGVkLCB0aGUNCiAgIHByb3RlY3Rpb24g cGF0aCBpbiB0aGUgY2FzZSBvZiBTTVAgY29uc2lzdHMgb2Ygc2VnbWVudHMgdGhhdCBhcmUNCiAg IHVzZWQgZm9yIHByb3RlY3Rpb24gb2YgdGhlIHJlbGF0ZWQgd29ya2luZyBwYXRoIGFuZCBhbHNv DQoNCltKUjJdIEkgYW0gb2sgd2l0aCB5b3VyIHByb3Bvc2VkIHRleHQuDQoNCj4NCj4NCj4gKDcp IFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4xOg0KPiBPTEQ6DQo+IFdoZW4gdGhl IHJlc2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSBjb21taXR0ZWQg dG8gYQ0KPiBwYXJ0aWN1bGFyIHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZm aWNpZW50IHJlc291cmNlcw0KPiBhdmFpbGFibGUgZm9yIGFuIGFkZGl0aW9uYWwgcHJvdGVjdGlv biBwYXRoLiBUaGlzIHRoZW4gaW1wbGllcyB0aGF0DQo+IGlmIGFub3RoZXIgd29ya2luZyBwYXRo IG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVjdGlvbg0KPiBzd2l0Y2gsIHRoZSBj b21taXRtZW50IG9mIHRoZSByZXNvdXJjZXMgbWF5IGZhaWwuIEluIG9yZGVyIHRvDQo+IG9wdGlt aXplIHRoZSBvcGVyYXRpb24gb2YgdGhlIGNvbW1pdG1lbnQgYW5kIHByZXBhcmluZyBmb3IgY2Fz ZXMgb2YNCj4gbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgY29tbWl0bWVudCBv ZiB0aGUgc2hhcmVkDQo+IHJlc291cmNlcyBhcmUgYmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0aGUg ZGlmZmVyZW50IHdvcmtpbmcgcGF0aHMgaW4NCj4gdGhlIFNNUCBuZXR3b3JrLg0KPiBORVc6DQo+ IFdoZW4gdGhlIHJlc2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSB1 dGlsaXplZCBieSBhDQo+IHBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVyZSBtYXkgbm90 IGJlIHN1ZmZpY2llbnQgcmVzb3VyY2VzDQo+IGF2YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25hbCBw cm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQNCj4gaWYgYW5vdGhlciB3b3Jr aW5nIHBhdGggb2YgdGhlIFNNUCBkb21haW4gdHJpZ2dlcnMgYSBwcm90ZWN0aW9uDQo+IHN3aXRj aCwgdGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiBtYXkgZmFpbC4gVGhlIGRp ZmZlcmVudA0Kd29ya2luZyBwYXRocyBpbg0KPiB0aGUgU01QIG5ldHdvcmsgYXJlIGludm9sdmVk IGluIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24uDQo+DQo+DQo+IFRoaXMg aXMgZmluZSwgYnV0IEkgd29uZGVyIHdoeSB5b3UgYXJlIHVzaW5nICJyZXNvdXJjZSB1dGlsaXph dGlvbiIgdnMNCiJwcm90ZWN0aW9uIHN3aXRjaCI/ICh0aGlzIGlzIGFjdHVhbGx5IGEgYml0IG9m IGEgZ2VuZXJhbCBjb21tZW50IC0tIEkNCnRoZSBsYXR0ZXIgaXMgYW4gZXhpc3RpbmcgYXBwbGlj YWJsZSB0ZXJtIHRoYXQgd291bGQgaGVscCByZWFkZXJzIGhvdw0KdGhpcyBkb2N1bWVudCBmaXRz IGluIHRvIHRoZSB0ZWNobm9sb2d5IHNwYWNlLikNCj4NCj4gW0pSXSBBcyBkZXNjcmliZWQgaW4g YW4gZWFybGllciBwYXJ0IG9mIHRoaXMgc2VjdGlvbiwgU01QIHByb3RlY3Rpb24NCmNvbnNpc3Rz IG9mIHR3byBvcGVyYXRpb25zOiB0cmFmZmljIHN3aXRjaG92ZXIgYW5kIHJlc291cmNlIHV0aWxp emF0aW9uDQpjb29yZGluYXRpb24uIFRoZSBzZW50ZW5jZXMgYXJlIGFib3V0IHRoZSByZXNvdXJj ZSB1dGlsaXphdGlvbg0KY29vcmRpbmF0aW9uLCBhbmQg4oCccmVzb3VyY2UgdXRpbGl6YXRpb27i gJ0gc2VlbXMgdG8gYmUgbW9yZSBhY2N1cmF0ZS4NCg0KSXMgInJlc291cmNlIHV0aWxpemF0aW9u IGNvb3JkaW5hdGlvbiIgZG9uZSB2aWEgc29tZSBmb3JtIG9mIGludGVyLW5vZGUNCmNvb3JkaW5h dGlvbj8gSWYgeWVzLCB0aGVuIEkgdGhpbmsgbXkgY29tbWVudCBob2xkcy4gIElmIG5vLCB0aGVu IEkNCnRoaW5rIHlvdSBzaG91bGQgZWxhYm90YXRlIG9uIGhvdyB0aGUgImNvb3JkaW5hdGlvbiIg aW4gdGhpcyBjYXNlDQpkaWZmZXJlcyBmcm9tIGhvdyB5b3UgdXNlICJjb29yZGluYXRpb24iIGVs c2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQuDQpFaXRoZXIgd2F5LCBJIHRoaW5rIHdlJ3ZlIGRpc2N1 c3NlZCB0aGlzIGVub3VnaCwgaS5lLiwgSSB3b24ndCBwdXNoIHRoaXMNCnBvaW50IGZ1cnRoZXIu DQoNCltKUjJdICJyZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yaW5hdGlvbiIgb2NjdXJzIGJldHdl ZW4gdGhlIG5vZGVzIGFzIGluIG90aGVyIHByb3RlY3Rpb24gc3dpdGNoaW5nLiAicmVzb3VyY2Ug dXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIiBpcyBhIHBhcnQgb2Ygd2hvbGUgU01QIHByb3RlY3Rp b24gc3dpdGNoaW5nIGNvb3JkaW5hdGlvbiBhbmQgaXMgbWVhbnQgdG8gZW1waGFzaXplIHRoYXQg Y29vcmRpbmF0aW9uIGlzIGZvciByZXNvdXJjZSB1dGlsaXphdGlvbi4gT2YgY291cnNlLCB0aGUg cmVhc29uIHdoeSBpdCBkb2VzIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiBpcyB0 byBjb21wbGV0ZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBldmVudHVhbGx5LiANCg0KDQo+DQo+DQo+ IC0gR2VuZXJhbCBjb21tZW50OiBmYXRlLXNoYXJpbmcgZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIExTUA0KPiBwcm90ZWN0aW9uOiBIb3cgaXMgY28tcm91dGluZyBwcmVzZXJ2ZWQgZm9yIHRo ZSByZXZlcnNlIHBhdGggaW4gU01QPw0KPiBJJ2QgYXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0 Y2ggY29vcmRpbmF0aW9uIHByb3RvY29sIHdvdWxkIGJlDQo+IHJlcXVpcmVkIHRvIHRyaWdnZXIg YSBzd2l0Y2hvdmVyIG9mIHRoZSByZXZlcnNlIExTUCBpbiB0aGUgY28tcm91dGVkDQo+IGNhc2Us IGJ1dCBkb24ndCBzZWUgdGhpcyBpbiB0aGUgZG9jdW1lbnQuDQo+IFtBdXRob3JzXSBGYXRlLXNo YXJpbmcgaXMgbm90IHJlcXVpcmVkIGJ5IHRoaXMgZG9jdW1lbnQuIEV2ZW4gaW4gdGhlDQpQU0Mg bGluZWFyIHByb3RlY3Rpb24gc3dpdGNoaW5nLCBzdWNoIGFzIFJGQyA2Mzc4IChQU0MpIGFuZCBS RkMgNzI3MQ0KKFBTQyBpbiBBUFMgbW9kZSksIGZhdGUtc2hhcmluZyBpcyBub3QgcmVxdWlyZWQg YXMgdW5pZGlyZWN0aW9uYWwNCnN3aXRjaGluZyBpcyBhbGxvd2VkLiBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IGltcG9zZSBhbnkgcmVzdHJpY3Rpb24gb24NCmNvLXJvdXRpbmcsIGVpdGhlci4NCj4N Cj4NCj4gQm90aCBSRkM0NDI3IGFuZCA2MzcyIG1lbnRpb24gdGhpcyAoQmktZGlyZWN0aW9uYWwg cmVjb3Zlcnkgc3dpdGNoaW5nDQppbiB0aGUgZm9ybWVyKS4gSSB0aGluayB0aGlzIGRvY3VtZW50 IHJlYWxseSBuZWVkcyB0byBtZW50aW9uIHNvbWV0aGluZw0Kb24gdGhlIHRvcGljLiAgR2l2ZW4g dGhlIDYzNzIgYSAiTUFZIiBsZXZlbCByZXF1aXJlbWVudCBpcyBwcm9iYWJseQ0Kc3VmZmljaWVu dCwgYnV0IHRoaXMgc2hvdWxkIGJlIGNvbmZpcm1lZCB3aXRoIHRoZSBXRy4gIChJIHBlcnNvbmFs bHkNCndvdWxkIGxpa2UgU0hPVUxEIGFzIHRoaXMgc2VlbXMgdG8gYmV0dGVyIG1hdGNoIDYzNzIn cyB0ZXh0ICJvcGVyYXRvcg0Kb2Z0ZW4gcmVxdWlyZXMuLi4iLikNCj4NCj4gW0pSXSBPLksuIEkg Z3Vlc3MgdGhhdCBtYW5kYXRpbmcgYmlkaXJlY3Rpb25hbCBzd2l0Y2hpbmcgZG9lcyBub3QgbWVh bg0KdGhhdCB1bmlkaXJlY3Rpb25hbCBzd2l0Y2hpbmcgaXMgcHJvaGliaXRlZC4gV2hhdCB3ZSBj YW4gZG8gaXMgdGhhdCwNCmFmdGVyIGNoYW5naW5nIHRoZSB0aXRsZSBvZiBTZWN0aW9uIDUuNC4g ZnJvbSDigJxSZXZlcnRpdmUgcHJvdGVjdGlvbg0Kc3dpdGNoaW5n4oCdIHRvIOKAnFJldmVyc2lv biBhbmQgRmF0ZS1zaGFyaW5n4oCdLCBvbmUgcGFyYWdyYXBoIHdpdGggdGhlDQpmb2xsb3dpbmcg c2VudGVuY2Ugd2lsbCBiZSBhZGRlZDog4oCcQmlkaXJlY3Rpb25hbCBwcm90ZWN0aW9uIHN3aXRj aGluZw0KU0hPVUxEIGJlIHN1cHBvcnRlZCBpbiBTTVAu4oCdDQoNClRoZSB0b3BpY3MgYXJlIGVz c2VudGlhbGx5IG9ydGhvZ25hbCwgaS5lLiwgc3VwcG9ydGluZyBvbmUgd2l0aG91dCB0aGUNCm90 aGVyIGlzIGNvbXBsZXRseSByZWFzb25hYmxlLiAgSWYgeW91IGRvbid0IHdhbnQgdG8gYWRkIGEg ZGVkaWNhdGVkDQpzZWN0aW9uLCB0aGVuIFNlY3Rpb25zIDUuNywgNS4zIGFuZCBwZXJoYXBzIGV2 ZW4gNS41IGFyZSBiZXR0ZXIgY2hvaWNlcy4NCg0KW0pSMl0gWWVzLCBJIGFsc28gdGhpbmsgdGhh dCB0aG9zZSBzZWN0aW9ucyB0aGF0IHlvdSBzdWdnZXN0ZWQgY2FuIGJlIGdvb2QgY2FuZGlkYXRl cyB0byBhY2NvbW1vZGF0ZSAiZmF0ZS1zaGFyaW5nIi4NCkkganVzdCBwaWNrZWQgdXAgNS40IGJl Y2F1c2UgaXQgY3VycmVudGx5IGhhcyBqdXN0IG9uZSBwYXJhZ3JhcGggYW5kIG1pZ2h0IGJlIGVh c2lsZXIgdG8gcGFyc2UgdGhlIHNlY3Rpb24gaWYgdHdvIHBhcmFncmFwaHMgYXJlIHRoZXJlLiBB bmQsIHJldmVydGl2ZS9ub24tcmV2ZXJ0aXZlIChtb2RlIG9mIG9wZXJhdGlvbikgYW5kIHVuaS0v YmktZGlyZWN0aW9uYWwgc3dpdGNoaW5nICh0eXBlIG9mIHN3aXRjaGluZykgYXJlIG9mdGVuIHVz ZWQgdG9nZXRoZXIgdG8gY2hhcmFjdGVyaXplIHRoZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBwcm9j ZXNzIHJ1bm5pbmcgb24gYSBwcm90ZWN0ZWQgZG9tYWluLiANCg0KDQo+DQo+DQo+IC0gSW4gc2Vj dGlvbiA0IGFuZCA1LjIgeW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRlZmluaW5nDQo+ IHByZWVtcHRpb24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMgdGhl IHJpZ2h0DQo+IHJlZmVyZW5jZSBoZXJlIGFzIGl0IGRlZmluZXMgYm90aCBpbiB0aGUgY29udGV4 dCBvZiBzdXJ2aXZhYmlsaXR5IGFuZA0KPiBpbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFuZS4N Cj4gW0F1dGhvcnNdIE9uZSBjb25jZXJuIGlzIHRoYXQgUkZDIDYzNzIgZGVzY3JpYmVzIGJvdGgg c29mdCBhbmQgaGFyZA0KcHJlZW1wdGlvbnMgaW4gdGhlIGNvbnRleHQgb2YgZXh0cmEgdHJhZmZp Yywgd2hpY2ggaXMgbm90IGV4YWN0bHkgdGhlDQpjYXNlIGZvciBTTVAuDQo+DQo+IFRoZW4gNjM3 MiBzaG91bGQgYmUgcmVmZXJlbmNlZCBhbmQgdGhlIGRpZmZlcmVuY2Ugc2hvdWxkIGJlIGRlc2Ny aWJlZC4NCiBPdGhlcndpc2UgcmVhZGVycyBhcmUgbGlrZWx5IHRvIHRoaW5rIHlvdSBqdXN0IHVz ZWQgdGhlIHdyb25nIHJlZmVyZW5jZQ0KYW5kIHRoYXQgNjM3MidzIHRleHQgYXBwbGllcy4gIDYz NzIgaXMgYWZ0ZXIgYWxsIHRpdGxlZCAiTVBMUy1UUA0KU3Vydml2YWJpbGl0eSBGcmFtZXdvcmsi Li4uDQo+DQo+IFtKUl0gTy5LLiA2MzcyIHdpbGwgYmUgcmVmZXJlbmNlZCBhbmQgd2UgY2FuIGFk ZCB0aGUgZm9sbG93aW5nDQpzZW50ZW5jZSBhcyB0aGUgdGhpcmQgc2VudGVuY2UgaW4gdGhlIHBh cmFncmFwaDog4oCcVGhlIHRyYWZmaWMgb2YgbG93ZXINCnByaW9yaXR5IHBhdGhzIGluIHRoaXMg ZG9jdW1lbnQgY2FuIGJlIHZpZXdlZCBhcyB0aGUgZXh0cmEgdHJhZmZpYyBiZWluZw0KcHJlZW1w dGVkIGluIFtSRkM2MzcyXS7igJ0NCg0KZ3JlYXQuDQoNCj4NCj4NCj4gLSBTZWN0aW9uIDQuMS4g WW91IHNheSAidHdvIG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3UgcmVhbGx5DQo+ IG1lYW4gInNpbXVsdGFuZW91c2x5IiBvciBtZXJlbHkgdGhhdCB0aGV5IG11c3QgYm90aCBvY2N1 ciBmb3INCj4gcHJvdGVjdGlvbiB0byBiZSBwcm92aWRlZD8gKFNhbWUgY29tbWVudCBpbiBzZWN0 aW9uIDUuMS4NCj4gW0F1dGhvcnNdIEJvdGggYWN0aW9ucyBzaG91bGQgb2NjdXIgYXQgdGhlIHNh bWUgdGltZSwgb3IgYXMgY2xvc2VseSBhcw0KcG9zc2libGUgdG8gcHJvdmlkZSBmYXN0IHByb3Rl Y3Rpb24uDQo+DQo+IFdoYXQgdGV4dCBjaGFuZ2UgaXMgcGxhbm5lZD8NCj4NCj4gW0pSXSBXZSBj YW4gZXJhc2Ug4oCcc2ltdWx0YW5lb3VzbHnigJ0gYW5kIGFkZCB0aGUgc2VudGVuY2UgKOKAnEJv dGgNCm9wZXJhdGlvbnMgc2hvdWxkIG9jY3VyIGF0IHRoZSBzYW1lIHRpbWUsIG9yIGFzIGNsb3Nl bHkgYXMgcG9zc2libGUgdG8NCnByb3ZpZGUgZmFzdCBwcm90ZWN0aW9uLuKAnSkgYXMgdGhlIHNl Y29uZCBzZW50ZW5jZSBvZiB0aGUgcGFyYWdyYXBoLg0KDQpXRk0uDQoNCj4NCj4NCj4NCj4gLSBT ZWN0aW9uIDUuMjogRmlyc3QgcGFyYWdyYXBoIGFuZCBmb3J0aCBidWxsZXQgbGFzdCBzZW50ZW5j ZS4gVGhlc2UNCj4gYm90aCBiYXNpY2FsbHkgY292ZXIgdGhlIHNhbWUgdG9waWMgKHByZWVtcHRp b24pIGFuZCBhY3R1YWxseSBzYXkNCj4gc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5ncy4gSSBzdWdn ZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZQ0KPiByZXF1aXJlbWVudCB0byBlbnN1cmUgY29uc2lz dGVuY3kgYW5kIGZ1bGwgY292ZXJhZ2Ugb2YgdGhlIHRvcGljLg0KPiBbQXV0aG9yc10gVGhlIGZp cnN0IHBhcmFncmFwaCBpcyBmb3Igc29mdC1wcmVlbXB0aW9uLCB3aGlsZSB0aGUgZm91cnRoDQpi dWxsZXQgYmVsb25ncyB0byB0aGUgcmVxdWlyZW1lbnRzIG9mIGhhcmQtcHJlZW1wdGlvbi4NCj4N Cj4gRG8geW91IHBsYW4gYSB0ZXh0IGNoYW5nZT8gICh0aGUgMXN0IHBhcmFncmFwaCBzaG91bGQg YmUgYSBsaXN0IGl0ZW0NCmFuZCBzb2Z0LXByZWVtcHRpb24gaXMgbWVudGlvbmVkIGFzIGEgcGFy ZW50aGV0aWNhbCAsIGFuZCB0aGUgZm9ydGgNCmRvZXNuJ3QgbWVudGlvbiBpdHMgc2NvcGUgYXMg aGFyZCBwcmVlbXB0aW9uLikNCj4NCj4gW0pSXSBPSy4gV2UgY2FuIG1ha2UgdGhlbSBjbGVhci4g SG93IGFib3V0IHRoZSBmb2xsb3dpbmcgYXJyYW5nZW1lbnQ/DQo+DQo+IDUuMi4gTXVsdGlwbGUg dHJpZ2dlcnMNCj4NCj4gSWYgbW9yZSB0aGFuIG9uZSB3b3JraW5nIHBhdGggaXMgdHJpZ2dlcmlu ZyBhIHByb3RlY3Rpb24gc3dpdGNoIHN1Y2gNCj4gdGhhdCBhIHByb3RlY3Rpb24gc2VnbWVudCBp cyBvdmVyc3Vic2NyaWJlZCwgdGhlcmUgYXJlIHR3byBkaWZmZXJlbnQNCj4gYWN0aW9ucyB0aGF0 IHRoZSBTTVAgbmV0d29yayBjYW4gY2hvb3NlIOKAkyBzb2Z0IHByZWVtcHRpb24gYW5kIGhhcmQN Cj4gcHJlZW1wdGlvbi4NCj4NCj4gNS4yLjEuIFNvZnQtcHJlZW1wdGlvbg0KPg0KPiBGb3IgbmV0 d29ya3MgdGhhdCBzdXBwb3J0IG11bHRpcGxleGluZyBwYWNrZXRzIG92ZXIgdGhlIHNoYXJlZA0K c2VnbWVudHMsIHRoZSByZXF1aXJlbWVudCBpczoNCj4NCj4gTyBBbGwgb2YgdGhlIHByb3RlY3Rp b24gcGF0aHMgTUFZIGJlIGFsbG93ZWQgdG8gc2hhcmUgdGhlIHJlc291cmNlcw0KPiBvZiB0aGUg c2hhcmVkIHNlZ21lbnRzDQo+DQo+IDUuMi4yIEhhcmQtcHJlZW1wdGlvbg0KPg0KPiBUaGVyZSBh cmUgbmV0d29ya3MgdGhhdCByZXF1aXJlIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBwcm90ZWN0 aW9uDQo+IHJlc291cmNlcyB3aGVuIGEgcHJvdGVjdGlvbiBzZWdtZW50IGlzIG92ZXJzdWJzY3Jp YmVkLg0KPiBUcmFmZmljIG9mIGxvd2VyIHByaW9yaXR5IHBhdGhzIGlzIGNvbXBsZXRlbHkgYmxv Y2tlZC4NCj4gVGhlc2UgaW5jbHVkZSBuZXR3b3JrcyB0aGF0IHN1cHBvcnQgdGhlIHJlcXVpcmVt ZW50cyBpbiBbUkZDNTY1NF0sDQo+IGFuZCBpbiBwYXJ0aWN1bGFyIHN1cHBvcnQgcmVxdWlyZW1l bnQgNTguIEZvciBzdWNoIG5ldHdvcmtzLA0KPiB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cyBh cHBseToNCj4NCj4gTyAuLi4NCj4NCj4gTyAuLi4NCj4NCg0KSSB0aGluayB0aGlzIHdpbGwgd29y ay4NCg0KVGhhbmtzLA0KTG91DQoNCi4uLg0KDQo= From nobody Thu Jul 10 08:50:11 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459B31A0546; Thu, 10 Jul 2014 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.402 X-Spam-Level: X-Spam-Status: No, score=-95.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olgaexeln03G; Thu, 10 Jul 2014 07:01:19 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F002B1A0527; Thu, 10 Jul 2014 07:01:18 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 Jul 2014 23:01:16 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Thu, 10 Jul 2014 23:01:13 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger , Yaacov Weingarten Thread-Topic: =?ks_c_5601-1987?B?yLi9xTogW1JURy1ESVJdIFttcGxzXSBSdGdEaXIgcmV2aWV3OiBk?= =?ks_c_5601-1987?Q?raft-ietf-mpls-smp-requirements-06.txt?= Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+gAI5dwCABCIRAIADfBBe//+7pICAALQH1Q== Date: Thu, 10 Jul 2014 14:01:13 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2874981D@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> , <53BBCE48.7060008@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749725@SMTP2.etri.info>, <53BE8141.1050506@labn.net> In-Reply-To: <53BE8141.1050506@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/4tv9jgpZjhkXBDQQMJ2lNOpVC34 X-Mailman-Approved-At: Thu, 10 Jul 2014 08:49:48 -0700 Cc: "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogyLi9xTogIFttcGxzXSBSdGdEaXIgcmV2aWV3?= =?euc-kr?q?=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:01:23 -0000 TG91LA0KDQpUaGV5IGFyZSBtZWFudCB0byBiZSB1bmRlciB0aGUgaGFyZC1wcmVlbXB0aW9uLg0K QW5kLCB5b3UgYXJlIHJpZ2h0LiBUaGV5IGFyZSBubyBnb29kLiANCihJIGp1c3QgdHJpZWQgdG8g a2VlcCB3aGF0IGhhdmUgYmVlbiB0aGVyZSBiZWZvcmUuKQ0KDQpOZXcgc3VnZ2VzdGlvbnM6IA0K PT09PT09DQpvIElmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkg YXJlIHJlcXVlc3RpbmcNCiAgIHRoZSBzaGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2VzIFNI QUxMIGJlDQogICB1dGlsaXplZCBvbiBhIGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzLg0K ICAgVHJhZmZpYyBvZiB0aGUgcHJvdGVjdGlvbiBwYXRocyB0aGF0IHJlcXVlc3QgdGhlIHNoYXJl ZCByZXNvdXJjZSBsYXRlDQogICBTSEFMTCBiZSBibG9ja2VkLg0KICAgSW4gb3JkZXIgdG8gY292 ZXIgdGhlIHNpdHVhdGlvbiB3aGVyZSB0aGUgZmlyc3QgY29tZSBmaXJzdCBzZXJ2ZWQgcHJpbmNp cGxlDQogICBjYW5ub3QgcmVzb2x2ZSB0aGUgY29udGVudGlvbiBhbW9uZyBtdWx0aXBsZSBlcXVh bCBwcmlvcml0eSByZXF1ZXN0cywNCiAgIGkuZS4sIHdoZW4gdGhlIHJlcXVlc3RzIG9jY3VyIHNp bXVsdGFuZW91c2x5LCB0aWUtYnJlYWtpbmcgcnVsZXMNCiAgIFNIQUxMIGJlIGRlZmluZWQgaW4g c2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCg0KbyBJZiBhIGhpZ2hlciBwcmlvcml0eSBwYXRoIHJl cXVpcmVzIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyB0aGF0IGFyZQ0KICAgYmVpbmcgdXRpbGl6 ZWQgYnkgYSBsb3dlciBwcmlvcml0eSBwYXRoLCB0aGUgcmVzb3VyY2VzIFNIQUxMIGJlDQogICB1 dGlsaXplZCBieSB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGguDQogICBUcmFmZmljIHdpdGggdGhl IGxvd2VyIHByaW9yaXR5IFNIQUxMIGJlIGJsb2NrZWQuIA0KPT09PT09DQoNCllhYWNvdiBhbmQg Y28tYXV0aG9yczoNClNlZSBpZiBuZXcgdGV4dHMgYXJlIG9rLg0KDQoNCg0KQmVzdCByZWdhcmRz LA0KDQpKZW9uZy1kb25nDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KurizvSC757b3OiBMb3UgQmVyZ2VyIFtsYmVyZ2VyQGxhYm4ubmV0XQ0Kuriz vSCzr8KlOiAyMDE0s+IgN7/5IDEwwM8guPG/5MDPIL/AyMQgOTowNA0Kud60wiC757b3OiC3+cGk tb87IFlhYWNvdiBXZWluZ2FydGVuDQrC/MG2OiBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1w bHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1hZHNAdG9vbHMuaWV0 Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmcNCsGmuPE6IFJlOiDIuL3FOiBbUlRHLURJUl0gW21wbHNd IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0K DQpKZW9uZy1kb25nLA0KDQpEaWQgeW91IHBlcmhhcHMgbWVhbiB0aGF0IHRoZXNlIG5ldyBwYXJh Z3JhcGhzIHdvdWxkIGJlIHVuZGVyIHRoZQ0Kc29mdC1wcmVlbXB0aW9uIHNlY3Rpb24/IElmIHNv LCBzb3VuZHMgZmluZS4gSWYgbm90LCBhbGxvd2luZyB1c2Ugb2YNCmF2YWlsYWJsZSByZXNvdXJj ZXMgYnkgdGhlICJoYXJkLXBlZW1wdGVkIiB0cmFmZmljIHJ1bnMgY291bnRlciB0byBSRkM2Mzcy Og0KDQotIEluICJoYXJkIHByZWVtcHRpb24iLCB0aGUgZXh0cmEgdHJhZmZpYyBpcyBleGNsdWRl ZCBmcm9tIHRoZQ0KcHJvdGVjdGlvbiByZXNvdXJjZS4gVGhlIGRpc3J1cHRpb24gb2YgdGhlIGV4 dHJhIHRyYWZmaWMgaXMgdG90YWwsDQphbmQgdGhlIHNlcnZpY2Ugc3VwcG9ydGVkIGJ5IHRoZSBl eHRyYSB0cmFmZmljIG11c3QgYmUgZHJvcHBlZCwgb3INCnNvbWUgZm9ybSBvZiByZXJvdXRpbmcg b3IgcmVzdG9yYXRpb24gbXVzdCBiZSBhcHBsaWVkIHRvIHRoZSBleHRyYQ0KdHJhZmZpYyBMU1Ag aW4gb3JkZXIgdG8gcmVjb3ZlciB0aGUgc2VydmljZS4NCg0KLi4uDQoNCi0gSW4gInNvZnQgcHJl ZW1wdGlvbiIsIHRoZSBleHRyYSB0cmFmZmljIGlzIG5vdCBleHBsaWNpdGx5IGV4Y2x1ZGVkDQpm cm9tIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlLCBidXQgaXMgZ2l2ZW4gbG93ZXIgcHJpb3JpdHkg dGhhbiB0aGUNCnByb3RlY3RlZCB0cmFmZmljLiBJbiBhIHBhY2tldCBuZXR3b3JrIChzdWNoIGFz IE1QTFMtVFApLCB0aGlzIGNhbg0KcmVzdWx0IGluIG92ZXJzdWJzY3JpcHRpb24gb2YgdGhlIHBy b3RlY3Rpb24gcmVzb3VyY2Ugd2l0aCB0aGUNCnJlc3VsdCB0aGF0IHRoZSBleHRyYSB0cmFmZmlj IHJlY2VpdmVzICJiZXN0LWVmZm9ydCIgZGVsaXZlcnkuDQoNCkxvdQ0KDQpPbiA3LzEwLzIwMTQg Mzo1MiBBTSwgt/nBpLW/IHdyb3RlOg0KPiBMb3UgYW5kIFlhYWNvdiwNCj4NCj4gSGVyZSBpcyBt eSBzdWdnZXN0aW9uIG9uIHRob3NlIHR3byBidWxsZXQgaXRlbSB0ZXh0cyByZWxhdGVkIHRvICJh c3NpZ25lZCIuDQo+DQo+IEFzIGluIG15IGVhcmxpZXIgZW1haWwgdG8gTG91J3MgZm9sbG93dXAg Y29tbWVudHMsDQo+IHdlIGNhbiBtYWtlIHR3byBzdWIgc2VjdGlvbnMgdW5kZXIgdGhpcyBTZWN0 aW9uIDUuMi4NCj4gYW5kIHRpdGxlIHRoZW0gYXMgIjUuMi4xIFNvZnQgcHJlZW1wdGlvbiIgYW5k ICI1LjIuMiBIYXJkIHByZWVtcHRpb24iLg0KPiBUaG9zZSB0d28gYnVsbGV0IGl0ZW1zIHdpdGgg ImFzc2lnbmVkIiB3aWxsIGJlIHBsYWNlZCB1bmRlciA1LjIuMiBIYXJkIHByZWVtcHRpb24uDQo+ DQo+IEluIGFkZGl0aW9uIHRvIHRoaXMsIHdlIGNhbiBjbGFyaWZ5IGZ1cnRoZXIsIHNvIHRoYXQg InV0aWxpemVkIiBpcyBub3QgYmVpbmcgbWlzdXNlZC4NCj4gTmV3IHRleHRzIGZvciB0aG9zZSB0 d28gYnVsbGV0IGl0ZW1zIGFyZToNCj4NCj4gbyBJZiBtdWx0aXBsZSBwcm90ZWN0aW9uIHBhdGhz IG9mIGVxdWFsIHByaW9yaXR5IGFyZSByZXF1ZXN0aW5nDQo+ICAgIHRoZSBzaGFyZWQgcmVzb3Vy Y2VzLCB0aGUgcmVzb3VyY2VzIFNIQUxMIGJlDQo+ICAgIHV0aWxpemVkIG9uIGEgZmlyc3QgY29t ZSBmaXJzdCBzZXJ2ZWQgYmFzaXMuDQo+ICAgIFRyYWZmaWMgb2YgdGhlIHByb3RlY3Rpb24gcGF0 aHMgdGhhdCByZXF1ZXN0IHRoZSBzaGFyZWQgcmVzb3VyY2UgbGF0ZQ0KPiAgICBTSEFMTCBiZSBi bG9ja2VkIG9yIE1BWSB1c2UgYXZhaWxhYmxlIHJlc291cmNlIHdpdGhvdXQgaW50ZXJydXB0aW5n DQo+ICAgIHRyYWZmaWMgb2YgcHJpb3IgcHJvdGVjdGlvbiBwYXRocyB0aGF0IGFyZSB1dGlsaXpp bmcgdGhlIHNoYXJlZCByZXNvdXJjZS4NCj4gICAgSW4gb3JkZXIgdG8gY292ZXIgdGhlIHNpdHVh dGlvbiB3aGVyZSB0aGUgZmlyc3QgY29tZSBmaXJzdCBzZXJ2ZWQgcHJpbmNpcGxlDQo+ICAgIGNh bm5vdCByZXNvbHZlIHRoZSBjb250ZW50aW9uIGFtb25nIG11bHRpcGxlIGVxdWFsIHByaW9yaXR5 IHJlcXVlc3RzLA0KPiAgICBpLmUuLCB3aGVuIHRoZSByZXF1ZXN0cyBvY2N1ciBzaW11bHRhbmVv dXNseSwgdGllLWJyZWFraW5nIHJ1bGVzDQo+ICAgIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUg b2YgYW4gU01QIGRvbWFpbi4NCj4NCj4gbyBJZiBhIGhpZ2hlciBwcmlvcml0eSBwYXRoIHJlcXVp cmVzIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyB0aGF0IGFyZQ0KPiAgICBiZWluZyB1dGlsaXpl ZCBieSBhIGxvd2VyIHByaW9yaXR5IHBhdGgsIHRoZSByZXNvdXJjZXMgU0hBTEwgYmUNCj4gICAg dXRpbGl6ZWQgYnkgdGhlIGhpZ2hlciBwcmlvcml0eSBwYXRoLg0KPiAgICBUcmFmZmljIHdpdGgg dGhlIGxvd2VyIHByaW9yaXR5IFNIQUxMIGJlIGJsb2NrZWQgb3IgTUFZIHVzZSBhdmFpbGFibGUg cmVzb3VyY2VzDQo+ICAgIHdpdGhvdXQgaW50ZXJydXB0aW5nIHRyYWZmaWMgb2YgdGhlIGhpZ2hl ciBwcmlvcml0eSBwYXRoLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+IEplb25nLWRvbmcNCj4N Cj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiC6 uLO9ILvntvc6IExvdSBCZXJnZXIgW2xiZXJnZXJAbGFibi5uZXRdDQo+ILq4s70gs6/CpTogMjAx NLPiIDe/+SA4wM8gyK2/5MDPIL/AyMQgNzo1Ng0KPiC53rTCILvntvc6IFlhYWNvdiBXZWluZ2Fy dGVuOyC3+cGktb8NCj4gwvzBtjogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnOyBydGctYWRzQHRvb2xzLmlldGYub3JnOyBy dGctZGlyQGlldGYub3JnDQo+IMGmuPE6IFJlOiBbUlRHLURJUl0gW21wbHNdIFJ0Z0RpciByZXZp ZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KPg0KPiBZYWFjb3Ys DQo+ICAgICBTb3VuZHMgcmVhc29uYWJsZSwgYnV0IEknbGwgbmVlZCB0byBzZWUgdGhlIG5ldyB3 b3JkaW5nIHRvIGJlIHN1cmUuDQo+DQo+IFRoYW5rcywNCj4gTG91DQo+IE9uIDcvNS8yMDE0IDM6 NDkgUE0sIFlhYWNvdiBXZWluZ2FydGVuIHdyb3RlOg0KPj4gTG91LCBoaQ0KPj4gSSB3b3VsZCBs aWtlIHRvIGFkZHJlc3MgdHdvIG9mIHlvdXIgY29tbWVudHMsIGluIHlvdXIgZm9sbG93LXVwDQo+ PiBtZXNzYWdlLCBzaW5jZSBJIGFtIHRoZSBzb3VyY2Ugb2YgdGhlIGNoYW5nZSBpbiB0ZXJtaW5v bG9neS4NCj4+DQo+PiBSZWdhcmRpbmcgdGhlIHR3byBvY2N1cmVuY2VzIG9mICJhc3NpZ25lZCIg aW4gcGxhY2Ugb2YgInV0aWxpemVkIiAtDQo+PiB3aGVuIEkgcmVhZCB0aGUgcHJvcG9zZWQgY2hh bmdlcyxhcyBkaXNjdXNzZWQgYW1vbmdzdCB0aGUgYXV0aG9ycywgSQ0KPj4gZmVsdCB0aGF0IGlu IHRob3NlIHR3byBpbnN0YW5jZXMgdGhlIHVzZSBvZiAidXRpbGl6ZWQiIGNvdWxkIGxlYWQgdG8N Cj4+IHNvbWUgYW1iaWd1aXR5Lg0KPj4NCj4+IElmIHdlIHN0YXRlIHRoYXQgInJlc291cmNlcyBT SE9VTEQgYmUgdXRpbGl6ZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0DQo+PiBzZXJ2ZWQgYmFzaXMi IHRoaXMgY291bGQgYmUgaW50ZXJwcmV0ZWQgKElNTykgYXMgcmVmZXJyaW5nIHRvIHRoZQ0KPj4g cGFja2V0IGxldmVsLCByYXRoZXIgdGhhbiAgdXRpbGl6ZWQgYnkgYSBzcGVjaWZpYyBwYXRoLCBz dWNoIHRoYXQNCj4+IHBhY2tldHMgZnJvbSBkaWZmZXJlbnQgcGF0aHMgY291bGQgYmUgaW50ZXJz cGVyc2VkIGFsb25nIHRoZSBzaGFyZWQNCj4+IHNlZ21lbnRzLiBUaGVyZWZvcmUsSSBzdWdnZXN0 ZWQgdGhhdCBvciB0aGlzIGNvbnRleHQgaXQgd291bGQgYmUNCj4+IGJldHRlciB0byB1c2UgYSB3 b3JkIHRoYXQgbWVhbnQgdGhhdCB0aGUgZmlyc3QtY29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMNCj4+ IHdhcyBhdCB0aGUgbGV2ZWwgb2YgYXNzaWduaW5nIChvciBhbGxvY2F0aW5nKSB0aGUgcmVzb3Vy Y2VzIHJhdGhlcg0KPj4gdGhhbiB1dGlsaXppbmcgdGhlbS4NCj4+DQo+PiBIb3BlIHRoaXMgY2xh cmlmaWVzIHRoaXMgcG9pbnQuIEkgYW0gY2VydGFpbiB0aGF0IEkgc3BlYWsgZm9yIHRoZQ0KPj4g b3RoZXIgYXV0aG9ycyBpbiAgc2F5aW5nIHRoYXQgSSBhbSBvcGVuIHRvIG90aGVyIHN1Z2dlc3Rp b25zLg0KPj4NCj4+IEJSLA0KPj4geWFhY292DQo+Pg0KPj4gT24gSnVsIDQsIDIwMTQgMzo1MyBB TSwgIkplb25nIFJ5b28iIDxyeW9vQGV0cmkucmUua3INCj4+IDxtYWlsdG86cnlvb0BldHJpLnJl LmtyPj4gd3JvdGU6DQo+Pg0KPj4gICAgIERlYXIgTG91LA0KPj4NCj4+DQo+Pg0KPj4gICAgIFRo YW5rcyBhIGxvdCBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cy4NCj4+DQo+Pg0KPj4NCj4+ICAg ICBUaGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0IGhhdmUgZGlzY3Vzc2VkIHlvdXIgY29tbWVudHMs IGFuZCBhcmUNCj4+ICAgICBwcm9wb3Npbmcgb3VyIHJlc29sdXRpb25zIHRvIHlvdXIgY29tbWVu dHMuIFBsZWFzZSwgbGV0IHVzIGtub3cgaWYNCj4+ICAgICB0aGUgcHJvcG9zYWwgaXMgYXBwcm9w cmlhdGUgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRzIGFuZCBjb25jZXJucy4NCj4+DQo+Pg0KPj4N Cj4+ICAgICBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4NCj4+DQo+PiAgICAgQXV0aG9ycyBvZiBkcmFm dC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cyBkcmFmdA0KPj4NCj4+DQo+Pg0KPj4gICAgICoq KioqKiBCZWdpbm5pbmcgb2YgQ29tbWVudCBSZXNvbHV0aW9uICoqKioqKg0KPj4NCj4+DQo+Pg0K Pj4gICAgIC0gRG9jdW1lbnQncyB1c2FnZSBvZiAiY29tbWl0dGVkIiB2cyAiYWxsb2NhdGVkIiBy ZXNvdXJjZXM6DQo+Pg0KPj4gICAgIEluIHNlY3Rpb24gMSB0aGUgZG9jdW1lbnQgaW50cm9kdWNl cyB0aGUgbm90aW9uIHRoYXQgdGhlDQo+PiAgICAgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90ZWN0 aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBiYXNlZCBvbiB3aGVuDQo+PiAgICAgcmVzb3VyY2VzIGFy ZSAiY29tbWl0dGVkIi4gVGhpcyBkaWZmZXJlbmNlIGZyb20gcGFzdA0KPj4gICAgIGRlZmluaXRp b24uIFJGQzQ0MjcgYW5kIDYzNzIgbWFrZSB0aGUgZGlzdGluY3Rpb24gdGhhdCBwcm90ZWN0aW9u DQo+PiAgICAgYW5kIHJlc3RvcmF0aW9uIGRpZmZlciBiYXNlZCBvbiB3aGVuIHJlc291cmNlcyBh cmUgKmFsbG9jYXRlZCogbm90DQo+PiAgICAgKmNvbW1pdHRlZCouIFRvIHF1b3RlIFJGQyA0NDI3 Og0KPj4NCj4+ICAgICBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90ZWN0aW9uIGFuZCByZXN0 b3JhdGlvbiBpcyBtYWRlIGJhc2VkDQo+PiAgICAgb24gdGhlIHJlc291cmNlIGFsbG9jYXRpb24g ZG9uZSBkdXJpbmcgdGhlIHJlY292ZXJ5IExTUC9zcGFuDQo+PiAgICAgZXN0YWJsaXNobWVudC4g VGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gZGlmZmVyZW50IHR5cGVzIG9mDQo+PiAgICAgcmVzdG9y YXRpb24gaXMgbWFkZSBiYXNlZCBvbiB0aGUgbGV2ZWwgb2Ygcm91dGUgY29tcHV0YXRpb24sDQo+ PiAgICAgc2lnbmFsaW5nLCBhbmQgcmVzb3VyY2UgYWxsb2NhdGlvbiBkdXJpbmcgdGhlIHJlc3Rv cmF0aW9uDQo+PiAgICAgTFNQL3NwYW4gZXN0YWJsaXNobWVudC4NCj4+DQo+PiAgICAgVGhpcyBk aWZmZXJlbmNlIGFsc28gbGVhZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZQ0K Pj4gICAgIGRvY3VtZW50IGFzIHdlbGwgYXMgYW1iaWd1aXR5IGluIHRoZSB0ZXh0LCBpLmUuIGNv bmZ1c2lvbiBieSB0aGUNCj4+ICAgICByZWFkZXIuIFRoZSB0ZXJtICJjb21taXR0ZWQiIGlzIG5v dCB0aWdodGx5IGRlZmluZWQgaW4gdGhpcw0KPj4gICAgIGRvY3VtZW50IChvciBlYXJsaWVyIHdv cmspIGFuZCBpcyB1c2VkIGRpZmZlcmVudGx5IHRoYW4gaG93DQo+PiAgICAgImFsbG9jYXRlZCIg aGFzIGJlZW4gdXNlZC4gQW4gZXhhbXBsZSBvZiB0aGlzIGNhbiBiZSBmb3VuZCBpbg0KPj4gICAg IFNlY3Rpb24gMy4xIHdoaWNoIHN0YXRlczoNCj4+DQo+PiAgICAgSG93ZXZlciwgdGhlIGNvbW1p dG1lbnQgb2YgdGhlIHJlc291cmNlcywgYXQgbGVhc3QgZm9yIHRoZQ0KPj4gICAgIHNoYXJlZCBz ZWdtZW50cywgd2lsbCBvbmx5IGJlIGZpbmFsaXplZCB3aGVuIHRoZSBwcm90ZWN0aW9uDQo+PiAg ICAgcGF0aCBpcyBhY3R1YWxseSBhY3RpdmF0ZWQuIFRoZXJlZm9yZSwgZm9yIHRoZSBwdXJpc3Rz IC0NCj4+ICAgICByZWdhcmRpbmcgdGhlIHRlcm1pbm9sb2d5IC0gU01QIGxpZXMgc29tZXdoZXJl IGJldHdlZW4NCj4+ICAgICBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbi4NCj4+DQo+PiAgICAg Qm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1hdGljLiBJbiB0aGUgZmlyc3QsIGNvbW1pdG1lbnQg c2VlbXMgdG8NCj4+ICAgICBjb3ZlciBhICJwcm90ZWN0aW9uIHN3aXRjaCIgd291bGQgImNvbm5l Y3QiIHRoZSBwcm90ZWN0aW9uIHBhdGgNCj4+ICAgICBidXQgbm90IHRoZSBlYXJsaWVyICJhbGxv Y2F0aW9uIiBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMgYXJlDQo+PiAgICAgdXNlZCBpbiBl YXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24gaXMgYmFzZWQgb24gdGhlIG5ldw0K Pj4gICAgIGRpc3RpbmN0aW9uIG9mIHByb3RlY3Rpb24gdnMuIHJlc3RvcmF0aW9uIGFuZCBpcyB1 bm5lY2Vzc2FyeSB3aXRoDQo+PiAgICAgdGhlIGV4aXN0aW5nIGRpc3RpbmN0aW9uLg0KPj4NCj4+ ICAgICBUaGlzIGlzc3VlIGV4aXN0cyBpbiBtdWx0aXBsZSBwbGFjZXMgaW4gdGhlIGRvY3VtZW50 IHdoZXJlDQo+PiAgICAgImNvbW1pdHRlZCIgaXMgdXNlZCBhbmQgSSdkIHJlY29tbWVuZCB0aGF0 IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkDQo+PiAgICAgd2l0aCB0ZXJtaW5vbG9neSB1c2VkIGlu IHRoZSByZWZlcmVuY2VkIFJGQ3MsIGkuZS4sICJhbGxvY2F0aW9uIiwNCj4+ICAgICAiY29ubmVj dGlvbiIsICJjcm9zcy1jb25uZWN0IiwgInByb3RlY3Rpb24gc3dpdGNoKG92ZXIpIiwgLi4uDQo+ Pg0KPj4gICAgIE5vdGUgSSdtICpub3QqIGhpZ2hsaWdodGluZyBhbGwgY2FzZXMgd2hlcmUgdGhl cmUgYXJlIHByb2JsZW1zIGluIHRoZQ0KPj4gICAgIGRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBp c3N1ZS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHBsYWNlcyBpbiB0aGUNCj4+ICAgICBkb2N1bWVu dCB3aGVyZSBJIHRoaW5rIGl0J3MgcG9zc2libGUgdGhhdCBvbmNlIHRoaXMgdGVybWlub2xvZ3kN Cj4+ICAgICBhbWJpZ3VpdHkgaXMgY29ycmVjdGVkIHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1YnN0 YW50aXZlIGNvbW1lbnRzLg0KPj4NCj4+DQo+Pg0KPj4gICAgIFtBdXRob3JzXSBBZnRlciByZXZp ZXdpbmcgUkZDcyA0NDI3LCA2MzcyLCAzOTQ1LCA0NDI2LCBhbmQgNDQyOCwNCj4+ICAgICB3ZSBj b25jbHVkZWQgdGhhdCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90ZWN0aW9uIGFuZA0KPj4g ICAgIHJlc3RvcmF0aW9uIHNob3VsZCBiZSBhbGlnbmVkIHdpdGggdGhlIGV4aXRpbmcgZG9jdW1l bnRzDQo+PiAgICAgbm9ybWF0aXZlbHkgcmVmZXJlbmNlZCBieSB0aGlzIGRvY3VtZW50LiBBY2Nv cmRpbmdseSwgdGhlDQo+PiAgICAgZm9sbG93aW5nIDE2IG1vZGlmaWNhdGlvbnMgd2lsbCBiZSBk b25lIGluIHJldmlzaW9uOg0KPj4NCj4+DQo+Pg0KPj4gICAgICgxKSBTZWN0aW9uIDEsIHRoZSB0 aGlyZCBwYXJhZ3JhcGgNCj4+DQo+PiAgICAgT0xEOg0KPj4NCj4+ICAgICBBcyBwb2ludGVkIG91 dA0KPj4NCj4+ICAgICBpbiBbUkZDNjM3Ml0gYW5kIFtSRkM0NDI4XSwgYXBwbHlpbmcgMSsxIGxp bmVhciBwcm90ZWN0aW9uIHJlcXVpcmVzDQo+Pg0KPj4gICAgIHRoYXQgcmVzb3VyY2VzIGFyZSBj b21taXR0ZWQgZm9yIHVzZSBieSBib3RoIHRoZSB3b3JraW5nIGFuZA0KPj4NCj4+ICAgICBwcm90 ZWN0aW9uIHBhdGhzLiBBcHBseWluZyAxOjEgcHJvdGVjdGlvbiByZXF1aXJlcyB0aGF0IHRoZSBz YW1lDQo+Pg0KPj4gICAgIHJlc291cmNlcyBhcmUgY29tbWl0dGVkLCBidXQgYWxsb3dzIHRoZSBy ZXNvdXJjZXMgb2YgdGhlIHByb3RlY3Rpb24NCj4+DQo+PiAgICAgcGF0aCB0byBiZSB1dGlsaXpl ZCBmb3IgcHJlLWVtcHRpYmxlIGV4dHJhIHRyYWZmaWMuDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+ PiAgICAgQXMgcG9pbnRlZCBvdXQNCj4+DQo+PiAgICAgaW4gW1JGQzYzNzJdIGFuZCBbUkZDNDQy OF0sIGFwcGx5aW5nIDErMSBwcm90ZWN0aW9uIHJlcXVpcmVzDQo+Pg0KPj4gICAgIHRoYXQgcmVz b3VyY2VzIGFyZSBhbGxvY2F0ZWQgZm9yIHVzZSBieSBib3RoIHRoZSB3b3JraW5nIGFuZA0KPj4N Cj4+ICAgICBwcm90ZWN0aW9uIHBhdGhzLiBBcHBseWluZyAxOjEgcHJvdGVjdGlvbiByZXF1aXJl cyB0aGF0IHRoZSBzYW1lDQo+Pg0KPj4gICAgIHJlc291cmNlcyBhcmUgYWxsb2NhdGVkLCBidXQg YWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhlIHByb3RlY3Rpb24NCj4+DQo+PiAgICAgcGF0aCB0 byBiZSB1dGlsaXplZCBmb3IgcHJlLWVtcHRpYmxlIGV4dHJhIHRyYWZmaWMuDQo+Pg0KPj4NCj4+ DQo+PiAgICAgKDIpIFRoZSB3aG9sZSB0ZXh0IGluIFNlY3Rpb24gMy4xIHdpbGwgYmUgcmVwbGFj ZWQgd2l0aDoNCj4+DQo+PiAgICAgW1JGQzYzNzJdLCBiYXNlZCB1cG9uIHRoZSBkZWZpbml0aW9u cyBpbiBbUkZDNDQyN10sIGRpZmZlcmVudGlhdGVzDQo+PiAgICAgYmV0d2VlbiAicHJvdGVjdGlv biIgYW5kICJyZXN0b3JhdGlvbiIgZGVwZW5kZW50IHVwb24gdGhlIGR5bmFtaXNtDQo+PiAgICAg b2YgdGhlIHJlc291cmNlIGFsbG9jYXRpb24uIFRoZSBzYW1lIGRpc3RpbmN0aW9uIGlzIHVzZWQg aW4NCj4+ICAgICBbUkZDMzk0NV0sIFtSRkM0NDI2XSwgYW5kIFtSRkM0NDI4XS4gVGhpcyBkb2N1 bWVudCBhbHNvIHVzZXMgdGhlDQo+PiAgICAgc2FtZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3Rl Y3Rpb24gYW5kIHJlc3RvcmF0aW9uIGFzIHN0YXRlZCBpbg0KPj4gICAgIFtSRkM2MzcyXS4NCj4+ DQo+Pg0KPj4NCj4+ICAgICAoMykgSW4gcGFnZSA2LA0KPj4NCj4+ICAgICBPTEQ6DQo+Pg0KPj4g ICAgIFRoZSB1c2Ugb2YgcHJlZW1wdGlvbiBpbiB0aGUgbmV0d29yayBpcyB0eXBpY2FsbHkgYSBi dXNpbmVzcyBvcg0KPj4NCj4+ICAgICBwb2xpY3kgZGVjaXNpb24gc3VjaCB0aGF0IHdoZW4gcHJv dGVjdGlvbiByZXNvdXJjZXMgYXJlIGNvbnRlbmRlZCwNCj4+DQo+PiAgICAgcHJpb3JpdHkgY2Fu IGJlIGFwcGxpZWQgdG8gZGV0ZXJtaW5lIHRvIHdoaWNoIHBhcnRpZXMgdGhlIHByb3RlY3Rpb24N Cj4+DQo+PiAgICAgcmVzb3VyY2VzIGFyZSBjb21taXR0ZWQuDQo+Pg0KPj4gICAgIE5FVzoNCj4+ DQo+PiAgICAgVGhlIHVzZSBvZiBwcmVlbXB0aW9uIGluIHRoZSBuZXR3b3JrIGlzIHR5cGljYWxs eSBhIGJ1c2luZXNzIG9yDQo+Pg0KPj4gICAgIHBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hl biBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgY29udGVuZGVkLA0KPj4NCj4+ICAgICBwcmlvcml0 eSBjYW4gYmUgYXBwbGllZCB0byBkZXRlcm1pbmUgd2hpY2ggcGFydGllcyB1dGlsaXplIHRoZQ0K Pj4gICAgIHByb3RlY3Rpb24NCj4+DQo+PiAgICAgcmVzb3VyY2VzLg0KPj4NCj4+DQo+Pg0KPj4g ICAgICg0KSBQYWdlIDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQo+Pg0KPj4gICAgIE9MRDoNCj4+ DQo+PiAgICAgdGhlIHJlc291cmNlcyBmb3IgdGhlIHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkg Y29tbWl0dGVkLA0KPj4NCj4+ICAgICBORVcNCj4+DQo+PiAgICAgdGhlIHJlc291cmNlcyBmb3Ig dGhlIHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkgZGVkaWNhdGVkLA0KPj4NCj4+DQo+Pg0KPj4g ICAgIE9MRDoNCj4+DQo+PiAgICAgcmVzb3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBu b3QgYmUgY29tbWl0dGVkIHVudGlsIKGmDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+PiAgICAgcmVz b3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBub3QgYmUgdXRpbGl6ZWQgdW50aWwgoaYN Cj4+DQo+Pg0KPj4NCj4+ICAgICAoNSkgSW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gcGFnZSA3 LA0KPj4NCj4+ICAgICBPTEQ6DQo+Pg0KPj4gICAgICJIYXJkIFByZWVtcHRpb24iIHJlcXVpcmVz IHRoZSBwcm9ncmFtbWluZyBvZiBzZWxlY3RvcnMgYXQgdGhlDQo+PiAgICAgaW5ncmVzcyBvZiBl YWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkgd2hpY2ggYmFja3VwIHBhdGggaGFzDQo+PiAg ICAgdGhlIGhpZ2hlc3QgcHJpb3JpdHkgd2hlbiBjb21taXR0aW5nIHByb3RlY3Rpb24gcmVzb3Vy Y2VzLCB0aGUNCj4+ICAgICBvdGhlcnMgYmVpbmcgcHJlZW1wdGVkLg0KPj4NCj4+ICAgICBORVcN Cj4+DQo+PiAgICAgIkhhcmQgUHJlZW1wdGlvbiIgcmVxdWlyZXMgdGhlIHByb2dyYW1taW5nIG9m IHNlbGVjdG9ycyBhdCB0aGUNCj4+ICAgICBpbmdyZXNzIG9mIGVhY2ggc2hhcmVkIHNlZ21lbnQg dG8gc3BlY2lmeSB0aGUgcHJpb3JpdGllcyBvZiBiYWNrdXANCj4+ICAgICBwYXRocywgc28gdGhh dCB0cmFmZmljIG9mIGxvd2VyIHByaW9yaXR5IHBhdGhzIGNhbiBiZSBwcmVlbXB0ZWQuDQo+Pg0K Pj4NCj4+DQo+PiAgICAgKDYpIFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0LjE6DQo+ Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgoaYgYW5kIGNvbW1pdCB0aGUgYXNzb2NpYXRlZCBy ZXNvdXJjZXMuIFRoZSBjb21taXRtZW50IG9mIHJlc291cmNlcw0KPj4NCj4+ICAgICBpcyBkZXBl bmRlbnQgdXBvbiChpg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4gICAgIKGmIGFuZCBjb29yZGlu YXRlIHRoZSB1dGlsaXphdGlvbiBvZiB0aGUgYXNzb2NpYXRlZCBzaGFyZWQgcmVzb3VyY2VzLg0K Pj4NCj4+ICAgICBUaGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIGlzIGRlcGVu ZGVudCB1cG9uIKGmDQo+Pg0KPj4NCj4+DQo+PiAgICAgKDcpIFRoZSBzZWNvbmQgcGFyYWdyYXBo IG9mIFNlY3Rpb24gNC4xOg0KPj4NCj4+ICAgICBPTEQ6DQo+Pg0KPj4gICAgIFdoZW4gdGhlIHJl c2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSBjb21taXR0ZWQgdG8g YQ0KPj4NCj4+ICAgICBwYXJ0aWN1bGFyIHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBi ZSBzdWZmaWNpZW50IHJlc291cmNlcw0KPj4NCj4+ICAgICBhdmFpbGFibGUgZm9yIGFuIGFkZGl0 aW9uYWwgcHJvdGVjdGlvbiBwYXRoLiBUaGlzIHRoZW4gaW1wbGllcyB0aGF0DQo+Pg0KPj4gICAg IGlmIGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJv dGVjdGlvbg0KPj4NCj4+ICAgICBzd2l0Y2gsIHRoZSBjb21taXRtZW50IG9mIHRoZSByZXNvdXJj ZXMgbWF5IGZhaWwuIEluIG9yZGVyIHRvDQo+Pg0KPj4gICAgIG9wdGltaXplIHRoZSBvcGVyYXRp b24gb2YgdGhlIGNvbW1pdG1lbnQgYW5kIHByZXBhcmluZyBmb3IgY2FzZXMgb2YNCj4+DQo+PiAg ICAgbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgY29tbWl0bWVudCBvZiB0aGUg c2hhcmVkDQo+Pg0KPj4gICAgIHJlc291cmNlcyBhcmUgYmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0 aGUgZGlmZmVyZW50IHdvcmtpbmcgcGF0aHMgaW4NCj4+DQo+PiAgICAgdGhlIFNNUCBuZXR3b3Jr Lg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4gICAgIFdoZW4gdGhlIHJlc2VydmVkIHJlc291cmNl cyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSB1dGlsaXplZCBieSBhDQo+Pg0KPj4gICAgIHBh cnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVyZSBtYXkgbm90IGJlIHN1ZmZpY2llbnQgcmVz b3VyY2VzDQo+Pg0KPj4gICAgIGF2YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25hbCBwcm90ZWN0aW9u IHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQNCj4+DQo+PiAgICAgaWYgYW5vdGhlciB3b3Jr aW5nIHBhdGggb2YgdGhlIFNNUCBkb21haW4gdHJpZ2dlcnMgYSBwcm90ZWN0aW9uDQo+Pg0KPj4g ICAgIHN3aXRjaCwgdGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiBtYXkgZmFp bC4gVGhlDQo+PiAgICAgZGlmZmVyZW50IHdvcmtpbmcgcGF0aHMgaW4NCj4+DQo+PiAgICAgdGhl IFNNUCBuZXR3b3JrIGFyZSBpbnZvbHZlZCBpbiB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24NCj4+ ICAgICBjb29yZGluYXRpb24uDQo+Pg0KPj4gICAgIC4NCj4+DQo+Pg0KPj4NCj4+ICAgICAoOCkg U2VjdGlvbiA1LjEsDQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgoaYgYW5kIGNvbW1pdCB0 aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMuDQo+Pg0KPj4gICAgIE5FVw0KPj4NCj4+ICAgICChpiBh bmQgY29vcmRpbmF0ZSB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIGFzc29jaWF0ZWQgc2hhcmVkIHJl c291cmNlcy4NCj4+DQo+Pg0KPj4NCj4+ICAgICAoOSkgSW4gU2VjdGlvbiA1LjEsDQo+Pg0KPj4g ICAgIE9MRDoNCj4+DQo+PiAgICAgSW4gdGhlIGNhc2Ugb2YgbXVsdGlwbGUgd29ya2luZyBwYXRo cyBmYWlsaW5nLCB0aGUgY29tbWl0bWVudCBvZiB0aGUNCj4+DQo+PiAgICAgc2hhcmVkIHJlc291 cmNlcyBTSEFMTCBiZSBjb29yZGluYXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZw0K Pj4NCj4+ICAgICBwYXRocyBpbiB0aGUgU01QIG5ldHdvcmsuDQo+Pg0KPj4gICAgIE5FVzoNCj4+ DQo+PiAgICAgSW4gdGhlIGNhc2Ugb2YgbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0 aGUgc2hhcmVkIHJlc291cmNlDQo+PiAgICAgdXRpbGl6YXRpb24NCj4+DQo+PiAgICAgY29vcmRp bmF0aW9uIFNIQUxMIGJlIGJldHdlZW4gdGhlIGRpZmZlcmVudCB3b3JraW5nDQo+Pg0KPj4gICAg IHBhdGhzIGluIHRoZSBTTVAgbmV0d29yay4NCj4+DQo+Pg0KPj4NCj4+ICAgICAoMTApIFNlY3Rp b24gNS4xLjEuDQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgoaYgYmVjYXVzZSB0aGV5IGFs cmVhZHkgaGF2ZSBiZWVuIGNvbW1pdHRlZCB0byB0aGUgcHJvdGVjdGlvbiBvZiwNCj4+ICAgICBm b3IgZXhhbXBsZSwgYSBoaWdoZXIgcHJpb3JpdHkgd29ya2luZyBwYXRoLg0KPj4NCj4+ICAgICBO RVc6DQo+Pg0KPj4gICAgIKGmIGJlY2F1c2UgdGhleSBhbHJlYWR5IGhhdmUgYmVlbiB1dGlsaXpl ZCBmb3IgdGhlIHByb3RlY3Rpb24gb2YsDQo+PiAgICAgZm9yIGV4YW1wbGUsIGEgaGlnaGVyIHBy aW9yaXR5IHdvcmtpbmcgcGF0aC4NCj4+DQo+Pg0KPj4NCj4+ICAgICAoMTEpIFNlY3Rpb24gNS4y LCB0aGUgc2Vjb25kIGJ1bGxldCBpdGVtOg0KPj4NCj4+ICAgICBPTEQ6DQo+Pg0KPj4gICAgIFJl c291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIFNIQUxMIGJlIGNvbW1pdHRlZCB0byB0aGUN Cj4+DQo+PiAgICAgcHJvdGVjdGlvbiBwYXRoIKGmDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+PiAg ICAgUmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgU0hBTEwgYmUgdXRpbGl6ZWQgYnkg dGhlDQo+Pg0KPj4gICAgIHByb3RlY3Rpb24gcGF0aCChpg0KPj4NCj4+DQo+Pg0KPj4gICAgICgx MikgU2VjdGlvbiA1LjIsIHRoZSB0aGlyZCBidWxsZXQgaXRlbToNCj4+DQo+PiAgICAgT0xEOg0K Pj4NCj4+ICAgICBJZiBtdWx0aXBsZSBwcm90ZWN0aW9uIHBhdGhzIG9mIGVxdWFsIHByaW9yaXR5 IGFyZSByZXF1ZXN0aW5nDQo+Pg0KPj4gICAgIGFsbG9jYXRpb24gb2YgdGhlIHNoYXJlZCByZXNv dXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxEIGJlDQo+Pg0KPj4gICAgIGNvbW1pdHRlZCBvbiBh IGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzLg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4g ICAgIElmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJl cXVlc3RpbmcNCj4+DQo+PiAgICAgdGhlIHNoYXJlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMg U0hPVUxEIGJlDQo+Pg0KPj4gICAgIGFzc2lnbmVkIG9uIGEgZmlyc3QgY29tZSBmaXJzdCBzZXJ2 ZWQgYmFzaXMuDQo+Pg0KPj4NCj4+DQo+PiAgICAgKDEzKSBTZWN0aW9uIDUuMiwgdGhlIGZvdXJ0 aCBidWxsZXQgaXRlbToNCj4+DQo+PiAgICAgT0xEOg0KPj4NCj4+ICAgICBJZiB0aGUgcHJvdGVj dGlvbiByZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCB0byBhIHByb3RlY3Rpb24gcGF0aCwNCj4+DQo+ PiAgICAgd2hvc2Ugd29ya2luZyBwYXRoIGhhcyBhIGxvd2VyIHByaW9yaXR5LCByZXNvdXJjZXMg cmVxdWlyZWQgZm9yDQo+Pg0KPj4gICAgIHRoZSBoaWdoZXIgcHJpb3JpdHkgcGF0aCBTSEFMTCBi ZSBjb21taXR0ZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eQ0KPj4NCj4+ICAgICBwYXRoLg0KPj4N Cj4+ICAgICBORVc6DQo+Pg0KPj4gICAgIElmIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUg dXRpbGl6ZWQgYnkgYSBwcm90ZWN0aW9uIHBhdGgsDQo+Pg0KPj4gICAgIHdob3NlIHdvcmtpbmcg cGF0aCBoYXMgYSBsb3dlciBwcmlvcml0eSwgcmVzb3VyY2VzIHJlcXVpcmVkIGZvcg0KPj4NCj4+ ICAgICB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGggU0hBTEwgYmUgYXNzaWduZWQgdG8gdGhlIGhp Z2hlciBwcmlvcml0eQ0KPj4NCj4+ICAgICBwYXRoLg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAg ICAgKDE0KSBTZWN0aW9uIDUuMi4gdGhlIHNldmVudGggYnVsbGV0IGl0ZW0NCj4+DQo+PiAgICAg T0xEOg0KPj4NCj4+ICAgICBPbmNlIHJlc291cmNlcyBvZiBzaGFyZWQgc2VnbWVudHMgaGF2ZSBi ZWVuIHN1Y2Nlc3NmdWxseSBjb21taXR0ZWQNCj4+DQo+PiAgICAgdG8gYSBwcm90ZWN0aW9uIHBh dGgsIKGmDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+PiAgICAgT25jZSByZXNvdXJjZXMgb2Ygc2hh cmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkgdXRpbGl6ZWQNCj4+DQo+PiAgICAg YnkgYSBwcm90ZWN0aW9uIHBhdGgsIKGmDQo+Pg0KPj4NCj4+DQo+PiAgICAgKDE1KSBTZWN0aW9u IDUuMywgdGhlIGZpcnN0IHBhcmFncmFwaCwNCj4+DQo+PiAgICAgT0xEOg0KPj4NCj4+ICAgICCh piByZXF1ZXN0IHRoZSBjb21taXRtZW50IG9mIHByb3RlY3Rpb24gcmVzb3VyY2VzLiBJZiB0aGUg bmVjZXNzYXJ5DQo+Pg0KPj4gICAgIHNoYXJlZCByZXNvdXJjZXMgYXJlIHVuYXZhaWxhYmxlIHRv IGJlIGNvbW1pdHRlZCB0byB0aGUgcHJvdGVjdGlvbg0KPj4NCj4+ICAgICBwYXRoLCB0aGUgZW5k cG9pbnRzIKGmDQo+Pg0KPj4NCj4+DQo+PiAgICAgTkVXOg0KPj4NCj4+ICAgICChpiByZXF1ZXN0 IHRoZSBjb29yZGluYXRpb24gb2YgdGhlIHNoYXJlZCByZXNvdXJjZSB1dGlsaXphdGlvbi4gSWYN Cj4+ICAgICB0aGUgbmVjZXNzYXJ5DQo+Pg0KPj4gICAgIHNoYXJlZCByZXNvdXJjZXMgYXJlIHVu YXZhaWxhYmxlLCB0aGUgZW5kcG9pbnRzIKGmDQo+Pg0KPj4NCj4+DQo+PiAgICAgKDE2KSBTZWN0 aW9uIDUuMywgdGhlIHNlY29uZCBwYXJhZ3JhcGgsDQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAg ICAgU2ltaWxhcmx5LCBpZiBwcmVlbXB0aW9uIGlzIHN1cHBvcnRlZCBhbmQgdGhlIHJlc291cmNl cyBjdXJyZW50bHkNCj4+DQo+PiAgICAgY29tbWl0dGVkIGZvciBhIHBhcnRpY3VsYXIgd29ya2lu ZyBwYXRoIGFyZSChpg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4gICAgIFNpbWlsYXJseSwgaWYg cHJlZW1wdGlvbiBpcyBzdXBwb3J0ZWQgYW5kIHRoZSByZXNvdXJjZXMgY3VycmVudGx5DQo+Pg0K Pj4gICAgIHV0aWxpemVkIGJ5IGEgcGFydGljdWxhciB3b3JraW5nIHBhdGggYXJlIKGmDQo+Pg0K Pj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gMiwgMXN0IHBhcmFncmFwaCwgbGFzdCBz ZW50ZW5jZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkNCj4+ICAgICBkZWZpbmVzDQo+PiAgICAgdGhl IHNjb3BlL3B1cnBvc2Ugb2YgdGhlIGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0 cnVjdGlvbnMNCj4+ICAgICB0byBwcm90b2NvbCBkZXNpZ25lcnMgcHJvZHVjaW5nIHNvbHV0aW9u cyB0aGF0IHNhdGlzZnkgdGhlDQo+PiAgICAgcmVxdWlyZW1lbnRzIHNldCBvdXQgaW4gdGhpcyBk b2N1bWVudC4iIEFzIHN1Y2gsIEknZCByZXBlYXQgdGhpcyBpbg0KPj4gICAgIHRoZSBhYnN0cmFj dCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJvbm91bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9y DQo+PiAgICAgMykuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBXZSBjYW4gYWRkIHRoZSBmb2xsb3dp bmcgcGFyYWdyYXBoIGF0IHRoZSBlbmQgb2YgU2VjdGlvbiAxOg0KPj4NCj4+ICAgICChsFRoaXMg ZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8gY2xhcmlmeSB0aGUgaW5zdHJ1Y3Rpb25zIHRvIHByb3Rv Y29sDQo+PiAgICAgZGVzaWduZXJzIHByb2R1Y2luZyBzb2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRo ZSByZXF1aXJlbWVudHMgc2V0DQo+PiAgICAgb3V0IGluIHRoaXMgZG9jdW1lbnQuobENCj4+DQo+ Pg0KPj4NCj4+DQo+PiAgICAgLSBHZW5lcmFsIGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBmb3IgY28t cm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQo+PiAgICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJv dXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD8NCj4+ICAgICBJJ2Qg YXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2ggY29vcmRpbmF0aW9uIHByb3RvY29sIHdvdWxk IGJlDQo+PiAgICAgcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVy c2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCj4+ICAgICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMg aW4gdGhlIGRvY3VtZW50Lg0KPj4NCj4+ICAgICBbQXV0aG9yc10gRmF0ZS1zaGFyaW5nIGlzIG5v dCByZXF1aXJlZCBieSB0aGlzIGRvY3VtZW50LiBFdmVuIGluDQo+PiAgICAgdGhlIFBTQyBsaW5l YXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIHN1Y2ggYXMgUkZDIDYzNzggKFBTQykgYW5kDQo+PiAg ICAgUkZDIDcyNzEgKFBTQyBpbiBBUFMgbW9kZSksIGZhdGUtc2hhcmluZyBpcyBub3QgcmVxdWly ZWQgYXMNCj4+ICAgICB1bmlkaXJlY3Rpb25hbCBzd2l0Y2hpbmcgaXMgYWxsb3dlZC4gVGhpcyBk b2N1bWVudCBkb2VzIG5vdCBpbXBvc2UNCj4+ICAgICBhbnkgcmVzdHJpY3Rpb24gb24gY28tcm91 dGluZywgZWl0aGVyLg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIEluIHNlY3Rpb24gNCBhbmQg NS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBhcyBkZWZpbmluZw0KPj4gICAgIHByZWVt cHRpb24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0 DQo+PiAgICAgcmVmZXJlbmNlIGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBjb250ZXh0 IG9mIHN1cnZpdmFiaWxpdHkgYW5kDQo+PiAgICAgaW4gZGVwZW5kZW50IG9mIGNvbnRyb2wgcGxh bmUuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBPbmUgY29uY2VybiBpcyB0aGF0IFJGQyA2MzcyIGRl c2NyaWJlcyBib3RoIHNvZnQgYW5kDQo+PiAgICAgaGFyZCBwcmVlbXB0aW9ucyBpbiB0aGUgY29u dGV4dCBvZiBleHRyYSB0cmFmZmljLCB3aGljaCBpcyBub3QNCj4+ICAgICBleGFjdGx5IHRoZSBj YXNlIGZvciBTTVAuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gSW4gc2VjdGlvbiA0LjIgeW91 IHNheSAiVGhlcmVmb3JlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGJlDQo+PiAgICAgY2Fy cmllZCBvdXQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgc2lt aWxhciB0bw0KPj4gICAgIEdNUExTIFtSRkMzOTQ1XS4iIHBlcmhhcHMgeW91IG1lYW4gImJhc2Vk IG9uIEdNUExTIj8gSWYgc28sIGdyZWF0LA0KPj4gICAgIHBsZWFzZSBtYWtlIHRoZSBjb3JyZWN0 aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBvZiB3aGljaA0KPj4gICAgIGNvbnRyb2wg cHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBpcyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0 aGlzDQo+PiAgICAgZG9jdW1lbnQuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBZZXMsIHdlIHdpbGwg bWFrZSB0aGUgY29ycmVjdGlvbi4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDUu MSwgcGFyYWdyYXBoIDEuIFdoeSBhcmUgeW91IHVzaW5nICJTSE9VTEQgTk9UIiBoZXJlPyBJZg0K Pj4gICAgIHJlZmVycmluZyB0byBzb2x1dGlvbnMgY29uZm9ybWFudCB3aXRoIHRoaXMgZG9jdW1l bnQsIHRoZW4gdGhlc2UgYXJlDQo+PiAgICAgaW5mb3JtYXRpdmUgc3RhdGVtZW50cywgImFuZCBh IG5vbi1jb250cm9sIHBsYW5lIGJhc2VkIFNNUCBzd2l0Y2hvdmVyDQo+PiAgICAgbWVjaGFuaXNt IGlzIHVzZWQsIHRoZSBjb250cm9sIHBsYW5lIFNIQUxMIE5PVCAuLi4iLiBJZiByZWZlcnJpbmcg dG8NCj4+ICAgICBhbiBvcGVyYXRvcidzL3VzZXIncyBjaG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNo YW5pc20sIEkgdGhpbmsgdGhlIG1vc3QNCj4+ICAgICB5b3UgY2FuIHNheSBpcyBNQVkuDQo+Pg0K Pj4gICAgIFtBdXRob3JzXSBUaGUgZmlyc3QgY2FzZSBpcyB0aGUgb25lIHdlIGFyZSBhaW1pbmcg YXQuIFdlIHdpbGwgdXNlDQo+PiAgICAgU0hBTEwgTk9ULg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAg ICAtIFNlY3Rpb24gNS4yLiAiVGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4g c2NvcGUgb2YgYW4gU01QDQo+PiAgICAgZG9tYWluLiIgQXMgdGhpcyBpcyBhIHJlcXVpcmVtZW50 LCB3aGF0IHlvdSBtZWFuIGJ5ICJ0aWUtYnJlYWtpbmcNCj4+ICAgICBydWxlcyIgc2hvdWxkIGJl IGRlZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNlLg0KPj4NCj4+ICAgICBbQXV0aG9yc10g VGhlIHNlbnRlbmNlIGNhbiBiZSByZXdyaXR0ZW4gYXM6DQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+ PiAgICAgVGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4g U01QIGRvbWFpbi4NCj4+DQo+PiAgICAgTkVXOg0KPj4NCj4+ICAgICBJbiBvcmRlciB0byBjb3Zl ciB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZA0KPj4gICAg IHByaW5jaXBsZSBjYW5ub3QgcmVzb2x2ZSB0aGUgY29udGVudGlvbiBhbW9uZyBtdWx0aXBsZSBl cXVhbA0KPj4gICAgIHByaW9yaXR5IHJlcXVlc3RzLCBpLmUuLCB3aGVuIHRoZSByZXF1ZXN0cyBv Y2N1ciBzaW11bHRhbmVvdXNseSwsDQo+PiAgICAgdGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJl IGRlZmluZWQgaW4gc2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0K Pj4NCj4+ICAgICAtIFNlY3Rpb24gNS4zLiBSRkM2MzcyIHRha2VzIGFuIGFwcHJvYWNoIHdoZXJl IHByZWVtcHRpb24gbm90aWZpY2F0aW9uDQo+PiAgICAgbGV2ZXJhZ2VzIHRoZSBzdGFuZGFyZCBN UExTLVRQIE9BTSBtZWNoYW5pc21zLCBpcyB0aGVyZSBhbnkgcmVhc29uIHRvDQo+PiAgICAgZG8g bW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2MzcyPw0KPj4NCj4+ICAgICBbQXV0aG9yc10gV2UgY2Fu IGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGF0IHRoZSBlbmQ6DQo+Pg0KPj4gICAgIKGwQXMg ZGVzY3JpYmVkIGluIFtSRkM2MzcyXSwgdGhlIGV2ZW50IG9mIHByZWVtcHRpb24gbWF5IGJlDQo+ PiAgICAgZGV0ZWN0ZWQgYnkgT0FNIGFuZCByZXBvcnRlZCBhcyBhIGZhdWx0IG9yIGEgZGVncmFk YXRpb24gb2YNCj4+ICAgICB0cmFmZmljIGRlbGl2ZXJ5LqGxDQo+Pg0KPj4NCj4+ICAgICAtIFNl Y3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9uIHJlcXVpcmVkIG9uDQo+PiAgICAg c29mdC1wcmVlbXB0aW9uIGFzDQo+PiAgICAgd2VsbCAoZGVwZW5kaW5nIG9uIHRoZSBjcm9zcy1j b25uZWN0cyBlc3RhYmxpc2hlZCBkdXJpbmcgTFNQDQo+PiAgICAgZXN0YWJsaXNobWVudCkgc28g Y29vcmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBiZSBzdXBwb3J0ZWQNCj4+ICAgICBpbmRlcGVu ZGVudCBvZiBwcmVlbXB0aW9uIG1vZGUuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBZZXMsIHdlIHdp bGwgY2hhbmdlIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGZyb20gobBTTVAgaW4NCj4+ICAgICBoYXJk LXByZWVtcHRpb24gbW9kZSBTSE9VTEQgoaahsSB0byChsFNNUCBTSE9VTEQgoaahsSBhbmQgbW92 ZSB0aGUNCj4+ICAgICBjaGFuZ2VkIHBhcmFncmFwaCBhYm92ZSB0aGUgZmlyc3QgcGFyYWdyYXBo Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICBOaXRzOg0KPj4NCj4+ICAgICAtIEFic3RyYWN0OiBJ IGRvbid0IHJlY2FsbCB0aGUgdGVybSAiZXhlY3V0aXZlIGFjdGlvbiIgYmVpbmcgdXNlZA0KPj4g ICAgIGluIGFueQ0KPj4gICAgIGVhcmxpZXIgcmVsYXRlZC9yZWZlcmVuY2VkIFJGQ3MuIFJhdGhl ciB0aGFuIGludHJvZHVjZSBhIG5ldyAoYW5kDQo+PiAgICAgdW5kZWZpbmVkKSB0ZXJtLCBwZXJo YXBzIHlvdSBjYW4gdXNlIGFuIGV4aXN0aW5nIG9uZSwgZS5nLiwNCj4+ICAgICAicHJvdGVjdGlv biBzd2l0Y2giPw0KPj4NCj4+ICAgICBbQXV0aG9yc10gWWVzLCB0aGUgdGVybSB3aWxsIGJlIGNo YW5nZWQgYXMgeW91IHN1Z2dlc3RlZC4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9u IDEsIHBhcmFncmFwaCAxLiBEbyB3ZSByZWFsbHkgbmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2YN Cj4+ICAgICBNUExTLVRQIHRvIGRlYmF0ZT8gSSBzdWdnZXN0IGp1c3QgcmVmZXJlbmNpbmcgeW91 ciBmYXZvcml0ZSBNUExTLVRQDQo+PiAgICAgZG9jdW1lbnQocykgYW5kIGRyb3BwaW5nIHRoZSBm aXJzdCBmb3VyIHNlbnRlbmNlcy4NCj4+DQo+PiAgICAgVGhlIGxhc3Qgc2VudGVuY2UgYWxzbyBt YWtlcyBhIHN1YmplY3RpdmUgc3RhdGVtZW50LiBXaGV0aGVyIGl0IGlzDQo+PiAgICAgY3JpdGlj YWwgb3Igbm8gaXMgdW5uZWNlc3NhcnkuIFlvdSBjYW4ganVzdCBzYXkgc29tZXRoaW5nIGxpa2Ug NjM3Mg0KPj4gICAgIHByb3ZpZGVzIGEgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgZm9yIE1QTFMt VFAgYW5kIGlzIHRoZSBmb3VuZGF0aW9uDQo+PiAgICAgZm9yIHRoaXMgZG9jdW1lbnQuDQo+Pg0K Pj4gICAgIFtBdXRob3JzXSBUaGUgcHJvcG9zZWQgdGV4dCBmb3IgdGhlIHBhcmFncmFwaCAxIGlz Og0KPj4NCj4+ICAgICChsFRoZSBNUExTIFRyYW5zcG9ydCBQcm9maWxlIChNUExTLVRQKSBpcyBk ZXNjcmliZWQgaW4gW1JGQzU5MjFdLA0KPj4NCj4+ICAgICBhbmQgW1JGQzYzNzJdIHByb3ZpZGVz IGEgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgZm9yIE1QTFMtVFANCj4+DQo+PiAgICAgYW5kIGlz IHRoZSBmb3VuZGF0aW9uIGZvciB0aGlzIGRvY3VtZW50LqGxDQo+Pg0KPj4NCj4+DQo+Pg0KPj4g ICAgIC0gU2VjdGlvbiAxLCBwYXJhZ3JhcGggMy4gSXNuJ3QgdGhlIHJpZ2h0IHJlZmVyZW5jZSA0 NDI3IG5vdCA0NDI4Pw0KPj4gICAgIEFsc28gZHJvcCB0aGUgd29yZCBsaW5lYXIsIGFzIGl0IGlz IGFuIHVubmVjZXNzYXJ5IHF1YWxpZmllciBhbmQNCj4+ICAgICA0NDI3LzQ0MjggZG9uJ3QgdXNl IGl0Lg0KPj4NCj4+ICAgICBbQXV0aG9yc10gT0suDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+ PiAgICAgLSBTZWN0aW9ucyAzIChhbmQgdG8gYSBsZXNzZXIgZGVncmVlIHNlY3Rpb24gMikgYXJl IHJlYWxseQ0KPj4gICAgIGludHJvZHVjdG9yeQ0KPj4gICAgIHRleHQuIEknbSB1bnN1cmUgYXMg dG8gd2h5IHRoZXkgYXJlbid0IHBhcnQgb2Ygc2VjdGlvbiAxLg0KPj4NCj4+ICAgICBbQXV0aG9y c10gU2VjdGlvbiAzIHdhcyBpbnRlbmRlZCB0byBwcmVzZW50IGEgcmVmZXJlbmNlIG1vZGVsIGZv cg0KPj4gICAgIFNNUC4gU29tZSB0ZXh0IG9mIFNlY3Rpb24gMiBpcyByZXBlYXRlZCBpbiBTZWN0 aW9uIDEgYXMgeW91DQo+PiAgICAgc3VnZ2VzdGVkIGVhcmxpZXIuDQo+Pg0KPj4NCj4+DQo+Pg0K Pj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDMuMiBzaG91bGQgaGF2ZSBhIHJlZmVyZW5jZSBmb3Ig ImV4aXN0aW5nIGNvbnRyb2wgcGxhbmUNCj4+ICAgICBzb2x1dGlvbnMgZm9yIFNNUCB3aXRoaW4g TVBMUyIuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBbUkZDNDIwNl0gd2lsbCBiZSBhZGRlZCBhcyBh IHJlZmVyZW5jZQ0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDMuMiBhZ2FpbiB1c2VzIHRoZSAi ZXhlY3V0aXZlIGFjdGlvbiIgdGVybS4NCj4+DQo+PiAgICAgW0F1dGhvcnNdIE9LLCB0aGUgdGVy bSB3aWxsIGJlIGNoYW5nZWQuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA0LjEu IFlvdSBzYXkgInR3byBvcGVyYXRpb25zIHNpbXVsdGFuZW91c2x5Ii4gRG8geW91IHJlYWxseQ0K Pj4gICAgIG1lYW4gInNpbXVsdGFuZW91c2x5IiBvciBtZXJlbHkgdGhhdCB0aGV5IG11c3QgYm90 aCBvY2N1ciBmb3INCj4+ICAgICBwcm90ZWN0aW9uIHRvIGJlIHByb3ZpZGVkPyAoU2FtZSBjb21t ZW50IGluIHNlY3Rpb24gNS4xLg0KPj4NCj4+ICAgICBbQXV0aG9yc10gQm90aCBhY3Rpb25zIHNo b3VsZCBvY2N1ciBhdCB0aGUgc2FtZSB0aW1lLCBvciBhcw0KPj4gICAgIGNsb3NlbHkgYXMgcG9z c2libGUgdG8gcHJvdmlkZSBmYXN0IHByb3RlY3Rpb24uDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gICAg IC0gU2VjdGlvbiA1LjIuIEkgc3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0 ZWQNCj4+ICAgICByZXF1aXJlbWVudHMNCj4+ICAgICBsaXN0Lg0KPj4NCj4+ICAgICBbQXV0aG9y c10gT0ssIHdlIHdpbGwgdXNlIG51bWJlcnMuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gU2Vj dGlvbiA1LjI6IEZpcnN0IHBhcmFncmFwaCBhbmQgZm9ydGggYnVsbGV0IGxhc3Qgc2VudGVuY2Uu IFRoZXNlDQo+PiAgICAgYm90aCBiYXNpY2FsbHkgY292ZXIgdGhlIHNhbWUgdG9waWMgKHByZWVt cHRpb24pIGFuZCBhY3R1YWxseSBzYXkNCj4+ICAgICBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdz LiBJIHN1Z2dlc3QgY29tYmluZSBpbnRvIGEgc2luZ2xlDQo+PiAgICAgcmVxdWlyZW1lbnQgdG8g ZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBmdWxsIGNvdmVyYWdlIG9mIHRoZSB0b3BpYy4NCj4+DQo+ PiAgICAgW0F1dGhvcnNdIFRoZSBmaXJzdCBwYXJhZ3JhcGggaXMgZm9yIHNvZnQtcHJlZW1wdGlv biwgd2hpbGUgdGhlDQo+PiAgICAgZm91cnRoIGJ1bGxldCBiZWxvbmdzIHRvIHRoZSByZXF1aXJl bWVudHMgb2YgaGFyZC1wcmVlbXB0aW9uLg0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDUuMiwg cmVxIDUuIEhvdyBkb2VzIHRoaXMgcmVsYXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3QNCj4+ ICAgICB0aGUgdG9waWNzIHJlbGF0ZWQgdG8gdGltaW5nIGJlIGNvbnNvbGlkYXRlZD8NCj4+DQo+ PiAgICAgW0F1dGhvcnNdIFllcywgcmVxIDUgY2FuIGJlIG1vdmVkIHRvIFNlY3Rpb24gNS41Lg0K Pj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4yOiByZXF1aXJlbWVudCA2IHNlZW1z IHRvIGJlIGEgc3Vic2V0IG9mIDcsIHNvIGl0DQo+PiAgICAgc2hvdWxkIGJlDQo+PiAgICAgZHJv cHBlZC4NCj4+DQo+PiAgICAgW0F1dGhvcnNdIFllcywgaXQgd2lsbCBiZSBkZWxldGVkLg0KPj4N Cj4+DQo+PiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1lbnQgOC4gSXNuJ3QgdGhpcyBhIHN1 YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCj4+ICAgICBqdXN0IHRoaXMgb25lIHRyYWZmaWMgdHJl YXRtZW50IChzdWIpIHJlcXVpcmVtZW50Pw0KPj4NCj4+ICAgICBbQXV0aG9yc10gUmVxLiA5IHdp bGwgYmUgZGVsZXRlZCBhcyBpdCBzZWVtcyB0byByZXF1aXJlIGNvbnRyb2wNCj4+ICAgICBwbGFu ZSBzdXBwb3J0cy4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4zLiBzL01BWS93aWxs DQo+Pg0KPj4gICAgIFtBdXRob3JzXSBPSy4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgLSBzZWN0 aW9uIDUuNDogIiBXaGVuIHRoZSB3b3JraW5nIHBhdGggZGV0ZWN0cy4uIiBkZXRlY3Rpb24gaXMg YnkgdGhlDQo+PiAgICAgbm9kZSBub3QgdGhlIHBhdGguDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBZ ZXMuIFdlIHdpbGwgc2ltcGx5IHNheSB0aGF0IKGwV2hlbiB0aGUgY29uZGl0aW9uIHRoYXQNCj4+ ICAgICB0cmlnZ2VyZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIGlzIGNsZWFyZWQsIKGmobEN Cj4+DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjQsIGxhc3Qgc2VudGVuY2UuIFRoaXMgaXMgb25s eSB0aGUgMm5kIHRpbWUgeW91IGltcGx5IHRoYXQNCj4+ICAgICB0aGUgZG9jdW1lbnQgY292ZXJz IHJlcXVpcmVtZW50cyBvbiBhIG5ldyBwcm90b2NvbC4gSSB0aGluayB0aGlzDQo+PiAgICAgcG9p bnQgaXMgY3VycmVudGx5IHRvbyBzdWJ0bGUgaW4gdGhlIGRvY3VtZW50LiAoVGhpcyBwb2ludCB3 YXMgYWxzbw0KPj4gICAgIG1hZGUgYXMgYSBtaW5vciBjb21tZW50LikNCj4+DQo+PiAgICAgW0F1 dGhvcnNdIEFzIGluIG90aGVyIHByb3RlY3Rpb24gc3dpdGNoaW5nIHRlY2hub2xvZ2llcywgdHdv IG1vZGVzDQo+PiAgICAgb2Ygb3BlcmF0aW9ucyAocmV2ZXJ0aXZlIGFuZCBub24tcmV2ZXJ0aXZl KSBhcmUgcmVxdWlyZWQuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gc2VjdGlvbiA1LjYuIFJG QyA2MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBXZSB3aWxs IGFkZCChsGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3Ml2hsSB0byB0aGUgZW5kcyBvZg0KPj4gICAg IHR3byBwYXJhZ3JhcGhzIGZvciBXVFIgdGltZXIgYW5kIGhvbGQtb2ZmIHRpbWVyLg0KPj4NCj4+ DQo+Pg0KPj4gICAgICoqKioqIEVuZCBvZiBDb21tZW50IHJlc29sdXRpb24gKioqKioNCj4+DQo+ Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ICAgICAqurizvSC7 57b3IDogKiJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldA0KPj4gICAgIDxtYWlsdG86bGJl cmdlckBsYWJuLm5ldD4+DQo+PiAgICAgKrq4s70gs6/CpSA6ICoyMDE0LTA2LTIyIDAxOjAwOjQ4 ICggKzA5OjAwICkNCj4+ICAgICAqud60wiC757b3IDogKnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcN Cj4+ICAgICA8bWFpbHRvOnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc+IDxydGctYWRzQHRvb2xzLmll dGYub3JnDQo+PiAgICAgPG1haWx0bzpydGctYWRzQHRvb2xzLmlldGYub3JnPj4NCj4+ICAgICAq wvzBtiA6ICpydGctZGlyQGlldGYub3JnIDxtYWlsdG86cnRnLWRpckBpZXRmLm9yZz4NCj4+ICAg ICA8cnRnLWRpckBpZXRmLm9yZyA8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+PiwNCj4+ICAgICBk cmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4+ICAg ICA8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRm Lm9yZz4NCj4+ICAgICA8ZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xz LmlldGYub3JnDQo+PiAgICAgPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50 cy5hbGxAdG9vbHMuaWV0Zi5vcmc+PiwNCj4+ICAgICBtcGxzQGlldGYub3JnIDxtYWlsdG86bXBs c0BpZXRmLm9yZz4gPG1wbHNAaWV0Zi5vcmcNCj4+ICAgICA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+ Pg0KPj4gICAgICrBprjxIDogKlttcGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMt c21wLXJlcXVpcmVtZW50cy0wNi50eHQNCj4+DQo+Pg0KPj4gICAgIEhlbGxvLA0KPj4NCj4+ICAg ICBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdl ciBmb3IgdGhpcw0KPj4gICAgIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3INCj4+ICAgICByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFz IHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHDQo+PiAgICAgcmV2aWV3 LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJl dmlldyBpcw0KPj4gICAgIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMu IEZvciBtb3JlIGluZm9ybWF0aW9uDQo+PiAgICAgYWJvdXQgdGhlDQo+PiAgICAgUm91dGluZyBE aXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KPj4gICAgIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4+DQo+PiAgICAgQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZw0KPj4gICAgIEFE cywgaXQNCj4+ICAgICB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVt IGFsb25nIHdpdGggYW55IG90aGVyIElFVEYNCj4+ICAgICBMYXN0IENhbGwgY29tbWVudHMgdGhh dCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0NCj4+ICAgICB0aHJvdWdo DQo+PiAgICAgZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+Pg0KPj4gICAg IERvY3VtZW50OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50eHQNCj4+ICAg ICBSZXZpZXdlcjogTG91IEJlcmdlcg0KPj4gICAgIFJldmlldyBEYXRlOiBKdW5lIDIxIDIwMTQN Cj4+ICAgICBJRVRGIExDIEVuZCBEYXRlOiAyMDE0LTA2LTIzDQo+PiAgICAgSW50ZW5kZWQgU3Rh dHVzOiBJbmZvcm1hdGlvbmFsDQo+Pg0KPj4gICAgIFN1bW1hcnk6DQo+PiAgICAgSSBoYXZlIHNv bWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsNCj4+ICAg ICBzaG91bGQgKG11c3QsIGFjdHVhbGx5KSBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24u DQo+Pg0KPj4gICAgIENvbW1lbnRzOg0KPj4NCj4+ICAgICBJIHRoaW5rIHRoZSBkb2N1bWVudCBp cyB3ZWxsIHdyaXR0ZW4gYW5kLCBvdGhlciB0aGFuIGEgY291cGxlIG9mDQo+PiAgICAgdGVybWlu b2xvZ3kgcmVsYXRlZCBpc3N1ZXMsIGVhc2lseSB1bmRlcnN0b29kLiBUaGUgZG9jdW1lbnQgZG9l cw0KPj4gICAgIGhhdmUgYSBudW1iZXIgb2YgdGVybWlub2xvZ3kgYW5kIHRlY2huaWNhbCBpc3N1 ZXMgd2hpY2ggc2hvdWxkIGJlDQo+PiAgICAgcmVhZGlseSByZXNvbHZlZCBwcmlvciB0byBwdWJs aWNhdGlvbi4NCj4+DQo+PiAgICAgTWFqb3IgSXNzdWVzOg0KPj4NCj4+ICAgICBNYWpvciBpc3N1 ZXMgYXJlIHRoZSB0eXBlIG9mIGNvbmNlcm5zIHRoYXQgd2lsbCByZXN1bHQgaW4gdGhlDQo+PiAg ICAgZG9jdW1lbnQgYmVpbmcgYmxvY2tlZCB1bnRpbCB0aGV5IGFyZSByZXNvbHZlZC4gVGhlIFJv dXRpbmcgQURzIHdpbGwNCj4+ICAgICBiZWNvbWUgaW52b2x2ZWQuIFBsZWFzZSBpbmNsdWRlIGFs bCBvZiB0aGUgbWFqb3IgaXNzdWVzIHlvdSBoYXZlDQo+PiAgICAgZm91bmQuIEdpdmUgYXMgbXVj aCBjb250ZXh0IGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIChlLmcuLCBzZWN0aW9uDQo+PiAgICAg bnVtYmVycywgcGFyYWdyYXBoIGNvdW50cykuIElmIHlvdSBmaW5kIG5vIG1ham9yIGlzc3Vlcywg cGxlYXNlDQo+PiAgICAgd3JpdGU6ICJObyBtYWpvciBpc3N1ZXMgZm91bmQuIg0KPj4NCj4+ICAg ICAtIE5vIG1ham9yIGlzc3VlcyBmb3VuZC4gSW4gcGFydGljdWxhciwgSSBleHBlY3QgYWxsIGlz c3VlcyBjYW4gYmUNCj4+ICAgICByZXNvbHZlZCB3aXRob3V0IEFEIGludGVydmVudGlvbi4gU29t ZSBvZiB0aGUgbWlub3IgaXNzdWVzLCBpZiBub3QNCj4+ICAgICByZXNvbHZlZCB3aWxsIGJlIGVz Y2FsYXRlZCB0byB0aGUgQUQvbWFqb3IgaXNzdWUgY2F0ZWdvcnkuDQo+Pg0KPj4gICAgIE1pbm9y IElzc3VlczoNCj4+DQo+PiAgICAgTWlub3IgaXNzdWVzIGFyZSBjb25jZXJucyBhYm91dCBjbGFy aXR5IG9yIHRlY2huaWNhbCBhY2N1cmFjeSB0aGF0DQo+PiAgICAgc2hvdWxkIGJlIGRpc2N1c3Nl ZCBhbmQgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLCBidXQgd2hpY2ggd291bGQNCj4+ICAg ICBub3JtYWxseSBiZSByZXNvbHZlZCBiZXR3ZWVuIHRoZSBhdXRob3JzIGFuZCB0aGUgcmV2aWV3 ZXJzLiBQbGVhc2UNCj4+ICAgICBpbmNsdWRlIGFsbCBvZiB0aGUgbWlub3IgaXNzdWVzIHlvdSBo YXZlIGZvdW5kLiBHaXZlIGFzIG11Y2ggY29udGV4dA0KPj4gICAgIGluZm9ybWF0aW9uIGFzIHBv c3NpYmxlIChlLmcuLCBzZWN0aW9uIG51bWJlcnMsIHBhcmFncmFwaCBjb3VudHMpLg0KPj4gICAg IElmIHlvdSBmaW5kIG5vIG1pbm9yIGlzc3VlcywgcGxlYXNlIHdyaXRlOiAiTm8gbWlub3IgaXNz dWVzIGZvdW5kLiINCj4+DQo+PiAgICAgLSBEb2N1bWVudCdzIHVzYWdlIG9mICJjb21taXR0ZWQi IHZzICJhbGxvY2F0ZWQiIHJlc291cmNlczoNCj4+DQo+PiAgICAgSW4gc2VjdGlvbiAxIHRoZSBk b2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBub3Rpb24gdGhhdCB0aGUNCj4+ICAgICBkaXN0aW5jdGlv biBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIGJhc2VkIG9uIHdoZW4NCj4+ ICAgICByZXNvdXJjZXMgYXJlICJjb21taXR0ZWQiLiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBwYXN0 DQo+PiAgICAgZGVmaW5pdGlvbi4gUkZDNDQyNyBhbmQgNjM3MiBtYWtlIHRoZSBkaXN0aW5jdGlv biB0aGF0IHByb3RlY3Rpb24NCj4+ICAgICBhbmQgcmVzdG9yYXRpb24gZGlmZmVyIGJhc2VkIG9u IHdoZW4gcmVzb3VyY2VzIGFyZSAqYWxsb2NhdGVkKiBub3QNCj4+ICAgICAqY29tbWl0dGVkKi4g VG8gcXVvdGUgUkZDIDQ0Mjc6DQo+Pg0KPj4gICAgIFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHBy b3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIG1hZGUgYmFzZWQNCj4+ICAgICBvbiB0aGUgcmVz b3VyY2UgYWxsb2NhdGlvbiBkb25lIGR1cmluZyB0aGUgcmVjb3ZlcnkgTFNQL3NwYW4NCj4+ICAg ICBlc3RhYmxpc2htZW50LiBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBkaWZmZXJlbnQgdHlwZXMg b2YNCj4+ICAgICByZXN0b3JhdGlvbiBpcyBtYWRlIGJhc2VkIG9uIHRoZSBsZXZlbCBvZiByb3V0 ZSBjb21wdXRhdGlvbiwNCj4+ICAgICBzaWduYWxpbmcsIGFuZCByZXNvdXJjZSBhbGxvY2F0aW9u IGR1cmluZyB0aGUgcmVzdG9yYXRpb24NCj4+ICAgICBMU1Avc3BhbiBlc3RhYmxpc2htZW50Lg0K Pj4NCj4+ICAgICBUaGlzIGRpZmZlcmVuY2UgYWxzbyBsZWFkcyB0byBjb21lIGNvbmZ1c2VkIHN0 YXRlbWVudHMgaW4gdGhlDQo+PiAgICAgZG9jdW1lbnQgYXMgd2VsbCBhcyBhbWJpZ3VpdHkgaW4g dGhlIHRleHQsIGkuZS4gY29uZnVzaW9uIGJ5IHRoZQ0KPj4gICAgIHJlYWRlci4gVGhlIHRlcm0g ImNvbW1pdHRlZCIgaXMgbm90IHRpZ2h0bHkgZGVmaW5lZCBpbiB0aGlzDQo+PiAgICAgZG9jdW1l bnQgKG9yIGVhcmxpZXIgd29yaykgYW5kIGlzIHVzZWQgZGlmZmVyZW50bHkgdGhhbiBob3cNCj4+ ICAgICAiYWxsb2NhdGVkIiBoYXMgYmVlbiB1c2VkLiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJl IGZvdW5kIGluDQo+PiAgICAgU2VjdGlvbiAzLjEgd2hpY2ggc3RhdGVzOg0KPj4NCj4+ICAgICBI b3dldmVyLCB0aGUgY29tbWl0bWVudCBvZiB0aGUgcmVzb3VyY2VzLCBhdCBsZWFzdCBmb3IgdGhl DQo+PiAgICAgc2hhcmVkIHNlZ21lbnRzLCB3aWxsIG9ubHkgYmUgZmluYWxpemVkIHdoZW4gdGhl IHByb3RlY3Rpb24NCj4+ICAgICBwYXRoIGlzIGFjdHVhbGx5IGFjdGl2YXRlZC4gVGhlcmVmb3Jl LCBmb3IgdGhlIHB1cmlzdHMgLQ0KPj4gICAgIHJlZ2FyZGluZyB0aGUgdGVybWlub2xvZ3kgLSBT TVAgbGllcyBzb21ld2hlcmUgYmV0d2Vlbg0KPj4gICAgIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0 aW9uLg0KPj4NCj4+ICAgICBCb3RoIHNlbnRlbmNlcyBhcmUgcHJvYmxlbWF0aWMuIEluIHRoZSBm aXJzdCwgY29tbWl0bWVudCBzZWVtcyB0bw0KPj4gICAgIGNvdmVyIGEgInByb3RlY3Rpb24gc3dp dGNoIiB3b3VsZCAiY29ubmVjdCIgdGhlIHByb3RlY3Rpb24gcGF0aA0KPj4gICAgIGJ1dCBub3Qg dGhlIGVhcmxpZXIgImFsbG9jYXRpb24iIG9mIHJlc291cmNlcy4gKFF1b3RlZCB0ZXJtcyBhcmUN Cj4+ICAgICB1c2VkIGluIGVhcmxpZXIgUkZDcy4pIFRoZSBzZWNvbmQgY29uY2x1c2lvbiBpcyBi YXNlZCBvbiB0aGUgbmV3DQo+PiAgICAgZGlzdGluY3Rpb24gb2YgcHJvdGVjdGlvbiB2cy4gcmVz dG9yYXRpb24gYW5kIGlzIHVubmVjZXNzYXJ5IHdpdGgNCj4+ICAgICB0aGUgZXhpc3RpbmcgZGlz dGluY3Rpb24uDQo+Pg0KPj4gICAgIFRoaXMgaXNzdWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNl cyBpbiB0aGUgZG9jdW1lbnQgd2hlcmUNCj4+ICAgICAiY29tbWl0dGVkIiBpcyB1c2VkIGFuZCBJ J2QgcmVjb21tZW5kIHRoYXQgZWFjaCBzaG91bGQgYmUgcmVwbGFjZWQNCj4+ICAgICB3aXRoIHRl cm1pbm9sb2d5IHVzZWQgaW4gdGhlIHJlZmVyZW5jZWQgUkZDcywgaS5lLiwgImFsbG9jYXRpb24i LA0KPj4gICAgICJjb25uZWN0aW9uIiwgImNyb3NzLWNvbm5lY3QiLCAicHJvdGVjdGlvbiBzd2l0 Y2gob3ZlcikiLCAuLi4NCj4+DQo+PiAgICAgTm90ZSBJJ20gKm5vdCogaGlnaGxpZ2h0aW5nIGFs bCBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgcHJvYmxlbXMgaW4gdGhlDQo+PiAgICAgZG9jdW1lbnQg cmVsYXRlZCB0byB0aGlzIGlzc3VlLiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcGxhY2VzIGluIHRo ZQ0KPj4gICAgIGRvY3VtZW50IHdoZXJlIEkgdGhpbmsgaXQncyBwb3NzaWJsZSB0aGF0IG9uY2Ug dGhpcyB0ZXJtaW5vbG9neQ0KPj4gICAgIGFtYmlndWl0eSBpcyBjb3JyZWN0ZWQgdGhhdCBJJ2xs IGhhdmUgb3RoZXIgc3Vic3RhbnRpdmUgY29tbWVudHMuDQo+Pg0KPj4gICAgIC0gU2VjdGlvbiAy LCAxc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLiBUaGlzIHNlbnRlbmNlIHJlYWxseQ0KPj4g ICAgIGRlZmluZXMNCj4+ICAgICB0aGUgc2NvcGUvcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQsIGku ZS4sICJjbGFyaWZpZXMgdGhlIGluc3RydWN0aW9ucw0KPj4gICAgIHRvIHByb3RvY29sIGRlc2ln bmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0aGUNCj4+ICAgICByZXF1aXJl bWVudHMgc2V0IG91dCBpbiB0aGlzIGRvY3VtZW50LiIgQXMgc3VjaCwgSSdkIHJlcGVhdCB0aGlz IGluDQo+PiAgICAgdGhlIGFic3RyYWN0IGFuZCBtb3ZlIGl0IHRvIGEgbW9yZSBwcm9ub3VuY2Vk IHBsYWNlIGluIHNlY3Rpb24gMSAob3INCj4+ICAgICAzKS4NCj4+DQo+PiAgICAgLSBHZW5lcmFs IGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQo+ PiAgICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJvdXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2 ZXJzZSBwYXRoIGluIFNNUD8NCj4+ICAgICBJJ2QgYXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0 Y2ggY29vcmRpbmF0aW9uIHByb3RvY29sIHdvdWxkIGJlDQo+PiAgICAgcmVxdWlyZWQgdG8gdHJp Z2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVyc2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCj4+ ICAgICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhlIGRvY3VtZW50Lg0KPj4NCj4+ICAg ICAtIEluIHNlY3Rpb24gNCBhbmQgNS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBhcyBk ZWZpbmluZw0KPj4gICAgIHByZWVtcHRpb24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRo aW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+PiAgICAgcmVmZXJlbmNlIGhlcmUgYXMgaXQgZGVmaW5l cyBib3RoIGluIHRoZSBjb250ZXh0IG9mIHN1cnZpdmFiaWxpdHkgYW5kDQo+PiAgICAgaW4gZGVw ZW5kZW50IG9mIGNvbnRyb2wgcGxhbmUuDQo+Pg0KPj4gICAgIC0gSW4gc2VjdGlvbiA0LjIgeW91 IHNheSAiVGhlcmVmb3JlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGJlDQo+PiAgICAgY2Fy cmllZCBvdXQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgc2lt aWxhciB0bw0KPj4gICAgIEdNUExTIFtSRkMzOTQ1XS4iIHBlcmhhcHMgeW91IG1lYW4gImJhc2Vk IG9uIEdNUExTIj8gSWYgc28sIGdyZWF0LA0KPj4gICAgIHBsZWFzZSBtYWtlIHRoZSBjb3JyZWN0 aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0ZSBvZiB3aGljaA0KPj4gICAgIGNvbnRyb2wg cHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBpcyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0 aGlzDQo+PiAgICAgZG9jdW1lbnQuDQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjEsIHBhcmFncmFw aCAxLiBXaHkgYXJlIHlvdSB1c2luZyAiU0hPVUxEIE5PVCIgaGVyZT8gSWYNCj4+ICAgICByZWZl cnJpbmcgdG8gc29sdXRpb25zIGNvbmZvcm1hbnQgd2l0aCB0aGlzIGRvY3VtZW50LCB0aGVuIHRo ZXNlIGFyZQ0KPj4gICAgIGluZm9ybWF0aXZlIHN0YXRlbWVudHMsICJhbmQgYSBub24tY29udHJv bCBwbGFuZSBiYXNlZCBTTVAgc3dpdGNob3Zlcg0KPj4gICAgIG1lY2hhbmlzbSBpcyB1c2VkLCB0 aGUgY29udHJvbCBwbGFuZSBTSEFMTCBOT1QgLi4uIi4gSWYgcmVmZXJyaW5nIHRvDQo+PiAgICAg YW4gb3BlcmF0b3Incy91c2VyJ3MgY2hvaWNlIG9mIHByb3RlY3Rpb24gbWVjaGFuaXNtLCBJIHRo aW5rIHRoZSBtb3N0DQo+PiAgICAgeW91IGNhbiBzYXkgaXMgTUFZLg0KPj4NCj4+ICAgICAtIFNl Y3Rpb24gNS4yLiAiVGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUg b2YgYW4gU01QDQo+PiAgICAgZG9tYWluLiIgQXMgdGhpcyBpcyBhIHJlcXVpcmVtZW50LCB3aGF0 IHlvdSBtZWFuIGJ5ICJ0aWUtYnJlYWtpbmcNCj4+ICAgICBydWxlcyIgc2hvdWxkIGJlIGRlZmlu ZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNlLg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4zLiBS RkM2MzcyIHRha2VzIGFuIGFwcHJvYWNoIHdoZXJlIHByZWVtcHRpb24gbm90aWZpY2F0aW9uDQo+ PiAgICAgbGV2ZXJhZ2VzIHRoZSBzdGFuZGFyZCBNUExTLVRQIE9BTSBtZWNoYW5pc21zLCBpcyB0 aGVyZSBhbnkgcmVhc29uIHRvDQo+PiAgICAgZG8gbW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2Mzcy Pw0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9uIHJl cXVpcmVkIG9uDQo+PiAgICAgc29mdC1wcmVlbXB0aW9uIGFzDQo+PiAgICAgd2VsbCAoZGVwZW5k aW5nIG9uIHRoZSBjcm9zcy1jb25uZWN0cyBlc3RhYmxpc2hlZCBkdXJpbmcgTFNQDQo+PiAgICAg ZXN0YWJsaXNobWVudCkgc28gY29vcmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBiZSBzdXBwb3J0 ZWQNCj4+ICAgICBpbmRlcGVuZGVudCBvZiBwcmVlbXB0aW9uIG1vZGUuDQo+Pg0KPj4gICAgIE5p dHM6DQo+Pg0KPj4gICAgIC0gQWJzdHJhY3Q6IEkgZG9uJ3QgcmVjYWxsIHRoZSB0ZXJtICJleGVj dXRpdmUgYWN0aW9uIiBiZWluZyB1c2VkDQo+PiAgICAgaW4gYW55DQo+PiAgICAgZWFybGllciBy ZWxhdGVkL3JlZmVyZW5jZWQgUkZDcy4gUmF0aGVyIHRoYW4gaW50cm9kdWNlIGEgbmV3IChhbmQN Cj4+ICAgICB1bmRlZmluZWQpIHRlcm0sIHBlcmhhcHMgeW91IGNhbiB1c2UgYW4gZXhpc3Rpbmcg b25lLCBlLmcuLA0KPj4gICAgICJwcm90ZWN0aW9uIHN3aXRjaCI/DQo+Pg0KPj4gICAgIC0gU2Vj dGlvbiAxLCBwYXJhZ3JhcGggMS4gRG8gd2UgcmVhbGx5IG5lZWQgYW5vdGhlciBkZWZpbml0aW9u IG9mDQo+PiAgICAgTVBMUy1UUCB0byBkZWJhdGU/IEkgc3VnZ2VzdCBqdXN0IHJlZmVyZW5jaW5n IHlvdXIgZmF2b3JpdGUgTVBMUy1UUA0KPj4gICAgIGRvY3VtZW50KHMpIGFuZCBkcm9wcGluZyB0 aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMuDQo+Pg0KPj4gICAgIFRoZSBsYXN0IHNlbnRlbmNlIGFs c28gbWFrZXMgYSBzdWJqZWN0aXZlIHN0YXRlbWVudC4gV2hldGhlciBpdCBpcw0KPj4gICAgIGNy aXRpY2FsIG9yIG5vIGlzIHVubmVjZXNzYXJ5LiBZb3UgY2FuIGp1c3Qgc2F5IHNvbWV0aGluZyBs aWtlIDYzNzINCj4+ICAgICBwcm92aWRlcyBhIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGZvciBN UExTLVRQIGFuZCBpcyB0aGUgZm91bmRhdGlvbg0KPj4gICAgIGZvciB0aGlzIGRvY3VtZW50Lg0K Pj4NCj4+ICAgICAtIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElzbid0IHRoZSByaWdodCByZWZl cmVuY2UgNDQyNyBub3QgNDQyOD8NCj4+ICAgICBBbHNvIGRyb3AgdGhlIHdvcmQgbGluZWFyLCBh cyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZpZXIgYW5kDQo+PiAgICAgNDQyNy80NDI4IGRv bid0IHVzZSBpdC4NCj4+DQo+PiAgICAgLSBTZWN0aW9ucyAzIChhbmQgdG8gYSBsZXNzZXIgZGVn cmVlIHNlY3Rpb24gMikgYXJlIHJlYWxseQ0KPj4gICAgIGludHJvZHVjdG9yeQ0KPj4gICAgIHRl eHQuIEknbSB1bnN1cmUgYXMgdG8gd2h5IHRoZXkgYXJlbid0IHBhcnQgb2Ygc2VjdGlvbiAxLg0K Pj4NCj4+ICAgICAtIFNlY3Rpb24gMy4yIHNob3VsZCBoYXZlIGEgcmVmZXJlbmNlIGZvciAiZXhp c3RpbmcgY29udHJvbCBwbGFuZQ0KPj4gICAgIHNvbHV0aW9ucyBmb3IgU01QIHdpdGhpbiBNUExT Ii4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDMuMiBhZ2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZlIGFj dGlvbiIgdGVybS4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDQuMS4gWW91IHNheSAidHdvIG9wZXJh dGlvbnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3UgcmVhbGx5DQo+PiAgICAgbWVhbiAic2ltdWx0 YW5lb3VzbHkiIG9yIG1lcmVseSB0aGF0IHRoZXkgbXVzdCBib3RoIG9jY3VyIGZvcg0KPj4gICAg IHByb3RlY3Rpb24gdG8gYmUgcHJvdmlkZWQ/IChTYW1lIGNvbW1lbnQgaW4gc2VjdGlvbiA1LjEu DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjIuIEkgc3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJl bnRseSBidWxsZXR0ZWQNCj4+ICAgICByZXF1aXJlbWVudHMNCj4+ICAgICBsaXN0Lg0KPj4NCj4+ ICAgICAtIFNlY3Rpb24gNS4yOiBGaXJzdCBwYXJhZ3JhcGggYW5kIGZvcnRoIGJ1bGxldCBsYXN0 IHNlbnRlbmNlLiBUaGVzZQ0KPj4gICAgIGJvdGggYmFzaWNhbGx5IGNvdmVyIHRoZSBzYW1lIHRv cGljIChwcmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkgc2F5DQo+PiAgICAgc2xpZ2h0bHkgZGlmZmVy ZW50IHRoaW5ncy4gSSBzdWdnZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZQ0KPj4gICAgIHJlcXVp cmVtZW50IHRvIGVuc3VyZSBjb25zaXN0ZW5jeSBhbmQgZnVsbCBjb3ZlcmFnZSBvZiB0aGUgdG9w aWMuDQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjIsIHJlcSA1LiBIb3cgZG9lcyB0aGlzIHJlbGF0 ZSB0byBzZWN0aW9uIDUuNT8gU2hvdWxkbid0DQo+PiAgICAgdGhlIHRvcGljcyByZWxhdGVkIHRv IHRpbWluZyBiZSBjb25zb2xpZGF0ZWQ/DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjI6IHJlcXVp cmVtZW50IDYgc2VlbXMgdG8gYmUgYSBzdWJzZXQgb2YgNywgc28gaXQNCj4+ICAgICBzaG91bGQg YmUNCj4+ICAgICBkcm9wcGVkLg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4yLCByZXF1aXJlbWVu dCA4LiBJc24ndCB0aGlzIGEgc3Vic2V0IG9mIDk/IFdoeSBjYWxsIG91dA0KPj4gICAgIGp1c3Qg dGhpcyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/DQo+Pg0KPj4gICAg IC0gU2VjdGlvbiA1LjMuIHMvTUFZL3dpbGwNCj4+DQo+PiAgICAgLSBzZWN0aW9uIDUuNDogIiBX aGVuIHRoZSB3b3JraW5nIHBhdGggZGV0ZWN0cy4uIiBkZXRlY3Rpb24gaXMgYnkgdGhlDQo+PiAg ICAgbm9kZSBub3QgdGhlIHBhdGguDQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjQsIGxhc3Qgc2Vu dGVuY2UuIFRoaXMgaXMgb25seSB0aGUgMm5kIHRpbWUgeW91IGltcGx5IHRoYXQNCj4+ICAgICB0 aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBhIG5ldyBwcm90b2NvbC4gSSB0aGlu ayB0aGlzDQo+PiAgICAgcG9pbnQgaXMgY3VycmVudGx5IHRvbyBzdWJ0bGUgaW4gdGhlIGRvY3Vt ZW50LiAoVGhpcyBwb2ludCB3YXMgYWxzbw0KPj4gICAgIG1hZGUgYXMgYSBtaW5vciBjb21tZW50 LikNCj4+DQo+PiAgICAgLSBzZWN0aW9uIDUuNi4gUkZDIDYzNzIgc2hvdWxkIGJlIHJlZmVyZW5j ZWQNCj4+DQo+Pg0KPj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiAgICAgbXBscyBtYWlsaW5nIGxpc3QNCj4+ICAgICBtcGxzQGlldGYub3Jn IDxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+PiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ICAgICBtcGxzIG1haWxpbmcgbGlzdA0KPj4gICAgIG1w bHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4gICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4NCg0K From nobody Thu Jul 10 13:05:50 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D521B29AB; Thu, 10 Jul 2014 13:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i6alAcNirnT; Thu, 10 Jul 2014 13:05:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7941D1B29A8; Thu, 10 Jul 2014 13:05:45 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 20:05:42 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 20:05:42 +0000 From: John E Drake To: "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-etree-frwk-06.txt Thread-Index: Ac+cdCxlkUqZZ2i0RBSAIPtolwe6aw== Date: Thu, 10 Jul 2014 20:05:42 +0000 Message-ID: <49da5e94288044e6bac36dc58013f0b1@BLUPR05MB562.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377424004)(199002)(189002)(83322001)(50986999)(85852003)(101416001)(21056001)(85306003)(99396002)(105586002)(95666004)(19580395003)(15975445006)(106356001)(83072002)(2351001)(64706001)(86362001)(99286002)(110136001)(66066001)(77982001)(80022001)(46102001)(92566001)(4396001)(74662001)(87936001)(20776003)(81342001)(74502001)(2656002)(54356999)(229853001)(76482001)(76576001)(74316001)(107046002)(79102001)(15202345003)(33646001)(31966008)(81542001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/7jvP1YpeeBU77t0ok1E3UuUwJhg Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-etree-frwk.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-etree-frwk-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:05:48 -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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-l2vpn-etree-frwk-06.txt Reviewer: John Drake Review Date: July 10 2014 IETF LC End Date: 2014-07-13 Intended Status: Informational Summary: =20 The document is ready for publication. Comments: I think the document is well written and easily understood. =20 Major Issues: Major issues are the type of concerns that will result in the document being blocked until they are resolved. The Routing ADs will become involved. Please include all of the major issues you have found. Give as much context information as possible (e.g., section numbers, paragraph counts). If you find no major issues, please write: "No major issues found." No major issues found Minor Issues: Minor issues are concerns about clarity or technical accuracy that should be discussed and resolved before publication, but which would normally be resolved between the authors and the reviewers. Please include all of the minor issues you have found. Give as much context information as possible (e.g., section numbers, paragraph counts). If you find no minor issues, please write: "No minor issues found." No minor issues found Nits: None Yours Irrespectively, John From nobody Fri Jul 11 12:10:16 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E631A0B11 for ; Fri, 11 Jul 2014 12:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UywLb-Z4WQFE for ; Fri, 11 Jul 2014 12:10:14 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id D721D1A0AE8 for ; Fri, 11 Jul 2014 12:10:12 -0700 (PDT) Received: (qmail 11779 invoked by uid 0); 11 Jul 2014 19:10:10 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 11 Jul 2014 19:10:10 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id RDA01o01T2SSUrH01DA3Sk; Fri, 11 Jul 2014 19:10:08 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=ZSdzdHkL1-cA:10 a=zCehyBWSIz4A:10 a=HFCU6gKsb0MA:10 a=jPJDawAOAc8A:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=XKRAzt7loxlGrBEaZkYA:9 a=QEXdDO2ut3YA:10 a=33rK67OTR_gA:10 a=Flg0Rsxmn5MA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=FuDokubYgHNNcktFSkueE4DTPGz6M7331E71WQS+Eqo=; b=Yv8V0DW5XmnFuqs8hZoAFlIYB0FmN+QZ4jaXUoeGJ9o1xoIVph2s+ET5mKoiU8QeXS+JAwoSSXg71XnZjelo1Ka+KeF1tnuv/EhCteeeLIcZAu3eIJ6MYQ8p33aeTUTP; Received: from box313.bluehost.com ([69.89.31.113]:60059 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X5gCo-000532-88; Fri, 11 Jul 2014 13:10:02 -0600 Message-ID: <53C03687.2000007@labn.net> Date: Fri, 11 Jul 2014 15:09:59 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?66WY7KCV64+Z?= References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info>, <53BE7F3B.9010005@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749804@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749804@SMTP2.etri.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ZRdri1TnKFhc7uf0mdQy8kUwT9E Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] =?utf-8?b?7ZqM7IugOiDtmozsi6A6ICBbbXBsc10gUnRnRGlyIHJl?= =?utf-8?q?view=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 19:10:15 -0000 Thank you -- just one response and suggested change. Lou On 07/10/2014 09:43 AM, ë¥˜ì •ë™ wrote: > Lou, > > Thank you for agreeing on most of the suggestions. > Please, see the lines starting with [JR2] below. > > Best regards, > > Jeong-dong > > > ________________________________________ > 보낸 사람: Lou Berger [lberger@labn.net] ... >> This is fine, but I wonder why you are using "resource utilization" vs > "protection switch"? (this is actually a bit of a general comment -- I > the latter is an existing applicable term that would help readers how > this document fits in to the technology space.) >> >> [JR] As described in an earlier part of this section, SMP protection > consists of two operations: traffic switchover and resource utilization > coordination. The sentences are about the resource utilization > coordination, and “resource utilization†seems to be more accurate. > > Is "resource utilization coordination" done via some form of inter-node > coordination? If yes, then I think my comment holds. If no, then I > think you should elabotate on how the "coordination" in this case > differes from how you use "coordination" elsewhere in the document. > Either way, I think we've discussed this enough, i.e., I won't push this > point further. > > [JR2] "resource utilization coorination" occurs between the nodes as in other protection switching. "resource utilization coordination" is a part of whole SMP protection switching coordination and is meant to emphasize that coordination is for resource utilization. Of course, the reason why it does resource utilization coordination is to complete protection switching eventually. > Okay. I think adding something along the lines of ""resource utilization coordination" is a part of whole SMP protection switching coordination " to the text would clarify your intent to future readers. ... From nobody Mon Jul 14 00:51:36 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4654E1B29AC; Fri, 11 Jul 2014 13:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.602 X-Spam-Level: X-Spam-Status: No, score=-96.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH9SIXB4VBtC; Fri, 11 Jul 2014 13:44:10 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA47C1A0406; Fri, 11 Jul 2014 13:44:09 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 12 Jul 2014 05:44:09 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Sat, 12 Jul 2014 05:44:05 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger Thread-Topic: =?ks_c_5601-1987?B?W1JURy1ESVJdIMi4vcU6IMi4vcU6ICBbbXBsc10gUnRnRGlyIHJl?= =?ks_c_5601-1987?B?dmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMt?= =?ks_c_5601-1987?Q?06.txt?= Thread-Index: AQHPnTu+I+zt/9CorUOfYbvrcdbcUpubVend Date: Fri, 11 Jul 2014 20:44:05 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B0A@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info>, <53BE7F3B.9010005@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749804@SMTP2.etri.info>, <53C03687.2000007@labn.net> In-Reply-To: <53C03687.2000007@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/BYtwu2yw7cnnvuT9sgcOjeCnM4A X-Mailman-Approved-At: Mon, 14 Jul 2014 00:51:31 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogIMi4vcU6IMi4vcU6ICBbbXBsc10gUnRnRGly?= =?euc-kr?q?_review=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 20:44:12 -0000 TG91LCANCg0KQ2VydGFpbmx5LCBpdCBjYW4gYmUgZG9uZSBhcyB5b3Ugc3VnZ2VzdGVkLg0KSSBh bHNvIHRoaW5rIHRoYXQgeW91ciBzdWdnZXN0ZWQgY2hhbmdlIHdvdWxkIGhlbHAgdGhlIHJlYWRp YmlsaXR5IG9mIHRoaXMgZG9jdW1lbnQuDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgaGVscC4NCg0K QmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQogDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KurizvSC757b3OiBMb3UgQmVyZ2VyIFtsYmVyZ2VyQGxhYm4u bmV0XQ0KurizvSCzr8KlOiAyMDE0s+IgN7/5IDEywM8gxeS/5MDPIL/AwPwgNDowOQ0Kud60wiC7 57b3OiC3+cGktb8NCsL8wbY6IHJ0Zy1kaXJAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZzsgcnRnLWFkc0B0 b29scy5pZXRmLm9yZw0Kwaa48TogUmU6IFtSVEctRElSXSDIuL3FOiDIuL3FOiAgW21wbHNdIFJ0 Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KDQpU aGFuayB5b3UgLS0ganVzdCBvbmUgcmVzcG9uc2UgYW5kIHN1Z2dlc3RlZCBjaGFuZ2UuDQoNCkxv dQ0KDQpPbiAwNy8xMC8yMDE0IDA5OjQzIEFNLCC3+cGktb8gd3JvdGU6DQo+IExvdSwNCj4NCj4g VGhhbmsgeW91IGZvciBhZ3JlZWluZyBvbiBtb3N0IG9mIHRoZSBzdWdnZXN0aW9ucy4NCj4gUGxl YXNlLCBzZWUgdGhlIGxpbmVzIHN0YXJ0aW5nIHdpdGggW0pSMl0gYmVsb3cuDQo+DQo+IEJlc3Qg cmVnYXJkcywNCj4NCj4gSmVvbmctZG9uZw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ILq4s70gu+e29zogTG91IEJlcmdlciBbbGJlcmdlckBsYWJu Lm5ldF0NCi4uLg0KPj4gVGhpcyBpcyBmaW5lLCBidXQgSSB3b25kZXIgd2h5IHlvdSBhcmUgdXNp bmcgInJlc291cmNlIHV0aWxpemF0aW9uIiB2cw0KPiAicHJvdGVjdGlvbiBzd2l0Y2giPyAodGhp cyBpcyBhY3R1YWxseSBhIGJpdCBvZiBhIGdlbmVyYWwgY29tbWVudCAtLSBJDQo+IHRoZSBsYXR0 ZXIgaXMgYW4gZXhpc3RpbmcgYXBwbGljYWJsZSB0ZXJtIHRoYXQgd291bGQgaGVscCByZWFkZXJz IGhvdw0KPiB0aGlzIGRvY3VtZW50IGZpdHMgaW4gdG8gdGhlIHRlY2hub2xvZ3kgc3BhY2UuKQ0K Pj4NCj4+IFtKUl0gQXMgZGVzY3JpYmVkIGluIGFuIGVhcmxpZXIgcGFydCBvZiB0aGlzIHNlY3Rp b24sIFNNUCBwcm90ZWN0aW9uDQo+IGNvbnNpc3RzIG9mIHR3byBvcGVyYXRpb25zOiB0cmFmZmlj IHN3aXRjaG92ZXIgYW5kIHJlc291cmNlIHV0aWxpemF0aW9uDQo+IGNvb3JkaW5hdGlvbi4gVGhl IHNlbnRlbmNlcyBhcmUgYWJvdXQgdGhlIHJlc291cmNlIHV0aWxpemF0aW9uDQo+IGNvb3JkaW5h dGlvbiwgYW5kIKGwcmVzb3VyY2UgdXRpbGl6YXRpb26hsSBzZWVtcyB0byBiZSBtb3JlIGFjY3Vy YXRlLg0KPg0KPiBJcyAicmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIiBkb25lIHZp YSBzb21lIGZvcm0gb2YgaW50ZXItbm9kZQ0KPiBjb29yZGluYXRpb24/IElmIHllcywgdGhlbiBJ IHRoaW5rIG15IGNvbW1lbnQgaG9sZHMuICBJZiBubywgdGhlbiBJDQo+IHRoaW5rIHlvdSBzaG91 bGQgZWxhYm90YXRlIG9uIGhvdyB0aGUgImNvb3JkaW5hdGlvbiIgaW4gdGhpcyBjYXNlDQo+IGRp ZmZlcmVzIGZyb20gaG93IHlvdSB1c2UgImNvb3JkaW5hdGlvbiIgZWxzZXdoZXJlIGluIHRoZSBk b2N1bWVudC4NCj4gRWl0aGVyIHdheSwgSSB0aGluayB3ZSd2ZSBkaXNjdXNzZWQgdGhpcyBlbm91 Z2gsIGkuZS4sIEkgd29uJ3QgcHVzaCB0aGlzDQo+IHBvaW50IGZ1cnRoZXIuDQo+DQo+IFtKUjJd ICJyZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yaW5hdGlvbiIgb2NjdXJzIGJldHdlZW4gdGhlIG5v ZGVzIGFzIGluIG90aGVyIHByb3RlY3Rpb24gc3dpdGNoaW5nLiAicmVzb3VyY2UgdXRpbGl6YXRp b24gY29vcmRpbmF0aW9uIiBpcyBhIHBhcnQgb2Ygd2hvbGUgU01QIHByb3RlY3Rpb24gc3dpdGNo aW5nIGNvb3JkaW5hdGlvbiBhbmQgaXMgbWVhbnQgdG8gZW1waGFzaXplIHRoYXQgY29vcmRpbmF0 aW9uIGlzIGZvciByZXNvdXJjZSB1dGlsaXphdGlvbi4gT2YgY291cnNlLCB0aGUgcmVhc29uIHdo eSBpdCBkb2VzIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiBpcyB0byBjb21wbGV0 ZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBldmVudHVhbGx5Lg0KPg0KDQpPa2F5LiBJIHRoaW5rIGFk ZGluZyBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICIicmVzb3VyY2UgdXRpbGl6YXRpb24N CmNvb3JkaW5hdGlvbiIgaXMgYSBwYXJ0IG9mIHdob2xlIFNNUCBwcm90ZWN0aW9uIHN3aXRjaGlu ZyBjb29yZGluYXRpb24gIg0KdG8gdGhlIHRleHQgd291bGQgY2xhcmlmeSB5b3VyIGludGVudCB0 byBmdXR1cmUgcmVhZGVycy4NCi4uLg0KDQo= From nobody Mon Jul 14 00:51:37 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B411B29FB; Fri, 11 Jul 2014 13:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.402 X-Spam-Level: X-Spam-Status: No, score=-95.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEKFe8RU4oJo; Fri, 11 Jul 2014 13:45:38 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2DF1B29AC; Fri, 11 Jul 2014 13:45:37 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 12 Jul 2014 05:45:33 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Sat, 12 Jul 2014 05:45:32 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger , Yaacov Weingarten Thread-Topic: =?ks_c_5601-1987?B?W1JURy1ESVJdIMi4vcU6IMi4vcU6ICBbbXBsc10gUnRnRGlyIHJl?= =?ks_c_5601-1987?B?dmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMt?= =?ks_c_5601-1987?Q?06.txt?= Thread-Index: AQHPnTwR3Su8Nb99YkmyI+lQcafNCZubV139 Date: Fri, 11 Jul 2014 20:45:31 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B1D@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> , <53BBCE48.7060008@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749725@SMTP2.etri.info>, <53BE8141.1050506@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A2874981D@SMTP2.etri.info>, <53C0370D.1010503@labn.net> In-Reply-To: <53C0370D.1010503@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ulyGlxwCK7nzx0LFBexyOho-F9Y X-Mailman-Approved-At: Mon, 14 Jul 2014 00:51:31 -0700 Cc: "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogIMi4vcU6IMi4vcU6ICBbbXBsc10gUnRnRGly?= =?euc-kr?q?_review=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 20:45:42 -0000 TG91LCANCg0KSSBoYXZlIG5vIHByb2JsZW0gd2l0aCBjaGFuZ2luZyBhcyB5b3Ugc3VnZ2VzdGVk Lg0KQWdhaW4sIHRoYW5rcyBmb3IgeW91ciBoZWxwLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25n LWRvbmcNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq6uLO9 ILvntvc6IExvdSBCZXJnZXIgW2xiZXJnZXJAbGFibi5uZXRdDQq6uLO9ILOvwqU6IDIwMTSz4iA3 v/kgMTLAzyDF5L/kwM8gv8DA/CA0OjEyDQq53rTCILvntvc6ILf5waS1vzsgWWFhY292IFdlaW5n YXJ0ZW4NCsL8wbY6IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1l bnRzLmFsbEB0b29scy5pZXRmLm9yZzsgcnRnLWRpckBpZXRmLm9yZzsgcnRnLWFkc0B0b29scy5p ZXRmLm9yZw0Kwaa48TogUmU6IFtSVEctRElSXSDIuL3FOiDIuL3FOiAgW21wbHNdIFJ0Z0RpciBy ZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KDQpKZW9uZy1k b25nLA0KICAgICAgICBPbmUgdHdlYWsgYW5kIHdlJ3JlIHRoZXJlIQ0KR2l2ZW4gcHJlZW1wdGlv biBpcyBhbHJlYWR5IGRlZmluZWQsIGhvdyBhYm91dDoNCnMvYmxvY2tlZC9wcmVlbXB0ZWQuDQoN CkxvdQ0KDQoNCk9uIDA3LzEwLzIwMTQgMTA6MDEgQU0sILf5waS1vyB3cm90ZToNCj4gTG91LA0K Pg0KPiBUaGV5IGFyZSBtZWFudCB0byBiZSB1bmRlciB0aGUgaGFyZC1wcmVlbXB0aW9uLg0KPiBB bmQsIHlvdSBhcmUgcmlnaHQuIFRoZXkgYXJlIG5vIGdvb2QuDQo+IChJIGp1c3QgdHJpZWQgdG8g a2VlcCB3aGF0IGhhdmUgYmVlbiB0aGVyZSBiZWZvcmUuKQ0KPg0KPiBOZXcgc3VnZ2VzdGlvbnM6 DQo+ID09PT09PQ0KPiBvIElmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJp b3JpdHkgYXJlIHJlcXVlc3RpbmcNCj4gICAgdGhlIHNoYXJlZCByZXNvdXJjZXMsIHRoZSByZXNv dXJjZXMgU0hBTEwgYmUNCj4gICAgdXRpbGl6ZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0IHNlcnZl ZCBiYXNpcy4NCj4gICAgVHJhZmZpYyBvZiB0aGUgcHJvdGVjdGlvbiBwYXRocyB0aGF0IHJlcXVl c3QgdGhlIHNoYXJlZCByZXNvdXJjZSBsYXRlDQo+ICAgIFNIQUxMIGJlIGJsb2NrZWQuDQo+ICAg IEluIG9yZGVyIHRvIGNvdmVyIHRoZSBzaXR1YXRpb24gd2hlcmUgdGhlIGZpcnN0IGNvbWUgZmly c3Qgc2VydmVkIHByaW5jaXBsZQ0KPiAgICBjYW5ub3QgcmVzb2x2ZSB0aGUgY29udGVudGlvbiBh bW9uZyBtdWx0aXBsZSBlcXVhbCBwcmlvcml0eSByZXF1ZXN0cywNCj4gICAgaS5lLiwgd2hlbiB0 aGUgcmVxdWVzdHMgb2NjdXIgc2ltdWx0YW5lb3VzbHksIHRpZS1icmVha2luZyBydWxlcw0KPiAg ICBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNNUCBkb21haW4uDQo+DQo+IG8gSWYg YSBoaWdoZXIgcHJpb3JpdHkgcGF0aCByZXF1aXJlcyB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMg dGhhdCBhcmUNCj4gICAgYmVpbmcgdXRpbGl6ZWQgYnkgYSBsb3dlciBwcmlvcml0eSBwYXRoLCB0 aGUgcmVzb3VyY2VzIFNIQUxMIGJlDQo+ICAgIHV0aWxpemVkIGJ5IHRoZSBoaWdoZXIgcHJpb3Jp dHkgcGF0aC4NCj4gICAgVHJhZmZpYyB3aXRoIHRoZSBsb3dlciBwcmlvcml0eSBTSEFMTCBiZSBi bG9ja2VkLg0KPiA9PT09PT0NCj4NCj4gWWFhY292IGFuZCBjby1hdXRob3JzOg0KPiBTZWUgaWYg bmV3IHRleHRzIGFyZSBvay4NCj4NCj4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPiBKZW9uZy1k b25nDQo+DQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gurizvSC757b3OiBMb3UgQmVyZ2VyIFtsYmVyZ2VyQGxhYm4ubmV0XQ0KPiC6uLO9 ILOvwqU6IDIwMTSz4iA3v/kgMTDAzyC48b/kwM8gv8DIxCA5OjA0DQo+ILnetMIgu+e29zogt/nB pLW/OyBZYWFjb3YgV2VpbmdhcnRlbg0KPiDC/MG2OiBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRm LW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1hZHNAdG9vbHMu aWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmcNCj4gwaa48TogUmU6IMi4vcU6IFtSVEctRElSXSBb bXBsc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYu dHh0DQo+DQo+IEplb25nLWRvbmcsDQo+DQo+IERpZCB5b3UgcGVyaGFwcyBtZWFuIHRoYXQgdGhl c2UgbmV3IHBhcmFncmFwaHMgd291bGQgYmUgdW5kZXIgdGhlDQo+IHNvZnQtcHJlZW1wdGlvbiBz ZWN0aW9uPyBJZiBzbywgc291bmRzIGZpbmUuIElmIG5vdCwgYWxsb3dpbmcgdXNlIG9mDQo+IGF2 YWlsYWJsZSByZXNvdXJjZXMgYnkgdGhlICJoYXJkLXBlZW1wdGVkIiB0cmFmZmljIHJ1bnMgY291 bnRlciB0byBSRkM2MzcyOg0KPg0KPiAtIEluICJoYXJkIHByZWVtcHRpb24iLCB0aGUgZXh0cmEg dHJhZmZpYyBpcyBleGNsdWRlZCBmcm9tIHRoZQ0KPiBwcm90ZWN0aW9uIHJlc291cmNlLiBUaGUg ZGlzcnVwdGlvbiBvZiB0aGUgZXh0cmEgdHJhZmZpYyBpcyB0b3RhbCwNCj4gYW5kIHRoZSBzZXJ2 aWNlIHN1cHBvcnRlZCBieSB0aGUgZXh0cmEgdHJhZmZpYyBtdXN0IGJlIGRyb3BwZWQsIG9yDQo+ IHNvbWUgZm9ybSBvZiByZXJvdXRpbmcgb3IgcmVzdG9yYXRpb24gbXVzdCBiZSBhcHBsaWVkIHRv IHRoZSBleHRyYQ0KPiB0cmFmZmljIExTUCBpbiBvcmRlciB0byByZWNvdmVyIHRoZSBzZXJ2aWNl Lg0KPg0KPiAuLi4NCj4NCj4gLSBJbiAic29mdCBwcmVlbXB0aW9uIiwgdGhlIGV4dHJhIHRyYWZm aWMgaXMgbm90IGV4cGxpY2l0bHkgZXhjbHVkZWQNCj4gZnJvbSB0aGUgcHJvdGVjdGlvbiByZXNv dXJjZSwgYnV0IGlzIGdpdmVuIGxvd2VyIHByaW9yaXR5IHRoYW4gdGhlDQo+IHByb3RlY3RlZCB0 cmFmZmljLiBJbiBhIHBhY2tldCBuZXR3b3JrIChzdWNoIGFzIE1QTFMtVFApLCB0aGlzIGNhbg0K PiByZXN1bHQgaW4gb3ZlcnN1YnNjcmlwdGlvbiBvZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZSB3 aXRoIHRoZQ0KPiByZXN1bHQgdGhhdCB0aGUgZXh0cmEgdHJhZmZpYyByZWNlaXZlcyAiYmVzdC1l ZmZvcnQiIGRlbGl2ZXJ5Lg0KPg0KPiBMb3UNCj4NCj4gT24gNy8xMC8yMDE0IDM6NTIgQU0sILf5 waS1vyB3cm90ZToNCj4+IExvdSBhbmQgWWFhY292LA0KPj4NCj4+IEhlcmUgaXMgbXkgc3VnZ2Vz dGlvbiBvbiB0aG9zZSB0d28gYnVsbGV0IGl0ZW0gdGV4dHMgcmVsYXRlZCB0byAiYXNzaWduZWQi Lg0KPj4NCj4+IEFzIGluIG15IGVhcmxpZXIgZW1haWwgdG8gTG91J3MgZm9sbG93dXAgY29tbWVu dHMsDQo+PiB3ZSBjYW4gbWFrZSB0d28gc3ViIHNlY3Rpb25zIHVuZGVyIHRoaXMgU2VjdGlvbiA1 LjIuDQo+PiBhbmQgdGl0bGUgdGhlbSBhcyAiNS4yLjEgU29mdCBwcmVlbXB0aW9uIiBhbmQgIjUu Mi4yIEhhcmQgcHJlZW1wdGlvbiIuDQo+PiBUaG9zZSB0d28gYnVsbGV0IGl0ZW1zIHdpdGggImFz c2lnbmVkIiB3aWxsIGJlIHBsYWNlZCB1bmRlciA1LjIuMiBIYXJkIHByZWVtcHRpb24uDQo+Pg0K Pj4gSW4gYWRkaXRpb24gdG8gdGhpcywgd2UgY2FuIGNsYXJpZnkgZnVydGhlciwgc28gdGhhdCAi dXRpbGl6ZWQiIGlzIG5vdCBiZWluZyBtaXN1c2VkLg0KPj4gTmV3IHRleHRzIGZvciB0aG9zZSB0 d28gYnVsbGV0IGl0ZW1zIGFyZToNCj4+DQo+PiBvIElmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0 aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3RpbmcNCj4+ICAgIHRoZSBzaGFyZWQgcmVz b3VyY2VzLCB0aGUgcmVzb3VyY2VzIFNIQUxMIGJlDQo+PiAgICB1dGlsaXplZCBvbiBhIGZpcnN0 IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzLg0KPj4gICAgVHJhZmZpYyBvZiB0aGUgcHJvdGVjdGlv biBwYXRocyB0aGF0IHJlcXVlc3QgdGhlIHNoYXJlZCByZXNvdXJjZSBsYXRlDQo+PiAgICBTSEFM TCBiZSBibG9ja2VkIG9yIE1BWSB1c2UgYXZhaWxhYmxlIHJlc291cmNlIHdpdGhvdXQgaW50ZXJy dXB0aW5nDQo+PiAgICB0cmFmZmljIG9mIHByaW9yIHByb3RlY3Rpb24gcGF0aHMgdGhhdCBhcmUg dXRpbGl6aW5nIHRoZSBzaGFyZWQgcmVzb3VyY2UuDQo+PiAgICBJbiBvcmRlciB0byBjb3ZlciB0 aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBwcmluY2lwbGUN Cj4+ICAgIGNhbm5vdCByZXNvbHZlIHRoZSBjb250ZW50aW9uIGFtb25nIG11bHRpcGxlIGVxdWFs IHByaW9yaXR5IHJlcXVlc3RzLA0KPj4gICAgaS5lLiwgd2hlbiB0aGUgcmVxdWVzdHMgb2NjdXIg c2ltdWx0YW5lb3VzbHksIHRpZS1icmVha2luZyBydWxlcw0KPj4gICAgU0hBTEwgYmUgZGVmaW5l ZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9tYWluLg0KPj4NCj4+IG8gSWYgYSBoaWdoZXIgcHJpb3Jp dHkgcGF0aCByZXF1aXJlcyB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMgdGhhdCBhcmUNCj4+ICAg IGJlaW5nIHV0aWxpemVkIGJ5IGEgbG93ZXIgcHJpb3JpdHkgcGF0aCwgdGhlIHJlc291cmNlcyBT SEFMTCBiZQ0KPj4gICAgdXRpbGl6ZWQgYnkgdGhlIGhpZ2hlciBwcmlvcml0eSBwYXRoLg0KPj4g ICAgVHJhZmZpYyB3aXRoIHRoZSBsb3dlciBwcmlvcml0eSBTSEFMTCBiZSBibG9ja2VkIG9yIE1B WSB1c2UgYXZhaWxhYmxlIHJlc291cmNlcw0KPj4gICAgd2l0aG91dCBpbnRlcnJ1cHRpbmcgdHJh ZmZpYyBvZiB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGguDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0K Pj4NCj4+IEplb25nLWRvbmcNCj4+DQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiC6uLO9ILvntvc6IExvdSBCZXJnZXIgW2xiZXJnZXJA bGFibi5uZXRdDQo+PiC6uLO9ILOvwqU6IDIwMTSz4iA3v/kgOMDPIMitv+TAzyC/wMjEIDc6NTYN Cj4+ILnetMIgu+e29zogWWFhY292IFdlaW5nYXJ0ZW47ILf5waS1vw0KPj4gwvzBtjogbXBsc0Bp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYu b3JnOyBydGctYWRzQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGlldGYub3JnDQo+PiDBprjxOiBS ZTogW1JURy1ESVJdIFttcGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJl cXVpcmVtZW50cy0wNi50eHQNCj4+DQo+PiBZYWFjb3YsDQo+PiAgICAgU291bmRzIHJlYXNvbmFi bGUsIGJ1dCBJJ2xsIG5lZWQgdG8gc2VlIHRoZSBuZXcgd29yZGluZyB0byBiZSBzdXJlLg0KPj4N Cj4+IFRoYW5rcywNCj4+IExvdQ0KPj4gT24gNy81LzIwMTQgMzo0OSBQTSwgWWFhY292IFdlaW5n YXJ0ZW4gd3JvdGU6DQo+Pj4gTG91LCBoaQ0KPj4+IEkgd291bGQgbGlrZSB0byBhZGRyZXNzIHR3 byBvZiB5b3VyIGNvbW1lbnRzLCBpbiB5b3VyIGZvbGxvdy11cA0KPj4+IG1lc3NhZ2UsIHNpbmNl IEkgYW0gdGhlIHNvdXJjZSBvZiB0aGUgY2hhbmdlIGluIHRlcm1pbm9sb2d5Lg0KPj4+DQo+Pj4g UmVnYXJkaW5nIHRoZSB0d28gb2NjdXJlbmNlcyBvZiAiYXNzaWduZWQiIGluIHBsYWNlIG9mICJ1 dGlsaXplZCIgLQ0KPj4+IHdoZW4gSSByZWFkIHRoZSBwcm9wb3NlZCBjaGFuZ2VzLGFzIGRpc2N1 c3NlZCBhbW9uZ3N0IHRoZSBhdXRob3JzLCBJDQo+Pj4gZmVsdCB0aGF0IGluIHRob3NlIHR3byBp bnN0YW5jZXMgdGhlIHVzZSBvZiAidXRpbGl6ZWQiIGNvdWxkIGxlYWQgdG8NCj4+PiBzb21lIGFt YmlndWl0eS4NCj4+Pg0KPj4+IElmIHdlIHN0YXRlIHRoYXQgInJlc291cmNlcyBTSE9VTEQgYmUg dXRpbGl6ZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0DQo+Pj4gc2VydmVkIGJhc2lzIiB0aGlzIGNv dWxkIGJlIGludGVycHJldGVkIChJTU8pIGFzIHJlZmVycmluZyB0byB0aGUNCj4+PiBwYWNrZXQg bGV2ZWwsIHJhdGhlciB0aGFuICB1dGlsaXplZCBieSBhIHNwZWNpZmljIHBhdGgsIHN1Y2ggdGhh dA0KPj4+IHBhY2tldHMgZnJvbSBkaWZmZXJlbnQgcGF0aHMgY291bGQgYmUgaW50ZXJzcGVyc2Vk IGFsb25nIHRoZSBzaGFyZWQNCj4+PiBzZWdtZW50cy4gVGhlcmVmb3JlLEkgc3VnZ2VzdGVkIHRo YXQgb3IgdGhpcyBjb250ZXh0IGl0IHdvdWxkIGJlDQo+Pj4gYmV0dGVyIHRvIHVzZSBhIHdvcmQg dGhhdCBtZWFudCB0aGF0IHRoZSBmaXJzdC1jb21lIGZpcnN0IHNlcnZlZCBiYXNpcw0KPj4+IHdh cyBhdCB0aGUgbGV2ZWwgb2YgYXNzaWduaW5nIChvciBhbGxvY2F0aW5nKSB0aGUgcmVzb3VyY2Vz IHJhdGhlcg0KPj4+IHRoYW4gdXRpbGl6aW5nIHRoZW0uDQo+Pj4NCj4+PiBIb3BlIHRoaXMgY2xh cmlmaWVzIHRoaXMgcG9pbnQuIEkgYW0gY2VydGFpbiB0aGF0IEkgc3BlYWsgZm9yIHRoZQ0KPj4+ IG90aGVyIGF1dGhvcnMgaW4gIHNheWluZyB0aGF0IEkgYW0gb3BlbiB0byBvdGhlciBzdWdnZXN0 aW9ucy4NCj4+Pg0KPj4+IEJSLA0KPj4+IHlhYWNvdg0KPj4+DQo+Pj4gT24gSnVsIDQsIDIwMTQg Mzo1MyBBTSwgIkplb25nIFJ5b28iIDxyeW9vQGV0cmkucmUua3INCj4+PiA8bWFpbHRvOnJ5b29A ZXRyaS5yZS5rcj4+IHdyb3RlOg0KPj4+DQo+Pj4gICAgIERlYXIgTG91LA0KPj4+DQo+Pj4NCj4+ Pg0KPj4+ICAgICBUaGFua3MgYSBsb3QgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMuDQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4gICAgIFRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgaGF2ZSBkaXNjdXNz ZWQgeW91ciBjb21tZW50cywgYW5kIGFyZQ0KPj4+ICAgICBwcm9wb3Npbmcgb3VyIHJlc29sdXRp b25zIHRvIHlvdXIgY29tbWVudHMuIFBsZWFzZSwgbGV0IHVzIGtub3cgaWYNCj4+PiAgICAgdGhl IHByb3Bvc2FsIGlzIGFwcHJvcHJpYXRlIHRvIGFkZHJlc3MgeW91ciBjb21tZW50cyBhbmQgY29u Y2VybnMuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIEJlc3QgcmVnYXJkcywNCj4+Pg0KPj4+DQo+ Pj4NCj4+PiAgICAgQXV0aG9ycyBvZiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cyBk cmFmdA0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAgICAqKioqKiogQmVnaW5uaW5nIG9mIENvbW1lbnQg UmVzb2x1dGlvbiAqKioqKioNCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgLSBEb2N1bWVudCdzIHVz YWdlIG9mICJjb21taXR0ZWQiIHZzICJhbGxvY2F0ZWQiIHJlc291cmNlczoNCj4+Pg0KPj4+ICAg ICBJbiBzZWN0aW9uIDEgdGhlIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRo ZQ0KPj4+ICAgICBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9u IGlzIGJhc2VkIG9uIHdoZW4NCj4+PiAgICAgcmVzb3VyY2VzIGFyZSAiY29tbWl0dGVkIi4gVGhp cyBkaWZmZXJlbmNlIGZyb20gcGFzdA0KPj4+ICAgICBkZWZpbml0aW9uLiBSRkM0NDI3IGFuZCA2 MzcyIG1ha2UgdGhlIGRpc3RpbmN0aW9uIHRoYXQgcHJvdGVjdGlvbg0KPj4+ICAgICBhbmQgcmVz dG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3VyY2VzIGFyZSAqYWxsb2NhdGVkKiBu b3QNCj4+PiAgICAgKmNvbW1pdHRlZCouIFRvIHF1b3RlIFJGQyA0NDI3Og0KPj4+DQo+Pj4gICAg IFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIG1h ZGUgYmFzZWQNCj4+PiAgICAgb24gdGhlIHJlc291cmNlIGFsbG9jYXRpb24gZG9uZSBkdXJpbmcg dGhlIHJlY292ZXJ5IExTUC9zcGFuDQo+Pj4gICAgIGVzdGFibGlzaG1lbnQuIFRoZSBkaXN0aW5j dGlvbiBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZg0KPj4+ICAgICByZXN0b3JhdGlvbiBpcyBt YWRlIGJhc2VkIG9uIHRoZSBsZXZlbCBvZiByb3V0ZSBjb21wdXRhdGlvbiwNCj4+PiAgICAgc2ln bmFsaW5nLCBhbmQgcmVzb3VyY2UgYWxsb2NhdGlvbiBkdXJpbmcgdGhlIHJlc3RvcmF0aW9uDQo+ Pj4gICAgIExTUC9zcGFuIGVzdGFibGlzaG1lbnQuDQo+Pj4NCj4+PiAgICAgVGhpcyBkaWZmZXJl bmNlIGFsc28gbGVhZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZQ0KPj4+ICAg ICBkb2N1bWVudCBhcyB3ZWxsIGFzIGFtYmlndWl0eSBpbiB0aGUgdGV4dCwgaS5lLiBjb25mdXNp b24gYnkgdGhlDQo+Pj4gICAgIHJlYWRlci4gVGhlIHRlcm0gImNvbW1pdHRlZCIgaXMgbm90IHRp Z2h0bHkgZGVmaW5lZCBpbiB0aGlzDQo+Pj4gICAgIGRvY3VtZW50IChvciBlYXJsaWVyIHdvcmsp IGFuZCBpcyB1c2VkIGRpZmZlcmVudGx5IHRoYW4gaG93DQo+Pj4gICAgICJhbGxvY2F0ZWQiIGhh cyBiZWVuIHVzZWQuIEFuIGV4YW1wbGUgb2YgdGhpcyBjYW4gYmUgZm91bmQgaW4NCj4+PiAgICAg U2VjdGlvbiAzLjEgd2hpY2ggc3RhdGVzOg0KPj4+DQo+Pj4gICAgIEhvd2V2ZXIsIHRoZSBjb21t aXRtZW50IG9mIHRoZSByZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGUNCj4+PiAgICAgc2hhcmVk IHNlZ21lbnRzLCB3aWxsIG9ubHkgYmUgZmluYWxpemVkIHdoZW4gdGhlIHByb3RlY3Rpb24NCj4+ PiAgICAgcGF0aCBpcyBhY3R1YWxseSBhY3RpdmF0ZWQuIFRoZXJlZm9yZSwgZm9yIHRoZSBwdXJp c3RzIC0NCj4+PiAgICAgcmVnYXJkaW5nIHRoZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3 aGVyZSBiZXR3ZWVuDQo+Pj4gICAgIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uLg0KPj4+DQo+ Pj4gICAgIEJvdGggc2VudGVuY2VzIGFyZSBwcm9ibGVtYXRpYy4gSW4gdGhlIGZpcnN0LCBjb21t aXRtZW50IHNlZW1zIHRvDQo+Pj4gICAgIGNvdmVyIGEgInByb3RlY3Rpb24gc3dpdGNoIiB3b3Vs ZCAiY29ubmVjdCIgdGhlIHByb3RlY3Rpb24gcGF0aA0KPj4+ICAgICBidXQgbm90IHRoZSBlYXJs aWVyICJhbGxvY2F0aW9uIiBvZiByZXNvdXJjZXMuIChRdW90ZWQgdGVybXMgYXJlDQo+Pj4gICAg IHVzZWQgaW4gZWFybGllciBSRkNzLikgVGhlIHNlY29uZCBjb25jbHVzaW9uIGlzIGJhc2VkIG9u IHRoZSBuZXcNCj4+PiAgICAgZGlzdGluY3Rpb24gb2YgcHJvdGVjdGlvbiB2cy4gcmVzdG9yYXRp b24gYW5kIGlzIHVubmVjZXNzYXJ5IHdpdGgNCj4+PiAgICAgdGhlIGV4aXN0aW5nIGRpc3RpbmN0 aW9uLg0KPj4+DQo+Pj4gICAgIFRoaXMgaXNzdWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNlcyBp biB0aGUgZG9jdW1lbnQgd2hlcmUNCj4+PiAgICAgImNvbW1pdHRlZCIgaXMgdXNlZCBhbmQgSSdk IHJlY29tbWVuZCB0aGF0IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkDQo+Pj4gICAgIHdpdGggdGVy bWlub2xvZ3kgdXNlZCBpbiB0aGUgcmVmZXJlbmNlZCBSRkNzLCBpLmUuLCAiYWxsb2NhdGlvbiIs DQo+Pj4gICAgICJjb25uZWN0aW9uIiwgImNyb3NzLWNvbm5lY3QiLCAicHJvdGVjdGlvbiBzd2l0 Y2gob3ZlcikiLCAuLi4NCj4+Pg0KPj4+ICAgICBOb3RlIEknbSAqbm90KiBoaWdobGlnaHRpbmcg YWxsIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBwcm9ibGVtcyBpbiB0aGUNCj4+PiAgICAgZG9jdW1l bnQgcmVsYXRlZCB0byB0aGlzIGlzc3VlLiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcGxhY2VzIGlu IHRoZQ0KPj4+ICAgICBkb2N1bWVudCB3aGVyZSBJIHRoaW5rIGl0J3MgcG9zc2libGUgdGhhdCBv bmNlIHRoaXMgdGVybWlub2xvZ3kNCj4+PiAgICAgYW1iaWd1aXR5IGlzIGNvcnJlY3RlZCB0aGF0 IEknbGwgaGF2ZSBvdGhlciBzdWJzdGFudGl2ZSBjb21tZW50cy4NCj4+Pg0KPj4+DQo+Pj4NCj4+ PiAgICAgW0F1dGhvcnNdIEFmdGVyIHJldmlld2luZyBSRkNzIDQ0MjcsIDYzNzIsIDM5NDUsIDQ0 MjYsIGFuZCA0NDI4LA0KPj4+ICAgICB3ZSBjb25jbHVkZWQgdGhhdCB0aGUgZGlzdGluY3Rpb24g YmV0d2VlbiBwcm90ZWN0aW9uIGFuZA0KPj4+ICAgICByZXN0b3JhdGlvbiBzaG91bGQgYmUgYWxp Z25lZCB3aXRoIHRoZSBleGl0aW5nIGRvY3VtZW50cw0KPj4+ICAgICBub3JtYXRpdmVseSByZWZl cmVuY2VkIGJ5IHRoaXMgZG9jdW1lbnQuIEFjY29yZGluZ2x5LCB0aGUNCj4+PiAgICAgZm9sbG93 aW5nIDE2IG1vZGlmaWNhdGlvbnMgd2lsbCBiZSBkb25lIGluIHJldmlzaW9uOg0KPj4+DQo+Pj4N Cj4+Pg0KPj4+ICAgICAoMSkgU2VjdGlvbiAxLCB0aGUgdGhpcmQgcGFyYWdyYXBoDQo+Pj4NCj4+ PiAgICAgT0xEOg0KPj4+DQo+Pj4gICAgIEFzIHBvaW50ZWQgb3V0DQo+Pj4NCj4+PiAgICAgaW4g W1JGQzYzNzJdIGFuZCBbUkZDNDQyOF0sIGFwcGx5aW5nIDErMSBsaW5lYXIgcHJvdGVjdGlvbiBy ZXF1aXJlcw0KPj4+DQo+Pj4gICAgIHRoYXQgcmVzb3VyY2VzIGFyZSBjb21taXR0ZWQgZm9yIHVz ZSBieSBib3RoIHRoZSB3b3JraW5nIGFuZA0KPj4+DQo+Pj4gICAgIHByb3RlY3Rpb24gcGF0aHMu IEFwcGx5aW5nIDE6MSBwcm90ZWN0aW9uIHJlcXVpcmVzIHRoYXQgdGhlIHNhbWUNCj4+Pg0KPj4+ ICAgICByZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCwgYnV0IGFsbG93cyB0aGUgcmVzb3VyY2VzIG9m IHRoZSBwcm90ZWN0aW9uDQo+Pj4NCj4+PiAgICAgcGF0aCB0byBiZSB1dGlsaXplZCBmb3IgcHJl LWVtcHRpYmxlIGV4dHJhIHRyYWZmaWMuDQo+Pj4NCj4+PiAgICAgTkVXOg0KPj4+DQo+Pj4gICAg IEFzIHBvaW50ZWQgb3V0DQo+Pj4NCj4+PiAgICAgaW4gW1JGQzYzNzJdIGFuZCBbUkZDNDQyOF0s IGFwcGx5aW5nIDErMSBwcm90ZWN0aW9uIHJlcXVpcmVzDQo+Pj4NCj4+PiAgICAgdGhhdCByZXNv dXJjZXMgYXJlIGFsbG9jYXRlZCBmb3IgdXNlIGJ5IGJvdGggdGhlIHdvcmtpbmcgYW5kDQo+Pj4N Cj4+PiAgICAgcHJvdGVjdGlvbiBwYXRocy4gQXBwbHlpbmcgMToxIHByb3RlY3Rpb24gcmVxdWly ZXMgdGhhdCB0aGUgc2FtZQ0KPj4+DQo+Pj4gICAgIHJlc291cmNlcyBhcmUgYWxsb2NhdGVkLCBi dXQgYWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhlIHByb3RlY3Rpb24NCj4+Pg0KPj4+ICAgICBw YXRoIHRvIGJlIHV0aWxpemVkIGZvciBwcmUtZW1wdGlibGUgZXh0cmEgdHJhZmZpYy4NCj4+Pg0K Pj4+DQo+Pj4NCj4+PiAgICAgKDIpIFRoZSB3aG9sZSB0ZXh0IGluIFNlY3Rpb24gMy4xIHdpbGwg YmUgcmVwbGFjZWQgd2l0aDoNCj4+Pg0KPj4+ICAgICBbUkZDNjM3Ml0sIGJhc2VkIHVwb24gdGhl IGRlZmluaXRpb25zIGluIFtSRkM0NDI3XSwgZGlmZmVyZW50aWF0ZXMNCj4+PiAgICAgYmV0d2Vl biAicHJvdGVjdGlvbiIgYW5kICJyZXN0b3JhdGlvbiIgZGVwZW5kZW50IHVwb24gdGhlIGR5bmFt aXNtDQo+Pj4gICAgIG9mIHRoZSByZXNvdXJjZSBhbGxvY2F0aW9uLiBUaGUgc2FtZSBkaXN0aW5j dGlvbiBpcyB1c2VkIGluDQo+Pj4gICAgIFtSRkMzOTQ1XSwgW1JGQzQ0MjZdLCBhbmQgW1JGQzQ0 MjhdLiBUaGlzIGRvY3VtZW50IGFsc28gdXNlcyB0aGUNCj4+PiAgICAgc2FtZSBkaXN0aW5jdGlv biBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGFzIHN0YXRlZCBpbg0KPj4+ICAg ICBbUkZDNjM3Ml0uDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgICgzKSBJbiBwYWdlIDYsDQo+Pj4N Cj4+PiAgICAgT0xEOg0KPj4+DQo+Pj4gICAgIFRoZSB1c2Ugb2YgcHJlZW1wdGlvbiBpbiB0aGUg bmV0d29yayBpcyB0eXBpY2FsbHkgYSBidXNpbmVzcyBvcg0KPj4+DQo+Pj4gICAgIHBvbGljeSBk ZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgY29udGVuZGVk LA0KPj4+DQo+Pj4gICAgIHByaW9yaXR5IGNhbiBiZSBhcHBsaWVkIHRvIGRldGVybWluZSB0byB3 aGljaCBwYXJ0aWVzIHRoZSBwcm90ZWN0aW9uDQo+Pj4NCj4+PiAgICAgcmVzb3VyY2VzIGFyZSBj b21taXR0ZWQuDQo+Pj4NCj4+PiAgICAgTkVXOg0KPj4+DQo+Pj4gICAgIFRoZSB1c2Ugb2YgcHJl ZW1wdGlvbiBpbiB0aGUgbmV0d29yayBpcyB0eXBpY2FsbHkgYSBidXNpbmVzcyBvcg0KPj4+DQo+ Pj4gICAgIHBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90ZWN0aW9uIHJlc291cmNl cyBhcmUgY29udGVuZGVkLA0KPj4+DQo+Pj4gICAgIHByaW9yaXR5IGNhbiBiZSBhcHBsaWVkIHRv IGRldGVybWluZSB3aGljaCBwYXJ0aWVzIHV0aWxpemUgdGhlDQo+Pj4gICAgIHByb3RlY3Rpb24N Cj4+Pg0KPj4+ICAgICByZXNvdXJjZXMuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgICg0KSBQYWdl IDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQo+Pj4NCj4+PiAgICAgT0xEOg0KPj4+DQo+Pj4gICAg IHRoZSByZXNvdXJjZXMgZm9yIHRoZSBwcm90ZWN0aW9uIHBhdGggYXJlIGZ1bGx5IGNvbW1pdHRl ZCwNCj4+Pg0KPj4+ICAgICBORVcNCj4+Pg0KPj4+ICAgICB0aGUgcmVzb3VyY2VzIGZvciB0aGUg cHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBkZWRpY2F0ZWQsDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g ICAgIE9MRDoNCj4+Pg0KPj4+ICAgICByZXNvdXJjZXMgbWF5IGJlIHBsYW5uZWQgYnV0IHdvdWxk IG5vdCBiZSBjb21taXR0ZWQgdW50aWwgoaYNCj4+Pg0KPj4+ICAgICBORVc6DQo+Pj4NCj4+PiAg ICAgcmVzb3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBub3QgYmUgdXRpbGl6ZWQgdW50 aWwgoaYNCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgKDUpIEluIHRoZSBzZWNvbmQgcGFyYWdyYXBo IGluIHBhZ2UgNywNCj4+Pg0KPj4+ICAgICBPTEQ6DQo+Pj4NCj4+PiAgICAgIkhhcmQgUHJlZW1w dGlvbiIgcmVxdWlyZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUNCj4+PiAg ICAgaW5ncmVzcyBvZiBlYWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkgd2hpY2ggYmFja3Vw IHBhdGggaGFzDQo+Pj4gICAgIHRoZSBoaWdoZXN0IHByaW9yaXR5IHdoZW4gY29tbWl0dGluZyBw cm90ZWN0aW9uIHJlc291cmNlcywgdGhlDQo+Pj4gICAgIG90aGVycyBiZWluZyBwcmVlbXB0ZWQu DQo+Pj4NCj4+PiAgICAgTkVXDQo+Pj4NCj4+PiAgICAgIkhhcmQgUHJlZW1wdGlvbiIgcmVxdWly ZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUNCj4+PiAgICAgaW5ncmVzcyBv ZiBlYWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkgdGhlIHByaW9yaXRpZXMgb2YgYmFja3Vw DQo+Pj4gICAgIHBhdGhzLCBzbyB0aGF0IHRyYWZmaWMgb2YgbG93ZXIgcHJpb3JpdHkgcGF0aHMg Y2FuIGJlIHByZWVtcHRlZC4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgKDYpIFRoZSBmaXJzdCBw YXJhZ3JhcGggb2YgU2VjdGlvbiA0LjE6DQo+Pj4NCj4+PiAgICAgT0xEOg0KPj4+DQo+Pj4gICAg IKGmIGFuZCBjb21taXQgdGhlIGFzc29jaWF0ZWQgcmVzb3VyY2VzLiBUaGUgY29tbWl0bWVudCBv ZiByZXNvdXJjZXMNCj4+Pg0KPj4+ICAgICBpcyBkZXBlbmRlbnQgdXBvbiChpg0KPj4+DQo+Pj4g ICAgIE5FVzoNCj4+Pg0KPj4+ICAgICChpiBhbmQgY29vcmRpbmF0ZSB0aGUgdXRpbGl6YXRpb24g b2YgdGhlIGFzc29jaWF0ZWQgc2hhcmVkIHJlc291cmNlcy4NCj4+Pg0KPj4+ICAgICBUaGUgcmVz b3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIGlzIGRlcGVuZGVudCB1cG9uIKGmDQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4gICAgICg3KSBUaGUgc2Vjb25kIHBhcmFncmFwaCBvZiBTZWN0aW9uIDQu MToNCj4+Pg0KPj4+ICAgICBPTEQ6DQo+Pj4NCj4+PiAgICAgV2hlbiB0aGUgcmVzZXJ2ZWQgcmVz b3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJlIGNvbW1pdHRlZCB0byBhDQo+Pj4NCj4+ PiAgICAgcGFydGljdWxhciBwcm90ZWN0aW9uIHBhdGgsIHRoZXJlIG1heSBub3QgYmUgc3VmZmlj aWVudCByZXNvdXJjZXMNCj4+Pg0KPj4+ICAgICBhdmFpbGFibGUgZm9yIGFuIGFkZGl0aW9uYWwg cHJvdGVjdGlvbiBwYXRoLiBUaGlzIHRoZW4gaW1wbGllcyB0aGF0DQo+Pj4NCj4+PiAgICAgaWYg YW5vdGhlciB3b3JraW5nIHBhdGggb2YgdGhlIFNNUCBkb21haW4gdHJpZ2dlcnMgYSBwcm90ZWN0 aW9uDQo+Pj4NCj4+PiAgICAgc3dpdGNoLCB0aGUgY29tbWl0bWVudCBvZiB0aGUgcmVzb3VyY2Vz IG1heSBmYWlsLiBJbiBvcmRlciB0bw0KPj4+DQo+Pj4gICAgIG9wdGltaXplIHRoZSBvcGVyYXRp b24gb2YgdGhlIGNvbW1pdG1lbnQgYW5kIHByZXBhcmluZyBmb3IgY2FzZXMgb2YNCj4+Pg0KPj4+ ICAgICBtdWx0aXBsZSB3b3JraW5nIHBhdGhzIGZhaWxpbmcsIHRoZSBjb21taXRtZW50IG9mIHRo ZSBzaGFyZWQNCj4+Pg0KPj4+ICAgICByZXNvdXJjZXMgYXJlIGJlIGNvb3JkaW5hdGVkIGJldHdl ZW4gdGhlIGRpZmZlcmVudCB3b3JraW5nIHBhdGhzIGluDQo+Pj4NCj4+PiAgICAgdGhlIFNNUCBu ZXR3b3JrLg0KPj4+DQo+Pj4gICAgIE5FVzoNCj4+Pg0KPj4+ICAgICBXaGVuIHRoZSByZXNlcnZl ZCByZXNvdXJjZXMgb2YgdGhlIHNoYXJlZCBzZWdtZW50cyBhcmUgdXRpbGl6ZWQgYnkgYQ0KPj4+ DQo+Pj4gICAgIHBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVyZSBtYXkgbm90IGJlIHN1 ZmZpY2llbnQgcmVzb3VyY2VzDQo+Pj4NCj4+PiAgICAgYXZhaWxhYmxlIGZvciBhbiBhZGRpdGlv bmFsIHByb3RlY3Rpb24gcGF0aC4gVGhpcyB0aGVuIGltcGxpZXMgdGhhdA0KPj4+DQo+Pj4gICAg IGlmIGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJv dGVjdGlvbg0KPj4+DQo+Pj4gICAgIHN3aXRjaCwgdGhlIHJlc291cmNlIHV0aWxpemF0aW9uIGNv b3JkaW5hdGlvbiBtYXkgZmFpbC4gVGhlDQo+Pj4gICAgIGRpZmZlcmVudCB3b3JraW5nIHBhdGhz IGluDQo+Pj4NCj4+PiAgICAgdGhlIFNNUCBuZXR3b3JrIGFyZSBpbnZvbHZlZCBpbiB0aGUgcmVz b3VyY2UgdXRpbGl6YXRpb24NCj4+PiAgICAgY29vcmRpbmF0aW9uLg0KPj4+DQo+Pj4gICAgIC4N Cj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgKDgpIFNlY3Rpb24gNS4xLA0KPj4+DQo+Pj4gICAgIE9M RDoNCj4+Pg0KPj4+ICAgICChpiBhbmQgY29tbWl0IHRoZSBhc3NvY2lhdGVkIHJlc291cmNlcy4N Cj4+Pg0KPj4+ICAgICBORVcNCj4+Pg0KPj4+ICAgICChpiBhbmQgY29vcmRpbmF0ZSB0aGUgdXRp bGl6YXRpb24gb2YgdGhlIGFzc29jaWF0ZWQgc2hhcmVkIHJlc291cmNlcy4NCj4+Pg0KPj4+DQo+ Pj4NCj4+PiAgICAgKDkpIEluIFNlY3Rpb24gNS4xLA0KPj4+DQo+Pj4gICAgIE9MRDoNCj4+Pg0K Pj4+ICAgICBJbiB0aGUgY2FzZSBvZiBtdWx0aXBsZSB3b3JraW5nIHBhdGhzIGZhaWxpbmcsIHRo ZSBjb21taXRtZW50IG9mIHRoZQ0KPj4+DQo+Pj4gICAgIHNoYXJlZCByZXNvdXJjZXMgU0hBTEwg YmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0aGUgZGlmZmVyZW50IHdvcmtpbmcNCj4+Pg0KPj4+ICAg ICBwYXRocyBpbiB0aGUgU01QIG5ldHdvcmsuDQo+Pj4NCj4+PiAgICAgTkVXOg0KPj4+DQo+Pj4g ICAgIEluIHRoZSBjYXNlIG9mIG11bHRpcGxlIHdvcmtpbmcgcGF0aHMgZmFpbGluZywgdGhlIHNo YXJlZCByZXNvdXJjZQ0KPj4+ICAgICB1dGlsaXphdGlvbg0KPj4+DQo+Pj4gICAgIGNvb3JkaW5h dGlvbiBTSEFMTCBiZSBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZw0KPj4+DQo+Pj4gICAg IHBhdGhzIGluIHRoZSBTTVAgbmV0d29yay4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgKDEwKSBT ZWN0aW9uIDUuMS4xLg0KPj4+DQo+Pj4gICAgIE9MRDoNCj4+Pg0KPj4+ICAgICChpiBiZWNhdXNl IHRoZXkgYWxyZWFkeSBoYXZlIGJlZW4gY29tbWl0dGVkIHRvIHRoZSBwcm90ZWN0aW9uIG9mLA0K Pj4+ICAgICBmb3IgZXhhbXBsZSwgYSBoaWdoZXIgcHJpb3JpdHkgd29ya2luZyBwYXRoLg0KPj4+ DQo+Pj4gICAgIE5FVzoNCj4+Pg0KPj4+ICAgICChpiBiZWNhdXNlIHRoZXkgYWxyZWFkeSBoYXZl IGJlZW4gdXRpbGl6ZWQgZm9yIHRoZSBwcm90ZWN0aW9uIG9mLA0KPj4+ICAgICBmb3IgZXhhbXBs ZSwgYSBoaWdoZXIgcHJpb3JpdHkgd29ya2luZyBwYXRoLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAg ICAoMTEpIFNlY3Rpb24gNS4yLCB0aGUgc2Vjb25kIGJ1bGxldCBpdGVtOg0KPj4+DQo+Pj4gICAg IE9MRDoNCj4+Pg0KPj4+ICAgICBSZXNvdXJjZXMgb2YgdGhlIHNoYXJlZCBzZWdtZW50cyBTSEFM TCBiZSBjb21taXR0ZWQgdG8gdGhlDQo+Pj4NCj4+PiAgICAgcHJvdGVjdGlvbiBwYXRoIKGmDQo+ Pj4NCj4+PiAgICAgTkVXOg0KPj4+DQo+Pj4gICAgIFJlc291cmNlcyBvZiB0aGUgc2hhcmVkIHNl Z21lbnRzIFNIQUxMIGJlIHV0aWxpemVkIGJ5IHRoZQ0KPj4+DQo+Pj4gICAgIHByb3RlY3Rpb24g cGF0aCChpg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAgICAoMTIpIFNlY3Rpb24gNS4yLCB0aGUgdGhp cmQgYnVsbGV0IGl0ZW06DQo+Pj4NCj4+PiAgICAgT0xEOg0KPj4+DQo+Pj4gICAgIElmIG11bHRp cGxlIHByb3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3RpbmcNCj4+ Pg0KPj4+ICAgICBhbGxvY2F0aW9uIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3Vy Y2VzIFNIT1VMRCBiZQ0KPj4+DQo+Pj4gICAgIGNvbW1pdHRlZCBvbiBhIGZpcnN0IGNvbWUgZmly c3Qgc2VydmVkIGJhc2lzLg0KPj4+DQo+Pj4gICAgIE5FVzoNCj4+Pg0KPj4+ICAgICBJZiBtdWx0 aXBsZSBwcm90ZWN0aW9uIHBhdGhzIG9mIGVxdWFsIHByaW9yaXR5IGFyZSByZXF1ZXN0aW5nDQo+ Pj4NCj4+PiAgICAgdGhlIHNoYXJlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxEIGJl DQo+Pj4NCj4+PiAgICAgYXNzaWduZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBiYXNp cy4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgKDEzKSBTZWN0aW9uIDUuMiwgdGhlIGZvdXJ0aCBi dWxsZXQgaXRlbToNCj4+Pg0KPj4+ICAgICBPTEQ6DQo+Pj4NCj4+PiAgICAgSWYgdGhlIHByb3Rl Y3Rpb24gcmVzb3VyY2VzIGFyZSBjb21taXR0ZWQgdG8gYSBwcm90ZWN0aW9uIHBhdGgsDQo+Pj4N Cj4+PiAgICAgd2hvc2Ugd29ya2luZyBwYXRoIGhhcyBhIGxvd2VyIHByaW9yaXR5LCByZXNvdXJj ZXMgcmVxdWlyZWQgZm9yDQo+Pj4NCj4+PiAgICAgdGhlIGhpZ2hlciBwcmlvcml0eSBwYXRoIFNI QUxMIGJlIGNvbW1pdHRlZCB0byB0aGUgaGlnaGVyIHByaW9yaXR5DQo+Pj4NCj4+PiAgICAgcGF0 aC4NCj4+Pg0KPj4+ICAgICBORVc6DQo+Pj4NCj4+PiAgICAgSWYgdGhlIHByb3RlY3Rpb24gcmVz b3VyY2VzIGFyZSB1dGlsaXplZCBieSBhIHByb3RlY3Rpb24gcGF0aCwNCj4+Pg0KPj4+ICAgICB3 aG9zZSB3b3JraW5nIHBhdGggaGFzIGEgbG93ZXIgcHJpb3JpdHksIHJlc291cmNlcyByZXF1aXJl ZCBmb3INCj4+Pg0KPj4+ICAgICB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGggU0hBTEwgYmUgYXNz aWduZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eQ0KPj4+DQo+Pj4gICAgIHBhdGguDQo+Pj4NCj4+ Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAgICAoMTQpIFNlY3Rpb24gNS4yLiB0aGUgc2V2ZW50aCBi dWxsZXQgaXRlbQ0KPj4+DQo+Pj4gICAgIE9MRDoNCj4+Pg0KPj4+ICAgICBPbmNlIHJlc291cmNl cyBvZiBzaGFyZWQgc2VnbWVudHMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBjb21taXR0ZWQNCj4+ Pg0KPj4+ICAgICB0byBhIHByb3RlY3Rpb24gcGF0aCwgoaYNCj4+Pg0KPj4+ICAgICBORVc6DQo+ Pj4NCj4+PiAgICAgT25jZSByZXNvdXJjZXMgb2Ygc2hhcmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBz dWNjZXNzZnVsbHkgdXRpbGl6ZWQNCj4+Pg0KPj4+ICAgICBieSBhIHByb3RlY3Rpb24gcGF0aCwg oaYNCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgKDE1KSBTZWN0aW9uIDUuMywgdGhlIGZpcnN0IHBh cmFncmFwaCwNCj4+Pg0KPj4+ICAgICBPTEQ6DQo+Pj4NCj4+PiAgICAgoaYgcmVxdWVzdCB0aGUg Y29tbWl0bWVudCBvZiBwcm90ZWN0aW9uIHJlc291cmNlcy4gSWYgdGhlIG5lY2Vzc2FyeQ0KPj4+ DQo+Pj4gICAgIHNoYXJlZCByZXNvdXJjZXMgYXJlIHVuYXZhaWxhYmxlIHRvIGJlIGNvbW1pdHRl ZCB0byB0aGUgcHJvdGVjdGlvbg0KPj4+DQo+Pj4gICAgIHBhdGgsIHRoZSBlbmRwb2ludHMgoaYN Cj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgTkVXOg0KPj4+DQo+Pj4gICAgIKGmIHJlcXVlc3QgdGhl IGNvb3JkaW5hdGlvbiBvZiB0aGUgc2hhcmVkIHJlc291cmNlIHV0aWxpemF0aW9uLiBJZg0KPj4+ ICAgICB0aGUgbmVjZXNzYXJ5DQo+Pj4NCj4+PiAgICAgc2hhcmVkIHJlc291cmNlcyBhcmUgdW5h dmFpbGFibGUsIHRoZSBlbmRwb2ludHMgoaYNCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgKDE2KSBT ZWN0aW9uIDUuMywgdGhlIHNlY29uZCBwYXJhZ3JhcGgsDQo+Pj4NCj4+PiAgICAgT0xEOg0KPj4+ DQo+Pj4gICAgIFNpbWlsYXJseSwgaWYgcHJlZW1wdGlvbiBpcyBzdXBwb3J0ZWQgYW5kIHRoZSBy ZXNvdXJjZXMgY3VycmVudGx5DQo+Pj4NCj4+PiAgICAgY29tbWl0dGVkIGZvciBhIHBhcnRpY3Vs YXIgd29ya2luZyBwYXRoIGFyZSChpg0KPj4+DQo+Pj4gICAgIE5FVzoNCj4+Pg0KPj4+ICAgICBT aW1pbGFybHksIGlmIHByZWVtcHRpb24gaXMgc3VwcG9ydGVkIGFuZCB0aGUgcmVzb3VyY2VzIGN1 cnJlbnRseQ0KPj4+DQo+Pj4gICAgIHV0aWxpemVkIGJ5IGEgcGFydGljdWxhciB3b3JraW5nIHBh dGggYXJlIKGmDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAgICAtIFNlY3Rpb24gMiwg MXN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkNCj4+PiAg ICAgZGVmaW5lcw0KPj4+ICAgICB0aGUgc2NvcGUvcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQsIGku ZS4sICJjbGFyaWZpZXMgdGhlIGluc3RydWN0aW9ucw0KPj4+ICAgICB0byBwcm90b2NvbCBkZXNp Z25lcnMgcHJvZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhlDQo+Pj4gICAgIHJlcXVp cmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNoLCBJJ2QgcmVwZWF0IHRo aXMgaW4NCj4+PiAgICAgdGhlIGFic3RyYWN0IGFuZCBtb3ZlIGl0IHRvIGEgbW9yZSBwcm9ub3Vu Y2VkIHBsYWNlIGluIHNlY3Rpb24gMSAob3INCj4+PiAgICAgMykuDQo+Pj4NCj4+PiAgICAgW0F1 dGhvcnNdIFdlIGNhbiBhZGQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBT ZWN0aW9uIDE6DQo+Pj4NCj4+PiAgICAgobBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGNs YXJpZnkgdGhlIGluc3RydWN0aW9ucyB0byBwcm90b2NvbA0KPj4+ICAgICBkZXNpZ25lcnMgcHJv ZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cyBzZXQNCj4+PiAg ICAgb3V0IGluIHRoaXMgZG9jdW1lbnQuobENCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAgICAt IEdlbmVyYWwgY29tbWVudDogZmF0ZS1zaGFyaW5nIGZvciBjby1yb3V0ZWQgYmlkaXJlY3Rpb25h bCBMU1ANCj4+PiAgICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJvdXRpbmcgcHJlc2VydmVkIGZv ciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD8NCj4+PiAgICAgSSdkIGFzc3VtZWQgdGhlIHByb3Rl Y3Rpb24gc3dpdGNoIGNvb3JkaW5hdGlvbiBwcm90b2NvbCB3b3VsZCBiZQ0KPj4+ICAgICByZXF1 aXJlZCB0byB0cmlnZ2VyIGEgc3dpdGNob3ZlciBvZiB0aGUgcmV2ZXJzZSBMU1AgaW4gdGhlIGNv LXJvdXRlZA0KPj4+ICAgICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhlIGRvY3VtZW50 Lg0KPj4+DQo+Pj4gICAgIFtBdXRob3JzXSBGYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVkIGJ5 IHRoaXMgZG9jdW1lbnQuIEV2ZW4gaW4NCj4+PiAgICAgdGhlIFBTQyBsaW5lYXIgcHJvdGVjdGlv biBzd2l0Y2hpbmcsIHN1Y2ggYXMgUkZDIDYzNzggKFBTQykgYW5kDQo+Pj4gICAgIFJGQyA3Mjcx IChQU0MgaW4gQVBTIG1vZGUpLCBmYXRlLXNoYXJpbmcgaXMgbm90IHJlcXVpcmVkIGFzDQo+Pj4g ICAgIHVuaWRpcmVjdGlvbmFsIHN3aXRjaGluZyBpcyBhbGxvd2VkLiBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IGltcG9zZQ0KPj4+ICAgICBhbnkgcmVzdHJpY3Rpb24gb24gY28tcm91dGluZywgZWl0 aGVyLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIC0gSW4gc2VjdGlvbiA0IGFuZCA1LjIg eW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRlZmluaW5nDQo+Pj4gICAgIHByZWVtcHRp b24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+ Pj4gICAgIHJlZmVyZW5jZSBoZXJlIGFzIGl0IGRlZmluZXMgYm90aCBpbiB0aGUgY29udGV4dCBv ZiBzdXJ2aXZhYmlsaXR5IGFuZA0KPj4+ICAgICBpbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFu ZS4NCj4+Pg0KPj4+ICAgICBbQXV0aG9yc10gT25lIGNvbmNlcm4gaXMgdGhhdCBSRkMgNjM3MiBk ZXNjcmliZXMgYm90aCBzb2Z0IGFuZA0KPj4+ICAgICBoYXJkIHByZWVtcHRpb25zIGluIHRoZSBj b250ZXh0IG9mIGV4dHJhIHRyYWZmaWMsIHdoaWNoIGlzIG5vdA0KPj4+ICAgICBleGFjdGx5IHRo ZSBjYXNlIGZvciBTTVAuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgLSBJbiBzZWN0aW9u IDQuMiB5b3Ugc2F5ICJUaGVyZWZvcmUsIGl0IGlzIHN1Z2dlc3RlZCB0aGF0IHRoaXMgYmUNCj4+ PiAgICAgY2FycmllZCBvdXQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBkeW5hbWljIGNvbnRyb2wg cGxhbmUgc2ltaWxhciB0bw0KPj4+ICAgICBHTVBMUyBbUkZDMzk0NV0uIiBwZXJoYXBzIHlvdSBt ZWFuICJiYXNlZCBvbiBHTVBMUyI/IElmIHNvLCBncmVhdCwNCj4+PiAgICAgcGxlYXNlIG1ha2Ug dGhlIGNvcnJlY3Rpb24uIElmIG5vdCwgSSB0aGluayB0aGUgZGViYXRlIG9mIHdoaWNoDQo+Pj4g ICAgIGNvbnRyb2wgcHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBpcyB3YXkgYmV5b25kIHRo ZSBzY29wZSBvZiB0aGlzDQo+Pj4gICAgIGRvY3VtZW50Lg0KPj4+DQo+Pj4gICAgIFtBdXRob3Jz XSBZZXMsIHdlIHdpbGwgbWFrZSB0aGUgY29ycmVjdGlvbi4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0K Pj4+ICAgICAtIFNlY3Rpb24gNS4xLCBwYXJhZ3JhcGggMS4gV2h5IGFyZSB5b3UgdXNpbmcgIlNI T1VMRCBOT1QiIGhlcmU/IElmDQo+Pj4gICAgIHJlZmVycmluZyB0byBzb2x1dGlvbnMgY29uZm9y bWFudCB3aXRoIHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlc2UgYXJlDQo+Pj4gICAgIGluZm9ybWF0 aXZlIHN0YXRlbWVudHMsICJhbmQgYSBub24tY29udHJvbCBwbGFuZSBiYXNlZCBTTVAgc3dpdGNo b3Zlcg0KPj4+ICAgICBtZWNoYW5pc20gaXMgdXNlZCwgdGhlIGNvbnRyb2wgcGxhbmUgU0hBTEwg Tk9UIC4uLiIuIElmIHJlZmVycmluZyB0bw0KPj4+ICAgICBhbiBvcGVyYXRvcidzL3VzZXIncyBj aG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNoYW5pc20sIEkgdGhpbmsgdGhlIG1vc3QNCj4+PiAgICAg eW91IGNhbiBzYXkgaXMgTUFZLg0KPj4+DQo+Pj4gICAgIFtBdXRob3JzXSBUaGUgZmlyc3QgY2Fz ZSBpcyB0aGUgb25lIHdlIGFyZSBhaW1pbmcgYXQuIFdlIHdpbGwgdXNlDQo+Pj4gICAgIFNIQUxM IE5PVC4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAgICAtIFNlY3Rpb24gNS4yLiAiVGllLWJy ZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4gU01QDQo+Pj4gICAg IGRvbWFpbi4iIEFzIHRoaXMgaXMgYSByZXF1aXJlbWVudCwgd2hhdCB5b3UgbWVhbiBieSAidGll LWJyZWFraW5nDQo+Pj4gICAgIHJ1bGVzIiBzaG91bGQgYmUgZGVmaW5lZCBkaXJlY3RseSBvciBi eSByZWZlcmVuY2UuDQo+Pj4NCj4+PiAgICAgW0F1dGhvcnNdIFRoZSBzZW50ZW5jZSBjYW4gYmUg cmV3cml0dGVuIGFzOg0KPj4+DQo+Pj4gICAgIE9MRDoNCj4+Pg0KPj4+ICAgICBUaWUtYnJlYWtp bmcgcnVsZXMgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9tYWluLg0KPj4+ DQo+Pj4gICAgIE5FVzoNCj4+Pg0KPj4+ICAgICBJbiBvcmRlciB0byBjb3ZlciB0aGUgc2l0dWF0 aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZA0KPj4+ICAgICBwcmluY2lwbGUg Y2Fubm90IHJlc29sdmUgdGhlIGNvbnRlbnRpb24gYW1vbmcgbXVsdGlwbGUgZXF1YWwNCj4+PiAg ICAgcHJpb3JpdHkgcmVxdWVzdHMsIGkuZS4sIHdoZW4gdGhlIHJlcXVlc3RzIG9jY3VyIHNpbXVs dGFuZW91c2x5LCwNCj4+PiAgICAgdGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQg aW4gc2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4N Cj4+PiAgICAgLSBTZWN0aW9uIDUuMy4gUkZDNjM3MiB0YWtlcyBhbiBhcHByb2FjaCB3aGVyZSBw cmVlbXB0aW9uIG5vdGlmaWNhdGlvbg0KPj4+ICAgICBsZXZlcmFnZXMgdGhlIHN0YW5kYXJkIE1Q TFMtVFAgT0FNIG1lY2hhbmlzbXMsIGlzIHRoZXJlIGFueSByZWFzb24gdG8NCj4+PiAgICAgZG8g bW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2MzcyPw0KPj4+DQo+Pj4gICAgIFtBdXRob3JzXSBXZSBj YW4gYWRkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgYXQgdGhlIGVuZDoNCj4+Pg0KPj4+ICAgICCh sEFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3Ml0sIHRoZSBldmVudCBvZiBwcmVlbXB0aW9uIG1heSBi ZQ0KPj4+ICAgICBkZXRlY3RlZCBieSBPQU0gYW5kIHJlcG9ydGVkIGFzIGEgZmF1bHQgb3IgYSBk ZWdyYWRhdGlvbiBvZg0KPj4+ICAgICB0cmFmZmljIGRlbGl2ZXJ5LqGxDQo+Pj4NCj4+Pg0KPj4+ ICAgICAtIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRpbmF0aW9uIHJlcXVpcmVkIG9u DQo+Pj4gICAgIHNvZnQtcHJlZW1wdGlvbiBhcw0KPj4+ICAgICB3ZWxsIChkZXBlbmRpbmcgb24g dGhlIGNyb3NzLWNvbm5lY3RzIGVzdGFibGlzaGVkIGR1cmluZyBMU1ANCj4+PiAgICAgZXN0YWJs aXNobWVudCkgc28gY29vcmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBiZSBzdXBwb3J0ZWQNCj4+ PiAgICAgaW5kZXBlbmRlbnQgb2YgcHJlZW1wdGlvbiBtb2RlLg0KPj4+DQo+Pj4gICAgIFtBdXRo b3JzXSBZZXMsIHdlIHdpbGwgY2hhbmdlIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGZyb20gobBTTVAg aW4NCj4+PiAgICAgaGFyZC1wcmVlbXB0aW9uIG1vZGUgU0hPVUxEIKGmobEgdG8gobBTTVAgU0hP VUxEIKGmobEgYW5kIG1vdmUgdGhlDQo+Pj4gICAgIGNoYW5nZWQgcGFyYWdyYXBoIGFib3ZlIHRo ZSBmaXJzdCBwYXJhZ3JhcGguDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgTml0czoNCj4+ Pg0KPj4+ICAgICAtIEFic3RyYWN0OiBJIGRvbid0IHJlY2FsbCB0aGUgdGVybSAiZXhlY3V0aXZl IGFjdGlvbiIgYmVpbmcgdXNlZA0KPj4+ICAgICBpbiBhbnkNCj4+PiAgICAgZWFybGllciByZWxh dGVkL3JlZmVyZW5jZWQgUkZDcy4gUmF0aGVyIHRoYW4gaW50cm9kdWNlIGEgbmV3IChhbmQNCj4+ PiAgICAgdW5kZWZpbmVkKSB0ZXJtLCBwZXJoYXBzIHlvdSBjYW4gdXNlIGFuIGV4aXN0aW5nIG9u ZSwgZS5nLiwNCj4+PiAgICAgInByb3RlY3Rpb24gc3dpdGNoIj8NCj4+Pg0KPj4+ICAgICBbQXV0 aG9yc10gWWVzLCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQgYXMgeW91IHN1Z2dlc3RlZC4NCj4+ Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAgICAtIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDEuIERvIHdl IHJlYWxseSBuZWVkIGFub3RoZXIgZGVmaW5pdGlvbiBvZg0KPj4+ICAgICBNUExTLVRQIHRvIGRl YmF0ZT8gSSBzdWdnZXN0IGp1c3QgcmVmZXJlbmNpbmcgeW91ciBmYXZvcml0ZSBNUExTLVRQDQo+ Pj4gICAgIGRvY3VtZW50KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMu DQo+Pj4NCj4+PiAgICAgVGhlIGxhc3Qgc2VudGVuY2UgYWxzbyBtYWtlcyBhIHN1YmplY3RpdmUg c3RhdGVtZW50LiBXaGV0aGVyIGl0IGlzDQo+Pj4gICAgIGNyaXRpY2FsIG9yIG5vIGlzIHVubmVj ZXNzYXJ5LiBZb3UgY2FuIGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtlIDYzNzINCj4+PiAgICAgcHJv dmlkZXMgYSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1UUCBhbmQgaXMgdGhlIGZv dW5kYXRpb24NCj4+PiAgICAgZm9yIHRoaXMgZG9jdW1lbnQuDQo+Pj4NCj4+PiAgICAgW0F1dGhv cnNdIFRoZSBwcm9wb3NlZCB0ZXh0IGZvciB0aGUgcGFyYWdyYXBoIDEgaXM6DQo+Pj4NCj4+PiAg ICAgobBUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgaXMgZGVzY3JpYmVkIGlu IFtSRkM1OTIxXSwNCj4+Pg0KPj4+ICAgICBhbmQgW1JGQzYzNzJdIHByb3ZpZGVzIGEgc3Vydml2 YWJpbGl0eSBmcmFtZXdvcmsgZm9yIE1QTFMtVFANCj4+Pg0KPj4+ICAgICBhbmQgaXMgdGhlIGZv dW5kYXRpb24gZm9yIHRoaXMgZG9jdW1lbnQuobENCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ICAg ICAtIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDMuIElzbid0IHRoZSByaWdodCByZWZlcmVuY2UgNDQy NyBub3QgNDQyOD8NCj4+PiAgICAgQWxzbyBkcm9wIHRoZSB3b3JkIGxpbmVhciwgYXMgaXQgaXMg YW4gdW5uZWNlc3NhcnkgcXVhbGlmaWVyIGFuZA0KPj4+ICAgICA0NDI3LzQ0MjggZG9uJ3QgdXNl IGl0Lg0KPj4+DQo+Pj4gICAgIFtBdXRob3JzXSBPSy4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+ DQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9ucyAzIChhbmQgdG8gYSBsZXNzZXIgZGVncmVlIHNlY3Rp b24gMikgYXJlIHJlYWxseQ0KPj4+ICAgICBpbnRyb2R1Y3RvcnkNCj4+PiAgICAgdGV4dC4gSSdt IHVuc3VyZSBhcyB0byB3aHkgdGhleSBhcmVuJ3QgcGFydCBvZiBzZWN0aW9uIDEuDQo+Pj4NCj4+ PiAgICAgW0F1dGhvcnNdIFNlY3Rpb24gMyB3YXMgaW50ZW5kZWQgdG8gcHJlc2VudCBhIHJlZmVy ZW5jZSBtb2RlbCBmb3INCj4+PiAgICAgU01QLiBTb21lIHRleHQgb2YgU2VjdGlvbiAyIGlzIHJl cGVhdGVkIGluIFNlY3Rpb24gMSBhcyB5b3UNCj4+PiAgICAgc3VnZ2VzdGVkIGVhcmxpZXIuDQo+ Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIC0gU2VjdGlvbiAzLjIgc2hvdWxk IGhhdmUgYSByZWZlcmVuY2UgZm9yICJleGlzdGluZyBjb250cm9sIHBsYW5lDQo+Pj4gICAgIHNv bHV0aW9ucyBmb3IgU01QIHdpdGhpbiBNUExTIi4NCj4+Pg0KPj4+ICAgICBbQXV0aG9yc10gW1JG QzQyMDZdIHdpbGwgYmUgYWRkZWQgYXMgYSByZWZlcmVuY2UNCj4+Pg0KPj4+DQo+Pj4gICAgIC0g U2VjdGlvbiAzLjIgYWdhaW4gdXNlcyB0aGUgImV4ZWN1dGl2ZSBhY3Rpb24iIHRlcm0uDQo+Pj4N Cj4+PiAgICAgW0F1dGhvcnNdIE9LLCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQuDQo+Pj4NCj4+ Pg0KPj4+DQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9uIDQuMS4gWW91IHNheSAidHdvIG9wZXJhdGlv bnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3UgcmVhbGx5DQo+Pj4gICAgIG1lYW4gInNpbXVsdGFu ZW91c2x5IiBvciBtZXJlbHkgdGhhdCB0aGV5IG11c3QgYm90aCBvY2N1ciBmb3INCj4+PiAgICAg cHJvdGVjdGlvbiB0byBiZSBwcm92aWRlZD8gKFNhbWUgY29tbWVudCBpbiBzZWN0aW9uIDUuMS4N Cj4+Pg0KPj4+ICAgICBbQXV0aG9yc10gQm90aCBhY3Rpb25zIHNob3VsZCBvY2N1ciBhdCB0aGUg c2FtZSB0aW1lLCBvciBhcw0KPj4+ICAgICBjbG9zZWx5IGFzIHBvc3NpYmxlIHRvIHByb3ZpZGUg ZmFzdCBwcm90ZWN0aW9uLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIC0gU2VjdGlvbiA1 LjIuIEkgc3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0ZWQNCj4+PiAgICAg cmVxdWlyZW1lbnRzDQo+Pj4gICAgIGxpc3QuDQo+Pj4NCj4+PiAgICAgW0F1dGhvcnNdIE9LLCB3 ZSB3aWxsIHVzZSBudW1iZXJzLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIC0gU2VjdGlv biA1LjI6IEZpcnN0IHBhcmFncmFwaCBhbmQgZm9ydGggYnVsbGV0IGxhc3Qgc2VudGVuY2UuIFRo ZXNlDQo+Pj4gICAgIGJvdGggYmFzaWNhbGx5IGNvdmVyIHRoZSBzYW1lIHRvcGljIChwcmVlbXB0 aW9uKSBhbmQgYWN0dWFsbHkgc2F5DQo+Pj4gICAgIHNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3Mu IEkgc3VnZ2VzdCBjb21iaW5lIGludG8gYSBzaW5nbGUNCj4+PiAgICAgcmVxdWlyZW1lbnQgdG8g ZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBmdWxsIGNvdmVyYWdlIG9mIHRoZSB0b3BpYy4NCj4+Pg0K Pj4+ICAgICBbQXV0aG9yc10gVGhlIGZpcnN0IHBhcmFncmFwaCBpcyBmb3Igc29mdC1wcmVlbXB0 aW9uLCB3aGlsZSB0aGUNCj4+PiAgICAgZm91cnRoIGJ1bGxldCBiZWxvbmdzIHRvIHRoZSByZXF1 aXJlbWVudHMgb2YgaGFyZC1wcmVlbXB0aW9uLg0KPj4+DQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9u IDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRoaXMgcmVsYXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRu J3QNCj4+PiAgICAgdGhlIHRvcGljcyByZWxhdGVkIHRvIHRpbWluZyBiZSBjb25zb2xpZGF0ZWQ/ DQo+Pj4NCj4+PiAgICAgW0F1dGhvcnNdIFllcywgcmVxIDUgY2FuIGJlIG1vdmVkIHRvIFNlY3Rp b24gNS41Lg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIC0gU2VjdGlvbiA1LjI6IHJlcXVp cmVtZW50IDYgc2VlbXMgdG8gYmUgYSBzdWJzZXQgb2YgNywgc28gaXQNCj4+PiAgICAgc2hvdWxk IGJlDQo+Pj4gICAgIGRyb3BwZWQuDQo+Pj4NCj4+PiAgICAgW0F1dGhvcnNdIFllcywgaXQgd2ls bCBiZSBkZWxldGVkLg0KPj4+DQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1l bnQgOC4gSXNuJ3QgdGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCj4+PiAgICAganVz dCB0aGlzIG9uZSB0cmFmZmljIHRyZWF0bWVudCAoc3ViKSByZXF1aXJlbWVudD8NCj4+Pg0KPj4+ ICAgICBbQXV0aG9yc10gUmVxLiA5IHdpbGwgYmUgZGVsZXRlZCBhcyBpdCBzZWVtcyB0byByZXF1 aXJlIGNvbnRyb2wNCj4+PiAgICAgcGxhbmUgc3VwcG9ydHMuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g ICAgIC0gU2VjdGlvbiA1LjMuIHMvTUFZL3dpbGwNCj4+Pg0KPj4+ICAgICBbQXV0aG9yc10gT0su DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICAgLSBzZWN0aW9uIDUuNDogIiBXaGVuIHRoZSB3 b3JraW5nIHBhdGggZGV0ZWN0cy4uIiBkZXRlY3Rpb24gaXMgYnkgdGhlDQo+Pj4gICAgIG5vZGUg bm90IHRoZSBwYXRoLg0KPj4+DQo+Pj4gICAgIFtBdXRob3JzXSBZZXMuIFdlIHdpbGwgc2ltcGx5 IHNheSB0aGF0IKGwV2hlbiB0aGUgY29uZGl0aW9uIHRoYXQNCj4+PiAgICAgdHJpZ2dlcmVkIHRo ZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBpcyBjbGVhcmVkLCChpqGxDQo+Pj4NCj4+Pg0KPj4+ICAg ICAtIFNlY3Rpb24gNS40LCBsYXN0IHNlbnRlbmNlLiBUaGlzIGlzIG9ubHkgdGhlIDJuZCB0aW1l IHlvdSBpbXBseSB0aGF0DQo+Pj4gICAgIHRoZSBkb2N1bWVudCBjb3ZlcnMgcmVxdWlyZW1lbnRz IG9uIGEgbmV3IHByb3RvY29sLiBJIHRoaW5rIHRoaXMNCj4+PiAgICAgcG9pbnQgaXMgY3VycmVu dGx5IHRvbyBzdWJ0bGUgaW4gdGhlIGRvY3VtZW50LiAoVGhpcyBwb2ludCB3YXMgYWxzbw0KPj4+ ICAgICBtYWRlIGFzIGEgbWlub3IgY29tbWVudC4pDQo+Pj4NCj4+PiAgICAgW0F1dGhvcnNdIEFz IGluIG90aGVyIHByb3RlY3Rpb24gc3dpdGNoaW5nIHRlY2hub2xvZ2llcywgdHdvIG1vZGVzDQo+ Pj4gICAgIG9mIG9wZXJhdGlvbnMgKHJldmVydGl2ZSBhbmQgbm9uLXJldmVydGl2ZSkgYXJlIHJl cXVpcmVkLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIC0gc2VjdGlvbiA1LjYuIFJGQyA2 MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkDQo+Pj4NCj4+PiAgICAgW0F1dGhvcnNdIFdlIHdpbGwg YWRkIKGwYXMgZGVzY3JpYmVkIGluIFtSRkM2MzcyXaGxIHRvIHRoZSBlbmRzIG9mDQo+Pj4gICAg IHR3byBwYXJhZ3JhcGhzIGZvciBXVFIgdGltZXIgYW5kIGhvbGQtb2ZmIHRpbWVyLg0KPj4+DQo+ Pj4NCj4+Pg0KPj4+ICAgICAqKioqKiBFbmQgb2YgQ29tbWVudCByZXNvbHV0aW9uICoqKioqDQo+ Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ ICAgICAqurizvSC757b3IDogKiJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldA0KPj4+ICAg ICA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPj4+ICAgICAqurizvSCzr8KlIDogKjIwMTQt MDYtMjIgMDE6MDA6NDggKCArMDk6MDAgKQ0KPj4+ICAgICAqud60wiC757b3IDogKnJ0Zy1hZHNA dG9vbHMuaWV0Zi5vcmcNCj4+PiAgICAgPG1haWx0bzpydGctYWRzQHRvb2xzLmlldGYub3JnPiA8 cnRnLWFkc0B0b29scy5pZXRmLm9yZw0KPj4+ICAgICA8bWFpbHRvOnJ0Zy1hZHNAdG9vbHMuaWV0 Zi5vcmc+Pg0KPj4+ICAgICAqwvzBtiA6ICpydGctZGlyQGlldGYub3JnIDxtYWlsdG86cnRnLWRp ckBpZXRmLm9yZz4NCj4+PiAgICAgPHJ0Zy1kaXJAaWV0Zi5vcmcgPG1haWx0bzpydGctZGlyQGll dGYub3JnPj4sDQo+Pj4gICAgIGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0 b29scy5pZXRmLm9yZw0KPj4+ICAgICA8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWly ZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZz4NCj4+PiAgICAgPGRyYWZ0LWlldGYtbXBscy1zbXAt cmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZw0KPj4+ICAgICA8bWFpbHRvOmRyYWZ0LWll dGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZz4+LA0KPj4+ICAgICBt cGxzQGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4gPG1wbHNAaWV0Zi5vcmcNCj4+PiAg ICAgPG1haWx0bzptcGxzQGlldGYub3JnPj4NCj4+PiAgICAgKsGmuPEgOiAqW21wbHNdIFJ0Z0Rp ciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KPj4+DQo+ Pj4NCj4+PiAgICAgSGVsbG8sDQo+Pj4NCj4+PiAgICAgSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMg dGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMNCj4+PiAgICAgZHJhZnQu IFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvcg0K Pj4+ICAgICByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYg bGFzdCBjYWxsIGFuZCBJRVNHDQo+Pj4gICAgIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVj aWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMNCj4+PiAgICAgdG8gcHJv dmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24N Cj4+PiAgICAgYWJvdXQgdGhlDQo+Pj4gICAgIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBz ZWUNCj4+PiAgICAgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0Rpcg0KPj4+DQo+Pj4gICAgIEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJp bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcNCj4+PiAgICAgQURzLCBpdA0KPj4+ICAgICB3 b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55 IG90aGVyIElFVEYNCj4+PiAgICAgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUs IGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtDQo+Pj4gICAgIHRocm91Z2gNCj4+PiAgICAgZGlz Y3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+Pj4NCj4+PiAgICAgRG9jdW1lbnQ6 IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KPj4+ICAgICBSZXZpZXdl cjogTG91IEJlcmdlcg0KPj4+ICAgICBSZXZpZXcgRGF0ZTogSnVuZSAyMSAyMDE0DQo+Pj4gICAg IElFVEYgTEMgRW5kIERhdGU6IDIwMTQtMDYtMjMNCj4+PiAgICAgSW50ZW5kZWQgU3RhdHVzOiBJ bmZvcm1hdGlvbmFsDQo+Pj4NCj4+PiAgICAgU3VtbWFyeToNCj4+PiAgICAgSSBoYXZlIHNvbWUg bWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsNCj4+PiAgICAg c2hvdWxkIChtdXN0LCBhY3R1YWxseSkgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0K Pj4+DQo+Pj4gICAgIENvbW1lbnRzOg0KPj4+DQo+Pj4gICAgIEkgdGhpbmsgdGhlIGRvY3VtZW50 IGlzIHdlbGwgd3JpdHRlbiBhbmQsIG90aGVyIHRoYW4gYSBjb3VwbGUgb2YNCj4+PiAgICAgdGVy bWlub2xvZ3kgcmVsYXRlZCBpc3N1ZXMsIGVhc2lseSB1bmRlcnN0b29kLiBUaGUgZG9jdW1lbnQg ZG9lcw0KPj4+ICAgICBoYXZlIGEgbnVtYmVyIG9mIHRlcm1pbm9sb2d5IGFuZCB0ZWNobmljYWwg aXNzdWVzIHdoaWNoIHNob3VsZCBiZQ0KPj4+ICAgICByZWFkaWx5IHJlc29sdmVkIHByaW9yIHRv IHB1YmxpY2F0aW9uLg0KPj4+DQo+Pj4gICAgIE1ham9yIElzc3VlczoNCj4+Pg0KPj4+ICAgICBN YWpvciBpc3N1ZXMgYXJlIHRoZSB0eXBlIG9mIGNvbmNlcm5zIHRoYXQgd2lsbCByZXN1bHQgaW4g dGhlDQo+Pj4gICAgIGRvY3VtZW50IGJlaW5nIGJsb2NrZWQgdW50aWwgdGhleSBhcmUgcmVzb2x2 ZWQuIFRoZSBSb3V0aW5nIEFEcyB3aWxsDQo+Pj4gICAgIGJlY29tZSBpbnZvbHZlZC4gUGxlYXNl IGluY2x1ZGUgYWxsIG9mIHRoZSBtYWpvciBpc3N1ZXMgeW91IGhhdmUNCj4+PiAgICAgZm91bmQu IEdpdmUgYXMgbXVjaCBjb250ZXh0IGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIChlLmcuLCBzZWN0 aW9uDQo+Pj4gICAgIG51bWJlcnMsIHBhcmFncmFwaCBjb3VudHMpLiBJZiB5b3UgZmluZCBubyBt YWpvciBpc3N1ZXMsIHBsZWFzZQ0KPj4+ICAgICB3cml0ZTogIk5vIG1ham9yIGlzc3VlcyBmb3Vu ZC4iDQo+Pj4NCj4+PiAgICAgLSBObyBtYWpvciBpc3N1ZXMgZm91bmQuIEluIHBhcnRpY3VsYXIs IEkgZXhwZWN0IGFsbCBpc3N1ZXMgY2FuIGJlDQo+Pj4gICAgIHJlc29sdmVkIHdpdGhvdXQgQUQg aW50ZXJ2ZW50aW9uLiBTb21lIG9mIHRoZSBtaW5vciBpc3N1ZXMsIGlmIG5vdA0KPj4+ICAgICBy ZXNvbHZlZCB3aWxsIGJlIGVzY2FsYXRlZCB0byB0aGUgQUQvbWFqb3IgaXNzdWUgY2F0ZWdvcnku DQo+Pj4NCj4+PiAgICAgTWlub3IgSXNzdWVzOg0KPj4+DQo+Pj4gICAgIE1pbm9yIGlzc3VlcyBh cmUgY29uY2VybnMgYWJvdXQgY2xhcml0eSBvciB0ZWNobmljYWwgYWNjdXJhY3kgdGhhdA0KPj4+ ICAgICBzaG91bGQgYmUgZGlzY3Vzc2VkIGFuZCByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24s IGJ1dCB3aGljaCB3b3VsZA0KPj4+ICAgICBub3JtYWxseSBiZSByZXNvbHZlZCBiZXR3ZWVuIHRo ZSBhdXRob3JzIGFuZCB0aGUgcmV2aWV3ZXJzLiBQbGVhc2UNCj4+PiAgICAgaW5jbHVkZSBhbGwg b2YgdGhlIG1pbm9yIGlzc3VlcyB5b3UgaGF2ZSBmb3VuZC4gR2l2ZSBhcyBtdWNoIGNvbnRleHQN Cj4+PiAgICAgaW5mb3JtYXRpb24gYXMgcG9zc2libGUgKGUuZy4sIHNlY3Rpb24gbnVtYmVycywg cGFyYWdyYXBoIGNvdW50cykuDQo+Pj4gICAgIElmIHlvdSBmaW5kIG5vIG1pbm9yIGlzc3Vlcywg cGxlYXNlIHdyaXRlOiAiTm8gbWlub3IgaXNzdWVzIGZvdW5kLiINCj4+Pg0KPj4+ICAgICAtIERv Y3VtZW50J3MgdXNhZ2Ugb2YgImNvbW1pdHRlZCIgdnMgImFsbG9jYXRlZCIgcmVzb3VyY2VzOg0K Pj4+DQo+Pj4gICAgIEluIHNlY3Rpb24gMSB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgbm90 aW9uIHRoYXQgdGhlDQo+Pj4gICAgIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQg cmVzdG9yYXRpb24gaXMgYmFzZWQgb24gd2hlbg0KPj4+ICAgICByZXNvdXJjZXMgYXJlICJjb21t aXR0ZWQiLiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBwYXN0DQo+Pj4gICAgIGRlZmluaXRpb24uIFJG QzQ0MjcgYW5kIDYzNzIgbWFrZSB0aGUgZGlzdGluY3Rpb24gdGhhdCBwcm90ZWN0aW9uDQo+Pj4g ICAgIGFuZCByZXN0b3JhdGlvbiBkaWZmZXIgYmFzZWQgb24gd2hlbiByZXNvdXJjZXMgYXJlICph bGxvY2F0ZWQqIG5vdA0KPj4+ICAgICAqY29tbWl0dGVkKi4gVG8gcXVvdGUgUkZDIDQ0Mjc6DQo+ Pj4NCj4+PiAgICAgVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9y YXRpb24gaXMgbWFkZSBiYXNlZA0KPj4+ICAgICBvbiB0aGUgcmVzb3VyY2UgYWxsb2NhdGlvbiBk b25lIGR1cmluZyB0aGUgcmVjb3ZlcnkgTFNQL3NwYW4NCj4+PiAgICAgZXN0YWJsaXNobWVudC4g VGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gZGlmZmVyZW50IHR5cGVzIG9mDQo+Pj4gICAgIHJlc3Rv cmF0aW9uIGlzIG1hZGUgYmFzZWQgb24gdGhlIGxldmVsIG9mIHJvdXRlIGNvbXB1dGF0aW9uLA0K Pj4+ICAgICBzaWduYWxpbmcsIGFuZCByZXNvdXJjZSBhbGxvY2F0aW9uIGR1cmluZyB0aGUgcmVz dG9yYXRpb24NCj4+PiAgICAgTFNQL3NwYW4gZXN0YWJsaXNobWVudC4NCj4+Pg0KPj4+ICAgICBU aGlzIGRpZmZlcmVuY2UgYWxzbyBsZWFkcyB0byBjb21lIGNvbmZ1c2VkIHN0YXRlbWVudHMgaW4g dGhlDQo+Pj4gICAgIGRvY3VtZW50IGFzIHdlbGwgYXMgYW1iaWd1aXR5IGluIHRoZSB0ZXh0LCBp LmUuIGNvbmZ1c2lvbiBieSB0aGUNCj4+PiAgICAgcmVhZGVyLiBUaGUgdGVybSAiY29tbWl0dGVk IiBpcyBub3QgdGlnaHRseSBkZWZpbmVkIGluIHRoaXMNCj4+PiAgICAgZG9jdW1lbnQgKG9yIGVh cmxpZXIgd29yaykgYW5kIGlzIHVzZWQgZGlmZmVyZW50bHkgdGhhbiBob3cNCj4+PiAgICAgImFs bG9jYXRlZCIgaGFzIGJlZW4gdXNlZC4gQW4gZXhhbXBsZSBvZiB0aGlzIGNhbiBiZSBmb3VuZCBp bg0KPj4+ICAgICBTZWN0aW9uIDMuMSB3aGljaCBzdGF0ZXM6DQo+Pj4NCj4+PiAgICAgSG93ZXZl ciwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcywgYXQgbGVhc3QgZm9yIHRoZQ0KPj4+ ICAgICBzaGFyZWQgc2VnbWVudHMsIHdpbGwgb25seSBiZSBmaW5hbGl6ZWQgd2hlbiB0aGUgcHJv dGVjdGlvbg0KPj4+ICAgICBwYXRoIGlzIGFjdHVhbGx5IGFjdGl2YXRlZC4gVGhlcmVmb3JlLCBm b3IgdGhlIHB1cmlzdHMgLQ0KPj4+ICAgICByZWdhcmRpbmcgdGhlIHRlcm1pbm9sb2d5IC0gU01Q IGxpZXMgc29tZXdoZXJlIGJldHdlZW4NCj4+PiAgICAgcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRp b24uDQo+Pj4NCj4+PiAgICAgQm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1hdGljLiBJbiB0aGUg Zmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG8NCj4+PiAgICAgY292ZXIgYSAicHJvdGVjdGlvbiBz d2l0Y2giIHdvdWxkICJjb25uZWN0IiB0aGUgcHJvdGVjdGlvbiBwYXRoDQo+Pj4gICAgIGJ1dCBu b3QgdGhlIGVhcmxpZXIgImFsbG9jYXRpb24iIG9mIHJlc291cmNlcy4gKFF1b3RlZCB0ZXJtcyBh cmUNCj4+PiAgICAgdXNlZCBpbiBlYXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNsdXNpb24g aXMgYmFzZWQgb24gdGhlIG5ldw0KPj4+ICAgICBkaXN0aW5jdGlvbiBvZiBwcm90ZWN0aW9uIHZz LiByZXN0b3JhdGlvbiBhbmQgaXMgdW5uZWNlc3Nhcnkgd2l0aA0KPj4+ICAgICB0aGUgZXhpc3Rp bmcgZGlzdGluY3Rpb24uDQo+Pj4NCj4+PiAgICAgVGhpcyBpc3N1ZSBleGlzdHMgaW4gbXVsdGlw bGUgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB3aGVyZQ0KPj4+ICAgICAiY29tbWl0dGVkIiBpcyB1 c2VkIGFuZCBJJ2QgcmVjb21tZW5kIHRoYXQgZWFjaCBzaG91bGQgYmUgcmVwbGFjZWQNCj4+PiAg ICAgd2l0aCB0ZXJtaW5vbG9neSB1c2VkIGluIHRoZSByZWZlcmVuY2VkIFJGQ3MsIGkuZS4sICJh bGxvY2F0aW9uIiwNCj4+PiAgICAgImNvbm5lY3Rpb24iLCAiY3Jvc3MtY29ubmVjdCIsICJwcm90 ZWN0aW9uIHN3aXRjaChvdmVyKSIsIC4uLg0KPj4+DQo+Pj4gICAgIE5vdGUgSSdtICpub3QqIGhp Z2hsaWdodGluZyBhbGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2JsZW1zIGluIHRoZQ0KPj4+ ICAgICBkb2N1bWVudCByZWxhdGVkIHRvIHRoaXMgaXNzdWUuIFRoZXJlIGFyZSBhIGNvdXBsZSBv ZiBwbGFjZXMgaW4gdGhlDQo+Pj4gICAgIGRvY3VtZW50IHdoZXJlIEkgdGhpbmsgaXQncyBwb3Nz aWJsZSB0aGF0IG9uY2UgdGhpcyB0ZXJtaW5vbG9neQ0KPj4+ICAgICBhbWJpZ3VpdHkgaXMgY29y cmVjdGVkIHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1YnN0YW50aXZlIGNvbW1lbnRzLg0KPj4+DQo+ Pj4gICAgIC0gU2VjdGlvbiAyLCAxc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLiBUaGlzIHNl bnRlbmNlIHJlYWxseQ0KPj4+ICAgICBkZWZpbmVzDQo+Pj4gICAgIHRoZSBzY29wZS9wdXJwb3Nl IG9mIHRoZSBkb2N1bWVudCwgaS5lLiwgImNsYXJpZmllcyB0aGUgaW5zdHJ1Y3Rpb25zDQo+Pj4g ICAgIHRvIHByb3RvY29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNm eSB0aGUNCj4+PiAgICAgcmVxdWlyZW1lbnRzIHNldCBvdXQgaW4gdGhpcyBkb2N1bWVudC4iIEFz IHN1Y2gsIEknZCByZXBlYXQgdGhpcyBpbg0KPj4+ICAgICB0aGUgYWJzdHJhY3QgYW5kIG1vdmUg aXQgdG8gYSBtb3JlIHByb25vdW5jZWQgcGxhY2UgaW4gc2VjdGlvbiAxIChvcg0KPj4+ICAgICAz KS4NCj4+Pg0KPj4+ICAgICAtIEdlbmVyYWwgY29tbWVudDogZmF0ZS1zaGFyaW5nIGZvciBjby1y b3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCj4+PiAgICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJv dXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD8NCj4+PiAgICAgSSdk IGFzc3VtZWQgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGNvb3JkaW5hdGlvbiBwcm90b2NvbCB3b3Vs ZCBiZQ0KPj4+ICAgICByZXF1aXJlZCB0byB0cmlnZ2VyIGEgc3dpdGNob3ZlciBvZiB0aGUgcmV2 ZXJzZSBMU1AgaW4gdGhlIGNvLXJvdXRlZA0KPj4+ICAgICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRo aXMgaW4gdGhlIGRvY3VtZW50Lg0KPj4+DQo+Pj4gICAgIC0gSW4gc2VjdGlvbiA0IGFuZCA1LjIg eW91IHJlZmVyZW5jZSA1NzEyIGFuZCAzMjA5IGFzIGRlZmluaW5nDQo+Pj4gICAgIHByZWVtcHRp b24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+ Pj4gICAgIHJlZmVyZW5jZSBoZXJlIGFzIGl0IGRlZmluZXMgYm90aCBpbiB0aGUgY29udGV4dCBv ZiBzdXJ2aXZhYmlsaXR5IGFuZA0KPj4+ICAgICBpbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFu ZS4NCj4+Pg0KPj4+ICAgICAtIEluIHNlY3Rpb24gNC4yIHlvdSBzYXkgIlRoZXJlZm9yZSwgaXQg aXMgc3VnZ2VzdGVkIHRoYXQgdGhpcyBiZQ0KPj4+ICAgICBjYXJyaWVkIG91dCB1bmRlciB0aGUg Y29udHJvbCBvZiBhIGR5bmFtaWMgY29udHJvbCBwbGFuZSBzaW1pbGFyIHRvDQo+Pj4gICAgIEdN UExTIFtSRkMzOTQ1XS4iIHBlcmhhcHMgeW91IG1lYW4gImJhc2VkIG9uIEdNUExTIj8gSWYgc28s IGdyZWF0LA0KPj4+ICAgICBwbGVhc2UgbWFrZSB0aGUgY29ycmVjdGlvbi4gSWYgbm90LCBJIHRo aW5rIHRoZSBkZWJhdGUgb2Ygd2hpY2gNCj4+PiAgICAgY29udHJvbCBwcm90b2NvbCBpcyB1c2Vk IGZvciBNUExTLVRQIGlzIHdheSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMNCj4+PiAgICAgZG9j dW1lbnQuDQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9uIDUuMSwgcGFyYWdyYXBoIDEuIFdoeSBhcmUg eW91IHVzaW5nICJTSE9VTEQgTk9UIiBoZXJlPyBJZg0KPj4+ICAgICByZWZlcnJpbmcgdG8gc29s dXRpb25zIGNvbmZvcm1hbnQgd2l0aCB0aGlzIGRvY3VtZW50LCB0aGVuIHRoZXNlIGFyZQ0KPj4+ ICAgICBpbmZvcm1hdGl2ZSBzdGF0ZW1lbnRzLCAiYW5kIGEgbm9uLWNvbnRyb2wgcGxhbmUgYmFz ZWQgU01QIHN3aXRjaG92ZXINCj4+PiAgICAgbWVjaGFuaXNtIGlzIHVzZWQsIHRoZSBjb250cm9s IHBsYW5lIFNIQUxMIE5PVCAuLi4iLiBJZiByZWZlcnJpbmcgdG8NCj4+PiAgICAgYW4gb3BlcmF0 b3Incy91c2VyJ3MgY2hvaWNlIG9mIHByb3RlY3Rpb24gbWVjaGFuaXNtLCBJIHRoaW5rIHRoZSBt b3N0DQo+Pj4gICAgIHlvdSBjYW4gc2F5IGlzIE1BWS4NCj4+Pg0KPj4+ICAgICAtIFNlY3Rpb24g NS4yLiAiVGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4g U01QDQo+Pj4gICAgIGRvbWFpbi4iIEFzIHRoaXMgaXMgYSByZXF1aXJlbWVudCwgd2hhdCB5b3Ug bWVhbiBieSAidGllLWJyZWFraW5nDQo+Pj4gICAgIHJ1bGVzIiBzaG91bGQgYmUgZGVmaW5lZCBk aXJlY3RseSBvciBieSByZWZlcmVuY2UuDQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9uIDUuMy4gUkZD NjM3MiB0YWtlcyBhbiBhcHByb2FjaCB3aGVyZSBwcmVlbXB0aW9uIG5vdGlmaWNhdGlvbg0KPj4+ ICAgICBsZXZlcmFnZXMgdGhlIHN0YW5kYXJkIE1QTFMtVFAgT0FNIG1lY2hhbmlzbXMsIGlzIHRo ZXJlIGFueSByZWFzb24gdG8NCj4+PiAgICAgZG8gbW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2Mzcy Pw0KPj4+DQo+Pj4gICAgIC0gU2VjdGlvbiA1LjcuIFRoZXJlIG1heSBiZSBjb29yZGluYXRpb24g cmVxdWlyZWQgb24NCj4+PiAgICAgc29mdC1wcmVlbXB0aW9uIGFzDQo+Pj4gICAgIHdlbGwgKGRl cGVuZGluZyBvbiB0aGUgY3Jvc3MtY29ubmVjdHMgZXN0YWJsaXNoZWQgZHVyaW5nIExTUA0KPj4+ ICAgICBlc3RhYmxpc2htZW50KSBzbyBjb29yZGluYXRlZCBzd2l0Y2hpbmcgc2hvdWxkIGJlIHN1 cHBvcnRlZA0KPj4+ICAgICBpbmRlcGVuZGVudCBvZiBwcmVlbXB0aW9uIG1vZGUuDQo+Pj4NCj4+ PiAgICAgTml0czoNCj4+Pg0KPj4+ICAgICAtIEFic3RyYWN0OiBJIGRvbid0IHJlY2FsbCB0aGUg dGVybSAiZXhlY3V0aXZlIGFjdGlvbiIgYmVpbmcgdXNlZA0KPj4+ICAgICBpbiBhbnkNCj4+PiAg ICAgZWFybGllciByZWxhdGVkL3JlZmVyZW5jZWQgUkZDcy4gUmF0aGVyIHRoYW4gaW50cm9kdWNl IGEgbmV3IChhbmQNCj4+PiAgICAgdW5kZWZpbmVkKSB0ZXJtLCBwZXJoYXBzIHlvdSBjYW4gdXNl IGFuIGV4aXN0aW5nIG9uZSwgZS5nLiwNCj4+PiAgICAgInByb3RlY3Rpb24gc3dpdGNoIj8NCj4+ Pg0KPj4+ICAgICAtIFNlY3Rpb24gMSwgcGFyYWdyYXBoIDEuIERvIHdlIHJlYWxseSBuZWVkIGFu b3RoZXIgZGVmaW5pdGlvbiBvZg0KPj4+ICAgICBNUExTLVRQIHRvIGRlYmF0ZT8gSSBzdWdnZXN0 IGp1c3QgcmVmZXJlbmNpbmcgeW91ciBmYXZvcml0ZSBNUExTLVRQDQo+Pj4gICAgIGRvY3VtZW50 KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMuDQo+Pj4NCj4+PiAgICAg VGhlIGxhc3Qgc2VudGVuY2UgYWxzbyBtYWtlcyBhIHN1YmplY3RpdmUgc3RhdGVtZW50LiBXaGV0 aGVyIGl0IGlzDQo+Pj4gICAgIGNyaXRpY2FsIG9yIG5vIGlzIHVubmVjZXNzYXJ5LiBZb3UgY2Fu IGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtlIDYzNzINCj4+PiAgICAgcHJvdmlkZXMgYSBzdXJ2aXZh YmlsaXR5IGZyYW1ld29yayBmb3IgTVBMUy1UUCBhbmQgaXMgdGhlIGZvdW5kYXRpb24NCj4+PiAg ICAgZm9yIHRoaXMgZG9jdW1lbnQuDQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9uIDEsIHBhcmFncmFw aCAzLiBJc24ndCB0aGUgcmlnaHQgcmVmZXJlbmNlIDQ0Mjcgbm90IDQ0Mjg/DQo+Pj4gICAgIEFs c28gZHJvcCB0aGUgd29yZCBsaW5lYXIsIGFzIGl0IGlzIGFuIHVubmVjZXNzYXJ5IHF1YWxpZmll ciBhbmQNCj4+PiAgICAgNDQyNy80NDI4IGRvbid0IHVzZSBpdC4NCj4+Pg0KPj4+ICAgICAtIFNl Y3Rpb25zIDMgKGFuZCB0byBhIGxlc3NlciBkZWdyZWUgc2VjdGlvbiAyKSBhcmUgcmVhbGx5DQo+ Pj4gICAgIGludHJvZHVjdG9yeQ0KPj4+ICAgICB0ZXh0LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0 aGV5IGFyZW4ndCBwYXJ0IG9mIHNlY3Rpb24gMS4NCj4+Pg0KPj4+ICAgICAtIFNlY3Rpb24gMy4y IHNob3VsZCBoYXZlIGEgcmVmZXJlbmNlIGZvciAiZXhpc3RpbmcgY29udHJvbCBwbGFuZQ0KPj4+ ICAgICBzb2x1dGlvbnMgZm9yIFNNUCB3aXRoaW4gTVBMUyIuDQo+Pj4NCj4+PiAgICAgLSBTZWN0 aW9uIDMuMiBhZ2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZlIGFjdGlvbiIgdGVybS4NCj4+Pg0KPj4+ ICAgICAtIFNlY3Rpb24gNC4xLiBZb3Ugc2F5ICJ0d28gb3BlcmF0aW9ucyBzaW11bHRhbmVvdXNs eSIuIERvIHlvdSByZWFsbHkNCj4+PiAgICAgbWVhbiAic2ltdWx0YW5lb3VzbHkiIG9yIG1lcmVs eSB0aGF0IHRoZXkgbXVzdCBib3RoIG9jY3VyIGZvcg0KPj4+ICAgICBwcm90ZWN0aW9uIHRvIGJl IHByb3ZpZGVkPyAoU2FtZSBjb21tZW50IGluIHNlY3Rpb24gNS4xLg0KPj4+DQo+Pj4gICAgIC0g U2VjdGlvbiA1LjIuIEkgc3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0ZWQN Cj4+PiAgICAgcmVxdWlyZW1lbnRzDQo+Pj4gICAgIGxpc3QuDQo+Pj4NCj4+PiAgICAgLSBTZWN0 aW9uIDUuMjogRmlyc3QgcGFyYWdyYXBoIGFuZCBmb3J0aCBidWxsZXQgbGFzdCBzZW50ZW5jZS4g VGhlc2UNCj4+PiAgICAgYm90aCBiYXNpY2FsbHkgY292ZXIgdGhlIHNhbWUgdG9waWMgKHByZWVt cHRpb24pIGFuZCBhY3R1YWxseSBzYXkNCj4+PiAgICAgc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5n cy4gSSBzdWdnZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZQ0KPj4+ICAgICByZXF1aXJlbWVudCB0 byBlbnN1cmUgY29uc2lzdGVuY3kgYW5kIGZ1bGwgY292ZXJhZ2Ugb2YgdGhlIHRvcGljLg0KPj4+ DQo+Pj4gICAgIC0gU2VjdGlvbiA1LjIsIHJlcSA1LiBIb3cgZG9lcyB0aGlzIHJlbGF0ZSB0byBz ZWN0aW9uIDUuNT8gU2hvdWxkbid0DQo+Pj4gICAgIHRoZSB0b3BpY3MgcmVsYXRlZCB0byB0aW1p bmcgYmUgY29uc29saWRhdGVkPw0KPj4+DQo+Pj4gICAgIC0gU2VjdGlvbiA1LjI6IHJlcXVpcmVt ZW50IDYgc2VlbXMgdG8gYmUgYSBzdWJzZXQgb2YgNywgc28gaXQNCj4+PiAgICAgc2hvdWxkIGJl DQo+Pj4gICAgIGRyb3BwZWQuDQo+Pj4NCj4+PiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1l bnQgOC4gSXNuJ3QgdGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCj4+PiAgICAganVz dCB0aGlzIG9uZSB0cmFmZmljIHRyZWF0bWVudCAoc3ViKSByZXF1aXJlbWVudD8NCj4+Pg0KPj4+ ICAgICAtIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsDQo+Pj4NCj4+PiAgICAgLSBzZWN0aW9uIDUu NDogIiBXaGVuIHRoZSB3b3JraW5nIHBhdGggZGV0ZWN0cy4uIiBkZXRlY3Rpb24gaXMgYnkgdGhl DQo+Pj4gICAgIG5vZGUgbm90IHRoZSBwYXRoLg0KPj4+DQo+Pj4gICAgIC0gU2VjdGlvbiA1LjQs IGxhc3Qgc2VudGVuY2UuIFRoaXMgaXMgb25seSB0aGUgMm5kIHRpbWUgeW91IGltcGx5IHRoYXQN Cj4+PiAgICAgdGhlIGRvY3VtZW50IGNvdmVycyByZXF1aXJlbWVudHMgb24gYSBuZXcgcHJvdG9j b2wuIEkgdGhpbmsgdGhpcw0KPj4+ICAgICBwb2ludCBpcyBjdXJyZW50bHkgdG9vIHN1YnRsZSBp biB0aGUgZG9jdW1lbnQuIChUaGlzIHBvaW50IHdhcyBhbHNvDQo+Pj4gICAgIG1hZGUgYXMgYSBt aW5vciBjb21tZW50LikNCj4+Pg0KPj4+ICAgICAtIHNlY3Rpb24gNS42LiBSRkMgNjM3MiBzaG91 bGQgYmUgcmVmZXJlbmNlZA0KPj4+DQo+Pj4NCj4+PiAgICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiAgICAgbXBscyBtYWlsaW5nIGxpc3QNCj4+ PiAgICAgbXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+Pj4gICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+DQo+Pj4gICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gICAgIG1wbHMg bWFpbGluZyBsaXN0DQo+Pj4gICAgIG1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KPj4+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ Pg0KPg0KDQo= From nobody Mon Jul 14 00:51:38 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01FC1B29FC; Fri, 11 Jul 2014 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.602 X-Spam-Level: X-Spam-Status: No, score=-96.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf9BIUlHCjZ5; Fri, 11 Jul 2014 14:00:09 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5A21ACD01; Fri, 11 Jul 2014 14:00:08 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 12 Jul 2014 06:00:07 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Sat, 12 Jul 2014 06:00:06 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger Thread-Topic: =?ks_c_5601-1987?B?W1JURy1ESVJdIMi4vcU6IMi4vcU6ICBbbXBsc10gUnRnRGlyIHJl?= =?ks_c_5601-1987?B?dmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMt?= =?ks_c_5601-1987?Q?06.txt?= Thread-Index: AQHPnTu+I+zt/9CorUOfYbvrcdbcUpubVendgAADsf0= Date: Fri, 11 Jul 2014 21:00:05 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B31@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info>, <53BE7F3B.9010005@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749804@SMTP2.etri.info>, <53C03687.2000007@labn.net>, <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B0A@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B0A@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/cX075CzbpSSaT2KHT5k-KC5oJ40 X-Mailman-Approved-At: Mon, 14 Jul 2014 00:51:32 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogIMi4vcU6IMi4vcU6ICBbbXBsc10gUnRnRGly?= =?euc-kr?q?_review=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 21:00:14 -0000 TG91LCANCg0KSSBzZW50IHRoZSBwcmV2aW91cyBlbWFpbCB3aXRob3V0IHNob3dpbmcgdGhlIHBy b3Bvc2VkIHRleHQuIA0KVGhlIGxhc3Qgc2VudGVuY2Ugb2YgdGhlIGxhc3QgcGFyYWdyYXBoIGlu IFNlY3Rpb24gNC4xIHdpbGwgYmU6DQotLS0tLS0NCldoZW4gdGhlIHJlc2VydmVkIHJlc291cmNl cyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSB1dGlsaXplZCBieSANCmEgcGFydGljdWxhciBw cm90ZWN0aW9uIHBhdGgsIHRoZXJlIG1heSBub3QgYmUgc3VmZmljaWVudCByZXNvdXJjZXMNCmF2 YWlsYWJsZSBmb3IgYW4gYWRkaXRpb25hbCBwcm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBs aWVzIHRoYXQNCmlmIGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRoZSBTTVAgZG9tYWluIHRyaWdn ZXJzIGEgcHJvdGVjdGlvbg0Kc3dpdGNoLCB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRp bmF0aW9uIG1heSBmYWlsLg0KVGhlIGRpZmZlcmVudCB3b3JraW5nIHBhdGhzIGluIHRoZSBTTVAg bmV0d29yayBhcmUgaW52b2x2ZWQgaW4gdGhlIHJlc291cmNlIA0KdXRpbGl6YXRpb24gY29vcmRp bmF0aW9uLCB3aGljaCBpcyBhIHBhcnQgb2Ygd2hvbGUgU01QIHByb3RlY3Rpb24gc3dpdGNoaW5n IGNvb3JkaW5hdGlvbi4NCi0tLS0tLQ0KUGxlYXNlLCBsZXQgbWUga25vdyBpZiB0aGVyZSBpcyBz b21ldGluZyB0byBpbXByb3ZlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq6uLO9ILvntvc6ILf5waS1 vw0KurizvSCzr8KlOiAyMDE0s+IgN7/5IDEywM8gxeS/5MDPIL/AwPwgNTo0NA0Kud60wiC757b3 OiBMb3UgQmVyZ2VyDQrC/MG2OiBydGctZGlyQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBkcmFm dC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1hZHNA dG9vbHMuaWV0Zi5vcmcNCsGmuPE6IMi4vcU6IFtSVEctRElSXSDIuL3FOiDIuL3FOiAgW21wbHNd IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0K DQpMb3UsDQoNCkNlcnRhaW5seSwgaXQgY2FuIGJlIGRvbmUgYXMgeW91IHN1Z2dlc3RlZC4NCkkg YWxzbyB0aGluayB0aGF0IHlvdXIgc3VnZ2VzdGVkIGNoYW5nZSB3b3VsZCBoZWxwIHRoZSByZWFk aWJpbGl0eSBvZiB0aGlzIGRvY3VtZW50Lg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGhlbHAuDQoN CkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KurizvSC757b3OiBMb3UgQmVyZ2VyIFtsYmVyZ2VyQGxhYm4u bmV0XQ0KurizvSCzr8KlOiAyMDE0s+IgN7/5IDEywM8gxeS/5MDPIL/AwPwgNDowOQ0Kud60wiC7 57b3OiC3+cGktb8NCsL8wbY6IHJ0Zy1kaXJAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZzsgcnRnLWFkc0B0 b29scy5pZXRmLm9yZw0Kwaa48TogUmU6IFtSVEctRElSXSDIuL3FOiDIuL3FOiAgW21wbHNdIFJ0 Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KDQpU aGFuayB5b3UgLS0ganVzdCBvbmUgcmVzcG9uc2UgYW5kIHN1Z2dlc3RlZCBjaGFuZ2UuDQoNCkxv dQ0KDQpPbiAwNy8xMC8yMDE0IDA5OjQzIEFNLCC3+cGktb8gd3JvdGU6DQo+IExvdSwNCj4NCj4g VGhhbmsgeW91IGZvciBhZ3JlZWluZyBvbiBtb3N0IG9mIHRoZSBzdWdnZXN0aW9ucy4NCj4gUGxl YXNlLCBzZWUgdGhlIGxpbmVzIHN0YXJ0aW5nIHdpdGggW0pSMl0gYmVsb3cuDQo+DQo+IEJlc3Qg cmVnYXJkcywNCj4NCj4gSmVvbmctZG9uZw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ILq4s70gu+e29zogTG91IEJlcmdlciBbbGJlcmdlckBsYWJu Lm5ldF0NCi4uLg0KPj4gVGhpcyBpcyBmaW5lLCBidXQgSSB3b25kZXIgd2h5IHlvdSBhcmUgdXNp bmcgInJlc291cmNlIHV0aWxpemF0aW9uIiB2cw0KPiAicHJvdGVjdGlvbiBzd2l0Y2giPyAodGhp cyBpcyBhY3R1YWxseSBhIGJpdCBvZiBhIGdlbmVyYWwgY29tbWVudCAtLSBJDQo+IHRoZSBsYXR0 ZXIgaXMgYW4gZXhpc3RpbmcgYXBwbGljYWJsZSB0ZXJtIHRoYXQgd291bGQgaGVscCByZWFkZXJz IGhvdw0KPiB0aGlzIGRvY3VtZW50IGZpdHMgaW4gdG8gdGhlIHRlY2hub2xvZ3kgc3BhY2UuKQ0K Pj4NCj4+IFtKUl0gQXMgZGVzY3JpYmVkIGluIGFuIGVhcmxpZXIgcGFydCBvZiB0aGlzIHNlY3Rp b24sIFNNUCBwcm90ZWN0aW9uDQo+IGNvbnNpc3RzIG9mIHR3byBvcGVyYXRpb25zOiB0cmFmZmlj IHN3aXRjaG92ZXIgYW5kIHJlc291cmNlIHV0aWxpemF0aW9uDQo+IGNvb3JkaW5hdGlvbi4gVGhl IHNlbnRlbmNlcyBhcmUgYWJvdXQgdGhlIHJlc291cmNlIHV0aWxpemF0aW9uDQo+IGNvb3JkaW5h dGlvbiwgYW5kIKGwcmVzb3VyY2UgdXRpbGl6YXRpb26hsSBzZWVtcyB0byBiZSBtb3JlIGFjY3Vy YXRlLg0KPg0KPiBJcyAicmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIiBkb25lIHZp YSBzb21lIGZvcm0gb2YgaW50ZXItbm9kZQ0KPiBjb29yZGluYXRpb24/IElmIHllcywgdGhlbiBJ IHRoaW5rIG15IGNvbW1lbnQgaG9sZHMuICBJZiBubywgdGhlbiBJDQo+IHRoaW5rIHlvdSBzaG91 bGQgZWxhYm90YXRlIG9uIGhvdyB0aGUgImNvb3JkaW5hdGlvbiIgaW4gdGhpcyBjYXNlDQo+IGRp ZmZlcmVzIGZyb20gaG93IHlvdSB1c2UgImNvb3JkaW5hdGlvbiIgZWxzZXdoZXJlIGluIHRoZSBk b2N1bWVudC4NCj4gRWl0aGVyIHdheSwgSSB0aGluayB3ZSd2ZSBkaXNjdXNzZWQgdGhpcyBlbm91 Z2gsIGkuZS4sIEkgd29uJ3QgcHVzaCB0aGlzDQo+IHBvaW50IGZ1cnRoZXIuDQo+DQo+IFtKUjJd ICJyZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yaW5hdGlvbiIgb2NjdXJzIGJldHdlZW4gdGhlIG5v ZGVzIGFzIGluIG90aGVyIHByb3RlY3Rpb24gc3dpdGNoaW5nLiAicmVzb3VyY2UgdXRpbGl6YXRp b24gY29vcmRpbmF0aW9uIiBpcyBhIHBhcnQgb2Ygd2hvbGUgU01QIHByb3RlY3Rpb24gc3dpdGNo aW5nIGNvb3JkaW5hdGlvbiBhbmQgaXMgbWVhbnQgdG8gZW1waGFzaXplIHRoYXQgY29vcmRpbmF0 aW9uIGlzIGZvciByZXNvdXJjZSB1dGlsaXphdGlvbi4gT2YgY291cnNlLCB0aGUgcmVhc29uIHdo eSBpdCBkb2VzIHJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiBpcyB0byBjb21wbGV0 ZSBwcm90ZWN0aW9uIHN3aXRjaGluZyBldmVudHVhbGx5Lg0KPg0KDQpPa2F5LiBJIHRoaW5rIGFk ZGluZyBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICIicmVzb3VyY2UgdXRpbGl6YXRpb24N CmNvb3JkaW5hdGlvbiIgaXMgYSBwYXJ0IG9mIHdob2xlIFNNUCBwcm90ZWN0aW9uIHN3aXRjaGlu ZyBjb29yZGluYXRpb24gIg0KdG8gdGhlIHRleHQgd291bGQgY2xhcmlmeSB5b3VyIGludGVudCB0 byBmdXR1cmUgcmVhZGVycy4NCi4uLg0KDQo= From nobody Mon Jul 14 08:24:46 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328191A0A9B for ; Mon, 14 Jul 2014 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.283 X-Spam-Level: **** X-Spam-Status: No, score=4.283 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfSqp93Z_3sB for ; Mon, 14 Jul 2014 08:24:44 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 24D841A0A86 for ; Mon, 14 Jul 2014 08:24:44 -0700 (PDT) Received: (qmail 27263 invoked by uid 0); 14 Jul 2014 15:24:37 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 14 Jul 2014 15:24:37 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id SMQU1o00J2SSUrH01MQXEv; Mon, 14 Jul 2014 15:24:36 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=ZSdzdHkL1-cA:10 a=0h-4G3Jn0DgA:10 a=HFCU6gKsb0MA:10 a=jPJDawAOAc8A:10 a=XW0vzNQbW2AA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=FTdrIyHOBxr9dhh79YcA:9 a=Spabb166XhwA:10 a=lZB815dzVvQA:10 a=33rK67OTR_gA:10 a=PyHJAHBcnqkA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=drZQQW/fovSqJ0ECkPZdgtKJ/FhJ1NEc18SUkLeN1Xs=; b=hMSYIKN7RvKmA3NhyXRaqcDZu+4jREqVIEtnCNe9N733TdM0T0PrJUx1n6igp0g+8T997oFq6NQJXbUp1jnKNXs6OQWf/ukuPnv3jTpFBi+KFVQOz64Bw3PLeMHyqy1Y; Received: from box313.bluehost.com ([69.89.31.113]:37479 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X6i7B-0007TZ-Nc; Mon, 14 Jul 2014 09:24:29 -0600 Message-ID: <53C3F62A.8030903@labn.net> Date: Mon, 14 Jul 2014 11:24:26 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?EUC-KR?B?t/nBpLW/?= References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info>, <53BE7F3B.9010005@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749804@SMTP2.etri.info>, <53C03687.2000007@labn.net>, <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B0A@SMTP2.etri.info> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B31@SMTP2.etri.info> In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B31@SMTP2.etri.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/1X2TxN6u0Hw2OG2PFAC5PB0tmCA Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] =?euc-kr?b?yLi9xTogIMi4vcU6IMi4vcU6ICBbbXBsc10gUnRnRGly?= =?euc-kr?q?_review=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 15:24:45 -0000 Jeong-dong, Unless I missed something, I think we've closed all topics. Agreed? Much thanks, Lou On 07/11/2014 05:00 PM, ·ùÁ¤µ¿ wrote: > Lou, > > I sent the previous email without showing the proposed text. > The last sentence of the last paragraph in Section 4.1 will be: > ------ > When the reserved resources of the shared segments are utilized by > a particular protection path, there may not be sufficient resources > available for an additional protection path. This then implies that > if another working path of the SMP domain triggers a protection > switch, the resource utilization coordination may fail. > The different working paths in the SMP network are involved in the resource > utilization coordination, which is a part of whole SMP protection switching coordination. > ------ > Please, let me know if there is someting to improve. > > Best regards, > > Jeong-dong > > > ________________________________________ > º¸³½ »ç¶÷: ·ùÁ¤µ¿ > º¸³½ ³¯Â¥: 2014³â 7¿ù 12ÀÏ Åä¿äÀÏ ¿ÀÀü 5:44 > ¹Þ´Â »ç¶÷: Lou Berger > ÂüÁ¶: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-smp-requirements.all@tools.ietf.org; rtg-ads@tools.ietf.org > Á¦¸ñ: ȸ½Å: [RTG-DIR] ȸ½Å: ȸ½Å: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt > > Lou, > > Certainly, it can be done as you suggested. > I also think that your suggested change would help the readibility of this document. > Thanks a lot for your help. > > Best regards, > > Jeong-dong > > > > ________________________________________ > º¸³½ »ç¶÷: Lou Berger [lberger@labn.net] > º¸³½ ³¯Â¥: 2014³â 7¿ù 12ÀÏ Åä¿äÀÏ ¿ÀÀü 4:09 > ¹Þ´Â »ç¶÷: ·ùÁ¤µ¿ > ÂüÁ¶: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-smp-requirements.all@tools.ietf.org; rtg-ads@tools.ietf.org > Á¦¸ñ: Re: [RTG-DIR] ȸ½Å: ȸ½Å: [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt > > Thank you -- just one response and suggested change. > > Lou > > On 07/10/2014 09:43 AM, ·ùÁ¤µ¿ wrote: >> Lou, >> >> Thank you for agreeing on most of the suggestions. >> Please, see the lines starting with [JR2] below. >> >> Best regards, >> >> Jeong-dong >> >> >> ________________________________________ >> º¸³½ »ç¶÷: Lou Berger [lberger@labn.net] > ... >>> This is fine, but I wonder why you are using "resource utilization" vs >> "protection switch"? (this is actually a bit of a general comment -- I >> the latter is an existing applicable term that would help readers how >> this document fits in to the technology space.) >>> >>> [JR] As described in an earlier part of this section, SMP protection >> consists of two operations: traffic switchover and resource utilization >> coordination. The sentences are about the resource utilization >> coordination, and ¡°resource utilization¡± seems to be more accurate. >> >> Is "resource utilization coordination" done via some form of inter-node >> coordination? If yes, then I think my comment holds. If no, then I >> think you should elabotate on how the "coordination" in this case >> differes from how you use "coordination" elsewhere in the document. >> Either way, I think we've discussed this enough, i.e., I won't push this >> point further. >> >> [JR2] "resource utilization coorination" occurs between the nodes as in other protection switching. "resource utilization coordination" is a part of whole SMP protection switching coordination and is meant to emphasize that coordination is for resource utilization. Of course, the reason why it does resource utilization coordination is to complete protection switching eventually. >> > > Okay. I think adding something along the lines of ""resource utilization > coordination" is a part of whole SMP protection switching coordination " > to the text would clarify your intent to future readers. > ... > From nobody Tue Jul 15 00:14:40 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417F81B27EC; Mon, 14 Jul 2014 17:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC_caB4swp5g; Mon, 14 Jul 2014 17:56:05 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CCB01B27DA; Mon, 14 Jul 2014 17:56:05 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 15 Jul 2014 09:56:03 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Tue, 15 Jul 2014 09:56:02 +0900 From: Jeong Ryoo To: Lou Berger Thread-Topic: =?utf-8?B?W1JURy1ESVJdIO2ajOyLoDogIO2ajOyLoDog7ZqM7IugOiAgW21wbHNdIFJ0?= =?utf-8?B?Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRz?= =?utf-8?Q?-06.txt?= Thread-Index: AQHPn3e7uepjPT4mU0qK6Tz1m0V7U5ugT2Vz Date: Tue, 15 Jul 2014 00:56:02 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A28749F56@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info>, <53BE7F3B.9010005@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749804@SMTP2.etri.info>, <53C03687.2000007@labn.net>, <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B0A@SMTP2.etri.info> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749B31@SMTP2.etri.info>, <53C3F62A.8030903@labn.net> In-Reply-To: <53C3F62A.8030903@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: SmVvbmcgUnlvbw== x-originating-ip: [129.254.28.41] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28749F56SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/MXss-ttnR7-PuQeQEDVzoGVqnBo X-Mailman-Approved-At: Tue, 15 Jul 2014 00:14:38 -0700 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] =?utf-8?b?7ZqM7IugOiAg7ZqM7IugOiDtmozsi6A6ICBbbXBsc10g?= =?utf-8?q?RtgDir_review=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 00:56:08 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28749F56SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpMb3UsDQoNCk15IHJlY29yZCBzYXlzIHRoZSBzYW1lLiBNYW55IHRoYW5rcyBmb3IgeW91ciBy ZXZpZXcgYW5kIGhlbHBmdWwgY29tbWVudHMuDQpJIHdpbGwgcmVmbGVjdCBhbGwgdGhlIHJlc29s dXRpb25zIHRvIGEgcmV2aXNpb24gYW5kIHBvc3QgaW4gcHVibGljIHNvb24uDQoNCkJlc3QgcmVn YXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQrrs7Trgrgg7IKs656MIDogIkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0Pg0K67O064K4 IOuCoOynnCA6IDIwMTQtMDctMTUgMDA6MjQ6NDEgKCArMDk6MDAgKQ0K67Cb64qUIOyCrOuejCA6 IOulmOygleuPmSA8cnlvb0BldHJpLnJlLmtyPg0K7LC47KGwIDogcnRnLWRpckBpZXRmLm9yZyA8 cnRnLWRpckBpZXRmLm9yZz4sIHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcgPHJ0Zy1hZHNAdG9vbHMu aWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0 Zi5vcmcgPGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9y Zz4sIG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+DQrsoJzrqqkgOiBSZTogW1JURy1ESVJd IO2ajOyLoDog7ZqM7IugOiDtmozsi6A6IFttcGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRm LW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50eHQNCg0KSmVvbmctZG9uZywNCg0KVW5sZXNzIEkg bWlzc2VkIHNvbWV0aGluZywgSSB0aGluayB3ZSd2ZSBjbG9zZWQgYWxsIHRvcGljcy4gQWdyZWVk Pw0KDQpNdWNoIHRoYW5rcywNCkxvdQ0KDQpPbiAwNy8xMS8yMDE0IDA1OjAwIFBNLCDrpZjsoJXr j5kgd3JvdGU6DQo+IExvdSwNCj4NCj4gSSBzZW50IHRoZSBwcmV2aW91cyBlbWFpbCB3aXRob3V0 IHNob3dpbmcgdGhlIHByb3Bvc2VkIHRleHQuDQo+IFRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBs YXN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDQuMSB3aWxsIGJlOg0KPiAtLS0tLS0NCj4gV2hlbiB0 aGUgcmVzZXJ2ZWQgcmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJlIHV0aWxpemVk IGJ5DQo+IGEgcGFydGljdWxhciBwcm90ZWN0aW9uIHBhdGgsIHRoZXJlIG1heSBub3QgYmUgc3Vm ZmljaWVudCByZXNvdXJjZXMNCj4gYXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rp b24gcGF0aC4gVGhpcyB0aGVuIGltcGxpZXMgdGhhdA0KPiBpZiBhbm90aGVyIHdvcmtpbmcgcGF0 aCBvZiB0aGUgU01QIGRvbWFpbiB0cmlnZ2VycyBhIHByb3RlY3Rpb24NCj4gc3dpdGNoLCB0aGUg cmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIG1heSBmYWlsLg0KPiBUaGUgZGlmZmVy ZW50IHdvcmtpbmcgcGF0aHMgaW4gdGhlIFNNUCBuZXR3b3JrIGFyZSBpbnZvbHZlZCBpbiB0aGUg cmVzb3VyY2UNCj4gdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uLCB3aGljaCBpcyBhIHBhcnQgb2Yg d2hvbGUgU01QIHByb3RlY3Rpb24gc3dpdGNoaW5nIGNvb3JkaW5hdGlvbi4NCj4gLS0tLS0tDQo+ IFBsZWFzZSwgbGV0IG1lIGtub3cgaWYgdGhlcmUgaXMgc29tZXRpbmcgdG8gaW1wcm92ZS4NCj4N Cj4gQmVzdCByZWdhcmRzLA0KPg0KPiBKZW9uZy1kb25nDQo+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g67O064K4IOyCrOuejDog66WY7KCV64+ZDQo+ IOuztOuCuCDrgqDsp5w6IDIwMTTrhYQgN+yblCAxMuydvCDthqDsmpTsnbwg7Jik7KCEIDU6NDQN Cj4g67Cb64qUIOyCrOuejDogTG91IEJlcmdlcg0KPiDssLjsobA6IHJ0Zy1kaXJAaWV0Zi5vcmc7 IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1lbnRzLmFsbEB0b29s cy5pZXRmLm9yZzsgcnRnLWFkc0B0b29scy5pZXRmLm9yZw0KPiDsoJzrqqk6IO2ajOyLoDogW1JU Ry1ESVJdIO2ajOyLoDog7ZqM7IugOiBbbXBsc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1t cGxzLXNtcC1yZXF1aXJlbWVudHMtMDYudHh0DQo+DQo+IExvdSwNCj4NCj4gQ2VydGFpbmx5LCBp dCBjYW4gYmUgZG9uZSBhcyB5b3Ugc3VnZ2VzdGVkLg0KPiBJIGFsc28gdGhpbmsgdGhhdCB5b3Vy IHN1Z2dlc3RlZCBjaGFuZ2Ugd291bGQgaGVscCB0aGUgcmVhZGliaWxpdHkgb2YgdGhpcyBkb2N1 bWVudC4NCj4gVGhhbmtzIGEgbG90IGZvciB5b3VyIGhlbHAuDQo+DQo+IEJlc3QgcmVnYXJkcywN Cj4NCj4gSmVvbmctZG9uZw0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IOuztOuCuCDsgqzrnow6IExvdSBCZXJnZXIgW2xiZXJnZXJAbGFibi5u ZXRdDQo+IOuztOuCuCDrgqDsp5w6IDIwMTTrhYQgN+yblCAxMuydvCDthqDsmpTsnbwg7Jik7KCE IDQ6MDkNCj4g67Cb64qUIOyCrOuejDog66WY7KCV64+ZDQo+IOywuOyhsDogcnRnLWRpckBpZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxs QHRvb2xzLmlldGYub3JnOyBydGctYWRzQHRvb2xzLmlldGYub3JnDQo+IOygnOuqqTogUmU6IFtS VEctRElSXSDtmozsi6A6IO2ajOyLoDogW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYt bXBscy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KPg0KPiBUaGFuayB5b3UgLS0ganVzdCBvbmUg cmVzcG9uc2UgYW5kIHN1Z2dlc3RlZCBjaGFuZ2UuDQo+DQo+IExvdQ0KPg0KPiBPbiAwNy8xMC8y MDE0IDA5OjQzIEFNLCDrpZjsoJXrj5kgd3JvdGU6DQo+PiBMb3UsDQo+Pg0KPj4gVGhhbmsgeW91 IGZvciBhZ3JlZWluZyBvbiBtb3N0IG9mIHRoZSBzdWdnZXN0aW9ucy4NCj4+IFBsZWFzZSwgc2Vl IHRoZSBsaW5lcyBzdGFydGluZyB3aXRoIFtKUjJdIGJlbG93Lg0KPj4NCj4+IEJlc3QgcmVnYXJk cywNCj4+DQo+PiBKZW9uZy1kb25nDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IOuztOuCuCDsgqzrnow6IExvdSBCZXJnZXIgW2xiZXJnZXJA bGFibi5uZXRdDQo+IC4uLg0KPj4+IFRoaXMgaXMgZmluZSwgYnV0IEkgd29uZGVyIHdoeSB5b3Ug YXJlIHVzaW5nICJyZXNvdXJjZSB1dGlsaXphdGlvbiIgdnMNCj4+ICJwcm90ZWN0aW9uIHN3aXRj aCI/ICh0aGlzIGlzIGFjdHVhbGx5IGEgYml0IG9mIGEgZ2VuZXJhbCBjb21tZW50IC0tIEkNCj4+ IHRoZSBsYXR0ZXIgaXMgYW4gZXhpc3RpbmcgYXBwbGljYWJsZSB0ZXJtIHRoYXQgd291bGQgaGVs cCByZWFkZXJzIGhvdw0KPj4gdGhpcyBkb2N1bWVudCBmaXRzIGluIHRvIHRoZSB0ZWNobm9sb2d5 IHNwYWNlLikNCj4+Pg0KPj4+IFtKUl0gQXMgZGVzY3JpYmVkIGluIGFuIGVhcmxpZXIgcGFydCBv ZiB0aGlzIHNlY3Rpb24sIFNNUCBwcm90ZWN0aW9uDQo+PiBjb25zaXN0cyBvZiB0d28gb3BlcmF0 aW9uczogdHJhZmZpYyBzd2l0Y2hvdmVyIGFuZCByZXNvdXJjZSB1dGlsaXphdGlvbg0KPj4gY29v cmRpbmF0aW9uLiBUaGUgc2VudGVuY2VzIGFyZSBhYm91dCB0aGUgcmVzb3VyY2UgdXRpbGl6YXRp b24NCj4+IGNvb3JkaW5hdGlvbiwgYW5kIOKAnHJlc291cmNlIHV0aWxpemF0aW9u4oCdIHNlZW1z IHRvIGJlIG1vcmUgYWNjdXJhdGUuDQo+Pg0KPj4gSXMgInJlc291cmNlIHV0aWxpemF0aW9uIGNv b3JkaW5hdGlvbiIgZG9uZSB2aWEgc29tZSBmb3JtIG9mIGludGVyLW5vZGUNCj4+IGNvb3JkaW5h dGlvbj8gSWYgeWVzLCB0aGVuIEkgdGhpbmsgbXkgY29tbWVudCBob2xkcy4gSWYgbm8sIHRoZW4g SQ0KPj4gdGhpbmsgeW91IHNob3VsZCBlbGFib3RhdGUgb24gaG93IHRoZSAiY29vcmRpbmF0aW9u IiBpbiB0aGlzIGNhc2UNCj4+IGRpZmZlcmVzIGZyb20gaG93IHlvdSB1c2UgImNvb3JkaW5hdGlv biIgZWxzZXdoZXJlIGluIHRoZSBkb2N1bWVudC4NCj4+IEVpdGhlciB3YXksIEkgdGhpbmsgd2Un dmUgZGlzY3Vzc2VkIHRoaXMgZW5vdWdoLCBpLmUuLCBJIHdvbid0IHB1c2ggdGhpcw0KPj4gcG9p bnQgZnVydGhlci4NCj4+DQo+PiBbSlIyXSAicmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmluYXRp b24iIG9jY3VycyBiZXR3ZWVuIHRoZSBub2RlcyBhcyBpbiBvdGhlciBwcm90ZWN0aW9uIHN3aXRj aGluZy4gInJlc291cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiIgaXMgYSBwYXJ0IG9mIHdo b2xlIFNNUCBwcm90ZWN0aW9uIHN3aXRjaGluZyBjb29yZGluYXRpb24gYW5kIGlzIG1lYW50IHRv IGVtcGhhc2l6ZSB0aGF0IGNvb3JkaW5hdGlvbiBpcyBmb3IgcmVzb3VyY2UgdXRpbGl6YXRpb24u IE9mIGNvdXJzZSwgdGhlIHJlYXNvbiB3aHkgaXQgZG9lcyByZXNvdXJjZSB1dGlsaXphdGlvbiBj b29yZGluYXRpb24gaXMgdG8gY29tcGxldGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgZXZlbnR1YWxs eS4NCj4+DQo+DQo+IE9rYXkuIEkgdGhpbmsgYWRkaW5nIHNvbWV0aGluZyBhbG9uZyB0aGUgbGlu ZXMgb2YgIiJyZXNvdXJjZSB1dGlsaXphdGlvbg0KPiBjb29yZGluYXRpb24iIGlzIGEgcGFydCBv ZiB3aG9sZSBTTVAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgY29vcmRpbmF0aW9uICINCj4gdG8gdGhl IHRleHQgd291bGQgY2xhcmlmeSB5b3VyIGludGVudCB0byBmdXR1cmUgcmVhZGVycy4NCj4gLi4u DQo+DQoNCg== --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28749F56SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIw cHQiPjxicj4NCkxvdSw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij4mbmJz cDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij5NeSByZWNvcmQgc2F5cyB0 aGUgc2FtZS4gTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBoZWxwZnVsIGNvbW1lbnRz LjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQiPkkgd2lsbCZuYnNwO3JlZmxl Y3QgYWxsIHRoZSByZXNvbHV0aW9ucyZuYnNwO3RvJm5ic3A7YSZuYnNwO3JldmlzaW9uIGFuZCBw b3N0Jm5ic3A7aW4gcHVibGljIHNvb24uPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MjBwdCI+Jm5ic3A7PGJyPg0KQmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1I RUlHSFQ6IDIwcHQiPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDIwcHQi Pkplb25nLWRvbmc8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij4mbmJzcDs8 L2Rpdj4NCjxkaXYgaWQ9Ik1haWxTaWduU2VudCIgc3R5bGU9IkxJTkUtSEVJR0hUOiAyMHB0Ij48 YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9Ik9SR01BSUxfQ09OVEVOVCIgc3R5bGU9IkxJTkUtSEVJR0hU OiAyMHB0Ij4NCjxociB0YWJpbmRleD0iLTEiPg0KPGI+67O064K4IOyCrOuejCA6IDwvYj4mcXVv dDtMb3UgQmVyZ2VyJnF1b3Q7ICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0Ozxicj4NCjxiPuuztOuC uCDrgqDsp5wgOiA8L2I+MjAxNC0wNy0xNSAwMDoyNDo0MSAoICYjNDM7MDk6MDAgKTxicj4NCjxi Puuwm+uKlCDsgqzrnowgOiA8L2I+66WY7KCV64+ZICZsdDtyeW9vQGV0cmkucmUua3ImZ3Q7PGJy Pg0KPGI+7LC47KGwIDogPC9iPnJ0Zy1kaXJAaWV0Zi5vcmcgJmx0O3J0Zy1kaXJAaWV0Zi5vcmcm Z3Q7LCBydGctYWRzQHRvb2xzLmlldGYub3JnICZsdDtydGctYWRzQHRvb2xzLmlldGYub3JnJmd0 OywgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnICZs dDtkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmcmZ3Q7 LCBtcGxzQGlldGYub3JnICZsdDttcGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPuygnOuqqSA6IDwv Yj5SZTogW1JURy1ESVJdIO2ajOyLoDog7ZqM7IugOiDtmozsi6A6IFttcGxzXSBSdGdEaXIgcmV2 aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50eHQ8YnI+DQo8YnI+DQpK ZW9uZy1kb25nLDxicj4NCjxicj4NClVubGVzcyBJIG1pc3NlZCBzb21ldGhpbmcsIEkgdGhpbmsg d2UndmUgY2xvc2VkIGFsbCB0b3BpY3MuIEFncmVlZD88YnI+DQo8YnI+DQpNdWNoIHRoYW5rcyw8 YnI+DQpMb3U8YnI+DQo8YnI+DQpPbiAwNy8xMS8yMDE0IDA1OjAwIFBNLCDrpZjsoJXrj5kgd3Jv dGU6PGJyPg0KJmd0OyBMb3UsIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHNlbnQgdGhlIHByZXZp b3VzIGVtYWlsIHdpdGhvdXQgc2hvd2luZyB0aGUgcHJvcG9zZWQgdGV4dC4gPGJyPg0KJmd0OyBU aGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUgbGFzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA0LjEgd2ls bCBiZTo8YnI+DQomZ3Q7IC0tLS0tLTxicj4NCiZndDsgV2hlbiB0aGUgcmVzZXJ2ZWQgcmVzb3Vy Y2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJlIHV0aWxpemVkIGJ5IDxicj4NCiZndDsgYSBw YXJ0aWN1bGFyIHByb3RlY3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50IHJl c291cmNlczxicj4NCiZndDsgYXZhaWxhYmxlIGZvciBhbiBhZGRpdGlvbmFsIHByb3RlY3Rpb24g cGF0aC4gVGhpcyB0aGVuIGltcGxpZXMgdGhhdDxicj4NCiZndDsgaWYgYW5vdGhlciB3b3JraW5n IHBhdGggb2YgdGhlIFNNUCBkb21haW4gdHJpZ2dlcnMgYSBwcm90ZWN0aW9uPGJyPg0KJmd0OyBz d2l0Y2gsIHRoZSByZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24gbWF5IGZhaWwuPGJy Pg0KJmd0OyBUaGUgZGlmZmVyZW50IHdvcmtpbmcgcGF0aHMgaW4gdGhlIFNNUCBuZXR3b3JrIGFy ZSBpbnZvbHZlZCBpbiB0aGUgcmVzb3VyY2UgPGJyPg0KJmd0OyB1dGlsaXphdGlvbiBjb29yZGlu YXRpb24sIHdoaWNoIGlzIGEgcGFydCBvZiB3aG9sZSBTTVAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcg Y29vcmRpbmF0aW9uLjxicj4NCiZndDsgLS0tLS0tPGJyPg0KJmd0OyBQbGVhc2UsIGxldCBtZSBr bm93IGlmIHRoZXJlIGlzIHNvbWV0aW5nIHRvIGltcHJvdmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSmVvbmctZG9uZzxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IOuztOuCuCDsgqzrnow6IOulmOygleuPmTxicj4NCiZndDsg67O064K4 IOuCoOynnDogMjAxNOuFhCA37JuUIDEy7J28IO2GoOyalOydvCDsmKTsoIQgNTo0NDxicj4NCiZn dDsg67Cb64qUIOyCrOuejDogTG91IEJlcmdlcjxicj4NCiZndDsg7LC47KGwOiBydGctZGlyQGll dGYub3JnOyBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5h bGxAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc8YnI+DQomZ3Q7IOygnOuq qTog7ZqM7IugOiBbUlRHLURJUl0g7ZqM7IugOiDtmozsi6A6IFttcGxzXSBSdGdEaXIgcmV2aWV3 OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50eHQ8YnI+DQomZ3Q7IDxicj4N CiZndDsgTG91LDxicj4NCiZndDsgPGJyPg0KJmd0OyBDZXJ0YWlubHksIGl0IGNhbiBiZSBkb25l IGFzIHlvdSBzdWdnZXN0ZWQuPGJyPg0KJmd0OyBJIGFsc28gdGhpbmsgdGhhdCB5b3VyIHN1Z2dl c3RlZCBjaGFuZ2Ugd291bGQgaGVscCB0aGUgcmVhZGliaWxpdHkgb2YgdGhpcyBkb2N1bWVudC48 YnI+DQomZ3Q7IFRoYW5rcyBhIGxvdCBmb3IgeW91ciBoZWxwLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEplb25nLWRvbmc8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IOuztOuCuCDsgqzrnow6IExvdSBCZXJnZXIgW2xi ZXJnZXJAbGFibi5uZXRdPGJyPg0KJmd0OyDrs7Trgrgg64Kg7KecOiAyMDE064WEIDfsm5QgMTLs nbwg7Yag7JqU7J28IOyYpOyghCA0OjA5PGJyPg0KJmd0OyDrsJvripQg7IKs656MOiDrpZjsoJXr j5k8YnI+DQomZ3Q7IOywuOyhsDogcnRnLWRpckBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnOyBydGctYWRz QHRvb2xzLmlldGYub3JnPGJyPg0KJmd0OyDsoJzrqqk6IFJlOiBbUlRHLURJUl0g7ZqM7IugOiDt mozsi6A6IFttcGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVt ZW50cy0wNi50eHQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmsgeW91IC0tIGp1c3Qgb25lIHJl c3BvbnNlIGFuZCBzdWdnZXN0ZWQgY2hhbmdlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBMb3U8YnI+ DQomZ3Q7IDxicj4NCiZndDsgT24gMDcvMTAvMjAxNCAwOTo0MyBBTSwg66WY7KCV64+ZIHdyb3Rl Ojxicj4NCiZndDsmZ3Q7IExvdSw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rIHlv dSBmb3IgYWdyZWVpbmcgb24gbW9zdCBvZiB0aGUgc3VnZ2VzdGlvbnMuPGJyPg0KJmd0OyZndDsg UGxlYXNlLCBzZWUgdGhlIGxpbmVzIHN0YXJ0aW5nIHdpdGggW0pSMl0gYmVsb3cuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBKZW9uZy1kb25nPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyDr s7Trgrgg7IKs656MOiBMb3UgQmVyZ2VyIFtsYmVyZ2VyQGxhYm4ubmV0XTxicj4NCiZndDsgLi4u PGJyPg0KJmd0OyZndDsmZ3Q7IFRoaXMgaXMgZmluZSwgYnV0IEkgd29uZGVyIHdoeSB5b3UgYXJl IHVzaW5nICZxdW90O3Jlc291cmNlIHV0aWxpemF0aW9uJnF1b3Q7IHZzPGJyPg0KJmd0OyZndDsg JnF1b3Q7cHJvdGVjdGlvbiBzd2l0Y2gmcXVvdDs/ICh0aGlzIGlzIGFjdHVhbGx5IGEgYml0IG9m IGEgZ2VuZXJhbCBjb21tZW50IC0tIEk8YnI+DQomZ3Q7Jmd0OyB0aGUgbGF0dGVyIGlzIGFuIGV4 aXN0aW5nIGFwcGxpY2FibGUgdGVybSB0aGF0IHdvdWxkIGhlbHAgcmVhZGVycyBob3c8YnI+DQom Z3Q7Jmd0OyB0aGlzIGRvY3VtZW50IGZpdHMgaW4gdG8gdGhlIHRlY2hub2xvZ3kgc3BhY2UuKTxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBbSlJdIEFzIGRlc2NyaWJlZCBpbiBh biBlYXJsaWVyIHBhcnQgb2YgdGhpcyBzZWN0aW9uLCBTTVAgcHJvdGVjdGlvbjxicj4NCiZndDsm Z3Q7IGNvbnNpc3RzIG9mIHR3byBvcGVyYXRpb25zOiB0cmFmZmljIHN3aXRjaG92ZXIgYW5kIHJl c291cmNlIHV0aWxpemF0aW9uPGJyPg0KJmd0OyZndDsgY29vcmRpbmF0aW9uLiBUaGUgc2VudGVu Y2VzIGFyZSBhYm91dCB0aGUgcmVzb3VyY2UgdXRpbGl6YXRpb248YnI+DQomZ3Q7Jmd0OyBjb29y ZGluYXRpb24sIGFuZCDigJxyZXNvdXJjZSB1dGlsaXphdGlvbuKAnSBzZWVtcyB0byBiZSBtb3Jl IGFjY3VyYXRlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSXMgJnF1b3Q7cmVzb3VyY2Ug dXRpbGl6YXRpb24gY29vcmRpbmF0aW9uJnF1b3Q7IGRvbmUgdmlhIHNvbWUgZm9ybSBvZiBpbnRl ci1ub2RlPGJyPg0KJmd0OyZndDsgY29vcmRpbmF0aW9uPyBJZiB5ZXMsIHRoZW4gSSB0aGluayBt eSBjb21tZW50IGhvbGRzLiBJZiBubywgdGhlbiBJPGJyPg0KJmd0OyZndDsgdGhpbmsgeW91IHNo b3VsZCBlbGFib3RhdGUgb24gaG93IHRoZSAmcXVvdDtjb29yZGluYXRpb24mcXVvdDsgaW4gdGhp cyBjYXNlPGJyPg0KJmd0OyZndDsgZGlmZmVyZXMgZnJvbSBob3cgeW91IHVzZSAmcXVvdDtjb29y ZGluYXRpb24mcXVvdDsgZWxzZXdoZXJlIGluIHRoZSBkb2N1bWVudC48YnI+DQomZ3Q7Jmd0OyBF aXRoZXIgd2F5LCBJIHRoaW5rIHdlJ3ZlIGRpc2N1c3NlZCB0aGlzIGVub3VnaCwgaS5lLiwgSSB3 b24ndCBwdXNoIHRoaXM8YnI+DQomZ3Q7Jmd0OyBwb2ludCBmdXJ0aGVyLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgW0pSMl0gJnF1b3Q7cmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmluYXRp b24mcXVvdDsgb2NjdXJzIGJldHdlZW4gdGhlIG5vZGVzIGFzIGluIG90aGVyIHByb3RlY3Rpb24g c3dpdGNoaW5nLiAmcXVvdDtyZXNvdXJjZSB1dGlsaXphdGlvbiBjb29yZGluYXRpb24mcXVvdDsg aXMgYSBwYXJ0IG9mIHdob2xlIFNNUCBwcm90ZWN0aW9uIHN3aXRjaGluZyBjb29yZGluYXRpb24g YW5kIGlzIG1lYW50IHRvIGVtcGhhc2l6ZSB0aGF0IGNvb3JkaW5hdGlvbiBpcyBmb3IgcmVzb3Vy Y2UgdXRpbGl6YXRpb24uDQogT2YgY291cnNlLCB0aGUgcmVhc29uIHdoeSBpdCBkb2VzIHJlc291 cmNlIHV0aWxpemF0aW9uIGNvb3JkaW5hdGlvbiBpcyB0byBjb21wbGV0ZSBwcm90ZWN0aW9uIHN3 aXRjaGluZyBldmVudHVhbGx5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9r YXkuIEkgdGhpbmsgYWRkaW5nIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgJnF1b3Q7JnF1 b3Q7cmVzb3VyY2UgdXRpbGl6YXRpb248YnI+DQomZ3Q7IGNvb3JkaW5hdGlvbiZxdW90OyBpcyBh IHBhcnQgb2Ygd2hvbGUgU01QIHByb3RlY3Rpb24gc3dpdGNoaW5nIGNvb3JkaW5hdGlvbiAmcXVv dDs8YnI+DQomZ3Q7IHRvIHRoZSB0ZXh0IHdvdWxkIGNsYXJpZnkgeW91ciBpbnRlbnQgdG8gZnV0 dXJlIHJlYWRlcnMuPGJyPg0KJmd0OyAuLi48YnI+DQomZ3Q7IDxicj4NCjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A28749F56SMTP2etriinfo_-- From nobody Thu Jul 17 02:00:48 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C221A0164; Thu, 17 Jul 2014 02:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtBysORQAKGd; Thu, 17 Jul 2014 02:00:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B231A011E; Thu, 17 Jul 2014 02:00:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6H8R61t012352; Thu, 17 Jul 2014 09:27:06 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6H8R5GW012346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Jul 2014 09:27:06 +0100 From: "Adrian Farrel" To: , , Date: Thu, 17 Jul 2014 09:27:10 +0100 Message-ID: <03c501cfa198$e7c6f370$b754da50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+hmOS2BGbE6mcYRk+Itxz2a0ycfQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20822.005 X-TM-AS-Result: No--2.271-10.0-31-10 X-imss-scan-details: No--2.271-10.0-31-10 X-TMASE-MatchedRID: dbwu/f0cqRo6SNANGjU5lNPNaYYJeRf5fS0Ip2eEHny+qryzYw2E8M4b ajgO0kgvgZK4jdUf7rU+Aoot6UqUmMRB0bsfrpPIcSqbxBgG0w7myCUQ3qrOJN3UfQdioOnab60 IPG+mHcoTWtROkTeuhiXidVjAhEZBrX7cmKNisA4yqaEb8zSjj/QwfDO7YmjAf+weolWHdq6UTG VAhB5EbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ERuOahMt2ege0gAvIxIKga81Trw Cc: 'Alia Atlas' Subject: [RTG-DIR] RTG ADs' office hours in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 09:00:44 -0000 Hi, Sunday 14.30-16.00 in "Alberta" Just drop in and talk to us about your routing concerns. Alia and Adrian From nobody Mon Jul 21 08:03:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B905F1A0178; Mon, 21 Jul 2014 08:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1OX1vo14iJ2; Mon, 21 Jul 2014 08:03:19 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D307F1A00F1; Mon, 21 Jul 2014 08:02:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id B5DB3121C4F; Mon, 21 Jul 2014 08:02:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 460DE121C56; Mon, 21 Jul 2014 08:02:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1962.2\)) From: Thomas Heide Clausen In-Reply-To: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> Date: Mon, 21 Jul 2014 17:02:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.1962.2) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/R2LC6TKvup_5KtOAR4mS7ngXnuk Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:03:21 -0000 Hey A^2, I may have missed it, but was there a room announced for this event =E2=80= =94 or, is the recommended to stalk either of you after the morning = sessions, and see where that takes us? Cheers, Thomas =20 > On 24 Jun 2014, at 22:14 , Adrian Farrel wrote: >=20 > Chairs and Directorate, >=20 > Alia and I have blocked out a slot in Toronto for you to come and = discuss Area > reorganisation with us. >=20 > We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG WG = meetings, > so we suggest "grab lunch and come along". Room to be announced. >=20 > The meeting will not be announced wider than this grouping, but will = not be a > private meeting so it is possible that other will drift in. We will = not throw > them out! >=20 > Thanks for the discussions on the various lists so far and please stay = engaged. >=20 > Adrian and Alia >=20 From nobody Mon Jul 21 08:54:23 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D7E1A02DE; Mon, 21 Jul 2014 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziHgVdN6JBwA; Mon, 21 Jul 2014 08:54:16 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6C31A0270; Mon, 21 Jul 2014 08:54:14 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 131so4084698ykp.14 for ; Mon, 21 Jul 2014 08:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TXGId2iOXQ5YWND1eHD+W/0/UNmXxIfTYXSz1g8qgOI=; b=Ri6q2CcOozJev4zN3VoafdcQvVKrtsJfvkxfu3uktrg9snbZytJWIEfR61a+P7cYOT hltJTePlzagqtDV+QTb2YKveFGUwqeUVy4qiMcs92KE/8j8Aw1GI+tqNCiwKFye0qZIs PfI73mJH0Q8K1/f1G4LNcVMQ1e/cReFjWiKmBpvGYIlu8bXEn1HtfbVRjcUo4M3LQLku u5AlyXdwF2c5oZn8N0iEs7SGUYCu9nM2vzjB5w3UQcX7KSogzhqoEtDWN0109HxSxlMV kPd3APeDyp7SsRfgQJ1/ToUNXuxl87ceWRqsilyiKc0MXk3Frvt/J3uG53MDfW4bBqKk UG3w== MIME-Version: 1.0 X-Received: by 10.236.103.135 with SMTP id f7mr41947833yhg.102.1405958054257; Mon, 21 Jul 2014 08:54:14 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Mon, 21 Jul 2014 08:54:13 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Mon, 21 Jul 2014 08:54:13 -0700 (PDT) In-Reply-To: References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> Date: Mon, 21 Jul 2014 11:54:13 -0400 Message-ID: From: Alia Atlas To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a11332a2e64ad8204feb61e44 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/tQZZoayFQrwEPACV_KfF8lhSeic Cc: Adrian Farrel , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:54:18 -0000 --001a11332a2e64ad8204feb61e44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The meeting is on Tuesday from 12pm to 2pm in the Quebec room. Thanks for the reminder to send it the room info. Alia On Jul 21, 2014 11:03 AM, "Thomas Heide Clausen" wrote: > Hey A^2, > > I may have missed it, but was there a room announced for this event =E2= =80=94 or, > is the recommended to stalk either of you after the morning sessions, and > see where that takes us? > > Cheers, > > Thomas > > > On 24 Jun 2014, at 22:14 , Adrian Farrel wrote: > > > > Chairs and Directorate, > > > > Alia and I have blocked out a slot in Toronto for you to come and > discuss Area > > reorganisation with us. > > > > We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG WG > meetings, > > so we suggest "grab lunch and come along". Room to be announced. > > > > The meeting will not be announced wider than this grouping, but will no= t > be a > > private meeting so it is possible that other will drift in. We will not > throw > > them out! > > > > Thanks for the discussions on the various lists so far and please stay > engaged. > > > > Adrian and Alia > > > > --001a11332a2e64ad8204feb61e44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The meeting is on Tuesday from 12pm to 2pm in the Quebec roo= m.

Thanks for the reminder to send it the room info.

Alia

On Jul 21, 2014 11:03 AM, "Thomas Heide Cla= usen" <thomas@thomascla= usen.org> wrote:
Hey A^2,

I may have missed it, but was there a room announced for this event =E2=80= =94 or, is the recommended to stalk either of you after the morning session= s, and see where that takes us?

Cheers,

Thomas

> On 24 Jun 2014, at 22:14 , Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> Chairs and Directorate,
>
> Alia and I have blocked out a slot in Toronto for you to come and disc= uss Area
> reorganisation with us.
>
> We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG= WG meetings,
> so we suggest "grab lunch and come along". Room to be announ= ced.
>
> The meeting will not be announced wider than this grouping, but will n= ot be a
> private meeting so it is possible that other will drift in. We will no= t throw
> them out!
>
> Thanks for the discussions on the various lists so far and please stay= engaged.
>
> Adrian and Alia
>

--001a11332a2e64ad8204feb61e44-- From nobody Mon Jul 21 08:57:38 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F771A02F7; Mon, 21 Jul 2014 08:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6eoiWUbW5-3; Mon, 21 Jul 2014 08:57:28 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B7A1A0270; Mon, 21 Jul 2014 08:57:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 64DCB121C4B; Mon, 21 Jul 2014 08:57:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [107.18.111.72] (69-165-189-130.dsl.teksavvy.com [69.165.189.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 9B661121BA8; Mon, 21 Jul 2014 08:57:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A9A6BBA4-92BF-4338-AFBD-F709592B57C9" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1962.2\)) From: Thomas Heide Clausen In-Reply-To: Date: Mon, 21 Jul 2014 17:57:19 +0200 Message-Id: References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> To: Alia Atlas X-Mailer: Apple Mail (2.1962.2) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/2QImMPgI86y6jAFZ2z7ejyTE9Nc Cc: Adrian Farrel , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:57:30 -0000 --Apple-Mail=_A9A6BBA4-92BF-4338-AFBD-F709592B57C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Awesome, Alia, thanks a ton. See all y'all tomorrow, then. Thomas > On 21 Jul 2014, at 17:54 , Alia Atlas wrote: >=20 > The meeting is on Tuesday from 12pm to 2pm in the Quebec room. >=20 > Thanks for the reminder to send it the room info. >=20 > Alia >=20 > On Jul 21, 2014 11:03 AM, "Thomas Heide Clausen" = wrote: > Hey A^2, >=20 > I may have missed it, but was there a room announced for this event = =E2=80=94 or, is the recommended to stalk either of you after the = morning sessions, and see where that takes us? >=20 > Cheers, >=20 > Thomas >=20 > > On 24 Jun 2014, at 22:14 , Adrian Farrel = wrote: > > > > Chairs and Directorate, > > > > Alia and I have blocked out a slot in Toronto for you to come and = discuss Area > > reorganisation with us. > > > > We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG = WG meetings, > > so we suggest "grab lunch and come along". Room to be announced. > > > > The meeting will not be announced wider than this grouping, but will = not be a > > private meeting so it is possible that other will drift in. We will = not throw > > them out! > > > > Thanks for the discussions on the various lists so far and please = stay engaged. > > > > Adrian and Alia > > >=20 --Apple-Mail=_A9A6BBA4-92BF-4338-AFBD-F709592B57C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Awesome, Alia, thanks a ton. See all y'all tomorrow, = then.

Thomas

On 21 Jul 2014, at 17:54 , Alia Atlas <akatlas@gmail.com> = wrote:

The meeting is on Tuesday from 12pm to 2pm in the Quebec = room.

Thanks for the reminder to send it the room = info.

Alia

On Jul 21, 2014 11:03 AM, "Thomas Heide = Clausen" <thomas@thomasclausen.org> = wrote:
Hey A^2,

I may have missed it, but was there a room announced for this event =E2=80= =94 or, is the recommended to stalk either of you after the morning = sessions, and see where that takes us?

Cheers,

Thomas

> On 24 Jun 2014, at 22:14 , Adrian Farrel <adrian@olddog.co.uk> = wrote:
>
> Chairs and Directorate,
>
> Alia and I have blocked out a slot in Toronto for you to come and = discuss Area
> reorganisation with us.
>
> We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG = WG meetings,
> so we suggest "grab lunch and come along". Room to be = announced.
>
> The meeting will not be announced wider than this grouping, but = will not be a
> private meeting so it is possible that other will drift in. We will = not throw
> them out!
>
> Thanks for the discussions on the various lists so far and please = stay engaged.
>
> Adrian and Alia
>


= --Apple-Mail=_A9A6BBA4-92BF-4338-AFBD-F709592B57C9-- From nobody Tue Jul 22 03:02:48 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D961A0AB0; Tue, 22 Jul 2014 03:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9HIU6BxwSjr; Tue, 22 Jul 2014 03:02:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D551A032A; Tue, 22 Jul 2014 03:02:40 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 10:02:37 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0990.007; Tue, 22 Jul 2014 10:02:37 +0000 From: Alexander Vainshtein To: Thomas Heide Clausen , Alia Atlas Thread-Topic: [RTG-DIR] Consultative Session on RTG Reorg in Toronto Thread-Index: AQHPpZQQS5sHzN6ifEu+KGg5a693sg== Date: Tue, 22 Jul 2014 10:02:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.35.50.33] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(24454002)(377454003)(51914003)(479174003)(80022001)(50986999)(54356999)(99396002)(19580405001)(95666004)(74316001)(76482001)(107046002)(83322001)(106356001)(101416001)(74662001)(46102001)(105586002)(74502001)(77982001)(33646002)(66066001)(87936001)(31966008)(19580395003)(64706001)(86362001)(106116001)(76576001)(16236675004)(4396001)(81342001)(85852003)(20776003)(92566001)(83072002)(85306003)(81542001)(21056001)(79102001)(2656002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; LANG:en; Content-Type: multipart/alternative; boundary="_000_d9cb3b39e72d48eea013b6e4193f06dcAM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/auoF9oJ5AEgDkAmelv0-an3w2ac Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 10:02:46 -0000 --_000_d9cb3b39e72d48eea013b6e4193f06dcAM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSwgQWRyaWFuLA0KDQpJcyB0aGVyZSBhbnkgd2F5IHRvIGNvbm5lY3QgcmVtb3RlbHk/DQoN Cg0KDQpUaHVtYiB0eXBlZCBvbiBteSBMRywNClNhc2hhDQoNCi0tLS0tLSBPcmlnaW5hbCBtZXNz YWdlIC0tLS0tLQ0KRnJvbTogVGhvbWFzIEhlaWRlIENsYXVzZW4NCkRhdGU6IDIxLzA3LzIwMTQg MTg6NTcNClRvOiBBbGlhIEF0bGFzOw0KQ2M6IEFkcmlhbiBGYXJyZWw7cnRnLWRpckBpZXRmLm9y ZztydGctY2hhaXJzQGlldGYub3JnOw0KU3ViamVjdDpSZTogW1JURy1ESVJdIENvbnN1bHRhdGl2 ZSBTZXNzaW9uIG9uIFJURyBSZW9yZyBpbiBUb3JvbnRvDQoNCkF3ZXNvbWUsIEFsaWEsIHRoYW5r cyBhIHRvbi4gU2VlIGFsbCB5J2FsbCB0b21vcnJvdywgdGhlbi4NCg0KVGhvbWFzDQoNCk9uIDIx IEp1bCAyMDE0LCBhdCAxNzo1NCAsIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0 bzpha2F0bGFzQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNClRoZSBtZWV0aW5nIGlzIG9uIFR1ZXNk YXkgZnJvbSAxMnBtIHRvIDJwbSBpbiB0aGUgUXVlYmVjIHJvb20uDQoNClRoYW5rcyBmb3IgdGhl IHJlbWluZGVyIHRvIHNlbmQgaXQgdGhlIHJvb20gaW5mby4NCg0KQWxpYQ0KDQpPbiBKdWwgMjEs IDIwMTQgMTE6MDMgQU0sICJUaG9tYXMgSGVpZGUgQ2xhdXNlbiIgPHRob21hc0B0aG9tYXNjbGF1 c2VuLm9yZzxtYWlsdG86dGhvbWFzQHRob21hc2NsYXVzZW4ub3JnPj4gd3JvdGU6DQpIZXkgQV4y LA0KDQpJIG1heSBoYXZlIG1pc3NlZCBpdCwgYnV0IHdhcyB0aGVyZSBhIHJvb20gYW5ub3VuY2Vk IGZvciB0aGlzIGV2ZW50IOKAlCBvciwgaXMgdGhlIHJlY29tbWVuZGVkIHRvIHN0YWxrIGVpdGhl ciBvZiB5b3UgYWZ0ZXIgdGhlIG1vcm5pbmcgc2Vzc2lvbnMsIGFuZCBzZWUgd2hlcmUgdGhhdCB0 YWtlcyB1cz8NCg0KQ2hlZXJzLA0KDQpUaG9tYXMNCg0KPiBPbiAyNCBKdW4gMjAxNCwgYXQgMjI6 MTQgLCBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xk ZG9nLmNvLnVrPj4gd3JvdGU6DQo+DQo+IENoYWlycyBhbmQgRGlyZWN0b3JhdGUsDQo+DQo+IEFs aWEgYW5kIEkgaGF2ZSBibG9ja2VkIG91dCBhIHNsb3QgaW4gVG9yb250byBmb3IgeW91IHRvIGNv bWUgYW5kIGRpc2N1c3MgQXJlYQ0KPiByZW9yZ2FuaXNhdGlvbiB3aXRoIHVzLg0KPg0KPiBXZSBo YXZlIGZvdW5kIFR1ZXNkYXkgMTIuMDAgdG8gMTQuMDAgZG9lc24ndCBjb25mbGljdCB3aXRoIGFu eSBSVEcgV0cgbWVldGluZ3MsDQo+IHNvIHdlIHN1Z2dlc3QgImdyYWIgbHVuY2ggYW5kIGNvbWUg YWxvbmciLiBSb29tIHRvIGJlIGFubm91bmNlZC4NCj4NCj4gVGhlIG1lZXRpbmcgd2lsbCBub3Qg YmUgYW5ub3VuY2VkIHdpZGVyIHRoYW4gdGhpcyBncm91cGluZywgYnV0IHdpbGwgbm90IGJlIGEN Cj4gcHJpdmF0ZSBtZWV0aW5nIHNvIGl0IGlzIHBvc3NpYmxlIHRoYXQgb3RoZXIgd2lsbCBkcmlm dCBpbi4gV2Ugd2lsbCBub3QgdGhyb3cNCj4gdGhlbSBvdXQhDQo+DQo+IFRoYW5rcyBmb3IgdGhl IGRpc2N1c3Npb25zIG9uIHRoZSB2YXJpb3VzIGxpc3RzIHNvIGZhciBhbmQgcGxlYXNlIHN0YXkg ZW5nYWdlZC4NCj4NCj4gQWRyaWFuIGFuZCBBbGlhDQo+DQoNCg0K --_000_d9cb3b39e72d48eea013b6e4193f06dcAM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-ID: <2EF1C869E9BBA94DB7875C63E5EC995F@ECI365.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4NCjxwIHN0eWxl PSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+QWxpYSwgQWRyaWFuLDwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+SXMgdGhlcmUgYW55IHdheSB0byBj b25uZWN0IHJlbW90ZWx5PzwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRv bTowOyI+Jm5ic3A7PC9wPg0KPGRldjNfamp5PlRodW1iIHR5cGVkIG9uIG15IExHLDxicj4NClNh c2hhPC9kZXYzX2pqeT48YnI+DQo8YnI+DQotLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS08 YnI+DQo8Yj5Gcm9tOiZuYnNwOzwvYj5UaG9tYXMgSGVpZGUgQ2xhdXNlbjx0aG9tYXNAdGhvbWFz Y2xhdXNlbi5vcmc+PGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+MjEvMDcvMjAxNCAxODo1Nzxicj4N CjxiPlRvOiZuYnNwOzwvYj5BbGlhIEF0bGFzOzxicj4NCjxiPkNjOiZuYnNwOzwvYj5BZHJpYW4g RmFycmVsO3J0Zy1kaXJAaWV0Zi5vcmc7cnRnLWNoYWlyc0BpZXRmLm9yZzs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj5SZTogW1JURy1ESVJdIENvbnN1bHRhdGl2ZSBTZXNzaW9uIG9uIFJURyBSZW9yZyBp biBUb3JvbnRvPGJyPg0KPGJyPg0KQXdlc29tZSwgQWxpYSwgdGhhbmtzIGEgdG9uLiBTZWUgYWxs IHknYWxsIHRvbW9ycm93LCB0aGVuLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhvbWFzPC9k aXY+DQo8ZGl2Pjxicj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+T24g MjEgSnVsIDIwMTQsIGF0IDE3OjU0ICwgQWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFr YXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXY+DQo8cCBkaXI9Imx0 ciI+VGhlIG1lZXRpbmcgaXMgb24gVHVlc2RheSBmcm9tIDEycG0gdG8gMnBtIGluIHRoZSBRdWVi ZWMgcm9vbS48L3A+DQo8cCBkaXI9Imx0ciI+VGhhbmtzIGZvciB0aGUgcmVtaW5kZXIgdG8gc2Vu ZCBpdCB0aGUgcm9vbSBpbmZvLjwvcD4NCjxwIGRpcj0ibHRyIj5BbGlhPC9wPg0KPGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPk9uIEp1bCAyMSwgMjAxNCAxMTowMyBBTSwgJnF1b3Q7VGhvbWFzIEhl aWRlIENsYXVzZW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNl bi5vcmciPnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciB0eXBlPSJh dHRyaWJ1dGlvbiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7IHBhZGRpbmctbGVmdDox ZXgiPg0KSGV5IEFeMiw8YnI+DQo8YnI+DQpJIG1heSBoYXZlIG1pc3NlZCBpdCwgYnV0IHdhcyB0 aGVyZSBhIHJvb20gYW5ub3VuY2VkIGZvciB0aGlzIGV2ZW50IOKAlCBvciwgaXMgdGhlIHJlY29t bWVuZGVkIHRvIHN0YWxrIGVpdGhlciBvZiB5b3UgYWZ0ZXIgdGhlIG1vcm5pbmcgc2Vzc2lvbnMs IGFuZCBzZWUgd2hlcmUgdGhhdCB0YWtlcyB1cz88YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJy Pg0KVGhvbWFzPGJyPg0KPGJyPg0KJmd0OyBPbiAyNCBKdW4gMjAxNCwgYXQgMjI6MTQgLCBBZHJp YW4gRmFycmVsICZsdDs8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFu QG9sZGRvZy5jby51azwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IENoYWlycyBh bmQgRGlyZWN0b3JhdGUsPGJyPg0KJmd0Ozxicj4NCiZndDsgQWxpYSBhbmQgSSBoYXZlIGJsb2Nr ZWQgb3V0IGEgc2xvdCBpbiBUb3JvbnRvIGZvciB5b3UgdG8gY29tZSBhbmQgZGlzY3VzcyBBcmVh PGJyPg0KJmd0OyByZW9yZ2FuaXNhdGlvbiB3aXRoIHVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdl IGhhdmUgZm91bmQgVHVlc2RheSAxMi4wMCB0byAxNC4wMCBkb2Vzbid0IGNvbmZsaWN0IHdpdGgg YW55IFJURyBXRyBtZWV0aW5ncyw8YnI+DQomZ3Q7IHNvIHdlIHN1Z2dlc3QgJnF1b3Q7Z3JhYiBs dW5jaCBhbmQgY29tZSBhbG9uZyZxdW90Oy4gUm9vbSB0byBiZSBhbm5vdW5jZWQuPGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhlIG1lZXRpbmcgd2lsbCBub3QgYmUgYW5ub3VuY2VkIHdpZGVyIHRoYW4g dGhpcyBncm91cGluZywgYnV0IHdpbGwgbm90IGJlIGE8YnI+DQomZ3Q7IHByaXZhdGUgbWVldGlu ZyBzbyBpdCBpcyBwb3NzaWJsZSB0aGF0IG90aGVyIHdpbGwgZHJpZnQgaW4uIFdlIHdpbGwgbm90 IHRocm93PGJyPg0KJmd0OyB0aGVtIG91dCE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgZm9y IHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgdmFyaW91cyBsaXN0cyBzbyBmYXIgYW5kIHBsZWFzZSBz dGF5IGVuZ2FnZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWRyaWFuIGFuZCBBbGlhPGJyPg0KJmd0 Ozxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d9cb3b39e72d48eea013b6e4193f06dcAM3PR03MB612eurprd03pro_-- From nobody Tue Jul 22 05:52:42 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785A61A0B10; Tue, 22 Jul 2014 05:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjGgZBLnoefx; Tue, 22 Jul 2014 05:52:37 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F931A0B03; Tue, 22 Jul 2014 05:52:36 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so9016701wes.36 for ; Tue, 22 Jul 2014 05:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FqgfYnfMm5fEmknUHiipbOd/dlqEzf4M+8M7cNtN06M=; b=I/yiYLvrLspQOk49F7A0tflw9QeoKShnvxorA/kg0Hd1NpqJ+6fgNANfOUWB3ZUv82 Kdc61Xn+mYQluM1G0u0WO/GLImmztXjj2Fohkrz7gBHbH7vSoY186w2WZMyELuhUOskD FNU7d+sauFm5ZmnsJKixvF/Bm9+61xPFXb3/E3TxCcFn/2Tl6F1hD363o/jDio21ell/ b5MvEIn1/jFWhwe6rOFXMR1SQK5PygyQ+Qptwo5N92FyGF2oL4JwZTgxfRHVM5qrXnZq rOgpPe3G5pokGAymJvvWimT3knlUmirSsGGbdm2RCUozXH68o7Gc7KcUWtuU+ACqltZL iY3g== MIME-Version: 1.0 X-Received: by 10.194.58.199 with SMTP id t7mr34454832wjq.14.1406033553686; Tue, 22 Jul 2014 05:52:33 -0700 (PDT) Received: by 10.216.194.138 with HTTP; Tue, 22 Jul 2014 05:52:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 08:52:33 -0400 Message-ID: From: Alia Atlas To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=047d7bacc66482905704fec7b2b8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/WNvIj5YVTfbmAnGWhTc1jLOgkOk Cc: Adrian Farrel , Thomas Heide Clausen , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 12:52:40 -0000 --047d7bacc66482905704fec7b2b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sasha, No - sorry - but what we really want to hear are your opinions on the reorganization. Please just email them. Thanks, Alia On Tue, Jul 22, 2014 at 6:02 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Alia, Adrian, > > Is there any way to connect remotely? > > > Thumb typed on my LG, > Sasha > > > ------ Original message ------ > *From: *Thomas Heide Clausen > *Date: *21/07/2014 18:57 > *To: *Alia Atlas; > *Cc: *Adrian Farrel;rtg-dir@ietf.org;rtg-chairs@ietf.org; > *Subject:*Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto > > Awesome, Alia, thanks a ton. See all y'all tomorrow, then. > > Thomas > > On 21 Jul 2014, at 17:54 , Alia Atlas wrote: > > The meeting is on Tuesday from 12pm to 2pm in the Quebec room. > > Thanks for the reminder to send it the room info. > > Alia > On Jul 21, 2014 11:03 AM, "Thomas Heide Clausen" > wrote: > >> Hey A^2, >> >> I may have missed it, but was there a room announced for this event =E2= =80=94 or, >> is the recommended to stalk either of you after the morning sessions, an= d >> see where that takes us? >> >> Cheers, >> >> Thomas >> >> > On 24 Jun 2014, at 22:14 , Adrian Farrel wrote: >> > >> > Chairs and Directorate, >> > >> > Alia and I have blocked out a slot in Toronto for you to come and >> discuss Area >> > reorganisation with us. >> > >> > We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG WG >> meetings, >> > so we suggest "grab lunch and come along". Room to be announced. >> > >> > The meeting will not be announced wider than this grouping, but will >> not be a >> > private meeting so it is possible that other will drift in. We will no= t >> throw >> > them out! >> > >> > Thanks for the discussions on the various lists so far and please stay >> engaged. >> > >> > Adrian and Alia >> > >> >> > --047d7bacc66482905704fec7b2b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sasha,

No - sorry - but what we really = want to hear are your opinions on the reorganization. =C2=A0Please
just email them.

Thanks,
Alia


On Tue, Jul 22, 2014 at 6:02 AM, Alexand= er Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Alia, Adrian,

Is there any way to connect remot= ely?

=C2=A0

Thumb typed on my LG,
Sasha


------ Original message ------
From:=C2=A0Thomas Heide Clausen
Date:=C2=A021/07/2014 18:57
To:=C2=A0Alia Atlas;
Cc:=C2=A0Adrian Farrel;rtg-dir@ietf.org;rtg-chairs@ietf.org;
Subject:Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto
Awesome, Alia, thanks a ton. See all y'all tomorrow, then.

Thomas

On 21 Jul 2014, at 17:54 , Alia Atlas <akatlas@gmail.com> wrote:

The meeting is on Tuesday from 12pm to 2pm in the Quebec roo= m.

Thanks for the reminder to send it the room info.

Alia

On Jul 21, 2014 11:03 AM, "Thomas Heide Cla= usen" <thomas@thomasclausen.org> wrote:
Hey A^2,

I may have missed it, but was there a room announced for this event =E2=80= =94 or, is the recommended to stalk either of you after the morning session= s, and see where that takes us?

Cheers,

Thomas

> On 24 Jun 2014, at 22:14 , Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> Chairs and Directorate,
>
> Alia and I have blocked out a slot in Toronto for you to come and disc= uss Area
> reorganisation with us.
>
> We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG= WG meetings,
> so we suggest "grab lunch and come along". Room to be announ= ced.
>
> The meeting will not be announced wider than this grouping, but will n= ot be a
> private meeting so it is possible that other will drift in. We will no= t throw
> them out!
>
> Thanks for the discussions on the various lists so far and please stay= engaged.
>
> Adrian and Alia
>

--047d7bacc66482905704fec7b2b8-- From nobody Tue Jul 22 05:54:46 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E5A1A0B03; Tue, 22 Jul 2014 05:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrtLHqNZ4TUw; Tue, 22 Jul 2014 05:54:43 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F1F1A0B12; Tue, 22 Jul 2014 05:54:41 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so5944398wiw.6 for ; Tue, 22 Jul 2014 05:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uBzf/StEiRjxnA4AOmH8aNQWTlWy6hCn0gGepP5RL0k=; b=kVJnSeCFnKfMUZqa3PKhi7F5uhRhHcBzvDTQNgTQxu6CRSlwMIFATKS0iJzarMmN/M Pl4F84c2jmqCO2PWkHlmob5UOoNby46NnhpzFLAqFcTPNnec8xkcSpnV2P3LZvx3ee11 bEr/2WkVmUbuyVbJE5Qjz1TYMRYvwL9sanpqa/aeiTbmAD8H3Pd9fDayRTaoiMDewz0m LnZKMN9QkLXgu+jKQSPD0GqUd0TFLDaTmw2vEfv2ONrmD/k0YTrNoegO95iwBsLU4qVj M7RfJXFvkD/CRc6hQMEkIa5PlrpaGxvO4kruzXJBsDYoHv7KjEN4/Ek7/VeMj1pZrB/J 5suQ== MIME-Version: 1.0 X-Received: by 10.194.58.199 with SMTP id t7mr34473268wjq.14.1406033680091; Tue, 22 Jul 2014 05:54:40 -0700 (PDT) Received: by 10.216.194.138 with HTTP; Tue, 22 Jul 2014 05:54:40 -0700 (PDT) In-Reply-To: References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> Date: Tue, 22 Jul 2014 08:54:40 -0400 Message-ID: From: Alia Atlas To: Thomas Clausen Content-Type: multipart/alternative; boundary=047d7bacc6640b52f104fec7ba3b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/zRX3NnfU4i2hB_BK_Yg3cShSado Cc: Adrian Farrel , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 12:54:44 -0000 --047d7bacc6640b52f104fec7ba3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Because the question has come up a couple times, this meeting is a "bring your own lunch". See you at noon in the Quebec room. Alia On Mon, Jul 21, 2014 at 11:54 AM, Alia Atlas wrote: > The meeting is on Tuesday from 12pm to 2pm in the Quebec room. > > Thanks for the reminder to send it the room info. > > Alia > On Jul 21, 2014 11:03 AM, "Thomas Heide Clausen" > wrote: > >> Hey A^2, >> >> I may have missed it, but was there a room announced for this event =E2= =80=94 or, >> is the recommended to stalk either of you after the morning sessions, an= d >> see where that takes us? >> >> Cheers, >> >> Thomas >> >> > On 24 Jun 2014, at 22:14 , Adrian Farrel wrote: >> > >> > Chairs and Directorate, >> > >> > Alia and I have blocked out a slot in Toronto for you to come and >> discuss Area >> > reorganisation with us. >> > >> > We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG WG >> meetings, >> > so we suggest "grab lunch and come along". Room to be announced. >> > >> > The meeting will not be announced wider than this grouping, but will >> not be a >> > private meeting so it is possible that other will drift in. We will no= t >> throw >> > them out! >> > >> > Thanks for the discussions on the various lists so far and please stay >> engaged. >> > >> > Adrian and Alia >> > >> >> --047d7bacc6640b52f104fec7ba3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Because the question has come up a couple times, this meet= ing is a "bring your own lunch".

See you at no= on in the Quebec room.

Alia


On Mon, Jul 21, 2014 at 11:54 AM, Alia A= tlas <akatlas@gmail.com> wrote:

The meeting is on Tuesday from 12pm to 2pm in the Quebec roo= m.

Thanks for the reminder to send it the room info.

Alia

On Jul 21, 2014 11:03 AM, "Thomas Heide Cla= usen" <thomas@thomasclausen.org> wrote:
Hey A^2,

I may have missed it, but was there a room announced for this event =E2=80= =94 or, is the recommended to stalk either of you after the morning session= s, and see where that takes us?

Cheers,

Thomas

> On 24 Jun 2014, at 22:14 , Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> Chairs and Directorate,
>
> Alia and I have blocked out a slot in Toronto for you to come and disc= uss Area
> reorganisation with us.
>
> We have found Tuesday 12.00 to 14.00 doesn't conflict with any RTG= WG meetings,
> so we suggest "grab lunch and come along". Room to be announ= ced.
>
> The meeting will not be announced wider than this grouping, but will n= ot be a
> private meeting so it is possible that other will drift in. We will no= t throw
> them out!
>
> Thanks for the discussions on the various lists so far and please stay= engaged.
>
> Adrian and Alia
>


--047d7bacc6640b52f104fec7ba3b-- From nobody Tue Jul 22 05:55:23 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B1B1A0652; Tue, 22 Jul 2014 05:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoqoGUO0Ckqh; Tue, 22 Jul 2014 05:55:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675691A8BB0; Tue, 22 Jul 2014 05:55:11 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 12:55:08 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0990.007; Tue, 22 Jul 2014 12:55:08 +0000 From: Alexander Vainshtein To: Alia Atlas Thread-Topic: [RTG-DIR] Consultative Session on RTG Reorg in Toronto Thread-Index: AQHPpZQQS5sHzN6ifEu+KGg5a693spusDHOAgAAAGgA= Date: Tue, 22 Jul 2014 12:55:08 +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.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(252514010)(199002)(189002)(51704005)(24454002)(377454003)(51914003)(164054003)(479174003)(54356999)(99396002)(19580405001)(95666004)(50986999)(19300405004)(19625215002)(74316001)(76482001)(107046002)(80022001)(83322001)(106356001)(105586002)(101416001)(74662001)(46102001)(15202345003)(15975445006)(74502001)(110136001)(77982001)(33646002)(66066001)(76176999)(87936001)(31966008)(19580395003)(64706001)(106116001)(86362001)(76576001)(4396001)(16236675004)(81342001)(21056001)(20776003)(85852003)(92566001)(83072002)(19609705001)(85306003)(81542001)(2656002)(79102001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a4f139987eaf4a2da05136447d942b9cAM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/P00f6p0XT2mDjk3ea3PJ2Gy-VPo Cc: Adrian Farrel , Thomas Heide Clausen , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 12:55:21 -0000 --_000_a4f139987eaf4a2da05136447d942b9cAM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSwNCkxvdHMgb2YgdGhhbmtzIGZvciBhIHByb21wdCAoZXZlbiBpZiBhIGJpdCBkaXNjb3Vy YWdpbmcpIHJlc3BvbnNlLiBJdCBpcyBtdWNoIGVhc2llciB0byBwcm92aWRlIGEgZmVlZGJhY2sg aW4gYSBsaXZlIGRpc2N1c3Npb24uDQoNCk5ldmVydGhlbGVzcyBJIHdpbGwgdHJ5IHRvIHN1bW1h cml6ZSBteSB0aG91Z2h0cyBpbnRvIHNvbWV0aGluZyBjb2hlcmVudCBhbmQgc2VuZCB0aGVtIHRv IHRoZSBncm91cC4gTWF5IHRha2Ugc29tZSB0aW1lLCB0aG91Z2jigKYNCg0KUmVnYXJkcywNCiAg ICAgICBTYXNoYQ0KRW1haWw6IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQpNb2Jp bGU6IDA1NC05MjY2MzAyDQoNCkZyb206IEFsaWEgQXRsYXMgW21haWx0bzpha2F0bGFzQGdtYWls LmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIwMTQgMzo1MyBQTQ0KVG86IEFsZXhhbmRl ciBWYWluc2h0ZWluDQpDYzogVGhvbWFzIEhlaWRlIENsYXVzZW47IEFkcmlhbiBGYXJyZWw7IHJ0 Zy1kaXJAaWV0Zi5vcmc7IHJ0Zy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUlRHLURJ Ul0gQ29uc3VsdGF0aXZlIFNlc3Npb24gb24gUlRHIFJlb3JnIGluIFRvcm9udG8NCg0KU2FzaGEs DQoNCk5vIC0gc29ycnkgLSBidXQgd2hhdCB3ZSByZWFsbHkgd2FudCB0byBoZWFyIGFyZSB5b3Vy IG9waW5pb25zIG9uIHRoZSByZW9yZ2FuaXphdGlvbi4gIFBsZWFzZQ0KanVzdCBlbWFpbCB0aGVt Lg0KDQpUaGFua3MsDQpBbGlhDQoNCk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDY6MDIgQU0sIEFs ZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWls dG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+PiB3cm90ZToNCg0KQWxpYSwgQWRy aWFuLA0KDQpJcyB0aGVyZSBhbnkgd2F5IHRvIGNvbm5lY3QgcmVtb3RlbHk/DQoNCg0KVGh1bWIg dHlwZWQgb24gbXkgTEcsDQpTYXNoYQ0KDQoNCi0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LQ0KRnJvbTogVGhvbWFzIEhlaWRlIENsYXVzZW4NCkRhdGU6IDIxLzA3LzIwMTQgMTg6NTcNClRv OiBBbGlhIEF0bGFzOw0KQ2M6IEFkcmlhbiBGYXJyZWw7cnRnLWRpckBpZXRmLm9yZzxtYWlsdG86 RmFycmVsJTNCcnRnLWRpckBpZXRmLm9yZz47cnRnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86cnRn LWNoYWlyc0BpZXRmLm9yZz47DQpTdWJqZWN0OlJlOiBbUlRHLURJUl0gQ29uc3VsdGF0aXZlIFNl c3Npb24gb24gUlRHIFJlb3JnIGluIFRvcm9udG8NCkF3ZXNvbWUsIEFsaWEsIHRoYW5rcyBhIHRv bi4gU2VlIGFsbCB5J2FsbCB0b21vcnJvdywgdGhlbi4NCg0KVGhvbWFzDQoNCk9uIDIxIEp1bCAy MDE0LCBhdCAxNzo1NCAsIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0 bGFzQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNClRoZSBtZWV0aW5nIGlzIG9uIFR1ZXNkYXkgZnJv bSAxMnBtIHRvIDJwbSBpbiB0aGUgUXVlYmVjIHJvb20uDQoNClRoYW5rcyBmb3IgdGhlIHJlbWlu ZGVyIHRvIHNlbmQgaXQgdGhlIHJvb20gaW5mby4NCg0KQWxpYQ0KT24gSnVsIDIxLCAyMDE0IDEx OjAzIEFNLCAiVGhvbWFzIEhlaWRlIENsYXVzZW4iIDx0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmc8 bWFpbHRvOnRob21hc0B0aG9tYXNjbGF1c2VuLm9yZz4+IHdyb3RlOg0KSGV5IEFeMiwNCg0KSSBt YXkgaGF2ZSBtaXNzZWQgaXQsIGJ1dCB3YXMgdGhlcmUgYSByb29tIGFubm91bmNlZCBmb3IgdGhp cyBldmVudCDigJQgb3IsIGlzIHRoZSByZWNvbW1lbmRlZCB0byBzdGFsayBlaXRoZXIgb2YgeW91 IGFmdGVyIHRoZSBtb3JuaW5nIHNlc3Npb25zLCBhbmQgc2VlIHdoZXJlIHRoYXQgdGFrZXMgdXM/ DQoNCkNoZWVycywNCg0KVGhvbWFzDQoNCj4gT24gMjQgSnVuIDIwMTQsIGF0IDIyOjE0ICwgQWRy aWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51 az4+IHdyb3RlOg0KPg0KPiBDaGFpcnMgYW5kIERpcmVjdG9yYXRlLA0KPg0KPiBBbGlhIGFuZCBJ IGhhdmUgYmxvY2tlZCBvdXQgYSBzbG90IGluIFRvcm9udG8gZm9yIHlvdSB0byBjb21lIGFuZCBk aXNjdXNzIEFyZWENCj4gcmVvcmdhbmlzYXRpb24gd2l0aCB1cy4NCj4NCj4gV2UgaGF2ZSBmb3Vu ZCBUdWVzZGF5IDEyLjAwIHRvIDE0LjAwIGRvZXNuJ3QgY29uZmxpY3Qgd2l0aCBhbnkgUlRHIFdH IG1lZXRpbmdzLA0KPiBzbyB3ZSBzdWdnZXN0ICJncmFiIGx1bmNoIGFuZCBjb21lIGFsb25nIi4g Um9vbSB0byBiZSBhbm5vdW5jZWQuDQo+DQo+IFRoZSBtZWV0aW5nIHdpbGwgbm90IGJlIGFubm91 bmNlZCB3aWRlciB0aGFuIHRoaXMgZ3JvdXBpbmcsIGJ1dCB3aWxsIG5vdCBiZSBhDQo+IHByaXZh dGUgbWVldGluZyBzbyBpdCBpcyBwb3NzaWJsZSB0aGF0IG90aGVyIHdpbGwgZHJpZnQgaW4uIFdl IHdpbGwgbm90IHRocm93DQo+IHRoZW0gb3V0IQ0KPg0KPiBUaGFua3MgZm9yIHRoZSBkaXNjdXNz aW9ucyBvbiB0aGUgdmFyaW91cyBsaXN0cyBzbyBmYXIgYW5kIHBsZWFzZSBzdGF5IGVuZ2FnZWQu DQo+DQo+IEFkcmlhbiBhbmQgQWxpYQ0KPg0KDQoNCg== --_000_a4f139987eaf4a2da05136447d942b9cAM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkFoYXJvbmk7DQoJcGFub3NlLTE6MiAxIDggMyAyIDEg NCAzIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6IzFGNDk3RDsNCgl0ZXh0 LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwt YWxpZ246YmFzZWxpbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxpYSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IChldmVuIGlmIGEg Yml0IGRpc2NvdXJhZ2luZykgcmVzcG9uc2UuIEl0IGlzIG11Y2ggZWFzaWVyIHRvIHByb3ZpZGUg YSBmZWVkYmFjayBpbiBhIGxpdmUgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5ldmVydGhlbGVzcyBJ IHdpbGwgdHJ5IHRvIHN1bW1hcml6ZSBteSB0aG91Z2h0cyBpbnRvIHNvbWV0aGluZyBjb2hlcmVu dCBhbmQgc2VuZCB0aGVtIHRvIHRoZSBncm91cC4gTWF5IHRha2Ugc29tZSB0aW1lLCB0aG91Z2ji gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNoYQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Nb2JpbGU6IDA1NC05MjY2MzAyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsaWEgQXRsYXMgW21haWx0bzpha2F0 bGFzQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0 IDM6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEFsZXhhbmRlciBWYWluc2h0ZWluPGJyPg0KPGI+Q2M6 PC9iPiBUaG9tYXMgSGVpZGUgQ2xhdXNlbjsgQWRyaWFuIEZhcnJlbDsgcnRnLWRpckBpZXRmLm9y ZzsgcnRnLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JURy1ESVJd IENvbnN1bHRhdGl2ZSBTZXNzaW9uIG9uIFJURyBSZW9yZyBpbiBUb3JvbnRvPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhc2hhLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8gLSBzb3JyeSAtIGJ1dCB3 aGF0IHdlIHJlYWxseSB3YW50IHRvIGhlYXIgYXJlIHlvdXIgb3BpbmlvbnMgb24gdGhlIHJlb3Jn YW5pemF0aW9uLiAmbmJzcDtQbGVhc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmp1c3QgZW1haWwgdGhlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxpYTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDY6MDIgQU0sIEFsZXhhbmRlciBWYWlu c2h0ZWluICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFsaWEs IEFkcmlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JcyB0aGVy ZSBhbnkgd2F5IHRvIGNvbm5lY3QgcmVtb3RlbHk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRodW1iIHR5cGVkIG9uIG15 IExHLDxicj4NClNhc2hhPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPjxicj4NCjxicj4NCi0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLTxi cj4NCjxiPkZyb206Jm5ic3A7PC9iPlRob21hcyBIZWlkZSBDbGF1c2VuPGJyPg0KPGI+RGF0ZTom bmJzcDs8L2I+MjEvMDcvMjAxNCAxODo1Nzxicj4NCjxiPlRvOiZuYnNwOzwvYj5BbGlhIEF0bGFz Ozxicj4NCjxiPkNjOiZuYnNwOzwvYj5BZHJpYW4gPGEgaHJlZj0ibWFpbHRvOkZhcnJlbCUzQnJ0 Zy1kaXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5GYXJyZWw7cnRnLWRpckBpZXRmLm9yZzwv YT47PGEgaHJlZj0ibWFpbHRvOnJ0Zy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5y dGctY2hhaXJzQGlldGYub3JnPC9hPjs8YnI+DQo8Yj5TdWJqZWN0OjwvYj5SZTogW1JURy1ESVJd IENvbnN1bHRhdGl2ZSBTZXNzaW9uIG9uIFJURyBSZW9yZyBpbiBUb3JvbnRvPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkF3ZXNvbWUsIEFsaWEsIHRoYW5rcyBhIHRvbi4gU2VlIGFs bCB5J2FsbCB0b21vcnJvdywgdGhlbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRob21hczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPk9uIDIxIEp1bCAyMDE0LCBhdCAxNzo1NCAsIEFsaWEgQXRsYXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFrYXRs YXNAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5UaGUgbWVldGluZyBpcyBvbiBUdWVzZGF5IGZyb20gMTJwbSB0byAycG0gaW4g dGhlIFF1ZWJlYyByb29tLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5UaGFua3MgZm9yIHRoZSByZW1pbmRlciB0byBzZW5kIGl0IHRoZSBy b29tIGluZm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPkFsaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIEp1bCAyMSwgMjAxNCAx MTowMyBBTSwgJnF1b3Q7VGhvbWFzIEhlaWRlIENsYXVzZW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmciIHRhcmdldD0iX2JsYW5rIj50aG9tYXNAdGhv bWFzY2xhdXNlbi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5IZXkgQV4yLDxicj4NCjxicj4NCkkgbWF5IGhhdmUgbWlzc2Vk IGl0LCBidXQgd2FzIHRoZXJlIGEgcm9vbSBhbm5vdW5jZWQgZm9yIHRoaXMgZXZlbnQg4oCUIG9y LCBpcyB0aGUgcmVjb21tZW5kZWQgdG8gc3RhbGsgZWl0aGVyIG9mIHlvdSBhZnRlciB0aGUgbW9y bmluZyBzZXNzaW9ucywgYW5kIHNlZSB3aGVyZSB0aGF0IHRha2VzIHVzPzxicj4NCjxicj4NCkNo ZWVycyw8YnI+DQo8YnI+DQpUaG9tYXM8YnI+DQo8YnI+DQomZ3Q7IE9uIDI0IEp1biAyMDE0LCBh dCAyMjoxNCAsIEFkcmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9n LmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDs8YnI+DQomZ3Q7IENoYWlycyBhbmQgRGlyZWN0b3JhdGUsPGJyPg0KJmd0Ozxi cj4NCiZndDsgQWxpYSBhbmQgSSBoYXZlIGJsb2NrZWQgb3V0IGEgc2xvdCBpbiBUb3JvbnRvIGZv ciB5b3UgdG8gY29tZSBhbmQgZGlzY3VzcyBBcmVhPGJyPg0KJmd0OyByZW9yZ2FuaXNhdGlvbiB3 aXRoIHVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGhhdmUgZm91bmQgVHVlc2RheSAxMi4wMCB0 byAxNC4wMCBkb2Vzbid0IGNvbmZsaWN0IHdpdGggYW55IFJURyBXRyBtZWV0aW5ncyw8YnI+DQom Z3Q7IHNvIHdlIHN1Z2dlc3QgJnF1b3Q7Z3JhYiBsdW5jaCBhbmQgY29tZSBhbG9uZyZxdW90Oy4g Um9vbSB0byBiZSBhbm5vdW5jZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIG1lZXRpbmcgd2ls bCBub3QgYmUgYW5ub3VuY2VkIHdpZGVyIHRoYW4gdGhpcyBncm91cGluZywgYnV0IHdpbGwgbm90 IGJlIGE8YnI+DQomZ3Q7IHByaXZhdGUgbWVldGluZyBzbyBpdCBpcyBwb3NzaWJsZSB0aGF0IG90 aGVyIHdpbGwgZHJpZnQgaW4uIFdlIHdpbGwgbm90IHRocm93PGJyPg0KJmd0OyB0aGVtIG91dCE8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgdmFy aW91cyBsaXN0cyBzbyBmYXIgYW5kIHBsZWFzZSBzdGF5IGVuZ2FnZWQuPGJyPg0KJmd0Ozxicj4N CiZndDsgQWRyaWFuIGFuZCBBbGlhPGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_a4f139987eaf4a2da05136447d942b9cAM3PR03MB612eurprd03pro_-- From nobody Tue Jul 22 06:38:04 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2281B27D9; Tue, 22 Jul 2014 06:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.503 X-Spam-Level: X-Spam-Status: No, score=-96.503 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsv0G-nJ8Kmg; Tue, 22 Jul 2014 06:32:49 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673FF1B27D4; Tue, 22 Jul 2014 06:32:49 -0700 (PDT) Received: from SMTP1.etri.info (129.254.28.71) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 22 Jul 2014 22:32:48 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP1.etri.info ([10.2.6.30]) with mapi id 14.01.0355.002; Tue, 22 Jul 2014 22:32:45 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger Thread-Topic: Uploaded draft-ietf-mpls-smp-requirements-07 Thread-Index: AQHPpbFrWPotK+BDYUSN4fLjzJrAvQ== Date: Tue, 22 Jul 2014 13:32:44 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2874C922@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/7WpTjJBEZn20qav34hR1HmvmWwk X-Mailman-Approved-At: Tue, 22 Jul 2014 06:38:01 -0700 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] Uploaded draft-ietf-mpls-smp-requirements-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 13:32:52 -0000 SGksIGFsbC4NCg0KVGhlIGF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudCB1cGxvYWRlZCBhIG5ldyB2 ZXJzaW9uLCB3aGljaCByZXNvbHZlcyBhbGwgdGhlIGNvbW1lbnRzIHJhaXNlZCBzbyBmYXIuIA0K DQpCZXN0IHJlZ2FyZHMsDQoNCkplb25nLWRvbmcNCg0K From nobody Tue Jul 22 07:24:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01D31B28E1; Tue, 22 Jul 2014 07:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpObBGvNBVF4; Tue, 22 Jul 2014 07:24:12 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1CB1A007A; Tue, 22 Jul 2014 07:24:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A89472407D0; Tue, 22 Jul 2014 07:24:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-96a9.meeting.ietf.org (dhcp-96a9.meeting.ietf.org [31.133.150.169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1CCC1240223; Tue, 22 Jul 2014 07:24:09 -0700 (PDT) Message-ID: <53CE7407.1080607@joelhalpern.com> Date: Tue, 22 Jul 2014 10:24:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas , Thomas Clausen References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/KjqdDnNDqLQulWjGy5whuhKzxW4 Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:24:15 -0000 I will not be able to make it to the meeting due to a conflicting meeting. Several people have mentioned an idea that apparently was floated, but which I missed if it was on the list. THe idea is to separate requirements generation (for various activities) from protocol generation to address those requirements. Not just separate them in time (we do that) but put them in different working groups. This strikes me as likely to cause trouble. Whether other folks have succeeded with this or not, the way the IETF works our requirements work is neither divorced from the solutions nor is it typically complete enough to be fully understood without context. So throwing requirements over a wall from one WG to another seems ineffective. One could argue that this separation is what KARPO did. But I would say that KARP did requirements, GAP Analysis, and then participated in the work on solution development for several iterations. In fact several times the work started in KARP, and only moved to the specific protocol group when it was reasonably clear that the problem was being addressed. Just a thought, Joel From nobody Tue Jul 22 08:07:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607A51A007A; Tue, 22 Jul 2014 08:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVMBvq8BVY0v; Tue, 22 Jul 2014 08:07:03 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAE81A0060; Tue, 22 Jul 2014 08:07:02 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 15:07:00 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0990.007; Tue, 22 Jul 2014 15:07:00 +0000 From: Alexander Vainshtein To: "Joel M. Halpern" Thread-Topic: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input Thread-Index: AQHPpbixd9rRNYf2N0G32QbhV/Q3QpusLeiQ Date: Tue, 22 Jul 2014 15:06:59 +0000 Message-ID: <0bbb67f5f192421c8872b351f3f329d4@AM3PR03MB612.eurprd03.prod.outlook.com> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> In-Reply-To: <53CE7407.1080607@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(37854004)(13464003)(377454003)(252514010)(189002)(199002)(86362001)(76576001)(106116001)(92566001)(31966008)(87936001)(76176999)(33646002)(66066001)(64706001)(19580395003)(83072002)(81542001)(85306003)(85852003)(21056001)(81342001)(93886003)(79102001)(2656002)(4396001)(20776003)(107046002)(76482001)(80022001)(19580405001)(95666004)(74316001)(50986999)(99396002)(54356999)(83322001)(74502001)(77982001)(110136001)(46102001)(101416001)(106356001)(105586002)(74662001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/frBW3wQg-JNNF-G_GQRZOT4BPW4 Cc: Thomas Clausen , Adrian Farrel , Alia Atlas , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:07:07 -0000 Sm9lbCwgYW5kIGFsbCwNCkkgYWdyZWUgd2l0aCBKb2VsOiBhZG1pbmlzdHJhdGl2ZSBzZXBhcmF0 aW9uIG9mIHJlcXVpcmVtZW50cyBhbmQgcHJvdG9jb2wgd29yayBpcyBhIGhpZ2hseSBwcm9ibGVt YXRpYyBpZGVhLg0KDQpJIGFzc3VtZSB0aGF0IHdlIHdvdWxkIG5vdCBsaWtlIHRvIHBvc3Rwb25l IGJlZ2lubmluZyBvZiB0aGUgV0cgd29yayBvbiB0aGUgcHJvdG9jb2wgIHVudGlsIHRoZSByZXF1 aXJlbWVudCBkb2N1bWVudCBpcyBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24gYXMgYW4gUkZDOyBi dXQgaWYgd2UgcnVuIHRoZXNlIHR3byBpbiBwYXJhbGxlbCwgc3luY2hyb25pemluZyBvbmdvaW5n IGNoYW5nZXMgaW4gdGhlIHJlcXVpcmVtZW50cyB3aXRoIGNoYW5nZXMgaW4gdGhlIHNvbHV0aW9u IHdvdWxkIGJlY29tZSBhIGNvbXBsZXggY3Jvc3MtV0cgdGFzay4gDQoNCkFuZCBjb25zaWRlciB0 aGUgY2FzZSB3aGVuIGluIG9yZGVyIHRvIGFkZHJlc3MgcmVxdWlyZW1lbnRzIHdlIHdvdWxkIG5l ZWQgY2hhbmdlcyBpbiBtb3JlIHRoYW4gb25lIHByb3RvY29sPyBDQ0FNUCB3b3JrIG9uIEdNUExT IHByb3ZpZGVzIGxvdHMgb2YgZXhhbXBsZXMgd2hlbiByZXF1aXJlbWVudHMgdG8gcHJvdmlkZSBh IEdNUExTLWNvbnRyb2xsZWQgbm9uLXBhY2tldCBuZXR3b3JrIHJlcXVpcmUgY29vcmRpbmF0ZWQg Y2hhbmdlcyBpbiBSU1ZQLVRFLCBMTVAsIE9TUEYtVEUgYW5kIElTLUlTLVRFLi4uIEp1c3QgcGxh bm5pbmcgdGhlIHNlc3Npb25zIG9mIHRoZSBhZmZlY3RlZCBXR3MgZHVyaW5nIGFuIElFVEYgbWVl dGluZyB0byBhdm9pZCBjb25mbGljdHMgd291bGQgYmVjb21lIGhpZ2hseSBub24tdHJpdmlhbCBJ TU8uLi4NCg0KTXkgMmMsDQogICAgICAgU2FzaGEgDQpFbWFpbDogQWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20NCk1vYmlsZTogMDU0LTkyNjYzMDINCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGctZGlyIFttYWlsdG86cnRnLWRpci1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkg MjIsIDIwMTQgNToyNCBQTQ0KPiBUbzogQWxpYSBBdGxhczsgVGhvbWFzIENsYXVzZW4NCj4gQ2M6 IEFkcmlhbiBGYXJyZWw7IHJ0Zy1jaGFpcnNAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtSVEctRElSXSBDb25zdWx0YXRpdmUgU2Vzc2lvbiBvbiBSVEcgUmVvcmcg aW4gVG9yb250byAtLSBpbnB1dA0KPiANCj4gSSB3aWxsIG5vdCBiZSBhYmxlIHRvIG1ha2UgaXQg dG8gdGhlIG1lZXRpbmcgZHVlIHRvIGEgY29uZmxpY3RpbmcgbWVldGluZy4NCj4gDQo+IFNldmVy YWwgcGVvcGxlIGhhdmUgbWVudGlvbmVkIGFuIGlkZWEgdGhhdCBhcHBhcmVudGx5IHdhcyBmbG9h dGVkLCBidXQNCj4gd2hpY2ggSSBtaXNzZWQgaWYgaXQgd2FzIG9uIHRoZSBsaXN0Lg0KPiBUSGUg aWRlYSBpcyB0byBzZXBhcmF0ZSByZXF1aXJlbWVudHMgZ2VuZXJhdGlvbiAoZm9yIHZhcmlvdXMg YWN0aXZpdGllcykNCj4gZnJvbSBwcm90b2NvbCBnZW5lcmF0aW9uIHRvIGFkZHJlc3MgdGhvc2Ug cmVxdWlyZW1lbnRzLiAgTm90IGp1c3QNCj4gc2VwYXJhdGUgdGhlbSBpbiB0aW1lICh3ZSBkbyB0 aGF0KSBidXQgcHV0IHRoZW0gaW4gZGlmZmVyZW50IHdvcmtpbmcNCj4gZ3JvdXBzLg0KPiANCj4g VGhpcyBzdHJpa2VzIG1lIGFzIGxpa2VseSB0byBjYXVzZSB0cm91YmxlLiAgV2hldGhlciBvdGhl ciBmb2xrcyBoYXZlDQo+IHN1Y2NlZWRlZCB3aXRoIHRoaXMgb3Igbm90LCB0aGUgd2F5IHRoZSBJ RVRGIHdvcmtzIG91ciByZXF1aXJlbWVudHMgd29yaw0KPiBpcyBuZWl0aGVyIGRpdm9yY2VkIGZy b20gdGhlIHNvbHV0aW9ucyBub3IgaXMgaXQgdHlwaWNhbGx5IGNvbXBsZXRlDQo+IGVub3VnaCB0 byBiZSBmdWxseSB1bmRlcnN0b29kIHdpdGhvdXQgY29udGV4dC4gIFNvIHRocm93aW5nIHJlcXVp cmVtZW50cw0KPiBvdmVyIGEgd2FsbCBmcm9tIG9uZSBXRyB0byBhbm90aGVyIHNlZW1zIGluZWZm ZWN0aXZlLiAgT25lIGNvdWxkIGFyZ3VlDQo+IHRoYXQgdGhpcyBzZXBhcmF0aW9uIGlzIHdoYXQg S0FSUE8gZGlkLiAgQnV0IEkgd291bGQgc2F5IHRoYXQgS0FSUCBkaWQNCj4gcmVxdWlyZW1lbnRz LCBHQVAgQW5hbHlzaXMsIGFuZCB0aGVuIHBhcnRpY2lwYXRlZCBpbiB0aGUgd29yayBvbg0KPiBz b2x1dGlvbiBkZXZlbG9wbWVudCBmb3Igc2V2ZXJhbCBpdGVyYXRpb25zLiAgSW4gZmFjdCBzZXZl cmFsIHRpbWVzIHRoZQ0KPiB3b3JrIHN0YXJ0ZWQgaW4gS0FSUCwgYW5kIG9ubHkgbW92ZWQgdG8g dGhlIHNwZWNpZmljIHByb3RvY29sIGdyb3VwIHdoZW4NCj4gaXQgd2FzIHJlYXNvbmFibHkgY2xl YXIgdGhhdCB0aGUgcHJvYmxlbSB3YXMgYmVpbmcgYWRkcmVzc2VkLg0KPiANCj4gSnVzdCBhIHRo b3VnaHQsDQo+IEpvZWwNCg0K From nobody Tue Jul 22 08:10:19 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245F31B28AF; Tue, 22 Jul 2014 08:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ6YBGWlMP5j; Tue, 22 Jul 2014 08:09:53 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788501B2821; Tue, 22 Jul 2014 08:09:53 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so4991350ykp.32 for ; Tue, 22 Jul 2014 08:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fGPBmEtXEg9HMOKh5Oby7LwT1JFeTQpSAKp3l/nmXsM=; b=BIIRJAXHiOznN1KmyxjWINC+A84bVrFk8/X2ec6ub0hdDSgrf1RgjdP7fmRv17NbFY uiuhSJRQCTcXFx73m0ScM2J6lj9+YeIHNuatMhazP1Skgkb2MDaLCKpY/g9y+IH9zlTt 5HTaYOInJOCPY+TivW2U4ga+OcdblnI7jY7jR02xlC13hXThfo1EOAW82dahQsS4S93i TvNkTOfki3gUufjrVt8+NZmMBG4eQIhM1wQjgRSgMy6BZjEfvowEOcULxtyjjda0DQ6t WK43CRTCGJ52dg4U7Cne4T7iibq9Ad0dEvJda0Pk6gqE0G1mdeaysOFtpybCidAK33hO hR3Q== MIME-Version: 1.0 X-Received: by 10.236.67.9 with SMTP id i9mr5824980yhd.139.1406041792817; Tue, 22 Jul 2014 08:09:52 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Tue, 22 Jul 2014 08:09:52 -0700 (PDT) In-Reply-To: <53CE7407.1080607@joelhalpern.com> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> Date: Tue, 22 Jul 2014 11:09:52 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=089e0122957099af9b04fec99db8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/8NpwUp03eSoUx7DEayWGQbaVnzs Cc: Adrian Farrel , Thomas Clausen , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:09:59 -0000 --089e0122957099af9b04fec99db8 Content-Type: text/plain; charset=UTF-8 Joel, First I've heard of that idea... Alia On Tue, Jul 22, 2014 at 10:24 AM, Joel M. Halpern wrote: > I will not be able to make it to the meeting due to a conflicting meeting. > > Several people have mentioned an idea that apparently was floated, but > which I missed if it was on the list. > THe idea is to separate requirements generation (for various activities) > from protocol generation to address those requirements. Not just separate > them in time (we do that) but put them in different working groups. > > This strikes me as likely to cause trouble. Whether other folks have > succeeded with this or not, the way the IETF works our requirements work is > neither divorced from the solutions nor is it typically complete enough to > be fully understood without context. So throwing requirements over a wall > from one WG to another seems ineffective. One could argue that this > separation is what KARPO did. But I would say that KARP did requirements, > GAP Analysis, and then participated in the work on solution development for > several iterations. In fact several times the work started in KARP, and > only moved to the specific protocol group when it was reasonably clear that > the problem was being addressed. > > Just a thought, > Joel > --089e0122957099af9b04fec99db8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joel,

First I've heard of that idea= ...

Alia

On Tue, Jul 22, 2014 at 10:24 AM, Joel M. H= alpern <jmh@joelhalpern.com> wrote:
I will not be able to make it to the meeting= due to a conflicting meeting.

Several people have mentioned an idea that apparently was floated, but whic= h I missed if it was on the list.
THe idea is to separate requirements generation (for various activities) fr= om protocol generation to address those requirements. =C2=A0Not just separa= te them in time (we do that) but put them in different working groups.

This strikes me as likely to cause trouble. =C2=A0Whether other folks have = succeeded with this or not, the way the IETF works our requirements work is= neither divorced from the solutions nor is it typically complete enough to= be fully understood without context. =C2=A0So throwing requirements over a= wall from one WG to another seems ineffective. =C2=A0One could argue that = this separation is what KARPO did. =C2=A0But I would say that KARP did requ= irements, GAP Analysis, and then participated in the work on solution devel= opment for several iterations. =C2=A0In fact several times the work started= in KARP, and only moved to the specific protocol group when it was reasona= bly clear that the problem was being addressed.

Just a thought,
Joel

--089e0122957099af9b04fec99db8-- From nobody Tue Jul 22 08:31:48 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7B1A00F9 for ; Tue, 22 Jul 2014 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z03HbpGZD1hO for ; Tue, 22 Jul 2014 08:31:45 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 632DB1A0025 for ; Tue, 22 Jul 2014 08:31:45 -0700 (PDT) Received: (qmail 642 invoked by uid 0); 22 Jul 2014 15:31:41 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 22 Jul 2014 15:31:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id VTXW1o0162SSUrH01TXZal; Tue, 22 Jul 2014 09:31:40 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=WrhVjQHxoPwA:10 a=Lhyv8l1xRe4A:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=IRDgFnn-AAAA:8 a=48vgC7mUAAAA:8 a=PZEZ8CSbuXdq9GiGgDIA:9 a=0LXFZJpwR3Vpdfk3:21 a=Re5ifUXRLzH5IaMG:21 a=QEXdDO2ut3YA:10 a=ZgsxABZQttoA:10 a=1QW4SJF8ptEA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=vYwm0+h8arZkVkeavDMoCoBCYmwTaW6bvNXTvswBRI0=; b=PVArSRuElyq9bmVfEJkBZvVO9Ukc7S4aDL2lkZxBgZACwRJ9ucVlRYEau1SbNQF3T2s1CgrKjG4iu5ZOW88RzGze9FLYfzha6leXjNE6wHQT3s9NhEFNFjUk/XZJOsZQ; Received: from box313.bluehost.com ([69.89.31.113]:42066 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X9c2M-0005Tb-HV; Tue, 22 Jul 2014 09:31:30 -0600 Message-ID: <53CE83DC.8020002@labn.net> Date: Tue, 22 Jul 2014 11:31:40 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexander Vainshtein , "Joel M. Halpern" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <0bbb67f5f192421c8872b351f3f329d4@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <0bbb67f5f192421c8872b351f3f329d4@AM3PR03MB612.eurprd03.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/6uYYU2D-XkZubN_IRNkX0vs4ecw Cc: Adrian Farrel , Thomas Clausen , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , Alia Atlas Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:31:46 -0000 While I agree with both sasha's and Joels comments on separation, and don't generally believe such is a good idea, it could yield smaller wgs with less signal-to-noise ratio -- which seems to be one of the objectives of this discussion... lou On 7/22/2014 11:06 AM, Alexander Vainshtein wrote: > Joel, and all, > I agree with Joel: administrative separation of requirements and protocol work is a highly problematic idea. > > I assume that we would not like to postpone beginning of the WG work on the protocol until the requirement document is approved for publication as an RFC; but if we run these two in parallel, synchronizing ongoing changes in the requirements with changes in the solution would become a complex cross-WG task. > > And consider the case when in order to address requirements we would need changes in more than one protocol? CCAMP work on GMPLS provides lots of examples when requirements to provide a GMPLS-controlled non-packet network require coordinated changes in RSVP-TE, LMP, OSPF-TE and IS-IS-TE... Just planning the sessions of the affected WGs during an IETF meeting to avoid conflicts would become highly non-trivial IMO... > > My 2c, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 > >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Tuesday, July 22, 2014 5:24 PM >> To: Alia Atlas; Thomas Clausen >> Cc: Adrian Farrel; rtg-chairs@ietf.org; rtg-dir@ietf.org >> Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input >> >> I will not be able to make it to the meeting due to a conflicting meeting. >> >> Several people have mentioned an idea that apparently was floated, but >> which I missed if it was on the list. >> THe idea is to separate requirements generation (for various activities) >> from protocol generation to address those requirements. Not just >> separate them in time (we do that) but put them in different working >> groups. >> >> This strikes me as likely to cause trouble. Whether other folks have >> succeeded with this or not, the way the IETF works our requirements work >> is neither divorced from the solutions nor is it typically complete >> enough to be fully understood without context. So throwing requirements >> over a wall from one WG to another seems ineffective. One could argue >> that this separation is what KARPO did. But I would say that KARP did >> requirements, GAP Analysis, and then participated in the work on >> solution development for several iterations. In fact several times the >> work started in KARP, and only moved to the specific protocol group when >> it was reasonably clear that the problem was being addressed. >> >> Just a thought, >> Joel From nobody Tue Jul 22 13:05:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34141B2AF5; Tue, 22 Jul 2014 10:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14cz3WmDVXjn; Tue, 22 Jul 2014 10:41:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0510C1B2AF4; Tue, 22 Jul 2014 10:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5457; q=dns/txt; s=iport; t=1406050863; x=1407260463; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sukzFUzVvNkm70WOQo7be46f7S/Bj70z6L5oEe0JYxA=; b=fUvKaI9kMN7GqCanX3cfdfs5nz2R300JLtzdTjdbxyUeh+eA3HaJ7elf h3R87HqA/7atBn7LQSPcv4C2m/gZgeUN2SxtVOkA8kodyaQ1diZHwSCDW Jv64FgKnWLJbAVKnc6FXFJy5ohD4GTTbyCHbQ430FWGUWL2V9Wuponl2o A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAJWgzlOtJV2T/2dsb2JhbABYgw5SV4J4xCGHRQGBExZ2hAMBAQEDASMPAQVAARALFAQCAgUWCwICCQMCAQIBRQYBDAEHAQGINggNqGGXKReBLIwZggYHgniBTgEEmyeBTYVKjRyDYiEvAQ X-IronPort-AV: E=Sophos;i="5.01,711,1400025600"; d="scan'208";a="338907487" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2014 17:41:02 +0000 Received: from [10.21.126.103] (sjc-vpn6-1639.cisco.com [10.21.126.103]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6MHf0Jg003562; Tue, 22 Jul 2014 17:41:01 GMT Message-ID: <53CEA22C.4010105@cisco.com> Date: Tue, 22 Jul 2014 13:41:00 -0400 From: Bhavani Parise User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Terry Manderson , "rtg-ads@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/TgkEFylv5Fsy3cg7ERR-x-8jER0 X-Mailman-Approved-At: Tue, 22 Jul 2014 13:05:46 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-bmwg-bgp-basic-convergence.all@tools.ietf.org" , "bmwg@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bmwg-bgp-basic-convergence-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:41:04 -0000 Terry, Thanks for your review and feedback. Apologies for the delay, we incorporated the changes in the latest version of the draft (draft-ietf-bmwg-bgp-basic-convergence-02.txt) published couple of weeks ago. Please see inline for details on each of the comments: On 4/22/14 7:50 PM, Terry Manderson 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > 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-bmwg-bgp-basic-convergence-01 > http://tools.ietf.org/id/draft-ietf-bmwg-bgp-basic-convergence-01.txt > Reviewer: Terry Manderson > Review Date: 18/04/2014 > IETF LC End Date: N/A - WG requested Routing Area Directorate review > Intended Status: Standards Track > > Summary: > > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > This document is clearly written and for the most part easy to understand. > The steps are > enumerated, which is very helpful. I would have prefered to see the > reference topology figures repeated closer to the test case where they are > used, but this is a matter of style. > > > Major Issues: > > No major issues found > > Minor Issues: > > Section 3 (figures 1-4): please define The Helper node (HLP) before its > use. It is first defined in section 5.1.2 <> Fixed this in Sec.3 > > Section 4.5: Please clarify if the interface media types and throughput > must all be exactly the same for all devices in all the test cases, or > that the media types and throughput are to be the same for iterations of > the test cases. I re-read that Para several times and could infer either > situation. <> thanks, clarified this. It should be for all iterations of test cases > > Section 4.10: Can you please highlight the impact on the tests for where > routing processor redundancy cannot be disabled, or if unwilling to do > that suggest that the impacts or assessment of impacts are out of scope of > this draft. <> yes clarified this and added the scope/impact in the section > > Section 5.: Point B. I assume you mean Hard Reset here. For understanding > purposes you may like to consider adding the term in parenthesis. <>thanks, another reviewer also pointed to the same. So we reworded and clarified the sentence > > Section 5.1.1: Pont B introduces "peer x of Emulator". I find this wording > terse, can you please clarify what this is as I couldn't see in the text > of section 3. > > Point D: "peer-x" is used here. Is this the same term as point B? > > It appears as I read through the points, that Peer-X (possibly otherwise > known as 'SOME_ASN-X) is the test case nomenclature representation of the > emulator function. It may be worth stating that up front to be pragmatic > and help the reader. <>good catch, fixed this and used the same representation now in both Sec.3 and 5.1.1 > > > Section 5.1.2: > > This section introduces a NTP time source to the test case, that isn't > described in "Section 3. Test Topologies". While not a critical concern to > someone implementing the topologies, it may help them by highlighting the > necessity of NTP in section 3. <> added the text in Sec.3 > > Section 5.1.5 > > Is the omission of normative language in the points, specifically A,B, > and C intentional? <> fixed these > > Section 5.5, Point B. The language here surrounding the time source is > different than in earlier text, is that intentional? <> thanks, fixed this > > Nits: > > Section 1.1, Para 3: s/functional/functions/ > Section 4.2, Para 1: s/or through neighbor/or through a neighbor/ > Section 4.4, Para 3: s/a)default/a) default/ > s/b)platform-specific/b) platform-specific/ > s/c)values/c) values/ > Section 4.6, Para 3: s/)is/) is/ > > Section 5.1.1, second last para: s/Stand Deviation/Standard Deviation/ > > Section 5.2.1, > Point C. "Tx1", do you simply mean "Tx" as described in Figure 1? > Point C. s/(Tx1)Interface/(Tx1) Interface/ > Point E. s/Trr2/Tr2/ > Point F. "(Drr1)" Can you clarify this is the intended nomenclature for > this egress interface on the DUT? > > Section 5.3, Point E s/route say/route, say/ - I'd expect the RFC editor > may suggest using "e.g". > > Section 5.6, Point B(6) s/(e.g. route A)/(e.g. routeA)/ - "RouteA" appears > to be the selected form from earlier parts of the draft. > (same for other occurrences in the remainder of the Draft (eg S5.8 point > N,Q, .) > > > Section 5.8. point F. s/Autonomous System.s/Autonomous Systems/ > Section 5.8. Point S. s/Node -1/Node-1/ <> thanks for pointing all these variations. Fixed them in the newer version of the draft Once again thanks for the review. regards, Bhavani > > > Cheers > Terry From nobody Tue Jul 22 15:49:26 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE511A0381; Tue, 22 Jul 2014 15:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2XFr1SefZpT; Tue, 22 Jul 2014 15:49:24 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869311A02EF; Tue, 22 Jul 2014 15:49:23 -0700 (PDT) Received: from [172.16.57.142] (unknown [206.47.221.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 67E491802B19; Wed, 23 Jul 2014 00:49:21 +0200 (CEST) Message-ID: <53CEEA79.8010300@pi.nu> Date: Wed, 23 Jul 2014 00:49:29 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> In-Reply-To: <53CE7407.1080607@joelhalpern.com> Content-Type: multipart/mixed; boundary="------------060503070308040102070004" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/wpRdhzaOynQDuFhhBAFiZPJ4RAI Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:49:25 -0000 This is a multi-part message in MIME format. --------------060503070308040102070004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Folks, I took a look at the performance on rtg wg's. The spread sheet list the number of RFC's per working group between two meeting. I've used the number of people who signed the blue sheets in Vancouver as some type of average except for roll that did not meet in Vancouver, where I used the London figure instead. Calculated the number of RFCs per person in the room. The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. The highest absolute number of RFC is MPLS (this meeting). The best trend has MPLS. Since I don't care too much about how much noise the non-participating participants is exposed too, I don't think the a re-org is motivated by the figures in the spread sheet. I guess I would go as far as too say that no arguments presented so far motivates a re-org of the RTG area. Though I'm totally supportive of some well considered re-organization of working groups, but - do it carefully - at a time when it is optimal for the working groups - involve the chairs to drive the re-org - don't break things that work /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --------------060503070308040102070004 Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="stats.xlsx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="stats.xlsx" UEsDBBQABgAIAAAAIQCeLGxvawEAABAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACslMFOwzAMhu9IvEOVK2qzcUAIrdthwBEm MR4gJO4aLU2iOBvb2+NmY0KorELrpVEb+/+/uHYms11jsi0E1M6WbFyMWAZWOqXtqmTvy+f8 nmUYhVXCOAsl2wOy2fT6arLce8CMsi2WrI7RP3COsoZGYOE8WNqpXGhEpNew4l7ItVgBvx2N 7rh0NoKNeWw12HTyCJXYmJg97ejzgSSAQZbND4GtV8mE90ZLEYmUb6365ZIfHQrKTDFYa483 hMF4p0O787fBMe+VShO0gmwhQnwRDWHwneGfLqw/nFsX50U6KF1VaQnKyU1DFSjQBxAKa4DY mCKtRSO0/eY+45+CkadlPDBIe74k3MMR6X8DT8/LEZJMjyHGvQEcuuxJtM+5FgHUWww0GYMD /NTu4ZDCyHlNLTJwEU665/ypbxfBeaQJDvB/gO8RbbNzT0IQoobTkHY1+8mRpv/iE0N7vyhQ Hd483WfTLwAAAP//AwBQSwMEFAAGAAgAAAAhALVVMCP0AAAATAIAAAsACAJfcmVscy8ucmVs cyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskk1PwzAMhu9I/IfI99XdkBBC S3dBSLshVH6ASdwPtY2jJBvdvyccEFQagwNHf71+/Mrb3TyN6sgh9uI0rIsSFDsjtnethpf6 cXUHKiZylkZxrOHEEXbV9dX2mUdKeSh2vY8qq7iooUvJ3yNG0/FEsRDPLlcaCROlHIYWPZmB WsZNWd5i+K4B1UJT7a2GsLc3oOqTz5t/15am6Q0/iDlM7NKZFchzYmfZrnzIbCH1+RpVU2g5 abBinnI6InlfZGzA80SbvxP9fC1OnMhSIjQS+DLPR8cloPV/WrQ08cudecQ3CcOryPDJgosf qN4BAAD//wMAUEsDBBQABgAIAAAAIQCSB5TsBAEAAD8DAAAaAAgBeGwvX3JlbHMvd29ya2Jv b2sueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACskstqxDAMRfeF/oPRvnEyfVCGcWbRUphtm36AcJQ4TGIHW33k72tSOsnAkG6yMUjC 9x6Ju9t/d634JB8aZxVkSQqCrHZlY2sF78XLzSOIwGhLbJ0lBQMF2OfXV7tXapHjp2CaPoio YoMCw9xvpQzaUIchcT3ZOKmc75Bj6WvZoz5iTXKTpg/SzzUgP9MUh1KBP5S3IIqhj87/a7uq ajQ9O/3RkeULFjLw0MYFRIG+JlbwWyeREeRl+82a9hzPQpP7WMrxzZYYsjUZvpw/BkPEE8ep FeQ4WYS5XxNGY6ufDDZ2gjm1li5yt2ooDHoq39jHzM+zMW//wciz2Oc/AAAA//8DAFBLAwQU AAYACAAAACEAufD/4jcCAACSBAAADwAAAHhsL3dvcmtib29rLnhtbKxUy27bMBC8F+g/ELzL ekSKE8FSkDguaiAogjSPiy40tbIIU6RKUrWNoP/elVS1aXNJ0V7EJbka7swsubg4NJJ8BWOF VhkNZwEloLguhdpm9OH+g3dGiXVMlUxqBRk9gqUX+ft3i702u43WO4IAyma0dq5Nfd/yGhpm Z7oFhTuVNg1zODVb37YGWGlrANdIPwqCU79hQtERITVvwdBVJThca941oNwIYkAyh+XbWrR2 Qmv4W+AaZnZd63HdtAixEVK44wBKScPT9VZpwzYSaR/CZELG8BV0I7jRVlduhlD+WOQrvmHg h+FIOV9UQsLjKDthbfuJNf0pkhLJrFuVwkGZ0VOc6j38tmC69qoTEnfDOI4C6uc/rbg1pISK ddLdowkTPCYmJ1EU9ZlI6lI6MIo5WGrlUMMf6v+rXgP2stboDrmDL50wgE3Ry5Yv8Mt4yjb2 lrmadEZmdJkWDxbpFzeaFZOdthDgqsKAh+1SvNCbvTbzLxRnvKfuI/exvjH+U4d80Xfzo4C9 /aVoPyWHJ6FKvc8o3o3ji3g/LD+J0tUZjYL4HPfHtY8gtrXL6HyeJMPZL6CH/scjhpGowffP /Z0I8aL147q3lhKTCgzMugwHhOk3ziRHn/thSEyiJBwy4OBurMsXOKLEIqPPYRxczoPz2AtW J4kXn51H3ll8EnnL+DpaJfPV9eoq+fZ/uxqdTqeHoa+yZsbdG8Z3+JzcQXXFLHb5SAjrRCOm qv3pr/w7AAAA//8DAFBLAwQUAAYACAAAACEA4p9ToRYBAABoAgAAFAAAAHhsL3NoYXJlZFN0 cmluZ3MueG1sdJLBTsMwDIbvSLxDlHuXtBtbh9rugJjEjcPgHlJvi5Q4oU4HvD3ZJoHUdkd/ n/PbkVxtvp1lJ+jIeKx5PpOcAWrfGjzU/G23zUrOKCpslfUINf8B4pvm/q4iiiy9Rar5Mcbw KATpIzhFMx8Ak9n7zqmYyu4gKHSgWjoCRGdFIeVSOGWQM+17jGlumtKj+ezh6Q80FZmmis3H vq1EbCpxLq9Ia+XCEKZ5GmhIbXEKOILzCegUQhx2umBHkUHDsC18wXzIOm/tkL0877asXDDG 8iKTq2n9cLF5Pm2Xyc4zWUzb1dXeSC4v9lbyOtlFJkcfuSy9luelkx5Fv6ouGm2CwkjsXaXj 6dM9/a8n0qU0vwAAAP//AwBQSwMEFAAGAAgAAAAhAIuCbliTBgAAjhoAABMAAAB4bC90aGVt ZS90aGVtZTEueG1s7FnPixs3FL4X+j8Mc3f8a2ZsL/EGe2xn2+wmIeuk5Ki1ZY+ympEZybsx IVCSY6FQmpZeCr31UNoGEugl/Wu2TWlTyL/QJ83YI63lbppuIC1ZwzKj+fT06b0335M0Fy/d jalzhFNOWNJ2qxcqroOTERuTZNp2bw4HpabrcIGSMaIswW13gbl7afv99y6iLRHhGDvQP+Fb qO1GQsy2ymU+gmbEL7AZTuDZhKUxEnCbTsvjFB2D3ZiWa5VKUI4RSVwnQTGYvTaZkBF2htKk u7003qdwmwguG0Y03ZemsdFDYceHVYngCx7S1DlCtO3COGN2PMR3hetQxAU8aLsV9eeWty+W 0VbeiYoNfbV+A/WX98s7jA9rasx0erAa1PN8L+is7CsAFeu4fqMf9IOVPQVAoxHMNOOi2/S7 rW7Pz7EaKLu02O41evWqgdfs19c4d3z5M/AKlNn31vCDQQheNPAKlOF9i08atdAz8AqU4YM1 fKPS6XkNA69AESXJ4Rq64gf1cDnbFWTC6I4V3vK9QaOWGy9QkA2r7JJDTFgiNuVajO6wdAAA CaRIkMQRixmeoBFkcYgoOUiJs0umESTeDCWMQ3OlVhlU6vBf/jx1pTyCtjDSektewISvNUk+ Dh+lZCba7odg1dUgL599//LZE+fls8cnD56ePPjp5OHDkwc/ZraMjjsomeodX3z72Z9ff+z8 8eSbF4++sOO5jv/1h09++flzOxAmW3jh+ZePf3v6+PlXn/7+3SMLvJOiAx0+JDHmzlV87Nxg McxNecFkjg/Sf9ZjGCFi9EAR2LaY7ovIAF5dIGrDdbHpvFspCIwNeHl+x+C6H6VzQSwjX4li A7jHGO2y1OqAK3IszcPDeTK1D57OddwNhI5sY4coMULbn89AWYnNZBhhg+Z1ihKBpjjBwpHP 2CHGltndJsTw6x4ZpYyziXBuE6eLiNUlQ3JgJFLRaYfEEJeFjSCE2vDN3i2ny6ht1j18ZCLh hUDUQn6IqeHGy2guUGwzOUQx1R2+i0RkI7m/SEc6rs8FRHqKKXP6Y8y5rc+1FOarBf0KiIs9 7Ht0EZvIVJBDm81dxJiO7LHDMELxzMqZJJGO/YAfQooi5zoTNvgeM98QeQ9xQMnGcN8i2Aj3 2UJwE3RVp1QkiHwyTy2xvIyZ+T4u6ARhpTIg+4aaxyQ5U9pPibr/TtSzqnRa1Dspsb5aO6ek fBPuPyjgPTRPrmN4Z9YL2Dv9fqff7v9evze9y+ev2oVQg4YXq3W1do83Lt0nhNJ9saB4l6vV O4fyNB5Ao9pWqL3lais3i+Ay3ygYuGmKVB8nZeIjIqL9CM1giV9VG9Epz01PuTNjHFb+qllt ifEp22r/MI/32DjbsVarcneaiQdHomiv+Kt22G2IDB00il3Yyrza107VbnlJQPb9JyS0wUwS dQuJxrIRovB3JNTMzoVFy8KiKc0vQ7WM4soVQG0VFVg/ObDqaru+l50EwKYKUTyWccoOBZbR lcE510hvcibVMwAWE8sMKCLdklw3Tk/OLku1V4i0QUJLN5OEloYRGuM8O/Wjk/OMdasIqUFP umL5NhQ0Gs03EWspIqe0gSa6UtDEOW67Qd2H07ERmrXdCez84TKeQe5wue5FdArHZyORZi/8 6yjLLOWih3iUOVyJTqYGMRE4dSiJ266c/iobaKI0RHGr1kAQ3lpyLZCVt40cBN0MMp5M8Ejo YddapKezW1D4TCusT1X31wfLnmwO4d6PxsfOAZ2nNxCkmN+oSgeOCYcDoGrmzTGBE82VkBX5 d6ow5bKrHymqHMraEZ1FKK8ouphncCWiKzrqbuUD7S6fMzh03YUHU1lg/3XVPbtUS89polnU TENVZNW0i+mbK/Iaq6KIGqwy6VbbBl5oXWupdZCo1ipxRtV9hYKgUSsGM6hJxusyLDU7bzWp neOCQPNEsMFvqxph9cTrVn7odzprZYFYritV4qtPH/rXCXZwB8SjB+fAcyq4CiV8e0gRLPqy k+RMNuAVuSvyNSJcOfOUtN17Fb/jhTU/LFWafr/k1b1Kqel36qWO79erfb9a6XVr96GwiCiu +tlnlwGcR9FF/vFFta99gImXR24XRiwuM/WBpayIqw8w1drmDzAOAdG5F9QGrXqrG5Ra9c6g 5PW6zVIrDLqlXhA2eoNe6Ddbg/uuc6TAXqceekG/WQqqYVjygoqk32yVGl6t1vEanWbf69zP lzEw80w+cl+AexWv7b8AAAD//wMAUEsDBBQABgAIAAAAIQBDiOnbeQMAAB4KAAANAAAAeGwv c3R5bGVzLnhtbKxW227bOBB9L7D/QOhd1sWSIxmSitqOgAJtsUCyQF9pibKJ8iJQdGq36L93 SMm20rpO0mweYnI4PDwzw8NR9nbPGXogqqNS5E4w8R1ERCVrKja589996SYO6jQWNWZSkNw5 kM55W/zzJuv0gZG7LSEaAYTocmerdTv3vK7aEo67iWyJgJVGKo41TNXG61pFcN2ZTZx5oe/P PI6pcHqEOa+eA8Kx+rJr3UryFmu6pozqg8VyEK/m7zdCKrxmQHUfRLg6YtvJb/CcVkp2stET gPNk09CK/M4y9VIPkIpM7HjJdYcquRMasnUyoX7lfQ3GGWSsD3opa6DhT3zfd7wi84btRdZI MUZBltz8i5BfRWmWemjjVWTdN/SAGVgCg1FJJhXSkGFAthaBOek9lpjRtaLGrcGcskNvDo3B FmXw4xRSZAn1J3iWDmyijJ1iiyA2YygyyLImSpQwQcP4/tDC8QIuRA9j/Z7w3ih8CML4+Rs6 yWhtWGyW46BvHKSpyb4/iVP4mybpLEyTwI8SC74e3KmoyZ5AQWaRPXMUBpSiJ/sE5T8wiM4M boBAAhVPkjSaBlFkc/0SBpZIV2RrqWoQ4fhm9aYiY6TRUEFFN1vzq2UL/9dSa7ixRVZTvJEC M3O/jjuGAcBWhLE7I9TPzSPsfTO6sSB5cwPM5TVDKOYw7PH6icEfo/XYI9gUSvVyWLRvTviv 2I1w27LDO0Y3gpOjNEEO/RRtpaLfIESjowrWiXLMm6dpNbZ8Vbi9J3srbBPuvnlVRP8HpxfQ CB00rtcpsT0No97hwXhGmqd/hQUMLtyj61ifdnxNVGl7hOF3ne3lE65H/rIThtf7KTX8kt1f z4CyPcryZd4gtisVu4BpBQiSG+n6kapP+kSmKeTOJ5NWBh1w0Bha7yiDx/OCogGz3p/fCNuv tGmj9vU4nQKUa9LgHdP3p8XcOY8/kpruOIQ7eP1LH6S2ELlzHn8wT1kwM88yyO1DB10OftFO 0dz5fru4SVe3Zegm/iJxoymJ3TRerNw4Wi5WqzL1Q3/5Y9TVX9HT7bcHlCqI5h2Dzq+GYAfy d2db7owmPX3bVID2mHsazvx3ceC75dQP3GiGEzeZTWO3jINwNYsWt3EZj7jHf8c98L0g6D+c DPl4riknjIpjrY4VGluhSDC9EoR3rIR3/rArfgIAAP//AwBQSwMEFAAGAAgAAAAhADgP+THm BwAA2CQAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWysWlmTozYQfk9V/oOLyutiJA4f NfbWGmxwsptN5XxmbDym1jYOMDO7/z4tCbxSIzBUZh48dqv7k9SHWt3w8P7r+TR6SfIizS4L g5iWMUouu2yfXp4Wxl9/bt5NjVFRxpd9fMouycL4lhTG++WPPzy8ZvmX4pgk5QgQLsXCOJbl dT4eF7tjco4LM7smFxg5ZPk5LuFn/jQurnkS77nQ+TSmluWNz3F6MQTCPO+DkR0O6S4Jst3z ObmUAiRPTnEJ6y+O6bWo0c67PnDnOP/yfH23y85XgHhMT2n5jYMao/Nuvn26ZHn8eIJ9fyVO vKux+Y8G/Dnd5VmRHUoT4MZioc09z8azMSAtH/Yp7ICpfZQnh4Xxgc4/U9sYLx+4gv5Ok9dC +j4q48c/klOyK5M92MkYldn1Y3Io/eR0YsLGiBnkMcu+MMkt8FgwR8El2BzxrkxfEsH9iTCj /sunZd9hzvFtUvl7vYANN+Jv+WifHOLnU/l79hol6dOxhJW4oBSmm/n+W5AUOzAKTG1Sl6Hu shNAwOfonIJ3wSLP8Vf+/zXdl0cmbRLH8oB7tHsuyuz8T0WvpIWcXcnNYJNifGa6E8smTO4x KcpNylaiwxiLJfDdBXEZLx/y7HUEngZrKa4x81syZ3tge7HB+fV7gU0woRWTEtpfGAXo92VJ Jg/jF9DZrmLxNSyWyhJoWIjKstawUJVlo2GxVZZQw+KoLJGGxVVZthoWT2X5WbBQbjWmqF8w 4SMmfMKEXzHhs0QYg9VupnOQ6TpN9oFxg2khYGqTIXOsag6tOcWgw22NLBAogsiA8hiacNMx FnaMRR3zbfVyit7AyxWX79Yb42Z6Y2HMfR8TfEFwQTWHpe+Mf1qBbx2YEi2TkInnTCx3OqW2 S2cOcu9AiHpMlNvlGOfJ3hAHYeDOt2w85UdYIAO75g2wmmD9Dhll3QIt4GAzsDwUSIMlwsES 0X2JHnvjalkYDbVp96aY3htkeuC+BQuy3IpN/rJ0ZujUE2RsZkHFFtJSN1qEUMsbCSo67bYY QdHAZIgGfMa9MKbCtT1wbTjwuGtT03KsKfFs6rm25RFKGh4YSMJN557Mt2wcnJsYy0CGdkwF mDq06dwt0AKOO3cPlM19lB7bDN9kLdF9FM8klDrOdDaZuTMytT2voReu0spessolvXTvSHEV djmSrwbd5yTjVvML8vdVzcEDBx0+vjyI7wkdY+uOsY08hkIy7BiLOsa2+vkUvcH1bIDeGLeS XzDBFwR+2i39KQThtM4v6D4lMTYDbjbfsnEIOAoB1wGzboERotrMcV+Cmq6l/DXPi/BNUKI3 QeGqaskw/HYnZ0/F+ATuzgOsz9hvOQYd5CsYZLEyQb7rV3ScZfTkdUXG2V5PDvUgUUXGqaZB VnUBpUh/XfiEsS+Micg2xAJPJ7Bqnm+ICenGca2J5VDqwl1Kk29k+ab/EzLfcg6IABsiYDD+ ug2fBQa/HzavVMNFwh4iPZQR9YBxzEqVhHoTz3I9u5lQ/jeM6hC42uxOKURUPnLNgsq21Y2F BYqHKjZfGcVVizKI605lsBE69bo0t+iwCzbqgt22SKoaBGUMOV4Yu5JdCKb4FaXKL4SysANd 8bCzTWvizahdf050YScQW4oYYkPYMQ4IEqgeAxWfmK49dTxy+3Sbdz15ffhS47CyTBN2LUsS i9CJhD1m6bHYaPhihXZack21v+6ZVQcZ1hUgwH7LPyh8VjDItGs3wkrfBqjYG6EkuBtBpCWH FQjijvTkbWNKVReDKn2ftb++VzuEFdykLuVdc0IcOnVvn7pAkOQ1+QfKeT4DBAL0CgIVn5oS Np9HEwgt+MyreZtREwiDRUJZCzjc9LNEw0WEJloqlWqWbpWohh5W1xPGrtYqqJG3urHoL2A1 AA8PdAtXRHHN3zW4UQZxD1MZRBEZKYMoR26VQagdqjatqkG5LwBX6DuJWVSrUlOMYIpfUeq0 wip8UncPetw8AlleE03QP+Ac4PswRUAUfHAd4s0saKlXd8bmzWbdhs+iyRNppQfMpgdMj92G PWAm0HJRLmyzxhER9YBxTc+2pxa9aUjTRugBw3qb9bVRwH1/AKB6ltxGuO9ZwH3LR+iRwgoe 0fBwREHlV3TcNqjIjXwkUBr5SJBxn0CPHemxtw1uVRVyZ+CeKnwiKtmq+UZYxU7aKn+ZVxMs UPtzDnBtqK4CFYuY9lT906QeaS04KUxa7mD3RXrMHLbtjIWpfuaoh0iPmYXGWlJUY2bFzlTu Adx1ec6tZqPvh3T1uI0B8rKV9Zxx6+wGwBtr+BmbLIqzkSKJPH+jDKI5Q2UQwUZdsNsWSVWB cuPgvgJF30DKRhRT/IpSZSPKegu07i3AUYaVJuRbShoKnQSOBy4I0RlgNAtl57U8OY4e/tT5 ZdmjP7bpAdMwU8tGWPRUM1smXm/0NusVOmopbHSTqy4gtwruuwBw39IGeiazotDwZHGDy5iK jtOGnrzWkzd6cliRG5EhloL8bdsAUVUh1/x30wa8OyFVMZSV87Qu5xtblXibaYNC6c7RwFlm zM+7sNbyvNjJZ/oUMVwk7CHimI7617zgRD1gKHTHlD9Nd2zQBoRNxQsm4hWMa/yUfIrzp/RS jE7wDgt7YQTu0bl4o4R/h7dbOBXquMeshBdD6l9HeIMogTcMLBNseMiysv7BXmK5vZO0/A8A AP//AwBQSwMEFAAGAAgAAAAhAGI/ESFHAQAAawIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySSU/DMBSE 70j8h8j3xFlaFitJxaKeWgmJViBulv3aRsSLbEPaf4+TtCFQDhztmfd55sn5bC/q4BOMrZQs UBLFKADJFK/ktkDr1Ty8QYF1VHJaKwkFOoBFs/LyImeaMGXgySgNxlVgA0+SljBdoJ1zmmBs 2Q4EtZF3SC9ulBHU+aPZYk3ZO90CTuP4CgtwlFNHcQsM9UBERyRnA1J/mLoDcIahBgHSWZxE Cf72OjDC/jnQKSOnqNxB+07HuGM2Z704uPe2GoxN00RN1sXw+RP8ulw8d1XDSra7YoDKnDPC DFCnTLlQNLiT3C/ZKpnjkdJusabWLf3CNxXw+8Nv87nBk7siPR544KORvshJeckeHldzVKZx Mgnj6zBNV2lMJlMyvX1r3/8x30btL8QxxT+JKckSkk1GxBOgzPHZ9yi/AAAA//8DAFBLAwQU AAYACAAAACEAAXdfWDQBAABvBQAAEAAAAHhsL2NhbGNDaGFpbi54bWxk1MtqhDAYBeB9oe8Q su9ELb1MUWeRNJd9+wBB01HQKEZK+/a1pWPLfzaCX35yAjmkPH2MA3sPS+qnWPH8kHEWYjO1 fTxX/PVF3zxyllYfWz9MMVT8MyR+qq+vysYPjex8H9m2Q0wV79Z1fhIiNV0YfTpMc4jbytu0 jH7dfpezSPMSfJu6ENZxEEWW3Ytx24DXZcOWiqvilrN+OwRnw/dX/Prz7hfRIAbEgjgQCaKK Lf3nDH/pVDTMGBAL4kAkiMqPNB1EgxgQC+JAJIjKHyCdioYZA2JBHIgEUfkdpFPRMGNALIgD kSAqv3Rvv3cQDWJALIgDkSAqh9aBaBADYkEciARRUDoKmoKhYCk4CpKCgrZB2SgYCpaCoyAp KKgZtIyCoWApOAryH4j9qay/AAAA//8DAFBLAwQUAAYACAAAACEA3kEW2YoBAAARAwAAEAAI AWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACckkFv2zAMhe8D9h8M3Rs53ToMgaxiSDf0sGIBknZnTaZjobIkiKyR7NeP ttHUaXvajeR7ePpESV0fOl/0kNHFUInlohQFBBtrF/aVuN/9uPgqCiQTauNjgEocAcW1/vhB bXJMkMkBFhwRsBItUVpJibaFzuCC5cBKE3NniNu8l7FpnIWbaJ86CCQvy/KLhANBqKG+SKdA MSWuevrf0DragQ8fdsfEwFp9S8k7a4hvqe+czRFjQ8X3gwWv5FxUTLcF+5QdHXWp5LxVW2s8 rDlYN8YjKPkyULdghqVtjMuoVU+rHizFXKD7y2u7FMUfgzDgVKI32ZlAjDXYpmasfULK+nfM j9gCECrJhmk4lnPvvHaf9XI0cHFuHAImEBbOEXeOPOCvZmMyvUO8nBOPDBPvhLMd+KYz53zj lfmkV9nr2CUTjiycqp8uPOJ92sUbQ/C8zvOh2rYmQ80vcFr3aaBueZPZDyHr1oQ91M+et8Lw +A/TD9fLq0X5qeR3nc2UfPnL+h8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJ4sbG9rAQAAEAUA ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA tVUwI/QAAABMAgAACwAAAAAAAAAAAAAAAACkAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAkgeU7AQBAAA/AwAAGgAAAAAAAAAAAAAAAADJBgAAeGwvX3JlbHMvd29ya2Jvb2sueG1s LnJlbHNQSwECLQAUAAYACAAAACEAufD/4jcCAACSBAAADwAAAAAAAAAAAAAAAAANCQAAeGwv d29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhAOKfU6EWAQAAaAIAABQAAAAAAAAAAAAAAAAA cQsAAHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAIuCbliTBgAAjhoAABMA AAAAAAAAAAAAAAAAuQwAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAQ4jp 23kDAAAeCgAADQAAAAAAAAAAAAAAAAB9EwAAeGwvc3R5bGVzLnhtbFBLAQItABQABgAIAAAA IQA4D/kx5gcAANgkAAAYAAAAAAAAAAAAAAAAACEXAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54 bWxQSwECLQAUAAYACAAAACEAYj8RIUcBAABrAgAAEQAAAAAAAAAAAAAAAAA9HwAAZG9jUHJv cHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAAXdfWDQBAABvBQAAEAAAAAAAAAAAAAAAAAC7 IQAAeGwvY2FsY0NoYWluLnhtbFBLAQItABQABgAIAAAAIQDeQRbZigEAABEDAAAQAAAAAAAA AAAAAAAAAB0jAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAALAAsAvgIAAN0lAAAAAA== --------------060503070308040102070004-- From nobody Tue Jul 22 19:45:48 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B191A02D8; Tue, 22 Jul 2014 19:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROmwjCUqKY4O; Tue, 22 Jul 2014 19:45:45 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DD81A0217; Tue, 22 Jul 2014 19:45:45 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so696049pdj.8 for ; Tue, 22 Jul 2014 19:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Tk+QaBGpyx9ZmXetUvQ/7ex6DqMs00yHrPOlrSYqwkc=; b=ivm9hYyqstVqDzre08Ly9n7AQzzTdu5xmAU2c7FqyQ1a7FkyNHKdWCyoMHiN1QLWQ+ TStFSr48JPEVKmdnQHaVOvqyhN6wMn+C0+GR0t1EuGKf/+cvLoPaU0VZ4m1yihM7pM9d tgtUq1cCk7aX+raKNrn2qc2VIjYChHC8XFeDMfxyF5LRUSudrAuLLJLLl/8CJRv4qTtC 8+M3TjvDQRn2TPnG9FVAMsJeLrKuaIaINteIv05hzFzs0s/DTUT5k6x/5loKCtSs6Vci 9780jpbjyEOz++LAIxCzFfKyn/12GHKby4kXyCkWuW9XS2RtZyuf4A/xEgadkrRmDdxi w+dg== X-Received: by 10.70.90.161 with SMTP id bx1mr6703964pdb.150.1406083545104; Tue, 22 Jul 2014 19:45:45 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id ia2sm653402pbb.32.2014.07.22.19.45.40 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Jul 2014 19:45:44 -0700 (PDT) From: "Lizhong Jin" To: "'Alexander Vainshtein'" , "'Joel M. Halpern'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <0bbb67f5f192421c8872b351f3f329d4@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <0bbb67f5f192421c8872b351f3f329d4@AM3PR03MB612.eurprd03.prod.outlook.com> Date: Wed, 23 Jul 2014 10:45:37 +0800 Message-ID: <017c01cfa620$32c02050$984060f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKoEM/Y/Vubz9dfpwP/nDHHq79/PAH8SQ9wApok1FgByE30QAMeS+r2AXWTwuqZpIWrQA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/fBfhieHK7F8BNbhzCaAFiK5s0Qs Cc: 'Adrian Farrel' , 'Thomas Clausen' , rtg-chairs@ietf.org, rtg-dir@ietf.org, 'Alia Atlas' Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 02:45:46 -0000 I also agree this is not a good idea. There are many protocol = enhancements draft raised in the WG, and these drafts solve real = problem, but there may not separate requirement document, instead the = requirement is incorporated into the solution draft. Separate = requirements and protocol to different WGs may cause additional = administrative coordination work. Lizhong > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alexander > Vainshtein > Sent: 2014=E5=B9=B47=E6=9C=8822=E6=97=A5 23:07 > To: Joel M. Halpern > Cc: Thomas Clausen; Adrian Farrel; Alia Atlas; rtg-dir@ietf.org; rtg- > chairs@ietf.org > Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- = input >=20 > Joel, and all, > I agree with Joel: administrative separation of requirements and = protocol > work is a highly problematic idea. >=20 > I assume that we would not like to postpone beginning of the WG work = on > the protocol until the requirement document is approved for = publication as > an RFC; but if we run these two in parallel, synchronizing ongoing = changes in > the requirements with changes in the solution would become a complex > cross-WG task. >=20 > And consider the case when in order to address requirements we would > need changes in more than one protocol? CCAMP work on GMPLS provides > lots of examples when requirements to provide a GMPLS-controlled non- > packet network require coordinated changes in RSVP-TE, LMP, OSPF-TE = and > IS-IS-TE... Just planning the sessions of the affected WGs during an = IETF > meeting to avoid conflicts would become highly non-trivial IMO... >=20 > My 2c, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 > > -----Original Message----- > > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. > > Halpern > > Sent: Tuesday, July 22, 2014 5:24 PM > > To: Alia Atlas; Thomas Clausen > > Cc: Adrian Farrel; rtg-chairs@ietf.org; rtg-dir@ietf.org > > Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto = -- > > input > > > > I will not be able to make it to the meeting due to a conflicting = meeting. > > > > Several people have mentioned an idea that apparently was floated, = but > > which I missed if it was on the list. > > THe idea is to separate requirements generation (for various > > activities) from protocol generation to address those requirements. > > Not just separate them in time (we do that) but put them in = different > > working groups. > > > > This strikes me as likely to cause trouble. Whether other folks = have > > succeeded with this or not, the way the IETF works our requirements > > work is neither divorced from the solutions nor is it typically > > complete enough to be fully understood without context. So throwing > > requirements over a wall from one WG to another seems ineffective. > > One could argue that this separation is what KARPO did. But I would > > say that KARP did requirements, GAP Analysis, and then participated = in > > the work on solution development for several iterations. In fact > > several times the work started in KARP, and only moved to the = specific > > protocol group when it was reasonably clear that the problem was = being > addressed. > > > > Just a thought, > > Joel From nobody Tue Jul 22 19:55:40 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED38D1A02D9; Tue, 22 Jul 2014 19:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzOVpB8nasrZ; Tue, 22 Jul 2014 19:55:37 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0A91A028E; Tue, 22 Jul 2014 19:55:37 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id f51so693188qge.18 for ; Tue, 22 Jul 2014 19:55:36 -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=28ytSf1MDHfSgMB9tJQK7dNW87xVXw0kqWbDPXQ6p/I=; b=KKb69+0pKmsWk0w777WZZN/Cmpt43WQ3tHLiBmeO+be99jjmFv1DrLwpDTCtAuD9Ui dn5fI2Nn25J78igvWyYBBsXg2qPXMgaM6ZyuZu0lmuBxGl0+1hYUG6SoyK7Qoc+xds2t i4fMwTFe0Mz5e9uqPk99//eNLpK/VVlnhTOypGDAi43f7BOvRHF45CTH64qA/h+mCiBp 787UhMNaah4FNB/2PQz3cAcnTuIaX3v3LTeTJJjvKCHDrkEoD8FzfbhDFwPoM+ak7tM2 pjq3i6ep+6LuYzVTndEoD7X9GGCTVw/JGERBMfUkTP8w2ME8qBUTlBxRs1zANCbi1rmk pXIQ== X-Received: by 10.224.3.201 with SMTP id 9mr61452321qao.73.1406084136199; Tue, 22 Jul 2014 19:55:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Tue, 22 Jul 2014 19:55:15 -0700 (PDT) In-Reply-To: <53CEEA79.8010300@pi.nu> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> From: "Andrew G. Malis" Date: Tue, 22 Jul 2014 22:55:15 -0400 Message-ID: To: Loa Andersson Content-Type: multipart/mixed; boundary=001a11c24cfc768bc504fed3799f Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/VNjMt9ovxebpfN6Fv_FrhnMUPjo Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 02:55:39 -0000 --001a11c24cfc768bc504fed3799f Content-Type: multipart/alternative; boundary=001a11c24cfc768bc104fed3799d --001a11c24cfc768bc104fed3799d Content-Type: text/plain; charset=UTF-8 Loa, I added one more column, to total all of the RFCs over the period. mpls came in first in terms of total RFCs per capita, and pwe3 came in second. I also agree with your conclusions. Cheers, Andy On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: > Folks, > > I took a look at the performance on rtg wg's. > > The spread sheet list the number of RFC's per working group > between two meeting. I've used the number of people who signed the > blue sheets in Vancouver as some type of average except for roll > that did not meet in Vancouver, where I used the London figure instead. > > Calculated the number of RFCs per person in the room. > > The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. > The highest absolute number of RFC is MPLS (this meeting). > The best trend has MPLS. > > Since I don't care too much about how much noise the non-participating > participants is exposed too, I don't think the a re-org is motivated > by the figures in the spread sheet. > > I guess I would go as far as too say that no arguments presented so far > motivates a re-org of the RTG area. > > Though I'm totally supportive of some well considered re-organization > of working groups, but > > - do it carefully > - at a time when it is optimal for the working groups > - involve the chairs to drive the re-org > - don't break things that work > > /Loa > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a11c24cfc768bc104fed3799d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

I added one more column, to total = all of the RFCs over the period. mpls came in first in terms of total RFCs = per capita, and pwe3 came in second. I also agree with your conclusions.

Cheers,
Andy


On Tue, Jul 22, 2014 at 6:49 PM, L= oa Andersson <loa@pi.nu> wrote:
Folks,

I took a look at the performance on rtg wg's.

The spread sheet list the number of RFC's per working group
between two meeting. I've used the number of people who signed the
blue sheets in Vancouver as some type of average except for roll
that did not meet in Vancouver, where I used the London figure instead.

Calculated the number of RFCs per person in the room.

The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting.
The highest absolute number of RFC is MPLS (this meeting).
The best trend has MPLS.

Since I don't care too much about how much noise the non-participating<= br> participants is exposed too, I don't think the a re-org is motivated by the figures in the spread sheet.

I guess I would go as far as too say that no arguments presented so far
motivates a re-org of the RTG area.

Though I'm totally supportive of some well considered re-organization of working groups, but

- do it carefully
- at a time when it is optimal for the working groups
- involve the chairs to drive the re-org
- don't break things that work

/Loa


--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64

--001a11c24cfc768bc104fed3799d-- --001a11c24cfc768bc504fed3799f Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="statsv2.xlsx" Content-Disposition: attachment; filename="statsv2.xlsx" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hxy25rad1 UEsDBBQABgAIAAAAIQBIZhxhaAEAABAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lNFOwyAUhu9NfIeGW9OyeWGMWbeLqZe6xPkACKcrGQXCYXN7e0/ZXIxZWhd7U9LC+f+PU34ms11j si0E1M6WbFyMWAZWOqXtqmTvy+f8nmUYhVXCOAsl2wOy2fT6arLce8CMqi2WrI7RP3COsoZGYOE8 WJqpXGhEpNew4l7ItVgBvx2N7rh0NoKNeWw12HTyCJXYmJg97ejzgYTKWTY/rGutSia8N1qKSKC8 neVn6wIY7CjcWvWLLj+SFVSZxLHWHm+ODq/UmqAVZAsR4otoiIPvDP90Yf3h3Lroxjzj5qpKS1BO bhrqQIE+gFBYA8TGFGksGqHtH/zTYuRpGA8M0u4vCfdwRPrfwNPz/whJpscQ494ADrzbg2ifcy0C qLcYKBmDA/zU7uGQwsh5TUdk4CacdLv86dwugvNICQ5wOcB31Nrq3JMQhKihM2wnR4r/5Ya/0gbt /aJAnfHm6T6bfgEAAP//AwBQSwMEFAAGAAgAAAAhAFB8TsH2AAAATAIAAAsACAJfcmVscy8ucmVs cyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACMks9KAzEQh++C7xDm3s22gog024sIvYnUBxiT2T/sbiYk07p9e4OguLDWHpPMfPPN j2x30zioE8XUsTewLkpQ5C27zjcG3g7PqwdQSdA7HNiTgTMl2FW3N9tXGlByU2q7kFSm+GSgFQmP Wifb0oip4EA+v9QcR5R8jI0OaHtsSG/K8l7H3wyoZky1dwbi3q1BHc4hT/6fzXXdWXpiexzJy8II Pa/IZIwNiYFp0B8c+3fmvsjCoJddNte7/L2nHknQoaC2HGkVYk4pSpdz/dFxbF/ydfqquCR0d73Q fPWlcGgS8o7cZSUM4dtIz/5A9QkAAP//AwBQSwMEFAAGAAgAAAAhAJbV+XMCAQAAPwMAABoACAF4 bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKyS3WqEMBCF7wt9hzD3Nbr9oZSNe9FS2NvWPkCIo5HVRDLTH9++wYK6sNgbbwJnhpzzzTD7 w0/Xii8M1HinIEtSEOiMLxtXK/goXm8eQRBrV+rWO1QwIMEhv77av2GrOX4i2/QkoosjBZa5f5KS jMVOU+J7dLFT+dBpjjLUstfmpGuUuzR9kGHpAfmZpziWCsKxvAVRDH1M/t/bV1Vj8MWbzw4dX4iQ xEMbBxCFDjWygj+dREaQl+PvNo23OmD5ziFud0mxLK/B3G8JY3Rrnq1u3LyOqbQGkW0J8e3DiSwi zxBTieTYydZgdlvCcLxanEFGKcd3YpBnZ5//AgAA//8DAFBLAwQUAAYACAAAACEAA3AIEP8BAABx AwAADwAAAHhsL3dvcmtib29rLnhtbIxTTY+bMBC9V+p/sHwnNgRINgqs8kHUSFW1are7Z9eYYAXb yDYNq6r/vQM0u1F72dOMPePHe2+G9X2vGvRTWCeNznA4oxgJzU0p9SnD3x8PwRIj55kuWWO0yPCL cPg+//hhfTH2/MOYMwIA7TJce9+uCHG8Foq5mWmFhkplrGIejvZEXGsFK10thFcNiShNiWJS4wlh Zd+DYapKcrE3vFNC+wnEioZ5oO9q2TqcryvZiKdJEWJt+4Up4N03GDXM+aKUXpQZTuBoLuLtIsXI du22kw1Uo3gZppjkryofLGKdNzujQIRzD5L7DpIM06Fr8OFJiot7ezAcUf8sdWkuQxd6uckv4/Wz LH0N34riFOrT3SchT7WHQcTgzwBNbrBH6+AbY0R61PVtsDOEGQ3xCNQhtysJiT2W4YhwfcZZw0HH EMbGmFIK3dxo3lkLdu6g8leR6P1n5/M1RNRZmeFfiySaF8l+HkTJYR5skoIGYTqPgjQ+REm8AxVJ 9Ps6S9X/N0wluTXOVH7GjSLTHGH+nIiei3EdltM65GvVrzaW18c9OjTsBCZHow7gcksojOlmQe/i gBbzJIiXd1GwjIHQLt5HRbIo9sU2eSXUh8n7GP27pCElYXglBiir694PTtbM+kfL+Bn+lq+i2jIH mzaZPpIFbZON5Poq/wMAAP//AwBQSwMEFAAGAAgAAAAhAEtRVTogAQAAggIAABQAAAB4bC9zaGFy ZWRTdHJpbmdzLnhtbHSSy27DIBBF95X6D4i9A7bTPCrbWUS11F1Vpd1TPEmQYKAGp+3flyRSVWFn OecMlwFNtfk2mpyg98piTfMZpwRQ2k7hoaZvuzZbUeKDwE5oi1DTH/B009zfVd4HEs+ir+kxBPfI mJdHMMLPrAOMZm97I0Is+wPzrgfR+SNAMJoVnC+YEQopkXbAEO9dUzKg+hxg+weayqumCs3HvqtY aCp2Lq9ISmFcCuN9EnxKdXFyOILlBDQCIaSdxulRpJOQtrkvKFPWW61T9vy0a8lqTgjJi4wvp/XD xeb5tF1EW2a8mLbLq72RvLrYW8nraOcZHz3kMvSan4eOehT9IvqgpHICgyfvIi7PEPcpHW9ng9Dk td3++04Wd6j5BQAA//8DAFBLAwQUAAYACAAAACEA2n3icqgGAABbGgAAEwAAAHhsL3RoZW1lL3Ro ZW1lMS54bWzsWc+PGzUUviPxP4zmnubXzCRZNVslk6QL3W2rJi3q0UmcjBvPOJpxdhtVlVB7REJC FMQFiRsHBFRqJS7lr1kogiL1X+DZM5nYicNuVz0U1N1LxvO958/v2d+zx5ev3A+pdYzjhLCoaZcv lWwLRyM2JtG0ad8e9Ap120o4isaIsgg37SVO7Cv7H35wGe3xAIfYAvso2UNNO+B8vlcsJiNoRskl NscRvJuwOEQcHuNpcRyjE/Ab0mKlVPKKISKRbUUoBLc3JhMywtZAuLT3V867FB4jnoiGEY37wjXW LCR2PCsLRLJMfBpbx4g2behnzE4G+D63LYoSDi+adkn+2cX9y0W0lxlRvsNWsevJv8wuMxjPKrLP eDrMO3Uc1/FauX8JoHwb1611va6X+5MANBrBSFMuqk+33Wh33AyrgNKfBt+dWqda1vCK/+oW55Yr /jW8BKX+nS18r+dDFDW8BKV4dwvvOLWK72h4CUrx3ha+Vmp1nJqGl6CAkmi2hS65XtVfjTaHTBg9 MMIbrtOrVTLnaxTMhnx2iS4mLOK75lqI7rG4BwABpIiTyOLLOZ6gEcxiH1EyjIl1SKYBF92gPYyU 92nTKNlqEj1aySgmc960P54jWBdrr69f/Pj6xTPr9Yunp4+enz765fTx49NHP6e+NMMDFE1Vw1ff f/H3t59afz377tWTr8z4RMX//tNnv/36pRkI62jN6OXXT/94/vTlN5//+cMTA7wVo6EKH5AQJ9Z1 fGLdYiGMTQZGZ46H8ZtZDAJENAsUgG+D6y4PNOD1JaImXBvrwbsTg4SYgFcX9zSu/SBecGLo+VoQ asAjxmibxcYAXBN9KREeLKKpufN4oeJuIXRs6ttHkZba7mIO2klMLv0AazRvUhRxNMUR5pZ4x2YY G0Z3lxAtrkdkFLOETbh1l1htRIwhGZChNpHWRgckhLwsTQQh1Vpsju5YbUZNo+7gYx0JCwJRA/kB ploYr6IFR6HJ5QCFVA34IeKBiWR/GY9UXDfhkOkppszqjnGSmGxuxDBeJenXQD7MaT+iy1BHxpzM TD4PEWMqssNmfoDCuQnbJ1GgYj9KZjBFkXWTcRP8iOkrRDxDHlC0M913CNbSfbYQ3AblVCmtJ4h4 s4gNubyKmTZ/+0s6QViqDAi7ptchic4U77SH97LdtFsxMS6egw2x3oX7D0p0By2imxhWxXaJeq/Q 7xXa/t8r9K61/PZ1eS3FoNJiM5juuOX+O9y5/Z4QSvt8SfFhInfgCRSgcQ8ahZ08euL8ODYP4KdY ydCBhpvGSNpYMeOfEB70AzSH3XvZFk6mSeZ6mlhzlsCpUTYbfQs8XYRHbJyeOstlccJMxSNBfN1e cvN2ODHwFO3V1iep3L1kO5Un3hUBYfsmJJTOdBJVA4naqlEESZ6vIWgGEnJkb4VFw8CiLtyvUrXF AqjlWYEdkgX7qqbtOmACRnBsQhSPRZ7SVK+yK5P5NjO9K5jaDCjBp41sBqwz3RBcdw5PjC6daufI tEZCmW46CRkZWcOSAI1xNjtF63lovGmuG+uUavREKLJYKDRq9X9jcdFcg92mNtBIVQoaWSdN26u6 MGVGaN60J3B6h5/hHOZOIna2iE7hE9iIx+mCv4iyzOOEd1ASpAGXopOqQUg4ji1KwqYthp+ngUZS QyS3cgUE4Z0l1wBZedfIQdL1JOPJBI+4mnalRUQ6fQSFT7XC+FaaXxwsLNkC0t0PxifWkC7iWwim mFsriwCOSQKfeMppNMcEvkrmQraefxuFKZNd9bOgnENpO6LzAGUVRRXzFC6lPKcjn/IYKE/ZmCGg SkiyQjicigKrBlWrpnnVSDnsrLpnG4nIKaK5rpmaqoiqaVYxrYdVGdiI5cWKvMJqFWIol2qFT6V7 U3IbK63b2CfkVQICnsfPUHXPURAUauvONGqC8bYMC83OWvXasRrgGdTOUyQU1fdWbjfiltcIY3fQ eKHKD3absxaaJqt9pYy0vL5QbxjY8B6IRwe+5S4oT2Qq4f4gRrAh6ss9SSobsETu82xpwC9rEZOm /aDkthy/4vqFUt3tFpyqUyrU3Va10HLdarnrlkudduUhFBYehGU3vTrpwRcnuswuUGT71iVKuPqo dmnEwiKTlyRFSVxeopQr2SWKvIRp2sbbFIuA+jzwKr1GtdH2Co1qq1dwOu16oeF77ULH82udXsd3 643eQ9s6lmCnVfUdr1sveGXfLzheSYyj3ijUnEql5dRa9a7TepjtZyAEqY5kQYE4S4L7/wAAAP// AwBQSwMEFAAGAAgAAAAhAENb0jMHBAAA+g0AAA0AAAB4bC9zdHlsZXMueG1s7Fdbj+I2FH6v1P8Q +T2TBBImQcBqgYm60na10kylvprEAWt8iRwzA1v1v/fYDpCBcplttepDeQj2if35O3dn9GHDmfdC VEOlGKPoLkQeEYUsqViO0W9PuZ8ir9FYlJhJQcZoSxr0YfLzT6NGbxl5XBGiPYAQzRittK6HQdAU K8JxcydrIuBNJRXHGqZqGTS1IrhszCbOgl4YDgKOqUAOYciLW0A4Vs/r2i8kr7GmC8qo3los5PFi +GkppMILBlQ3UYyLHbadnMBzWijZyErfAVwgq4oW5JRlFmQBIE1GYs1zrhuvkGuhwVp7kefefCpB OIiR55SeyRJohHdhGKJgMgra7ZNRJcUBpQ8UDdPhs5CvIjevHLRZNRk137wXzEASGYxCMqk8DRYG ZCsRmBO3YoYZXShqllWYU7Z14p4RWKe06zgFE1lC7gT3XJtVF86yKvyow/4lzQKjWgPmoIztvRaD 14xgMoL40USJHCZeO37a1mBYAaHuDGTXXVm9VHgb9ZLbNzSS0dKwWM667rxHnqYmrsK7JINfP80G vSyNwji14It2ORUl2RAINYg0cFrQUQNmjuwVymcYQOTuGNwDgTQapGmaxf0ojm0UvYeBJQK2X0hV Qnnp5owTTUaMVBoUUHS5Mv9a1vBcSK0hFyejkuKlFJjBMNjtaAcAWxDGHk0J+r3aYydg003VyUUo ZiYCTFqaITizHTo8NwH8c5uis5s8XNds+2XNF0TltsLZI6w0h3MOs6nV/zD/yOhScGL9jBzMVyU1 KbStwDbNzvHp/cf4/G8fiCsTn91odLHZCcv0u8LS21RX4/N8UO93uwjrBJ1pWtAoXAx6K6noN0gR 02EKCEqikLkNaFp0Ja8K109kA6XJFuZgU53PmR/EyVj9RhqQNd18PzKNy1ar15u0M7l2WjugWV/A elsPIDs69eDWEy6zfd8J7V3kWgU8ssjxGccF8u8tA35/h2V2SQNp0qnlbyr5Pqc8c+sYo1wyJl9J 6f0CPVoxKp7h4mRzxJhsTRm0LpMxGfJWtCyJuc6a5LwdB9rfO3BOaIC/O9vh3nyRxsl2E1oHLa5t /2KaDttZwBj/sPeoJoGFy82hS9q32lyRbf/c2xwwSlLhNdNP+5djdBj/Skq65mDrdtVX+iK1hRij w/izaebRwBgeCsbnBm6w8O+tFR2jPx6m99n8Ie/5aThN/bhPEj9LpnM/iWfT+TzPwl44+7NzY/8H 93X7XQFVKoqHDYNbvWqVbck/HmRj1Jk4+ramA+0u96w3CD8mUejn/TDy4wFO/XTQT/w8iXrzQTx9 SPKkwz35Pu5RGESR+ygy5JOhppxArO98tfNQVwpOgukFJYKdJ4Jm/9E2+QsAAP//AwBQSwMEFAAG AAgAAAAhADz9TxAwCgAA+ygAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWysWltv47gVfi/Q /yAIfWgfIovUzTYSLyaSLVmd6Qx2urvPii0nwtqWKymX2aL/vYcXSSRFOQqwBuzY50oenk+HPOHt T2+no/GSV3VRnu9MZNmmkZ935b44P96Zv/x7czM3jbrJzvvsWJ7zO/NHXps/rf76l9vXsvq9fsrz xgAL5/rOfGqay3I2q3dP+SmrrfKSn4FzKKtT1sDP6nFWX6o821Ol03GGbdufnbLibDILy2qKjfJw KHZ5VO6eT/m5YUaq/Jg1MP76qbjUrbXTboq5U1b9/ny52ZWnC5h4KI5F84MaNY3Tbrl9PJdV9nCE eb8hN9u1tumPgflTsavKujw0FpibsYEO57yYLWZgaXW7L2AGJOxGlR/uzE94+RU75mx1SwP0a5G/ 1sJ3o8kevufHfNfke1gn02jKy+f80IT58UiUTYMsyENZ/k40tyBjg4+aahAf2a4pXvJW2oVF/Q93 6xKfs86p+L0dwIYu4rfKeMjqPCyPvxX75glGAcmyzw/Z87HpiXNr7mDbQdjrmD+Xr0lePD41oAKe afSW+x9RXu9gDclIYQS78gju4NM4FZCJMKFT9kb/vnJvnoV81/aJ4d1z3ZSndhhcnSk6XHEBEWGK Cws0HvK62RRkBDrtGfNOgxBlTba6rcpXAxIShlFfMpLeaInADJkDnkNkd4R7T9jUJJBroL6sUHA7 e4EY7rhIqBGxZZFII4JkkbVGBMsiG42II4vEGhFXFkk0Ip4sstWI+LJIykTgs4/LXBb5ZytClp7E 8rNK+KIS/qUSvgqEGSxYt2okvYVV4x4+EfKdCQnSjUpZiftWQruSIlMJfiTy1LUTeYrDzRVefIWX iDzF31bkKf5SF5L0sPr+y5e/h+5y6/7jdnYgc+2zQIojJLwujoRM4tgu3b1KCBnBo85Cd/a3e3BA HdkWQoHvBrY3n2PHwwtXGX0kqNJ1esqqfG+yZ2TkLbeEX9CnWyQa9qzOIHewvlEWaT1impmDybys lHBtPqwRf1gjeV9jwtxoWO5MGnExbONzS5lflhCpGErb4ivTr1SHXSk9fH16ALkDmLK69z59SLqL ziDFfsjIinDEqOoqaqkbrYVYK5swqvJw3GotpITKAeMvt34LGNSPSgpJoA1JSMh3ZsDw4AMe4IFJ 8YAt27XnyHew7zm2jzAapG0kKItLS8t3FCy3hA+IQOYqEk27lmQYu3hgej1impmjiJhgZfO+lQnT jN+3MmEsyftWfAth7LrzRbDwFmju+P4gLjSkfL3EkAtxmTCjlI2FI0xcGkCYOIDAcfsCKqUT2Xxr Chkhy4WsT0e2MWkl6MNdeaqFIlPhRVd46yu8jchTcBxf4SVXeFuRp4wzJXswjsv5cjtvcdmDWooj bAZ1cSRkqZCphJAReCGbA3BhG8MKmfwEiwRBMWMYSBfLLeEDSDGA9IqZ9YgZpqotUe9rYMuzpdfw GRP/KVaSP8UKDdVIKcNkzzEo0ynzy4Emhjew3IX0CkSsSylCDjO6HCH0rpz16cVgBkwynkDJ+JDT FXKkJ685WUnxjZ4c640knKyMcKsnp5TM8YPsJYi1COpLsxweODdpwhMiQr8zWZmEeQNEEEyEYgRZ UNtczw5sF2MPdnvDxItE/SFwEIKhEQ8AHQeg82H76zH7zKIumzYfV4knqEwIRjLBjGvxUCLsB77t +Y6Y0TQrWcT4mogxFeY8wUzKR8NhJYce9vGtf2duY9jBjOUNOaNpShhiZzfxMNYfQji4WhECMV85 hYadAcJVyl8kMRUUriXmAHSiU4UZS5qK2URiKppbialopsDsihnCkPG4BWM/aRmMEDZtUAldKmhI pYScwksawgSwED4KWMeyA3+BnfYz0AGWWRycNFilQw4Mn0gAYCFxYCFE+8jynLnro+7TGyTvWhyf mry0VTV4/G8+rhJPUJkw2GSCmUEmjMSPRYw+kCZ4TrnnFpxSmANLXET4fqXqkWaBDp5A76pen4Uc mMTry8pR6CE097RgZGQl69dcWonPRk+O9eRET95ysuIypeS26kH/A73XACEtP014QkrvDnSInJ5R 2+LwrAC5eO51nzoQscM3PRCKSc5BBG0O6gFABDiLZPvYEmxTPxoQjdgnSeZp91AbcUrikMZV4o+r JB9XYZEYOYzxuUwISco9t4CRlox0paQlw323Un7wjrQ8EKHLJ7L+RMdB04oQiAw3jCJX2cNFnXUN utbXmBuJqZiNJaaC5URiKpV5KzH7UNGJpsDsqxn0TFDXNMF9b1yOKjkodw8hsqWmlj4hdoAWGo0D SsgpbTkjp2zUNlcmbHIiUV9Me45EaK9QCcANTAtWQrQPaQf7Hht1u9zhXmw9Zp/AymdInGBmM8HM hNnGE8wE0JGStpiLweMlmWDGs3yn3RnSCGm6LBPMEGTKG80+h3i6SV0WeYFsSxoCHEV6VMoZSFoN ugwEelcGFc/3iPQgAMvK5jPkdKWwRZys1KS1Xnqjl4710oleequXTim5LYPQPUHvtU8QOWAPwxNS el8GyckbjTVIRFkN0KBFQiUAFlAVIViiLQTrKL8GObkes0+AFoyUPNY3GFRhQWWC5/jjnpMJKhM8 s4iNlEb9nFPuuS2DUphd+Aer9HLFMEuAwVK3pH9kU7pcCJX6cN+JEPC4CkpCmas02SSmAru1xFRQ tpGYis9YYipmE4mpmN1KTEUzBWZXCDH0WHDXYxn77wGWmixCVFmTRSiEVFI86YWcwgshJo0YDBNl zUpLGXgkSg/RiKHtQiUAO/CQi1RrtrJbWI+ZI0iat1Xu3S7kZoKZwdqx0AyOo4Jn21LHm0xwNKFr ymI00qrk0x46T7lzDkE1tv0uTQac1EcRUgPoXYXqezBsz4lJYwFApixXyOlKLCM9ea0nb/TkmJMV MCScrOThVm8kpWReoTB0RHDXERkLDzlVayoU3KghG3P+nzdMjskYhqZt4YuyGkxAZ4NKQEovCCau 2VqP2SJpudBXo4+rxBNUXMuVX8N9WDLBDIa2o/QabnVZdEaqkX7OKffcQkEKqW9JtQh+DKsRu7bE buxcssf8S1Y9FufaOMLNKLgjYMHesGIXj+h3uDNFqXA6figbuEHU/nqCe2k5XEKBDaNpHMqyaX9A P4bY/Z43zxejrAq4r0Svmt2Zl7Jqqqxo4E4Q0P8ogXGMLrC8LlxqWPgBXgAy4WJdU+yGDDBbkLtl +X5dVWUFF5/En+3drNQ10sBIF0to1xvQJYQ3UJAP77kB5QXe4IPcsHs+Zj9n50e4p4ZIcmmNecsU NEERIXg78PbgDfbRAgzBY5QboveZNEZnolUYcf7WfK4b+td4rmDi/4XbWTYOHHTzyb+3bzzyAXt3 +yYIMLoPQnvh2/b/2jt0J7jcpVwZ1F6gO2W7Wf62y+mFwTm7MLi6Pb0tv33+1fhS7mHOsBf5es6/ wTrR7799h4jTrxAK0IUxkk862Nlre21x9X8AAAD//wMAUEsDBBQABgAIAAAAIQC+FBBtUgEAAGoC AAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACMkstuwyAURPeV+g8Wexs/kj6Q7agPZZVIleqqVXcIbhJUGxDQOvn7YjtxHbWLLmHmHmauyBf7 pg6+wFihZIGSKEYBSKa4kNsCvVTL8AYF1lHJaa0kFOgAFi3Ky4ucacKUgSejNBgnwAaeJC1hukA7 5zTB2LIdNNRG3iG9uFGmoc4fzRZryj7oFnAax1e4AUc5dRR3wFCPRHREcjYi9aepewBnGGpoQDqL kyjBP14HprF/DvTKxNkId9C+0zHulM3ZII7uvRWjsW3bqM36GD5/gt/Wq+e+aihktysGqMw5I8wA dcqUK0WDO8n9kq2SOZ4o3RZrat3aL3wjgN8fSm800AZrWgub49+6B/c9BjrwwCcjQ4+T8po9PFZL VKZxMgvj6zBNqzQmszmZ3753z5/Nd0mHi+YY4j/ErIpTMs9IMpsQT4Cyz33+O8pvAAAA//8DAFBL AwQUAAYACAAAACEAbmThymABAADRBgAAEAAAAHhsL2NhbGNDaGFpbi54bWxk1V1LwzAUBuB7wf8Q cu+6VJ0frNtFvr3WHxC6uBbadDRF9N8bhQ09700hT5OTN/SEbvef48A+4pz7KTVcrNacxdROhz4d G/72am4eOctLSIcwTCk2/Ctmvt9dX23bMLSyC31ipULKDe+W5fRcVbnt4hjyajrFVN68T/MYljKc j1U+zTEcchfjMg5VvV5vqrEU4Ltty+aGvzxw1pcMnA0/z+rMJcEvX6CuQW5BykHIqlL4vwioLJ5g zgbkHPOSR9zBnHsQyCwgs4DMAjJDQMgHYWgWVdOdNYgBsSAOxINIEFXTM2kQA2JBHIgHkSAKvrAG MSAWxIF4EAmiBO0dDWJALIgD8SASRAnaCRrEgFgQB+JBJIiCftcgBsSCOBAPIkEU3CQNYkAsiAPx IBJE0VurKRgKloKj4ClICgq6jYKhYCk4Cp6CpKCgzSgYCpaCo+ApyD9QXX5Gu28AAAD//wMAUEsD BBQABgAIAAAAIQDXU5wwkAEAABsDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySTW/bMAyG7wP2HwzdGzldMQyBrKJIO/SwYgGSdmdNpmOh siSIrJHs14+2kcbZdtqNHy9ePqKobg+dL3rI6GKoxHJRigKCjbUL+0o8775efREFkgm18TFAJY6A 4lZ//KA2OSbI5AALtghYiZYoraRE20JncMHtwJ0m5s4Qp3kvY9M4C/fRvnUQSF6X5WcJB4JQQ32V 3g3F5Ljq6X9N62gHPnzZHRMDa3WXknfWEL9SPzmbI8aGiidjXaCIbfFwsOCVnMsUc27BvmVHR10q OU/V1hoPax6hG+MRlDwX1COYYX0b4zJq1dOqB0sxF+h+8QKvRfHTIAxglehNdiYQAw6yKRljn5Cy /hHzK7YAhEqyYCqO4Vw7j92NXo4CDi6Fg8EEwo1LxJ0jD/i92ZhM/yBezolHhol3wtkOfNPMOd/4 ZJ70h/c6dsmEIzfeo28uvOJz2sV7Q3Ba52VRbVuToeYfOPXPBfXIm8x+MFm3JuyhPmn+bgxn8DLd ul7eLMpPJf/rrKbk+ar1bwAAAP//AwBQSwECLQAUAAYACAAAACEASGYcYWgBAAAQBQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBQfE7B9gAAAEwC AAALAAAAAAAAAAAAAAAAAKEDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCW1flzAgEAAD8D AAAaAAAAAAAAAAAAAAAAAMgGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAI AAAAIQADcAgQ/wEAAHEDAAAPAAAAAAAAAAAAAAAAAAoJAAB4bC93b3JrYm9vay54bWxQSwECLQAU AAYACAAAACEAS1FVOiABAACCAgAAFAAAAAAAAAAAAAAAAAA2CwAAeGwvc2hhcmVkU3RyaW5ncy54 bWxQSwECLQAUAAYACAAAACEA2n3icqgGAABbGgAAEwAAAAAAAAAAAAAAAACIDAAAeGwvdGhlbWUv dGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBDW9IzBwQAAPoNAAANAAAAAAAAAAAAAAAAAGETAAB4 bC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhADz9TxAwCgAA+ygAABgAAAAAAAAAAAAAAAAAkxcA AHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbFBLAQItABQABgAIAAAAIQC+FBBtUgEAAGoCAAARAAAA AAAAAAAAAAAAAPkhAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQBuZOHKYAEAANEG AAAQAAAAAAAAAAAAAAAAAIIkAAB4bC9jYWxjQ2hhaW4ueG1sUEsBAi0AFAAGAAgAAAAhANdTnDCQ AQAAGwMAABAAAAAAAAAAAAAAAAAAECYAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAsACwC+AgAA 1igAAAAA --001a11c24cfc768bc504fed3799f-- From nobody Wed Jul 23 03:55:55 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0F21A0422; Wed, 23 Jul 2014 03:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JrKqv6-y2Pl; Wed, 23 Jul 2014 03:55:50 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DE14E1A0453; Wed, 23 Jul 2014 03:55:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.162.238; From: "Susan Hares" To: "'Giles Heron \(giheron\)'" , "'Andrew G. Malis'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> In-Reply-To: <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> Date: Wed, 23 Jul 2014 06:55:47 -0400 Message-ID: <011801cfa664$a9573980$fc05ac80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0119_01CFA643.224B8CF0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKoEM/Y/Vubz9dfpwP/nDHHq79/PAH8SQ9wApok1FgByE30QAMeS+r2AWPA0fICCrwfdwIpoaPdmYP6ndA= X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/czTt_n0ntUTJEm-bq0AbFKUrieE Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org, 'Loa Andersson' Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 10:55:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0119_01CFA643.224B8CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Giles: The performance that IETF has utilized for its ADs, IETF chairs, and WG groups for 20 years has been: Quantitative: 1) RFC published 2) WG groups formed and completed 3) Administrative effectiveness (AFI/SAFIs, early code adoption, ports assigned. ) 4) Number of authors and demographics on authors 5) Statistics on the timing of RFCs and the timing of WG forming 6) Statistics on attendance in WG/ IETF Please note, I do know of a statistically valid analysis of the correlation between #6 an #1. If you do, I would be interested. Qualitatively 1) Technologies described in RFCs get deployed. 2) IETF is collaborative (at IESG, at WG), 3) People want to come (from surveys) The "people" want to come falls into a qualitative experience that says "important to learn about the technology". http://www.arkko.com/tools/docstats.html has document statistics. If you want to propose a new metric it can be useful going forward, but unless it is built on the data kept by the datatracker, we do not have the past trends to defend it. You could also use the mail list information, but we would need to use a long-running group to get a valid statistics. Sue From: Giles Heron (giheron) [mailto:giheron@cisco.com] Sent: Wednesday, July 23, 2014 6:32 AM To: Andrew G. Malis Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad I'm not sure that how helpful the exercise is? Is performance really related to how many people show up? There's no way after all to determine what fraction of attendees are active participants vs "IETF tourists". And of course we're supposed to do more work outside meetings than in them. At any rate to be meaningful at all we need to weight the results by length of WG meeting as time is the constraint we're trying to optimise for here (I think!). I counted WG meeting durations in minutes (since L2VPN was 2 hours 10 mins - and I didn't have the time to type a recurring decimal). Couldn't find ROLL on the Vancouver Agenda though - so I used their London duration. Of course then the RFCs per minute were all rather low. In honour of the recent World Cup I went for RFCs per football match (counting only the players and the playing minutes - no allowance for referees, half-time, injury time or extra time). the results show PWE3 a mile ahead of the rest, followed by BFD, then MPLS, then a cluster of WGs with very similar productivity (L2VPN leading those by a nose, but who am I to brag?) with L3VPN and then PCE (possibly the victim of the recent SDN hype) bringing up the rear. like I say, does this really mean anything? Can I have the last half hour of my life (or rather 1/66 of a football match) back? Giles On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: > Loa, > > I added one more column, to total all of the RFCs over the period. mpls came in first in terms of total RFCs per capita, and pwe3 came in second. I also agree with your conclusions. > > Cheers, > Andy > > > On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: > Folks, > > I took a look at the performance on rtg wg's. > > The spread sheet list the number of RFC's per working group > between two meeting. I've used the number of people who signed the > blue sheets in Vancouver as some type of average except for roll > that did not meet in Vancouver, where I used the London figure instead. > > Calculated the number of RFCs per person in the room. > > The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. > The highest absolute number of RFC is MPLS (this meeting). > The best trend has MPLS. > > Since I don't care too much about how much noise the non-participating > participants is exposed too, I don't think the a re-org is motivated > by the figures in the spread sheet. > > I guess I would go as far as too say that no arguments presented so far > motivates a re-org of the RTG area. > > Though I'm totally supportive of some well considered re-organization > of working groups, but > > - do it carefully > - at a time when it is optimal for the working groups > - involve the chairs to drive the re-org > - don't break things that work > > /Loa > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > ------=_NextPart_000_0119_01CFA643.224B8CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Giles:

 

The performance that IETF has utilized for its ADs, IETF chairs, and = WG groups for 20 years has been:

 

Quantitative:

1)      = RFC published

2)      = WG groups formed and completed

3)      = Administrative effectiveness (AFI/SAFIs, early code adoption, ports = assigned… )

4)      = Number of authors and demographics on authors =

5)      = Statistics on the timing of RFCs and the timing of WG forming =

6)      = Statistics on attendance in WG/ IETF

 

Please note, I do know of a statistically valid analysis of the = correlation between #6 an #1.  If you do, I would be interested. =

 

Qualitatively

1)      = Technologies described in RFCs get deployed.

2)      = IETF is collaborative (at IESG, at WG),

3)      = People want to come (from surveys) =   

 

The “people” want to come falls into a qualitative = experience that says “important to learn about the = technology”.

 

http://www.arkko.com/to= ols/docstats.html  has document statistics. =

 

If you want to propose a new metric it can be useful going forward, = but unless it is built on the data kept by the datatracker, we do not = have the past trends to defend it.   You could also use the = mail list information, but we would need to use a long-running group to = get a valid statistics.

 

Sue

From:= = Giles Heron (giheron) [mailto:giheron@cisco.com]
Sent: = Wednesday, July 23, 2014 6:32 AM
To: Andrew G. = Malis
Cc: Loa Andersson; rtg-dir@ietf.org; = rtg-chairs@ietf.org
Subject: Re: [RTG-DIR] what is so = bad

 

I'm not = sure that how helpful the exercise is?  Is performance really = related to how many people show up?  There's no way after all to = determine what fraction of attendees are active participants vs = "IETF tourists".  And of course we're supposed to do more = work outside meetings than in them.

At any rate to be meaningful = at all we need to weight the results by length of WG meeting as time is = the constraint we're trying to optimise for here (I think!).  I = counted WG meeting durations in minutes (since L2VPN was 2 hours 10 mins = - and I didn't have the time to type a recurring decimal).  = Couldn't find ROLL on the Vancouver Agenda though - so I used their = London duration.  Of course then the RFCs per minute were all = rather low.  In honour of the recent World Cup I went for RFCs per = football match (counting only the players and the playing minutes - no = allowance for referees, half-time, injury time or extra = time).

the results show PWE3 a mile ahead of the rest, followed = by BFD, then MPLS, then a cluster of WGs with very similar productivity = (L2VPN leading those by a nose, but who am I to brag?) with L3VPN and = then PCE (possibly the victim of the recent SDN hype) bringing up the = rear.

like I say, does this really mean anything?   Can = I have the last half hour of my life (or rather 1/66 of a football = match) back?

Giles




On 23 Jul 2014, at 03:55, Andrew = G. Malis <agmalis@gmail.com> = wrote:

> Loa,
>
> I added one more column, to = total all of the RFCs over the period. mpls came in first in terms of = total RFCs per capita, and pwe3 came in second. I also agree with your = conclusions.
>
> Cheers,
> Andy
>
> =
> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson <loa@pi.nu> wrote:
> = Folks,
>
> I took a look at the performance on rtg = wg's.
>
> The spread sheet list the number of RFC's per = working group
> between two meeting. I've used the number of = people who signed the
> blue sheets in Vancouver as some type of = average except for roll
> that did not meet in Vancouver, where I = used the London figure instead.
>
> Calculated the number = of RFCs per person in the room.
>
> The highest figure has = BFD 0.12 RFCs prior to the IETF84 meeting.
> The highest absolute = number of RFC is MPLS (this meeting).
> The best trend has = MPLS.
>
> Since I don't care too much about how much noise = the non-participating
> participants is exposed too, I don't think = the a re-org is motivated
> by the figures in the spread = sheet.
>
> I guess I would go as far as too say that no = arguments presented so far
> motivates a re-org of the RTG = area.
>
> Though I'm totally supportive of some well = considered re-organization
> of working groups, but
> =
> - do it carefully
> - at a time when it is optimal for = the working groups
> - involve the chairs to drive the = re-org
> - don't break things that work
>
> = /Loa
>
>
> --
>
>
> Loa = Andersson          &nbs= p;            = ; email: loa@mail01.huawei.com
> = Senior MPLS = Expert           &= nbsp;           &n= bsp;  loa@pi.nu
> Huawei = Technologies (consultant)     phone: +46 739 81 21 = 64
>
> = <statsv2.xlsx>

------=_NextPart_000_0119_01CFA643.224B8CF0-- From nobody Wed Jul 23 04:24:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0221A038A; Wed, 23 Jul 2014 04:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM-iICZKAkto; Wed, 23 Jul 2014 04:24:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F170B1A037D; Wed, 23 Jul 2014 04:24:18 -0700 (PDT) Received: from CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) by CO2PR05MB730.namprd05.prod.outlook.com (10.141.228.15) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 11:24:16 +0000 Received: from CO2PR05MB732.namprd05.prod.outlook.com ([10.141.228.22]) by CO2PR05MB732.namprd05.prod.outlook.com ([10.141.228.22]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 11:24:16 +0000 From: John Scudder To: "Giles Heron (giheron)" Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf9IM04b0e02pk+dfc3mGMfie5utSuGAgAB/voD//7KzgIAAAgqAgAAF68M= Date: Wed, 23 Jul 2014 11:24:15 +0000 Message-ID: <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com>, <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> In-Reply-To: <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [206.47.221.210] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(377454003)(43544003)(189002)(199002)(83072002)(50986999)(85852003)(81342001)(83716003)(93886003)(66066001)(76176999)(36756003)(31966008)(20776003)(106356001)(107046002)(76482001)(54356999)(85306003)(77982001)(99286002)(92726001)(74502001)(95666004)(105586002)(19580395003)(21056001)(86362001)(79102001)(101416001)(80022001)(87936001)(19580405001)(74662001)(33656002)(2656002)(64706001)(83322001)(46102001)(81542001)(106116001)(4396001)(82746002)(92566001)(110136001)(99396002)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB730; H:CO2PR05MB732.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/O-tCxbthCdzl30Dbz_BAKkQ6kmw Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , "Andrew G. Malis" , Susan Hares , Loa Andersson Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 11:24:20 -0000 On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)" wr= ote: > I think my point was rather that I'm not sure metrics are what we should = be concentrating on in this debate. Numbers can be made to say just about = anything, after all ;) That was more-or-less the point I had been waiting to make when we ran out = of time yesterday. That, plus, bad (or the wrong) metrics are worse than no= metrics, so take care.=20 --John= From nobody Wed Jul 23 04:30:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFE81A0453 for ; Wed, 23 Jul 2014 04:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVPKQfieEIrg for ; Wed, 23 Jul 2014 04:30:19 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id C6F191A0380 for ; Wed, 23 Jul 2014 04:30:19 -0700 (PDT) Received: (qmail 12714 invoked by uid 0); 23 Jul 2014 11:30:12 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 23 Jul 2014 11:30:12 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id VtW51o00m2SSUrH01tW82P; Wed, 23 Jul 2014 11:30:11 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Mp07CAuinD0A:10 a=Lhyv8l1xRe4A:10 a=HFCU6gKsb0MA:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=9SVZ0dGN6bwA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=pGLkceISAAAA:8 a=ABeY7kuGAAAA:8 a=RFcmiRFDnyN0AowMFKEA:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=chC_agHSu74A:10 a=Xked-Dsx8X5pAU4obd8A:9 a=ZTA9Mu2krr5b7Yn9:21 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=8YIAnvFOpSxzngQNLtiIO3M7ZQj28Cti0a+x+NFdjz4=; b=jpruGnjg3Kabf2scNIZ3jMl+mN8svtg++b2XBgkuVDlq8Sh5cx7vK6467P48U1j40QyFZDtnUwcPdpI/0XpKZG+XMbfNNoI2iUKJP96HbceINSH8KcSEJ0s2usSR91m9; Received: from [31.133.146.239] (port=32810) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9ukI-0007Mc-TK; Wed, 23 Jul 2014 05:30:07 -0600 From: Lou Berger To: Alia Atlas , "Joel M. Halpern" Date: Wed, 23 Jul 2014 07:30:05 -0400 Message-ID: <14762fc3690.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.4.0.30 (build: 2100451) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14762fc437d1b2227e942d14be8" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 31.133.146.239 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/jylekvPJ83jzN2J2zRnFCZwwG3Y Cc: Adrian Farrel , Thomas Clausen , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Consultative Session on RTG Reorg in Toronto -- input X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 11:30:21 -0000 This is a multi-part message in MIME format. ------------14762fc437d1b2227e942d14be8 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Alia/Adrian, While this point didn't come up directly yesterday, perhaps due to Joel's absence, there is a case in your plan. In particular TE routing occurs in the core protocol group (s) while requirements come from the new TE group. As others have mentioned, we've had very good success in developing TE routing extensions together with requirements, framework and signaling in ccamp, with good cooperation and support of the related IGP WG. If you do decided to go a head with the reorganization as described yesterday, I think excluding TE routing solutions from the te 'requirements and signalling' group qualifies as the issue raised by Joel. Lou On July 22, 2014 11:10:50 AM Alia Atlas wrote: > Joel, > > First I've heard of that idea... > > Alia > > > On Tue, Jul 22, 2014 at 10:24 AM, Joel M. Halpern > wrote: > > > I will not be able to make it to the meeting due to a conflicting meeting. > > > > Several people have mentioned an idea that apparently was floated, but > > which I missed if it was on the list. > > THe idea is to separate requirements generation (for various activities) > > from protocol generation to address those requirements. Not just separate > > them in time (we do that) but put them in different working groups. > > > > This strikes me as likely to cause trouble. Whether other folks have > > succeeded with this or not, the way the IETF works our requirements work is > > neither divorced from the solutions nor is it typically complete enough to > > be fully understood without context. So throwing requirements over a wall > > from one WG to another seems ineffective. One could argue that this > > separation is what KARPO did. But I would say that KARP did requirements, > > GAP Analysis, and then participated in the work on solution development for > > several iterations. In fact several times the work started in KARP, and > > only moved to the specific protocol group when it was reasonably clear that > > the problem was being addressed. > > > > Just a thought, > > Joel > > ------------14762fc437d1b2227e942d14be8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Alia/Adrian,

While this point didn't come up directly yesterday, perhaps due to Joel's absence, there is a case in your plan. In particular TE routing occurs in the core protocol group (s) while requirements come from the new TE group.

As others have mentioned,  we've had very good success in developing TE routing extensions together with requirements,  framework and signaling in ccamp, with good cooperation and support of the related IGP WG.

If you do decided to go a head with the reorganization as described yesterday,  I think excluding TE routing solutions from the te 'requirements and signalling' group qualifies as the issue raised by Joel.

Lou

On July 22, 2014 11:10:50 AM Alia Atlas <akatlas@gmail.com> wrote:

Joel,

First I've heard of that idea...

Alia


On Tue, Jul 22, 2014 at 10:24 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
I will not be able to make it to the meeting due to a conflicting meeting.

Several people have mentioned an idea that apparently was floated, but which I missed if it was on the list.
THe idea is to separate requirements generation (for various activities) from protocol generation to address those requirements.  Not just separate them in time (we do that) but put them in different working groups.

This strikes me as likely to cause trouble.  Whether other folks have succeeded with this or not, the way the IETF works our requirements work is neither divorced from the solutions nor is it typically complete enough to be fully understood without context.  So throwing requirements over a wall from one WG to another seems ineffective.  One could argue that this separation is what KARPO did.  But I would say that KARP did requirements, GAP Analysis, and then participated in the work on solution development for several iterations.  In fact several times the work started in KARP, and only moved to the specific protocol group when it was reasonably clear that the problem was being addressed.

Just a thought,
Joel

------------14762fc437d1b2227e942d14be8-- From nobody Wed Jul 23 04:35:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E7F1A03A4; Wed, 23 Jul 2014 03:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8sL9ErBvtOj; Wed, 23 Jul 2014 03:32:29 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C971A03B9; Wed, 23 Jul 2014 03:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24668; q=dns/txt; s=iport; t=1406111548; x=1407321148; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jIHH1Eg4GDV+CvK3LCOaIvOsBD7Dp54Y1jOf588+QZw=; b=WunA4E761huz+thPSDD9f9e1EKRnTinikWemM7gsGCzf3QJL5uEsTIYS vY1/n+nBN+EOjeMP4dDtXDqoUu3b58tyVlzYzsrwvZ9GN34kbfIzybLe8 CZ/57iGOBNlBV8S+pGAYyBA6MHEEbt7miXk5GqL8L8L7LL7vRApAA/bs6 U=; X-Files: statsv3.xlsx : 11761 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIOOz1OtJA2I/2dsb2JhbABZgkdHgSkEzyIBgQ0WdoQDAQEBAwFrDgUJAgIBCBguAhkGESUCBA4FDguIFQMJCLgGDYccFwSFIYd5gRU2DgMBJBEbB4MugRgBBJJBgUWFHYIDjhiGHINGbIEMOQ X-IronPort-AV: E=Sophos;i="5.01,716,1400025600"; d="xml'?rels'?scan'208,217,72,48?xlsx'208,217,72,48,72,48";a="63287398" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 23 Jul 2014 10:32:27 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NAWRX0012254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 10:32:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 05:32:27 -0500 From: "Giles Heron (giheron)" To: "Andrew G. Malis" Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf9IM04b0e02pk+dfc3mGMfie5utSuGAgAB/voA= Date: Wed, 23 Jul 2014 10:32:27 +0000 Message-ID: <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.60.143.153] Content-Type: multipart/mixed; boundary="_004_0C3E597932FE4F5B971E81F3D93173A2ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/iE0Tdl6en6NoSjWr6JkbO31p6xk X-Mailman-Approved-At: Wed, 23 Jul 2014 04:35:15 -0700 Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Loa Andersson Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 10:32:30 -0000 --_004_0C3E597932FE4F5B971E81F3D93173A2ciscocom_ Content-Type: multipart/alternative; boundary="_000_0C3E597932FE4F5B971E81F3D93173A2ciscocom_" --_000_0C3E597932FE4F5B971E81F3D93173A2ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure that how helpful the exercise is? Is performance really relat= ed to how many people show up? There's no way after all to determine what = fraction of attendees are active participants vs "IETF tourists". And of c= ourse we're supposed to do more work outside meetings than in them. At any rate to be meaningful at all we need to weight the results by length= of WG meeting as time is the constraint we're trying to optimise for here = (I think!). I counted WG meeting durations in minutes (since L2VPN was 2 h= ours 10 mins - and I didn't have the time to type a recurring decimal). Co= uldn't find ROLL on the Vancouver Agenda though - so I used their London du= ration. Of course then the RFCs per minute were all rather low. In honour= of the recent World Cup I went for RFCs per football match (counting only = the players and the playing minutes - no allowance for referees, half-time,= injury time or extra time). the results show PWE3 a mile ahead of the rest, followed by BFD, then MPLS,= then a cluster of WGs with very similar productivity (L2VPN leading those = by a nose, but who am I to brag?) with L3VPN and then PCE (possibly the vic= tim of the recent SDN hype) bringing up the rear. like I say, does this really mean anything? Can I have the last half hour= of my life (or rather 1/66 of a football match) back? Giles On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: > Loa, > > I added one more column, to total all of the RFCs over the period. mpls c= ame in first in terms of total RFCs per capita, and pwe3 came in second. I = also agree with your conclusions. > > Cheers, > Andy > > > On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: > Folks, > > I took a look at the performance on rtg wg's. > > The spread sheet list the number of RFC's per working group > between two meeting. I've used the number of people who signed the > blue sheets in Vancouver as some type of average except for roll > that did not meet in Vancouver, where I used the London figure instead. > > Calculated the number of RFCs per person in the room. > > The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. > The highest absolute number of RFC is MPLS (this meeting). > The best trend has MPLS. > > Since I don't care too much about how much noise the non-participating > participants is exposed too, I don't think the a re-org is motivated > by the figures in the spread sheet. > > I guess I would go as far as too say that no arguments presented so far > motivates a re-org of the RTG area. > > Though I'm totally supportive of some well considered re-organization > of working groups, but > > - do it carefully > - at a time when it is optimal for the working groups > - involve the chairs to drive the re-org > - don't break things that work > > /Loa > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > --_000_0C3E597932FE4F5B971E81F3D93173A2ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0610607880F7F942A581F9F75F5530A6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I'm not sure that how helpful the exercise is?&nbs= p; Is performance really related to how many people show up?  There's = no way after all to determine what fraction of attendees are active partici= pants vs "IETF tourists".  And of course we're supposed to do more work outside meetings than in them.

At any rate to be meaningful at all we need to weight the results by length= of WG meeting as time is the constraint we're trying to optimise for here = (I think!).  I counted WG meeting durations in minutes (since L2VPN wa= s 2 hours 10 mins - and I didn't have the time to type a recurring decimal).  Couldn't find ROLL on the Van= couver Agenda though - so I used their London duration.  Of course the= n the RFCs per minute were all rather low.  In honour of the recent Wo= rld Cup I went for RFCs per football match (counting only the players and the playing minutes - no allowance for referees, half= -time, injury time or extra time).

the results show PWE3 a mile ahead of the rest, followed by BFD, then MPLS,= then a cluster of WGs with very similar productivity (L2VPN leading those = by a nose, but who am I to brag?) with L3VPN and then PCE (possibly the vic= tim of the recent SDN hype) bringing up the rear.

like I say, does this really mean anything?   Can I have the last= half hour of my life (or rather 1/66 of a football match) back?

Giles




On 23 Jul 2014, at 03:55, Andrew G. Malis <agmalis@gmail.com> wrote:<= br>
> Loa,
>
> I added one more column, to total all of the RFCs over the period. mpl= s came in first in terms of total RFCs per capita, and pwe3 came in second.= I also agree with your conclusions.
>
> Cheers,
> Andy
>
>
> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson <loa@pi.nu> wrote= :
> Folks,
>
> I took a look at the performance on rtg wg's.
>
> The spread sheet list the number of RFC's per working group
> between two meeting. I've used the number of people who signed the
> blue sheets in Vancouver as some type of average except for roll
> that did not meet in Vancouver, where I used the London figure instead= .
>
> Calculated the number of RFCs per person in the room.
>
> The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting.
> The highest absolute number of RFC is MPLS (this meeting).
> The best trend has MPLS.
>
> Since I don't care too much about how much noise the non-participating=
> participants is exposed too, I don't think the a re-org is motivated > by the figures in the spread sheet.
>
> I guess I would go as far as too say that no arguments presented so fa= r
> motivates a re-org of the RTG area.
>
> Though I'm totally supportive of some well considered re-organization<= br> > of working groups, but
>
> - do it carefully
> - at a time when it is optimal for the working groups
> - involve the chairs to drive the re-org
> - don't break things that work
>
> /Loa
>
>
> --
>
>
> Loa Andersson         &nb= sp;            =   email: loa@mail01.huawei.com
> Senior MPLS Expert        &nbs= p;            &= nbsp;    loa@pi.nu
> Huawei Technologies (consultant)     phone: +4= 6 739 81 21 64
>
> <statsv2.xlsx>

--_000_0C3E597932FE4F5B971E81F3D93173A2ciscocom_-- --_004_0C3E597932FE4F5B971E81F3D93173A2ciscocom_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="statsv3.xlsx" Content-Description: statsv3.xlsx Content-Disposition: attachment; filename="statsv3.xlsx"; size=11761; creation-date="Wed, 23 Jul 2014 10:32:27 GMT"; modification-date="Wed, 23 Jul 2014 10:32:27 GMT" Content-ID: <9C1BF3CFFE984546A4E127AFF51B8355@emea.cisco.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBIZhxhaAEAABAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs lNFOwyAUhu9NfIeGW9OyeWGMWbeLqZe6xPkACKcrGQXCYXN7e0/ZXIxZWhd7U9LC+f+PU34ms11j si0E1M6WbFyMWAZWOqXtqmTvy+f8nmUYhVXCOAsl2wOy2fT6arLce8CMqi2WrI7RP3COsoZGYOE8 WJqpXGhEpNew4l7ItVgBvx2N7rh0NoKNeWw12HTyCJXYmJg97ejzgYTKWTY/rGutSia8N1qKSKC8 neVn6wIY7CjcWvWLLj+SFVSZxLHWHm+ODq/UmqAVZAsR4otoiIPvDP90Yf3h3Lroxjzj5qpKS1BO bhrqQIE+gFBYA8TGFGksGqHtH/zTYuRpGA8M0u4vCfdwRPrfwNPz/whJpscQ494ADrzbg2ifcy0C qLcYKBmDA/zU7uGQwsh5TUdk4CacdLv86dwugvNICQ5wOcB31Nrq3JMQhKihM2wnR4r/5Ya/0gbt /aJAnfHm6T6bfgEAAP//AwBQSwMEFAAGAAgAAAAhAFB8TsH2AAAATAIAAAsACAJfcmVscy8ucmVs cyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACMks9KAzEQh++C7xDm3s22gog024sIvYnUBxiT2T/sbiYk07p9e4OguLDWHpPMfPPN j2x30zioE8XUsTewLkpQ5C27zjcG3g7PqwdQSdA7HNiTgTMl2FW3N9tXGlByU2q7kFSm+GSgFQmP Wifb0oip4EA+v9QcR5R8jI0OaHtsSG/K8l7H3wyoZky1dwbi3q1BHc4hT/6fzXXdWXpiexzJy8II Pa/IZIwNiYFp0B8c+3fmvsjCoJddNte7/L2nHknQoaC2HGkVYk4pSpdz/dFxbF/ydfqquCR0d73Q fPWlcGgS8o7cZSUM4dtIz/5A9QkAAP//AwBQSwMEFAAGAAgAAAAhAJbV+XMCAQAAPwMAABoACAF4 bC9fcmVscy93b3JrYm9vay54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKyS3WqEMBCF7wt9hzD3Nbr9oZSNe9FS2NvWPkCIo5HVRDLTH9++wYK6sNgbbwJnhpzzzTD7 w0/Xii8M1HinIEtSEOiMLxtXK/goXm8eQRBrV+rWO1QwIMEhv77av2GrOX4i2/QkoosjBZa5f5KS jMVOU+J7dLFT+dBpjjLUstfmpGuUuzR9kGHpAfmZpziWCsKxvAVRDH1M/t/bV1Vj8MWbzw4dX4iQ xEMbBxCFDjWygj+dREaQl+PvNo23OmD5ziFud0mxLK/B3G8JY3Rrnq1u3LyOqbQGkW0J8e3DiSwi zxBTieTYydZgdlvCcLxanEFGKcd3YpBnZ5//AgAA//8DAFBLAwQUAAYACAAAACEAv60LHwQCAAB3 AwAADwAAAHhsL3dvcmtib29rLnhtbIxTTY+bMBC9V+p/sHwnGIIJGwVW+SBqpKpatdvds2tMsAI2 sk3Dqup/7wAlu2ove5oZjz3z3pvx5r5vavRTGCu1SnGwIBgJxXUh1TnF3x+PXoKRdUwVrNZKpPhF WHyfffywuWpz+aH1BUEBZVNcOdeufd/ySjTMLnQrFGRKbRrmIDRn37ZGsMJWQrim9kNCYr9hUuGp wtq8p4YuS8nFQfOuEcpNRYyomQP4tpKtxdmmlLV4mhgh1rZfWAO4+xqjmlmXF9KJIsUUQn0Vrwcx RqZrd52sIRtGSRBjP7uxfDCIdU7vdQMkrH2Q3HXgpJgMtwYdnqS42tcHQ4j6Z6kKfU3xKkhA2Jc5 pHQIr2PyWRaugo5hFN/OPgl5rhyMIwKVhgb+mw6jgNBptEiN7L4NogYwqcGegAD4Zi3BMaciGCvM zzirObAZzHgxIoTAba4V74wBUfeQ+ctL9O6zddkGLOqMTPGvFQ2XOT0svZAel96W5sQL4mXoxdEx pNEeWNDw9zzRpv9vpI3kRltdugXXjT9NE7aA+6LnYlyKZFqKbNP0663h1emAjjU7g9ThyAOwvAUU RGS7IneRR/Il9aLkLvSSCADto0OY01V+yHf0BqgP6PsQ/buqAfGDYAYGVdbz9g9KVsy4R8P4Bf7M V1HumIV9m0QfwQK3SUZ/fpX9AQAA//8DAFBLAwQUAAYACAAAACEAbyd48UkBAAD4AgAAFAAAAHhs L3NoYXJlZFN0cmluZ3MueG1sdJLLbsIwEEX3lfoPlvfBSaC8lJgFKlIXlaqKsjfOQCz5Vduh7d/X AYmFE5Y+Z3wzjm61+VUSXcB5YXSNi0mOEWhuGqHPNf7a77IlRj4w3TBpNNT4Dzze0OenyvuA4l3t a9yGYNeEeN6CYn5iLOhoTsYpFuLRnYm3DljjW4CgJCnzfE4UExojbjodalyWGHVafHewvQNaeUGr QI+npiKBVqQ/3hDnTNkUxu9x8CmV5cXqAZyOQMU0hHRSWTmItBzSMfsD05Q5I2XK3l73O7ScIYSK MssX4/rlaoti3M6jnWZ5OW4XN/sgeXm1j5JX0c6yfPCQ69KrvF866kH0B3NBcGGZDh4dWCxPF/uU rrc3gUn0udsOfmfPkAWHTsaEI5MSxdrwNgnou7b2lvHYwVgmD+4CmN7vJtP0XeguwOg+JDaX/gMA AP//AwBQSwMEFAAGAAgAAAAhANp94nKoBgAAWxoAABMAAAB4bC90aGVtZS90aGVtZTEueG1s7FnP jxs1FL4j8T+M5p7m18wkWTVbJZOkC91tqyYt6tFJnIwbzziacXYbVZVQe0RCQhTEBYkbBwRUaiUu 5a9ZKIIi9V/g2TOZ2InDblc9FNTdS8bzvefP79nfs8eXr9wPqXWM44SwqGmXL5VsC0cjNibRtGnf HvQKddtKOIrGiLIIN+0lTuwr+x9+cBnt8QCH2AL7KNlDTTvgfL5XLCYjaEbJJTbHEbybsDhEHB7j aXEcoxPwG9JipVTyiiEikW1FKAS3NyYTMsLWQLi091fOuxQeI56IhhGN+8I11iwkdjwrC0SyTHwa W8eINm3oZ8xOBvg+ty2KEg4vmnZJ/tnF/ctFtJcZUb7DVrHryb/MLjMYzyqyz3g6zDt1HNfxWrl/ CaB8G9etdb2ul/uTADQawUhTLqpPt91od9wMq4DSnwbfnVqnWtbwiv/qFueWK/41vASl/p0tfK/n QxQ1vASleHcL7zi1iu9oeAlK8d4WvlZqdZyahpeggJJotoUuuV7VX402h0wYPTDCG67Tq1Uy52sU zIZ8dokuJiziu+ZaiO6xuAcAAaSIk8jiyzmeoBHMYh9RMoyJdUimARfdoD2MlPdp0yjZahI9Wsko JnPetD+eI1gXa6+vX/z4+sUz6/WLp6ePnp8++uX08ePTRz+nvjTDAxRNVcNX33/x97efWn89++7V k6/M+ETF//7TZ7/9+qUZCOtozejl10//eP705Tef//nDEwO8FaOhCh+QECfWdXxi3WIhjE0GRmeO h/GbWQwCRDQLFIBvg+suDzTg9SWiJlwb68G7E4OEmIBXF/c0rv0gXnBi6PlaEGrAI8Zom8XGAFwT fSkRHiyiqbnzeKHibiF0bOrbR5GW2u5iDtpJTC79AGs0b1IUcTTFEeaWeMdmGBtGd5cQLa5HZBSz hE24dZdYbUSMIRmQoTaR1kYHJIS8LE0EIdVabI7uWG1GTaPu4GMdCQsCUQP5AaZaGK+iBUehyeUA hVQN+CHigYlkfxmPVFw34ZDpKabM6o5xkphsbsQwXiXp10A+zGk/ostQR8aczEw+DxFjKrLDZn6A wrkJ2ydRoGI/SmYwRZF1k3ET/IjpK0Q8Qx5QtDPddwjW0n22ENwG5VQprSeIeLOIDbm8ipk2f/tL OkFYqgwIu6bXIYnOFO+0h/ey3bRbMTEunoMNsd6F+w9KdActopsYVsV2iXqv0O8V2v7fK/Sutfz2 dXktxaDSYjOY7rjl/jvcuf2eEEr7fEnxYSJ34AkUoHEPGoWdPHri/Dg2D+CnWMnQgYabxkjaWDHj nxAe9AM0h9172RZOpknmeppYc5bAqVE2G30LPF2ER2ycnjrLZXHCTMUjQXzdXnLzdjgx8BTt1dYn qdy9ZDuVJ94VAWH7JiSUznQSVQOJ2qpRBEmeryFoBhJyZG+FRcPAoi7cr1K1xQKo5VmBHZIF+6qm 7TpgAkZwbEIUj0We0lSvsiuT+TYzvSuY2gwowaeNbAasM90QXHcOT4wunWrnyLRGQpluOgkZGVnD kgCNcTY7Ret5aLxprhvrlGr0RCiyWCg0avV/Y3HRXIPdpjbQSFUKGlknTdurujBlRmjetCdweoef 4RzmTiJ2tohO4RPYiMfpgr+IsszjhHdQEqQBl6KTqkFIOI4tSsKmLYafp4FGUkMkt3IFBOGdJdcA WXnXyEHS9STjyQSPuJp2pUVEOn0EhU+1wvhWml8cLCzZAtLdD8Yn1pAu4lsIpphbK4sAjkkCn3jK aTTHBL5K5kK2nn8bhSmTXfWzoJxDaTui8wBlFUUV8xQupTynI5/yGChP2ZghoEpIskI4nIoCqwZV q6Z51Ug57Ky6ZxuJyCmiua6ZmqqIqmlWMa2HVRnYiOXFirzCahViKJdqhU+le1NyGyut29gn5FUC Ap7Hz1B1z1EQFGrrzjRqgvG2DAvNzlr12rEa4BnUzlMkFNX3Vm434pbXCGN30Hihyg92m7MWmiar faWMtLy+UG8Y2PAeiEcHvuUuKE9kKuH+IEawIerLPUkqG7BE7vNsacAvaxGTpv2g5LYcv+L6hVLd 7RacqlMq1N1WtdBy3Wq565ZLnXblIRQWHoRlN7066cEXJ7rMLlBk+9YlSrj6qHZpxMIik5ckRUlc XqKUK9kliryEadrG2xSLgPo88Cq9RrXR9gqNaqtXcDrteqHhe+1Cx/NrnV7Hd+uN3kPbOpZgp1X1 Ha9bL3hl3y84XkmMo94o1JxKpeXUWvWu03qY7WcgBKmOZEGBOEuC+/8AAAD//wMAUEsDBBQABgAI AAAAIQADPA7KeQQAAD8bAAANAAAAeGwvc3R5bGVzLnhtbOxZX2/iOBB/P+m+Q5T3kDgkNEHAaoFG t9LeaqX2pHs1iQNWHTtyTAt7uu9+YydAWg4KhVvdA31obccz/nn+dWY8+LQqmPVMZEUFH9qo49kW 4anIKJ8P7T8eEyeyrUphnmEmOBnaa1LZn0a//jKo1JqRhwUhygIWvBraC6XKvutW6YIUuOqIknD4 kgtZYAVTOXerUhKcVZqoYK7veT23wJTbNYd+kZ7CpMDyaVk6qShKrOiMMqrWhpdtFWn/y5wLiWcM oK5QgNMNbzPZY1/QVIpK5KoD7FyR5zQl+yhjN3aB02jAl0VSqMpKxZIrkNZ2yaq/fMlgsRfYVn3p icgAhtfxPM92RwO3IR8NcsF3XLoAUSPtP3HxwhP9qWatd40G1Q/rGTNYQZpHKpiQlgIJA2ezwnFB 6h0TzOhMUr0txwVl63rZ1wtGKc2+goKIDKD6hPr3Uu86cpa5ws867Eo3c/XVKhAHZWyrtQC0phdG A7AfRSRPYGI148d1CYLlYOq1gMy+d3bPJV4jPzydoBKMZhrFfNJW551tKartyuuEMfx0o7jnxxHy gsgwnzXbKc/IioCpgaWB0tzWNWBWg30H8gEEYLkbBHcAIEK9KIrioIuCwFjROQgMEJD9TMgMwkvb Z+ql0YCRXMEFJJ0v9F8lSvg9E0qBL44GGcVzwTGDobuhaAbANiWMPegQ9Ge+5e1rh1zlLWeEaKZN QPulHoI2m2HNsJ7AAYeI0EEiC5clW39bFjMiExPizBFmNYFzdrOxEcBu/pnROS+IUbRds/kuhSKp MiHY+NkhPP7/DM9NPmBXN/v5sD3f7OdmP5fEw5v93OznZj//Xb5x86+bf53iX247Ha+T81ZeHn0o LbdW+bv5+eGkfktdZ9itS+giAW9ycGshJP0BJYIusVNIyom0dTtE0bS98iJx+UhWUJuZytRd5Ydr hp+ESZdFJ8KAqqFd77wRTR09zL1elR261tivnaBbcYTX63oIokerHjr1hONozzuhaca8VwG+kcjb M94m+P8uGdD7GZLR6tNOA27SKmZfl7Jbp7J032VoJ4Ix8UIy6zfoUkhG+RO0joyTaJktKYPiXbtM bFsLmmVEN/R0dXI6H2gAXIVP70p8oPl4FTxIK+caAkLXkjS6lqjRtWSNriVs/zxh7xkzhI2WrgDV UWPeI9cRaqfqs8nDy8ihiXfJ6eC6l5BDk/gy+guFhy6UHrpQfOg8+X3TjTu2CaKvzbZu2W9DJ0Tp bLVrNZqvSr8zmCbkNm4Dj4zkeMnU4/bj0N6NfycZXRYQRJpd3+mzUIbF0N6Nv+qOKDg2xG5IOr5W 8AwAf62lpEP7r/vxXTy9T3wn8saRE3RJ6MTheOqEwWQ8nSax53uTv1vPHhc8epjHGch0UNCvGDyN yOayDfiH3drQbk1q+KY3DbDb2GO/530OkeckXQ85QQ9HTtTrhk4SIn/aC8b3YRK2sIcfw448F6H6 ZUmDD/uKFgT+XW50tdFQexWUBNMjl3A3mnCr7cvX6B8AAAD//wMAUEsDBBQABgAIAAAAIQAx6G5w tAsAAP4tAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srFrZbuM4Fn0fYP7BMOahJkBkkZK1 GEkaFe+Wa6rQNd39rNhKYpRtpW1lqRnMv8/hIomkaEcB2oAd5y6H5F14qWte/fK223ZessNxk++v u8Rxu51sv8rXm/3Ddfe3f08uo27nWKT7dbrN99l192d27P5y8/e/Xb3mhx/HxywrOkDYH6+7j0Xx NOj1jqvHbJcenfwp24Nznx92aYF/Dw+949MhS9dcabftUdcNert0s+8KhMGhDUZ+f79ZZaN89bzL 9oUAOWTbtMD8j4+bp2OJtlu1gdulhx/PT5erfPcEiLvNdlP85KDdzm41mD/s80N6t8W634ifrkps /k8DfrdZHfJjfl84gOuJiTbXHPfiHpBurtYbrICZvXPI7q+7n+ngK/W6vZsrbqDfN9nrUfneKdK7 79k2WxXZGn7qdor8aZndF8Nsu2XK3Q5zyF2e/2Cac8i4GOPINdgY6arYvGRCekH7cOqffFj2HWP2 qkHV7+UEJtyJ3w6du/SYDfPtH5t18YhZIFjW2X36vC1qYuREHnU9wsaQzF/z11m2eXgsoOLDhsyU g/XPUXZcwYdsppjBKt9iOHx2dhtEIha0S9/431c5GnG8Cnn1fCzyXTkPqS80PamJv6UmdYLAdwM2 pTOKmBofki1LasYOVO6yYzHZsMmfVSfllNmXcmTVGmeGJuWkCcaTuqrq42a9zlh+2mbQE6bjHhyl RXpzdchfO8gmzOP4lLLcJAMGzBxAI4TFinFvGZtDgnwE9eWGhFe9FwTASooMmyKU6CKjpghxdZGx RcRAmVhEqI4ytYh4usjMIuLrInOLSF8XWVhEAl0kESL4rE0X6SJLi0isi3xpilDDdP8qRViCMKd9 VQg9uLnyNYJX9bUU/8zI111EVzVRY4TbUsLqf5UZG5ojlWk4a6zyTF+rPANzeoY3O8ObqzxjvIXK M8ZLfMT9/c333758GvmDhf/Pq949M0QdNZqRkUM2IzMyM3LppFuTMDQJI0Ho89FHfu8ftxiRj+w6 hISBH7r9KKJen8a+sZyxosq9+pgesnVXFJFxf7Bg/A3f/scqcN+pAOUA40vDa5MT0AIOq3u5Mew3 /bDG7MMa8/c1WqyNm+W6yy2umu302hIxroiQRDWl60jP1J7SM3upTPmG0ovYvQDAp1v/YliFWN+p tbmfT8RcYI85kKuUNiLkNuCbuW9sN0NBpqHhw5GgGyBjKa0vbGKlTq0IM6vsXFCNnXthRUgYVWZn MFgEZXaSOm619Aytphox8nU3FLkWINewm/Nco47ruxEJPBr0PTcglDRSYqwoq2HDz07jcLBgfGQb 6d6MVWjf0YCpTxvQkxPQAo5nWwuU6fsoLZY5ex+lxVzm76MEDqHU96M4jPsxibwgaNiFm1T6SzW5 YpcWK0rEXGT2qq5B9qoTCD3fqO5LoSo2Z5m9AbI3uBjWIeiUC2D6sRfV5V8LSfb0pBzByrLMyHpZ rkNaHM5KCV6NjIwdqsxGWVaZhuL4DG9yhjdVecZGMTvDm5/hLVSeMc+EHVJl4keDRVQmfr1raEaO 7UZmZK0sm4ShSRgJgizLEbYKuFWUZX0fHCuCaoyKbSEeLBgf2wLFtnAGZnICRqhaC+77GtTpu9qr uavN/hKU+V+Cwk11ojBTdqRqHDoSMa5MbdW8oePH2its7C5LZdJlaY6Q3NHFsAoz4gT1M4EWaezR 0JbPjF6V4zpKRSqDyVYRGokzlHTiGdE/KhlGzNnJE0k2QKZ28swOMpdkY+oLOznhZJmfxB1ArMzQ +syh2w0Prha7jQijX3dFnce6kXHs6ZGnHHFQnP2+G7o+pX0ckZpxPFb1m3lICKbGRkAmesjED+NP TuELRFtwTj+uMmuh0sIY8xYwviNNSWgQBm4/8BoJIiwmfaLaVFlzC5hEzkZmqW56POSU43uRS3EE q+OG58xSams1GBifEB4XSJwy3IgT4+AWuFEU+W7oBWEdwHr8scdmSx1mrRqjENfHcJm9pQjLYWVf 4NxhBcC4pG8k4UhjGyV+rDGNzWGiMQ3Y6TnmTGMasHONacAuNKahmYBZ1WRCkVi0dMKpvRJdB6vN GV2ry6z7pVGGDcpIUmRpJpTtFDAo3yk8xw2DmHrlZ2jbKcQYXF+NalGxiYcFMQnsFIhYuEbFJ07f i/yAVJ/9RtZM1Pmp+ALRvlOcmNJplVmLUVpMdt4CphEb70+2xciJHLncFTQzh47qRHy3VG915mX5 hrOwL1DsC1VI4neM2lvcc1Ut1fcF1huy7QugV/W8jm+5I7DZv9x4Bn2I3jbfBcwm3kgyGvkv5aup cfiJlDYcMLWTZ3by3E5eSHIjt4U/eBuMoA9Gqi5FvRvqdmMNjqbdRqzLjEyWz9qENU1I2dnqOyHx adSvPm1ZquirWSSzFN0tPgKyFIk81vGpo2DzcSxZegKfpRz/HaRx2JyqS1KndFpl9nGV+cdVhCVO PCfLtbQwSSJHFhGQ6CZlzUjNZbR+zOXBupTaep1mrS6CXlcdRgTNx9rxzDlV0OtxdaLbRRhdf2A2 HtpvKxGWg82zdgnAuM0WmKZcnyH4Gsca00jiyTnmVGMasDONaewlc41ZJyGf0EJjGh5JwKzrNLpm pOpZ0FNGZ/2OKplZmefDfCaiD6L0tRuUYYMykpSyULPOCykbbi3OjWNVX803uQWg5cYlkLBYKHyj 4iPecZR0SfXg0DzeTk7hs3wOxPNmC5hpC5gWq521gAnRpdRO7XFjX5u3gOk7gVcetrmFLJ23FjBs S9DP7nVU8bBJJEi5oWgOch1tCni6M9J4qU6hKvCs+0bQflNi2QmjKPSoF/voIZK4noS+n7Amky20 Qa/qe63LF3BLWPcJe4iR6kNJt5zyhYJRscelfLXVcfiJJBvSU7v0zC49t0sv7NIJJ5fP62iokarV UW9Kut1Yl6RptxER3ZOyvrPeCznVIlNlLYmMJhmXQNoBDsZSsfBTPx7p1Fcj5ien8Fkih9bG0bSF SouRZy1gDO/OW6i0GFlY7ETNt685kSOX6aiZ2XdIoL38hpmXUl+v8KxjRtAyqwPJdfpG27GuWlpo Ua2FVlcbTtdLvFHabisRlp6+YeKhxg0M7kjj1lPjKTnWmEbaTzSmcXKeakxjzJnGNGDnGtOAXWhM QzMBs6rwFN03WrdDalHd5lr7TbG5aL8pFZ6alGGDMpIUWeEpa9qxRx7RJ3eMpYxV6eY2QNGi4xJI Wuyi8ISO5hoHo8kpOJb1UVm+jUhsPmhMW8A0vClMw5etLkQZ2XXM+c5bDNSiYS9sdKJLLpfdHDyR g8vcN21b7/08C5bqVMvSC51P8O4Fsqts98RO3azTo0xrsilRBnpVbGtdUWwpk0M2G34eSnrj1y1J N5wztpMndvLUTp5Jcp1EfIpzSTYCe2EHSThZ1lqKPhmtmhK1vXWzsc6KpdbiMqDyLE1Zq4Riataf o1RZNTbFoZmiu8UlkCMxS7JzWJNTWCzOY3td/bjKrIWK7/j6q3linbeAoeh5a6/mQ4Gwzom6al9z Ikcuc0szaYD7hvqrWVelvlZX4RhkGzpZddCg8a8j1QdmEUXi5qa49/eUPmRf0sPDZn/sbHE5FLeA HDzEHcTdS/4d10Y5FY2Qu7zAHcryv0dczc1wwwxH9G7nPs+L8h/0Lhnu96x4furkhw2ubPLbttfd p/xQHNJNgZuFoP8nB2M7ekKY+Li2FAchjZH5uFtcbFZNBmA37Hptth4fDvkBdz/Vf8vrqYnfScJO Eg/wm1MHPWi8QSEB3lEHlRBvjMEuGT9v01/T/QOu6hIWpFaw/iCBJhQJwdvDu4838EkMIOzvEojf irSA9lRUzDh7K5bHgv/tPB+w8P/imqlLQ49cfg5u3cs++8DTknsZhpTchkM3Dlz3f+U14h3utxq3 pq13iHfpqpe9rTJ+ZzoSd6ZvrnZvg2/L3ztf8jXWjEPV1332DX7i3//4DovzrzAFdDFH9skn23st b27f/B8AAP//AwBQSwMEFAAGAAgAAAAhAN7C6jFSAQAAaQIAABEACAFkb2NQcm9wcy9jb3JlLnht bCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySy07DMBRE90j8Q+R94jxaHlaS iocKi1ZCIgjEzrJvW4vYjmxD27/HSdqQChYs7Zl7PHfkfLaTdfAFxgqtCpREMQpAMc2FWhfopZqH VyiwjipOa62gQHuwaFaen+WsIUwbeDK6AeME2MCTlCWsKdDGuYZgbNkGJLWRdygvrrSR1PmjWeOG sg+6BpzG8QWW4CinjuIWGDYDER2QnA3I5tPUHYAzDDVIUM7iJErwj9eBkfbPgU4ZOaVw+8bvdIg7 ZnPWi4N7Z8Vg3G630TbrYvj8CX5bLp67VUOh2q4YoDLnjDAD1GlTLjQNbhT3JVutcjxS2hZrat3S F74SwG/35YOofZePYFrrb9lzuzV6OPDAByP9GkflNbu7r+aoTONkEsaXYZpWaUwmUzK9fm9fP5lv g/YX8pDhP8SsSmKSxSSZjIhHQNnlPv0c5TcAAAD//wMAUEsDBBQABgAIAAAAIQAhATCOgwEAAIIH AAAQAAAAeGwvY2FsY0NoYWluLnhtbGzVy06DQBiG4b2J90Bmb+mg1kNKu3DOsNQLIHQsJDA0DDF6 96JpG/2/bprwFCZv/zDT9faz75IPP8Z2CDnjiyVLfKiHXRv2OXt7VTePLIlTFXZVNwSfsy8f2XZz fbWuq65+aao2JPMKIeasmabDc5rGuvF9FRfDwYf5m/dh7Ktpvhz3aTyMvtrFxvup79JsuVyl/bwA 26zrZMxZkWUsaecIlnQ/n+nRy+z26Ccpsjnz986TlNn81D8p+Fz+T0r+RKTgKyIlfyBS8DsiJb8n UvBT+bmHQzOHZg7NkAzFEAy9kAu18MiFAUPaheHBOhcGg2OAleE30mAJfQpEgxgQC+JABIiEV0uB aBADYkEciACRMHcFokEMiAVxIAJEwnZQIBrEgFgQByJAJLxPCkSDGBAL4kAEiIQtrEA0iAGxIA5E gEg4HBSIBjEgFsSBCBBJ96SioCkYCpaCoyAoSHqiKAqagqFgKTgKgoKkB46ioCkYCpaCoyD+QHr+ 99x8AwAA//8DAFBLAwQUAAYACAAAACEA11OcMJABAAAbAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwg ogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckk1v2zAMhu8D9h8M3Rs5XTEMgayi SDv0sGIBknZnTaZjobIkiKyR7NePtpHG2XbajR8vXj6iqG4PnS96yOhiqMRyUYoCgo21C/tKPO++ Xn0RBZIJtfExQCWOgOJWf/ygNjkmyOQAC7YIWImWKK2kRNtCZ3DB7cCdJubOEKd5L2PTOAv30b51 EEhel+VnCQeCUEN9ld4NxeS46ul/TetoBz582R0TA2t1l5J31hC/Uj85myPGhoonY12giG3xcLDg lZzLFHNuwb5lR0ddKjlP1dYaD2seoRvjEZQ8F9QjmGF9G+MyatXTqgdLMRfofvECr0Xx0yAMYJXo TXYmEAMOsikZY5+Qsv4R8yu2AIRKsmAqjuFcO4/djV6OAg4uhYPBBMKNS8SdIw/4vdmYTP8gXs6J R4aJd8LZDnzTzDnf+GSe9If3OnbJhCM33qNvLrzic9rFe0NwWudlUW1bk6HmHzj1zwX1yJvMfjBZ tybsoT5p/m4MZ/Ay3bpe3izKTyX/66ym5Pmq9W8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAEhmHGFo AQAAEAUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAUHxOwfYAAABMAgAACwAAAAAAAAAAAAAAAAChAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEAltX5cwIBAAA/AwAAGgAAAAAAAAAAAAAAAADIBgAAeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHNQSwECLQAUAAYACAAAACEAv60LHwQCAAB3AwAADwAAAAAAAAAAAAAAAAAKCQAAeGwvd29ya2Jv b2sueG1sUEsBAi0AFAAGAAgAAAAhAG8nePFJAQAA+AIAABQAAAAAAAAAAAAAAAAAOwsAAHhsL3No YXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhANp94nKoBgAAWxoAABMAAAAAAAAAAAAAAAAA tgwAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAAzwOynkEAAA/GwAADQAAAAAA AAAAAAAAAACPEwAAeGwvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQAx6G5wtAsAAP4tAAAYAAAA AAAAAAAAAAAAADMYAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEA3sLq MVIBAABpAgAAEQAAAAAAAAAAAAAAAAAdJAAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAA ACEAIQEwjoMBAACCBwAAEAAAAAAAAAAAAAAAAACmJgAAeGwvY2FsY0NoYWluLnhtbFBLAQItABQA BgAIAAAAIQDXU5wwkAEAABsDAAAQAAAAAAAAAAAAAAAAAFcoAABkb2NQcm9wcy9hcHAueG1sUEsF BgAAAAALAAsAvgIAAB0rAAAAAA== --_004_0C3E597932FE4F5B971E81F3D93173A2ciscocom_-- From nobody Wed Jul 23 04:35:23 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49011A04B7; Wed, 23 Jul 2014 04:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnEMysk_ajNB; Wed, 23 Jul 2014 04:03:12 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682FB1A019C; Wed, 23 Jul 2014 04:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5204; q=dns/txt; s=iport; t=1406113392; x=1407322992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v+FsXp2sRYe3OEYezZllpANOHmfijQ7krpZiezhMyxY=; b=NCVXL90ecUiGyqSYa9Zl+v9LT5huXxL7y2ORH5M3ysebjxuuxhBBiRIZ si49nWsJXN9qGLLK6Q1IyDCVLrHTSbp+AgTVCjC62aUOkOQUngz9eDdDF 5URF8ESTXVSdCRvZlC4ozimshCSvTq823GLq/MiMz5dnPQEJgeDE3UlWA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAESVz1OtJV2Y/2dsb2JhbABZgw5SVwTHYIdFAYENFnaEAwEBAQMBaw4FCQICAQgOAwQBAQEnBxsGERQJCAIEDgUZiBUDCQgNuAANhxwXBIUhh3mBFTYOAgIBHDMCBYMugRgFmSOCA44YhhyDRmwBgUQ X-IronPort-AV: E=Sophos;i="5.01,716,1400025600"; d="scan'208";a="63299828" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 23 Jul 2014 11:03:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6NB36FF012910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 11:03:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 06:03:06 -0500 From: "Giles Heron (giheron)" To: Susan Hares Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf9IM04b0e02pk+dfc3mGMfie5utSuGAgAB/voCAAAaEgIAAAgwA Date: Wed, 23 Jul 2014 11:03:05 +0000 Message-ID: <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> In-Reply-To: <011801cfa664$a9573980$fc05ac80$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.143.153] Content-Type: text/plain; charset="Windows-1252" Content-ID: <91E0C78F2F787E4B9CD4A8A6B1480221@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/myoFSRbWvrTlEGTttOExc7wkB-I X-Mailman-Approved-At: Wed, 23 Jul 2014 04:35:16 -0700 Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , "Andrew G. Malis" , Loa Andersson Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 11:03:16 -0000 Hi Sue, I think my point was rather that I'm not sure metrics are what we should be= concentrating on in this debate. Numbers can be made to say just about an= ything, after all ;) Giles On 23 Jul 2014, at 11:55, Susan Hares wrote: > Giles: > =20 > The performance that IETF has utilized for its ADs, IETF chairs, and WG g= roups for 20 years has been: > =20 > Quantitative: > 1) RFC published > 2) WG groups formed and completed > 3) Administrative effectiveness (AFI/SAFIs, early code adoption, por= ts assigned=85 ) > 4) Number of authors and demographics on authors > 5) Statistics on the timing of RFCs and the timing of WG forming > 6) Statistics on attendance in WG/ IETF > =20 > Please note, I do know of a statistically valid analysis of the correlati= on between #6 an #1. If you do, I would be interested. > =20 > Qualitatively > 1) Technologies described in RFCs get deployed. > 2) IETF is collaborative (at IESG, at WG), > 3) People want to come (from surveys) =20 > =20 > The =93people=94 want to come falls into a qualitative experience that sa= ys =93important to learn about the technology=94. > =20 > http://www.arkko.com/tools/docstats.html has document statistics. > =20 > If you want to propose a new metric it can be useful going forward, but u= nless it is built on the data kept by the datatracker, we do not have the p= ast trends to defend it. You could also use the mail list information, bu= t we would need to use a long-running group to get a valid statistics. > =20 > Sue > From: Giles Heron (giheron) [mailto:giheron@cisco.com]=20 > Sent: Wednesday, July 23, 2014 6:32 AM > To: Andrew G. Malis > Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] what is so bad > =20 > I'm not sure that how helpful the exercise is? Is performance really rel= ated to how many people show up? There's no way after all to determine wha= t fraction of attendees are active participants vs "IETF tourists". And of= course we're supposed to do more work outside meetings than in them. >=20 > At any rate to be meaningful at all we need to weight the results by leng= th of WG meeting as time is the constraint we're trying to optimise for her= e (I think!). I counted WG meeting durations in minutes (since L2VPN was 2= hours 10 mins - and I didn't have the time to type a recurring decimal). = Couldn't find ROLL on the Vancouver Agenda though - so I used their London = duration. Of course then the RFCs per minute were all rather low. In hono= ur of the recent World Cup I went for RFCs per football match (counting onl= y the players and the playing minutes - no allowance for referees, half-tim= e, injury time or extra time). >=20 > the results show PWE3 a mile ahead of the rest, followed by BFD, then MPL= S, then a cluster of WGs with very similar productivity (L2VPN leading thos= e by a nose, but who am I to brag?) with L3VPN and then PCE (possibly the v= ictim of the recent SDN hype) bringing up the rear. >=20 > like I say, does this really mean anything? Can I have the last half ho= ur of my life (or rather 1/66 of a football match) back? >=20 > Giles >=20 >=20 >=20 >=20 > On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: >=20 > > Loa, > >=20 > > I added one more column, to total all of the RFCs over the period. mpls= came in first in terms of total RFCs per capita, and pwe3 came in second. = I also agree with your conclusions. > >=20 > > Cheers, > > Andy > >=20 > >=20 > > On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: > > Folks, > >=20 > > I took a look at the performance on rtg wg's. > >=20 > > The spread sheet list the number of RFC's per working group > > between two meeting. I've used the number of people who signed the > > blue sheets in Vancouver as some type of average except for roll > > that did not meet in Vancouver, where I used the London figure instead. > >=20 > > Calculated the number of RFCs per person in the room. > >=20 > > The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. > > The highest absolute number of RFC is MPLS (this meeting). > > The best trend has MPLS. > >=20 > > Since I don't care too much about how much noise the non-participating > > participants is exposed too, I don't think the a re-org is motivated > > by the figures in the spread sheet. > >=20 > > I guess I would go as far as too say that no arguments presented so far > > motivates a re-org of the RTG area. > >=20 > > Though I'm totally supportive of some well considered re-organization > > of working groups, but > >=20 > > - do it carefully > > - at a time when it is optimal for the working groups > > - involve the chairs to drive the re-org > > - don't break things that work > >=20 > > /Loa > >=20 > >=20 > > --=20 > >=20 > >=20 > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > >=20 > > >=20 From nobody Wed Jul 23 05:05:24 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDB11A0AC0 for ; Wed, 23 Jul 2014 05:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtY-OUsZ342g for ; Wed, 23 Jul 2014 05:05:19 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id BD47A1A0A9F for ; Wed, 23 Jul 2014 05:05:19 -0700 (PDT) Received: (qmail 26776 invoked by uid 0); 23 Jul 2014 12:05:13 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 23 Jul 2014 12:05:13 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Vu561o00s2SSUrH01u59BP; Wed, 23 Jul 2014 12:05:11 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=WrhVjQHxoPwA:10 a=zqHLjNqbk_wA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=7xPyp7LSBkGDkgT6ofoA:9 a=aFWM0igt9LHy5JB9:21 a=paBcm47MSIfgH0O7:21 a=QEXdDO2ut3YA:10 a=33rK67OTR_gA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UgcAzg/cKvbDWqD/iEK1jE3HCEu7J0Mfjt4/UtcG3Io=; b=asA/fKN1zUrDXznKizeh+AMuPOS6c6dwqhJ14l9ik8jDMVAkMnPEx9NyavmoTWlEPkXDcz0Po4dVEGAnUZSRe1qSAZsQzqgrFA+w4yt9l2+zhyM0YOcR5GZ5rvMNSSKA; Received: from box313.bluehost.com ([69.89.31.113]:56985 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1X9vIB-0007oW-8K; Wed, 23 Jul 2014 06:05:08 -0600 Message-ID: <53CFA4FC.3080304@labn.net> Date: Wed, 23 Jul 2014 08:05:16 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yaacov Weingarten , Jeong Ryoo References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/R-oONXc7bGP0dOC0u9V40MiIYC0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:05:23 -0000 Yaacov, Jeong, I'm not sure how the latest text addresses the ambiguity you identified below. Perhaps adding the words "on a per LSP basis" to the requirement? If the ambiguity is intentional, then of course no change is warranted. Lou On 7/5/2014 3:49 PM, Yaacov Weingarten wrote: > > Lou, hi > I would like to address two of your comments, in your follow-up > message, since I am the source of the change in terminology. > > Regarding the two occurences of "assigned" in place of "utilized" - > when I read the proposed changes,as discussed amongst the authors, I > felt that in those two instances the use of "utilized" could lead to > some ambiguity. > > If we state that "resources SHOULD be utilized on a first come first > served basis" this could be interpreted (IMO) as referring to the > packet level, rather than utilized by a specific path, such that > packets from different paths could be interspersed along the shared > segments. Therefore,I suggested that or this context it would be > better to use a word that meant that the first-come first served basis > was at the level of assigning (or allocating) the resources rather > than utilizing them. > > Hope this clarifies this point. I am certain that I speak for the > other authors in saying that I am open to other suggestions. > > BR, > yaacov > > On Jul 4, 2014 3:53 AM, "Jeong Ryoo" > wrote: > > Dear Lou, > > > > Thanks a lot for your valuable comments. > > > > The authors of this draft have discussed your comments, and are > proposing our resolutions to your comments. Please, let us know if > the proposal is appropriate to address your comments and concerns. > > > > Best regards, > > > > Authors of draft-ietf-mpls-smp-requirements draft > > > > ****** Beginning of Comment Resolution ****** > > > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > > > [Authors] After reviewing RFCs 4427, 6372, 3945, 4426, and 4428, > we concluded that the distinction between protection and > restoration should be aligned with the exiting documents > normatively referenced by this document. Accordingly, the > following 16 modifications will be done in revision: > > > > (1) Section 1, the third paragraph > > OLD: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 linear protection requires > > that resources are committed for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are committed, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > NEW: > > As pointed out > > in [RFC6372] and [RFC4428], applying 1+1 protection requires > > that resources are allocated for use by both the working and > > protection paths. Applying 1:1 protection requires that the same > > resources are allocated, but allows the resources of the protection > > path to be utilized for pre-emptible extra traffic. > > > > (2) The whole text in Section 3.1 will be replaced with: > > [RFC6372], based upon the definitions in [RFC4427], differentiates > between "protection" and "restoration" dependent upon the dynamism > of the resource allocation. The same distinction is used in > [RFC3945], [RFC4426], and [RFC4428]. This document also uses the > same distinction between protection and restoration as stated in > [RFC6372]. > > > > (3) In page 6, > > OLD: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine to which parties the protection > > resources are committed. > > NEW: > > The use of preemption in the network is typically a business or > > policy decision such that when protection resources are contended, > > priority can be applied to determine which parties utilize the > protection > > resources. > > > > (4) Page 7, the first paragraph: > > OLD: > > the resources for the protection path are fully committed, > > NEW > > the resources for the protection path are fully dedicated, > > > > OLD: > > resources may be planned but would not be committed until … > > NEW: > > resources may be planned but would not be utilized until … > > > > (5) In the second paragraph in page 7, > > OLD: > > "Hard Preemption" requires the programming of selectors at the > ingress of each shared segment to specify which backup path has > the highest priority when committing protection resources, the > others being preempted. > > NEW > > "Hard Preemption" requires the programming of selectors at the > ingress of each shared segment to specify the priorities of backup > paths, so that traffic of lower priority paths can be preempted. > > > > (6) The first paragraph of Section 4.1: > > OLD: > > … and commit the associated resources. The commitment of resources > > is dependent upon … > > NEW: > > … and coordinate the utilization of the associated shared resources. > > The resource utilization coordination is dependent upon … > > > > (7) The second paragraph of Section 4.1: > > OLD: > > When the reserved resources of the shared segments are committed to a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the commitment of the resources may fail. In order to > > optimize the operation of the commitment and preparing for cases of > > multiple working paths failing, the commitment of the shared > > resources are be coordinated between the different working paths in > > the SMP network. > > NEW: > > When the reserved resources of the shared segments are utilized by a > > particular protection path, there may not be sufficient resources > > available for an additional protection path. This then implies that > > if another working path of the SMP domain triggers a protection > > switch, the resource utilization coordination may fail. The > different working paths in > > the SMP network are involved in the resource utilization > coordination. > > . > > > > (8) Section 5.1, > > OLD: > > … and commit the associated resources. > > NEW > > … and coordinate the utilization of the associated shared resources. > > > > (9) In Section 5.1, > > OLD: > > In the case of multiple working paths failing, the commitment of the > > shared resources SHALL be coordinated between the different working > > paths in the SMP network. > > NEW: > > In the case of multiple working paths failing, the shared resource > utilization > > coordination SHALL be between the different working > > paths in the SMP network. > > > > (10) Section 5.1.1. > > OLD: > > … because they already have been committed to the protection of, > for example, a higher priority working path. > > NEW: > > … because they already have been utilized for the protection of, > for example, a higher priority working path. > > > > (11) Section 5.2, the second bullet item: > > OLD: > > Resources of the shared segments SHALL be committed to the > > protection path … > > NEW: > > Resources of the shared segments SHALL be utilized by the > > protection path … > > > > (12) Section 5.2, the third bullet item: > > OLD: > > If multiple protection paths of equal priority are requesting > > allocation of the shared resources, the resources SHOULD be > > committed on a first come first served basis. > > NEW: > > If multiple protection paths of equal priority are requesting > > the shared resources, the resources SHOULD be > > assigned on a first come first served basis. > > > > (13) Section 5.2, the fourth bullet item: > > OLD: > > If the protection resources are committed to a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be committed to the higher priority > > path. > > NEW: > > If the protection resources are utilized by a protection path, > > whose working path has a lower priority, resources required for > > the higher priority path SHALL be assigned to the higher priority > > path. > > > > > > (14) Section 5.2. the seventh bullet item > > OLD: > > Once resources of shared segments have been successfully committed > > to a protection path, … > > NEW: > > Once resources of shared segments have been successfully utilized > > by a protection path, … > > > > (15) Section 5.3, the first paragraph, > > OLD: > > … request the commitment of protection resources. If the necessary > > shared resources are unavailable to be committed to the protection > > path, the endpoints … > > > > NEW: > > … request the coordination of the shared resource utilization. If > the necessary > > shared resources are unavailable, the endpoints … > > > > (16) Section 5.3, the second paragraph, > > OLD: > > Similarly, if preemption is supported and the resources currently > > committed for a particular working path are … > > NEW: > > Similarly, if preemption is supported and the resources currently > > utilized by a particular working path are … > > > > > > - Section 2, 1st paragraph, last sentence. This sentence really > defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > [Authors] We can add the following paragraph at the end of Section 1: > > “This document is intended to clarify the instructions to protocol > designers producing solutions that satisfy the requirements set > out in this document.†> > > > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > [Authors] Fate-sharing is not required by this document. Even in > the PSC linear protection switching, such as RFC 6378 (PSC) and > RFC 7271 (PSC in APS mode), fate-sharing is not required as > unidirectional switching is allowed. This document does not impose > any restriction on co-routing, either. > > > > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > [Authors] One concern is that RFC 6372 describes both soft and > hard preemptions in the context of extra traffic, which is not > exactly the case for SMP. > > > > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > [Authors] Yes, we will make the correction. > > > > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > [Authors] The first case is the one we are aiming at. We will use > SHALL NOT. > > > > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > [Authors] The sentence can be rewritten as: > > OLD: > > Tie-breaking rules SHALL be defined in scope of an SMP domain. > > NEW: > > In order to cover the situation where the first come first served > principle cannot resolve the contention among multiple equal > priority requests, i.e., when the requests occur simultaneously,, > tie-breaking rules SHALL be defined in scope of an SMP domain. > > > > > > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > [Authors] We can add the following sentence at the end: > > “As described in [RFC6372], the event of preemption may be > detected by OAM and reported as a fault or a degradation of > traffic delivery.†> > > - Section 5.7. There may be coordination required on > soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > [Authors] Yes, we will change the second paragraph from “SMP in > hard-preemption mode SHOULD …†to “SMP SHOULD …†and move the > changed paragraph above the first paragraph. > > > > > Nits: > > - Abstract: I don't recall the term "executive action" being used > in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > [Authors] Yes, the term will be changed as you suggested. > > > > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > [Authors] The proposed text for the paragraph 1 is: > > “The MPLS Transport Profile (MPLS-TP) is described in [RFC5921], > > and [RFC6372] provides a survivability framework for MPLS-TP > > and is the foundation for this document.†> > > > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > [Authors] OK. > > > > > > > - Sections 3 (and to a lesser degree section 2) are really > introductory > text. I'm unsure as to why they aren't part of section 1. > > [Authors] Section 3 was intended to present a reference model for > SMP. Some text of Section 2 is repeated in Section 1 as you > suggested earlier. > > > > > > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > [Authors] [RFC4206] will be added as a reference > > > - Section 3.2 again uses the "executive action" term. > > [Authors] OK, the term will be changed. > > > > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > [Authors] Both actions should occur at the same time, or as > closely as possible to provide fast protection. > > > > > - Section 5.2. I suggest numbering the currently bulletted > requirements > list. > > [Authors] OK, we will use numbers. > > > > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > [Authors] The first paragraph is for soft-preemption, while the > fourth bullet belongs to the requirements of hard-preemption. > > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > [Authors] Yes, req 5 can be moved to Section 5.5. > > > > > - Section 5.2: requirement 6 seems to be a subset of 7, so it > should be > dropped. > > [Authors] Yes, it will be deleted. > > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > [Authors] Req. 9 will be deleted as it seems to require control > plane supports. > > > > - Section 5.3. s/MAY/will > > [Authors] OK. > > > > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > [Authors] Yes. We will simply say that “When the condition that > triggered the protection switching is cleared, …†> > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > [Authors] As in other protection switching technologies, two modes > of operations (revertive and non-revertive) are required. > > > > > - section 5.6. RFC 6372 should be referenced > > [Authors] We will add “as described in [RFC6372]†to the ends of > two paragraphs for WTR timer and hold-off timer. > > > > ***** End of Comment resolution ***** > > > > > > > ------------------------------------------------------------------------ > *보낸 사람 : *"Lou Berger" > > *보낸 날짜 : *2014-06-22 01:00:48 ( +09:00 ) > *받는 사람 : *rtg-ads@tools.ietf.org > > > *참조 : *rtg-dir@ietf.org > >, > draft-ietf-mpls-smp-requirements.all@tools.ietf.org > > >, > mpls@ietf.org > > *제목 : *[mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt > > > 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > 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-mpls-smp-requirements-06.txt > Reviewer: Lou Berger > Review Date: June 21 2014 > IETF LC End Date: 2014-06-23 > Intended Status: Informational > > Summary: > I have some minor concerns about this document that I think > should (must, actually) be resolved before publication. > > Comments: > > I think the document is well written and, other than a couple of > terminology related issues, easily understood. The document does > have a number of terminology and technical issues which should be > readily resolved prior to publication. > > Major Issues: > > Major issues are the type of concerns that will result in the > document being blocked until they are resolved. The Routing ADs will > become involved. Please include all of the major issues you have > found. Give as much context information as possible (e.g., section > numbers, paragraph counts). If you find no major issues, please > write: "No major issues found." > > - No major issues found. In particular, I expect all issues can be > resolved without AD intervention. Some of the minor issues, if not > resolved will be escalated to the AD/major issue category. > > Minor Issues: > > Minor issues are concerns about clarity or technical accuracy that > should be discussed and resolved before publication, but which would > normally be resolved between the authors and the reviewers. Please > include all of the minor issues you have found. Give as much context > information as possible (e.g., section numbers, paragraph counts). > If you find no minor issues, please write: "No minor issues found." > > - Document's usage of "committed" vs "allocated" resources: > > In section 1 the document introduces the notion that the > distinction between protection and restoration is based on when > resources are "committed". This difference from past > definition. RFC4427 and 6372 make the distinction that protection > and restoration differ based on when resources are *allocated* not > *committed*. To quote RFC 4427: > > The distinction between protection and restoration is made based > on the resource allocation done during the recovery LSP/span > establishment. The distinction between different types of > restoration is made based on the level of route computation, > signaling, and resource allocation during the restoration > LSP/span establishment. > > This difference also leads to come confused statements in the > document as well as ambiguity in the text, i.e. confusion by the > reader. The term "committed" is not tightly defined in this > document (or earlier work) and is used differently than how > "allocated" has been used. An example of this can be found in > Section 3.1 which states: > > However, the commitment of the resources, at least for the > shared segments, will only be finalized when the protection > path is actually activated. Therefore, for the purists - > regarding the terminology - SMP lies somewhere between > protection and restoration. > > Both sentences are problematic. In the first, commitment seems to > cover a "protection switch" would "connect" the protection path > but not the earlier "allocation" of resources. (Quoted terms are > used in earlier RFCs.) The second conclusion is based on the new > distinction of protection vs. restoration and is unnecessary with > the existing distinction. > > This issue exists in multiple places in the document where > "committed" is used and I'd recommend that each should be replaced > with terminology used in the referenced RFCs, i.e., "allocation", > "connection", "cross-connect", "protection switch(over)", ... > > Note I'm *not* highlighting all cases where there are problems in the > document related to this issue. There are a couple of places in the > document where I think it's possible that once this terminology > ambiguity is corrected that I'll have other substantive comments. > > - Section 2, 1st paragraph, last sentence. This sentence really > defines > the scope/purpose of the document, i.e., "clarifies the instructions > to protocol designers producing solutions that satisfy the > requirements set out in this document." As such, I'd repeat this in > the abstract and move it to a more pronounced place in section 1 (or > 3). > > - General comment: fate-sharing for co-routed bidirectional LSP > protection: How is co-routing preserved for the reverse path in SMP? > I'd assumed the protection switch coordination protocol would be > required to trigger a switchover of the reverse LSP in the co-routed > case, but don't see this in the document. > > - In section 4 and 5.2 you reference 5712 and 3209 as defining > preemption terminology and behavior. I think 6372 is the right > reference here as it defines both in the context of survivability and > in dependent of control plane. > > - In section 4.2 you say "Therefore, it is suggested that this be > carried out under the control of a dynamic control plane similar to > GMPLS [RFC3945]." perhaps you mean "based on GMPLS"? If so, great, > please make the correction. If not, I think the debate of which > control protocol is used for MPLS-TP is way beyond the scope of this > document. > > - Section 5.1, paragraph 1. Why are you using "SHOULD NOT" here? If > referring to solutions conformant with this document, then these are > informative statements, "and a non-control plane based SMP switchover > mechanism is used, the control plane SHALL NOT ...". If referring to > an operator's/user's choice of protection mechanism, I think the most > you can say is MAY. > > - Section 5.2. "Tie-breaking rules SHALL be defined in scope of an SMP > domain." As this is a requirement, what you mean by "tie-breaking > rules" should be defined directly or by reference. > > - Section 5.3. RFC6372 takes an approach where preemption notification > leverages the standard MPLS-TP OAM mechanisms, is there any reason to > do more / not just follow 6372? > > - Section 5.7. There may be coordination required on > soft-preemption as > well (depending on the cross-connects established during LSP > establishment) so coordinated switching should be supported > independent of preemption mode. > > Nits: > > - Abstract: I don't recall the term "executive action" being used > in any > earlier related/referenced RFCs. Rather than introduce a new (and > undefined) term, perhaps you can use an existing one, e.g., > "protection switch"? > > - Section 1, paragraph 1. Do we really need another definition of > MPLS-TP to debate? I suggest just referencing your favorite MPLS-TP > document(s) and dropping the first four sentences. > > The last sentence also makes a subjective statement. Whether it is > critical or no is unnecessary. You can just say something like 6372 > provides a survivability framework for MPLS-TP and is the foundation > for this document. > > - Section 1, paragraph 3. Isn't the right reference 4427 not 4428? > Also drop the word linear, as it is an unnecessary qualifier and > 4427/4428 don't use it. > > - Sections 3 (and to a lesser degree section 2) are really > introductory > text. I'm unsure as to why they aren't part of section 1. > > - Section 3.2 should have a reference for "existing control plane > solutions for SMP within MPLS". > > - Section 3.2 again uses the "executive action" term. > > - Section 4.1. You say "two operations simultaneously". Do you really > mean "simultaneously" or merely that they must both occur for > protection to be provided? (Same comment in section 5.1. > > - Section 5.2. I suggest numbering the currently bulletted > requirements > list. > > - Section 5.2: First paragraph and forth bullet last sentence. These > both basically cover the same topic (preemption) and actually say > slightly different things. I suggest combine into a single > requirement to ensure consistency and full coverage of the topic. > > - Section 5.2, req 5. How does this relate to section 5.5? Shouldn't > the topics related to timing be consolidated? > > - Section 5.2: requirement 6 seems to be a subset of 7, so it > should be > dropped. > > - Section 5.2, requirement 8. Isn't this a subset of 9? Why call out > just this one traffic treatment (sub) requirement? > > - Section 5.3. s/MAY/will > > - section 5.4: " When the working path detects.." detection is by the > node not the path. > > - Section 5.4, last sentence. This is only the 2nd time you imply that > the document covers requirements on a new protocol. I think this > point is currently too subtle in the document. (This point was also > made as a minor comment.) > > - section 5.6. RFC 6372 should be referenced > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Wed Jul 23 05:51:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35161A0B01; Wed, 23 Jul 2014 05:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QZtqQVZkb9G; Wed, 23 Jul 2014 05:51:28 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01AF1A0117; Wed, 23 Jul 2014 05:51:27 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 12:51:25 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 12:51:25 +0000 From: Alexander Vainshtein To: John Scudder , "Giles Heron (giheron)" Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf80czvDOyGBQEukadUvLR5gxJutSuGAgAB/voD//7KzgIAAAgqAgAAF68OAAABHcA== Date: Wed, 23 Jul 2014 12:51:25 +0000 Message-ID: <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com>, <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> In-Reply-To: <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(36944003)(24454002)(43544003)(13464003)(51704005)(189002)(252514010)(199002)(53754006)(85852003)(83072002)(107046002)(92566001)(106116001)(85306003)(99936001)(79102001)(76176999)(54356999)(95666004)(21056001)(76576001)(2656002)(87936001)(105586002)(74316001)(33646002)(101416001)(66066001)(31966008)(20776003)(81342001)(80022001)(99396002)(50986999)(81542001)(86362001)(4396001)(83322001)(74662001)(74502001)(93886003)(106356001)(19580405001)(15975445006)(46102001)(64706001)(77982001)(76482001)(19580395003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_002_036d1ff7201340c48135ac0a38b05684AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/LrOHBleAJiB91kA9eFsZKoYCMDo Cc: "rtg-dir@ietf.org" , Loa Andersson , "Andrew G. Malis" , Susan Hares , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:51:31 -0000 --_002_036d1ff7201340c48135ac0a38b05684AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, One example of "what is bad" is the cases when drafts reach advanced stage = (or even are published as RFCs) with serious technical problems/gaps. E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private LAN = Service (VPLS) Management Information Base" reporting what I see as a serio= us technical gap in an RFC that has been published earlier this month. Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mpls-d= eprecate-bgp-entropy-label: in this case the authors have discovered a seri= ous bug in an already published RFC 6970 that requires deprecation of one o= f its elements. While these case may be relatively rare, the definitely fall under the gene= ral category of "what is bad" IMO. I cannot point to any specific organizational or process change that would = reduce the number of these cases. But at least it makes sense to me to cons= ider them as valid use cases for estimating such changes. My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of John Scudder > Sent: Wednesday, July 23, 2014 2:24 PM > To: Giles Heron (giheron) > Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan Hares; = Loa > Andersson > Subject: Re: [RTG-DIR] what is so bad >=20 > On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)" > wrote: > > I think my point was rather that I'm not sure metrics are what we shoul= d be > concentrating on in this debate. Numbers can be made to say just about > anything, after all ;) >=20 > That was more-or-less the point I had been waiting to make when we ran ou= t > of time yesterday. That, plus, bad (or the wrong) metrics are worse than = no > metrics, so take care. >=20 > --John --_002_036d1ff7201340c48135ac0a38b05684AM3PR03MB612eurprd03pro_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 23 Jul 2014 12:51:23 GMT"; modification-date="Wed, 23 Jul 2014 12:51:23 GMT" Received: from DBXPR03MB619.eurprd03.prod.outlook.com (10.141.232.140) by AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) with Microsoft SMTP Server (TLS) id 15.0.990.7 via Mailbox Transport; Wed, 23 Jul 2014 12:38:55 +0000 Received: from AMSPR03CA0022.eurprd03.prod.outlook.com (10.242.14.150) by DBXPR03MB619.eurprd03.prod.outlook.com (10.141.232.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 23 Jul 2014 12:38:54 +0000 Received: from AM1FFO11FD037.protection.gbl (2a01:111:f400:7e00::194) by AMSPR03CA0022.outlook.office365.com (2a01:111:e400:8040::22) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Wed, 23 Jul 2014 12:38:54 +0000 Received: from to365.ecitele.com (147.234.56.21) by AM1FFO11FD037.mail.protection.outlook.com (10.174.64.226) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Wed, 23 Jul 2014 12:38:53 +0000 Received: from ILPTWPVEXCH01.ecitele.com (172.31.244.126) by ILPTWPVEXCH01.ecitele.com (172.31.244.126) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 23 Jul 2014 15:38:52 +0300 Received: from ilptbmg01-out.ecitele.com (147.234.242.231) by ILPTWPVEXCH01.ecitele.com (172.31.244.126) with Microsoft SMTP Server (TLS) id 15.0.913.22 via Frontend Transport; Wed, 23 Jul 2014 15:38:52 +0300 Received: from rfc-editor.org ( [4.31.198.49]) by ilptbmg01-out.ecitele.com (Messaging Gateway) with SMTP id 9F.9E.22932.302BFC35; Wed, 23 Jul 2014 16:00:54 +0300 (IDT) Received: by rfc-editor.org (Postfix, from userid 30) id E2ED9180015; Wed, 23 Jul 2014 05:37:32 -0700 (PDT) From: RFC Errata System To: "tnadeau@lucidvision.com" , "kkoushik@brocade.com" , "romedira@cisco.com" , "akatlas@gmail.com" , "adrian@olddog.co.uk" , "giheron@cisco.com" , "nabil.n.bitar@verizon.com" CC: Alexander Vainshtein , "l2vpn@ietf.org" , "rfc-editor@rfc-editor.org" Subject: [Technical Errata Reported] RFC7257 (4059) Thread-Topic: [Technical Errata Reported] RFC7257 (4059) Thread-Index: AQHPpnMRE/4IRKA2CEa4SUg+NYe9Hg== Date: Wed, 23 Jul 2014 12:37:32 +0000 Message-ID: <20140723123732.E2ED9180015@rfc-editor.org> Content-Language: en-US X-MS-Exchange-Organization-AuthSource: AM1FFO11FD037.protection.gbl X-MS-Has-Attach: X-MS-TNEF-Correlator: x-auditid: 93eaf2e7-f79096d000005994-a3-53cfb2027cb0 x-brightmail-tracker: H4sIAAAAAAAAA+NgFlrHIsWRWlGSWpSXmKPExsXCIn/MUJdt0/lggyVPGS2mbv3A7MDosenf ccYAxigum5TUnMyy1CJ9uwSujFU7ZrIVtAtVvF2+gbWB8ThfFyMnh4SAiUT7zousIDajgI3E 7lsz2CHiYhIX7q1n62Lk4hASWMUo0dN4mA0kISSQK9Gw4SsrSEJEYDajxJTzT5m7GDk4hAWM JV7O4QcxJQSMJFbuyQQpZwOKXlvyDqyVWcBfYse7eUwgNq+AucTSA9vAdrEIaEtcbd3ENoGR ZwEjwypG0cycgpKk3HQDQ73U5MyS1JxUveT83E2MQM9OfvXp+Q7GX/NVDjEKcDAq8fAqNp4L FmJNLCuuzD3EKMnBpCTKq7jkfLAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7VPUA53pTEyqrU onyYlDQHi5I4b4pUZLCQQHpiSWp2ampBahFMlomD/RCjDAeHkgTvj9VA3YJFqempFWmZOSXI ajhBBBfIGh6gNV9ACnmLCxJzizPTIYpOMSpKifNuA0kIgCQySvPgBsCi8RKjrJQwLyMDA4MQ D9AFuZklqPKvGMWBnhbm5V4DNIUnM68EbvoroMVMQItfJYAtLklESEk1MJplK3nmzzrVxOp1 uePWsXc7rir980tIkN8TPHl1apKNe3CCWXLk11jV2aIfT3z5+sr27941i2ZxFqhtDO4+siru x7bLN04vbVV5+/fLbkOLe9paajbX+Byu/GBQ+Xc81jv/y4oshYsxAmEb2/7FiR6Yeyk9s+tD twevQUODwvafMpvzKp/cdlJiKc5INNRiLipOBAChbcKTwQIAAA== authentication-results: symauth.service.identifier; spf=pass x-forefront-antispam-report: CIP:147.234.56.21;CTRY:IL;IPV:CAL;IPV:NLI;IPV:NLI;EFV:NLI;SFV:SKN;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:DBXPR03MB619;H:to365.ecitele.com;FPR:;LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 The following errata report has been submitted for RFC7257, "Virtual Private LAN Service (VPLS) Management Information Base". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D7257&eid=3D4059 -------------------------------------- Type: Technical Reported by: Alexander ("Sasha") Vainshtein Section: 6 Original Text ------------- N/A - this is about some missing MIB objects that should be there Corrected Text -------------- N/A - this is hardly the right place to define missing MIB objects Notes ----- As per RFC 4762 (which defines at least one of the two VPLS types for which= this RFC defines Management Information Base), Virtual Switching Instance = (VSI)(a local representation of a given VPLS instance within a given PE) is= connected to CE devices via Attachment Circuits (AC). Hence I would expect= that Management Information Base for VPLS would provide for some represent= ation of ACs that perform this function for a given VSI. However, this RFC does not even mention attachment circuits in any way. I have tried to raise this issue with the WG and the authors. One of the au= thors has replied (see http://www.ietf.org/mail-archive/web/l2vpn/current/m= sg04539.html) that "ACs are attached to the VPLS instances and are represen= ted as IfMIB entries". However, neither Interfaces MIB nor any of its key e= lements (e.g., ifIndex) are mentioned in this RFC. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7257 (draft-ietf-l2vpn-vpls-mib-15) -------------------------------------- Title : Virtual Private LAN Service (VPLS) Management Informa= tion Base Publication Date : July 2014 Author(s) : T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, = Ed. Category : PROPOSED STANDARD Source : Layer 2 Virtual Private Networks Area : Routing Stream : IETF Verifying Party : IESG --_002_036d1ff7201340c48135ac0a38b05684AM3PR03MB612eurprd03pro_-- From nobody Wed Jul 23 06:11:01 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19571A0AD5; Wed, 23 Jul 2014 06:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt-ho8iFKK1q; Wed, 23 Jul 2014 06:10:51 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE71D1A0AE8; Wed, 23 Jul 2014 06:10:50 -0700 (PDT) Received: from [172.16.57.142] (unknown [206.47.221.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1BDED1802B19; Wed, 23 Jul 2014 15:10:48 +0200 (CEST) Message-ID: <53CFB462.8030603@pi.nu> Date: Wed, 23 Jul 2014 15:10:58 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Giles Heron (giheron)" , "Andrew G. Malis" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> In-Reply-To: <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/0w1GJJDg5Itzf76HvTNZzwKjIB0 Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:10:58 -0000 Giles and John, On 2014-07-23 12:32, Giles Heron (giheron) wrote: Giles: > like I say, does this really mean anything? Can I have the last half > hour of my life (or rather 1/66 of a football match) back? John: "bad (or the wrong) metrics are worse than no metric" You make my point! What I did to try to see if I by some simple (non-scientific) method could find some proof of what has been in this debate from the beginning. Restating this slightly "Giant working groups are inefficient since a large number of people will have to spend boring time listening to discussions/presentations on thing they are not interested in." Giant where not defined and the problem with statements that are made over and over again is that they over time become "true" even if there are nothing to substantiate them. Over time they become as bad as bad statistic! I don't think the original slide show anything that support the allegation above. It is true that the number of people in the room, the length of football matches, slot duration, the weather outside, the location, etc. If there is a small conclusion we can draw ii is that the people that are interested come to the wg meetings and we make good progress regardless of how many drone or tourists we have in the meeting. There has also been alleged that big groups have a higher ratio of drones, I can't find any support for that allegation. In summary - the metrics I have is useless when it comes to motivate or de-motivate an area re-org. To repeat what in the first mail, and which I think it would be good to converge on: I'm totally supportive of some well considered re-organization of working groups, - don't re-org the area, re-org working groups - do it carefully - at a time when it is optimal for the working groups - involve the chairs to drive the re-org - don't break things that work /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 06:30:54 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B7A1B2957; Wed, 23 Jul 2014 06:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKON3IM9bpyu; Wed, 23 Jul 2014 06:30:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF3E1B2955; Wed, 23 Jul 2014 06:30:50 -0700 (PDT) Received: from [172.16.57.142] (unknown [206.47.221.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8F18F1802B19; Wed, 23 Jul 2014 15:30:47 +0200 (CEST) Message-ID: <53CFB910.3030607@pi.nu> Date: Wed, 23 Jul 2014 15:30:56 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexander Vainshtein , John Scudder , "Giles Heron (giheron)" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com>, <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Riby_BIgNqb9_DJpIvYvhuX2BV0 Cc: "rtg-dir@ietf.org" , "Andrew G. Malis" , Susan Hares , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:30:53 -0000 Sasha, I agree that what you list are example of "bad things"! However, I don't see how it is related to a re-org of the area (which I also think is a bad idea) or of wg groups (which at times might be a very good idea). This I think is more related to another (good) initiative taken by the AD's - the working chair training; it also could be related to initiatives taken by some wg chairs, the wg review teams! It might be of interest that what is now RFC 6790 (which is the RFC I think you mean) was accepted as a wg doc before the MPLS-RT were looking at all MPLS drafts. /Loa On 2014-07-23 14:51, Alexander Vainshtein wrote: > Hi all, > One example of "what is bad" is the cases when drafts reach advanced stage (or even are published as RFCs) with serious technical problems/gaps. > > E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private LAN Service (VPLS) Management Information Base" reporting what I see as a serious technical gap in an RFC that has been published earlier this month. > > Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label: in this case the authors have discovered a serious bug in an already published RFC 6970 that requires deprecation of one of its elements. > > While these case may be relatively rare, the definitely fall under the general category of "what is bad" IMO. > > I cannot point to any specific organizational or process change that would reduce the number of these cases. But at least it makes sense to me to consider them as valid use cases for estimating such changes. > > My 2c, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 > >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of John Scudder >> Sent: Wednesday, July 23, 2014 2:24 PM >> To: Giles Heron (giheron) >> Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan Hares; Loa >> Andersson >> Subject: Re: [RTG-DIR] what is so bad >> >> On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)" >> wrote: >>> I think my point was rather that I'm not sure metrics are what we should be >> concentrating on in this debate. Numbers can be made to say just about >> anything, after all ;) >> >> That was more-or-less the point I had been waiting to make when we ran out >> of time yesterday. That, plus, bad (or the wrong) metrics are worse than no >> metrics, so take care. >> >> --John -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 06:46:52 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D21B2793; Wed, 23 Jul 2014 06:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXkfhd6mIkzm; Wed, 23 Jul 2014 06:46:41 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E202C1A0AC9; Wed, 23 Jul 2014 06:46:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.162.238; From: "Susan Hares" To: "'Giles Heron \(giheron\)'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> In-Reply-To: <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> Date: Wed, 23 Jul 2014 09:46:39 -0400 Message-ID: <005c01cfa67c$87b42780$971c7680$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKoEM/Y/Vubz9dfpwP/nDHHq79/PAH8SQ9wApok1FgByE30QAMeS+r2AWPA0fICCrwfdwIpoaPdAdDjzH4CWHgAopli4nsg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/41oTOktqIrx0YBOBiEqiepUq8TI Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org, "'Andrew G. Malis'" , 'Loa Andersson' Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:46:46 -0000 Giles: Ah... Do you have a proposal for what you consider valid, and reasons for abandoning the traditional statistics. Sue -----Original Message----- From: Giles Heron (giheron) [mailto:giheron@cisco.com] Sent: Wednesday, July 23, 2014 7:03 AM To: Susan Hares Cc: Andrew G. Malis; Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad Hi Sue, I think my point was rather that I'm not sure metrics are what we should be concentrating on in this debate. Numbers can be made to say just about anything, after all ;) Giles On 23 Jul 2014, at 11:55, Susan Hares wrote: > Giles: > > The performance that IETF has utilized for its ADs, IETF chairs, and WG groups for 20 years has been: > > Quantitative: > 1) RFC published > 2) WG groups formed and completed > 3) Administrative effectiveness (AFI/SAFIs, early code adoption, ports assigned. ) > 4) Number of authors and demographics on authors > 5) Statistics on the timing of RFCs and the timing of WG forming > 6) Statistics on attendance in WG/ IETF > > Please note, I do know of a statistically valid analysis of the correlation between #6 an #1. If you do, I would be interested. > > Qualitatively > 1) Technologies described in RFCs get deployed. > 2) IETF is collaborative (at IESG, at WG), > 3) People want to come (from surveys) > > The "people" want to come falls into a qualitative experience that says "important to learn about the technology". > > http://www.arkko.com/tools/docstats.html has document statistics. > > If you want to propose a new metric it can be useful going forward, but unless it is built on the data kept by the datatracker, we do not have the past trends to defend it. You could also use the mail list information, but we would need to use a long-running group to get a valid statistics. > > Sue > From: Giles Heron (giheron) [mailto:giheron@cisco.com] > Sent: Wednesday, July 23, 2014 6:32 AM > To: Andrew G. Malis > Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] what is so bad > > I'm not sure that how helpful the exercise is? Is performance really related to how many people show up? There's no way after all to determine what fraction of attendees are active participants vs "IETF tourists". And of course we're supposed to do more work outside meetings than in them. > > At any rate to be meaningful at all we need to weight the results by length of WG meeting as time is the constraint we're trying to optimise for here (I think!). I counted WG meeting durations in minutes (since L2VPN was 2 hours 10 mins - and I didn't have the time to type a recurring decimal). Couldn't find ROLL on the Vancouver Agenda though - so I used their London duration. Of course then the RFCs per minute were all rather low. In honour of the recent World Cup I went for RFCs per football match (counting only the players and the playing minutes - no allowance for referees, half-time, injury time or extra time). > > the results show PWE3 a mile ahead of the rest, followed by BFD, then MPLS, then a cluster of WGs with very similar productivity (L2VPN leading those by a nose, but who am I to brag?) with L3VPN and then PCE (possibly the victim of the recent SDN hype) bringing up the rear. > > like I say, does this really mean anything? Can I have the last half hour of my life (or rather 1/66 of a football match) back? > > Giles > > > > > On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: > > > Loa, > > > > I added one more column, to total all of the RFCs over the period. mpls came in first in terms of total RFCs per capita, and pwe3 came in second. I also agree with your conclusions. > > > > Cheers, > > Andy > > > > > > On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: > > Folks, > > > > I took a look at the performance on rtg wg's. > > > > The spread sheet list the number of RFC's per working group between > > two meeting. I've used the number of people who signed the blue > > sheets in Vancouver as some type of average except for roll that did > > not meet in Vancouver, where I used the London figure instead. > > > > Calculated the number of RFCs per person in the room. > > > > The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. > > The highest absolute number of RFC is MPLS (this meeting). > > The best trend has MPLS. > > > > Since I don't care too much about how much noise the > > non-participating participants is exposed too, I don't think the a > > re-org is motivated by the figures in the spread sheet. > > > > I guess I would go as far as too say that no arguments presented so > > far motivates a re-org of the RTG area. > > > > Though I'm totally supportive of some well considered > > re-organization of working groups, but > > > > - do it carefully > > - at a time when it is optimal for the working groups > > - involve the chairs to drive the re-org > > - don't break things that work > > > > /Loa > > > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > From nobody Wed Jul 23 06:58:50 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E071A0B0B; Wed, 23 Jul 2014 06:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxuZloHKMZXF; Wed, 23 Jul 2014 06:58:46 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5BA1ACAD6; Wed, 23 Jul 2014 06:58:46 -0700 (PDT) Received: from [172.16.57.142] (unknown [206.47.221.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4A81B18013DA; Wed, 23 Jul 2014 15:58:44 +0200 (CEST) Message-ID: <53CFBF9D.9030300@pi.nu> Date: Wed, 23 Jul 2014 15:58:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Susan Hares , "'Giles Heron (giheron)'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <005c01cfa67c$87b42780$971c7680$@ndzh.com> In-Reply-To: <005c01cfa67c$87b42780$971c7680$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/rvnJ_wFinz1HeeJVurXvWLie9Xo Cc: rtg-dir@ietf.org, "'Andrew G. Malis'" , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:58:48 -0000 Sue, I don't think that Giles says that we should abandon traditional statistics, merely that the "numbers" the way I used can be made to show what you want them to show. And sure I agree to that. I further think that there are no way to actually show what has been alleged about giant groups and long periods of uninteresting presentations. It is simply not true. Though it is possible to to make it seem true by repeating it often enough. I would be in favor of having some useful traditional statistics available per working group if it can be achieved with a reasonable amount of work. /Loa On 2014-07-23 15:46, Susan Hares wrote: > Giles: > > Ah... Do you have a proposal for what you consider valid, and reasons for > abandoning the traditional statistics. > > Sue > > -----Original Message----- > From: Giles Heron (giheron) [mailto:giheron@cisco.com] > Sent: Wednesday, July 23, 2014 7:03 AM > To: Susan Hares > Cc: Andrew G. Malis; Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] what is so bad > > Hi Sue, > > I think my point was rather that I'm not sure metrics are what we should be > concentrating on in this debate. Numbers can be made to say just about > anything, after all ;) > > Giles > > On 23 Jul 2014, at 11:55, Susan Hares wrote: > >> Giles: >> >> The performance that IETF has utilized for its ADs, IETF chairs, and WG > groups for 20 years has been: >> >> Quantitative: >> 1) RFC published >> 2) WG groups formed and completed >> 3) Administrative effectiveness (AFI/SAFIs, early code adoption, > ports assigned. ) >> 4) Number of authors and demographics on authors >> 5) Statistics on the timing of RFCs and the timing of WG forming >> 6) Statistics on attendance in WG/ IETF >> >> Please note, I do know of a statistically valid analysis of the > correlation between #6 an #1. If you do, I would be interested. >> >> Qualitatively >> 1) Technologies described in RFCs get deployed. >> 2) IETF is collaborative (at IESG, at WG), >> 3) People want to come (from surveys) >> >> The "people" want to come falls into a qualitative experience that says > "important to learn about the technology". >> >> http://www.arkko.com/tools/docstats.html has document statistics. >> >> If you want to propose a new metric it can be useful going forward, but > unless it is built on the data kept by the datatracker, we do not have the > past trends to defend it. You could also use the mail list information, > but we would need to use a long-running group to get a valid statistics. >> >> Sue >> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >> Sent: Wednesday, July 23, 2014 6:32 AM >> To: Andrew G. Malis >> Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: Re: [RTG-DIR] what is so bad >> >> I'm not sure that how helpful the exercise is? Is performance really > related to how many people show up? There's no way after all to determine > what fraction of attendees are active participants vs "IETF tourists". And > of course we're supposed to do more work outside meetings than in them. >> >> At any rate to be meaningful at all we need to weight the results by > length of WG meeting as time is the constraint we're trying to optimise for > here (I think!). I counted WG meeting durations in minutes (since L2VPN was > 2 hours 10 mins - and I didn't have the time to type a recurring decimal). > Couldn't find ROLL on the Vancouver Agenda though - so I used their London > duration. Of course then the RFCs per minute were all rather low. In > honour of the recent World Cup I went for RFCs per football match (counting > only the players and the playing minutes - no allowance for referees, > half-time, injury time or extra time). >> >> the results show PWE3 a mile ahead of the rest, followed by BFD, then > MPLS, then a cluster of WGs with very similar productivity (L2VPN leading > those by a nose, but who am I to brag?) with L3VPN and then PCE (possibly > the victim of the recent SDN hype) bringing up the rear. >> >> like I say, does this really mean anything? Can I have the last half > hour of my life (or rather 1/66 of a football match) back? >> >> Giles >> >> >> >> >> On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: >> >>> Loa, >>> >>> I added one more column, to total all of the RFCs over the period. mpls > came in first in terms of total RFCs per capita, and pwe3 came in second. I > also agree with your conclusions. >>> >>> Cheers, >>> Andy >>> >>> >>> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: >>> Folks, >>> >>> I took a look at the performance on rtg wg's. >>> >>> The spread sheet list the number of RFC's per working group between >>> two meeting. I've used the number of people who signed the blue >>> sheets in Vancouver as some type of average except for roll that did >>> not meet in Vancouver, where I used the London figure instead. >>> >>> Calculated the number of RFCs per person in the room. >>> >>> The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. >>> The highest absolute number of RFC is MPLS (this meeting). >>> The best trend has MPLS. >>> >>> Since I don't care too much about how much noise the >>> non-participating participants is exposed too, I don't think the a >>> re-org is motivated by the figures in the spread sheet. >>> >>> I guess I would go as far as too say that no arguments presented so >>> far motivates a re-org of the RTG area. >>> >>> Though I'm totally supportive of some well considered >>> re-organization of working groups, but >>> >>> - do it carefully >>> - at a time when it is optimal for the working groups >>> - involve the chairs to drive the re-org >>> - don't break things that work >>> >>> /Loa >>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >>> >> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 06:59:29 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078B31AC0D1; Wed, 23 Jul 2014 06:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huovxACoxv6n; Wed, 23 Jul 2014 06:59:23 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D311A0B0B; Wed, 23 Jul 2014 06:59:23 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 13:59:20 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 13:59:20 +0000 From: Alexander Vainshtein To: Loa Andersson Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf80czvDOyGBQEukadUvLR5gxJutSuGAgAB/voD//7KzgIAAAgqAgAAF68OAAABHcIAAIx0AgAAEyiA= Date: Wed, 23 Jul 2014 13:59:19 +0000 Message-ID: References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com>, <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> <53CFB910.3030607@pi.nu> In-Reply-To: <53CFB910.3030607@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377424004)(53754006)(252514010)(199002)(189002)(51704005)(24454002)(377454003)(36944003)(13464003)(43544003)(74316001)(19580405001)(99396002)(95666004)(50986999)(76176999)(83322001)(54356999)(80022001)(74502001)(74662001)(101416001)(106356001)(46102001)(105586002)(15975445006)(77982001)(110136001)(66066001)(33646002)(31966008)(19580395003)(64706001)(106116001)(86362001)(76576001)(92566001)(107046002)(76482001)(4396001)(87936001)(20776003)(81342001)(81542001)(83072002)(79102001)(2656002)(85306003)(93886003)(21056001)(85852003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/9JxiCfLqm6r4j0bjrV5FL4aTJkc Cc: "rtg-dir@ietf.org" , "Giles Heron \(giheron\)" , "Andrew G. Malis" , "rtg-chairs@ietf.org" , John Scudder , Susan Hares Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:59:27 -0000 Loa, Lots of thanks for a prompt and encouraging in a way) response. I have already said in my email that "I cannot point to any specific organi= zational or process change that would reduce the number of these cases". This seems to me pretty close what you have said in your email: these prob= lems should be handled by introducing some new elements in the process (int= ra-WG, inter-WG or both) rather than by re-shuffling the WGs. I wonder if we could collect some statistics related to quality of our docu= ments. E.g., number of validated technical errata? number of iterations of= the draft after the WG has requested its publication and until it has been= approved for publication? This seems to me more relevant than the number o= f people attending the WG F2F sessions (possibly because I have not been at= tending them for quite some time;-). My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, July 23, 2014 4:31 PM > To: Alexander Vainshtein; John Scudder; Giles Heron (giheron) > Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan Hares > Subject: Re: [RTG-DIR] what is so bad >=20 > Sasha, >=20 > I agree that what you list are example of "bad things"! >=20 > However, I don't see how it is related to a re-org of the area (which I a= lso > think is a bad idea) or of wg groups (which at times might be a very good > idea). >=20 > This I think is more related to another (good) initiative taken by the AD= 's - the > working chair training; it also could be related to initiatives taken by = some wg > chairs, the wg review teams! >=20 > It might be of interest that what is now RFC 6790 (which is the RFC I thi= nk you > mean) was accepted as a wg doc before the MPLS-RT were looking at all > MPLS drafts. >=20 > /Loa >=20 >=20 >=20 > On 2014-07-23 14:51, Alexander Vainshtein wrote: > > Hi all, > > One example of "what is bad" is the cases when drafts reach advanced > stage (or even are published as RFCs) with serious technical problems/gap= s. > > > > E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private = LAN > Service (VPLS) Management Information Base" reporting what I see as a > serious technical gap in an RFC that has been published earlier this mont= h. > > > > Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mp= ls- > deprecate-bgp-entropy-label: in this case the authors have discovered a > serious bug in an already published RFC 6970 that requires deprecation of > one of its elements. > > > > While these case may be relatively rare, the definitely fall under the > general category of "what is bad" IMO. > > > > I cannot point to any specific organizational or process change that wo= uld > reduce the number of these cases. But at least it makes sense to me to > consider them as valid use cases for estimating such changes. > > > > My 2c, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > >> -----Original Message----- > >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of John > >> Scudder > >> Sent: Wednesday, July 23, 2014 2:24 PM > >> To: Giles Heron (giheron) > >> Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan > >> Hares; Loa Andersson > >> Subject: Re: [RTG-DIR] what is so bad > >> > >> On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)" > >> > >> wrote: > >>> I think my point was rather that I'm not sure metrics are what we > >>> should be > >> concentrating on in this debate. Numbers can be made to say just > >> about anything, after all ;) > >> > >> That was more-or-less the point I had been waiting to make when we > >> ran out of time yesterday. That, plus, bad (or the wrong) metrics are > >> worse than no metrics, so take care. > >> > >> --John >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 07:26:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9343C1B280E; Wed, 23 Jul 2014 07:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MiJbWhlj7lh; Wed, 23 Jul 2014 07:26:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF81B27CA; Wed, 23 Jul 2014 07:26:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 384ABC1FA; Wed, 23 Jul 2014 10:26:30 -0400 (EDT) Date: Wed, 23 Jul 2014 10:26:30 -0400 From: Jeffrey Haas To: "Giles Heron (giheron)" Message-ID: <20140723142630.GC4653@pfrc> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/VKz4vjPIdFzTt_NJ-d5gaZaOGxA Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , "Andrew G. Malis" , Loa Andersson Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:26:32 -0000 On Wed, Jul 23, 2014 at 10:32:27AM +0000, Giles Heron (giheron) wrote: > the results show PWE3 a mile ahead of the rest, followed by BFD, then > MPLS, then a cluster of WGs with very similar productivity (L2VPN leading > those by a nose, but who am I to brag?) with L3VPN and then PCE (possibly > the victim of the recent SDN hype) bringing up the rear. PWE3 beat BFD? Wow... we'll have to step up productivity in BFD then. :-) To some extent, this was the source of my strong disapproval of the functional merge. For BFD, what we have seems to be working. We didn't meet for a while because it was unnecessary. When we did, drafts moved along very quickly. I agree we should address the functional grouping issues. The solution space is what I question. -- Jeff From nobody Wed Jul 23 07:38:56 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893E41B2A68; Wed, 23 Jul 2014 07:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr8nuPy5BHOw; Wed, 23 Jul 2014 07:38:53 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07021B2AAD; Wed, 23 Jul 2014 07:37:27 -0700 (PDT) Received: from [172.16.57.142] (unknown [206.47.221.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3772318013DA; Wed, 23 Jul 2014 16:37:26 +0200 (CEST) Message-ID: <53CFC8AF.8060508@pi.nu> Date: Wed, 23 Jul 2014 16:37:35 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeffrey Haas References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <20140723142630.GC4653@pfrc> In-Reply-To: <20140723142630.GC4653@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/VNjs9ic5qMdftpbbmxxJ9dubVZA Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:38:54 -0000 Jeff, On 2014-07-23 16:26, Jeffrey Haas wrote: > For BFD, what we have seems to be working. I think this is key - what we have for BFD is working! Further, BFD is not generating any particular problems for other working group. Conclusions: Don't touch BFD. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 07:48:12 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB69B1B27D1; Wed, 23 Jul 2014 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrvCg1DPQT6O; Wed, 23 Jul 2014 07:48:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 222F71B27CA; Wed, 23 Jul 2014 07:48:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D1766C1FA; Wed, 23 Jul 2014 10:48:06 -0400 (EDT) Date: Wed, 23 Jul 2014 10:48:06 -0400 From: Jeffrey Haas To: Loa Andersson Message-ID: <20140723144806.GF4653@pfrc> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <20140723142630.GC4653@pfrc> <53CFC8AF.8060508@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CFC8AF.8060508@pi.nu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/SIRBlo1DackzUml3PMdkqDTXgbc Cc: Jeffrey Haas , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:48:07 -0000 On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson wrote: > On 2014-07-23 16:26, Jeffrey Haas wrote: > > For BFD, what we have seems to be working. > > I think this is key - what we have for BFD is working! > > Further, BFD is not generating any particular problems for > other working group. > > Conclusions: Don't touch BFD. That said, let's find a way to coordinate OAM across groups, including BFD. In my discussions with Alia, I'm fond of the idea of "meta" WGs. Individual work functions that implement IETF process (drafts, chairs, etc.) should be partially apportioned based on not overloading any given function or individual. This was part of my comment about such a merger likely involving adding a third chair. But as Brooks' book tells us, adding more people simply may make late work later - simply due to the need for increased communication in the project. What we definitely could use is a meeting of the meta-group, even if only on a chairs basis, regularly. As long as we're talking amongst each other, we have IETF leadership level communication. The question of whether we need IETF participant communication broadened can be serviced by targeted presentation of related work in an appropriate place. That could happen either in existing WG context (preserve WG work pipelining) or do more open meeting. Frankly, the Monday night dinner we had with several of our key BFD members which also included significant conversation about relationships to non-BFD OAM (e.g. CFM) was what we really need. -- Jeff From nobody Wed Jul 23 07:51:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489BD1B29CE for ; Wed, 23 Jul 2014 07:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2gvG1jkzDv2 for ; Wed, 23 Jul 2014 07:51:13 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBE81B2A0F for ; Wed, 23 Jul 2014 07:51:13 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so2337408vcb.29 for ; Wed, 23 Jul 2014 07:51:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fNkZ+izx5jRQ9NMlsurVEyBRmlOZCIogjqoAEG7elDA=; b=AXsJwU9LVIFB1EhfT4dSGUgQZRoxRseTmUdtdJZsWWZs9rKJmoc7isC1OiaTc9dXSs BZiSHEMeYhLyDXgTzE2/PTWgTksGCf1DdzcdkxS14XkXTSz0cIQhR2KqTA5IS+kvpahi smOCsjBlP4a0JLgTQWq0RKaqcat26Ow4haeSDDM0kpFxiru0kAXr1EsIsPlkFtt45eWi 2gARrr3VxhxQ/3CbfYogEkeLS0L50V/QVyIsj24xnv48fZK5KhN7KysuEe0on8BhEiFb porP6kvihgguOiuJIYioSQb5w/pkK2DVknK2EVaIVshJhqZGqrF0m9zHnywJ+4q0PZlE uokw== X-Gm-Message-State: ALoCoQlOFPz47gECkAnVei5XdFSHI1DW+FwcMmsSHOBdDOdfYl61+S60BqqPMolx2CcSCNaSEBO5 X-Received: by 10.220.122.132 with SMTP id l4mr2722322vcr.41.1406127068660; Wed, 23 Jul 2014 07:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.236.199 with HTTP; Wed, 23 Jul 2014 07:50:48 -0700 (PDT) In-Reply-To: <53CFBF9D.9030300@pi.nu> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <005c01cfa67c$87b42780$971c7680$@ndzh.com> <53CFBF9D.9030300@pi.nu> From: Jamal Hadi Salim Date: Wed, 23 Jul 2014 10:50:48 -0400 Message-ID: To: Loa Andersson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/L71VjglszzkmIUklTVqzgGYYgt4 Cc: "rtg-dir@ietf.org" , "Giles Heron \(giheron\)" , "Andrew G. Malis" , Susan Hares , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:51:19 -0000 Loa, Couple of things that will improve the stats. 1) a column of documents that are in "publication process" 2) Life cycles of the WG: Example ForCES new charter starts at IETF 87. IETF 86 and 85 were discussions on re-charter. I am not sure how one would go about quantifying that in a spread sheet. I am not sure i subscribe to the quantity=quality arguement. Sue, The metric on "demographics and number of authors on an RFC" is easy to hack (and has been taken advantage of before). Get all kinds of big name corps to endorse your doc etc. I think this got so bad that at some point it was concluded cant have more than 5 authors max. So not sure how such a metric is useful. http://www.arkko.com/tools/docstats.html has some really good stats that could also be utilized as you pointed out. How many people attend and consistency of attendance over time is important. But i dont think you should count the first 1-3 meetings which is high tourist season (as it is right now in SFC where i am sitting). I do think as a tourist i had a choice to be here and my presence counts because i could have been doing something else instead. And tourists do become tenants. cheers, jamal On Wed, Jul 23, 2014 at 9:58 AM, Loa Andersson wrote: > Sue, > > I don't think that Giles says that we should abandon traditional > statistics, merely that the "numbers" the way I used can be made to > show what you want them to show. And sure I agree to that. > > I further think that there are no way to actually > show what has been alleged about giant groups and long periods of > uninteresting presentations. It is simply not true. Though it is > possible to to make it seem true by repeating it often enough. > > I would be in favor of having some useful traditional statistics > available per working group if it can be achieved with a reasonable > amount of work. > > /Loa > > > On 2014-07-23 15:46, Susan Hares wrote: >> >> Giles: >> >> Ah... Do you have a proposal for what you consider valid, and reasons for >> abandoning the traditional statistics. >> >> Sue >> >> -----Original Message----- >> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >> Sent: Wednesday, July 23, 2014 7:03 AM >> To: Susan Hares >> Cc: Andrew G. Malis; Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: Re: [RTG-DIR] what is so bad >> >> Hi Sue, >> >> I think my point was rather that I'm not sure metrics are what we should >> be >> concentrating on in this debate. Numbers can be made to say just about >> anything, after all ;) >> >> Giles >> >> On 23 Jul 2014, at 11:55, Susan Hares wrote: >> >>> Giles: >>> >>> The performance that IETF has utilized for its ADs, IETF chairs, and WG >> >> groups for 20 years has been: >>> >>> >>> Quantitative: >>> 1) RFC published >>> 2) WG groups formed and completed >>> 3) Administrative effectiveness (AFI/SAFIs, early code adoption, >> >> ports assigned. ) >>> >>> 4) Number of authors and demographics on authors >>> 5) Statistics on the timing of RFCs and the timing of WG forming >>> 6) Statistics on attendance in WG/ IETF >>> >>> Please note, I do know of a statistically valid analysis of the >> >> correlation between #6 an #1. If you do, I would be interested. >>> >>> >>> Qualitatively >>> 1) Technologies described in RFCs get deployed. >>> 2) IETF is collaborative (at IESG, at WG), >>> 3) People want to come (from surveys) >>> >>> The "people" want to come falls into a qualitative experience that says >> >> "important to learn about the technology". >>> >>> >>> http://www.arkko.com/tools/docstats.html has document statistics. >>> >>> If you want to propose a new metric it can be useful going forward, but >> >> unless it is built on the data kept by the datatracker, we do not have the >> past trends to defend it. You could also use the mail list information, >> but we would need to use a long-running group to get a valid statistics. >>> >>> >>> Sue >>> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >>> Sent: Wednesday, July 23, 2014 6:32 AM >>> To: Andrew G. Malis >>> Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Subject: Re: [RTG-DIR] what is so bad >>> >>> I'm not sure that how helpful the exercise is? Is performance really >> >> related to how many people show up? There's no way after all to determine >> what fraction of attendees are active participants vs "IETF tourists". >> And >> of course we're supposed to do more work outside meetings than in them. >>> >>> >>> At any rate to be meaningful at all we need to weight the results by >> >> length of WG meeting as time is the constraint we're trying to optimise >> for >> here (I think!). I counted WG meeting durations in minutes (since L2VPN >> was >> 2 hours 10 mins - and I didn't have the time to type a recurring decimal). >> Couldn't find ROLL on the Vancouver Agenda though - so I used their London >> duration. Of course then the RFCs per minute were all rather low. In >> honour of the recent World Cup I went for RFCs per football match >> (counting >> only the players and the playing minutes - no allowance for referees, >> half-time, injury time or extra time). >>> >>> >>> the results show PWE3 a mile ahead of the rest, followed by BFD, then >> >> MPLS, then a cluster of WGs with very similar productivity (L2VPN leading >> those by a nose, but who am I to brag?) with L3VPN and then PCE (possibly >> the victim of the recent SDN hype) bringing up the rear. >>> >>> >>> like I say, does this really mean anything? Can I have the last half >> >> hour of my life (or rather 1/66 of a football match) back? >>> >>> >>> Giles >>> >>> >>> >>> >>> On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: >>> >>>> Loa, >>>> >>>> I added one more column, to total all of the RFCs over the period. mpls >> >> came in first in terms of total RFCs per capita, and pwe3 came in second. >> I >> also agree with your conclusions. >>>> >>>> >>>> Cheers, >>>> Andy >>>> >>>> >>>> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: >>>> Folks, >>>> >>>> I took a look at the performance on rtg wg's. >>>> >>>> The spread sheet list the number of RFC's per working group between >>>> two meeting. I've used the number of people who signed the blue >>>> sheets in Vancouver as some type of average except for roll that did >>>> not meet in Vancouver, where I used the London figure instead. >>>> >>>> Calculated the number of RFCs per person in the room. >>>> >>>> The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. >>>> The highest absolute number of RFC is MPLS (this meeting). >>>> The best trend has MPLS. >>>> >>>> Since I don't care too much about how much noise the >>>> non-participating participants is exposed too, I don't think the a >>>> re-org is motivated by the figures in the spread sheet. >>>> >>>> I guess I would go as far as too say that no arguments presented so >>>> far motivates a re-org of the RTG area. >>>> >>>> Though I'm totally supportive of some well considered >>>> re-organization of working groups, but >>>> >>>> - do it carefully >>>> - at a time when it is optimal for the working groups >>>> - involve the chairs to drive the re-org >>>> - don't break things that work >>>> >>>> /Loa >>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> >>>> >>> >>> >> >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > From nobody Wed Jul 23 07:58:27 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A561B2A68; Wed, 23 Jul 2014 07:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNADBhHzbEh; Wed, 23 Jul 2014 07:58:13 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2A51B2A70; Wed, 23 Jul 2014 07:58:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.162.238; From: "Susan Hares" To: "'Loa Andersson'" , "'Giles Heron \(giheron\)'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <005c01cfa67c$87b42780$971c7680$@ndzh.com> <53CFBF9D.9030300@pi.nu> In-Reply-To: <53CFBF9D.9030300@pi.nu> Date: Wed, 23 Jul 2014 10:58:09 -0400 Message-ID: <00ca01cfa686$84c8e2e0$8e5aa8a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKoEM/Y/Vubz9dfpwP/nDHHq79/PAH8SQ9wApok1FgByE30QAMeS+r2AWPA0fICCrwfdwIpoaPdAdDjzH4CWHgAogOT/yjGAX7111yZOllwcA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/xH0k7H26X0WIS5OiEcjBGB4obUM Cc: rtg-dir@ietf.org, "'Andrew G. Malis'" , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:58:15 -0000 Loa and Giles: I've check the statistics on http://www.arkko.com/tools/idauthors.txt . These statistics do not have a link to working group or a time stamp for drafts and RFC even though there are links in the online database. Perhaps Jari or the tools team can help me get better data. I will check with the secretariat to see if they can give their numbers for WG attendance. Your theses are: 1. "an increase in the numbers of WG attendees does not have a correlation to RFC production by a working group". 2. the RFC production has remained constant in the last 3 years within the standard deviation. If these are your two proposals, I can test these fairly quickly - once I validate the data. Jamal noted that the inclusion of many authors on a draft is "hacking the data". With author information, we can observe if the statistics of 4-5 authors differ from 1-3 authors. Please let me know if I have understood your concerns. Sue -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, July 23, 2014 9:59 AM To: Susan Hares; 'Giles Heron (giheron)' Cc: 'Andrew G. Malis'; rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad Sue, I don't think that Giles says that we should abandon traditional statistics, merely that the "numbers" the way I used can be made to show what you want them to show. And sure I agree to that. I further think that there are no way to actually show what has been alleged about giant groups and long periods of uninteresting presentations. It is simply not true. Though it is possible to to make it seem true by repeating it often enough. I would be in favor of having some useful traditional statistics available per working group if it can be achieved with a reasonable amount of work. /Loa On 2014-07-23 15:46, Susan Hares wrote: > Giles: > > Ah... Do you have a proposal for what you consider valid, and reasons > for abandoning the traditional statistics. > > Sue > > -----Original Message----- > From: Giles Heron (giheron) [mailto:giheron@cisco.com] > Sent: Wednesday, July 23, 2014 7:03 AM > To: Susan Hares > Cc: Andrew G. Malis; Loa Andersson; rtg-dir@ietf.org; > rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] what is so bad > > Hi Sue, > > I think my point was rather that I'm not sure metrics are what we > should be concentrating on in this debate. Numbers can be made to say > just about anything, after all ;) > > Giles > > On 23 Jul 2014, at 11:55, Susan Hares wrote: > >> Giles: >> >> The performance that IETF has utilized for its ADs, IETF chairs, and >> WG > groups for 20 years has been: >> >> Quantitative: >> 1) RFC published >> 2) WG groups formed and completed >> 3) Administrative effectiveness (AFI/SAFIs, early code adoption, > ports assigned. ) >> 4) Number of authors and demographics on authors >> 5) Statistics on the timing of RFCs and the timing of WG forming >> 6) Statistics on attendance in WG/ IETF >> >> Please note, I do know of a statistically valid analysis of the > correlation between #6 an #1. If you do, I would be interested. >> >> Qualitatively >> 1) Technologies described in RFCs get deployed. >> 2) IETF is collaborative (at IESG, at WG), >> 3) People want to come (from surveys) >> >> The "people" want to come falls into a qualitative experience that >> says > "important to learn about the technology". >> >> http://www.arkko.com/tools/docstats.html has document statistics. >> >> If you want to propose a new metric it can be useful going forward, >> but > unless it is built on the data kept by the datatracker, we do not have the > past trends to defend it. You could also use the mail list information, > but we would need to use a long-running group to get a valid statistics. >> >> Sue >> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >> Sent: Wednesday, July 23, 2014 6:32 AM >> To: Andrew G. Malis >> Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: Re: [RTG-DIR] what is so bad >> >> I'm not sure that how helpful the exercise is? Is performance really > related to how many people show up? There's no way after all to > determine what fraction of attendees are active participants vs "IETF > tourists". And of course we're supposed to do more work outside meetings than in them. >> >> At any rate to be meaningful at all we need to weight the results by > length of WG meeting as time is the constraint we're trying to > optimise for here (I think!). I counted WG meeting durations in > minutes (since L2VPN was > 2 hours 10 mins - and I didn't have the time to type a recurring decimal). > Couldn't find ROLL on the Vancouver Agenda though - so I used their > London duration. Of course then the RFCs per minute were all rather > low. In honour of the recent World Cup I went for RFCs per football > match (counting only the players and the playing minutes - no > allowance for referees, half-time, injury time or extra time). >> >> the results show PWE3 a mile ahead of the rest, followed by BFD, then > MPLS, then a cluster of WGs with very similar productivity (L2VPN > leading those by a nose, but who am I to brag?) with L3VPN and then > PCE (possibly the victim of the recent SDN hype) bringing up the rear. >> >> like I say, does this really mean anything? Can I have the last half > hour of my life (or rather 1/66 of a football match) back? >> >> Giles >> >> >> >> >> On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: >> >>> Loa, >>> >>> I added one more column, to total all of the RFCs over the period. >>> mpls > came in first in terms of total RFCs per capita, and pwe3 came in > second. I also agree with your conclusions. >>> >>> Cheers, >>> Andy >>> >>> >>> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: >>> Folks, >>> >>> I took a look at the performance on rtg wg's. >>> >>> The spread sheet list the number of RFC's per working group between >>> two meeting. I've used the number of people who signed the blue >>> sheets in Vancouver as some type of average except for roll that did >>> not meet in Vancouver, where I used the London figure instead. >>> >>> Calculated the number of RFCs per person in the room. >>> >>> The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. >>> The highest absolute number of RFC is MPLS (this meeting). >>> The best trend has MPLS. >>> >>> Since I don't care too much about how much noise the >>> non-participating participants is exposed too, I don't think the a >>> re-org is motivated by the figures in the spread sheet. >>> >>> I guess I would go as far as too say that no arguments presented so >>> far motivates a re-org of the RTG area. >>> >>> Though I'm totally supportive of some well considered >>> re-organization of working groups, but >>> >>> - do it carefully >>> - at a time when it is optimal for the working groups >>> - involve the chairs to drive the re-org >>> - don't break things that work >>> >>> /Loa >>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >>> >> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 08:56:04 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E311A1B27EA; Wed, 23 Jul 2014 08:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnQtfSwGnqJn; Wed, 23 Jul 2014 08:55:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315AD1A01D2; Wed, 23 Jul 2014 08:55:54 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 15:55:51 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 15:55:51 +0000 From: Ross Callon To: Alexander Vainshtein Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf8zdGB5ofF5ZUqteNALTi1dKpus9xCAgAB/vYCAAAaFgIAAAgqAgAAF6oCAABhbgIAACwoAgAAH7oCAAB448A== Date: Wed, 23 Jul 2014 15:55:51 +0000 Message-ID: <6a7d4948bf7c4a70898db7884d74e86d@CO2PR05MB636.namprd05.prod.outlook.com> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com>, <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> <53CFB910.3030607@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(36944003)(24454002)(13464003)(377424004)(252514010)(43544003)(377454003)(54094003)(51704005)(199002)(189002)(21056001)(81542001)(33646002)(85306003)(64706001)(54356999)(76176999)(77982001)(20776003)(101416001)(86362001)(81342001)(80022001)(76482001)(74316001)(46102001)(66066001)(4396001)(87936001)(2656002)(74662001)(95666004)(74502001)(19580405001)(93886003)(76576001)(50986999)(107046002)(110136001)(83322001)(31966008)(106356001)(15975445006)(79102001)(85852003)(105586002)(19580395003)(99286002)(92566001)(99396002)(83072002)(106116001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/r5qLlC-y2h20AqO6fRxENx4WCqg Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 15:56:01 -0000 > I wonder if we could collect some statistics related to quality of our do= cuments. E.g., > number of validated technical errata?=20 One small nit: If a protocol specification is widely implemented, then it m= ay be more likely to develop technical errata when compared to a specificat= ion which is not implemented at all (if only because a lot of people are lo= oking at it very closely). Being widely implemented however might be a sign= of quality, rather than lack of quality.=20 Which of course points to the observation that it can be difficult to inter= pret statistics.=20 Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alexander Vain= shtein Sent: Wednesday, July 23, 2014 9:59 AM To: Loa Andersson Cc: rtg-dir@ietf.org; Giles Heron (giheron); Andrew G. Malis; rtg-chairs@ie= tf.org; John Scudder; Susan Hares Subject: Re: [RTG-DIR] what is so bad Loa, Lots of thanks for a prompt and encouraging in a way) response. I have already said in my email that "I cannot point to any specific organi= zational or process change that would reduce the number of these cases". This seems to me pretty close what you have said in your email: these prob= lems should be handled by introducing some new elements in the process (int= ra-WG, inter-WG or both) rather than by re-shuffling the WGs. I wonder if we could collect some statistics related to quality of our docu= ments. E.g., number of validated technical errata? number of iterations of= the draft after the WG has requested its publication and until it has been= approved for publication? This seems to me more relevant than the number o= f people attending the WG F2F sessions (possibly because I have not been at= tending them for quite some time;-). My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, July 23, 2014 4:31 PM > To: Alexander Vainshtein; John Scudder; Giles Heron (giheron) > Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan Hares > Subject: Re: [RTG-DIR] what is so bad >=20 > Sasha, >=20 > I agree that what you list are example of "bad things"! >=20 > However, I don't see how it is related to a re-org of the area (which I a= lso > think is a bad idea) or of wg groups (which at times might be a very good > idea). >=20 > This I think is more related to another (good) initiative taken by the AD= 's - the > working chair training; it also could be related to initiatives taken by = some wg > chairs, the wg review teams! >=20 > It might be of interest that what is now RFC 6790 (which is the RFC I thi= nk you > mean) was accepted as a wg doc before the MPLS-RT were looking at all > MPLS drafts. >=20 > /Loa >=20 >=20 >=20 > On 2014-07-23 14:51, Alexander Vainshtein wrote: > > Hi all, > > One example of "what is bad" is the cases when drafts reach advanced > stage (or even are published as RFCs) with serious technical problems/gap= s. > > > > E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private = LAN > Service (VPLS) Management Information Base" reporting what I see as a > serious technical gap in an RFC that has been published earlier this mont= h. > > > > Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mp= ls- > deprecate-bgp-entropy-label: in this case the authors have discovered a > serious bug in an already published RFC 6970 that requires deprecation of > one of its elements. > > > > While these case may be relatively rare, the definitely fall under the > general category of "what is bad" IMO. > > > > I cannot point to any specific organizational or process change that wo= uld > reduce the number of these cases. But at least it makes sense to me to > consider them as valid use cases for estimating such changes. > > > > My 2c, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > >> -----Original Message----- > >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of John > >> Scudder > >> Sent: Wednesday, July 23, 2014 2:24 PM > >> To: Giles Heron (giheron) > >> Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan > >> Hares; Loa Andersson > >> Subject: Re: [RTG-DIR] what is so bad > >> > >> On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)" > >> > >> wrote: > >>> I think my point was rather that I'm not sure metrics are what we > >>> should be > >> concentrating on in this debate. Numbers can be made to say just > >> about anything, after all ;) > >> > >> That was more-or-less the point I had been waiting to make when we > >> ran out of time yesterday. That, plus, bad (or the wrong) metrics are > >> worse than no metrics, so take care. > >> > >> --John >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 10:25:50 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95F91A01C6; Wed, 23 Jul 2014 10:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzrChYSdk0H4; Wed, 23 Jul 2014 10:25:38 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDE41B2B6A; Wed, 23 Jul 2014 10:25:29 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 17:25:25 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 17:25:25 +0000 From: Alexander Vainshtein To: Ross Callon Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf80czvDOyGBQEukadUvLR5gxJutSuGAgAB/voD//7KzgIAAAgqAgAAF68OAAABHcIAAIx0AgAAEyiCAACOzgIAAF9kD Date: Wed, 23 Jul 2014 17:25:25 +0000 Message-ID: <1406136437595.13137@ecitele.com> References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com>, <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> <53CFB910.3030607@pi.nu> , <6a7d4948bf7c4a70898db7884d74e86d@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <6a7d4948bf7c4a70898db7884d74e86d@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.202] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(51704005)(377424004)(199002)(252514010)(24454002)(36944003)(377454003)(13464003)(43544003)(54094003)(80022001)(99396002)(81342001)(20776003)(31966008)(4396001)(86362001)(50986999)(74662001)(81542001)(66066001)(101416001)(83322001)(76482001)(77982001)(64706001)(15975445006)(19580395003)(93886003)(36756003)(106356001)(74502001)(19580405001)(1941001)(46102001)(79102001)(95666004)(21056001)(76176999)(54356999)(92726001)(92566001)(85852003)(83072002)(107046002)(85306003)(106116001)(110136001)(105586002)(87936001)(2656002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ysnk42q0gvJFD-0_XjInOZTKuUE Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 17:25:43 -0000 Ross,=0A= Lots of thanks for an important (at least, to me) coment.=0A= =0A= Of course a protocol that is widely deployed is (a) most probably reasonabl= y good and (b) may have multiple errata reported because many people have b= een implementing and/or using it.=0A= =0A= Collecting reliable statistics about actual implementation and, especially,= deployment, is not simple. At the same time I still wonder why the Routing= Area has removed its once requirement to have at least one implementation = for the drafts that are intended for the PS status. =0A= =0A= My 2c,=0A= Sasha =0A= ________________________________________=0A= From: Ross Callon =0A= Sent: Wednesday, July 23, 2014 6:55 PM=0A= To: Alexander Vainshtein=0A= Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org=0A= Subject: RE: [RTG-DIR] what is so bad=0A= =0A= > I wonder if we could collect some statistics related to quality of our do= cuments. E.g.,=0A= > number of validated technical errata?=0A= =0A= One small nit: If a protocol specification is widely implemented, then it m= ay be more likely to develop technical errata when compared to a specificat= ion which is not implemented at all (if only because a lot of people are lo= oking at it very closely). Being widely implemented however might be a sign= of quality, rather than lack of quality.=0A= =0A= Which of course points to the observation that it can be difficult to inter= pret statistics.=0A= =0A= Ross=0A= =0A= =0A= -----Original Message-----=0A= From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alexander Vain= shtein=0A= Sent: Wednesday, July 23, 2014 9:59 AM=0A= To: Loa Andersson=0A= Cc: rtg-dir@ietf.org; Giles Heron (giheron); Andrew G. Malis; rtg-chairs@ie= tf.org; John Scudder; Susan Hares=0A= Subject: Re: [RTG-DIR] what is so bad=0A= =0A= Loa,=0A= Lots of thanks for a prompt and encouraging in a way) response.=0A= =0A= I have already said in my email that "I cannot point to any specific organi= zational or process change that would reduce the number of these cases".=0A= =0A= This seems to me pretty close what you have said in your email: these prob= lems should be handled by introducing some new elements in the process (int= ra-WG, inter-WG or both) rather than by re-shuffling the WGs.=0A= =0A= I wonder if we could collect some statistics related to quality of our docu= ments. E.g., number of validated technical errata? number of iterations of= the draft after the WG has requested its publication and until it has been= approved for publication? This seems to me more relevant than the number o= f people attending the WG F2F sessions (possibly because I have not been at= tending them for quite some time;-).=0A= =0A= My 2c,=0A= Sasha=0A= Email: Alexander.Vainshtein@ecitele.com=0A= Mobile: 054-9266302=0A= =0A= =0A= > -----Original Message-----=0A= > From: Loa Andersson [mailto:loa@pi.nu]=0A= > Sent: Wednesday, July 23, 2014 4:31 PM=0A= > To: Alexander Vainshtein; John Scudder; Giles Heron (giheron)=0A= > Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan Hares= =0A= > Subject: Re: [RTG-DIR] what is so bad=0A= >=0A= > Sasha,=0A= >=0A= > I agree that what you list are example of "bad things"!=0A= >=0A= > However, I don't see how it is related to a re-org of the area (which I a= lso=0A= > think is a bad idea) or of wg groups (which at times might be a very good= =0A= > idea).=0A= >=0A= > This I think is more related to another (good) initiative taken by the AD= 's - the=0A= > working chair training; it also could be related to initiatives taken by = some wg=0A= > chairs, the wg review teams!=0A= >=0A= > It might be of interest that what is now RFC 6790 (which is the RFC I thi= nk you=0A= > mean) was accepted as a wg doc before the MPLS-RT were looking at all=0A= > MPLS drafts.=0A= >=0A= > /Loa=0A= >=0A= >=0A= >=0A= > On 2014-07-23 14:51, Alexander Vainshtein wrote:=0A= > > Hi all,=0A= > > One example of "what is bad" is the cases when drafts reach advanced=0A= > stage (or even are published as RFCs) with serious technical problems/gap= s.=0A= > >=0A= > > E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private = LAN=0A= > Service (VPLS) Management Information Base" reporting what I see as a=0A= > serious technical gap in an RFC that has been published earlier this mont= h.=0A= > >=0A= > > Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mp= ls-=0A= > deprecate-bgp-entropy-label: in this case the authors have discovered a= =0A= > serious bug in an already published RFC 6970 that requires deprecation of= =0A= > one of its elements.=0A= > >=0A= > > While these case may be relatively rare, the definitely fall under the= =0A= > general category of "what is bad" IMO.=0A= > >=0A= > > I cannot point to any specific organizational or process change that wo= uld=0A= > reduce the number of these cases. But at least it makes sense to me to=0A= > consider them as valid use cases for estimating such changes.=0A= > >=0A= > > My 2c,=0A= > > Sasha=0A= > > Email: Alexander.Vainshtein@ecitele.com=0A= > > Mobile: 054-9266302=0A= > >=0A= > >> -----Original Message-----=0A= > >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of John=0A= > >> Scudder=0A= > >> Sent: Wednesday, July 23, 2014 2:24 PM=0A= > >> To: Giles Heron (giheron)=0A= > >> Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan=0A= > >> Hares; Loa Andersson=0A= > >> Subject: Re: [RTG-DIR] what is so bad=0A= > >>=0A= > >> On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)"=0A= > >> =0A= > >> wrote:=0A= > >>> I think my point was rather that I'm not sure metrics are what we=0A= > >>> should be=0A= > >> concentrating on in this debate. Numbers can be made to say just=0A= > >> about anything, after all ;)=0A= > >>=0A= > >> That was more-or-less the point I had been waiting to make when we=0A= > >> ran out of time yesterday. That, plus, bad (or the wrong) metrics are= =0A= > >> worse than no metrics, so take care.=0A= > >>=0A= > >> --John=0A= >=0A= > --=0A= >=0A= >=0A= > Loa Andersson email: loa@mail01.huawei.com=0A= > Senior MPLS Expert loa@pi.nu=0A= > Huawei Technologies (consultant) phone: +46 739 81 21 64=0A= =0A= From nobody Wed Jul 23 12:51:00 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46E31B2CD8; Wed, 23 Jul 2014 12:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez4JkeDS7gnY; Wed, 23 Jul 2014 12:50:51 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B3D1A014F; Wed, 23 Jul 2014 12:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2029; q=dns/txt; s=iport; t=1406145051; x=1407354651; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jqmcUxoRTinHxVpweXNmLdmsckvGAyZf4/nZGFOe4Xs=; b=PqpqoVjkiCWjBRE0lYFmdPMV+JPiebY88mV7rxjOwukdNQo9S2UbgvlF nWyNsk1a5AcJx1upMMoOeEJkWv1JyD1PlEGhdvZcewq2ALQqpDO0dxsHh gwPd2AbOAyyKHphB3sk1vfpUZtOHzJOXlVCxjwU50l4GNQQ6HwmU+Cvvh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAMYR0FOtJV2Z/2dsb2JhbABZgw6BKQTPKwGBCxZ2hAQBAQQ6OAcSAQgOCh5CJQIEAQ0FiELAFxeOegEBTweERgEEmy2UQINIbIEMOQ X-IronPort-AV: E=Sophos;i="5.01,719,1400025600"; d="scan'208";a="63393434" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 23 Jul 2014 19:50:37 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6NJoaI1019310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 19:50:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 14:50:36 -0500 From: "George Swallow (swallow)" To: Jeffrey Haas , Loa Andersson Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf9I1jbNKI5UQk6+U3LNCUGw55utSuGAgAB/voCAAEFkAIAAAxmAgAAC8ACAABF0AA== Date: Wed, 23 Jul 2014 19:50:35 +0000 Message-ID: In-Reply-To: <20140723144806.GF4653@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.82.237.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <7EB5565B2215CA478968B621C6EA83CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/-ApuTKWEUAS-sYc4nRsINoaubz0 Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:50:53 -0000 Sounds like a good idea to me. Ops is about to charter a centralized OAM reporting group. We should include them as well. Along the lines of your second point we could experiment with an OAM mail list. It'd be great if we could schedule the presentations (assuming they would be short) in the rtgarea meeting. George On 7/23/14 10:48 AM, "Jeffrey Haas" wrote: >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson wrote: >> On 2014-07-23 16:26, Jeffrey Haas wrote: >> > For BFD, what we have seems to be working. >>=20 >> I think this is key - what we have for BFD is working! >>=20 >> Further, BFD is not generating any particular problems for >> other working group. >>=20 >> Conclusions: Don't touch BFD. > >That said, let's find a way to coordinate OAM across groups, including >BFD. > >In my discussions with Alia, I'm fond of the idea of "meta" WGs. >Individual >work functions that implement IETF process (drafts, chairs, etc.) should >be >partially apportioned based on not overloading any given function or >individual. This was part of my comment about such a merger likely >involving adding a third chair. But as Brooks' book tells us, adding more >people simply may make late work later - simply due to the need for >increased communication in the project. > >What we definitely could use is a meeting of the meta-group, even if only >on >a chairs basis, regularly. As long as we're talking amongst each other, >we >have IETF leadership level communication. > >The question of whether we need IETF participant communication broadened >can >be serviced by targeted presentation of related work in an appropriate >place. That could happen either in existing WG context (preserve WG work >pipelining) or do more open meeting. > >Frankly, the Monday night dinner we had with several of our key BFD >members >which also included significant conversation about relationships to >non-BFD >OAM (e.g. CFM) was what we really need. > >-- Jeff From nobody Wed Jul 23 13:03:58 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B4A1A0338; Wed, 23 Jul 2014 13:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arSG0sPKuTuu; Wed, 23 Jul 2014 13:03:56 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A59DC1A01D9; Wed, 23 Jul 2014 13:03:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.162.238; From: "Susan Hares" To: "'Ross Callon'" , "'Alexander Vainshtein'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com>, <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> <53CFB910.3030607@pi.nu> <6a7d4948bf7c4a70898db7884d74e86d@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <6a7d4948bf7c4a70898db7884d74e86d@CO2PR05MB636.namprd05.prod.outlook.com> Date: Wed, 23 Jul 2014 16:03:53 -0400 Message-ID: <002f01cfa6b1$3a6e8ee0$af4baca0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKoEM/Y/Vubz9dfpwP/nDHHq79/PAH8SQ9wApok1FgByE30QAMeS+r2AWPA0fICCrwfdwIpoaPdAdDjzH4CWHgAogEg054eAv6asAwCEZVWBQHsuAlRAzN6iz2ZCMKYEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/6voAiwaqBpinB39vDWUyW5a5Rng Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:03:57 -0000 Ross: If you get the RFC errata sub-classed into editorial (not-quality indicator), and substantive errors - you might be able to get some trends from the data. Sue -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net] Sent: Wednesday, July 23, 2014 11:56 AM To: Alexander Vainshtein Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: RE: [RTG-DIR] what is so bad > I wonder if we could collect some statistics related to quality of our > documents. E.g., number of validated technical errata? One small nit: If a protocol specification is widely implemented, then it may be more likely to develop technical errata when compared to a specification which is not implemented at all (if only because a lot of people are looking at it very closely). Being widely implemented however might be a sign of quality, rather than lack of quality. Which of course points to the observation that it can be difficult to interpret statistics. Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, July 23, 2014 9:59 AM To: Loa Andersson Cc: rtg-dir@ietf.org; Giles Heron (giheron); Andrew G. Malis; rtg-chairs@ietf.org; John Scudder; Susan Hares Subject: Re: [RTG-DIR] what is so bad Loa, Lots of thanks for a prompt and encouraging in a way) response. I have already said in my email that "I cannot point to any specific organizational or process change that would reduce the number of these cases". This seems to me pretty close what you have said in your email: these problems should be handled by introducing some new elements in the process (intra-WG, inter-WG or both) rather than by re-shuffling the WGs. I wonder if we could collect some statistics related to quality of our documents. E.g., number of validated technical errata? number of iterations of the draft after the WG has requested its publication and until it has been approved for publication? This seems to me more relevant than the number of people attending the WG F2F sessions (possibly because I have not been attending them for quite some time;-). My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, July 23, 2014 4:31 PM > To: Alexander Vainshtein; John Scudder; Giles Heron (giheron) > Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan Hares > Subject: Re: [RTG-DIR] what is so bad > > Sasha, > > I agree that what you list are example of "bad things"! > > However, I don't see how it is related to a re-org of the area (which I also > think is a bad idea) or of wg groups (which at times might be a very good > idea). > > This I think is more related to another (good) initiative taken by the AD's - the > working chair training; it also could be related to initiatives taken by some wg > chairs, the wg review teams! > > It might be of interest that what is now RFC 6790 (which is the RFC I think you > mean) was accepted as a wg doc before the MPLS-RT were looking at all > MPLS drafts. > > /Loa > > > > On 2014-07-23 14:51, Alexander Vainshtein wrote: > > Hi all, > > One example of "what is bad" is the cases when drafts reach advanced > stage (or even are published as RFCs) with serious technical problems/gaps. > > > > E.g., I have just now submitted an Errata to RFC 7257 "Virtual Private LAN > Service (VPLS) Management Information Base" reporting what I see as a > serious technical gap in an RFC that has been published earlier this month. > > > > Another example is, IMO, https://datatracker.ietf.org/doc/draft-ietf-mpls- > deprecate-bgp-entropy-label: in this case the authors have discovered a > serious bug in an already published RFC 6970 that requires deprecation of > one of its elements. > > > > While these case may be relatively rare, the definitely fall under the > general category of "what is bad" IMO. > > > > I cannot point to any specific organizational or process change that would > reduce the number of these cases. But at least it makes sense to me to > consider them as valid use cases for estimating such changes. > > > > My 2c, > > Sasha > > Email: Alexander.Vainshtein@ecitele.com > > Mobile: 054-9266302 > > > >> -----Original Message----- > >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of John > >> Scudder > >> Sent: Wednesday, July 23, 2014 2:24 PM > >> To: Giles Heron (giheron) > >> Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org; Andrew G. Malis; Susan > >> Hares; Loa Andersson > >> Subject: Re: [RTG-DIR] what is so bad > >> > >> On Jul 23, 2014, at 7:12 AM, "Giles Heron (giheron)" > >> > >> wrote: > >>> I think my point was rather that I'm not sure metrics are what we > >>> should be > >> concentrating on in this debate. Numbers can be made to say just > >> about anything, after all ;) > >> > >> That was more-or-less the point I had been waiting to make when we > >> ran out of time yesterday. That, plus, bad (or the wrong) metrics are > >> worse than no metrics, so take care. > >> > >> --John > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:05:36 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0921A0A89; Wed, 23 Jul 2014 13:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0OU14bNbtfo; Wed, 23 Jul 2014 13:05:30 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2063A1A03BB; Wed, 23 Jul 2014 13:05:30 -0700 (PDT) Received: from [31.133.165.202] (dhcp-a5ca.meeting.ietf.org [31.133.165.202]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4D01318013DA; Wed, 23 Jul 2014 22:05:28 +0200 (CEST) Message-ID: <53D01592.7080103@pi.nu> Date: Wed, 23 Jul 2014 22:05:38 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Susan Hares , "'Giles Heron (giheron)'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <005c01cfa67c$87b42780$971c7680$@ndzh.com> <53CFBF9D.9030300@pi.nu> <00ca01cfa686$84c8e2e0$8e5aa8a0$@ndzh.com> In-Reply-To: <00ca01cfa686$84c8e2e0$8e5aa8a0$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/GH35FQj3JCTTF2jRPAVCxZb5Vv4 Cc: rtg-dir@ietf.org, "'Andrew G. Malis'" , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:05:33 -0000 Sue, On 2014-07-23 16:58, Susan Hares wrote: > Loa and Giles: > > I've check the statistics on http://www.arkko.com/tools/idauthors.txt . > These statistics do not have a link to working group or a time stamp for > drafts and RFC even though there are links in the online database. Perhaps > Jari or the tools team can help me get better data. I will check with the > secretariat to see if they can give their numbers for WG attendance. > > Your theses are: > > 1. "an increase in the numbers of WG attendees does not have a correlation > to RFC production by a working group". > 2. the RFC production has remained constant in the last 3 years within the > standard deviation. > > If these are your two proposals, I can test these fairly quickly - once I > validate the data. Jamal noted that the inclusion of many authors on a > draft is "hacking the data". With author information, we can observe if the > statistics of 4-5 authors differ from 1-3 authors. I think I agree to the first as one of "my theses", as for the second one what I see is (for the MPLS wg) is that the number of RFC has been slowly been increasing since we started to introduce process improvements about 2 and a half year ago. /Loa > > Please let me know if I have understood your concerns. > > Sue > > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, July 23, 2014 9:59 AM > To: Susan Hares; 'Giles Heron (giheron)' > Cc: 'Andrew G. Malis'; rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] what is so bad > > Sue, > > I don't think that Giles says that we should abandon traditional statistics, > merely that the "numbers" the way I used can be made to show what you want > them to show. And sure I agree to that. > > I further think that there are no way to actually show what has been alleged > about giant groups and long periods of uninteresting presentations. It is > simply not true. Though it is possible to to make it seem true by repeating > it often enough. > > I would be in favor of having some useful traditional statistics available > per working group if it can be achieved with a reasonable amount of work. > > /Loa > > On 2014-07-23 15:46, Susan Hares wrote: >> Giles: >> >> Ah... Do you have a proposal for what you consider valid, and reasons >> for abandoning the traditional statistics. >> >> Sue >> >> -----Original Message----- >> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >> Sent: Wednesday, July 23, 2014 7:03 AM >> To: Susan Hares >> Cc: Andrew G. Malis; Loa Andersson; rtg-dir@ietf.org; >> rtg-chairs@ietf.org >> Subject: Re: [RTG-DIR] what is so bad >> >> Hi Sue, >> >> I think my point was rather that I'm not sure metrics are what we >> should be concentrating on in this debate. Numbers can be made to say >> just about anything, after all ;) >> >> Giles >> >> On 23 Jul 2014, at 11:55, Susan Hares wrote: >> >>> Giles: >>> >>> The performance that IETF has utilized for its ADs, IETF chairs, and >>> WG >> groups for 20 years has been: >>> >>> Quantitative: >>> 1) RFC published >>> 2) WG groups formed and completed >>> 3) Administrative effectiveness (AFI/SAFIs, early code adoption, >> ports assigned. ) >>> 4) Number of authors and demographics on authors >>> 5) Statistics on the timing of RFCs and the timing of WG forming >>> 6) Statistics on attendance in WG/ IETF >>> >>> Please note, I do know of a statistically valid analysis of the >> correlation between #6 an #1. If you do, I would be interested. >>> >>> Qualitatively >>> 1) Technologies described in RFCs get deployed. >>> 2) IETF is collaborative (at IESG, at WG), >>> 3) People want to come (from surveys) >>> >>> The "people" want to come falls into a qualitative experience that >>> says >> "important to learn about the technology". >>> >>> http://www.arkko.com/tools/docstats.html has document statistics. >>> >>> If you want to propose a new metric it can be useful going forward, >>> but >> unless it is built on the data kept by the datatracker, we do not have the >> past trends to defend it. You could also use the mail list information, >> but we would need to use a long-running group to get a valid statistics. >>> >>> Sue >>> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >>> Sent: Wednesday, July 23, 2014 6:32 AM >>> To: Andrew G. Malis >>> Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Subject: Re: [RTG-DIR] what is so bad >>> >>> I'm not sure that how helpful the exercise is? Is performance really >> related to how many people show up? There's no way after all to >> determine what fraction of attendees are active participants vs "IETF >> tourists". And of course we're supposed to do more work outside meetings > than in them. >>> >>> At any rate to be meaningful at all we need to weight the results by >> length of WG meeting as time is the constraint we're trying to >> optimise for here (I think!). I counted WG meeting durations in >> minutes (since L2VPN was >> 2 hours 10 mins - and I didn't have the time to type a recurring decimal). >> Couldn't find ROLL on the Vancouver Agenda though - so I used their >> London duration. Of course then the RFCs per minute were all rather >> low. In honour of the recent World Cup I went for RFCs per football >> match (counting only the players and the playing minutes - no >> allowance for referees, half-time, injury time or extra time). >>> >>> the results show PWE3 a mile ahead of the rest, followed by BFD, then >> MPLS, then a cluster of WGs with very similar productivity (L2VPN >> leading those by a nose, but who am I to brag?) with L3VPN and then >> PCE (possibly the victim of the recent SDN hype) bringing up the rear. >>> >>> like I say, does this really mean anything? Can I have the last half >> hour of my life (or rather 1/66 of a football match) back? >>> >>> Giles >>> >>> >>> >>> >>> On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: >>> >>>> Loa, >>>> >>>> I added one more column, to total all of the RFCs over the period. >>>> mpls >> came in first in terms of total RFCs per capita, and pwe3 came in >> second. I also agree with your conclusions. >>>> >>>> Cheers, >>>> Andy >>>> >>>> >>>> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: >>>> Folks, >>>> >>>> I took a look at the performance on rtg wg's. >>>> >>>> The spread sheet list the number of RFC's per working group between >>>> two meeting. I've used the number of people who signed the blue >>>> sheets in Vancouver as some type of average except for roll that did >>>> not meet in Vancouver, where I used the London figure instead. >>>> >>>> Calculated the number of RFCs per person in the room. >>>> >>>> The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. >>>> The highest absolute number of RFC is MPLS (this meeting). >>>> The best trend has MPLS. >>>> >>>> Since I don't care too much about how much noise the >>>> non-participating participants is exposed too, I don't think the a >>>> re-org is motivated by the figures in the spread sheet. >>>> >>>> I guess I would go as far as too say that no arguments presented so >>>> far motivates a re-org of the RTG area. >>>> >>>> Though I'm totally supportive of some well considered >>>> re-organization of working groups, but >>>> >>>> - do it carefully >>>> - at a time when it is optimal for the working groups >>>> - involve the chairs to drive the re-org >>>> - don't break things that work >>>> >>>> /Loa >>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> >>>> >>> >> >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:12:11 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377011A0309; Wed, 23 Jul 2014 13:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV6gC6Ber91X; Wed, 23 Jul 2014 13:12:07 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5CD1A00B7; Wed, 23 Jul 2014 13:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2547; q=dns/txt; s=iport; t=1406146327; x=1407355927; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DzF8QUKkAr0DNd0OszIEjYEN+Wz5Z16UOvSd3+UWQJY=; b=WmF7JC+ioql+MdoUWIOka9UfHLNS4u+n43I9CwhDTY0kOgiImVLn1NUA gEOuYNiuZa7xYis+ib1Fa35zkgRZSatAfFk467eBSinKwoYxujurWhC3A 8G0g95V2icgv0Kesd68g1NyPcKTM2wMWmuN10+3jC/YpP8yKDKRIUQ+5L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHgW0FOtJA2G/2dsb2JhbABZgw6BKQTPKwGBCxZ2hAQBAQQ6MQ4OBAEIGB4rFyUCBAENBRmIKcAYFwSFIYlDARACAU8HhEYFmy2UQINIbIFF X-IronPort-AV: E=Sophos;i="5.01,719,1400025600"; d="scan'208";a="63445132" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 23 Jul 2014 20:12:05 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6NKC5g1022378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 20:12:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 15:12:04 -0500 From: "George Swallow (swallow)" To: Loa Andersson , "Giles Heron (giheron)" , "Andrew G. Malis" Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf9I1jbNKI5UQk6+U3LNCUGw55utSuGAgAB/voCAACxKAIAAMpYA Date: Wed, 23 Jul 2014 20:12:04 +0000 Message-ID: In-Reply-To: <53CFB462.8030603@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.82.237.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <998E1F0A9D1CD545B41879CEBAB97689@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/HOv9S3O-wiRrFw_QAI6P6SgMDUw Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:12:09 -0000 A giant workgroup with a potpourri of diverse topics would obviously be bad. A giant* workgroup of closely related items that need to play together in many deployments IMHO does make sense. George *I'd call MPLS big or large. Giant sounds like a term chosen for rhetorical effect. On 7/23/14 9:10 AM, "Loa Andersson" wrote: >Giles and John, > > >On 2014-07-23 12:32, Giles Heron (giheron) wrote: > >Giles: >> like I say, does this really mean anything? Can I have the last half >> hour of my life (or rather 1/66 of a football match) back? > >John: >"bad (or the wrong) metrics are worse than no metric" > >You make my point! What I did to try to see if I by some simple >(non-scientific) method could find some proof of what has been in this >debate from the beginning. > >Restating this slightly >"Giant working groups are inefficient since a large number of people > will have to spend boring time listening to discussions/presentations > on thing they are not interested in." > >Giant where not defined and the problem with statements that are made >over and over again is that they over time become "true" even if there >are nothing to substantiate them. Over time they become as bad as bad >statistic! > >I don't think the original slide show anything that support the >allegation above. It is true that the number of people in the room, >the length of football matches, slot duration, the weather outside, >the location, etc. > >If there is a small conclusion we can draw ii is that the people that >are interested come to the wg meetings and we make good progress >regardless of how many drone or tourists we have in the meeting. > >There has also been alleged that big groups have a higher ratio of >drones, I can't find any support for that allegation. > >In summary - the metrics I have is useless when it comes to motivate or >de-motivate an area re-org. > >To repeat what in the first mail, and which I think it would be good to >converge on: > >I'm totally supportive of some well considered re-organization >of working groups, > >- don't re-org the area, re-org working groups >- do it carefully >- at a time when it is optimal for the working groups >- involve the chairs to drive the re-org >- don't break things that work > > >/Loa > > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:14:56 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856F21A03BC; Wed, 23 Jul 2014 13:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_af47BOy0io; Wed, 23 Jul 2014 13:14:53 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FAA11A0309; Wed, 23 Jul 2014 13:14:53 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id v1so1188189yhn.13 for ; Wed, 23 Jul 2014 13:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hwQzxOG7pA2JkEpZU0YIHekb0fVg/kbSyI4EqLPYSmI=; b=KMYcNqclSJbiw/wTCnehqOez4tQPWaDoEiLN7rfFKSuk/PJey/tcyyaFiE8G1i/01j 6/nh/iQP+9Ld6rsDSAkmcNcNDIx1TbbwEBUb9omMWKaIZh6sMI8TsgmMlIkOaKZ3MRll 3tDEIHd91VoVAYwvtYhlCTHUgK/9NkWIVBMHyfbJwYuxDz5O8NJYPETQIZ3IVNPBKhS+ CfcgTZ2vF0eIN13x6Mfe+Qw9/SemlqeyzRo6ZO+2pxiZGLxrq8uSCyD226Fw2I8DXxyh tk/PgJWrjvn7pEpq+AjRfLUE0z+RZbCBQP5MbOJ9rJZ63h1IoDAdIxhlysDq60SAfAtf JLUg== MIME-Version: 1.0 X-Received: by 10.236.106.10 with SMTP id l10mr4885724yhg.101.1406146492891; Wed, 23 Jul 2014 13:14:52 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Wed, 23 Jul 2014 13:14:52 -0700 (PDT) In-Reply-To: References: <20140723144806.GF4653@pfrc> Date: Wed, 23 Jul 2014 16:14:52 -0400 Message-ID: From: Alia Atlas To: "George Swallow (swallow)" Content-Type: multipart/alternative; boundary=001a11c1de88360c4d04fee1fed1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/QEaSyyCD-xzrHIP0WpZTZ2QQfvk Cc: Jeffrey Haas , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Loa Andersson Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:14:55 -0000 --001a11c1de88360c4d04fee1fed1 Content-Type: text/plain; charset=UTF-8 We do have a lot of cases other than OAM where cross-WG communication would be very useful. I am in favor of interest-based mailing lists. Another case is for routing YANG modules, especially as the inter-dependencies need to be figured out. I have created a wiki page to track ideas for such mailing lists. Please put your ideas there for tracking (and feel free to add agreement/support/disagreement). http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists Alia On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow) wrote: > Sounds like a good idea to me. Ops is about to charter a centralized OAM > reporting group. We should include them as well. > > Along the lines of your second point we could experiment with an OAM mail > list. It'd be great if we could schedule the presentations (assuming they > would be short) in the rtgarea meeting. > > George > > On 7/23/14 10:48 AM, "Jeffrey Haas" wrote: > > >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson wrote: > >> On 2014-07-23 16:26, Jeffrey Haas wrote: > >> > For BFD, what we have seems to be working. > >> > >> I think this is key - what we have for BFD is working! > >> > >> Further, BFD is not generating any particular problems for > >> other working group. > >> > >> Conclusions: Don't touch BFD. > > > >That said, let's find a way to coordinate OAM across groups, including > >BFD. > > > >In my discussions with Alia, I'm fond of the idea of "meta" WGs. > >Individual > >work functions that implement IETF process (drafts, chairs, etc.) should > >be > >partially apportioned based on not overloading any given function or > >individual. This was part of my comment about such a merger likely > >involving adding a third chair. But as Brooks' book tells us, adding more > >people simply may make late work later - simply due to the need for > >increased communication in the project. > > > >What we definitely could use is a meeting of the meta-group, even if only > >on > >a chairs basis, regularly. As long as we're talking amongst each other, > >we > >have IETF leadership level communication. > > > >The question of whether we need IETF participant communication broadened > >can > >be serviced by targeted presentation of related work in an appropriate > >place. That could happen either in existing WG context (preserve WG work > >pipelining) or do more open meeting. > > > >Frankly, the Monday night dinner we had with several of our key BFD > >members > >which also included significant conversation about relationships to > >non-BFD > >OAM (e.g. CFM) was what we really need. > > > >-- Jeff > > --001a11c1de88360c4d04fee1fed1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We do have a lot of cases other than OAM where cross-WG co= mmunication would be very
useful. =C2=A0I am in favor of interest-based= mailing lists. =C2=A0Another case is for routing YANG modules,
e= specially as the inter-dependencies need to be figured out.

I have created a wiki page to track ideas for such mail= ing lists. =C2=A0Please put your ideas there for
tracking (and fe= el free to add agreement/support/disagreement).

http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists

Alia



On Wed, Jul 23, 2014 at 3:50 PM= , George Swallow (swallow) <swallow@cisco.com> wrote:
Sounds like a good idea to me. =C2=A0Ops is = about to charter a centralized OAM
reporting group. We should include them as well.

Along the lines of your second point we could experiment with an OAM mail list. It'd be great if we could schedule the presentations (assuming th= ey
would be short) in the rtgarea meeting.

George

On 7/23/14 10:48 AM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

>On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson wrote:
>> On 2014-07-23 16:26, Jeffrey Haas wrote:
>> > =C2=A0For BFD, what we have seems to be working.
>>
>> I think this is key - what we have for BFD is working!
>>
>> Further, BFD is not generating any particular problems for
>> other working group.
>>
>> Conclusions: Don't touch BFD.
>
>That said, let's find a way to coordinate OAM across groups, includ= ing
>BFD.
>
>In my discussions with Alia, I'm fond of the idea of "meta&quo= t; WGs.
>Individual
>work functions that implement IETF process (drafts, chairs, etc.) shoul= d
>be
>partially apportioned based on not overloading any given function or >individual. =C2=A0This was part of my comment about such a merger likel= y
>involving adding a third chair. =C2=A0But as Brooks' book tells us,= adding more
>people simply may make late work later - simply due to the need for
>increased communication in the project.
>
>What we definitely could use is a meeting of the meta-group, even if on= ly
>on
>a chairs basis, regularly. =C2=A0As long as we're talking amongst e= ach other,
>we
>have IETF leadership level communication.
>
>The question of whether we need IETF participant communication broadene= d
>can
>be serviced by targeted presentation of related work in an appropriate<= br> >place. =C2=A0That could happen either in existing WG context (preserve = WG work
>pipelining) or do more open meeting.
>
>Frankly, the Monday night dinner we had with several of our key BFD
>members
>which also included significant conversation about relationships to
>non-BFD
>OAM (e.g. CFM) was what we really need.
>
>-- Jeff


--001a11c1de88360c4d04fee1fed1-- From nobody Wed Jul 23 13:18:05 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05D1B27D2; Wed, 23 Jul 2014 13:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81ysNyhs_reh; Wed, 23 Jul 2014 13:18:00 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863061A0AF6; Wed, 23 Jul 2014 13:18:00 -0700 (PDT) Received: from [31.133.165.202] (dhcp-a5ca.meeting.ietf.org [31.133.165.202]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B40D118013DA; Wed, 23 Jul 2014 22:17:58 +0200 (CEST) Message-ID: <53D01880.4070903@pi.nu> Date: Wed, 23 Jul 2014 22:18:08 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas , "George Swallow (swallow)" References: <20140723144806.GF4653@pfrc> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/pOZigGmQkg83z1giToayT5QsCWM Cc: Jeffrey Haas , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:18:02 -0000 Alia, I hope you understand that this type of inter wg communication, to a certain extent makes the area re-org you have been proposing unnecessary, while we still have to look at how optimize the working groups. /Loa On 2014-07-23 22:14, Alia Atlas wrote: > We do have a lot of cases other than OAM where cross-WG communication > would be very > useful. I am in favor of interest-based mailing lists. Another case is > for routing YANG modules, > especially as the inter-dependencies need to be figured out. > > I have created a wiki page to track ideas for such mailing lists. > Please put your ideas there for > tracking (and feel free to add agreement/support/disagreement). > > http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists > > Alia > > > > On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow) > > wrote: > > Sounds like a good idea to me. Ops is about to charter a > centralized OAM > reporting group. We should include them as well. > > Along the lines of your second point we could experiment with an OAM > mail > list. It'd be great if we could schedule the presentations (assuming > they > would be short) in the rtgarea meeting. > > George > > On 7/23/14 10:48 AM, "Jeffrey Haas" > wrote: > > >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson wrote: > >> On 2014-07-23 16:26, Jeffrey Haas wrote: > >> > For BFD, what we have seems to be working. > >> > >> I think this is key - what we have for BFD is working! > >> > >> Further, BFD is not generating any particular problems for > >> other working group. > >> > >> Conclusions: Don't touch BFD. > > > >That said, let's find a way to coordinate OAM across groups, including > >BFD. > > > >In my discussions with Alia, I'm fond of the idea of "meta" WGs. > >Individual > >work functions that implement IETF process (drafts, chairs, etc.) > should > >be > >partially apportioned based on not overloading any given function or > >individual. This was part of my comment about such a merger likely > >involving adding a third chair. But as Brooks' book tells us, > adding more > >people simply may make late work later - simply due to the need for > >increased communication in the project. > > > >What we definitely could use is a meeting of the meta-group, even > if only > >on > >a chairs basis, regularly. As long as we're talking amongst each > other, > >we > >have IETF leadership level communication. > > > >The question of whether we need IETF participant communication > broadened > >can > >be serviced by targeted presentation of related work in an appropriate > >place. That could happen either in existing WG context (preserve > WG work > >pipelining) or do more open meeting. > > > >Frankly, the Monday night dinner we had with several of our key BFD > >members > >which also included significant conversation about relationships to > >non-BFD > >OAM (e.g. CFM) was what we really need. > > > >-- Jeff > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:21:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B361B2880; Wed, 23 Jul 2014 13:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCVDXs2nchH2; Wed, 23 Jul 2014 13:21:42 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C94A1B2882; Wed, 23 Jul 2014 13:21:41 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id a41so1216557yho.29 for ; Wed, 23 Jul 2014 13:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gaEqHHg1woTa2y3PbWQfaD754+hGof52I2bN8ImwL64=; b=rFipCJCq7uiF8of+ckNnXQnLt6YwUGx/awe+X4v5EvAlRsLZiOprWjOhw8drdwzOeY QRKiI+vEawAV3oauCcyn8PygcMOuvUS5W4SAOZrpr1/pXaaVuCAnh0A3ZUYoA3bLV7pS FCMyjM7dI60H9K7q//Vh6GSEMJv/mMqll/muJHvXb2fDhg9BL2LA3A9+zysP/Q3Arzcx vNhE67ZbXPHqxT4dI2IXmzggOt+snIU09S7UYA6DktL33pRyNdw/TVrsp79HLK95Qj5z LijFhUjrYWtTXjzoMnusNiJSSAUgpwA7OncAf3JuXqmLNL3J7V3AWnALNs/GySPp9Cm9 wIcw== MIME-Version: 1.0 X-Received: by 10.236.138.167 with SMTP id a27mr4872781yhj.141.1406146900913; Wed, 23 Jul 2014 13:21:40 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Wed, 23 Jul 2014 13:21:40 -0700 (PDT) In-Reply-To: <53D01880.4070903@pi.nu> References: <20140723144806.GF4653@pfrc> <53D01880.4070903@pi.nu> Date: Wed, 23 Jul 2014 16:21:40 -0400 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf303ddb8287f50704fee2160f Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/_4j8sqSgtPIOSEXnuJgY5PPBCX4 Cc: "George Swallow \(swallow\)" , Jeffrey Haas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:21:45 -0000 --20cf303ddb8287f50704fee2160f Content-Type: text/plain; charset=UTF-8 Loa, It is a way of addressing topics that are split and does nothing to address WG size and focus. Of course we also need cross-WG communication. Alia On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson wrote: > Alia, > > I hope you understand that this type of inter wg communication, to > a certain extent makes the area re-org you have been proposing > unnecessary, while we still have to look at how optimize the working > groups. > > /Loa > > > On 2014-07-23 22:14, Alia Atlas wrote: > >> We do have a lot of cases other than OAM where cross-WG communication >> would be very >> useful. I am in favor of interest-based mailing lists. Another case is >> for routing YANG modules, >> especially as the inter-dependencies need to be figured out. >> >> I have created a wiki page to track ideas for such mailing lists. >> Please put your ideas there for >> tracking (and feel free to add agreement/support/disagreement). >> >> http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists >> >> Alia >> >> >> >> On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow) >> > wrote: >> >> Sounds like a good idea to me. Ops is about to charter a >> centralized OAM >> reporting group. We should include them as well. >> >> Along the lines of your second point we could experiment with an OAM >> mail >> list. It'd be great if we could schedule the presentations (assuming >> they >> would be short) in the rtgarea meeting. >> >> George >> >> On 7/23/14 10:48 AM, "Jeffrey Haas" > > wrote: >> >> >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson wrote: >> >> On 2014-07-23 16:26, Jeffrey Haas wrote: >> >> > For BFD, what we have seems to be working. >> >> >> >> I think this is key - what we have for BFD is working! >> >> >> >> Further, BFD is not generating any particular problems for >> >> other working group. >> >> >> >> Conclusions: Don't touch BFD. >> > >> >That said, let's find a way to coordinate OAM across groups, >> including >> >BFD. >> > >> >In my discussions with Alia, I'm fond of the idea of "meta" WGs. >> >Individual >> >work functions that implement IETF process (drafts, chairs, etc.) >> should >> >be >> >partially apportioned based on not overloading any given function or >> >individual. This was part of my comment about such a merger likely >> >involving adding a third chair. But as Brooks' book tells us, >> adding more >> >people simply may make late work later - simply due to the need for >> >increased communication in the project. >> > >> >What we definitely could use is a meeting of the meta-group, even >> if only >> >on >> >a chairs basis, regularly. As long as we're talking amongst each >> other, >> >we >> >have IETF leadership level communication. >> > >> >The question of whether we need IETF participant communication >> broadened >> >can >> >be serviced by targeted presentation of related work in an >> appropriate >> >place. That could happen either in existing WG context (preserve >> WG work >> >pipelining) or do more open meeting. >> > >> >Frankly, the Monday night dinner we had with several of our key BFD >> >members >> >which also included significant conversation about relationships to >> >non-BFD >> >OAM (e.g. CFM) was what we really need. >> > >> >-- Jeff >> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --20cf303ddb8287f50704fee2160f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,=

It is= a way of addressing topics that are split and does nothing to address WG s= ize
and focus. =C2=A0 Of course we also need cross-W= G communication.

Alia

On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson = <loa@pi.nu>= wrote:
Alia,

I hope you understand that this type of inter wg communication, to
a certain extent makes the area re-org you have been proposing
unnecessary, while we still have to look at how optimize the working
groups.

/Loa


On 2014-07-23 22:14, Alia Atlas wrote:
We do have a lot of cases other than OAM where cross-WG communication
would be very
useful. =C2=A0I am in favor of interest-based mailing lists. =C2=A0Another = case is
for routing YANG modules,
especially as the inter-dependencies need to be figured out.

I have created a wiki page to track ideas for such mailing lists.
=C2=A0 Please put your ideas there for
tracking (and feel free to add agreement/support/disagreement).

http://wiki.tools.ietf.org/area/rtg/trac/wik= i/RtgCrossWGMailingLists

Alia



On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow)
<swallow@cisco.co= m <mailto:swa= llow@cisco.com>> wrote:

=C2=A0 =C2=A0 Sounds like a good idea to me. =C2=A0Ops is about to charter = a
=C2=A0 =C2=A0 centralized OAM
=C2=A0 =C2=A0 reporting group. We should include them as well.

=C2=A0 =C2=A0 Along the lines of your second point we could experiment with= an OAM
=C2=A0 =C2=A0 mail
=C2=A0 =C2=A0 list. It'd be great if we could schedule the presentation= s (assuming
=C2=A0 =C2=A0 they
=C2=A0 =C2=A0 would be short) in the rtgarea meeting.

=C2=A0 =C2=A0 George

=C2=A0 =C2=A0 On 7/23/14 10:48 AM, "Jeffrey Haas" <jhaas@pfrc.org
<= div class=3D"h5"> =C2=A0 =C2=A0 <mailto:jhaas@pfrc.org>> wrote:

=C2=A0 =C2=A0 =C2=A0>On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Ander= sson wrote:
=C2=A0 =C2=A0 =C2=A0>> On 2014-07-23 16:26, Jeffrey Haas wrote:
=C2=A0 =C2=A0 =C2=A0>> > =C2=A0For BFD, what we have seems to be w= orking.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>> I think this is key - what we have for BFD is = working!
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>> Further, BFD is not generating any particular = problems for
=C2=A0 =C2=A0 =C2=A0>> other working group.
=C2=A0 =C2=A0 =C2=A0>>
=C2=A0 =C2=A0 =C2=A0>> Conclusions: Don't touch BFD.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>That said, let's find a way to coordinate OAM a= cross groups, including
=C2=A0 =C2=A0 =C2=A0>BFD.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>In my discussions with Alia, I'm fond of the id= ea of "meta" WGs.
=C2=A0 =C2=A0 =C2=A0>Individual
=C2=A0 =C2=A0 =C2=A0>work functions that implement IETF process (drafts,= chairs, etc.)
=C2=A0 =C2=A0 should
=C2=A0 =C2=A0 =C2=A0>be
=C2=A0 =C2=A0 =C2=A0>partially apportioned based on not overloading any = given function or
=C2=A0 =C2=A0 =C2=A0>individual. =C2=A0This was part of my comment about= such a merger likely
=C2=A0 =C2=A0 =C2=A0>involving adding a third chair. =C2=A0But as Brooks= ' book tells us,
=C2=A0 =C2=A0 adding more
=C2=A0 =C2=A0 =C2=A0>people simply may make late work later - simply due= to the need for
=C2=A0 =C2=A0 =C2=A0>increased communication in the project.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>What we definitely could use is a meeting of the me= ta-group, even
=C2=A0 =C2=A0 if only
=C2=A0 =C2=A0 =C2=A0>on
=C2=A0 =C2=A0 =C2=A0>a chairs basis, regularly. =C2=A0As long as we'= re talking amongst each
=C2=A0 =C2=A0 other,
=C2=A0 =C2=A0 =C2=A0>we
=C2=A0 =C2=A0 =C2=A0>have IETF leadership level communication.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>The question of whether we need IETF participant co= mmunication
=C2=A0 =C2=A0 broadened
=C2=A0 =C2=A0 =C2=A0>can
=C2=A0 =C2=A0 =C2=A0>be serviced by targeted presentation of related wor= k in an appropriate
=C2=A0 =C2=A0 =C2=A0>place. =C2=A0That could happen either in existing W= G context (preserve
=C2=A0 =C2=A0 WG work
=C2=A0 =C2=A0 =C2=A0>pipelining) or do more open meeting.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>Frankly, the Monday night dinner we had with severa= l of our key BFD
=C2=A0 =C2=A0 =C2=A0>members
=C2=A0 =C2=A0 =C2=A0>which also included significant conversation about = relationships to
=C2=A0 =C2=A0 =C2=A0>non-BFD
=C2=A0 =C2=A0 =C2=A0>OAM (e.g. CFM) was what we really need.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>-- Jeff



--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64

--20cf303ddb8287f50704fee2160f-- From nobody Wed Jul 23 13:22:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CED71B27FD; Wed, 23 Jul 2014 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h436n8eEEzdu; Wed, 23 Jul 2014 13:21:46 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 22BA81B2880; Wed, 23 Jul 2014 13:21:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.162.238; From: "Susan Hares" To: "'Loa Andersson'" , "'Giles Heron \(giheron\)'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <005c01cfa67c$87b42780$971c7680$@ndzh.com> <53CFBF9D.9030300@pi.nu> <00ca01cfa686$84c8e2e0$8e5aa8a0$@ndzh.com> <53D01592.7080103@pi.nu> In-Reply-To: <53D01592.7080103@pi.nu> Date: Wed, 23 Jul 2014 16:21:44 -0400 Message-ID: <003e01cfa6b3$b9392300$2bab6900$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKoEM/Y/Vubz9dfpwP/nDHHq79/PAH8SQ9wApok1FgByE30QAMeS+r2AWPA0fICCrwfdwIpoaPdAdDjzH4CWHgAogOT/yjGAX7111wBm7xoFQI+BD2FmRvpS4A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/eB_xTYqnl4HTG2kVd7BhYBcXmbw Cc: rtg-dir@ietf.org, "'Andrew G. Malis'" , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:21:48 -0000 Loa: Thank you for the correction to the second thesis. I will use this as the second thesis in any testing. Sue PS - I'm still in the process of trying to get a data file with the WG identified and date. -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, July 23, 2014 4:06 PM To: Susan Hares; 'Giles Heron (giheron)' Cc: rtg-dir@ietf.org; 'Andrew G. Malis'; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad Sue, On 2014-07-23 16:58, Susan Hares wrote: > Loa and Giles: > > I've check the statistics on http://www.arkko.com/tools/idauthors.txt . > These statistics do not have a link to working group or a time stamp > for drafts and RFC even though there are links in the online database. > Perhaps Jari or the tools team can help me get better data. I will > check with the secretariat to see if they can give their numbers for WG attendance. > > Your theses are: > > 1. "an increase in the numbers of WG attendees does not have a > correlation to RFC production by a working group". > 2. the RFC production has remained constant in the last 3 years > within the standard deviation. > > If these are your two proposals, I can test these fairly quickly - once I > validate the data. Jamal noted that the inclusion of many authors on a > draft is "hacking the data". With author information, we can observe > if the statistics of 4-5 authors differ from 1-3 authors. I think I agree to the first as one of "my theses", as for the second one what I see is (for the MPLS wg) is that the number of RFC has been slowly been increasing since we started to introduce process improvements about 2 and a half year ago. /Loa > > Please let me know if I have understood your concerns. > > Sue > > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, July 23, 2014 9:59 AM > To: Susan Hares; 'Giles Heron (giheron)' > Cc: 'Andrew G. Malis'; rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] what is so bad > > Sue, > > I don't think that Giles says that we should abandon traditional > statistics, merely that the "numbers" the way I used can be made to > show what you want them to show. And sure I agree to that. > > I further think that there are no way to actually show what has been > alleged about giant groups and long periods of uninteresting > presentations. It is simply not true. Though it is possible to to make > it seem true by repeating it often enough. > > I would be in favor of having some useful traditional statistics > available per working group if it can be achieved with a reasonable amount of work. > > /Loa > > On 2014-07-23 15:46, Susan Hares wrote: >> Giles: >> >> Ah... Do you have a proposal for what you consider valid, and reasons >> for abandoning the traditional statistics. >> >> Sue >> >> -----Original Message----- >> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >> Sent: Wednesday, July 23, 2014 7:03 AM >> To: Susan Hares >> Cc: Andrew G. Malis; Loa Andersson; rtg-dir@ietf.org; >> rtg-chairs@ietf.org >> Subject: Re: [RTG-DIR] what is so bad >> >> Hi Sue, >> >> I think my point was rather that I'm not sure metrics are what we >> should be concentrating on in this debate. Numbers can be made to >> say just about anything, after all ;) >> >> Giles >> >> On 23 Jul 2014, at 11:55, Susan Hares wrote: >> >>> Giles: >>> >>> The performance that IETF has utilized for its ADs, IETF chairs, and >>> WG >> groups for 20 years has been: >>> >>> Quantitative: >>> 1) RFC published >>> 2) WG groups formed and completed >>> 3) Administrative effectiveness (AFI/SAFIs, early code adoption, >> ports assigned. ) >>> 4) Number of authors and demographics on authors >>> 5) Statistics on the timing of RFCs and the timing of WG forming >>> 6) Statistics on attendance in WG/ IETF >>> >>> Please note, I do know of a statistically valid analysis of the >> correlation between #6 an #1. If you do, I would be interested. >>> >>> Qualitatively >>> 1) Technologies described in RFCs get deployed. >>> 2) IETF is collaborative (at IESG, at WG), >>> 3) People want to come (from surveys) >>> >>> The "people" want to come falls into a qualitative experience that >>> says >> "important to learn about the technology". >>> >>> http://www.arkko.com/tools/docstats.html has document statistics. >>> >>> If you want to propose a new metric it can be useful going forward, >>> but >> unless it is built on the data kept by the datatracker, we do not have the >> past trends to defend it. You could also use the mail list information, >> but we would need to use a long-running group to get a valid statistics. >>> >>> Sue >>> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >>> Sent: Wednesday, July 23, 2014 6:32 AM >>> To: Andrew G. Malis >>> Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Subject: Re: [RTG-DIR] what is so bad >>> >>> I'm not sure that how helpful the exercise is? Is performance >>> really >> related to how many people show up? There's no way after all to >> determine what fraction of attendees are active participants vs "IETF >> tourists". And of course we're supposed to do more work outside >> meetings > than in them. >>> >>> At any rate to be meaningful at all we need to weight the results by >> length of WG meeting as time is the constraint we're trying to >> optimise for here (I think!). I counted WG meeting durations in >> minutes (since L2VPN was >> 2 hours 10 mins - and I didn't have the time to type a recurring decimal). >> Couldn't find ROLL on the Vancouver Agenda though - so I used their >> London duration. Of course then the RFCs per minute were all rather >> low. In honour of the recent World Cup I went for RFCs per football >> match (counting only the players and the playing minutes - no >> allowance for referees, half-time, injury time or extra time). >>> >>> the results show PWE3 a mile ahead of the rest, followed by BFD, >>> then >> MPLS, then a cluster of WGs with very similar productivity (L2VPN >> leading those by a nose, but who am I to brag?) with L3VPN and then >> PCE (possibly the victim of the recent SDN hype) bringing up the rear. >>> >>> like I say, does this really mean anything? Can I have the last half >> hour of my life (or rather 1/66 of a football match) back? >>> >>> Giles >>> >>> >>> >>> >>> On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: >>> >>>> Loa, >>>> >>>> I added one more column, to total all of the RFCs over the period. >>>> mpls >> came in first in terms of total RFCs per capita, and pwe3 came in >> second. I also agree with your conclusions. >>>> >>>> Cheers, >>>> Andy >>>> >>>> >>>> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: >>>> Folks, >>>> >>>> I took a look at the performance on rtg wg's. >>>> >>>> The spread sheet list the number of RFC's per working group between >>>> two meeting. I've used the number of people who signed the blue >>>> sheets in Vancouver as some type of average except for roll that >>>> did not meet in Vancouver, where I used the London figure instead. >>>> >>>> Calculated the number of RFCs per person in the room. >>>> >>>> The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. >>>> The highest absolute number of RFC is MPLS (this meeting). >>>> The best trend has MPLS. >>>> >>>> Since I don't care too much about how much noise the >>>> non-participating participants is exposed too, I don't think the a >>>> re-org is motivated by the figures in the spread sheet. >>>> >>>> I guess I would go as far as too say that no arguments presented so >>>> far motivates a re-org of the RTG area. >>>> >>>> Though I'm totally supportive of some well considered >>>> re-organization of working groups, but >>>> >>>> - do it carefully >>>> - at a time when it is optimal for the working groups >>>> - involve the chairs to drive the re-org >>>> - don't break things that work >>>> >>>> /Loa >>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> >>>> >>> >> >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:26:07 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B21B2822; Wed, 23 Jul 2014 13:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF8Dodot-Eej; Wed, 23 Jul 2014 13:25:56 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244C81B2882; Wed, 23 Jul 2014 13:25:55 -0700 (PDT) Received: from dhcp-a5fc.meeting.ietf.org ([31.133.165.252]:61091) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XA36i-0001uC-Go; Wed, 23 Jul 2014 20:25:48 +0000 References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <6CFF2DD2-D3A4-410E-8320-F0E9A789EE71@juniper.net> <036d1ff7201340c48135ac0a38b05684@AM3PR03MB612.eurprd03.prod.outlook.com> <53CFB910.3030607@pi.nu> <6a7d4948bf7c4a70898db7884d74e86d@CO2PR05MB636.namprd05.prod.outlook.com> <002f01cfa6b1$3a6e8ee0$af4baca0$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: <002f01cfa6b1$3a6e8ee0$af4baca0$@ndzh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11D257) From: Russ White Date: Wed, 23 Jul 2014 16:25:46 -0400 To: Susan Hares X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/oYvFJ4VZfb7VCDy9Twqe-YagYMM Cc: Ross Callon , "rtg-dir@ietf.org" , Alexander Vainshtein , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:26:05 -0000 So... I hate to try and bring us back to basics, but I'm not certain I under= stand the goals very well. I think I heard: - increase participation - increase productivity The second I take to mean faster progress from idea to wg to draft... I susp= ect there is a third, which is to provide more direction in an architectural= sense to the area. The challenges, it seems to me, are: - momentum - the nature of IETF work (customer driven through vendors) - understanding what "participation" means I don't know if the proposed reorg would "solve" these problems. It seems, t= o me, that it makes sense to rethink things, but that rethinking might mean m= ore than "just" shuffling wg's around. Maybe we need to be more intentional a= bout using experimental status, to speed up getting work through without com= mitting to the standards track. Part of the problem, I think, is our focus o= n getting things to standards. I do like the idea of taking a more architectural view, and trying to find w= ays to bring more general resources to bear on more specific problems, I'm n= ot certain how to do it. Specifically, the Oma issues we seem to be relearni= ng from the ground up each time we approach that problem set, which seems in= efficient. It would be nice to get the point where extensions to OSPF and is= -is once, rather than once per protocol, but I don't know how to get from wh= ere we are to there. :-) Russ= From nobody Wed Jul 23 13:27:52 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C2A1B27D2; Wed, 23 Jul 2014 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mieDO3dlna57; Wed, 23 Jul 2014 13:27:43 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF471A0B0E; Wed, 23 Jul 2014 13:27:43 -0700 (PDT) Received: from [31.133.165.202] (dhcp-a5ca.meeting.ietf.org [31.133.165.202]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B0AEB18013DA; Wed, 23 Jul 2014 22:27:41 +0200 (CEST) Message-ID: <53D01AC7.2090303@pi.nu> Date: Wed, 23 Jul 2014 22:27:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Susan Hares , "'Giles Heron (giheron)'" References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> <0C3E5979-32FE-4F5B-971E-81F3D93173A2@cisco.com> <011801cfa664$a9573980$fc05ac80$@ndzh.com> <2AC27E6E-7994-47F6-B6AA-875E9FAB4047@cisco.com> <005c01cfa67c$87b42780$971c7680$@ndzh.com> <53CFBF9D.9030300@pi.nu> <00ca01cfa686$84c8e2e0$8e5aa8a0$@ndzh.com> <53D01592.7080103@pi.nu> <003e01cfa6b3$b9392300$2bab6900$@ndzh.com> In-Reply-To: <003e01cfa6b3$b9392300$2bab6900$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/zjoF4zyp6ZVaUSSO2dGjOT4f_Vo Cc: rtg-dir@ietf.org, "'Andrew G. Malis'" , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:27:47 -0000 Sue, I have one gut feeling that I don't know how much impact it will have on your result, I think that we can assume the a wg that produces "a lot of drafts" might attract more tourist, which might cause a correlation between the number of "participants" in the wg and the number of RFCs. I can't say if this is strong enough to show up in the results. /Loa On 2014-07-23 22:21, Susan Hares wrote: > Loa: > > Thank you for the correction to the second thesis. I will use this as the > second thesis in any testing. > Sue > > PS - I'm still in the process of trying to get a data file with the WG > identified and date. > > > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Wednesday, July 23, 2014 4:06 PM > To: Susan Hares; 'Giles Heron (giheron)' > Cc: rtg-dir@ietf.org; 'Andrew G. Malis'; rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] what is so bad > > Sue, > > On 2014-07-23 16:58, Susan Hares wrote: >> Loa and Giles: >> >> I've check the statistics on http://www.arkko.com/tools/idauthors.txt . >> These statistics do not have a link to working group or a time stamp >> for drafts and RFC even though there are links in the online database. >> Perhaps Jari or the tools team can help me get better data. I will >> check with the secretariat to see if they can give their numbers for WG > attendance. >> >> Your theses are: >> >> 1. "an increase in the numbers of WG attendees does not have a >> correlation to RFC production by a working group". >> 2. the RFC production has remained constant in the last 3 years >> within the standard deviation. >> >> If these are your two proposals, I can test these fairly quickly - once I >> validate the data. Jamal noted that the inclusion of many authors on a >> draft is "hacking the data". With author information, we can observe >> if the statistics of 4-5 authors differ from 1-3 authors. > > I think I agree to the first as one of "my theses", as for the second one > what I see is (for the MPLS wg) is that the number of RFC has been slowly > been increasing since we started to introduce process improvements about 2 > and a half year ago. > > /Loa > >> >> Please let me know if I have understood your concerns. >> >> Sue >> >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Wednesday, July 23, 2014 9:59 AM >> To: Susan Hares; 'Giles Heron (giheron)' >> Cc: 'Andrew G. Malis'; rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: Re: [RTG-DIR] what is so bad >> >> Sue, >> >> I don't think that Giles says that we should abandon traditional >> statistics, merely that the "numbers" the way I used can be made to >> show what you want them to show. And sure I agree to that. >> >> I further think that there are no way to actually show what has been >> alleged about giant groups and long periods of uninteresting >> presentations. It is simply not true. Though it is possible to to make >> it seem true by repeating it often enough. >> >> I would be in favor of having some useful traditional statistics >> available per working group if it can be achieved with a reasonable amount > of work. >> >> /Loa >> >> On 2014-07-23 15:46, Susan Hares wrote: >>> Giles: >>> >>> Ah... Do you have a proposal for what you consider valid, and reasons >>> for abandoning the traditional statistics. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >>> Sent: Wednesday, July 23, 2014 7:03 AM >>> To: Susan Hares >>> Cc: Andrew G. Malis; Loa Andersson; rtg-dir@ietf.org; >>> rtg-chairs@ietf.org >>> Subject: Re: [RTG-DIR] what is so bad >>> >>> Hi Sue, >>> >>> I think my point was rather that I'm not sure metrics are what we >>> should be concentrating on in this debate. Numbers can be made to >>> say just about anything, after all ;) >>> >>> Giles >>> >>> On 23 Jul 2014, at 11:55, Susan Hares wrote: >>> >>>> Giles: >>>> >>>> The performance that IETF has utilized for its ADs, IETF chairs, and >>>> WG >>> groups for 20 years has been: >>>> >>>> Quantitative: >>>> 1) RFC published >>>> 2) WG groups formed and completed >>>> 3) Administrative effectiveness (AFI/SAFIs, early code adoption, >>> ports assigned. ) >>>> 4) Number of authors and demographics on authors >>>> 5) Statistics on the timing of RFCs and the timing of WG forming >>>> 6) Statistics on attendance in WG/ IETF >>>> >>>> Please note, I do know of a statistically valid analysis of the >>> correlation between #6 an #1. If you do, I would be interested. >>>> >>>> Qualitatively >>>> 1) Technologies described in RFCs get deployed. >>>> 2) IETF is collaborative (at IESG, at WG), >>>> 3) People want to come (from surveys) >>>> >>>> The "people" want to come falls into a qualitative experience that >>>> says >>> "important to learn about the technology". >>>> >>>> http://www.arkko.com/tools/docstats.html has document statistics. >>>> >>>> If you want to propose a new metric it can be useful going forward, >>>> but >>> unless it is built on the data kept by the datatracker, we do not have > the >>> past trends to defend it. You could also use the mail list information, >>> but we would need to use a long-running group to get a valid statistics. >>>> >>>> Sue >>>> From: Giles Heron (giheron) [mailto:giheron@cisco.com] >>>> Sent: Wednesday, July 23, 2014 6:32 AM >>>> To: Andrew G. Malis >>>> Cc: Loa Andersson; rtg-dir@ietf.org; rtg-chairs@ietf.org >>>> Subject: Re: [RTG-DIR] what is so bad >>>> >>>> I'm not sure that how helpful the exercise is? Is performance >>>> really >>> related to how many people show up? There's no way after all to >>> determine what fraction of attendees are active participants vs "IETF >>> tourists". And of course we're supposed to do more work outside >>> meetings >> than in them. >>>> >>>> At any rate to be meaningful at all we need to weight the results by >>> length of WG meeting as time is the constraint we're trying to >>> optimise for here (I think!). I counted WG meeting durations in >>> minutes (since L2VPN was >>> 2 hours 10 mins - and I didn't have the time to type a recurring > decimal). >>> Couldn't find ROLL on the Vancouver Agenda though - so I used their >>> London duration. Of course then the RFCs per minute were all rather >>> low. In honour of the recent World Cup I went for RFCs per football >>> match (counting only the players and the playing minutes - no >>> allowance for referees, half-time, injury time or extra time). >>>> >>>> the results show PWE3 a mile ahead of the rest, followed by BFD, >>>> then >>> MPLS, then a cluster of WGs with very similar productivity (L2VPN >>> leading those by a nose, but who am I to brag?) with L3VPN and then >>> PCE (possibly the victim of the recent SDN hype) bringing up the rear. >>>> >>>> like I say, does this really mean anything? Can I have the last half >>> hour of my life (or rather 1/66 of a football match) back? >>>> >>>> Giles >>>> >>>> >>>> >>>> >>>> On 23 Jul 2014, at 03:55, Andrew G. Malis wrote: >>>> >>>>> Loa, >>>>> >>>>> I added one more column, to total all of the RFCs over the period. >>>>> mpls >>> came in first in terms of total RFCs per capita, and pwe3 came in >>> second. I also agree with your conclusions. >>>>> >>>>> Cheers, >>>>> Andy >>>>> >>>>> >>>>> On Tue, Jul 22, 2014 at 6:49 PM, Loa Andersson wrote: >>>>> Folks, >>>>> >>>>> I took a look at the performance on rtg wg's. >>>>> >>>>> The spread sheet list the number of RFC's per working group between >>>>> two meeting. I've used the number of people who signed the blue >>>>> sheets in Vancouver as some type of average except for roll that >>>>> did not meet in Vancouver, where I used the London figure instead. >>>>> >>>>> Calculated the number of RFCs per person in the room. >>>>> >>>>> The highest figure has BFD 0.12 RFCs prior to the IETF84 meeting. >>>>> The highest absolute number of RFC is MPLS (this meeting). >>>>> The best trend has MPLS. >>>>> >>>>> Since I don't care too much about how much noise the >>>>> non-participating participants is exposed too, I don't think the a >>>>> re-org is motivated by the figures in the spread sheet. >>>>> >>>>> I guess I would go as far as too say that no arguments presented so >>>>> far motivates a re-org of the RTG area. >>>>> >>>>> Though I'm totally supportive of some well considered >>>>> re-organization of working groups, but >>>>> >>>>> - do it carefully >>>>> - at a time when it is optimal for the working groups >>>>> - involve the chairs to drive the re-org >>>>> - don't break things that work >>>>> >>>>> /Loa >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> >>>>> >>>> >>> >>> >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:30:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E8C1B29EB; Wed, 23 Jul 2014 13:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AUwEQ4I-uVM; Wed, 23 Jul 2014 13:30:36 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBF71B29C8; Wed, 23 Jul 2014 13:30:35 -0700 (PDT) Received: from [31.133.165.202] (dhcp-a5ca.meeting.ietf.org [31.133.165.202]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B0C9018013DA; Wed, 23 Jul 2014 22:30:33 +0200 (CEST) Message-ID: <53D01B73.1070103@pi.nu> Date: Wed, 23 Jul 2014 22:30:43 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <20140723144806.GF4653@pfrc> <53D01880.4070903@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/PAVW612blpIv7FwQ4mvZCQz1g8s Cc: "George Swallow \(swallow\)" , Jeffrey Haas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:30:43 -0000 Alia, What in your mind is the correlation between "wg size" and "focus"? And what your metrics for "wg size" is? /Loa On 2014-07-23 22:21, Alia Atlas wrote: > Loa, > > It is a way of addressing topics that are split and does nothing to > address WG size > and focus. Of course we also need cross-WG communication. > > Alia > > On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson > wrote: > > Alia, > > I hope you understand that this type of inter wg communication, to > a certain extent makes the area re-org you have been proposing > unnecessary, while we still have to look at how optimize the working > groups. > > /Loa > > > On 2014-07-23 22:14, Alia Atlas wrote: > > We do have a lot of cases other than OAM where cross-WG > communication > would be very > useful. I am in favor of interest-based mailing lists. Another > case is > for routing YANG modules, > especially as the inter-dependencies need to be figured out. > > I have created a wiki page to track ideas for such mailing lists. > Please put your ideas there for > tracking (and feel free to add agreement/support/__disagreement). > > http://wiki.tools.ietf.org/__area/rtg/trac/wiki/__RtgCrossWGMailingLists > > > Alia > > > > On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow) > > >> wrote: > > Sounds like a good idea to me. Ops is about to charter a > centralized OAM > reporting group. We should include them as well. > > Along the lines of your second point we could experiment > with an OAM > mail > list. It'd be great if we could schedule the presentations > (assuming > they > would be short) in the rtgarea meeting. > > George > > On 7/23/14 10:48 AM, "Jeffrey Haas" > >> wrote: > > >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson > wrote: > >> On 2014-07-23 16:26, Jeffrey Haas wrote: > >> > For BFD, what we have seems to be working. > >> > >> I think this is key - what we have for BFD is working! > >> > >> Further, BFD is not generating any particular problems for > >> other working group. > >> > >> Conclusions: Don't touch BFD. > > > >That said, let's find a way to coordinate OAM across > groups, including > >BFD. > > > >In my discussions with Alia, I'm fond of the idea of > "meta" WGs. > >Individual > >work functions that implement IETF process (drafts, > chairs, etc.) > should > >be > >partially apportioned based on not overloading any given > function or > >individual. This was part of my comment about such a > merger likely > >involving adding a third chair. But as Brooks' book > tells us, > adding more > >people simply may make late work later - simply due to > the need for > >increased communication in the project. > > > >What we definitely could use is a meeting of the > meta-group, even > if only > >on > >a chairs basis, regularly. As long as we're talking > amongst each > other, > >we > >have IETF leadership level communication. > > > >The question of whether we need IETF participant > communication > broadened > >can > >be serviced by targeted presentation of related work in > an appropriate > >place. That could happen either in existing WG context > (preserve > WG work > >pipelining) or do more open meeting. > > > >Frankly, the Monday night dinner we had with several of > our key BFD > >members > >which also included significant conversation about > relationships to > >non-BFD > >OAM (e.g. CFM) was what we really need. > > > >-- Jeff > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:36:37 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0671B299D; Wed, 23 Jul 2014 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0bmWLh43vyG; Wed, 23 Jul 2014 13:36:34 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCBB1A0537; Wed, 23 Jul 2014 13:36:33 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f73so1200098yha.38 for ; Wed, 23 Jul 2014 13:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3C7Cwtcu43IXmHkw+66LtYz4CxiUeLw2rlZR969X9iE=; b=xeOf5cpzvyDQZwvXUBVk6U183WF713RdIeyDC9qLRGy3Gpmuo1T8BXrWBXZXTHKoSb KcxHnKGfGNLpJJbr/a3VOuV2Rw42opuQLmzR8DPChRIIyriNoznONiJvWD/ClPt2F/8m QHxgXdkIY0L8CHc5tHeCTvCOTDszcMRMZxMA3j0VUg76haxjdsxKubU+ZhSlBTXKdFKf +0g6LscoHMofFL8wl2UK0KAPyQEjI69JkvvhheMN80HLkZeBnQRGPhZZ0O/tHcmiiX9M KbF5uXRF8IwpMyhCirFbbwbfinnaCAd7mSWUIhsw8XSJ9D7V5D96uNr7pc51tvcTpan1 BynQ== MIME-Version: 1.0 X-Received: by 10.236.38.71 with SMTP id z47mr5388359yha.18.1406147792986; Wed, 23 Jul 2014 13:36:32 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Wed, 23 Jul 2014 13:36:32 -0700 (PDT) In-Reply-To: <53D01B73.1070103@pi.nu> References: <20140723144806.GF4653@pfrc> <53D01880.4070903@pi.nu> <53D01B73.1070103@pi.nu> Date: Wed, 23 Jul 2014 16:36:32 -0400 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7bf0d932b4017a04fee24bd5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/XhId4g01WkO-TtFYW9JluyWoDvk Cc: "George Swallow \(swallow\)" , Jeffrey Haas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:36:36 -0000 --047d7bf0d932b4017a04fee24bd5 Content-Type: text/plain; charset=UTF-8 Loa, It is not a function of the number of people, but the dynamics of the interactions between the people. A group could have 50 people actively discussing one topic, 50 people with about 10 per each of 5 topics, etc. Silence and lack of willingness to comment, review, or actively participate are bad signs. I can't give you a mathematical relationship that pretends people are wooden blocks that can be arbitrarily stacked together. Alia On Wed, Jul 23, 2014 at 4:30 PM, Loa Andersson wrote: > Alia, > > What in your mind is the correlation between "wg size" and "focus"? And > what your metrics for "wg size" is? > > /Loa > > > On 2014-07-23 22:21, Alia Atlas wrote: > >> Loa, >> >> It is a way of addressing topics that are split and does nothing to >> address WG size >> and focus. Of course we also need cross-WG communication. >> >> Alia >> >> On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson > > wrote: >> >> Alia, >> >> I hope you understand that this type of inter wg communication, to >> a certain extent makes the area re-org you have been proposing >> unnecessary, while we still have to look at how optimize the working >> groups. >> >> /Loa >> >> >> On 2014-07-23 22:14, Alia Atlas wrote: >> >> We do have a lot of cases other than OAM where cross-WG >> communication >> would be very >> useful. I am in favor of interest-based mailing lists. Another >> case is >> for routing YANG modules, >> especially as the inter-dependencies need to be figured out. >> >> I have created a wiki page to track ideas for such mailing lists. >> Please put your ideas there for >> tracking (and feel free to add agreement/support/__disagreement). >> >> http://wiki.tools.ietf.org/__area/rtg/trac/wiki/__ >> RtgCrossWGMailingLists >> >> > RtgCrossWGMailingLists> >> >> Alia >> >> >> >> On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow) >> >> >> wrote: >> >> Sounds like a good idea to me. Ops is about to charter a >> centralized OAM >> reporting group. We should include them as well. >> >> Along the lines of your second point we could experiment >> with an OAM >> mail >> list. It'd be great if we could schedule the presentations >> (assuming >> they >> would be short) in the rtgarea meeting. >> >> George >> >> On 7/23/14 10:48 AM, "Jeffrey Haas" > >> >> wrote: >> >> >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa Andersson >> wrote: >> >> On 2014-07-23 16:26, Jeffrey Haas wrote: >> >> > For BFD, what we have seems to be working. >> >> >> >> I think this is key - what we have for BFD is working! >> >> >> >> Further, BFD is not generating any particular problems >> for >> >> other working group. >> >> >> >> Conclusions: Don't touch BFD. >> > >> >That said, let's find a way to coordinate OAM across >> groups, including >> >BFD. >> > >> >In my discussions with Alia, I'm fond of the idea of >> "meta" WGs. >> >Individual >> >work functions that implement IETF process (drafts, >> chairs, etc.) >> should >> >be >> >partially apportioned based on not overloading any given >> function or >> >individual. This was part of my comment about such a >> merger likely >> >involving adding a third chair. But as Brooks' book >> tells us, >> adding more >> >people simply may make late work later - simply due to >> the need for >> >increased communication in the project. >> > >> >What we definitely could use is a meeting of the >> meta-group, even >> if only >> >on >> >a chairs basis, regularly. As long as we're talking >> amongst each >> other, >> >we >> >have IETF leadership level communication. >> > >> >The question of whether we need IETF participant >> communication >> broadened >> >can >> >be serviced by targeted presentation of related work in >> an appropriate >> >place. That could happen either in existing WG context >> (preserve >> WG work >> >pipelining) or do more open meeting. >> > >> >Frankly, the Monday night dinner we had with several of >> our key BFD >> >members >> >which also included significant conversation about >> relationships to >> >non-BFD >> >OAM (e.g. CFM) was what we really need. >> > >> >-- Jeff >> >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --047d7bf0d932b4017a04fee24bd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

It is not a function of the number= of people, but the dynamics of the interactions between the people.
<= div>A group could have 50 people actively discussing one topic, 50 people w= ith about 10 per each of 5
topics, etc. =C2=A0

Silence and lack of willi= ngness to comment, review, or actively participate are bad signs.

I can't give you a mathematical relationship that prete= nds people are wooden blocks that can
be arbitrarily stacked together.

Alia


On Wed, Ju= l 23, 2014 at 4:30 PM, Loa Andersson <loa@pi.nu> wrote:
Alia,

What in your mind is the correlation between "wg size" and "= focus"? And
what your metrics for "wg size" is?

/Loa


On 2014-07-23 22:21, Alia Atlas wrote:
Loa,

It is a way of addressing topics that are split and does nothing to
address WG size
and focus. =C2=A0 Of course we also need cross-WG communication.

Alia

On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson <loa@pi.nu
<mailto:loa@pi.nu>= > wrote:

=C2=A0 =C2=A0 Alia,

=C2=A0 =C2=A0 I hope you understand that this type of inter wg communicatio= n, to
=C2=A0 =C2=A0 a certain extent makes the area re-org you have been proposin= g
=C2=A0 =C2=A0 unnecessary, while we still have to look at how optimize the = working
=C2=A0 =C2=A0 groups.

=C2=A0 =C2=A0 /Loa


=C2=A0 =C2=A0 On 2014-07-23 22:14, Alia Atlas wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We do have a lot of cases other than OAM where = cross-WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 communication
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would be very
=C2=A0 =C2=A0 =C2=A0 =C2=A0 useful. =C2=A0I am in favor of interest-based m= ailing lists. =C2=A0Another
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for routing YANG modules,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 especially as the inter-dependencies need to be= figured out.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have created a wiki page to track ideas for s= uch mailing lists.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please put your ideas there for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tracking (and feel free to add agreement/suppor= t/__disagreement).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://wiki.tools.i= etf.org/__area/rtg/trac/wiki/__RtgCrossWGMailingLists
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://wiki.tools.i= etf.org/area/rtg/trac/wiki/RtgCrossWGMailingLists>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alia



=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Jul 23, 2014 at 3:50 PM, George Swallow= (swallow)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <swallow@cisco.com <mailto:swallow@cisco.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:swallow@cisco.com <mailto:swallow@cisco.com>>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sounds like a good idea to = me. =C2=A0Ops is about to charter a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0centralized OAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reporting group. We should = include them as well.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Along the lines of your sec= ond point we could experiment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with an OAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mail
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list. It'd be great if = we could schedule the presentations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (assuming
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would be short) in the rtga= rea meeting.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0George

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 7/23/14 10:48 AM, "= Jeffrey Haas" <= jhaas@pfrc.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:jhaas@pfrc.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:jhaas@pfrc.org <mailto:jhaas@pfrc.org>>>= wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >On Wed, Jul 23, 2014 a= t 04:37:35PM +0200, Loa Andersson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> On 2014-07-23 16:= 26, Jeffrey Haas wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> > =C2=A0For BF= D, what we have seems to be working.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> I think this is k= ey - what we have for BFD is working!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Further, BFD is n= ot generating any particular problems for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> other working gro= up.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Conclusions: Don&= #39;t touch BFD.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >That said, let's f= ind a way to coordinate OAM across
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups, including
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >BFD.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >In my discussions with= Alia, I'm fond of the idea of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "meta" WGs.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >Individual
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >work functions that im= plement IETF process (drafts,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 chairs, etc.)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >partially apportioned = based on not overloading any given
=C2=A0 =C2=A0 =C2=A0 =C2=A0 function or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >individual. =C2=A0This= was part of my comment about such a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 merger likely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >involving adding a thi= rd chair. =C2=A0But as Brooks' book
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tells us,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adding more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >people simply may make= late work later - simply due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the need for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >increased communicatio= n in the project.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >What we definitely cou= ld use is a meeting of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 meta-group, even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >a chairs basis, regula= rly. =C2=A0As long as we're talking
=C2=A0 =C2=A0 =C2=A0 =C2=A0 amongst each
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >have IETF leadership l= evel communication.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >The question of whethe= r we need IETF participant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 communication
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0broadened
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >be serviced by targete= d presentation of related work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 an appropriate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >place. =C2=A0That coul= d happen either in existing WG context
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (preserve
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WG work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >pipelining) or do more= open meeting.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >Frankly, the Monday ni= ght dinner we had with several of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 our key BFD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >members
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >which also included si= gnificant conversation about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 relationships to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >non-BFD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >OAM (e.g. CFM) was wha= t we really need.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >-- Jeff



=C2=A0 =C2=A0 --


=C2=A0 =C2=A0 Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
=C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com>
=C2=A0 =C2=A0 Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>

=C2=A0 =C2=A0 Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 21 64
=C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>



--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64

--047d7bf0d932b4017a04fee24bd5-- From nobody Wed Jul 23 13:39:36 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4C1B2A1E; Wed, 23 Jul 2014 13:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJa0sbeth5iv; Wed, 23 Jul 2014 13:39:34 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC951B29EB; Wed, 23 Jul 2014 13:39:33 -0700 (PDT) Received: from [31.133.165.202] (dhcp-a5ca.meeting.ietf.org [31.133.165.202]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CA48618013DA; Wed, 23 Jul 2014 22:39:31 +0200 (CEST) Message-ID: <53D01D8D.4060904@pi.nu> Date: Wed, 23 Jul 2014 22:39:41 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <20140723144806.GF4653@pfrc> <53D01880.4070903@pi.nu> <53D01B73.1070103@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/cwqjbx3PlkTFtevZNvRO9rQDHU4 Cc: "George Swallow \(swallow\)" , Jeffrey Haas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:39:36 -0000 OK - fair enough, can you give a hint of which working groups you think lack "focus" because of its size? /Loa On 2014-07-23 22:36, Alia Atlas wrote: > Loa, > > It is not a function of the number of people, but the dynamics of the > interactions between the people. > A group could have 50 people actively discussing one topic, 50 people > with about 10 per each of 5 > topics, etc. > > Silence and lack of willingness to comment, review, or actively > participate are bad signs. > > I can't give you a mathematical relationship that pretends people are > wooden blocks that can > be arbitrarily stacked together. > > Alia > > > On Wed, Jul 23, 2014 at 4:30 PM, Loa Andersson > wrote: > > Alia, > > What in your mind is the correlation between "wg size" and "focus"? And > what your metrics for "wg size" is? > > /Loa > > > On 2014-07-23 22:21, Alia Atlas wrote: > > Loa, > > It is a way of addressing topics that are split and does nothing to > address WG size > and focus. Of course we also need cross-WG communication. > > Alia > > On Wed, Jul 23, 2014 at 4:18 PM, Loa Andersson > >> wrote: > > Alia, > > I hope you understand that this type of inter wg > communication, to > a certain extent makes the area re-org you have been proposing > unnecessary, while we still have to look at how optimize > the working > groups. > > /Loa > > > On 2014-07-23 22:14, Alia Atlas wrote: > > We do have a lot of cases other than OAM where cross-WG > communication > would be very > useful. I am in favor of interest-based mailing lists. > Another > case is > for routing YANG modules, > especially as the inter-dependencies need to be figured > out. > > I have created a wiki page to track ideas for such > mailing lists. > Please put your ideas there for > tracking (and feel free to add > agreement/support/____disagreement). > > http://wiki.tools.ietf.org/____area/rtg/trac/wiki/____RtgCrossWGMailingLists > > > > > > > Alia > > > > On Wed, Jul 23, 2014 at 3:50 PM, George Swallow (swallow) > > > > > >>> wrote: > > Sounds like a good idea to me. Ops is about to > charter a > centralized OAM > reporting group. We should include them as well. > > Along the lines of your second point we could > experiment > with an OAM > mail > list. It'd be great if we could schedule the > presentations > (assuming > they > would be short) in the rtgarea meeting. > > George > > On 7/23/14 10:48 AM, "Jeffrey Haas" > > > > > >>> wrote: > > >On Wed, Jul 23, 2014 at 04:37:35PM +0200, Loa > Andersson > wrote: > >> On 2014-07-23 16:26, Jeffrey Haas wrote: > >> > For BFD, what we have seems to be working. > >> > >> I think this is key - what we have for BFD is > working! > >> > >> Further, BFD is not generating any particular > problems for > >> other working group. > >> > >> Conclusions: Don't touch BFD. > > > >That said, let's find a way to coordinate OAM across > groups, including > >BFD. > > > >In my discussions with Alia, I'm fond of the idea of > "meta" WGs. > >Individual > >work functions that implement IETF process (drafts, > chairs, etc.) > should > >be > >partially apportioned based on not overloading > any given > function or > >individual. This was part of my comment about > such a > merger likely > >involving adding a third chair. But as Brooks' book > tells us, > adding more > >people simply may make late work later - simply > due to > the need for > >increased communication in the project. > > > >What we definitely could use is a meeting of the > meta-group, even > if only > >on > >a chairs basis, regularly. As long as we're talking > amongst each > other, > >we > >have IETF leadership level communication. > > > >The question of whether we need IETF participant > communication > broadened > >can > >be serviced by targeted presentation of related > work in > an appropriate > >place. That could happen either in existing WG > context > (preserve > WG work > >pipelining) or do more open meeting. > > > >Frankly, the Monday night dinner we had with > several of > our key BFD > >members > >which also included significant conversation about > relationships to > >non-BFD > >OAM (e.g. CFM) was what we really need. > > > >-- Jeff > > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu > > > > Huawei Technologies (consultant) phone: +46 739 81 21 > 64 > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Jul 23 13:44:01 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F098D1B2B03; Wed, 23 Jul 2014 13:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT8UD2fJLjCF; Wed, 23 Jul 2014 13:43:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4681B2AE8; Wed, 23 Jul 2014 13:43:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN52184; Wed, 23 Jul 2014 20:43:55 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 21:43:55 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 04:43:48 +0800 From: Mach Chen To: Loa Andersson Thread-Topic: [RTG-DIR] what is so bad Thread-Index: AQHPpf81A3cShPYKQ0S6LMEr44Pxp5uuHx4g Date: Wed, 23 Jul 2014 20:43:47 +0000 Message-ID: References: <036f01cf8fe8$d8c5cca0$8a5165e0$@olddog.co.uk> <53CE7407.1080607@joelhalpern.com> <53CEEA79.8010300@pi.nu> In-Reply-To: <53CEEA79.8010300@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.159] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/d3Ghmr5UEOETfQWdFvHO-IhwWCI Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] what is so bad X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:44:01 -0000 SGkgTG9hLA0KDQo+IFRob3VnaCBJJ20gdG90YWxseSBzdXBwb3J0aXZlIG9mIHNvbWUgd2VsbCBj b25zaWRlcmVkIHJlLW9yZ2FuaXphdGlvbiBvZg0KPiB3b3JraW5nIGdyb3VwcywgYnV0DQo+IA0K PiAtIGRvIGl0IGNhcmVmdWxseQ0KPiAtIGF0IGEgdGltZSB3aGVuIGl0IGlzIG9wdGltYWwgZm9y IHRoZSB3b3JraW5nIGdyb3Vwcw0KPiAtIGludm9sdmUgdGhlIGNoYWlycyB0byBkcml2ZSB0aGUg cmUtb3JnDQo+IC0gZG9uJ3QgYnJlYWsgdGhpbmdzIHRoYXQgd29yaw0KDQpJIGFncmVlIHdpdGgg dGhpcywgYW5kIEkgd291bGQgbGlrZSB0byBhZGQgb25lLCB3aGVuIHBsYW4gdG8gcmUtb3JnIGEg V0csIGl0IHNob3VsZCBiZSBjbGVhciB3aGF0IHByb2JsZW1zIGFyZSBnb2luZyB0byBiZSBzb2x2 ZWQgYW5kIHdoYXQgaW1wcm92ZW1lbnRzIGFyZSBkZXNpcmVkLg0KDQpCZXN0IHJlZ2FyZHMsDQpN YWNoDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcnRnLWRpciBbbWFp bHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24N Cj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDY6NDkgQU0NCj4gQ2M6IHJ0Zy1kaXJA aWV0Zi5vcmc7IHJ0Zy1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW1JURy1ESVJdIHdoYXQg aXMgc28gYmFkDQo+IA0KPiBGb2xrcywNCj4gDQo+IEkgdG9vayBhIGxvb2sgYXQgdGhlIHBlcmZv cm1hbmNlIG9uIHJ0ZyB3ZydzLg0KPiANCj4gVGhlIHNwcmVhZCBzaGVldCBsaXN0IHRoZSBudW1i ZXIgb2YgUkZDJ3MgcGVyIHdvcmtpbmcgZ3JvdXAgYmV0d2VlbiB0d28NCj4gbWVldGluZy4gSSd2 ZSB1c2VkIHRoZSBudW1iZXIgb2YgcGVvcGxlIHdobyBzaWduZWQgdGhlIGJsdWUgc2hlZXRzIGlu DQo+IFZhbmNvdXZlciBhcyBzb21lIHR5cGUgb2YgYXZlcmFnZSBleGNlcHQgZm9yIHJvbGwgdGhh dCBkaWQgbm90IG1lZXQgaW4NCj4gVmFuY291dmVyLCB3aGVyZSBJIHVzZWQgdGhlIExvbmRvbiBm aWd1cmUgaW5zdGVhZC4NCj4gDQo+IENhbGN1bGF0ZWQgdGhlIG51bWJlciBvZiBSRkNzIHBlciBw ZXJzb24gaW4gdGhlIHJvb20uDQo+IA0KPiBUaGUgaGlnaGVzdCBmaWd1cmUgaGFzIEJGRCAwLjEy IFJGQ3MgcHJpb3IgdG8gdGhlIElFVEY4NCBtZWV0aW5nLg0KPiBUaGUgaGlnaGVzdCBhYnNvbHV0 ZSBudW1iZXIgb2YgUkZDIGlzIE1QTFMgKHRoaXMgbWVldGluZykuDQo+IFRoZSBiZXN0IHRyZW5k IGhhcyBNUExTLg0KPiANCj4gU2luY2UgSSBkb24ndCBjYXJlIHRvbyBtdWNoIGFib3V0IGhvdyBt dWNoIG5vaXNlIHRoZSBub24tcGFydGljaXBhdGluZw0KPiBwYXJ0aWNpcGFudHMgaXMgZXhwb3Nl ZCB0b28sIEkgZG9uJ3QgdGhpbmsgdGhlIGEgcmUtb3JnIGlzIG1vdGl2YXRlZCBieSB0aGUgZmln dXJlcw0KPiBpbiB0aGUgc3ByZWFkIHNoZWV0Lg0KPiANCj4gSSBndWVzcyBJIHdvdWxkIGdvIGFz IGZhciBhcyB0b28gc2F5IHRoYXQgbm8gYXJndW1lbnRzIHByZXNlbnRlZCBzbyBmYXINCj4gbW90 aXZhdGVzIGEgcmUtb3JnIG9mIHRoZSBSVEcgYXJlYS4NCj4gDQo+IFRob3VnaCBJJ20gdG90YWxs eSBzdXBwb3J0aXZlIG9mIHNvbWUgd2VsbCBjb25zaWRlcmVkIHJlLW9yZ2FuaXphdGlvbiBvZg0K PiB3b3JraW5nIGdyb3VwcywgYnV0DQo+IA0KPiAtIGRvIGl0IGNhcmVmdWxseQ0KPiAtIGF0IGEg dGltZSB3aGVuIGl0IGlzIG9wdGltYWwgZm9yIHRoZSB3b3JraW5nIGdyb3Vwcw0KPiAtIGludm9s dmUgdGhlIGNoYWlycyB0byBkcml2ZSB0aGUgcmUtb3JnDQo+IC0gZG9uJ3QgYnJlYWsgdGhpbmdz IHRoYXQgd29yaw0KPiANCj4gL0xvYQ0KPiANCj4gDQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20N Cj4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUN Cj4gSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgx IDIxIDY0DQo= From nobody Thu Jul 24 11:05:54 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC0A1A023E; Thu, 24 Jul 2014 04:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.752 X-Spam-Level: X-Spam-Status: No, score=-94.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkQnbVCUicho; Thu, 24 Jul 2014 04:52:49 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23AB1A01DC; Thu, 24 Jul 2014 04:52:45 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 24 Jul 2014 20:52:44 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Thu, 24 Jul 2014 20:52:38 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger , Yaacov Weingarten Thread-Topic: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-smp-requirements-06.txt Thread-Index: AQHPjWn3yaQ2bqHMa0u/oexBdb3lpJuPKTU+gAI5dwCAG8haAIACIb8i Date: Thu, 24 Jul 2014 11:52:37 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2874CF28@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> , <53CFA4FC.3080304@labn.net> In-Reply-To: <53CFA4FC.3080304@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/8aS-DNehrERBlknK7CArmP-SLaQ X-Mailman-Approved-At: Thu, 24 Jul 2014 11:05:37 -0700 Cc: "mpls@ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogIFttcGxzXSBSdGdEaXIgcmV2aWV3OiBkcmFm?= =?euc-kr?q?t-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 11:52:55 -0000 TG91LA0KDQpBbnkgYW1iaWd1aXR5IGlzIG5vdCBpbnRlbnRpb25hbC4NCg0KVGhlIGxhdGVzdCB0 ZXh0IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZSBpczoNCi0tLSANCiAgIDMuIElmIG11bHRpcGxlIHBy b3RlY3Rpb24gcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3RpbmcgdGhlDQogICAg ICBzaGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2VzIFNIQUxMIGJlIHV0aWxpemVkIG9uIGEg Zmlyc3QgY29tZQ0KICAgICAgZmlyc3Qgc2VydmVkIGJhc2lzLiBUcmFmZmljIG9mIHRoZSBwcm90 ZWN0aW9uIHBhdGhzIHRoYXQgcmVxdWVzdA0KICAgICAgdGhlIHNoYXJlZCByZXNvdXJjZXMgbGF0 ZSBTSEFMTCBiZSBwcmVlbXB0ZWQuIEluIG9yZGVyIHRvIGNvdmVyDQogICAgICB0aGUgc2l0dWF0 aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZCBwcmluY2lwbGUgY2Fubm90DQog ICAgICByZXNvbHZlIHRoZSBjb250ZW50aW9uIGFtb25nIG11bHRpcGxlIGVxdWFsIHByaW9yaXR5 IHJlcXVlc3RzLA0KICAgICAgaS5lLiwgd2hlbiB0aGUgcmVxdWVzdHMgb2NjdXIgc2ltdWx0YW5l b3VzbHksIHRpZS1icmVha2luZyBydWxlcw0KICAgICAgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29w ZSBvZiBhbiBTTVAgZG9tYWluLg0KDQogICA0LiBJZiBhIGhpZ2hlciBwcmlvcml0eSBwYXRoIHJl cXVpcmVzIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyB0aGF0DQogICAgICBhcmUgYmVpbmcgdXRp bGl6ZWQgYnkgYSBsb3dlciBwcmlvcml0eSBwYXRoLCB0aGUgcmVzb3VyY2VzIFNIQUxMDQogICAg ICBiZSB1dGlsaXplZCBieSB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGguIFRyYWZmaWMgd2l0aCB0 aGUgbG93ZXINCiAgICAgIHByaW9yaXR5IFNIQUxMIGJlIHByZWVtcHRlZC4NCi0tLQ0KDQpUaGUg dGV4dCBpcyBhbHJlYWR5IHNheWluZyB0aGF0IHRoZSBwcmVlcG10aW9uIGFuZCB1dGlsaXphdGlv biBpcyBwZXIgcGF0aCBiYXNpcy4gDQpJbiBteSBvcGluaW9uLCBpdCBzZWVtcyB0byBiZSBvayB3 aXRob3V0IGFkZGluZyBhbiBMU1AgaGVyZS4NCg0KSmVvbmctZG9uZw0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KurizvSC757b3OiBMb3UgQmVyZ2VyIFts YmVyZ2VyQGxhYm4ubmV0XQ0KurizvSCzr8KlOiAyMDE0s+IgN7/5IDIzwM8gvPa/5MDPIL/AyMQg OTowNQ0Kud60wiC757b3OiBZYWFjb3YgV2VpbmdhcnRlbjsgt/nBpLW/DQrC/MG2OiBtcGxzQGll dGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5v cmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmcNCsGmuPE6IFJlOiBb UlRHLURJUl0gW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWly ZW1lbnRzLTA2LnR4dA0KDQpZYWFjb3YsIEplb25nLA0KICAgIEknbSBub3Qgc3VyZSBob3cgdGhl IGxhdGVzdCB0ZXh0IGFkZHJlc3NlcyB0aGUgYW1iaWd1aXR5IHlvdQ0KaWRlbnRpZmllZCBiZWxv dy4gIFBlcmhhcHMgYWRkaW5nIHRoZSB3b3JkcyAib24gYSBwZXIgTFNQIGJhc2lzIiB0byB0aGUN CnJlcXVpcmVtZW50PyAgSWYgdGhlIGFtYmlndWl0eSBpcyBpbnRlbnRpb25hbCwgdGhlbiBvZiBj b3Vyc2Ugbm8gY2hhbmdlDQppcyB3YXJyYW50ZWQuDQoNCkxvdQ0KDQpPbiA3LzUvMjAxNCAzOjQ5 IFBNLCBZYWFjb3YgV2VpbmdhcnRlbiB3cm90ZToNCj4NCj4gTG91LCBoaQ0KPiBJIHdvdWxkIGxp a2UgdG8gYWRkcmVzcyB0d28gb2YgeW91ciBjb21tZW50cywgaW4geW91ciBmb2xsb3ctdXANCj4g bWVzc2FnZSwgc2luY2UgSSBhbSB0aGUgc291cmNlIG9mIHRoZSBjaGFuZ2UgaW4gdGVybWlub2xv Z3kuDQo+DQo+IFJlZ2FyZGluZyB0aGUgdHdvIG9jY3VyZW5jZXMgb2YgImFzc2lnbmVkIiBpbiBw bGFjZSBvZiAidXRpbGl6ZWQiIC0NCj4gd2hlbiBJIHJlYWQgdGhlIHByb3Bvc2VkIGNoYW5nZXMs YXMgZGlzY3Vzc2VkIGFtb25nc3QgdGhlIGF1dGhvcnMsIEkNCj4gZmVsdCB0aGF0IGluIHRob3Nl IHR3byBpbnN0YW5jZXMgdGhlIHVzZSBvZiAidXRpbGl6ZWQiIGNvdWxkIGxlYWQgdG8NCj4gc29t ZSBhbWJpZ3VpdHkuDQo+DQo+IElmIHdlIHN0YXRlIHRoYXQgInJlc291cmNlcyBTSE9VTEQgYmUg dXRpbGl6ZWQgb24gYSBmaXJzdCBjb21lIGZpcnN0DQo+IHNlcnZlZCBiYXNpcyIgdGhpcyBjb3Vs ZCBiZSBpbnRlcnByZXRlZCAoSU1PKSBhcyByZWZlcnJpbmcgdG8gdGhlDQo+IHBhY2tldCBsZXZl bCwgcmF0aGVyIHRoYW4gIHV0aWxpemVkIGJ5IGEgc3BlY2lmaWMgcGF0aCwgc3VjaCB0aGF0DQo+ IHBhY2tldHMgZnJvbSBkaWZmZXJlbnQgcGF0aHMgY291bGQgYmUgaW50ZXJzcGVyc2VkIGFsb25n IHRoZSBzaGFyZWQNCj4gc2VnbWVudHMuIFRoZXJlZm9yZSxJIHN1Z2dlc3RlZCB0aGF0IG9yIHRo aXMgY29udGV4dCBpdCB3b3VsZCBiZQ0KPiBiZXR0ZXIgdG8gdXNlIGEgd29yZCB0aGF0IG1lYW50 IHRoYXQgdGhlIGZpcnN0LWNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzDQo+IHdhcyBhdCB0aGUgbGV2 ZWwgb2YgYXNzaWduaW5nIChvciBhbGxvY2F0aW5nKSB0aGUgcmVzb3VyY2VzIHJhdGhlcg0KPiB0 aGFuIHV0aWxpemluZyB0aGVtLg0KPg0KPiBIb3BlIHRoaXMgY2xhcmlmaWVzIHRoaXMgcG9pbnQu IEkgYW0gY2VydGFpbiB0aGF0IEkgc3BlYWsgZm9yIHRoZQ0KPiBvdGhlciBhdXRob3JzIGluICBz YXlpbmcgdGhhdCBJIGFtIG9wZW4gdG8gb3RoZXIgc3VnZ2VzdGlvbnMuDQo+DQo+IEJSLA0KPiB5 YWFjb3YNCj4NCj4gT24gSnVsIDQsIDIwMTQgMzo1MyBBTSwgIkplb25nIFJ5b28iIDxyeW9vQGV0 cmkucmUua3INCj4gPG1haWx0bzpyeW9vQGV0cmkucmUua3I+PiB3cm90ZToNCj4NCj4gICAgIERl YXIgTG91LA0KPg0KPg0KPg0KPiAgICAgVGhhbmtzIGEgbG90IGZvciB5b3VyIHZhbHVhYmxlIGNv bW1lbnRzLg0KPg0KPg0KPg0KPiAgICAgVGhlIGF1dGhvcnMgb2YgdGhpcyBkcmFmdCBoYXZlIGRp c2N1c3NlZCB5b3VyIGNvbW1lbnRzLCBhbmQgYXJlDQo+ICAgICBwcm9wb3Npbmcgb3VyIHJlc29s dXRpb25zIHRvIHlvdXIgY29tbWVudHMuIFBsZWFzZSwgbGV0IHVzIGtub3cgaWYNCj4gICAgIHRo ZSBwcm9wb3NhbCBpcyBhcHByb3ByaWF0ZSB0byBhZGRyZXNzIHlvdXIgY29tbWVudHMgYW5kIGNv bmNlcm5zLg0KPg0KPg0KPg0KPiAgICAgQmVzdCByZWdhcmRzLA0KPg0KPg0KPg0KPiAgICAgQXV0 aG9ycyBvZiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cyBkcmFmdA0KPg0KPg0KPg0K PiAgICAgKioqKioqIEJlZ2lubmluZyBvZiBDb21tZW50IFJlc29sdXRpb24gKioqKioqDQo+DQo+ DQo+DQo+ICAgICAtIERvY3VtZW50J3MgdXNhZ2Ugb2YgImNvbW1pdHRlZCIgdnMgImFsbG9jYXRl ZCIgcmVzb3VyY2VzOg0KPg0KPiAgICAgSW4gc2VjdGlvbiAxIHRoZSBkb2N1bWVudCBpbnRyb2R1 Y2VzIHRoZSBub3Rpb24gdGhhdCB0aGUNCj4gICAgIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVj dGlvbiBhbmQgcmVzdG9yYXRpb24gaXMgYmFzZWQgb24gd2hlbg0KPiAgICAgcmVzb3VyY2VzIGFy ZSAiY29tbWl0dGVkIi4gVGhpcyBkaWZmZXJlbmNlIGZyb20gcGFzdA0KPiAgICAgZGVmaW5pdGlv bi4gUkZDNDQyNyBhbmQgNjM3MiBtYWtlIHRoZSBkaXN0aW5jdGlvbiB0aGF0IHByb3RlY3Rpb24N Cj4gICAgIGFuZCByZXN0b3JhdGlvbiBkaWZmZXIgYmFzZWQgb24gd2hlbiByZXNvdXJjZXMgYXJl ICphbGxvY2F0ZWQqIG5vdA0KPiAgICAgKmNvbW1pdHRlZCouIFRvIHF1b3RlIFJGQyA0NDI3Og0K Pg0KPiAgICAgVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gcHJvdGVjdGlvbiBhbmQgcmVzdG9yYXRp b24gaXMgbWFkZSBiYXNlZA0KPiAgICAgb24gdGhlIHJlc291cmNlIGFsbG9jYXRpb24gZG9uZSBk dXJpbmcgdGhlIHJlY292ZXJ5IExTUC9zcGFuDQo+ICAgICBlc3RhYmxpc2htZW50LiBUaGUgZGlz dGluY3Rpb24gYmV0d2VlbiBkaWZmZXJlbnQgdHlwZXMgb2YNCj4gICAgIHJlc3RvcmF0aW9uIGlz IG1hZGUgYmFzZWQgb24gdGhlIGxldmVsIG9mIHJvdXRlIGNvbXB1dGF0aW9uLA0KPiAgICAgc2ln bmFsaW5nLCBhbmQgcmVzb3VyY2UgYWxsb2NhdGlvbiBkdXJpbmcgdGhlIHJlc3RvcmF0aW9uDQo+ ICAgICBMU1Avc3BhbiBlc3RhYmxpc2htZW50Lg0KPg0KPiAgICAgVGhpcyBkaWZmZXJlbmNlIGFs c28gbGVhZHMgdG8gY29tZSBjb25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZQ0KPiAgICAgZG9jdW1l bnQgYXMgd2VsbCBhcyBhbWJpZ3VpdHkgaW4gdGhlIHRleHQsIGkuZS4gY29uZnVzaW9uIGJ5IHRo ZQ0KPiAgICAgcmVhZGVyLiBUaGUgdGVybSAiY29tbWl0dGVkIiBpcyBub3QgdGlnaHRseSBkZWZp bmVkIGluIHRoaXMNCj4gICAgIGRvY3VtZW50IChvciBlYXJsaWVyIHdvcmspIGFuZCBpcyB1c2Vk IGRpZmZlcmVudGx5IHRoYW4gaG93DQo+ICAgICAiYWxsb2NhdGVkIiBoYXMgYmVlbiB1c2VkLiBB biBleGFtcGxlIG9mIHRoaXMgY2FuIGJlIGZvdW5kIGluDQo+ICAgICBTZWN0aW9uIDMuMSB3aGlj aCBzdGF0ZXM6DQo+DQo+ICAgICBIb3dldmVyLCB0aGUgY29tbWl0bWVudCBvZiB0aGUgcmVzb3Vy Y2VzLCBhdCBsZWFzdCBmb3IgdGhlDQo+ICAgICBzaGFyZWQgc2VnbWVudHMsIHdpbGwgb25seSBi ZSBmaW5hbGl6ZWQgd2hlbiB0aGUgcHJvdGVjdGlvbg0KPiAgICAgcGF0aCBpcyBhY3R1YWxseSBh Y3RpdmF0ZWQuIFRoZXJlZm9yZSwgZm9yIHRoZSBwdXJpc3RzIC0NCj4gICAgIHJlZ2FyZGluZyB0 aGUgdGVybWlub2xvZ3kgLSBTTVAgbGllcyBzb21ld2hlcmUgYmV0d2Vlbg0KPiAgICAgcHJvdGVj dGlvbiBhbmQgcmVzdG9yYXRpb24uDQo+DQo+ICAgICBCb3RoIHNlbnRlbmNlcyBhcmUgcHJvYmxl bWF0aWMuIEluIHRoZSBmaXJzdCwgY29tbWl0bWVudCBzZWVtcyB0bw0KPiAgICAgY292ZXIgYSAi cHJvdGVjdGlvbiBzd2l0Y2giIHdvdWxkICJjb25uZWN0IiB0aGUgcHJvdGVjdGlvbiBwYXRoDQo+ ICAgICBidXQgbm90IHRoZSBlYXJsaWVyICJhbGxvY2F0aW9uIiBvZiByZXNvdXJjZXMuIChRdW90 ZWQgdGVybXMgYXJlDQo+ICAgICB1c2VkIGluIGVhcmxpZXIgUkZDcy4pIFRoZSBzZWNvbmQgY29u Y2x1c2lvbiBpcyBiYXNlZCBvbiB0aGUgbmV3DQo+ICAgICBkaXN0aW5jdGlvbiBvZiBwcm90ZWN0 aW9uIHZzLiByZXN0b3JhdGlvbiBhbmQgaXMgdW5uZWNlc3Nhcnkgd2l0aA0KPiAgICAgdGhlIGV4 aXN0aW5nIGRpc3RpbmN0aW9uLg0KPg0KPiAgICAgVGhpcyBpc3N1ZSBleGlzdHMgaW4gbXVsdGlw bGUgcGxhY2VzIGluIHRoZSBkb2N1bWVudCB3aGVyZQ0KPiAgICAgImNvbW1pdHRlZCIgaXMgdXNl ZCBhbmQgSSdkIHJlY29tbWVuZCB0aGF0IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkDQo+ICAgICB3 aXRoIHRlcm1pbm9sb2d5IHVzZWQgaW4gdGhlIHJlZmVyZW5jZWQgUkZDcywgaS5lLiwgImFsbG9j YXRpb24iLA0KPiAgICAgImNvbm5lY3Rpb24iLCAiY3Jvc3MtY29ubmVjdCIsICJwcm90ZWN0aW9u IHN3aXRjaChvdmVyKSIsIC4uLg0KPg0KPiAgICAgTm90ZSBJJ20gKm5vdCogaGlnaGxpZ2h0aW5n IGFsbCBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgcHJvYmxlbXMgaW4gdGhlDQo+ICAgICBkb2N1bWVu dCByZWxhdGVkIHRvIHRoaXMgaXNzdWUuIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBwbGFjZXMgaW4g dGhlDQo+ICAgICBkb2N1bWVudCB3aGVyZSBJIHRoaW5rIGl0J3MgcG9zc2libGUgdGhhdCBvbmNl IHRoaXMgdGVybWlub2xvZ3kNCj4gICAgIGFtYmlndWl0eSBpcyBjb3JyZWN0ZWQgdGhhdCBJJ2xs IGhhdmUgb3RoZXIgc3Vic3RhbnRpdmUgY29tbWVudHMuDQo+DQo+DQo+DQo+ICAgICBbQXV0aG9y c10gQWZ0ZXIgcmV2aWV3aW5nIFJGQ3MgNDQyNywgNjM3MiwgMzk0NSwgNDQyNiwgYW5kIDQ0Mjgs DQo+ICAgICB3ZSBjb25jbHVkZWQgdGhhdCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90ZWN0 aW9uIGFuZA0KPiAgICAgcmVzdG9yYXRpb24gc2hvdWxkIGJlIGFsaWduZWQgd2l0aCB0aGUgZXhp dGluZyBkb2N1bWVudHMNCj4gICAgIG5vcm1hdGl2ZWx5IHJlZmVyZW5jZWQgYnkgdGhpcyBkb2N1 bWVudC4gQWNjb3JkaW5nbHksIHRoZQ0KPiAgICAgZm9sbG93aW5nIDE2IG1vZGlmaWNhdGlvbnMg d2lsbCBiZSBkb25lIGluIHJldmlzaW9uOg0KPg0KPg0KPg0KPiAgICAgKDEpIFNlY3Rpb24gMSwg dGhlIHRoaXJkIHBhcmFncmFwaA0KPg0KPiAgICAgT0xEOg0KPg0KPiAgICAgQXMgcG9pbnRlZCBv dXQNCj4NCj4gICAgIGluIFtSRkM2MzcyXSBhbmQgW1JGQzQ0MjhdLCBhcHBseWluZyAxKzEgbGlu ZWFyIHByb3RlY3Rpb24gcmVxdWlyZXMNCj4NCj4gICAgIHRoYXQgcmVzb3VyY2VzIGFyZSBjb21t aXR0ZWQgZm9yIHVzZSBieSBib3RoIHRoZSB3b3JraW5nIGFuZA0KPg0KPiAgICAgcHJvdGVjdGlv biBwYXRocy4gQXBwbHlpbmcgMToxIHByb3RlY3Rpb24gcmVxdWlyZXMgdGhhdCB0aGUgc2FtZQ0K Pg0KPiAgICAgcmVzb3VyY2VzIGFyZSBjb21taXR0ZWQsIGJ1dCBhbGxvd3MgdGhlIHJlc291cmNl cyBvZiB0aGUgcHJvdGVjdGlvbg0KPg0KPiAgICAgcGF0aCB0byBiZSB1dGlsaXplZCBmb3IgcHJl LWVtcHRpYmxlIGV4dHJhIHRyYWZmaWMuDQo+DQo+ICAgICBORVc6DQo+DQo+ICAgICBBcyBwb2lu dGVkIG91dA0KPg0KPiAgICAgaW4gW1JGQzYzNzJdIGFuZCBbUkZDNDQyOF0sIGFwcGx5aW5nIDEr MSBwcm90ZWN0aW9uIHJlcXVpcmVzDQo+DQo+ICAgICB0aGF0IHJlc291cmNlcyBhcmUgYWxsb2Nh dGVkIGZvciB1c2UgYnkgYm90aCB0aGUgd29ya2luZyBhbmQNCj4NCj4gICAgIHByb3RlY3Rpb24g cGF0aHMuIEFwcGx5aW5nIDE6MSBwcm90ZWN0aW9uIHJlcXVpcmVzIHRoYXQgdGhlIHNhbWUNCj4N Cj4gICAgIHJlc291cmNlcyBhcmUgYWxsb2NhdGVkLCBidXQgYWxsb3dzIHRoZSByZXNvdXJjZXMg b2YgdGhlIHByb3RlY3Rpb24NCj4NCj4gICAgIHBhdGggdG8gYmUgdXRpbGl6ZWQgZm9yIHByZS1l bXB0aWJsZSBleHRyYSB0cmFmZmljLg0KPg0KPg0KPg0KPiAgICAgKDIpIFRoZSB3aG9sZSB0ZXh0 IGluIFNlY3Rpb24gMy4xIHdpbGwgYmUgcmVwbGFjZWQgd2l0aDoNCj4NCj4gICAgIFtSRkM2Mzcy XSwgYmFzZWQgdXBvbiB0aGUgZGVmaW5pdGlvbnMgaW4gW1JGQzQ0MjddLCBkaWZmZXJlbnRpYXRl cw0KPiAgICAgYmV0d2VlbiAicHJvdGVjdGlvbiIgYW5kICJyZXN0b3JhdGlvbiIgZGVwZW5kZW50 IHVwb24gdGhlIGR5bmFtaXNtDQo+ICAgICBvZiB0aGUgcmVzb3VyY2UgYWxsb2NhdGlvbi4gVGhl IHNhbWUgZGlzdGluY3Rpb24gaXMgdXNlZCBpbg0KPiAgICAgW1JGQzM5NDVdLCBbUkZDNDQyNl0s IGFuZCBbUkZDNDQyOF0uIFRoaXMgZG9jdW1lbnQgYWxzbyB1c2VzIHRoZQ0KPiAgICAgc2FtZSBk aXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGFzIHN0YXRlZCBp bg0KPiAgICAgW1JGQzYzNzJdLg0KPg0KPg0KPg0KPiAgICAgKDMpIEluIHBhZ2UgNiwNCj4NCj4g ICAgIE9MRDoNCj4NCj4gICAgIFRoZSB1c2Ugb2YgcHJlZW1wdGlvbiBpbiB0aGUgbmV0d29yayBp cyB0eXBpY2FsbHkgYSBidXNpbmVzcyBvcg0KPg0KPiAgICAgcG9saWN5IGRlY2lzaW9uIHN1Y2gg dGhhdCB3aGVuIHByb3RlY3Rpb24gcmVzb3VyY2VzIGFyZSBjb250ZW5kZWQsDQo+DQo+ICAgICBw cmlvcml0eSBjYW4gYmUgYXBwbGllZCB0byBkZXRlcm1pbmUgdG8gd2hpY2ggcGFydGllcyB0aGUg cHJvdGVjdGlvbg0KPg0KPiAgICAgcmVzb3VyY2VzIGFyZSBjb21taXR0ZWQuDQo+DQo+ICAgICBO RVc6DQo+DQo+ICAgICBUaGUgdXNlIG9mIHByZWVtcHRpb24gaW4gdGhlIG5ldHdvcmsgaXMgdHlw aWNhbGx5IGEgYnVzaW5lc3Mgb3INCj4NCj4gICAgIHBvbGljeSBkZWNpc2lvbiBzdWNoIHRoYXQg d2hlbiBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgY29udGVuZGVkLA0KPg0KPiAgICAgcHJpb3Jp dHkgY2FuIGJlIGFwcGxpZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIHBhcnRpZXMgdXRpbGl6ZSB0aGUN Cj4gICAgIHByb3RlY3Rpb24NCj4NCj4gICAgIHJlc291cmNlcy4NCj4NCj4NCj4NCj4gICAgICg0 KSBQYWdlIDcsIHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICB0 aGUgcmVzb3VyY2VzIGZvciB0aGUgcHJvdGVjdGlvbiBwYXRoIGFyZSBmdWxseSBjb21taXR0ZWQs DQo+DQo+ICAgICBORVcNCj4NCj4gICAgIHRoZSByZXNvdXJjZXMgZm9yIHRoZSBwcm90ZWN0aW9u IHBhdGggYXJlIGZ1bGx5IGRlZGljYXRlZCwNCj4NCj4NCj4NCj4gICAgIE9MRDoNCj4NCj4gICAg IHJlc291cmNlcyBtYXkgYmUgcGxhbm5lZCBidXQgd291bGQgbm90IGJlIGNvbW1pdHRlZCB1bnRp bCChpg0KPg0KPiAgICAgTkVXOg0KPg0KPiAgICAgcmVzb3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1 dCB3b3VsZCBub3QgYmUgdXRpbGl6ZWQgdW50aWwgoaYNCj4NCj4NCj4NCj4gICAgICg1KSBJbiB0 aGUgc2Vjb25kIHBhcmFncmFwaCBpbiBwYWdlIDcsDQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICAi SGFyZCBQcmVlbXB0aW9uIiByZXF1aXJlcyB0aGUgcHJvZ3JhbW1pbmcgb2Ygc2VsZWN0b3JzIGF0 IHRoZQ0KPiAgICAgaW5ncmVzcyBvZiBlYWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkgd2hp Y2ggYmFja3VwIHBhdGggaGFzDQo+ICAgICB0aGUgaGlnaGVzdCBwcmlvcml0eSB3aGVuIGNvbW1p dHRpbmcgcHJvdGVjdGlvbiByZXNvdXJjZXMsIHRoZQ0KPiAgICAgb3RoZXJzIGJlaW5nIHByZWVt cHRlZC4NCj4NCj4gICAgIE5FVw0KPg0KPiAgICAgIkhhcmQgUHJlZW1wdGlvbiIgcmVxdWlyZXMg dGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUNCj4gICAgIGluZ3Jlc3Mgb2YgZWFj aCBzaGFyZWQgc2VnbWVudCB0byBzcGVjaWZ5IHRoZSBwcmlvcml0aWVzIG9mIGJhY2t1cA0KPiAg ICAgcGF0aHMsIHNvIHRoYXQgdHJhZmZpYyBvZiBsb3dlciBwcmlvcml0eSBwYXRocyBjYW4gYmUg cHJlZW1wdGVkLg0KPg0KPg0KPg0KPiAgICAgKDYpIFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgU2Vj dGlvbiA0LjE6DQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICChpiBhbmQgY29tbWl0IHRoZSBhc3Nv Y2lhdGVkIHJlc291cmNlcy4gVGhlIGNvbW1pdG1lbnQgb2YgcmVzb3VyY2VzDQo+DQo+ICAgICBp cyBkZXBlbmRlbnQgdXBvbiChpg0KPg0KPiAgICAgTkVXOg0KPg0KPiAgICAgoaYgYW5kIGNvb3Jk aW5hdGUgdGhlIHV0aWxpemF0aW9uIG9mIHRoZSBhc3NvY2lhdGVkIHNoYXJlZCByZXNvdXJjZXMu DQo+DQo+ICAgICBUaGUgcmVzb3VyY2UgdXRpbGl6YXRpb24gY29vcmRpbmF0aW9uIGlzIGRlcGVu ZGVudCB1cG9uIKGmDQo+DQo+DQo+DQo+ICAgICAoNykgVGhlIHNlY29uZCBwYXJhZ3JhcGggb2Yg U2VjdGlvbiA0LjE6DQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICBXaGVuIHRoZSByZXNlcnZlZCBy ZXNvdXJjZXMgb2YgdGhlIHNoYXJlZCBzZWdtZW50cyBhcmUgY29tbWl0dGVkIHRvIGENCj4NCj4g ICAgIHBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVyZSBtYXkgbm90IGJlIHN1ZmZpY2ll bnQgcmVzb3VyY2VzDQo+DQo+ICAgICBhdmFpbGFibGUgZm9yIGFuIGFkZGl0aW9uYWwgcHJvdGVj dGlvbiBwYXRoLiBUaGlzIHRoZW4gaW1wbGllcyB0aGF0DQo+DQo+ICAgICBpZiBhbm90aGVyIHdv cmtpbmcgcGF0aCBvZiB0aGUgU01QIGRvbWFpbiB0cmlnZ2VycyBhIHByb3RlY3Rpb24NCj4NCj4g ICAgIHN3aXRjaCwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcyBtYXkgZmFpbC4gSW4g b3JkZXIgdG8NCj4NCj4gICAgIG9wdGltaXplIHRoZSBvcGVyYXRpb24gb2YgdGhlIGNvbW1pdG1l bnQgYW5kIHByZXBhcmluZyBmb3IgY2FzZXMgb2YNCj4NCj4gICAgIG11bHRpcGxlIHdvcmtpbmcg cGF0aHMgZmFpbGluZywgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHNoYXJlZA0KPg0KPiAgICAgcmVz b3VyY2VzIGFyZSBiZSBjb29yZGluYXRlZCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZyBw YXRocyBpbg0KPg0KPiAgICAgdGhlIFNNUCBuZXR3b3JrLg0KPg0KPiAgICAgTkVXOg0KPg0KPiAg ICAgV2hlbiB0aGUgcmVzZXJ2ZWQgcmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgYXJl IHV0aWxpemVkIGJ5IGENCj4NCj4gICAgIHBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVy ZSBtYXkgbm90IGJlIHN1ZmZpY2llbnQgcmVzb3VyY2VzDQo+DQo+ICAgICBhdmFpbGFibGUgZm9y IGFuIGFkZGl0aW9uYWwgcHJvdGVjdGlvbiBwYXRoLiBUaGlzIHRoZW4gaW1wbGllcyB0aGF0DQo+ DQo+ICAgICBpZiBhbm90aGVyIHdvcmtpbmcgcGF0aCBvZiB0aGUgU01QIGRvbWFpbiB0cmlnZ2Vy cyBhIHByb3RlY3Rpb24NCj4NCj4gICAgIHN3aXRjaCwgdGhlIHJlc291cmNlIHV0aWxpemF0aW9u IGNvb3JkaW5hdGlvbiBtYXkgZmFpbC4gVGhlDQo+ICAgICBkaWZmZXJlbnQgd29ya2luZyBwYXRo cyBpbg0KPg0KPiAgICAgdGhlIFNNUCBuZXR3b3JrIGFyZSBpbnZvbHZlZCBpbiB0aGUgcmVzb3Vy Y2UgdXRpbGl6YXRpb24NCj4gICAgIGNvb3JkaW5hdGlvbi4NCj4NCj4gICAgIC4NCj4NCj4NCj4N Cj4gICAgICg4KSBTZWN0aW9uIDUuMSwNCj4NCj4gICAgIE9MRDoNCj4NCj4gICAgIKGmIGFuZCBj b21taXQgdGhlIGFzc29jaWF0ZWQgcmVzb3VyY2VzLg0KPg0KPiAgICAgTkVXDQo+DQo+ICAgICCh piBhbmQgY29vcmRpbmF0ZSB0aGUgdXRpbGl6YXRpb24gb2YgdGhlIGFzc29jaWF0ZWQgc2hhcmVk IHJlc291cmNlcy4NCj4NCj4NCj4NCj4gICAgICg5KSBJbiBTZWN0aW9uIDUuMSwNCj4NCj4gICAg IE9MRDoNCj4NCj4gICAgIEluIHRoZSBjYXNlIG9mIG11bHRpcGxlIHdvcmtpbmcgcGF0aHMgZmFp bGluZywgdGhlIGNvbW1pdG1lbnQgb2YgdGhlDQo+DQo+ICAgICBzaGFyZWQgcmVzb3VyY2VzIFNI QUxMIGJlIGNvb3JkaW5hdGVkIGJldHdlZW4gdGhlIGRpZmZlcmVudCB3b3JraW5nDQo+DQo+ICAg ICBwYXRocyBpbiB0aGUgU01QIG5ldHdvcmsuDQo+DQo+ICAgICBORVc6DQo+DQo+ICAgICBJbiB0 aGUgY2FzZSBvZiBtdWx0aXBsZSB3b3JraW5nIHBhdGhzIGZhaWxpbmcsIHRoZSBzaGFyZWQgcmVz b3VyY2UNCj4gICAgIHV0aWxpemF0aW9uDQo+DQo+ICAgICBjb29yZGluYXRpb24gU0hBTEwgYmUg YmV0d2VlbiB0aGUgZGlmZmVyZW50IHdvcmtpbmcNCj4NCj4gICAgIHBhdGhzIGluIHRoZSBTTVAg bmV0d29yay4NCj4NCj4NCj4NCj4gICAgICgxMCkgU2VjdGlvbiA1LjEuMS4NCj4NCj4gICAgIE9M RDoNCj4NCj4gICAgIKGmIGJlY2F1c2UgdGhleSBhbHJlYWR5IGhhdmUgYmVlbiBjb21taXR0ZWQg dG8gdGhlIHByb3RlY3Rpb24gb2YsDQo+ICAgICBmb3IgZXhhbXBsZSwgYSBoaWdoZXIgcHJpb3Jp dHkgd29ya2luZyBwYXRoLg0KPg0KPiAgICAgTkVXOg0KPg0KPiAgICAgoaYgYmVjYXVzZSB0aGV5 IGFscmVhZHkgaGF2ZSBiZWVuIHV0aWxpemVkIGZvciB0aGUgcHJvdGVjdGlvbiBvZiwNCj4gICAg IGZvciBleGFtcGxlLCBhIGhpZ2hlciBwcmlvcml0eSB3b3JraW5nIHBhdGguDQo+DQo+DQo+DQo+ ICAgICAoMTEpIFNlY3Rpb24gNS4yLCB0aGUgc2Vjb25kIGJ1bGxldCBpdGVtOg0KPg0KPiAgICAg T0xEOg0KPg0KPiAgICAgUmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2VnbWVudHMgU0hBTEwgYmUg Y29tbWl0dGVkIHRvIHRoZQ0KPg0KPiAgICAgcHJvdGVjdGlvbiBwYXRoIKGmDQo+DQo+ICAgICBO RVc6DQo+DQo+ICAgICBSZXNvdXJjZXMgb2YgdGhlIHNoYXJlZCBzZWdtZW50cyBTSEFMTCBiZSB1 dGlsaXplZCBieSB0aGUNCj4NCj4gICAgIHByb3RlY3Rpb24gcGF0aCChpg0KPg0KPg0KPg0KPiAg ICAgKDEyKSBTZWN0aW9uIDUuMiwgdGhlIHRoaXJkIGJ1bGxldCBpdGVtOg0KPg0KPiAgICAgT0xE Og0KPg0KPiAgICAgSWYgbXVsdGlwbGUgcHJvdGVjdGlvbiBwYXRocyBvZiBlcXVhbCBwcmlvcml0 eSBhcmUgcmVxdWVzdGluZw0KPg0KPiAgICAgYWxsb2NhdGlvbiBvZiB0aGUgc2hhcmVkIHJlc291 cmNlcywgdGhlIHJlc291cmNlcyBTSE9VTEQgYmUNCj4NCj4gICAgIGNvbW1pdHRlZCBvbiBhIGZp cnN0IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzLg0KPg0KPiAgICAgTkVXOg0KPg0KPiAgICAgSWYg bXVsdGlwbGUgcHJvdGVjdGlvbiBwYXRocyBvZiBlcXVhbCBwcmlvcml0eSBhcmUgcmVxdWVzdGlu Zw0KPg0KPiAgICAgdGhlIHNoYXJlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxEIGJl DQo+DQo+ICAgICBhc3NpZ25lZCBvbiBhIGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lzLg0K Pg0KPg0KPg0KPiAgICAgKDEzKSBTZWN0aW9uIDUuMiwgdGhlIGZvdXJ0aCBidWxsZXQgaXRlbToN Cj4NCj4gICAgIE9MRDoNCj4NCj4gICAgIElmIHRoZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUg Y29tbWl0dGVkIHRvIGEgcHJvdGVjdGlvbiBwYXRoLA0KPg0KPiAgICAgd2hvc2Ugd29ya2luZyBw YXRoIGhhcyBhIGxvd2VyIHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yDQo+DQo+ICAg ICB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGggU0hBTEwgYmUgY29tbWl0dGVkIHRvIHRoZSBoaWdo ZXIgcHJpb3JpdHkNCj4NCj4gICAgIHBhdGguDQo+DQo+ICAgICBORVc6DQo+DQo+ICAgICBJZiB0 aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIHV0aWxpemVkIGJ5IGEgcHJvdGVjdGlvbiBwYXRo LA0KPg0KPiAgICAgd2hvc2Ugd29ya2luZyBwYXRoIGhhcyBhIGxvd2VyIHByaW9yaXR5LCByZXNv dXJjZXMgcmVxdWlyZWQgZm9yDQo+DQo+ICAgICB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGggU0hB TEwgYmUgYXNzaWduZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eQ0KPg0KPiAgICAgcGF0aC4NCj4N Cj4NCj4NCj4NCj4NCj4gICAgICgxNCkgU2VjdGlvbiA1LjIuIHRoZSBzZXZlbnRoIGJ1bGxldCBp dGVtDQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICBPbmNlIHJlc291cmNlcyBvZiBzaGFyZWQgc2Vn bWVudHMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBjb21taXR0ZWQNCj4NCj4gICAgIHRvIGEgcHJv dGVjdGlvbiBwYXRoLCChpg0KPg0KPiAgICAgTkVXOg0KPg0KPiAgICAgT25jZSByZXNvdXJjZXMg b2Ygc2hhcmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkgdXRpbGl6ZWQNCj4NCj4g ICAgIGJ5IGEgcHJvdGVjdGlvbiBwYXRoLCChpg0KPg0KPg0KPg0KPiAgICAgKDE1KSBTZWN0aW9u IDUuMywgdGhlIGZpcnN0IHBhcmFncmFwaCwNCj4NCj4gICAgIE9MRDoNCj4NCj4gICAgIKGmIHJl cXVlc3QgdGhlIGNvbW1pdG1lbnQgb2YgcHJvdGVjdGlvbiByZXNvdXJjZXMuIElmIHRoZSBuZWNl c3NhcnkNCj4NCj4gICAgIHNoYXJlZCByZXNvdXJjZXMgYXJlIHVuYXZhaWxhYmxlIHRvIGJlIGNv bW1pdHRlZCB0byB0aGUgcHJvdGVjdGlvbg0KPg0KPiAgICAgcGF0aCwgdGhlIGVuZHBvaW50cyCh pg0KPg0KPg0KPg0KPiAgICAgTkVXOg0KPg0KPiAgICAgoaYgcmVxdWVzdCB0aGUgY29vcmRpbmF0 aW9uIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2UgdXRpbGl6YXRpb24uIElmDQo+ICAgICB0aGUgbmVj ZXNzYXJ5DQo+DQo+ICAgICBzaGFyZWQgcmVzb3VyY2VzIGFyZSB1bmF2YWlsYWJsZSwgdGhlIGVu ZHBvaW50cyChpg0KPg0KPg0KPg0KPiAgICAgKDE2KSBTZWN0aW9uIDUuMywgdGhlIHNlY29uZCBw YXJhZ3JhcGgsDQo+DQo+ICAgICBPTEQ6DQo+DQo+ICAgICBTaW1pbGFybHksIGlmIHByZWVtcHRp b24gaXMgc3VwcG9ydGVkIGFuZCB0aGUgcmVzb3VyY2VzIGN1cnJlbnRseQ0KPg0KPiAgICAgY29t bWl0dGVkIGZvciBhIHBhcnRpY3VsYXIgd29ya2luZyBwYXRoIGFyZSChpg0KPg0KPiAgICAgTkVX Og0KPg0KPiAgICAgU2ltaWxhcmx5LCBpZiBwcmVlbXB0aW9uIGlzIHN1cHBvcnRlZCBhbmQgdGhl IHJlc291cmNlcyBjdXJyZW50bHkNCj4NCj4gICAgIHV0aWxpemVkIGJ5IGEgcGFydGljdWxhciB3 b3JraW5nIHBhdGggYXJlIKGmDQo+DQo+DQo+DQo+DQo+DQo+ICAgICAtIFNlY3Rpb24gMiwgMXN0 IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkNCj4gICAgIGRl ZmluZXMNCj4gICAgIHRoZSBzY29wZS9wdXJwb3NlIG9mIHRoZSBkb2N1bWVudCwgaS5lLiwgImNs YXJpZmllcyB0aGUgaW5zdHJ1Y3Rpb25zDQo+ICAgICB0byBwcm90b2NvbCBkZXNpZ25lcnMgcHJv ZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhlDQo+ICAgICByZXF1aXJlbWVudHMgc2V0 IG91dCBpbiB0aGlzIGRvY3VtZW50LiIgQXMgc3VjaCwgSSdkIHJlcGVhdCB0aGlzIGluDQo+ICAg ICB0aGUgYWJzdHJhY3QgYW5kIG1vdmUgaXQgdG8gYSBtb3JlIHByb25vdW5jZWQgcGxhY2UgaW4g c2VjdGlvbiAxIChvcg0KPiAgICAgMykuDQo+DQo+ICAgICBbQXV0aG9yc10gV2UgY2FuIGFkZCB0 aGUgZm9sbG93aW5nIHBhcmFncmFwaCBhdCB0aGUgZW5kIG9mIFNlY3Rpb24gMToNCj4NCj4gICAg IKGwVGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBjbGFyaWZ5IHRoZSBpbnN0cnVjdGlvbnMg dG8gcHJvdG9jb2wNCj4gICAgIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0 aXNmeSB0aGUgcmVxdWlyZW1lbnRzIHNldA0KPiAgICAgb3V0IGluIHRoaXMgZG9jdW1lbnQuobEN Cj4NCj4NCj4NCj4NCj4gICAgIC0gR2VuZXJhbCBjb21tZW50OiBmYXRlLXNoYXJpbmcgZm9yIGNv LXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUA0KPiAgICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJv dXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD8NCj4gICAgIEknZCBh c3N1bWVkIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCBjb29yZGluYXRpb24gcHJvdG9jb2wgd291bGQg YmUNCj4gICAgIHJlcXVpcmVkIHRvIHRyaWdnZXIgYSBzd2l0Y2hvdmVyIG9mIHRoZSByZXZlcnNl IExTUCBpbiB0aGUgY28tcm91dGVkDQo+ICAgICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4g dGhlIGRvY3VtZW50Lg0KPg0KPiAgICAgW0F1dGhvcnNdIEZhdGUtc2hhcmluZyBpcyBub3QgcmVx dWlyZWQgYnkgdGhpcyBkb2N1bWVudC4gRXZlbiBpbg0KPiAgICAgdGhlIFBTQyBsaW5lYXIgcHJv dGVjdGlvbiBzd2l0Y2hpbmcsIHN1Y2ggYXMgUkZDIDYzNzggKFBTQykgYW5kDQo+ICAgICBSRkMg NzI3MSAoUFNDIGluIEFQUyBtb2RlKSwgZmF0ZS1zaGFyaW5nIGlzIG5vdCByZXF1aXJlZCBhcw0K PiAgICAgdW5pZGlyZWN0aW9uYWwgc3dpdGNoaW5nIGlzIGFsbG93ZWQuIFRoaXMgZG9jdW1lbnQg ZG9lcyBub3QgaW1wb3NlDQo+ICAgICBhbnkgcmVzdHJpY3Rpb24gb24gY28tcm91dGluZywgZWl0 aGVyLg0KPg0KPg0KPg0KPg0KPiAgICAgLSBJbiBzZWN0aW9uIDQgYW5kIDUuMiB5b3UgcmVmZXJl bmNlIDU3MTIgYW5kIDMyMDkgYXMgZGVmaW5pbmcNCj4gICAgIHByZWVtcHRpb24gdGVybWlub2xv Z3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+ICAgICByZWZlcmVu Y2UgaGVyZSBhcyBpdCBkZWZpbmVzIGJvdGggaW4gdGhlIGNvbnRleHQgb2Ygc3Vydml2YWJpbGl0 eSBhbmQNCj4gICAgIGluIGRlcGVuZGVudCBvZiBjb250cm9sIHBsYW5lLg0KPg0KPiAgICAgW0F1 dGhvcnNdIE9uZSBjb25jZXJuIGlzIHRoYXQgUkZDIDYzNzIgZGVzY3JpYmVzIGJvdGggc29mdCBh bmQNCj4gICAgIGhhcmQgcHJlZW1wdGlvbnMgaW4gdGhlIGNvbnRleHQgb2YgZXh0cmEgdHJhZmZp Yywgd2hpY2ggaXMgbm90DQo+ICAgICBleGFjdGx5IHRoZSBjYXNlIGZvciBTTVAuDQo+DQo+DQo+ DQo+DQo+ICAgICAtIEluIHNlY3Rpb24gNC4yIHlvdSBzYXkgIlRoZXJlZm9yZSwgaXQgaXMgc3Vn Z2VzdGVkIHRoYXQgdGhpcyBiZQ0KPiAgICAgY2FycmllZCBvdXQgdW5kZXIgdGhlIGNvbnRyb2wg b2YgYSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgc2ltaWxhciB0bw0KPiAgICAgR01QTFMgW1JGQzM5 NDVdLiIgcGVyaGFwcyB5b3UgbWVhbiAiYmFzZWQgb24gR01QTFMiPyBJZiBzbywgZ3JlYXQsDQo+ ICAgICBwbGVhc2UgbWFrZSB0aGUgY29ycmVjdGlvbi4gSWYgbm90LCBJIHRoaW5rIHRoZSBkZWJh dGUgb2Ygd2hpY2gNCj4gICAgIGNvbnRyb2wgcHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBp cyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzDQo+ICAgICBkb2N1bWVudC4NCj4NCj4gICAg IFtBdXRob3JzXSBZZXMsIHdlIHdpbGwgbWFrZSB0aGUgY29ycmVjdGlvbi4NCj4NCj4NCj4NCj4N Cj4gICAgIC0gU2VjdGlvbiA1LjEsIHBhcmFncmFwaCAxLiBXaHkgYXJlIHlvdSB1c2luZyAiU0hP VUxEIE5PVCIgaGVyZT8gSWYNCj4gICAgIHJlZmVycmluZyB0byBzb2x1dGlvbnMgY29uZm9ybWFu dCB3aXRoIHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlc2UgYXJlDQo+ICAgICBpbmZvcm1hdGl2ZSBz dGF0ZW1lbnRzLCAiYW5kIGEgbm9uLWNvbnRyb2wgcGxhbmUgYmFzZWQgU01QIHN3aXRjaG92ZXIN Cj4gICAgIG1lY2hhbmlzbSBpcyB1c2VkLCB0aGUgY29udHJvbCBwbGFuZSBTSEFMTCBOT1QgLi4u Ii4gSWYgcmVmZXJyaW5nIHRvDQo+ICAgICBhbiBvcGVyYXRvcidzL3VzZXIncyBjaG9pY2Ugb2Yg cHJvdGVjdGlvbiBtZWNoYW5pc20sIEkgdGhpbmsgdGhlIG1vc3QNCj4gICAgIHlvdSBjYW4gc2F5 IGlzIE1BWS4NCj4NCj4gICAgIFtBdXRob3JzXSBUaGUgZmlyc3QgY2FzZSBpcyB0aGUgb25lIHdl IGFyZSBhaW1pbmcgYXQuIFdlIHdpbGwgdXNlDQo+ICAgICBTSEFMTCBOT1QuDQo+DQo+DQo+DQo+ DQo+ICAgICAtIFNlY3Rpb24gNS4yLiAiVGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmlu ZWQgaW4gc2NvcGUgb2YgYW4gU01QDQo+ICAgICBkb21haW4uIiBBcyB0aGlzIGlzIGEgcmVxdWly ZW1lbnQsIHdoYXQgeW91IG1lYW4gYnkgInRpZS1icmVha2luZw0KPiAgICAgcnVsZXMiIHNob3Vs ZCBiZSBkZWZpbmVkIGRpcmVjdGx5IG9yIGJ5IHJlZmVyZW5jZS4NCj4NCj4gICAgIFtBdXRob3Jz XSBUaGUgc2VudGVuY2UgY2FuIGJlIHJld3JpdHRlbiBhczoNCj4NCj4gICAgIE9MRDoNCj4NCj4g ICAgIFRpZS1icmVha2luZyBydWxlcyBTSEFMTCBiZSBkZWZpbmVkIGluIHNjb3BlIG9mIGFuIFNN UCBkb21haW4uDQo+DQo+ICAgICBORVc6DQo+DQo+ICAgICBJbiBvcmRlciB0byBjb3ZlciB0aGUg c2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZpcnN0IHNlcnZlZA0KPiAgICAgcHJpbmNp cGxlIGNhbm5vdCByZXNvbHZlIHRoZSBjb250ZW50aW9uIGFtb25nIG11bHRpcGxlIGVxdWFsDQo+ ICAgICBwcmlvcml0eSByZXF1ZXN0cywgaS5lLiwgd2hlbiB0aGUgcmVxdWVzdHMgb2NjdXIgc2lt dWx0YW5lb3VzbHksLA0KPiAgICAgdGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQg aW4gc2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gICAgIC0gU2Vj dGlvbiA1LjMuIFJGQzYzNzIgdGFrZXMgYW4gYXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3Rp ZmljYXRpb24NCj4gICAgIGxldmVyYWdlcyB0aGUgc3RhbmRhcmQgTVBMUy1UUCBPQU0gbWVjaGFu aXNtcywgaXMgdGhlcmUgYW55IHJlYXNvbiB0bw0KPiAgICAgZG8gbW9yZSAvIG5vdCBqdXN0IGZv bGxvdyA2MzcyPw0KPg0KPiAgICAgW0F1dGhvcnNdIFdlIGNhbiBhZGQgdGhlIGZvbGxvd2luZyBz ZW50ZW5jZSBhdCB0aGUgZW5kOg0KPg0KPiAgICAgobBBcyBkZXNjcmliZWQgaW4gW1JGQzYzNzJd LCB0aGUgZXZlbnQgb2YgcHJlZW1wdGlvbiBtYXkgYmUNCj4gICAgIGRldGVjdGVkIGJ5IE9BTSBh bmQgcmVwb3J0ZWQgYXMgYSBmYXVsdCBvciBhIGRlZ3JhZGF0aW9uIG9mDQo+ICAgICB0cmFmZmlj IGRlbGl2ZXJ5LqGxDQo+DQo+DQo+ICAgICAtIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29v cmRpbmF0aW9uIHJlcXVpcmVkIG9uDQo+ICAgICBzb2Z0LXByZWVtcHRpb24gYXMNCj4gICAgIHdl bGwgKGRlcGVuZGluZyBvbiB0aGUgY3Jvc3MtY29ubmVjdHMgZXN0YWJsaXNoZWQgZHVyaW5nIExT UA0KPiAgICAgZXN0YWJsaXNobWVudCkgc28gY29vcmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBi ZSBzdXBwb3J0ZWQNCj4gICAgIGluZGVwZW5kZW50IG9mIHByZWVtcHRpb24gbW9kZS4NCj4NCj4g ICAgIFtBdXRob3JzXSBZZXMsIHdlIHdpbGwgY2hhbmdlIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGZy b20gobBTTVAgaW4NCj4gICAgIGhhcmQtcHJlZW1wdGlvbiBtb2RlIFNIT1VMRCChpqGxIHRvIKGw U01QIFNIT1VMRCChpqGxIGFuZCBtb3ZlIHRoZQ0KPiAgICAgY2hhbmdlZCBwYXJhZ3JhcGggYWJv dmUgdGhlIGZpcnN0IHBhcmFncmFwaC4NCj4NCj4NCj4NCj4NCj4gICAgIE5pdHM6DQo+DQo+ICAg ICAtIEFic3RyYWN0OiBJIGRvbid0IHJlY2FsbCB0aGUgdGVybSAiZXhlY3V0aXZlIGFjdGlvbiIg YmVpbmcgdXNlZA0KPiAgICAgaW4gYW55DQo+ICAgICBlYXJsaWVyIHJlbGF0ZWQvcmVmZXJlbmNl ZCBSRkNzLiBSYXRoZXIgdGhhbiBpbnRyb2R1Y2UgYSBuZXcgKGFuZA0KPiAgICAgdW5kZWZpbmVk KSB0ZXJtLCBwZXJoYXBzIHlvdSBjYW4gdXNlIGFuIGV4aXN0aW5nIG9uZSwgZS5nLiwNCj4gICAg ICJwcm90ZWN0aW9uIHN3aXRjaCI/DQo+DQo+ICAgICBbQXV0aG9yc10gWWVzLCB0aGUgdGVybSB3 aWxsIGJlIGNoYW5nZWQgYXMgeW91IHN1Z2dlc3RlZC4NCj4NCj4NCj4NCj4NCj4gICAgIC0gU2Vj dGlvbiAxLCBwYXJhZ3JhcGggMS4gRG8gd2UgcmVhbGx5IG5lZWQgYW5vdGhlciBkZWZpbml0aW9u IG9mDQo+ICAgICBNUExTLVRQIHRvIGRlYmF0ZT8gSSBzdWdnZXN0IGp1c3QgcmVmZXJlbmNpbmcg eW91ciBmYXZvcml0ZSBNUExTLVRQDQo+ICAgICBkb2N1bWVudChzKSBhbmQgZHJvcHBpbmcgdGhl IGZpcnN0IGZvdXIgc2VudGVuY2VzLg0KPg0KPiAgICAgVGhlIGxhc3Qgc2VudGVuY2UgYWxzbyBt YWtlcyBhIHN1YmplY3RpdmUgc3RhdGVtZW50LiBXaGV0aGVyIGl0IGlzDQo+ICAgICBjcml0aWNh bCBvciBubyBpcyB1bm5lY2Vzc2FyeS4gWW91IGNhbiBqdXN0IHNheSBzb21ldGhpbmcgbGlrZSA2 MzcyDQo+ICAgICBwcm92aWRlcyBhIHN1cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGZvciBNUExTLVRQ IGFuZCBpcyB0aGUgZm91bmRhdGlvbg0KPiAgICAgZm9yIHRoaXMgZG9jdW1lbnQuDQo+DQo+ICAg ICBbQXV0aG9yc10gVGhlIHByb3Bvc2VkIHRleHQgZm9yIHRoZSBwYXJhZ3JhcGggMSBpczoNCj4N Cj4gICAgIKGwVGhlIE1QTFMgVHJhbnNwb3J0IFByb2ZpbGUgKE1QTFMtVFApIGlzIGRlc2NyaWJl ZCBpbiBbUkZDNTkyMV0sDQo+DQo+ICAgICBhbmQgW1JGQzYzNzJdIHByb3ZpZGVzIGEgc3Vydml2 YWJpbGl0eSBmcmFtZXdvcmsgZm9yIE1QTFMtVFANCj4NCj4gICAgIGFuZCBpcyB0aGUgZm91bmRh dGlvbiBmb3IgdGhpcyBkb2N1bWVudC6hsQ0KPg0KPg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDEs IHBhcmFncmFwaCAzLiBJc24ndCB0aGUgcmlnaHQgcmVmZXJlbmNlIDQ0Mjcgbm90IDQ0Mjg/DQo+ ICAgICBBbHNvIGRyb3AgdGhlIHdvcmQgbGluZWFyLCBhcyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBx dWFsaWZpZXIgYW5kDQo+ICAgICA0NDI3LzQ0MjggZG9uJ3QgdXNlIGl0Lg0KPg0KPiAgICAgW0F1 dGhvcnNdIE9LLg0KPg0KPg0KPg0KPg0KPg0KPg0KPiAgICAgLSBTZWN0aW9ucyAzIChhbmQgdG8g YSBsZXNzZXIgZGVncmVlIHNlY3Rpb24gMikgYXJlIHJlYWxseQ0KPiAgICAgaW50cm9kdWN0b3J5 DQo+ICAgICB0ZXh0LiBJJ20gdW5zdXJlIGFzIHRvIHdoeSB0aGV5IGFyZW4ndCBwYXJ0IG9mIHNl Y3Rpb24gMS4NCj4NCj4gICAgIFtBdXRob3JzXSBTZWN0aW9uIDMgd2FzIGludGVuZGVkIHRvIHBy ZXNlbnQgYSByZWZlcmVuY2UgbW9kZWwgZm9yDQo+ICAgICBTTVAuIFNvbWUgdGV4dCBvZiBTZWN0 aW9uIDIgaXMgcmVwZWF0ZWQgaW4gU2VjdGlvbiAxIGFzIHlvdQ0KPiAgICAgc3VnZ2VzdGVkIGVh cmxpZXIuDQo+DQo+DQo+DQo+DQo+DQo+DQo+ICAgICAtIFNlY3Rpb24gMy4yIHNob3VsZCBoYXZl IGEgcmVmZXJlbmNlIGZvciAiZXhpc3RpbmcgY29udHJvbCBwbGFuZQ0KPiAgICAgc29sdXRpb25z IGZvciBTTVAgd2l0aGluIE1QTFMiLg0KPg0KPiAgICAgW0F1dGhvcnNdIFtSRkM0MjA2XSB3aWxs IGJlIGFkZGVkIGFzIGEgcmVmZXJlbmNlDQo+DQo+DQo+ICAgICAtIFNlY3Rpb24gMy4yIGFnYWlu IHVzZXMgdGhlICJleGVjdXRpdmUgYWN0aW9uIiB0ZXJtLg0KPg0KPiAgICAgW0F1dGhvcnNdIE9L LCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQuDQo+DQo+DQo+DQo+DQo+ICAgICAtIFNlY3Rpb24g NC4xLiBZb3Ugc2F5ICJ0d28gb3BlcmF0aW9ucyBzaW11bHRhbmVvdXNseSIuIERvIHlvdSByZWFs bHkNCj4gICAgIG1lYW4gInNpbXVsdGFuZW91c2x5IiBvciBtZXJlbHkgdGhhdCB0aGV5IG11c3Qg Ym90aCBvY2N1ciBmb3INCj4gICAgIHByb3RlY3Rpb24gdG8gYmUgcHJvdmlkZWQ/IChTYW1lIGNv bW1lbnQgaW4gc2VjdGlvbiA1LjEuDQo+DQo+ICAgICBbQXV0aG9yc10gQm90aCBhY3Rpb25zIHNo b3VsZCBvY2N1ciBhdCB0aGUgc2FtZSB0aW1lLCBvciBhcw0KPiAgICAgY2xvc2VseSBhcyBwb3Nz aWJsZSB0byBwcm92aWRlIGZhc3QgcHJvdGVjdGlvbi4NCj4NCj4NCj4NCj4NCj4gICAgIC0gU2Vj dGlvbiA1LjIuIEkgc3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0ZWQNCj4g ICAgIHJlcXVpcmVtZW50cw0KPiAgICAgbGlzdC4NCj4NCj4gICAgIFtBdXRob3JzXSBPSywgd2Ug d2lsbCB1c2UgbnVtYmVycy4NCj4NCj4NCj4NCj4NCj4gICAgIC0gU2VjdGlvbiA1LjI6IEZpcnN0 IHBhcmFncmFwaCBhbmQgZm9ydGggYnVsbGV0IGxhc3Qgc2VudGVuY2UuIFRoZXNlDQo+ICAgICBi b3RoIGJhc2ljYWxseSBjb3ZlciB0aGUgc2FtZSB0b3BpYyAocHJlZW1wdGlvbikgYW5kIGFjdHVh bGx5IHNheQ0KPiAgICAgc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5ncy4gSSBzdWdnZXN0IGNvbWJp bmUgaW50byBhIHNpbmdsZQ0KPiAgICAgcmVxdWlyZW1lbnQgdG8gZW5zdXJlIGNvbnNpc3RlbmN5 IGFuZCBmdWxsIGNvdmVyYWdlIG9mIHRoZSB0b3BpYy4NCj4NCj4gICAgIFtBdXRob3JzXSBUaGUg Zmlyc3QgcGFyYWdyYXBoIGlzIGZvciBzb2Z0LXByZWVtcHRpb24sIHdoaWxlIHRoZQ0KPiAgICAg Zm91cnRoIGJ1bGxldCBiZWxvbmdzIHRvIHRoZSByZXF1aXJlbWVudHMgb2YgaGFyZC1wcmVlbXB0 aW9uLg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRoaXMgcmVs YXRlIHRvIHNlY3Rpb24gNS41PyBTaG91bGRuJ3QNCj4gICAgIHRoZSB0b3BpY3MgcmVsYXRlZCB0 byB0aW1pbmcgYmUgY29uc29saWRhdGVkPw0KPg0KPiAgICAgW0F1dGhvcnNdIFllcywgcmVxIDUg Y2FuIGJlIG1vdmVkIHRvIFNlY3Rpb24gNS41Lg0KPg0KPg0KPg0KPg0KPiAgICAgLSBTZWN0aW9u IDUuMjogcmVxdWlyZW1lbnQgNiBzZWVtcyB0byBiZSBhIHN1YnNldCBvZiA3LCBzbyBpdA0KPiAg ICAgc2hvdWxkIGJlDQo+ICAgICBkcm9wcGVkLg0KPg0KPiAgICAgW0F1dGhvcnNdIFllcywgaXQg d2lsbCBiZSBkZWxldGVkLg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxdWlyZW1lbnQg OC4gSXNuJ3QgdGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCj4gICAgIGp1c3QgdGhp cyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1YikgcmVxdWlyZW1lbnQ/DQo+DQo+ICAgICBbQXV0 aG9yc10gUmVxLiA5IHdpbGwgYmUgZGVsZXRlZCBhcyBpdCBzZWVtcyB0byByZXF1aXJlIGNvbnRy b2wNCj4gICAgIHBsYW5lIHN1cHBvcnRzLg0KPg0KPg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMy4g cy9NQVkvd2lsbA0KPg0KPiAgICAgW0F1dGhvcnNdIE9LLg0KPg0KPg0KPg0KPg0KPiAgICAgLSBz ZWN0aW9uIDUuNDogIiBXaGVuIHRoZSB3b3JraW5nIHBhdGggZGV0ZWN0cy4uIiBkZXRlY3Rpb24g aXMgYnkgdGhlDQo+ICAgICBub2RlIG5vdCB0aGUgcGF0aC4NCj4NCj4gICAgIFtBdXRob3JzXSBZ ZXMuIFdlIHdpbGwgc2ltcGx5IHNheSB0aGF0IKGwV2hlbiB0aGUgY29uZGl0aW9uIHRoYXQNCj4g ICAgIHRyaWdnZXJlZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgaXMgY2xlYXJlZCwgoaahsQ0K Pg0KPg0KPiAgICAgLSBTZWN0aW9uIDUuNCwgbGFzdCBzZW50ZW5jZS4gVGhpcyBpcyBvbmx5IHRo ZSAybmQgdGltZSB5b3UgaW1wbHkgdGhhdA0KPiAgICAgdGhlIGRvY3VtZW50IGNvdmVycyByZXF1 aXJlbWVudHMgb24gYSBuZXcgcHJvdG9jb2wuIEkgdGhpbmsgdGhpcw0KPiAgICAgcG9pbnQgaXMg Y3VycmVudGx5IHRvbyBzdWJ0bGUgaW4gdGhlIGRvY3VtZW50LiAoVGhpcyBwb2ludCB3YXMgYWxz bw0KPiAgICAgbWFkZSBhcyBhIG1pbm9yIGNvbW1lbnQuKQ0KPg0KPiAgICAgW0F1dGhvcnNdIEFz IGluIG90aGVyIHByb3RlY3Rpb24gc3dpdGNoaW5nIHRlY2hub2xvZ2llcywgdHdvIG1vZGVzDQo+ ICAgICBvZiBvcGVyYXRpb25zIChyZXZlcnRpdmUgYW5kIG5vbi1yZXZlcnRpdmUpIGFyZSByZXF1 aXJlZC4NCj4NCj4NCj4NCj4NCj4gICAgIC0gc2VjdGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBi ZSByZWZlcmVuY2VkDQo+DQo+ICAgICBbQXV0aG9yc10gV2Ugd2lsbCBhZGQgobBhcyBkZXNjcmli ZWQgaW4gW1JGQzYzNzJdobEgdG8gdGhlIGVuZHMgb2YNCj4gICAgIHR3byBwYXJhZ3JhcGhzIGZv ciBXVFIgdGltZXIgYW5kIGhvbGQtb2ZmIHRpbWVyLg0KPg0KPg0KPg0KPiAgICAgKioqKiogRW5k IG9mIENvbW1lbnQgcmVzb2x1dGlvbiAqKioqKg0KPg0KPg0KPg0KPg0KPg0KPg0KPiAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ICAgICAqurizvSC757b3IDogKiJMb3UgQmVyZ2VyIiA8bGJlcmdlckBs YWJuLm5ldA0KPiAgICAgPG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4NCj4gICAgICq6uLO9ILOv wqUgOiAqMjAxNC0wNi0yMiAwMTowMDo0OCAoICswOTowMCApDQo+ICAgICAqud60wiC757b3IDog KnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86cnRnLWFkc0B0b29scy5pZXRm Lm9yZz4gPHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86cnRnLWFkc0B0b29s cy5pZXRmLm9yZz4+DQo+ICAgICAqwvzBtiA6ICpydGctZGlyQGlldGYub3JnIDxtYWlsdG86cnRn LWRpckBpZXRmLm9yZz4NCj4gICAgIDxydGctZGlyQGlldGYub3JnIDxtYWlsdG86cnRnLWRpckBp ZXRmLm9yZz4+LA0KPiAgICAgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRv b2xzLmlldGYub3JnDQo+ICAgICA8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy1zbXAtcmVxdWlyZW1l bnRzLmFsbEB0b29scy5pZXRmLm9yZz4NCj4gICAgIDxkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVp cmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86ZHJhZnQtaWV0Zi1tcGxz LXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnPj4sDQo+ICAgICBtcGxzQGlldGYu b3JnIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4gPG1wbHNAaWV0Zi5vcmcNCj4gICAgIDxtYWlsdG86 bXBsc0BpZXRmLm9yZz4+DQo+ICAgICAqwaa48SA6ICpbbXBsc10gUnRnRGlyIHJldmlldzogZHJh ZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYudHh0DQo+DQo+DQo+ICAgICBIZWxsbywN Cj4NCj4gICAgIEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzDQo+ICAgICBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg c2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yDQo+ICAgICByb3V0aW5nLXJlbGF0ZWQgZHJh ZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHDQo+ICAgICBy ZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0 aGUgcmV2aWV3IGlzDQo+ICAgICB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcg QURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbg0KPiAgICAgYWJvdXQgdGhlDQo+ICAgICBSb3V0aW5n IERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo+ICAgICBodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyDQo+DQo+ICAgICBBbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nDQo+ICAgICBBRHMs IGl0DQo+ICAgICB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFs b25nIHdpdGggYW55IG90aGVyIElFVEYNCj4gICAgIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlv dSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbQ0KPiAgICAgdGhyb3VnaA0KPiAg ICAgZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+DQo+ICAgICBEb2N1bWVu dDogZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMtMDYudHh0DQo+ICAgICBSZXZpZXdl cjogTG91IEJlcmdlcg0KPiAgICAgUmV2aWV3IERhdGU6IEp1bmUgMjEgMjAxNA0KPiAgICAgSUVU RiBMQyBFbmQgRGF0ZTogMjAxNC0wNi0yMw0KPiAgICAgSW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1h dGlvbmFsDQo+DQo+ICAgICBTdW1tYXJ5Og0KPiAgICAgSSBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsNCj4gICAgIHNob3VsZCAobXVzdCwg YWN0dWFsbHkpIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCj4NCj4gICAgIENvbW1l bnRzOg0KPg0KPiAgICAgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCwg b3RoZXIgdGhhbiBhIGNvdXBsZSBvZg0KPiAgICAgdGVybWlub2xvZ3kgcmVsYXRlZCBpc3N1ZXMs IGVhc2lseSB1bmRlcnN0b29kLiBUaGUgZG9jdW1lbnQgZG9lcw0KPiAgICAgaGF2ZSBhIG51bWJl ciBvZiB0ZXJtaW5vbG9neSBhbmQgdGVjaG5pY2FsIGlzc3VlcyB3aGljaCBzaG91bGQgYmUNCj4g ICAgIHJlYWRpbHkgcmVzb2x2ZWQgcHJpb3IgdG8gcHVibGljYXRpb24uDQo+DQo+ICAgICBNYWpv ciBJc3N1ZXM6DQo+DQo+ICAgICBNYWpvciBpc3N1ZXMgYXJlIHRoZSB0eXBlIG9mIGNvbmNlcm5z IHRoYXQgd2lsbCByZXN1bHQgaW4gdGhlDQo+ICAgICBkb2N1bWVudCBiZWluZyBibG9ja2VkIHVu dGlsIHRoZXkgYXJlIHJlc29sdmVkLiBUaGUgUm91dGluZyBBRHMgd2lsbA0KPiAgICAgYmVjb21l IGludm9sdmVkLiBQbGVhc2UgaW5jbHVkZSBhbGwgb2YgdGhlIG1ham9yIGlzc3VlcyB5b3UgaGF2 ZQ0KPiAgICAgZm91bmQuIEdpdmUgYXMgbXVjaCBjb250ZXh0IGluZm9ybWF0aW9uIGFzIHBvc3Np YmxlIChlLmcuLCBzZWN0aW9uDQo+ICAgICBudW1iZXJzLCBwYXJhZ3JhcGggY291bnRzKS4gSWYg eW91IGZpbmQgbm8gbWFqb3IgaXNzdWVzLCBwbGVhc2UNCj4gICAgIHdyaXRlOiAiTm8gbWFqb3Ig aXNzdWVzIGZvdW5kLiINCj4NCj4gICAgIC0gTm8gbWFqb3IgaXNzdWVzIGZvdW5kLiBJbiBwYXJ0 aWN1bGFyLCBJIGV4cGVjdCBhbGwgaXNzdWVzIGNhbiBiZQ0KPiAgICAgcmVzb2x2ZWQgd2l0aG91 dCBBRCBpbnRlcnZlbnRpb24uIFNvbWUgb2YgdGhlIG1pbm9yIGlzc3VlcywgaWYgbm90DQo+ICAg ICByZXNvbHZlZCB3aWxsIGJlIGVzY2FsYXRlZCB0byB0aGUgQUQvbWFqb3IgaXNzdWUgY2F0ZWdv cnkuDQo+DQo+ICAgICBNaW5vciBJc3N1ZXM6DQo+DQo+ICAgICBNaW5vciBpc3N1ZXMgYXJlIGNv bmNlcm5zIGFib3V0IGNsYXJpdHkgb3IgdGVjaG5pY2FsIGFjY3VyYWN5IHRoYXQNCj4gICAgIHNo b3VsZCBiZSBkaXNjdXNzZWQgYW5kIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbiwgYnV0IHdo aWNoIHdvdWxkDQo+ICAgICBub3JtYWxseSBiZSByZXNvbHZlZCBiZXR3ZWVuIHRoZSBhdXRob3Jz IGFuZCB0aGUgcmV2aWV3ZXJzLiBQbGVhc2UNCj4gICAgIGluY2x1ZGUgYWxsIG9mIHRoZSBtaW5v ciBpc3N1ZXMgeW91IGhhdmUgZm91bmQuIEdpdmUgYXMgbXVjaCBjb250ZXh0DQo+ICAgICBpbmZv cm1hdGlvbiBhcyBwb3NzaWJsZSAoZS5nLiwgc2VjdGlvbiBudW1iZXJzLCBwYXJhZ3JhcGggY291 bnRzKS4NCj4gICAgIElmIHlvdSBmaW5kIG5vIG1pbm9yIGlzc3VlcywgcGxlYXNlIHdyaXRlOiAi Tm8gbWlub3IgaXNzdWVzIGZvdW5kLiINCj4NCj4gICAgIC0gRG9jdW1lbnQncyB1c2FnZSBvZiAi Y29tbWl0dGVkIiB2cyAiYWxsb2NhdGVkIiByZXNvdXJjZXM6DQo+DQo+ICAgICBJbiBzZWN0aW9u IDEgdGhlIGRvY3VtZW50IGludHJvZHVjZXMgdGhlIG5vdGlvbiB0aGF0IHRoZQ0KPiAgICAgZGlz dGluY3Rpb24gYmV0d2VlbiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBiYXNlZCBvbiB3 aGVuDQo+ICAgICByZXNvdXJjZXMgYXJlICJjb21taXR0ZWQiLiBUaGlzIGRpZmZlcmVuY2UgZnJv bSBwYXN0DQo+ICAgICBkZWZpbml0aW9uLiBSRkM0NDI3IGFuZCA2MzcyIG1ha2UgdGhlIGRpc3Rp bmN0aW9uIHRoYXQgcHJvdGVjdGlvbg0KPiAgICAgYW5kIHJlc3RvcmF0aW9uIGRpZmZlciBiYXNl ZCBvbiB3aGVuIHJlc291cmNlcyBhcmUgKmFsbG9jYXRlZCogbm90DQo+ICAgICAqY29tbWl0dGVk Ki4gVG8gcXVvdGUgUkZDIDQ0Mjc6DQo+DQo+ICAgICBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBw cm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBtYWRlIGJhc2VkDQo+ICAgICBvbiB0aGUgcmVz b3VyY2UgYWxsb2NhdGlvbiBkb25lIGR1cmluZyB0aGUgcmVjb3ZlcnkgTFNQL3NwYW4NCj4gICAg IGVzdGFibGlzaG1lbnQuIFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBv Zg0KPiAgICAgcmVzdG9yYXRpb24gaXMgbWFkZSBiYXNlZCBvbiB0aGUgbGV2ZWwgb2Ygcm91dGUg Y29tcHV0YXRpb24sDQo+ICAgICBzaWduYWxpbmcsIGFuZCByZXNvdXJjZSBhbGxvY2F0aW9uIGR1 cmluZyB0aGUgcmVzdG9yYXRpb24NCj4gICAgIExTUC9zcGFuIGVzdGFibGlzaG1lbnQuDQo+DQo+ ICAgICBUaGlzIGRpZmZlcmVuY2UgYWxzbyBsZWFkcyB0byBjb21lIGNvbmZ1c2VkIHN0YXRlbWVu dHMgaW4gdGhlDQo+ICAgICBkb2N1bWVudCBhcyB3ZWxsIGFzIGFtYmlndWl0eSBpbiB0aGUgdGV4 dCwgaS5lLiBjb25mdXNpb24gYnkgdGhlDQo+ICAgICByZWFkZXIuIFRoZSB0ZXJtICJjb21taXR0 ZWQiIGlzIG5vdCB0aWdodGx5IGRlZmluZWQgaW4gdGhpcw0KPiAgICAgZG9jdW1lbnQgKG9yIGVh cmxpZXIgd29yaykgYW5kIGlzIHVzZWQgZGlmZmVyZW50bHkgdGhhbiBob3cNCj4gICAgICJhbGxv Y2F0ZWQiIGhhcyBiZWVuIHVzZWQuIEFuIGV4YW1wbGUgb2YgdGhpcyBjYW4gYmUgZm91bmQgaW4N Cj4gICAgIFNlY3Rpb24gMy4xIHdoaWNoIHN0YXRlczoNCj4NCj4gICAgIEhvd2V2ZXIsIHRoZSBj b21taXRtZW50IG9mIHRoZSByZXNvdXJjZXMsIGF0IGxlYXN0IGZvciB0aGUNCj4gICAgIHNoYXJl ZCBzZWdtZW50cywgd2lsbCBvbmx5IGJlIGZpbmFsaXplZCB3aGVuIHRoZSBwcm90ZWN0aW9uDQo+ ICAgICBwYXRoIGlzIGFjdHVhbGx5IGFjdGl2YXRlZC4gVGhlcmVmb3JlLCBmb3IgdGhlIHB1cmlz dHMgLQ0KPiAgICAgcmVnYXJkaW5nIHRoZSB0ZXJtaW5vbG9neSAtIFNNUCBsaWVzIHNvbWV3aGVy ZSBiZXR3ZWVuDQo+ICAgICBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbi4NCj4NCj4gICAgIEJv dGggc2VudGVuY2VzIGFyZSBwcm9ibGVtYXRpYy4gSW4gdGhlIGZpcnN0LCBjb21taXRtZW50IHNl ZW1zIHRvDQo+ICAgICBjb3ZlciBhICJwcm90ZWN0aW9uIHN3aXRjaCIgd291bGQgImNvbm5lY3Qi IHRoZSBwcm90ZWN0aW9uIHBhdGgNCj4gICAgIGJ1dCBub3QgdGhlIGVhcmxpZXIgImFsbG9jYXRp b24iIG9mIHJlc291cmNlcy4gKFF1b3RlZCB0ZXJtcyBhcmUNCj4gICAgIHVzZWQgaW4gZWFybGll ciBSRkNzLikgVGhlIHNlY29uZCBjb25jbHVzaW9uIGlzIGJhc2VkIG9uIHRoZSBuZXcNCj4gICAg IGRpc3RpbmN0aW9uIG9mIHByb3RlY3Rpb24gdnMuIHJlc3RvcmF0aW9uIGFuZCBpcyB1bm5lY2Vz c2FyeSB3aXRoDQo+ICAgICB0aGUgZXhpc3RpbmcgZGlzdGluY3Rpb24uDQo+DQo+ICAgICBUaGlz IGlzc3VlIGV4aXN0cyBpbiBtdWx0aXBsZSBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlDQo+ ICAgICAiY29tbWl0dGVkIiBpcyB1c2VkIGFuZCBJJ2QgcmVjb21tZW5kIHRoYXQgZWFjaCBzaG91 bGQgYmUgcmVwbGFjZWQNCj4gICAgIHdpdGggdGVybWlub2xvZ3kgdXNlZCBpbiB0aGUgcmVmZXJl bmNlZCBSRkNzLCBpLmUuLCAiYWxsb2NhdGlvbiIsDQo+ICAgICAiY29ubmVjdGlvbiIsICJjcm9z cy1jb25uZWN0IiwgInByb3RlY3Rpb24gc3dpdGNoKG92ZXIpIiwgLi4uDQo+DQo+ICAgICBOb3Rl IEknbSAqbm90KiBoaWdobGlnaHRpbmcgYWxsIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBwcm9ibGVt cyBpbiB0aGUNCj4gICAgIGRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4gVGhlcmUgYXJl IGEgY291cGxlIG9mIHBsYWNlcyBpbiB0aGUNCj4gICAgIGRvY3VtZW50IHdoZXJlIEkgdGhpbmsg aXQncyBwb3NzaWJsZSB0aGF0IG9uY2UgdGhpcyB0ZXJtaW5vbG9neQ0KPiAgICAgYW1iaWd1aXR5 IGlzIGNvcnJlY3RlZCB0aGF0IEknbGwgaGF2ZSBvdGhlciBzdWJzdGFudGl2ZSBjb21tZW50cy4N Cj4NCj4gICAgIC0gU2VjdGlvbiAyLCAxc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLiBUaGlz IHNlbnRlbmNlIHJlYWxseQ0KPiAgICAgZGVmaW5lcw0KPiAgICAgdGhlIHNjb3BlL3B1cnBvc2Ug b2YgdGhlIGRvY3VtZW50LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlvbnMNCj4gICAg IHRvIHByb3RvY29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQgc2F0aXNmeSB0 aGUNCj4gICAgIHJlcXVpcmVtZW50cyBzZXQgb3V0IGluIHRoaXMgZG9jdW1lbnQuIiBBcyBzdWNo LCBJJ2QgcmVwZWF0IHRoaXMgaW4NCj4gICAgIHRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBh IG1vcmUgcHJvbm91bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yDQo+ICAgICAzKS4NCj4NCj4g ICAgIC0gR2VuZXJhbCBjb21tZW50OiBmYXRlLXNoYXJpbmcgZm9yIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIExTUA0KPiAgICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJvdXRpbmcgcHJlc2VydmVk IGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD8NCj4gICAgIEknZCBhc3N1bWVkIHRoZSBwcm90 ZWN0aW9uIHN3aXRjaCBjb29yZGluYXRpb24gcHJvdG9jb2wgd291bGQgYmUNCj4gICAgIHJlcXVp cmVkIHRvIHRyaWdnZXIgYSBzd2l0Y2hvdmVyIG9mIHRoZSByZXZlcnNlIExTUCBpbiB0aGUgY28t cm91dGVkDQo+ICAgICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhlIGRvY3VtZW50Lg0K Pg0KPiAgICAgLSBJbiBzZWN0aW9uIDQgYW5kIDUuMiB5b3UgcmVmZXJlbmNlIDU3MTIgYW5kIDMy MDkgYXMgZGVmaW5pbmcNCj4gICAgIHByZWVtcHRpb24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9y LiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+ICAgICByZWZlcmVuY2UgaGVyZSBhcyBpdCBk ZWZpbmVzIGJvdGggaW4gdGhlIGNvbnRleHQgb2Ygc3Vydml2YWJpbGl0eSBhbmQNCj4gICAgIGlu IGRlcGVuZGVudCBvZiBjb250cm9sIHBsYW5lLg0KPg0KPiAgICAgLSBJbiBzZWN0aW9uIDQuMiB5 b3Ugc2F5ICJUaGVyZWZvcmUsIGl0IGlzIHN1Z2dlc3RlZCB0aGF0IHRoaXMgYmUNCj4gICAgIGNh cnJpZWQgb3V0IHVuZGVyIHRoZSBjb250cm9sIG9mIGEgZHluYW1pYyBjb250cm9sIHBsYW5lIHNp bWlsYXIgdG8NCj4gICAgIEdNUExTIFtSRkMzOTQ1XS4iIHBlcmhhcHMgeW91IG1lYW4gImJhc2Vk IG9uIEdNUExTIj8gSWYgc28sIGdyZWF0LA0KPiAgICAgcGxlYXNlIG1ha2UgdGhlIGNvcnJlY3Rp b24uIElmIG5vdCwgSSB0aGluayB0aGUgZGViYXRlIG9mIHdoaWNoDQo+ICAgICBjb250cm9sIHBy b3RvY29sIGlzIHVzZWQgZm9yIE1QTFMtVFAgaXMgd2F5IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhp cw0KPiAgICAgZG9jdW1lbnQuDQo+DQo+ICAgICAtIFNlY3Rpb24gNS4xLCBwYXJhZ3JhcGggMS4g V2h5IGFyZSB5b3UgdXNpbmcgIlNIT1VMRCBOT1QiIGhlcmU/IElmDQo+ICAgICByZWZlcnJpbmcg dG8gc29sdXRpb25zIGNvbmZvcm1hbnQgd2l0aCB0aGlzIGRvY3VtZW50LCB0aGVuIHRoZXNlIGFy ZQ0KPiAgICAgaW5mb3JtYXRpdmUgc3RhdGVtZW50cywgImFuZCBhIG5vbi1jb250cm9sIHBsYW5l IGJhc2VkIFNNUCBzd2l0Y2hvdmVyDQo+ICAgICBtZWNoYW5pc20gaXMgdXNlZCwgdGhlIGNvbnRy b2wgcGxhbmUgU0hBTEwgTk9UIC4uLiIuIElmIHJlZmVycmluZyB0bw0KPiAgICAgYW4gb3BlcmF0 b3Incy91c2VyJ3MgY2hvaWNlIG9mIHByb3RlY3Rpb24gbWVjaGFuaXNtLCBJIHRoaW5rIHRoZSBt b3N0DQo+ICAgICB5b3UgY2FuIHNheSBpcyBNQVkuDQo+DQo+ICAgICAtIFNlY3Rpb24gNS4yLiAi VGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4gU01QDQo+ ICAgICBkb21haW4uIiBBcyB0aGlzIGlzIGEgcmVxdWlyZW1lbnQsIHdoYXQgeW91IG1lYW4gYnkg InRpZS1icmVha2luZw0KPiAgICAgcnVsZXMiIHNob3VsZCBiZSBkZWZpbmVkIGRpcmVjdGx5IG9y IGJ5IHJlZmVyZW5jZS4NCj4NCj4gICAgIC0gU2VjdGlvbiA1LjMuIFJGQzYzNzIgdGFrZXMgYW4g YXBwcm9hY2ggd2hlcmUgcHJlZW1wdGlvbiBub3RpZmljYXRpb24NCj4gICAgIGxldmVyYWdlcyB0 aGUgc3RhbmRhcmQgTVBMUy1UUCBPQU0gbWVjaGFuaXNtcywgaXMgdGhlcmUgYW55IHJlYXNvbiB0 bw0KPiAgICAgZG8gbW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2MzcyPw0KPg0KPiAgICAgLSBTZWN0 aW9uIDUuNy4gVGhlcmUgbWF5IGJlIGNvb3JkaW5hdGlvbiByZXF1aXJlZCBvbg0KPiAgICAgc29m dC1wcmVlbXB0aW9uIGFzDQo+ICAgICB3ZWxsIChkZXBlbmRpbmcgb24gdGhlIGNyb3NzLWNvbm5l Y3RzIGVzdGFibGlzaGVkIGR1cmluZyBMU1ANCj4gICAgIGVzdGFibGlzaG1lbnQpIHNvIGNvb3Jk aW5hdGVkIHN3aXRjaGluZyBzaG91bGQgYmUgc3VwcG9ydGVkDQo+ICAgICBpbmRlcGVuZGVudCBv ZiBwcmVlbXB0aW9uIG1vZGUuDQo+DQo+ICAgICBOaXRzOg0KPg0KPiAgICAgLSBBYnN0cmFjdDog SSBkb24ndCByZWNhbGwgdGhlIHRlcm0gImV4ZWN1dGl2ZSBhY3Rpb24iIGJlaW5nIHVzZWQNCj4g ICAgIGluIGFueQ0KPiAgICAgZWFybGllciByZWxhdGVkL3JlZmVyZW5jZWQgUkZDcy4gUmF0aGVy IHRoYW4gaW50cm9kdWNlIGEgbmV3IChhbmQNCj4gICAgIHVuZGVmaW5lZCkgdGVybSwgcGVyaGFw cyB5b3UgY2FuIHVzZSBhbiBleGlzdGluZyBvbmUsIGUuZy4sDQo+ICAgICAicHJvdGVjdGlvbiBz d2l0Y2giPw0KPg0KPiAgICAgLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAxLiBEbyB3ZSByZWFsbHkg bmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2YNCj4gICAgIE1QTFMtVFAgdG8gZGViYXRlPyBJIHN1 Z2dlc3QganVzdCByZWZlcmVuY2luZyB5b3VyIGZhdm9yaXRlIE1QTFMtVFANCj4gICAgIGRvY3Vt ZW50KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMuDQo+DQo+ICAgICBU aGUgbGFzdCBzZW50ZW5jZSBhbHNvIG1ha2VzIGEgc3ViamVjdGl2ZSBzdGF0ZW1lbnQuIFdoZXRo ZXIgaXQgaXMNCj4gICAgIGNyaXRpY2FsIG9yIG5vIGlzIHVubmVjZXNzYXJ5LiBZb3UgY2FuIGp1 c3Qgc2F5IHNvbWV0aGluZyBsaWtlIDYzNzINCj4gICAgIHByb3ZpZGVzIGEgc3Vydml2YWJpbGl0 eSBmcmFtZXdvcmsgZm9yIE1QTFMtVFAgYW5kIGlzIHRoZSBmb3VuZGF0aW9uDQo+ICAgICBmb3Ig dGhpcyBkb2N1bWVudC4NCj4NCj4gICAgIC0gU2VjdGlvbiAxLCBwYXJhZ3JhcGggMy4gSXNuJ3Qg dGhlIHJpZ2h0IHJlZmVyZW5jZSA0NDI3IG5vdCA0NDI4Pw0KPiAgICAgQWxzbyBkcm9wIHRoZSB3 b3JkIGxpbmVhciwgYXMgaXQgaXMgYW4gdW5uZWNlc3NhcnkgcXVhbGlmaWVyIGFuZA0KPiAgICAg NDQyNy80NDI4IGRvbid0IHVzZSBpdC4NCj4NCj4gICAgIC0gU2VjdGlvbnMgMyAoYW5kIHRvIGEg bGVzc2VyIGRlZ3JlZSBzZWN0aW9uIDIpIGFyZSByZWFsbHkNCj4gICAgIGludHJvZHVjdG9yeQ0K PiAgICAgdGV4dC4gSSdtIHVuc3VyZSBhcyB0byB3aHkgdGhleSBhcmVuJ3QgcGFydCBvZiBzZWN0 aW9uIDEuDQo+DQo+ICAgICAtIFNlY3Rpb24gMy4yIHNob3VsZCBoYXZlIGEgcmVmZXJlbmNlIGZv ciAiZXhpc3RpbmcgY29udHJvbCBwbGFuZQ0KPiAgICAgc29sdXRpb25zIGZvciBTTVAgd2l0aGlu IE1QTFMiLg0KPg0KPiAgICAgLSBTZWN0aW9uIDMuMiBhZ2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZl IGFjdGlvbiIgdGVybS4NCj4NCj4gICAgIC0gU2VjdGlvbiA0LjEuIFlvdSBzYXkgInR3byBvcGVy YXRpb25zIHNpbXVsdGFuZW91c2x5Ii4gRG8geW91IHJlYWxseQ0KPiAgICAgbWVhbiAic2ltdWx0 YW5lb3VzbHkiIG9yIG1lcmVseSB0aGF0IHRoZXkgbXVzdCBib3RoIG9jY3VyIGZvcg0KPiAgICAg cHJvdGVjdGlvbiB0byBiZSBwcm92aWRlZD8gKFNhbWUgY29tbWVudCBpbiBzZWN0aW9uIDUuMS4N Cj4NCj4gICAgIC0gU2VjdGlvbiA1LjIuIEkgc3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRs eSBidWxsZXR0ZWQNCj4gICAgIHJlcXVpcmVtZW50cw0KPiAgICAgbGlzdC4NCj4NCj4gICAgIC0g U2VjdGlvbiA1LjI6IEZpcnN0IHBhcmFncmFwaCBhbmQgZm9ydGggYnVsbGV0IGxhc3Qgc2VudGVu Y2UuIFRoZXNlDQo+ICAgICBib3RoIGJhc2ljYWxseSBjb3ZlciB0aGUgc2FtZSB0b3BpYyAocHJl ZW1wdGlvbikgYW5kIGFjdHVhbGx5IHNheQ0KPiAgICAgc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5n cy4gSSBzdWdnZXN0IGNvbWJpbmUgaW50byBhIHNpbmdsZQ0KPiAgICAgcmVxdWlyZW1lbnQgdG8g ZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBmdWxsIGNvdmVyYWdlIG9mIHRoZSB0b3BpYy4NCj4NCj4g ICAgIC0gU2VjdGlvbiA1LjIsIHJlcSA1LiBIb3cgZG9lcyB0aGlzIHJlbGF0ZSB0byBzZWN0aW9u IDUuNT8gU2hvdWxkbid0DQo+ICAgICB0aGUgdG9waWNzIHJlbGF0ZWQgdG8gdGltaW5nIGJlIGNv bnNvbGlkYXRlZD8NCj4NCj4gICAgIC0gU2VjdGlvbiA1LjI6IHJlcXVpcmVtZW50IDYgc2VlbXMg dG8gYmUgYSBzdWJzZXQgb2YgNywgc28gaXQNCj4gICAgIHNob3VsZCBiZQ0KPiAgICAgZHJvcHBl ZC4NCj4NCj4gICAgIC0gU2VjdGlvbiA1LjIsIHJlcXVpcmVtZW50IDguIElzbid0IHRoaXMgYSBz dWJzZXQgb2YgOT8gV2h5IGNhbGwgb3V0DQo+ICAgICBqdXN0IHRoaXMgb25lIHRyYWZmaWMgdHJl YXRtZW50IChzdWIpIHJlcXVpcmVtZW50Pw0KPg0KPiAgICAgLSBTZWN0aW9uIDUuMy4gcy9NQVkv d2lsbA0KPg0KPiAgICAgLSBzZWN0aW9uIDUuNDogIiBXaGVuIHRoZSB3b3JraW5nIHBhdGggZGV0 ZWN0cy4uIiBkZXRlY3Rpb24gaXMgYnkgdGhlDQo+ICAgICBub2RlIG5vdCB0aGUgcGF0aC4NCj4N Cj4gICAgIC0gU2VjdGlvbiA1LjQsIGxhc3Qgc2VudGVuY2UuIFRoaXMgaXMgb25seSB0aGUgMm5k IHRpbWUgeW91IGltcGx5IHRoYXQNCj4gICAgIHRoZSBkb2N1bWVudCBjb3ZlcnMgcmVxdWlyZW1l bnRzIG9uIGEgbmV3IHByb3RvY29sLiBJIHRoaW5rIHRoaXMNCj4gICAgIHBvaW50IGlzIGN1cnJl bnRseSB0b28gc3VidGxlIGluIHRoZSBkb2N1bWVudC4gKFRoaXMgcG9pbnQgd2FzIGFsc28NCj4g ICAgIG1hZGUgYXMgYSBtaW5vciBjb21tZW50LikNCj4NCj4gICAgIC0gc2VjdGlvbiA1LjYuIFJG QyA2MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkDQo+DQo+DQo+ICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgbXBscyBtYWlsaW5nIGxpc3QN Cj4gICAgIG1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQo+ICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgbXBscyBtYWlsaW5n IGxpc3QNCj4gICAgIG1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+DQoNCg== From nobody Thu Jul 24 13:43:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4971B28E8; Thu, 24 Jul 2014 13:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNrMcv2K_cDU; Thu, 24 Jul 2014 13:43:24 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD95B1ADDC6; Thu, 24 Jul 2014 13:43:23 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so3390130wes.33 for ; Thu, 24 Jul 2014 13:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=YyA7H5o/N8id0Jj+aXIe9SzcXIz7nSL5t0dnWJnYi6c=; b=Xu6Fq9Y3nhlAGrY63iRKuwA7/YHU7mSGiXsSAk6mmUzcb+YejWLcHabQb8pr829ZRI Y5Hek4m4rO+Mb5IRCvMCrU0Qrcngz3rrjlw4H5RyUtwTAcFALWiUAXqBlVCo/TZ49Csr Op4BYM6ByeYJ5P8WZExD9viXn8Exgzc7Q0/e4x8gqHrKs9IYDS6443B3j9fDJc4+fbMn spUSzbF0AF9XQvBmFhm/qH7lCzE2uaDhG1/mSD8ogGz/kspRwxr6t8bIeJ4og3NErL6Z BoSa9DVBGN/XMpCl5V5OKSbcc4pcwFUDzbRJSrg0RvQgYccmNHcPJGzuPFvLoqv6p3lT 9nzQ== X-Received: by 10.180.90.233 with SMTP id bz9mr16142614wib.42.1406234602390; Thu, 24 Jul 2014 13:43:22 -0700 (PDT) Received: from [127.0.0.1] (ARennes-652-1-33-41.w86-214.abo.wanadoo.fr. [86.214.136.41]) by mx.google.com with ESMTPSA id m8sm10534047wjy.35.2014.07.24.13.43.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 13:43:21 -0700 (PDT) Sender: Thomas Morin Message-ID: <53D16FE5.3080903@orange.com> Date: Thu, 24 Jul 2014 16:43:17 -0400 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/0M5kDKgQ0Xg93mT_zDomD2sFBV8 Subject: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:43:27 -0000 Adrian, Alia, Just one little tiny thing: I would personally love it if we can avoid 3-letter acronyms, often colliding all over the place, and have at least 4 letters in the working group nicknames. We can have a quantitative metric to measure success (e.g. number of working group with 3 letters or less). So, that's a low hanging fruit. You can't say no. -Thomas From nobody Thu Jul 24 13:47:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7F51ADDC6; Thu, 24 Jul 2014 13:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B58nLhxFDgs; Thu, 24 Jul 2014 13:47:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD19D1AD972; Thu, 24 Jul 2014 13:47:18 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB723.namprd05.prod.outlook.com (10.141.207.153) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 24 Jul 2014 20:47:11 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) by BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) with mapi id 15.00.0995.014; Thu, 24 Jul 2014 20:47:11 +0000 From: John Scudder To: "EXT - thomas.morin@orange.com" Thread-Topic: [RTG-DIR] Working group names Thread-Index: AQHPp3/yf3sVnasEjkuaF3owvMIAUJuvseHp Date: Thu, 24 Jul 2014 20:47:10 +0000 Message-ID: <2B9AE31E-B2CE-4F67-8BBD-245DD50EF147@juniper.net> References: <53D16FE5.3080903@orange.com> In-Reply-To: <53D16FE5.3080903@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.163.16] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(24454002)(189002)(199002)(377454003)(95666004)(82746002)(99286002)(19580395003)(83716003)(85852003)(21056001)(86362001)(107046002)(101416001)(106356001)(83072002)(79102001)(77982001)(66066001)(110136001)(33656002)(46102001)(36756003)(64706001)(2656002)(85306003)(87936001)(50986999)(54356999)(76482001)(76176999)(19580405001)(80022001)(20776003)(83322001)(92566001)(74502001)(74662001)(106116001)(105586002)(99396002)(4396001)(81542001)(31966008)(92726001)(81342001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB723; H:BLUPR05MB722.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/p3_2M3b6IxOtsxYlI2jzbXdWFDM Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:47:20 -0000 I believe these are technically known as ETLAs (Extended TLAs).=20 --John On Jul 24, 2014, at 4:43 PM, "Thomas Morin" wrote= : >=20 > Adrian, Alia, >=20 > Just one little tiny thing: I would personally love it if we can avoid 3-= letter acronyms, often colliding all over the place, and have at least 4 le= tters in the working group nicknames. >=20 > We can have a quantitative metric to measure success (e.g. number of work= ing group with 3 letters or less). > So, that's a low hanging fruit. > You can't say no. >=20 > -Thomas >=20 From nobody Thu Jul 24 14:54:35 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FB21A0880; Thu, 24 Jul 2014 14:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.752 X-Spam-Level: X-Spam-Status: No, score=-94.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5mX0Tcn8UPA; Thu, 24 Jul 2014 14:08:40 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EB81A0944; Thu, 24 Jul 2014 14:08:39 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 Jul 2014 06:08:35 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.01.0355.002; Fri, 25 Jul 2014 06:08:35 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger , Yaacov Weingarten Thread-Topic: =?ks_c_5601-1987?B?W1JURy1ESVJdIMi4vcU6ICBbbXBsc10gUnRnRGlyIHJldmlldzog?= =?ks_c_5601-1987?Q?draft-ietf-mpls-smp-requirements-06.txt?= Thread-Index: AQHPp30iSpuXCVf3qESpyvJuRanFjZuvtdp1 Date: Thu, 24 Jul 2014 21:08:35 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2874D304@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info> , <53CFA4FC.3080304@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A2874CF28@SMTP2.etri.info>, <53D16B3C.4000104@labn.net> In-Reply-To: <53D16B3C.4000104@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/j1gi5lQxYegFH2UP_-e_N6bC5xY X-Mailman-Approved-At: Thu, 24 Jul 2014 14:54:33 -0700 Cc: "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogIMi4vcU6ICBbbXBsc10gUnRnRGlyIHJldmll?= =?euc-kr?q?w=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 21:08:44 -0000 TG91LA0KDQpUaGUgdGV4dCBpbiB0aGUgY3VycmVudCBkcmFmdCAoMDcgdmVyc2lvbikgd2FzIHJl dmlld2VkIGJ5IFlhYWNvdiBiZWZvcmUgdXBsb2FkaW5nIGluIHB1YmxpYy4NCkhlIG1pZ2h0IGhh dmUgc29tZSBuaXRzIHRoYXQgY2FuIGJlIGZpeGVkIGR1cmluZyB0aGUgUkZDIGVkaXRpbmcsIA0K YnV0ICBpdCBpcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQgaGUgaXMgb2sgd2l0aCB0aGUgY3VycmVu dCBvbmUuDQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0KDQoNCiANCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrq4s70gu+e29zogTG91IEJlcmdlciBbbGJl cmdlckBsYWJuLm5ldF0NCrq4s70gs6/CpTogMjAxNLPiIDe/+SAyNcDPILHdv+TAzyC/wMD8IDU6 MjMNCrnetMIgu+e29zogt/nBpLW/OyBZYWFjb3YgV2VpbmdhcnRlbg0KwvzBtjogbXBsc0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3Jn OyBydGctZGlyQGlldGYub3JnOyBydGctYWRzQHRvb2xzLmlldGYub3JnDQrBprjxOiBSZTogW1JU Ry1ESVJdIMi4vcU6ICBbbXBsc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxzLXNtcC1y ZXF1aXJlbWVudHMtMDYudHh0DQoNCkkgYmVsaWV2ZSB0aGUgYW1iaWd1aXR5IG1lbnRpb25lZCBi eSBZYWNvdiBzdGlsbCBleGlzdHMuIEkgYWN0dWFsbHkNCmRlZmVyIHRvIFlhY292IG9uIHRoaXMs IGFuZCBpZiBoZSdzIGhhcHB5IHdpdGggdGhlIHRleHQgLS0gc28gYW0gSS4NCg0KTG91DQoNClBT IEkgaGF2ZSBhIGNvdXBsZSBvZiBtb3JlIG1pbm9yIGNvbW1lbnRzIHRvIHNlbmQgLS0gYW5kIHdp bGwgZG8gc28gYXMNCnNvb24gYXMgSSBjYW4uDQoNCk9uIDcvMjQvMjAxNCA3OjUyIEFNLCC3+cGk tb8gd3JvdGU6DQo+IExvdSwNCj4NCj4gQW55IGFtYmlndWl0eSBpcyBub3QgaW50ZW50aW9uYWwu DQo+DQo+IFRoZSBsYXRlc3QgdGV4dCByZWxhdGVkIHRvIHRoaXMgaXNzdWUgaXM6DQo+IC0tLQ0K PiAgICAzLiBJZiBtdWx0aXBsZSBwcm90ZWN0aW9uIHBhdGhzIG9mIGVxdWFsIHByaW9yaXR5IGFy ZSByZXF1ZXN0aW5nIHRoZQ0KPiAgICAgICBzaGFyZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2Vz IFNIQUxMIGJlIHV0aWxpemVkIG9uIGEgZmlyc3QgY29tZQ0KPiAgICAgICBmaXJzdCBzZXJ2ZWQg YmFzaXMuIFRyYWZmaWMgb2YgdGhlIHByb3RlY3Rpb24gcGF0aHMgdGhhdCByZXF1ZXN0DQo+ICAg ICAgIHRoZSBzaGFyZWQgcmVzb3VyY2VzIGxhdGUgU0hBTEwgYmUgcHJlZW1wdGVkLiBJbiBvcmRl ciB0byBjb3Zlcg0KPiAgICAgICB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJzdCBjb21lIGZp cnN0IHNlcnZlZCBwcmluY2lwbGUgY2Fubm90DQo+ICAgICAgIHJlc29sdmUgdGhlIGNvbnRlbnRp b24gYW1vbmcgbXVsdGlwbGUgZXF1YWwgcHJpb3JpdHkgcmVxdWVzdHMsDQo+ICAgICAgIGkuZS4s IHdoZW4gdGhlIHJlcXVlc3RzIG9jY3VyIHNpbXVsdGFuZW91c2x5LCB0aWUtYnJlYWtpbmcgcnVs ZXMNCj4gICAgICAgU0hBTEwgYmUgZGVmaW5lZCBpbiBzY29wZSBvZiBhbiBTTVAgZG9tYWluLg0K Pg0KPiAgICA0LiBJZiBhIGhpZ2hlciBwcmlvcml0eSBwYXRoIHJlcXVpcmVzIHRoZSBwcm90ZWN0 aW9uIHJlc291cmNlcyB0aGF0DQo+ICAgICAgIGFyZSBiZWluZyB1dGlsaXplZCBieSBhIGxvd2Vy IHByaW9yaXR5IHBhdGgsIHRoZSByZXNvdXJjZXMgU0hBTEwNCj4gICAgICAgYmUgdXRpbGl6ZWQg YnkgdGhlIGhpZ2hlciBwcmlvcml0eSBwYXRoLiBUcmFmZmljIHdpdGggdGhlIGxvd2VyDQo+ICAg ICAgIHByaW9yaXR5IFNIQUxMIGJlIHByZWVtcHRlZC4NCj4gLS0tDQo+DQo+IFRoZSB0ZXh0IGlz IGFscmVhZHkgc2F5aW5nIHRoYXQgdGhlIHByZWVwbXRpb24gYW5kIHV0aWxpemF0aW9uIGlzIHBl ciBwYXRoIGJhc2lzLg0KPiBJbiBteSBvcGluaW9uLCBpdCBzZWVtcyB0byBiZSBvayB3aXRob3V0 IGFkZGluZyBhbiBMU1AgaGVyZS4NCj4NCj4gSmVvbmctZG9uZw0KPg0KPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILq4s70gu+e29zogTG91IEJlcmdl ciBbbGJlcmdlckBsYWJuLm5ldF0NCj4gurizvSCzr8KlOiAyMDE0s+IgN7/5IDIzwM8gvPa/5MDP IL/AyMQgOTowNQ0KPiC53rTCILvntvc6IFlhYWNvdiBXZWluZ2FydGVuOyC3+cGktb8NCj4gwvzB tjogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXNtcC1yZXF1aXJlbWVudHMuYWxsQHRv b2xzLmlldGYub3JnOyBydGctYWRzQHRvb2xzLmlldGYub3JnOyBydGctZGlyQGlldGYub3JnDQo+ IMGmuPE6IFJlOiBbUlRHLURJUl0gW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbXBs cy1zbXAtcmVxdWlyZW1lbnRzLTA2LnR4dA0KPg0KPiBZYWFjb3YsIEplb25nLA0KPiAgICAgSSdt IG5vdCBzdXJlIGhvdyB0aGUgbGF0ZXN0IHRleHQgYWRkcmVzc2VzIHRoZSBhbWJpZ3VpdHkgeW91 DQo+IGlkZW50aWZpZWQgYmVsb3cuICBQZXJoYXBzIGFkZGluZyB0aGUgd29yZHMgIm9uIGEgcGVy IExTUCBiYXNpcyIgdG8gdGhlDQo+IHJlcXVpcmVtZW50PyAgSWYgdGhlIGFtYmlndWl0eSBpcyBp bnRlbnRpb25hbCwgdGhlbiBvZiBjb3Vyc2Ugbm8gY2hhbmdlDQo+IGlzIHdhcnJhbnRlZC4NCj4N Cj4gTG91DQo+DQo+IE9uIDcvNS8yMDE0IDM6NDkgUE0sIFlhYWNvdiBXZWluZ2FydGVuIHdyb3Rl Og0KPj4gTG91LCBoaQ0KPj4gSSB3b3VsZCBsaWtlIHRvIGFkZHJlc3MgdHdvIG9mIHlvdXIgY29t bWVudHMsIGluIHlvdXIgZm9sbG93LXVwDQo+PiBtZXNzYWdlLCBzaW5jZSBJIGFtIHRoZSBzb3Vy Y2Ugb2YgdGhlIGNoYW5nZSBpbiB0ZXJtaW5vbG9neS4NCj4+DQo+PiBSZWdhcmRpbmcgdGhlIHR3 byBvY2N1cmVuY2VzIG9mICJhc3NpZ25lZCIgaW4gcGxhY2Ugb2YgInV0aWxpemVkIiAtDQo+PiB3 aGVuIEkgcmVhZCB0aGUgcHJvcG9zZWQgY2hhbmdlcyxhcyBkaXNjdXNzZWQgYW1vbmdzdCB0aGUg YXV0aG9ycywgSQ0KPj4gZmVsdCB0aGF0IGluIHRob3NlIHR3byBpbnN0YW5jZXMgdGhlIHVzZSBv ZiAidXRpbGl6ZWQiIGNvdWxkIGxlYWQgdG8NCj4+IHNvbWUgYW1iaWd1aXR5Lg0KPj4NCj4+IElm IHdlIHN0YXRlIHRoYXQgInJlc291cmNlcyBTSE9VTEQgYmUgdXRpbGl6ZWQgb24gYSBmaXJzdCBj b21lIGZpcnN0DQo+PiBzZXJ2ZWQgYmFzaXMiIHRoaXMgY291bGQgYmUgaW50ZXJwcmV0ZWQgKElN TykgYXMgcmVmZXJyaW5nIHRvIHRoZQ0KPj4gcGFja2V0IGxldmVsLCByYXRoZXIgdGhhbiAgdXRp bGl6ZWQgYnkgYSBzcGVjaWZpYyBwYXRoLCBzdWNoIHRoYXQNCj4+IHBhY2tldHMgZnJvbSBkaWZm ZXJlbnQgcGF0aHMgY291bGQgYmUgaW50ZXJzcGVyc2VkIGFsb25nIHRoZSBzaGFyZWQNCj4+IHNl Z21lbnRzLiBUaGVyZWZvcmUsSSBzdWdnZXN0ZWQgdGhhdCBvciB0aGlzIGNvbnRleHQgaXQgd291 bGQgYmUNCj4+IGJldHRlciB0byB1c2UgYSB3b3JkIHRoYXQgbWVhbnQgdGhhdCB0aGUgZmlyc3Qt Y29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMNCj4+IHdhcyBhdCB0aGUgbGV2ZWwgb2YgYXNzaWduaW5n IChvciBhbGxvY2F0aW5nKSB0aGUgcmVzb3VyY2VzIHJhdGhlcg0KPj4gdGhhbiB1dGlsaXppbmcg dGhlbS4NCj4+DQo+PiBIb3BlIHRoaXMgY2xhcmlmaWVzIHRoaXMgcG9pbnQuIEkgYW0gY2VydGFp biB0aGF0IEkgc3BlYWsgZm9yIHRoZQ0KPj4gb3RoZXIgYXV0aG9ycyBpbiAgc2F5aW5nIHRoYXQg SSBhbSBvcGVuIHRvIG90aGVyIHN1Z2dlc3Rpb25zLg0KPj4NCj4+IEJSLA0KPj4geWFhY292DQo+ Pg0KPj4gT24gSnVsIDQsIDIwMTQgMzo1MyBBTSwgIkplb25nIFJ5b28iIDxyeW9vQGV0cmkucmUu a3INCj4+IDxtYWlsdG86cnlvb0BldHJpLnJlLmtyPj4gd3JvdGU6DQo+Pg0KPj4gICAgIERlYXIg TG91LA0KPj4NCj4+DQo+Pg0KPj4gICAgIFRoYW5rcyBhIGxvdCBmb3IgeW91ciB2YWx1YWJsZSBj b21tZW50cy4NCj4+DQo+Pg0KPj4NCj4+ICAgICBUaGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0IGhh dmUgZGlzY3Vzc2VkIHlvdXIgY29tbWVudHMsIGFuZCBhcmUNCj4+ICAgICBwcm9wb3Npbmcgb3Vy IHJlc29sdXRpb25zIHRvIHlvdXIgY29tbWVudHMuIFBsZWFzZSwgbGV0IHVzIGtub3cgaWYNCj4+ ICAgICB0aGUgcHJvcG9zYWwgaXMgYXBwcm9wcmlhdGUgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRz IGFuZCBjb25jZXJucy4NCj4+DQo+Pg0KPj4NCj4+ICAgICBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4N Cj4+DQo+PiAgICAgQXV0aG9ycyBvZiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cyBk cmFmdA0KPj4NCj4+DQo+Pg0KPj4gICAgICoqKioqKiBCZWdpbm5pbmcgb2YgQ29tbWVudCBSZXNv bHV0aW9uICoqKioqKg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gRG9jdW1lbnQncyB1c2FnZSBvZiAi Y29tbWl0dGVkIiB2cyAiYWxsb2NhdGVkIiByZXNvdXJjZXM6DQo+Pg0KPj4gICAgIEluIHNlY3Rp b24gMSB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgbm90aW9uIHRoYXQgdGhlDQo+PiAgICAg ZGlzdGluY3Rpb24gYmV0d2VlbiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBiYXNlZCBv biB3aGVuDQo+PiAgICAgcmVzb3VyY2VzIGFyZSAiY29tbWl0dGVkIi4gVGhpcyBkaWZmZXJlbmNl IGZyb20gcGFzdA0KPj4gICAgIGRlZmluaXRpb24uIFJGQzQ0MjcgYW5kIDYzNzIgbWFrZSB0aGUg ZGlzdGluY3Rpb24gdGhhdCBwcm90ZWN0aW9uDQo+PiAgICAgYW5kIHJlc3RvcmF0aW9uIGRpZmZl ciBiYXNlZCBvbiB3aGVuIHJlc291cmNlcyBhcmUgKmFsbG9jYXRlZCogbm90DQo+PiAgICAgKmNv bW1pdHRlZCouIFRvIHF1b3RlIFJGQyA0NDI3Og0KPj4NCj4+ICAgICBUaGUgZGlzdGluY3Rpb24g YmV0d2VlbiBwcm90ZWN0aW9uIGFuZCByZXN0b3JhdGlvbiBpcyBtYWRlIGJhc2VkDQo+PiAgICAg b24gdGhlIHJlc291cmNlIGFsbG9jYXRpb24gZG9uZSBkdXJpbmcgdGhlIHJlY292ZXJ5IExTUC9z cGFuDQo+PiAgICAgZXN0YWJsaXNobWVudC4gVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gZGlmZmVy ZW50IHR5cGVzIG9mDQo+PiAgICAgcmVzdG9yYXRpb24gaXMgbWFkZSBiYXNlZCBvbiB0aGUgbGV2 ZWwgb2Ygcm91dGUgY29tcHV0YXRpb24sDQo+PiAgICAgc2lnbmFsaW5nLCBhbmQgcmVzb3VyY2Ug YWxsb2NhdGlvbiBkdXJpbmcgdGhlIHJlc3RvcmF0aW9uDQo+PiAgICAgTFNQL3NwYW4gZXN0YWJs aXNobWVudC4NCj4+DQo+PiAgICAgVGhpcyBkaWZmZXJlbmNlIGFsc28gbGVhZHMgdG8gY29tZSBj b25mdXNlZCBzdGF0ZW1lbnRzIGluIHRoZQ0KPj4gICAgIGRvY3VtZW50IGFzIHdlbGwgYXMgYW1i aWd1aXR5IGluIHRoZSB0ZXh0LCBpLmUuIGNvbmZ1c2lvbiBieSB0aGUNCj4+ICAgICByZWFkZXIu IFRoZSB0ZXJtICJjb21taXR0ZWQiIGlzIG5vdCB0aWdodGx5IGRlZmluZWQgaW4gdGhpcw0KPj4g ICAgIGRvY3VtZW50IChvciBlYXJsaWVyIHdvcmspIGFuZCBpcyB1c2VkIGRpZmZlcmVudGx5IHRo YW4gaG93DQo+PiAgICAgImFsbG9jYXRlZCIgaGFzIGJlZW4gdXNlZC4gQW4gZXhhbXBsZSBvZiB0 aGlzIGNhbiBiZSBmb3VuZCBpbg0KPj4gICAgIFNlY3Rpb24gMy4xIHdoaWNoIHN0YXRlczoNCj4+ DQo+PiAgICAgSG93ZXZlciwgdGhlIGNvbW1pdG1lbnQgb2YgdGhlIHJlc291cmNlcywgYXQgbGVh c3QgZm9yIHRoZQ0KPj4gICAgIHNoYXJlZCBzZWdtZW50cywgd2lsbCBvbmx5IGJlIGZpbmFsaXpl ZCB3aGVuIHRoZSBwcm90ZWN0aW9uDQo+PiAgICAgcGF0aCBpcyBhY3R1YWxseSBhY3RpdmF0ZWQu IFRoZXJlZm9yZSwgZm9yIHRoZSBwdXJpc3RzIC0NCj4+ICAgICByZWdhcmRpbmcgdGhlIHRlcm1p bm9sb2d5IC0gU01QIGxpZXMgc29tZXdoZXJlIGJldHdlZW4NCj4+ICAgICBwcm90ZWN0aW9uIGFu ZCByZXN0b3JhdGlvbi4NCj4+DQo+PiAgICAgQm90aCBzZW50ZW5jZXMgYXJlIHByb2JsZW1hdGlj LiBJbiB0aGUgZmlyc3QsIGNvbW1pdG1lbnQgc2VlbXMgdG8NCj4+ICAgICBjb3ZlciBhICJwcm90 ZWN0aW9uIHN3aXRjaCIgd291bGQgImNvbm5lY3QiIHRoZSBwcm90ZWN0aW9uIHBhdGgNCj4+ICAg ICBidXQgbm90IHRoZSBlYXJsaWVyICJhbGxvY2F0aW9uIiBvZiByZXNvdXJjZXMuIChRdW90ZWQg dGVybXMgYXJlDQo+PiAgICAgdXNlZCBpbiBlYXJsaWVyIFJGQ3MuKSBUaGUgc2Vjb25kIGNvbmNs dXNpb24gaXMgYmFzZWQgb24gdGhlIG5ldw0KPj4gICAgIGRpc3RpbmN0aW9uIG9mIHByb3RlY3Rp b24gdnMuIHJlc3RvcmF0aW9uIGFuZCBpcyB1bm5lY2Vzc2FyeSB3aXRoDQo+PiAgICAgdGhlIGV4 aXN0aW5nIGRpc3RpbmN0aW9uLg0KPj4NCj4+ICAgICBUaGlzIGlzc3VlIGV4aXN0cyBpbiBtdWx0 aXBsZSBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlDQo+PiAgICAgImNvbW1pdHRlZCIgaXMg dXNlZCBhbmQgSSdkIHJlY29tbWVuZCB0aGF0IGVhY2ggc2hvdWxkIGJlIHJlcGxhY2VkDQo+PiAg ICAgd2l0aCB0ZXJtaW5vbG9neSB1c2VkIGluIHRoZSByZWZlcmVuY2VkIFJGQ3MsIGkuZS4sICJh bGxvY2F0aW9uIiwNCj4+ICAgICAiY29ubmVjdGlvbiIsICJjcm9zcy1jb25uZWN0IiwgInByb3Rl Y3Rpb24gc3dpdGNoKG92ZXIpIiwgLi4uDQo+Pg0KPj4gICAgIE5vdGUgSSdtICpub3QqIGhpZ2hs aWdodGluZyBhbGwgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIHByb2JsZW1zIGluIHRoZQ0KPj4gICAg IGRvY3VtZW50IHJlbGF0ZWQgdG8gdGhpcyBpc3N1ZS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHBs YWNlcyBpbiB0aGUNCj4+ICAgICBkb2N1bWVudCB3aGVyZSBJIHRoaW5rIGl0J3MgcG9zc2libGUg dGhhdCBvbmNlIHRoaXMgdGVybWlub2xvZ3kNCj4+ICAgICBhbWJpZ3VpdHkgaXMgY29ycmVjdGVk IHRoYXQgSSdsbCBoYXZlIG90aGVyIHN1YnN0YW50aXZlIGNvbW1lbnRzLg0KPj4NCj4+DQo+Pg0K Pj4gICAgIFtBdXRob3JzXSBBZnRlciByZXZpZXdpbmcgUkZDcyA0NDI3LCA2MzcyLCAzOTQ1LCA0 NDI2LCBhbmQgNDQyOCwNCj4+ICAgICB3ZSBjb25jbHVkZWQgdGhhdCB0aGUgZGlzdGluY3Rpb24g YmV0d2VlbiBwcm90ZWN0aW9uIGFuZA0KPj4gICAgIHJlc3RvcmF0aW9uIHNob3VsZCBiZSBhbGln bmVkIHdpdGggdGhlIGV4aXRpbmcgZG9jdW1lbnRzDQo+PiAgICAgbm9ybWF0aXZlbHkgcmVmZXJl bmNlZCBieSB0aGlzIGRvY3VtZW50LiBBY2NvcmRpbmdseSwgdGhlDQo+PiAgICAgZm9sbG93aW5n IDE2IG1vZGlmaWNhdGlvbnMgd2lsbCBiZSBkb25lIGluIHJldmlzaW9uOg0KPj4NCj4+DQo+Pg0K Pj4gICAgICgxKSBTZWN0aW9uIDEsIHRoZSB0aGlyZCBwYXJhZ3JhcGgNCj4+DQo+PiAgICAgT0xE Og0KPj4NCj4+ICAgICBBcyBwb2ludGVkIG91dA0KPj4NCj4+ICAgICBpbiBbUkZDNjM3Ml0gYW5k IFtSRkM0NDI4XSwgYXBwbHlpbmcgMSsxIGxpbmVhciBwcm90ZWN0aW9uIHJlcXVpcmVzDQo+Pg0K Pj4gICAgIHRoYXQgcmVzb3VyY2VzIGFyZSBjb21taXR0ZWQgZm9yIHVzZSBieSBib3RoIHRoZSB3 b3JraW5nIGFuZA0KPj4NCj4+ICAgICBwcm90ZWN0aW9uIHBhdGhzLiBBcHBseWluZyAxOjEgcHJv dGVjdGlvbiByZXF1aXJlcyB0aGF0IHRoZSBzYW1lDQo+Pg0KPj4gICAgIHJlc291cmNlcyBhcmUg Y29tbWl0dGVkLCBidXQgYWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhlIHByb3RlY3Rpb24NCj4+ DQo+PiAgICAgcGF0aCB0byBiZSB1dGlsaXplZCBmb3IgcHJlLWVtcHRpYmxlIGV4dHJhIHRyYWZm aWMuDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+PiAgICAgQXMgcG9pbnRlZCBvdXQNCj4+DQo+PiAg ICAgaW4gW1JGQzYzNzJdIGFuZCBbUkZDNDQyOF0sIGFwcGx5aW5nIDErMSBwcm90ZWN0aW9uIHJl cXVpcmVzDQo+Pg0KPj4gICAgIHRoYXQgcmVzb3VyY2VzIGFyZSBhbGxvY2F0ZWQgZm9yIHVzZSBi eSBib3RoIHRoZSB3b3JraW5nIGFuZA0KPj4NCj4+ICAgICBwcm90ZWN0aW9uIHBhdGhzLiBBcHBs eWluZyAxOjEgcHJvdGVjdGlvbiByZXF1aXJlcyB0aGF0IHRoZSBzYW1lDQo+Pg0KPj4gICAgIHJl c291cmNlcyBhcmUgYWxsb2NhdGVkLCBidXQgYWxsb3dzIHRoZSByZXNvdXJjZXMgb2YgdGhlIHBy b3RlY3Rpb24NCj4+DQo+PiAgICAgcGF0aCB0byBiZSB1dGlsaXplZCBmb3IgcHJlLWVtcHRpYmxl IGV4dHJhIHRyYWZmaWMuDQo+Pg0KPj4NCj4+DQo+PiAgICAgKDIpIFRoZSB3aG9sZSB0ZXh0IGlu IFNlY3Rpb24gMy4xIHdpbGwgYmUgcmVwbGFjZWQgd2l0aDoNCj4+DQo+PiAgICAgW1JGQzYzNzJd LCBiYXNlZCB1cG9uIHRoZSBkZWZpbml0aW9ucyBpbiBbUkZDNDQyN10sIGRpZmZlcmVudGlhdGVz DQo+PiAgICAgYmV0d2VlbiAicHJvdGVjdGlvbiIgYW5kICJyZXN0b3JhdGlvbiIgZGVwZW5kZW50 IHVwb24gdGhlIGR5bmFtaXNtDQo+PiAgICAgb2YgdGhlIHJlc291cmNlIGFsbG9jYXRpb24uIFRo ZSBzYW1lIGRpc3RpbmN0aW9uIGlzIHVzZWQgaW4NCj4+ICAgICBbUkZDMzk0NV0sIFtSRkM0NDI2 XSwgYW5kIFtSRkM0NDI4XS4gVGhpcyBkb2N1bWVudCBhbHNvIHVzZXMgdGhlDQo+PiAgICAgc2Ft ZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGFzIHN0YXRl ZCBpbg0KPj4gICAgIFtSRkM2MzcyXS4NCj4+DQo+Pg0KPj4NCj4+ICAgICAoMykgSW4gcGFnZSA2 LA0KPj4NCj4+ICAgICBPTEQ6DQo+Pg0KPj4gICAgIFRoZSB1c2Ugb2YgcHJlZW1wdGlvbiBpbiB0 aGUgbmV0d29yayBpcyB0eXBpY2FsbHkgYSBidXNpbmVzcyBvcg0KPj4NCj4+ICAgICBwb2xpY3kg ZGVjaXNpb24gc3VjaCB0aGF0IHdoZW4gcHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIGNvbnRlbmRl ZCwNCj4+DQo+PiAgICAgcHJpb3JpdHkgY2FuIGJlIGFwcGxpZWQgdG8gZGV0ZXJtaW5lIHRvIHdo aWNoIHBhcnRpZXMgdGhlIHByb3RlY3Rpb24NCj4+DQo+PiAgICAgcmVzb3VyY2VzIGFyZSBjb21t aXR0ZWQuDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+PiAgICAgVGhlIHVzZSBvZiBwcmVlbXB0aW9u IGluIHRoZSBuZXR3b3JrIGlzIHR5cGljYWxseSBhIGJ1c2luZXNzIG9yDQo+Pg0KPj4gICAgIHBv bGljeSBkZWNpc2lvbiBzdWNoIHRoYXQgd2hlbiBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgY29u dGVuZGVkLA0KPj4NCj4+ICAgICBwcmlvcml0eSBjYW4gYmUgYXBwbGllZCB0byBkZXRlcm1pbmUg d2hpY2ggcGFydGllcyB1dGlsaXplIHRoZQ0KPj4gICAgIHByb3RlY3Rpb24NCj4+DQo+PiAgICAg cmVzb3VyY2VzLg0KPj4NCj4+DQo+Pg0KPj4gICAgICg0KSBQYWdlIDcsIHRoZSBmaXJzdCBwYXJh Z3JhcGg6DQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgdGhlIHJlc291cmNlcyBmb3IgdGhl IHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkgY29tbWl0dGVkLA0KPj4NCj4+ICAgICBORVcNCj4+ DQo+PiAgICAgdGhlIHJlc291cmNlcyBmb3IgdGhlIHByb3RlY3Rpb24gcGF0aCBhcmUgZnVsbHkg ZGVkaWNhdGVkLA0KPj4NCj4+DQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgcmVzb3VyY2Vz IG1heSBiZSBwbGFubmVkIGJ1dCB3b3VsZCBub3QgYmUgY29tbWl0dGVkIHVudGlsIKGmDQo+Pg0K Pj4gICAgIE5FVzoNCj4+DQo+PiAgICAgcmVzb3VyY2VzIG1heSBiZSBwbGFubmVkIGJ1dCB3b3Vs ZCBub3QgYmUgdXRpbGl6ZWQgdW50aWwgoaYNCj4+DQo+Pg0KPj4NCj4+ICAgICAoNSkgSW4gdGhl IHNlY29uZCBwYXJhZ3JhcGggaW4gcGFnZSA3LA0KPj4NCj4+ICAgICBPTEQ6DQo+Pg0KPj4gICAg ICJIYXJkIFByZWVtcHRpb24iIHJlcXVpcmVzIHRoZSBwcm9ncmFtbWluZyBvZiBzZWxlY3RvcnMg YXQgdGhlDQo+PiAgICAgaW5ncmVzcyBvZiBlYWNoIHNoYXJlZCBzZWdtZW50IHRvIHNwZWNpZnkg d2hpY2ggYmFja3VwIHBhdGggaGFzDQo+PiAgICAgdGhlIGhpZ2hlc3QgcHJpb3JpdHkgd2hlbiBj b21taXR0aW5nIHByb3RlY3Rpb24gcmVzb3VyY2VzLCB0aGUNCj4+ICAgICBvdGhlcnMgYmVpbmcg cHJlZW1wdGVkLg0KPj4NCj4+ICAgICBORVcNCj4+DQo+PiAgICAgIkhhcmQgUHJlZW1wdGlvbiIg cmVxdWlyZXMgdGhlIHByb2dyYW1taW5nIG9mIHNlbGVjdG9ycyBhdCB0aGUNCj4+ICAgICBpbmdy ZXNzIG9mIGVhY2ggc2hhcmVkIHNlZ21lbnQgdG8gc3BlY2lmeSB0aGUgcHJpb3JpdGllcyBvZiBi YWNrdXANCj4+ICAgICBwYXRocywgc28gdGhhdCB0cmFmZmljIG9mIGxvd2VyIHByaW9yaXR5IHBh dGhzIGNhbiBiZSBwcmVlbXB0ZWQuDQo+Pg0KPj4NCj4+DQo+PiAgICAgKDYpIFRoZSBmaXJzdCBw YXJhZ3JhcGggb2YgU2VjdGlvbiA0LjE6DQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgoaYg YW5kIGNvbW1pdCB0aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMuIFRoZSBjb21taXRtZW50IG9mIHJl c291cmNlcw0KPj4NCj4+ICAgICBpcyBkZXBlbmRlbnQgdXBvbiChpg0KPj4NCj4+ICAgICBORVc6 DQo+Pg0KPj4gICAgIKGmIGFuZCBjb29yZGluYXRlIHRoZSB1dGlsaXphdGlvbiBvZiB0aGUgYXNz b2NpYXRlZCBzaGFyZWQgcmVzb3VyY2VzLg0KPj4NCj4+ICAgICBUaGUgcmVzb3VyY2UgdXRpbGl6 YXRpb24gY29vcmRpbmF0aW9uIGlzIGRlcGVuZGVudCB1cG9uIKGmDQo+Pg0KPj4NCj4+DQo+PiAg ICAgKDcpIFRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNC4xOg0KPj4NCj4+ICAgICBP TEQ6DQo+Pg0KPj4gICAgIFdoZW4gdGhlIHJlc2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hhcmVk IHNlZ21lbnRzIGFyZSBjb21taXR0ZWQgdG8gYQ0KPj4NCj4+ICAgICBwYXJ0aWN1bGFyIHByb3Rl Y3Rpb24gcGF0aCwgdGhlcmUgbWF5IG5vdCBiZSBzdWZmaWNpZW50IHJlc291cmNlcw0KPj4NCj4+ ICAgICBhdmFpbGFibGUgZm9yIGFuIGFkZGl0aW9uYWwgcHJvdGVjdGlvbiBwYXRoLiBUaGlzIHRo ZW4gaW1wbGllcyB0aGF0DQo+Pg0KPj4gICAgIGlmIGFub3RoZXIgd29ya2luZyBwYXRoIG9mIHRo ZSBTTVAgZG9tYWluIHRyaWdnZXJzIGEgcHJvdGVjdGlvbg0KPj4NCj4+ICAgICBzd2l0Y2gsIHRo ZSBjb21taXRtZW50IG9mIHRoZSByZXNvdXJjZXMgbWF5IGZhaWwuIEluIG9yZGVyIHRvDQo+Pg0K Pj4gICAgIG9wdGltaXplIHRoZSBvcGVyYXRpb24gb2YgdGhlIGNvbW1pdG1lbnQgYW5kIHByZXBh cmluZyBmb3IgY2FzZXMgb2YNCj4+DQo+PiAgICAgbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWls aW5nLCB0aGUgY29tbWl0bWVudCBvZiB0aGUgc2hhcmVkDQo+Pg0KPj4gICAgIHJlc291cmNlcyBh cmUgYmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0aGUgZGlmZmVyZW50IHdvcmtpbmcgcGF0aHMgaW4N Cj4+DQo+PiAgICAgdGhlIFNNUCBuZXR3b3JrLg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4gICAg IFdoZW4gdGhlIHJlc2VydmVkIHJlc291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRzIGFyZSB1 dGlsaXplZCBieSBhDQo+Pg0KPj4gICAgIHBhcnRpY3VsYXIgcHJvdGVjdGlvbiBwYXRoLCB0aGVy ZSBtYXkgbm90IGJlIHN1ZmZpY2llbnQgcmVzb3VyY2VzDQo+Pg0KPj4gICAgIGF2YWlsYWJsZSBm b3IgYW4gYWRkaXRpb25hbCBwcm90ZWN0aW9uIHBhdGguIFRoaXMgdGhlbiBpbXBsaWVzIHRoYXQN Cj4+DQo+PiAgICAgaWYgYW5vdGhlciB3b3JraW5nIHBhdGggb2YgdGhlIFNNUCBkb21haW4gdHJp Z2dlcnMgYSBwcm90ZWN0aW9uDQo+Pg0KPj4gICAgIHN3aXRjaCwgdGhlIHJlc291cmNlIHV0aWxp emF0aW9uIGNvb3JkaW5hdGlvbiBtYXkgZmFpbC4gVGhlDQo+PiAgICAgZGlmZmVyZW50IHdvcmtp bmcgcGF0aHMgaW4NCj4+DQo+PiAgICAgdGhlIFNNUCBuZXR3b3JrIGFyZSBpbnZvbHZlZCBpbiB0 aGUgcmVzb3VyY2UgdXRpbGl6YXRpb24NCj4+ICAgICBjb29yZGluYXRpb24uDQo+Pg0KPj4gICAg IC4NCj4+DQo+Pg0KPj4NCj4+ICAgICAoOCkgU2VjdGlvbiA1LjEsDQo+Pg0KPj4gICAgIE9MRDoN Cj4+DQo+PiAgICAgoaYgYW5kIGNvbW1pdCB0aGUgYXNzb2NpYXRlZCByZXNvdXJjZXMuDQo+Pg0K Pj4gICAgIE5FVw0KPj4NCj4+ICAgICChpiBhbmQgY29vcmRpbmF0ZSB0aGUgdXRpbGl6YXRpb24g b2YgdGhlIGFzc29jaWF0ZWQgc2hhcmVkIHJlc291cmNlcy4NCj4+DQo+Pg0KPj4NCj4+ICAgICAo OSkgSW4gU2VjdGlvbiA1LjEsDQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgSW4gdGhlIGNh c2Ugb2YgbXVsdGlwbGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgY29tbWl0bWVudCBvZiB0 aGUNCj4+DQo+PiAgICAgc2hhcmVkIHJlc291cmNlcyBTSEFMTCBiZSBjb29yZGluYXRlZCBiZXR3 ZWVuIHRoZSBkaWZmZXJlbnQgd29ya2luZw0KPj4NCj4+ICAgICBwYXRocyBpbiB0aGUgU01QIG5l dHdvcmsuDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+PiAgICAgSW4gdGhlIGNhc2Ugb2YgbXVsdGlw bGUgd29ya2luZyBwYXRocyBmYWlsaW5nLCB0aGUgc2hhcmVkIHJlc291cmNlDQo+PiAgICAgdXRp bGl6YXRpb24NCj4+DQo+PiAgICAgY29vcmRpbmF0aW9uIFNIQUxMIGJlIGJldHdlZW4gdGhlIGRp ZmZlcmVudCB3b3JraW5nDQo+Pg0KPj4gICAgIHBhdGhzIGluIHRoZSBTTVAgbmV0d29yay4NCj4+ DQo+Pg0KPj4NCj4+ICAgICAoMTApIFNlY3Rpb24gNS4xLjEuDQo+Pg0KPj4gICAgIE9MRDoNCj4+ DQo+PiAgICAgoaYgYmVjYXVzZSB0aGV5IGFscmVhZHkgaGF2ZSBiZWVuIGNvbW1pdHRlZCB0byB0 aGUgcHJvdGVjdGlvbiBvZiwNCj4+ICAgICBmb3IgZXhhbXBsZSwgYSBoaWdoZXIgcHJpb3JpdHkg d29ya2luZyBwYXRoLg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4gICAgIKGmIGJlY2F1c2UgdGhl eSBhbHJlYWR5IGhhdmUgYmVlbiB1dGlsaXplZCBmb3IgdGhlIHByb3RlY3Rpb24gb2YsDQo+PiAg ICAgZm9yIGV4YW1wbGUsIGEgaGlnaGVyIHByaW9yaXR5IHdvcmtpbmcgcGF0aC4NCj4+DQo+Pg0K Pj4NCj4+ICAgICAoMTEpIFNlY3Rpb24gNS4yLCB0aGUgc2Vjb25kIGJ1bGxldCBpdGVtOg0KPj4N Cj4+ICAgICBPTEQ6DQo+Pg0KPj4gICAgIFJlc291cmNlcyBvZiB0aGUgc2hhcmVkIHNlZ21lbnRz IFNIQUxMIGJlIGNvbW1pdHRlZCB0byB0aGUNCj4+DQo+PiAgICAgcHJvdGVjdGlvbiBwYXRoIKGm DQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+PiAgICAgUmVzb3VyY2VzIG9mIHRoZSBzaGFyZWQgc2Vn bWVudHMgU0hBTEwgYmUgdXRpbGl6ZWQgYnkgdGhlDQo+Pg0KPj4gICAgIHByb3RlY3Rpb24gcGF0 aCChpg0KPj4NCj4+DQo+Pg0KPj4gICAgICgxMikgU2VjdGlvbiA1LjIsIHRoZSB0aGlyZCBidWxs ZXQgaXRlbToNCj4+DQo+PiAgICAgT0xEOg0KPj4NCj4+ICAgICBJZiBtdWx0aXBsZSBwcm90ZWN0 aW9uIHBhdGhzIG9mIGVxdWFsIHByaW9yaXR5IGFyZSByZXF1ZXN0aW5nDQo+Pg0KPj4gICAgIGFs bG9jYXRpb24gb2YgdGhlIHNoYXJlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxEIGJl DQo+Pg0KPj4gICAgIGNvbW1pdHRlZCBvbiBhIGZpcnN0IGNvbWUgZmlyc3Qgc2VydmVkIGJhc2lz Lg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4gICAgIElmIG11bHRpcGxlIHByb3RlY3Rpb24gcGF0 aHMgb2YgZXF1YWwgcHJpb3JpdHkgYXJlIHJlcXVlc3RpbmcNCj4+DQo+PiAgICAgdGhlIHNoYXJl ZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZXMgU0hPVUxEIGJlDQo+Pg0KPj4gICAgIGFzc2lnbmVk IG9uIGEgZmlyc3QgY29tZSBmaXJzdCBzZXJ2ZWQgYmFzaXMuDQo+Pg0KPj4NCj4+DQo+PiAgICAg KDEzKSBTZWN0aW9uIDUuMiwgdGhlIGZvdXJ0aCBidWxsZXQgaXRlbToNCj4+DQo+PiAgICAgT0xE Og0KPj4NCj4+ICAgICBJZiB0aGUgcHJvdGVjdGlvbiByZXNvdXJjZXMgYXJlIGNvbW1pdHRlZCB0 byBhIHByb3RlY3Rpb24gcGF0aCwNCj4+DQo+PiAgICAgd2hvc2Ugd29ya2luZyBwYXRoIGhhcyBh IGxvd2VyIHByaW9yaXR5LCByZXNvdXJjZXMgcmVxdWlyZWQgZm9yDQo+Pg0KPj4gICAgIHRoZSBo aWdoZXIgcHJpb3JpdHkgcGF0aCBTSEFMTCBiZSBjb21taXR0ZWQgdG8gdGhlIGhpZ2hlciBwcmlv cml0eQ0KPj4NCj4+ICAgICBwYXRoLg0KPj4NCj4+ICAgICBORVc6DQo+Pg0KPj4gICAgIElmIHRo ZSBwcm90ZWN0aW9uIHJlc291cmNlcyBhcmUgdXRpbGl6ZWQgYnkgYSBwcm90ZWN0aW9uIHBhdGgs DQo+Pg0KPj4gICAgIHdob3NlIHdvcmtpbmcgcGF0aCBoYXMgYSBsb3dlciBwcmlvcml0eSwgcmVz b3VyY2VzIHJlcXVpcmVkIGZvcg0KPj4NCj4+ICAgICB0aGUgaGlnaGVyIHByaW9yaXR5IHBhdGgg U0hBTEwgYmUgYXNzaWduZWQgdG8gdGhlIGhpZ2hlciBwcmlvcml0eQ0KPj4NCj4+ICAgICBwYXRo Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgKDE0KSBTZWN0aW9uIDUuMi4gdGhlIHNldmVu dGggYnVsbGV0IGl0ZW0NCj4+DQo+PiAgICAgT0xEOg0KPj4NCj4+ICAgICBPbmNlIHJlc291cmNl cyBvZiBzaGFyZWQgc2VnbWVudHMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBjb21taXR0ZWQNCj4+ DQo+PiAgICAgdG8gYSBwcm90ZWN0aW9uIHBhdGgsIKGmDQo+Pg0KPj4gICAgIE5FVzoNCj4+DQo+ PiAgICAgT25jZSByZXNvdXJjZXMgb2Ygc2hhcmVkIHNlZ21lbnRzIGhhdmUgYmVlbiBzdWNjZXNz ZnVsbHkgdXRpbGl6ZWQNCj4+DQo+PiAgICAgYnkgYSBwcm90ZWN0aW9uIHBhdGgsIKGmDQo+Pg0K Pj4NCj4+DQo+PiAgICAgKDE1KSBTZWN0aW9uIDUuMywgdGhlIGZpcnN0IHBhcmFncmFwaCwNCj4+ DQo+PiAgICAgT0xEOg0KPj4NCj4+ICAgICChpiByZXF1ZXN0IHRoZSBjb21taXRtZW50IG9mIHBy b3RlY3Rpb24gcmVzb3VyY2VzLiBJZiB0aGUgbmVjZXNzYXJ5DQo+Pg0KPj4gICAgIHNoYXJlZCBy ZXNvdXJjZXMgYXJlIHVuYXZhaWxhYmxlIHRvIGJlIGNvbW1pdHRlZCB0byB0aGUgcHJvdGVjdGlv bg0KPj4NCj4+ICAgICBwYXRoLCB0aGUgZW5kcG9pbnRzIKGmDQo+Pg0KPj4NCj4+DQo+PiAgICAg TkVXOg0KPj4NCj4+ICAgICChpiByZXF1ZXN0IHRoZSBjb29yZGluYXRpb24gb2YgdGhlIHNoYXJl ZCByZXNvdXJjZSB1dGlsaXphdGlvbi4gSWYNCj4+ICAgICB0aGUgbmVjZXNzYXJ5DQo+Pg0KPj4g ICAgIHNoYXJlZCByZXNvdXJjZXMgYXJlIHVuYXZhaWxhYmxlLCB0aGUgZW5kcG9pbnRzIKGmDQo+ Pg0KPj4NCj4+DQo+PiAgICAgKDE2KSBTZWN0aW9uIDUuMywgdGhlIHNlY29uZCBwYXJhZ3JhcGgs DQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgU2ltaWxhcmx5LCBpZiBwcmVlbXB0aW9uIGlz IHN1cHBvcnRlZCBhbmQgdGhlIHJlc291cmNlcyBjdXJyZW50bHkNCj4+DQo+PiAgICAgY29tbWl0 dGVkIGZvciBhIHBhcnRpY3VsYXIgd29ya2luZyBwYXRoIGFyZSChpg0KPj4NCj4+ICAgICBORVc6 DQo+Pg0KPj4gICAgIFNpbWlsYXJseSwgaWYgcHJlZW1wdGlvbiBpcyBzdXBwb3J0ZWQgYW5kIHRo ZSByZXNvdXJjZXMgY3VycmVudGx5DQo+Pg0KPj4gICAgIHV0aWxpemVkIGJ5IGEgcGFydGljdWxh ciB3b3JraW5nIHBhdGggYXJlIKGmDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rp b24gMiwgMXN0IHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZS4gVGhpcyBzZW50ZW5jZSByZWFsbHkN Cj4+ICAgICBkZWZpbmVzDQo+PiAgICAgdGhlIHNjb3BlL3B1cnBvc2Ugb2YgdGhlIGRvY3VtZW50 LCBpLmUuLCAiY2xhcmlmaWVzIHRoZSBpbnN0cnVjdGlvbnMNCj4+ICAgICB0byBwcm90b2NvbCBk ZXNpZ25lcnMgcHJvZHVjaW5nIHNvbHV0aW9ucyB0aGF0IHNhdGlzZnkgdGhlDQo+PiAgICAgcmVx dWlyZW1lbnRzIHNldCBvdXQgaW4gdGhpcyBkb2N1bWVudC4iIEFzIHN1Y2gsIEknZCByZXBlYXQg dGhpcyBpbg0KPj4gICAgIHRoZSBhYnN0cmFjdCBhbmQgbW92ZSBpdCB0byBhIG1vcmUgcHJvbm91 bmNlZCBwbGFjZSBpbiBzZWN0aW9uIDEgKG9yDQo+PiAgICAgMykuDQo+Pg0KPj4gICAgIFtBdXRo b3JzXSBXZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGF0IHRoZSBlbmQgb2YgU2Vj dGlvbiAxOg0KPj4NCj4+ICAgICChsFRoaXMgZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8gY2xhcmlm eSB0aGUgaW5zdHJ1Y3Rpb25zIHRvIHByb3RvY29sDQo+PiAgICAgZGVzaWduZXJzIHByb2R1Y2lu ZyBzb2x1dGlvbnMgdGhhdCBzYXRpc2Z5IHRoZSByZXF1aXJlbWVudHMgc2V0DQo+PiAgICAgb3V0 IGluIHRoaXMgZG9jdW1lbnQuobENCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgLSBHZW5lcmFsIGNv bW1lbnQ6IGZhdGUtc2hhcmluZyBmb3IgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQo+PiAg ICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJvdXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJz ZSBwYXRoIGluIFNNUD8NCj4+ICAgICBJJ2QgYXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2gg Y29vcmRpbmF0aW9uIHByb3RvY29sIHdvdWxkIGJlDQo+PiAgICAgcmVxdWlyZWQgdG8gdHJpZ2dl ciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVyc2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCj4+ICAg ICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMgaW4gdGhlIGRvY3VtZW50Lg0KPj4NCj4+ICAgICBb QXV0aG9yc10gRmF0ZS1zaGFyaW5nIGlzIG5vdCByZXF1aXJlZCBieSB0aGlzIGRvY3VtZW50LiBF dmVuIGluDQo+PiAgICAgdGhlIFBTQyBsaW5lYXIgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIHN1Y2gg YXMgUkZDIDYzNzggKFBTQykgYW5kDQo+PiAgICAgUkZDIDcyNzEgKFBTQyBpbiBBUFMgbW9kZSks IGZhdGUtc2hhcmluZyBpcyBub3QgcmVxdWlyZWQgYXMNCj4+ICAgICB1bmlkaXJlY3Rpb25hbCBz d2l0Y2hpbmcgaXMgYWxsb3dlZC4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbXBvc2UNCj4+ICAg ICBhbnkgcmVzdHJpY3Rpb24gb24gY28tcm91dGluZywgZWl0aGVyLg0KPj4NCj4+DQo+Pg0KPj4N Cj4+ICAgICAtIEluIHNlY3Rpb24gNCBhbmQgNS4yIHlvdSByZWZlcmVuY2UgNTcxMiBhbmQgMzIw OSBhcyBkZWZpbmluZw0KPj4gICAgIHByZWVtcHRpb24gdGVybWlub2xvZ3kgYW5kIGJlaGF2aW9y LiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+PiAgICAgcmVmZXJlbmNlIGhlcmUgYXMgaXQg ZGVmaW5lcyBib3RoIGluIHRoZSBjb250ZXh0IG9mIHN1cnZpdmFiaWxpdHkgYW5kDQo+PiAgICAg aW4gZGVwZW5kZW50IG9mIGNvbnRyb2wgcGxhbmUuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBPbmUg Y29uY2VybiBpcyB0aGF0IFJGQyA2MzcyIGRlc2NyaWJlcyBib3RoIHNvZnQgYW5kDQo+PiAgICAg aGFyZCBwcmVlbXB0aW9ucyBpbiB0aGUgY29udGV4dCBvZiBleHRyYSB0cmFmZmljLCB3aGljaCBp cyBub3QNCj4+ICAgICBleGFjdGx5IHRoZSBjYXNlIGZvciBTTVAuDQo+Pg0KPj4NCj4+DQo+Pg0K Pj4gICAgIC0gSW4gc2VjdGlvbiA0LjIgeW91IHNheSAiVGhlcmVmb3JlLCBpdCBpcyBzdWdnZXN0 ZWQgdGhhdCB0aGlzIGJlDQo+PiAgICAgY2FycmllZCBvdXQgdW5kZXIgdGhlIGNvbnRyb2wgb2Yg YSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgc2ltaWxhciB0bw0KPj4gICAgIEdNUExTIFtSRkMzOTQ1 XS4iIHBlcmhhcHMgeW91IG1lYW4gImJhc2VkIG9uIEdNUExTIj8gSWYgc28sIGdyZWF0LA0KPj4g ICAgIHBsZWFzZSBtYWtlIHRoZSBjb3JyZWN0aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0 ZSBvZiB3aGljaA0KPj4gICAgIGNvbnRyb2wgcHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBp cyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzDQo+PiAgICAgZG9jdW1lbnQuDQo+Pg0KPj4g ICAgIFtBdXRob3JzXSBZZXMsIHdlIHdpbGwgbWFrZSB0aGUgY29ycmVjdGlvbi4NCj4+DQo+Pg0K Pj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDUuMSwgcGFyYWdyYXBoIDEuIFdoeSBhcmUgeW91IHVz aW5nICJTSE9VTEQgTk9UIiBoZXJlPyBJZg0KPj4gICAgIHJlZmVycmluZyB0byBzb2x1dGlvbnMg Y29uZm9ybWFudCB3aXRoIHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlc2UgYXJlDQo+PiAgICAgaW5m b3JtYXRpdmUgc3RhdGVtZW50cywgImFuZCBhIG5vbi1jb250cm9sIHBsYW5lIGJhc2VkIFNNUCBz d2l0Y2hvdmVyDQo+PiAgICAgbWVjaGFuaXNtIGlzIHVzZWQsIHRoZSBjb250cm9sIHBsYW5lIFNI QUxMIE5PVCAuLi4iLiBJZiByZWZlcnJpbmcgdG8NCj4+ICAgICBhbiBvcGVyYXRvcidzL3VzZXIn cyBjaG9pY2Ugb2YgcHJvdGVjdGlvbiBtZWNoYW5pc20sIEkgdGhpbmsgdGhlIG1vc3QNCj4+ICAg ICB5b3UgY2FuIHNheSBpcyBNQVkuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBUaGUgZmlyc3QgY2Fz ZSBpcyB0aGUgb25lIHdlIGFyZSBhaW1pbmcgYXQuIFdlIHdpbGwgdXNlDQo+PiAgICAgU0hBTEwg Tk9ULg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4yLiAiVGllLWJyZWFraW5n IHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4gU01QDQo+PiAgICAgZG9tYWlu LiIgQXMgdGhpcyBpcyBhIHJlcXVpcmVtZW50LCB3aGF0IHlvdSBtZWFuIGJ5ICJ0aWUtYnJlYWtp bmcNCj4+ICAgICBydWxlcyIgc2hvdWxkIGJlIGRlZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJl bmNlLg0KPj4NCj4+ICAgICBbQXV0aG9yc10gVGhlIHNlbnRlbmNlIGNhbiBiZSByZXdyaXR0ZW4g YXM6DQo+Pg0KPj4gICAgIE9MRDoNCj4+DQo+PiAgICAgVGllLWJyZWFraW5nIHJ1bGVzIFNIQUxM IGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4gU01QIGRvbWFpbi4NCj4+DQo+PiAgICAgTkVXOg0K Pj4NCj4+ICAgICBJbiBvcmRlciB0byBjb3ZlciB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBmaXJz dCBjb21lIGZpcnN0IHNlcnZlZA0KPj4gICAgIHByaW5jaXBsZSBjYW5ub3QgcmVzb2x2ZSB0aGUg Y29udGVudGlvbiBhbW9uZyBtdWx0aXBsZSBlcXVhbA0KPj4gICAgIHByaW9yaXR5IHJlcXVlc3Rz LCBpLmUuLCB3aGVuIHRoZSByZXF1ZXN0cyBvY2N1ciBzaW11bHRhbmVvdXNseSwsDQo+PiAgICAg dGllLWJyZWFraW5nIHJ1bGVzIFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4gU01QIGRv bWFpbi4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4zLiBSRkM2 MzcyIHRha2VzIGFuIGFwcHJvYWNoIHdoZXJlIHByZWVtcHRpb24gbm90aWZpY2F0aW9uDQo+PiAg ICAgbGV2ZXJhZ2VzIHRoZSBzdGFuZGFyZCBNUExTLVRQIE9BTSBtZWNoYW5pc21zLCBpcyB0aGVy ZSBhbnkgcmVhc29uIHRvDQo+PiAgICAgZG8gbW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2MzcyPw0K Pj4NCj4+ICAgICBbQXV0aG9yc10gV2UgY2FuIGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIGF0 IHRoZSBlbmQ6DQo+Pg0KPj4gICAgIKGwQXMgZGVzY3JpYmVkIGluIFtSRkM2MzcyXSwgdGhlIGV2 ZW50IG9mIHByZWVtcHRpb24gbWF5IGJlDQo+PiAgICAgZGV0ZWN0ZWQgYnkgT0FNIGFuZCByZXBv cnRlZCBhcyBhIGZhdWx0IG9yIGEgZGVncmFkYXRpb24gb2YNCj4+ICAgICB0cmFmZmljIGRlbGl2 ZXJ5LqGxDQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS43LiBUaGVyZSBtYXkgYmUgY29vcmRp bmF0aW9uIHJlcXVpcmVkIG9uDQo+PiAgICAgc29mdC1wcmVlbXB0aW9uIGFzDQo+PiAgICAgd2Vs bCAoZGVwZW5kaW5nIG9uIHRoZSBjcm9zcy1jb25uZWN0cyBlc3RhYmxpc2hlZCBkdXJpbmcgTFNQ DQo+PiAgICAgZXN0YWJsaXNobWVudCkgc28gY29vcmRpbmF0ZWQgc3dpdGNoaW5nIHNob3VsZCBi ZSBzdXBwb3J0ZWQNCj4+ICAgICBpbmRlcGVuZGVudCBvZiBwcmVlbXB0aW9uIG1vZGUuDQo+Pg0K Pj4gICAgIFtBdXRob3JzXSBZZXMsIHdlIHdpbGwgY2hhbmdlIHRoZSBzZWNvbmQgcGFyYWdyYXBo IGZyb20gobBTTVAgaW4NCj4+ICAgICBoYXJkLXByZWVtcHRpb24gbW9kZSBTSE9VTEQgoaahsSB0 byChsFNNUCBTSE9VTEQgoaahsSBhbmQgbW92ZSB0aGUNCj4+ICAgICBjaGFuZ2VkIHBhcmFncmFw aCBhYm92ZSB0aGUgZmlyc3QgcGFyYWdyYXBoLg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICBOaXRz Og0KPj4NCj4+ICAgICAtIEFic3RyYWN0OiBJIGRvbid0IHJlY2FsbCB0aGUgdGVybSAiZXhlY3V0 aXZlIGFjdGlvbiIgYmVpbmcgdXNlZA0KPj4gICAgIGluIGFueQ0KPj4gICAgIGVhcmxpZXIgcmVs YXRlZC9yZWZlcmVuY2VkIFJGQ3MuIFJhdGhlciB0aGFuIGludHJvZHVjZSBhIG5ldyAoYW5kDQo+ PiAgICAgdW5kZWZpbmVkKSB0ZXJtLCBwZXJoYXBzIHlvdSBjYW4gdXNlIGFuIGV4aXN0aW5nIG9u ZSwgZS5nLiwNCj4+ICAgICAicHJvdGVjdGlvbiBzd2l0Y2giPw0KPj4NCj4+ICAgICBbQXV0aG9y c10gWWVzLCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQgYXMgeW91IHN1Z2dlc3RlZC4NCj4+DQo+ Pg0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDEsIHBhcmFncmFwaCAxLiBEbyB3ZSByZWFsbHkg bmVlZCBhbm90aGVyIGRlZmluaXRpb24gb2YNCj4+ICAgICBNUExTLVRQIHRvIGRlYmF0ZT8gSSBz dWdnZXN0IGp1c3QgcmVmZXJlbmNpbmcgeW91ciBmYXZvcml0ZSBNUExTLVRQDQo+PiAgICAgZG9j dW1lbnQocykgYW5kIGRyb3BwaW5nIHRoZSBmaXJzdCBmb3VyIHNlbnRlbmNlcy4NCj4+DQo+PiAg ICAgVGhlIGxhc3Qgc2VudGVuY2UgYWxzbyBtYWtlcyBhIHN1YmplY3RpdmUgc3RhdGVtZW50LiBX aGV0aGVyIGl0IGlzDQo+PiAgICAgY3JpdGljYWwgb3Igbm8gaXMgdW5uZWNlc3NhcnkuIFlvdSBj YW4ganVzdCBzYXkgc29tZXRoaW5nIGxpa2UgNjM3Mg0KPj4gICAgIHByb3ZpZGVzIGEgc3Vydml2 YWJpbGl0eSBmcmFtZXdvcmsgZm9yIE1QTFMtVFAgYW5kIGlzIHRoZSBmb3VuZGF0aW9uDQo+PiAg ICAgZm9yIHRoaXMgZG9jdW1lbnQuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBUaGUgcHJvcG9zZWQg dGV4dCBmb3IgdGhlIHBhcmFncmFwaCAxIGlzOg0KPj4NCj4+ICAgICChsFRoZSBNUExTIFRyYW5z cG9ydCBQcm9maWxlIChNUExTLVRQKSBpcyBkZXNjcmliZWQgaW4gW1JGQzU5MjFdLA0KPj4NCj4+ ICAgICBhbmQgW1JGQzYzNzJdIHByb3ZpZGVzIGEgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsgZm9y IE1QTFMtVFANCj4+DQo+PiAgICAgYW5kIGlzIHRoZSBmb3VuZGF0aW9uIGZvciB0aGlzIGRvY3Vt ZW50LqGxDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiAxLCBwYXJhZ3JhcGggMy4g SXNuJ3QgdGhlIHJpZ2h0IHJlZmVyZW5jZSA0NDI3IG5vdCA0NDI4Pw0KPj4gICAgIEFsc28gZHJv cCB0aGUgd29yZCBsaW5lYXIsIGFzIGl0IGlzIGFuIHVubmVjZXNzYXJ5IHF1YWxpZmllciBhbmQN Cj4+ICAgICA0NDI3LzQ0MjggZG9uJ3QgdXNlIGl0Lg0KPj4NCj4+ICAgICBbQXV0aG9yc10gT0su DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9ucyAzIChhbmQgdG8gYSBs ZXNzZXIgZGVncmVlIHNlY3Rpb24gMikgYXJlIHJlYWxseQ0KPj4gICAgIGludHJvZHVjdG9yeQ0K Pj4gICAgIHRleHQuIEknbSB1bnN1cmUgYXMgdG8gd2h5IHRoZXkgYXJlbid0IHBhcnQgb2Ygc2Vj dGlvbiAxLg0KPj4NCj4+ICAgICBbQXV0aG9yc10gU2VjdGlvbiAzIHdhcyBpbnRlbmRlZCB0byBw cmVzZW50IGEgcmVmZXJlbmNlIG1vZGVsIGZvcg0KPj4gICAgIFNNUC4gU29tZSB0ZXh0IG9mIFNl Y3Rpb24gMiBpcyByZXBlYXRlZCBpbiBTZWN0aW9uIDEgYXMgeW91DQo+PiAgICAgc3VnZ2VzdGVk IGVhcmxpZXIuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDMuMiBz aG91bGQgaGF2ZSBhIHJlZmVyZW5jZSBmb3IgImV4aXN0aW5nIGNvbnRyb2wgcGxhbmUNCj4+ICAg ICBzb2x1dGlvbnMgZm9yIFNNUCB3aXRoaW4gTVBMUyIuDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBb UkZDNDIwNl0gd2lsbCBiZSBhZGRlZCBhcyBhIHJlZmVyZW5jZQ0KPj4NCj4+DQo+PiAgICAgLSBT ZWN0aW9uIDMuMiBhZ2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZlIGFjdGlvbiIgdGVybS4NCj4+DQo+ PiAgICAgW0F1dGhvcnNdIE9LLCB0aGUgdGVybSB3aWxsIGJlIGNoYW5nZWQuDQo+Pg0KPj4NCj4+ DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA0LjEuIFlvdSBzYXkgInR3byBvcGVyYXRpb25zIHNpbXVs dGFuZW91c2x5Ii4gRG8geW91IHJlYWxseQ0KPj4gICAgIG1lYW4gInNpbXVsdGFuZW91c2x5IiBv ciBtZXJlbHkgdGhhdCB0aGV5IG11c3QgYm90aCBvY2N1ciBmb3INCj4+ICAgICBwcm90ZWN0aW9u IHRvIGJlIHByb3ZpZGVkPyAoU2FtZSBjb21tZW50IGluIHNlY3Rpb24gNS4xLg0KPj4NCj4+ICAg ICBbQXV0aG9yc10gQm90aCBhY3Rpb25zIHNob3VsZCBvY2N1ciBhdCB0aGUgc2FtZSB0aW1lLCBv ciBhcw0KPj4gICAgIGNsb3NlbHkgYXMgcG9zc2libGUgdG8gcHJvdmlkZSBmYXN0IHByb3RlY3Rp b24uDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjIuIEkgc3VnZ2VzdCBudW1i ZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0ZWQNCj4+ICAgICByZXF1aXJlbWVudHMNCj4+ICAg ICBsaXN0Lg0KPj4NCj4+ICAgICBbQXV0aG9yc10gT0ssIHdlIHdpbGwgdXNlIG51bWJlcnMuDQo+ Pg0KPj4NCj4+DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjI6IEZpcnN0IHBhcmFncmFwaCBhbmQg Zm9ydGggYnVsbGV0IGxhc3Qgc2VudGVuY2UuIFRoZXNlDQo+PiAgICAgYm90aCBiYXNpY2FsbHkg Y292ZXIgdGhlIHNhbWUgdG9waWMgKHByZWVtcHRpb24pIGFuZCBhY3R1YWxseSBzYXkNCj4+ICAg ICBzbGlnaHRseSBkaWZmZXJlbnQgdGhpbmdzLiBJIHN1Z2dlc3QgY29tYmluZSBpbnRvIGEgc2lu Z2xlDQo+PiAgICAgcmVxdWlyZW1lbnQgdG8gZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBmdWxsIGNv dmVyYWdlIG9mIHRoZSB0b3BpYy4NCj4+DQo+PiAgICAgW0F1dGhvcnNdIFRoZSBmaXJzdCBwYXJh Z3JhcGggaXMgZm9yIHNvZnQtcHJlZW1wdGlvbiwgd2hpbGUgdGhlDQo+PiAgICAgZm91cnRoIGJ1 bGxldCBiZWxvbmdzIHRvIHRoZSByZXF1aXJlbWVudHMgb2YgaGFyZC1wcmVlbXB0aW9uLg0KPj4N Cj4+DQo+PiAgICAgLSBTZWN0aW9uIDUuMiwgcmVxIDUuIEhvdyBkb2VzIHRoaXMgcmVsYXRlIHRv IHNlY3Rpb24gNS41PyBTaG91bGRuJ3QNCj4+ICAgICB0aGUgdG9waWNzIHJlbGF0ZWQgdG8gdGlt aW5nIGJlIGNvbnNvbGlkYXRlZD8NCj4+DQo+PiAgICAgW0F1dGhvcnNdIFllcywgcmVxIDUgY2Fu IGJlIG1vdmVkIHRvIFNlY3Rpb24gNS41Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtIFNlY3Rp b24gNS4yOiByZXF1aXJlbWVudCA2IHNlZW1zIHRvIGJlIGEgc3Vic2V0IG9mIDcsIHNvIGl0DQo+ PiAgICAgc2hvdWxkIGJlDQo+PiAgICAgZHJvcHBlZC4NCj4+DQo+PiAgICAgW0F1dGhvcnNdIFll cywgaXQgd2lsbCBiZSBkZWxldGVkLg0KPj4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDUuMiwgcmVx dWlyZW1lbnQgOC4gSXNuJ3QgdGhpcyBhIHN1YnNldCBvZiA5PyBXaHkgY2FsbCBvdXQNCj4+ICAg ICBqdXN0IHRoaXMgb25lIHRyYWZmaWMgdHJlYXRtZW50IChzdWIpIHJlcXVpcmVtZW50Pw0KPj4N Cj4+ICAgICBbQXV0aG9yc10gUmVxLiA5IHdpbGwgYmUgZGVsZXRlZCBhcyBpdCBzZWVtcyB0byBy ZXF1aXJlIGNvbnRyb2wNCj4+ICAgICBwbGFuZSBzdXBwb3J0cy4NCj4+DQo+Pg0KPj4NCj4+ICAg ICAtIFNlY3Rpb24gNS4zLiBzL01BWS93aWxsDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBPSy4NCj4+ DQo+Pg0KPj4NCj4+DQo+PiAgICAgLSBzZWN0aW9uIDUuNDogIiBXaGVuIHRoZSB3b3JraW5nIHBh dGggZGV0ZWN0cy4uIiBkZXRlY3Rpb24gaXMgYnkgdGhlDQo+PiAgICAgbm9kZSBub3QgdGhlIHBh dGguDQo+Pg0KPj4gICAgIFtBdXRob3JzXSBZZXMuIFdlIHdpbGwgc2ltcGx5IHNheSB0aGF0IKGw V2hlbiB0aGUgY29uZGl0aW9uIHRoYXQNCj4+ICAgICB0cmlnZ2VyZWQgdGhlIHByb3RlY3Rpb24g c3dpdGNoaW5nIGlzIGNsZWFyZWQsIKGmobENCj4+DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjQs IGxhc3Qgc2VudGVuY2UuIFRoaXMgaXMgb25seSB0aGUgMm5kIHRpbWUgeW91IGltcGx5IHRoYXQN Cj4+ICAgICB0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50cyBvbiBhIG5ldyBwcm90b2Nv bC4gSSB0aGluayB0aGlzDQo+PiAgICAgcG9pbnQgaXMgY3VycmVudGx5IHRvbyBzdWJ0bGUgaW4g dGhlIGRvY3VtZW50LiAoVGhpcyBwb2ludCB3YXMgYWxzbw0KPj4gICAgIG1hZGUgYXMgYSBtaW5v ciBjb21tZW50LikNCj4+DQo+PiAgICAgW0F1dGhvcnNdIEFzIGluIG90aGVyIHByb3RlY3Rpb24g c3dpdGNoaW5nIHRlY2hub2xvZ2llcywgdHdvIG1vZGVzDQo+PiAgICAgb2Ygb3BlcmF0aW9ucyAo cmV2ZXJ0aXZlIGFuZCBub24tcmV2ZXJ0aXZlKSBhcmUgcmVxdWlyZWQuDQo+Pg0KPj4NCj4+DQo+ Pg0KPj4gICAgIC0gc2VjdGlvbiA1LjYuIFJGQyA2MzcyIHNob3VsZCBiZSByZWZlcmVuY2VkDQo+ Pg0KPj4gICAgIFtBdXRob3JzXSBXZSB3aWxsIGFkZCChsGFzIGRlc2NyaWJlZCBpbiBbUkZDNjM3 Ml2hsSB0byB0aGUgZW5kcyBvZg0KPj4gICAgIHR3byBwYXJhZ3JhcGhzIGZvciBXVFIgdGltZXIg YW5kIGhvbGQtb2ZmIHRpbWVyLg0KPj4NCj4+DQo+Pg0KPj4gICAgICoqKioqIEVuZCBvZiBDb21t ZW50IHJlc29sdXRpb24gKioqKioNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+ICAgICAqurizvSC757b3IDogKiJMb3UgQmVyZ2VyIiA8bGJlcmdlckBs YWJuLm5ldA0KPj4gICAgIDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+DQo+PiAgICAgKrq4s70g s6/CpSA6ICoyMDE0LTA2LTIyIDAxOjAwOjQ4ICggKzA5OjAwICkNCj4+ICAgICAqud60wiC757b3 IDogKnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4+ICAgICA8bWFpbHRvOnJ0Zy1hZHNAdG9vbHMu aWV0Zi5vcmc+IDxydGctYWRzQHRvb2xzLmlldGYub3JnDQo+PiAgICAgPG1haWx0bzpydGctYWRz QHRvb2xzLmlldGYub3JnPj4NCj4+ICAgICAqwvzBtiA6ICpydGctZGlyQGlldGYub3JnIDxtYWls dG86cnRnLWRpckBpZXRmLm9yZz4NCj4+ICAgICA8cnRnLWRpckBpZXRmLm9yZyA8bWFpbHRvOnJ0 Zy1kaXJAaWV0Zi5vcmc+PiwNCj4+ICAgICBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50 cy5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4+ICAgICA8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy1zbXAt cmVxdWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZz4NCj4+ICAgICA8ZHJhZnQtaWV0Zi1tcGxz LXNtcC1yZXF1aXJlbWVudHMuYWxsQHRvb2xzLmlldGYub3JnDQo+PiAgICAgPG1haWx0bzpkcmFm dC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmc+PiwNCj4+ICAg ICBtcGxzQGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4gPG1wbHNAaWV0Zi5vcmcNCj4+ ICAgICA8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Pg0KPj4gICAgICrBprjxIDogKlttcGxzXSBSdGdE aXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50eHQNCj4+DQo+ Pg0KPj4gICAgIEhlbGxvLA0KPj4NCj4+ICAgICBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUg Um91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcw0KPj4gICAgIGRyYWZ0LiBUaGUg Um91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3INCj4+ICAg ICByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBj YWxsIGFuZCBJRVNHDQo+PiAgICAgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVx dWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcw0KPj4gICAgIHRvIHByb3ZpZGUgYXNz aXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uDQo+PiAgICAg YWJvdXQgdGhlDQo+PiAgICAgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KPj4gICAg IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4+ DQo+PiAgICAgQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVz ZSBvZiB0aGUgUm91dGluZw0KPj4gICAgIEFEcywgaXQNCj4+ICAgICB3b3VsZCBiZSBoZWxwZnVs IGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYNCj4+ ICAgICBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byBy ZXNvbHZlIHRoZW0NCj4+ICAgICB0aHJvdWdoDQo+PiAgICAgZGlzY3Vzc2lvbiBvciBieSB1cGRh dGluZyB0aGUgZHJhZnQuDQo+Pg0KPj4gICAgIERvY3VtZW50OiBkcmFmdC1pZXRmLW1wbHMtc21w LXJlcXVpcmVtZW50cy0wNi50eHQNCj4+ICAgICBSZXZpZXdlcjogTG91IEJlcmdlcg0KPj4gICAg IFJldmlldyBEYXRlOiBKdW5lIDIxIDIwMTQNCj4+ICAgICBJRVRGIExDIEVuZCBEYXRlOiAyMDE0 LTA2LTIzDQo+PiAgICAgSW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFsDQo+Pg0KPj4gICAg IFN1bW1hcnk6DQo+PiAgICAgSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBk b2N1bWVudCB0aGF0IEkgdGhpbmsNCj4+ICAgICBzaG91bGQgKG11c3QsIGFjdHVhbGx5KSBiZSBy ZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+Pg0KPj4gICAgIENvbW1lbnRzOg0KPj4NCj4+ ICAgICBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kLCBvdGhlciB0aGFu IGEgY291cGxlIG9mDQo+PiAgICAgdGVybWlub2xvZ3kgcmVsYXRlZCBpc3N1ZXMsIGVhc2lseSB1 bmRlcnN0b29kLiBUaGUgZG9jdW1lbnQgZG9lcw0KPj4gICAgIGhhdmUgYSBudW1iZXIgb2YgdGVy bWlub2xvZ3kgYW5kIHRlY2huaWNhbCBpc3N1ZXMgd2hpY2ggc2hvdWxkIGJlDQo+PiAgICAgcmVh ZGlseSByZXNvbHZlZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCj4+DQo+PiAgICAgTWFqb3IgSXNz dWVzOg0KPj4NCj4+ICAgICBNYWpvciBpc3N1ZXMgYXJlIHRoZSB0eXBlIG9mIGNvbmNlcm5zIHRo YXQgd2lsbCByZXN1bHQgaW4gdGhlDQo+PiAgICAgZG9jdW1lbnQgYmVpbmcgYmxvY2tlZCB1bnRp bCB0aGV5IGFyZSByZXNvbHZlZC4gVGhlIFJvdXRpbmcgQURzIHdpbGwNCj4+ICAgICBiZWNvbWUg aW52b2x2ZWQuIFBsZWFzZSBpbmNsdWRlIGFsbCBvZiB0aGUgbWFqb3IgaXNzdWVzIHlvdSBoYXZl DQo+PiAgICAgZm91bmQuIEdpdmUgYXMgbXVjaCBjb250ZXh0IGluZm9ybWF0aW9uIGFzIHBvc3Np YmxlIChlLmcuLCBzZWN0aW9uDQo+PiAgICAgbnVtYmVycywgcGFyYWdyYXBoIGNvdW50cykuIElm IHlvdSBmaW5kIG5vIG1ham9yIGlzc3VlcywgcGxlYXNlDQo+PiAgICAgd3JpdGU6ICJObyBtYWpv ciBpc3N1ZXMgZm91bmQuIg0KPj4NCj4+ICAgICAtIE5vIG1ham9yIGlzc3VlcyBmb3VuZC4gSW4g cGFydGljdWxhciwgSSBleHBlY3QgYWxsIGlzc3VlcyBjYW4gYmUNCj4+ICAgICByZXNvbHZlZCB3 aXRob3V0IEFEIGludGVydmVudGlvbi4gU29tZSBvZiB0aGUgbWlub3IgaXNzdWVzLCBpZiBub3QN Cj4+ICAgICByZXNvbHZlZCB3aWxsIGJlIGVzY2FsYXRlZCB0byB0aGUgQUQvbWFqb3IgaXNzdWUg Y2F0ZWdvcnkuDQo+Pg0KPj4gICAgIE1pbm9yIElzc3VlczoNCj4+DQo+PiAgICAgTWlub3IgaXNz dWVzIGFyZSBjb25jZXJucyBhYm91dCBjbGFyaXR5IG9yIHRlY2huaWNhbCBhY2N1cmFjeSB0aGF0 DQo+PiAgICAgc2hvdWxkIGJlIGRpc2N1c3NlZCBhbmQgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0 aW9uLCBidXQgd2hpY2ggd291bGQNCj4+ICAgICBub3JtYWxseSBiZSByZXNvbHZlZCBiZXR3ZWVu IHRoZSBhdXRob3JzIGFuZCB0aGUgcmV2aWV3ZXJzLiBQbGVhc2UNCj4+ICAgICBpbmNsdWRlIGFs bCBvZiB0aGUgbWlub3IgaXNzdWVzIHlvdSBoYXZlIGZvdW5kLiBHaXZlIGFzIG11Y2ggY29udGV4 dA0KPj4gICAgIGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIChlLmcuLCBzZWN0aW9uIG51bWJlcnMs IHBhcmFncmFwaCBjb3VudHMpLg0KPj4gICAgIElmIHlvdSBmaW5kIG5vIG1pbm9yIGlzc3Vlcywg cGxlYXNlIHdyaXRlOiAiTm8gbWlub3IgaXNzdWVzIGZvdW5kLiINCj4+DQo+PiAgICAgLSBEb2N1 bWVudCdzIHVzYWdlIG9mICJjb21taXR0ZWQiIHZzICJhbGxvY2F0ZWQiIHJlc291cmNlczoNCj4+ DQo+PiAgICAgSW4gc2VjdGlvbiAxIHRoZSBkb2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBub3Rpb24g dGhhdCB0aGUNCj4+ICAgICBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3Rv cmF0aW9uIGlzIGJhc2VkIG9uIHdoZW4NCj4+ICAgICByZXNvdXJjZXMgYXJlICJjb21taXR0ZWQi LiBUaGlzIGRpZmZlcmVuY2UgZnJvbSBwYXN0DQo+PiAgICAgZGVmaW5pdGlvbi4gUkZDNDQyNyBh bmQgNjM3MiBtYWtlIHRoZSBkaXN0aW5jdGlvbiB0aGF0IHByb3RlY3Rpb24NCj4+ICAgICBhbmQg cmVzdG9yYXRpb24gZGlmZmVyIGJhc2VkIG9uIHdoZW4gcmVzb3VyY2VzIGFyZSAqYWxsb2NhdGVk KiBub3QNCj4+ICAgICAqY29tbWl0dGVkKi4gVG8gcXVvdGUgUkZDIDQ0Mjc6DQo+Pg0KPj4gICAg IFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uIGlzIG1h ZGUgYmFzZWQNCj4+ICAgICBvbiB0aGUgcmVzb3VyY2UgYWxsb2NhdGlvbiBkb25lIGR1cmluZyB0 aGUgcmVjb3ZlcnkgTFNQL3NwYW4NCj4+ICAgICBlc3RhYmxpc2htZW50LiBUaGUgZGlzdGluY3Rp b24gYmV0d2VlbiBkaWZmZXJlbnQgdHlwZXMgb2YNCj4+ICAgICByZXN0b3JhdGlvbiBpcyBtYWRl IGJhc2VkIG9uIHRoZSBsZXZlbCBvZiByb3V0ZSBjb21wdXRhdGlvbiwNCj4+ICAgICBzaWduYWxp bmcsIGFuZCByZXNvdXJjZSBhbGxvY2F0aW9uIGR1cmluZyB0aGUgcmVzdG9yYXRpb24NCj4+ICAg ICBMU1Avc3BhbiBlc3RhYmxpc2htZW50Lg0KPj4NCj4+ICAgICBUaGlzIGRpZmZlcmVuY2UgYWxz byBsZWFkcyB0byBjb21lIGNvbmZ1c2VkIHN0YXRlbWVudHMgaW4gdGhlDQo+PiAgICAgZG9jdW1l bnQgYXMgd2VsbCBhcyBhbWJpZ3VpdHkgaW4gdGhlIHRleHQsIGkuZS4gY29uZnVzaW9uIGJ5IHRo ZQ0KPj4gICAgIHJlYWRlci4gVGhlIHRlcm0gImNvbW1pdHRlZCIgaXMgbm90IHRpZ2h0bHkgZGVm aW5lZCBpbiB0aGlzDQo+PiAgICAgZG9jdW1lbnQgKG9yIGVhcmxpZXIgd29yaykgYW5kIGlzIHVz ZWQgZGlmZmVyZW50bHkgdGhhbiBob3cNCj4+ICAgICAiYWxsb2NhdGVkIiBoYXMgYmVlbiB1c2Vk LiBBbiBleGFtcGxlIG9mIHRoaXMgY2FuIGJlIGZvdW5kIGluDQo+PiAgICAgU2VjdGlvbiAzLjEg d2hpY2ggc3RhdGVzOg0KPj4NCj4+ICAgICBIb3dldmVyLCB0aGUgY29tbWl0bWVudCBvZiB0aGUg cmVzb3VyY2VzLCBhdCBsZWFzdCBmb3IgdGhlDQo+PiAgICAgc2hhcmVkIHNlZ21lbnRzLCB3aWxs IG9ubHkgYmUgZmluYWxpemVkIHdoZW4gdGhlIHByb3RlY3Rpb24NCj4+ICAgICBwYXRoIGlzIGFj dHVhbGx5IGFjdGl2YXRlZC4gVGhlcmVmb3JlLCBmb3IgdGhlIHB1cmlzdHMgLQ0KPj4gICAgIHJl Z2FyZGluZyB0aGUgdGVybWlub2xvZ3kgLSBTTVAgbGllcyBzb21ld2hlcmUgYmV0d2Vlbg0KPj4g ICAgIHByb3RlY3Rpb24gYW5kIHJlc3RvcmF0aW9uLg0KPj4NCj4+ICAgICBCb3RoIHNlbnRlbmNl cyBhcmUgcHJvYmxlbWF0aWMuIEluIHRoZSBmaXJzdCwgY29tbWl0bWVudCBzZWVtcyB0bw0KPj4g ICAgIGNvdmVyIGEgInByb3RlY3Rpb24gc3dpdGNoIiB3b3VsZCAiY29ubmVjdCIgdGhlIHByb3Rl Y3Rpb24gcGF0aA0KPj4gICAgIGJ1dCBub3QgdGhlIGVhcmxpZXIgImFsbG9jYXRpb24iIG9mIHJl c291cmNlcy4gKFF1b3RlZCB0ZXJtcyBhcmUNCj4+ICAgICB1c2VkIGluIGVhcmxpZXIgUkZDcy4p IFRoZSBzZWNvbmQgY29uY2x1c2lvbiBpcyBiYXNlZCBvbiB0aGUgbmV3DQo+PiAgICAgZGlzdGlu Y3Rpb24gb2YgcHJvdGVjdGlvbiB2cy4gcmVzdG9yYXRpb24gYW5kIGlzIHVubmVjZXNzYXJ5IHdp dGgNCj4+ICAgICB0aGUgZXhpc3RpbmcgZGlzdGluY3Rpb24uDQo+Pg0KPj4gICAgIFRoaXMgaXNz dWUgZXhpc3RzIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQgd2hlcmUNCj4+ICAg ICAiY29tbWl0dGVkIiBpcyB1c2VkIGFuZCBJJ2QgcmVjb21tZW5kIHRoYXQgZWFjaCBzaG91bGQg YmUgcmVwbGFjZWQNCj4+ICAgICB3aXRoIHRlcm1pbm9sb2d5IHVzZWQgaW4gdGhlIHJlZmVyZW5j ZWQgUkZDcywgaS5lLiwgImFsbG9jYXRpb24iLA0KPj4gICAgICJjb25uZWN0aW9uIiwgImNyb3Nz LWNvbm5lY3QiLCAicHJvdGVjdGlvbiBzd2l0Y2gob3ZlcikiLCAuLi4NCj4+DQo+PiAgICAgTm90 ZSBJJ20gKm5vdCogaGlnaGxpZ2h0aW5nIGFsbCBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgcHJvYmxl bXMgaW4gdGhlDQo+PiAgICAgZG9jdW1lbnQgcmVsYXRlZCB0byB0aGlzIGlzc3VlLiBUaGVyZSBh cmUgYSBjb3VwbGUgb2YgcGxhY2VzIGluIHRoZQ0KPj4gICAgIGRvY3VtZW50IHdoZXJlIEkgdGhp bmsgaXQncyBwb3NzaWJsZSB0aGF0IG9uY2UgdGhpcyB0ZXJtaW5vbG9neQ0KPj4gICAgIGFtYmln dWl0eSBpcyBjb3JyZWN0ZWQgdGhhdCBJJ2xsIGhhdmUgb3RoZXIgc3Vic3RhbnRpdmUgY29tbWVu dHMuDQo+Pg0KPj4gICAgIC0gU2VjdGlvbiAyLCAxc3QgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNl LiBUaGlzIHNlbnRlbmNlIHJlYWxseQ0KPj4gICAgIGRlZmluZXMNCj4+ICAgICB0aGUgc2NvcGUv cHVycG9zZSBvZiB0aGUgZG9jdW1lbnQsIGkuZS4sICJjbGFyaWZpZXMgdGhlIGluc3RydWN0aW9u cw0KPj4gICAgIHRvIHByb3RvY29sIGRlc2lnbmVycyBwcm9kdWNpbmcgc29sdXRpb25zIHRoYXQg c2F0aXNmeSB0aGUNCj4+ICAgICByZXF1aXJlbWVudHMgc2V0IG91dCBpbiB0aGlzIGRvY3VtZW50 LiIgQXMgc3VjaCwgSSdkIHJlcGVhdCB0aGlzIGluDQo+PiAgICAgdGhlIGFic3RyYWN0IGFuZCBt b3ZlIGl0IHRvIGEgbW9yZSBwcm9ub3VuY2VkIHBsYWNlIGluIHNlY3Rpb24gMSAob3INCj4+ICAg ICAzKS4NCj4+DQo+PiAgICAgLSBHZW5lcmFsIGNvbW1lbnQ6IGZhdGUtc2hhcmluZyBmb3IgY28t cm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQo+PiAgICAgcHJvdGVjdGlvbjogSG93IGlzIGNvLXJv dXRpbmcgcHJlc2VydmVkIGZvciB0aGUgcmV2ZXJzZSBwYXRoIGluIFNNUD8NCj4+ICAgICBJJ2Qg YXNzdW1lZCB0aGUgcHJvdGVjdGlvbiBzd2l0Y2ggY29vcmRpbmF0aW9uIHByb3RvY29sIHdvdWxk IGJlDQo+PiAgICAgcmVxdWlyZWQgdG8gdHJpZ2dlciBhIHN3aXRjaG92ZXIgb2YgdGhlIHJldmVy c2UgTFNQIGluIHRoZSBjby1yb3V0ZWQNCj4+ICAgICBjYXNlLCBidXQgZG9uJ3Qgc2VlIHRoaXMg aW4gdGhlIGRvY3VtZW50Lg0KPj4NCj4+ICAgICAtIEluIHNlY3Rpb24gNCBhbmQgNS4yIHlvdSBy ZWZlcmVuY2UgNTcxMiBhbmQgMzIwOSBhcyBkZWZpbmluZw0KPj4gICAgIHByZWVtcHRpb24gdGVy bWlub2xvZ3kgYW5kIGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+PiAgICAg cmVmZXJlbmNlIGhlcmUgYXMgaXQgZGVmaW5lcyBib3RoIGluIHRoZSBjb250ZXh0IG9mIHN1cnZp dmFiaWxpdHkgYW5kDQo+PiAgICAgaW4gZGVwZW5kZW50IG9mIGNvbnRyb2wgcGxhbmUuDQo+Pg0K Pj4gICAgIC0gSW4gc2VjdGlvbiA0LjIgeW91IHNheSAiVGhlcmVmb3JlLCBpdCBpcyBzdWdnZXN0 ZWQgdGhhdCB0aGlzIGJlDQo+PiAgICAgY2FycmllZCBvdXQgdW5kZXIgdGhlIGNvbnRyb2wgb2Yg YSBkeW5hbWljIGNvbnRyb2wgcGxhbmUgc2ltaWxhciB0bw0KPj4gICAgIEdNUExTIFtSRkMzOTQ1 XS4iIHBlcmhhcHMgeW91IG1lYW4gImJhc2VkIG9uIEdNUExTIj8gSWYgc28sIGdyZWF0LA0KPj4g ICAgIHBsZWFzZSBtYWtlIHRoZSBjb3JyZWN0aW9uLiBJZiBub3QsIEkgdGhpbmsgdGhlIGRlYmF0 ZSBvZiB3aGljaA0KPj4gICAgIGNvbnRyb2wgcHJvdG9jb2wgaXMgdXNlZCBmb3IgTVBMUy1UUCBp cyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzDQo+PiAgICAgZG9jdW1lbnQuDQo+Pg0KPj4g ICAgIC0gU2VjdGlvbiA1LjEsIHBhcmFncmFwaCAxLiBXaHkgYXJlIHlvdSB1c2luZyAiU0hPVUxE IE5PVCIgaGVyZT8gSWYNCj4+ICAgICByZWZlcnJpbmcgdG8gc29sdXRpb25zIGNvbmZvcm1hbnQg d2l0aCB0aGlzIGRvY3VtZW50LCB0aGVuIHRoZXNlIGFyZQ0KPj4gICAgIGluZm9ybWF0aXZlIHN0 YXRlbWVudHMsICJhbmQgYSBub24tY29udHJvbCBwbGFuZSBiYXNlZCBTTVAgc3dpdGNob3Zlcg0K Pj4gICAgIG1lY2hhbmlzbSBpcyB1c2VkLCB0aGUgY29udHJvbCBwbGFuZSBTSEFMTCBOT1QgLi4u Ii4gSWYgcmVmZXJyaW5nIHRvDQo+PiAgICAgYW4gb3BlcmF0b3Incy91c2VyJ3MgY2hvaWNlIG9m IHByb3RlY3Rpb24gbWVjaGFuaXNtLCBJIHRoaW5rIHRoZSBtb3N0DQo+PiAgICAgeW91IGNhbiBz YXkgaXMgTUFZLg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4yLiAiVGllLWJyZWFraW5nIHJ1bGVz IFNIQUxMIGJlIGRlZmluZWQgaW4gc2NvcGUgb2YgYW4gU01QDQo+PiAgICAgZG9tYWluLiIgQXMg dGhpcyBpcyBhIHJlcXVpcmVtZW50LCB3aGF0IHlvdSBtZWFuIGJ5ICJ0aWUtYnJlYWtpbmcNCj4+ ICAgICBydWxlcyIgc2hvdWxkIGJlIGRlZmluZWQgZGlyZWN0bHkgb3IgYnkgcmVmZXJlbmNlLg0K Pj4NCj4+ICAgICAtIFNlY3Rpb24gNS4zLiBSRkM2MzcyIHRha2VzIGFuIGFwcHJvYWNoIHdoZXJl IHByZWVtcHRpb24gbm90aWZpY2F0aW9uDQo+PiAgICAgbGV2ZXJhZ2VzIHRoZSBzdGFuZGFyZCBN UExTLVRQIE9BTSBtZWNoYW5pc21zLCBpcyB0aGVyZSBhbnkgcmVhc29uIHRvDQo+PiAgICAgZG8g bW9yZSAvIG5vdCBqdXN0IGZvbGxvdyA2MzcyPw0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS43LiBU aGVyZSBtYXkgYmUgY29vcmRpbmF0aW9uIHJlcXVpcmVkIG9uDQo+PiAgICAgc29mdC1wcmVlbXB0 aW9uIGFzDQo+PiAgICAgd2VsbCAoZGVwZW5kaW5nIG9uIHRoZSBjcm9zcy1jb25uZWN0cyBlc3Rh Ymxpc2hlZCBkdXJpbmcgTFNQDQo+PiAgICAgZXN0YWJsaXNobWVudCkgc28gY29vcmRpbmF0ZWQg c3dpdGNoaW5nIHNob3VsZCBiZSBzdXBwb3J0ZWQNCj4+ICAgICBpbmRlcGVuZGVudCBvZiBwcmVl bXB0aW9uIG1vZGUuDQo+Pg0KPj4gICAgIE5pdHM6DQo+Pg0KPj4gICAgIC0gQWJzdHJhY3Q6IEkg ZG9uJ3QgcmVjYWxsIHRoZSB0ZXJtICJleGVjdXRpdmUgYWN0aW9uIiBiZWluZyB1c2VkDQo+PiAg ICAgaW4gYW55DQo+PiAgICAgZWFybGllciByZWxhdGVkL3JlZmVyZW5jZWQgUkZDcy4gUmF0aGVy IHRoYW4gaW50cm9kdWNlIGEgbmV3IChhbmQNCj4+ICAgICB1bmRlZmluZWQpIHRlcm0sIHBlcmhh cHMgeW91IGNhbiB1c2UgYW4gZXhpc3Rpbmcgb25lLCBlLmcuLA0KPj4gICAgICJwcm90ZWN0aW9u IHN3aXRjaCI/DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiAxLCBwYXJhZ3JhcGggMS4gRG8gd2UgcmVh bGx5IG5lZWQgYW5vdGhlciBkZWZpbml0aW9uIG9mDQo+PiAgICAgTVBMUy1UUCB0byBkZWJhdGU/ IEkgc3VnZ2VzdCBqdXN0IHJlZmVyZW5jaW5nIHlvdXIgZmF2b3JpdGUgTVBMUy1UUA0KPj4gICAg IGRvY3VtZW50KHMpIGFuZCBkcm9wcGluZyB0aGUgZmlyc3QgZm91ciBzZW50ZW5jZXMuDQo+Pg0K Pj4gICAgIFRoZSBsYXN0IHNlbnRlbmNlIGFsc28gbWFrZXMgYSBzdWJqZWN0aXZlIHN0YXRlbWVu dC4gV2hldGhlciBpdCBpcw0KPj4gICAgIGNyaXRpY2FsIG9yIG5vIGlzIHVubmVjZXNzYXJ5LiBZ b3UgY2FuIGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtlIDYzNzINCj4+ICAgICBwcm92aWRlcyBhIHN1 cnZpdmFiaWxpdHkgZnJhbWV3b3JrIGZvciBNUExTLVRQIGFuZCBpcyB0aGUgZm91bmRhdGlvbg0K Pj4gICAgIGZvciB0aGlzIGRvY3VtZW50Lg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gMSwgcGFyYWdy YXBoIDMuIElzbid0IHRoZSByaWdodCByZWZlcmVuY2UgNDQyNyBub3QgNDQyOD8NCj4+ICAgICBB bHNvIGRyb3AgdGhlIHdvcmQgbGluZWFyLCBhcyBpdCBpcyBhbiB1bm5lY2Vzc2FyeSBxdWFsaWZp ZXIgYW5kDQo+PiAgICAgNDQyNy80NDI4IGRvbid0IHVzZSBpdC4NCj4+DQo+PiAgICAgLSBTZWN0 aW9ucyAzIChhbmQgdG8gYSBsZXNzZXIgZGVncmVlIHNlY3Rpb24gMikgYXJlIHJlYWxseQ0KPj4g ICAgIGludHJvZHVjdG9yeQ0KPj4gICAgIHRleHQuIEknbSB1bnN1cmUgYXMgdG8gd2h5IHRoZXkg YXJlbid0IHBhcnQgb2Ygc2VjdGlvbiAxLg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gMy4yIHNob3Vs ZCBoYXZlIGEgcmVmZXJlbmNlIGZvciAiZXhpc3RpbmcgY29udHJvbCBwbGFuZQ0KPj4gICAgIHNv bHV0aW9ucyBmb3IgU01QIHdpdGhpbiBNUExTIi4NCj4+DQo+PiAgICAgLSBTZWN0aW9uIDMuMiBh Z2FpbiB1c2VzIHRoZSAiZXhlY3V0aXZlIGFjdGlvbiIgdGVybS4NCj4+DQo+PiAgICAgLSBTZWN0 aW9uIDQuMS4gWW91IHNheSAidHdvIG9wZXJhdGlvbnMgc2ltdWx0YW5lb3VzbHkiLiBEbyB5b3Ug cmVhbGx5DQo+PiAgICAgbWVhbiAic2ltdWx0YW5lb3VzbHkiIG9yIG1lcmVseSB0aGF0IHRoZXkg bXVzdCBib3RoIG9jY3VyIGZvcg0KPj4gICAgIHByb3RlY3Rpb24gdG8gYmUgcHJvdmlkZWQ/IChT YW1lIGNvbW1lbnQgaW4gc2VjdGlvbiA1LjEuDQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjIuIEkg c3VnZ2VzdCBudW1iZXJpbmcgdGhlIGN1cnJlbnRseSBidWxsZXR0ZWQNCj4+ICAgICByZXF1aXJl bWVudHMNCj4+ICAgICBsaXN0Lg0KPj4NCj4+ICAgICAtIFNlY3Rpb24gNS4yOiBGaXJzdCBwYXJh Z3JhcGggYW5kIGZvcnRoIGJ1bGxldCBsYXN0IHNlbnRlbmNlLiBUaGVzZQ0KPj4gICAgIGJvdGgg YmFzaWNhbGx5IGNvdmVyIHRoZSBzYW1lIHRvcGljIChwcmVlbXB0aW9uKSBhbmQgYWN0dWFsbHkg c2F5DQo+PiAgICAgc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5ncy4gSSBzdWdnZXN0IGNvbWJpbmUg aW50byBhIHNpbmdsZQ0KPj4gICAgIHJlcXVpcmVtZW50IHRvIGVuc3VyZSBjb25zaXN0ZW5jeSBh bmQgZnVsbCBjb3ZlcmFnZSBvZiB0aGUgdG9waWMuDQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjIs IHJlcSA1LiBIb3cgZG9lcyB0aGlzIHJlbGF0ZSB0byBzZWN0aW9uIDUuNT8gU2hvdWxkbid0DQo+ PiAgICAgdGhlIHRvcGljcyByZWxhdGVkIHRvIHRpbWluZyBiZSBjb25zb2xpZGF0ZWQ/DQo+Pg0K Pj4gICAgIC0gU2VjdGlvbiA1LjI6IHJlcXVpcmVtZW50IDYgc2VlbXMgdG8gYmUgYSBzdWJzZXQg b2YgNywgc28gaXQNCj4+ICAgICBzaG91bGQgYmUNCj4+ICAgICBkcm9wcGVkLg0KPj4NCj4+ICAg ICAtIFNlY3Rpb24gNS4yLCByZXF1aXJlbWVudCA4LiBJc24ndCB0aGlzIGEgc3Vic2V0IG9mIDk/ IFdoeSBjYWxsIG91dA0KPj4gICAgIGp1c3QgdGhpcyBvbmUgdHJhZmZpYyB0cmVhdG1lbnQgKHN1 YikgcmVxdWlyZW1lbnQ/DQo+Pg0KPj4gICAgIC0gU2VjdGlvbiA1LjMuIHMvTUFZL3dpbGwNCj4+ DQo+PiAgICAgLSBzZWN0aW9uIDUuNDogIiBXaGVuIHRoZSB3b3JraW5nIHBhdGggZGV0ZWN0cy4u IiBkZXRlY3Rpb24gaXMgYnkgdGhlDQo+PiAgICAgbm9kZSBub3QgdGhlIHBhdGguDQo+Pg0KPj4g ICAgIC0gU2VjdGlvbiA1LjQsIGxhc3Qgc2VudGVuY2UuIFRoaXMgaXMgb25seSB0aGUgMm5kIHRp bWUgeW91IGltcGx5IHRoYXQNCj4+ICAgICB0aGUgZG9jdW1lbnQgY292ZXJzIHJlcXVpcmVtZW50 cyBvbiBhIG5ldyBwcm90b2NvbC4gSSB0aGluayB0aGlzDQo+PiAgICAgcG9pbnQgaXMgY3VycmVu dGx5IHRvbyBzdWJ0bGUgaW4gdGhlIGRvY3VtZW50LiAoVGhpcyBwb2ludCB3YXMgYWxzbw0KPj4g ICAgIG1hZGUgYXMgYSBtaW5vciBjb21tZW50LikNCj4+DQo+PiAgICAgLSBzZWN0aW9uIDUuNi4g UkZDIDYzNzIgc2hvdWxkIGJlIHJlZmVyZW5jZWQNCj4+DQo+Pg0KPj4gICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAgICAgbXBscyBtYWlsaW5n IGxpc3QNCj4+ICAgICBtcGxzQGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+ICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+PiAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICAgICBt cGxzIG1haWxpbmcgbGlzdA0KPj4gICAgIG1wbHNAaWV0Zi5vcmcgPG1haWx0bzptcGxzQGlldGYu b3JnPg0KPj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K Pj4NCg0K From nobody Thu Jul 24 15:12:00 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220A01A0111; Thu, 24 Jul 2014 15:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3WlXkR6UVhU; Thu, 24 Jul 2014 15:11:48 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B7E1A0194; Thu, 24 Jul 2014 15:11:43 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so3354688wes.14 for ; Thu, 24 Jul 2014 15:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yMtayuYGyXsjV8p1CQ7S3mKEgf12UCI65jCJkKLdqko=; b=OM5mAvF4jUHrrcIHkVSppwHqc+I8k2PeZ8MV92VxhdJXs/BY/1olD3Ro+6difqRj2V iBGX67xrJxox4rAVqVcE6190N9cpuhpfuNQN6SPwfPnhwBP0hHR9hbC5wOZ8EhlS3uoE xDGdX6RNtXI3GoM0/gREDZ48iL7Xs2CGJoRzj/2vWvlgFe+ad/x5gnZjvxdlNGRgoxo4 WjbxIK7stdiR7RF2trFS7+BxNCT5WhiTGj3t51JvDyHl1prnPTQuVY8ofX3AQbnzD3n1 5FKN9beeSH516zjRJ/iGsoky4CnQOWnxTgGLsJfUKWyuJci0uSQqierCOUKlbjhDr/wl 6VOQ== MIME-Version: 1.0 X-Received: by 10.180.7.230 with SMTP id m6mr113114wia.3.1406239902710; Thu, 24 Jul 2014 15:11:42 -0700 (PDT) Received: by 10.216.194.138 with HTTP; Thu, 24 Jul 2014 15:11:42 -0700 (PDT) In-Reply-To: <53D16FE5.3080903@orange.com> References: <53D16FE5.3080903@orange.com> Date: Thu, 24 Jul 2014 18:11:42 -0400 Message-ID: From: Alia Atlas To: Thomas Morin Content-Type: multipart/alternative; boundary=f46d044403b8dec14404fef7bd7c Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/GX7Y9RGL8Jp-wO5ca0lZYS98V3U Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:11:56 -0000 --f46d044403b8dec14404fef7bd7c Content-Type: text/plain; charset=UTF-8 I assume this is an objection to LES as a WG name? I have a few concerns myself about the potential and inaccurate jokes. We could make it LDP-Enabled Pseudowire-based Services (LEPS) instead? I hope you have a better naming suggestion. Alia On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin wrote: > Adrian, Alia, > > Just one little tiny thing: I would personally love it if we can avoid > 3-letter acronyms, often colliding all over the place, and have at least 4 > letters in the working group nicknames. > > We can have a quantitative metric to measure success (e.g. number of > working group with 3 letters or less). > So, that's a low hanging fruit. > You can't say no. > > -Thomas > > --f46d044403b8dec14404fef7bd7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I assume this is an objection to LES as a WG name?
I h= ave a few concerns myself about the potential and inaccurate jokes.
We could make it LDP-Enabled Pseudowire-based Services =C2=A0(LEPS) inst= ead?
I hope you have a better naming suggestion.

A= lia


On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin <thomas.morin@orange= .com> wrote:
Adrian, Alia,

Just one little tiny thing: I would personally love it if we can avoid 3-le= tter acronyms, often colliding all over the place, and have at least 4 lett= ers in the working group nicknames.

We can have a quantitative metric to measure success (e.g. number of workin= g group with 3 letters or less).
So, that's a low hanging fruit.
You can't say no.

-Thomas


--f46d044403b8dec14404fef7bd7c-- From nobody Thu Jul 24 15:49:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ED51B28B8; Thu, 24 Jul 2014 15:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfbHnp4OfsS4; Thu, 24 Jul 2014 15:48:59 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477781B28A8; Thu, 24 Jul 2014 15:48:59 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so3498859wev.27 for ; Thu, 24 Jul 2014 15:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=yaklV3VoHIHdUMCUZHVNizjYHW0i6UDK52SIZWMbG3c=; b=dyaSJkXGDL/2GXBczP7uhTAjM9ccIIO7nKzXib79wW6uMvuiVFCoc7h6bd55afancN VloRDYlCJHcWE6LXrtnsoNmZkD40XL6R2rzP1vo3D8bE0AdkQH2RbPP9ZhCIjzILTZNJ bajFxGWki7iHdeWEFfP5JBM71SiFU6SQB4ToaUD8rT+EUA7bmpClhPJVjfYxusD+QgzX 8O+rFtqk2Qo+x+FkDHhcoYCdH0MJFF+Rum7tPG8t9BoIWtN5WQIoME85T4+/+0ZW+2Hx 4K9zBf9x9WYLoxJ8QdsPK6Ckq4Ao5nZXv4HlncRS/CWB2IOL5PLNggg7Fk157fBQ5PPp XSCg== X-Received: by 10.180.212.12 with SMTP id ng12mr292566wic.9.1406242137801; Thu, 24 Jul 2014 15:48:57 -0700 (PDT) Received: from [127.0.0.1] (ARennes-652-1-33-41.w86-214.abo.wanadoo.fr. [86.214.136.41]) by mx.google.com with ESMTPSA id ft17sm19684223wjc.14.2014.07.24.15.48.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 15:48:57 -0700 (PDT) Sender: Thomas Morin Message-ID: <53D18D55.5080406@orange.com> Date: Thu, 24 Jul 2014 18:48:53 -0400 From: Thomas Morin Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <53D16FE5.3080903@orange.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010509020800020604070300" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/PcjesYyW0dXPwHYM-EukehHeEag Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:49:01 -0000 This is a multi-part message in MIME format. --------------010509020800020604070300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Alia, That was partly a joke - I hadn't read the list to check specific cases - and it's certainly not a core issue. Now looking at the list, indeed, there aren't any TLA in the proposed new working groups, except LES. I do like LEPS better. I also liked MCAST in your previous proposal, which had the benefit of reflecting the fact that PIM onw also cover IGMP maintenance and evolutions. But arguably, its probably not a good idea to change the name of a working group that does not change (much). -Thomas 2014-07-24, Alia Atlas: > I assume this is an objection to LES as a WG name? > I have a few concerns myself about the potential and inaccurate jokes. > We could make it LDP-Enabled Pseudowire-based Services (LEPS) instead? > I hope you have a better naming suggestion. > > Alia > > > On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin > wrote: > > Adrian, Alia, > > Just one little tiny thing: I would personally love it if we can > avoid 3-letter acronyms, often colliding all over the place, and > have at least 4 letters in the working group nicknames. > > We can have a quantitative metric to measure success (e.g. number > of working group with 3 letters or less). > So, that's a low hanging fruit. > You can't say no. > > -Thomas > > --------------010509020800020604070300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Alia,

That was partly a joke - I hadn't read the list to check specific cases - and it's certainly not a core issue.

Now looking at the list, indeed, there aren't any TLA in the proposed new working groups, except LES.
I do like LEPS better.

I also liked MCAST in your previous proposal, which had the benefit of reflecting the fact that PIM onw also cover IGMP maintenance and evolutions.  But arguably, its probably not a good idea to change the name of a working group that does not change (much).

-Thomas

2014-07-24, Alia Atlas:
I assume this is an objection to LES as a WG name?
I have a few concerns myself about the potential and inaccurate jokes.
We could make it LDP-Enabled Pseudowire-based Services  (LEPS) instead?
I hope you have a better naming suggestion.

Alia


On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin <thomas.morin@orange.com> wrote:
Adrian, Alia,

Just one little tiny thing: I would personally love it if we can avoid 3-letter acronyms, often colliding all over the place, and have at least 4 letters in the working group nicknames.

We can have a quantitative metric to measure success (e.g. number of working group with 3 letters or less).
So, that's a low hanging fruit.
You can't say no.

-Thomas



--------------010509020800020604070300-- From nobody Thu Jul 24 17:03:12 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663331A0537; Thu, 24 Jul 2014 17:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-pI_06TFEp8; Thu, 24 Jul 2014 17:03:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 81D691A0255; Thu, 24 Jul 2014 17:03:07 -0700 (PDT) Received: from [31.133.151.150] (unknown [31.133.151.150]) by slice.pfrc.org (Postfix) with ESMTPSA id E6105C046; Thu, 24 Jul 2014 20:03:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Haas X-Mailer: iPhone Mail (11D257) In-Reply-To: <53D18D55.5080406@orange.com> Date: Thu, 24 Jul 2014 20:02:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> To: Thomas Morin Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/M5H5HBBhHFamaJH5fQOrpSpwmdM Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Alia Atlas Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:03:08 -0000 Somehow I think that working group participants may object to being called l= epers.=20 Jeff > On Jul 24, 2014, at 18:48, Thomas Morin wrote: >=20 > I do like LEPS better. From nobody Thu Jul 24 18:44:38 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AEA1A0A86; Thu, 24 Jul 2014 18:44:36 -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=-1.9, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_rp_HTsSsN8; Thu, 24 Jul 2014 18:44:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2C71A0944; Thu, 24 Jul 2014 18:44:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHO60451; Fri, 25 Jul 2014 01:44:32 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Jul 2014 02:44:31 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.145]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 18:44:25 -0700 From: Leeyoung To: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: TEAS Thread-Index: AQHPp6n2oeW61lSmtkS4OENB4q+LUw== Date: Fri, 25 Jul 2014 01:44:24 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C0665E@dfweml706-chm.china.huawei.com> References: <53D16FE5.3080903@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.36] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C0665Edfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/oc7QqR40XsnkyBZsCZdwwm0-Ij0 Subject: [RTG-DIR] TEAS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:44:36 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C0665Edfweml706chmchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBhIHRob3VnaHQsIFRFQVMgaXMgVEUgQXJjaCBhbmQgU2lnbmFsaW5nLCBidXQgc2luY2Ug SUdQLVRFIGlzIGEgcGFydCBvZiB0aGUgZ3JvdXDigJlzIGNoYXJ0ZXIsIHdoZXJlIGlzIOKAnFJv dXRpbmfigJ0gaW4gdGhlIG5hbWUuIE1heSBJIHN1Z2dlc3QgVEVBUlMgKFRFIEFyY2gsIFJvdXRp bmcgYW5kIFNpZ25hbGluZyk/DQoNCllvdW5nDQoNCkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGct ZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0bGFzDQpTZW50OiBUaHVy c2RheSwgSnVseSAyNCwgMjAxNCA1OjEyIFBNDQpUbzogVGhvbWFzIE1vcmluDQpDYzogcnRnLWRp ckBpZXRmLm9yZzsgcnRnLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtSVEctRElSXSBX b3JraW5nIGdyb3VwIG5hbWVzDQoNCkkgYXNzdW1lIHRoaXMgaXMgYW4gb2JqZWN0aW9uIHRvIExF UyBhcyBhIFdHIG5hbWU/DQpJIGhhdmUgYSBmZXcgY29uY2VybnMgbXlzZWxmIGFib3V0IHRoZSBw b3RlbnRpYWwgYW5kIGluYWNjdXJhdGUgam9rZXMuDQpXZSBjb3VsZCBtYWtlIGl0IExEUC1FbmFi bGVkIFBzZXVkb3dpcmUtYmFzZWQgU2VydmljZXMgIChMRVBTKSBpbnN0ZWFkPw0KSSBob3BlIHlv dSBoYXZlIGEgYmV0dGVyIG5hbWluZyBzdWdnZXN0aW9uLg0KDQpBbGlhDQoNCk9uIFRodSwgSnVs IDI0LCAyMDE0IGF0IDQ6NDMgUE0sIFRob21hcyBNb3JpbiA8dGhvbWFzLm1vcmluQG9yYW5nZS5j b208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQpBZHJpYW4sIEFsaWEs DQoNCkp1c3Qgb25lIGxpdHRsZSB0aW55IHRoaW5nOiBJIHdvdWxkIHBlcnNvbmFsbHkgbG92ZSBp dCBpZiB3ZSBjYW4gYXZvaWQgMy1sZXR0ZXIgYWNyb255bXMsIG9mdGVuIGNvbGxpZGluZyBhbGwg b3ZlciB0aGUgcGxhY2UsIGFuZCBoYXZlIGF0IGxlYXN0IDQgbGV0dGVycyBpbiB0aGUgd29ya2lu ZyBncm91cCBuaWNrbmFtZXMuDQoNCldlIGNhbiBoYXZlIGEgcXVhbnRpdGF0aXZlIG1ldHJpYyB0 byBtZWFzdXJlIHN1Y2Nlc3MgKGUuZy4gbnVtYmVyIG9mIHdvcmtpbmcgZ3JvdXAgd2l0aCAzIGxl dHRlcnMgb3IgbGVzcykuDQpTbywgdGhhdCdzIGEgbG93IGhhbmdpbmcgZnJ1aXQuDQpZb3UgY2Fu J3Qgc2F5IG5vLg0KDQotVGhvbWFzDQoNCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729C0665Edfweml706chmchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SnVzdCBhIHRob3VnaHQsIFRFQVMgaXMgVEUgQXJjaCBhbmQgU2lnbmFsaW5nLCBidXQg c2luY2UgSUdQLVRFIGlzIGEgcGFydCBvZiB0aGUgZ3JvdXDigJlzIGNoYXJ0ZXIsIHdoZXJlIGlz IOKAnFJvdXRpbmfigJ0gaW4gdGhlIG5hbWUuIE1heSBJIHN1Z2dlc3QgVEVBUlMgKFRFIEFyY2gs DQogUm91dGluZyBhbmQgU2lnbmFsaW5nKT8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3VuZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g cnRnLWRpciBbbWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QWxpYSBBdGxhczxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAyNCwgMjAx NCA1OjEyIFBNPGJyPg0KPGI+VG86PC9iPiBUaG9tYXMgTW9yaW48YnI+DQo8Yj5DYzo8L2I+IHJ0 Zy1kaXJAaWV0Zi5vcmc7IHJ0Zy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtSVEctRElSXSBXb3JraW5nIGdyb3VwIG5hbWVzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFzc3VtZSB0aGlzIGlzIGFuIG9iamVjdGlvbiB0byBM RVMgYXMgYSBXRyBuYW1lPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgaGF2ZSBhIGZldyBjb25jZXJucyBteXNlbGYgYWJvdXQgdGhlIHBvdGVudGlhbCBhbmQg aW5hY2N1cmF0ZSBqb2tlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldlIGNvdWxkIG1ha2UgaXQgTERQLUVuYWJsZWQgUHNldWRvd2lyZS1iYXNl ZCBTZXJ2aWNlcyAmbmJzcDsoTEVQUykgaW5zdGVhZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaG9wZSB5b3UgaGF2ZSBhIGJldHRlciBuYW1p bmcgc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QWxpYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDI0 LCAyMDE0IGF0IDQ6NDMgUE0sIFRob21hcyBNb3JpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21h cy5tb3JpbkBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGhvbWFzLm1vcmluQG9yYW5nZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWRyaWFuLCBBbGlhLDxicj4NCjxicj4NCkp1c3Qg b25lIGxpdHRsZSB0aW55IHRoaW5nOiBJIHdvdWxkIHBlcnNvbmFsbHkgbG92ZSBpdCBpZiB3ZSBj YW4gYXZvaWQgMy1sZXR0ZXIgYWNyb255bXMsIG9mdGVuIGNvbGxpZGluZyBhbGwgb3ZlciB0aGUg cGxhY2UsIGFuZCBoYXZlIGF0IGxlYXN0IDQgbGV0dGVycyBpbiB0aGUgd29ya2luZyBncm91cCBu aWNrbmFtZXMuPGJyPg0KPGJyPg0KV2UgY2FuIGhhdmUgYSBxdWFudGl0YXRpdmUgbWV0cmljIHRv IG1lYXN1cmUgc3VjY2VzcyAoZS5nLiBudW1iZXIgb2Ygd29ya2luZyBncm91cCB3aXRoIDMgbGV0 dGVycyBvciBsZXNzKS48YnI+DQpTbywgdGhhdCdzIGEgbG93IGhhbmdpbmcgZnJ1aXQuPGJyPg0K WW91IGNhbid0IHNheSBuby48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0K PHNwYW4gY2xhc3M9ImhvZW56YiI+LVRob21hczwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729C0665Edfweml706chmchi_-- From nobody Thu Jul 24 18:50:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BB21A0AA3; Thu, 24 Jul 2014 18:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka_1-2m2RDVg; Thu, 24 Jul 2014 18:50:18 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4E91A0A90; Thu, 24 Jul 2014 18:50:18 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 200so2387564ykr.25 for ; Thu, 24 Jul 2014 18:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XsgpcxQMwwa6mTM+FN5zrjm9F0Of1482IxH6d8YD1lc=; b=Kvif/1vXQ4PX/hk0rbq0qBmlR8/l5dFtIYUi9EH4IIEN8UpqKG1AveVgsQNm6dH++1 kg1oYRNPJZPB//i9BQRLkcbfhDActzohEmK2RfwuMkHWlaaTB6YbOZZC3tDBystuAIXC fIMBtbiENdJC/6PaBiP42DXMWWX+jyOilpz1vk8eNBHPFUhfqEd/g4xAMIv6Rh8bwIvX 1JF0CeKYvj5HW3vKpbtqIhqo6SM/GCXtbPyXv+P+uL0HhMGzrmrXbxgle26+1Bla/cNS NP0pXvl2eNxkQGxdEO93adGBB2ibeWVGLTe4l7FXS9eor8kLi3nr7j83zyLw1f7dIQ7O gtVA== MIME-Version: 1.0 X-Received: by 10.236.138.167 with SMTP id a27mr17964809yhj.141.1406253017626; Thu, 24 Jul 2014 18:50:17 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Thu, 24 Jul 2014 18:50:17 -0700 (PDT) In-Reply-To: <53D18D55.5080406@orange.com> References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> Date: Thu, 24 Jul 2014 21:50:17 -0400 Message-ID: From: Alia Atlas To: Thomas Morin Content-Type: multipart/alternative; boundary=20cf303ddb82947e5e04fefacbdf Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/le9IO4bwdSIKTIeKhh-BMm_8rHc Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:50:20 -0000 --20cf303ddb82947e5e04fefacbdf Content-Type: text/plain; charset=UTF-8 Thomas, On Thu, Jul 24, 2014 at 6:48 PM, Thomas Morin wrote: > Alia, > > That was partly a joke - I hadn't read the list to check specific cases - > and it's certainly not a core issue. > Not to worry - I knew it wasn't a core issue and was a joke. :-) But I was also a bit concerned about LES as a WG name - b/c of the obvious parallelism to BESS. As I've frequently said, I'm not in marketing - I don't do good names. > Now looking at the list, indeed, there aren't any TLA in the proposed new > working groups, except LES. > I do like LEPS better. > Good to hear. > I also liked MCAST in your previous proposal, which had the benefit of > reflecting the fact that PIM onw also cover IGMP maintenance and > evolutions. But arguably, its probably not a good idea to change the name > of a working group that does not change (much). > Yes, I'm a bit undecided about whether it makes sense to change the name or not. I feel like MCAST is better advertising and accuracy - but it is a hassle. Alia > > -Thomas > > 2014-07-24, Alia Atlas: > > I assume this is an objection to LES as a WG name? > I have a few concerns myself about the potential and inaccurate jokes. > We could make it LDP-Enabled Pseudowire-based Services (LEPS) instead? > I hope you have a better naming suggestion. > > Alia > > > On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin > wrote: > >> Adrian, Alia, >> >> Just one little tiny thing: I would personally love it if we can avoid >> 3-letter acronyms, often colliding all over the place, and have at least 4 >> letters in the working group nicknames. >> >> We can have a quantitative metric to measure success (e.g. number of >> working group with 3 letters or less). >> So, that's a low hanging fruit. >> You can't say no. >> >> -Thomas >> >> > > --20cf303ddb82947e5e04fefacbdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thomas,

On Thu, Jul 24, 2014 at 6:48 PM, Thomas Morin <thomas.morin@orange.com> wrote:
=20 =20 =20
Alia,

That was partly a joke - I hadn't read the list to check specific cases - and it's certainly not a core issue.

Not to worry - I knew it wasn't a core issu= e and was a joke. :-)
But I was also a bit concerned about LES as= a WG name - b/c of the obvious parallelism to BESS. =C2=A0As I've
frequently said, I'm not in marketing - I don't do good names.= =C2=A0

=C2=A0
=
Now looking at the list, indeed, there aren't any TLA in the proposed new working groups, except LES.
I do like LEPS better.

Good to hear.=C2=A0

=C2=A0
I also liked MCAST in your previous proposal, which had the benefit of reflecting the fact that PIM onw also cover IGMP maintenance and evolutions.=C2=A0 But arguably, its probably not a go= od idea to change the name of a working group that does not change (much).

Yes, I'm = a bit undecided about whether it makes sense to change the name or not. =C2= =A0I feel like MCAST is better
advertising and accuracy - but it = is a hassle.

Alia
=C2=A0

-Thomas

2014-07-24, Alia Atlas:
=20
=C2=A0I assume this is an objection to LES as a WG n= ame?
I have a few concerns myself about the potential and inaccurate jokes.
We could make it LDP-Enabled Pseudowire-based Services =C2=A0(LEPS) instead?
I hope you have a better naming suggestion.

Alia


On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin <thomas.morin@orange.com> wrote:
Adrian, Alia,

Just one little tiny thing: I would personally love it if we can avoid 3-letter acronyms, often colliding all over the place, and have at least 4 letters in the working group nicknames.

We can have a quantitative metric to measure success (e.g. number of working group with 3 letters or less).
So, that's a low hanging fruit.
You can't say no.

-Thomas




--20cf303ddb82947e5e04fefacbdf-- From nobody Thu Jul 24 18:51:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520F1A0AA3; Thu, 24 Jul 2014 18:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFWL0VriMDBN; Thu, 24 Jul 2014 18:51:19 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA3A1A0A90; Thu, 24 Jul 2014 18:51:18 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 79so2363858ykr.22 for ; Thu, 24 Jul 2014 18:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=USYmo2oh3xOzbxra++BiD2ZL551e0bCxG8IgpolT6rE=; b=YsIjAAdLmSM76OKp3GL6HEJhNk9400FOCi7CeslPW7+tPHFnLlIbAZDQXzy9pHDR3j fjDcNOe/adYckVlR87Xwh7a/FwneGBIzKRIUDRxXRESy8UebEFtnjws3+tI1gP0qvbHi wJLvn8i75dTvHPrMjDULVc53KPP0ePUUbI4nbNlXA41dg5XkyKx2L+yNZXh8HYZs5T0o IqoBphlBowCUA+/hDtjjldDzsoz0NQ+c/zuczTByiHLNtz7713eK+GqdtXgjklxYGcPC JDKPDlnAdKIYYbmahlxUngJ+jVkl3JJGa2L1uux7nCqU/dr0OEENacJmmN+GQirTO8oL TECQ== MIME-Version: 1.0 X-Received: by 10.236.106.10 with SMTP id l10mr18021370yhg.101.1406253078260; Thu, 24 Jul 2014 18:51:18 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Thu, 24 Jul 2014 18:51:18 -0700 (PDT) In-Reply-To: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> Date: Thu, 24 Jul 2014 21:51:18 -0400 Message-ID: From: Alia Atlas To: Jeff Haas Content-Type: multipart/alternative; boundary=001a11c1de8831b39504fefacf24 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/K5l1gYXleIiINQFFkg5ec3vKjR4 Cc: "rtg-dir@ietf.org" , Thomas Morin , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:51:20 -0000 --001a11c1de8831b39504fefacf24 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas wrote: > Somehow I think that working group participants may object to being called > lepers. > I won't call them that, if you don't ;-) The group's got some great technology in it that's deployed all over, after all. Alia > > Jeff > > > On Jul 24, 2014, at 18:48, Thomas Morin wrote: > > > > I do like LEPS better. > --001a11c1de8831b39504fefacf24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 24, 2014 at 8:02 PM, Jeff Haas <jhaas@pfrc.org> wrote:<= br>
Somehow I think that working group participants may object to being called = lepers.

I won't call them that, if = you don't ;-) =C2=A0
The group's got some great technolog= y in it that's deployed all over, after all.

Alia
=C2=A0

Jeff

> On Jul 24, 2014, at 18:48, Thomas Morin <thomas.morin@orange.com> wrote:
>
> I do like LEPS better.

--001a11c1de8831b39504fefacf24-- From nobody Fri Jul 25 01:44:44 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FFA1A00B0; Fri, 25 Jul 2014 01:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfPs7BwVLsMh; Fri, 25 Jul 2014 01:44:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFEE1A008B; Fri, 25 Jul 2014 01:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2634; q=dns/txt; s=iport; t=1406277881; x=1407487481; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RmQJeuP6sKxnLlITjTuSvEu1bd4LQKvHoPtGaNCvNaU=; b=hnC7+MLavunUWqC7H+FjBnBIbwTFAuolRiI89ty5YSI0+dXztGqFMpRY CPnahWAQLLZs6SFOmQ7fNxZqEgzk2vInISG7MNAFgUjG0KzBtxiwtwyoJ F7sCCFObF1ekLmAgDbeS8yfwzSBmujFRZfHbWcsWECRitu/o3nVIA0tkX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAKMY0lOtJV2b/2dsb2JhbABZgw6BKdFAAYESFneEAwEBAQMBeQULAgEIBAEJCicHIREUEQIEDgWILgMJCLd1DYcgF4l+gyCCLQeDLoEZBZk6ggOOJ4Yhg0hs X-IronPort-AV: E=Sophos;i="5.01,729,1400025600"; d="scan'208,217";a="342725272" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jul 2014 08:44:24 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6P8iOLi012201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 08:44:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 03:44:24 -0500 From: "Stewart Bryant (stbryant)" To: Alia Atlas Thread-Topic: [RTG-DIR] Working group names Thread-Index: AQHPp3/1AQIpy6soLkyLHumcCDlol5uwHVAAgAAKZICAABSdAIAAHloAgAAfmRQ= Date: Fri, 25 Jul 2014 08:44:23 +0000 Message-ID: <5D991159-E447-4522-9B97-5974482B377C@cisco.com> References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5D991159E44745229B975974482B377Cciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/B-eeH5dyYFkkPmn_il-yL0Yx8UU Cc: Jeff Haas , "rtg-dir@ietf.org" , Thomas Morin , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 08:44:43 -0000 --_000_5D991159E44745229B975974482B377Cciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pseudo wire and LDP enabled services=3D please Stewart On 25 Jul 2014, at 02:51, "Alia Atlas" > wrote: On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas > wrote: Somehow I think that working group participants may object to being called = lepers. I won't call them that, if you don't ;-) The group's got some great technology in it that's deployed all over, after= all. Alia Jeff > On Jul 24, 2014, at 18:48, Thomas Morin > wrote: > > I do like LEPS better. --_000_5D991159E44745229B975974482B377Cciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pseudo wire and LDP enabled services=3D please

Stewart



On 25 Jul 2014, at 02:51, "Alia Atlas" <akatlas@gmail.com> wrote:

On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas <jhaas@pfrc.org&= gt; wrote:
Somehow I think that working group participants may object to being called = lepers.

I won't call them that, if you don't ;-)  
The group's got some great technology in it that's deployed all over, = after all.

Alia
 

Jeff

> On Jul 24, 2014, at 18:48, Thomas Morin <thomas.morin@orange.com> wrote:
>
> I do like LEPS better.

--_000_5D991159E44745229B975974482B377Cciscocom_-- From nobody Fri Jul 25 02:25:32 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164591B27A9; Fri, 25 Jul 2014 02:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VY_qNx-RJuh; Fri, 25 Jul 2014 02:25:31 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5D1B27AF; Fri, 25 Jul 2014 02:25:30 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 56418DE4004; Fri, 25 Jul 2014 11:25:29 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 48CA6DE4001; Fri, 25 Jul 2014 11:25:29 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jul 2014 11:25:28 +0200 Received: from [10.193.71.122] ([10.193.71.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jul 2014 11:25:28 +0200 Message-ID: <53D22282.2040906@orange.com> Date: Fri, 25 Jul 2014 11:25:22 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stewart Bryant (stbryant)" , Alia Atlas References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> , <5D991159-E447-4522-9B97-5974482B377C@cisco.com> In-Reply-To: <5D991159-E447-4522-9B97-5974482B377C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2014 09:25:28.0698 (UTC) FILETIME=[5FB5F5A0:01CFA7EA] Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/zfGf3Uoup0GymUqSmDKbvT79t2E Cc: Jeff Haas , "rtg-dir@ietf.org" , Thomas Morin , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:25:32 -0000 If that LEPS stick in the ground doesn't fit, yours is likely to please... Julien Jul. 25, 2014 - Stewart Bryant (stbryant): > Pseudo wire and LDP enabled services= please > > Stewart > > > > On 25 Jul 2014, at 02:51, "Alia Atlas" > wrote: > >> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas > > wrote: >> >> Somehow I think that working group participants may object to >> being called lepers. >> >> >> I won't call them that, if you don't ;-) >> The group's got some great technology in it that's deployed all over, >> after all. >> >> Alia >> >> >> Jeff >> >> > On Jul 24, 2014, at 18:48, Thomas Morin > > wrote: >> > >> > I do like LEPS better. >> >> From nobody Fri Jul 25 02:36:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C211A011F; Fri, 25 Jul 2014 02:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdfvIZE0y0gY; Fri, 25 Jul 2014 02:36:30 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id EFF0D1A00FF; Fri, 25 Jul 2014 02:36:29 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 385885D8B73; Fri, 25 Jul 2014 11:36:29 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 2DA335D8B57; Fri, 25 Jul 2014 11:36:29 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jul 2014 11:36:29 +0200 Received: from [10.193.71.122] ([10.193.71.122]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jul 2014 11:36:28 +0200 Message-ID: <53D22515.1060806@orange.com> Date: Fri, 25 Jul 2014 11:36:21 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Scudder , "EXT - thomas.morin@orange.com" References: <53D16FE5.3080903@orange.com> <2B9AE31E-B2CE-4F67-8BBD-245DD50EF147@juniper.net> In-Reply-To: <2B9AE31E-B2CE-4F67-8BBD-245DD50EF147@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2014 09:36:28.0648 (UTC) FILETIME=[E9125680:01CFA7EB] Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/AsWNanu3fs0amlU2BiX0VFl1o6w Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:36:31 -0000 Thomas, Any suggestion to extend "PCE" TLA? PCEP? PCECP? PAP-CHAP? (Protocols Around PCE - Computation in Hosts Appart, just Protocols) Julien Jul. 24, 2014 - John Scudder: > I believe these are technically known as ETLAs (Extended TLAs). > > --John > > On Jul 24, 2014, at 4:43 PM, "Thomas Morin" wrote: >> >> Adrian, Alia, >> >> Just one little tiny thing: I would personally love it if we can avoid 3-letter acronyms, often colliding all over the place, and have at least 4 letters in the working group nicknames. >> >> We can have a quantitative metric to measure success (e.g. number of working group with 3 letters or less). >> So, that's a low hanging fruit. >> You can't say no. >> >> -Thomas >> > From nobody Fri Jul 25 04:48:50 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C41B2816 for ; Fri, 25 Jul 2014 04:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5f8bhhhQlsQ for ; Fri, 25 Jul 2014 04:48:47 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 0D84E1B280F for ; Fri, 25 Jul 2014 04:48:47 -0700 (PDT) Received: (qmail 20657 invoked by uid 0); 25 Jul 2014 11:48:45 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 25 Jul 2014 11:48:45 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Whoa1o00n2SSUrH01hod0i; Fri, 25 Jul 2014 11:48:44 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=WrhVjQHxoPwA:10 a=Vibm9H0Vx1QA:10 a=HFCU6gKsb0MA:10 a=jPJDawAOAc8A:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=hUfgD3D5UiI3-pSYQBwA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=7OoRvQ9QHtpL63B5GDmLxhIB8+MAZNO7O8WdxcLoqoc=; b=SiGsBX1wbCjtQfzQl5uPNHdJrlws4bo7iiqEeI6zistyZiiHjAJeqZMAOUjzojvpRnWbJhQMUsPEf0uz7RknnnQnO7cGxjhmNG+/UxAWxXYsrQBYrPlGRg7179FnqtPS; Received: from box313.bluehost.com ([69.89.31.113]:44772 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XAdzH-0005Z5-9Q; Fri, 25 Jul 2014 05:48:36 -0600 Message-ID: <53D2440B.5030503@labn.net> Date: Fri, 25 Jul 2014 07:48:27 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?66WY7KCV64+Z?= References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> <53BE7F3B.9010005@labn.net> In-Reply-To: <53BE7F3B.9010005@labn.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/iwwiycTdj81w_tKrkjnDNxUyfo0 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] =?utf-8?b?W21wbHNdIO2ajOyLoDogICBSdGdEaXIgcmV2aWV3OiBk?= =?utf-8?q?raft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:48:48 -0000 Jeong, I think the document looks good. Two *minor* comments on the latest rev: On 7/10/2014 7:55 AM, Lou Berger wrote: >> > - In section 4 and 5.2 you reference 5712 and 3209 as defining >> > preemption terminology and behavior. I think 6372 is the right >> > reference here as it defines both in the context of survivability and >> > in dependent of control plane. >> > [Authors] One concern is that RFC 6372 describes both soft and hard > preemptions in the context of extra traffic, which is not exactly the > case for SMP. >> > >> > Then 6372 should be referenced and the difference should be described. > Otherwise readers are likely to think you just used the wrong reference > and that 6372's text applies. 6372 is after all titled "MPLS-TP > Survivability Framework"... >> > >> > [JR] O.K. 6372 will be referenced and we can add the following > sentence as the third sentence in the paragraph: “The traffic of lower > priority paths in this document can be viewed as the extra traffic being > preempted in [RFC6372].†Section 4 looks good, but the reference is missing from in 5.2. > Bidirectional protection switching SHOULD be supported in SMP. This is really in the wrong section. bidirectional PS has nothing to do with reversion. As before, I think section 5.7 is the best place for it. Lou From nobody Fri Jul 25 05:42:51 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D61B2857; Fri, 25 Jul 2014 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sAxsKtgBc18; Fri, 25 Jul 2014 05:42:44 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EF11B2820; Fri, 25 Jul 2014 05:42:44 -0700 (PDT) Received: from [172.16.57.142] (unknown [206.47.221.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EC0771801586; Fri, 25 Jul 2014 14:42:41 +0200 (CEST) Message-ID: <53D250CB.8020400@pi.nu> Date: Fri, 25 Jul 2014 14:42:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stewart Bryant (stbryant)" , Alia Atlas References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> , <5D991159-E447-4522-9B97-5974482B377C@cisco.com> In-Reply-To: <5D991159-E447-4522-9B97-5974482B377C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/3lBqNW4PnRK38wU-PN2zkuhnS8g Cc: Jeff Haas , "rtg-dir@ietf.org" , Thomas Morin , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:42:50 -0000 Folks, I thought about "please" also, it is a little bit "begging" but nice. /Loa On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote: > Pseudo wire and LDP enabled services= please > > Stewart > > > > On 25 Jul 2014, at 02:51, "Alia Atlas" > wrote: > >> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas > > wrote: >> >> Somehow I think that working group participants may object to >> being called lepers. >> >> >> I won't call them that, if you don't ;-) >> The group's got some great technology in it that's deployed all over, >> after all. >> >> Alia >> >> >> Jeff >> >> > On Jul 24, 2014, at 18:48, Thomas Morin > > wrote: >> > >> > I do like LEPS better. >> >> -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Jul 25 05:56:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3B01B282A; Fri, 25 Jul 2014 05:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBw9j_AWSxux; Fri, 25 Jul 2014 05:56:16 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AE91A023F; Fri, 25 Jul 2014 05:56:16 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6PCuA9t000647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jul 2014 07:56:12 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6PCu6L9029667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 14:56:10 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 25 Jul 2014 14:56:07 +0200 From: "Bocci, Matthew (Matthew)" To: Loa Andersson , "Stewart Bryant (stbryant)" , Alia Atlas Thread-Topic: [RTG-DIR] Working group names Thread-Index: AQHPp3/xbRiU7EOKG0qmV/UaOyEqhJuvp/gAgAAKY4CAABSeAIAAHloAgABzaoCAAEKggIAAFHUA Date: Fri, 25 Jul 2014 12:56:06 +0000 Message-ID: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> In-Reply-To: <53D250CB.8020400@pi.nu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ydXmbPkjNR-vmXsQs_6JPP1sCnE Cc: Jeff Haas , "rtg-dir@ietf.org" , Thomas Morin , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 12:56:20 -0000 =8CPlease=B9 is good, but I also like =8CPALS=B9. On 25/07/2014 13:42, "Loa Andersson" wrote: >Folks, > >I thought about "please" also, it is a little bit "begging" but nice. > >/Loa > >On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote: >> Pseudo wire and LDP enabled services=3D please >> >> Stewart >> >> >> >> On 25 Jul 2014, at 02:51, "Alia Atlas" > > wrote: >> >>> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas >> > wrote: >>> >>> Somehow I think that working group participants may object to >>> being called lepers. >>> >>> >>> I won't call them that, if you don't ;-) >>> The group's got some great technology in it that's deployed all over, >>> after all. >>> >>> Alia >>> >>> >>> Jeff >>> >>> > On Jul 24, 2014, at 18:48, Thomas Morin >> > wrote: >>> > >>> > I do like LEPS better. >>> >>> > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > From nobody Fri Jul 25 06:02:31 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD111A028A; Fri, 25 Jul 2014 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_pk2DDaxSw0; Fri, 25 Jul 2014 06:02:26 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB4B1A010C; Fri, 25 Jul 2014 06:02:26 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s6PD2NHe006487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jul 2014 08:02:24 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6PD1e92005801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 15:02:22 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 25 Jul 2014 15:01:35 +0200 From: "Bocci, Matthew (Matthew)" To: "Bocci, Matthew (Matthew)" , "Loa Andersson" , "Stewart Bryant (stbryant)" , "Alia Atlas" Thread-Topic: [RTG-DIR] Working group names Thread-Index: AQHPp3/xbRiU7EOKG0qmV/UaOyEqhJuvp/gAgAAKY4CAABSeAIAAHloAgABzaoCAAEKggIAAFHUAgAABhwA= Date: Fri, 25 Jul 2014 13:01:34 +0000 Message-ID: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/n5uQFDJZ3mzod-WClecPY6ayVhg Cc: Jeff Haas , "rtg-dir@ietf.org" , Thomas Morin , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:02:30 -0000 QWxsDQoNClNvbWV0aGluZyBzdHJhbmdlIGhhcHBlbmVkIHRvIHRoYXQgZW1haWwuDQoNCkkgbWVh bnQgdG8gc2F5IHRoYXQgSSBsaWtlIFBsZWFzZSwgYnV0IEkgYWxzbyBsaWtlIFBhbHMuDQoNClJl Z2FyZHMNCg0KTWF0dGhldw0KDQoNCk9uIDI1LzA3LzIwMTQgMTM6NTYsICJCb2NjaSwgTWF0dGhl dyAoTWF0dGhldykiDQo8bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0K DQo+xZJQbGVhc2XCuSBpcyBnb29kLCBidXQgSSBhbHNvIGxpa2UgxZJQQUxTwrkuDQo+DQo+DQo+ DQo+T24gMjUvMDcvMjAxNCAxMzo0MiwgIkxvYSBBbmRlcnNzb24iIDxsb2FAcGkubnU+IHdyb3Rl Og0KPg0KPj5Gb2xrcywNCj4+DQo+PkkgdGhvdWdodCBhYm91dCAicGxlYXNlIiBhbHNvLCBpdCBp cyBhIGxpdHRsZSBiaXQgImJlZ2dpbmciIGJ1dCBuaWNlLg0KPj4NCj4+L0xvYQ0KPj4NCj4+T24g MjAxNC0wNy0yNSAxMDo0NCwgU3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KSB3cm90ZToNCj4+PiBQ c2V1ZG8gd2lyZSBhbmQgTERQIGVuYWJsZWQgc2VydmljZXM9IHBsZWFzZQ0KPj4+DQo+Pj4gU3Rl d2FydA0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIDI1IEp1bCAyMDE0LCBhdCAwMjo1MSwgIkFsaWEg QXRsYXMiIDxha2F0bGFzQGdtYWlsLmNvbQ0KPj4+IDxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+ PiB3cm90ZToNCj4+Pg0KPj4+PiBPbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCA4OjAyIFBNLCBKZWZm IEhhYXMgPGpoYWFzQHBmcmMub3JnDQo+Pj4+IDxtYWlsdG86amhhYXNAcGZyYy5vcmc+PiB3cm90 ZToNCj4+Pj4NCj4+Pj4gICAgIFNvbWVob3cgSSB0aGluayB0aGF0IHdvcmtpbmcgZ3JvdXAgcGFy dGljaXBhbnRzIG1heSBvYmplY3QgdG8NCj4+Pj4gICAgIGJlaW5nIGNhbGxlZCBsZXBlcnMuDQo+ Pj4+DQo+Pj4+DQo+Pj4+IEkgd29uJ3QgY2FsbCB0aGVtIHRoYXQsIGlmIHlvdSBkb24ndCA7LSkN Cj4+Pj4gVGhlIGdyb3VwJ3MgZ290IHNvbWUgZ3JlYXQgdGVjaG5vbG9neSBpbiBpdCB0aGF0J3Mg ZGVwbG95ZWQgYWxsIG92ZXIsDQo+Pj4+IGFmdGVyIGFsbC4NCj4+Pj4NCj4+Pj4gQWxpYQ0KPj4+ Pg0KPj4+Pg0KPj4+PiAgICAgSmVmZg0KPj4+Pg0KPj4+PiAgICAgPiBPbiBKdWwgMjQsIDIwMTQs IGF0IDE4OjQ4LCBUaG9tYXMgTW9yaW4gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tDQo+Pj4+ICAg ICA8bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+Pj4+ICAgICA+DQo+ Pj4+ICAgICA+IEkgZG8gbGlrZSBMRVBTIGJldHRlci4NCj4+Pj4NCj4+Pj4NCj4+DQo+Pi0tIA0K Pj4NCj4+DQo+PkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9h QG1haWwwMS5odWF3ZWkuY29tDQo+PlNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAg ICAgICAgICAgbG9hQHBpLm51DQo+Pkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAg ICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPj4NCj4NCg0K From nobody Fri Jul 25 06:04:31 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08881A028A; Fri, 25 Jul 2014 06:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i98l6-qClJQC; Fri, 25 Jul 2014 06:04:28 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733D41A010C; Fri, 25 Jul 2014 06:04:28 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so5009706qgf.17 for ; Fri, 25 Jul 2014 06:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rjPzRH4y9/ymGrCJ2ay7t2lDnudRwSU75HAG1seSIUI=; b=xQlMxyfupWjPnCTnEl7tfyA2PuqTxvb1K7FzoOrstrTNu2K6/o+6jTQq2OBBmZAJ8M mwYBKDH5nfar7qK5De9dS0nqqDBCPR1wzxW3FEJ/XSQoSGfWQPvDSHHLXDHwierPrZyJ JNw7Ym26NDBnz8A/0U5Baxn5GM9DVL+1MbPxp7isrQoh/6/PO5dEmU71rF8r4g6kIL+b F5NbM9hT8oLw99jIM9TNyLsH36bh7EhBRCNkrIKTQnsjOcup309R6LM8Z9WPDj7F2JtB ONErKfzSBoC8EM70miRLHeI9enmmHWv11w+lo7Egeg88kvtmyfC9pZLSG55x4wcVu+0U DYFw== X-Received: by 10.224.65.134 with SMTP id j6mr27220192qai.90.1406293467555; Fri, 25 Jul 2014 06:04:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.22 with HTTP; Fri, 25 Jul 2014 06:04:06 -0700 (PDT) In-Reply-To: References: <53D16FE5.3080903@orange.com> From: "Andrew G. Malis" Date: Fri, 25 Jul 2014 09:04:06 -0400 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11c2c9a4957bf904ff0436ea Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/FAjc-36l-f_Np_6uqCzst_t_cV0 Cc: "rtg-dir@ietf.org" , Thomas Morin , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:04:30 -0000 --001a11c2c9a4957bf904ff0436ea Content-Type: text/plain; charset=UTF-8 Alia, Since we already have BESS, I really don't mind LESS to go along with that, after all, less is more! Cheers, Andy On Thu, Jul 24, 2014 at 6:11 PM, Alia Atlas wrote: > I assume this is an objection to LES as a WG name? > I have a few concerns myself about the potential and inaccurate jokes. > We could make it LDP-Enabled Pseudowire-based Services (LEPS) instead? > I hope you have a better naming suggestion. > > Alia > > > On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin > wrote: > >> Adrian, Alia, >> >> Just one little tiny thing: I would personally love it if we can avoid >> 3-letter acronyms, often colliding all over the place, and have at least 4 >> letters in the working group nicknames. >> >> We can have a quantitative metric to measure success (e.g. number of >> working group with 3 letters or less). >> So, that's a low hanging fruit. >> You can't say no. >> >> -Thomas >> >> > --001a11c2c9a4957bf904ff0436ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alia,

Since we already have BESS, I rea= lly don't mind LESS to go along with that, after all, less is more!

Cheers,
Andy


On Thu, Jul 24, 2014 at 6:11 PM, Alia At= las <akatlas@gmail.com> wrote:
I assume this is an objection to LES as a WG name?
I h= ave a few concerns myself about the potential and inaccurate jokes.
We could make it LDP-Enabled Pseudowire-based Services =C2=A0(LEPS) inst= ead?
I hope you have a better naming suggestion.

Alia

On Thu, Jul 24, 2014 at 4:43 PM, Thomas Morin <thomas.morin@orange.c= om> wrote:
Adrian, Alia,

Just one little tiny thing: I would personally love it if we can avoid 3-le= tter acronyms, often colliding all over the place, and have at least 4 lett= ers in the working group nicknames.

We can have a quantitative metric to measure success (e.g. number of workin= g group with 3 letters or less).
So, that's a low hanging fruit.
You can't say no.

-Thomas



--001a11c2c9a4957bf904ff0436ea-- From nobody Fri Jul 25 06:06:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0F71A013B; Fri, 25 Jul 2014 06:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYD9Yuy3mbg7; Fri, 25 Jul 2014 06:06:41 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6001A0294; Fri, 25 Jul 2014 06:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1820; q=dns/txt; s=iport; t=1406293600; x=1407503200; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vufoizvTKiJ7um727uW4oWJ5t6qn+nQjQYdGoAUJAaE=; b=B6Z0H8Esjm4PL70uYNiOgNWmsASGH99NJ+X3QY5NrMb8WI/rfpqXCFGf u1Bct1e7gUDaGcb0C+FzyCJN/KeVx4Gg22cXjW4ru5GpgIXDlEHKMUjw9 K7Owah2QgD90mkiZog6yIbFjFTjtSREjszW5wt4MnENygq8hdzK69oh1t s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAIxV0lOtJV2P/2dsb2JhbABZgw6BKbEpoCABgQ4Wd4QDAQEBAwFrDgUJAgIBCBgnBxsGERQRAgQOBYguAwkIuEcNhyAXBIl6gyCBSxEBHTMHgy6BGwWOV4ptggOOKIYig0hsgQw X-IronPort-AV: E=Sophos;i="5.01,731,1400025600"; d="scan'208";a="63987932" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 25 Jul 2014 13:06:36 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6PD6arI000704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 13:06:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 08:06:35 -0500 From: "Stewart Bryant (stbryant)" To: "Bocci, Matthew (Matthew)" Thread-Topic: [RTG-DIR] Working group names Thread-Index: AQHPp3/1AQIpy6soLkyLHumcCDlol5uwHVAAgAAKZICAABSdAIAAHloAgAAfmRSAAJZygIAAA7QAgAABhwD//62Vlw== Date: Fri, 25 Jul 2014 13:06:35 +0000 Message-ID: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/RULkJhoKAxwTe_Yr6wJsmY0SuYo Cc: "rtg-dir@ietf.org" , Alia Atlas , "rtg-chairs@ietf.org" , Jeff Haas , Thomas Morin , Loa Andersson Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:06:44 -0000 Pals also works. S Sent from my iPad > On 25 Jul 2014, at 14:02, "Bocci, Matthew (Matthew)" wrote: >=20 > All >=20 > Something strange happened to that email. >=20 > I meant to say that I like Please, but I also like Pals. >=20 > Regards >=20 > Matthew >=20 >=20 > On 25/07/2014 13:56, "Bocci, Matthew (Matthew)" > wrote: >=20 >> =8CPlease=B9 is good, but I also like =8CPALS=B9. >>=20 >>=20 >>=20 >>> On 25/07/2014 13:42, "Loa Andersson" wrote: >>>=20 >>> Folks, >>>=20 >>> I thought about "please" also, it is a little bit "begging" but nice. >>>=20 >>> /Loa >>>=20 >>>> On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote: >>>> Pseudo wire and LDP enabled services=3D please >>>>=20 >>>> Stewart >>>>=20 >>>>=20 >>>>=20 >>>> On 25 Jul 2014, at 02:51, "Alia Atlas" >>> > wrote: >>>>=20 >>>>> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas >>>> > wrote: >>>>>=20 >>>>> Somehow I think that working group participants may object to >>>>> being called lepers. >>>>>=20 >>>>>=20 >>>>> I won't call them that, if you don't ;-) >>>>> The group's got some great technology in it that's deployed all over, >>>>> after all. >>>>>=20 >>>>> Alia >>>>>=20 >>>>>=20 >>>>> Jeff >>>>>=20 >>>>>>> On Jul 24, 2014, at 18:48, Thomas Morin >>>>> > wrote: >>>>>>=20 >>>>>> I do like LEPS better. >>>=20 >>> --=20 >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 From nobody Fri Jul 25 06:33:00 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464661B2841; Fri, 25 Jul 2014 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.952 X-Spam-Level: X-Spam-Status: No, score=-95.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URHIAxOx9VFe; Fri, 25 Jul 2014 06:26:55 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5361A0278; Fri, 25 Jul 2014 06:26:55 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 Jul 2014 22:26:51 +0900 Received: from SMTP2.etri.info ([169.254.2.160]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Fri, 25 Jul 2014 22:26:50 +0900 From: =?ks_c_5601-1987?B?t/nBpLW/?= To: Lou Berger Thread-Topic: =?ks_c_5601-1987?B?W21wbHNdIMi4vcU6IFtSVEctRElSXSAgUnRnRGlyIHJldmlldzog?= =?ks_c_5601-1987?Q?draft-ietf-mpls-smp-requirements-06.txt?= Thread-Index: AQHPp/5n6aVNhxcwpkevL5SCbROCbJuwxtNM Date: Fri, 25 Jul 2014 13:26:50 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A2874D504@SMTP2.etri.info> References: <53A5ABED.9080408@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28748144@SMTP2.etri.info>, <53B8190E.6080505@labn.net> <5B4A6CBE3924BB41A3BEE462A8E0B75A28749702@SMTP2.etri.info> <53BE7F3B.9010005@labn.net>,<53D2440B.5030503@labn.net> In-Reply-To: <53D2440B.5030503@labn.net> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.26.37] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/6X7Kemq7sFT6Oj8ea9TyUUg8SfA X-Mailman-Approved-At: Fri, 25 Jul 2014 06:32:57 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-smp-requirements.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] =?euc-kr?b?yLi9xTogW21wbHNdIMi4vcU6ICAgUnRnRGlyIHJldmll?= =?euc-kr?q?w=3A_draft-ietf-mpls-smp-requirements-06=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:26:57 -0000 TG91LA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4NCkFzIHlvdSBzdWdnZXN0ZWQsIFJGQyA2 MzcyIGlzIGFkZGVkIGluIFNlY3Rpb24gNS4yIA0KYW5kIHRoZSBzZW50ZW5jZSBvbiBiaWRpcmVj dGlvbmFsIHN3aXRjaGluZyBpcyBtb3ZlZCB0byBTZWN0aW9uIDUuNy4NCg0KSSBhbSB1cGxvYWRp bmcgYSByZXZpc2lvbi4NCg0KQWdhaW4sIHRoYW5rcyBmb3IgeW91ciB0aG9yb2doIHJldmlldy4N Cg0KQmVzdCByZWdhcmRzLA0KDQpKZW9uZy1kb25nDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCrq4s70gu+e29zogTG91IEJlcmdlciBbbGJlcmdlckBs YWJuLm5ldF0NCrq4s70gs6/CpTogMjAxNLPiIDe/+SAyNcDPILHdv+TAzyC/wMjEIDg6NDgNCrne tMIgu+e29zogt/nBpLW/DQrC/MG2OiBydGctZGlyQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBk cmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1h ZHNAdG9vbHMuaWV0Zi5vcmcNCsGmuPE6IFJlOiBbbXBsc10gyLi9xTogW1JURy1ESVJdICBSdGdE aXIgcmV2aWV3OiBkcmFmdC1pZXRmLW1wbHMtc21wLXJlcXVpcmVtZW50cy0wNi50eHQNCg0KSmVv bmcsDQogICAgSSB0aGluayB0aGUgZG9jdW1lbnQgbG9va3MgZ29vZC4gIFR3byAqbWlub3IqIGNv bW1lbnRzIG9uIHRoZSBsYXRlc3QNCnJldjoNCg0KT24gNy8xMC8yMDE0IDc6NTUgQU0sIExvdSBC ZXJnZXIgd3JvdGU6DQo+PiA+IC0gSW4gc2VjdGlvbiA0IGFuZCA1LjIgeW91IHJlZmVyZW5jZSA1 NzEyIGFuZCAzMjA5IGFzIGRlZmluaW5nDQo+PiA+IHByZWVtcHRpb24gdGVybWlub2xvZ3kgYW5k IGJlaGF2aW9yLiBJIHRoaW5rIDYzNzIgaXMgdGhlIHJpZ2h0DQo+PiA+IHJlZmVyZW5jZSBoZXJl IGFzIGl0IGRlZmluZXMgYm90aCBpbiB0aGUgY29udGV4dCBvZiBzdXJ2aXZhYmlsaXR5IGFuZA0K Pj4gPiBpbiBkZXBlbmRlbnQgb2YgY29udHJvbCBwbGFuZS4NCj4+ID4gW0F1dGhvcnNdIE9uZSBj b25jZXJuIGlzIHRoYXQgUkZDIDYzNzIgZGVzY3JpYmVzIGJvdGggc29mdCBhbmQgaGFyZA0KPiBw cmVlbXB0aW9ucyBpbiB0aGUgY29udGV4dCBvZiBleHRyYSB0cmFmZmljLCB3aGljaCBpcyBub3Qg ZXhhY3RseSB0aGUNCj4gY2FzZSBmb3IgU01QLg0KPj4gPg0KPj4gPiBUaGVuIDYzNzIgc2hvdWxk IGJlIHJlZmVyZW5jZWQgYW5kIHRoZSBkaWZmZXJlbmNlIHNob3VsZCBiZSBkZXNjcmliZWQuDQo+ ICBPdGhlcndpc2UgcmVhZGVycyBhcmUgbGlrZWx5IHRvIHRoaW5rIHlvdSBqdXN0IHVzZWQgdGhl IHdyb25nIHJlZmVyZW5jZQ0KPiBhbmQgdGhhdCA2MzcyJ3MgdGV4dCBhcHBsaWVzLiAgNjM3MiBp cyBhZnRlciBhbGwgdGl0bGVkICJNUExTLVRQDQo+IFN1cnZpdmFiaWxpdHkgRnJhbWV3b3JrIi4u Lg0KPj4gPg0KPj4gPiBbSlJdIE8uSy4gNjM3MiB3aWxsIGJlIHJlZmVyZW5jZWQgYW5kIHdlIGNh biBhZGQgdGhlIGZvbGxvd2luZw0KPiBzZW50ZW5jZSBhcyB0aGUgdGhpcmQgc2VudGVuY2UgaW4g dGhlIHBhcmFncmFwaDogobBUaGUgdHJhZmZpYyBvZiBsb3dlcg0KPiBwcmlvcml0eSBwYXRocyBp biB0aGlzIGRvY3VtZW50IGNhbiBiZSB2aWV3ZWQgYXMgdGhlIGV4dHJhIHRyYWZmaWMgYmVpbmcN Cj4gcHJlZW1wdGVkIGluIFtSRkM2MzcyXS6hsQ0KDQpTZWN0aW9uIDQgbG9va3MgZ29vZCwgYnV0 IHRoZSByZWZlcmVuY2UgaXMgbWlzc2luZyBmcm9tIGluIDUuMi4NCg0KPiAgICBCaWRpcmVjdGlv bmFsIHByb3RlY3Rpb24gc3dpdGNoaW5nIFNIT1VMRCBiZSBzdXBwb3J0ZWQgaW4gU01QLg0KDQpU aGlzIGlzIHJlYWxseSBpbiB0aGUgd3Jvbmcgc2VjdGlvbi4gIGJpZGlyZWN0aW9uYWwgUFMgaGFz IG5vdGhpbmcgdG8gZG8NCndpdGggcmV2ZXJzaW9uLiAgQXMgYmVmb3JlLCBJIHRoaW5rIHNlY3Rp b24gNS43IGlzIHRoZSBiZXN0IHBsYWNlIGZvciBpdC4NCg0KTG91DQoNCg== From nobody Fri Jul 25 06:45:06 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609191B2883; Fri, 25 Jul 2014 06:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXJ54cWWZoyi; Fri, 25 Jul 2014 06:44:56 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9729B1B28A8; Fri, 25 Jul 2014 06:44:43 -0700 (PDT) Received: from AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) by AM3PR03MB564.eurprd03.prod.outlook.com (10.242.111.155) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 25 Jul 2014 13:44:41 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 25 Jul 2014 13:44:40 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Fri, 25 Jul 2014 13:44:40 +0000 From: Alexander Vainshtein To: "Stewart Bryant (stbryant)" , "Bocci, Matthew (Matthew)" Thread-Topic: [RTG-DIR] Working group names Thread-Index: AQHPqA6URyj7vz48N0CupHc6NcJRrw== Date: Fri, 25 Jul 2014 13:44:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.253.158.25] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(51444003)(51704005)(24454002)(199002)(189002)(479174003)(377454003)(252514010)(377424004)(79102001)(106356001)(80022001)(19580395003)(95666004)(85852003)(86362001)(101416001)(77982001)(66066001)(107046002)(46102001)(85306003)(4396001)(19580405001)(2656002)(76482001)(87936001)(50986999)(54356999)(74316001)(33646002)(76576001)(83322001)(64706001)(21056001)(83072002)(19625215002)(99396002)(74502001)(106116001)(31966008)(74662001)(92566001)(16236675004)(81542001)(81342001)(105586002)(20776003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_db62ac4297f34b9a8a93469efe492e27AM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/wr25weVNre1U_YDGtQYYxHlMI5s Cc: "rtg-dir@ietf.org" , Alia Atlas , "rtg-chairs@ietf.org" , Jeff Haas , Thomas Morin , Loa Andersson Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:45:02 -0000 --_000_db62ac4297f34b9a8a93469efe492e27AM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UEFMUyBoYXBwZW5zIHRvIGRlbm90ZSBQZWRpYXRyaWMgQWR2YW5jZWQgTGlmZSBTdXBwb3J0Lg0K DQoNCg0KTXkgd2lmZSAod2hvIGlzIGEgcGVkaWF0cmljaWFuKSB3b3VsZCBwcm9iYWJseSBiZSBo YXBweSB0byBhdHRlbmQuLi4NCg0KDQoNClRodW1iIHR5cGVkIG9uIG15IExHLA0KU2FzaGENCg0K LS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tDQpGcm9tOiBTdGV3YXJ0IEJyeWFudCAoc3Ri cnlhbnQpDQpEYXRlOiAyNS8wNy8yMDE0IDE2OjA2DQpUbzogQm9jY2ksIE1hdHRoZXcgKE1hdHRo ZXcpOw0KQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7QWxpYSBBdGxhcztydGctY2hhaXJzQGlldGYub3Jn O0plZmYgSGFhcztUaG9tYXMgTW9yaW47TG9hIEFuZGVyc3NvbjsNClN1YmplY3Q6UmU6IFtSVEct RElSXSBXb3JraW5nIGdyb3VwIG5hbWVzDQoNClBhbHMgYWxzbyB3b3Jrcy4NCg0KUw0KDQpTZW50 IGZyb20gbXkgaVBhZA0KDQo+IE9uIDI1IEp1bCAyMDE0LCBhdCAxNDowMiwgIkJvY2NpLCBNYXR0 aGV3IChNYXR0aGV3KSIgPG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToN Cj4NCj4gQWxsDQo+DQo+IFNvbWV0aGluZyBzdHJhbmdlIGhhcHBlbmVkIHRvIHRoYXQgZW1haWwu DQo+DQo+IEkgbWVhbnQgdG8gc2F5IHRoYXQgSSBsaWtlIFBsZWFzZSwgYnV0IEkgYWxzbyBsaWtl IFBhbHMuDQo+DQo+IFJlZ2FyZHMNCj4NCj4gTWF0dGhldw0KPg0KPg0KPiBPbiAyNS8wNy8yMDE0 IDEzOjU2LCAiQm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpIg0KPiA8bWF0dGhldy5ib2NjaUBhbGNh dGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPg0KPj4gxZJQbGVhc2XCuSBpcyBnb29kLCBidXQgSSBh bHNvIGxpa2UgxZJQQUxTwrkuDQo+Pg0KPj4NCj4+DQo+Pj4gT24gMjUvMDcvMjAxNCAxMzo0Miwg IkxvYSBBbmRlcnNzb24iIDxsb2FAcGkubnU+IHdyb3RlOg0KPj4+DQo+Pj4gRm9sa3MsDQo+Pj4N Cj4+PiBJIHRob3VnaHQgYWJvdXQgInBsZWFzZSIgYWxzbywgaXQgaXMgYSBsaXR0bGUgYml0ICJi ZWdnaW5nIiBidXQgbmljZS4NCj4+Pg0KPj4+IC9Mb2ENCj4+Pg0KPj4+PiBPbiAyMDE0LTA3LTI1 IDEwOjQ0LCBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpIHdyb3RlOg0KPj4+PiBQc2V1ZG8gd2ly ZSBhbmQgTERQIGVuYWJsZWQgc2VydmljZXM9IHBsZWFzZQ0KPj4+Pg0KPj4+PiBTdGV3YXJ0DQo+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDI1IEp1bCAyMDE0LCBhdCAwMjo1MSwgIkFsaWEgQXRs YXMiIDxha2F0bGFzQGdtYWlsLmNvbQ0KPj4+PiA8bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPj4g d3JvdGU6DQo+Pj4+DQo+Pj4+PiBPbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCA4OjAyIFBNLCBKZWZm IEhhYXMgPGpoYWFzQHBmcmMub3JnDQo+Pj4+PiA8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4gd3Jv dGU6DQo+Pj4+Pg0KPj4+Pj4gICAgU29tZWhvdyBJIHRoaW5rIHRoYXQgd29ya2luZyBncm91cCBw YXJ0aWNpcGFudHMgbWF5IG9iamVjdCB0bw0KPj4+Pj4gICAgYmVpbmcgY2FsbGVkIGxlcGVycy4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gSSB3b24ndCBjYWxsIHRoZW0gdGhhdCwgaWYgeW91IGRvbid0 IDstKQ0KPj4+Pj4gVGhlIGdyb3VwJ3MgZ290IHNvbWUgZ3JlYXQgdGVjaG5vbG9neSBpbiBpdCB0 aGF0J3MgZGVwbG95ZWQgYWxsIG92ZXIsDQo+Pj4+PiBhZnRlciBhbGwuDQo+Pj4+Pg0KPj4+Pj4g QWxpYQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgICBKZWZmDQo+Pj4+Pg0KPj4+Pj4+PiBPbiBKdWwg MjQsIDIwMTQsIGF0IDE4OjQ4LCBUaG9tYXMgTW9yaW4gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29t DQo+Pj4+Pj4gICAgPG1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4+IHdyb3RlOg0KPj4+ Pj4+DQo+Pj4+Pj4gSSBkbyBsaWtlIExFUFMgYmV0dGVyLg0KPj4+DQo+Pj4gLS0NCj4+Pg0KPj4+ DQo+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFp bDAxLmh1YXdlaS5jb20NCj4+PiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAg ICAgICAgIGxvYUBwaS5udQ0KPj4+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAg ICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPg0KDQo= --_000_db62ac4297f34b9a8a93469efe492e27AM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8c3R5bGU+PCEtLSAuRW1haWxRdW90ZSB7 IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3JkZXItbGVmdDogIzgwMDAw MCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5Pg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206 MDsiPlBBTFMgaGFwcGVucyB0byBkZW5vdGUgUGVkaWF0cmljIEFkdmFuY2VkIExpZmUgU3VwcG9y dC48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowOyI+TXkgd2lmZSAod2hv IGlzIGEgcGVkaWF0cmljaWFuKSB3b3VsZCBwcm9iYWJseSBiZSBoYXBweSB0byBhdHRlbmQuLi48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPiZuYnNwOzwvcD4N CjxkZXYzX2pqeT5UaHVtYiB0eXBlZCBvbiBteSBMRyw8YnI+DQpTYXNoYTwvZGV2M19qank+PGJy Pg0KPGJyPg0KLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tPGJyPg0KPGI+RnJvbTombmJz cDs8L2I+U3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KTxzdGJyeWFudEBjaXNjby5jb20+PGJyPg0K PGI+RGF0ZTombmJzcDs8L2I+MjUvMDcvMjAxNCAxNjowNjxicj4NCjxiPlRvOiZuYnNwOzwvYj5C b2NjaSwgTWF0dGhldyAoTWF0dGhldyk7PGJyPg0KPGI+Q2M6Jm5ic3A7PC9iPnJ0Zy1kaXJAaWV0 Zi5vcmc7QWxpYSBBdGxhcztydGctY2hhaXJzQGlldGYub3JnO0plZmYgSGFhcztUaG9tYXMgTW9y aW47TG9hIEFuZGVyc3Nvbjs8YnI+DQo8Yj5TdWJqZWN0OjwvYj5SZTogW1JURy1ESVJdIFdvcmtp bmcgZ3JvdXAgbmFtZXM8YnI+DQo8YnI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQgLS0+PGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPlBhbHMgYWxzbyB3b3Jrcy48YnI+DQo8YnI+DQpTPGJyPg0KPGJyPg0KU2VudCBm cm9tIG15IGlQYWQ8YnI+DQo8YnI+DQomZ3Q7IE9uIDI1IEp1bCAyMDE0LCBhdCAxNDowMiwgJnF1 b3Q7Qm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpJnF1b3Q7ICZsdDttYXR0aGV3LmJvY2NpQGFsY2F0 ZWwtbHVjZW50LmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsbDxicj4NCiZn dDsgPGJyPg0KJmd0OyBTb21ldGhpbmcgc3RyYW5nZSBoYXBwZW5lZCB0byB0aGF0IGVtYWlsLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBJIG1lYW50IHRvIHNheSB0aGF0IEkgbGlrZSBQbGVhc2UsIGJ1 dCBJIGFsc28gbGlrZSBQYWxzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IE1hdHRoZXc8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiAy NS8wNy8yMDE0IDEzOjU2LCAmcXVvdDtCb2NjaSwgTWF0dGhldyAoTWF0dGhldykmcXVvdDs8YnI+ DQomZ3Q7ICZsdDttYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDsgd3JvdGU6PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyDFklBsZWFzZcK5IGlzIGdvb2QsIGJ1dCBJIGFsc28gbGlr ZSDFklBBTFPCuS48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsgT24gMjUvMDcvMjAxNCAxMzo0MiwgJnF1b3Q7TG9hIEFuZGVyc3Nv biZxdW90OyAmbHQ7bG9hQHBpLm51Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7IEZvbGtzLDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsg SSB0aG91Z2h0IGFib3V0ICZxdW90O3BsZWFzZSZxdW90OyBhbHNvLCBpdCBpcyBhIGxpdHRsZSBi aXQgJnF1b3Q7YmVnZ2luZyZxdW90OyBidXQgbmljZS48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7IC9Mb2E8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBPbiAyMDE0LTA3LTI1IDEwOjQ0LCBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpIHdyb3RlOjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgUHNldWRvIHdpcmUgYW5kIExEUCBlbmFibGVkIHNlcnZpY2Vz PSBwbGVhc2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU3Rl d2FydDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT24gMjUgSnVsIDIwMTQsIGF0 IDAyOjUxLCAmcXVvdDtBbGlhIEF0bGFzJnF1b3Q7ICZsdDtha2F0bGFzQGdtYWlsLmNvbTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+ bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gVGh1LCBKdWwgMjQsIDIwMTQg YXQgODowMiBQTSwgSmVmZiBIYWFzICZsdDtqaGFhc0BwZnJjLm9yZzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciPm1haWx0bzpqaGFh c0BwZnJjLm9yZzwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDtTb21laG93IEkgdGhp bmsgdGhhdCB3b3JraW5nIGdyb3VwIHBhcnRpY2lwYW50cyBtYXkgb2JqZWN0IHRvPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7YmVpbmcgY2FsbGVkIGxlcGVycy48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHdvbid0IGNhbGwgdGhlbSB0aGF0LCBpZiB5b3UgZG9u J3QgOy0pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGdyb3VwJ3MgZ290IHNvbWUgZ3Jl YXQgdGVjaG5vbG9neSBpbiBpdCB0aGF0J3MgZGVwbG95ZWQgYWxsIG92ZXIsPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYWZ0ZXIgYWxsLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFsaWE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsm bmJzcDsmbmJzcDtKZWZmPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBKdWwgMjQsIDIwMTQsIGF0IDE4OjQ4LCBUaG9tYXMgTW9y aW4gJmx0O3Rob21hcy5tb3JpbkBvcmFuZ2UuY29tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9y YW5nZS5jb20iPm1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEkgZG8gbGlrZSBMRVBTIGJldHRlci48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyZndDsmZ3Q7IC0tIDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7IExvYSBBbmRlcnNzb24gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW1haWw6 IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxicj4NCiZndDsmZ3Q7Jmd0OyBTZW5pb3IgTVBMUyBFeHBl cnQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bG9hQHBpLm51PGJyPg0KJmd0 OyZndDsmZ3Q7IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3Bob25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NDxicj4NCiZndDsgPGJyPg0KPGJy Pg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_db62ac4297f34b9a8a93469efe492e27AM3PR03MB612eurprd03pro_-- From nobody Fri Jul 25 06:46:26 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6A31B280B; Fri, 25 Jul 2014 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAHAl76b1uAH; Fri, 25 Jul 2014 06:46:23 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C521A02E5; Fri, 25 Jul 2014 06:46:23 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id v1so2931130yhn.13 for ; Fri, 25 Jul 2014 06:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HSC7oGXiC+iWcTrFJ2Ia8yrNgYXGROSbm4TM+LCqvZQ=; b=GddABaLx5oTCxcoTDwk9pzq+7fOAw4Hl2eU0Mvszk+nwXvs4a/PW5IqQ/zgGv+lHKv J7AmelHV+RuivEDtH05gD60K44ONJOzJopgBTqFHhEH4IJe3fHK9y3yzbGT+YKrs/wsb 1y94JMi6IgbJOhR0jHcxNETQDPZBcu6oLhm9/oabFcIaRiVE/vQmdtKy7oxbEpkckRMd aQIJOe6K2nbRh0mJ/mm95y86vKq2AruprpJmbErssqsMzK01kJrJ5O1SBOYc044aRvex X3skCX/zljw4oWzyyaXr1dZe3JYw9VQ4zYxDAzxg1BIz/57dMg0qqNlZFRjuNIrJHZDM 6c5Q== MIME-Version: 1.0 X-Received: by 10.236.134.8 with SMTP id r8mr23038180yhi.153.1406295982754; Fri, 25 Jul 2014 06:46:22 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Fri, 25 Jul 2014 06:46:22 -0700 (PDT) In-Reply-To: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> Date: Fri, 25 Jul 2014 09:46:22 -0400 Message-ID: From: Alia Atlas To: "Stewart Bryant (stbryant)" Content-Type: multipart/alternative; boundary=485b397dcf9180535c04ff04cc23 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/YOIOehynRq2Ge39t68ap-k0_UOQ Cc: "Bocci, Matthew \(Matthew\)" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Jeff Haas , Thomas Morin , Loa Andersson Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:46:25 -0000 --485b397dcf9180535c04ff04cc23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I can see PLES or PLESS (Pseudo-wire LDP-Enabled Services) Getting the A seems like a stretch. May I mention my joy and relaxation that we are reduced to amusing bike-shedding discussions of WG names? Alia On Fri, Jul 25, 2014 at 9:06 AM, Stewart Bryant (stbryant) < stbryant@cisco.com> wrote: > Pals also works. > > S > > Sent from my iPad > > > On 25 Jul 2014, at 14:02, "Bocci, Matthew (Matthew)" < > matthew.bocci@alcatel-lucent.com> wrote: > > > > All > > > > Something strange happened to that email. > > > > I meant to say that I like Please, but I also like Pals. > > > > Regards > > > > Matthew > > > > > > On 25/07/2014 13:56, "Bocci, Matthew (Matthew)" > > wrote: > > > >> =C5=92Please=C2=B9 is good, but I also like =C5=92PALS=C2=B9. > >> > >> > >> > >>> On 25/07/2014 13:42, "Loa Andersson" wrote: > >>> > >>> Folks, > >>> > >>> I thought about "please" also, it is a little bit "begging" but nice. > >>> > >>> /Loa > >>> > >>>> On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote: > >>>> Pseudo wire and LDP enabled services=3D please > >>>> > >>>> Stewart > >>>> > >>>> > >>>> > >>>> On 25 Jul 2014, at 02:51, "Alia Atlas" >>>> > wrote: > >>>> > >>>>> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas >>>>> > wrote: > >>>>> > >>>>> Somehow I think that working group participants may object to > >>>>> being called lepers. > >>>>> > >>>>> > >>>>> I won't call them that, if you don't ;-) > >>>>> The group's got some great technology in it that's deployed all ove= r, > >>>>> after all. > >>>>> > >>>>> Alia > >>>>> > >>>>> > >>>>> Jeff > >>>>> > >>>>>>> On Jul 24, 2014, at 18:48, Thomas Morin >>>>>> > wrote: > >>>>>> > >>>>>> I do like LEPS better. > >>> > >>> -- > >>> > >>> > >>> Loa Andersson email: loa@mail01.huawei.com > >>> Senior MPLS Expert loa@pi.nu > >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --485b397dcf9180535c04ff04cc23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can see
PLES or PLESS (Pseudo-wire LDP-Enabled Servi= ces)=C2=A0

Getting the A seems like a stretch.

May I mention my joy and relaxation that we are reduc= ed to amusing
bike-shedding discussions of WG names?

Alia


On = Fri, Jul 25, 2014 at 9:06 AM, Stewart Bryant (stbryant) &= lt;stbryant@cisco.c= om> wrote:
Pals also works.

S

Sent from my iPad

> On 25 Jul 2014, at 14:02, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-luce= nt.com> wrote:
>
> All
>
> Something strange happened to that email.
>
> I meant to say that I like Please, but I also like Pals.
>
> Regards
>
> Matthew
>
>
> On 25/07/2014 13:56, "Bocci, Matthew (Matthew)"
> <matthew.bocci@= alcatel-lucent.com> wrote:
>
>> =C5=92Please=C2=B9 is good, but I also like =C5=92PALS=C2=B9.
>>
>>
>>
>>> On 25/07/2014 13:42, "Loa Andersson" <loa@pi.nu> wrote:
>>>
>>> Folks,
>>>
>>> I thought about "please" also, it is a little bit &q= uot;begging" but nice.
>>>
>>> /Loa
>>>
>>>> On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote:
>>>> Pseudo wire and LDP enabled services=3D please
>>>>
>>>> Stewart
>>>>
>>>>
>>>>
>>>> On 25 Jul 2014, at 02:51, "Alia Atlas" <akatlas@gmail.com
>>>> <mailto:akatlas@gm= ail.com>> wrote:
>>>>
>>>>> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas <jhaas@pfrc.org
>>>>> <mailto:jhaas@pfr= c.org>> wrote:
>>>>>
>>>>> =C2=A0 =C2=A0Somehow I think that working group partic= ipants may object to
>>>>> =C2=A0 =C2=A0being called lepers.
>>>>>
>>>>>
>>>>> I won't call them that, if you don't ;-)
>>>>> The group's got some great technology in it that&#= 39;s deployed all over,
>>>>> after all.
>>>>>
>>>>> Alia
>>>>>
>>>>>
>>>>> =C2=A0 =C2=A0Jeff
>>>>>
>>>>>>> On Jul 24, 2014, at 18:48, Thomas Morin <thomas.morin@orange.com
>>>>>> =C2=A0 =C2=A0<mailto:thomas.morin@orange.com>> wrote:
>>>>>>
>>>>>> I do like LEPS better.
>>>
>>> --
>>>
>>>
>>> Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
>>> Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
>>> Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 21 64=
>

--485b397dcf9180535c04ff04cc23-- From nobody Fri Jul 25 06:50:20 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0C61B28AA; Fri, 25 Jul 2014 06:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esPq_rFXslCy; Fri, 25 Jul 2014 06:50:17 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1CF1A02E3; Fri, 25 Jul 2014 06:50:10 -0700 (PDT) Received: from [172.16.57.142] (unknown [206.47.221.210]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id ADF471802B19; Fri, 25 Jul 2014 15:50:07 +0200 (CEST) Message-ID: <53D26099.7010601@pi.nu> Date: Fri, 25 Jul 2014 15:50:17 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas , "Stewart Bryant (stbryant)" References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/xhNje2NVRdRe3jvCFswnUcpfU2E Cc: Jeff Haas , "Bocci, Matthew \(Matthew\)" , Thomas Morin , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:50:18 -0000 Alia, What is wrong stretching :), after all it is a name and not necessary an abbreviation. /Loa On 2014-07-25 15:46, Alia Atlas wrote: > I can see > PLES or PLESS (Pseudo-wire LDP-Enabled Services) > > Getting the A seems like a stretch. > > May I mention my joy and relaxation that we are reduced to amusing > bike-shedding discussions of WG names? > > Alia > > > On Fri, Jul 25, 2014 at 9:06 AM, Stewart Bryant (stbryant) > > wrote: > > Pals also works. > > S > > Sent from my iPad > > > On 25 Jul 2014, at 14:02, "Bocci, Matthew (Matthew)" > > wrote: > > > > All > > > > Something strange happened to that email. > > > > I meant to say that I like Please, but I also like Pals. > > > > Regards > > > > Matthew > > > > > > On 25/07/2014 13:56, "Bocci, Matthew (Matthew)" > > > wrote: > > > >> ŒPlease¹ is good, but I also like ŒPALS¹. > >> > >> > >> > >>> On 25/07/2014 13:42, "Loa Andersson" > wrote: > >>> > >>> Folks, > >>> > >>> I thought about "please" also, it is a little bit "begging" but > nice. > >>> > >>> /Loa > >>> > >>>> On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote: > >>>> Pseudo wire and LDP enabled services= please > >>>> > >>>> Stewart > >>>> > >>>> > >>>> > >>>> On 25 Jul 2014, at 02:51, "Alia Atlas" > >>>> >> wrote: > >>>> > >>>>> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas > >>>>> >> wrote: > >>>>> > >>>>> Somehow I think that working group participants may object to > >>>>> being called lepers. > >>>>> > >>>>> > >>>>> I won't call them that, if you don't ;-) > >>>>> The group's got some great technology in it that's deployed > all over, > >>>>> after all. > >>>>> > >>>>> Alia > >>>>> > >>>>> > >>>>> Jeff > >>>>> > >>>>>>> On Jul 24, 2014, at 18:48, Thomas Morin > > >>>>>> >> wrote: > >>>>>> > >>>>>> I do like LEPS better. > >>> > >>> -- > >>> > >>> > >>> Loa Andersson email: > loa@mail01.huawei.com > >>> Senior MPLS Expert loa@pi.nu > >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Jul 25 07:29:14 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E681A0328 for ; Fri, 25 Jul 2014 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cASlg0j-Y0_7 for ; Fri, 25 Jul 2014 07:29:10 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id B51741A02CF for ; Fri, 25 Jul 2014 07:29:10 -0700 (PDT) Received: (qmail 25087 invoked by uid 0); 25 Jul 2014 14:29:10 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 25 Jul 2014 14:29:10 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id WkV51o00q2SSUrH01kV8Wy; Fri, 25 Jul 2014 14:29:08 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=WrhVjQHxoPwA:10 a=g5P8IWEH2eQA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=OUFSQUHnWscs1CfKbmAA:9 a=QEXdDO2ut3YA:10 a=-RtFPPzVYDYA:10 a=eAyaW0B_bOEA:10 a=ThGsz3vOAFMA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Kb7HDZGHe0qHAbXKxgX9HS+RtUV4H+BKPw3BDTFwVzk=; b=2chDGREnaUMFC6nPSV9qPeHS5nh0xJSu0cK636/Zsolh6o7UQ1c2xKirAjskfJZtHj8kWyrJXPcO3FQPW6PjX4sN4M74rzCphMXgklr93/owfZGuXlKb61/jFMU2QTX1; Received: from box313.bluehost.com ([69.89.31.113]:35454 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XAgUd-00029a-6W; Fri, 25 Jul 2014 08:29:07 -0600 Message-ID: <53D269C2.8090906@labn.net> Date: Fri, 25 Jul 2014 10:29:22 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/oxiyRJDY2lrNNsRyASgTCtDbflc Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:29:11 -0000 On 7/25/2014 9:46 AM, Alia Atlas wrote: > May I mention my joy and relaxation that we are reduced to amusing > bike-shedding discussions of WG names? > Alia, I'm not sure what other kind of discussion you are expecting at this point. Personally, I'm in a holding pattern -- waiting for you/Adrian to let me know the details of how you want to proceed on new/revised charter drafting... Lou From nobody Fri Jul 25 07:55:42 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3321B29BC; Fri, 25 Jul 2014 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8typNoO4ZmV; Fri, 25 Jul 2014 07:55:36 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4007F1B29BB; Fri, 25 Jul 2014 07:55:36 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id 29so2957398yhl.30 for ; Fri, 25 Jul 2014 07:55: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:date:message-id:subject:from:to :cc:content-type; bh=bESxNaVPshv/0YRbNOCC1CTLCswQwcbUlVdLJaGxTWw=; b=LvJufje1GTju5dE67goKn974u+00uDFRkO1J+FW6mhPC84QGGUmijdkHjnHYSgKKfW nuP/6WYqZEUnvaLI/BoXiwIhjOEWnlBu7I4uuXlb8Jfn5swS14D8HHBrsN1JGiBXaTGv lXfUFRgVyM4xabTuE2p3JzXWnhmr+6VgG38yRnAvqe7tylzrs204At153zYrqSLhU7I4 iVVg7HVmY3QGaeDped+uwu8HWbnmPts/XhrqyCshbW3bHqRFJ/c1Qz6zcJ4HiffpC80G gHihKmwIM3l5gWukCt6Ek/DwEIApFTLk6QodsTu5XLqujySsSrUI4PvGgpOAQEffe7+z 9HXw== MIME-Version: 1.0 X-Received: by 10.236.208.2 with SMTP id p2mr5016811yho.173.1406300135597; Fri, 25 Jul 2014 07:55:35 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Fri, 25 Jul 2014 07:55:35 -0700 (PDT) In-Reply-To: <53D269C2.8090906@labn.net> References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> <53D269C2.8090906@labn.net> Date: Fri, 25 Jul 2014 10:55:35 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c1c7f607adcc04ff05c4d0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/qutqRgqIbNZerFgK9kTWlSmG7Nw Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:55:38 -0000 --001a11c1c7f607adcc04ff05c4d0 Content-Type: text/plain; charset=UTF-8 Lou, Adrian and I are talking later today to work on nailing down details. Alia On Fri, Jul 25, 2014 at 10:29 AM, Lou Berger wrote: > > On 7/25/2014 9:46 AM, Alia Atlas wrote: > > May I mention my joy and relaxation that we are reduced to amusing > > bike-shedding discussions of WG names? > > > > Alia, > I'm not sure what other kind of discussion you are expecting at this > point. > > Personally, I'm in a holding pattern -- waiting for you/Adrian to let me > know the details of how you want to proceed on new/revised charter > drafting... > > Lou > > --001a11c1c7f607adcc04ff05c4d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lou,=

Adria= n and I are talking later today to work on nailing down details.

Alia
<= br>
On Fri, Jul 25, 2014 at 10:29 AM, Lou B= erger <lberger@labn.net> wrote:

On 7/25/2014 9:46 AM, Alia Atlas wrote:
> May I mention my joy and relaxation that we are reduced to amusing
> bike-shedding discussions of WG names?
>

Alia,
=C2=A0 =C2=A0 I'm not sure what other kind of discussion you are expect= ing at this
point.

Personally, I'm in a holding pattern -- waiting for you/Adrian to let m= e
know the details of =C2=A0how you want to proceed on new/revised charter drafting...

Lou


--001a11c1c7f607adcc04ff05c4d0-- From nobody Fri Jul 25 08:24:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA601B27D8 for ; Fri, 25 Jul 2014 08:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5BfJcW8Ij5g for ; Fri, 25 Jul 2014 08:24:19 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 5D0891A0318 for ; Fri, 25 Jul 2014 08:24:19 -0700 (PDT) Received: (qmail 28326 invoked by uid 0); 25 Jul 2014 15:24:19 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 25 Jul 2014 15:24:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id WfQ81o00o2SSUrH01fQB65; Fri, 25 Jul 2014 09:24:19 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Mp07CAuinD0A:10 a=g5P8IWEH2eQA:10 a=HFCU6gKsb0MA:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=SWaWCKL8q04A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=pGLkceISAAAA:8 a=iH12AfMcR0QZVZ2iW8sA:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=33rK67OTR_gA:10 a=OUFSQUHnWscs1CfKbmAA:9 a=Ved31MRfLU74NYOx:21 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=bnCxFinX6UL+Xcw1prwZxvOTGTYRijk7eA8iSTKwn84=; b=MW+xVaj/y0K0ALaclo2koEzPCazX7DdCZR3J0B6goycQancj0rmwqJEZVfWyP2fD6bL0J/H5YsI+Idt7AJNPKWHi29oXPS4VjggKM0pZdkCRDzA4hVuYvFaPzU1qaQxy; Received: from [31.133.148.228] (port=60125) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAhLs-0001jR-Df; Fri, 25 Jul 2014 09:24:08 -0600 From: Lou Berger To: Alia Atlas Date: Fri, 25 Jul 2014 11:24:07 -0400 Message-ID: <1476e1f3220.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> <53D269C2.8090906@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.4.0.30 (build: 2100451) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------1476e1f4059171027e942b6a0f0" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 31.133.148.228 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/TOgYZtlnAW7wCDM3Mnl8ugJDBD8 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:24:20 -0000 This is a multi-part message in MIME format. ------------1476e1f4059171027e942b6a0f0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Great. On July 25, 2014 10:56:37 AM Alia Atlas wrote: > Lou, > > Adrian and I are talking later today to work on nailing down details. > > Alia > > On Fri, Jul 25, 2014 at 10:29 AM, Lou Berger wrote: > > > > > On 7/25/2014 9:46 AM, Alia Atlas wrote: > > > May I mention my joy and relaxation that we are reduced to amusing > > > bike-shedding discussions of WG names? > > > > > > > Alia, > > I'm not sure what other kind of discussion you are expecting at this > > point. > > > > Personally, I'm in a holding pattern -- waiting for you/Adrian to let me > > know the details of how you want to proceed on new/revised charter > > drafting... > > > > Lou > > > > ------------1476e1f4059171027e942b6a0f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Great.

On July 25, 2014 10:56:37 AM Alia Atlas <akatlas@gmail.com> wrote:

Lou,

Adrian and I are talking later today to work on nailing down details.

Alia

On Fri, Jul 25, 2014 at 10:29 AM, Lou Berger <lberger@labn.net> wrote:

On 7/25/2014 9:46 AM, Alia Atlas wrote:
> May I mention my joy and relaxation that we are reduced to amusing
> bike-shedding discussions of WG names?
>

Alia,
    I'm not sure what other kind of discussion you are expecting at this
point.

Personally, I'm in a holding pattern -- waiting for you/Adrian to let me
know the details of  how you want to proceed on new/revised charter
drafting...

Lou


------------1476e1f4059171027e942b6a0f0-- From nobody Fri Jul 25 16:39:42 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7ED1A0522; Fri, 25 Jul 2014 16:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzwgpKb20HYm; Fri, 25 Jul 2014 16:39:38 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6DD1A04B7; Fri, 25 Jul 2014 16:39:38 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id q200so3216836ykb.26 for ; Fri, 25 Jul 2014 16:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZLrVixYeEmZTMkQmv9RX030pXEvlIPCLX3sNzFe3E+0=; b=AFgXlnXfVCkwp0Bh36QaHlGgx5S5SkkXmaebgPxouP0QPHbLwnsKGwbZ5umxqGS4V+ Cid/A3FgtLfGeWq1fk6Rl5LVsRDVKekhfrs9VWdYI6QlyqtlgX4ABUWuJchWEv/2PP9i GtNJP3zuHMMXI3UqdGC4SIfl7QsXGcA49kRGP2nkyc5g0AewXoSOHbZKnyHCtWbLDUjo +26jBPEQzrK03f8vyjsUdRsJ1UdtIqgApnS6Kgkh/RnmUKQTcVSbcLthYMO7UpL/jEQW gWQrgfNlbRhr9AXYnuBMZHOkRJND6j6mULG/yzaKdQjGW96Bn/p/VzWxPOxu3Fdf+TUh loaw== MIME-Version: 1.0 X-Received: by 10.236.124.132 with SMTP id x4mr27791415yhh.119.1406331577761; Fri, 25 Jul 2014 16:39:37 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Fri, 25 Jul 2014 16:39:37 -0700 (PDT) Received: by 10.170.130.201 with HTTP; Fri, 25 Jul 2014 16:39:37 -0700 (PDT) In-Reply-To: References: <53D16FE5.3080903@orange.com> <53D18D55.5080406@orange.com> <5D991159-E447-4522-9B97-5974482B377C@cisco.com> <53D250CB.8020400@pi.nu> Date: Fri, 25 Jul 2014 19:39:37 -0400 Message-ID: From: Alia Atlas To: Matthew Bocci Content-Type: multipart/alternative; boundary=20cf303a2ebd21062904ff0d163f Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/UzTdt-DLFqc665wTenSRQ6hHskQ Cc: "rtg-dir@ietf.org" , Thomas Morin , rtg-chairs@ietf.org, Jeff Haas , "Stewart Bryant \(stbryant\)" , Loa Andersson Subject: Re: [RTG-DIR] Working group names X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 23:39:40 -0000 --20cf303a2ebd21062904ff0d163f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable PALS seems like a win & not too much of a stretch. Psuedowire- and LDP-enabled Services Alia On Jul 25, 2014 9:02 AM, "Bocci, Matthew (Matthew)" < matthew.bocci@alcatel-lucent.com> wrote: > All > > Something strange happened to that email. > > I meant to say that I like Please, but I also like Pals. > > Regards > > Matthew > > > On 25/07/2014 13:56, "Bocci, Matthew (Matthew)" > wrote: > > >=C5=92Please=C2=B9 is good, but I also like =C5=92PALS=C2=B9. > > > > > > > >On 25/07/2014 13:42, "Loa Andersson" wrote: > > > >>Folks, > >> > >>I thought about "please" also, it is a little bit "begging" but nice. > >> > >>/Loa > >> > >>On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote: > >>> Pseudo wire and LDP enabled services=3D please > >>> > >>> Stewart > >>> > >>> > >>> > >>> On 25 Jul 2014, at 02:51, "Alia Atlas" >>> > wrote: > >>> > >>>> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas >>>> > wrote: > >>>> > >>>> Somehow I think that working group participants may object to > >>>> being called lepers. > >>>> > >>>> > >>>> I won't call them that, if you don't ;-) > >>>> The group's got some great technology in it that's deployed all over= , > >>>> after all. > >>>> > >>>> Alia > >>>> > >>>> > >>>> Jeff > >>>> > >>>> > On Jul 24, 2014, at 18:48, Thomas Morin < > thomas.morin@orange.com > >>>> > wrote: > >>>> > > >>>> > I do like LEPS better. > >>>> > >>>> > >> > >>-- > >> > >> > >>Loa Andersson email: loa@mail01.huawei.com > >>Senior MPLS Expert loa@pi.nu > >>Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > > > > --20cf303a2ebd21062904ff0d163f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

PALS seems like a win & not too much of a stretch.

Psuedowire- and LDP-enabled Services

Alia

On Jul 25, 2014 9:02 AM, "Bocci, Matthew (M= atthew)" <matth= ew.bocci@alcatel-lucent.com> wrote:
All

Something strange happened to that email.

I meant to say that I like Please, but I also like Pals.

Regards

Matthew


On 25/07/2014 13:56, "Bocci, Matthew (Matthew)"
<matthew.bocci@alcat= el-lucent.com> wrote:

>=C5=92Please=C2=B9 is good, but I also like =C5=92PALS=C2=B9.
>
>
>
>On 25/07/2014 13:42, "Loa Andersson" <loa@pi.nu> wrote:
>
>>Folks,
>>
>>I thought about "please" also, it is a little bit "b= egging" but nice.
>>
>>/Loa
>>
>>On 2014-07-25 10:44, Stewart Bryant (stbryant) wrote:
>>> Pseudo wire and LDP enabled services=3D please
>>>
>>> Stewart
>>>
>>>
>>>
>>> On 25 Jul 2014, at 02:51, "Alia Atlas" <akatlas@gmail.com
>>> <mailto:akatlas@gmail.= com>> wrote:
>>>
>>>> On Thu, Jul 24, 2014 at 8:02 PM, Jeff Haas <jhaas@pfrc.org
>>>> <mailto:jhaas@pfrc.or= g>> wrote:
>>>>
>>>> =C2=A0 =C2=A0 Somehow I think that working group participa= nts may object to
>>>> =C2=A0 =C2=A0 being called lepers.
>>>>
>>>>
>>>> I won't call them that, if you don't ;-)
>>>> The group's got some great technology in it that's= deployed all over,
>>>> after all.
>>>>
>>>> Alia
>>>>
>>>>
>>>> =C2=A0 =C2=A0 Jeff
>>>>
>>>> =C2=A0 =C2=A0 > On Jul 24, 2014, at 18:48, Thomas Morin= <thomas.morin@orange.com=
>>>> =C2=A0 =C2=A0 <mailto:thomas.morin@orange.com>> wrote:
>>>> =C2=A0 =C2=A0 >
>>>> =C2=A0 =C2=A0 > I do like LEPS better.
>>>>
>>>>
>>
>>--
>>
>>
>>Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
>>Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@= pi.nu
>>Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 21 64 >>
>

--20cf303a2ebd21062904ff0d163f-- From nobody Wed Jul 30 06:02:34 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F1D1A0021 for ; Wed, 30 Jul 2014 06:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJdGnOaFnttA for ; Wed, 30 Jul 2014 06:02:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F3C1A0020 for ; Wed, 30 Jul 2014 06:02:21 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6UD29YC021044; Wed, 30 Jul 2014 14:02:09 +0100 Received: from 950129200 ([200.130.255.1]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6UD225c020876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 14:02:05 +0100 From: "Adrian Farrel" To: "'Kamran Raza \(skraza\)'" References: <2baf5ec74dbf42929b973c99cae1b1bd@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <2baf5ec74dbf42929b973c99cae1b1bd@AM3PR03MB612.eurprd03.prod.outlook.com> Date: Wed, 30 Jul 2014 14:02:06 +0100 Message-ID: <02ca01cfabf6$7a2a70e0$6e7f52a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CB_01CFABFE.DBF652F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5dxMs+oaAUnzdi3sEUonP+cPrI5pk/htQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20848.007 X-TM-AS-Result: No--28.981-10.0-31-10 X-imss-scan-details: No--28.981-10.0-31-10 X-TMASE-MatchedRID: HQYVVRq48RxbJCKOm3VRCaj5v7I4/SgYgLxiA5wrMD0d3f60TB3YNhXR lvQslVRBHodpx3o6GrtT46Ow+EhYOK/Nc0jg2jTVxSZxKZrfThNY7aa4/f753MJN1A4Xsa0XUUu 8YxG/ncQQ7qKF6LOVXp9UKbhpcge0JNtuyL6mpIUchOq9qK+AGi670e2gJiRY+WXvsIYYZvWpfL BCJLeQYZ/JE/eOMuX3Vo6mn+xXmdVBCir9/rc1+3RNGrhtzGYfXcLiA766x+uevNpNG+udb6l8s EIkt5BhXSTr2nYJDfgER9Ta+6BEXZ3CiZIvqKEdM/dZg2GSzOWcci0lRpPGpulSru6TfUc+UUu8 YxG/ncQ8A73TdWVG0i4uTw19Klh6k4FdoXhNFg1oNGY/OdYkWSztlR7ZLgp2stpGYye7NyPupTw knGG9dSaOcv37gc1KgW5/KXM36b4xmbT6wQT2a7KD2ZBd3Hi1nQS2JFHcHyaDZvpzckf8heU8VM Gqkl70CYzAZe+RNg5/TWpwlAOFXnnL427v8Q46qe7f8q1Z8ZBcRWGahHnWFMI5VzLB01st3VyvU xgUmwfG5PWYfPKjUjHzsy28T+GVu2rcU2ygxCCCsBeCv8CM/ZTBY8pA+2x83KyKcpgdIrM+d4Bx r4xboQW/eUHwJTrI+IHpXFbQo2LegqK9F+QonPBM74B0/T+aA4U+VwBvBgVHJDerV6yz76Y//KK eIgL2sqFY8SqBLVBPuMJi/ZAk8ZWr6iSXWtgPSZV6zWnCdrlBpTDv/pIBigW7EfGTDL4PevTrVj gbgNNjYmcruApxcoWs+rMQjb4f+xSA5hg3iBqbKItl61J/yZUdXE/WGn0FfeZdJ1Xsorg5MLTF7 xJ++tAswyNCu3AMIvZ1O8ggoYB5ILrkKK3IDJQfo9YNbu+X78J0OfO+dsfHclgIoe6J6IDCQ7Tk qZKHftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/O1mrJgpIR4G7DLO17aeCDL750N4 Cc: rtg-dir@ietf.org, draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org, 'Alexander Vainshtein' , 'Sami Boutros' , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 13:02:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CB_01CFABFE.DBF652F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kamran, Thanks for responding to the question in the GenArt review. Do you have any responses to Sasha's review (copied below)? cheers, Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 11 May 2014 15:09 To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (sboutros@cisco.com) Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt 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-mpls-ldp-ip-pw-capability-07.txt Reviewer: Alexander ("Sasha") Vainshtein Review date: 11-May-14 IETF LC End Date: 12-May-14 Intended status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. These concerns mainly deal with potential negative impact of the mechanisms (introduced in the draft) for disabling "non-negotiable" capabilities of LDP sessions with the techniques that could dynamically change the state of "interest" in these capabilities for a given LDP session. Some of these mechanisms are already standardized by the IETF, e.g., L2VPN auto-discovery (RFC 6074 ) and dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw ) while others - LDP FRR using remote loop-free adjacencies (draft-ietf-rtgwg-remote-lfa )- are in advanced stages of the IETF process. I must admit that I did not follow closely the discussion of the draft in question in the MPLS WG; so it may well be that some of my concerns have been already raised, considered and found not relevant. I also do not know if the draft has ever been discussed in the PWE3, L2VPN and RTG WGs. One possible way to address these concerns would be by adding an Applicability Statement section to the draft and discussing potentially problematic combinations of mechanisms there. I have discussed this option with the authors and, to the best of my understanding, they have in general agreed to add such a section to the next revision of the draft. General comments: To the best of my understanding the sole purpose of the draft is prevention of " wasteful" distribution of state dealing with two non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined in RFC 5036 ) and PW FECs (i.e. PW Id FEC and Generalized PW Id FEC defined in RFC 4447 ) to LDP peers that are "not interested' in this state. Such unnecessary distribution would result in unnecessary waste of resources (memory and/or CPU cycles) and hence should be avoided. The draft mentions that: To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments. The draft, however, does not mention that filtering policies provide much finer granularity of control over distribution of labels than that supported by the mechanism introduced in the draft. E.g., in a scenario when LDP is supposed to set up only "tunnel LSPs" between PEs for L2 and L3 VPN applications, an appropriate policy allow distribution of the just the FECs associated with Router IDs of the PEs but not, say FECs associated with the subnets of their core-facing interfaces. IMHO and FWIW this means that support of the mechanism defined in the draft would not eliminate the need for the filtering policies. I have discussed this point with the authors and they have agreed to add some clarifying text. I have also failed to understand how distribution of PW FECs could be wasteful. Section 5.3.3 "Signaling Procedures" of RFC 4447 explicitly states that: In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure. The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). My reading of the quoted text is that PW FECs are only distributed across targeted LDP sessions with the known Remote PEs for specific PWs. AFAIK, this is what actually happens in most existing implementations of PW signaling with RFC 4447. What's more, many implementations, when required to set up a PW with a specific remote PE, check for existence of a targeted LDP session with this PE, and set it up implicitly if it does not exist; then they distribute PW FEC-to-label binding via this session only. Implicit targeted LDP sessions are also implicitly torn down when the last PW between the given pair of PEs is torn down. I have discussed this point with the authors, but, as of the moment of writing this review, we did not yet reach full agreement on it. Readability of the draft: Initially I have failed to understand the following text fragment in the draft (the problematic statements are marked with italics): For Prefix-LSPs application type, the non-interesting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings as a non-interesting state and allows the advertisement of IP Address bindings to facilitate other LDP applications (such as mLDP) that depend on learning of peer addresses over an LDP session for their correct operation. After discussing this point with the authors I've understood that they refer to exchange of the LSR addresses in the Address and Address Withdraw messages that is required for mapping Next Hop IP addresses computed by the IGP to Next Hop LSR. While initial misunderstanding may be specific to me, I have suggested to the authors to clarify this point with explicit references to specific LDP messages and sections of RFC 5036 . Major Issue: The draft, which builds on the mechanisms defined in RFC 5561 , defines two ways to manipulate distribution of "non-interesting state", since by default it would be enabled . In the Initialization message. I assume that in this case the only valid use case would be disabling distribution of non-interesting state . In the Capability message. This method could be both to disable and re-enable distribution of state, but it could only be used if the peer supports "Dynamic Announcement Capability". My concern stems from the fact that the draft deals with "old" LDP applications, so that the possibility that distribution of FEC-to-Label bindings can be unilaterally disabled for PW- and Prefix-FECs is not taken into account in the existing deployments and mechanisms. Here is a couple of examples: Consider the case when a targeted LDP session between PE1 and PE2 has been set just for the purpose of running ICCP between these devices (i.e., in the terms of the ICCP draft they belong to the same RG). According to the example in Section 5.1 of the draft, the PEs could then disable distribution of both PW FECs and Prefix-FECs across such a session in their appropriate Initialization messages. The following (valid from my point of view) scenarios would make such a setting highly problematic: 1. The operator that manages both PE1 and PE2: a. Maintains some VPLS instances in its network b. Initially maintains VPLS instances in both E1 and PE2, but without overlap between the sets of these instances (so that there is no need to setup PWs between PE1 and PE2) c. Uses BGP-based autodiscovery mechanisms for VPLS in its network as described in RFC 6074 d. Is required to extend one of the VPLS instances it maintains and that already has presence in PE1 to have presence also in PE2: i. With BGP-based autodiscovery, explicit configuration of just PE2 should suffice, the person (or management application) that extends this instance does not have to know about the rest of the locations where this VPLS instance is present ii. The autodiscovery process (which does not depend on LDP) identifies PE1 as a peer for the VPLS instance being defined in PE2, so that a PW between PE1 and PE2 is now required iii. The PW setup process finds a targeted LDP session between PE1 and PE2 and tries to use it for setting up the required PW iv. However, PW setup would fails because distribution of PW FECs across the already existing targeted LDP session between PE1 and PE2 has been disabled. e. If PE1 and PE2 support "Dynamic Capability Announcement", this could be amended by enabling distribution of PW FECs prior to setting the required PW. However, this would require substantial changes in the existing PW setup procedures f. If even one of the PEs does not support "Dynamic Capability Announcement", the existing targeted LDP session would have to be torn down and re-established again. This would probably have serious implications for the ICCP-based redundancy mechanism. 2. A similar scenario could be encountered if the operator employs dynamic setup of multi-segment PWs, and the PW routing mechanism decides that one of the segments of a new MS-PW to be set up should run between PE1 and PE2. Such a situation could be probably prevented if the PW routing mechanism could learn that PE1 and PE2 cannot be "directly connected", but, to the best of my understanding, it would require changes in the already standardized MS-PW routing mechanism. I have discussed these cases with the authors, but we have not reached an agreement on them yet. From my point of view, the Applicability Statement section should address these concerns. Consider now the case described in Section 5.2 of the draft, when a targeted LDP session between PE1 and PE2 is initially used just for distribution of setup of PWs, so that distribution of Prefix-FECs is disabled. The following (valid from my point of view) scenario would make such a setting highly problematic: 1. The operator uses LDP for setting "Tunnel LSPs" in its network 2. LFA-based LDP FRR (as per RFC 5286 and Remote LFA draft ) is used as the mechanism for fast protection in the operator's network. 3. Initially PE1 can protect all the LSPs passing through it using just local LFA. 4. The network topology changes (e.g., because new LSRs are added to it), and in order to provide the required coverage, PE1 has to use PE2 as its "remote LFA" for some destinations. a. This would require distribution of Prefix-FECs across the targeted LDP session between PE1 and PE2 - but it has been disabled b. If PE2 does not support "Dynamic Announcement Capability", then the only way to amend the situation would be to tear down the targeted LDP session between PE1 and PE2 and to set it up again - but this would negatively affect PW traffic between PE1 and PE2. I have discussed this case with the authors. To the best of my understanding, they have agreed that combining LDP FRR based on Remote LFAs with the mechanisms defined in the draft would be highly problematic, and will add some suitable text to the Applicability Statement section in the next revision of the draft. Minor Issues: 1. The draft states (in section 4.2) that desire of a given LSR of reception of unnecessary state from the peer is "unilateral and unidirectional by nature". a. IMO this makes perfect sense for Prefix-FECs. b. However, PW FECs must always be exchange in both directions of a targeted LDP session, so that disabling their distribution in just one direction would effectively prevent setup of PWs between the given pair of PEs 2. I concur with Adrian's comment in his AD review of the draft about proposed encoding of states of non-interest. 3. I also wonder whence the need for 16 potential states of non-interest in the draft that, to the best of my understanding, deals with exactly 4 "old" LDP applications. I hope that this does not imply possibility of developing new "old-style' LDP applications in future (or discovering some forgotten old ones?). I have not yet discussed these issues with the authors (as we concentrated on the major ones). Nits: None found by the IDNITS tool. Spelling and Grammar: I defer to the English Language review team. Hopefully these comments will be useful. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: +972-54-9266302 ------=_NextPart_000_02CB_01CFABFE.DBF652F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kamran,

 

Thanks for responding = to the question in the GenArt review.

 

Do you have any = responses to Sasha's review (copied below)?

 

cheers,

Adrian

 

From: Alexander = Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: 11 = May 2014 15:09
To: rtg-ads@tools.ietf.org
Cc: = rtg-dir@ietf.org; = drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; = skraza@cisco.com; Sami Boutros (sboutros@cisco.com)
Subject: = RTG-DIR Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

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-mpls-ldp-ip-pw-capability-07.txt

Reviewer: Alexander (“Sasha”) = Vainshtein   

Review date: 11-May-14

IETF LC End Date: 12-May-14

Intended status: Standards Track

 

Summary:

 

I have significant concerns about this document = and recommend that the Routing ADs discuss these issues further with the = authors.

These concerns mainly deal with potential = negative impact of the mechanisms (introduced in the draft) for = disabling “non-negotiable” capabilities of LDP sessions =  with the techniques that could dynamically change the state of = “interest” in these capabilities for a given LDP = session. 

Some of these mechanisms are already = standardized by the IETF, e.g.,   L2VPN auto-discovery (RFC 6074) and =  dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others - =  LDP FRR using remote loop-free adjacencies (draft-ietf-rtgwg-remote-lfa)- are in advanced stages = of the IETF process.   

 

 

I must admit that I did not follow closely the = discussion of  the draft in question in the MPLS WG; so it may well = be that some of my concerns have been already raised, considered and = found not relevant.

I also do not know if the draft has ever been = discussed in the PWE3, L2VPN and RTG WGs.

 

One possible way to address these concerns = would be by adding an Applicability Statement section to the draft and = discussing potentially problematic combinations of mechanisms = there.

I have discussed this option with the authors = and, to the best of my understanding, they have in general agreed to add = such a section to the next revision of the draft.

 

General comments:

To the best of my = understanding the sole purpose of the draft is  prevention of = “ wasteful” distribution of state dealing with two = non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 = and IPv6 prefixes defined in RFC 5036) and PW FECs = (i.e. PW Id FEC and Generalized PW Id FEC defined in RFC 4447) to LDP peers = that are “not interested’ in this state. Such unnecessary = distribution would result in unnecessary waste of resources (memory = and/or CPU cycles) and hence should be avoided. =  

 

The draft mentions = that:

<quote>

  To avoid this = unnecessary state advertisement and exchange, currently

  an operator is = typically required to configure and define filtering

  policies on the = LSR, which introduces unnecessary operational

  overhead and = complexity for such deployments. 

<end = quote>

 

The draft, however, does = not mention that filtering policies provide much finer granularity of = control over distribution of labels than that supported by the mechanism = introduced in the draft.

E.g., in a scenario when = LDP is supposed to set up only “tunnel LSPs” between PEs for = L2 and L3 VPN applications, an appropriate policy allow distribution of = the just the FECs associated with Router IDs of the PEs but not, say = FECs associated with the subnets of their core-facing interfaces. IMHO = and FWIW this means that support of the mechanism defined in the draft = would not eliminate the need for the filtering = policies.

 

I have discussed this = point with the authors and they have agreed to add some clarifying = text.

 

I have also failed to = understand how distribution of PW FECs could be wasteful. Section 5.3.3 =  “Signaling Procedures” of RFC 4447 explicitly = states that:

<quote>

   =
In order for PE1 to begin signaling PE2, PE1 must know the address =
of
   the remote =
PE2, and a TAI.  This information may have been =
configured
   at PE1, or it =
may have been learned dynamically via some
   autodiscovery =
procedure.
 
   =
The egress PE (PE1), which has knowledge of the ingress PE, =
initiates
   the setup by =
sending a Label Mapping Message to the ingress PE =
(PE2).
<end =
quote>
 
My reading of the quoted =
text is that PW FECs are only distributed across targeted LDP sessions =
with the known Remote PEs for specific PWs.
AFAIK, this is what =
actually happens in most existing implementations of PW signaling with =
RFC 4447. 
What’s more, many =
implementations, when required to set up a PW with a specific remote PE, =
check for existence of a targeted LDP session with this PE, and set it =
up implicitly if it does not exist; then they distribute PW FEC-to-label =
binding via this session only. Implicit targeted LDP sessions are also =
implicitly torn down when the last PW between  the given pair of =
PEs is torn down.
I have discussed this =
point with the authors, but, as of the moment of writing this review, =
 we did not yet reach full agreement on it. =
 
 
Readability of the =
draft:
 
Initially I have failed to =
understand the following text fragment in the draft (the problematic =
statements are marked with italics):
<quote>
   =
For Prefix-LSPs application type, the non-interesting state refers =

   to any =
state related to IP Prefix FEC (such as FEC label bindings, =

   LDP =
Status). This document, however, does not classify IP address =

   bindings =
as a non-interesting state and allows the advertisement of =

   IP =
Address bindings to facilitate other LDP applications (such as =
   mLDP) = that depend on learning of peer addresses over an LDP session =    for = their correct operation.<end = quote>

After discussing this = point with the authors I’ve understood that they refer to exchange = of the LSR addresses in the Address and Address Withdraw = messages that is required for mapping Next Hop IP addresses = computed by the IGP to Next Hop LSR. While initial misunderstanding may = be specific to me,  I have suggested to the authors to clarify this = point with explicit references to specific LDP messages and sections of = RFC = 5036.

 

Major = Issue:

 

The draft, which builds on = the mechanisms defined in RFC = 5561,  defines two ways to manipulate distribution of = “non-interesting state”, since by default it would be = enabled

·=    &nb= sp;     In the Initialization = message. I assume that in this case the only valid use case would be = disabling distribution of non-interesting state

·=    &nb= sp;     In the Capability message. = This method could be both to disable and re-enable distribution of = state, but it could only be used if the peer supports “Dynamic = Announcement Capability”.

 

My concern stems from the = fact that the draft deals with “old” LDP applications, so = that the possibility that distribution of FEC-to-Label bindings can be = unilaterally disabled for PW- and Prefix-FECs is not taken into account = in the existing deployments and mechanisms.

 

Here is a couple of = examples:

 

Consider the case when a = targeted LDP session between PE1 and PE2 has been set just for the = purpose of running ICCP between these devices (i.e., in the terms of the = ICCP draft they belong to the same RG). According to the example in = Section 5.1 of the draft, the PEs could then disable distribution of = both PW FECs and Prefix-FECs across such a session in their appropriate = Initialization messages.

 

The following (valid from = my point of view) scenarios would make such a setting highly = problematic:

1.   &nb= sp;   The operator that manages = both PE1 and PE2:

a.   &nb= sp;   Maintains some  VPLS = instances in its network

b.   &nb= sp;  Initially maintains VPLS = instances in both E1 and PE2, but without overlap between the sets of = these instances (so that there is no need to setup PWs between PE1 and = PE2)

c.   &nb= sp;   Uses BGP-based = autodiscovery mechanisms for VPLS in its network as described in RFC = 6074

d.   &nb= sp;  Is required to extend one = of the VPLS instances it maintains and that already has presence in PE1 = to have presence also in PE2:

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           = i.   &nb= sp;  With BGP-based = autodiscovery, explicit configuration of just PE2 should suffice, the = person (or management application) that extends this instance does not = have to know about the rest of the locations where this VPLS instance is = present

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;          ii.   &nb= sp;  The autodiscovery process = (which does not depend on LDP) identifies PE1 as a peer for the VPLS = instance being defined in PE2, so that a PW between PE1 and PE2 is now = required

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        iii.   &nb= sp;  The PW setup process finds = a targeted LDP session between PE1 and PE2 and tries to use it for = setting up the required PW

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        iv.   &nb= sp;  However, PW setup would = fails because distribution of PW FECs across the already existing = targeted LDP session between PE1 and PE2 has been = disabled.

e.   &nb= sp;  If PE1 and PE2 support = “Dynamic Capability Announcement”, this could be amended by = enabling distribution of PW FECs prior to setting the required PW. = However, this would require substantial changes in the existing PW setup = procedures

f.   &nb= sp;    If even one of the PEs = does not support “Dynamic Capability Announcement”, the = existing targeted LDP session would have to be torn down and = re-established again. This would probably have serious implications for = the ICCP-based redundancy mechanism.

2.   &nb= sp;   A similar scenario could = be encountered if the operator employs dynamic setup of multi-segment = PWs, and the PW routing mechanism decides that one of the segments of a = new MS-PW to be set up should run between PE1 and PE2.   Such = a situation could be probably prevented if the PW routing mechanism = could learn that PE1 and PE2 cannot be “directly connected”, = but, to the best of my understanding, it would require changes in the = already standardized MS-PW routing mechanism.

 

I have discussed these = cases with the authors, but we have not reached an agreement on them = yet. From my point of view, the Applicability Statement section should = address these concerns.

 

Consider now the case = described in Section 5.2 of the draft, when a targeted LDP session = between PE1 and PE2 is initially used just for distribution of setup of = PWs, so that distribution of Prefix-FECs is = disabled.

 

The following (valid from = my point of view) scenario would make such a setting highly = problematic:

1.   &nb= sp;   The operator uses LDP for = setting “Tunnel LSPs” in its network

2.   &nb= sp;   LFA-based LDP FRR (as per = RFC = 5286 and Remote LFA draft) is used as the mechanism for fast = protection in the operator’s network.

3.   &nb= sp;   Initially PE1 can protect = all the LSPs passing through it using just local = LFA.

4.   &nb= sp;   The network topology = changes (e.g., because new LSRs are added to it), and in order to = provide the required coverage, PE1 has to use PE2 as its “remote = LFA” for some destinations.

a.   &nb= sp;   This would require = distribution of Prefix-FECs across the targeted LDP session between PE1 = and PE2 – but it has been disabled

b.   &nb= sp;  If PE2 does not support = “Dynamic Announcement Capability”, then the only way to = amend the situation would be to tear down the targeted LDP session = between PE1 and PE2 and to set it up again – but this would = negatively affect PW traffic between PE1 and = PE2.

 

I have discussed this case = with the authors. To the best of my understanding, they have agreed that = combining LDP FRR based on Remote LFAs with the mechanisms defined in = the draft would be highly problematic, and will add some suitable text = to the Applicability Statement section in the next revision of the = draft.

 

 

Minor = Issues:

 

1.       = The draft states (in = section 4.2) that desire of a given LSR  of reception of = unnecessary state from the peer is “unilateral and unidirectional = by nature”.

a.       = IMO this makes perfect = sense for Prefix-FECs.

b.      = However, PW FECs must = always be exchange in both directions of  a targeted LDP session, = so that disabling their distribution in just one direction would = effectively prevent setup of PWs between the given pair of = PEs

2.       = I concur with = Adrian’s comment in his AD review of the draft about proposed = encoding of states of non-interest.

3.       =  I also wonder whence = the need for 16 potential states of non-interest in the draft that, = to the best of my understanding, deals with exactly 4 “old” = LDP applications. I hope that = this does not imply possibility of developing new = “old-style’ LDP applications in future (or discovering some = forgotten old ones?).

 

I have not yet discussed = these issues with the authors (as we concentrated on the major = ones).

 

Nits:

None found by the IDNITS = tool.

 

 

Spelling and = Grammar:

I defer to the English = Language review team.

 

Hopefully these comments = will be useful.

 

Regards,<= /p>

    &nb= sp;  Sasha

Email: Alexander.Vainshtein@eci= tele.com

Mobile: = +972-54-9266302

 

------=_NextPart_000_02CB_01CFABFE.DBF652F0-- From nobody Wed Jul 30 10:48:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2111A01EB for ; Wed, 30 Jul 2014 10:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgUXk0CvF4So for ; Wed, 30 Jul 2014 10:48:13 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58491A0164 for ; Wed, 30 Jul 2014 10:48:10 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 17:48:08 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Wed, 30 Jul 2014 17:48:08 +0000 From: Alexander Vainshtein To: Adrian Farrel , "'Kamran Raza (skraza)'" Thread-Topic: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Thread-Index: AQHPrB5ry7MH85zjQlWHldfu8Tbv0Q== Date: Wed, 30 Jul 2014 17:48:07 +0000 Message-ID: <98715847e3ea4ffca171a4c870a2d2ed@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.35.50.58] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(252514010)(52604005)(479174003)(46102001)(81542001)(19580405001)(64706001)(74502001)(15202345003)(19273905006)(101416001)(50986999)(54356999)(76576001)(99396002)(20776003)(86362001)(74662001)(4396001)(87936001)(19625215002)(31966008)(74316001)(81342001)(2656002)(77982001)(92566001)(85306003)(80022001)(105586002)(33646002)(106356001)(95666004)(106116001)(19617315012)(83072002)(21056001)(83322001)(19580395003)(79102001)(16236675004)(66066001)(76482001)(85852003)(107046002)(15975445006)(24736002)(108616003)(579004)(563064011); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_98715847e3ea4ffca171a4c870a2d2edAM3PR03MB612eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/KF2JiRJf-1jTmc385uwA5e8Sq8o Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" , 'Sami Boutros' , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:48:19 -0000 --_000_98715847e3ea4ffca171a4c870a2d2edAM3PR03MB612eurprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRyaWFuLA0KDQpXZSBwbGFuIHRvIGhvbGQgYSBjaGF0IHRvbW9ycm93IGV2ZW5pbmcuDQoNClRo ZW4gd2Ugc2hhbGwga25vdyBiZXR0ZXIuDQoNCg0KDQpUaHVtYiB0eXBlZCBvbiBteSBMRywNClNh c2hhDQoNCi0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLQ0KRnJvbTogQWRyaWFuIEZhcnJl bA0KRGF0ZTogMzAvMDcvMjAxNCAxNjowMg0KVG86ICdLYW1yYW4gUmF6YSAoc2tyYXphKSc7DQpD YzogcnRnLWRpckBpZXRmLm9yZzsnU2FtaSBCb3V0cm9zJztkcmFmdC1pZXRmLW1wbHMtbGRwLWlw LXB3LWNhcGFiaWxpdHkuYWxsQHRvb2xzLmlldGYub3JnO0FsZXhhbmRlciBWYWluc2h0ZWluO3J0 Zy1hZHNAdG9vbHMuaWV0Zi5vcmc7DQpTdWJqZWN0OlJFOiBSVEctRElSIFJldmlldzogZHJhZnQt aWV0Zi1tcGxzLWxkcC1pcC1wdy1jYXBhYmlsaXR5LTA3LnR4dA0KDQpLYW1yYW4sDQoNClRoYW5r cyBmb3IgcmVzcG9uZGluZyB0byB0aGUgcXVlc3Rpb24gaW4gdGhlIEdlbkFydCByZXZpZXcuDQoN CkRvIHlvdSBoYXZlIGFueSByZXNwb25zZXMgdG8gU2FzaGEncyByZXZpZXcgKGNvcGllZCBiZWxv dyk/DQoNCmNoZWVycywNCkFkcmlhbg0KDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KU2VudDogMTEgTWF5IDIwMTQg MTU6MDkNClRvOiBydGctYWRzQHRvb2xzLmlldGYub3JnDQpDYzogcnRnLWRpckBpZXRmLm9yZzsg ZHJhZnRzLWlldGYtbXBscy1sZHAtaXAtcHctY2FwYWJpbGl0eS5hbGxAdG9vbHMuaWV0Zi5vcmc7 IHNrcmF6YUBjaXNjby5jb207IFNhbWkgQm91dHJvcyAoc2JvdXRyb3NAY2lzY28uY29tKQ0KU3Vi amVjdDogUlRHLURJUiBSZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1sZHAtaXAtcHctY2FwYWJpbGl0 eS0wNy50eHQNCg0KDQpIZWxsbywNCg0KDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBS b3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0KDQpUaGUgUm91dGlu ZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxh dGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyBy ZXZpZXcuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNl IHRvIHRoZSBSb3V0aW5nIEFEcy4NCg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJv dXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2Rp cmVjdG9yYXRlL3JvdXRpbmcuaHRtbA0KDQoNCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJl IHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhl bHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVU RiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNv bHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCg0K DQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwLXB3LWNhcGFiaWxpdHktMDcudHh0 DQoNClJldmlld2VyOiBBbGV4YW5kZXIgKOKAnFNhc2hh4oCdKSBWYWluc2h0ZWluDQoNClJldmll dyBkYXRlOiAxMS1NYXktMTQNCg0KSUVURiBMQyBFbmQgRGF0ZTogMTItTWF5LTE0DQoNCkludGVu ZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNCg0KDQpTdW1tYXJ5Og0KDQoNCg0KSSBoYXZl IHNpZ25pZmljYW50IGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgYW5kIHJlY29tbWVuZCB0 aGF0IHRoZSBSb3V0aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlzc3VlcyBmdXJ0aGVyIHdpdGggdGhl IGF1dGhvcnMuDQoNClRoZXNlIGNvbmNlcm5zIG1haW5seSBkZWFsIHdpdGggcG90ZW50aWFsIG5l Z2F0aXZlIGltcGFjdCBvZiB0aGUgbWVjaGFuaXNtcyAoaW50cm9kdWNlZCBpbiB0aGUgZHJhZnQp IGZvciBkaXNhYmxpbmcg4oCcbm9uLW5lZ290aWFibGXigJ0gY2FwYWJpbGl0aWVzIG9mIExEUCBz ZXNzaW9ucyAgd2l0aCB0aGUgdGVjaG5pcXVlcyB0aGF0IGNvdWxkIGR5bmFtaWNhbGx5IGNoYW5n ZSB0aGUgc3RhdGUgb2Yg4oCcaW50ZXJlc3TigJ0gaW4gdGhlc2UgY2FwYWJpbGl0aWVzIGZvciBh IGdpdmVuIExEUCBzZXNzaW9uLg0KDQpTb21lIG9mIHRoZXNlIG1lY2hhbmlzbXMgYXJlIGFscmVh ZHkgc3RhbmRhcmRpemVkIGJ5IHRoZSBJRVRGLCBlLmcuLCAgIEwyVlBOIGF1dG8tZGlzY292ZXJ5 IChSRkMgNjA3NDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDc0PikgYW5kICBkeW5h bWljIHBsYWNlbWVudCBvZiBtdWx0aS1zZWdtZW50IHBzZXVkby13aXJlcyAoZHJhZnQtaWV0Zi1w d2UzLWR5bmFtaWMtbXMtcHc8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXB3ZTMtZHluYW1pYy1tcy1wdy8/aW5jbHVkZV90ZXh0PTE+KSB3aGlsZSBvdGhlcnMgLSAg TERQIEZSUiB1c2luZyByZW1vdGUgbG9vcC1mcmVlIGFkamFjZW5jaWVzIChkcmFmdC1pZXRmLXJ0 Z3dnLXJlbW90ZS1sZmE8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1ydGd3Zy1yZW1vdGUtbGZhLz9pbmNsdWRlX3RleHQ9MT4pLSBhcmUgaW4gYWR2YW5jZWQgc3Rh Z2VzIG9mIHRoZSBJRVRGIHByb2Nlc3MuDQoNCg0KDQoNCg0KSSBtdXN0IGFkbWl0IHRoYXQgSSBk aWQgbm90IGZvbGxvdyBjbG9zZWx5IHRoZSBkaXNjdXNzaW9uIG9mICB0aGUgZHJhZnQgaW4gcXVl c3Rpb24gaW4gdGhlIE1QTFMgV0c7IHNvIGl0IG1heSB3ZWxsIGJlIHRoYXQgc29tZSBvZiBteSBj b25jZXJucyBoYXZlIGJlZW4gYWxyZWFkeSByYWlzZWQsIGNvbnNpZGVyZWQgYW5kIGZvdW5kIG5v dCByZWxldmFudC4NCg0KSSBhbHNvIGRvIG5vdCBrbm93IGlmIHRoZSBkcmFmdCBoYXMgZXZlciBi ZWVuIGRpc2N1c3NlZCBpbiB0aGUgUFdFMywgTDJWUE4gYW5kIFJURyBXR3MuDQoNCg0KDQpPbmUg cG9zc2libGUgd2F5IHRvIGFkZHJlc3MgdGhlc2UgY29uY2VybnMgd291bGQgYmUgYnkgYWRkaW5n IGFuIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IHNlY3Rpb24gdG8gdGhlIGRyYWZ0IGFuZCBkaXNj dXNzaW5nIHBvdGVudGlhbGx5IHByb2JsZW1hdGljIGNvbWJpbmF0aW9ucyBvZiBtZWNoYW5pc21z IHRoZXJlLg0KDQpJIGhhdmUgZGlzY3Vzc2VkIHRoaXMgb3B0aW9uIHdpdGggdGhlIGF1dGhvcnMg YW5kLCB0byB0aGUgYmVzdCBvZiBteSB1bmRlcnN0YW5kaW5nLCB0aGV5IGhhdmUgaW4gZ2VuZXJh bCBhZ3JlZWQgdG8gYWRkIHN1Y2ggYSBzZWN0aW9uIHRvIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRo ZSBkcmFmdC4NCg0KDQoNCkdlbmVyYWwgY29tbWVudHM6DQpUbyB0aGUgYmVzdCBvZiBteSB1bmRl cnN0YW5kaW5nIHRoZSBzb2xlIHB1cnBvc2Ugb2YgdGhlIGRyYWZ0IGlzICBwcmV2ZW50aW9uIG9m IOKAnCB3YXN0ZWZ1bOKAnSBkaXN0cmlidXRpb24gb2Ygc3RhdGUgZGVhbGluZyB3aXRoIHR3byBu b24tbmVnb3RpYWJsZSBjbGFzc2VzIG9mIEZFQ3M6IFByZWZpeCBGRUNzIChpLmUuLCBGRUNzIGRl ZmluZWQgYnkgSVB2NCBhbmQgSVB2NiBwcmVmaXhlcyBkZWZpbmVkIGluICBSRkMgNTAzNjxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MDM2PikgYW5kIFBXIEZFQ3MgKGkuZS4gUFcgSWQg RkVDIGFuZCBHZW5lcmFsaXplZCBQVyBJZCBGRUMgZGVmaW5lZCBpbiAgUkZDIDQ0NDc8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0Nz4pIHRvIExEUCBwZWVycyB0aGF0IGFyZSDigJxu b3QgaW50ZXJlc3RlZOKAmSBpbiB0aGlzIHN0YXRlLiBTdWNoIHVubmVjZXNzYXJ5IGRpc3RyaWJ1 dGlvbiB3b3VsZCByZXN1bHQgaW4gdW5uZWNlc3Nhcnkgd2FzdGUgb2YgcmVzb3VyY2VzIChtZW1v cnkgYW5kL29yIENQVSBjeWNsZXMpIGFuZCBoZW5jZSBzaG91bGQgYmUgYXZvaWRlZC4NCg0KVGhl IGRyYWZ0IG1lbnRpb25zIHRoYXQ6DQo8cXVvdGU+DQogIFRvIGF2b2lkIHRoaXMgdW5uZWNlc3Nh cnkgc3RhdGUgYWR2ZXJ0aXNlbWVudCBhbmQgZXhjaGFuZ2UsIGN1cnJlbnRseQ0KICBhbiBvcGVy YXRvciBpcyB0eXBpY2FsbHkgcmVxdWlyZWQgdG8gY29uZmlndXJlIGFuZCBkZWZpbmUgZmlsdGVy aW5nDQogIHBvbGljaWVzIG9uIHRoZSBMU1IsIHdoaWNoIGludHJvZHVjZXMgdW5uZWNlc3Nhcnkg b3BlcmF0aW9uYWwNCiAgb3ZlcmhlYWQgYW5kIGNvbXBsZXhpdHkgZm9yIHN1Y2ggZGVwbG95bWVu dHMuDQo8ZW5kIHF1b3RlPg0KDQpUaGUgZHJhZnQsIGhvd2V2ZXIsIGRvZXMgbm90IG1lbnRpb24g dGhhdCBmaWx0ZXJpbmcgcG9saWNpZXMgcHJvdmlkZSBtdWNoIGZpbmVyIGdyYW51bGFyaXR5IG9m IGNvbnRyb2wgb3ZlciBkaXN0cmlidXRpb24gb2YgbGFiZWxzIHRoYW4gdGhhdCBzdXBwb3J0ZWQg YnkgdGhlIG1lY2hhbmlzbSBpbnRyb2R1Y2VkIGluIHRoZSBkcmFmdC4NCkUuZy4sIGluIGEgc2Nl bmFyaW8gd2hlbiBMRFAgaXMgc3VwcG9zZWQgdG8gc2V0IHVwIG9ubHkg4oCcdHVubmVsIExTUHPi gJ0gYmV0d2VlbiBQRXMgZm9yIEwyIGFuZCBMMyBWUE4gYXBwbGljYXRpb25zLCBhbiBhcHByb3By aWF0ZSBwb2xpY3kgYWxsb3cgZGlzdHJpYnV0aW9uIG9mIHRoZSBqdXN0IHRoZSBGRUNzIGFzc29j aWF0ZWQgd2l0aCBSb3V0ZXIgSURzIG9mIHRoZSBQRXMgYnV0IG5vdCwgc2F5IEZFQ3MgYXNzb2Np YXRlZCB3aXRoIHRoZSBzdWJuZXRzIG9mIHRoZWlyIGNvcmUtZmFjaW5nIGludGVyZmFjZXMuIElN SE8gYW5kIEZXSVcgdGhpcyBtZWFucyB0aGF0IHN1cHBvcnQgb2YgdGhlIG1lY2hhbmlzbSBkZWZp bmVkIGluIHRoZSBkcmFmdCB3b3VsZCBub3QgZWxpbWluYXRlIHRoZSBuZWVkIGZvciB0aGUgZmls dGVyaW5nIHBvbGljaWVzLg0KDQpJIGhhdmUgZGlzY3Vzc2VkIHRoaXMgcG9pbnQgd2l0aCB0aGUg YXV0aG9ycyBhbmQgdGhleSBoYXZlIGFncmVlZCB0byBhZGQgc29tZSBjbGFyaWZ5aW5nIHRleHQu DQoNCkkgaGF2ZSBhbHNvIGZhaWxlZCB0byB1bmRlcnN0YW5kIGhvdyBkaXN0cmlidXRpb24gb2Yg UFcgRkVDcyBjb3VsZCBiZSB3YXN0ZWZ1bC4gU2VjdGlvbiA1LjMuMyAg4oCcU2lnbmFsaW5nIFBy b2NlZHVyZXPigJ0gb2YgUkZDIDQ0NDc8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0 Nz4gZXhwbGljaXRseSBzdGF0ZXMgdGhhdDoNCjxxdW90ZT4NCg0KICAgSW4gb3JkZXIgZm9yIFBF MSB0byBiZWdpbiBzaWduYWxpbmcgUEUyLCBQRTEgbXVzdCBrbm93IHRoZSBhZGRyZXNzIG9mDQoN CiAgIHRoZSByZW1vdGUgUEUyLCBhbmQgYSBUQUkuICBUaGlzIGluZm9ybWF0aW9uIG1heSBoYXZl IGJlZW4gY29uZmlndXJlZA0KDQogICBhdCBQRTEsIG9yIGl0IG1heSBoYXZlIGJlZW4gbGVhcm5l ZCBkeW5hbWljYWxseSB2aWEgc29tZQ0KDQogICBhdXRvZGlzY292ZXJ5IHByb2NlZHVyZS4NCg0K DQoNCiAgIFRoZSBlZ3Jlc3MgUEUgKFBFMSksIHdoaWNoIGhhcyBrbm93bGVkZ2Ugb2YgdGhlIGlu Z3Jlc3MgUEUsIGluaXRpYXRlcw0KDQogICB0aGUgc2V0dXAgYnkgc2VuZGluZyBhIExhYmVsIE1h cHBpbmcgTWVzc2FnZSB0byB0aGUgaW5ncmVzcyBQRSAoUEUyKS4NCjxlbmQgcXVvdGU+DQoNCk15 IHJlYWRpbmcgb2YgdGhlIHF1b3RlZCB0ZXh0IGlzIHRoYXQgUFcgRkVDcyBhcmUgb25seSBkaXN0 cmlidXRlZCBhY3Jvc3MgdGFyZ2V0ZWQgTERQIHNlc3Npb25zIHdpdGggdGhlIGtub3duIFJlbW90 ZSBQRXMgZm9yIHNwZWNpZmljIFBXcy4NCkFGQUlLLCB0aGlzIGlzIHdoYXQgYWN0dWFsbHkgaGFw cGVucyBpbiBtb3N0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBvZiBQVyBzaWduYWxpbmcgd2l0 aCBSRkMgNDQ0Ny4NCldoYXTigJlzIG1vcmUsIG1hbnkgaW1wbGVtZW50YXRpb25zLCB3aGVuIHJl cXVpcmVkIHRvIHNldCB1cCBhIFBXIHdpdGggYSBzcGVjaWZpYyByZW1vdGUgUEUsIGNoZWNrIGZv ciBleGlzdGVuY2Ugb2YgYSB0YXJnZXRlZCBMRFAgc2Vzc2lvbiB3aXRoIHRoaXMgUEUsIGFuZCBz ZXQgaXQgdXAgaW1wbGljaXRseSBpZiBpdCBkb2VzIG5vdCBleGlzdDsgdGhlbiB0aGV5IGRpc3Ry aWJ1dGUgUFcgRkVDLXRvLWxhYmVsIGJpbmRpbmcgdmlhIHRoaXMgc2Vzc2lvbiBvbmx5LiBJbXBs aWNpdCB0YXJnZXRlZCBMRFAgc2Vzc2lvbnMgYXJlIGFsc28gaW1wbGljaXRseSB0b3JuIGRvd24g d2hlbiB0aGUgbGFzdCBQVyBiZXR3ZWVuICB0aGUgZ2l2ZW4gcGFpciBvZiBQRXMgaXMgdG9ybiBk b3duLg0KSSBoYXZlIGRpc2N1c3NlZCB0aGlzIHBvaW50IHdpdGggdGhlIGF1dGhvcnMsIGJ1dCwg YXMgb2YgdGhlIG1vbWVudCBvZiB3cml0aW5nIHRoaXMgcmV2aWV3LCAgd2UgZGlkIG5vdCB5ZXQg cmVhY2ggZnVsbCBhZ3JlZW1lbnQgb24gaXQuDQoNClJlYWRhYmlsaXR5IG9mIHRoZSBkcmFmdDoN Cg0KSW5pdGlhbGx5IEkgaGF2ZSBmYWlsZWQgdG8gdW5kZXJzdGFuZCB0aGUgZm9sbG93aW5nIHRl eHQgZnJhZ21lbnQgaW4gdGhlIGRyYWZ0ICh0aGUgcHJvYmxlbWF0aWMgc3RhdGVtZW50cyBhcmUg bWFya2VkIHdpdGggaXRhbGljcyk6DQo8cXVvdGU+DQoNCiAgIEZvciBQcmVmaXgtTFNQcyBhcHBs aWNhdGlvbiB0eXBlLCB0aGUgbm9uLWludGVyZXN0aW5nIHN0YXRlIHJlZmVycw0KDQogICB0byBh bnkgc3RhdGUgcmVsYXRlZCB0byBJUCBQcmVmaXggRkVDIChzdWNoIGFzIEZFQyBsYWJlbCBiaW5k aW5ncywNCg0KICAgTERQIFN0YXR1cykuIFRoaXMgZG9jdW1lbnQsIGhvd2V2ZXIsIGRvZXMgbm90 IGNsYXNzaWZ5IElQIGFkZHJlc3MNCg0KICAgYmluZGluZ3MgYXMgYSBub24taW50ZXJlc3Rpbmcg c3RhdGUgYW5kIGFsbG93cyB0aGUgYWR2ZXJ0aXNlbWVudCBvZg0KDQogICBJUCBBZGRyZXNzIGJp bmRpbmdzIHRvIGZhY2lsaXRhdGUgb3RoZXIgTERQIGFwcGxpY2F0aW9ucyAoc3VjaCBhcw0KDQog ICBtTERQKSB0aGF0IGRlcGVuZCBvbiBsZWFybmluZyBvZiBwZWVyIGFkZHJlc3NlcyBvdmVyIGFu IExEUCBzZXNzaW9uDQoNCiAgIGZvciB0aGVpciBjb3JyZWN0IG9wZXJhdGlvbi4NCjxlbmQgcXVv dGU+DQpBZnRlciBkaXNjdXNzaW5nIHRoaXMgcG9pbnQgd2l0aCB0aGUgYXV0aG9ycyBJ4oCZdmUg dW5kZXJzdG9vZCB0aGF0IHRoZXkgcmVmZXIgdG8gZXhjaGFuZ2Ugb2YgdGhlIExTUiBhZGRyZXNz ZXMgaW4gdGhlIEFkZHJlc3MgYW5kIEFkZHJlc3MgV2l0aGRyYXcgbWVzc2FnZXMgdGhhdCBpcyBy ZXF1aXJlZCBmb3IgbWFwcGluZyBOZXh0IEhvcCBJUCBhZGRyZXNzZXMgY29tcHV0ZWQgYnkgdGhl IElHUCB0byBOZXh0IEhvcCBMU1IuIFdoaWxlIGluaXRpYWwgbWlzdW5kZXJzdGFuZGluZyBtYXkg YmUgc3BlY2lmaWMgdG8gbWUsICBJIGhhdmUgc3VnZ2VzdGVkIHRvIHRoZSBhdXRob3JzIHRvIGNs YXJpZnkgdGhpcyBwb2ludCB3aXRoIGV4cGxpY2l0IHJlZmVyZW5jZXMgdG8gc3BlY2lmaWMgTERQ IG1lc3NhZ2VzIGFuZCBzZWN0aW9ucyBvZiBSRkMgNTAzNjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1MDM2Pi4NCg0KTWFqb3IgSXNzdWU6DQoNClRoZSBkcmFmdCwgd2hpY2ggYnVpbGRz IG9uIHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gIFJGQyA1NTYxPGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL3JmYzU1NjEvP2luY2x1ZGVfdGV4dD0xPiwgIGRlZmluZXMgdHdvIHdh eXMgdG8gbWFuaXB1bGF0ZSBkaXN0cmlidXRpb24gb2Yg4oCcbm9uLWludGVyZXN0aW5nIHN0YXRl 4oCdLCBzaW5jZSBieSBkZWZhdWx0IGl0IHdvdWxkIGJlIGVuYWJsZWQNCg0K4oCiICAgICAgICAg SW4gdGhlIEluaXRpYWxpemF0aW9uIG1lc3NhZ2UuIEkgYXNzdW1lIHRoYXQgaW4gdGhpcyBjYXNl IHRoZSBvbmx5IHZhbGlkIHVzZSBjYXNlIHdvdWxkIGJlIGRpc2FibGluZyBkaXN0cmlidXRpb24g b2Ygbm9uLWludGVyZXN0aW5nIHN0YXRlDQoNCuKAoiAgICAgICAgIEluIHRoZSBDYXBhYmlsaXR5 IG1lc3NhZ2UuIFRoaXMgbWV0aG9kIGNvdWxkIGJlIGJvdGggdG8gZGlzYWJsZSBhbmQgcmUtZW5h YmxlIGRpc3RyaWJ1dGlvbiBvZiBzdGF0ZSwgYnV0IGl0IGNvdWxkIG9ubHkgYmUgdXNlZCBpZiB0 aGUgcGVlciBzdXBwb3J0cyDigJxEeW5hbWljIEFubm91bmNlbWVudCBDYXBhYmlsaXR54oCdLg0K DQpNeSBjb25jZXJuIHN0ZW1zIGZyb20gdGhlIGZhY3QgdGhhdCB0aGUgZHJhZnQgZGVhbHMgd2l0 aCDigJxvbGTigJ0gTERQIGFwcGxpY2F0aW9ucywgc28gdGhhdCB0aGUgcG9zc2liaWxpdHkgdGhh dCBkaXN0cmlidXRpb24gb2YgRkVDLXRvLUxhYmVsIGJpbmRpbmdzIGNhbiBiZSB1bmlsYXRlcmFs bHkgZGlzYWJsZWQgZm9yIFBXLSBhbmQgUHJlZml4LUZFQ3MgaXMgbm90IHRha2VuIGludG8gYWNj b3VudCBpbiB0aGUgZXhpc3RpbmcgZGVwbG95bWVudHMgYW5kIG1lY2hhbmlzbXMuDQoNCkhlcmUg aXMgYSBjb3VwbGUgb2YgZXhhbXBsZXM6DQoNCkNvbnNpZGVyIHRoZSBjYXNlIHdoZW4gYSB0YXJn ZXRlZCBMRFAgc2Vzc2lvbiBiZXR3ZWVuIFBFMSBhbmQgUEUyIGhhcyBiZWVuIHNldCBqdXN0IGZv ciB0aGUgcHVycG9zZSBvZiBydW5uaW5nIElDQ1AgYmV0d2VlbiB0aGVzZSBkZXZpY2VzIChpLmUu LCBpbiB0aGUgdGVybXMgb2YgdGhlIElDQ1AgZHJhZnQgdGhleSBiZWxvbmcgdG8gdGhlIHNhbWUg UkcpLiBBY2NvcmRpbmcgdG8gdGhlIGV4YW1wbGUgaW4gU2VjdGlvbiA1LjEgb2YgdGhlIGRyYWZ0 LCB0aGUgUEVzIGNvdWxkIHRoZW4gZGlzYWJsZSBkaXN0cmlidXRpb24gb2YgYm90aCBQVyBGRUNz IGFuZCBQcmVmaXgtRkVDcyBhY3Jvc3Mgc3VjaCBhIHNlc3Npb24gaW4gdGhlaXIgYXBwcm9wcmlh dGUgSW5pdGlhbGl6YXRpb24gbWVzc2FnZXMuDQoNClRoZSBmb2xsb3dpbmcgKHZhbGlkIGZyb20g bXkgcG9pbnQgb2Ygdmlldykgc2NlbmFyaW9zIHdvdWxkIG1ha2Ugc3VjaCBhIHNldHRpbmcgaGln aGx5IHByb2JsZW1hdGljOg0KDQoxLiAgICAgICBUaGUgb3BlcmF0b3IgdGhhdCBtYW5hZ2VzIGJv dGggUEUxIGFuZCBQRTI6DQoNCmEuICAgICAgIE1haW50YWlucyBzb21lICBWUExTIGluc3RhbmNl cyBpbiBpdHMgbmV0d29yaw0KDQpiLiAgICAgIEluaXRpYWxseSBtYWludGFpbnMgVlBMUyBpbnN0 YW5jZXMgaW4gYm90aCBFMSBhbmQgUEUyLCBidXQgd2l0aG91dCBvdmVybGFwIGJldHdlZW4gdGhl IHNldHMgb2YgdGhlc2UgaW5zdGFuY2VzIChzbyB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgdG8gc2V0 dXAgUFdzIGJldHdlZW4gUEUxIGFuZCBQRTIpDQoNCmMuICAgICAgIFVzZXMgQkdQLWJhc2VkIGF1 dG9kaXNjb3ZlcnkgbWVjaGFuaXNtcyBmb3IgVlBMUyBpbiBpdHMgbmV0d29yayBhcyBkZXNjcmli ZWQgaW4gUkZDIDYwNzQNCg0KZC4gICAgICBJcyByZXF1aXJlZCB0byBleHRlbmQgb25lIG9mIHRo ZSBWUExTIGluc3RhbmNlcyBpdCBtYWludGFpbnMgYW5kIHRoYXQgYWxyZWFkeSBoYXMgcHJlc2Vu Y2UgaW4gUEUxIHRvIGhhdmUgcHJlc2VuY2UgYWxzbyBpbiBQRTI6DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpLiAgICAg IFdpdGggQkdQLWJhc2VkIGF1dG9kaXNjb3ZlcnksIGV4cGxpY2l0IGNvbmZpZ3VyYXRpb24gb2Yg anVzdCBQRTIgc2hvdWxkIHN1ZmZpY2UsIHRoZSBwZXJzb24gKG9yIG1hbmFnZW1lbnQgYXBwbGlj YXRpb24pIHRoYXQgZXh0ZW5kcyB0aGlzIGluc3RhbmNlIGRvZXMgbm90IGhhdmUgdG8ga25vdyBh Ym91dCB0aGUgcmVzdCBvZiB0aGUgbG9jYXRpb25zIHdoZXJlIHRoaXMgVlBMUyBpbnN0YW5jZSBp cyBwcmVzZW50DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGlpLiAgICAgIFRoZSBhdXRvZGlzY292ZXJ5IHByb2Nlc3MgKHdo aWNoIGRvZXMgbm90IGRlcGVuZCBvbiBMRFApIGlkZW50aWZpZXMgUEUxIGFzIGEgcGVlciBmb3Ig dGhlIFZQTFMgaW5zdGFuY2UgYmVpbmcgZGVmaW5lZCBpbiBQRTIsIHNvIHRoYXQgYSBQVyBiZXR3 ZWVuIFBFMSBhbmQgUEUyIGlzIG5vdyByZXF1aXJlZA0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWlpLiAgICAgIFRoZSBQVyBz ZXR1cCBwcm9jZXNzIGZpbmRzIGEgdGFyZ2V0ZWQgTERQIHNlc3Npb24gYmV0d2VlbiBQRTEgYW5k IFBFMiBhbmQgdHJpZXMgdG8gdXNlIGl0IGZvciBzZXR0aW5nIHVwIHRoZSByZXF1aXJlZCBQVw0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaXYuICAgICAgSG93ZXZlciwgUFcgc2V0dXAgd291bGQgZmFpbHMgYmVjYXVzZSBkaXN0 cmlidXRpb24gb2YgUFcgRkVDcyBhY3Jvc3MgdGhlIGFscmVhZHkgZXhpc3RpbmcgdGFyZ2V0ZWQg TERQIHNlc3Npb24gYmV0d2VlbiBQRTEgYW5kIFBFMiBoYXMgYmVlbiBkaXNhYmxlZC4NCg0KZS4g ICAgICBJZiBQRTEgYW5kIFBFMiBzdXBwb3J0IOKAnER5bmFtaWMgQ2FwYWJpbGl0eSBBbm5vdW5j ZW1lbnTigJ0sIHRoaXMgY291bGQgYmUgYW1lbmRlZCBieSBlbmFibGluZyBkaXN0cmlidXRpb24g b2YgUFcgRkVDcyBwcmlvciB0byBzZXR0aW5nIHRoZSByZXF1aXJlZCBQVy4gSG93ZXZlciwgdGhp cyB3b3VsZCByZXF1aXJlIHN1YnN0YW50aWFsIGNoYW5nZXMgaW4gdGhlIGV4aXN0aW5nIFBXIHNl dHVwIHByb2NlZHVyZXMNCg0KZi4gICAgICAgIElmIGV2ZW4gb25lIG9mIHRoZSBQRXMgZG9lcyBu b3Qgc3VwcG9ydCDigJxEeW5hbWljIENhcGFiaWxpdHkgQW5ub3VuY2VtZW504oCdLCB0aGUgZXhp c3RpbmcgdGFyZ2V0ZWQgTERQIHNlc3Npb24gd291bGQgaGF2ZSB0byBiZSB0b3JuIGRvd24gYW5k IHJlLWVzdGFibGlzaGVkIGFnYWluLiBUaGlzIHdvdWxkIHByb2JhYmx5IGhhdmUgc2VyaW91cyBp bXBsaWNhdGlvbnMgZm9yIHRoZSBJQ0NQLWJhc2VkIHJlZHVuZGFuY3kgbWVjaGFuaXNtLg0KDQoy LiAgICAgICBBIHNpbWlsYXIgc2NlbmFyaW8gY291bGQgYmUgZW5jb3VudGVyZWQgaWYgdGhlIG9w ZXJhdG9yIGVtcGxveXMgZHluYW1pYyBzZXR1cCBvZiBtdWx0aS1zZWdtZW50IFBXcywgYW5kIHRo ZSBQVyByb3V0aW5nIG1lY2hhbmlzbSBkZWNpZGVzIHRoYXQgb25lIG9mIHRoZSBzZWdtZW50cyBv ZiBhIG5ldyBNUy1QVyB0byBiZSBzZXQgdXAgc2hvdWxkIHJ1biBiZXR3ZWVuIFBFMSBhbmQgUEUy LiAgIFN1Y2ggYSBzaXR1YXRpb24gY291bGQgYmUgcHJvYmFibHkgcHJldmVudGVkIGlmIHRoZSBQ VyByb3V0aW5nIG1lY2hhbmlzbSBjb3VsZCBsZWFybiB0aGF0IFBFMSBhbmQgUEUyIGNhbm5vdCBi ZSDigJxkaXJlY3RseSBjb25uZWN0ZWTigJ0sIGJ1dCwgdG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJz dGFuZGluZywgaXQgd291bGQgcmVxdWlyZSBjaGFuZ2VzIGluIHRoZSBhbHJlYWR5IHN0YW5kYXJk aXplZCBNUy1QVyByb3V0aW5nIG1lY2hhbmlzbS4NCg0KDQoNCkkgaGF2ZSBkaXNjdXNzZWQgdGhl c2UgY2FzZXMgd2l0aCB0aGUgYXV0aG9ycywgYnV0IHdlIGhhdmUgbm90IHJlYWNoZWQgYW4gYWdy ZWVtZW50IG9uIHRoZW0geWV0LiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIHRoZSBBcHBsaWNhYmls aXR5IFN0YXRlbWVudCBzZWN0aW9uIHNob3VsZCBhZGRyZXNzIHRoZXNlIGNvbmNlcm5zLg0KDQoN Cg0KQ29uc2lkZXIgbm93IHRoZSBjYXNlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMiBvZiB0aGUg ZHJhZnQsIHdoZW4gYSB0YXJnZXRlZCBMRFAgc2Vzc2lvbiBiZXR3ZWVuIFBFMSBhbmQgUEUyIGlz IGluaXRpYWxseSB1c2VkIGp1c3QgZm9yIGRpc3RyaWJ1dGlvbiBvZiBzZXR1cCBvZiBQV3MsIHNv IHRoYXQgZGlzdHJpYnV0aW9uIG9mIFByZWZpeC1GRUNzIGlzIGRpc2FibGVkLg0KDQoNCg0KVGhl IGZvbGxvd2luZyAodmFsaWQgZnJvbSBteSBwb2ludCBvZiB2aWV3KSBzY2VuYXJpbyB3b3VsZCBt YWtlIHN1Y2ggYSBzZXR0aW5nIGhpZ2hseSBwcm9ibGVtYXRpYzoNCg0KMS4gICAgICAgVGhlIG9w ZXJhdG9yIHVzZXMgTERQIGZvciBzZXR0aW5nIOKAnFR1bm5lbCBMU1Bz4oCdIGluIGl0cyBuZXR3 b3JrDQoNCjIuICAgICAgIExGQS1iYXNlZCBMRFAgRlJSIChhcyBwZXIgIFJGQyA1Mjg2PGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzUyODYvP2luY2x1ZGVfdGV4dD0xPiBhbmQg IFJlbW90ZSBMRkEgZHJhZnQ8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1ydGd3Zy1yZW1vdGUtbGZhLz9pbmNsdWRlX3RleHQ9MT4pIGlzIHVzZWQgYXMgdGhlIG1l Y2hhbmlzbSBmb3IgZmFzdCBwcm90ZWN0aW9uIGluIHRoZSBvcGVyYXRvcuKAmXMgbmV0d29yay4N Cg0KMy4gICAgICAgSW5pdGlhbGx5IFBFMSBjYW4gcHJvdGVjdCBhbGwgdGhlIExTUHMgcGFzc2lu ZyB0aHJvdWdoIGl0IHVzaW5nIGp1c3QgbG9jYWwgTEZBLg0KDQo0LiAgICAgICBUaGUgbmV0d29y ayB0b3BvbG9neSBjaGFuZ2VzIChlLmcuLCBiZWNhdXNlIG5ldyBMU1JzIGFyZSBhZGRlZCB0byBp dCksIGFuZCBpbiBvcmRlciB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBjb3ZlcmFnZSwgUEUxIGhh cyB0byB1c2UgUEUyIGFzIGl0cyDigJxyZW1vdGUgTEZB4oCdIGZvciBzb21lIGRlc3RpbmF0aW9u cy4NCg0KYS4gICAgICAgVGhpcyB3b3VsZCByZXF1aXJlIGRpc3RyaWJ1dGlvbiBvZiBQcmVmaXgt RkVDcyBhY3Jvc3MgdGhlIHRhcmdldGVkIExEUCBzZXNzaW9uIGJldHdlZW4gUEUxIGFuZCBQRTIg 4oCTIGJ1dCBpdCBoYXMgYmVlbiBkaXNhYmxlZA0KDQpiLiAgICAgIElmIFBFMiBkb2VzIG5vdCBz dXBwb3J0IOKAnER5bmFtaWMgQW5ub3VuY2VtZW50IENhcGFiaWxpdHnigJ0sIHRoZW4gdGhlIG9u bHkgd2F5IHRvIGFtZW5kIHRoZSBzaXR1YXRpb24gd291bGQgYmUgdG8gdGVhciBkb3duIHRoZSB0 YXJnZXRlZCBMRFAgc2Vzc2lvbiBiZXR3ZWVuIFBFMSBhbmQgUEUyIGFuZCB0byBzZXQgaXQgdXAg YWdhaW4g4oCTIGJ1dCB0aGlzIHdvdWxkIG5lZ2F0aXZlbHkgYWZmZWN0IFBXIHRyYWZmaWMgYmV0 d2VlbiBQRTEgYW5kIFBFMi4NCg0KSSBoYXZlIGRpc2N1c3NlZCB0aGlzIGNhc2Ugd2l0aCB0aGUg YXV0aG9ycy4gVG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZywgdGhleSBoYXZlIGFncmVl ZCB0aGF0IGNvbWJpbmluZyBMRFAgRlJSIGJhc2VkIG9uIFJlbW90ZSBMRkFzIHdpdGggdGhlIG1l Y2hhbmlzbXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQgd291bGQgYmUgaGlnaGx5IHByb2JsZW1hdGlj LCBhbmQgd2lsbCBhZGQgc29tZSBzdWl0YWJsZSB0ZXh0IHRvIHRoZSBBcHBsaWNhYmlsaXR5IFN0 YXRlbWVudCBzZWN0aW9uIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4NCg0KDQpN aW5vciBJc3N1ZXM6DQoNCg0KMS4gICAgICAgVGhlIGRyYWZ0IHN0YXRlcyAoaW4gc2VjdGlvbiA0 LjIpIHRoYXQgZGVzaXJlIG9mIGEgZ2l2ZW4gTFNSICBvZiByZWNlcHRpb24gb2YgdW5uZWNlc3Nh cnkgc3RhdGUgZnJvbSB0aGUgcGVlciBpcyDigJx1bmlsYXRlcmFsIGFuZCB1bmlkaXJlY3Rpb25h bCBieSBuYXR1cmXigJ0uDQoNCmEuICAgICAgIElNTyB0aGlzIG1ha2VzIHBlcmZlY3Qgc2Vuc2Ug Zm9yIFByZWZpeC1GRUNzLg0KDQpiLiAgICAgIEhvd2V2ZXIsIFBXIEZFQ3MgbXVzdCBhbHdheXMg YmUgZXhjaGFuZ2UgaW4gYm90aCBkaXJlY3Rpb25zIG9mICBhIHRhcmdldGVkIExEUCBzZXNzaW9u LCBzbyB0aGF0IGRpc2FibGluZyB0aGVpciBkaXN0cmlidXRpb24gaW4ganVzdCBvbmUgZGlyZWN0 aW9uIHdvdWxkIGVmZmVjdGl2ZWx5IHByZXZlbnQgc2V0dXAgb2YgUFdzIGJldHdlZW4gdGhlIGdp dmVuIHBhaXIgb2YgUEVzDQoNCjIuICAgICAgIEkgY29uY3VyIHdpdGggQWRyaWFu4oCZcyBjb21t ZW50IGluIGhpcyBBRCByZXZpZXcgb2YgdGhlIGRyYWZ0IGFib3V0IHByb3Bvc2VkIGVuY29kaW5n IG9mIHN0YXRlcyBvZiBub24taW50ZXJlc3QuDQoNCjMuICAgICAgICBJIGFsc28gd29uZGVyIHdo ZW5jZSB0aGUgbmVlZCBmb3IgMTYgcG90ZW50aWFsIHN0YXRlcyBvZiBub24taW50ZXJlc3QgaW4g dGhlIGRyYWZ0IHRoYXQsIHRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcsIGRlYWxzIHdp dGggZXhhY3RseSA0IOKAnG9sZOKAnSBMRFAgYXBwbGljYXRpb25zLiBJIGhvcGUgdGhhdCB0aGlz IGRvZXMgbm90IGltcGx5IHBvc3NpYmlsaXR5IG9mIGRldmVsb3BpbmcgbmV3IOKAnG9sZC1zdHls ZeKAmSBMRFAgYXBwbGljYXRpb25zIGluIGZ1dHVyZSAob3IgZGlzY292ZXJpbmcgc29tZSBmb3Jn b3R0ZW4gb2xkIG9uZXM/KS4NCg0KSSBoYXZlIG5vdCB5ZXQgZGlzY3Vzc2VkIHRoZXNlIGlzc3Vl cyB3aXRoIHRoZSBhdXRob3JzIChhcyB3ZSBjb25jZW50cmF0ZWQgb24gdGhlIG1ham9yIG9uZXMp Lg0KDQpOaXRzOg0KTm9uZSBmb3VuZCBieSB0aGUgSUROSVRTIHRvb2wuDQoNCg0KU3BlbGxpbmcg YW5kIEdyYW1tYXI6DQpJIGRlZmVyIHRvIHRoZSBFbmdsaXNoIExhbmd1YWdlIHJldmlldyB0ZWFt Lg0KDQpIb3BlZnVsbHkgdGhlc2UgY29tbWVudHMgd2lsbCBiZSB1c2VmdWwuDQoNClJlZ2FyZHMs DQogICAgICAgU2FzaGENCkVtYWlsOiBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQpNb2JpbGU6ICs5NzItNTQt OTI2NjMwMg0KDQo= --_000_98715847e3ea4ffca171a4c870a2d2edAM3PR03MB612eurprd03pro_ Content-Type: text/html; charset="utf-8" Content-ID: <5F126C268989BB4CB577102D6B41E3D3@ECI365.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYifQ0KLS0+DQo8L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMHB0OyI+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPkFkcmlh biw8L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDsiPldlIHBsYW4g dG8gaG9sZCBhIGNoYXQgdG9tb3Jyb3cgZXZlbmluZy48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRv cDowO21hcmdpbi1ib3R0b206MDsiPlRoZW4gd2Ugc2hhbGwga25vdyBiZXR0ZXIuPC9wPg0KPHAg c3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7Ij4mbmJzcDs8L3A+DQo8ZGV2M19q ank+VGh1bWIgdHlwZWQgb24gbXkgTEcsPGJyPg0KU2FzaGE8L2RldjNfamp5Pjxicj4NCjxicj4N Ci0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9iPkFk cmlhbiBGYXJyZWw8YWRyaWFuQG9sZGRvZy5jby51az48YnI+DQo8Yj5EYXRlOiZuYnNwOzwvYj4z MC8wNy8yMDE0IDE2OjAyPGJyPg0KPGI+VG86Jm5ic3A7PC9iPidLYW1yYW4gUmF6YSAoc2tyYXph KSc7PGJyPg0KPGI+Q2M6Jm5ic3A7PC9iPnJ0Zy1kaXJAaWV0Zi5vcmc7J1NhbWkgQm91dHJvcyc7 ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcC1wdy1jYXBhYmlsaXR5LmFsbEB0b29scy5pZXRmLm9yZztB bGV4YW5kZXIgVmFpbnNodGVpbjtydGctYWRzQHRvb2xzLmlldGYub3JnOzxicj4NCjxiPlN1Ympl Y3Q6PC9iPlJFOiBSVEctRElSIFJldmlldzogZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcC1wdy1jYXBh YmlsaXR5LTA3LnR4dDxicj4NCjxicj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+S2FtcmFuLDwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5UaGFua3MgZm9yIHJlc3BvbmRpbmcgdG8gdGhlIHF1ZXN0aW9uIGluIHRoZSBH ZW5BcnQgcmV2aWV3Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5EbyB5b3UgaGF2ZSBhbnkgcmVzcG9uc2VzIHRv IFNhc2hhJ3MgcmV2aWV3IChjb3BpZWQgYmVsb3cpPzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5jaGVlcnMsPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5BZHJpYW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsg Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDsgcGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFsZXhhbmRl ciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gMTEgTWF5IDIwMTQgMTU6MDk8YnI+DQo8Yj5Ubzo8L2I+IHJ0Zy1h ZHNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0 cy1pZXRmLW1wbHMtbGRwLWlwLXB3LWNhcGFiaWxpdHkuYWxsQHRvb2xzLmlldGYub3JnOyBza3Jh emFAY2lzY28uY29tOyBTYW1pIEJvdXRyb3MgKHNib3V0cm9zQGNpc2NvLmNvbSk8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUlRHLURJUiBSZXZpZXc6IGRyYWZ0LWlldGYtbXBscy1sZHAtaXAtcHctY2Fw YWJpbGl0eS0wNy50eHQ8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6YmxhY2siPkhlbGxvLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OmJsYWNrIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5UaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVr cyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5 IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQNCiBJRVNHIHJldmlldy4gVGhlIHB1cnBv c2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcg QURzLg0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6YmxhY2siPkZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9y YXRlLCBwbGVhc2Ugc2VlJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2Rp cmVjdG9yYXRlL3JvdXRpbmcuaHRtbCIgdGFyZ2V0PSJfQkxBTksiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJl IHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhl bHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0NCiBhbG9uZyB3aXRoIGFueSBvdGhlciBJ RVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPkRvY3VtZW50 OiBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwLXB3LWNhcGFiaWxpdHktMDcudHh0PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5SZXZpZXdlcjogQWxleGFuZGVy ICjigJxTYXNoYeKAnSkgVmFpbnNodGVpbiAmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+UmV2aWV3IGRhdGU6IDExLU1heS0xNDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+SUVURiBMQyBF bmQgRGF0ZTogMTItTWF5LTE0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOmJsYWNrIj5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlN1bW1hcnk8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+ Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5JIGhhdmUg c2lnbmlmaWNhbnQgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5kIHRo YXQgdGhlIFJvdXRpbmcgQURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aA0KIHRo ZSBhdXRob3JzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFj ayI+VGhlc2UgY29uY2VybnMgbWFpbmx5IGRlYWwgd2l0aCBwb3RlbnRpYWwgbmVnYXRpdmUgaW1w YWN0IG9mIHRoZSBtZWNoYW5pc21zIChpbnRyb2R1Y2VkIGluIHRoZSBkcmFmdCkgZm9yIGRpc2Fi bGluZw0KIOKAnG5vbi1uZWdvdGlhYmxl4oCdIGNhcGFiaWxpdGllcyBvZiBMRFAgc2Vzc2lvbnMg Jm5ic3A7d2l0aCB0aGUgdGVjaG5pcXVlcyB0aGF0IGNvdWxkIGR5bmFtaWNhbGx5IGNoYW5nZSB0 aGUgc3RhdGUgb2Yg4oCcaW50ZXJlc3TigJ0gaW4gdGhlc2UgY2FwYWJpbGl0aWVzIGZvciBhIGdp dmVuIExEUCBzZXNzaW9uLiZuYnNwOw0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlNvbWUgb2YgdGhlc2UgbWVjaGFuaXNtcyBhcmUg YWxyZWFkeSBzdGFuZGFyZGl6ZWQgYnkgdGhlIElFVEYsIGUuZy4sICZuYnNwOyZuYnNwO0wyVlBO IGF1dG8tZGlzY292ZXJ5ICg8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 MDc0IiB0YXJnZXQ9Il9CTEFOSyI+UkZDDQogNjA3NDwvYT4pIGFuZCAmbmJzcDtkeW5hbWljIHBs YWNlbWVudCBvZiBtdWx0aS1zZWdtZW50IHBzZXVkby13aXJlcyAoPGEgaHJlZj0iaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXB3ZTMtZHluYW1pYy1tcy1wdy8/aW5j bHVkZV90ZXh0PTEiIHRhcmdldD0iX0JMQU5LIj5kcmFmdC1pZXRmLXB3ZTMtZHluYW1pYy1tcy1w dzwvYT4pIHdoaWxlIG90aGVycyAtICZuYnNwO0xEUCBGUlIgdXNpbmcgcmVtb3RlIGxvb3AtZnJl ZSBhZGphY2VuY2llcw0KICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJ0Z3dnLXJlbW90ZS1sZmEvP2luY2x1ZGVfdGV4dD0xIiB0YXJnZXQ9Il9C TEFOSyI+ZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZhPC9hPiktIGFyZSBpbiBhZHZhbmNlZCBz dGFnZXMgb2YgdGhlIElFVEYgcHJvY2Vzcy4gJm5ic3A7Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPkkgbXVz dCBhZG1pdCB0aGF0IEkgZGlkIG5vdCBmb2xsb3cgY2xvc2VseSB0aGUgZGlzY3Vzc2lvbiBvZiAm bmJzcDt0aGUgZHJhZnQgaW4gcXVlc3Rpb24gaW4gdGhlIE1QTFMgV0c7IHNvIGl0IG1heSB3ZWxs DQogYmUgdGhhdCBzb21lIG9mIG15IGNvbmNlcm5zIGhhdmUgYmVlbiBhbHJlYWR5IHJhaXNlZCwg Y29uc2lkZXJlZCBhbmQgZm91bmQgbm90IHJlbGV2YW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+SSBhbHNvIGRvIG5vdCBrbm93IGlmIHRoZSBkcmFm dCBoYXMgZXZlciBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgUFdFMywgTDJWUE4gYW5kIFJURyBXR3Mu PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+T25l IHBvc3NpYmxlIHdheSB0byBhZGRyZXNzIHRoZXNlIGNvbmNlcm5zIHdvdWxkIGJlIGJ5IGFkZGlu ZyBhbiBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCBzZWN0aW9uIHRvIHRoZSBkcmFmdCBhbmQgZGlz Y3Vzc2luZw0KIHBvdGVudGlhbGx5IHByb2JsZW1hdGljIGNvbWJpbmF0aW9ucyBvZiBtZWNoYW5p c21zIHRoZXJlLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOmJsYWNrIj5JIGhhdmUgZGlzY3Vzc2VkIHRoaXMgb3B0aW9uIHdpdGggdGhlIGF1dGhv cnMgYW5kLCB0byB0aGUgYmVzdCBvZiBteSB1bmRlcnN0YW5kaW5nLCB0aGV5IGhhdmUgaW4gZ2Vu ZXJhbCBhZ3JlZWQgdG8NCiBhZGQgc3VjaCBhIHNlY3Rpb24gdG8gdGhlIG5leHQgcmV2aXNpb24g b2YgdGhlIGRyYWZ0LiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFj ayI+R2VuZXJhbCBjb21tZW50czwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj46PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+VG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZyB0aGUgc29sZSBwdXJwb3NlIG9mIHRo ZSBkcmFmdCBpcyAmbmJzcDtwcmV2ZW50aW9uIG9mIOKAnCB3YXN0ZWZ1bOKAnSBkaXN0cmlidXRp b24gb2Ygc3RhdGUgZGVhbGluZyB3aXRoIHR3byBub24tbmVnb3RpYWJsZSBjbGFzc2VzIG9mIEZF Q3M6IFByZWZpeCBGRUNzDQogKGkuZS4sIEZFQ3MgZGVmaW5lZCBieSBJUHY0IGFuZCBJUHY2IHBy ZWZpeGVzIGRlZmluZWQgaW4mbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTAzNiIgdGFyZ2V0PSJfQkxBTksiPg0KUkZDIDUwMzY8L2E+KSBhbmQgUFcgRkVDcyAo aS5lLiBQVyBJZCBGRUMgYW5kIEdlbmVyYWxpemVkIFBXIElkIEZFQyBkZWZpbmVkIGluJm5ic3A7 IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDciIHRhcmdldD0iX0JM QU5LIj4NClJGQyA0NDQ3PC9hPikgdG8gTERQIHBlZXJzIHRoYXQgYXJlIOKAnG5vdCBpbnRlcmVz dGVk4oCZIGluIHRoaXMgc3RhdGUuIFN1Y2ggdW5uZWNlc3NhcnkgZGlzdHJpYnV0aW9uIHdvdWxk IHJlc3VsdCBpbiB1bm5lY2Vzc2FyeSB3YXN0ZSBvZiByZXNvdXJjZXMgKG1lbW9yeSBhbmQvb3Ig Q1BVIGN5Y2xlcykgYW5kIGhlbmNlIHNob3VsZCBiZSBhdm9pZGVkLiAmbmJzcDs8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGRyYWZ0IG1lbnRpb25zIHRoYXQ6PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbHQ7cXVvdGUmZ3Q7PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQ7IGJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtU byBhdm9pZCB0aGlzIHVubmVjZXNzYXJ5IHN0YXRlIGFkdmVydGlzZW1lbnQgYW5kIGV4Y2hhbmdl LCBjdXJyZW50bHkNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0 LjRwdDsgYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwO2FuIG9wZXJhdG9yIGlzIHR5cGljYWxseSByZXF1aXJlZCB0byBjb25m aWd1cmUgYW5kIGRlZmluZSBmaWx0ZXJpbmcNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE0LjRwdDsgYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO3BvbGljaWVzIG9uIHRoZSBMU1IsIHdoaWNo IGludHJvZHVjZXMgdW5uZWNlc3Nhcnkgb3BlcmF0aW9uYWwNCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdDsgYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO292ZXJoZWFkIGFuZCBjb21w bGV4aXR5IGZvciBzdWNoIGRlcGxveW1lbnRzLiZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+Jmx0O2VuZCBxdW90ZSZndDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhlIGRyYWZ0LCBob3dldmVyLCBkb2VzIG5vdCBtZW50aW9uIHRoYXQgZmlsdGVyaW5nIHBvbGlj aWVzIHByb3ZpZGUgbXVjaCBmaW5lciBncmFudWxhcml0eSBvZiBjb250cm9sIG92ZXIgZGlzdHJp YnV0aW9uIG9mIGxhYmVscyB0aGFuIHRoYXQgc3VwcG9ydGVkIGJ5IHRoZSBtZWNoYW5pc20gaW50 cm9kdWNlZA0KIGluIHRoZSBkcmFmdC4gPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5FLmcuLCBpbiBhIHNjZW5hcmlvIHdoZW4gTERQIGlzIHN1cHBvc2VkIHRvIHNldCB1 cCBvbmx5IOKAnHR1bm5lbCBMU1Bz4oCdIGJldHdlZW4gUEVzIGZvciBMMiBhbmQgTDMgVlBOIGFw cGxpY2F0aW9ucywgYW4gYXBwcm9wcmlhdGUgcG9saWN5IGFsbG93IGRpc3RyaWJ1dGlvbiBvZiB0 aGUganVzdCB0aGUgRkVDcw0KIGFzc29jaWF0ZWQgd2l0aCBSb3V0ZXIgSURzIG9mIHRoZSBQRXMg YnV0IG5vdCwgc2F5IEZFQ3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBzdWJuZXRzIG9mIHRoZWlyIGNv cmUtZmFjaW5nIGludGVyZmFjZXMuIElNSE8gYW5kIEZXSVcgdGhpcyBtZWFucyB0aGF0IHN1cHBv cnQgb2YgdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGluIHRoZSBkcmFmdCB3b3VsZCBub3QgZWxpbWlu YXRlIHRoZSBuZWVkIGZvciB0aGUgZmlsdGVyaW5nIHBvbGljaWVzLjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIGhhdmUgZGlzY3Vzc2VkIHRoaXMgcG9pbnQgd2l0aCB0aGUgYXV0aG9y cyBhbmQgdGhleSBoYXZlIGFncmVlZCB0byBhZGQgc29tZSBjbGFyaWZ5aW5nIHRleHQuPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkkgaGF2ZSBhbHNvIGZhaWxlZCB0byB1bmRlcnN0YW5k IGhvdyBkaXN0cmlidXRpb24gb2YgUFcgRkVDcyBjb3VsZCBiZSB3YXN0ZWZ1bC4gU2VjdGlvbiA1 LjMuMyAmbmJzcDvigJxTaWduYWxpbmcgUHJvY2VkdXJlc+KAnSBvZiZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDciIHRhcmdldD0iX0JMQU5LIj5SRkMNCiA0 NDQ3PC9hPiBleHBsaWNpdGx5IHN0YXRlcyB0aGF0Ojwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jmx0O3F1b3RlJmd0Ozwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXM7IGJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0luIG9yZGVyIGZvciBQRTEg dG8gYmVnaW4gc2lnbmFsaW5nIFBFMiwgUEUxIG11c3Qga25vdyB0aGUgYWRkcmVzcyBvZjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5czsgYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7dGhlIHJlbW90ZSBQRTIsIGFuZCBhIFRBSS4gJm5ic3A7VGhpcyBpbmZvcm1hdGlv biBtYXkgaGF2ZSBiZWVuIGNvbmZpZ3VyZWQ8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXM7IGJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO2F0IFBFMSwgb3IgaXQgbWF5 IGhhdmUgYmVlbiBsZWFybmVkIGR5bmFtaWNhbGx5IHZpYSBzb21lPC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzOyBiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDthdXRv ZGlzY292ZXJ5IHByb2NlZHVyZS48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXM7IGJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5czsgYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGVncmVzcyBQRSAoUEUxKSwg d2hpY2ggaGFzIGtub3dsZWRnZSBvZiB0aGUgaW5ncmVzcyBQRSwgaW5pdGlhdGVzPC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzOyBiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDt0aGUgc2V0dXAgYnkgc2VuZGluZyBhIExhYmVsIE1hcHBpbmcgTWVzc2FnZSB0byB0aGUg aW5ncmVzcyBQRSAoUEUyKS48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmx0O2VuZCBxdW90ZSZndDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+TXkgcmVh ZGluZyBvZiB0aGUgcXVvdGVkIHRleHQgaXMgdGhhdCBQVyBGRUNzIGFyZSBvbmx5IGRpc3RyaWJ1 dGVkIGFjcm9zcyB0YXJnZXRlZCBMRFAgc2Vzc2lvbnMgd2l0aCB0aGUga25vd24gUmVtb3RlIFBF cyBmb3Igc3BlY2lmaWMgUFdzLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+QUZBSUssIHRoaXMgaXMgd2hhdCBhY3R1YWxseSBoYXBwZW5zIGluIG1vc3QgZXhpc3Rpbmcg aW1wbGVtZW50YXRpb25zIG9mIFBXIHNpZ25hbGluZyB3aXRoIFJGQyA0NDQ3Lg0KPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5XaGF04oCZcyBtb3JlLCBtYW55IGltcGxl bWVudGF0aW9ucywgd2hlbiByZXF1aXJlZCB0byBzZXQgdXAgYSBQVyB3aXRoIGEgc3BlY2lmaWMg cmVtb3RlIFBFLCBjaGVjayBmb3IgZXhpc3RlbmNlIG9mIGEgdGFyZ2V0ZWQgTERQIHNlc3Npb24g d2l0aCB0aGlzIFBFLCBhbmQgc2V0IGl0IHVwIGltcGxpY2l0bHkNCiBpZiBpdCBkb2VzIG5vdCBl eGlzdDsgdGhlbiB0aGV5IGRpc3RyaWJ1dGUgUFcgRkVDLXRvLWxhYmVsIGJpbmRpbmcgdmlhIHRo aXMgc2Vzc2lvbiBvbmx5LiBJbXBsaWNpdCB0YXJnZXRlZCBMRFAgc2Vzc2lvbnMgYXJlIGFsc28g aW1wbGljaXRseSB0b3JuIGRvd24gd2hlbiB0aGUgbGFzdCBQVyBiZXR3ZWVuICZuYnNwO3RoZSBn aXZlbiBwYWlyIG9mIFBFcyBpcyB0b3JuIGRvd24uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIGhhdmUgZGlzY3Vzc2VkIHRoaXMgcG9pbnQgd2l0aCB0aGUgYXV0aG9y cywgYnV0LCBhcyBvZiB0aGUgbW9tZW50IG9mIHdyaXRpbmcgdGhpcyByZXZpZXcsICZuYnNwO3dl IGRpZCBub3QgeWV0IHJlYWNoIGZ1bGwgYWdyZWVtZW50IG9uIGl0LiAmbmJzcDs8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UmVhZGFiaWxpdHkgb2YgdGhlIGRyYWZ0PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj46PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPkluaXRpYWxseSBJIGhhdmUgZmFpbGVkIHRvIHVuZGVyc3RhbmQgdGhl IGZvbGxvd2luZyB0ZXh0IGZyYWdtZW50IGluIHRoZSBkcmFmdCAodGhlIHByb2JsZW1hdGljIHN0 YXRlbWVudHMgYXJlIG1hcmtlZCB3aXRoJm5ic3A7PGk+aXRhbGljczwvaT4pOjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jmx0O3F1b3RlJmd0Ozwvc3Bhbj48L3A+DQo8 cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQ7IGJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0ZvciBQcmVm aXgtTFNQcyBhcHBsaWNhdGlvbiB0eXBlLCB0aGUgbm9uLWludGVyZXN0aW5nIHN0YXRlIHJlZmVy cyZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdDsgYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7dG8gYW55IHN0YXRlIHJlbGF0ZWQgdG8gSVAgUHJlZml4IEZFQyAoc3Vj aCBhcyBGRUMgbGFiZWwgYmluZGluZ3MsJm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bGluZS1oZWlnaHQ6MTQuNHB0OyBiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtMRFAgU3RhdHVzKS4mbmJzcDs8 aT5UaGlzIGRvY3VtZW50LCBob3dldmVyLCBkb2VzIG5vdCBjbGFzc2lmeSBJUCBhZGRyZXNzJm5i c3A7PC9pPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdDsgYmFj a2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7YmluZGluZ3MgYXMgYSBub24taW50ZXJlc3Rpbmcgc3RhdGUgYW5k IGFsbG93cyB0aGUgYWR2ZXJ0aXNlbWVudCBvZiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTQuNHB0OyBiYWNrZ3JvdW5kOndoaXRlIj48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtJUCBBZGRyZXNzIGJpbmRpbmdz IHRvIGZhY2lsaXRhdGUgb3RoZXIgTERQIGFwcGxpY2F0aW9ucyAoc3VjaCBhcyZuYnNwOzwvc3Bh bj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0OyBiYWNrZ3JvdW5kOndoaXRlIj48aT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtt TERQKSB0aGF0IGRlcGVuZCBvbiBsZWFybmluZyBvZiBwZWVyIGFkZHJlc3NlcyBvdmVyIGFuIExE UCBzZXNzaW9uJm5ic3A7PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQ7IGJh Y2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwO2ZvciB0aGVpciBjb3JyZWN0IG9wZXJhdGlvbjwvc3Bhbj48L2k+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Ljwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbHQ7ZW5kIHF1b3RlJmd0Ozwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+QWZ0ZXIgZGlzY3Vzc2luZyB0aGlzIHBvaW50IHdp dGggdGhlIGF1dGhvcnMgSeKAmXZlIHVuZGVyc3Rvb2QgdGhhdCB0aGV5IHJlZmVyIHRvIGV4Y2hh bmdlIG9mIHRoZSBMU1IgYWRkcmVzc2VzIGluIHRoZSBBZGRyZXNzIGFuZCBBZGRyZXNzIFdpdGhk cmF3IG1lc3NhZ2VzIHRoYXQgaXMgcmVxdWlyZWQNCiBmb3IgbWFwcGluZyBOZXh0IEhvcCBJUCBh ZGRyZXNzZXMgY29tcHV0ZWQgYnkgdGhlIElHUCB0byBOZXh0IEhvcCBMU1IuIFdoaWxlIGluaXRp YWwgbWlzdW5kZXJzdGFuZGluZyBtYXkgYmUgc3BlY2lmaWMgdG8gbWUsICZuYnNwO0kgaGF2ZSBz dWdnZXN0ZWQgdG8gdGhlIGF1dGhvcnMgdG8gY2xhcmlmeSB0aGlzIHBvaW50IHdpdGggZXhwbGlj aXQgcmVmZXJlbmNlcyB0byBzcGVjaWZpYyBMRFAgbWVzc2FnZXMgYW5kIHNlY3Rpb25zIG9mJm5i c3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTAzNiIgdGFyZ2V0PSJf QkxBTksiPlJGQw0KIDUwMzY8L2E+Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5N YWpvciBJc3N1ZTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+Ojwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZHJhZnQsIHdoaWNoIGJ1aWxk cyBvbiB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkIGluJm5ic3A7DQo8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM1NTYxLz9pbmNsdWRlX3RleHQ9MSIgdGFyZ2V0PSJf QkxBTksiPg0KUkZDIDU1NjE8L2E+LCAmbmJzcDtkZWZpbmVzIHR3byB3YXlzIHRvIG1hbmlwdWxh dGUgZGlzdHJpYnV0aW9uIG9mIOKAnG5vbi1pbnRlcmVzdGluZyBzdGF0ZeKAnSwgc2luY2UgYnkg ZGVmYXVsdCBpdCB3b3VsZCBiZSBlbmFibGVkPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDAuNXB0OyB0ZXh0LWluZGVudDotMTguMHB0 OyBiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sOyBjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj5JbiB0aGUgSW5pdGlhbGl6YXRpb24gbWVzc2FnZS4gSSBhc3N1 bWUNCiB0aGF0IGluIHRoaXMgY2FzZSB0aGUgb25seSB2YWxpZCB1c2UgY2FzZSB3b3VsZCBiZSBk aXNhYmxpbmcgZGlzdHJpYnV0aW9uIG9mIG5vbi1pbnRlcmVzdGluZyBzdGF0ZTwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQwLjVwdDsg dGV4dC1pbmRlbnQ6LTE4LjBwdDsgYmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbDsgY29sb3I6YmxhY2siPsK3PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0OyBmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gdGhlIENhcGFiaWxpdHkg bWVzc2FnZS4gVGhpcyBtZXRob2QgY291bGQNCiBiZSBib3RoIHRvIGRpc2FibGUgYW5kIHJlLWVu YWJsZSBkaXN0cmlidXRpb24gb2Ygc3RhdGUsIGJ1dCBpdCBjb3VsZCBvbmx5IGJlIHVzZWQgaWYg dGhlIHBlZXIgc3VwcG9ydHMg4oCcRHluYW1pYyBBbm5vdW5jZW1lbnQgQ2FwYWJpbGl0eeKAnS48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+TXkgY29uY2VybiBzdGVtcyBmcm9tIHRoZSBm YWN0IHRoYXQgdGhlIGRyYWZ0IGRlYWxzIHdpdGgg4oCcb2xk4oCdIExEUCBhcHBsaWNhdGlvbnMs IHNvIHRoYXQgdGhlIHBvc3NpYmlsaXR5IHRoYXQgZGlzdHJpYnV0aW9uIG9mIEZFQy10by1MYWJl bCBiaW5kaW5ncyBjYW4gYmUgdW5pbGF0ZXJhbGx5IGRpc2FibGVkDQogZm9yIFBXLSBhbmQgUHJl Zml4LUZFQ3MgaXMgbm90IHRha2VuIGludG8gYWNjb3VudCBpbiB0aGUgZXhpc3RpbmcgZGVwbG95 bWVudHMgYW5kIG1lY2hhbmlzbXMuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkhlcmUg aXMgYSBjb3VwbGUgb2YgZXhhbXBsZXM6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkNv bnNpZGVyIHRoZSBjYXNlIHdoZW4gYSB0YXJnZXRlZCBMRFAgc2Vzc2lvbiBiZXR3ZWVuIFBFMSBh bmQgUEUyIGhhcyBiZWVuIHNldCBqdXN0IGZvciB0aGUgcHVycG9zZSBvZiBydW5uaW5nIElDQ1Ag YmV0d2VlbiB0aGVzZSBkZXZpY2VzIChpLmUuLCBpbiB0aGUgdGVybXMgb2YgdGhlIElDQ1AgZHJh ZnQNCiB0aGV5IGJlbG9uZyB0byB0aGUgc2FtZSBSRykuIEFjY29yZGluZyB0byB0aGUgZXhhbXBs ZSBpbiBTZWN0aW9uIDUuMSBvZiB0aGUgZHJhZnQsIHRoZSBQRXMgY291bGQgdGhlbiBkaXNhYmxl IGRpc3RyaWJ1dGlvbiBvZiBib3RoIFBXIEZFQ3MgYW5kIFByZWZpeC1GRUNzIGFjcm9zcyBzdWNo IGEgc2Vzc2lvbiBpbiB0aGVpciBhcHByb3ByaWF0ZSBJbml0aWFsaXphdGlvbiBtZXNzYWdlcy48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGZvbGxvd2luZyAodmFsaWQgZnJvbSBt eSBwb2ludCBvZiB2aWV3KSBzY2VuYXJpb3Mgd291bGQgbWFrZSBzdWNoIGEgc2V0dGluZyBoaWdo bHkgcHJvYmxlbWF0aWM6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzguMjVwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdDsgYmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4xLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7OyBjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBvcGVyYXRvciB0aGF0IG1hbmFn ZXMgYm90aCBQRTEgYW5kIFBFMjo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3NC4yNXB0OyB0ZXh0LWluZGVudDotMTguMHB0OyBiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmEu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0OyBmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7IGNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+TWFpbnRhaW5zIHNvbWUgJm5i c3A7VlBMUyBpbnN0YW5jZXMgaW4gaXRzIG5ldHdvcms8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3NC4yNXB0OyB0ZXh0LWluZGVudDot MTguMHB0OyBiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPmIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcu MHB0OyBmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SW5pdGlhbGx5IG1h aW50YWlucyBWUExTIGluc3RhbmNlcyBpbiBib3RoIEUxIGFuZCBQRTIsIGJ1dCB3aXRob3V0DQog b3ZlcmxhcCBiZXR3ZWVuIHRoZSBzZXRzIG9mIHRoZXNlIGluc3RhbmNlcyAoc28gdGhhdCB0aGVy ZSBpcyBubyBuZWVkIHRvIHNldHVwIFBXcyBiZXR3ZWVuIFBFMSBhbmQgUEUyKTwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojc0LjI1cHQ7 IHRleHQtaW5kZW50Oi0xOC4wcHQ7IGJhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Yy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5Vc2VzIEJHUC1iYXNlZCBhdXRvZGlzY292ZXJ5IG1lY2hhbmlzbXMgZm9yIFZQTFMg aW4gaXRzIG5ldHdvcmsNCiBhcyBkZXNjcmliZWQgaW4gUkZDIDYwNzQ8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3NC4yNXB0OyB0ZXh0 LWluZGVudDotMTguMHB0OyBiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPmQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0OyBmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SXMg cmVxdWlyZWQgdG8gZXh0ZW5kIG9uZSBvZiB0aGUgVlBMUyBpbnN0YW5jZXMgaXQgbWFpbnRhaW5z IGFuZA0KIHRoYXQgYWxyZWFkeSBoYXMgcHJlc2VuY2UgaW4gUEUxIHRvIGhhdmUgcHJlc2VuY2Ug YWxzbyBpbiBQRTI6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTEwLjI1cHQ7IHRleHQtaW5kZW50Oi0xMTAuMjVwdDsgYmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7OyBj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmkuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0OyBmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+V2l0aA0KIEJHUC1iYXNlZCBhdXRvZGlzY292ZXJ5LCBleHBs aWNpdCBjb25maWd1cmF0aW9uIG9mIGp1c3QgUEUyIHNob3VsZCBzdWZmaWNlLCB0aGUgcGVyc29u IChvciBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uKSB0aGF0IGV4dGVuZHMgdGhpcyBpbnN0YW5jZSBk b2VzIG5vdCBoYXZlIHRvIGtub3cgYWJvdXQgdGhlIHJlc3Qgb2YgdGhlIGxvY2F0aW9ucyB3aGVy ZSB0aGlzIFZQTFMgaW5zdGFuY2UgaXMgcHJlc2VudDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjExMC4yNXB0OyB0ZXh0LWluZGVudDot MTEwLjI1cHQ7IGJhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5p aS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OzsgY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUNCiBhdXRvZGlzY292ZXJ5IHBy b2Nlc3MgKHdoaWNoIGRvZXMgbm90IGRlcGVuZCBvbiBMRFApIGlkZW50aWZpZXMgUEUxIGFzIGEg cGVlciBmb3IgdGhlIFZQTFMgaW5zdGFuY2UgYmVpbmcgZGVmaW5lZCBpbiBQRTIsIHNvIHRoYXQg YSBQVyBiZXR3ZWVuIFBFMSBhbmQgUEUyIGlzIG5vdyByZXF1aXJlZA0KPC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTEwLjI1cHQ7IHRl eHQtaW5kZW50Oi0xMTAuMjVwdDsgYmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmlp aS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OzsgY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUNCiBQVyBzZXR1cCBwcm9jZXNz IGZpbmRzIGEgdGFyZ2V0ZWQgTERQIHNlc3Npb24gYmV0d2VlbiBQRTEgYW5kIFBFMiBhbmQgdHJp ZXMgdG8gdXNlIGl0IGZvciBzZXR0aW5nIHVwIHRoZSByZXF1aXJlZCBQVzwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjExMC4yNXB0OyB0 ZXh0LWluZGVudDotMTEwLjI1cHQ7IGJhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5p di48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OzsgY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Ib3dldmVyLA0KIFBXIHNldHVwIHdv dWxkIGZhaWxzIGJlY2F1c2UgZGlzdHJpYnV0aW9uIG9mIFBXIEZFQ3MgYWNyb3NzIHRoZSBhbHJl YWR5IGV4aXN0aW5nIHRhcmdldGVkIExEUCBzZXNzaW9uIGJldHdlZW4gUEUxIGFuZCBQRTIgaGFz IGJlZW4gZGlzYWJsZWQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzQuMjVwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdDsgYmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5lLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7OyBjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPklmIFBFMSBhbmQgUEUyIHN1cHBvcnQg4oCcRHlu YW1pYyBDYXBhYmlsaXR5IEFubm91bmNlbWVudOKAnSwgdGhpcw0KIGNvdWxkIGJlIGFtZW5kZWQg YnkgZW5hYmxpbmcgZGlzdHJpYnV0aW9uIG9mIFBXIEZFQ3MgcHJpb3IgdG8gc2V0dGluZyB0aGUg cmVxdWlyZWQgUFcuIEhvd2V2ZXIsIHRoaXMgd291bGQgcmVxdWlyZSBzdWJzdGFudGlhbCBjaGFu Z2VzIGluIHRoZSBleGlzdGluZyBQVyBzZXR1cCBwcm9jZWR1cmVzPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzQuMjVwdDsgdGV4dC1p bmRlbnQ6LTE4LjBwdDsgYmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj5mLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPklmIGV2ZW4gb25lIG9mIHRoZSBQRXMgZG9lcyBub3Qgc3VwcG9ydCDigJxEeW5hbWlj IENhcGFiaWxpdHkNCiBBbm5vdW5jZW1lbnTigJ0sIHRoZSBleGlzdGluZyB0YXJnZXRlZCBMRFAg c2Vzc2lvbiB3b3VsZCBoYXZlIHRvIGJlIHRvcm4gZG93biBhbmQgcmUtZXN0YWJsaXNoZWQgYWdh aW4uIFRoaXMgd291bGQgcHJvYmFibHkgaGF2ZSBzZXJpb3VzIGltcGxpY2F0aW9ucyBmb3IgdGhl IElDQ1AtYmFzZWQgcmVkdW5kYW5jeSBtZWNoYW5pc20uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzguMjVwdDsgdGV4dC1pbmRlbnQ6 LTE4LjBwdDsgYmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkEgc2lt aWxhciBzY2VuYXJpbyBjb3VsZCBiZSBlbmNvdW50ZXJlZCBpZiB0aGUgb3BlcmF0b3IgZW1wbG95 cw0KIGR5bmFtaWMgc2V0dXAgb2YgbXVsdGktc2VnbWVudCBQV3MsIGFuZCB0aGUgUFcgcm91dGlu ZyBtZWNoYW5pc20gZGVjaWRlcyB0aGF0IG9uZSBvZiB0aGUgc2VnbWVudHMgb2YgYSBuZXcgTVMt UFcgdG8gYmUgc2V0IHVwIHNob3VsZCBydW4gYmV0d2VlbiBQRTEgYW5kIFBFMi4gJm5ic3A7Jm5i c3A7U3VjaCBhIHNpdHVhdGlvbiBjb3VsZCBiZSBwcm9iYWJseSBwcmV2ZW50ZWQgaWYgdGhlIFBX IHJvdXRpbmcgbWVjaGFuaXNtIGNvdWxkIGxlYXJuIHRoYXQgUEUxIGFuZA0KIFBFMiBjYW5ub3Qg YmUg4oCcZGlyZWN0bHkgY29ubmVjdGVk4oCdLCBidXQsIHRvIHRoZSBiZXN0IG9mIG15IHVuZGVy c3RhbmRpbmcsIGl0IHdvdWxkIHJlcXVpcmUgY2hhbmdlcyBpbiB0aGUgYWxyZWFkeSBzdGFuZGFy ZGl6ZWQgTVMtUFcgcm91dGluZyBtZWNoYW5pc20uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtOyBiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207IGJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkkgaGF2 ZSBkaXNjdXNzZWQgdGhlc2UgY2FzZXMgd2l0aCB0aGUgYXV0aG9ycywgYnV0IHdlIGhhdmUgbm90 IHJlYWNoZWQgYW4gYWdyZWVtZW50IG9uIHRoZW0geWV0LiBGcm9tIG15IHBvaW50IG9mIHZpZXcs IHRoZSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudA0KIHNlY3Rpb24gc2hvdWxkIGFkZHJlc3MgdGhl c2UgY29uY2VybnMuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGNtOyBiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207IGJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkNvbnNpZGVyIG5vdyB0aGUgY2FzZSBk ZXNjcmliZWQgaW4gU2VjdGlvbiA1LjIgb2YgdGhlIGRyYWZ0LCB3aGVuIGEgdGFyZ2V0ZWQgTERQ IHNlc3Npb24gYmV0d2VlbiBQRTEgYW5kIFBFMiBpcyBpbml0aWFsbHkgdXNlZCBqdXN0IGZvciBk aXN0cmlidXRpb24NCiBvZiBzZXR1cCBvZiBQV3MsIHNvIHRoYXQgZGlzdHJpYnV0aW9uIG9mIFBy ZWZpeC1GRUNzIGlzIGRpc2FibGVkLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTsgYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtOyBiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZm9sbG93aW5n ICh2YWxpZCBmcm9tIG15IHBvaW50IG9mIHZpZXcpIHNjZW5hcmlvIHdvdWxkIG1ha2Ugc3VjaCBh IHNldHRpbmcgaGlnaGx5IHByb2JsZW1hdGljOjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM4LjI1cHQ7IHRleHQtaW5kZW50Oi0xOC4w cHQ7IGJhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+MS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgb3BlcmF0 b3IgdXNlcyBMRFAgZm9yIHNldHRpbmcg4oCcVHVubmVsIExTUHPigJ0gaW4gaXRzIG5ldHdvcms8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDozOC4yNXB0OyB0ZXh0LWluZGVudDotMTguMHB0OyBiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjIuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0OyBmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+TEZBLWJhc2VkIExEUCBGUlIgKGFzIHBlciZuYnNwOw0KPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjNTI4Ni8/aW5jbHVkZV90ZXh0 PTEiIHRhcmdldD0iX0JMQU5LIj4NClJGQyA1Mjg2PC9hPiBhbmQmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGd3Zy1yZW1vdGUtbGZh Lz9pbmNsdWRlX3RleHQ9MSIgdGFyZ2V0PSJfQkxBTksiPg0KUmVtb3RlIExGQSBkcmFmdDwvYT4p IGlzIHVzZWQgYXMgdGhlIG1lY2hhbmlzbSBmb3IgZmFzdCBwcm90ZWN0aW9uIGluIHRoZSBvcGVy YXRvcuKAmXMgbmV0d29yay48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDozOC4yNXB0OyB0ZXh0LWluZGVudDotMTguMHB0OyBiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjMuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0OyBmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SW5pdGlhbGx5IFBFMSBjYW4gcHJv dGVjdCBhbGwgdGhlIExTUHMgcGFzc2luZyB0aHJvdWdoIGl0IHVzaW5nDQoganVzdCBsb2NhbCBM RkEuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzguMjVwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdDsgYmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj40Ljwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBuZXR3b3JrIHRvcG9sb2d5IGNoYW5nZXMgKGUuZy4s IGJlY2F1c2UgbmV3IExTUnMgYXJlIGFkZGVkDQogdG8gaXQpLCBhbmQgaW4gb3JkZXIgdG8gcHJv dmlkZSB0aGUgcmVxdWlyZWQgY292ZXJhZ2UsIFBFMSBoYXMgdG8gdXNlIFBFMiBhcyBpdHMg4oCc cmVtb3RlIExGQeKAnSBmb3Igc29tZSBkZXN0aW5hdGlvbnMuDQo8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3NC4yNXB0OyB0ZXh0LWlu ZGVudDotMTguMHB0OyBiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPmEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0OyBmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhpcyB3b3VsZCByZXF1aXJlIGRpc3RyaWJ1dGlvbiBvZiBQcmVmaXgtRkVDcyBhY3Jvc3MgdGhl IHRhcmdldGVkDQogTERQIHNlc3Npb24gYmV0d2VlbiBQRTEgYW5kIFBFMiDigJMgYnV0IGl0IGhh cyBiZWVuIGRpc2FibGVkPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzQuMjVwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdDsgYmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5iLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7OyBjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPklmIFBFMiBkb2VzIG5vdCBzdXBwb3J0IOKAnER5 bmFtaWMgQW5ub3VuY2VtZW50IENhcGFiaWxpdHnigJ0sIHRoZW4NCiB0aGUgb25seSB3YXkgdG8g YW1lbmQgdGhlIHNpdHVhdGlvbiB3b3VsZCBiZSB0byB0ZWFyIGRvd24gdGhlIHRhcmdldGVkIExE UCBzZXNzaW9uIGJldHdlZW4gUEUxIGFuZCBQRTIgYW5kIHRvIHNldCBpdCB1cCBhZ2FpbiDigJMg YnV0IHRoaXMgd291bGQgbmVnYXRpdmVseSBhZmZlY3QgUFcgdHJhZmZpYyBiZXR3ZWVuIFBFMSBh bmQgUEUyLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6Mi4yNXB0OyBiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjIuMjVwdDsgYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+SSBoYXZlIGRpc2N1c3NlZCB0aGlzIGNhc2Ugd2l0aCB0aGUg YXV0aG9ycy4gVG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZywgdGhleSBoYXZlIGFncmVl ZCB0aGF0IGNvbWJpbmluZyBMRFAgRlJSIGJhc2VkIG9uIFJlbW90ZSBMRkFzIHdpdGggdGhlIG1l Y2hhbmlzbXMNCiBkZWZpbmVkIGluIHRoZSBkcmFmdCB3b3VsZCBiZSBoaWdobHkgcHJvYmxlbWF0 aWMsIGFuZCB3aWxsIGFkZCBzb21lIHN1aXRhYmxlIHRleHQgdG8gdGhlIEFwcGxpY2FiaWxpdHkg U3RhdGVtZW50IHNlY3Rpb24gaW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIGRyYWZ0Ljwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi4yNXB0OyBi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjIuMjVwdDsgYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoyLjI1cHQ7IGJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPk1pbm9yIElzc3Vlczwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi4yNXB0OyBiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0OyBiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0iIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGRy YWZ0IHN0YXRlcw0KIChpbiBzZWN0aW9uIDQuMikgdGhhdCBkZXNpcmUgb2YgYSBnaXZlbiBMU1Ig Jm5ic3A7b2YgcmVjZXB0aW9uIG9mIHVubmVjZXNzYXJ5IHN0YXRlIGZyb20gdGhlIHBlZXIgaXMg 4oCcdW5pbGF0ZXJhbCBhbmQgdW5pZGlyZWN0aW9uYWwgYnkgbmF0dXJl4oCdLg0KPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0 OyB0ZXh0LWluZGVudDotMTguMHB0OyBiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSIiPmEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5JTU8gdGhpcyBtYWtlcyBwZXJmZWN0IHNlbnNlIGZv ciBQcmVmaXgtRkVDcy4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdDsgYmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0iIj5iLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SG93ZXZlciwgUFcg RkVDcyBtdXN0IGFsd2F5cyBiZSBleGNoYW5nZSBpbiBib3RoIGRpcmVjdGlvbnMgb2YgJm5ic3A7 YSB0YXJnZXRlZCBMRFAgc2Vzc2lvbiwgc28gdGhhdA0KIGRpc2FibGluZyB0aGVpciBkaXN0cmli dXRpb24gaW4ganVzdCBvbmUgZGlyZWN0aW9uIHdvdWxkIGVmZmVjdGl2ZWx5IHByZXZlbnQgc2V0 dXAgb2YgUFdzIGJldHdlZW4gdGhlIGdpdmVuIHBhaXIgb2YgUEVzPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDsgYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4g c3R5bGU9IiI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkkgY29u Y3VyIHdpdGggQWRyaWFu4oCZcw0KIGNvbW1lbnQgaW4gaGlzIEFEIHJldmlldyBvZiB0aGUgZHJh ZnQgYWJvdXQgcHJvcG9zZWQgZW5jb2Rpbmcgb2Ygc3RhdGVzIG9mIG5vbi1pbnRlcmVzdC48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0OyBiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0iIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7SSBhbHNvIHdvbmRlciB3aGVuY2UNCiB0aGUgbmVlZCBmb3IgMTYgcG90 ZW50aWFsIHN0YXRlcyBvZiBub24taW50ZXJlc3QgaW4gdGhlIGRyYWZ0IHRoYXQsIHRvIHRoZSBi ZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcsIGRlYWxzIHdpdGggZXhhY3RseSA0IOKAnG9sZOKAnSBM RFAgYXBwbGljYXRpb25zLiBJJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Ij5ob3BlPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gdGhhdCB0aGlzIGRvZXMgbm90IGltcGx5 IHBvc3NpYmlsaXR5IG9mIGRldmVsb3BpbmcNCiBuZXcg4oCcb2xkLXN0eWxl4oCZIExEUCBhcHBs aWNhdGlvbnMgaW4gZnV0dXJlIChvciBkaXNjb3ZlcmluZyBzb21lIGZvcmdvdHRlbiBvbGQgb25l cz8pLjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SSBoYXZlIG5vdCB5ZXQg ZGlzY3Vzc2VkIHRoZXNlIGlzc3VlcyB3aXRoIHRoZSBhdXRob3JzIChhcyB3ZSBjb25jZW50cmF0 ZWQgb24gdGhlIG1ham9yIG9uZXMpLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5O aXRzPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj46PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Ob25lIGZvdW5kIGJ5IHRoZSBJ RE5JVFMgdG9vbC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5TcGVsbGluZyBhbmQgR3JhbW1hcjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SSBkZWZlciB0byB0aGUgRW5nbGlzaCBM YW5ndWFnZSByZXZpZXcgdGVhbS4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Ib3Bl ZnVsbHkgdGhlc2UgY29tbWVudHMgd2lsbCBiZSB1c2VmdWwuPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTYXNoYQ0KPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5FbWFpbDombmJzcDs8YSBocmVmPSJt YWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iPkFsZXhhbmRlci5WYWluc2h0 ZWluQGVjaXRlbGUuY29tPC9hPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+TW9iaWxlOiAmIzQzOzk3Mi01NC05MjY2MzAyPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_98715847e3ea4ffca171a4c870a2d2edAM3PR03MB612eurprd03pro_-- From nobody Wed Jul 30 12:46:13 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381651A032E; Wed, 30 Jul 2014 12:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqXduuYfuJWG; Wed, 30 Jul 2014 12:43:45 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F171A0201; Wed, 30 Jul 2014 12:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6644; q=dns/txt; s=iport; t=1406749425; x=1407959025; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BwdFXXkhoN7nhX7wLpk0LA0HQcdbO8ZtWjBa59gCxj8=; b=VvuBhjaXry7gIir0aXdw1hmTRP8u70PBMoAkOS1YXc8jXJKNX/W+Wbc5 EGrahJOXrN9caCpdkXL5Om5H41PT1IdX0N0x8Xch3sLEvIg0fRytYLXDn shent6vEPn3Ji2DVGT+ovNjRPfWg33KjUq4N3CSMjNW49i2K2H/WqGZDq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAI9K2VOtJV2a/2dsb2JhbABZgw6BLdJWAYEQFneEBAEBBDotEhACAQg2EDIlAgQOiEfAQBeJf4UaMweDL4EbBZtklFODSYFvBzs X-IronPort-AV: E=Sophos;i="5.01,766,1400025600"; d="scan'208";a="65256160" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 30 Jul 2014 19:43:44 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6UJhi3D022456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 19:43:44 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 14:42:59 -0500 From: "Sami Boutros (sboutros)" To: Mach Chen Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPcL43MdQKFwuY10i9fAzq1cK1Rpu5z3cA Date: Wed, 30 Jul 2014 19:43:43 +0000 Message-ID: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/BSvhggXy4GxSfMwIM4pUePDKEEY X-Mailman-Approved-At: Wed, 30 Jul 2014 12:46:10 -0700 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , Loa Andersson , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:43:48 -0000 Resending.. On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >>=20 >> Minor Issues:=20 >>=20 >> 1. Since the TTL TLV is defined for both MS-PW and bidirectional co-rout= ed >> LSP, it should be better to explicitly state this in the abstract sectio= n. >>=20 >=20 > Sami: Sure will do. >=20 >> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", "ec= ho >> request" and "request" are interchangeably used in the draft, it's bette= r to >> unify the usage of it to "MPLS echo request" (to align with the usage in >> RFC4379). For "echo reply", "bidirectional co-routed LSP", they have the >> similar issue. >>=20 >=20 > Sami: Ok, will fix that. >=20 >> 3.Section 3.1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Value | Reserved | Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> For the TTL TLV, the value filed should include the "value", "Reserved" = and >> "Flags", so it's better to change the "Value" field to "TTL" field hence= to >> reduce the confusion. >>=20 >=20 > Sami: Sure. >=20 >> 4. Section 3.2 >> "This TLV shall be included in the echo request by the originator of >> request. The use of this TLV is optional. If a receiver does not >> understand the TTL TLV, it will simply ignore the TLV (Type value of >> TLV is assumed to be in the range of optional TLV's which SHOULD be >> ignored if an implementation does not support or understand them). In >> the absence of TTL TLV or if TTL TLV is ignored by a receiver, the >> determination of the TTL value used in the MPLS label on the echo >> reply is beyond the scope of this document." >>=20 >> What's your mean of "beyond the scope of this document" here? Is it to >> apply the procedures defined in RFC4379 or just let it to the >> implementation?I guess you assume to apply the definition in RFC4379, >=20 > Sami: It is out of scope of this document, but for sure procedure in 4379= apply. >> if >=20 >> so, the TTL of the MPLS label will be more probably set to 255, means th= e >> echo reply will be sent to the ingress of the MS-PW or LSP. I am not sur= e >> whether this is the right procedure, it seems a security issue. IMHO, it >> does not make any sense to expect the receiver to send echo reply in thi= s >> situation, and even sent, the initiator will not receive the reply. The >> safer way is to drop the whole echo request and record an error log. >=20 >=20 > Sami:=20 >=20 > We are not saying the receiver must send a reply, however if he does the = reply > may be received by the ingress node which might be the wrong node, since= =20 > the receiver may not set the TTL properly on the reply, keep in mind that= this is=20 > a receiver with an old implementation and the TLV is optional. >=20 > Please refer to the security section for your security concern. >=20 > Sami: >=20 >=20 >>=20 >> 5. Section 3.2 >>=20 >> "In other words, if the value of the TTL provided by this TLV does not >> match the TTL >> determined by other means, such as Switching Point TLV in MS-PW, then >> TTL TLV must be used." >> Here, it implies that the receiver has to perform TTL matching process, >> since how to set the TTL is independent of such matching, seems this >> sentence is redundant and confusion. >>=20 >=20 > Sami: Are you familiar with the switching point TLV? and what it includes= ? >=20 >> 6. Section 4. >>=20 >> "...The value field of the TTL TLV and the TTL field of the MPLS label a= re >> set to 2," >>=20 >> I guess that the MPLS Label is the PW label, right? It's better to add m= ore >> text to make this more explicit. In addition, how to set the TTL value o= f >> the tunnel Label? 255 or any other value? >>=20 >=20 > Sami: The tunnel label TTL is irrelevant here, however we will make it ex= plicit that this is a PW label. >=20 >> 5. Section 4.1. Traceroute mode >> "In the traceroute mode TTL value in the TLV is successively set to 1, >> 2, and so on. This is similar to the TTL values used for the label >> set on the packet." >> IMHO, some text may be needed to clarify which "FEC" should be carried, >> especially for MS-PW trace. Since in Section 4.0, the example says the F= EC >> of segment C-D should be carried, does it mean the FEC of last PW Segmen= t of >> the segment under test should be carried or the FEC will vary when TTL >> changed. For example, when perform segment trace (e.g., to trace B-D >> segment), when TTL is 1, which FEC should be carried? >=20 > Sami:=20 > We are not here redefining a trace route for a MS-PW, we are describing = how our extensions will apply. > Sami: >=20 >>=20 >> 6. Section 4.2. Error scenario >> For this scenario, do you need to define some error codes here? >=20 > Sami:=20 > The section describe how to handle the error scenario, there is no need f= or an error code. > Sami: >=20 >>=20 >> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if so= , >> it should be explicitly stated. If not, you should define how the MS-PW >> trace works (given that the tunnels in both directions may span differen= t >> hops).=20 >=20 > Sami:=20 > Not sure I get the concern? Again we are not re-defining how MS-PW trace = work. >=20 > Thanks, >=20 > Sami >>=20 >> Nits:=20 >>=20 >> 1. Please check the text for acronyms that have not been expanded in the= ir >> first use. >>=20 >> 2. I run the idnits tool and found the following nits, please check and >> fix.=20 >> (See RFCs 3967 and 4897 for information about using normative >> references >> to lower-maturity documents in RFCs) >>=20 >> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 >>=20 >> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 >>=20 >> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit >> reference >> was found in the text >>=20 >> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit >> reference >> was found in the text >>=20 >> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit >> reference >> was found in the text >>=20 >> 3. Section 3.2, >> 3.1 first para first sentence >> s/shall/SHALL >> 3.2 last para, the last second sentence >> s/must/MUST >>=20 >> 4. The draft quotes the MS-PW and bidirectional co-routed LSP concept, i= t's >> better to add related references to this document. >>=20 >>=20 >> Best regards, >> Mach >>=20 >>=20 >=20 From nobody Wed Jul 30 12:46:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494DD1A02BC for ; Wed, 30 Jul 2014 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTXcdcugxWkX for ; Wed, 30 Jul 2014 11:00:11 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285A01A01C5 for ; Wed, 30 Jul 2014 11:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=101279; q=dns/txt; s=iport; t=1406743211; x=1407952811; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w2HOUoIxUmZxaK2TCAr/MnnS7ZLqTOG1YzzL+8gRuVI=; b=byErUwNq3cmtvSwcf8Je2zj4ynZsADxTIFa9A0zFRRJddsNS75SD3v1q Syaro4AUeBDqM/2CLQ4OivTd1nn1MkWkVgNje/3g/RV8pC2t76ni6SCCE BzaiMumyeYpKSRBJ5eOb1vYJucG6EkG7B9Qcp99lDGKwNyDP9yOyWEzMA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMIAMAx2VOtJA2N/2dsb2JhbABWA4JHR1JXBLJWllKBWAELh0kBgRAWd4QDAQEBBBoTIRgHBwUOAgIBCAcKAwEBAQ0JCwEGBxsLCwEUCQgBAQQOAQMBAQgUBIghDaoElhQXBIE/iDyEaxEBGQsBBQIMBwEMBAYBAgQDAQeCeoE/BY0qgTuIWYQmgVKTAYNJbAEGfgcXIg X-IronPort-AV: E=Sophos; i="5.01,765,1400025600"; d="scan'208,217"; a="65231180" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 30 Jul 2014 18:00:09 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6UI097J007228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 18:00:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 13:00:09 -0500 From: "Kamran Raza (skraza)" To: "adrian@olddog.co.uk" Thread-Topic: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Thread-Index: Ac9tIpHty7MH85zjQlWHldfu8Tbv0Q+/c2sAAAIGHYA= Date: Wed, 30 Jul 2014 18:00:07 +0000 Message-ID: References: <2baf5ec74dbf42929b973c99cae1b1bd@AM3PR03MB612.eurprd03.prod.outlook.com> <02ca01cfabf6$7a2a70e0$6e7f52a0$@olddog.co.uk> In-Reply-To: <02ca01cfabf6$7a2a70e0$6e7f52a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [161.44.213.21] Content-Type: multipart/alternative; boundary="_000_CFFEAA8EA8C5Fskrazaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/hHfHSW6Kb4LJIxej21X0z2QYUvA X-Mailman-Approved-At: Wed, 30 Jul 2014 12:46:22 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" , 'Alexander Vainshtein' , "Sami Boutros \(sboutros\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 18:00:20 -0000 --_000_CFFEAA8EA8C5Fskrazaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adrian, Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had to s= chedule the meeting post IETF as Sasha did not attend. We are meeting tomorrow with Sasha to clarify/converge. Thanks. Kamran Raza TECHNICAL LEADER.ENGINEERING Product Development skraza@cisco.com Phone: +1 613 254 4520 Cisco.com Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J = 2T3. Phone: 416-306-7000; Fax: 416-306-7099. Preferences - Unsubs= cribe =96 Privacy<= http://www.cisco.com/web/siteassets/legal/privacy.html> [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before = you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, July 30, 2014 at 9:02 AM To: Syed Kamran Raza > Cc: "rtg-dir@ietf.org" >, "Sami Boutros (sboutros)" >, "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org<= mailto:draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>" >, 'Alexander Vainshtein' >, "rtg-ads@too= ls.ietf.org" > Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Kamran, Thanks for responding to the question in the GenArt review. Do you have any responses to Sasha's review (copied below)? cheers, Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 11 May 2014 15:09 To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-c= apability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros= (sboutros@cisco.com) Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts 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.i= etf.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-mpls-ldp-ip-pw-capability-07.txt Reviewer: Alexander (=93Sasha=94) Vainshtein Review date: 11-May-14 IETF LC End Date: 12-May-14 Intended status: Standards Track Summary: I have significant concerns about this document and recommend that the Rout= ing ADs discuss these issues further with the authors. These concerns mainly deal with potential negative impact of the mechanisms= (introduced in the draft) for disabling =93non-negotiable=94 capabilities = of LDP sessions with the techniques that could dynamically change the stat= e of =93interest=94 in these capabilities for a given LDP session. Some of these mechanisms are already standardized by the IETF, e.g., L2VP= N auto-discovery (RFC 6074) and dynami= c placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others - LDP FRR using remote loop-free adjacencies (draft-ie= tf-rtgwg-remote-lfa)- are in advanced stages of the IETF process. I must admit that I did not follow closely the discussion of the draft in = question in the MPLS WG; so it may well be that some of my concerns have be= en already raised, considered and found not relevant. I also do not know if the draft has ever been discussed in the PWE3, L2VPN = and RTG WGs. One possible way to address these concerns would be by adding an Applicabil= ity Statement section to the draft and discussing potentially problematic c= ombinations of mechanisms there. I have discussed this option with the authors and, to the best of my unders= tanding, they have in general agreed to add such a section to the next revi= sion of the draft. General comments: To the best of my understanding the sole purpose of the draft is preventio= n of =93 wasteful=94 distribution of state dealing with two non-negotiable = classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes = defined in RFC 5036) and PW FECs (i.e. = PW Id FEC and Generalized PW Id FEC defined in RFC 4447) to LDP peers that are =93not interested=92 in this state.= Such unnecessary distribution would result in unnecessary waste of resourc= es (memory and/or CPU cycles) and hence should be avoided. The draft mentions that: To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments. The draft, however, does not mention that filtering policies provide much f= iner granularity of control over distribution of labels than that supported= by the mechanism introduced in the draft. E.g., in a scenario when LDP is supposed to set up only =93tunnel LSPs=94 b= etween PEs for L2 and L3 VPN applications, an appropriate policy allow dist= ribution of the just the FECs associated with Router IDs of the PEs but not= , say FECs associated with the subnets of their core-facing interfaces. IMH= O and FWIW this means that support of the mechanism defined in the draft wo= uld not eliminate the need for the filtering policies. I have discussed this point with the authors and they have agreed to add so= me clarifying text. I have also failed to understand how distribution of PW FECs could be waste= ful. Section 5.3.3 =93Signaling Procedures=94 of RFC 4447 explicitly states that: In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure. The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). My reading of the quoted text is that PW FECs are only distributed across t= argeted LDP sessions with the known Remote PEs for specific PWs. AFAIK, this is what actually happens in most existing implementations of PW= signaling with RFC 4447. What=92s more, many implementations, when required to set up a PW with a sp= ecific remote PE, check for existence of a targeted LDP session with this P= E, and set it up implicitly if it does not exist; then they distribute PW F= EC-to-label binding via this session only. Implicit targeted LDP sessions a= re also implicitly torn down when the last PW between the given pair of PE= s is torn down. I have discussed this point with the authors, but, as of the moment of writ= ing this review, we did not yet reach full agreement on it. Readability of the draft: Initially I have failed to understand the following text fragment in the dr= aft (the problematic statements are marked with italics): For Prefix-LSPs application type, the non-interesting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings as a non-interesting state and allows the advertisement of IP Address bindings to facilitate other LDP applications (such as mLDP) that depend on learning of peer addresses over an LDP session for their correct operation. After discussing this point with the authors I=92ve understood that they re= fer to exchange of the LSR addresses in the Address and Address Withdraw me= ssages that is required for mapping Next Hop IP addresses computed by the I= GP to Next Hop LSR. While initial misunderstanding may be specific to me, = I have suggested to the authors to clarify this point with explicit referen= ces to specific LDP messages and sections of RFC 5036. Major Issue: The draft, which builds on the mechanisms defined in RFC 5561, defines two ways to manipu= late distribution of =93non-interesting state=94, since by default it would= be enabled =B7 In the Initialization message. I assume that in this case the o= nly valid use case would be disabling distribution of non-interesting state =B7 In the Capability message. This method could be both to disable= and re-enable distribution of state, but it could only be used if the peer= supports =93Dynamic Announcement Capability=94. My concern stems from the fact that the draft deals with =93old=94 LDP appl= ications, so that the possibility that distribution of FEC-to-Label binding= s can be unilaterally disabled for PW- and Prefix-FECs is not taken into ac= count in the existing deployments and mechanisms. Here is a couple of examples: Consider the case when a targeted LDP session between PE1 and PE2 has been = set just for the purpose of running ICCP between these devices (i.e., in th= e terms of the ICCP draft they belong to the same RG). According to the exa= mple in Section 5.1 of the draft, the PEs could then disable distribution o= f both PW FECs and Prefix-FECs across such a session in their appropriate I= nitialization messages. The following (valid from my point of view) scenarios would make such a set= ting highly problematic: 1. The operator that manages both PE1 and PE2: a. Maintains some VPLS instances in its network b. Initially maintains VPLS instances in both E1 and PE2, but without = overlap between the sets of these instances (so that there is no need to se= tup PWs between PE1 and PE2) c. Uses BGP-based autodiscovery mechanisms for VPLS in its network as= described in RFC 6074 d. Is required to extend one of the VPLS instances it maintains and th= at already has presence in PE1 to have presence also in PE2: i. Wit= h BGP-based autodiscovery, explicit configuration of just PE2 should suffic= e, the person (or management application) that extends this instance does n= ot have to know about the rest of the locations where this VPLS instance is= present ii. The= autodiscovery process (which does not depend on LDP) identifies PE1 as a p= eer for the VPLS instance being defined in PE2, so that a PW between PE1 an= d PE2 is now required iii. The = PW setup process finds a targeted LDP session between PE1 and PE2 and tries= to use it for setting up the required PW iv. Howev= er, PW setup would fails because distribution of PW FECs across the already= existing targeted LDP session between PE1 and PE2 has been disabled. e. If PE1 and PE2 support =93Dynamic Capability Announcement=94, this = could be amended by enabling distribution of PW FECs prior to setting the r= equired PW. However, this would require substantial changes in the existing= PW setup procedures f. If even one of the PEs does not support =93Dynamic Capability Ann= ouncement=94, the existing targeted LDP session would have to be torn down = and re-established again. This would probably have serious implications for= the ICCP-based redundancy mechanism. 2. A similar scenario could be encountered if the operator employs dy= namic setup of multi-segment PWs, and the PW routing mechanism decides that= one of the segments of a new MS-PW to be set up should run between PE1 and= PE2. Such a situation could be probably prevented if the PW routing mech= anism could learn that PE1 and PE2 cannot be =93directly connected=94, but,= to the best of my understanding, it would require changes in the already s= tandardized MS-PW routing mechanism. I have discussed these cases with the authors, but we have not reached an a= greement on them yet. From my point of view, the Applicability Statement se= ction should address these concerns. Consider now the case described in Section 5.2 of the draft, when a targete= d LDP session between PE1 and PE2 is initially used just for distribution o= f setup of PWs, so that distribution of Prefix-FECs is disabled. The following (valid from my point of view) scenario would make such a sett= ing highly problematic: 1. The operator uses LDP for setting =93Tunnel LSPs=94 in its network 2. LFA-based LDP FRR (as per RFC 5286 and Remote LFA draft) is used as the mech= anism for fast protection in the operator=92s network. 3. Initially PE1 can protect all the LSPs passing through it using ju= st local LFA. 4. The network topology changes (e.g., because new LSRs are added to = it), and in order to provide the required coverage, PE1 has to use PE2 as i= ts =93remote LFA=94 for some destinations. a. This would require distribution of Prefix-FECs across the targeted= LDP session between PE1 and PE2 =96 but it has been disabled b. If PE2 does not support =93Dynamic Announcement Capability=94, then= the only way to amend the situation would be to tear down the targeted LDP= session between PE1 and PE2 and to set it up again =96 but this would nega= tively affect PW traffic between PE1 and PE2. I have discussed this case with the authors. To the best of my understandin= g, they have agreed that combining LDP FRR based on Remote LFAs with the me= chanisms defined in the draft would be highly problematic, and will add som= e suitable text to the Applicability Statement section in the next revision= of the draft. Minor Issues: 1. The draft states (in section 4.2) that desire of a given LSR of r= eception of unnecessary state from the peer is =93unilateral and unidirecti= onal by nature=94. a. IMO this makes perfect sense for Prefix-FECs. b. However, PW FECs must always be exchange in both directions of a t= argeted LDP session, so that disabling their distribution in just one direc= tion would effectively prevent setup of PWs between the given pair of PEs 2. I concur with Adrian=92s comment in his AD review of the draft abo= ut proposed encoding of states of non-interest. 3. I also wonder whence the need for 16 potential states of non-inte= rest in the draft that, to the best of my understanding, deals with exactly= 4 =93old=94 LDP applications. I hope that this does not imply possibility = of developing new =93old-style=92 LDP applications in future (or discoverin= g some forgotten old ones?). I have not yet discussed these issues with the authors (as we concentrated = on the major ones). Nits: None found by the IDNITS tool. Spelling and Grammar: I defer to the English Language review team. Hopefully these comments will be useful. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: +972-54-9266302 --_000_CFFEAA8EA8C5Fskrazaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Adrian,

Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had= to schedule the meeting post IETF as Sasha did not attend.
We are meeting tomorrow with Sasha to clarify/converge.

Thanks.

Kamran Raza
TECHNICAL LEADER.ENGINEERING
Product Development
skraza@cisco.com
Phone: +1 613 254 4520


Cisco.com
Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toro= nto, ON, Canada, M5J 2T3. Phone: 416-306-7000; Fax: 416-306-7099.
Preferences - Unsubscribe =96 Privacy

 Think before you print.

This email may contain conf= idential and privileged material for the sole use of the intended recipient= . Any review, use, distribution or disclosure by others is strictly prohibi= ted. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by= reply email and delete all copies of this message.

Please click here for= Company Registration Information.


From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Wednesday, July 30, 2014 at 9= :02 AM
To: Syed Kamran Raza <skraza@cisco.com>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "Sami Boutros (sboutros)" <sboutros@cisco.com>, "draft-i= etf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" <draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, 'Alex= ander Vainshtein' <A= lexander.Vainshtein@ecitele.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org&g= t;
Subject: RE: RTG-DIR Review: draft-= ietf-mpls-ldp-ip-pw-capability-07.txt

Kamran,

 

Thanks for responding to the question in the GenArt review.

 

Do you have any responses to Sasha's review (copied below)?

 

cheers,

Adrian

 

From: Alexander Vainshtei= n [mailto:Alexander.Vai= nshtein@ecitele.com]
Sent: 11 May 2014 15:09
To: rtg-ads@tools.ietf.org=
Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (s= boutros@cisco.com)
Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt=

 

H= ello,

&= nbsp;

I= have been selected as the Routing Directorate reviewer for this draft.

T= he Routing Directorate seeks to review all routing or routing-related draft= s as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Rou= ting ADs.

F= or more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html=

&= nbsp;

A= lthough 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. <= o:p>

&= nbsp;

D= ocument: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

R= eviewer: Alexander (=93Sasha=94) Vainshtein    <= o:p>

R= eview date: 11-May-14

I= ETF LC End Date: 12-May-14

I= ntended status: Standards Track <= o:p>

&= nbsp;

:

&= nbsp;

I= have significant concerns about this document and recommend that the Routi= ng ADs discuss these issues further with the authors.

T= hese concerns mainly deal with potential negative impact of the mechanisms = (introduced in the draft) for disabling =93non-negotiable=94 capabilities of LDP sessions  with the technique= s that could dynamically change the state of =93interest=94 in these capabi= lities for a given LDP session. 

S= ome of these mechanisms are already standardized by the IETF, e.g.,  &= nbsp;L2VPN auto-discovery (R= FC 6074) and  dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others -  LDP FRR= using remote loop-free adjacencies (draft-ietf-rtgwg-remot= e-lfa)- are in advanced stages of the IETF process.   =

<= o:p> 

&= nbsp;

I= must admit that I did not follow closely the discussion of  the draft= in question in the MPLS WG; so it may well be that some of my concerns have been already raised, considered and found no= t relevant.

I= also do not know if the draft has ever been discussed in the PWE3, L2VPN a= nd RTG WGs.

 

O= ne possible way to address these concerns would be by adding an Applicabili= ty Statement section to the draft and discussing potentially problematic combinations of mechanisms there.

I= have discussed this option with the authors and, to the best of my underst= anding, they have in general agreed to add such a section to the next revision of the draft.

 

:

To the best of my understanding t= he sole purpose of the draft is  prevention of =93 wasteful=94 distrib= ution of state dealing with two non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined= in RFC 5036) and PW FECs (i.e. PW Id FEC and Generalized PW Id FEC defined= in RFC 4447) to LDP peers that are =93not interested=92 in this state. Suc= h unnecessary distribution would result in unnecessary waste of resources (= memory and/or CPU cycles) and hence should be avoided.  

 

The draft mentions that:

<quote>

  To avoid this unnecessary state advertisement and exchange,= currently <= o:p>

  an operator is typically required to configure and def= ine filtering <= o:p>

  policies on the LSR, which introduces unnecessary oper= ational <= o:p>

  overhead and complexity for such deployments.  <= o:p>

<end quote>

 

The draft, however, does not ment= ion that filtering policies provide much finer granularity of control over = distribution of labels than that supported by the mechanism introduced in the draft.

E.g., in a scenario when LDP is s= upposed to set up only =93tunnel LSPs=94 between PEs for L2 and L3 VPN appl= ications, an appropriate policy allow distribution of the just the FECs associated with Router IDs of the PEs but not, say FE= Cs associated with the subnets of their core-facing interfaces. IMHO and FW= IW this means that support of the mechanism defined in the draft would not = eliminate the need for the filtering policies.

 

I have discussed this point with = the authors and they have agreed to add some clarifying text.

 

I have also failed to understand = how distribution of PW FECs could be wasteful. Section 5.3.3  =93Signa= ling Procedures=94 of RFC 4447 explicitly stat= es that:

<quote> 

   In order for =
PE1 to begin signaling PE2, PE1 must know the address of<=
/pre>

   the remote PE=
2, and a TAI.  This information may have been configured


   at PE1, or it=
 may have been learned dynamically via some


   autodiscovery=
 procedure.


 

   The egress PE=
 (PE1), which has knowledge of the ingress PE, initiates<=
/pre>

   the setup by =
sending a Label Mapping Message to the ingress PE (PE2).<=
/pre>

<end quote>


 


My reading of the quoted text is =
that PW FECs are only distributed across targeted LDP sessions with the kno=
wn Remote PEs for specific PWs.


AFAIK, this is what actually happ=
ens in most existing implementations of PW signaling with RFC 4447.



What=92s more, many implementatio=
ns, when required to set up a PW with a specific remote PE, check for exist=
ence of a targeted LDP session with this PE,
 and set it up implicitly if it does not exist; then they distribute PW FEC=
-to-label binding via this session only. Implicit targeted LDP sessions are=
 also implicitly torn down when the last PW between  the given pair of=
 PEs is torn down.


I have discussed this point with =
the authors, but, as of the moment of writing this review,  we did not=
 yet reach full agreement on it.  


 


Readability of the draft:


 


Initially I have failed to unders=
tand the following text fragment in the draft (the problematic statements a=
re marked with
italics):


<quote>

   For Prefix-LSPs app=
lication type, the non-interesting state refers 


   to any state r=
elated to IP Prefix FEC (such as FEC label bindings, 

   LDP Status). <=
i>This document, however, does not classify IP address 


   bindings as=
 a non-interesting state and allows the advertisement of 


   IP Address =
bindings to facilitate other LDP applications (such as 


   mLDP) that =
depend on learning of peer addresses over an LDP session 


   for their c=
orrect operation.


<end quote>


After discussing this point with =
the authors I=92ve understood that they refer to exchange of the LSR addres=
ses in the Address and Address Withdraw messages that
 is required for mapping Next Hop IP addresses computed by the IGP to Next =
Hop LSR. While initial misunderstanding may be specific to me,  I have=
 suggested to the authors to clarify this point with explicit references to=
 specific LDP messages and sections of
RFC 5036.


 


Major Issue:


 


The draft, which builds on the me=
chanisms defined in
RFC =
5561,  defines two ways to manipulate distribution of =93non-inter=
esting state=94, since by default it would be enabled



=B7        
I=
n the Initialization message. I assume that in this case the only valid use=
 case would be disabling distribution of non-interesting state



=B7        
I=
n the Capability message. This method could be both to disable and re-enabl=
e distribution of state, but it could only be used if the peer supports =93=
Dynamic Announcement Capability=94.


 


My concern stems from the fact th=
at the draft deals with =93old=94 LDP applications, so that the possibility=
 that distribution of FEC-to-Label bindings
 can be unilaterally disabled for PW- and Prefix-FECs is not taken into acc=
ount in the existing deployments and mechanisms.


 


Here is a couple of examples:


 


Consider the case when a targeted=
 LDP session between PE1 and PE2 has been set just for the purpose of runni=
ng ICCP between these devices (i.e., in
 the terms of the ICCP draft they belong to the same RG). According to the =
example in Section 5.1 of the draft, the PEs could then disable distributio=
n of both PW FECs and Prefix-FECs across such a session in their appropriat=
e Initialization messages.


 


The following (valid from my poin=
t of view) scenarios would make such a setting highly problematic:



1.      
T=
he operator that manages both PE1 and PE2:



a.      
M=
aintains some  VPLS instances in its network



b.     
I=
nitially maintains VPLS instances in both E1 and PE2, but without overlap b=
etween the sets of these instances (so that there is no need to setup PWs b=
etween PE1 and PE2)



c.      
U=
ses BGP-based autodiscovery mechanisms for VPLS in its network as described=
 in RFC 6074



d.     
I=
s required to extend one of the VPLS instances it maintains and that alread=
y has presence in PE1 to have presence also in PE2:



     
W=
ith BGP-based autodiscovery, explicit configuration of just PE2 should suff=
ice, the person (or management application) that extends this instance does=
 not have to know about the rest of
 the locations where this VPLS instance is present



     
T=
he autodiscovery process (which does not depend on LDP) identifies PE1 as a=
 peer for the VPLS instance being defined in PE2, so that a PW between PE1 =
and PE2 is now required




     
T=
he PW setup process finds a targeted LDP session between PE1 and PE2 and tr=
ies to use it for setting up the required PW



     
H=
owever, PW setup would fails because distribution of PW FECs across the alr=
eady existing targeted LDP session between PE1 and PE2 has been disabled.



e.     
I=
f PE1 and PE2 support =93Dynamic Capability Announcement=94, this could be =
amended by enabling distribution of PW FECs prior to setting the required P=
W. However, this would require substantial
 changes in the existing PW setup procedures



f.       
I=
f even one of the PEs does not support =93Dynamic Capability Announcement=
=94, the existing targeted LDP session would have to be torn down and re-es=
tablished again. This would probably have
 serious implications for the ICCP-based redundancy mechanism.



2.      
A=
 similar scenario could be encountered if the operator employs dynamic setu=
p of multi-segment PWs, and the PW routing mechanism decides that one of th=
e segments of a new MS-PW to be set
 up should run between PE1 and PE2.   Such a situation could be p=
robably prevented if the PW routing mechanism could learn that PE1 and PE2 =
cannot be =93directly connected=94, but, to the best of my understanding, i=
t would require changes in the already standardized
 MS-PW routing mechanism.


 


I have dis=
cussed these cases with the authors, but we have not reached an agreement o=
n them yet. From my point of view, the Applicability
 Statement section should address these concerns.


 =
;


Consider n=
ow the case described in Section 5.2 of the draft, when a targeted LDP sess=
ion between PE1 and PE2 is initially used
 just for distribution of setup of PWs, so that distribution of Prefix-FECs=
 is disabled.


 


The follow=
ing (valid from my point of view) scenario would make such a setting highly=
 problematic:



1.      
T=
he operator uses LDP for setting =93Tunnel LSPs=94 in its network



2.      
L=
FA-based LDP FRR (as per
RFC =
5286 and

Remote LFA draft) is used as the mechanism for fast protection in the o=
perator=92s network.



3.      
I=
nitially PE1 can protect all the LSPs passing through it using just local L=
FA.



4.      
T=
he network topology changes (e.g., because new LSRs are added to it), and i=
n order to provide the required coverage, PE1 has to use PE2 as its =93remo=
te LFA=94 for some destinations.




a.      
T=
his would require distribution of Prefix-FECs across the targeted LDP sessi=
on between PE1 and PE2 =96 but it has been disabled



b.     
I=
f PE2 does not support =93Dynamic Announcement Capability=94, then the only=
 way to amend the situation would be to tear down the targeted LDP session =
between PE1 and PE2 and to set it up again
 =96 but this would negatively affect PW traffic between PE1 and PE2.<=
/o:p>


 


I have discuss=
ed this case with the authors. To the best of my understanding, they have a=
greed that combining LDP FRR based on Remote
 LFAs with the mechanisms defined in the draft would be highly problematic,=
 and will add some suitable text to the Applicability Statement section in =
the next revision of the draft.


 


 


Minor Issue=
s:


 



1.      
The draft states (in section 4.2) that desire of=
 a given LSR  of reception of unnecessary state from the peer is =93un=
ilateral and unidirectional by nature=94.




a.      
IMO this makes perfect sense for Prefix-FECs.




b.     
However, PW FECs must always be exchange in both=
 directions of  a targeted LDP session, so that disabling their distri=
bution in just one direction would effectively
 prevent setup of PWs between the given pair of PEs



2.      
I concur with Adrian=92s comment in his AD revie=
w of the draft about proposed encoding of states of non-interest.



3.      
 I also wonder whence the need for 16 poten=
tial states of non-interest in the draft that, to the best of my under=
standing, deals with exactly 4 =93old=94 LDP applications.
 I hope that this does not imply possibility of developing n=
ew =93old-style=92 LDP applications in future (or discovering some forgotte=
n old ones?).


 


I have not yet discussed these is=
sues with the authors (as we concentrated on the major ones).


 


Nits:


None found by the IDNITS tool.


 


 


Spelling and Grammar:<=
/o:p>


I defer to the English Language r=
eview team.



 


Hopefully these comments will be =
useful.


 


Regards,


     &nb=
sp; Sasha



Email:
Alexander.Vainshtein@ec=
itele.com


Mobile: +972-54-9266302<=
/o:p>


 
--_000_CFFEAA8EA8C5Fskrazaciscocom_-- From nobody Wed Jul 30 15:16:50 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0C1A05C0 for ; Wed, 30 Jul 2014 15:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTpKGIuGihkj for ; Wed, 30 Jul 2014 15:16:37 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF29F1A01AA for ; Wed, 30 Jul 2014 15:16:35 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6UMGOdP007601; Wed, 30 Jul 2014 23:16:24 +0100 Received: from 950129200 ([200.130.255.1]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6UMGHxO007541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 23:16:19 +0100 From: "Adrian Farrel" To: "'Kamran Raza \(skraza\)'" References: <2baf5ec74dbf42929b973c99cae1b1bd@AM3PR03MB612.eurprd03.prod.outlook.com> <02ca01cfabf6$7a2a70e0$6e7f52a0$@olddog.co.uk> In-Reply-To: Date: Wed, 30 Jul 2014 23:16:21 +0100 Message-ID: <005401cfac43$e76b9f10$b642dd30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0055_01CFAC4C.493BEDF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5dxMs+oaAUnzdi3sEUonP+cPrIwKFi4+cAi/ERhGaP+6ykA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20850.002 X-TM-AS-Result: No--29.762-10.0-31-10 X-imss-scan-details: No--29.762-10.0-31-10 X-TMASE-MatchedRID: OoEa6u7Uk5/uYusHgJkgynPacKDoX0vPMxVjmK1sOgMIvXJhQQTwfuvE TfHMaqizONMIq6tJjPVHdhuYYkLbTMzFNBdwq3l+EtdrY/Wb3fPYS1qoqSmAs/zNCg0YCtjvnK6 NH0kJeVqEQ6fCoGYP1yA+hAZZidnjsFkCLeeufNvAMyYDvAr9pnQJ0T3rcVkLoNHoTHGfOdKdaZ 8GemxrgM8bFMQN3nGuS4Q3I/LeUOc65i/3MEClPC80/gzJzfIR+Cckfm+bb6AGM1PEXPYYiuNQd sUacxp9qDXCa0DU7LcuaG2Mwsx7IDahjZPEodkXz1luCiC8bwRffSkyb6LPSAqEOaaKoFK3pVdM iW33wf+x/IsbGBsvcdDayMIPbRSlZlRzaO1xpJ0lUwMLwz1QzxyE6r2or4AaLrvR7aAmJFj5Ze+ whhhm9al8sEIkt5Bhn8kT944y5fdLxLYX2WS870MYW8F4HadcSm/fS2gAxvppxmgQfRgShCvUsM XkPP/x4I5dk7crHP/tvMVN/9JMyhNEPNwNrw/rq42z3mLQna7QNIRrNw4jpLgA+zkAs/dTYRxVj 9/2xAqe+4FA0oHroyC92D94UBz+oxWB033D5MKUWmF9Epiq6onqJzDYczEQKDkR2MDyn9zswJyg 33osaye858LUHn00WF08SJkeWby7vYqkCS0dL1NfPqmlqqgMub0OdICB/orLQTjZGXu14A2dMJP LSwJxjjTaQl7lJACd5MMyOelRHdWxbZgaqhS0myqQJWNsuklzwVmY5TMrNnpe6c6J9YF704kWrN 1eItczpHlwH+mURXdcpuk3AlAunhHKNOYbLL7G0EHapv1eJ2RinB1Mnjd9lR1cT9YafQV95l0nV eyiuG/8zizTBYnkWe3zo5eSMXB19LjmGa81g/5uAMTUsGowGD3o2DVQwD/BLuRC5H70nj9fIezg Yr5Buji9vjEJWfnQFuCHJYPNNw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/MhOtOkLKslnQ4mCJA9_oFtpGh18 Cc: rtg-dir@ietf.org, draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org, 'Alexander Vainshtein' , "'Sami Boutros \(sboutros\)'" , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 22:16:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01CFAC4C.493BEDF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0056_01CFAC4C.493BEDF0" ------=_NextPart_001_0056_01CFAC4C.493BEDF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is very excellent. Thank you for going the extra mile to sort things out. A From: Kamran Raza (skraza) [mailto:skraza@cisco.com] Sent: 30 July 2014 19:00 To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami Boutros (sboutros); draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander Vainshtein'; rtg-ads@tools.ietf.org Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hi Adrian, Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had to schedule the meeting post IETF as Sasha did not attend. We are meeting tomorrow with Sasha to clarify/converge. Thanks. Kamran Raza TECHNICAL LEADER.ENGINEERING Product Development skraza@cisco.com Phone: +1 613 254 4520 Cisco.com Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J 2T3. Phone: 416-306-7000; Fax: 416-306-7099. Preferences - Unsubscribe - Privacy Image removed by sender. Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here for Company Registration Information. From: Adrian Farrel Reply-To: "adrian@olddog.co.uk" Date: Wednesday, July 30, 2014 at 9:02 AM To: Syed Kamran Raza Cc: "rtg-dir@ietf.org" , "Sami Boutros (sboutros)" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" , 'Alexander Vainshtein' , "rtg-ads@tools.ietf.org" Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Kamran, Thanks for responding to the question in the GenArt review. Do you have any responses to Sasha's review (copied below)? cheers, Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 11 May 2014 15:09 To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (sboutros@cisco.com) Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt 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-mpls-ldp-ip-pw-capability-07.txt Reviewer: Alexander ("Sasha") Vainshtein Review date: 11-May-14 IETF LC End Date: 12-May-14 Intended status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. These concerns mainly deal with potential negative impact of the mechanisms (introduced in the draft) for disabling "non-negotiable" capabilities of LDP sessions with the techniques that could dynamically change the state of "interest" in these capabilities for a given LDP session. Some of these mechanisms are already standardized by the IETF, e.g., L2VPN auto-discovery (RFC 6074 ) and dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw ) while others - LDP FRR using remote loop-free adjacencies (draft-ietf-rtgwg-remote-lfa )- are in advanced stages of the IETF process. I must admit that I did not follow closely the discussion of the draft in question in the MPLS WG; so it may well be that some of my concerns have been already raised, considered and found not relevant. I also do not know if the draft has ever been discussed in the PWE3, L2VPN and RTG WGs. One possible way to address these concerns would be by adding an Applicability Statement section to the draft and discussing potentially problematic combinations of mechanisms there. I have discussed this option with the authors and, to the best of my understanding, they have in general agreed to add such a section to the next revision of the draft. General comments: To the best of my understanding the sole purpose of the draft is prevention of " wasteful" distribution of state dealing with two non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined in RFC 5036 ) and PW FECs (i.e. PW Id FEC and Generalized PW Id FEC defined in RFC 4447 ) to LDP peers that are "not interested' in this state. Such unnecessary distribution would result in unnecessary waste of resources (memory and/or CPU cycles) and hence should be avoided. The draft mentions that: To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments. The draft, however, does not mention that filtering policies provide much finer granularity of control over distribution of labels than that supported by the mechanism introduced in the draft. E.g., in a scenario when LDP is supposed to set up only "tunnel LSPs" between PEs for L2 and L3 VPN applications, an appropriate policy allow distribution of the just the FECs associated with Router IDs of the PEs but not, say FECs associated with the subnets of their core-facing interfaces. IMHO and FWIW this means that support of the mechanism defined in the draft would not eliminate the need for the filtering policies. I have discussed this point with the authors and they have agreed to add some clarifying text. I have also failed to understand how distribution of PW FECs could be wasteful. Section 5.3.3 "Signaling Procedures" of RFC 4447 explicitly states that: In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure. The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). My reading of the quoted text is that PW FECs are only distributed across targeted LDP sessions with the known Remote PEs for specific PWs. AFAIK, this is what actually happens in most existing implementations of PW signaling with RFC 4447. What's more, many implementations, when required to set up a PW with a specific remote PE, check for existence of a targeted LDP session with this PE, and set it up implicitly if it does not exist; then they distribute PW FEC-to-label binding via this session only. Implicit targeted LDP sessions are also implicitly torn down when the last PW between the given pair of PEs is torn down. I have discussed this point with the authors, but, as of the moment of writing this review, we did not yet reach full agreement on it. Readability of the draft: Initially I have failed to understand the following text fragment in the draft (the problematic statements are marked with italics): For Prefix-LSPs application type, the non-interesting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings as a non-interesting state and allows the advertisement of IP Address bindings to facilitate other LDP applications (such as mLDP) that depend on learning of peer addresses over an LDP session for their correct operation. After discussing this point with the authors I've understood that they refer to exchange of the LSR addresses in the Address and Address Withdraw messages that is required for mapping Next Hop IP addresses computed by the IGP to Next Hop LSR. While initial misunderstanding may be specific to me, I have suggested to the authors to clarify this point with explicit references to specific LDP messages and sections of RFC 5036 . Major Issue: The draft, which builds on the mechanisms defined in RFC 5561 , defines two ways to manipulate distribution of "non-interesting state", since by default it would be enabled . In the Initialization message. I assume that in this case the only valid use case would be disabling distribution of non-interesting state . In the Capability message. This method could be both to disable and re-enable distribution of state, but it could only be used if the peer supports "Dynamic Announcement Capability". My concern stems from the fact that the draft deals with "old" LDP applications, so that the possibility that distribution of FEC-to-Label bindings can be unilaterally disabled for PW- and Prefix-FECs is not taken into account in the existing deployments and mechanisms. Here is a couple of examples: Consider the case when a targeted LDP session between PE1 and PE2 has been set just for the purpose of running ICCP between these devices (i.e., in the terms of the ICCP draft they belong to the same RG). According to the example in Section 5.1 of the draft, the PEs could then disable distribution of both PW FECs and Prefix-FECs across such a session in their appropriate Initialization messages. The following (valid from my point of view) scenarios would make such a setting highly problematic: 1. The operator that manages both PE1 and PE2: a. Maintains some VPLS instances in its network b. Initially maintains VPLS instances in both E1 and PE2, but without overlap between the sets of these instances (so that there is no need to setup PWs between PE1 and PE2) c. Uses BGP-based autodiscovery mechanisms for VPLS in its network as described in RFC 6074 d. Is required to extend one of the VPLS instances it maintains and that already has presence in PE1 to have presence also in PE2: i. With BGP-based autodiscovery, explicit configuration of just PE2 should suffice, the person (or management application) that extends this instance does not have to know about the rest of the locations where this VPLS instance is present ii. The autodiscovery process (which does not depend on LDP) identifies PE1 as a peer for the VPLS instance being defined in PE2, so that a PW between PE1 and PE2 is now required iii. The PW setup process finds a targeted LDP session between PE1 and PE2 and tries to use it for setting up the required PW iv. However, PW setup would fails because distribution of PW FECs across the already existing targeted LDP session between PE1 and PE2 has been disabled. e. If PE1 and PE2 support "Dynamic Capability Announcement", this could be amended by enabling distribution of PW FECs prior to setting the required PW. However, this would require substantial changes in the existing PW setup procedures f. If even one of the PEs does not support "Dynamic Capability Announcement", the existing targeted LDP session would have to be torn down and re-established again. This would probably have serious implications for the ICCP-based redundancy mechanism. 2. A similar scenario could be encountered if the operator employs dynamic setup of multi-segment PWs, and the PW routing mechanism decides that one of the segments of a new MS-PW to be set up should run between PE1 and PE2. Such a situation could be probably prevented if the PW routing mechanism could learn that PE1 and PE2 cannot be "directly connected", but, to the best of my understanding, it would require changes in the already standardized MS-PW routing mechanism. I have discussed these cases with the authors, but we have not reached an agreement on them yet. From my point of view, the Applicability Statement section should address these concerns. Consider now the case described in Section 5.2 of the draft, when a targeted LDP session between PE1 and PE2 is initially used just for distribution of setup of PWs, so that distribution of Prefix-FECs is disabled. The following (valid from my point of view) scenario would make such a setting highly problematic: 1. The operator uses LDP for setting "Tunnel LSPs" in its network 2. LFA-based LDP FRR (as per RFC 5286 and Remote LFA draft ) is used as the mechanism for fast protection in the operator's network. 3. Initially PE1 can protect all the LSPs passing through it using just local LFA. 4. The network topology changes (e.g., because new LSRs are added to it), and in order to provide the required coverage, PE1 has to use PE2 as its "remote LFA" for some destinations. a. This would require distribution of Prefix-FECs across the targeted LDP session between PE1 and PE2 - but it has been disabled b. If PE2 does not support "Dynamic Announcement Capability", then the only way to amend the situation would be to tear down the targeted LDP session between PE1 and PE2 and to set it up again - but this would negatively affect PW traffic between PE1 and PE2. I have discussed this case with the authors. To the best of my understanding, they have agreed that combining LDP FRR based on Remote LFAs with the mechanisms defined in the draft would be highly problematic, and will add some suitable text to the Applicability Statement section in the next revision of the draft. Minor Issues: 1. The draft states (in section 4.2) that desire of a given LSR of reception of unnecessary state from the peer is "unilateral and unidirectional by nature". a. IMO this makes perfect sense for Prefix-FECs. b. However, PW FECs must always be exchange in both directions of a targeted LDP session, so that disabling their distribution in just one direction would effectively prevent setup of PWs between the given pair of PEs 2. I concur with Adrian's comment in his AD review of the draft about proposed encoding of states of non-interest. 3. I also wonder whence the need for 16 potential states of non-interest in the draft that, to the best of my understanding, deals with exactly 4 "old" LDP applications. I hope that this does not imply possibility of developing new "old-style' LDP applications in future (or discovering some forgotten old ones?). I have not yet discussed these issues with the authors (as we concentrated on the major ones). Nits: None found by the IDNITS tool. Spelling and Grammar: I defer to the English Language review team. Hopefully these comments will be useful. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: +972-54-9266302 ------=_NextPart_001_0056_01CFAC4C.493BEDF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is very excellent. Thank you for going the = extra mile to sort things out.

 

A

 

From: Kamran Raza = (skraza) [mailto:skraza@cisco.com]
Sent: 30 July 2014 = 19:00
To: adrian@olddog.co.uk
Cc: rtg-dir@ietf.org; = Sami Boutros (sboutros); = draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander = Vainshtein'; rtg-ads@tools.ietf.org
Subject: Re: RTG-DIR = Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

Hi Adrian,

 

Yes, authors wanted to have a f2f meeting with Sasha = @ IETF but we had to schedule the meeting post IETF as Sasha did not = attend.

We are meeting tomorrow with Sasha to = clarify/converge.

 

Thanks.

 

= Kamran Raza=
TECHNICAL LEADER.ENGINEERING
Product Development
skraza@c= isco.com
Phone: +1 613 254 = 4520

=
Cisco.co= m

 

Cisco Systems Canada Co, 181 = Bay St., Suite 3400, Toronto, ON, Canada, M5J 2T3. Phone: 416-306-7000; = Fax: 416-306-7099.
Preferences - Unsubscribe – Privacy<= /a>

3D"Image Think before you = print.

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

= Please click = here for Company Registration = Information.

 

 

From: = Adrian Farrel <adrian@olddog.co.uk>
Rep= ly-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Dat= e: Wednesday, July 30, 2014 at 9:02 AM
To: Syed Kamran = Raza <skraza@cisco.com>
Cc: = "rtg-dir@ietf.org" = <rtg-dir@ietf.org>, = "Sami Boutros (sboutros)" <sboutros@cisco.com>, "d= raft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" <d= raft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, = 'Alexander Vainshtein' <Alexander.Vainshtein@eci= tele.com>, "rtg-ads@tools.ietf.org" = <rtg-ads@tools.ietf.org>
= Subject: RE: RTG-DIR Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

Kamran,

 

Thanks for responding to the question in the = GenArt review.

 

Do you have any responses to Sasha's review = (copied below)?

 

cheers,

Adrian

 

From: Alexander Vainshtein [mailto:Alexander.Vainsht= ein@ecitele.com]
Sent: 11 May 2014 15:09
To: rtg-ads@tools.ietf.org
C= c: rtg-dir@ietf.org; = drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (sboutros@cisco.com)
Subject:= RTG-DIR Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

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-mpls-ldp-ip-pw-capability-07.txt

Reviewer: Alexander (“Sasha”) = Vainshtein   

Review date: 11-May-14

IETF LC End Date: 12-May-14

Intended status: Standards Track

 

Summary:

 

I have significant concerns about this document = and recommend that the Routing ADs discuss these issues further with the = authors.

These concerns mainly deal with potential = negative impact of the mechanisms (introduced in the draft) for = disabling “non-negotiable” capabilities of LDP sessions =  with the techniques that could dynamically change the state of = “interest” in these capabilities for a given LDP = session. 

Some of these mechanisms are already = standardized by the IETF, e.g.,   L2VPN auto-discovery (RFC 6074) and =  dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others - =  LDP FRR using remote loop-free adjacencies (draft-ietf-rtgwg-remote-lfa)- are in advanced stages = of the IETF process.   

 

 

I must admit that I did not follow closely the = discussion of  the draft in question in the MPLS WG; so it may well = be that some of my concerns have been already raised, considered and = found not relevant.

I also do not know if the draft has ever been = discussed in the PWE3, L2VPN and RTG WGs.

 

One possible way to address these concerns = would be by adding an Applicability Statement section to the draft and = discussing potentially problematic combinations of mechanisms = there.

I have discussed this option with the authors = and, to the best of my understanding, they have in general agreed to add = such a section to the next revision of the draft.

 

General comments:

To the best of my = understanding the sole purpose of the draft is  prevention of = “ wasteful” distribution of state dealing with two = non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 = and IPv6 prefixes defined in RFC 5036) and PW FECs = (i.e. PW Id FEC and Generalized PW Id FEC defined in RFC 4447) to LDP peers = that are “not interested’ in this state. Such unnecessary = distribution would result in unnecessary waste of resources (memory = and/or CPU cycles) and hence should be avoided.  

 

The draft mentions = that:

<quote>

  To avoid this = unnecessary state advertisement and exchange, currently

  an operator is = typically required to configure and define filtering

  policies on the = LSR, which introduces unnecessary operational

  overhead and = complexity for such deployments. 

<end = quote>

 

The draft, however, does = not mention that filtering policies provide much finer granularity of = control over distribution of labels than that supported by the mechanism = introduced in the draft.

E.g., in a scenario when = LDP is supposed to set up only “tunnel LSPs” between PEs for = L2 and L3 VPN applications, an appropriate policy allow distribution of = the just the FECs associated with Router IDs of the PEs but not, say = FECs associated with the subnets of their core-facing interfaces. IMHO = and FWIW this means that support of the mechanism defined in the draft = would not eliminate the need for the filtering policies.

 

I have discussed this = point with the authors and they have agreed to add some clarifying = text.

 

I have also failed to = understand how distribution of PW FECs could be wasteful. Section 5.3.3 =  “Signaling Procedures” of RFC 4447 explicitly = states that:

<quote>

   In order for =
PE1 to begin signaling PE2, PE1 must know the address of
   the remote =
PE2, and a TAI.  This information may have been =
configured
   at PE1, or it =
may have been learned dynamically via some
   autodiscovery =
procedure.
 
   The egress PE =
(PE1), which has knowledge of the ingress PE, initiates
   the setup by =
sending a Label Mapping Message to the ingress PE (PE2).

<end = quote>

 

My reading of the quoted = text is that PW FECs are only distributed across targeted LDP sessions = with the known Remote PEs for specific PWs.

AFAIK, this is what = actually happens in most existing implementations of PW signaling with = RFC 4447.

What’s more, many = implementations, when required to set up a PW with a specific remote PE, = check for existence of a targeted LDP session with this PE, and set it = up implicitly if it does not exist; then they distribute PW FEC-to-label = binding via this session only. Implicit targeted LDP sessions are also = implicitly torn down when the last PW between  the given pair of = PEs is torn down.

I have discussed this = point with the authors, but, as of the moment of writing this review, =  we did not yet reach full agreement on it.  

 

Readability of the = draft:

 

Initially I have failed to = understand the following text fragment in the draft (the problematic = statements are marked with italics):

<quote>

   For =
Prefix-LSPs application type, the non-interesting state refers =

   to any =
state related to IP Prefix FEC (such as FEC label bindings, 
   LDP =
Status). This document, however, does not classify IP address =

   bindings =
as a non-interesting state and allows the advertisement of =

   IP =
Address bindings to facilitate other LDP applications (such as =

   mLDP) =
that depend on learning of peer addresses over an LDP session =

   for =
their correct operation.

<end = quote>

After discussing this = point with the authors I’ve understood that they refer to exchange = of the LSR addresses in the Address and Address Withdraw = messages that is required for mapping Next Hop IP addresses = computed by the IGP to Next Hop LSR. While initial misunderstanding may = be specific to me,  I have suggested to the authors to clarify this = point with explicit references to specific LDP messages and sections of = RFC 5036.

 

Major = Issue:

 

The draft, which builds on = the mechanisms defined in RFC = 5561,  defines two ways to manipulate distribution of = “non-interesting state”, since by default it would be = enabled

·   &nb= sp;     In the Initialization = message. I assume that in this case the only valid use case would be = disabling distribution of non-interesting state

·   &nb= sp;     In the Capability message. = This method could be both to disable and re-enable distribution of = state, but it could only be used if the peer supports “Dynamic = Announcement Capability”.

 

My concern stems from the = fact that the draft deals with “old” LDP applications, so = that the possibility that distribution of FEC-to-Label bindings can be = unilaterally disabled for PW- and Prefix-FECs is not taken into account = in the existing deployments and mechanisms.

 

Here is a couple of = examples:

 

Consider the case when a = targeted LDP session between PE1 and PE2 has been set just for the = purpose of running ICCP between these devices (i.e., in the terms of the = ICCP draft they belong to the same RG). According to the example in = Section 5.1 of the draft, the PEs could then disable distribution of = both PW FECs and Prefix-FECs across such a session in their appropriate = Initialization messages.

 

The following (valid from = my point of view) scenarios would make such a setting highly = problematic:

1.   &nb= sp;   The operator that manages = both PE1 and PE2:

a.   &nb= sp;   Maintains some  VPLS = instances in its network

b.   &nb= sp;  Initially maintains VPLS = instances in both E1 and PE2, but without overlap between the sets of = these instances (so that there is no need to setup PWs between PE1 and = PE2)

c.   &nb= sp;   Uses BGP-based = autodiscovery mechanisms for VPLS in its network as described in RFC = 6074

d.   &nb= sp;  Is required to extend one = of the VPLS instances it maintains and that already has presence in PE1 = to have presence also in PE2:

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           = i.   &nb= sp;  With BGP-based = autodiscovery, explicit configuration of just PE2 should suffice, the = person (or management application) that extends this instance does not = have to know about the rest of the locations where this VPLS instance is = present

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;          ii.   &nb= sp;  The autodiscovery process = (which does not depend on LDP) identifies PE1 as a peer for the VPLS = instance being defined in PE2, so that a PW between PE1 and PE2 is now = required

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        iii.   &nb= sp;  The PW setup process finds = a targeted LDP session between PE1 and PE2 and tries to use it for = setting up the required PW

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        iv.   &nb= sp;  However, PW setup would = fails because distribution of PW FECs across the already existing = targeted LDP session between PE1 and PE2 has been disabled.

e.   &nb= sp;  If PE1 and PE2 support = “Dynamic Capability Announcement”, this could be amended by = enabling distribution of PW FECs prior to setting the required PW. = However, this would require substantial changes in the existing PW setup = procedures

f.   &nb= sp;    If even one of the PEs = does not support “Dynamic Capability Announcement”, the = existing targeted LDP session would have to be torn down and = re-established again. This would probably have serious implications for = the ICCP-based redundancy mechanism.

2.   &nb= sp;   A similar scenario could = be encountered if the operator employs dynamic setup of multi-segment = PWs, and the PW routing mechanism decides that one of the segments of a = new MS-PW to be set up should run between PE1 and PE2.   Such = a situation could be probably prevented if the PW routing mechanism = could learn that PE1 and PE2 cannot be “directly connected”, = but, to the best of my understanding, it would require changes in the = already standardized MS-PW routing mechanism.

 

I have discussed these = cases with the authors, but we have not reached an agreement on them = yet. From my point of view, the Applicability Statement section should = address these concerns.

 

Consider now the case = described in Section 5.2 of the draft, when a targeted LDP session = between PE1 and PE2 is initially used just for distribution of setup of = PWs, so that distribution of Prefix-FECs is disabled.

 

The following (valid from = my point of view) scenario would make such a setting highly = problematic:

1.   &nb= sp;   The operator uses LDP for = setting “Tunnel LSPs” in its network

2.   &nb= sp;   LFA-based LDP FRR (as per = RFC = 5286 and Remote LFA draft) is used as the mechanism for fast = protection in the operator’s network.

3.   &nb= sp;   Initially PE1 can protect = all the LSPs passing through it using just local LFA.

4.   &nb= sp;   The network topology = changes (e.g., because new LSRs are added to it), and in order to = provide the required coverage, PE1 has to use PE2 as its “remote = LFA” for some destinations.

a.   &nb= sp;   This would require = distribution of Prefix-FECs across the targeted LDP session between PE1 = and PE2 – but it has been disabled

b.   &nb= sp;  If PE2 does not support = “Dynamic Announcement Capability”, then the only way to = amend the situation would be to tear down the targeted LDP session = between PE1 and PE2 and to set it up again – but this would = negatively affect PW traffic between PE1 and PE2.

 

I have discussed this case = with the authors. To the best of my understanding, they have agreed that = combining LDP FRR based on Remote LFAs with the mechanisms defined in = the draft would be highly problematic, and will add some suitable text = to the Applicability Statement section in the next revision of the = draft.

 

 

Minor = Issues:

 

1.       = The draft states (in = section 4.2) that desire of a given LSR  of reception of = unnecessary state from the peer is “unilateral and unidirectional = by nature”.

a.       = IMO this makes perfect = sense for Prefix-FECs.

b.      = However, PW FECs must = always be exchange in both directions of  a targeted LDP session, = so that disabling their distribution in just one direction would = effectively prevent setup of PWs between the given pair of = PEs

2.       = I concur with = Adrian’s comment in his AD review of the draft about proposed = encoding of states of non-interest.

3.       =  I also wonder whence = the need for 16 potential states of non-interest in the draft that, = to the best of my understanding, deals with exactly 4 “old” = LDP applications. I hope that this does not imply possibility of = developing new “old-style’ LDP applications in future (or = discovering some forgotten old ones?).

 

I have not yet discussed = these issues with the authors (as we concentrated on the major = ones).

 

Nits:

None found by the IDNITS = tool.

 

 

Spelling and = Grammar:

I defer to the English = Language review team.

 

Hopefully these comments = will be useful.

 

Regards,

    &nb= sp;  Sasha

Email: Alexander.Vainshtein@eci= tele.com

Mobile: = +972-54-9266302

 

------=_NextPart_001_0056_01CFAC4C.493BEDF0-- ------=_NextPart_000_0055_01CFAC4C.493BEDF0 Content-Type: image/jpeg; name="~WRD000.jpg" Content-Transfer-Encoding: base64 Content-ID: <~WRD000.jpg> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== ------=_NextPart_000_0055_01CFAC4C.493BEDF0-- From nobody Wed Jul 30 20:46:13 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904EA1A0097; Wed, 30 Jul 2014 20:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqS6yaUdMp6p; Wed, 30 Jul 2014 20:46:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EBE1A007E; Wed, 30 Jul 2014 20:46:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT58711; Thu, 31 Jul 2014 03:46:03 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 04:46:02 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 11:45:57 +0800 From: Mach Chen To: "Sami Boutros (sboutros)" Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: Ac9MiA8kPZwsDe8nRuKlfe9UUOMhxJu5z3cAmvn8hjA= Date: Thu, 31 Jul 2014 03:45:56 +0000 Message-ID: References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> In-Reply-To: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/4ZtA1vf9AHFLwXL3mWIHJMGudJU Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , Loa Andersson , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 03:46:09 -0000 Hi Sami, Sorry for missing your last reply. Thanks for considering my comments, and it resolved my comments. Best regards, Mach > -----Original Message----- > From: Sami Boutros (sboutros) [mailto:sboutros@cisco.com] > Sent: Thursday, July 31, 2014 3:44 AM > To: Mach Chen > Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; mpls@ietf.org; > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; Loa Andersson > Subject: Re: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >=20 > Resending.. >=20 > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >=20 > >> > >> Minor Issues: > >> > >> 1. Since the TTL TLV is defined for both MS-PW and bidirectional > >> co-routed LSP, it should be better to explicitly state this in the abs= tract section. > >> > > > > Sami: Sure will do. > > > >> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", > >> "echo request" and "request" are interchangeably used in the draft, > >> it's better to unify the usage of it to "MPLS echo request" (to align > >> with the usage in RFC4379). For "echo reply", "bidirectional > >> co-routed LSP", they have the similar issue. > >> > > > > Sami: Ok, will fix that. > > > >> 3.Section 3.1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Value | Reserved | Flags | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> For the TTL TLV, the value filed should include the "value", > >> "Reserved" and "Flags", so it's better to change the "Value" field to > >> "TTL" field hence to reduce the confusion. > >> > > > > Sami: Sure. > > > >> 4. Section 3.2 > >> "This TLV shall be included in the echo request by the originator of > >> request. The use of this TLV is optional. If a receiver does not > >> understand the TTL TLV, it will simply ignore the TLV (Type value of > >> TLV is assumed to be in the range of optional TLV's which SHOULD be > >> ignored if an implementation does not support or understand them). In > >> the absence of TTL TLV or if TTL TLV is ignored by a receiver, the > >> determination of the TTL value used in the MPLS label on the echo > >> reply is beyond the scope of this document." > >> > >> What's your mean of "beyond the scope of this document" here? Is it > >> to apply the procedures defined in RFC4379 or just let it to the > >> implementation?I guess you assume to apply the definition in RFC4379, > > > > Sami: It is out of scope of this document, but for sure procedure in 43= 79 apply. > >> if > > > >> so, the TTL of the MPLS label will be more probably set to 255, means > >> the echo reply will be sent to the ingress of the MS-PW or LSP. I am > >> not sure whether this is the right procedure, it seems a security > >> issue. IMHO, it does not make any sense to expect the receiver to > >> send echo reply in this situation, and even sent, the initiator will > >> not receive the reply. The safer way is to drop the whole echo request= and > record an error log. > > > > > > Sami: > > > > We are not saying the receiver must send a reply, however if he does > > the reply may be received by the ingress node which might be the wrong > > node, since the receiver may not set the TTL properly on the reply, > > keep in mind that this is a receiver with an old implementation and the= TLV is > optional. > > > > Please refer to the security section for your security concern. > > > > Sami: > > > > > >> > >> 5. Section 3.2 > >> > >> "In other words, if the value of the TTL provided by this TLV does > >> not match the TTL determined by other means, such as Switching Point > >> TLV in MS-PW, then TTL TLV must be used." > >> Here, it implies that the receiver has to perform TTL matching > >> process, since how to set the TTL is independent of such matching, > >> seems this sentence is redundant and confusion. > >> > > > > Sami: Are you familiar with the switching point TLV? and what it includ= es? > > > >> 6. Section 4. > >> > >> "...The value field of the TTL TLV and the TTL field of the MPLS > >> label are set to 2," > >> > >> I guess that the MPLS Label is the PW label, right? It's better to > >> add more text to make this more explicit. In addition, how to set the > >> TTL value of the tunnel Label? 255 or any other value? > >> > > > > Sami: The tunnel label TTL is irrelevant here, however we will make it = explicit > that this is a PW label. > > > >> 5. Section 4.1. Traceroute mode > >> "In the traceroute mode TTL value in the TLV is successively set to > >> 1, 2, and so on. This is similar to the TTL values used for the > >> label set on the packet." > >> IMHO, some text may be needed to clarify which "FEC" should be > >> carried, especially for MS-PW trace. Since in Section 4.0, the > >> example says the FEC of segment C-D should be carried, does it mean > >> the FEC of last PW Segment of the segment under test should be > >> carried or the FEC will vary when TTL changed. For example, when > >> perform segment trace (e.g., to trace B-D segment), when TTL is 1, whi= ch FEC > should be carried? > > > > Sami: > > We are not here redefining a trace route for a MS-PW, we are describin= g how > our extensions will apply. > > Sami: > > > >> > >> 6. Section 4.2. Error scenario > >> For this scenario, do you need to define some error codes here? > > > > Sami: > > The section describe how to handle the error scenario, there is no need= for an > error code. > > Sami: > > > >> > >> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if > >> so, it should be explicitly stated. If not, you should define how the > >> MS-PW trace works (given that the tunnels in both directions may span > >> different hops). > > > > Sami: > > Not sure I get the concern? Again we are not re-defining how MS-PW trac= e > work. > > > > Thanks, > > > > Sami > >> > >> Nits: > >> > >> 1. Please check the text for acronyms that have not been expanded in > >> their first use. > >> > >> 2. I run the idnits tool and found the following nits, please check > >> and fix. > >> (See RFCs 3967 and 4897 for information about using normative > >> references > >> to lower-maturity documents in RFCs) > >> > >> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 > >> > >> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 > >> > >> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit > >> reference > >> was found in the text > >> > >> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit > >> reference > >> was found in the text > >> > >> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit > >> reference > >> was found in the text > >> > >> 3. Section 3.2, > >> 3.1 first para first sentence > >> s/shall/SHALL > >> 3.2 last para, the last second sentence s/must/MUST > >> > >> 4. The draft quotes the MS-PW and bidirectional co-routed LSP > >> concept, it's better to add related references to this document. > >> > >> > >> Best regards, > >> Mach > >> > >> > > From nobody Wed Jul 30 21:00:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A89D1A0123; Wed, 30 Jul 2014 21:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuzf_6QB6IXY; Wed, 30 Jul 2014 20:59:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F111A00AD; Wed, 30 Jul 2014 20:59:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS89136; Thu, 31 Jul 2014 03:59:56 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 04:59:54 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.190]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 11:59:50 +0800 From: Mach Chen To: "Shah, Himanshu" , "Sami Boutros (sboutros)" Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: Ac9MiA8kPZwsDe8nRuKlfe9UUOMhxJu5z3cA5QUyjQD//yu1sA== Date: Thu, 31 Jul 2014 03:59:49 +0000 Message-ID: References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Gc11Nlo-QU9XWLt8mPdVNk58MgE Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 04:00:01 -0000 Hi Himanshu, I just rechecked my mailbox found that I sent out my comments on March 31, = 2014, and received Sami's reply on May 15 and the reply was wrongly filtere= d into the Junk email folder, sorry for that :-) Best regards, Mach > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Thursday, July 31, 2014 7:15 AM > To: Sami Boutros (sboutros); Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org; > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg-ads@tools.ietf.o= rg > Subject: RE: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >=20 > This draft fills a major shortcoming of the VCCV ping over MS-PW (especia= lly if > reply mode is in-band). > I am not sure why this draft is stuck (i.e. taking too long to go through= ). >=20 > Is there a provisional IANA assignment for the TTL TLV type value? >=20 > Thanks, > himanshu >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros > (sboutros) > Sent: Wednesday, July 30, 2014 3:44 PM > To: Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org; > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg-ads@tools.ietf.o= rg > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.tx= t >=20 > Resending.. >=20 > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >=20 > >> > >> Minor Issues: > >> > >> 1. Since the TTL TLV is defined for both MS-PW and bidirectional > >> co-routed LSP, it should be better to explicitly state this in the abs= tract section. > >> > > > > Sami: Sure will do. > > > >> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", > >> "echo request" and "request" are interchangeably used in the draft, > >> it's better to unify the usage of it to "MPLS echo request" (to align > >> with the usage in RFC4379). For "echo reply", "bidirectional > >> co-routed LSP", they have the similar issue. > >> > > > > Sami: Ok, will fix that. > > > >> 3.Section 3.1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Value | Reserved | Flags | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> For the TTL TLV, the value filed should include the "value", > >> "Reserved" and "Flags", so it's better to change the "Value" field to > >> "TTL" field hence to reduce the confusion. > >> > > > > Sami: Sure. > > > >> 4. Section 3.2 > >> "This TLV shall be included in the echo request by the originator of > >> request. The use of this TLV is optional. If a receiver does not > >> understand the TTL TLV, it will simply ignore the TLV (Type value of > >> TLV is assumed to be in the range of optional TLV's which SHOULD be > >> ignored if an implementation does not support or understand them). In > >> the absence of TTL TLV or if TTL TLV is ignored by a receiver, the > >> determination of the TTL value used in the MPLS label on the echo > >> reply is beyond the scope of this document." > >> > >> What's your mean of "beyond the scope of this document" here? Is it > >> to apply the procedures defined in RFC4379 or just let it to the > >> implementation?I guess you assume to apply the definition in RFC4379, > > > > Sami: It is out of scope of this document, but for sure procedure in 43= 79 apply. > >> if > > > >> so, the TTL of the MPLS label will be more probably set to 255, means > >> the echo reply will be sent to the ingress of the MS-PW or LSP. I am > >> not sure whether this is the right procedure, it seems a security > >> issue. IMHO, it does not make any sense to expect the receiver to > >> send echo reply in this situation, and even sent, the initiator will > >> not receive the reply. The safer way is to drop the whole echo request= and > record an error log. > > > > > > Sami: > > > > We are not saying the receiver must send a reply, however if he does > > the reply may be received by the ingress node which might be the wrong > > node, since the receiver may not set the TTL properly on the reply, > > keep in mind that this is a receiver with an old implementation and the= TLV is > optional. > > > > Please refer to the security section for your security concern. > > > > Sami: > > > > > >> > >> 5. Section 3.2 > >> > >> "In other words, if the value of the TTL provided by this TLV does > >> not match the TTL determined by other means, such as Switching Point > >> TLV in MS-PW, then TTL TLV must be used." > >> Here, it implies that the receiver has to perform TTL matching > >> process, since how to set the TTL is independent of such matching, > >> seems this sentence is redundant and confusion. > >> > > > > Sami: Are you familiar with the switching point TLV? and what it includ= es? > > > >> 6. Section 4. > >> > >> "...The value field of the TTL TLV and the TTL field of the MPLS > >> label are set to 2," > >> > >> I guess that the MPLS Label is the PW label, right? It's better to > >> add more text to make this more explicit. In addition, how to set the > >> TTL value of the tunnel Label? 255 or any other value? > >> > > > > Sami: The tunnel label TTL is irrelevant here, however we will make it = explicit > that this is a PW label. > > > >> 5. Section 4.1. Traceroute mode > >> "In the traceroute mode TTL value in the TLV is successively set to > >> 1, 2, and so on. This is similar to the TTL values used for the > >> label set on the packet." > >> IMHO, some text may be needed to clarify which "FEC" should be > >> carried, especially for MS-PW trace. Since in Section 4.0, the > >> example says the FEC of segment C-D should be carried, does it mean > >> the FEC of last PW Segment of the segment under test should be > >> carried or the FEC will vary when TTL changed. For example, when > >> perform segment trace (e.g., to trace B-D segment), when TTL is 1, whi= ch FEC > should be carried? > > > > Sami: > > We are not here redefining a trace route for a MS-PW, we are describin= g how > our extensions will apply. > > Sami: > > > >> > >> 6. Section 4.2. Error scenario > >> For this scenario, do you need to define some error codes here? > > > > Sami: > > The section describe how to handle the error scenario, there is no need= for an > error code. > > Sami: > > > >> > >> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if > >> so, it should be explicitly stated. If not, you should define how the > >> MS-PW trace works (given that the tunnels in both directions may span > >> different hops). > > > > Sami: > > Not sure I get the concern? Again we are not re-defining how MS-PW trac= e > work. > > > > Thanks, > > > > Sami > >> > >> Nits: > >> > >> 1. Please check the text for acronyms that have not been expanded in > >> their first use. > >> > >> 2. I run the idnits tool and found the following nits, please check > >> and fix. > >> (See RFCs 3967 and 4897 for information about using normative > >> references > >> to lower-maturity documents in RFCs) > >> > >> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 > >> > >> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 > >> > >> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit > >> reference > >> was found in the text > >> > >> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit > >> reference > >> was found in the text > >> > >> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit > >> reference > >> was found in the text > >> > >> 3. Section 3.2, > >> 3.1 first para first sentence > >> s/shall/SHALL > >> 3.2 last para, the last second sentence s/must/MUST > >> > >> 4. The draft quotes the MS-PW and bidirectional co-routed LSP > >> concept, it's better to add related references to this document. > >> > >> > >> Best regards, > >> Mach > >> > >> > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jul 30 23:03:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A31A0276 for ; Wed, 30 Jul 2014 23:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTYMiQtL-Ixl for ; Wed, 30 Jul 2014 23:03:03 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65DA1A0298 for ; Wed, 30 Jul 2014 23:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9157; q=dns/txt; s=iport; t=1406786582; x=1407996182; h=from:to:cc:subject:date:message-id:mime-version; bh=2S4scQZuS6pLCuViXaRjTDtthqfNEkfdsH4hCSyUi3s=; b=dU3PSApXK6mzVZ74gxptwAEuyrvDMpTbel/tybt3Fgzv/S6VNjfkIRm3 KFfsT5ESnYUDfOyMPuhVCZHaE7+hdzmnhZ2TqvoQKahhqKLGbDnR3xaCN m5MlIUhwJPe64Qs5Y3bG4gwyriohvrPmchucudyjHtJn8vn0v6bdnGiRF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAAnb2VOtJA2G/2dsb2JhbABZgkdHUlcEySOBYodLAYEHFneEBQEBAy1MEgEcDlYmAQQODQESiCcNvDIXjUaBVSARgzaBGwWOZYhZhXiTAYNJbAGBRA X-IronPort-AV: E=Sophos; i="5.01,770,1400025600"; d="scan'208,217"; a="65392543" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 31 Jul 2014 06:03:01 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6V631SB016091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 06:03:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 01:03:01 -0500 From: "Les Ginsberg (ginsberg)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-karp-bfd-analysis-04.txt Thread-Index: Ac+shGzPWBGyWOV8RaCVb10qJlxIvw== Date: Thu, 31 Jul 2014 06:03:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.59] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F23E88A19xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/93Wno5vbXphEtHwDLtOtM8MdlHM Cc: "rtg-dir@ietf.org" , "manav@ionosnetworks.com" , "draft-ietf-karp-bfd-analysis@tools.ietf.org" , "zhangdacheng@huawei.com" , "all@tools.ietf.org" , "mjethanandani@gmail.com" Subject: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 06:03:06 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F23E88A19xmbalnx02ciscoc_ 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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-karp-bfd-analysis-04 Reviewer: Les Ginsberg Review Date: July 30, 2014 IETF LC End Date: August 12, 2014 Intended Status: Informational Summary: This document is basically ready for publication, but has minor e= ditorial issues that should be corrected prior to publication. I also have = a minor concern which the authors may want to address. Major Issues: None Minor Issues: I am a little surprised that the use of UTC is emphasized as = a means of preventing replay attacks. While this is certainly a viable solu= tion what has been more commonly used by a number of other protocols is res= erving a portion of the sequence number for a boot count. In fact this is t= he way that http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.tx= t has chosen. Yet this document chooses to emphasize UTC encoding. Nits: 1)The affiliation for one of the authors (Manav) is inconsistent in the hea= der vs the authors addresses section. 2)In the Introduction the last sentence of the second paragraph reads: "Moving the routing protocols to a stronger algorithm while using weaker algorithm for BFD would require the attacker to bring down BFD in order to bring down the routing protocol. " I think what is meant is that if the BFD authentication algorithm is weaker= than that used by the routing protocols it is more likely to be the target= of an attack. The phrase "require the attacker..." seems inappropriate. 3)Section 3 last sentence of the penultimate paragraph: s/reply/replay 4)Section 6 Second paragraph second sentence s/notion/the notion Thanx. Les --_000_F3ADE4747C9E124B89F0ED2180CC814F23E88A19xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected as the Routing Directorate r= eviewer for this draft. The Routing Directorate seeks to review all routing= or routing-related drafts as they pass through IETF last call and IESG rev= iew, 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://tra= c.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use= of the Routing ADs, it would be helpful if you could consider them along w= ith any other IETF Last Call comments that you receive, and strive to resol= ve them through discussion or by updating the draft.

Document: draft-ietf-karp-bfd-analysis-04

Reviewer: Les Ginsberg

Review Date: July 30, 2014

IETF LC End Date: August 12, 2014

Intended Status: Informational

 

Summary:  This document is basically ready f= or publication, but has minor editorial issues that should be corrected pri= or to publication. I also have a minor concern which the authors may want t= o address.

 

Major Issues: None

 

Minor Issues: I am a little surprised that the us= e of UTC is emphasized as a means of preventing replay attacks. While this = is certainly a viable solution what has been more commonly used by a number= of other protocols is reserving a portion of the sequence number for a boot count. In fact this is the way t= hat http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.txt  = has chosen. Yet this document chooses to emphasize UTC encoding.=

 

Nits:

 

1)The affiliation for one of the authors (Manav) = is inconsistent in the header vs the authors addresses section.<= /p>

 

2)In the Introduction the last sentence of the se= cond paragraph reads:

 

"Moving the routing protocols to a stronger<= o:p>

   algorithm while using weaker algorit= hm for BFD would require the

   attacker to bring down BFD in order = to bring down the routing

   protocol. "

I think what is meant is that if the BFD authenti= cation algorithm is weaker than that used by the routing protocols it is mo= re likely to be the target of an attack. The phrase "require the attac= ker..." seems inappropriate.

 

3)Section 3 last sentence of the penultimate para= graph:

 

s/reply/replay

 

4)Section 6 Second paragraph second sentence=

 

s/notion/the notion

 

Thanx.

 

   Les

 

--_000_F3ADE4747C9E124B89F0ED2180CC814F23E88A19xmbalnx02ciscoc_-- From nobody Thu Jul 31 04:54:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E261A02E8; Wed, 30 Jul 2014 16:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtIqUsRRHqpY; Wed, 30 Jul 2014 16:15:36 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6091A0197; Wed, 30 Jul 2014 16:15:36 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6UNF87h005333; Wed, 30 Jul 2014 19:15:20 -0400 Received: from vawvcgsie2k1302.ciena.com (LIN1-118-36-36.ciena.com [63.118.36.36]) by mx0b-00103a01.pphosted.com with ESMTP id 1nf4xa0wnu-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2014 19:15:20 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 30 Jul 2014 19:15:18 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 30 Jul 2014 19:15:18 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Wed, 30 Jul 2014 19:15:18 -0400 From: "Shah, Himanshu" To: "Sami Boutros (sboutros)" , Mach Chen Date: Wed, 30 Jul 2014 19:15:16 -0400 Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPcL43MdQKFwuY10i9fAzq1cK1Rpu5z3cA///lHDA= Message-ID: <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> In-Reply-To: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-30_08:2014-07-30,2014-07-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407300259 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/bKfCb--HJzj084WcAb88eJ_AGV8 X-Mailman-Approved-At: Thu, 31 Jul 2014 04:54:29 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 23:15:38 -0000 This draft fills a major shortcoming of the VCCV ping over MS-PW (especiall= y if reply mode is in-band). I am not sure why this draft is stuck (i.e. taking too long to go through). Is there a provisional IANA assignment for the TTL TLV type value? Thanks, himanshu -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros (sboutr= os) Sent: Wednesday, July 30, 2014 3:44 PM To: Mach Chen Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@t= ools.ietf.org; rtg-ads@tools.ietf.org Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Resending.. On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >>=20 >> Minor Issues:=20 >>=20 >> 1. Since the TTL TLV is defined for both MS-PW and bidirectional=20 >> co-routed LSP, it should be better to explicitly state this in the abstr= act section. >>=20 >=20 > Sami: Sure will do. >=20 >> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request",=20 >> "echo request" and "request" are interchangeably used in the draft,=20 >> it's better to unify the usage of it to "MPLS echo request" (to align=20 >> with the usage in RFC4379). For "echo reply", "bidirectional=20 >> co-routed LSP", they have the similar issue. >>=20 >=20 > Sami: Ok, will fix that. >=20 >> 3.Section 3.1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Value | Reserved | Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> For the TTL TLV, the value filed should include the "value",=20 >> "Reserved" and "Flags", so it's better to change the "Value" field to=20 >> "TTL" field hence to reduce the confusion. >>=20 >=20 > Sami: Sure. >=20 >> 4. Section 3.2 >> "This TLV shall be included in the echo request by the originator of =20 >> request. The use of this TLV is optional. If a receiver does not =20 >> understand the TTL TLV, it will simply ignore the TLV (Type value of =20 >> TLV is assumed to be in the range of optional TLV's which SHOULD be =20 >> ignored if an implementation does not support or understand them). In =20 >> the absence of TTL TLV or if TTL TLV is ignored by a receiver, the =20 >> determination of the TTL value used in the MPLS label on the echo =20 >> reply is beyond the scope of this document." >>=20 >> What's your mean of "beyond the scope of this document" here? Is it=20 >> to apply the procedures defined in RFC4379 or just let it to the=20 >> implementation?I guess you assume to apply the definition in RFC4379, >=20 > Sami: It is out of scope of this document, but for sure procedure in 4379= apply. >> if >=20 >> so, the TTL of the MPLS label will be more probably set to 255, means=20 >> the echo reply will be sent to the ingress of the MS-PW or LSP. I am=20 >> not sure whether this is the right procedure, it seems a security=20 >> issue. IMHO, it does not make any sense to expect the receiver to=20 >> send echo reply in this situation, and even sent, the initiator will=20 >> not receive the reply. The safer way is to drop the whole echo request a= nd record an error log. >=20 >=20 > Sami:=20 >=20 > We are not saying the receiver must send a reply, however if he does=20 > the reply may be received by the ingress node which might be the wrong=20 > node, since the receiver may not set the TTL properly on the reply,=20 > keep in mind that this is a receiver with an old implementation and the T= LV is optional. >=20 > Please refer to the security section for your security concern. >=20 > Sami: >=20 >=20 >>=20 >> 5. Section 3.2 >>=20 >> "In other words, if the value of the TTL provided by this TLV does=20 >> not match the TTL determined by other means, such as Switching Point=20 >> TLV in MS-PW, then TTL TLV must be used." >> Here, it implies that the receiver has to perform TTL matching=20 >> process, since how to set the TTL is independent of such matching,=20 >> seems this sentence is redundant and confusion. >>=20 >=20 > Sami: Are you familiar with the switching point TLV? and what it includes= ? >=20 >> 6. Section 4. >>=20 >> "...The value field of the TTL TLV and the TTL field of the MPLS=20 >> label are set to 2," >>=20 >> I guess that the MPLS Label is the PW label, right? It's better to=20 >> add more text to make this more explicit. In addition, how to set the=20 >> TTL value of the tunnel Label? 255 or any other value? >>=20 >=20 > Sami: The tunnel label TTL is irrelevant here, however we will make it ex= plicit that this is a PW label. >=20 >> 5. Section 4.1. Traceroute mode >> "In the traceroute mode TTL value in the TLV is successively set to=20 >> 1, 2, and so on. This is similar to the TTL values used for the=20 >> label set on the packet." >> IMHO, some text may be needed to clarify which "FEC" should be=20 >> carried, especially for MS-PW trace. Since in Section 4.0, the=20 >> example says the FEC of segment C-D should be carried, does it mean=20 >> the FEC of last PW Segment of the segment under test should be=20 >> carried or the FEC will vary when TTL changed. For example, when=20 >> perform segment trace (e.g., to trace B-D segment), when TTL is 1, which= FEC should be carried? >=20 > Sami:=20 > We are not here redefining a trace route for a MS-PW, we are describing = how our extensions will apply. > Sami: >=20 >>=20 >> 6. Section 4.2. Error scenario >> For this scenario, do you need to define some error codes here? >=20 > Sami:=20 > The section describe how to handle the error scenario, there is no need f= or an error code. > Sami: >=20 >>=20 >> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if=20 >> so, it should be explicitly stated. If not, you should define how the=20 >> MS-PW trace works (given that the tunnels in both directions may span=20 >> different hops). >=20 > Sami:=20 > Not sure I get the concern? Again we are not re-defining how MS-PW trace = work. >=20 > Thanks, >=20 > Sami >>=20 >> Nits:=20 >>=20 >> 1. Please check the text for acronyms that have not been expanded in=20 >> their first use. >>=20 >> 2. I run the idnits tool and found the following nits, please check=20 >> and fix. >> (See RFCs 3967 and 4897 for information about using normative=20 >> references >> to lower-maturity documents in RFCs) >>=20 >> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 >>=20 >> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 >>=20 >> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit=20 >> reference >> was found in the text >>=20 >> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit=20 >> reference >> was found in the text >>=20 >> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit=20 >> reference >> was found in the text >>=20 >> 3. Section 3.2, >> 3.1 first para first sentence >> s/shall/SHALL >> 3.2 last para, the last second sentence s/must/MUST >>=20 >> 4. The draft quotes the MS-PW and bidirectional co-routed LSP=20 >> concept, it's better to add related references to this document. >>=20 >>=20 >> Best regards, >> Mach >>=20 >>=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 31 05:08:13 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E7B1A854B; Thu, 31 Jul 2014 05:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-o8ZUyWQGbY; Thu, 31 Jul 2014 05:07:52 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5861A0B13; Thu, 31 Jul 2014 05:07:51 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C44171802B88; Thu, 31 Jul 2014 14:07:49 +0200 (CEST) Message-ID: <53DA3194.4040306@pi.nu> Date: Thu, 31 Jul 2014 14:07:48 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Shah, Himanshu" , "Sami Boutros (sboutros)" , Mach Chen References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/jiVgTh_ulJdprBQkohF15Pe7uHs Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:08:00 -0000 Himanshu, A request for early allocation need to come from the authors, to wg-chairs and ADs. The draft is through IETF Last call and has been updated, given that ADrian is comfortable it will be on the IESG agenda shortly. IANA has reviewed it and are OK. Normally I would not ask for early allocation this late in the process. /Loa On 2014-07-31 01:15, Shah, Himanshu wrote: > This draft fills a major shortcoming of the VCCV ping over MS-PW (especially if reply mode is in-band). > I am not sure why this draft is stuck (i.e. taking too long to go through). > > Is there a provisional IANA assignment for the TTL TLV type value? > > Thanks, > himanshu > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros (sboutros) > Sent: Wednesday, July 30, 2014 3:44 PM > To: Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > Resending.. > > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: > >>> >>> Minor Issues: >>> >>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional >>> co-routed LSP, it should be better to explicitly state this in the abstract section. >>> >> >> Sami: Sure will do. >> >>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", >>> "echo request" and "request" are interchangeably used in the draft, >>> it's better to unify the usage of it to "MPLS echo request" (to align >>> with the usage in RFC4379). For "echo reply", "bidirectional >>> co-routed LSP", they have the similar issue. >>> >> >> Sami: Ok, will fix that. >> >>> 3.Section 3.1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Value | Reserved | Flags | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> For the TTL TLV, the value filed should include the "value", >>> "Reserved" and "Flags", so it's better to change the "Value" field to >>> "TTL" field hence to reduce the confusion. >>> >> >> Sami: Sure. >> >>> 4. Section 3.2 >>> "This TLV shall be included in the echo request by the originator of >>> request. The use of this TLV is optional. If a receiver does not >>> understand the TTL TLV, it will simply ignore the TLV (Type value of >>> TLV is assumed to be in the range of optional TLV's which SHOULD be >>> ignored if an implementation does not support or understand them). In >>> the absence of TTL TLV or if TTL TLV is ignored by a receiver, the >>> determination of the TTL value used in the MPLS label on the echo >>> reply is beyond the scope of this document." >>> >>> What's your mean of "beyond the scope of this document" here? Is it >>> to apply the procedures defined in RFC4379 or just let it to the >>> implementation?I guess you assume to apply the definition in RFC4379, >> >> Sami: It is out of scope of this document, but for sure procedure in 4379 apply. >>> if >> >>> so, the TTL of the MPLS label will be more probably set to 255, means >>> the echo reply will be sent to the ingress of the MS-PW or LSP. I am >>> not sure whether this is the right procedure, it seems a security >>> issue. IMHO, it does not make any sense to expect the receiver to >>> send echo reply in this situation, and even sent, the initiator will >>> not receive the reply. The safer way is to drop the whole echo request and record an error log. >> >> >> Sami: >> >> We are not saying the receiver must send a reply, however if he does >> the reply may be received by the ingress node which might be the wrong >> node, since the receiver may not set the TTL properly on the reply, >> keep in mind that this is a receiver with an old implementation and the TLV is optional. >> >> Please refer to the security section for your security concern. >> >> Sami: >> >> >>> >>> 5. Section 3.2 >>> >>> "In other words, if the value of the TTL provided by this TLV does >>> not match the TTL determined by other means, such as Switching Point >>> TLV in MS-PW, then TTL TLV must be used." >>> Here, it implies that the receiver has to perform TTL matching >>> process, since how to set the TTL is independent of such matching, >>> seems this sentence is redundant and confusion. >>> >> >> Sami: Are you familiar with the switching point TLV? and what it includes? >> >>> 6. Section 4. >>> >>> "...The value field of the TTL TLV and the TTL field of the MPLS >>> label are set to 2," >>> >>> I guess that the MPLS Label is the PW label, right? It's better to >>> add more text to make this more explicit. In addition, how to set the >>> TTL value of the tunnel Label? 255 or any other value? >>> >> >> Sami: The tunnel label TTL is irrelevant here, however we will make it explicit that this is a PW label. >> >>> 5. Section 4.1. Traceroute mode >>> "In the traceroute mode TTL value in the TLV is successively set to >>> 1, 2, and so on. This is similar to the TTL values used for the >>> label set on the packet." >>> IMHO, some text may be needed to clarify which "FEC" should be >>> carried, especially for MS-PW trace. Since in Section 4.0, the >>> example says the FEC of segment C-D should be carried, does it mean >>> the FEC of last PW Segment of the segment under test should be >>> carried or the FEC will vary when TTL changed. For example, when >>> perform segment trace (e.g., to trace B-D segment), when TTL is 1, which FEC should be carried? >> >> Sami: >> We are not here redefining a trace route for a MS-PW, we are describing how our extensions will apply. >> Sami: >> >>> >>> 6. Section 4.2. Error scenario >>> For this scenario, do you need to define some error codes here? >> >> Sami: >> The section describe how to handle the error scenario, there is no need for an error code. >> Sami: >> >>> >>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if >>> so, it should be explicitly stated. If not, you should define how the >>> MS-PW trace works (given that the tunnels in both directions may span >>> different hops). >> >> Sami: >> Not sure I get the concern? Again we are not re-defining how MS-PW trace work. >> >> Thanks, >> >> Sami >>> >>> Nits: >>> >>> 1. Please check the text for acronyms that have not been expanded in >>> their first use. >>> >>> 2. I run the idnits tool and found the following nits, please check >>> and fix. >>> (See RFCs 3967 and 4897 for information about using normative >>> references >>> to lower-maturity documents in RFCs) >>> >>> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 >>> >>> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 >>> >>> == Unused Reference: '1' is defined on line 284, but no explicit >>> reference >>> was found in the text >>> >>> == Unused Reference: '2' is defined on line 287, but no explicit >>> reference >>> was found in the text >>> >>> == Unused Reference: '3' is defined on line 291, but no explicit >>> reference >>> was found in the text >>> >>> 3. Section 3.2, >>> 3.1 first para first sentence >>> s/shall/SHALL >>> 3.2 last para, the last second sentence s/must/MUST >>> >>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP >>> concept, it's better to add related references to this document. >>> >>> >>> Best regards, >>> Mach >>> >>> >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 05:22:30 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF911ADDB5 for ; Thu, 31 Jul 2014 05:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtsFKTkY5Ae4 for ; Thu, 31 Jul 2014 05:22:19 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88751ABB90 for ; Thu, 31 Jul 2014 05:22:18 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so1984593lbi.13 for ; Thu, 31 Jul 2014 05:22:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D8nrMxsaIgPLjVbOcAi7MeVHO4k0OWeeabk9jG1aObs=; b=WjmJX4qr45N45W7ADQ9zw5QkzmM+VeennL9P/V9I2c2RopLo83yTKPa5qlrXoU2V66 BIQvVDgh+ClkepfmQfAZdeMmXV1/P4YokbQxzGNdV5I1HDDD+nodXIbd5er6BlZZBG1Q sv0hRhi+VTXCnWbrwzvc3z2NYFgQJtzf06fVRoSMzee6orvU3LtH/lyVWAQtS6Kswq3L Y5tF5kkV0xXUipJbEdqlHXpaCX6OJMCX4o5WRokQzQqB0lGN11LeX43j42/S8Qrg2K9r WOrMVbWXWx83U9IaqZWKLUwxHndEA6Xp3rGQNkCrO0HNj6KrvUghg6F7NIJZvWp8Xm8j qR4w== X-Gm-Message-State: ALoCoQmdXj3B27vUNvEoIpBcYx0mkYwhzUETwaEihvaVazBB2sFqG4FzaxzGDAZj04ei3YRgqz82 MIME-Version: 1.0 X-Received: by 10.152.27.66 with SMTP id r2mr11805842lag.34.1406809336574; Thu, 31 Jul 2014 05:22:16 -0700 (PDT) Received: by 10.112.8.4 with HTTP; Thu, 31 Jul 2014 05:22:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 17:52:16 +0530 Message-ID: From: manav bhatia To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=089e0158c070c6090f04ff7c5261 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/IbRZ6tqbu7b-HppC8hLwX4GvATs Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-bfd-analysis@tools.ietf.org" , "zhangdacheng@huawei.com" , "all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mjethanandani@gmail.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:22:27 -0000 --089e0158c070c6090f04ff7c5261 Content-Type: text/plain; charset=UTF-8 Hi Les, Thanks for the comments. > > > Minor Issues: I am a little surprised that the use of UTC is emphasized as > a means of preventing replay attacks. While this is certainly a viable > solution what has been more commonly used by a number of other protocols is > reserving a portion of the sequence number for a boot count. In fact this > is the way that > http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.txt has > chosen. Yet this document chooses to emphasize UTC encoding. > > > I am the author of the standards that started using the boot count initially as a way to preserve the crypto sequence count. I am not a big fan of UTC and this was suggested as a plausible mechanism that did not appear to be outright loony (especially when you have increased the seq space to 64 bits). Let me put it this way - I wouldnt be baying for blood if the directorate believes that this is a retrogressive step and we need to snip out that section. Nits: > > > > 1)The affiliation for one of the authors (Manav) is inconsistent in the > header vs the authors addresses section. > Will fix this. For the record, i now work for Ionos Networks. > > > 2)In the Introduction the last sentence of the second paragraph reads: > > > > "Moving the routing protocols to a stronger > > algorithm while using weaker algorithm for BFD would require the > > attacker to bring down BFD in order to bring down the routing > > protocol. " > > I think what is meant is that if the BFD authentication algorithm is > weaker than that used by the routing protocols it is more likely to be the > target of an attack. The phrase "require the attacker..." seems > inappropriate. > Gotcha. Will fix this. > > > 3)Section 3 last sentence of the penultimate paragraph: > > > > s/reply/replay > .. and this. > > > 4)Section 6 Second paragraph second sentence > > > > s/notion/the notion > .. and this as well. Thanks, Manav > > > Thanx. > > > > Les > > > --089e0158c070c6090f04ff7c5261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Les,

Thanks for the comments.
<= div class=3D"gmail_extra">

=C2=A0

Minor Issues: I am a little surprised that the use of UTC is emphasized = as a means of preventing replay attacks. While this is certainly a viable s= olution what has been more commonly used by a number of other protocols is = reserving a portion of the sequence number for a boot count. In fact this is the way t= hat http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.txt =C2=A0= has chosen. Yet this document chooses to emphasize UTC encoding.<= /u>

=C2=A0

I am the author of the st= andards that started using the boot count initially as a way to preserve th= e crypto sequence count. I am not a big fan of UTC and this was suggested a= s a plausible mechanism that did not appear to be outright loony (especiall= y when you have increased the seq space to 64 bits). Let me put it this way= - I wouldnt be baying for blood if the directorate believes that this is a= retrogressive step and we need to snip out that section.

Nits:

=C2=A0

1)The affiliation for one of the authors (Manav) is inconsistent in the = header vs the authors addresses section.

<= br>
Will fix this. For the record, i now work for Ionos Networks.=
=C2=A0

=C2=A0

2)In the Introduction the last sentence of the second paragraph reads:

=C2=A0

"Moving the routing protocols to a stronger

=C2=A0=C2=A0 algorithm while using weaker algorithm for BFD would requir= e the

=C2=A0=C2=A0 attacker to bring down BFD in order to bring down the routi= ng

=C2=A0=C2=A0 protocol. "

I think what is meant is that if the BFD authentication algorithm is wea= ker than that used by the routing protocols it is more likely to be the tar= get of an attack. The phrase "require the attacker..." seems inap= propriate.


Gotcha. Will fix this.
=C2=A0

=C2=A0

3)Section 3 last sentence of the penultimate paragraph:

=C2=A0

s/reply/replay


.. and th= is.
=C2=A0

=C2=A0

4)Section 6 Second paragraph second sentence

=C2=A0

s/notion/the notion


.. a= nd this as well.

Thanks,

= Manav =C2=A0

=C2=A0

Thanx.

=C2=A0

=C2=A0=C2=A0 Les

=C2=A0


--089e0158c070c6090f04ff7c5261-- From nobody Thu Jul 31 06:47:41 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC881B280F for ; Thu, 31 Jul 2014 06:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59r5VvOmEocl for ; Thu, 31 Jul 2014 06:47:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35811B2804 for ; Thu, 31 Jul 2014 06:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11249; q=dns/txt; s=iport; t=1406814458; x=1408024058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Dpa/OzJdtCChJlGAeCT0+gtI6Pd/23fh+AefwBRtzT4=; b=HYc8hzTXU8aTGE5Pu2Sg6vZTXEcXFLiX4NrktrlCwWFA6YYr/4UG+5Bk fUixUdfyxukFCWNjcGWWvya+vR4NgvPnz9n2V+bLpkioMIBwl2HTAFOex MaTR2cobEareiGPI4uOMe29vGLqk/M9/9tOvtGONeYA+ETxz3le8UXQCl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAGxI2lOtJV2Z/2dsb2JhbABZgkdHUlcEyyyHSwGBBhZ3hAMBAQEBA3kQAgEIEQMBAigHIREUCQgBAQQBDQUJEogTAxENtR4Nhw4XjR+CHBEHhEoFjmWIWYIhggWOLoYlg0lsAYEEJBw X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208,217";a="344112939" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 31 Jul 2014 13:47:21 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6VDlLt7028695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 13:47:21 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 08:47:21 -0500 From: "Acee Lindem (acee)" To: manav bhatia , "Les Ginsberg (ginsberg)" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt Thread-Index: Ac+shGzPWBGyWOV8RaCVb10qJlxIvwAX4yoA///UtYA= Date: Thu, 31 Jul 2014 13:47:20 +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.116.152.195] Content-Type: multipart/alternative; boundary="_000_CFFFBE9915F1aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/hwdzzQBNA34fafPLy3996_QF28Q Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-bfd-analysis@tools.ietf.org" , "zhangdacheng@huawei.com" , "all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mjethanandani@gmail.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 13:47:40 -0000 --_000_CFFFBE9915F1aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, I agree with Les though I may have logged this as a major issue. What if th= e next-hop used to reach your NTP server is validated using authenticated m= ulti-hop BFD? Also, It is seems a bit superficial to recommend usage of UT= C for the high order 32 bits of the sequence number without dealing without= mentioning the 2038 wrap for the UNIX time. Thanks, Acee From: Manav Bhatia = > Date: Thursday, July 31, 2014 at 8:22 AM To: "Les Ginsberg (ginsberg)" > Cc: "rtg-dir@ietf.org" >, "draft-ietf-karp-bfd-analysis@tools.ietf.org" >, "zhangdach= eng@huawei.com" >, "all@tools.ietf.org" >, "rtg-ads@tools.ietf.o= rg" >, "mjethanandani@gmail.com" = > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt Hi Les, Thanks for the comments. Minor Issues: I am a little surprised that the use of UTC is emphasized as = a means of preventing replay attacks. While this is certainly a viable solu= tion what has been more commonly used by a number of other protocols is res= erving a portion of the sequence number for a boot count. In fact this is t= he way that http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.tx= t has chosen. Yet this document chooses to emphasize UTC encoding. I am the author of the standards that started using the boot count initiall= y as a way to preserve the crypto sequence count. I am not a big fan of UTC= and this was suggested as a plausible mechanism that did not appear to be = outright loony (especially when you have increased the seq space to 64 bits= ). Let me put it this way - I wouldnt be baying for blood if the directorat= e believes that this is a retrogressive step and we need to snip out that s= ection. Nits: 1)The affiliation for one of the authors (Manav) is inconsistent in the hea= der vs the authors addresses section. Will fix this. For the record, i now work for Ionos Networks. 2)In the Introduction the last sentence of the second paragraph reads: "Moving the routing protocols to a stronger algorithm while using weaker algorithm for BFD would require the attacker to bring down BFD in order to bring down the routing protocol. " I think what is meant is that if the BFD authentication algorithm is weaker= than that used by the routing protocols it is more likely to be the target= of an attack. The phrase "require the attacker..." seems inappropriate. Gotcha. Will fix this. 3)Section 3 last sentence of the penultimate paragraph: s/reply/replay .. and this. 4)Section 6 Second paragraph second sentence s/notion/the notion .. and this as well. Thanks, Manav Thanx. Les --_000_CFFFBE9915F1aceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <540F8B2D88A49345AF95C57592949CE8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Manav, 
I agree with Les though I may have logged this as a major issue. What = if the next-hop used to reach your NTP server is validated using authentica= ted multi-hop BFD?  Also, It is seems a bit superficial to recommend u= sage of UTC for the high order 32 bits of the sequence number without dealing without mentioning the 2038 wrap fo= r the UNIX time. 
Thanks,
Acee 

From: Manav Bhatia <manav@ionosnetworks.com>
Date: Thursday, July 31, 2014 at 8:= 22 AM
To: "Les Ginsberg (ginsberg)&q= uot; <ginsberg@cisco.com> Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-karp-bfd-analysis@tools.ietf.org"= ; <draft-i= etf-karp-bfd-analysis@tools.ietf.org>, "zhangdacheng@huawei.com" <zhangdacheng@huawei.com>, "all@tools.ietf.org" <all@tools.ietf.org>, &quo= t;rtg-ads@tools.ietf.org"= ; <rtg-ads@tools.ietf.org&= gt;, "mjethanandani@gmail.c= om" <mjethanandani@gmail.com= >
Subject: Re: [RTG-DIR] RtgDir revie= w: draft-ietf-karp-bfd-analysis-04.txt

Hi Les,

Thanks for the comments.

 

Minor Issues: I am a little surprised that the use of UTC is emphasized = as a means of preventing replay attacks. While this is certainly a viable s= olution what has been more commonly used by a number of other protocols is = reserving a portion of the sequence number for a boot count. In fact this is the way that http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.txt  = has chosen. Yet this document chooses to emphasize UTC encoding.<= /u>

 

I am the author of the standards that started using the boot count ini= tially as a way to preserve the crypto sequence count. I am not a big fan o= f UTC and this was suggested as a plausible mechanism that did not appear t= o be outright loony (especially when you have increased the seq space to 64 bits). Let me put it this way = - I wouldnt be baying for blood if the directorate believes that this is a = retrogressive step and we need to snip out that section.

Nits:

 

1)The affiliation for one of the authors (Manav) is inconsistent in the = header vs the authors addresses section.


Will fix this. For the record, i now work for Ionos Networks.
 

 

2)In the Introduction the last sentence of the second paragraph reads:

 

"Moving the routing protocols to a stronger

   algorithm while using weaker algorithm for BFD would requir= e the

   attacker to bring down BFD in order to bring down the routi= ng

   protocol. "

I think what is meant is that if the BFD authentication algorithm is wea= ker than that used by the routing protocols it is more likely to be the tar= get of an attack. The phrase "require the attacker..." seems inap= propriate.


Gotcha. Will fix this.
 

 

3)Section 3 last sentence of the penultimate paragraph:

 

s/reply/replay


.. and this.
 

 

4)Section 6 Second paragraph second sentence

 

s/notion/the notion


.. and this as well.

Thanks,

Manav  

 

Thanx.

 

   Les

 


 --_000_CFFFBE9915F1aceeciscocom_-- From nobody Thu Jul 31 06:54:29 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ED71B27E3; Thu, 31 Jul 2014 06:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A_uG_BnJIar; Thu, 31 Jul 2014 06:14:52 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8561F1B27D9; Thu, 31 Jul 2014 06:14:52 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6VDAGv1025342; Thu, 31 Jul 2014 09:14:42 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0a-00103a01.pphosted.com with ESMTP id 1nfnvjg5d7-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2014 09:14:42 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 31 Jul 2014 09:14:40 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Thu, 31 Jul 2014 09:14:40 -0400 From: "Shah, Himanshu" To: Loa Andersson , "Sami Boutros (sboutros)" , Mach Chen Date: Thu, 31 Jul 2014 09:14:38 -0400 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: Ac+suCSYSSTl0yCuQe6sjT6oD+tJGgACLZdQ Message-ID: <40746B2300A8FC4AB04EE722A593182B76F4F335@ONWVEXCHMB04.ciena.com> References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> In-Reply-To: <53DA3194.4040306@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-20850.007 x-tm-as-result: No--53.144800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-31_04:2014-07-30,2014-07-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407310162 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/orRlDGhH4ordfIWRoQaiy6BY8oA X-Mailman-Approved-At: Thu, 31 Jul 2014 06:54:27 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 13:14:59 -0000 Thanks Loa. Early allocation request could have been made much earlier, but that is wat= er under the bridge now. I would still favor requesting for provisional IANA code allocation now. This would allow interoperability of the ongoing implementations. /himanshu -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Thursday, July 31, 2014 8:08 AM To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen Cc: rtg-dir@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; = rtg-ads@tools.ietf.org; mpls@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.t= xt Himanshu, A request for early allocation need to come from the authors, to wg-chairs = and ADs. The draft is through IETF Last call and has been updated, given that ADrian= is comfortable it will be on the IESG agenda shortly. IANA has reviewed it and are OK. Normally I would not ask for early allocation this late in the process. /Loa On 2014-07-31 01:15, Shah, Himanshu wrote: > This draft fills a major shortcoming of the VCCV ping over MS-PW (especia= lly if reply mode is in-band). > I am not sure why this draft is stuck (i.e. taking too long to go through= ). > > Is there a provisional IANA assignment for the TTL TLV type value? > > Thanks, > himanshu > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros=20 > (sboutros) > Sent: Wednesday, July 30, 2014 3:44 PM > To: Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org;=20 > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org;=20 > rtg-ads@tools.ietf.org > Subject: Re: [mpls] RtgDir review:=20 > draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > Resending.. > > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: > >>> >>> Minor Issues: >>> >>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional=20 >>> co-routed LSP, it should be better to explicitly state this in the abst= ract section. >>> >> >> Sami: Sure will do. >> >>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request",=20 >>> "echo request" and "request" are interchangeably used in the draft,=20 >>> it's better to unify the usage of it to "MPLS echo request" (to=20 >>> align with the usage in RFC4379). For "echo reply", "bidirectional=20 >>> co-routed LSP", they have the similar issue. >>> >> >> Sami: Ok, will fix that. >> >>> 3.Section 3.1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Value | Reserved | Flags | >>> =20 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> For the TTL TLV, the value filed should include the "value",=20 >>> "Reserved" and "Flags", so it's better to change the "Value" field=20 >>> to "TTL" field hence to reduce the confusion. >>> >> >> Sami: Sure. >> >>> 4. Section 3.2 >>> "This TLV shall be included in the echo request by the originator of=20 >>> request. The use of this TLV is optional. If a receiver does not=20 >>> understand the TTL TLV, it will simply ignore the TLV (Type value of=20 >>> TLV is assumed to be in the range of optional TLV's which SHOULD be=20 >>> ignored if an implementation does not support or understand them).=20 >>> In the absence of TTL TLV or if TTL TLV is ignored by a receiver,=20 >>> the determination of the TTL value used in the MPLS label on the=20 >>> echo reply is beyond the scope of this document." >>> >>> What's your mean of "beyond the scope of this document" here? Is it=20 >>> to apply the procedures defined in RFC4379 or just let it to the=20 >>> implementation?I guess you assume to apply the definition in=20 >>> RFC4379, >> >> Sami: It is out of scope of this document, but for sure procedure in 437= 9 apply. >>> if >> >>> so, the TTL of the MPLS label will be more probably set to 255,=20 >>> means the echo reply will be sent to the ingress of the MS-PW or=20 >>> LSP. I am not sure whether this is the right procedure, it seems a=20 >>> security issue. IMHO, it does not make any sense to expect the=20 >>> receiver to send echo reply in this situation, and even sent, the=20 >>> initiator will not receive the reply. The safer way is to drop the whol= e echo request and record an error log. >> >> >> Sami: >> >> We are not saying the receiver must send a reply, however if he does=20 >> the reply may be received by the ingress node which might be the=20 >> wrong node, since the receiver may not set the TTL properly on the=20 >> reply, keep in mind that this is a receiver with an old implementation a= nd the TLV is optional. >> >> Please refer to the security section for your security concern. >> >> Sami: >> >> >>> >>> 5. Section 3.2 >>> >>> "In other words, if the value of the TTL provided by this TLV does=20 >>> not match the TTL determined by other means, such as Switching=20 >>> Point TLV in MS-PW, then TTL TLV must be used." >>> Here, it implies that the receiver has to perform TTL matching=20 >>> process, since how to set the TTL is independent of such matching,=20 >>> seems this sentence is redundant and confusion. >>> >> >> Sami: Are you familiar with the switching point TLV? and what it include= s? >> >>> 6. Section 4. >>> >>> "...The value field of the TTL TLV and the TTL field of the MPLS=20 >>> label are set to 2," >>> >>> I guess that the MPLS Label is the PW label, right? It's better to=20 >>> add more text to make this more explicit. In addition, how to set=20 >>> the TTL value of the tunnel Label? 255 or any other value? >>> >> >> Sami: The tunnel label TTL is irrelevant here, however we will make it e= xplicit that this is a PW label. >> >>> 5. Section 4.1. Traceroute mode >>> "In the traceroute mode TTL value in the TLV is successively set=20 >>> to 1, 2, and so on. This is similar to the TTL values used for the=20 >>> label set on the packet." >>> IMHO, some text may be needed to clarify which "FEC" should be=20 >>> carried, especially for MS-PW trace. Since in Section 4.0, the=20 >>> example says the FEC of segment C-D should be carried, does it mean=20 >>> the FEC of last PW Segment of the segment under test should be=20 >>> carried or the FEC will vary when TTL changed. For example, when=20 >>> perform segment trace (e.g., to trace B-D segment), when TTL is 1, whic= h FEC should be carried? >> >> Sami: >> We are not here redefining a trace route for a MS-PW, we are describing= how our extensions will apply. >> Sami: >> >>> >>> 6. Section 4.2. Error scenario >>> For this scenario, do you need to define some error codes here? >> >> Sami: >> The section describe how to handle the error scenario, there is no need = for an error code. >> Sami: >> >>> >>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode,=20 >>> if so, it should be explicitly stated. If not, you should define how=20 >>> the MS-PW trace works (given that the tunnels in both directions may=20 >>> span different hops). >> >> Sami: >> Not sure I get the concern? Again we are not re-defining how MS-PW trace= work. >> >> Thanks, >> >> Sami >>> >>> Nits: >>> >>> 1. Please check the text for acronyms that have not been expanded in=20 >>> their first use. >>> >>> 2. I run the idnits tool and found the following nits, please check=20 >>> and fix. >>> (See RFCs 3967 and 4897 for information about using normative=20 >>> references >>> to lower-maturity documents in RFCs) >>> >>> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 >>> >>> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 >>> >>> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit=20 >>> reference >>> was found in the text >>> >>> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit=20 >>> reference >>> was found in the text >>> >>> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit=20 >>> reference >>> was found in the text >>> >>> 3. Section 3.2, >>> 3.1 first para first sentence >>> s/shall/SHALL >>> 3.2 last para, the last second sentence s/must/MUST >>> >>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP=20 >>> concept, it's better to add related references to this document. >>> >>> >>> Best regards, >>> Mach >>> >>> >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 06:54:31 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30511A0012; Thu, 31 Jul 2014 06:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwU_zhAT8gBy; Thu, 31 Jul 2014 06:15:50 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB78C1B27CD; Thu, 31 Jul 2014 06:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9712; q=dns/txt; s=iport; t=1406812549; x=1408022149; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3zalv1oSIN2Si4r3u2+ZFhPPWgC9RQuPdL/sUDhE0W8=; b=MNEh1QxIVY+W+eGbohxhnLACWKJJgp7Ue2ubY2RtXW6EG8Ba9DNV5pHA qVT/krjwC6TYhSkQ/RpNzaTJ1I6VWHQZfVWmdxvh6Y36QBGxkqshFJf/b QrxgzamzlhcecsA74YCJXzBXns7V0vAToN4f+7nsS5ULimBKffzci8AQ0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAD5B2lOtJV2Y/2dsb2JhbABZgmokUlcEywkZCodLAYEGFneEAwEBAQECAQEBATctBAMLDAICAgEIEQQBAQEKFAkHGwwLFAkIAgQBDQUIiDIIAQy9AxMEBIl7hGsRAR8xBwaDKYEbBY5loVKDSWwBgQs5 X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="65477076" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 31 Jul 2014 13:15:40 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6VDFejq016199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 13:15:40 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 08:15:40 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , "Shah, Himanshu" , "Sami Boutros (sboutros)" , Mach Chen Thread-Topic: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPrLgh361wuvGpdEGeup7tEEixMpu6J0Kg Date: Thu, 31 Jul 2014 13:15:40 +0000 Message-ID: References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> In-Reply-To: <53DA3194.4040306@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/WousubautJqYSjJpMfRw6nfNe0E X-Mailman-Approved-At: Thu, 31 Jul 2014 06:54:27 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 13:15:59 -0000 Hi Loa, Authors, The code base which I'm familiar with already have shipped implementation o= f the TTL TLV, and it appears that the Type=3D0x8001 is being used. I do not have the knowledge of why this value was used in this implementati= on without doing early IANA allocation for the TTL TLV code point. If usage of Type=3D0x8001 as the TTL TLV does not conflict with any other i= mplementations out there, is it possible to ask IANA to assign this value (= 0x8001) when the document progresses? My apologies for causing extra burden on the authors, the Shepherd and the = ADs. But I truly hope that this request can be accommodated. Thanks! -Nobo > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, July 31, 2014 8:08 AM > To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > Cc: rtg-dir@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org= ; > mpls@ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl= -tlv- > 07.txt >=20 > Himanshu, >=20 > A request for early allocation need to come from the authors, to wg-chair= s > and ADs. >=20 > The draft is through IETF Last call and has been updated, given that ADri= an is > comfortable it will be on the IESG agenda shortly. >=20 > IANA has reviewed it and are OK. >=20 > Normally I would not ask for early allocation this late in the process. >=20 > /Loa >=20 > On 2014-07-31 01:15, Shah, Himanshu wrote: > > This draft fills a major shortcoming of the VCCV ping over MS-PW > (especially if reply mode is in-band). > > I am not sure why this draft is stuck (i.e. taking too long to go throu= gh). > > > > Is there a provisional IANA assignment for the TTL TLV type value? > > > > Thanks, > > himanshu > > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros > > (sboutros) > > Sent: Wednesday, July 30, 2014 3:44 PM > > To: Mach Chen > > Cc: rtg-dir@ietf.org; mpls@ietf.org; > > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [mpls] RtgDir review: > > draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > > > Resending.. > > > > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: > > > >>> > >>> Minor Issues: > >>> > >>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional > >>> co-routed LSP, it should be better to explicitly state this in the ab= stract > section. > >>> > >> > >> Sami: Sure will do. > >> > >>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", > >>> "echo request" and "request" are interchangeably used in the draft, > >>> it's better to unify the usage of it to "MPLS echo request" (to > >>> align with the usage in RFC4379). For "echo reply", "bidirectional > >>> co-routed LSP", they have the similar issue. > >>> > >> > >> Sami: Ok, will fix that. > >> > >>> 3.Section 3.1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > >>> | Value | Reserved | Flags | > >>> > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> For the TTL TLV, the value filed should include the "value", > >>> "Reserved" and "Flags", so it's better to change the "Value" field > >>> to "TTL" field hence to reduce the confusion. > >>> > >> > >> Sami: Sure. > >> > >>> 4. Section 3.2 > >>> "This TLV shall be included in the echo request by the originator of > >>> request. The use of this TLV is optional. If a receiver does not > >>> understand the TTL TLV, it will simply ignore the TLV (Type value of > >>> TLV is assumed to be in the range of optional TLV's which SHOULD be > >>> ignored if an implementation does not support or understand them). > >>> In the absence of TTL TLV or if TTL TLV is ignored by a receiver, > >>> the determination of the TTL value used in the MPLS label on the > >>> echo reply is beyond the scope of this document." > >>> > >>> What's your mean of "beyond the scope of this document" here? Is it > >>> to apply the procedures defined in RFC4379 or just let it to the > >>> implementation?I guess you assume to apply the definition in > >>> RFC4379, > >> > >> Sami: It is out of scope of this document, but for sure procedure in 4= 379 > apply. > >>> if > >> > >>> so, the TTL of the MPLS label will be more probably set to 255, > >>> means the echo reply will be sent to the ingress of the MS-PW or > >>> LSP. I am not sure whether this is the right procedure, it seems a > >>> security issue. IMHO, it does not make any sense to expect the > >>> receiver to send echo reply in this situation, and even sent, the > >>> initiator will not receive the reply. The safer way is to drop the wh= ole > echo request and record an error log. > >> > >> > >> Sami: > >> > >> We are not saying the receiver must send a reply, however if he does > >> the reply may be received by the ingress node which might be the > >> wrong node, since the receiver may not set the TTL properly on the > >> reply, keep in mind that this is a receiver with an old implementation= and > the TLV is optional. > >> > >> Please refer to the security section for your security concern. > >> > >> Sami: > >> > >> > >>> > >>> 5. Section 3.2 > >>> > >>> "In other words, if the value of the TTL provided by this TLV does > >>> not match the TTL determined by other means, such as Switching > >>> Point TLV in MS-PW, then TTL TLV must be used." > >>> Here, it implies that the receiver has to perform TTL matching > >>> process, since how to set the TTL is independent of such matching, > >>> seems this sentence is redundant and confusion. > >>> > >> > >> Sami: Are you familiar with the switching point TLV? and what it > includes? > >> > >>> 6. Section 4. > >>> > >>> "...The value field of the TTL TLV and the TTL field of the MPLS > >>> label are set to 2," > >>> > >>> I guess that the MPLS Label is the PW label, right? It's better to > >>> add more text to make this more explicit. In addition, how to set > >>> the TTL value of the tunnel Label? 255 or any other value? > >>> > >> > >> Sami: The tunnel label TTL is irrelevant here, however we will make it > explicit that this is a PW label. > >> > >>> 5. Section 4.1. Traceroute mode > >>> "In the traceroute mode TTL value in the TLV is successively set > >>> to 1, 2, and so on. This is similar to the TTL values used for the > >>> label set on the packet." > >>> IMHO, some text may be needed to clarify which "FEC" should be > >>> carried, especially for MS-PW trace. Since in Section 4.0, the > >>> example says the FEC of segment C-D should be carried, does it mean > >>> the FEC of last PW Segment of the segment under test should be > >>> carried or the FEC will vary when TTL changed. For example, when > >>> perform segment trace (e.g., to trace B-D segment), when TTL is 1, wh= ich > FEC should be carried? > >> > >> Sami: > >> We are not here redefining a trace route for a MS-PW, we are describi= ng > how our extensions will apply. > >> Sami: > >> > >>> > >>> 6. Section 4.2. Error scenario > >>> For this scenario, do you need to define some error codes here? > >> > >> Sami: > >> The section describe how to handle the error scenario, there is no nee= d > for an error code. > >> Sami: > >> > >>> > >>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, > >>> if so, it should be explicitly stated. If not, you should define how > >>> the MS-PW trace works (given that the tunnels in both directions may > >>> span different hops). > >> > >> Sami: > >> Not sure I get the concern? Again we are not re-defining how MS-PW > trace work. > >> > >> Thanks, > >> > >> Sami > >>> > >>> Nits: > >>> > >>> 1. Please check the text for acronyms that have not been expanded in > >>> their first use. > >>> > >>> 2. I run the idnits tool and found the following nits, please check > >>> and fix. > >>> (See RFCs 3967 and 4897 for information about using normative > >>> references > >>> to lower-maturity documents in RFCs) > >>> > >>> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 > >>> > >>> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 > >>> > >>> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit > >>> reference > >>> was found in the text > >>> > >>> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit > >>> reference > >>> was found in the text > >>> > >>> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit > >>> reference > >>> was found in the text > >>> > >>> 3. Section 3.2, > >>> 3.1 first para first sentence > >>> s/shall/SHALL > >>> 3.2 last para, the last second sentence s/must/MUST > >>> > >>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP > >>> concept, it's better to add related references to this document. > >>> > >>> > >>> Best regards, > >>> Mach > >>> > >>> > >> > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 31 07:11:19 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34EF1A0045; Thu, 31 Jul 2014 07:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m80yaWKByePd; Thu, 31 Jul 2014 07:11:12 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0077.outbound.protection.outlook.com [213.199.154.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF9F1B281E; Thu, 31 Jul 2014 07:11:11 -0700 (PDT) Received: from AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) by AM3PR03MB530.eurprd03.prod.outlook.com (10.242.109.154) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 14:11:09 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 14:11:08 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Thu, 31 Jul 2014 14:11:08 +0000 From: Alexander Vainshtein To: "Nobo Akiya (nobo)" Thread-Topic: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPcL43MdQKFwuY10i9fAzq1cK1Rpu5z3cA///lHDCAANoHAIAAEvYAgAAOQSA= Date: Thu, 31 Jul 2014 14:11:07 +0000 Message-ID: <7adbcb851e224adbbd93416e5932b618@AM3PR03MB612.eurprd03.prod.outlook.com> References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(189002)(377424004)(377454003)(51704005)(24454002)(41574002)(252514010)(164054003)(199002)(87936001)(110136001)(54356999)(33646002)(20776003)(15975445006)(83322001)(83072002)(81342001)(50986999)(86362001)(4396001)(2656002)(93886003)(74316001)(101416001)(107046002)(19580405001)(85852003)(80022001)(76482001)(81542001)(106356001)(64706001)(66066001)(76576001)(95666004)(31966008)(74662001)(106116001)(79102001)(21056001)(76176999)(85306003)(46102001)(92566001)(74502001)(105586002)(77982001)(19580395003)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/UUqU-jHPRE2A9Sbepj9xM30xkFQ Cc: "rtg-dir@ietf.org" , Mach Chen , "mpls@ietf.org" , "Sami Boutros \(sboutros\)" , "Shah, Himanshu" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , Loa Andersson Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:11:17 -0000 Nobo, and all, 0x8001 =3D 32769 falls in the "Unassigned" range of TLVs for LSP Ping. I th= ink that it has been considered as safe enough to use by the implementers. Somehow the relevant IANA registry does not provide any values for experime= ntal use. My 2c, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) > Sent: Thursday, July 31, 2014 4:16 PM > To: Loa Andersson; Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > Cc: rtg-dir@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org= ; rtg- > ads@tools.ietf.org; mpls@ietf.org > Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl= -tlv- > 07.txt >=20 > Hi Loa, Authors, >=20 > The code base which I'm familiar with already have shipped implementation > of the TTL TLV, and it appears that the Type=3D0x8001 is being used. >=20 > I do not have the knowledge of why this value was used in this > implementation without doing early IANA allocation for the TTL TLV code > point. >=20 > If usage of Type=3D0x8001 as the TTL TLV does not conflict with any other > implementations out there, is it possible to ask IANA to assign this valu= e > (0x8001) when the document progresses? >=20 > My apologies for causing extra burden on the authors, the Shepherd and th= e > ADs. >=20 > But I truly hope that this request can be accommodated. >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: Thursday, July 31, 2014 8:08 AM > > To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; > > mpls@ietf.org; rtg-ads@tools.ietf.org > > Subject: Re: [mpls] [RTG-DIR] RtgDir review: > > draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt > > > > Himanshu, > > > > A request for early allocation need to come from the authors, to > > wg-chairs and ADs. > > > > The draft is through IETF Last call and has been updated, given that > > ADrian is comfortable it will be on the IESG agenda shortly. > > > > IANA has reviewed it and are OK. > > > > Normally I would not ask for early allocation this late in the process. > > > > /Loa > > > > On 2014-07-31 01:15, Shah, Himanshu wrote: > > > This draft fills a major shortcoming of the VCCV ping over MS-PW > > (especially if reply mode is in-band). > > > I am not sure why this draft is stuck (i.e. taking too long to go thr= ough). > > > > > > Is there a provisional IANA assignment for the TTL TLV type value? > > > > > > Thanks, > > > himanshu > > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros > > > (sboutros) > > > Sent: Wednesday, July 30, 2014 3:44 PM > > > To: Mach Chen > > > Cc: rtg-dir@ietf.org; mpls@ietf.org; > > > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; > > > rtg-ads@tools.ietf.org > > > Subject: Re: [mpls] RtgDir review: > > > draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > > > > > Resending.. > > > > > > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: > > > > > >>> > > >>> Minor Issues: > > >>> > > >>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional > > >>> co-routed LSP, it should be better to explicitly state this in the > > >>> abstract > > section. > > >>> > > >> > > >> Sami: Sure will do. > > >> > > >>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo > > >>> request", "echo request" and "request" are interchangeably used in > > >>> the draft, it's better to unify the usage of it to "MPLS echo > > >>> request" (to align with the usage in RFC4379). For "echo reply", > > >>> "bidirectional co-routed LSP", they have the similar issue. > > >>> > > >> > > >> Sami: Ok, will fix that. > > >> > > >>> 3.Section 3.1 > > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +- > + > > >>> | Value | Reserved | Flags | > > >>> > > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >>> > > >>> For the TTL TLV, the value filed should include the "value", > > >>> "Reserved" and "Flags", so it's better to change the "Value" field > > >>> to "TTL" field hence to reduce the confusion. > > >>> > > >> > > >> Sami: Sure. > > >> > > >>> 4. Section 3.2 > > >>> "This TLV shall be included in the echo request by the originator > > >>> of request. The use of this TLV is optional. If a receiver does > > >>> not understand the TTL TLV, it will simply ignore the TLV (Type > > >>> value of TLV is assumed to be in the range of optional TLV's which > > >>> SHOULD be ignored if an implementation does not support or > understand them). > > >>> In the absence of TTL TLV or if TTL TLV is ignored by a receiver, > > >>> the determination of the TTL value used in the MPLS label on the > > >>> echo reply is beyond the scope of this document." > > >>> > > >>> What's your mean of "beyond the scope of this document" here? Is > > >>> it to apply the procedures defined in RFC4379 or just let it to > > >>> the implementation?I guess you assume to apply the definition in > > >>> RFC4379, > > >> > > >> Sami: It is out of scope of this document, but for sure procedure > > >> in 4379 > > apply. > > >>> if > > >> > > >>> so, the TTL of the MPLS label will be more probably set to 255, > > >>> means the echo reply will be sent to the ingress of the MS-PW or > > >>> LSP. I am not sure whether this is the right procedure, it seems a > > >>> security issue. IMHO, it does not make any sense to expect the > > >>> receiver to send echo reply in this situation, and even sent, the > > >>> initiator will not receive the reply. The safer way is to drop the > > >>> whole > > echo request and record an error log. > > >> > > >> > > >> Sami: > > >> > > >> We are not saying the receiver must send a reply, however if he > > >> does the reply may be received by the ingress node which might be > > >> the wrong node, since the receiver may not set the TTL properly on > > >> the reply, keep in mind that this is a receiver with an old > > >> implementation and > > the TLV is optional. > > >> > > >> Please refer to the security section for your security concern. > > >> > > >> Sami: > > >> > > >> > > >>> > > >>> 5. Section 3.2 > > >>> > > >>> "In other words, if the value of the TTL provided by this TLV does > > >>> not match the TTL determined by other means, such as Switching > > >>> Point TLV in MS-PW, then TTL TLV must be used." > > >>> Here, it implies that the receiver has to perform TTL matching > > >>> process, since how to set the TTL is independent of such matching, > > >>> seems this sentence is redundant and confusion. > > >>> > > >> > > >> Sami: Are you familiar with the switching point TLV? and what it > > includes? > > >> > > >>> 6. Section 4. > > >>> > > >>> "...The value field of the TTL TLV and the TTL field of the MPLS > > >>> label are set to 2," > > >>> > > >>> I guess that the MPLS Label is the PW label, right? It's better to > > >>> add more text to make this more explicit. In addition, how to set > > >>> the TTL value of the tunnel Label? 255 or any other value? > > >>> > > >> > > >> Sami: The tunnel label TTL is irrelevant here, however we will make > > >> it > > explicit that this is a PW label. > > >> > > >>> 5. Section 4.1. Traceroute mode > > >>> "In the traceroute mode TTL value in the TLV is successively set > > >>> to 1, 2, and so on. This is similar to the TTL values used for > > >>> the label set on the packet." > > >>> IMHO, some text may be needed to clarify which "FEC" should be > > >>> carried, especially for MS-PW trace. Since in Section 4.0, the > > >>> example says the FEC of segment C-D should be carried, does it > > >>> mean the FEC of last PW Segment of the segment under test should > > >>> be carried or the FEC will vary when TTL changed. For example, > > >>> when perform segment trace (e.g., to trace B-D segment), when TTL > > >>> is 1, which > > FEC should be carried? > > >> > > >> Sami: > > >> We are not here redefining a trace route for a MS-PW, we are > > >> describing > > how our extensions will apply. > > >> Sami: > > >> > > >>> > > >>> 6. Section 4.2. Error scenario > > >>> For this scenario, do you need to define some error codes here? > > >> > > >> Sami: > > >> The section describe how to handle the error scenario, there is no > > >> need > > for an error code. > > >> Sami: > > >> > > >>> > > >>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, > > >>> if so, it should be explicitly stated. If not, you should define > > >>> how the MS-PW trace works (given that the tunnels in both > > >>> directions may span different hops). > > >> > > >> Sami: > > >> Not sure I get the concern? Again we are not re-defining how MS-PW > > trace work. > > >> > > >> Thanks, > > >> > > >> Sami > > >>> > > >>> Nits: > > >>> > > >>> 1. Please check the text for acronyms that have not been expanded > > >>> in their first use. > > >>> > > >>> 2. I run the idnits tool and found the following nits, please > > >>> check and fix. > > >>> (See RFCs 3967 and 4897 for information about using normative > > >>> references > > >>> to lower-maturity documents in RFCs) > > >>> > > >>> -- Looks like a reference, but probably isn't: 'RFC2119' on line > > >>> 121 > > >>> > > >>> -- Looks like a reference, but probably isn't: 'RFC4379' on line > > >>> 258 > > >>> > > >>> =3D=3D Unused Reference: '1' is defined on line 284, but no explici= t > > >>> reference > > >>> was found in the text > > >>> > > >>> =3D=3D Unused Reference: '2' is defined on line 287, but no explici= t > > >>> reference > > >>> was found in the text > > >>> > > >>> =3D=3D Unused Reference: '3' is defined on line 291, but no explici= t > > >>> reference > > >>> was found in the text > > >>> > > >>> 3. Section 3.2, > > >>> 3.1 first para first sentence > > >>> s/shall/SHALL > > >>> 3.2 last para, the last second sentence s/must/MUST > > >>> > > >>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP > > >>> concept, it's better to add related references to this document. > > >>> > > >>> > > >>> Best regards, > > >>> Mach > > >>> > > >>> > > >> > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 31 07:29:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770BA1B2862; Thu, 31 Jul 2014 07:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TgXO-pb_mEJ; Thu, 31 Jul 2014 07:29:39 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAF61B282F; Thu, 31 Jul 2014 07:29:38 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4EB1C1802B19; Thu, 31 Jul 2014 16:29:37 +0200 (CEST) Message-ID: <53DA52D0.8030206@pi.nu> Date: Thu, 31 Jul 2014 16:29:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , Alexander Vainshtein References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> <7adbcb851e224adbbd93416e5932b618@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/G2saGsuUJL1gjFFa51TPRsL8TWo Cc: "rtg-dir@ietf.org" , Mach Chen , "mpls@ietf.org" , "Sami Boutros \(sboutros\)" , "Shah, Himanshu" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:29:42 -0000 Nobo, If that is what you want, I can initiate the procedure to allocate that code point. /Loa On 2014-07-31 16:20, Nobo Akiya (nobo) wrote: > Hi Sasha, > > I wish that was the case :) > > https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#tlvs > > 32768-49161 > Standards Action > This range is for optional TLVs that can be silently dropped if not recognized. > > Thanks, > Nobo > >> -----Original Message----- >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Thursday, July 31, 2014 10:11 AM >> To: Nobo Akiya (nobo) >> Cc: rtg-dir@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg- >> ads@tools.ietf.org; mpls@ietf.org; Loa Andersson; Shah, Himanshu; Sami >> Boutros (sboutros); Mach Chen >> Subject: RE: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv- >> 07.txt >> >> Nobo, and all, >> 0x8001 = 32769 falls in the "Unassigned" range of TLVs for LSP Ping. I think >> that it has been considered as safe enough to use by the implementers. >> Somehow the relevant IANA registry does not provide any values for >> experimental use. >> >> My 2c, >> Sasha >> Email: Alexander.Vainshtein@ecitele.com >> Mobile: 054-9266302 >> >>> -----Original Message----- >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya >>> (nobo) >>> Sent: Thursday, July 31, 2014 4:16 PM >>> To: Loa Andersson; Shah, Himanshu; Sami Boutros (sboutros); Mach Chen >>> Cc: rtg-dir@ietf.org; >>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg- >>> ads@tools.ietf.org; mpls@ietf.org >>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: >>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt >>> >>> Hi Loa, Authors, >>> >>> The code base which I'm familiar with already have shipped >>> implementation of the TTL TLV, and it appears that the Type=0x8001 is >> being used. >>> >>> I do not have the knowledge of why this value was used in this >>> implementation without doing early IANA allocation for the TTL TLV >>> code point. >>> >>> If usage of Type=0x8001 as the TTL TLV does not conflict with any >>> other implementations out there, is it possible to ask IANA to assign >>> this value >>> (0x8001) when the document progresses? >>> >>> My apologies for causing extra burden on the authors, the Shepherd and >>> the ADs. >>> >>> But I truly hope that this request can be accommodated. >>> >>> Thanks! >>> >>> -Nobo >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >>>> Sent: Thursday, July 31, 2014 8:08 AM >>>> To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen >>>> Cc: rtg-dir@ietf.org; >>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >>>> mpls@ietf.org; rtg-ads@tools.ietf.org >>>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: >>>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt >>>> >>>> Himanshu, >>>> >>>> A request for early allocation need to come from the authors, to >>>> wg-chairs and ADs. >>>> >>>> The draft is through IETF Last call and has been updated, given that >>>> ADrian is comfortable it will be on the IESG agenda shortly. >>>> >>>> IANA has reviewed it and are OK. >>>> >>>> Normally I would not ask for early allocation this late in the process. >>>> >>>> /Loa >>>> >>>> On 2014-07-31 01:15, Shah, Himanshu wrote: >>>>> This draft fills a major shortcoming of the VCCV ping over MS-PW >>>> (especially if reply mode is in-band). >>>>> I am not sure why this draft is stuck (i.e. taking too long to go through). >>>>> >>>>> Is there a provisional IANA assignment for the TTL TLV type value? >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> -----Original Message----- >>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami >>>>> Boutros >>>>> (sboutros) >>>>> Sent: Wednesday, July 30, 2014 3:44 PM >>>>> To: Mach Chen >>>>> Cc: rtg-dir@ietf.org; mpls@ietf.org; >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >>>>> rtg-ads@tools.ietf.org >>>>> Subject: Re: [mpls] RtgDir review: >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >>>>> >>>>> Resending.. >>>>> >>>>> On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >>>>> >>>>>>> >>>>>>> Minor Issues: >>>>>>> >>>>>>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional >>>>>>> co-routed LSP, it should be better to explicitly state this in >>>>>>> the abstract >>>> section. >>>>>>> >>>>>> >>>>>> Sami: Sure will do. >>>>>> >>>>>>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo >>>>>>> request", "echo request" and "request" are interchangeably used >>>>>>> in the draft, it's better to unify the usage of it to "MPLS echo >>>>>>> request" (to align with the usage in RFC4379). For "echo reply", >>>>>>> "bidirectional co-routed LSP", they have the similar issue. >>>>>>> >>>>>> >>>>>> Sami: Ok, will fix that. >>>>>> >>>>>>> 3.Section 3.1 >>>>>>> >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> + >>>>>>> | Value | Reserved | Flags | >>>>>>> >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> For the TTL TLV, the value filed should include the "value", >>>>>>> "Reserved" and "Flags", so it's better to change the "Value" >>>>>>> field to "TTL" field hence to reduce the confusion. >>>>>>> >>>>>> >>>>>> Sami: Sure. >>>>>> >>>>>>> 4. Section 3.2 >>>>>>> "This TLV shall be included in the echo request by the >>>>>>> originator of request. The use of this TLV is optional. If a >>>>>>> receiver does not understand the TTL TLV, it will simply ignore >>>>>>> the TLV (Type value of TLV is assumed to be in the range of >>>>>>> optional TLV's which SHOULD be ignored if an implementation does >>>>>>> not support or >>> understand them). >>>>>>> In the absence of TTL TLV or if TTL TLV is ignored by a >>>>>>> receiver, the determination of the TTL value used in the MPLS >>>>>>> label on the echo reply is beyond the scope of this document." >>>>>>> >>>>>>> What's your mean of "beyond the scope of this document" here? Is >>>>>>> it to apply the procedures defined in RFC4379 or just let it to >>>>>>> the implementation?I guess you assume to apply the definition in >>>>>>> RFC4379, >>>>>> >>>>>> Sami: It is out of scope of this document, but for sure procedure >>>>>> in 4379 >>>> apply. >>>>>>> if >>>>>> >>>>>>> so, the TTL of the MPLS label will be more probably set to 255, >>>>>>> means the echo reply will be sent to the ingress of the MS-PW or >>>>>>> LSP. I am not sure whether this is the right procedure, it seems >>>>>>> a security issue. IMHO, it does not make any sense to expect the >>>>>>> receiver to send echo reply in this situation, and even sent, >>>>>>> the initiator will not receive the reply. The safer way is to >>>>>>> drop the whole >>>> echo request and record an error log. >>>>>> >>>>>> >>>>>> Sami: >>>>>> >>>>>> We are not saying the receiver must send a reply, however if he >>>>>> does the reply may be received by the ingress node which might be >>>>>> the wrong node, since the receiver may not set the TTL properly >>>>>> on the reply, keep in mind that this is a receiver with an old >>>>>> implementation and >>>> the TLV is optional. >>>>>> >>>>>> Please refer to the security section for your security concern. >>>>>> >>>>>> Sami: >>>>>> >>>>>> >>>>>>> >>>>>>> 5. Section 3.2 >>>>>>> >>>>>>> "In other words, if the value of the TTL provided by this TLV >>>>>>> does not match the TTL determined by other means, such as >>>>>>> Switching Point TLV in MS-PW, then TTL TLV must be used." >>>>>>> Here, it implies that the receiver has to perform TTL matching >>>>>>> process, since how to set the TTL is independent of such >>>>>>> matching, seems this sentence is redundant and confusion. >>>>>>> >>>>>> >>>>>> Sami: Are you familiar with the switching point TLV? and what it >>>> includes? >>>>>> >>>>>>> 6. Section 4. >>>>>>> >>>>>>> "...The value field of the TTL TLV and the TTL field of the MPLS >>>>>>> label are set to 2," >>>>>>> >>>>>>> I guess that the MPLS Label is the PW label, right? It's better >>>>>>> to add more text to make this more explicit. In addition, how to >>>>>>> set the TTL value of the tunnel Label? 255 or any other value? >>>>>>> >>>>>> >>>>>> Sami: The tunnel label TTL is irrelevant here, however we will >>>>>> make it >>>> explicit that this is a PW label. >>>>>> >>>>>>> 5. Section 4.1. Traceroute mode >>>>>>> "In the traceroute mode TTL value in the TLV is successively >>>>>>> set to 1, 2, and so on. This is similar to the TTL values used >>>>>>> for the label set on the packet." >>>>>>> IMHO, some text may be needed to clarify which "FEC" should be >>>>>>> carried, especially for MS-PW trace. Since in Section 4.0, the >>>>>>> example says the FEC of segment C-D should be carried, does it >>>>>>> mean the FEC of last PW Segment of the segment under test should >>>>>>> be carried or the FEC will vary when TTL changed. For example, >>>>>>> when perform segment trace (e.g., to trace B-D segment), when >>>>>>> TTL is 1, which >>>> FEC should be carried? >>>>>> >>>>>> Sami: >>>>>> We are not here redefining a trace route for a MS-PW, we are >>>>>> describing >>>> how our extensions will apply. >>>>>> Sami: >>>>>> >>>>>>> >>>>>>> 6. Section 4.2. Error scenario >>>>>>> For this scenario, do you need to define some error codes here? >>>>>> >>>>>> Sami: >>>>>> The section describe how to handle the error scenario, there is >>>>>> no need >>>> for an error code. >>>>>> Sami: >>>>>> >>>>>>> >>>>>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe >>>>>>> mode, if so, it should be explicitly stated. If not, you should >>>>>>> define how the MS-PW trace works (given that the tunnels in both >>>>>>> directions may span different hops). >>>>>> >>>>>> Sami: >>>>>> Not sure I get the concern? Again we are not re-defining how >>>>>> MS-PW >>>> trace work. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Sami >>>>>>> >>>>>>> Nits: >>>>>>> >>>>>>> 1. Please check the text for acronyms that have not been >>>>>>> expanded in their first use. >>>>>>> >>>>>>> 2. I run the idnits tool and found the following nits, please >>>>>>> check and fix. >>>>>>> (See RFCs 3967 and 4897 for information about using normative >>>>>>> references >>>>>>> to lower-maturity documents in RFCs) >>>>>>> >>>>>>> -- Looks like a reference, but probably isn't: 'RFC2119' on line >>>>>>> 121 >>>>>>> >>>>>>> -- Looks like a reference, but probably isn't: 'RFC4379' on line >>>>>>> 258 >>>>>>> >>>>>>> == Unused Reference: '1' is defined on line 284, but no explicit >>>>>>> reference >>>>>>> was found in the text >>>>>>> >>>>>>> == Unused Reference: '2' is defined on line 287, but no explicit >>>>>>> reference >>>>>>> was found in the text >>>>>>> >>>>>>> == Unused Reference: '3' is defined on line 291, but no explicit >>>>>>> reference >>>>>>> was found in the text >>>>>>> >>>>>>> 3. Section 3.2, >>>>>>> 3.1 first para first sentence >>>>>>> s/shall/SHALL >>>>>>> 3.2 last para, the last second sentence s/must/MUST >>>>>>> >>>>>>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP >>>>>>> concept, it's better to add related references to this document. >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Mach >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 07:30:29 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC4D1B2846; Thu, 31 Jul 2014 07:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_WcuxVw00be; Thu, 31 Jul 2014 07:20:34 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFED11A0059; Thu, 31 Jul 2014 07:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12608; q=dns/txt; s=iport; t=1406816433; x=1408026033; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oyXx9RwufBXMh8htdoDkACd0/TC3FqwXZ+VzMC6gSdA=; b=Tz90IpvxdzLuolw0f1WjKlUkRLltkx5IKMsfsvDgmzyytIAJU9iQwupW I47sA7QNo6ScAIzRxuF6r5wt/5SDh9pAhPGt3gco3e7sJFq7+Tk1vtU3i oOwFY+O01QJvWVH1JKhzadp7IMiJVZEJ4VILuWuItf+CLnvKy/LM885p4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAOxP2lOtJV2b/2dsb2JhbABZgmokUlcEyn8jDIdJAYEGFneEAwEBAQEDAQEBNy0EAwsMAgICAQgRBAEBAQoUCQcbDAsUCQgCBA4FCIg6AQy7RxMEBIl7hGsRAR8xBwaDKYEbBbA3g0lsAYECBwIXIg X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="344170868" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 31 Jul 2014 14:20:31 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6VEKVrK008641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 14:20:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 09:20:31 -0500 From: "Nobo Akiya (nobo)" To: Alexander Vainshtein Thread-Topic: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPrMlKRtb0V4c6eEO/q10Vgbo2Opu6OslQ Date: Thu, 31 Jul 2014 14:20:30 +0000 Message-ID: References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> <7adbcb851e224adbbd93416e5932b618@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <7adbcb851e224adbbd93416e5932b618@AM3PR03MB612.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/5B8oJ5RuwThiPsf5npZOzSTqMhg X-Mailman-Approved-At: Thu, 31 Jul 2014 07:30:24 -0700 Cc: "rtg-dir@ietf.org" , Mach Chen , "mpls@ietf.org" , "Sami Boutros \(sboutros\)" , "Shah, Himanshu" , "rtg-ads@tools.ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , Loa Andersson Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:20:42 -0000 Hi Sasha, I wish that was the case :) https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-par= ameters.xhtml#tlvs 32768-49161 Standards Action This range is for optional TLVs that can be silently dropped if not recogni= zed. Thanks, Nobo > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, July 31, 2014 10:11 AM > To: Nobo Akiya (nobo) > Cc: rtg-dir@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org= ; rtg- > ads@tools.ietf.org; mpls@ietf.org; Loa Andersson; Shah, Himanshu; Sami > Boutros (sboutros); Mach Chen > Subject: RE: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl= -tlv- > 07.txt >=20 > Nobo, and all, > 0x8001 =3D 32769 falls in the "Unassigned" range of TLVs for LSP Ping. I = think > that it has been considered as safe enough to use by the implementers. > Somehow the relevant IANA registry does not provide any values for > experimental use. >=20 > My 2c, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > > (nobo) > > Sent: Thursday, July 31, 2014 4:16 PM > > To: Loa Andersson; Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > > Cc: rtg-dir@ietf.org; > > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg- > > ads@tools.ietf.org; mpls@ietf.org > > Subject: Re: [mpls] [RTG-DIR] RtgDir review: > > draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt > > > > Hi Loa, Authors, > > > > The code base which I'm familiar with already have shipped > > implementation of the TTL TLV, and it appears that the Type=3D0x8001 is > being used. > > > > I do not have the knowledge of why this value was used in this > > implementation without doing early IANA allocation for the TTL TLV > > code point. > > > > If usage of Type=3D0x8001 as the TTL TLV does not conflict with any > > other implementations out there, is it possible to ask IANA to assign > > this value > > (0x8001) when the document progresses? > > > > My apologies for causing extra burden on the authors, the Shepherd and > > the ADs. > > > > But I truly hope that this request can be accommodated. > > > > Thanks! > > > > -Nobo > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > > > Sent: Thursday, July 31, 2014 8:08 AM > > > To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; > > > mpls@ietf.org; rtg-ads@tools.ietf.org > > > Subject: Re: [mpls] [RTG-DIR] RtgDir review: > > > draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt > > > > > > Himanshu, > > > > > > A request for early allocation need to come from the authors, to > > > wg-chairs and ADs. > > > > > > The draft is through IETF Last call and has been updated, given that > > > ADrian is comfortable it will be on the IESG agenda shortly. > > > > > > IANA has reviewed it and are OK. > > > > > > Normally I would not ask for early allocation this late in the proces= s. > > > > > > /Loa > > > > > > On 2014-07-31 01:15, Shah, Himanshu wrote: > > > > This draft fills a major shortcoming of the VCCV ping over MS-PW > > > (especially if reply mode is in-band). > > > > I am not sure why this draft is stuck (i.e. taking too long to go t= hrough). > > > > > > > > Is there a provisional IANA assignment for the TTL TLV type value? > > > > > > > > Thanks, > > > > himanshu > > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami > > > > Boutros > > > > (sboutros) > > > > Sent: Wednesday, July 30, 2014 3:44 PM > > > > To: Mach Chen > > > > Cc: rtg-dir@ietf.org; mpls@ietf.org; > > > > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; > > > > rtg-ads@tools.ietf.org > > > > Subject: Re: [mpls] RtgDir review: > > > > draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > > > > > > > Resending.. > > > > > > > > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: > > > > > > > >>> > > > >>> Minor Issues: > > > >>> > > > >>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional > > > >>> co-routed LSP, it should be better to explicitly state this in > > > >>> the abstract > > > section. > > > >>> > > > >> > > > >> Sami: Sure will do. > > > >> > > > >>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo > > > >>> request", "echo request" and "request" are interchangeably used > > > >>> in the draft, it's better to unify the usage of it to "MPLS echo > > > >>> request" (to align with the usage in RFC4379). For "echo reply", > > > >>> "bidirectional co-routed LSP", they have the similar issue. > > > >>> > > > >> > > > >> Sami: Ok, will fix that. > > > >> > > > >>> 3.Section 3.1 > > > >>> > > > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > + > > > >>> | Value | Reserved | Flags = | > > > >>> > > > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >>> > > > >>> For the TTL TLV, the value filed should include the "value", > > > >>> "Reserved" and "Flags", so it's better to change the "Value" > > > >>> field to "TTL" field hence to reduce the confusion. > > > >>> > > > >> > > > >> Sami: Sure. > > > >> > > > >>> 4. Section 3.2 > > > >>> "This TLV shall be included in the echo request by the > > > >>> originator of request. The use of this TLV is optional. If a > > > >>> receiver does not understand the TTL TLV, it will simply ignore > > > >>> the TLV (Type value of TLV is assumed to be in the range of > > > >>> optional TLV's which SHOULD be ignored if an implementation does > > > >>> not support or > > understand them). > > > >>> In the absence of TTL TLV or if TTL TLV is ignored by a > > > >>> receiver, the determination of the TTL value used in the MPLS > > > >>> label on the echo reply is beyond the scope of this document." > > > >>> > > > >>> What's your mean of "beyond the scope of this document" here? Is > > > >>> it to apply the procedures defined in RFC4379 or just let it to > > > >>> the implementation?I guess you assume to apply the definition in > > > >>> RFC4379, > > > >> > > > >> Sami: It is out of scope of this document, but for sure procedure > > > >> in 4379 > > > apply. > > > >>> if > > > >> > > > >>> so, the TTL of the MPLS label will be more probably set to 255, > > > >>> means the echo reply will be sent to the ingress of the MS-PW or > > > >>> LSP. I am not sure whether this is the right procedure, it seems > > > >>> a security issue. IMHO, it does not make any sense to expect the > > > >>> receiver to send echo reply in this situation, and even sent, > > > >>> the initiator will not receive the reply. The safer way is to > > > >>> drop the whole > > > echo request and record an error log. > > > >> > > > >> > > > >> Sami: > > > >> > > > >> We are not saying the receiver must send a reply, however if he > > > >> does the reply may be received by the ingress node which might be > > > >> the wrong node, since the receiver may not set the TTL properly > > > >> on the reply, keep in mind that this is a receiver with an old > > > >> implementation and > > > the TLV is optional. > > > >> > > > >> Please refer to the security section for your security concern. > > > >> > > > >> Sami: > > > >> > > > >> > > > >>> > > > >>> 5. Section 3.2 > > > >>> > > > >>> "In other words, if the value of the TTL provided by this TLV > > > >>> does not match the TTL determined by other means, such as > > > >>> Switching Point TLV in MS-PW, then TTL TLV must be used." > > > >>> Here, it implies that the receiver has to perform TTL matching > > > >>> process, since how to set the TTL is independent of such > > > >>> matching, seems this sentence is redundant and confusion. > > > >>> > > > >> > > > >> Sami: Are you familiar with the switching point TLV? and what it > > > includes? > > > >> > > > >>> 6. Section 4. > > > >>> > > > >>> "...The value field of the TTL TLV and the TTL field of the MPLS > > > >>> label are set to 2," > > > >>> > > > >>> I guess that the MPLS Label is the PW label, right? It's better > > > >>> to add more text to make this more explicit. In addition, how to > > > >>> set the TTL value of the tunnel Label? 255 or any other value? > > > >>> > > > >> > > > >> Sami: The tunnel label TTL is irrelevant here, however we will > > > >> make it > > > explicit that this is a PW label. > > > >> > > > >>> 5. Section 4.1. Traceroute mode > > > >>> "In the traceroute mode TTL value in the TLV is successively > > > >>> set to 1, 2, and so on. This is similar to the TTL values used > > > >>> for the label set on the packet." > > > >>> IMHO, some text may be needed to clarify which "FEC" should be > > > >>> carried, especially for MS-PW trace. Since in Section 4.0, the > > > >>> example says the FEC of segment C-D should be carried, does it > > > >>> mean the FEC of last PW Segment of the segment under test should > > > >>> be carried or the FEC will vary when TTL changed. For example, > > > >>> when perform segment trace (e.g., to trace B-D segment), when > > > >>> TTL is 1, which > > > FEC should be carried? > > > >> > > > >> Sami: > > > >> We are not here redefining a trace route for a MS-PW, we are > > > >> describing > > > how our extensions will apply. > > > >> Sami: > > > >> > > > >>> > > > >>> 6. Section 4.2. Error scenario > > > >>> For this scenario, do you need to define some error codes here? > > > >> > > > >> Sami: > > > >> The section describe how to handle the error scenario, there is > > > >> no need > > > for an error code. > > > >> Sami: > > > >> > > > >>> > > > >>> 7. For MS-PW trace, seems that you assume the tunnel is pipe > > > >>> mode, if so, it should be explicitly stated. If not, you should > > > >>> define how the MS-PW trace works (given that the tunnels in both > > > >>> directions may span different hops). > > > >> > > > >> Sami: > > > >> Not sure I get the concern? Again we are not re-defining how > > > >> MS-PW > > > trace work. > > > >> > > > >> Thanks, > > > >> > > > >> Sami > > > >>> > > > >>> Nits: > > > >>> > > > >>> 1. Please check the text for acronyms that have not been > > > >>> expanded in their first use. > > > >>> > > > >>> 2. I run the idnits tool and found the following nits, please > > > >>> check and fix. > > > >>> (See RFCs 3967 and 4897 for information about using normative > > > >>> references > > > >>> to lower-maturity documents in RFCs) > > > >>> > > > >>> -- Looks like a reference, but probably isn't: 'RFC2119' on line > > > >>> 121 > > > >>> > > > >>> -- Looks like a reference, but probably isn't: 'RFC4379' on line > > > >>> 258 > > > >>> > > > >>> =3D=3D Unused Reference: '1' is defined on line 284, but no expli= cit > > > >>> reference > > > >>> was found in the text > > > >>> > > > >>> =3D=3D Unused Reference: '2' is defined on line 287, but no expli= cit > > > >>> reference > > > >>> was found in the text > > > >>> > > > >>> =3D=3D Unused Reference: '3' is defined on line 291, but no expli= cit > > > >>> reference > > > >>> was found in the text > > > >>> > > > >>> 3. Section 3.2, > > > >>> 3.1 first para first sentence > > > >>> s/shall/SHALL > > > >>> 3.2 last para, the last second sentence s/must/MUST > > > >>> > > > >>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP > > > >>> concept, it's better to add related references to this document. > > > >>> > > > >>> > > > >>> Best regards, > > > >>> Mach > > > >>> > > > >>> > > > >> > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > -- > > > > > > > > > Loa Andersson email: loa@mail01.huawei.com > > > Senior MPLS Expert loa@pi.nu > > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 31 07:37:37 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290EF1B28F2 for ; Thu, 31 Jul 2014 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyGyna0iM2jI for ; Thu, 31 Jul 2014 07:37:30 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C159C1B28F3 for ; Thu, 31 Jul 2014 07:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23419; q=dns/txt; s=iport; t=1406817427; x=1408027027; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Haj0GkxnYOZrqjHoAQQ3+NuSNRbYndRAUduO+7396Bk=; b=d7q00GRu/T0yw8vVqpCoIqhK5KLA/QomgB1KOe00j39lsFzxH7Kk94az b6VMHPUiGTWXPxApLHVG2orwhNJZ9fDIIqY86Fhp2I014jiGNwjM48nqb tWYXsh977WIkzRsvpd1pVWa3A0iLuG7f1MznWu4eY/HQaoo4ZHy4ZmbDP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAOVT2lOtJV2Z/2dsb2JhbABZgkdHUlcEyyyHSwGBBhZ3hAMBAQEBAy1MEAIBCBEDAQEBCxYHByERFAkIAgQBDQUIAQsHiBMDEQ2zfA2HDheNH4F8IBEGAYMvgRsFjmWIWYIhkDOGJYNJbAGBBCQc X-IronPort-AV: E=Sophos; i="5.01,772,1400025600"; d="scan'208,217"; a="65489686" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 31 Jul 2014 14:37:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6VEb5CH004178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 14:37:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 09:37:05 -0500 From: "Les Ginsberg (ginsberg)" To: "Acee Lindem (acee)" , manav bhatia Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt Thread-Index: AQHPrLoUFdmBB0mVgk+oxcK2WPmbF5u6hkMA//+4DtA= Date: Thu, 31 Jul 2014 14:37:04 +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.21.147.59] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F23E89092xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/UwLp95-OkL0MxNdBIHxmIbUfNt4 Cc: "rtg-dir@ietf.org" , "draft-ietf-karp-bfd-analysis@tools.ietf.org" , "zhangdacheng@huawei.com" , "all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mjethanandani@gmail.com" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:37:36 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F23E89092xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Manav/Acee - Thanx for the replies. Given that the IETF community at large does not favo= r use of UTC (as demonstrated by how various protocols have addressed the r= eplay attack issue) AND the fact that at least one of the authors also does= n't favor it there seems little justification for keeping this text in the = document. The responses from Manav and Acee advance the case for changing t= he text - though I am stopping short of saying this is a MUST - largely bec= ause as a practical matter the BFD WG seems to have been smart enough (in p= art because of you Manav) to ignore this recommendation. Les From: Acee Lindem (acee) Sent: Thursday, July 31, 2014 6:47 AM To: manav bhatia; Les Ginsberg (ginsberg) Cc: rtg-dir@ietf.org; draft-ietf-karp-bfd-analysis@tools.ietf.org; zhangdac= heng@huawei.com; all@tools.ietf.org; rtg-ads@tools.ietf.org; mjethanandani@= gmail.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt Hi Manav, I agree with Les though I may have logged this as a major issue. What if th= e next-hop used to reach your NTP server is validated using authenticated m= ulti-hop BFD? Also, It is seems a bit superficial to recommend usage of UT= C for the high order 32 bits of the sequence number without dealing without= mentioning the 2038 wrap for the UNIX time. Thanks, Acee From: Manav Bhatia = > Date: Thursday, July 31, 2014 at 8:22 AM To: "Les Ginsberg (ginsberg)" > Cc: "rtg-dir@ietf.org" >, "draft-ietf-karp-bfd-analysis@tools.ietf.org" >, "zhangdach= eng@huawei.com" >, "all@tools.ietf.org" >, "rtg-ads@tools.ietf.o= rg" >, "mjethanandani@gmail.com" = > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt Hi Les, Thanks for the comments. Minor Issues: I am a little surprised that the use of UTC is emphasized as = a means of preventing replay attacks. While this is certainly a viable solu= tion what has been more commonly used by a number of other protocols is res= erving a portion of the sequence number for a boot count. In fact this is t= he way that http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.tx= t has chosen. Yet this document chooses to emphasize UTC encoding. I am the author of the standards that started using the boot count initiall= y as a way to preserve the crypto sequence count. I am not a big fan of UTC= and this was suggested as a plausible mechanism that did not appear to be = outright loony (especially when you have increased the seq space to 64 bits= ). Let me put it this way - I wouldnt be baying for blood if the directorat= e believes that this is a retrogressive step and we need to snip out that s= ection. Nits: 1)The affiliation for one of the authors (Manav) is inconsistent in the hea= der vs the authors addresses section. Will fix this. For the record, i now work for Ionos Networks. 2)In the Introduction the last sentence of the second paragraph reads: "Moving the routing protocols to a stronger algorithm while using weaker algorithm for BFD would require the attacker to bring down BFD in order to bring down the routing protocol. " I think what is meant is that if the BFD authentication algorithm is weaker= than that used by the routing protocols it is more likely to be the target= of an attack. The phrase "require the attacker..." seems inappropriate. Gotcha. Will fix this. 3)Section 3 last sentence of the penultimate paragraph: s/reply/replay .. and this. 4)Section 6 Second paragraph second sentence s/notion/the notion .. and this as well. Thanks, Manav Thanx. Les --_000_F3ADE4747C9E124B89F0ED2180CC814F23E89092xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Manav/Acee –

 <= /p>

Thanx for the replies. Gi= ven that the IETF community at large does not favor use of UTC (as demonstr= ated by how various protocols have addressed the replay attack issue) AND the fact that at least one of the authors also doesnR= 17;t favor it there seems little justification for keeping this text in the= document. The responses from Manav and Acee advance the case for changing = the text – though I am stopping short of saying this is a MUST – largely because as a practical matter the= BFD WG seems to have been smart enough (in part because of you Manav) to i= gnore this recommendation.

 <= /p>

   Les

 <= /p>

 <= /p>

From: Acee Lin= dem (acee)
Sent: Thursday, July 31, 2014 6:47 AM
To: manav bhatia; Les Ginsberg (ginsberg)
Cc: rtg-dir@ietf.org; draft-ietf-karp-bfd-analysis@tools.ietf.org; z= hangdacheng@huawei.com; all@tools.ietf.org; rtg-ads@tools.ietf.org; mjethan= andani@gmail.com
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-0= 4.txt

 

Hi Manav, <= /span>

I agree with Les though I m= ay have logged this as a major issue. What if the next-hop used to reach yo= ur NTP server is validated using authenticated multi-hop BFD?  Also, It is seems a bit superficial to recommend usage of UTC f= or the high order 32 bits of the sequence number without dealing without me= ntioning the 2038 wrap for the UNIX time. 

Thanks,

Acee 

 

 

Hi Les,

 

Thanks for the comments.

 

Minor Issues: I am a little surprised that the = use of UTC is emphasized as a means of preventing replay attacks. While thi= s is certainly a viable solution what has been more commonly used by a number of other protocols is reserving a portion of the sequence= number for a boot count. In fact this is the way that http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.txt  = has chosen. Yet this document chooses to emphasize UTC encoding.=

 

I am the author of the stan= dards that started using the boot count initially as a way to preserve the = crypto sequence count. I am not a big fan of UTC and this was suggested as a plausible mechanism that did not appear to be outright = loony (especially when you have increased the seq space to 64 bits). Let me= put it this way - I wouldnt be baying for blood if the directorate believe= s that this is a retrogressive step and we need to snip out that section.

 

Nits:

 

1)The affiliation for one of the authors (Manav= ) is inconsistent in the header vs the authors addresses section.

 

Will fix this. For the reco= rd, i now work for Ionos Networks.

 

 

2)In the Introduction the last sentence of the = second paragraph reads:

 

"Moving the routing protocols to a stronge= r

   algorithm while using weaker algor= ithm for BFD would require the

   attacker to bring down BFD in orde= r to bring down the routing

   protocol. "=

I think what is meant is that if the BFD authen= tication algorithm is weaker than that used by the routing protocols it is = more likely to be the target of an attack. The phrase "require the attacker..." seems inappropriate.=

 

Gotcha. Will fix this.=

 

 

3)Section 3 last sentence of the penultimate pa= ragraph:

 

s/reply/replay

 

.. and this.

 

 

4)Section 6 Second paragraph second sentence

 

s/notion/the notion

 

.. and this as well.

 

Thanks,

 

Manav  

 

Thanx.

 

   Les

 

 

--_000_F3ADE4747C9E124B89F0ED2180CC814F23E89092xmbalnx02ciscoc_-- From nobody Thu Jul 31 07:44:57 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079791B28BB; Thu, 31 Jul 2014 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53ZvKoUgvICc; Thu, 31 Jul 2014 07:44:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F48E1A005B; Thu, 31 Jul 2014 07:44:50 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 90FE41802B19; Thu, 31 Jul 2014 16:44:48 +0200 (CEST) Message-ID: <53DA565F.3030906@pi.nu> Date: Thu, 31 Jul 2014 16:44:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nobo Akiya (nobo)" , Alexander Vainshtein References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> <7adbcb851e224adbbd93416e5932b618@AM3PR03MB612.eurprd03.prod.outlook.com> <53DA52D0.8030206@pi.nu> In-Reply-To: <53DA52D0.8030206@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/AZgKA3aPnaybwRM5mxZDIxWjnMA Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Sami Boutros \(sboutros\)" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:44:54 -0000 Nobo, dam it - you are not an author of this document, so you can't request the early allocation. If you think we should do it, tell one of the authors to send me a mail. /Loa On 2014-07-31 16:29, Loa Andersson wrote: > Nobo, > > If that is what you want, I can initiate the procedure to allocate that > code point. > > /Loa > > On 2014-07-31 16:20, Nobo Akiya (nobo) wrote: >> Hi Sasha, >> >> I wish that was the case :) >> >> https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#tlvs >> >> >> 32768-49161 >> Standards Action >> This range is for optional TLVs that can be silently dropped if not >> recognized. >> >> Thanks, >> Nobo >> >>> -----Original Message----- >>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >>> Sent: Thursday, July 31, 2014 10:11 AM >>> To: Nobo Akiya (nobo) >>> Cc: rtg-dir@ietf.org; >>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg- >>> ads@tools.ietf.org; mpls@ietf.org; Loa Andersson; Shah, Himanshu; Sami >>> Boutros (sboutros); Mach Chen >>> Subject: RE: [mpls] [RTG-DIR] RtgDir review: >>> draft-ietf-mpls-lsp-ping-ttl-tlv- >>> 07.txt >>> >>> Nobo, and all, >>> 0x8001 = 32769 falls in the "Unassigned" range of TLVs for LSP Ping. >>> I think >>> that it has been considered as safe enough to use by the implementers. >>> Somehow the relevant IANA registry does not provide any values for >>> experimental use. >>> >>> My 2c, >>> Sasha >>> Email: Alexander.Vainshtein@ecitele.com >>> Mobile: 054-9266302 >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya >>>> (nobo) >>>> Sent: Thursday, July 31, 2014 4:16 PM >>>> To: Loa Andersson; Shah, Himanshu; Sami Boutros (sboutros); Mach Chen >>>> Cc: rtg-dir@ietf.org; >>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg- >>>> ads@tools.ietf.org; mpls@ietf.org >>>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: >>>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt >>>> >>>> Hi Loa, Authors, >>>> >>>> The code base which I'm familiar with already have shipped >>>> implementation of the TTL TLV, and it appears that the Type=0x8001 is >>> being used. >>>> >>>> I do not have the knowledge of why this value was used in this >>>> implementation without doing early IANA allocation for the TTL TLV >>>> code point. >>>> >>>> If usage of Type=0x8001 as the TTL TLV does not conflict with any >>>> other implementations out there, is it possible to ask IANA to assign >>>> this value >>>> (0x8001) when the document progresses? >>>> >>>> My apologies for causing extra burden on the authors, the Shepherd and >>>> the ADs. >>>> >>>> But I truly hope that this request can be accommodated. >>>> >>>> Thanks! >>>> >>>> -Nobo >>>> >>>>> -----Original Message----- >>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >>>>> Sent: Thursday, July 31, 2014 8:08 AM >>>>> To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen >>>>> Cc: rtg-dir@ietf.org; >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >>>>> mpls@ietf.org; rtg-ads@tools.ietf.org >>>>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt >>>>> >>>>> Himanshu, >>>>> >>>>> A request for early allocation need to come from the authors, to >>>>> wg-chairs and ADs. >>>>> >>>>> The draft is through IETF Last call and has been updated, given that >>>>> ADrian is comfortable it will be on the IESG agenda shortly. >>>>> >>>>> IANA has reviewed it and are OK. >>>>> >>>>> Normally I would not ask for early allocation this late in the >>>>> process. >>>>> >>>>> /Loa >>>>> >>>>> On 2014-07-31 01:15, Shah, Himanshu wrote: >>>>>> This draft fills a major shortcoming of the VCCV ping over MS-PW >>>>> (especially if reply mode is in-band). >>>>>> I am not sure why this draft is stuck (i.e. taking too long to go >>>>>> through). >>>>>> >>>>>> Is there a provisional IANA assignment for the TTL TLV type value? >>>>>> >>>>>> Thanks, >>>>>> himanshu >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami >>>>>> Boutros >>>>>> (sboutros) >>>>>> Sent: Wednesday, July 30, 2014 3:44 PM >>>>>> To: Mach Chen >>>>>> Cc: rtg-dir@ietf.org; mpls@ietf.org; >>>>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >>>>>> rtg-ads@tools.ietf.org >>>>>> Subject: Re: [mpls] RtgDir review: >>>>>> draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >>>>>> >>>>>> Resending.. >>>>>> >>>>>> On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >>>>>> >>>>>>>> >>>>>>>> Minor Issues: >>>>>>>> >>>>>>>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional >>>>>>>> co-routed LSP, it should be better to explicitly state this in >>>>>>>> the abstract >>>>> section. >>>>>>>> >>>>>>> >>>>>>> Sami: Sure will do. >>>>>>> >>>>>>>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo >>>>>>>> request", "echo request" and "request" are interchangeably used >>>>>>>> in the draft, it's better to unify the usage of it to "MPLS echo >>>>>>>> request" (to align with the usage in RFC4379). For "echo reply", >>>>>>>> "bidirectional co-routed LSP", they have the similar issue. >>>>>>>> >>>>>>> >>>>>>> Sami: Ok, will fix that. >>>>>>> >>>>>>>> 3.Section 3.1 >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> + >>>>>>>> | Value | Reserved | >>>>>>>> Flags | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>> For the TTL TLV, the value filed should include the "value", >>>>>>>> "Reserved" and "Flags", so it's better to change the "Value" >>>>>>>> field to "TTL" field hence to reduce the confusion. >>>>>>>> >>>>>>> >>>>>>> Sami: Sure. >>>>>>> >>>>>>>> 4. Section 3.2 >>>>>>>> "This TLV shall be included in the echo request by the >>>>>>>> originator of request. The use of this TLV is optional. If a >>>>>>>> receiver does not understand the TTL TLV, it will simply ignore >>>>>>>> the TLV (Type value of TLV is assumed to be in the range of >>>>>>>> optional TLV's which SHOULD be ignored if an implementation does >>>>>>>> not support or >>>> understand them). >>>>>>>> In the absence of TTL TLV or if TTL TLV is ignored by a >>>>>>>> receiver, the determination of the TTL value used in the MPLS >>>>>>>> label on the echo reply is beyond the scope of this document." >>>>>>>> >>>>>>>> What's your mean of "beyond the scope of this document" here? Is >>>>>>>> it to apply the procedures defined in RFC4379 or just let it to >>>>>>>> the implementation?I guess you assume to apply the definition in >>>>>>>> RFC4379, >>>>>>> >>>>>>> Sami: It is out of scope of this document, but for sure procedure >>>>>>> in 4379 >>>>> apply. >>>>>>>> if >>>>>>> >>>>>>>> so, the TTL of the MPLS label will be more probably set to 255, >>>>>>>> means the echo reply will be sent to the ingress of the MS-PW or >>>>>>>> LSP. I am not sure whether this is the right procedure, it seems >>>>>>>> a security issue. IMHO, it does not make any sense to expect the >>>>>>>> receiver to send echo reply in this situation, and even sent, >>>>>>>> the initiator will not receive the reply. The safer way is to >>>>>>>> drop the whole >>>>> echo request and record an error log. >>>>>>> >>>>>>> >>>>>>> Sami: >>>>>>> >>>>>>> We are not saying the receiver must send a reply, however if he >>>>>>> does the reply may be received by the ingress node which might be >>>>>>> the wrong node, since the receiver may not set the TTL properly >>>>>>> on the reply, keep in mind that this is a receiver with an old >>>>>>> implementation and >>>>> the TLV is optional. >>>>>>> >>>>>>> Please refer to the security section for your security concern. >>>>>>> >>>>>>> Sami: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 5. Section 3.2 >>>>>>>> >>>>>>>> "In other words, if the value of the TTL provided by this TLV >>>>>>>> does not match the TTL determined by other means, such as >>>>>>>> Switching Point TLV in MS-PW, then TTL TLV must be used." >>>>>>>> Here, it implies that the receiver has to perform TTL matching >>>>>>>> process, since how to set the TTL is independent of such >>>>>>>> matching, seems this sentence is redundant and confusion. >>>>>>>> >>>>>>> >>>>>>> Sami: Are you familiar with the switching point TLV? and what it >>>>> includes? >>>>>>> >>>>>>>> 6. Section 4. >>>>>>>> >>>>>>>> "...The value field of the TTL TLV and the TTL field of the MPLS >>>>>>>> label are set to 2," >>>>>>>> >>>>>>>> I guess that the MPLS Label is the PW label, right? It's better >>>>>>>> to add more text to make this more explicit. In addition, how to >>>>>>>> set the TTL value of the tunnel Label? 255 or any other value? >>>>>>>> >>>>>>> >>>>>>> Sami: The tunnel label TTL is irrelevant here, however we will >>>>>>> make it >>>>> explicit that this is a PW label. >>>>>>> >>>>>>>> 5. Section 4.1. Traceroute mode >>>>>>>> "In the traceroute mode TTL value in the TLV is successively >>>>>>>> set to 1, 2, and so on. This is similar to the TTL values used >>>>>>>> for the label set on the packet." >>>>>>>> IMHO, some text may be needed to clarify which "FEC" should be >>>>>>>> carried, especially for MS-PW trace. Since in Section 4.0, the >>>>>>>> example says the FEC of segment C-D should be carried, does it >>>>>>>> mean the FEC of last PW Segment of the segment under test should >>>>>>>> be carried or the FEC will vary when TTL changed. For example, >>>>>>>> when perform segment trace (e.g., to trace B-D segment), when >>>>>>>> TTL is 1, which >>>>> FEC should be carried? >>>>>>> >>>>>>> Sami: >>>>>>> We are not here redefining a trace route for a MS-PW, we are >>>>>>> describing >>>>> how our extensions will apply. >>>>>>> Sami: >>>>>>> >>>>>>>> >>>>>>>> 6. Section 4.2. Error scenario >>>>>>>> For this scenario, do you need to define some error codes here? >>>>>>> >>>>>>> Sami: >>>>>>> The section describe how to handle the error scenario, there is >>>>>>> no need >>>>> for an error code. >>>>>>> Sami: >>>>>>> >>>>>>>> >>>>>>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe >>>>>>>> mode, if so, it should be explicitly stated. If not, you should >>>>>>>> define how the MS-PW trace works (given that the tunnels in both >>>>>>>> directions may span different hops). >>>>>>> >>>>>>> Sami: >>>>>>> Not sure I get the concern? Again we are not re-defining how >>>>>>> MS-PW >>>>> trace work. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Sami >>>>>>>> >>>>>>>> Nits: >>>>>>>> >>>>>>>> 1. Please check the text for acronyms that have not been >>>>>>>> expanded in their first use. >>>>>>>> >>>>>>>> 2. I run the idnits tool and found the following nits, please >>>>>>>> check and fix. >>>>>>>> (See RFCs 3967 and 4897 for information about using normative >>>>>>>> references >>>>>>>> to lower-maturity documents in RFCs) >>>>>>>> >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC2119' on line >>>>>>>> 121 >>>>>>>> >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC4379' on line >>>>>>>> 258 >>>>>>>> >>>>>>>> == Unused Reference: '1' is defined on line 284, but no explicit >>>>>>>> reference >>>>>>>> was found in the text >>>>>>>> >>>>>>>> == Unused Reference: '2' is defined on line 287, but no explicit >>>>>>>> reference >>>>>>>> was found in the text >>>>>>>> >>>>>>>> == Unused Reference: '3' is defined on line 291, but no explicit >>>>>>>> reference >>>>>>>> was found in the text >>>>>>>> >>>>>>>> 3. Section 3.2, >>>>>>>> 3.1 first para first sentence >>>>>>>> s/shall/SHALL >>>>>>>> 3.2 last para, the last second sentence s/must/MUST >>>>>>>> >>>>>>>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP >>>>>>>> concept, it's better to add related references to this document. >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mach >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 07:51:00 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297C31B28BB; Thu, 31 Jul 2014 07:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOzyds3Wt2-B; Thu, 31 Jul 2014 07:50:53 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151681A014C; Thu, 31 Jul 2014 07:50:53 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8031C1802B19; Thu, 31 Jul 2014 16:50:51 +0200 (CEST) Message-ID: <53DA57CA.8010001@pi.nu> Date: Thu, 31 Jul 2014 16:50:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Shah, Himanshu" , "Sami Boutros (sboutros)" , Mach Chen References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> <40746B2300A8FC4AB04EE722A593182B76F4F335@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B76F4F335@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Ticg94cUqfL8KFRRkAgenZ1RrQ4 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:50:56 -0000 Himanshu, The process is that authors request through a mail to the wg chairs, chairs initiate this by a mail to IANA and the ADs. Get an author to send the request to wg-chairs. /Loa On 2014-07-31 15:14, Shah, Himanshu wrote: > Thanks Loa. > Early allocation request could have been made much earlier, but that is water under the bridge now. > I would still favor requesting for provisional IANA code allocation now. > This would allow interoperability of the ongoing implementations. > > /himanshu > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, July 31, 2014 8:08 AM > To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > Cc: rtg-dir@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg-ads@tools.ietf.org; mpls@ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > Himanshu, > > A request for early allocation need to come from the authors, to wg-chairs and ADs. > > The draft is through IETF Last call and has been updated, given that ADrian is comfortable it will be on the IESG agenda shortly. > > IANA has reviewed it and are OK. > > Normally I would not ask for early allocation this late in the process. > > /Loa > > On 2014-07-31 01:15, Shah, Himanshu wrote: >> This draft fills a major shortcoming of the VCCV ping over MS-PW (especially if reply mode is in-band). >> I am not sure why this draft is stuck (i.e. taking too long to go through). >> >> Is there a provisional IANA assignment for the TTL TLV type value? >> >> Thanks, >> himanshu >> >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros >> (sboutros) >> Sent: Wednesday, July 30, 2014 3:44 PM >> To: Mach Chen >> Cc: rtg-dir@ietf.org; mpls@ietf.org; >> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >> rtg-ads@tools.ietf.org >> Subject: Re: [mpls] RtgDir review: >> draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >> >> Resending.. >> >> On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >> >>>> >>>> Minor Issues: >>>> >>>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional >>>> co-routed LSP, it should be better to explicitly state this in the abstract section. >>>> >>> >>> Sami: Sure will do. >>> >>>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", >>>> "echo request" and "request" are interchangeably used in the draft, >>>> it's better to unify the usage of it to "MPLS echo request" (to >>>> align with the usage in RFC4379). For "echo reply", "bidirectional >>>> co-routed LSP", they have the similar issue. >>>> >>> >>> Sami: Ok, will fix that. >>> >>>> 3.Section 3.1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Value | Reserved | Flags | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> For the TTL TLV, the value filed should include the "value", >>>> "Reserved" and "Flags", so it's better to change the "Value" field >>>> to "TTL" field hence to reduce the confusion. >>>> >>> >>> Sami: Sure. >>> >>>> 4. Section 3.2 >>>> "This TLV shall be included in the echo request by the originator of >>>> request. The use of this TLV is optional. If a receiver does not >>>> understand the TTL TLV, it will simply ignore the TLV (Type value of >>>> TLV is assumed to be in the range of optional TLV's which SHOULD be >>>> ignored if an implementation does not support or understand them). >>>> In the absence of TTL TLV or if TTL TLV is ignored by a receiver, >>>> the determination of the TTL value used in the MPLS label on the >>>> echo reply is beyond the scope of this document." >>>> >>>> What's your mean of "beyond the scope of this document" here? Is it >>>> to apply the procedures defined in RFC4379 or just let it to the >>>> implementation?I guess you assume to apply the definition in >>>> RFC4379, >>> >>> Sami: It is out of scope of this document, but for sure procedure in 4379 apply. >>>> if >>> >>>> so, the TTL of the MPLS label will be more probably set to 255, >>>> means the echo reply will be sent to the ingress of the MS-PW or >>>> LSP. I am not sure whether this is the right procedure, it seems a >>>> security issue. IMHO, it does not make any sense to expect the >>>> receiver to send echo reply in this situation, and even sent, the >>>> initiator will not receive the reply. The safer way is to drop the whole echo request and record an error log. >>> >>> >>> Sami: >>> >>> We are not saying the receiver must send a reply, however if he does >>> the reply may be received by the ingress node which might be the >>> wrong node, since the receiver may not set the TTL properly on the >>> reply, keep in mind that this is a receiver with an old implementation and the TLV is optional. >>> >>> Please refer to the security section for your security concern. >>> >>> Sami: >>> >>> >>>> >>>> 5. Section 3.2 >>>> >>>> "In other words, if the value of the TTL provided by this TLV does >>>> not match the TTL determined by other means, such as Switching >>>> Point TLV in MS-PW, then TTL TLV must be used." >>>> Here, it implies that the receiver has to perform TTL matching >>>> process, since how to set the TTL is independent of such matching, >>>> seems this sentence is redundant and confusion. >>>> >>> >>> Sami: Are you familiar with the switching point TLV? and what it includes? >>> >>>> 6. Section 4. >>>> >>>> "...The value field of the TTL TLV and the TTL field of the MPLS >>>> label are set to 2," >>>> >>>> I guess that the MPLS Label is the PW label, right? It's better to >>>> add more text to make this more explicit. In addition, how to set >>>> the TTL value of the tunnel Label? 255 or any other value? >>>> >>> >>> Sami: The tunnel label TTL is irrelevant here, however we will make it explicit that this is a PW label. >>> >>>> 5. Section 4.1. Traceroute mode >>>> "In the traceroute mode TTL value in the TLV is successively set >>>> to 1, 2, and so on. This is similar to the TTL values used for the >>>> label set on the packet." >>>> IMHO, some text may be needed to clarify which "FEC" should be >>>> carried, especially for MS-PW trace. Since in Section 4.0, the >>>> example says the FEC of segment C-D should be carried, does it mean >>>> the FEC of last PW Segment of the segment under test should be >>>> carried or the FEC will vary when TTL changed. For example, when >>>> perform segment trace (e.g., to trace B-D segment), when TTL is 1, which FEC should be carried? >>> >>> Sami: >>> We are not here redefining a trace route for a MS-PW, we are describing how our extensions will apply. >>> Sami: >>> >>>> >>>> 6. Section 4.2. Error scenario >>>> For this scenario, do you need to define some error codes here? >>> >>> Sami: >>> The section describe how to handle the error scenario, there is no need for an error code. >>> Sami: >>> >>>> >>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, >>>> if so, it should be explicitly stated. If not, you should define how >>>> the MS-PW trace works (given that the tunnels in both directions may >>>> span different hops). >>> >>> Sami: >>> Not sure I get the concern? Again we are not re-defining how MS-PW trace work. >>> >>> Thanks, >>> >>> Sami >>>> >>>> Nits: >>>> >>>> 1. Please check the text for acronyms that have not been expanded in >>>> their first use. >>>> >>>> 2. I run the idnits tool and found the following nits, please check >>>> and fix. >>>> (See RFCs 3967 and 4897 for information about using normative >>>> references >>>> to lower-maturity documents in RFCs) >>>> >>>> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 >>>> >>>> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 >>>> >>>> == Unused Reference: '1' is defined on line 284, but no explicit >>>> reference >>>> was found in the text >>>> >>>> == Unused Reference: '2' is defined on line 287, but no explicit >>>> reference >>>> was found in the text >>>> >>>> == Unused Reference: '3' is defined on line 291, but no explicit >>>> reference >>>> was found in the text >>>> >>>> 3. Section 3.2, >>>> 3.1 first para first sentence >>>> s/shall/SHALL >>>> 3.2 last para, the last second sentence s/must/MUST >>>> >>>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP >>>> concept, it's better to add related references to this document. >>>> >>>> >>>> Best regards, >>>> Mach >>>> >>>> >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 07:58:28 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51DD1B283B; Thu, 31 Jul 2014 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ0KWcKVnzXp; Thu, 31 Jul 2014 07:51:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C451B2909; Thu, 31 Jul 2014 07:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14800; q=dns/txt; s=iport; t=1406818283; x=1408027883; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IAHTfn8Nvfdn1PaOEOJmYkau9W6yBoVKLwT/g5ZkpMk=; b=jfdYgAs655+9XZJzhNaSWceBHufx07zthq5b+xTh3SnSduZngq+nWSVc P7IriSd73sWWaAykYsvpGCZdiSqEnH+FdtkEcPPYU2U4Py6MZfD4g71dV PPg8Gh4XnNg+3eM/IPdxIjhXa6Bn0dgYuVNlCl4IgKVGe7RPQAc+q2lVP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FALtX2lOtJV2c/2dsb2JhbABZgmokUlcEyn8jCodLAYEGFneEAwEBAQEDAQEBNy0EAwsMAgICAQgRBAEBAQoUCQcbDAsUCQgCBAENBQiIOgEMvCATBASJe4RrEAIBHjEHBoMpgRsFjmWPDpJEg0lsAYECBzs X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="344126695" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2014 14:51:02 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6VEp2nD016171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 14:51:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 09:51:01 -0500 From: "Nobo Akiya (nobo)" To: Loa Andersson , Alexander Vainshtein Thread-Topic: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPrMlKRtb0V4c6eEO/q10Vgbo2Opu6OslQgABXKgCAAAQ+gP//rTIA Date: Thu, 31 Jul 2014 14:51:01 +0000 Message-ID: References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> <7adbcb851e224adbbd93416e5932b618@AM3PR03MB612.eurprd03.prod.outlook.com> <53DA52D0.8030206@pi.nu> <53DA565F.3030906@pi.nu> In-Reply-To: <53DA565F.3030906@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/XcUCL60W4RmTKjWKsCMxvNaCvKM X-Mailman-Approved-At: Thu, 31 Jul 2014 07:58:24 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Sami Boutros \(sboutros\)" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:51:31 -0000 Hi Loa, Sorry about the confusion. I was requesting for a specific value to be allo= cated when the document progresses. But you are right, a better approach wo= uld be to initiate early IANA allocation to reserve that specific value, wh= ich should come from authors. I will reach out to the authors to send you an official request for early = IANA allocation with specific value (0x8001) for the TTL TLV. Thanks! -Nobo > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, July 31, 2014 10:45 AM > To: Nobo Akiya (nobo); Alexander Vainshtein > Cc: rtg-dir@ietf.org; mpls@ietf.org; Sami Boutros (sboutros); rtg- > ads@tools.ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org > Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl= -tlv- > 07.txt >=20 > Nobo, >=20 > dam it - you are not an author of this document, so you can't request the > early allocation. If you think we should do it, tell one of the authors t= o send > me a mail. >=20 > /Loa >=20 > On 2014-07-31 16:29, Loa Andersson wrote: > > Nobo, > > > > If that is what you want, I can initiate the procedure to allocate > > that code point. > > > > /Loa > > > > On 2014-07-31 16:20, Nobo Akiya (nobo) wrote: > >> Hi Sasha, > >> > >> I wish that was the case :) > >> > >> https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp- > pi > >> ng-parameters.xhtml#tlvs > >> > >> > >> 32768-49161 > >> Standards Action > >> This range is for optional TLVs that can be silently dropped if not > >> recognized. > >> > >> Thanks, > >> Nobo > >> > >>> -----Original Message----- > >>> From: Alexander Vainshtein > [mailto:Alexander.Vainshtein@ecitele.com] > >>> Sent: Thursday, July 31, 2014 10:11 AM > >>> To: Nobo Akiya (nobo) > >>> Cc: rtg-dir@ietf.org; > >>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg- > >>> ads@tools.ietf.org; mpls@ietf.org; Loa Andersson; Shah, Himanshu; > >>> Sami Boutros (sboutros); Mach Chen > >>> Subject: RE: [mpls] [RTG-DIR] RtgDir review: > >>> draft-ietf-mpls-lsp-ping-ttl-tlv- > >>> 07.txt > >>> > >>> Nobo, and all, > >>> 0x8001 =3D 32769 falls in the "Unassigned" range of TLVs for LSP Ping= . > >>> I think > >>> that it has been considered as safe enough to use by the implementers= . > >>> Somehow the relevant IANA registry does not provide any values for > >>> experimental use. > >>> > >>> My 2c, > >>> Sasha > >>> Email: Alexander.Vainshtein@ecitele.com > >>> Mobile: 054-9266302 > >>> > >>>> -----Original Message----- > >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya > >>>> (nobo) > >>>> Sent: Thursday, July 31, 2014 4:16 PM > >>>> To: Loa Andersson; Shah, Himanshu; Sami Boutros (sboutros); Mach > >>>> Chen > >>>> Cc: rtg-dir@ietf.org; > >>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg- > >>>> ads@tools.ietf.org; mpls@ietf.org > >>>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: > >>>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt > >>>> > >>>> Hi Loa, Authors, > >>>> > >>>> The code base which I'm familiar with already have shipped > >>>> implementation of the TTL TLV, and it appears that the Type=3D0x8001 > >>>> is > >>> being used. > >>>> > >>>> I do not have the knowledge of why this value was used in this > >>>> implementation without doing early IANA allocation for the TTL TLV > >>>> code point. > >>>> > >>>> If usage of Type=3D0x8001 as the TTL TLV does not conflict with any > >>>> other implementations out there, is it possible to ask IANA to > >>>> assign this value > >>>> (0x8001) when the document progresses? > >>>> > >>>> My apologies for causing extra burden on the authors, the Shepherd > >>>> and the ADs. > >>>> > >>>> But I truly hope that this request can be accommodated. > >>>> > >>>> Thanks! > >>>> > >>>> -Nobo > >>>> > >>>>> -----Original Message----- > >>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > >>>>> Andersson > >>>>> Sent: Thursday, July 31, 2014 8:08 AM > >>>>> To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > >>>>> Cc: rtg-dir@ietf.org; > >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; > >>>>> mpls@ietf.org; rtg-ads@tools.ietf.org > >>>>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: > >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt > >>>>> > >>>>> Himanshu, > >>>>> > >>>>> A request for early allocation need to come from the authors, to > >>>>> wg-chairs and ADs. > >>>>> > >>>>> The draft is through IETF Last call and has been updated, given > >>>>> that ADrian is comfortable it will be on the IESG agenda shortly. > >>>>> > >>>>> IANA has reviewed it and are OK. > >>>>> > >>>>> Normally I would not ask for early allocation this late in the > >>>>> process. > >>>>> > >>>>> /Loa > >>>>> > >>>>> On 2014-07-31 01:15, Shah, Himanshu wrote: > >>>>>> This draft fills a major shortcoming of the VCCV ping over MS-PW > >>>>> (especially if reply mode is in-band). > >>>>>> I am not sure why this draft is stuck (i.e. taking too long to go > >>>>>> through). > >>>>>> > >>>>>> Is there a provisional IANA assignment for the TTL TLV type value? > >>>>>> > >>>>>> Thanks, > >>>>>> himanshu > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami > >>>>>> Boutros > >>>>>> (sboutros) > >>>>>> Sent: Wednesday, July 30, 2014 3:44 PM > >>>>>> To: Mach Chen > >>>>>> Cc: rtg-dir@ietf.org; mpls@ietf.org; > >>>>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; > >>>>>> rtg-ads@tools.ietf.org > >>>>>> Subject: Re: [mpls] RtgDir review: > >>>>>> draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > >>>>>> > >>>>>> Resending.. > >>>>>> > >>>>>> On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: > >>>>>> > >>>>>>>> > >>>>>>>> Minor Issues: > >>>>>>>> > >>>>>>>> 1. Since the TTL TLV is defined for both MS-PW and > >>>>>>>> bidirectional co-routed LSP, it should be better to explicitly > >>>>>>>> state this in the abstract > >>>>> section. > >>>>>>>> > >>>>>>> > >>>>>>> Sami: Sure will do. > >>>>>>> > >>>>>>>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo > >>>>>>>> request", "echo request" and "request" are interchangeably used > >>>>>>>> in the draft, it's better to unify the usage of it to "MPLS > >>>>>>>> echo request" (to align with the usage in RFC4379). For "echo > >>>>>>>> reply", "bidirectional co-routed LSP", they have the similar iss= ue. > >>>>>>>> > >>>>>>> > >>>>>>> Sami: Ok, will fix that. > >>>>>>> > >>>>>>>> 3.Section 3.1 > >>>>>>>> > >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >>>> + > >>>>>>>> | Value | Reserved | > >>>>>>>> Flags | > >>>>>>>> > >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > >>>>>>>> > >>>>>>>> For the TTL TLV, the value filed should include the "value", > >>>>>>>> "Reserved" and "Flags", so it's better to change the "Value" > >>>>>>>> field to "TTL" field hence to reduce the confusion. > >>>>>>>> > >>>>>>> > >>>>>>> Sami: Sure. > >>>>>>> > >>>>>>>> 4. Section 3.2 > >>>>>>>> "This TLV shall be included in the echo request by the > >>>>>>>> originator of request. The use of this TLV is optional. If a > >>>>>>>> receiver does not understand the TTL TLV, it will simply ignore > >>>>>>>> the TLV (Type value of TLV is assumed to be in the range of > >>>>>>>> optional TLV's which SHOULD be ignored if an implementation > >>>>>>>> does not support or > >>>> understand them). > >>>>>>>> In the absence of TTL TLV or if TTL TLV is ignored by a > >>>>>>>> receiver, the determination of the TTL value used in the MPLS > >>>>>>>> label on the echo reply is beyond the scope of this document." > >>>>>>>> > >>>>>>>> What's your mean of "beyond the scope of this document" here? > >>>>>>>> Is it to apply the procedures defined in RFC4379 or just let it > >>>>>>>> to the implementation?I guess you assume to apply the > >>>>>>>> definition in RFC4379, > >>>>>>> > >>>>>>> Sami: It is out of scope of this document, but for sure > >>>>>>> procedure in 4379 > >>>>> apply. > >>>>>>>> if > >>>>>>> > >>>>>>>> so, the TTL of the MPLS label will be more probably set to 255, > >>>>>>>> means the echo reply will be sent to the ingress of the MS-PW > >>>>>>>> or LSP. I am not sure whether this is the right procedure, it > >>>>>>>> seems a security issue. IMHO, it does not make any sense to > >>>>>>>> expect the receiver to send echo reply in this situation, and > >>>>>>>> even sent, the initiator will not receive the reply. The safer > >>>>>>>> way is to drop the whole > >>>>> echo request and record an error log. > >>>>>>> > >>>>>>> > >>>>>>> Sami: > >>>>>>> > >>>>>>> We are not saying the receiver must send a reply, however if he > >>>>>>> does the reply may be received by the ingress node which might > >>>>>>> be the wrong node, since the receiver may not set the TTL > >>>>>>> properly on the reply, keep in mind that this is a receiver with > >>>>>>> an old implementation and > >>>>> the TLV is optional. > >>>>>>> > >>>>>>> Please refer to the security section for your security concern. > >>>>>>> > >>>>>>> Sami: > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> 5. Section 3.2 > >>>>>>>> > >>>>>>>> "In other words, if the value of the TTL provided by this TLV > >>>>>>>> does not match the TTL determined by other means, such as > >>>>>>>> Switching Point TLV in MS-PW, then TTL TLV must be used." > >>>>>>>> Here, it implies that the receiver has to perform TTL matching > >>>>>>>> process, since how to set the TTL is independent of such > >>>>>>>> matching, seems this sentence is redundant and confusion. > >>>>>>>> > >>>>>>> > >>>>>>> Sami: Are you familiar with the switching point TLV? and what it > >>>>> includes? > >>>>>>> > >>>>>>>> 6. Section 4. > >>>>>>>> > >>>>>>>> "...The value field of the TTL TLV and the TTL field of the > >>>>>>>> MPLS label are set to 2," > >>>>>>>> > >>>>>>>> I guess that the MPLS Label is the PW label, right? It's better > >>>>>>>> to add more text to make this more explicit. In addition, how > >>>>>>>> to set the TTL value of the tunnel Label? 255 or any other value= ? > >>>>>>>> > >>>>>>> > >>>>>>> Sami: The tunnel label TTL is irrelevant here, however we will > >>>>>>> make it > >>>>> explicit that this is a PW label. > >>>>>>> > >>>>>>>> 5. Section 4.1. Traceroute mode > >>>>>>>> "In the traceroute mode TTL value in the TLV is successively > >>>>>>>> set to 1, 2, and so on. This is similar to the TTL values used > >>>>>>>> for the label set on the packet." > >>>>>>>> IMHO, some text may be needed to clarify which "FEC" should be > >>>>>>>> carried, especially for MS-PW trace. Since in Section 4.0, the > >>>>>>>> example says the FEC of segment C-D should be carried, does it > >>>>>>>> mean the FEC of last PW Segment of the segment under test > >>>>>>>> should be carried or the FEC will vary when TTL changed. For > >>>>>>>> example, when perform segment trace (e.g., to trace B-D > >>>>>>>> segment), when TTL is 1, which > >>>>> FEC should be carried? > >>>>>>> > >>>>>>> Sami: > >>>>>>> We are not here redefining a trace route for a MS-PW, we are > >>>>>>> describing > >>>>> how our extensions will apply. > >>>>>>> Sami: > >>>>>>> > >>>>>>>> > >>>>>>>> 6. Section 4.2. Error scenario > >>>>>>>> For this scenario, do you need to define some error codes here? > >>>>>>> > >>>>>>> Sami: > >>>>>>> The section describe how to handle the error scenario, there is > >>>>>>> no need > >>>>> for an error code. > >>>>>>> Sami: > >>>>>>> > >>>>>>>> > >>>>>>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe > >>>>>>>> mode, if so, it should be explicitly stated. If not, you should > >>>>>>>> define how the MS-PW trace works (given that the tunnels in > >>>>>>>> both directions may span different hops). > >>>>>>> > >>>>>>> Sami: > >>>>>>> Not sure I get the concern? Again we are not re-defining how > >>>>>>> MS-PW > >>>>> trace work. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Sami > >>>>>>>> > >>>>>>>> Nits: > >>>>>>>> > >>>>>>>> 1. Please check the text for acronyms that have not been > >>>>>>>> expanded in their first use. > >>>>>>>> > >>>>>>>> 2. I run the idnits tool and found the following nits, please > >>>>>>>> check and fix. > >>>>>>>> (See RFCs 3967 and 4897 for information about using > >>>>>>>> normative references > >>>>>>>> to lower-maturity documents in RFCs) > >>>>>>>> > >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC2119' on > >>>>>>>> line > >>>>>>>> 121 > >>>>>>>> > >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC4379' on > >>>>>>>> line > >>>>>>>> 258 > >>>>>>>> > >>>>>>>> =3D=3D Unused Reference: '1' is defined on line 284, but no > >>>>>>>> explicit reference > >>>>>>>> was found in the text > >>>>>>>> > >>>>>>>> =3D=3D Unused Reference: '2' is defined on line 287, but no > >>>>>>>> explicit reference > >>>>>>>> was found in the text > >>>>>>>> > >>>>>>>> =3D=3D Unused Reference: '3' is defined on line 291, but no > >>>>>>>> explicit reference > >>>>>>>> was found in the text > >>>>>>>> > >>>>>>>> 3. Section 3.2, > >>>>>>>> 3.1 first para first sentence > >>>>>>>> s/shall/SHALL > >>>>>>>> 3.2 last para, the last second sentence s/must/MUST > >>>>>>>> > >>>>>>>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP > >>>>>>>> concept, it's better to add related references to this document. > >>>>>>>> > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Mach > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> > >>>>> Loa Andersson email: loa@mail01.huawei.com > >>>>> Senior MPLS Expert loa@pi.nu > >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >>>>> > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 07:58:30 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA02C1B291E; Thu, 31 Jul 2014 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrO3cT1oLoJa; Thu, 31 Jul 2014 07:53:28 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F8F1B2918; Thu, 31 Jul 2014 07:53:28 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6VEoAqF028447; Thu, 31 Jul 2014 10:53:18 -0400 Received: from vawvcgsie2k1302.ciena.com (LIN1-118-36-36.ciena.com [63.118.36.36]) by mx0a-00103a01.pphosted.com with ESMTP id 1nfnvjgk8a-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2014 10:53:18 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 31 Jul 2014 10:53:16 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Thu, 31 Jul 2014 10:53:15 -0400 From: "Shah, Himanshu" To: Loa Andersson , "Sami Boutros (sboutros)" , Mach Chen Date: Thu, 31 Jul 2014 10:53:13 -0400 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: Ac+szuADwTKMkNEOSJ2wl6PorYcynAAABCWg Message-ID: <40746B2300A8FC4AB04EE722A593182B76F4F480@ONWVEXCHMB04.ciena.com> References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> <40746B2300A8FC4AB04EE722A593182B76F4F335@ONWVEXCHMB04.ciena.com> <53DA57CA.8010001@pi.nu> In-Reply-To: <53DA57CA.8010001@pi.nu> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-07-31_05:2014-07-30,2014-07-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407310186 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/DnPydZssBZdoNXaPy7gYHhWkIHA X-Mailman-Approved-At: Thu, 31 Jul 2014 07:58:26 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:53:32 -0000 Sure. Thanks Loa.. (this is IETF.. we shouldn't get hung up on process thingy... :-)) /himanshu -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Thursday, July 31, 2014 10:51 AM To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen Cc: rtg-dir@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; = mpls@ietf.org; rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.t= xt Himanshu, The process is that authors request through a mail to the wg chairs, chairs= initiate this by a mail to IANA and the ADs. Get an author to send the request to wg-chairs. /Loa On 2014-07-31 15:14, Shah, Himanshu wrote: > Thanks Loa. > Early allocation request could have been made much earlier, but that is w= ater under the bridge now. > I would still favor requesting for provisional IANA code allocation now. > This would allow interoperability of the ongoing implementations. > > /himanshu > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, July 31, 2014 8:08 AM > To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen > Cc: rtg-dir@ietf.org;=20 > draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org;=20 > rtg-ads@tools.ietf.org; mpls@ietf.org > Subject: Re: [RTG-DIR] RtgDir review:=20 > draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > Himanshu, > > A request for early allocation need to come from the authors, to wg-chair= s and ADs. > > The draft is through IETF Last call and has been updated, given that ADri= an is comfortable it will be on the IESG agenda shortly. > > IANA has reviewed it and are OK. > > Normally I would not ask for early allocation this late in the process. > > /Loa > > On 2014-07-31 01:15, Shah, Himanshu wrote: >> This draft fills a major shortcoming of the VCCV ping over MS-PW (especi= ally if reply mode is in-band). >> I am not sure why this draft is stuck (i.e. taking too long to go throug= h). >> >> Is there a provisional IANA assignment for the TTL TLV type value? >> >> Thanks, >> himanshu >> >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros >> (sboutros) >> Sent: Wednesday, July 30, 2014 3:44 PM >> To: Mach Chen >> Cc: rtg-dir@ietf.org; mpls@ietf.org; >> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >> rtg-ads@tools.ietf.org >> Subject: Re: [mpls] RtgDir review: >> draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >> >> Resending.. >> >> On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >> >>>> >>>> Minor Issues: >>>> >>>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional=20 >>>> co-routed LSP, it should be better to explicitly state this in the abs= tract section. >>>> >>> >>> Sami: Sure will do. >>> >>>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo=20 >>>> request", "echo request" and "request" are interchangeably used in=20 >>>> the draft, it's better to unify the usage of it to "MPLS echo=20 >>>> request" (to align with the usage in RFC4379). For "echo reply",=20 >>>> "bidirectional co-routed LSP", they have the similar issue. >>>> >>> >>> Sami: Ok, will fix that. >>> >>>> 3.Section 3.1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + >>>> | Value | Reserved | Flags | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> For the TTL TLV, the value filed should include the "value",=20 >>>> "Reserved" and "Flags", so it's better to change the "Value" field=20 >>>> to "TTL" field hence to reduce the confusion. >>>> >>> >>> Sami: Sure. >>> >>>> 4. Section 3.2 >>>> "This TLV shall be included in the echo request by the originator=20 >>>> of request. The use of this TLV is optional. If a receiver does not=20 >>>> understand the TTL TLV, it will simply ignore the TLV (Type value=20 >>>> of TLV is assumed to be in the range of optional TLV's which SHOULD=20 >>>> be ignored if an implementation does not support or understand them). >>>> In the absence of TTL TLV or if TTL TLV is ignored by a receiver,=20 >>>> the determination of the TTL value used in the MPLS label on the=20 >>>> echo reply is beyond the scope of this document." >>>> >>>> What's your mean of "beyond the scope of this document" here? Is it=20 >>>> to apply the procedures defined in RFC4379 or just let it to the=20 >>>> implementation?I guess you assume to apply the definition in=20 >>>> RFC4379, >>> >>> Sami: It is out of scope of this document, but for sure procedure in 43= 79 apply. >>>> if >>> >>>> so, the TTL of the MPLS label will be more probably set to 255,=20 >>>> means the echo reply will be sent to the ingress of the MS-PW or=20 >>>> LSP. I am not sure whether this is the right procedure, it seems a=20 >>>> security issue. IMHO, it does not make any sense to expect the=20 >>>> receiver to send echo reply in this situation, and even sent, the=20 >>>> initiator will not receive the reply. The safer way is to drop the who= le echo request and record an error log. >>> >>> >>> Sami: >>> >>> We are not saying the receiver must send a reply, however if he does=20 >>> the reply may be received by the ingress node which might be the=20 >>> wrong node, since the receiver may not set the TTL properly on the=20 >>> reply, keep in mind that this is a receiver with an old implementation = and the TLV is optional. >>> >>> Please refer to the security section for your security concern. >>> >>> Sami: >>> >>> >>>> >>>> 5. Section 3.2 >>>> >>>> "In other words, if the value of the TTL provided by this TLV does=20 >>>> not match the TTL determined by other means, such as Switching=20 >>>> Point TLV in MS-PW, then TTL TLV must be used." >>>> Here, it implies that the receiver has to perform TTL matching=20 >>>> process, since how to set the TTL is independent of such matching,=20 >>>> seems this sentence is redundant and confusion. >>>> >>> >>> Sami: Are you familiar with the switching point TLV? and what it includ= es? >>> >>>> 6. Section 4. >>>> >>>> "...The value field of the TTL TLV and the TTL field of the MPLS=20 >>>> label are set to 2," >>>> >>>> I guess that the MPLS Label is the PW label, right? It's better to=20 >>>> add more text to make this more explicit. In addition, how to set=20 >>>> the TTL value of the tunnel Label? 255 or any other value? >>>> >>> >>> Sami: The tunnel label TTL is irrelevant here, however we will make it = explicit that this is a PW label. >>> >>>> 5. Section 4.1. Traceroute mode >>>> "In the traceroute mode TTL value in the TLV is successively set=20 >>>> to 1, 2, and so on. This is similar to the TTL values used for the=20 >>>> label set on the packet." >>>> IMHO, some text may be needed to clarify which "FEC" should be=20 >>>> carried, especially for MS-PW trace. Since in Section 4.0, the=20 >>>> example says the FEC of segment C-D should be carried, does it mean=20 >>>> the FEC of last PW Segment of the segment under test should be=20 >>>> carried or the FEC will vary when TTL changed. For example, when=20 >>>> perform segment trace (e.g., to trace B-D segment), when TTL is 1, whi= ch FEC should be carried? >>> >>> Sami: >>> We are not here redefining a trace route for a MS-PW, we are describin= g how our extensions will apply. >>> Sami: >>> >>>> >>>> 6. Section 4.2. Error scenario >>>> For this scenario, do you need to define some error codes here? >>> >>> Sami: >>> The section describe how to handle the error scenario, there is no need= for an error code. >>> Sami: >>> >>>> >>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode,=20 >>>> if so, it should be explicitly stated. If not, you should define=20 >>>> how the MS-PW trace works (given that the tunnels in both=20 >>>> directions may span different hops). >>> >>> Sami: >>> Not sure I get the concern? Again we are not re-defining how MS-PW trac= e work. >>> >>> Thanks, >>> >>> Sami >>>> >>>> Nits: >>>> >>>> 1. Please check the text for acronyms that have not been expanded=20 >>>> in their first use. >>>> >>>> 2. I run the idnits tool and found the following nits, please check=20 >>>> and fix. >>>> (See RFCs 3967 and 4897 for information about using normative=20 >>>> references >>>> to lower-maturity documents in RFCs) >>>> >>>> -- Looks like a reference, but probably isn't: 'RFC2119' on line=20 >>>> 121 >>>> >>>> -- Looks like a reference, but probably isn't: 'RFC4379' on line=20 >>>> 258 >>>> >>>> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit=20 >>>> reference >>>> was found in the text >>>> >>>> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit=20 >>>> reference >>>> was found in the text >>>> >>>> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit=20 >>>> reference >>>> was found in the text >>>> >>>> 3. Section 3.2, >>>> 3.1 first para first sentence >>>> s/shall/SHALL >>>> 3.2 last para, the last second sentence s/must/MUST >>>> >>>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP=20 >>>> concept, it's better to add related references to this document. >>>> >>>> >>>> Best regards, >>>> Mach >>>> >>>> >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 07:58:31 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1101B2921; Thu, 31 Jul 2014 07:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaEI6Jp8DCJM; Thu, 31 Jul 2014 07:53:35 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441751B291D; Thu, 31 Jul 2014 07:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13983; q=dns/txt; s=iport; t=1406818409; x=1408028009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sXo8HjfFVl3V7ys088WawA3tfb33YdFM3gQsvAl2NxU=; b=fmJ4XrjPKPWK1CCVZ4FBLD+/vnRji9rcD9z0drvQvrOpeSkS5OvoS+2l yJNO1btlx6Nch0p7KB3sRjudH6OH2zJ5X3Y1fHpxy/8nmLMfUqxu1cUao wZzJc3l/t1mM76fpSAn/hGkY56xOUD879o6kUdzBRgiNBAvBvd6r5CDdL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAEJX2lOtJA2E/2dsb2JhbABZgw5SVwTKfyMKh0sBgQYWd4QDAQEBAQMBAQE3LQQDCwwCAgIBCBEEAQEBChQJBxsMCxQJCAIEAQ0FCIg6DbwGEwQEiXuEaxACAR4xBwaDKYEbBbA3g0lsAYECBzs X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="65499024" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP; 31 Jul 2014 14:53:28 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6VErRva010227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 14:53:27 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 09:53:27 -0500 From: "Siva Sivabalan (msiva)" To: Loa Andersson , "Nobo Akiya (nobo)" , "Alexander Vainshtein" Thread-Topic: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHPrMlVmEpmxDEqmEysff6oRA2Y4Ju6j2gAgAACiwCAAAQ+gP//rZ/Q Date: Thu, 31 Jul 2014 14:53:26 +0000 Message-ID: References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <53DA3194.4040306@pi.nu> <7adbcb851e224adbbd93416e5932b618@AM3PR03MB612.eurprd03.prod.outlook.com> <53DA52D0.8030206@pi.nu> <53DA565F.3030906@pi.nu> In-Reply-To: <53DA565F.3030906@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/1SqyTVcNI8obUszjXpNswHGTD40 X-Mailman-Approved-At: Thu, 31 Jul 2014 07:58:26 -0700 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "Sami Boutros \(sboutros\)" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:53:39 -0000 Hi Loa, (chiming in as a co-author) Please could you do the needful to allocate the code-point. Thanks Himanshu and Nobo for initiating this discussion. Regards, Siva -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Thursday, July 31, 2014 10:45 AM To: Nobo Akiya (nobo); Alexander Vainshtein Cc: rtg-dir@ietf.org; mpls@ietf.org; Sami Boutros (sboutros); rtg-ads@tools= .ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-t= lv-07.txt Nobo, dam it - you are not an author of this document, so you can't request the e= arly allocation. If you think we should do it, tell one of the authors to s= end me a mail. /Loa On 2014-07-31 16:29, Loa Andersson wrote: > Nobo, > > If that is what you want, I can initiate the procedure to allocate=20 > that code point. > > /Loa > > On 2014-07-31 16:20, Nobo Akiya (nobo) wrote: >> Hi Sasha, >> >> I wish that was the case :) >> >> https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-pi >> ng-parameters.xhtml#tlvs >> >> >> 32768-49161 >> Standards Action >> This range is for optional TLVs that can be silently dropped if not=20 >> recognized. >> >> Thanks, >> Nobo >> >>> -----Original Message----- >>> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >>> Sent: Thursday, July 31, 2014 10:11 AM >>> To: Nobo Akiya (nobo) >>> Cc: rtg-dir@ietf.org; >>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg-=20 >>> ads@tools.ietf.org; mpls@ietf.org; Loa Andersson; Shah, Himanshu;=20 >>> Sami Boutros (sboutros); Mach Chen >>> Subject: RE: [mpls] [RTG-DIR] RtgDir review: >>> draft-ietf-mpls-lsp-ping-ttl-tlv- >>> 07.txt >>> >>> Nobo, and all, >>> 0x8001 =3D 32769 falls in the "Unassigned" range of TLVs for LSP Ping. >>> I think >>> that it has been considered as safe enough to use by the implementers. >>> Somehow the relevant IANA registry does not provide any values for=20 >>> experimental use. >>> >>> My 2c, >>> Sasha >>> Email: Alexander.Vainshtein@ecitele.com >>> Mobile: 054-9266302 >>> >>>> -----Original Message----- >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Nobo Akiya >>>> (nobo) >>>> Sent: Thursday, July 31, 2014 4:16 PM >>>> To: Loa Andersson; Shah, Himanshu; Sami Boutros (sboutros); Mach=20 >>>> Chen >>>> Cc: rtg-dir@ietf.org; >>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; rtg-=20 >>>> ads@tools.ietf.org; mpls@ietf.org >>>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: >>>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt >>>> >>>> Hi Loa, Authors, >>>> >>>> The code base which I'm familiar with already have shipped=20 >>>> implementation of the TTL TLV, and it appears that the Type=3D0x8001=20 >>>> is >>> being used. >>>> >>>> I do not have the knowledge of why this value was used in this=20 >>>> implementation without doing early IANA allocation for the TTL TLV=20 >>>> code point. >>>> >>>> If usage of Type=3D0x8001 as the TTL TLV does not conflict with any=20 >>>> other implementations out there, is it possible to ask IANA to=20 >>>> assign this value >>>> (0x8001) when the document progresses? >>>> >>>> My apologies for causing extra burden on the authors, the Shepherd=20 >>>> and the ADs. >>>> >>>> But I truly hope that this request can be accommodated. >>>> >>>> Thanks! >>>> >>>> -Nobo >>>> >>>>> -----Original Message----- >>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa=20 >>>>> Andersson >>>>> Sent: Thursday, July 31, 2014 8:08 AM >>>>> To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen >>>>> Cc: rtg-dir@ietf.org; >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >>>>> mpls@ietf.org; rtg-ads@tools.ietf.org >>>>> Subject: Re: [mpls] [RTG-DIR] RtgDir review: >>>>> draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt >>>>> >>>>> Himanshu, >>>>> >>>>> A request for early allocation need to come from the authors, to=20 >>>>> wg-chairs and ADs. >>>>> >>>>> The draft is through IETF Last call and has been updated, given=20 >>>>> that ADrian is comfortable it will be on the IESG agenda shortly. >>>>> >>>>> IANA has reviewed it and are OK. >>>>> >>>>> Normally I would not ask for early allocation this late in the=20 >>>>> process. >>>>> >>>>> /Loa >>>>> >>>>> On 2014-07-31 01:15, Shah, Himanshu wrote: >>>>>> This draft fills a major shortcoming of the VCCV ping over MS-PW >>>>> (especially if reply mode is in-band). >>>>>> I am not sure why this draft is stuck (i.e. taking too long to go=20 >>>>>> through). >>>>>> >>>>>> Is there a provisional IANA assignment for the TTL TLV type value? >>>>>> >>>>>> Thanks, >>>>>> himanshu >>>>>> >>>>>> -----Original Message----- >>>>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami=20 >>>>>> Boutros >>>>>> (sboutros) >>>>>> Sent: Wednesday, July 30, 2014 3:44 PM >>>>>> To: Mach Chen >>>>>> Cc: rtg-dir@ietf.org; mpls@ietf.org;=20 >>>>>> draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org; >>>>>> rtg-ads@tools.ietf.org >>>>>> Subject: Re: [mpls] RtgDir review: >>>>>> draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >>>>>> >>>>>> Resending.. >>>>>> >>>>>> On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >>>>>> >>>>>>>> >>>>>>>> Minor Issues: >>>>>>>> >>>>>>>> 1. Since the TTL TLV is defined for both MS-PW and=20 >>>>>>>> bidirectional co-routed LSP, it should be better to explicitly=20 >>>>>>>> state this in the abstract >>>>> section. >>>>>>>> >>>>>>> >>>>>>> Sami: Sure will do. >>>>>>> >>>>>>>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo=20 >>>>>>>> request", "echo request" and "request" are interchangeably used=20 >>>>>>>> in the draft, it's better to unify the usage of it to "MPLS=20 >>>>>>>> echo request" (to align with the usage in RFC4379). For "echo=20 >>>>>>>> reply", "bidirectional co-routed LSP", they have the similar issue= . >>>>>>>> >>>>>>> >>>>>>> Sami: Ok, will fix that. >>>>>>> >>>>>>>> 3.Section 3.1 >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>>> + >>>>>>>> | Value | Reserved | >>>>>>>> Flags | >>>>>>>> >>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>> For the TTL TLV, the value filed should include the "value",=20 >>>>>>>> "Reserved" and "Flags", so it's better to change the "Value" >>>>>>>> field to "TTL" field hence to reduce the confusion. >>>>>>>> >>>>>>> >>>>>>> Sami: Sure. >>>>>>> >>>>>>>> 4. Section 3.2 >>>>>>>> "This TLV shall be included in the echo request by the=20 >>>>>>>> originator of request. The use of this TLV is optional. If a=20 >>>>>>>> receiver does not understand the TTL TLV, it will simply ignore=20 >>>>>>>> the TLV (Type value of TLV is assumed to be in the range of=20 >>>>>>>> optional TLV's which SHOULD be ignored if an implementation=20 >>>>>>>> does not support or >>>> understand them). >>>>>>>> In the absence of TTL TLV or if TTL TLV is ignored by a=20 >>>>>>>> receiver, the determination of the TTL value used in the MPLS=20 >>>>>>>> label on the echo reply is beyond the scope of this document." >>>>>>>> >>>>>>>> What's your mean of "beyond the scope of this document" here?=20 >>>>>>>> Is it to apply the procedures defined in RFC4379 or just let it=20 >>>>>>>> to the implementation?I guess you assume to apply the=20 >>>>>>>> definition in RFC4379, >>>>>>> >>>>>>> Sami: It is out of scope of this document, but for sure=20 >>>>>>> procedure in 4379 >>>>> apply. >>>>>>>> if >>>>>>> >>>>>>>> so, the TTL of the MPLS label will be more probably set to 255,=20 >>>>>>>> means the echo reply will be sent to the ingress of the MS-PW=20 >>>>>>>> or LSP. I am not sure whether this is the right procedure, it=20 >>>>>>>> seems a security issue. IMHO, it does not make any sense to=20 >>>>>>>> expect the receiver to send echo reply in this situation, and=20 >>>>>>>> even sent, the initiator will not receive the reply. The safer=20 >>>>>>>> way is to drop the whole >>>>> echo request and record an error log. >>>>>>> >>>>>>> >>>>>>> Sami: >>>>>>> >>>>>>> We are not saying the receiver must send a reply, however if he=20 >>>>>>> does the reply may be received by the ingress node which might=20 >>>>>>> be the wrong node, since the receiver may not set the TTL=20 >>>>>>> properly on the reply, keep in mind that this is a receiver with=20 >>>>>>> an old implementation and >>>>> the TLV is optional. >>>>>>> >>>>>>> Please refer to the security section for your security concern. >>>>>>> >>>>>>> Sami: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 5. Section 3.2 >>>>>>>> >>>>>>>> "In other words, if the value of the TTL provided by this TLV=20 >>>>>>>> does not match the TTL determined by other means, such as=20 >>>>>>>> Switching Point TLV in MS-PW, then TTL TLV must be used." >>>>>>>> Here, it implies that the receiver has to perform TTL matching=20 >>>>>>>> process, since how to set the TTL is independent of such=20 >>>>>>>> matching, seems this sentence is redundant and confusion. >>>>>>>> >>>>>>> >>>>>>> Sami: Are you familiar with the switching point TLV? and what it >>>>> includes? >>>>>>> >>>>>>>> 6. Section 4. >>>>>>>> >>>>>>>> "...The value field of the TTL TLV and the TTL field of the=20 >>>>>>>> MPLS label are set to 2," >>>>>>>> >>>>>>>> I guess that the MPLS Label is the PW label, right? It's better=20 >>>>>>>> to add more text to make this more explicit. In addition, how=20 >>>>>>>> to set the TTL value of the tunnel Label? 255 or any other value? >>>>>>>> >>>>>>> >>>>>>> Sami: The tunnel label TTL is irrelevant here, however we will=20 >>>>>>> make it >>>>> explicit that this is a PW label. >>>>>>> >>>>>>>> 5. Section 4.1. Traceroute mode >>>>>>>> "In the traceroute mode TTL value in the TLV is successively=20 >>>>>>>> set to 1, 2, and so on. This is similar to the TTL values used=20 >>>>>>>> for the label set on the packet." >>>>>>>> IMHO, some text may be needed to clarify which "FEC" should be=20 >>>>>>>> carried, especially for MS-PW trace. Since in Section 4.0, the=20 >>>>>>>> example says the FEC of segment C-D should be carried, does it=20 >>>>>>>> mean the FEC of last PW Segment of the segment under test=20 >>>>>>>> should be carried or the FEC will vary when TTL changed. For=20 >>>>>>>> example, when perform segment trace (e.g., to trace B-D=20 >>>>>>>> segment), when TTL is 1, which >>>>> FEC should be carried? >>>>>>> >>>>>>> Sami: >>>>>>> We are not here redefining a trace route for a MS-PW, we are=20 >>>>>>> describing >>>>> how our extensions will apply. >>>>>>> Sami: >>>>>>> >>>>>>>> >>>>>>>> 6. Section 4.2. Error scenario >>>>>>>> For this scenario, do you need to define some error codes here? >>>>>>> >>>>>>> Sami: >>>>>>> The section describe how to handle the error scenario, there is=20 >>>>>>> no need >>>>> for an error code. >>>>>>> Sami: >>>>>>> >>>>>>>> >>>>>>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe=20 >>>>>>>> mode, if so, it should be explicitly stated. If not, you should=20 >>>>>>>> define how the MS-PW trace works (given that the tunnels in=20 >>>>>>>> both directions may span different hops). >>>>>>> >>>>>>> Sami: >>>>>>> Not sure I get the concern? Again we are not re-defining how=20 >>>>>>> MS-PW >>>>> trace work. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Sami >>>>>>>> >>>>>>>> Nits: >>>>>>>> >>>>>>>> 1. Please check the text for acronyms that have not been=20 >>>>>>>> expanded in their first use. >>>>>>>> >>>>>>>> 2. I run the idnits tool and found the following nits, please=20 >>>>>>>> check and fix. >>>>>>>> (See RFCs 3967 and 4897 for information about using=20 >>>>>>>> normative references >>>>>>>> to lower-maturity documents in RFCs) >>>>>>>> >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC2119' on=20 >>>>>>>> line >>>>>>>> 121 >>>>>>>> >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC4379' on=20 >>>>>>>> line >>>>>>>> 258 >>>>>>>> >>>>>>>> =3D=3D Unused Reference: '1' is defined on line 284, but no=20 >>>>>>>> explicit reference >>>>>>>> was found in the text >>>>>>>> >>>>>>>> =3D=3D Unused Reference: '2' is defined on line 287, but no=20 >>>>>>>> explicit reference >>>>>>>> was found in the text >>>>>>>> >>>>>>>> =3D=3D Unused Reference: '3' is defined on line 291, but no=20 >>>>>>>> explicit reference >>>>>>>> was found in the text >>>>>>>> >>>>>>>> 3. Section 3.2, >>>>>>>> 3.1 first para first sentence >>>>>>>> s/shall/SHALL >>>>>>>> 3.2 last para, the last second sentence s/must/MUST >>>>>>>> >>>>>>>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP=20 >>>>>>>> concept, it's better to add related references to this document. >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Mach >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jul 31 10:24:18 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073481B295D; Thu, 31 Jul 2014 10:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJRaMOUIIkID; Thu, 31 Jul 2014 10:24:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A251A0310; Thu, 31 Jul 2014 10:24:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6VHNpdE005119; Thu, 31 Jul 2014 18:23:51 +0100 Received: from 950129200 (b18ef902.virtua.com.br [177.142.249.2] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6VHNN6j004799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 18:23:43 +0100 From: "Adrian Farrel" To: "'Shah, Himanshu'" , "'Sami Boutros \(sboutros\)'" , "'Mach Chen'" References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> Date: Thu, 31 Jul 2014 18:23:27 +0100 Message-ID: <001201cface4$33eaf1b0$9bc0d510$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHr8B29JN6lHzMtl3Z16fKN/FuooQKiAWJDAb034jICW3sei5tLyQkg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20852.001 X-TM-AS-Result: No--33.666-10.0-31-10 X-imss-scan-details: No--33.666-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtEwJ6xbTjBa5o1nuRzhSr7jwx0jRRxcQfMn+p552csI1R9I nwZVKlPIRIpasgDKarJNrgJ/QPoCneG5o3Ih4/5zVo6mn+xXmdWe8Eev9oWcztm9lptMNsMLklw j+zYtbPWKhXV7aRCSUgQ/URiXaEPlJnLCYm9iI2nhuXUWQoMQt7d2noO4P7rALraGNlLRahit/2 uGCywATsAfb65gvbMMONMIq6tJjPVmHCESzdHlJe7KTDtx8CggfkuZtv/FS5owyfWtyopBqDC0p JIQUiJOo7QSSB5Xe13AgeaK+M0v4h0QUKM89Lf/mlaAItiONP0UkWvaqUqLH5p5yGjWmTixV96Q sW8/xRVQgRhQ8LfXjLTeYox5gQ2wwuTfHDVJ/14SuhBXNJb1dLRfRjDbtW6i+Cckfm+bb6APnFh 6w8GlzLy6ePjAiEEvbktwtgMv6fX0DbEEQawseJmug812qIbzUb94TvZPQ0Lqi5hQjKcH1JivGt cLct3u1di5kB0M8FZjEoGkSWwOcbyTOSF4+k+YUIhTTahb7dWimsR6hkcJAjdnd59Af7CPmYipE y3261sqHM6hQwNnrNu7Y1z8Bd7mULNUje/+PyCeEco05hssvsPfVjo91KYI0mAM2eipqlrRIkCL Rkbt6qYuny6fS1JXJsAUhrRx+DUTSpw9+3gvPw6uUGRBr2oW16H/l0XwR9vJYIv7y0tu9lmkhn7 TN/aLarOX7+hRHjc+ZLNSw8H/z3rSP9RtGZYoU+OjsPhIWDgfOdo4H355iAUwUtcn3I+UsL+3Kv +qd5QdzlFITageAKtDr6Utp+bsYWo9dIuk10CeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/rQN3e7RUNlLXkwzCe1hAuEO6n4I Cc: rtg-dir@ietf.org, draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org, rtg-ads@tools.ietf.org, mpls@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 17:24:13 -0000 OK, I'm moving this forward now that we have a new revision (posted yesterday, and a response from Mach today), Please note that none of this is magic! To advance a document that is in review you have to complete the discussion of review comments and post a revision. The authors and shepherd are responsible for chasing down those comments: you can come to the AD to handle issues of silence, but the AD cannot micro-manage all of the documents and it doesn't help to ask why this has taken so long when no update was posted. Adrian > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: 31 July 2014 00:15 > To: Sami Boutros (sboutros); Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-lsp-ping-ttl- > tlv.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > This draft fills a major shortcoming of the VCCV ping over MS-PW (especially if > reply mode is in-band). > I am not sure why this draft is stuck (i.e. taking too long to go through). > > Is there a provisional IANA assignment for the TTL TLV type value? > > Thanks, > himanshu > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros > (sboutros) > Sent: Wednesday, July 30, 2014 3:44 PM > To: Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-lsp-ping-ttl- > tlv.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt > > Resending.. > > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: > > >> > >> Minor Issues: > >> > >> 1. Since the TTL TLV is defined for both MS-PW and bidirectional > >> co-routed LSP, it should be better to explicitly state this in the abstract section. > >> > > > > Sami: Sure will do. > > > >> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", > >> "echo request" and "request" are interchangeably used in the draft, > >> it's better to unify the usage of it to "MPLS echo request" (to align > >> with the usage in RFC4379). For "echo reply", "bidirectional > >> co-routed LSP", they have the similar issue. > >> > > > > Sami: Ok, will fix that. > > > >> 3.Section 3.1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Value | Reserved | Flags | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> For the TTL TLV, the value filed should include the "value", > >> "Reserved" and "Flags", so it's better to change the "Value" field to > >> "TTL" field hence to reduce the confusion. > >> > > > > Sami: Sure. > > > >> 4. Section 3.2 > >> "This TLV shall be included in the echo request by the originator of > >> request. The use of this TLV is optional. If a receiver does not > >> understand the TTL TLV, it will simply ignore the TLV (Type value of > >> TLV is assumed to be in the range of optional TLV's which SHOULD be > >> ignored if an implementation does not support or understand them). In > >> the absence of TTL TLV or if TTL TLV is ignored by a receiver, the > >> determination of the TTL value used in the MPLS label on the echo > >> reply is beyond the scope of this document." > >> > >> What's your mean of "beyond the scope of this document" here? Is it > >> to apply the procedures defined in RFC4379 or just let it to the > >> implementation?I guess you assume to apply the definition in RFC4379, > > > > Sami: It is out of scope of this document, but for sure procedure in 4379 apply. > >> if > > > >> so, the TTL of the MPLS label will be more probably set to 255, means > >> the echo reply will be sent to the ingress of the MS-PW or LSP. I am > >> not sure whether this is the right procedure, it seems a security > >> issue. IMHO, it does not make any sense to expect the receiver to > >> send echo reply in this situation, and even sent, the initiator will > >> not receive the reply. The safer way is to drop the whole echo request and > record an error log. > > > > > > Sami: > > > > We are not saying the receiver must send a reply, however if he does > > the reply may be received by the ingress node which might be the wrong > > node, since the receiver may not set the TTL properly on the reply, > > keep in mind that this is a receiver with an old implementation and the TLV is > optional. > > > > Please refer to the security section for your security concern. > > > > Sami: > > > > > >> > >> 5. Section 3.2 > >> > >> "In other words, if the value of the TTL provided by this TLV does > >> not match the TTL determined by other means, such as Switching Point > >> TLV in MS-PW, then TTL TLV must be used." > >> Here, it implies that the receiver has to perform TTL matching > >> process, since how to set the TTL is independent of such matching, > >> seems this sentence is redundant and confusion. > >> > > > > Sami: Are you familiar with the switching point TLV? and what it includes? > > > >> 6. Section 4. > >> > >> "...The value field of the TTL TLV and the TTL field of the MPLS > >> label are set to 2," > >> > >> I guess that the MPLS Label is the PW label, right? It's better to > >> add more text to make this more explicit. In addition, how to set the > >> TTL value of the tunnel Label? 255 or any other value? > >> > > > > Sami: The tunnel label TTL is irrelevant here, however we will make it explicit > that this is a PW label. > > > >> 5. Section 4.1. Traceroute mode > >> "In the traceroute mode TTL value in the TLV is successively set to > >> 1, 2, and so on. This is similar to the TTL values used for the > >> label set on the packet." > >> IMHO, some text may be needed to clarify which "FEC" should be > >> carried, especially for MS-PW trace. Since in Section 4.0, the > >> example says the FEC of segment C-D should be carried, does it mean > >> the FEC of last PW Segment of the segment under test should be > >> carried or the FEC will vary when TTL changed. For example, when > >> perform segment trace (e.g., to trace B-D segment), when TTL is 1, which FEC > should be carried? > > > > Sami: > > We are not here redefining a trace route for a MS-PW, we are describing how > our extensions will apply. > > Sami: > > > >> > >> 6. Section 4.2. Error scenario > >> For this scenario, do you need to define some error codes here? > > > > Sami: > > The section describe how to handle the error scenario, there is no need for an > error code. > > Sami: > > > >> > >> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if > >> so, it should be explicitly stated. If not, you should define how the > >> MS-PW trace works (given that the tunnels in both directions may span > >> different hops). > > > > Sami: > > Not sure I get the concern? Again we are not re-defining how MS-PW trace > work. > > > > Thanks, > > > > Sami > >> > >> Nits: > >> > >> 1. Please check the text for acronyms that have not been expanded in > >> their first use. > >> > >> 2. I run the idnits tool and found the following nits, please check > >> and fix. > >> (See RFCs 3967 and 4897 for information about using normative > >> references > >> to lower-maturity documents in RFCs) > >> > >> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 > >> > >> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 > >> > >> == Unused Reference: '1' is defined on line 284, but no explicit > >> reference > >> was found in the text > >> > >> == Unused Reference: '2' is defined on line 287, but no explicit > >> reference > >> was found in the text > >> > >> == Unused Reference: '3' is defined on line 291, but no explicit > >> reference > >> was found in the text > >> > >> 3. Section 3.2, > >> 3.1 first para first sentence > >> s/shall/SHALL > >> 3.2 last para, the last second sentence s/must/MUST > >> > >> 4. The draft quotes the MS-PW and bidirectional co-routed LSP > >> concept, it's better to add related references to this document. > >> > >> > >> Best regards, > >> Mach > >> > >> > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls