home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2039.txt < prev    next >
Text File  |  1996-11-04  |  32KB  |  788 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                    C. Kalbfleisch
  8. Request for Comments: 2039                    OnRamp Technologies, Inc.
  9. Category: Informational                                   November 1996
  10.  
  11.  
  12.     Applicablity of Standards Track MIBs to Management of World Wide
  13.                               Web Servers
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. 1. Abstract
  22.  
  23.    This document was produced at the request of the Network Management
  24.    Area Director following the HTTP-MIB BOF at the 35th IETF meeting to
  25.    report on the applicability of the existing standards track MIBs to
  26.    management of WWW servers.
  27.  
  28.    Requirements for management of a World Wide Web (WWW) server are
  29.    presented.  The applicable existing standards track MIBs are then
  30.    examined.  Finally, an analysis of the additional groups of MIB
  31.    attributes that are needed to meet the requirements is presented.
  32.  
  33. Table of Contents
  34.  
  35.   1.     Abstract.................................................1
  36.   2.     Overview.................................................2
  37.   3.     Requirements.............................................3
  38.   3.1    Operational Model Requirements...........................3
  39.   3.1.1. Host specific and Application Monitoring.................3
  40.   3.1.2. Dependencies among applications..........................3
  41.   3.1.3. Error generation and reporting...........................3
  42.   3.1.4. Capacity planning........................................4
  43.   3.1.5. Log Digester.............................................4
  44.   3.2.   Service Model Requirements...............................4
  45.   3.2.1. Retrieval services.......................................4
  46.   3.2.2. Document information store -- managing documents.........4
  47.   3.2.3. Server configuration.....................................4
  48.   3.2.4. Server Control...........................................4
  49.   3.2.5. Quality of Service.......................................4
  50.   4.     Relationship to existing IETF efforts....................5
  51.   4.1.   MIB-II [2]...............................................5
  52.   4.2.   Host Resources MIB [3]...................................5
  53.   4.3.   Network Services Monitoring MIB [4]......................6
  54.   4.4.   Application MIB [5]......................................7
  55.  
  56.  
  57.  
  58. Kalbfleisch                  Informational                      [Page 1]
  59.  
  60. RFC 2039                     WWW Track MIBs                November 1996
  61.  
  62.  
  63.   5.     Summary of Existing Standards Track MIBs.................8
  64.   6.     Definition of additional attributes......................9
  65.   7.     Usage Scenarios.........................................11
  66.   8.     Conclusion..............................................11
  67.   9.     References..............................................13
  68.   10.    Acknowledgments.........................................13
  69.   11.    Further Information.....................................14
  70.   12.    Security Considerations.................................14
  71.   13.    Authors' Address........................................14
  72.  
  73. 2. Overview
  74.  
  75.    The World Wide Web (WWW) is a network of information, accessible via
  76.    a simple easy to use interface.  The information is often presented
  77.    in HyperText or multi-media.  The information is provided by servers
  78.    which are located all around the world.  The usability of the web
  79.    depends largely on the performance of these servers. WWW servers are
  80.    typically monitored through log files.  This becomes a difficult task
  81.    when a single organization is responsible for a number of servers.
  82.    Since many organizations currently use the Internet Standard SNMP to
  83.    manage their network devices, it is desirable to treat these WWW
  84.    servers as additional devices within this framework. This will allow
  85.    a single Network Management Station (NMS) to automate the management
  86.    of a number of WWW servers as well as the entire enterprise. Defining
  87.    a standard for this purpose allows a single management application to
  88.    manage a number of servers from a variety of vendors.  Additionally,
  89.    a formal definition of what has to be managed and how to manage it
  90.    tends to lead to integrated and improved performance and fault
  91.    management.
  92.  
  93.    Content providers are interested in the access statistics and
  94.    configuration of their sites. The content provider may be the same or
  95.    a different organization than the one that maintains the server as a
  96.    whole. It may be possible to realize the new paradigm of "Customer
  97.    Network Management" to provide this information to the content
  98.    provider. This means that there exists a distinct organization
  99.    different than the network operations center that is also interested
  100.    in the management information from a device. Customer network
  101.    management is desirable to allow each content provider on a server to
  102.    access information about his own documents independent of the rest.
  103.  
  104.    Various organizations may be interested in SNMP manageable WWW
  105.    clients and proxies as well. At this time, our focus is on WWW
  106.    servers. A natural extension to this work could be a framework for
  107.    managing WWW Clients and general information retrieval systems like
  108.    WWW proxies, NNTP, GOPHER, FTP and WAIS.  The focus of this document
  109.    remains the management of WWW servers.
  110.  
  111.  
  112.  
  113.  
  114. Kalbfleisch                  Informational                      [Page 2]
  115.  
  116. RFC 2039                     WWW Track MIBs                November 1996
  117.  
  118.  
  119. 3. Requirements
  120.  
  121.    WWW servers can be viewed from several perspectives when assigning
  122.    management responsibilities.  For the sake of discussion, these
  123.    perspectives are named the Operational Model and the Service Model.
  124.    The Operational Model views WWW servers as computers with hardware,
  125.    disk, OS and web server software.  This model represents the actual
  126.    resources that make up the machine so that it can be monitored from
  127.    the perspective of resource utilization.  The Service Model views the
  128.    WWW server as a black box that simply handles the responses to
  129.    requests from clients located on the web.
  130.  
  131.    The two models compliment each other while providing distinct
  132.    information about the server.  Members of the organization
  133.    responsible for the WWW server, may be interested in one and/or both
  134.    of the management models.  For this reason, the management
  135.    information should be scalable, for one or both models to be
  136.    implemented independent of the other.
  137.  
  138.    With this in mind, the requirements for WWW server management can are
  139.    summarized below by expanding upon those generated at the HTTP-MIB
  140.    BOF.
  141.  
  142. 3.1  Operational Model Requirements
  143.  
  144. 3.1.1. Host specific and Application Monitoring
  145.  
  146.    This includes monitoring the utilization of CPU, disk and network
  147.    capacity.
  148.  
  149. 3.1.2. Dependencies among applications.
  150.  
  151.    Some systems implement a number of services within a single piece of
  152.    code. Others use multiple pieces of code to implement the same set of
  153.    services. Because of this, dependencies develop among processes.
  154.    These dependencies become critical when a particular process needs to
  155.    be stopped, restarted or reconfigured. These dependencies need to be
  156.    defined within the management information so that management
  157.    applications can operate the systems correctly.
  158.  
  159. 3.1.3. Error generation and reporting
  160.  
  161.    The WWW server generally reports errors via logging facilities.  The
  162.    format of the log file is not well defined.  It is required that a
  163.    standard facility for error reporting be utilized.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Kalbfleisch                  Informational                      [Page 3]
  171.  
  172. RFC 2039                     WWW Track MIBs                November 1996
  173.  
  174.  
  175. 3.1.4. Capacity planning
  176.  
  177.    It is required to obtain statistics which can be used for capacity
  178.    planning purposes. This includes planning for increased network
  179.    bandwidth, computing power, disk space, number of concurrent server
  180.    threads, etc.
  181.  
  182. 3.1.5. Log Digester
  183.  
  184.    WWW servers generally report status information by data generated in
  185.    Common Log Format [1].  This information needs to be preserved as
  186.    attributes in a MIB to facilitate remote monitoring providing a
  187.    standard way to represent and retrieve the management information.
  188.  
  189. 3.2. Service Model Requirements
  190.  
  191. 3.2.1. Retrieval services
  192.  
  193.    Retrieval services are an abstract decoupling the information space
  194.    from the underlying transport mechanism.  The goal at this time is to
  195.    focus on the requirements for management of WWW servers. There may be
  196.    considerable overlap with other types of servers like (FTP, NNTP,
  197.    GOPHER and WAIS).  The term "retrieval services" is used here to
  198.    retain this abstraction.  It is required to get statistics about the
  199.    usage and performance of the retrieval services.
  200.  
  201. 3.2.2. Document information store -- managing documents.
  202.  
  203.    Information from a WWW server can be static (a file) or dynamic (the
  204.    output of some processing).  Management of these two types of
  205.    information sources range from maintaining access statistics and
  206.    access permissions to verifying the operational status of all
  207.    applications that provide the dynamic information.
  208.  
  209. 3.2.3. Server configuration.
  210.  
  211.    It is desirable to be able to centralize configuration management of
  212.    the servers within an enterprise.
  213.  
  214. 3.2.4. Server Control.
  215.  
  216.    WWW servers generally need to be controlled in regards to starting
  217.    and stopping them as well as rotating log files.
  218.  
  219. 3.2.5. Quality of Service
  220.  
  221.    Provide an indication of the quality of service the WWW server is
  222.    providing.
  223.  
  224.  
  225.  
  226. Kalbfleisch                  Informational                      [Page 4]
  227.  
  228. RFC 2039                     WWW Track MIBs                November 1996
  229.  
  230.  
  231. 4. Relationship to existing IETF efforts
  232.  
  233.    In general, a WWW server is made up of or depends upon the following
  234.    components:
  235.  
  236.       -a general purpose workstation running some operating system
  237.       -http server software to answers requests from the network
  238.       -various support routines like CGI programs or external
  239.        applications (like DBMS) used to access information
  240.       -a document store on one or more storage devices
  241.  
  242.    The health and performance of each of the above components is of
  243.    interest when managing a WWW server.
  244.  
  245.    There are a number of standards track MIB modules that are of
  246.    interest to the above list of items.  This list includes MIB-II [2],
  247.    Host Resources MIB [3], Network Service Monitoring MIB [4] and
  248.    Application MIB [5].
  249.  
  250.    This creates an impressive list of attributes to be implemented.  A
  251.    definition of various levels of management of a WWW server is desired
  252.    so that the implementor may scale his implementation in chunks which
  253.    may include various components of each section.  For instance, this
  254.    may allow customer network management without requiring the other
  255.    groups being implemented.
  256.  
  257. 4.1. MIB-II [2]
  258.  
  259.    MIB-II defines the managed objects which should be contained within
  260.    TCP/IP based devices.
  261.  
  262.    The WWW server should support the applicable portions of MIB-II.
  263.    This set probably includes, as a minimum, the following groups:
  264.    system, interfaces, udp, icmp, tcp and snmp.
  265.  
  266. 4.2. Host Resources MIB [3]
  267.  
  268.    This MIB defines a uniform set of objects useful for the management
  269.    of host computers independently of the operating system, network
  270.    services, or any software application.
  271.  
  272.    The MIB is structured as six groups; each specified as either
  273.    "mandatory" or "optional".  If ANY "optional" group of the MIB is
  274.    implemented, then ALL "mandatory" groups of the MIB must also be
  275.    implemented.  This may cause implementation problems for some
  276.    developers since many of these attributes require intimate knowledge
  277.    of the OS.
  278.  
  279.  
  280.  
  281.  
  282. Kalbfleisch                  Informational                      [Page 5]
  283.  
  284. RFC 2039                     WWW Track MIBs                November 1996
  285.  
  286.  
  287.    The groups defined by the MIB are:
  288.  
  289.       -System Group                           Mandatory
  290.       -Storage Group                          Mandatory
  291.       -Device Group                           Mandatory
  292.  
  293.                 -device types
  294.                 -device table
  295.                 -processor table
  296.                 -network table
  297.                 -printer table
  298.                 -disk storage table
  299.                 -partition table
  300.                 -file-system table
  301.                 -file-system types
  302.       -Running Software Group                 Optional
  303.       -Running Software Performance Group     Optional
  304.       -Installed Software Group               Optional
  305.  
  306.    The system group provides general status information about the host.
  307.    The storage and device groups define the information about the
  308.    configuration and status of the resources which compose the host.  It
  309.    defines the resources which make up a generic host system and how
  310.    they relate to each other.  Much of this information is useful for
  311.    managing various aspects of a WWW server, like the file system and
  312.    CPU utilization.  This information is useful for meeting the
  313.    operational requirements. Much of this information is however more
  314.    detailed than many WWW server managers require for service level
  315.    requirements.
  316.  
  317.    The remaining groups define software components which are installed
  318.    and/or running on the host.  Performance information is defined which
  319.    extends that defined for each running process.  Unfortunately, the
  320.    mapping between running software and installed software is difficult
  321.    since it is related by a foreign key (Product ID) which does not
  322.    appear to be required to exist in either table [6]. There is no
  323.    provision to represent a group of processes which together perform
  324.    some task (IE an application made up of multiple processes). The
  325.    Applications MIB WG plans to address these deficiencies.
  326.  
  327. 4.3. Network Services Monitoring MIB [4]
  328.  
  329.    This MIB is one of three documents produced by the MADMAN (Message
  330.    And Directory MANagement) Working group.  It defines a set of general
  331.    purpose attributes which would be appropriate for a range of
  332.    applications that provide network services.  This definition is from
  333.    the perspective of the service without considering the implementation
  334.    in terms of host computers or processes.  Attributes provide
  335.  
  336.  
  337.  
  338. Kalbfleisch                  Informational                      [Page 6]
  339.  
  340. RFC 2039                     WWW Track MIBs                November 1996
  341.  
  342.  
  343.    statistics and status on the in-bound and out-bound associations that
  344.    are currently active, and which have been active.
  345.  
  346.    This MIB is intended to be the minimum set of attributes common
  347.    across a number of Network Service Applications.  Additional
  348.    attributes are to be defined as necessary to manage specific network
  349.    service applications.  WWW servers clearly fall into the category of
  350.    network service applications.  All attributes in this MIB are
  351.    relevant to WWW servers.
  352.  
  353.    The MIB consists of two tables:
  354.  
  355.            -applTable                  Mandatory
  356.            -assocTable                 Optional
  357.  
  358.    The applTable describes applications that provide network services
  359.    and keeps statistics of the current number of active associations and
  360.    the total number of associations since application initialization.
  361.    The assocTable contains more detailed information about active
  362.    associations.
  363.  
  364.    The other two MIBs defined by MADMAN, MTA MIB [7] and DSA MIB [8],
  365.    are not relevant to the management of WWW services.  They do,
  366.    however, demonstrate how to extend the Network Services Monitoring
  367.    MIB for a specific set of applications.
  368.  
  369. 4.4. Application MIB [5]
  370.  
  371.    The Application MIB WG is defining two separate MIBs: the sysApplMib
  372.    and the applMib.  The first defines attributes that can be monitored
  373.    without instrumenting the applications.  The second will define
  374.    additional attributes requiring application instrumentation.
  375.  
  376.    The sysApplMIB allows for the description of applications as a
  377.    collection of executables, and files installed and executing on a
  378.    host computer. The objects support configuration, fault and
  379.    performance management of some of the basic attributes of application
  380.    software.
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Kalbfleisch                  Informational                      [Page 7]
  395.  
  396. RFC 2039                     WWW Track MIBs                November 1996
  397.  
  398.  
  399.    The groups defined in the sysApplMIB are:
  400.  
  401.            -System Application Installed Group     Mandatory
  402.                    -sysApplInstalledTable
  403.                    -sysApplCfgElmtTable
  404.  
  405.            -System Application Run Group           Mandatory
  406.                    -sysApplRunTable
  407.                    -SysApplPastRunTable
  408.                    -sysApplElmtRunTable
  409.                    -sysApplElmtPastRunTable
  410.  
  411.    The sysApplInstalledTable captures what applications are installed on
  412.    a particular host and the sysApplCfgElmtTable provides information
  413.    regarding the executables and non executable files which collectively
  414.    compose the application. The sysApplRunTable contains the application
  415.    instances which are currently running and the sysApplPastRunTable
  416.    contains a history about applications which have previously executed
  417.    on the host. The sysApplElmtRunTable contains the process instances
  418.    which are currently running and sysApplElmtPastRunTable contains a
  419.    history about processes which have previously executed on the host.
  420.  
  421.    It should be noted that two implementations of the same set of
  422.    network services may each define a different set of processes and
  423.    files within this MIB.  Ultimately enough management information is
  424.    needed so that these different implementations can at least be
  425.    managed similarly.
  426.  
  427.    WWW servers fall into the general category of application software.
  428.    Therefore the attributes of this MIB are applicable if the process
  429.    level detail is requested to meet the Operational Model requirements.
  430.  
  431.    The Application MIB WG is to resolve the problems described above
  432.    with the relationship between the running and installed software of
  433.    the Host Resources MIB.
  434.  
  435. 5. Summary of Existing Standards Track MIBs
  436.  
  437.    The existing MIBs are largely orthogonal as demonstrated by the
  438.    diagram below.  Host Resources relates network information to the
  439.    interfaces defined in MIB-II.  The system application MIB relates its
  440.    running element table to the equivalent entry in the Host Resources
  441.    running software table.
  442.  
  443.    It should be noted that the running software of the Host Resources
  444.    includes ALL software running on the host, while the running element
  445.    table of the system application MIB only includes "interesting"
  446.    processes of monitored applications.
  447.  
  448.  
  449.  
  450. Kalbfleisch                  Informational                      [Page 8]
  451.  
  452. RFC 2039                     WWW Track MIBs                November 1996
  453.  
  454.  
  455.    In the diagram below, "Other Services", "Application Specific MIBs"
  456.    and "Application MIB" represent work to be done or in progress.
  457.  
  458.                           +---------------+
  459.                           |  Application  |
  460.                           | Specific MIBs |
  461.                           +---------------+
  462.                                  |
  463.   +--------+ +---+ +---+  +---------------+
  464.   |Other   | |MTA| |DSA|  |  Application  |
  465.   |services| |MIB| |MIB|  |      MIB      |
  466.   +--------+ +---+ +---+  +---------------+
  467.       |        |     |           |
  468.   +--------------------+  +---------------+  +--------------+  +------+
  469.   |  Network Services  |  |    System     |  |Host Resources|  |MIB-II|
  470.   |   Monitoring MIB   |  |Application MIB|--|     MIB      |--|      |
  471.   +--------------------+  +---------------+  +--------------+  +------+
  472.  
  473.    The stack of MIBs above "Network Services Monitoring MIB" represent
  474.    monitoring from the Service Model.  The other stacks represent
  475.    monitoring from the Operational Model.  Neither of these stacks goes
  476.    to the level of specific detail for any application. The author is of
  477.    the opinion that HTTP or Web Server specific MIBs would exist at the
  478.    top of each stack to represent the service and implementation view of
  479.    the server respectively.  There should be a relationship between
  480.    these two perspectives defined so that the correlations between the
  481.    two perspectives is possible.  This relationship would be useful for
  482.    general application and service monitoring in addition to just web
  483.    servers.  However, it is not of specific interest to either the
  484.    MADMAN WG or the Application MIB WG. It is therefore suggested that
  485.    such a relationship is defined in a general case outside of either of
  486.    those groups that would be applicable for WWW servers as well as for
  487.    other application to service mappings.
  488.  
  489. 6. Definition of additional attributes
  490.  
  491.    The existing MIB attributes meet the Operational Model Requirement
  492.    for tracking information specific to a host.  Specifically, MIB-II,
  493.    Host Resources and the Applications MIB address these items. The
  494.    Network Services MIB addresses a portion of the service model
  495.    requirement for the decoupling of the information space from the
  496.    transport mechanism.
  497.  
  498.    Several sets of additional attributes are needed to meet the
  499.    remaining requirements. These additional attributes may be generally
  500.    applicable to other network information retrieval services (like FTP,
  501.    NNTP, GOPHER and WAIS) as well as client and proxy management.
  502.    Management of these services is not the scope of this document.
  503.  
  504.  
  505.  
  506. Kalbfleisch                  Informational                      [Page 9]
  507.  
  508. RFC 2039                     WWW Track MIBs                November 1996
  509.  
  510.  
  511.    These additional attributes can be classified as:
  512.  
  513.    1) Definition of relationship between the Network Services Monitoring
  514.       and Application MIBs.  This allows the functional organization of
  515.       the server to be known.  It allows the management application to
  516.       understand the effect of restarting specific processes on the
  517.       services provided.  This addresses the Operational Model
  518.       requirement to model dependencies between applications.
  519.  
  520.    2) Additions to generic Network Services Monitoring MIB. A draft [9]
  521.       has already been circulated due to the work of a mailing list and
  522.       a sample implementation.  These attributes list a summary at the
  523.       service level of the configuration and the health of the server.
  524.       From this, performance metrics can be observed.  In addition, the
  525.       health of the server in terms of data timeouts is known.  These
  526.       attributes address the requirement for Operational Model tracking
  527.       of specific activity and the requirement for Service Model
  528.       retrieval services.
  529.  
  530.    3) Document storage and access statistics are needed to address
  531.       service model requirements.
  532.  
  533.    4) Additions to Application MIB are required to address server
  534.       configuration requirements in the service model.
  535.  
  536.    5) Error and fault management attributes are required to address
  537.       requirements for tracking specific activity of the web server.
  538.  
  539.    6) Configuration and Control are items that may be able to be defined
  540.       in a general way within the applications MIB.  If not, a specific
  541.       definition would be required here.
  542.  
  543.    Of the items listed above, (1) is needed on a general basis.  The
  544.    others appear to the author as WWW server specific unless the scope
  545.    of the work is opened to WWW clients and proxies as well as other
  546.    services (like NNTP, FTP, GOPHER and WAIS).
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Kalbfleisch                  Informational                     [Page 10]
  563.  
  564. RFC 2039                     WWW Track MIBs                November 1996
  565.  
  566.  
  567. 7. Usage Scenarios
  568.  
  569.    The example scenario will be a single host computer which implements
  570.    WWW services using the "virtual domain" concept.  In this model, a
  571.    single host performs as the WWW server for one or more addresses.
  572.    For the purpose of example, we will specify that there are three
  573.    domains being serviced from this host whose WWW servers are:
  574.  
  575.            -www.a.com
  576.            -www.b.com
  577.            -www.c.com
  578.  
  579.    Some implementations may implement these services as one set of
  580.    processes that handle requests for each of the addresses.  Others may
  581.    implement these services as a set of processes for each address.
  582.    This means that the relationship defined between the Network Services
  583.    Monitoring MIB and Application MIB components of the management
  584.    information may vary between different implementations of the same
  585.    configuration.
  586.  
  587.    MIB-II and Host Resources would provide the information about the
  588.    host including the CPU, disk and network.  The Host Resource running
  589.    table provide information on the processes in the system.
  590.  
  591.    There would be an entry in the Network Services Monitoring applTable
  592.    for each virtual domain.  In addition, the assocTable shows which
  593.    connections are currently active.  An extension to the association
  594.    table would be helpful to provide information as to what is being
  595.    transmitted.
  596.  
  597.    The sysApplMib would have entries in its installed software tables
  598.    for the web server software and each "interesting" component.  This
  599.    should include the server binary, CGI programs, configuration files
  600.    and possibly the server log files.  Depending on the implementation
  601.    of the server, the processes for each domain may show up in the same
  602.    or different running software tables.
  603.  
  604.    Additional information as described in the previous section would
  605.    round out the management information that would be available for the
  606.    WWW server.
  607.  
  608. 8. Conclusion
  609.  
  610.    A number of currently defined attributes are useful for management of
  611.    a WWW server. Specifically, MIB-II and Host Resources should be
  612.    considered for monitoring the health of the machine in terms of host
  613.    and network configuration and capacity.  The Network Services
  614.    Monitoring MIB and the Application MIBs provide a general framework
  615.  
  616.  
  617.  
  618. Kalbfleisch                  Informational                     [Page 11]
  619.  
  620. RFC 2039                     WWW Track MIBs                November 1996
  621.  
  622.  
  623.    to represent the components of the WWW server from both a service and
  624.    implementation perspective.  The Network Services Monitoring MIB
  625.    suggests that extensions are necessary to cover specific network
  626.    application monitoring. A set of such attributes can be well defined
  627.    to provide status information of the WWW server.  The Application MIB
  628.    suggests similar extensions.  Some of these attributes may be generic
  629.    to all applications, and thus be implemented within the scope of the
  630.    applMib. It is the opinion of this author that there will still
  631.    remain specific instrumentation for WWW servers that can not, and
  632.    should not, be covered in the Network Services Monitoring and
  633.    Application MIBs.
  634.  
  635.    Since the Network Services Monitoring MIB and the Applications MIB
  636.    represent orthogonal efforts of management, it is desirable to define
  637.    the relationship between the two in a standard way.  This definition
  638.    is probably more than a simple pointer from one table to another.
  639.    Since it is outside the scope of either of those efforts, it is this
  640.    author's opinion that that definition could and should be addressed
  641.    within the scope of defining management of a specific application (IE
  642.    WWW servers). This defintion although defined for a particular
  643.    application, should be useful in a general way to describe the
  644.    relationship between the Network Services Monitoring MIB and the
  645.    Applications MIB.
  646.  
  647.    Additional attributes are needed in order to meet all of the
  648.    requirements specified in this document.  An IETF standard would
  649.    prevent independent developments of this effort in many enterprise
  650.    MIBs.  It also allows management applications to control servers from
  651.    multiple vendors.  It is likely that as the work in this area
  652.    progresses, the management information will be useful for other
  653.    Network Information Retrieval services (like FTP, GOPHER, WAIS and
  654.    NNTP) as well.
  655.  
  656.    Finally, the Operational Model and Service Model Requirements lead to
  657.    two main uses of the management information.  Design of the MIB
  658.    including the usage of the existing MIBs should allow one or the
  659.    other or both of these models to be implemented in a standard way.
  660.    This may be desirable depending specifically on the audience of the
  661.    data, the cost of instrumentation and the resources of the system.
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Kalbfleisch                  Informational                     [Page 12]
  675.  
  676. RFC 2039                     WWW Track MIBs                November 1996
  677.  
  678.  
  679. 9. References
  680.  
  681.  [1] Anonymous, "Logging in the W3C httpd",
  682.      http://www.w3.org/hypertext/WWW/Daemon/User/Config/Logging.html,
  683.      W3C, July 1995.
  684.  
  685.  [2] McCloghrie, K., and M. Rose, Editors, "Management Information
  686.      Base for Network Management of TCP/IP-based internets: MIB-
  687.      II", STD 17, RFC 1213, Hughes LAN Systems, Performance
  688.      Systems International, March 1991.
  689.  
  690.  [3] Grillo, P., and S. Waldbusser, "Host Resources MIB", RFC 1514,
  691.      Network Innovations, Intel Corporation, Carnegie Mellon
  692.      University, September 1993.
  693.  
  694.  [4] Kille, S., and N. Freed, "Network Services Monitoring MIB",
  695.      RFC 1565, ISODE Consortium, Innosoft, January 1994.
  696.  
  697.  [5] Saperia, J., C. Krupczak, R. Sturm, and J. Weinstock, "Definition
  698.      of Managed Objects for Applications", Work in Progress.
  699.  
  700.  [6] Krupczak, C. and S. Waldbusser, "Applicability of Host Resources
  701.      MIB to Application Management", Empire Technologies, Inc.,
  702.      International Network Services, October 1995.
  703.  
  704.  [7] Kille, S., and N. Freed, "Mail Monitoring MIB", RFC 1566, ISODE
  705.      Consortium, Innosoft, January 1994.
  706.  
  707.  [8] Mansfield, G., and S. Kille, "X.500 Directory Monitoring MIB",
  708.      RFC 1567, AIC Systems Laboratory, ISODE Consortium, January 1994.
  709.  
  710.  [9] Hazewinkel, H., E. van Hengstum, A. Pras, "Definitions of Managed
  711.      Objects for HTTP", Work in Progress.
  712.  
  713. 10. Acknowledgments
  714.  
  715.    This document was produced at the request of the Network Management
  716.    Area Director following the HTTP-MIB BOF at the 35th IETF meeting to
  717.    report on the applicability of the existing standards track MIBs to
  718.    management of WWW servers.
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Kalbfleisch                  Informational                     [Page 13]
  731.  
  732. RFC 2039                     WWW Track MIBs                November 1996
  733.  
  734.  
  735.    The author gratefully acknowledges the comments of the following
  736.    individuals:
  737.  
  738.             Ned Freed, ned@innosoft.com
  739.                 Innosoft, Inc.
  740.  
  741.             Harrie Hazewinkel, hazewink@cs.utwente.nl
  742.                 University of Twente
  743.  
  744.             Cheryl Krupczak, cheryl@empiretech.com
  745.                 Empire Technologies, Inc.
  746.  
  747.             Rui Meneses, rui.meneses@jrc.it
  748.                 Centre for Earth Observation
  749.  
  750.             Jon Saperia, saperia@bgs.com
  751.                 BGS Systems, Inc.
  752.  
  753.             Juergen Schoenwaelder, schoenw@cs.utwente.nl
  754.                 University of Twente
  755.  
  756.             Chris Wellens, chrisw@iwl.com
  757.                 InterWorking Labs, Inc.
  758.  
  759. 11. Further Information
  760.  
  761.    The current status of the HTTP-MIB standardization can be found on
  762.    the World Wide Web at <URL:http://http-mib.onramp.net/>.  An email
  763.    list is in operation for discussion of this topic.  To subscribe,
  764.    send email to "http-mib-request@onramp.net" with the message body of
  765.    "subscribe HTTP-MIB".
  766.  
  767. 12. Security Considerations
  768.  
  769.    Security issues are not discussed in this memo.
  770.  
  771. 13. Authors' Address
  772.  
  773.    Carl W. Kalbfleisch
  774.    OnRamp Technologies, Inc.
  775.    Email: cwk@onramp.net
  776.    1950 Stemmons Frwy
  777.    2026 INFOMART
  778.    Dallas, TX 75207, USA               Tel: (214) 672-7246
  779.    cwk@onramp.net                      Fax: (214) 672-7275
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Kalbfleisch                  Informational                     [Page 14]
  787.  
  788.