Summary

  • RFC 3528 explicitly allows a mesh-enhanced Directory Agent to return SrvAck to a Service Agent before forwarding the registration asynchronously to peer Directory Agents. The acknowledgment can prove local acceptance while mesh-wide propagation remains unfinished.
  • A defensible receipt chain separates authorization, local acceptance, per-peer forwarding, anti-entropy completion, query visibility, registration lifetime, endpoint reachability and application outcome. A green registration result cannot inherit all of those meanings.

The first receipt arrived from the brightest node in the room. Its database contained the registration. Its local rules had accepted the update. Its response to the sender was well formed.

The other nodes were not part of that response. They might receive the update moments later over persistent peer connections. A failed connection might force anti-entropy. A user agent might query a peer before either event completed. The service named by the registration might not answer at all.

RFC 3528 was published in April 2003 as an Experimental protocol. It extends SLPv2 with a scope-based full mesh among Directory Agents, direct forwarding and anti-entropy. Its design is valuable precisely because it names the distributed states that a single acknowledgment cannot collapse.

The acknowledgment closes one local transaction

In SLP, a Service Agent sends a registration to a Directory Agent. The receiving DA processes it and returns SrvAck under the SLPv2 exchange. RFC 3528 calls the DA that takes the update the accept DA. When that DA is mesh-enhanced, it may subsequently forward the state to peer DAs serving the same scope.

The order is decisive. Direct forwarding is asynchronous. The accept MDA can acknowledge the MSA before sending the Srv(De)Reg to another MDA. The sender therefore learns that one directory agent accepted the message; it does not learn, from that receipt alone, which peers have received or indexed it.

This is not a flaw hidden between the lines. It is the stated protocol behavior. A design that waited for every peer before acknowledging would expose the sender to the availability and latency of the entire mesh. A local acknowledgment preserves a bounded transaction. The cost is that operators must preserve its bounded meaning.

An audit row should identify the accepting DA, the authenticated sender, the scope set, the registration digest, the local decision and the exact SrvAck causal type. Calling the row “service registered everywhere” invents a distributed observation that the accept DA did not make.

A reliable peer link does not make forwarding synchronous

Mesh peers maintain a persistent reliable ordered connection for all scopes they share. That transport property prevents a class of reordering and loss on a live connection. It does not turn future sends into completed sends, nor does it make every peer simultaneously available.

After initial reconciliation, the accept DA directly forwards new updates to its peers until a failure interrupts the path. The forwarding is one hop: the accepting DA sends to its peers in the registration’s scopes. Peers do not flood the same update onward as an uncontrolled relay chain.

The reliable connection also changes acknowledgment behavior. A peer need not acknowledge every forwarded registration because transport already supplies ordered delivery semantics. The absence of a peer SrvAck is therefore not itself failure, while the sender-facing SrvAck is not evidence of peer delivery.

A useful forwarding receipt is built from connection identity, authenticated peer identity, shared scopes, update accept ID, send position, transport result and the peer frontier observed after reconciliation. “TCP was up” is insufficient. It proves neither authorized mesh membership nor that a particular registration crossed and became queryable.

The mesh has no single acceptance clock

RFC 3528 attaches an accept ID to an update. It combines the accept DA’s URL with an accept timestamp. One accept DA assigns monotonically increasing timestamps, so updates from that origin can be propagated in their accepted order.

That is not a total clock for the mesh. Updates accepted by different DAs may travel in any relative order. Comparing their accept timestamps cannot establish a universal sequence, because the values belong to different origin streams rather than a shared consensus clock.

The registration also carries a version timestamp assigned by the mesh-enhanced Service Agent. That timestamp resolves which version of the same registration is newer. Arrival time at a peer cannot do the job: a delayed older update can arrive after a newer one.

The three moments answer different questions. The version timestamp says which registration version should prevail. The accept ID says where and in what origin order an update entered the mesh. The query moment says what one observer could retrieve at a later instant. Treating any one of them as the others destroys the reconstruction operators need after a disagreement.

The design assumes one SA updates a registration. It does not solve cross-writer conflict resolution. A system that allows several principals to edit one logical record has added a concurrency problem beyond the RFC’s evidence model and must document its own authority and version rules.

Summary vectors describe receipt frontiers

For anti-entropy, a mesh participant builds a summary vector. For each accept DA represented in the state it has seen, the vector retains the latest accept timestamp. It is compact evidence of progress along several origin streams.

The vector is powerful because it can drive a differential exchange. A peer can request updates later than the frontiers it already possesses. A complete request also covers origin DAs missing from the request, while a selective request asks only about the listed accept IDs.

But a summary vector is not a health certificate. It does not say that every stored registration remains unexpired, belongs to the right scope, answers every query, describes a reachable endpoint or produces a useful application result. It records received update history, not semantic truth about services.

The distinction between complete and selective anti-entropy belongs in the receipt. A successful selective exchange can be complete relative to its request while leaving an omitted origin entirely unchecked. A dashboard that shows only “anti-entropy successful” hides that selection boundary.

After an anti-entropy request, the provider sends the requested states in increasing accept-ID order and then returns SrvAck when processing of that request completes. That acknowledgment has a different causal object from the earlier registration acknowledgment. Reusing one undifferentiated success label makes two valid receipts misleading.

Recovery preserves age, not a fresh promise

When registration state crosses the mesh during recovery, its remaining lifetime travels with it. The transfer does not mint a new full lifetime. Otherwise, repeated reconciliation could keep stale service advertisements alive indefinitely.

Deletion has an equally important intermediate state. A deregistration is retained as a deleted registration—a tombstone—so that an older registration arriving late cannot resurrect what was removed. The tombstone can be purged when the original registration expires.

There are therefore at least three separate facts: a delete update was accepted, peers received the tombstone, and the expired state was physically purged. None proves that every observer stopped returning the record at the same instant. Query caches, temporarily disconnected peers and scope choices can create other visibility boundaries.

An operational record should retain the registration identity, version timestamp, accept ID, deletion flag, remaining lifetime, reconciliation path and query observations. “Deleted” without a vantage point and time is as overbroad as “registered everywhere.”

Scope defines the audience and the scaling cost

The mesh is formed per scope. All mesh-enhanced DAs serving a scope peer with one another, and a single persistent connection can carry state for multiple shared scopes. A mesh-enhanced SA can register with enough MDAs that the union of their scopes covers the SA’s own scope set, relying on propagation to reach the other peers.

This makes scope configuration part of the evidence chain. A registration accepted under one scope says nothing about DAs outside it. A user agent choosing another scope or another DA can obtain a different answer without violating the acceptance receipt.

The RFC presents the full mesh as a simplicity and reliability choice, generally for tens of MDAs or fewer rather than an arbitrarily large population. Every added member increases peer relationships and reconciliation work. This is design guidance from the document, not a measurement of a present network.

Splitting a broad scope into narrower scopes changes obligations. A service formerly registered under the parent can require registration under both child scopes to preserve discoverability. Taxonomy work is therefore runtime work: renaming or partitioning a scope can alter who receives state and which queries can find it.

Authentication determines who may write the mesh

RFC 3528 relies on SLPv2 authentication. It says an MDA should authenticate peer MDAs before forming the mesh, should authenticate MSAs before accepting and forwarding their updates, and an MSA should authenticate the MDA it uses.

Those are distinct trust decisions. Reliable ordered transport does not prove that the endpoint is an authorized directory peer. A syntactically valid registration does not prove its sender may speak for the service. A correct signature does not by itself decide whether the represented key is currently trusted for this scope.

The security consequence is systemic. If one MDA is compromised, false or destructive state can propagate to the rest of the mesh. The fan-out that improves availability also enlarges the effect of a wrong acceptance decision.

SLPv2 notes a bootstrap problem when no security configuration is already available: discovery may require a degree of “blind faith.” That warning keeps key distribution and verification policy in view. Protocol support cannot manufacture an authority relationship that operators never configured.

The IANA registry currently assigns SLPv2 extension ID 0x0006 to Mesh-enhancement and points to RFC 3528. The entry stabilizes an identifier. It does not attest that an implementation supports the extension, enables it, authenticates peers correctly, converges within a target or serves truthful registrations.

Query visibility is another measurement

The purpose of directory state is discovery, yet acceptance and discovery happen at different interfaces. A Service Agent writes to one DA. A User Agent later sends a query to a DA selected through its own discovery and scope rules.

To prove visibility, test from the relevant query vantage points. Record which DA answered, its authenticated identity, requested scopes, predicate, response digest, registration version, remaining lifetime and observation time. If the promise is mesh-wide visibility, sample every member or define an explicit, defensible coverage set.

Even then, a directory answer only says that a record was returned. It does not open a connection to the service, validate the service’s application protocol, authorize a user or complete the task for which discovery was attempted.

The evidence chain must continue: endpoint selection, DNS or address resolution where applicable, network reachability, protocol handshake, service-specific health and application result. A discovery record is a claim about where a service can be found. It is not the service itself.

Build receipts that keep the boundaries visible

Start with identity and authority: protocol version, RFC status, scope definitions, sender identity, credentials, trust-policy version and authorization result. Bind these to the exact payload digest, version timestamp, accepting DA and accept ID.

Record the local decision and the SrvAck sent to the Service Agent as a local receipt. Then create separate per-peer forwarding records, including connection identity, shared scopes, send result and later summary-vector frontier. Do not backfill the local receipt with facts learned afterward; link subsequent receipts by immutable identifiers.

For recovery, preserve whether the request was complete or selective, the supplied summary vector, requested origin streams, states transferred and final anti-entropy acknowledgment. Keep registration lifetime and tombstone state explicit.

Finally, observe queries and the service outcome. The chain is strongest when each control owner signs only its own result: directory operators certify state transfer, service owners certify health, identity owners certify principals and application owners certify the user-visible promise.

One green icon can still summarize the chain, but it must disclose which link it represents. If the icon means only “accepted here,” it should not remain green under a heading that says “available everywhere.”

Evidence boundary

This Article identifies no implementation, vendor, operator, mesh, Directory Agent, Service Agent, User Agent, service, endpoint, registration, deployment, incident, outage, exploit or customer outcome. It reports no current adoption, topology size, propagation delay, query success, reachability, health or business impact.

RFC 3528 is treated as an April 2003 Experimental protocol, not an Internet Standard. The documented 200-second keepalive and 300-second timeout values are protocol defaults, not evidence that any deployment used them or detected a failure within either interval.

Later metadata, registry entries and related RFCs retain their own scopes. They establish document identity, assigned values and protocol context; they do not prove running-code behavior.

Heng Lu’s notes on authority and running code are disclosed editorial lenses. They motivate a narrow question—what exactly may a coordination receipt claim?—but do not establish the authors’ intent, implementation conformance or operational fact.

The conclusion is bounded: a valid SrvAck can coexist with incomplete mesh propagation, uneven query visibility and a failed service. Each state requires its own evidence.

Sources