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.