[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Here is my Draft Proposal
- Date: Sun, 1 Dec 1996 14:42:15 -0500 (EST)
- From: jp@Mohatu.AGN.NET (John Palmer)
- Subject: Here is my Draft Proposal
I published this before, last April, but I don't see it on the IAHC
Web Page, so I will post it here again. Could someone from the IAHC
please put this on their web page?
RANDOM DRAFT 53-D.1 J. Palmer
AGN
December 1996
Delegation of International Top Level Domains (iTLDs)
Modified from DRAFT 53-C (by Jon Postel)
Status of this Memo
1
2
3
4
5
6
7 IETF DRAFT boiler plate goes here when this is an IETF DRAFT
8 as long as it recognizes that the internet is an international
9 organ of commerce and that free enterprise should drive its
10 operation
11
12
13
Abstract
This document describes a proposed policy, procedure, and control
structure for the allocation of additional top-level domains.
Further it discusses the issues surrounding additional international
top level domains (iTLDs) and registries, qualification proposals for
operating such a registry, and justifications for the positions
expressed in this paper.
This document describes policies and procedures to
o allow the time-tested policy of "first-come, first-serve"
in domain name registration in the iTLDs, just as it has
worked for so many years in the common second-level domains
under .COM, .ORG, etc.
o provide for financial support for the root name servers
while not allowing any organization (such as the IANA) from
succeeding in unlawful enrichment schemes
Note that while cooperation between competing iTLD registries is
allowed, it is not required. This is specifically not assumed in
this proposal, and is considered to be an operational aspect of a
registry best determined, and coordinated, by contractual agreements
between private interests.
Palmer Expires Jun-97 [Page 1]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
The NEWDOM, IETF, and related mailing lists are encouraged to read,
and comment, on this material. Presuming a consensus can be found
within these audiences, the distribution of this memorandum should be
expanded to include general commentary from the Internet community.
1. Introduction
For the purpose of delegation, the top level domains (TLDs) fall into
the categories listed below. While all are described to provide
context, only the last is the subject of this document.
1.1. National TLDs
The two-character namespace is, and will remain, reserved for ISO
country codes under existing accepted Internet RFCs.
National TLDs such as AF, FR, US, ... ZW are named in accordance
with ISO 3166, and have, in the major part, been delegated to
national naming registries. Any further delegation of these TLDs
is undertaken by the Internet Assigned Number Authority (IANA), in
accordance with the policies described in RFC 1591.
It is good practice for these delegated TLD registries to publicly
document the applicable management policies and further delegation
procedures for these national domains, as, for example, RFC 1480
does for the US domain.
The ISO 3166 3-letter country codes ARE NOT to be reserved as domain
names as this would eliminate many viable iTLD's from commercial use
for no reason.
1.2. US Governmental TLDs
1.2.1. Delegation of the GOV TLD is described by RFC 1816, and is
under the authority of the US Federal Networking Council (FNC).
1.2.2. Delegation of the MIL domain is under the authority of the
DDN NIC. See DDS Management Bulletin 9513, dated Nov 7, 1995,
"Policy Governing Domain Registration in the '.MIL' and
'.SMIL.MIL' Domains"
The document can be obtained by either: ftp nic.ddn.mil, cd
ddn-news, get bul-9513.txt or http://nic.ddn.mil/ddn-man.html.
1.3. Infrastructure TLDs
TLDs such as IN-ADDR.ARPA and INT are under the authority of the
IANA and may be delegated to others, e.g., IN-ADDR.ARPA is
currently delegated to the InterNIC for day-to-day management.
They are created for technical needs internal to the operation of
the internet at the discretion of the IANA in consultation with
the IETF.
Palmer Expires Jun-97 [Page 2]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
1.4 The EDU TLD
Delegation of the EDU domain is under the authority of the FNC and
is currently delegated to the NSF which has contracted to the
InterNIC for registration.
Over time, the FNC and NSF may decide to use other delegation
models, such as those described below for non-governmental TLDs.
1.5 The International Top Level Domains (iTLDs) COM, ORG, and NET
The iTLDs are generic top level domains which are open to general
registration. They are currently delegated to the InterNIC by the
authority of the IANA.
1.5.1. The intent for these iTLDs is discussed in RFC 1591.
Generally, COM is for commercial organizations (e.g., companies
and corporations), NET is for the internal infrastructure of
service providers, and ORG is for miscellaneous organizations
(e.g., non-profit corporations, and clubs).
1.5.2. There is a perceived need to open the market in commercial
iTLDs to allow competition, differentiation, and change, and
yet maintain some control to manage the Domain Name System
operation.
The current monopoly situation with regards to these domain
spaces, and the inherent perceived value of being registered
under a single top level domain (.COM) is undesirable and
should be, to the extent possible, neutralized.
Open, free-market competition has proven itself in other areas
of the provisioning of related services (ISPs, NSPs, telephone
companies) but does not appear to be applicable to this situation.
as these aforementioned services deal with a finite resource
(limited radio frequency spectrum, area codes, etc).
It is considered undesirable to have enormous numbers
(100,000+) of top-level domains for administrative reasons and
the unreasonable burden such would place on organizations such
as the IANA unless such organizations are compensated for the
extra expense (and only for the expenses, and no more).
It is not, however, undesirable to have diversity in the top-
level domain space, and in fact, positive market forces dictate
that free enterprise and open competition will give users
of the internet many options and will foster excellence in
service.
In the real world, when a company is created, the government
agency that acts as a registry for corporations (state
departments of commerce) operate on a first-come, first-serve
basis. That is, whoever is the first to claim a company name
gets it. This has worked fine in the past and should be the
guiding principle of this new policy.
1.5.3. As the net becomes larger and more commercial, the IANA
needs a formal body to accept responsibility for the legal
Palmer Expires Jun-97 [Page 3]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
issues which arise surrounding DNS policy and its
implementation.
1.6. This memo deals with introducing new registries for iTLDs and
additional iTLDs names, it does not deal with the longer term
issue of the management and charter of the current iTLDs (COM,
NET, and ORG), or the specialized TLDs (EDU, GOV, MIL, and INT).
The current iTLDs may come under the provisions of this document
when their current sponsorship relationship ends.
The specialized iTLDs have such restrictive requirements for
registration that they do not play a significant role in the
competitive business environment.
1.7. Trademarks
Domain names are intended to be an addressing mechanism but
in many places, reflect trademarks, copyrights and other
intellectual property rights. This policy must acknowlege
this
Except for brief mentions in sections 6.1, 6.4, and 9.3,
trademarks are not further discussed in this document.
2. Goals
To facilitate administration of the domain name subsystem within the
Internet by ensuring that there is a marketplace for clients to obtain
and subsequently maintain delegation of subdomains within the iTLDs,
while preserving the operational integrity of the Internet DNS itself.
The specific measures to achieve this objective are as follows:
2.1. Provide the IANA with the international legal
umbrella of the Internet Society (ISOC),
2.2. Allow domain name registration in the iTLDs,
which will then allow registries to charge for their services,
2.3. Allow multiple registries to operate cooperatively and fairly in
the COM domain and/or other multi-registry iTLDs which may be
created,
Palmer Expires Jun-97 [Page 4]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
2.4. Facilitate creation of new iTLDs in a fair and useful, but
reliable, fashion,
2.5. Provide for reliable maintenance of the registrants of an iTLD
should the current delegatee no longer wish to maintain it, and
2.6. Define iTLD policies and procedures by open methods, modeled on
the IETF process and/or using IETF mechanisms when appropriate.
3.0 Scope of this Document
This document describes the administrative structure for the
operation of the iTLDs. While other administrative issues may exist
within the broader domain of the DNS, they are not addressed in this
document.
Specifically:
3.1. Only those relationships between the IANA, IETF, and ISOC which
are specifically necessary for responsible maintenance of the
iTLDs are described.
3.2. The Board of Trustees acts for the ISOC, the IAB for the IETF,
and the IANA for itself.
3.3. Long range maintenance of the IANA is not described; It is not
the subject of this document and fees for iTLD's should be used
only to support the root name servers and any other support
structures neccessary to directly support management of iTLD's
by the root servers and IANA.
3.4. The IETF is not directly involved in operation of the net.
Hence it serves the iTLD administrative work mainly in a technical
capacity, such as the formalization of new protocols and the
handling of technical appeals.
3.5. The ISOC does not directly operate the net. But it takes legal
responsibility for standards processes and some network management
processes, manages funds, and participates in the appeals process.
3.6. The IANA and any necessary ad hoc groups deal with operational
details.
3.7. The ISOC, the IETF, and the IANA are not to be legally or
financially responsible for the registries. The registries must
be responsible for themselves.
3.8. Creation of a large staff is not desired.
Palmer Expires Jun-97 [Page 5]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
4. Technical Assumptions
Further growth within the iTLDs can be accommodated technically, and
tools are in evidence to automate much of the process of registration
and maintenance of entries within the DNS as well as multiple
administrative access to a single delegated domain.
4.1. The size of current TLD databases such as COM, while large, is
not really a burden on servers, nor is it expected to become so in
the near future.
4.2. Procedures which allow mutual exclusion for the creation of
names within a single TLD are being developed within the IETF's
"dnsind" and "dnssec" working groups, and a test implementation is
available.
4.3. Tools are being developed to ease the processes of registration
and running the information servers which are expected of
registries.
5. The Process
5.1. The IANA continues to supervise and control all operational
aspects of the iTLDs, and is the second level of the appeals
process after the registries (which are the first level). It
appoints three members to the ad hoc iTLD group(s). The IANA may
directly review appeals and/or it may ask the IDNB to participate
in the review of an appeal.
As described in RFC 1591 regarding a dispute between parties
contending for the management of a national TLD, the Internet DNS
Names Review Board (IDNB), a committee established by the IANA,
will act as a review panel for cases in which the parties can not
reach agreement among themselves.
Now the role of the INDB is expanded to include appeals on a
technical basis of the process documented in this memo.
5.2. The IETF, as part of its normal procedures, publishes documents
which describe technical and operational aspects of the domain
space including the iTLDs. Via the IAB, it also provides an
appeals procedure for process issues and appoints two members to
the ad hoc iTLD group(s). The IAB reviews appeals that question
whether the process was properly followed.
Palmer Expires Jun-97 [Page 6]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
5.3. The ISOC provides the legal and financial umbrella, and the
final level of the appeal process. Via the BoT, it provides an
appeals procedure for procedural issues and appoints two members
to the ad hoc iTLD group(s). The ISOC assumes legal liability for
the process and the iTLDs. The ISOC BoT reviews appeals that
question the fairness of the process.
5.4. The ad hoc working group, for developing procedures and deciding
creation of new iTLDs and chartering of registries, consist of
seven members appointed by the IANA (3), the IETF (2), and the
ISOC (2).
5.5. Note that 'ad hoc' means 'for this purpose only.' In this case,
a new ad hoc group is created and convened on a periodic basis
(probably annual) when needed to change procedures or to review
registry and iTLD applications.
5.6. It is estimated that approximately ten (10) new registries and
thirty (30) iTLDs will be created per year. It is expected that
this will continue for the next five years - unless something
significant happens to change this plan. In this first year of
this plan more new registries may be chartered, perhaps up to
fifty (50). These estimates should NOT be used to restrict the
number of new iTLDs, however.
5.7. The policies and procedures to be used by the ad hoc working
group will be decided by the first ad hoc group in an open process
and will be clearly documented. This group will be appointed and
convene in in the next few months. It is expected that these
policies and procedures will mature over time.
5.8. Multiple registries for the COM TLD database, and multiple
registries for other (new and old) iTLDs may be created in the
future.
5.9. New iTLDs will be created over time. This is a direct change to
RFC 1591. New iTLDs may be created with a non-exclusive
administration arrangement, i.e. multiple operators for any
further iTLDs may be within the conditions of creation of an iTLD.
Note that it is not required that multiple operators exist for
an iTLD.
5.11. Registries pay for charters, and the fees collected are kept in
a fund managed by the ISOC and used for the iTLD process (such as
for insurance against an iTLD registry withdrawal or collapse),
but UNDER NO CIRCUMSTANCES should these funds be used for current or
future funding models for other activities of the IANA.
Palmer Expires Jun-97 [Page 7]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
6. Selection of iTLDs and Registries
6.1. The New Registries and iTLDs
[In future years, charters may be for a new registry (creating a
multiple registry iTLD) for either an existing iTLD or a new iTLD,
or for renewing the charter of an existing registry and iTLD(s).]
6.1.1. The new iTLD Name Space
It is desirable to maintain a "short" suffix on these iTLDs to
permit easier use by the public. As such, the presumption will
be that three to six-character alphanumeric iTLDs will be
assigned.
The space of new iTLD names will be restricted to alpha numeric
strings of from 3 to 6 characters. iTLD names are case
independent (i.e., COM = com = cOm).
Palmer Expires Jun-97 [Page 8]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
6.2. Who May Apply
Persons or organizations wishing to operate registries and manage
iTLDS shall send applications to the IANA in accordance with the
provisions of this memo.
A "person or organization" may be a single person or organization
or any group of persons and organizations which may combine to
offer registration services under one name as a cooperative or
competitive provider of services, provided that all partners in
the confederation or alliance shall otherwise be in compliance
with the terms of this document. Organizations granted iTLD names
may add or remove additional cooperating registration partners at
their discretion, provided that doing so does not violate the
provisions of this memorandum.
6.3. Open Process
The applications for iTLD domain names and registries shall be
evaluated in a neutral, impartial, and open manner. Applications
shall be approved if the applicant can show it can provide the
name servers for the iTLD's and that these servers are robust
enough to survive network outages (see below). It is suggested
that a WHOIS database be operated by the registries, but at this
time, it is not required.
The proceedings and evaluations of the applications submitted
shall be available for public inspection via an on-line procedure
(e.g., web site) along with the decisions made.
Financial and business aspects of proposals are kept confidential
during the evaluation process. The complete proposal of the
successful applicants, including these aspects, will be made
public at the completion of the ad hoc committee process.
6.3. Review Criteria
The only review criteria allowed is wether or not the applicant
can supply a robust name server configuration for the requested
iTLDs. Applicants who meet this requirement and that pay the
annual fee MUST be appoved. No other discretion is allowed.
Palmer Expires Jun-97 [Page 9]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
6.3.1. Registration Services
Each registry holding a iTLD shall provide the following
administrative services and policies:
1) Access to the Registration Database
The DNS database files and "whois" databases maintained by any
iTLD operator are deemed to be publicly available and public,
non-protected information, if the organization operates such
a database.
A registry shall provide guaranteed availability of the
registration data in a useful form should transfer of
responsibility become necessary, e.g., regular publication of
the information, or regular deposits of copies of the
information with a reputable escrow agent instructed to release
the information to the IANA.
The IANA is authorized to designate one or more organizations
as "escrow holders" of said database information for the
purposes described below under "Termination of Registries".
Internal database and operational issues are to be decided by
Palmer Expires Jun-97 [Page 10]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
the registry. These issues, including pricing to customers of
the registry, are properly free-market issues and are excluded
from the control of the IETF, IANA, ISOC and other related
organizations.
2) Published policies on services offered, registration
procedures, and fees, available via WWW, FTP, and automated
email responder at an address associated with the organization.
3) A clear description of the appeals mechanism within the
registry, including the entry point for appeals and the
expected response time.
6.3.2. Operational Resources
1) Internet Connectivity
A description of the Internet connectivity to the site where
each nameserver for each iTLD will be located.
For example, a diagram showing full multi-homed connectivity to
the organization's computers which will serve as the iTLD
nameservers, with each leg of that connectivity being at a
non-aggregated data rate of <whatever>.
And route advertisement via BGP4 for this organization's
connectivity must be operational for the connections maintained
under this provision, and the network involved should be
operating in a "defaultless" configuration.
2) Nameserver Performance
The description of at least two (2) nameservers for the iTLDs
in question. These nameservers shall run the latest
"consumable" release of the BIND code (4.9.x at present), and
may include local enhancements, changes, or operational
improvements.
The names and IP addresses of the hosts which are proposed to
serve the iTLDs.
Palmer Expires Jun-97 [Page 11]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
6.4. The Application
All of the information required to be supplied with an application
should be prepared for transmission via email in plain ASCII text.
The details of the submission of applications will be determined
by the ad hoc committee.
The application shall include the following:
6.4.1. Applicant Name
The name of the applicant, including the contact information.
6.4.2. iTLD Names
The iTLDs proposed.
6.4.3. The Criteria Statements
These statements should include:
A clear statement of the charter, policies, and procedures,
a statement of registrant qualification procedures and a
statement that they will be non-discriminatory,
a description demonstrating the organizational and technical
competence to run a registry and the expected accompanying
information services,
a statement that the registry will abide by the results of the
appeals process and the direction of the IANA.
Palmer Expires Jun-97 [Page 12]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
6.4.4. The Application Fee
A non-refundable application fee of USD 1000 payable to the
"Internet Society" to be deposited in the "iTLD fund".
If approved, this fee pays for one year of charter.
6.5. Charters are for a period of five years.
6.5.1 Previous Applications
The IANA, when executing the "first-come, first-serve"
paradigm, will honor any applications sent to the InterNIC for
iTLD's prior to the adoption of this policy. That means if there
were any applications submitted before this policy was adopted,
that they get placed first in line.
The IANA will notify any persons or organizations who have
previously sent in an InterNIC domain template with an application
for a top level domain, that a policy is now in place and will inform
said person or organization that he/she/it has the right to claim
that iTLD. IANA will send a copy of all application instructions and
a copy of this policy to that person or organization.
6.9. Schedule
There are several stages that each take some time: forming the ad hoc
committee, finalizing the procedure, accepting the applications, and
evaluating the applications.
6.9.1. Assume the ad hoc committee is be formed day 1.
6.9.2. The ad hoc committee will finalize and announce its procedures
by day 30.
6.9.3. The ad hoc committee will begin accepting applications.
6.9.4. The ad hoc committee will review the applications and announce
all of the applcations which meet the criteria beginning on day 135.
For example suppose the ad hoc committee was formed on 1-May-96.
Then the schedule would be:
12-Nov-96 ad hoc committee formed
15-Jan-97 procedures finalized,
begin accepting applications
01-Mar-97 announce first appovals
Palmer Expires Jun-97 [Page 13]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
7. Termination of Registries
iTLD registries may decide they no longer wish to operate their
registry. Likely, the operation will not be profitable when this
occurs, yet the registrants under the iTLD may need to be supported
for a considerable time.
Some portion of the fees in the ISOC-managed iTLD fund are reserved
to pay for some other organization to operate the failing iTLD or
registry until it again becomes viable or until the registrants have
safely migrated elsewhere.
While it is unclear how expensive providing even temporary service
for the iTLDs of a failed registry might be, the iTLD process must be
prepared for the case where a very popular, possibly because it is
low cost, iTLD or registry fails.
Some views on the possible scenarios:
It will be very expensive.
Bailing out the registrants of a failing domain could be very
expensive, even on the order of a million USD (remember, a
likely failure mode may be because someone thought they could
do it for less).
It is not a big deal.
It is presumed that any registry with a significant client base
will constitute a legitimate on-going business interest with
revenue prospects sufficient to insure that the registry will
in fact be transferred to another organization.
As an example, presuming 5,000 registrants of a given registry
and a fee of 50 USD per year, a revenue stream of 250000 USD
per year would inure to the benefit of any organization taking
over the services of a defunct organization.
Should a registry close without having significant second-level
registrations in place at that time, the impact to the Internet
users as a whole will be minimal or non-existent.
Succession issues related to the relationships between customers of a
registry and that registry itself are properly contractual matters
between the registry and its customers, and when properly attended to
do not involve the IETF, ISOC, or the IANA.
The IANA or its designee may operate one or more "escrow services" to
Palmer Expires Jun-97 [Page 14]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
insure that the records contained in a registry will remain available
in the event of intentional or accidental destruction due to a
registry forfeiting a iTLD.
Organizations providing registry services may elect to terminate
their involvement in this program and release the iTLD namespace
delegated to their organization under the following circumstances:
7.1. Any organization may transfer the authority for, and
registration services provided, for a iTLD to any other
organization provided that the new registration authority complies
with all provisions of this memorandum. The business and
financial terms under which this transfer is conducted shall be
properly between the old and new registry organizations and not
under the jurisdiction of the IANA, the IETF or the ISOC. However,
the IANA must be notified of such a transfer, and the charter of
the registry for the management of these iTLDs shall be reviewed
as a renewal of the charter at the next normal session of the ad
hoc committee.
7.2. iTLDs which are "orphaned" by a registry that constructively
abandons them or ceases business operations without first securing
a successor organization to assume the authority and registration
services for that namespace shall be deemed "abandoned".
Abandoned iTLD namespace shall be auctioned to the highest bidder
by an open, competitive bid process adjudicated by the IANA or its
designees, which shall be conducted without undue delay. During
the interim period in question the IANA shall be authorized to
designate one or more firm(s) to hold the existing registration
records to prevent the interruption of service.
7.3. An organization which is alleged to be in violation of the terms
of this delegation memorandum shall be given notice of intent to
recover the iTLD domain space allocated under this policy via
normal postal mail. Within 30 days, the organization against
which the complaint has been lodged shall a) cure the violation(s)
of this policy, (b) transfer authority to another organization
under 7.1 above, or (c) constructively abandon
the namespace under the provisions of 7.2 above. Where the facts
are disputed regarding possible violations of this policy, the
IANA is authorized to promulgate reasonable adjudication policies
which should include an arbitration provision.
Palmer Expires Jun-97 [Page 15]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
8. Finances
It is desirable to keep the IANA and IETF from becoming involved in
operational and contractual aspects of the iTLD registries, and it is
further desirable to separate, to the extent possible, the IETF and
IANA funding from these organizations.
It is presumed in the best interest of the IETF and the IANA to see
that this separation of function is preserved.
Note:
8.1. A registry may charge as it sees fit, within the bounds of the
policy published when it is chartered.
8.2. The ISOC manages all finances in a separate iTLD fund with open
reporting and published budgets. Agreement of the ISOC, the IANA,
and the IETF is required on all budgets. The IANA must publish
an annual report showing revenues and expenses related to the
operation of iTLD's and also a budget for the next calendar year.
This report is due in public on March 1st of the succeeding year.
The new budget is due in public on Oct 1st of the succeeding year.
8.2.1 The annual charter fee for a particular year shall be the current
years expenditure divided by the current number of iTLD's plus
10 percent for inflation with a minimum charter fee of US$1,000
8.3. Charter fee income may be used to pay legal costs of the IANA,
IETF, ISOC, and ad hoc groups when serious legal disputes arise
from the iTLDs process, But only those legal costs associated with
iTLDs and only of one of the aforementioned agency is named as a
party in a suit.
8.4. Charter fee income is also used to pay modest and publicly
visible costs of the chartering process, e.g., the costs of the ad
hoc committee.
8.5. Charter fee income may NEVER be used to fund the IANA in its other
activities not related to iTLDs.
Palmer Expires Jun-97 [Page 16]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
8.6. Should the reserves be too large, the surplus should be paid
back to charter holders by decreasing the annual charter fee in
subsequent years. During any calendar year, if there is a large
surplus, that surplus must be paid back in reduced charter fees
within TWO calendar years.
8.7. The ISOC may charge a modest amount for administering the iTLD
account.
9. Appeals
Arbitration to resolve conflicts is encouraged. That an appeals
process is specified should not preclude use of arbitration. The
appeals process described here is for when arbitration has failed or
when the parties decide not to use arbitration, yet they do not wish
to exercise recourse to lawyers and the courts.
9.1. The appeals process does not apply to disputes over Intellectual
Property Rights on names (trademark, service mark, copyright).
These disputes are best left to arbitration or the courts.
Registries may require appropriate waivers from registrants.
9.2. The appeals process does not apply to charging and billing.
This is left to market forces, arbitration, and the courts.
9.3. The appeals process applies to all other aspect of registry
processing of registration requests.
8.4. A registrant's first recourse is to the registry which has
denied them registration or otherwise annoyed them.
9.5. All registries must specify in their applications an entry point
and a process for appeals, as well as a response time, and must
subsequently conform to them.
9.6. If appellant is dissatisfied with the registry response, appeal
may be escalated to the IANA. The IANA hears appeals based only
on technical issues. Note that the IANA may use the IDNB to
process the appeal.
9.7. The IANA must define its entry point for appeals and must
respond to appeals within four weeks.
9.8. If appellant is dissatisfied with the IANA response, and the
appeal has nontrivial process aspects, the appeal may be escalated
to the IETF. The IETF (via the IAB) hears appeals based only on
process issues, that is breach of appeals procedure.
Palmer Expires Jun-97 [Page 17]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
9.9. If appellant is dissatisfied with the IANA and, if invoked, the
IETF response, appeal may be escalated to the ISOC. The ISOC
appeals process hears appeals only about the fairness of the
procedure. I.e. the decision of IANA and/or IETF is final,
unless there is an appeal that the procedure itself is unfair.
9.10. The appeals process works by email. Appellant must provide
concise history of the case and summarize grounds of appeal. The
IANA, the IAB (acting on behalf of the IETF), or the ISOC may ask
for information from third parties. All information is normally
treated as nonconfidential and may be made publicly available.
Confidential information is considered only in special
circumstances.
9.11. The IANA, the IETF and the ISOC may establish appeals sub-
committees chosen either from their own membership or outside of
it by whatever means each deems reasonable for their procedures
and purposes.
10. Security Considerations
There are no known security considerations beyond those already
extant in the DNS.
11. Acknowledgments
This memo is a considerable rip off of a draft by Randy Bush and
Jon Postel, combined with substantial inclusion of material from
a draft by Karl Denninger.
To the base of 53-C, I've made many changes. The significant ones
deal with ELIMINATING any unlawful enrichment scheme of the IANA
and ensuring that ONLY THE FUNDS needed to support the root servers
(or the portion dealing with iTLDs) and modest IANA administrative
costs associated with iTLDs. The second one was ENSURING "first-come,
first-serve" policy.
A lot of significant and constructive input and review was received
from the following: (These were included by Jon Postel)
Alan Barrett <apb@iafrica.com>
Randy Bush <randy@psg.com>
Brian E. Carpenter <brian@dxcoms.cern.ch>
Karl Denninger <karl@MCS.Net>
Robert Elz <kre@munnari.oz.au>
Geoff Huston <gih@aarnet.edu.au>
John Klensin <klensin@mci.net>
Lawrence Landweber <lhl@cs.wisc.edu>
Palmer Expires Jun-97 [Page 18]
RANDOM DRAFT 53-D.1 Delegation of iTLDs December 1996
12. Author's Address
John Palmer
AGN Phone: +1 810 790-9522
Internetworking Services Fax: +1 810 790-0156
31511 Harper Ave.
St. Clair Shores, MI 48082 Email: jp@AGN.NET
Palmer Expires Jun-97 [Page 19]
</pre>