Approval for merges?

[travisbgreen]

Team, do we have any strong feelings about the process for approving merges that document existing ranges? I've just been sending them through.

[jasonish]

No issues from me if not overlapping and not excessively huge.

But I guess we should come up with some guidelines for brand new allocations:

• How large? 100k doesn't seem like a lot anymore.
• What number should they start at.
• How would an company with a large internal range get an allocation, especially if they don't want to get listed? Or should that not be an option?

[zoomequipd]

How large? 100k doesn't seem like a lot anymore.

ET passed 80k rules in 2021, I'm guessing we'll pass 100k in 2022, it's taken us a long time to get there.

However, I do think that automation and large "blocklist" style are pushing WAY more than 100k - abuse.ch is a good example of this.

Maybe we carve out some space for "large ranges" akin to issuing a /8 in IPv4 terms.
another range can be used for a bunch of smaller 10k ranges for those that don't need more than 100k.

How would an company with a large internal range get an allocation, especially if they don't want to get listed? Or should that not be an option?

This IMO, shouldn't happen. If someone is producing rules that are not being distributed, they should be using the "local use" range.

[zoomequipd]

So long as PRs are for the sake of documenting existing ranges, I'm fine with PRs and sending them through.

My initial thought is to have the working group take a phased approach.
Phase 1: Documentation
Phase 2: Conflict Resolution
Phase 3: Allocation

After a period of time to allow existing documentation to occur, we can start to "manage" it, first working to resolve existing conflicts, and finally be issuing new ranges as people request them.

[travisbgreen]

I put branch protection on gh-pages to require pull requests for merge and 1 approval. Seemed the right thing to do since we're past the Documentation phase.