Discuss mailing list

["Daniel Quintiliani" <danq AT runbox.com>]

While I can't say anything about the specifics of this, as I don't run any 
TLDs, you might want to take into account the current volatile nature of 
Github, by specifically stating that members can vote to move things to other 
sites in the event of a problem. We shouldn't try and predict the finances 
and (mis)management of Github, but instead change these proposals to 
specifically state that members can vote to move hosting to other places.

--

-Dan Q


On Fri, 13 Jul 2018 20:03:14 -0500, Jonah Aragon <jonah AT triplebit.net> wrote:

> Recently, I’ve been somewhat concerned about the reliability of some of our 
> community members (regardless of their current intentions, see “bus 
> factor”), and I want to make sure our top-level domains are protected, “DNS 
> resolution”-wise in any case. I also noticed we don’t really have any 
> policies regarding the ownership, transfer, and deletion rights of our 
> TLDs, so I wanted to specify things a bit. 
> 
> I’m proposing the following additions to our current policies:
> 
> ## Operator Activity
> -  Operators are defined as “Active” if at least one of the following 
> conditions are met: (a) they are operating a working registration system, 
> or (b) they have made a meaningful contribution to the community within the 
> last 6 months (for example, contributing on the mailing list, IRC, wiki, or 
> GitHub). Additionally, their Tier 1 server must reliably resolve their TLD 
> zone. 
> 
> ## Deletion of top-level domains
> - TLD zones may never be removed, with the exception of an ICANN collision, 
> which should be voted on (following “.free” precedent). 
> 
> ## TLD ownership
> - Top-Level domains should be considered the property of the administrative 
> team responsible for its operation, provided they are aligned with all 
> applicable OpenNIC policies. 
> 
> ## Voluntary transfer of TLD ownership
> - Active operators unfit for continued TLD operation must post a notice to 
> that effect on the mailing list. A private transfer of TLD ownership is 
> prohibited. 
> - Any Tier 2 or Tier 1 server operator may apply (via the mailing list 
> notice) for ownership, within a 14 day period following the initial notice. 
> - A list of applicants will be compiled, and the community will vote on a 
> new operator based on that list. The vote will last for 14 days. 
> - Following a community vote, the applicant selected by the community will 
> immediately assume operation and ownership of the top-level domain. 
> - The applicant selected by the community is expected to maintain domain 
> records that existed prior to TLD transfer. 
> - TLD operators are expected to continue resolving their TLD throughout 
> this process, until the ownership is transferred. In a case of urgency, any 
> Tier 1 operator may assume interim operation throughout this process until 
> a new operator is chosen. The TLD operator should reach out to another Tier 
> 1 operator to take over the zone before posting the notice, to ensure 
> continued resolution. 
> 
> ## Involuntary transfer of TLD ownership
> - TLDs may not be involuntarily transferred from Active operators. 
> - Any Tier 2 or 1 operator may apply for ownership of a TLD owned by an 
> inactive operator. They must send a discussion thread to the mailing list 
> declaring this statement. Any Tier 2 or 1 operator may reply to this notice 
> with a challenge, if they wish to assume ownership of the zone. This 
> discussion thread will last for a minimum of 21 days. 
> - Unchallenged claims will be voted on by the community following 
> discussion in a simple “Yes, transfer ownership” or “No, retain the current 
> operator” vote. 
> - Challenged claims will be voted on by the community following discussion, 
> accounting for every claimant as an option. Additionally, the community may 
> vote for no change to the ownership. 
> - Following a community vote, if a new owner is chosen, ownership of the 
> zone will immediately pass to them. They must be ready to provide 
> resolution at this time. 
> - New operators are expected to resolve zones/subdomains of the TLD that 
> existed prior to them gaining ownership, from the last available good 
> backup of the zone. 
> 
> ## Inactive zone alternatives
> - Zones operated by an inactive member of the community should be 
> considered for an involuntary zone transfer first and foremost. 
> - If no community member is willing to adopt an inactive zone, the zone may 
> be archived in a read-only state, as they are prohibited from being 
> deleted. 
> - Archived zones shall exist as a read-only master copy on every Tier 1 
> server. Tier 1 servers are prohibited from adding records to an archived 
> zone, but existing records may be modified or removed manually at the 
> request of a record owner posted to the mailing list. 
> - A zone may be nominated to be archived in the event of operator 
> inactivity, on the mailing list. Any member may nominate an eligible zone 
> to be archived. This notice includes a 30 day minimum discussion period. 
> - Any Tier 1 or 2 operator may challenge an archive nomination within the 
> discussion timeframe if they wish to take ownership of a zone. In this 
> case, the “involuntary zone ownership transfer” policies outlined above 
> take precedent, and the archive proposal ends. 
> - Following the discussion period, the zone shall be archived immediately, 
> assuming no Tier 1 or 2 operator wishes to assume ownership of the zone. 
> 
> ## Guaranteed Resolution
> - If a Tier 1 server has been unresponsive for at least 7 days, and the 
> operator can not be contacted, any Tier 1 operator may assume interim 
> operation of the TLD zone on their own server, and the root should be 
> changed immediately. The assuming operator must post a notice to that 
> affect to the mailing list. The assuming operator must operate their zone 
> based on the last known good backup of the TLD zonefile. The assuming 
> operator may not add new records to the zone. Zones that are being operated 
> by an interim zone operator should be considered for an “involuntary TLD 
> transfer” (see above), if applicable. 
> - TLD zonefiles should be considered public information, and they will be 
> posted to the @OpenNIC GitHub organization, which will serve as a backup 
> repository. 
> 
> ## Notes
> - These notes in this section are informative and non-binding. 
> - ModernTLD, operators of the .o zone, operated by myself, has volunteered 
> to act as an interim operator for any zones that may require that service, 
> as per the “urgent” voluntary zone transfer procedure listed above. 
> - ModernTLD will be providing a backup of all OpenNIC zones hosted on the 
> @ModernTLD GitHub organization, in case anything affects the long-term 
> reliability of the OpenNIC official GitHub repositories. 
> - “Owners” and “operators” should be considered synonymous throughout this 
> policy, as zones are the property of their operators. 
> 
> I think most of these changes should be “common sense” policies, but I feel 
> like they should be codified just so everything is clear. 
> 
> Jonah
> 
> 
> --------
> You are a member of the OpenNIC Discuss list. 
> You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org