GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


archive:internet:usbic

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.
/data/webs/external/dokuwiki/data/pages/archive/internet/usbic.txt · Last modified: 2000/11/25 03:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki