Summary

  • RFC 3055 made PINT services measurable from a server-side management surface, separating totals by service, time window, client, user and gateway.
  • Its counters were useful receipts, but “successful” remained an agent-maintained classification: it did not independently prove that a person answered, heard the content or received a readable fax.

A telephone service seen from the Internet side

PINT—the PSTN/Internet Interworking architecture—started with a useful asymmetry. The Internet could ask for an action in the telephone network without becoming the telephone network. A request could cause two parties to be called, a fax to be sent, stored material to be faxed back, or content to be spoken over a telephone. The request crossed an administrative and technical boundary. Important details of execution could remain inside the PSTN.

That boundary made monitoring unusually consequential. A web-facing service might accept a request while the gateway rejected it. A gateway might take it while the telephone side failed. A person might never answer. A fax call might complete at one layer while producing an unreadable page at another. Operators needed evidence better than a hopeful HTTP response or a generic server heartbeat.

RFC 3055 supplied a Management Information Base for that task. Published in February 2001 as a Proposed Standard, it defined an SMIv2 module under the IANA-assigned mib-2 number 93. The MIB was narrow by design. It monitored PINT-specific service performance; it did not manage the network elements, and it explicitly left related host and network performance outside its scope.

That narrowing was not a defect. It was the beginning of evidentiary honesty.

Four services, four windows, four ways to group a count

The MIB named four service types: Request-to-Call, Request-to-Fax, Request-to-Fax-Back and Request-to-Hear-Content. It offered four periods: the last 30 seconds, last 15 minutes, last 24 hours and since reboot.

It then exposed the same operational world through four different axes.

The global table gave the server-wide view. It counted calls received, successful calls and disconnected calls, then divided some failures into client or user authorization failures, server problems and gateway problems.

The client table grouped activity by a client address represented as a human-readable string. It counted receipts, successes, disconnections, client-authorization failures and egress-facility problems.

The user table did similar work for a UserIdName. The gateway table grouped received, successful and disconnected calls by a registered gateway name.

These were not four independent witnesses. The agent was expected to run at the PINT server, including when it reported gateway-related behavior. The tables were four cuts through an instrumented service surface. Comparing them could narrow a question—did failures cluster around one client, one user or one gateway?—but agreement did not turn server-side accounting into a telephone-network trace.

The dangerous word was “successful”

pintServerGlobalSuccessfulCalls sounds definitive. So do the corresponding client, user and gateway counters. Yet the MIB did not install a human observer beside every receiver or a scanner behind every fax machine. It specified objects through which an implementation reported its classification.

The distinction matters because PINT deliberately connected unlike systems. On the Internet side, an accepted service request could be meaningful progress. At a gateway, successful handoff could be another receipt. Inside the telephone network, answer, playback, fax negotiation and content transfer introduced further conditions. At the edge, a person could hear silence, misunderstand speech or discard an unreadable page.

RFC 3055 did not claim to close that chain. Its object descriptions used “successfully completed,” but a counter increment still belonged to the agent's instrumentation and the implementation's chosen event boundary. Without the implementation rule, transaction evidence and downstream observation, the word “successful” could not carry more weight than the layer that produced it.

This is not an argument against counters. It is an argument for keeping their receipt boundary visible.

A number needs a before, an after and a continuity story

Every service count in the performance tables used Counter32. SMIv2 defines that type as a non-negative value that increases until 2^32−1, then wraps to zero. It also states a principle that should hang above every operations console: a single counter value generally has no information content.

A value of 17,000 is not a rate. It does not say whether the system was busy, idle, recovering or reset. A useful claim requires at least two bounded samples and a reason to believe the counter remained continuous between them.

RFC 3055 called out the problem for the sinceReboot period. The consuming application had to account for the counter reaching its maximum and returning to zero. Reboot created another boundary. Rolling windows added their own questions: when was the 30-second window cut, did two agents align it, and did a missed poll erase the comparison?

Later Application MIB work made discontinuity indicators more explicit. That later discipline is useful context, not proof that every PINT implementation supplied it. For RFC 3055 evidence, the conservative rule remains: record the sample time, observation point, period, prior value, reboot state and wrap interpretation together.

Missing rows were not clean zeros

The user and client views promised diagnostic precision at a cost. RFC 3055 acknowledged that their tables could demand substantial resources. It left user-row aging to local implementation and floated a future top-N mechanism for high-level debugging.

That choice created several legitimate meanings for absence. A user row might be missing because there was no activity. It might have aged out. The agent might not implement the expensive detail. An identifier might be constructed differently on another server. A resource limit might preserve only a subset.

The user identifier itself carried an architectural assumption. It was expected to be unique across the relevant PINT servers and gateways and mapped to a session identifier. Appending client identity and a timestamp was suggested as one possible construction. A table key therefore reflected identity policy as well as observed traffic.

Treating a missing row as zero would erase both facts.

The MIB had no alarm bell of its own

RFC 3055 defined no notifications. Instead, it pointed to the Remote Monitoring MIB as a standard way to apply thresholds to counters—for example, repeated login or authentication failures from one client, or nuisance calls from one user.

That delegation kept the PINT module smaller, but it also moved alert semantics elsewhere. An RMON alarm depends on a selected variable, sampling interval, sample type, rising and falling thresholds, and associated events. Silence can mean that nothing crossed the line. It can also mean no alarm was configured, the relevant table was inaccessible, the sampling boundary hid the transition or delivery failed.

No trap is not a health receipt.

Read-only did not mean harmless

Only one object in the PINT MIB, the service-administrator contact, was read-write. There were no read-create objects. That might suggest a low-risk module. RFC 3055 rejected that shortcut.

The user identifier could reveal customer identity. Client and gateway slices could expose relationships. Service and failure volumes could reveal commercially sensitive performance. A manager who could only GET the tables might still learn who used the service, where failures accumulated and how traffic changed.

The RFC warned that SNMPv1 alone did not create a secure environment and recommended the then-current SNMPv3 user-security and view-based access-control models. Even an encrypted network did not answer the principal-level question: who was entitled to read or change which object? Later RFCs replaced those SNMPv3 documents, but their publication does not prove that a PINT agent used them.

The monitoring surface therefore had two evidence duties. It had to preserve the meaning of the counters, and it had to preserve the legitimacy of access to them.

What RFC 3055 really standardized

The durable achievement was not a claim that PINT had become observable end to end. It was a common vocabulary for asking narrower questions.

Which service was involved? Over what window? Was the count global or keyed to a client, user or gateway? Did the agent classify the operation as received, successful or disconnected? Which broad failure family did it assign? When did the counter reset or wrap? Which principal could read the answer?

Those questions make operations more legible. They do not remove the glass between a server's account and the physical result.

Sources

Lu Heng did not author or endorse RFC 3055. His essays are used here only as disclosed analytical lenses. The H. Lu credited on RFC 2458 is not treated as the same person without independent identity evidence.