Summary

  • draft-nottnick-ietf-decisions-01 says a Working Group cannot overturn a decision settled at a broader IETF level, but may decide whether that wider decision applies to its own circumstances.
  • The draft warns that an inapplicability finding often rests on an assumption about the protocol’s deployment environment, and that such assumptions have often proved wrong over time.
  • Revision 01 is an individual Internet-Draft with no RFC stream, responsible Area Director, Last Call or IETF consensus. Its proposed procedure is not current BCP.
  • A deployment environment is not a label. It is a set of testable predicates about reachability, administration, users, gateways, dependencies, implementations and change control.
  • Daniel Kade proposes an applicability-assumption receipt that binds the wider principle, local decision, predicates, evidence, falsifiers, owner, review trigger and successor decision.
  • The receipt is not a waiver or deployment approval. It prevents a dated applicability judgment from becoming a permanent exception after its factual boundary has dissolved.

The difficult sentence comes after the authority rule

The most consequential part of Making Decisions in IETF Working Groups is easy to miss because it appears inside a discussion of authority. The proposal first says that Working Group consensus must stay within the group’s charter. It then adds a second boundary: a local group cannot use its own consensus to set aside a decision already settled at a broader IETF level.

That is the clear part. The harder part is applicability.

A general IETF position may be binding where it applies while leaving room to ask whether a particular design is actually inside its domain. Revision 01 uses congestion-control guidance as the example. A group might determine that its protocol can only be deployed in an environment where the broader guidance does not apply. The draft requires the reasoning to be stated and recorded, allows objection and appeal, and immediately supplies the warning that matters most: this kind of determination usually depends on an assumption about the deployment environment, and such assumptions have often turned out to be wrong.

The text does not say that writing “controlled environment” creates an exception. It does not say that a charter authorises a group to repeal wider consensus. It describes an interpretive decision whose validity depends on facts outside the words of the protocol.

That dependence is the governance problem.

This is a proposal about IETF practice, not IETF practice already changed

The distinction begins with the document itself. The Datatracker identifies revision 01 as an active individual Internet-Draft. It has no RFC stream, no responsible Area Director and no telechat. The page says only that an Internet-Draft exists. The document header proposes Best Current Practice status and says RFC 2418 would be updated if the work were approved. Those are intended outcomes, not accomplished ones.

RFC 2418 therefore remains part of the published BCP baseline. RFC 7282 remains an Informational account of consensus and humming. RFC 2026 remains part of the standards-process and appeal architecture. Revision 01 is valuable evidence of a live procedural proposal; it is not authority to conduct a current decision as if the proposal had already become BCP.

This boundary is not ceremonial. A paper about authority can acquire borrowed authority merely because it is clear, current and hosted in the Datatracker. The same discipline the draft demands of Working Groups should be applied to the draft: identify its state before relying on its content.

“Environment” is a compressed model

Engineers often use environment labels efficiently. “Closed network,” “single administrator,” “data-centre fabric,” “laboratory,” “managed endpoints” and “non-Internet deployment” can carry a great deal of shared context. During design, that compression helps a group reason without restating the entire system on every page.

For an applicability determination, however, the compressed label is not enough. The conclusion rests on predicates such as these:

  • traffic cannot cross a public or independently controlled boundary;
  • all endpoints remain under one change authority;
  • no gateway converts the protocol into a wider service;
  • the user population and threat model remain bounded;
  • dependencies do not import the condition the wider principle addresses;
  • implementations reject operation outside the asserted domain;
  • operators can observe when any of those facts stops being true.

Each predicate can change while the protocol name stays the same. A product can add a cloud relay. An isolated control plane can gain an interconnection. A library can be reused in a different application. A deployment once managed by one operator can be federated. A debug interface can become an integration surface. An implementation can quietly omit the guard that the architecture assumed would prevent external use.

The old consensus record may remain perfectly intact through every one of those changes. That is exactly why the record needs a lifecycle.

A local applicability judgment is not a general waiver

Three claims must remain separate.

First, a wider IETF decision exists. RFC 7258, for example, records the community’s technical consensus that pervasive monitoring is an attack and requires protocol designers to be able to explain whether it is relevant and how it has been considered. RFC 2914 records congestion-control principles. The new draft invokes this category of broader decision when describing the limit on Working Group authority.

Second, a Working Group may decide that a broader principle does not apply to a specific question because of defined circumstances. That is a decision about the relationship between a principle and a domain, not a cancellation of the principle.

Third, an implementer or operator decides whether a concrete system actually remains inside that domain. A Working Group cannot inspect every later topology, product integration, tenancy model or gateway. Even a sound standards decision cannot certify an unknown deployment.

Collapsing these claims creates a travelling exemption. A sentence written for one architecture is quoted by a vendor, copied into a security review and reused by an operator whose environment shares the label but not the predicates. Eventually “the Working Group decided” substitutes for evidence that the condition still holds.

Running code can test a premise without making it permanent

RFC 7942 gives Internet-Draft authors a way to disclose known implementations. Such evidence can be extremely useful here. An implementation can show that a protocol enforces a boundary, refuses unsupported modes or behaves as expected under a particular topology. Interoperability work can expose hidden assumptions. Operational trials can demonstrate which signals actually reveal boundary failure.

But RFC 7942 also says implementation information is time-dependent. Its suggested section is normally removed before RFC publication, and continuing evidence may need a maintained external home. That is the opposite of a permanent certificate.

An implementation-status entry proves at most what was reported about a named implementation at a date. It does not prove every implementation carries the same guard. It does not prove that deployed configurations keep it enabled. It does not prove the surrounding environment remains closed. Running code is evidence against a model; it is not a timeless definition of the world around it.

The applicability-assumption receipt

The smallest useful record has nine linked parts.

It begins with the authoritative wider principle: document, version, relevant section and publication state. Next comes the exact local decision: the question asked, proposal snapshot, decision date and consensus caller. A later editor should not be able to move the conclusion onto a materially different design without a new record.

The third part expands the environment label into predicates. The fourth attaches evidence to each predicate: implementation behaviour, test results, deployment diagrams, administrative constraints, known gateways and observed operating limits. Sensitive details can remain protected, but the public decision still needs enough shape for a reviewer to understand what kind of boundary carried the reasoning.

Fifth are falsifiers. If a new gateway, multi-operator use, Internet reachability, changed threat model or missing enforcement check would defeat the premise, say so in advance. Sixth is authority: who called consensus, which charter interpretation was used and where an appeal can go.

Seventh is ownership after publication. Someone must watch the premise rather than merely own the text. Eighth is a review trigger: a date, a new deployment class, a protocol extension, an implementation report, an incident or genuinely new information. Ninth is lineage. A successor decision should point back to the old one, preserve why it was reasonable then and state which fact changed now.

This record does not need to become a large compliance system. A short table linked from the decision can be enough. The essential move is to make the conditional grammar visible: the wider principle was found inapplicable because these predicates held, according to this evidence, at this time.

Expiry applies to the assumption, not automatically to the decision

An expiry date can be misunderstood as forcing a group to relitigate settled engineering on a calendar. That is not the recommendation.

The object that expires is confidence in the external premise. If a group has evidence that an environment is enforced by construction and the construction has not changed, review may renew the premise without reopening the technical choice. If the protocol has escaped its intended domain, the review may narrow the claim, add a mitigation, seek broader guidance or reopen the relevant decision.

The historical decision remains true. It is not deleted because circumstances change. What ends is its unexamined ability to govern a new environment.

Evidence boundary

No source reviewed shows that an IETF Working Group has used revision 01 to claim an improper exception. The BCP 41 passage is an illustrative example in an individual draft, not a documented case. There is no basis here to allege a defective consensus call, a protocol failure, an appeal or harm to users.

There is also no basis to say every environment-dependent decision must lapse on a fixed schedule. Some predicates are architectural and durable; others are operational and volatile. The proportional rule is that the review mechanism should match the rate at which the decisive facts can change.

The proposal’s warning is enough to justify the control. If environment assumptions have often proved wrong over time, a decision system should preserve not only what a group concluded, but the factual boundary that allowed it to conclude it.

Sources

  1. Making Decisions in IETF Working Groups, revision 01
  2. Datatracker document status
  3. Datatracker revision history
  4. RFC 2418 — IETF Working Group Guidelines and Procedures
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. RFC 8789 — IETF Stream Documents Require IETF Rough Consensus
  7. RFC 2026 — The Internet Standards Process
  8. RFC 8874 — Working Group GitHub Usage Guidance
  9. RFC 2914 — Congestion Control Principles
  10. RFC 7258 — Pervasive Monitoring Is an Attack
  11. RFC 7942 — Improving Awareness of Running Code
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. Lu Heng — The Policy Mirror