R B B S - N E T Policy and Procedures Guide Draft 1.7 April 29, 1990 Section Page ------- ---- 1 Overview ...................................................... 3 1.1 Objectives ................................................ 3 1.2 Background ................................................ 3 1.3 Definitions ............................................... 3 1.4 The Levels of RBBS-NET .................................... 4 2 Sysop Procedures .............................................. 5 2.1 How to get a node number .................................. 5 2.2 If you are going down ..................................... 6 2.3 How to join a network ..................................... 6 2.4 How to form a network ..................................... 7 3 Network Coordinator Procedures ................................ 8 3.1 Routing inbound mail ...................................... 8 3.2 Assigning node numbers .................................... 8 3.3 Maintaining the Node List ................................. 8 3.4 Passing along Node Lists and RBBS-NET News ................ 9 4 Network Administration Procedures ............................. 10 4.1 Assigning node numbers .................................... 10 4.2 Encouraging the formation and growth of networks .......... 10 4.3 Assigning network numbers ................................. 11 4.4 Maintaining the Node List ................................. 11 4.5 Overseeing network operations ............................. 12 4.6 Passing along Node Lists and RBBS-NET News ................ 12 5 EchoMail Conferences .......................................... 13 6 RBBS-PC Network Contact People ................................ 17 7 Acknowledgments ............................................... 18 RBBS-PC Network Policy and Procedures Page 2 Chapter 1 OVERVIEW 1.1 Objective To connect RBBS-PC System across the Nation into a FidoNet Compatible Network for the "Free Exchange of Information." We (The RBBS-PC Network) have no intentions of trying to replace or compete with the existing FidoNet Network. We (The RBBS-PC Network) only want a means of communicating directly with other RBBS-PC SysOps across the nation and to enhance the transmission of messages across the nation and to further develop RBBS-PC. This document is an attempt to describe the procedures which have been developed to manage The RBBS-PC Network (RBBS-NET). 1.2 Background FidoNet is an amateur electronic mail system. From its early beginnings as a few friends swapping messages back and forth, it has now grown to (January 1989) over 4000 different systems on four continents. RBBS-NET is going to provide the resources to a RBBS-PC System Operator (SysOp) with the tools to connect into a Network of other Bulletin Board (BBS) SysOps across the nation. We hope to be able to provide international connectivity also. RBBS-NET will not try to re-invent the wheel. We will adopt most of of the standards that International FidoNet Association has already adopted into their network. 1.3 Definitions RBBS-NET nodes are grouped on several levels. These are as follows: Nodes: A node is a single Net address, and is the smallest recognized unit of the Net. Networks: A network is a collection of nodes, usually in a relatively small geographic area. Networks coordinate their mail activity to decrease cost and increase mail throughput. Hubs: Is another Network within an existing Network. Hubs are treated just like Networks. Therefore, all that applies for Networks ... also applies for Hubs. Regions: (Not applicable) 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. RBBS-PC Network Policy and Procedures Page 3 Zones: (Not applicable) A zone is a large geographic area containing many regions, and covering one or more countries and/or continents. RBBS-NET: This indicates the entire mail network, as designed by the RBBS-PC Network Coordinators and as defined by the weekly Node List. 1.4 The Levels of RBBS-NET With the introduction of The RBBS-PC Network, RBBS-NET has developed the following levels of organization: The Network Coordinator The Network Coordinator compiles all of the Node Lists from all of the Networks and creates the master Node List, which is then distributed across The RBBS-PC Network. The Network Coordinator The Network Coordinator is responsible for maintaining the list of nodes for his network, and for receiving and forwarding any mail coming to the network from the outside. He is also responsible for the maintenance of the members of his network and will insure proper use of the network by those members. The Network Routing Hub Network Routing Hubs exist only in three-tiered networks. They generally share some or all of the duties of the Network Coordinator, in order to ease the management of a large network. The exact duties and procedures are a matter for the Network Coordinator and his hubs to settle, and will not be discussed here. The Network Coordinator is still responsible for the maintenance of the network and insures proper use of the network for the people in his Routing Hub. The System Operator (SysOp) The SysOp formulates his own policy for running his board and dealing with his users, so that will not be discussed in this document. However, the sysop must also mesh with the rest of the RBBS-NET Systems if he is to send and receive mail, and that will be discussed here. The User Policy and procedures for the individual user on any given board is determined by the system operator of that board, and will not be considered in this document. These levels act to distribute the administration and control of RBBS-NET to the lowest possible level, while still allowing for coordinated action over the entire mail system. RBBS-PC Network Policy and Procedures Page 4 Chapter 2 SYSOP PROCEDURES A SysOp of an individual node can pretty much do as he pleases, as long as he observes the mail events, is not excessively annoying to other nodes on RBBS-NET or any other FidoNet Compatible Network and does not promote the distribution of pirated copyrighted software. software. National Mail Hour is the heart of of any NetMail Network, as this is when the network mail is passed between systems. Any system which wishes to be a part of a NetMail Network must be able to receive mail at this time. A system which is a member of a network may also be required to observe additional mail events, as defined by his Network Coordinator. 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 Node List as is practical. The exact timing of National Mail Hour is set for each zone by the International Coordinator, or by his designated Zone Coordinator. In the United States, National Mail Hour is observed from 0900 to 1000 GMT every day, weekends included. In each of the United States time zones, this would be as follows: 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 Networks do not observe daylight savings time. In areas which observe daylight savings time the RBBS-NET mail schedules must be adjusted in the same direction as the clock change. Alternatively, you can simply leave your system on standard time. 2.1 How to get a node number You must first obtain a current Node List 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 Node List is to locate the closest RBBS-NET Bulletin Board System to you. If the SysOp of any RBBS-NET system does not have a Node List available for downloading, then he can probably tell you where to get one. RBBS-PC Network Policy and Procedures Page 5 Once you have a Node List, you must determine which network or region covers your area. If you are unsure of this or there is not one in your area, send the information to the Network Coordinator. Once you have located the network or region in your area, send a request for a node number to node zero of that network or region. The request must be sent by a NetMail message and must include at least the following: 1) Your name. 2) The name of your system. 3) The city and state where your system is located. 4) The phone number to be used when calling your system. 5) Your hours of operation. 6) The maximum baud rate you can support. 7) BBS Software Version. 8) NetMail Interface Program. 9) A list EchoMail Conferences that you wish to pick up. 10) Voice number (Internal use only!). Your coordinator may want additional information. If so, he will contact you. Please allow at least three days for a node number request to be processed. If you send your request to Network Administration, then he may forward your request to the Network Coordinator who covers your area (if any), which may take longer. 2.2 If you are going down If your node will be down for an extended period (more than a day or two), then you should inform your coordinator as soon as possible. If you do not do this, then other systems will still try to reach you while you are down, much to the annoyance of everyone. Do not under any circumstances put an answering machine or similar device on your phone line while you are down. If you do, then calling systems will get the machine repeatedly, racking up large phone bills, which is very annoying. 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 do 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.3 How to join a network If you are an independent node and would like to join a network in your area, you must contact the Network Coordinator. He can be reached by sending RBBS-NET mail to node zero of the network. He will inform you of any special mail schedules and/or routing required by the network. Network Administration will contact you to confirm that you wish to join the network. Once you have been placed in the network, you will be informed by the Network Coordinator. RBBS-PC Network Policy and Procedures Page 6 There are many advantages to being in a network. First and foremost is that it helps reduce congestion of RBBS-NET during National Mail Hour. Also, many networks are "outbound" as well as "inbound", which can substantially reduce your phone bills. In addition, network members receive regular updates of the Node List, while an independent node may not. 2.4 How to form a network If there are several nodes in your area, but no network, then you may wish to form your own. Again, this has several advantages as outlined above. Your 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 is going to be the Network Coordinator. Your next step is to inform Network Administration. You must send him a NetMail message with 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 International Coordinator and the coordinators of any affected networks that a new network is in formation. 2) The name that you wish to call your network. Please try to select a name that relates to your grouping. For example, SoCalNet for nodes in the Southern California Area and MassNet for Massachusetts Area. Remember if you call yourself DOGNET it doesn't help others know what area of the country (or even what country) your group is in. 3) A copy of the proposed network's Node List. The Node List file should be named Rrrr-nnn.NET where rrr is the proposed host's current region or network number and nnn is his current node number. For example, if the proposed host is currently listed as node 5 in region 13, then you would name the file R013-005.NET! This file should be sent attached to the message of Application for a Network Number. SAMPLE FORMAT OF A NEW911.TXT FILE Host,911,Inland_Empire_NET,Colton_CA,Rod_Bowman,1-714-381-6013,9600,XA,CM,HST ,1,The_'PC'_Spectrum_(tm)_RBBS-PC,Colton_CA,Rod_Bowman,1-714-381-6013,9600,XA,C M,HST ,2,Chips_Unlimited_RBBS-PC,Rancho_Cucamonga_CA,Phil_Rheinecker,1-714-989-2603,9 600,RE,WK0100-0500,WE,HST ,10,The_RBBS-PC_Network_Mail_System,Colton_CA,Rod_Bowman,1-714-884-5743,9600,XA ,CM,MO,HST,V32 ; Granting of a network number is not automatic. Network Administration will review your application and inform you of the decision. RBBS-PC Network Policy and Procedures Page 7 Chapter 3 NETWORK COORDINATOR PROCEDURES A Network Coordinator has the following responsibilities: 1) To receive incoming mail for nodes in his network, and to deliver it to its recipients. This mean you have to poll the Mail Distribution System to receive your mail. 2) To assign node numbers to nodes in his network. 3) To maintain the Node List for his network, and to send a copy of it to Membership Services whenever it changes. 4) To pass along to his nodes the new Node List, Node List updates and new issues of RBBS-NET as they are received. 3.1 Routing inbound mail It is your responsibility as Network Coordinator to receive all inbound mail for nodes in your network and to forward it to its recipients. You are left to your own discretion as to how best to accomplish this. If a node in your network is routing large volumes of EchoMail, you can ask him to either limit the amount of EchoMail, or even to stop routing his EchoMail completely. The design of EchoMail is such that it is a simple matter to do either of these. Or they can break off out of your network. 3.2 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. 3.3 Maintaining the Node List You should attempt to implement name changes, phone number changes, et cetera in your Node List as soon as possible, and to forward the revised Node List to Membership Services whenever a change occurs. You should also on occasion send a message to every node in your network to ensure that they are still operational. If a node turns out to be "off the air" with no prior warning given to you, then you can either mark the node as down, place it in the dog house, or remove it from the Node List completely, at your own discretion. RBBS-PC Network Policy and Procedures Page 8 3.4 Passing along Node Lists and RBBS-NET News As a Network Coordinator you should obtain a new Node List update every week. The Node List update is posted weekly on Sundays. The list will be made available to you by Network Administration. You should pass both of these along to your member nodes as soon as is practical after you receive them. It is also desirable that you make them both available for downloading by the general user, but this is not required. The Node Lists are the glue that holds us together. Without them, we cease to be a community, and become just another random collection of bulletin boards. RBBS-PC Network Policy and Procedures Page 9 Chapter 4 NETWORK ADMINISTRATION PROCEDURES Membership Services and RBBS-NET Administration 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. 4) To compile a Node List of all of the networks and independents in the region, and to send a copy of it to the Mail Distribution Node whenever it changes. 5) To ensure the smooth operation of the networks within the region. 6) To make a new RBBS-NET Node List, create a News Letter and make them available to the Network Coordinators in the region as soon as is practical. 4.1 Assigning Node numbers The responsibility to assign node numbers to new network in the region. You may also change the numbers of existing networks in the region, though you should check with the respective nodes before doing so. The numbers assigned to networks must be within the RBBS-NET Network Plan in order for future growth of the region to be possible. You should use network mail to inform a new node of their node number, as this helps to insure that he is capable of receiving network mail. If you receive a node number request from a new node that is in an area covered by an existing network, then you should forward the request to the Coordinator of that network instead of assigning a number yourself. 4.2 Encouraging the formation and growth of networks One of your main duties as a the Network Administration is to promote the growth of networks in the region. You should try to avoid having independent nodes in the 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 commercial system with a large volume of traffic which would clog the network. The resolution of such special cases is left to your own discretion. RBBS-PC Network Policy and Procedures Page 10 If several independent nodes in your region are in a "clump", then you should encourage them to form a network. Refer to the SysOp procedure forming a network on forming a network for details of what information you should get. Note that this does not mean 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 should be according to the plan of the region. 4.3 Assigning network numbers It is your responsibility to assign network numbers to new networks forming within your region. The network numbers are assigned by referring to the RBBS-NET Network Plan. 4.4 Maintaining the Node List Network Administration has a dual role in maintaining the Node List for the 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 Node List as soon as possible. You should also on occasion send a message to every independent node in your region to ensure that they are still operational. If a node turns out to be "off the air" with no prior warning given to you, then you can either mark the node as down, place it in the dog house, or remove it from the Node List completely, at your own discretion. Second, you must receive the Node Lists from the Network Coordinators within your region. You should assemble a master Node List for your region every week and send it to the International Coordinator no later than National Mail Hour on Saturday morning. It is suggested that you do this as late as is practical, so as to accommodate any late changes. You will need to maintain a set of Node Lists for each network within your region, since you cannot count on getting an update from each Network Coordinator every week. RBBS-PC Network Policy and Procedures Page 11 4.5 Overseeing network operations It is the responsibility of Network Administration to ensure that the networks within the 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 seeing to it that the Network Coordinators within your region are acting responsibly. It is the obligation of Network Administration to maintain direct and reasonably frequent contact with the networks in the region. The exact method of accomplishing this is left to your discretion. 4.6 Passing along Node Lists and RBBS-NET News Network Administration is responsible to obtain the latest RBBS-NET Node List updates and any RBBS-NET News issues as they are published, and to make them available to the Network Coordinators within your region. The Node List is posted weekly on Sunday's by RBBS-NET Nodes #8/0 and #8/1. It is your responsibility to distribute these to any Network Coordinators 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. It is also desirable that you make them both available for downloading by the general user, but this is not required. RBBS-PC Network Policy and Procedures Page 12 Chapter 5 ECHOMAIL CONFERENCES EchoMail Conferences are messages that are passed around the nation. These conferences can range from very technical ordinated to very religious. Some may even have offensive language in them. So, it is very important that you only choose the ones that would be of interest to you and/or your users. You can always add and/or delete the conferences that you choose. For a current list of the available EchoMail Conferences, ask your Netmail Manager for the currect list. It will also be available for download and/or file requestable from Membership Services as ECHOLIST.ARC If you are receiving EchoMail Conferences from RBBS-NET, it is mandatory that you NOT forward RBBS-NET or any another Network EchoMail Conferences to NON RBBS-NET Systems. Also, do not accept feeds of the same EchoMail Conference from more than one source. If you do, it will create duplicate messages in EVERYONES Network. Violation of this will not be tolerated! The following are REQUIRED RBBS-NET EchoMail Conferences: RBBS-SYSOP This conference will be the RBBS-NET SysOp's Conference and will be available to all RBBS-NET Nodes. This is also a PUBLIC Conference ... so it can be made available to the callers of your system on an RBBS-NET Node. RBBS-NET This is a PRIVATE Conference which is only available to the RBBS-NET Net Managers. This conference will be used for Net Manager Information between them and RBBS-NET Network Administration. This should be listed in your AREAS.NET File as "sysop-only"! (This Echo Mail Conference is also available to the Hub Manager.) RBBS_DEV This is a PRIVATE Conference which is only available to nodes of RBBS-NET. This conference will be used for the development of The RBBS-PC Network. This should be listed in your AREAS.NET File as "sysop-only" also! This Echo Mail Conference is ONLY for RBBS-NET Development Information and should not be used for anything else. RBBSBITS This is a PUBLIC Conference which is only available to nodes of RBBS-NET. This conference will be used for chatter about the RBBS-NET News Letter. RBBS-PC Network Policy and Procedures Page 13 The following are OPTIONAL RBBS-NET EchoMail Conferences: DOORWARE This is a PUBLIC Conference which is available to all the RBBS-NET Members. This Conference is also Gated into other networks. It is chaired by Rod Bowman who is the one of the authors of for the DOORWARE (tm) Programs and he is also the who created the Standard Door Interface for the use of other Door and BBS Programmers. PROANA This is a PUBLIC Conference which is available to all the RBBS-NET Members. This Conference is also Gated into other networks. It is chaired by Gene Lowry who is one of the authors of the program called: Professional Call Analyzer. The program was written for use with the RBBS-PC Program. RBBS_4SALE This conference will be the RBBS-NET For Sale Conference and will be available to all RBBS-NET Nodes. This is also a PUBLIC Conference ... so it can be made available to the callers of your system on an RBBS-NET Node. RBBS_BETA This is a PRIVATE Conference which is only available to the Beta Testers of the RBBS-PC Software Program. This Conference is chaired by Jon Martin. Access to this Conference can only be granted with authorization by Jon Martin. RBBS_CDROM This is a PRIVATE Conference which is only available to nodes of RBBS-NET. This conference will be used for the discussions of the use of a CD ROM Drive with RBBS-PC. This should be listed in your AREAS.NET File as "SysOp-ONLY" also! RBBS_DOOR This is a PRIVATE Conference which is only available to nodes of RBBS-NET. This conference will be used for the discussions of the use of DOORS with RBBS-PC. This should be listed in your AREAS.NET File as "SysOp-ONLY" also! RBBS_FEND This is a PRIVATE Conference which is only available to nodes of RBBS-NET. This conference will be used for the discussions of the use of a Front End Processor with RBBS-PC (ie BinkleyTerm and DBridge). This should be listed in your AREAS.NET File as "SysOp-ONLY" also! RBBS_HST This conference will be the RBBS-NET High Speed Transfer Conference and will be available to all RBBS-NET Nodes. This is also a PUBLIC Conference ... so it can be made available to the callers of your system on an RBBS-NET Node. RBBS-PC Network Policy and Procedures Page 14 RBBS_MSGTOSS This conference will focus on the MSGTOSS software utility and will be available to all RBBS-NET Nodes. This is also a PUBLIC Conference ... so it can be made available to other SysOps on your RBBS-Net Node system. Host/Moderator: Greg Popovich RBBS_MTASK This is a PRIVATE Conference which is only available to nodes of RBBS-NET. This conference will be used for the discussions of the use of a Multi-Tasking Program with RBBS-PC. This should be listed in your AREAS.NET File as "SysOp-ONLY" also! RBBS_SRC This is a PRIVATE Conference which is only available to nodes of RBBS-NET. This conference will be used for the discussions of RBBS-PC Source Code Changes. This should be listed in your AREAS.NET File as "SysOp-ONLY" also! RBBS_SD This is a PRIVATE Conference which is only available to nodes of RBBS-NET. This conference will be used for the discussions of the Software Distribution Services for RBBS-NET. This should be listed in your AREAS.NET File as "SysOp-ONLY" also! RBBS-TEC This conference will be the RBBS-NET Technical Conference on PC hardware and software, and will be available to all RBBS-NET Nodes. This is also a PUBLIC Conference, which can be made available to all callers on a RBBS-NET Node system. RBBS-VIP This is a PRIVATE Conference which is only available to the RBBS-NET System Operators. This conference will be used as a 'open-aire' forum for all Net/Hub Managers to exchange information between themselves with no restriction on topic. This should be listed in your AREAS.NET File as "SysOp-ONLY"! RBBSMAIL_PACK This is a PUBLIC Conference which is available to all the RBBS-NET Members. This Conference is also Gated into other networks. It is chaired by Jim Oswell and Rod Bowman who are the authors of the program called: RBBSPACK This conference is used as a support Echo for this program as well as the support Echo for the program called: RBBSMail SMLWARE This is a PUBLIC Conference which is available to all the RBBS-NET Members. It is chaired by Darwin Collins who is the author of all of the SMLWare Programs. This Conference will be used to help support those programs. RBBS-PC Network Policy and Procedures Page 15 ZOOM This Conference will be an open forum for ZOOM Modem/SENDFAX equipment. This Conference will be available to all Nodes. It is also a PUBLIC Conference and can be accessable to all callers on your RBBS-NET System. Host/Moderator: Ray Waechter and Bob Germer USC This Conference focuses on the practice and use of USC (Uniform System Code) for DOS directories and FMS. The theme is to support a universally accepted standard for PC users and SysOps to classify and identify files according to a com- monly share code system. This echo will support the broadcasting of new and recent files which are available from SysOps and software authors who have adopted the USC practice and wish to post file descriptions with USC classifications. This Conference is open to all users and sysops. Host/Moderator: Ray Waechter RBBS-PC Network Policy and Procedures Page 16 Chapter 6 RBBS-PC NETWORK CONTACTS Rod Bowman Terry Rossi Network Administration Membership Services Colton, California Medford, New Jersey (D) 714-381-6013 (D) 609-654-0999 RBBS-NET Node #8:8/0 RBBS-NET Node #8:8/10 FidoNet Node #1:10/8 FidoNet Node #1:266/22 Ray Waechter Jim Oswell Software Distribution Administration Backup Downington, Pennsylvania Charlotte, North Carolina (D) 215-269-9729 (D) 704-889-8897 RBBS-NET Node #8:8/11 RBBS-NET Node #8:8/2 FidoNet Node #1:273/303 FidoNet Node #1:379/2 Robert Koewn Jan Terpstra RBBSBits News Editor Europe Gateway Norristown, Pennsylvania Beemster Holland (D) 215-896-9240 (D) 31-2998-3603 RBBS-NET Node #8:8/13 RBBS-NET Node #8:8/2 FidoNet Node #1:273/302 FidoNet Node #1:512/10 Bob Fletcher Australia Gateway Melbourne Australia (D) 61-3-467-7984 RBBS-NET Node #8:8/3 RBBS-PC Network Policy and Procedures Page 17 Chapter 7 ACKNOWLEDGMENTS IFNA The International FidoNet Association for creating standards for Packet Mail to be transmitted across the nation. RBBS-PC Remote Bulletin Board Service Program written by Tom Mack, Jon Martin and Ken Goosens. NetMail DOORWARE Program written by Bob Westcott and Rod Bowman which makes RBBS-NET all possible for RBBS-PC Systems. BinkleyTerm The Front End Program for the Interface to a FidoNet Compatible Network written by Bob Hartman. RBBS-NET The RBBS-PC Network created by Rod Bowman and the help of many others. RBBSPACK The Zone Aware EchoMail Packer and Router Program which was written by Jim Oswell and Rod Bowman. RBBSMail A program written by Jan Terpstra that allows a SysOp pull EchoMail Conferences into RBBS-PC. Bob Westcott For all of his work on the DOORWARE Programs. Kim Wells For all of his work with the interface between RBBS-PC and SeaDog. Bowman Family I would like to thank them for allowing me the time to work on my (expensive) hobby. RBBS-PC Network Policy and Procedures Page 18