Zone 2 Echopol
Denis Mcmahon, 2:251/20
March 31st 1998
Table of Contents
=================
1. Prologue
1.1. History
1.2. Application and Scope
2. Definitions
2.1. Echomail
2.2. Echo
2.3. Moderated Echo
2.4. Zone Echo Co-Ordinator (ZEC)
2.5. Region Echo Co-Ordinator (REC)
2.6. Net Echo Co-Ordinator (NEC)
2.7. Echo Backbone
2.8. Echo List
2.9. Automated Censorship
2.10. Fidonet Policy
2.11. Terminal Node
2.12. Echo Hub
2.13. Echo Moderator
2.14. Gateway
2.15. Sysop
2.16. User
2.17. ZC
2.18. Echomail Feed
2.19. Inheritance
2.20. Zone
2.21. Region
2.22. Net
3. Duties Of Echo Co-Ordinators Etc.
3.1. ZEC
3.2. REC
3.3. NEC
3.4. Echolist Keeper
3.5. Echo Moderator
3.6. Echo Hub
3.7. Sysop
3.8. User
3.9. Gateway
3.10. ZC
3.11. Echomail Feed
4. Regulation Of Echoes
4.1. Basic Principles
4.2. Moderation
4.3. Gross Misconduct
4.4. Disconnection
4.5. Complaint Against Moderator
4.6. Regulation of Moderator
4.7. Inter-Zone Dispute
4.8. Backbone
5. Selection And Removal Of Zone Echo Co-Ordinator And Moderators
5.1. Grandfather Clause
5.2. General Principles
5.3. Election and Removal Of ZEC
5.4. Selection and Removal Of Moderator
6. Statement Of Policies
6.1. Basic Policy
6.2. No Modification
6.3. Inter-Network Echoes
6.4. Sysop's Responsibility
6.5. Echomail Software
6.6. Routing Of Echoes
6.7. Topology and Duplicate Messages
6.8. Technical Message Standards
7. Adoption Of Echomail Policy
7.1. Adoption
7.2. Grandfather Clause
7.3. Enforcement
7.4. Region And Net Echomail Policies
7.5. Modification of Echomail Policy
7.6. Revocation and Replacement Of Echomail Policy
8. Footnotes
1. Prologue
===========
1.1. History
~~~~~~~~~~~~
Echomail is variously described as the sharing of message bases or
conferences between various independent network addresses, distributed
electronic conferencing etc. The Echomail concept started with a series of
programs by Jeff Rush. Since the original implementation, many authors have
written programs improving on the original idea. In spite of worries that
the flow of Echomail would increase Network traffic to the point that the
Network would collapse under its own weight, Echomail has been a success, to
the extent where it is now a principle part of Fidonet traffic. To simplify
the distribution of Echomail, Echomail Backbones exist whose primary purpose
is the distribution of Echomail, and consist of the Echomail Hubs. As a
result of the growth of Fidonet and the increase in the volume of Echomail,
it has become necessary to set forth a formal policy governing Echomail.
1.2. Application and Scope
~~~~~~~~~~~~~~~~~~~~~~~~~~
This document sets forth policy governing Echomail conferences and their
distribution within Fidonet Zone 2. This Policy applies to Zone 2 Backbone
Echomail conferences. This policy may be adapted for use at Regional and
Net levels, or for use within other zones, but is written specifically for
Zone 2 conferences. The adoption of this policy at the Zone level does not
apply it to local Intra-Region and Intra-Net level conferences.
2. Definitions
==============
2.1. Echomail
~~~~~~~~~~~~~
Electronically distributed text conferencing between Fidonet Nodes.
2.2. Echo
~~~~~~~~~
An electronically distributed textual forum for discussion where all
messages entered by any participent are received by all subscribers to the
Echo.
2.3. Moderated Echo
~~~~~~~~~~~~~~~~~~~
A Moderated Echo is an Echo for which a Moderator exists to supervise the
flow and content of the Echo. All Echoes carried on the Backbone must be
Moderated.
2.4. Zone Echo Co-Ordinator (ZEC)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The individual responsible for coordination of Echomail on a Fidonet Zone
level.
2.5. Region Echo Co-Ordinator (REC)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A voter in the ZEC election and policy replacement processes. Other duties
may be defined by a Region Echomail Policy.
2.6. Net Echo Co-Ordinator (NEC)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A voter in the ZEC election and policy replacement processes. Other duties
may be defined by a Region Echomail Policy.
2.7. Echo Backbone
~~~~~~~~~~~~~~~~~~
The Echo Backbone consists of voluntary members who provide services to
enhance the distribution of Echoes. The Backbone consists of Nodes which
handle a high volume of Echomail traffic, carry most or all of the Echoes in
the Zone Echolist and carry out the distribution of those Echoes (Echo Hubs).
2.8. Echo List
~~~~~~~~~~~~~~
The Echo List identifies the Backbone Echoes, the Echo Moderators and their
netmail addresses, and contains a short description of each echo. The ZEC
appoints the keeper of the Echo List.
2.9. Automated Censorship
~~~~~~~~~~~~~~~~~~~~~~~~~
The term 'Automated Censorship' refers to programs which cause messages in
transit to be removed from the intended Echo or have their content altered,
based upon some arbitary comparison of message content or header field with
some predefined value. Automated Censorship does not apply to programs
designed to act solely upon the messages held on a public access BBS system,
nor does it apply if used to remove messages based solely upon those
messages containing specific words or phrases which are prohibited from use
in electronic communications by any local, regional or national statute
applicable to the governmental domain in which the system is located.
2.10. Fidonet Policy
~~~~~~~~~~~~~~~~~~~~
The document which governs Fidonet as adopted by Fidonet. All Fidonet Nodes
are required to comply with General Fidonet Policy, and nothing herein
removes or lessens in any way that requirement.
2.11. Terminal Node
~~~~~~~~~~~~~~~~~~~
A Node which does not process Echomail for pickup by another system. From
the viewpoint of an echo, a gateway to another FTN or non-FTN network is a
terminal node, whereas a gateway node to another FidoNet zone (as defined by
the FidoNet Nodelist) is not a terminal node, irrespective of the
communication methods and protocols used.
2.12. Echo Hub
~~~~~~~~~~~~~~
A Node which carries most or all of the Echoes in the Echolist for
distribution to other Nodes in the zone. It is hoped that each Region within
the Zone will contain at least one Echo Hub carrying Zone Echomail Backbone
Echoes.
2.13. Echo Moderator
~~~~~~~~~~~~~~~~~~~~
The Moderator is the voice, embodiment and representative of the Echo Users.
The Moderator defines, monitors and guides discussion within an Echo, and if
neccessary instigates any action to ensure compliance with this document and
the Echo rules. The Moderator is identified by the User name and network
address in the Echolist.
2.14. Gateway
~~~~~~~~~~~~~
A Node which interfaces between Zone 2 Backbone Echomail conferences and
some other medium for electronic conferencing, whether another Fidonet zone,
or another FTN based or non FTN based network.
2.15. Sysop
~~~~~~~~~~~
This is the Sysop of a Fidonet system as listed in the Fidonet Nodelist.
2.16. User
~~~~~~~~~~
This is any User of an Echomail area, ie one who writes messages in that
Echomail conference. A User may also be a Fidonet Sysop, a person logging
onto a BBS which has Fidonet Echomail areas available for Users to write in,
or a person operating as or using a Point system to write messages in
Fidonet Echo areas.
2.17. ZC
~~~~~~~~
This is the Fidonet Zone Nodelist Co-Ordinator responsible for Nodelist
maintenance within the Zone.
2.18. Echomail Feed
~~~~~~~~~~~~~~~~~~~
Any Node which feeds Echomail to one or more other Nodes.
2.19. Inheritance
~~~~~~~~~~~~~~~~~
Inheritance refers to the handing on of an echo from the echo founder to
subsequent moderators.
2.20. Zone
~~~~~~~~~~
A FidoNet Zone, as defined in the FidoNet Nodelist, is collectively those
systems appearing between a Zone identifier line and the next subsequent
Zone identifier line, or the end of the nodelist.
2.21. Region
~~~~~~~~~~~~
A FidoNet Region, as defined in the FidoNet Nodelist, is collectively those
systems appearing between a Region identifier line and the next subsequent
Zone or Region identifier line, or the end of the nodelist.
2.22. Net
~~~~~~~~~
A FidoNet Net, as defined in the FidoNet Nodelist, is collectively those
systems appearing between a Host identifier line and the next subsequent
Zone, Region or Host identifier line, or the end of the nodelist.
3. Duties Of Echo Co-Ordinators Etc.
====================================
3.1. ZEC
~~~~~~~~
It is the duty of the ZEC to provide guidance and assistance to Sysops,
Moderators and Echo Users to ensure the smooth and trouble free distribution
of Echomail. The ZEC also maintains a list of and recognises the Zone
Echomail Hubs. The ZEC may also be requested to act in arbitration of
disputes arising from Region or Net level echomail policies. In such cases,
prior to arbitration, all parties to the dispute must agree to acept any
decision of the ZEC as binding.
3.2. REC
~~~~~~~~
It is the duty of the REC to represent the Region in ZEC elections and
Echopol Referenda. Other REC duties may be defined by Local Echomail Policy.
3.3. NEC
~~~~~~~~
It is the duty of the NEC to represent the Net in ZEC elections and
Echopol Referenda. Other NEC duties may be defined by Local Echomail Policy.
3.4. Echolist Keeper
~~~~~~~~~~~~~~~~~~~~
It is the duty of the Echolist Keeper to compile and make available a
listing of Echoes on the Backbone whose list they maintain. The content and
format of the list shall be at the sole discretion of the Echolist Keeper,
but shall include the Echo name, Moderator's name and Moderator's netmail
address for each Echo. The Echolist Keeper shall also hold copies of the
requirements applicable to each listed Echo (The Echo Rules). Ideally the
Echolist Keeper should be granted an administrative address by the Zone
Nodelist Co-Ordinator.
3.5. Echo Moderator
~~~~~~~~~~~~~~~~~~~
The Moderator shall be responsible for ensuring that messages contained in
the Echo correspond to the Echo theme and for initiating any action under
section 4 below when they fail to do so. The Moderator shall post the Echo
rules in the Echo at least once a month, and ensure that the Zone Echolist
Keeper has a copy of the current rules.
3.6. Echo Hub
~~~~~~~~~~~~~
An Echo Hub shall carry all of the Backbone Echoes, except for any which
they notify the ZEC that they reject on a basis of content they find
disagreeable. Hubs shall allow any Node within the Zone to connect to them
to obtain those Echoes. Holding the position of Backbone Hub does not
preclude the Sysop or Node from any other activity within Fidonet.
3.7. Sysop
~~~~~~~~~~
The Sysop has a duty to ensure that all messages from a Node are technically
compliant with Echomail requirements, and to ensure that Users of their
system (including themselves) are aware of and comply with Moderators rules.
3.8. User
~~~~~~~~~
Users have a duty to ensure that they are aware of and comply with
Moderators rules.
3.9. Gateway
~~~~~~~~~~~~
Gateway operators have a duty to ensure that the operation of the Gateway
and the messages passed through it do not interfere with the smooth
operation and distribution of the conference on either side of the Gateway.
3.10. ZC
~~~~~~~~
The ZC has the sole duty under this policy of ensuring that in the absence
of a Zone Echomail Co-Ordinator, one is elected. The ZC is also graciously
requested by this policy to recognise the ZEC and Zone Echolist Keeper with
Zone level administrative addresses.
3.11. Echomail Feed
~~~~~~~~~~~~~~~~~~~
The Echomail feed, when asked by the Moderator to cut the link to another
Node, has a duty to consider the request of the Moderator and take whatever
action they believe appropriate in accordance with this policy.
4. Regulation Of Echoes
=======================
4.1. Basic Principles
~~~~~~~~~~~~~~~~~~~~~
It is recommended that at all times discussion and mediation are considered
preferable to disconnection, and that all parties should attempt to resolve
any differences in an amicable manner. Should an amicable resolution be
unatainable, then action may be taken as follows.
4.2. Moderation
~~~~~~~~~~~~~~~
When a breach of Echo rules is discovered by a Moderator, they should
initially contact the User concerned and request that the User comply with
Echo rules and Echo policy. Should the User fail to comply with the request
the Moderator should then ask the Sysop of the Node to withdraw the Users
write access to the Echo. Should the Sysop fail to comply, the Moderator may
request that the feed of the Echo be removed from the Node concerned.
4.3. Gross Misconduct
~~~~~~~~~~~~~~~~~~~~~
A Moderators rules may on occasion allow instant removal from the Echo for
gross misconduct by a User. For this to be enforced, the behaviour exhibited
must be defined as gross misconduct in the current Echo rules, i.e. the last
set of rules posted in the Echo and held by the Echo list Co-Ordinator.
Should a Sysop fail to comply with the request of a Moderator to prevent a
Users access under these circumstances, the Moderator may request that the
feed to the Echo be removed from the Node concerned.
4.4. Disconnection
~~~~~~~~~~~~~~~~~~
A request that you disconnect a feed to another Node will originate from the
Moderator of the Echo, or in exceptional circumstances from the ZEC. Such
requests should clearly state the reason for the request. You are not
compelled to comply with the request, but failure to do so may lead to the
same request being made to the system that feeds the Echo to you. Any
Backbone Hub that fails to comply with such a request may be deemed to be in
breach of this policy, and may be removed from that post.
4.5. Complaint Against Moderator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Echo complaints should be filed at the Moderator level first. If a User or
Sysop is unhappy with the Moderators decision then they have the right to
appeal to the ZEC. Complaints against a Moderator's will only be considered
once all moerator requested disconnections have been enacted. A complaint
against the Moderator of an Echo will usually lead to an attempt at
mediation of the dispute by the ZEC. Whilst the majority of the Users of an
Echo appear content with the actions of the Moderator, the ZEC may not take
any action against the Moderator in response to a Sysop or User complaint.
4.6. Regulation of Moderators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regulation of Moderators actions is considered under section 5.4 of this
document.
4.7. Inter-Zone Dispute
~~~~~~~~~~~~~~~~~~~~~~~
Where either the Moderator or the offending system is in a different Zone,
the Echo policy in force for the Zone in which the Moderator resides should
be applied. Where it is impossible to obtain a satisfactory conclusion to
the matter, the inter-zone link may be cut on request of the Moderator.
4.8. Backbone
~~~~~~~~~~~~~
An Echo may be added to the Backbone only by request of the Moderator. The
criteria for Backbone listing of an Echo will be:
a) Unique Name
No new Echo will be allowed which duplicates a name already known to exist
on any Backbone.
b) Rules
The Moderator must submit a copy of the rules for the Echo.
c) Moderator
The Moderator must be clearly identified and contactable by netmail.
In addition, a further two criteria may be defined for an Echo to remain on
the Backbone:
d) Traffic
The ZEC may define a minimum traffic requirement for Backbone Echoes.
e) Connectivity
The ZEC may define a minimum connectivity requirement for Backbone Echoes.
The ZEC shall review the status of Backbone Echoes every 3 months. Where an
Echo fails to comply with condition (c) above, the ZEC may instigate an
election for Moderator. In the case of non compliance with conditions (d)
and (e), the ZEC may advise the Moderator that if the criteria are not met
within 3 months the Echo may be removed from the Backbone. Conditions (d)
and (e), where they exist, may be waived in respect of individual Echoes by
the ZEC. The granting of such waiver to a single Echo does not convey any
entitlement to a waiver to any other Echoes. Echoes may only be removed for
failure to meet traffic and connectivity criteria if the failure is still
apparent three months after the Moderator is made aware of the failure.
The Moderator may request removal of their Echo from the Fidonet Backbone
distribution at their discretion.
5. Selection And Removal Of Zone Echo Co-Ordinator and Moderators
=================================================================
5.1. Grandfather Clause
~~~~~~~~~~~~~~~~~~~~~~~
The Zone Echo Co-Ordinator currently holding that position as of the date
of acceptance of this Policy shall continue to serve in said capacity until
resignation or two years from the date of appointment has elapsed, whichever
is the sooner.
Elected moderators holding that position as of the date of acceptance of
this Policy shall continue to serve in said capacity until resignation or
two years from the date of election has elapsed, whichever is the sooner.
Non-elected moderators may not be removed or replaced under this policy, and
will continue to hold their position until such time as they relinquish it.
5.2. General Principles
~~~~~~~~~~~~~~~~~~~~~~~
Elected post-holders shall serve for a period of two years, after which they
may stand for re-election.
Those entitled to vote in election are also entitled to vote for removal of
a postholder.
A moderator who has inherited the echo from a previous moderator may not be
removed from the post.
Elections shall be held with a timescale of 2 weeks for declaration of
candidates, 3 weeks for hustings and debate, and 3 weeks for voting. A
Returning Officer will be appointed by the person calling the election. The
Returning Officer may be the person calling the election.
The winner is the candidate receiving most votes. In the event of two or
more candidates coming 'equal first', a run-off election will be held
between those candidates, such run-off to be a 2 week notification and 3
week voting period.
Results will be published in a manner that allow all voters to confirm that
their votes have been applied according to their wishes and enable non
voters to confirm that their votes have not been falsely applied, but which
do not allow the determination of which candidate any individual voted for.
The date of election is the date on which the Returning Officer announces
the succesful candidate.
No individual may cast more than one vote in any round of any election.
An elected post-holders term of office is two years from the date of
election.
No candidate may also act as the Returning Officer for an election, and the
Returning Officer for an election may not stand as a candidate in that
election.
5.3. Election and Removal of ZEC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Upon resignation, removal or end of term of the ZEC, the outgoing ZEC, or if
they are not available the ZC will call an election.
The *ECs within the Zone may vote. If a Region or Net has no EC, then that
Region or Net foregoes it's vote. If a Region or Net is undergoing EC
selection, then either the outgoing EC, any temporary EC or the EC elect may
vote, but only one vote may be cast on behalf of the Region or Net.
The ZC will call for a removal vote if approached by 25% of the Zone's ECs
requesting such a vote in any calendar month.
If the ZEC is removed, an election shall be called as described above.
A vote to remove the ZEC from that post may only be invoked once during each
term of office. In such an vote, the choices will be to (i) Remove the ZEC
and (ii) retain the ZEC.
A ZEC removed from office is not barred from standing in any subsequent
election.
5.4. Selection and Removal of Moderator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choice of moderator may be by one of two methods, election or inheritence.
Inheritence is where the echo has been passed to the current moderator's
nominee since the echo was founded, and under these conditions the outgoing
moderator may choose to nominate the next moderator, or to hold an election.
Where an echo has no moderator, or the existing or any previous moderator was
an elected moderator, subsequent moderator selection is by election.
Where an election is to be held, the outgoing or resigning Moderator shall
call the election. In their absence, the ZEC may call the election. The
person calling the election may appoint a third party (the Returning
Officer) to actually administer the electoral process, or may do so
themselves.
All Users of the Echo may stand as candidates and vote. Users of the Echo
will be determined by a method decided upon by the Returning Officer.
The ZEC shall call for a removal vote if approached by 25% of the Echo Users
requesting such a vote.
The Users of the Echo may vote.
The ZEC may remove a Moderator for failure to comply with this policy. A
failure to comply with a request of the ZEC, or to follow the guidance or
advice of the ZEC, is not a failure to comply with this policy.
If a Moderator is removed, an election shall be called as described above.
A non-elected Moderator, whether the original Moderator of an Echo or one
who has inherited the Echo from a previous Moderator may not be removed. In
the case where the Users do not accept the Moderator, they should leave the
Echo and initiate an alternative one. Where the ZEC feels that the Moderator
has acted in breach of this policy, they may remove the Echo from the
Backbone.
6. Statement Of Policies
========================
6.1. Basic Policy
~~~~~~~~~~~~~~~~~
The basic policy of Echomail is to promote communication in Echoes in a
lawful, friendly manner consistent with the general principles of Fidonet.
The maximum sanction available under this policy for any breach of this
policy is the removal of Echomail connectivity.
6.2. No Modification
~~~~~~~~~~~~~~~~~~~~
Echomail passing through a system should not be modified except for the
addition of control information relevant to it's processing. The use of
Automated Censorship in the passing or distribution of Echoes is considered
to be unacceptable behaviour. No Echomail shall be modified in any manner
which could potentially cause duplicates. Doing either will be grounds for
removal from the any Zone Echo-Hub post, and offending systems may have
their Zone Echomail links cut.
6.3. Inter-Network Echoes
~~~~~~~~~~~~~~~~~~~~~~~~~
Inter-Network links should be operated in a manner that complies with the
technical and administrative requirements of both networks.
6.4. Sysop's Responsibility
~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is the responsibility of each Sysop to make every reasonable effort to
ensure that messages from their system comply with this policy.
6.5. Echomail Software
~~~~~~~~~~~~~~~~~~~~~~
Use of Echomail software which does not conform to the minimum acceptable
standards as defined by the Fidonet Technical Standards Committee (FTSC) may
lead to requests by Moderators or the ZEC that Echoes be disconnected from
the Node concerned.
6.6. Routing Of Echoes
~~~~~~~~~~~~~~~~~~~~~~
Routing of Echoes without the prior consent of the Node being routed through
may be refused by that Node.
6.7. Topology and Duplicate Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Where duplicate message creation due to topology is detected, the Echo
Moderator with the advice if needed of the ZEC will identify loops and
request that the Nodes in that loop reconfigure their Echo connections to
break the loop.
6.8. Technical Message Standards
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Until the adoption of a superseding standard by the Fidonet Technical
Standards Committee, the following Echomail message standards will apply,
but any or all of these may be relaxed in respect of an individual echo by
the Moderator for testing purposes, or to allow improved communication:
a) ASCII / ANSI Codes
(i) Characters in the ASCII code range 128-255 (except for national
characters by Moderator approval in specified Echoes); (ii) non-printing
low-order codes (Ascii 2-31) (except as used in Echomail as control
characters); and (iii) ANSI codes (except in Echoes specifically for the
purpose of distributing ANSI content) are not permitted. Echo Backbone Hubs
may refuse to list any Echoes carrying such characters. The Echolist Must
identify Echoes which allow any of these.
b) Origin Lines
Origin lines are limited to 79 characters including the required ending of a
proper network address (i.e. Zone:Net/Node.Point with Point being optional)
enclosed in brackets thus (address).
c) Tear Lines
Tear lines are limited to 35 characters including the required '--- '
lead-in. Messages may only contain a single tear line.
d) 'Extra' Origin Lines
'Extra' origin lines (Gateways) are limited to essential information only.
This consists of the required lead-in plus the network name 'Gateway' and
optionally the software Id followed by a Zone:Net/Node address.
Example: ' * Origin: Fidonet Gateway (Tcomm 88:372/666)'
e) Seen-By Lines
Seen-By addresses must be in sorted order. Multiple Akas are not allowed in
Seen-By lines unless you have more than one address which processes mail, or
for one month during change of an existing address (to avoid duplicates to
the previous address). Tiny Seen-Bys and the stripping of Seen-Bys (except
at Gateway Nodes) are not permitted.
f) Path Lines
The Pathline is required except for terminal Nodes.
g) FTSC Standards
All current appropriate FTSC Standards must be followed.
7. Adoption Of Echomail Policy
==============================
7.1. Adoption
~~~~~~~~~~~~~
This policy shall become effective upon adoption by the ZEC. The ZEC may
solicit comment from other parties as to the suitability of this document
prior to it's implementation, such other parties may include, but are not
limited to, RECs, NECs, Sysops, Echo Users and Moderators, NCs, RCs and the
ZC. The ZEC is not compelled to either seek or abide by the sentiments
expressed in such comment.
7.2. Grandfather Clause
~~~~~~~~~~~~~~~~~~~~~~~
Within 60 days of adoption of this policy, Moderators shall be elected for
all Backbone Echoes which do not now have a Moderator. In the case where
more than one individual claims to be the Moderator and no agreement can be
reached, the ZEC may remove the Echo from the Backbone.
7.3. Enforcement
~~~~~~~~~~~~~~~~
Enforcement is immediate, with any currently existing software allowed 60
days to conform. A 30-day extension may be granted solely at the discretion
of the ZEC if efforts to bring about compliance are clear. Continued use of
aberrant software after this period shall be grounds for disconnection of
affected Echoes from a Node.
7.4. Region And Net Echomail Policies
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Local Echomail policies should be adopted by all Regions within the Zone,
such policies dealing with REC selection and the handling of Echomail at the
Region level. Nets may also wish to adopt policies for NEC election and the
handling of Echomail at the net level, or such matters may also be defined
in Regional policies. Regional and Net policies may not assign any duty or
responsibility to the ZEC beyond those defined in this document, nor may
they contradict this document in application to Zone Backbone Echoes.
7.5. Modification of Echomail Policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ZEC may modify echomail policy to meet the changing needs and requirements
of echomail distribution within the zone. Any modification made by ZEC must
be reversed should a majority vote of either all RECs within the one, or of
all NECs within the zone, or of all *ECs within the zone call for that
modification to be reversed. ZEC may not remove from or diminish the
entitlement of *ECs to collectively reverse any policy modification made by
ZEC. ZEC will maintain an echo available for all *ECs, Moderators, Hubs and
any other interested parties to discuss echomail policy, and in which ZEC
will announce any modifications to echomail policy.
7.6. Revocation and Replacement Of Echomail Policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This policy may be revoked by a majority vote of the ECs within the Zone.
Any such vote must clearly identify the policy document to replace this
document, and the revocation and replacement will only occur if more than
50% of those voting indicate a preference for the replacement document.
8. Footnotes
============
These footnotes are editorial comment, and are intended to be informative.
1. This proposal has been derived From Echopol2 Draft 3 by Denis McMahon,
with contribution, comments and input from: Vladimiro Macedo, Michiel van
der Vlist, Verner Olsen, Kim Andersen, Dave Langridge, and Frank Peterson.
Echopol2 Draft 3 was authored by Steve Woodmore, with contribution, comments
and input from: Bill Birrell, Bernd Hohmann, and Denis McMahon.
Additional input and comments have been made by Steve Stacher, Cliff Harold,
Mats Wallin, Werner Dworak, Rafal Wiosna, Martyn Wilkins, Bill Hayles,
Ward Dossche, Rene Laederach and Frank Ellermann.
2. The inclusion of any name above indicates that at some point in the
development of this document that person has made a comment or remark that
has shaped the document in some way, and does not indicate any endorsement
of this document by the persons named.