From nobody Thu Apr 2 04:46:30 2020 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13F73A1079; Thu, 2 Apr 2020 04:46:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 S2iMR8uOqzdo; Thu, 2 Apr 2020 04:46:25 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2106.outbound.protection.outlook.com [40.107.21.106]) (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 56BC63A1080; Thu, 2 Apr 2020 04:46:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mPV4ScCew0jrCFlozs73vgbUuuhSjQdtd6zNAre4B0qod9PyddB7UEzlLqXDNrnr5296DdD4X14aicO+9VN7KtfI1VccWgypx3RwCsdzjAOmarU/fPMZ6BK8aJqlosJlqT0pCaruliBm+KEmFuJZL2epogZDGx33vO/wUukS+ludMgsx+eMzC2MPgyWc+A1F/w7/2qsNM6Z99NUm8F6u4eyLy3xDJJRQqBY1dz+syIEdqN8XtmlMQyMo7nXOkz6WfK2AQ6LG8H35TeIa2sSuFIGf0OOlsqguXv390vmK96qlJa3EIrXY24uxp0tk/mhKZifgoSTSEf0tsuvjTO2Gow== 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=LI21Hce0GHCAvD4mEsG1YEu4ezjI8OlOEqyxzIJ8lJc=; b=HzDX8LrM5fZJSRBQpbiqHp28xQsFjiPYKxuSmfpU89mnRATQSvvmIYC/6D8aKMny1JUknpcvmXYVZIa64khvtHYUlOAWqCAGfJwJUi3ebOwCe8nIX03c0voxR0AlON+qwUihEvS4/NNpGlcPVzClncfreHV+llZfSMvbMWQO6h6dwsQkuN+vCBjN9YPnVRQSU2bFYl5af5YCTL5ZCBFEkM84ORnzotMQwEsJU0y+GaJFM5KyLYvb4sGsFrQ9SATAWSQy+/DblHbnrp9z2OXnIEoWyHlckJMyEKqmVoE0NBnCMLzSKxFFvVYy5pBt8XUx9aOJNoceCcZzZA3qLO3ZTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LI21Hce0GHCAvD4mEsG1YEu4ezjI8OlOEqyxzIJ8lJc=; b=m7ivk2BZyykWUu5Z797J7tKpP0juS4ksStUCFbtpMZqgKsfS4HoBZZvctGHLnTRRv7bfW61lJlgUY2KnUcHRntz0Ox7+gyqa2EF5I9kVuivvSui/6HnoXcr8IFRX8jJxWq/cHDz2QjpwAQqCK9h+Bh3UR2qAbVqkaMt6DwdsqKQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from VI1PR07MB3502.eurprd07.prod.outlook.com (10.170.237.22) by VI1PR07MB4766.eurprd07.prod.outlook.com (20.177.53.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Thu, 2 Apr 2020 11:46:23 +0000 Received: from VI1PR07MB3502.eurprd07.prod.outlook.com ([fe80::50f:3508:da66:c7fc]) by VI1PR07MB3502.eurprd07.prod.outlook.com ([fe80::50f:3508:da66:c7fc%7]) with mapi id 15.20.2878.014; Thu, 2 Apr 2020 11:46:23 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable References: <157349122063.7571.1978842562243958252@ietfa.amsl.com> Date: Thu, 2 Apr 2020 12:27:48 +0100 Message-ID: <1UW7PG0cZk.1BtlYcJAH5b@pc8xp> In-Reply-To: From: "tom petch" To: "Mr. Jaehoon Paul Jeong" , "Jan Lindblad" Cc: "draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org" , "i2nsf@ietf.org" User-Agent: OEClassic/3.0 (WinXP.2600; F; 2019-11-28) X-ClientProxiedBy: LO2P123CA0068.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1::32) To VI1PR07MB3502.eurprd07.prod.outlook.com (2603:10a6:802:1a::22) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from pc8xp (81.131.229.19) by LO2P123CA0068.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Thu, 2 Apr 2020 11:46:21 +0000 X-Originating-IP: [81.131.229.19] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5379ce03-e941-4aa4-9f77-08d7d6fb76fb X-MS-TrafficTypeDiagnostic: VI1PR07MB4766: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0361212EA8 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB3502.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(376002)(136003)(346002)(396003)(366004)(39860400002)(26005)(8936002)(55016002)(6666004)(45080400002)(53546011)(186003)(54906003)(478600001)(110136005)(16799955002)(2906002)(316002)(956004)(9686003)(33716001)(966005)(9576002)(30864003)(5660300002)(16526019)(86362001)(6496006)(4326008)(81156014)(15188155005)(52116002)(66476007)(66556008)(66574012)(8676002)(52230400001)(81166006)(66946007); DIR:OUT; SFP:1102; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tlZybBn8AnQ/NjDRdDv00A3LrdDtnpwNzJ3Iamci82c5N33Nb5cB/wm61SvQmWoD3wq2ac/7eyFgzbW2elM2bj8EqBQP5z2T1ko5nEp6AzysaO8sxR6e72YGLjdsiFX4BHZHTReMJcc3EG7pG8zO3z1XftwAVMSOK/XqhEz9tGxB3qIEHtcD08soGV7ZvBZMM/BFT8uM8CxQmM1vKilTvsRvuquT+m0d6OyPShdD56b2m3G+IR8E63mCqHWxn1vR8nOpuHrWuIy/ABeh/zNWJd968v8o009I8ygZQGOtF5AYeC5zOQtkUA6BEQ61nnShW7rfjFyQQ274oYUEoeYDayGu3LX458HAIByxZCkMxfOTk6/xl/fu9MRvZDiD1gBG9YzhXLmqZD2JMsDcm7z/fMhdn4/pKBHMO8P31PxSyyD3Rz8K9i/ywlNz+cIRgtd8P0PNYWqsN8wVjygfnkE7lV2Ma9vocSinUoDK3sWkkX5g4dZeKj73dLNPOJVO5N218zrymZWS/FLY35WZWRB6hA== X-MS-Exchange-AntiSpam-MessageData: yWZLBmX6ibBvJW0PrO1iqFi2PqA08Z97VBSPlPLliHL4H7wURW3sq49WfirZjF8LPyDTvcBGbxrjBTLOqak0pB4lnmN+Mu4r+GNydDuZRd9yaRBrwUPwEaveggGz2ocye3uk3Bn50Tr1d5wRz+oAZA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5379ce03-e941-4aa4-9f77-08d7d6fb76fb X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 11:46:22.9015 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iH4D/NySmZlVYepaFk5R999NkV9fZQ3Iu4I2YwzhG2leuoOXESvUxhJW65BX44QfzAxksaTiW4P64cm2/VIlzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4766 Archived-At: Subject: Re: [I2nsf] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-07 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 11:46:29 -0000 --- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ Paul At a tangent to Jan's comprehensive review, you have plenty of YANG referen= ce clauses which is good, but the RFC you reference must then appear as Nor= mative References in the I-D. I see RFC 854 913 1081 1631 2579 2616 2818 3339 4250 5321 and draft-ietf-sdn-ipsec-... all of which need adding On a different tack, I think that the choice of prefix is unfortunate. =20 capability uses nsfcap registration uses nsfreg This should use nsf.... perhaps nsfcon or nsfcfi ... HTH Tom Petch ----- Original Message ----- From: Mr. Jaehoon Paul Jeong To: Jan Lindblad Cc: , , , YANG Doctors , skku-i= otlab-members , Mr. Jaehoon Paul Jeon= g Sent: 18/03/2020 17:41:41 Subject: Re: [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf= -i2nsf-consumer-facing-interface-dm-07 ___________________________________________________________________________= _____ Hi Jan, Could you update the state of YANGDOCTORS Last Call Review on I2NSF Consumer-Facing Interface YANG Data Model if the updates are fine to= you? https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface= -dm/ I think your comments are all addressed in this version. Thanks. Best Regards, Paul On Thu, Mar 12, 2020 at 1:15 AM Mr. Jaehoon Paul Jeong wrote: Hi Jan, We authors have addressed your comments with the revision: https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-0= 8 I attach a revision letter to explain how to respond to your comments. If you have further comments, please let me know. Thanks. Best Regards, Paul On Tue, Nov 12, 2019 at 1:53 AM Jan Lindblad via Datatracker wrote: Reviewer: Jan Lindblad Review result: Almost Ready This is my YD review of draft-ietf-i2nsf-consumer-facing-interface-dm-07. I have previously reviewed the -05 revision (~end June). I find the new revis= ion much improved, but still with much to discuss. I will call this "almost rea= dy". Generally speaking, I think the YANG module lacks the precision and descriptions needed to foster interoperability. The examples at the end are very enlightening however, and compensate for much of that, but their infor= mal nature can never replace proper YANG. The module usage needs to be mostly c= lear from the module itself. The management access control model proposed here is, even with its latest adaptation towards NACM, is still quite different from NACM author's origin= al ideas. I will therefore bring this use case up in the NETMOD WG for discuss= ion. 1. Network access control principles Network access control is about which users are able to use the network bei= ng managed, for example connect to facebook. The purpose of the NSF module is = to control this access. This version of the YANG module is now based on a list= of policies. Each policy has a list of rules. Each rule has an event -- condition -- act= ion triplet. This resembles traditional firewall management, which is a good th= ing, because that concept is stable and much tried. This allows operators to cre= ate lists of rules in this style: if pkt.x =3D=3D 1: drop // Rule 1 elif pkt.y > 2: alert // Rule 2 elif pkt.z =3D=3D 10: pass // Rule 3 else: drop // Rule 4 This pattern relies heavily on the ability to control the order of the rule= s. The current model relies on the alphabetical sorting of names rules for the ordering. The YANG trick I would recommend to give operators the ability to insert and move rules as they wish is to add ordered-by user on the list: list rule { ordered-by user; // <=3D=3D Add this line leaf rule-name { Nothing is said about what the system should do in case policies conflict. = What if one policy says pass, the other drop for the same packet? Please clarify= .. What should happen to packets that do not match any of the policies? This module also assumes that all users in the operator's organization are listed in one or more NACM groups (e.g. "employees"). That wasn't really th= e NACM authors' original intent. Even if this could be made to work maybe, th= ere is no strong reason to repurpose the NACM group concept for user network ac= cess purposes. It could easily be modeled differently. So in the cases where the= re are leafrefs to NACM groups when dealing with network access rather than management access, don't use NACM groups. leaf src-target { type leafref { path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name; = // <=3D=3D Point to some other list of network users 2. Management access control principles Management access control is about which users are able to configure/run actions/the policies and rules. IMO, the most controversial aspect of this module has always been its new and creative management access control model= .. In this revision, the management principles have been remodeled greatly to fit= in with NACM. I find this redesign very promising, but the result is still not quite ready for publication. The point where integration with NACM concepts is important is when it come= s to allow some users to CRUD the NSF policies and rules themselves. There is no= w a leaf-list "owners" on each policy and rule which point to a list of NACM groups. My understanding is that the idea is that the NSF module should be = seen as a service model that translate high level ownership information to speci= fic NACM rules. It would be good to mention these ideas somewhere in the NSF document. leaf-list owners { type leafref { path /nacm:nacm/nacm:groups/nacm:group/nacm:name; I expect the intent is that any user listed in a NACM group mentioned in th= e owners list would get full CRUD privileges for the contents of the rule the owners leaf sits on. That is never spelled out anywhere, however. It is a little less clear how leaf-list owners on policy objects should be handled. Should owners listed on a policy object get full CRUD powers over = the entire policy, including all the rules inside? Or would they need to be lis= ted on the rules as well? Not clear. Is the intent that users not listed on the policy object are unable to create new rules, but to be able to update rule= s they are listed as owners of, if any? Who is allowed to create new policy objects? Should users that are not owne= rs get read access to all the policies and rules? Finally, there is an "owner" leaf on each rule with an identityref allowing operators to configure a role name like dept-head or sec-admin. It is marke= d mandatory, but never included in any of the examples at the end of the document. This makes me think this may be a remnant from bygone times and should be removed from the YANG. If not, an explanation of how to use this leaf, and how it interacts with "owners" needs to be added, and the example= s updated. 3. leafrefs crosspointing between policy instances There are six leafrefs that point to various objects inside a policy, e.g. = a rule condition pointing to a device group name. None of them restrict what = can be pointed to so that only names within the current policy are valid. It is therefore possible to configure the name of a device group defined in a different policy. I suspect this is not the intention. In order to restrict= the leafrefs to the same policy, the following predicate can be added: leaf-list src-target { type leafref { path "/i2nsf-cfi-policy[policy-name=3Dcurrent()/../../../../..= /policy-name]/endpoint-group/device-group/name"; // <=3D=3D Add predicate 4. Mandatory to implement all events, conditions, actions Each rule is defined with a choice of different events (admin, time), conditions (firewall, ddos, custom, threat-feed) and actions (pass, drop, alert, mirror, ...). Is the intent that all of these options should be mandatory to implement? The current model requires this. Also, would it mak= e sense to allow additional mechanisms here? If so, it may be good to explain= to readers how the set of choices and identities can be extended by implementations. 5. Optional and mandatory elements In this revision of the module, 8 leafs have been marked mandatory. A few o= f them are list keys, which are conventionally not marked mandatory, since li= st keys are always mandatory. A few others are skipped in the XML examples at = the end of the NSF document, which makes me believe they might not really be mandatory after all. Three leafs have a default, but most leafs are left optional without any default. In many cases I think I understand what it means to not set a leaf= , but with the ones listed here, I don't think it clear at all. Either add a default to make it clear, make them mandatory if they should be, or explain= in the leaf description what happens if not set. 493: leaf-list name 513: leaf-list protocol 531: leaf geo-ip-ipv4 541: leaf continent 562: leaf feed-server-ipv4 585: leaf payload-description 590: leaf-list content 600: leaf-list owners 870: leaf method 6. Indentation The YANG indentation is mostly wrong. Run the YANG text through pyang or so= me other tool that can indent the content correctly before you put it into a document. 7. YANG element naming The YANG convention is to not have lists on the top level in the YANG modul= e, but to surround lists with a container. The surrounding container often has= a name in the plural and the list in singluar, like this container interfaces { list interface { To better fit into the world of IETF YANG modules, I'd recommend turning th= e top level list i2nsf-cfi-policy into this instead: container i2nsf-cfi-policies { list policy { Further down, I would change container rule to rules: container rules { list rule { Finally, it is customary to not repeat the names of parent object in the na= mes of elements. For example, in the following: list threat-feed-list leaf feed-name leaf feed-server-ipv4 leaf feed-server-ipv6 leaf feed-description all the leafs should normally not repeat "feed-". Just leaf name, leaf server-ipv4, leaf server-ipv6, leaf description. There are many more exampl= es of this throughout the module. The condition choice has many containers with a single leaf inside (e.g. ddos-source). Their purpose is rather unclear to me. Remove? container ddos-source { description "This represents the source."; leaf-list src-target { Also, I find the name "src-target" rather confusing. How about "source"? 8. No date leaf The draft text near fig 2 talks about a date leaf. There is no date object = in this revision of te YANG. "Date: Date when this object was created or last modified" 9. leaf owner Near fig.3 leaf Owner is mentioned. Is this leaf still current? "Owner: This field contains the onwer of the rule. For example, the person who created it, and eligible for modifying it." 10. leaf packet-per-second This is now modeled as uint16. Is this future proof? Many packet flows on t= he internet exceed 64k pps. 11. container custon-source Misspelled. Should be custom-source 12. identity ddos Is ddos a malware file-type? This is not exactly in line with my intuition. 13. identity protocol-type There are other modules that already define protocol-types. Would it be wor= th reusing one of them? 14. identity palo-alto Is it a good IETF practice to list vendor names in modules? Can we consider this a protocol name? Is there perhaps an RFC/specification name for it tha= t we could reference instead? 15. grouping ipsec-based-method This grouping contains a list which allows listing none of, either of or bo= th of ipsecike and ikeless. Are all valid configurations? 16. leaf feed-name This leaf is the key in a list, which makes it possible to have at most one feed of each type. If it would make sense to configure more than one feed o= f the same type, the YANG needs to be updated here. 17. leaf-list content This leaflist is of type string. What is the format of this string? Does th= e name refer to something? 18. Event types container event has a choice between enforce-admin and time alternatives. E= ach of those choices have a leaf that allows the operator to configure an identityref to an enforce-type value. What does that mean? What would it me= an if an operator configured admin =3D=3D 'time' (or enforce-time =3D=3D 'admi= n')? 19. leaf begin-time, end-time >From the examples, it can be seen that these are meant to be a time of day values. Currently they are modeled as yang:date-and-time, which means they = are a concrete time a specific day, e.g. 2019-11-11T16:07. This needs to be cha= nged in order to be what the modeler intended. Perhaps like this: typedef time-of-day { type string { pattern '(2[0-3]|[01]?[0-9]):[0-5][0-9]'; } } 20. leaf frequency This leaf is now modeled properly from a YANG perspective. But what does it mean? If this leaf is set to 'once-only', what exactly will happen only onc= e? Please write a description that explains this. 21. Example in Fig.17 The example contains XML that refers to "endpoint-group/user-group". There = is no such element in the YANG. Furthermore, there is nothing called range-ip-address, start-ip-address, end-ip-address. They are called range-ipv4-address, start-ipv4-address, end-ipv4-address. 221.159.112.1 221.159.112.90 Finally, there must not be any xmlns attribute on an closing XML tag. So should be This happens in several of the examples. 22. Example in Fig.18 There is no element called policy any more. It's now i2nsf-cfi-policy. security_policy_for_blocking_sns The rules are modeled in a container and list, both by the name rule. So th= ere needs to be two tags. block_access_to_sns_during_office_hours The security-event element is marked mandatory in the YANG, but missing in = the example. The times given below may be what is intended, but do not match th= e date format for the type used (which include a date, etc). 09:00 18:00 Since the example is not mentioning leaf frequency, it will have the value 'once-only'. Maybe explain what that means in the context of the example? The condition/firewall-condition says the src-target is mandatory and dest-target optional, exactly like below. condition/custom-destination/dest-target is mandatory and src-target is optional, exactly like below. Is this pure luck, or is there a logical explanation why exactly those should be mandatory, and the example use precisely those? employees sns-websites The current YANG model does not allow setting both a firewall-condition and custom-condition. If that should be allowed, the model needs to change. Sho= uld it be possible to have multiple firewall- or other conditions? That is not currently possible. This example leaves out the mandatory leaf owner. Is that a sign that it sh= ould not be mandatory, or perhaps not exist at all? 23. Example in Fig.19 This example lists a firewall-condition with no src-target, which is mandat= ory. employees Under condition, there is a container rate-limit with a leaf packet-per-sec= ond. Is this a trigger value for the condition, or is it an actual limit that th= e system is expected to enforce? If it's a trigger, it may be good to find a clearer name. If it's enforced, it's placement under condition is deceiving= . If a rule's action is set to 'rate-limit', to which rate will it be limited= ? 24. Security Considerations Section 10 in the NSF document under review is the Security Considerations.= I think it would make sense to mention something about the management access control mechanism here, and its relation to NACM. (End of list) _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php From nobody Thu Apr 2 21:18:51 2020 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31C63A0E13; Thu, 2 Apr 2020 21:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZYgMvhe05DDI; Thu, 2 Apr 2020 21:18:45 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134E63A0E0F; Thu, 2 Apr 2020 21:18:45 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id r17so1072926lff.2; Thu, 02 Apr 2020 21:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KZahubFqcxY+up2W4UO+Gxw2VZ5d9y2tV23CAMF4/8Y=; b=Wr7wDrZutaQl1ekH7uELRoQWH1pYPv++At1PUVigsjMpLZIYjopIBSAn9eqWfBYaGZ PLenXzh8A3DhndquBFL8CEiPgSK4lK9ZVb3L+7ssJ/glpridrRApUkvJ9yVzHFGh8I2I tGzCWX2qStdVJWED76JLYrUveBnTbwd89kxx7btMYISmukd1UV33I+4lPX0kRdoia5h3 gst+p+KLejYa8aTQbGOH+ZTWY1C+yvvmXeGyVXcZlzTs1M2I0pBk+dYwEcVmoDWW0WqA 6n99RU+TDedxWktcvmnRv3GuBUzEFgaGus1iggAM8cqlxFJ8Jep3FOUOSQp1psawA2Jl 8kEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KZahubFqcxY+up2W4UO+Gxw2VZ5d9y2tV23CAMF4/8Y=; b=NDOKb4LIk3D7jqlzgMx58VPe5A1znvOnkM4Prj3siCycskgcA3Jeb+KVS0gTiNqCa+ cS5E1t8CFRUwmxGvd/uaOvRtlWU5YBHq/VVQE7sQpO27UATFse1TbwzpBy19KhC9i/7c GSWWMw2/WSd+BntcQ60sxE21PcSm4gkL0uPimaIUlzXE1lGIn8F4uxLzVb1XyIozfGkR LxNctf3/XwNY+4seWDRSEdB0hVEYczHi/2VeniBj2s0ztI5iotK/HudNEiCXUq6BD6Hc 01YsZEVMt0UbPnC1I0eFJoqkBWOBs3Xk+2ohwfN61/SPp6y1EaaKH7RRyIAMabu5vDl4 Nzrg== X-Gm-Message-State: AGi0PuZnMS/BgH8+fK5nzDVaDMeX+B6bqcsgtOdGH0k5Qa71xYh2LegL 8csk1KPxxY1/ZvDJA5m7xhefkzGraXWF4DEgjM8Zyg== X-Google-Smtp-Source: APiQypI0ms1FjTfsE5dWtYGJlZPe7ZTIoVb4m4rtHtqJwzdFeBS3VZyXi50XPyYw7ZMFT7VeMUXamdpsp08TdQH2Ib4= X-Received: by 2002:a19:ee18:: with SMTP id g24mr4217554lfb.29.1585887523106; Thu, 02 Apr 2020 21:18:43 -0700 (PDT) MIME-Version: 1.0 References: <157349122063.7571.1978842562243958252@ietfa.amsl.com> <1UW7PG0cZk.1BtlYcJAH5b@pc8xp> In-Reply-To: <1UW7PG0cZk.1BtlYcJAH5b@pc8xp> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 3 Apr 2020 13:18:05 +0900 Message-ID: To: tom petch Cc: Jan Lindblad , "draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org" , "i2nsf@ietf.org" , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="00000000000077f3c705a25b369f" Archived-At: Subject: Re: [I2nsf] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-07 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 04:18:50 -0000 --00000000000077f3c705a25b369f Content-Type: text/plain; charset="UTF-8" Hi Tom, Thanks for your good suggestions. I will reflect your comments on the revision. Best Regards, Paul On Thu, Apr 2, 2020 at 8:46 PM tom petch wrote: > > --- > New Outlook Express and Windows Live Mail replacement - get it here: > https://www.oeclassic.com/ > > Paul > > At a tangent to Jan's comprehensive review, you have plenty of YANG > reference clauses which is good, but the RFC you reference must then appear > as Normative References in the I-D. > > I see RFC > 854 > 913 > 1081 > 1631 > 2579 > 2616 > 2818 > 3339 > 4250 > 5321 > and > draft-ietf-sdn-ipsec-... > all of which need adding > > On a different tack, I think that the choice of prefix is unfortunate. > capability uses nsfcap > registration uses nsfreg > This should use nsf.... perhaps nsfcon or nsfcfi ... > HTH > > Tom Petch > ----- Original Message ----- > From: Mr. Jaehoon Paul Jeong > To: Jan Lindblad > Cc: , < > i2nsf@ietf.org>, , YANG Doctors , > skku-iotlab-members , Mr. Jaehoon > Paul Jeong > Sent: 18/03/2020 17:41:41 > Subject: Re: [Last-Call] [I2nsf] Yangdoctors last call review of > draft-ietf-i2nsf-consumer-facing-interface-dm-07 > > ________________________________________________________________________________ > > > Hi Jan, > Could you update the state of YANGDOCTORS Last Call Review on > I2NSF Consumer-Facing Interface YANG Data Model if the updates are fine > to you? > > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/ > > I think your comments are all addressed in this version. > > Thanks. > > Best Regards, > Paul > > > > On Thu, Mar 12, 2020 at 1:15 AM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Jan, > We authors have addressed your comments with the revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-08 > > I attach a revision letter to explain how to respond to your comments. > > If you have further comments, please let me know. > > Thanks. > > Best Regards, > Paul > > > > On Tue, Nov 12, 2019 at 1:53 AM Jan Lindblad via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Jan Lindblad > Review result: Almost Ready > > This is my YD review of draft-ietf-i2nsf-consumer-facing-interface-dm-07. I > have previously reviewed the -05 revision (~end June). I find the new > revision > much improved, but still with much to discuss. I will call this "almost > ready". > > Generally speaking, I think the YANG module lacks the precision and > descriptions needed to foster interoperability. The examples at the end are > very enlightening however, and compensate for much of that, but their > informal > nature can never replace proper YANG. The module usage needs to be mostly > clear > from the module itself. > > The management access control model proposed here is, even with its latest > adaptation towards NACM, is still quite different from NACM author's > original > ideas. I will therefore bring this use case up in the NETMOD WG for > discussion. > > 1. Network access control principles > > Network access control is about which users are able to use the network > being > managed, for example connect to facebook. The purpose of the NSF module is > to > control this access. This version of the YANG module is now based on a > list of > policies. > > Each policy has a list of rules. Each rule has an event -- condition -- > action > triplet. This resembles traditional firewall management, which is a good > thing, > because that concept is stable and much tried. This allows operators to > create > lists of rules in this style: > > if pkt.x == 1: drop // Rule 1 > elif pkt.y > 2: alert // Rule 2 > elif pkt.z == 10: pass // Rule 3 > else: drop // Rule 4 > > This pattern relies heavily on the ability to control the order of the > rules. > The current model relies on the alphabetical sorting of names rules for the > ordering. The YANG trick I would recommend to give operators the ability to > insert and move rules as they wish is to add ordered-by user on the list: > > list rule { > ordered-by user; // <== Add this line > leaf rule-name { > > Nothing is said about what the system should do in case policies conflict. > What > if one policy says pass, the other drop for the same packet? Please > clarify.. > What should happen to packets that do not match any of the policies? > > This module also assumes that all users in the operator's organization are > listed in one or more NACM groups (e.g. "employees"). That wasn't really > the > NACM authors' original intent. Even if this could be made to work maybe, > there > is no strong reason to repurpose the NACM group concept for user network > access > purposes. It could easily be modeled differently. So in the cases where > there > are leafrefs to NACM groups when dealing with network access rather than > management access, don't use NACM groups. > > leaf src-target { > type leafref { > path > /nacm:nacm/nacm:groups/nacm:group/nacm:user-name; // > <== Point to some other list of network users > > 2. Management access control principles > > Management access control is about which users are able to configure/run > actions/the policies and rules. IMO, the most controversial aspect of this > module has always been its new and creative management access control > model.. In > this revision, the management principles have been remodeled greatly to > fit in > with NACM. I find this redesign very promising, but the result is still not > quite ready for publication. > > The point where integration with NACM concepts is important is when it > comes to > allow some users to CRUD the NSF policies and rules themselves. There is > now a > leaf-list "owners" on each policy and rule which point to a list of NACM > groups. My understanding is that the idea is that the NSF module should be > seen > as a service model that translate high level ownership information to > specific > NACM rules. It would be good to mention these ideas somewhere in the NSF > document. > > leaf-list owners { > type leafref { > path /nacm:nacm/nacm:groups/nacm:group/nacm:name; > > I expect the intent is that any user listed in a NACM group mentioned in > the > owners list would get full CRUD privileges for the contents of the rule the > owners leaf sits on. That is never spelled out anywhere, however. > > It is a little less clear how leaf-list owners on policy objects should be > handled. Should owners listed on a policy object get full CRUD powers over > the > entire policy, including all the rules inside? Or would they need to be > listed > on the rules as well? Not clear. Is the intent that users not listed on the > policy object are unable to create new rules, but to be able to update > rules > they are listed as owners of, if any? > > Who is allowed to create new policy objects? Should users that are not > owners > get read access to all the policies and rules? > > Finally, there is an "owner" leaf on each rule with an identityref allowing > operators to configure a role name like dept-head or sec-admin. It is > marked > mandatory, but never included in any of the examples at the end of the > document. This makes me think this may be a remnant from bygone times and > should be removed from the YANG. If not, an explanation of how to use this > leaf, and how it interacts with "owners" needs to be added, and the > examples > updated. > > 3. leafrefs crosspointing between policy instances > > There are six leafrefs that point to various objects inside a policy, e.g. > a > rule condition pointing to a device group name. None of them restrict what > can > be pointed to so that only names within the current policy are valid. It is > therefore possible to configure the name of a device group defined in a > different policy. I suspect this is not the intention. In order to > restrict the > leafrefs to the same policy, the following predicate can be added: > > leaf-list src-target { > type leafref { > path > > "/i2nsf-cfi-policy[policy-name=current()/../../../../../policy-name]/endpoint-group/device-group/name"; > // <== Add predicate > > 4. Mandatory to implement all events, conditions, actions > > Each rule is defined with a choice of different events (admin, time), > conditions (firewall, ddos, custom, threat-feed) and actions (pass, drop, > alert, mirror, ...). Is the intent that all of these options should be > mandatory to implement? The current model requires this. Also, would it > make > sense to allow additional mechanisms here? If so, it may be good to > explain to > readers how the set of choices and identities can be extended by > implementations. > > 5. Optional and mandatory elements > > In this revision of the module, 8 leafs have been marked mandatory. A few > of > them are list keys, which are conventionally not marked mandatory, since > list > keys are always mandatory. A few others are skipped in the XML examples at > the > end of the NSF document, which makes me believe they might not really be > mandatory after all. > > Three leafs have a default, but most leafs are left optional without any > default. In many cases I think I understand what it means to not set a > leaf, > but with the ones listed here, I don't think it clear at all. Either add a > default to make it clear, make them mandatory if they should be, or > explain in > the leaf description what happens if not set. > > 493: leaf-list name > 513: leaf-list protocol > 531: leaf geo-ip-ipv4 > 541: leaf continent > 562: leaf feed-server-ipv4 > 585: leaf payload-description > 590: leaf-list content > 600: leaf-list owners > 870: leaf method > > 6. Indentation > > The YANG indentation is mostly wrong. Run the YANG text through pyang or > some > other tool that can indent the content correctly before you put it into a > document. > > 7. YANG element naming > > The YANG convention is to not have lists on the top level in the YANG > module, > but to surround lists with a container. The surrounding container often > has a > name in the plural and the list in singluar, like this > > container interfaces { > list interface { > > To better fit into the world of IETF YANG modules, I'd recommend turning > the > top level list i2nsf-cfi-policy into this instead: > > container i2nsf-cfi-policies { > list policy { > > Further down, I would change container rule to rules: > > container rules { > list rule { > > Finally, it is customary to not repeat the names of parent object in the > names > of elements. For example, in the following: > > list threat-feed-list > leaf feed-name > leaf feed-server-ipv4 > leaf feed-server-ipv6 > leaf feed-description > > all the leafs should normally not repeat "feed-". Just leaf name, leaf > server-ipv4, leaf server-ipv6, leaf description. There are many more > examples > of this throughout the module. > > The condition choice has many containers with a single leaf inside (e.g. > ddos-source). Their purpose is rather unclear to me. Remove? > > container ddos-source { > description > "This represents the source."; > leaf-list src-target { > > Also, I find the name "src-target" rather confusing. How about "source"? > > 8. No date leaf > > The draft text near fig 2 talks about a date leaf. There is no date object > in > this revision of te YANG. > > "Date: Date when this object was created or last modified" > > 9. leaf owner > > Near fig.3 leaf Owner is mentioned. Is this leaf still current? > > "Owner: This field contains the onwer of the rule. For example, > the person who created it, and eligible for modifying it." > > 10. leaf packet-per-second > > This is now modeled as uint16. Is this future proof? Many packet flows on > the > internet exceed 64k pps. > > 11. container custon-source > > Misspelled. Should be custom-source > > 12. identity ddos > > Is ddos a malware file-type? This is not exactly in line with my intuition. > > 13. identity protocol-type > > There are other modules that already define protocol-types. Would it be > worth > reusing one of them? > > 14. identity palo-alto > > Is it a good IETF practice to list vendor names in modules? Can we consider > this a protocol name? Is there perhaps an RFC/specification name for it > that we > could reference instead? > > 15. grouping ipsec-based-method > > This grouping contains a list which allows listing none of, either of or > both > of ipsecike and ikeless. Are all valid configurations? > > 16. leaf feed-name > > This leaf is the key in a list, which makes it possible to have at most one > feed of each type. If it would make sense to configure more than one feed > of > the same type, the YANG needs to be updated here. > > 17. leaf-list content > > This leaflist is of type string. What is the format of this string? Does > the > name refer to something? > > 18. Event types > > container event has a choice between enforce-admin and time alternatives. > Each > of those choices have a leaf that allows the operator to configure an > identityref to an enforce-type value. What does that mean? What would it > mean > if an operator configured admin == 'time' (or enforce-time == 'admin')? > > 19. leaf begin-time, end-time > > >From the examples, it can be seen that these are meant to be a time of day > values. Currently they are modeled as yang:date-and-time, which means they > are > a concrete time a specific day, e.g. 2019-11-11T16:07. This needs to be > changed > in order to be what the modeler intended. Perhaps like this: > > typedef time-of-day { > type string { > pattern '(2[0-3]|[01]?[0-9]):[0-5][0-9]'; > } > } > > 20. leaf frequency > > This leaf is now modeled properly from a YANG perspective. But what does it > mean? If this leaf is set to 'once-only', what exactly will happen only > once? > Please write a description that explains this. > > 21. Example in Fig.17 > > The example contains XML that refers to "endpoint-group/user-group". There > is > no such element in the YANG. > > > > > Furthermore, there is nothing called range-ip-address, start-ip-address, > end-ip-address. They are called range-ipv4-address, start-ipv4-address, > end-ipv4-address. > > > 221.159.112.1 > 221.159.112.90 > > > Finally, there must not be any xmlns attribute on an closing XML tag. So > > > > should be > > > > This happens in several of the examples. > > 22. Example in Fig.18 > > There is no element called policy any more. It's now i2nsf-cfi-policy. > > > security_policy_for_blocking_sns > > The rules are modeled in a container and list, both by the name rule. So > there > needs to be two tags. > > > block_access_to_sns_during_office_hours > > The security-event element is marked mandatory in the YANG, but missing in > the > example. The times given below may be what is intended, but do not match > the > date format for the type used (which include a date, etc). > > > > 09:00 > 18:00 > > > > Since the example is not mentioning leaf frequency, it will have the value > 'once-only'. Maybe explain what that means in the context of the example? > > The condition/firewall-condition says the src-target is mandatory and > dest-target optional, exactly like below. > condition/custom-destination/dest-target is mandatory and src-target is > optional, exactly like below. Is this pure luck, or is there a logical > explanation why exactly those should be mandatory, and the example use > precisely those? > > > > > employees > > > > > sns-websites > > > > The current YANG model does not allow setting both a firewall-condition and > custom-condition. If that should be allowed, the model needs to change. > Should > it be possible to have multiple firewall- or other conditions? That is not > currently possible. > > This example leaves out the mandatory leaf owner. Is that a sign that it > should > not be mandatory, or perhaps not exist at all? > > 23. Example in Fig.19 > > This example lists a firewall-condition with no src-target, which is > mandatory. > > > > employees > > > > Under condition, there is a container rate-limit with a leaf > packet-per-second. > Is this a trigger value for the condition, or is it an actual limit that > the > system is expected to enforce? If it's a trigger, it may be good to find a > clearer name. If it's enforced, it's placement under condition is > deceiving. > > If a rule's action is set to 'rate-limit', to which rate will it be > limited? > > 24. Security Considerations > > Section 10 in the NSF document under review is the Security > Considerations. I > think it would make sense to mention something about the management access > control mechanism here, and its relation to NACM. > > (End of list) > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --00000000000077f3c705a25b369f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
Thanks for your good suggestions.
I will reflect your comments on the revision.

Best Regards,
Paul

On Thu, Apr 2, 2020 at 8:46 PM t= om petch <daedulus@btconnect.c= om> wrote:
https://www.oeclassic.com/

Paul

At a tangent to Jan's comprehensive review, you have plenty of YANG ref= erence clauses which is good, but the RFC you reference must then appear as= Normative References in the I-D.

I see RFC
=C2=A0854
=C2=A0913
1081
1631
2579
2616
2818
3339
4250
5321
and
draft-ietf-sdn-ipsec-...
all of which need adding

On a different tack, I think that the choice of=C2=A0 prefix is unfortunate= .=C2=A0
capability uses nsfcap
registration uses nsfreg
This should use nsf.... perhaps nsfcon or nsfcfi ...
HTH

Tom Petch
----- Original Message -----
From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>
To: Jan Lindblad <j= anl@tail-f.com>
Cc: <draft-ietf-i2nsf-consumer-facing-interface-dm.= all@ietf.org>, <i2nsf@ietf.org>, <last-call@ietf.org>, YANG Doctors <yang-doctors@ietf.org>, skk= u-iotlab-members <skku-iotlab-members@googlegroups.com>, Mr. Jaeho= on Paul Jeong <jaehoon.paul@gmail.com>
Sent: 18/03/2020 17:41:41
Subject: Re: [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf= -i2nsf-consumer-facing-interface-dm-07
___________________________________________________________________________= _____


Hi Jan,
Could you update the state of YANGDOCTORS Last Call Review on
I2NSF Consumer-Facing Interface YANG Data Model=C2=A0 if the updates are fi= ne to you?

https://datatracker.i= etf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/

I think your comments are all addressed in this version.

Thanks.

Best Regards,
Paul



On Thu, Mar 12, 2020 at 1:15 AM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> = wrote:

Hi Jan,
We authors have addressed your comments with the revision:
https://tools.ietf.org/h= tml/draft-ietf-i2nsf-consumer-facing-interface-dm-08

I attach a revision letter to explain how to respond to your comments.

If you have further comments, please let me know.

Thanks.

Best Regards,
Paul



On Tue, Nov 12, 2019 at 1:53 AM Jan Lindblad via Datatracker <noreply@ietf.org> wrote:=

Reviewer: Jan Lindblad
Review result: Almost Ready

This is my YD review of draft-ietf-i2nsf-consumer-facing-interface-dm-07. I=
have previously reviewed the -05 revision (~end June). I find the new revis= ion
much improved, but still with much to discuss. I will call this "almos= t ready".

Generally speaking, I think the YANG module lacks the precision and
descriptions needed to foster interoperability. The examples at the end are=
very enlightening however, and compensate for much of that, but their infor= mal
nature can never replace proper YANG. The module usage needs to be mostly c= lear
from the module itself.

The management access control model proposed here is, even with its latest<= br> adaptation towards NACM, is still quite different from NACM author's or= iginal
ideas. I will therefore bring this use case up in the NETMOD WG for discuss= ion.

1. Network access control principles

Network access control is about which users are able to use the network bei= ng
managed, for example connect to facebook. The purpose of the NSF module is = to
control this access. This version of the YANG module is now based on a list= of
policies.

Each policy has a list of rules. Each rule has an event -- condition -- act= ion
triplet. This resembles traditional firewall management, which is a good th= ing,
because that concept is stable and much tried. This allows operators to cre= ate
lists of rules in this style:

if pkt.x =3D=3D 1: drop=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0// Rule 1
elif pkt.y > 2: alert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0// Rule 2
elif pkt.z =3D=3D 10: pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Rule 3
else: drop=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 // Rule 4

This pattern relies heavily on the ability to control the order of the rule= s.
The current model relies on the alphabetical sorting of names rules for the=
ordering. The YANG trick I would recommend to give operators the ability to=
insert and move rules as they wish is to add ordered-by user on the list:
=C2=A0 =C2=A0 list rule {
=C2=A0 =C2=A0 =C2=A0 ordered-by user;=C2=A0 // <=3D=3D Add this line
=C2=A0 =C2=A0 =C2=A0 leaf rule-name {

Nothing is said about what the system should do in case policies conflict. = What
if one policy says pass, the other drop for the same packet? Please clarify= ..
What should happen to packets that do not match any of the policies?

This module also assumes that all users in the operator's organization = are
listed in one or more NACM groups (e.g. "employees"). That wasn&#= 39;t really the
NACM authors' original intent. Even if this could be made to work maybe= , there
is no strong reason to repurpose the NACM group concept for user network ac= cess
purposes. It could easily be modeled differently. So in the cases where the= re
are leafrefs to NACM groups when dealing with network access rather than management access, don't use NACM groups.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf src-target { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path = /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;=C2=A0 //
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= =3D=3D Point to some other list of network users

2. Management access control principles

Management access control is about which users are able to configure/run actions/the policies and rules. IMO, the most controversial aspect of this<= br> module has always been its new and creative management access control model= .. In
this revision, the management principles have been remodeled greatly to fit= in
with NACM. I find this redesign very promising, but the result is still not=
quite ready for publication.

The point where integration with NACM concepts is important is when it come= s to
allow some users to CRUD the NSF policies and rules themselves. There is no= w a
leaf-list "owners" on each policy and rule which point to a list = of NACM
groups. My understanding is that the idea is that the NSF module should be = seen
as a service model that translate high level ownership information to speci= fic
NACM rules. It would be good to mention these ideas somewhere in the NSF document.

=C2=A0 leaf-list owners {
=C2=A0 =C2=A0 type leafref {
=C2=A0 =C2=A0 =C2=A0 path /nacm:nacm/nacm:groups/nacm:group/nacm:name;

I expect the intent is that any user listed in a NACM group mentioned in th= e
owners list would get full CRUD privileges for the contents of the rule the=
owners leaf sits on. That is never spelled out anywhere, however.

It is a little less clear how leaf-list owners on policy objects should be<= br> handled. Should owners listed on a policy object get full CRUD powers over = the
entire policy, including all the rules inside? Or would they need to be lis= ted
on the rules as well? Not clear. Is the intent that users not listed on the=
policy object are unable to create new rules, but to be able to update rule= s
they are listed as owners of, if any?

Who is allowed to create new policy objects? Should users that are not owne= rs
get read access to all the policies and rules?

Finally, there is an "owner" leaf on each rule with an identityre= f allowing
operators to configure a role name like dept-head or sec-admin. It is marke= d
mandatory, but never included in any of the examples at the end of the
document. This makes me think this may be a remnant from bygone times and should be removed from the YANG. If not, an explanation of how to use this<= br> leaf, and how it interacts with "owners" needs to be added, and t= he examples
updated.

3. leafrefs crosspointing between policy instances

There are six leafrefs that point to various objects inside a policy, e.g. = a
rule condition pointing to a device group name. None of them restrict what = can
be pointed to so that only names within the current policy are valid. It is=
therefore possible to configure the name of a device group defined in a
different policy. I suspect this is not the intention. In order to restrict= the
leafrefs to the same policy, the following predicate can be added:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list src-targe= t {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "/i2nsf= -cfi-policy[policy-name=3Dcurrent()/../../../../../policy-name]/endpoint-gr= oup/device-group/name";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// <= ;=3D=3D Add predicate

4. Mandatory to implement all events, conditions, actions

Each rule is defined with a choice of different events (admin, time),
conditions (firewall, ddos, custom, threat-feed) and actions (pass, drop, alert, mirror, ...). Is the intent that all of these options should be
mandatory to implement? The current model requires this. Also, would it mak= e
sense to allow additional mechanisms here? If so, it may be good to explain= to
readers how the set of choices and identities can be extended by
implementations.

5. Optional and mandatory elements

In this revision of the module, 8 leafs have been marked mandatory. A few o= f
them are list keys, which are conventionally not marked mandatory, since li= st
keys are always mandatory. A few others are skipped in the XML examples at = the
end of the NSF document, which makes me believe they might not really be mandatory after all.

Three leafs have a default, but most leafs are left optional without any default. In many cases I think I understand what it means to not set a leaf= ,
but with the ones listed here, I don't think it clear at all. Either ad= d a
default to make it clear, make them mandatory if they should be, or explain= in
the leaf description what happens if not set.

493: leaf-list name
513: leaf-list protocol
531: leaf geo-ip-ipv4
541: leaf continent
562: leaf feed-server-ipv4
585: leaf payload-description
590: leaf-list content
600: leaf-list owners
870: leaf method

6. Indentation

The YANG indentation is mostly wrong. Run the YANG text through pyang or so= me
other tool that can indent the content correctly before you put it into a document.

7. YANG element naming

The YANG convention is to not have lists on the top level in the YANG modul= e,
but to surround lists with a container. The surrounding container often has= a
name in the plural and the list in singluar, like this

container interfaces {
=C2=A0 =C2=A0 list interface {

To better fit into the world of IETF YANG modules, I'd recommend turnin= g the
top level list i2nsf-cfi-policy into this instead:

container i2nsf-cfi-policies {
=C2=A0 =C2=A0 list policy {

Further down, I would change container rule to rules:

container rules {
=C2=A0 =C2=A0 list rule {

Finally, it is customary to not repeat the names of parent object in the na= mes
of elements. For example, in the following:

list threat-feed-list
=C2=A0 =C2=A0 leaf feed-name
=C2=A0 =C2=A0 leaf feed-server-ipv4
=C2=A0 =C2=A0 leaf feed-server-ipv6
=C2=A0 =C2=A0 leaf feed-description

all the leafs should normally not repeat "feed-". Just leaf name,= leaf
server-ipv4, leaf server-ipv6, leaf description. There are many more exampl= es
of this throughout the module.

The condition choice has many containers with a single leaf inside (e.g. ddos-source). Their purpose is rather unclear to me. Remove?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container ddos-source { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This represen= ts the source.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list src-targe= t {

Also, I find the name "src-target" rather confusing. How about &q= uot;source"?

8. No date leaf

The draft text near fig 2 talks about a date leaf. There is no date object = in
this revision of te YANG.

"Date:=C2=A0 Date when this object was created or last modified"<= br>
9. leaf owner

Near fig.3 leaf Owner is mentioned. Is this leaf still current?

"Owner: This field contains the onwer of the rule.=C2=A0 For example,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the person who created it, = and eligible for modifying it."

10. leaf packet-per-second

This is now modeled as uint16. Is this future proof? Many packet flows on t= he
internet exceed 64k pps.

11. container custon-source

Misspelled. Should be custom-source

12. identity ddos

Is ddos a malware file-type? This is not exactly in line with my intuition.=

13. identity protocol-type

There are other modules that already define protocol-types. Would it be wor= th
reusing one of them?

14. identity palo-alto

Is it a good IETF practice to list vendor names in modules? Can we consider=
this a protocol name? Is there perhaps an RFC/specification name for it tha= t we
could reference instead?

15. grouping ipsec-based-method

This grouping contains a list which allows listing none of, either of or bo= th
of ipsecike and ikeless. Are all valid configurations?

16. leaf feed-name

This leaf is the key in a list, which makes it possible to have at most one=
feed of each type. If it would make sense to configure more than one feed o= f
the same type, the YANG needs to be updated here.

17. leaf-list content

This leaflist is of type string. What is the format of this string? Does th= e
name refer to something?

18. Event types

container event has a choice between enforce-admin and time alternatives. E= ach
of those choices have a leaf that allows the operator to configure an
identityref to an enforce-type value. What does that mean? What would it me= an
if an operator configured admin =3D=3D 'time' (or enforce-time =3D= =3D 'admin')?

19. leaf begin-time, end-time

>From the examples, it can be seen that these are meant to be a time of = day
values. Currently they are modeled as yang:date-and-time, which means they = are
a concrete time a specific day, e.g. 2019-11-11T16:07. This needs to be cha= nged
in order to be what the modeler intended. Perhaps like this:

typedef time-of-day {
=C2=A0 =C2=A0 type string {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pattern '(2[0-3]|[01]?[0-9]):[0-5][0-9]'= ;;
=C2=A0 =C2=A0 }
}

20. leaf frequency

This leaf is now modeled properly from a YANG perspective. But what does it=
mean? If this leaf is set to 'once-only', what exactly will happen = only once?
Please write a description that explains this.

21. Example in Fig.17

The example contains XML that refers to "endpoint-group/user-group&quo= t;. There is
no such element in the YANG.

<endpoint-group xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi= -policy">
=C2=A0 <user-group>

Furthermore, there is nothing called range-ip-address, start-ip-address, end-ip-address. They are called range-ipv4-address, start-ipv4-address,
end-ipv4-address.

=C2=A0 =C2=A0 <range-ip-address>
=C2=A0 =C2=A0 =C2=A0 <start-ip-address>221.159.112.1</start-ip-add= ress>
=C2=A0 =C2=A0 =C2=A0 <end-ip-address>221.159.112.90</end-ip-addres= s>
=C2=A0 =C2=A0 </range-ip-address>

Finally, there must not be any xmlns attribute on an closing XML tag. So
</endpoint-group xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-i2nsf-cf= i-policy">

should be

</endpoint-group>

This happens in several of the examples.

22. Example in Fig.18

There is no element called policy any more. It's now i2nsf-cfi-policy.<= br>
=C2=A0 =C2=A0<policy xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-i2ns= f-cfi-policy">
=C2=A0 =C2=A0 =C2=A0<policy-name>security_policy_for_blocking_sns<= /policy-name>

The rules are modeled in a container and list, both by the name rule. So th= ere
needs to be two <rule> tags.

=C2=A0 =C2=A0 =C2=A0<rule>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<rule-name>block_access_to_sns_during_offi= ce_hours</rule-name>

The security-event element is marked mandatory in the YANG, but missing in = the
example. The times given below may be what is intended, but do not match th= e
date format for the type used (which include a date, etc).

=C2=A0 =C2=A0 =C2=A0 =C2=A0<event>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<time-information>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<begin-time>09:00</begin-= time>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<end-time>18:00</end-time= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</time-information>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</event>

Since the example is not mentioning leaf frequency, it will have the value<= br> 'once-only'. Maybe explain what that means in the context of the ex= ample?

The condition/firewall-condition says the src-target is mandatory and
dest-target optional, exactly like below.
condition/custom-destination/dest-target is mandatory and src-target is
optional, exactly like below. Is this pure luck, or is there a logical
explanation why exactly those should be mandatory, and the example use
precisely those?

=C2=A0 =C2=A0 =C2=A0 =C2=A0<condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<firewall-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<source-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<src-target>employees= </src-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</source-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</firewall-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<custom-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<destination-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dest-target>sns-webs= ites</dest-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</destination-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</custom-condition>

The current YANG model does not allow setting both a firewall-condition and=
custom-condition. If that should be allowed, the model needs to change. Sho= uld
it be possible to have multiple firewall- or other conditions? That is not<= br> currently possible.

This example leaves out the mandatory leaf owner. Is that a sign that it sh= ould
not be mandatory, or perhaps not exist at all?

23. Example in Fig.19

This example lists a firewall-condition with no src-target, which is mandat= ory.

=C2=A0 =C2=A0 =C2=A0 <firewall-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <destination-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dest-target>employees</dest-ta= rget>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </destination-target>
=C2=A0 =C2=A0 =C2=A0 </firewall-condition>

Under condition, there is a container rate-limit with a leaf packet-per-sec= ond.
Is this a trigger value for the condition, or is it an actual limit that th= e
system is expected to enforce? If it's a trigger, it may be good to fin= d a
clearer name. If it's enforced, it's placement under condition is d= eceiving.

If a rule's action is set to 'rate-limit', to which rate will i= t be limited?

24. Security Considerations

Section 10 in the NSF document under review is the Security Considerations.= I
think it would make sense to mention something about the management access<= br> control mechanism here, and its relation to NACM.

(End of list)


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf





--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php





--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.= D.
Associate Professor
Department of Software
Sungkyunkwan Univers= ity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeon= g@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeho= on-jeong.php
--00000000000077f3c705a25b369f-- From nobody Mon Apr 6 01:46:49 2020 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BC33A0B7D; Mon, 6 Apr 2020 01:46:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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_rnHoH6EYJY; Mon, 6 Apr 2020 01:46:08 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2132.outbound.protection.outlook.com [40.107.21.132]) (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 5BD033A0B79; Mon, 6 Apr 2020 01:46:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mPC2g+5tQ2sjZT9mjKi1zOTHPP/JrcGnRo43RG5SNFbDMl4OnQ5U0Flj5Lucyd3Fl0Un7uOBTLw6JKPzcJtMAb1Hs0AupM48397JF5U5L3webhKPIvaoKexgR+qsnHZt7jqj7ytdLblBK9Wq9Aivu7GKGkOOmwftdBrWwaDs+lqHnchS3XX/CZOnkNlmZdltGm1lbHJmMfJPUi1IVbe0iiekbCqS/aGKrzTkQpHsZGT7aVade/k19On2VQevuDzJh8MKvLXg01CrJR74AGwkksiJkeRzIZPFqylN02TMAq4fkGBCg3JbbP9qNehXp8gfNNnXCbLK7zR3Jgw/1WSDNA== 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=AkFJHx+v+79m0uN9zmYpzPHyMXH9UOomdeQlOPilvJ0=; b=W0Zw0f1W4Tqfk3KHmNgwRns1fzVb0afYZebuw0Rj3NsFcvrVZDocNKCXDNbq1MRssjpD9cVF9l2Hl5lJDNPv2dM3Qm3GtrdnKsk/J3zHOQZpJAySB+QvHi3/TwZFvrcBATzZuq8YfhfXOgL6Idh11eBNn7BbxvlTSN7fRcf1ziSxxztzJZjkrBHlqoxviJEFWD7yqADGxJBT8Uehq7iSqBaxagzkSMXH08sAgfl7M6+FRg7d6mFt/Kgip+hy6xORuO1v8kJESv/o2RigzRtikTeJzvkP8bHwendggwiCYH4s4N85JsBX92WYBibJntXSiZEdY+jGaD8o6zzVbStG4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AkFJHx+v+79m0uN9zmYpzPHyMXH9UOomdeQlOPilvJ0=; b=p6igvJqqnTK/XrBbtlNUc0+5aUUtajauybxIYenM692xT0HJDzOR9RAJa2tGy0XEwjztzliad45lK22QIQhoodjLoGUxdL7JSskwy/6Sn82BXmUtSwuVzwZuhoUvrTsftvOBvcm2SX+xnKltfPi73mgUR4S2xOXxpjDaaZQfHjI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from VI1PR07MB3502.eurprd07.prod.outlook.com (10.170.237.22) by VI1PR07MB6173.eurprd07.prod.outlook.com (20.178.11.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Mon, 6 Apr 2020 08:46:04 +0000 Received: from VI1PR07MB3502.eurprd07.prod.outlook.com ([fe80::50f:3508:da66:c7fc]) by VI1PR07MB3502.eurprd07.prod.outlook.com ([fe80::50f:3508:da66:c7fc%7]) with mapi id 15.20.2878.014; Mon, 6 Apr 2020 08:46:04 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable References: <157349122063.7571.1978842562243958252@ietfa.amsl.com> <1UW7PG0cZk.1BtlYcJAH5b@pc8xp> Date: Mon, 6 Apr 2020 09:45:51 +0100 Message-ID: <1UW7Tantp8.3ZcaUT390qJ@pc8xp> In-Reply-To: From: "tom petch" To: "Mr. Jaehoon Paul Jeong" Cc: "Jan Lindblad" , "draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org" , "i2nsf@ietf.org" , "Mr. Jaehoon Paul Jeong" User-Agent: OEClassic/3.0 (WinXP.2600; F; 2019-11-28) X-ClientProxiedBy: LO2P265CA0273.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::21) To VI1PR07MB3502.eurprd07.prod.outlook.com (2603:10a6:802:1a::22) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from pc8xp (81.131.229.19) by LO2P265CA0273.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20 via Frontend Transport; Mon, 6 Apr 2020 08:46:02 +0000 X-Originating-IP: [81.131.229.19] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5e5ea3bd-5d14-409f-b6f7-08d7da06f070 X-MS-TrafficTypeDiagnostic: VI1PR07MB6173: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0365C0E14B X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB3502.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(39860400002)(346002)(136003)(396003)(376002)(366004)(8936002)(5660300002)(66946007)(30864003)(45080400002)(66556008)(66476007)(9686003)(66574012)(55016002)(966005)(6666004)(6916009)(52230400001)(4326008)(26005)(9576002)(186003)(54906003)(478600001)(81166006)(81156014)(8676002)(33716001)(956004)(16799955002)(86362001)(2906002)(52116002)(16526019)(53546011)(6496006)(15188155005)(316002); DIR:OUT; SFP:1102; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UCLeabaz4kUQBBAEG7VUSFoLqe8RCO0e+H0LOyZjKSb6uO7H260zNcNuq/Tq2GXiNwaOpyfgnRh2AkWN37bmpSmLk2541h9Vw3dU3d3dG/jCpluMlNS5jbIKcb62o0qhN+V4FpjyP4z/j2cLcT0YKc5ALzVliTgcli83SesrMJM/UvQQP7YeD+I8nwz/V0XvMEaRLVosvQSColLbz4nztKRs7U6+jfZOcghSrHP79D3CI28saFwa5uMC0ied5CQ0TDjIo/GHk2cNj70BV9fUwpk4Lq+eKZEMgMWCyW+SxXmgNOqTJPuU2l1jOUHS3ZpCdiX83MP4sQunzx4WfZfFp5XNr1h5I/+cGHnz/qmkbLw7bPIXTQIGiR1OiSqbUsFHYqCiZ98GJ+5oKs0xgbsmZ8/dEH2rZAHw4T4Bb/5SOnkAxHUPY02gzpDB8+vFQzRqrQuCrr4dIY1+ZgcPl8kMTkqG59nIYCkR6c9Hhh4wPLZqcvLONC7QPpAsYZKAP/F3tSLsPqGQ+xQjw7ITvsM55w== X-MS-Exchange-AntiSpam-MessageData: ZlxOs2KzBX47zd8qLQOwehDrHr+QL0h6npuyKtcy8elqf5kOgiWgJ2LNAvOGUB9WvdMvgTEC3cKZB5xoJTIpqLndN8Zzh082RuP53ayPX/smppHrdjBu3zh5ACzxbn0nA7I+ZpHnp+NtNVPpQgA2Fg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e5ea3bd-5d14-409f-b6f7-08d7da06f070 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 08:46:04.3956 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YP21ZpzzQ7xyBOCoOE5y9up/3yts4CtwDTllKCu7GhzLKWInjSBX4dYCckB0YvfG6SJ6KDkp6dJqr73snzHKEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6173 Archived-At: Subject: Re: [I2nsf] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-07 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 08:46:13 -0000 Paul, another tangential suggestion, posting here because I am not on the I= 2NSF list (and my ESP will not let me subscribe to it:-(, one which is gene= ral to other I2NSF I-D; move the Examples to an Appendix. The logic is tha= t by convention, Appendices are Informative while the rest of the I-D is No= rmative and if you want it different, then that is normally explicitly spel= t out. Examples are commonly Informative which fits with placing them in a= n Appendix. If you want to keep them in Section 9, and do not want them to= be seen as Normative, then I suggest adding a note 'This section is Inform= ative' to the start of section 9.=20 HTH, tom petch --- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ ----- Original Message ----- From: Mr. Jaehoon Paul Jeong Sent: 03/04/2020 05:18:05 Hi Tom, Thanks for your good suggestions. I will reflect your comments on the revision. Best Regards, Paul On Thu, Apr 2, 2020 at 8:46 PM tom petch wrote: --- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ Paul At a tangent to Jan's comprehensive review, you have plenty of YANG referen= ce clauses which is good, but the RFC you reference must then appear as Nor= mative References in the I-D. I see RFC 854 913 1081 1631 2579 2616 2818 3339 4250 5321 and draft-ietf-sdn-ipsec-... all of which need adding On a different tack, I think that the choice of prefix is unfortunate. =20 capability uses nsfcap registration uses nsfreg This should use nsf.... perhaps nsfcon or nsfcfi ... HTH Tom Petch ----- Original Message ----- From: Mr. Jaehoon Paul Jeong To: Jan Lindblad Cc: , , , YANG Doctors , skku-i= otlab-members , Mr. Jaehoon Paul Jeon= g Sent: 18/03/2020 17:41:41 Subject: Re: [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf= -i2nsf-consumer-facing-interface-dm-07 ___________________________________________________________________________= _____ Hi Jan, Could you update the state of YANGDOCTORS Last Call Review on I2NSF Consumer-Facing Interface YANG Data Model if the updates are fine to= you? https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface= -dm/ I think your comments are all addressed in this version. Thanks. Best Regards, Paul On Thu, Mar 12, 2020 at 1:15 AM Mr. Jaehoon Paul Jeong wrote: Hi Jan, We authors have addressed your comments with the revision: https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-0= 8 I attach a revision letter to explain how to respond to your comments. If you have further comments, please let me know. Thanks. Best Regards, Paul On Tue, Nov 12, 2019 at 1:53 AM Jan Lindblad via Datatracker wrote: Reviewer: Jan Lindblad Review result: Almost Ready This is my YD review of draft-ietf-i2nsf-consumer-facing-interface-dm-07. I have previously reviewed the -05 revision (~end June). I find the new revis= ion much improved, but still with much to discuss. I will call this "almost rea= dy". Generally speaking, I think the YANG module lacks the precision and descriptions needed to foster interoperability. The examples at the end are very enlightening however, and compensate for much of that, but their infor= mal nature can never replace proper YANG. The module usage needs to be mostly c= lear from the module itself. The management access control model proposed here is, even with its latest adaptation towards NACM, is still quite different from NACM author's origin= al ideas. I will therefore bring this use case up in the NETMOD WG for discuss= ion. 1. Network access control principles Network access control is about which users are able to use the network bei= ng managed, for example connect to facebook. The purpose of the NSF module is = to control this access. This version of the YANG module is now based on a list= of policies. Each policy has a list of rules. Each rule has an event -- condition -- act= ion triplet. This resembles traditional firewall management, which is a good th= ing, because that concept is stable and much tried. This allows operators to cre= ate lists of rules in this style: if pkt.x =3D=3D 1: drop // Rule 1 elif pkt.y > 2: alert // Rule 2 elif pkt.z =3D=3D 10: pass // Rule 3 else: drop // Rule 4 This pattern relies heavily on the ability to control the order of the rule= s. The current model relies on the alphabetical sorting of names rules for the ordering. The YANG trick I would recommend to give operators the ability to insert and move rules as they wish is to add ordered-by user on the list: list rule { ordered-by user; // <=3D=3D Add this line leaf rule-name { Nothing is said about what the system should do in case policies conflict. = What if one policy says pass, the other drop for the same packet? Please clarify= .. What should happen to packets that do not match any of the policies? This module also assumes that all users in the operator's organization are listed in one or more NACM groups (e.g. "employees"). That wasn't really th= e NACM authors' original intent. Even if this could be made to work maybe, th= ere is no strong reason to repurpose the NACM group concept for user network ac= cess purposes. It could easily be modeled differently. So in the cases where the= re are leafrefs to NACM groups when dealing with network access rather than management access, don't use NACM groups. leaf src-target { type leafref { path /nacm:nacm/nacm:groups/nacm:group/nacm:user-name; = // <=3D=3D Point to some other list of network users 2. Management access control principles Management access control is about which users are able to configure/run actions/the policies and rules. IMO, the most controversial aspect of this module has always been its new and creative management access control model= .. In this revision, the management principles have been remodeled greatly to fit= in with NACM. I find this redesign very promising, but the result is still not quite ready for publication. The point where integration with NACM concepts is important is when it come= s to allow some users to CRUD the NSF policies and rules themselves. There is no= w a leaf-list "owners" on each policy and rule which point to a list of NACM groups. My understanding is that the idea is that the NSF module should be = seen as a service model that translate high level ownership information to speci= fic NACM rules. It would be good to mention these ideas somewhere in the NSF document. leaf-list owners { type leafref { path /nacm:nacm/nacm:groups/nacm:group/nacm:name; I expect the intent is that any user listed in a NACM group mentioned in th= e owners list would get full CRUD privileges for the contents of the rule the owners leaf sits on. That is never spelled out anywhere, however. It is a little less clear how leaf-list owners on policy objects should be handled. Should owners listed on a policy object get full CRUD powers over = the entire policy, including all the rules inside? Or would they need to be lis= ted on the rules as well? Not clear. Is the intent that users not listed on the policy object are unable to create new rules, but to be able to update rule= s they are listed as owners of, if any? Who is allowed to create new policy objects? Should users that are not owne= rs get read access to all the policies and rules? Finally, there is an "owner" leaf on each rule with an identityref allowing operators to configure a role name like dept-head or sec-admin. It is marke= d mandatory, but never included in any of the examples at the end of the document. This makes me think this may be a remnant from bygone times and should be removed from the YANG. If not, an explanation of how to use this leaf, and how it interacts with "owners" needs to be added, and the example= s updated. 3. leafrefs crosspointing between policy instances There are six leafrefs that point to various objects inside a policy, e.g. = a rule condition pointing to a device group name. None of them restrict what = can be pointed to so that only names within the current policy are valid. It is therefore possible to configure the name of a device group defined in a different policy. I suspect this is not the intention. In order to restrict= the leafrefs to the same policy, the following predicate can be added: leaf-list src-target { type leafref { path "/i2nsf-cfi-policy[policy-name=3Dcurrent()/../../../../..= /policy-name]/endpoint-group/device-group/name"; // <=3D=3D Add predicate 4. Mandatory to implement all events, conditions, actions Each rule is defined with a choice of different events (admin, time), conditions (firewall, ddos, custom, threat-feed) and actions (pass, drop, alert, mirror, ...). Is the intent that all of these options should be mandatory to implement? The current model requires this. Also, would it mak= e sense to allow additional mechanisms here? If so, it may be good to explain= to readers how the set of choices and identities can be extended by implementations. 5. Optional and mandatory elements In this revision of the module, 8 leafs have been marked mandatory. A few o= f them are list keys, which are conventionally not marked mandatory, since li= st keys are always mandatory. A few others are skipped in the XML examples at = the end of the NSF document, which makes me believe they might not really be mandatory after all. Three leafs have a default, but most leafs are left optional without any default. In many cases I think I understand what it means to not set a leaf= , but with the ones listed here, I don't think it clear at all. Either add a default to make it clear, make them mandatory if they should be, or explain= in the leaf description what happens if not set. 493: leaf-list name 513: leaf-list protocol 531: leaf geo-ip-ipv4 541: leaf continent 562: leaf feed-server-ipv4 585: leaf payload-description 590: leaf-list content 600: leaf-list owners 870: leaf method 6. Indentation The YANG indentation is mostly wrong. Run the YANG text through pyang or so= me other tool that can indent the content correctly before you put it into a document. 7. YANG element naming The YANG convention is to not have lists on the top level in the YANG modul= e, but to surround lists with a container. The surrounding container often has= a name in the plural and the list in singluar, like this container interfaces { list interface { To better fit into the world of IETF YANG modules, I'd recommend turning th= e top level list i2nsf-cfi-policy into this instead: container i2nsf-cfi-policies { list policy { Further down, I would change container rule to rules: container rules { list rule { Finally, it is customary to not repeat the names of parent object in the na= mes of elements. For example, in the following: list threat-feed-list leaf feed-name leaf feed-server-ipv4 leaf feed-server-ipv6 leaf feed-description all the leafs should normally not repeat "feed-". Just leaf name, leaf server-ipv4, leaf server-ipv6, leaf description. There are many more exampl= es of this throughout the module. The condition choice has many containers with a single leaf inside (e.g. ddos-source). Their purpose is rather unclear to me. Remove? container ddos-source { description "This represents the source."; leaf-list src-target { Also, I find the name "src-target" rather confusing. How about "source"? 8. No date leaf The draft text near fig 2 talks about a date leaf. There is no date object = in this revision of te YANG. "Date: Date when this object was created or last modified" 9. leaf owner Near fig.3 leaf Owner is mentioned. Is this leaf still current? "Owner: This field contains the onwer of the rule. For example, the person who created it, and eligible for modifying it." 10. leaf packet-per-second This is now modeled as uint16. Is this future proof? Many packet flows on t= he internet exceed 64k pps. 11. container custon-source Misspelled. Should be custom-source 12. identity ddos Is ddos a malware file-type? This is not exactly in line with my intuition. 13. identity protocol-type There are other modules that already define protocol-types. Would it be wor= th reusing one of them? 14. identity palo-alto Is it a good IETF practice to list vendor names in modules? Can we consider this a protocol name? Is there perhaps an RFC/specification name for it tha= t we could reference instead? 15. grouping ipsec-based-method This grouping contains a list which allows listing none of, either of or bo= th of ipsecike and ikeless. Are all valid configurations? 16. leaf feed-name This leaf is the key in a list, which makes it possible to have at most one feed of each type. If it would make sense to configure more than one feed o= f the same type, the YANG needs to be updated here. 17. leaf-list content This leaflist is of type string. What is the format of this string? Does th= e name refer to something? 18. Event types container event has a choice between enforce-admin and time alternatives. E= ach of those choices have a leaf that allows the operator to configure an identityref to an enforce-type value. What does that mean? What would it me= an if an operator configured admin =3D=3D 'time' (or enforce-time =3D=3D 'admi= n')? 19. leaf begin-time, end-time >From the examples, it can be seen that these are meant to be a time of day values. Currently they are modeled as yang:date-and-time, which means they = are a concrete time a specific day, e.g. 2019-11-11T16:07. This needs to be cha= nged in order to be what the modeler intended. Perhaps like this: typedef time-of-day { type string { pattern '(2[0-3]|[01]?[0-9]):[0-5][0-9]'; } } 20. leaf frequency This leaf is now modeled properly from a YANG perspective. But what does it mean? If this leaf is set to 'once-only', what exactly will happen only onc= e? Please write a description that explains this. 21. Example in Fig.17 The example contains XML that refers to "endpoint-group/user-group". There = is no such element in the YANG. Furthermore, there is nothing called range-ip-address, start-ip-address, end-ip-address. They are called range-ipv4-address, start-ipv4-address, end-ipv4-address. 221.159.112.1 221.159.112.90 Finally, there must not be any xmlns attribute on an closing XML tag. So should be This happens in several of the examples. 22. Example in Fig.18 There is no element called policy any more. It's now i2nsf-cfi-policy. security_policy_for_blocking_sns The rules are modeled in a container and list, both by the name rule. So th= ere needs to be two tags. block_access_to_sns_during_office_hours The security-event element is marked mandatory in the YANG, but missing in = the example. The times given below may be what is intended, but do not match th= e date format for the type used (which include a date, etc). 09:00 18:00 Since the example is not mentioning leaf frequency, it will have the value 'once-only'. Maybe explain what that means in the context of the example? The condition/firewall-condition says the src-target is mandatory and dest-target optional, exactly like below. condition/custom-destination/dest-target is mandatory and src-target is optional, exactly like below. Is this pure luck, or is there a logical explanation why exactly those should be mandatory, and the example use precisely those? employees sns-websites The current YANG model does not allow setting both a firewall-condition and custom-condition. If that should be allowed, the model needs to change. Sho= uld it be possible to have multiple firewall- or other conditions? That is not currently possible. This example leaves out the mandatory leaf owner. Is that a sign that it sh= ould not be mandatory, or perhaps not exist at all? 23. Example in Fig.19 This example lists a firewall-condition with no src-target, which is mandat= ory. employees Under condition, there is a container rate-limit with a leaf packet-per-sec= ond. Is this a trigger value for the condition, or is it an actual limit that th= e system is expected to enforce? If it's a trigger, it may be good to find a clearer name. If it's enforced, it's placement under condition is deceiving= . If a rule's action is set to 'rate-limit', to which rate will it be limited= ? 24. Security Considerations Section 10 in the NSF document under review is the Security Considerations.= I think it would make sense to mention something about the management access control mechanism here, and its relation to NACM. (End of list) _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php From nobody Mon Apr 6 01:50:19 2020 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0673A0BC3; Mon, 6 Apr 2020 01:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7cOnn7f8UWEa; Mon, 6 Apr 2020 01:50:09 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268FA3A0BC1; Mon, 6 Apr 2020 01:50:08 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id j17so11112513lfe.7; Mon, 06 Apr 2020 01:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cehKN46bHhlVMJsfKbsenudNd2WHtqUHSU74DUoqtH4=; b=U6iFrSVMAa3QfbOWo5CrYO4TnrQ8zzP7mdVgd5iwE6XXeOFCnq7T3EkvAPBRltCjmB 0r+pjWZmF0VayZqmoKkP/DeBLuzVejOBfYs3XKE89pZKFbCVrm79GPIYhmdXH9LkV3RV LPJdy293BFEDJgCDkYu6+FuNf75HxvaNikPQ2YOEtLawuLec+00Rox3bk41Un9f6ke2+ ptQwBrGYZ4vgjm0ngeZfCmqvj+7KTqwMiZk6MoxKEckvml0sDAVpwz1Q0/Bbpk5btOYc z4zhrutQxzOhVLiOnZqju55ej03DeA4UHLuEnqXlrWiNMQXI0Ze7akdJlM0F9kqxB1LF TLjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cehKN46bHhlVMJsfKbsenudNd2WHtqUHSU74DUoqtH4=; b=mJbhGq0hGAWXwe6F75PXiVOH+cLDu9y2kBs1mYBudpkW2R6egnVQsucY6XStpbG/KD hSZBrfBo/eC8HPVil15tRkJr97F8MK7WaeC/ePN2yUdf5QUWcAaYTnGoVeWfD0lGSPGr IYGP3SkLWyM2esi6bZ1j1qzrtZwCfkPDbEri28U6Uj5my0/LkHTi9WRaWcASozWLNCOk vYgMasyNnsW2sgskgcbtM0VyQuqLpT8jQJUwg+YAvQ+FISsHgc3jl+g4usSRwk4QAzEF en/cnXXPj9CTRvoLUTw7ec8QRfy5Mkt2UABnPWGYxI38bQCtc9n16GEOt0A8dJU/7aoo nqEQ== X-Gm-Message-State: AGi0Pua/nHgShmheB5I4D3DNRRcwDKnIXDo3kqX5pBh6DtTfTK8Wv2uR EoBIj3OVTQb5Xg2pTKLGqNnyVrSAgcVuslnJi9g= X-Google-Smtp-Source: APiQypK4TdFxkHJkwg/zBA4KH3s5YuszueXsSDDceH8xDNuEHUgz913wrz5XF5YJI+XvKfre0iOsssngZQipZ8T1Nic= X-Received: by 2002:ac2:4295:: with SMTP id m21mr12909383lfh.132.1586163005570; Mon, 06 Apr 2020 01:50:05 -0700 (PDT) MIME-Version: 1.0 References: <157349122063.7571.1978842562243958252@ietfa.amsl.com> <1UW7PG0cZk.1BtlYcJAH5b@pc8xp> <1UW7Tantp8.3ZcaUT390qJ@pc8xp> In-Reply-To: <1UW7Tantp8.3ZcaUT390qJ@pc8xp> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 6 Apr 2020 17:49:28 +0900 Message-ID: To: tom petch Cc: Jan Lindblad , "draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org" , "i2nsf@ietf.org" , skku-iotlab-members , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="00000000000080c30005a29b5a4b" Archived-At: Subject: Re: [I2nsf] [Last-Call] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-07 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 08:50:15 -0000 --00000000000080c30005a29b5a4b Content-Type: text/plain; charset="UTF-8" Hi Tom, Thanks for your kind guidelines. I will follow your suggestions for our I2NSF YANG drafts. Best Regards, Paul On Mon, Apr 6, 2020 at 5:46 PM tom petch wrote: > Paul, another tangential suggestion, posting here because I am not on the > I2NSF list (and my ESP will not let me subscribe to it:-(, one which is > general to other I2NSF I-D; move the Examples to an Appendix. The logic is > that by convention, Appendices are Informative while the rest of the I-D is > Normative and if you want it different, then that is normally explicitly > spelt out. Examples are commonly Informative which fits with placing them > in an Appendix. If you want to keep them in Section 9, and do not want > them to be seen as Normative, then I suggest adding a note 'This section is > Informative' to the start of section 9. > HTH, tom petch > > --- > New Outlook Express and Windows Live Mail replacement - get it here: > https://www.oeclassic.com/ > > > ----- Original Message ----- > From: Mr. Jaehoon Paul Jeong > Sent: 03/04/2020 05:18:05 > > > Hi Tom, > Thanks for your good suggestions. > > > I will reflect your comments on the revision. > > > Best Regards, > Paul > > > On Thu, Apr 2, 2020 at 8:46 PM tom petch wrote: > > > --- > New Outlook Express and Windows Live Mail replacement - get it here: > https://www.oeclassic.com/ > > Paul > > At a tangent to Jan's comprehensive review, you have plenty of YANG > reference clauses which is good, but the RFC you reference must then appear > as Normative References in the I-D. > > I see RFC > 854 > 913 > 1081 > 1631 > 2579 > 2616 > 2818 > 3339 > 4250 > 5321 > and > draft-ietf-sdn-ipsec-... > all of which need adding > > On a different tack, I think that the choice of prefix is unfortunate. > capability uses nsfcap > registration uses nsfreg > This should use nsf.... perhaps nsfcon or nsfcfi ... > HTH > > Tom Petch > ----- Original Message ----- > From: Mr. Jaehoon Paul Jeong > To: Jan Lindblad > Cc: , < > i2nsf@ietf.org>, , YANG Doctors , > skku-iotlab-members , Mr. Jaehoon > Paul Jeong > Sent: 18/03/2020 17:41:41 > Subject: Re: [Last-Call] [I2nsf] Yangdoctors last call review of > draft-ietf-i2nsf-consumer-facing-interface-dm-07 > > ________________________________________________________________________________ > > > Hi Jan, > Could you update the state of YANGDOCTORS Last Call Review on > I2NSF Consumer-Facing Interface YANG Data Model if the updates are fine > to you? > > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/ > > I think your comments are all addressed in this version. > > Thanks. > > Best Regards, > Paul > > > > On Thu, Mar 12, 2020 at 1:15 AM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Jan, > We authors have addressed your comments with the revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-consumer-facing-interface-dm-08 > > I attach a revision letter to explain how to respond to your comments. > > If you have further comments, please let me know. > > Thanks. > > Best Regards, > Paul > > > > On Tue, Nov 12, 2019 at 1:53 AM Jan Lindblad via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Jan Lindblad > Review result: Almost Ready > > This is my YD review of draft-ietf-i2nsf-consumer-facing-interface-dm-07. I > have previously reviewed the -05 revision (~end June). I find the new > revision > much improved, but still with much to discuss. I will call this "almost > ready". > > Generally speaking, I think the YANG module lacks the precision and > descriptions needed to foster interoperability. The examples at the end are > very enlightening however, and compensate for much of that, but their > informal > nature can never replace proper YANG. The module usage needs to be mostly > clear > from the module itself. > > The management access control model proposed here is, even with its latest > adaptation towards NACM, is still quite different from NACM author's > original > ideas. I will therefore bring this use case up in the NETMOD WG for > discussion. > > 1. Network access control principles > > Network access control is about which users are able to use the network > being > managed, for example connect to facebook. The purpose of the NSF module is > to > control this access. This version of the YANG module is now based on a > list of > policies. > > Each policy has a list of rules. Each rule has an event -- condition -- > action > triplet. This resembles traditional firewall management, which is a good > thing, > because that concept is stable and much tried. This allows operators to > create > lists of rules in this style: > > if pkt.x == 1: drop // Rule 1 > elif pkt.y > 2: alert // Rule 2 > elif pkt.z == 10: pass // Rule 3 > else: drop // Rule 4 > > This pattern relies heavily on the ability to control the order of the > rules. > The current model relies on the alphabetical sorting of names rules for the > ordering. The YANG trick I would recommend to give operators the ability to > insert and move rules as they wish is to add ordered-by user on the list: > > list rule { > ordered-by user; // <== Add this line > leaf rule-name { > > Nothing is said about what the system should do in case policies conflict. > What > if one policy says pass, the other drop for the same packet? Please > clarify.. > What should happen to packets that do not match any of the policies? > > This module also assumes that all users in the operator's organization are > listed in one or more NACM groups (e.g. "employees"). That wasn't really > the > NACM authors' original intent. Even if this could be made to work maybe, > there > is no strong reason to repurpose the NACM group concept for user network > access > purposes. It could easily be modeled differently. So in the cases where > there > are leafrefs to NACM groups when dealing with network access rather than > management access, don't use NACM groups. > > leaf src-target { > type leafref { > path > /nacm:nacm/nacm:groups/nacm:group/nacm:user-name; // > <== Point to some other list of network users > > 2. Management access control principles > > Management access control is about which users are able to configure/run > actions/the policies and rules. IMO, the most controversial aspect of this > module has always been its new and creative management access control > model.. In > this revision, the management principles have been remodeled greatly to > fit in > with NACM. I find this redesign very promising, but the result is still not > quite ready for publication. > > The point where integration with NACM concepts is important is when it > comes to > allow some users to CRUD the NSF policies and rules themselves. There is > now a > leaf-list "owners" on each policy and rule which point to a list of NACM > groups. My understanding is that the idea is that the NSF module should be > seen > as a service model that translate high level ownership information to > specific > NACM rules. It would be good to mention these ideas somewhere in the NSF > document. > > leaf-list owners { > type leafref { > path /nacm:nacm/nacm:groups/nacm:group/nacm:name; > > I expect the intent is that any user listed in a NACM group mentioned in > the > owners list would get full CRUD privileges for the contents of the rule the > owners leaf sits on. That is never spelled out anywhere, however. > > It is a little less clear how leaf-list owners on policy objects should be > handled. Should owners listed on a policy object get full CRUD powers over > the > entire policy, including all the rules inside? Or would they need to be > listed > on the rules as well? Not clear. Is the intent that users not listed on the > policy object are unable to create new rules, but to be able to update > rules > they are listed as owners of, if any? > > Who is allowed to create new policy objects? Should users that are not > owners > get read access to all the policies and rules? > > Finally, there is an "owner" leaf on each rule with an identityref allowing > operators to configure a role name like dept-head or sec-admin. It is > marked > mandatory, but never included in any of the examples at the end of the > document. This makes me think this may be a remnant from bygone times and > should be removed from the YANG. If not, an explanation of how to use this > leaf, and how it interacts with "owners" needs to be added, and the > examples > updated. > > 3. leafrefs crosspointing between policy instances > > There are six leafrefs that point to various objects inside a policy, e.g. > a > rule condition pointing to a device group name. None of them restrict what > can > be pointed to so that only names within the current policy are valid. It is > therefore possible to configure the name of a device group defined in a > different policy. I suspect this is not the intention. In order to > restrict the > leafrefs to the same policy, the following predicate can be added: > > leaf-list src-target { > type leafref { > path > > "/i2nsf-cfi-policy[policy-name=current()/../../../../../policy-name]/endpoint-group/device-group/name"; > // <== Add predicate > > 4. Mandatory to implement all events, conditions, actions > > Each rule is defined with a choice of different events (admin, time), > conditions (firewall, ddos, custom, threat-feed) and actions (pass, drop, > alert, mirror, ...). Is the intent that all of these options should be > mandatory to implement? The current model requires this. Also, would it > make > sense to allow additional mechanisms here? If so, it may be good to > explain to > readers how the set of choices and identities can be extended by > implementations. > > 5. Optional and mandatory elements > > In this revision of the module, 8 leafs have been marked mandatory. A few > of > them are list keys, which are conventionally not marked mandatory, since > list > keys are always mandatory. A few others are skipped in the XML examples at > the > end of the NSF document, which makes me believe they might not really be > mandatory after all. > > Three leafs have a default, but most leafs are left optional without any > default. In many cases I think I understand what it means to not set a > leaf, > but with the ones listed here, I don't think it clear at all. Either add a > default to make it clear, make them mandatory if they should be, or > explain in > the leaf description what happens if not set. > > 493: leaf-list name > 513: leaf-list protocol > 531: leaf geo-ip-ipv4 > 541: leaf continent > 562: leaf feed-server-ipv4 > 585: leaf payload-description > 590: leaf-list content > 600: leaf-list owners > 870: leaf method > > 6. Indentation > > The YANG indentation is mostly wrong. Run the YANG text through pyang or > some > other tool that can indent the content correctly before you put it into a > document. > > 7. YANG element naming > > The YANG convention is to not have lists on the top level in the YANG > module, > but to surround lists with a container. The surrounding container often > has a > name in the plural and the list in singluar, like this > > container interfaces { > list interface { > > To better fit into the world of IETF YANG modules, I'd recommend turning > the > top level list i2nsf-cfi-policy into this instead: > > container i2nsf-cfi-policies { > list policy { > > Further down, I would change container rule to rules: > > container rules { > list rule { > > Finally, it is customary to not repeat the names of parent object in the > names > of elements. For example, in the following: > > list threat-feed-list > leaf feed-name > leaf feed-server-ipv4 > leaf feed-server-ipv6 > leaf feed-description > > all the leafs should normally not repeat "feed-". Just leaf name, leaf > server-ipv4, leaf server-ipv6, leaf description. There are many more > examples > of this throughout the module. > > The condition choice has many containers with a single leaf inside (e.g. > ddos-source). Their purpose is rather unclear to me. Remove? > > container ddos-source { > description > "This represents the source."; > leaf-list src-target { > > Also, I find the name "src-target" rather confusing. How about "source"? > > 8. No date leaf > > The draft text near fig 2 talks about a date leaf. There is no date object > in > this revision of te YANG. > > "Date: Date when this object was created or last modified" > > 9. leaf owner > > Near fig.3 leaf Owner is mentioned. Is this leaf still current? > > "Owner: This field contains the onwer of the rule. For example, > the person who created it, and eligible for modifying it." > > 10. leaf packet-per-second > > This is now modeled as uint16. Is this future proof? Many packet flows on > the > internet exceed 64k pps. > > 11. container custon-source > > Misspelled. Should be custom-source > > 12. identity ddos > > Is ddos a malware file-type? This is not exactly in line with my intuition. > > 13. identity protocol-type > > There are other modules that already define protocol-types. Would it be > worth > reusing one of them? > > 14. identity palo-alto > > Is it a good IETF practice to list vendor names in modules? Can we consider > this a protocol name? Is there perhaps an RFC/specification name for it > that we > could reference instead? > > 15. grouping ipsec-based-method > > This grouping contains a list which allows listing none of, either of or > both > of ipsecike and ikeless. Are all valid configurations? > > 16. leaf feed-name > > This leaf is the key in a list, which makes it possible to have at most one > feed of each type. If it would make sense to configure more than one feed > of > the same type, the YANG needs to be updated here. > > 17. leaf-list content > > This leaflist is of type string. What is the format of this string? Does > the > name refer to something? > > 18. Event types > > container event has a choice between enforce-admin and time alternatives. > Each > of those choices have a leaf that allows the operator to configure an > identityref to an enforce-type value. What does that mean? What would it > mean > if an operator configured admin == 'time' (or enforce-time == 'admin')? > > 19. leaf begin-time, end-time > > >From the examples, it can be seen that these are meant to be a time of day > values. Currently they are modeled as yang:date-and-time, which means they > are > a concrete time a specific day, e.g. 2019-11-11T16:07. This needs to be > changed > in order to be what the modeler intended. Perhaps like this: > > typedef time-of-day { > type string { > pattern '(2[0-3]|[01]?[0-9]):[0-5][0-9]'; > } > } > > 20. leaf frequency > > This leaf is now modeled properly from a YANG perspective. But what does it > mean? If this leaf is set to 'once-only', what exactly will happen only > once? > Please write a description that explains this. > > 21. Example in Fig.17 > > The example contains XML that refers to "endpoint-group/user-group". There > is > no such element in the YANG. > > > > > Furthermore, there is nothing called range-ip-address, start-ip-address, > end-ip-address. They are called range-ipv4-address, start-ipv4-address, > end-ipv4-address. > > > 221.159.112.1 > 221.159.112.90 > > > Finally, there must not be any xmlns attribute on an closing XML tag. So > > > > should be > > > > This happens in several of the examples. > > 22. Example in Fig.18 > > There is no element called policy any more. It's now i2nsf-cfi-policy. > > > security_policy_for_blocking_sns > > The rules are modeled in a container and list, both by the name rule. So > there > needs to be two tags. > > > block_access_to_sns_during_office_hours > > The security-event element is marked mandatory in the YANG, but missing in > the > example. The times given below may be what is intended, but do not match > the > date format for the type used (which include a date, etc). > > > > 09:00 > 18:00 > > > > Since the example is not mentioning leaf frequency, it will have the value > 'once-only'. Maybe explain what that means in the context of the example? > > The condition/firewall-condition says the src-target is mandatory and > dest-target optional, exactly like below. > condition/custom-destination/dest-target is mandatory and src-target is > optional, exactly like below. Is this pure luck, or is there a logical > explanation why exactly those should be mandatory, and the example use > precisely those? > > > > > employees > > > > > sns-websites > > > > The current YANG model does not allow setting both a firewall-condition and > custom-condition. If that should be allowed, the model needs to change. > Should > it be possible to have multiple firewall- or other conditions? That is not > currently possible. > > This example leaves out the mandatory leaf owner. Is that a sign that it > should > not be mandatory, or perhaps not exist at all? > > 23. Example in Fig.19 > > This example lists a firewall-condition with no src-target, which is > mandatory. > > > > employees > > > > Under condition, there is a container rate-limit with a leaf > packet-per-second. > Is this a trigger value for the condition, or is it an actual limit that > the > system is expected to enforce? If it's a trigger, it may be good to find a > clearer name. If it's enforced, it's placement under condition is > deceiving. > > If a rule's action is set to 'rate-limit', to which rate will it be > limited? > > 24. Security Considerations > > Section 10 in the NSF document under review is the Security > Considerations. I > think it would make sense to mention something about the management access > control mechanism here, and its relation to NACM. > > (End of list) > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --00000000000080c30005a29b5a4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
Thanks for your kind guidelines.
I will follow your suggestions for our I2NSF YANG drafts.
=

Best Regards,
Paul

=
On Mon= , Apr 6, 2020 at 5:46 PM tom petch <daedulus@btconnect.com> wrote:
Paul, another tangential suggestion, posting he= re because I am not on the I2NSF list (and my ESP will not let me subscribe= to it:-(, one which is general to other I2NSF I-D; move the Examples to an= Appendix.=C2=A0 The logic is that by convention, Appendices are Informativ= e while the rest of the I-D is Normative and if you want it different, then= that is normally explicitly spelt out.=C2=A0 Examples are commonly Informa= tive which fits with placing them in an Appendix.=C2=A0 If you want to keep= them in Section 9, and do not want them to be seen as Normative, then I su= ggest adding a note 'This section is Informative' to the start of s= ection 9.
HTH, tom petch

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/


----- Original Message -----
From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>
Sent: 03/04/2020 05:18:05


Hi Tom,
Thanks for your good suggestions.


I will reflect your comments on the revision.


Best Regards,
Paul


On Thu, Apr 2, 2020 at 8:46 PM tom petch <daedulus@btconnect.com> wrote:


---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/

Paul

At a tangent to Jan's comprehensive review, you have plenty of YANG ref= erence clauses which is good, but the RFC you reference must then appear as= Normative References in the I-D.

I see RFC
=C2=A0854
=C2=A0913
1081
1631
2579
2616
2818
3339
4250
5321
and
draft-ietf-sdn-ipsec-...
all of which need adding

On a different tack, I think that the choice of=C2=A0 prefix is unfortunate= .=C2=A0
capability uses nsfcap
registration uses nsfreg
This should use nsf.... perhaps nsfcon or nsfcfi ...
HTH

Tom Petch
----- Original Message -----
From: Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>
To: Jan Lindblad <j= anl@tail-f.com>
Cc: <draft-ietf-i2nsf-consumer-facing-interface-dm.= all@ietf.org>, <i2nsf@ietf.org>, <last-call@ietf.org>, YANG Doctors <yang-doctors@ietf.org>, skk= u-iotlab-members <skku-iotlab-members@googlegroups.com>, Mr. Jaeho= on Paul Jeong <jaehoon.paul@gmail.com>
Sent: 18/03/2020 17:41:41
Subject: Re: [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf= -i2nsf-consumer-facing-interface-dm-07
___________________________________________________________________________= _____


Hi Jan,
Could you update the state of YANGDOCTORS Last Call Review on
I2NSF Consumer-Facing Interface YANG Data Model=C2=A0 if the updates are fi= ne to you?

https://datatracker.i= etf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/

I think your comments are all addressed in this version.

Thanks.

Best Regards,
Paul



On Thu, Mar 12, 2020 at 1:15 AM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> = wrote:

Hi Jan,
We authors have addressed your comments with the revision:
https://tools.ietf.org/h= tml/draft-ietf-i2nsf-consumer-facing-interface-dm-08

I attach a revision letter to explain how to respond to your comments.

If you have further comments, please let me know.

Thanks.

Best Regards,
Paul



On Tue, Nov 12, 2019 at 1:53 AM Jan Lindblad via Datatracker <noreply@ietf.org> wrote:=

Reviewer: Jan Lindblad
Review result: Almost Ready

This is my YD review of draft-ietf-i2nsf-consumer-facing-interface-dm-07. I=
have previously reviewed the -05 revision (~end June). I find the new revis= ion
much improved, but still with much to discuss. I will call this "almos= t ready".

Generally speaking, I think the YANG module lacks the precision and
descriptions needed to foster interoperability. The examples at the end are=
very enlightening however, and compensate for much of that, but their infor= mal
nature can never replace proper YANG. The module usage needs to be mostly c= lear
from the module itself.

The management access control model proposed here is, even with its latest<= br> adaptation towards NACM, is still quite different from NACM author's or= iginal
ideas. I will therefore bring this use case up in the NETMOD WG for discuss= ion.

1. Network access control principles

Network access control is about which users are able to use the network bei= ng
managed, for example connect to facebook. The purpose of the NSF module is = to
control this access. This version of the YANG module is now based on a list= of
policies.

Each policy has a list of rules. Each rule has an event -- condition -- act= ion
triplet. This resembles traditional firewall management, which is a good th= ing,
because that concept is stable and much tried. This allows operators to cre= ate
lists of rules in this style:

if pkt.x =3D=3D 1: drop=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0// Rule 1
elif pkt.y > 2: alert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0// Rule 2
elif pkt.z =3D=3D 10: pass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Rule 3
else: drop=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 // Rule 4

This pattern relies heavily on the ability to control the order of the rule= s.
The current model relies on the alphabetical sorting of names rules for the=
ordering. The YANG trick I would recommend to give operators the ability to=
insert and move rules as they wish is to add ordered-by user on the list:
=C2=A0 =C2=A0 list rule {
=C2=A0 =C2=A0 =C2=A0 ordered-by user;=C2=A0 // <=3D=3D Add this line
=C2=A0 =C2=A0 =C2=A0 leaf rule-name {

Nothing is said about what the system should do in case policies conflict. = What
if one policy says pass, the other drop for the same packet? Please clarify= ..
What should happen to packets that do not match any of the policies?

This module also assumes that all users in the operator's organization = are
listed in one or more NACM groups (e.g. "employees"). That wasn&#= 39;t really the
NACM authors' original intent. Even if this could be made to work maybe= , there
is no strong reason to repurpose the NACM group concept for user network ac= cess
purposes. It could easily be modeled differently. So in the cases where the= re
are leafrefs to NACM groups when dealing with network access rather than management access, don't use NACM groups.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf src-target { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path = /nacm:nacm/nacm:groups/nacm:group/nacm:user-name;=C2=A0 //
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= =3D=3D Point to some other list of network users

2. Management access control principles

Management access control is about which users are able to configure/run actions/the policies and rules. IMO, the most controversial aspect of this<= br> module has always been its new and creative management access control model= .. In
this revision, the management principles have been remodeled greatly to fit= in
with NACM. I find this redesign very promising, but the result is still not=
quite ready for publication.

The point where integration with NACM concepts is important is when it come= s to
allow some users to CRUD the NSF policies and rules themselves. There is no= w a
leaf-list "owners" on each policy and rule which point to a list = of NACM
groups. My understanding is that the idea is that the NSF module should be = seen
as a service model that translate high level ownership information to speci= fic
NACM rules. It would be good to mention these ideas somewhere in the NSF document.

=C2=A0 leaf-list owners {
=C2=A0 =C2=A0 type leafref {
=C2=A0 =C2=A0 =C2=A0 path /nacm:nacm/nacm:groups/nacm:group/nacm:name;

I expect the intent is that any user listed in a NACM group mentioned in th= e
owners list would get full CRUD privileges for the contents of the rule the=
owners leaf sits on. That is never spelled out anywhere, however.

It is a little less clear how leaf-list owners on policy objects should be<= br> handled. Should owners listed on a policy object get full CRUD powers over = the
entire policy, including all the rules inside? Or would they need to be lis= ted
on the rules as well? Not clear. Is the intent that users not listed on the=
policy object are unable to create new rules, but to be able to update rule= s
they are listed as owners of, if any?

Who is allowed to create new policy objects? Should users that are not owne= rs
get read access to all the policies and rules?

Finally, there is an "owner" leaf on each rule with an identityre= f allowing
operators to configure a role name like dept-head or sec-admin. It is marke= d
mandatory, but never included in any of the examples at the end of the
document. This makes me think this may be a remnant from bygone times and should be removed from the YANG. If not, an explanation of how to use this<= br> leaf, and how it interacts with "owners" needs to be added, and t= he examples
updated.

3. leafrefs crosspointing between policy instances

There are six leafrefs that point to various objects inside a policy, e.g. = a
rule condition pointing to a device group name. None of them restrict what = can
be pointed to so that only names within the current policy are valid. It is=
therefore possible to configure the name of a device group defined in a
different policy. I suspect this is not the intention. In order to restrict= the
leafrefs to the same policy, the following predicate can be added:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list src-targe= t {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "/i2nsf= -cfi-policy[policy-name=3Dcurrent()/../../../../../policy-name]/endpoint-gr= oup/device-group/name";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// <= ;=3D=3D Add predicate

4. Mandatory to implement all events, conditions, actions

Each rule is defined with a choice of different events (admin, time),
conditions (firewall, ddos, custom, threat-feed) and actions (pass, drop, alert, mirror, ...). Is the intent that all of these options should be
mandatory to implement? The current model requires this. Also, would it mak= e
sense to allow additional mechanisms here? If so, it may be good to explain= to
readers how the set of choices and identities can be extended by
implementations.

5. Optional and mandatory elements

In this revision of the module, 8 leafs have been marked mandatory. A few o= f
them are list keys, which are conventionally not marked mandatory, since li= st
keys are always mandatory. A few others are skipped in the XML examples at = the
end of the NSF document, which makes me believe they might not really be mandatory after all.

Three leafs have a default, but most leafs are left optional without any default. In many cases I think I understand what it means to not set a leaf= ,
but with the ones listed here, I don't think it clear at all. Either ad= d a
default to make it clear, make them mandatory if they should be, or explain= in
the leaf description what happens if not set.

493: leaf-list name
513: leaf-list protocol
531: leaf geo-ip-ipv4
541: leaf continent
562: leaf feed-server-ipv4
585: leaf payload-description
590: leaf-list content
600: leaf-list owners
870: leaf method

6. Indentation

The YANG indentation is mostly wrong. Run the YANG text through pyang or so= me
other tool that can indent the content correctly before you put it into a document.

7. YANG element naming

The YANG convention is to not have lists on the top level in the YANG modul= e,
but to surround lists with a container. The surrounding container often has= a
name in the plural and the list in singluar, like this

container interfaces {
=C2=A0 =C2=A0 list interface {

To better fit into the world of IETF YANG modules, I'd recommend turnin= g the
top level list i2nsf-cfi-policy into this instead:

container i2nsf-cfi-policies {
=C2=A0 =C2=A0 list policy {

Further down, I would change container rule to rules:

container rules {
=C2=A0 =C2=A0 list rule {

Finally, it is customary to not repeat the names of parent object in the na= mes
of elements. For example, in the following:

list threat-feed-list
=C2=A0 =C2=A0 leaf feed-name
=C2=A0 =C2=A0 leaf feed-server-ipv4
=C2=A0 =C2=A0 leaf feed-server-ipv6
=C2=A0 =C2=A0 leaf feed-description

all the leafs should normally not repeat "feed-". Just leaf name,= leaf
server-ipv4, leaf server-ipv6, leaf description. There are many more exampl= es
of this throughout the module.

The condition choice has many containers with a single leaf inside (e.g. ddos-source). Their purpose is rather unclear to me. Remove?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container ddos-source { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This represen= ts the source.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list src-targe= t {

Also, I find the name "src-target" rather confusing. How about &q= uot;source"?

8. No date leaf

The draft text near fig 2 talks about a date leaf. There is no date object = in
this revision of te YANG.

"Date:=C2=A0 Date when this object was created or last modified"<= br>
9. leaf owner

Near fig.3 leaf Owner is mentioned. Is this leaf still current?

"Owner: This field contains the onwer of the rule.=C2=A0 For example,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the person who created it, = and eligible for modifying it."

10. leaf packet-per-second

This is now modeled as uint16. Is this future proof? Many packet flows on t= he
internet exceed 64k pps.

11. container custon-source

Misspelled. Should be custom-source

12. identity ddos

Is ddos a malware file-type? This is not exactly in line with my intuition.=

13. identity protocol-type

There are other modules that already define protocol-types. Would it be wor= th
reusing one of them?

14. identity palo-alto

Is it a good IETF practice to list vendor names in modules? Can we consider=
this a protocol name? Is there perhaps an RFC/specification name for it tha= t we
could reference instead?

15. grouping ipsec-based-method

This grouping contains a list which allows listing none of, either of or bo= th
of ipsecike and ikeless. Are all valid configurations?

16. leaf feed-name

This leaf is the key in a list, which makes it possible to have at most one=
feed of each type. If it would make sense to configure more than one feed o= f
the same type, the YANG needs to be updated here.

17. leaf-list content

This leaflist is of type string. What is the format of this string? Does th= e
name refer to something?

18. Event types

container event has a choice between enforce-admin and time alternatives. E= ach
of those choices have a leaf that allows the operator to configure an
identityref to an enforce-type value. What does that mean? What would it me= an
if an operator configured admin =3D=3D 'time' (or enforce-time =3D= =3D 'admin')?

19. leaf begin-time, end-time

>From the examples, it can be seen that these are meant to be a time of = day
values. Currently they are modeled as yang:date-and-time, which means they = are
a concrete time a specific day, e.g. 2019-11-11T16:07. This needs to be cha= nged
in order to be what the modeler intended. Perhaps like this:

typedef time-of-day {
=C2=A0 =C2=A0 type string {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pattern '(2[0-3]|[01]?[0-9]):[0-5][0-9]'= ;;
=C2=A0 =C2=A0 }
}

20. leaf frequency

This leaf is now modeled properly from a YANG perspective. But what does it=
mean? If this leaf is set to 'once-only', what exactly will happen = only once?
Please write a description that explains this.

21. Example in Fig.17

The example contains XML that refers to "endpoint-group/user-group&quo= t;. There is
no such element in the YANG.

<endpoint-group xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-i2nsf-cfi= -policy">
=C2=A0 <user-group>

Furthermore, there is nothing called range-ip-address, start-ip-address, end-ip-address. They are called range-ipv4-address, start-ipv4-address,
end-ipv4-address.

=C2=A0 =C2=A0 <range-ip-address>
=C2=A0 =C2=A0 =C2=A0 <start-ip-address>221.159.112.1</start-ip-add= ress>
=C2=A0 =C2=A0 =C2=A0 <end-ip-address>221.159.112.90</end-ip-addres= s>
=C2=A0 =C2=A0 </range-ip-address>

Finally, there must not be any xmlns attribute on an closing XML tag. So
</endpoint-group xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-i2nsf-cf= i-policy">

should be

</endpoint-group>

This happens in several of the examples.

22. Example in Fig.18

There is no element called policy any more. It's now i2nsf-cfi-policy.<= br>
=C2=A0 =C2=A0<policy xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-i2ns= f-cfi-policy">
=C2=A0 =C2=A0 =C2=A0<policy-name>security_policy_for_blocking_sns<= /policy-name>

The rules are modeled in a container and list, both by the name rule. So th= ere
needs to be two <rule> tags.

=C2=A0 =C2=A0 =C2=A0<rule>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<rule-name>block_access_to_sns_during_offi= ce_hours</rule-name>

The security-event element is marked mandatory in the YANG, but missing in = the
example. The times given below may be what is intended, but do not match th= e
date format for the type used (which include a date, etc).

=C2=A0 =C2=A0 =C2=A0 =C2=A0<event>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<time-information>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<begin-time>09:00</begin-= time>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<end-time>18:00</end-time= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</time-information>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</event>

Since the example is not mentioning leaf frequency, it will have the value<= br> 'once-only'. Maybe explain what that means in the context of the ex= ample?

The condition/firewall-condition says the src-target is mandatory and
dest-target optional, exactly like below.
condition/custom-destination/dest-target is mandatory and src-target is
optional, exactly like below. Is this pure luck, or is there a logical
explanation why exactly those should be mandatory, and the example use
precisely those?

=C2=A0 =C2=A0 =C2=A0 =C2=A0<condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<firewall-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<source-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<src-target>employees= </src-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</source-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</firewall-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<custom-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<destination-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dest-target>sns-webs= ites</dest-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</destination-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</custom-condition>

The current YANG model does not allow setting both a firewall-condition and=
custom-condition. If that should be allowed, the model needs to change. Sho= uld
it be possible to have multiple firewall- or other conditions? That is not<= br> currently possible.

This example leaves out the mandatory leaf owner. Is that a sign that it sh= ould
not be mandatory, or perhaps not exist at all?

23. Example in Fig.19

This example lists a firewall-condition with no src-target, which is mandat= ory.

=C2=A0 =C2=A0 =C2=A0 <firewall-condition>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <destination-target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dest-target>employees</dest-ta= rget>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </destination-target>
=C2=A0 =C2=A0 =C2=A0 </firewall-condition>

Under condition, there is a container rate-limit with a leaf packet-per-sec= ond.
Is this a trigger value for the condition, or is it an actual limit that th= e
system is expected to enforce? If it's a trigger, it may be good to fin= d a
clearer name. If it's enforced, it's placement under condition is d= eceiving.

If a rule's action is set to 'rate-limit', to which rate will i= t be limited?

24. Security Considerations

Section 10 in the NSF document under review is the Security Considerations.= I
think it would make sense to mention something about the management access<= br> control mechanism here, and its relation to NACM.

(End of list)


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf





--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php





--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php





--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeh= oon-jeong.php


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.= D.
Associate Professor
Department of Software
Sungkyunkwan Univers= ity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeon= g@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeho= on-jeong.php
--00000000000080c30005a29b5a4b-- From nobody Wed Apr 8 16:33:55 2020 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1753A1A29; Wed, 8 Apr 2020 16:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=gw/xsEnr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rpzH8w5L 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 3wzfSt7PX79c; Wed, 8 Apr 2020 16:33:39 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC143A19FC; Wed, 8 Apr 2020 16:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=106065; q=dns/txt; s=iport; t=1586388818; x=1587598418; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jucy26ghmmb8INJi+tzBV4ccag4Ta5XYotwDysUjkV4=; b=gw/xsEnrnZ5Ay+lSyr4nP43a5AA9csxZyWRPdrxrLSdxnWREQv0dMODg QLFiHxWSTz22LLNfMP1rCjlZYVOYIMI+YDqQlxmdCiDf04XOnO0Y5gAmS Y7KqP0WYD7w7IF17yJxQcXauDnFXHn+m+8Yo0rM4sqkfzFoHqqTutNXtg E=; IronPort-PHdr: =?us-ascii?q?9a23=3AiYadURfL1auXV7zKlO2Yim9MlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBwBXXo5e/4QNJK1MEAEJHAEBAQE?= =?us-ascii?q?BBwEBEQEEBAEBgXuBJS9QBWxYIAQLKgqEEoNFA4pqgl+JcI4wgUKBEANQBAo?= =?us-ascii?q?BAQEMAQEYAQ4GAgQBAYFQgT6BNgIXgXAkOBMCAwEBCwEBBQEBAQIBBQRthVY?= =?us-ascii?q?MhXABAQEBAwEBEAgBCAQZAQEpAwsBDQICAQgRAwECIQEGAwICAhQLBgsUCQg?= =?us-ascii?q?CBA4FHwODBAGBfk0DLgEOPKUhAoE5iGJ1fzOCfwEBBYEvAQMCAQsCQAGDSA0?= =?us-ascii?q?Lgg0JBYEzjDMagUE/gREnHIIfLj6CHkkBAQEBAQGBJAgBBwEDAQYBOAkNCYJ?= =?us-ascii?q?cMoIKIo4AIIJthgUkhzOCZY4KOCoySAqCPYd1hV6FJQSEOR2CToEEhzaBDY9?= =?us-ascii?q?zkQ+FUoIDgj2QRgIEAgQFAg4BAQWBPyoiKj1wcBU7KgGCPglHGA2QfiQ4gzt?= =?us-ascii?q?qhCqFQXQCgSeLZgEBJgeBBAGBDwEB?= X-IronPort-AV: E=Sophos;i="5.72,360,1580774400"; d="scan'208,217";a="469839502" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2020 23:33:36 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 038NXaCh006889 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Apr 2020 23:33:36 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 18:33:36 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Apr 2020 19:33:34 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Apr 2020 18:33:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WvHEP25yS4zPPLPIS2jWcZaazkE/XtRVoWsdj+umwREXqMhJEnOQ9bbKSq3pJ2/RSVWk3+J0JLEHfEG38Y4d5OAVrJIP3ia3rfKhnvlPggrFL95MzwbRGqVIidpyLFcs2j8W3WSKINuGd7BEpWMy+RyIlxByt+UjLxY5Ldi2Xz2TfqTlcIrhtpSOYCnKWn8OA5LbmbtxHWVfMWHXyD/ND/5Sfsb1DIQgv0ZffPrQROuyZ2CRet7qHCtxS3VrqXUfZ3oiZ3+koXldjRjHgUZm0WUkCbO6rrvMETT65EnIK7hdUqoGa67S+Hmeuz5qgBL8pdB9Ou68v9uU39A7pi+0Bw== 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=jucy26ghmmb8INJi+tzBV4ccag4Ta5XYotwDysUjkV4=; b=SrvXB2S6glzCyEilQPHCynYLvs35PKiGyiycGvb1BBBYRot9SVmX+kS4QKWBj4JcS57iJtstOx6Ag7S1DtweM4paE+qj1JUlPja6wZFDOjr5H9wRwUiiL7rxvpXio75VO4+T0lUJkyKRXLg6NSQEjqVZXGIWeZussTgvzJuZvwvLHvZAK9WWucxcaVgjc1oS+EnNmNCeByAWz1PjktpwtSE7OCDIoYtkRC0qDGDBNMJgxL023lbpTNlRxWQN9D9ldc108OzGbycXptLbK/6jH1DfpcTSNj1IyGciGWguzLrGaKIyyHWu9Azg+BXptjtOq8tWRuoWjjjvKc8A9YPX9w== 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=jucy26ghmmb8INJi+tzBV4ccag4Ta5XYotwDysUjkV4=; b=rpzH8w5LyzNW+L34JR0lq43ka7TOMcb8U8IYKWvSayy0y5vojJFkzaiMPyImlgCSt3ihb/NJzCPpb15nLK6e3nzESdysMeRTPQHW/T9iFVumQJlpGIPJ7WinQC2INBLMx/PGKUMAVJazd+MbyDFKebl0WnSleswWGCcs4T5IhhQ= Received: from BN6PR11MB1748.namprd11.prod.outlook.com (2603:10b6:404:101::12) by BN6PR11MB1393.namprd11.prod.outlook.com (2603:10b6:404:3c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr 2020 23:33:32 +0000 Received: from BN6PR11MB1748.namprd11.prod.outlook.com ([fe80::d1f9:733e:e200:f972]) by BN6PR11MB1748.namprd11.prod.outlook.com ([fe80::d1f9:733e:e200:f972%6]) with mapi id 15.20.2878.021; Wed, 8 Apr 2020 23:33:32 +0000 From: "Reshad Rahman (rrahman)" To: "Mr. Jaehoon Paul Jeong" CC: YANG Doctors , "i2nsf@ietf.org" , Sangwon Hyun , skku-iotlab-members Thread-Topic: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-registration-interface-dm-04 Thread-Index: AQHVQvTAkkfTX09q5USrQyd4LCPXc6d+Bl8AgAiCPgCAb4ewAIAObmKAgAzG1ACAAIR/gIAABJWAgADsOgCALslXAP//3POAgB3nyYCAA4DtAIAOaWgA Date: Wed, 8 Apr 2020 23:33:31 +0000 Message-ID: <936E09CA-B9EA-4C1C-B6D9-14723BC2F1EA@cisco.com> References: <156175664267.21931.10329030969352120108@ietfa.amsl.com> <47E6993E-1045-4B29-B814-E7185516B272@cisco.com> <9B0042BE-DF30-4EAD-9B7F-5E4FB196F980@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [70.31.50.95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b219fa26-6f78-45f1-cfaa-08d7dc154007 x-ms-traffictypediagnostic: BN6PR11MB1393:|BN6PR11MB1393: x-microsoft-antispam-prvs: x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1748.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(376002)(39860400002)(36756003)(16799955002)(81156014)(71200400001)(15188155005)(6512007)(186003)(2906002)(5660300002)(30864003)(107886003)(26005)(81166007)(6506007)(64756008)(9326002)(2616005)(316002)(6486002)(8936002)(8676002)(66446008)(53546011)(66556008)(6916009)(478600001)(91956017)(54906003)(76116006)(66946007)(86362001)(66476007)(4326008)(33656002)(966005)(559001)(579004); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bN9mEY3C7UWExKsyksPfjX7D4NGaxJ0xKoavMiX63I5vhCrXdp543gtLajZfwaXfOliweS+7Qs2z2zH5no51TMlFkqNUp+R709oPnVIW0KLS4SImxwoepTVkYBjxp5MNZYkCQBP3tgH/qEuwQboHU3js9UnAAJH+XAFqmPLXWK5lk7luZ6TWGlsIENmaS8YHGrRemr8f67tPDIUGqXcwp6vF7aQtVtVn6Nu1du+8ENjNsQkHxJWwHkegL7JhOJd8OSBOIwFQx6DGAzh3H/JaTVSccveiNED3ruMSSVsXbm+VtQLwQubUONNp5VKoAcdPlR33X070lEU0GMb9oVgmegTy8d/EM/qikOa9A7zmNWzJd4x1LesysAA/L6U/eRzs6DdNC+CWBzpSR9I+d+oRiyH1Hc0yCix+p7GQrSKG2737B0rQZs6oXOqFhaJqKa3NkqIsZi146MNDl8zXb5Q0qsbWoOjjmbUH4ny/Lyf+EEQkfTJRWwM8fEd8I4F0gWYYZ55N0DnmHdPPrASVWo4Vhg== x-ms-exchange-antispam-messagedata: SHowJyPIhURYhV3d//wvGw+Vm0Roez5+Jm2Lrr0HwqLLEd5QwLROt8dxHaD4Xhc/vdBZTR6oHnKb56LWofkEdH4kCACJwQe6ckX0E9hlFXCrqbAFvHi459iL9hztej9r8h6trcL1LZE1phmoprK1ZQ== Content-Type: multipart/alternative; boundary="_000_936E09CAB9EA4C1CB6D914723BC2F1EAciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b219fa26-6f78-45f1-cfaa-08d7dc154007 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 23:33:32.0663 (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: 3pzn74Hl3f5wH6XEkapzjl2lVaw47PKfxkHgP9Tt5If1A/p4Y4mVi2fNr8jFY5+Yav8n90xt6C++xxSkJiiphg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1393 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-registration-interface-dm-04 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 23:33:49 -0000 --_000_936E09CAB9EA4C1CB6D914723BC2F1EAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KVGhlIFlBTkcgcmV2aWV3IHJlc3VsdCBoYXMgYmVlbiB1cGRhdGVkIGluIGRh dGF0cmFja2VyPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJu c2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS8+Lg0KDQpSZWdhcmRpbmcg4oCcdXNlIG9mIGNs b2NrIHNwZWVkIHRvIGlkZW50aWZ5IHBlcmZvcm1hbmNl4oCdLCBJ4oCZbGwgbGVhdmUgdGhpcyB0 byB0aGUgV0cuDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCkZyb206ICJNci4gSmFlaG9vbiBQYXVs IEplb25nIiA8amFlaG9vbi5wYXVsQGdtYWlsLmNvbT4NCkRhdGU6IE1vbmRheSwgTWFyY2ggMzAs IDIwMjAgYXQgMTE6MjkgQU0NClRvOiAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFu QGNpc2NvLmNvbT4NCkNjOiBZQU5HIERvY3RvcnMgPHlhbmctZG9jdG9yc0BpZXRmLm9yZz4sICJp Mm5zZkBpZXRmLm9yZyIgPGkybnNmQGlldGYub3JnPiwgU2FuZ3dvbiBIeXVuIDxzd2h5dW43N0Bn bWFpbC5jb20+LCBza2t1LWlvdGxhYi1tZW1iZXJzIDxza2t1LWlvdGxhYi1tZW1iZXJzQGdvb2ds ZWdyb3Vwcy5jb20+LCAiTXIuIEphZWhvb24gUGF1bCBKZW9uZyIgPGphZWhvb24ucGF1bEBnbWFp bC5jb20+DQpTdWJqZWN0OiBSZTogW0kybnNmXSBZYW5nZG9jdG9ycyBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNA0KDQpIaSBS ZXNoYWQsDQpJIGhhdmUgcmVmbGVjdGVkIHlvdXIgZm91ciBjb21tZW50cyBvbiAtMDggdmVyc2lv bjoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJh dGlvbi1pbnRlcmZhY2UtZG0tMDgNCg0KICAgVGhlIGZvbGxvd2luZyBjaGFuZ2VzIGhhdmUgYmVl biBtYWRlIGZyb20gZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA3 Og0KDQogICBvICBkcmFmdC1pZXRmLWkybnNmLWNhcGFiaWxpdHktZGF0YS1tb2RlbCBpcyBjaXRl ZCBhcyBhIG5vcm1hdGl2ZQ0KICAgICAgcmVmZXJlbmNlIGFjY29yZGluZyB0byB0aGUgZ3VpZGVs aW5lIGF0DQogICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQwNyNzZWN0aW9u LTMuOQ0KDQogICBvICBGb3IgdGhlIHJlZmVyZW5jZXMgdG8gZHJhZnQtaWV0Zi1pMm5zZi1jYXBh YmlsaXR5LWRhdGEtbW9kZWwgaW4NCiAgICAgIHRoZSBZQU5HIG1vZGVsLCB0aGV5IGFyZSBxdWFs aWZpZWQgd2l0aCBhIG5vdGUgdG8gdGhlIGVkaXRvciB0aGF0DQogICAgICB0aGUgZHJhZnQgd2ls bCBiZWNvbWUgYW4gUkZDLCBzbyB0aGUgYWN0dWFsIFJGQyBudW1iZXIgb2YgdGhlDQogICAgICBk cmFmdCBuZWVkcyB0byBiZSB1c2VkLg0KDQogICBvICBUaGUgZWRpdG9yJ3Mgbm90ZXMgYXJlIHB1 dCB0byByZXF1ZXN0IHRvIHJlcGxhY2UgWFhYWCB3aXRoIHRoZQ0KICAgICAgYWN0dWFsIFJGQyBu dW1iZXIgb2YgdGhpcyBkb2N1bWVudCAoaS5lLiwgZHJhZnQtaWV0Zi1pMm5zZi0NCiAgICAgIHJl Z2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0pIHdoZW4gdGhlIGRvY3VtZW50IGlzIHB1Ymxpc2hlZC4N Cg0KICAgbyAgTGVhZiBub2RlcyAoaS5lLiwgcHJvY2Vzc2luZy1hdmVyYWdlIGFuZCBwcm9jZXNz aW5nLXBlYWspIHVuZGVyDQogICAgICBjb250YWluZXIgcHJvY2Vzc2luZyBoYXZlIHVuaXQgR0h6 IGV4cGxpY2l0bHkgd2l0aCB1bml0cyAiR0h6Ii4NCg0KQ291bGQgeW91IGNoZWNrIGl0IGFuZCBt b3ZlIGl0IGZvcndhcmQ/DQoNClRoYW5rcy4NCg0KQmVzdCBSZWdhcmRzLA0KUGF1bA0KDQpPbiBT YXQsIE1hciAyOCwgMjAyMCBhdCA2OjU4IFBNIE1yLiBKYWVob29uIFBhdWwgSmVvbmcgPGphZWhv b24ucGF1bEBnbWFpbC5jb208bWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20+PiB3cm90ZToN CkhpIFJlc2hhZCwNCkkgd2lsbCByZWZsZWN0IHlvdXIgY29tbWVudHMgb24gdGhlIHJldmlzaW9u Lg0KDQpUaGFua3MuDQoNCkJlc3QgUmVnYXJkcywNClBhdWwNCg0KDQpPbiBXZWQsIE1hciAyNSwg MjAyMCBhdCAzOjI4IEFNIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIDxycmFobWFuQGNpc2NvLmNv bTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+PiB3cm90ZToNCkhpIFBhdWwsDQoNCkFwb2xvZ2ll cyBmb3IgdGhlIGRlbGF5LiBJIHRvb2sgYSBsb29rIGF0IHJldi0wNyBhbmQgaGVyZSBhcmUgc29t ZSB0aGluZ3Mgd2hpY2ggSSBtaXNzZWQgaW4gcHJldmlvdXMgcmV2aWV3czoNCg0KDQogIDEuICBk cmFmdC1pZXRmLWkybnNmLWNhcGFiaWxpdHktZGF0YS1tb2RlbCBpcyBhbiBpbmZvcm1hdGl2ZSBy ZWZlcmVuY2UsIGl0IHNob3VsZCBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgYXMgcGVyIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDA3I3NlY3Rpb24tMy45DQogIDIuICBUaGVyZSBh cmUgcmVmZXJlbmNlcyB0byBkcmFmdC1pZXRmLWkybnNmLWNhcGFiaWxpdHktZGF0YS1tb2RlbCBp biB0aGUgWUFORyBtb2RlbCB3aGljaCBzaG91bGQgYmUgcXVhbGlmaWVkIHdpdGggYSBub3RlIHRv IHRoZSBlZGl0b3IgKHRoYXQgZHJhZnQgd2lsbCBiZWNvbWUgYW4gUkZDKS4gQXMgYW4gZXhhbXBs ZSBzZWFyY2ggZm9yIFlZWVkgaW4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1i ZmQteWFuZy0xNy50eHQNCg0KMy4gICAgICAgVGhlIGVkaXRvcuKAmXMgbm90ZSBzaG91bGQgYWxz byByZXF1ZXN0IHRvIGNoYW5nZSBYWFhYIHRvIGFjdHVhbCBSRkMgbnVtYmVyIHdoZW4gdGhlIGRv Y3VtZW50IGlzIHB1Ymxpc2hlZC4NCg0KICAxLiAgTGVhZiBub2RlcyB1bmRlciBjb250YWluZXIg cHJvY2Vzc2luZyBzaG91bGQgaGF2ZSB1bml0IEdIei4gT24gdGhpcyBub3RlLCBJ4oCZbSBub3Qg c3VyZSBob3cgY2xvY2sgc3BlZWQgdW5pcXVlbHkgaWRlbnRpZmllcyBwZXJmb3JtYW5jZSwgYnV0 IEkgd29u4oCZdCBwcmV0ZW5kIHRvIGJlIGFuIGV4cGVydCBpbiB0aGUgYXJlYS4gSU1PIHRoaXMg aXMgc29tZXRoaW5nIHRoZSBXRyBzaG91bGQgY29tbWVudCBvbi4NCg0KUmVnYXJkcywNClJlc2hh ZC4NCg0KRnJvbTogIk1yLiBKYWVob29uIFBhdWwgSmVvbmciIDxqYWVob29uLnBhdWxAZ21haWwu Y29tPG1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tPj4NCkRhdGU6IE1vbmRheSwgTWFyY2gg OSwgMjAyMCBhdCA3OjIzIEFNDQpUbzogIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1h bkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPj4NCkNjOiBZQU5HIERvY3RvcnMg PHlhbmctZG9jdG9yc0BpZXRmLm9yZzxtYWlsdG86eWFuZy1kb2N0b3JzQGlldGYub3JnPj4sICJp Mm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+IiA8aTJuc2ZAaWV0Zi5vcmc8bWFp bHRvOmkybnNmQGlldGYub3JnPj4sIFNhbmd3b24gSHl1biA8c3doeXVuNzdAZ21haWwuY29tPG1h aWx0bzpzd2h5dW43N0BnbWFpbC5jb20+Piwgc2trdS1pb3RsYWItbWVtYmVycyA8c2trdS1pb3Rs YWItbWVtYmVyc0Bnb29nbGVncm91cHMuY29tPG1haWx0bzpza2t1LWlvdGxhYi1tZW1iZXJzQGdv b2dsZWdyb3Vwcy5jb20+PiwgIk1yLiBKYWVob29uIFBhdWwgSmVvbmciIDxqYWVob29uLnBhdWxA Z21haWwuY29tPG1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tPj4NClN1YmplY3Q6IFJlOiBb STJuc2ZdIFlhbmdkb2N0b3JzIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pMm5zZi1y ZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA0DQoNCkhpIFJlc2hhZCwNCldlIGF1dGhvcnMgaGF2 ZSBhZGRyZXNzZWQgeW91ciBjb21tZW50cyBpbiB0aGUgcmV2aXNpb246DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRt LTA3DQoNCkkgYXR0YWNoIHRoZSByZXZpc2lvbiBsZXR0ZXIgZm9yIHlvdXIgZWFzeSBjaGVja3Vw Lg0KDQpPbmNlIHlvdXIgY29tbWVudHMgYXJlIGFkZHJlc3NlZCB3ZWxsLCBwbGVhc2UgdXBkYXRl IHRoZSBZQU5HIHJldmlldyByZXN1bHQ6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0vDQoNClRoYW5rcyBm b3IgeW91ciB2YWx1YWJsZSBoZWxwLg0KDQpCZXN0IFJlZ2FyZHMsDQpQYXVsDQoNCg0KT24gU3Vu LCBGZWIgOSwgMjAyMCBhdCA2OjU0IEFNIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIDxycmFobWFu QGNpc2NvLmNvbTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+PiB3cm90ZToNCkhpLA0KDQpHb2lu ZyBiYWNrIHRvIHRoaXMgY29tbWVudCBvbiByZXYtMDU6DQotIEFiaWRlIGJ5IG9yZGVyIGluIFJG Qzg0MDcgQXBwZW5kaXggQi4gZS5nLiBSUEMgc3RhdGVtZW50cyBzaG91bGQgYmUgYWZ0ZXIgZ3Jv dXBpbmdzLg0KVGhlIG9ubHkgdGhpbmcgd2hpY2ggc2VlbXMgdG8gaGF2ZSBiZWVuIGZpeGVkIGlz IHRoYXQgdGhlIFJQQyBzdGF0ZW1lbnQgd2FzIHB1dCBhZnRlciBncm91cGluZ3MuIEJ1dCB5b3Ug c2hvdWxkIGxvb2sgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDcjcGFnZS02 MToNCg0KICAgICAvLyBleHRlbnNpb24gc3RhdGVtZW50cw0KDQogICAgIC8vIGZlYXR1cmUgc3Rh dGVtZW50cw0KDQogICAgIC8vIGlkZW50aXR5IHN0YXRlbWVudHMNCg0KICAgICAvLyB0eXBlZGVm IHN0YXRlbWVudHMNCg0KICAgICAvLyBncm91cGluZyBzdGF0ZW1lbnRzDQoNCiAgICAgLy8gZGF0 YSBkZWZpbml0aW9uIHN0YXRlbWVudHMNCg0KICAgICAvLyBhdWdtZW50IHN0YXRlbWVudHMNCg0K ICAgICAvLyBycGMgc3RhdGVtZW50cw0KDQogICAgIC8vIG5vdGlmaWNhdGlvbiBzdGF0ZW1lbnRz DQoNCiAgICAgLy8gRE8gTk9UIHB1dCBkZXZpYXRpb24gc3RhdGVtZW50cyBpbiBhIHB1Ymxpc2hl ZCBtb2R1bGUNCg0KVGhhdCBtZWFucyB5b3VyIGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnRzIChj b250YWluZXIgbnNmLXJlZ2lzdHJhdGlvbnMpIHNob3VsZCBiZSBhZnRlciB0aGUgZ3JvdXBpbmdz Lg0KDQpBbHNvIHRoZSBpbmRlbnRhdGlvbiBzZWVtcyBvZmYgb24gdGhlIFlBTkcgbW9kdWxlIGlu IHNvbWUgcGxhY2VzLCBmb3IgZXhhbXBsZSBvbiBQMTQuDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoN Cg0KRnJvbTogIk1yLiBKYWVob29uIFBhdWwgSmVvbmciIDxqYWVob29uLnBhdWxAZ21haWwuY29t PG1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tPj4NCkRhdGU6IEZyaWRheSwgRmVicnVhcnkg NywgMjAyMCBhdCA5OjQ5IFBNDQpUbzogIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1h bkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPj4NCkNjOiBZQU5HIERvY3RvcnMg PHlhbmctZG9jdG9yc0BpZXRmLm9yZzxtYWlsdG86eWFuZy1kb2N0b3JzQGlldGYub3JnPj4sICJp Mm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+IiA8aTJuc2ZAaWV0Zi5vcmc8bWFp bHRvOmkybnNmQGlldGYub3JnPj4sIFNhbmd3b24gSHl1biA8c3doeXVuNzdAZ21haWwuY29tPG1h aWx0bzpzd2h5dW43N0BnbWFpbC5jb20+Piwgc2trdS1pb3RsYWItbWVtYmVycyA8c2trdS1pb3Rs YWItbWVtYmVyc0Bnb29nbGVncm91cHMuY29tPG1haWx0bzpza2t1LWlvdGxhYi1tZW1iZXJzQGdv b2dsZWdyb3Vwcy5jb20+Pg0KU3ViamVjdDogUmU6IFtJMm5zZl0gWWFuZ2RvY3RvcnMgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0t MDQNCg0KSGkgUmVzaGFkLA0KQ291bGQgeW91IHVwZGF0ZSB0aGUgcmV2aWV3IHN0YXR1cyBhcyBS RUFEWT8NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtaTJu c2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNC15YW5nZG9jdG9ycy1sYy1yYWhtYW4tMjAx OS0wNi0yOC8NCg0KVGhhbmtzLg0KDQpQYXVsDQoNCk9uIFNhdCwgRmViIDgsIDIwMjAgYXQgMTE6 MzIgQU0gTXIuIEphZWhvb24gUGF1bCBKZW9uZyA8amFlaG9vbi5wYXVsQGdtYWlsLmNvbTxtYWls dG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgUmVzaGFkLA0KVGhhbmtzIGZv ciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzIGFuZCBoZWxwLg0KDQpCZXN0IFJlZ2FyZHMsDQpQYXVs DQoNCk9uIFNhdCwgRmViIDgsIDIwMjAgYXQgODozOCBBTSBSZXNoYWQgUmFobWFuIChycmFobWFu KSA8cnJhaG1hbkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPj4gd3JvdGU6DQpI aSBQYXVsLA0KDQpJIGhhdmUgdmVyaWZpZWQgdGhhdCB5b3XigJl2ZSBhZGRyZXNzZWQgYWxsIGNv bW1lbnRzIHdoaWNoIHdlcmUgcHJvdmlkZWQgb24gMDUuDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoN CkZyb206ICJNci4gSmFlaG9vbiBQYXVsIEplb25nIiA8amFlaG9vbi5wYXVsQGdtYWlsLmNvbTxt YWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgSmFudWFyeSAz MCwgMjAyMCBhdCAxMDozMiBBTQ0KVG86ICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWht YW5AY2lzY28uY29tPG1haWx0bzpycmFobWFuQGNpc2NvLmNvbT4+DQpDYzogWUFORyBEb2N0b3Jz IDx5YW5nLWRvY3RvcnNAaWV0Zi5vcmc8bWFpbHRvOnlhbmctZG9jdG9yc0BpZXRmLm9yZz4+LCAi aTJuc2ZAaWV0Zi5vcmc8bWFpbHRvOmkybnNmQGlldGYub3JnPiIgPGkybnNmQGlldGYub3JnPG1h aWx0bzppMm5zZkBpZXRmLm9yZz4+LCBTYW5nd29uIEh5dW4gPHN3aHl1bjc3QGdtYWlsLmNvbTxt YWlsdG86c3doeXVuNzdAZ21haWwuY29tPj4sIHNra3UtaW90bGFiLW1lbWJlcnMgPHNra3UtaW90 bGFiLW1lbWJlcnNAZ29vZ2xlZ3JvdXBzLmNvbTxtYWlsdG86c2trdS1pb3RsYWItbWVtYmVyc0Bn b29nbGVncm91cHMuY29tPj4sIFBhdHJpY2sgTGluZ2dhIDxwYXRyaWNrbGluazg4OEBnbWFpbC5j b208bWFpbHRvOnBhdHJpY2tsaW5rODg4QGdtYWlsLmNvbT4+LCAiTXIuIEphZWhvb24gUGF1bCBK ZW9uZyIgPGphZWhvb24ucGF1bEBnbWFpbC5jb208bWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5j b20+Pg0KU3ViamVjdDogUmU6IFtJMm5zZl0gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBv ZiBkcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDQNCg0KUmVzaGFk LA0KQ291bGQgeW91IHJlc3BvbmQgdG8gbXkgcHJldmlvdXMgZW1haWwgYWJvdXQgdGhlIGxhdGVz dCByZXZpc2lvbiBvZiB0aGUgSTJOU0YgUmVnaXN0cmF0aW9uIEludGVyZmFjZSBZQU5GIERhdGEg TW9kZWwgZHJhZnQ/DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5z Zi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA2DQoNCklmIHlvdSBhcmUgc2F0aXNmaWVkIHdp dGggbXkgcmV2aXNpb24sIGNvdWxkIHlvdSB1cGRhdGUgdGhlIFlBTkcgRG9jdG9yJ3MgcmV2aWV3 IHJlc3VsdCBpbiB0aGUgZm9sbG93aW5nIGxpbms/DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9yZXZpZXctaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA0LXlh bmdkb2N0b3JzLWxjLXJhaG1hbi0yMDE5LTA2LTI4Lw0KDQpBZnRlciBnZXR0aW5nIHlvdXIgcmV2 aWV3IHVwZGF0ZSBzdGF0ZSwgSSBjYW4gYXNrIHRoZSBJMk5TRiBXRyBjaGFpcnMgdG8gbWFrZSB0 aGUgV0cgTGFzdCBDYWxsIG9uDQpvdXIgSTJOU0YgUmVnaXN0cmF0aW9uIEludGVyZmFjZSBkcmFm dC4NCg0KVGhhbmtzIGZvciB5b3VyIGVmZm9ydHMgYW5kIGhlbHAuDQoNCkJlc3QgUmVnYXJkcywN ClBhdWwNCg0KT24gVHVlLCBKYW4gMjEsIDIwMjAgYXQgODowOCBQTSBNci4gSmFlaG9vbiBQYXVs IEplb25nIDxqYWVob29uLnBhdWxAZ21haWwuY29tPG1haWx0bzpqYWVob29uLnBhdWxAZ21haWwu Y29tPj4gd3JvdGU6DQpIaSBSZXNoYWQsDQpXZSBhdXRob3JzIGhhdmUgYWRkcmVzc2VkIHlvdXIg Y29tbWVudHMgd2l0aCB0aGUgZm9sbG93aW5nIHJldmlzaW9uOg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNg0K DQpJIGF0dGFjaCB0aGUgcmV2aXNpb24gbGV0dGVyIHRvIHNob3cgaG93IHRvIGFkZHJlc3MgeW91 ciBjb21tZW50cy4NCg0KQ291bGQgeW91ciBjaGVjayB0aGlzIHJldmlzaW9uIGFuZCBwcm9jZWVk IHdpdGggdGhlIFlBTkcgcmV2aWV3IHVwZGF0ZT8NCg0KVGhhbmtzLg0KDQpCZXN0IFJlZ2FyZHMs DQpQYXVsDQoNCg0KT24gVHVlLCBOb3YgMTIsIDIwMTkgYXQgMTo1OCBBTSBSZXNoYWQgUmFobWFu IChycmFobWFuKSA8cnJhaG1hbkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPj4g d3JvdGU6DQpIaSBQYXVsLA0KDQpJIGhhdmUgZG9uZSBhbm90aGVyIHJldmlldyAoSSBkb27igJl0 IHRoaW5rIGFuIGF1dG9tYXRlZCBlbWFpbCBnb3Qgc2VudCBvdXQpLg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFj ZS1kbS0wNC15YW5nZG9jdG9ycy1sYy1yYWhtYW4tMjAxOS0wNi0yOC8NCg0KWUFORyBEb2N0b3Ig cmV2aWV3IG9mIGRyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNSAo YnkgUmVzaGFkIFJhaG1hbikNCg0KVGhhbmsgeW91IGZvciBhZGRyZXNzaW5nIGNvbW1lbnRzIGZy b20gbXkgZWFybGllciByZXZpZXcgQCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9y ZXZpZXctaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA0LXlhbmdkb2N0b3Jz LWxjLXJhaG1hbi0yMDE5LTA2LTI4Lw0KDQpNYWpvciBjb21tZW50cy9xdWVzdGlvbnM6DQotIFRo ZXJlIGlzIGEgWUFORyB3YXJuaW5nIG9uIHRoZSBkYXRhdHJhY2tlciBwYWdlOg0KaWV0Zi1pMm5z Zi1yZWctaW50ZXJmYWNlQDIwMTktMDctMjQueWFuZzo1NDogd2FybmluZzogUkZDIDg0MDc6IDMu MTogVGhlIElFVEYgVHJ1c3QgQ29weXJpZ2h0IHN0YXRlbWVudCBzZWVtcyB0byBiZSBtaXNzaW5n IChzZWUgcHlhbmcgLS1pZXRmLWhlbHAgZm9yIGRldGFpbHMpLg0KVG8gZml4IHRoaXMsIGluIHRo ZSBZQU5HIG1vZHVsZSByZW1vdmUgdGhlIDw+IGFyb3VuZCAyMDE5OiBDb3B5cmlnaHQgKGMpIDwy MDE5Pg0KDQotIEZvciBjb250YWN0IGluIFlBTkcgbW9kdWxlLCBwbGVhc2UgcmVtb3ZlIFdHIGNo YWlyIGluZm8gKHNlZSBSRkM4NDA3IGFwcGVuZGl4IEIgZm9yIGFuIGV4YW1wbGUpDQoNCi0gRm9y IHRoZSByZXZpc2lvbiBpbiBZQU5nIG1vZHVsZSwgcHV0ICJJbml0aWFsIHZlcnNpb24iIChldmVu IHRob3VnaCBpdCdzIHRoZSA1dGggcmV2aXNpb24pDQoNCi0gV2h5IGRlZmluZSBhIHVuaW9uIG9m IGlwdjQtYWRkcmVzcyBhbmQgaXB2Ni1hZGRyZXNzIGluIHR5cGVkZWYgbnNmLWFkZHJlc3MsIHdo eSBub3QgcmV1c2UgZXhpc3RpbmcgaXAtYWRkcmVzcyB0eXBlIGZyb20gUkZDNjAyMT8NCg0KLSBG b3IgYmFuZHdpZHRoLCBpcyB0aGVyZSBhIHJlYXNvbiB3aHkgaXQncyBsaW1pdGVkIHRvIHVpbnQx Nj8gRXZlbiB0aG91Z2ggNjVUYnBzIGlzIGEgbG90LCBJIHdvdWxkbid0IGxpbWl0IGl0IHRvIHVp bnQxNi4gQW5kIGFyZW4ndCB0aGVyZSBhbnkgdXNlLWNhc2VzIGZvciBiYW5kd2lkdGggc21hbGxl ciB0aGFuIDEgR2Jwcz8gSWYgeWVzLCB1c2UgZS5nIE1icHMgYXMgdW5pdCBhbmQgdXNlIHVpbnQz MiBpbnN0ZWFkIG9mIHVpbnQxNj8gUGxlYXNlIHVzZSB1bml0cyBzdGF0ZW1lbnQuDQotIEl0IGlz IG5vdCBjbGVhciB0byBtZSB3aGF04oCZcyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBuc2YtbmFt ZSBhbmQgbnNmLWluc3RhbmNlLW5hbWUuIEluIEV4YW1wbGVzIDQgYW5kIDUsIHRoZXkgaGF2ZSB0 aGUgc2FtZSB2YWx1ZSwgYnV0IG5vdCBpbiBFeGFtcGxlIDMuICBNaWdodCBiZSB3b3J0aCBjbGFy aWZ5aW5nIG9yIGdpdmluZyB0aGUgc2FtZSBuYW1lLg0KDQotIEhhdmluZyBuc2Ygb3IgaTJuc2Yg aW4gbWFueSBub2RlIG5hbWVzIGlzIHJlZHVuZGFudCwgc2luY2UgTlNGIG9yIEkyTlNGIGlzIGlu IHRoZSBoaWdoZXIgbGV2ZWwgY29udGFpbmVyIG5hbWUuICBlLmcsIGluIE5TRiBDYXBhYmlsaXR5 IFJlZ2lzdHJhdGlvbiBhbGwgbm9kZXMgc2VlbSB0byBoYXZlIGkybnNmIG9yIG5zZiBpbiB0aGVp ciBuYW1lLg0KDQotIFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgaW5kZW50YXRpb24gaXNzdWVzIGlu IHRoZSBZQU5HICBtb2R1bGUgKGUuZy4gUDE2KQ0KDQotIEFiaWRlIGJ5IG9yZGVyIGluIFJGQzg0 MDcgQXBwZW5kaXggQi4gZS5nLiBSUEMgc3RhdGVtZW50cyBzaG91bGQgYmUgYWZ0ZXIgZ3JvdXBp bmdzLg0KDQpOaXRzOg0KDQotIEFwcGVuZGl4IEI6IE1hbmFnbWVuZXQgLT4gTWFuYWdlbWVudA0K DQotIFNlY3Rpb24gNi4yOiBjYXBhaWxpdGllcyAtPiBjYXBhYmlsaXRpZXMNCg0KLSBFeGFtcGxl IDU6IHNwYWNlIGluICJodHRwX2FuZF9oIHR0cHNfZmxvb2RfbWl0aWdhdGlvbl9jYXBhYmlsaXR5 Ig0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCkZyb206ICJN ci4gSmFlaG9vbiBQYXVsIEplb25nIiA8amFlaG9vbi5wYXVsQGdtYWlsLmNvbTxtYWlsdG86amFl aG9vbi5wYXVsQGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBOb3ZlbWJlciA1LCAyMDE5IGF0 IDk6MDIgUE0NClRvOiAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNv bTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+Pg0KQ2M6IFlBTkcgRG9jdG9ycyA8eWFuZy1kb2N0 b3JzQGlldGYub3JnPG1haWx0bzp5YW5nLWRvY3RvcnNAaWV0Zi5vcmc+PiwgImkybnNmQGlldGYu b3JnPG1haWx0bzppMm5zZkBpZXRmLm9yZz4iIDxpMm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZA aWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS5h bGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFj ZS1kbS5hbGxAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJm YWNlLWRtLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24t aW50ZXJmYWNlLWRtLmFsbEBpZXRmLm9yZz4+LCBTYW5nd29uIEh5dW4gPHN3aHl1bjc3QGdtYWls LmNvbTxtYWlsdG86c3doeXVuNzdAZ21haWwuY29tPj4sICJza2t1LWlvdGxhYi1tZW1iZXJzQGdv b2dsZWdyb3Vwcy5jb208bWFpbHRvOnNra3UtaW90bGFiLW1lbWJlcnNAZ29vZ2xlZ3JvdXBzLmNv bT4iIDxza2t1LWlvdGxhYi1tZW1iZXJzQGdvb2dsZWdyb3Vwcy5jb208bWFpbHRvOnNra3UtaW90 bGFiLW1lbWJlcnNAZ29vZ2xlZ3JvdXBzLmNvbT4+LCAiTXIuIEphZWhvb24gUGF1bCBKZW9uZyIg PGphZWhvb24ucGF1bEBnbWFpbC5jb208bWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20+Pg0K U3ViamVjdDogUmU6IFtJMm5zZl0gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDQNCg0KSGkgUmVzaGFkLA0K SSBiZWxpZXZlIHRoYXQgSSBoYXZlIGFkZHJlc3NlZCB5b3VyIGNvbW1lbnRzIG9uIEkyTlNGIFJl Z2lzdHJhdGlvbiBJbnRlcmZhY2UgRGF0YSBNb2RlbDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDUNCg0KSWYg eW91IGFyZSBzYXRpc2ZpZWQgd2l0aCB0aGUgcmV2aXNpb24sIGNvdWxkIHlvdSB1cGRhdGUgdGhl IFJldmlldyByZXN1bHQgaW4gdGhlIGZvbGxvd2luZyBwYWdlPw0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1k bS0wNC15YW5nZG9jdG9ycy1sYy1yYWhtYW4tMjAxOS0wNi0yOC8NCg0KVGhhbmtzLg0KDQpCZXN0 IFJlZ2FyZHMsDQpQYXVsDQoNCk9uIFRodSwgSnVsIDI1LCAyMDE5IGF0IDExOjIzIFBNIE1yLiBK YWVob29uIFBhdWwgSmVvbmcgPGphZWhvb24ucGF1bEBnbWFpbC5jb208bWFpbHRvOmphZWhvb24u cGF1bEBnbWFpbC5jb20+PiB3cm90ZToNCkhpIFJlc2hhZCwNCkhlcmUgaXMgdGhlIHJldmlzaW9u IGxldHRlciBmb3IgdGhlIHJldmlzZWQgZHJhZnQsIHJlZmxlY3RpbmcgeW91ciBjb21tZW50cyBh bG9uZyB3aXRoIHRoZSByZXZpc2VkIGRyYWZ0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNQ0KDQpJZiB5b3Ug aGF2ZSBmdXJ0aGVyIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMsIHBsZWFzZSBsZXQgbWUga25vdy4N Cg0KVGhhbmtzLg0KDQpCZXN0IFJlZ2FyZHMsDQpQYXVsDQoNCk9uIEZyaSwgSnVuIDI4LCAyMDE5 IGF0IDU6MTcgUE0gUmVzaGFkIFJhaG1hbiB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5v cmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToNClJldmlld2VyOiBSZXNoYWQgUmFo bWFuDQpSZXZpZXcgcmVzdWx0OiBPbiB0aGUgUmlnaHQgVHJhY2sNCg0KWUFORyBEb2N0b3IgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNCAoYnkg UmVzaGFkDQpSYWhtYW4pDQoNCk1ham9yIGNvbW1lbnRzOg0KLSBMb29rIGF0IGFwcGVuZGl4IEIg b2YgUkZDODQwNyBmb3IgYW4gZXhhbXBsZSBvZiBob3cgYSBZQU5HIG1vZHVsZSBzaG91bGQgYmUN CnN0cnVjdHVyZWQuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgYWJpZGUgdG8gdGhhdC4gLSBQb29y IGRlc2NyaXB0aW9ucyBlLmcuDQoibnNmLW5hbWUiIGZvciBsZWFmICJuc2YtbmFtZSIgZXRjIC0g cHJlZml4ICJpaXJlZ2kiIGRvZXNuJ3Qgc2VlbSByaWdodC4gV2hhdA0KYWJvdXQgIm5zZnJlZyI/ IFByb2JhYmx5IG5lZWRzIGNvb3JkaW5hdGlvbiB3aXRoIHRoZSBvdGhlciBJMk5TRiBZQU5HIG1v ZHVsZXMNCnRvIGhhdmUgY29uc2lzdGVuY3kgYmV0d2VlbiB0aGUgcHJlZml4ZXMuIEkgc2VlIHRo YXQgWUQgQWNlZSBzdWdnZXN0ZWQNCiJuc2ZpbnRmIiBmb3IgZHJhZnQtaWV0Zi1pMm5zZi1uc2Yt ZmFjaW5nLWludGVyZmFjZS1kbS0wNiAtIE5vIHVuaXQgc3BlY2lmaWVkDQpmb3IgYmFuZHdpZHRo LCBwcm9jZXNzaW5nIChwZXJmb3JtYW5jZSkgLSBuc2YtYWRkcmVzcyBpcyBJUHY0IHNwZWNpZmlj IC0NClNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBsaXN0IHRoZSBub2RlcyBhcyBwZXIg c2VjdGlvbiAzLjcgb2YgUkZDODQwNy4gLQ0KU2hvdWxkIHRoaXMgZG9jdW1lbnQgYmUgaW5mb3Jt YXRpb25hbCBzaW5jZSA4MzI5IGlzIGluZm9ybWF0aW9uYWw/IC0gU2VjdGlvbiAyDQpzaG91bGQg dXNlIFJGQzgxNzQgYWxzbyAtIFJlZmVyIHRvIFJGQzg0MDcgaW5zdGVhZCBvZiA2ODA3IChZQU5H IEd1aWRlbGluZXMpIC0NCkV4YW1wbGVzIHNob3VsZCB1c2UgSVB2NiBhcyBleGFtcGxlcyAodXNl IHRoZSByYW5nZSBmcm9tIFJGQzM4NDkpLiBLdWRvcyBmb3INCmFsbCB0aGUgZXhhbXBsZXMuDQoN Ck1pbm9yIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM6DQotIFRoZSBZQU5HIHRyZWVzIHN1Y2ggYXMg RmlndXJlIDYsIDcgZXRjIGRvbid0IHNob3cgdGhlIGNvbnRlbnRzIG9mIHRoZQ0KZ3JvdXBpbmdz LiBTbyB0aGV5IGRvbid0IGhlbHAgbXVjaC4gLSBuc2YtcG9ydC1hZGRyZXNzIHNob3VsZCBiZSBu c2YtcG9ydD8gLQ0KU2VjdGlvbiA0LCBsYXN0IGJ1bGxldC4gSSBhbSBub3QgYW4gZXhwZXJ0IG9u IEkyTlNGIHNvIG5vdCBjbGVhciB0byBtZSB3aHkgdGhpcw0KcXVlcnkgaXMgbmVlZGVkLCBpcyBp dCBiZWNhdXNlIE5TRiBtYXkgbm90IHJlLXJlZ2lzdGVyIGFmdGVyIHRoZWlyIGNhcGFiaWxpdGll cw0KaGF2ZSBiZWVuIHVwZGF0ZWQ/IE1pZ2h0IGJlIHdvcnRoIGFkZGluZyBzb21lIGV4cGxhbmF0 aW9uLiAtIEhhdmUgdGhlIGV4YW1wbGVzDQpiZWVuIHZhbGlkYXRlZD8NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkkybnNmIG1haWxpbmcgbGlzdA0K STJuc2ZAaWV0Zi5vcmc8bWFpbHRvOkkybnNmQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZg0KDQoNCi0tDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCk1yLiBKYWVob29uIChQYXVsKSBKZW9uZywgUGguRC4NCkFzc29jaWF0ZSBQcm9mZXNz b3INCkRlcGFydG1lbnQgb2YgU29mdHdhcmUNClN1bmdreXVua3dhbiBVbml2ZXJzaXR5DQpPZmZp Y2U6ICs4Mi0zMS0yOTktNDk1Nw0KRW1haWw6IGphZWhvb24ucGF1bEBnbWFpbC5jb208bWFpbHRv OmphZWhvb24ucGF1bEBnbWFpbC5jb20+LCBwYXVsamVvbmdAc2trdS5lZHU8bWFpbHRvOnBhdWxq ZW9uZ0Bza2t1LmVkdT4NClBlcnNvbmFsIEhvbWVwYWdlOiBodHRwOi8vaW90bGFiLnNra3UuZWR1 L3Blb3BsZS1qYWVob29uLWplb25nLnBocDxodHRwOi8vY3BzbGFiLnNra3UuZWR1L3Blb3BsZS1q YWVob29uLWplb25nLnBocD4NCg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09DQpN ci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcsIFBoLkQuDQpBc3NvY2lhdGUgUHJvZmVzc29yDQpEZXBh cnRtZW50IG9mIFNvZnR3YXJlDQpTdW5na3l1bmt3YW4gVW5pdmVyc2l0eQ0KT2ZmaWNlOiArODIt MzEtMjk5LTQ5NTcNCkVtYWlsOiBqYWVob29uLnBhdWxAZ21haWwuY29tPG1haWx0bzpqYWVob29u LnBhdWxAZ21haWwuY29tPiwgcGF1bGplb25nQHNra3UuZWR1PG1haWx0bzpwYXVsamVvbmdAc2tr dS5lZHU+DQpQZXJzb25hbCBIb21lcGFnZTogaHR0cDovL2lvdGxhYi5za2t1LmVkdS9wZW9wbGUt amFlaG9vbi1qZW9uZy5waHA8aHR0cDovL2Nwc2xhYi5za2t1LmVkdS9wZW9wbGUtamFlaG9vbi1q ZW9uZy5waHA+DQoNCg0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KTXIuIEphZWhv b24gKFBhdWwpIEplb25nLCBQaC5ELg0KQXNzb2NpYXRlIFByb2Zlc3Nvcg0KRGVwYXJ0bWVudCBv ZiBTb2Z0d2FyZQ0KU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHkNCk9mZmljZTogKzgyLTMxLTI5OS00 OTU3DQpFbWFpbDogamFlaG9vbi5wYXVsQGdtYWlsLmNvbTxtYWlsdG86amFlaG9vbi5wYXVsQGdt YWlsLmNvbT4sIHBhdWxqZW9uZ0Bza2t1LmVkdTxtYWlsdG86cGF1bGplb25nQHNra3UuZWR1Pg0K UGVyc29uYWwgSG9tZXBhZ2U6IGh0dHA6Ly9pb3RsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24t amVvbmcucGhwPGh0dHA6Ly9jcHNsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhw Pg0KDQoNCi0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT0NCk1yLiBKYWVob29uIChQYXVs KSBKZW9uZywgUGguRC4NCkFzc29jaWF0ZSBQcm9mZXNzb3INCkRlcGFydG1lbnQgb2YgU29mdHdh cmUNClN1bmdreXVua3dhbiBVbml2ZXJzaXR5DQpPZmZpY2U6ICs4Mi0zMS0yOTktNDk1Nw0KRW1h aWw6IGphZWhvb24ucGF1bEBnbWFpbC5jb208bWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20+ LCBwYXVsamVvbmdAc2trdS5lZHU8bWFpbHRvOnBhdWxqZW9uZ0Bza2t1LmVkdT4NClBlcnNvbmFs IEhvbWVwYWdlOiBodHRwOi8vaW90bGFiLnNra3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBo cDxodHRwOi8vY3BzbGFiLnNra3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBocD4NCg0KDQot LQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09DQpNci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcs IFBoLkQuDQpBc3NvY2lhdGUgUHJvZmVzc29yDQpEZXBhcnRtZW50IG9mIFNvZnR3YXJlDQpTdW5n a3l1bmt3YW4gVW5pdmVyc2l0eQ0KT2ZmaWNlOiArODItMzEtMjk5LTQ5NTcNCkVtYWlsOiBqYWVo b29uLnBhdWxAZ21haWwuY29tPG1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tPiwgcGF1bGpl b25nQHNra3UuZWR1PG1haWx0bzpwYXVsamVvbmdAc2trdS5lZHU+DQpQZXJzb25hbCBIb21lcGFn ZTogaHR0cDovL2lvdGxhYi5za2t1LmVkdS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHA8aHR0cDov L2Nwc2xhYi5za2t1LmVkdS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHA+DQoNCg0KLS0NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KTXIuIEphZWhvb24gKFBhdWwpIEplb25nLCBQaC5ELg0K QXNzb2NpYXRlIFByb2Zlc3Nvcg0KRGVwYXJ0bWVudCBvZiBTb2Z0d2FyZQ0KU3VuZ2t5dW5rd2Fu IFVuaXZlcnNpdHkNCk9mZmljZTogKzgyLTMxLTI5OS00OTU3DQpFbWFpbDogamFlaG9vbi5wYXVs QGdtYWlsLmNvbTxtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbT4sIHBhdWxqZW9uZ0Bza2t1 LmVkdTxtYWlsdG86cGF1bGplb25nQHNra3UuZWR1Pg0KUGVyc29uYWwgSG9tZXBhZ2U6IGh0dHA6 Ly9pb3RsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhwPGh0dHA6Ly9jcHNsYWIu c2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhwPg0KDQoNCi0tDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCk1yLiBKYWVob29uIChQYXVsKSBKZW9uZywgUGguRC4NCkFzc29jaWF0 ZSBQcm9mZXNzb3INCkRlcGFydG1lbnQgb2YgU29mdHdhcmUNClN1bmdreXVua3dhbiBVbml2ZXJz aXR5DQpPZmZpY2U6ICs4Mi0zMS0yOTktNDk1Nw0KRW1haWw6IGphZWhvb24ucGF1bEBnbWFpbC5j b208bWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20+LCBwYXVsamVvbmdAc2trdS5lZHU8bWFp bHRvOnBhdWxqZW9uZ0Bza2t1LmVkdT4NClBlcnNvbmFsIEhvbWVwYWdlOiBodHRwOi8vaW90bGFi LnNra3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBocDxodHRwOi8vY3BzbGFiLnNra3UuZWR1 L3Blb3BsZS1qYWVob29uLWplb25nLnBocD4NCg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpNci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcsIFBoLkQuDQpBc3NvY2lhdGUgUHJvZmVz c29yDQpEZXBhcnRtZW50IG9mIFNvZnR3YXJlDQpTdW5na3l1bmt3YW4gVW5pdmVyc2l0eQ0KT2Zm aWNlOiArODItMzEtMjk5LTQ5NTcNCkVtYWlsOiBqYWVob29uLnBhdWxAZ21haWwuY29tPG1haWx0 bzpqYWVob29uLnBhdWxAZ21haWwuY29tPiwgcGF1bGplb25nQHNra3UuZWR1PG1haWx0bzpwYXVs amVvbmdAc2trdS5lZHU+DQpQZXJzb25hbCBIb21lcGFnZTogaHR0cDovL2lvdGxhYi5za2t1LmVk dS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHA8aHR0cDovL2Nwc2xhYi5za2t1LmVkdS9wZW9wbGUt amFlaG9vbi1qZW9uZy5waHA+DQoNCg0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K TXIuIEphZWhvb24gKFBhdWwpIEplb25nLCBQaC5ELg0KQXNzb2NpYXRlIFByb2Zlc3Nvcg0KRGVw YXJ0bWVudCBvZiBTb2Z0d2FyZQ0KU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHkNCk9mZmljZTogKzgy LTMxLTI5OS00OTU3DQpFbWFpbDogamFlaG9vbi5wYXVsQGdtYWlsLmNvbTxtYWlsdG86amFlaG9v bi5wYXVsQGdtYWlsLmNvbT4sIHBhdWxqZW9uZ0Bza2t1LmVkdTxtYWlsdG86cGF1bGplb25nQHNr a3UuZWR1Pg0KUGVyc29uYWwgSG9tZXBhZ2U6IGh0dHA6Ly9pb3RsYWIuc2trdS5lZHUvcGVvcGxl LWphZWhvb24tamVvbmcucGhwPGh0dHA6Ly9jcHNsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24t amVvbmcucGhwPg0K --_000_936E09CAB9EA4C1CB6D914723BC2F1EAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3659001AEA0D564BA125F5705762889B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiUFQgTW9ubyI7DQoJcGFub3NlLTE6MiA2 IDUgOSAyIDIgNSAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox Nzk1NzU4Mjk4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NTA1NjAxMjg7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6MjEzMzU5NzMyMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg5NTg2 OTg3MDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t Q0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBQYXVsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIFlBTkcgcmV2aWV3IHJlc3VsdCBoYXMgYmVlbiB1cGRhdGVkIGlu DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWky bnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0vIj4NCmRhdGF0cmFja2VyPC9hPi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlJlZ2FyZGluZyDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPnVzZSBv ZiBjbG9jayBzcGVlZCB0byBpZGVudGlmeSBwZXJmb3JtYW5jZeKAnSwgSeKAmWxsIGxlYXZlIHRo aXMgdG8gdGhlIFdHLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDtNci4gSmFl aG9vbiBQYXVsIEplb25nJnF1b3Q7ICZsdDtqYWVob29uLnBhdWxAZ21haWwuY29tJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5Nb25kYXksIE1hcmNoIDMwLCAyMDIwIGF0IDExOjI5IEFNPGJyPg0KPGI+ VG86IDwvYj4mcXVvdDtSZXNoYWQgUmFobWFuIChycmFobWFuKSZxdW90OyAmbHQ7cnJhaG1hbkBj aXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5ZQU5HIERvY3RvcnMgJmx0O3lhbmctZG9jdG9y c0BpZXRmLm9yZyZndDssICZxdW90O2kybnNmQGlldGYub3JnJnF1b3Q7ICZsdDtpMm5zZkBpZXRm Lm9yZyZndDssIFNhbmd3b24gSHl1biAmbHQ7c3doeXVuNzdAZ21haWwuY29tJmd0Oywgc2trdS1p b3RsYWItbWVtYmVycyAmbHQ7c2trdS1pb3RsYWItbWVtYmVyc0Bnb29nbGVncm91cHMuY29tJmd0 OywgJnF1b3Q7TXIuIEphZWhvb24gUGF1bCBKZW9uZyZxdW90OyAmbHQ7amFlaG9vbi5wYXVsQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJMm5zZl0gWWFuZ2RvY3RvcnMg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZh Y2UtZG0tMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIFJlc2hhZCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBoYXZlIHJlZmxlY3RlZCB5b3VyIGZvdXIgY29tbWVudHMgb24gLTA4IHZl cnNpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5zZi1y ZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA4Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA4PC9hPiZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7VGhlIGZvbGxvd2luZyBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIGZyb20g ZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA3Ojxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDtvICZuYnNwO2RyYWZ0LWlldGYtaTJuc2YtY2FwYWJpbGl0eS1kYXRhLW1v ZGVsIGlzIGNpdGVkIGFzIGEgbm9ybWF0aXZlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVm ZXJlbmNlIGFjY29yZGluZyB0byB0aGUgZ3VpZGVsaW5lIGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MDcjc2VjdGlv bi0zLjkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDA3I3NlY3Rpb24tMy45PC9h Pjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvICZuYnNwO0ZvciB0aGUgcmVmZXJlbmNlcyB0byBk cmFmdC1pZXRmLWkybnNmLWNhcGFiaWxpdHktZGF0YS1tb2RlbCBpbjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHRoZSBZQU5HIG1vZGVsLCB0aGV5IGFyZSBxdWFsaWZpZWQgd2l0aCBhIG5vdGUg dG8gdGhlIGVkaXRvciB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIGRyYWZ0IHdp bGwgYmVjb21lIGFuIFJGQywgc28gdGhlIGFjdHVhbCBSRkMgbnVtYmVyIG9mIHRoZTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0IG5lZWRzIHRvIGJlIHVzZWQuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO28gJm5ic3A7VGhlIGVkaXRvcidzIG5vdGVzIGFyZSBwdXQgdG8gcmVxdWVzdCB0 byByZXBsYWNlIFhYWFggd2l0aCB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhY3R1YWwg UkZDIG51bWJlciBvZiB0aGlzIGRvY3VtZW50IChpLmUuLCBkcmFmdC1pZXRmLWkybnNmLTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0pIHdoZW4gdGhl IGRvY3VtZW50IGlzIHB1Ymxpc2hlZC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7byAmbmJzcDtM ZWFmIG5vZGVzIChpLmUuLCBwcm9jZXNzaW5nLWF2ZXJhZ2UgYW5kIHByb2Nlc3NpbmctcGVhaykg dW5kZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBjb250YWluZXIgcHJvY2Vzc2luZyBoYXZl IHVuaXQgR0h6IGV4cGxpY2l0bHkgd2l0aCB1bml0cyAmcXVvdDtHSHomcXVvdDsuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvdWxkIHlvdSBj aGVjayBpdCBhbmQgbW92ZSBpdCBmb3J3YXJkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhdWw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBNYXIgMjgs IDIwMjAgYXQgNjo1OCBQTSBNci4gSmFlaG9vbiBQYXVsIEplb25nICZsdDs8YSBocmVmPSJtYWls dG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSI+amFlaG9vbi5wYXVsQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIFJlc2hhZCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3aWxsIHJlZmxlY3QgeW91ciBjb21tZW50cyBvbiB0aGUgcmV2aXNp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UGF1bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDI1LCAyMDIwIGF0IDM6MjggQU0gUmVzaGFk IFJhaG1hbiAocnJhaG1hbikgJmx0OzxhIGhyZWY9Im1haWx0bzpycmFobWFuQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJyYWhtYW5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIFBhdWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+QXBvbG9naWVzIGZvciB0aGUgZGVsYXkuIEkgdG9vayBhIGxvb2sgYXQgcmV2LTA3IGFuZCBo ZXJlIGFyZSBzb21lIHRoaW5ncyB3aGljaCBJIG1pc3NlZCBpbiBwcmV2aW91cyByZXZpZXdzOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ZHJhZnQtaWV0Zi1pMm5zZi1jYXBhYmlsaXR5LWRhdGEt bW9kZWwgaXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlLCBpdCBzaG91bGQgYmUgYSBub3JtYXRp dmUgcmVmZXJlbmNlIGFzIHBlcg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4NDA3I3NlY3Rpb24tMy45IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzg0MDcjc2VjdGlvbi0zLjk8L2E+PG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSBhcmUgcmVmZXJlbmNlcyB0byBkcmFmdC1pZXRmLWkybnNm LWNhcGFiaWxpdHktZGF0YS1tb2RlbCBpbiB0aGUgWUFORyBtb2RlbCB3aGljaCBzaG91bGQgYmUg cXVhbGlmaWVkIHdpdGggYSBub3RlIHRvIHRoZSBlZGl0b3IgKHRoYXQgZHJhZnQgd2lsbCBiZWNv bWUgYW4gUkZDKS4gQXMgYW4gZXhhbXBsZSBzZWFyY2ggZm9yIFlZWVkgaW4NCjwvc3Bhbj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWJmZC15YW5nLTE3LnR4dCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtYmZkLXlh bmctMTcudHh0PC9hPjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5UaGUgZWRpdG9y4oCZcyBub3RlIHNob3VsZCBhbHNvIHJlcXVlc3QgdG8gY2hhbmdlIFhY WFggdG8gYWN0dWFsIFJGQyBudW1iZXIgd2hlbiB0aGUgZG9jdW1lbnQgaXMgcHVibGlzaGVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iNCIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVT Ij5MZWFmIG5vZGVzIHVuZGVyIGNvbnRhaW5lciBwcm9jZXNzaW5nIHNob3VsZCBoYXZlIHVuaXQg R0h6LiBPbiB0aGlzIG5vdGUsIEnigJltIG5vdCBzdXJlIGhvdyBjbG9jayBzcGVlZCB1bmlxdWVs eSBpZGVudGlmaWVzIHBlcmZvcm1hbmNlLCBidXQgSSB3b27igJl0IHByZXRlbmQgdG8gYmUgYW4g ZXhwZXJ0IGluIHRoZSBhcmVhLiBJTU8gdGhpcyBpcyBzb21ldGhpbmcgdGhlIFdHIHNob3VsZCBj b21tZW50IG9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ UmVzaGFkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDtNci4gSmFlaG9vbiBQYXVsIEpl b25nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmphZWhvb24ucGF1bEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5Nb25kYXksIE1hcmNoIDksIDIwMjAgYXQgNzoyMyBBTTxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7UmVzaGFkIFJhaG1hbiAocnJhaG1hbikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpycmFo bWFuQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYWhtYW5AY2lzY28uY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzogPC9iPllBTkcgRG9jdG9ycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhbmctZG9j dG9yc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnlhbmctZG9jdG9yc0BpZXRmLm9yZzwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pMm5zZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppMm5zZkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkybnNmQGlldGYub3JnPC9hPiZndDssIFNhbmd3b24gSHl1 bg0KICZsdDs8YSBocmVmPSJtYWlsdG86c3doeXVuNzdAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+c3doeXVuNzdAZ21haWwuY29tPC9hPiZndDssIHNra3UtaW90bGFiLW1lbWJlcnMgJmx0Ozxh IGhyZWY9Im1haWx0bzpza2t1LWlvdGxhYi1tZW1iZXJzQGdvb2dsZWdyb3Vwcy5jb20iIHRhcmdl dD0iX2JsYW5rIj5za2t1LWlvdGxhYi1tZW1iZXJzQGdvb2dsZWdyb3Vwcy5jb208L2E+Jmd0Oywg JnF1b3Q7TXIuIEphZWhvb24gUGF1bCBKZW9uZyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmph ZWhvb24ucGF1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYWVob29uLnBhdWxAZ21haWwu Y29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtJMm5zZl0gWWFuZ2RvY3RvcnMg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZh Y2UtZG0tMDQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSBSZXNoYWQsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPldlIGF1dGhvcnMgaGF2ZSBhZGRyZXNzZWQgeW91ciBjb21tZW50 cyBpbiB0aGUgcmV2aXNpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDciIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRp b24taW50ZXJmYWNlLWRtLTA3PC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhdHRhY2ggdGhlIHJldmlzaW9uIGxldHRl ciBmb3IgeW91ciBlYXN5IGNoZWNrdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbmNlIHlvdXIgY29tbWVudHMgYXJlIGFkZHJlc3Nl ZCB3ZWxsLCBwbGVhc2UgdXBkYXRlIHRoZSBZQU5HIHJldmlldyByZXN1bHQ6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9u LWludGVyZmFjZS1kbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0vPC9hPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhbmtzIGZvciB5b3VyIHZhbHVhYmxlIGhlbHAuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0IFJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBhdWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBTdW4sIEZlYiA5LCAyMDIwIGF0IDY6NTQgQU0gUmVzaGFkIFJhaG1hbiAocnJhaG1hbikg Jmx0OzxhIGhyZWY9Im1haWx0bzpycmFobWFuQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJy YWhtYW5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5Hb2luZyBiYWNrIHRvIHRoaXMgY29tbWVudCBvbiByZXYtMDU6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr Z3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+LSBBYmlkZSBieSBvcmRlciBpbiBS RkM4NDA3IEFwcGVuZGl4IEIuIGUuZy4gUlBDIHN0YXRlbWVudHMgc2hvdWxkIGJlIGFmdGVyIGdy b3VwaW5ncy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIG9ubHkgdGhpbmcgd2hpY2ggc2VlbXMgdG8gaGF2ZSBiZWVuIGZpeGVkIGlzIHRo YXQgdGhlIFJQQyBzdGF0ZW1lbnQgd2FzIHB1dCBhZnRlciBncm91cGluZ3MuIEJ1dCB5b3Ugc2hv dWxkIGxvb2sgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDA3 I3BhZ2UtNjEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj ODQwNyNwYWdlLTYxPC9hPjo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gZXh0ZW5zaW9uIHN0YXRlbWVudHM8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gZmVhdHVyZSBzdGF0ZW1lbnRzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC8vIGlkZW50aXR5IHN0YXRlbWVudHM8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLy8gdHlwZWRlZiBzdGF0ZW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIGdyb3Vw aW5nIHN0YXRlbWVudHM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gZGF0YSBkZWZpbml0aW9u IHN0YXRlbWVudHM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gYXVnbWVudCBzdGF0ZW1lbnRz PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIHJwYyBzdGF0ZW1lbnRzPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC8vIG5vdGlmaWNhdGlvbiBzdGF0ZW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC8vIERPIE5PVCBwdXQgZGV2aWF0aW9uIHN0YXRlbWVudHMgaW4gYSBwdWJsaXNoZWQgbW9k dWxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhhdCBtZWFucyB5b3VyIGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnRzIChjb250YWluZXIg bnNmLXJlZ2lzdHJhdGlvbnMpIHNob3VsZCBiZSBhZnRlciB0aGUgZ3JvdXBpbmdzLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+QWxzbyB0aGUgaW5kZW50YXRpb24gc2VlbXMgb2ZmIG9uIHRoZSBZ QU5HIG1vZHVsZSBpbiBzb21lIHBsYWNlcywgZm9yIGV4YW1wbGUgb24gUDE0Lg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNoYWQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90O01yLiBKYWVob29uIFBhdWwgSmVvbmcmcXVvdDsg Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5qYWVob29uLnBhdWxAZ21h aWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEZlYnJ1YXJ5IDcsIDIwMjAgYXQgOTo0 OSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmVzaGFkIFJhaG1hbiAocnJhaG1hbikmcXVvdDsg Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnJhaG1hbkBjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cnJhaG1hbkBjaXNjby5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5ZQU5HIERvY3RvcnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86eWFu Zy1kb2N0b3JzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPnlhbmctZG9jdG9yc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDssICZxdW90Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86aTJuc2ZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+aTJuc2ZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDsNCiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzppMm5zZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5pMm5zZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPiZndDssIFNhbmd3b24gSHl1biAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpzd2h5dW43N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+c3doeXVuNzdAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0OywNCiBza2t1LWlvdGxhYi1tZW1i ZXJzICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNra3UtaW90bGFiLW1lbWJlcnNAZ29vZ2xl Z3JvdXBzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5za2t1LWlvdGxhYi1tZW1iZXJzQGdvb2dsZWdyb3Vwcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbSTJuc2ZdIFlhbmdkb2N0b3JzIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgUmVzaGFkLA0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db3VsZCB5b3Ug dXBkYXRlIHRoZSByZXZpZXcgc3RhdHVzIGFzIFJFQURZPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVy ZmFjZS1kbS0wNC15YW5nZG9jdG9ycy1sYy1yYWhtYW4tMjAxOS0wNi0yOC8iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZXZpZXctaWV0Zi1pMm5zZi1y ZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA0LXlhbmdkb2N0b3JzLWxjLXJhaG1hbi0yMDE5LTA2 LTI4LzwvYT4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBhdWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFNhdCwgRmViIDgsIDIwMjAgYXQgMTE6 MzIgQU0gTXIuIEphZWhvb24gUGF1bCBKZW9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphZWhvb24u cGF1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYWVob29uLnBhdWxAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SGkgUmVzaGFkLA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGFua3MgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMgYW5kIGhlbHAuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0IFJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlBhdWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk9uIFNhdCwgRmViIDgsIDIwMjAgYXQgODozOCBBTSBSZXNoYWQgUmFobWFuIChy cmFobWFuKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJyYWhtYW5AY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+cnJhaG1hbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhp IFBhdWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBoYXZlIHZlcmlmaWVkIHRoYXQgeW914oCZ dmUgYWRkcmVzc2VkIGFsbCBjb21tZW50cyB3aGljaCB3ZXJlIHByb3ZpZGVkIG9uIDA1Lg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNoYWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPiZxdW90O01yLiBKYWVob29uIFBhdWwgSmVvbmcmcXVvdDsgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5qYWVob29uLnBhdWxAZ21haWwuY29tPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgSmFudWFyeSAzMCwgMjAyMCBhdCAxMDozMiBBTTxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmVzaGFkIFJhaG1hbiAocnJhaG1hbikmcXVvdDsgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86cnJhaG1hbkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cnJhaG1hbkBjaXNjby5jb208L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj5ZQU5HIERvY3RvcnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86eWFuZy1kb2N0 b3JzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPnlhbmctZG9jdG9yc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDssICZxdW90Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86 aTJuc2ZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+aTJuc2ZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mcXVvdDsNCiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppMm5z ZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5pMm5zZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPiZndDssIFNhbmd3b24gSHl1biAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpzd2h5dW43N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+c3doeXVuNzdAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0OywNCiBza2t1LWlvdGxhYi1tZW1iZXJzICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNra3UtaW90bGFiLW1lbWJlcnNAZ29vZ2xlZ3JvdXBz LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5za2t1 LWlvdGxhYi1tZW1iZXJzQGdvb2dsZWdyb3Vwcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7LCBQYXRyaWNrIExpbmdnYSAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpwYXRyaWNrbGluazg4OEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cGF0cmlja2xpbms4ODhAZ21haWwu Y29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Jmd0OywNCiAmcXVvdDtNci4gSmFlaG9vbiBQYXVsIEplb25nJnF1b3Q7ICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+amFlaG9vbi5wYXVsQGdtYWlsLmNvbTwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtJMm5zZl0gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBv ZiBkcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5S ZXNoYWQsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNv dWxkIHlvdSByZXNwb25kIHRvIG15IHByZXZpb3VzIGVtYWlsIGFib3V0IHRoZSBsYXRlc3QgcmV2 aXNpb24gb2YgdGhlIEkyTlNGIFJlZ2lzdHJhdGlvbiBJbnRlcmZhY2UgWUFORiBEYXRhIE1vZGVs IGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5z Zi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFj ZS1kbS0wNjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPklmIHlvdSBhcmUgc2F0aXNmaWVkIHdpdGggbXkgcmV2aXNpb24sIGNvdWxk IHlvdSB1cGRhdGUgdGhlIFlBTkcgRG9jdG9yJ3MgcmV2aWV3IHJlc3VsdCBpbiB0aGUgZm9sbG93 aW5nIGxpbms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3Jldmlldy1p ZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDQteWFuZ2RvY3RvcnMtbGMtcmFo bWFuLTIwMTktMDYtMjgvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvcmV2aWV3LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNC15 YW5nZG9jdG9ycy1sYy1yYWhtYW4tMjAxOS0wNi0yOC88L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZnRlciBnZXR0aW5nIHlvdXIg cmV2aWV3IHVwZGF0ZSBzdGF0ZSwgSSBjYW4gYXNrIHRoZSBJMk5TRiBXRyBjaGFpcnMgdG8gbWFr ZSB0aGUgV0cgTGFzdCBDYWxsIG9uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm91ciBJMk5TRiBSZWdpc3RyYXRpb24gSW50ZXJmYWNl IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+VGhhbmtzIGZvciB5b3VyIGVmZm9ydHMgYW5kIGhlbHAuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0IFJlZ2FyZHMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBh dWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFR1ZSwgSmFuIDIxLCAyMDIwIGF0IDg6MDggUE0gTXIuIEphZWhvb24gUGF1bCBKZW9u ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5qYWVob29uLnBhdWxAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgUmVzaGFkLA0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBhdXRob3JzIGhhdmUgYWRkcmVz c2VkIHlvdXIgY29tbWVudHMgd2l0aCB0aGUgZm9sbG93aW5nIHJldmlzaW9uOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50 ZXJmYWNlLWRtLTA2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNjwvYT4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgYXR0YWNoIHRoZSByZXZpc2lvbiBsZXR0ZXIgdG8gc2hvdyBob3cgdG8gYWRkcmVzcyB5b3Vy IGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q291bGQgeW91ciBjaGVjayB0aGlzIHJldmlzaW9uIGFuZCBwcm9jZWVkIHdp dGggdGhlIFlBTkcgcmV2aWV3IHVwZGF0ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlc3QgUmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UGF1bDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIFR1ZSwgTm92IDEyLCAyMDE5IGF0IDE6NTggQU0gUmVzaGFkIFJhaG1hbiAocnJhaG1hbikg Jmx0OzxhIGhyZWY9Im1haWx0bzpycmFobWFuQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJy YWhtYW5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkg UGF1bCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgaGF2ZSBkb25lIGFu b3RoZXIgcmV2aWV3IChJIGRvbuKAmXQgdGhpbmsgYW4gYXV0b21hdGVkIGVtYWlsIGdvdCBzZW50 IG91dCkuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYt aTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNC15YW5nZG9jdG9ycy1sYy1yYWhtYW4t MjAxOS0wNi0yOC8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3Jldmlldy1pZXRmLWkybnNmLXJlZ2lzdHJh dGlvbi1pbnRlcmZhY2UtZG0tMDQteWFuZ2RvY3RvcnMtbGMtcmFobWFuLTIwMTktMDYtMjgvPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4 LjBwdCA4LjBwdCA4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZx dW90Oztjb2xvcjpibGFjayI+WUFORyBEb2N0b3IgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaTJuc2Yt cmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNSAoYnkgUmVzaGFkIFJhaG1hbik8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rIHlvdSBmb3IgYWRk cmVzc2luZyBjb21tZW50cyBmcm9tIG15IGVhcmxpZXIgcmV2aWV3IEANCjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL3Jldmlldy1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDQteWFuZ2Rv Y3RvcnMtbGMtcmFobWFuLTIwMTktMDYtMjgvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjoj M0QyMkIzIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZXZpZXctaWV0Zi1pMm5z Zi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA0LXlhbmdkb2N0b3JzLWxjLXJhaG1hbi0yMDE5 LTA2LTI4Lzwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2Nv bG9yOmJsYWNrIj5NYWpvciBjb21tZW50cy9xdWVzdGlvbnM6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2si Pi0gVGhlcmUgaXMgYSBZQU5HIHdhcm5pbmcgb24gdGhlIGRhdGF0cmFja2VyIHBhZ2U6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVv dDs7Y29sb3I6YmxhY2siPmlldGYtaTJuc2YtcmVnLWludGVyZmFjZUAyMDE5LTA3LTI0Lnlhbmc6 NTQ6IHdhcm5pbmc6IFJGQyA4NDA3OiAzLjE6IFRoZSBJRVRGIFRydXN0IENvcHlyaWdodCBzdGF0 ZW1lbnQgc2VlbXMgdG8gYmUgbWlzc2luZyAoc2VlIHB5YW5nIC0taWV0Zi1oZWxwIGZvciBkZXRh aWxzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+VG8gZml4IHRoaXMsIGluIHRoZSBZQU5HIG1vZHVs ZSByZW1vdmUgdGhlICZsdDsmZ3Q7IGFyb3VuZCAyMDE5OiBDb3B5cmlnaHQgKGMpICZsdDsyMDE5 Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG RkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQ VCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+LSBG b3IgY29udGFjdCBpbiBZQU5HIG1vZHVsZSwgcGxlYXNlIHJlbW92ZSBXRyBjaGFpciBpbmZvIChz ZWUgUkZDODQwNyBhcHBlbmRpeCBCIGZvciBhbiBleGFtcGxlKTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5k OiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+LSBGb3IgdGhlIHJldmlzaW9uIGluIFlBTmcg bW9kdWxlLCBwdXQgJnF1b3Q7SW5pdGlhbCB2ZXJzaW9uJnF1b3Q7IChldmVuIHRob3VnaCBpdCdz IHRoZSA1dGggcmV2aXNpb24pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2Nv bG9yOmJsYWNrIj4tIFdoeSBkZWZpbmUgYSB1bmlvbiBvZiBpcHY0LWFkZHJlc3MgYW5kIGlwdjYt YWRkcmVzcyBpbiB0eXBlZGVmIG5zZi1hZGRyZXNzLCB3aHkgbm90IHJldXNlIGV4aXN0aW5nIGlw LWFkZHJlc3MgdHlwZSBmcm9tIFJGQzYwMjE/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25v JnF1b3Q7O2NvbG9yOmJsYWNrIj4tIEZvciBiYW5kd2lkdGgsIGlzIHRoZXJlIGEgcmVhc29uIHdo eSBpdCdzIGxpbWl0ZWQgdG8gdWludDE2PyBFdmVuIHRob3VnaCA2NVRicHMgaXMgYSBsb3QsIEkg d291bGRuJ3QgbGltaXQgaXQgdG8gdWludDE2LiBBbmQgYXJlbid0IHRoZXJlIGFueSB1c2UtY2Fz ZXMgZm9yIGJhbmR3aWR0aCBzbWFsbGVyIHRoYW4gMSBHYnBzPyBJZg0KIHllcywgdXNlIGUuZyBN YnBzIGFzIHVuaXQgYW5kIHVzZSB1aW50MzIgaW5zdGVhZCBvZiB1aW50MTY/IFBsZWFzZSB1c2Ug dW5pdHMgc3RhdGVtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2Jh Y2tncm91bmQ6I0ZGRkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4tIEl0IGlzIG5vdCBjbGVhciB0 byBtZSB3aGF04oCZcyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBuc2YtbmFtZSBhbmQgbnNmLWlu c3RhbmNlLW5hbWUuIEluIEV4YW1wbGVzIDQgYW5kIDUsIHRoZXkgaGF2ZSB0aGUgc2FtZSB2YWx1 ZSwgYnV0IG5vdCBpbiBFeGFtcGxlIDMuJm5ic3A7IE1pZ2h0IGJlIHdvcnRoIGNsYXJpZnlpbmcg b3IgZ2l2aW5nDQogdGhlIHNhbWUgbmFtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8m cXVvdDs7Y29sb3I6YmxhY2siPi0gSGF2aW5nIG5zZiBvciBpMm5zZiBpbiBtYW55IG5vZGUgbmFt ZXMgaXMgcmVkdW5kYW50LCBzaW5jZSBOU0Ygb3IgSTJOU0YgaXMgaW4gdGhlIGhpZ2hlciBsZXZl bCBjb250YWluZXIgbmFtZS4mbmJzcDsgZS5nLCBpbiBOU0YgQ2FwYWJpbGl0eSBSZWdpc3RyYXRp b24gYWxsIG5vZGVzIHNlZW0gdG8gaGF2ZSBpMm5zZiBvciBuc2YgaW4gdGhlaXINCiBuYW1lLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25v JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+LSBUaGVyZSBz ZWVtcyB0byBiZSBzb21lIGluZGVudGF0aW9uIGlzc3VlcyBpbiB0aGUgWUFORyZuYnNwOyBtb2R1 bGUgKGUuZy4gUDE2KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn cm91bmQ6I0ZGRkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpi bGFjayI+LSBBYmlkZSBieSBvcmRlciBpbiBSRkM4NDA3IEFwcGVuZGl4IEIuIGUuZy4gUlBDIHN0 YXRlbWVudHMgc2hvdWxkIGJlIGFmdGVyIGdyb3VwaW5ncy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDoj RkZGREY1Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPk5pdHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG RkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQ VCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4tIEFwcGVuZGl4IEI6IE1hbmFnbWVuZXQgLSZndDsg TWFuYWdlbWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91 bmQ6I0ZGRkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFj ayI+LSBTZWN0aW9uIDYuMjogY2FwYWlsaXRpZXMgLSZndDsgY2FwYWJpbGl0aWVzPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0 O2JhY2tncm91bmQ6I0ZGRkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4tIEV4YW1wbGUgNTogc3Bh Y2UgaW4gJnF1b3Q7aHR0cF9hbmRfaCB0dHBzX2Zsb29kX21pdGlnYXRpb25fY2FwYWJpbGl0eSZx dW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG RkRGNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQ VCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+UmVn YXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+UmVzaGFkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPlJlc2hhZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7TXIuIEphZWhvb24g UGF1bCBKZW9uZyZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqYWVob29uLnBhdWxA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PmphZWhvb24ucGF1bEBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE5vdmVt YmVyIDUsIDIwMTkgYXQgOTowMiBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmVzaGFkIFJhaG1h biAocnJhaG1hbikmcXVvdDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnJhaG1hbkBjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cnJh aG1hbkBjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5ZQU5HIERvY3RvcnMgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86eWFuZy1kb2N0b3JzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnlhbmctZG9jdG9yc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDssICZxdW90 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+aTJuc2ZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDsNCiAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzppMm5zZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5pMm5zZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDssICZxdW90Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRt LmFsbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5kcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0uYWxsQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ JnF1b3Q7DQogJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1pMm5zZi1yZWdp c3RyYXRpb24taW50ZXJmYWNlLWRtLmFsbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5kcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1p bnRlcmZhY2UtZG0uYWxsQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0OywgU2FuZ3dvbiBIeXVuICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnN3aHl1bjc3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5zd2h5dW43N0BnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7LA0KICZxdW90Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86c2trdS1pb3RsYWItbWVtYmVyc0Bnb29nbGVncm91cHMuY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnNra3UtaW90bGFiLW1l bWJlcnNAZ29vZ2xlZ3JvdXBzLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpza2t1 LWlvdGxhYi1tZW1iZXJzQGdvb2dsZWdyb3Vwcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+c2trdS1pb3RsYWItbWVtYmVyc0Bnb29nbGVncm91cHMu Y29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Jmd0OywNCiAmcXVvdDtNci4gSmFlaG9vbiBQYXVsIEplb25nJnF1b3Q7ICZsdDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+amFlaG9vbi5wYXVsQGdtYWlsLmNvbTwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtJMm5zZl0gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBv ZiBkcmFmdC1pZXRmLWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBSZXNo YWQsPGJyPg0KSSBiZWxpZXZlIHRoYXQgSSBoYXZlIGFkZHJlc3NlZCB5b3VyIGNvbW1lbnRzIG9u IEkyTlNGIFJlZ2lzdHJhdGlvbiBJbnRlcmZhY2UgRGF0YSBNb2RlbDo8YnI+DQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24t aW50ZXJmYWNlLWRtLTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtaTJuc2YtcmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNTwvYT48YnI+ DQo8YnI+DQpJZiB5b3UgYXJlIHNhdGlzZmllZCB3aXRoIHRoZSByZXZpc2lvbiwgY291bGQgeW91 IHVwZGF0ZSB0aGUgUmV2aWV3IHJlc3VsdCBpbiB0aGUgZm9sbG93aW5nIHBhZ2U/PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtaTJuc2Yt cmVnaXN0cmF0aW9uLWludGVyZmFjZS1kbS0wNC15YW5nZG9jdG9ycy1sYy1yYWhtYW4tMjAxOS0w Ni0yOC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9y ZXZpZXctaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50ZXJmYWNlLWRtLTA0LXlhbmdkb2N0b3Jz LWxjLXJhaG1hbi0yMDE5LTA2LTI4LzwvYT48YnI+DQombmJzcDs8YnI+DQpUaGFua3MuPGJyPg0K PGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NClBhdWwgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBKdWwgMjUsIDIwMTkgYXQgMTE6MjMgUE0g TXIuIEphZWhvb24gUGF1bCBKZW9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphZWhvb24ucGF1bEBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYWVob29uLnBhdWxAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkg UmVzaGFkLDxicj4NCkhlcmUgaXMgdGhlIHJldmlzaW9uIGxldHRlciBmb3IgdGhlIHJldmlzZWQg ZHJhZnQsIHJlZmxlY3RpbmcgeW91ciBjb21tZW50cyBhbG9uZyB3aXRoIHRoZSByZXZpc2VkIGRy YWZ0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWkybnNmLXJlZ2lzdHJhdGlvbi1pbnRlcmZhY2UtZG0tMDUiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRpb24taW50 ZXJmYWNlLWRtLTA1PC9hPiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8YnI+DQpJZiB5b3UgaGF2ZSBmdXJ0aGVyIGNvbW1lbnRzIGFu ZCBxdWVzdGlvbnMsIHBsZWFzZSBsZXQgbWUga25vdy48YnI+DQo8YnI+DQpUaGFua3MuPGJyPg0K PGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NClBhdWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgSnVuIDI4LCAyMDE5IGF0IDU6 MTcgUE0gUmVzaGFkIFJhaG1hbiB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpu b3JlcGx5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmV2aWV3ZXI6 IFJlc2hhZCBSYWhtYW48YnI+DQpSZXZpZXcgcmVzdWx0OiBPbiB0aGUgUmlnaHQgVHJhY2s8YnI+ DQo8YnI+DQpZQU5HIERvY3RvciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pMm5zZi1yZWdpc3RyYXRp b24taW50ZXJmYWNlLWRtLTA0IChieSBSZXNoYWQ8YnI+DQpSYWhtYW4pPGJyPg0KPGJyPg0KTWFq b3IgY29tbWVudHM6PGJyPg0KLSBMb29rIGF0IGFwcGVuZGl4IEIgb2YgUkZDODQwNyBmb3IgYW4g ZXhhbXBsZSBvZiBob3cgYSBZQU5HIG1vZHVsZSBzaG91bGQgYmU8YnI+DQpzdHJ1Y3R1cmVkLiBU aGlzIGRvY3VtZW50IGRvZXMgbm90IGFiaWRlIHRvIHRoYXQuIC0gUG9vciBkZXNjcmlwdGlvbnMg ZS5nLjxicj4NCiZxdW90O25zZi1uYW1lJnF1b3Q7IGZvciBsZWFmICZxdW90O25zZi1uYW1lJnF1 b3Q7IGV0YyAtIHByZWZpeCAmcXVvdDtpaXJlZ2kmcXVvdDsgZG9lc24ndCBzZWVtIHJpZ2h0LiBX aGF0PGJyPg0KYWJvdXQgJnF1b3Q7bnNmcmVnJnF1b3Q7PyBQcm9iYWJseSBuZWVkcyBjb29yZGlu YXRpb24gd2l0aCB0aGUgb3RoZXIgSTJOU0YgWUFORyBtb2R1bGVzPGJyPg0KdG8gaGF2ZSBjb25z aXN0ZW5jeSBiZXR3ZWVuIHRoZSBwcmVmaXhlcy4gSSBzZWUgdGhhdCBZRCBBY2VlIHN1Z2dlc3Rl ZDxicj4NCiZxdW90O25zZmludGYmcXVvdDsgZm9yIGRyYWZ0LWlldGYtaTJuc2YtbnNmLWZhY2lu Zy1pbnRlcmZhY2UtZG0tMDYgLSBObyB1bml0IHNwZWNpZmllZDxicj4NCmZvciBiYW5kd2lkdGgs IHByb2Nlc3NpbmcgKHBlcmZvcm1hbmNlKSAtIG5zZi1hZGRyZXNzIGlzIElQdjQgc3BlY2lmaWMg LTxicj4NClNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBsaXN0IHRoZSBub2RlcyBhcyBw ZXIgc2VjdGlvbiAzLjcgb2YgUkZDODQwNy4gLTxicj4NClNob3VsZCB0aGlzIGRvY3VtZW50IGJl IGluZm9ybWF0aW9uYWwgc2luY2UgODMyOSBpcyBpbmZvcm1hdGlvbmFsPyAtIFNlY3Rpb24gMjxi cj4NCnNob3VsZCB1c2UgUkZDODE3NCBhbHNvIC0gUmVmZXIgdG8gUkZDODQwNyBpbnN0ZWFkIG9m IDY4MDcgKFlBTkcgR3VpZGVsaW5lcykgLTxicj4NCkV4YW1wbGVzIHNob3VsZCB1c2UgSVB2NiBh cyBleGFtcGxlcyAodXNlIHRoZSByYW5nZSBmcm9tIFJGQzM4NDkpLiBLdWRvcyBmb3I8YnI+DQph bGwgdGhlIGV4YW1wbGVzLjxicj4NCjxicj4NCk1pbm9yIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM6 PGJyPg0KLSBUaGUgWUFORyB0cmVlcyBzdWNoIGFzIEZpZ3VyZSA2LCA3IGV0YyBkb24ndCBzaG93 IHRoZSBjb250ZW50cyBvZiB0aGU8YnI+DQpncm91cGluZ3MuIFNvIHRoZXkgZG9uJ3QgaGVscCBt dWNoLiAtIG5zZi1wb3J0LWFkZHJlc3Mgc2hvdWxkIGJlIG5zZi1wb3J0PyAtPGJyPg0KU2VjdGlv biA0LCBsYXN0IGJ1bGxldC4gSSBhbSBub3QgYW4gZXhwZXJ0IG9uIEkyTlNGIHNvIG5vdCBjbGVh ciB0byBtZSB3aHkgdGhpczxicj4NCnF1ZXJ5IGlzIG5lZWRlZCwgaXMgaXQgYmVjYXVzZSBOU0Yg bWF5IG5vdCByZS1yZWdpc3RlciBhZnRlciB0aGVpciBjYXBhYmlsaXRpZXM8YnI+DQpoYXZlIGJl ZW4gdXBkYXRlZD8gTWlnaHQgYmUgd29ydGggYWRkaW5nIHNvbWUgZXhwbGFuYXRpb24uIC0gSGF2 ZSB0aGUgZXhhbXBsZXM8YnI+DQpiZWVuIHZhbGlkYXRlZD88YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkkybnNmIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJMm5zZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PkkybnNmQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaTJuc2YiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2kybnNmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4N Ck1yLiBKYWVob29uIChQYXVsKSBKZW9uZywgUGguRC48YnI+DQpBc3NvY2lhdGUgUHJvZmVzc29y PGJyPg0KRGVwYXJ0bWVudCBvZiBTb2Z0d2FyZTxicj4NClN1bmdreXVua3dhbiBVbml2ZXJzaXR5 PGJyPg0KT2ZmaWNlOiAmIzQzOzgyLTMxLTI5OS00OTU3PGJyPg0KRW1haWw6IDxhIGhyZWY9Im1h aWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFlaG9vbi5wYXVs QGdtYWlsLmNvbTwvYT4sJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnBhdWxqZW9uZ0Bza2t1LmVkdSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPnBhdWxqZW9uZ0Bz a2t1LmVkdTwvc3Bhbj48L2E+PGJyPg0KUGVyc29uYWwgSG9tZXBhZ2U6IDxhIGhyZWY9Imh0dHA6 Ly9jcHNsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhwIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vaW90bGFiLnNra3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBocDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KTXIuIEphZWhvb24gKFBhdWwpIEpl b25nLCBQaC5ELjxicj4NCkFzc29jaWF0ZSBQcm9mZXNzb3I8YnI+DQpEZXBhcnRtZW50IG9mIFNv ZnR3YXJlPGJyPg0KU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHk8YnI+DQpPZmZpY2U6ICYjNDM7ODIt MzEtMjk5LTQ5NTc8YnI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmphZWhvb24ucGF1bEBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYWVob29uLnBhdWxAZ21haWwuY29tPC9hPiwmbmJzcDs8 YSBocmVmPSJtYWlsdG86cGF1bGplb25nQHNra3UuZWR1IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+cGF1bGplb25nQHNra3UuZWR1PC9zcGFuPjwvYT48YnI+ DQpQZXJzb25hbCBIb21lcGFnZTogPGEgaHJlZj0iaHR0cDovL2Nwc2xhYi5za2t1LmVkdS9wZW9w bGUtamFlaG9vbi1qZW9uZy5waHAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9pb3RsYWIuc2tr dS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PT09 PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KTXIuIEphZWhvb24gKFBhdWwpIEplb25nLCBQ aC5ELjxicj4NCkFzc29jaWF0ZSBQcm9mZXNzb3I8YnI+DQpEZXBhcnRtZW50IG9mIFNvZnR3YXJl PGJyPg0KU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHk8YnI+DQpPZmZpY2U6ICYjNDM7ODItMzEtMjk5 LTQ5NTc8YnI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5qYWVob29uLnBhdWxAZ21haWwuY29tPC9hPiwmbmJzcDs8YSBocmVm PSJtYWlsdG86cGF1bGplb25nQHNra3UuZWR1IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdCI+cGF1bGplb25nQHNra3UuZWR1PC9zcGFuPjwvYT48YnI+DQpQZXJz b25hbCBIb21lcGFnZTogPGEgaHJlZj0iaHR0cDovL2Nwc2xhYi5za2t1LmVkdS9wZW9wbGUtamFl aG9vbi1qZW9uZy5waHAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9pb3RsYWIuc2trdS5lZHUv cGVvcGxlLWphZWhvb24tamVvbmcucGhwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj49PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQpNci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcsIFBoLkQuPGJyPg0KQXNzb2NpYXRlIFBy b2Zlc3Nvcjxicj4NCkRlcGFydG1lbnQgb2YgU29mdHdhcmU8YnI+DQpTdW5na3l1bmt3YW4gVW5p dmVyc2l0eTxicj4NCk9mZmljZTogJiM0Mzs4Mi0zMS0yOTktNDk1Nzxicj4NCkVtYWlsOiA8YSBo cmVmPSJtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphZWhv b24ucGF1bEBnbWFpbC5jb208L2E+LCZuYnNwOzxhIGhyZWY9Im1haWx0bzpwYXVsamVvbmdAc2tr dS5lZHUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5wYXVs amVvbmdAc2trdS5lZHU8L3NwYW4+PC9hPjxicj4NClBlcnNvbmFsIEhvbWVwYWdlOiA8YSBocmVm PSJodHRwOi8vY3BzbGFiLnNra3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBocCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cDovL2lvdGxhYi5za2t1LmVkdS9wZW9wbGUtamFlaG9vbi1qZW9uZy5w aHA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj49PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ DQpNci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcsIFBoLkQuPGJyPg0KQXNzb2NpYXRlIFByb2Zlc3Nv cjxicj4NCkRlcGFydG1lbnQgb2YgU29mdHdhcmU8YnI+DQpTdW5na3l1bmt3YW4gVW5pdmVyc2l0 eTxicj4NCk9mZmljZTogJiM0Mzs4Mi0zMS0yOTktNDk1Nzxicj4NCkVtYWlsOiA8YSBocmVmPSJt YWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphZWhvb24ucGF1 bEBnbWFpbC5jb208L2E+LCZuYnNwOzxhIGhyZWY9Im1haWx0bzpwYXVsamVvbmdAc2trdS5lZHUi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5wYXVsamVvbmdA c2trdS5lZHU8L3NwYW4+PC9hPjxicj4NClBlcnNvbmFsIEhvbWVwYWdlOiA8YSBocmVmPSJodHRw Oi8vY3BzbGFiLnNra3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBocCIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cDovL2lvdGxhYi5za2t1LmVkdS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHA8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPj09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCk1yLiBKYWVob29uIChQYXVsKSBK ZW9uZywgUGguRC48YnI+DQpBc3NvY2lhdGUgUHJvZmVzc29yPGJyPg0KRGVwYXJ0bWVudCBvZiBT b2Z0d2FyZTxicj4NClN1bmdreXVua3dhbiBVbml2ZXJzaXR5PGJyPg0KT2ZmaWNlOiAmIzQzOzgy LTMxLTI5OS00OTU3PGJyPg0KRW1haWw6IDxhIGhyZWY9Im1haWx0bzpqYWVob29uLnBhdWxAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFlaG9vbi5wYXVsQGdtYWlsLmNvbTwvYT4sJm5ic3A7 PGEgaHJlZj0ibWFpbHRvOnBhdWxqZW9uZ0Bza2t1LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPnBhdWxqZW9uZ0Bza2t1LmVkdTwvc3Bhbj48L2E+PGJy Pg0KUGVyc29uYWwgSG9tZXBhZ2U6IDxhIGhyZWY9Imh0dHA6Ly9jcHNsYWIuc2trdS5lZHUvcGVv cGxlLWphZWhvb24tamVvbmcucGhwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vaW90bGFiLnNr a3UuZWR1L3Blb3BsZS1qYWVob29uLWplb25nLnBocDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj09 PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCk1yLiBKYWVob29uIChQYXVsKSBKZW9uZywg UGguRC48YnI+DQpBc3NvY2lhdGUgUHJvZmVzc29yPGJyPg0KRGVwYXJ0bWVudCBvZiBTb2Z0d2Fy ZTxicj4NClN1bmdreXVua3dhbiBVbml2ZXJzaXR5PGJyPg0KT2ZmaWNlOiAmIzQzOzgyLTMxLTI5 OS00OTU3PGJyPg0KRW1haWw6IDxhIGhyZWY9Im1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+amFlaG9vbi5wYXVsQGdtYWlsLmNvbTwvYT4sJm5ic3A7PGEgaHJl Zj0ibWFpbHRvOnBhdWxqZW9uZ0Bza2t1LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPnBhdWxqZW9uZ0Bza2t1LmVkdTwvc3Bhbj48L2E+PGJyPg0KUGVy c29uYWwgSG9tZXBhZ2U6IDxhIGhyZWY9Imh0dHA6Ly9jcHNsYWIuc2trdS5lZHUvcGVvcGxlLWph ZWhvb24tamVvbmcucGhwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vaW90bGFiLnNra3UuZWR1 L3Blb3BsZS1qYWVob29uLWplb25nLnBocDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NCk1yLiBKYWVob29uIChQYXVsKSBKZW9uZywgUGguRC48YnI+DQpBc3Nv Y2lhdGUgUHJvZmVzc29yPGJyPg0KRGVwYXJ0bWVudCBvZiBTb2Z0d2FyZTxicj4NClN1bmdreXVu a3dhbiBVbml2ZXJzaXR5PGJyPg0KT2ZmaWNlOiAmIzQzOzgyLTMxLTI5OS00OTU3PGJyPg0KRW1h aWw6IDxhIGhyZWY9Im1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+amFlaG9vbi5wYXVsQGdtYWlsLmNvbTwvYT4sJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnBhdWxq ZW9uZ0Bza2t1LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQiPnBhdWxqZW9uZ0Bza2t1LmVkdTwvc3Bhbj48L2E+PGJyPg0KUGVyc29uYWwgSG9tZXBhZ2U6 IDxhIGhyZWY9Imh0dHA6Ly9jcHNsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhw IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vaW90bGFiLnNra3UuZWR1L3Blb3BsZS1qYWVob29u LWplb25nLnBocDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KTXIuIEphZWhvb24gKFBh dWwpIEplb25nLCBQaC5ELjxicj4NCkFzc29jaWF0ZSBQcm9mZXNzb3I8YnI+DQpEZXBhcnRtZW50 IG9mIFNvZnR3YXJlPGJyPg0KU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHk8YnI+DQpPZmZpY2U6ICYj NDM7ODItMzEtMjk5LTQ5NTc8YnI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmphZWhvb24ucGF1 bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYWVob29uLnBhdWxAZ21haWwuY29tPC9hPiwm bmJzcDs8YSBocmVmPSJtYWlsdG86cGF1bGplb25nQHNra3UuZWR1IiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+cGF1bGplb25nQHNra3UuZWR1PC9zcGFuPjwv YT48YnI+DQpQZXJzb25hbCBIb21lcGFnZTogPGEgaHJlZj0iaHR0cDovL2Nwc2xhYi5za2t1LmVk dS9wZW9wbGUtamFlaG9vbi1qZW9uZy5waHAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9pb3Rs YWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhwPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_936E09CAB9EA4C1CB6D914723BC2F1EAciscocom_-- From nobody Mon Apr 13 08:22:46 2020 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EF73A1781; Mon, 13 Apr 2020 08:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 x3NiAaQouRfK; Mon, 13 Apr 2020 08:22:24 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDCA3A1797; Mon, 13 Apr 2020 08:22:23 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id y4so2898920ljn.7; Mon, 13 Apr 2020 08:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PHyR5+1648QHJ5xF6Oijcby6QACv0HeY6kUp3MLEklE=; b=dUAoL2mD8nnutr9ONP0roIcnBEoa5AzM4LfAyayrBxZZExV9odx2ZPsffpxileAfKs 3kA5c4najFko9Tj/ywJ0cDII4PkGEMm/cXmMskiNuJ0kuEmLPbdQRsBv5NVr+RLsyroD Tp4hpX6GW7nrX9dGXOsf81sj7Jjh8iJh/W70WgaSq1lAymBKrd/hJjtno6p6FPKBkbwl cD9vbh4S3n+OFzGac7X3OsRMr4CQIM2TetiXlS0Yqd50OPvBj1p0yNVLWOhrQFY5zzNq +Q9aGRzxxeuB/E68CtoOfwk+jwNKVko1rom2rlFOtFZz71KfSjEEgtEp66O/4LZWzo90 Qidg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PHyR5+1648QHJ5xF6Oijcby6QACv0HeY6kUp3MLEklE=; b=kk6tHicnFtDCd9ZV11B4fa1Re/viFjV0sgvbYwaO8Sp4zwd+fvDUQofBSYLM6+uNrj V6P2/0t+3JS6jV/IDstE0XoFjF8pRmKAg7TwRDp9cvoRvDe4meZoG3dE+9SyJ4qlIPlr fdvXUb2XG4Dk8n3P1/WtWlhJLET+vKL2E9cT46OC5ng2AdIn/FA8FIUevGV2sXMCrPcv QHNMVx/anLgoPz0DR1XXVuUehq35kykUp0qgDB5SnqYKB5nkIuXq+OvA1i3y5Y/Iovwl rHk/0o6dHNy9lwSqzVExKbz31mRNPM2oS1+KZR/VRvC1INpA1dxwwpdFYinrQa9n2Oq3 d5lQ== X-Gm-Message-State: AGi0PuY6iaemN7asu62EQMsuo8/fMHb8u3BkwokOR+DLVMKFHiEfMIj/ 4oAi1UOdAP7MXwcCDhGBD//0xCdlJgJ7nwYnXt0= X-Google-Smtp-Source: APiQypKBaZZfZJg2vdImD6m784Sau4cJ/hlNg85RulaLEubuzpRHYBB+JFv9/KUaOWjwxHs/6WrYfDLv3mM3quTg2Mw= X-Received: by 2002:a2e:351a:: with SMTP id z26mr10486629ljz.162.1586791340361; Mon, 13 Apr 2020 08:22:20 -0700 (PDT) MIME-Version: 1.0 References: <156175664267.21931.10329030969352120108@ietfa.amsl.com> <47E6993E-1045-4B29-B814-E7185516B272@cisco.com> <9B0042BE-DF30-4EAD-9B7F-5E4FB196F980@cisco.com> <936E09CA-B9EA-4C1C-B6D9-14723BC2F1EA@cisco.com> In-Reply-To: <936E09CA-B9EA-4C1C-B6D9-14723BC2F1EA@cisco.com> From: "Mr. Jaehoon Paul Jeong" Date: Tue, 14 Apr 2020 00:22:02 +0900 Message-ID: To: "Reshad Rahman (rrahman)" Cc: YANG Doctors , "i2nsf@ietf.org" , Sangwon Hyun , skku-iotlab-members Content-Type: multipart/alternative; boundary="0000000000002ccdc905a32da663" Archived-At: Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-registration-interface-dm-04 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 15:22:34 -0000 --0000000000002ccdc905a32da663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Reshad, Thanks for your help. Best Regards, Paul On Thu, Apr 9, 2020 at 8:33 AM Reshad Rahman (rrahman) wrote: > Hi Paul, > > > > The YANG review result has been updated in datatracker > > . > > > > Regarding =E2=80=9Cuse of clock speed to identify performance=E2=80=9D, I= =E2=80=99ll leave this > to the WG. > > > > Regards, > > Reshad. > > > > *From: *"Mr. Jaehoon Paul Jeong" > *Date: *Monday, March 30, 2020 at 11:29 AM > *To: *"Reshad Rahman (rrahman)" > *Cc: *YANG Doctors , "i2nsf@ietf.org" < > i2nsf@ietf.org>, Sangwon Hyun , skku-iotlab-members < > skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" < > jaehoon.paul@gmail.com> > *Subject: *Re: [I2nsf] Yangdoctors last call review of > draft-ietf-i2nsf-registration-interface-dm-04 > > > > Hi Reshad, > > I have reflected your four comments on -08 version: > > https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-08 > > > > > The following changes have been made from > draft-ietf-i2nsf-registration-interface-dm-07: > > o draft-ietf-i2nsf-capability-data-model is cited as a normative > reference according to the guideline at > https://tools.ietf.org/html/rfc8407#section-3.9 > > o For the references to draft-ietf-i2nsf-capability-data-model in > the YANG model, they are qualified with a note to the editor that > the draft will become an RFC, so the actual RFC number of the > draft needs to be used. > > o The editor's notes are put to request to replace XXXX with the > actual RFC number of this document (i.e., draft-ietf-i2nsf- > registration-interface-dm) when the document is published. > > o Leaf nodes (i.e., processing-average and processing-peak) under > container processing have unit GHz explicitly with units "GHz". > > > > Could you check it and move it forward? > > > > Thanks. > > > > Best Regards, > > Paul > > > > On Sat, Mar 28, 2020 at 6:58 PM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Reshad, > > I will reflect your comments on the revision. > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Wed, Mar 25, 2020 at 3:28 AM Reshad Rahman (rrahman) > wrote: > > Hi Paul, > > > > Apologies for the delay. I took a look at rev-07 and here are some things > which I missed in previous reviews: > > > > 1. draft-ietf-i2nsf-capability-data-model is an informative reference, > it should be a normative reference as per > https://tools.ietf.org/html/rfc8407#section-3.9 > 2. There are references to draft-ietf-i2nsf-capability-data-model in > the YANG model which should be qualified with a note to the editor (th= at > draft will become an RFC). As an example search for YYYY in > https://www.ietf.org/id/draft-ietf-bfd-yang-17.txt > > 3. The editor=E2=80=99s note should also request to change XXXX to = actual > RFC number when the document is published. > > 1. Leaf nodes under container processing should have unit GHz. On this > note, I=E2=80=99m not sure how clock speed uniquely identifies perform= ance, but I > won=E2=80=99t pretend to be an expert in the area. IMO this is somethi= ng the WG > should comment on. > > > > Regards, > > Reshad. > > > > *From: *"Mr. Jaehoon Paul Jeong" > *Date: *Monday, March 9, 2020 at 7:23 AM > *To: *"Reshad Rahman (rrahman)" > *Cc: *YANG Doctors , "i2nsf@ietf.org" < > i2nsf@ietf.org>, Sangwon Hyun , skku-iotlab-members < > skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" < > jaehoon.paul@gmail.com> > *Subject: *Re: [I2nsf] Yangdoctors last call review of > draft-ietf-i2nsf-registration-interface-dm-04 > > > > Hi Reshad, > > We authors have addressed your comments in the revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-07 > > > > I attach the revision letter for your easy checkup. > > > > Once your comments are addressed well, please update the YANG review > result: > > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-= dm/ > > > > > Thanks for your valuable help. > > > > Best Regards, > > Paul > > > > > > On Sun, Feb 9, 2020 at 6:54 AM Reshad Rahman (rrahman) > wrote: > > Hi, > > > > Going back to this comment on rev-05: > > - Abide by order in RFC8407 Appendix B. e.g. RPC statements should be > after groupings. > > The only thing which seems to have been fixed is that the RPC statement > was put after groupings. But you should look at > https://tools.ietf.org/html/rfc8407#page-61: > > // extension statements > > // feature statements > > // identity statements > > // typedef statements > > // grouping statements > > // data definition statements > > // augment statements > > // rpc statements > > // notification statements > > // DO NOT put deviation statements in a published module > > > > That means your data definition statements (container nsf-registrations) > should be after the groupings. > > > > Also the indentation seems off on the YANG module in some places, for > example on P14. > > > > Regards, > > Reshad. > > > > > > *From: *"Mr. Jaehoon Paul Jeong" > *Date: *Friday, February 7, 2020 at 9:49 PM > *To: *"Reshad Rahman (rrahman)" > *Cc: *YANG Doctors , "i2nsf@ietf.org" < > i2nsf@ietf.org>, Sangwon Hyun , skku-iotlab-members < > skku-iotlab-members@googlegroups.com> > *Subject: *Re: [I2nsf] Yangdoctors last call review of > draft-ietf-i2nsf-registration-interface-dm-04 > > > > Hi Reshad, > > Could you update the review status as READY? > > > > > https://datatracker.ietf.org/doc/review-ietf-i2nsf-registration-interface= -dm-04-yangdoctors-lc-rahman-2019-06-28/ > > > > > Thanks. > > > > Paul > > > > On Sat, Feb 8, 2020 at 11:32 AM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Reshad, > > Thanks for your valuable comments and help. > > > > Best Regards, > > Paul > > > > On Sat, Feb 8, 2020 at 8:38 AM Reshad Rahman (rrahman) > wrote: > > Hi Paul, > > > > I have verified that you=E2=80=99ve addressed all comments which were pro= vided on > 05. > > > > Regards, > > Reshad. > > > > *From: *"Mr. Jaehoon Paul Jeong" > *Date: *Thursday, January 30, 2020 at 10:32 AM > *To: *"Reshad Rahman (rrahman)" > *Cc: *YANG Doctors , "i2nsf@ietf.org" < > i2nsf@ietf.org>, Sangwon Hyun , skku-iotlab-members < > skku-iotlab-members@googlegroups.com>, Patrick Lingga < > patricklink888@gmail.com>, "Mr. Jaehoon Paul Jeong" < > jaehoon.paul@gmail.com> > *Subject: *Re: [I2nsf] Yangdoctors last call review of > draft-ietf-i2nsf-registration-interface-dm-04 > > > > Reshad, > > Could you respond to my previous email about the latest revision of the > I2NSF Registration Interface YANF Data Model draft? > > https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-06 > > > > If you are satisfied with my revision, could you update the YANG Doctor's > review result in the following link? > > > https://datatracker.ietf.org/doc/review-ietf-i2nsf-registration-interface= -dm-04-yangdoctors-lc-rahman-2019-06-28/ > > > > After getting your review update state, I can ask the I2NSF WG chairs to > make the WG Last Call on > > our I2NSF Registration Interface draft. > > > > Thanks for your efforts and help. > > > > Best Regards, > > Paul > > > > On Tue, Jan 21, 2020 at 8:08 PM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Reshad, > > We authors have addressed your comments with the following revision: > > https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-06 > > > > I attach the revision letter to show how to address your comments. > > > > Could your check this revision and proceed with the YANG review update? > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Tue, Nov 12, 2019 at 1:58 AM Reshad Rahman (rrahman) > wrote: > > Hi Paul, > > > > I have done another review (I don=E2=80=99t think an automated email got = sent > out). > > > https://datatracker.ietf.org/doc/review-ietf-i2nsf-registration-interface= -dm-04-yangdoctors-lc-rahman-2019-06-28/ > > > > YANG Doctor review of draft-ietf-i2nsf-registration-interface-dm-05 (by > Reshad Rahman) > > > > Thank you for addressing comments from my earlier review @ > https://datatracker.ietf.org/doc/review-ietf-i2nsf-registration-interface= -dm-04-yangdoctors-lc-rahman-2019-06-28/ > > > > Major comments/questions: > > - There is a YANG warning on the datatracker page: > > ietf-i2nsf-reg-interface@2019-07-24.yang:54: warning: RFC 8407: 3.1: The > IETF Trust Copyright statement seems to be missing (see pyang --ietf-help > for details). > > To fix this, in the YANG module remove the <> around 2019: Copyright (c) > <2019> > > > > - For contact in YANG module, please remove WG chair info (see RFC8407 > appendix B for an example) > > > > - For the revision in YANg module, put "Initial version" (even though it'= s > the 5th revision) > > > > - Why define a union of ipv4-address and ipv6-address in typedef > nsf-address, why not reuse existing ip-address type from RFC6021? > > > > - For bandwidth, is there a reason why it's limited to uint16? Even thoug= h > 65Tbps is a lot, I wouldn't limit it to uint16. And aren't there any > use-cases for bandwidth smaller than 1 Gbps? If yes, use e.g Mbps as unit > and use uint32 instead of uint16? Please use units statement. > > - It is not clear to me what=E2=80=99s the distinction between nsf-name a= nd > nsf-instance-name. In Examples 4 and 5, they have the same value, but not > in Example 3. Might be worth clarifying or giving the same name. > > > > - Having nsf or i2nsf in many node names is redundant, since NSF or I2NSF > is in the higher level container name. e.g, in NSF Capability Registrati= on > all nodes seem to have i2nsf or nsf in their name. > > > > - There seems to be some indentation issues in the YANG module (e.g. P16= ) > > > > - Abide by order in RFC8407 Appendix B. e.g. RPC statements should be > after groupings. > > > > Nits: > > > > - Appendix B: Managmenet -> Management > > > > - Section 6.2: capailities -> capabilities > > > > - Example 5: space in "http_and_h ttps_flood_mitigation_capability" > > > > Regards, > > Reshad. > > > > > > Regards, > > Reshad. > > > > *From: *"Mr. Jaehoon Paul Jeong" > *Date: *Tuesday, November 5, 2019 at 9:02 PM > *To: *"Reshad Rahman (rrahman)" > *Cc: *YANG Doctors , "i2nsf@ietf.org" < > i2nsf@ietf.org>, "draft-ietf-i2nsf-registration-interface-dm.all@ietf.org= " > , Sangwon Hyun < > swhyun77@gmail.com>, "skku-iotlab-members@googlegroups.com" < > skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" < > jaehoon.paul@gmail.com> > *Subject: *Re: [I2nsf] Yangdoctors last call review of > draft-ietf-i2nsf-registration-interface-dm-04 > > > > Hi Reshad, > I believe that I have addressed your comments on I2NSF Registration > Interface Data Model: > https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-05 > > If you are satisfied with the revision, could you update the Review resul= t > in the following page? > > https://datatracker.ietf.org/doc/review-ietf-i2nsf-registration-interface= -dm-04-yangdoctors-lc-rahman-2019-06-28/ > > Thanks. > > Best Regards, > Paul > > > > On Thu, Jul 25, 2019 at 11:23 PM Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Hi Reshad, > Here is the revision letter for the revised draft, reflecting your > comments along with the revised draft: > https://tools.ietf.org/html/draft-ietf-i2nsf-registration-interface-dm-05 > > > > If you have further comments and questions, please let me know. > > Thanks. > > Best Regards, > Paul > > > > On Fri, Jun 28, 2019 at 5:17 PM Reshad Rahman via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Reshad Rahman > Review result: On the Right Track > > YANG Doctor review of draft-ietf-i2nsf-registration-interface-dm-04 (by > Reshad > Rahman) > > Major comments: > - Look at appendix B of RFC8407 for an example of how a YANG module shoul= d > be > structured. This document does not abide to that. - Poor descriptions e.g= . > "nsf-name" for leaf "nsf-name" etc - prefix "iiregi" doesn't seem right. > What > about "nsfreg"? Probably needs coordination with the other I2NSF YANG > modules > to have consistency between the prefixes. I see that YD Acee suggested > "nsfintf" for draft-ietf-i2nsf-nsf-facing-interface-dm-06 - No unit > specified > for bandwidth, processing (performance) - nsf-address is IPv4 specific - > Security considerations should list the nodes as per section 3.7 of > RFC8407. - > Should this document be informational since 8329 is informational? - > Section 2 > should use RFC8174 also - Refer to RFC8407 instead of 6807 (YANG > Guidelines) - > Examples should use IPv6 as examples (use the range from RFC3849). Kudos > for > all the examples. > > Minor comments and questions: > - The YANG trees such as Figure 6, 7 etc don't show the contents of the > groupings. So they don't help much. - nsf-port-address should be nsf-port= ? > - > Section 4, last bullet. I am not an expert on I2NSF so not clear to me wh= y > this > query is needed, is it because NSF may not re-register after their > capabilities > have been updated? Might be worth adding some explanation. - Have the > examples > been validated? > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --0000000000002ccdc905a32da663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Reshad,
Thanks for your help.

<= div>Best Regards,
Paul

=
On Thu, Apr 9, 2020 at 8:33 AM Reshad= Rahman (rrahman) <rrahman@cisco.co= m> wrote:

Hi Paul,

=C2=A0

The YANG review result has been= updated in datatracker.

=C2=A0

Regarding =E2=80=9Cuse of clock speed to identify performance=E2=80=9D, I=E2= =80=99ll leave this to the WG.

=C2=A0

Regards,

Reshad.

=C2=A0

From: = "Mr. Jaehoon Pau= l Jeong" <jaehoon.paul@gmail.com>
Date: Monday, March 30, 2020 at 11:29 AM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: YANG Doctors <yang-doctors@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Sangwon Hyun <swhyun77@gmail.com>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>,= "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2ns= f-registration-interface-dm-04

=C2=A0

Hi Reshad,

I have reflected your four comments on -08 version:<= u>

=C2=A0

=C2=A0 =C2=A0The following changes have been made fr= om draft-ietf-i2nsf-registration-interface-dm-07:

=C2=A0 =C2=A0o =C2=A0draft-ietf-i2nsf-capability-data-model is cited as a n= ormative
=C2=A0 =C2=A0 =C2=A0 reference according to the guideline at
=C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/rfc8407#section-3.9=

=C2=A0 =C2=A0o =C2=A0For the references to draft-ietf-i2nsf-capability-data= -model in
=C2=A0 =C2=A0 =C2=A0 the YANG model, they are qualified with a note to the = editor that
=C2=A0 =C2=A0 =C2=A0 the draft will become an RFC, so the actual RFC number= of the
=C2=A0 =C2=A0 =C2=A0 draft needs to be used.

=C2=A0 =C2=A0o =C2=A0The editor's notes are put to request to replace X= XXX with the
=C2=A0 =C2=A0 =C2=A0 actual RFC number of this document (i.e., draft-ietf-i= 2nsf-
=C2=A0 =C2=A0 =C2=A0 registration-interface-dm) when the document is publis= hed.

=C2=A0 =C2=A0o =C2=A0Leaf nodes (i.e., processing-average and processing-pe= ak) under
=C2=A0 =C2=A0 =C2=A0 container processing have unit GHz explicitly with uni= ts "GHz".

=C2=A0

Could you check it and move it forward?

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

=C2=A0

On Sat, Mar 28, 2020 at 6:58 PM Mr. Jaehoon Paul Jeo= ng <jaehoon.= paul@gmail.com> wrote:

Hi Reshad,

I will reflect your comments on the revision.=

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

=C2=A0

=C2=A0

On Wed, Mar 25, 2020 at 3:28 AM Reshad Rahman (rrahm= an) <rrahman@cisc= o.com> wrote:

Hi Paul,

=C2=A0

Apologies for the delay. I took= a look at rev-07 and here are some things which I missed in previous revie= ws:

=C2=A0

  1. draft-ietf-i2nsf-capability-data-model is an in= formative reference, it should be a normative reference as per https://tools.ietf.org/html/rfc8407#section-3.9
  2. There are references to draft-ietf-i2nsf-capabi= lity-data-model in the YANG model which should be qualified with a note to = the editor (that draft will become an RFC). As an example search for YYYY i= n https://www.ietf.org/id/draft-ietf-bfd-yang-17.txt<= u>

3.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 The editor=E2=80=99s note should also re= quest to change XXXX to actual RFC number when the document is published.

  1. Leaf nodes under container processing should have unit= GHz. On this note, I=E2=80=99m not sure how clock speed uniquely identifie= s performance, but I won=E2=80=99t pretend to be an expert in the area. IMO= this is something the WG should comment on.

=C2=A0

Regards,

Reshad.

=C2=A0

From: "Mr. Jaehoon Pau= l Jeong" <jaehoon.paul@gmail.com>
Date: Monday, March 9, 2020 at 7:23 AM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: YANG Doctors <yang-doctors@ietf.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, Sangwon Hyun <swhyun77@gmail= .com>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2ns= f-registration-interface-dm-04

=C2=A0

Hi Reshad,

We authors have addressed your comments in the revis= ion:

=C2=A0

I attach the revision letter for your easy checkup.<= u>

=C2=A0

Once your comments are addressed well, please update= the YANG review result:

=C2=A0

Thanks for your valuable help.

=C2=A0

Best Regards,

Paul

=C2=A0

=C2=A0

On Sun, Feb 9, 2020 at 6:54 AM Reshad Rahman (rrahma= n) <rrahman@cisco= .com> wrote:

Hi,

=C2=A0

Going back to this comment on r= ev-05:

The only thing which seems to have been fixed is tha= t the RPC statement was put after groupings. But you should look at h= ttps://tools.ietf.org/html/rfc8407#page-61:

=C2=A0=C2=A0=C2=A0=C2=A0 // extension stat=
ements
=C2=A0=C2=A0=C2=A0=C2=A0 // feature statem=
ents
=C2=A0=C2=A0=C2=A0=C2=A0 // identity state=
ments
=C2=A0=C2=A0=C2=A0=C2=A0 // typedef statem=
ents
=C2=A0=C2=A0=C2=A0=C2=A0 // grouping state=
ments
=C2=A0=C2=A0=C2=A0=C2=A0 // data definitio=
n statements
=C2=A0=C2=A0=C2=A0=C2=A0 // augment statem=
ents
=C2=A0=C2=A0=C2=A0=C2=A0 // rpc statements=

=C2=A0=C2=A0=C2=A0=C2=A0 // notification s=
tatements
=C2=A0=C2=A0=C2=A0=C2=A0 // DO NOT put dev=
iation statements in a published module

=C2=A0

That means your data definition= statements (container nsf-registrations) should be after the groupings.

=C2=A0

Also the indentation seems off = on the YANG module in some places, for example on P14.

=C2=A0

Regards,

Reshad.

=C2=A0

=C2=A0

From: "Mr. Jaehoon Pau= l Jeong" <jaehoon.paul@gmail.com>
Date: Friday, February 7, 2020 at 9:49 PM
To: "Reshad Rahman (rrahman)" <rrahma= n@cisco.com>
Cc: YANG Doctors <yang-doctors@ietf.org>, "i2nsf@ietf.org"= ; <i2nsf@ietf.org>, Sangwon Hyun <swhyun77@gmail.com>, skku-iotlab-members <skku-iotlab-m= embers@googlegroups.com>
Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2ns= f-registration-interface-dm-04

=C2=A0

Hi Reshad,

Could you update the review status as READY?<= u>

=C2=A0

=C2=A0

Thanks.

=C2=A0

Paul

=C2=A0

On Sat, Feb 8, 2020 at 11:32 AM Mr. Jaehoon Paul Jeo= ng <jaehoon.= paul@gmail.com> wrote:

Hi Reshad,

Thanks for your valuable comments and help.

=C2=A0

Best Regards,

Paul

=C2=A0

On Sat, Feb 8, 2020 at 8:38 AM Reshad Rahman (rrahma= n) <rrahman@cisco= .com> wrote:

Hi Paul,

=C2=A0

I have verified that you=E2=80= =99ve addressed all comments which were provided on 05.

=C2=A0

Regards,

Reshad.

=C2=A0

From: "Mr. Jaehoon Pau= l Jeong" <jaehoon.paul@gmail.com>
Date: Thursday, January 30, 2020 at 10:32 AM
To: "Reshad Rahman (rrahman)" <rrahma= n@cisco.com>
Cc: YANG Doctors <yang-doctors@ietf.org>, "i2nsf@ietf.org"= ; <i2nsf@ietf.org>, Sangwon Hyun <swhyun77@gmail.com>, skku-iotlab-members <skku-iotlab-m= embers@googlegroups.com>, Patrick Lingga <patricklink888@gmail.co= m>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul= @gmail.com>
Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2ns= f-registration-interface-dm-04

=C2=A0

Reshad,

Could you respond to my previous email about the lat= est revision of the I2NSF Registration Interface YANF Data Model draft?<= /u>

=C2=A0

If you are satisfied with my revision, could you upd= ate the YANG Doctor's review result in the following link?

=C2=A0

After getting your review update state, I can ask th= e I2NSF WG chairs to make the WG Last Call on=C2=A0

our I2NSF Registration Interface draft.

=C2=A0

Thanks for your efforts and help.

=C2=A0

Best Regards,

Paul

=C2=A0

On Tue, Jan 21, 2020 at 8:08 PM Mr. Jaehoon Paul Jeo= ng <jaehoon.= paul@gmail.com> wrote:

Hi Reshad,

We authors have addressed your comments with the fol= lowing revision:

=C2=A0

I attach the revision letter to show how to address = your comments.

=C2=A0

Could your check this revision and proceed with the = YANG review update?

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

=C2=A0

=C2=A0

On Tue, Nov 12, 2019 at 1:58 AM Reshad Rahman (rrahm= an) <rrahman@cisc= o.com> wrote:

Hi Paul,

=C2=A0<= /u>

I have done another revi= ew (I don=E2=80=99t think an automated email got sent out). =C2=A0

https://datatracker.ietf.org/d= oc/review-ietf-i2nsf-registration-interface-dm-04-yangdoctors-lc-rahman-201= 9-06-28/

=C2=A0

https://datatracker.ietf.org/doc/re= view-ietf-i2nsf-registration-interface-dm-04-yangdoctors-lc-rahman-2019-06-= 28/

=C2=A0

=C2=A0

Regards,<= /span>

Reshad.

=C2=A0

=C2=A0

Hi Reshad,
I believe that I have addressed your comments on I2NSF Registration Interfa= ce Data Model:
https://tools.ietf.org/html/draft-ietf-i2nsf-r= egistration-interface-dm-05

If you are satisfied with the revision, could you update the Review result = in the following page?
https:= //datatracker.ietf.org/doc/review-ietf-i2nsf-registration-interface-dm-04-y= angdoctors-lc-rahman-2019-06-28/
=C2=A0
Thanks.

Best Regards,
Paul

=C2=A0

On Thu, Jul 25, 2019 at 11:23 PM Mr. Jaehoon Paul Je= ong <jaehoon= .paul@gmail.com> wrote:

Hi Reshad,
Here is the revision letter for the revised draft, reflecting your comments= along with the revised draft:
https://tools.ietf.org/html/draft-ietf-i2nsf-r= egistration-interface-dm-05=C2=A0

=C2=A0
If you have further comments and questions, please let me know.

Thanks.

Best Regards,
Paul

=C2=A0

On Fri, Jun 28, 2019 at 5:17 PM Reshad Rahman via Da= tatracker <noreply= @ietf.org> wrote:

Reviewer: Reshad Rahman
Review result: On the Right Track

YANG Doctor review of draft-ietf-i2nsf-registration-interface-dm-04 (by Res= had
Rahman)

Major comments:
- Look at appendix B of RFC8407 for an example of how a YANG module should = be
structured. This document does not abide to that. - Poor descriptions e.g.<= br> "nsf-name" for leaf "nsf-name" etc - prefix "iireg= i" doesn't seem right. What
about "nsfreg"? Probably needs coordination with the other I2NSF = YANG modules
to have consistency between the prefixes. I see that YD Acee suggested
"nsfintf" for draft-ietf-i2nsf-nsf-facing-interface-dm-06 - No un= it specified
for bandwidth, processing (performance) - nsf-address is IPv4 specific - Security considerations should list the nodes as per section 3.7 of RFC8407= . -
Should this document be informational since 8329 is informational? - Sectio= n 2
should use RFC8174 also - Refer to RFC8407 instead of 6807 (YANG Guidelines= ) -
Examples should use IPv6 as examples (use the range from RFC3849). Kudos fo= r
all the examples.

Minor comments and questions:
- The YANG trees such as Figure 6, 7 etc don't show the contents of the=
groupings. So they don't help much. - nsf-port-address should be nsf-po= rt? -
Section 4, last bullet. I am not an expert on I2NSF so not clear to me why = this
query is needed, is it because NSF may not re-register after their capabili= ties
have been updated? Might be worth adding some explanation. - Have the examp= les
been validated?

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i2nsf


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php


=C2=A0

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.= D.
Associate Professor
Department of Software
Sungkyunkwan Univers= ity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeon= g@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeho= on-jeong.php
--0000000000002ccdc905a32da663--