Skip to Content.
Sympa Menu

discuss - Re: [opennic-discuss] [DISCUSSION] Mailing List Voting and Formatting Policies

discuss AT

Subject: Discuss mailing list

List archive

Re: [opennic-discuss] [DISCUSSION] Mailing List Voting and Formatting Policies

Chronological Thread 
  • From: Amunak <amunak AT>
  • To: discuss AT
  • Subject: Re: [opennic-discuss] [DISCUSSION] Mailing List Voting and Formatting Policies
  • Date: Mon, 23 Oct 2017 16:27:35 +0200

I see, that's what I expected, but the thing is that I live in a country that does exactly this - we are a "progressive, western society" and yet the government has banned some gambling websites because of our gambling laws (it's always either children, [child] porn, piracy, gambling or something else that opens the gates for further censorship), implemented on the ISP DNS level (that is no one but ISPs need to block anything). But I guess I still should not provide a T2 server because of this clause? I mean, if it's just a recommendation then it doesn't matter that much, but it could unnecessarily dissuade people from running resolvers. And what's the issue of operating servers in China? I don't think anything bad could come from this - at worst they'll ban those servers or they'll go after their owners, who'll (hopefully) live in another country. And even then it's most likely that no one will notice.

Also, do you have any comments or thoughts on adding a clear rule about updating the voting subject mid-voting/commenting period?

Thank you,

On 23.10.2017, at 14:00 Jonah Aragon wrote:
The main issue I’m tying to avoid with that is countries that censor their web content via DNS, like China. We shouldn’t be operating any servers from within China for example because it would probably affect the resolutions of some domain names. And even if there’s no technical limitation like that, it doesn’t make sense to actively try and operate services that circumvent censorship from within the country itself. People located in these countries are of course always welcome to use our servers, but it doesn’t make much sense for us to have servers within said countries. There’s always exceptions of course, which is why that’s just a recommendation. 

OpenNIC Members are whoever is a part of this list, yes. It’s probably an easy system to abuse but there’s not much we can do about it. Hopefully we’ll all agree to move to Fisk’s wiki voting system that was proposed in another thread. 


On Oct 23, 2017, at 4:03 AM, Amunak <amunak AT> wrote:

I really like your proposals. Finally our policies would be properly defined while not restricting server operators beyond current expectations.

However I would advise to remove this:
> SHOULD NOT operate from a country that censors web content.

Many countries censor web content in one way or another. China, Russia, the US, but also the UK, Canada, basically all of EU thanks to our privacy laws, gambling laws in countries like Czech Republic, ... Essentially this clause is unenforceable. Or it needs to be amended to clearly state what "censorship" is. But I'd personally think it'd be best to remove this limitation - OpenNIC actually has a chance to fight for free speech this way - by providing uncensored DNS in countries that otherwise do censor the internet through DNS. Alternatively we could distinguish servers that do abide by their countries' censorship by a flag in the server list like we do for servers with blacklisting.

There's also one thing I think is missing from your proposal: a clause that'd clearly state that changing the charter when the vote is underway is unacceptable. Either you wait before the vote ends or you can cancel the vote (there should perhaps be something explicitly allowing or disallowing this too) and then there should be another discussion period on the changed terms and then another vote. Same goes for the discussion period - in my opinion it should extend by at least the minimum amount when the proposal that is being discussed changes. Currently it's way too easy to propose something, change it a day before the discussion period ends and then vote on that changed proposal with some people not noticing or having the time to discuss the updated proposal.

I also realized that we don't really define who is an OpenNIC member; do we really define this by "anyone who subscribes to the mailing list"? And how do we prevent potential abuse that will eventually happen, because it's really easy to just use multiple addresses?

Other than that I really like where this is going, good job.


On 21.10.2017 21:20, Jonah Aragon wrote:
This is going to be a fairly long email, because it’s really 4 different proposals, all regarding how votes are handled on the mailing list, how they are passed, and the formal set of requirements every TLD proposal must meet prior to starting a discussion.

This is split up into 4 sections, and when/if this goes to a vote each of the sections will be voted on individually. Very open to suggestions on this, as I’m not sure what the community is looking for in regards to some of these changes. I mainly wanted to ensure there was a very standardized way this is all run, and maybe some more technical requirements for would-be TLD proposals.

This document loosely follows RFC 2119 in defining the following keywords used throughout:

- “MUST”, “SHALL”, “REQUIRED”: Indicates the definition is an absolute requirement, with no exceptions.
- “MUST NOT”, “SHALL NOT”: Indicates the definition is an absolute prohibition, with no exceptions.
- “SHOULD”, “RECOMMENDED”: Indicates there may be valid reasons to ignore a particular item, but you should understand and carefully weigh the full implications of ignoring the item before proceeding.
- “SHOULD NOT”, “NOT RECOMMENDED”: Indicates there may be valid reasons in which a particular behavior is acceptable or useful, but the full implications should be understood and carefully weighed before proceeding with any behavior described with these labels.
- “OPTIONAL”: Indicates a behavior is truly optional, and may or may not be implemented.

SECTION I: Minimum requirements to pass.

OpenNIC organizational policy revisions, additions, or deletions that do NOT directly affect the operation of individual TLD registries SHALL require a simple majority of votes to pass.

Organizational policy revisions, additions, or deletions that directly affect the operation of individual TLD registries (for example: overarching abuse/trademark policies) SHALL require a simple majority of votes to pass, AND at least 5 members will have to participate in the vote.

Revisions to TLD charters SHALL require a 2/3rds majority vote to pass, AND at least 5 members will have to participate in the vote. Additionally, any existing specific clauses in the charter regarding how modifications of the charter will be handled SHALL take priority over this document.

The addition or removal of a TLD SHALL require a 2/3rds majority vote to pass, AND at least 10 members—including one Tier 1 server operator—MUST participate in the vote.

An exception: to prevent abuse of the voting system, amendments to this policy SHALL require a 2/3rds majority vote to pass, with at least 5 members participating in the vote.

SECTION II: Proposing a TLD

BEFORE you begin a proposal, you MUST meet the following requirements:

- You MUST have an operational Tier 1 DNS server. This server must mirror the root data of the root “.” zone and all the zone data for each OpenNIC TLD. This server MUST pass the Tier 1 server test:
- You MUST have a website accessible at www.opennic.[TLD] with the following information:
- A copy of your charter (detailed below in this document)
- Information on how to register a new domain
- Administrative contacts
- You MUST accept and process emails to the following addresses, and they must be listed on your website detailed above.
- hostmaster@opennic.[TLD] — SHOULD be delivered to the DNS administration team for your TLD.
- abuse@opennic.[TLD] — SHOULD be delivered to your abuse handling team (dealing with spam, malware, or other charter violators)
- webmaster@opennic.[TLD] — SHOULD be delivered to the web presence team for your TLD.
- You MUST publish and enforce a charter, which satisfies the following requirements:
- Your charter MUST clearly explain the purpose of your TLD (possibly including a brief description and/or examples of domains and content to be hosted)
- It MUST include a description of content that will not be allowed on your domain (for example: trademarked names, malware hosts)
- It SHOULD NOT conflict with existing OpenNIC policies.
- It SHOULD include descriptions on how amendments to your charter will be handled. If no amendment clauses are included, changes will be handled in accordance to the current OpenNIC voting policies.

Additionally, you MUST meet the following requirements before proposing your TLD to the community:

- You MUST have operated a Tier 2 DNS server continuously for at least 3 months, and said DNS server MUST be in operation while your TLD is being considered.
- You should keep this DNS server in operation following the approval of your TLD.
- You MUST have a process for users to register domains. Domain registrations SHOULD be provided free of charge, and an automated domain registration system is RECOMMENDED.
- You SHOULD have an administration team gathered. Your team can consist of as many people as needed, or a single person, but it MUST be able to handle DNS Administration, Webmaster Related, and Abuse Report requests effectively.

OPTIONALLY: You may wish to informally request feedback from the community and experienced members before pushing your TLD proposal to a formal discussion. While not required, it can help you prepare for your TLD proposal by satisfying some requests the community has before official judging.

- Consider starting a discussion on the #opennic IRC channel on Freenode to get faster feedback from some experienced members of the community. Make sure you stick around on the channel throughout the discussion to answer any questions some may have.
- You can also start a new thread on the Mailing List with a brief description of your TLD, ensuring it is clear this is just an informal discussion on the matter. Make sure you are available to answer questions and take advice from the community, which you may be able to implement either technically or in your charter before a formal discussion.

After you have satisfied ALL of the above requirements, you may proceed to submit your TLD for formal discussion and a vote.

Start a discussion by sending an email to the Mailing List, with the subject line: “[DISCUSSION] ‘.{TLD}’ Proposal” (replacing {TLD} with your namespace). This email MUST include the following:

- A copy of the charter, which may be pasted in-line, linked to, or attached as a PDF. If you choose to link to your charter, it MUST be accessible from a location other than your www.opennic.tld homepage, as no community members will be able to access that site prior to your TLD being approved.
- The IP address(es) of your Tier 1 server(s) that will be added following the approval of your TLD.
- Your OpenNIC Member username.

NOTE: DO NOT send this email as a reply to another thread. You MUST start a discussion thread by sending a new message to discuss AT

After a minimum of 7 days following your discussion thread, you may begin a vote. A vote may be started by sending a new email (NOT a reply) to the Mailing List with the subject: “[VOTE] ‘.{TLD}’”

The email MUST include the following:

- A deadline for votes, at least 7 days following the post date of your thread. This should be a clear date and time (in UTC).
- A linked or attached final copy of the charter.

Section III: Voting Thread Formatting

For the sake of clarity, formal Mailing List threads MUST begin with the following prefixes, depending on the content of the message:

- “[DISCUSSION]”, or “[PROPOSAL]” — For formal discussions or proposals of official policies or changes that will eventually lead to a vote.
- “[VOTE]” — Indicates an official voting thread.

Voting threads MUST include the following information:

- A deadline, at least 7 days following the post date of the voting thread. It must include a clear date and time (in UTC). Acceptable formats include, for example: “January 21st, 2018 at 8:00 PM UTC” or “2018-01-21, 20:00”.
- A link to the original discussion thread, in the form of an archive link, for example: These links are accessible at
- A brief description of what the vote is on, and exactly what will happen depending on the outcome.

They SHOULD also include the following:

- The subject line following [VOTE] should be the same as the subject line on your discussion thread.
- The community’s options for voting, if not a simple YES/NO.
- A timeline of when your vote will go into place, if not an immediate change. You may also wish to include reasoning why your proposal won’t enter into effect immediately, if applicable.

Following the vote, the original author of the thread MUST summarize the results in a reply, signifying the vote has closed. The closing email SHOULD be sent as close as possible to the posted deadline, but never before. The closing email MUST include the following:

- A count of the votes, either briefly summarized or in a YES-NO format (for example: “The vote has ended with 9 YES votes and 12 NO votes”, or simply “9-12”).
- A description of when the community should expect the proposal to be completely implemented.

Section IV: Voting Thread Procedures

A voting thread MUST NOT be sent without a corresponding discussion thread. It MUST NOT be sent until at least 7 days have passed following the post of the original discussion thread, AND at least 1 day has passed following the last reply to the original discussion thread, whichever comes last.

Thanks for reading all of that, looking forward to some insight and suggestions to move this forward.


You are a member of the OpenNIC Discuss list. 
You may unsubscribe by emailing discuss-unsubscribe AT

You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing discuss-unsubscribe AT

You are a member of the OpenNIC Discuss list. 
You may unsubscribe by emailing discuss-unsubscribe AT

Archive powered by MHonArc 2.6.19.

Top of Page