2446 lines
99 KiB
Plaintext
2446 lines
99 KiB
Plaintext
|
|
ISGNet Policy Document
|
|
|
|
Index
|
|
|
|
ADDITIONAL MAIL EVENTS IN LOCAL NETWORK 2.1.8
|
|
ADDRESS IN MESSAGE TO REQUEST NODE 2.2
|
|
ADMINISTRATIVE REGION 6.1
|
|
ADVANTAGES TO NETWORK MEMBERSHIP 2.2
|
|
ALTERATION OF MAIL 2.1.5
|
|
ANSWERING MACHINE 2.3
|
|
ANNOUNCEMENT OF VOTING RESULTS 8.2
|
|
ANNOYING BEHAVIOR 1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4, 2.1.6, 2.1.7, 2.1.8,
|
|
2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
|
|
APPEAL CHAIN 9.5
|
|
APPOINTMENT OF COORDINATORS 1.2.3, 1.2.4, 5.7, 6.1
|
|
AVAILABILITY OF NODELIST 1.3.4
|
|
BACKBONE OPERATING PROCEDURES 11
|
|
PURPOSE OF THIS DOCUMENT 11.0
|
|
ZONE ECHOMAIL COORDINATOR 11.2
|
|
ZONE ECHOLIST COORDINATOR 11.3
|
|
ZONE HUBS 11.4
|
|
REGION ECHOMAIL COORDINATORS 11.5
|
|
REGION HUBS 11.6
|
|
BACKBONE CONFERENCE MODERATORS 11.7
|
|
DUTIES OF MODERATORS 11.8
|
|
RECOGNITION OF MODERATORS 11.9
|
|
OPERATING PROCEDURES 11.10
|
|
ECHOMAIL MESSAGE STANDARDS 11.11
|
|
BANNED MESSAGES 11.12
|
|
CENSORSHIP 11.13
|
|
ADDING CONFERENCES TO THE BACKBONE 11.14
|
|
REMOVING CONFERENCES FROM THE BACKBONE 11.15
|
|
ECHOMAIL GATEWAYS 11.16
|
|
ROUTED NETMAIL 11.17
|
|
DISPUTE RESOLUTION 11.18
|
|
CHANGES TO THIS DOCUMENT 11.19
|
|
BALLOTING PERIOD 8.4
|
|
BOMBING RUN 4.2
|
|
BOSSNODE 1.2.1.2
|
|
BOUNDARIES 1.3.2
|
|
BUSINESS USE OF ISGNET 1.3.6
|
|
CALLING AREAS 1.3.2, 5.6, 5.7
|
|
CASE HISTORIES 9.10, 10.3
|
|
CHAIN OF COMMAND 1.2.8
|
|
CHANGING NODE NUMBERS 4.3, 5.2
|
|
CHECKS AND BALANCES 1.2.8
|
|
COMMERCIAL MESSAGES 1.3.6, 2.1.4, 4.2
|
|
COMPLAINT (POLICY) 2.1.6.1, 9
|
|
CONTRIBUTIONS TO INEWS 1.3.1
|
|
COST RECOVERY PLAN 12
|
|
OVERVIEW 12.0.0
|
|
PURPOSE 12.2.0.0
|
|
DEFINITIONS 12.3.0.0
|
|
ECHOMAIL 12.3.1.1
|
|
NATIONAL ECHOMAIL 12.3.1.2
|
|
REGIONAL ECHOMAIL 12.3.1.3
|
|
LOCAL ECHOMAIL 12.3.2.0
|
|
ORGANIZATION 12.4.0.0
|
|
ECHOMAIL COORDINATOR 12.4.1.0
|
|
ECHOMAIL 12.4.1.1
|
|
COST RECOVERY PLAN 12.4.1.2
|
|
SYSOPS 12.4.2.0
|
|
POINT OPERATORS/SYSTEMS 12.4.3.0
|
|
DISTRIBUTION OF ECHOMAIL 12.4.4.0
|
|
COST RECOVERY PLAN 15.5.0.0
|
|
PARTICIPATION 12.5.1.0
|
|
DOWNLINKS 12.5.1.1
|
|
POINT SYSTEMS 15.5.1.2
|
|
TIERS 12.5.1.3
|
|
BACKBONE ACCESS 12.5.1.4
|
|
COST RECOVERY PLAN FEES 12.5.2.0
|
|
PAYMENTS 12.5.2.1
|
|
NEW PARTICIPANTS 12.5.2.2
|
|
REIMBURSEMENTS 12.5.2.3
|
|
CHANGING TIERS 12.5.2.4
|
|
ENFORCEMENT OFECHOMAIL POLICY 12.6.0.0
|
|
FAILURE TO SUBMIT 12.6.1.0
|
|
NODES 12.6.1.1
|
|
POINTS 12.6.1.2
|
|
RECONNECTION 12.6.1.3
|
|
HABITUAL LATENESS 12.6.2.0
|
|
VIOLATION OF THIS POLICY 12.6.3.0
|
|
NODES PARTICIPATING 12.6.3.1
|
|
THE PASSING OF ECHOMAIL 12.6.3.2
|
|
CRP PAYMENTS REFUNDED. 12.6.3.3
|
|
APPEALS 12.6.4.0
|
|
SECURITY 12.7.0.0
|
|
ADOPTING AND AMENDING THIS POLICY 12.8.0.0
|
|
SUBMISSION 12.8.1.0
|
|
VOTING 12.8.2.0
|
|
VOTING FOR RATIFICATION 12.8.2.1
|
|
ONLY THE ISG NETWORK NODELISTED 12.8.2.2
|
|
VOTES WILL BE SUBMITTED BY EACH NODE, 12.8.2.3
|
|
VOTES 12.8.2.4
|
|
AMENDMENTS 12.8.3.0
|
|
ADDENDUM I 12.8.4.0
|
|
CURRENT NODELIST 2.1.11
|
|
DAYLIGHT SAVINGS TIME 2.1.14
|
|
DIFFERENCE FILE 4.5, 5.8, 8.2
|
|
DISCLOSING PRIVATE MAIL 2.1.6
|
|
DISCUSSION PERIOD 8.2
|
|
DISPUTES 9
|
|
DISTRIBUTION OF BALLOTS 8.2
|
|
DOWN 2.3, 4.4, 5.5
|
|
DOWNLOADING BY USERS 3.6, 4.5, 5.8
|
|
ECHOMAIL 4.2, 9.9
|
|
EFFECTIVE DATE (POLICY CHANGE) 8.2
|
|
ELECTION OF COORDINATORS 1.2.5, 6.2, 7.2
|
|
ELIGIBILITY TO VOTE 8.3
|
|
ENCRYPTION 2.1.4, 4.2
|
|
EXCEPTIONS 5.6
|
|
EXCESSIVELY ANNOYING BEHAVIOR 1.2.1.1, 1.3.5, 2.1.1, 2.1.2, 2.1.4, 2.1.6,
|
|
2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
|
|
EXCLUSIVITY OF ZONE MAIL HOUR 2.1.8
|
|
EXCOMMUNICATION 2.1.12, 4.3, 5.2, 9
|
|
EXEMPTIONS, NODE LOCATION 1.3.2, 5.6
|
|
FAMILIARITY WITH POLICY 2.1.2, 2.2
|
|
INEWS 1.3.1
|
|
AVAILABILITY 3.1, 4.5, 5.8
|
|
FTSC 2.1.8, 2.1.9, 2.4
|
|
GATEWAY 2.1.3
|
|
GEOGRAPHY 1.3.2, 5.6
|
|
GLUE 4.5
|
|
GUARANTEE OF MAIL DELIVERY 1.3.6
|
|
HATS 3.4
|
|
HOST-ROUTED MAIL 4.2
|
|
HOW TO OBTAIN A NODE NUMBER 2.2
|
|
HUB 1.2.3.1, 4.4
|
|
ILLEGAL BEHAVIOR 2.1.1, 9.6
|
|
ILLEGAL MAIL 4.2
|
|
IMPEACHMENT 8.7
|
|
IN-TRANSIT MAIL 2.1.6.1
|
|
INDEPENDENT NODE 4.2, 5.2
|
|
INTER-ZONAL QUESTIONS 1.2.6
|
|
INTERNATIONAL COORDINATOR 1.4.1, 1.4.9, 7
|
|
JUSTIFICATION OF PRIVATE NODES 2.1.9
|
|
LANGUAGE 1.0
|
|
LEVELS OF ISGNET 1.2, 1.4
|
|
LOCAL CALLING AREAS 1.3.2
|
|
LOCAL POLICIES 1.2, 3.3
|
|
MAIL 1.2.3, 4.2
|
|
MAILER 2.2
|
|
MAJORITY 8.6, 8.7.2
|
|
MEMBER OF AREA ADMINISTRATED 3.5
|
|
MODEM 2.2
|
|
MODIFICATION OF MAIL 2.1.5
|
|
NATIONAL MAIL HOUR SEE ZONE MAIL HOUR
|
|
NETWORK
|
|
ADVANTAGES 2.2
|
|
BOUNDARIES 1.3.2, 5.4
|
|
DEFINITION 1.2.3
|
|
FORMING 2.4, 5.3
|
|
HUB 1.2.3.1, 4.4
|
|
NUMBERS 2.2, 5.4
|
|
NETWORK COORDINATOR 1.2.3
|
|
PROCEDURES 4
|
|
REPLACEMENT 5.7, 9.3
|
|
NETWORK MAIL HOUR SEE ZONE MAIL HOUR
|
|
NEW SYSOPS 2.1.2, 3.6
|
|
NODE NUMBERS 4.3, 5.2
|
|
OBTAINING 2.2
|
|
NODELIST 1.3.4, 2.2, 4.4, 5.5
|
|
AVAILABILITY 3.1, 4.5, 5.8
|
|
CHANGES 4.4, 5.2
|
|
CURRENT 2.1.11
|
|
DEFINITION 1.3.4
|
|
FORMAT 10.3
|
|
OFFICIAL 1.3.4
|
|
NODES
|
|
DEFINITION 1.2.1
|
|
DOWN 2.3
|
|
OBSERVING MAIL EVENTS 2.1.8, 2.1.10
|
|
OBTAINING A NODE NUMBER 2.2
|
|
OFFENSIVE MESSAGES 2.1.5
|
|
ORDERS (COMMERCIAL) 1.3.6
|
|
PARTIAL NODELIST 1.3.4
|
|
PIRATED SOFTWARE 2.1.1
|
|
POINT OF ORIGIN 2.1.3
|
|
POINTS 1.2.1.2, 2.1.3
|
|
POLICY 3.1, 3.3, 4.5, 5.8
|
|
CHANGING 8
|
|
COMPLAINT 2.1.6.1, 9
|
|
FAMILIARITY WITH 2.1.2, 2.2
|
|
LOCAL 1.2, 3.3
|
|
PRECEDENT 3.7, 9.10, 10.3
|
|
PRIVATE MESSSAGES 2.1.6
|
|
PRIVATE NETWORK 1.2.1.2
|
|
PRIVATE NODES 2.1.9
|
|
PROBLEM RESOLUTION 9
|
|
PROTOCOL 2.1.8
|
|
PUBLIC BBS 3.6
|
|
RATIFICATION 7.1
|
|
REDUNDANT NODES 2.1.9
|
|
REFERENDUM 1.2.7, 8
|
|
REGIONAL COORDINATOR 1.2.4
|
|
PROCEDURES 5
|
|
REPLACEMENT 6.1, 9.4
|
|
REGIONS 1.2.4
|
|
REPLACEMENT OF COORDINATORS 1.2.8
|
|
REPLACING SERVICES 3.4
|
|
REQUIREMENTS TO BE IN NODELIST 1.3.4, 2.1.2, 2.2
|
|
RESIGNATION OF ZC 8.7.4
|
|
RESOLUTION OF DISPUTES 9
|
|
RESULTS ANNOUNCEMENT 8.2
|
|
REVIEW OF DECISIONS 3.7
|
|
REVIEW OF ROUTED TRAFFIC 2.1.4
|
|
ROUTING 2.1.4 - 2.1.7, 4.2
|
|
ROUTING HUB 1.2.3.1, 4.4
|
|
RULES 9.1
|
|
SPEEDY DECISION 9.7
|
|
STANDARDS (FTSC) 2.1.8, 2.4
|
|
STATUTE OF LIMITATIONS 9.6
|
|
SUBMISSIONS TO INEWS 1.3.1
|
|
SYSOP PROCEDURES 2
|
|
SYSTEM OPERATOR (SYSOP) 1.2.1
|
|
THREE-TIERED NETWORKS 1.2.3.1
|
|
TIME LIMIT ON DECISION 9.7
|
|
TIMING OF ZONE MAIL HOUR 2.1.13, 2.1.14, 10.2
|
|
TOP-DOWN 1.4.9
|
|
TRADITION 3.7
|
|
TRIVIAL NETWORK 5.3
|
|
UNATTENDED SYSTEMS 2.3
|
|
UPDATES TO NODELIST 3.2
|
|
USER 1.2.1.1
|
|
USER ACCESS DURING ZMH 2.1.8
|
|
VACATION 2.3
|
|
VOICE TELEPHONE NUMBER 2.2
|
|
VOTE 8
|
|
ELIGIBILITY 8.3, 8.7.2
|
|
ZMH SEE ZONE MAIL HOUR
|
|
ZONE COORDINATOR 1.2.5, 6
|
|
ELECTION 6.2
|
|
IMPEACHMENT 8.7
|
|
PROCEDURES 6
|
|
REMOVAL 6.2
|
|
RESIGNATION DURING IMPEACHMENT 8.7.4
|
|
ZONE COORDINATOR COUNCIL 1.2.6, 7.1
|
|
ZONE MAIL HOUR 1.3.3, 2.1.8
|
|
TIMING 2.1.13, 2.1.14, 10.2
|
|
ZONES 1.2.5, 1.3.2
|
|
|
|
ISGNet Policy Document
|
|
|
|
|
|
This policy document is the official NetWork policy for the INTERNATIONAL
|
|
SYSOP'S GUILD NETWORK known as ISGNet and is modeled after FidoNet's policy4.
|
|
|
|
This document superceded any other ISGNET POLICY document prior
|
|
to this date Dec 29, 1992
|
|
|
|
1 Overview
|
|
|
|
This document establishes the policy for sysops who are members of the
|
|
ISGNet organization of electronic bulletin board systems. ISGNet is
|
|
defined by a NodeList issued weekly by the International Coordinator.
|
|
|
|
Separate policy documents may be issued at the zone, region, or net level to
|
|
provide additional detail on local procedures. Ordinarily, these lower-level
|
|
policies may not contradict this policy. However, with the approval of the
|
|
International Coordinator, local policy can be used to implement differences
|
|
required due to local conditions. These local policies may not place
|
|
additional restrictions on members of ISGNet beyond those included in this
|
|
document, other than enforcement of local mail periods.
|
|
|
|
|
|
|
|
1.0 Language
|
|
|
|
The official language of ISGNet is English. All documents must exist in
|
|
English. Translation into other languages is encouraged.
|
|
|
|
|
|
1.1 Introduction
|
|
|
|
ISGNet is an amateur electronic mail system. As such, all of its partici-
|
|
pants and operators are unpaid volunteers. From its early beginning as a few
|
|
friends swapping messages back and forth (1984), it now (1989) includes over
|
|
5,000 systems on six continents.
|
|
|
|
ISGNet is not a common carrier or a value-added service network and is a
|
|
public network only in as much as the independent, constituent nodes may
|
|
individually provide public access to the network on their system.
|
|
|
|
ISGNet is large enough that it would quickly fall apart of its own weight
|
|
unless some sort of structure and control were imposed on it. Multinet
|
|
operation provides the structure. Decentralized management provides the
|
|
control. This document describes the procedures which have been developed to
|
|
manage the network.
|
|
|
|
|
|
1.2 Organization
|
|
|
|
ISGNet systems are grouped on several levels, and administration is decen-
|
|
tralized to correspond with these groupings. This overview provides a
|
|
summary of the structure; specific duties of the coordinator positions are
|
|
given later in the document.
|
|
|
|
1.2.1 Individual Systems and System Operators
|
|
|
|
The smallest subdivision of ISGNet is the individual system, corresponding
|
|
to a single entry in the nodelist. The system operator (sysop) formulates a
|
|
policy for running the board and dealing with users. The sysop must mesh
|
|
with the rest of the ISGNet system to send and receive mail, and the local
|
|
policy must be consistent with other levels of ISGNet.
|
|
|
|
1.2.1.1 Users
|
|
|
|
The sysop is responsible for the actions of any user when they affect the
|
|
rest of ISGNet. (If a user is annoying, the sysop is annoying.) Any
|
|
traffic entering ISGNet via a given node, if not from the sysop, is consid-
|
|
ered to be from a user and is the responsibility of the sysop. (See section
|
|
2.1.3.)
|
|
|
|
1.2.1.2 Points
|
|
|
|
A point is a ISGNet-compatible system that is not in the nodelist, but
|
|
communicates with ISGNet through a node referred to as a bossnode. A point
|
|
is generally regarded in the same manner as a user, for example, the bossnode
|
|
is responsible for mail from the point. (See section 2.1.3.) Points are
|
|
addressed by using the bossnode's nodelist address; for example, a point
|
|
system with a bossnode of 114/15 might be known as 114/15.12. Mail destined
|
|
for the point is sent to the bossnode, which then routes it to the point.
|
|
|
|
In supporting points, the bossnode makes use of a private net number which
|
|
should not be generally visible outside of the bossnode-point relationship.
|
|
Unfortunately, should the point call another system directly (to do a file
|
|
request, for example), the private network number will appear as the caller's
|
|
address. In this way, points are different from users, since they operate
|
|
ISGNet-compatible mailers which are capable of contacting systems other than
|
|
the bossnode.
|
|
|
|
|
|
1.2.3 Networks and Network Coordinators
|
|
|
|
A network is a collection of nodes in a local geographic area, usually
|
|
defined by an area of convenient telephone calling. Networks coordinate
|
|
their mail activity to decrease cost.
|
|
|
|
The Network Coordinator is responsible for maintaining the list of nodes for
|
|
the network, and for forwarding netmail sent to members of the network from
|
|
other ISGNet nodes. The Network Coordinator may make arrangements to handle
|
|
outgoing netmail, but is not required to do so.
|
|
|
|
The Network Coordinator is appointed by the Regional Coordinator.
|
|
|
|
1.2.3.1 Network Routing Hubs
|
|
|
|
Network Routing Hubs exist only in some networks. They may be appointed by
|
|
the Network Coordinator, in order to assist in the management of a large net-
|
|
work. The exact duties and procedures are a matter for the Network Coordina-
|
|
tor and the hubs to arrange, and will not be discussed here, except that a
|
|
network coordinator cannot delegate responsibility to mediate disputes.
|
|
|
|
1.2.4 Regions and Regional Coordinators
|
|
|
|
A region is a well-defined geographic area containing nodes which may or may
|
|
not be combined into networks. A typical region will contain many nodes in
|
|
networks, and a few independent nodes which are not a part of any network.
|
|
|
|
The Regional Coordinator maintains the list of independent nodes in the
|
|
region and accepts nodelists from the Network Coordinators in the region.
|
|
These are compiled to create a regional nodelist, which is then sent to the
|
|
Zone Coordinator. A Regional Coordinator does not perform message-forwarding
|
|
services for any nodes in the region.
|
|
|
|
Regional Coordinators are appointed by the Zone Coordinator.
|
|
|
|
|
|
1.2.5 Zones and Zone Coordinators
|
|
|
|
A zone is a large geographic area containing many regions, covering one or
|
|
more countries and/or continents.
|
|
|
|
The Zone Coordinator compiles the nodelists from all of the regions in the
|
|
zone, and creates the master nodelist and difference file, which is then
|
|
distributed over ISGNet in the zone. A Zone Coordinator does not perform
|
|
message-forwarding services for any nodes in the zone.
|
|
|
|
Zone Coordinators are selected by the Regional Coordinators in that zone.
|
|
|
|
|
|
1.2.6 Zone Coordinator Council
|
|
|
|
In certain cases, the Zone Coordinators work as a council to provide advice
|
|
to the International Coordinator. The arrangement is similar to that between
|
|
a president and advisors. In particular, this council considers inter-zonal
|
|
issues. This includes, but is not limited to: working out the details of
|
|
nodelist production, mediating inter-zonal disputes, and such issues not
|
|
addressed at a lower level of ISGNet.
|
|
|
|
|
|
1.2.7 International Coordinator
|
|
|
|
The International Coordinator is the "first among equals" Zone Coordinator,
|
|
and coordinates the joint production of the master nodelist by the Zone
|
|
Coordinators.
|
|
|
|
The International Coordinator acts as the chair of the Zone Coordinator
|
|
Council and as the overseer of elections -- arranging the announcement of
|
|
referenda, the collection and counting of the ballots, and announcing the
|
|
results for those issues that affect ISGNet as a whole.
|
|
|
|
The International Coordinator is selected by the Zone Coordinators.
|
|
|
|
|
|
1.2.8 Top-down Organization. Checks and Balances.
|
|
|
|
These levels act to distribute the administration and control of ISGNet to
|
|
the lowest possible level, while still allowing for coordinated action over
|
|
the entire mail system. Administration is made possible by operating in a
|
|
top-down manner. That is, a person at any given level is responsible to the
|
|
level above, and responsible for the level below.
|
|
|
|
For example, a Regional Coordinator is responsible to the Zone Coordinator
|
|
for anything that happens in the region. From the point of view of the Zone
|
|
Coordinator, the Regional Coordinator is completely responsible for the
|
|
smooth operation of the region. Likewise, from the point of view of the
|
|
Regional Coordinator, the Network Coordinator is completely responsible for
|
|
the smooth operation of the network.
|
|
|
|
If a person at any level above sysop is unable to properly perform their
|
|
duties, the person at the next level may replace them. For example, if a
|
|
Regional Coordinator fails to perform, the Zone Coordinator can replace him.
|
|
|
|
To provide for checks and balances at the highest level of ISGNet, there are
|
|
two exceptions to this top-down organization. Zone Coordinators and the
|
|
International Coordinator are selected by a majority vote of the coordinators
|
|
at the level below. Similarly, decisions made by the International Coordina-
|
|
tor can be reversed by the Zone Coordinator Council, and decisions made by a
|
|
Zone Coordinator can be reversed by the Regional Coordinators. See sections
|
|
6 and 7 for details. Decisions made by other coordinators are not subject to
|
|
reversal by a vote of the lower level, but instead are subject to the appeal
|
|
process described in section 9.5.
|
|
|
|
|
|
1.3 Definitions
|
|
|
|
1.3.1 INews
|
|
|
|
INews is a weekly newsletter distributed in electronic form throughout the
|
|
network. It is an important medium by which ISGNet sysops communicate with
|
|
each other. Inews provides a sense of being a community of people with
|
|
common interests. Accordingly, sysops and users are encouraged to contribute
|
|
to Inews. Contributions are submitted to node 1:1/1; a file describing
|
|
the format to be used is available from 1:1/1 and many other systems.
|
|
|
|
|
|
1.3.2 Geography
|
|
|
|
Each level of ISGNet is geographically contained by the level immediately
|
|
above it. A given geographic location is covered by one zone and one region
|
|
within that zone, and is either in one network or not in a network. There
|
|
are never two zones, two regions, or two networks which cover the same
|
|
geographic area.
|
|
|
|
If a node is in the area of a network, it should be listed in that network,
|
|
not as an independent in the region. (The primary exception to this is a
|
|
node receiving inordinate amounts of host-routed mail; see section 4.2).
|
|
Network boundaries are based on calling areas as defined by the local
|
|
telephone company. Even in the case of areas where node density is so great
|
|
that more than one network is needed to serve one local calling area, a geo-
|
|
graphic guideline is used to decide which nodes belong to what network.
|
|
Network membership is based on geographic or other purely technical ratio-
|
|
nale. It is not based on personal or social factors.
|
|
|
|
There are cases in which the local calling areas lead to situations where
|
|
logic dictates that a node physically in one ISGNet Region should be
|
|
assigned to another. In those cases, with the agreement of the Regional
|
|
Coordinators and Zone Coordinator involved, exemptions may be granted. Such
|
|
exemptions are described in section 5.6.
|
|
|
|
1.3.3 Zone Mail Hour
|
|
|
|
Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are
|
|
required to be able to accept netmail. Each ISGNet zone defines a ZMH and
|
|
publishes the time of its ZMH to all other ISGNet zones. See sections 2.1.8
|
|
and 10.2.
|
|
|
|
Zone Mail Hour has previously been referred to as National Mail Hour and
|
|
Network Mail hour. The term Zone Mail Hour is more accurate.
|
|
|
|
1.3.4 Nodelist
|
|
|
|
The nodelist is a file updated weekly which contains the addresses of all
|
|
recognized ISGNet nodes. This file is currently made available by the Zone
|
|
Coordinator not later than Zone Mail Hour each Saturday, and is available
|
|
electronically for download or file request at no charge. To be included in
|
|
the nodelist, a system must meet the requirements defined by this document.
|
|
No other requirements may be imposed.
|
|
|
|
Partial nodelists (single-zone, for example) may be made available at
|
|
different levels in ISGNet. The full list as published by the International
|
|
Coordinator is regarded as the official ISGNet nodelist, and is used in
|
|
circumstances such as determination of eligibility for voting. All parts
|
|
that make up the full nodelist are available on each Zone Coordinator's and
|
|
each Regional Coordinator's system.
|
|
|
|
|
|
1.3.5 Excessively Annoying Behavior
|
|
|
|
There are references throughout this policy to "excessively annoying behav-
|
|
ior", especially in section 9 (Resolution of Disputes). It is difficult to
|
|
define this term, as it is based upon the judgement of the coordinator
|
|
structure. Generally speaking, annoying behavior irritates, bothers, or
|
|
causes harm to some other person. It is not necessary to break a law to be
|
|
annoying.
|
|
|
|
There is a distinction between excessively annoying behavior and (simply)
|
|
annoying behavior. For example, there is a learning curve that each new
|
|
sysop must climb, both in the technical issues of how to set up the software
|
|
and the social issues of how to interact with ISGNet. It is a rare sysop
|
|
who, at some point in this journey, does not manage to annoy others. Only
|
|
when such behavior persists, after being pointed out to the sysop, does it
|
|
becomes excessively annoying. This does not imply that it is not possible to
|
|
be excessively annoying without repetition (for example, deliberate falsifi-
|
|
cation of mail would likely be excessively annoying on the very first try),
|
|
but simply illustrates that a certain amount of tolerance is extended.
|
|
|
|
Refer to section 9 and the case studies (section 10.3) for more information.
|
|
|
|
|
|
1.3.6 Commercial Use
|
|
|
|
ISGNet is an amateur network. Participants spend their own time and money
|
|
to make it work for the good of all the users. It is not appropriate for a
|
|
commercial enterprise to take advantage of these volunteer efforts to further
|
|
their own business interests. On the other hand, ISGNet provides a
|
|
convenient and effective means for companies and users to exchange informa-
|
|
tion, to the mutual benefit of all.
|
|
|
|
Network Coordinators could be forced to subsidize commercial operations by
|
|
forwarding host-routed netmail, and could even find themselves involved in a
|
|
lawsuit if any guarantee was suggested for mail delivery. It is therefore
|
|
ISGNet policy that commercial mail is not to be routed. "Commercial mail"
|
|
includes mail which furthers specific business interests without being of
|
|
benefit to the net as a whole. Examples include company-internal mail,
|
|
inter-corporate mail, specific product inquiries (price quotes, for in-
|
|
stance), orders and their follow-ups, and all other subjects specifically
|
|
related to business.
|
|
|
|
|
|
2 Sysop Procedures
|
|
|
|
2.1 General
|
|
|
|
2.1.1 The Basics
|
|
|
|
As the sysop of an individual node, you can generally do as you please, as
|
|
long as you observe mail events, are not excessively annoying to other nodes
|
|
in ISGNet, and do not promote or participate in the distribution of pirated
|
|
copyrighted software or other illegal behavior via ISGNet.
|
|
|
|
|
|
2.1.2 Familiarity with Policy
|
|
|
|
In order to understand the meaning of "excessively annoying", it is incumbent
|
|
upon all sysops to occasionally re-read ISGNet policy. New sysops must
|
|
familiarize themselves with policy before requesting a node number.
|
|
|
|
|
|
2.1.3 Responsible for All Traffic Entering ISGNet Via the Node
|
|
|
|
The sysop listed in the nodelist entry is responsible for all traffic
|
|
entering ISGNet via that system. This includes (but is not limited to)
|
|
traffic entered by users, points, and any other networks for which the system
|
|
might act as a gateway. If a sysop allows "outside" messages to enter
|
|
ISGNet via the system, the gateway system must be clearly identified by
|
|
ISGNet node number as the point of origin of that message, and it must act
|
|
as a gateway in the reverse direction. Should such traffic result in a
|
|
violation of Policy, the sysop must rectify the situation.
|
|
|
|
|
|
2.1.4 Encryption and Review of Mail
|
|
|
|
ISGNet is an amateur system. Our technology is such that the privacy of
|
|
messages cannot be guaranteed. As a sysop, you have the right to review
|
|
traffic flowing through your system, if for no other reason than to ensure
|
|
that the system is not being used for illegal or commercial purposes.
|
|
Encryption obviously makes this review impossible. Therefore, encrypted
|
|
and/or commercial traffic that is routed without the express permission of
|
|
all the links in the delivery system constitutes annoying behavior. See
|
|
section 1.3.6 for a definition of commercial traffic.
|
|
|
|
|
|
2.1.5 No Alteration of Routed Mail
|
|
|
|
You may not modify, other than as required for routing or other technical
|
|
purposes, any message, netmail or echomail, passing through the system from
|
|
one ISGNet node to another. If you are offended by the content of a
|
|
message, the procedure described in section 2.1.7 must be used.
|
|
|
|
|
|
2.1.6 Private Netmail
|
|
|
|
The word "private" should be used with great care, especially with users of a
|
|
BBS. Some countries have laws which deal with "private mail", and it should
|
|
be made clear that the word "private" does not imply that no person other
|
|
than the recipient can read messages. Sysops who cannot provide this
|
|
distinction should consider not offering users the option of "private mail".
|
|
|
|
If a user sends a "private message", the user has no control over the number
|
|
of intermediate systems through which that message is routed. A sysop who
|
|
sends a message to another sysop can control this aspect by sending the
|
|
message direct to the recipient's system, thus guaranteeing that only the
|
|
recipient or another individual to whom that sysop has given authorization
|
|
can read the message. Thus, a sysop may have different expectations than a
|
|
casual user.
|
|
|
|
2.1.6.1 No Disclosure of in-transit mail
|
|
|
|
Disclosing or in any way using information contained in private netmail
|
|
traffic not addressed to you or written by you is considered annoying
|
|
behavior, unless the traffic has been released by the author or the recipient
|
|
as a part of a formal policy complaint. This does not apply to echomail
|
|
which is by definition a broadcast medium, and where private mail is often
|
|
used to keep a sysop-only area restricted.
|
|
|
|
2.1.6.2 Private mail addressed to you
|
|
|
|
The issue of private mail which is addressed to you is more difficult than
|
|
the in-transit question treated in the previous section. A common legal
|
|
opinion holds that when you receive a message it becomes your property and
|
|
you have a legal right to do with it what you wish. Your legal right does
|
|
not excuse you from annoying others.
|
|
|
|
In general, sensitive material should not be sent using ISGNet. This ideal
|
|
is often compromised, as ISGNet is our primary mode of communication. In
|
|
general, if the sender of a message specifically requests in the text of the
|
|
message that the contents be kept confidential, release of the message into a
|
|
public forum may be considered annoying.
|
|
|
|
There are exceptions. If someone is saying one thing in public and saying
|
|
`he opposite in private mail, the recipient of the private mail should not be
|
|
subjected to harassment simply because the sender requests that the message
|
|
not be released. Judgement and common sense should be used in this area as
|
|
in all other aspects of ISGNet behavior.
|
|
|
|
2.1.7 Not Routing Mail
|
|
|
|
You are not required to route traffic if you have not agreed to do so. You
|
|
are not obligated to route traffic for all if you route it for any, unless
|
|
you hold a Network Coordinator or Hub Coordinator position. Routing traffic
|
|
through a node not obligated to perform routing without the permission of
|
|
that node may be annoying behavior. This includes unsolicited echomail.
|
|
|
|
If you do not forward a message when you previously agreed to perform such
|
|
routing, the message must be returned to the sysop of the node at which it
|
|
entered ISGNet with an explanation of why it was not forwarded. (It is not
|
|
necessary to return messages which are addressed to a node which is not in
|
|
the current nodelist.) Intentionally stopping an in-transit message without
|
|
following this procedure constitutes annoying behavior. In the case of a
|
|
failure to forward traffic due to a technical problem, it does not become
|
|
annoying unless it persists after being pointed out to the sysop.
|
|
|
|
|
|
2.1.8 Exclusivity of Zone Mail Hour
|
|
|
|
Zone Mail Hour is the heart of ISGNet, as this is when network mail is
|
|
passed between systems. Any system which wishes to be a part of ISGNet must
|
|
be able to receive mail during this time using the protocol defined in the
|
|
current ISGNet Technical Standards Committee publication (FTS-0001 at this
|
|
writing). It is permissible to have greater capability (for example, to
|
|
support additional protocols or extended mail hours), but the minimum
|
|
requirement is FTS-0001 capability during this one hour of the day.
|
|
|
|
This time is exclusively reserved for netmail. Many phone systems charge on
|
|
a per-call basis, regardless of whether a connect, no connect, or busy signal
|
|
is encountered. For this reason, any activity other than normal network mail
|
|
processing that ties up a system during ZMH is considered annoying behavior.
|
|
Echomail should not be transferred during ZMH. User (BBS) access to a system
|
|
is prohibited during ZMH.
|
|
|
|
A system which is a member of a local network may also be required to observe
|
|
additional mail events, as defined by the Network Coordinator. Access
|
|
restrictions during local network periods are left to the discretion of the
|
|
Network Coordinator.
|
|
|
|
|
|
2.1.9 Private Nodes
|
|
|
|
The rare exception to ZMH compliance is private nodes. Persons requesting
|
|
private nodes should be supported as points if possible. A private listing
|
|
is justified when the system must interface with many others, such as an
|
|
echomail distributor. In these cases, the exact manner and timing of mail
|
|
delivery is arranged between the private node and other systems. Such an
|
|
agreement between a private system and a hub is not binding on any replace-
|
|
ment for that hub. A private node must be a part of a network (they cannot
|
|
be independents in the region.)
|
|
|
|
Private listings impact each member of ISGNet, since they take up space in
|
|
everyone's nodelist. Private listings which are for the convenience of one
|
|
sysop (at the expense of every other sysop in ISGNet) are a luxury which is
|
|
no longer possible. Non-essential redundant listings (more than one listing
|
|
for the same telephone number, except as mandated by FTSC standards) also
|
|
fall into this category. Sysops requesting private or redundant listings
|
|
must justify them with a statement explaining how they benefit the local net
|
|
or ISGNet as a whole. The Network Coordinator or Regional Coordinator may
|
|
review this statement at any time and listings which are not justified will
|
|
be removed.
|
|
|
|
|
|
2.1.10 Observing Mail Events
|
|
|
|
Failure to observe the proper mail events is grounds for any node to be
|
|
dropped from ISGNet without notice (since notice is generally given by
|
|
netmail).
|
|
|
|
|
|
2.1.11 Use of Current Nodelist
|
|
|
|
Network mail systems generally operate unattended, and place calls at odd
|
|
hours of the night. If a system tries to call an incorrect or out-of-date
|
|
number, it could cause some poor citizen's phone to ring in the wee hours of
|
|
the morning, much to the annoyance of innocent bystanders and civil authori-
|
|
ties. For this reason, a sysop who sends mail is obligated to obtain and use
|
|
the most recent edition of the nodelist as is practical.
|
|
|
|
|
|
2.1.12 Excommunication
|
|
|
|
A system which has been dropped from the network is said to be excommunicated
|
|
(i.e. denied communication). If you find that you have been excommunicated
|
|
without warning, your coordinator was unable to contact you. You should
|
|
rectify the problem and contact your coordinator.
|
|
|
|
Systems may also be dropped from the nodelist for cause. See section 9, and
|
|
sections 4.3 and 5.2.
|
|
|
|
It is considered annoying behavior to assist a system which was excommuni-
|
|
cated in circumventing that removal from the nodelist. For example, if you
|
|
decide to provide an echomail feed to your friend who has been excommuni-
|
|
cated, it is likely that your listing will also be removed.
|
|
|
|
|
|
2.1.13 Timing of Zone Mail Hour
|
|
|
|
The exact timing of Zone Mail Hour for each zone is set by the Zone Coordina-
|
|
tor. See section 10.2.
|
|
|
|
|
|
2.1.14 Non-observance of Daylight Savings Time
|
|
|
|
ISGNet does not observe daylight savings time. In areas which observe
|
|
daylight savings time the ISGNet mail schedules must be adjusted in the same
|
|
direction as the clock change. Alternatively, you can simply leave your
|
|
system on standard time.
|
|
|
|
|
|
2.2 How to obtain a node number
|
|
|
|
|
|
You must first obtain a current nodelist so that you can send mail. You do
|
|
not need a node number to send mail, but you must have one in order for
|
|
others to send mail to you.
|
|
|
|
The first step in obtaining a current nodelist is to locate a ISGNet
|
|
bulletin board. Most bulletin board lists include at least a few ISGNet
|
|
systems, and usually identify them as such. Use a local source to obtain
|
|
documents because many networks have detailed information available which
|
|
explains the coverage area of the network and any special requirements or
|
|
procedures.
|
|
|
|
Once you have a nodelist, you must determine which network or region covers
|
|
your area. Regions are numbered 1-99; network numbers are greater than 99.
|
|
Networks are more restricted in area than regions, but are preferred since
|
|
they improve the flow of mail and provide more services to their members. If
|
|
you cannot find a network which covers your area, then pick the region which
|
|
does.
|
|
|
|
Once you have located the network or region in your area, send a message
|
|
containing a request for a node number to node zero of that network or
|
|
region. The request must be sent by netmail, as this indicates that your
|
|
system has ISGNet capability.
|
|
|
|
You must set up your software so that the from-address in your message does
|
|
not cause problems for the coordinator who receives it. If you pick the
|
|
address of an existing system, this will cause obvious problems. If your
|
|
software is capable of using address -1/-1, this is the traditional address
|
|
used by potential sysops. Otherwise use net/9999 (e.g. if you are applying
|
|
to net 123, set your system up as 123/9999). Many nets have specific
|
|
instructions available to potential sysops and these procedures may indicate
|
|
a preference for the from-address.
|
|
|
|
The message you send must include at least the following information:
|
|
|
|
1) Your name.
|
|
2) Your voice telephone number
|
|
3) The name of your system.
|
|
4) The city and state where your system is located.
|
|
5) The phone number to be used when calling your system.
|
|
6) Your hours of operation, netmail and BBS.
|
|
7) The maximum baud rate you can support.
|
|
8) The type of mailer software and modem you are using.
|
|
|
|
Your coordinator may contact you for additional information. All information
|
|
submitted will be kept confidential and will not be supplied to anyone except
|
|
the person who assumes the coordinator position at the resignation of the
|
|
current coordinator.
|
|
|
|
You must indicate that you have read, and agree to abide by, this document
|
|
and all the current policies of ISGNet.
|
|
|
|
Please allow at least two weeks for a node number request to be processed.
|
|
If you send your request to a Regional Coordinator, it may forwarded to the
|
|
appropriate Network Coordinator.
|
|
|
|
|
|
2.3 If You are Going Down
|
|
|
|
If your node will be down for an extended period (more than a day or two),
|
|
inform your coordinator as soon as possible. It is not your coordinator's
|
|
responsibility to chase you down for a status report, and if your system
|
|
stops accepting mail it will be removed from the nodelist.
|
|
|
|
Never put an answering machine or any other device which answers the phone on
|
|
your phone line while you are down. If you do, calling systems will get the
|
|
machine repeatedly, racking up large phone bills, which is very annoying. In
|
|
short, the only thing which should ever answer the telephone during periods
|
|
when the nodelist indicates that your node will accept mail is ISGNet-
|
|
compatible software which accepts mail.
|
|
|
|
If you will be leaving your system unattended for an extended period of time
|
|
(such as while you are on vacation), you should notify your coordinator.
|
|
Systems have a tendency to "crash" now and then, so you will probably want
|
|
your coordinator to know that it is a temporary condition if it happens while
|
|
you are away.
|
|
|
|
|
|
2.4 How to Form a Network
|
|
|
|
If there are several nodes in your area, but no network, a new network can be
|
|
formed. This has advantages to both you and to the rest of ISGNet. You
|
|
receive better availability of nodelist difference files and INews, and
|
|
everyone else can take advantage of host-routing netmail to the new network.
|
|
|
|
The first step is to contact the other sysops in your area. You must decide
|
|
which nodes will comprise the network, and which of those nodes you would
|
|
like to be the Network Coordinator. Then consult your Regional Coordinator.
|
|
You must send the following information:
|
|
|
|
1) The region number(s), or network number(s) if a network is splitting
|
|
up, that are affected by the formation of your network. The Regional
|
|
Coordinator will inform the Zone Coordinator and the coordinators of any
|
|
affected networks that a new network is in formation.
|
|
|
|
2) A copy of the proposed network's nodelist segment. This file should
|
|
be attached to the message of application for a network number, and
|
|
should use the nodelist format described in the current version of the
|
|
appropriate FTSC publication. Please elect a name that relates to your
|
|
grouping, for example SoCalNet for nodes in the Southern California Area
|
|
and MassNet West for the Western Massachusetts Area. Remember if you
|
|
call yourself DOGNET it doesn't identify your area.
|
|
|
|
Granting a network number is not automatic. Even if the request is granted,
|
|
the network might not be structured exactly as you request. Your Regional
|
|
Coordinator will review your application and inform you of the decision.
|
|
|
|
Do not send a network number request to the Zone Coordinator. All network
|
|
number requests must be processed by the Regional Coordinator.
|
|
|
|
|
|
|
|
3 General Procedures for All Coordinators
|
|
|
|
3.1 Make Available Difference Files and INews
|
|
|
|
Any Coordinator is responsible for obtaining and making available, on a
|
|
weekly basis, nodelist difference files and INews.
|
|
|
|
|
|
3.2 Processing Nodelist Changes and Passing Them Upstream
|
|
|
|
Each coordinator is responsible for obtaining nodelist information from the
|
|
level below, processing it, and passing the results to the level above. The
|
|
timing of this process is determined by the requirements imposed by the level
|
|
above.
|
|
|
|
|
|
3.3 Ensure the Latest Policy is Available
|
|
|
|
A Coordinator is responsible to make the current version of this document
|
|
available to the level below, and to encourage familiarity with it.
|
|
|
|
In addition, a coordinator is required to forward any local policies received
|
|
to the level above, and to review such policies. Although not required,
|
|
common courtesy dictates that when formulating a local policy, the participa-
|
|
tion of the level above should be solicited.
|
|
|
|
|
|
3.4 Minimize the Number of Hats Worn
|
|
|
|
Coordinators are encouraged to limit the number of ISGNet functions they
|
|
perform. A coordinator who holds two different positions compromises the
|
|
appeal process. For example, if the Network Coordinator is also the Regional
|
|
Coordinator, sysops in that network are denied one level of appeal.
|
|
|
|
Coordinators are discouraged from acting as echomail and software-distri-
|
|
bution hubs. If they do so, they should handle echomail (or other volume
|
|
distribution) on a system other than the administrative system. A coordina-
|
|
tor's system should be readily available to the levels immediately above and
|
|
below.
|
|
|
|
Another reason to discourage multiple hats is the difficulty of replacing
|
|
services if someone leaves the network. For example, if a coordinator is the
|
|
echomail hub and the software-distribution hub, those services will be
|
|
difficult to restore when that person resigns.
|
|
|
|
3.5 Be a Member of the Area Administered
|
|
|
|
A coordinator must be a member of the area administered. That is, a Network
|
|
Coordinator must be a member of that network by virtue of geography. A
|
|
Regional Coordinator must be either a member of a network in the region, or
|
|
an independent in the region.
|
|
|
|
|
|
3.6 Encourage New Sysops to Enter ISGNet
|
|
|
|
A coordinator is encouraged to operate a public bulletin board system which
|
|
is freely available for the purpose of distributing Policy, INEWS, and
|
|
Nodelists to potential new sysops. Dissemination of this information to
|
|
persons who are potential ISGNet sysops is important to the growth of
|
|
ISGNet, and coordinators should encourage development of new systems.
|
|
|
|
|
|
3.7 Tradition and Precedent
|
|
|
|
A coordinator is not bound by the practices of predecessor or peers beyond
|
|
the scope of this document.
|
|
|
|
In addition, a new coordinator has the right to review any decision made by
|
|
predecessors for compliance with Policy, and take whatever actions may be
|
|
necessary to rectify any situations not in compliance.
|
|
|
|
|
|
3.8 Technical Management
|
|
|
|
The primary responsibility of any coordinator is technical management of
|
|
network operations. Decisions must be made on technical grounds.
|
|
|
|
|
|
|
|
4 Network Coordinator Procedures
|
|
|
|
4.1 Responsibilities
|
|
|
|
A Network Coordinator has the following responsibilities:
|
|
|
|
1) To receive incoming mail for nodes in the network, and arrange
|
|
delivery to its recipients.
|
|
|
|
2) To assign node numbers to nodes in the network.
|
|
|
|
3) To maintain the nodelist for the network, and to send a copy of it to
|
|
the Regional Coordinator whenever it changes.
|
|
|
|
4) To make available to nodes in the network new nodelist difference
|
|
files, new issues of INEWS, and new revisions of Network Policy
|
|
Documents as they are received, and to periodically check to insure that
|
|
nodes use up to date nodelists.
|
|
|
|
|
|
4.2 Routing Inbound Mail
|
|
|
|
It is your responsibility as Network Coordinator to coordinate the receipt
|
|
and forwarding of host-routed inbound netmail for nodes in your network. The
|
|
best way to accomplish this is left to your discretion.
|
|
|
|
If a node in your network is receiving large volumes of mail you can request
|
|
that the sysop contact the systems which are sending this mail and request
|
|
that they not host-route it. If the problem persists, you can request your
|
|
Regional Coordinator to assign the node a number as an independent and drop
|
|
the system from your network.
|
|
|
|
Occasionally a node will make a "bombing run" (sending one message to a great
|
|
many nodes). If a node in another network is making bombing runs on your
|
|
nodes and routing them through your inbound host, then you can complain to
|
|
the network coordinator of the offending node. (If the node is an indepen-
|
|
dent, complain to the regional coordinator.) Bombing runs are considered to
|
|
be annoying.
|
|
|
|
Another source of routing overload is echomail. Echomail cannot be allowed
|
|
to degrade the ability of ISGNet to handle normal message traffic. If a
|
|
node in your network is routing large volumes of echomail, you can ask the
|
|
sysop to either limit the amount of echomail or to stop routing echomail.
|
|
|
|
You are not required to forward encrypted, commercial, or illegal mail.
|
|
However, you must follow the procedures described in section 2.1.7 if you do
|
|
not forward the mail.
|
|
|
|
|
|
4.3 Assigning Node Numbers
|
|
|
|
It is your responsibility to assign node numbers to new nodes in your net-
|
|
work. You may also change the numbers of existing nodes in your network,
|
|
though you should check with your member nodes before doing so. You may
|
|
assign any numbers you wish, so long as each node has a unique number within
|
|
your network.
|
|
|
|
You must not assign a node number to any system until you have received a
|
|
formal request from that system by ISGNet mail. This will ensure that the
|
|
system is minimally operational. The strict maintenance of this policy has
|
|
been one of the great strengths of ISGNet.
|
|
|
|
It is also recommended, though not required, that you call a board which is
|
|
applying for a node number before assigning it a node number.
|
|
|
|
You may not assign a node number to a node in an area covered by an existing
|
|
network. Further, if you have nodes in an area covered by a network in
|
|
formation, those nodes must be transferred to the new network.
|
|
|
|
You should use network mail to inform a new sysop of the node number, as this
|
|
helps to insure that the system is capable of receiving network mail.
|
|
|
|
If a node in your network is acting in a sufficiently annoying manner, then
|
|
you can take whatever action you deem fit, according to the circumstances of
|
|
the case.
|
|
|
|
|
|
4.4 Maintaining the Nodelist
|
|
|
|
|
|
You should implement name changes, phone number changes, and so forth in your
|
|
segment of the nodelist as soon as possible after the information is received
|
|
from the affected node. You should also on occasion send a message to every
|
|
node in your network to ensure that they are operational. If a node turns
|
|
out to be "off the air" with no prior warning, you can either mark the node
|
|
down or remove it from the nodelist. (Nodes are to be marked DOWN for a
|
|
maximum of two weeks, after which the line should be removed from the node-
|
|
list.)
|
|
|
|
At your discretion, you may distribute a portion of this workload to routing
|
|
hubs. In this case, you should receive the nodelists from the Hub Coordina-
|
|
tors within your network. You will need to maintain a set of nodelists for
|
|
each hub within your network, since you cannot count on getting an update
|
|
from each Hub Coordinator every week. You should assemble a master nodelist
|
|
for your network every week and send it to your Regional Coordinator by the
|
|
day and time designated. It is suggested that you do this as late as is
|
|
practical, so as to accommodate any late changes, balanced with the risk of
|
|
missing the connection with your Regional Coordinator and thus losing a week.
|
|
|
|
4.5 Making Available Policies, Nodelists and INEWS
|
|
|
|
As a Network Coordinator you should obtain a new issue of INEWS and a new
|
|
nodelist difference file every week from your Regional Coordinator. The
|
|
nodelist difference file is currently made available each Saturday, and
|
|
INEWS is published each Monday. You must make these files available to
|
|
all nodes in the network, and you are encouraged to make them available to
|
|
the general public for download.
|
|
|
|
You should also obtain the most recent versions of the Policy documents that
|
|
bind the members of your network, and make those available to the nodes in
|
|
your network. Policies are released at sporadic intervals, so you should
|
|
also inform the nodes in your network when such events occur, and ensure the
|
|
nodes are generally familiar with the changes.
|
|
|
|
Policy, INEWS, and the nodelist are the glue that holds us together.
|
|
Without them, we would cease to be a community, and become just another
|
|
random collection of bulletin boards.
|
|
|
|
|
|
|
|
5 Regional Coordinator Procedures
|
|
|
|
5.1 Responsibilities
|
|
|
|
A Regional Coordinator has the following responsibilities:
|
|
|
|
1) To assign node numbers to independent nodes in the region.
|
|
|
|
2) To encourage independent nodes in the region to join existing net-
|
|
works, or to form new networks.
|
|
|
|
3) To assign network numbers to networks in the region and define their
|
|
boundaries.
|
|
|
|
4) To compile a nodelist of all of the networks and independents in the
|
|
region, and to send a copy of it to the Zone Coordinator whenever it
|
|
changes.
|
|
|
|
5) To ensure the smooth operation of networks within the region.
|
|
|
|
6) To make new nodelist difference files, Policies, and issues of
|
|
INEWS available to the Network Coordinators in the region as soon as
|
|
is practical.
|
|
|
|
|
|
5.2 Assigning Node Numbers
|
|
|
|
It is your responsibility to assign node numbers to independent nodes in your
|
|
region. You may also change the numbers of existing nodes in your region,
|
|
though you should check with the respective nodes before doing so. You may
|
|
assign any numbers you wish, so long as each node has a unique number within
|
|
your region.
|
|
|
|
You should not assign a node number to any system until you have received a
|
|
formal request from that system by ISGNet mail. This will ensure that the
|
|
system is minimally operational. The strict maintenance of this policy has
|
|
been one of the great strengths of ISGNet.
|
|
|
|
It is also recommended, though not required, that you call a board which is
|
|
applying for a node number before assigning it a node number.
|
|
|
|
You should use network mail to inform a new sysop of the node number, as this
|
|
helps to insure that the system is capable of receiving network mail.
|
|
|
|
If a node in your region is acting in a sufficiently annoying manner, then
|
|
you can take whatever action you deem fit, according to the circumstances of
|
|
the case.
|
|
|
|
If you receive a node number request from outside your region, you must
|
|
forward it to the most local coordinator for the requestor as you can deter-
|
|
mine. If you receive a node number request from a new node that is in an
|
|
area covered by an existing network, then you must forward the request to the
|
|
Coordinator of that network instead of assigning a number yourself.
|
|
|
|
If a network forms in an area for which you have independent nodes, those
|
|
nodes will be transferred to the local network as soon as is practical.
|
|
|
|
|
|
5.3 Encouraging the Formation and Growth of Networks
|
|
|
|
One of your main duties as a Regional Coordinator is to promote the growth of
|
|
networks in your region.
|
|
|
|
You should avoid having independent nodes in your region which are within the
|
|
coverage area of a network. There are, however, certain cases where a node
|
|
should not be a member of a network, such as a system with a large amount of
|
|
inbound netmail; see section 4.2.
|
|
|
|
If several independent nodes in your region are in a local area you should
|
|
encourage them to form a network, and if necessary you may require them to
|
|
form a network. Refer to section 2.4. Note that this is not intended to
|
|
encourage the formation of trivial networks. Obviously, one node does not
|
|
make a network. The exact number of nodes required for an effective network
|
|
must be judged according to the circumstances of the situation, and is left
|
|
to your discretion.
|
|
|
|
|
|
5.4 Assigning Network Numbers
|
|
|
|
It is your responsibility to assign network numbers to new networks forming
|
|
within your region. You are assigned a pool of network numbers to use for
|
|
this purpose by your Zone Coordinator. As a part of this function, it is the
|
|
responsibility of the Regional Coordinator to define the boundaries of the
|
|
networks in the region.
|
|
|
|
|
|
5.5 Maintaining the Nodelist
|
|
|
|
As a Regional Coordinator, you have a dual role in maintaining the nodelist
|
|
for your region.
|
|
|
|
First, you must maintain the list of independent nodes in your region. You
|
|
should attempt to implement name changes, phone number changes, and so forth
|
|
in this nodelist as soon as possible. You should also on occasion send a
|
|
message to every independent node in your region to ensure that they are
|
|
operational. If a node turns out to be "off the air" with no prior warning,
|
|
you can either mark the node down or remove it from the nodelist. (Nodes are
|
|
to marked DOWN for a maximum of two weeks, after which the line should be
|
|
removed from the nodelist.)
|
|
|
|
Second, you must receive the nodelists from the Network Coordinators within
|
|
your region. You will need to maintain a set of nodelists for each network
|
|
within your region, since you cannot count on getting an update from each
|
|
Network Coordinator every week. You should assemble a master nodelist for
|
|
your region every week and send it to your Zone Coordinator by the day and
|
|
time designated. It is suggested that you do this as late as practical, so
|
|
as to accommodate late changes, balanced with the risk of missing the connec-
|
|
tion with your Zone Coordinator and thus losing a week.
|
|
|
|
|
|
5.6 Geographic Exemptions
|
|
|
|
There are cases where local calling geography does not follow ISGNet re-
|
|
gions. In exceptional cases, exemptions to normal geographic guidelines are
|
|
agreed upon by the Regional Coordinators and Zone Coordinator involved. Such
|
|
an exemption is not a right, and is not permanent. When a network is formed
|
|
in the proper region that would provide local calling access to the exempted
|
|
node, it is no longer exempt. An exemption may be reviewed and revoked at
|
|
any time by any of the coordinators involved.
|
|
|
|
|
|
5.7 Overseeing Network Operations
|
|
|
|
You are responsible for appointing network coordinators for the nets in your
|
|
region. If the outgoing Network Coordinator suggests a successor, you are
|
|
not obligated to accept that individual, although you normally will. Simi-
|
|
larly, you are not obligated to accept the individual selected by the members
|
|
of the network in an election, although you normally will.
|
|
|
|
It is your responsibility as Regional Coordinator to ensure that the networks
|
|
within your region are operating in an acceptable manner. This does not mean
|
|
that you are required to operate those networks; that is the responsibility
|
|
of the Network Coordinators. It means that you are responsible for assuring
|
|
that the Network Coordinators within your region are acting responsibly.
|
|
|
|
If you find that a Network Coordinator within your region is not properly
|
|
performing the duties outlined in Section 4, you should take whatever action
|
|
you deem necessary to correct the situation.
|
|
|
|
If a network grows so large that it cannot reasonably accommodate traffic
|
|
flow during the Zone Mail Hour, the Regional Coordinator can direct the
|
|
creation of one or more new networks from that network. These new networks,
|
|
although they may be within a single local-calling area, must still conform
|
|
to a geographical basis for determining membership.
|
|
|
|
It is your obligation as Regional Coordinator to maintain direct and reason-
|
|
ably frequent contact with the networks in your region. The exact method of
|
|
accomplishing this is left to your discretion.
|
|
|
|
|
|
5.8 Making Available Nodelists, Policies, and INEWS
|
|
|
|
As a Regional Coordinator, it is your responsibility to obtain the latest
|
|
nodelist difference file, network policies, and the latest issues of INEWS
|
|
as they are published, and to make them available to the Network Coordinators
|
|
within your region. The nodelist is posted weekly on Saturday by the Zone
|
|
Coordinator, and INEWS is published weekly on Monday by node 1/1. Contact
|
|
them for more details on how to obtain the latest copies each week.
|
|
|
|
It is your responsibility to make these available to all Network Coordina-
|
|
tors in your region as soon as is practical after you receive them. The
|
|
method of distribution is left to your discretion. You are not required to
|
|
distribute them to any independent nodes in your region, though you may if
|
|
you wish. You are encouraged to make all these documents available for
|
|
downloading by the general public.
|
|
|
|
|
|
|
|
6 Zone Coordinator Procedures
|
|
|
|
6.1 General
|
|
|
|
A Zone Coordinator for ISGNet has the primary task of maintaining the
|
|
nodelist for the Zone, sharing it with the other Zone Coordinators, and
|
|
ensuring the distribution of the master nodelist (or difference file) to the
|
|
Regions in the Zone. The Zone Coordinator is also responsible for coordinat-
|
|
ing the distribution of Network Policy documents and INEWS to the Regional
|
|
Coordinators in the zone.
|
|
|
|
The Zone Coordinator is responsible for the maintenance of the nodelist for
|
|
the administrative region. The Administrative Region has the same number as
|
|
the zone, and consists of nodes assigned for administrative purposes not
|
|
related to the sending and receiving of normal network mail.
|
|
|
|
A Zone Coordinator is charged with the task of ensuring the smooth operation
|
|
of the Zone, which is done by appointing and supervising the Regional Coordi-
|
|
nators.
|
|
|
|
If a Zone Coordinator determines that a Regional Coordinator is not properly
|
|
performing the duties outlined in section 5, a replacement should be found.
|
|
|
|
The Zone Coordinator defines the geographic boundaries of the regions within
|
|
the zone and sets the time for the Zone Mail Hour.
|
|
|
|
The Zone Coordinator is responsible for reviewing and approving any geograph-
|
|
ic exemptions as described in section 5.6.
|
|
|
|
The Zone Coordinator is responsible for insuring the smooth operation of
|
|
gates between that zone and all other zones for the transfer of interzonal
|
|
mail.
|
|
|
|
The Zone Coordinators are responsible for the selection of the International
|
|
Coordinator from among their ranks.
|
|
|
|
|
|
6.2 Selection
|
|
|
|
The Zone Coordinator is selected by an absolute majority vote of the Regional
|
|
Coordinators within the zone.
|
|
|
|
|
|
7 International Coordinator Procedures
|
|
|
|
7.1 General
|
|
|
|
The International Coordinator is the "first among equals" Zone Coordinator.
|
|
|
|
The International Coordinator has the primary task of coordinating the
|
|
creation of the master nodelist by managing the distribution between the
|
|
Zones of the Zone nodelists. The International Coordinator is responsible
|
|
for definition of new zones and for negotiation of agreements for communica-
|
|
tion with other networks. ("Other network" in this context means other
|
|
networks with which ISGNet communicates as peer-to-peer, not "network" in
|
|
the sense of the ISGNet organizational level.)
|
|
|
|
The International Coordinator is also responsible for coordinating the
|
|
distribution of Network Policies and INEWS to the Zone Coordinators.
|
|
|
|
The International Coordinator is responsible for coordinating the activities
|
|
of the Zone Coordinator Council. The International Coordinator acts as the
|
|
spokesman for the Zone Coordinator Council.
|
|
|
|
In cases not specifically covered by this document, the International Coordi-
|
|
nator may issue specific interpretations or extensions to this policy. The
|
|
Zone Coordinator Council may reverse such rulings by a majority vote.
|
|
|
|
7.2 Selection
|
|
|
|
The International Coordinator is selected (or removed) by an absolute majori-
|
|
ty vote of the Zone Coordinators.
|
|
|
|
|
|
8 Referenda
|
|
|
|
The procedures described in this section are used to ratify a new version of
|
|
ISGNet policy, which is the mechanism by which policy is changed. This
|
|
procedure is also used to impeach a Zone Coordinator.
|
|
|
|
|
|
8.1 Initiation
|
|
|
|
A referendum on policy modification is invoked when a majority of the
|
|
ISGNet Regional Coordinators inform the International Coordinator that they
|
|
wish to consider a proposed new version of Policy.
|
|
|
|
|
|
8.2 Announcement and Results Notification
|
|
|
|
Proposed changes to Policy are distributed using the same structure which is
|
|
used to distribute nodelist difference files and INEWS. Results and
|
|
announcements related to the referendum are distributed by the coordinator
|
|
structure as a part of the weekly nodelist difference file. The Interna-
|
|
tional Coordinator provides copies to the editor of INEWS for inclusion
|
|
there, although the official announcement and voting dates are tied to
|
|
nodelist distributions.
|
|
|
|
If it is adopted, the International Coordinator sets the effective date for a
|
|
new policy through announcement in the weekly nodelist difference file. The
|
|
effective date will be not more than one month after the close of balloting.
|
|
|
|
|
|
8.3 Eligibility to Vote
|
|
|
|
Each member of the ISGNet coordinator structure at and above Network Coordi-
|
|
nator is entitled to one vote. (Hub coordinators do not vote.) In the case
|
|
of the position changing hands during the balloting process, either the
|
|
incumbent or the new coordinator may vote, but not both. If a person holds
|
|
more than one coordinator position, they still receive only one vote.
|
|
|
|
Network coordinators are expected to assess the opinions of the members of
|
|
their network, and to vote accordingly. A formal election is not necessary,
|
|
but the network coordinator must inform the net of the issues and solicit
|
|
input. The network coordinator functions as the representative of the rank
|
|
and file members of ISGNet.
|
|
|
|
|
|
8.4 Voting Mechanism
|
|
|
|
The actual voting mechanism, including whether the ballot is secret and how
|
|
the ballots are to be collected, verified, and counted, is left to the
|
|
discretion of the International Coordinator. Ideally, ballot collection
|
|
should be by some secure message system, conducted over ISGNet itself.
|
|
|
|
In order to provide a discussion period, the announcement of any ballot must
|
|
be made at least two weeks before the date of voting commencement. The
|
|
balloting period must be at least two weeks.
|
|
|
|
|
|
8.5 Voting on a whole Policy Document
|
|
|
|
Given that Policy is intertwined and self referencing, a relatively simple
|
|
change may require several alterations of the document. In order to simplify
|
|
the process, balloting is done on choices between whole documents, rather
|
|
than individual amendments. In the simplest case, this means voting yea or
|
|
nay to a new document. If a number of alternatives are to be considered,
|
|
they must be presented as whole documents, from which one is chosen.
|
|
|
|
|
|
8.6 Decision of vote
|
|
|
|
A Policy amendment is considered in force if, at the end of the balloting
|
|
period, it has received a majority of the votes cast. For example, if there
|
|
were 350 eligible voters, 100 of which cast a vote, then at least 51 affirma-
|
|
tive votes would be required to declare the amendment in force.
|
|
|
|
In the case of multiple policy changes which are considered on the same
|
|
ballot, a version must receive more than 50% of the votes cast to be consid-
|
|
ered ratified. "Abstain" is a valid vote in this case, effectively being a
|
|
vote for not changing the current policy as it simply increases the number of
|
|
votes required to ratify the proposed change.
|
|
|
|
|
|
8.7 Impeachment of a Zone Coordinator
|
|
|
|
8.7.1 Initiation
|
|
|
|
In extreme cases, a Zone Coordinator may be impeached by referendum. Im-
|
|
peachment of a Zone Coordinator does not require a Policy violation. An
|
|
impeachment proceeding is invoked when a majority of the Regional Coordina-
|
|
tors in a zone request the International Coordinator to institute it.
|
|
|
|
8.7.2 Procedure as in Policy Referendum
|
|
|
|
The provisions of sections 8.2 and 8.3 apply to impeachment referenda.
|
|
|
|
The definition of "majority" in section 8.6 applies. Only coordinators in
|
|
the affected zone vote (even if the zone coordinator is also the Internation-
|
|
al Coordinator).
|
|
|
|
8.7.3 Voting Mechanism
|
|
|
|
The balloting procedures are set, the votes are collected, and the results
|
|
are announced by a Regional Coordinator chosen by the Zone Coordinator who is
|
|
being impeached. The removal of the Zone Coordinator is effective two weeks
|
|
after the end of balloting if the impeachment carries.
|
|
|
|
8.7.4 Limited to once per year
|
|
|
|
The removal of a Zone Coordinator is primarily intended to be a mechanism by
|
|
which the net as a whole expresses displeasure with the way Policy is being
|
|
interpreted. At one time or another, everyone is unhappy with the way policy
|
|
is interpreted. In order to keep the Zone Coordinators interpreting policy
|
|
as opposed to defending themselves, at least one full calendar year must
|
|
elapse between impeachment referenda (regardless of how many people hold the
|
|
position of Zone Coordinator during that year.)
|
|
|
|
Should a Zone Coordinator resign during an impeachment process, the process
|
|
is considered null and void, and does not consume the "once per year quota".
|
|
|
|
|
|
9 Resolution of Disputes
|
|
|
|
9.1 General
|
|
|
|
The ISGNet judicial philosophy can be summed up in two rules:
|
|
|
|
1) Thou shalt not excessively annoy others.
|
|
|
|
2) Thou shalt not be too easily annoyed.
|
|
|
|
In other words, there are no hard and fast rules of conduct, but reasonably
|
|
polite behavior is expected. Also, in any dispute both sides are examined,
|
|
and action could be taken against either or both parties. ("Judge not, lest
|
|
ye be judged!")
|
|
|
|
The coordinator structure has the responsibility for defining "excessively
|
|
annoying". Like a common definition of pornography ("I can't define it, but
|
|
I know it when I see it."), a hard and fast definition of acceptable ISGNet
|
|
behavior is not possible. The guidelines in this policy are deliberately
|
|
vague to provide the freedom that the coordinator structure requires to
|
|
respond to the needs of a growing and changing community.
|
|
|
|
The first step in any dispute between sysops is for the sysops to attempt to
|
|
communicate directly, at least by netmail, preferably by voice. Any com-
|
|
plaint made that has skipped this most basic communication step will be
|
|
rejected.
|
|
|
|
Filing a formal complaint is not an action which should be taken lightly.
|
|
Investigation and response to complaints requires time which coordinators
|
|
would prefer to spend doing more constructive activities. Persons who
|
|
persist in filing trivial policy complaints may find themselves on the wrong
|
|
side of an excessively-annoying complaint. Complaints must be accompanied
|
|
with verifiable evidence, generally copies of messages; a simple word-of-
|
|
mouth complaint will be dismissed out of hand.
|
|
|
|
Failure to follow the procedures herein described (in particular, by skipping
|
|
a coordinator, or involving a coordinator not in the appeal chain) is in and
|
|
of itself annoying behavior.
|
|
|
|
|
|
9.2 Problems with Another Sysop
|
|
|
|
If you are having problems with another sysop, you should first try to work
|
|
it out via netmail or voice conversation with the other sysop.
|
|
|
|
If this fails to resolve the problem, you should complain to your Network
|
|
Coordinator and the other sysop's Network Coordinator. If one or both of you
|
|
is not in a network, then complain to the appropriate Regional Coordinator.
|
|
Should this fail to provide satisfaction, you have the right to follow the
|
|
appeal process described in section 9.5.
|
|
|
|
|
|
9.3 Problems with your Network Coordinator
|
|
|
|
If you are having problems with your Network Coordinator and feel that you
|
|
are not being treated properly, you are entitled to a review of your situa-
|
|
tion. As with all disputes, the first step is to communicate directly to
|
|
attempt to resolve the problem.
|
|
|
|
The next step is to contact your Regional Coordinator. If your case has
|
|
merit, there are several possible courses of action, including a change of
|
|
Network Coordinators or even the disbanding of your network. If you have
|
|
been excommunicated by your Network Coordinator, that judgement may be
|
|
reversed, at which point you will be reinstated into your net.
|
|
|
|
If you fail to obtain relief from your Regional Coordinator, you have the
|
|
right to follow the appeal process described in section 9.5.
|
|
|
|
|
|
9.4 Problems with Other Coordinators
|
|
|
|
Complaints concerning annoying behavior on the part of any coordinator are
|
|
treated as in section 9.2 and should be filed with the next level of coordi-
|
|
nator. For example, if you feel that your Regional Coordinator is guilty of
|
|
annoying behavior (as opposed to a failure to perform duties as a coordina-
|
|
tor) you should file your complaint with the Zone Coordinator.
|
|
|
|
Complaints concerning the performance of a coordinator in carrying out the
|
|
duties mandated by policy are accepted only from the level immediately below.
|
|
For example, complaints concerning the performance of Regional Coordinators
|
|
would be accepted from Network Coordinators and independents in that region.
|
|
Such complaints should be addressed to the Zone Coordinator after an appro-
|
|
priate attempt to work them out by direct communications.
|
|
|
|
|
|
9.5 Appeal Process
|
|
|
|
A decision made by a coordinator may be appealed to the next level. Appeals
|
|
must be made within two weeks of the decision which is being appealed. All
|
|
appeals must follow the chain of command; if levels are skipped the appeal
|
|
will be dismissed out of hand.
|
|
|
|
An appeal will not result in a full investigation, but will be based upon the
|
|
documentation supplied by the parties at the lower level. For example, an
|
|
appeal of a Network Coordinator's decision will be decided by the Regional
|
|
Coordinator based upon information provided by the coordinator and the sysop
|
|
involved; the Regional Coordinator is not expected to make an independent
|
|
attempt to gather information.
|
|
|
|
The appeal structure is as follows:
|
|
|
|
Network Coordinator decisions may be appealed to the appropriate Region-
|
|
al Coordinator.
|
|
|
|
Regional Coordinator decisions may be appealed to the appropriate Zone
|
|
Coordinator. At this point, the Zone Coordinator will make a decision
|
|
and communicate it to the Regional Coordinators in that zone. This
|
|
decision may be reversed by a majority vote of the Regional Coordina-
|
|
tors.
|
|
|
|
Zone Coordinator decisions may be appealed to the International Coordi-
|
|
nator. The International Coordinator will make a decision and communi-
|
|
cate it to the Zone Coordinator Council, which may reverse it by majori-
|
|
ty vote.
|
|
|
|
If your problem is with a Zone Coordinator per se, that is, a Zone Coordina-
|
|
tor has committed a Policy violation against you, your complaint should be
|
|
filed with the International Coordinator, who will make a decision and submit
|
|
it to the Zone Coordinator Council for possible reversal, as described above.
|
|
|
|
|
|
9.6 Statute of Limitations
|
|
|
|
A complaint may not be filed more than 60 days after the date of discovery of
|
|
the source of the infraction, either by admission or technical evidence.
|
|
Complaints may not be filed more than 120 days after the incident unless they
|
|
involve explicitly illegal behavior.
|
|
|
|
|
|
9.7 Right to a Speedy Decision
|
|
|
|
A coordinator is required to render a final decision and notify the parties
|
|
involved within 30 days of the receipt of the complaint or appeal.
|
|
|
|
|
|
9.8 Return to Original Network
|
|
|
|
Once a policy dispute is resolved, any nodes reinstated on appeal are re-
|
|
turned to the local network or region to which they geographically or techni-
|
|
cally belong.
|
|
|
|
|
|
9.9 Echomail
|
|
|
|
Echomail is an important and powerful force in ISGNet. For the purposes of
|
|
Policy Disputes, echomail is simply a different flavor of netmail, and is
|
|
therefore covered by Policy. By its nature, echomail places unique technical
|
|
and social demands on the net over and above those covered by this version of
|
|
Policy. In recognition of this, an echomail policy which extends (and does
|
|
not contradict) general Policy, maintained by the Echomail Coordinators, and
|
|
ratified by a process similar to that of this document, is recognized by the
|
|
ISGNet Coordinators as a valid structure for dispute resolution on matters
|
|
pertaining to echomail. At some future date the echomail policy document may
|
|
be merged with this one.
|
|
|
|
|
|
9.10 Case Histories
|
|
|
|
Most of ISGNet Policy is interpretive in nature. No one can see what is to
|
|
come in our rapidly changing environment. Policy itself is only a part of
|
|
what is used as the ground rules for mediating disputes -- as or more impor-
|
|
tant are the precedents.
|
|
|
|
In order to accommodate this process, case histories may be added to or
|
|
removed from this document by the International Coordinator, with such a
|
|
revision subject to reversal by the Zone Coordinator Council. Should Policy
|
|
be amended in such a way to invalidate a precedent, Policy supersedes said
|
|
precedent. (A carefully prepared amendment would address this by removing
|
|
the precedent reference as a part of the amendment.)
|
|
|
|
Although a case may be removed, the text of a case history may not be modi-
|
|
fied by any mechanism. Case history is written close to the time of the
|
|
decision, by those involved with it. Amending the text of a case history is
|
|
the same as revising history, something quite inappropriate in an organiza-
|
|
tion dedicated to moving information.
|
|
|
|
|
|
|
|
10 Appendices
|
|
|
|
10.1 General
|
|
|
|
The Appendices of this document are exceptions to the normal ratification
|
|
process. Section 10.2 can be changed by the appropriate Zone Coordinator,
|
|
and section 10.3 may be modified by the International Coordinator (see
|
|
Section 9.10).
|
|
|
|
|
|
10.2 Timing of Zone Mail Hour
|
|
|
|
Zone Mail Hour is observed each day, including weekends and holidays. The
|
|
time is based upon Universal Coordinated Time (UTC), also known as Greenwich
|
|
Mean time (GMT). In areas which observe Daylight Savings Time during part of
|
|
the year, the local time of zone mail hour will change because ISGNet does
|
|
not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set
|
|
for each zone by the Zone Coordinator.
|
|
|
|
In ISGNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC. In each
|
|
of the time zones, this is:
|
|
|
|
Eastern Standard Time 4 AM to 5 AM
|
|
Central Standard Time 3 AM to 4 AM
|
|
Mountain Standard Time 2 AM to 3 AM
|
|
Pacific Standard Time 1 AM to 2 AM
|
|
Hawaii Standard Time 11 PM to Midnight
|
|
|
|
In ISGNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC.
|
|
|
|
In ISGNet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC. In each
|
|
of the time Zones involved this is:
|
|
|
|
|
|
GMT +12 Zone 6:00 AM to 7:00 AM
|
|
(New Zealand)
|
|
|
|
GMT +10 Zone 4:00 AM to 5:00 AM
|
|
(East Australia)
|
|
(Papua New Guinea)
|
|
(Micronesia)
|
|
|
|
GMT +9.5 Zone 3:30 AM to 4:30 AM
|
|
(Central Australia)
|
|
|
|
GMT +9 Zone 3:00 AM to 4:00 AM
|
|
(Japan)
|
|
(Korea)
|
|
(Eastern Indonesia)
|
|
|
|
GMT +8 Zone 2:00 AM to 3:00 AM
|
|
(Hong Kong)
|
|
(Taiwan)
|
|
(Central Indonesia)
|
|
(Philippines)
|
|
(Western Australia)
|
|
|
|
GMT +7 Zone 1:00 AM to 2:00 AM
|
|
(Malaysia)
|
|
(Singapore)
|
|
(Thailand)
|
|
(Western Indonesia)
|
|
|
|
|
|
10.3 Case Histories
|
|
|
|
|
|
Case histories of past disputes are instructive to show general procedures
|
|
and methods. Any decision may be included in this document by a majority
|
|
vote of either the Zone Coordinator Council or the Regional Coordinators.
|
|
|
|
Policy4 significantly changes the functions of the Zone and International
|
|
Coordinators. In the following cases which were decided using Policy3,
|
|
substitute "Zone Coordinator" for all occurrences of "International Coordina-
|
|
tor(*)".
|
|
|
|
|
|
10.3.1 The Case of the Crooked Node
|
|
|
|
A sysop of a local node was using network mail to engage in unethical busi-
|
|
ness practices. The Network Coordinator became very annoyed at this, and
|
|
dropped the local from the nodelist.
|
|
|
|
The local appealed to the Regional Coordinator for assignment as an indepen-
|
|
dent node. The Regional Coordinator, after checking with the Network Coordi-
|
|
nator, decided that the Network Coordinator was right to be annoyed. Inde-
|
|
pendent status was denied.
|
|
|
|
The International Coordinator(*) did not intervene.
|
|
|
|
|
|
10.3.2 The Case of the Hacker Mailer
|
|
|
|
A sysop of a local node made use of file attaches for extra users to mail
|
|
himself the USER.BBS file from several local boards. The sysops of these
|
|
boards felt annoyed at this, and appealed to their Network Coordinator, who
|
|
agreed and dropped the offending node from the nodelist.
|
|
|
|
The Regional Coordinator was not consulted.
|
|
|
|
The International Coordinator(*) did not intervene.
|
|
|
|
|
|
10.3.3 The Case of the Bothered Barker
|
|
|
|
A local node became annoyed with the Network Coordinator for failing to
|
|
provide services. Repeated complaints to the Network Coordinator did not
|
|
satisfy him, so he appealed to the International Coordinator(*).
|
|
|
|
The International Coordinator(*) dismissed the complaint because the Regional
|
|
Coordinator had not been consulted.
|
|
|
|
The local node submitted the complaint to his Regional Coordinator, who
|
|
investigated the case and discovered that there was some justice to the
|
|
complaint. He advised and assisted the Network Coordinator in configuring
|
|
his system to provide an improved level of service to the local nodes.
|
|
|
|
The Regional Coordinator also decided that the local node was being too
|
|
easily annoyed, in that he was expecting services not normally required of a
|
|
Network Coordinator. The local node was informed as to the true duties of a
|
|
Network Coordinator, and was advised to lower his expectations.
|
|
|
|
|
|
10.3.4 The Case of the Busy Beaver
|
|
|
|
A local node which was operated by a retail establishment was engaged in
|
|
making "bombing runs" to mail advertisements over ISGNet. The Network
|
|
Coordinator felt annoyed and handling the outgoing traffic for a commercial
|
|
operation, and asked the local node to leave the network.
|
|
|
|
The local node applied to the Regional Coordinator, and was granted status as
|
|
an independent node in the region.
|
|
|
|
|
|
10.3.5 The Mark of the Devil
|
|
|
|
A local sysop whose board was used in conjunction with voodoo rites, hacking,
|
|
phreaking, and obscene material applied to a Network Coordinator for a node
|
|
number. The Network Coordinator deemed that this board was exceptionally
|
|
annoying, and denied the request.
|
|
|
|
The Regional Coordinator was not consulted.
|
|
|
|
The International Coordinator(*), on seeing that the Regional Coordinator had
|
|
not been consulted, dismissed the case out of hand. No further appeals were
|
|
made.
|
|
|
|
|
|
10.3.6 The Case of the Sysop Twit
|
|
|
|
A patron of various local nodes had been roundly recognized by all sysops as
|
|
a twit. The user obtained his own system, became a sysop, and applied for a
|
|
node number. The Network Coordinator denied the request. No appeals were
|
|
made.
|
|
|
|
|
|
10.3.7 The Case of the Echomail Junkie
|
|
|
|
A local node became enamored with echomail and joined several conferences,
|
|
routing mail through his network. He then started an echomail conference of
|
|
his own and began relaying echomail between several systems, again routing it
|
|
all through the network.
|
|
|
|
His Network Coordinator observed that network performance was becoming
|
|
seriously impaired. The offending node was told to hold it down. A compro-
|
|
mise was reached whereby much of the echomail traffic was no longer routed
|
|
through the network, and routed echomail was limited to twenty messages per
|
|
night. No appeals were made.
|
|
|
|
|
|
10.3.8 The Case of the Bouncing Board
|
|
|
|
A local user decided to establish a node to promote a worthy charity. The
|
|
machine being used was also used for various other activities during the day,
|
|
and the sysop was often called away. His coworkers would often forget to
|
|
bring the board up at the end of the day while he was away, so the node was
|
|
often down for extended periods. The Network Coordinator, finding the node
|
|
unable to receive mail, would mark it down. The sysop would return, restart
|
|
the board, and ask to be reinstated.
|
|
|
|
The Network Coordinator eventually decided that the sysop was not able to
|
|
maintain a reliable system, and removed him from the nodelist completely.
|
|
Subsequent requests for a node number from the same sysop were turned down.
|
|
No appeals were made.
|
|
|
|
|
|
10.5 Credits, acknowledgments, etc.
|
|
|
|
ISG and ISGNet are registered trademarks of NIGHT-Software,and Andrew Wyatt.
|
|
|
|
|
|
11 Backbone Operating Procedures
|
|
|
|
|
|
11.0 Purpose of this Document
|
|
|
|
|
|
The Backbone Echomail System consists of the Zone Echomail
|
|
Hubs (commonly referred to as "Stars"), Region Echomail Hubs and
|
|
Net Echomail Hubs who help to distribute the Backbone echomail
|
|
conferences. This system is hereafter referred to simply as the
|
|
Backbone.
|
|
|
|
An echomail conference is a message base or forum, distributed
|
|
under a specified echomail conference name, dealing with a defined area
|
|
of interest. Echomail conferences are hereafter referred to simply as
|
|
conferences.
|
|
|
|
Echomail Hubs are nodes who distribute echomail. The Echomail Hubs
|
|
are hereafter referred to simply as Hubs. Zone Hubs distribute
|
|
echomail at the zone level. Region Hubs distribute echomail at the
|
|
region level. Net Hubs distribute echomail at the net level.
|
|
|
|
This document sets forth the operating procedures used by the
|
|
Backbone at the zone level. It describes how the Zone Hubs, and
|
|
those Region Hubs who connect directly to them, operate. The
|
|
operation of the Backbone within a region or net is not covered by
|
|
this document.
|
|
|
|
If any item in this document is in conflict with any existing or
|
|
subsequent General ISGnetnet Policy, then General ISGnetnet Policy
|
|
will be in effect.
|
|
|
|
|
|
11.2 Zone Echomail Coordinator
|
|
|
|
The Zone Echomail Coordinator (ZEC) oversees the operation of the
|
|
Backbone at the zone level. The ZEC coordinates routing and
|
|
schedules to ensure reliable and efficient availability of Backbone
|
|
echomail while avoiding creation of duplicate messages. The
|
|
current ZEC can be identified from the 91/200 listing in the Nodelist.
|
|
|
|
|
|
11.3 Zone Echolist Coordinator
|
|
|
|
The ZEC is responsible for maintaining a list of Backbone
|
|
conferences (Echolist). To assist in this effort, the ZEC appoints the Zone
|
|
Echolist Coordinator. The current Zone Echolist Coordinator can be
|
|
identified from the 91/201 listing in the Nodelist.
|
|
|
|
The Zone Echolist Coordinator compiles and publishes the Echolist
|
|
monthly. It is distributed with the ISGNEWS.
|
|
|
|
The content and format of the Echolist are at the discretion of the
|
|
|
|
Zone Echolist Coordinator, except that it includes the conference's
|
|
name, the Moderator's name, a netmail address listed in a publicly
|
|
available nodelist of any network where the Moderator can be
|
|
reached, a general description of the conference topic, any eligibility
|
|
requirements for restricted conferences, and the network of origin
|
|
for conferences which originate outside of ISGnet.
|
|
|
|
The ZEC personally maintains a text file called ECHOLIST.ISG. This
|
|
is a list of the Backbone conferences in such a format that it can be
|
|
used as a forward-list by programs such as AreaFix. The ZEC
|
|
distributes this list to the Zone Hubs whenever it changes.
|
|
|
|
|
|
11.4 Zone Hubs
|
|
--------------
|
|
|
|
The ZC appoints Zone Hubs (Stars) to distribute Backbone echomail
|
|
at the zone level. The ZEC may also serve as a Zone Hub if [s]he so
|
|
desires.
|
|
|
|
The ZEC makes available a minimum of one connection from each of
|
|
the Zone Hubs to each region. A region may choose to not use all of
|
|
the connections available to it.
|
|
|
|
Each Zone Hub carries all of the Backbone conferences. Each also
|
|
distribute the ECHOLIST.ISG file, as received from the ZEC, to the
|
|
Region Hubs they connect with.
|
|
|
|
The ZEC and Zone Hubs maintain an emergency backup plan should one
|
|
of the Zone Hubs experience problems.
|
|
|
|
Nothing in this provision requires that a ZEC or Zone Hub must
|
|
import any conference to the extent of adverse economic impact.
|
|
|
|
|
|
11.5 Region Echomail Coordinators
|
|
=================================
|
|
|
|
The Region Echomail Coordinator (REC) oversees the operation of the
|
|
Backbone at the region level. The REC coordinates routing and
|
|
schedules to ensure reliable and efficient availability of Backbone
|
|
echomail while avoiding creation of duplicate messages. The
|
|
current RECs can be identified from the 91/2xx (where "xx" = the region
|
|
number) listings in the Nodelist.
|
|
|
|
|
|
11.6 Region Hubs
|
|
----------------
|
|
|
|
The REC appoints Region Hubs to distribute Backbone echomail at the
|
|
region level. The REC may also serve as a Region Hub if [s]he so
|
|
desires. The REC decides which Region Hub connects to each of the Zone Hubs.
|
|
If a REC feels that [s]he needs more than one connection to each of
|
|
the Zone Hubs, [s]he may request extra connections from the ZEC.
|
|
|
|
Region Hubs do not necessarily carry all of the Backbone
|
|
conferences, but all of the Backbone conferences are available through them.
|
|
They also distribute the ECHOLIST.ISG file, as received from the Zone
|
|
Hubs, to those they connect with.
|
|
|
|
Nothing in this provision requires that a REC or Region Hub must
|
|
import any conference to the extent of adverse economic impact.
|
|
|
|
|
|
11.7 Backbone Conference Moderators
|
|
===================================
|
|
|
|
Backbone Conference Moderators (Moderators) preside over
|
|
conferences. The Backbone has no desire to interfere with the
|
|
internal affairs of a conference in so much as they do not disturb
|
|
the operation of the Backbone.
|
|
|
|
A Moderator need not be either a Sysop or a member of ISGnet. If
|
|
the Moderator is not a member of ISGnet, [s]he must list an address
|
|
in a publicly available Nodelist of any network, so that he can be
|
|
contacted if the need arises.
|
|
|
|
|
|
11.8 Duties of Moderators
|
|
-------------------------
|
|
|
|
Moderators are responsible for:
|
|
|
|
1) Seeing that messages in their conference correspond to
|
|
the conference's theme.
|
|
|
|
2) Updating their conference listing in Echolist at least
|
|
every six months.
|
|
|
|
If a Moderator believes that a node is violating a conference rule,
|
|
[s]he may authorize the feed to that node be severed. This
|
|
authorization is made in direct written form (netmail), to the Hub
|
|
feeding the offending node, with a copy to the offending node.
|
|
|
|
|
|
11.9 Recognition of Moderators
|
|
------------------------------
|
|
|
|
A Moderator is recognized as follows:
|
|
|
|
1) Upon formation of a conference, the person who forms the
|
|
conference is the Moderator.
|
|
|
|
2) Upon resignation or replacement of an existing Moderator,
|
|
the conference's rules define how the new Moderator is
|
|
selected.
|
|
|
|
3) Should a conference which originates inside of ISGnet be
|
|
without a moderator for over 30 days, the ZEC may cause a
|
|
Moderator to be selected.
|
|
|
|
Moderators are encouraged to appoint Co-Moderators to assist them
|
|
in their duties and to stand in for them in their absence.
|
|
|
|
|
|
11.10 Operating Procedures
|
|
=========================
|
|
|
|
|
|
11.11 Echomail Message Standards
|
|
-------------------------------
|
|
|
|
FTSC specifications FTS-0001 and FTS-0004 are followed. All
|
|
Backbone nodes use the pathline option.
|
|
|
|
|
|
11.12 Banned Messages
|
|
--------------------
|
|
|
|
The Backbone does not distribute any conference which routinely
|
|
contains messages which are encrypted, contain illegal information
|
|
or promote illegal activities. As used in this paragraph, "illegal
|
|
activities" includes activities which are a violation of civil law
|
|
as well as activities which would result in criminal prosecution.
|
|
|
|
The Backbone does not distribute any conference which routinely
|
|
contains counterfeit messages. A counterfeit message is any
|
|
message entered using another person's name, handle or node address with
|
|
the intent of deceiving others about the true author of the message.
|
|
|
|
|
|
11.13 Censorship
|
|
---------------
|
|
|
|
It is not allowed to delete a message from a conference, or alter
|
|
its contents, in the passing or distribution of Backbone echomail.
|
|
|
|
Exceptions to this provision are the deletion of messages, by any
|
|
node, which may lead to legal action against that node or which do
|
|
not meet the echomail message standards in Section 5.1.
|
|
|
|
|
|
11.14 Adding Conferences to the Backbone
|
|
---------------------------------------
|
|
|
|
The ZEC adds a conference to the Backbone when all of these
|
|
requirements are met:
|
|
|
|
1) The conference is listed in the Echolist.
|
|
|
|
2) The moderator sends a netmail request to the ZEC. [S]he
|
|
should include a copy of the Echolist confirmation
|
|
message if the conference does not appear in the
|
|
currently published Echolist.
|
|
|
|
3) Two RECs request that the Backbone carry the conference
|
|
to their regions.
|
|
|
|
|
|
11.15 Removing Conferences from the Backbone
|
|
-------------------------------------------
|
|
|
|
The ZEC may drop a conference from the Backbone when any of these
|
|
situations occur:
|
|
|
|
1) The conference is not listed in the Echolist.
|
|
|
|
2) The moderator sends a netmail request to the ZEC. The
|
|
ZEC always honors this request.
|
|
|
|
3) There are no longer two RECs requesting that the Backbone
|
|
carry the conference to their regions.
|
|
|
|
4) The Moderator fails to properly carry out his duties, as
|
|
described in Section 4.1.
|
|
|
|
5) The conference is without a Moderator for over 30 days.
|
|
|
|
6) The traffic level in the conference falls below 5
|
|
messages over a two month period).
|
|
|
|
|
|
11.16 Echomail Gateways
|
|
----------------------
|
|
|
|
Echomail Gateways are nodes whose systems are used to exchange mail
|
|
with other groups. The term Gateway, as used hereafter, includes
|
|
all forms of gating including, but not limited to, zone-gating,
|
|
inter-network gating, and domain-gating. Gateways remove foreign
|
|
distribution identifiers (including seen-bys) which might adversely
|
|
affect the distribution of the conference on the Backbone.
|
|
|
|
Gateways also pass netmail into the other network, unless it is
|
|
technically impossible to do so.
|
|
|
|
|
|
11.17 Routed Netmail
|
|
-------------------
|
|
|
|
Backbone nodes accept routed netmail from any node who connects
|
|
with them for Backbone conferences. Any netmail message with a valid
|
|
ISGnet destination, regardless of its origin, is accepted. Routed
|
|
netmail may be routed along echomail paths or to a ZC, RC, or NC
|
|
who has agreed to handle such mail.
|
|
|
|
|
|
11.18 Dispute Resolution
|
|
------------------------
|
|
|
|
All Dispute's will be handled by the Region Coordinator and may
|
|
be appealed to the ZONE COUNCIL.
|
|
|
|
All HUB'S, NEC'S, NC'S, RNEC'S, RC'S and Netmembers will comply
|
|
with the ZONE COUNCIL ruling OR be removed......
|
|
|
|
|
|
11.19 Changes to this Document
|
|
=============================
|
|
|
|
A change to this document may be proposed by any REC. Anyone else
|
|
desiring to propose a change should find a REC who is willing to
|
|
sponsor their proposal.
|
|
|
|
If a second REC concurs with a proposal, the proposed change is
|
|
voted on by all of the RECs. Notice of such a vote is posted both in the
|
|
REC conference and in ISGNews, at least 14 days prior to the start
|
|
of the voting period. The RECs are expected to assess the opinions
|
|
of the members of their regions, and to vote accordingly.
|
|
|
|
The voting period is 7 days. More than 50 percent of those voting
|
|
must vote for a change for it to be accepted.
|
|
|
|
|
|
|
|
12 Cost Recovery Plan
|
|
|
|
** This is not policy but a guide line for nets to set a cost sharing plan. **
|
|
and is modeled after FIDOnet 1:377 and ISGnet 91:5's cost recovery plan.
|
|
|
|
12.1.0.0 Overview
|
|
|
|
This document establishes the Echomail policy and Backbone
|
|
echomail cost sharing plan for SysOps who are members of ISG NETWORK, .
|
|
|
|
This policy implements local policy for the administration of
|
|
Echomail routing and the cost sharing plan for Backbone and
|
|
Regional echomail.
|
|
|
|
This policy will not contradict current ISGNet policy or procedures.
|
|
Other than the enforcement of local echomail policy, in accordance with
|
|
Policy 4 this policy may not place additional restrictions on members of
|
|
.
|
|
|
|
|
|
12.2.0.0 Purpose
|
|
|
|
The purpose of this document is to define the basic Echomail distribution
|
|
system of and a cost sharing plan which will reduce the cost of
|
|
receiving echomail for each Node participating in the plan and to fairly
|
|
distribute those costs among the participating Nodes.
|
|
|
|
|
|
12.3.0.0 Definitions
|
|
|
|
12.3.1.0
|
|
|
|
is defined by the NodeList issued weekly by the
|
|
International SYSOP'S Guild ZEC.
|
|
|
|
12.3.1.1 Echomail
|
|
|
|
For the purposes of this document, ECHOMAIL refers to regional and
|
|
national echomail as defined below. This policy does not in any way
|
|
affect handling of echomail not covered by the definitions of regional
|
|
and national echomail.
|
|
|
|
12.3.1.2 National Echomail
|
|
|
|
Those echoes distributed via the Zone 91 Backbone and listed in the files
|
|
ISGECHO.NA and ISGECHO.LST
|
|
|
|
12.3.1.3 Regional Echomail
|
|
|
|
Those echoes that are available from the Region 216 echomail hubs but are
|
|
not considered national echomail.
|
|
|
|
12.3.2.0 Local Echomail
|
|
|
|
Those echoes originating and distributed within or in cooperation
|
|
with neighboring nets.
|
|
|
|
Distribution of local echomail in is free of charge and not
|
|
included in the Cost Recovery Plan.
|
|
|
|
|
|
12.4.0.0 Organization
|
|
|
|
12.4.1.0 Echomail Coordinator
|
|
|
|
12.4.1.1 Echomail
|
|
|
|
The Network Echomail Coordinator (hereafter referred to as NEC)
|
|
is responsible for the administration of the echomail
|
|
distribution system, and coordinating the collection, distribution and
|
|
routing of echomail within .
|
|
|
|
The NEC provides a daily connection to the Echomail Backbone for
|
|
the collection and distribution of echomail conferences distributed
|
|
throughout .
|
|
|
|
12.4.1.2 Cost Recovery Plan
|
|
|
|
The NEC is responsible for carrying out the enforcement of the Cost
|
|
Recovery Plan as defined below.
|
|
|
|
4.2.0 SysOps
|
|
|
|
The SysOps (referred to as SysOps and Nodes
|
|
interchangeably) are responsible for ensuring the proper operation of
|
|
their systems to preclude the generation of Echomail duplicates.
|
|
|
|
12.4.3.0 Point Operators/Systems
|
|
|
|
Point Operators/Systems are responsible to their Boss Node (operated by a
|
|
SysOp) for the proper operation of their system to ensure
|
|
Echomail duplicates are not generated. The SysOp of the Boss Node is
|
|
responsible for the behavior of it's Points in relation to this policy.
|
|
|
|
12.4.4.0 Distribution of Echomail
|
|
|
|
Distribution of Echomail within will be limited to the
|
|
NEC > HUB > Node > Point topology. Node to Node distribution
|
|
of echomail conferences is prohibited unless approved previously by the
|
|
NEC. These conferences will be bound to the Cost
|
|
Recovery Plan.
|
|
|
|
|
|
12.5.0.0 Cost Recovery Plan
|
|
|
|
The Cost Recovery Plan is designed to reduce the costs of 's
|
|
participation in ISG NetWork Backbone and regional echomail and cover the
|
|
expenses this involves.
|
|
|
|
The Cost Recovery Plan does not include local echoes as their
|
|
distribution does not incur any cost.
|
|
|
|
The Cost Recovery Plan is hereafter referred to as the CRP.
|
|
|
|
12.5.1.0 Participation
|
|
|
|
Participation in the CRP for ISGNet Backbone and Regional
|
|
echomail conferences is voluntary.
|
|
|
|
Each Node who elects not to participate in the CSP must obtain his/her
|
|
own connection for echomail from outside . This link must not
|
|
violate current or future or ISGNET policy or procedures.
|
|
|
|
12.5.1.1 Downlinks
|
|
|
|
Permission from the NEC is required before participating Nodes may pass
|
|
echomail on to participating Nodes.
|
|
|
|
Nodes participating in the CRP may not feed echomail to non-participating
|
|
Nodes.
|
|
|
|
12.5.1.2 Point Systems
|
|
|
|
A Node may pass echomail on to Point Systems provided the echomail is for
|
|
the Point Operator's personal use. If the Point System is a bbs, the
|
|
Point Operator must participate in the CRP to receive echomail feeds from
|
|
a participating Node.
|
|
|
|
12.5.1.3 Tiers
|
|
|
|
Each Node may elect to participate in one of the three tiers of the
|
|
CRP. The tiers differ in cost, the number of echoes a Node may
|
|
carry, and Backbone access.
|
|
|
|
Tier Two Nodes may carry as many echoes as they wish and have unlimited
|
|
Backbone access.
|
|
|
|
Tier one Nodes may carry as many as 10 echoes and have limited Backbone
|
|
access.
|
|
|
|
|
|
Tier One Nodes may only carry echoes that are being carried by Tier Two
|
|
s. When an echo carried by a Tier One Node is no longer carried by a
|
|
Tier Two, the NEC will post a notice in SysOp . If the echo is not
|
|
picked up by a Tier Two or Tier Three Node within 7 days, the echo will
|
|
be dropped from the NEC's system.
|
|
|
|
12.5.1.4 Backbone Access
|
|
|
|
For the purposes of this document, Backbone access refers to the ability
|
|
of a Node to request echomail.
|
|
|
|
If a Node has limited Backbone access, he has access to any echomail echoes
|
|
available on the NEC's system.
|
|
|
|
A Node with unlimited Backbone access has access to any echomail echoes
|
|
available on the NEC's system and any that are carried on the ISG NetWork
|
|
Backbone.
|
|
|
|
12.5.2.0 Cost Recovery Plan Fees
|
|
|
|
The CRP fees are based on an estimate of the cost of full access to
|
|
Backbone and Regional echomail. CRP Schedule I defines a tiered
|
|
approach. Fees for the Nodes electing to participate in Tier Two,
|
|
with unlimited echomail access, are based on these Nodes sharing 86% of
|
|
the total costs. Fees for the Nodes in Tier One, with limited
|
|
echomail access, are based on these Nodes sharing the remaining 14% of
|
|
the total costs.
|
|
|
|
12.5.2.1 Payments
|
|
|
|
CRP payments are due the first of each month from the Node wishes to
|
|
participate. If the NEC has not received payment by the 10th of the
|
|
month, echomail service to the Node will be suspended.
|
|
|
|
If a Node wishes to make advance payments to the NEC, this transaction is
|
|
solely between the two parties involved and outside the realm of this
|
|
policy.
|
|
|
|
12.5.2.2 New Participants
|
|
|
|
New participants who wish to receive echomail prior to or on the 10th of
|
|
the month, must submit the full month's payment. Nodes requesting
|
|
echomail after the 10th but on or before the 20th must submit 50% of the
|
|
full month's payment. Nodes requesting echomail after the 20th will not
|
|
be required to submit that month's payment.
|
|
|
|
The NEC will not begin feeding echomail to a new participant until the
|
|
appropriate fee has been received.
|
|
|
|
12.5.2.3 Reimbursements
|
|
|
|
Participants who wish to drop out of the CRP will receive a reimbursement
|
|
prorated as defined under New Participants.
|
|
|
|
12.5.2.4 Changing Tiers
|
|
|
|
Nodes who change CRP tiers must do so on a prorated basis as defined
|
|
under New Participants.
|
|
|
|
|
|
12.6.0.0 Enforcement of Echomail Policy and Cost Recovery
|
|
Plan
|
|
|
|
12.6.1.0 Failure to submit the Cost Recovery Plan Payment to the
|
|
NEC
|
|
|
|
12.6.1.1 Nodes
|
|
|
|
A Node's failure to submit his/her CRP payment to the NEC by
|
|
the 10th of the month will result in severance of the Node's connection
|
|
to the echomail conferences at the NEC's system.
|
|
|
|
12.6.1.2 Points
|
|
|
|
If a Point required to participate in the CRP as defined in 5.1.2 has not
|
|
made the monthly CRP payment by the 5th, the NEC will send a notice to the
|
|
Point's Boss Node to alert him of the situation. A Points' failure to
|
|
submit his/her CRP payment to the NEC by the 10th of the month
|
|
will result in the Boss Node being requested to sever the connection to
|
|
the echomail conferences to that Point. If the Boss Node does not comply
|
|
with the request the Boss Nodes' connection to echomail at the NEC's
|
|
system will be severed.
|
|
|
|
12.6.1.3 Reconnection
|
|
|
|
Reconnection to echomail after severing for not submitting the month's
|
|
payment will be done only after payment of the entire month's fees have
|
|
been received. The NEC is not required to rescan all the echomail
|
|
conferences the Node was connected to.
|
|
|
|
12.6.2.0 Habitual lateness in submitting CRP Payments
|
|
|
|
Nodes that make payments late for 3 consecutive months will have to make
|
|
payments by the first of the next 3 months before returning to the normal
|
|
schedule of payments.
|
|
|
|
12.6.3.0 Violation of this policy
|
|
|
|
12.6.3.1 Nodes participating in CRP found to be providing a
|
|
connection to echomail for those Points that are required to submit CRP
|
|
payments and have not paid their CRP payments, will have their connection
|
|
to echomail severed.
|
|
|
|
12.6.3.2 The passing of echomail from a CRP participating Node to a
|
|
non-participating Node, or a Node to Node connection that has not been
|
|
previously approved by the NEC will result in the sending Node's echomail
|
|
connection being severed and Node Id removed.
|
|
|
|
12.6.3.3 In the event either of the instances in section 5.3.2 above takes
|
|
place, any CRP payments submitted by the Nodes/Points will not be
|
|
refunded.
|
|
|
|
12.6.4.0 Appeals
|
|
|
|
Should a disagreement regarding the payment of CRP funds arise
|
|
between the NEC and a participating Node the SysOp may appeal the NEC's
|
|
decision to the NC. Such an appeal must be accompanied by proof of
|
|
payment for the disputed period of time. The NC's decision in the
|
|
matter is binding.
|
|
|
|
|
|
12.7.0.0 Security
|
|
|
|
All Nodes picking up echomail from the NEC's system must use password
|
|
protected sessions with the NEC's system.
|
|
|
|
|
|
12.8.0.0 Adopting and Amending this policy
|
|
|
|
12.8.1.0 Submission
|
|
|
|
This policy will be submitted to the SysOps for ratification.
|
|
|
|
12.8.2.0 Voting
|
|
|
|
12.8.2.1 Voting for ratification of this policy will take place within two
|
|
weeks of presentation to the SysOps.
|
|
|
|
12.8.2.2 Only the ISG Network Nodelisted SysOps are eligible to vote.
|
|
Point Operators are not eligible. Those SysOps having more than one
|
|
Nodelist entry are allowed only one vote.
|
|
|
|
12.8.2.3 Votes will be submitted by each Node, via netmail, with a password,
|
|
to the NC or at a meeting called by the NC. At the end of a two week period
|
|
or after all Nodes have voted, The NC will then tally the votes and post the
|
|
results in the Net_Sysop conference.
|
|
|
|
12.8.2.4 A simple majority of votes received will determine whether this
|
|
document is ratified/amended. A simple majority consists of 51% of the
|
|
votes received being in favor of adopting/amending this document.
|
|
|
|
12.8.3.0 Amendments
|
|
|
|
Amendments to this document will be submitted to the NC. The NC will
|
|
submit the proposed changes to as a whole for voting as
|
|
described above.
|
|
|
|
|
|
|
|
ADDENDUM I
|
|
|
|
Monthly Schedule of Payments
|
|
|
|
|
|
1st of month -- payments due
|
|
5th of month -- late notices sent out
|
|
11th of month -- feeds suspended if payment not received
|
|
25th of month -- reminders for next month's payment sent out
|
|
|
|
|
|
Tier Number of Cost/month Backbone Access
|
|
echoes
|
|
Two 11 + $12.00 unlimited
|
|
One 3 - 10 $ 8.50 limited
|
|
|
|
|
|
|
|
Notices:
|
|
Notices will be sent out via netmail by the NEC. Should the
|
|
notices not be issued, the Nodes are still responsible for
|
|
the payments.
|
|
|
|
|
|
ADDENDUM II
|
|
|
|
Schedule of Payments for New CRP Participants
|
|
|
|
|
|
Tier Number of Day Day Day Backbone
|
|
echoes 1-10 11-20 21-31 Access
|
|
|
|
Two 11+ $12.00 $6.00 free unlimited
|
|
One 1 - 10 $ 8.50 $4.25 free limited
|
|
|
|
|
|
|
|
Note:
|
|
Unlimited access is available to upper tier Nodes joining
|
|
before the 21st of the month and is available to those
|
|
joining after the 20th when the first full monthly payment
|
|
is made.
|
|
|
|
|
|
|
|
|