home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / RDBMSMIB / 94FEB.MIN next >
Encoding:
Text File  |  1994-06-07  |  5.1 KB  |  131 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Bob Purvy/Oracle and David Brower/INGRES
  5.  
  6. Minutes of the Relational Database Management Systems MIB Working Group
  7. (RDBMSMIB)
  8.  
  9. The RDBMSMIB Working Group met on Tuesday, 8 February 1994 at
  10. Independence Technologies in Fremont, California.
  11.  
  12.  
  13. Agenda
  14.  
  15.    o Review Dave's latest MIB, and Marshall's suggested revisions (all
  16.      copied at the end of this message).
  17.  
  18.    o There are some large architectural issues here (also related to the
  19.      first outstanding issue below), so this may not be a short topic.
  20.  
  21.  
  22. Outstanding Issues
  23.  
  24.    o Server states and database states:  A technical contribution via
  25.      e-mail from Marc Sinykin and Jay Smith of Oracle is expected.
  26.  
  27.    o Network (or ``interprocess'') activity, now in the MIB as ``RPCs'':
  28.      Technical contributions are solicited on how to measure and
  29.      characterize this.
  30.  
  31.    o SQL compliance, other than ANSI SQL: A contribution via e-mail from
  32.      Mike Hartstein of Oracle is expected.
  33.  
  34.    o Size used/size allocated metrics for the database:  Is Dave's
  35.      `dbSize' definition acceptable for everyone?  Should we have ``size
  36.      used'' as well?
  37.  
  38.    o The meaning of ``sessions.''
  39.  
  40.    o Trap usage:  Given that traps are out of favor in the SNMP
  41.      community, should we keep the ones we have, in the form that we
  42.      have them now?
  43.  
  44.  
  45. Discussion
  46.  
  47. The meeting proceeded more or less according to plan, with excellent
  48. progress made:
  49.  
  50.  
  51.    o The prefix `rdbms' instead of `db' for all MIB objects was
  52.      accepted.  There was no consensus for broadening the goals of the
  53.      MIB to include non-relational databases, as was proposed in an
  54.      e-mail message.
  55.  
  56.    o States and the tabular organization of the MIB occupied about an
  57.      hour of discussion.  Stephen Campbell's proposal via e-mail to
  58.      delete the dbRelTable was discussed but did not receive support,
  59.      since describing the relationship between servers and databases is
  60.      considered valuable.  Particular decisions will be described
  61.      completely in the editor's new draft, but included:
  62.  
  63.       -  rdbmsRelState will consist of 5 values:  other, active,
  64.          available, unavailable, and restricted.  `restricted' is to
  65.          mean ``there may, but need not be a problem with the
  66.          database-server combination'' and `other' means ``the
  67.          presumption is that this does correspond to a problem state, to
  68.          be further defined by the vendor.''
  69.  
  70.       -  The state variable for databases is deleted.
  71.  
  72.      (The above two are to be considered `tentative' rather than
  73.      `consensus,' since they represent people agreeing that this is the
  74.      best we can do for now, and we need a chance to go off and think
  75.      about it.)
  76.  
  77.    o Marshall's proposal to move ``active'' variables to separate
  78.      tables, to be called rdbmsDbInfoTable and rdbmdSrvInfoTable) was
  79.      accepted.  The rule is that, for databases which are ``active,''
  80.      all variables must be present.  For ``inactive'' databases, there
  81.      is no such conformance statement.
  82.  
  83.    o SQL compliance level:  After some discussion, it was observed that
  84.      this does not help with fault, configuration, performance,
  85.      security, or accounting management, so why have it at all?  So it
  86.      was deleted.
  87.  
  88.    o Network traffic:  Dave Brower's proposal was accepted, but only for
  89.      the first four variables (i.e., the ``bytes sent'' and ``bytes
  90.      received'' were deleted).  Exact wording was kicked around a bit,
  91.      with the editor's draft to have the final word.
  92.  
  93.    o Size:  `Size used' was added as a new attribute in
  94.      rdbmsDbInfoTable.  It was noted that, for some vendors, `size used'
  95.      may always be the same as `size allocated'.  Units are to be the
  96.      same as `size allocated', and the `units' variable was changed to
  97.      an enumeration.
  98.  
  99.    o Sessions:  The chair brought it up, but no one could remember why
  100.      this was considered controversial.  If someone has an issue with
  101.      it, can they please state it?  The editor defined it to be a ``SQL
  102.      CONNECT'' statement that has not been ``disconnected.''
  103.  
  104.    o Traps:  Marshall explained the SNMP philosophy of traps.  We
  105.      removed the `security violation' trap.  The rdbmsStateChange trap
  106.      received a lot of discussion, with the end result being that we
  107.      decided that it will mean ``the database's state has changed to one
  108.      of less availability'' with no presumption that this represents an
  109.      unusual condition.  In other words, an implementation is free to
  110.      send a trap after the administrator deliberately shuts down the
  111.      database.
  112.  
  113.  
  114. Attendees
  115.  
  116. Janice Befu
  117. Gerard Berthet           gerard@indetech.com
  118. David Brower             daveb@ingres.com
  119. Barry Bruins             barryb@ngc.com
  120. Anthony Daniel           anthony@informix.com
  121. Craig De Noce            craigd@sybase.co
  122. Howard Dernehl           howard@ingres.com
  123. Mike Hartstein           mhartste@us.oracle.com
  124. David Morandi            davidm@redbrick.com
  125. Robert Purvy             bpurvy@us.oracle.com
  126. Roger Reinsh
  127. Marshall T. Rose         mrose.iesg@dbc.mtview.ca.us
  128. Marc Sinykin             msinykin@us.oracle.com
  129. Jay Smith                jaysmith@us.oracle.com
  130.  
  131.