The following article proposes a possible organization for IRCnet. The first part focuses on a hierarchical management structure which divides IRCnet in easy comprehensible administrative units. Here are meta questions of the organization discussed. The second part focuses on the tasks which must be solved after a global IRC management framework has been established. In this section contents and urgent tasks will be discussed.

A major intention of a global IRC management framework is to give decision power to a representative board of IRC coordinators (BIC) which vote democratically on major IRC issues. This ensures a balance of power, and gives such a BIC the possibility to enforce its rules, which was one of the big shortcomings of the previous EBIC organization. Another issue is to avoid power concentration to single servers and thus avoid egocentric behavior of single administrators which finally lead to the EFNET split.

Normally IRC is running more or less without explicit intervention. Ideally such a management structure just rules exceptional conditions. That means if an exception occurs this management structure rules who is responsible or who needs to be involved to solve the problem.

Control Hierarchies in IRCnet

Administration Units

IRCnet Servers

Traditionally IRCnet servers are grouped around their top level domain (TLD). The "native" TLD of a IRCnet server builds the first level of the administration hierarchy. Operators collaborately deal with the daily administration issues, like the management of network problems, sanctions of abusive users or operators or the linkage of new TLD servers.

While IRCnet server operators normally coordinate daily administration issues ad hoc within their TLD, there are also rise global administration tasks, where several TLD may be involved. To solve such global tasks the next level in the administration hierarchy is needed.

Bodies

A body builds a geographical and/or net topological region which autonomously administrates its region user base. A body is sovereign in administration of its' region and decides about the connection of new servers and server linking within the body. Each body has a representative (coordinator) that is decided on within that body. The coordinator is member of the BIC and represents that body. A body coordinator act on the democratic decisions of all body server representatives, but should have the power to act autonomously where necessary.

A body has to qualify for a seat within the BIC. This qualification has to involve the real user base of a body. This will introduce a required minimal size for a body (w.r.t its user base) and reduce the number of seats within BIC.

A BODY consists of one or more top level domains (TLD's) that exceed 500 users average. If a TLD has less than 500 users, it may seek to join a BODY that is already formed or may form a new BODY with other TLD's (see table).

To participate all new connecting TLDs, each TLD is preassigned to a BODY: Every square kilometer on Earth is preassigned a "godfather"-BODY, even if there was no real activity there yet. Once there starts to be activity there, they will have automatic representation in the BIC by their "godfather"-BODY and if the area grows dramatically in user base, it can be split up as its own BODY [Cor]. Alternatively there is a provision for a "Misfit BODY" for servers which doesn't fit elsewhere, like large Internationally based ISP's [Lorry].

If a TLD within a BODY is not satisfied with it then they may leave that BODY and join another neighboring body if they feel they could be better represented there. If a TLD wishes to not join a BODY then that is acceptable and that TLD will simply not be represented.

The reason why less users are required for BODIES with more than one participating TLD is to encourage TLDs with a smaller user base to join a BODY. This should avoid domination of "small" TLDs by "big" TLDs with a huge user base in the same body.

To have a simple deciding factor which does not require permanent/complicated evaluation of statistics, the qualification feature should be the connected user base of the BODY to IRCnet (regardless of the server location where these users connect to IRCnet). Using the total user base of a body as qualification criterion has the advantage, that BODIES wouldn't compete for users to connect within their BODY to gain more influence within the BIC.