Summary

  • RFC 1095 gave CMOT and SNMP the same “Draft Standard” and “Recommended” status. The IAB wanted both implemented and tested, even though its earlier policy treated SNMP as the short-term tool and CMIS/CMIP as the longer-term system.
  • Both protocols were aligned to one Internet MIB, but shared object names did not supply a shared management application. CMOT interoperability required a specific profile of CMIS, CMIP, ACSE, ROSE, ASN.1 and lightweight presentation over TCP or UDP.
  • The profile covered one management domain, left applications outside its scope and made access-control parameters optional. An accepted association or returned operation therefore showed protocol progress, not institutional mandate or independently verified device effect.

The standards page had room for two winners

The famous ending is too tidy. SNMP became the familiar instrument of Internet operations; CMOT is usually introduced as the heavier alternative that did not. But RFC 1095 begins at a moment before that outcome had hardened into memory. It says the Internet Activities Board had designated two different network-management protocols with exactly the same status: Draft Standard and Recommended.

One was SNMP. The other was the Common Management Information Services and Protocol over TCP/IP, shortened to CMOT. Implementations that were network-manageable were expected to adopt at least one. The IAB wanted reports from builders and users of both.

Equal labels did not mean equal histories. A year earlier, RFC 1052 had recommended SNMP as the short-term basis because software was already available and operating. CMIS/CMIP was assigned the longer-term task: develop, deploy and test an ISO-based management system, then use real Internet experience to improve the standards conversation.

This was less a horse race than a policy hedge. The Internet urgently needed tools for rapid growth, but it also wanted a path into a broader international management architecture. “Recommended” recorded permission and priority for experimentation. It did not certify comparable code, deployment or operator confidence.

The distinction became visible almost immediately. RFC 1109, reporting a June 1989 review, described SNMP implementations in networks and products. For CMOT it reported no publicly available implementation at that meeting, although vendors and the University of Wisconsin had work planned. RFC 1095’s Interop ’88 prototypes established feasibility and multivendor promise; they were not a census of production use.

One MIB was the bridge, not the destination

The most consequential common decision sat above both wire protocols. RFC 1052 created a separate effort to define the Internet Management Information Base and directed it to feed both the SNMP and Netman groups. RFC 1109 later counted roughly one hundred public-subtree variables that both groups had accepted as mandatory.

This meant an IP input counter, a routing-table entry or another managed object did not have to acquire unrelated meanings merely because an operator changed the protocol used to ask about it. The common MIB was a semantic bridge. RFC 1052 even imagined it supporting a smooth transition from short-term SNMP to long-term CMIP.

But a common noun is not a common conversation. Two systems may agree that a managed object exists while disagreeing about how to select instances, scope an operation, report an event, establish a session, encode an error or protect a request. They may transport the same variable into entirely different operator tools.

RFC 1109 recognized that distinction. It said the effectiveness of management would be determined by the tools available to operators, not only by the supporting protocol. Neither contemporary service interface could ask for historical information or schedule an action for thirty minutes later. The MIB named observable things; it did not build the application that made them useful.

That is why RFC 1095 is so long. The common MIB did not eliminate the need for a profile. It made the profile’s job more exact: carry these Internet management semantics through one selected set of CMIS/CMIP options so that independent implementations could meet on the wire.

Interoperability lived in the seams

CMOT was not a single header placed over TCP. An implementer needed ASN.1 for abstract data, the Association Control Service Element to open and close an application association, the Remote Operations Service Element to carry operations, CMIS and CMIP for management services and protocol, the Internet SMI and MIB, and a lightweight presentation service defined in RFC 1085.

RFC 1095 therefore alternates between architecture and implementors’ agreements. It says which functional units belong in an association, how object classes and instances map into CMIP, which protocol data units can occur, how scope and filters are treated, and how ACSE, ROSE and CMIP are serialized through the lightweight presentation layer.

The point of the lightweight layer was practical. CMOT could use ISO application protocols without requiring an implementation of the full ISO presentation, session and transport stack. RFC 1085 preserved the presentation service interface while mapping it to familiar Internet transport.

That reduction did not turn optional standards into a slogan. Interoperability depends on decisions about which alternatives are allowed and how they are represented. A vendor saying “we implement CMIP” is less informative than a record of the application context, functional units, encoding agreements, transport mapping and MIB version actually supported.

The profile was therefore a boundary document. It reduced a large option space to a smaller set in which two machines might exchange meaningful management operations. It did not certify the machines, their applications or their organizations.

TCP and UDP did not promise the same journey

RFC 1085 offered two transport mappings. TCP supplied what it called the high-quality service; UDP supplied the low-quality service. Its memorable warning—low quality really meant low quality—was not decoration. UDP did not quietly inherit TCP’s connection, ordering and recovery properties merely because both carried presentation data.

RFC 1095 used that choice. Its lightweight presentation protocol could ride TCP or UDP, with managers on port 163 and agents on port 164. Under UDP, a CMOT protocol data unit was limited to 484 octets so it could fit an unfragmented IP datagram under the document’s assumptions. Discovery might come from a directory, from local configuration or from trying an association.

Thus “CMOT endpoint” was not one universal coordinate. The operator had to know the transport mapping, address, role, profile and discovery basis. A successful TCP association and a received UDP datagram provided different evidence about the path. Neither provided evidence about the mandate of the person behind the manager.

The same separation applies to failure. A timeout may reflect transport loss, presentation mismatch, association rejection, an unsupported CMIS function, access policy or the managed object itself. Collapsing every layer into “CMOT failed” discards the very boundaries the profile painstakingly defined.

The architecture drew a circle around one domain

RFC 1095 describes managers and agents, managed objects and the five familiar functional areas of OSI management. Then it declines to standardize the management applications that would perform those tasks. Its objective was the minimum architecture necessary for interoperable multivendor management; applications remained an arena for competition.

It also excludes relations and interactions between management domains. The architecture is confined to a single management domain. That line matters more than it first appears.

A management domain is not simply a subnet. It is an administrative arrangement: which systems act as managers, which elements accept their operations, what policy binds them and where responsibility lies. A packet can cross an IP boundary more easily than an institution can delegate authority. CMOT specified a protocol path; it did not invent the contract between two administrations.

The standard could therefore describe how a manager requests an operation from an agent without answering whether a manager from another organization was entitled to make the request. It could expose an object without resolving who owned the consequences of changing it. Inter-domain federation needed agreements above the protocol profile.

This is a useful antidote to diagrams that make management look symmetric and universal. Protocol roles can be implemented on either side and operations can be expressed consistently. Institutional power remains asymmetric, scoped and revocable.

An association was not a grant of authority

CMOT used ACSE to establish an application association. The parties negotiated an application context and functional units before management operations flowed. That negotiation was real evidence: it showed that two protocol implementations had found a compatible context.

It was not an employment record, a delegation instrument or an ownership certificate. RFC 1095 made association-level and request-level access-control parameters optional. It recommended handling access control at association establishment and anticipated future Internet authentication work, but the request field could be ignored by a receiver. A temporary simple method might consist of an unencrypted password.

These provisions should be read with their 1989 limits intact. They show that the authors understood access and authentication as distinct problems. They do not establish that every conforming association strongly authenticated its peer or that a password field expressed a complete authorization policy.

RFC 1109 made the gap explicit a few months later. It listed user access control and authentication of management commands and responses among the important matters not settled by either CMOT or SNMP. A standards profile could provide a place for access information without providing a complete, deployed trust system.

So the evidence ladder must stay ordered. Network reach permits an attempt. Presentation and association agreement permit a protocol conversation. Authentication attributes a message to a security principal under some method. Authorization permits an operation within a policy. None can be inferred solely from the rung below.

A returned result stopped before the machine’s consequence

CMIS could request information, change attributes and report events with richer service structure than a simple variable fetch. Yet RFC 1095 did not promise that every operation was a transaction over the physical world. Best-effort synchronization was required; atomic synchronization was optional.

Suppose a manager receives an accepted association and a successful response to a set operation. What is proven? At most, the profiled stack delivered and processed a request, and the agent reported the result defined by that operation. The response does not independently show that a card changed mode, that traffic moved, that a restart preserved the setting or that users saw the intended service.

Those are later observations. They may require a readback through a separate object, an event report, a traffic counter, configuration persistence evidence or measurement outside the managed element. When the same device supplies both command status and confirmation, the operator should still record that shared source rather than call the evidence independent.

The difference is not distrust of the protocol. It is correct attribution. CMOT standardizes messages and semantics. Instrumentation translates those semantics into device behavior. Hardware and network conditions produce effects. Each layer can succeed while the next fails.

RFC 1189 revised the profile, not the boundary

In October 1990, RFC 1189 obsoleted RFC 1095. CMIS and CMIP had moved from draft to final international standards. The revision removed tutorial material, moved Internet MIB semantics into a separate document, reused updated implementors’ agreements and changed association negotiation while preserving recognition of the earlier application-context name.

That history confirms why profiles exist. When a base standard changes, the Internet agreement has to say which version, options and contexts still interoperate. A protocol name alone cannot carry that state.

It also preserves the narrower lesson. In 1989, the Internet could recommend two management protocols and give them one MIB without pretending they were one system. The profile joined syntax and transport tightly enough to attempt interoperability. The management domain, authorization policy, operator application and observed device outcome remained outside or beyond that join.

The Internet’s later preference does not erase that architecture. RFC 1095 is valuable precisely because it records the layers that a winner’s history compresses: naming the same thing, carrying the same thing, being allowed to change it and proving that it changed are four different achievements.

Sources