IETF Last Call Review of draft-ietf-sidrops-publication-server-bcp-10
review-ietf-sidrops-publication-server-bcp-10-httpdir-lc-nottingham-2026-09-08-00

[Drafted with AI assistance from a structured review over the document and the
WG's record, then reviewed and edited by me.]

The draft is mostly careful with HTTP -- no fixed paths, no new methods or
status codes, no redefinition of the caching model, and RFC 9110 is the
reference used throughout. Two things are worth fixing before publication.

## Issues

1. Section 3.4 says RFC 8181 has no way to signal backoff, but HTTP does

"Unfortunately, the publication protocol specified in [RFC8181] has no adequate
support for rate limiting or signaling requests to CAs to backoff. Therefore,
publishers SHOULD NOT perform this resynchronisation more frequently than once
every 10 minutes..."

RFC 8181 runs over HTTP POST. 429 or 503 with Retry-After (Section 10.2.3 of
RFC 9110) lets a publication engine enforce and communicate exactly this limit,
rather than asking publishers to self-limit on trust.

Reword to say the PDUs themselves carry no backoff signal, but a compliant
server can still respond with 429/503 plus Retry-After -- and recommend doing
so.

2. Compression with no mention of Vary

Section 5.3: "RRDP endpoints SHOULD support compression. At a minimum, gzip
content coding (see Section 8.4.1.3 of [RFC9110]) SHOULD be supported..."
Section 5.4 separately recommends serving RRDP content through a CDN.

Without Vary: Accept-Encoding, a shared cache has no basis to key on the
client's Accept-Encoding -- whichever variant it stores first is what every RP
behind that cache gets, regardless of what it asked for. An RP that never
implemented decompression, because it never sends Accept-Encoding: gzip, could
still be handed a gzip response.

Suggestion: "RRDP endpoints SHOULD support compression through proactive
content negotiation (see Section 12.1 of [RFC9110]). At a minimum, gzip content
coding (see Section 8.4.1.3 of [RFC9110]) SHOULD be supported. Additionally,
servers are RECOMMENDED to support other widely used compression algorithms
where feasible. Note that this implies that the Vary header field be sent on
responses; see Section 12.5.5 of [RFC9110]."

## Comments

Section 5.4's "unless the backend RRDP server is unavailable, in which case it
is RECOMMENDED that stale files are served" needs a mechanism: RFC 9111 Section
4.2.4 only lets a connected cache serve stale content when the origin or client
explicitly permits it (e.g. stale-if-error, RFC 5861, or an out-of-band CDN
contract).

ARTART (Fältström) already asked that Section 5.1's "same host" be pinned down
precisely. This document already normatively cites RFC 9110, whose Section
4.3.1 gives the same canonicalisation ARTART is asking for (lowercase scheme
and host, drop leading zeros from the port, substitute the default port when
elided) without pulling in RFC 6454.

Section 8 says no new security issues arise beyond RFC 8181/8182/9589/9674, but
Section 5.4's own CDN recommendation exposes RP fetch patterns to a third party
-- none of those documents' security considerations account for that. SECDIR's
review is still outstanding; may already be on their list.

## Nits

* Section 5.2: "HTTP GET parameters" isn't HTTP terminology -- query
parameters, or the query component of the request-target? * Section 5.9.2:
"HTTP keepalive" -- RFC 9112 Section 9.3 calls this persistent connections. *
Section 5.4: "HTTP 404 responses" -- editorial convention for status codes is
using the bare code plus reason phrase in parenthesis: "404 (Not Found)".

Cheers,