Summary

  • RFC 5249 made MIB review more consistent by moving authors away from copied RFCs and toward maintained external templates, because boilerplate and submission requirements change.
  • That design makes provenance operationally important: in this review, each named legacy template URL redirected to a generic author-resources page, which proves reachability but not retrieval of the XML, advised-text or plain-text artifact named by the OPS page.

Three successful requests, zero named files

The first request asked for an XML template for MIB documents. The second asked for the text edition with embedded advice. The third asked for the plain text edition without that advice. Each returned HTTP 200. Each ended at the same generic IETF Authors page. None of the three responses identified itself as the named MIB artifact.

That is not evidence of wrongdoing, and it is not proof that the templates were lost. An authoritative route may exist elsewhere. It is, however, a clean demonstration of a common evidence failure: availability was measured, artifact identity was assumed.

RFC 5249 was written to prevent almost the same category error. Editors had been using existing MIB RFCs as templates. A published document looked authoritative, but its boilerplate could reflect an earlier requirement set. The BCP therefore pointed authors toward maintained templates that could be updated as requirements changed. The standard stayed fixed; the practical starting point was allowed to move.

That was a rational division of labour. It also means “we followed RFC 5249” is incomplete unless the record says which external artifact was used.

A static BCP created a live control surface

RFC 5249 names three variants. The XML2RFC source carries comments and advice. An advised text version exposes guidance in the document. A plain version removes the advice. The difference is not cosmetic. A reviewer who sees only the rendered result cannot infer which prompts, warnings or MUST-level reminders were present when the author made decisions.

The RFC says many MUSTs in the templates commonly express IESG requirements and that MIB Doctors are likely to check them. It also says templates will be updated to reflect the latest requirements. The operative document process is therefore a composition: immutable BCP text, mutable template, other current policies, tool behaviour and reviewer judgment.

Composition requires version evidence. A citation to BCP 139 establishes the design rule. It does not establish the bytes fed to an editor on a particular day. A URL records an intended locator. It does not establish the terminal response after redirects. A page timestamp describes a page. It does not prove that a particular draft incorporated its latest content.

This is the reality-layer distinction in Heng Lu's notes applied to standards production. The label “current template” is a claim. The retrieved artifact, its hash, its provenance and the resulting validation are observable facts.

The redirect is a receipt for routing, not content identity

The current OPS wiki still describes the three MIB-specific templates and calls out updated templates from June 2013. The legacy URLs now redirect to authors.ietf.org/templates-and-schemas. That destination is useful: it contains modern generic RFCXML templates and resources for Markdown and Asciidoc. It also warns authors not to use a processed XML RFC as an Internet-Draft template because preparation hard-codes data that is unsuitable for continued editing.

The page retrieved for this research contained no MIB-specific template name. It did not claim to be the XML MIB document template, the advised MIB text template or the plain MIB text template. A redirect to that page may be an intentional migration to general author tooling. It may be a broad legacy redirect. The response alone cannot choose between those explanations.

An evidence system should preserve that uncertainty. Record the starting URL, every redirect, the terminal URL, retrieval time, response hash and content type. Then ask the authority question separately: does an IETF source identify this terminal artifact as the successor to the named MIB template? Until that edge is documented, the honest status is “reachable, successor identity unproven.”

The template never contained the module's truth

RFC 5249 draws another boundary that automation often erases. Its document templates do not provide the MIB module template itself. The BCP recommends developing the module outside the surrounding prose because validation tools typically need the module separated, and then including it in the document.

There are at least four independent receipts:

  1. the policy source that says what the document must contain;
  2. the exact template artifact used to structure the surrounding draft;
  3. the compiler or validator result for the separated MIB module; and
  4. the human review of meaning, security and implementability.

Passing one does not imply the next. A draft can have the right headings and a broken module. A module can compile while its DESCRIPTION clauses remain ambiguous. A security section can reproduce approved words while failing to identify the writable objects that would be dangerous if abused. A technically precise module can still use stale legal, IANA or submission boilerplate.

RFC 4181 makes this explicit. It calls for the latest approved management-framework and security templates, but tells reviewers not to copy security text blindly. It recommends syntax tools and then warns that syntax is only part of the job: someone must read the module as a potential implementer and decide whether its descriptions are clear enough to produce interoperable systems.

Familiar shape is the weakest possible provenance

Template use leaves visible patterns: section order, headings, stock transitions and editorial notes. Those patterns help review. They are not a version identifier.

RFC 7367 acknowledges Harrington's template, showing that later documents used the lineage. RFC 9349 shows that MIB documents continued to be published years after the 2013 OPS materials. Neither document reconstructs the exact source bytes available to another author or the advice that accompanied them. Attribution is useful history, not a reproducible build.

This matters most during maintenance. An editor may start from a working group draft, a recent RFC or an old local file because it feels safer than an unfamiliar current template. The file may render cleanly and pass basic checks. Yet the entire reason for RFC 5249 was that published precedent ages. Visual familiarity is exactly what makes stale requirements dangerous.

The right analogy is not a form in a filing cabinet. It is a build dependency. If that dependency can change independently of the BCP, pin it for the review, preserve it with the record and revalidate when it changes.

Security prose needs a subject, not just a slot

The current OPS security guidance says reusable text may need to change as new RFCs appear. It asks authors to identify sensitive readable objects and dangerous writable objects. Placeholders are invitations to analyse the module, not fields whose presence proves analysis occurred.

This is where generic template automation can create false confidence. A pipeline can require a Security Considerations heading, reject leftover angle brackets and check references. It cannot decide why a particular object exposes private data, how a write changes forwarding behaviour, or whether access control assumptions match deployment.

The review receipt should therefore connect each security claim to named objects and operations. If the section says there are no objects in a risk class, that negative statement should be deliberate. If an object is omitted, the record should not silently convert omission into “no risk.” RFC 4181 expressly rejects that inference.

The authority gap has an owner even when the link does not

Maintained templates reduce author effort and reviewer variance. Their owner absorbs the work of tracking changing submission rules. Authors receive a current starting point. Reviewers receive predictable structure. The agency problem appears when responsibility for the moving artifact is not visible at the point of reliance.

Who declares a template current? Who publishes its revision history? Who maps a retired URL to a successor? Who tells an author that a generic template lacks MIB-specific advice? Who bears the delay when the answer is discovered only during expert review?

Those questions are not an argument for freezing guidance inside a new RFC every time a heading changes. They are an argument for making the delegation inspectable. A mutable control surface needs release identity, change history, ownership and durable redirects that preserve semantic identity rather than only web reachability.

A review packet should survive the website

For each MIB document, freeze a compact provenance manifest alongside the review:

  • source policy and BCP identifiers;
  • template name, revision, authoritative locator, retrieval time and SHA-256;
  • redirect chain and the evidence that any successor is authoritative;
  • separated MIB module hash and validation-tool version;
  • validation output, warnings and unresolved exceptions;
  • subject-specific security review mapped to objects;
  • human reviewer, review date and disposition.

The packet does not need to publish private working data. It does need to let a later maintainer answer what changed: the policy, the template, the module, the tool or the interpretation.

Running-code primacy is useful here because the final test is executable. A template can coordinate authors, but it cannot become the module. A compiler can verify syntax, but it cannot become deployment. A published RFC can stabilize text, but it cannot make every implementation agree. Each layer earns only the authority of its own receipt.

Sources