Summary

  • The IESG opened Last Call on 28 August for draft-ietf-sidrops-publication-server-bcp-10, an operational guide intended for Best Current Practice status. The Datatracker set 11 September as the end of Last Call.
  • The draft applies BCP 14 words such as MUST, SHOULD and RECOMMENDED, then expressly says they stress operational importance and are not formal implementation requirements.
  • The distinction prevents a respected IETF label from becoming an invented certification. A final BCP would document reviewed practice; it would not prove that a named repository implemented a control or met it during an incident.
  • Publication operators should therefore publish a versioned implementation receipt: exact section, architecture, declared state, exception, measurement window, incident history, restore and RRDP-reset evidence, publisher notice, resynchronisation state and bounded independent observation.
  • No source establishes that the draft has been adopted, that any operator is compliant or non-compliant, or that IETF consensus replaces contracts, audits, procurement duties or local routing policy.

A Last Call for the layer between signing and use

On 28 August, the Internet Engineering Steering Group asked the IETF community to review a document about a layer that is easy to describe and difficult to observe from end to end. A resource holder or other certification authority creates signed RPKI material. An RFC 8181 publication engine accepts changes. Public RRDP and rsync repositories make the material available. Relying parties retrieve and validate it before network operators decide what to do with the result.

The document in Last Call is version 10 of Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services. It is intended to become a Best Current Practice, not a protocol that introduces a new wire format. Its raw material is more than a decade of operating experience: separation of functions, availability, recovery after data loss, synchronisation, DNS and routing dependencies, CDN behaviour, load balancing, snapshot and delta ordering, and the consistent views that clients need.

That scope matters because a signature is not the last operational state. A certificate authority can produce a correct ROA, ASPA or BGPsec certificate while the publication engine is unavailable. The engine can accept a change while a public edge still exposes an older repository view.

A restore can move content back to an earlier state. A notification file can become visible before the snapshot or delta files it names. A relying party can retrieve a coherent view and still apply it at a different time from another relying party.

None of these seams invalidates RPKI. They show why publication is an operating system of responsibilities rather than a single green light.

The unusual sentence below the capital letters

Section 2.1 uses the familiar BCP 14 vocabulary. In ordinary IETF documents, uppercase MUST marks an absolute requirement of the specification, while SHOULD permits a departure only when the implications are understood and weighed. RFC 8174 narrows that special meaning to the uppercase form.

The publication draft adds a note that must travel with any summary of its requirements language. It says the capitalized words are used to stress importance for operations and are not required as formal implementation requirements.

The two statements should not be collapsed into either extreme. It would be wrong to strip the words of force and treat every MUST as casual advice. It would also be wrong to market the document as if every MUST automatically created a conformance test, licence condition or service warranty. The draft is saying something narrower and more useful: these practices deserve the strongest operational attention, but the document does not itself install a certification regime around them.

If the text completes the IETF process as a BCP, its status will matter. RFC 7841’s publication boilerplate distinguishes a BCP from an Internet Standards Track specification and records the review and consensus behind an IETF-stream document. That provenance tells readers why the guidance deserves weight.

It does not identify which operators have implemented it, which controls apply to their architecture, what evidence was examined or what happened during the last restore.

Consensus can define a practice. Only implementation evidence can describe an implementation.

The draft contains controls that can be observed

Many of the recommendations are not abstract aspirations. They point to facts that an operator can record.

The draft recommends placing the CA-facing publication engine on machines separate from the public RRDP and rsync services. The purpose is fate separation: a load spike on the public surface should not disable the channel through which publishers change their material. A useful record can name the logical separation and failure domains without publishing addresses, credentials or an attack map.

It says both the public repository and the publication engine must be highly available. The reasons differ. A public outage obstructs retrieval. An engine outage prevents a publisher from distributing new issuances and revocations. If disruption lasts, manifests, certificate-revocation lists and signed objects can become stale. “RPKI uptime” therefore needs at least two measured surfaces, not one blended percentage.

It recommends round-trip monitoring of expected and observed reissued objects. That is more informative than testing whether a web endpoint answers. A probe can show that an object expected after a controlled issuance became observable through the public path, with a definition of start, finish, vantage points and exclusions.

The draft cites research in which propagation across the studied authorities and repositories ranged from 15 to 95 minutes; that range is evidence about the study cohort, not a universal service objective.

It recommends that maintenance windows be planned and communicated to publishers. A public implementation record need not expose an email list. It can show the window, affected surface, notice time, declared impact, actual impact and closure state.

It also gives recovery a distinct grammar. If a restore causes content regression, the server must reset the RRDP session. The operator should notify dependent CAs so they know to perform a full resynchronisation. The CA is recommended to query the repository state before submitting changes, and a related changeset should be sent in one multi-element request to reduce inconsistent partial effects.

These are joinable events: backup restored, regression detected, RRDP session changed, publishers notified, list state compared, full state republished and public observation reconciled. An availability dashboard cannot reconstruct that chain after the fact.

A serial can move while confidence stands still

RRDP uses a session identifier and serial number to help relying parties keep a local repository copy synchronized. Deltas can carry discrete publication events, while a snapshot supplies a full current view. This is an efficient distribution design. It is not a universal audit statement.

A rising serial proves that one repository session exposed later revisions. It does not alone prove that the publisher’s intended set was accepted, that every load-balanced node exposed the same files, that a restore preserved recent publisher registrations or that all relying parties observed the change.

The current draft accordingly requires a notification file not to appear before its referenced snapshot and deltas are available. With multiple backends, each must present a consistent view; the order in which files become visible matters.

RFC 9286 gives manifests a complementary role. A manifest lists file names and hashes so a relying party can detect specified forms of stale substitution, unauthorized removal or in-flight modification. That is strong, bounded evidence. A valid manifest is not a certificate for the operator’s maintenance notices, dual-stack reachability, topology, backup age, CDN settings, load tests or publisher support.

The governance error would be to collect these different facts under one label—BCP compliant—without defining what was actually tested.

Consolidation is a recommendation, not a franchise

The draft observes that self-hosted repositories tend in practice to have more availability problems than services run by larger specialist organizations. It also notes that a larger number of publication points increases relying-party workload. Parent CAs are therefore recommended to offer publication to child CAs, and children are recommended to use an available parent service. Where that is unavailable, a reliable third party is preferred to a new isolated repository.

This is an operational case for consolidation. It is not a grant of political jurisdiction or an exclusive franchise to an RIR, NIR or commercial provider. The document also recognizes small repositories that can attain high availability with modest infrastructure and describes several ways in which a grandchild CA can publish through or beside its parent.

An implementation receipt should preserve that choice. It should name the architecture—self-hosted, parent-hosted, third-party or proxied—and apply only the controls relevant to it. Not applicable is a legitimate state when accompanied by a bounded reason. Silence is not, because silence lets a purchaser or relying party assume the strongest interpretation.

The same discipline applies to topology. The draft recommends IPv4 and IPv6, warns against a repository depending solely on address or AS authority whose correction it must itself publish, and recommends separating RRDP and rsync networks. Yet it also acknowledges the risk of becoming dependent on address space or networks managed by another organization. The correct evidence is not a universal architecture diagram. It is the operator’s stated choice, threat model, dependency owner and last verified test.

The implementation receipt

A useful receipt begins with identity. It should name the operator, service, architecture, public repository identifiers, relevant customer class and exact draft or RFC version. A claim tied only to “the IETF BCP” becomes ambiguous as the document changes.

The next block is a control register. Each material section receives a stable row and one declared state: implemented, not applicable, planned, exception or unknown. The row identifies who made the declaration, when it was last reviewed and why any exception exists. It does not expose keys, credentials, private publisher identities or security-sensitive topology.

The third block defines evidence. A round-trip publication measure needs the object class, start event, end observation, vantage points, sampling period, percentiles, failures and exclusions. Availability needs separate denominators for the publisher-facing engine, RRDP and rsync. CDN freshness needs a notification-cache rule and an observed check. Load-balancing consistency needs a safe test that can detect different views without publishing an exploit recipe.

The fourth block handles change and recovery. It records material maintenance, data regression, RRDP session reset, publisher notice, resynchronisation request, completion evidence and unresolved divergence. Corrections append a new state instead of erasing the original record.

The fifth block limits the claim. It says whether evidence is an operator declaration, independent measurement, contracted audit or incident review. It states the period and systems covered. It does not claim that IETF certified the service unless a future IETF process actually creates such a mechanism.

This receipt is deliberately less grand than a compliance badge. It can be challenged row by row. A badge encourages readers to stop asking.

What the evidence cannot establish today

The Last Call does not prove the draft will be approved unchanged. The IESG may receive comments, request revisions, evaluate the document or decline publication. No RFC or BCP number has yet been assigned.

The author affiliations—RIPE NCC, ARIN, APNIC and BSD among them—do not prove that those organizations implement every recommendation. Authorship is not an audit sample. Nor does the draft identify an operator that failed a recovery, served inconsistent content or hid an outage.

Nothing in the sources says that an IETF BCP overrides a service contract, procurement term, regulator, court order or a network’s local routing policy. RFC 8181 defines the publication exchange. RFC 8182 defines repository distribution. RFC 9286 defines manifests. Each settles important technical states; none turns a document title into evidence of performance.

The defensible conclusion is narrower. The IETF now has a detailed candidate record of how publication services should be operated. If it becomes a BCP, the record will be stronger. The missing step will remain the same: a particular operator must show, with bounded evidence, which parts it actually does.

Sources

  1. IESG — Last Call for the RPKI publication-services BCP draft
  2. IETF Datatracker — publication-services BCP document record
  3. IETF Datatracker — draft version 10
  4. RFC 2119 — requirement-level key words
  5. RFC 8174 — uppercase and lowercase clarification
  6. RFC 7841 — RFC streams, categories and boilerplates
  7. RFC 8181 — RPKI publication protocol
  8. RFC 8182 — RPKI Repository Delta Protocol
  9. RFC 9286 — RPKI manifests
  10. RFC 7115 — RPKI-based origin-validation operations