home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 91jul / snmpdir-minutes-91jul.txt < prev    next >
Text File  |  1993-02-17  |  24KB  |  545 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by James Davin/MIT
  6.  
  7. SNMP NM Directorate Minutes
  8.  
  9. Special Session
  10.  
  11. These Minutes record statements made during an open session convened at
  12. the IETF meeting in Atlanta.  These minutes are an accurate report of
  13. what was said as a concrete reference for future discussion; however, no
  14. statement reported here should be construed either as a consensus of
  15. those present or even as necessarily factually correct (in explicit
  16. content or in implicit assumptions).
  17.  
  18. Chuck Davin (MIT) called the meeting to order and reviewed the purpose
  19. of the session as it had been announced in mailing list postings:
  20.  
  21.  
  22. From: "James R. (Chuck) Davin" <jrd@ptt.lcs.mit.edu>
  23. To: snmp-wg@nisc.nyser.net
  24. Subject: SNMP Directorate Mtg at Atlanta
  25. Date: Wed, 17 Jul 91 20:06:56 -0400
  26. Sender: jrd
  27.  
  28.  
  29.  
  30. Agenda
  31.  
  32. The SNMP Network Management Directorate session scheduled for the
  33. Atlanta IETF meeting will have as its goal the identification of
  34. concerns about functional deficiencies in the SNMP network management
  35. framework.  The scope of the discussion will be lapses in the scope of
  36. extant management instrumentation and functional problems or
  37. deficiencies in the Internet SMI (RFC 1155; also RFC 1212) and the SNMP
  38. protocol (RFC 1157).
  39.  
  40.  
  41.    o Instrumentation Scope
  42.    o Structure of Management Information (RFC 1155; also RFC 1212)
  43.    o Simple Network Management Protocol (RFC 1157)
  44.  
  45.  
  46. To keep the session productively focused, discussion will not extend to
  47. any identification or description of potential solutions.
  48.  
  49. Participants are asked to have read relevant documents in advance of the
  50. session.
  51.  
  52. Davin took pains to emphasize that the purpose of this meeting was to
  53. identify perceptions of functional deficiencies in the internet-
  54. standard network management framework and that discussion of potential
  55. solutions was not in order.
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Davin also stated that this meeting was a tentative, exploratory step in
  64. a process whose future course remains unclear.  Regardless of the future
  65. course of any efforts to evolve the internet- standard network
  66. management framework, it would be useful even at the outset to begin to
  67. identify what problems might need addressing in any such future work.
  68. Davin reminded those present of the exceptional character of the meeting
  69. and that no one should draw any conclusions from this meeting about the
  70. content, process, venue, or schedule of any future work on the internet-
  71. standard network management framework.
  72.  
  73. After this introduction, the floor was opened, and a succession of
  74. speakers addressed the meeting to articulate one or more perceived
  75. problems with the internet-standard NM framework.
  76.  
  77. David Waitzman (BBN) identified the performance of SNMP in the retrieval
  78. of large amounts of tabular management information as being less than
  79. desirable.  He cited as an example the task of retrieving the columns of
  80. a routing table for purposes of comparing its contents to an
  81. administratively determined configuration.
  82.  
  83. Waitzman also stated that interoperability among SNMP systems may suffer
  84. owing to varying practice with respect to the creation and deletion of
  85. of MIB object instances.
  86.  
  87. Waitzman also stated that MIB objects with mandatory status that were
  88. not universally implementable posed problems of interoperability, fault
  89. diagnosis, and ill-defined conformance posture.
  90.  
  91. Waitzman also stated that it is difficult to map between the information
  92. models for OSI and SNMP network management.  He characterized this
  93. problem as one of increased difficulty for MIB implementors and
  94. attributed it to a lack of coordination among standards bodies.
  95.  
  96. Waitzman also stated that the level of granularity in SNMP authorization
  97. mechanisms was inadequate to realize certain policies.
  98.  
  99. Lynn Monsanto (Sun Microsystems Incorporated) stated that his customers
  100. want to have confidence that significant network events will be reliably
  101. reported to a management station.  He emphasized this point by noting a
  102. lack of defined MIBs for management stations.  He also cited an example
  103. environment in a brokerage house that requires a very low mean time to
  104. detect errors.
  105.  
  106. Monsanto stated that the framework was weak in its support for
  107. distributed atomic operations, e.g., to add a user account to multiple
  108. hosts but to back out of the operation under certain circumstances.
  109.  
  110. Monsanto also stated that the SNMP SMI makes units of measurement for
  111. various instrumented quantities ambiguous.  He pointed out that this
  112. makes mechanical interpretation of MIB objects by management stations
  113. difficult.  In this context, he also cited the difficulty in displaying
  114. a new, unknown MIB object at a management station.
  115.  
  116. Karl Auerbach (Sun Microsystems Incorporated) stated that the SNMP SMI
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124. does not afford support for representing large numbers.  He cited the
  125. example of the number of bytes transmitted on an Ethernet interface in
  126. this connection.  He also stated that the SNMP SMI was weak in its
  127. distinction between signed and unsigned quantities, offering as an
  128. example the difference between measurements of disk space and a bank
  129. account balance.
  130.  
  131. Auerbach also stated that it is difficult for a management station to
  132. know how to display a retrieved physical address quantity.  He said that
  133. this difficulty limits the range of network types that can be managed by
  134. SNMP.
  135.  
  136. Auerbach also stated that the SNMP error status values confuse network
  137. operators.  He cited the example of the readOnly status.
  138.  
  139. Auerbach also stated that the use of ASN.1 encodings in the SNMP imposed
  140. an excessive computational burden on agent systems and that this burden
  141. is compounded by the emerging SNMP security proposals.
  142.  
  143. Auerbach also stated that the atomic failure character of the SNMP Get
  144. operation complicates the implementation of management stations.
  145.  
  146. Auerbach also stated that ``holes in the MIB'' owing to unimplemented
  147. MIB objects or access control policies cause both a performance problem
  148. and an efficiency problem for the internet-standard network management
  149. framework.
  150.  
  151. Auerbach also stated that the retrieval of large amounts of tabular
  152. information via the SNMP was inefficient both in terms of bandwidth
  153. consumed and in packet processing overhead.  He cited as examples the
  154. need to retrieve log files, large routing tables, and core image dumps
  155. using the SNMP.
  156.  
  157. Auerbach also stated that the existence of MIB objects with optional
  158. status poses an interoperability problem.  He stated that such objects
  159. also pose the problem that important management information may not be
  160. present when it is needed.  He further cited in this connection the
  161. inefficiency of repolling when operations may fail owing to the absence
  162. of desired information.  Auerbach stated that he personally likes
  163. optional status MIB objects but that, in reality, vendors do not observe
  164. the MIB group as the unit of conformance.  In this context, he observed
  165. that a conceptual table in the MIB that currently comprised no
  166. conceptual rows was difficult to distinguish from a failure to implement
  167. the relevant MIB objects.
  168.  
  169. John Cook (Chipcom Corporation) stated that the framework may lack a
  170. consistent way within the SNMP framework by which agents may document
  171. what MIB objects they support.
  172.  
  173. Cook also identified a problem with the Ethernet MIB currently under
  174. discussion that it attempts to instrument both IEEE 802.3 and
  175. traditional Ethernet functionality.
  176.  
  177. Karl Auerbach stated that the feedback afforded by a SNMP Set operation
  178.  
  179.                                    3
  180.  
  181.  
  182.  
  183.  
  184.  
  185. is weak and the attendant ambiguity requires that SNMP Sets be done in
  186. the blind.  Thus, the results of a Set must be confirmed by a poll, and
  187. this requirement interferes with the need to perform management
  188. operations atomically.
  189.  
  190. Auerbach also stated that the implementation of management stations is
  191. complicated by the lack of uniform practice with respect to creation and
  192. deletion of MIB object instances.  In particular, the implementation of
  193. managers is complicated by lack of knowledge about what is required in
  194. the varbind list for SNMP Sets.
  195.  
  196. Auerbach also stated that semantic relationships that affect ranges of
  197. acceptable values for MIB objects are not well-represented in the
  198. internet- standard network management framework with the result that
  199. implementation of management stations is more complicated.  He cited the
  200. example that if an instance of the ifType MIB object has the value 5,
  201. then the value for the corresponding instance of the ifSpeed object can
  202. not be 10 Mb/s.  He also said that constraints of this sort can
  203. transcend the scope of individual conceptual tables.
  204.  
  205. Auerbach also stated that the lack of a MIB representation for maximum
  206. acceptable SNMP PDU sizes reduces the efficiency of management.
  207.  
  208. Fred Baker (ACC) stated that the failure to implement mandatory MIB
  209. objects hurts implementors of proxy agents that have made good faith
  210. efforts to conform to MIB standards.  Because existing standards are not
  211. clear on the conformance requirements for proxy agents, such agents may
  212. themselves be inappropriately judged as nonconformant when they proxy
  213. for a deficient agent.
  214.  
  215. John Cook stated that management stations need more information than is
  216. currently represented in the internet-standard network management
  217. framework in order to do a good job of managing the network.  He cited
  218. the lack of a common representation for individual objects and
  219. structures of those objects that is oriented to the needs of management
  220. stations.
  221.  
  222. Cook also stated that the framework may be lacking a way to distribute
  223. ``human information'' to management stations -- for example, useful
  224. human-readable text, or textual tags for enumerated values.
  225.  
  226. Karl Auerbach stated that the internet-standard framework can complicate
  227. the configuration of a management station:  constructing ``smart''
  228. management applications may be difficult because the framework lacks a
  229. dynamic, mechanical way of finding out what is in a managed device.
  230.  
  231. Auerbach also stated that textual ambiguities in the standard
  232. specifications degrades interoperability.  He cited as an example of
  233. this problem the phrase ``as if simultaneously.''
  234.  
  235. John Saperia (Digital Equipment Corporation) stated that in the existing
  236. framework it was difficult to associate information collected over time
  237. with MIB structures that may change over time.  He cited the example
  238. that, although statistics may be collected over time about several
  239.  
  240.                                    4
  241.  
  242.  
  243.  
  244.  
  245.  
  246. network interfaces, the representation of such interfaces in the MIB may
  247. itself change over time as the result of management operations.
  248.  
  249. David Waitzman stated that implementation of a management station is
  250. complicated by the possibility of receiving a reference to an
  251. unrecognized MIB object in the varbind list of a SNMP trap PDU. In this
  252. context, Waitzman noted a lack of any mechanism in the framework to
  253. obtain information on how to display an unknown MIB object.
  254.  
  255. Waitzman also stated that the representation of the IP routing table in
  256. MIB-2 does not support multiple routes to a single destination.
  257.  
  258. Karl Auerbach stated that the scope of ASN.1 syntax that is legal in
  259. Concise MIB expressions is not made clear in the relevant standards.
  260.  
  261. Bob Stewart (Xyplex, Incorporated) stated that the cost of agent
  262. implementation for MIB objects is a problem with the current framework.
  263. Stewart stated that limitations on what agents need to do is important
  264. and that too much is expected of managed agents.  He also stated that
  265. providing minimal management information in agents is a big job.
  266.  
  267. Karl Auerbach stated that interoperability suffers in the current
  268. framework owing to a lack of a common communication mechanism between
  269. ``head agents'' and ``subordinate agents.''
  270.  
  271. Anil Rijsinghani (Digital Equipment Corporation) stated that, because
  272. the IEEE allows individual objects to be optional, the translation of
  273. network management definitions from IEEE into the SNMP idiom is
  274. complicated.
  275.  
  276. Rijsinghani also stated that the framework lacks rules of thumb for
  277. translating IEEE conformance posture into the SNMP idiom.  (Marshall
  278. Rose of Dover Beach Consulting interjected a reference to Appendix A of
  279. RFC 1212 at this point in the proceedings.)
  280.  
  281. Rijsinghani also stated that the IETF process for developing SNMP
  282. standards produced a level of volatility that is incompatible with
  283. gaining essential implementation experience.
  284.  
  285. Karl Auerbach stated that the semantic context of a SNMP Set operation
  286. (particularly the relation of one MIB object to another) may be
  287. ambiguous in the current framework.  He cited the example of a MIB
  288. object whose semantics are ``open bomb bay doors'' and a MIB object
  289. whose semantics are ``drop bombs.''  He pointed out the importance of
  290. temporal sequencing in operations on these two objects.
  291.  
  292. Bob Stewart stated that the process by which MIBs are developed may be
  293. inconsistent in its discouraging of vendors against shipping
  294. experimental MIBs while at the same time enjoining vendors to experiment
  295. to benefit the community.  He stated that companies don't want to do
  296. experiments that don't ship in products but that companies will ship
  297. experiments and assume the risk that entails.  Stewart cited as a
  298. problem in the framework that the intended use of the experimental
  299. branch of the MIB namespace is not clearly articulated.
  300.  
  301.                                    5
  302.  
  303.  
  304.  
  305.  
  306.  
  307. Karl Auerbach stated that a problem with the current framework is its
  308. excessive use of polling.  He stated that a deficiency of the framework
  309. is the lack of a way to generate traps at the discretion of a manager,
  310. in order that knowledge about a serial scenario and its causal structure
  311. may be profitably applied.
  312.  
  313. David Perkins (Synoptics, Incorporated) stated that a weakness of the
  314. internet- standard network management framework was the difficulty in
  315. understanding it adequately to do an implementation.  He stated that the
  316. specifications could be clearer, particularly in the areas of proxy
  317. operations and the function of SNMP communities.
  318.  
  319. Perkins also stated that a problem with the current framework is that
  320. the heritage of RFC 1155 as a dual SMI for both CMOT and SNMP confuses
  321. some readers owing to now-extraneous provisions.
  322.  
  323. Perkins also stated that a problem with the framework is its lack of a
  324. MIB for instrumenting the function of the BOOTP protocol and the process
  325. of booting in general.  He cited in this context the special problems of
  326. devices that incorporate flash EPROM technologies.
  327.  
  328. Perkins also stated that the current framework suffered from a model of
  329. network interfaces (as captured in the ifTable of MIB 2) that is
  330. confusing and difficult to understand.
  331.  
  332. Perkins also stated that the current notation for defining MIBs makes it
  333. hard for people to learn how to write MIBs.  In this context, he stated
  334. that the Concise MIB notation should be even more concise.  He also said
  335. that the framework lacked notational support for capturing of defined
  336. object identifiers by management stations.
  337.  
  338. Lynn Monsanto stated that interoperability suffers because the framework
  339. lacks support for management stations to interact easily with new or
  340. unfamiliar devices.  He cited the example of the new class of devices
  341. that implement the RMON MIB. He stated that the framework comprises no
  342. algorithms or mechanical notations for communicating the complex
  343. semantics of such MIBs to the management station.
  344.  
  345. Monsanto also stated that the framework may engender confusion among its
  346. users because the notation for building instance identifiers may be
  347. confusing, particularly for ``messy'' tabular constructs.
  348.  
  349. Karen Robertson (Concord Communications) stated that interoperability
  350. suffers owing to the lack of a consistent mechanism for configuring and
  351. using SNMP proxy.
  352.  
  353. Robertson also stated that the effectiveness of the framework in certain
  354. contexts may be compromised by the lack of a common mechanism to recover
  355. from timeouts.  She cited a problem raised in the Internet Accounting
  356. Working Group that concerned the loss of valuable information when the
  357. specified polling interval may be too short.
  358.  
  359. Robertson also stated that the framework makes the definition of new MIB
  360. specifications difficult owing to the lack of provision for defining
  361.  
  362.                                    6
  363.  
  364.  
  365.  
  366.  
  367.  
  368. ASN.1 subtypes from existing SMI types.  She cited the example of
  369. subrange types defined from the existing Guage type.
  370.  
  371. Cheryl Krupzak (herself) stated that interoperability and efficiency
  372. suffer for want of a common mechanism for supporting multiple SNMP
  373. agents on the same platform.
  374.  
  375. Krupzak also stated that interoperability and efficiency suffer from
  376. variations in practice regarding constraints on the minimal set of
  377. varbinds required in a SNMP Set PDU that is to instantiate a conceptual
  378. row in the MIB.
  379.  
  380. Krupzak also stated that interoperability and efficiency suffer for want
  381. of a common strategy for marking the deletion of conceptual rows from
  382. the MIB.
  383.  
  384. David Waitzman stated that the framework may be confusing to
  385. implementors in the conventions surrounding the SNMP Trap PDU. Waitzman
  386. cited the names of the fields in the Trap PDU, the semantics of trap
  387. types, and the operation of trap mechanisms in general as possible
  388. points of confusion among implementors.
  389.  
  390. Keith McCloghrie (Hughes LAN Systems) stated that a weakness of the
  391. current framework was that it did not facilitate development of
  392. management applications because current MIB conformance postures admit
  393. too much optionality and assure too little commonality in what MIB
  394. objects are actually available for applications to use.
  395.  
  396. McCloghrie stated that the current framework does not foster
  397. interoperability or facilitate management station implementation because
  398. it lacks a common notation for documenting degrees of conformance by an
  399. implementation.  He cited the example of an agent that implements a
  400. subset of MIB 2 and observed that there is no common way of documenting
  401. that subset.
  402.  
  403. McCloghrie also stated that the framework was limited in the range of
  404. MIBs it could generate owing to the lack of a way to define structures
  405. of traditional MIB objects that need not be manipulated individually.
  406.  
  407. Karl Auerbach stated that interoperability and global management suffer
  408. owing to the lack of a tough requirement on the out-of-the-box state of
  409. every device.  He cited the need to characterize new or unfamiliar
  410. devices and stated the desirability of requiring that the system group
  411. of MIB 2 be required to be available for query on every device.
  412.  
  413. Frank Kastenholz (Clearpoint Research) that the use of SNMP management
  414. in non-IP networks may suffer owing to the inclusion of a NetworkAddress
  415. value in the Trap PDU.
  416.  
  417. Bob Stewart stated that a concern for agent implementations was that the
  418. framework did not explicitly provide for transient MIB objects
  419. exclusively to support effective use of varbind lists in Trap messages.
  420. He observed that although the contents of a Trap varbind list is
  421. properly derived from MIB objects, the cost entailed by making such
  422.  
  423.                                    7
  424.  
  425.  
  426.  
  427.  
  428.  
  429. objects constantly available may not be justified in some cases.
  430.  
  431. Frank Kastenholz stated that the implementation of mangement stations is
  432. complicated by the lack of a common mechanism for automatic discovery of
  433. network devices.
  434.  
  435. Jeff Case (University of Tennessee, Knoxville, on behalf of Unni
  436. Warrier, not present) stated that effective management suffered for want
  437. of more intensive transport mechanisms that provide reliable
  438. communication.
  439.  
  440. Bob Stewart stated that the range of widely deployed SNMP configurations
  441. may be limited by the lack of explicit statement in the standards that a
  442. single-system may realize both agent and manager roles.
  443.  
  444. Mark Kepke (Hewlett-Packard) stated that a weakness of the current
  445. framework is the difficulty experienced by vendors in developing private
  446. MIB specifications.
  447.  
  448. Kepke also stated that interoperability may suffer from the want of a
  449. common mechanism for configuring the destinations of Trap PDUs.
  450.  
  451. Kepke also stated that interoperability may suffer owing to confusion
  452. about the use of DEFVAL clauses and their role in object instantiation.
  453.  
  454. Kepke also stated that implementation of management stations was
  455. complicated by the lack of a common notation or mechanism for
  456. correlating semantically related constructs in the MIB. He cited the
  457. example of exploiting the analogous structure and content of the ifTable
  458. and the various tables of the Ethernet MIB.
  459.  
  460. Frank Kastenholz stated that the development of standard MIB
  461. specifications may be impeded by confusion about IAB policy and
  462. procedures for MIB acceptance.
  463.  
  464. Jeff Case (on behalf of Unni Warrier, not present) stated that the
  465. efficiency of the internet- standard network management framework
  466. suffers from the use of ASN.1 encoding and that, accordingly, a new
  467. transfer syntax is desirable.
  468.  
  469. John Cook stated that implementation of the SNMP is complicated by its
  470. use of special security mechanisms and that implementation would be
  471. facilitated by the use of a common authentication technology (CAT) in
  472. SNMP.
  473.  
  474. David Waitzman stated that the effectiveness of the framework may suffer
  475. for want of a LSSR or SSSR mechanism for use in the transmission of Trap
  476. PDUs.
  477.  
  478. Jeff Case (on behalf of Unni Warrier, not present) stated that a
  479. weakness of the framework is its disregard for international standards
  480. and that compatibility with CMIP should be an important goal for the
  481. future.
  482.  
  483.  
  484.                                    8
  485.  
  486.  
  487.  
  488.  
  489.  
  490. At this point, Chuck Davin adjourned the session, as the time allotted
  491. for the meeting had elapsed.
  492.  
  493. Attendees
  494.  
  495. Karl Auerbach            karl@eng.sun.com
  496. James Barnes             barnes@xylogics.com
  497. Steve Bostock            steveb@novell.com
  498. John Burruss             jburruss@wellfleet.com
  499. Jeffrey Case             case@cs.utk.edu
  500. John Cook                cook@chipcom.com
  501. Kurt Dobbins             dobbins@ctron.com
  502. Shari Galitzer           shari@gateway.mitre.org
  503. Shawn Gallagher          gallagher@quiver.enet.dec.com
  504. Phillip Hasse            phasse@honchuca-emh8.army.mil
  505. Mark Hoerth              mark_hoerth@hp0400.desk.hp.com
  506. Ron Jacoby               rj@sgi.com
  507. Ken Jones                konkord!ksj@uunet.uu.net
  508. Frank Kastenholz         kasten@europa.clearpoint.com
  509. Manu Kaycee              kaycee@ctron.com
  510. Mark Kepke               mak@cnd.hp.com
  511. Kenneth Key              key@cs.utk.edu
  512. Christopher Kolb         kolb@psi.com
  513. Bobby Krupczak           rdk@cc.gatech.edu
  514. Cheryl Krupczak          cheryl@cc.gatech.edu
  515. heryl Krupczak           cheryl@cc.gatech.edu
  516. Tim Lee-Thorp            ngc!tim@uunet.uu.net
  517. Keith McCloghrie         kzm@hls.com
  518. Robert Meierhofer        robert@cnt.mn.org
  519. Lynn Monsanto            monsanto@sun.com
  520. David Perkins            dperkins@synoptics.com
  521. Anil Rijsinghani         anil@levers.enet.dec.com
  522. Michael Ritter           mwritter@applelink.apple.com
  523. Kary Robertson           kr@concord.com
  524. Marshall Rose            mrose@dbc.mtview.ca.us
  525. Jonathan Saperia         saperia@tcpjon.enet.dec.com
  526. Mark Schaefer            schaefer@davidsys.com
  527. John Seligson            johns@ultra.com
  528. Timon Sloane             peernet!timon@uunet.uu.net
  529. Lance Sprung             sprung@sys.smc.com
  530. Bob Stewart              rlstewart@eng.xyplex.com
  531. Bruce Taber              taber@interlan.com
  532. Dean Throop              throop@dg-rtp.dg.com
  533. Maurice Turcotte         dnmrt@rm1.uucp
  534. David Waitzman           djw@bbn.com
  535. Steven Waldbusser        waldbusser@andrew.cmu.edu
  536. Drew Wansley             dwansley@ccgate.ColumbiaSC.NCR.COM
  537. Preston Wilson           preston@i88.isc.com
  538. Wengyik Yeong            yeongw@psi.com
  539. Joseph Zur               fibrontics!zur@uunet.uu.net
  540. Peter de Vries           peter@wco.ftp.com
  541.  
  542.  
  543.  
  544.                                    9
  545.