Summary

  • RFC 2039 divided management into an Operational Model for hardware, operating systems, processes and capacity, and a Service Model for the requests and responses experienced by web clients.
  • The document found useful host and application instruments but no complete service view; its three-virtual-domain example showed why the mapping between a service and the machinery beneath it could not be assumed.

A green light on a server is a statement about an object. The harder question is whether it is the object that matters.

That was the practical tension in RFC 2039, published in November 1996 under the title Applicability of Standards Track MIBs to Management of World Wide Web Servers. The memo was Informational, not an Internet standard. It followed an HTTP-MIB Birds of a Feather session at the 35th IETF meeting in Los Angeles and asked what management information a web operator actually needed. Its most durable answer was not a particular counter. It was a boundary.

The RFC called one side the Operational Model. Here the web server is a computer: processor, disk, network interface, operating system, server software, installed files and running processes. Management asks how much capacity is being used, what depends on what, which errors are generated, and what must be stopped or restarted when configuration changes.

The other side was the Service Model. Here the server is treated as a black box that handles client requests and produces responses. Management asks what retrieval service is being used, how it performs, which documents are served, whether access controls apply, and whether the applications behind dynamically generated material are actually operational.

These views were complementary, but not interchangeable. A host can have spare CPU and a responsive network interface while a gateway or database needed for one class of documents is unavailable. A web service may continue returning some responses while disk headroom, a process dependency or the underlying machine is approaching failure. Each observation can be accurate and still say nothing conclusive about the other layer.

Why process inventory was not enough

RFC 2039 surveyed the available standards-track management work rather than pretending the field was empty. MIB-II exposed system and interface information. The Host Resources MIB represented processors, storage, devices and installed or running software. Network Services Monitoring described service applications and their active associations. Application MIB work sought to describe executables, files and instrumented applications.

The memo’s judgement was restrained: these attributes were useful. Much of the host-level requirement could be met. Network Services Monitoring supplied part of the service picture. Yet the stacks were orthogonal, and neither reached far enough by itself. A service-to-process relationship was not just a pointer because software composition differed from one implementation to another.

Its best demonstration used one physical system serving three virtual domains. One server program might host all three. Three processes might host one each. A dynamic document might pass through a gateway and a database, while a static document depended only on a file. A process table could truthfully report that the server binary was running without identifying which virtual service had failed or what it had transmitted. A service table could distinguish virtual domains and associations without revealing which executable, configuration file or downstream application needed intervention.

That gap changed what “management” meant. It was not enough to collect more numbers. The operator needed a maintained map between service identities and operational components, plus web-specific instrumentation that described activity at the request-and-document layer.

Requirements on both sides of the boundary

For the operational view, RFC 2039 wanted CPU, disk and network-capacity utilisation; explicit dependencies among applications; consistent error reporting; history for capacity planning; and structured access to information commonly left in server logs. Dependency representation mattered because stopping, restarting or reconfiguring one process could disturb several services.

For the service view, it wanted usage and performance of the retrieval service, including static and dynamic sources. It called for document-level activity and permissions, the status of applications that produced dynamic information, central configuration, operational controls such as start, stop and log rotation, and an indication of service quality.

Those words should not be inflated into modern claims that the RFC did not make. It did not measure reliability, define contemporary service objectives, report adoption or show that a particular implementation improved performance. It mentioned an Internet-Draft, a mailing list and a sample implementation as work in progress. Its security section explicitly left security issues undiscussed.

RFC 2594 later made the service side more concrete. Published in May 1999 as a Proposed Standard, it defined managed objects for WWW services around an abstract document-transfer protocol, requests, responses, status codes, virtual hosts and statistics. It explicitly described its view as service-oriented rather than process-oriented, and limited its purpose to short-term problem detection and troubleshooting rather than accounting or hit metering. It could connect to system and application management frameworks, but it was also self-contained.

That later design did not formally update or obsolete RFC 2039. It nevertheless shows the consequence of the earlier distinction: the service needed its own vocabulary. A web request is not a CPU sample, a virtual host is not an executable, and a successful process lookup is not a successful response.

Sources