Discuss mailing list

[<vv AT cgs.pw>]

I don't understand why a vote that's passes would
be resubmitted, now how not allowing them to do
that would improve their infrastructure.

~ Ole


On Sat, 14 Jul 2018 14:50:03 -0400
Rouben <rouben AT rouben.net> wrote:

> I like the idea of this in principle... a number of TLDs
> I’ve browsed don’t have adequate basic infrastructure.
> 
> On Fri, Jul 13, 2018 at 21:03 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
> >