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. 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. 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. 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.1 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.2 Except where otherwise noted, a simple majority vote is needed to pass an issue. 4.3 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 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. Documentation regarding the desired optimum linking structure for servers, together with fall-back plans to be used in the event of predictable or common failures and other comments and useful information, shall be kept 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. 2. Servers must provide (via the ADMIN command) valid email addresses for each server administrator who is responsible for that server. 2.1 Thus, in agreement with (1), the email addresses must not point to an account which is not local, where local is understood to mean that the address given is either on the machine on which the server is run, or at the same physical site (eg. university) as that machine. 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 The modifications are made publicly available, preferrably via anonymous ftp. A copy of this must also be sent to the maintainer of the IRC server source code for review. 4.1.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.2 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.3 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. Server operators who are not also server administrators may be appointed at the discretion of the 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.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 local hosts (no off site hosts). 5.4.1 It is acceptable for server administrators of servers which the server in question connects to be operators 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. A majority vote of yes constitutes permission. Note that the personal charm of any potential off-site operator does constitute a good reason. The distance from the off-site operator to the server should be minimal. Outside of the normal routing region 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 that C/N lines for servers which no longer run are not left in an `active' state. 6.2 ensuring that all C/N lines for servers have passwords; 6.3 ensuring that O-lines are set up in such a way as to only allow connections that conform to previously mentioned restrictions; 6.4 (for non-hub servers) ensuring that world wide connectivity for clients is not allowed. Appropriate use of I-lines should (as a minimum) provide site wide access and further single site access as is appropriate in terms of network connectivity; 6.5 (for non-hub servers) ensuring that only server connections to/from hubs are allowed. 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. 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 a reasonable amount of time 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 good reasons for the breach, the administrators of servers which link to the offending server should co-operate 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 7 days if the offending operator rectifies the problem. If the problem is not rectified within 7 days 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 7 days 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. 9.3.1 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.2 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. Each hostmasked domain shall, by whatever means chosen internally by the members of that domain, appoint one person as primary co-ordinator for that site. By default this will be the administrator of the hub server for that site, but may be any recognised USBIC member from that site. 1.1 Each site will be represented on a regional board. The regions, seperated by mid-level boundaries, will then each elect a person to represent the best interests of that region to USBIC. 1.2 The primary co-ordinator for the US (routing coordinator) shall be appointed by vote of the USBIC membership. 2. The primary co-ordinator for each domain shall be the person to contact for all routine administrative details pertaining to that domain. 3. The primary co-ordinator 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. 3.1 He or she should be consulted in any decision to establish links or make other arrangements involving servers within the relevant domain. 3.2 He or she is empowered to direct and make decisions about how various servers and networks should link together to form the most sensible and efficient structure. 4. 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. 5. Since the primary co-ordinator for a domain is the central authority for information regarding the linking and structure of that domain, he or she shall be responsible for documenting that information as described earlier. The same applies for regions. ##### RULES FOR THE ESTABLISHMENT OF NEW IRC SERVERS ##### (This section of the OzBIC rules is based on the European Board of IRC Coordinators' (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 should send the candidate administrator a copy of the USBIC rules, to which the candidate must agree to abide if he or she is given links. 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. This should be done even if the candidate server administrator claims to be the system administrator at the site in question. If necessary, a phonecall should be used as a follow-up. Necessary situations include possibly forged email. 1.3 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) should mail all other members of USBIC, 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, should also be forwarded to the members of USBIC. 1.4 If the vote is successful, the links should be given. 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. If the new site wishes to run local test-servers, they then may only be connected to the server granted external links. (This avoids confusion about linking hierarchy). 3. If, after serving a probationary period, 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. 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). 4.1 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 which server (if any) should remain connected. 5. 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. 2.4 If there are any corrections to be made to the vote tally they must be made within 7 days 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 retrospectively. No member can be held to task for rules which did not exist at the time of any behaviour which is later ruled against.