The Kitchen Sink Proposal

RIPE address policy is not described by any single, consistent body of text. The current stack works because we are incredibly nice people and because the RIPE NCC absorbs the ambiguity. That is not a stable arrangement but an undocumented dependency, and it is one this working group can no longer afford. The population that sustains our consensus process has shrunk by a factor of three over the past decade, while the same definitional gaps keep resurfacing as full proposal cycles, multi-month threads and NCC feedback rounds.

This is the fourth talk in a series (Why-PI at RIPE 82, Why-PI Redux at RIPE 88, Simplifying Assignment Status at RIPE 89).

This time it comes with a concrete, evolutionary path rather than a diagnosis:
1. an indexed manual that initially just points at the current documents;
2. a definitions chapter pulled, aggregated and deconflicted from the stack;
3. principles
4. per-resource chapters re-homed one at a time, verbatim, starting with the already-consolidated transfer policy. One chapter per proposal.

Any database-shaped material is explicitly parked until the definitional layer is in force and a joint scope with the Database WG exists.

The talk presents the inconsistency inventory, the participation numbers, the phased plan, and a proposal to charter a small task force, in the mould of the DB Task Force, as editor of record.

I would like the working group to look at a picture of a new kitchen before we call the plumber again.