And while both publish in parent and BGPSec in hosted RPKI are feature requests with the same "build and they will come" spirit, I believe publish in parent to be a low hanging fruit here.
That said, not being a resource holder in the RIPE region means I shouldn't try prioritizing the work of others... ;-) Rubens On Thu, Oct 7, 2021 at 11:31 AM Tim Bruijnzeels <[email protected]> wrote: > > Dear all, > > I would like to support this proposal. > > As an implementer of an open-source RPKI CA I find that a large part of the > support questions > that we get, and the hesitation to run a delegated CA, stems from the > requirement to not > just run a CA, which can even be offline between signing events, but a 24/7 > repository as > well. > > If this is added to the RIPE NCC RPKI backlog then I would also request that > LIRs, and PI > holders, can have multiple CAs publish at the RIPE NCC. The reason for this > is that one of > benefits of running a delegated CA lies in having the option to sub-delegate > to child CAs. > For example one can create child CAs with specific sub-sets of resources for > departments, > business units etc. To make this scale it would very beneficial if those > children could > publish under the publication server as well. > > Kind regards, > Tim > > > > On 20 Sep 2021, at 13:26, Job Snijders via routing-wg <[email protected]> > > wrote: > > > > Hi working group, > > > > In recent mail threads the concepts of "Hosted RPKI" and "Delegated > > RPKI" came up, but as mentioned by Tim and Rubens, another flavor also > > exists! A "hybrid" between Delegated and Hosted, informally known as > > "publish in parent" (aka RFC 8181 compliant Publication Services). > > > > There are multiple benefits to the general RPKI ecosystem when RIRs and > > NIRs support RFC 8181: > > > > * Resource Holders are relieved from the responsibility to operate > > always online RSYNC and RRDP servers. > > > > * Reducing the number of Publication servers reduces overall > > resource consumption for Relying Parties. Consolidation of > > Publication Servers improves efficiency and is generally > > considered advantageous. > > > > * Helps avoid "reinventing the wheel": it might be better to have a > > small group of experts build a globally performant and resillient > > infrastructure that serves everyone, rather than everyone building > > the 'same' infrastructure. > > > > Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is > > relatively new so it'll take some time before we see universal > > availability. > > > > NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/ > > APNIC (available): > > https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-parent-self-hosted-rpki/ > > ARIN (planned): > > https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/ > > > > Is implementing RFC 8181 support something RIPE NCC should add to the > > https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap > > ? > > > > What do others think? > > > > Kind regards, > > > > Job > > > > Relevant documentation: > > https://datatracker.ietf.org/doc/html/rfc8181 > > > >
