Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCA1200DB for ; Tue, 24 Sep 2019 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fcAHNZ/4; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=vdhfbuNo 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 S4LsJ2rDIjfN for ; Tue, 24 Sep 2019 14:14:53 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F438120071 for ; Tue, 24 Sep 2019 14:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20919; q=dns/txt; s=iport; t=1569359693; x=1570569293; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=glpQ0WR5s7xqGkM1kQ/xAtU4k2OFXb5mP450xGdj8PM=; b=fcAHNZ/4gVRweoR1R4qve/q1NerEXEhgrM4GU68/7A9K8l1mFYDxmXON nUu6+hwG/AGhbsevg55gTTxsG27YkxGK4/abmIRKk4gX+JuZg73X2xgHj 5X+noeRLQbitg2TB5KAe74q89ISuhtBMuPegiScGGDrM16tdsSLXJj6vz k=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3A0kSBqhQs72BhxdVxPDYc80zSetpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkG8VefFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADyhYpd/49dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBUwQBAQEBAQsBgRsvUANtViAECyoKhBiDRwOEUoYmgly?= =?us-ascii?q?HRIIjiTCEXYEugSQDVAIHAQEBCQMBASUIAgEBhD8CgyEjNAkOAgMJAQEEAQE?= =?us-ascii?q?BAgEFBG2FLQyFSgEBAQQSEQoTAQE1AgEPAgEIDgMEAQEoAwICAh8RFAkIAgQ?= =?us-ascii?q?BDQUIBhSDAYEdTQMdAQIMoyMCgTiIYXOBMoJ9AQEFgQcBLwKDWQ0LghAHAwa?= =?us-ascii?q?BNAGBUIo5GIFAP4ERRoJMPoFURkcBAQOBSBgrCYJVMoImjHEzgjaGLJYcLUE?= =?us-ascii?q?KgiKDQYIugRaKBIQcgjaHS41IgVyOGogTggiLIYNZAgQCBAUCDgEBBYFSOIF?= =?us-ascii?q?YcBWDJ1AQFIFOg3KFFIUIATZzgSmJJgeBKgGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,545,1559520000"; d="p7s'?scan'208,217";a="331989723" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2019 21:14:52 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8OLEqxU021690 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Sep 2019 21:14:52 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 16:14:51 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 16:14:50 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Sep 2019 16:14:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mSFSb7AzbVu/W9EwpZZnSpR+3RXSf5JO0xLaT8Gnpqgn0cJouKZGC13kMnuicrJfeHo42gB/+YwfO2+AFMAILaQ7XMGnPtu9KSzFESKED/OQ1DomZswp8+AuffFQmupB+zNdiBOS6DadZL6tYxNFaKVeGFYIl2m9R9mguXJS+5kScOzmI4WKnnbKPivALwoO0fmuOjyvI2WkkaN1+qJTRNOPpjggCQF+mjGPA1i1HcA650DyQDXltM4e2MYQuoDQ/QlY8593cacZlYiDU+Qao3P7w9CTCF8u2+QllnE3Dva1UrlurVZr0KCxnC4752r/xd8aQ/m4vs+ZLsX3mwAzPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BvU/z1PAPev04WpaYvtFhFZ0hoRvi+OghZkay5S5ulo=; b=mjkBBEbiylCFQimg+ZmeKPSLXG8jA8wxYXvI4xGesFlGM4KGxmx6FEbAJtnjx5IONw3KjnPAjmVpWZkX7mEmZd1qfHPkokA2TbsbBs7UHb9o/MvnS/MEYM9W9xftWc6hmj01bV0atkaDqs5jfI+NGVvAEKyZ+JatyRlQAKlDgx4ZRJhzz3yurMHOdQJW0dQT+DcqueAVPEDQRy2RVLwuht/1Y8ZSHqLO9Hanw6r/CGg7Q8yRzIoi0gcCdFhDbhTGvySdntFL4Rm4+Vjap7xLImSk1j12pBCfGNIPw0UkZ142TH50KYXQ1JlUItq4Dkdk6PAMLdTCkqqEoI/t+Tz2Iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BvU/z1PAPev04WpaYvtFhFZ0hoRvi+OghZkay5S5ulo=; b=vdhfbuNo7SLzyY6hi23B0kgEKzMASAVntWgiU3rVCmKCH4Luz0Rjr2/wJTX2/r81KcETI1wgSlWrz0TvqGiUa+78Y24apsUVa416ABX4a3c1ahPghpF/PuyreWuzcS35tUjSMrPQ316UnmNQbJoe/RjvvTAsf3VQudke7IYcb0U= Received: from BN7PR11MB2627.namprd11.prod.outlook.com (52.135.255.31) by BN7PR11MB2770.namprd11.prod.outlook.com (52.135.246.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.18; Tue, 24 Sep 2019 21:14:49 +0000 Received: from BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095]) by BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095%3]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 21:14:49 +0000 From: "Eric Voit (evoit)" To: Mahesh Jethanandani , "Balazs Lengyel (balazs.lengyel@ericsson.com)" , Alexander Clemm , "Benoit Claise (bclaise)" CC: Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVcwCXe43vmPblgUW74U2qSpt2bac7U+ng Date: Tue, 24 Sep 2019 21:14:49 +0000 Message-ID: References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> In-Reply-To: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98d21785-eaed-4ce2-7698-08d741343bb7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BN7PR11MB2770; x-ms-traffictypediagnostic: BN7PR11MB2770: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(189003)(199004)(4326008)(790700001)(6116002)(3846002)(7736002)(66616009)(2906002)(66556008)(76116006)(66476007)(74316002)(478600001)(66066001)(256004)(99286004)(52536014)(7696005)(14454004)(14444005)(5660300002)(446003)(26005)(486006)(476003)(11346002)(102836004)(6506007)(76176011)(186003)(53546011)(25786009)(15650500001)(99936001)(71190400001)(71200400001)(66946007)(2420400007)(81166006)(64756008)(8676002)(81156014)(8936002)(33656002)(6436002)(236005)(86362001)(9686003)(229853002)(55016002)(606006)(6306002)(54896002)(7110500001)(6246003)(110136005)(66446008)(316002)(6636002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2770; H:BN7PR11MB2627.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aBeZikhAQzbZ+uDl/I1EmIGDKBGUYFddUFOv3AEDnPipJ2uwT3zH5r88+tg646G2wlMVTNjZvftGxLMS5sYO8wMwMapCmoLyTQ0KRjjcdzcOiUjfVttbKsGykB6zyzR3flPntmQL6vrpJT28gS4Yo1X1Mr+s/3c5Zvc30jdiMEET31L1GfWHm7ZwkL/fvxQqsYJ+1Ycl9ql36C4LgSX6vlYDJ0XzYvB6Qi1NXxJKDsZqi9iLiPk75ZUtiIkPP4VPdnhtLSiSsUfnzx16ogmU2gtx1+KUznONUuWOvcSHZIXVw97jFNV5RQ4QjRuH6AysTbWTeJQrPftgJYat122nN+IQcrLN5hg4lhIL46qxZmqBxti+FDAuRxeZ498//WdMKighM6H+vJE1JyezjpBSFYCYEregeVql1zMz4jvBB6g= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E3_01D572FB.8FB15920" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 98d21785-eaed-4ce2-7698-08d741343bb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 21:14:49.0379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uT/5rFGB3+q8Ynjs6sr9MPBRTVEE8k+ungTvpcNdgXTijrDSZ1CoT1lEOggXnDRA X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2770 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 21:14:57 -0000 ------=_NextPart_000_01E3_01D572FB.8FB15920 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01E4_01D572FB.8FB15920" ------=_NextPart_001_01E4_01D572FB.8FB15920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Here are some comments... Section 1: Terminology YANG-Push is the RFC-8641 term rather than Yang-Push. Both variants are used in this document On-change Notification Capability: Is this different from support for RFC-8641 feature "on-change"? If they are the same, it might be possible to remove the term. Especially as this term is used inconsistently. Implementation-time information is used twice in the document, but without the dash Run-time information is used once. And the definition refers to the availability of information over network management protocols. Is it worth differentiating the term via a linkage to run-time state objects? Section 2 Paragraph 4: instead of " meaningless (e.g., a temperature gauge changing 0.1 degrees)", how about "irrelevant to the receiver (e.g., a temperature gauge change of 0.1 degrees within a predetermined and acceptable range)"? Paragraph 6: instead of "not available early in some document" how about " not documented in a way available to the NMS designer". Also // from, is/ from is Bullet #1 under Run time information: not sure what is meant by "it does not care which data nodes send notification, it will just handle what is available.". Should reword. Bullet #3: might want to reword: " implementation time capability information about the capabilities" Section 3 Paragraph 2, bullet 2: Instead of "amount of notifications the server can send out", do you mean "the minimum periodicity of updates which a server can send out for an object" Paragraph 2, bullets 3 & 4: I don't think these should be indented as bullets are they are more about proper behavior of a correctly populated model. Paragraph 3, bullets 2: why isn't SHALL instead MUST? Also, shouldn't this point out that both NETCONF and RESTCONF MUST be supported if on-change is advertised, and this draft is supported? YANG Model I am not sure why "server" is preferable to "publisher". The initial YANG-Push draft moved to "Publisher" because it is possible for the client-server roles to be reversed for some transport protocols. For example, the recent HTTP notif draft might have the receiver fill the HTTP server role. I believe it cleaner to revert to the "publisher" terminology. I do like the tiered structure of specific and generic values. There are lots of good parallels to other YANG work. Section 4 I suspect that you will need to do a security analysis per YANG object. This has been done the other YANG push family. I suspect that manipulating the reporting intervals could have some security implications. E.g., a hacker could push up the damping period or periodic interval to a level where the information they are changing then becomes invisible to a monitoring system. Thanks, Eric From: netconf On Behalf Of Mahesh Jethanandani Sent: Tuesday, September 24, 2019 1:50 PM To: Netconf Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities We were supposed to have closed on the WGLC today. However, between the document becoming a WG item and it going into LC, we have not received too many comments on the draft. As such, we are extending the LC by another week. Please review the draft and provide any comments you might have. Mahesh & Kent (as co-chairs) On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani > wrote: Authors have published -04 version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC. This therefore starts a two week LC, ending on September 24th. Please provide any technical comments you might have on the document. If you believe the document is not ready for LC, please state your reasons. We will issue a IPR poll separately. Mahesh & Kent (as co-chairs) ------=_NextPart_001_01E4_01D572FB.8FB15920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Here are = some comments...

 

Section 1: Terminology

 

YANG-Push is the RFC-8641 term rather than = Yang-Push.=C2=A0=C2=A0 Both variants are used in this = document

 

On-change Notification Capability: Is this = different from support for RFC-8641 feature "on-change"?=C2=A0 = If they are the same, it might be possible to remove the term.=C2=A0 = Especially as this term is used inconsistently.

 

Implementation-time information is used twice in = the document, but without the dash

 

Run-time information is used once.=C2=A0 And the = definition refers to the availability of information over network = management protocols.=C2=A0 Is it worth differentiating the term via a = linkage to run-time state objects?

 

 

 

Section 2

 

Paragraph 4: instead of " meaningless (e.g., a = temperature gauge changing 0.1 degrees)", how about = "irrelevant to the receiver (e.g., a temperature gauge change of = 0.1 degrees within a predetermined and acceptable = range)"?

 

Paragraph 6:=C2=A0 instead of "not available = early in some document"=C2=A0 how about " not documented in a = way available to the NMS designer".=C2=A0 Also // from, is/ from = is

 

Bullet #1 under Run time information: not sure what = is meant by "it does not care which data nodes send notification, = it will just handle what is available.".=C2=A0 Should = reword.

 

Bullet #3: might want to reword: " = implementation time capability information about the = capabilities"

 

 

 

Section 3

 

Paragraph 2, bullet 2: Instead of = =C2=A0"amount of notifications the server can send out", do = you mean "the minimum periodicity of updates which a server can = send out for an object"

 

Paragraph 2, bullets 3 & 4: I don't think these = should be indented as bullets are they are more about proper behavior of = a correctly populated model.

 

Paragraph 3, bullets 2: why isn't SHALL instead = MUST?=C2=A0=C2=A0 Also, shouldn't this point out that both NETCONF and = RESTCONF MUST be supported if on-change is advertised, and this draft is = supported?

 

 

 

YANG = Model

 

I am not sure why "server" is preferable = to "publisher".=C2=A0 The initial YANG-Push draft moved to = "Publisher" because it is possible for the client-server roles = to be reversed for some transport protocols.=C2=A0 For example, the = recent HTTP notif draft might have the receiver fill the HTTP server = role.=C2=A0=C2=A0 I believe it cleaner to revert to the = "publisher" terminology.

 

I do = like the tiered structure of specific and generic values.=C2=A0 There = are lots of good parallels to other YANG work.

 

 

Section 4

 

I = suspect that you will need to do a security analysis per YANG = object.=C2=A0=C2=A0 This has been done the other YANG push = family.

 

I suspect that manipulating the reporting intervals = could have some security implications.=C2=A0=C2=A0 E.g., a hacker could = push up the damping period or periodic interval to a level where the = information they are changing then becomes invisible to a monitoring = system.

 

Thanks,

Eric =

 

 

From: = netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh = Jethanandani
Sent: Tuesday, September 24, 2019 1:50 = PM
To: Netconf <netconf@ietf.org>
Subject: Re: = [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

We = were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have.

 

Mahesh & Kent (as co-chairs)

 



On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = <mjethanandani@gmail.com> = wrote:

 

Authors have published -04 version of the draft, which addresses comments = they received in IETF 105. If you provided comments please check to make = sure your comments have been addressed. At this point, the authors = believe that the document is ready for WGLC.

 

This therefore starts a two week LC, ending on = September 24th. Please provide any technical comments you might have on = the document. If you believe the document is not ready for LC, please = state your reasons.

 

We will issue a IPR poll = separately. 

 

Mahesh & Kent (as = co-chairs)

 

 

 

 

------=_NextPart_001_01E4_01D572FB.8FB15920-- ------=_NextPart_000_01E3_01D572FB.8FB15920 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTI0MjExNDQ1WjAjBgkqhkiG 9w0BCQQxFgQU+1DgPqxDm40rl/JGkBqRvuINZU4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBvoIZv5efJuCoLSFRfz2NiEiqoVQ4mrP/HHDSQQbA9WzMfUYdpD9zZH7id7vGCg8Z/ IVYy0rHqitjDVdh5WJMqdqgY2udPTBLXz78gzhSh+SP1znIThkxFnpc2UnbIVSatQpRGHj7fdrnD wiU/ytIDP/Vw1hZBeTEqmkv8ky2izoBGwrzm+miAqh1xDZWaDP5lIkrmyRbQ/z/jlFkPwqQgIiJp MbCQih/skPqLtv151gwPMMGls8Ge6QUW+KHt+TATuL/afoVRiE7kNLlPoL2+6uaNBb8pLYY69JJQ zutUk3lKCu4QewehAw8RbfUZq1aatWiAvLCTXx7cZy/Ltbw5AAAAAAAA ------=_NextPart_000_01E3_01D572FB.8FB15920--