idnits 2.17.1 draft-kalbfleisch-www-track-mibs-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 1996) is 10182 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1514 (ref. '3') (Obsoleted by RFC 2790) ** Obsolete normative reference: RFC 1565 (ref. '4') (Obsoleted by RFC 2248) == Outdated reference: A later version (-08) exists of draft-ietf-applmib-sysapplmib-02 -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1566 (ref. '7') (Obsoleted by RFC 2249, RFC 2789) ** Obsolete normative reference: RFC 1567 (ref. '8') (Obsoleted by RFC 2605) -- Possible downref: Normative reference to a draft: ref. '9' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT WWW Track MIBs June 9, 1996 3 Applicability of Standards Track MIBs to 4 Management of World Wide Web Servers 6 8 Carl W. Kalbfleisch 9 OnRamp Technologies, Inc. 10 cwk@onramp.net 12 June, 9 1996 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet- 29 Drafts Shadow Directories on ftp.is.co.za (Africa), 30 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 31 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 33 1. Abstract 35 This document was produced at the request of the Network Management 36 Area Director following the HTTP-MIB BOF at the 35th IETF meeting 37 to report on the applicability of the existing standards track 38 MIBs to management of WWW servers. 40 Requirements for management of a World Wide Web (WWW) server are 41 presented. The applicable existing standards track MIBs are then 42 examined. Finally, an analysis of the additional groups of MIB 43 attributes that are needed to meet the requirements is presented. 45 2. Overview 47 The World Wide Web (WWW) is a network of information, accessible 48 via a simple easy to use interface. The information is often 49 presented in HyperText or multi-media. The information is 50 provided by servers which are located all around the world. 51 The usability of the web depends largely on the performance of 52 these servers. WWW servers are typically monitored through log files. 53 This becomes a difficult task when a single organization is 54 responsible for a number of servers. Since many organizations 55 currently use the Internet Standard SNMP to manage their network 56 devices, it is desirable to treat these WWW servers as additional 57 devices within this framework. This will allow a single Network 58 Management Station (NMS) to automate the management of a number of 59 WWW servers as well as the entire enterprise. Defining a standard for 60 this purpose allows a single management application to manage a 61 number of servers from a variety of vendors. Additionally, a formal 62 definition of what has to be managed and how to manage it tends to 63 lead to integrated and improved performance and fault management. 65 Content providers are interested in the access statistics and 66 configuration of their sites. The content provider may be the same or 67 a different organization than the one that maintains the server as a 68 whole. It may be possible to realize the new paradigm of "Customer 69 Network Management" to provide this information to the content 70 provider. This means that there exists a distinct organization 71 different than the network operations center that is also interested 72 in the management information from a device. Customer network 73 management is desirable to allow each content provider on a server 74 to access information about his own documents independent of the 75 rest. 77 Various organizations may be interested in SNMP manageable WWW 78 clients and proxies as well. At this time, our focus is on WWW 79 servers. A natural extension to this work could be a framework for 80 managing WWW Clients and general information retrieval systems 81 like WWW proxies, NNTP, GOPHER, FTP and WAIS. The focus of this 82 document remains the management of WWW servers. 84 3. Requirements 86 WWW servers can be viewed from several perspectives when assigning 87 management responsibilities. For the sake of discussion, these 88 perspectives are named the Operational Model and the Service Model. 89 The Operational Model views WWW servers as computers with hardware, 90 disk, OS and web server software. This model represents the actual 91 resources that make up the machine so that it can be monitored from 92 the perspective of resource utilization. The Service Model views the 93 WWW server as a black box that simply handles the responses to 94 requests from clients located on the web. 96 The two models compliment each other while providing distinct 97 information about the server. Members of the organization 98 responsible for the WWW server, may be interested in one and/or 99 both of the management models. For this reason, the management 100 information should be scalable, for one or both models to be 101 implemented independent of the other. 103 With this in mind, the requirements for WWW server management 104 can are summarized below by expanding upon those generated at the 105 HTTP-MIB BOF. 107 3.1 Operational Model Requirements 109 3.1.1. Host specific and Application Monitoring 111 This includes monitoring the utilization of CPU, disk and network 112 capacity. 114 3.1.2. Dependencies among applications. 116 Some systems implement a number of services within a single piece of 117 code. Others use multiple pieces of code to implement the same set of 118 services. Because of this, dependencies develop among processes. 119 These dependencies become critical when a particular process needs to 120 be stopped, restarted or reconfigured. These dependencies need to be 121 defined within the management information so that management 122 applications can operate the systems correctly. 124 3.1.3. Error generation and reporting 126 The WWW server generally reports errors via logging facilities. The 127 format of the log file is not well defined. It is required that a 128 standard facility for error reporting be utilized. 130 3.1.4. Capacity planning 132 It is required to obtain statistics which can be used for capacity 133 planning purposes. This includes planning for increased network 134 bandwidth, computing power, disk space, number of concurrent server 135 threads, etc. 137 3.1.5. Log Digester 139 WWW servers generally report status information by data generated in 140 Common Log Format [1]. This information needs to be preserved as 141 attributes in a MIB to facilitate remote monitoring providing a 142 standard way to represent and retrieve the management information. 144 3.2. Service Model Requirements 146 3.2.1. Retrieval services 148 Retrieval services are an abstract decoupling the information space 149 from the underlying transport mechanism. The goal at this time is 150 to focus on the requirements for management of WWW servers. There 151 may be considerable overlap with other types of servers like (FTP, 152 NNTP, GOPHER and WAIS). The term "retrieval services" is used here 153 to retain this abstraction. It is required to get statistics about 154 the usage and performance of the retrieval services. 156 3.2.2. Document information store -- managing documents. 158 Information from a WWW server can be static (a file) or dynamic 159 (the output of some processing). Management of these two types 160 of information sources range from maintaining access statistics 161 and access permissions to verifying the operational status of all 162 applications that provide the dynamic information. 164 3.2.3. Server configuration. 166 It is desirable to be able to centralize configuration management of 167 the servers within an enterprise. 169 3.2.4. Server Control. 171 WWW servers generally need to be controlled in regards to starting 172 and stopping them as well as rotating log files. 174 3.2.5. Quality of Service 176 Provide an indication of the quality of service the WWW server 177 is providing. 179 4. Relationship to existing IETF efforts 181 In general, a WWW server is made up of or depends upon the following 182 components: 184 -a general purpose workstation running some operating system 185 -http server software to answers requests from the network 186 -various support routines like CGI programs or external 187 applications (like DBMS) used to access information 188 -a document store on one or more storage devices 190 The health and performance of each of the above components is of 191 interest when managing a WWW server. 193 There are a number of standards track MIB modules that are of 194 interest to the above list of items. This list includes MIB-II [2], 195 Host Resources MIB [3], Network Service Monitoring MIB [4] and 196 Application MIB [5]. 198 This creates an impressive list of attributes to be implemented. A 199 definition of various levels of management of a WWW server is 200 desired so that the implementor may scale his implementation in 201 chunks which may include various components of each section. For 202 instance, this may allow customer network management without 203 requiring the other groups being implemented. 205 4.1. MIB-II [2] 207 MIB-II defines the managed objects which should be contained within 208 TCP/IP based devices. 210 The WWW server should support the applicable portions of MIB-II. 211 This set probably includes, as a minimum, the following groups: 212 system, interfaces, udp, icmp, tcp and snmp. 214 4.2. Host Resources MIB [3] 216 This MIB defines a uniform set of objects useful for the management 217 of host computers independently of the operating system, network 218 services, or any software application. 220 The MIB is structured as six groups; each specified as either 221 "mandatory" or "optional". If ANY "optional" group of the MIB is 222 implemented, then ALL "mandatory" groups of the MIB must also be 223 implemented. This may cause implementation problems for some 224 developers since many of these attributes require intimate knowledge 225 of the OS. 227 The groups defined by the MIB are: 229 -System Group Mandatory 230 -Storage Group Mandatory 231 -Device Group Mandatory 232 -device types 233 -device table 234 -processor table 235 -network table 236 -printer table 237 -disk storage table 238 -partition table 239 -file-system table 240 -file-system types 241 -Running Software Group Optional 242 -Running Software Performance Group Optional 243 -Installed Software Group Optional 245 The system group provides general status information about the host. 246 The storage and device groups define the information about the 247 configuration and status of the resources which compose the host. 248 It defines the resources which make up a generic host system and how 249 they relate to each other. Much of this information is useful for 250 managing various aspects of a WWW server, like the file system and 251 CPU utilization. This information is useful for meeting the 252 operational requirements. Much of this information is however more 253 detailed than many WWW server managers require for service level 254 requirements. 256 The remaining groups define software components which are installed 257 and/or running on the host. Performance information is defined which 258 extends that defined for each running process. Unfortunately, the 259 mapping between running software and installed software is difficult 260 since it is related by a foreign key (Product ID) which does not 261 appear to be required to exist in either table [6]. There is no 262 provision to represent a group of processes which together perform 263 some task (IE an application made up of multiple processes). The 264 Applications MIB WG plans to address these deficiencies. 266 4.3. Network Services Monitoring MIB [4] 268 This MIB is one of three documents produced by the MADMAN (Message 269 And Directory MANagement) Working group. It defines a set of general 270 purpose attributes which would be appropriate for a range of 271 applications that provide network services. This definition is from 272 the perspective of the service without considering the implementation 273 in terms of host computers or processes. Attributes provide 274 statistics and status on the in-bound and out-bound associations that 275 are currently active, and which have been active. 277 This MIB is intended to be the minimum set of attributes common 278 across a number of Network Service Applications. Additional 279 attributes are to be defined as necessary to manage specific network 280 service applications. WWW servers clearly fall into the category of 281 network service applications. All attributes in this MIB are 282 relevant to WWW servers. 284 The MIB consists of two tables: 286 -applTable Mandatory 287 -assocTable Optional 289 The applTable describes applications that provide network services 290 and keeps statistics of the current number of active associations and 291 the total number of associations since application initialization. 292 The assocTable contains more detailed information about active 293 associations. 295 The other two MIBs defined by MADMAN, MTA MIB [7] and DSA MIB [8], 296 are not relevant to the management of WWW services. They do, 297 however, demonstrate how to extend the Network Services Monitoring 298 MIB for a specific set of applications. 300 4.4. Application MIB [5] 302 The Application MIB WG is defining two separate MIBs: the sysApplMib 303 and the applMib. The first defines attributes that can be monitored 304 without instrumenting the applications. The second will define 305 additional attributes requiring application instrumentation. 307 The sysApplMIB allows for the description of applications as a 308 collection of executables, and files installed and executing on a 309 host computer. The objects support configuration, fault and 310 performance management of some of the basic attributes of application 311 software. 313 The groups defined in the sysApplMIB are: 315 -System Application Installed Group Mandatory 316 -sysApplInstalledTable 317 -sysApplCfgElmtTable 319 -System Application Run Group Mandatory 320 -sysApplRunTable 321 -SysApplPastRunTable 322 -sysApplElmtRunTable 323 -sysApplElmtPastRunTable 325 The sysApplInstalledTable captures what applications are installed on 326 a particular host and the sysApplCfgElmtTable provides information 327 regarding the executables and non executable files which collectively 328 compose the application. The sysApplRunTable contains the application 329 instances which are currently running and the sysApplPastRunTable 330 contains a history about applications which have previously executed 331 on the host. The sysApplElmtRunTable contains the process instances 332 which are currently running and sysApplElmtPastRunTable contains a 333 history about processes which have previously executed on the host. 335 It should be noted that two implementations of the same set of 336 network services may each define a different set of processes and 337 files within this MIB. Ultimately enough management information is 338 needed so that these different implementations can at least be 339 managed similarly. 341 WWW servers fall into the general category of application software. 342 Therefore the attributes of this MIB are applicable if the process 343 level detail is requested to meet the Operational Model requirements. 345 The Application MIB WG is to resolve the problems described above 346 with the relationship between the running and installed software of 347 the Host Resources MIB. 349 5. Summary of Existing Standards Track MIBs 351 The existing MIBs are largely orthogonal as demonstrated by the 352 diagram below. Host Resources relates network information to the 353 interfaces defined in MIB-II. The system application MIB relates its 354 running element table to the equivalent entry in the Host Resources 355 running software table. 357 It should be noted that the running software of the Host Resources 358 includes ALL software running on the host, while the running element 359 table of the system application MIB only includes "interesting" 360 processes of monitored applications. 362 In the diagram below, "Other Services", "Application Specific MIBs" 363 and "Application MIB" represent work to be done or in progress. 365 +---------------+ 366 | Application | 367 | Specific MIBs | 368 +---------------+ 369 | 370 +--------+ +---+ +---+ +---------------+ 371 |Other | |MTA| |DSA| | Application | 372 |services| |MIB| |MIB| | MIB | 373 +--------+ +---+ +---+ +---------------+ 374 | | | | 375 +--------------------+ +---------------+ +--------------+ +------+ 376 | Network Services | | System | |Host Resources| |MIB-II| 377 | Monitoring MIB | |Application MIB|--| MIB |--| | 378 +--------------------+ +---------------+ +--------------+ +------+ 380 The stack of MIBs above "Network Services Monitoring MIB" represent 381 monitoring from the Service Model. The other stacks represent 382 monitoring from the Operational Model. Neither of these stacks goes 383 to the level of specific detail for any application. The author is of 384 the opinion that HTTP or Web Server specific MIBs would exist at the 385 top of each stack to represent the service and implementation view of 386 the server respectively. There should be a relationship between 387 these two perspectives defined so that the correlations between the 388 two perspectives is possible. This relationship would be useful for 389 general application and service monitoring in addition to just web 390 servers. However, it is not of specific interest to either the 391 MADMAN WG or the Application MIB WG. It is therefore suggested that 392 such a relationship is defined in a general case outside of either 393 of those groups that would be applicable for WWW servers as well as 394 for other application to service mappings. 396 6. Definition of additional attributes 398 The existing MIB attributes meet the Operational Model Requirement 399 for tracking information specific to a host. Specifically, MIB-II, 400 Host Resources and the Applications MIB address these items. The 401 Network Services MIB addresses a portion of the service model 402 requirement for the decoupling of the information space from the 403 transport mechanism. 405 Several sets of additional attributes are needed to meet the 406 remaining requirements. These additional attributes may be generally 407 applicable to other network information retrieval services (like FTP, 408 NNTP, GOPHER and WAIS) as well as client and proxy management. 409 Management of these services is not the scope of this document. 411 These additional attributes can be classified as: 413 1) Definition of relationship between the Network Services Monitoring 414 and Application MIBs. This allows the functional organization of 415 the server to be known. It allows the management application to 416 understand the effect of restarting specific processes on the 417 services provided. This addresses the Operational Model 418 requirement to model dependencies between applications. 420 2) Additions to generic Network Services Monitoring MIB. A draft [9] 421 has already been circulated due to the work of a mailing list and 422 a sample implementation. These attributes list a summary at the 423 service level of the configuration and the health of the server. 424 From this, performance metrics can be observed. In addition, the 425 health of the server in terms of data timeouts is known. These 426 attributes address the requirement for Operational Model tracking 427 of specific activity and the requirement for Service Model 428 retrieval services. 430 3) Document storage and access statistics are needed to address 431 service model requirements. 433 4) Additions to Application MIB are required to address server 434 configuration requirements in the service model. 436 5) Error and fault management attributes are required to address 437 requirements for tracking specific activity of the web server. 439 6) Configuration and Control are items that may be able to be defined 440 in a general way within the applications MIB. If not, a specific 441 definition would be required here. 443 Of the items listed above, (1) is needed on a general basis. The 444 others appear to the author as WWW server specific unless the scope 445 of the work is opened to WWW clients and proxies as well as other 446 services (like NNTP, FTP, GOPHER and WAIS). 448 7. Usage Scenarios 450 The example scenario will be a single host computer which implements 451 WWW services using the "virtual domain" concept. In this model, a 452 single host performs as the WWW server for one or more addresses. 453 For the purpose of example, we will specify that there are three 454 domains being serviced from this host whose WWW servers are: 456 -www.a.com 457 -www.b.com 458 -www.c.com 460 Some implementations may implement these services as one set of 461 processes that handle requests for each of the addresses. Others 462 may implement these services as a set of processes for each address. 463 This means that the relationship defined between the Network Services 464 Monitoring MIB and Application MIB components of the management 465 information may vary between different implementations of the same 466 configuration. 468 MIB-II and Host Resources would provide the information about the 469 host including the CPU, disk and network. The Host Resource running 470 table provide information on the processes in the system. 472 There would be an entry in the Network Services Monitoring applTable 473 for each virtual domain. In addition, the assocTable shows which 474 connections are currently active. An extension to the association 475 table would be helpful to provide information as to what is being 476 transmitted. 478 The sysApplMib would have entries in its installed software tables 479 for the web server software and each "interesting" component. This 480 should include the server binary, CGI programs, configuration files 481 and possibly the server log files. Depending on the implementation 482 of the server, the processes for each domain may show up in the same 483 or different running software tables. 485 Additional information as described in the previous section would 486 round out the management information that would be available for 487 the WWW server. 489 8. Conclusion 491 A number of currently defined attributes are useful for management 492 of a WWW server. Specifically, MIB-II and Host Resources should be 493 considered for monitoring the health of the machine in terms of 494 host and network configuration and capacity. The Network Services 495 Monitoring MIB and the Application MIBs provide a general framework 496 to represent the components of the WWW server from both a service and 497 implementation perspective. The Network Services Monitoring MIB 498 suggests that extensions are necessary to cover specific network 499 application monitoring. A set of such attributes can be well defined 500 to provide status information of the WWW server. The Application MIB 501 suggests similar extensions. Some of these attributes may be generic 502 to all applications, and thus be implemented within the scope of the 503 applMib. It is the opinion of this author that there will still 504 remain specific instrumentation for WWW servers that can not, and 505 should not, be covered in the Network Services Monitoring and 506 Application MIBs. 508 Since the Network Services Monitoring MIB and the Applications MIB 509 represent orthogonal efforts of management, it is desirable to 510 define the relationship between the two in a standard way. This 511 definition is probably more than a simple pointer from one table to 512 another. Since it is outside the scope of either of those efforts, it 513 is this author's opinion that that definition could and should be 514 addressed within the scope of defining management of a specific 515 application (IE WWW servers). This defintion although defined for 516 a particular application, should be useful in a general way to 517 describe the relationship between the Network Services Monitoring 518 MIB and the Applications MIB. 520 Additional attributes are needed in order to meet all of the 521 requirements specified in this document. An IETF standard would 522 prevent independent developments of this effort in many enterprise 523 MIBs. It also allows management applications to control servers from 524 multiple vendors. It is likely that as the work in this area 525 progresses, the management information will be useful for other 526 Network Information Retrieval services (like FTP, GOPHER, WAIS and 527 NNTP) as well. 529 Finally, the Operational Model and Service Model Requirements lead 530 to two main uses of the management information. Design of the MIB 531 including the usage of the existing MIBs should allow one or the 532 other or both of these models to be implemented in a standard way. 533 This may be desirable depending specifically on the audience of the 534 data, the cost of instrumentation and the resources of the system. 536 9. References 538 [1] Anonymous, "Logging in the W3C httpd", 539 http://www.w3.org/hypertext/WWW/Daemon/User/Config/Logging.html, 540 W3C, July 1995 542 [2] McCloghrie, K., and M. Rose, Editors, "Management Information 543 Base for Network Management of TCP/IP-based internets: MIB- 544 II", STD 17, RFC 1213, Hughes LAN Systems, Performance 545 Systems International, March 1991. 547 [3] Grillo, P., and S. Waldbusser, "Host Resources MIB", RFC 1514, 548 Network Innovations, Intel Corporation, Carnegie Mellon 549 University, September 1993 551 [4] Kille, S., and N. Freed, "Network Services Monitoring MIB", 552 RFC 1565, ISODE Consortium, Innosoft, January 1994 554 [5] Saperia, J., C. Krupczak, R. Sturm, and J. Weinstock, "Definition 555 of Managed Objects for Applications", 556 draft-ietf-applmib-sysapplmib-02.txt, BGS Systems, Empire 557 Technologies, Enterprise Management Professional Services, 558 Bellcore, May 1996 560 [6] Krupczak, C. and S. Waldbusser, "Applicability of Host Resources 561 MIB to Application Management", Empire Technologies, Inc., 562 International Network Services, October 1995. 564 [7] Kille, S., and N. Freed, "Mail Monitoring MIB", RFC 1566, ISODE 565 Consortium, Innosoft, January 1994 567 [8] Mansfield, G., and S. Kille, "X.500 Directory Monitoring MIB", 568 RFC 1567, AIC Systems Laboratory, ISODE Consortium, January 1994 570 [9] Hazewinkel, H., E. van Hengstum, A. Pras, "Definitions of Managed 571 Objects for HTTP", draft-hazewinkel-httpmib-00.txt, University of 572 Twente, April 1996 574 10. Acknowledgments 576 This document was produced at the request of the Network Management 577 Area Director following the HTTP-MIB BOF at the 35th IETF meeting 578 to report on the applicability of the existing standards track 579 MIBs to management of WWW servers. 581 The author gratefully acknowledges the comments of the following 582 individuals: 584 Ned Freed, ned@innosoft.com 585 Innosoft, Inc. 587 Harrie Hazewinkel, hazewink@cs.utwente.nl 588 University of Twente 590 Cheryl Krupczak, cheryl@empiretech.com 591 Empire Technologies, Inc. 593 Rui Meneses, rui.meneses@jrc.it 594 Centre for Earth Observation 596 Jon Saperia, saperia@bgs.com 597 BGS Systems, Inc. 599 Juergen Schoenwaelder, schoenw@cs.utwente.nl 600 University of Twente 602 Chris Wellens, chrisw@iwl.com 603 InterWorking Labs, Inc. 605 11. Further Information 607 The current status of the HTTP-MIB standardization can be found on 608 the World Wide Web at . An email 609 list is in operation for discussion of this topic. To subscribe, 610 send email to "http-mib-request@onramp.net" with the message body 611 of "subscribe HTTP-MIB". 613 12. Security Considerations 615 Security issues are not discussed in this memo. 617 13. Authors' Address 619 Carl W. Kalbfleisch 620 OnRamp Technologies, Inc. 621 Email: cwk@onramp.net 622 1950 Stemmons Frwy 623 2026 INFOMART 624 Dallas, TX 75207, USA Tel: (214) 672-7246 625 cwk@onramp.net Fax: (214) 672-7275 627 Table of Contents 629 1. Abstract.................................................1 630 2. Overview.................................................1 631 3. Requirements.............................................2 632 3.1 Operational Model Requirements...........................3 633 3.1.1. Host specific and Application Monitoring.................3 634 3.1.2. Dependencies among applications..........................3 635 3.1.3. Error generation and reporting...........................3 636 3.1.4. Capacity planning........................................3 637 3.1.5. Log Digester.............................................3 638 3.2. Service Model Requirements...............................4 639 3.2.1. Retrieval services.......................................4 640 3.2.2. Document information store -- managing documents.........4 641 3.2.3. Server configuration.....................................4 642 3.2.4. Server Control...........................................4 643 3.2.5. Quality of Service.......................................4 644 4. Relationship to existing IETF efforts....................4 645 4.1. MIB-II [2]...............................................5 646 4.2. Host Resources MIB [3]...................................5 647 4.3. Network Services Monitoring MIB [4]......................6 648 4.4. Application MIB [5]......................................7 649 5. Summary of Existing Standards Track MIBs.................8 650 6. Definition of additional attributes......................9 651 7. Usage Scenarios.........................................10 652 8. Conclusion..............................................11 653 9. References..............................................12 654 10. Acknowledgments.........................................13 655 11. Further Information.....................................14 656 12. Security Considerations.................................15 657 13. Authors' Address........................................15