USBIC - United States Board of IRC Co-ordinators 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, 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 MOTD. 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 MOTD. 4. Voting is not compulsory where there is a call for votes on an USBIC matter, however all USBIC members must have the opportunity to vote. 4.1 Everything possible must be done (including making long-distance telephone calls to vacationing USBIC members) to ensure that members have a chance to vote. 4.2 Except where otherwise noted, voting periods must last for a minimum of seven days, or until all USBIC members have voted. 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. 4.3 Except where otherwise noted, a simple majority vote is needed to pass an issue. 4.4 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. 4.4.1 Because they do not partake in the vote, this does not mean that they are not bound by the decision. Ample time will be given for them to comply. "Ample Time" will be decided at vote-taking time. 4.5 An USBIC member 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, for instance if they are going on vacation and do not wish to be disturbed. 5. There will be a MODERATED mailing list for USBIC members where all official USBIC related discussion will go. 5.1 The moderator of the USBIC mailing list will be elected by the members of USBIC. A new moderator may be appointed at any time by a vote of USBIC members. 5.2 Any rejected articles by the moderator will be returned to the sender with a short explanation why it was rejected. 6. There will be an active routing plan to provide an optimal structure for all servers. 6.1 This plan will provide 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.4 Information shall be made publically available together with the other information detailed above. ##### RULES FOR IRC SERVER ADMINISTRATORS AND OPERATORS ##### (This section of the USBIC rules 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 Server administrators must have written (email) system administrator approval to run the irc server. 2. Servers must provide (via the A: line) valid email addresses for each server administrator who is responsible for that server. 2.1 Email addresses for the server administrator must be on a local machine, and must not forward off-site. Exceptions will be made where the USBIC body has granted permission for non-local email addresses. 2.2 Email addresses listed which are aliases should give a list of the recipients whenever the mail server (ie sendmail) is presented with a valid EXPN command (from the SMTP protocol). 3. The only people who are allowed access to the server's configuration file are those who are recognised as the server administrators as defined above. 4. Modified source shall not be used unless it meets the following criteria: 4.1 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.2 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.2.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.3 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.4 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) under the following conditions: 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 circulate 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 a majority vote of the USBIC membership calls for it. 5.4 Server operators on a server must all connect from nearby hosts. (no out-of-region hosts). 5.4.1 It is acceptable for server administrators to have operator status on their up and down links as long as all parties involved are registered members of USBIC. This access should not be treated as a condition for the server to be accepted nor should it be considered as mandatory. 5.4.2 If there is a good reason for the existence of a non-local operator on a server, the administrator(s) of that server may petition the other members of USBIC for permission, by calling for a vote on the matter. The distance from the out-of-region operator to the server should be minimal. Outside of the country is unacceptable. 6. All server administrators are required to keep their server configuration files up to date. In this context, `up to date' means no longer than 24 hours after the administrator becomes aware of the need to change the configuration file, and no longer than one week in any case. This includes (but is not limited to) the following: 6.1 Ensuring they are running *the* most recent server version. A two week grace period will be given for servers to upgrade to the most stable latest server version. Old versions will not be tolerated. 6.1.1 Hub servers must upgrade to the most recent patch level within 24 hours. 6.2 Ensuring that C/N lines for servers which no longer run are not left in an `active' state. 6.3 Ensuring that all C/N lines for servers have passwords; 6.4 Ensuring that O-lines are set up in such a way as to only allow connections that conform to previously mentioned restrictions; 6.5 (for non-hub servers) With the appropriate use of I-lines, restrict access to your server to that server's immediate domain plus whatever currently used sites are closest. These I-lines will be revised as the need arises. 6.6 (for hub servers) ensuring that all links for leaf servers shall be "L: lined" (leaf-only) so to prevent leaf servers from routing traffic. 7. Administrators who remove their server from operation for some period of time are requested to inform people in advance by at least 24 hours (preferably more) so that appropriate measures can be taken to ensure there is minimum risk to the IRC network. Notification should be via the (to be formed) usbic mailing list, operlist, and alt.irc (for the users). It is suggested that the administrator in question put the information in their /MOTD. 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 any breaches of the above rules are not rectified within three days (four days if over a weekend) after the administrator has been asked to rectify them, the members of USBIC should be informed of the transgression. 8.2 Once the USBIC membership has been notified of the breach, if a server administrator found to be in breach of any of the above rules refuses to rectify the situation and cannot provide any any reasons which USBIC members find valid for the breach, the administrators of servers which link to the offending server should co-operate with US, and regional routing coordinators to ensure that all links for the offending server are commented out, and servers which need them have alternative links. 8.3 Links which have been commented out may be reinstated within 1 week if the offending operator rectifies the problem. If the problem is not rectified within 1 week links to the offending server should be removed entirely. 8.3.1 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. 9. Server administrators must not allow their server to be used for the interception of or tampering with of any network traffic, unless they have the appropriate legal permissions to do so. 9.1 If such permissions do exist the administrator(s) of the server being used to intercept or tamper with traffic must (unless specifically prohibited from doing so by the appropriate legal authorities) provide the administrators of all servers which link to his or her server with a copy of the documents giving that permission. 9.1.1 Administrators who have been made aware of the existence of any such permissions must treat that knowledge as confidential. 9.2 Any server operator who becomes aware of any use of an IRC server to intercept or tamper with network traffic must take the following actions: 9.2.1 inform the administrator(s) of the server involved of his or her suspicions, and provide the administrator(s) with copies of any evidence that has been found. 9.2.2 inform the administrators of those servers which connect to the suspect server of his or her suspicions, and provide the administrators with copies of any evidence that has been found. 9.3 Administrators of servers who are informed that a server for which they have links is suspected of using that server to intercept or tamper with network traffic should take the following actions: 9.3.1 If the administrator is aware of any relevant permissions having been granted, the person who has brought their suspicions to the knowledge of the administrator should be told of this. 9.3.2 If the administrator is not aware of any relevant permissions, he or she should cooperate with any other servers which link to the suspect server to ensure that all links for the offending server are commented out, and that servers which need them have alternative links, and should then inform all other members of USBIC of the reason for the quarantine. 9.3.3 If, within 1 week of links for the suspect server being commented out, the administrator(s) of the server are unable to produce proof of any permissions allowing him or her to intercept or tamper with network traffic, links for that server should be permanently cut. Proof of permission includes: a warrant or court order, a written request from the computing center. Other justifications might be permitted. They will be dealt with on a case-by-case basis. 9.3.4 If there is more than one server administrator at the suspect site, and it can be shown that only one knew about and was responsible for the illegal interception of or tampering with of network traffic, then the offending server administrator should be removed from his or her position, the server should be recompiled, and links to the server should be reinstated. 9.3.5 A server administrator who has lost his or her links after breaching rule 9 may not apply to have links reinstated, however application may be made to establish a server at the same site with different server administrator(s). 9.4 Administrators who, through the normal course of debugging or maintaining the server, capture traffic not explicitly destined for them will not be considered to be in breach of rule 9, but must keep the contents of that traffic strictly confidential, and destroy any information not directly related to their administrative task. ##### RULES FOR CO-ORDINATING SIMPLE DECISIONS, ##### ##### AND AVOIDING UN-NECESSARY VOTING ##### (This section of the USBIC rules was based on the OzBIC Rules was written by Daniel Carosone (danielce@ee.mu.oz.au)) 1. This position is intended to simplify the process of implementing common-sense decisions without needing to invoke the entire voting mechanism of USBIC, as well as to provide a single person to handle simple day-to-day matters with the minimum of fuss. Any decision made by the primary co-ordinator of a domain may be questioned at any time by an USBIC member, and if necessary challenged by a vote. 2. Each hostmasked domain shall, by whatever means chosen internally by the members of that domain, appoint one person as the main contact for that site. 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 Each site will be represented on a regional board. The regions will be defined in the routing plan, and the number will be determined later. The USBIC members of each region will then elect a person to represent the best interests of that region to USBIC. 2.2 The primary routing co-ordinator for the US shall be appointed by vote of the USBIC membership. He/She will work in conjunction with the information provided by regional routing co-ordinators to maintain and modify the routing plan as necessary. 2.3 Someone may not be regional co-ordinator for more than one region. However, a person may be a regional co-ordinator and a primary co-ordinator if the vote favors it. 2.4 All routing co-ordinators may be removed from their position if the region votes in favor of a new co-ordinator. 3. The main contact for each domain shall be the person to contact for all routine administrative details pertaining to that domain. 4. The main contact of each domain is responsible for organizing and maintaining such things as routing within the domain, and all external links to/from servers in that domain. 4.1 The main contact should consult with the regional co-ordinator when making arrangements involving other servers in the region. 5. The regional co-ordinator is empowered to direct and make decisions about how various servers and networks should link together to form the most sensible and efficient regional structure. 5.1 Except in cases where the changes will constitute a change in the overall routing plan for the US. In which case, the primary routing co-ordinator must be consulted. 6. All changes in domain, regional, or national level routing will be documented by the relevant co-ordinators. ##### RULES FOR THE ESTABLISHMENT OF NEW IRC SERVERS ##### (This section of the OzBIC rules is based on the European Board of IRC Co-ordinators' (EBIC) "RULES FOR ESTABLISHING NEW IRC SERVERS IN EUROPE". Modifications by Elizabeth M. Reid (emr@ee.mu.oz.au)). In turn, it has been modified for USBIC by Helen Rose (hrose@eff.org). 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 giving reasons (eg. number of users at the proposed site) 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, and asking for confirmation of his or her permission to run the 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 phonecall 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 permission from the system administrator at the proposed new site has been given, the potential uplink administrator(s) must mail all other members of USBIC, via the moderated USBIC mailing list, stating the reasons why a new server should be established, and calling for a vote on the matter. Copies of the candidate administrator's agreement to abide by USBIC rules, and of the system administrator's permission to run an IRC server, must also be forwarded to the members of USBIC. 1.5 If the vote is successful, the primary routing co-ordinator will classify the new server into a region, and the regional routing co-ordinator will find the best place(s)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. New servers must serve a probationary period, any condition of which can be ended if a majority of USBIC members agree to it. Probationary conditions are: 2.1 New servers should be leafed until their administrator(s) have sufficient experience to handle their server responsibly. (This avoids routing disasters). 2.2 A link for only ONE server should be given to the new server site. 2.3 At the end of two weeks the probationary period is automatically ended. The server may now be fully implemented in any routing decided upon by the regional routing co-ordinator. 2.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. 3. 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. Server administrators should arrange these changes amongst themselves, and inform the USBIC members of the change. 4. If administration of a current server changes, the server will will have to undergo a new probationary period. 5. Server administrators must ensure that if a domain hostmask link is given, all servers of that domain can connect to the masked server. (this should avoid disagreement between several hub administrators in one domain). 6. Where there is more than 1 server running at an organization and due to whatever circumstances they are not able to be connected to each other a vote should be taken by USBIC members to decide if either server is necessary. 6.1 Where there is more than one server running on hosts within the same domain a host mask should be used whenever a server forms a connection with an IRC server external to that organisation. ##### RULES FOR EFFECTING CHANGES TO THE USBIC RULES ##### (This section was written by Elizabeth M. Reid (emr@ee.mu.oz.au) and is based on the rules for creating new Usenet newsgroups written by Gene Spafford) Again, modified by hrose@eff.org 1. Any USBIC member may propose a change to the USBIC rules by informing all other members of the proposal. 2. Changes to USBIC rules may be effected as follows: 2.1 Proposed changes must be posted to all USBIC members, and a discussion period of at least two weeks must pass before a vote can be called. 2.2 After a 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. 2.3 At the end 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. The moderated USBIC list, mentioned above, will be used for the purpose of tallying votes. The moderator of the USBIC mailing list will do the tallying and announce the results in a timely fashion. 2.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. 2.5 If, after corrections, there is a 2/3 (two thirds) majority in favour of the change to the USBIC rules, the person who called the vote may change the USBIC rules, and distribute the new set of rules to all members of USBIC, to alt.irc, and to all the FTP sites which carry the rules. 3. Rules cannot be applied retroactively. No member can be held to task for rules which did not exist at the time of any behaviour which is later ruled against. 4. Rules 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. OBVIOUS CHANGES FROM DRAFT #1: Voting Procedures for adoption of USBIC 1. Voting will be limited to the servers on the "list of servers" posted to alt.irc and to the ftp site h.ece.uiuc.edu:/irc/servers.930301 2. Each server gets one vote. Servers at a site run by the same admin and/or servers that link together get one vote. (e.g. csa.bu.edu and csd.bu.edu are run by the same admin) Servers behind a hostmask get one vote. 3. Each *admin* gets one vote. Even if the admin controls multiple servers at multiple sites. 4. Only USBIC members can vote. Organization of USBIC 1. USBIC will have a council of members. This allows busy administrators not to have to be part of day-to-day decisions, yet allows all areas of the country to have a say. 1.1 The council will be made up of regional co-ordinators. The regions they represent will be determined along with the accepted routing plan. 1.1.1 Each region shall elect its own representative to the USBIC council. They shall form their own voting procedure at the local level. 1.1.2 Each region will have veto power over the USBIC council 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. But the local people must have 80% approval of the /admins of the region for a veto.