I don't agree with any of these reasons.
These limits have been considered carefully. At this time, there is no
known justification for someone in the 'network admin' role to change
any of them.
We do not know what a future 'emergency' would look like, but I doubt it
would look like "oh I know,
Claudio Jeker wrote:
> On Thu, Nov 25, 2021 at 08:18:10PM +0100, Sebastian Benoit wrote:
> > Job Snijders(j...@openbsd.org) on 2021.11.25 16:13:51 +:
> > > It might be advantageous to permit operators to optionally specify the
> > > maximum number of publication points with which rpki-client
On Thu, Nov 25, 2021 at 08:18:10PM +0100, Sebastian Benoit wrote:
> Job Snijders(j...@openbsd.org) on 2021.11.25 16:13:51 +:
> > It might be advantageous to permit operators to optionally specify the
> > maximum number of publication points with which rpki-client will
> > synchronize.
> >
> >
Job Snijders(j...@openbsd.org) on 2021.11.25 16:13:51 +:
> It might be advantageous to permit operators to optionally specify the
> maximum number of publication points with which rpki-client will
> synchronize.
>
> For example: "doas rpki-client -m 1 -t /etc/rpki/ripe.tal" has as effect
> tha
It might be advantageous to permit operators to optionally specify the
maximum number of publication points with which rpki-client will
synchronize.
For example: "doas rpki-client -m 1 -t /etc/rpki/ripe.tal" has as effect
that only RIPE NCC's repository is contacted, but none of the delegated
repo
