CURRENT_MEETING_REPORT_ Reported by Bob Purvy/Oracle and David Brower/INGRES Minutes of the Relational Database Management Systems MIB Working Group (RDBMSMIB) These are the minutes of the open meetings of the RDBMSMIB Working Group at the 29th IETF meeting in Seattle, Washington on March 29 and 30, 1994. Please send comments to the working group mailing list, rdbmsmib@indetech.com. Introduction The working group held three meetings in Seattle, Tuesday afternoon, and Wednesday morning and afternoon. Tuesday's meeting was a general review of the MIB as it existed prior to Seattle. The Wednesday morning session was devoted to Tony Daniel's/Informix's configuration parameter proposal, one more pass over existing objects, and a discussion of conformance groups. The afternoon was spent considering Tony's proposal for storage hierarchy discovery and statistics. Tuesday Afternoon A general walk-through of the MIB was done. Bob Natale suggested that each vendor's private MIB have some sort of direct tie-in to the public MIB. After some discussion, he decided to withdraw the request for more study. The OutofSpace trap: It was suggested that you could have a way, through the MIB, of setting a hysteresis threshold, so that the network does not get flooded with traps once the database runs out of space. Finally, we decided just to add language to the MIB suggesting that the implementor just not allow that. The StateChange trap: Language will be added to clarify that the variable returned with the trap is the new state. A writeable variable was suggested whereby the database could be shut down. There was also a proposal to add other settable variables, so the RDBMS could be controlled as well as monitored. It was eventually decided to leave this for the second version of the public MIB. It was proposed that RMON-like tables be added to the MIB (histograms, etc.). It was also proposed that a ``time of highwater sessions'' variable be added, so that you could tell when you almost ran out of configured sessions. This was discussed at length, with no one violently opposed, but finally it was pointed out that there are already mechanisms, in RMON and the M2M MIB, to accomplish some of what was wanted. Also, if you are polling the database even as seldom as every half hour, you would still have a good idea when it happened. So this was not adopted. The ever-popular topic of associations was brought up. Many at IBM do not like the current definition, since it does not distinguish between ``local'' and ``remote'' connections. Furthermore, they have both SQL and DRDA connections. It was observed that many vendors have no way of telling local and remote apart, since the underlying software hides that information. Finally it was decided that language would be added to the MIB to broaden the definition of association. Wednesday Morning I. Parameters Tony Daniels presented his proposal for configuration parameters. All vendors had some sort of parameters, and their visibility through the standard MIB would be useful for the following purposes: 1. Collecting data for a trouble ticket 2. Revealing changes in configurations 3. Enabling table driven interpretation in network management stations Those present agreed strongly that (1) and (2) were useful and important, and we should pursue parameter visibility. There was weaker support of (3) on the grounds that it called for more powerful NMS applications than might be present. There was considerable discussion about the semantics of the value-carrying object. The proposal had a very loose definition that no one was very happy with. There seemed to be four possible semantics: 1. The value at server startup 2. The current value 3. The value the administrator would like the current to be 4. The value the administrator would like at next startup Those present strongly preferred that the value field here be the current value. We then discussed what to do about things for which the current value might not be obtainable in an RDBMS product, and concluded it should not make the value visible at all. This led us to consider whether we should have two objects, the startup config value and the current. This was unclear, and we left with the sense that only current need exist in this version of the MIB. Since the value was current, we suggested the names be changed to reflect a parameter (rather than configuration) table, with a current value object. This will admit extension of configuration and desired value objects at a later time. We wondered what to do about global parameters, common across all servers, and decided we should just duplicate the value in all servers. We then discussed what to do about multi-valued parameters, for instance an ``IsDBA'' objects that would have a comma separated list of users who had a DBA privilege. Some thought there should not be rows in the table with duplicate names and different values. There was also a thought that a display string might not be big enough to hold all enumerated list values. This would require multiple rows per object, but this leads to questions of ordering. This still seems to be an open question. Marc Sinykin, Tony Daniels, and Dave Brower were named to a subcommittee to try to resolve this, since it seems like a reasonable solution should be doable. They will report back to the group when they have a proposal. Value objects should have writable max-access, and read-only min-access in the conformance clauses. The name objects should continue to be strings instead of OIDs, as they are more efficient. II. Object Review (A) We noted that the RFC 1565 Application MIB wording seemed to suggest that it not be used to support things that were not network services (i.e., services local to a host and not visible on the network). Marshall Rose said that was not the intent of that document, that the wording would need to be revised, that he would take care of it, and we should not be further concerned. (B) Uncommitted transactions had been noted as controversial, and we discussed what it meant. Was the value meaningful? Was it painful to determine? We concluded that it was useful to sample for trends, but probably not meaningful as an instantaneous value. We then wondered why we did not have the first order statistics from which this could be determined: - update transactions started - update transactions completed David Meldrum volunteered to float a proposal on the list for these values. (C) People were confused by the distinction between requests handled/made and sends/receives. We considered the example of a `select' statement that returned one row (1 receive, 1 request handled, 1 send) and one that returned a million rows (1 receive, 1 handled, 1,000,000 sends). This made sense, and will be included in the MIB documentation. (D) Outbound associations seemed so product specific that it was useless. It had been included for symmetry with Inbound associations in the ApplMib. We will remove it, though this causes some conformance problems (see below). (E) The out of space trap should pass the out of space value, rather than just the server. This will also pass the server as its index value, and is more useful. (F) Requests made seemed as product-specific as outbound associations. Related objects will be removed. III. Conformance Groups (A) We need to split the MIB into (at least) two groups, one containing most objects, and another containing the optional trap related things. We were not clear whether the out of spaces count should be in the trap group or the base group. (B) There was discussion whether we should split the main objects into a ``base'' group and the statistics in the Info tables into an optional ``info'' group. The vendors present wondered if this would allow separate packaging and pricing. The users booed and hissed, and insisted that such a consideration had never been raised at an IETF before, harrumph! Several management tools vendors asked that we not have any more conformance groups than absolutely necessary, since it complicates their lives enormously and is one of the reasons for OSI's lack of success. Bob Purvey feels that the group is not going to do this. (C) The removal of our Outbound association objects creates problems with conformance to the RFC 1565 Application MIB. It insists we keep track of outbound associations, and if we do not have any, what should we do? Marshall Rose effectively said again, ``don't worry, I'll take care of it.'' Wednesday Afternoon I. Storage Hierarchy and Related Statistics Tony Daniels presented his storage hierarchy and statistics proposal, which prompted much discussion. The essence of his scheme is to provide meta-data allowing description of many different storage relationships, and then allow arbitrary statistics gathering as in the Parameter table. This was interesting to those present, but there was very little support for including it in the current MIB for a number of reasons. First, it looked like it would take a long time to get it into acceptable shape, and no one wanted to push out the completion dates for this scheme. Second, it seemed counter to the ``known object'' philosophy of SNMP. It would place a tremendous burden on the NMS to decipher the meta-data and do the right thing, and this did not seem like a good thing to require. There was head-nodding that we should consider more objects than had currently been proposed, but without dragging in the meta-data approach. So, we decided that the ``last call for new objects'' made before the meeting would be considered a ``next to last call,'' and that we would actively seek to discuss critical things that seemed missing. II. Brainstorm Session for Grossly Missing Objects A list of items were brainstormed that seemed important, but which were currently missing. Discussion of these are encouraged on the list. It is unclear what some of these mean in the broad sense, and concrete proposals are needed. o Cache hits/misses/attempts o Table overflows o Table size o Lock waits o Buffer overflow o Log space use o Error message log o Index ``readaheads'' o Time of last full/partial backup o I/O errors o xact force aborts o Lock overflows o Security violations o Pages per disk I/O o Schema change o SQL statements (distinct from requests handled?) o SQL connects (distinct from inbound association count?) Some of these will have scoping problems. We now only admit to having servers and databases, and some statistics might belong to larger or smaller entities. We do not know if we should create new tables for these other entities, or shoe-horn objects into the database or server info tables. Attendees David Arneson arneson@ctron.com Bashir Ashrafi bashraf@chipcom.com Robert Austein sra@epilogue.com Virinder Batra batra@vnet.ibm.com Gerard Berthet gerard@indetech.com David Brower daveb@ingres.com Jeff Case case@snmp.com Bobby Clay clay@pscni.nasa.gov Anthony Daniel anthony@informix.com Louis Fernandez lff@sequent.com Shawn Gillam shawn@timonware.com Christine Gressley gressley@uiuc.edu Walter Guilarte guilarte@wg.com Mike Holloway mikeh@newbridge.com Mark Kepke mak@aiinet.com Cheryl Krupczak cheryl@empiretech.com Damien Lindauer damienl@microsof.com Dwayne McIntosh mcintosh@sleepy.ns.us.boeing.com David Meldrum meldrum@sybase.com Scott Mordock mordock@cisco.com Robert Natale natale@acec.com Brian O'Keefe bok@cnd.hp.com Andrew Pearson pearson@snmp.com Peter Phillips pphillip@cs.ubc.ca Randy Presuhn randy@peer.com Robert Purvy bpurvy@us.oracle.com Dan Romascanu dan@lannet.com Marshall T. Rose mrose.iesg@dbc.mtview.ca.us Blair Sanders bbs@sanders.itg.ti.com Jon Saperia saperia@zko.dec.com Michael Scanlon scanlon@ftp.com Marc Sinykin msinykin@us.oracle.com Jay Smith jaysmith@us.oracle.com Suzanne Smith smith@es.net Michael Sorsen c02420MS@wuvmd.wustl.edu Dick Wallace dick@concord.com David Walters walters@wg.com Bert Wijnen wijnen@vnet.ibm.com Stan Wong swong@vnet.ibm.com