💾 Archived View for spam.works › mirrors › textfiles › internet › usbic captured on 2023-11-14 at 10:26:50.
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
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.