Summary

  • RFC 1503 suggested that an SNMPv2 manager accept a textual handle, host name or IP address and find the right context without asking the user to specify parties.
  • For a previously unknown host, its resolver would create volatile noAuth/noPriv party records, a context and an ACL allowing get, get-next and get-bulk. The application’s security requirements still governed whether an operation could run.

The 1993 memo begins with an operator’s irritation: why should a person invoking a management application have to name the protocol parties and context as well as the machine? Keith McCloghrie and Marshall Rose put a “context resolver” between the application and the manager’s local party database. The user supplies a string. The resolver does the filing.

Its order of business matters. An exact textual handle such as router.xyz.com-public selects the context the administrator already configured. The shorter router.xyz.com may select both -public and -all by prefix. Those two contexts can carry different privileges: the memo’s example gives the public context interrogation operations and the other one authenticated access including set. The same convenient input can therefore identify a set of possible contexts, while the requested operation and security requirement decide which entry is usable.

If no configured handle matches, the resolver treats an IP address or a DNS name as an address. For one address it creates a volatile pair of noAuth/noPriv parties, a volatile context and a volatile ACL for get, get-next and get-bulk. For a name resolving to several addresses, it repeats that construction for each. “Volatile” is doing real work here: the proposed manager is manufacturing local records for a session of management, not discovering that the remote agent has authenticated anything. The identifiers follow the initialPartyId and initialContextId conventions of the earlier Party MIB.

There is an even more revealing shortcut. A slash after a host name or address supplies an SNMPv1 community string. The resolver can create another volatile interrogation context from that input. RFC 1503 is thus a design for lowering the setup burden across both versions, with the trust material tucked into a string a user types.

At operation time, the application supplies a context handle and minimum security requirements. The manager searches ACL entries that permit the operation and meet those requirements, choosing the least demanding suitable SNMPv2 entry before considering SNMPv1. If authentication is required and no suitable SNMPv2 entry exists, the operation stops. A name got the manager to a candidate context; it did not decide the permission by itself.

The RFC Editor record calls this an Informational memo, and its model is expressly illustrative. Its final security section says security issues are not discussed. There is no named product or successful query in that record. What the paper does preserve is a sharp design choice: hide administration from the operator, and the manager must perform it somewhere. The button may look simple; the local party database is doing the paperwork.