From owner-snmpconf@seymour39.SNMP.COM Mon May 1 01:38: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 BAA14380 for ; Mon, 1 May 2000 01:38:33 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id BAA16172 for snmpconf-outgoing; Mon, 1 May 2000 01:18:35 -0400 (EDT) Message-Id: <4.3.0.20000430221909.03d22f08@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 30 Apr 2000 22:22:33 -0700 To: snmpconf@snmp.com From: Michael MacFaden Subject: snmpconf Fwd: Re: external access and passwd mgmt (was Re: SSH on Cisco ...) 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 Thought this was timely and worth the cross post. Building the "confidence" is the key part....they want the functionality but fear not knowing what it might do... Mike >Delivered-To: nanog-outgoing@merit.edu >Date: Sun, 30 Apr 2000 17:33:44 -0400 >From: Bennett Todd >To: nanog@merit.edu >Subject: Re: external access and passwd mgmt (was Re: SSH on Cisco ...) >X-Mailer: Mutt 1.0i >Sender: owner-nanog@merit.edu >X-Loop: nanog > > >Content-Type: text/plain; charset=us-ascii > > >*** PGP Signature Status: unknown >*** Signer: Unknown, Key ID = 0xCE34B136 >*** Signed: 4/30/2000 2:33:44 PM >*** Verified: 4/30/2000 10:17:54 PM >*** BEGIN PGP VERIFIED MESSAGE *** > >2000-04-30-17:16:41 Sean Donelan: > > Folks seem to be concentrating on locking down the front door. > > You also need to watch all the backdoors. With multi-protocol > > equipment, there are a lot of backdoors. > >Excellent point. > >Personally I think it's easier to balkanize than to really secure. >So use access lists so telnet access is either entirely disabled, or >if it's needed is restricted to the local LAN. Restrict all >questionable services to the local LAN, making sure there's a >bastion on that LAN, and use ingress/egress filtering wherever >possible to break address forging between LANs. > >What this turns up is that it's exceptionally helpful if you can >have a really solid bastion host on every LAN. Fortunately, that >doesn't have to be too hard. I _still_ wish someone would make e.g. >a PCI card with say 32 or 64 10BaseT ports on it, but a civilized >approximation for many purposes is a nice 100Mbps port talking >802.1Q VLANs to a switch dedicated to this purpose. > >But back to the wealth of possible, worrisome backdoors in modern >multiprotocol gear, what are people doing to try and get a grip on >config management for piles and stacks of Cisco? (my apologies if >this thread has already been pounded to death, I just joined). Seems >to me like a lot could be done with some simple m4 work, but so far >a lot of the parameterizing I'd like to achieve (e.g. interfaces, >access-list rules) has evaded me. The fantasy of course would be to >get hip to a new thought --- a new kind of filtering you want to add >to your access lists, or whatever --- and do it in one place, with >the confidence that it'll take effect on every box it applies to. >The distribution I can handle, it's the structured config management >that's evading me. > >-Bennett > > >*** END PGP VERIFIED MESSAGE *** From owner-snmpconf@seymour39.SNMP.COM Fri May 5 07:05: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 HAA13889 for ; Fri, 5 May 2000 07:05:34 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA01060 for snmpconf-outgoing; Fri, 5 May 2000 06:41:55 -0400 (EDT) Message-Id: <200005051041.GAA13388@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-01.txt Date: Fri, 05 May 2000 06:41:20 -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-01.txt Pages : 17 Date : 04-May-00 Data networks have grown greatly in size and complexity over the past decade. Configuration (provisioning) of network elements has grown correspondingly more complex. Complexity in the context of this document means specifically: 1) Scale - data networks consist of more devices than ever 2) Functionality - network devices increasingly perform more functions 3) Convergence - more devices involved and different levels of the stack are affected during configuration changes causing lost connectivity for some period of time The SNMP framework can and has been used to develop configuration management systems. This document describes Best Current Practices that SHOULD be used when designing and effective SNMP-based management system that includes configuration functions, or is an SNMP-based system that has only configuration functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-01.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-01.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-01.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: <20000504125058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-bcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-bcp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000504125058.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Fri May 5 08:44: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 IAA17047 for ; Fri, 5 May 2000 08:44:49 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA03285 for snmpconf-outgoing; Fri, 5 May 2000 08:29:18 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 05 May 2000 08:28:45 -0400 Subject: snmpconf Additional Agenda Details for SNMPCONF Interim Meeting, May 17 - 19 From: Jon Saperia To: snmpconf , Bert Wijnen , Randy Bush 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 are some additional details about the agenda and background reading for our meeting in San Francisco: Day 1 - Wednesday May 17 9am - 6pm Meeting Logistics and administrivia Agenda Discussion Background Presentation for the SNMPCONF Work - How the pieces fit together. Policy MIB Module issues Follow-up Actions review Day 2 - Thursday May 18 9am - 6pm Remaining Policy MIB Module discussions Differentiated Services Policy MIB Module Relationship to the Qos Device Policy Model Follow-Up actions Review Day 3 - Friday May 19 9am - 3pm Remaining Differentiated Services Policy MIB Module Issues Best Current Practices Document Agent Issues Management Software Issues Wrap-up and Close. Additional Agenda Topics - The agenda will be reviewed when we start. There were issues raised at our WG meeting in Adelaide (for example Multiple Manager Interactions, Filter/Action Expressions, PolicyType and subType Definition, Conflict Detection, Conflict Resolution and relationship to other work). Before each of the three days, we will work on the open issues list for that particular topic area - to be developed by the discussion leader for each of the three days. If there are specific topics or presentations that anyone would like to request, please post them to the list. Background reading and document publication status: The revised Policy MIB Module is still undergoing revision. Steve Waldbusser will publish it to this list and send off to the ID people no later than Tuesday afternoon May 9th. The Best Current Practices revision was submitted yesterday and while a significant amount of data has been added, it is not yet complete. For your convenience: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-01.txt The revisions for the Differentiated Services Policy MIB Module were published a while ago: A URL for this Internet-Draft is: http://ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-01.txt As general preparation for the meeting and to help understand the Differentiated Services Policy MIB Module, it is also suggested that the following two documents be read prior to the meeting: http://ietf.org/internet-drafts/draft-ietf-policy-core-info-model-05.txt http://ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-00.t xt Happy Reading, see you at 9:00 am on May 17th. /jon From owner-snmpconf@seymour39.SNMP.COM Tue May 9 12:46:38 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24987 for ; Tue, 9 May 2000 12:46:38 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA25720 for snmpconf-outgoing; Tue, 9 May 2000 12:21:03 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 09 May 2000 12:20:40 -0400 Subject: snmpconf Hotel Confirmations for the Interim Meeting 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 Hi everyone, I would appreciate it if you would email me a yes if you have registered at the Sir Francis Drake hotel for the interim meeting. The list I got from them did not seem complete. I want to make sure that everyone has been correctly registered under the IETF group. Thanks /jon P.S. - we are still looking for a corporate sponsor for the coffee and afternoon break. From owner-snmpconf@seymour39.SNMP.COM Tue May 9 13:03:21 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25480 for ; Tue, 9 May 2000 13:03:20 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA26477 for snmpconf-outgoing; Tue, 9 May 2000 12:46:01 -0400 (EDT) Message-ID: <39184103.41BCC3E6@ins.com> Date: Tue, 09 May 2000 09:46:59 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Hotel Confirmations for the Interim Meeting 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 have registered at the hotel. Steve Jon Saperia wrote: > > Hi everyone, I would appreciate it if you would email me a yes if you have > registered at the Sir Francis Drake hotel for the interim meeting. The list > I got from them did not seem complete. I want to make sure that everyone has > been correctly registered under the IETF group. > > Thanks > /jon > > P.S. - we are still looking for a corporate sponsor for the coffee and > afternoon break. From owner-snmpconf@seymour39.SNMP.COM Tue May 9 13:51: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 NAA26311 for ; Tue, 9 May 2000 13:51:41 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA27599 for snmpconf-outgoing; Tue, 9 May 2000 13:35:05 -0400 (EDT) Message-ID: <39184D0E.348B52F4@cisco.com> Date: Tue, 09 May 2000 10:38:22 -0700 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Hotel Confirmations for the Interim Meeting References: <15F58915DF84D311AC7D0090279AA61412836B@ITC-EML2> 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 Dan Romascanu wrote: > > yes, I have registered at the Sir Francis Drake hotel for the meeting - > starting with May 14 (as I will attend first the RMON WG meeting). > ditto > Regards, > > Dan Romascanu Andy > > > -----Original Message----- > > From: Jon Saperia [SMTP:saperia@mediaone.net] > > Sent: Tue May 09 2000 18:21 > > To: snmpconf > > Subject: snmpconf Hotel Confirmations for the Interim Meeting > > > > Hi everyone, I would appreciate it if you would email me a yes if you have > > registered at the Sir Francis Drake hotel for the interim meeting. The > > list > > I got from them did not seem complete. I want to make sure that everyone > > has > > been correctly registered under the IETF group. > > > > Thanks > > /jon > > > > P.S. - we are still looking for a corporate sponsor for the coffee and > > afternoon break. From owner-snmpconf@seymour39.SNMP.COM Tue May 9 13:54: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 NAA26346 for ; Tue, 9 May 2000 13:54:38 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA27429 for snmpconf-outgoing; Tue, 9 May 2000 13:28:10 -0400 (EDT) Message-ID: <15F58915DF84D311AC7D0090279AA61412836B@ITC-EML2> From: Dan Romascanu To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Hotel Confirmations for the Interim Meeting Date: Tue, 9 May 2000 20:26:16 +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 yes, I have registered at the Sir Francis Drake hotel for the meeting - starting with May 14 (as I will attend first the RMON WG meeting). Regards, Dan Romascanu > -----Original Message----- > From: Jon Saperia [SMTP:saperia@mediaone.net] > Sent: Tue May 09 2000 18:21 > To: snmpconf > Subject: snmpconf Hotel Confirmations for the Interim Meeting > > Hi everyone, I would appreciate it if you would email me a yes if you have > registered at the Sir Francis Drake hotel for the interim meeting. The > list > I got from them did not seem complete. I want to make sure that everyone > has > been correctly registered under the IETF group. > > Thanks > /jon > > P.S. - we are still looking for a corporate sponsor for the coffee and > afternoon break. From owner-snmpconf@seymour39.SNMP.COM Tue May 9 17:34: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 RAA01298 for ; Tue, 9 May 2000 17:34:32 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA03708 for snmpconf-outgoing; Tue, 9 May 2000 17:16:27 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB072945CF@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Subject: RE: snmpconf Hotel Confirmations for the Interim Meeting Date: Tue, 9 May 2000 23:15:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Yep, I have registered at the hotel, starting May 14th 5 nights Bert From owner-snmpconf@seymour39.SNMP.COM Tue May 9 20: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 UAA03392 for ; Tue, 9 May 2000 20:52:06 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id UAA07954 for snmpconf-outgoing; Tue, 9 May 2000 20:35:15 -0400 (EDT) Message-ID: <3918ADFB.7859A1F2@riverstonenet.com> Date: Tue, 09 May 2000 17:31:55 -0700 From: "Michael R. MacFaden" Organization: Riverstone Networks , Inc X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Hotel Confirmations for the Interim Meeting 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'll be there wed/friday with the projector and have reserved a room in the hotel. Hongal just called and is flying back now. We'll probably share the room. Mike From owner-snmpconf@seymour39.SNMP.COM Wed May 10 01:44: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 BAA12714 for ; Wed, 10 May 2000 01:44:35 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id BAA20521 for snmpconf-outgoing; Wed, 10 May 2000 01:25:13 -0400 (EDT) Message-ID: <3918F2DF.6E85DAA2@ins.com> Date: Tue, 09 May 2000 22:25:51 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: snmpconf New draft of Policy Based Management MIB Content-Type: multipart/mixed; boundary="------------D5BF5198608C6C316EC3FDE6" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This is a multi-part message in MIME format. --------------D5BF5198608C6C316EC3FDE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's a new draft of the Policy Based Management MIB. Quite a lot has been added. Please review for next weeks meeting. Steve --------------D5BF5198608C6C316EC3FDE6 Content-Type: text/plain; charset=us-ascii; name="a" Content-Disposition: inline; filename="a" Content-Transfer-Encoding: 7bit Internet Draft Policy-Based Management MIB May 8, 2000 Policy Based Management MIB draft-ietf-snmpconf-pm-01.txt May 8, 2000 Steve Waldbusser Jon Saperia Thippanna Hongal Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 1. Abstract 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 Various Authors Expires November 8, 2000 [Page 1] Internet Draft Policy-Based Management MIB May 8, 2000 infrastructures. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [18]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. Various Authors Expires November 8, 2000 [Page 2] Internet Draft Policy-Based Management MIB May 8, 2000 This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Various Authors Expires November 8, 2000 [Page 3] Internet Draft Policy-Based Management MIB May 8, 2000 3. Overview Large IT organizations have developed management strategies to cope with the extraordinarily large scale inherent in large networks. In particular, they try to manage the network as a whole by describing and implementing high-level business policies, rather than managing device by device, where orders of magnitude more decisions (and mistakes) may be made. Following this management practice results in the following benefits: - Reduced training needs (fewer details to learn) - Reduced documentation costs (fewer details to document) - Reduced impact of turnover (less ad-hoc knowledge goes out the door) - Greater testability (a greater percentage of fielded configurations may be tested in the lab) - Higher reliability (combination of factors above) - Lower cost of changes (changes can be simpler and operate over a wider extent) - Lower cost of corporate mergers (less knowledge to transfer; fewer policies to integrate) - Lower cost of ownership (combination of factors above) To illustrate the concept of "business policies", some examples are: - All routers will run code version 6.2 - On-site contracters will all have special security restrictions on their ports - All voice over cable ports in California must provide free local calling - Apply special forwarding to all ports whose customers have paid for premium service. Each of these policies could represent an action applied to hundreds of thousands of configuration variables. In order to automate this practice, customers need software tools that will implement business policies across their network, as well as a standard protocol that will ensure that it can be applied to all of their devices, regardless of the vendor. This practice is called Policy-Based Network Management. This document defines standard managed objects for the Simple Network Management Protocol that are used to distribute policies in a standard form throughout the network. Various Authors Expires November 8, 2000 [Page 4] Internet Draft Policy-Based Management MIB May 8, 2000 4. Policy-Based Network Management Architecture Policy-based network management is the practice of applying management operations globally on all managed objects that share certain attributes. Policies always express a notion of: if (an object has certain characteristics) then (apply operation to that object) Policies take the following normal form: if (policyFilter) then (policyAction) A policyFilter is an expression which results in a boolean to determine whether or not an object is a member of a set of objects upon which an action is to be performed. A policyAction is an operation performed on a set of objects. These policies are executed on managed devices, where the objects live (and thus their characteristics may be easily inspected), and where operations on those objects will be performed. A management station is responsible for distributing an organization's policies to all of the managed devices in the infrastructure. The pmPolicyTable provides managed objects for sending a policy to a managed device. In this architecture, the objects that policies act on are called elements. An element is a group of related MIB variables such as all the variables for interface #7. This enables policies to be expressed more efficiently and concisely. Elements can also model circuits, CPUs, queues, processes, systems, etc. The execution model for policies on a managed device is: foreach element for which policyFilter returns true execute policyAction on that element For example: If (interface is fast ethernet) then (apply full-duplex mode) If (interface is access) then (apply security filters) If (gold service paid for on circuit) then (apply special queueing) Various Authors Expires November 8, 2000 [Page 5] Internet Draft Policy-Based Management MIB May 8, 2000 PolicyFilters have the capability of performing comparison operations on SNMP variables, logical expressions, and other functions. Many device characteristics are already defined in MIBs and are easy to include in policyFilter expressions (ifType == ethernet, frCircuitCommittedBurst < 128K, etc). However, there are important characteristics that aren't currently in MIB objects, and worse, it is not current practice to store this information on managed devices. Therefore, this document defines MIB objects for this information. To meet today's needs there are three missing areas: roles, capabilities and time. Roles A role is an abstract characteristic assigned to an element that expresses a notion, such as a political, financial, legal, geographical, or architectural attribute, typically not directly derivable from information stored on the managed system. For example, "paid for premium service" or "is plugged into a UPS" are examples of roles, whereas the percent utilization of a link would not be. The types of information one would put into a role are: political - describes the role of a person or group of people, or of a service that a group of people use. Examples: executive, sales, outside-contracter, customer. If (attached user is executive) then (apply higher bandwidth) If (attached user is outside-contracter) then (restrict access) financial/legal - describes what financial consideration was received. Could also include contractual or legal considerations. Examples: paid, gold, free, trial, demo, lifeline (The lifeline example is supposed to model the RBOC's legal obligation to provide dial tone to elderly/poor). If (gold service paid for) then (apply special queueing) geographical - describes the location of an element. Examples: California, Headquarters, insecure conduit. If (interface leaves the building) then (apply special security) architectural - describes the network architects "intent" for an element. For example: backup, trunk. If (interface is backup) then (set ifAdminStatus = down) Various Authors Expires November 8, 2000 [Page 6] Internet Draft Policy-Based Management MIB May 8, 2000 Collectively, these 4 classes of characteristics are called roles. Roles are human defined strings that can be referenced by a policyFilter. Multiple roles may be assigned to each element. Capabilities Some actions are inappropriate for certain elements or are simply unsupported. PolicyFilter's must be able to be defined so that a policy can be applied only to elements that have the proper capability. The capabilities table provides MIB objects that describe the capabilities of the system. Time Managers may wish to define policies that are true for certain periods of time. This might mean that a policy is downloaded and is dormant for a period of time, becomes active, and then later becomes inactive. Sometimes these time periods will be regular (M-F 9-5) and sometimes ad-hoc. This MIB provides MIB objects that allow policies to be dependent on time. 5. Policy Based Management Expression Language Policy filters and policy actions are expressed with the policy expression language. This expression language provides the power to make parenthesized logical and arithmetic comparisons and to call a number of pre-defined functions. The policy expression language is a subset of ANSI C [19] that is limited to expressions. Some examples of the features that have been removed are: function definitions, local variables, assignments, pointers (except for constant pointers used for strings), arrays, structures, floating point and pre-processor functions. The policy expression language is defined in this standard by reference to ANSI C, but only allows those constructs that may be expressed in the BNF documented here. This is done because while BNF doesn't fully specify syntactical rules (it allows constructs that are invalid) and doesn't specify semantic rules, it can successfully be used to define the subset of ANSI C that is required for conformance to this standard. Various Authors Expires November 8, 2000 [Page 7] Internet Draft Policy-Based Management MIB May 8, 2000 5.1. Formal Definition The policy expression language follows the syntax and semantics of ANSI C [19], but expressions are limited to those that can be expressed in the following EBNF form: identifier : ascii_char ( ascii_char | digit )* string : '"' ascii_char* '"' expression : const_exp ( ';' const_exp )* const_exp : compound_exp | conditional_exp conditional_exp : const_exp '?' const_exp ':' const_exp binary_operator : '*' | '/' | '%' | '+' | '-' | '<<' | '>>' | '<' | '>' | '<=' | '>=' | '==' | '!=' | '&' | '^' | '|' | '&&' | '||' compound_exp : unary_exp (binary_operator unary_exp)* unary_exp : integer | char | string | functioncall | '(' unary_exp ')' | unary_operator unary_exp unary_operator : '+' | '-' | ' | '!' functioncall : identifier '(' arg_exp_list? ')' arg_exp_list : const_exp ( ',' const_exp )* -- For reference ascii_char : Any ascii character digit : '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' hexdigit : digit | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' decimal : digit+ integer : decimal | ( '0' 'x' hexdigit+ ) Various Authors Expires November 8, 2000 [Page 8] Internet Draft Policy-Based Management MIB May 8, 2000 char : ( ''' ascii_char ''' ) | ( ''' '' decimal ''' ) 5.2. Accessor Functions Several functions are available to provide access to information on the local system. No functions are available except for those described here. 5.2.1. getint() The getint() function is used to retrieve the value of an SNMP MIB instance. int getint(char *objectIdentifier) objectIdentifier is a NULL terminated string containing an ASCII dotted-decimal representation of an object identifier (e.g. 1.3.6.1.2.1.1.1.0). The 2-character token "$1" can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the index value of each element the expression acts upon. The agent will retrieve the instance in the same SNMP context in which the element resides. Note that no actual SNMP PDU needs to be generated and parsed when the policy MIB module resides on the same system as the managed elements. If the queried object identifier value does not exist or is not an integer-valued object, execution of the containing expression on the current element will immediately terminate and the associated policyAction will not be executed on the current element. This function returns the value of the integer-valued MIB instance. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values followed by the index in dotted-decimal form (e.g., "ifType.7). Various Authors Expires November 8, 2000 [Page 9] Internet Draft Policy-Based Management MIB May 8, 2000 5.2.2. getstring() The getstring() function is used to retrieve the value of an SNMP MIB instance. char * getstring(char *objectIdentifier) objectIdentifier is a NULL terminated string containing an ASCII dotted-decimal representation of an object identifier (e.g. 1.3.6.1.2.1.1.1.0). The 2-character token "$1" can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the index value of each element the expression acts upon. The agent will retrieve the instance in the same SNMP context in which the element resides. Note that no actual SNMP PDU needs to be generated and parsed when the policy MIB module resides on the same system as the managed elements. If the queried object identifier value does not exist or is not a string-valued or object-identifier-valued object, execution of the containing expression on the current element will immediately terminate and the associated policyAction will not be executed on the current element. This function returns a string containing the value of string-valued MIB instances or the ASCII dotted-decimal representation of object-identifier-valued instances. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values followed by the index in dotted-decimal form (e.g., "ifType.7). 5.2.3. exists() The exists() function is used to verify the existence of an SNMP MIB instance. int exists(char *objectIdentifier) objectIdentifier is a NULL terminated string containing an ASCII dotted-decimal representation of an object identifier Various Authors Expires November 8, 2000 [Page 10] Internet Draft Policy-Based Management MIB May 8, 2000 (e.g. 1.3.6.1.2.1.1.1.0). The 2-character token "$1" can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the index value of each element the expression acts upon. The agent will retrieve the instance in the same SNMP context in which the element resides. Note that no actual SNMP PDU needs to be generated and parsed when the policy MIB module resides on the same system as the managed elements. This function returns the value 1 if the SNMP instance exists and 0 if it doesn't exist. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values followed by the index in dotted-decimal form (e.g., "ifType.7). 5.2.4. elementName() The elementName() function is used to determine what the current element is and can be used to provide information about the type of element as well as how it is indexed. char * elementName(void) elementName returns a NULL terminated string containing an ASCII dotted-decimal representation of an object identifier (e.g. 1.3.6.1.2.1.1.1.0). This object identifier identifies an instance of a MIB object that is an attribute of this element. 5.2.5. strcmp() The strcmp() function is used to compare two strings. int strcmp(char *s1, char *s2) Arguments s1 and s2 are NULL terminated strings. Returns -1 if s1 is lexicographically less than s2. Returns 1 if s1 is lexicographically greater than s2. Various Authors Expires November 8, 2000 [Page 11] Internet Draft Policy-Based Management MIB May 8, 2000 Returns 0 if s1 and s2 are equal. 5.2.6. lc_strcmp() The lc_strcmp() function is used to compare two strings. int lc_strcmp(char *s1, char *s2) Arguments s1 and s2 are NULL terminated strings that are translated into lower case strings lc1 and lc2. Then: Returns -1 if lc1 is lexicographically less than lc2. Returns 1 if lc1 is lexicographically greater than lc2. Returns 0 if lc1 and lc2 are equal. 5.2.7. roleMatch() The roleMatch() function is used to check to see if the current element has been assigned a particular role. int roleMatch(char *roleString) Argument roleString is a NULL terminated string. If this exactly matches (content and length) any role assigned to the current element, the function returns 1. If no roles match, the function returns 0. 5.2.8. capMatch() The capMatch() function is used to check to see if the current element has a certain capability. int capMatch(char *capString) Argument capability is a NULL terminated string containing a ASCII dotted-decimal representation of an object identifier that describes a capability as would be found in the pmCapabilitiesTable. If the current element has the capability described by capString, this function returns 1, otherwise it returns 0. Various Authors Expires November 8, 2000 [Page 12] Internet Draft Policy-Based Management MIB May 8, 2000 5.2.9. setint() The setint() function is used to set a MIB instance to a certain integer value. The setint() function is only valid in policyActions. If when executing a policyFilter, the agent encounters a call to the setint() function, execution of the policyFilter for the current element will immediately terminate and the associated policyAction will not be executed on the current element. int setint(char *objectIdentifier, int value) objectIdentifier is a NULL terminated string containing an ASCII dotted-decimal representation of an object identifier (e.g. 1.3.6.1.2.1.1.1.0). The 2-character token "$1" can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the index value of each element the expression acts upon. The agent will set the variable specified by objectIdentifier to the value specified by value. The agent will set the instance in the same SNMP context in which the element resides. Note that no actual SNMP PDU needs to be generated and parsed when the policy MIB module resides on the same system as the managed elements. If the queried object identifier value does not exist and cannot be created or is not an integer-valued object, 0 is returned. If successful, 1 is returned. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values followed by the index in dotted-decimal form (e.g., "ifType.7). 5.2.10. setstring() The setstring() function is used to set a MIB instance to a certain string value. The setstring() function is only valid in policyActions. If when executing a policyFilter, the agent encounters a call to the setstring() function, execution of the policyFilter for the current element will immediately terminate and the associated policyAction will not be executed Various Authors Expires November 8, 2000 [Page 13] Internet Draft Policy-Based Management MIB May 8, 2000 on the current element. int setstring(char *objectIdentifier, char *value) objectIdentifier is a NULL terminated string containing an ASCII dotted-decimal representation of an object identifier (e.g. 1.3.6.1.2.1.1.1.0). The 2-character token "$1" can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the index value of each element the expression acts upon. value is a NULL terminated string containing a sequence of bytes. The agent will set the variable specified by objectIdentifier to the value specified by value. The agent will set the instance in the same SNMP context in which the element resides. Note that no actual SNMP PDU needs to be generated and parsed when the policy MIB module resides on the same system as the managed elements. If the queried object identifier value does not exist and cannot be created or is not a string-valued object, 0 is returned. If successful, 1 is returned. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values followed by the index in dotted-decimal form (e.g., "ifType.7). 5.2.11. setoid() The setoid() function is used to set a MIB instance to a certain object identifier value. The setoid() function is only valid in policyActions. If when executing a policyFilter, the agent encounters a call to the setoid() function, execution of the policyFilter for the current element will immediately terminate and the associated policyAction will not be executed on the current element. int setoid(char *objectIdentifier, int value) objectIdentifier is a NULL terminated string containing an ASCII dotted-decimal representation of an object identifier (e.g. 1.3.6.1.2.1.1.1.0). Various Authors Expires November 8, 2000 [Page 14] Internet Draft Policy-Based Management MIB May 8, 2000 The 2-character token "$1" can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the index value of each element the expression acts upon. The agent will set the instance in the same SNMP context in which the element resides. Note that no actual SNMP PDU needs to be generated and parsed when the policy MIB module resides on the same system as the managed elements. If the queried object identifier value does not exist and cannot be created or is not an object-identifier-valued object, 0 is returned. If successful, 1 is returned. It is recommended that NMS user interfaces display and allow input of MIB object names by their descriptor values followed by the index in dotted-decimal form (e.g., "ifType.7). Various Authors Expires November 8, 2000 [Page 15] Internet Draft Policy-Based Management MIB May 8, 2000 6. Definitions POLICY-MANAGEMENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32, experimental FROM SNMPv2-SMI RowStatus, RowPointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- Policy-Based Management MIB policyMgt MODULE-IDENTITY LAST-UPDATED "200005081500Z" -- May 8, 2000 ORGANIZATION "IETF SNMP Configuration Working Group" CONTACT-INFO "Steve Waldbusser Lucent Technologies 1213 Innsbruck Dr. Sunnyvale, CA 94089 USA Phone: +1-650-318-1251 Fax: +1-650-318-1633 Email: waldbusser@lucent.com Jon Saperia JDS Consulting, Inc. 174 Chapman St. Watertown MA 02472-3063 USA Phone: +1-617-744-1079 Fax: +1-617-249-0874 Email: saperia@jdscons.com Thippanna Hongal Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA, 95054 USA Phone: +1-408-878-6562 Fax: +1-408-878-6501 Email: hongal@riverstonenet.com" DESCRIPTION "The MIB module for rule-based configuration of SNMP Various Authors Expires November 8, 2000 [Page 16] Internet Draft Policy-Based Management MIB May 8, 2000 infrastructures." REVISION "200005081500Z" -- May 8, 2000 DESCRIPTION "The original version of this MIB, published as RFCXXXX." ::= { experimental 99 } -- The policy group pmPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The policy table. A policy is a pairing of a policyFilter and a policyAction which is used to apply the action to a selected set of objects." ::= { policyMgt 1 } pmPolicyEntry OBJECT-TYPE SYNTAX PmPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the policy table." INDEX { pmPolicyIndex } ::= { pmPolicyTable 1 } PmPolicyEntry ::= SEQUENCE { pmPolicyIndex Integer32, pmPolicyFilter OCTET STRING, pmPolicyCalendar RowPointer, pmPolicyAction OCTET STRING, pmPolicyDescription SnmpAdminString, pmPolicyMatches Gauge32, pmPolicyStatus RowStatus } pmPolicyIndex OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this policy entry." ::= { pmPolicyEntry 1 } Various Authors Expires November 8, 2000 [Page 17] Internet Draft Policy-Based Management MIB May 8, 2000 pmPolicyFilter OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..65535)) MAX-ACCESS read-create STATUS current DESCRIPTION "A policyFilter is an expression which results in a boolean value which represents whether or not an element is a member of a set of elements upon which an action is to be performed. The format of this expression is the policy expression language. The policyFilter is evaluated for various objects. Any object for which the policyFilter returns any nonzero value will match the filter and will have the associated policyAction executed on that object." ::= { pmPolicyEntry 2 } pmPolicyCalendar OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "A pointer to an entry in the schedTable of the Scheduling MIB [20]. This policy is active when specified by the associated schedule entry. If the value of this object is 0.0, this policy is always active." ::= { pmPolicyEntry 3 } pmPolicyAction OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "A pmPolicyAction is an operation performed on a set of elements. The format of this expression is the " ::= { pmPolicyEntry 4 } pmPolicyDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION Various Authors Expires November 8, 2000 [Page 18] Internet Draft Policy-Based Management MIB May 8, 2000 "A description of this rule and its significance, typically provided by a human." ::= { pmPolicyEntry 5 } pmPolicyMatches OBJECT-TYPE SYNTAX Gauge32 UNITS "elements" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of policies that are currently matched by the associated pmPolicyFilter." ::= { pmPolicyEntry 6 } pmPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this pmPolicyEntry." ::= { pmPolicyEntry 7 } -- roleTable -- The Role Table associates role strings to elements. It is the -- responsibility of the agent to keep track of any re-indexing of the -- underlying SNMP variables and to continue to associate role strings -- with the element with which they were initially configured. -- -- The agent must store role string associations in NVRAM. -- -- The Role String table is visible through 2 SNMP tables. The -- pmRoleESTable is a read-create table that organized role strings -- sorted by element. This table is used to create and modify role -- strings and their associations. -- The pmRoleSETable is a read-only table that organizes role strings -- sorted by string. This table is read-only. pmRoleESTable OBJECT-TYPE SYNTAX SEQUENCE OF PmRoleESEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The role string table with element as the major index." ::= { policyMgt 2 } Various Authors Expires November 8, 2000 [Page 19] Internet Draft Policy-Based Management MIB May 8, 2000 pmRoleESEntry OBJECT-TYPE SYNTAX PmRoleESEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A role string entry associates a role string with an individual element." INDEX { pmRoleESElement, pmRoleESString } ::= { pmRoleESTable 1 } PmRoleESEntry ::= SEQUENCE { pmRoleESElement RowPointer, pmRoleESString SnmpAdminString, pmRoleESStatus RowStatus } pmRoleESElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "The element to which this role string is associated. If the agent assigns new indexes in the MIB table to represent the same underlying element (re-indexing), the agent will modify this value to contain the new index for the underlying element." ::= { pmRoleESEntry 1 } pmRoleESString OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The role string that is associated with an element through this table." ::= { pmRoleESEntry 2 } pmRoleESStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this role string." ::= { pmRoleESEntry 3 } Various Authors Expires November 8, 2000 [Page 20] Internet Draft Policy-Based Management MIB May 8, 2000 pmRoleSETable OBJECT-TYPE SYNTAX SEQUENCE OF PmRoleSEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A read-only version of the role string table with roleString as the major index. The purpose of this table is to make it easy to retrieve all elements that share a common string." ::= { policyMgt 3 } pmRoleSEEntry OBJECT-TYPE SYNTAX PmRoleSEEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A role string entry associates a role string with an individual element." INDEX { pmRoleSEString, pmRoleSEElement } ::= { pmRoleSETable 1 } PmRoleSEEntry ::= SEQUENCE { pmRoleSEString SnmpAdminString, pmRoleSEElement RowPointer } pmRoleSEString OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The role string that is associated with an element through this table." ::= { pmRoleSEEntry 1 } pmRoleSEElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "The element to which this role string is associated. If the agent assigns new indexes in the MIB table to represent the same underlying element (re-indexing), the agent will modify this value to contain the new index for the Various Authors Expires November 8, 2000 [Page 21] Internet Draft Policy-Based Management MIB May 8, 2000 underlying element." ::= { pmRoleSEEntry 2 } pmConformance OBJECT IDENTIFIER ::= { policyMgt 20 } pmCompliances OBJECT IDENTIFIER ::= { pmConformance 1 } pmGroups OBJECT IDENTIFIER ::= { pmConformance 2 } -- capabilities table pmCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF PmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmCapabilitiesTable contains a description of the inherent capabilities of the system." ::= { policyMgt 4 } pmCapabilitiesEntry OBJECT-TYPE SYNTAX PmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The description of a capability of the system." INDEX { pmCapabilitiesIndex } ::= { pmCapabilitiesTable 1 } PmCapabilitiesEntry ::= SEQUENCE { pmCapabilitiesIndex Integer32, pmCapabilitiesType OBJECT IDENTIFIER } pmCapabilitiesIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this entry." ::= { pmCapabilitiesEntry 1 } pmCapabilitiesType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION Various Authors Expires November 8, 2000 [Page 22] Internet Draft Policy-Based Management MIB May 8, 2000 "The type of the capability represented by this entry. The IANA will publish the list of identifiers that are valid values for this object." ::= { pmCapabilitiesEntry 2 } -- Policy Tracking pmTrackingPolicyToElementTable OBJECT-TYPE SYNTAX SEQUENCE OF PmTrackingPolicyToElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmTrackingPolicyToElementTable describes what elements are under control of a policy." ::= { policyMgt 5 } pmTrackingPolicyToElementEntry OBJECT-TYPE SYNTAX PmTrackingPolicyToElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmTrackingPolicyToElementTable." INDEX { pmPolicyIndex, pmTrackingPolicyToElementElement } ::= { pmTrackingPolicyToElementTable 1 } PmTrackingPolicyToElementEntry ::= SEQUENCE { pmTrackingPolicyToElementElement RowPointer, pmTrackingPolicyToElementStatus INTEGER } pmTrackingPolicyToElementElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "The element this policy is configuring." ::= { pmTrackingPolicyToElementEntry 1 } pmTrackingPolicyToElementStatus OBJECT-TYPE SYNTAX INTEGER { off(0), on(1) } MAX-ACCESS read-only STATUS current Various Authors Expires November 8, 2000 [Page 23] Internet Draft Policy-Based Management MIB May 8, 2000 DESCRIPTION "The status of this policy-element relationship. This value will be 1 if the associated policyFilter returned 1 for this element and if the calendar for the policy is active. Entries will only exist in this table if their status is on(1). Thus, on(1) is the only value of this object that can be retrieved. This object exists so that it can serve as the 'payload' in the varbind instead of the pmTrackingPolicyToElementElement object which is much longer and is already in the index (it would otherwise be duplicated)." ::= { pmTrackingPolicyToElementEntry 2 } -- Element to Policy Table pmTrackingElementToPolicyTable OBJECT-TYPE SYNTAX SEQUENCE OF PmTrackingElementToPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmTrackingElementToPolicyTable describes what policies are controlling an element." ::= { policyMgt 6 } pmTrackingElementToPolicyEntry OBJECT-TYPE SYNTAX PmTrackingElementToPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmTrackingElementToPolicyTable." INDEX { pmTrackingElementToPolicyElement, pmPolicyIndex } ::= { pmTrackingElementToPolicyTable 1 } PmTrackingElementToPolicyEntry ::= SEQUENCE { pmTrackingElementToPolicyElement RowPointer, pmTrackingElementToPolicyStatus INTEGER } pmTrackingElementToPolicyElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "The element this policy is configuring." Various Authors Expires November 8, 2000 [Page 24] Internet Draft Policy-Based Management MIB May 8, 2000 ::= { pmTrackingElementToPolicyEntry 1 } pmTrackingElementToPolicyStatus OBJECT-TYPE SYNTAX INTEGER { off(0), on(1), forceOff(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The status of this policy-element relationship. This value will be 1 if the associated policyFilter returned 1 for this element and if the calendar for the policy is active. Entries will not exist in this table if their status would be off(0). A policy can be forcibly disabled on a particular interface by setting this value to forceOff(2). The agent should then act as if the policyFilter failed for this element. The forceOff(2) state will persist (even across reboots) until this value is set to on(1) by a management request. Even if the policyFilter later fails for this element, this value will stay in the forceOff(2) state." ::= { pmTrackingElementToPolicyEntry 2 } -- Compliance Statements pmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Policy-Based Management MIB" MODULE -- this module MANDATORY-GROUPS { pmPolicyManagementGroup } ::= { pmCompliances 1 } pmPolicyManagementGroup OBJECT-GROUP OBJECTS { pmPolicyFilter, pmPolicyCalendar, pmPolicyAction, pmPolicyDescription, pmPolicyMatches, pmPolicyStatus, pmRoleESStatus, pmRoleSEElement, pmCapabilitiesType, pmTrackingPolicyToElementStatus, pmTrackingElementToPolicyStatus } STATUS current Various Authors Expires November 8, 2000 [Page 25] Internet Draft Policy-Based Management MIB May 8, 2000 DESCRIPTION "Objects that allow for the creation and management of configuration policies." ::= { pmGroups 1 } END Various Authors Expires November 8, 2000 [Page 26] Internet Draft Policy-Based Management MIB May 8, 2000 7. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read- create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Various Authors Expires November 8, 2000 [Page 27] Internet Draft Policy-Based Management MIB May 8, 2000 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. Various Authors Expires November 8, 2000 [Page 28] Internet Draft Policy-Based Management MIB May 8, 2000 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. [18] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [19] American National Standards Institute, "C Language Specification" [20] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 2591, May 1999. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and Various Authors Expires November 8, 2000 [Page 29] Internet Draft Policy-Based Management MIB May 8, 2000 standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Various Authors Expires November 8, 2000 [Page 30] Internet Draft Policy-Based Management MIB May 8, 2000 Table of Contents 1 Abstract .............................................. 1 2 The SNMP Management Framework ......................... 2 3 Overview .............................................. 4 4 Policy-Based Network Management Architecture .......... 5 5 Policy Based Management Expression Language ........... 7 5.1 Formal Definition ................................... 8 5.2 Accessor Functions .................................. 9 5.2.1 getint() .......................................... 9 5.2.2 getstring() ....................................... 10 5.2.3 exists() .......................................... 10 5.2.4 elementName() ..................................... 11 5.2.5 strcmp() .......................................... 11 5.2.6 lc_strcmp() ....................................... 12 5.2.7 roleMatch() ....................................... 12 5.2.8 capMatch() ........................................ 12 5.2.9 setint() .......................................... 13 5.2.10 setstring() ...................................... 13 5.2.11 setoid() ......................................... 14 6 Definitions ........................................... 16 7 Security Considerations ............................... 27 8 References ............................................ 28 9 Intellectual Property ................................. 29 10 Full Copyright Statement ............................. 30 Various Authors Expires November 8, 2000 [Page 31] --------------D5BF5198608C6C316EC3FDE6-- From owner-snmpconf@seymour39.SNMP.COM Wed May 10 04:56: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 EAA20673 for ; Wed, 10 May 2000 04:56:51 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id EAA05636 for snmpconf-outgoing; Wed, 10 May 2000 04:39:24 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB07294910@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Subject: RE: snmpconf New draft of Policy Based Management MIB Date: Wed, 10 May 2000 10:38:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Again, pls post to I-D repository. Thanks, Bert > ---------- > From: Steve Waldbusser[SMTP:waldbusser@ins.com] > Reply To: snmpconf@snmp.com > Sent: Wednesday, May 10, 2000 7:25 AM > To: snmpconf@snmp.com > Subject: snmpconf New draft of Policy Based Management MIB > > <> > > Here's a new draft of the Policy Based Management MIB. Quite a lot has > been added. Please review for next weeks meeting. > > Steve > From owner-snmpconf@seymour39.SNMP.COM Wed May 10 10:03: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 KAA26428 for ; Wed, 10 May 2000 10:03:31 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA11467 for snmpconf-outgoing; Wed, 10 May 2000 09:45:12 -0400 (EDT) From: wkenneth@us.ibm.com X-Lotus-FromDomain: IBMUS To: snmpconf@snmp.com Message-ID: <852568DB.004B7638.00@d54mta05.raleigh.ibm.com> Date: Wed, 10 May 2000 06:28:44 -0700 Subject: Re: snmpconf Hotel Confirmations for the Interim Meeting Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Hi, I will be attending. Ken From owner-snmpconf@seymour39.SNMP.COM Wed May 10 13:03: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 NAA00007 for ; Wed, 10 May 2000 13:03:52 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA16902 for snmpconf-outgoing; Wed, 10 May 2000 12:38:00 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 10 May 2000 12:37:42 -0400 Subject: Re: snmpconf Hotel Confirmations for the Interim Meeting From: Jon Saperia To: Message-ID: In-Reply-To: <852568DB.004B7638.00@d54mta05.raleigh.ibm.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 05/10/2000 9:28 AM, wkenneth@us.ibm.com at wkenneth@us.ibm.com wrote: > > > Hi, > > I will be attending. > > Ken > > do you have a reservation at the sir Francis drake. I am just attempting to make sure the records are correct. /jon From owner-snmpconf@seymour39.SNMP.COM Wed May 10 20:43: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 UAA05530 for ; Wed, 10 May 2000 20:43:58 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id UAA00624 for snmpconf-outgoing; Wed, 10 May 2000 20:20:12 -0400 (EDT) Message-Id: <4.2.2.20000510201804.00a7e4a0@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 10 May 2000 20:18:37 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf Hotel Confirmations for the Interim Meeting 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 Yes, I have registered at the Sir Francis Drake at the Meeting rate for the Interim meeting. (Now all I have to do is get my airplane arrangements straightened out.) Joel At 12:20 PM 5/9/00 -0400, you wrote: >Hi everyone, I would appreciate it if you would email me a yes if you have >registered at the Sir Francis Drake hotel for the interim meeting. The list >I got from them did not seem complete. I want to make sure that everyone has >been correctly registered under the IETF group. > >Thanks >/jon > >P.S. - we are still looking for a corporate sponsor for the coffee and >afternoon break. From owner-snmpconf@seymour39.SNMP.COM Thu May 11 00:37: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 AAA09432 for ; Thu, 11 May 2000 00:37:42 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id AAA08129 for snmpconf-outgoing; Thu, 11 May 2000 00:21:00 -0400 (EDT) From: wkenneth@us.ibm.com X-Lotus-FromDomain: IBMUS To: snmpconf@snmp.com Message-ID: <852568DC.0017AECF.00@d54mta05.raleigh.ibm.com> Date: Wed, 10 May 2000 21:13:34 -0700 Subject: Re: snmpconf Hotel Confirmations for the Interim Meeting Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >on 05/10/2000 9:28 AM, wkenneth@us.ibm.com at wkenneth@us.ibm.com wrote: >do you have a reservation at the sir Francis drake. I am just attempting to >make sure the records are correct. Yes I do. From owner-snmpconf@seymour39.SNMP.COM Thu May 11 07:14:13 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 HAA23813 for ; Thu, 11 May 2000 07:14:13 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA01359 for snmpconf-outgoing; Thu, 11 May 2000 06:58:23 -0400 (EDT) Message-Id: <200005111057.GAA23579@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-01.txt Date: Thu, 11 May 2000 06:57:49 -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-01.txt Pages : 14 Date : 10-May-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-01.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-01.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-01.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: <20000510125613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-pm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-pm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510125613.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Fri May 12 14:05: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 OAA08776 for ; Fri, 12 May 2000 14:05:42 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA01419 for snmpconf-outgoing; Fri, 12 May 2000 13:47:28 -0400 (EDT) From: "Barr Hibbs" To: Subject: RE: snmpconf The May interim Meeting - Please respond asap Date: Fri, 12 May 2000 10:54:31 -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.2910.0) In-Reply-To: <3905ECCF.D119054B@ctron.com> Importance: Normal 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 I am tentatively planning to attend, however, I live in San Francisco, so won't be staying at the hotel.... --Barr Hibbs UltraDNS Corp. From owner-snmpconf@seymour39.SNMP.COM Tue May 16 13:15: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 NAA09299 for ; Tue, 16 May 2000 13:15:25 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA10810 for snmpconf-outgoing; Tue, 16 May 2000 12:55:28 -0400 (EDT) Message-Id: <200005161655.MAA17802@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf [Fwd: need patent in machine-readable format] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 16 May 2000 12:55:24 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit David Harrington sent the following message last week. Majordomo rejected my resubmission of it due to the message's large size. To avoid sending 5 mb to 192 subscribers, I have made the three files available, both via majordomo (in the cabletronPatents directory) and by anonymous ftp (www.snmp.com:pub/snmpconf/cabletronPatents). My apologies for the delay in handling this; a large portion of our staff was in Las Vegas last week. - Steve ---------------------------------------------------------------------- Hi, Attached are three patents for policy-based configuration management. There is running code associated with these patents, so they are known to work. I am sending these so the WG can study some of the problems that have been encountered in thereal world, and solved in real applications. There are some useful ideas here, but they don't solve all the problems we will need to face. The attachments are in pdf format. Sorry for the huge size. dbh --- 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 Wed May 31 16:23: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 QAA23814 for ; Wed, 31 May 2000 16:23:25 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA18884 for snmpconf-outgoing; Wed, 31 May 2000 16:01:20 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 31 May 2000 16:01:52 -0400 Subject: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting held in San Francisco May 17 - 19 From: Jon Saperia To: , Jon Saperia 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 QAA18876 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit What follows is a draft of the notes taken and the SNMPCONF WG interim meeting held in San Francisco May 17 - 19, 2000. I would like to thank David Harrington and Barr Hibbs for their contributions to these minutes. If any of the attendees have any additions or corrections (including duplicate detection), please send them to me by 5:00 PM east coast time this Friday June 2, 2000. I will work on them and also prepare the slide material available to me at that time. Thanks Jon Saperia Attendees: Jon Saperia, JDS Consulting Andy Bierman, Cisco Dan Romascanu, lucent Steve Waldbusser, lucent Andrew Smith, extreme Jeff Case, SNMP Research Joel Halpern, ivyplan Bert Wijnen, lucent Walter Weiss, lucent Harrie Hazewinkel, covalent Mike MacFaden, riverstone Thippanna Hongal, riverstone Deb Fitzgerald, nortel Ken White, IBM Xiang Li, IWL Barr Hibbs, Ultraradus Chris Wellens, IWL Dave Perkins, Randy Presuhn, BMC Don Goodnature, BMC Dale Francisco, Cisco Overall Summary: This interim meeting was to have advanced the work of all three documents on the working group charter. Time limitations and a desire to resolve some pressing issues limited the focus to the Policy and Differentiated Services Policy MIB modules. Work on the Best Current Practices Document (BCP) will continue. The meeting served as a way for attendees to exchange ideas and become familiar with a proposed architecture. The main result of the meeting is a fairly extensive set of issues that will be reviewed and discussed on the working group email list. That list is contained in this summary. Day One: Agenda Bashing - In summary, we agreed to start with the Policy MIB Module, then work on the Differentiated Services Policy MIB Module, then the BCP Document. Architecture presentation: Jon Saperia presented slides describing the overall architecture of the SNMPCONF approach. These slides showed the relationship of the different levels of policy information and how the different parts of the proposed SNMP Configuration architecture realize this information. The presentation will be made available on line separately. There were a number of persons present who had not been greatly involved yet, and it led to some useful discussions about and refinements of the concepts. There was a debate about terminology for device-type, or implementation-specific or implementation-version-dependent. The group preferred implementation-dependent over device-dependent. It was pointed out that mechanism-specific is akin to standard MIB modules, while device-specific (implementation-specific) was akin to vendor-extension MIB modules. It was pointed out that the BCP terminology/descriptions were not consistent with other documents and we agreed to make fixes to the BCP document where necessary. There was significant discussion about details and layers. There is a continuum. Something (like time filters) can be high (in the manager) or low (within the device). Sometimes, it is desirable to specify the specifics at the high level, and at other times it is desirable to hide the low-level details. Example: one customer wants a Holly four-barrel carburetor installed; another customer just wants their car to go as fast as possible, and allow the mechanic to select the best approach. Since policies may be multi-conditional, it should be possible to create a policy that is part abstract and part specific. We discussed the presentation of levels of abstraction. There was discussion about whether it should be described as levels, or whether device/instance should be one axis in a matrix with domain/mechanism as the other axis? Are there only four levels? Are the levels ordered? In the end we learned that part of the confusion was that one slide was representing a simple taxonomy while the other was attempting to represent a more detailed view of the functions and data at a particular level of abstraction. Policy MIB Presentation: Steve Waldbusser presented slides on the design of the Policy MIB. The purpose of the Policy MIB is to use SNMP to move policies to places that can execute them. There is a rich set of attributes that can be examined to determine the state of the network/device/etc. There is a less rich set of attributes that can be set (either by SNMP or other management-interface). During discussion, it was observed that capacity and usage/utilization feedback is an important part of the process. Capabilities is a Boolean optimization: it is a true/false determination of what is supported by a device. This Boolean is provided to make it easier to determine what a device supports than by discovering and examining specific MIB attributes. The Boolean could be incorrect, so Policy filters should still check to verify that application of the policy may be inappropriate. During the time between determining which policies should be distributed to a device, and the time the policies should be applied to the device, the capabilities may change. It is important to use these capabilities optimizations carefully. Policies may be downloaded when not necessary; policies may not be downloaded when needed. These error conditions need to be detectable, and there should be some standardization in error handling. Capabilities may exist at different levels of abstraction. Do we need to clarify our terminology for capabilities, such as type and subtype? A discussion on "scheduling ­ must we use a particular approach? " was shelved for later discussion. The BNF expressing the expression in the current document needs close inspection and corrections. There are some problems. One issue is the length of the OCTET STRINGs. This discussion can be done on-list, rather than face-to-face. The efficiency of evaluating filters may need to be improved by having some standard expression pieces that constrain the scope of managed objects to be considered. Requiring that all expressions begin with the roles would reduce the costs of evaluation. We need to be careful to allow the initial expression to be multi-valued, to reduce duplication of policies, and to handle different vendors referring to something using different OIDs (Bay MIBs vs. IETF MIBs) Roles in SNMPCONF differ from roles in policy framework. Framework assumes a centralized PDP that determines role combinations. The assumption is being made that PDP has a semantic understanding of roles. SNMPCONF has found a way to store "roles" on the target devices. This may not be lightweight. We need to discuss whether iterations exist outside the rule, or inside the rule. We need to discuss scoping versus filtering regarding the level of abstraction. Some use rules to express policies, while others are using policy to determine which rules should be distributed. There are rules about what is allowed in the filters and in the actions. SETS and compound statements - may not be used in filters. Should the preferred language for expressions be C or maybe Perl, since Perl is commonly used by operators and is commonly built into embedded environment. What should we do with an error? How do we handle runtime exceptions? We may need exists() and isInstanced(). Do we need IPAddress, engineID, and context to properly qualify objects? How do we handle error conditions with requests to remote devices. We need to determine how to wildcard roles (ifIndex.*). Should we support if-then-else? For time determination, should we use rfc2591, additional acessor functions, or separate MIB objects designed for our purposes. It is useful to have the time calculations at the device so there is no dependency on a connection between manager and device. Rfc2591 resolves issues of local time, daylight savings, etc. Is there a need for duration-based time stuff? Does device need to understand time? There was a discussion of needed debugging capability. Do we need a test and verify function? Does the pmTrackingElementToPolicyTable allow one to get at the necessary information to debug the problems? Should we somehow log the SETs when a policy is applied, with a time limit for persistence? Does this table offer sufficient value to justify its existence? Should it be possible to forceOFF the application of a policy to an element via this table? That would provide one central MIB to control the forceOFF. This suggestion needs to be discussed on the mailing list. Do we need to have standard notification when policy is overridden? Should we add a last-update field to pmTable? Should we add current_version field? Which policy group is this part of? Day Two Review of Issues: We reviewed topics to be discussed, both from yesterdayıs meeting and new topics proposed by the attendees. The following lists were produced during an extended conversation designed to generate topics for discussion both for the remainder of the meeting and on the SNMPCONF mailing list. These issues will be published again to the mailing list in groups to foster discussion and resolution of issues. A Meta-question was raised: how do we add items to the list of features, and how do we resolve whether they will be accepted? Do we need to consider the costs/benefits? General Functional Questions: 1. Should operators be able to override policy? Where is it useful to restrict this in the architecture - fall out issues? 2. We need to more fully specify terminology regarding capabilities type and sub-type. 3. What do we call capabilities that are beyond type and sub-type such as those found in the mechanism and implementation specific modules? The mechanism for their discovery is? 4. Are capabilities and capacity information part of the policy decision? 5. How do we do duration time calculations? 6. How do we represent and deal with time of day in the policy expression? 7. Time based rules are good things, there are some scheduling approach options: What light weight options do we want to allow? Do we require the device to know about time of day? 8. Would like to test a filter to get to the pointer to the attributes that have been changed as a result of the policy. 9. Do the debug tables do enough? Do they need to change or should they be removed? What is needed to improve them and is it worth the cost? 10. When was a system last touched? What was changed and when was a constellation of policies changed? 11. How do capabilities work? 12. How do we represent capacity and information about utilization? 13. General issue of debugging policies and the PmTracking table. How useful is this and how do we want to support the function? Is more needed for these tables? 14. How do we deal with revision of a single policy and sets of policies? Do we have policy groups, and policy priorities. How will we represent them? 15. Is there fate sharing between policies in groups, if so how is this specified? 16. How often do policy evaluations run? 17. Storage-type clarification for policies, are they all non-volitile? 18. Do/can-we start/stop polices as groups? 19. Resolution of the forced off in the pmTracking tracking table? 20. Do we want to allow cascading policy what are the implications? 21. What are legitimate policy names? 22. Notifications - what is the proper role, what are the proper notifications to be developed? 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? 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. Language Related Questions: 1. Language for expressions. To what degree do we want to use an existing language, and to what extent do we want to define our own? If we leverage an existing language, but constrain it to behave in ways that make it incompatible with the original, then we do not get reuse of language implementation, although we may get reuse of operator knowledge of languages like Perl. 2. We need to discuss Choice of language and Richness of language. Temporary variables, garbage collection; do we support temps or not? 3. Is UTF-8 support required in the expression language? 4. Extensibility Questions: For language and assessor functions - a natural one that allows for extension without re-opening the standard? sub-setting the language (do we allow or prohibit it)? sub-setting the assessor functions ibid? 5. Accessor functions ­ work to be done; reviewing proposed list. How to add new ones as they are needed? Can they go outside the SNMP universe? Mapping of principals, etc? 6. How do we handle versioning issues? 7. There were some standardization questions: standardization of element identifiers? capability type and subtype? extensibility mechanisms - are these part of the expression language? 8. Is the attribute of the element predefined? Can there be multiple instances? 9. How big should an expression be? 10. What are the execution environment requirements? 11. Temporary variables - do we want them: How do you dispose of them if we have them? 12. There were a number of attributes that people felt were desired. These include: needs to be debug-able - want to avoid memory leaks want to have instrumentation that helps people find bugs, want to avoid loopers but want iterators. 13. Issues about comments - comments in the expression - are they allowed? 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. Conflict Issues 1. How do we deal with intentional and unintended conflicts. 2. Is conflict detection or resolution a goal? 3. What happens when a policy is deleted? What if anything do you revert to? 4. How many errors are acceptable in a policy? How are they reported? 5. What happens when a configured element breaks that is executing a policy? In the afternoon of the second day (Thursday) we had a long discussion of the architecture. There seems to be general agreement on the chosen approach though more work needs to be done to express this. The relationships (the ones presented in Jon's slides and later represented by Steve) seem to be the right ones and could be beneficial. Andrew suggested that a team might want to do more work on this. The theoretical approach is "for all elements, for all filters, then for each instance which triggers an action, perform the action". This is too inefficient, and we need to improve the scalability. One way is to define a standard order of evaluation that will yield fast elimination of large portions early in the process. Another approach is to preprocess the filter, such that the number of filters to be processed is reduced. (i.e. the PDP only sends appropriate role-based filters to the PEP) The amplification of instances promises greater savings than amplification of objects. The amplification of objects is useful when two vendors use different implementations of the same things. An agent should be able to determine which elements are supported for policy (and which existing functionality is not supported for policy). Not all functionality must be exposed to management via policy. Instance amplification happens in the device-specific component, and in the domain-specific evaluation. The most interesting is the expansion within the filter expansion applied over some set of objects, in a way to avoid evaluating the universe. The agent should know which things it should be able to iterate over. The manager should be able to determine which things the agent knows how to iterate over. To constrain the number of types of elements, an enumerated integer provides constraints to extensibility. A new proposal is to allow a manager to download an OID Prefix to identify what should be iterated over. Reuse of filters is unlikely to be frequent. Reuse of actions is more likely to have benefits. However, the cost of indirection may be more expensive than the benefits. Friday Agenda 9 - 12 day three: We agreed that we wanted to spend time on the following topics even though that meant that we would not get to the BCP document before the close of the meeting. MIB Relationships: Should Diffserv-Policy MIB Module refer to the Policy MIB Module, or should the Policy MIB Module refer to Diffserv-Policy MIB Module? i.e. where should the pointer (and dependencies/knowledge of relationship) be? Jeff Case wants Policy MIB to point to Diffserv Policy MIB because he expects to use a mid-level manager with a Policy MIB, and multiple Diffserv Policy MIB instantiations on various devices. The indexes used by both Policy MIB and Diffserv Policy MIB must be consistent across devices and across reboots. It is not always possible to determine from Diffserv Policy MIB entries which Policy MIB entries are associated; it will not be possible to determine from Diffserv Policy MIB entry which policies will be affected if the Diffserv Policy MIB entry is deleted. (This is similar to not understanding which programs will be impacted by deleting /etc/host file on UNIX or something.dll in WinXX). This may be made easier by having an installation log which keep track of which installed pieces have relationships, but this still wouldnıt resolve all the possible anomalies of these relationships. We need to study the issues here and make sure we have a good design. Scalability: How often do policies execute, and where are the iterators? Continuously, event-driven, once, periodically, ad hoc, combination? We may need to consider the parts separately: How often do the filters get evaluated? How frequently do actions get enforced? How can the importance of filter evaluation be specified - which filters are the most important when determining evaluation frequency? (not precedence in conflict resolution)? How quickly will you notice state changes? Should we make it possible for the NMS to specify maximum acceptable latency? This doesnıt imply polling; an async engine can provide very low latency without polling. Should we have a Reevaluate-All button to force all filters to be reevaluated? Should there be a lower bound for detection of the action, and an upper bound for the completion of the action Š these are two different things! Rollbacks ­ When a policy no longer exists or applies, in the absence of a specific policy which applies to the new state, what should the new settings be? Do we need to keep original state for re-application? Do we keep the same settings until a policy is found that tells us otherwise? Wrap Up: Conflict Resolution still needs to be discussed. We need to discuss how policies will be "packaged," and how packages are defined. Next Interim Meeting: June 28-30 Boston is cancelled because certain people cannot make it that week, and the consensus of the attendees is that the time to produce modified documents, review them, and meet again, then produce modified documents and review them before the IETF meeting is too demanding a schedule. The proposed alternative is to have an interim meeting on the Friday and Saturday following IETF Pittsburgh (with a full day Saturday). An early-week meeting would provide an opportunity for an overview of the work done during this interim meeting, plus questions and answers, and leave enough time for people to read all the necessary documents prior to the working sessions Friday and Saturday.