Summary

  • draft-ietf-opsawg-rfc5706bis-06 would require an Operational Considerations section in new IETF-stream RFCs for new protocols, extensions and their use, while allowing a reasoned statement when no new considerations are found. It remains an active Internet-Draft intended for Best Current Practice, not an approved RFC.
  • The proposed section improves design-time visibility; it does not certify operational readiness or identify the person entitled to accept a particular deployer’s residual risk. The draft itself avoids that overclaim: it does not demand a comprehensive inventory, fixed management solution or completion of every operational tool before publication.
  • A consequential deployment needs an operator-owned operability decision docket beside the specification. Each unresolved or environment-specific issue should be tied to deployment scope, evidence, monitoring, rollback, owner, review date and explicit acceptance authority without turning the docket into IETF normative text.

The packet on the screen is strong. It describes the transition from the old protocol, identifies a state that cannot be observed directly, notes a possible burst of management traffic and recommends a health indicator. The proposed Operational Considerations section has done what it was meant to do: it has made the design discussable before deployment.

The change request beneath it is weaker. “Operational considerations reviewed,” says one checked box. There is no statement of which limitation applies to this network, which customers sit inside the blast radius, what test result was accepted, when the exception expires or who can stop the rollout. A protocol author has identified risk. A reviewer has found the prose adequate. Neither act authorises a production decision for an operator they do not govern.

That missing handoff is the governance problem. Requiring the right section in a specification can stop operational questions from disappearing. It cannot answer them on behalf of every deployment.

The draft creates a place for operational truth

Revision 06 of the OPSAWG draft is ambitious in a useful way. It would replace RFC 5706, update the old RFC 2360 language that treated a MIB as the default answer, and require an Operational Considerations section for new IETF-stream RFCs that define new protocols or extensions or describe their use. The section is meant to cover management as well as operation. Process, policy and administrative documents are not swept into the requirement merely because they pass through the IETF stream.

At the research cutoff, this was still an Internet-Draft. The Datatracker showed the Working Group state as Submitted to IESG for Publication and the IESG state as Publication Requested, with no telechat date. Intended BCP status is a destination, not a current authority claim. The draft may change, be replaced or expire.

Its core diagnosis is difficult to dispute. Operational and management functions are expensive and awkward to retrofit after a protocol’s architecture has hardened. Designers should consider installation, coexistence, upgrade paths, dependencies, failure isolation, configuration, performance, security operations, accounting and tooling early enough that the protocol can still respond. A dedicated section gives authors and reviewers a stable place to find the result.

The placement recommendation matters more than it first appears. Putting Operational Considerations immediately before Security Considerations improves human discovery and may allow tools to detect whether the section exists. Visibility is itself a control. A question that must occupy a named part of the document is harder to bury in meeting memory or leave to vendor folklore.

But discoverability is not acceptance. A section is a container for design-time knowledge. It is not the signature block of every network that may later use the design.

A complete-looking section can still be deliberately incomplete

The draft is unusually clear about its own limit. It does not require a comprehensive inventory of operational issues. It does not prescribe one format, one management protocol or a formal data model. A Working Group may decide that interoperable management machinery is unnecessary, provided the decision is conscious and recorded rather than an omission. A substantial operational treatment may live in another document, with the specification carrying a short overview and normative references.

Most importantly, publication is not supposed to wait until every management solution or supporting tool exists. Authors should articulate gaps and document what is reasonably foreseeable at design time. Some operational knowledge can emerge only after people run the technology under real load, across mixed equipment and through failures that were not visible in a laboratory.

This flexibility is good standardisation policy. If every protocol were held until every local tool, dashboard and runbook existed, useful work could become hostage to deployments the authors do not control. If every operational issue had to be solved in the base specification, the document could become a catalogue of speculative machinery.

The flexibility also creates a clean boundary. “This risk is documented” may truthfully mean “the design community has exposed a known gap that is not solved here.” A deployer cannot turn that sentence into “the remaining risk is accepted” without a second act by someone who has authority over the affected service.

The escape clause records consideration, not universal safety

When authors conclude that a protocol or extension adds no new manageability or deployment concerns, the draft calls for a stock sentence saying so, followed by a brief rationale. Its stated value is evidentiary: the section tells future reviewers and deployers that operations and manageability received due consideration.

That is stronger than silence. Silence leaves no way to distinguish “we looked and found nothing new” from “nobody asked.” A reasoned statement creates something later contributors can challenge when the environment changes.

Yet a justified no-new-considerations conclusion is still scoped to the document. It may mean an extension inherits the base protocol’s monitoring and recovery model. It does not mean every implementation exposes those functions correctly, every operator has integrated them, every dependency has enough capacity, or every deployment uses the base mechanism in the assumed way. “No new requirement” is not “no residual risk.”

The draft demonstrates the distinction in its own Operational Considerations section. It says that the guidance creates no new operations or manageability requirements because the document does not define a protocol, extension or architecture. That is a classification of this document’s effect. It is not a warranty about the operational condition of networks that later rely on its advice.

An approval record should therefore preserve the rationale and then ask a local question: which assumption in that rationale has been verified here? If none needs testing, say why. If the deployment depends on an existing alarm, rollback mechanism or data model, identify the version and evidence that make the dependency real.

Deployment experience changes the meaning of “foreseeable”

The draft’s BGP flap-damping example prevents a comforting fiction. The mechanism was intended to suppress frequent route changes. In practice, resource constraints and path exploration produced behaviour—including false damping and lost reachability—that became visible at scale. The feature was often not enabled network-wide. The point is not that its designers failed to write a longer section. The point is that some questions do not exist in usable form until deployment creates evidence.

This should change how exceptions are governed. A design-time gap cannot receive an eternal waiver. It can receive a bounded decision based on present knowledge, coupled to observations that may reopen it. The expiry is not punishment for uncertainty; it is recognition that the evidence surface changes after deployment.

The same logic applies to the draft’s newer concerns. OAM traffic and telemetry can overwhelm a management plane, so designers are asked to consider rate limits. Security operations depend on logs, access controls, indicators and forensic tooling whose absence may weaken response without necessarily delaying publication. AI-assisted management may query devices and controllers frequently and aggressively, increasing load and raising integrity concerns. A specification can name these mechanisms.

Only an operator knows the size of its management plane, the behaviour of its controller fleet, its forensic obligations and the cost of a false automated action.

No global adjective—scalable, manageable, observable—can replace those local quantities.

Reviewers test the document; operators accept the exposure

The draft identifies protocol authors, Working Groups, OpsDir, PERFMETRDIR and the wider community as users of the guidance. Their roles are complementary. Authors explain the design. The Working Group weighs protocol choices. Directorate reviewers can test whether common questions have been faced. The IESG can judge a publication request within the IETF process. Implementers turn the specification into products. Operators decide whether a particular implementation belongs in a particular network.

These acts should inform one another without impersonation. A positive review does not transfer an operator’s duty of care to the reviewer. Publication does not attest that a vendor implemented the recommended counters. A conformance test does not prove that a migration plan protects the operator’s customers. A successful pilot does not silently authorise global rollout.

The boundary also protects the IETF. If a local approval record falsely treats publication as risk acceptance, later failure is blamed on an institution that never saw the topology, traffic profile or service obligation. Keeping deployment authority local lets the standard remain a common floor rather than a remote change board.

The missing artifact is an operability decision docket

For a consequential deployment, every material item raised by the Operational Considerations section should enter a small operator-owned docket. This is not a copy of the section and not a demand that the standards process solve local engineering. It is a record of the handoff from general design knowledge to a bounded decision.

Each docket item should contain:

  • the exact consideration, assumption or documented gap and the source section that names it;
  • the implementation and version, enabled features, deployment scope, dependencies and affected services;
  • the local failure mechanism, observable consequence and population inside the blast radius;
  • laboratory, pilot or production evidence, including the conditions the test did not cover;
  • the health signals, capacity thresholds and event rates that will be monitored;
  • the rollback or isolation action, the conditions that trigger it and evidence that it is still usable;
  • the issue owner, service owner and person or body authorised to accept the residual risk;
  • the decision, dissent or conditions attached to it, with effective and expiry dates;
  • the event that forces review, such as a new draft revision, implementation change, scale threshold, incident or missing tool; and
  • the correction trail when new operational experience overturns an earlier assumption.

The docket should distinguish four dispositions. Resolved means the local evidence meets a defined condition. Deferred means work remains but is not required before the bounded deployment. Accepted means a named authority understands the remaining exposure and owns the consequence. Not applicable means a documented feature or dependency is genuinely absent from this scope. A single checked box cannot safely express all four.

The record should remain small. It need not capture every discussion or reproduce sensitive topology. It needs enough provenance for a later reviewer to understand what was known, which scope was authorised and why the decision was reasonable at that time.

The docket must not become a second standards gate

There are two equal and opposite mistakes. One is to treat the Operational Considerations section as sufficient approval. The other is to demand that the IETF prescribe every operator’s docket, risk appetite and signatory chain.

The draft’s flexibility is worth preserving. A minimum common document can make operational knowledge portable without centralising deployment judgment. Local organisations can then apply their own safety, availability, regulatory and customer obligations. Small operators may use a concise change record; critical infrastructure may require independent review and staged evidence. The structure can be interoperable at the level of questions while the answers remain local.

This follows a broader governance principle in Heng Lu’s work: a common initial specification should leave room for later decisions by actors closer to the consequences. The useful minimum is the handoff, not universal command. The standard records what designers can foresee. The deployer records what it has verified, what it has not, and who is answerable for proceeding.

An Operational Considerations section can make risk legible. It cannot supply the authority that accepts it.

Sources