Video GameNet Policy
November 2011
Section 1.
Language
The
official language of Video GameNet is English. All
documents must exist in English. Translation into other languages is
encouraged.
Section 2.
Introduction
Video
GameNet is an amateur electronic mail system. As
such, all of its participants and operators are unpaid volunteers.
Video
GameNet 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.
Section 3.
Users
The
sysop is responsible for the actions of any user when they affect the rest of Video
GameNet. (If a user is annoying, the sysop is
annoying.) Any traffic entering Video GameNet via a given node, if not from the sysop, is
considered to be from a user and is the responsibility of the sysop. (See
Article 2, Section 1.c)
Section 4. Individual Systems and System Operators
The
smallest subdivision of Video GameNet 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 Video GameNet
system to send and receive mail, and the local policy must be consistent with
other levels of Video GameNet.
a. 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 Video
GameNet, and do not promote or participate in the
distribution of pirated copyrighted software or other illegal behavior via Video
GameNet.
b. Familiarity with Policy
In
order to understand the meaning of "excessively annoying", it is
incumbent upon all sysops to occasionally re-read Video GameNet
policy. New sysops must familiarize themselves with policy before requesting a
node number.
c. Responsible for All Traffic Entering Video
GameNet Via the Node
The
sysop listed in the nodelist entry is responsible for all traffic entering Video
GameNet 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 Video GameNet via the system, the
gateway system must be clearly identified by Video GameNet
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.
Section 2.
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.
Section 3. 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.
Section 4.
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 Video GameNet. This ideal is often compromised, as Video GameNet 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 the 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. Judgment and common sense should be used in this area as in all other aspects of Video GameNet behavior.
Section 5. 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 Video GameNet 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.
Zone Mail Hour is the heart of Video GameNet, as this is when network mail is passed between systems. Any system, which wishes to be a part of Video GameNet, must be able to receive mail during this time using the protocol defined in the current Video GameNet 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.
A system that 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.
Section 7. 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 Video GameNet bulletin board or visit the Video GameNet website. Most bulletin board lists include at least a few Video GameNet systems, and usually identify them as such. Use a local source to obtain documents because many networks have detailed information available that explains the coverage area of the network and any special requirements or procedures.
If you will be using QWK format for transferring your message packets then you simply need to fill out the application found in the Video GameNet packet and e-mail it back to the main HUB you will be assigned a node number and be ready to poll your mail in a few days.
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 that covers your area, then pick the region that 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 Video GameNet 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 Video GameNet. 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 be forwarded to the appropriate Network Coordinator.
Section 8. 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 that 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 Video GameNet-compatible
software that 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.
Section 9. 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 authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical.
Article III
General Procedures for All
Coordinators
Section 1. Make
Available Different Files and Nodelists
1. Any Coordinator is responsible for obtaining
and making available, on a weekly basis, nodelist difference files and
Nodelists.
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.
Section
2 Network
Coordinator Procedures
1.
Responsibilities
A Network Coordinator has the following
responsibilities:
a. To
receive incoming mail for nodes in the network, and arrange delivery to its
recipients.
b.
To assign node numbers to nodes in the network.
c.
To maintain the nodelist for the network, and to send a copy of it to the
Regional Coordinator whenever it changes.
d.
To make available to nodes in the
network new nodelist difference files, new issues of FidoNews, and new
revisions of Network Policy Documents as they are received, and to periodically
check to insure that
nodes use up to date nodelists.
Section 3. 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 that 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 independent, 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 Video GameNet 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 Article II, Section 5 if you do not
forward the mail.
Section 4.
Assigning Node Numbers
It
is your responsibility to assign node numbers to new nodes in your network. 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 Video GameNet netmail.
This will ensure that the system is minimally operational. The strict
maintenance of this policy has been one of the great strengths of Video GameNet.
It
is also recommended, though not required, that you call a board that 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.
Section 5.
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 Coordinators 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.
Section 6.
Making Available Policies and Nodelists
As
a Network Coordinator you should obtain a new nodelist difference file every
week from your Regional Coordinator. The nodelist difference file is currently
made available whenever changes are made to the nodelist. 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
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.
Section 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 networks, 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 Fiona’s
available to the Network Coordinators in the region as soon as is practical.
Section 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 Video GameNet netmail.
This will ensure that the system is minimally operational. The strict
maintenance of this policy has been one of the great strengths of Video GameNet.
It
is also recommended, though not required, that you call a board that 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 determine. 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.
Article V
Section 1.
General
A
Zone Coordinator for Video GameNet 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 coordinating the distribution of Network Policy documents 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
Coordinators. 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 geographic exemptions as described
in section Article IV, Section 1.6. The
Zone Coordinator is responsible for insuring the smooth operation of gates
between that zone and all other zones for the transfer of impersonal mail. The Zone Coordinators are responsible for the
selection of the International Coordinator from among their ranks.
Section 1.
Nominations
1)
Nodelist Coordinator
2)
Echolist Coordinator
3)
Election Coordinator
4)
Moderators
Section 2.
Responsibilities of elected positions:
1.
Nodelist Coordinator - Responsible for
assigning node numbers, maintaining the nodelist and distributing the nodelist
to the rest of the network.
2.
Echolist Coordinator - Responsible for
approving new echos and maintaining the Video GameNet
backbone and making it available to the rest of the network.
3.
Election Coordinator - Responsible for
scheduling and running the network elections.
4.
Moderators - Responsible for ensuring that
their echo(s) stay on topic and enforcing a no flaming policy. Also responsible
for posting the rules of his/her echo regularly (at least once a month) so that
newcomers can be assured that they will receive fair treatment.