Summary

  • RFC 5345 describes a five-stage SNMP measurement chain: capture raw packets, convert them, filter sensitive material, store the derived records and analyze them. Every stage can narrow what later claims are allowed to say. XML was designed to keep all relevant SNMP-message detail; CSV deliberately keeps selected fields and cannot preserve enough information to interpret SNMPv1 traps.
  • The most defensible record preserves capture scope, raw pcap, converter and filter versions, anonymization policy and analysis code. A registered XML namespace, a zero protocol error or a clean derived row does not prove complete observation, authenticated authority, current device state or an operational outcome.

A successful row was not a complete event

The CSV line was not fabricated. It accurately represented the fields its format had chosen to retain. Its timestamp was parseable. The request and response could be joined. The error status was zero. The object identifier and value were present. For bulk statistical work, those properties made the file attractive.

The trouble began when the derived format was treated as if it still possessed everything the packet had carried. RFC 5345 says otherwise. Its CSV representation captures “only the most relevant information” and points users to the XML form when all SNMP-message information must be retained. It then names a concrete loss: the CSV form does not preserve the information needed to understand SNMPv1 traps.

That distinction is not an argument against CSV. Measurement systems always choose a projection. The danger is forgetting that a projection has a boundary. A row can be adequate for response-count distributions and inadequate for trap interpretation. It can support message-size analysis while excluding link-layer headers. It can show a zero error field while remaining silent about whether a physical actuator moved or a configuration survived restart.

An honest query therefore begins with the format contract. Which fields exist? Which were normalized? Which were converted? Which were suppressed? Which questions were never answerable from this representation? “Valid CSV” is a syntax statement. “Complete evidence” is a claim about an earlier chain.

The blind spot begins before the file

RFC 5345 starts with raw packet capture, but “raw” does not mean omniscient. The probe sees only the traffic that crosses its observation surface. Its filter must match the transport endpoints actually carrying SNMP. UDP ports 161 and 162 are typical, not a guarantee that every management exchange will use exactly that path.

Placement matters just as much as the expression. On a bridged network, a probe may need access to every VLAN carrying management traffic. Mirror-port restrictions, asymmetric paths and traffic outside the management station’s immediate segment can make a quiet trace look like a quiet network. The RFC tells operators to investigate and document those restrictions because absence at one vantage is not absence from the system.

Packet length is another authority boundary. A truncated capture can preserve a header while losing the value whose distribution an analyst later reports. Snap length is not housekeeping; it is part of the evidence. So are packet drops, capture start and stop time, clock source and direction.

RFC 5345 recommends at least a full week to capture diurnal patterns and one weekly cycle, with longer periods encouraged. That is sensible sampling guidance. It does not turn seven days into a proof about a quarter-end change, an annual maintenance window, a rare failure, an emergency freeze or an incident that occurred before the probe was attached.

The denominator must travel with the claim. A report saying “no SNMP SET operations occurred” needs the capture locations, VLAN coverage, transport assumptions, sample window, loss counters and exclusion policy. Without them, zero is only the number of matching records inside one derived set.

A bad checksum may belong to the capture host

Local capture creates artefacts of its own. RFC 5345 points out that operating systems can offload transport-checksum calculation to a network interface card. A packet captured before the NIC fills the checksum field can appear invalid even though the wire packet was correct.

This gives an analyst a choice: disable offload, correct the apparent checksum during conversion, or ignore the field under a recorded policy. None of those choices should disappear into a generic “cleaned” flag. A later investigator must know whether a bad checksum came from the sender, capture timing, tool behavior or a repair rule.

Fragmentation adds a parallel problem. An SNMP message split at the IP layer must be reassembled before higher-level fields can be understood. A converter that ignores fragments can produce missing-message patterns that look like device or application behavior. A converter with a reassembly bug can join bytes that never belonged together.

The durable record names tool version, checksum policy, reassembly behavior, parser errors and rejected packet counts. Otherwise a conversion decision becomes an unreviewable fact.

XML and CSV answer different questions

RFC 5345’s XML form uses the namespace urn:ietf:params:xml:ns:snmp-trace-1.0. It was designed to represent SNMPv1, SNMPv2c and SNMPv3 messages and to retain relevant message detail, including some original ASN.1/BER length information for size analysis.

That richness costs storage and processing. The document recommends streaming XML APIs because in-memory representations do not scale well for large traces. The compact CSV alternative is faster precisely because it removes structure and selects fields.

Neither representation is inherently “the truth.” XML can be schema-valid and still derive from a blind probe. CSV can be perfectly suited to a bounded aggregate. The analyst’s duty is to align the claim with the retained evidence.

The SNMPv1 trap example shows why conversion provenance matters. Implementations may translate that trap into the SNMPv2c/v3 trap form according to RFC 3584, but activation of the conversion is a user choice. After conversion, the trace may be easier to compare with later notifications. It is not the untouched original. The record must say whether translation occurred and under which implementation.

If a repository merges converted and unconverted records without preserving that distinction, apparent changes in trap fields may reflect pipeline policy rather than device behavior.

The raw packet is the repair path

RFC 5345 repeatedly recommends keeping original pcap alongside XML and CSV. The reason is not nostalgia for binary files. Converter bugs are discovered. Protocol support improves. Analysis questions change. The only way to rebuild a lost intermediate correctly may be to return to the closest retained packet evidence.

The RFC calls pcap the most authentic information source in this chain. That phrase needs its own boundary. A pcap cannot recover an unseen VLAN, an excluded port, a dropped frame or a time before capture began. It is authoritative about the bytes retained at the probe, not about the entire managed network.

Retention also has a legitimate limit. Raw SNMP traces can contain community strings, usernames, access-control data, object values, addresses and operational topology. Privacy law, discovery risk or operator policy may make long-term raw retention impossible. RFC 5345 allows that reality. The consequence is not that the derived archive becomes equivalent to raw capture; it is that later verification has a narrower ceiling.

A responsible catalogue therefore states whether raw capture exists, who controls it, which transformations can be replayed and when deletion becomes irreversible.

Anonymization is a transformation, not a magic shield

SNMP instance identifiers can contain values. Packet and message headers reveal sources, destinations and authentication material. Even metadata describing the organization and probe position can help an attacker understand where to look.

RFC 5345 recommends a filter-in principle: retain a value only when its data type is known and an appropriate anonymization transformation exists. That is stricter than removing a few familiar secrets. Unknown structure should not be presumed harmless.

Yet privacy and analytical utility pull in opposite directions. An analyst may need lexicographic order in table indexes. Special transforms can preserve that order, but the RFC notes that their anonymization strength is usually lower than transformations that do not preserve ordering. The property that helps research can help correlation.

Initialization keys create another boundary. Independently anonymized traces may map the same original value differently, or unrelated originals into namespaces that cannot be compared. Merging them as if pseudonyms were globally stable can invent continuity.

The right provenance includes the filter rules, transform family, key scope, whether order was preserved, what was dropped and which cross-trace joins remain valid. “Anonymized” alone is not enough to assess either privacy or evidentiary fitness.

Counter values need discontinuity context

A trace can accurately record two counter values and still support a false rate. SNMP counters can reset or discontinuously change. RFC 5345 points to sysUpTime and the IF-MIB’s ifCounterDiscontinuityTime as contextual indicators.

If an interface counter falls from a large number to a small one, the result may be a wrap, a restart, a reinitialization or an instrumentation change. Subtracting endpoints without the applicable discontinuity evidence can produce a huge negative rate or an equally fictional wrap correction.

Freshness is also separate. The RFC notes that some implementations update counters from underlying instrumentation through adaptive algorithms, neither periodically nor on demand. Capture time proves when the manager received the value. It does not prove when the underlying physical state last changed.

A defensible metric carries counter semantics, discontinuity indicators, polling interval, agent uptime, response latency and known collection gaps. A dashboard that keeps only the calculated rate has thrown away the evidence needed to challenge it.

A namespace is not deployment evidence

IANA registered the XML namespace named by RFC 5345. That registration prevents a collision and gives the schema a stable vocabulary. It says nothing about how many operators used the format, whether a file was generated correctly, whether its capture was complete or whether the analysis was reproducible.

The status matters too. RFC 5345 is Informational work from the IRTF Network Management Research Group. Its IESG note explicitly says it is not a candidate for an Internet Standard and that the IETF does not attest its fitness for purpose. Treating the namespace as a certification mark would reverse that boundary.

Registry evidence supports a narrow statement: this identifier was allocated for this documented format. Adoption needs deployment evidence. Correctness needs validation and reproducibility. Truth needs the whole collection chain.

The result is a chain of bounded receipts

A mature measurement record does not ask one file to prove everything. It preserves linked receipts:

  1. capture plan and intended population;
  2. probe identity, location, interfaces and VLAN visibility;
  3. filter, snap length, loss and time window;
  4. raw pcap identity and retention policy;
  5. converter, checksum and reassembly settings;
  6. XML or CSV schema version and transformation log;
  7. filter and anonymization policy;
  8. analysis-code version and parameters;
  9. result with denominator and uncertainty;
  10. independent operational evidence for any claim beyond observed SNMP traffic.

This is not bureaucratic excess. It lets a later reviewer distinguish a device behavior from a probe blind spot, a parser defect, a privacy transform or a query mistake.

The enduring lesson of RFC 5345 is not that one file format wins. It is that measurement remains credible only while every projection admits what it can no longer see.

Sources