Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services
draft-ietf-sidrops-publication-server-bcp-12

[Ballot comment]
Thanks to Joe S. for the SECDIR review.

Thank you to the authors for this draft, much appreciated. 

I support Roman's discuss on the draft as well.

[Ballot comment]
# IESG review of draft-ietf-sidrops-publication-server-bcp-11

CC @MikeBishop

Thanks to Mark Nottingham for the HTTP Directorate review (https://datatracker.ietf.org/doc/review-ietf-sidrops-publication-server-bcp-10-httpdir-lc-nottingham-2026-09-08/).

## Comments

### Section 3.2, paragraph 2
```
    Authorizations (ROAs) [RFC9582], Autonomous System Provider
    Authorizations (ASPAs) [I-D.ietf-sidrops-aspa-profile], and BGPsec
```
Why is this draft a normative reference? It seems to be used purely as an
illustration of what types of data won't get distributed during an outage.

### Section 3.4, paragraph 3
```
    perspective.  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
```
Echoing what Mark Nottingham already said in his HTTPDIR review: HTTP has such a
mechanism, and suggesting its use would be reasonable here. 429 or 503 with a
Retry-After header is the mechanism you want here.

### Section 5.4, paragraph 3
```
    server is unavailable, in which case it is RECOMMENDED that operators
    permit that stale files are served (see Section 4.2.4 of [RFC9111]).
```
RFC9111 prohibits serving a stale file unless something specifically allows it.
Possible ways to do that include stale-if-error (RFC 5861) or CDN configuration.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.1, paragraph 2
```
-    use a third-party operated publication service (e.g., operated by a
-                    ^
+    use of a third-party-operated publication service (e.g., operated by a
+      +++              ^
```

#### Section 5.3, paragraph 5
```
-    Section 8.4.1.3 of [RFC9110]) SHOULD be supported Additionally,
+    Section 8.4.1.3 of [RFC9110]) SHOULD be supported. Additionally,
+                                                    +
```

### Section 9, paragraph 1
```
    Westerlund, Patrik Fä (U+00E4)ltströ (U+00F6)m, Jasdip Singh, Behcet
```
Your Unicode characters aren't coming through properly.

### Grammar/style

#### Section 1, paragraph 3
```
cess to the RRDP repositories. In addition some guidance is provided for CA o
                                  ^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "addition".

#### Section 3.1, paragraph 10
```
Signed Objects cached by RPs will became stale, in turn hampering, for exam
                                  ^^^^^^
```
The modal verb "will" requires the verb's base form ("become").

#### Section 5.3, paragraph 2
```
110]. RRDP snapshots can be substantial in size (e.g., tens to hundreds of me
                            ^^^^^^^^^^^^^^^^^^^
```
This wording could be more concise.

#### Section 5.5, paragraph 4
```
quired in the overall ecosystem. Therefore publishers are RECOMMENDED to use
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thank you to Joe Salowey for their secdir review.

Section 2.1:  I support Roman's discuss.

Section 8:  There should be a short explanation here on the risks of using a CDN - tracking fetch patterns, for example.  It will also be important to note that the information being served is intended be highly available, very public and that the CDN also provides protections to the RRDP Repo (see Section 5).  I don't think this needs to be long, and I'm happy to help draft if that helps.

[Ballot comment]
My thanks to the authors and the WG for their work on this document.

Please find below my comments inline in the idnits output of v11 of this document.
Look for the tag  at the end.

19   This document describes best current practices for operating an RFC
20   8181 (A Publication Protocol for the Resource Public Key
21   Infrastructure (RPKI)) publication engine and its associated publicly
22   accessible rsync (RFC 5781) and RPKI Repository Delta Protocol (RRDP)
23   (RFC 8182) repositories.

Perhaps add in the Abstract about the guidance offered to publishing CAs?
Authors' call ...

166   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
167   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
168   "OPTIONAL" in this document are to be interpreted as described in BCP
169   14 [RFC2119] [RFC8174] when, and only when, they appear in all
170   capitals, as shown here.

172   |  Note that the key words are used to stress importance for
173   |  operations; they are not required as a formal implementation
174   |  requirement.

The note in Section 2.1 says the key words "are used to stress
importance for operations; they are not required as a formal implementation
requirement".  A document cannot give BCP 14 words a weaker reading than
[RFC2119] and [RFC8174] give them, so perhaps:

SUGGEST
  The requirements in this document are addressed to operators of
  publication services and to the CAs that publish through them; they are
  operational requirements rather than conformance requirements on a
  protocol implementation.

I will leave it to the authors' call. It might help address some of the concerns
on the other ballots.

296   reachability.  While the publication engine only needs to be accessed
297   by publishers, the repository content MUST be highly-available to any
298   RP worldwide.  Depending on the specific setup, this may allow for

314   for example, BGP Origin Validation [RFC6811].  For the aforementioned
315   reasons, the publication engine MUST be highly-available.

337   Publication service operators MUST aim to minimise data loss.  If a

These requirements in the document that I am not sure how they can be
measured against what the document states.  "Highly-available" is used normatively
in Sections 3.2 and 5.4 without being defined, and Section 3.3's "MUST aim to
minimise data loss" places a requirement on intent.  The reasons already given in
each place carry the point well, and using "should" alongside those reasons would
still make the point.  I will leave it to the authors' call.


457   Publication service operators need to be aware of the normative
458   updates to [RFC8182] specified in Section 3.1 of [RFC9674].  In
459   short, these updates mean that all RRDP delta and snapshot resources
460   need have the same origin, i.e., HTTP redirects or references to
461   resources with a different origin compared to the referring RRDP
462   SubjectInfoAccess AccessDescription are not allowed and not followed
463   by RPs.

Section 5.1 attributes both halves of the same-origin rule to Section
3.1 of [RFC9674].  The rule that RPs do not follow cross-origin redirects is
in Section 3.2 of that document; Section 3.1 carries the RS side. Suggest
citing Section 3 of [RFC9674]?


510   of [RFC9110]).  At a minimum, gzip content coding (see
511   Section 8.4.1.3 of [RFC9110]) SHOULD be supported Additionally,
512   servers are RECOMMENDED to support other widely used compression

"SHOULD be supported Additionally," --> "SHOULD be supported.  Additionally,".

506   The RRDP XML container and its embedded Base64-encoded content are
507   highly compressible; compression typically reduces the volume of
508   transferred data by approximately 50%. RRDP endpoints SHOULD support

Three figures are given without a source: the approximately 50%
compression saving in Section 5.3, the 251GB-of-55.5TB measurement in Section
5.5, and the approximately 50% reduction from a 48-hour reissuance cycle in
Section 5.6. Could a clause say where each comes from -- one operator's
measurement, or a general expectation?  E.g., the document cites
[rpki-time-in-flight] for its propagation figures ... so is something on
similar lines possible for these other numbers? Up to the authors ...


526   The RRDP snapshot and delta files SHOULD remain available for at
527   least two hours after they have become unreferenced by the latest
528   RRDP notification file.  A two-hour period retention period helps
529   ensure overlap with RPs following an hourly synchronisation schedule.

Section 5.4 sets snapshot and delta retention at two hours.  Sections
3.5.2.2 and 3.5.3.2 of [RFC8182] already carry a five-minute SHOULD for the
same files. Suggest a clause noting this difference, so an operator reading
both knows which to implement and explaining why they differ. Unless there is
something here that I am missing?


591   In order to mitigate potential problems, the notification file size
592   MAY be reduced by removing delta file entries from the notification
593   file that already have been available for an extended period of time.
594   Because some RP instances may only synchronize every 1-2 hours, the
595   RRDP server SHOULD include deltas for at least 4 hours.

597   Furthermore, it is RECOMMENDED that publication engines do not
598   produce RRDP delta files more frequently than once per minute.  A

Section 5.5 recommends including deltas for at least four hours.
Section 3.3.2 of [RFC8182] requires older deltas be excluded once their
combined size would exceed the snapshot, which may be hit well inside four
hours?  Suggest saying which governs -- presumably the [RFC8182] limit, with
four hours as a target where size allows?


607 5.6.  Manifest and CRL Update Times

609   The manifest and CRL nextUpdate times and validity periods are

Sections 5.6, 5.7 and 5.8 sit under "5.  RRDP Server" but
are addressed to publishing CAs and none is RRDP-specific: 5.6 is about
validity periods the CA chooses, 5.7 turns on rsync's transfer algorithm, and
5.8 is about ROA issuance. A reader looking for the rsync filename guidance
would look in Section 6.

Suggest moving the three under Section 4 (Common Repository Considerations),
which already holds what is common to both repositories.  Gathering them into
a new top-level section on CA-side choices would be cleaner and is a larger
edit; either answers it.  Section 1 already sets this up, at the sentence
beginning "In addition some guidance is provided for CA operators".

Again, up to the authors ...

646   *  The algorithm most commonly used in the preparation phase of rsync
647       transfers relies on the 3-tuple of filename, filesize, and last-
648       modification timestamp to determine whether material was updated
649       and should be transferred.  Therefore, using a new unique filename
650       for each new issuance may help improve reliable propagation of
651       newly signed material in the pipeline from publishers to RPs.

653   An additional benefit of using new unique filenames for new content
654   is improved debuggability, because using the same name throughout
655   time for different things may hamper, for example, swift and accurate
656   interpretation of log messages containing filenames.

658   In summary, to conserve bandwidth, to improve reliability of object
659   propagation, and to make debugging easier, publishers are RECOMMENDED
660   to use "one-time-use" EE certificates (Section 3 of [RFC6487]) and to
661   adhere to the guidelines for naming objects described in Section 2.2
662   of [RFC6481].

Section 5.7 recommends "using a new unique filename for each new
issuance", and closes by recommending that publishers "adhere to the
guidelines for naming objects described in Section 2.2 of [RFC6481]".  Those
pull apart for three of the four object classes: RFC 6481 Section 2.2 has a
new CRL "MUST replace (overwrite) previous CRLs signed by the same CA
(instance)", a new manifest "MUST replace the previous manifest", and a
certificate series "SHOULD share the same filename".

The advice reads as right for RPKI signed objects, where the one-time-use EE
certificates Section 5.7 also recommends give each issuance a distinct derived
name.  Could the sentence be scoped that way, noting that CRLs, manifests and
certificate series follow Section 2.2 of [RFC6481]?

666   The practice of issuing ROAs with only a single prefix per ROA
667   [RFC9455] can lead to many ROA objects being published by a given CA.
668   However, clustering multiple prefixes in a single ROA (per origin AS)
669   can achieve a significant reduction in the number of objects and the
670   total size of a repository.  In order to reduce bandwidth consumption
671   and reduce the number of signatures, it is RECOMMENDED that issuing
672   CAs cluster as many prefixes per ROA as possible, provided:

Section 5.8 recommends clustering as many prefixes per ROA as
possible. RFC 9455 (BCP 238) Section 4 recommends the opposite default:
"Unless the CA has good reasons to the contrary, an issued ROA SHOULD contain
a single IP prefix." Section 5.8 cites RFC 9455 but describes it as "the
practice of issuing ROAs with only a single prefix per ROA", and the document
neither updates it nor says how the two fit together.

Which is intended?  If the two conditions in Section 5.8 are meant as
instances of what RFC 9455 calls "good reasons to the contrary", one sentence
would clarify, for example:

SUGGEST
  [RFC9455] recommends that an issued ROA contain a single IP prefix
  unless the CA has good reasons to the contrary.  The conditions below
  are offered as such reasons for a CA publishing at scale; they are not
  intended to change the default in [RFC9455].

If instead the default is meant to change, that would call for Updates: 9455
and text saying what changed. I would think that this should anyway update
RFC 9455 but then we have two different BCP numbers so it would be rather odd.
I don't know what works best to be honest.

686   New RRDP notification files MUST NOT be made available to RPs before
687   the associated snapshot and delta files also are available.

689   As a result, when using a load-balancing setup, special care SHOULD
690   be taken to ensure that RPs that make multiple subsequent requests
691   receive content from the same node.  This way, clients follow the
692   timeline on one node where the referenced snapshot and delta files
693   are available.  Alternatively, publication infrastructure SHOULD
694   ensure a particular ordering of the visibility of the snapshot plus
695   delta and notification file.  All nodes should receive the new
696   snapshot and delta files before any node receives the new

Section 5.9.1 offers two ways to keep a load-balanced repository
consistent and puts a SHOULD on each -- "special care SHOULD be taken to
ensure that RPs ... receive content from the same node", then "Alternatively,
publication infrastructure SHOULD ensure a particular ordering".  Read as
written an operator has to do both.  And the sentence carrying what that
second option actually requires is lowercase: "All nodes should receive the
new snapshot and delta files before any node receives the new notification
file."  So the operative rule is the one sentence in the passage with no key
word.

Suggest recasting as a single requirement with two ways to meet it, and moving
the BCP14 key word (perhaps RECOMMENDED?) onto the operative sentence.


798   Empirical data suggests that rsync server operators MAY assume it is
799   safe to remove old versions of repositories after two hours.  It is
800   recommended to monitor for "file has vanished" (or similar) lines in
801   the rsync log file to detect how many clients are affected by the
802   cleanup process timing parameters.

Could you say what the data is?  And was "MAY remove ... after
two hours" the intent?  MAY grants permission to act rather than permission to
assume.


some other nitty nits :-)

  line 105  "diagram attempt to convey"          -> "attempts"
  line 239  "make use a third-party"              -> "make use of a"
  line 313  "will became stale"                  -> "become"
  line 352  "have not yet became stale"          -> "become"
  line 460  "need have the same origin"          -> "need to have"
  line 528  "A two-hour period retention period"  -> skip the first period?
  line 640  "as part of in Manifest fileLists"    -> "as part of Manifest"

[Ballot comment]
I support the DISCUSSes of both Roman and Mahesh.

Many thanks to Patrik Fältström for the ARTART review, and thanks to the authors for addressing his review and letting us know which unicode characters can be used to spell his name. :)

> 9. Acknowledgments
> The authors wish to thank Mike Hollyman, Theodor-Fedor Vompe, Magnus Westerlund, Patrik Fä (U+00E4)ltströ (U+00F6)m, Jasdip Singh, Behcet Sarikaya, and Mark Nottingham for their feedback and suggestions.

[Ballot discuss]
Section 10, Normative References:

872   [I-D.ietf-sidrops-aspa-profile]
873               Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley,
874               R., and B. Maddison, "A Profile for Autonomous System
875               Provider Authorization", Work in Progress, Internet-Draft,
876               draft-ietf-sidrops-aspa-profile-29, 29 July 2026,

I don't think this needs to be a normative reference at all. It's cited in
exactly one place:

306   distribute new issuances and revocations of Route Origin
307   Authorizations (ROAs) [RFC9582], Autonomous System Provider
308   Authorizations (ASPAs) [I-D.ietf-sidrops-aspa-profile], and BGPsec
309   Router Certificates [RFC8209] for the duration of this outage.

and it's just one item in a list of examples of the kinds of objects a
publication engine outage would affect -- alongside ROAs and BGPsec Router
Certificates, mentioned the same way. Nothing in this document depends on
any specific normative content from the ASPA profile: no requirement here
is conditioned on how ASPAs are encoded, validated, or profiled. Moving
it to an Informative Reference will prevent this document from hitting
a MISREF in the RFC Editor queue.

---

Section 8:

858 8.  Security Considerations
859
860   This document does not introduce any new security issues beyond those
861   already discussed in the Security Considerations of [RFC8181],
862   [RFC8182], [RFC9589], and [RFC9674].

This is the same text Mark Nottingham's HTTPDIR review flagged as
incomplete: Section 5.4 of this document itself recommends fronting the
RRDP repository with a CDN, which exposes RP fetch patterns and timing to a
third party that has no obligations under any of the four cited RFCs'
security considerations. Tim Bruijnzeels agreed on-list
that "operators [should] understand potential
exposure of fetch patterns and data modification risks" from third-party
CDN use, and said he'd add that. It isn't here in -11. Given this document
is the one recommending the CDN in the first place, I think the Security
Considerations section needs to actually say something about it rather than
disclaim any new issues at all.

---

I also support Roman's DISCUSS on the requirements-language framing
(Section 2.1):

165   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
166   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
167   "OPTIONAL" in this document are to be interpreted as described in BCP
168   14 [RFC2119] [RFC8174] when, and only when, they appear in all
169   capitals, as shown here.
170
171   |  Note that the key words are used to stress importance for
172   |  operations; they are not required as a formal implementation
173   |  requirement.

In the list thread, Job Snijders pointed to RFC 9972 as prior art for this
framing, and checking RFC 9972, it does carry the same caveat. So this isn't
a one-off choice by these authors. That context is useful, but I don't think
it resolves the underlying problem: the document still cites RFC 2119/8174
and then immediately disclaims the thing those RFCs exist to establish.
Either the MUSTs in this document carry their normal weight or they don't;
the text can't have it both ways, and as written a reader genuinely can't
tell which MUST/SHOULD pairs (e.g., "MUST be highly-available" vs. the
surrounding SHOULDs) are meant to carry different weight.

[Ballot comment]
Section 5.8:

664 5.8.  ROA Prefix Aggregation
665
666   The practice of issuing ROAs with only a single prefix per ROA
667   [RFC9455] can lead to many ROA objects being published by a given CA.
668   However, clustering multiple prefixes in a single ROA (per origin AS)
669   can achieve a significant reduction in the number of objects and the
670   total size of a repository.  In order to reduce bandwidth consumption
671   and reduce the number of signatures, it is RECOMMENDED that issuing
672   CAs cluster as many prefixes per ROA as possible, provided:

Roman raises this as a DISCUSS, and it sent me back to read RFC 9455 Section
4 myself before forming a view. Its actual text is:

>    Unless the CA has good reasons to the contrary, an issued ROA
>    SHOULD contain a single IP prefix.

That's a SHOULD with a built-in exception clause, not a flat MUST, which
leaves me reading this a little differently than Roman does. Section 5.8's
two bullets (fate-sharing not a concern; operational impact outweighs the
risk) look to me like a reasonable elaboration of what "good reasons" looks
like in practice, rather than a contradiction of RFC 9455 -- so I'd lean
toward handling this one at COMMENT level rather than DISCUSS, though I
understand if Roman sees it differently. Where I do think the document falls
short is that it never actually says it's operating inside RFC 9455's own
exception -- it presents its own "provided" conditions as freestanding,
which is likely exactly what invited this reading as a conflict. A sentence
tying the two together explicitly ("the following are the kind of good
reasons to the contrary contemplated by RFC 9455 Section 4") would remove
the ambiguity.

---

Section 5.1:

455 5.1.  Same Origin URIs
456
457   Publication service operators need to be aware of the normative
458   updates to [RFC8182] specified in Section 3.1 of [RFC9674].  In
459   short, these updates mean that all RRDP delta and snapshot resources
460   need have the same origin, i.e., HTTP redirects or references to
461   resources with a different origin compared to the referring RRDP
462   SubjectInfoAccess AccessDescription are not allowed and not followed
463   by RPs.

Patrik Fältström (ARTART) and Mark Nottingham (HTTPDIR) independently landed
on the same gap: neither RFC 9674 nor this document says how "same origin"
is actually determined at the string level -- case-sensitivity of host,
default-port substitution, percent-encoding in reg-names. Nottingham's
suggestion to point implementers at RFC 9110 Section 4.3.1 (which does
define exactly this comparison) seems like the cheapest fix, though as
Fältström said, a self-contained rule works too.

---

Section 3.4:

375   In addition to the above, the publishing CA MAY perform regular
376   planned synchronisation events where it issues an [RFC8181] list
...
381   perspective.  Unfortunately, the publication protocol specified in
382   [RFC8181] has no adequate support for rate limiting or signaling
383   requests to CAs to backoff.  Therefore, publishers SHOULD NOT perform
384   this resynchronisation more frequently than once every 10 minutes,
385   unless otherwise agreed with the publication engine operator.

Tim Bruijnzeels agreed on-list that servers should be recommended to answer
overload with 429/503 plus Retry-After (RFC 6585 / RFC 9110 Section 10.2.3)
rather than leaving publishers to self-limit on trust, and drafted specific
replacement text saying so. That text isn't in -11 -- the paragraph above is
unchanged from what HTTPDIR originally reviewed. I assume this was simply
missed when carrying the agreed fix.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 1, introductory diagram:

105   The following diagram attempt to convey how the components mentioned
s/attempt/attempts/

Section 1, diagram (lines 109-142): Behcet Sarikaya (GENART) noted this
figure has no caption; still true in -11.

Section 5.1:

460   short, these updates mean that all RRDP delta and snapshot resources
461   need have the same origin, i.e., HTTP redirects or references to
s/need have/need to have/

Section 5.3:

508   transferred data by approximately 50%. RRDP endpoints SHOULD support
509   compression through proactive content negotiation (see Section 12.1
510   of [RFC9110]).  At a minimum, gzip content coding (see
511   Section 8.4.1.3 of [RFC9110]) SHOULD be supported Additionally,
512   servers are RECOMMENDED to support other widely used compression
s/SHOULD be supported Additionally,/SHOULD be supported.  Additionally,/

[Ballot comment]
# Gorry Fairhurst WIT AD comments

I was planning to raise a DISCUSS on the issue raised by Roman Danyliw on the addition to the boilerplate for a BCP provided in section 2.1. I really think if this is a BCP, then it needs to use the language defined in RFC 2119 and carefully consider each requirement based on interoperability. I support Roman's DISCUSS Position.

Thank you for the work that has been put into this document.

These are non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education), please do consider these when resolving the related DISCUSS position.

I hope that this review helps to improve the document,

Regards,
Gorry


---

/It is RECOMMENDED to monitor the availability and latency of publication engines/. The recommendation is fair enough, but if this is a requirement to consider, what is the outcome of monitoring? Is it logged? Is some action required?

/maintenance windows SHOULD be planned and communicated to publishers./ This may be good advice, but how is the RFC 2119 requirement to be confirmed in an implemented system and explain what the consequence is for not following this advice?

/Therefore, the publication engine operator SHOULD notify/ - please explain the consequence of not following this advice?

I am unsure what this means:
/  Furthermore, it is RECOMMENDED that DNSSEC is used in accordance with
  best current practices as described in [RFC9364]./
- Is this somehow trying to degrade/scope the recommendations of RFC9364, if not why isn't it required to follow the BCP's guidance? This seems to need either rewording or the addition of detail to explain.

Is the WG confident that this is not a /MUST/:
/  Repository operators SHOULD configure access control policies to protect their RRDP endpoints. /
- If it is a "SHOULD", please do explain when it is safe not to do this?

This seems to imply both monitoring and corrective action, but the text only refers to "monitoring", which is aid to be "closely monitoring" (I am also unsure what extra action "closely" implies):
/ publication service operator SHOULD attempt to prevent these issues
  by closely monitoring performance metrics/

/At a minimum, gzip content coding (see
  Section 8.4.1.3 of [RFC9110]) SHOULD be supported /
- What does "at a minimum" mean in this context of a requirement to support it, is this a /MUST at a minimum
support/ ? Or something else?

/As a result, when using a load-balancing setup, special care SHOULD
  be taken to ensure that RPs that make multiple subsequent requests
  receive content from the same node/
- I do not understand text that says "special care SHOULD be taken" and suggest this is wrong, please consider if this needs RFC-2119 language, and if so define the extra procedure needed!

/Alternatively, publication infrastructure SHOULD ensure a particular ordering of the visibility of the snapshot plus delta and notification file. /
- This seems too vague for a recommendation, please specify what ordering is needed or what way this the ordering is communicated, or consider not using RFC2119 language. (I see this text, which seems to be more explicit, is this possibly the RFC 2119 requirement: /All nodes should receive the new snapshot and delta files before any node receives the new notification file./

Presenting the folloiwng as a RFC2119 recommendation appears very strong to me, can the actual requirement (to not cache?) be made the formal requirement (or whatever was intended) rather than the use of network storage?
/Using network storage is NOT RECOMMENDED, because it may not benefit
  from this cache.  For example, when using NFS, the operating system
  might not be able to cache the directory listing(s) of the
  repository./

NiTs:
Publication Engine - please could you apply a consistent capitilisation?

[Ballot discuss]
** Framing of the requirements language

2.1.  Requirements Language
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in BCP
  14 [RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.

  |  Note that the key words are used to stress importance for
  |  operations; they are not required as a formal implementation
  |  requirement.

-- This document cannot cite RFC2119/RFC8174 guidance on key word interpretation, and then in the next paragraph redefine the meaning of these key words.  For example, RFC2119 defines a “MUST” statement as mandatory.  With the proposed text here, “MUST” is now defined as “important.”  If this editorial approach kept, perhaps the references to RFC2119/RFC8174 can be removed.

-- If these key words are only used to “stress importance”, what is the difference between a “MUST” and “SHOULD”?  Is one “important” and the other “really important”.

-- If there are not formal (normative) implementation (operational requirements) requirements implied, how can this be a BCP?

** These “MUST statements” are so vague that nearly anything would qualify as conformance making interoperability unclear.

-- Section 3.2: “While the publication engine only needs to be accessed by publishers, the repository content MUST be highly-available to any RP worldwide.”

-- Section 3.2: “For the aforementioned reasons, the publication engine MUST be highly-available.”

-- Section 3.3: “Publication service operators MUST aim to minimise data loss.”

-- Section 5.4: “Publication service operators MUST ensure that their RRDP servers are    highly available.”

** Section 5.8.

(a) Section 5.8, this document, “The practice of issuing ROAs with only a single prefix per ROA [RFC9455] can lead to many ROA objects being published by a given CA … In order to reduce bandwidth consumption and reduce the number of signatures, it is RECOMMENDED that issuing CAs cluster as many prefixes per ROA as possible …”

(b) Section 4, RFC9455, “Unless the CA has good reasons to the contrary, an issued ROA SHOULD contain a single IP prefix.”

Don’t these statements conflict in what is RECOMMENDED?  If not, what is the "good reason" (per RFC9455) this document is citing?

[Ballot comment]
Thank you to Behcet Sarikaya for the GENART review.

** Section 3.3.  This section describes a situation where a roll-back of sorts might occur and the “currently published ROAs no longer reflect the CA's intentions.”  Would that not have novel security implications that would benefit from further documentation?

** Section 6.3.
  It is RECOMMENDED to serve rsync repositories from local storage, so
  that the host operating system can optimally use its I/O cache.
  Using network storage is NOT RECOMMENDED, because it may not benefit
  from this cache.  For example, when using NFS, the operating system
  might not be able to cache the directory listing(s) of the
  repository.

Is the WG confident that this generic statement considers all of the nuances of the very diverse set of network storage options in the marketplace.  Host OS I/O cache management is but one of many considerations.

If the WG confident it should be specifying hardware configurations for RPKI?

** The document contains a number of “unqualified SHOULD statements” with unclear guidance on when the guidance would not apply.  These would benefit from review and clarity.

Except directorate reviews, no additional comments were received during IETF LC.

A revision is needed to implement the changes agreed with the various reviewers (artart, httpdir, etc.). Thank you.

Request for IETF Last Call review by HTTPDIR Completed: Ready with Issues. Reviewer: Mark Nottingham. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-09-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-publication-server-bcp@ietf.org, ggx@gigix.net, mohamed.boucadair@orange.com, sidrops-chairs@ietf.org, sidrops@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services) to Best Current Practice


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Best Practices for Operating Resource
Public Key Infrastructure (RPKI)
  Publication Services'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-09-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes best current practices for operating an RFC
  8181 (A Publication Protocol for the Resource Public Key
  Infrastructure (RPKI)) publication engine and its associated publicly
  accessible rsync (RFC 5781) and RPKI Repository Delta Protocol (RRDP)
  (RFC 8182) repositories.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-publication-server-bcp/



No IPR declarations have been submitted directly on this I-D.

AD review is adressed in -10.

There is a nit to be fixed (https://github.com/timbru/draft-sidrops-publication-server-bcp/issues/55) but no need to have a new rev simply for this.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-publication-server-bcp/

Title: Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services

Revision: draft-ietf-sidrops-publication-server-bcp-09

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    Working Group Last Call on the mailing list shows a broad support for this document. Some minor comments have been made during WGLC (revision -07), but have been addressed.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    This is not a protocol document. It is a Best Current Practice document on how to operate existing implementations.


# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    No further reviews needed.
   
6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any ops issue.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document requests to be published as Best Current Practice. BCP is the right intended status as the document includes operational guidance and current thoughts of the community on how to best operate a RPKI publication engine.
    Both the Datatracker and front page show the intended status. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits for revision -09 shows two warnings:
   
    1. There is 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.
    This refers to the FQDN "rpki.apnic.net" in section 9.1, which is not an example and not an HTTP server. This was discussed with the authors (see https://mailarchive.ietf.org/arch/msg/sidrops/7I0foe44Tkaw_4pLyKXC8nKMubk/).

    2. Found 'MUST not' in a paragraph of Section 8.5. A clear overlook that can be fixed in future revisions during publication process.


15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    There is no reference with restricted access. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    There are no DOWNREF references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    [I-D.ietf-sidrops-aspa-profile] is normative, however, the document is ready for WGLC, which should start in a couple of days. Other than that, no references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document does not change the status of any existing RFC. 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The IANA considerations section does not contain any action.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    There is no new registry requiring Expert Review created in this document.

# Document History

Document: https://datatracker.ietf.org/doc/draft-ietf-sidrops-publication-server-bcp/

Title: Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services

Revision: draft-ietf-sidrops-publication-server-bcp-09

Shepherd: Luigi Iannone (ggx@gigix.net)

Writeup Template: https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup



1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

    Working Group Last Call on the mailing list shows a broad support for this document. Some minor comments have been made during WGLC (revision -07), but have been addressed.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

    No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No one showed any form of discontent.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

    This is not a protocol document. It is a Best Current Practice document on how to operate existing implementations.


# Additional Reviews

5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.

    No further reviews needed.
   
6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    No formal review is required.

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

    This document does not contain a YANG Module.

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

    The document does not contain anything written in a formal language, hence, no validation and/or check has been performed.


# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

    The document is clearly written, needed, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?

    The document does not touch any ops issue.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

    This document requests to be published as Best Current Practice. BCP is the right intended status as the document includes operational guidance and current thoughts of the community on how to best operate a RPKI publication engine.
    Both the Datatracker and front page show the intended status. 

12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in BCP 79? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.

    All the co-authors, did state explicitly that they are not aware of any IPR related to this document. No one else did any IPR disclosure. 

13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.

    Each co-author is clearly willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the idnits tool is not enough; please review the "Content Guidelines" on authors.ietf.org. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)

    The idnits for revision -09 shows two warnings:
   
    1. There is 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.
    This refers to the FQDN "rpki.apnic.net" in section 9.1, which is not an example and not an HTTP server. This was discussed with the authors (see https://mailarchive.ietf.org/arch/msg/sidrops/7I0foe44Tkaw_4pLyKXC8nKMubk/).

    2. Found 'MUST not' in a paragraph of Section 8.5. A clear overlook that can be fixed in future revisions during publication process.


15. Should any informative references be normative or vice-versa? See the IESG Statement on Normative and Informative References.

    No reference should change type.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

    There is no reference with restricted access. 

17. Are there any normative downward references (see RFC 3967 and BCP 97) that are not already listed in the DOWNREF registry? If so, list them.

    There are no DOWNREF references.
s
18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?

    [I-D.ietf-sidrops-aspa-profile] is normative, however, the document is ready for WGLC, which should start in a couple of days. Other than that, no references are in unclear state or not ready.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

    This document does not change the status of any existing RFC. 

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

    The IANA considerations section does not contain any action.

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

    There is no new registry requiring Expert Review created in this document.