Summary

  • The FANN chairs adopted draft-dong-fann-problem-statement-00 as a working-group document and requested a resubmission under the draft-ietf- name; that is a disposition about a work item, not an operational command.
  • The adopted text says that action coordination remains for further study and out of scope. A notification can inform a local response without selecting the responder, authorizing the action, or proving the outcome.

A work item has changed state

The public conclusion is unusually useful because it says exactly what it does. The chairs concluded the Call for Adoption, named the individual draft, called it adopted as a FANN WG document, asked the authors to resubmit the same version under a new filename, and asked them to address call feedback in later iterations. Those are attributable process facts. They distinguish a completed poll from the separate work that follows it.

That distinction matters because “adopted” is easy to overread. It does not say that every premise of a problem statement is a measured fact in every network. It does not say that a mechanism has been selected. It does not say that a recipient may change forwarding, invoke a controller, move a workload, contact an application, or disclose a telemetry record. It does not say that an operator can rely on a future proposal before deciding its own policy and trust conditions.

The initial call was similarly bounded. It asked the list whether FANN should take on the Fast Network Notifications Problem Statement, with a stated response date. That request was a question about the group’s agenda. A response to it can be evidence of support, concern, missing scope or willingness to work. It is not a power of attorney from the organisations that will later accept or act on a notification.

The current individual record should also retain its own identity. The Datatracker describes draft-dong-fann-problem-statement-00 as an active individual Internet-Draft, not endorsed by the IETF and without formal standing in the standards process. The chair conclusion directs a successor filename; it does not make the old individual record, a future working-group version and a final published RFC interchangeable. A reader should be able to identify which version was called, which was adopted, which later version was reviewed, and whether any later disposition exists.

A notice is not the act it may inform

The problem statement itself draws the most important technical boundary. It describes fast notification of network conditions. It says that reduced packet loss or faster mitigation can be possible results of the actions that consume such notifications, but are not goals or requirements of the notification mechanism itself. The distinction is not decorative. It separates a message’s delivery from the policy that interprets it and from the action that changes an actual system.

A condition notification may be timely and still leave several questions open. Who emitted it? Which recipient is entitled to process it? What is the confidence or scope of the underlying observation? Which local policy maps that observation to an action? What action is reversible? Who pauses or rolls it back when a partial deployment behaves differently? Which party bears the loss if a traffic shift, protection response or workload decision is wrong? None of those questions becomes answered merely because a group has agreed that notification latency is a problem worth working on.

The draft is explicit that the mechanism for action coordination is for further study and outside its scope. It also says that recipients can be selected by configuration or signalling in the particular scenario, and that some recipients may subscribe according to roles or interests. This is not an omission to be silently filled with “the network will react.” It is the location of real authority. Different recipients can have different operational roles, risk tolerances, privileges and accountability. A shared notification vocabulary cannot make those local differences disappear.

That is why a notification should not be dressed up as an instruction. If an implementation carries a recommended response, the recommendation still needs a local admission rule. If a controller accepts a notification from another domain, source authorization and data handling need their own basis. If a recipient chooses not to act, that may be correct for its policy. If two recipients react, the potential collision is a coordination question—not proof that one of them was authorized by the problem statement.

The charter gives work scope, not operating authority

The FANN charter is useful in a different way. It identifies a problem statement, requirements and gap analysis to guide the group’s work and related deliverables. It tells readers why a working group may organize discussion around the problem. It does not decide a site’s topology, establish a cross-domain trust relationship, require one recipient to subscribe, or turn an abstract delivery objective into a service-level commitment.

The technical text reinforces that caution. It does not specify security mechanisms, while it says solution proposals must consider trust boundaries around subscriptions, authorization of notification sources and protection of operationally sensitive data. It also calls for evaluation of partial deployment and the consistency of corresponding actions. These are not footnotes that adoption has superseded. They are the reasons a later mechanism, a local configuration and an observed operating result must remain distinct records.

An operator therefore needs more than an adopted problem statement before making a consequential change. It needs the version it evaluated, the event classes it accepts, the source identity and authorization check, recipient role, action policy, rate and damping limits, failure behavior, observability, rollback owner and review trigger. A FANN document can eventually make some of those elements more interoperable. It cannot pre-approve them for every domain that may receive a message.

A small common receipt protects a large local decision

The common layer can still be strong without attempting to govern every response. It should retain the call opening, deadline, chair conclusion, exact draft version, successor version when available, stated scope boundary, comments that were dispositioned, and the next decision point. That is enough to let a reader see what the group decided to work on and what it has not yet decided.

The operator’s own record belongs beside, not inside, that receipt. It can name the notification source, the authorization rule, policy revision, recipient class, test environment, measured delivery behavior, action limits, exception path, accountable owner and rollback authority. This division is not bureaucracy. It prevents a public process state from impersonating a local control decision and prevents a local action from being advertised as IETF consensus.

It also makes later disagreement manageable. A reader can challenge whether the group adopted the problem statement by checking the conclusion. A participant can challenge a draft’s scope by checking its version and discussion. An operator can challenge an action by checking the policy and evidence that admitted it. Those are different questions with different owners. Joining them into one “FANN has solved fast response” assertion would make all three less auditable.

What deserves attention next

The next meaningful public evidence is not a retrospective claim about adoption. It is a successor working-group draft, an explicit requirements or solution proposal, a documented treatment of adoption-call feedback, and a later working-group disposition. For the action boundary, readers should look for an explicit coordination model, source-authentication rule, recipient authorization model, data-protection treatment, partial-deployment behavior and a stated relationship between notification delivery and operational action.

Until those records exist, precision is the useful posture. The group has decided to work on the problem statement. That is real. The draft has identified operational concerns and has declined to settle the coordination mechanism. That is real too. A network action remains authorized, tested and accountable only where the party that controls it says so on evidence appropriate to that decision.

Sources

  1. FANN chair conclusion of the Call for Adoption
  2. FANN Call for Adoption of the problem statement
  3. Current Datatracker record for the problem statement
  4. Fast Network Notifications Problem Statement, revision 00
  5. FANN charter