Log in | Back to darenet.org

Policy:Proposals/2

(Policy decisions)
(Server delink procedure)
Line 28: Line 28:
== Server delink procedure ==
== Server delink procedure ==
-
''(finish me!)''
+
There are two primary types of delink:  Voluntary and Involuntary.
 +
 
 +
=== Voluntary ===
 +
 
 +
Servers which voluntarily delink are requested to give the Infrastructure team as much advance notice of the decision as possible to facilitate a smooth transition. Those servers leaving on their own accord, provided they are in good standing, have the option to return at a later date in full link status provided the team is satisfied that any network changes that may have been made (e.g., different uplinks) will not render the server unusable on DareNET, and that the new server is operated by the same administrator. The Infrastructure team MUST be made aware of any such network changes, including traceroutes/pings from the server's new location, BEFORE any attempt to relink the server.
 +
 
 +
== Involuntary ==
 +
 
 +
A server may be involuntarily delinked due to an unexcused absence, or should the Infrastructure and Operations teams decide it's no longer in the best interest of DareNET for the server to remain linked to the network.
 +
 
 +
Servers that remain in absence from the network for a period of two weeks (fourteen days) will automatically be considered delinked. No CFV for the delinked server will be held in this case, though notification of the delink will be forwarded to the Operations team.
 +
 
 +
At the discretion of the Infrastructure team, a server may be granted an extended absence provided that the server's admin can give just cause for the absence, and can guarantee its return within a reasonable timeframe. To be granted such an extension, the server admin must make the request PRIOR to the end of the initial two week absentee period.
 +
 
 +
Servers which are involuntarily delinked may reapply for a link after a six month period following the full application procedure, including the initial testlink period.
 +
 
 +
For reasons of security or other situations where it's felt the server may have a negative impact on the rest of the network, the team may review that server's link at any time. Such possible circumstances include, but are not solely limited to, server compromised, other services running on the server which were not previously agreed on, uplink connectivity failing to evolve with growth, a complete change of network locations or connectivity.
== Appellate Procedure ==
== Appellate Procedure ==
''(finish me!)''
''(finish me!)''

Revision as of 10:07, 13 January 2014

Proposal #2 - Infrastructure Team: Policy and Operating Procedure

In This Guide:

Overview

The Infrastructure ream is subordinate to the DareNET Operations team for the purpose of maintaining a stable, secure, geographically diverse and well structured infrastructure for the organization as a whole. As such, the team is charged with handling and reviewing link applications, maintaining and monitoring all servers linked to the network, and administering the DNS pool. Communication between members of the team is effected by means of a private mailing list. Communications between the team and other relevant entities are effected by the Infrastructure Team Manager.

Membership

  • Manager: Appointed by the Operations team for a one year term, with no restrictions on the number of consecutive terms that may be served. The team manager is charged with ensuring the team is adequately staffed, supervising the overall performance of other team members, maintaining the P10 Server Numerics listing, notification to applicants, and liaising with all relevant parties through established communication channels. Where possible, they may delegate some of these responsibilities to other team members.
  • Members: Appointed by the team manager for an indefinite term. Members are charged with reviewing applications, reviewing existing servers for performance, updating server configurations, maintaining the DNS pool, voting in team Call for Votes (CFVs), etc.

Policy decisions

(finish me!)

Voting procedure

(finish me!)

New links procedure

(finish me!)

Testlink review procedure

(finish me!)

Server delink procedure

There are two primary types of delink: Voluntary and Involuntary.

Voluntary

Servers which voluntarily delink are requested to give the Infrastructure team as much advance notice of the decision as possible to facilitate a smooth transition. Those servers leaving on their own accord, provided they are in good standing, have the option to return at a later date in full link status provided the team is satisfied that any network changes that may have been made (e.g., different uplinks) will not render the server unusable on DareNET, and that the new server is operated by the same administrator. The Infrastructure team MUST be made aware of any such network changes, including traceroutes/pings from the server's new location, BEFORE any attempt to relink the server.

Involuntary

A server may be involuntarily delinked due to an unexcused absence, or should the Infrastructure and Operations teams decide it's no longer in the best interest of DareNET for the server to remain linked to the network.

Servers that remain in absence from the network for a period of two weeks (fourteen days) will automatically be considered delinked. No CFV for the delinked server will be held in this case, though notification of the delink will be forwarded to the Operations team.

At the discretion of the Infrastructure team, a server may be granted an extended absence provided that the server's admin can give just cause for the absence, and can guarantee its return within a reasonable timeframe. To be granted such an extension, the server admin must make the request PRIOR to the end of the initial two week absentee period.

Servers which are involuntarily delinked may reapply for a link after a six month period following the full application procedure, including the initial testlink period.

For reasons of security or other situations where it's felt the server may have a negative impact on the rest of the network, the team may review that server's link at any time. Such possible circumstances include, but are not solely limited to, server compromised, other services running on the server which were not previously agreed on, uplink connectivity failing to evolve with growth, a complete change of network locations or connectivity.

Appellate Procedure

(finish me!)