From owner-snmpconf@seymour39.SNMP.COM Mon Jul 3 09:28:37 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01731 for ; Mon, 3 Jul 2000 09:28:36 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA26405 for snmpconf-outgoing; Mon, 3 Jul 2000 09:04:56 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB07FE631F@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Subject: RE: snmpconf Conflict Resolution Issues - Consensu Date: Mon, 3 Jul 2000 15:04:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Agree. See commentsinline > ---------- > From: Jon Saperia[SMTP:saperia@mediaone.net] > Reply To: snmpconf@snmp.com > Sent: Wednesday, June 28, 2000 7:10 PM > To: snmpconf@snmp.com > Subject: Re: snmpconf Conflict Resolution Issues - Consensu > > on 06/24/2000 6:24 PM, Joel M. Halpern at joel@mcquillan.com wrote: > > > It is my opinion that deleting a policy should not directly cause a > change > > in any attributes of any instances. It may be reasonable to expect > > (depending upon our evaluation model) that the set of policies in effect > > should be re-evaluated, which my cause some existing policy to change > the > > values of some objects. Trying to perform a direct "unwinding" of a > policy > > when it is deleted would, I think, be a very bad idea. > > > > Yours, > > Joel M. Halpern > > > > Folks, I believe that we have consensus on this topic even though my > original postings may not have been clear. > > The consensus is that we should not attempt to deal with this in the > managed > systems at all for all the previously stated reasons. I agree. If a > manager > wants to do something fancy when deleting a policy that is outside the > scope > of the current work. > > All agreed? > So this means that if a policy gets deleted from the table, then no action is taken, i.e. no config changes take place because of that action. If my understanding is correct, then we should explicitly state so in the DESCRIPTION clause of the table. Bert From owner-snmpconf@seymour39.SNMP.COM Mon Jul 3 11:18:46 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03140 for ; Mon, 3 Jul 2000 11:18:46 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA29712 for snmpconf-outgoing; Mon, 3 Jul 2000 10:59:34 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 03 Jul 2000 10:59:33 -0400 Subject: Re: snmpconf Conflict Resolution Issues - Consensu From: Jon Saperia To: Message-ID: In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB07FE631F@nl0006exch002u.nl.lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/03/2000 9:04 AM, Wijnen, Bert (Bert) at bwijnen@lucent.com wrote: >> All agreed? >> > So this means that if a policy gets deleted from the table, then no action > is taken, i.e. no config changes take place because of that action. > If my understanding is correct, then we should explicitly state so in the > DESCRIPTION clause of the table. > > Bert > Yes Bert. You understanding is consistent with mine. We should remember that this does not obviate what Andrew Smith wrote the other week about each level in a policy management system having responsibility for doing the right thing. This is not new, agents have been doing this for a long time. We need to do three things: 1. On the next revision of the DiffServ Policy MIB Module we should add this text where appropriate. This will be after the next IETF since we have already published for this meeting. 2. The Policy MIB Module has not been published. We should be able to get that into the Policy MIB in time where it matters (seems particularly relevant to the Policy Table. Steve can we get this in. I do not think it affects any of the tables I wrote as drafts and published to this list the other week (the redo of the capabilities table). 3. We should put this into the BCP policy section where appropriate. I will do this as I work on that section. /jon From owner-snmpconf@seymour39.SNMP.COM Tue Jul 4 05:11:58 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25995 for ; Tue, 4 Jul 2000 05:11:58 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id EAA01330 for snmpconf-outgoing; Tue, 4 Jul 2000 04:54:37 -0400 (EDT) Message-ID: <3961A3C9.F4EB27BA@nextbeacon.com> Date: Tue, 04 Jul 2000 01:43:53 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Comments inline: > > Also, I don't believe in having these bits set as side-effects of setting an > > SNMP variable. Reasons include: > > 1) An SNMP set for a variable that is under policy control doesn't communicate > > the following necessary sentiment: "While I know that this variable is under > > policy control, I intend to override that anyway". In other words, the SNMP > > engine can't tell whether the request intended to override policy or was an > > innocent mistake. It would be hard to say that we're enforcing policy when any > > request has carte-blanche to get an exemption. > > The intent of the user, innocent or not does not matter here. What matters > is that a value that was provisioned via the Policy module was changed by > something other than the policy module. But what happened to the policy system's enforcement responsibility? Getting the network set up in a consistent way is only half the problem. From that point entropy takes over and makes the configuration less and less consistent as more and more devices get tweaked. Unfortunately, in my experience, humans are responsible for the large majority of this "entropy": untrained technicians, sloppy engineers, people from outside organizations, etc are all responsible for making configuration changes that defy the network manager's wishes. It must be the responsibility of the policy system to enforce the network manager's high-level wishes, while still allowing a fireighting technician to override when absolutely necessary. Another question this raises is why would we have the policyAction execute repetitively if it will never end up changing any variables back into conformance with the policy? The only time it is allowed to enforce the policy is when the network element is already in conformance with the policy? > Certainly a well run system would > not give carte-blanche to any user to make modifications. This is one of the > reasons why user based security can be helpful in policy management. Security is orthogonal to this discussion. If I am a highly-priveleged Unix admin I don't spend my day reading my email and writing documents while logged in as root. I spend most of my time with my privileges disabled so that I won't make a mistake and wreck the system. I enable my priveleges only when I need to use them so that I don't break my own "policy". In other words, even privileged users need a policy system to make sure that they don't make mistakes. > > 2) Would require changing instrumentation for all MIBs. > > I do not believe this is so since it is the policy system that will detect > this change, not the instance specific instrumentation. This breaks down to: if (variable == 7) then variable = 7; else skip cuz somebody changed it; In other words, a no-op. Steve From owner-snmpconf@seymour39.SNMP.COM Tue Jul 4 09:31:58 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27870 for ; Tue, 4 Jul 2000 09:31:58 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA05243 for snmpconf-outgoing; Tue, 4 Jul 2000 09:11:46 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 04 Jul 2000 09:11:47 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <3961A3C9.F4EB27BA@nextbeacon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/04/2000 4:43 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > > Comments inline: > >>> Also, I don't believe in having these bits set as side-effects of setting an >>> SNMP variable. Reasons include: 1) An SNMP set for a variable that is under >>> policy control doesn't communicate the following necessary sentiment: "While >>> I know that this variable is under policy control, I intend to override that >>> anyway". In other words, the SNMP engine can't tell whether the request >>> intended to override policy or was an innocent mistake. It would be hard to >>> say that we're enforcing policy when any request has carte-blanche to get an >>> exemption. >>> >> The intent of the user, innocent or not does not matter here. What matters is >> that a value that was provisioned via the Policy module was changed by >> something other than the policy module. >> > But what happened to the policy system's enforcement responsibility? Getting > the network set up in a consistent way is only half the problem. From that > point entropy takes over and makes the configuration less and less consistent > as more and more devices get tweaked. Unfortunately, in my experience, humans > are responsible for the large majority of this "entropy": untrained > technicians, sloppy engineers, people from outside organizations, etc are all > responsible for making configuration changes that defy the network manager's > wishes. It must be the responsibility of the policy system to enforce the > network manager's high-level wishes, while still allowing a fireighting > technician to override when absolutely necessary. It seems like we want the same thing. Consistent control by the policy system while allowing for human override. I agree that allowing the facility for override might have the entropy effect. Nevertheless, we must do it since that is how operators will want things done. All I am suggesting is that when a change to a policy controlled element is made, that the policy system can know about it. In fact this could be used by management systems to produce exception reports. Lets put the extra value I described in the object you suggested. > > Another question this raises is why would we have the policyAction execute > repetitively if it will never end up changing any variables back into > conformance with the policy? The only time it is allowed to enforce the policy > is when the network element is already in conformance with the policy? I did not suggest having the policy action execute for the reason you state. We do not want it overriding the human override. It is the evaluation (one of the means I suggested) of the filter that will have to be done repetitively independent of whether we do this feature or not. Otherwise how will we know if a new policy element has come into existence that should have a policy action taken. I did suggest that even the element evaluation might not be necessary for this function since the system will already know what elements are associated with a policy. That will be in the agent anyway. > >> Certainly a well run system would not give carte-blanche to any user to make >> modifications. This is one of the reasons why user based security can be >> helpful in policy management. >> > Security is orthogonal to this discussion. If I am a highly-priveleged Unix > admin I don't spend my day reading my email and writing documents while logged > in as root. I spend most of my time with my privileges disabled so that I > won't make a mistake and wreck the system. I enable my priveleges only when I > need to use them so that > I don't break my own "policy". In other words, even > privileged users need a policy system to make sure that they don't make > mistakes. I agree with you here again. I am saying that only those that can su to root can make the change. My point was that permissions based on who you are can help here. > >>> 2) Would require changing instrumentation for all MIBs. >>> >> I do not believe this is so since it is the policy system that will detect >> this change, not the instance specific instrumentation. >> > This breaks down to: if (variable == 7) then variable = 7; else skip cuz > somebody changed it; > > In other words, a no-op. > > No, if the value is not 7 do not reset. The idea is to reflect that the variable has been changed (not necessary to report the changed value since that can be obtained directly via a get from the management system). I think the logic would be: If first evaluation of policy (for each element in a policy) set value for each following application if value is equal default then continue, else if value does not equal default and pmTrackingElementToPolicyStatus is modified(3) - do not change (no-op) else, reset value and send notification. How is this? /jon From owner-snmpconf@seymour39.SNMP.COM Tue Jul 4 09:43:58 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27938 for ; Tue, 4 Jul 2000 09:43:57 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA05508 for snmpconf-outgoing; Tue, 4 Jul 2000 09:26:54 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 04 Jul 2000 09:26:56 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <4.2.2.20000629092716.00a9fed0@omniplex.mcquillan.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 06/29/2000 9:33 AM, Joel M. Halpern at joel@mcquillan.com wrote: > There are at least two problems that I see being aluded to here. Both are > related to the phrase "if a variable is unde3r control of more than one > policy". We do need to make sure we understand what we want to happen in > that case. > > 1) If you set that variable with SNMP, assuming that the intention is to > override the policy setting of that variable, then I believe that you are > overriding ALL the policies which set that variable. Trying to achieve > some intermediate state where some of the policies apply to that variable, > but not all of them, would be better done by actually changing the set of > roles, rather than trying to force-off. force-off is for the case when the > manual intervention is moving the variable out of the policy space > temporarily. Joel, sorry for the late reply. This is still quite relevant to the discussion Steve and I have been having on the list related to this topic. With this definition of force-off we could perhaps get rid of my suggested modified. I think we are looking for two separate things here which is why two enumerated values might be helpful: 1. Turn this off for a while (the forced off state). One of the problems I think we want to address is to make it easier for operators to take things in an out of policy (while reducing the drive to entropy that Steve is concerned with) without the more heavy weight role redefintions. Role changes and new policy creation is more work for the humans and computers, especially when one considers that for this function the human intends the element to return to the policy in the reasonable future. 2. This is a variant of point 1 except that a human wants for fire-fighting reasons - or something akin to that- to change a value of an element under policy control (modified). I have to agree with you when you say that if an element has an object that is set by many policies (would of course have to be the same value), then all policies should be considered to have been overridden for the purposes of this element. I believe the tables allow for this level of expression. > 2) In practice the variable can not really be set by more than one > policy. There is some sort of conflict which has essentially been resolved > by "last touch wins". Unless we are forcing order of evaluation of policy > (and what about order of re-evaluation?) such a conflict resolution > mechanism is exceedingly risky. This goes on the conflict resolution thread. Agreed. I do think policy group and a unique policy priority per managed system will help. > > Related to this, I believe that the intention of most of the discussants is > that if a human being directly modifies a variable whose current state was > effected by policy, then that variable better be removed from policy > control automatically. Otherwise, the user will get unexpected effects > wherein his changes evaporate periodically (or even worse, some of them > evaporate, but not all). > I think this is about right. I would modify it a bit and say, removed from the perspective of control, not membership. The point is that there is an expectation in this case that in the not distant future, the element will once again be returned by the human that changed the value to the warm and peaceful and controlling embrace of the policy:-) /jon From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 10:16:34 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04692 for ; Wed, 5 Jul 2000 10:16:34 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA10698 for snmpconf-outgoing; Wed, 5 Jul 2000 09:56:38 -0400 (EDT) Message-Id: <4.2.2.20000705095340.00ab0100@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jul 2000 09:54:16 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions In-Reply-To: References: <4.2.2.20000629092716.00a9fed0@omniplex.mcquillan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I agree with your clarification of the kind of "removal" we are discussing. Yours, Joel M. Halpern At 09:26 AM 7/4/00 -0400, you wrote: >I think this is about right. I would modify it a bit and say, removed from >the perspective of control, not membership. The point is that there is an >expectation in this case that in the not distant future, the element will >once again be returned by the human that changed the value to the warm and >peaceful and controlling embrace of the policy:-) > >/jon From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 11:33:28 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08831 for ; Wed, 5 Jul 2000 11:33:27 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA13858 for snmpconf-outgoing; Wed, 5 Jul 2000 11:14:21 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 05 Jul 2000 11:14:22 -0400 Subject: snmpconf Working Items for our meetings From: Jon Saperia To: snmpconf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Over the past week or so David H. and I have discussed the agenda for our meetings a bit. I proposed that I send some ideas to the list to get some input from potential attendees. We generated a number of issues lists at the last interim. Some of those items have been fairly extensively discussed on this list. We have even reached consensus on some of them :-) The majority of items remain to be resolved. It seems that after our first meeting which should be a general status update, we should dig into the issues and work our way through them. Those that we have discussed on the mailing list will go by very rapidly. Others may take time, and others we may as a group decide to omit. Does this make sense? Alternate proposals? /jon From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 11:34:10 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08845 for ; Wed, 5 Jul 2000 11:34:10 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA13982 for snmpconf-outgoing; Wed, 5 Jul 2000 11:16:17 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 05 Jul 2000 11:16:20 -0400 Subject: snmpconf Policy Processing Questions From: Jon Saperia To: snmpconf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit The second of three I promised. /jon Policy Processing Questions: 1. An agent that gets a bad policy should do the right thing where right thing is to be defined. 2. Expression examples would be helpful: can we get (a+b) and ((a+B)*c) or a+(bxc) or (A+B)xc? 3. How do we handle syntax errors? 4. How do we handle run time exceptions -How many errors are OK within a policy? 5. How to deal with partial failures - notification of policy in trouble? 6. Types of exceptions - e.g. divide by zero or parts of the system failures. Token and run time exceptions? 7. What is the role of the manager in evaluating expressions? 8. What type of error reporting from the agent is required. -agent validation functions and what type of errors -Policy testing/verification prior to putting into service 9. Is it a requirement that we support UTF8 in our accessor functions? 10. Do we want to feed values from filter in to the policy action? - Intermediate values? - After we get a return value do we want to fire an action, and if so with a parameter other than true false, passing arguments. 11. Is the constraint of left and right useful? 12. Do we need both action and filter or would one do? What are the interactions allowed? 13. Need to address the question of the syntax of an identifier - what is the proper syntax of ifType.$1 - what is the structure including wildcarding? 14. What are the implications of wildcarding and implications in both directions in the role tables. 15. How big should an expression be allowed to be? 16. Not possible to download all policies everywhere. Must subset what to send so must handle two errors: download superfluous policy, fail to download needed policy: Type I and Type II - false positives 17. How do we detect and how to standardize error handling. 18. Estimated number of policies that we need to handle - we need the architecture to be able to scale up and down - what attributes are required to meet this goal? 19.Where to start the policy evaluation? 20. How often to evaluate the filter and when? 21. Is iterator is outside or inside the filter statement? 22. Is one iterater sufficient or do we need nested iterators. 23. How do we select instances? 24. What do we want for role - iteraters how many where. [end of list] From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 11:34:24 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08855 for ; Wed, 5 Jul 2000 11:34:24 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA13998 for snmpconf-outgoing; Wed, 5 Jul 2000 11:16:34 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 05 Jul 2000 11:16:37 -0400 Subject: snmpconf Execution Environment Questions From: Jon Saperia To: snmpconf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id LAA13994 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit The third of three. /jon Execution Environment Questions: 1. What are the implementation target environment requirements for the work? 2. What are the minimal requirements for systems that participate in the policy work and configuration. 3. Would like clearer definition of what Œthis elementš is. 4. What is the scheduling environment? [end of list] From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 11:37:58 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08919 for ; Wed, 5 Jul 2000 11:37:58 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA13962 for snmpconf-outgoing; Wed, 5 Jul 2000 11:15:47 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 05 Jul 2000 11:15:50 -0400 Subject: snmpconf Architectural and Relationship with other Documents Questions From: Jon Saperia To: snmpconf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit I am going to forward two other notes to refresh people about the open issues. This list has not been republished since our minutes. Two others will follow that are in the same state. I will not reforward those that have been extensively discussed though we should do a quick review at the working group meeting. /jon Architectural and Relationship with other Documents Questions: 1. How do we expect the mechanism and implementation specific policy modules to interact with the policy module? 2. The Policy MIB Module can manipulate any MIB object. Therefore, these MIB modules need to create objects that can be manipulated by the Policy Module. These need to be added to the Differentiated Services Policy MIB Module 3. Can policies cascade (nest)? Can filters or actions cascade? Can a policy reference another? How are policies named so they can be referenced? 4. Access control to the objects touched by the policy module need to be specified. In short, when a policy is run, whose security credentials are used? 5. How do we deal with security issues when a policy includes out of box or out of SNMP 'view' operations? 6. The policy module provides for instance expansion. The mechanism and implementation specific modules provide for object expansion. 7. What is the semantic method for expressing the fact that a policy has decided that a mechanism template is to be applied to a specific set of instances? Do we want to use language or specific MIB objects? One view is that the semantics are in the definition of the MIB object that is in the mechanism specific module. 8. Issues about indexing between policy module and the Diffserv MIB module need pointers in both directions. Linkages of the differentiated services policy MIB module to the Policy MIB Module relationship; of the DS MIB to our work. [end of list] From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 12:18:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10250 for ; Wed, 5 Jul 2000 12:18:26 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA15947 for snmpconf-outgoing; Wed, 5 Jul 2000 12:02:11 -0400 (EDT) Message-Id: <200007051602.MAA31222@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf quarterly list maintenance instructions Date: Wed, 05 Jul 2000 12:02:06 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com To remove yourself from the snmpconf discussion list, send a message to snmpconf-request@majordomo.snmp.com and enter just the word unsubscribe in the message body (not in the subject). The snmpconf list is for discussing the business of the Configuration Management using SNMP (snmpconf) working group of the IETF, which is an open forum for raising and discussing issues related to network device configuration management and SNMP. From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 18:07:16 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17878 for ; Wed, 5 Jul 2000 18:07:16 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA10855 for snmpconf-outgoing; Wed, 5 Jul 2000 17:50:07 -0400 (EDT) Message-ID: <39637C7B.BDFB4EE4@nextbeacon.com> Date: Wed, 05 Jul 2000 11:20:43 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Jon Saperia wrote: > > This breaks down to: if (variable == 7) then variable = 7; else skip cuz > > somebody changed it; > > > > In other words, a no-op. > > > No, if the value is not 7 do not reset. The idea is to reflect that the > variable has been changed (not necessary to report the changed value since > that can be obtained directly via a get from the management system). I think > the logic would be: > > > If first evaluation of policy (for each element in a policy) > set value > for each following application > if value is equal default then continue, else > if value does not equal default and > pmTrackingElementToPolicyStatus > is modified(3) - do not change (no-op) > else, > reset value and send notification. It all depends on how you set the value to modified(3). If it is done implicitely when the policy engine notices that the value has changed, then the entire algorithm breaks down to the no-op I described (i.e.: any time you notice a variable has changed, set the do-not-touch bit. Stated another way: only enforce correct configuration of variables that have correct configuration.) However, if the modified(3) bit is set explicitely through an SNMP set (or CLI command), then the algorithm makes some sense. It seems we have three models to choose from: 1. Allow no overrides (Most conservative) In this option, if the policy is causing an operational problem in the field, the policy must be re-written at headquarters and re-distributed, which will delay problem resolution. 2. Any change causes an implicit override (Most liberal) I claim that this becomes a no-op. However, even if it worked as desired, it seems too liberal to let anybody override policy even when they might not realize that they are overriding it or without understanding the implications of overriding the policies they are overriding. 3. Explicit override capability (Middle Ground) Allows quick resolution of a problem and then subsequent re-engineering of the policy to anticipate the new situation. Policy will still be enforced in the following situations: - Untrained technician misconfigures something - Service provider or vendor tech-support script (or human) makes changes that don't follow customer's policy - Highly skilled network engineer makes a mistake - etc. I suggest that the mddle ground is the right way to go. Operators can still tweak (with SNMP or CLI) variables not under policy control. And operators can still tweak variables that are under policy control but only after disabling the controlling policy (with SNMP or CLI). Steve From owner-snmpconf@seymour39.SNMP.COM Wed Jul 5 18:47:15 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18200 for ; Wed, 5 Jul 2000 18:47:14 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id SAA11892 for snmpconf-outgoing; Wed, 5 Jul 2000 18:31:39 -0400 (EDT) Message-Id: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jul 2000 18:28:59 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions In-Reply-To: <39637C7B.BDFB4EE4@nextbeacon.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The problem with I have with your proposal is two fold: A) Your objection to alternative 2 (roughly what is on the table, stated somewhat oddly) is in your concern about whether someone should be able to override policy. If they have the access to write directly to the variable, then they should be able to do so. They should not have to understand the policy tables and find the correct place to markt "I mean this" If they are making the change, they mean it. 2) If you require people to explicitly mark that they want to override policy, they will forget. They will be surprised and confused when the system does things that they do not expect. Fundementally, you are arguing that putting an object under policy control should remove it from SNMP control unless it is explicitly removed from policy control first. I am arguing that the act of directly setting the attribute seems to me to be quite clear enough. You raise the red herring of "then why reevaluate policy". The answer is that there are many ways that reality can change, not just by changing an SNMP variable. Some of these are equivalent to such sets (CLI is I agree still manual change). But cards fail. VCs come up. peerings start and stop. Cards get inserted and removed. These things may have effects on the policy decision. Probably teh easiest case to understand is when a customer is added to a port. Yes, this results in direct SNMP sets. But these occur before the policy has manipulated the port. So they don't prevent policy from taking effect. Then the policy system decides what the effect of these (role, etc) attribute settings should be. Another related example is where the role table is changed. That does not change any object directly effected by policy, and therefore does not remove anything from policy. The policy reevaluation will take these changes into account. Yours, Joel At 11:20 AM 7/5/00 -0700, Steve Waldbusser wrote: >Jon Saperia wrote: > > > > This breaks down to: if (variable == 7) then variable = 7; else skip cuz > > > somebody changed it; > > > > > > In other words, a no-op. > > > > > No, if the value is not 7 do not reset. The idea is to reflect that the > > variable has been changed (not necessary to report the changed value since > > that can be obtained directly via a get from the management system). I > think > > the logic would be: > > > > > > If first evaluation of policy (for each element in a policy) > > set value > > for each following application > > if value is equal default then continue, else > > if value does not equal default and > > pmTrackingElementToPolicyStatus > > is modified(3) - do not change (no-op) > > else, > > reset value and send notification. > >It all depends on how you set the value to modified(3). If it is done >implicitely >when the policy engine notices that the value has changed, then the >entire algorithm >breaks down to the no-op I described (i.e.: any time you notice a >variable has >changed, set the do-not-touch bit. Stated another way: only enforce >correct >configuration of variables that have correct configuration.) > >However, if the modified(3) bit is set explicitely through an SNMP set >(or CLI >command), then the algorithm makes some sense. > >It seems we have three models to choose from: > >1. Allow no overrides >(Most conservative) >In this option, if the policy is causing an operational problem in the >field, the >policy must be re-written at headquarters and re-distributed, which will >delay >problem resolution. > >2. Any change causes an implicit override >(Most liberal) >I claim that this becomes a no-op. However, even if it worked as >desired, it seems >too liberal to let anybody override policy even when they might not >realize that >they are overriding it or without understanding the implications of >overriding the >policies they are overriding. > >3. Explicit override capability >(Middle Ground) >Allows quick resolution of a problem and then subsequent re-engineering >of the >policy to anticipate the new situation. Policy will still be enforced in >the >following situations: > - Untrained technician misconfigures something > - Service provider or vendor tech-support script (or human) makes >changes that >don't follow customer's policy > - Highly skilled network engineer makes a mistake > - etc. > >I suggest that the mddle ground is the right way to go. Operators can >still tweak >(with SNMP or CLI) variables not under policy control. And operators can >still tweak >variables that are under policy control but only after disabling the >controlling >policy (with SNMP or CLI). > > >Steve From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 06:37:30 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10975 for ; Thu, 6 Jul 2000 06:37:29 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA03961 for snmpconf-outgoing; Thu, 6 Jul 2000 06:18:48 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 06 Jul 2000 06:18:54 -0400 Subject: snmpconf Interim Meeting Attendance From: Jon Saperia To: snmpconf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Folks, As you know David H is working on the interim meeting arrangements. Bert suggested the other day that it might be helpful if people were to say if they planned on attending as it might help with space planning for the interim meeting room. This is similar to what I had done for our SFO interim. If you plan on attending, please post a note so David can capture that information. Thanks /jon P.S. - I plan on attending. From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 07:03:38 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11575 for ; Thu, 6 Jul 2000 07:03:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA04430 for snmpconf-outgoing; Thu, 6 Jul 2000 06:45:51 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 06 Jul 2000 06:45:56 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/05/2000 6:28 PM, Joel M. Halpern at joel@mcquillan.com wrote: > The problem with I have with your proposal is two fold: > A) Your objection to alternative 2 (roughly what is on the table, stated > somewhat oddly) is in your concern about whether someone should be able to > override policy. If they have the access to write directly to the > variable, then they should be able to do so. They should not have to > understand the policy tables and find the correct place to markt "I mean > this" If they are making the change, they mean it. > Obviously I agree with Joel's assessment. An item we have yet to discuss is how often policies are evaluated on a system. The need for this is exists independently of the current discussion. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 09:52:01 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16531 for ; Thu, 6 Jul 2000 09:52:01 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA08265 for snmpconf-outgoing; Thu, 6 Jul 2000 09:33:36 -0400 (EDT) Message-Id: <4.2.2.20000706093056.00acb330@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jul 2000 09:31:10 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf Interim Meeting Attendance In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I plan to attend the interim meeting. Yours, Joel M. Halpern At 06:18 AM 7/6/00 -0400, you wrote: >Folks, > >As you know David H is working on the interim meeting arrangements. Bert >suggested the other day that it might be helpful if people were to say if >they planned on attending as it might help with space planning for the >interim meeting room. This is similar to what I had done for our SFO >interim. > >If you plan on attending, please post a note so David can capture that >information. > >Thanks >/jon > >P.S. - I plan on attending. From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 09:52:06 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16542 for ; Thu, 6 Jul 2000 09:52:06 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA08308 for snmpconf-outgoing; Thu, 6 Jul 2000 09:34:28 -0400 (EDT) Message-Id: <200007061334.JAA08300@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Attendance In-reply-to: Your message of Thu, 06 Jul 2000 06:18:54 -0400. Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 06 Jul 2000 09:34:26 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Thursday, July 6 2000, Jon Saperia wrote: > Folks, > > As you know David H is working on the interim meeting arrangements. Bert > suggested the other day that it might be helpful if people were to say if > they planned on attending as it might help with space planning for the > interim meeting room. This is similar to what I had done for our SFO > interim. > > If you plan on attending, please post a note so David can capture that > information. Both Jeff Case and I plan to be there. - Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 09:52:50 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16566 for ; Thu, 6 Jul 2000 09:52:49 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA08217 for snmpconf-outgoing; Thu, 6 Jul 2000 09:32:15 -0400 (EDT) Message-ID: <6399122981E1D211AB490090271E0AA38B1DAC@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Conflict Resolution Issues Date: Thu, 6 Jul 2000 09:25:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com David, >If you plan on attending, please post a note so David can capture that >information. I plan on being at the Friday seesion of the interim meeting. Thanks, -Fran From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 11:27:20 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18524 for ; Thu, 6 Jul 2000 11:27:13 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA11502 for snmpconf-outgoing; Thu, 6 Jul 2000 11:05:47 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 06 Jul 2000 11:05:45 -0400 Subject: snmpconf FW: individual submission - draft-saperia-policysnmp-00.txt From: Jon Saperia To: snmpconf Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="MS_Mac_OE_3045726345_1805586_MIME_Part" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3045726345_1805586_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have had a 'to do' item for a while to write up some information about the SNMP Configuration work we have been doing in an ID form. I have been working on this document for some time and it has undergone a number of revisions. Below is the request I just sent to the ID people to get the document published. Attached to this email is the document. Note that I sent the document in as an individual contributor, not as an SNMPCONF WG submission. I think some of the text is valuable and have used some in the documents we are working on. If people are interested, I am happy to turn the document over to the WG for future modification. If not it is an interesting document of where I believe we are in our work and some of my ideas. Please note that the document was originally written with a several detailed drawings that are obviously not in the .txt. I have placed the fancy versions on my web site and they are available in both .ps and .pdf form. The URLs are: http://www.jdscons.com/snmpconf.pdf http://www.jdscons.com/snmpconf.ps Hope this helps /jon P.S. - Steve Moulton has agreed to place the document in archive to make it easy for people to get at the information. ---------- > From: Jon Saperia > Date: Thu, 06 Jul 2000 10:55:53 -0400 > To: , Jon Saperia > Subject: individual submission - draft-saperia-policysnmp-00.txt > > This is an initial version of an individual submission that I would like > posted as and ID. The file in .txt form is attached with the name of: > > draft-saperia-policysnmp-00.txt > > Abstract: > > This paper is an introduction to terms and principles of > policy-based network configuration management that is based on > work in the IETF. A generic model for the realization of > policy-based network configuration management is presented > based on these terms. The last portion, and focus of the > paper, examines the current work of the SNMP Configuration > Working Group in the IETF and maps that work to the previously > defined terms and model. > > Thanks > /jon > > --MS_Mac_OE_3045726345_1805586_MIME_Part Content-type: text/plain; name="draft-saperia-policysnmp-00.txt"; x-mac-creator="74747874"; x-mac-type="54455854" Content-disposition: attachment Content-Transfer-Encoding: base64 SW50ZXJuZXQgRHJhZnQgIFBvbGljeSBDb25maWd1cmF0aW9uIHdpdGggU05NUCAgICBKdWx5 IDYsIDIwMDANDQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSi4gU2FwZXJpYQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSkRTIENvbnN1bHRpbmcsIEluYw0NICAgICAgICAgICAgICAgIFBvbGljeSBD b25maWd1cmF0aW9uIHdpdGggU05NUA0gICAgICAgICAgICAgICBkcmFmdC1zYXBlcmlhLXBv bGljeXNubXAtMDAudHh0DQ0gICAgICAgICAgICAgICAgICAgICAgICAgSnVseSA2LCAyMDAw DQ0gICAgICAgICAgICAgICAgICAgICBzYXBlcmlhQGpkc2NvbnMuY29tDQ0NDQ0NU3RhdHVz IG9mIHRoaXMgTWVtbw0NVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQg aXMgaW4gZnVsbCBjb25mb3JtYW5jZQ13aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24g MTAgb2YgUkZDMjAyNi4NDUludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMg b2YgdGhlIEludGVybmV0DUVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJl YXMsIGFuZCBpdHMgd29ya2luZw1ncm91cHMuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZw1kb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRz Lg0NSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXgNbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9i c29sZXRlZCBieSBvdGhlcg1kb2N1bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0NRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBv ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcw0id29yayBpbiBwcm9ncmVzcy4iDQ1UaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQ1UaGUgbGlzdCBvZiBJ bnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkDWF0IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQ1Db3B5cmlnaHQgTm90aWNlDQ0gICBD b3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAwKS4gIEFsbCBSaWdodHMg UmVzZXJ2ZWQuDQ0NDQ0NDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDZ0aCAyMDAxICAgICAgICAgICBbUGFnZSAxXQ0MDUludGVybmV0IERyYWZ0ICBQb2xpY3kg Q29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NMS4gIEFic3RyYWN0 DQ1UaGlzIHBhcGVyIGlzIGFuIGludHJvZHVjdGlvbiB0byB0ZXJtcyBhbmQgcHJpbmNpcGxl cyBvZg1wb2xpY3ktYmFzZWQgbmV0d29yayBjb25maWd1cmF0aW9uIG1hbmFnZW1lbnQgdGhh dCBpcyBiYXNlZCBvbg13b3JrIGluIHRoZSBJRVRGLiBBIGdlbmVyaWMgbW9kZWwgZm9yIHRo ZSByZWFsaXphdGlvbiBvZg1wb2xpY3ktYmFzZWQgbmV0d29yayBjb25maWd1cmF0aW9uIG1h bmFnZW1lbnQgaXMgcHJlc2VudGVkDWJhc2VkIG9uIHRoZXNlIHRlcm1zLiBUaGUgbGFzdCBw b3J0aW9uLCBhbmQgZm9jdXMgb2YgdGhlDXBhcGVyLCBleGFtaW5lcyB0aGUgY3VycmVudCB3 b3JrIG9mIHRoZSBTTk1QIENvbmZpZ3VyYXRpb24NV29ya2luZyBHcm91cCBpbiB0aGUgSUVU RiBhbmQgbWFwcyB0aGF0IHdvcmsgdG8gdGhlIHByZXZpb3VzbHkNZGVmaW5lZCB0ZXJtcyBh bmQgbW9kZWwuDQ0NDTIuICBJbnRyb2R1Y3Rpb24NDUNvbmZpZ3VyYXRpb24gbWFuYWdlbWVu dCBvZiBuZXR3b3JrIGVsZW1lbnRzIGJhc2VkIG9uIGEgc2V0IG9mDXJ1bGVzIG9yIGJ1c2lu ZXNzIG9iamVjdGl2ZXMgaXMgbm90IG5ldy4gUGF5cm9sbCwgb3JkZXINcHJvY2Vzc2luZyBz eXN0ZW1zLCBhbmQgbWFueSBvdGhlciBidXNpbmVzcyBjcml0aWNhbA1hcHBsaWNhdGlvbnMg aGF2ZSBiZWVuIGNvbmZpZ3VyZWQgdG8gcmVjZWl2ZSBwcmlvcml0eQ1wcm9jZXNzaW5nIGlu IHByZWZlcmVuY2UgdG8gb3RoZXIgY29tcHV0ZXIgdGFza3MgZm9yIGRlY2FkZXMuDUZvciB5 ZWFycywgcm91dGVycyBoYXZlIGJlZW4gY29uZmlndXJlZCB0byBzZW5kIHRyYWZmaWMgb3Zl cg1jZXJ0YWluIGxpbmtzIGluIHByZWZlcmVuY2UgdG8gb3RoZXJzIGJhc2VkIG9uIHRoZSBs b3dlc3QNZG9sbGFyIGNvc3QgbGluayB2ZXJzdXMgd2hhdCB0aGUgcm91dGluZyBwcm90b2Nv bHMgaGF2ZQ1zZWxlY3RlZCAtIHBvbGljeS1iYXNlZCByb3V0aW5nLg0NV2hhdCBpcyBkcml2 aW5nIG11Y2ggb2YgdGhlIHJlY2VudCBwdWJsaWMgZGlzY3Vzc2lvbiBvZiBwb2xpY3kNaXMg dGhlIGRlbWFuZCBmb3IgaW1wcm92ZWQgYW5kIHByZWRpY3RhYmxlIHNlcnZpY2UgbGV2ZWwN cXVhbGl0aWVzIC0gUXVhbGl0aWVzIG9mIFNlcnZpY2UgKFFvcykuICBSZWxhdGVkIHRvIHRo aXMNZGVtYW5kIGlzIHRoZSBhc3NvY2lhdGVkIGV4cGxvc2lvbiBpbiB0aGUgc2l6ZSBhbmQg Y29tcGxleGl0eQ1vZiBuZXR3b3JrcyBhbmQgdGhlIHNjYXJjaXR5IG9mIGh1bWFuIHJlc291 cmNlcyB3aXRoIHRoZQ1yZXF1aXNpdGUgc2tpbGxzIG1hbmFnZSB0byB0aGVtLiBBbiBleGFt cGxlIG9mIGEgdGVjaG5vbG9neQ10aGF0IGNhbiBiZSB1c2VkIHRvIGhlbHAgZGVsaXZlciBk aWZmZXJlbnQgcXVhbGl0aWVzIG9mDXNlcnZpY2UgaXMgRGlmZmVyZW50aWF0ZWQgU2Vydmlj ZXMgW0RJRkZTRVJWXS4gU2luY2Ugc29tZQ10cmFmZmljIGluIHRoaXMgYW5kIG90aGVyIFFv cyBhcHByb2FjaGVzIGlzIHRyZWF0ZWQNcHJlZmVyZW50aWFsbHkgb3ZlciBvdGhlciB0cmFm ZmljLCB0aGVyZSBpcyBhbHNvIGFuIGluY3JlYXNlZA1uZWVkIGZvciBhdXRoZW50aWNhdGlv biBvZiB0aGUgbW9uaXRvcmluZyBhbmQgY29udHJvbA1mdW5jdGlvbnMgaW4gdGhlIG5ldHdv cmsuIFRoaXMgaXMgbmVjZXNzYXJ5IHRvIGF2b2lkDXVuYXV0aG9yaXplZCB1c2Ugb2YgbmV0 d29yayByZXNvdXJjZXMgYW5kIHRoZSBzdWJzZXF1ZW50DXJlZHVjdGlvbiBpbiBzZXJ2aWNl IHF1YWxpdHkgYnkgdGhvc2Ugd2hvIGhhZCBwYWlkIGZvcg1pbXByb3ZlZCBRdWFsaXR5IG9m IFNlcnZpY2UuIFRoaXMgYXV0aGVudGljYXRpb24gbmVlZHMgdG8gYmUNZmxleGlibGUgc2lu Y2Ugc29tZSBuZXR3b3JrIG9wZXJhdG9ycyBuZWVkIGNvbnRyb2wgYW5kDW1vbml0b3Jpbmcs IHdoaWxlIG90aGVycyBuZWVkIG9ubHkgbW9uaXRvcmluZyBmdW5jdGlvbnMuIEluDWZhY3Qg c29tZSBvcGVyYXRvcnMgbWF5IGJlIHBlcm1pdHRlZCB0byBjb250cm9sIHNvbWUgZnVuY3Rp b25zDW9uIGEgZGV2aWNlIG9ubHkgd2hlbiBhY2Nlc3NpbmcgdGhlbSBmcm9tIGEgJ3NlY3Vy ZScgbG9jYXRpb24uDVRoZSBjb25jZXJuIG92ZXIgc2VjdXJpdHkgZXh0ZW5kcyB0byB0aGUg bmVlZCBpbiBtYW55DQ0NDQ0NU2FwZXJpYSAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2 dGggMjAwMSAgICAgICAgICAgW1BhZ2UgMl0NDA1JbnRlcm5ldCBEcmFmdCAgUG9saWN5IENv bmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwgMjAwMA0NDWVudmlyb25tZW50cyB0 byBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCB0aGUgdW5hdXRob3JpemVkDWRpc2Nsb3N1 cmUgb2YgbWFuYWdlbWVudCBpbmZvcm1hdGlvbiBhcyB3ZWxsIGFzIHByb3RlY3Rpb25zDWFn YWluc3QgbW9kaWZpY2F0aW9uIG9mIGF1dGhvcml6ZWQgY29tbWFuZHMuDQ1JbiBvcmRlciB0 byBlZmZlY3RpdmVseSBtYWtlIGNvbmZpZ3VyYXRpb24gZGVjaXNpb25zLCBwb2xpY3ktDWJh c2VkIGNvbmZpZ3VyYXRpb24gdG9vbHMgbmVlZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUNb3Bl cmF0aW9uYWwgc3RhdGUgYW5kIGF2YWlsYWJsZSByZXNvdXJjZXMgaW4gdGhlIG5ldHdvcmsu IFRoaXMNaW5mb3JtYXRpb24gaW5jbHVkZXM6DQ0NICAgICAtICBUaGUgb3BlcmF0aW9uYWwg c3RhdGUgb2YgbmV0d29yayBlbGVtZW50cyB0aGF0IGFyZSB0bw0gICAgIGJlIGNvbmZpZ3Vy ZWQuDQ0NICAgICAtICBUaGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBkZXZpY2VzIGluIHRoZSBu ZXR3b3JrLiBBDSAgICAgY2FwYWJpbGl0eSBjYW4gYmUgYWxtb3N0IGFueSB1bml0IG9mIHdv cmsgYSBuZXR3b3JrDSAgICAgZWxlbWVudCBjYW4gcGVyZm9ybS4gVGhlc2UgaW5jbHVkZSwg cm91dGluZyBwcm90b2NvbHMNICAgICBzdXBwb3J0ZWQsIFdlYiBTZXJ2ZXIgYW5kIE9TIHZl cnNpb25zLCBxdWV1aW5nIG1lY2hhbmlzbXMNICAgICBzdXBwb3J0ZWQgb24gZWFjaCBpbnRl cmZhY2UgdGhhdCBjYW4gYmUgdXNlZCB0byBzdXBwb3J0DSAgICAgZGlmZmVyZW50IHF1YWxp dGllcyBvZiBzZXJ2aWNlLCBhbmQgbWFueSBvdGhlcnMuDQ0NICAgICAtIFRoZSBjYXBhY2l0 eSBvZiB0aGUgZGV2aWNlcyB0byBwZXJmb3JtIHRoZSBkZXNpcmVkDSAgICAgd29yay4gQ2Fw YWJpbGl0eSBpcyBhbiBhYmlsaXR5IHRvIHBlcmZvcm0gdGhlIGRlc2lyZWQNICAgICB3b3Jr IHdoaWxlIGEgY2FwYWNpdHkgaXMgYSBtZWFzdXJlIG9mIGhvdyBtdWNoIG9mIHRoYXQNICAg ICBjYXBhYmlsaXR5IHRoZSBzeXN0ZW0gaGFzLg0NDSAgICAgLSAgVXRpbGl6YXRpb24gcmVm ZXJzIHRvIGhvdyBtdWNoIGNhcGFjaXR5IGZvciBhDSAgICAgcGFydGljdWxhciBjYXBhYmls aXR5IGhhcyBiZWVuIGNvbnN1bWVkLg0NDVRvIHVuZGVyc3RhbmQgcG9saWN5LWJhc2VkIGNv bmZpZ3VyYXRpb24gd2l0aCBTTk1QIGFuZCB0aGUNd29yayBvZiB0aGUgU05NUCBDb25maWd1 cmF0aW9uIFdvcmtpbmcgZ3JvdXAsIHRoZSBwcmltYXJ5DWZvY3VzIG9mIHRoaXMgcGFwZXIs IGEgcmV2aWV3IG9mIHNvbWUgYmFja2dyb3VuZCBhbmQgaGlzdG9yeQ1pcyBoZWxwZnVsLiBU aGlzIHBhcGVyIGlzIGRpdmlkZWQgaW50byAzIFBhcnRzOg0NWzFdICBCYWNrZ3JvdW5kIGFu ZCByZWNlbnQgaGlzdG9yeSByZWxhdGVkIHRvIHBvbGljeSBhbmQNICAgICBwb2xpY3kgYmFz ZWQgbWFuYWdlbWVudC4NDVsyXSAgRGVmaW5pdGlvbiBvZiB0ZXJtcy4gVGhlIG1lYW5pbmcg b2YgcG9saWN5IGFuZCBwb2xpY3kNICAgICByZWxhdGVkIHRlcm1pbm9sb2d5IGhhcyBiZWVu IHByb2JsZW1hdGljLiBJbiB0aGlzIHNlY3Rpb24NICAgICBhIGZldyB0ZXJtcyBhcmUgZGVm aW5lZCB0aGF0IGhlbHAgcHJvdmlkZSBhIGNvbnRleHQgZm9yDSAgICAgdGhlIGRpc2N1c3Np b24gb24gdGhlIGFwcHJvYWNoIHRoYXQgdGhlIFNOTVANICAgICBDb25maWd1cmF0aW9uIHdv cmtpbmcgZ3JvdXAgaXMgdGFraW5nIGluIHRoaXMgYXJlYS4gQW4NDQ0NDQ1TYXBlcmlhICAg ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAgICBbUGFnZSAzXQ0M DUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVs eSA2LCAyMDAwDQ0NICAgICBlZmZvcnQgaGFzIGJlZW4gbWFkZSB0byBoYXJtb25pemUgdGhl c2UgdGVybXMgd2l0aCB0aGUNICAgICBhY3Rpdml0aWVzIG9mIHRob3NlIGluIHRoZSBQb2xp Y3kgV29ya2luZyBHcm91cC4NDQ1bM10gIEN1cnJlbnQgd29yayBvZiB0aGUgU05NUCBDb25m aWd1cmF0aW9uIFdvcmtpbmcgR3JvdXANDQ0zLiAgSGlzdG9yeSBhbmQgQmFja2dyb3VuZA0N DUFuIGV4YW1pbmF0aW9uIG9mIHRoZSBhcmNoaXZlcyBvZiB0aGUgUG9saWN5IEZyYW1ld29y ayBXb3JraW5nDUdyb3VwIGluIHRoZSBJRVRGIFtQT0xJQ1ldIHdpbGwgcmV2ZWFsIHRoYXQg dGhleSBoYXZlIGJlZW4NZGlzY3Vzc2luZyB0aGUgaXNzdWUgb2YgcG9saWN5LWJhc2VkIG1h bmFnZW1lbnQgc2luY2UgdGhlDW1pZGRsZSBvZiAxOTk4LiBUaGUgYXJjaGl2ZSBpcyBsb2Nh dGVkIGF0Og0NICAgICAgICBodHRwOi8vd3d3LnJhbGVpZ2guaWJtLmNvbS9tYWlsbGlzdHMv cG9saWN5DQ1UaGUgZmlyc3QgZmV3IHNlbnRlbmNlcyBvZiB0aGUgY2hhcnRlciByZWFkOg0N ICAgICAgICAiVGhlcmUgaXMgYSBuZWVkIHRvIHJlcHJlc2VudCwgbWFuYWdlLCBzaGFyZSwg YW5kDXJldXNlIHBvbGljaWVzIGFuZCBwb2xpY3kgaW5mb3JtYXRpb24gaW4gYSB2ZW5kb3It aW5kZXBlbmRlbnQsDWludGVyb3BlcmFibGUsIGFuZCBzY2FsYWJsZSBtYW5uZXIuIFRoaXMg d29ya2luZyBncm91cCBoYXMNdGhyZWUgbWFpbiBnb2Fscy4gRmlyc3QsIHRvIHByb3ZpZGUg YSBmcmFtZXdvcmsgdGhhdCB3aWxsIG1lZXQNdGhlc2UgbmVlZHMuIFNlY29uZCwgdG8gZGVm aW5lIGFuIGV4dGVuc2libGUgaW5mb3JtYXRpb24gbW9kZWwNYW5kIHNwZWNpZmljIHNjaGVt YXRhIGNvbXBsaWFudCB3aXRoIHRoYXQgZnJhbWV3b3JrIHRoYXQgY2FuDWJlIHVzZWQgZm9y IGdlbmVyYWwgcG9saWN5IHJlcHJlc2VudGF0aW9uIChjYWxsZWQgdGhlIGNvcmUNaW5mb3Jt YXRpb24gbW9kZWwgYW5kIHNjaGVtYSkuIFRoaXJkLCB0byBleHRlbmQgdGhlIGNvcmUNaW5m b3JtYXRpb24gbW9kZWwgYW5kIHNjaGVtYSB0byBhZGRyZXNzIHRoZSBuZWVkcyBvZiBRb1MN dHJhZmZpYyBtYW5hZ2VtZW50IChjYWxsZWQgdGhlIFFvUyBpbmZvcm1hdGlvbiBtb2RlbCBh bmQNc2NoZW1hdGEpLiINDUZvciBhZGRpdGlvbmFsIGRldGFpbHMgb2YgdGhlIGNoYXJ0ZXIg YW5kIHRoZSBjdXJyZW50IHdvcmtpbmcNZ3JvdXAgYWN0aXZpdGllcyBwbGVhc2UgcmVmZXJl bmNlIHRoZSBjaGFydGVyIHBhZ2UgZm9yIHRoZQ13b3JraW5nIGdyb3VwIGF0Og0NICAgICAg ICBodHRwOi8vaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9wb2xpY3ktY2hhcnRlci5odG1sDQ1E dXJpbmcgdGhpcyBzYW1lIHBlcmlvZCBvZiB0aW1lLCBTTk1QdjMgW1NOTVBdIG1vdmVkIGZy b20NUFJPUE9TRUQgdG8gRFJBRlQgU1RBTkRBUkQgc3RhdHVzLiBUaGlzIGltcG9ydGFudCBl dm9sdXRpb24gaXMNcmVsZXZhbnQgdG8gdGhlIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25z IGFzc29jaWF0ZWQgd2l0aA1wb2xpY3ktYmFzZWQgbWFuYWdlbWVudCBzaW5jZSBzZWN1cml0 eSBpcyBhbiBpbXBvcnRhbnQgaXNzdWUNd2hlbiBhIHNpbmdsZSBoaWdoLWxldmVsIGNvbW1h bmQgY2FuIGJlIGlzc3VlZCB0aGF0IGhhcw1uZXR3b3JrIHdpZGUgaW1wYWN0Lg0NVGhlIFJl c291cmNlIEFsbG9jYXRpb24gUHJvdG9jb2wgV29ya2luZyBHcm91cCBbUkFQXSBoYXMgYmVl bg0NDQ0NDVNhcGVyaWEgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNnRoIDIwMDEgICAg ICAgICAgIFtQYWdlIDRdDQwNSW50ZXJuZXQgRHJhZnQgIFBvbGljeSBDb25maWd1cmF0aW9u IHdpdGggU05NUCAgICBKdWx5IDYsIDIwMDANDQ13b3JraW5nIG9uIHBvbGljeSBiYXNlZCBt YW5hZ2VtZW50IGZvciBzb21lIHRpbWUgdXNpbmcNcHJvdG9jb2xzIG90aGVyIHRoYW4gU05N UC4gRm9yIGFkZGl0aW9uYWwgZGV0YWlscyBvbiB0aGVzZQ1wcm90b2NvbHMsIHNlZSB0aGUg cmVmZXJlbmNlIHNlY3Rpb24gYXQgdGhlIGVuZCBvZiB0aGlzDWRvY3VtZW50Lg0NVGhlIGZh Y3QgdGhhdCB0aGVyZSB3ZXJlIG11bHRpcGxlIGFwcHJvYWNoZXMgY2F1c2VkIHNvbWUNY29u Y2VybiBhbmQgZ2VuZXJhdGVkIGEgbnVtYmVyIG9mIHBhcGVycyB0aGF0IHdlcmUgcmV2aWV3 ZWQNYW5kIGRpc2N1c3NlZC4gVGhlc2UgZGlzY3Vzc2lvbnMgY3VsbWluYXRlZCBpbiBhIEJP RiBvbg1jb25maWd1cmF0aW9uIG1hbmFnZW1lbnQgYXQgdGhlIDQ2dGggSUVURiBoZWxkIGlu IFdhc2hpbmd0b24sDURDIGluIE5vdmVtYmVyLCAxOTk5LiBPbmUgb2YgdGhlIG91dGNvbWVz IG9mIHRoYXQgQk9GIHdhcyB0bw1leHBsb3JlIHRoZSBjcmVhdGlvbiBvZiBhIHdvcmtpbmcg Z3JvdXAgdGhhdCB3b3VsZCBsYXRlciBiZQ1jYWxsZWQgdGhlIFNOTVAgQ29uZmlndXJhdGlv biBXb3JraW5nIEdyb3VwIChzbm1wY29uZikuDUFkZGl0aW9uYWwgZGV0YWlscyBhYm91dCB0 aGUgd29ya2luZyBncm91cCBjaGFydGVyIGFuZA1hY3Rpdml0aWVzIGNhbiBiZSBmb3VuZCBh dDoNDSAgICAgICAgaHR0cDovL2lldGYub3JnL2h0bWwuY2hhcnRlcnMvc25tcGNvbmYtY2hh cnRlci5odG1sDQ1UaGlzIHBhcGVyIG91dGxpbmVzIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRo ZSBhY3Rpdml0aWVzIGluIHRoZQ1TTk1QIENvbmZpZ3VyYXRpb24gV29ya2luZyBHcm91cCBh bmQgaWxsdXN0cmF0ZXMgaG93IGFuDWVmZmVjdGl2ZSwgZWZmaWNpZW50LCBhbmQgaW50ZWdy YXRlZCBtYW5hZ2VtZW50IHN5c3RlbSBjYW4gYmUNYnVpbHQgdXNpbmcgdGhlIEludGVybmV0 IFN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrLCBTTk1QLg1UaGUgdGVybXMgdXNlZCBp biB0aGlzIHBhcGVyIGhhdmUgYmVlbiBhbGlnbmVkIGFzIG11Y2ggYXMNcG9zc2libGUgd2l0 aCB0aGUgd29yayBpbiB0aGUgUG9saWN5IEZyYW1ld29yayBXb3JraW5nIEdyb3VwDWFzIGFu IGV4YW1wbGUgb2YgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhlIHRocmVlIGdvYWxzDWRlc2Ny aWJlZCBpbiB0aGUgd29ya2luZyBncm91cCBjaGFydGVyIHByZXZpb3VzbHkgY2l0ZWQuDQ1V c2luZyB0aGUgSW50ZXJuZXQgU3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmsgKFNOTVAp IGFzIHRoZQ1mb3VuZGF0aW9uIGZvciBwb2xpY3ktYmFzZWQgY29uZmlndXJhdGlvbiBtYW5h Z2VtZW50IGFzIHdlbGwNYXMgZm9yIG1vcmUgdHJhZGl0aW9uYWwgaW5zdGFuY2UgYmFzZWQg Y29uZmlndXJhdGlvbiAoZS5nLA1zdWNoIGFzIHNldHRpbmcgYW4gSVAgYWRkcmVzcyBvbiBh biBpbnRlcmZhY2UpIHByb3ZpZGVzIGENcG93ZXJmdWwgc29sdXRpb24gdG8gdGhlIHByb2Js ZW0gb2YgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50DXNpbmNlIGl0IFtTTk1QdjNdIGFsc28g aGFzIHRoZSBleHRlbnNpdmUgc2VjdXJpdHkNaW5mcmFzdHJ1Y3R1cmUgdGhhdCBpcyBhbHNv IG5lZWRlZCB0byBlbnN1cmUgdGhhdCByZXNvdXJjZXMgaW4NdGhlIG5ldHdvcmsgYXJlIG9u bHkgdXNlZCBieSB0aG9zZSBhdXRob3JpemVkLiBQb2xpY3ktYmFzZWQNY29uZmlndXJhdGlv biBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBjYW4gYmUgYWNjb21wbGlzaGVkIHVzaW5nDXRoZSBl eGlzdGluZyBTTk1QIGFyY2hpdGVjdHVyZSBhcyBpdCBpcyB0b2RheSB3aXRob3V0IGFueQ1j aGFuZ2VzIHRvIHRoZSBmcmFtZXdvcmsuDQ1UaGUgU05NUCBhcmNoaXRlY3R1cmUgcHJvdmlk ZXMgZm9yIHRoZSBkZWZpbml0aW9uIG9mIG5ldyBNSUINbW9kdWxlcyBhcyBuZWVkcyBhcmlz ZS4gSW4gdGhlIGNhc2Ugb2YgYm90aCBwb2xpY3ktYmFzZWQgYW5kDWluc3RhbmNlLWJhc2Vk IGNvbmZpZ3VyYXRpb24sIGFsbCB0aGF0IGlzIG5lZWRlZCBpcyB0aGUNZGVmaW5pdGlvbiBv ZiBjb25maWd1cmF0aW9uIG9iamVjdHMuIFRoZSBpbXBvcnRhbnQgZGlzdGluY3Rpb24NdG8g YmUgbWFkZSBoZXJlIGlzIHRoYXQgc29tZSBvZiB0aGUgbmV3IG9iamVjdHMgd2lsbCBiZQ1h Z2dyZWdhdGUgKFBvbGljeSkgY29uZmlndXJhdGlvbiBjb21tYW5kcyB0aGF0IGNhbiBjb25j aXNlbHkNY29udmV5IHRvIHRoZSBtYW5hZ2VkIGVsZW1lbnQgYSBzZXJpZXMgb2YgY29uZmln dXJhdGlvbg0NDQ0NDVNhcGVyaWEgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNnRoIDIw MDEgICAgICAgICAgIFtQYWdlIDVdDQwNSW50ZXJuZXQgRHJhZnQgIFBvbGljeSBDb25maWd1 cmF0aW9uIHdpdGggU05NUCAgICBKdWx5IDYsIDIwMDANDQ1jb21tYW5kcyB0aGF0IHNob3Vs ZCBiZSBleGVjdXRlZC4gVGhlIG5ldyBvYmplY3RzIHJlcHJlc2VudA1pbmZvcm1hdGlvbiBh dCBhIGhpZ2hlciBsYXllciBvZiBhYnN0cmFjdGlvbiB0aGFuIGhhcyBiZWVuDWNvbW1vbiBp biBwcmV2aW91cyBNSUIgTW9kdWxlcy4NDUFub3RoZXIgYWR2YW50YWdlIG9mIHVzaW5nIFNO TVAgYXMgdGhlIGZvdW5kYXRpb24gZm9yDWNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudCBpcyB0 aGF0IGl0IG1ha2VzIGl0IGVhc2llciB0byBwZXJmb3JtDW90aGVyIHJlbGF0ZWQgZnVuY3Rp b25zIG9mIGZhdWx0IG9yIHBlcmZvcm1hbmNlIG1hbmFnZW1lbnQuDUNvbnNpZGVyIGhvdyBt dWNoIGVhc2llciBpdCB3aWxsIGJlIHRvIHVuZGVyc3RhbmQgdGhlIGVmZmVjdA1vZiBhbiBp bnRlcmZhY2UgZmFpbHVyZSBvciBhbiBhYm5vcm1hbGx5IHRlcm1pbmF0ZWQgc2VydmVyDXBy b2Nlc3MgaWYgdGhlIG1lY2hhbmlzbSB0aGF0IGNvbmZpZ3VyZWQgdGhlbSB0byBkZWxpdmVy IHNvbWUNcG9saWN5IHN1cHBvcnRpbmcgdXNlcyB0aGUgc2FtZSBuYW1lIHNwYWNlIChNSUIg T2JqZWN0DUlkZW50aWZpZXJzKSBhcyBpcyB1c2VkIGZvciBmYXVsdCBpbmZvcm1hdGlvbi4g Rm9yIGV4YW1wbGUsIGlmDWFuIGludGVyZmFjZSBmYWlscyB0aGF0IGlzIHN1cHBvcnRpbmcg YSBjdXN0b21lciB3aXRoIGENcGFydGljdWxhciBzZXJ2aWNlIGxldmVsIGd1YXJhbnRlZSwg a25vd2luZyB0aGF0IHRoYXQgaW5zdGFuY2UNaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBkZWxp dmVyeSBvZiBhIHBvbGljeSBjYW4gZ3JlYXRseQ1pbXByb3ZlIHRoZSBhYmlsaXR5IHRvIHJh cGlkbHkgdW5kZXJzdGFuZCBob3cgc2VydmljZSBsZXZlbHMNYXJlIGFmZmVjdGVkIGJ5IGZh aWx1cmUgb3Igb3ZlcnN1YnNjcmlwdGlvbi4gIE90aGVyIGFwcHJvYWNoZXMNZG8gbm90IGhh dmUgdGhpcyBkaXJlY3QgY29ubmVjdGlvbi4gVGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQNZWFj aCBpbnN0YW5jZSBvZiBjb25maWd1cmF0aW9uIG9iamVjdCBpbiBlYWNoIGludGVyZmFjZSBt dXN0DWJlIHNlbnQgdG8gdGhlIG1hbmFnZWQgZGV2aWNlLiBSdWxlcyBmb3IgdGhlIGV4cGFu c2lvbiBvZiB0aGUNY29uZmlndXJhdGlvbiBjb21tYW5kcyBjYW4gYmUgZWZmaWNpZW50bHkg dHJhbnNtaXR0ZWQgdG8gdGhlDW1hbmFnZWQgZWxlbWVudCB3aXRoIGp1c3QgYSBmZXcgTUlC IE9iamVjdHMuDQ1MYXRlciBzZWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50IG91dGxpbmUgaG93 IHRoZXNlIG5ldyBvYmplY3RzDXJlbGF0ZSB0byBlYWNoIG90aGVyIGFuZCB0aGUgdGhvdXNh bmRzIG9mIE1JQiBvYmplY3RzIHRoYXQNaGF2ZSBhbHJlYWR5IGJlZW4gZGVmaW5lZCBpbiBS RkNzIGFuZCBhIGxhcmdlIG51bWJlciBvZiB2ZW5kb3INc3BlY2lmaWMgTUlCIE1vZHVsZXMu DQ0NDTQuICBEZWZpbml0aW9uIG9mIFRlcm1zDQ0NDTQuMS4gIERlZmluaW5nIHRoZSBUZXJt IFBvbGljeQ0NT25lIGRpZmZpY3VsdHkgZm9yIHRoZSBhZHZhbmNlbWVudCBvZiBwb2xpY3kt YmFzZWQNY29uZmlndXJhdGlvbiBhbmQgY29udHJvbCBvZiBuZXR3b3JrcyBpcyB0aGUgZGVm aW5pdGlvbiBvZg10ZXJtcy4gVGhlIHNpbmdsZSBtb3N0IHByb2JsZW1hdGljIHRlcm0gaXMg cG9saWN5LiBUbyBiZWdpbiwNcG9saWN5LWJhc2VkIG1hbmFnZW1lbnQgaXMgc2ltcGx5IGEg cGFydGljdWxhciB0eXBlIG9mDWNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudC4gVGhlIGRpc3Rp bmN0aW9uIGhlcmUgaXMgdGhhdCBvZnRlbg10aGUgcG9saWN5IGlzIGV4cHJlc3NlZCBpbiB0 ZXJtcyB0aGF0IGFyZSBuZWl0aGVyIGluc3RhbmNlIG9yDXRlY2hub2xvZ3kgc3BlY2lmaWMu IFRoZSBjb25maWd1cmF0aW9uIG1hbmFnZW1lbnQgdGhhdCB3ZSBhcmUNbW9zdCBmYW1pbGlh ciB3aXRoLCB3aGVyZSB3ZSBtaWdodCBzZXQgdGhlIElQIGFkZHJlc3MgZm9yIGFuDWludGVy ZmFjZSwgdGVuZHMgdG8gYmUgdGVjaG5vbG9neSBhbmQgaW5zdGFuY2Utc3BlY2lmaWMuIFdo YXQNDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAg ICAgICAgICBbUGFnZSA2XQ0MDUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlv biB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NdGhpcyBtZWFucyBpcyB0aGF0IHRoZSBj b25maWd1cmF0aW9uIHNvZnR3YXJlIGtub3dzIGFib3V0IHRoZQ1mb3JtYXQgb2YgYW4gSVAg YWRkcmVzcyBhbmQgaG93IHRvIHNlbmQgaXQgdG8gdGhlIG1hbmFnZWQNZGV2aWNlIHNvIHRo YXQgaXQgZ2V0cyBhcHBsaWVkIHRvIGV4YWN0bHkgdGhlIGludGVyZmFjZQ1kZXNpcmVkLg0N DTQuMS4xLiAgV2hhdCBpcyBhIFBvbGljeSBhbmQgaG93IGRvZXMgaXQgcmVsYXRlIHRvDUNv bmZpZ3VyYXRpb24/DQ1QYXJ0IG9mIHRoZSBkaWZmaWN1bHR5IHdpdGggcG9saWN5IGRpc2N1 c3Npb25zIGhhcyBiZWVuIHRoYXQNcG9saWN5IGlzIG9mdGVuIHVzZWQgdG8gZGVzY3JpYmUg c2V2ZXJhbCBkaWZmZXJlbnQgY29uY2VwdHMuDVRoaXMgb3ZlcmxvYWRpbmcgaW1wYWlycyBv dXIgYWJpbGl0eSB0byBjb21tdW5pY2F0ZS4NDVdoYXQgaXMgb2Z0ZW4gdW5jbGVhciBpcyB0 aGUgbGV2ZWwgb2YgZGV0YWlsIG9yIGFic3RyYWN0aW9uDXRoYXQgdGhlIHNwZWFrZXIgaW50 ZW5kcy4gIEZvciBtYW55IHBlb3BsZSwgcG9saWN5IG1lYW5zDWJ1c2luZXNzIGxldmVsIG9y IHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50IGV4cHJlc3Npb25zLiBGb3INb3RoZXJzLCBwb2xp Y3kgbWVhbnMgY29uZmlndXJhdGlvbiBvZiBvbmUgb3IgbW9yZSBlbGVtZW50cyBpbg1hIG5l dHdvcmsgdG8gYmVoYXZlIGEgY2VydGFpbiB3YXkuIEZvciBtYW55IHRoYXQgaGF2ZSB0aG91 Z2h0DWFib3V0IHRoZSBpc3N1ZSwgcG9saWN5IGlzIG9uIGEgY29udGludXVtIHRoYXQgcmFu Z2VzIGZyb20NdmVyeSBoaWdoIGxldmVsIGJ1c2luZXNzIGFic3RyYWN0aW9ucyB0byB2ZXJ5 IGxvdyBsZXZlbCBkZXZpY2UNY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiBUaGUgZGlzdGlu Y3Rpb24gYmV0d2VlbiBhbGwgdGhlc2UNZGlmZmVyZW50IGxldmVscyBvZiBhYnN0cmFjdGlv biBpcyB0aGUgZGV0YWlsIGFzc29jaWF0ZWQgd2l0aA10aGUgZXhwcmVzc2lvbiBvZiB0aGUg cG9saWN5Lg0NDTQuMS4yLiAgVGVybXMgYW5kIFJlbGF0aW9uc2hpcCB0byBQb2xpY3kgRnJh bWV3b3JrIFdvcmtpbmcNR3JvdXANDU11Y2ggb2YgdGhlIGluZm9ybWF0aW9uIGluIHRoaXMg c2VjdGlvbiBpcyBhbiBhZGFwdGF0aW9uIGFuZA1leHBhbnNpb24gb2YgYSBwcmVzZW50YXRp b25zIGdpdmVuIGF0IHRoZSA0N3RoIElFVEYgaW4gZHVyaW5nDXRoZSBQb2xpY3kgRnJhbWV3 b3JrIFdvcmtpbmcgR3JvdXAgc2Vzc2lvbi4gQnkgYWRvcHRpbmcgdGVybXMNdXNlZCBieSB0 aGUgUG9saWN5IEZyYW1ld29yayBXb3JraW5nIEdyb3VwIHdoZXJldmVyIGZlYXNpYmxlOw10 aGUgU05NUCBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAgaG9wZXMgdG8gcmVkdWNlIHRo ZQ10ZXJtaW5vbG9neSBjb25mdXNpb24gdGhhdCBoYXMgZXhpc3RlZCBpbiB0aGlzIGFyZWEu IFdvcmsgaXMNb25nb2luZyBpbiB0aGUgU05NUCBDb25maWd1cmF0aW9uIGFuZCBQb2xpY3kg RnJhbWV3b3JrIGdyb3Vwcw1hcyB3ZWxsIGFzIG90aGVyczsgc28gc29tZSBjaGFuZ2UgaXMg aW5ldml0YWJsZS4gSGVyZSBhcmUNdGVybXMgdGhhdCBhcmUgdXNlZCB0byBkZXNjcmliZSBw b2xpY3kgaW5mb3JtYXRpb24gYXQNZGlmZmVyZW50IGxldmVscyBvZiBhYnN0cmFjdGlvbiBt b3ZpbmcgZnJvbSB0aGUgbW9zdCBnZW5lcmFsDXRvIHRoZSBtb3N0IHNwZWNpZmljLg0NDVsx XSAgRG9tYWluLVNwZWNpZmljLiBBIGRvbWFpbiBpcyBhIGdlbmVyYWwgYXJlYSBvZiB0ZWNo bm9sb2d5DSAgICAgc3VjaCBhcyBzZXJ2aWNlIHF1YWxpdHkgb3Igc2VjdXJpdHkuIFNlcnZp Y2VzLCBvciBzZXJ2aWNlDSAgICAgbGV2ZWwgYWdyZWVtZW50cywgbWF5IHNwYW4gc2V2ZXJh bCBkb21haW5zLCBlYWNoIG9mIHRoZW0NICAgICBwb3RlbnRpYWxseSBpbmNsdWRpbmcgbWFu eSBwb2xpY2llcy4gQXMgYSBnZW5lcmFsIHJ1bGUsDQ0NDQ0NU2FwZXJpYSAgICAgICAgICAg IEV4cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICAgW1BhZ2UgN10NDA1JbnRlcm5l dCBEcmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwgMjAw MA0NDSAgICAgcGVvcGxlIHdpbGwgbm90IGRpc2N1c3MgdGhlc2UgZG9tYWlucyBpbiB0aGUg YWJzdHJhY3QuDSAgICAgVGhleSB3aWxsIG1vc3Qgb2Z0ZW4gYmUgZGlzY3Vzc2VkIHdpdGgg dGVjaG5vbG9neSBvcg0gICAgIGFwcGxpY2F0aW9uLXNwZWNpZmljIGV4YW1wbGVzLiBFeGFt cGxlcyBvZiB0ZWNobmljYWwNICAgICBkb21haW5zIGluY2x1ZGUsIElQU2VjIGFuZCBEaWZm ZXJlbnRpYXRlZCBTZXJ2aWNlcy4gV2hlbg0gICAgIGV4cHJlc3NlZCBpbiB0ZXJtcyBzcGVj aWZpYyB0byBhIHBhcnRpY3VsYXIgZG9tYWluLCBhDSAgICAgcG9saWN5IGlzIHNhaWQgdG8g YmUgYXQgdGhlIERvbWFpbiBTcGVjaWZpYyBsZXZlbCBvZg0gICAgIGRldGFpbC4NDQ0gICAg IFRoZXJlIGlzIGxpdHRsZSBpbiBjb21tb24gYmV0d2VlbiBob3cgb25lIHdvdWxkIGNvbmZp Z3VyZQ0gICAgIGRpZmZlcmVudGlhdGVkIHNlcnZpY2VzIHdpdGggaG93IG9uZSB3b3VsZCBj b25maWd1cmUNICAgICBJUFNlYyBbSVBTRUNdLiBUaGV5IG1heSBib3RoIGJlIHJlcXVpcmVk IGZvciBhIHBhcnRpY3VsYXINICAgICBzZXJ2aWNlIGFncmVlbWVudCBob3dldmVyLiBGb3Ig ZXhhbXBsZSwgcGVvcGxlIHdobyB3YW50DSAgICAgdG8gdXNlIGEgdm9pY2Ugb3ZlciBJUCBh cHBsaWNhdGlvbiBtaWdodCBhbHNvIHdhbnQgdG8NICAgICBlbnN1cmUgYSBjZXJ0YWluIGxl dmVsIG9mIHNlY3VyaXR5IGZvciB0aGVzZQ0gICAgIGNvbW11bmljYXRpb25zLg0NDVsyXSAg TWVjaGFuaXNtLVNwZWNpZmljLiBNZWNoYW5pc21zIGFyZSB0ZWNobm9sb2dpZXMgdXNlZA0g ICAgIHdpdGhpbiBhIHBhcnRpY3VsYXIgZG9tYWluLiBGb3IgZXhhbXBsZSwgaW4gdGhlDSAg ICAgZGlmZmVyZW50aWF0ZWQgc2VydmljZXMgZG9tYWluLCBSRUQgKFJhbmRvbSBFYXJseQ0g ICAgIERldGVjdGlvbikgb3IgV1JFRCAoV2VpZ2h0ZWQgUmFuZG9tIEVhcmx5IERldGVjdGlv bikNICAgICBtaWdodCBiZSB1c2VkIGFzIG9uZSBvZiB0aGUgbWVjaGFuaXNtcyB0aGF0IGRl dmljZXMNICAgICBlbXBsb3kgdG8gc3VwcG9ydCBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNlcyBh bmQgdGhlDSAgICAgYXBwbGljYXRpb25zIG9uIHdoaWNoIHRoZXkgcmVseS4gUG9saWN5IGRl c2NyaXB0aW9ucyB0aGF0DSAgICAgaW5jbHVkZSB0aGUgZGV0YWlscyBhc3NvY2lhdGVkIHdp dGggYSBwYXJ0aWN1bGFyDSAgICAgbWVjaGFuaXNtLCBhcmUgc2FpZCB0byBiZSBtZWNoYW5p c20tc3BlY2lmaWMuDQ0NWzNdICBJbXBsZW1lbnRhdGlvbi1TcGVjaWZpYy4gaW1wbGVtZW50 YXRpb24tc3BlY2lmaWMgZGV0YWlscw0gICAgIGFyZSB0aG9zZSBwYXJhbWV0ZXJzIHRoYXQg YSBwYXJ0aWN1bGFyIHZlbmRvciBtaWdodCB1c2UNICAgICBpbiBhbiBpbXBsZW1lbnRhdGlv biB0aGF0IGF1Z21lbnQgYSBzdGFuZGFyZCBzZXQgb2YNICAgICBtZWNoYW5pc20tc3BlY2lm aWMgcGFyYW1ldGVycy4gVmVuZG9ycyBvZnRlbiBhZGQgc3BlY2lhbA0gICAgIGNhcGFiaWxp dGllcyB0byBiYXNpYyBtZWNoYW5pc21zIGFzIGEgd2F5IG9mIG1lZXRpbmcNICAgICBzcGVj aWFsIGN1c3RvbWVyIHJlcXVpcmVtZW50cyBvciBkaWZmZXJlbnRpYXRpbmcNICAgICB0aGVt c2VsdmVzIGZyb20gdGhlaXIgY29tcGV0aXRvcnMuIFRoZXNlIHNwZWNpYWwNICAgICBjYXBh YmlsaXRpZXMgYXJlIG9mdGVuIGEgcmVzdWx0IG9mIHRoZSBpbXBsZW1lbnRhdGlvbg0gICAg IGFwcHJvYWNoIHRoYXQgYSB2ZW5kb3IgaGFzIHVzZWQgZm9yIHRoZSBwcm9kdWN0LCB0aHVz IHRoZQ0gICAgIHRlcm0sIGltcGxlbWVudGF0aW9uLXNwZWNpZmljLiBGb3IgZXhhbXBsZSwg aWYgYSByb3V0ZXINICAgICB2ZW5kb3IgaW1wbGVtZW50ZWQgYSBwYXJ0aWN1bGFyIHJvdXRp bmcgcHJvdG9jb2wsIHRoZXkNICAgICB3b3VsZCBoYXZlIHRoZSBtZWNoYW5pc20tc3BlY2lm aWMgcGFyYW1ldGVycyB0aGF0IGNvbnRyb2wNICAgICB0aGUgYmVoYXZpb3Igb2YgdGhhdCBz b2Z0d2FyZS4gVGhlIHZlbmRvciBtaWdodCBoYXZlDSAgICAgY2hvc2VuIHRvIHJ1biBzZXZl cmFsIGluc3RhbmNlcyBvZiB0aGF0IHJvdXRpbmcgcHJvdG9jb2wsDSAgICAgcGVyaGFwcyBv biBkaWZmZXJlbnQgcHJvY2Vzc29ycywgZm9yIHBlcmZvcm1hbmNlIHJlYXNvbnMuDSAgICAg VGhlIHBhcmFtZXRlcnMgdGhhdCBhcmUgdXNlZCB0byBjb250cm9sIHRoZSBkaXN0cmlidXRp b24NDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAg ICAgICAgICBbUGFnZSA4XQ0MDUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlv biB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NICAgICBvZiB3b3JrIG9uIHRoZSBkaWZm ZXJlbnQgcHJvY2Vzc29ycyBmb3IgdGhhdCBwcm90b2NvbA0gICAgIHdvdWxkIGJlIGltcGxl bWVudGF0aW9uLXNwZWNpZmljLg0NDVs0XSAgSW5zdGFuY2UtU3BlY2lmaWMuIE5ldHdvcmsg b3BlcmF0b3JzIGFyZSBtb3N0IGZhbWlsaWFyDSAgICAgYW5kIGNvbWZvcnRhYmxlIHdpdGgg aW5mb3JtYXRpb24gb2YgdGhpcyB0eXBlLiBJbnN0YW5jZS0NICAgICBzcGVjaWZpYyBpbmZv cm1hdGlvbiByZWZlcnMgdG8gcGFyYW1ldGVyIHZhbHVlcyB0aGF0IGhhdmUNICAgICBiZWVu IGFzc29jaWF0ZWQgd2l0aCBhIHNwZWNpZmljIGluc3RhbmNlIGluIGEgbWFuYWdlZA0gICAg IGVsZW1lbnQuIEZvciBleGFtcGxlLCBUaGUgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wgaXMg YQ0gICAgIHJvdXRpbmcgcHJvdG9jb2wgdGhhdCBoYXMgYSBudW1iZXIgb2YgcGFyYW1ldGVy cyB0aGF0DSAgICAgZGVzY3JpYmUgaW5mb3JtYXRpb24gYWJvdXQgYSBwYXJ0aWN1bGFyIHJv dXRlcidzIHZpZXcgb2YNICAgICBvdGhlciByb3V0ZXJzIHRoYXQgaXQgaXMgc2hhcmluZyBp bmZvcm1hdGlvbiB3aXRoLCBwZWVyDSAgICAgcm91dGVycy4gT25lIHN1Y2ggcGFyYW1ldGVy IGRlZmluZWQgaW4gdGhlIEJHUCBNSUIgTW9kdWxlDSAgICAgW0JHUCBNSUJdIGlzIHRoZSBk ZXNpcmVkIGNvbm5lY3Rpb24gcmV0cnkgaW50ZXJ2YWwgZm9yIGENICAgICBwZWVyLCBiZ3BQ ZWVyQ29ubmVjdFJldHJ5SW50ZXJ2YWwuIEFuIGV4YW1wbGUgdmFsdWUgd291bGQNICAgICBi ZSAxMjAgKHNlY29uZHMpLiBXaGVuIGV4cHJlc3NlZCB3aXRoIHRoaXMgbGV2ZWwgb2YNICAg ICBzcGVjaWZpY2l0eSwgb25lIHdvdWxkIHNheSB0aGF0IHRoaXMgaXMgbWVjaGFuaXNtLQ0g ICAgIHNwZWNpZmljIGRhdGEuIElmIHdlIHdlcmUgdG8gc2VlIGEgdmFsdWUgb2YNICAgICBi Z3BQZWVyQ29ubmVjdFJldHJ5SW50ZXJ2YWwuMTAuMC4wLjEgPSAxMjAgd2Ugd291bGQgYmUN ICAgICBsb29raW5nIGF0IHRoZSByZXRyeSBpbnRlcnZhbCBvZiB0aGUgcGVlciByb3V0ZXIg Zm91bmQgYXQNICAgICBJUCBhZGRyZXNzIDEwLjAuMC4xLiBUaGUgdmFsdWUgZm9yIHRoaXMg aW5zdGFuY2UgaXMgMTIwDSAgICAgc2Vjb25kcywgaW5zdGFuY2Utc3BlY2lmaWMgZGF0YS4N DQ0gICAgIE9uZSBvZiB0aGUgZ29hbHMgb2YgcG9saWN5LWJhc2VkIChjb25maWd1cmF0aW9u KQ0gICAgIG1hbmFnZW1lbnQgaXMgdG8gaW1wcm92ZSB0aGUgZWZmaWNpZW5jeSBvZiBjb25m aWd1cmF0aW9uDSAgICAgb3BlcmF0aW9ucy4gVGhpcyBpcyBhY2NvbXBsaXNoZWQgaW4gcGFy dCBieSBlbGltaW5hdGluZw0gICAgIHRoZSBuZWNlc3NpdHkgb2Ygc2VuZGluZyB0byB0aGUg bWFuYWdlZCBkZXZpY2UgYQ0gICAgIGNvbmZpZ3VyYXRpb24gb2JqZWN0IGZvciBldmVyeSBp bnN0YW5jZSBvZiB0aGF0IG9iamVjdCBpbg0gICAgIGEgc3lzdGVtLiBGb3IgZXhhbXBsZSwg aWYgd2Ugd2FudGVkIHRvIGNoYW5nZSBvbmUgb2YgdGhlDSAgICAgQkdQIHBhcmFtZXRlcnMg cmVmZXJlbmNlZCBhYm92ZSBvbiBhIGxhcmdlIHN5c3RlbSBmb3INICAgICBlYWNoIGludGVy ZmFjZSB0aGF0IGlzIHN1cHBvcnRpbmcgdGhlIEJHUCwgdGhlcmUgbWF5IGJlDSAgICAgbWFu eSBpbmRpdmlkdWFsIGNvbW1hbmRzIG5lZWRlZCB0byBhY2NvbXBsaXNoIHRoaXMgdGFzay4N ICAgICBJZiBhIGNvbW1hbmQgbGluZSBpbnRlcmZhY2Ugd2VyZSB1c2VkIGFzIHRoZSBwcmlt YXJ5DSAgICAgY29uZmlndXJhdGlvbiB0b29sIGluIHRoaXMgZXhhbXBsZSwgbWFueSBjb25m aWd1cmF0aW9uDSAgICAgY29tbWFuZHMgd291bGQgYmUgbmVlZGVkIGFzIHdlbGwuDQ0NICAg ICBXaGVuIHdlIHNheSB0aGF0IGEgYSBwb2xpY3kgaXMgYXQgdGhlIGluc3RhbmNlDSAgICAg aW5kZXBlbmRlbnQgbGV2ZWwgb2YgYWJzdHJhY3Rpb24sIHdlIG1lYW4gdGhhdCB0aGUgdmFs dWUNICAgICBmb3IgYSBwYXJ0aWN1bGFyIHBhcmFtZXRlciBpcyBpbmRlcGVuZGVudCBvZiB0 aGUNICAgICBpbnN0YW5jZXMgdG8gd2hpY2ggaXQgd2lsbCBiZSBhcHBsaWVkLg0NICAgICBU byBtYWtlIHRoaW5ncyBtb3JlIGNvbmNyZXRlLCBjb25zaWRlciBhIHZvaWNlIG92ZXIgSVAN ICAgICBhcHBsaWNhdGlvbi4gSW4gb3JkZXIgdG8gJ21ha2UgdGhlIHNhbGUnLCB0aGUgc2Vy dmljZQ0NDQ0NDVNhcGVyaWEgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNnRoIDIwMDEg ICAgICAgICAgIFtQYWdlIDldDQwNSW50ZXJuZXQgRHJhZnQgIFBvbGljeSBDb25maWd1cmF0 aW9uIHdpdGggU05NUCAgICBKdWx5IDYsIDIwMDANDQ0gICAgIHByb3ZpZGVyIG11c3QgZ3Vh cmFudGVlIGNlcnRhaW4gY2hhcmFjdGVyaXN0aWNzIG9mIHRoZQ0gICAgIHRyYWZmaWMgdG8g dGhlIGN1c3RvbWVyLiBBdCBhIGJ1c2luZXNzIG9yIG5vbi10ZWNobmljYWwNICAgICBsZXZl bCwgd2hhdCB0aGUgY3VzdG9tZXIgbWF5IHdhbnQgaXMgdGhhdCB0aGUgdm9pY2Ugb3Zlcg0g ICAgIElQIGFwcGxpY2F0aW9uIHRyYWZmaWMgY2FycmllZCBieSB0aGUgc2VydmljZSBwcm92 ZXIgaGFzDSAgICAgdGhlIHNhbWUgZ2VuZXJhbCBjaGFyYWN0ZXJpc3RpY3MgYXMgcmVndWxh ciB0ZWxlcGhvbmUNICAgICBzZXJ2aWNlLiBNb3JlIHNwZWNpZmljYWxseSwgaGlzIG1pZ2h0 IGJlIGV4cHJlc3NlZCBhcw0gICAgICdBdXRob3JpemVkIElQIHBob25lIGNhbGxzIGdldCBl bm91Z2ggYmFuZHdpZHRoIGFuZA0gICAgIGxhdGVuY3kgYW5kIGppdHRlciBjb250cm9sIGZv ciBURE0gKHRpbWUtZGl2aXNpb24NICAgICBtdWx0aXBsZXhpbmcpIGVxdWl2YWxlbnQgdGVs ZXBob25lIHNlcnZpY2UnLiBXaGlsZSB0aGlzDSAgICAgaXMgaW1wb3J0YW50IGZyb20gYSBi dXNpbmVzcyBwZXJzcGVjdGl2ZSwgaXQgZG9lcyBub3Qgc2F5DSAgICAgbXVjaCBhYm91dCBo b3cgdGhlIG5ldHdvcmsgd291bGQgYmUgY29uZmlndXJlZCB0byBkZWxpdmVyDSAgICAgdGhp cyB0eXBlIG9mIHNlcnZpY2UuICBUaGlzIGlzIHdoZXJlIHRoZSBhZGRpdGlvbmFsDSAgICAg bGV2ZWxzIG9mIGRldGFpbCBhcmUgcmVxdWlyZWQuIFRoZSBpbmNyZWFzaW5nIGxldmVscyBv Zg0gICAgIGRldGFpbCB0aGF0IGFyZSBuZWVkZWQgdG8gZnVsbHkgc3BlY2lmeSB0aGlzIHNl cnZpY2UgYWxsDSAgICAgdGhlIHdheSBkb3duIHRvIHNwZWNpZmljIHZhbHVlcyBmb3Igc3Bl Y2lmaWMgaW5zdGFuY2VzDSAgICAgYXJlIGlsbHVzdHJhdGVkIGluIHRoZSBmb2xsb3dpbmcg dGFibGUgdXNpbmcgdGhlIHRlcm1zIHdlDSAgICAgaGF2ZSBkZWZpbmVkOg0NICAgICBUQUJM RSAxLiBJbmNyZWFzaW5nIERldGFpbCBmb3IgRWFjaCBMZXZlbCBvZiBBYnN0cmFjdGlvbg0N ICAgICBTZWUgLnBzIHZlcnNpb24gb2YgdGhpcyBwYXBlciBmb3IgdGFibGUgd2l0aCBncmFw aGljcy4NDSAgICAgRG9tYWluLVNwZWNpZmljIChEaWZmU2VydiBpcyB1c2VkIGZvciBvdXIg ZXhhbXBsZXMpOg0NICAgICAgICAgICAgIGlmIHNvdXJjZUlQQWRkcmVzcyA9PSAxNzIuMy4x MjguMC8xNSwgJiYgRFNDUCA9PSAxMDExMTAgVEhFTg0gICAgICAgICAgICAgbWFyayB2b2lj ZSB0cmFmZmljIHdpdGggRXhwZWRpdGVkIEZvcndhcmRpbmcuDQ0gICAgIE1lY2hhbmlzbS1T cGVjaWZpYzoNDSAgICAgICAgICAgICBGb3IgRFNDUCB2YWx1ZSA9PSAxMDExMTAgdGhlbiBz ZXQgUmFuZG9tIERyb3ANICAgICAgICAgICAgIFBhcmFtZXRlcnMgKGUuZy4sIFJFRCkgdG8g YmUgUU1pbiAobWluaW11bSBxdWV1ZSBzaXplKSA9IDAgYW5kDSAgICAgICAgICAgICBQTWlu IChsb3dlc3QgZHJvcCBwcm9iYWJpbGl0eSkgPSAwIGFuZCBRTWF4IChtYXhpbXVtIFF1ZXVl IFNpemUpDSAgICAgICAgICAgICA9IDUsIGFuZCBQTWF4IChtYXhpbXVtIGRpc2NhcmQgcHJv YmFiaWxpdHkgPSAxMDApLiBUaGVyZSBpcyBubw0gICAgICAgICAgICAgTUlCIE1vZHVsZSBm b3IgUkVEIGN1cnJlbnRseSBkZWZpbmVkLCBidXQgdG8gY2Fycnkgb3VyIGV4YW1wbGUNICAg ICAgICAgICAgIGZ1cnRoZXIgd2UgY291bGQgY3JlYXRlIE1JQiBPYmplY3RzIHRoYXQgd291 bGQgY29udGFpbiB0aGVzZQ0gICAgICAgICAgICAgZGVmYXVsdCB2YWx1ZXM6DQ0gICAgICAg ICAgICAgUU1pbiA9IDAgUE1pbiA9IDAsIFFNYXggPSA1LCBQTWF4ID0gMTAwDQ0gICAgIElt cGxlbWVudGF0aW9uLVNwZWNpZmljOg0NICAgICAgICAgICAgIEluIHRoaXMgZXhhbXBsZSB3 ZSBhcmUgbm90IGFkZGluZyBhbnkgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMNICAgICAgICAg ICAgIHBhcmFtZXRlcnMuIFdlcmUgdGhleSBuZWVkZWQsIHRoZXkgd291bGQgYXBwZWFyIGF0 IHRoaXMNICAgICAgICAgICAgIGxldmVsLiBPbmUgbWlnaHQgc2VlIHRoZW0gYXMgYXVnbWVu dGF0aW9ucyB0byB0aGUgdGFibGUgc2hvd24gaW4NICAgICAgICAgICAgIHRoZSBtZWNoYW5p c20tc3BlY2lmaWMgbGV2ZWwuDQ0NDQ0NU2FwZXJpYSAgICAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAxMF0NDA1JbnRlcm5ldCBEcmFmdCAgUG9s aWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwgMjAwMA0NDSAgICAgSW5z dGFuY2UtU3BlY2lmaWM6DQ0gICAgICAgICAgICAgQXQgdGhpcyBsZXZlbCBvZiBhYnN0cmFj dGlvbiwgdGhlIHNwZWNpZmljIHZhbHVlcyBmb3IgZWFjaA0gICAgICAgICAgICAgaW5zdGFu Y2Ugb2YgZWFjaCBxdWV1ZSB0aGF0IGhhcyBiZWVuIHNlbGVjdGVkIHRvIGVuZm9yY2UgdGhl DSAgICAgICAgICAgICBwb2xpY3kgd291bGQgYmUgdmlzaWJsZS4gIElmIHRoZXJlIHdlcmUg anVzdCAxMCBxdWV1ZXMgdGhhdA0gICAgICAgICAgICAgd291bGQgYmUgNDAgb2JqZWN0cyB3 aXRoIGp1c3QgdGhlIDQgb2JqZWN0cyB0aGF0IHdlcmUgc3BlY2ktDSAgICAgICAgICAgICBm aWVkIGluIHRoZSBwcmV2aW91cyBsZXZlbC4gSW4gb3VyIGZpY3Rpb25hbCBSRUQgTUlCIE1v ZHVsZSB3ZQ0gICAgICAgICAgICAgd291bGQgaGF2ZSBhIHRhYmxlIHRoYXQgbG9va2VkIGlu IHBhcnQgbGlrZToNDSAgICAgICAgICAgICAgSW5kZXggICAgICAgICAgICAgUU1pbiAgICBQ TWluICAgICAgUU1heCAgICAgICAgUE1heA0NICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgIDAgICAgICAgIDAgICAgICAgICA1ICAgICAgICAgMTAwDQ0gICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgMCAgICAgICAgMCAgICAgICAgIDUgICAgICAgICAxMDAN DSAgICAgICAgICAgICAgICAzICAgICAgICAgICAgICAgICAwICAgICAgICAwICAgICAgICAg NSAgICAgICAgIDEwMA0NICAgICAgICAgICAgICAgIDQgICAgICAgICAgICAgICAgIDAgICAg ICAgIDAgICAgICAgICA1ICAgICAgICAgMTAwDQ0gICAgICAgICAgICAgICAgLi4uLi4uLi4u Li4NDTQuMS4zLiAgTGV2ZWxzIG9mIEFic3RyYWN0aW9uDQ1BIHBvbGljeSBtYW5hZ2VtZW50 IHN5c3RlbSBtdXN0IGJlIGFibGUgdG8gd29yayB3aXRoDWluZm9ybWF0aW9uIGF0IGFsbCB0 aGVzZSBsZXZlbHMgb2YgYWJzdHJhY3Rpb24gZnJvbSB0aGUgZG9tYWluDXRvIGluc3RhbmNl LXNwZWNpZmljIHNpbmNlIHRoZXkgYXJlIHNvIGNsb3NlbHkgaW50ZXJyZWxhdGVkLiBBDXBv bGljeSBzeXN0ZW0gbXVzdCBhbHNvIG1ha2UgaXQgZWFzeSB0byBtb3ZlIGFuZCBtYXAgZnJv bSBvbmUNbGV2ZWwgb2YgYWJzdHJhY3Rpb24gdG8gYW5vdGhlci4NDUFzIG9uZSBtb3ZlcyBm cm9tIHRoZSBsZWFzdCBzcGVjaWZpYyB0byB0aGUgbW9zdCBzcGVjaWZpYw1sZXZlbCBvZiBk ZXRhaWwsIHRoZSBpbnN0YW5jZS1zcGVjaWZpYywgdGhlIGxvd2VyIGxheWVyDWRlcGVuZHMg b24gdGhlIGxheWVycyBhYm92ZS4gSW4gdGhlIEJHUCBleGFtcGxlIHdlIHVzZWQNZWFybGll ciBpdCB3b3VsZCBtYWtlIGxpdHRsZSBzZW5zZSB0byB0YWxrIGFib3V0IGEgZGF0YSB2YWx1 ZQ1vZiAxMjAgd2l0aG91dCBrbm93aW5nIHdoYXQgdGhlIHZhbHVlIHdhcyBkZXNjcmliaW5n LiBXZSB1c2UNdGhlIHRlcm1zIGRlcGVuZGVudCBhbmQgaW5kZXBlbmRlbnQgdG8gZGVzY3Jp YmUgdGhpcw1yZWxhdGlvbnNoaXAuIEhlcmUgaXMgYW4gZXhhbXBsZXMgZnJvbSB0aGUgcHJl dmlvdXMgdGFibGU6DQ0NICAgIDEuIERvbWFpbiBEZXBlbmRlbnQsIG1lY2hhbmlzbSwgaW1w bGVtZW50YXRpb24gYW5kIGluc3RhbmNlDSAgICBpbmRlcGVuZGVudC4gSWYgc291cmNlSVBB ZGRyZXNzID09IDE3Mi4zLjEyOC4wLzE1LCAmJiBEU0NQID09IDEwMTExMA0gICAgVEhFTiBt YXJrIHZvaWNlIHRyYWZmaWMgd2l0aCBFeHBlZGl0ZWQgRm9yd2FyZGluZy4gQXQgdGhpcyBs ZXZlbCBvZg0gICAgYWJzdHJhY3Rpb24sIG5vdGljZSB0aGF0IHRoaXMgcG9saWN5IGhhcyBu b3QgYmVlbiBhcHBsaWVkIHRvIGFueQ0gICAgc3BlY2lmaWMgZGV2aWNlLCBub3IgaGFzIHRo ZSBzcGVjaWZpYyBtZWNoYW5pc20gdGhyb3VnaCB3aGljaCB0aGUNICAgIEV4cGVkaXRlZCBG b3J3YXJkaW5nIGlzIHRvIGJlIHJlYWxpemVkIGJlZW4gZGVmaW5lZC4gV2UgaGF2ZSBzaW1w bHkNICAgIG1vdmVkIHRvIGEgbW9yZSBzcGVjaWZpYyBsZXZlbCBvZiBhYnN0cmFjdGlvbi4g SW4gdGhpcyBjYXNlIHdlIGhhdmUNDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdlIDExXQ0MDUludGVybmV0IERyYWZ0ICBQ b2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NICAgIHNl bGVjdGVkIGEgc3BlY2lmaWMgdGVjaG5vbG9neSBhcmVhLCBEaWZmZXJlbnRpYXRlZCBTZXJ2 aWNlcyBzaW5jZQ0gICAgd2UgYXJlIHVzaW5nIEV4cGVkaXRlZCBGb3J3YXJkaW5nLCBhIHRl cm0gZGVmaW5lZCB3aXRoaW4gdGhhdA0gICAgdGVjaG5vbG9neSBhcmVhDQ0gICAgMi4gTWVj aGFuaXNtIERlcGVuZGVudCBhbmQgSW1wbGVtZW50YXRpb24gYW5kIEluc3RhbmNlIEluZGVw ZW5kZW50LiBJZg0gICAgRFNDUCB2YWx1ZSA9PSAxMDExMTAgdGhlbiBzZXQgUmFuZG9tIERy b3AgUGFyYW1ldGVycyAoZS5nLiwgUkVEKSB0bw0gICAgYmUgUU1pbiAobWluaW11bSBxdWV1 ZSBzaXplKSA9IDAgYW5kIFBNaW4gKGxvd2VzdCBkcm9wIHByb2JhYmlsaXR5KQ0gICAgPSAw IGFuZCBRTWF4IChtYXhpbXVtIFF1ZXVlIFNpemUpID0gNSwgZXRjLiAgTm90aWNlIHRoYXQg dGhpcw0gICAgaW5mb3JtYXRpb24gaXMgZGVwZW5kZW50IG9uIG1lY2hhbmlzbS1zcGVjaWZp Y3MgYnV0IG5vdCBvbiBhbnkNICAgIGltcGxlbWVudGF0aW9uIG9yIGluc3RhbmNlIGluZm9y bWF0aW9uLg0NQSBwb2xpY3kgY2FuIGJlIGV4cHJlc3NlZCwgYXQgbGVhc3QgaW4gdGhlb3J5 LCBpbiBhDW1lY2hhbmlzbS1zcGVjaWZpYyBhbmQgaW1wbGVtZW50YXRpb24taW5kZXBlbmRl bnQgZmFzaGlvbi4NUmVmZXIgYmFjayB0byB0aGUgUkVEIG1lY2hhbmlzbSBpbiB0aGUgdGFi bGUsIHRoZXJlIGFyZQ1zZXZlcmFsIHBhcmFtZXRlcnMgdGhhdCB3aWxsIHJlcXVpcmUgY29u ZmlndXJhdGlvbiB0byBhY2hpZXZlDWEgcGFydGljdWxhciByZXN1bHQuIFBlb3BsZSB3b3Vs ZCBsaWtlIHRvIGV4cHJlc3MgcG9saWN5DWNvbmZpZ3VyYXRpb24gaW4gc3VjaCBhIG1lY2hh bmlzbSBpbmRlcGVuZGVudCB3YXkgdG8gbWFrZSB3b3JrDXNpbXBsZXIuIFRoZSBkZXRhaWxz IG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBmcm9tIG9uZSBkZXZpY2UgdG8NYW5vdGhlciwgZXZl biB3aGVuIHRoZSBkZXZpY2VzIGNvbWUgZnJvbSB0aGUgc2FtZSB2ZW5kb3IsIG1ha2UNaXQg dW5saWtlbHkgdGhhdCBtZWNoYW5pc20tc3BlY2lmaWMsIGltcGxlbWVudGF0aW9uDWluZGVw ZW5kZW50IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gd2lsbCBiZSBkZXBsb3llZCBvbg1z eXN0ZW1zLiBBY2NvcmRpbmdseSwgdGhlIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGluZm9y bWF0aW9uDWluIFRhYmxlIDEgd291bGQgZ2VuZXJhbGx5IGJlIGZpbGxlZC1pbiBpbiBhIHJl YWxpemF0aW9uIG9mDWRpZmZlcmVudGlhdGVkIHNlcnZpY2VzIGJ5IGEgcGFydGljdWxhciB2 ZW5kb3IuDQ1UaGUgcmVhc29uIGZvciB0aGlzIGlzIHRoYXQgd2hpbGUgbWVjaGFuaXNtLXNw ZWNpZmljcyBzdWNoIGFzDXJvdXRpbmcgcHJvdG9jb2xzLCBldGMuICBhcmUgcHVibGlzaGVk IGFzIHN0YW5kYXJkcywgbW9zdA12ZW5kb3JzIGFkZCB0byB0aGVzZSBzdGFuZGFyZHMgaW4g dGhlaXIgcHJvZHVjdA1pbXBsZW1lbnRhdGlvbnMuIFdoYXQgd2lsbCBiZSBkZXBsb3llZCBt b3JlIG9mdGVuLCB3aWxsIGJlDW1lY2hhbmlzbSBhbmQgaW1wbGVtZW50YXRpb24gZGVwZW5k ZW50IGRlZmF1bHRzIHRoYXQgYSBwb2xpY3kNc3lzdGVtIGNhbiBzZW5kIHRvIG1hbmFnZWQg ZGV2aWNlcyB0aGF0IG1hdGNoIGEgcGFydGljdWxhcg1pbXBsZW1lbnRhdGlvbiBhbmQgbWVj aGFuaXNtIHBhaXIgYXMgd2FzIHRoZSBjYXNlIGluIHRoZQ1yb3V0aW5nIHNvZnR3YXJlIGV4 YW1wbGUgaW4gdGhlIGltcGxlbWVudGF0aW9uLXNwZWNpZmljDWRlZmluaXRpb24gc2VjdGlv bi4gVGhlIHZlbmRvciBhZGRlZCB0aGUgY2FwYWJpbGl0eSB0byBzdXBwb3J0DWZlYXR1cmVz IHRoYXQgd2VyZSBub3QgcGFydCBvZiB0aGUgc3RhbmRhcmQgd2hpY2ggZGVmaW5lcw1tZWNo YW5pc20tc3BlY2lmaWMgZGV0YWlscy4gVG8gcHJvcGVybHkgY29uZmlndXJlIHRoYXQNdmVu ZG9yJ3Mgc3lzdGVtLCBib3RoIHRoZSBtZWNoYW5pc20tc3BlY2lmaWMgYXMgd2VsbCBhcyB2 ZW5kb3INZXh0ZW5zaW9ucywgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMsIGluZm9ybWF0aW9u IG11c3QgYmUNc3VwcGxpZWQuIFNvbWUgdmVuZG9ycyBtYWtlIHRoZXNlIGFkZGl0aW9ucyBh cyBhIHJlc3VsdCBvZg1jdXN0b21lciByZXF1ZXN0cyBvciB0aGUgcGVyY2VwdGlvbiB0aGF0 IHRoZXkgd2lsbCBpbXByb3ZlDXRoZWlyIG1hcmtldCBkaWZmZXJlbnRpYXRpb24uIEFub3Ro ZXIgcmVhc29uIGZvciB0aGlzIGlzIHRoYXQNc3RhbmRhcmRzIGFyZSBub3QgcGVyZmVjdC4g VGhleSBjYW4gYmUgaW5jb21wbGV0ZSBmb3IgYW55DW51bWJlciBvZiByZWFzb25zIGluY2x1 ZGluZyB0aGUgZmFjdCB0aGF0IHZlbmRvcnMgYXJlIG9mdGVuDWFibGUgdG8gcmVzcG9uZCBt b3JlIHJhcGlkbHkgdG8gY2hhbmdlcyBpbiBjdXN0b21lcg1yZXF1aXJlbWVudHMgdGhhbiB0 aGUgc3RhbmRhcmRzIGJvZGllcy4NDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdlIDEyXQ0MDUludGVybmV0IERyYWZ0ICBQ b2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NNS4gIFRo ZSBTTk1QIENvbmZpZ3VyYXRpb24gV29ya2luZyBHcm91cA0NVGhpcyBzZWN0aW9uLCBhbmQg dGhlIG9uZXMgdGhhdCBmb2xsb3csIGRlc2NyaWJlIGhvdyBTTk1QIGNhbg1iZSBhcHBsaWVk IHRvIHRoZSBhcmVhIG9mIHBvbGljeS1iYXNlZCBjb25maWd1cmF0aW9uIHdoaWxlIGF0DXRo ZSBzYW1lIHRpbWUgcGVyZm9ybWluZyBzaW1wbGUgY29uZmlndXJhdGlvbiB0YXNrcyBhbmQg YWxsIG9mDXRoZSBvdGhlciB0YXNrcyB0byB3aGljaCBpdCBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgYXBwbGllZC4gIEFuDWltcG9ydGFudCBiZW5lZml0IG9mIHVzaW5nIFNOTVAgZm9yIHNp bXBsZSBhcyB3ZWxsIGFzIHBvbGljeS0NYmFzZWQgY29uZmlndXJhdGlvbiBpcyB0aGF0IHdp dGggYWxsIGNvbmZpZ3VyYXRpb24gZGF0YQ1hc3NvY2lhdGVkIHdpdGggaW5zdGFuY2UgbGV2 ZWwgZGV0YWlscywgZS5nLiwgc3BlY2lmaWMNaW50ZXJmYWNlcyBhbmQgdGhlaXIgc3RhdHVz IGFuZCBjb3VudGVyIHZhbHVlcywgaXQgaXMgbXVjaA1lYXNpZXIgdG8gdW5kZXJzdGFuZCB0 aGUgcmVsYXRpb25zaGlwIG9mIGZhdWx0cyBhbmQNdXRpbGl6YXRpb24gb2YgcmVzb3VyY2Vz IHdpdGggc3BlY2lmaWMgcG9saWNpZXMuICBUaGlzDWFzc29jaWF0aW9uIHN0aWxsIGFsbG93 cyBmb3IgdGhlIGVmZmljaWVudCB0cmFuc2ZlciBvZg1jb25maWd1cmF0aW9uIGNvbW1hbmRz IHRvIHRoZSBtYW5hZ2VkIGRldmljZXMgaW4gdGVybXMgb2YgdGhlDXBvbGljeSBsZXZlbHMg ZGVzY3JpYmVkIGFib3ZlLiBTTk1QLWJhc2VkIHBvbGljeSBjb25maWd1cmF0aW9uDW9mZmVy cyBjb25zaWRlcmFibGUgZmxleGliaWxpdHkgYnkgYWxsb3dpbmcgdGhlIHNlbGVjdGlvbiBv Zg10aGUgbGV2ZWwgb2YgYWJzdHJhY3Rpb24gbmVlZGVkIGZvciB0aGUgdGFzay4gSXQgaXMg c3RpbGwNcG9zc2libGUgdG8gc2V0IGluZGl2aWR1YWwgaW5zdGFuY2UgbGV2ZWwgcGFyYW1l dGVycyBhcyBoYXMNYWx3YXlzIGJlZW4gdGhlIGNhc2UuIFRoaXMgYXBwcm9hY2ggYWxzbyBw cm92aWRlcyBmb3IgaGlnaGVyDWxldmVsIGNvbmZpZ3VyYXRpb24gYWJzdHJhY3Rpb25zIHRv IGJlIHNlbnQgdG8gdGhlIG1hbmFnZWQNZGV2aWNlcyBpbiBhIG5ldHdvcmsgd2hpY2ggY2Fu IHByb3ZpZGUgYSBzaWduaWZpY2FudCByZWR1Y3Rpb24NaW4gdGhlIGFtb3VudCBvZiBpbmZv cm1hdGlvbiB0byBiZSBleGNoYW5nZWQgYmV0d2VlbiB0aGUNbWFuYWdlbWVudCBhcHBsaWNh dGlvbiBhbmQgbWFuYWdlZCBkZXZpY2VzLg0NDTUuMS4gIENoYXJ0ZXIgYW5kIEdvYWxzDQ1U aGUgd29ya2luZyBncm91cCBpcyBleGFtaW5pbmcgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50 IHdpdGgNU05NUCBpbiBhIGZhaXJseSBicm9hZCBjb250ZXh0LiBJdCBpcyBub3QgbGltaXRl ZCB0byBwb2xpY3ktDWJhc2VkIGNvbmZpZ3VyYXRpb24gbm9yIGlzIGl0IGxpbWl0ZWQgdG8g dHJhZGl0aW9uYWwNaW5zdGFuY2Utc3BlY2lmaWMgY29uZmlndXJhdGlvbiBpc3N1ZXMuIFRo ZXJlIGFyZSB0aHJlZQ1kZWxpdmVyYWJsZXMgdGhhdCBoYXZlIGJlZW4gY2hhcnRlcmVkOg0N DSAgICAgICAgMS4gQSBCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGRvY3VtZW50IHRvIHByb3Zp ZGUgZ3VpZGVsaW5lcyBvbg0gICAgICAgIGhvdyB0byBiZXN0IHVzZSB0aGUgZXhpc3Rpbmcg SW50ZXJuZXQgU3RhbmRhcmQgTWFuYWdlbWVudA0gICAgICAgIEZyYW1ld29yayB0byBwZXJm b3JtIGNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudC4NDSAgICAgICAgMi4gQSBNSUIgbW9kdWxl IHdoaWNoIGRlc2NyaWJlcyBhIG5ldHdvcmsgZW50aXRpZXMgY2FwYWJpbGl0aWVzDSAgICAg ICAgc3VjaCBhcyBzdXBwb3J0IGZvciBhIHBhcnRpY3VsYXIgdHlwZSBvZiBzZWN1cml0eSBv ciBhDSAgICAgICAgcGFydGljdWxhciBxdWV1aW5nIG1ldGhvZCBvbiBjZXJ0YWluIGludGVy ZmFjZXMuIFRoZSBtb2R1bGUgd2lsbA0gICAgICAgIGFsc28gY29udmV5IHRoZSBjYXBhY2l0 eSBvZiB0aGUgZGV2aWNlIHRvIHBlcmZvcm0gY2VydGFpbiB3b3JrLg0NICAgICAgICAzLiBB IE1JQiBtb2R1bGUgd2hpY2ggY2FuIGJlIHVzZWQgdG8gY29uY2lzZWx5IGNvbnZleQ0gICAg ICAgIGluZm9ybWF0aW9uIGFib3V0IGRlc2lyZWQgbmV0d29yayB3aWRlIERpZmZTZXJ2IEJh c2VkIFFvUw0NDQ0NDVNhcGVyaWEgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNnRoIDIw MDEgICAgICAgICAgW1BhZ2UgMTNdDQwNSW50ZXJuZXQgRHJhZnQgIFBvbGljeSBDb25maWd1 cmF0aW9uIHdpdGggU05NUCAgICBKdWx5IDYsIDIwMDANDQ0gICAgICAgIGJlaGF2aW9yLg0N NS4yLiAgVGhlIFNOTVAgQXJjaGl0ZWN0dXJlIGFuZCBDb25maWd1cmF0aW9uIE1vZGVsDQ1B biB1bmRlcnN0YW5kaW5nIG9mIFBvbGljeSBhbmQgdGhlIGRpZmZlcmVudCBsZXZlbHMgb2YN YWJzdHJhY3Rpb24gdGhhdCBhcmUgdXNlZCB3aGVuIGRpc2N1c3NpbmcgcG9saWN5LCBlbmFi bGVzDW1hcHBpbmcgb2YgdGhlIEludGVybmV0IFN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3 b3JrIHRvIHRoZQ1Qb2xpY3kgRnJhbWV3b3JrLg0NUkZDIDI1NzEsIEFuIEFyY2hpdGVjdHVy ZSBmb3IgRGVzY3JpYmluZyBTTk1QIE1hbmFnZW1lbnQNRnJhbWV3b3JrcywgcmVzdGF0ZXMg c29tZSBvZiB0aGUgYmFzaWMgYXJjaGl0ZWN0dXJhbA1wcmluY2lwbGVzIHRoYXQgaGF2ZSBn dWlkZWQgU05NUC1iYXNlZCBtYW5hZ2VtZW50IGZvciBvdmVyIGENZGVjYWRlLiBGcm9tIHNl Y3Rpb24gMS4yDQ0gICAgICAgIEFuIFNOTVAgbWFuYWdlbWVudCBzeXN0ZW0gY29udGFpbnM6 DQ0gICAgICAgICAtIHNldmVyYWwgKHBvdGVudGlhbGx5IG1hbnkpIG5vZGVzLCBlYWNoIHdp dGggYW4gU05NUCBlbnRpdHkNICAgICAgICAgY29udGFpbmluZyBjb21tYW5kIHJlc3BvbmRl ciBhbmQgbm90aWZpY2F0aW9uIG9yaWdpbmF0b3INICAgICAgICAgYXBwbGljYXRpb25zLCB3 aGljaCBoYXZlIGFjY2VzcyB0byBtYW5hZ2VtZW50IGluc3RydW1lbnRhdGlvbg0gICAgICAg ICAodHJhZGl0aW9uYWxseSBjYWxsZWQgYWdlbnRzKTsNDSAgICAgICAgIC0gYXQgbGVhc3Qg b25lIFNOTVAgZW50aXR5IGNvbnRhaW5pbmcgY29tbWFuZCBnZW5lcmF0b3IgYW5kL29yDSAg ICAgICAgIG5vdGlmaWNhdGlvbiByZWNlaXZlciBhcHBsaWNhdGlvbnMgKHRyYWRpdGlvbmFs bHkgY2FsbGVkIGENICAgICAgICAgbWFuYWdlcikgYW5kLA0NICAgICAgICAgLSBhIG1hbmFn ZW1lbnQgcHJvdG9jb2wsIHVzZWQgdG8gY29udmV5IG1hbmFnZW1lbnQgaW5mb3JtYXRpb24N ICAgICAgICAgYmV0d2VlbiB0aGUgU05NUCBlbnRpdGllcy4NDVRoZSBhcmNoaXRlY3R1cmUg YXNzdW1lcyBBVCBMRUFTVCBvbmUgbWFuYWdlbWVudCBzeXN0ZW0gd2hpY2gNaW1wbGllcyBp biBtYW55IGNhc2VzIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBtb3JlIHRoYW4gb25lLg1U aGUgU05NUCBhcmNoaXRlY3R1cmUgaGFzIGJlZW4gZGVzaWduZWQgdG8gc3VwcG9ydCBtdWx0 aXBsZQ1tYW5hZ2VycyBzaW5jZSBpdHMgaW5jZXB0aW9uLiBBcyBuZXR3b3JrcyBiZWNvbWUg bW9yZSBjb21wbGV4LA10aGUgcmVkdW5kYW5jeSBwb3NzaWJsZSB3aXRoIHRoaXMgYXJjaGl0 ZWN0dXJlIHdpbGwgYmVjb21lDWluY3JlYXNpbmdseSBpbXBvcnRhbnQuIEZvciB0aGUgcHVy cG9zZSBvZiB0aGlzIGRvY3VtZW50LCBhDXBvbGljeSBtYW5hZ2VtZW50IGFwcGxpY2F0aW9u IGlzIGEgZ2VuZXJpYyB0ZXJtLiBJdCBjYW4gYmUgYW55DWNvbWJpbmF0aW9uIG9mIHRoZSBm aXZlIGFwcGxpY2F0aW9ucyB0aGF0IGFyZSBkZXNjcmliZWQgaW4gUkZDDTI1NzE6ICBDb21t YW5kIEdlbmVyYXRvcnMsIENvbW1hbmQgUmVzcG9uZGVycywgTm90aWZpY2F0aW9uDU9yaWdp bmF0b3JzLCBOb3RpZmljYXRpb24gUmVjZWl2ZXJzLCBhbmQgUHJveHkgRm9yd2FyZGVycy4g QQ1jb21tb24gY29tYmluYXRpb24gd2lsbCBiZSBDb21tYW5kIEdlbmVyYXRvcnMgY29tYmlu ZWQgd2l0aA1Ob3RpZmljYXRpb24gUmVjZWl2ZXJzLg0NRklHVVJFIDEuIFRoZSBJbnRlcm5l dCBTdGFuZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yaw0NDQ0NDQ0NU2FwZXJpYSAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAxNF0NDA1JbnRl cm5ldCBEcmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwg MjAwMA0NDTUuMi4xLiAgVGhlIFBvbGljeSBNSUIgTW9kdWxlDQ1HaXZlbiB0aGlzIGFyY2hp dGVjdHVyZSwgaXQgaXMgYSBzaW1wbGUgYW5kIGxvdy1jb3N0IG1hdHRlciB0bw1hZGQgcG9s aWN5LWVuYWJsZWQgbWFuYWdlbWVudCB3aXRoaW4gdGhlIFNOTVAgYXJjaGl0ZWN0dXJlLiBJ bg1mYWN0IGFsbCB0aGF0IGlzIHJlcXVpcmVkIGlzIHRoZSBhZGRpdGlvbiBvZiBvbmUgTUlC IE1vZHVsZS4NVGhlIFNOTVBDT05GIFdvcmtpbmcgR3JvdXAgaGFzIG5hbWVkIHRoaXMgdGhl IFBvbGljeS1CYXNlZA1NYW5hZ2VtZW50IE1JQiBNb2R1bGUsIG9yIFBvbGljeSBNb2R1bGUg Zm9yIHNob3J0Lg0NRklHVVJFIDIuIFRoZSBQb2xpY3kgTUlCIE1vZHVsZSAtIFNlZSB0aGUg LnBzIHZlcnNpb24uDQ1UaGUgUG9saWN5IE1vZHVsZSBoZWxwcyB0cmFuc2xhdGUgZnJvbSBv bmUgbGV2ZWwgb2YNYWJzdHJhY3Rpb24gdG8gYW5vdGhlci4gSXQgaGVscHMgbW92ZSBmcm9t IHRoZSBtZWNoYW5pc20NaW5kZXBlbmRlbnQgdG8gdGhlIG1lY2hhbmlzbSBkZXBlbmRlbnQg YW5kIGhlbHBzIG1vdmUgZnJvbSB0aGUNaW5zdGFuY2UgaW5kZXBlbmRlbnQgdG8gdGhlIGlu c3RhbmNlIGRlcGVuZGVudCBsZXZlbCBvZg1hYnN0cmFjdGlvbi4NDUhlcmUgYXJlIHNvbWUg dGVybXMgdXNlZCBpbiB0aGUgUG9saWN5LUJhc2VkIE1hbmFnZW1lbnQgTUlCDU1vZHVsZS4g Tm90ZSB0aGF0IFBvbGljeSwgUG9saWN5IEZpbHRlciwgUG9saWN5IEFjdGlvbiBhbmQNUm9s ZSBkZWZpbml0aW9ucyBhcmUgZnJvbSB0aGUgUG9saWN5LUJhc2VkIE1hbmFnZW1lbnQgTUlC DU1vZHVsZSBkcmFmdDoNDSAgICBodHRwOi8vaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtc25tcGNvbmYtcG0tDTAxLnR4dDoNDQ0gICAgIFBvbGljeSAtIGluIHRoZSBj b250ZXh0IG9mIHRoZSBQb2xpY3kgTUlCIE1vZHVsZSwgYQ0gICAgIHBvbGljeSBpcyBleHBy ZXNzZWQgYXM6IGlmIChwb2xpY3lGaWx0ZXIpIHRoZW4NICAgICAocG9saWN5QWN0aW9uKS4N DQ0gICAgIFBvbGljeSBGaWx0ZXIgLSBUaGUgcG9saWN5IGZpbHRlciBpcyBhbiBTTk1QIG9i amVjdCB0aGF0DSAgICAgY29udGFpbnMgYW4gZXhwcmVzc2lvbiB0aGF0IHJlc3VsdHMgaW4g YSBib29sZWFuIHRoYXQgaXMNICAgICB1c2VkIHRvIGRldGVybWluZSBpZiBhbiBlbGVtZW50 IGlzIHRvIGJlIGEgbWVtYmVyIG9mIGENICAgICBzZXQgb2Ygb2JqZWN0cyBvbiB3aGljaCBh biBhY3Rpb24gaXMgdG8gYmUgcGVyZm9ybWVkLg0NDSAgICAgUG9saWN5IEFjdGlvbiAtIFRo ZSBwb2xpY3kgYWN0aW9uIG9iamVjdCBjb250YWlucyB3aGF0DSAgICAgcGFyYW1ldGVycyBh cmUgdG8gYmUgbW9kaWZpZWQgb24gaW5zdGFuY2VzIGluIHRoZSBzeXN0ZW0NICAgICB0aGF0 IG1hdGNoIHRoZSBwb2xpY3kgZmlsdGVyIGV4cHJlc3Npb24uIFRoZXNlIGFjdGlvbnMNICAg ICBjb3VsZCBiZSB0byB0dXJuIGFuIGludGVyZmFjZSBvbiBvciBvZmYsIG9yIGNhdXNlIHRo ZQ0gICAgIGNvbmZpZ3VyYXRpb24gb2YgYSBjb21wbGV4IHNldCBvZiBvYmplY3RzIGFzIG1p Z2h0IGJlIHRoZQ0gICAgIGNhc2UgaW4gRGlmZmVyZW50aWF0ZWQgU2VydmljZXMuIEluIHRo YXQgY2FzZSwgdGhlIGFjdGlvbg0gICAgIHdvdWxkIGJlIGV4cGFuZGVkIGJ5IHRoZSBpbmZv cm1hdGlvbiBmb3IgdGhlIHBvbGljeSBmb3VuZA0gICAgIGluIHRoZSBtZWNoYW5pc20sIGFu ZCBpZiBuZWNlc3NhcnksIGltcGxlbWVudGF0aW9uLQ0gICAgIHNwZWNpZmljIHRhYmxlcy4g QW4gYWN0aW9uIGNvdWxkIGFsc28gYmUgYXMgc2ltcGxlIGFzDQ0NDQ0NU2FwZXJpYSAgICAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAxNV0NDA1J bnRlcm5ldCBEcmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkg NiwgMjAwMA0NDSAgICAgY2F1c2luZyBhIHBhcnRpY3VsYXIgZGV2aWNlIHRvIGRvd25sb2Fk IGEgbmV3IHZlcnNpb24gb2YNICAgICBvcGVyYXRpb25hbCBjb2RlLg0NDSAgICAgUm9sZSAt IEEgcm9sZSBpcyBhbiBhYnN0cmFjdCBjaGFyYWN0ZXJpc3RpYyBhc3NpZ25lZCB0bw0gICAg IHRoZSBlbGVtZW50LiAgVGhlc2UgYWJzdHJhY3Qgcm9sZXMgY2FuIGV4cHJlc3MgYQ0gICAg IGdlb2dyYXBoaWNhbCwgcG9saXRpY2FsLCBmaW5hbmNpYWwsIGxlZ2FsIG9yDSAgICAgYXJj aGl0ZWN0dXJhbCBhdHRyaWJ1dGUuIE1vc3Qgb2Z0ZW4gdGhlc2UgYXR0cmlidXRlcyBhcmUN ICAgICBub3QgYWxnb3JpdGhtaWNhbGx5IGRldGVybWluYWJsZS4NDSAgICAgVGhlIFBvbGlj eSBNSUIgTW9kdWxlIGNvbnRhaW5zIHN0YW5kYXJkIE1JQiB0YWJsZXMNICAgICBtYW5hZ2Vy cyBjYW4gcG9wdWxhdGUgdGhhdDoNDQ0gICAgIDEuIFRlbGwgdGhlIG1hbmFnZWQgc3lzdGVt IHdoYXQgcG9saWN5IGZpbHRlcnMgdG8gYXBwbHkNICAgICBpbiBvcmRlciB0byBzZWxlY3Qg dGhlIGluc3RhbmNlcyB0byB3aGljaCBhIHNwZWNpZmljDSAgICAgcG9saWN5IChhY3Rpb24p IHNob3VsZCBiZSBhcHBsaWVkLg0NDSAgICAgMi4gVGVsbCB0aGUgbWFuYWdlZCBzeXN0ZW0g d2hhdCByb2xlcyBhcHBseSB0byB3aGljaA0gICAgIGluc3RhbmNlcy4gV2UgY2FuIGRlZmlu ZSByb2xlcyBzdWNoIGFzOyBzZXJ2ZXMgY3VzdG9tZXINICAgICBBLCBvciBpcyBhIGJhY2t1 cCBpbnRlcmZhY2UgaW4gdGFibGVzIGluIHRoaXMgTUlCIE1vZHVsZS4NICAgICBGb3Igb3Vy IFZvaWNlIG92ZXIgSVAgY3VzdG9tZXIsIHRoZXNlIGNvdWxkIGJlIGludGVyZmFjZXMNICAg ICB0aGF0IGhhdmUgaGFkIHRoZSByb2xlIGFzc2lnbmVkIHRvIHRoZW0gb2Ygc2VydmluZyB0 aGlzDSAgICAgc3BlY2lmaWMgY3VzdG9tZXIgYW5kIGFyZSBhbHNvIGN1cnJlbnRseSB1cCB0 byBkYXRlIG9uDSAgICAgdGhlaXIgcHJlbWl1bSBzZXJ2aWNlIHBheW1lbnRzLiBXaGVuIHRo ZSBtYW5hZ2VkIHN5c3RlbQ0gICAgIG11c3QgZGV0ZXJtaW5lIHRvIHdoaWNoIGluc3RhbmNl cyB0byBhcHBseSB0aGUgcG9saWN5LCBpdA0gICAgIGV2YWx1YXRlcyB0aGVzZSByb2xlcyBh bmQgdGhlaXIgYXNzb2NpYXRpb25zIHdpdGgNICAgICBpbnN0YW5jZXMgKGludGVyZmFjZXMg aW4gb3VyIGV4YW1wbGUpLiBJdCBhY2NvbXBsaXNoZXMNICAgICB0aGlzIGZ1bmN0aW9uIGJh c2VkIG9uIHRoZSBmaWx0ZXIgb2JqZWN0IHRoYXQgaXMgc3VwcGxpZWQNICAgICB3aXRoIGVh Y2ggcG9saWN5LiBUaGlzIGZpbHRlciBpcyBhcHBsaWVkIHRvIHRoZSByb2xlcw0gICAgIGFz c2lnbmVkIHRvIGluc3RhbmNlcyBpbiB0aGUgZGV2aWNlLCBhbmQgYSByZXN1bHQgbGlzdCBp cw0gICAgIGNyZWF0ZWQgdG8gd2hpY2ggdGhlIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBh cHByb3ByaWF0ZQ0gICAgIHRvIHRoZSBwb2xpY3kgYXJlIGFwcGxpZWQuICBQYXJ0IG9mIHRo ZSBmaWx0ZXINICAgICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBpbmZvcm1hdGlvbiB0aGF0IHRo ZSBtYW5hZ2VkIHN5c3RlbQ0gICAgIGNhbiB1c2UgdG8gcmVzdHJpY3QgdGhlIHNjb3BlIG9m IHRoZSByb2xlIHNlYXJjaCBmb3INICAgICBlZmZpY2llbmN5IHB1cnBvc2VzLg0NDSAgICAg My4gVGVsbCB0aGUgbWFuYWdlZCBzeXN0ZW0gd2hlbiBhbmQgaG93IGxvbmcgdGhlIHBvbGlj eQ0gICAgIHNob3VsZCByZW1haW4gaW4gZWZmZWN0LCBmb3IgZXhhbXBsZSBldmVyeSBNb25k YXkgdG8NICAgICBGcmlkYXkgZnJvbSA5IGFtIHRvIDUgcG0uDQ0NDQ0NDQ1TYXBlcmlhICAg ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdlIDE2XQ0M DUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVs eSA2LCAyMDAwDQ0NICAgICA0LiBUZWxsIHRoZSBtYW5hZ2VkIHN5c3RlbSBpZiBhbmQgaG93 IHRvIGFwcGx5DSAgICAgbWVjaGFuaXNtLXNwZWNpZmljIHN1Y2ggYXMgRGlmZlNlcnYgYW5k IGluc3RhbmNlIGFuZA0gICAgIGltcGxlbWVudGF0aW9uIGluZGVwZW5kZW50IHBhcmFtZXRl cnMgYXMgbmVlZGVkIHRvIHRoZQ0gICAgIGluc3RhbmNlcyB0aGF0IGFyZSBhcHByb3ByaWF0 ZSB0byB0aGUgbG9jYWwgc3lzdGVtLiBUaGUNICAgICBtZWNoYW5pc20tc3BlY2lmaWMgcGFy YW1ldGVycyBhcmUgZm91bmQgaW4gdGhlDSAgICAgbWVjaGFuaXNtLXNwZWNpZmljIE1JQiBN b2R1bGVzIHN1Y2ggYXMgdGhlIERpZmZlcmVudGlhdGVkDSAgICAgU2VydmljZXMgUG9saWN5 IE1JQiBNb2R1bGUgdGhhdCBpcyBkZXNjcmliZWQgaW4gdGhlIG5leHQNICAgICBzZWN0aW9u Lg0NICAgICBUaGUgcG9saWN5IE1JQiBNb2R1bGUgYWxzbyBwcm92aWRlcyBpbXBvcnRhbnQg aW5mb3JtYXRpb24gdG8gdGhlIG1hbmFnZW1lbnQNICAgICBzeXN0ZW0uIFRoaXMgaW5mb3Jt YXRpb24gaW5jbHVkZXM6DQ0gICAgIDEuIFRoZSBjdXJyZW50IHN0YXRlIG9mIHRoZSBQb2xp Y3kuDQ0NICAgICAyLiBHbG9iYWwgdXRpbGl6YXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhl IHJlc291cmNlcw0gICAgIHVzZWQgYnkgYSBwYXJ0aWN1bGFyIHBvbGljeS4NDQ0gICAgIDMu IFRoZSBtZWNoYW5pc21zIHRoYXQgdGhlIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzLiBUaGUN ICAgICBQb2xpY3kgTW9kdWxlIGNvbnRhaW5zIG9iamVjdHMgdGhhdCBpZGVudGlmeSB0aGUN ICAgICBjYXBhYmlsaXRpZXMgdGhhdCB0aGUgc3lzdGVtIHN1cHBvcnRzLiBJdCBpcyBwbGFu bmVkIHRoYXQNICAgICBzdGFuZGFyZCBjYXBhYmlsaXRpZXMgd2lsbCBiZSBwdWJsaXNoZWQg YnkgSUFOQS4NDQ0gICAgIDQuIFRoZSBzcGVjaWZpYyBpbnN0YW5jZXMgdGhhdCBhcmUgYXNz b2NpYXRlZCB3aXRoIG9uZSBvcg0gICAgIG1vcmUgb2YgdGhlIHJvbGVzIGlkZW50aWZpZWQg ZWFybGllci4NDSAgICAgVGhlIGZpcnN0IHBhcnQgb2YgYSBwb2xpY3kgaW4gdGhlIFBvbGlj eSBUYWJsZSBpcyBhIHBvbGljeSBmaWx0ZXIuIFRoaXMNICAgICBjb250YWlucyB0aGUgcm9s ZXMgdGhhdCBhIHNwZWNpZmljIGluc3RhbmNlIG11c3QgbWF0Y2ggYmVmb3JlIHRoZSBwb2xp Y3kNICAgICBhY3Rpb24gcGFydCBpcyB0byBiZSBhcHBsaWVkLiAgVGhlIHNlY29uZCBwYXJ0 IGlzIGEgcG9saWN5IGFjdGlvbiB0aGF0DSAgICAgY29udGFpbnMgdGhlIG9wZXJhdGlvbnMg dGhlIHN5c3RlbSBpcyB0byBwZXJmb3JtIG9uIGluc3RhbmNlcyB0byB3aGljaA0gICAgIHRo ZSBwb2xpY3kgYXBwbGllcy4gVGhlIHBvbGljeSB0YWJsZSBhbHNvIGNvbnRhaW5zIHBvaW50 ZXIgaW5mb3JtYXRpb24NICAgICBmb3IgdGhlIHNjaGVkdWxpbmcgb2YgYSBwb2xpY3kgYXMg d2VsbCBhcyBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSBvZg0gICAgIHZhbHVlIHdoZW4gZGVi dWdnaW5nIGFuZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc3RhdHVzIG9mIGVhY2ggcG9saWN5 Lg0NICAgICBUaGUgUm9sZSBUYWJsZSBpbiB0aGUgUG9saWN5IE1vZHVsZSBpcyBjb25maWd1 cmVkIHdpdGggcm9sZXMgc3RyaW5ncw0gICAgIHRoYXQgYXJlIHRvIGJlIGFzc29jaWF0ZWQg d2l0aCBlbGVtZW50cyBvZiBhIHN5c3RlbSB1bmRlciBwb2xpY3kNICAgICBjb250cm9sLiBU aGUgcm9sZSB0YWJsZSBpcyByZWFsbHkgdHdvIHRhYmxlczsgZmlyc3QgaXMgdGhlIHBtUm9s ZUVTVGFibGUNICAgICB3aGVyZSByb2xlIHN0cmluZ3MgYXJlIGFzc2lnbmVkIHRvIHNwZWNp ZmljIGVsZW1lbnRzLiBUaGUgcG1Sb2xlU0VUYWJsZQ0gICAgIGlzIGEgcmVhZC1vbmx5IHRh YmxlIGluZGV4ZWQgYnkgcm9sZSBzdHJpbmcgYW5kIGNvdWxkIGJlIHZlcnkgaGVscGZ1bCBp bg0gICAgIGRlYnVnZ2luZyBzaXR1YXRpb25zLiBTY2hlZHVsaW5nIGluZm9ybWF0aW9uIGlz IGNvbnRhaW5lZCBpbiB0YWJsZXMNICAgICBleHRlcm5hbCB0byB0aGUgUG9saWN5IE1JQiBN b2R1bGUuIFRoYXQgaW5mb3JtYXRpb24gaXMgaW4gW1NDSEVEXS4NDSAgICAgSW4gdGhlIGNh c2Ugb2YgZGlmZmVyZW50aWF0ZWQgc2VydmljZXMgYW5kIG90aGVyIGNvbXBsZXggdGVjaG5v bG9naWVzDQ0NDQ0NU2FwZXJpYSAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2dGggMjAw MSAgICAgICAgICBbUGFnZSAxN10NDA1JbnRlcm5ldCBEcmFmdCAgUG9saWN5IENvbmZpZ3Vy YXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwgMjAwMA0NDSAgICAgdGhlcmUgY2FuIGJlIG1h bnkgb2JqZWN0cyB0aGF0IG5lZWQgdG8gYmUgY29uZmlndXJlZCB0byByZWFsaXplIGENICAg ICBwYXJ0aWN1bGFyIHBvbGljeS4gSGF2aW5nIHRoZXNlIG9iamVjdHMgc2VwYXJhdGVseSB2 aXNpYmxlIG1ha2VzDSAgICAgaW5zcGVjdGlvbiBhbmQgbW9kaWZpY2F0aW9uIG9mIHBhcmFt ZXRlcnMgZm9yIHN1Y2ggY29tcGxleCBwb2xpY2llcyBhbg0gICAgIGVhc2llciBtYXR0ZXIg YW5kIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGRvd25sb2FkIHBvbGljeSBpbiBhIG1lY2hhbmlz bQ0gICAgIGFuZCBpbXBsZW1lbnRhdGlvbiBpbmRlcGVuZGVudCBmYXNoaW9uIHRvIHRoZSBQ b2xpY3kgTW9kdWxlIHNpbmNlIHRoZQ0gICAgIG1lY2hhbmlzbSBhbmQgaW1wbGVtZW50YXRp b24tc3BlY2lmaWMgZGV0YWlscyBhcmUgcG90ZW50aWFsbHkgaW4NICAgICBtZWNoYW5pc20g YW5kIHRlY2hub2xvZ3kgc3BlY2lmaWMgbW9kdWxlcy4NDSAgICAgSW4gdGhlIGNhc2VzIHdo ZXJlIG1lY2hhbmlzbS1zcGVjaWZpYyBhbmQgaW5zdGFuY2Utc3BlY2lmaWMgTUlCIG1vZHVs ZXMNICAgICBoYXZlIGJlZW4gZGVmaW5lZCwgYm90aCBNSUIgTW9kdWxlcyBzaG91bGQgYmUg c3VwcG9ydGVkLiBBIG9iamVjdCB3aWxsDSAgICAgYmUgZGVmaW5lZCBzbyB0aGF0IGlmIGEg Y2hhbmdlIGlzIG1hZGUgdG8gdGhlIGluc3RhbmNlLXNwZWNpZmljIE1JQg0gICAgIE1vZHVs ZSB0aGF0IGFmZmVjdHMgYW4gaW5zdGFuY2UgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBwb2xp Y3ksIHRoZQ0gICAgIFBvbGljeSBNSUIgTW9kdWxlIHdpbGwgYmUgYWJsZSB0byByZWZsZWN0 IHRoYXQgYW4gb2JqZWN0IHVuZGVyIGl0cw0gICAgIGNvbnRyb2wgaGFzIGJlZW4gY2hhbmdl ZC4gSWYgcHJlc2VudCwgYQ0gICAgIG1lY2hhbmlzbS9pbXBsZW1lbnRhdGlvbi1zcGVjaWZp YyBNSUIgTW9kdWxlIHdpbGwgYWxzbyBiZSBhYmxlIHRvIGNvbnZleQ0gICAgIHRoYXQgYSBj aGFuZ2Ugb3IgY2hhbmdlcyBoYXZlIGJlZW4gbWFkZSBhdCB0aGUgaW5zdGFuY2Utc3BlY2lm aWMNICAgICBsZXZlbC4gVGhpcyBpbmZvcm1hdGlvbiBjYW4gYmUgY29udmV5ZWQgdmlhIE1J QiBvYmplY3RzIHRoYXQgcmVmbGVjdCB0aGUNICAgICBzdGF0ZSBvZiB0aGUgcG9saWN5Lg0N ICAgICBUaGUgUG9saWN5IE1vZHVsZSBhbGxvd3MgZm9yIHRoZSBleHBhbnNpb24gb2YgdGhl IE1lY2hhbmlzbSBJbmRlcGVuZGVudA0gICAgIHRvIHRoZSBNZWNoYW5pc20gYW5kIEltcGxl bWVudGF0aW9uIERlcGVuZGVudCwgd2hlbiBuZWVkZWQsIHRocm91Z2ggdGhlDSAgICAgY29u bmVjdGlvbiB0byB0aGUgTWVjaGFuaXNtL0ltcGxlbWVudGF0aW9uIERlcGVuZGVudCBNSUIg TW9kdWxlcy4gVGhlc2UNICAgICBzcGVjaWZpYyBtb2R1bGVzIHRha2UgdGhlIGluc3RhbmNl cyB0aGF0IGhhdmUgYmVlbiBzZWxlY3RlZCBhcyBhIHJlc3VsdA0gICAgIG9mIHRoZSBleHBh bnNpb24gb2YgdGhlIHBvbGljeSBmaWx0ZXIgYW5kIHRoZW4gZXhwYW5kIHRoZSAnZGVmYXVs dCcNICAgICBtZWNoYW5pc20sIGFuZCB3aGVyZSBhcHByb3ByaWF0ZSwgaW1wbGVtZW50YXRp b24tc3BlY2lmaWMgcGFyYW1ldGVycyB0bw0gICAgIGVhY2ggb2YgdGhlIHNlbGVjdGVkIGlu c3RhbmNlcy4NDSAgICAgSW4gc29tZSBzaW1wbGUgZG9tYWlucywgdGhlcmUgbWF5IGJlIG5v IHZhbHVlIGluIGJvdGggbWVjaGFuaXNtDSAgICAgZGVwZW5kZW50IGFuZCBpbmRlcGVuZGVu dCBsZXZlbHMuIEFuIGV4YW1wbGUgd291bGQgYmUgcG9saWN5IHdoaWNoDSAgICAgc3RhdGVz IHRoYXQgYWxsIGRldmljZXMgbXVzdCBydW4gdGhlIGxhdGVzdCBhcHByb3ZlZCB2ZXJzaW9u IG9mIHRoZQ0gICAgIG9wZXJhdGluZyBzeXN0ZW0uIEluIHRoZXNlIGNhc2VzIHRoZXJlIGFy ZSBub3QgYSBudW1iZXIgb2YgZGlmZmVyZW50DSAgICAgbWVjaGFuaXNtcyBhbmQgcmVsYXRl ZCBwYXJhbWV0ZXJzIHNvIHRoaXMgYWRkaXRpb25hbCBjb21wb25lbnQgbWF5IG5vdA0gICAg IGJlIG5lZWRlZC4gSW4gdGhpcyBjYXNlLCB0aGUgUG9saWN5IE1JQiBNb2R1bGUgbWF5IGlu dGVyYWN0IGRpcmVjdGx5DSAgICAgd2l0aCB0aGUgaW5zdGFuY2Utc3BlY2lmaWMsIHRoZSBs b3dlc3QgbGV2ZWwgb2YgYWJzdHJhY3Rpb24sDSAgICAgaW5zdHJ1bWVudGF0aW9uIGluIHRo ZSBkZXZpY2UuVGhlIFNOTVAgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwIGhhcw0gICAg IGRldmVsb3BlZCBhbiBleGFtcGxlIG9mIGEgTUlCIE1vZHVsZSB0aGF0IGNvbnZlcnRzIGZy b20gdGhlIG1lY2hhbmlzbQ0gICAgIGFuZCBpbXBsZW1lbnRhdGlvbiBpbmRlcGVuZGVudCBt ZXRob2RzIHRvIG1lY2hhbmlzbSwgaW1wbGVtZW50YXRpb24sIGFuZA0gICAgIGluc3RhbmNl LXNwZWNpZmljIGxldmVscy4gVGhpcyBNSUIgTW9kdWxlIGlzIHRoZSBEaWZmZXJlbnRpYXRl ZCBTZXJ2aWNlcw0gICAgIFBvbGljeSBNSUIgTW9kdWxlLg0NNS4yLjIuICBNZWNoYW5pc20g YW5kIEltcGxlbWVudGF0aW9uLVNwZWNpZmljIE1JQiBNb2R1bGVzDQ1Tb21ldGltZXMgbWVj aGFuaXNtLXNwZWNpZmljIGF0dHJpYnV0ZXMgYXJlIG5lZWRlZCB0byBmdWxseQ1zcGVjaWZ5 IGEgcG9saWN5LiBJbiBzb21lIGNhc2VzLCBib3RoIG1lY2hhbmlzbSBhbmQNaW1wbGVtZW50 YXRpb24tc3BlY2lmaWMgYXR0cmlidXRlcyBtdXN0IGJlIHNwZWNpZmllZCBmb3IgYW4NDQ0N DQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAg IFtQYWdlIDE4XQ0MDUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlvbiB3aXRo IFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NZWZmZWN0aXZlIHBvbGljeSB0byBiZSBjb25maWd1 cmVkIGlmIHRoZSB2ZW5kb3IgaGFzIGFkZGVkDWV4dGVuc2lvbnMgdG8gYSBzdGFuZGFyZCBt ZWNoYW5pc20gb3IgaGFzIGNyZWF0ZWQgYSBtZWNoYW5pc20NaW5zaWRlIGEgcGFydGljdWxh ciBkb21haW4uIFRoZSBhcmNoaXRlY3R1cmUgYWxsb3dzIGZvciB0aGUNcG9saWN5IGFjdGlv biB0byBjb250YWluIG1lY2hhbmlzbSBhbmQgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMNcmVm ZXJlbmNlcy4gSG93ZXZlciwgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZXJlIGlzIHZhbHVl IGluDWhhdmluZyB0aGlzIHBvbGljeSBhY3Rpb24gaW5jbHVkZSB0aGlzIG1lY2hhbmlzbSBh bmQvb3INaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgaW5mb3JtYXRpb24gYnkgcmVmZXJlbmNl IHJhdGhlciB0aGFuDWJ5IHZhbHVlLlRoZSB2YWx1ZSBvZiBoYXZpbmcgdGhlc2Ugc2VwYXJh dGUgdGFibGVzIHBvaW50ZWQgdG8NYnkgdGhlIGhpZ2hlciBsYXllciBQb2xpY3kgTUlCIG1v ZHVsZSBpcyBmb3IgZmFjaWxpdGF0aW5nIGdvb2QNbWFuYWdlbWVudCBhcHBsaWNhdGlvbnMg dGhhdCBjYW4gb3BlcmF0ZSBvbiB0aGVzZSBkaWZmZXJlbnQNbGV2ZWxzIG9mIGFic3RyYWN0 aW9uIGFzIG5lZWRlZCBieSB0aGUgdmFyaW91cyB1c2Vycy4gVGhpcw1zZXBhcmF0aW9uIGFs c28gYXZvaWRzIHVubmVjZXNzYXJpbHkgY29tcGxleCBjb25maWd1cmF0aW9uIG9mDXBvbGlj eSBhY3Rpb25zIGluIHRoZSBQb2xpY3kgTW9kdWxlIGFuZCBwb3RlbnRpYWxseSBtYWtlcw1k ZWJ1Z2dpbmcgYSBiaXQgZWFzaWVyIHNpbmNlIHRoZSBwb2xpY3kgYWN0aW9uIGlzIGFuDWV4 cHJlc3Npb24gdGhhdCBhbiBhcHBsaWNhdGlvbiB3b3VsZCBoYXZlIHRvIGtub3cgaG93IHRv IHBhcnNlDWluIG9yZGVyIHRvIHJlYXNvbmFibHkgcHJlc2VudCB0aGUgaW5mb3JtYXRpb24g d2hlcmVhcyB0aGUNbWVjaGFuaXNtIGFuZCBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBNSUIg TW9kdWxlcyBjb250YWluIHRoZQ1pbmZvcm1hdGlvbiBpbiBhIGZvcm0gdGhhdCBtb3N0IFNO TVAtYmFzZWQgbWFuYWdlbWVudA1hcHBsaWNhdGlvbnMgYXJlIHdlbGwgYWJsZSB0byAndW5k ZXJzdGFuZCcgYW5kIGRpc3BsYXkuICBUaGlzDWhlbHBzIGxldmVyYWdlIHRoZSBjb25zaWRl cmFibGUgaW52ZXN0bWVudCBpbiBvdXIgU05NUC1iYXNlZA1pbmZyYXN0cnVjdHVyZS4NDUZJ R1VSRSAzLiBNZWNoYW5pc20gYW5kIEltcGxlbWVudGF0aW9uLVNwZWNpZmljIE1JQiBNb2R1 bGVzIC0NU2VlIC5wcyB2ZXJzaW9uDQ1UaGUgcGFydCBvZiBvdXIgcG9saWN5IGVuYWJsZWQg c3lzdGVtIHRoYXQgY2FuIG1vdmUgZnJvbSB0aGUNbWVjaGFuaXNtIGluZGVwZW5kZW50IHRv IHRoZSBtZWNoYW5pc20gZGVwZW5kZW50IGlzIGENTWVjaGFuaXNtLVNwZWNpZmljIE1JQiBN b2R1bGUuIEltcGxlbWVudGF0aW9uLXNwZWNpZmljDWF0dHJpYnV0ZXMgY2FuIGJlIGRlZmlu ZWQgaW4gYSB2ZW5kb3Igc3BlY2lmaWMgZXh0ZW5zaW9ucyB0bw1tZWNoYW5pc20tc3BlY2lm aWMgTUlCIE1vZHVsZXMgc2luY2UgdGhlIElFVEYgZG9lcyBub3Qgc3BlY2lmeQ1pbXBsZW1l bnRhdGlvbi1zcGVjaWZpYyBtZWNoYW5pc21zLiBJZiBhIHZlbmRvciB3ZXJlIHRvDXJlcXVp cmUgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgZXh0ZW5zaW9ucyB0byBhIG1lY2hhbmlzbSB0 aGF0DWhhcyBiZWVuIGRlZmluZWQsIHRoZXkgd291bGQgYWRkIHRoZW0gdG8gdGhpcyBNSUIg TW9kdWxlLA1wcm9iYWJseSB0aHJvdWdoIHRoZSB1c2Ugb2YgYW4gQUdVTUVOVFMgY2xhdXNl LiBUaGlzIGFwcHJvYWNoDWlzIGlkZW50aWNhbCB0byB0aGUgYXBwcm9hY2ggdmVuZG9ycyBo YXZlIHVzZWQgZm9yIHRoZQ1leHRlbnNpb24gb2Ygc3RhbmRhcmQgaW5zdGFuY2UtYmFzZWQg YXR0cmlidXRlcyB3aXRoIHRoZWlyDW93bi4gVGhlIFNOTVAgQXJjaGl0ZWN0dXJlIHdhcyBk ZXNpZ25lZCB3aXRoIHRoaXMNZXh0ZW5zaWJpbGl0eSBpbiBtaW5kLiBNYW55IHZlbmRvcnMg cmVhbGl6ZSBib3RoIHN0YW5kYXJkIGFuZA12ZW5kb3Igc3BlY2lmaWMgTUlCIE9iamVjdHMg aW4gdGhlIHNhbWUgc29mdHdhcmUgbW9kdWxlLCBhbmQNaXQgaXMgZXhwZWN0ZWQgdGhhdCB0 aGlzIHdpbGwgYWxzbyBiZSB0aGUgY2FzZSB3aGVuIGEgdmVuZG9yDWV4dGVuZHMgSUVURiBz dGFuZGFyZCBNSUIgbW9kdWxlcyB0aGF0IGhhdmUgYmVlbiBkZWZpbmVkIGF0DXRoZSBtZWNo YW5pc20tc3BlY2lmaWMgbGV2ZWwgb2YgYWJzdHJhY3Rpb24uDQ1UaGUgaW5mb3JtYXRpb24g aW4gdGhlIG1lY2hhbmlzbS1zcGVjaWZpYyBNSUIgTW9kdWxlIGRvZXMgbm90DWFsd2F5cyBo YXZlIHRvIGJlIGxvY2F0ZWQgYXBhcnQgZnJvbSB0aGUgaW5zdGFuY2Utc3BlY2lmaWMgTUlC DQ0NDQ0NU2FwZXJpYSAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAg ICAgICBbUGFnZSAxOV0NDA1JbnRlcm5ldCBEcmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24g d2l0aCBTTk1QICAgIEp1bHkgNiwgMjAwMA0NDU1vZHVsZS4gU29tZSB3b3JraW5nIGdyb3Vw cyBpbiB0aGUgZnV0dXJlIG1heSBjaG9vc2UgdG8gY3JlYXRlDXBvbGljeSB0YWJsZXMgaW4g dGhlaXIgaW5zdGFuY2Utc3BlY2lmaWMgTUlCIE1vZHVsZXMuIEhhdmluZw10aGUgZXh0cmEg TUlCIG9iamVjdHMsIHdoZXRoZXIgaW4gYSBzZXBhcmF0ZSBNSUIgTW9kdWxlIGFzIHdlDWhh dmUgZm9yIHRoZSBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNlcyBkb21haW4sIG9yIGFzIGV4dHJh DXRhYmxlcyBpbiBmdXR1cmUgZG9tYWluIHNwZWNpZmljIE1JQiBNb2R1bGVzIGlzIG9mIGxl c3MNaW1wb3J0YW5jZSB0aGFuIGhhdmluZyB0aGUgaW5mb3JtYXRpb24gc2VwYXJhdGVseSBh dmFpbGFibGUuDQ0NNS4yLjMuICBJbnN0YW5jZS1TcGVjaWZpYyBNSUIgTW9kdWxlcw0NVGhl IGxhc3QgZWxlbWVudCB0byBhZGQgdG8gb3VyIGFyY2hpdGVjdHVyZSBpcyB0aGUgdHJhZGl0 aW9uYWwNTUlCIG1vZHVsZS4gVGhpcyBtb2R1bGUgaXMgYXQgdGhlIGluc3RhbmNlLXNwZWNp ZmljIGxldmVsIG9mDWFic3RyYWN0aW9uLiBJdCwgdG9vLCBjYW4gYmUgYmFzZWQgb24gYW4g SVRFRiBzdGFuZGFyZCBhbmQNaGF2ZSBhdWdtZW50YXRpb25zIGZvciBpbXBsZW1lbnRhdGlv bi1zcGVjaWZpYyBpbnN0YW5jZSB2YWx1ZXMNYXMgaGFzIGJlZW4gY29tbW9uIGZvciBzb21l IHRpbWUuIElmIGEgdmVuZG9yIGhhcw1pbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBNSUIgb2Jq ZWN0cywgdGhleSBzaG91bGQgYWxzbyBwcm92aWRlDU1JQiBvYmplY3RzIGZvciB0aGVzZSBp bXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBkZXRhaWxzIGF0IHRoZQ1pbnN0YW5jZSBpbmRlcGVu ZGVudCBsZXZlbCAobWVjaGFuaXNtIGFuZCBpbXBsZW1lbnRhdGlvbg1kZXBlbmRlbnQpLiBB biBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBNSUIgbW9kdWxlIHdpdGhvdXQgYQ1jb3JyZXNw b25kaW5nIGluc3RhbmNlIGJhc2VkIHZlcnNpb24gb2YgdGhvc2Ugb2JqZWN0cyB3b3VsZA1t YWtlIGl0IGltcG9zc2libGUgZm9yIGFuIFNOTVAgYmFzZWQgbWFuYWdlbWVudCBzeXN0ZW0g dG8gc2VlDXRoZSBpbnN0YW5jZS1zcGVjaWZpYyB2YWx1ZXMgb24gd2hpY2ggdGhlIGltcGxl bWVudGF0aW9uLQ1zcGVjaWZpYyBNSUIgbW9kdWxlIGlzIHByZXN1bWVkIHRvIG9wZXJhdGUg b24uDQ1UaGUgaW5mb3JtYXRpb24gc2VudCBieSB0aGUgbWFuYWdlbWVudCBzdGF0aW9uIHRv IHRoZQ1tZWNoYW5pc20gYW5kIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIE1JQiBNb2R1bGVz IGlzIGV4cHJlc3NlZA1pbiBJbXBsZW1lbnRhdGlvbiBhbmQgTWVjaGFuaXNtIGRlcGVuZGVu dCBhbmQgaW5zdGFuY2UNaW5kZXBlbmRlbnQgdGVybXMuIFdoZW4gdGhlIHBvbGljeSBtYW5h Z2VtZW50IGFwcGxpY2F0aW9uDXdhbnRzIHRvIGhhdmUgdGhlIHBvbGljeSBhY3RpdmF0ZWQg aW4gdGhlIG1hbmFnZWQgZGV2aWNlLCBhDWNvbW1hbmQgaXMgaXNzdWVkIHRoYXQgY2F1c2Vz IHRoZSBtYW5hZ2VkIGVsZW1lbnQgdG8gdGFrZSB0aGUNaW5mb3JtYXRpb24gaW4gdGhlIFBv bGljeSBNSUIgTW9kdWxlIGFuZCB0aGUgbWVjaGFuaXNtIGFuZA1pbXBsZW1lbnRhdGlvbi1z cGVjaWZpYyBNSUIgTW9kdWxlcyBhbmQgY29tYmluZSB0aGVtIHRvIGNyZWF0ZQ10aGUgaW1w bGVtZW50YXRpb24sIG1lY2hhbmlzbSBhbmQgaW5zdGFuY2Utc3BlY2lmaWMNaW5mb3JtYXRp b24gdXNlZCBieSB0aGUgZGV2aWNlLiBUaGUgaW5zdGFuY2VzIGFyZSBjcmVhdGVkDXVzaW5n IHRoZSBuYXRpdmUgZmFjaWxpdGllcyBpbiB0aGUgaW5zdGFuY2Utc3BlY2lmaWMgTUlCDW1v ZHVsZXMgYW5kIHRoZSB2YWx1ZXMgb2YgdGhlIGluc3RhbmNlcyBhcmUgdmlzaWJsZSBpbiB0 aGUNaW5zdGFuY2Utc3BlY2lmaWMgTUlCIG1vZHVsZXMgYXMgaGFzIHRyYWRpdGlvbmFsbHkg YmVlbiB0aGUNY2FzZSB3aXRoIFNOTVAtYmFzZWQgaW5mb3JtYXRpb24uDQ1GSUdVUkUgNC4g TWVjaGFuaXNtLCBJbXBsZW1lbnRhdGlvbiBhbmQgSW5zdGFuY2UtU3BlY2lmaWMgTUlCDU1v ZHVsZXMgLSBTZWUgLnBzIHZlcnNpb24uDQ0NDQ0NDQ0NU2FwZXJpYSAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAyMF0NDA1JbnRlcm5ldCBE cmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwgMjAwMA0N DTUuMy4gIFRoZSBwcm9jZXNzIG9mIENvbmZpZ3VyYXRpb24gTWFuYWdlbWVudA0NSW4gdGhp cyBzZWN0aW9uIHdlIHdpbGwgd2FsayB0aHJvdWdoIHRoZSBzdGVwcyBhbiBpbnRlZ3JhdGVk DVNOTVAtYmFzZWQgcG9saWN5IG1hbmFnZW1lbnQgc3lzdGVtIHdvdWxkIHRha2UgdG8gY29u ZmlndXJlIGENc3lzdGVtIHRoYXQgaXMNDQ0gICAgIDEuIFVzZXJzIHByb3ZpZGUgcG9saWN5 IGluZm9ybWF0aW9uIHRvIHRoZSBtYW5hZ2VtZW50DSAgICAgYXBwbGljYXRpb25zLiBJbiBv cmRlciBmb3IgdGhlIHBvbGljeSBtYW5hZ2VtZW50DSAgICAgYXBwbGljYXRpb25zIHRvIGNv cnJlY3RseSBjb250cm9sIHBvbGljeSBpbiBhbGwgb2YgdGhlDSAgICAgbWFuYWdlZCBlbGVt ZW50cywgdXNlcnMgbXVzdCBwcm92aWRlIGluZm9ybWF0aW9uIG9mDSAgICAgc2V2ZXJhbCB0 eXBlcyB0byB0aGUgcG9saWN5IG1hbmFnZW1lbnQgYXBwbGljYXRpb25zLiBJdA0gICAgIGlz IHBvc3NpYmxlIHRoYXQgJ3VzZXJzJyBpbiB0aGlzIGNhc2UgY291bGQgYWxzbyBtZWFuDSAg ICAgc29mdHdhcmUgdGhhdCBleHRyYWN0cyBpbmZvcm1hdGlvbiBmcm9tIG90aGVyIHNvdXJj ZXMuDSAgICAgVGhlIHR5cGVzIG9mIGluZm9ybWF0aW9uIG5lZWRlZCBieSBhIHBvbGljeSBt YW5hZ2VtZW50DSAgICAgYXBwbGljYXRpb24gYXJlOg0NDSAgICAgLSBUaGUgZmlsdGVyL3J1 bGVzIHRoYXQgYXJlIHRvIGJlIHNlbnQgdG8gZWFjaCBtYW5hZ2VkDSAgICAgZGV2aWNlLiBU aGlzIGlzIHRoZSBpbmZvcm1hdGlvbiB0aGF0IGlzIHVzZWQgdG8gZGV0ZXJtaW5lDSAgICAg dG8gd2hhdCBpbnN0YW5jZXMgYSBwb2xpY3kgaXMgdG8gYmUgYXBwbGllZC4gVGhpcw0gICAg IGluZm9ybWF0aW9uIHdpbGwgYmUgc2VudCB0byB0aGUgUG9saWN5IEZpbHRlciBvYmplY3Qg aW4NICAgICB0aGUgUG9saWN5IFRhYmxlIG9mIHRoZSBQb2xpY3kgTUlCIE1vZHVsZS4gQSBw b2xpY3kgY291bGQNICAgICByZXF1aXJlIHNldmVyYWwgY29uZGl0aW9ucyB0byBiZSBtZXQg YmVmb3JlIGFuIGluc3RhbmNlDSAgICAgaW4gYSBkZXZpY2UgaXMgdG8gYmUgaW5jbHVkZWQu IEZvciBleGFtcGxlLCB0aGUgZmlsdGVyDSAgICAgY291bGQgcmVxdWlyZSB0aGF0IHRoZSBw b2xpY3kgYmUgYXBwbGllZCBvbmx5IHRvDSAgICAgaW50ZXJmYWNlcyB0aGF0IGFyZSBFdGhl cm5ldCBhbmQgYXJlIGFsc28gY29ubmVjdGVkIHRvDSAgICAgY2VydGFpbiBkZXBhcnRtZW50 cyBzdWNoIGFzIHRoZSBhY2NvdW50aW5nIGRlcGFydG1lbnQuIEENICAgICBkaWZmZXJlbnQg cnVsZSBmb3IgYW5vdGhlciBwb2xpY3kgbWlnaHQgcmVxdWlyZSB0aGF0IGFuDSAgICAgaW50 ZXJmYWNlIGJlIGFuIE9DLTEyIGFuZCBiZSBjb25uZWN0ZWQgdG8gYSBwYXJ0aWN1bGFyDSAg ICAgY2FycmllciBiZWZvcmUgdGhlIHBvbGljeSBpcyBhcHBsaWVkLg0NDSAgICAgLSBTY2hl ZHVsZSBpbmZvcm1hdGlvbi4gU29tZSBwb2xpY2llcyBhcmUgaW50ZW5kZWQgdG8gcnVuDSAg ICAgY29udGludW91c2x5LCB3aGlsZSBvdGhlcnMgJ2ZpcmUnIG9uY2UsIGFuZCBzdGlsbCBv dGhlcnMNICAgICBydW4gb25seSBhdCBzcGVjaWZpYyB0aW1lIHBlcmlvZHMuIFRoZSBpbmZv cm1hdGlvbiB0aGF0DSAgICAgaXMgdG8gYmUgc2VudCB0byBlYWNoIG1hbmFnZWQgZGV2aWNl IGluIHRoZSBuZXR3b3JrIHRoYXQNICAgICBpcyB0byBjYXJyeSBvdXQgdGhpcyBwb2xpY3kg bXVzdCBiZSBwcm92aWRlZCB0byB0aGUNICAgICBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uLg0N DSAgICAgLSBJbXBsZW1lbnRhdGlvbiBhbmQgbWVjaGFuaXNtLXNwZWNpZmljIGluZm9ybWF0 aW9uLg0gICAgIFRoZXNlIGFyZSB0aGUgZGV0YWlscyBvZiBob3cgdGhlIHBvbGljeSBpcyBy ZWFsaXplZCBpbiBhDSAgICAgZGV2aWNlLiBUaGlzIGlzIGhvdyB0aGUgYWRtaW5pc3RyYXRp dmVseSBkZWZpbmVkIHBvbGljeQ0gICAgIGFuZCBwb2xpY2llcyBleHByZXNzZWQgYXQgdGhl IGltcGxlbWVudGF0aW9uLCBtZWNoYW5pc20sDQ0NDQ0NU2FwZXJpYSAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAyMV0NDA1JbnRlcm5ldCBE cmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwgMjAwMA0N DSAgICAgYW5kIGluc3RhbmNlIGluZGVwZW5kZW50IGxldmVscyBvZiBhYnN0cmFjdGlvbiBn ZXQNICAgICB0cmFuc2xhdGVkIHRvIHNvbWV0aGluZyB0aGF0IGlzIG1lYW5pbmdmdWwgdG8g YSBuZXR3b3JrDSAgICAgZGV2aWNlLiBUbyB1c2Ugb3VyIHRlbGVwaG9ueSBleGFtcGxlLCB0 aGUgcGFyYW1ldGVycw0gICAgIHdvdWxkIGJlIHNwZWNpZmljIHRvIGEgcGFydGljdWxhciB2 ZW5kb3IgYW5kIHBlcmhhcHMgZXZlbg0gICAgIG1vZGVsLiBUaGlzIGlzIHRoZSBpbnN0YW5j ZSBpbmRlcGVuZGVudCBpbmZvcm1hdGlvbiB0aGF0DSAgICAgaXMgc2VudCB0byB0aGUgbWVj aGFuaXNtIGFuZCB0ZWNobm9sb2d5IHNwZWNpZmljIE1JQg0gICAgIE1vZHVsZXMuIEluIHRo ZSBjYXNlIG9mIGRpZmZlcmVudGlhdGVkIHNlcnZpY2VzLCB0aGlzDSAgICAgaW5mb3JtYXRp b24gY291bGQgaW5jbHVkZSB0aGUgdmFsdWVzIHRoYXQgYWxsIHF1ZXVlcw0gICAgIGFzc29j aWF0ZWQgd2l0aCBhIHNwZWNpZmljIHBvbGljeSBzaG91bGQgdXNlIGZvciB0aGVpcg0gICAg IFdlaWdodGVkIEZhaXIgUXVldWluZyBwYXJhbWV0ZXJzLg0NDSAgICAgLSBNYW55IG9mIHRo ZSAnUm9sZXMnIHRoYXQgYXJlIGV4cHJlc3NlZCBpbiB0aGUgcG9saWN5DSAgICAgZmlsdGVy IG9iamVjdCBhcmUgbm90IGFsZ29yaXRobWljbHkgZGV0ZXJtaW5hYmxlIGJ5IGENICAgICBj b21wdXRlciBzeXN0ZW0gYW5kIG11c3QgYmUgYXNzaWduZWQgb24gZWFjaCBuZXR3b3JrDSAg ICAgZGV2aWNlLiBJdCBtYXkgbm90IGJlIHBvc3NpYmxlIGZvciB0aGUgbmV0d29yayBlbGVt ZW50IHRvDSAgICAga25vdyB0aGF0IHNvbWUgaW50ZXJmYWNlcyBhcmUgY29ubmVjdGVkIHRv IHRoZSBhY2NvdW50aW5nDSAgICAgZGVwYXJ0bWVudCBvciB0aGF0IG90aGVyIGludGVyZmFj ZXMgYXJlIGNvbm5lY3RlZCB0byBhDSAgICAgc3BlY2lmaWMgY2Fycmllci4gRm9yIHRoaXMg cmVhc29uLCB0aGUgbWFuYWdlbWVudA0gICAgIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSB0byBj b25maWd1cmUgdGhlICdSb2xlIFRhYmxlJyBpbg0gICAgIHRoZSBQb2xpY3kgTUlCIE1vZHVs ZS4gVGhpcyBpcyBob3cgdGhlIG1hbmFnZWQgZWxlbWVudA0gICAgIHdpbGwga25vdyB0aGF0 IGEgcGFydGljdWxhciBpbnRlcmZhY2UgbWF0Y2hlcyBvciBkb2VzIG5vdA0gICAgIG1hdGNo IGEgcGFydGljdWxhciBwb2xpY3kgZmlsdGVyLiBPbmUgb2YgdGhlIGFkdmFudGFnZXMNICAg ICBvZiB1c2luZyBTTk1QIGZvciBwb2xpY3kgYmFzZWQgbWFuYWdlbWVudCBpcyB0aGF0IG1h bnkgb2YNICAgICB0aGUgJ2ZpbHRlcnMnIHRoYXQgcGVvcGxlIHdvdWxkIHdhbnQgdG8gdXNl IGFyZSBhbHJlYWR5DSAgICAgZGVmaW5lZCBpbiB0ZXJtcyBvZiBNSUIgb2JqZWN0cyBhbmQg dGh1cyBjYW4gYmUgdXNlZA0gICAgIGRpcmVjdGx5LiBGb3IgZXhhbXBsZSwgdGhlIHR5cGUg b2YgaW50ZXJmYWNlIHVzZWQgaW4gdGhlDSAgICAgZXhhbXBsZSBhYm92ZSB3b3VsZCBiZSB2 ZXJ5IGVhc3kgdG8gc3BlY2lmeSB0byBhIG1hbmFnZWQNICAgICBlbGVtZW50IGJ5IGdpdmlu ZyB0aGUgc3BlY2lmaWMgdmFsdWUgb2YgdGhlIG9iamVjdCB0aGF0DSAgICAgY29udGFpbnMg dGhlIGludGVyZmFjZSB0eXBlIGFzIG9uZSBvZiB0aGUgcGFydHMgb2YgdGhlDSAgICAgcG9s aWN5IGZpbHRlci4NDSAgICAgRklHVVJFIDUuIEFuIFNOTVAtQmFzZWQgUG9saWN5IE1hbmFn ZW1lbnQgU3lzdGVtIC0gSW5wdXRzDSAgICAgLSBTZWUgLnBzIHZlcnNpb24NDSAgICAgRmln dXJlIDUgcmVwcmVzZW50cyBpbnB1dHMgdGhhdCBhcmUgcmVxdWlyZWQgZm9yIGEgcG9saWN5 DSAgICAgZW5hYmxlZCBTTk1QIG1hbmFnZW1lbnQgc3lzdGVtLiBOb3RlIHRoYXQgdGhlDSAg ICAgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IHNwZWNpZnkgb3IgYXNzdW1lIHRoZSBvcmlnaW4g b2YgdGhlDSAgICAgcm9sZSwgc2NoZWR1bGUsIGZpbHRlciBvciBtZWNoYW5pc20gYW5kIGlt cGxlbWVudGF0aW9uLQ0gICAgIHNwZWNpZmljIGluZm9ybWF0aW9uLiBUaGlzIGlzIGNvbnNp c3RlbnQgd2l0aCBjdXJyZW50DSAgICAgcHJhY3RpY2UgaW4gdGhlIFNOTVAgY29tbXVuaXR5 LiBNYW5hZ2VtZW50IHNvZnR3YXJlIHRvZGF5DSAgICAgdGFrZXMgaW5wdXRzIGZyb20gaHVt YW5zLCBkYXRhYmFzZSBzeXN0ZW1zIGFuZCBvdGhlcg0gICAgIHJlcG9zaXRvcmllcyBhcyB3 ZWxsIGFzIGEgd2lkZSB2YXJpZXR5IG9mIHN0YW5kYXJkIGFuZA0gICAgIHByb3ByaWV0YXJ5 IEFQSXMuIEFsc28gbm90ZSB0aGF0IHRoZSBhcmNoaXRlY3R1cmUgZG9lcw0gICAgIG5vdCBh c3N1bWUgdGhhdCB0aGUgbWFuYWdlbWVudCBhcHBsaWNhdGlvbnMgcnVuIGluIGENDQ0NDQ1T YXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQ YWdlIDIyXQ0MDUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNO TVAgICAgSnVseSA2LCAyMDAwDQ0NICAgICBwYXJ0aWN1bGFyIGxvY2F0aW9uLiBJdCBpcyBs aWtlbHkgdGhhdCBtYW5hZ2VyIHN0YXRpb25zDSAgICAgZGVkaWNhdGVkIHRvIHBvbGljeSBv ciBvdGhlciBtYW5hZ2VtZW50IGFjdGl2aXRpZXMgd2lsbA0gICAgIGJlIHVzZWQgdG8gbWFu YWdlIG51bWJlcnMgb2YgbmV0d29yayBlbGVtZW50cyBhdCBvbmUNICAgICB0aW1lLiBTTk1Q IHdpbGwgYmUgdGhlIHByb3RvY29sIHVzZWQgdG8gY29tbXVuaWNhdGUgdGhhdA0gICAgIG1h bmFnZW1lbnQgaW5mb3JtYXRpb24uIFRoZXJlIGlzIG5vdGhpbmcgaW5oZXJlbnQgaW4gdGhl DSAgICAgcG9saWN5IHdvcmsgdGhhdCB3b3VsZCBwcm9oaWJpdCBhIHZlbmRvciBmcm9tIHB1 dHRpbmcNICAgICB0aGVzZSBhcHBsaWNhdGlvbnMgb24gYW55IHN5c3RlbSwgbWlkLWxldmVs IG1hbmFnZXIgb3INICAgICBtYW5hZ2VkIGVsZW1lbnQuDQ0gICAgIENvbmZpZ3VyYXRpb24g aW4gYW4gU05NUC1iYXNlZCBwb2xpY3kgbWFuYWdlbWVudCBzeXN0ZW0NICAgICBjb250aW51 ZXMgYWZ0ZXIgdGhlIGZpcnN0IHN0ZXAgaXMgY29tcGxldGVkIGFzIGp1c3QNICAgICBkZXNj cmliZWQsIHNlZSBpdGVtIDEgdGhhdCBiZWdhbiB0aGlzIHNlY3Rpb24uIFRoZSBuZXh0DSAg ICAgc3RlcHMgYXJlOg0NDSAgICAgMi4gTWVjaGFuaXNtLXNwZWNpZmljIHN1YnN5c3RlbSBp biB0aGUgbWFuYWdlZCBkZXZpY2UNICAgICByZWdpc3RlcnMgd2l0aCBwb2xpY3kgbW9kdWxl LiBUaGUgcG9saWN5IG1vZHVsZSBoYXMgYQ0gICAgIGNhcGFiaWxpdGllcyB0YWJsZSB0aGF0 IGlzIHBvcHVsYXRlZCBieSB0aGUgdmFyaW91cw0gICAgIG1lY2hhbmlzbS1zcGVjaWZpYyBz dWJzeXN0ZW1zIGluIGEgbWFjaGluZS4gSW4gb3VyIGNhc2UsDSAgICAgdGhlIERpZmZlcmVu dGlhdGVkIFNlcnZpY2VzIFBvbGljeSBNSUIgTW9kdWxlIHdvdWxkDSAgICAgcmVnaXN0ZXIg d2l0aCB0aGUgUG9saWN5IE1JQiBNb2R1bGUgdGhhdCBpdCBpcyBwcmVzZW50DSAgICAgYW5k IGNhbiBwZXJmb3JtIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIEZ1bmN0aW9ucy4gVGhpcw0g ICAgIHJlZ2lzdHJhdGlvbiBtZWNoYW5pc20gd291bGQgcmVhbGx5IGJlIG5vIGRpZmZlcmVu dCB0aGF0DSAgICAgdGhlIHJlZ2lzdHJhdGlvbiBtZWNoYW5pc20gdGhhdCBtYW55IGltcGxl bWVudGF0aW9ucyBvZg0gICAgIG1hc3RlciBhbmQgc3ViYWdlbnQgdGVjaG5vbG9neSB1c2Ug dG9kYXkuIE1hbnkgc3VjaA0gICAgIHRlY2hub2xvZ2llcyBwcm92aWRlIGEgd2F5IGZvciBh IHN1YmFnZW50IHRvIHRlbGwgdGhlDSAgICAgbWFzdGVyIGFnZW50IHdoYXQgTUlCIG9iamVj dHMgaXQgc3VwcG9ydHMgd2hlbiB0aGUNICAgICBzdWJhZ2VudCBpcyBzdGFydGVkLg0NDSAg ICAgMy4gTWFuYWdlciB0aGVuICdrbm93cycgc3lzdGVtIGNhcGFiaWxpdGllcyAoZS5nLiwg V2ViDSAgICAgU2VydmVyLCBWUE4gU3VwcG9ydCwgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMs IE1QTFMpLg0gICAgIE1hbmFnZXJzIHdpbGwgbmVlZCB0byBrbm93IHRoZSBtZWNoYW5pc20t c3BlY2lmaWMgZGV0YWlscw0gICAgIHN1cHBvcnRlZCBieSBlYWNoIHN1YnN5c3RlbS4gSW4g c29tZSBjYXNlcyBpdCBtYXkgbm90IGJlDSAgICAgZWFzeSB0byBkaXNhbWJpZ3VhdGUgd2hh dCB0aGV5IGFyZSB3aXRob3V0IGludGVycm9nYXRpbmcNICAgICB0aGUgbWVjaGFuaXNtLXNw ZWNpZmljIHN1YnN5c3RlbSAoZS5nLiwgd2hhdCBXRlENICAgICBwYXJhbWV0ZXJzIGFyZSBz dXBwb3J0ZWQgb24gdGhpcyBzeXN0ZW0gdGhhdCBpcyBydW5uaW5nIGENICAgICBwYXJ0aWN1 bGFyIHNvZnR3YXJlIHJlbGVhc2UpLiBUaGVyZSBhcmUgdHdvIG1lY2hhbmlzbXMNICAgICB0 aHJvdWdoIHdoaWNoIGEgbWFuYWdlciBjYW4gJ2xlYXJuJyB0aGUgY2FwYWJpbGl0aWVzIG9m IGENICAgICBkZXZpY2UgYXMgcmVwcmVzZW50ZWQgaW4gdGhlIGNhcGFiaWxpdGllcyB0YWJs ZS4gVGhlDSAgICAgZmlyc3QsIGFuZCBwcmVmZXJyZWQgbWV0aG9kLCBpcyBieSB0aGUgbWFu YWdlZCBkZXZpY2UNICAgICBzZW5kaW5nIGFuIElORk9STSB0byB0aGUgbWFuYWdlciB3aGVu ZXZlciB0aGVyZSBpcyBhDSAgICAgY2hhbmdlIGluIHRoZSBjYXBhYmlsaXRpZXMgdGFibGUu IFNvbWUgbWFuYWdlbWVudA0gICAgIGFwcGxpY2F0aW9ucyBtYXkgd2FudCB0byBjaGVjayB0 aGUgZW50aXJlIGNvbnRlbnRzIG9mDSAgICAgdGhlc2UgdGFibGVzIHBlcmlvZGljYWxseS4g Tm90ZSB0aGF0IGluIHRoZSBjYXNlIG9mIGFuDQ0NDQ0NU2FwZXJpYSAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAyM10NDA1JbnRlcm5ldCBE cmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwgMjAwMA0N DSAgICAgU05NUCBJTkZPUk0sIHRoZXNlIG1lc3NhZ2VzIGFyZSBhY2tub3dsZWRnZWQgYnkg dGhlDSAgICAgbWFuYWdlciBzbyB0aGF0IHRoZSBtYW5hZ2VkIGRldmljZSBrbm93cyB0aGUg bWVzc2FnZSBoYXMNICAgICBiZWVuIHJlY2VpdmVkLiBBbiBpbXBvcnRhbnQgYWR2YW50YWdl IG9mIHRoaXMgYXBwcm9hY2ggaXMNICAgICB0aGF0IG11bHRpcGxlIG1hbmFnZW1lbnQgc3lz dGVtcyBjYW4gYmUga2VwdCBpbiBzeW5jIHdpdGgNICAgICB0aGUgbWFuYWdlZCBkZXZpY2Vz IGluIGEgbmV0d29yayB3aXRob3V0IHBvbGxpbmcgYW5kDSAgICAgd2l0aG91dCBoYXZpbmcg dG8gbWFpbnRhaW4gYSBUQ1AgY29ubmVjdGlvbiB0byBldmVyeQ0gICAgIG1hbmFnZWQgZGV2 aWNlIGluIHRoZSBuZXR3b3JrLg0NDSAgICAgNC4gTWFuYWdlcnMvbWFuYWdlbWVudCBzb2Z0 d2FyZSBzZW5kIHByZXZpb3VzbHkgZGVmaW5lZA0gICAgIHJvbGVzIHRvIGVhY2ggZGV2aWNl IGFuZCBhc3NvY2lhdGUgdGhlbSB3aXRoIHNwZWNpZmljDSAgICAgaW5zdGFuY2VzIGluIHRo ZSBkZXZpY2UuIFRoaXMgaXMgYWNjb21wbGlzaGVkIGJ5IHRoZQ0gICAgIG1hbmFnZXIgdmlh IHNlbmRpbmcgU05NUCBTRVQgb3BlcmF0aW9ucyB0byB0aGUgUm9sZSBUYWJsZQ0gICAgIGlu IHRoZSBQb2xpY3kgTW9kdWxlIGluIGVhY2ggbWFuYWdlZCBkZXZpY2UuIFJvbGVzIGNhbiBi ZQ0gICAgIGp1c3QgYWJvdXQgYW55dGhpbmcgZnJvbSBhbiBpbmRpY2F0aW9uIHRoYXQgYW4g aW50ZXJmYWNlDSAgICAgbWFya2VkIHdpdGggdGhpcyByb2xlIHNlcnZlcyBhbiBFeGVjdXRp dmUgb2ZmaWNlLCB0byB0aGUNICAgICBpbnRlcmZhY2UgaXMgYSBiYWNrdXAsIHRvIHRoZSBw ZXJzb24gY29ubmVjdGVkIHRvIHRoZQ0gICAgIGludGVyZmFjZSBoYXMgbm90IHBhaWQgZm9y IHByZW1pdW0gc2VydmljZXMuIFJvbGVzIGNhbiBiZQ0gICAgIGFzc29jaWF0ZWQgd2l0aCBh bnkgaW5zdGFuY2Ugc3BlY2lmaWMgZWxlbWVudCwgZnJvbSBhDSAgICAgcGFydGljdWxhciBp bnN0YW5jZSBvZiBhbiBFdGhlcm5ldCBpbnRlcmZhY2UgdG8gYQ0gICAgIHNwZWNpZmljIGlu c3RhbmNlIG9mIGEgV2ViIHNlcnZlci4NDQ0gICAgIDUuIE1hbmFnZXJzIHNlbmQgcG9saWNp ZXMgdG8gbWFuYWdlZCBkZXZpY2VzLiBUaGlzIGNhbg0gICAgIHRha2Ugb25lIG9mIHR3byBm b3JtcyBhcyBtZW50aW9uZWQgcHJldmlvdXNseS4gSW4gYQ0gICAgIHNpbXBsZSBjYXNlLCB0 aGUgcG9saWN5QWN0aW9uIE1JQiBPYmplY3QgY29udGFpbnMgYQ0gICAgIHNpbXBsZSBleHBy ZXNzaW9uICh3ZSB1c2VkIHRoZSBsb2FkIE9wZXJhdGluZyBTeXN0ZW0NICAgICB2ZXJzaW9u IGVhcmxpZXIpLiBJbiB0aGUgY2FzZSB3aGVyZSB0aGVyZSBpcyBhIGdyZWF0IGRlYWwNICAg ICBvZiBtZWNoYW5pc20tc3BlY2lmaWMgaW5mb3JtYXRpb24gdG8gYmUgY29udmV5ZWQgYXMg aW4NICAgICB0aGUgY2FzZSBvZiBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBvciBSb3V0aW5n IFBvbGljeSwNICAgICB0aGVuIGEgbWVjaGFuaXNtLXNwZWNpZmljIG1vZHVsZSBpcyByZWNv bW1lbmRlZC4gIFRoZQ0gICAgIG1lY2hhbmlzbSBhbmQgaW1wbGVtZW50YXRpb24gaW5kZXBl bmRlbnQgcG9saWN5IGlzIGxvYWRlZA0gICAgIGludG8gdGhlIFBvbGljeSBNb2R1bGUgYnkg dGhlIG1hbmFnZW1lbnQgYXBwbGljYXRpb24gYW5kDSAgICAgdGhlIGltcGxlbWVudGF0aW9u IGFuZCBtZWNoYW5pc20tc3BlY2lmaWMgZGVmYXVsdHMgKHdoZXJlDSAgICAgbmVjZXNzYXJ5 KSBhcmUgbG9hZGVkIGludG8gdGhlIG1lY2hhbmlzbSBhbmQNICAgICBpbXBsZW1lbnRhdGlv bi1zcGVjaWZpYyBNSUIgTW9kdWxlcyBpbiB0aGUgZGV2aWNlIGJ5IHRoZQ0gICAgIG1hbmFn ZXIuIFRoZSBwb2xpY3lGaWx0ZXIgb2JqZWN0IGluIHRoZSBQb2xpY3kgdGFibGUNICAgICBj b250YWlucyB0aGUgZXhwcmVzc2lvbiBzZW50IGJ5IHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB0 bw0gICAgIHRoZSBkZXZpY2UgdGhhdCB0aGUgZGV2aWNlIGlzIHRvIHVzZSB0byBkZXRlcm1p bmUgd2hpY2gNICAgICBpbnN0YW5jZXMgdG8gYXBwbHkgdGhlIHBvbGljeUFjdGlvbiB0by4N DQ0gICAgIDYuIE1hbmFnZWQgZGV2aWNlcyBldmFsdWF0ZSB0aGUgUG9saWN5IEZpbHRlciBh bmQgUG9saWN5DSAgICAgQWN0aW9uIE9iamVjdHMgdG8gZGV0ZXJtaW5lIHdoZXJlIGFuZCB3 aGVuIHRoZSBwb2xpY3kgaXMNICAgICBhcHBsaWVkLiBOb3RlIHRoYXQgYW4gaW1wb3J0YW50 IHBhcnQgb2YgdGhlIFBvbGljeSBNb2R1bGUNDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdlIDI0XQ0MDUludGVybmV0IERy YWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0N ICAgICBpcyBhIHBvaW50ZXIgdG8gW1NDSEVEXSB0aGF0IHRlbGxzIHRoZSBzeXN0ZW0gd2hl biBhbmQNICAgICBmb3IgaG93IGxvbmcgdG8gZXhlY3V0ZSBhIHBvbGljeS4gVGhlIGV4cHJl c3Npb24NICAgICBjb250YWluZWQgaW4gdGhlIHBvbGljeSBmaWx0ZXIgY29udGFpbnMgdGhl IGluZm9ybWF0aW9uDSAgICAgdGhhdCB0aGUgbWFuYWdlZCBkZXZpY2UgcmVxdWlyZXMgdG8g bG9vayB0aHJvdWdoIHRoZSBSb2xlDSAgICAgdGFibGUgdG8gZGV0ZXJtaW5lIHdoaWNoIGlu c3RhbmNlcyBvZiBvYmplY3RzIHRvIGFwcGx5DSAgICAgdGhlIGFjdGlvbiBjb250YWluZWQg aW4gdGhlIHBvbGljeUFjdGlvbiBvYmplY3QuDQ0NICAgICA3LiBJbXBsZW1lbnRhdGlvbiBh bmQgTWVjaGFuaXNtLXNwZWNpZmljIG1vZHVsZSBzZXRzDSAgICAgbmVjZXNzYXJ5IHZhbHVl cyB2aWEgaW5zdGFuY2Utc3BlY2lmaWMgc3Vic3lzdGVtLiBJZiB0aGUNICAgICBwb2xpY3kg YWN0aW9uIGluZGljYXRlZCBhIG1lY2hhbmlzbSBhbmQgaW1wbGVtZW50YXRpb24tDSAgICAg c3BlY2lmaWMgbW9kdWxlLCB0aGVuIHRoZSB2YXJpb3VzIG1lY2hhbmlzbSBhbmQNICAgICBp bXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBwYXJhbWV0ZXJzIGFzc29jaWF0ZWQgd2l0aCB0aGUN ICAgICBwb2xpY3kgd291bGQgYmUgYXBwbGllZCB0byB0aGUgaW5zdGFuY2VzIHRoYXQgd2Vy ZSB0aGUNICAgICByZXN1bHQgb2YgdGhlIHBvbGljeSBmaWx0ZXIgZXZhbHVhdGlvbiBvZiB0 aGUgUm9sZSBUYWJsZS4NICAgICBBbiBpbXBvcnRhbnQgY2hhcmFjdGVyaXN0aWMgb2YgdGhp cyBhcHByb2FjaCBpcyB0aGF0DSAgICAgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgYWRkaXRp b25zIGFyZSBlYXNpbHkgYWNjb21wbGlzaGVkDSAgICAgd2l0aCB0aGlzIGFwcHJvYWNoIHZp YSBhdWdtZW50aW5nIHRoZSBtZWNoYW5pc20tc3BlY2lmaWMNICAgICBNSUIgTW9kdWxlcy4g VGhpcyBpcyBleGFjdGx5IHRoZSBzYW1lIGFwcHJvYWNoIHRoYXQNICAgICB2ZW5kb3JzIGhh dmUgdXNlZCBmb3Igc29tZSB0aW1lIHRvIGFkZCBleHRlbnNpb25zIHRvDSAgICAgc3RhbmRh cmQgTUlCIE1vZHVsZXMgZm9yIGNvbmZpZ3VyYXRpb24gYW5kIG1vbml0b3JpbmcNICAgICBv cGVyYXRpb25zLg0NDSAgICAgOC4gTWFuYWdlbWVudCBzb2Z0d2FyZSBtb25pdG9ycyB1c2Fn ZSBhbmQgc3RhdHVzIHRvDSAgICAgcmVmaW5lIHBvbGljeSBhbmQgdmVyaWZ5IHBvbGljeSBj aGFuZ2VzLiBTaW5jZSB0aGlzDSAgICAgYXBwcm9hY2ggZG9lcyBtYWtlIGl0IHBvc3NpYmxl IGZvciBhIG1hbmFnZW1lbnQgc3lzdGVtIHRvDSAgICAga25vdyB0aGUgaW5zdGFuY2VzIHRo YXQgYXJlIGJlaW5nIHVzZWQgdG8gc3VwcG9ydA0gICAgIHBvbGljaWVzLCB0aGV5IGNhbiBi ZXR0ZXIgbW9uaXRvciBhbmQgY29udHJvbCBvdmVyYWxsDSAgICAgbmV0d29yayBiZWhhdmlv ci4gRm9yIGV4YW1wbGUsIGlmIHRoZXJlIGlzIGFuIGludGVyZmFjZQ0gICAgIGZhaWx1cmUg dGhhdCBpcyBhc3NvY2lhdGVkIHdpdGggYSBwb2xpY3ksIGEgbWFuYWdlciBjYW4NICAgICBi ZSBpbmZvcm1lZCBhbmQgcGVyaGFwcyBkaXNwbGF5IHRoZSBwb2xpY2llcyB0aGF0IGFyZQ0g ICAgIGxpa2VseSB0byBiZSBpbXBhY3RlZCBieSBzdWNoIGEgZmFpbHVyZS4gQWRkaXRpb25h bGx5LA0gICAgIHRoaXMgYXBwcm9hY2ggd291bGQgYWxsb3cgbW9yZSBlZmZlY3RpdmUgZGF0 YSBjb2xsZWN0aW9uDSAgICAgb2YgcGVyZm9ybWFuY2Ugc3RhdGlzdGljcyBzbyB0aGF0IHZl bmRvcnMgY2FuIGJldHRlciBwbGFuDSAgICAgd2hhdCByZXNvdXJjZXMgdGhleSBuZWVkIHRv IHVwZ3JhZGUgaW4gb3JkZXIgdG8gc3VwcG9ydA0gICAgIHRoZWlyIGN1c3RvbWVycyBiZWZv cmUgdGhlIHJlc291cmNlcyByZWFjaCBleGhhdXN0aW9uLg0NICAgICBQYXJ0IG9mIHRoZSBw b3dlciBvZiBhbiBTTk1QLWJhc2VkIHBvbGljeSBzeXN0ZW0gaXMgdGhlDSAgICAgaW50ZWdy YXRpb24gb2YgZmF1bHQgYW5kIG90aGVyIHR5cGVzIG9mIGluZm9ybWF0aW9uIGluDSAgICAg dGhlIHNhbWUgaW5mcmFzdHJ1Y3R1cmUsIHRoZXkgdXNlIHRoZSBzYW1lIGFkbWluaXN0cmF0 aXZlDSAgICAgZnJhbWV3b3JrLCBhbmQgc2hhcmUgY29tbW9uIGFjY2VzcyBtZXRob2RzLiBX aXRob3V0IHRoZQ0gICAgIGZlZWRiYWNrIHByb3ZpZGVkIGJ5IGZhdWx0LCB1dGlsaXphdGlv biwgcGVyZm9ybWFuY2UgYW5kDSAgICAgb3RoZXIgZGF0YSwgaXQgaXMgbGlrZSBkcml2aW5n IGEgY2FyIHdpdGggeW91ciBleWVzIHNodXQuDSAgICAgWW91IGhhdmUgYWxsIHRoZSBjb250 cm9sIG9mZmVyZWQgYnkgdGhlIHN0ZWVyaW5nIHdoZWVsLA0NDQ0NDVNhcGVyaWEgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgNnRoIDIwMDEgICAgICAgICAgW1BhZ2UgMjVdDQwNSW50 ZXJuZXQgRHJhZnQgIFBvbGljeSBDb25maWd1cmF0aW9uIHdpdGggU05NUCAgICBKdWx5IDYs IDIwMDANDQ0gICAgIGJyYWtlIGFuZCBhY2NlbGVyYXRvciBidXQgeW91ciBmZWVkYmFjayBp cyBsaW1pdGVkIHRvDSAgICAgd2hhdCB5b3UgY2FuIGhlYXIgYW5kIGZlZWwgd2hlbiB5b3Ug dG91Y2ggc29tZXRoaW5nLiBJdA0gICAgIGlzIHBvc3NpYmxlIHRvIGhhdmUgc29tZW9uZSB0 ZWxsIHlvdSB3aGVyZSB5b3UgYXJlIG9uIHRoZQ0gICAgIHJvYWQsIG9yIGlmIGEgY2FyIGlz IGFwcHJvYWNoaW5nLCBidXQgdGhpcyBpcyBmYXIgbGVzcw0gICAgIGVmZmVjdGl2ZSB0aGFu IHVzaW5nIHlvdXIgb3duIHNpZ2h0IHRoYXQgaXMgZGlyZWN0bHkNICAgICBsaW5rZWQgdG8g eW91ciBjb250cm9sIHN5c3RlbSwgeW91ciBmZWV0IGZvciBicmFrZSBhbmQNICAgICBhY2Nl bGVyYXRvciBhbmQgeW91ciBoYW5kcyBmb3IgdGhlIHN0ZWVyaW5nIHdoZWVsIGlucHV0Lg0g ICAgIFRoaXMgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gaXMgZXZlbiBtb3JlIHNldmVyZSBpZiB0 aGUNICAgICBwZXJzb24gd2F0Y2hpbmcgdGhlIHJvYWQgc3BlYWtzIGEgbGFuZ3VhZ2UgdGhh dCB5b3UNICAgICBjYW5ub3QgdW5kZXJzdGFuZCBhbmQgbXVzdCBiZSBmaXJzdCB0cmFuc2xh dGVkIHRvIHlvdXINICAgICBsYW5ndWFnZSBieSBhbm90aGVyIHVuZm9ydHVuYXRlIHJpZGVy IGluIHlvdXIgY2FyLiAgVGhlDSAgICAgc2FtZSBpcyB0cnVlIG9mIHN5c3RlbXMgdGhhdCBh dHRlbXB0IGNvbmZpZ3VyYXRpb24NICAgICBvcGVyYXRpb25zIHdpdGhvdXQgdGhlIGltcG9y dGFudCBkYXRhIG5vdGVkIGFib3ZlLiBJdCBpcw0gICAgIHBvc3NpYmxlIHRvIGhhdmUgYW5v dGhlciBzeXN0ZW0gaW5mb3JtIHRoZSBjb25maWd1cmF0aW9uDSAgICAgc3lzdGVtIGFib3V0 IGZhdWx0cywgb3Zlci11dGlsaXphdGlvbiwgYW5kIHJlbWFpbmluZw0gICAgIGNhcGFjaXR5 LiBUaGUgYWRkaXRpb25hbCBsZXZlbHMgb2YgdHJhbnNsYXRpb24gYW5kDSAgICAgaW5kaXJl Y3Rpb24gY2FuIGJlIGV4cGVuc2l2ZSBhbmQgYXJlIG5vdCBuZWNlc3NhcnkgaWYgYWxsDSAg ICAgdGhlIGRhdGEgaXMgaW4gYSBjb21tb24gbGFuZ3VhZ2UuIFdlIGhhdmUgdGhhdCBsYW5n dWFnZSwNICAgICB0aGUgU01JdjIsIGFuZCB0aGUgTUlCIE9iamVjdHMgdGhhdCBhcmUgZGVm aW5lZCB3aXRoIGl0Lg0gICAgIFRoaXMgaXMgbm90IHRvIHNheSBsYW5ndWFnZXMgY2Fubm90 IGV2b2x2ZSAtIHRoZSB2Mg0gICAgIGluZGljYXRlcyB0aGlzLiBBcyBuZXcgZmVhdHVyZXMg YXJlIHJlcXVpcmVkIGZvciB0aGUNICAgICBmdXR1cmUgdGhleSBjYW4gYmUgYWRkZWQsIGp1 c3QgYXMgbmV3IGZlYXR1cmVzIGhhdmUgYmVlbg0gICAgIGFkZGVkIHRvIHJvdXRpbmcgcHJv dG9jb2xzIGFuZCBvdGhlciBlc3NlbnRpYWwgZWxlbWVudHMNICAgICBvZiB0aGUgSW50ZXJu ZXQgaW5mcmFzdHJ1Y3R1cmUuDQ0gICAgIE5vdCBpbmNsdWRlZCBpbiB0aGlzIGRpc2N1c3Np b24gaXMgdGhlIGltcG9ydGFudCB3b3JrIG9mDSAgICAgdGhlIGFwcGxpY2F0aW9uIGRldmVs b3BtZW50IHRoYXQgbXVzdCB0YWtlIHBsYWNlLiBUaGVzZQ0gICAgIGFwcGxpY2F0aW9ucyB3 aWxsIHRha2UgaW5mb3JtYXRpb24gZnJvbSBwb2xpY3kgc2VydmVycywNICAgICB0aGUgbmV0 d29yayBhbmQgaHVtYW5zIHRvIGRvIHRoZSByaWdodCB0aGluZ3MuDQ0gICAgIFRoZSBkaWFn cmFtIHRoYXQgZm9sbG93cyBpbGx1c3RyYXRlcyBwYXJ0cyBvZiBhbiBTTk1QDSAgICAgcG9s aWN5LWVuYWJsZWQgbWFuYWdlbWVudCBzeXN0ZW0gaW52b2x2ZWQgaW4gdGhlIHZhcmlvdXMN ICAgICBzdGVwcyBkZXNjcmliZWQgYWJvdmUuIFRoaXMgZXhhbXBsZSBpcyBmb3IgRGlmZmVy ZW50aWF0ZWQNICAgICBTZXJ2aWNlcywgdGhvdWdoIG1hbnkgb3RoZXJzIGFyZSBwb3NzaWJs ZSBhbmQgZXhwZWN0ZWQNICAgICBvdmVyIHRpbWUuIFVzZXJzIHByb3ZpZGUgaW5mb3JtYXRp b24gdG8gdGhlIG1hbmFnZW1lbnQNICAgICBhcHBsaWNhdGlvbnMgdGhhdCB0aGUgYXBwbGlj YXRpb25zIHdpbGwgdXNlIHRvIGNvbmZpZ3VyZQ0gICAgIHRoZSB2YXJpb3VzIG5ldHdvcmsg ZWxlbWVudHMuIFRoaXMgaW5mb3JtYXRpb24gaXMgdXNlZCBieQ0gICAgIHRoZSBuZXR3b3Jr IGVsZW1lbnRzIHRvIGV2YWx1YXRlIHRoZSBpbmZvcm1hdGlvbiB0aGF0DSAgICAgZnVsbHkg ZGVzY3JpYmVzIHRoZSBwb2xpY3kgYW5kIHRoZW4gY29uZmlndXJlcyB0aGUNICAgICByZXF1 aXJlZCBwYXJ0cyBvZiBpdHNlbGYgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCBiZWhhdmlvci4N DSAgICAgRklHVVJFIDYuIEEgQ29tcGxldGUgU05NUC1CYXNlZCBQb2xpY3kgTWFuYWdlbWVu dCBTeXN0ZW0NICAgICAtIFNlZSAucHMgdmVyc2lvbi4NDQ0NDQ0NU2FwZXJpYSAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAyNl0NDA1JbnRl cm5ldCBEcmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwg MjAwMA0NNS4zLjEuICBCdXQgQ2FuIEkgZG8gU2ltcGxlIENvbmZpZ3VyYXRpb24/DQ1UaGUg TUlCIE1vZHVsZXMgZGVzY3JpYmVkIGRvIG5vdCBpbiBhbnkgd2F5IGludGVyZmVyZSB3aXRo DWJhc2ljLCBzaW1wbGUgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIHRoYXQgcGVvcGxlIG1h eSB3YW50IHRvDXBlcmZvcm0uIFRyYWRpdGlvbmFsIGluc3RhbmNlIGJhc2VkIGNvbmZpZ3Vy YXRpb24gb3BlcmF0aW9ucw1jYW4gY29udGludWUgdG8gYmUgdXNlZCBpbiBjb21iaW5hdGlv biB3aXRoIHRoZSBtb3JlIHBvd2VyZnVsDXBvbGljeS1iYXNlZCBjb25maWd1cmF0aW9uIG9w ZXJhdGlvbnMuDQ0NNi4gIENvbmNsdXNpb24NDVRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBm cmFtZXdvcmsgZm9yIHBvbGljeS1iYXNlZA1jb25maWd1cmF0aW9uIHdpdGggU05NUCBhbmQg YW4gaW50cm9kdWN0aW9uIHRvIGNvbW1vbiB0ZXJtcw11c2VkIGluIHRoYXQgZnJhbWV3b3Jr LiBUaGUgU05NUCBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXANaGFzIG5vdCB5ZXQgY29t cGxldGVkIGl0cyBpbml0aWFsIHdvcmsgdGhvdWdoIHN1YnN0YW50aWFsDXByb2dyZXNzIGhh cyBiZWVuIG1hZGUgb24gYWxsIG9mIHRoZSBkb2N1bWVudHMgaXQgaXMgd29ya2luZw1vbi4g SXQgaXMgbm93IGNsZWFyIHRoYXQgd2l0aCBqdXN0IGEgZmV3IE1JQiBPYmplY3RzLCBpdCBp cw1wb3NzaWJsZSB0byBjcmVhdGUgYSBwb3dlcmZ1bCwgZWZmaWNpZW50IGFuZCBpbnRlZ3Jh dGVkIHBvbGljeQ1tYW5hZ2VtZW50IHN5c3RlbSB1c2luZyB0aGUgSW50ZXJuZXQgU3RhbmRh cmQgTWFuYWdlbWVudA1GcmFtZXdvcmsuIEl0IGlzIGFsc28gY2xlYXIgdGhhdCB0aGlzIGFw cHJvYWNoIHRvIHBvbGljeSBiYXNlZA1tYW5hZ2VtZW50IG1hcHMgd2VsbCB0byB0aGUgd29y ayB1bmRlcnRha2VuIGluIHRoZSBQb2xpY3kNRnJhbWV3b3JrIFdvcmtpbmcgR3JvdXAuDQ0N Ny4gIEFja25vd2xlZGdtZW50cw0NTWFueSBpZGVhcyBpbiB0aGlzIHBhcGVyIGhhdmUgYmVl biBpbmZvcm1lZCBieSBjb252ZXJzYXRpb25zDXdpdGggYW5kIGNvbW1lbnRzIGJ5IG15IGNv bGxlZ2VzLiBJIHdvdWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UNdGhlaXIgY29udHJpYnV0aW9u IHRvIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHByb2JsZW0uIEEgZmV3DWluZGl2aWR1YWxz IHRoYXQgaGF2ZSBtYWRlIHNwZWNpYWwgY29udHJpYnV0aW9ucyBJIHdvdWxkIGxpa2UNdG8g YWNrbm93bGVkZ2U6IEFuZHkgQmllcm1hbiwgSmVmZiBDYXNlLCBKb2VsIEhhbHBlcm4sIEJv Yg1RdWlubiwgSm9obiBTY2huaXpsZWluLCBKb2huIFN0cmFzc25lciwgU3RldmUgV2FsZGJ1 c3NlciwNV2FsdGVyIFdlaXNzLCBhbmQgdGhlIG90aGVyIG1lbWJlcnMgb2YgdGhlIGVkaXRp bmcgdGVhbSB0aGF0DWhhdmUgY29udHJpYnV0ZWQgdG8gdGhlIFNOTVAgQ29uZmlndXJhdGlv biBkb2N1bWVudHMsIEhhcnJpZQ1IYXpld2lua2VsLCBUaGlwcGFubmEgSG9uZ2FsLCBNaWtl IE1hY0ZhZGVuLCBhbmQgRGF2aWQNUGFydGFpbi4gU29tZSBpbmRpdmlkdWFscyBoYXZlIGFs c28gcHJvdmlkZWQgZmVlZGJhY2sgb24NbnVtZXJvdXMgcmV2aXNpb25zIG9mIHRoaXMgZG9j dW1lbnQuIEkgd291bGQgYWxzbyBsaWtlIHRvDXRoYW5rIHRoZSBTTk1QQ09ORiBjby1jaGFp ciwgRGF2aWQgSGFycmluZ3RvbiwgZm9yIGhpcw1kZXRhaWxlZCBlZGl0b3JpYWwgcmV2aWV3 IG9mIHNldmVyYWwgZHJhZnRzIG9mIHRoaXMgZG9jdW1lbnQuDQ0NOC4gIEdlbmVyYWwgUmVm ZXJlbmNlcyB0byBXZWIgUGFnZXMNDUhlcmUgaXMgYSBsaXN0IG9mIFVSTHMgdG8gdGhlIHZh cmlvdXMgZG9jdW1lbnRzIG9yIHdvcmtpbmcNZ3JvdXBzIHRoYXQgbWF5IGJlIG9mIGludGVy ZXN0IHJlZmVyZW5jZWQgaW4gdGhpcyBwYXBlci4gVGhlDQ0NDQ0NU2FwZXJpYSAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSA2dGggMjAwMSAgICAgICAgICBbUGFnZSAyN10NDA1JbnRl cm5ldCBEcmFmdCAgUG9saWN5IENvbmZpZ3VyYXRpb24gd2l0aCBTTk1QICAgIEp1bHkgNiwg MjAwMA0Nd29ya2luZyBncm91cCBwYWdlcyBjb250YWluIHNvbWUgb2YgdGhlIHN1bW1hcnkg aW5mb3JtYXRpb24NdXNlZCBpbiB0aGlzIGRvY3VtZW50IGFzIHdlbGwgYXMgcG9pbnRlcnMg dG8gcmVsZXZhbnQgSURzIGFzDXdlbGwgYXMgbWFueSBvZiB0aGUgUkZDcyB0aGF0IGFyZSBv ZiBpbnRlcmVzdC4NW1NOTVBDT05GXQ0NQ29uZmlndXJhdGlvbiBNYW5hZ2VtZW50IHdpdGgg U05NUCAoc25tcGNvbmYpOg0NICAgICBodHRwOi8vd3d3LmlldGYub3JnL2h0bWwuY2hhcnRl cnMvc25tcGNvbmYtY2hhcnRlci5odG1sDQ1bUE9MSUNZXQ0NUG9saWN5IEZyYW1ld29yayAo cG9saWN5KToNDSAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL3BvbGlj eS1jaGFydGVyLmh0bWwNDVtSQVBdDQ1SZXNvdXJjZSBBbGxvY2F0aW9uIFByb3RvY29sIChy YXApOg0NICAgICBodHRwOi8vd3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvcmFwLWNoYXJ0 ZXIuaHRtbA0NW1NOTVBdDQ1TTk1QIFZlcnNpb24gMyAoc25tcHYzKQ0NICAgICBodHRwOi8v d3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvc25tcHYzLWNoYXJ0ZXIuaHRtbA0NW0RJRkZT RVJWXQ0NRGlmZmVyZW50aWF0ZWQgU2VydmljZXMgKGRpZmZzZXJ2KQ0NICAgICBodHRwOi8v d3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvZGlmZnNlcnYtY2hhcnRlci5odG1sDQ1bSVBT RUNdDQ1JUCBTZWN1cml0eSBQcm90b2NvbCAoaXBzZWMpDQ0gICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaHRtbC5jaGFydGVycy9pcHNlYy1jaGFydGVyLmh0bWwNDVtJTlRTRVJWXQ0NSW50 ZWdyYXRlZCBTZXJ2aWNlcyAoaW50c2VydikNDSAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9o dG1sLmNoYXJ0ZXJzL2ludHNlcnYtY2hhcnRlci5odG1sDQ0NDQ1TYXBlcmlhICAgICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdlIDI4XQ0MDUludGVy bmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVseSA2LCAy MDAwDQ0NW0JHUCBNSUJdDQ0gICAgIGZ0cDovL2Z0cC5pc2kuZWR1L2luLW5vdGVzL3JmYzE2 NTcudHh0DQ1bU0NIRURdDQ1EZWZpbml0aW9ucyBvZiBNYW5hZ2VkIE9iamVjdHMgZm9yIFNj aGVkdWxpbmcgTWFuYWdlbWVudCBPcGVyYXRpb25zDQ0gICAgIGZ0cDovL2Z0cC5pc2kuZWR1 L2luLW5vdGVzL3JmYzI1OTEudHh0DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAg ICAgICAgIFtQYWdlIDI5XQ0MDUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlv biB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NOS4gIFJlZmVyZW5jZXMNDVsxXSAgSGFy cmluZ3RvbiwgRC4sIFByZXN1aG4sIFIuLCBhbmQgQi4gV2lqbmVuLCAiQW4NICAgICBBcmNo aXRlY3R1cmUgZm9yIERlc2NyaWJpbmcgU05NUCBNYW5hZ2VtZW50IEZyYW1ld29ya3MiLA0g ICAgIFJGQyAyNTcxLCBBcHJpbCAxOTk5Lg0NWzJdICBSb3NlLCBNLiwgYW5kIEsuIE1jQ2xv Z2hyaWUsICJDb25jaXNlIE1JQiBEZWZpbml0aW9ucyIsDSAgICAgU1REIDE2LCBSRkMgMTIx MiwgTWFyY2ggMTk5MS4NDVszXSAgUm9zZSwgTS4sICJBIENvbnZlbnRpb24gZm9yIERlZmlu aW5nIFRyYXBzIGZvciB1c2Ugd2l0aA0gICAgIHRoZSBTTk1QIiwgUkZDIDEyMTUsIE1hcmNo IDE5OTEuDQ1bNF0gIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRl ciwgSi4sIENhc2UsIEouLA0gICAgIFJvc2UsIE0uLCBhbmQgUy4gV2FsZGJ1c3NlciwgIlN0 cnVjdHVyZSBvZiBNYW5hZ2VtZW50DSAgICAgSW5mb3JtYXRpb24gVmVyc2lvbiAyIChTTUl2 MikiLCBTVEQgNTgsIFJGQyAyNTc4LCBBcHJpbA0gICAgIDE5OTkuDQ1bNV0gIE1jQ2xvZ2hy aWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENhc2UsIEouLA0gICAg IFJvc2UsIE0uLCBhbmQgUy4gV2FsZGJ1c3NlciwgIlRleHR1YWwgQ29udmVudGlvbnMgZm9y DSAgICAgU01JdjIiLCBTVEQgNTgsIFJGQyAyNTc5LCBBcHJpbCAxOTk5Lg0NWzZdICBDYXNl LCBKLiwgSGFycmluZ3RvbiBELiwgUHJlc3VobiBSLiwgYW5kIEIuIFdpam5lbiwNICAgICAi TWVzc2FnZSBQcm9jZXNzaW5nIGFuZCBEaXNwYXRjaGluZyBmb3IgdGhlIFNpbXBsZQ0gICAg IE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbCAoU05NUCkiLCBSRkMgMjU3MiwgQXByaWwN ICAgICAxOTk5Lg0NWzddICBCbHVtZW50aGFsLCBVLiwgYW5kIEIuIFdpam5lbiwgIlVzZXIt YmFzZWQgU2VjdXJpdHkgTW9kZWwNICAgICAoVVNNKSBmb3IgdmVyc2lvbiAzIG9mIHRoZSBT aW1wbGUgTmV0d29yayBNYW5hZ2VtZW50DSAgICAgUHJvdG9jb2wgKFNOTVB2MykiLCBSRkMg MjU3NCwgQXByaWwgMTk5OS4NDVsxOF0gQ2FzZSwgSi4sIE1jQ2xvZ2hyaWUsIEsuLCBSb3Nl LCBNLiwgYW5kIFMuIFdhbGRidXNzZXIsDSAgICAgIlByb3RvY29sIE9wZXJhdGlvbnMgZm9y IFZlcnNpb24gMiBvZiB0aGUgU2ltcGxlIE5ldHdvcmsNICAgICBNYW5hZ2VtZW50IFByb3Rv Y29sIChTTk1QdjIpIiwgUkZDIDE5MDUsIEphbnVhcnkgMTk5Ni4NDVs5XSAgTGV2aSwgRC4s IE1leWVyLCBQLiwgYW5kIEIuIFN0ZXdhcnQsICJTTk1QdjMNICAgICBBcHBsaWNhdGlvbnMi LCBSRkMgMjU3MywgQXByaWwgMTk5OS4NDVsxMF0gV2lqbmVuLCBCLiwgUHJlc3VobiwgUi4s IGFuZCBLLiBNY0Nsb2docmllLCAiVmlldy1iYXNlZA0gICAgIEFjY2VzcyBDb250cm9sIE1v ZGVsIChWQUNNKSBmb3IgdGhlIFNpbXBsZSBOZXR3b3JrDSAgICAgTWFuYWdlbWVudCBQcm90 b2NvbCAoU05NUCkiLCBSRkMgMjU3NSwgQXByaWwgMTk5OS4NDVsxMV0gQ2FzZSwgSi4sIE11 bmR5LCBSLiwgUGFydGFpbiwgRC4sIGFuZCBCLiBTdGV3YXJ0LA0gICAgICJJbnRyb2R1Y3Rp b24gdG8gVmVyc2lvbiAzIG9mIHRoZSBJbnRlcm5ldC1zdGFuZGFyZA0gICAgIE5ldHdvcmsg TWFuYWdlbWVudCBGcmFtZXdvcmsiLCBSRkMgMjU3MCwgQXByaWwgMTk5OS4NDQ0NDQ1TYXBl cmlhICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdl IDMwXQ0MDUludGVybmV0IERyYWZ0ICBQb2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAg ICAgSnVseSA2LCAyMDAwDQ0xMC4gIEludGVsbGVjdHVhbCBQcm9wZXJ0eQ0NVGhlIElFVEYg dGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZg1h bnkgaW50ZWxsZWN0dWFsIHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJl DWNsYWltZWQgdG8gIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0 aGUNdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50 IHRvIHdoaWNoDWFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzIG1pZ2h0IG9yIG1pZ2h0 IG5vdCBiZSBhdmFpbGFibGU7DW5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBo YXMgbWFkZSBhbnkgZWZmb3J0IHRvDWlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9y bWF0aW9uIG9uIHRoZSBJRVRGJ3MNcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRz IGluIHN0YW5kYXJkcy10cmFjayBhbmQNc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlv biBjYW4gYmUgZm91bmQgaW4gQkNQLTExLg1Db3BpZXMgb2YgY2xhaW1zIG9mIHJpZ2h0cyBt YWRlIGF2YWlsYWJsZSBmb3IgcHVibGljYXRpb24gYW5kDWFueSBhc3N1cmFuY2VzIG9mIGxp Y2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0DW9mIGFuIGF0dGVt cHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbg1mb3Ig dGhlIHVzZSBvZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRvcnMgb3IN dXNlcnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJ RVRGDVNlY3JldGFyaWF0Lg0NVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0 eSB0byBicmluZyB0byBpdHMNYXR0ZW50aW9uIGFueSBjb3B5cmlnaHRzLCBwYXRlbnRzIG9y IHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yDW90aGVyIHByb3ByaWV0YXJ5IHJpZ2h0cyB3aGlj aCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heQ1iZSByZXF1aXJlZCB0byBwcmFjdGlj ZSB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlDWluZm9ybWF0aW9uIHRvIHRo ZSBJRVRGIEV4ZWN1dGl2ZSBEaXJlY3Rvci4NDQ0xMS4gIEF1dGhvcnMnIEFkZHJlc3Nlcw0N DSAgICAgSm9uIFNhcGVyaWENICAgICBKRFMgQ29uc3VsdGluZw0gICAgIDE3NCBDaGFwbWFu IFN0cmVldA0gICAgIFdhdGVydG93biwgTUEgMDI0NzINICAgICBlbWFpbCAtIHNhcGVyaWFA amRzY29ucy5jb20NDQ0NMTIuICBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNDUNvcHlyaWdo dCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDApLiBBbGwgUmlnaHRzIFJlc2VydmVk Lg0NVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQg YW5kDWZ1cm5pc2hlZCB0byBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29t bWVudCBvbiBvcg1vdGhlcndpc2UgZXhwbGFpbiBpdCBvciBhc3Npc3QgaW4gaXRzIGltcGxl bWVudGF0aW9uIG1heSBiZQ1wcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIGRpc3Ry aWJ1dGVkLCBpbiB3aG9sZSBvciBpbg1wYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFu eSBraW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZQ0NDQ0NDVNhcGVyaWEgICAgICAgICAg ICBFeHBpcmVzIEphbnVhcnkgNnRoIDIwMDEgICAgICAgICAgW1BhZ2UgMzFdDQwNSW50ZXJu ZXQgRHJhZnQgIFBvbGljeSBDb25maWd1cmF0aW9uIHdpdGggU05NUCAgICBKdWx5IDYsIDIw MDANDQ1jb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQg b24gYWxsIHN1Y2gNY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhp cyBkb2N1bWVudCBpdHNlbGYNbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNo IGFzIGJ5IHJlbW92aW5nIHRoZQ1jb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8g dGhlIEludGVybmV0IFNvY2lldHkgb3INb3RoZXIgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywg ZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlDXB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5l dCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUNcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0 cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMNcHJvY2VzcyBtdXN0IGJlIGZv bGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50bw1sYW5ndWFnZXMg b3RoZXIgdGhhbiBFbmdsaXNoLg0NVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBh Ym92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsDW5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRl cm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yDWFzc2lnbnMuDQ1UaGlzIGRvY3Vt ZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZA1v biBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElO VEVSTkVUDUVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVT LCBFWFBSRVNTIE9SDUlNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFDVVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwg Tk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1INQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiBN RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQQ1QQVJUSUNVTEFSIFBVUlBPU0UuDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdlIDMyXQ0MDUludGVybmV0IERyYWZ0ICBQ b2xpY3kgQ29uZmlndXJhdGlvbiB3aXRoIFNOTVAgICAgSnVseSA2LCAyMDAwDQ0NVGFibGUg b2YgQ29udGVudHMNDV4NMSBBYnN0cmFjdCAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uICAgIDINMiBJbnRyb2R1Y3Rpb24gLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDINMyBIaXN0b3J5IGFuZCBCYWNrZ3Jv dW5kIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDQNNCBEZWZpbml0aW9u IG9mIFRlcm1zIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgIDYNNC4x IERlZmluaW5nIHRoZSBUZXJtIFBvbGljeSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u ICAgIDYNNC4xLjEgV2hhdCBpcyBhIFBvbGljeSAgYW5kICBob3cgIGRvZXMgIGl0ICByZWxh dGUgIHRvDSAgICAgQ29uZmlndXJhdGlvbj8gIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLiAgICA3DTQuMS4yICBUZXJtcyAgYW5kICBSZWxhdGlvbnNoaXAgIHRvICBQ b2xpY3kgIEZyYW1ld29yaw0gICAgIFdvcmtpbmcgR3JvdXAgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4gICAgNw00LjEuMyBMZXZlbHMgb2YgQWJzdHJhY3Rpb24g Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gICAxMQ01IFRoZSBTTk1QIENvbmZpZ3Vy YXRpb24gV29ya2luZyBHcm91cCAuLi4uLi4uLi4uLi4uLi4uLi4gICAxMw01LjEgQ2hhcnRl ciBhbmQgR29hbHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gICAxMw01 LjIgVGhlIFNOTVAgQXJjaGl0ZWN0dXJlIGFuZCBDb25maWd1cmF0aW9uIE1vZGVsIC4uLi4u Li4gICAxNA01LjIuMSBUaGUgUG9saWN5IE1JQiBNb2R1bGUgLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4gICAxNQ01LjIuMiAgTWVjaGFuaXNtICAgYW5kICAgSW1wbGVtZW50YXRp b24tU3BlY2lmaWMgICBNSUINICAgICBNb2R1bGVzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uICAgMTgNNS4yLjMgSW5zdGFuY2UtU3BlY2lmaWMgTUlC IE1vZHVsZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgMjANNS4zIFRoZSBwcm9jZXNzIG9m IENvbmZpZ3VyYXRpb24gTWFuYWdlbWVudCAuLi4uLi4uLi4uLi4uICAgMjENNS4zLjEgQnV0 IENhbiBJIGRvIFNpbXBsZSBDb25maWd1cmF0aW9uPyAgLi4uLi4uLi4uLi4uLi4uICAgMjcN NiBDb25jbHVzaW9uIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uICAgMjcNNyBBY2tub3dsZWRnbWVudHMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uICAgMjcNOCBHZW5lcmFsIFJlZmVyZW5jZXMgdG8gV2ViIFBhZ2VzIC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uICAgMjcNOSBSZWZlcmVuY2VzIC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgMzANMTAgSW50ZWxsZWN0dWFsIFBy b3BlcnR5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgMzENMTEgQXV0aG9y cycgQWRkcmVzc2VzIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAgMzEN MTIgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uICAgMzENDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1TYXBlcmlhICAgICAgICAgICAgRXhwaXJl cyBKYW51YXJ5IDZ0aCAyMDAxICAgICAgICAgIFtQYWdlIDMzXQ0MDQ== --MS_Mac_OE_3045726345_1805586_MIME_Part-- From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 11:41:36 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18985 for ; Thu, 6 Jul 2000 11:41:35 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA12548 for snmpconf-outgoing; Thu, 6 Jul 2000 11:27:29 -0400 (EDT) Date: Thu, 6 Jul 2000 11:26:56 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Fri, 23 Jun 2000, Jon Saperia wrote: > on 06/19/2000 3:07 PM, Matt White at mwhite@torrentnet.com wrote: > > > On Wed, 14 Jun 2000, Jon Saperia wrote: > > > >> PmRoleESEntry ::= SEQUENCE { > >> pmRoleESElement RowPointer, > >> pmRoleESString SnmpAdminString, > >> pmRoleESStatus RowStatus > >> } > >> > >> I propose that the pmRoleESStatus be the place for the dirty bit. If that is > >> not acceptable, another object in this table. > > > > While this would work, I think I would prefer to look at the precedence > > issue first. We may come up with a solution to that problem that lends > > itself well to solving the manual configuration problem. Or we may not, > > but I'd at least like to see where that goes before we lock ourselves into > > a solution to this problem. > > > > > > -Matt > > > > > Matt, > > can you clarify what you mean by the precedence issue please? > > Thanks > /jon Jon: Sorry for the delay, this folder was relatively low traffic so I thought I could let it sit for a week while I worked on other things...silly me. ;) By "the precedence issue", I am referring to conflict resolution. You mentioned above the idea of associating a priority with a policy, which IMHO is the right thing to do. If we do go that route, we can look at manual configuration on a box as an implicit policy, the "manual policy" if you will. The user can then assign whatever priority they want to manual policy. This provides the flexibility to say "policy foo and bar do not override manual configuration, but policy baz takes precendence always". -Matt From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 12:23:04 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19940 for ; Thu, 6 Jul 2000 12:23:04 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA13847 for snmpconf-outgoing; Thu, 6 Jul 2000 12:02:15 -0400 (EDT) Date: Thu, 6 Jul 2000 12:01:41 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf Conflict Resolution Issues - Consensu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Yes. It is unreasonable to keep the state that this would require. Matt White Ericsson IP Infrastructure On Wed, 28 Jun 2000, Jon Saperia wrote: > on 06/24/2000 6:24 PM, Joel M. Halpern at joel@mcquillan.com wrote: > > > It is my opinion that deleting a policy should not directly cause a change > > in any attributes of any instances. It may be reasonable to expect > > (depending upon our evaluation model) that the set of policies in effect > > should be re-evaluated, which my cause some existing policy to change the > > values of some objects. Trying to perform a direct "unwinding" of a policy > > when it is deleted would, I think, be a very bad idea. > > > > Yours, > > Joel M. Halpern > > > > Folks, I believe that we have consensus on this topic even though my > original postings may not have been clear. > > The consensus is that we should not attempt to deal with this in the managed > systems at all for all the previously stated reasons. I agree. If a manager > wants to do something fancy when deleting a policy that is outside the scope > of the current work. > > All agreed? > > /jon > From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 12:50:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20767 for ; Thu, 6 Jul 2000 12:50:57 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA14185 for snmpconf-outgoing; Thu, 6 Jul 2000 12:13:40 -0400 (EDT) Date: Thu, 6 Jul 2000 12:13:08 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Attendance In-Reply-To: <200007061334.JAA08300@seymour39.SNMP.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I'll be at the interim as well. From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 14:46:11 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23078 for ; Thu, 6 Jul 2000 14:46:11 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id OAA18425 for snmpconf-outgoing; Thu, 6 Jul 2000 14:27:24 -0400 (EDT) Message-ID: <3964CF32.A31BAEBD@nextbeacon.com> Date: Thu, 06 Jul 2000 11:25:54 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit "Joel M. Halpern" wrote: > > If they have the access to write directly to the > variable, then they should be able to do so. They should not have to > understand the policy tables and find the correct place to markt "I mean > this" If they are making the change, they mean it. > > Fundementally, you are arguing that putting an object under policy control > should remove it from SNMP control unless it is explicitly removed from > policy control first. I am arguing that the act of directly setting the > attribute seems to me to be quite clear enough. I believe the main constituency for policy-based management is the network architect/engineer who is sick and tired of the ad-hoc nonsense that continuously creates problems. Maybe rigorous training of everybody who touches the network could solve this problem, but with staff turnover and the constant stream of vendor staff, consultants and service provider staff in and out the door, this is impossible. Policy-based management can help the network architect make everything consistent. Now you say "if they are making the change, they mean it". Well, when an entry-level technician makes an out-of-policy change, two things are true: 1. The technician meant it 2. The network architect wants to bash his brains in with a 2x4. The architect DIDN'T MEAN IT. Thus, there are 2 constituencies. One is tactically focused and one is strategically focused. The tactical constituency is the only one that has been represented so far WRT SNMP configuration. We are here to provide a tool for the strategic constituency that lets them enforce the strategic goals. We can't let ad-hoc SETs always win or we haven't provided any enforcement capability. So far I've only been talking about the case where the technician "meant it". What about the case where nobody meant it?: - I made a mistake - I didn't know what I was doing - I ran an old script, I didn't realise what it did. ... > 2) If you require people to explicitly mark that they want to override > policy, they will forget. They will be surprised and confused when the > system does things that they do not expect. This is better than having the network architect be surprised and confused. Yes, sometimes they will forget. They will have to learn. (An aside: it would be great if we could figure out how to give them more instant feedback without requiring changes to existing SNMP instrumentation). Sometimes the architect and the tech mean different things. Sometimes the architect is wrong and sometimes the tech is wrong. We can't assume that either is always right. The middle ground is to require that the tech take special action for those things under policy control - to acknowledge that what they are about to do is a conscious decision to violate the policy. No more unreasonable than "Delete all files. Are you sure?" Steve From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 14:46:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23102 for ; Thu, 6 Jul 2000 14:46:56 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA18472 for snmpconf-outgoing; Thu, 6 Jul 2000 14:28:40 -0400 (EDT) Date: Thu, 06 Jul 2000 11:22:51 -0700 From: Andrew Smith Subject: Re: snmpconf Pointers from Policy MIB -> implementation-specific MIB To: snmpconf@snmp.com, David Partain Message-id: <3964CE7B.B86868B7@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en] (WinNT; I) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <200006290729.JAA28621@lmera.lmera.ericsson.se> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8BIT David, I'm a bit worried about the scalability of this approach, but maybe I'm misunderstanding something about the proposal: are you saying that the "manager" would create all the rows in this table, one row for every low-level object instance that is affected by a high-level policy? That could be literally thousands of entries per-device for a single high-level rule. Alternatively, if the device creates them automagically, wouldn't some more interesting indexing be better, rather than having to plough through a flat list? (It's not clear from your MIB-fragment which you intended). But I'm still not clear on all the downsides to strategy (1). To me, if you (the manager) know which high-level rules map to which low-level MIBs/table then there is no problem to go to that MIB (or to a MIB that AUGMENTs tables in that low-level MIB) to debug it. You're going to have to know about the different indexing requirements of the low-level tables anyhow, in order to make sense of the results so I'm not convinced that the centralised approach can be used to make any sort of useful generic "policy debugger" tool. Andrew David Partain wrote: > > Greetings, > > While speaking with Jon and Harrie, we talked about the need > to have a way to "debug" policies. Basically, there needs to > be something showing the relationship between a policy in the > policy MIB and its instantiation "lower" down. > > We want this so that there is a way of correlating policies > with things that are broken. If you don't who's implementing > a policy or the parameters that cause the change you want > (or the change you _didn't_ want), you cannot debug it. > > Different strategies are possible. Three are: > > - pointers from the "lower" MIBs (implementation-specific) > into the policy MIB > > - shared indices between the policy MIB and the > implementation-specific MIBs > > - pointers from the policy MIB into the implementation-specific > MIBs > > This was discussed at the last interim meeting, and the best > approach appears to be the last of them. It allows the most > flexibility with respect to how many places to point to (which #2 > doesn't), while avoiding the problems that are associated with > #1. > > So, we propose that something along the lines of the objects > below be added to the policyMgt MIB in > draft-ietf-snmpconf-pm-??.txt. The arguments for this are: > > 1) If we don't put the relationship pointers in a central > place we have to spread them all over (if we're going to > have the information available). Thus, putting them in > the POLICY-MANAGEMENT-MIB avoids defining them in each > implementation-specific MIB. > > 2) From an implementation-specific MIB module it is not > possible to know all relationships of applied policies. The > other way around is that when a policy is applied, the > management station should already select which > implementation-specific or instance-specific objects > are applicable. > > 3) Having the relationships in a central place makes them > useful for debugging policies. For instance, if multiple > pointers from everywhere pointing to a policy in the Policy > MIB module you could have well overlooked 1 relationship. > > We're obviously not attached to any names. If someone has a > better way of solving this problem, those ideas are greatly > appreciated. > > pmPolicyMechanismTable OBJECT-TYPE > SYNTAX SEQUENCE OF PmPolicyMechanismEntry > STATUS current > DESCRIPTION > "This table is used to show the relationships > from policies to mechanism specific policy definitions." > ::= policyMgt xx } > > -- uses a shared index with the pmPolicyTable > pmPolicyMechanismEntry OBJECT-TYPE > SYNTAX PmPolicyMechanismEntry > STATUS current > DESCRIPTION > "An row of the pmPolicyMechanismTable." > INDEX { pmPolicyIndex, pmPolicyMechanismIndex } > ::= pmPolicyMechanismTable 1 } > > PmPolicyMechanismEntry SEQUENCE ::= > pmPolicyMechanismIndex Unsigned32, > pmPolicyMechanismPointer RowPointer > } > > pmPolicyMechanismIndex OBJECT-TYPE > SYNTAX INTEGER (1..2147483647) > STATUS current > DESCRIPTION > "A unique index for the mechanism pointers." > ::= pmPolicyMechanismEntry 1 } > > pmPolicyMechanismPointer OBJECT-TYPE > SYNTAX RowPointer > STATUS current > DESCRIPTION > "A row pointer that connects a policy instantiated at > 'pmPolicyIndex' to mechanism specific." > ::= pmPolicyMechanismEntry 1 } > > Your comments are welcome. > > With kind regards, > > -- > David Partain David.Partain@ericsson.com > Ericsson Radio Systems AB Tel: +46 13 28 41 44 > Research and Innovation Fax: +46 13 28 75 67 > P.O. Box 1248 > SE-581 12 Linköping, Sweden From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 14:55:09 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23285 for ; Thu, 6 Jul 2000 14:55:09 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA18859 for snmpconf-outgoing; Thu, 6 Jul 2000 14:37:54 -0400 (EDT) Message-ID: <3964D1AD.F882117B@nextbeacon.com> Date: Thu, 06 Jul 2000 11:36:29 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Attendance References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit I plan on attending. Steve From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 15:02:26 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23492 for ; Thu, 6 Jul 2000 15:02:25 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA19083 for snmpconf-outgoing; Thu, 6 Jul 2000 14:45:13 -0400 (EDT) Message-ID: <3964D367.9DD61A0A@nextbeacon.com> Date: Thu, 06 Jul 2000 11:43:51 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit "Joel M. Halpern" wrote: > You raise the red herring of "then why reevaluate policy". The answer is > that there are many ways that reality can change, not just by changing an > SNMP variable. Some of these are equivalent to such sets (CLI is I agree > still manual change). But cards fail. VCs come up. peerings start and > stop. Cards get inserted and removed. These things may have effects on the > policy decision. But early in this discussion it was proposed that the way the policy engine learns that a variable has been modified is by comparing with the policy value and when it notices that it is different, marking it as "don't touch". This was so that we didn't require changes to existing SNMP instrumentation. Thus the policy engine has no way to differentiate between changes due to SNMP, CLI, or simply state changes on the managed system - the net effect is that any change from any source locks policy out from fixing the change. Steve From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 16:06:49 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24541 for ; Thu, 6 Jul 2000 16:06:49 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA21096 for snmpconf-outgoing; Thu, 6 Jul 2000 15:49:57 -0400 (EDT) Message-Id: <4.2.2.20000706154322.00a94100@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jul 2000 15:47:31 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions In-Reply-To: <3964D367.9DD61A0A@nextbeacon.com> References: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I had overlooked that (background change detection) proposal. That would indeed produce the results you propose. And was not what I was expecting. I had assumed that one would indeed modify some internal mechanisms so taht if a change was being made to a variable which had been modified by policy, that the "don't touch" flag would get set. I would observe that even if that were the case, one would still have policy effect on new things, and policy effect when collatoral conditionals were changed. Yours, Joel M. Halpern Also, to respond to the note expressing concern about the interaction between the Network Architect and the Field Engineer, if the systems folks have decided that the field engineer should not be able to change certain things, don't given that engineer permission to change them. In my discussions with ISPs they have confirmed that it is normal and desirable for field engineers to change things, and that preventing them from doing so would be a bad thing. At 11:43 AM 7/6/00 -0700, Steve Waldbusser wrote: >But early in this discussion it was proposed that the way the policy engine >learns that a variable has been modified is by comparing with the policy >value and when it notices that it is different, marking it as "don't >touch". From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 16:35:10 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25107 for ; Thu, 6 Jul 2000 16:35:09 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA22255 for snmpconf-outgoing; Thu, 6 Jul 2000 16:19:25 -0400 (EDT) Message-ID: <15F58915DF84D311AC7D0090279AA614233960@ITC-EML2> From: Dan Romascanu To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Interim Meeting Attendance Date: Thu, 6 Jul 2000 23:16:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I will attend. Regards, Dan > -----Original Message----- > From: Jon Saperia [SMTP:saperia@mediaone.net] > Sent: Thu July 06 2000 12:19 > To: snmpconf > Subject: snmpconf Interim Meeting Attendance > > Folks, > > As you know David H is working on the interim meeting arrangements. Bert > suggested the other day that it might be helpful if people were to say if > they planned on attending as it might help with space planning for the > interim meeting room. This is similar to what I had done for our SFO > interim. > > If you plan on attending, please post a note so David can capture that > information. > > Thanks > /jon > > P.S. - I plan on attending. > From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 17:39:23 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26274 for ; Thu, 6 Jul 2000 17:39:23 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA23942 for snmpconf-outgoing; Thu, 6 Jul 2000 17:24:45 -0400 (EDT) Message-ID: <3964F8CC.3DC04A0B@nextbeacon.com> Date: Thu, 06 Jul 2000 14:23:24 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> <4.2.2.20000706154322.00a94100@omniplex.mcquillan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit I'm not suggesting that the field engineer be prevented from making changes. In fact, I was the original proposer for an override capability as well as operational/debugging tools for field engineers - they are all in the draft today. All I want is for the field engineer to have to do something special to override a policy. Shouldn't he at least know that he has done something significant? Wouldn't it be good if he was thus encouraged to think twice? Wouldn't it be good if he was encouraged to mention it to the network architect? ("hey, I needed to disable the blah policy on trunk 7 last night because it was interacting poorly with the backup circuit"). My proposal is that he issue 2 commands rather than one. The first disables the policy on the interface and the second is a normal SNMP set that makes the change. Regards, Steve "Joel M. Halpern" wrote: > > I had overlooked that (background change detection) proposal. That would > indeed produce the results you propose. And was not what I was > expecting. I had assumed that one would indeed modify some internal > mechanisms so taht if a change was being made to a variable which had been > modified by policy, that the "don't touch" flag would get set. > > I would observe that even if that were the case, one would still have > policy effect on new things, and policy effect when collatoral conditionals > were changed. > > Yours, > Joel M. Halpern > > Also, to respond to the note expressing concern about the interaction > between the Network Architect and the Field Engineer, if the systems folks > have decided that the field engineer should not be able to change certain > things, don't given that engineer permission to change them. In my > discussions with ISPs they have confirmed that it is normal and desirable > for field engineers to change things, and that preventing them from doing > so would be a bad thing. > > At 11:43 AM 7/6/00 -0700, Steve Waldbusser wrote: > >But early in this discussion it was proposed that the way the policy engine > >learns that a variable has been modified is by comparing with the policy > >value and when it notices that it is different, marking it as "don't > >touch". From owner-snmpconf@seymour39.SNMP.COM Thu Jul 6 19:18:36 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27343 for ; Thu, 6 Jul 2000 19:18:36 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA26020 for snmpconf-outgoing; Thu, 6 Jul 2000 18:58:01 -0400 (EDT) Message-ID: <3964F53E.10FFE4AE@riverstonenet.com> Date: Thu, 06 Jul 2000 16:08:14 -0500 From: Thippanna Hongal Organization: Riverstone Network Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: snmpconf Subject: snmpconf Interim Meeting Attendance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit I am attending. -- thanks hongal From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 07:08:41 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20348 for ; Fri, 7 Jul 2000 07:08:40 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA17334 for snmpconf-outgoing; Fri, 7 Jul 2000 06:52:04 -0400 (EDT) Message-Id: <200007071051.GAA19885@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-diffpolicy-02.txt Date: Fri, 07 Jul 2000 06:51:29 -0400 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : The DiffServ Policy MIB Author(s) : H. Hazewinkel, D. Partain Filename : draft-ietf-snmpconf-diffpolicy-02.txt Pages : 33 Date : 06-Jul-00 The MIB Module described in this document provides a conceptual layer between high-level 'network-wide' policy definitions that affect configuration of the differentiated services (DiffServ) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring DiffServ at a conceptually higher layer than that of the DiffServ Architecture MIB [DSARCHMIB]. This version of this memo is aligned with the DIFF-SERV-MIB [DIFFSERVMIB] found in draft-ietf-diffserv-mib-03.txt. This MIB module will be aligned with that work as updates are made. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-diffpolicy-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-diffpolicy-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000706151800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-diffpolicy-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-diffpolicy-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706151800.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 09:23:43 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25222 for ; Fri, 7 Jul 2000 09:23:42 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA19950 for snmpconf-outgoing; Fri, 7 Jul 2000 09:07:17 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 07 Jul 2000 09:07:25 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <4.2.2.20000706154322.00a94100@omniplex.mcquillan.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/06/2000 3:47 PM, Joel M. Halpern at joel@mcquillan.com wrote: > I had overlooked that (background change detection) proposal. That would > indeed produce the results you propose. And was not what I was > expecting. I had assumed that one would indeed modify some internal > mechanisms so that if a change was being made to a variable which had been > modified by policy, that the "don't touch" flag would get set. Yes. The modification of the internal mechanisms to which you refer, does not imply that one would need to modify the low level instrumentation as Steve suggests. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 09:23:49 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25233 for ; Fri, 7 Jul 2000 09:23:48 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA19932 for snmpconf-outgoing; Fri, 7 Jul 2000 09:07:01 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 07 Jul 2000 09:07:09 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <3964F8CC.3DC04A0B@nextbeacon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/06/2000 5:23 PM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > All I want is for the field engineer to have to do something special > to override a policy. Shouldn't he at least know that he has done > something significant? Wouldn't it be good if he was thus encouraged > to think twice? Wouldn't it be good if he was encouraged to mention it > to the network architect? ("hey, I needed to disable the blah policy > on trunk 7 last night because it was interacting poorly with the > backup circuit"). > > My proposal is that he issue 2 commands rather than one. The first > disables the policy on the interface and the second is a normal > SNMP set that makes the change. Steve, I am in agreement with your concern. I think we can accomplish this without having to issue two commands though. You gave the example of not running as 'root' to avoid making mistakes - most of us have learned that lesson. My point is that the access/change of policy is an operational policy (forgive the pun) decision. If a system is under policy control, access to the MIB tree that contains everything except the policy objects, should be quite restricted. The operator would then have to use the root password to make the changes. This is analogous to 'su root' make all your changes and exit. Your preference would be to have the person 'sudo change 1', 'sudo change2' etc. In our case the equivalent of the sudo is to make the explicit something special you suggest. I do not think either of the two approach we discuss is very bad since they do allow for policy override, which is my primary concern. I think Joel said it pretty well: > If they have the access to write directly to the variable, then they should be > able to do so. They should not have to understand the policy tables and find > the correct place to markt "I mean this" If they are making the change, they > mean it. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 09:23:59 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25245 for ; Fri, 7 Jul 2000 09:23:58 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA20003 for snmpconf-outgoing; Fri, 7 Jul 2000 09:07:57 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 07 Jul 2000 09:08:05 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <3964CF32.A31BAEBD@nextbeacon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/06/2000 2:25 PM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > Sometimes the architect and the tech mean different things. Sometimes the > architect is wrong and sometimes the tech is wrong. We can't assume that > either is always right. The middle ground is to require that the tech take > special action for those things under policy control - to acknowledge that > what they are about to do is a conscious decision to violate the policy. > > No more unreasonable than "Delete all files. Are you sure?" My experience suggests that the concern that people have about inconsistent policies that Steve is concerned with is valid. That does not outweigh the valid concern that people have that they are able to make modifications to 'standard' policies for any reason any of us can think of and probably more that we can not think of. If a particular environment does not want to allow these modifications then we have the mechanisms in the infrastructure to let the people who deploy the system decide who can change what where. I believe we must support the ability for users who have been authorized (regardless of job title) to modify elements that are under policy control and for the policy system to reflect this state. Lets put the modified(3) value in. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 09:24:05 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25263 for ; Fri, 7 Jul 2000 09:24:04 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA19992 for snmpconf-outgoing; Fri, 7 Jul 2000 09:07:52 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 07 Jul 2000 09:08:00 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/06/2000 11:26 AM, Matt White at mwhite@torrentnet.com wrote: > By "the precedence issue", I am referring to conflict resolution. You > mentioned above the idea of associating a priority with a policy, which > IMHO is the right thing to do. If we do go that route, we can look at > manual configuration on a box as an implicit policy, the "manual policy" > if you will. The user can then assign whatever priority they want to > manual policy. This provides the flexibility to say "policy foo and bar > do not override manual configuration, but policy baz takes precendence > always". Matt this is an interesting idea but seems a bit complicated to me. I think in effect what I and others have said is that a manual change always is highest priority and overrides other parameters - perhaps a simpler version of what you suggest. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 09:24:18 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25274 for ; Fri, 7 Jul 2000 09:24:16 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA19976 for snmpconf-outgoing; Fri, 7 Jul 2000 09:07:39 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 07 Jul 2000 09:07:46 -0400 Subject: Re: snmpconf Pointers from Policy MIB -> implementation-specific MIB From: Jon Saperia To: , David Partain Message-ID: In-Reply-To: <3964CE7B.B86868B7@pacbell.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/06/2000 2:22 PM, Andrew Smith at ah_smith@pacbell.net wrote: > David, > > I'm a bit worried about the scalability of this approach, but maybe I'm > misunderstanding something about the proposal: are you saying that the > "manager" would create all the rows in this table, one row for every low-level > object instance that is affected by a high-level policy? That could be > literally thousands of entries per-device for a single high-level rule. > Alternatively, if the device creates them automagically, wouldn't some more > interesting indexing be better, rather than having to plough through a flat > list? (It's not clear from your MIB-fragment which you intended). > Andrew, David P. is on holiday so he may not be able to respond quickly. It is definitely not the case that there would be a row in the table David described for every object instance. The pointer that is referred to in the proposed addition to the Policy MIB Module is a row pointer to the mechanism and implementation specific MIB Modules. In the case of the DiffServ MIB Module that David and Harrie are working on. > But I'm still not clear on all the downsides to strategy (1). To me, if you > (the manager) know which high-level rules map to which low-level MIBs/table > then there is no problem to go to that MIB (or to a MIB that AUGMENTs tables > in that low-level MIB) to debug it. You're going to have to know about the > different indexing requirements of the low-level tables anyhow, in order to > make sense of the results so I'm not convinced that the centralised approach > can be used to make any sort of useful generic "policy debugger" tool. > I am not sure that this has been presented with enough background to be clear yet. I believe what was intended is: Policy Module | | PolicyTable Proposed Table of 2 objects AUGMENTS Policy Table | |-PolicyEntry.1-->pmPolicyMechanismIndex,pmPolicyMechanismPointer |-PolicyEntry.2-->pmPolicyMechanismIndex,pmPolicyMechanismPointer In the case of the work in David and Harries module, the pmPolicyMechanismPointer would be a RowPointer to an entry in the diffPolicyPHBTable. It contains a diffPolicyPHBId Object that is the index to the table. This table would allow pointing to multiple mechanism and implementation specific tables for a single policy. It would also allow an entry in the diffPolicyPHBTable to be referenced by many policies. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 13:16:50 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05143 for ; Fri, 7 Jul 2000 13:16:49 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA27034 for snmpconf-outgoing; Fri, 7 Jul 2000 12:57:54 -0400 (EDT) Date: Fri, 7 Jul 2000 12:57:21 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon: As you say, the dirty bit that we talked about previously is functionally equivelant to locking the priority of manual configuration at the highest level. As to whether allowing this priority level to change is complicated or not really depends on how we deal with conflicting policies. In my mind however, there will always be the "manual configuration/firefighting" policy which may conflict with other policies on the device. For this reason, I think it might be worthwhile to decide how we're going to deal with conflicting policies. How to deal with manual configuration may fall out of how we deal with conflicting policies. At the very least, we may get some ideas from that discussion. -Matt Matt White Ericsson IP Infrastructure On Fri, 7 Jul 2000, Jon Saperia wrote: > on 07/06/2000 11:26 AM, Matt White at mwhite@torrentnet.com wrote: > > > By "the precedence issue", I am referring to conflict resolution. You > > mentioned above the idea of associating a priority with a policy, which > > IMHO is the right thing to do. If we do go that route, we can look at > > manual configuration on a box as an implicit policy, the "manual policy" > > if you will. The user can then assign whatever priority they want to > > manual policy. This provides the flexibility to say "policy foo and bar > > do not override manual configuration, but policy baz takes precendence > > always". > > Matt this is an interesting idea but seems a bit complicated to me. I think > in effect what I and others have said is that a manual change always is > highest priority and overrides other parameters - perhaps a simpler version > of what you suggest. > > /jon > From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 13:19:31 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05312 for ; Fri, 7 Jul 2000 13:19:30 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA27150 for snmpconf-outgoing; Fri, 7 Jul 2000 13:02:44 -0400 (EDT) Message-ID: <39660CB1.12619996@enterasys.com> Date: Fri, 07 Jul 2000 13:00:33 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: snmpconf out-of-policy indications References: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> <4.2.2.20000706154322.00a94100@omniplex.mcquillan.com> <3964F8CC.3DC04A0B@nextbeacon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, comments inline Steve Waldbusser wrote: > > All I want is for the field engineer to have to do something special > to override a policy. Shouldn't he at least know that he has done > something significant? Wouldn't it be good if he was thus encouraged > to think twice? I am wondering about a feedback loop that would make it apparent to the field engineer that a proposed change might have wide-ranging implications to policy. A management application could analyze all the conditions that might be affected by modifying a particular managed object, but this seems a heavyweight solution, and it could be difficult to synchronize between the application evaluation of the conditions, and the local evaluation of the conditions, i.e. it may be much more difficult for the application to determine affected instances. Any suggestions on how to provide feedback - upon request - to the field engineer about how many policies would be affected by changing a given managed object, so he could determine the scale of the potential impact on policy? > Wouldn't it be good if he was encouraged to mention it > to the network architect? ("hey, I needed to disable the blah policy > on trunk 7 last night because it was interacting poorly with the > backup circuit"). > Should we provide some mechanism for standardizing notifications advising of changes to objects that have been moved "out of policy"? There are two purposes - to remind the field engineer that he made a temporary change that should be reset, and to notify the architect that somebody changed a value that is subsequently affecting policy. One approach could be to define a general policy-system-wide notification control for periodically sending notifications as long as each element is out of policy (notification per element or role). The other is to provide an object associated with the "disable-this-policy" object that controls the notification frequency related to reporting this particular out-of-policy state. This would allow notifications to be sent more frequently for important policies, and less frequently or not at all for less important policy changes (although the field engineer could prevent the architect from being notified). The third is to depend on an application run by the architect to poll for all out-of-policy indicators. This may be less reliable as a reminder mechanism for the field engineer, since he'll need to remember to run the report. Is the third mechanism adequate? It certainly seems the simplest and most backwards compatible. If an engineer doesn't set the flag, and changes an object, he can affect policy until the next re-evaluation. Assuming policy would reset it before the architect checked it, the architect may never know that the engineer made such a change, and that could have security and reliability implications. A notification sent to the architect could ensure that the architect knows about the temporary policy change. Reliance on subsequent polling would not. > My proposal is that he issue 2 commands rather than one. The first > disables the policy on the interface and the second is a normal > SNMP set that makes the change. > I concur that two commands may be better than automatic flag-setting, since this would indicate intent to knowingly override. Another related comment follows this quote: > "Joel M. Halpern" wrote: > > Also, to respond to the note expressing concern about the interaction > > between the Network Architect and the Field Engineer, if the systems folks > > have decided that the field engineer should not be able to change certain > > things, don't given that engineer permission to change them. In my > > discussions with ISPs they have confirmed that it is normal and desirable > > for field engineers to change things, and that preventing them from doing > > so would be a bad thing. > > Yes, configuring access control to prevent the field engineer from changing things he shouldn't change is the first step. But even field engineers can sabotage or abuse networks. I seems that it would be a good thing to provide a standard mechanism for the architect to detect what changes had transpired that forced policy-controlled elements to an out-of-policy state. I think there may be a need for an out-of-policy-state notification (which the architect may choose to disable or filter via snmpv3) for security/auditing purposes. dbh -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 13:37:40 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06312 for ; Fri, 7 Jul 2000 13:37:39 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA27530 for snmpconf-outgoing; Fri, 7 Jul 2000 13:20:30 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 07 Jul 2000 13:20:38 -0400 Subject: Re: snmpconf General Functional Questions - Policy Groups and Priority From: Jon Saperia To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/07/2000 12:57 PM, Matt White at mwhite@torrentnet.com wrote: > For this reason, I think it might be worthwhile to decide how we're going > to deal with conflicting policies. How to deal with manual configuration > may fall out of how we deal with conflicting policies. At the very least, > we may get some ideas from that discussion. Note I changed the title a bit here since I wanted to start a new thread. Matt, I believe we did and even had consensus on the list on June 24th. Even Bert weighed in :-) The short answer is that the heavy lifting is done by the manger. Local conflict resolution has always been done to some degree. I gave the example of agents checking resources etc. Beyond that the policy system inside a managed element does not do any conflict resolution and detection. See my 7/3 posting. All of this said, I am pretty convinced that there is significant value in adding a policy group and policy priority object to the policy table. Specifically group/priority is a way of connecting/prioritizing or doing conflict resolution external to the device. If there are 10 policies on a device and three related groups of policies, then I would say that there would be three policy groups. I would also say that the policy groups should be centrally named so that there is consistency across systems. The policy priority should also be organized globally recognizing that local optimizations may be needed. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 16:25:39 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12337 for ; Fri, 7 Jul 2000 16:25:39 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA04022 for snmpconf-outgoing; Fri, 7 Jul 2000 16:09:24 -0400 (EDT) From: Jeff Case Date: Fri, 7 Jul 2000 16:09:22 -0400 (EDT) Message-Id: <200007072009.QAA17988@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Attendance Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >If you plan on attending, please post a note so David can capture that >information. i have already made my flight and hotel arrangements in order to be there regards, jdc From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 17:10:46 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13383 for ; Fri, 7 Jul 2000 17:10:45 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA06814 for snmpconf-outgoing; Fri, 7 Jul 2000 16:55:23 -0400 (EDT) Date: Fri, 7 Jul 2000 16:54:47 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions - Policy Groups and Priority In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon: Comments inline. -Matt Matt White Ericsson IP Infrastructure On Fri, 7 Jul 2000, Jon Saperia wrote: > on 07/07/2000 12:57 PM, Matt White at mwhite@torrentnet.com wrote: > > > For this reason, I think it might be worthwhile to decide how we're going > > to deal with conflicting policies. How to deal with manual configuration > > may fall out of how we deal with conflicting policies. At the very least, > > we may get some ideas from that discussion. > > Matt, I believe we did and even had consensus on the list on June 24th. Even > Bert weighed in :-) I must be missing Bert's message and perhaps a few others. My mailbox seems to indicate no real consensus on what to do when Policy A sets OID1 to X and Policy B sets OID1 to Y. The only recent message I have from Bert states that if the element gives priority to Policy B and Policy B is subsequently removed, then we should not go back and try to figure out what value OID1 had before and change back. I agree with this wholeheartedly. I also don't think that OID1 should automatically be set to the value indicated by Policy A except to note that policy deletion is probably a wizard time to re-evaluate the policies still on the device. However, we seem to be talking about keeping a table containing every instance on the device that is "under policy control" so that we know when an operator makes a modification to an instance that was otherwise set by policy. The exact nature of how that works differs depending on whether we take your path or the path suggested by Steve. I am merely asserting at this point that, if such a table is going to exist, that it would be relatively simple to include as part of it a pointer back to the policy that caused each row to be included. It would then also be a simple matter to have a priority level as part of the policy table. Then, when a policy is changing an instance, it could check to see if that instance is already under policy control and whether the policy being evaluated has a higher priority level. If yes, apply the change, if no, toss it. Actually, if you are evaluating all policies on a device, it's even simpler -- just evaluate in reverse priority order. > The short answer is that the heavy lifting is done by > the manger. Local conflict resolution has always been done to some degree. > I gave the example of agents checking resources etc. Beyond that the policy > system inside a managed element does not do any conflict resolution and > detection. See my 7/3 posting. Again, this all seems to be in regard to deleting policies and rollback of instance values. I agree. We can't do this. The best we can do is suggest that this might be a good time to re-evaluate those policies still on the device. > All of this said, I am pretty convinced that there is significant value in > adding a policy group and policy priority object to the policy table. > Specifically group/priority is a way of connecting/prioritizing or doing > conflict resolution external to the device. If there are 10 policies on a > device and three related groups of policies, then I would say that there > would be three policy groups. I would also say that the policy groups should > be centrally named so that there is consistency across systems. Agreed. Although as I mentioned above there seems to be some simple things that we *could* do on the box. Note that if we state that devices should overwrite on equal priorities, devices which cannot handle prioritizing can opt out by restricting the priority level to a single value. > The policy priority should also be organized globally recognizing that local > optimizations may be needed. An interesting point. From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 18:33:46 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14809 for ; Fri, 7 Jul 2000 18:33:45 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA09625 for snmpconf-outgoing; Fri, 7 Jul 2000 18:18:11 -0400 (EDT) From: Jeff Case Date: Fri, 7 Jul 2000 18:18:07 -0400 (EDT) Message-Id: <200007072218.SAA18868@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf out-of-policy indications Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >I think there may be a need for an out-of-policy-state notification >(which the architect may choose to disable or filter via snmpv3) for >security/auditing purposes. or use of multiple logical contexts wherein the only objects accessible in that mib view are the ones that would be altered by a given policy or policy change we need to get a greater appreciation for what multiple logical contexts can/could do for us i am not disagreeing ... this is not an either/or choice required regards, jdc From owner-snmpconf@seymour39.SNMP.COM Fri Jul 7 18:34:35 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14824 for ; Fri, 7 Jul 2000 18:34:35 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id SAA09673 for snmpconf-outgoing; Fri, 7 Jul 2000 18:19:08 -0400 (EDT) From: Jeff Case Date: Fri, 7 Jul 2000 18:19:05 -0400 (EDT) Message-Id: <200007072219.SAA18877@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions - Policy Groups and Priority Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com i think we want to be fastidious in substututing the work precedence for the word priority regards, jdc From owner-snmpconf@seymour39.SNMP.COM Sat Jul 8 10:25:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06242 for ; Sat, 8 Jul 2000 10:25:57 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA03531 for snmpconf-outgoing; Sat, 8 Jul 2000 10:11:58 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 08 Jul 2000 10:12:08 -0400 Subject: Re: snmpconf General Functional Questions - Policy Groups and Priority From: Jon Saperia To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/07/2000 4:54 PM, Matt White at mwhite@torrentnet.com wrote: > Jon: > > Comments inline. > > -Matt > > Matt White > Ericsson IP Infrastructure Matt, I just wrote two notes that I think address at least some of your concerns. lets see if they do :-). /jon From owner-snmpconf@seymour39.SNMP.COM Sat Jul 8 10:26:09 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06252 for ; Sat, 8 Jul 2000 10:26:09 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id KAA03480 for snmpconf-outgoing; Sat, 8 Jul 2000 10:10:04 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 08 Jul 2000 10:10:13 -0400 Subject: Re: snmpconf out-of-policy indications From: Jon Saperia To: Message-ID: In-Reply-To: <200007072218.SAA18868@seymour4.snmp.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/07/2000 6:18 PM, Jeff Case at case@snmp.com wrote: >> I think there may be a need for an out-of-policy-state notification >> (which the architect may choose to disable or filter via snmpv3) for >> security/auditing purposes. > > or use of multiple logical contexts wherein the only objects accessible > in that mib view are the ones that would be altered by a given policy > or policy change > > we need to get a greater appreciation for what multiple logical contexts > can/could do for us > > i am not disagreeing ... this is not an either/or choice required > > regards, > jdc I think Jeff is correct, these are not mutually exclusive. Here is an attempt to describe what I think helpful with regard to out of policy changes. The only point of disagreement that I know about in this area is that Steve would like to have a user making an out of policy change have to modify an object as an extra safety measure. I am not sure that would really be all that beneficial or produce the result he desires. Here are some comments, most of which belong in the BCP - though one, the modified(3) value we have discussed quite a lot does belong in the Policy Module. 1. A notification should be sent whenever an out of policy control change is made to an element that is under the control of policy. (I will say more on this in the BCP). 2. I had proposed the use of contexts earlier as Jeff suggests here. This can only help. I am not sure that is part of the MIB Modules we are developing, but probably should be in the BCP. Suggestions appreciated. 3. An element under the control of policy that has been changed remains a member of the policy group until the attributes in the Role table that caused it to match the policy in the first place are modified. 4. An element that has been modified by a human, while remaining a member of the policy does not get overridden by a policy until its value is made the same as the extant policy with the highest precedence for this element, and by implication then returned to policy control - see my next note. I had mentioned in a note a long time ago that a reload of a policy to a system is the brute force way of overriding all overrides. /jon From owner-snmpconf@seymour39.SNMP.COM Sat Jul 8 10:26:20 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06262 for ; Sat, 8 Jul 2000 10:26:20 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA03489 for snmpconf-outgoing; Sat, 8 Jul 2000 10:10:10 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 08 Jul 2000 10:10:21 -0400 Subject: Re: snmpconf General Functional Questions - Policy Groups and Priority From: Jon Saperia To: Message-ID: In-Reply-To: <200007072219.SAA18877@seymour4.snmp.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/07/2000 6:19 PM, Jeff Case at case@snmp.com wrote: > i think we want to be fastidious in substututing the work precedence for > the word priority I believe Jeff is correct. The term I meant is precedence: the fact of preceding in time. Specifically precedence of evaluation of the policies. Given this, I would like to suggest addition of two objects to the policy table and the addition of one more enumerated value to the pmTrackingElementToPolicyStatus object and a notification: pmPolicyPrecedence OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The order in which policies on the local system are evaluated. A policy with a higher precedence value will be evaluated after a policy with a lower precedence. For example, a policy with a precedence value of 999 will be evaluated after a policy with a precedence value of 998. These values must be unique on the local policy system that realizes this Module. The value for a particular policy should be the same across an administrative domain, though that is not mandatory. When the local policy system performs the evaluation in the pmPolicyFilter for the policy identified by this row it will also read the pmTrackingElementToPolicyStatus object for each object returned as a result of the policy evaluation. If that object is set to modified(3), then the pmPolicyAction shall not be taken on that element. The value of precedence(4), of pmTrackingElementToPolicyStatus is an indication that when an evaluation was performed by another policy, the pmTrackingElementToPolicyStatus was found to have a value of on(1) and that policy had a higher precedence value than the policy that initially set the value of the pmTrackingElementToPolicyStatus to on(1). In this event, the pmTrackingElementToPolicyPrecedence object shall have the value of the pmPolicyIndex for the policy with the higher precedence value entered. If the policy identified by this row of the pmPolicyTable has a higher precedence value than the value found in pmTrackingElementToPolicyPrecedence then the pmPolicyAction should be performed on the element and the pmTrackingElementToPolicyPrecedence object updated with the value of the pmPolicyIndex for this policy. The only exception to these rules is when the policy that has the higher precedence value in not currently running, i.e., the schedule is off." ::= { pmPolicyEntry XX } pmPolicyGroup OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively assigned string that is used to group policies. Any combination is legal, the pmPolicyGroup object does not constrain precedence. That is precedence is evaluated independent of grouping though adminstrators might group related policies together for clarity." ::= { pmPolicyEntry XX } I think the addition of the new state for pmTrackingElementToPolicyStatus and the new pmTrackingElementToPolicyPrecedence are pretty well defined above. We should add a notification each time such an override takes place. The notification should include the element, prior value, policy with the higher precedence and new value. This is an exception condition and should be reported as such. I think the exception to this exception is in schedule transitions. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jul 10 11:28:32 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13137 for ; Mon, 10 Jul 2000 11:28:32 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id KAA09241 for snmpconf-outgoing; Mon, 10 Jul 2000 10:54:38 -0400 (EDT) From: "Barr Hibbs" To: Subject: RE: snmpconf Interim Meeting Attendance Date: Mon, 10 Jul 2000 08:00:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit ...assuming that I attend IETF, I will be there.... --Barr > -----Original Message----- > From: owner-snmpconf@snmp.com [mailto:owner-snmpconf@snmp.com]On Behalf > Of Jon Saperia > Sent: Thursday, July 06, 2000 3:19 AM > To: snmpconf > Subject: snmpconf Interim Meeting Attendance From owner-snmpconf@seymour39.SNMP.COM Mon Jul 10 18:27:41 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00267 for ; Mon, 10 Jul 2000 18:27:40 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA22496 for snmpconf-outgoing; Mon, 10 Jul 2000 18:10:10 -0400 (EDT) From: Dale Francisco Message-Id: <200007102209.PAA05995@itech-view2.cisco.com> Subject: Re: snmpconf Interim Meeting Attendance To: snmpconf@snmp.com Date: Mon, 10 Jul 2000 15:09:28 -0700 (PDT) Cc: dfrancis@cisco.com (Dale Francisco) In-Reply-To: from "Jon Saperia" at Jul 06, 2000 06:18:54 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit I plan on attending. Dale --- /// Dale Francisco IOS Network Management Protocols \\\ Cisco Systems dfrancis@cisco.com /// 170 W Tasman Dr SJCM/2 voice: (408) 527-9787 \\\ San Jose CA 95134-1714 USA fax: (408) 527-2477 > > Folks, > > As you know David H is working on the interim meeting arrangements. Bert > suggested the other day that it might be helpful if people were to say if > they planned on attending as it might help with space planning for the > interim meeting room. This is similar to what I had done for our SFO > interim. > > If you plan on attending, please post a note so David can capture that > information. > > Thanks > /jon > > P.S. - I plan on attending. > > > From owner-snmpconf@seymour39.SNMP.COM Tue Jul 11 20:06:34 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23772 for ; Tue, 11 Jul 2000 20:06:34 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id TAA11974 for snmpconf-outgoing; Tue, 11 Jul 2000 19:49:38 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 11 Jul 2000 19:49:55 -0400 Subject: snmpconf ID Status Update From: Jon Saperia To: snmpconf Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Here is the status of the three relevant IDs for our efforts. The Diff Serv Policy MIB Module has already been posted. I have provided my input to Mike for a start of the policy section in the BCP. He is integrating my comments with his changes and will send the revised document to the ID people tomorrow. I put together the notes I sent to this list for the capability, and other suggestions for the Policy Module and resent them to Steve. I have not hear back from him. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Jul 12 15:44:24 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11034 for ; Wed, 12 Jul 2000 15:44:24 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA17476 for snmpconf-outgoing; Wed, 12 Jul 2000 15:24:46 -0400 (EDT) Message-ID: <396CC5B2.610FC5B7@nextbeacon.com> Date: Wed, 12 Jul 2000 12:23:30 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit All we're trying to do is make sure that when operators override a policy that they do so deliberately. Access control is not the right tool to accomplish this. If every operator has some more restrictive "root" priveleges and all objects require this new privelege, nothing has changed from an access control perspective and the same mistakes will be made. And administering fine-grained access control to restrict only those objects currently under policy control is a nightmare. Steve Jon Saperia wrote: > > on 07/06/2000 5:23 PM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > > > All I want is for the field engineer to have to do something special > > to override a policy. Shouldn't he at least know that he has done > > something significant? Wouldn't it be good if he was thus encouraged > > to think twice? Wouldn't it be good if he was encouraged to mention it > > to the network architect? ("hey, I needed to disable the blah policy > > on trunk 7 last night because it was interacting poorly with the > > backup circuit"). > > > > My proposal is that he issue 2 commands rather than one. The first > > disables the policy on the interface and the second is a normal > > SNMP set that makes the change. > > Steve, I am in agreement with your concern. I think we can accomplish this > without having to issue two commands though. You gave the example of not > running as 'root' to avoid making mistakes - most of us have learned that > lesson. My point is that the access/change of policy is an operational > policy (forgive the pun) decision. If a system is under policy control, > access to the MIB tree that contains everything except the policy objects, > should be quite restricted. The operator would then have to use the root > password to make the changes. This is analogous to 'su root' make all your > changes and exit. Your preference would be to have the person 'sudo change > 1', 'sudo change2' etc. In our case the equivalent of the sudo is to make > the explicit something special you suggest. From owner-snmpconf@seymour39.SNMP.COM Wed Jul 12 16:59:44 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14694 for ; Wed, 12 Jul 2000 16:59:43 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA20062 for snmpconf-outgoing; Wed, 12 Jul 2000 16:27:10 -0400 (EDT) Message-Id: <4.2.2.20000712161652.00abd250@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 12 Jul 2000 16:24:33 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions In-Reply-To: <396CC5B2.610FC5B7@nextbeacon.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I think I understand what you are asking for. If there were a way without excessive violence to the system to cause the "user" to get an error if he tried to change something that was under policy control without first removing it, I would at least be sympathetic to the two step process. But, if we make it a two step process without such coupling, what happens is that the "user" makes a change, gets no error, and comes back later and discovers it is gone. The "user" involved may well not be familiar with the policy mechanisms (someone else takes care of that). He needs to make the change. Forcing him to try to go through audit logs to figure out what happened is not sensible, particularly since network management is NOT this "user"s primary task. he is a network engineer trying to fix a customer problem. Whether this "user" is aware of the organizations desired policies is an organizational issue, not a protocol issue. Making sure that there is someway to tell that he has overriden the policy (the flag that can be checked, and the logs to say who set the flag) is a protocol issue. It may be that different organizations desire different behaviors in this regard. Experience suggests to me however that the larger organizations which most want policy also have folks who need to make changes without significant hinderance. And adding more options to the behavior does not seem like a good way out of this mess. That will just give our users more ways to get confused. Yours, Joel M. Halpern At 12:23 PM 7/12/00 -0700, you wrote: >All we're trying to do is make sure that when operators override a >policy that they do so deliberately. Access control is not the >right tool to accomplish this. > >If every operator has some more restrictive "root" priveleges and all >objects require this new privelege, nothing has changed from an access >control perspective and the same mistakes will be made. > >And administering fine-grained access control to restrict only those >objects currently under policy control is a nightmare. > > >Steve > > >Jon Saperia wrote: > > > > on 07/06/2000 5:23 PM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > > > > > All I want is for the field engineer to have to do something special > > > to override a policy. Shouldn't he at least know that he has done > > > something significant? Wouldn't it be good if he was thus encouraged > > > to think twice? Wouldn't it be good if he was encouraged to mention it > > > to the network architect? ("hey, I needed to disable the blah policy > > > on trunk 7 last night because it was interacting poorly with the > > > backup circuit"). > > > > > > My proposal is that he issue 2 commands rather than one. The first > > > disables the policy on the interface and the second is a normal > > > SNMP set that makes the change. > > > > Steve, I am in agreement with your concern. I think we can accomplish this > > without having to issue two commands though. You gave the example of not > > running as 'root' to avoid making mistakes - most of us have learned that > > lesson. My point is that the access/change of policy is an operational > > policy (forgive the pun) decision. If a system is under policy control, > > access to the MIB tree that contains everything except the policy objects, > > should be quite restricted. The operator would then have to use the root > > password to make the changes. This is analogous to 'su root' make all your > > changes and exit. Your preference would be to have the person 'sudo change > > 1', 'sudo change2' etc. In our case the equivalent of the sudo is to make > > the explicit something special you suggest. From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 00:41:40 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24944 for ; Thu, 13 Jul 2000 00:41:39 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id AAA05369 for snmpconf-outgoing; Thu, 13 Jul 2000 00:24:50 -0400 (EDT) Message-ID: <396D444A.D9D052F0@nextbeacon.com> Date: Wed, 12 Jul 2000 21:23:38 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Jon Saperia wrote: > on 07/06/2000 3:47 PM, Joel M. Halpern at joel@mcquillan.com wrote: > > > I had overlooked that (background change detection) proposal. That would > > indeed produce the results you propose. And was not what I was > > expecting. I had assumed that one would indeed modify some internal > > mechanisms so that if a change was being made to a variable which had been > > modified by policy, that the "don't touch" flag would get set. > > Yes. The modification of the internal mechanisms to which you refer, does > not imply that one would need to modify the low level instrumentation as > Steve suggests. It requires a change to the snmp protocol engine and to the CLI command processor and any other engine that processes management commands. Such a requirement is pretty unprecedented in MIB development. Some other issues: ======== Before any varbinds are modified, the system must check to see if it is under policy control (and thus would need to set the modified bit). How does this engine know that a variable is under policy control? This is difficult because it is hard to look at a policyAction script and figure out which variables it is controlling because there are conditionals (if A then set B else set C) and because some or all of the script is opaque depending on how much work you want to do interpreting it. Seems there are 2 strategies: A. When a policyAction executes, save a list of OIDs it modified in a master list of policy-controlled OIDs. Then we can check this list before modifying any variable. Problems: - Lots of memory used storing long list of OIDs. - When a policy becomes inactive, hard to tell which OIDs to take out of list (can't simply re-execute policyAction because conditionals might have changed). B. When you want to know if a variable has been modified, inspect policyAction to see which variables are controlled. Problems: - Requires execution of script to evaluate conditionals - Interpreting script in bowels of snmp protocol engine is not a good architectural decision. ======== When a policy goes away on an element and then comes back, should the modified bit get cleared? ======== This doesn't work when the policy agent is a mid-level manager (i.e.: where the agent that implements the Policy MIB enforces policy in a subdomain through SNMP requests). I think the modified bit proposal requires us to abandon that part of our architecture. ======== So far I've talked about the requirement for the operator to think twice before overriding a policy. The same is true when the tables are turned: When an operator overrides a policy to firefight a problem, the architect should think twice before returning it to policy control. The problem is that without an explicit forceOff state, the architect has no evidence that a modification to policy was done deliberately. ======== I am opposed to the modified bit because it doesn't offer the right services to network architects and operators alike and secondarily because of the modeling and implementation problems it presents. The current solution (the forceOff bit), allows operators to override any policy that is causing operational difficulties (subject to access control, of course). Meanwhile, the network architect can be assured that policy overrides are applied only when necessary. Steve From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 00:52:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25151 for ; Thu, 13 Jul 2000 00:52:57 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id AAA06638 for snmpconf-outgoing; Thu, 13 Jul 2000 00:37:41 -0400 (EDT) Message-ID: <396D474C.4609A920@nextbeacon.com> Date: Wed, 12 Jul 2000 21:36:28 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Pointers from Policy MIB -> implementation-specific MIB References: <200006290729.JAA28621@lmera.lmera.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit David Partain wrote: > Different strategies are possible. Three are: > > - pointers from the "lower" MIBs (implementation-specific) > into the policy MIB > > - shared indices between the policy MIB and the > implementation-specific MIBs > > - pointers from the policy MIB into the implementation-specific > MIBs > > This was discussed at the last interim meeting, and the best > approach appears to be the last of them. It allows the most > flexibility with respect to how many places to point to (which #2 > doesn't), while avoiding the problems that are associated with > #1. I agree that #3 is the best. > So, we propose that something along the lines of the objects > below be added to the policyMgt MIB in > draft-ietf-snmpconf-pm-??.txt. > ... > PmPolicyMechanismEntry SEQUENCE ::= { > pmPolicyMechanismIndex Unsigned32, > pmPolicyMechanismPointer RowPointer > } > ... I think there's a better way to implement #3. Add a settable object to the implementation-specific MIB that, when set, causes it to act. The contents of the set contains the identity of the target element. For example, in the diffserv policy MIB, you would have: diffPolicyPHBTarget OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object is set with the ifIndex value of the interface to be configured. When this object is set, the associated interface will be configured with the per-hop-behavior described by this entry." ::= { diffPolicyPHBEntry xx } Then a policy action can contain a command to set this variable to 7 (for example), and cause the specified PHB to be applied to interface #7. For example: diffPolicyPHBTable ID Descr TrafficID Action 37 "Mark SAP/R3 with DSCP 7" ptr to SAP 6tuple ptr to Mark command 51 ... policyFilter (type == interface) && roleMatch("Access") policyAction setint(diffPolicyPHBTarget.37, $1) In other words, foreach interface that is access, set diffPolicyPHBTarget.3 to the ifindex of the interface. This is more in keeping with the original architecture we agreed upon some time ago (and re-affirmed at the last meeting, ref.: "Instance Dependent, Mechanism Independent Service"). Benefits over the RowPointer include: 1. Allows mid-level-manager implementations We would like to have MLM implementations where the policy evaluation happens on one machine which enforces policy on a number of systems in a sub-domain. Unfortunately, a RowPointer has significance only within an agent so it can't be used in an MLM implementation. 2. Avoids uncertainty over which executes, the script or rowpointer If the pmPolicyTable had both the rowPointer object as well as policyAction, it would be unclear what to do when both the RowPointer and the policyAction were set. 3. Allows conditionals to be used Since policyActions are scripts they can contain conditionals such as: if (capMatch("diffServ")) -- If diffserv is supported setint(diffPolicyPHBTarget.3, $1) else setint(802PolicyTarget.7, $1) -- i.e. 802 implementation-specific MIB A RowPointer wouldn't allow such a construct. 4. Allows service of implementation-specific MIB to be used independently of Policy MIB Allows any SNMP application to use the diffPolicyMIB to configure per-hop-behavior. 5. The RowPointer mechanism only allows actions on "this element". A fair amount of the time we will want to perform an action on an element related to "this element". Scripts will have the ability to follow these relationships and select the correct target address. Steve From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 01:09:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26131 for ; Thu, 13 Jul 2000 01:09:57 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id AAA07547 for snmpconf-outgoing; Thu, 13 Jul 2000 00:55:04 -0400 (EDT) Message-ID: <396D4B5F.98343E26@nextbeacon.com> Date: Wed, 12 Jul 2000 21:53:51 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf out-of-policy indications References: <4.2.2.20000705182124.00aabaa0@omniplex.mcquillan.com> <4.2.2.20000706154322.00a94100@omniplex.mcquillan.com> <3964F8CC.3DC04A0B@nextbeacon.com> <39660CB1.12619996@enterasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit David Harrington wrote: > Any suggestions on how to provide feedback - upon request - to the field > engineer about how many policies would be affected by changing a given > managed object, so he could determine the scale of the potential impact > on policy? If you walk the pmTrackingElementToPolicyTable, you can count the number of policies applying to an element. Just walk the subtree for the element you are investigating. > > > Wouldn't it be good if he was encouraged to mention it > > to the network architect? ("hey, I needed to disable the blah policy > > on trunk 7 last night because it was interacting poorly with the > > backup circuit"). > > > > Should we provide some mechanism for standardizing notifications > advising of changes to objects that have been moved "out of policy"? > There are two purposes - to remind the field engineer that he made a > temporary change that should be reset, and to notify the architect that > somebody changed a value that is subsequently affecting policy. Yes, I agree this is important. Judging by other messages, it seems that others feel this way as well. I view this as self-documenting exceptions. Steve From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 02:53:03 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08958 for ; Thu, 13 Jul 2000 02:53:02 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id CAA14707 for snmpconf-outgoing; Thu, 13 Jul 2000 02:36:59 -0400 (EDT) Message-ID: <396D6343.CA1D4011@nextbeacon.com> Date: Wed, 12 Jul 2000 23:35:47 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions - Policy Groups andPriority References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Jon Saperia wrote: > pmPolicyPrecedence OBJECT-TYPE > SYNTAX Integer32 (0..65535) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The order in which policies on the local system are > evaluated. A policy with a higher precedence value will > be evaluated after a policy with a lower precedence. For > example, a policy with a precedence value of 999 will be > evaluated after a policy with a precedence value of 998. I don't think "time order" semantics will work very well. First of all, it seems to assume that there are no side effects of a variable going through a sequence of lower-precedence values before settling on the highest-precedence value. Second, we talked at the last meeting about having objects that control the frequency of policy evaluation on a per-policy basis, so it doesn't seem right to assume that all policies are evaluated at the same time, in order. Third, I'm concerned about what happens when an element changes state and suddenly matches a policyFilter - are we forced to rerun all higher precedence policyActions? Finally, consider that a policyAction may affect multiple variables - I think we want all of the variables to be set or none - it wouldn't be cool to change only those that survive higher precedence policies. > These > values must be unique on the local policy system that realizes > this Module. What if they're not? Should the agent reboot? I'd prefer to specify the agent behavior even if they aren't unique. Let me suggest that we allow them to be the same but it is an implementation-dependent matter how they are processed if they are the same. If the manager needs "unique" semantics, it's its responsibility to set them right. BTW, this would also present multi-manager problems. > The value for a particular policy should be > the same across an administrative domain, though that is not > mandatory. Is that important? > When the local policy system performs the evaluation > in the pmPolicyFilter for the policy identified by this row > it will also read the pmTrackingElementToPolicyStatus object > for each object returned as a result of the policy evaluation. > If that object is set to modified(3), then the pmPolicyAction > shall not be taken on that element. This object seems like an odd context to describe the modified or forceOff semantics. It should probably be in the pmPolicyTable description where the entire policy evaluation algorithm should be described. > The value of precedence(4), of pmTrackingElementToPolicyStatus > is an indication that when an evaluation was performed by > another policy, the pmTrackingElementToPolicyStatus was > found to have a value of on(1) and that policy had a higher > precedence value than the policy that initially set the value > of the pmTrackingElementToPolicyStatus to on(1). In this event, > the pmTrackingElementToPolicyPrecedence object shall have the > value of the pmPolicyIndex for the policy with the higher > precedence value entered. If the policy identified by this > row of the pmPolicyTable has a higher precedence value than > the value found in pmTrackingElementToPolicyPrecedence then > the pmPolicyAction should be performed on the element and the > pmTrackingElementToPolicyPrecedence object updated with the > value of the pmPolicyIndex for this policy. The only exception > to these rules is when the policy that has the higher > precedence value in not currently running, i.e., the schedule > is off." This is pretty cool. > ::= { pmPolicyEntry XX } > > pmPolicyGroup OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "An administratively assigned string that is used to group > policies. Any combination is legal, the pmPolicyGroup object > does not constrain precedence. That is precedence is evaluated > independent of grouping though adminstrators might group > related policies together for clarity." > ::= { pmPolicyEntry XX } > > I think the addition of the new state for pmTrackingElementToPolicyStatus > and the new pmTrackingElementToPolicyPrecedence are pretty well defined > above. > > We should add a notification each time such an override takes place. The > notification should include the element, prior value, policy with the higher > precedence and new value. This is an exception condition and should be > reported as such. I think the exception to this exception is in schedule > transitions. > > /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 06:45:28 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11860 for ; Thu, 13 Jul 2000 06:45:27 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA18606 for snmpconf-outgoing; Thu, 13 Jul 2000 06:29:04 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 13 Jul 2000 06:29:18 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <396D444A.D9D052F0@nextbeacon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/13/2000 12:23 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > Jon Saperia wrote: > >> on 07/06/2000 3:47 PM, Joel M. Halpern at joel@mcquillan.com wrote: >> >>> I had overlooked that (background change detection) proposal. That would >>> indeed produce the results you propose. And was not what I was >>> expecting. I had assumed that one would indeed modify some internal >>> mechanisms so that if a change was being made to a variable which had been >>> modified by policy, that the "don't touch" flag would get set. >> >> Yes. The modification of the internal mechanisms to which you refer, does >> not imply that one would need to modify the low level instrumentation as >> Steve suggests. > > It requires a change to the snmp protocol engine and to the CLI command > processor and any other engine that processes management commands. Such > a requirement is pretty unprecedented in MIB development. No, you assume a particular method of implementation. There is nothing in the realization of the software to access the instrumentation such as an interface counter object that is necessarily cognizant of how the request got there. I will agree that with some systems this is easier to do than with others. Many newer systems are implemented in the way I describe. There are ways or 'retrofitting' this into architectures that have the isolated CLI and SNMP systems that would be most problematic. I am working on one such system now. How one works on this problem is a function of how the system is put together. > So far I've talked about the requirement for the operator to think > twice before overriding a policy. The same is true when the tables > are turned: When an operator overrides a policy to firefight a > problem, the architect should think twice before returning it to > policy control. The problem is that without an explicit forceOff > state, the architect has no evidence that a modification to policy > was done deliberately. > ======== > > I am opposed to the modified bit because it doesn't offer the right > services to network architects and operators alike and secondarily > because of the modeling and implementation problems it presents. > > The current solution (the forceOff bit), allows operators to override > any policy that is causing operational difficulties (subject to > access control, of course). Meanwhile, the network architect can be > assured that policy overrides are applied only when necessary. Several of us has stated a different view of this. There is no objection to the foreOff bit. That said, we do not believe it is correct in this case, to try to do social engineering by making it more difficult to do policy overrides. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 09:01:07 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16943 for ; Thu, 13 Jul 2000 09:01:06 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA20811 for snmpconf-outgoing; Thu, 13 Jul 2000 08:46:45 -0400 (EDT) Message-ID: <396DB9AC.2AC924DC@enterasys.com> Date: Thu, 13 Jul 2000 08:44:28 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf IETF48 and Interim meeting logistics Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, The first draft of the IETF48 agenda has been posted. Here are the snmpconf meetings: Tuesday 0900-1130 Morning Sessions APP vpim Voice Profile for Internet Mail WG INT dhc Dynamic Host Configuration WG OPS snmpconf Configuration Management with SNMP WG RTG pim Protocol Independent Multicast WG SEC pkix Public-Key Infrastructure (X.509) WG TSV enum Telephone Number Mapping WG TSV issll Integrated Services over Specific Link Layers WG TSV nfsv4 Network File System Version 4 WG FRIDAY, August 4, 2000 0900-1130 Morning Sessions APP beep Blocks Extensible Exchange Protocol WG INT ipoptr IP over Packet Transport Rings BOF OPS snmpconf Configuration Management with SNMP WG RTG gsmp General Switch Management Protocol WG SEC idwg Intrusion Detection Exchange Format WG TSV rohc Robust Header Compression WG --- The Interim meeting will be held at the Doubletree Hotel, Aug 4 and 5. We have the Butler room, Friday 12-5 and Saturday 9-5. If you plan to attend, and have not yet told us, please do, so we can plan correctly. I have asked for Coffee/Cookies for both Friday and Saturday, and a continental breakfast for Saturday. The hotel will provide an overhead projector and power strips for laptops. Enterasys will provide a VGA projector. dbh -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 12:01:45 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25734 for ; Thu, 13 Jul 2000 12:01:44 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA27136 for snmpconf-outgoing; Thu, 13 Jul 2000 11:46:39 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 13 Jul 2000 11:46:57 -0400 Subject: Re: snmpconf IETF48 and Interim meeting logistics From: Jon Saperia To: Message-ID: In-Reply-To: <396DB9AC.2AC924DC@enterasys.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/13/2000 8:44 AM, David Harrington at dbh@enterasys.com wrote: > Enterasys will provide a VGA projector. Thanks David for setting all of this up. At the last interim meeting there was a problem with the projector. As you may recall, we ended up using the projector that Andy B. had brought for the previous meeting. We had a similar issue in N.H. Is there a way we can ensure we use a different type please? Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jul 13 13:45:25 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01870 for ; Thu, 13 Jul 2000 13:45:24 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA01914 for snmpconf-outgoing; Thu, 13 Jul 2000 13:25:42 -0400 (EDT) Date: Thu, 13 Jul 2000 13:25:03 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions - Policy Groups and Priority In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon: This looks good to me. Matt White Ericsson IP Infrastructure On Sat, 8 Jul 2000, Jon Saperia wrote: > on 07/07/2000 6:19 PM, Jeff Case at case@snmp.com wrote: > > > i think we want to be fastidious in substututing the work precedence for > > the word priority > > I believe Jeff is correct. The term I meant is precedence: the fact of > preceding in time. Specifically precedence of evaluation of the policies. > > Given this, I would like to suggest addition of two objects to the policy > table and the addition of one more enumerated value to the > pmTrackingElementToPolicyStatus object and a notification: > > pmPolicyPrecedence OBJECT-TYPE > SYNTAX Integer32 (0..65535) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The order in which policies on the local system are > evaluated. A policy with a higher precedence value will > be evaluated after a policy with a lower precedence. For > example, a policy with a precedence value of 999 will be > evaluated after a policy with a precedence value of 998. These > values must be unique on the local policy system that realizes > this Module. The value for a particular policy should be > the same across an administrative domain, though that is not > mandatory. > > When the local policy system performs the evaluation > in the pmPolicyFilter for the policy identified by this row > it will also read the pmTrackingElementToPolicyStatus object > for each object returned as a result of the policy evaluation. > If that object is set to modified(3), then the pmPolicyAction > shall not be taken on that element. > > The value of precedence(4), of pmTrackingElementToPolicyStatus > is an indication that when an evaluation was performed by > another policy, the pmTrackingElementToPolicyStatus was > found to have a value of on(1) and that policy had a higher > precedence value than the policy that initially set the value > of the pmTrackingElementToPolicyStatus to on(1). In this event, > the pmTrackingElementToPolicyPrecedence object shall have the > value of the pmPolicyIndex for the policy with the higher > precedence value entered. If the policy identified by this > row of the pmPolicyTable has a higher precedence value than > the value found in pmTrackingElementToPolicyPrecedence then > the pmPolicyAction should be performed on the element and the > pmTrackingElementToPolicyPrecedence object updated with the > value of the pmPolicyIndex for this policy. The only exception > to these rules is when the policy that has the higher > precedence value in not currently running, i.e., the schedule > is off." > ::= { pmPolicyEntry XX } > > pmPolicyGroup OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "An administratively assigned string that is used to group > policies. Any combination is legal, the pmPolicyGroup object > does not constrain precedence. That is precedence is evaluated > independent of grouping though adminstrators might group > related policies together for clarity." > ::= { pmPolicyEntry XX } > > > I think the addition of the new state for pmTrackingElementToPolicyStatus > and the new pmTrackingElementToPolicyPrecedence are pretty well defined > above. > > We should add a notification each time such an override takes place. The > notification should include the element, prior value, policy with the higher > precedence and new value. This is an exception condition and should be > reported as such. I think the exception to this exception is in schedule > transitions. > > /jon > From owner-snmpconf@seymour39.SNMP.COM Fri Jul 14 02:36:37 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05736 for ; Fri, 14 Jul 2000 02:36:36 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id CAA00917 for snmpconf-outgoing; Fri, 14 Jul 2000 02:18:45 -0400 (EDT) Message-ID: From: Walter Weiss To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Interim Meeting Attendance Date: Thu, 13 Jul 2000 20:39:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon, I plan on attending this meeting. regards, -Walter -----Original Message----- From: Jon Saperia [mailto:saperia@mediaone.net] Sent: Thursday, July 06, 2000 6:19 AM To: snmpconf Subject: snmpconf Interim Meeting Attendance Folks, As you know David H is working on the interim meeting arrangements. Bert suggested the other day that it might be helpful if people were to say if they planned on attending as it might help with space planning for the interim meeting room. This is similar to what I had done for our SFO interim. If you plan on attending, please post a note so David can capture that information. Thanks /jon P.S. - I plan on attending. From owner-snmpconf@seymour39.SNMP.COM Fri Jul 14 07:06:19 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14482 for ; Fri, 14 Jul 2000 07:06:19 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA02042 for snmpconf-outgoing; Fri, 14 Jul 2000 06:50:31 -0400 (EDT) Message-Id: <200007141049.GAA08603@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-bcp-02.txt Date: Fri, 14 Jul 2000 06:49:57 -0400 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : Configuring Networks and Devices with SNMP Author(s) : M. MacFaden, J. Saperia Filename : draft-ietf-snmpconf-bcp-02.txt Pages : 40 Date : 13-Jul-00 This document is intended for vendors building equipment using the Internet Standard Management Framework as well as for users of such equipment. General guidelines for configuration are presented from which specific current best practices using the Internet Standard Management Framework are derived. NOTE: this work is very much a draft in progress. Reviewer comments, questions and criticisms welcome on the snmpconf mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-bcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-bcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713144956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-bcp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-bcp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713144956.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Mon Jul 17 12:11:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14925 for ; Mon, 17 Jul 2000 12:11:57 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA19875 for snmpconf-outgoing; Mon, 17 Jul 2000 11:46:45 -0400 (EDT) Message-ID: <397329B3.97BF7658@enterasys.com> Date: Mon, 17 Jul 2000 11:43:47 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf meeting logistics Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, It was suggested that I remind everyone that the schedule of the snmpconf meetings, which I posted recently, is still subject to change by the IETF. -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Thu Jul 20 10:06:20 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27636 for ; Thu, 20 Jul 2000 10:06:19 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA00703 for snmpconf-outgoing; Thu, 20 Jul 2000 09:47:43 -0400 (EDT) Message-ID: <39770292.886C13D8@mediaone.net> Date: Thu, 20 Jul 2000 09:45:54 -0400 From: "D. Harrington" X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf Interim meeting costs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, We need one or more sponsors to pick up the costs for the Pittsburgh interim. The cost will be ~$2700. We need to advise the hotel who will be covering the costs soon. If we do not get sponsors, we will need to cancel the meeting. Please let me know asap if your company will sponsor this meeting. Thanks, dbh From owner-snmpconf@seymour39.SNMP.COM Thu Jul 20 12:15:39 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04693 for ; Thu, 20 Jul 2000 12:15:38 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA06842 for snmpconf-outgoing; Thu, 20 Jul 2000 11:55:42 -0400 (EDT) From: "Barr Hibbs" To: Subject: RE: snmpconf Interim meeting costs Date: Thu, 20 Jul 2000 08:55:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <39770292.886C13D8@mediaone.net> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit we're not in a position to underwrite the entire cost, but I will certainly pay my share.... --Barr Hibbs UltraDNS Corporation From owner-snmpconf@seymour39.SNMP.COM Thu Jul 20 23:10:21 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00755 for ; Thu, 20 Jul 2000 23:10:20 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id WAA26027 for snmpconf-outgoing; Thu, 20 Jul 2000 22:57:10 -0400 (EDT) X-Authentication-Warning: willy.cs.mcgill.ca: zhifeng owned process doing -bs Date: Thu, 20 Jul 2000 22:56:14 -0400 (EDT) From: Zhifeng XIAO To: snmpconf Subject: Re: snmpconf Interim Meeting Attendance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I will attend the Interim. Zhifeng Xiao From owner-snmpconf@seymour39.SNMP.COM Fri Jul 21 18:11:28 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24537 for ; Fri, 21 Jul 2000 18:11:28 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA07817 for snmpconf-outgoing; Fri, 21 Jul 2000 17:57:24 -0400 (EDT) X-Authentication-Warning: willy.cs.mcgill.ca: zhifeng owned process doing -bs Date: Fri, 21 Jul 2000 17:56:50 -0400 (EDT) From: Zhifeng XIAO To: snmpconf Subject: Re: snmpconf Interim Meeting Attendance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Professor Omar Cherkaoui at University of Quebec will attend the Interim meeting. Zhifeng Xaio From owner-snmpconf@seymour39.SNMP.COM Fri Jul 21 18:11:28 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24539 for ; Fri, 21 Jul 2000 18:11:28 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA07718 for snmpconf-outgoing; Fri, 21 Jul 2000 17:54:19 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 21 Jul 2000 17:54:57 -0400 Subject: snmpconf Agenda for SNMPCONF (SNMP Configuration) WG Meetings in Pittsburgh From: Jon Saperia To: , snmpconf , Jon Saperia Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Below is the proposed agenda for the SNMPCONF WG meetings to be held in Pittsburgh. TUESDAY, August 1, 2000 0900-1130 Welcome and logistics - Dave Harrington Overview of agendas* - Dave Harrington Status update on current work** - Jon Saperia Presentations for WG - Dave Harrington*** BPC issues - Mike MacFaden * The suggested reading list for all SNMPCONF WG Meetings at this IETF are: draft-ietf-snmpconf-pm-02.txt draft-ietf-snmpconf-diffpolicy-02.txt draft-ietf-snmpconf-bcp-02.txt **Presentation will be similar to one planned for O&M Open area meeting. ***A portion of this session will be reserved for anyone that requests a brief period to make presentations on relevant topics. FRIDAY, August 4, 2000 0900-1130* Agenda Review - Dave Harrington Execution Environment Questions - Steve Waldbusser * This meeting will pick up where the Tuesday meeting finishes. Most of the proposed agenda items are from the issues lists developed in San Francisco and published on the mailing list. These topics have occupied the majority of mailing list activity since then. The presenters will work through the issues lists with the headings shown in the agenda. Below is the agenda for the interim meeting. FRIDAY, August 4, 2000 (Interim meeting part 1) 1200-1700 Interim Meeting Logistics - Dave Harrington Execution Environment Questions - Steve Waldbusser Language Related Questions - Steve Waldbusser SATURDAY, August 5, 2000 (Interim meeting part 2) 0900-16:00 Policy Processing Questions - Steve Waldbusser Architectural and Relationship with other Documents Questions - Partain/Saperia/Hazewinkel General Functional Questions - Jon Saperia Conflict Resolution Issues - Jon Saperia Close - Jon/Dave From owner-snmpconf@seymour39.SNMP.COM Mon Jul 24 06:52:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14447 for ; Mon, 24 Jul 2000 06:52:57 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA11961 for snmpconf-outgoing; Mon, 24 Jul 2000 06:34:48 -0400 (EDT) Message-Id: <200007241034.GAA07610@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-pm-02.txt Date: Mon, 24 Jul 2000 06:34:14 -0400 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : Policy Based Management MIB Author(s) : S. Waldbusser, J. Saperia, T. Hongal Filename : draft-ietf-snmpconf-pm-02.txt Pages : 41 Date : 21-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based configuration management of SNMP infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-pm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-pm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000721171338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-pm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-pm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171338.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Wed Jul 26 09:09:04 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06523 for ; Wed, 26 Jul 2000 09:09:04 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA15357 for snmpconf-outgoing; Wed, 26 Jul 2000 08:51:01 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 26 Jul 2000 08:51:46 -0400 Subject: Re: snmpconf out-of-policy indications - NOTIFICATIONS From: Jon Saperia To: Message-ID: In-Reply-To: <396D4B5F.98343E26@nextbeacon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/13/2000 12:53 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: >> >> Should we provide some mechanism for standardizing notifications >> advising of changes to objects that have been moved "out of policy"? >> There are two purposes - to remind the field engineer that he made a >> temporary change that should be reset, and to notify the architect that >> somebody changed a value that is subsequently affecting policy. > > Yes, I agree this is important. Judging by other messages, it seems that > others feel this way as well. I view this as self-documenting > exceptions. > > > Steve This was part of the out of policy thread that I just responded to. In this note Steve responded to a note by Dave Harrington. The issue here is notifications. I think we are all in agreement on the importance of notifications. Please see the BCP document recently posted. It has a new section on policy overrides. It mentions notifications specifically. There is also a general section in the document on notifications, but it probably should be expanded. The relevant section is: > 6.7 Changes to configuration outside of the policy system > > A goal of SNMP-based policy management is to coexist with other > forms what have historically been instance based management. The > best example is command line interface. Here are some guidelines for > handling these changes. > > A notification should be sent whenever an out of policy control > change is made to an element that is under the control of policy. > This notification should include the policy that was changed, the > instance of the element that was changed and the object and value > that it was changed to. > From owner-snmpconf@seymour39.SNMP.COM Wed Jul 26 09:09:52 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06724 for ; Wed, 26 Jul 2000 09:09:51 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA15220 for snmpconf-outgoing; Wed, 26 Jul 2000 08:44:45 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 26 Jul 2000 08:45:35 -0400 Subject: Re: snmpconf General Functional Questions - AKA Policy Overrides. From: Jon Saperia To: Message-ID: In-Reply-To: <4.2.2.20000712161652.00abd250@omniplex.mcquillan.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/12/2000 4:24 PM, Joel M. Halpern at joel@mcquillan.com wrote: > I think I understand what you are asking for. If there were a way without > excessive violence to the system to cause the "user" to get an error if he > tried to change something that was under policy control without first removing > it, I would at least be sympathetic to the two step process. > > But, if we make it a two step process without such coupling, what happens is > that the "user" makes a change, gets no error, and comes back later and > discovers it is gone. The "user" involved may well not be familiar with the > policy mechanisms (someone else takes care of that). He needs to make the > change. Forcing him to try to go through audit logs to figure out what > happened is not sensible, particularly since network management is NOT this > "user"s primary task. he is a network engineer trying to fix a customer > problem. Whether this "user" is aware of the organizations desired policies is > an organizational issue, not a protocol issue. Making sure that there is > someway to tell that he has overriden the policy (the flag that can be > checked, and the logs to say who set the flag) is a protocol issue. > > It may be that different organizations desire different behaviors in this > regard. Experience suggests to me however that the larger organizations which > most want policy also have folks who need to make changes without significant > hinderance. And adding more options to the behavior does not seem like a good > way out of this mess. That will just give our users more ways to get > confused. In preparing for the upcoming meeting, I see that there were some notes from Steve Waldbusser and Joel that I had not properly responded to. I choose to respond to this note since I think Joel summarizes the issue well. The issue we have had is that some of us do not want the person who needs to override a policy on an element to have to know which object to set in the Policy MIB Module and thus a lot of details not relevant to the operational task at hand. Steve wanted to have an explicit object to set to cause people to know that they are overriding a policy also a good goal. I do see a way that a CLI could be implemented such that it could ask a user to 'confirm' their action if the action includes changing the value of an element under policy control. This would be a implementation detail not part of the protocol. Obviously SNMP-based managers can do even more. I still think it would be best not to require the user to have to write a specific SNMP object to override a policy. I am sure we will have some fun with this at the meeting :-) /jon From owner-snmpconf@seymour39.SNMP.COM Wed Jul 26 10:04:39 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16340 for ; Wed, 26 Jul 2000 10:04:38 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA16551 for snmpconf-outgoing; Wed, 26 Jul 2000 09:44:58 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 26 Jul 2000 09:45:47 -0400 Subject: Re: snmpconf Pointers from Policy MIB -> implementation-specific MIB From: Jon Saperia To: Message-ID: In-Reply-To: <396D474C.4609A920@nextbeacon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/13/2000 12:36 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > > David Partain wrote: > >> Different strategies are possible. Three are: >> >> - pointers from the "lower" MIBs (implementation-specific) >> into the policy MIB >> >> - shared indices between the policy MIB and the >> implementation-specific MIBs >> >> - pointers from the policy MIB into the implementation-specific >> MIBs >> >> This was discussed at the last interim meeting, and the best >> approach appears to be the last of them. It allows the most >> flexibility with respect to how many places to point to (which #2 >> doesn't), while avoiding the problems that are associated with >> #1. > > I agree that #3 is the best. I think we are all in agreement on this issue now. We have to work out the details. > > >> So, we propose that something along the lines of the objects >> below be added to the policyMgt MIB in >> draft-ietf-snmpconf-pm-??.txt. >> ... >> PmPolicyMechanismEntry SEQUENCE ::= { >> pmPolicyMechanismIndex Unsigned32, >> pmPolicyMechanismPointer RowPointer >> } >> ... > > I think there's a better way to implement #3. Add a settable object > to the implementation-specific MIB that, when set, causes it to act. > The contents of the set contains the identity of the target element. > > For example, in the diffserv policy MIB, you would have: > > diffPolicyPHBTarget OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object is set with the ifIndex value of the interface > to be configured. When this object is set, the associated > interface will be configured with the per-hop-behavior > described by this entry." > ::= { diffPolicyPHBEntry xx } A couple of problems here if I understand this proposal: 1. We were talking about a pointer from the Policy MIB Module to the mechanism or implementation specific MIB Module. Your example seems to have added an object to the DiffServ Policy MIB Module. This is not a show stopper since the way you propose it the object is 'set' via the policy MIB Module. I have a proposal below that I think makes this work. 2. The PHB Table in the current DiffServ Policy MIB Module draft is not instance/element specific. Many instances in a system might be configured based on this 'template'. From the recently posted draft: >> - The diffPolicyPHBTable provides managed objects for >> per-hop-behavior configuration. This table contains >> RowPointers into subsequent tables in such a way that the >> Traffic Control Block (TCB) can be created as soon as a >> configuration is made active. >> The mechanism and implementation specific MIB Modules will not as a rule have instance specific information such as ifIndex. All this said, you make what I think are some really good points in the rest of the note which I have left attached. I think we can make this all work as you suggest and get all the benefits you describe(though I am skeptical about the Mid-level manager piece). A side effect is that if more than one policy wishes to use a mechanism or implementation specific set of parameters, additional duplicate rows must be created in each module. In this case we are talking about the DiffServ mechanisms, but the problem is generic. What we would do is change your definition and substitute the following object: diffPolicyPHBPolicy OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "When this MIB Module is used in conjunction with the Policy MIB Module, the policyAction portion of the policy can contain a command to set this object to the value of the pmPolicyIndex that will use the PHB definitions defined in this row of the diffPolicyPHBTable. In the case where the policyAction points to an entry in the diffPolicyPHBTable that already has a value for this object, then the values from that row will be copied into a new row and this value will be filled in with the pmPolicyIndex of the policy that caused the creation of this row. When a policy is removed, all created rows are to be deleted. When a policy is removed that did not create this row, then this value shall be set to 0 indicating this row is not currently used by any policy on the system." ::= { diffPolicyPHBEntry xx } All this is a bit awkward, but is the only way I have thought of to date to avoid having to manually create duplicate rows for policies that will have the same mechanism and implementation specific parameters. I think this will happen a lot. What will be different are the instances to which they are applied. /jon > Then a policy action can contain a command to set this variable > to 7 (for example), and cause the specified PHB to be applied to > interface #7. > > For example: > > diffPolicyPHBTable > ID Descr TrafficID Action > 37 "Mark SAP/R3 with DSCP 7" ptr to SAP 6tuple ptr to Mark command > 51 ... > > > policyFilter > (type == interface) && roleMatch("Access") > policyAction > setint(diffPolicyPHBTarget.37, $1) > > In other words, foreach interface that is access, set > diffPolicyPHBTarget.3 to the ifindex of the interface. > > This is more in keeping with the original architecture we agreed > upon some time ago (and re-affirmed at the last meeting, > ref.: "Instance Dependent, Mechanism Independent Service"). > > Benefits over the RowPointer include: > > 1. Allows mid-level-manager implementations > We would like to have MLM implementations where the policy > evaluation happens on one machine which enforces policy on > a number of systems in a sub-domain. Unfortunately, a > RowPointer has significance only within an agent so it can't > be used in an MLM implementation. > > 2. Avoids uncertainty over which executes, the script or rowpointer > If the pmPolicyTable had both the rowPointer object as well as > policyAction, it would be unclear what to do when both > the RowPointer and the policyAction were set. > > 3. Allows conditionals to be used > Since policyActions are scripts they can contain conditionals > such as: > if (capMatch("diffServ")) -- If diffserv is supported > setint(diffPolicyPHBTarget.3, $1) > else > setint(802PolicyTarget.7, $1) > -- i.e. 802 implementation-specific MIB > > A RowPointer wouldn't allow such a construct. > > 4. Allows service of implementation-specific MIB to be used > independently of Policy MIB > Allows any SNMP application to use the diffPolicyMIB to configure > per-hop-behavior. > > 5. The RowPointer mechanism only allows actions on "this element". > A fair amount of the time we will want to perform an action on > an element related to "this element". Scripts will have the > ability to follow these relationships and select the correct > target address. > > > Steve From owner-snmpconf@seymour39.SNMP.COM Wed Jul 26 10:57:56 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23593 for ; Wed, 26 Jul 2000 10:57:55 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id KAA18166 for snmpconf-outgoing; Wed, 26 Jul 2000 10:38:55 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 26 Jul 2000 09:57:39 -0400 Subject: Re: snmpconf General Functional Questions - Policy Groups andPriority From: Jon Saperia To: Message-ID: In-Reply-To: <396D6343.CA1D4011@nextbeacon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/13/2000 2:35 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > Jon Saperia wrote: > >> pmPolicyPrecedence OBJECT-TYPE >> SYNTAX Integer32 (0..65535) >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "The order in which policies on the local system are >> evaluated. A policy with a higher precedence value will >> be evaluated after a policy with a lower precedence. For >> example, a policy with a precedence value of 999 will be >> evaluated after a policy with a precedence value of 998. > > I don't think "time order" semantics will work very well. First of all, > it seems to assume that there are no side effects of a variable going > through a sequence of lower-precedence values before settling on the > highest-precedence value. Second, we talked at the last meeting about > having objects that control the frequency of policy evaluation on a > per-policy basis, so it doesn't seem right to assume that all policies > are evaluated at the same time, in order. Third, I'm concerned about > what happens when an element changes state and suddenly matches > a policyFilter - are we forced to rerun all higher precedence > policyActions? Finally, consider that a policyAction may affect multiple > variables - I think we want all of the variables to be set or none - > it wouldn't be cool to change only those that survive higher precedence > policies. > I did not reproduce the entire note here since the main points are above. In short, we are in agreement that we want to have objects that control the frequency of policy evaluation. I do not think what I propose requires that all policies be evaluated in order. The precedence value will work even if one policy is evaluated every minute while another that potentially conflicts with it is evaluated only once a day. Once evaluated, the information needed by the system to work is present. We can talk more in Pitts. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jul 27 14:33:42 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20750 for ; Thu, 27 Jul 2000 14:33:42 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA24379 for snmpconf-outgoing; Thu, 27 Jul 2000 14:12:19 -0400 (EDT) Message-ID: <39807B6B.B1A62A47@nextbeacon.com> Date: Thu, 27 Jul 2000 11:11:55 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Pointers from Policy MIB -> implementation-specificMIB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > 2. The PHB Table in the current DiffServ Policy MIB Module draft is not > instance/element specific. Many instances in a system might be configured > based on this 'template'. From the recently posted draft: That is not how my proposal would work. Using the example I gave earlier: diffPolicyPHBTable ID Descr TrafficID Action 37 "Mark SAP/R3 with DSCP 7" ptr to SAP 6tuple ptr to Mark command 51 ... policyFilter (type == interface) && roleMatch("Access") policyAction setint(diffPolicyPHBTarget.37, $1) Every time diffPolicyPHBTarget.37 is set to a value, it spits out a number of implementation-specific commands to the element specified by the value. So one entry in the PHB table above will control many interfaces. It is the policyFilter that decides which interfaces at any given moment. The implementation-specific MIB will act like this: Input Output set diffPolicyPHBTarget.37=5 set value A for interface 5 set value B for interface 5 set value C for interface 5 set value D for interface 5 set diffPolicyPHBTarget.37=8 set value A for interface 8 set value B for interface 8 set value C for interface 8 set value D for interface 8 So when one policyAction references one entry in the implementation-specific MIB, it actually does so for all N elements that the policy applies to. Further, other policies may also have references to the same entry in the impl-specific MIB. > diffPolicyPHBPolicy OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "When this MIB Module is used in conjunction with the Policy MIB Module, the > policyAction portion of the policy can contain a command to set this object > to the value of the pmPolicyIndex that will use the PHB definitions defined > in this row of the diffPolicyPHBTable. In the case where the policyAction > points to an entry in the diffPolicyPHBTable that already has a value for > this object, then the values from that row will be copied into a new row and > this value will be filled in with the pmPolicyIndex of the policy that > caused the creation of this row. When a policy is removed, all created rows > are to be deleted. When a policy is removed that did not create this row, > then this value shall be set to 0 indicating this row is not currently used > by any policy on the system." > ::= { diffPolicyPHBEntry xx } This is more complex and still suffers from a number of the problems I described earlier. Specifically I think that issues 1, 4, 5 (copied below) are still problems. Steve > > Then a policy action can contain a command to set this variable > > to 7 (for example), and cause the specified PHB to be applied to > > interface #7. > > > > For example: > > > > diffPolicyPHBTable > > ID Descr TrafficID Action > > 37 "Mark SAP/R3 with DSCP 7" ptr to SAP 6tuple ptr to Mark command > > 51 ... > > > > > > policyFilter > > (type == interface) && roleMatch("Access") > > policyAction > > setint(diffPolicyPHBTarget.37, $1) > > > > In other words, foreach interface that is access, set > > diffPolicyPHBTarget.3 to the ifindex of the interface. > > > > This is more in keeping with the original architecture we agreed > > upon some time ago (and re-affirmed at the last meeting, > > ref.: "Instance Dependent, Mechanism Independent Service"). > > > > Benefits over the RowPointer include: > > > > 1. Allows mid-level-manager implementations > > We would like to have MLM implementations where the policy > > evaluation happens on one machine which enforces policy on > > a number of systems in a sub-domain. Unfortunately, a > > RowPointer has significance only within an agent so it can't > > be used in an MLM implementation. > > > > 2. Avoids uncertainty over which executes, the script or rowpointer > > If the pmPolicyTable had both the rowPointer object as well as > > policyAction, it would be unclear what to do when both > > the RowPointer and the policyAction were set. > > > > 3. Allows conditionals to be used > > Since policyActions are scripts they can contain conditionals > > such as: > > if (capMatch("diffServ")) -- If diffserv is supported > > setint(diffPolicyPHBTarget.3, $1) > > else > > setint(802PolicyTarget.7, $1) > > -- i.e. 802 implementation-specific MIB > > > > A RowPointer wouldn't allow such a construct. > > > > 4. Allows service of implementation-specific MIB to be used > > independently of Policy MIB > > Allows any SNMP application to use the diffPolicyMIB to configure > > per-hop-behavior. > > > > 5. The RowPointer mechanism only allows actions on "this element". > > A fair amount of the time we will want to perform an action on > > an element related to "this element". Scripts will have the > > ability to follow these relationships and select the correct > > target address. > > > > > > Steve From owner-snmpconf@seymour39.SNMP.COM Mon Jul 31 16:12:09 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08083 for ; Mon, 31 Jul 2000 16:12:08 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA21341 for snmpconf-outgoing; Mon, 31 Jul 2000 15:50:18 -0400 (EDT) Message-Id: <200007311950.PAA21335@seymour39.SNMP.COM> to: snmpconf@snmp.com Subject: Re: snmpconf Interim meeting costs Date: Mon, 31 Jul 2000 15:50:16 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com [submission bounced due to address change forwarded.] --- Date: Mon, 31 Jul 2000 15:38:27 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf Interim meeting costs In-Reply-To: <39770292.886C13D8@mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I presume that the meeting will be occurring? Thanks, Joel At 09:45 AM 7/20/00 -0400, you wrote: >Hi, > >We need one or more sponsors to pick up the costs for the Pittsburgh >interim. The cost will be ~$2700. > >We need to advise the hotel who will be covering the costs soon. If we >do not get sponsors, we will need to cancel the meeting. > >Please let me know asap if your company will sponsor this meeting. > >Thanks, >dbh ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Mon Jul 31 16:46:06 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13639 for ; Mon, 31 Jul 2000 16:46:05 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA22949 for snmpconf-outgoing; Mon, 31 Jul 2000 16:30:11 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 31 Jul 2000 16:31:17 -0400 Subject: Re: snmpconf Interim meeting costs From: Jon Saperia To: Message-ID: In-Reply-To: <200007311950.PAA21335@seymour39.SNMP.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 07/31/2000 3:50 PM, Steve Moulton at moulton@snmp.com wrote: > > [submission bounced due to address change forwarded.] > > --- > Date: Mon, 31 Jul 2000 15:38:27 -0400 > To: snmpconf@snmp.com > From: "Joel M. Halpern" > Subject: Re: snmpconf Interim meeting costs > In-Reply-To: <39770292.886C13D8@mediaone.net> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > > I presume that the meeting will be occurring? > Thanks, > Joel > > At 09:45 AM 7/20/00 -0400, you wrote: >> Hi, >> >> We need one or more sponsors to pick up the costs for the Pittsburgh >> interim. The cost will be ~$2700. >> >> We need to advise the hotel who will be covering the costs soon. If we >> do not get sponsors, we will need to cancel the meeting. >> >> Please let me know asap if your company will sponsor this meeting. >> >> Thanks, >> dbh > > > ------- End of Forwarded Message > Yes, as far as I know the meeting is on. Dave Harrington - what is the status. /jon