Policy:Proposals/2

Proposal #2 - Infrastructure Team: Policy and Operating Procedure

Overview
The Infrastructure team 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 handled 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
Policy decisions include, but are not limited to, making changes to this document, making changes to the linking guidelines, linking/delinking servers or voting to bring action against a server. Voting procedure:


 * A vote is called by the team manager or designee.
 * A discussion is conducted on the mailing list and opinions are posted by the members.
 * Within 4 days, each member will submit their vote to the mailing list. The vote will pass with a simple majority. In the event of a tie, the Manager may cast the tiebreaking vote.

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.

A server may be temporarily delinked (juped) if it shows considerable disruption to the rest of the network. This action should be no longer than five days; otherwise, it qualifies for delink.

Appellate Procedure
Should an individual or server admin wish to appeal the decision of the Infrastructure team, they shall immediately notify the Infrastructure Manager of their decision to appeal. The appellate must inform the Manager of their appeal within 48 hours of the decision they're appealing. Failure to do so will result in the assumption that there is no intent to appeal, and the course of action will effected.

The appellate procedure only exists for decisions concerning servers already linked to DareNET, whether in a testlink or permlink status. Decisions regarding applications for new servers may not be appealed at this time. Upon receiving a valid appeal, the Manager shall note the appeal and notify the Operations team. The Operations team will then hold a Call for Discussion (CFD) and a Call for Votes (CFV) on the matter. The decision reached by the Operations team shall be final. The Manager shall notify the appellate of the Operations team's decision.

Should an appeal overturn the decision of the Infrastructure team, the Manager shall liaise with all relevant parties to return the appellate to the status held prior to the decision that caused the appeal. In the case of a testlink server, the server shall be returned to testlink status for a minimum period of 30 days. In the case of a permlink server, the server shall be returned to permlink status.

Note: This procedure only applies to decisions of the Infrastructure team. Appeals to decisions made by the Operations team should be directed to the Executive Board.