From owner-snmpconf@seymour39.SNMP.COM Fri Nov 3 16:29:07 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00465 for ; Fri, 3 Nov 2000 16:29:07 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA11104 for snmpconf-outgoing; Fri, 3 Nov 2000 16:10:43 -0500 (EST) Message-Id: <4.3.2.7.2.20001103160157.00bd4c40@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Nov 2000 16:10:08 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: Re: snmpconf 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 On Wed, 25 Oct 2000 17:58:47 -0500, Mike_Ayers@bmc.com wrote: >{8.1.1.3. exists()} 9.) This function and many following >return 1 for success and 0 for failure, the reverse of the C >convention. Not so. In a boolean context, C defines false as zero and true as 1. (Actually, any non-zero value is true). The exists() function (and most of the other boolean functions) do not return success and failure (which are not defined in C) but true or false. If you were to write: if (exists("1.2.3.4.5.6.7")) blah(); you would expect blah() to be executed if 1.2.3.4.5.6.7 exists. Exists must return non-zero (true) for this situation. Compare to Standard C: if (is_upper(c)) blah(); will execute blah() if is_upper() returns 1, i.e. if c is an upper-case letter. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Fri Nov 3 16:45:55 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04275 for ; Fri, 3 Nov 2000 16:45:55 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id QAA11438 for snmpconf-outgoing; Fri, 3 Nov 2000 16:30:46 -0500 (EST) Message-Id: <4.3.2.7.2.20001103155842.00c6c980@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Nov 2000 16:30:32 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: snmpconf Policy MIB: General language issues 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 Hi, I'm working with Jon Saperia on implementing the Policy-based management MIB. In reading the October 11 draft, I came up with a number of issues related to the C-like language that is described in the document. Jon encouraged me to air these issues in this forum, so that we can get other people's brains involved. In order to keep the discussion manageable, I will post each issue with a different subject line, so that each issue can have its own thread of discussion. First, though, here are some general thoughts: I understand that we trying not to create a new language. However, we must recognize that any time we try to create a subset of a language, we are, in effect, creating a new language. Imagine, for example, if we were to say, "We're going to write a book. The story will be a subset of 'The Wizard of Oz'. Some examples of features that will be removed are the wicked witch, the tornado, and all mention of Kansas." The resulting story would, of course, be much shorter than the original, but we could not create it just be chopping out parts. We would have to plug up the holes in the story line in order for it to hold together. We would have to create additional pieces of plot to explain what the characters are doing in Oz, why the are seeking out the Wizard, etc. The final book would retain some of the flavor of "The Wizard of Oz", but would not be a simple subset. So it is with the language we are "not creating" here. We are chopping out about 75% of the language; not just pointers, structures, and floating point, but also function definitions, void, volatile, const, enum, storage classes, linkage, sizeof, unions and more. This leaves some major holes that must be plugged if the language is to hold together. For example, what does "char*" mean if there are no pointers? Failure to plug these holes with NEW (read non-C) syntax and semantics will leave a lot to the implementor's imagination, resulting in serious interoperability problems. In the next few posts I make to this list, I will be proposing some additions to the language. My intent is not to create a new language except to the degree that it is necessary to make it work. Please read my proposals with that in mind. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Fri Nov 3 17:14:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11613 for ; Fri, 3 Nov 2000 17:14:27 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id RAA12217 for snmpconf-outgoing; Fri, 3 Nov 2000 17:00:44 -0500 (EST) Message-Id: <4.3.2.7.2.20001103163036.00c91490@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Nov 2000 16:58:27 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: snmpconf Policy MIB: Strings and other data types Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The C string is so tied to the C language that it does not belong in any other language, especially one that doesn't have pointers and runs in an interpretive environment. One of the attributes of a text string is that it has a length. The fact that the length may be computed by searching for a null terminator is irrelevant to the concept of a string. A number of the functions defined in the Policy MIB have variants for NUL-terminated strings and non-NUL-terminated strings. Yet these concepts do not have meaning within SNMP. A string just exists and has a length. It is not null-terminated or non-null-terminated. Although we are modeling the language after C, we must also remember that we are working in a specific problem domain. The C string simply adds too much complexity to what is supposed to be a simple language. The C string is represented as a char*. But what is a char* if there are no pointers? Someone who does not program in C every day might easily write: char* a, b; expecting that a and b would be strings. But that is not what is written. In the above declaration, a is a string and b is a single char. Oops! Try to explain that to somebody without bringing in the concept of pointers. Also try to explain to them why, if string a contains binary data, you cannot determine its length and, therefore, you must pass the length in to a function as a separate parameter. Then, what happens if you pass the wrong length into a function? Does the agent crash? What happens if we pass a char* to a function without initializing it first? Do we really want to inherit all of these problems from C? If we replace "char*" with a new, intrinsic, "string" type, we solve all of these problems. A string would have a built-in length that would be returned by strlen() (for C compatibility). Functions could have string parameters and return strings without artificially introducing separate integer arguments. Also, strings could be assigned without aliasing and compared using ==, !=, <, >, etc. (yielding the correct results, not the bogus results of comparing pointers). For people that know C, we could still have functions like strcmp() and strcat(), although operators < and + would also do the job. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Fri Nov 3 17:45:06 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18917 for ; Fri, 3 Nov 2000 17:45:06 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA12997 for snmpconf-outgoing; Fri, 3 Nov 2000 17:30:45 -0500 (EST) Message-Id: <4.3.2.7.2.20001103170411.00c645a0@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Nov 2000 17:24:47 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: snmpconf Policy MIB: Other intrinsic data types 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 One of the consequences of doing away with struct and typedef is that anything that is not an integer must be encoded as a string. I think this is a rather impoverished state of affairs. Objects like OIDs, varbinds and especially 64-bit integers are better represented as intrinsic types. I see the following as useful intrinsic types that could exist in the language to support our problem domain: int -- 32-bit signed integers unsigned, unsigned int -- 32-bit unsigned integers unsigned int64 -- 64-bit unsigned integers string -- A text string (see my previous post) oid -- An OID varbind_list -- A list of varbinds (I'll go further into this in a future post) Of all of my proposals, this one may look the most un-like C. However, C allows structs to be declared, passed and returned by value, etc. My proposal is little more than pre-defining some struct types. Yes, I would like to see some syntactic sugar, like having + for string or OID concatenation, but that is secondary. If we are concerned that such operator overloading is adding too much to C, we could just as easily claim that we are creating a subset of C++, where overloading is permitted. These new types, then, would just be pre-defined classes. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Fri Nov 3 18:12:05 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24864 for ; Fri, 3 Nov 2000 18:12:04 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id SAA13290 for snmpconf-outgoing; Fri, 3 Nov 2000 18:00:26 -0500 (EST) Message-Id: <4.3.2.7.2.20001103173552.00cc4140@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Nov 2000 17:59:44 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: snmpconf Policy MIB: varbinds 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 In my other emails, I have proposed enhancements that would make the language described in the MIB (slightly) less C-like. In this message, I will do the reverse. I think that the readVarbind(), writeVarbind() and send() functions as proposed in the October 11th draft are decidedly unlike C. They propose a mysterious two-dimensional nameless array of varbinds that are accessed using the writeVarbind and readVarbind functions. The individual varbind lists are referenced by numbers instead of by name. Shades of FORTAN 68 (or worse) loom large. It is also unclear whether this mysterious array is global or local. My proposal: Declare varbind lists as (named) variables: varbind_list getstuff; append(getstuff, "1.2.3.4.5.6.7"); append(getstuff, "1.2.3.4.5.7.7"); snmpget(getstuff); string val1 = find_oid(getstuff, "1.2.3.4.5.6.7"); varbind_list setstuff; append(setstuff, "1.2.3.4.5.6.7", "Hello world"); snmpset(setstuff); varbind_list walkstuff; append(walkstuff, "1.2.3.4.55.6"); append(walkstuff, "1.2.3.4.55.7"); while (snmpgetnext(walkstuff)) { oid0 = lookup_oid(walkstuff, 0); val0 = lookup_value(walkstuff, 0); oid0 = lookup_oid(walkstuff, 1); val0 = lookup_value(walkstuff, 1); } In brief: - varbind_list would be an intrinsic type. - append(varbind_list, oid [, value ]) appends a varbind to the list. It replaces writeVarbind(). Note that the type need not be specified because it is implied by the Oid. - snmpget(), snmpset(), snmpgetnext(), etc. are separate functions that replace the generic snmpsend() function. It is not essetial that we do this. - find_oid() and lookup_value() would replace readVarbind(). find_oid() finds an oid in a varbind list by oid name and returns its value. lookup_oid() and lookup_value() return the components of a varbind in the nth position in the varbind list. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Fri Nov 3 18:25:03 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27750 for ; Fri, 3 Nov 2000 18:25:03 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA13410 for snmpconf-outgoing; Fri, 3 Nov 2000 18:12:15 -0500 (EST) Message-Id: <200011032312.SAA13403@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: snmpconf@snmp.com Subject: RE: snmpconf In-reply-to: Your message of Fri, 03 Nov 2000 17:32:50 -0500. <200011032232.RAA13029@seymour39.SNMP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 03 Nov 2000 18:12:11 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit -------- Re: BOUNCE snmpconf@majordomo.snmp.com: Non-member submission from [Mike Ayers ] This message bounced as Mike submitted it from other than his usual posting address. I have added Mike Ayers to the "can post, but does not receive messages" list. On Friday, November 3 2000, owner-snmpconf@snmp.com wrote: > >From owner-snmpconf@seymour39.SNMP.COM Fri Nov 3 17:32:48 2000 > Received: from web10704.mail.yahoo.com (web10704.mail.yahoo.com [216.136.130. 212]) > by seymour39.SNMP.COM (8.9.3/m.000221) with SMTP id RAA13024 > for ; Fri, 3 Nov 2000 17:32:47 -0500 (EST) > Message-ID: <20001103223216.35911.qmail@web10704.mail.yahoo.com> > Received: from [198.175.229.251] by web10704.mail.yahoo.com; Fri, 03 Nov 2000 14:32:16 PST > Date: Fri, 3 Nov 2000 14:32:16 -0800 (PST) > From: Mike Ayers > Reply-To: mayers@bmc.com > Subject: RE: snmpconf > To: snmpconf@snmp.com > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > > > From: Pablo Halpern [mailto:phalpern@newview.org] > > > > > > On Wed, 25 Oct 2000 17:58:47 -0500, Mike_Ayers@bmc.com wrote: > > >{8.1.1.3. exists()} 9.) This function and many following > > >return 1 for success and 0 for failure, the reverse of the C > > >convention. > > > > Not so. In a boolean context, C defines false as zero and true as 1. > > (Actually, any non-zero value is true). The exists() function > > (and most of > > the other boolean functions) do not return success and > > failure (which are > > not defined in C) but true or false. If you were to write: > > It appears I didn't double check this when writing. I intended to > refer to {8.1.1.4. setint()}, which uses the same convention as > exists(). This, I now recall, is a two-edged sword in C, because the > conventions for predicates and exit() are contradictory. You have, > however, clarified for me that some will wish to do 'if > (setint("1.3.6.1.4.1...", 2)) {/* success clause */} else {/* failure > clause */}', so it appears my point is unmade. > > > /|/|ike > > > __________________________________________________ > Do You Yahoo!? > >From homework help to love advice, Yahoo! Experts has your answer. > http://experts.yahoo.com/ --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com List manager, bottle washer, utility player, finder of lost things From owner-snmpconf@seymour39.SNMP.COM Tue Nov 7 03:21:21 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25366 for ; Tue, 7 Nov 2000 03:21:21 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id CAA24089 for snmpconf-outgoing; Tue, 7 Nov 2000 02:53:56 -0500 (EST) Message-ID: <3A07B2D9.E90B202D@nextbeacon.com> Date: Mon, 06 Nov 2000 23:44:25 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf RE: snmpconf New draft of the Policy Management MIB 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 Mike, Excellent feedback! Thank You! Out of the many many coments, I am only responding to the several that require feedback. Ayers, Mike wrote: > {8.1.1.3. exists()} > > 9.) This function and many following return 1 for success and 0 for > failure, the reverse of the C convention. It's not success or failure, it's true or false. exists() needs no failure return code. > {8.2. Constants} > > 13.) The SNMP error constants are not given their usual values. > Since they will not appear in an ASN.1 type field, this makes no sense. Is > there a reason for this? Yes, they will appear in an ASN.1 type field. I didn't finish that text yet. > {8.3.4. setScratchpad()} > > 15.) Note that if one uses scratchpads during, say, iteration of > rows in a table, it may be impossible to use the scratchpad elsewhere, since > no row (and therefore translated scratchpad varIndex) may be guaranteed to > be unused. This will be changed to index scratchpad variables by strings. The main motivation is to make the code more readable, but it will also increase the "range" of the indexing. Note that the design intent of the scratchpad is that scripts will typically store just several variables between invocations (many scripts won't use the scratchpad at all). But I still consider this a legitimate issue because the namespace size could still be an issue if say I was selecting 1 row from 1 table and 1 row from another table - they could conflict. > {8.4.4. oidsplice()} > > 16.) The starting point of the splice is not specified for oid2. It starts from the beginning. oid2 in it's entirety is spliced into oid1. It's intended to be used commonly for replacing index variables. I'll try to make this more clear. > {pmElementTypeRegTable} > > 18.) Wouldn't it be better to index this table via > pmElementTypeRegOIDPrefix and eliminate pmElementTypeRegIndex? I hate OIDs as indexes (I think most right-thinking people do :-). They are complex and long and the integer index is a small price to pay. (another minor point: I don't think common mgt tools will be smart enough to decode the OID at the end of the OID and pretty print it as a descriptor). > {pmTrackingPolicyToElementTable} & {pmTrackingElementToPolicyTable} > > 23.) After reading these sections three times, I am still baffled. > Questions include: > > - Why are there two tables? One is an efficient way to find all elements that a certain policy has matched. Another is an efficient way to find all policies that are acting on a certain element. > - Why the special objects for row status? Won't a rowStatus work? Well RowStatus is designed as a mutex mechanism for creating rows in tables. These tables don't support row creation by SNMP requests so that is the wrong tool for this job. > - Why does pmTrackingElementToPolicyEntry vanish when the > corresponding pmPolicyFilter fails? So that we don't have to wade through this table to find the many things that didn't match. > {pmConformance} > > 25.) This is instantiated as policyMgt.20, leaving 11 unused > objects between it and pmDebuggingTable. Is there any reason for this? Just cutting down my bookkeeping work while the MIB is under development. This way I don't have to renumber this subtree every time I add a table. Steve From owner-snmpconf@seymour39.SNMP.COM Tue Nov 7 11:48:58 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04629 for ; Tue, 7 Nov 2000 11:48:57 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA18706 for snmpconf-outgoing; Tue, 7 Nov 2000 11:36:16 -0500 (EST) Message-Id: <4.3.2.7.2.20001107110447.00c278b0@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Nov 2000 11:34:15 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: snmpconf Policy MIB: Eliminate pointers 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 This is a continuation of my series of critiques/suggestions for the C-like language in the Policy MIB. The text of the document indicates that pointers will not be part of the language. Indeed, I think it is inappropriate to introduce a machine-level concept like pointers into a language that is intended to be small and easy to interpret. Pointers are a major complicating subject and C's use of pointers is foreign to most people who don't program in C. The problem with eliminating pointers is that the library function seem to use them for pass-by-address parameters. This involves using the address-of operator (&) to take the address of a variable before passing it to a library function. Both the address-of operator and the dereference operator (*) add syntactic and semantic complexity to the language. My proposed solution: implied pass-by-reference. Library functions that needed to modify their arguments would simply be able to do so. Since the library functions are all built-in and do not need to be declared explicitly, there should be no syntactic issue with this. This eliminates the need for the address-of operator and the dereference operator and for pointers in general (except for char*, which I addressed in an earlier post). Another alternative would be to use C++ as a base language instead of C. That way, we could use references. The final language wouldn't be bigger, we would just have a larger starting point from which to pick-an-choose features. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Tue Nov 7 12:09:05 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13041 for ; Tue, 7 Nov 2000 12:09:04 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA19433 for snmpconf-outgoing; Tue, 7 Nov 2000 11:55:52 -0500 (EST) Message-Id: <4.3.2.7.2.20001107113452.00d01660@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Nov 2000 11:45:42 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: snmpconf Policy MIB: Pre-processor 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 Another (possibly the last) in my series of suggestions for significant in the C-like language described in the Policy MIB. The document lists a number of #defines for important constants. This implies a C preprocessor. In the interest of keeping the language small, I suggest that we do away with the C preprocessor in the agent code. Instead, we would encourage implementors of management applications to provide a C preprocessor through which code is processed before being sent to the Policy agent. We are already recommending that management applications perform substitution OIDs for MIB variable names, so I see this suggestion as entirely consistent. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Tue Nov 7 12:37:26 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22829 for ; Tue, 7 Nov 2000 12:37:26 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA21064 for snmpconf-outgoing; Tue, 7 Nov 2000 12:26:12 -0500 (EST) Message-Id: <4.3.2.7.2.20001107115531.00d1cb30@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Nov 2000 12:17:48 -0500 To: snmpconf@snmp.com From: Pablo Halpern Subject: snmpconf BNF errors in policy MIB 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 This post is NOT part of my series addressing general language issues. This message is intended to address specific errors I found in the language as specified in the BNF. First, the BNF in the document is far from complete. The text implies that the BNF is a subset of the language and that the rest of the language is supplied by the ANSI/ISO C standard. It does not make it clear exactly how the subset described is intended to mesh with the rest of C. Since the subset in question is less than 1/3 of the C standard, I suggest that we specify the ENTIRE language in BNF, rather than trying to describe deltas from the C standard. The entire C syntax is only about 10 pages of BNF, so our mini-C could be described in 3 or 4 pages at most. I'm willing to do this work, if desired. I can even run it through YACC to ensure that it is complete and unambiguous. (Steve Waldbusser: want to give me a crack at it?) Even if we don't describe the entire language in BNF, there are important errors in the existing syntax. I don't have time to list every detail, but here are some highlights: 1. The language depends on char*, yet there is no way to declare a variable of type char*. 2. The syntax allows constructs like if (while(for( i = 0; i < 10; ++i) ; ))) j = if (i > 9) x = 5; In other words, an expression is allowed to have loops and if-conditionals in it. This is not C (although it is valid in other languages, including Perl). If we do want to allow such things (useful, but very not-C), we must describe the semantics. 3. There is no switch statement. Don't we want a switch statement? I think we do. Again, I'm willing to take a crack at tightening this up, but I don't want to overlap with someone else's work or step on anybody's toes. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Tue Nov 7 13:43:02 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17070 for ; Tue, 7 Nov 2000 13:43:01 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA23377 for snmpconf-outgoing; Tue, 7 Nov 2000 13:29:42 -0500 (EST) Message-Id: <4.3.2.7.0.20001107131340.03861788@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Nov 2000 13:27:10 -0500 To: snmpconf@snmp.com, snmpconf@snmp.com From: "Wayne F. Tackabury" Subject: Re: snmpconf Policy MIB: Pre-processor In-Reply-To: <4.3.2.7.2.20001107113452.00d01660@192.168.1.99> 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 Hi Pablo--by the way, this is *great* input you're contributing here. :) At 11:45 AM 11/7/2000 -0500, Pablo Halpern wrote: >The document lists a number of #defines for important constants. This >implies a C preprocessor. In the interest of keeping the language small, I >suggest that we do away with the C preprocessor in the agent code. >Instead, we would encourage implementors of management applications to >provide a C preprocessor through which code is processed before being sent >to the Policy agent. We are already recommending that management >applications perform substitution OIDs for MIB variable names, so I see >this suggestion as entirely consistent. At the interim meeting, we struggled with this a fair amount. The result was a real Hobson's choice deferring to a deployment reality as it stands now--and one which some of us aren't completely thrilled with. In the first place, the "#define's" that the document references were placeholders for a greater "global constant" gestalt that the policy MIB framework requires. This is to say, all of the examples in the policy MIB document were for the benefit of the implementation, and did *not*, as of that writing, imply that such a facility was available for the policy author. So, one might ask, why *not* make such a facility available to the policy author. Well, at least, I asked. :) For starters, the notion of a formalized "#define" preprocessor construct was rejected for all the reasons you mentioned (in addition to the fact that we don't want to go promoting the more byzantine aspects of the typical C language implementation, such as preprocessor substitution in general). So, the option is some sort of "const" mechanism. However, since the policy MIB should be implementable in an agent with the minimum amount of additional resources required for this realization, we can't assume the ability for *any* agent-side symbolic substitution. Now, it is certainly something that a *given* management station which is tailored to the SNMPConf policy authoring function could itself implement, doing substitution of real OID's and constant values prior to writing them to the Policy MIB agent (that was my read on the outcome, anyway). This has an unfortunate side effect--on reading the policy back in, there's no way to accurately "substitute back" the symbolic reference. So, while a given implementation (and I think the idea is to not have the I-D reference this facility at all, or certainly to flag it as utterly optional) may be able to do a substitution from a human-readable const reference for OID's and scalars (timeout values, addr prefixes, etc.), they will be read *back* from the Policy MIB agent as hardcoded values. It's not pretty, but we haven't yet come up with a clean way to resolve this to everybody's satisfaction. The revision of the Policy MIB document which Steve is working on based on Knoxville input should address this point. Somebody correct me if I'm misstating how we ended up on this issue. Regards, Wayne -------- Wayne F. Tackabury Internet: wayne@goldwiretech.com Gold Wire Technology Phone: (781) 647-2211, x213 411 Waverley Oaks Rd., Ste. 331 Waltham, MA 02452 Cell: (617) 699-6156 From owner-snmpconf@seymour39.SNMP.COM Wed Nov 8 13:03:05 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16791 for ; Wed, 8 Nov 2000 13:03:04 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA10027 for snmpconf-outgoing; Wed, 8 Nov 2000 12:46:34 -0500 (EST) Message-Id: <200011081745.MAA31046@aix43.snmp.com> to: snmpconf@snmp.com, minutes@ietf.org Subject: snmpconf SNMPCONF Working Group Interim Meeting 10/2000 Slides Date: Wed, 08 Nov 2000 12:45:51 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com There was an interim meeting of the SNMPCONF Working Group of the IETF in Knoxville, Tennessee, USA on October 26 and 27, 2000. The slides for this meeting are now available via anonymous ftp at ftp://ftp.snmp.com/pub/snmpconf/interim-oct-2000. Minutes for this meeting are not yet ready, but will be submitted to this list and to minutes@ietf.org, and will be available at the ftp address above. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpconf@seymour39.SNMP.COM Thu Nov 9 04:15:57 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21827 for ; Thu, 9 Nov 2000 04:15:57 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id EAA00670 for snmpconf-outgoing; Thu, 9 Nov 2000 04:02:34 -0500 (EST) Message-ID: <3A0A65E6.2BDBEC54@nextbeacon.com> Date: Thu, 09 Nov 2000 00:52:54 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: snmpconf A non-trivial policyAction example 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 There are many, many simple examples of policyActions that can be expressed in only 1 or 2 lines of code. (turn off a port, set a configuration option, etc.) In order to see if the current version of the language is up to some more complex tasks, I started writing some examples. I figured an RMON2 example would satisfy the non-triviality test. The example below sets up RMON2 AlMatrix monitoring on an interface (for the RMON-ignorant: basically this will keep track of application conversations). This is done by creating and configuring the hlMatrixControlEntry. An action like this might be associated with a filter such as 'roleMatch("trunk")' which would be used to automatically set up AlMatrix monitoring only on trunk ports (not on access ports). This is a good configuration practice because the trunk port is a more efficient place to sniff the traffic rather than double-counting it on each access port. Enough RMON2 background, here's the script: char oid[STRINGLEN], value[STRINGLEN]; int index, pdu; pdu = 0; /* Use PDU #0 */ if (!(index = setRowStatus("hlMatrixControlStatus.*", 20))) return; /* couldn't find a free entry */ sprintf(oid, "hlMatrixControlDataSource.%d", index); sprintf(value, "ifIndex.%d", $1); writeVarbind(pdu, 0, oid, TYPE_OBJECT_IDENTIFIER, value, 0); sprintf(oid, "hlMatrixControlNlMaxDesiredEntries.%d", index); writeVarbind(pdu, 1, oid, TYPE_INTEGER, "1000", 0); sprintf(oid, "hlMatrixControlAlMaxDesiredEntries.%d", index); writeVarbind(pdu, 2, oid, TYPE_INTEGER, "1000", 0); sprintf(oid, "hlMatrixControlOwner.%d", index); writeVarbind(pdu, 3, oid, TYPE_OCTET_STRING, "policy manager", 14); sprintf(oid, "hlMatrixControlStatus.%d", index); writeVarbind(pdu, 4, oid, TYPE_INTEGER, "1", 0); snmpsend(0, 5, OP_SET); It's pretty straightforward. Basically it uses setRowStatus to find and reserve an unused row, and then creates a single PDU with all of the column values filled in and sends the SET. This is useful to illustrate how reasonable it is to do some fairly complex stuff, but it has a flaw which I'll identify and then fix. Scripts run periodically so that they can re-assert whatever state the policy is expected to enforce. The script above would create a control entry for every iteration. The fix is to see if a control entry already exists and, if so, exit. The first time we create an entry we store the dataSource in the scratchpad and then every time we execute, we retrieve it from the scratchpad (if it's there), check to see if it still represents a matrix on "this" interface, and if so, return immediately. Here's the complete example. The new code is lines 4-9 and 18: char oid[STRINGLEN], value[STRINGLEN]; int index, length, pdu; /* retrieve dataSource and make sure it exists */ if (getScratchpad(0, oid, &length) && exists(oid)){ getvar(oid, value, &length); if (subid(value, 10) == $1) /* still points to this interface */ return; } if (!(index = setRowStatus("hlMatrixControlStatus.*", 20))) return; /* couldn't find a free entry */ pdu = 0; /* Use PDU #0 */ sprintf(oid, "hlMatrixControlDataSource.%d", index); sprintf(value, "ifIndex.%d", $1); writeVarbind(pdu, 0, oid, TYPE_OBJECT_IDENTIFIER, value, strlen(value)); setScratchpad(0, oid, strlen(oid)); sprintf(oid, "hlMatrixControlNlMaxDesiredEntries.%d", index); writeVarbind(pdu, 1, oid, TYPE_INTEGER, "1000", 0); sprintf(oid, "hlMatrixControlAlMaxDesiredEntries.%d", index); writeVarbind(pdu, 2, oid, TYPE_INTEGER, "1000", 0); sprintf(oid, "hlMatrixControlOwner.%d", index); writeVarbind(pdu, 3, oid, TYPE_OCTET_STRING, "policy manager", 14); sprintf(oid, "hlMatrixControlStatus.%d", index); writeVarbind(pdu, 4, oid, TYPE_INTEGER, "1", 0); snmpsend(0, 5, OP_SET); I'm pretty happy how these examples turned out. By the way, there are a couple of subtle differences in the API that are reflected here but are not yet shown in the draft. The most obvious is the inclusion of sprintf. Steve From owner-snmpconf@seymour39.SNMP.COM Thu Nov 9 04:57:10 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08955 for ; Thu, 9 Nov 2000 04:57:09 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id EAA00944 for snmpconf-outgoing; Thu, 9 Nov 2000 04:44:10 -0500 (EST) Date: Thu, 9 Nov 2000 10:43:36 +0100 Message-Id: <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <3A0A65E6.2BDBEC54@nextbeacon.com> (message from Steve Waldbusser on Thu, 09 Nov 2000 00:52:54 -0800) Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Steve Waldbusser writes: [...] Steve> Enough RMON2 background, here's the script: [...] Steve> It's pretty straightforward. Basically it uses setRowStatus to Steve> find and reserve an unused row, and then creates a single PDU Steve> with all of the column values filled in and sends the SET. FYI, here is the same script in Tcl using the Tnm extension as you can run and execute it today. proc create_hlMatrixControlEntry {s ifIndex} { if {[catch {setRowStatus hlMatrixControlStatus} index]} { return } lappend vbl [list hlMatrixControlDataSource.$index ifIndex.$ifIndex] lappend vbl [list hlMatrixControlNlMaxDesiredEntries.$index 1000] lappend vbl [list hlMatrixControlAlMaxDesiredEntries.$index 1000] lappend vbl [list hlMatrixControlOwner.$index "policy manager"] lappend vbl [list hlMatrixControlStatus.$index 1] $s set $vbl } This example makes it very obvious to me that actions will be complex over time and that a mechanism is needed to write "procedures" (like the one above) which you can call and reuse in actions. (I can easily imagine cases where a policy rule action instantiates many rows and the hlMatrixControlEntry is just one of them.) Steve> This is useful to illustrate how reasonable it is to do some Steve> fairly complex stuff, but it has a flaw which I'll identify and Steve> then fix. Scripts run periodically so that they can re-assert Steve> whatever state the policy is expected to enforce. The script Steve> above would create a control entry for every iteration. Steve> The fix is to see if a control entry already exists and, if so, Steve> exit. The first time we create an entry we store the dataSource Steve> in the scratchpad and then every time we execute, we retrieve Steve> it from the scratchpad (if it's there), check to see if it Steve> still represents a matrix on "this" interface, and if so, Steve> return immediately. Steve> Here's the complete example. The new code is lines 4-9 and 18: [...] The fix is flawed as well since the oid in the scratchpad does not say which SNMP agent the action is executed on. If you want to use the action on multiple RMON2 boxes, bad things will happen. I am also concerned about the error handling - what happens if e.g. snmpsend(0, 5, OP_SET); fails with an SNMP error? Will the policy repeat in a loop to fire this action regularily?? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Thu Nov 9 14:13:05 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29468 for ; Thu, 9 Nov 2000 14:13:04 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA09787 for snmpconf-outgoing; Thu, 9 Nov 2000 13:45:13 -0500 (EST) Message-ID: <3A0AEE65.6CCA0BA4@nextbeacon.com> Date: Thu, 09 Nov 2000 10:35:17 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > proc create_hlMatrixControlEntry {s ifIndex} { > > if {[catch {setRowStatus hlMatrixControlStatus} index]} { > return > } > > lappend vbl [list hlMatrixControlDataSource.$index ifIndex.$ifIndex] > lappend vbl [list hlMatrixControlNlMaxDesiredEntries.$index 1000] > lappend vbl [list hlMatrixControlAlMaxDesiredEntries.$index 1000] > lappend vbl [list hlMatrixControlOwner.$index "policy manager"] > lappend vbl [list hlMatrixControlStatus.$index 1] > > $s set $vbl > } This API won't work in our environment because agents don't have MIB compilers and therefore don't know the type of a variable. For example, in the maxDesiredEntries varbinds above, it's not clear whether to send the integer 1000 or the 4 character string "1000". I'm definitely interested in continuing to work on the API/language to make scripts shorter and easier to write. > This example makes it very obvious to me that actions will be complex > over time and that a mechanism is needed to write "procedures" (like > the one above) which you can call and reuse in actions. (I can easily > imagine cases where a policy rule action instantiates many rows and > the hlMatrixControlEntry is just one of them.) Interesting, I had the opposite reaction. I was struck by the fact that the function was well within a manageable size and that no functional decomposition seemed obvious. > Steve> Here's the complete example. The new code is lines 4-9 and 18: > > [...] > > The fix is flawed as well since the oid in the scratchpad does not say > which SNMP agent the action is executed on. This is handled automatically by the execution environment which knows the address of "this element". > I am also > concerned about the error handling - what happens if e.g. snmpsend(0, > 5, OP_SET); fails with an SNMP error? Will the policy repeat in a loop > to fire this action regularily?? Yes, and I think this is desired behavior. A policy is trying to enforce a certain behavior. If the enforcement fails temporarily I think that it should continue to try. In this case, the maxLatency won't be too high (maybe run once per hour) and the (computational/operational) cost of failing is low. In another circumstance where the cost of failing was high, we could set something in the scratchpad to disable enforcement on this interface. Steve From owner-snmpconf@seymour39.SNMP.COM Thu Nov 9 16:01:28 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07144 for ; Thu, 9 Nov 2000 16:01:28 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA12225 for snmpconf-outgoing; Thu, 9 Nov 2000 15:35:53 -0500 (EST) Date: Thu, 9 Nov 2000 21:35:12 +0100 Message-Id: <200011092035.VAA25043@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <3A0AEE65.6CCA0BA4@nextbeacon.com> (message from Steve Waldbusser on Thu, 09 Nov 2000 10:35:17 -0800) Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> <3A0AEE65.6CCA0BA4@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Steve Waldbusser writes: Steve> This API won't work in our environment because agents don't Steve> have MIB compilers and therefore don't know the type of a Steve> variable. For example, in the maxDesiredEntries varbinds above, Steve> it's not clear whether to send the integer 1000 or the 4 Steve> character string "1000". Sure, I can write the same script using OIDs and having type information in there as well. The Tnm API allows you to do both. I decided to go with the short version since you used descriptors rather than OIDs in your example as well. :-) >> This example makes it very obvious to me that actions will be >> complex over time and that a mechanism is needed to write >> "procedures" (like the one above) which you can call and reuse in >> actions. (I can easily imagine cases where a policy rule action >> instantiates many rows and the hlMatrixControlEntry is just one of >> them.) Steve> Interesting, I had the opposite reaction. I was struck by the Steve> fact that the function was well within a manageable size and Steve> that no functional decomposition seemed obvious. We are working on a language which will have primitives on a much higher level, e.g. a primitive to 'ensure that the following row exists in a table'. Your code (and my code as well) was more part of the assembler code for what I consider to be a primitive in a decent policy language. But I know, we have different opinions on this. >> The fix is flawed as well since the oid in the scratchpad does not >> say which SNMP agent the action is executed on. Steve> This is handled automatically by the execution environment Steve> which knows the address of "this element". Address? EngineID? EngineID + ContextName? Is it specified anywhere what it is? >> I am also concerned about the error handling - what happens if >> e.g. snmpsend(0, 5, OP_SET); fails with an SNMP error? Will the >> policy repeat in a loop to fire this action regularily?? Steve> Yes, and I think this is desired behavior. A policy is trying Steve> to enforce a certain behavior. If the enforcement fails Steve> temporarily I think that it should continue to try. In this Steve> case, the maxLatency won't be too high (maybe run once per Steve> hour) and the (computational/operational) cost of failing is Steve> low. In another circumstance where the cost of failing was Steve> high, we could set something in the scratchpad to disable Steve> enforcement on this interface. There are errors where retrying simply does not make any sense (e.g. a VACM configuration which does not give you access to the target). Sure, it is much easier to ignore errors. But my experience is that systems that ignore errors are not useful once something goes wrong. Probably another point where we just have very different opinions. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Thu Nov 9 17:00:01 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23867 for ; Thu, 9 Nov 2000 17:00:01 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA13767 for snmpconf-outgoing; Thu, 9 Nov 2000 16:41:55 -0500 (EST) Message-Id: <200011092141.QAA20114@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf slides of interim meeting Date: Thu, 09 Nov 2000 16:41:52 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Per request by one of the working group members, I have made the slides available via http at http://www.snmp.com/snmpconf These will stay in place at least until the San Diego IETF meeting. The Powerpoint version of the slides at ftp://www.snmp.com/pub/snmpconf/interim-oct-2000/ will remain there indefinitely. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpconf@seymour39.SNMP.COM Thu Nov 9 23:43:21 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07765 for ; Thu, 9 Nov 2000 23:43:21 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id XAA00662 for snmpconf-outgoing; Thu, 9 Nov 2000 23:27:32 -0500 (EST) Message-ID: From: "Ayers, Mike" To: "'snmpconf@snmp.com'" Subject: RE: snmpconf A non-trivial policyAction example Date: Thu, 9 Nov 2000 16:31:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com > From: Steve Waldbusser [mailto:waldbusser@nextbeacon.com] > > Juergen Schoenwaelder wrote: > > > proc create_hlMatrixControlEntry {s ifIndex} { > > > > if {[catch {setRowStatus hlMatrixControlStatus} index]} { > > return > > } > > > > lappend vbl [list hlMatrixControlDataSource.$index > ifIndex.$ifIndex] > > lappend vbl [list > hlMatrixControlNlMaxDesiredEntries.$index 1000] > > lappend vbl [list > hlMatrixControlAlMaxDesiredEntries.$index 1000] > > lappend vbl [list hlMatrixControlOwner.$index "policy manager"] > > lappend vbl [list hlMatrixControlStatus.$index 1] > > > > $s set $vbl > > } > > This API won't work in our environment because agents don't have MIB > compilers and therefore don't know the type of a variable. > For example, in > the maxDesiredEntries varbinds above, it's not clear whether > to send the > integer 1000 or the 4 character string "1000". This is true if the set function operates strictly as an SNMP set. However, it is possible to make a copy of the varbind list, issue a get on it to fill out the type information, and use that information to build the set operation. I once wrote an SNMP interface that used this technique, and I was quite pleasesed with the results - since it checks the agent's idea of the variable type, it can even detect misconfiguration (i.e. if the type is integer and alphabetics occur, an error can be flagged without attempting the set) due to conflicting MIBs (something which shouldn't occur, but sometimes does). Just a thought, /|/|ike From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 01:15:00 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09640 for ; Fri, 10 Nov 2000 01:15:00 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id BAA07468 for snmpconf-outgoing; Fri, 10 Nov 2000 01:02:06 -0500 (EST) Message-ID: <3A0B7E30.80C8FB7B@nextbeacon.com> Date: Thu, 09 Nov 2000 20:48:48 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> <3A0AEE65.6CCA0BA4@nextbeacon.com> <200011092035.VAA25043@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > >>>>> Steve Waldbusser writes: > > Steve> This API won't work in our environment because agents don't > Steve> have MIB compilers and therefore don't know the type of a > Steve> variable. For example, in the maxDesiredEntries varbinds above, > Steve> it's not clear whether to send the integer 1000 or the 4 > Steve> character string "1000". > > Sure, I can write the same script using OIDs and having type > information in there as well. The Tnm API allows you to do both. I > decided to go with the short version since you used descriptors rather > than OIDs in your example as well. :-) Sorry, I assumed that the API didn't specify the type since you didn't specify the type in the example. As a side note, the use of descriptors in my examples is part of a convention described and encouraged in the PM draft in which humans read and write scripts with descriptors and then management stations translate them into dotted decimal before shipping them to agents. Another side note after looking at the TNM API: I see there is some optionality allowed for the parameters of varbind lists, but I'm surprised to see the middle parameter of the 3-tuple be omitted. It would seem to be very difficult to parse correctly. Was this just a mistake in your example? > >> This example makes it very obvious to me that actions will be > >> complex over time and that a mechanism is needed to write > >> "procedures" (like the one above) which you can call and reuse in > >> actions. (I can easily imagine cases where a policy rule action > >> instantiates many rows and the hlMatrixControlEntry is just one of > >> them.) > > Steve> Interesting, I had the opposite reaction. I was struck by the > Steve> fact that the function was well within a manageable size and > Steve> that no functional decomposition seemed obvious. > > We are working on a language which will have primitives on a much > higher level, e.g. a primitive to 'ensure that the following row > exists in a table'. Your code (and my code as well) was more part of > the assembler code for what I consider to be a primitive in a decent > policy language. But I know, we have different opinions on this. I'm not sure we differ at all on this. If you look at the type of routines I've added to the library, we seem to be on the same wavelength (i.e. setRowStatus, searchColumn). In other words, I believe that there are several high-level library routines that can immensely simplify script writing. One thing I brought up at the meeting was that it may be possible to further simplify the addition of rows with a library function specifically designed for this purpose. I may make a proposal soon. > >> The fix is flawed as well since the oid in the scratchpad does not > >> say which SNMP agent the action is executed on. > > Steve> This is handled automatically by the execution environment > Steve> which knows the address of "this element". > > Address? EngineID? EngineID + ContextName? Is it specified anywhere > what it is? "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 text can stand a bit of improvement, but I think it is basically clear. Also, note that the last published draft has this text for 5 of the 6 SNMP functions but doesn't have it for the snmpsend function. You'll see this fix in the next draft. > >> I am also concerned about the error handling - what happens if > >> e.g. snmpsend(0, 5, OP_SET); fails with an SNMP error? Will the > >> policy repeat in a loop to fire this action regularily?? > > Steve> Yes, and I think this is desired behavior. A policy is trying > Steve> to enforce a certain behavior. If the enforcement fails > Steve> temporarily I think that it should continue to try. In this > Steve> case, the maxLatency won't be too high (maybe run once per > Steve> hour) and the (computational/operational) cost of failing is > Steve> low. In another circumstance where the cost of failing was > Steve> high, we could set something in the scratchpad to disable > Steve> enforcement on this interface. > > There are errors where retrying simply does not make any sense (e.g. > a VACM configuration which does not give you access to the target). > Sure, it is much easier to ignore errors. But my experience is that > systems that ignore errors are not useful once something goes wrong. > Probably another point where we just have very different opinions. I hope it was clear that I was just talking about this RMON2 example. There are certainly situations where the cost of failure is high (too much CPU or other operational impact) or where a remedial operation is desired. If error recovery is mandated, then it is easy to code it in. I just don't feel it is warranted in this case. Nevertheless, I'm not sure your VACM example would make me change my mind. From an operational point of view, if and when the VACM configuration on an interface was fixed, I'd like the alMatrix entry to be created because it moves me closer to my policy which is "all trunk ports are monitored with alMatrix". If we were to disable a policy on error (never to retry again), would a momentary misconfiguration (of security, say) cause the element to forever be out of policy? I don't think this is the right behavior. The issue of error handling comes up when (1) failure is expensive or (2) recovery was an option. (1) An interesting example of expensive failure is when a log message is generated whenever an alMatrix creation fails. The cost here is operational (confusion, time, etc), not computational (CPU, disk, etc). In such a case, I'd want to make sure the policy didn't retry more than once a day or so after failure. I could accomplish this with a scratchpad variable that recorded the last failure time and didn't try again within some window of that time. (2) Sometimes recovery is an option when it might be possible to modify the request and try again or use another mechanism entirely. In such circumstances I see nothing wrong with adding error recovery code. In this RMON2 example, there isn't anything about the request that the agent could complain about. Steve From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 04:02:01 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09656 for ; Fri, 10 Nov 2000 04:02:01 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id DAA11691 for snmpconf-outgoing; Fri, 10 Nov 2000 03:49:39 -0500 (EST) Message-Id: <200011100848.JAA18189@lmera.lmera.ericsson.se> To: snmpconf@snmp.com cc: schoenw@ibr.cs.tu-bs.de Subject: Re: snmpconf A non-trivial policyAction example From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 X-Priority: normal In-reply-to: Your message of Thu, 09 Nov 2000 10:43:36 +0100. <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <16364.973846135.1@y5m638.lmera.ericsson.se> Date: Fri, 10 Nov 2000 09:48:55 +0100 X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id DAA11686 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id DAA11691 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA09656 Greetings, I just have one quick clarifying question: Jürgen writes: > The fix is flawed as well since the oid in the scratchpad does not say > which SNMP agent the action is executed on. If you want to use the > action on multiple RMON2 boxes, bad things will happen. Is the implication of this statement that you are expecting the execution environment to send SNMP set requests to multiple other devices in a mid-level manager kind of way? I see the "sets" in Steve's example as internal within a device, not something that's sent to other devices. Cheers, -- David Partain David.Partain@ericsson.com Ericsson Radio Systems AB Tel: +46 13 28 41 44 Research and Innovation Mobile: +46 70 633 0515 P.O. Box 1248 Fax: +46 13 28 75 67 SE-581 12 Linköping, Sweden From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 12:24:53 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17035 for ; Fri, 10 Nov 2000 12:24:52 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA00722 for snmpconf-outgoing; Fri, 10 Nov 2000 12:03:21 -0500 (EST) Date: Fri, 10 Nov 2000 14:45:32 +0100 Message-Id: <200011101345.OAA06975@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <200011100848.JAA18189@lmera.lmera.ericsson.se> (message from David Partain on Fri, 10 Nov 2000 09:48:55 +0100) Subject: Re: snmpconf A non-trivial policyAction example References: <200011100848.JAA18189@lmera.lmera.ericsson.se> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> David Partain writes: David> I just have one quick clarifying question: David> Jürgen writes: Thanks for the umlaut. :-) >> The fix is flawed as well since the oid in the scratchpad does not >> say which SNMP agent the action is executed on. If you want to use >> the action on multiple RMON2 boxes, bad things will happen. David> Is the implication of this statement that you are expecting the David> execution environment to send SNMP set requests to multiple David> other devices in a mid-level manager kind of way? David> I see the "sets" in Steve's example as internal within a David> device, not something that's sent to other devices. Well, I have not been at the interim and so I am only aware of what is in the documents. And says in section 8.1: : - General SNMP Functions : : The General SNMP functions allow nearly any legal SNMP Message to : be generated, including those with multiple varbinds, getNext : operations, notifications, and messages with explicit addressing : or security specifications. To me "messages with explicit addressing or security specifications" sounds like you are able to talk to other SNMP engines. But even if this WG restricts itself to a single local engine, then the question remains which context (perhaps you want to restrict yourself to a specific context in an SNMP engine?) and which set of security parameters you use (unless you propose to bypass VACM completely - which I hope you do not plan to do). I personally would like to use a policy configuration engine with existing deployed SNMP devices and MIBs. The assumption that each and every device implements the policy MIB is in my view not very convincing. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 12:29:57 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18707 for ; Fri, 10 Nov 2000 12:29:56 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA00974 for snmpconf-outgoing; Fri, 10 Nov 2000 12:07:47 -0500 (EST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 10 Nov 2000 12:08:01 -0500 Subject: Re: snmpconf BNF errors in policy MIB From: Jon Saperia To: Message-ID: In-Reply-To: <4.3.2.7.2.20001107115531.00d1cb30@192.168.1.99> 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 11/07/2000 12:17 PM, Pablo Halpern at phalpern@newview.org wrote: > First, the BNF in the document is far from complete. The text implies that > the BNF is a subset of the language and that the rest of the language is > supplied by the ANSI/ISO C standard. It does not make it clear exactly how > the subset described is intended to mesh with the rest of C. Since the > subset in question is less than 1/3 of the C standard, I suggest that we > specify the ENTIRE language in BNF, rather than trying to describe deltas > from the C standard. The entire C syntax is only about 10 pages of BNF, so > our mini-C could be described in 3 or 4 pages at most. I'm willing to do > this work, if desired. I can even run it through YACC to ensure that it is > complete and unambiguous. (Steve Waldbusser: want to give me a crack at it?) Hi Pablo, I do not think I saw a reply from Steve on this one. I like your suggestion of doing a BNF. If you can do this soon, and publish it we could talk about it at the next IETF, the second week of December. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 12:30:02 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18743 for ; Fri, 10 Nov 2000 12:30:01 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA00721 for snmpconf-outgoing; Fri, 10 Nov 2000 12:03:21 -0500 (EST) Date: Fri, 10 Nov 2000 15:37:08 +0100 Message-Id: <200011101437.PAA07472@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <3A0B7E30.80C8FB7B@nextbeacon.com> (message from Steve Waldbusser on Thu, 09 Nov 2000 20:48:48 -0800) Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> <3A0AEE65.6CCA0BA4@nextbeacon.com> <200011092035.VAA25043@henkell.ibr.cs.tu-bs.de> <3A0B7E30.80C8FB7B@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Steve Waldbusser writes: Steve> Another side note after looking at the TNM API: I see there is Steve> some optionality allowed for the parameters of varbind lists, Steve> but I'm surprised to see the middle parameter of the 3-tuple be Steve> omitted. It would seem to be very difficult to parse Steve> correctly. Was this just a mistake in your example? I do not find it hard to determine the number of arguments in a list and to parse the rest accordingly. In fact, Tmn even allows to omit the value when you do read requests. And you can write OIDs in many different ways. (But I guess this is not really relevant here.) Steve> This is handled automatically by the execution environment Steve> which knows the address of "this element". >> Address? EngineID? EngineID + ContextName? Is it specified >> anywhere what it is? Steve> "The agent will retrieve the instance in the same SNMP Steve> context in which the element resides. Note that no actual SNMP Steve> PDU needs to be generated and parsed when the policy MIB module Steve> resides on the same system as the managed elements." Steve> This text can stand a bit of improvement, but I think it is Steve> basically clear. Also, note that the last published draft has Steve> this text for 5 of the 6 SNMP functions but doesn't have it for Steve> the snmpsend function. You'll see this fix in the next draft. I think it is not clear since it is conditional. What happens if the MIB module does not reside on the same system as the managed elements? Note also that the terminology is not precise. Does the phrase "same system as the managed elements" mean it is the same context with the same SNMP engine? (We now have this great architecture to clearly say what we mean and we should thus use the right terminology.) Steve> If we were to disable a policy on error (never to retry again), Steve> would a momentary misconfiguration (of security, say) cause the Steve> element to forever be out of policy? I don't think this is the Steve> right behavior. Steve> The issue of error handling comes up when (1) failure is Steve> expensive or (2) recovery was an option. Ignoring the problem is not an answer. You need to report and handle errors somehow. A policy system which shows all lights turned to green while at the same time the lower layers do not install any policies due to e.g. VACM configuration errors is IMHO useless. My experience so far is that programming distributed systems is always 80 % time spend on getting error handling right and 20 % spend on the functional stuff. I would be surprised if this rule does not apply here as well. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 12:50:09 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25726 for ; Fri, 10 Nov 2000 12:50:09 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA01752 for snmpconf-outgoing; Fri, 10 Nov 2000 12:24:26 -0500 (EST) Message-ID: <75C9A75D295AD31184E70008C79189D20542182E@zcard00b.ca.nortel.com> From: "Glenn Waters" To: snmpconf@snmp.com Subject: RE: snmpconf A non-trivial policyAction example Date: Fri, 10 Nov 2000 11:55:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04B37.0BBB6990" X-Orig: Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04B37.0BBB6990 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Steve Waldbusser [mailto:waldbusser@nextbeacon.com] Sent: Thursday, November 9, 2000 13:35 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example Juergen Schoenwaelder wrote: > proc create_hlMatrixControlEntry {s ifIndex} { > > if {[catch {setRowStatus hlMatrixControlStatus} index]} { > return > } > > lappend vbl [list hlMatrixControlDataSource.$index ifIndex.$ifIndex] > lappend vbl [list hlMatrixControlNlMaxDesiredEntries.$index 1000] > lappend vbl [list hlMatrixControlAlMaxDesiredEntries.$index 1000] > lappend vbl [list hlMatrixControlOwner.$index "policy manager"] > lappend vbl [list hlMatrixControlStatus.$index 1] > > $s set $vbl > } This API won't work in our environment because agents don't have MIB compilers and therefore don't know the type of a variable. For example, in the maxDesiredEntries varbinds above, it's not clear whether to send the integer 1000 or the 4 character string "1000". [gww] Actually, a MIB compiler is not needed by the agent - just the output from the MIB compiler. The output tends to be one or more files that could easily used by an agent (at least in systems I have used and designed in the past). Also, if the agent does have access to the compiled MIB the agent would have access to the type (e.g.: string, integer, etc.) information of the objects. I'm definitely interested in continuing to work on the API/language to make scripts shorter and easier to write. > This example makes it very obvious to me that actions will be complex > over time and that a mechanism is needed to write "procedures" (like > the one above) which you can call and reuse in actions. (I can easily > imagine cases where a policy rule action instantiates many rows and > the hlMatrixControlEntry is just one of them.) Interesting, I had the opposite reaction. I was struck by the fact that the function was well within a manageable size and that no functional decomposition seemed obvious. > Steve> Here's the complete example. The new code is lines 4-9 and 18: > > [...] > > The fix is flawed as well since the oid in the scratchpad does not say > which SNMP agent the action is executed on. This is handled automatically by the execution environment which knows the address of "this element". > I am also > concerned about the error handling - what happens if e.g. snmpsend(0, > 5, OP_SET); fails with an SNMP error? Will the policy repeat in a loop > to fire this action regularily?? Yes, and I think this is desired behavior. A policy is trying to enforce a certain behavior. If the enforcement fails temporarily I think that it should continue to try. In this case, the maxLatency won't be too high (maybe run once per hour) and the (computational/operational) cost of failing is low. In another circumstance where the cost of failing was high, we could set something in the scratchpad to disable enforcement on this interface. Steve /gww ------_=_NextPart_001_01C04B37.0BBB6990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: snmpconf A non-trivial policyAction example

-----Original Message-----
From: Steve Waldbusser [mailto:waldbusser@nextbeacon.c= om]
Sent: Thursday, November 9, 2000 13:35
To: snmpconf@snmp.com
Subject: Re: snmpconf A non-trivial policyAction = example


Juergen Schoenwaelder wrote:

> proc create_hlMatrixControlEntry {s ifIndex} = {
>
>     if {[catch = {setRowStatus hlMatrixControlStatus} index]} {
>         = return
>     }
>
>     lappend vbl [list = hlMatrixControlDataSource.$index ifIndex.$ifIndex]
>     lappend vbl [list = hlMatrixControlNlMaxDesiredEntries.$index 1000]
>     lappend vbl [list = hlMatrixControlAlMaxDesiredEntries.$index 1000]
>     lappend vbl [list = hlMatrixControlOwner.$index "policy manager"]
>     lappend vbl [list = hlMatrixControlStatus.$index 1]
>
>     $s set $vbl
> }

This API won't work in our environment because agents = don't have MIB
compilers and therefore don't know the type of a = variable. For example, in
the maxDesiredEntries varbinds above, it's not clear = whether to send the
integer 1000 or the 4 character string = "1000".
[gww] Actually, a MIB compiler is not needed by the = agent - just the output from the MIB compiler. The output tends to be = one or more files that could easily used by an agent (at least in = systems I have used and designed in the past). Also, if the agent does = have access to the compiled MIB the agent would have access to the type = (e.g.: string, integer, etc.) information of the objects.

I'm definitely interested in continuing to work on = the API/language to make
scripts shorter and easier to write.

> This example makes it very obvious to me that = actions will be complex
> over time and that a mechanism is needed to = write "procedures" (like
> the one above) which you can call and reuse in = actions. (I can easily
> imagine cases where a policy rule action = instantiates many rows and
> the hlMatrixControlEntry is just one of = them.)

Interesting, I had the opposite reaction. I was = struck by the fact that the
function was well within a manageable size and that = no functional
decomposition seemed obvious.

> Steve> Here's the complete example. The new = code is lines 4-9 and 18:
>
> [...]
>
> The fix is flawed as well since the oid in the = scratchpad does not say
> which SNMP agent the action is executed = on.

This is handled automatically by the execution = environment which knows the
address of "this element".

> I am also
> concerned about the error handling - what = happens if e.g. snmpsend(0,
> 5, OP_SET); fails with an SNMP error? Will the = policy repeat in a loop
> to fire this action regularily??

Yes, and I think this is desired behavior. A policy = is trying to enforce a
certain behavior. If the enforcement fails = temporarily I think that it
should continue to try. In this case, the maxLatency = won't be too high
(maybe run once per hour) and the = (computational/operational) cost of
failing is low. In another circumstance where the = cost of failing was high,
we could set something in the scratchpad to disable = enforcement on this
interface.


Steve
/gww

------_=_NextPart_001_01C04B37.0BBB6990-- From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 13:28:30 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09408 for ; Fri, 10 Nov 2000 13:28:29 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA03459 for snmpconf-outgoing; Fri, 10 Nov 2000 13:07:40 -0500 (EST) Message-Id: <200011101807.NAA17537@seymour16.SNMP.COM> to: snmpconf@snmp.com Subject: snmpconf site outage Date: Fri, 10 Nov 2000 13:07:37 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Due to a rash of storms in the area, SNMP Research experienced something like 12 power outages in the past 18 hours, several after the UPSs had exhausted themselves. Not only did this cause considerable delay in mailing list operations, but this may have caused occasional DNS problems. Operations have returned to normal. When you see this message the backlog of SNMPCONF traffic should be gone. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 17:30:18 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03275 for ; Fri, 10 Nov 2000 17:30:17 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA09269 for snmpconf-outgoing; Fri, 10 Nov 2000 17:00:56 -0500 (EST) Message-ID: <3A0C6DD2.2A87A31A@nextbeacon.com> Date: Fri, 10 Nov 2000 13:51:14 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example References: <200011100848.JAA18189@lmera.lmera.ericsson.se> <200011101345.OAA06975@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > >> The fix is flawed as well since the oid in the scratchpad does not > >> say which SNMP agent the action is executed on. If you want to use > >> the action on multiple RMON2 boxes, bad things will happen. > > David> Is the implication of this statement that you are expecting the > David> execution environment to send SNMP set requests to multiple > David> other devices in a mid-level manager kind of way? > > David> I see the "sets" in Steve's example as internal within a > David> device, not something that's sent to other devices. > > Well, I have not been at the interim and so I am only aware of what is > in the documents. And says in section > 8.1: > > : - General SNMP Functions > : > : The General SNMP functions allow nearly any legal SNMP Message to > : be generated, including those with multiple varbinds, getNext > : operations, notifications, and messages with explicit addressing > : or security specifications. > > To me "messages with explicit addressing or security specifications" > sounds like you are able to talk to other SNMP engines. But even if > this WG restricts itself to a single local engine, then the question > remains which context (perhaps you want to restrict yourself to a > specific context in an SNMP engine?) and which set of security > parameters you use (unless you propose to bypass VACM completely - > which I hope you do not plan to do). > > I personally would like to use a policy configuration engine with > existing deployed SNMP devices and MIBs. The assumption that each > and every device implements the policy MIB is in my view not very > convincing. Let me try to shed some light on all of this. One important point that will be made in the following paragraphs is that talking to other systems (over the network) is, in fact, orthogonal to using explicit addressing or security specifications. The architecture specifically allows for the policy MIB to talk to other systems. One reason this is done is to allow proxy architectures where a local policy agent can enforce policy on a workgroup of managed systems that don't support the policy MIB. The policy agent gathers a set of elements of various types and executes policies on those elements. The policy agent is free to gather those elements from any context on the local system and also from remote systems. It is the job of the execution environment to forward a policy's management requests to the element. When the execution environment executes a policy on a non-local element, it sends those requests in SNMP PDUs to the address and context which are known by the execution environment. In other words, for this situation, whether elements are local or non-local, the policy code is the same (devoid of addressing information). This situation is complete for communications with "this element" and for other elements related to "this element". However, sometimes in a policy I will want to read or write information that is in a different context in the same system. I also can't rule out the need to read or write information on another system. So for these purposes the PM draft talks about the ability to address messages to any system/context. This functionality has not yet been added to the API, but it will be. Finally, regarding the example code that led up to all of this: the RMON2 "Add alMatrix" policy action code will add an alMatrix entry to any interface element (on any context/system) managed by the PM agent and selected by the corresponding policyFilter. It doesn't need addressing information, even if the PM agent is "proxying" for other systems. Steve From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 17:48:20 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07425 for ; Fri, 10 Nov 2000 17:48:19 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA10137 for snmpconf-outgoing; Fri, 10 Nov 2000 17:33:31 -0500 (EST) Message-ID: <3A0C7576.4D113926@nextbeacon.com> Date: Fri, 10 Nov 2000 14:23:50 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> <3A0AEE65.6CCA0BA4@nextbeacon.com> <200011092035.VAA25043@henkell.ibr.cs.tu-bs.de> <3A0B7E30.80C8FB7B@nextbeacon.com> <200011101437.PAA07472@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > Steve> Another side note after looking at the TNM API: I see there is > Steve> some optionality allowed for the parameters of varbind lists, > Steve> but I'm surprised to see the middle parameter of the 3-tuple be > Steve> omitted. It would seem to be very difficult to parse > Steve> correctly. Was this just a mistake in your example? > > I do not find it hard to determine the number of arguments in a list > and to parse the rest accordingly. In fact, Tmn even allows to omit > the value when you do read requests. And you can write OIDs in many > different ways. (But I guess this is not really relevant here.) I just though that if I omit the middle of 3 arguments (leaving two), it is difficult to tell which of the last 2 arguments was left off. For example, if I send { 1.3.6.1.4.1.2.3.4.5, integer }, do I interpret that as sending an unspecified integer value, or as sending a string whose value is "integer". Most varargs schemes allow you to optionally remove items from the end of the sequence only. > Steve> "The agent will retrieve the instance in the same SNMP > Steve> context in which the element resides. Note that no actual SNMP > Steve> PDU needs to be generated and parsed when the policy MIB module > Steve> resides on the same system as the managed elements." > > Steve> This text can stand a bit of improvement, but I think it is > Steve> basically clear. Also, note that the last published draft has > Steve> this text for 5 of the 6 SNMP functions but doesn't have it for > Steve> the snmpsend function. You'll see this fix in the next draft. > > I think it is not clear since it is conditional. What happens if the > MIB module does not reside on the same system as the managed elements? > Note also that the terminology is not precise. Does the phrase "same > system as the managed elements" mean it is the same context with the > same SNMP engine? (We now have this great architecture to clearly > say what we mean and we should thus use the right terminology.) Your first question is answered in the email I just sent. Regarding your second question, it doesn't mean "same context" (context is really more of a modelling concept than a physical concept anyway). And I don't think that there is any terminology in our architecture that helps. It's simply pointing out that if the PM agent and the target agent are on the same system, you can getint() without issuing a PDU. And if they are in different subagents on the same system, you can (probably) getint() without issuing a PDU. And if they are on different systems you probably have to send an SNMP PDU on the wire between the two systems. I think the "same system" phrase is pretty good but am willing to use any better terminology. > Steve> If we were to disable a policy on error (never to retry again), > Steve> would a momentary misconfiguration (of security, say) cause the > Steve> element to forever be out of policy? I don't think this is the > Steve> right behavior. > > Steve> The issue of error handling comes up when (1) failure is > Steve> expensive or (2) recovery was an option. > > Ignoring the problem is not an answer. You need to report and handle > errors somehow. A policy system which shows all lights turned to green > while at the same time the lower layers do not install any policies > due to e.g. VACM configuration errors is IMHO useless. > > My experience so far is that programming distributed systems is always > 80 % time spend on getting error handling right and 20 % spend on the > functional stuff. I would be surprised if this rule does not apply > here as well. You think I'm saying that error handling is not important in the general case. I'm not. Please re-read my comments and you'll see. Steve From owner-snmpconf@seymour39.SNMP.COM Fri Nov 10 18:08:42 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11923 for ; Fri, 10 Nov 2000 18:08:42 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id RAA10336 for snmpconf-outgoing; Fri, 10 Nov 2000 17:55:09 -0500 (EST) Message-ID: <3A0C7A87.A782211F@nextbeacon.com> Date: Fri, 10 Nov 2000 14:45:27 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example References: <75C9A75D295AD31184E70008C79189D20542182E@zcard00b.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Glenn Waters wrote: > [gww] Actually, a MIB compiler is not needed by the agent - just the > output from the MIB compiler. The output tends to be one or more files > that could easily used by an agent (at least in systems I have used > and designed in the past). Also, if the agent does have access to the > compiled MIB the agent would have access to the type (e.g.: string, > integer, etc.) information of the objects. True. My main point is that the SNMP architecture has never required agents to be datastores of this information (in any format) and that has been a good thing. This isn't a good time to start. I'd like to go further before anyone says "Given that this mib is implemented on the agent why can't the agent determine an object's type given its OID?" First, there are various implementation-specific reasons why a tight linkage between the execution environment and the agent may not be possible. The policy agent might be on a different system than the target system. Even on the same system the policy agent and the target agent might be in separate independent processes (and not using an extensible agent). Even if part of the same (potentially virtual) agent, the agent might not offer a name to type interface. Second, even if the PM scripting engine can get access to that information from the local agent, what if the script is trying to request an object that doesn't exist on the local system? Yes, the request will eventually fail, but I think it is important to be able to actually create the PDU and send it and get the proper failure back from the agent. Steve From owner-snmpconf@seymour39.SNMP.COM Sat Nov 11 10:10:12 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00081 for ; Sat, 11 Nov 2000 10:10:12 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA24187 for snmpconf-outgoing; Sat, 11 Nov 2000 09:56:23 -0500 (EST) Date: Sat, 11 Nov 2000 15:55:29 +0100 Message-Id: <200011111455.PAA14588@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <75C9A75D295AD31184E70008C79189D20542182E@zcard00b.ca.nortel.com> (gww@nortelnetworks.com) Subject: Re: snmpconf A non-trivial policyAction example References: <75C9A75D295AD31184E70008C79189D20542182E@zcard00b.ca.nortel.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Glenn Waters writes: >> I am also concerned about the error handling - what happens if >> e.g. snmpsend(0, 5, OP_SET); fails with an SNMP error? Will the >> policy repeat in a loop to fire this action regularily?? Glenn> Yes, and I think this is desired behavior. A policy is trying Glenn> to enforce a certain behavior. If the enforcement fails Glenn> temporarily I think that it should continue to try. In this Glenn> case, the maxLatency won't be too high (maybe run once per Glenn> hour) and the (computational/operational) cost of failing is Glenn> low. In another circumstance where the cost of failing was Glenn> high, we could set something in the scratchpad to disable Glenn> enforcement on this interface. What about broken policy code? Or a broken agent which interacts with correct policy code? All I am saying is that there needs to be a way to detect when things go wrong and to allow other entities to find out what went wrong. But I will shut up on this now. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Sat Nov 11 10:13:39 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01225 for ; Sat, 11 Nov 2000 10:13:39 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA24273 for snmpconf-outgoing; Sat, 11 Nov 2000 10:01:36 -0500 (EST) Date: Sat, 11 Nov 2000 16:01:03 +0100 Message-Id: <200011111501.QAA14606@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <3A0C6DD2.2A87A31A@nextbeacon.com> (message from Steve Waldbusser on Fri, 10 Nov 2000 13:51:14 -0800) Subject: Re: snmpconf A non-trivial policyAction example References: <200011100848.JAA18189@lmera.lmera.ericsson.se> <200011101345.OAA06975@henkell.ibr.cs.tu-bs.de> <3A0C6DD2.2A87A31A@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> David Partain asked: David> Is the implication of this statement that you are expecting the David> execution environment to send SNMP set requests to multiple David> other devices in a mid-level manager kind of way? [...] >>>>> Steve Waldbusser writes: [...] Steve> It is the job of the execution Steve> environment to forward a policy's management requests to the Steve> element. When the execution environment executes a policy on a Steve> non-local element, it sends those requests in SNMP PDUs to the Steve> address and context which are known by the execution Steve> environment. In other words, for this situation, whether Steve> elements are local or non-local, the policy code is the same Steve> (devoid of addressing information). [...] So your answer to David's question is: Yes, the policy execution environment can act as a mid-level manager. Please correct me if I am wrong. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Sat Nov 11 10:30:10 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06429 for ; Sat, 11 Nov 2000 10:30:10 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA24369 for snmpconf-outgoing; Sat, 11 Nov 2000 10:18:20 -0500 (EST) Date: Sat, 11 Nov 2000 16:17:47 +0100 Message-Id: <200011111517.QAA14642@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <3A0C7576.4D113926@nextbeacon.com> (message from Steve Waldbusser on Fri, 10 Nov 2000 14:23:50 -0800) Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> <3A0AEE65.6CCA0BA4@nextbeacon.com> <200011092035.VAA25043@henkell.ibr.cs.tu-bs.de> <3A0B7E30.80C8FB7B@nextbeacon.com> <200011101437.PAA07472@henkell.ibr.cs.tu-bs.de> <3A0C7576.4D113926@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Steve Waldbusser writes: Steve> I just though that if I omit the middle of 3 arguments (leaving Steve> two), it is difficult to tell which of the last 2 arguments was Steve> left off. For example, if I send { 1.3.6.1.4.1.2.3.4.5, integer Steve> }, do I interpret that as sending an unspecified integer value, Steve> or as sending a string whose value is "integer". The Tmn API is clear about this. three list elements: 1 oid (or something that resolves to an oid) 2 type name 3 value two list elements: 1 oid (or something that resolves to an oid) 2 value one list element: 1 oid (or something that resolves to an oid) Steve> Most varargs schemes allow you to optionally remove items from Steve> the end of the sequence only. See, these are lists and not varargs. ;-) Steve> Regarding your second question, it doesn't mean "same context" Steve> (context is really more of a modelling concept than a physical Steve> concept anyway). He? SNMPv3 has scoped PDUs - is that not physical enough? Steve> And I don't think that there is any terminology in our Steve> architecture that helps. It's simply pointing out that if the Steve> PM agent and the target agent are on the same system, you can Steve> getint() without issuing a PDU. And if they are in different Steve> subagents on the same system, you can (probably) getint() Steve> without issuing a PDU. And if they are on different systems you Steve> probably have to send an SNMP PDU on the wire between the two Steve> systems. For me, it would be easier to understand the complete picture if things were described based on the SNMP architecture and its terminology. But given the fact that you stated (as I understood it) that an execution engine can act as a mid-level manager, then the distinction between a "local getint()" and a "remote getint()" does not really matter and you may as well remove that text. [...] Steve> You think I'm saying that error handling is not important in Steve> the general case. I'm not. Please re-read my comments and Steve> you'll see. When I started to write the scotty package, I introduced a job command which allows to schedule the execution of Tcl procedures regularily with the capability to suspend and resume jobs. However, I did not give jobs full control how they should behave on error situations. In fact, the scheduler was just scheduling them again. Experience with real world code later told me that this was a design mistake and there are now job properties which give complete control over what happens if things go crazy. This was needed to write robust code. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Sat Nov 11 11:12:52 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18580 for ; Sat, 11 Nov 2000 11:12:52 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA24543 for snmpconf-outgoing; Sat, 11 Nov 2000 11:00:42 -0500 (EST) Message-Id: <4.3.2.7.0.20001111105508.041f3ec0@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 11 Nov 2000 10:58:07 -0500 To: snmpconf@snmp.com From: "Wayne F. Tackabury" Subject: Re: snmpconf A non-trivial policyAction example In-Reply-To: <200011111501.QAA14606@henkell.ibr.cs.tu-bs.de> References: <3A0C6DD2.2A87A31A@nextbeacon.com> <200011100848.JAA18189@lmera.lmera.ericsson.se> <200011101345.OAA06975@henkell.ibr.cs.tu-bs.de> <3A0C6DD2.2A87A31A@nextbeacon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 04:01 PM 11/11/2000 +0100, Juergen Schoenwaelder wrote: >So your answer to David's question is: > > Yes, the policy execution environment can act as a mid-level manager. > >Please correct me if I am wrong. It is my understanding that the policy environment can *absolutely* act as a mid-level manager. In my vision, this is a transitional product strategy for allowing a Policy MIB environment get deployed in a world with no Policy MIB-savvy managed element agent environments initially. In any event, there are plenty of text fragments through the current MIB which indicate this capability unambiguously (even if we haven't discussed explicit considerations for it very much if at all). Thanks for forcing the issue, Juergen, since it's an important one. Wayne From owner-snmpconf@seymour39.SNMP.COM Sat Nov 11 17:23:09 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08157 for ; Sat, 11 Nov 2000 17:23:08 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA25605 for snmpconf-outgoing; Sat, 11 Nov 2000 17:10:20 -0500 (EST) Message-ID: <3A0DC19D.18061B35@nextbeacon.com> Date: Sat, 11 Nov 2000 14:01:01 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example References: <3A0A65E6.2BDBEC54@nextbeacon.com> <200011090943.KAA23597@hansa.ibr.cs.tu-bs.de> <3A0AEE65.6CCA0BA4@nextbeacon.com> <200011092035.VAA25043@henkell.ibr.cs.tu-bs.de> <3A0B7E30.80C8FB7B@nextbeacon.com> <200011101437.PAA07472@henkell.ibr.cs.tu-bs.de> <3A0C7576.4D113926@nextbeacon.com> <200011111517.QAA14642@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > Steve> Regarding your second question, it doesn't mean "same context" > Steve> (context is really more of a modelling concept than a physical > Steve> concept anyway). > > He? SNMPv3 has scoped PDUs - is that not physical enough? I meant something else. The decision to place an object in a different context on the same agent is based on information modeling desires. When an object is on another system it simply reflects physical realities. The point is that architecturally speaking, moving an object to another context on the same agent does not make it harder to communicate with. > Steve> And I don't think that there is any terminology in our > Steve> architecture that helps. It's simply pointing out that if the > Steve> PM agent and the target agent are on the same system, you can > Steve> getint() without issuing a PDU. And if they are in different > Steve> subagents on the same system, you can (probably) getint() > Steve> without issuing a PDU. And if they are on different systems you > Steve> probably have to send an SNMP PDU on the wire between the two > Steve> systems. > > ... But given the fact that you stated (as I understood it) > that an execution engine can act as a mid-level manager, then the > distinction between a "local getint()" and a "remote getint()" does > not really matter and you may as well remove that text. I disagree - I believe the text is helpful to the implementor and should remain: "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." > Steve> You think I'm saying that error handling is not important in > Steve> the general case. I'm not. Please re-read my comments and > Steve> you'll see. > > > When I started to write the scotty package, I introduced a job command > which allows to schedule the execution of Tcl procedures regularily > with the capability to suspend and resume jobs. However, I did not > give jobs full control how they should behave on error situations. In > fact, the scheduler was just scheduling them again. Experience with > real world code later told me that this was a design mistake and there > are now job properties which give complete control over what happens > if things go crazy. This was needed to write robust code. > Thanks for the story. It is abundantly clear that we agree one hundred percent. Steve From owner-snmpconf@seymour39.SNMP.COM Sat Nov 11 17:23:09 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08166 for ; Sat, 11 Nov 2000 17:23:09 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA25604 for snmpconf-outgoing; Sat, 11 Nov 2000 17:10:19 -0500 (EST) Message-ID: <3A0DC184.AC40DFE2@nextbeacon.com> Date: Sat, 11 Nov 2000 14:00:36 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf A non-trivial policyAction example References: <200011100848.JAA18189@lmera.lmera.ericsson.se> <200011101345.OAA06975@henkell.ibr.cs.tu-bs.de> <3A0C6DD2.2A87A31A@nextbeacon.com> <200011111501.QAA14606@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > So your answer to David's question is: > > Yes, the policy execution environment can act as a mid-level manager. Yes, it can. The cool thing about this is that it came for free - we didn't do anything explicit to make this possible and script witers don't need to write their script any differently to allow their scripts to work when a network separates them from the target agent. Steve From owner-snmpconf@seymour39.SNMP.COM Mon Nov 13 12:16:17 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05436 for ; Mon, 13 Nov 2000 12:16:17 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA04957 for snmpconf-outgoing; Mon, 13 Nov 2000 11:59:03 -0500 (EST) Message-ID: From: "Ayers, Mike" To: "'snmpconf@snmp.com'" Subject: RE: snmpconf A non-trivial policyAction example Date: Mon, 13 Nov 2000 11:00:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com > From: Steve Waldbusser [mailto:waldbusser@nextbeacon.com] > > Steve> And I don't think that there is any terminology in our > > Steve> architecture that helps. It's simply pointing out that if the > > Steve> PM agent and the target agent are on the same system, you can > > Steve> getint() without issuing a PDU. And if they are in different > > Steve> subagents on the same system, you can (probably) getint() > > Steve> without issuing a PDU. And if they are on different > systems you > > Steve> probably have to send an SNMP PDU on the wire between the two > > Steve> systems. > > > > ... But given the fact that you stated (as I understood it) > > that an execution engine can act as a mid-level manager, then the > > distinction between a "local getint()" and a "remote getint()" does > > not really matter and you may as well remove that text. > > I disagree - I believe the text is helpful to the implementor > and should > remain: > > "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." > I would prefer "same network node" to "same system". Specifically, I'd prefer text that clearly rules out using a network protocol other than SNMP for information transfer. The term "system" is generic to the point of meaninglessness in computing environments, IMHO. /|/|ike From owner-snmpconf@seymour39.SNMP.COM Wed Nov 15 08:13:17 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16181 for ; Wed, 15 Nov 2000 08:13:17 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id HAA24321 for snmpconf-outgoing; Wed, 15 Nov 2000 07:54:26 -0500 (EST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 15 Nov 2000 07:54:44 -0500 Subject: snmpconf Re: [Diffserv] Instance amplification in Diffserv MIB From: Jon Saperia To: Andrew Smith , "'Robert Moore/Raleigh/IBM '" , Jon Saperia CC: "''diffserv@ietf.org ' ' '" , "'snmpconf@snmp.com'" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 11/14/2000 5:15 PM, Andrew Smith at andrew@allegronetworks.com wrote: > What you are arguing here is a need for some sort of "templating" capability > for these objects: this is something that was discussed at length in the early > snmpconf meetings (I wasn't at the last one so I don't know if this is still a > goal) and was being called "instance amplification". The problem, in brief was > "how do we apply a template of values for config parameters (columns) to a > whole collection of instances (table entries)?" and there were hopes that > snmpconf work would produce some sort of generic solution to this problem. > What you are describing here is a local solution for this problem for this > particular MIB, so I would ask you and Harrie to comment on whether we are > duplicating effort here or just moving this solution from being a snmpconf > work item to being a part of this diffserv MIB? If the latter then that's just > fine but we do need to check for consistency with the solutions being worked > on in snmpconf (yes Brian, that would mean a two-way dependency between these > work items). If the former then I think that the duplication of solutions > would be a Bad Thing. Andrew, this is only in response to your general questions about the SNMPCONF work. Harrie and others have commented on some of the other questions. Instance amplification is a primary goal of the SNMPCONF work. The MIB Module Harrie and David Partain are working on is to apply to the selected elements (interfaces in this case) the template of values to these selected elements. There was a desire to see if some of the 'template' tables could be included in the standard DiffServ. That is what they have been working on with Kwok. There should not be a duplication of solutions. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Nov 15 08:55:25 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01252 for ; Wed, 15 Nov 2000 08:55:24 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA24784 for snmpconf-outgoing; Wed, 15 Nov 2000 08:42:59 -0500 (EST) Importance: Normal Subject: snmpconf Re: [Diffserv] draft-ietf-diffserv-mib-05.txt posted To: Keith McCloghrie , internet-drafts@ietf.org Cc: brian@hursley.ibm.com (Brian E Carpenter), harrie@covalent.net (Harrie Hazewinkel), andrew@allegronetworks.com (Andrew Smith), diffserv@ietf.org (Diff Serv), khchan@nortelnetworks.com (Kwok Ho Chan), snmpconf@snmp.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Robert Moore/Raleigh/IBM" Date: Wed, 15 Nov 2000 08:43:09 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 11/15/2000 08:39:51 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=85256998004A15A58f9e8a93df938690918c85256998004A15A5" Content-Disposition: inline Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --0__=85256998004A15A58f9e8a93df938690918c85256998004A15A5 Content-type: text/plain; charset=us-ascii Keith (and others), I can't help with the "studied" part, but I can with the "distributed". I'm attaching the individual submission that Kwok and I wrote to define these two textual conventions. For smnpconf people who weren't present in Knoxville, I had hoped I could wait until after the meeting minutes came out before posting this draft, so that there would be some context for it. But it's time for other people to see the draft, and in any case, the cutoff date for new Internet-Drafts is now only two days away. I've also copied internet-drafts@ietf.org: could y'all please post this document in the individual submissions part of the Internet-Drafts repository? Thanks. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com (See attached file: draft-moore-snmpconf-tcs-00.txt) Keith McCloghrie on 11/14/2000 05:51:15 PM To: brian@hursley.ibm.com (Brian E Carpenter) cc: harrie@covalent.net (Harrie Hazewinkel), Robert Moore/Raleigh/IBM@IBMUS, andrew@allegronetworks.com (Andrew Smith), diffserv@ietf.org (Diff Serv), khchan@nortelnetworks.com (Kwok Ho Chan) Subject: Re: [Diffserv] draft-ietf-diffserv-mib-05.txt posted > Thanks for the clear explanation. Since we are in a hurry, > we cannot add any more dependencies. So there are two choices: > > 1. Forget this entirely for the diffserv MIB. > 2. Add these textual conventions explicitly in the -06 version of the > diffserv MIB. > > If you are telling us that the MIB experts who have looked at this > are all in agreement, let's take choice 2 as a consensus. It is my understanding that those "MIB experts" who were not present in Knoxville, are having trouble reconciling the several differently- garbled versions of said discussions. I don't think you can posit a consensus until the written description has been distributed and studied. Keith. --0__=85256998004A15A58f9e8a93df938690918c85256998004A15A5 Content-type: application/octet-stream; name="draft-moore-snmpconf-tcs-00.txt" Content-Disposition: attachment; filename="draft-moore-snmpconf-tcs-00.txt" Content-Description: Text - character set unknown Content-Transfer-Encoding: base64 DQogU05NUCBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBCb2IgTW9vcmUNCiBJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElCTQ0KIENhdGVnb3J5OiBTdGFuZGFyZHMg VHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgS3dvayBIbyBDaGFuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9y dGVsIE5ldHdvcmtzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE5vdmVtYmVyLCAyMDAwDQoKCiAgICAgICAgICAgICAgICAgVGV4dHVh bCBDb252ZW50aW9ucyBmb3IgU05NUCBDb25maWd1cmF0aW9uDQoKICAgICAgICAgICAgICAgICAg ICAgPGRyYWZ0LW1vb3JlLXNubXBjb25mLXRjcy0wMC50eHQ+DQogICAgICAgICAgICAgICAgICAg V2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAwMCwgODoyNyBBTQ0KCiBTdGF0dXMgb2YgdGhpcyBN ZW1vDQoKICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVs bCBjb25mb3JtYW5jZSB3aXRoIGFsbA0KICAgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJG QzIwMjYuDQoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzaw0KICAgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFu ZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgb3RoZXINCiAgIGdyb3VwcyBtYXkgYWxz byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCgogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl ZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0 ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KCiAgIFRoZSBsaXN0 IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoKICAgVGhlIGxpc3Qgb2YgSW50 ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KCiBDb3B5cmlnaHQgTm90aWNlDQoKICAgQ29w eXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMCkuICBBbGwgUmlnaHRzIFJlc2Vy dmVkLg0KCiBBYnN0cmFjdA0KCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gdGV4dHVhbCBj b252ZW50aW9ucyBzaW1pbGFyIHRvIHRoZQ0KICAgUm93UG9pbnRlciB0ZXh0dWFsIGNvbnZlbnRp b24gZGVmaW5lZCBpbiBSRkMyNTc5LiAgVGhlc2UgdHdvIHRleHR1YWwNCiAgIGNvbnZlbnRpb25z IGluZGljYXRlIGhvdyB0aGUgY29uY2VwdHVhbCByb3cgdG8gd2hpY2ggYW4gb2JqZWN0IHBvaW50 cw0KICAgaXMgdG8gYmUgaGFuZGxlZCB3aGVuIHRoZSBvYmplY3QgaXMgY2xvbmVkIHRvIGNyZWF0 ZSBhbiBpbnN0YW5jZS0NCiAgIHNwZWNpZmljIGNvbmZpZ3VyYXRpb24uICBUaGlzIGNsb25pbmcg bWF5IGludm9sdmUgdGhlIHNjcmlwdGluZy1iYXNlZA0KICAgdGVjaG5pcXVlcyBkZWZpbmVkIHVu ZGVyIHRoZSBTTU5QIENvbmZpZ3VyYXRpb24gdW1icmVsbGEsIGJ1dCBpdCBuZWVkDQogICBub3Q6 IGNsb25pbmcgY2FuIGFsc28gYmUgcmVhbGl6ZWQgd2l0aCBvcmRpbmFyeSBTTk1QIEdldCBhbmQg U2V0DQogICBvcGVyYXRpb25zLg0KCgoKCgoKCgoKCiBNb29yZSBhbmQgQ2hhbiAgICAgICAgRXhw aXJlczogTm92IDIwMDAgKyA2IG1vbnRocyAgICAgICAgICAgICBbUGFnZSAxXQ0MDQogSW50ZXJu ZXQgRHJhZnQgICBTTk1QIENvbmZpZ3VyYXRpb24gVGV4dHVhbCBDb252ZW50aW9ucyAgIE5vdmVt YmVyIDIwMDANCgoKICAgVGFibGUgb2YgQ29udGVudHMNCgogICAxLiBJbnRyb2R1Y3Rpb24uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yDQogICAy LiBEZWZpbml0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4zDQogICAzLiBJbnRlbGxlY3R1YWwgUHJvcGVydHkuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQogICA0LiBBY2tub3dsZWRnZW1lbnRzLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICA1LiBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi42DQogICA2LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICA3LiBBdXRob3JzJyBBZGRyZXNzZXMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43DQogICA4LiBGdWxs IENvcHlyaWdodCBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi44DQoKCgogMS4gSW50cm9kdWN0aW9uDQoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3 byB0ZXh0dWFsIGNvbnZlbnRpb25zIHNpbWlsYXIgdG8gdGhlDQogICBSb3dQb2ludGVyIHRleHR1 YWwgY29udmVudGlvbiBkZWZpbmVkIGluIFJGQzI1NzkuICBUaGVzZSB0d28gdGV4dHVhbA0KICAg Y29udmVudGlvbnMgaW5kaWNhdGUgaG93IHRoZSBjb25jZXB0dWFsIHJvdyB0byB3aGljaCBhbiBv YmplY3QgcG9pbnRzDQogICBpcyB0byBiZSBoYW5kbGVkIHdoZW4gdGhlIG9iamVjdCBpcyBjbG9u ZWQgdG8gY3JlYXRlIGFuIGluc3RhbmNlLQ0KICAgc3BlY2lmaWMgY29uZmlndXJhdGlvbi4gIFRo aXMgY2xvbmluZyBtYXkgaW52b2x2ZSB0aGUgc2NyaXB0aW5nLWJhc2VkDQogICB0ZWNobmlxdWVz IGRlZmluZWQgdW5kZXIgdGhlIFNNTlAgQ29uZmlndXJhdGlvbiB1bWJyZWxsYSwgYnV0IGl0IG5l ZWQNCiAgIG5vdDogY2xvbmluZyBjYW4gYWxzbyBiZSByZWFsaXplZCB3aXRoIG9yZGluYXJ5IFNO TVAgR2V0IGFuZCBTZXQNCiAgIG9wZXJhdGlvbnMuDQoKICAgVGhlIHByb2Nlc3Mgb2YgY3JlYXRp bmcgaW5zdGFuY2Utc3BlY2lmaWMgY29uZmlndXJhdGlvbiBmcm9tIGFuDQogICBpbXBsZW1lbnRh dGlvbi1zcGVjaWZpYyB0ZW1wbGF0ZSBpcyBwcmVzZW50ZWQgaW4gW3NvbWUgc25tcGNvbmYNCiAg IGRvY3VtZW50XS4gIChFRElUT1InUyBOT1RFOiBTaW5jZSB0aGVzZSB0ZXh0dWFsIGNvbnZlbnRp b25zIGNhbiBhbHNvDQogICBiZSB1c2VkIHdpdGggIm9yZGluYXJ5IiBTTk1QIEdldCBhbmQgU2V0 IG9wZXJhdGlvbnMsIEkgdGhpbmsgd2UgY2FuDQogICB0cmVhdCB0aGlzIHJlZmVyZW5jZSBhcyBu b24tbm9ybWF0aXZlIGZvciB0aGUgcHVycG9zZXMgb2YgYWR2YW5jaW5nDQogICB0aGVzZSB0d28g dGV4dHVhbCBjb252ZW50aW9ucyB0byBQcm9wb3NlZCBTdGFuZGFyZC4pICBCcmllZmx5LCBhDQog ICB0ZW1wbGF0ZSBpbnZvbHZlcyByb3dzIGluIHNldmVyYWwgdGFibGVzLCB0aWVkIHRvZ2V0aGVy IHdpdGggT0lELQ0KICAgdmFsdWVkIG9iamVjdHMgdGhhdCBmdW5jdGlvbiBhcyBwb2ludGVycyB0 byBvdGhlciB0YWJsZXMuICBSYXRoZXIgdGhhbg0KICAgYmVpbmcgZGVmaW5lZCB3aXRoIHRoZSBS b3dQb2ludGVyIHRleHR1YWwgY29udmVudGlvbiwgaG93ZXZlciwgZWFjaCBvZg0KICAgdGhlc2Ug cG9pbnRlciBvYmplY3RzIGlzIGRlZmluZWQgdXNpbmcgb25lIG9mIHRoZSB0d28gdGV4dHVhbA0K ICAgY29udmVudGlvbnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhlc2UgdHdvIHRleHR1 YWwgY29udmVudGlvbnMNCiAgIGVtYm9keSBhZGRpdGlvbmFsIHNlbWFudGljcywgdG8gdGVsbCB0 aGUgcHJvY2VzcyBkb2luZyB0aGUgY2xvbmluZyBob3cNCiAgIGl0IHNob3VsZCB0cmVhdCB0aGUg Y29uY2VwdHVhbCByb3cgdGhhdCBhbiBvYmplY3QgaXMgcG9pbnRpbmcgdG8uICBGb3INCiAgIG1v cmUgZGV0YWlscywgc2VlIHJlZmVyZW5jZSBbdGhlIHNhbWUgc25tcGNvbmYgZG9jdW1lbnQgYXMg YmVmb3JlXS4NCgogICBBIGRpZmZlcmVudCB0eXBlIG9mIGNsb25pbmcgY2FuIGFsc28gYmVuZWZp dCBmcm9tIHRoZXNlIHRleHR1YWwNCiAgIGNvbnZlbnRpb25zLiAgVXNpbmcgb25seSBTTk1QIEdl dCBhbmQgU2V0IG9wZXJhdGlvbnMsIGl0IGlzIHBvc3NpYmxlDQogICB0byByZXRyaWV2ZSBvbmUg aW5zdGFuY2Utc3BlY2lmaWMgY29uY2VwdHVhbCByb3csIGFuZCB0aGVuIHVzZSB0aGUNCiAgIHZh bHVlcyB0aGF0IHdlcmUgcmV0cmlldmVkIHRvIGNyZWF0ZSBhbm90aGVyIGluc3RhbmNlLXNwZWNp ZmljIHJvdw0KICAgImp1c3QgbGlrZSBpdC4iICBUaGUgdGV4dHVhbCBjb252ZW50aW9ucyB0ZWxs IHRoZSBwcm9jZXNzIGRvaW5nIHRoZQ0KICAgY2xvbmluZyB3aGV0aGVyIGEgcG9pbnRlciBpbiBh IG5ld2x5IGNyZWF0ZWQgY29uY2VwdHVhbCByb3cgc2hvdWxkDQogICBwb2ludCB0byBhbm90aGVy IG5ld2x5IGNyZWF0ZWQgY29uY2VwdHVhbCByb3csIG9yIHRvIHRoZSBzYW1lDQogICBjb25jZXB0 dWFsIHJvdyBwb2ludGVkIHRvIGJ5IHRoZSBvYmplY3QgZnJvbSB3aGljaCB0aGUgcG9pbnRlciB3 YXMNCiAgIGNsb25lZC4NCgogICBUaGVyZSBpcyBhIG5hdHVyYWwgbWFwcGluZyBiZXR3ZWVuIHRo ZSB0d28gdGV4dHVhbCBjb252ZW50aW9ucyBkZWZpbmVkDQogICBoZXJlIGFuZCB0aGUgYXNzb2Np YXRpb24gY2FyZGluYWxpdGllcyBpbiBhbiBpbmZvcm1hdGlvbiBtb2RlbC4gIElmIGFuDQogICBh c3NvY2lhdGlvbiBoYXMgYSAxOjEgY2FyZGluYWxpdHkgKGVhY2ggQSBpcyBhc3NvY2lhdGVkIHdp dGggYQ0KCgogTW9vcmUgYW5kIENoYW4gICAgICAgIEV4cGlyZXM6IE5vdiAyMDAwICsgNiBtb250 aHMgICAgICAgICAgICAgW1BhZ2UgMl0NDA0KIEludGVybmV0IERyYWZ0ICAgU05NUCBDb25maWd1 cmF0aW9uIFRleHR1YWwgQ29udmVudGlvbnMgICBOb3ZlbWJlciAyMDAwDQoKCiAgIHNlcGFyYXRl IEIpLCB0aGVuIHRoZSBwb2ludGVyIGZyb20gYSBjb25jZXB0dWFsIHJvdyByZXByZXNlbnRpbmcg YW4gQQ0KICAgdG8gYSBjb25jZXB0dWFsIHJvdyByZXByZXNlbnRpbmcgYSBCIHdvdWxkIGhhdmUg dGhlIHN5bnRheA0KICAgRHluYW1pY1Jvd1BvaW50ZXIuICBUaGlzIG1lYW5zIHRoYXQgd2hlbiBh IG5ldyBBIGlzIGNyZWF0ZWQsIGl0IG11c3QNCiAgIGJlIGFzc29jaWF0ZWQgd2l0aCBhIG5ldyBC LCByYXRoZXIgdGhhbiB3aXRoIGEgQiB0aGF0IGlzIGFscmVhZHkNCiAgIGFzc29jaWF0ZWQgd2l0 aCBhbm90aGVyIEEuDQoKICAgT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoZSBhc3NvY2lhdGlvbiBo YXMgYSBuOjEgY2FyZGluYWxpdHkgKHNldmVyYWwNCiAgIEEncyBtYXkgYmUgYXNzb2NpYXRlZCB3 aXRoIHRoZSBzYW1lIEIpLCB0aGVuIHRoZSBwb2ludGVyIGZyb20gYQ0KICAgY29uY2VwdHVhbCBy b3cgcmVwcmVzZW50aW5nIGFuIEEgdG8gYSBjb25jZXB0dWFsIHJvdyByZXByZXNlbnRpbmcgYSBC DQogICB3b3VsZCBoYXZlIHRoZSBzeW50YXggU3RhdGljUm93UG9pbnRlci4gIFRoaXMgbWVhbnMg dGhhdCB3aGVuIGEgbmV3IEENCiAgIGlzIGNyZWF0ZWQsIGl0IG1heSBiZSBhc3NvY2lhdGVkIHdp dGggYSBCIHRoYXQgaXMgYWxyZWFkeSBhc3NvY2lhdGVkDQogICB3aXRoIG90aGVyIEEncy4NCgog ICBUaGUgTUlCIG1vZHVsZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgY2FzdCBhcyBhIGdl bmVyYWwtcHVycG9zZQ0KICAgbW9kdWxlIGZvciBhbGwgdGhlIHRleHR1YWwgY29udmVudGlvbnMg dGhhdCBtaWdodCBiZSBkZWZpbmVkIHRvDQogICBzdXBwb3J0IGxhcmdlLXNjYWxlIGNvbmZpZ3Vy YXRpb24gdmlhIFNOTVAuICBDdXJyZW50bHkgdGhlIG1vZHVsZQ0KICAgY29udGFpbnMgb25seSB0 aGUgdHdvIFJvd1BvaW50ZXItbGlrZSB0ZXh0dWFsIGNvbnZlbnRpb25zIHVzZWQgaW4gdGhlDQog ICBwcm9jZXNzIG9mIGNyZWF0aW5nIGluc3RhbmNlLWxldmVsIGNvbmZpZ3VyYXRpb25zIHZpYSBj bG9uaW5nLg0KCgogMi4gRGVmaW5pdGlvbnMNCgogICBTTk1QLUNPTkZJR1VSQVRJT04tVENTLU1J QiBERUZJTklUSU9OUyA6Oj0gQkVHSU4NCgoKICAgICAgSU1QT1JUUw0KICAgICAgICBNT0RVTEUt SURFTlRJVFksIG1pYi0yIEZST00gU05NUHYyLVNNSQ0KICAgICAgICBURVhUVUFMLUNPTlZFTlRJ T04gICAgIEZST00gU05NUHYyLVRDOw0KCgogICAgICBzbm1wQ29uZmlndXJhdGlvblRDc01JQiBN T0RVTEUtSURFTlRJVFkNCiAgICAgICAgTEFTVC1VUERBVEVEICIyMDAwMTExNDAwMDBaIiAtLSBO b3ZlbWJlciAxNCwgMjAwMA0KICAgICAgICBPUkdBTklaQVRJT04NCiAgICAgICAgICAgICJTTk1Q IENvbmZpZ3VyYXRpb24gV0ciDQogICAgICAgIENPTlRBQ1QtSU5GTw0KICAgICAgICAgICAgIkJv YiBNb29yZQ0KICAgICAgICAgICAgIElCTSBDb3Jwb3JhdGlvbiwgQlJRQS81MDINCiAgICAgICAg ICAgICBQTyBCb3ggMTIxOTUNCiAgICAgICAgICAgICBSZXNlYXJjaCBUcmlhbmdsZSBQYXJrLCBO QyAyNzcwOSwgVVNBDQogICAgICAgICAgICAgUGhvbmU6ICsxIDkxOSAyNTQgNDQzNg0KICAgICAg ICAgICAgIEVNYWlsOiByZW1vb3JlQHVzLmlibS5jb20NCgogICAgICAgICAgICAgS3dvayBIbyBD aGFuDQogICAgICAgICAgICAgTm9ydGVsIE5ldHdvcmtzDQogICAgICAgICAgICAgNjAwIFRlY2hu b2xvZ3kgUGFyayBEcml2ZQ0KICAgICAgICAgICAgIEJpbGxlcmljYSwgTUEgMDE4MjEsIFVTQQ0K ICAgICAgICAgICAgIEUtbWFpbDoga2hjaGFuQG5vcnRlbG5ldHdvcmtzLmNvbQ0KCiAgICAgICAg ICAgICBTZW5kIGNvbW1lbnRzIHRvIHNtbnBjb25mQG9wcy5pZXRmLm9yZy4iDQoKICAgICAgREVT Q1JJUFRJT04NCiAgICAgICAgIlRoaXMgTUlCIG1vZHVsZSBkZWZpbmVzIHRleHR1YWwgY29udmVu dGlvbnMgdXNlZnVsDQoKCiBNb29yZSBhbmQgQ2hhbiAgICAgICAgRXhwaXJlczogTm92IDIwMDAg KyA2IG1vbnRocyAgICAgICAgICAgICBbUGFnZSAzXQ0MDQogSW50ZXJuZXQgRHJhZnQgICBTTk1Q IENvbmZpZ3VyYXRpb24gVGV4dHVhbCBDb252ZW50aW9ucyAgIE5vdmVtYmVyIDIwMDANCgoKICAg ICAgICAgZm9yIHBvbGljeS1iYXNlZCBjb25maWd1cmF0aW9uIHVzaW5nIFNOTVAuIg0KCiAgICAg IFJFVklTSU9OICAgICAiMjAwMDExMTQwMDAwWiIgLS0gTm92ZW1iZXIgMTQsIDIwMDANCiAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgIkluaXRpYWwgdmVyc2lvbiwgcHVibGlzaGVkIGFzIFJG Q25ubm4uIg0KICAgICAgOjo9IHsgbWliLTIgNjc4OTAgfSAtLSB0byBiZSBhc3NpZ25lZCBieSBJ QU5BDQoKCiAgIER5bmFtaWNSb3dQb2ludGVyIDo6PSBURVhUVUFMLUNPTlZFTlRJT04NCiAgICAg ICBTVEFUVVMgICAgICAgY3VycmVudA0KICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAg ICAiTGlrZSBhIFJvd1BvaW50ZXIsIHRoaXMgdGV4dHVhbCBjb252ZW50aW9uDQogICAgICAgICAg ICAgICByZXByZXNlbnRzIGEgcG9pbnRlciB0byBhIGNvbmNlcHR1YWwgcm93Lg0KICAgICAgICAg ICAgICAgVGhlIHZhbHVlIGlzIHRoZSBuYW1lIG9mIHRoZSBpbnN0YW5jZSBvZiB0aGUNCiAgICAg ICAgICAgICAgIGZpcnN0IGFjY2Vzc2libGUgY29sdW1uYXIgb2JqZWN0IGluIHRoZQ0KICAgICAg ICAgICAgICAgY29uY2VwdHVhbCByb3cuDQoKICAgICAgICAgICAgICAgVGhlIGFkZGl0aW9uYWwg c2VtYW50aWNzIG9mIHRoaXMgdGV4dHVhbA0KICAgICAgICAgICAgICAgY29udmVudGlvbiwgcmVs YXRpdmUgdG8gUm93UG9pbnRlciwgYXJlDQogICAgICAgICAgICAgICByZWxhdGVkIHRvIHRoZSBj cmVhdGlvbiBvZiBpbnN0YW5jZS1zcGVjaWZpYw0KICAgICAgICAgICAgICAgb2JqZWN0cyBieSBj bG9uaW5nLiAgVGhlIG9iamVjdHMgYmVpbmcgY2xvbmVkDQogICAgICAgICAgICAgICBtYXkgZWl0 aGVyIGJlIHNwZWNpYWwgb25lcyB0aGF0IGV4cHJlc3MNCiAgICAgICAgICAgICAgIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24gYXQgdGhlDQogICAgICAgICAgICAgICBpbXBsZW1lbnRhdGlvbi1z cGVjaWZpYyBsZXZlbCwgb3Igc2ltcGx5DQogICAgICAgICAgICAgICBpbnN0YW5jZS1zcGVjaWZp YyBvbmVzIHRoYXQgYWxyZWFkeSBleGlzdCBhdA0KICAgICAgICAgICAgICAgdGhlIHRpbWUgdGhl IGNsb25pbmcgaXMgZG9uZS4gIFdoZW4gYW4gb2JqZWN0DQogICAgICAgICAgICAgICB3aXRoIHRo ZSBzeW50YXggRHluYW1pY1Jvd1BvaW50ZXIgaXMgY2xvbmVkLA0KICAgICAgICAgICAgICAgYSBu ZXcgY29uY2VwdHVhbCByb3cgaXMgY3JlYXRlZCBiYXNlZCBvbiB0aGUNCiAgICAgICAgICAgICAg IGNvbmNlcHR1YWwgcm93IHBvaW50ZWQgdG8gYnkgdGhlDQogICAgICAgICAgICAgICBEeW5hbWlj Um93UG9pbnRlciBpbiB0aGUgY2xvbmVkLWZyb20gb2JqZWN0LA0KICAgICAgICAgICAgICAgYW5k IHRoZSBEeW5hbWljUm93UG9pbnRlciBpbiB0aGUgbmV3bHkgY2xvbmVkDQogICAgICAgICAgICAg ICBvYmplY3QgaXMgc2V0IHRvIHBvaW50IHRvIHRoaXMgbmV3IGNvbmNlcHR1YWwNCiAgICAgICAg ICAgICAgIHJvdy4gIFRoZSBjbG9uaW5nIG9wZXJhdGlvbnMgbWF5IGJlDQogICAgICAgICAgICAg ICBhY2NvbXBsaXNoZWQgZWl0aGVyIHdpdGggdGhlIHNjcmlwdC1iYXNlZA0KICAgICAgICAgICAg ICAgdGVjaG5pcXVlIGRlZmluZWQgYnkgU05NUCBDb25maWd1cmF0aW9uLCBvciBieQ0KICAgICAg ICAgICAgICAgb3JkaW5hcnkgU05NUCBHZXQgYW5kIFNldCBvcGVyYXRpb25zLg0KCiAgICAgICAg ICAgICAgIFdoZW4gY2xvbmluZyBpcyBub3QgaW52b2x2ZWQsIHRoaXMgdGV4dHVhbA0KICAgICAg ICAgICAgICAgY29udmVudGlvbiBiZWhhdmVzIGlkZW50aWNhbGx5IHRvIHRoZSBSb3dQb2ludGVy DQogICAgICAgICAgICAgICB0ZXh0dWFsIGNvbnZlbnRpb24uICBTcGVjaWZpY2FsbHksIG9uY2Ug YW4gb2JqZWN0DQogICAgICAgICAgICAgICB3aXRoIHRoaXMgc3ludGF4IGhhcyBiZWVuIGNyZWF0 ZWQsIGVpdGhlciBieQ0KICAgICAgICAgICAgICAgY2xvbmluZyBvciBieSBvdGhlciBtZWFucywg aXRzIHZhbHVlIG1heSBiZQ0KICAgICAgICAgICAgICAgdXBkYXRlZCBpbiB0aGUgc2FtZSB3YXkg dGhhdCB0aGUgdmFsdWUgb2YgYW55DQogICAgICAgICAgICAgICBvdGhlciBvYmplY3Qgd2l0aCBy ZWFkLXdyaXRlIG9yIHJlYWQtY3JlYXRlDQogICAgICAgICAgICAgICBhY2Nlc3MgbWF5IGJlIHVw ZGF0ZWQuIg0KICAgICAgIFNZTlRBWCAgICAgICBPQkpFQ1QgSURFTlRJRklFUg0KCgoKICAgU3Rh dGljUm93UG9pbnRlciA6Oj0gVEVYVFVBTC1DT05WRU5USU9ODQogICAgICAgU1RBVFVTICAgICAg IGN1cnJlbnQNCiAgICAgICBERVNDUklQVElPTg0KCgogTW9vcmUgYW5kIENoYW4gICAgICAgIEV4 cGlyZXM6IE5vdiAyMDAwICsgNiBtb250aHMgICAgICAgICAgICAgW1BhZ2UgNF0NDA0KIEludGVy bmV0IERyYWZ0ICAgU05NUCBDb25maWd1cmF0aW9uIFRleHR1YWwgQ29udmVudGlvbnMgICBOb3Zl bWJlciAyMDAwDQoKCiAgICAgICAgICAgICAgICJMaWtlIGEgUm93UG9pbnRlciwgdGhpcyB0ZXh0 dWFsIGNvbnZlbnRpb24NCiAgICAgICAgICAgICAgIHJlcHJlc2VudHMgYSBwb2ludGVyIHRvIGEg Y29uY2VwdHVhbCByb3cuDQogICAgICAgICAgICAgICBUaGUgdmFsdWUgaXMgdGhlIG5hbWUgb2Yg dGhlIGluc3RhbmNlIG9mIHRoZQ0KICAgICAgICAgICAgICAgZmlyc3QgYWNjZXNzaWJsZSBjb2x1 bW5hciBvYmplY3QgaW4gdGhlDQogICAgICAgICAgICAgICBjb25jZXB0dWFsIHJvdy4NCgogICAg ICAgICAgICAgICBUaGUgYWRkaXRpb25hbCBzZW1hbnRpY3Mgb2YgdGhpcyB0ZXh0dWFsDQogICAg ICAgICAgICAgICBjb252ZW50aW9uLCByZWxhdGl2ZSB0byBSb3dQb2ludGVyLCBhcmUNCiAgICAg ICAgICAgICAgIHJlbGF0ZWQgdG8gdGhlIGNyZWF0aW9uIG9mIGluc3RhbmNlLXNwZWNpZmljDQog ICAgICAgICAgICAgICBvYmplY3RzIGJ5IGNsb25pbmcuICBUaGUgb2JqZWN0cyBiZWluZyBjbG9u ZWQNCiAgICAgICAgICAgICAgIG1heSBlaXRoZXIgYmUgc3BlY2lhbCBvbmVzIHRoYXQgZXhwcmVz cw0KICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBhdCB0aGUNCiAgICAg ICAgICAgICAgIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGxldmVsLCBvciBzaW1wbHkNCiAgICAg ICAgICAgICAgIGluc3RhbmNlLXNwZWNpZmljIG9uZXMgdGhhdCBhbHJlYWR5IGV4aXN0IGF0DQog ICAgICAgICAgICAgICB0aGUgdGltZSB0aGUgY2xvbmluZyBpcyBkb25lLiAgV2hlbiBhbiBvYmpl Y3QNCiAgICAgICAgICAgICAgIHdpdGggdGhlIHN5bnRheCBTdGF0aWNSb3dQb2ludGVyIGlzIGNs b25lZCwgdGhlDQogICAgICAgICAgICAgICBTdGF0aWNSb3dQb2ludGVyIGluIHRoZSBuZXdseSBj bG9uZWQgb2JqZWN0IGlzDQogICAgICAgICAgICAgICBzZXQgdG8gcG9pbnQgdG8gdGhlIHNhbWUg Y29uY2VwdHVhbCByb3cgdGhhdCB0aGUNCiAgICAgICAgICAgICAgIFN0YXRpY1Jvd1BvaW50ZXIg aW4gdGhlIGNsb25lZC1mcm9tIG9iamVjdA0KICAgICAgICAgICAgICAgcG9pbnRlZCB0by4gVGhl IGNsb25pbmcgb3BlcmF0aW9ucyBtYXkgYmUNCiAgICAgICAgICAgICAgIGFjY29tcGxpc2hlZCBl aXRoZXIgd2l0aCB0aGUgc2NyaXB0LWJhc2VkDQogICAgICAgICAgICAgICB0ZWNobmlxdWUgZGVm aW5lZCBieSBTTk1QIENvbmZpZ3VyYXRpb24sIG9yIGJ5DQogICAgICAgICAgICAgICBvcmRpbmFy eSBTTk1QIEdldCBhbmQgU2V0IG9wZXJhdGlvbnMuDQoKICAgICAgICAgICAgICAgV2hlbiBjbG9u aW5nIGlzIG5vdCBpbnZvbHZlZCwgdGhpcyB0ZXh0dWFsDQogICAgICAgICAgICAgICBjb252ZW50 aW9uIGJlaGF2ZXMgaWRlbnRpY2FsbHkgdG8gdGhlIFJvd1BvaW50ZXINCiAgICAgICAgICAgICAg IHRleHR1YWwgY29udmVudGlvbi4gIFNwZWNpZmljYWxseSwgb25jZSBhbiBvYmplY3QNCiAgICAg ICAgICAgICAgIHdpdGggdGhpcyBzeW50YXggaGFzIGJlZW4gY3JlYXRlZCwgZWl0aGVyIGJ5DQog ICAgICAgICAgICAgICBjbG9uaW5nIG9yIGJ5IG90aGVyIG1lYW5zLCBpdHMgdmFsdWUgbWF5IGJl DQogICAgICAgICAgICAgICB1cGRhdGVkIGluIHRoZSBzYW1lIHdheSB0aGF0IHRoZSB2YWx1ZSBv ZiBhbnkNCiAgICAgICAgICAgICAgIG90aGVyIG9iamVjdCB3aXRoIHJlYWQtd3JpdGUgb3IgcmVh ZC1jcmVhdGUNCiAgICAgICAgICAgICAgIGFjY2VzcyBtYXkgYmUgdXBkYXRlZC4iDQogICAgICAg U1lOVEFYICAgICAgIE9CSkVDVCBJREVOVElGSUVSDQoKICAgRU5EDQoKCgogMy4gSW50ZWxsZWN0 dWFsIFByb3BlcnR5DQoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRo ZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIGludGVsbGVjdHVhbCBwcm9wZXJ0eSBvciBv dGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvIHBlcnRhaW4NCiAgIHRvIHRoZSBp bXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluIHRoaXMN CiAgIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3Vj aCByaWdodHMgbWlnaHQgb3INCiAgIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5laXRoZXIgZG9l cyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMgbWFkZSBhbnkNCiAgIGVmZm9ydCB0byBpZGVudGlm eSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbiBvbiB0aGUgSUVURidzDQogICBwcm9jZWR1 cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRhcmRzLXRyYWNrIGFuZCBzdGFuZGFy ZHMtDQogICByZWxhdGVkIGRvY3VtZW50YXRpb24gY2FuIGJlIGZvdW5kIGluIEJDUC0xMS4NCgog ICBDb3BpZXMgb2YgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2YWlsYWJsZSBmb3IgcHVibGljYXRp b24gYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJs ZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVy YWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQoKCiBNb29yZSBhbmQgQ2hh biAgICAgICAgRXhwaXJlczogTm92IDIwMDAgKyA2IG1vbnRocyAgICAgICAgICAgICBbUGFnZSA1 XQ0MDQogSW50ZXJuZXQgRHJhZnQgICBTTk1QIENvbmZpZ3VyYXRpb24gVGV4dHVhbCBDb252ZW50 aW9ucyAgIE5vdmVtYmVyIDIwMDANCgoKICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1w bGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbg0KICAgY2FuIGJlIG9idGFp bmVkIGZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuDQoKICAgVGhlIElFVEYgaW52aXRlcyBhbnkg aW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJp Z2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFy eQ0KICAgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVp cmVkIHRvIHByYWN0aWNlDQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGlu Zm9ybWF0aW9uIHRvIHRoZSBJRVRGIEV4ZWN1dGl2ZQ0KICAgRGlyZWN0b3IuDQoKCiA0LiBBY2tu b3dsZWRnZW1lbnRzDQoKICAgVGhpcyBkb2N1bWVudCBncmV3IG91dCBvZiB0aGUgd29yayBvZiB0 aGUgU05NUCBDb25maWd1cmF0aW9uIHdvcmtpbmcNCiAgIGdyb3VwLg0KCgogNS4gU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMNCgogICBUaGlzIG1vZHVsZSBkb2VzIG5vdCBkZWZpbmUgYW55IG1hbmFn ZW1lbnQgb2JqZWN0cy4gSW5zdGVhZCwgaXQNCiAgIGRlZmluZXMgYSBzZXQgb2YgdGV4dHVhbCBj b252ZW50aW9ucyB0aGF0IG1heSBiZSB1c2VkIGJ5IG90aGVyIE1JQg0KICAgbW9kdWxlcyB0byBk ZWZpbmUgbWFuYWdlbWVudCBvYmplY3RzLg0KCiAgIE1lYW5pbmdmdWwgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgY2FuIG9ubHkgYmUgd3JpdHRlbiBpbiB0aGUgbW9kdWxlcw0KICAgdGhhdCBkZWZp bmUgbWFuYWdlbWVudCBvYmplY3RzLg0KCgogNi4gUmVmZXJlbmNlcw0KCiBbMV0gIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudA0K ICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCgogWzJdICBIYXJy aW5ndG9uLCBELiwgUHJlc3VobiwgUi4gYW5kIEIuIFdpam5lbiwgIkFuIEFyY2hpdGVjdHVyZSBm b3INCiAgICAgIERlc2NyaWJpbmcgU05NUCBNYW5hZ2VtZW50IEZyYW1ld29ya3MiLCBSRkMgMjU3 MSwgQXByaWwgMTk5OS4NCgogWzNdICBSb3NlLCBNLiBhbmQgSy4gTWNDbG9naHJpZSwgIlN0cnVj dHVyZSBhbmQgSWRlbnRpZmljYXRpb24gb2YNCiAgICAgIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24g Zm9yIFRDUC9JUC1iYXNlZCBJbnRlcm5ldHMiLCBTVEQgMTYsIFJGQw0KICAgICAgMTE1NSwgTWF5 IDE5OTAuDQoKIFs0XSAgUm9zZSwgTS4gYW5kIEsuIE1jQ2xvZ2hyaWUsICJDb25jaXNlIE1JQiBE ZWZpbml0aW9ucyIsIFNURCAxNiwNCiAgICAgIFJGQyAxMjEyLCBNYXJjaCAxOTkxLg0KCiBbNV0g IFJvc2UsIE0uLCAiQSBDb252ZW50aW9uIGZvciBEZWZpbmluZyBUcmFwcyBmb3IgdXNlIHdpdGgg dGhlDQogICAgICBTTk1QIiwgUkZDIDEyMTUsIE1hcmNoIDE5OTEuDQoKIFs2XSAgTWNDbG9naHJp ZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwgQ2FzZSwgSi4sIFJvc2UsDQog ICAgICBNLiBhbmQgUy4gV2FsZGJ1c3NlciwgIlN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50IEluZm9y bWF0aW9uDQogICAgICBWZXJzaW9uIDIgKFNNSXYyKSIsIFNURCA1OCwgUkZDIDI1NzgsIEFwcmls IDE5OTkuDQoKIFs3XSAgTWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVy LCBKLiwgQ2FzZSwgSi4sIFJvc2UsDQogICAgICBNLiBhbmQgUy4gV2FsZGJ1c3NlciwgIlRleHR1 YWwgQ29udmVudGlvbnMgZm9yIFNNSXYyIiwgU1REIDU4LA0KICAgICAgUkZDIDI1NzksIEFwcmls IDE5OTkuDQoKCgogTW9vcmUgYW5kIENoYW4gICAgICAgIEV4cGlyZXM6IE5vdiAyMDAwICsgNiBt b250aHMgICAgICAgICAgICAgW1BhZ2UgNl0NDA0KIEludGVybmV0IERyYWZ0ICAgU05NUCBDb25m aWd1cmF0aW9uIFRleHR1YWwgQ29udmVudGlvbnMgICBOb3ZlbWJlciAyMDAwDQoKCiBbOF0gIE1j Q2xvZ2hyaWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENhc2UsIEouLCBS b3NlLA0KICAgICAgTS4gYW5kIFMuIFdhbGRidXNzZXIsICJDb25mb3JtYW5jZSBTdGF0ZW1lbnRz IGZvciBTTUl2MiIsIFNURA0KICAgICAgNTgsIFJGQyAyNTgwLCBBcHJpbCAxOTk5Lg0KCiBbOV0g IENhc2UsIEouLCBGZWRvciwgTS4sIFNjaG9mZnN0YWxsLCBNLiBhbmQgSi4gRGF2aW4sICJBIFNp bXBsZQ0KICAgICAgTmV0d29yayBNYW5hZ2VtZW50IFByb3RvY29sIChTTk1QKSIsIFNURCAxNSwg UkZDIDExNTcsIE1heSAxOTkwLg0KCiBbMTBdIENhc2UsIEouLCBNY0Nsb2docmllLCBLLiwgUm9z ZSwgTS4gYW5kIFMuIFdhbGRidXNzZXIsDQogICAgICAiSW50cm9kdWN0aW9uIHRvIENvbW11bml0 eS1iYXNlZCBTTk1QdjIiLCBSRkMgMTkwMSwgSmFudWFyeQ0KICAgICAgMTk5Ni4NCgogWzExXSBD YXNlLCBKLiwgTWNDbG9naHJpZSwgSy4sIFJvc2UsIE0uIGFuZCBTLiBXYWxkYnVzc2VyLA0KICAg ICAgIlRyYW5zcG9ydCBNYXBwaW5ncyBmb3IgVmVyc2lvbiAyIG9mIHRoZSBTaW1wbGUgTmV0d29y aw0KICAgICAgTWFuYWdlbWVudCBQcm90b2NvbCAoU05NUHYyKSIsIFJGQyAxOTA2LCBKYW51YXJ5 IDE5OTYuDQoKIFsxMl0gQ2FzZSwgSi4sIEhhcnJpbmd0b24sIEQuLCBQcmVzdWhuLCBSLiBhbmQg Qi4gV2lqbmVuLCAiTWVzc2FnZQ0KICAgICAgUHJvY2Vzc2luZyBhbmQgRGlzcGF0Y2hpbmcgZm9y IHRoZSBTaW1wbGUgTmV0d29yayBNYW5hZ2VtZW50DQogICAgICBQcm90b2NvbCAoU05NUCkiLCBS RkMgMjU3MiwgQXByaWwgMTk5OS4NCgogWzEzXSBCbHVtZW50aGFsLCBVLiBhbmQgQi4gV2lqbmVu LCAiVXNlci1iYXNlZCBTZWN1cml0eSBNb2RlbCAoVVNNKQ0KICAgICAgZm9yIHZlcnNpb24gMyBv ZiB0aGUgU2ltcGxlIE5ldHdvcmsgTWFuYWdlbWVudCBQcm90b2NvbA0KICAgICAgKFNOTVB2Myki LCBSRkMgMjU3NCwgQXByaWwgMTk5OS4NCgogWzE0XSBDYXNlLCBKLiwgTWNDbG9naHJpZSwgSy4s IFJvc2UsIE0uIGFuZCBTLiBXYWxkYnVzc2VyLA0KICAgICAgIlByb3RvY29sIE9wZXJhdGlvbnMg Zm9yIFZlcnNpb24gMiBvZiB0aGUgU2ltcGxlIE5ldHdvcmsNCiAgICAgIE1hbmFnZW1lbnQgUHJv dG9jb2wgKFNOTVB2MikiLCBSRkMgMTkwNSwgSmFudWFyeSAxOTk2Lg0KCiBbMTVdIExldmksIEQu LCBNZXllciwgUC4gYW5kIEIuIFN0ZXdhcnQsICJTTk1QIEFwcGxpY2F0aW9ucyIsIFJGQw0KICAg ICAgMjU3MywgQXByaWwgMTk5OS4NCgogWzE2XSBXaWpuZW4sIEIuLCBQcmVzdWhuLCBSLiBhbmQg Sy4gTWNDbG9naHJpZSwgIlZpZXctYmFzZWQgQWNjZXNzDQogICAgICBDb250cm9sIE1vZGVsIChW QUNNKSBmb3IgdGhlIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQNCiAgICAgIFByb3RvY29sIChT Tk1QKSIsIFJGQyAyNTc1LCBBcHJpbCAxOTk5Lg0KCiBbMTddIENhc2UsIEouLCBNdW5keSwgUi4s IFBhcnRhaW4sIEQuIGFuZCBCLiBTdGV3YXJ0LCAiSW50cm9kdWN0aW9uDQogICAgICB0byBWZXJz aW9uIDMgb2YgdGhlIEludGVybmV0LXN0YW5kYXJkIE5ldHdvcmsgTWFuYWdlbWVudA0KICAgICAg RnJhbWV3b3JrIiwgUkZDIDI1NzAsIEFwcmlsIDE5OTkuDQoKCiA3LiBBdXRob3JzJyBBZGRyZXNz ZXMNCgogICBCb2IgTW9vcmUNCiAgICAgIElCTSBDb3Jwb3JhdGlvbiwgQlJRQS81MDINCiAgICAg IDQyMDUgUy4gTWlhbWkgQmx2ZC4NCiAgICAgIFJlc2VhcmNoIFRyaWFuZ2xlIFBhcmssIE5DIDI3 NzA5DQogICAgICBQaG9uZTogICArMSA5MTktMjU0LTQ0MzYNCiAgICAgIEZheDogICAgICsxIDkx OS0yNTQtNjI0Mw0KICAgICAgRS1tYWlsOiAgcmVtb29yZUB1cy5pYm0uY29tDQoKICAgS3dvayBI byBDaGFuDQogICAgICBOb3J0ZWwgTmV0d29ya3MNCiAgICAgIDYwMCBUZWNobm9sb2d5IFBhcmsg RHJpdmUNCgoKIE1vb3JlIGFuZCBDaGFuICAgICAgICBFeHBpcmVzOiBOb3YgMjAwMCArIDYgbW9u dGhzICAgICAgICAgICAgIFtQYWdlIDddDQwNCiBJbnRlcm5ldCBEcmFmdCAgIFNOTVAgQ29uZmln dXJhdGlvbiBUZXh0dWFsIENvbnZlbnRpb25zICAgTm92ZW1iZXIgMjAwMA0KCgogICAgICBCaWxs ZXJpY2EsIE1BIDAxODIxLCBVU0ENCiAgICAgIEUtbWFpbDoga2hjaGFuQG5vcnRlbG5ldHdvcmtz LmNvbQ0KCgogOC4gRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoKICAgQ29weXJpZ2h0IChDKSBU aGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMCkuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0KCiAgIFRo aXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJu aXNoZWQgdG8NCiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9u IG9yIG90aGVyd2lzZSBleHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0 aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kDQogICBkaXN0cmlidXRl ZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwN CiAgIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFy YWdyYXBoIGFyZQ0KICAgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZl IHdvcmtzLiAgSG93ZXZlciwgdGhpcw0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9k aWZpZWQgaW4gYW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZw0KICAgdGhlIGNvcHlyaWdodCBu b3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBvdGhlcg0KICAg SW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ug b2YgZGV2ZWxvcGluZw0KICAgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHBy b2NlZHVyZXMgZm9yIGNvcHlyaWdodHMgZGVmaW5lZA0KICAgaW4gdGhlIEludGVybmV0IFN0YW5k YXJkcyBwcm9jZXNzIG11c3QgYmUgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvDQogICB0cmFu c2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLg0KCiAgIFRoZSBsaW1p dGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3Qg YmUNCiAgIHJldm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMg b3IgYXNzaWducy4NCgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIElO VEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORw0KICAgVEFTSyBGT1JD RSBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5H IEJVVA0KICAgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUg SU5GT1JNQVRJT04gSEVSRUlODQogICBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFO WSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YNCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZP UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCiBNb29yZSBh bmQgQ2hhbiAgICAgICAgRXhwaXJlczogTm92IDIwMDAgKyA2IG1vbnRocyAgICAgICAgICAgICBb UGFnZSA4XQ0M --0__=85256998004A15A58f9e8a93df938690918c85256998004A15A5-- From owner-snmpconf@seymour39.SNMP.COM Wed Nov 15 09:38:47 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19832 for ; Wed, 15 Nov 2000 09:38:45 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA25557 for snmpconf-outgoing; Wed, 15 Nov 2000 09:25:58 -0500 (EST) Message-Id: <200011151425.JAA25540@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: snmpconf Re: Instance amplification in Diffserv MIB Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 15 Nov 2000 09:25:51 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id JAA25557 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA19832 I am resubmitting the following on behalf of Andrew Smith, whose email address has recently changed. ------- Forwarded Message From: Andrew Smith To: "'Robert Moore/Raleigh/IBM '" Cc: "''diffserv@ietf.org ' ' '" , "'snmpconf@snmp.com'" Subject: Instance amplification in Diffserv MIB Date: Tue, 14 Nov 2000 14:15:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04E88.5FF367C0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04E88.5FF367C0 Content-Type: text/plain; charset="iso-8859-1" Bob, [Apologies for the cross-posting to snmpconf but this is of relevance there, I think. Besides, there's not much traffic on that list right now :-)] I think this is the usual 'C' discussion case of "do you use a subroutine or place the code inline?". Sometimes one is best, sometimes the other, depending on how you see it being used. i.e. we could come up with other examples where hard-coupling the meter entries and the configuration value entries is *more* efficient. Now I must admit that I hadn't noticed until now (a list of "-04 to -05 changes" would have helped) that the -05 MIB now totally decouples the diffServTBMeterTable from the diffServTBMeterTable - the indexing is no longer common: if you do this then, of course, you have to allow independent parent/child row creation. If you hard-couple the two tables with common indexing, as it was in the -04 draft, then the first part of your argument below is somewhat moot - whether a "column" is placed in the parent table or in the child table does not really affect the implementation complexity or the "number of entries" involved - in your example it would not be 200 entries it would be 100 entries with the columns split between 2 tables sharing common indexing (the child effectively "AUGMENTS" the parent table entry although that is not the right SMI syntax to use). I'd argue that, in fact, that is less complex for the agent (far less spaghetti-pointer-interdependance-checking for the agent) and only marginally less efficient in protocol operations. The second part of your argument does hold though - if you want to change all of the values for all of the meters at once then it is much more protocol-efficient to have a single MIB variable instead of having to change each instance. So, is this going to be the most common operational scenario? I don't know. But I don't think that this "low-level" "raw" Diffserv MIB needs to be optimised for protocol efficiency - that is a job for the snmpconf work - this Diffserv MIB is already far too clumsy to be protocol-efficient for configuration usage on a box with more than a handful of interfaces. What you are arguing here is a need for some sort of "templating" capability for these objects: this is something that was discussed at length in the early snmpconf meetings (I wasn't at the last one so I don't know if this is still a goal) and was being called "instance amplification". The problem, in brief was "how do we apply a template of values for config parameters (columns) to a whole collection of instances (table entries)?" and there were hopes that snmpconf work would produce some sort of generic solution to this problem. What you are describing here is a local solution for this problem for this particular MIB, so I would ask you and Harrie to comment on whether we are duplicating effort here or just moving this solution from being a snmpconf work item to being a part of this diffserv MIB? If the latter then that's just fine but we do need to check for consistency with the solutions being worked on in snmpconf (yes Brian, that would mean a two-way dependency between these work items). If the former then I think that the duplication of solutions would be a Bad Thing. [Maybe someone can put my mind at rest on this - I must apologise for having missed out on recent snmpconf happenings - I'm trying to catch up though] Andrew Smith -----Original Message----- From: Robert Moore/Raleigh/IBM To: Andrew Smith Cc: 'Harrie Hazewinkel '; ''diffserv@ietf.org ' ' Sent: 11/13/00 10:24 AM Subject: RE: [Diffserv] draft-ietf-diffserv-mib-05.txt posted Andrew, I don't think this is what Harrie was talking about. The case he mentioned is not multiple daughters for one parent -- it's multiple parents sharing one daughter. We discussed this at some length at the snmpconf interim in Knoxville. The idea is that if you have, say, 100 interfaces where you need meters that are configured in exactly the same way, you'll need 100 meter instances (because these represent operational information as well as configuration values), but only 1 daughter entry to provide the configuration values for all of the meters. Not only does this result in fewer entries overall (101 rather than 200), it makes it easy to reconfigure all of the meters at the same time. Kwok and I will be publishing an Internet-Draft this week with two textual conventions that capture generalized versions of the DiffServ MIB's "next" pointers and "specific" pointers. We expect these textual conventions to be put on the standards track through the snmpconf WG, at which point they can be referenced by the next version of the DiffServ MIB. So my answers to issues 23 and 31 are different from yours: 23. Daughter entries can exist independently of their parent entries. 31. In the sense the question was asked: The linkage from parent to daughter should be a RowPointer, rather than an OID that points to the table root. Really, though, these pointers should use the syntax StaticRowPointer (coming later this week, in a draft that's going to be called either draft-moore-snmpconf-tcs-00.txt or draft-ietf-smnpconf-tcs-00.txt). Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Andrew Smith @ietf.org on 11/10/2000 02:02:29 PM Sent by: diffserv-admin@ietf.org To: "'Harrie Hazewinkel '" cc: "''diffserv@ietf.org ' '" Subject: RE: [Diffserv] draft-ietf-diffserv-mib-05.txt posted Harrie, I am only referring to the case(s) in the current MIB where indexing is common between parent and child i.e. it is a pure inheritance relationship (the child object represents the parent object extended with extra properties). This forces there to be either zero or one daughters for any parent. Are you proposing that we need to allow for greater than one daughter object for such cases? If so then there are other indexing changes e.g. to diffServTBMeterTable that you need to propose. I think the WG consensus on the intent of current MIB is as follows (please correct me if I'm wrong, somebody): if a vendor implements their own diffServXXMeterTable they have a choice: either they extend the token-bucket definition in diffServTBMeterTable (in the case where they consider their new meter to be a sub-type of token-bucket meter) or else they extend the base diffServMeterTable instead. But you have to pick one - you cannot say "my new meter is a bit like a TB meter but I don't want to use property XX, I want my own property YY which is in my private MIB". For that you have to extend the base diffServMeterTable table and (potentially) replicate those properties that you do want to steal from diffServTBMeterTable in your own MIB. Andrew -----Original Message----- From: Harrie Hazewinkel To: Andrew Smith Cc: 'diffserv@ietf.org ' Sent: 11/9/00 1:06 PM Subject: Re: [Diffserv] draft-ietf-diffserv-mib-05.txt posted Hi, Comments in line. > Andrew Smith wrote: > > Brian asked for arguments on the open issues. > > Issue 23: > > (23) Do daughter entries of derived table entries need to exist > >      independently of the parent?  Examples are > >      diffServMeterEntry/diffServTBMeterEntry, > >      diffServActionEntry/diffServCountActEntry and > >      diffServAlgDropEntry/diffServRandomDropEntry (assume they must be > >      independent of the equivalent entry in diffServMeterTable which > >      points at the TB table - needs diffServTBMeterStatus: daughters > >      must be created explicitly by manager). > > I've argued all along that the current solution (-05 draft) makes a > manager jump through such hoops as to make this attempt at > object-oriented MIB design too complex to be of much use. My opinion > is that, in nearly all cases, there is no need to have the daughter > entry exist if the parent is deleted and vice-versa. You make an assumption that 1 parent can have only 1 daughter. I would argue parents could share daughters. Like in real life, parents come in packages of 2 (father/mother). :-)) Maybe it is wrong to have the entries mapped onto a parent daughter paradigma. IMHO, multiple entries (top-level) could share a parameter (detailed) entry. > There is no need > to have independent RowStatus variables with all their associated > complexity (I believe that about 80% of the > implementation/testing/maintenance complexity for a table with > row-create/delete capabilities is in the RowStatus column). Of course > the real solution is to redesign SMI to increase its OO capabilities > but that is not a topic for this WG. But within the constraints of > SMIv2 I think that we can do a better job than the current draft. The > main argument I've heard against this approach is that "that's not how > we've done MIBs in the past". I'm still waiting for some technical > counter-arguments. I don't know what precise thing you are goaling for here. > > For specific proposed changes for, e.g. diffServTBMeterTable, we > should go back to what was intended in the -03 draft: the last > paragraph of the DESCRIPTION for diffServTBMeterTable should read: > > "Entries in this table share indexing with those in the base > diffServMeterTable: they appear in this table whenever an base entry > that shares the same indexing and has a diffServMeterSpecific value > that points to this table comes into existence. They disappear either > when the base entry does or when the base entry's > diffServMeterSpecific value no longer points to this table." I understand your point here, but what happens if a vendor comes up with his own detailed diffServXXMeterTable that provides parameters for his implemented meter. Then in as well the diffServTBMeterTable and diffServXXMeterTable the same index can be used and its parameters can conflict with each other. I understand the complexity grows, but with a 'specificPointer' (not index sharing) we are sure there is only 1 entry providing parameters for a table. By using the 'specificPointer' in a table instead of indexing it could well be that the detailed (daughter) entries are shared among parents. With other words, 2 diffServMeterEntries could have the same diffServTBMeterEntry for its parameters. IMHO, there is no need to duplicate the diffServTBMeterEntry. Having both a specific pointer and a shared index the data in the MIB can be ambiguous. So the only possibility is selecting or a specific pointer or a shared index. As described above, I believe having the specific pointer makes it totally unambiguous. > > I think this is the only instance of a parent/daughter table like this > in this MIB module although others could arise in other MIBs that > tried to use the base tables in this Diffserv MIB. > > Issue 31: > > (31) When inheritance is needed and parent/daughter share indexing, the > >      parent often points to the daughter using a "Specific" attribute > >      e.g. diffServMeterSpecific, diffServActionSpecific, > >      diffServAlgDropSpecific. If this is a RowPointer and points to the > >      associated row in the daughter's table, there is redundant > >      information which gives scope for additional error cases. So, > >      wherever possible, should we remove this redundant information by > >      making the "Specific" attribute point only to the base of the > >      daughter table and make it an OBJECT IDENTIFIER? The con is that > >      this is an unusual use of MIB pointers (point at table base, not > >      individual entries). > > Again, I've argued all along that allowing the provision of redundant > information is the root of most evil (i.e. complexity) in handling > error cases. Yes, the redudancy creates unambiguous data in the MIB. (see above) > And again I've only heard a Luddite counter-argument. For > specific changes, go back to the -04 draft description/syntax for e.g. > diffServMeterSpecific (there's a separate discussion of whether the > syntax should then be RowPointer or OBJECT IDENTIFIER but let's leave > that for now). I agree, selecting a RowPointer or OBJECT IDENTIFIER is less important. I would say select OBJECT IDENTIFIER which can be a RowPointer, but a RowPointer can not be an OBJECT IDENTIFIER. The RowPointer is a subset with restricted semantics. Harrie 0- Harrie Hazewinkel ---------------------------------------0  mailto:harrie@covalent.net            phone:+1-415-536-5221 0-----------------------------------------------------------0 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ ------_=_NextPart_001_01C04E88.5FF367C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Instance amplification in Diffserv MIB

Bob,

[Apologies for the cross-posting to snmpconf but this = is of relevance there, I think. Besides, there's not much traffic on = that list right now :-)]

I think this is the usual 'C' discussion case of = "do you use a subroutine or place the code inline?". = Sometimes one is best, sometimes the other, depending on how you see it = being used. i.e. we could come up with other examples where = hard-coupling the meter entries and the configuration value entries is = *more* efficient.

Now I must admit that I hadn't noticed until now (a = list of "-04 to -05 changes" would have helped) that the -05 = MIB now totally decouples the diffServTBMeterTable from the = diffServTBMeterTable - the indexing is no longer common: if you do this = then, of course, you have to allow independent parent/child row = creation.

If you hard-couple the two tables with common = indexing, as it was in the -04 draft, then the first part of your = argument below is somewhat moot - whether a "column" is = placed in the parent table or in the child table does not really affect = the implementation complexity or the "number of entries" = involved - in your example it would not be 200 entries it would be 100 = entries with the columns split between 2 tables sharing common indexing = (the child effectively "AUGMENTS" the parent table entry = although that is not the right SMI syntax to use). I'd argue that, in = fact, that is less complex for the agent (far less = spaghetti-pointer-interdependance-checking for the agent) and only = marginally less efficient in protocol operations.

The second part of your argument does hold though - = if you want to change all of the values for all of the meters at once = then it is much more protocol-efficient to have a single MIB variable = instead of having to change each instance. So, is this going to be the = most common operational scenario? I don't know. But I don't think that = this "low-level" "raw" Diffserv MIB needs to be = optimised for protocol efficiency - that is a job for the snmpconf work = - this Diffserv MIB is already far too clumsy to be protocol-efficient = for configuration usage on a box with more than a handful of = interfaces.

What you are arguing here is a need for some sort of = "templating" capability for these objects: this is something = that was discussed at length in the early snmpconf meetings (I wasn't = at the last one so I don't know if this is still a goal) and was being = called "instance amplification". The problem, in brief was = "how do we apply a template of values for config parameters = (columns) to a whole collection of instances (table entries)?" and = there were hopes that snmpconf work would produce some sort of generic = solution to this problem. What you are describing here is a local = solution for this problem for this particular MIB, so I would ask you = and Harrie to comment on whether we are duplicating effort here or just = moving this solution from being a snmpconf work item to being a part of = this diffserv MIB? If the latter then that's just fine but we do need = to check for consistency with the solutions being worked on in snmpconf = (yes Brian, that would mean a two-way dependency between these work = items). If the former then I think that the duplication of solutions = would be a Bad Thing.

[Maybe someone can put my mind at rest on this - I = must apologise for having missed out on recent snmpconf happenings - = I'm trying to catch up though]


Andrew Smith



-----Original Message-----
From: Robert Moore/Raleigh/IBM
To: Andrew Smith
Cc: 'Harrie Hazewinkel '; ''diffserv@ietf.org ' = '
Sent: 11/13/00 10:24 AM
Subject: RE: [Diffserv] = draft-ietf-diffserv-mib-05.txt posted

Andrew,

I don't think this is what Harrie was talking = about.  The case
he mentioned is not multiple daughters for one = parent -- it's
multiple parents sharing one daughter.

We discussed this at some length at the snmpconf = interim in
Knoxville.  The idea is that if you have, say, = 100 interfaces
where you need meters that are configured in exactly = the same
way, you'll need 100 meter instances (because these = represent
operational information as well as configuration = values), but
only 1 daughter entry to provide the configuration = values for
all of the meters.  Not only does this result = in fewer entries
overall (101 rather than 200), it makes it easy to = reconfigure
all of the meters at the same time.

Kwok and I will be publishing an Internet-Draft this = week with
two textual conventions that capture generalized = versions of
the DiffServ MIB's "next" pointers and = "specific" pointers.
We expect these textual conventions to be put on the = standards
track through the snmpconf WG, at which point they = can be
referenced by the next version of the DiffServ = MIB.

So my answers to issues 23 and 31 are different from = yours:

23. Daughter entries can exist independently of = their
    parent entries.

31. In the sense the question was asked:  The = linkage from
    parent to daughter should be a = RowPointer, rather than
    an OID that points to the table = root.  Really, though,
    these pointers should use the = syntax StaticRowPointer
    (coming later this week, in a = draft that's going to be
    called either = draft-moore-snmpconf-tcs-00.txt or
    = draft-ietf-smnpconf-tcs-00.txt).

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



Andrew Smith = <andrew@allegronetworks.com>@ietf.org on 11/10/2000
02:02:29
PM

Sent by:  diffserv-admin@ietf.org


To:   "'Harrie Hazewinkel '" = <harrie@covalent.net>
cc:   "''diffserv@ietf.org ' '" = <diffserv@ietf.org>
Subject:  RE: [Diffserv] = draft-ietf-diffserv-mib-05.txt posted





Harrie,

I am only referring to the case(s) in the current MIB = where indexing is
common between parent and child i.e. it is a pure = inheritance
relationship
(the child object represents the parent object = extended with extra
properties). This forces there to be either zero or = one daughters for
any
parent. Are you proposing that we need to allow for = greater than one
daughter object for such cases? If so then there are = other indexing
changes
e.g. to diffServTBMeterTable that you need to = propose.

I think the WG consensus on the intent of current MIB = is as follows
(please
correct me if I'm wrong, somebody): if a vendor = implements their own
diffServXXMeterTable they have a choice: either they = extend the
token-bucket definition in diffServTBMeterTable (in = the case where they
consider their new meter to be a sub-type of = token-bucket meter) or else
they extend the base diffServMeterTable instead. But = you have to pick
one -
you cannot say "my new meter is a bit like a TB = meter but I don't want
to
use property XX, I want my own property YY which is = in my private MIB".
For
that you have to extend the base diffServMeterTable = table and
(potentially)
replicate those properties that you do want to steal = from
diffServTBMeterTable in your own MIB.

Andrew

-----Original Message-----
From: Harrie Hazewinkel
To: Andrew Smith
Cc: 'diffserv@ietf.org '
Sent: 11/9/00 1:06 PM
Subject: Re: [Diffserv] = draft-ietf-diffserv-mib-05.txt posted

Hi,

Comments in line.

> Andrew Smith wrote:
>
> Brian asked for arguments on the open = issues.
>
> Issue 23:
> > (23) Do daughter entries of derived table = entries need to exist
> >=A0=A0=A0=A0=A0 independently of the = parent?=A0 Examples are
> >=A0=A0=A0=A0=A0 = diffServMeterEntry/diffServTBMeterEntry,
> >=A0=A0=A0=A0=A0 = diffServActionEntry/diffServCountActEntry and
> >=A0=A0=A0=A0=A0 = diffServAlgDropEntry/diffServRandomDropEntry (assume they must
be
> >=A0=A0=A0=A0=A0 independent of the = equivalent entry in diffServMeterTable which

> >=A0=A0=A0=A0=A0 points at the TB table - = needs diffServTBMeterStatus: daughters

> >=A0=A0=A0=A0=A0 must be created explicitly = by manager).
>
> I've argued all along that the current solution = (-05 draft) makes a
> manager jump through such hoops as to make this = attempt at
> object-oriented MIB design too complex to be of = much use. My opinion
> is that, in nearly all cases, there is no need = to have the daughter
> entry exist if the parent is deleted and = vice-versa.

You make an assumption that 1 parent can have only 1 = daughter.
I would argue parents could share daughters.
Like in real life, parents come in packages of 2 = (father/mother). :-))

Maybe it is wrong to have the entries mapped onto a = parent daughter
paradigma. IMHO, multiple entries (top-level) could = share a
parameter (detailed) entry.

> There is no need
> to have independent RowStatus variables with = all their associated
> complexity (I believe that about 80% of = the
> implementation/testing/maintenance complexity = for a table with
> row-create/delete capabilities is in the = RowStatus column). Of course
> the real solution is to redesign SMI to = increase its OO capabilities
> but that is not a topic for this WG. But within = the constraints of
> SMIv2 I think that we can do a better job than = the current draft. The
> main argument I've heard against this approach = is that "that's not how
> we've done MIBs in the past". I'm still = waiting for some technical
> counter-arguments.

I don't know what precise thing you are goaling for = here.

>
> For specific proposed changes for, e.g. = diffServTBMeterTable, we
> should go back to what was intended in the -03 = draft: the last
> paragraph of the DESCRIPTION for = diffServTBMeterTable should read:
>
> "Entries in this table share indexing with = those in the base
> diffServMeterTable: they appear in this table = whenever an base entry
> that shares the same indexing and has a = diffServMeterSpecific value
> that points to this table comes into existence. = They disappear either
> when the base entry does or when the base = entry's
> diffServMeterSpecific value no longer points to = this table."

I understand your point here, but what happens if a = vendor comes
up with his own detailed diffServXXMeterTable that = provides
parameters for his implemented meter. Then in as = well the
diffServTBMeterTable and diffServXXMeterTable the = same index
can be used and its parameters can conflict with = each other.

I understand the complexity grows, but with a = 'specificPointer'
(not index sharing) we are sure there is only 1 = entry
providing parameters for a table.

By using the 'specificPointer' in a table instead of = indexing
it could well be that the detailed (daughter) = entries are
shared among parents.
With other words, 2 diffServMeterEntries could have = the
same diffServTBMeterEntry for its parameters. = IMHO,
there is no need to duplicate the = diffServTBMeterEntry.

Having both a specific pointer and a shared index = the
data in the MIB can be ambiguous. So the only = possibility is
selecting or a specific pointer or a shared = index.
As described above, I believe having the specific = pointer
makes it totally unambiguous.

>
> I think this is the only instance of a = parent/daughter table like this
> in this MIB module although others could arise = in other MIBs that
> tried to use the base tables in this Diffserv = MIB.
>
> Issue 31:
> > (31) When inheritance is needed and = parent/daughter share indexing,
the
> >=A0=A0=A0=A0=A0 parent often points to the = daughter using a "Specific"
attribute
> >=A0=A0=A0=A0=A0 e.g. diffServMeterSpecific, = diffServActionSpecific,
> >=A0=A0=A0=A0=A0 diffServAlgDropSpecific. If = this is a RowPointer and points to
the
> >=A0=A0=A0=A0=A0 associated row in the = daughter's table, there is redundant
> >=A0=A0=A0=A0=A0 information which gives = scope for additional error cases. So,
> >=A0=A0=A0=A0=A0 wherever possible, should = we remove this redundant information
by
> >=A0=A0=A0=A0=A0 making the = "Specific" attribute point only to the base of the
> >=A0=A0=A0=A0=A0 daughter table and make it = an OBJECT IDENTIFIER? The con is
that
> >=A0=A0=A0=A0=A0 this is an unusual use of = MIB pointers (point at table base,
not
> >=A0=A0=A0=A0=A0 individual entries).
>
> Again, I've argued all along that allowing the = provision of redundant
> information is the root of most evil (i.e. = complexity) in handling
> error cases.

Yes, the redudancy creates unambiguous data in the = MIB. (see above)

> And again I've only heard a Luddite = counter-argument. For
> specific changes, go back to the -04 draft = description/syntax for e.g.
> diffServMeterSpecific (there's a separate = discussion of whether the
> syntax should then be RowPointer or OBJECT = IDENTIFIER but let's leave
> that for now).

I agree, selecting a RowPointer or OBJECT IDENTIFIER = is
less important. I would say select OBJECT IDENTIFIER = which
can be a RowPointer, but a RowPointer can not be an = OBJECT IDENTIFIER.
The RowPointer is a subset with restricted = semantics.

Harrie
0- Harrie Hazewinkel = ---------------------------------------0
=A0mailto:harrie@covalent.net=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 phone:+1-415-536-5221
0-----------------------------------------------------------0

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


------_=_NextPart_001_01C04E88.5FF367C0-- ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Wed Nov 15 11:12:40 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27419 for ; Wed, 15 Nov 2000 11:12:39 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA27297 for snmpconf-outgoing; Wed, 15 Nov 2000 10:58:58 -0500 (EST) Message-Id: <4.3.2.7.2.20001115102653.00cc3100@192.168.1.99> X-Sender: phalpern@192.168.1.99 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Nov 2000 10:59:10 -0500 To: snmpconf@snmp.com, snmpconf@snmp.com From: Pablo Halpern Subject: Re: snmpconf A non-trivial policyAction example In-Reply-To: <3A0A65E6.2BDBEC54@nextbeacon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 12:52 AM 11/9/00 -0800, Steve Waldbusser wrote: Enough RMON2 background, here's the script: In my never-ending crusade to introduce a native string type, let me rewrite the above script using such a native type based on the following assumptions: a quoted string is of type "string" Strings can be assigned using the '=' operator Strings can be concatenated using the '+' infix operator (as in C++) Using the + operator to add an integer to a string converts the integer to a string first. Below is the original script interleaved with my revisions > char oid[STRINGLEN], value[STRINGLEN]; /* The declarations of oid and value are not necessary in the revised example, * but for exposition, here is what they would look like: */ string oid, value; > int index, pdu; > > pdu = 0; /* Use PDU #0 */ > if (!(index = setRowStatus("hlMatrixControlStatus.*", 20))) > return; /* couldn't find a free entry */ The above code would be unchanged. > sprintf(oid, "hlMatrixControlDataSource.%d", index); > sprintf(value, "ifIndex.%d", $1); > writeVarbind(pdu, 0, oid, TYPE_OBJECT_IDENTIFIER, value, 0); /* No need to pass a length argument */ writeVarbind(pdu, 0, "hlMatrixControlDataSource." + index, TYPE_OBJECT_IDENTIFIER, "ifIndex." + $1); > sprintf(oid, "hlMatrixControlNlMaxDesiredEntries.%d", index); > writeVarbind(pdu, 1, oid, TYPE_INTEGER, "1000", 0); > > sprintf(oid, "hlMatrixControlAlMaxDesiredEntries.%d", index); > writeVarbind(pdu, 2, oid, TYPE_INTEGER, "1000", 0); > > sprintf(oid, "hlMatrixControlOwner.%d", index); > writeVarbind(pdu, 3, oid, TYPE_OCTET_STRING, "policy manager", 14); > > sprintf(oid, "hlMatrixControlStatus.%d", index); > writeVarbind(pdu, 4, oid, TYPE_INTEGER, "1", 0); writeVarbind(pdu, 1, "hlMatrixControlNlMaxDesiredEntries." + index, TYPE_INTEGER, "1000"); writeVarbind(pdu, 2, "hlMatrixControlAlMaxDesiredEntries." + index, TYPE_INTEGER, "1000"); writeVarbind(pdu, 3, "hlMatrixControlOwner." + index, TYPE_OCTET_STRING, "policy manager"); writeVarbind(pdu, 4, "hlMatrixControlStatus." + index,TYPE_INTEGER, "1"); > snmpsend(0, 5, OP_SET); /* The a snmpsend line could be unchanged, although I * would prefer the following: */ snmpset(pdu, 5); - - - - - - The above example does not fully show the benefits of the string type. An example using get would be more interesting from the string standpoint. Here is an off-the-cuff fragment: Using character arrays (no string type): ========================================= char oid[STRINGLEN], value[STRINGLEN]; int index, pdu, valueLen; pdu = 0; /* Use PDU #0 */ sprintf(oid, "hlMatrixControlDataSource.%d", index); writeVarbind(pdu, 0, oid, TYPE_OBJECT_IDENTIFIER, "", 0); snmpsend(pdu, 1, OP_GET); /* Error if retrieved oid or value don't fit in buffer */ readVarbind(pdu, 0, oid, TYPE_OBJECT_IDENTIFIER, value, &valueLen); ========================================================= Using a built-in string type: ============================= string value, oid; int index, pdu; pdu = 0; /* Use PDU #0 */ sprintf(oid, "hlMatrixControlDataSource.%d", index); writeVarbind(pdu, 0, "hlMatrixControlDataSource." + index, TYPE_OBJECT_IDENTIFIER, ""); snmpsend(pdu, 1, OP_GET); /* or snmpget(pdu, 1); */ /* oid and value will grow to required length */ value = readVarbind(pdu, 0, &oid); The above example is basic, but with enough code, the simplification provided by the string type becomes more compelling. Also, the reduced chance of error results in reduced need for error handling, which is always a big win. There are also several other simplifications possible once strings are part of the language. For example, the readVarbind function could be split and simplified, avoiding the need for declaring dummy variables to hold unused results: oid = readVarbindOid(pdu, 0); value = readVarbindValue(pdu, 0); Note that either of the above two calls could be eliminated if one or the other result is not needed. - Pablo --------------------------------------------------------------------- Pablo Halpern phalpern@newview.org http://www.halpernwightsoftware.com From owner-snmpconf@seymour39.SNMP.COM Wed Nov 15 14:29:53 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14333 for ; Wed, 15 Nov 2000 14:29:49 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA01655 for snmpconf-outgoing; Wed, 15 Nov 2000 14:08:20 -0500 (EST) Message-ID: <3A12DE6B.D0B52D70@covalent.net> Date: Wed, 15 Nov 2000 11:05:15 -0800 From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jon Saperia CC: Andrew Smith , "'Robert Moore/Raleigh/IBM '" , "''diffserv@ietf.org ' ' '" , "'snmpconf@snmp.com'" Subject: snmpconf Re: [Diffserv] Instance amplification in Diffserv MIB 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 HI, I hope this post works. Some confusion could be created by me, since I suddenly was not accepted as a legal post-account for the mailinglist anymore. Sorry about that. Jon Saperia wrote: > > on 11/14/2000 5:15 PM, Andrew Smith at andrew@allegronetworks.com wrote: > > > What you are arguing here is a need for some sort of "templating" capability > > for these objects: this is something that was discussed at length in the early > > snmpconf meetings (I wasn't at the last one so I don't know if this is still a > > goal) and was being called "instance amplification". The problem, in brief was > > "how do we apply a template of values for config parameters (columns) to a > > whole collection of instances (table entries)?" and there were hopes that > > snmpconf work would produce some sort of generic solution to this problem. > > What you are describing here is a local solution for this problem for this > > particular MIB, so I would ask you and Harrie to comment on whether we are > > duplicating effort here or just moving this solution from being a snmpconf > > work item to being a part of this diffserv MIB? Originally, SNMPCONF was more or less trying to duplicate the managed objects of the DiffServ-MIB. When trying to understand the DiffServ-MIB and speaking with Joel in Pittsburgh, he came up with the idea of having a more configurable DiffServ-MIB, which ment do not use in all tables the interface index and interface direction index. When I thought of what it really ment, I discovered that the DiffServ-MIB had a very inconsitent design. There were 2 ways on how to built datapath. The next pointers pointed each time to the next functional datapath element and "the interface index and interface direction index" connected datapath elements. I found out that next pointer could point to any other datapath element without considering the "the interface index and interface direction index". With other words "the interface index and interface direction index" were useless on all tables and would cause even more confusion then clarity. I discussed this that time with Kwok and others. They all agreed with me. That is why the DiffServ-MIb is changed. As a result of this, SNMPCONF can make much eaiser use of the DiffServ-MIB without duplication the managed objects and provide them as a configuration object. This is an example from which I say the "interface index and interface direction index" is redundant. As you can see below the 'diffServMeterSucceedNext' points to an entry associated with a different interface index. diffServMeterTable * ifIndex = 1 * diffServMeterIfDirection = egress * diffServMeterId = 1 diffServMeterSucceedNext = diffServActionEntry.diffServActionId.2.egress.1 diffServMeterFailNext = diffServActionEntry.diffServActionId.2.ingress.2 diffServMeterSpecific = 0.0 diffServMeterStatus = active diffServActionTable * ifIndex = 2 * diffServActionIfDirection = egress * diffServActionId = 1 diffServActionNext = 0.0 diffServActionSpecific = 0.0 diffServActionStatus = active diffServActionTable * ifIndex = 2 * diffServActionIfDirection = ingress * diffServActionId = 2 diffServActionNext = 0.0 diffServActionSpecific = 0.0 diffServActionStatus = active > > If the latter then that's just > > fine but we do need to check for consistency with the solutions being worked > > on in snmpconf (yes Brian, that would mean a two-way dependency between these > > work items). If the former then I think that the duplication of solutions > > would be a Bad Thing. > > Andrew, this is only in response to your general questions about the > SNMPCONF work. Harrie and others have commented on some of the other > questions. Instance amplification is a primary goal of the SNMPCONF work. > The MIB Module Harrie and David Partain are working on is to apply to the > selected elements (interfaces in this case) the template of values to these > selected elements. > > There was a desire to see if some of the 'template' tables could be included > in the standard DiffServ. This was a desire, but my example above make it more mandatory, due to not consistent usage of for instance interface index. As said before, due to the change in the DiffServ MIB it makes SNMPCONF usage very simple. We can use the same tables for datapath 'templates'. > That is what they have been working on with Kwok. > There should not be a duplication of solutions. That was also a goal. No duplication. Hope this helps. Harrie 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 From owner-snmpconf@seymour39.SNMP.COM Wed Nov 15 14:57:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26758 for ; Wed, 15 Nov 2000 14:57:26 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA02229 for snmpconf-outgoing; Wed, 15 Nov 2000 14:43:33 -0500 (EST) Date: Wed, 15 Nov 2000 11:13:17 -0800 From: Andrew Smith Subject: Re: snmpconf Re: Instance amplification in Diffserv MIB To: snmpconf@snmp.com Cc: Andrew Smith Message-id: <3A12E04D.3010803@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000929 Netscape6/6.0b3 X-Accept-Language: en References: <200011151425.JAA25540@seymour39.SNMP.COM> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Steve - it hasn't changed, I've just got an additional one now (which I was planning to use just for diffserv messages): I guess I need to subscribe to snmpconf with the new address as well as the old one in order to post anything - oh, the problems of being a consultant working for multiple clients ... Sorry to bother you. Andrew Steve Moulton wrote: > I am resubmitting the following on behalf of Andrew Smith, whose > email address has recently changed. From owner-snmpconf@seymour39.SNMP.COM Sun Nov 19 21:29:01 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14423 for ; Sun, 19 Nov 2000 21:29:00 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id VAA17348 for snmpconf-outgoing; Sun, 19 Nov 2000 21:06:26 -0500 (EST) From: "Andrea Westerinen" To: "Jon Saperia" , , "snmpconf" Subject: snmpconf RE: Comments on the draft-ietf-policy-terminology-00.txt document Date: Sun, 19 Nov 2000 18:09:01 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Jon, I realized that I never replied to this list of comments. As the polterm editors are about to rev the draft for the next meeting, it would be good to close on some of these issues. Replies are inline. Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Jon Saperia Sent: Monday, August 28, 2000 7:24 AM To: policy@raleigh.ibm.com; snmpconf Subject: Comments on the draft-ietf-policy-terminology-00.txt document Here are some comments on the recent draft. Sorry for the cross posting. I know that some on the SNMPCONF WG list are not on the policy list. On Page 3: > - "M" identifies various mechanisms to create or convey policy- > related information in a network. For example, COPS and an > "Information Model" are two mechanisms for communicating and > describing policy-related data. Perhaps we need another term. Mechanism has come to be used in the context of a technology used to realize a particular policy in a policy domain. An example would be RED or WRED in DiffServ of BGP Policy in the Routing Policy domain. This use of "mechanism" really seems more of a convention than a definition. However, for clarity, an alternative might be "(T) Technique". In addition, there are several places in the document (see also page 7) that would benefit from a clearer expansion of the terms that are currently in use in terms of levels of abstraction. At present 4 levels of abstraction have been defined and are now in common use in the SNMPCONF documents. They are: 1. Domain Specific. 2. Mechanism Specific 3. Implementation Specific 4. Instance Specific Although these abstractions may work within the context of SNMPConf, they do not translate to the extended scope of general policy - moving from SLAs down to specific device abstractions. In previous versions of the terminology and policy framework documents, the number of levels of abstraction was debated at length. The decision was that you could not say that there were only 3, 4 or 6 levels - since a particular implementation may require more or less. (SNMPConf does indeed assume a specific context and implementation.) Your terms certainly fit within the definition of "abstraction", and could be referenced as examples. Here is some new text: $ policy abstraction (P) Policy can be represented at different levels, ranging from business goals to device-specific configuration parameters. Translation between different levels of "abstraction" may require information, other than policy, such as network and host parameter configuration and capabilities. Various documents and implementations may specify explicit levels of abstraction [for example, DiffPolicy]. However, these do not necessarily correspond to distinct processing entities or the complete set of levels in all environments. (See also "configuration" and "policy translation.") <\arw> Rather than quote the entirety of these terms, here are the reference IDs: draft-ietf-snmpconf-diffpolicy-02.txt draft-ietf-snmpconf-bcp-02.txt Additional background information is found in: draft-saperia-policysnmp-00.txt I believe that community will be well served by a common set of terms as they relate to these levels of abstraction. On Page 4 > Common Open Policy System (COPS) I have no issue with the inclusion of this specific mechanism and components of its architecture such as PDPs and PEPs. To the extent that we choose to define such technologies in this document, we should also define the SNMP-based ones as well and it based documents - those references are pretty well known. With regard to SNMPCONF specific items this document should also include items such as: Policy MIB Module Mechanism and Implementation Specific MIB Modules Policy Management Application (see above references) What new terms are you defining? I agree that we should add another "(T)technique" that says that policy can be defined via MIBs and reference the SNMPConf work. Here is the new text... $ Policy Management Information Base (MIB) (T) Collections of policy-related managed objects, defined as a module and accessed via an SNMP framework. [PolicyMIB] This definition is consistent with the PIB one. Other than this new technique (T), I do not know of any other new terms that should be defined. As regards, a "policy management application" - this does not appear to be a "term" in any of the SNMPConf documents, but is discussed in draft-saperia-policysnmp-00.txt. In the latter, it is tied strictly to SNMP and RFC2571. This does not seem to be a general/generic term or even require definition since there does not seem to be any ambiguity related to it. IMHO, I believe that ultimately all "management applications" will deal with policy in one form or another, whether they are SNMP-based or not. Also on Page 4 > configuration I found this paragraph a bit confusing. The telco industry uses configuration to refer to parameters that 'are set at the factory' and are not generally changeable by the customer. Provisioning refers to those parameters that are customer changeable. I think there is a useful concept in the paragraph which points to user or provisioning system(s) setting of object values versus those that are dynamic or run time. The best example I can give is in the routing are where a set of BGP or OSPF configuration values are set by the user, but the routing information is continuously changing while the system is running. The position articulated by John Schnizlein seems very relevant here: > The Internet industry seems to use "configuration" to mean > changable parameters, as in the Dynamic Host Configuration Protocol > [RFC 2131]. The BOF announced with Policy Terminology was called > Configuration Management (excerpt below). The WG you co-chair is > called Configuration Management with SNMP (snmpconf). > > My impression is that there is a rough consensus that we would be > better served using this word as in the Internet context rather than > in the "telco industry" you cite. However, this is not meant to slight the telco industry. So, we can add an alternate definition and clarify that it is not the "Internet industry"s usage. We have done this in other parts of the document. On Page 5. > Directory Enabled Networks (DEN) My issue is not the inclusion or definition. I would like for us to have generic terms that are not dependent on the DMTF as well. For example what shall we call the general data model that is not LDAP specific? There can only be an "information model" that is not protocol/repository-specific - which we describe in PCIM. There cannot be a "data model" one. By definition, "data models" are repository/protocol specific. The reason that DEN is mentioned is that it was designed to use a directory as a policy repository. It is directly tied to policy. Since this is an IETF document, I think we should not only reference the work that the document is based on, but the technology over which we have change control and will use, perhaps in addition to other technologies. Agreed. However, there is also no reason to slight other relevant work since our customers hear these terms and could be confused. On pages 7, 9, 11 and 12: Terms such as policy condition, policy action, policy rule, role and role combination. I assume this document will be revised to reflect discussions that came out of the IETF meeting to resolve term conflicts that Andrea and Steve Waldbusser and others have had. I have not seen documentation of these discussions and look forward to those clarifications. We did resolve the definitions of Role and Role Combination. No other terminology issues were raised. Here are the new definitions for roles ... $ role An administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules, to determine the applicability of the rule to a particular managed element. [SNMPCONF, PCIM, PIB] $ role combination (P) An unordered set of roles that characterize managed elements and indicate the applicability of policy rules. A policy system uses the set of roles reported by the managed element to determine the correct policy rules to be sent for enforcement. That determination may examine all applicable policy rules identified by the role combination, its sub- combinations and the individual roles in the combination [PCIM], or may require that rules explicitly match the role combination specified for the managed element [PIB]. The final set of rules for enforcement are defined by the policy system, as appropriate for the specified role combination of the managed element. Page 9 > Policy Information Base (PIB) Same comment as before. No issue with definition, we just need to add the SNMP counterparts. Policy MIB is added as documented above. Page 10 > policy server I do have an issue with this definition. It states: > (P) A marketing term whose definition is imprecise. Originally, > [R2753] referenced a "policy server." As the RFC evolved, this > term became more precise and known as the Policy Decision Point > (PDP). Today, the term is used in marketing and other > literature to refer specifically to a PDP, or for any entity > that uses/services policy. In the SNMPCONF work we have been using policy application for some time since PDP and PEP have a very specific and sometimes different set of behaviors than SNMP. The goal of the definition was not to establish "policy server" as a real term, but to say that it is an "imprecise"/"marketing" term. The whole goal of "policy server" was to give the history of the term, which has caused confusion in the past. Since SNMPConf's documents do not reference this term, there is no ambiguity. Also, you are justified in not using the term, since it is "imprecise." BTW, I am very reluctant to add "policy application" as a formal term - since it is just a "policy" adjective in front of a general term. Even SNMPConf's I-Ds do not formally define it. Also on Page 10. > PolicyRepository I feel this should be a generic term since many people will store the information cited in systems and formats not common to PCIM or CIM. We actually have the generic and specific terms defined in the document. Here is the generic ... $ policy repository (P) "Policy repository" can be defined from three perspectives: - A specific data store that holds policy rules, their conditions and actions, and related policy data. A directory would be an example of such a store. - A logical container representing the administrative scope and naming of policy rules, their conditions and actions, and related policy data. A QoS policy domain would be an example of such a container. [QoSModel] - In [PCIM], a more restrictive definition than the prior one exists. PolicyRepository is a model abstraction representing an administratively defined, logical container for reusable policy conditions and policy actions. These comments aside. The document is a good start and will be quite helpful. Thanks. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Nov 20 15:34:38 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12596 for ; Mon, 20 Nov 2000 15:34:35 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA11383 for snmpconf-outgoing; Mon, 20 Nov 2000 15:15:39 -0500 (EST) Message-ID: <3A198634.9CA069D3@mediaone.net> Date: Mon, 20 Nov 2000 15:14:44 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andrea Westerinen CC: policy@raleigh.ibm.com, snmpconf , Jon Saperia Subject: snmpconf Re: Comments on the draft-ietf-policy-terminology-00.txt document References: Content-Type: multipart/mixed; boundary="------------6C9AAF11CDA2066283416305" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This is a multi-part message in MIME format. --------------6C9AAF11CDA2066283416305 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Westerinen wrote: --------------6C9AAF11CDA2066283416305 Content-Type: text/plain; charset=us-ascii; name="drafttoarw" Content-Disposition: inline; filename="drafttoarw" Content-Transfer-Encoding: 7bit > Jon, I realized that I never replied to this list of comments. As the > polterm editors are about to rev the draft for the next meeting, it would be > good to close on some of these issues. Thanks for the reply. In the interest of brevity. I have cut out some of the extraneous material. > On Page 3: > > > - "M" identifies various mechanisms to create or convey policy- > > related information in a network. For example, COPS and an > > "Information Model" are two mechanisms for communicating and > > describing policy-related data. > > Perhaps we need another term. Mechanism has come to be used in the context > of a technology used to realize a particular policy in a policy domain. An > example would be RED or WRED in DiffServ of BGP Policy in the Routing Policy > domain. > > > This use of "mechanism" really seems more of a convention than a definition. > However, for clarity, an alternative might be "(T) Technique". > I am happy with technique. It does sound like COPS or SNMP are both being used as transport and data definition tools. I understand in an absolute sense that the protocol(s) for transport and the languages for data definition, are not really the concern of policy. To the extent that they are used to transport and define that information, it might be helpful to identify terms that reference the functions of policy transport and data definition. > > In addition, there are several places in the document (see also page 7) that > would benefit from a clearer expansion of the terms that are currently in > use in terms of levels of abstraction. At present 4 levels of abstraction > have been defined and are now in common use in the SNMPCONF documents. They > are: > 1. Domain Specific. > 2. Mechanism Specific > 3. Implementation Specific > 4. Instance Specific > > > Although these abstractions may work within the context of SNMPConf, they do > not translate to the extended scope of general policy - moving from SLAs > down to specific device abstractions. In previous versions of the > terminology and policy framework documents, the number of levels of > abstraction was debated at length. The decision was that you could not say > that there were only 3, 4 or 6 levels - since a particular implementation > may require more or less. (SNMPConf does indeed assume a specific context > and implementation.) Your terms certainly fit within the definition of > "abstraction", and could be referenced as examples. Here is some new text: > $ policy abstraction > (P) Policy can be represented at different levels, ranging from > business goals to device-specific configuration parameters. > Translation between different levels of "abstraction" may require > information, other than policy, such as network and host > parameter configuration and capabilities. Various documents and > implementations may specify explicit levels of abstraction > [for example, DiffPolicy]. However, these do not necessarily > correspond to distinct processing entities or the complete set > of levels in all environments. (See also "configuration" and > "policy translation.") > <\arw> > This is a good start. You should reference the current documents on the web site. The terms are in the documents cited below. > Rather than quote the entirety of these terms, here are the reference IDs: > draft-ietf-snmpconf-diffpolicy-02.txt > draft-ietf-snmpconf-bcp-02.txt > Additional background information is found in: > draft-saperia-policysnmp-00.txt > > I believe that community will be well served by a common set of terms as > they relate to these levels of abstraction. > > On Page 4 > > > Common Open Policy System (COPS) > > I have no issue with the inclusion of this specific mechanism and components > of its architecture such as PDPs and PEPs. To the extent that we choose to > define such technologies in this document, we should also define the > SNMP-based ones as well and it based documents - those references are pretty > well known. With regard to SNMPCONF specific items this document should > also include items such as: > > Policy MIB Module > Mechanism and Implementation Specific MIB Modules > Policy Management Application > > (see above references) > > > What new terms are you defining? I agree that we should add another > "(T)technique" that says that policy can be defined via MIBs and reference > the SNMPConf work. Here is the new text... When you reference COPS as in the case above and PDPs and PEPs, they are protocol specific concepts. A policy management application and/or agent would be the comparable items in a Policy-enabled SNMP environment. > $ Policy Management Information Base (MIB) > (T) Collections of policy-related managed objects, defined as > a module and accessed via an SNMP framework. [PolicyMIB] > This definition is consistent with the PIB one. Other than this new > technique (T), I do not know of any other new terms that should be defined. > Not sure the SNMPCONF talks much about Policy Management Information Base unless you mean the Policy Module that controls the behavior of the managed system. We have Implementation, Mechanism, and Instance specific MIB Modules. All of which could contain 'policy' data. > As regards, a "policy management application" - this does not appear to be a > "term" in any of the SNMPConf documents, but is discussed in > draft-saperia-policysnmp-00.txt. In the latter, it is tied strictly to SNMP > and RFC2571. This does not seem to be a general/generic term or even > require definition since there does not seem to be any ambiguity related to > it. IMHO, I believe that ultimately all "management applications" will deal > with policy in one form or another, whether they are SNMP-based or not. > > If a policy Management Application is tied to SNMP, a PDP and PEP and COPs are all also specific technology terms and should not be referenced. Either we equally reference both or we should purge technology specifics. I do not feel strongly one way or the other. > Also on Page 4 > > > configuration > > I found this paragraph a bit confusing. The telco industry uses > configuration to refer to parameters that 'are set at the factory' and are > not generally changeable by the customer. Provisioning refers to those > parameters that are customer changeable. > > I think there is a useful concept in the paragraph which points to user or > provisioning system(s) setting of object values versus those that are > dynamic or run time. The best example I can give is in the routing are where > a set of BGP or OSPF configuration values are set by the user, but the > routing information is continuously changing while the system is running. > > > The position articulated by John Schnizlein seems very relevant here: > > The Internet industry seems to use "configuration" to mean > > changable parameters, as in the Dynamic Host Configuration Protocol > > [RFC 2131]. The BOF announced with Policy Terminology was called > > Configuration Management (excerpt below). The WG you co-chair is > > called Configuration Management with SNMP (snmpconf). > > > > My impression is that there is a rough consensus that we would be > > better served using this word as in the Internet context rather than > > in the "telco industry" you cite. > However, this is not meant to slight the telco industry. So, we can add an > alternate definition and clarify that it is not the "Internet industry"s > usage. We have done this in other parts of the document. > > Fine. > On Page 5. > > > Directory Enabled Networks (DEN) > > My issue is not the inclusion or definition. I would like for us to have > generic terms that are not dependent on the DMTF as well. For example what > shall we call the general data model that is not LDAP specific? > > > There can only be an "information model" that is not > protocol/repository-specific - which we describe in PCIM. There cannot be a > "data model" one. By definition, "data models" are repository/protocol > specific. The reason that DEN is mentioned is that it was designed to use a > directory as a policy repository. It is directly tied to policy. > > I would feel much more comfortable with the effort if we could include an example that used a database model as well. > Since this is an IETF document, I think we should not only reference the > work that the document is based on, but the technology over which we have > change control > and will use, perhaps in addition to other technologies. > > > Agreed. However, there is also no reason to slight other relevant work > since our customers hear these terms and could be confused. > > good then we can include some words about databases as well. > On pages 7, 9, 11 and 12: > > Terms such as policy condition, policy action, policy rule, role and role > combination. I assume this document will be revised to reflect discussions > that came out of the IETF meeting to resolve term conflicts that Andrea and > Steve Waldbusser and others have had. I have not seen documentation of these > discussions and look forward to those clarifications. > > > We did resolve the definitions of Role and Role Combination. No other > terminology issues were raised. Here are the new definitions for roles ... > $ role > An administratively specified characteristic of a managed > element (for example, an interface). It is a selector for > policy rules, to determine the applicability of the rule > to a particular managed element. [SNMPCONF, PCIM, PIB] > $ role combination > (P) An unordered set of roles that characterize managed > elements and indicate the applicability of policy rules. > A policy system uses the set of roles reported by the managed > element to determine the correct policy rules to be sent for > enforcement. That determination may examine all applicable > policy rules identified by the role combination, its sub- > combinations and the individual roles in the combination > [PCIM], or may require that rules explicitly match the role > combination specified for the managed element [PIB]. The > final set of rules for enforcement are defined by the > policy system, as appropriate for the specified role > combination of the managed element. > > > Page 9 > > > Policy Information Base (PIB) > > Same comment as before. No issue with definition, we just need to add the > SNMP counterparts. > > > Policy MIB is added as documented above. > Please see my comments above. > > Page 10 > > > policy server > > I do have an issue with this definition. It states: > > > (P) A marketing term whose definition is imprecise. Originally, > > [R2753] referenced a "policy server." As the RFC evolved, this > > term became more precise and known as the Policy Decision Point > > (PDP). Today, the term is used in marketing and other > > literature to refer specifically to a PDP, or for any entity > > that uses/services policy. > > In the SNMPCONF work we have been using policy application for some time > since PDP and PEP have a very specific and sometimes different set of > behaviors than SNMP. > > > The goal of the definition was not to establish "policy server" as a real > term, but to say that it is an "imprecise"/"marketing" term. The whole goal > of "policy server" was to give the history of the term, which has caused > confusion in the past. Since SNMPConf's documents do not reference this > term, there is no ambiguity. Also, you are justified in not using the term, > since it is "imprecise." BTW, I am very reluctant to add "policy > application" as a formal term - since it is just a "policy" adjective in > front of a general term. Even SNMPConf's I-Ds do not formally define it. > > > Also on Page 10. > > > PolicyRepository > > I feel this should be a generic term since many people will store the > information cited in systems and formats not common to PCIM or CIM. > > > We actually have the generic and specific terms defined in the document. > Here is the generic ... > $ policy repository > (P) "Policy repository" can be defined from three perspectives: > - A specific data store that holds policy rules, their > conditions and actions, and related policy data. A directory > would be an example of such a store. > - A logical container representing the administrative scope and > naming of policy rules, their conditions and actions, and > related policy data. A QoS policy domain would be an example > of such a container. [QoSModel] > - In [PCIM], a more restrictive definition than the prior one > exists. PolicyRepository is a model abstraction representing an > administratively defined, logical container for reusable policy > conditions and policy actions. > > I have not issue with these except to the extent that people think they are only realized in LDAP implementations. LDAP can be used to store policy data as well as relational and other technologies. Thanks /jon --------------6C9AAF11CDA2066283416305-- From owner-snmpconf@seymour39.SNMP.COM Mon Nov 20 17:09:46 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27950 for ; Mon, 20 Nov 2000 17:09:46 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA14340 for snmpconf-outgoing; Mon, 20 Nov 2000 16:54:08 -0500 (EST) Message-Id: <4.1.20001120163101.00b5d100@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 20 Nov 2000 16:50:33 -0500 To: Jon Saperia From: John Schnizlein Subject: Re: snmpconf Re: Comments on the draft-ietf-policy-terminology-00.txt document Cc: policy@raleigh.ibm.com, snmpconf In-Reply-To: <3A198634.9CA069D3@mediaone.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com It was in our attempt to include both terms from both the COPS and the SNMP-CONF efforts that we included Policy MIB along with PEP and PDP. Please send replacement (corrected) text for this definition. In general, the Policy Terms draft has been around long enough that the preferred form of comments is replacement (or edited) text rather than general questions. This preference also applies to the comments regarding other database technologies. We would gladly include any policy terms that reference databases other than directories or MIBs. It is worth noting that this terminology draft is not intended to imply any particular architecture for policy management. John At 03:14 PM 11/20/2000 -0500, Jon Saperia wrote: >Andrea Westerinen wrote: >>.. >When you reference COPS as in the case above and PDPs and PEPs, they are >protocol specific concepts. A policy management application and/or agent >would be the comparable items in a Policy-enabled SNMP environment. > >> $ Policy Management Information Base (MIB) >> (T) Collections of policy-related managed objects, defined as >> a module and accessed via an SNMP framework. [PolicyMIB] >> This definition is consistent with the PIB one. Other than this new >> technique (T), I do not know of any other new terms that should be defined. >> >Not sure the SNMPCONF talks much about Policy Management Information >Base unless you mean the Policy Module that controls the behavior of the >managed system. We have Implementation, Mechanism, and Instance specific >MIB Modules. All of which could contain 'policy' data. > >If a policy Management Application is tied to SNMP, a PDP and PEP and >COPs are all also specific technology terms and should not be >referenced. Either we equally reference both or we should purge >technology specifics. I do not feel strongly one way or the other. > >> >> > Directory Enabled Networks (DEN) >> >> My issue is not the inclusion or definition. I would like for us to have >> generic terms that are not dependent on the DMTF as well. For example >> what shall we call the general data model that is not LDAP specific? >> >> >> There can only be an "information model" that is not >> protocol/repository-specific - which we describe in PCIM. There >> cannot be a "data model" one. By definition, "data models" are >> repository/protocol specific. The reason that DEN is mentioned is >> that it was designed to use a directory as a policy repository. >> It is directly tied to policy. >> >> >I would feel much more comfortable with the effort if we could include >an example that used a database model as well. > >> Since this is an IETF document, I think we should not only reference >> the work that the document is based on, but the technology over >> which we have change control and will use, perhaps in addition >> to other technologies. >> >> >> Agreed. However, there is also no reason to slight other relevant >> work since our customers hear these terms and could be confused. >> >> >good then we can include some words about databases as well. ... >> >> > Policy Information Base (PIB) >> >> Same comment as before. No issue with definition, we just need to add the >> SNMP counterparts. >> >> >> Policy MIB is added as documented above. >> > >Please see my comments above. ... >> >I have not issue with these except to the extent that people think they >are only realized in LDAP implementations. LDAP can be used to store >policy data as well as relational and other technologies. From owner-snmpconf@seymour39.SNMP.COM Mon Nov 20 17:24:00 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29996 for ; Mon, 20 Nov 2000 17:24:00 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA14793 for snmpconf-outgoing; Mon, 20 Nov 2000 17:09:41 -0500 (EST) From: Keith McCloghrie Message-Id: <200011202209.OAA15935@cisco.com> Subject: Re: snmpconf Re: Comments on the draft-ietf-policy-terminology-00.txt document To: snmpconf@snmp.com Date: Mon, 20 Nov 2000 14:09:06 -0800 (PST) Cc: andreaw@cisco.com (Andrea Westerinen), policy@raleigh.ibm.com, saperia@jdscons.com (Jon Saperia) In-Reply-To: <3A198634.9CA069D3@mediaone.net> from "Jon Saperia" at Nov 20, 2000 03:14:44 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > When you reference COPS as in the case above and PDPs and PEPs, they are > protocol specific concepts. A policy management application and/or agent > would be the comparable items in a Policy-enabled SNMP environment. Jon, I think you have it round the wrong way. The PDP and PEP terminology was coined by the RAP WG for the purpose of describing "A Framework for Policy-based Admission Control" (RFC 2753), which is specified independently of the COPS-protocol. Keith. From owner-snmpconf@seymour39.SNMP.COM Tue Nov 21 05:15:55 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25185 for ; Tue, 21 Nov 2000 05:15:55 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id FAA29069 for snmpconf-outgoing; Tue, 21 Nov 2000 05:02:29 -0500 (EST) Message-ID: <3A1A4809.86B1085@mediaone.net> Date: Tue, 21 Nov 2000 05:01:45 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andrea Westerinen CC: policy@raleigh.ibm.com, snmpconf Subject: snmpconf Re: Comments on the draft-ietf-policy-terminology-00.txt document 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 Thanks for all the comments. I look forward to the next draft. /jon From owner-snmpconf@seymour39.SNMP.COM Tue Nov 21 05:19:17 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25541 for ; Tue, 21 Nov 2000 05:19:16 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id FAA29116 for snmpconf-outgoing; Tue, 21 Nov 2000 05:07:43 -0500 (EST) Message-Id: <200011211007.LAA25708@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Call for agenda items From: David Partain MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7141.974801228.1@y5m638.lmera.ericsson.se> Date: Tue, 21 Nov 2000 11:07:08 +0100 X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id FAA29111 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id FAA29116 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA25541 Greetings, Jon and I are in the process of putting together the agenda for the IETF in San Diego. If you have issues that you would like to see on the agenda, please let one of us know. With kind regards, -- David Partain David.Partain@ericsson.com Ericsson Radio Systems AB Tel: +46 13 28 41 44 Research and Innovation Mobile: +46 70 633 0515 P.O. Box 1248 Fax: +46 13 28 75 67 SE-581 12 Linköping, Sweden From owner-snmpconf@seymour39.SNMP.COM Wed Nov 22 02:29:17 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20458 for ; Wed, 22 Nov 2000 02:29:16 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id CAA27161 for snmpconf-outgoing; Wed, 22 Nov 2000 02:12:29 -0500 (EST) Message-ID: <15F58915DF84D311AC7D0090279AA6142340D5@itc-eml2.lannet.com> From: Dan Romascanu To: "'minutes@ietf.org'" Cc: "'snmpconf@snmp.com'" Subject: snmpconf Minutes of the SNMPCONF WG Interim Meeting - Pittsburgh, October 26-27, 2000 Date: Wed, 22 Nov 2000 07:38:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C05446.6BFF20E0" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C05446.6BFF20E0 Content-Type: text/plain Please find attached the minutes of the SNMPCONF Working Group Interim Meeting, hold in Pittsburgh on 10/26-27. Regards, Dan <> ------_=_NextPart_000_01C05446.6BFF20E0 Content-Type: text/plain; name="snmpconf_interim_minutes.txt" Content-Disposition: attachment; filename="snmpconf_interim_minutes.txt" Content-Transfer-Encoding: quoted-printable October 26-27 Interim Meeting SNMPCONF Working Group Minutes Submitted by Dan Romascanu and Steve Moulton=20 Participants Jon Saperia Joel M. Halpern Bai Jian=09 Mart Nurmet Alan Luchuk David Levi Steve Moulton Mike McFaden Dave Harrington Harrie Hazewinkel Kwok Ho Chan Dan Romascanu Bob Moore Walter Weiss Jeff Case Wayne Tackabury Dave Partain=20 Steve Waldbusser Dave Durham Chris Elliott Thursday, October 26 Thanks to the hosts. Schedule of discussions Agenda 1. Script MIB discussion (Partain/Waldbusser) * Show me the commercial implementation on boxes * Are the semantic differences important and valid * It's a general tool but we may want a specific tool * It is too much of a good thing Could RFC 2592 be good enough, could it be used? - Juergen's proposal 2. Language discussion (Waldbusser) Proposal - use the language that is specified in the document 3. Execution environment (Waldbusser) 4. Scheduling module discussion (Hongal/Saperia) Proposal - will be done with the scheduling MIB 5. Policy grouping, precedence and termination 6. Status of diffserv MIB * What's being done * What's to be done * Disappear or changed? 7. Implementation ? - what's being done? Interoperability 8. What to do about Jon Saperia's ID 9. Status of the IPSec Policy WG cooperation (Partain) * Need for examples - will be brought to help on the discussion 1. Script MIB Discussion David representing Juergen: it is good to reuse technologies. The proposal is to re-use Script MIB for storing and transporting policies. Jeff pointed out that we knew previously about the Script MIB, = discussed=20 it, and decided that it is not appropriate Steve: there are three objects overlapping the script MIB - filter=20 object, action object, description. In the Script MIB there is a lot of = stuff that is not relevant. Execution environment does not fit with the = environment assumed by the Policy MIB. The run table is inconsistent. David - Separation of filters and actions is an important issue - it is = more difficult to do with the Script MIB. Steve: How to use the Script MIB - replace octet object defining=20 actions and filters by references to the Script MIB. Concept of=20 association is weak and seems to have documentation purposes in the=20 Script MIB. Dave D. - Script MIB is good for all that is procedural. Can the Script = MIB be stripped down of the unnecessary objects, in order to see how it = may work Joel - looking at the compliance clauses - a lot of mandatory objects=20 in the Script MIB are in our 'non-necessary' list. Steve - using the script MIB would contradict the goals of simplicity = and=20 scalability. Doing the grouping would ease expressing paradigms like=20 'all Ethernet interfaces'. Joel - does the model of execution look very much like running a=20 script? Bob - In core policy you have a distinction between instance=20 identification and the policy congestion. Does the filter concept cover = both? Steve - Yes David P. - The script MIB was designed for mid-level managers. It is=20 the wrong tool for the purpose. Jeff - need for partitioning of filters and actions will become obvious = for everyone soon. Assuming this is true, the Script MIB is not=20 simpler, because the number of objects to refer the Script MIB would be = the same as the number of objects, and tougher to implement. Dave - trying to summarize - there is value in the model as created=20 by this WG, the generic Script MIB does not meet the requirements of = this=20 model At this point Jon tries to summarize - question to the WG - do we=20 believe, that the policy module as constructed is best served by not=20 using the Script MIB? Hum if inappropriate! Strong consensus. If=20 somebody has strong reasons to disagree, send reasons to the list. Minutes takers are instructed to reflect this discussion faithfully,=20 give the opportunity for discussions. A clear statement will be=20 introduced in the document about why we are not wanting to use the=20 Script MIB. Language and Library Discussion -- Language issues Steve - quickly discussing the changes in the language - quite a few in = the BNF Dave H. raised the issue if changes be made on anything else but local=20 variables? Text does not say - Steve - all is local variables. Dave H.=20 - ensure that only local variables can be modified in the filter side. Dave H. - refer to the ISO definition of C rather than the ANSI = definition Data type constants definition - is this useful? Use #const instead of #define? Or pre-defined constants? -> Steve conclusion - will use #const Dave H. - Can we distinguish between non-executing an action because=20 the filter result is zero, or because termination as result of an=20 error? Steve - add a gauge variable pmPolicyAbnormalTerminations for=20 abnormal termination counter. Dave H. - what the implementation would=20 do - what value is returned? - in the case of an abnormal termination=20 between of error? Add a numerical gap between data types and error codes Re-address delta function - delta("oid", minDeltaTime, ...) - other=20 benefits - it takes away time keeping functions from the script,=20 independence from scheduling skews, deltas times independent of=20 scheduling time - issue deferred to the list Are 64 bit integers going to be supported? Should all integers be 64=20 bit, or should we add long long? If we say all ints are 64 bits what=20 happens when we pass 2^32+1 to snmpset? - resolution - support 64 bits, = but do not use 64 bit for everything. Use long long when need to=20 express 64 bits. Proposal will be taken to mailing list. Details regarding casting ints (sign conversion, etc.) - make sure that = casting rules are clear for snmp functions Introduce note about Perl being a moving target therefore there is no=20 reference-able version of Perl - though the language should be familiar = both to C and Perl programmers Is wstrnlen() needed? Extend beyond $1-$9 (restriction on 2 character token is wrong) The RowStatus accessor function implies the usage of RowStatus in one=20 of the two ways accepted by SMIv2 for agents implementation - leave it=20 as is Decrease mandated minimum to 32 varbinds instead of 60 Define the concepts of 'element' and 'context' - might be necessary to=20 change names - resolution define "execution context", define "this=20 element" Should results of a varbind list be included in the same snmpset, as=20 defined today in the document? - resolution could be defined one way or = another, but it should be specified Consider in examples having descriptor-style OIDs not in quotes so they = aren't confused and considered legal to be sent over wire Be very explicit that examples are using descriptors Put other language stuff brought by Dave H., Joel, other, on a list of=20 items to be discussed after some examples are presented -- Library Discussion Library went through substantial changes Bob - Relationship between the accessor functions and the MIB access=20 rights is not clear - text should be written about inherited access=20 rights after Steve investigates the issue more. Allow OID assignments? int i; char descr[256]; i =3D ifNumber.0; strcpy(descr, 1.3.6.1.2.1.1.1.0); /*not C but would increase efficiency in local SNMP contexts */ /*open - would get to that later */ Discuss "inherited" access rights - Dave H. put a security name in the=20 policy table? DISMAN specialists need to be consulted - decision - this = is delayed for the agenda in the meeting in San Diego, discuss on the=20 mailing list and bring specific proposals before the San Diego.=20 Organize a meeting to bring in a smaller group of experts - Ross Mundy, = etc. Discuss whether expression author can use const construct inside the=20 scripts - Steve proposes that this is not necessary Jeff - why is it necessary? Dave H. - diffserv has some well known constants that we would have=20 globally named and used, this is the global const construct that would=20 be really useful . Is global naming naming? - looks like fixing the=20 problem is more painful than the gain. This is the consensus of the=20 meeting, may be raised again in the future Discuss whether varbinds may be indexed by strings. Suggestion was made = to make ifindex a string variable rather than a quoted string.=20 Rejected, because it would not work for ifIndex.1. Pursue typelessness - Whether to use only a typeless getvar and abandon = getint? Wayne's global whiteboard problem - can content be inspected by network = management? Scratchpad discussion was started - to be continued on Friday. Friday, October 27 Status of DiffServ MIB (Hazewinkel) Presentation of diffserv concept and model diagram MIB tables - datapath starting point table, traffic classifier tables,=20 meter functions tables, action tables, queueing element tables All=20 tables can be used for configuration, except the diffservDataPathTable=20 - needed a starting point table for specific data path configuration Dave - is a way to start policy needed? Proposal - one table which=20 specifies the indexing. That's all that will be left in this WG MIB=20 module. A good text explanation about how the different pieces fit will = be added (how it gets started, where roles come from, etc.) Kwok - We still need an ifIndex some place in the management system=20 that is mapped to the role or sets of roles that are relevant for the=20 policy There needs to be a difference between the button that activates the=20 mechanism in the policy MIB and the specific policy algorithms that=20 should be defined in the mechanism specific MIB. 'Invoke the algorithm=20 by reference and not by value.' Bob M. will prepare a proposal with two RowPointer TCs, one for targets = that must be copied when a template is applied to an interface, and the = other where there will be multiple pointers to a single target. Back to the Language Discussion Scratchpad discussion - example about RMON matrix - raised issue=20 whether scratchpad would be consistent between reboots Dave H. suggests that we create flags about scratchpad being consistent = between reboots and being shared Wayne - do we need a table reflecting what policies are in a state of=20 running or executing? -Steve - it is already reflected in the MIB Should we make scratchpad contents visible in MIB objects? Joel: This scratchpad represents the allocation of a row in a=20 table. What happens to the scratchpad if there is a power failure? If=20 the row allocation persists across the power loss then you want the scratchpad value to exist. If the policy goes away, you want the=20 scratchpad to go away (fate share). -- Next issue: variable bindings indexed by strings. If we are going to take the approach that OID and constant translations = are done by the manager; we ought to leave varbind translation in the=20 manager and leave it out of the language. There is no reason to have=20 varbind list naming in the agent; this should be in the manager. Sure=20 it makes it harder to debug; but lighter to implement, and is parallel=20 with leaving OID and constant naming in the manager. Current Varbind naming is by integer index (0..). Discussion about use of varbind lists as arrays of local storage. This=20 to solve the issue of how we declare/maintain local storage. There was a long discussion about whether an integer index on a varbind = will be sufficient for readability, or if we need a string index. The=20 room was tilting towards using a integer index, but strong consensus=20 within the room was not reached. -- Next issue: should varIndexs be integers or strings. Aside: varIndexs are used to index scratchpads. In short, should=20 objects in a scratchpad be named by integer or by character string. The = general feel of the room was that we do want to allow strings as=20 varIndices. -- Next issue: Implied getints. Do we want to allow the semantic i =3D ifindex.3 do an implied get and put the value in i? After some discussion the=20 consensus of the room was that we should not have an implied getint. -- Next issue: How do we handle Wayne's global whiteboard problem. Problem: We need to be able share data say between same policies on different elements. 4 instances: . policy*element (i.e, scratchpad data is scoped by policy and by element). We already have this. . all elements * 1 policy . all policies * 1 element (not useful) . global One proposed solution is to add an argument to get/setScratchpad to=20 specify policyElement/policy/global for scope of namespace. This led=20 to discussion of when to free a scratchpad entry. The proposals were . Keep track of who did the last setScratchpad on an item; and when that policy goes away the object goes away. . Explicit delete scratchpad entry function . If the thing that created something is destroyed, the things that are created are destroyed. Does the creator or the last writer determine fate? A request was made to restrict the number of scratchpad entries that can be created. This met with general agreement, with the proviso that there may be different limits for policy*element, policy, and global. Conclusion: Extend scratchpad functions with scope parameter, Mention explicitly about . Implementation specific limits on scratchpad variables per policy . implementation specific limits on global scratchpad may be lower . should we make scratchpad contents visible in MIB objects . should scratchpads persist across reboots This is the end of the discussion on accessor library. The discussion turned to array bounds and bounds checking. The fact of = an interpreter dumping core leads to a loss of the entire execution=20 engine leads to great conservatism with respect to array references. =20 The question is, have we been too conservative? The point was brought up that Perl has arrays bounds checking,=20 returning "undefined variable" on out-of-range array references. =20 Should we look at doing that? Steve Waldbusser became "a rabid=20 proponent of array indexing now that Chris mentioned dynamic array=20 index checking". The discussion moderator agreed that we should do this, and that the=20 issue should be taken to the mailing list for consensus. One participant was more comfortable with accessing substrings through=20 accessor functions. Another made the point that "[" (the array=20 reference index delimiter) is an accessor function. Jon Saperia lead the next presentation, in which the set of issues revolved around . What to do when a policy terminates. . What to do in the event of a policy override . What to do when a policy that had an override is to be restored. . What to do when a policy that was modified by a policy with a higher precedence is to be restored. [see policy-termination.ppt discussion slides] What to do when a policy that was modified by a policy with a higher precedence is to be restored. Possible actions before a policy is activated: . The objects did not exist, two forms: . no such object . no such instance . Object instances existed but with different values (BGP timer had 60, but the guy at the CLI set it to 30). . Objects existed as a side effect of some of the objects. Policy termination is the removal of a policy entry, it can also be what happens on schedule boundaries. That is handled by a special object. Policy Termination Choices . Delete current policy . Leave as is - take no action and leave values . Install another policy . Restore specific default . Restore specific values other than default (say what it was before I changed it). Jon proposes three pmPolicyTable objects for policy control: pmPolicyNonTemporalTerminate (delete(1), leaveInPlace(2),=20 installAlternate(3)) Semantics: 1: run and delete policy (oneshot). Anything touched remains in last state. 2: run and leave in place 3: run, replace with another policy pmPolicyRestore RowPointer Semantics: Null if pmPolicyNonTemporalTerminate is delete(1) or leaveInPlace(2), otherwise pointer to the pmPolicyEntry that will replace the entry after execution. pmPolicyDispose (delete(1), leaveInPlace(2), installAlternate(3)) Semantics: Same as pmPolicyNonTemporalTerminate except this specifies the behavior for interval (time-based) schedules. In the case of the use of alternate schedules, the schedule that is to be used is the one specified in pmPolicyRestore. The question was raised about what we do about looping policies. This does not present a clear solution. What problem are we solving? To clarify, Jon asked what happens to objects that are touched when a policy terminates. How do you reset: do we reinstall policy? Floor: I thought we did this with precedence. We fall back to policy=20 below it. Jon: Precedence is issue of overlapping policies; i.e. when schedules=20 overlap.=20 Floor: I Thought precedence is the tool to deal with this. We have=20 intentional policy conflict so that when a policy goes away then the=20 policy lower in precedence takes over. Use lowest level precedence to=20 set default conditions; if there is no lower, then object values stay=20 the same.=20 Jon: This implies policy groups, which we have not had until now. Floor: the highest remaining precedence policy is the "default case". If there is no remaining policy, no action is taken. Note that the solution I specified does not deal with what happens to a = policy when it deactivates. This should be a policy termination object = that says what cleanup needs to be done. For example: policyDispose: when a policy will no longer execute;=20 remove it or keep it in table. For example: When the 1-2 PM video=20 conference policy is done; it should go away. But the baseline bronze=20 policy should stick around. The question was raised about what do you do with all of the other=20 stuff floating around that a policy has created: what do you do with=20 dangling markers, objects, etc?=20 One proposed solution: when you clean up something pointed to by a=20 policy pointer, installation - dependent cleanup takes place. If we=20 have a metabutton to make a bunch of stuff, we should have a metabutton clean the stuff up. The write metabutton reads the stuff=20 before it sets it for cleanup. There is not a clean semantic for associating objects with policies so=20 we don't know what to clean up. We should have a one shot policy that=20 is invoked that a policy goes away. It should run in the same context=20 of the policy that it is running in and clean up the scratchpad &c. The point was raised that we may already have it. You are about to=20 create level 35; you create 34 at the same time to clean up.=20 The objection was raised that doing root cause analysis by analyzing=20 variable state becomes difficult with this.=20 Another objection is that only having if else choices may trip you up. At this point two new approaches have been proposed. The three=20 currently under discussion are 1 pmPolicyNonTemporalTerminate/pmPolicyRestore/pmPolicyDispose, 2 put policies in precedence groups, and install policy so that each=20 policy has a policy destructor installed in a higher precedence group 3 associate destructor policy with each policy (can be done w/ 1). Proposed Basic Rules: . Good policies will always have a default available . We will use groups to organize precedence. You only resolve precedence in a group. . The lowest policy number will be a default. The point was raised that we may need different words; there is=20 conflict with the concept of an active policy in the diffserv world. Another objection is that as things stand in the diffserv world, there=20 is no concept of global precedence.=20 A proposed scenario: imagine the possibility that when you evaluate the = left half you make instance selection; the right half is invoked later=20 to make sure the precedence evaluation is done correctly. For a given policy and a given instance you are always going to run the = highest precedence policy in a group that is active. Note that when you have a policy exit, you may on exit set some things=20 the the lower level policy immediately resets. One must be careful of=20 race conditions. This concludes the Policy Termination and Precedence discussion At this point, David Partain brought three other working group business issues: 1) What are various companies are thinking about implementing? =20 He is doing internal prodding in Ericsson, talking with Chris=20 Elliott at Cisco, and poking SNMP Research. We need to have proof=20 positive that this stuff actually works. Ideally he would like to see an interoperability event. Jeff Case commented that this is going to happen; but not before=20 San Diego. 2) He has been trying to work with Ricky Charlet in IPsec about ways=20 we can work together particularly with respect to the diffserv policy=20 MIB. Nothing is happening in IPSEC world right now; the IPSEC people=20 are currently concentrating efforts elsewhere, but the cooperation will pick up. 3) There is a personal internet draft published by Jon Saperia. There=20 have been some voices saying that the WG should adopt this. DLP is in=20 favor. Are there thoughts about using this as a background document=20 for what we are doing.=20 Three viewpoints were presented on draft-saperia-policysnmp: . If the purpose of this document is marketing then is useful now;=20 if it is a technical explanation it should be deferred.=20 . It aids in implementations. It has been useful in actual=20 implementations. In terms of what we are doing now it is not so=20 helpful. I think someone else should take over change control. It=20 does lay terms and contexts for doing policy based management with=20 SNMP, and provides a map for how the architecture is tied together=20 (managers & agents &c).=20 . One of things that was good about it was the pictures. Do you=20 anticipate that we can get some of this into the Simple Times - will=20 you have time to do this? I think this group is getting badly outmarketed.=20 The question: is a document that describes the mapping of SNMP=20 technology to policy in general and a document that describes where the = various pieces in a snmp system are at an introductory level something=20 the WG wants? It is in a non-graphic form (ID) today. From the floor: it is a good document but need some work in two areas 1 it needs some work in terminology alignment with other working=20 groups. 2 things keep shifting and the document needs to be updated to reflect = that.=20 This is not huge, but it is just work. We have good consensus from this group that this document should be=20 taken on by the working group. We need to get consensus from the working group at large via the mailing list. Wrapping-up! ------_=_NextPart_000_01C05446.6BFF20E0-- From owner-snmpconf@seymour39.SNMP.COM Wed Nov 22 09:45:05 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01110 for ; Wed, 22 Nov 2000 09:45:05 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA29617 for snmpconf-outgoing; Wed, 22 Nov 2000 09:28:11 -0500 (EST) Message-Id: <200011221427.JAA12164@aix43.snmp.com> to: minutes@ietf.org, snmpconf@snmp.com Subject: snmpconf Minutes and Slides of the SNMPCONF Working Group Interim Meeting, hold in Knoxville, on 10/26-27 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 22 Nov 2000 09:27:37 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit The slides for the interim meeting of the SNMP Working Group held in Knoxville, Tennessee, USA on October 26 and 27 are available via anonymous FTP at ftp://ftp.snmp.com/pub/snmpconf/interim-oct-2000. The minutes are also available at that location. Please note that the minutes submitted for this meeting indicated that the meeting took place in Pittsburgh. While there was an interim meeting in Pittsburgh just subsequent to IETF48, the minutes and slides are for the meeting held in Knoxville. If you have difficulties with anonymous FTP or for some other reason need to have the slides emailed to you, please contact me at moulton@snmp.com. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpconf@seymour39.SNMP.COM Thu Nov 23 09:16:53 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01834 for ; Thu, 23 Nov 2000 09:16:52 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA16544 for snmpconf-outgoing; Thu, 23 Nov 2000 09:04:13 -0500 (EST) Message-ID: <3A1D23AE.E3767967@mediaone.net> Date: Thu, 23 Nov 2000 09:03:26 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: agenda@ietf.org, SNMP Configuration WG , David Partain , Jon Saperia , Bert Wijnen , Randy Bush Subject: Agenda - Configuration Management with SNMP (snmpconf) 49th IETF Content-Type: multipart/mixed; boundary="------------881C0C427A1AF4F71E3E3EA9" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This is a multi-part message in MIME format. --------------881C0C427A1AF4F71E3E3EA9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------881C0C427A1AF4F71E3E3EA9 Content-Type: text/plain; charset=us-ascii; name="snmpconfagenda" Content-Disposition: inline; filename="snmpconfagenda" Content-Transfer-Encoding: 7bit Configuration Management with SNMP (snmpconf) CHAIRs: Daivd Partain David.Partain@ericsson.com Jon Saperia saperia@jdscons.com THURSDAY, December 14 at 1300-1500 FRIDAY, December 15 at 0900-1130 To ensure a successful meeting, please check the internet-drafts directory for updates to all of the WG documents. New versions will be posted before the meeting as follows: The DiffServ Policy MIB draft-ietf-snmpconf-diffpolicy-03.txt Policy Based Management MIB draft-ietf-snmpconf-pm-04.txt Configuring Networks and Devices with SNMP draft-ietf-snmpconf-bcp-03.txt AGENDA: Below is the proposed agenda to cover the two working group sessions that the SNMPCONF WG is having and the next IETF in San Diego: Administration: - Sign-up - Status and Schedule - Note takers Language Issues: - Proposal to have a string data type. - Within an execution environment do we need something like argv and argc? - Other proposed functions/changes. Security Issues: - Dealing with SNMP actions in scripts - security parameter passing to the SNMP calls. - Mid-level manager security issues - inherited access writes - how do you decide which security parameters to use. Policy Grouping for precedence: - Define rules - e.g., ensure that when a policy is no longer valid, rather than waiting for max latency, when C uncovers B, B executes immediately - Finalize objects Do we need an accessor for CLI functions? Notification Types for capabilities updates - desire to see new capabilities only of types of interest. - Scope - By registering ones you want to see, or - registering ones you do not want to see Protection from scripts running for ever - the looping question Schedule work finalization Discussion of the version .06 DiffServ MIB Module and how it and the DiffServ Policy and Policy Modules work together. BCP Discussion - changes since last draft - remaining Issues. Closure On issues from the interim meeting. Other issues and Closing. If you have any potential agenda items you would like considered, please email either David or Jon: David.Partain@ericsson.com saperia@jdscons.com Thanks, David Partain and Jon Saperia --------------881C0C427A1AF4F71E3E3EA9-- From owner-snmpconf@seymour39.SNMP.COM Thu Nov 23 10:09:22 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14738 for ; Thu, 23 Nov 2000 10:09:22 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA17585 for snmpconf-outgoing; Thu, 23 Nov 2000 09:56:50 -0500 (EST) Date: Thu, 23 Nov 2000 15:56:13 +0100 Message-Id: <200011231456.PAA28309@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com In-reply-to: <15F58915DF84D311AC7D0090279AA6142340D5@itc-eml2.lannet.com> (message from Dan Romascanu on Wed, 22 Nov 2000 07:38:20 +0200) Subject: snmpconf interim meeting script mib discussion 26-27, 2000 References: <15F58915DF84D311AC7D0090279AA6142340D5@itc-eml2.lannet.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Dan Romascanu writes: Dan> 1. Script MIB Discussion [...] I have read through the minutes and it looks like the discussion somehow missed the point. As I said before: I believe the granularity of the model you are using is flawed. Modeling individual filters and actions as individual MIB objects (that have to fit into SNMP message size constraints) will not scale. My experience is that control programs tend to become complex and lengthy over time. The benefits of being able to share some action code between filters will soon be eaten up by the amount of additional data required to implement the fine granular MIB objects. Furthermore, once you have to deal with hundreds or even thousends of filters and actions, you will experience typical SNMP efficiency problems when installing/removing large sets of policies. In addition, you impose a non-trivial burden on the manager (and the agent) to do lots of row creation/deletion operations and the appropriate handling of error cases. In contrast, bundling associated filters and actions into a single script which is transferred to the policy execution engine avoids all these problems. And in this case, the script MIB becomes the natural way to transfer, activate and control the execution of policy scripts. Dan> Dave - trying to summarize - there is value in the model as Dan> created by this WG, the generic Script MIB does not meet the Dan> requirements of this model I can agree that the Script MIB does not fit the requirements imposed by the current model. But I also believe that the model itself is flawed (see above) since it won't scale and it will be difficult to implement and use. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Thu Nov 23 11:04:22 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03380 for ; Thu, 23 Nov 2000 11:04:22 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id KAA18711 for snmpconf-outgoing; Thu, 23 Nov 2000 10:52:43 -0500 (EST) Message-Id: <200011231552.QAA09461@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf New version of the DiffServ Policy MIB From: David Partain MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <24653.974994726.1@y5m638.lmera.ericsson.se> Date: Thu, 23 Nov 2000 16:52:06 +0100 X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id KAA18704 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id KAA18711 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA03380 Hello all, I have just submitted a new version of the DiffServ Policy MIB to the I-D folks. Until it pops up in the repositories, you'll find it at http://www.cs.utk.edu/~partain/draft-ietf-snmpconf-diffpolicy-03.txt This version is MUCH smaller than previous versions of this MIB. The reason is that one can now, directly in the DiffServ MIB, create "templates" that aren't bound to a particular interface/interface direction. As such, it is no longer necessary for "our" MIB to have all of the tables for creating these templates. Because the changes are so significant, it's not reasonable to have a version with change bars, I'm afraid. See you all in San Diego. Cheers, -- David Partain David.Partain@ericsson.com Ericsson Radio Systems AB Tel: +46 13 28 41 44 Research and Innovation Mobile: +46 70 633 0515 P.O. Box 1248 Fax: +46 13 28 75 67 SE-581 12 Linköping, Sweden From owner-snmpconf@seymour39.SNMP.COM Thu Nov 23 16:07:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25769 for ; Thu, 23 Nov 2000 16:07:56 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA24537 for snmpconf-outgoing; Thu, 23 Nov 2000 15:56:12 -0500 (EST) Message-Id: <4.3.2.7.1.20001123123117.05cb83a8@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Nov 2000 13:01:10 -0800 To: snmpconf@snmp.com From: Michael MacFaden Subject: snmpconf New version of the Best Current Practices document In-Reply-To: <200011231552.QAA09461@lmera.lmera.ericsson.se> 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 Hello all, I have also just submitted a new version of the working group internet draft "Best Current Practices for Configuration with SNMP." Until it surfaces in the ietf repositories, you can find it here: http://www.macfaden.com/ietf/draft-ietf-snmpconf-bcp-03.txt We have added a new editor, Wayne Tackabury. There has been substantial work on overall organization and prose. Regards, Mike MacFaden Riverstone Networks, Inc www.riverstonenet.com From owner-snmpconf@seymour39.SNMP.COM Mon Nov 27 09:58:06 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04620 for ; Mon, 27 Nov 2000 09:58:06 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA01685 for snmpconf-outgoing; Mon, 27 Nov 2000 09:40:08 -0500 (EST) Message-ID: <15F58915DF84D311AC7D0090279AA61423412E@itc-eml2.lannet.com> From: Dan Romascanu To: "'snmpconf@snmp.com'" , "'minutes@ietf.org'" Subject: RE: snmpconf Minutes of the SNMPCONF WG Interim Meeting - Pittsbu rgh, October 26-27, 2000 Date: Mon, 27 Nov 2000 16:39:17 +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 The SNMPCONF Interim Meeting was hold in Knoxville, Knoxville, Knoxville, Knoxville...(x100 times for penitence). My apologies to the SNMPCONF list and to our excellent hosts for the confusion. Dan > -----Original Message----- > From: Dan Romascanu [SMTP:dromasca@avaya.com] > Sent: Wed November 22 2000 7:38 > To: 'minutes@ietf.org' > Cc: 'snmpconf@snmp.com' > Subject: snmpconf Minutes of the SNMPCONF WG Interim Meeting - > Pittsburgh, October 26-27, 2000 > > Please find attached the minutes of the SNMPCONF Working Group Interim > Meeting, hold in Pittsburgh on 10/26-27. Regards, Dan > > <> << File: snmpconf_interim_minutes.txt > >> From owner-snmpconf@seymour39.SNMP.COM Mon Nov 27 23:35:22 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04692 for ; Mon, 27 Nov 2000 23:35:19 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id XAA07898 for snmpconf-outgoing; Mon, 27 Nov 2000 23:19:34 -0500 (EST) Message-ID: <3A2331DE.6AEC2A02@nextbeacon.com> Date: Mon, 27 Nov 2000 20:17:34 -0800 From: Steve Waldbusser X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: snmpconf New version of the Policy-Based Management MIB Content-Type: multipart/mixed; boundary="------------E83CA73EF5A8BC0AC99BE3EA" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This is a multi-part message in MIME format. --------------E83CA73EF5A8BC0AC99BE3EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's the latest version I submitted as an Internet Draft. They indicated it may take as long as December 4th before we see the ID. Steve --------------E83CA73EF5A8BC0AC99BE3EA Content-Type: text/plain; charset=us-ascii; name="pm.txt" Content-Disposition: inline; filename="pm.txt" Content-Transfer-Encoding: 7bit Internet Draft Policy-Based Management MIB Nov 22, 2000 Policy Based Management MIB draft-ietf-snmpconf-pm-04.txt November 22, 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 May 22, 2001 [Page 1] Internet Draft Policy-Based Management MIB Nov 22, 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 May 22, 2001 [Page 2] Internet Draft Policy-Based Management MIB Nov 22, 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 May 22, 2001 [Page 3] Internet Draft Policy-Based Management MIB Nov 22, 2000 3. Overview Large IT organizations have developed management strategies to cope with the extraordinarily large scale and complexity inherent in today's networks. In particular, they try to configure 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 May 22, 2001 [Page 4] Internet Draft Policy-Based Management MIB Nov 22, 2000 4. Policy-Based 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 program code 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 an object or a set of objects. These policies are executed on or near 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) Various Authors Expires May 22, 2001 [Page 5] Internet Draft Policy-Based Management MIB Nov 22, 2000 If (gold service paid for on circuit) then (apply special queueing) 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 administratively specified characteristic of a managed element (for example, an interface). It is a selector for policies, to determine the applicability of the policy to a particular managed element. Some examples of roles are political, financial, legal, geographical, or architectural characteristics, 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. Some types of information one would put into a role include: 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 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 Various Authors Expires May 22, 2001 [Page 6] Internet Draft Policy-Based Management MIB Nov 22, 2000 element. For example: backup, trunk. If (interface is backup) then (set ifAdminStatus = down) Roles are human defined strings that can be referenced by policy code. Roles may be assigned to elements by the role group in this MIB as well as through implementation-dependent means. Multiple roles may be assigned to each element. Because policy code can make policy decisions based on the value of any MIB object, role strings will typically contain information not accessible in MIB objects. The roleMatch accessor function allows policy code to make decisions based on whether or not an element has a particular role assigned to it. The role group allows a management station to learn what roles exist on a managed system. The management station may choose not to download policies that depend on a role that does not exist on any elements in the system. The management station can then register for notifications of new roles. Upon receipt of a pmNewRoleNotification, it may choose to download new policies that make use of that new role. Capabilities Some actions are inappropriate for certain elements or are simply unsupported because a capability doesn't exist or because it is restricted. Policy filters 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. The capMatch accessor function allows policy code to make decisions based on whether or not an element has certain capabilities. The capabilities group allows a management station to learn what capabilities exist on a managed system. The management station may choose not to download policies that depend on a capability that does not exist on any elements in the system. The management station can then register for notifications of new capabilities. Upon receipt of a pmNewCapabilityNotification, it may choose to download new policies that make use of that new capability. Time Various Authors Expires May 22, 2001 [Page 7] Internet Draft Policy-Based Management MIB Nov 22, 2000 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 Execution Environment There are several steps performed in order to execute policies in this environment: - Element Discovery - Element Filtering - Policy Enforcement 5.1. Element Discovery An element is a uniquely addressable entity on a managed device. Examples of elements include interfaces, circuits, queues, CPUs, and processes. Sometimes various attributes of an entity will be described through tables in several standard and proprietary MIBs - as long as the indexing is consistent between these tables, the entity can be modeled as 1 element. For example, the ifTable and the dot3Stats table both contain attributes of interfaces and share the same index (ifIndex), therefore they can be modeled as one element type. The Element Type Registration table is used for the manager to learn what element types are being managed by the system and to register new types if necessary. An element type is registered by providing the OID of an SNMP object (i.e., without the instance). Each SNMP instance that exists under that object is a distinct element. The address of the element is the index part of the discovered OID. This address will be supplied to policy filters and actions so that this code can inspect and configure the element. For each element that is discovered, the policy filter is called with the element address as an argument to see if the element is a member of the set that the policy acts upon. If the agent is discovering elements by polling, it should Various Authors Expires May 22, 2001 [Page 8] Internet Draft Policy-Based Management MIB Nov 22, 2000 check for new elements no less frequently than pmElementTypeRegMaxLatency would dictate. When an element is first discovered all policyFilters are run immediately and policyFilters that match will have the associated policyAction run immediately. Subsequently, the policyFilter will be run regularly for the element with no more than pmPolicyFilterMaxLatency milliseconds elapsing between each invocation. 5.1.1. Implementation Notes Note that while the external behavior of this registration process is defined in terms of the walking of MIB tables, implementation strategies may differ. For example, commonly- used element types (like interface) may have purpose-built element discovery capability built-in and advertised to managers through an entry in the pmElementTypeRegTable. Before registering an element type, it is the responsibility of a manager to inspect the table and see if it is already registered (by the agent or another manager). Note that entries that differ only in the last OID (which specifies which object in an entry) are effectively duplicates and should be treated as such by the manager. The system which implements the Policy-Based Management MIB may not have knowledge of the format of object identifiers in other MIBs. Therefore it is inappropriate for it to check these OIDs for errors. It is the responsibility of the management station to register well-formed object-identifiers. For example, if an extra sub-identifier is supplied when registering the ifTable, no elements will be discovered. Similarly, if a sub-identifier is missing, every element will be discovered numerous times (once per column) and none of the element addresses will be well-formed. 5.2. Element Filtering The first step in executing a policy is to see which elements match the policy filter. To evaluate a policy, the policy filter is called once for each element and runs to completion. The element address is the only state that is passed to the Various Authors Expires May 22, 2001 [Page 9] Internet Draft Policy-Based Management MIB Nov 22, 2000 filter code for each invocation (in particular, except for state accessible from accessor functions, no state is remembered from the previous invocation of this element nor from the previous invocation of the policy filter). If any syntax or processing error occurs, the filter will terminate immediately for this element. If the filter returns non-zero, the corresponding policy action will be executed for this element. If an element matches a filter and it had not matched that filter the last time it was checked (or it was a newly- discovered element), the associated policyAction will be executed immediately. If the element had matched the filter at the last check, it will remain in the set of elements that will whose policyAction will be run within the policyFilterActionMaxLatency. 5.2.1. Implementation Notes It is an implementation-dependent matter as to how policy filters are scheduled. Each filter/element combination is conceptually its own process and can be scheduled sequentially or one or more could be run simultaneously. Policy filters have no side-effects. Policy filter interpreters are encouraged to stop processing a filter as soon as it's return value is known. 5.3. Policy Enforcement For each element that has returned non-zero from the policy filter, the corresponding policy action is called. The element address is the only state that is passed to the policy action for each invocation (in particular, except for state accessible from accessor functions, no state is remembered from the policy filter evaluation, nor from the previous filter/action invocation of this element nor from the previous invocation of the policy filter or action). If any syntax or processing error occurs, the action will terminate immediately for this element. Various Authors Expires May 22, 2001 [Page 10] Internet Draft Policy-Based Management MIB Nov 22, 2000 5.3.1. Implementation Notes It is an implementation-dependent matter as to how policy actions are scheduled. Each filter/element combination is conceptually its own process and can be scheduled sequentially or one or more could be run simultaneously. Various Authors Expires May 22, 2001 [Page 11] Internet Draft Policy-Based Management MIB Nov 22, 2000 6. Policy Language Policy filters and policy actions are expressed with the policy language. The policy language is intended to be familiar to programmers in a variety of languages, including Perl and C. There is no referenceable standard for the Perl language, so the policy language is defined as a subset of the C language. A subset was used to provide for easy development of low-cost interpreters of the policy language and to take away language constructs that are peculiar to the C language. For example, it is expected that both C and Perl programmers will understand the constructs allowed in the policy language. Some examples of the features that have been removed from the C language are: function definitions, pointer variables, structures, enums, typedefs, floating point and pre-processor functions. This language is formally defined as a subset of ISO C [19], 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 ISO C that is required for conformance to this standard. Unless explicitly described herein, the meaning of any construct expressed in the BNF can be found by reference to the ANSI/ISO C standard. The use of comments and newlines are allowed and encouraged where they will promote readability of policy code. Policy code in this language must be expressed in the UTF8 character set. 6.1. Formal Definition The policy language follows the syntax and semantics of ISO C [19], but policy code is limited to that which that can be expressed in the following EBNF form: letter : Any lower or upper case letter or underscore Various Authors Expires May 22, 2001 [Page 12] Internet Draft Policy-Based Management MIB Nov 22, 2000 char : Any 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-constant : decimal | ( '0' 'x' hexdigit+ ) char-constant : ( ''' char ''' ) | ( ''' '' decimal ''' ) identifier : letter ( letter | digit )* string-literal : '"' char* '"' -- Expressions primary-expression: identifier | integer-constant | char-constant | string-literal | '(' expression ')' postfix-expression: primary-expression | postfix-expression '(' argument-expression-list? ')' | postfix-expression '++' | postfix-expression '--' | postfix-expression '[' expression ']' argument-expression-list: assignment-expression | argument-expression-list ',' assignment-expression unary-expression: postfix-expression | unary-operator unary-expression unary_operator: '+', '-', ', '!', '++', '--', '&' Various Authors Expires May 22, 2001 [Page 13] Internet Draft Policy-Based Management MIB Nov 22, 2000 multiplicative-expression: unary-expression | multiplicative-expression '*' unary-expression | multiplicative-expression '/' unary-expression | multiplicative-expression '%' unary-expression additive-expression: multiplicative-expression | additive-expression '+' multiplicative-expression | additive-expression '-' multiplicative-expression shift-expression: additive-expression | shift-expression '<<' additive-expression | shift-expression '>>' additive-expression relational-expression: shift-expression | relational-expression '<' shift-expression | relational-expression '>' shift-expression | relational-expression '<=' shift-expression | relational-expression '>=' shift-expression equality-expression: relational-expression | equality-expression '==' relational-expression | equality-expression '!=' relational-expression AND-expression: equality-expression | AND-expression '&' equality-expression exclusive-OR-expression: AND-expression | exclusive-OR-expression '^' AND-expression inclusive-OR-expression: exclusive-OR-expression | inclusive-OR-expression '|' exclusive-OR-expression logical-AND-expression: inclusive-OR-expression | logical-AND-expression '&&' inclusive-OR-expression logical-OR-expression: Various Authors Expires May 22, 2001 [Page 14] Internet Draft Policy-Based Management MIB Nov 22, 2000 logical-AND-expression | logical-OR-expression '||' logical-AND-expression assignment-expression: logical-OR-expression | unary-expression assignment-operator assignment-expression assignment-operator: '=' | '*=' | '/=' | '%=' | '+=' | '-=' | '<<=' | '>>=' | '&=' | '^=' | '|=' expression: assignment-expression | expression ',' assignment-expression constant-expression: logical-OR-expression ------------------------------------------------------ -- Declarations declaration: type-specifier declarator-list ';' declarator-list: init-declarator | declarator-list ',' init-declarator init-declarator: identifier | identifier '=' assignment-expression type-specifier: 'char' | 'int' | 'long' | 'long' 'long' | 'unsigned' | 'unsigned' 'int' | 'unsigned' 'long' | 'unsigned' 'long' 'long' | 'string' ------------------------------------------------------ -- Statements statement: if-statement | non-if-statement Various Authors Expires May 22, 2001 [Page 15] Internet Draft Policy-Based Management MIB Nov 22, 2000 -- if-else-statement is considered a non-if statement for -- purpose of resolving dangling if clauses. non-if-statement: labeled-statement | compound-statement | expression-statement | if-else-statement | iteration-statement | jump-statement compound-statement: '{' statement-list? '}' statement-list: statement | statement-list statement expression-statement: expression? ';' if-statement: 'if' '(' expression ')' statement if-else-statement: 'if' '(' expression ')' non-if-statement 'else' statement iteration-statement: 'while' '(' expression ')' statement | 'for' '(' expression? ';' expression? ';' expression? ')' statement jump-statement: 'continue' ';' | 'break' ';' | 'return' expression? ';' --------------------------------------------- -- Root production. policy-code: declaration* statement-list? Various Authors Expires May 22, 2001 [Page 16] Internet Draft Policy-Based Management MIB Nov 22, 2000 7. Sizes of variables While ISO C [19] allows implementation flexibility in choosing the size of the integer types, implementations of the policy language must use the following sizes: type bits range ---- ---- ----- int 32 -2147483648 to 2147483647 long 32 -2147483648 to 2147483647 long long 64 -9223372036854775808 to 9223372036854775807 unsigned 32 0 to 4294967296 unsigned int 32 0 to 4294967296 unsigned long 32 0 to 4294967296 unsigned long long 64 0 to 18446744073709551616 8. String type The string type is available for use in policy code as if declared as a typedef prior to a policy's execution (however, note that typedef is not provided in the C subset valid for policy code itself). A string represents a sequence of characters. The string type is not a null-terminated string and does not need to be pre- allocated. Operations on a string that change its length will automatically allocate or free memory as necessary. Strings can contain binary data (including null bytes) as well as printable data. The length of a string cannot be determined by inspection of the contents of the string (i.e. no null termination), but can be determined by calling strlen(). When a string variable is a parameter to a function, it can be modified by that function. 8.1. Infix string operators The following operators are supported for strings. In the following list, a and b are variables or expressions of type string and i is an expression of type int. Assign: a = b; Various Authors Expires May 22, 2001 [Page 17] Internet Draft Policy-Based Management MIB Nov 22, 2000 Copies the value of b to a. After the copy a and b are equal but do not share storage. Concatenate: a + b Append: a += b Index (with range checking): a[i] Test for equality: a == b Test for not equal: a != b Compare: a < b, a > b, a <= b, or a >= b 9. Address of `this element' Policy code needs a convenient way to get the components of the index for "this element" so that they can perform SNMP operations on it or on related elements. Two mechanisms are provided. 1. For all oid input parameters to all SNMP Access Functions (but not oid utility functions), the token "$n" ('$' followed by an integer between 0 and 99) can be used in place of any decimal sub-identifier. This token is expanded by the agent at execution time to contain the n'th subid of the index for the current element. For example, if the element is interface #7, and the objectIdentifier is "1.3.6.1.2.1.2.2.1.3.$1", it will be expanded to "1.3.6.1.2.1.2.2.1.3.7". If the token specified is beyond the length of the index for the current element, processing of the containing filter or action will be immediately terminated. 2. An array of strings will be available to the policy code. The n'th element of the array contains the ascii decimal string value of the n'th subidentifier in the index for "this element". The array is called iv. The number of subids in the array is called ic. For example, if "this element" is frCircuitDLCI.5.57 (ifIndex = 5, DLCI = 57) then ic == 2 iv[0] == 5 iv[1] == 57 Various Authors Expires May 22, 2001 [Page 18] Internet Draft Policy-Based Management MIB Nov 22, 2000 10. Accessor Functions Accessor functions are built-in functions available primarily to provide access to information on the local system or to more efficiently manipulate this information. A group of functions is organized into a library, the unit of conformance for function implementation. In order to claim conformance to a library, an implementation must implement all functions in a library to the specifications of the library. In order for a management station or policy code to understand if a certain library of functions is implemented, each library will have a registration OID that it registers in this MIB's capabilities table. Thus, conformance to a library can be tested with the capMatch library function (in the base library) or by inspecting the pmCapabilitiesType objects in the pmCapabilitiesTable. 11. Base Accessor Function Library A standard base library of accessor functions is available to all systems that implement this specification. This library is known by the capability OID of: pmBaseFunctionLibrary ::= { policyMgt pmConformance pmGroups 2 } This library contains four types of functions: - SNMP Access functions - Policy Configuration Access functions - Utility functions - Library Functions 11.1. SNMP Access Functions Two sets of SNMP Access functions are available with different situations in mind: - Convenience SNMP Functions In an effort to keep simple things simple, these functions are easy to use and promote easy to understand code. These functions will suffice for the majority of situations where a single Various Authors Expires May 22, 2001 [Page 19] Internet Draft Policy-Based Management MIB Nov 22, 2000 variable is referenced and the desired error recovery is to simply (and immediately) give up (and move to the next policy-element combination). In more complex cases, the General SNMP Functions can be used at the cost of several times the code complexity. The convenience SNMP functions are getint, getvar, exists, setint, setvar, setRowStatus, and searchcolumn. - General SNMP Functions The General SNMP functions allow nearly any legal SNMP Message to be generated, including those with multiple varbinds, getNext operations, notifications, and messages with explicit addressing or security specifications. The general SNMP functions are writeVarbind, readVarbind, and snmpsend. Many of the accessor functions use a string encoding of a value that may be one of many SMI data types as input or output parameters. The actual type is not encoded in the value, but rather is specified elsewhere, possibly by nature of the context in which it is used. The encodings are: Any Integer value (INTEGER, Integer32, Counter32, Counter64, Gauge32, Unsigned32, TimeTicks, Counter64): Ascii-encoded integer in ascii, range: -9223372036854775808 to 9223372036854775807 Note that getint and setint encode integers as C integer values and do not use this character string encoding. Octet String The character string contains the unencoded value of the octet string. Object Identifier A decimal ascii encoded object identifier stored in a string. subid: decimal oid: subid | subid '.' oid Note that ascii descriptors (e.g. "ifIndex") are never used in Various Authors Expires May 22, 2001 [Page 20] Internet Draft Policy-Based Management MIB Nov 22, 2000 these encodings "over the wire". They are never returned from accessor functions nor are they ever accepted by them. NMS user interfaces are encouraged to allow humans to view object identifiers with ascii descriptors, but they must translate those descriptors to dotted-decimal format before sending them in MIB objects to policy agents. 11.1.1. Convenience SNMP Functions 11.1.1.1. getint() The getint() function is used to retrieve the value of an SNMP MIB instance when it is known to be of a 32 bit unsigned integer type. 32-bit signed integer values may be retrieved but they may have undefined results if the sign bit is set. long getint(string oid) Oid is a string containing an ASCII dotted-decimal representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). 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 32-bit integer-valued object, execution of the containing code 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 May 22, 2001 [Page 21] Internet Draft Policy-Based Management MIB Nov 22, 2000 11.1.1.2. getvar() The getvar() function is used to retrieve the value of an SNMP MIB instance. string getvar(string oid, string value) Oid is a string containing an ASCII dotted-decimal representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). 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 execution of the containing code 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 returned value, encoded according to the returned type. The optional argument value will be filled in with the returned value if supplied. 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). 11.1.1.3. exists() The exists() function is used to verify the existence of an SNMP MIB instance. int exists(string oid) oid is a string containing an ASCII dotted-decimal representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). 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 Various Authors Expires May 22, 2001 [Page 22] Internet Draft Policy-Based Management MIB Nov 22, 2000 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). 11.1.1.4. 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(string oid, long value) oid is a string containing an ASCII dotted-decimal representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). The agent will set the variable specified by oid to the integer 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 set encounters any error, 0 is returned. If sucessful, 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). 11.1.1.5. setvar() The setvar() function is used to set a MIB instance to a certain value. The setvar() function is only valid in policyActions. If when executing a policyFilter, the agent Various Authors Expires May 22, 2001 [Page 23] Internet Draft Policy-Based Management MIB Nov 22, 2000 encounters a call to the setvar() 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 setvar(string oid, string value, int type) oid is a string containing an ASCII dotted-decimal representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). value is a string encoded in the format appropriate to the type parameter. The agent will set the variable specified by oid to the value specified by value. type is the type of the value parameter and will be one of the DataType Constants. 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 set encounters any error, 0 is returned. If sucessful, 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). 11.1.1.6. searchcolumn() int searchcolumn(string columnoid, string startoid, string value, int type, string oid) searchcolumn performs an SNMP walk on a portion of the MIB searching for objects with values equal to the `value' parameter. columnoid constrains the search to only those variables that share the same OID prefix (i.e. are beneath it in the OID tree). startoid is the OID sent in the first getnext packet. While the value has not been found and the returned OID still shares Various Authors Expires May 22, 2001 [Page 24] Internet Draft Policy-Based Management MIB Nov 22, 2000 the same prefix wth columnoid, the returned OID will be sent in the next getnext query. In the first search of a column, startoid will be set to the same value as columnoid. If the caller wishes to learn of more than one match, it should call searchcolumn multiple times where the startoid value should be set to the value returned from the previous invocation (effectively continuing the search). value is the value to be searched for. When a value is found that matches exactly, oid is set to the oid of the matched value. type describes the type of the value to be matched. If the search traverses beyond columnoid without finding a match, zero is returned. For example: To find an ethernet interface searchcolumn("ifType", "ifType", "6", Integer); This sends a getnext request for ifType and continues to walk the tree until a value matching 6 is found or a variable returns that is not in the 'ifType' subtree. To find the next ethernet interface, assuming interface #3 was discovered to be the first: searchcolumn("ifType", "ifType.3", "6", Integer); 11.1.1.7. setRowStatus() int setRowStatus(string oid, int maxTries) setRowStatus is used to automate the process of finding an unused row in a read-create table that uses RowStatus. oid is a string containing an ASCII dotted-decimal representation of an object identifier, with one of the subids replaced with a '*' character (e.g. "1.3.6.1.3.1.99.1.2.1.9.*"). The oid must reference an 'instance' of the RowStatus object and the '*' must replace any integer index item that may be set to some random value. Various Authors Expires May 22, 2001 [Page 25] Internet Draft Policy-Based Management MIB Nov 22, 2000 setRowStatus will come up with a random number for the selected index item and will attempt to create the instance with the createAndWait state. If the attempt fails, it will retry with a different random index value. It will attempt this no more than maxTries times. setRowStatus returns the successful integer value for the index. If unsuccessful after maxTries or if more than one '*' is in oid, -1 will be returned. 11.1.2. General SNMP Functions It is desireable for a general SNMP interface have the ability to perform SNMP operations on multiple variables at once and for it to allow multiple varbind lists to exist at once. The readVarbind and writeVarbind functions exist in order to provide these facilities in a language without pointers, arrays and memory allocators. readVarbind and writeVarbind access a data store of variable length varbindlists. The index of the varbindlist and the index of the variable within that varbindlist are specified in every readVarbind and writeVarbind operation. Once a varbindlist has been fully specified by one or more calls to writeVarbind, it is passed to snmpsend (by referencing the varbindlist index) and the number of varbinds to be included in the operation. When a response is returned, the contents of the response are in the same varbindlist (i.e. the same varbindlist index is used) and may be read by one or more calls to readVarbind. Varbinds in this data store are created automatically whenever they are written or read by any writeVarbind, readVarbind, or snmpsend operation. It is not a runtime error to read a varbind that has not been previously written, however the values read will be unpredictable. For example: writeVarbind(0, 0, "sysDescr.0", ...); writeVarbind(0, 1, "sysOID.0", ...); writeVarbind(0, 2, "ifNumber.0", ...); if (snmpsend(0, 3, Get, ...)) return; readVarbind(0, 0, iKnowItsSysDescr, iKnowItsaString, value, &len); Various Authors Expires May 22, 2001 [Page 26] Internet Draft Policy-Based Management MIB Nov 22, 2000 readVarbind(0, 1, ...) readVarbind(0, 2, ...) ... or, writeVarbind(0, 0, "ifIndex", ...); writeVarbind(0, 1, "ifType", ...); while(!done){ if (snmpsend(0, 2, Getnext, ...)) continue; readVarbind(0, 0, oid1, ...); readVarbind(0, 1, oid2, ...); /* leave OIDs alone, now varbindlist #0 is set up for next step in table walk. */ if (oidncmp(oid1, "ifIndex", oidlen("ifIndex"))) done = 0; ... } To be conformant to this specification, implementations must support at least 5 varbindlists with at least 32 varbinds per list. Implementations may, but are not required to, initialize the varbind database when a new filter or action begins executing. A policy filter or action can only depend on the state it has written into this datastore or retrieves with accessor functions. 11.1.2.1. writeVarbind() void writeVarbind(int varbindListIndex, int varBindIndex, string oid, int type, string value) writeVarbind will store the oid, the value and it's type in the specified varbind. varbindListIndex is a non-negative integer that identifies the varbindList modified by this call. varbindIndex is a non-negative integer that identifies the varbind within the varbindList modified by this call. oid is a string containing an ASCII dotted-decimal Various Authors Expires May 22, 2001 [Page 27] Internet Draft Policy-Based Management MIB Nov 22, 2000 representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). type is the type of the value parameter and should be set to one of the values for DataType Constants. value is a string encoded in the format appropriate to the type parameter. 11.1.2.2. readVarbind() void readVarbind(int varbindListIndex, int varBindIndex, string oid, int *type, string value) writeVarbind will retrieve the oid, the value and it's type from the specified varbind. varbindListIndex is a non-negative integer that identifies the varbindList read by this call. varbindIndex is a non-negative integer that identifies the varbind within the varbindList read by this call. The object identifier value of the referenced varbind will be copied into the oid parameter, formatted in an ASCII dotted-decimal representation (e.g. "1.3.6.1.2.1.1.1.0"). type is the type of the value parameter and will be set to one of the values for DataType Constants. value is a string encoded in the format appropriate to the type parameter. 11.1.2.3. snmpsend() int snmpsend(int varbindListIndex, int numVarbinds, int opcode) snmpsend will perform an SNMP operation using the specified varbindlist. 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. Various Authors Expires May 22, 2001 [Page 28] Internet Draft Policy-Based Management MIB Nov 22, 2000 The results of the operation will be placed in the same varbindList. If an error occurred, the varbindlist will remain unmodified except for the following: 1) If the response PDU had a nonzero error-index, the varbind specified by the error-index will have its type field replaced with associated error-status constant. 2) If the response PDU contained varbinds with exceptions, the type field of those varbinds will be replaced with the appropriate exception (Nosuchobject, NosuchInstance, or Endofmibview). 3) If the error-status was zero and there were no exceptions, the varbindlist will remain unmodified. (some examples of situations where this will apply are timeout and authentication failure). This function returns zero unless an error occurs in which case it returns the proper SNMP Error Constant. varbindListIndex is a non-negative integer that identifies the varbindList used by this operation. numVarbinds is a integer greater than zero that specified which varbinds in the varbindList will be used in this operation. The first N varbinds in the varbindList are used. opcode is the type of SNMP operation to perform and must be one of the values for SNMP Operation Constants. 11.2. Constants The following constants are defined for use in all SNMP Access Functions. Policy code will be executed in an environment where the following constants are declared. (Note that these constant declarations will not be visible in the policyFilter or policyAction MIB objects.) While these declarations are expressed here as C 'const's, the 'const' construct itself is not available to be used inside of policy code. -- Datatype Constants const int Integer = 1; Various Authors Expires May 22, 2001 [Page 29] Internet Draft Policy-Based Management MIB Nov 22, 2000 const int String = 2; const int Oid = 3; const int Integer32 = 4; const int Ipaddress = 5; const int Counter32 = 6; const int Gauge32 = 7; const int Unsigned32 = 8; const int Timeticks = 9; const int Opaque = 10; const int Counter64 = 11; -- SNMP Error Constants const int Nosuchobject = 21; const int Nosuchinstance = 22; const int Endofmibview = 23; const int Noerror = 24; const int Toobig = 25; const int Nosuchname = 26; const int Badvalue = 27; const int Readonly = 28; const int Generr = 29; const int Noaccess = 30; const int Wrongtype = 31; const int Wronglength = 32; const int Wrongencoding = 33; const int Wrongvalue = 34; const int Nocreation = 35; const int Inconsistentvalue = 36; const int Resourceunavailable = 37; const int Commitfailed = 38; const int Undofailed = 39; const int Authorizationerror = 40; const int Notwritable = 41; const int Badparameter = 42; const int Toolong = 43; const int Parseerror = 44; const int Authfailure = 45; const int Timeout = 46; -- SNMP Operation Constants const int Get = 0; const int Getnext = 1; Various Authors Expires May 22, 2001 [Page 30] Internet Draft Policy-Based Management MIB Nov 22, 2000 const int Set = 3; const int Trap = 4; const int Inform = 6; const int V2trap = 7; 11.3. Policy Configuration Access Functions Policy Configuration Access Functions provide access to information specifically related to the execution of policies. 11.3.1. roleMatch() The roleMatch() function is used to check to see if the current element has been assigned a particular role. int roleMatch(string roleString) Argument roleString is a 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. 11.3.2. capMatch() The capMatch() function is used to check to see if the current element has a certain capability. int capMatch(string capOid) Argument capability is a 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. 11.3.3. 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. Various Authors Expires May 22, 2001 [Page 31] Internet Draft Policy-Based Management MIB Nov 22, 2000 string elementName() elementName returns a 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. .fi .sh 3 "setScratchpad()" 11.3.4. setScratchpad() setScratchpad(string varName, int scope, string value) Every maxLatency time period, every policy runs once for each element. When the setScratchpad function executes, it stores a value that can be retrieved even after this policy execution code exits. The value of scope controls which policy/element combinations can retrieve this varName/value pair. The options for scope are: Global The varName/value combination will be available in the filter or action of any policy while executing on any element. Policy The varName/value combination will be available in any future execution of the filter or action of the current policy (regardless of what element the policy is executing on). PolicyElement The varName/value combination will be available in future executions of the filter or action of the current policy but only when the policy is executing on the current element. varName is a string used to identify the value. Subsequent retrievals of the same varName in the proper scope will return the value stored. Note that the namespace for varName is distinct for each scope. varName is case sensitive. value is a string containing the value to be stored. Various Authors Expires May 22, 2001 [Page 32] Internet Draft Policy-Based Management MIB Nov 22, 2000 11.3.5. getScratchpad() int getScratchpad(string varName, int scope, string value) The getScratchpad function allows the retrieval of values that were stored previously in this execution context or in other execution contexts. The value of scope controls which execution contexts can pass a value to this execution context. Refer to the definition of setScratchpad to see which values of scope can pass a value to which execution contexts. varName is a string used to identify the value. Subsequent retrievals of the same varName in the proper scope will return the value stored. Note that the namespace for varName is distinct for each scope. As a result, getScratchpad cannot force access to a variable in an inaccessible scope - it can only retrieve variables by referencing the proper scope in which they were set. varName is case sensitive. On successful return, value will be set to the value that was previously stored. This function returns 1 if a value was previously stored and 0 otherwise. Scratchpad Usage Examples Policy Element Action A ifIndex.1 setScratchpad("foo", Global, "55") A ifIndex.1 getScratchpad("foo", Global, val) == 55 A ifIndex.2 getScratchpad("foo", Global, val) == 55 B ifIndex.2 getScratchpad("foo", Global, val) == 55 B ifIndex.2 setScratchpad("foo", Global, "16") A ifIndex.1 getScratchpad("foo", Global, val) == 16 Policy Element Action A ifIndex.1 setScratchpad("bar", Policy, "75") A ifIndex.1 getScratchpad("bar", Policy, val) == 75 A ifIndex.2 getScratchpad("bar", Policy, val) == 75 B ifIndex.1 getScratchpad("bar", Policy, val) not found B ifIndex.1 setScratchpad("bar", Policy, "20") A ifIndex.2 getScratchpad("bar", Policy, val) == 75 B ifIndex.2 getScratchpad("bar", Policy, val) == 20 Policy Element Action Various Authors Expires May 22, 2001 [Page 33] Internet Draft Policy-Based Management MIB Nov 22, 2000 A ifIndex.1 setScratchpad("baz", PolicyElement, "43") A ifIndex.1 getScratchpad("baz", PolicyElement, val) == 43 A ifIndex.2 getScratchpad("baz", PolicyElement, val) not found B ifIndex.1 getScratchpad("baz", PolicyElement, val) not found A ifIndex.2 setScratchpad("baz", PolicyElement, "54") B ifIndex.1 setScratchpad("baz", PolicyElement, "65") A ifIndex.1 getScratchpad("baz", PolicyElement, val) == 43 A ifIndex.2 getScratchpad("baz", PolicyElement, val) == 54 B ifIndex.1 getScratchpad("baz", PolicyElement, val) == 65 Policy Element Action A ifIndex.1 setScratchpad("foo", PolicyElement, "11") A ifIndex.1 setScratchpad("foo", Global, "22") A ifIndex.1 getScratchpad("foo", PolicyElement, val) == 11 A ifIndex.1 getScratchpad("foo", Global, val) == 22 11.3.6. Constants The following constants are defined for use for the scratchpad functions. Policy code will be executed in an environment where the following constants are declared. (Note that these constant declarations will not be visible in the policyFilter or policyAction MIB objects.) While these declarations are expressed here as C 'const's, the 'const' construct itself is not available to be used inside of policy code. -- Scratchpad Constants const int Global = 0; const int Policy = 1; const int PolicyElement = 2; 11.4. Utility Accessor Functions Utility Accessor Functions are provided to enable more efficient use of the other accessor functions. Various Authors Expires May 22, 2001 [Page 34] Internet Draft Policy-Based Management MIB Nov 22, 2000 11.4.1. oidlength() int oidlen(string oid) oidlen returns the number of subidentifiers in oid. oid is a string containing an ASCII dotted-decimal representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). 11.4.2. oidncmp() int oidncmp(string oid1, string oid2, int n) Arguments oid1 and oid2 are strings containing ASCII dotted-decimal representations of object identifiers (e.g. "1.3.6.1.2.1.1.1.0"). Compares the first n subidentifiers of oid1 and oid2 and returns -1 if oid1 is less than oid2, 0 if they are equal, and 1 if oid1 is greater than oid2. 11.4.3. subid() int subid(string oid, int n) subid returns the value of the n'th (starting at zero) subidentifier of oid. oid is a string containing an ASCII dotted-decimal representation of an object identifier (e.g. "1.3.6.1.2.1.1.1.0"). If n specifies a subidentifier beyond the length of oid, a value of -1 is returned. 11.4.4. subidwrite() int subidwrite(string oid, int n, int subid) subid sets the value of the n'th (starting at zero) subidentifier of oid to `subid'. oid is a 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 May 22, 2001 [Page 35] Internet Draft Policy-Based Management MIB Nov 22, 2000 If n specifies a subidentifier beyond the length of oid, a value of -1 is returned. 11.4.5. oidsplice() string oidsplice(string oid1, int m, string oid2, int n) oidsplice replaces n subidentifiers in oid1 with all of the subidentifiers from oid2, starting at the m'th subidentifier in oid1. The oid length will be extended if necessary. The resulting oid is returned. 11.5. Library Accessor Functions The following standard library accessor functions are provided: strncmp() strncasecmp() strncat() strlen() strncpy() atoi() random() memcmp() memmove() sprintf() Various Authors Expires May 22, 2001 [Page 36] Internet Draft Policy-Based Management MIB Nov 22, 2000 12. Definitions POLICY-MANAGEMENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, Gauge32, Unsigned32, experimental FROM SNMPv2-SMI RowStatus, RowPointer, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- Policy-Based Management MIB policyMgt MODULE-IDENTITY LAST-UPDATED "200011221500Z" -- November 22, 2000 ORGANIZATION "IETF SNMP Configuration Working Group" CONTACT-INFO " Steve Waldbusser Phone: +1-650-948-6500 Fax: +1-650-745-0671 Email: waldbusser@nextbeacon.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" Various Authors Expires May 22, 2001 [Page 37] Internet Draft Policy-Based Management MIB Nov 22, 2000 DESCRIPTION "The MIB module for rule-based configuration of SNMP infrastructures." REVISION "200011221500Z" -- November 22, 2000 DESCRIPTION "The original version of this MIB, published as RFCXXXX." ::= { experimental 107 } UTF8String ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "An octet string containing information typically in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. Various Authors Expires May 22, 2001 [Page 38] Internet Draft Policy-Based Management MIB Nov 22, 2000 UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC1905]. Note that the size of an UTF8String object is measured in octets, not characters." SYNTAX OCTET STRING -- 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 elements." ::= { 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 Unsigned32, pmPolicyFilter Unsigned32, pmPolicyCalendar RowPointer, pmPolicyAction Unsigned32, Various Authors Expires May 22, 2001 [Page 39] Internet Draft Policy-Based Management MIB Nov 22, 2000 pmPolicyFilterMaxLatency Unsigned32, pmPolicyActionMaxLatency Unsigned32, pmPolicyPrecedence Unsigned32, pmPolicyGroup UTF8String, pmPolicyDescription UTF8String, pmPolicyMatches Gauge32, pmPolicyAbnormalTerminations Gauge32, pmPolicyExecutionErrors Counter32, pmPolicyDebugging INTEGER, pmPolicyStatus RowStatus } pmPolicyIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this policy entry." ::= { pmPolicyEntry 1 } pmPolicyFilter OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the row or rows in the pmPolicyCodeTable that contain the filter code for this policy. When a policy entry is created, an unused pmPolicyCodeIndex value will be assigned to this object. A policy filter is one or more policy language statements which results in a boolean value that represents whether or not an element is a member of a set of elements upon which an action is to be performed. Filter evaluation stops immediately when any error is detected without executing the policyAction. The policyFilter is evaluated for various elements. Any element for which the policyFilter returns any nonzero value will match the filter and will have the associated policyAction executed on that element." ::= { pmPolicyEntry 2 } Various Authors Expires May 22, 2001 [Page 40] Internet Draft Policy-Based Management MIB Nov 22, 2000 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 Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A pointer to the row or rows in the pmPolicyCodeTable that contain the action code for this policy. When a policy entry is created, an unused pmPolicyCodeIndex value will be assigned to this object. A pmPolicyAction is an operation performed on a set of elements. Action evaluation stops immediately when any error is detected." ::= { pmPolicyEntry 4 } pmPolicyFilterMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Every element under the control of this agent is re-checked periodically to see if it is under control of this policy by re-running the filter for this policy. This object lets the manager control the maximum amount of time that may pass before an element is re-checked. In other words, in any given interval of this duration, all elements must be re-checked. Note that it is an implementation-dependent matter as to how the policy agent Various Authors Expires May 22, 2001 [Page 41] Internet Draft Policy-Based Management MIB Nov 22, 2000 schedules the checking of various elements within this interval." ::= { pmPolicyEntry 5 } pmPolicyActionMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Every element that matches this policy's filter and is therefore under control of this policy will have this policy's action executed periodically to ensure that the element remains in the state dictated by the policy. This object lets the manager control the maximum amount of time that may pass before an element has the action run on it. In other words, in any given interval of this duration, all elements under control of this policy must have the action run on them. Note that it is an implementation-dependent matter as to how the policy agent schedules the policy action on various elements within this interval." ::= { pmPolicyEntry 6 } pmPolicyPrecedence OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The order in which policies on the local system are evaluated. A policy with a higher precedence value will be evaluated after a policy with a lower precedence. For example, a policy with a precedence value of 999 will be evaluated after a policy with a precedence value of 998. These values must be unique on the local policy system that realizes this module. The value for a particular policy should be the same across an administrative domain, though that is not mandatory. When the local policy system performs the evaluation in the pmPolicyFilter for the policy identified by this row it will also read the pmTrackingElementToPolicyStatus object for each object returned as a result of the policy evaluation. If that object is set to modified(3), then the pmPolicyAction shall Various Authors Expires May 22, 2001 [Page 42] Internet Draft Policy-Based Management MIB Nov 22, 2000 not be taken on that element. The value of precedence(4), of pmTrackingElementToPolicyStatus is an indication that when an evaluation was performed by another policy, the pmTrackingElementToPolicyStatus was found to have a value of on(1) and that policy had a higher precedence value than the policy that initially set the value of the pmTrackingElementToPolicyStatus to on(1). In this event, the pmTrackingElementToPolicyPrecedence object shall have the value of the pmPolicyIndex for the policy with the higher precedence value entered. If the policy identified by this row of the pmPolicyTable has a higher precedence value than the value found in pmTrackingElementToPolicyPrecedence then the pmPolicyAction should be performed on the element and the pmTrackingElementToPolicyPrecedence object updated with the value of the pmPolicyIndex for this policy. The only exception to these rules is when the policy that has the higher precedence value in not currently running, i.e., the schedule is off." ::= { pmPolicyEntry 7 } pmPolicyGroup OBJECT-TYPE SYNTAX UTF8String (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively assigned string that is used to group policies. Any combination is legal, the pmPolicyGroup object does not constrain precedence. That is precedence is evaluated independent of grouping though adminstrators might group related policies together for clarity." ::= { pmPolicyEntry 8 } pmPolicyDescription OBJECT-TYPE SYNTAX UTF8String (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "A description of this rule and its significance, typically provided by a human." ::= { pmPolicyEntry 9 } pmPolicyMatches OBJECT-TYPE SYNTAX Gauge32 UNITS "elements" Various Authors Expires May 22, 2001 [Page 43] Internet Draft Policy-Based Management MIB Nov 22, 2000 MAX-ACCESS read-create STATUS current DESCRIPTION "The number of elements that are currently matched by the associated pmPolicyFilter." ::= { pmPolicyEntry 10 } pmPolicyAbnormalTerminations OBJECT-TYPE SYNTAX Gauge32 UNITS "elements" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of elements that have experienced processing errors in the policyFilter code." ::= { pmPolicyEntry 11 } pmPolicyExecutionErrors OBJECT-TYPE SYNTAX Counter32 UNITS "errors" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times execution of this policy has been terminated due to run-time errors." ::= { pmPolicyEntry 12 } pmPolicyDebugging OBJECT-TYPE SYNTAX INTEGER { off(0), on(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "The status of debugging for this policy. If this is turned on(1), log entries will be created in the pmDebuggingTable for each run-time error that is experienced by this policy." DEFVAL { off } ::= { pmPolicyEntry 13 } pmPolicyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current Various Authors Expires May 22, 2001 [Page 44] Internet Draft Policy-Based Management MIB Nov 22, 2000 DESCRIPTION "The status of this pmPolicyEntry. The status may not be set to active if any of the related entries in the pmPolicyCode table do not have a status of active." ::= { pmPolicyEntry 14 } pmPolicyCodeTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPolicyCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmPolicyCodeTable stores the code for policy filters and actions." ::= { policyMgt 2 } pmPolicyCodeEntry OBJECT-TYPE SYNTAX PmPolicyCodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the policy code table." INDEX { pmPolicyCodeProgramIndex, pmPolicyCodeSegment } ::= { pmPolicyCodeTable 1 } PmPolicyCodeEntry ::= SEQUENCE { pmPolicyCodeProgramIndex Unsigned32, pmPolicyCodeSegment Unsigned32, pmPolicyCodeText UTF8String, pmPolicyCodeStatus RowStatus } pmPolicyCodeProgramIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for each policy filter or action. The code for each such filter or action may be composed of multiple entries in this table if the code cannot fit in one entry. Values of pmPolicyCodeProgramIndex may not be used unless they have previously been assigned in the pmPolicyFilterProgramIndex or pmPolicyActionProgramIndex Various Authors Expires May 22, 2001 [Page 45] Internet Draft Policy-Based Management MIB Nov 22, 2000 objects." ::= { pmPolicyCodeEntry 1 } pmPolicyCodeSegment OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for each segment of a policy filter or action. When a policy filter or action spans multiple entries in this table, the code of that policy starts from the lowest-numbered segment and continues with increasing segment values until ending with the highest-numbered segment." ::= { pmPolicyCodeEntry 2 } pmPolicyCodeText OBJECT-TYPE SYNTAX UTF8String (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "A segment of policy code (filter or action). Lengthy Policy filters or actions may be stored in multiple segments in this table that share the same value of pmPolicyCodeProgramIndex. When multiple segments are used, it is recommended that each segment be as large as practical. The code Entries in this table are associated with policies by values of the pmPolicyFilterProgramIndex and pmPolicyActionProgramIndex objects. If the status of the related policy is active, then this object may not be modified." ::= { pmPolicyCodeEntry 3 } pmPolicyCodeStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this code entry. Entries in this table are associated with policies by values Various Authors Expires May 22, 2001 [Page 46] Internet Draft Policy-Based Management MIB Nov 22, 2000 of the pmPolicyFilterProgramIndex and pmPolicyActionProgramIndex objects. If the status of the related policy is active, then entries in this table may not be created or deleted." ::= { pmPolicyCodeEntry 4 } -- Element Type Registration Table -- The Element Type Registration table is used for the manager to -- learn what element types are being managed by the system and to -- register new types if necessary. An element type is registered by -- providing the OID of an SNMP object (i.e., without the -- instance). Each SNMP instance that exists under that object is a -- distinct element. The address of the element is the index part of -- the discovered OID. This address will be supplied to policy filters -- and actions so that this code can inspect and configure the -- element. -- -- Before registering an element type, it is the responsibility of a -- manager to inspect the table and see if it is already registered -- (by the agent or another manager). Note that entries that differ -- only in the last OID (which specifies which object in an entry) are -- effectively duplicates and should be treated as such by the -- manager. -- -- Note that agents may automatically configure elements in this -- table. pmElementTypeRegTable OBJECT-TYPE SYNTAX SEQUENCE OF PmElementTypeRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A registration table for element types managed by this system." ::= { policyMgt 3 } pmElementTypeRegEntry OBJECT-TYPE SYNTAX PmElementTypeRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A registration of an element type." INDEX { pmElementTypeRegIndex } ::= { pmElementTypeRegTable 1 } Various Authors Expires May 22, 2001 [Page 47] Internet Draft Policy-Based Management MIB Nov 22, 2000 PmElementTypeRegEntry ::= SEQUENCE { pmElementTypeRegIndex Unsigned32, pmElementTypeRegOIDPrefix OBJECT IDENTIFIER, pmElementTypeRegMaxLatency Unsigned32, pmElementTypeRegName UTF8String, pmElementTypeRegRowStatus RowStatus } pmElementTypeRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this entry." ::= { pmElementTypeRegEntry 1 } pmElementTypeRegOIDPrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "An OBJECT IDENTIFIER subtree under which all instances of this element type may be found. This OBJECT IDENTIFIER should be specified up to, but not including, any index objects. The agent will discover all instances in the system that are members of the specified subtree. It will then execute policy filters (and potentially policy actions) for each instance discovered. Each invocation of the policy filter will be supplied with a parameter. This is derived by taking the last N sub-identifiers from the discovered instance, where N is: X = number of sub-identifiers in pmElementTypeRegOIDPrefix Y = number of sub-identifiers in discovered instance N = Y - X " ::= { pmElementTypeRegEntry 2 } pmElementTypeRegMaxLatency OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create Various Authors Expires May 22, 2001 [Page 48] Internet Draft Policy-Based Management MIB Nov 22, 2000 STATUS current DESCRIPTION "The PM agent is responsible for discovering new elements of types that are registered. This object lets the manager control the maximum amount of time that may pass between the time an element is created and when it is discovered. In other words, in any given interval of this duration, all new elements must be discovered. Note that it is an implementation-dependent matter as to how the policy agent schedules the checking of various elements within this interval." ::= { pmElementTypeRegEntry 3 } pmElementTypeRegName OBJECT-TYPE SYNTAX UTF8String (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A descriptive label for this registered type." ::= { pmElementTypeRegEntry 4 } pmElementTypeRegRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this registration entry." ::= { pmElementTypeRegEntry 5 } -- Role Tables -- The Role tables associate role strings to elements. It is the -- responsibility of the agent to keep track of any re-indexing of the -- underlying SNMP elements and to continue to associate role strings -- with the element with which they were initially configured. -- -- The agent must store role string associations in nonvolatile -- storage. -- -- The Role String table is visible through 2 SNMP tables. The -- pmRoleESTable is a read-create table that organizes 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 Various Authors Expires May 22, 2001 [Page 49] Internet Draft Policy-Based Management MIB Nov 22, 2000 -- 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 4 } 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 UTF8String, 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 UTF8String (SIZE (0..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "The role string that is associated with an element through Various Authors Expires May 22, 2001 [Page 50] Internet Draft Policy-Based Management MIB Nov 22, 2000 this table. A role string is an administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules, to determine the applicability of the rule to a particular managed element." ::= { pmRoleESEntry 2 } pmRoleESStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this role string." ::= { pmRoleESEntry 3 } 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 5 } 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 UTF8String, pmRoleSEElement RowPointer } pmRoleSEString OBJECT-TYPE SYNTAX UTF8String (SIZE (0..64)) MAX-ACCESS not-accessible Various Authors Expires May 22, 2001 [Page 51] Internet Draft Policy-Based Management MIB Nov 22, 2000 STATUS current DESCRIPTION "The role string that is associated with an element through this table. A role string is an administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules, to determine the applicability of the rule to a particular managed element." ::= { 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 underlying element." ::= { pmRoleSEEntry 2 } -- Capabilities table -- Note that with this table it is not necessary to list all OIDs that -- a mechanism specific MIB Module supports, just the base OID if -- the implementation is a fully compliant one. If the implementation -- is not, then additional rows will exist in the table that list -- the limitations or enhancements. 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 6 } pmCapabilitiesEntry OBJECT-TYPE SYNTAX PmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current Various Authors Expires May 22, 2001 [Page 52] Internet Draft Policy-Based Management MIB Nov 22, 2000 DESCRIPTION "The description of a capability or limitation of a capability of the system. An entry will exist for each domain and mechanism specific ability the system has. In the case of a domain specific capability with no mechanism specific parameters, the pmCapabilitiesSubType and all other columns may be null. Entries will exist that contain values for the pmCapabilitiesRestrictOID, pmCapabilitiesRestrictType, pmCapabilitiesRestrictValue and pmCapabilitiesRestrictString objects only when an implementation is reporting a mechanism specific restriction. Multiple entries are possible when more than one restriction for a type or subtype are needed." INDEX { pmCapabilitiesIndex } ::= { pmCapabilitiesTable 1 } PmCapabilitiesEntry ::= SEQUENCE { pmCapabilitiesIndex Unsigned32, pmCapabilitiesType OBJECT IDENTIFIER, pmCapabilitiesSubType OBJECT IDENTIFIER, pmCapabilitiesModificationOID OBJECT IDENTIFIER, pmCapabilitiesModificationType INTEGER, pmCapabilitiesModificationValue Integer32, pmCapabilitiesModificationString OCTET STRING } pmCapabilitiesIndex OBJECT-TYPE SYNTAX Unsigned32 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 "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 } pmCapabilitiesSubType OBJECT-TYPE Various Authors Expires May 22, 2001 [Page 53] Internet Draft Policy-Based Management MIB Nov 22, 2000 SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The sub type of capability is a pointer to a mechanism specific set of capabilities supporting a base technology. In the case of DIFFSERV, the OID value here would be the base OID of the Differentiated Services Policy MIB Module." ::= { pmCapabilitiesEntry 3 } pmCapabilitiesModificationOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The OID of the object that is either not supported, supported with one or more limitations, or expanded by an implementation specific module. If this columnar object is other than null then there must be at least an entry in pmCapabilitiesModificationType. Note that this need not be a leaf node or scalar object. If an entire table is not supported, this value can be the base OID for the table." ::= { pmCapabilitiesEntry 4 } pmCapabilitiesModificationType OBJECT-TYPE SYNTAX INTEGER { unsupported(0), restricted(1), additional(2), addvalue(3), maxlimit(4), minlimit(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "An unsupported value indicates that the OID in pmCapabilitiesModificationOID is not supported on this system. A value of 1 indicates that the OID is supported but with restricted values These constraints are described in the pmCapabilitiesModificationValue and pmCapabilitiesModificationString objects. A value of 2 indicates a vendor specific extension to a standard. The OID of the new object is pmCapabilitiesModificationOID. Various Authors Expires May 22, 2001 [Page 54] Internet Draft Policy-Based Management MIB Nov 22, 2000 For some implementations, additional functions may be provided. addvalue indicates that this row of the table describes an additional value that the object can take. The specific value is in the pmCapabilitiesModificationValue. The values of 4 and 5 indicate restrictions or the removal of restrictions for the object identified." ::= { pmCapabilitiesEntry 5 } pmCapabilitiesModificationValue OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of pmCapabilitiesModificationType is 0, this object will be null since 0 indicates no support for the object at all. A value of 1 in the pmCapabilitiesModificationType will be further modified by a single integer value in this object that corresponds to enumerated integer values that are not supported by the system for the object that is identified in this row. This value can also represent the limit values in the pmCapabilitiesModificationType object." ::= { pmCapabilitiesEntry 6 } pmCapabilitiesModificationString OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Any additional details or description or parameters needed." ::= { pmCapabilitiesEntry 7 } -- 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. This table is indexed in order to optimize retrieval of the entire status for a given policy." ::= { policyMgt 7 } Various Authors Expires May 22, 2001 [Page 55] Internet Draft Policy-Based Management MIB Nov 22, 2000 pmTrackingPolicyToElementEntry OBJECT-TYPE SYNTAX PmTrackingPolicyToElementEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmTrackingPolicyToElementTable. The pmPolicyIndex in the index specifies the policy tracked by this entry." 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 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 } Various Authors Expires May 22, 2001 [Page 56] Internet Draft Policy-Based Management MIB Nov 22, 2000 -- 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. This table is indexed in order to optimize retrieval of the status of all policies active for a given element." ::= { policyMgt 8 } pmTrackingElementToPolicyEntry OBJECT-TYPE SYNTAX PmTrackingElementToPolicyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmTrackingElementToPolicyTable. The pmPolicyIndex in the index specifies the policy tracked by this entry." 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." ::= { pmTrackingElementToPolicyEntry 1 } pmTrackingElementToPolicyStatus OBJECT-TYPE SYNTAX INTEGER { off(0), on(1), forceOff(2) } MAX-ACCESS read-write STATUS current Various Authors Expires May 22, 2001 [Page 57] Internet Draft Policy-Based Management MIB Nov 22, 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 not exist in this table if their status would be off(0). A policy can be forcibly disabled on a particular element 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 } -- Policy Debugging Table -- Policies that have debugging turned on will generate a log entry in -- the policy debugging table for every runtine error that occurs in -- either the filter or action code. pmDebuggingTable OBJECT-TYPE SYNTAX SEQUENCE OF PmDebuggingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmDebuggingTable logs debugging messages when policies experience runtime errors." ::= { policyMgt 9 } pmDebuggingEntry OBJECT-TYPE SYNTAX PmDebuggingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmDebuggingTable. The pmPolicyIndex in the index specifies the policy that encountered the error that led to this log entry." INDEX { pmPolicyIndex, pmDebuggingElement, pmDebuggingLogIndex } ::= { pmDebuggingTable 1 } PmDebuggingEntry ::= SEQUENCE { Various Authors Expires May 22, 2001 [Page 58] Internet Draft Policy-Based Management MIB Nov 22, 2000 pmDebuggingElement RowPointer, pmDebuggingLogIndex Unsigned32, pmDebuggingMessage UTF8String } pmDebuggingElement OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "The element the policy was executing on when it encountered the error that led to this log entry." ::= { pmDebuggingEntry 1 } pmDebuggingLogIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "A unique index for this log entry amongst other log entries for this policy/element combination." ::= { pmDebuggingEntry 2 } pmDebuggingMessage OBJECT-TYPE SYNTAX UTF8String (SIZE (0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "An error message generated by the policy execution environment." ::= { pmDebuggingEntry 3 } -- Notification Registration Table -- A management station may choose not to download policies to a -- system that depend on roles or capabilities that don't exist on any -- elements in the system. However, the management station must be able -- to quickly learn if new roles or capabilities are added to the -- system so that it can immediately download the policies that make -- use of that new role or capability. This table allows a management -- station to register itself so that it will receive -- pmNewRoleNotifications and pmNewCapabilityNotifications whenever a -- role or capability first appears on the system. -- -- pmNewRoleNotifications and pmNewCapabilityNotifications are sent in -- Inform PDU's so they are automatically retransmitted if they are Various Authors Expires May 22, 2001 [Page 59] Internet Draft Policy-Based Management MIB Nov 22, 2000 -- not acknowledged. -- -- The procedure to guarantee accurate knowledge of roles and -- capabilities is as follows: -- -- Step 1: The NMS registers itself in the pmNotificationRegTable -- Whenever it receives a notification, it adds the new role -- or capability to its internal database for that system. -- Followed immediately by: -- Step 2: The NMS downloads the roles and capabilities from the -- system from the pmRoleESTable (or pmRoleSETable) and the -- pmCapabilitiesTable, adding this information to its -- internal database. -- Followed immediately by: -- Step 3: The NMS downloads policies to the system, potentially -- skipping policies that depend on roles or capabilities -- that haven't been inserted into the internal database. -- Followed immediately by: -- Step 4: Whenever a notification indicates a new role or -- capability that requires new policies to be downloaded, -- it will immediately download such policies. The NMS will -- continue this step indefinitely. pmNotificationRegTable OBJECT-TYPE SYNTAX SEQUENCE OF PmNotificationRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A manager that wishes to receive notifications about new roles or capabilities on an agent places an entry in the notification registration table. pmNewRoleNotifications and pmNewCapabilityNotifications will then be sent to the target specified in the associated snmpTargetAddr entry. These notifications will be sent until the entry is removed from this table." ::= { policyMgt 10 } pmNotificationRegEntry OBJECT-TYPE SYNTAX PmNotificationRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the pmNotificationRegTable." INDEX { pmNotificationRegIndex } ::= { pmNotificationRegTable 1 } Various Authors Expires May 22, 2001 [Page 60] Internet Draft Policy-Based Management MIB Nov 22, 2000 PmNotificationRegEntry ::= SEQUENCE { pmNotificationRegIndex Unsigned32, pmNotificationRegSnmpTargetAddrName SnmpAdminString, pmNotificationRegStatus RowStatus } pmNotificationRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this entry." ::= { pmNotificationRegEntry 1 } pmNotificationRegSnmpTargetAddrName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The snmpTargetAddrName of an associated snmpTargetAddrEntry. When the following conditions are true, pmNewRoleNotifications and pmNewCapabilityNotifications should be sent to the specified target: 1) The pmNotificationRegEntry is active 2) The associated snmpTargetAddr entry is fully configured and active. 3) The associated snmpTargetParams entry is fully configured and active." ::= { pmNotificationRegEntry 2 } pmNotificationRegStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this entry." ::= { pmNotificationRegEntry 3 } -- Notifications pmNotifications OBJECT IDENTIFIER ::= { policyMgt 11 } pmNewRoleNotification NOTIFICATION-TYPE OBJECTS { pmRoleESString } Various Authors Expires May 22, 2001 [Page 61] Internet Draft Policy-Based Management MIB Nov 22, 2000 STATUS current DESCRIPTION "The pmNewRoleNotification is sent when an agent is configured with its first instance of a previously unused role string (not every time a new element is given a particular role). An instance of the pmRoleESString object is sent containing the new roleString. In the event that two or more elements are given the same role simultaneously, it is an implementation-dependent matter as to which pmRoleESString instance will be included in the notification." ::= { pmNotifications 1 } pmNewCapabilityNotification NOTIFICATION-TYPE OBJECTS { pmCapabilitiesType } STATUS current DESCRIPTION "The pmNewCapabilityNotification is sent when an agent gains a new capability that did not previously exist in any element on the system (not every time an element gains a particular role). An instance of the pmCapabilitiesType object is sent containing the identity of the new capability. In the event that two or more elements gain the same role simultaneously, it is an implementation-dependent matter as to which pmCapabilitiesType instance will be included in the notification." ::= { pmNotifications 2 } -- Compliance Statements pmConformance OBJECT IDENTIFIER ::= { policyMgt 20 } pmCompliances OBJECT IDENTIFIER ::= { pmConformance 1 } pmGroups OBJECT IDENTIFIER ::= { pmConformance 2 } pmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the Policy-Based Management MIB" MODULE -- this module MANDATORY-GROUPS { pmPolicyManagementGroup, pmNotificationGroup } ::= { pmCompliances 1 } Various Authors Expires May 22, 2001 [Page 62] Internet Draft Policy-Based Management MIB Nov 22, 2000 pmPolicyManagementGroup OBJECT-GROUP OBJECTS { pmPolicyFilter, pmPolicyCalendar, pmPolicyAction, pmPolicyFilterMaxLatency, pmPolicyActionMaxLatency, pmPolicyPrecedence, pmPolicyGroup, pmPolicyDescription, pmPolicyMatches, pmPolicyAbnormalTerminations, pmPolicyExecutionErrors, pmPolicyDebugging, pmPolicyStatus, pmPolicyCodeText, pmPolicyCodeStatus, pmElementTypeRegOIDPrefix, pmElementTypeRegMaxLatency, pmElementTypeRegName, pmElementTypeRegRowStatus, pmRoleESString, pmRoleESStatus, pmRoleSEElement, pmCapabilitiesType, pmCapabilitiesSubType, pmCapabilitiesModificationOID, pmCapabilitiesModificationType, pmCapabilitiesModificationValue, pmCapabilitiesModificationString, pmTrackingPolicyToElementStatus, pmTrackingElementToPolicyStatus, pmDebuggingElement, pmDebuggingLogIndex, pmDebuggingMessage, pmNotificationRegSnmpTargetAddrName, pmNotificationRegStatus } STATUS current DESCRIPTION "Objects that allow for the creation and management of configuration policies." ::= { pmGroups 1 } pmNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { pmNewRoleNotification, pmNewCapabilityNotification } STATUS current DESCRIPTION "Notifications sent by an Policy MIB agent." ::= { pmGroups 2 } pmBaseFunctionLibrary OBJECT IDENTIFIER ::= { pmGroups 2 } END Various Authors Expires May 22, 2001 [Page 63] Internet Draft Policy-Based Management MIB Nov 22, 2000 13. 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 May 22, 2001 [Page 64] Internet Draft Policy-Based Management MIB Nov 22, 2000 14. 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 May 22, 2001 [Page 65] Internet Draft Policy-Based Management MIB Nov 22, 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] International Standards Organization, "C Language Specification", X3J11 [20] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations", RFC 2591, May 1999. 15. 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 May 22, 2001 [Page 66] Internet Draft Policy-Based Management MIB Nov 22, 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. 16. 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 May 22, 2001 [Page 67] Internet Draft Policy-Based Management MIB Nov 22, 2000 Table of Contents 1 Abstract .............................................. 1 2 The SNMP Management Framework ......................... 2 3 Overview .............................................. 4 4 Policy-Based Management Architecture .................. 5 5 Policy Based Management Execution Environment ......... 8 5.1 Element Discovery ................................... 8 5.1.1 Implementation Notes .............................. 9 5.2 Element Filtering ................................... 9 5.2.1 Implementation Notes .............................. 10 5.3 Policy Enforcement .................................. 10 5.3.1 Implementation Notes .............................. 11 6 Policy Language ....................................... 12 6.1 Formal Definition ................................... 12 7 Sizes of variables .................................... 17 8 String type ........................................... 17 8.1 Infix string operators .............................. 17 9 Address of `this element' ............................. 18 10 Accessor Functions ................................... 19 11 Base Accessor Function Library ....................... 19 11.1 SNMP Access Functions .............................. 19 11.1.1 Convenience SNMP Functions ....................... 21 11.1.1.1 getint() ....................................... 21 11.1.1.2 getvar() ....................................... 22 11.1.1.3 exists() ....................................... 22 11.1.1.4 setint() ....................................... 23 11.1.1.5 setvar() ....................................... 23 11.1.1.6 searchcolumn() ................................. 24 11.1.1.7 setRowStatus() ................................. 25 11.1.2 General SNMP Functions ........................... 26 11.1.2.1 writeVarbind() ................................. 27 11.1.2.2 readVarbind() .................................. 28 11.1.2.3 snmpsend() ..................................... 28 11.2 Constants .......................................... 29 11.3 Policy Configuration Access Functions .............. 31 11.3.1 roleMatch() ...................................... 31 11.3.2 capMatch() ....................................... 31 11.3.3 elementName() .................................... 31 11.3.4 setScratchpad() .................................. 32 11.3.5 getScratchpad() .................................. 33 11.3.6 Constants ........................................ 34 11.4 Utility Accessor Functions ......................... 34 11.4.1 oidlength() ...................................... 35 Various Authors Expires May 22, 2001 [Page 68] Internet Draft Policy-Based Management MIB Nov 22, 2000 11.4.2 oidncmp() ........................................ 35 11.4.3 subid() .......................................... 35 11.4.4 subidwrite() ..................................... 35 11.4.5 oidsplice() ...................................... 36 11.5 Library Accessor Functions ......................... 36 12 Definitions .......................................... 37 13 Security Considerations .............................. 64 14 References ........................................... 65 15 Intellectual Property ................................ 66 16 Full Copyright Statement ............................. 67 Various Authors Expires May 22, 2001 [Page 69] --------------E83CA73EF5A8BC0AC99BE3EA-- From owner-snmpconf@seymour39.SNMP.COM Tue Nov 28 09:50:13 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05395 for ; Tue, 28 Nov 2000 09:50:13 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA27652 for snmpconf-outgoing; Tue, 28 Nov 2000 09:35:59 -0500 (EST) Message-Id: <200011281435.JAA05548@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf Documents for IETF49 San Diego Date: Tue, 28 Nov 2000 09:35:56 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com All three documents for the next IETF are available in ftp://ftp.snmp.com/pub/snmpconf/ietf49/documents The documents are stored as draft-ietf-snmpconf-bcp-03.txt draft-ietf-snmpconf-diffpolicy-03.txt draft-ietf-snmpconf-pm-04.txt The documents will remain there indefinitely. The documents will also eventually be available in the IETF repository, but as of 5:15 this morning they were not yet present. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpconf@seymour39.SNMP.COM Wed Nov 29 06:46:19 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09780 for ; Wed, 29 Nov 2000 06:46:18 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA26879 for snmpconf-outgoing; Wed, 29 Nov 2000 06:27:16 -0500 (EST) Message-Id: <200011291127.GAA29430@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-03.txt Date: Wed, 29 Nov 2000 06:27:01 -0500 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, W. Tackabury Filename : draft-ietf-snmpconf-bcp-03.txt Pages : 58 Date : 28-Nov-00 This document is for a variety of readers interested in the Internet Standard Management Framework for the Simple Network Management Protocol[SNMP]. In particular, it offers guidance in the SNMP usage for effective configuration management. This information is relevant to vendors that build network elements, third party application developers, and those that acquire and deploy this technology in their networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-03.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-03.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-03.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: <20001128133504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-bcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-bcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128133504.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Thu Nov 30 06: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 SMTP id GAA02840 for ; Thu, 30 Nov 2000 06:05:43 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id FAA02286 for snmpconf-outgoing; Thu, 30 Nov 2000 05:51:54 -0500 (EST) Message-Id: <200011301051.FAA25153@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-diffpolicy-03.txt Date: Thu, 30 Nov 2000 05:51:18 -0500 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : The DiffServ Policy MIB Author(s) : H. Hazewinkel, D. Partain Filename : draft-ietf-snmpconf-diffpolicy-03.txt Pages : 17 Date : 29-Nov-00 The MIB Module described in this document provides a conceptual layer between high-level 'network-wide' policy definitions that affect configuration of the differentiated services (DiffServ) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring DiffServ at a conceptually higher layer than that of the DiffServ Architecture MIB [DIFFSERVMIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-diffpolicy-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-diffpolicy-03.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: <20001129113927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-diffpolicy-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-diffpolicy-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129113927.I-D@ietf.org> --OtherAccess-- --NextPart--