Re: [Sidrops] [WG ADOPTION] Adoption call: draft-timbru-sidrops-publication-server-bcp - ENDS 02/08/2024

[Job Snijders <[e-mail]>]

On Tue, Feb 06, 2024 at 10:57:22AM +0100, Tim Bruijnzeels wrote:
> Job, thank you for your feedback. I will go over some of your other
> points later, but wanted to respond to this point now:
> 
> > On Feb 5, 2024, at 22:03, Job Snijders <job=[e-mail]> wrote:
> > 
> > - Section 6 could perhaps (in addition to the phrase 'consistent')
> >  describe the desired outcome using the phrase 'atomic'. I think within
> >  our community we often describe the cause of 'failed fetches' as the
> >  repository being updated in a non-atomic fashion. 
> 
> This section is really about having a consistent, unchanging, view in
> rsync.
> 
> There is another, related, issue though that CAs need to publish all
> their content in a consistent way, using a multi-element RFC 8181
> publication, to ensure that their Manifest, CRL and all signed
> certificates and RPKI objects are published atomically. I thought of
> including some text on this, but technically it’s a BCP for a CA,
> rather than a Publication Server. I don’t mind extending this document
> with CA concerns, but if preferred we could consider having a separate
> BCP for CAs.

I think you are right to focus the draft BCP at hand on just the
publication side of the house, but I was getting at this: 

The "Publisher" must signal updates in an atomic fashion using
multi-element RFC 8181, and additionally, the Publication Point must
signal updates in an atomic fashion (be it rsync symlink pivoting, or
grouping the RFC 8181 multi-element publication in a single RRDP delta).

E.g. the publication point must not unravel the publisher's atomicity.

Kind regards,

Job