[IDONS] RegistrationPolicy :: pdf :: context view

inbound links:
Domain Registry

Domain Registry

The registration and resolution policy can/should be understood as two contracts:

  1. Among the set of "root" servers for each Domain Registry (community).
  2. Between every subscriber of a recursive name server and the subscribed root server community.

Purpose (#1) (see Domain Registry in Glossary):

The Domain Registration Policy governs the process to perform updates to the mapping from Names to Identifiers as maintained by a Domain Registry (community).

The Contract Part

Requirements Analysis

Alternatives so far (ordered by complexity):

  1. FIFO
    • domain names are first come, first serve, excluding those reserved for .idons operational matters for domain spam prevention, to qualify for a domain you must own at least one domain of the same name in the existing TLD scope (eg: test.idons requires you to own test.com/.net/.org/etc)
    • Two TLD's
      1. .key for the backend of the .idons (.k2k for symmetry)
      2. .idons for the human readable text
    • To prevent domain fraud on commonly used domains (eg: google.*) alexa top1000 will be locked to the owner of the highest ranking domain that appears on the alexa rankings ...
    • Reselling of domains/subdomains, as a domain is controlled by a member, we have no direct say in how it's operations are handled. All domains handled through nic.idons will be freely available to all members.
    • OpenNIC .idons Charter
  2. Register using ''Name+Date+Geographic Location''.
    • This model would work like certification of births.
    • Relies on prior existent, so far "proofed working" registration of individuals and/or legal entities.
    • Similar approach in: Distinguishing namespace: claim other unique identifiers.
  3. Consensus models (see also Subscription Reputation Support):
    • Some form of reputation system for nodes, managed and assigned as part of the protocol
    • Consensus on the address of a site should be needed before handing it out to a client
    • Nodes sending out fake IP addresses should not have their results propagated
    • Nodes that continue to send out addresses that do not meet consensus should have their reputation decreased
    • Policies in place to deal with spammers and others, albeit not ones we agree with. To add entries, one could employ quarantine of some sort.

Initial Proposal

A TLD could be chartered for use for the sake of compatibility with the existing DNS system.

Practical Issues

Automation of Registration and Dispute

  1. P2P?
  2. Contract language: coded as a executable program, not only as a procedure for humans to follow. (See Subscription Reputation Support effects MechanismSoftwarePeer)

seized/scammer domains

many P2P? programs do not own the .com domains they deserve. Some are hosting scam sites, some advertise "legal" or subscription based versions. If you are going to use the .idons TLD then you need to protect the domains for P2P? applications such as shareaza, ares, emule, Lphant, bearshare, limewire... as well as domains like "youtorrent", "bitorrent.com", "shareza", etc

Ideas

Distributed decision example

Distributed decision example at p2p-dns.

Working code example: an overly simplified voting type of a dispute process in an executable contract language.


Last modification: Tue, 21 Dec 2010 20:58:18 +0100

Author(s): jfw,

Document number A5afeb39445695358a1d5cf9425159a3a (version 434) delivered to public at Sat, 18 Nov 2017 22:21:01 +0100

short comments

add comment