United States Board of IRC Co-ordinators Charter (last revision: 8 April 1993) Preamble On this day of April 7th 1993, the United States Internet Relay Chat Administrators, believing that irresponsibility, neglect, and rivalry are the causes of a bad network have framed, constituted, and drafted this charter to enact such just and equal guidelines, policies, and offices that were thought for the improvement of the IRC network within the United States. Article I ##### General Policies ##### This document was based upon the one created for OzBIC -- written by Elizabeth Reid (emr@ee.mu.oz.au). 1. All administrators and operators of servers within the USA connected to any USBIC server shall be members of USBIC, and abide by the USBIC rules. 2. The names, email address(es), and server affiliation of all USBIC members should be freely available for FTP. 2.1 All server administrators who are able to make such a list available for FTP must do so, and must advertise its availability in their server's Message of the Day. 3. The USBIC rules should be freely available for FTP. 3.1 All server administrators who are able to make the rules available for FTP must do so, and must advertise its availability in their server's Message of the Day. 4. There will be a moderated mailing list for USBIC members where all official USBIC related discussion and notification will take place. 4.1 The moderator of the USBIC mailing list will be elected by the voting body of USBIC. A new moderator may be appointed by a new person being elected by the voting body of USBIC. 4.2 Any rejected articles by the moderator will be returned to the sender with a short explanation why it was rejected, and a notice will be sent to the mailing list stating it was rejected. 4.2.1 The rejected articles will be archived separately and will be available for review. 4.3 The moderator will be responsible for archiving all USBIC traffic. 5. Voting is not compulsory where there is a call for votes on an USBIC matter, however all of the USBIC voting body must have the opportunity to vote. 5.1 A call for votes will be made on the USBIC mailing list with the issue, All individual votes will be sent to the moderator of the USBIC mailing list. 5.1.1 Unless otherwise specified, the voting period is one week, or until all of the USBIC voting body has voted. 5.2 Everything possible must be done by the moderator of the USBIC mailing list to ensure that members have a chance to vote. 5.3 At the conclusion of the voting period the vote taker must post the vote tally and the E-mail addresses and names of the voters, indicating whether they voted yes or no, to all the members of USBIC. 5.3.1 Except where otherwise noted, a minimum of over 50% of the voting body is required to vote for a vote to be tallied. 5.3.2 In the case of an issue vote, except where otherwise noted, a simple majority `yes' vote of over 50% of the people who vote is needed to pass an issue. 5.3.3 In the case of an election, except where otherwise noted, the person with the most votes will be elected. 5.4 If there are any corrections to be made to the vote tally they must be made within 1 week of it being posted. Any corrections must be taken to account when calculating the final vote tally. 5.5 Once a matter has been decided by a vote, all members shall accept that decision, and co-operate in any manner necessary to implement any consequences of that decision, regardless of their own feelings or vote. 5.5.1 All members not partaking in the vote are still bound by the decision. Ample time will be given for USBIC members to comply with the voting results. "Ample Time" will be decided at vote-taking time. 5.6 A member of the USBIC voting body may indicate that they do not wish to partake in USBIC discussions or voting for a specified period by notifying the other members of USBIC 5.7 Once a topic has been voted upon, it may not be revoted upon until three weeks after the last vote. 6. There will be an active routing plan to provide an optimal structure for a national server backbone. 6.1 This plan will have adequate backup links that will provide for major network failures. 6.2 Procedures for where and when dynamic routing changes should be made will also be mentioned in the above plan. 6.3 New plans can be implemented once a new plan is proposed, voted on, and accepted by the USBIC members. 6.3.1 None of Article II will be in effect while there is no adopted routing plan. 6.4 Routing information shall be made publically available together with the other information detailed above. 6.5 Proposed routing plans will be voted on. 6.5.1 The vote will require a 2/3 (66%) majority to pass. Any non-votes will be counted as `no' votes. 7. Exceptions may be made for any USBIC rule by a vote of the USBIC voting body. 7.1 Exceptions will not be made if the rule explicitly forbids it. 7.2 Non-votes will count as `no' votes. Article II ##### RULES FOR IRC SERVER ADMINISTRATORS AND OPERATORS ##### (This section of the USBIC charter is based on the OzBIC rules written by Darren Reed (avalon@coombs.anu.edu.au) and Elizabeth M. Reid (emr@ee.mu.oz.au)) 1. All server administrators must have an account on the machine which is running the IRC server software. 1.1 The system administrator must be made aware of the irc server running machine via email from the USBIC moderator and not object. 2. Servers must provide, via the A-line, valid email address(es) where the server administrator(s) who is responsible for that server can be reached. 3. The only people who are allowed access to the server's configuration file are those who are recognized as the server administrators as defined above, and server administrators at that site. 4. Modified source shall not be used unless it meets all of the following criteria: 4.1 It is an sanctioned release by the IRC server source coder(s) 4.2 It is not a test or experimental server. Test and/or experimental servers have no place on the main net until they are no longer tests and/or experiments. 4.3 The modifications are made publicly available, preferably via anonymous ftp. A copy of this must also be sent to the maintainer of the IRC server source code for review. 4.3.1 The place of availability must be easily reachable by all members of the internet (ie firewalled public anonymous ftp sites are not acceptable). 4.4 The server while running must clearly indicate by way of the patchlevel the modifications/origins of the modifications. Failure to do this contravenes the GNU Public License under which the IRC server is registered. 4.5 If any server administrator is aware of a server running code which does not conform to the above rules he or she is required to inform all members of USBIC. 5. Additional IRC operators may be appointed at the discretion of the server administrator(s). 5.1 Operators must be sent a copy of the USBIC rules, and must indicate their compliance with them before being given an O-line. 5.2 Server administrators must notify the members of USBIC of any new operators on their servers, and must supply copies of that new operator's letter of agreement to abide by USBIC rules. 5.2.1 The O-line for the operator may not be activated until a one-week period from when the USBIC members were notified has passed. 5.3 An operator's O-line must be removed by the relevant server administrator(s) if there is a successful vote by the USBIC voting body. 5.4 Server operators on a server must connect from hosts that are in the same region as the server. 6. All server administrators are required to keep their server and configuration files current no longer than 24 hours after the administrator becomes aware of the need to change the configuration file. 6.1 The most recent server version possible must be running. A two week grace period will be given for servers to upgrade to the most latest stable server version. 6.1.1 Backbone servers must upgrade to the most recent patch level possible within 24 hours. 6.1.2 Non-backbone servers must upgrade to the most recent patch level possible within 72 hours (4 days if over a weekend). 6.2 C/N lines for servers which no longer run shall not be left in an `active' state in the configuration file. 6.3 All C/N lines for servers will have passwords. 6.4 All O-lines should be set up to only allow connections that are known to all USBIC members. 6.5 (for non-backbone servers) Use I-lines to only allow access to your server to sites that are designated by that servers regional co-ordinator. 6.5.1 The Regional Co-ordinator may designate a non-backbone server in their region to be a client-open server by not having site specific I-lines on the server. 6.6 (for backbone servers) ensuring that all links for leaf servers shall be L-lined so to prevent leaf servers from routing traffic. 7. Administrators who remove their server from operation for more than an hour are requested to inform people in advance by at least 24 hours. 7.1 Notification should be via the, USBIC mailing list, operlist, and alt.irc. It is suggested that the administrator in question put the information in their Message of the Day if the outage is lengthy. 7.2 If outage unplanned the admin should notify USBIC members as soon as possible. 8. Servers or server administrators found to be in breach of any of the above rules should be asked to rectify the problem. 8.1 If the problem is not rectified within three days (four days if over a weekend) after the administrator has been notified, the members of USBIC should be informed of the transgression. 8.2 If a server administrator found to be in breach of any of the above rules refuses to rectify the situation, the administrators of servers which link to the offending server should co-operate with the US, and Regional Co-ordinators to ensure that all links for the offending server are commented out, and servers which need them have alternative links. 8.2.1 If a server's C/N lines are removed from use by a particular server then any O-lines granted to the operators from the remote server must also be removed. 8.3 Links which have been commented out may be reinstated within one week if the offending server rectifies the problem. 8.3.1 If the problem is not rectified within one week links to the offending server should be removed entirely. 8.3.2 Server administrators who have had their links cut after being found to have breached USBIC rules may apply to have their links reinstated by following the USBIC Rules for the Establishment of New Servers. Article III ##### RULES FOR CO-ORDINATING SIMPLE DECISIONS, ##### ##### AND AVOIDING UN-NECESSARY VOTING ##### (This section of the USBIC charter was based on the OzBIC Rules that was written by Daniel Carosone (danielce@ee.mu.oz.au)) 1. These positions are intended to simplify the process of implementing common-sense decisions without needing to invoke the entire voting mechanism of USBIC. 1.1 The decisions made by the positions can be overturned by a successful vote of the USBIC voting body. 2. The voting body of USBIC will consist of all of the Main Contacts for each site, the Regional Co-ordinators, and the U.S. Co-ordinator. 2.1 The Main Contact by default this will be the administrator of the main server for that site, but may be any recognized USBIC member from that site. 2.1.1 The Main Contact is responsible for all actions of the server(s) at that site. 2.1.2 The Main Contact will be the person to contact for routine administrative duties at that site. 2.1.3 The Main Contact shall maintain the routing of servers at that site. 2.1.4 The Main Contact should consult with the Regional Co-ordinator when making arrangements with other servers in that region. 2.1.5 The Main Contact should consult with the U.S. and Regional Co-ordinators when making arrangements involving other servers outside the region. 2.1.6 If the Main Contact will be unavailable for a limited length of time, a temporary Main Contact may be appointed from another USBIC member at that site for a maximum of three weeks. 2.2 The USBIC voting body of each region will then elect a person as Regional Co-ordinator. The regions will be defined in the adopted routing plan. 2.2.1 The Regional Co-ordinator will set up the linking of servers within their region in accordance with the adopted routing plan. 2.2.2 The Regional Co-ordinator will determine the most sensible and efficient routing structure of servers within his/her domain that are not specified in the routing plan. 2.2.3 The Regional Co-ordinator will determine where I-lines should be added or removed on servers in their region. 2.2.4 The Regional Co-ordinator should consult with the Main Contact(s) when making arrangements with server(s). 2.2.5 The Regional Co-ordinator should consult with the U.S. Co-ordinator and the Main Contacts of servers in question when making arrangements involving other servers outside the region. 2.2.6 All decisions made by the Regional Co-ordinator may be invalidated by a majority vote of the USBIC voting body, or the USBIC voting body in that region. 2.3 The USBIC voting body will elect a person as the U.S. Co-ordinator. 2.3.1 The U.S. Co-ordinator will set up the linking of the regions in accordance with the adopted routing plan. 2.3.1 The U.S. Co-ordinator will determine the regions to which new servers are assigned. 2.3.2 The U.S. Co-ordinator will determine where all out of the country links will be given. 2.3.3 The U.S. Co-ordinator should consult with the Regional Co-ordinator, the Main Contacts of servers in question, and BICs of other countries (where established) when making arrangements involving other servers outside of the country. 2.3.4 All decisions made by the U.S. Co-ordinator may be invalidated by a majority vote of the USBIC voting body. 2.4 Someone may not be regional co-ordinator for more than one region. 2.4.1 A person may be a Regional Co-ordinator and U.S. Co-ordinator if the vote favors it. 2.4.2 The moderator of the USBIC mailing list may not be the same as the U.S or a Regional Co-ordinator. 2.4.3 If a person holds more than one voting position, they only get one vote on a USBIC matter. 2.5 All Co-ordinators may be removed from their position if the voting members of the region votes in favor of a new Co-ordinator. 2.6 All permanent changes in site, regional, or national level routing will be documented by the relevant co-ordinators and sent to the USBIC mailing list. 2.6.1 There will be a one week period in between when routing changes to the backbone are documented, and when they are implemented. Article IV ##### RULES FOR THE ESTABLISHMENT OF NEW IRC SERVERS ##### (This section of the USBIC charter was based on the European Board of IRC Co-ordinators' (EBIC) "RULES FOR ESTABLISHING NEW IRC SERVERS IN EUROPE". And OzBIC Modifications by Elizabeth M. Reid (emr@ee.mu.oz.au)). 1. Establishment of a new server should be a local toplevel domain (country) decision. 1.1 Any person wishing to establish a new server should send email to the administrator(s) of the potential uplink server 1.1.1 The mail should give the reasons for the request, together with other relevant details about themselves, about the machine and network connectivity and so on. 1.2 The administrator(s) of the potential uplink server must send the candidate administrator a copy of the USBIC rules. 1.3 The potential uplink administrator(s) must also send email to the system administrator at the candidate site, informing him or her of the request for links for an IRC server. 1.3.1 This should be done even if the candidate system administrator claims to be the system administrator at the site in question. If necessary, a phone call should be used as a follow-up. Being listed as the NIC contact for the site is sufficient proof. 1.4 If the candidate agrees to abide by USBIC rules, and the system administrator at the proposed new site has been informed, the Main Contact of the uplink must mail the moderated USBIC mailing list about the new server. 1.4.1 The mail should state the reasons why a new server should be established, and calling for a vote on the matter. 1.4.2 Copies of the candidate administrator's agreement to abide by USBIC rules should be sent to the USBIC mailing list. 1.5 If the vote is successful, the U.S. Co-ordinator will classify the new server into a region, and the Regional Co-ordinator will find the best place to give links to the new server. 1.5.1 If the vote is unsuccessful, no petitions for a new server from that site will be allowed for three weeks. After which the server may re apply for the establishment of a new server. 2. Each region will have veto power on whether a new server in their region should be added or not. The idea is that only the local people know the impact of a local server or not. 2.1 All non-votes from that region are counted as `no' votes. 3. New servers must serve a probationary period of two weeks which can be ended earlier if a majority of USBIC members agree to it. 3.1 New servers should be L-lined until their administrator(s) have sufficient experience to handle their server responsibly to avoid routing disasters. 3.2 A link for only ONE server should be given to the new server site. 3.3 When the probationary period is over, the server may now be fully implemented in any routing decided upon by the Regional or U.S Co-ordinators. 3.3.1 If during the probationary period, complaints are raised to the new server, after two weeks a vote will be called on to decide if the probationary period should be extended for another two weeks. 4. If a server administrator wishes or needs to switch from running the server on one machine at a particular site to another machine at the same site, this does not constitute a new server, and does not require a vote. 4.1 The Main Contact of the site should arrange these changes and inform the USBIC members of the change. 5. If administration of a current server changes, the server will will have to undergo a new probationary period. 6. Server administrators must ensure that if a hostmasked link is given, all servers of that site can connect to the masked server. 7. When there is more than one server running at a site that aren't able to be connected to each other a vote should be taken by USBIC members to decide if either server is necessary. 7.1 Where there is more than one approved server running on hosts at the same site, a host mask should be used whenever a server forms a connection with an IRC server external to that site. Article V ##### RULES FOR EFFECTING CHANGES AND MAKING ###### ##### AMENDMENTS TO THE USBIC CHARTER ###### (This section of the USBIC charter was based on OzBIC by Elizabeth M. Reid (emr@ee.mu.oz.au) and is based on the rules for creating new Usenet newsgroups written by Gene Spafford) 1. Any USBIC member may propose a change or amendment to the USBIC charter by informing all other members of the proposal. 1.1 Proposed changes or amendments must mailed to the USBIC mailing list, and a discussion period of at least two weeks must pass before a vote can be called. 1.1.1 The discussion period can be lengthened by the proposer if he/she feels the need 1.2 After the minimum of two weeks have passed since the call for discussion, a call for votes may be issued. The voting period must last for at least two weeks and the time at which voting will close must be posted along with the call for votes. 1.3 The vote will require a 2/3 (66%) majority to pass. Any non-votes will be counted as `no' votes. 1.3.1 If the vote passes the USBIC charter will be revised to reflect the new changes or amendments, and a new copy of the charter will be sent to all members of USBIC, to alt.irc, and to all the FTP sites which carry USBIC. 3. Decisions cannot be applied retroactively. No member can be held to accountable for rules which did not exist at the time of any behavior which is later ruled against. 4. Decisions will be unilateral. All servers must comply with new rules which have been voted on, and passed. If server do not comply with the rules, proper procedures for servers breaking USBIC policies will be followed. Postamble In order to better serve the IRC community as a whole the IRC Adminstrators of the United States of America solomnly and mutually combine and accept this charter and base this system of co-operation with one another to maintain and improve the scope, performance, and security of the IRC network as a whole. Changes to original documents by Helen Rose (hrose@eff.org) and Alex Samonte (asamonte@hertz.elee.calpoly.edu). ------------------------------------------------------------------------------- End of Document Time Table 1. The USBIC charter is proposed. 2. The USBIC charter is voted upon. The vote will require a 2/3 (66%) majority of the server admins (1 vote per server) on the March 1st server list (1 vote per server) to pass. Any non-votes will be counted as `no' votes. 3. If the charter passes USBIC is formed. 4. Routing plans are proposed. 5. Routing plans are voted upon. 6. A routing plan is implemented. 7. Servers are changed to reflect the routing plan and USBIC server policies. 8. Amendments will be proposed and voted upon. Possible Amendments These amendments are my no means definite, but were discussed during USBIC discussion and didn't make it into the original charter. 1. A system for term limits which might address such things as: - Length of a term. - Which offices should have terms 2. A system for user voting which might address such things as: - Eligibility - Method of tallying votes - Weights for voting 3. A system for deciding on server operation requirements which might address such things as: - Userbase required - Routing considerations 4. A system for deciding on operator ettiquitte which might address such things as: - 'Good' and 'bad' users of operator commands. - Actions to take when rules are broken by operators