Summary

  • RFC 5190 maps one logical MIDCOM configuration transaction onto several SNMP operations. A successful SET reply can mean only that request parameters were written and processing may now start; completion and the full result can live in later notification and GET evidence.
  • Notification loss, ambiguous SET timeouts, concurrent writers and early deletion of terminal rows make correlation and retention part of correctness. A green event without the reconstructed reply is not an operation receipt.

The message looked conclusive. It carried the rule's operational status and remaining lifetime, and it arrived after the middlebox had finished processing the request. For a dashboard, that was enough to turn one row green.

For an evidence system, it was the beginning of another read.

RFC 5190 translates the MIDCOM semantics into an SNMP MIB. That translation matters because the two transaction models do not line up one for one. A MIDCOM request may contain more parameters than one SNMP datagram should carry. A client can therefore create a row, fill its request fields through several SET operations and finally write the administrative trigger. Completion of that last SET means the middlebox has enough input to start processing. It does not mean the requested policy operation has finished.

The logical reply is fragmented in the other direction. A solicited notification announces a relevant terminal state and carries operational status plus lifetime. If every reply parameter cannot fit there, the manager must issue one or more GETs. For a successful reserve or enable operation, those reads recover returned addresses, ports and other values. For failure, they recover operational status and the error text.

The trap is therefore not a self-contained receipt. It is a pointer into a stateful evidence surface.

The SET reply closes the wrong transaction

SNMP defines its own transaction boundary. A SET request and SET response say whether a collection of varbind writes was accepted as one SNMP operation. RFC 5190 uses those operations to assemble a larger MIDCOM request.

That creates three distinct times. First, a row exists. Second, all request parameters and the administrative trigger have been written, so the implementation can move from setting to checking and processing. Third, the middlebox reaches a rule result such as reserved, enabled, rejected or terminated.

If an operator records the second time as the third, the system manufactures completion. The MIB's operational states make the error visible: checkingRequest and processingRequest are transient states precisely because work remains after the write that triggered them.

The correct write receipt stores the exact SET, principal, varbinds, row index, response and time. It then says what that evidence authorizes: the SNMP agent accepted those writes. It does not silently inherit the authority of the later middlebox result.

A timeout is two possible histories

RFC 5190 is unusually direct about the ambiguity. The SET request and its reply are normally carried in unreliable UDP packets. If the request disappears, no write happened. If the request arrives and only the reply disappears, the write may already have happened. The client sees the same timeout in both cases.

Blind retry collapses those histories. A repeated lifetime change can be applied against a value that has already begun to count down. A repeated request can arrive after the row has moved, expired or been altered. The specification advises clients to check the initial write with GET and repeat only if necessary. It also points to snmpSetSerialNo, retransmission intervals bounded by the smallest requested lifetime or storage time, and the option of disabling retransmission.

Those controls reduce a protocol risk; they do not create business-level exactly-once execution. A serial number can distinguish requests within its defined mechanism. It cannot prove that packets crossed the middlebox, that a remote host accepted them or that an application completed its work.

An incident record should keep the ambiguous timeout, the recovery read, the retry decision and any serial number. Replacing them with “retry succeeded” discards the very fork that investigators later need to resolve.

Notification and polling trade cost for evidence

RFC 5190 offers two ways to learn that request processing ended. The middlebox can send a notification, after which the manager fetches any remaining reply fields. Or the manager can poll operational status until it observes completion, then fetch the reply.

The first path is cheaper when the event arrives. It is also lossy. SNMP notifications can disappear, and the absence of one does not prove that the requested operation failed. A client expecting an event must be prepared to poll the middlebox when the waiting interval expires.

The second path performs more SNMP operations, but the RFC calls it more reliable. That sentence is not an instruction to trust every poll. It is a statement about recovering state from a surface that can be queried again instead of depending on one datagram.

Polling has its own evidence boundary. A long list or multi-object result can change between GETs. A rule can terminate while the manager is walking related state. The specification tells the client to reconcile notifications received during the read or repeat the monitoring transaction. The result is a versioned reconstruction, not an atomic photograph.

The row is a temporary evidence cache

The rule table deliberately holds more than active rules. It can contain a row being assembled, a request under examination, a rejected request, an established rule or a terminated rule. That makes the row useful as a place to recover the logical result after a narrow notification.

It does not make the row an archive.

midcomRuleStorageTime describes how long a row may remain after entering an error or termination state. The value counts down toward deletion. Yet RFC 5190 also says there is no guarantee that a terminated row will remain for the indicated duration: an implementation may remove it early, after which the stored information is unavailable.

This creates a collection deadline. If the notification arrives but the follow-up GET is delayed, the event may survive while its explanatory row does not. If the notification is lost and polling begins late, absence of the row cannot distinguish “never existed” from “completed and removed.”

Operational systems need their own durable evidence object before the device's retention boundary closes. Copy the rule identity, owner, group, request parameters, status, lifetime, returned values, error and source timestamps. Preserve which values came from the notification and which came from later GETs. Do not backfill the event with fields that were never present in it.

Shared authority creates an assembly race

A logical policy request may require several SETs. Between the first and the final trigger, another client with the same access can reach the same row. RFC 5190 accepts that shared clients are usually coordinated, while recommending operational separation through scheduled access, distinct group indexes or non-overlapping rule-index ranges.

“Usually coordinated” is an assumption, not a transaction lock. If two automation systems share the owner namespace, one can replace parameters written by the other before processing starts. Every individual SET can authenticate correctly. The resulting request can still have no single authorial intent.

The evidence model therefore needs an assembly identity above the packet. Record the intended parameter set, writer identity for every mutation, row version, trigger write and any competing access. Per-message authentication proves who sent each message. It does not prove that the final row matches the plan of any one sender.

This is where the distinction from generic RowStatus matters. RowStatus explains whether a conceptual row exists, is ready or is in service. The RFC 5190 problem is how a larger operation is constructed and later reconstructed across several authenticated messages whose combined meaning can change between them.

Security applies to each message, not an imagined session

The MIDCOM semantic model speaks of sessions. The SNMP realization uses authentication and authorization per message. USM can supply identity, integrity, confidentiality and replay protection; VACM can constrain which managed objects that identity may read or write.

Those are necessary controls. They do not merge separate messages into one indivisible claim.

The SET that supplied an address, the SET that triggered processing, the notification that announced a state and the GET that recovered an error can each have different delivery evidence and timestamps. A missing GET cannot be inferred from a valid trap. A permitted write does not imply permitted access to every field required for post-event diagnosis. Notification filtering may also be configured separately from access to the transaction row.

Leadership should ask whether the complete evidence chain remains readable to the responsible operator, not only whether every individual packet passed its security model.

What the operating record must contain

Start with the logical operation: immutable request ID, intended MIDCOM transaction, rule and group coordinates, target middlebox, interface, desired parameters and accountable owner.

Append every SNMP operation separately. For SET, retain message identity, security principal, access decision, complete varbind set, snmpSetSerialNo if used, response or timeout and retry policy. Mark the final trigger that allowed processing to begin.

Track midcomRuleOperStatus transitions with observation time. Preserve whether completion was learned from a solicited notification or polling. Store the notification's actual fields without pretending it carried the rest. Then attach the GET responses that recovered returned tuples, lifetime, operational state and error text.

Record the row's storage type and observed storage time, the moment its evidence was copied and any later failure to retrieve it. If several clients can write the row, keep their individual mutations and the reconciliation decision.

Finally, join the control-plane reconstruction to the local NAT or firewall resource, packet observations on both sides, remote endpoint receipt and application outcome. The chain can legitimately stop early. “Rule enabled; packet outcome unknown” is better evidence than “operation complete” assembled from the wrong transaction boundary.

Sources

  1. RFC 5190 HTML
  2. RFC 5190 text
  3. RFC 5190 record
  4. IETF Datatracker: RFC 5190
  5. RFC 5190 history
  6. RFC 5190 references
  7. RFC 5190 errata
  8. RFC 5189
  9. RFC 5189 record
  10. RFC 3416
  11. RFC 3418
  12. RFC 3414
  13. RFC 3415
  14. RFC 2578
  15. RFC 2579
  16. RFC 2580
  17. RFC 3304
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy