User Agreement Policy By continuing your connection to the AustNet IRC network, and its subsequent servers, you agree to the following conditions. ● Flooding is not tolerated on the AustNet network. Any violations of this rule will result in banning your site and often entire domain from the network. ● Clones are not tolerated on the AustNet network. Any violations of this rule will result in banning your site and often entire domain from the network. ● IRC is an unmoderated medium. No AustNet server, staff member or
provider logs or scrutinizes the traffic which passes through the
servers. We take no responsibility, and explicitly disclaim any legal
liability for the content of any messages which pass through any AustNet
server, and the consequences of running any commands you do as a result
of being “on IRC”. The exception to this includes channel logging,
private message logging and notices (server and otherwise), which is
freely available to any user on the network and may also be used to
later verify events or users if the need arises. ● IRC may not be suitable for children. Please supervise your child’s IRC session. ● We reserve the right to change rules without warning or prior notice. ● Upon connection to our network, you give us express permission to connect to your host for verification. This is done via ident/auth lookups on port 113, and insecure wingate proxy on both ports 23 and 1080. ● We reserve the right to deny access to this server to any users without the need for warning nor explanation. Privacy Policy Collection of personal information by AustNet staff, such as email addresses and IP addresses shall not be harvested from NickOP info, scans, and server notices. Personal email address requests are only requested for NickOP. This information is used to provide two services: Password retrieval and sending logs from ChanOP to channel owners. AustNet services only request NickOP information once when a user is registering their nickname. From time to time AustNet services may automatically check when a user logs in and identifies to ensure that their identification information is correct. This information, email addresses and passwords are kept on a secure server. AustNet staff are expected to keep information including ASD notices; helpme’s; G:lines; klines; & IP addresses they see in server notices and NickOP info private and not to be shared with NON AustNet staff. We advise users that we keep records of email addresses and IP addresses for identification purposes only and not for any other reasons. AustNet staff who are permitted to change email addresses may do so once they are satisfied that the user is the owner of the nickname and correct/amend or change the email address as/when appropriate. No staff member shall use information, which can be obtained through their helper status for their personal gain or to assist non AustNet staff for their personal gain. Information obtained from AustNet users will only be used for purposes of identification to the network, other requests for personal information from Non AustNet staff must be provided in writing to [email protected] Privacy laws in all countries are there to protect the personal and commercial information of anyone who uses any service, be it an IRC service, voluntary or business organisation. This also applies to IRC users, ISP or commercially sponsored servers and server information. Governing Policies This document outlines the rules and regulations that govern the AustNet IRC network. It represents the wills and support of a mass majority of the AustNet community (users, opers and admins alike). It discusses the policy and guidelines which are enforced on the network, educating and promoting proper network usage. IRC Operators Use of /KILL should be limited to providing a quick disruption of a broken or errored client or one that is flooding or breaking server rules or abusing other servers/clients. This includes or could include a K:Line (local) or G:Line (network wide). Client disconnection from the network is substantiated when: ● violation of organisation charter agreement occurs Use of /SQUIT should be used only to reroute a server or in some cases jupe a server in co-operation or support of other online IRC-operators or admins. Before using /SQUIT, an operator is required to WALLOP the reroute with the online operators /msg $.austnet.org to inform the general community. Online operators are expected to have general knowledge about IRC; if a user asks a question (basic help), operators are expected to politely attempt to help. If you find you are otherwise occupied, feel free to forward clients to #Help. In the case of reroute or deliberate service interference, operators should /msg $*.austnet.org (or relevant server masks) in order to notify clients of the upcomming events. General abuse or hassles with operators or servers should be presented to the IRC operators on [email protected] An operator can have only one primary O-line at a time. This is considered to be their main server, and the one they use the most. This is also the person who is responsible for their duties. An operator, however, can have as many secondaries as desired. These are not listed in server MOTD’s and the operator must help the admin/oper contact maintain an accurate list of primaries and secondaries. Operators are considered network staff. As such, they may change primary O lines with the consent and prior notification to [email protected] by the admin adding the operator to their staff, and no objection by another administrator within 48 hours. If there is an objection by another server administrator, a vote must be called. Operators coming in with a server that then delinks will lose their O line unless approval and a move occurs within 7 days of the server delinking. In the event of a vote, no operator who has a current vote pending (including the operator who is the subject of the vote), may vote to ensure fairness. Server Administrators The owners/administrators of IRC servers are required to keep their server on-line to the requirements of server applications. They are required to maintain and housekeep their server, upgrading the daemon when required and ensuring that the server is running at optimum performance. Report outages, connectivity upgrades or the like to [email protected] Server administrators are required to give network administration prior knowledge of O-line generation on servers at least 48 hours before hand. This is for administrative purposes, and so mail aliases, server information and the appropriate resources can be modified. This too, serves as a method of monitoring the operator count network wide and the ability for discussion over the O-line. It is the responsibility of admins to see that their operators get the training required to perform well. Any more than four O-lines (primary) on a server is highly discouraged unless there is a serious problem on the server that requires further monitoring. Server administrators are required to organise connection lines with [email protected] The server administrator is able to upgrade the server’s machine or link, providing the machine remains in the same location, net-wise, or making other changes as necessary in keeping his or her server in the best possible working condition, where “best possible working condition” is defined at the discretion of the administrator. Setting up an additional server to expand the capability of the site, even if this includes running additional processes on different machines, providing that the machines are of comparably capability, and the server’s location does not change. Do whatever is necessary regarding his or her own server, to be decided at the administrator’s discretion, to make a smooth transition during hardware or software upgrades, or during an emergency situation. An administrator is responsible for the actions of their operators. If an operator causes problems which the administrator cannot or will not deal with, the administrator/operator contact will ask the administrator to suspend the operator until the matter can be resolved. Each administrator may add one local operator for training to global provided that: ● [email protected] is notified at least 48 hours prior to the generation of the local o line, AND If an objection is lodged, a network vote may occur to allow the addition. The trainee must remain local at least 4 weeks, though 6-8 weeks is recommended for most cases. After that time, the administrator may request an o: -> O: vote. If successful, the operator will be added to staff, is considered network staff, and may be added to Sprint/OperOP/VoteOP. If unsuccessful, they may remain local, or be removed, at the administrator’s discretion, but no vote may be recalled for at least another 4 weeks. Services Operators Network Operators (100 service access) should attempt to mediate problems such as channel takeovers and channel floods, using the SETMODE and WIPECHAN commands. Issuing operator status to certain users should be done only when a channel has lost ops for a reason and channel users are unhappy about it and they have decided upon who is to be opped. A WIPECHAN should be used when a channel has been locked and set to +pstmil 1 or such similar mechanism (such as +b *!*@*) and channel regulars complain about it. In this case, the channel has to be cleared and nothing else. Ops will be decided as usual by the person who joins the channel first. Service Operators (200 service access) are required to assist users in the legitimate recovery of passwords to their nickname. Service Operators, in the case of channel or service abuse, are required to use the SUSPEND command to stop the management of a certain channel temporarily. Channel suspension or removal as a disciplanary action should be posted to [email protected] as well to inform the network of channel management modifications. Service Operators reserve the right to remove channel registrations when services have been abused. This is most likely the case when an operator on a channel registers the channel, and they are not supported by the current fellow operators. This is considered a channel takeover and should be investigated in depth. All IRC Operators are not subject to addition of service access. Routing Department Policy Testlinked Servers: The administrator of a Testlinked server is allowed to be global O:,
in order to facilitate evaluation and encourage more familiarity for
both the network and the new administrator. The administrator has the
following limitations imposed:they will not have Sprint/OperOP/VoteOP
access during the testlink; Testlink to Permlinked Servers: Upon approved testlink to permlink, the administrator and all operators listed on the application will become global O:, may be added to Sprint/OperOP/VoteOP, and are subject to O: line provisions within the Charter. Voting Policy Vote Roll All AustNet Administrators and global IRC Operators are given the option to vote for issues as they arise. Voting is a privilege, and is subject to your vote participation. Vote Participation Anyone on the vote roll who does not vote for 3 votes in a row, may be subject to removal from that vote roll. (exceptions are those who are known to be away for a period of time). We need each and every vote, as most are often close, therefore having inactive voting members wastes time in having to call revotes. If you do not vote, you will be asked as to why and decisions left up for discussion by all staff members. Vote Procedure Any Server Administrator must call a vote, which can then be checked
over and approved/denied by another Server Administrator. Once approved,
everyone is notified and they have a certain time frame in which to
vote. Vote Results Any abstains made in a vote shall not be taken into account when
deciding what the majority was. A votes outcome is determined only by
the YES and NO votes. A clear 50% or higher majority is required either
way. Vote Scenarios Testlink Vote: On event of a YES, server shall be given permanent AustNet server status for a given period of time. o: to O: Vote: On event of a YES, administrator has support of network to modify the
person’s o: into an O:. However, this is still the administrators
choice, and may choose not to do that immediately. The administrator may
remove o:/O: lines anytime they wish without need for votes. Departmental Policy The following departments exist within the network: Help: The help department ensures that clients receive answers to their questions promptly, online and offline. Mailing lists such as [email protected] are established to assist users. Web site: The web site department is responsible for the architecture and implementation of departmental and network web sites. Services: The service department aims to discuss possible modifications and
provide as a source of information in relation to channel and nickname
ownership details. It is also used as a forum to which mediates
ownership discussion. Public Relations: The role of the Public Relations department is to provide documents
to users about AustNet, ensure that the network is well advertised (for
example, in search engines, client server lists etc Routing: The role of the Routing Department is a fundamental aspect of the
network’s connectivity. Its aim is to provide users with the best
possible connection, along side a fast, efficient and stable network
topology. The routing department is also in charge of network linkages. |