Claudio Jeker <[email protected]> wrote: > On Thu, Nov 25, 2021 at 08:18:10PM +0100, Sebastian Benoit wrote: > > Job Snijders([email protected]) on 2021.11.25 16:13:51 +0000: > > > 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 > > > repositories. > > > > > > This flag perhaps permits us to start shipping with a more conservative > > > default than 1000, like 100 or 200. It is clear that encouraging the > > > ecosystem to embrace 'Publish in Parent' is a saner model than everyone > > > running their own delegation. > > > > > > Thoughts? > > > > Yes, if we dont have these configurable, we will have users running into > > them eventually and be sad. > > I'm not a big fan of this config option. This is for sure not something > that needs to change between runs and abusing it for the -m 1 case seems > strange. > Will we end up with a option salad for each and every limit? I think this > is a bad direction. rpki-client should just work and the limits need to be > chosen with that in mind.
I think the button pushers will abuse these options and create bad outcomes. 1. they will filter less. 2. they will encounter weird behaviours, and then not mention that they are using these options in reports, because that's the state of the art practice "the option is there for me to use, why would i need to say I am using it". This makes everyone angry. 3. it will be very difficult to document the outcomes. 4. also, difficult to pick sane ranges for the options. The initial idea was to set this to 1? Great, I'll run it with 1 everywhere today! I think the designers of this software can come up with sane defaults which 99% of the world should use, and the 1% that remain can re-compile the software. If we find evidence the number of poeple needing changes to these defaults is greater than 1% of the community, then we can discuss changing a specific default to a new position which once again satisfies the maximum number of people. There are huge benefits to having a userbase running with the same choices. I don't see evidence that throw that away, by giving them options which encourage fragmented usage patterns.
