Summary

  • A 27 October individual IETF draft gives each distributed policy a mandatory area, owner, author, language and opaque rule body. Its Policy Administration Point MAY ask a decision point whether the owner or submitter may set rules for that area. The border check is optional in the text.
  • A provenance signature can identify the package that crossed the boundary. It cannot grant its sender authority over the receiving network. The receiving operator must make that decision, record it and retain a way back.

The parcel arrived with its own name tag

Picture a network control room accepting a policy sent from another administration. The package says which area it governs and who owns it. It carries a signature. The screen can display every field in green while the operator's hardest question remains unanswered: who let this sender change what our systems do?

The 27 October individual Internet-Draft describes a YANG container for a single policy artifact. Its required leaves include an administrative area, a policy language, opaque policy-content, an owner URI and an author URI. origin and a provenance signature are optional leaves in the example model. The carrier can tell a receiving system what the parcel claims to be. The policy logic inside remains opaque to that carrier; the target engine supplies its meaning.

That distinction makes this a governance story rather than another format story. An owner field is a declaration inside the incoming object. It is not a permission issued by the receiving domain. An author field names the writer. It does not settle whether that writer may define rules for the named area. A cryptographic signature can show that the artifact has not changed since signing, provided the verifier trusts the key binding. It does not turn the signer into the receiving network's policy principal. The draft's own introduction identifies the risk: in multi-domain exchange, the source may be trustworthy as an identity but unauthorized to make policy for the target area.

A solid box around an optional gate

Section 6.1 assigns the Policy Administration Point, or PAP, the job of validating the schema, managing versions and, where applicable, checking provenance. Before acceptance or distribution, the PAP MAY query a Policy Decision Point to determine whether the declared owner or submitter is authorized to define or modify policy in the area. Section 6.2 then draws a large “Governance Authorization Check” inside the PAP box. The diagram looks like a border post. The normative sentence gives the operator a choice about staffing it.

This is a precise design tension, not a hidden scandal. MAY lets an implementation use a local authority model, perhaps because the draft aims to describe an exchange artifact rather than impose one trust framework. But a cross-domain deployment cannot use the diagram as proof that somebody checked the mandate. The receiver needs to specify its own decision rule: which principal grants power over which area, which credential establishes that principal, what happens when authority expires, and who can revoke an installed rule. Without that policy, the parcel can be impeccably signed and still be accepted for the wrong reason.

The author's NMOP mailing-list note describes a planned demonstration: one domain would feed a Rego policy to an OPA-based decision point; another would receive a policy based on RFC 9061 and establish an IPsec tunnel between particular nodes. Different languages make the transport problem real. They also make it tempting to declare victory once both engines understand their respective payloads. The harder test is whether each receiving domain can show the authorization decision that preceded installation.

The proposal is listed by IETF Datatracker as an active individual draft, with I-D Exists status. The mailing-list message describes a future hackathon demonstration. These records establish the design and the plan; they supply no completed cross-domain authorization trace.

What a border record must contain

The draft separates a policy store from the artifact in transit and leaves the distribution protocol to deployments. That is a sensible boundary. It also means the acceptance record must be supplied by the deployment. At a minimum it should join the exact artifact revision, the signer and verified key, the owner claim, the receiving area's locally recognized authority, the decision to accept or reject, the installation target and the rollback handle. The receiver should be able to answer the question after the rule changes, not merely while a dashboard still shows the latest package.

RFC 2904 supplies the older functional separation among authorization roles. The draft's reference to YANG provenance signatures supplies a way to bind origin and integrity to the data. Neither document writes a local delegation instrument for this receiver. That instrument belongs to the institution operating the receiving domain.

Sources